【ITニュース解説】Kiro: the good, bad and ugly part in my personal experience

Kiroは、AIの力を活用してソフトウェア開発を支援する、新しいタイプの統合開発環境（IDE）である。プログラミングを行うためのツールが一つの場所で利用できるのがIDEだが、KiroはここにAIを深く組み込み、開発プロセスをより計画的かつ効率的に進める「スペック駆動開発（SDD）」という考え方を提唱している。これは、コードを漠然と書き始めるのではなく、まず「何を作るか」という要件を明確にし、その後に具体的な設計、そして実行すべきタスクへと段階的に進める方法だ。KiroのAIは、この開発の各段階で支援を提供し、プロジェクトの背景情報やルールを「Steering」という機能でAIに与えることで、より的確なアドバイスやコード生成が可能になる。また、「Hooks」という機能を使えば、ファイルの変更を検知してテストの生成や文書の更新などを自動で行わせることもできる。

Kiroの中心的な機能である「Spec」は、要件定義、設計、タスクの三つの文書を通じて開発を進める点が特徴である。まず「requirements.md」は、ユーザーの視点から機能をどのように使いたいかという要件を洗い出す。これは開発者の指示を基にAIが生成し、開発者が自身のアイデアを整理し、具体的なユーザーの振る舞いや成功基準を考えるための手助けとなる。次に「design.md」では、要件に基づいて技術的な設計を行う。漠然としたアイデアも、この段階でAIが適切な技術用語、システム構成図、アーキテクチャの方向性などを提示してくれるため、開発者は新しい知識を得ながら、より具体的な設計へと落とし込むことができる。最後に「tasks.md」は、設計書の内容を具体的な作業リストに分解する。このリストは「進行中」「完了」「失敗」といった状態を持ち、開発者はこのリストに沿って作業を進められる。特に優れているのは、このタスクリストからGitのブランチ作成やコミットメッセージまで自動生成できる点で、開発者はAIに細かく指示を出さなくても、Gitを使った開発フローを自動化できる。例えば、ある開発者がUIデザインのテンプレートである「デザインシステム」を作成する際、Kiroに既存のコードベースを分析させ、特定のスタイル（例えば「ネオブルータリズム」）に変えるよう指示するだけで、一貫性のあるデザインシステムを一気に生成できたという成功事例は、KiroのSpec機能の大きな可能性を示している。画像を参考にしてデザインシステムを生成できる点も強力だ。

しかし、Spec機能にはいくつかの課題も存在する。まず、その流れが固定的であり、要件定義、設計、タスクという順番を常に踏まなければならない。例えば、設計書だけを生成したい場合でも、必ず要件定義から始める必要があるため、柔軟性に欠ける。また、Specの生成や修正、AIとの会話を通じて内容を練り上げていく過程で、Kiroが「vibe」と呼ぶクレジットが消費される。これはカジュアルなチャットと同様に課金されるため、計画的に開発を進めるためのSpecであるにもかかわらず、その調整や改善のたびにコストがかかるのは不満点として挙げられる。さらに、初期段階のAIはテストの生成に非常に積極的で、単体テスト、結合テスト、エンドツーエンドテストといったあらゆる種類のテストコードを大量に生成しがちである。まだ機能が固まっていない段階では、これらの過剰なテストは無駄な作業となり、クレジットを急速に消費してしまう。この問題は「Steering」ファイルでテストの量を調整できるものの、初心者はその設定に気づきにくい可能性がある。

二つ目の主要な機能である「Hooks」は、ファイルイベントをトリガーとして自動処理を行う仕組みだ。例えば、APIのエンドポイントを変更すれば自動的にAPIドキュメントを更新したり、新しいモジュールを追加すれば関連するテストファイルのひな形を生成したりと、定型的な面倒な作業をAIが自動でこなしてくれる。これはまるで、見えないジュニア開発者が常に裏で開発者をサポートしているような感覚で、開発者はより創造的な作業に集中できる。しかし、このHooks機能にも改善点がある。たとえ小さな修正によるフックの実行であっても、1回の「vibe」クレジットを消費するため、コストに見合わないと感じることがある。例えば、軽微なコードの整形（linting）のような小さな自動化でも、大規模なコードの変更と同じクレジットが消費されるのは効率が悪い。さらに、「Hooks」はKiroのエディター内でファイルを明示的に保存したり、新規作成したりした場合にのみトリガーされるという制約がある。つまり、IDEの外からファイルを変更したり作成したりしても、フックは作動しない。これにより、開発者が期待する「自動化」の範囲が狭まり、ワークフローへの組み込みに限界が生じる。

Kiroの全体的なAIエージェント体験は、非常に高度なものを提供している。チャット形式のサイドバー、優れたコンテキスト管理、コードベース全体を理解する能力、ターミナルでのコマンド実行、そして複数のファイルを意識した処理が可能である。特に「Steering」によるコンテキスト管理は優れており、プロジェクトの特定のフォルダやファイルに対して異なるルールや指示を適用できるため、AIの動作をきめ細かく制御できる。チャットサイドバーは、高度なAIモデル「Claude Sonnet 4」を搭載しており、開発者の長い指示を理解し、一度に2000行以上の大量のコードを生成することも可能だ。また、「#codebase」というキーワードを使えば、プロジェクト全体のコードから必要な情報を素早く検索できるため、明確な指示があれば、非常に効率的なコーディングパートナーとして機能する。

一方で、エージェント体験にもいくつかの課題が見られる。ターミナルでのコマンド実行がしばしば停止し、手動での入力が必要になることがある。また、Spec機能と同様に、AIはテストを過剰に生成する傾向がある。最も大きな問題は、料金モデルとクレジット消費の仕組みである。Kiroの無料枠は月に50回と generous（寛大）に感じるが、AIがタスクに取り組む時間や、その間の開発者とのやり取りが全てクレジットを消費するため、たった2時間の作業で無料枠を使い切ってしまうことも珍しくない。料金体系が不明瞭で、クレジットの消費速度が開発者の期待と合わないため、不満を抱く開発者もいる。さらに、コンテキストの要約やプロンプトの修正・再入力といった、試行錯誤やデバッグの過程で行う操作のたびにクレジットが消費されるため、開発の勢いを削ぎ、ストレスを感じる要因となる。クレジットの残量を気にしながら開発を進めることは、AIがもたらすはずの生産性向上を阻害する。

総じてKiroは、AIを活用したコーディング支援の分野で非常に意欲的で大胆な試みである。Spec機能はその構造化されたアプローチが教育的であり、開発者の思考を整理する上で非常に役立つ。Hooksは適切に機能すれば強力な自動化ツールとなり、エージェントの全体的な体験は、優れたコンテキスト理解とコード生成能力によって開発を加速させる可能性を秘めている。しかし、その強力な機能の裏側には、柔軟性に欠けるSpecのフロー、小さな自動化にもコストがかかるHooks、そして何よりも理解しにくく、急速に消費される料金モデルとクレジットの仕組みといった課題が横たわっている。中規模から大規模な、計画的なプロジェクトには将来性が感じられる一方で、試行錯誤を繰り返す高速な開発には向かない側面もある。今後、他のIDEも同様のAI機能を搭載してくることが予想される中で、Kiroがこの分野での優位性を保つには、これらの課題を克服し、より使いやすく、コスト効率の良い開発者体験を提供する必要がある。スペック駆動開発に長けているだけでは不十分で、全体的な開発者体験の改善が強く求められるだろう。