Kiro、1 歳。コードを書く IDE から、仕事を任せるチームへ
2026-08-03 | Author : 稲田 大陸 (いなりく)
はじめに
こんにちは ! ソリューションアーキテクトの いなりく です !
1 年前の私は、AI コーディングエージェントの「完了しました !」に何度も騙されていました。自信満々の宣言の裏でテストは落ちている。ビルドは通っていない。問い詰めると「申し訳ありません、修正します」と素直に謝り、今度は別の場所を壊す。可愛げはあるのですが、仕事は任せられない。それが 2025 年夏の正直な体感でした。
その Kiro が、2025 年 7 月 14 日の Preview 公開から 1 年を迎えました。 1 周年ブログ はこの 1 年を「AI コーディングからエージェンティックエンジニアリングへの進化」と総括しています。きれいな言葉ですが、私の実感で言い換えるとこうなります。
この 1 年は、機能が増えた歴史ではなく、開発のボトルネックが移動し続けた歴史でした。
生成が詰まりどころでなくなると意図が、意図を残せると検証が、検証が揃うと分業が、分業が進むと権限が、権限を引けると今度は人間の画面そのものが、次のボトルネックになる。私はこの 1 年、Kiro Changelog で「何が変わったか」を確認し、自分の環境で「本当にそう動くか」を試し、その往復を Kiro の仕様駆動開発、Kiro にハーネスを付ける、Kiro CLI の /goal という記事に書いてきました。本記事では、その立場から Kiro の 365 日を「ボトルネックの移動」として 5 つの転機で振り返ります。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
まずは 1 年を一枚で
1 つ解決するたびに、次の詰まりどころが顔を出す。この繰り返しを順に見ていきます。
|
時期
|
主な出来事
|
ボトルネックの移動
|
|---|---|---|
|
2025 年 7 月
|
Preview。Specs、Hooks、Steering、MCP |
生成 → 意図 |
|
2025 年 11 月
|
GA。PBT、Checkpointing、Kiro CLI、組織管理 |
意図 → 検証 |
|
2025 年 12 月 ~ 2026 年 2 月
|
Autonomous agent (Preview)、Powers、Subagents、Skills |
検証 → 分業 |
|
2026 年 2 月 ~ 4 月
|
Governance、GovCloud、CLI 2.0、Headless mode |
分業 → 権限 |
|
2026 年 5 月 ~ 7 月
|
Kiro Web、Automations、iOS、 /goal 、Agent Focus |
権限 → 指揮 |
第 1 の転機 : 速く書ける。でも、意図が消える
2025 年 7 月、Preview 公開の時点で、プロンプトを重ねれば動くアプリケーションはすでに作れました。生成そのものは、もうボトルネックではなくなりつつあった。困っていたのは、3 日後の自分が「なぜこの実装なのか」を思い出せないことです。AI が勝手に置いた仮定、チャットで伝えたはずの判断、除外したはずの要件。全部、会話の奥へ流れて消えます。
Introducing Kiro が示した回答が Specs でした。自然言語の依頼を requirements.md、design.md、tasks.md へ変換し、受入基準、設計判断、実装順序をレビューできる形で残します。Marc Brooker は公開翌日の記事「Kiro and the future of AI spec-driven software development」で、Spec を「version controlled, human-readable super prompt」、つまりバージョン管理でき、人が読めるスーパープロンプトと表現しました。言い得て妙です。プロンプトは消えますが、Spec は git に残ります。
Specs が意図を残し、Steering が規約を伝え、Hooks が保存やコミットを合図に決まった仕事を起動し、MCP が外部の道具へつなぐ。最初の Kiro が解いたのは「もっと速く書く」ではなく、書いたそばから意図が消えるというボトルネックでした。
ただ、意図が残るようになると、新しい疑問が生まれます。この実装は、残した意図を本当に満たしているのか ?
図: 「vibe coding の流れ」と「Spec の明確さ」の重なりとして表現された公開当初の Kiro (出典: Introducing Kiro）。
第 2 の転機 : 作れる。でも、「正しい」と言い切れない
AI に「テストも書いてね」と頼むと、AI は自分の答案に自分で採点する生徒になります。全部に丸を付けて「完了しました !」。冒頭で書いた私の苛立ちは、まさにここでした。生成の次のボトルネックは、検証だったのです。
2025 年 11 月 17 日、Kiro は GA を迎え、この問題への部品が一気に揃います。象徴が Property-Based Testing (PBT) です。「ユーザー A が商品 1 をお気に入りに追加できる」という具体例ではなく、「あらゆる認証済みユーザーと有効な商品について、追加後に一覧へ表示される」という性質を Spec から抽出し、多様な入力で反例を探します。PBT は形式検証や正しさの証明ではありませんが、AI が自作のテストに丸を付けるのとは違い、実装が Spec に適合しているという証拠を積み上げます。Checkpointing は変更を以前の状態へ戻せるようにし、「やり直せること」を自律性に組み込みました。
同時に Kiro CLI が登場し、.kiro の Steering や MCP 設定を IDE と共有したまま、ログ調査、インフラ操作、デバッグへ活動範囲を広げます。AWS IAM Identity Center による組織管理も加わり、Kiro は個人のおもちゃから、チームに導入できる開発環境になりました。
第 3 の転機 : 1 体に全部は、無理
人間のチームでも、1 人が調査も設計も実装もレビューも抱えれば、どれも中途半端になります。エージェントも同じでした。すべてのツール定義と知識を 1 つのコンテキストへ詰め込めば、肝心の仕事に使う容量が減っていきます。
2025 年 12 月 2 日、Kiro autonomous agent が Preview として一部の有料ユーザーへ段階展開されました。隔離された sandbox で非同期に働き、複数リポジトリを変更し、Pull Request を返す。人が別の仕事をしている間も進むエージェントの登場です。翌日の Powers は MCP、Steering、Hooks を「専門能力のパッケージ」としてまとめ、会話に必要なときだけ読み込みます。12 月 18 日には IDE と CLI へ Subagents が入り、調査やレビューを独立したコンテキストへ委任できるようになりました。2026 年 2 月の IDE 0.9 では、自前の Custom Subagents、持ち運べる Agent Skills、ツール実行の前後へ介入する Hooks が加わります。
Specs が「何を作るか」を残す仕組みなら、Skills や Custom Agents は「どう仕事を進めるか」を残す仕組みです。プロンプト職人の頭の中にあったノウハウが、バージョン管理できるチームの資産になりました。
ところが、分業と自律が進むほど、今度は管理者の顔が曇ります。「それ、うちの環境で動かして大丈夫 ?」
第 4 の転機 : 任せたい。でも、全権は渡せない
2026 年 2 月から 4 月にかけて、Kiro は Enterprise SSO、GovCloud、Web tools の制御、MCP Registry、Model Governance、細かな tool permission、利用状況の可視化を拡張しました。 IDE 0.11 では、IAM Identity Center を利用する Enterprise 組織の管理者が、承認済みの MCP server とモデルだけを利用者へ配れます。4 月 13 日の Kiro CLI 2.0 は Windows 対応と標準 Terminal UI に加えて Headless mode を載せ、人が画面を見ていない CI/CD の中でも Kiro を動かせるようにしました。対話で止められないからこそ、権限設計が先に要ります。
第 5 の転機 : 書く画面から、指揮する画面へ
2026 年 5 月以降の Kiro は、人の側の仕事を作り替えにきます。
まず原点の Specs が速くなりました。IDE 0.12 の Parallel Task Execution は依存しない tasks を並列実行し、Quick Plan は明確な仕事の計画を一括生成し、Requirements Analysis は要件の矛盾や曖昧さを実装前に探します。仕事の性質でプロセスの重さを変える使い分けは、私が 6 月に書いた「進化し続ける Kiro の仕様駆動開発を一度立ち止まって整理する 」にまとめています。
5 月に Preview となった Kiro Web は、cloud sandbox へ仕事を渡し、複数リポジトリの変更を Pull Request で受け取る働き方を持ち込みました。GitHub issue の label や comment から仕事を割り当てられるので、エージェントは開発者の手元ではなく、チームの workflow に参加します。6 月には Web で Specs と GitLab が使えるようになり、Automations が定期作業を cron で回し始めました。Kiro for iOS の Early Access も発表され、スマートフォンから session を開始し、進捗と diff を確認し、判断だけ返せるようになりました。
Kiro CLI 2.7.0 の /goal は、受入基準を満たすまで実装と自己検証を反復するコマンドです。「ゴールが決まるまで笛は鳴らない 」で書いた通り、完了の笛をエージェント自身に吹かせない仕組みで、冒頭の「完了しました !」問題への直接の回答です。ただし油断は禁物で、エージェントは失敗するテストを消したり assertion を弱めたりという「ゴールの偽装」もやってきます。CI/CD や隠しテストのような、実装者が触れない証拠を審判にする設計は「Kiro にハーネスを付ける」に書きました。
図: スマートフォンから cloud session の開始・監視・判断を行う Kiro for iOS (出典: Introducing Kiro for iOS）。
Agent Focus、 CLI V3 Early Access の登場
そして 6 月 25 日、IDE 1.0 に Agent Focus が Experimental として登場します。コードを中央に置く従来の IDE とは別に、複数の agent session を並列に走らせ、状態を一覧し、必要な session にだけ介入する chat-first の画面です。公式記事は、開発者の時間が「すべての行を直接編集する」ことから「agent を導く」ことへ移りつつあると説明しています。
CLI V3 Early Access では、IDE、CLI、Web が同じ agent harness を共有する方向も示されました。1 年前の Kiro は「AI を内蔵した IDE」でした。1 年後には、複数の仕事とエージェントを見渡す管制塔のような画面が現れています。人の仕事は、入力から判断へ移りました。
図: Agent session、会話、Spec の状態を一画面で俯瞰する Agent Focus (Experimental) (出典: Introducing Agent Focus）。
1 年目の到達点 : モデルは替わる。ハーネスは残る
1 周年当日の 2026 年 7 月 14 日、OpenAI GPT-5.6 Sol、Terra、Luna の Experimental support が発表されました。OpenAI のモデルが Kiro に載るのは初めてです。GPT と Claude の両方を選べる Kiro は、モデルの主役がコロコロ変わる今の世の中で、よい選択肢だと思っています。
ただ、選べるモデルが増えるだけでは、仕事は楽になりません。「このタスクにはどのモデルが合うのか」「品質を落とさず、どこまでコストを下げられるのか」という判断が、そのたびに増えるからです。評判のよいモデルを決め打ちしても、次のモデルが登場すれば、また同じ議論が始まります。必要なのは「最強のモデル」を覚えることではなく、モデルをいつでも同じ物差しで選び直せる仕組みです。
その物差しを作るためのサンプルが、aws-samples で公開されている sample-agent-cost-bench です。Kiro CLI の中でモデルを替える model-compare と、同じモデルを複数のエージェントで動かす cli-compare の 2 つの比較方法があり、品質、コスト、レイテンシを横並びにできます。同梱タスクだけでなく、自分の GitHub リポジトリとテストも指定できます。つまり、誰かが作ったランキングを眺める道具ではなく、自分たちの仕事を評価基準に変えるためのハーネスです。
私は model-compare を使い、Kiro CLI 上で Sonnet 5、Opus 4.8、Haiku 4.5 を比較しました。アプリケーションコードから Docker、Kubernetes、Terraform まで 6 タスクを選び、各モデルへ同じプロンプトと推論量を渡して 3 回ずつ、計 54 回実行しました。採点に使うのは、モデル自身が書いたテストではなく、モデルから見えない場所に置いた隠しテストです。Kiro CLI のクレジット消費量と実行時間も記録し、成功率だけでなく「1 回成功させるのに必要なコスト」まで比べました。結果は、Sonnet と Opus がともに 18/18 成功し、Opus のコストは Sonnet の約 1.7 倍。Haiku は 14/18 成功でしたが、失敗を含めても 1 成功あたりのコストは 3 モデルで最も低くなりました。
これは私の担当業務における条件での結果にすぎません。大事なのはランキングの暗記ではなく、自分のタスクと予算で測ることです。そしてこの計測をしていて確信したことがあります。モデルは入れ替わる頭脳であり、来年には順位が変わっているでしょう。長く残るのは、Specs、権限、評価基準、Skills といった、頭脳の外側の仕組み、つまりハーネスの方です。
図: 6 タスク × 3 モデル × 3 回、計 54 実行の品質・コスト比較
AI-DLC と仕様駆動開発の関係
私が Kiro と並行して AI 駆動開発ライフサイクル (AI-DLC) に取り組んでいるのも、同じ確信からです。ハーネスの発想をチーム全体へ広げると方法論になります。AI-DLC は「AI が実行し、人間が監視・意思決定する」ための上位方法論で、チームの仕事を Inception、Construction、Operation の 3 フェーズで捉えます。Kiro SDD はその中で、Unit of Work を requirements.md、design.md、tasks.md として実装へ落とすツール層です。つまり Kiro は AI-DLC そのものではなく、それを実行できるハーネスの一つです。
この関係は AI-DLC Workflows 2.0 の実装にも現れています。執筆時点で GA Preview の v2 は、Initialization、Ideation、Inception、Construction、Operation の 5 フェーズを 32 ステージへ分け、11 の専門エージェントと 9 スコープを組み合わせて、作業の種類に応じて実行する手順と深さを変えます。これらの定義は Markdown と YAML で 1 つの core/ に置かれ、ビルド時に Claude Code、Kiro IDE、Kiro CLI、Codex CLI という 4 つのハーネス向け配布物へ変換されます。ハーネス固有の違いは薄いアダプター層で吸収し、生成物のずれはドリフトチェックで検出します。方法論が 1 つ、実行環境が 4 つ。「モデルは替わる、ハーネスは残る」のさらに一段上で、「ハーネスも選べる、方法論は残る」という構造です。
図: チーム全体の方法論である AI-DLC と、機能単位の実装を支える Kiro SDD の関係（出典: 進化し続ける Kiro の仕様駆動開発を一度立ち止まって整理する）。
まとめ : 2 年目のボトルネックはどこへ
1 年かけて、ボトルネックは生成 → 意図 → 検証 → 分業 → 権限 → 指揮と移ってきました。Kiro が作ってきたのは、コードを増やすボタンではありません。意図を残し、専門性を渡し、任せる範囲を制御し、結果を証拠で確かめる仕組みです。1 周年ブログ のいう「エージェンティックエンジニアリング」の中身は、これだと私は読んでいます。
では 2 年目、ボトルネックはどこへ移るのか。私の予想は「完了を誰が認めるか」です。生成も検証もエージェント同士で回るようになったとき、最後まで残るのは、人と複数のエージェントで構成されたチームの設計と、その中で人が下す判断です。
人間の 1 歳児は、歩き始めると目が離せなくなります。Kiro は逆でした。1 歳になって、ようやく安心して目を離せるようになった。目を離しても仕事が進み、戻ってきたら Pull Request が待っている。そういう 2 年目にしていきましょう。
Kiro、お誕生日おめでとうございます ! 2 年目も、良いエージェンティックエンジニアリングを !
筆者プロフィール
稲田 大陸 (いなりく / @inada_riku)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
AWS Japan で働く筋トレが趣味のソリューションアーキテクト。製造業のお客様を支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、Kiro のブログなどを執筆しています。
