【Kiro】進捗とともに生成AIのクレジット消費ペースは上昇するのかもしれないというお話

こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
昨年夏頃から、Kiroによるスペック駆動開発（仕様駆動開発）について試行錯誤をしております。

blog.serverworks.co.jp

先日一つ感想を述べたのですが、あれから少し時間が経ち、今度はKiroのコスト面＝生成AIのクレジット消費量について感じたことがあるので、今回はこちらについて述べていきます。

はじめに
Kiroのクレジット消費量
開発の進行とクレジット消費量の変化
プロジェクトマネジメントにおけるクレジット管理の必要性

はじめに

本記事は、私がKiroで個人開発した体験をもとに書いた内容です。
実験的にKiroおよびAIに全力で任せる方針で開発をしていたので、実案件で起きることとは乖離があるかもしれません。
そうなるかもしれないという気持ちで読んでいただけると幸いです。

Kiroのクレジット消費量

Kiroはサブスク契約となっており、プランごとに月間のクレジット消費量上限が決まっています。

kiro.dev

私はProプランを利用しており、月間1,000クレジットが上限となっています。
なお、クレジットはOveragesという設定を有効にすることで、上限を超えても利用できるようになります。
ただし、Overages分は従量課金となりますので、使いすぎには注意が必要です。

Kiroのクレジットは、バイブコーディングでもスペックでも消費されます。

開発の進行とクレジット消費量の変化

私は昨年の夏頃からKiroを利用して個人開発を進めています。
WBSを作成し、ワークパッケージ単位でスペックを作成して実装していくスタイルで進めていました。
作り込みはまだまだ甘いですが、一旦形になった時点でスペックの合計は46となりました。

ここで気になったのが、開発の後半に差し掛かった11月頃から、クレジット消費量が急激に上がった点です。
最終的には、1つのスペックを実装し切るのに200〜300クレジット近く消費するようになりました。
初期は1つのスペックあたり2桁ぐらいだったので、クレジット消費量の上がり方に少々戸惑いました。

開発の後半になり、機能を束ねた統合的な機能を実装するようになってから、クレジットが跳ね上がった印象です。
意外だったのはコア機能を実装していたころはクレジットはそこまで気にならなかったことです。
難易度が少々高くとも、単一機能の実装であれば、クレジット消費量は抑えられていたように思います。
AIが組み合わせをする段階で、各機能の詳細を再チェックしながら辻褄合わせをするのに手間取っていたように見えます。

また、ぱっと見同じようなサイズのスペックでも、開発の前半と後半でクレジット消費量が異なるように感じました。
これは、全体のコード量が増えていくことで、AIが参照する情報量が増えたことが影響していると考えています。

プロジェクトマネジメントにおけるクレジット管理の必要性

今回の経験から、開発におけるクレジットの消費ペースは一定ではないなと理解しています。
WBSとそのワークパッケージ、そしてスペックの粒度と難易度にバラつきがあったとは思いますが、実案件でも開発のある段階でクレジット消費ペースが急激に上がるシチュエーションは起き得るだろうと考えています。
KiroをはじめとしたAIをフル活用して開発を進めた場合、プロジェクト佳境に入った時に急にクレジット不足になったらかなり焦りそうです。
それを考えると、以下のことを考えておく必要がある気がします。

十分なクレジットの確保
クレジット不足が起きた場合の追加購入手段
クレジットの節約
クレジットのモニタリング

挙げはしましたが、現実問題としてプロジェクトの途中でクレジットの追加購入は難しい気がしますね。
私が相談される立場だとしたら、あらかじめ言っておいてくれないと・・・という反応をしそうです。
となると、最初から十分なクレジットの確保をするか、クレジットの節約を最初から考慮した開発計画を立てる必要がありそうです。

節約と言えば、今のところ私の方では結合テストやE2EテストのコードはAIに丸投げするのはよくなかったかなと感じています。
この2つをAIに任せると、整合性を取るためにかなりのクレジットを消費してしまう印象です。
AIがテストが通らない状態からなかなか抜け出せないループに陥ることもありました。
（これについては、実験がてらあえて静観していた部分もあります。）
3・4割は自分で書いて、AIには補助的に使うくらいがちょうど良かったのかもしれません。

モデルに最新のClaude Sonnetを積極的に選択したのもよくなかったのかもしれません。
Claude Sonnet4・4.5は、クレジット消費量が1.3倍ですからね。
しかし、先述のテストコードのループ状態は4.5でないと抜け出せないシチュエーションがあったので、難しいところです。

以上のことから、最初から最後までAIをフルに活用できる環境を前提とした計画は、ちょっと怖いなと思っています。
AIにやらせるまでもない部分は人間がやるという線引きをしておくのと、無理にAIで解決させようとしない方針が必要と感じます。
あとは、適度にモデルを切り替えながら使用するぐらいですかね。

クレジットのモニタリングは、チームレベルではどうするべきかはまだ見えていません。
個人のクレジットはVisual Studio Codeでも、Kiroのダッシュボードでも確認できますが、チーム全体での消費量を把握する手段は今のところ私の方ではわかっていません。
今後、何かいい方法があれば、また共有したいと思います。