エージェントは設計判断を下しています。それを記録している人はいますか？
この記事のポイント
- AIコーディングツールの課題は、コードを生み出せないことではありません。半年後に「なぜこのコードはこの形なのか」を誰も説明できないことです。Kiroはこの課題に最も正面から取り組むツールです。
- 仕様駆動開発はオーバーヘッドを伴います。問うべきは「遅くなるかどうか」ではなく(間違いなく遅くなります)、「その代替案にチームが耐えられるかどうか」です。
- 失敗パターンは現実に存在します。中身の薄い仕様、EARS記法による見せかけの精度、形だけ整って実態を伴わないADR。レビューゲートを本物のゲートとして扱わない限り、このワークフローは機能しません。
AIコーディングツールはコード生成に長けてきました。本当に長けています。マルチエージェントフレームワーク、エージェント型アシスタント、自律型パイプライン。「アイデアを動くコードに変える」という課題に対して、選択肢は十分に揃っています。しかし、チームでソフトウェアを開発しているなら、印象的なデモから2週間ほど経った頃に必ず突き当たる壁を経験しているはずです。コードは動く、しかし、なぜその形になったのかを誰も説明できない。「なぜこのアプローチを採ったのか」と問われたときの正直な答えは、*「エージェントに任せたので、自分でもよく分からない」*というものです。
この光景を、私はいくつものチームで目にしてきました。問題はエージェントが悪い選択をしたことではありません。市場に出回るほぼすべてのAIコーディングツールがタスク実行に最適化されており、チーム開発を長期にわたって整合的に保つための成果物にほとんど投資されていないことが、本当の問題です。
2025年7月にプレビュー版として登場したAmazonのKiroは、私が見てきた中で最もこのギャップに正面から取り組むツールです。本稿は「Kiro対Cursor」の比較ではありません。個別タスクを高速にこなす力なら、Cursor、Claude Code、各種マルチエージェントフレームワークは強力です。本当に問うべきは、Kiroの仕様駆動開発モデルとSteeringシステムから構成できるアーキテクチャ決定記録(ADR)ワークフローが、他のツールにはないもの、すなわち「ソフトウェアがどう設計され、なぜそう設計されたのかを、チーム全員が共有・レビューできる記録」を提供してくれるのか、という点です。
マルチエージェントの現状：強力だが、構造的に不完全
現行世代のマルチエージェントフレームワーク(CrewAI、LangGraph、AutoGen、MetaGPT)は十分に成熟しています。DocuSignやPwCといった企業は、本番環境で大規模にマルチエージェントパイプラインを運用しています。Kiroの意義を語るには、まず代替手段がすでにコード生成において優秀であることを認める必要があります。
MetaGPTは直接比較に値します。LangGraphやCrewAIに比べると本番運用例は少ないものの、Kiroが提供すると謳う領域と最も重なるためです。一行の要件を渡すと、構造化された成果物(PRD、設計ドキュメント、インターフェース仕様、実装コード)を出力します。書面上は、Kiroの仕様駆動ワークフローと同じ範囲をカバーしています。
構造的な違いは、出力の品質ではありません。「誰が、いつ、どの判断を見るのか」にあります。
MetaGPTでは、エージェントが成果物を生成し、次のエージェントへ引き渡します。出力は包括的ですが、プロセスは不透明です。Architectエージェントが下した判断は、レビュー可能な記録として表に出てきません。実装が始まる前にチームが設計ドキュメントを読み、制約を指摘するための承認ゲートも存在しません。成果物は消費される出力であって、レビューに供される協働文書ではないのです。
同じ欠落は、マルチエージェントフレームワーク全般に共通しています。これらは優れた実行エンジンです。「ソフトウェアがなぜこのように作られたのか」というチームの共通理解を生み出すように設計されたものではありません。それは欠点ではなく、設計上の選択です。これらのフレームワークはタスクの完了に最適化されています。一方、Kiroが最適化しているのは時間を超えたチームの可読性です。
Kiroが実際に提供するもの
Kiroは、Amazon Bedrock上のClaude Sonnetを基盤としたVS Codeのフォークです。慣れ親しんだ環境であることには意味があります。新しいIDEを学ぶ必要も、コンテキストの切り替えも不要で、既存のOpen VSXプラグイン、テーマ、設定がそのまま移行できます。汎用IDEなので言語やフレームワークを問わず使えますが、仕様駆動ワークフローが最も自然に活きるのは、設計判断の重みが大きいバックエンド開発・フルスタック開発です。
差別化要因は、Kiroが強制するワークフローにあります。
仕様駆動開発：実行の前に成果物を
Kiroではすべての機能が**仕様(spec)**から始まります。コードを1行も書く前に、構造化されたMarkdownファイル群がリポジトリにコミットされます。3段階のプロセスは意図的に設計されています。
フェーズ1：要件(requirements.md)
最初のゲートは、多くのチームがまるごとスキップしてしまうものです。コードが存在する前に、書かれた要件をレビューし承認することです。あなたは自然言語で欲しいものを記述します。Kiroはコーディングを始めません。代わりに、EARS記法(Easy Approach to Requirements Syntax)を用いた正式な要件ドキュメントを作成します。これは、すべての要件を曖昧さのない、テスト可能な形式に落とし込むフォーマットです。
WHEN [trigger condition] THE SYSTEM SHALL [observable behavior]EARS記法は、暗黙のままになりがちな前提を表面化させます。Kiroが意図しない受け入れ基準を生成しても、コードレビューや本番環境ではなく、この段階で気づけます。要件は他の作業に進む前に、人間がレビューし承認します。
フェーズ2：技術設計(design.md)
ここが、本来アーキテクチャに関する本格的な議論が起こるべきフェーズです。多くのAIツールは、すでにコードを書き始めてしまっている段階です。承認された要件をもとに、Kiroは既存のコードベースを分析し、設計ドキュメントを生成します。コンポーネント階層、データフロー図、データベーススキーマ、API契約、TypeScriptインターフェースなど、実際のプロジェクトアーキテクチャを反映した設計です。
これが、本番コードが1行書かれる前にチームがレビューするドキュメントです。アーキテクトはスキーマに異議を唱えられます。シニアエンジニアはスケーリングの懸念を指摘できます。並行して別の機能を担当するエンジニアは、新しい設計が自分の作業との統合上の衝突を生まないか確認できます。これらすべてが、プルリクエスト上の書面成果物に対して行われます。
フェーズ3：実装タスク(tasks.md)
ここで初めて実装が始まります。Kiroは要件にひも付いた依存関係順のタスクリストを生成します。各タスクには関連するユニットテストと統合テスト、必要に応じてローディング状態やアクセシビリティへの配慮も含まれます。タスクは各ステップで明示的な人間の承認を得ながら一つずつ実行することも、オートパイロットモードで自律的に実行することもできます。コード差分とエージェントの実行履歴は、各段階で確認できます。
仕様ファイルは、プロジェクトリポジトリ内の.kiro/specs/<feature-name>/に置かれます。プルリクエストでコミット・バージョン管理・レビュー可能であり、git履歴からたどれます。チーム全員が、それが存在した瞬間から見ることができます。
この可視性は、シニアエンジニアの時間の使い方を変えます。「何が決まり、なぜそうなったのか」を発掘する考古学作業に巻き込まれる代わりに、書かれた設計をレビューし、必要なところに異議を唱え、作業開始前に承認します。彼らの判断力が、最も効果を発揮する場所に投じられるのです。
マルチエージェントツールが埋められないギャップ：判断の記録
ここが、マルチエージェントフレームワークとの比較で最も鋭くなる部分であり、ツール選択が長期的な影響を持つ部分です。短いデモでは見えてこない領域です。
Kiroの仕様ファイルは、システムが何をすべきか、そしてそれをどう設計したかを記録します。これだけでも、ほとんどのAI支援ワークフローが残すものを上回っています。しかし、design.mdはPostgreSQLが選ばれたことを伝え、スキーマを記述します。一方で、DynamoDBが評価されたものの、アクセスパターンが複数カラムでのフィルタリングを必要とし、DynamoDBのクエリモデルでは高コストな非正規化と書き込みパスの重複なしには対応できなかったために却下された、という経緯までは伝えてくれません。イベントソーシングが検討されたものの、チームにイベントストアの運用経験がなく、レイテンシ予算が結果整合性に対応できなかったために見送られた、という経緯も書かれません。
こうした文脈、つまり「何が評価され、なぜ却下され、どのトレードオフが受け入れられたか」を記録するのが**アーキテクチャ決定記録(ADR)**です。この概念はMichael Nygardが2011年に提唱したもので、以来、持続可能なソフトウェアアーキテクチャの定番手法となりました。詳しく知りたい方は、ADRのGitHubオーガニゼーションがフォーマットとそのバリエーションについて良い概観を提供しています。
ADRは確立された実践です。GOV.UK Digital Serviceは、AWS移行の際に39件のADRを公開しており、ホスティングプラットフォームの選定からデータベース統合、DNSアーキテクチャまで、多岐にわたる判断をカバーしています。一つひとつは短いMarkdownファイルで、Status、Context、Decision、Consequencesという構成です。コレクション全体が移行プロジェクト全体の判断ログとなっており、それが記述するインフラと並んでバージョン管理されています。
ほとんどのチームがADRを維持できない理由は**摩擦(friction)**です。作成は出荷のプレッシャーと競合し、規律は1〜2スプリントで崩れ、実際に記録されるのは設計時に前もって下された判断ばかりです。実装の途中で「制約が想定と違っていた」と判明したときに発生する、同じくらい重要な判断は記録されません。
Kiroはこの摩擦を、二つの仕組みで取り除きます。
Steeringによる自動ADR生成
KiroのSteeringシステムでは、チーム全体のすべてのエージェント対話に適用される永続的な指示を、.kiro/steering/にコミットできます。1つのsteeringファイルで、ADR生成を自動化できます。
When generating or updating design.md for any spec, also create or updatea decisions/ subdirectory within the spec folder. For each significantarchitectural choice — technology selection, data model, integrationpattern, security mechanism — create an ADR file following the namingconvention ADR-NNN-short-title.md.
Each ADR must include: Status, Context, Decision, and Consequences(positive, negative, risks). Record options considered but not chosenand the reasons they were rejected.一度コミットすれば、この指示はチーム全体に適用されます。誰かが意識的に作成しなくても、ADRが生成されるようになります。
# ADR-001: Use PostgreSQL over DynamoDB for review storage
## StatusAccepted
## ContextThe review system requires complex multi-column filtering (rating, date, product).DynamoDB's query model requires denormalized duplicates per access pattern,increasing storage and write complexity by an estimated 3-4x.The team has existing PostgreSQL operational experience and monitoring tooling.DynamoDB was the initial default assumption given existing AWS infrastructure.
## DecisionUse PostgreSQL with a normalized schema. Index the columns used in the fourmost common filter combinations. Accept the horizontal scaling trade-off.
## Consequences- Positive: Query logic is significantly simpler; existing tooling applies- Negative: Horizontal scaling requires more coordination than DynamoDB- Risk: Revisit if read throughput exceeds 20k RPS at peak; document thresholdHookによる、実装中の判断の捕捉
設計時に下される判断は、捕捉が容易な部類です。本当に危険なのは実装中に発生するものです。あるライブラリに破壊的なエッジケースが見つかった、性能測定の結果データアクセスパターンを変更することになった、といったものです。これらは会話や小さなコード変更で解決され、どこにも記録されません。
design.mdの変更に対するKiro Hookが、これを処理します。設計ドキュメントが(エンジニアによって、あるいはタスク実行中のKiroによって)変更されると、Hookがエージェントを起動し、その変更が新たなアーキテクチャ判断に該当するかを評価します。該当する場合は、チームがレビューするためのADRをドラフトします。仕様と判断記録は、初期設計の時点だけでなく、実装を通じて同期し続けるのです。
マルチエージェントパイプラインにおけるADR：補完的なアプローチ
ADRの自動化はKiroに限った話ではありません。既存のCrewAIやLangGraphのパイプラインに、ADR Writerエージェントを追加することもできます。ただし、生成されたADRがレビュー可能な形でチームに届くかどうかは、パイプラインの出力を開発ワークフローにどう組み込んでいるかに依存します。Kiroは、コードが書かれる前にチームがそれを見て、レビューし、異議を唱えるワークフローにADRを組み込んでいます。
すでにマルチエージェントパイプラインを運用しているチームにとって、両者は自然に共存します。Kiroが設計、仕様、判断記録を担当し、既存のパイプラインは仕様で確立された制約の範囲内で限定的な実行タスクを担当します。仕様は、チームが監督する設計フェーズと、エージェントがより自律的に動作する実行フェーズの間の契約となります。
モデルが破綻するところ
失敗のパターンを語らないのは不誠実でしょう。これらは、数スプリント経たないと見えてきません。
仕様の品質はプロンプトの品質に縛られる
Kiroの要件・設計ドキュメントは、最初に与える記述以上のものにはなりません。曖昧なプロンプトは曖昧な仕様を生みます。問題は、それがEARS記法と受け入れ基準できれいに整形されると、厳密さの体裁をまとった曖昧な仕様になってしまうことです。これは仕様がない状態より悪い場合があります。チームがレビューし、構造を見て、内容まで確かだと思い込んでしまうからです。
対処は技術ではなく文化にあります。仕様レビューを形式的な承認ではなく、本物の設計レビューとして扱うことです。要件が一般論に感じられたり、設計が自分たちの固有の制約を扱っていなかったりするなら、承認前に異議を唱えてください。承認ゲートの存在意義は、それが形式ではなくゲートであることにあります。
EARS記法は見せかけの精度を生み出しうる
EARSは、個別の要件における曖昧さの排除に長けています。ただし、網羅性は保証しません。20の完璧に明確な要件を持っていても、本当に難しい問題を全部見落としている、ということが起こりえます。Kiroが技術的には正しいが運用上は無意味なEARS要件を生成するのを、何度も見てきました。ハッピーパスを詳細に書きながら、本番でシステムが機能するかどうかを実際に左右する失敗パターンを無視しているのです。
対処法は、requirements.mdをレビューする際に、各要件が形式として整っているかだけでなく、要件の集合として、システムにとって重要な失敗ケース、エッジケース、運用上の関心事(モニタリング、アラート、ロールバック)をカバーしているかを確認することです。カバーできていなければ、承認前に追加してください。
自動生成されたADRは中身が薄くなる可能性がある
「重要なアーキテクチャ判断についてADRを生成する」と書かれたsteeringファイルは、確かにADRを生成します。しかし、それが有用な推論を含むかどうかは、Kiroが制約についてどれだけ文脈を持っているかに依存します。「リレーショナルクエリをサポートしているのでPostgreSQLを選んだ」と書かれたADRは、技術的には正しく、完全に無価値です。シニアエンジニアならすでに知っていることだからです。価値があるのは、却下された代替案と、却下された具体的な理由です。
steeringファイルは、何を記録してほしいかについて明示的に書くようチューニングしましょう。「重要な選択を記録する」ではなく、「各技術選定について、評価された代替案を少なくとも2つ、それぞれが却下された具体的な技術的・運用的理由、そして判断を見直すべき条件を記録する」と書いてみてください。指示が具体的であるほど、出力は有用になります。
仕様のドリフトはデフォルトでは静かに進行する
Kiroは、実装が設計から逸脱したことを自動的には検知しません。仕様は設計時点での意図のスナップショットです。エンジニア(あるいはオートパイロットモードのエージェント)が設計と矛盾する変更(別のデータベースエンジン、追加のAPIエンドポイント、変更されたデータモデル)を加えても、仕様ファイルが自動で更新されることはありません。
これは前述のとおりHookで解決可能ですが、デフォルトの挙動ではありません。Kiroを導入するなら、ドリフト検知のHookは問題が表面化してから足すものではなく、初期設定の一部に組み込むべきです。
ガバナンスは設計の境界で止まる
2025年12月、Kiroのエージェントが本番のAWS環境を削除し、中国リージョンでAWS Cost Explorerが13時間にわたり停止する事故が発生しました(The Register, 2026年2月)。Amazonは、エンジニアのロールが想定より広い権限を持っていたことを原因としました。独立した報道では、Kiroが部分的な修正ではなく環境を削除して再作成することを自律的に決めたと描かれており、Amazonはこの点について異議を唱えています。
どちらの説明であっても、教訓は同じです。仕様がレビューされ、設計が承認され、ADRが文書化されていても、承認された設計と本番デプロイの間を誰もレビューしなかった結果として、壊滅的な失敗が起こりうるということです。
Kiroのガバナンスモデルは、設計フェーズを徹底的にカバーします。カバーしていないのは、実行の境界です。エージェントが実際の権限を持って実際のインフラに作用する瞬間です。オートパイロットモードは便利ですが、他のCI/CDパイプラインと同じ規律が必要です。デプロイのレビュー、限定された権限、本番に変更が到達する前のヒューマンインザループです。仕様ワークフローは、ガバナンスが処理されていると思い込ませやすい構造を持ちます。Kiroのワークフローが終わる地点を超えて、その規律をチームが延長しない限り、ガバナンスは処理されません。
チームに何が変わるか
設計が、エージェントの非公開セッションではなく、公の場で起こる
マルチエージェントパイプラインでは、設計判断はパイプラインの内部で下されます。チームメンバーが目にする頃には、すでに実装されているか、プルリクエストに含まれるとは限らない出力ファイルにコミットされています。Kiroでは、設計ドキュメントが、実装の前にリポジトリへ最初にコミットされる成果物です。チームは、設計が作成される過程を見てレビューします。完成後ではありません。
これはコードレビューを直接変えます。仕様なしのコードレビューは、実装から意図を推測する作業であり、遅く、内容よりスタイルへのコメントに偏りがちです。仕様に対するコードレビューでは、実装が記述された要件を満たしているか、選択が文書化された理由付けと整合しているかを確認します。レビューはより速く、より本質的になります。
並行作業の衝突が早期に表面化する
マルチエージェントパイプラインは通常、単一のタスクコンテキストで動作します。複数のエンジニアが並行して開発するチームで、それぞれが自分のエージェントセッションを使ったり自分のパイプラインを動かしたりしている場合、二つの機能が矛盾するアーキテクチャ前提を置いていることを検知する仕組みがありません。Kiroの仕様は実装前にコミットされるため、衝突するコードが書かれる前という適切なタイミングで、こうした衝突を可視化する共通の参照点を提供します。
知識が人事異動を超えて生き残る
ノリで(vibe coding)開発したり、構造のないエージェントパイプラインを使ったりしてきたチームから誰かが去ると、その人の文脈も一緒に去ります。私はこれを何度も見てきたので、その後の展開は分かります。3か月後、誰かが、誰も完全には理解していないサービスをリバースエンジニアリングしているのです。Kiroモデルにおけるspecとは、人ではなくリポジトリに紐づくものです。すべての重要な判断の背景は、3か月後に加わるエンジニアにも、3年後にシステムを引き継ぐチームにも、そこに残されています。
正直な問いかけ
マルチエージェントパイプラインを運用しているチームへの正直な問いかけはこうです。あなたのパイプラインはコードを生成します。それがなぜそのように設計されたのか、あなたは知っていますか？チームは知っていますか？6か月後にも知っているでしょうか？どれかが不確かなら、あなたは複利で増えていく知識的負債を蓄積している最中です。
その負債には、予測可能な軌跡があります。速度が落ち、オンボーディングが遅くなり、最終的に誰かが書き直しを提案します。誰も理解していないシステムを修正するほうが、ゼロから始めるより危険に感じられるからです。
Kiroは、限定的なタスク実行に使うマルチエージェントツールを置き換えるものではありません。それは構造のレイヤー(仕様、ADR、Hook、実装前にコミットされチームに見える成果物)を提供し、AIが生成した出力を、チームが本当の意味で所有できるソフトウェアへと変えるものです。
オーバーヘッドの問題
仕様ワークフローは、実装前に計画時間を加えます。短命のスクリプトや限定的な自動化タスクには、そのオーバーヘッドは見合いません。Kiroの構造化アプローチが単純な問題を過剰に仕様化し、低リスクの変更には不要に感じる摩擦を承認ゲートが加える、と感じるチームもいます。
Martin Fowlerのチームは仕様駆動開発ツール(Kiroを含む)を検討し、強い指針を持つ単一ワークフローのアプローチは「現実のコーディング問題の大多数には適していない可能性が高い」と結論づけました。彼らの指摘には一理あります。日々のエンジニアリング作業の大部分は、既存システムの修正、バグ修正、漸進的な変更であり、完全な仕様サイクルが価値を上回る摩擦を生みかねない領域です。仕様駆動開発の意義は、アーキテクチャ判断が下され、その判断を誤ったときのコストが大きい仕事のサブセットにかかっています。そのサブセットはこの記事が示唆するより小さいものですが、最も影響の大きいミスが起こる場所でもあります。
Kiroは同じIDE内で仕様駆動モードとvibe codingモードの両方を提供しており、両者はうまく共存します。探索や使い捨ての作業にはvibe coding、保守される対象には仕様、という具合です。難しい問いは、チームがその判断を正確に適用できているかです。私の経験では、すべてに高速パスを使い、その機能を実際より単純だと自分に言い聞かせる誘惑が強くあります。コードベースに溜まる知識的負債の多くは、繰り返し下されたその判断の蓄積です。
実用的な目安として、次のいずれかが当てはまるなら仕様モードを使ってください。機能がデータモデルに触れる、新しい外部統合を導入する、セキュリティ境界をまたぐ、複数のエンジニアが関与する。それ以外はvibe codingで構いません。誤ったアーキテクチャ判断のコストは、その後のすべてのスプリントで複利的に増えていきますが、使い捨てスクリプトを過剰に仕様化するコストは1時間程度の自分の時間です。
初めて仕様モードを導入するチームには、段階的なアプローチが抵抗を減らします。上記のヒューリスティックの少なくとも2つを満たす新機能を1つ選び、仕様の価値を実感できる程度の複雑さがありつつ、最初の経験が圧倒的に重くならない範囲のものから始めましょう。仕様レビューを本物の設計ミーティングとして実施し、要件ドキュメントを単に読むのではなく、承認前に異議を唱える担当を割り当ててください。最初の機能が出荷されたあと、仕様によって、後で表面化していたはずの何かを捕まえられたかどうかを短く振り返ります。「設計レビューでスキーマの問題を捕まえられた、本番ではなく」という、その一つのデータポイントは、懐疑的なエンジニアリングチームにとって、どんなプロセス論よりも説得力があります。
まとめ
現行世代のAI開発ツールは、コード生成という問題をおおむね解決しました。3年前なら不可能に思えた速度で、自然言語の要件を動く実装に変えてくれます。
しかし、ほとんどのツールが解決していないのは、チームの問題です。エンジニアの集団がAIの支援を受けながら、誰も完全には所有していない共有出力ではなく、共有された理解を生み出す形でソフトウェアを共同で作るには、どうすればよいか？*「なぜこのように設計されたのか」*という問いに、設計が誰にも見られていないエージェントセッションの中で起こったときに、どう答えればよいか？
Kiroの答えは構造的です。コードが存在する前に、ワークフローの標準的な一部として、これらの問いに答えられるようにする成果物を生成することです。仕様ファイルは、設計意図に対するチームの可視性を与えます。設定したsteeringファイルから生成され、Hookで最新に保たれるADRは、判断の理由付けに対するチームの可視性を与えます。どちらもリポジトリに置かれ、他のコード成果物と同じようにプルリクエストを通って流れます。
すでにマルチエージェントフレームワークを実行タスクに使っているチームにとって、Kiroは置き換えではありません。これらのツールが提供しないレイヤー、つまり判断を捕捉し、AIが生成したコードをエンジニアリングチームが保守できるソフトウェアに変えるための、レビュー可能でチームに見えるワークフローです。
実行の問題はおおむね解決しました。チームの問題はそうではありません。それこそが取り組む価値のある問題であり、ツール業界の他のプレイヤーがまだ賭けていない問題なのです。