AWS製IDEであるKiroの一般提供が始まり、それに伴いAmazon Q Developer CLI（以下Q CLI）がKiro-CLIとして統合されました。
本記事では、Q CLIからKiro CLIへの移行によって追加された主要機能を紹介します。その上で、これらの機能とAWSが提唱するAI-DLC（AI駆動開発ライフサイクル）との関連性、およびAWSの戦略的方向性について考察します。
TL;DR
Q CLIからKiro CLIへの移行により、Knowledge（コンテキスト永続化）、Todo Lists（セッション跨ぎタスク管理）、Tangent Mode（会話分岐）など、ファイルベースでのコンテキスト管理を重視した機能群が追加されました。これらは即興的な開発（Vibe Coding）とは対極にある構造化アプローチで、AWSが提唱するAI-DLC（AI駆動開発ライフサイクル）の「開始→構築→運用」3フェーズにわたる永続的なコンテキスト管理と方向性が一致しています。AWSは単なるコーディング支援を超え、開発ライフサイクル全体を通じたAI駆動プラットフォームへの進化を志向していると考えられます。
KiroとSpec Driven Developmentの台頭
2025年7月にプレビュー版がリリースされた「Kiro」はSpec Driven Development（仕様駆動開発、以下SDD）を浸透させました。
Vibe Codingの話題に飽き飽きし、AIを使った開発にある種の限界を感じ始めていたエンジニア達に業務における現実的な大規模開発の可能性を見せました。
しかし、小回りが利き、素のシステムプロンプトと組み込みのツールが優れているClaude Codeが人気の先頭を走っています。
結果としてKiroのプロンプトを抜き出したものをClaude Codeのカスタムスラッシュコマンドに放り込むテクニックが生まれ、各Agentで利用可能なcc-ssdやgithub製のspec-kit等のツールも誕生しました。
2025年11月、Amazon Q DeveloperのCLIツールであったAmazon Q Developer CLIがKiro CLIに名称変更され、Kiroブランドへの統合が完了しました。これにより、IDEとCLIのコンテキストをまとめて管理できるようになりました。
Q CLIからKiro CLIへの移行
q update
で移行が完了する。ツール名の変化によってコマンドも変化するが、従来のq chatでも起動する。
$ kiro-cli
# エイリアスが登録されるようで q や q chat でも起動する
Q CLIの起動画面
Kiro CLIの起動画面
起動画面も変更されます。
Kiro CLIで追加された主要機能
ここからは具体の話に切り替え、Kiro CLIとしてリリースされたことで追加された機能と最近のアップデートで追加されたであろう機能を見ていきます。
ベータ版機能も含めて紹介しますが、当然ベータ版機能ですので、正式採用されるかは不透明で、急に削除されてもおかしくないことには留意してください。
主要機能の概要
まず、追加された機能の全体像を把握するため、カテゴリ別に整理した概要表を示します：
コンテキスト管理系
| 機能 | ステータス | 主な用途 |
|---|---|---|
| Knowledge | ベータ | セッション間でのコンテキスト情報の保持 |
| /context show | 正式 | トークン量の比率表示による直感的な管理 |
| Context Usage Indicator | ベータ | プロンプトでのコンテキスト使用率の色分け表示 |
タスク・ワークフロー管理系
| 機能 | ステータス | 主な用途 |
|---|---|---|
| Todo Lists | ベータ | サブタスクへの分解と進捗追跡、セッション跨ぎの継続 |
| Checkpoints | ベータ | ファイル変更のスナップショット化と復元 |
| Tangent Mode | ベータ | メイン会話を乱さない脇道の探索 |
実装支援系
| 機能 | ステータス | 主な用途 |
|---|---|---|
| Thinking | ベータ | 複雑な問題に対するAIの思考プロセス表示 |
| Delegate | ベータ | 背景タスクでの並列チャットセッション実行 |
| Auto Agent | 正式 | タスクに応じた最適モデルの自動選択 |
マルチモーダル
| 機能 | ステータス | 主な用途 |
|---|---|---|
| 画像の読み込み | 正式 | クリップボードやドラッグ&ドロップからの画像取得 |
ベータ版機能のON/OFFの仕方
/experimentコマンドでon/offを切り替えられます
詳細はドキュメントで確認してください。
コンテキスト管理系
Knowledge（ベータ）
セッション間でのコンテキスト永続化を実現する機能です。
/knowledge addでファイルやディレクトリをインデックスに登録し、/knowledge showで保存済みエントリを確認できます。インデックスタイプは、高速なキーワード完全一致の「Fast（語彙ベース）」と、文脈認識・自然言語クエリ対応の「Best（セマンティック）」から選択可能です。各エージェントは独立した知識ベース（~/.kiro/knowledge_bases/）を持ち、テキスト、Markdown、JSON、各種プログラミング言語など幅広いファイルをサポートします。
Claude CodeやCodex CLIには対応する機能がなく、Kiro CLI独自の実装です。Cursor等で見られるようなコードベースのインデックス化を行います。
この機能も、Todo ListsやTangent Modeと同様に、コンテキストウィンドウの制約を超えるためのアプローチです。重要な情報をファイルベースで永続化することで、セマンティック検索により過去のセッションで得た知識を効率的に再利用できます。
Kiro IDEでのSSDにおけるマークダウンファイルのタスクリスト管理と同じく、ファイルベースのコンテキスト管理を徹底することで、長期的なプロジェクト開発を支援する意図が伺えます。
/context showの改善
コンテキストウィンドウにおける起動時に読み込んでいるファイルごとのトークン量が比率で表現されるようになりました。
Q CLIでの/context show
Kiro CLIでの/context show
コンテキストウィンドウの調整においてはトークン量よりもパーセンテージで表現されたほうが遥かに直感的なので大変ありがたい改善です。
Context Usage Indicator（ベータ）
プロンプトにコンテキスト使用率を色分けで表示する機能です。緑（50%未満）、黄（50-89%）、赤（90-100%）で視覚的にコンテキストウィンドウの使用状況を把握できます。
コンテキストウィンドウが逼迫してきたタイミングを視覚的に把握できるため、自動コンパクション（コンテキストの自動圧縮）が発動する前に、能動的にコンテキストを整理できます。トークン量よりもパーセンテージ表示の方が直感的に管理しやすいという利点があります。
Claude Codeでは/contextコマンドでトークン消費量と残りコンテキストウィンドウのパーセンテージを表示できますが、常時表示される機能ではありません。サードパーティツールのccusageを使うことで、Kiro CLIと同様に色分け表示（緑<50%、黄50-80%、赤>80%）が可能になります。ステータスバーへの統合は要望として上がっているものの未実装です。Kiro CLIではこの機能がネイティブに組み込まれており、コンテキストウィンドウの管理がより直感的に行えます。
前述の /context showの改善 と同様にコンテキストウィンドウの調整はユーザーの需要が高いのでしょう。
タスク・ワークフロー管理系
Todo Lists（ベータ）
Q CLIのv1.15ぐらいからあった模様。
Claude CodeのTodoツールやCodexなどでタスクを内部的にサブタスクに分解する能力をKiro風に実装したものです。
Claude Codeと同様にlocalのファイル.kiro/cli-todo-lists/にjsonファイルとして保存されます。
Claude Codeとの違いはセッションをクリアした後も/todos resumeでTodo Listを引き継げることにあります。ここはKiro IDEでのSSDにおいてマークダウンファイルのタスクリストをクリアさせる手法と同様にファイルベースで管理することでコンテキストの限界を超える意図が見えます。
Todo Listを使ったタスク管理
Tangent Mode（ベータ）
メイン会話を乱さずに脇道の話題を探索できるチェックポイント機能です。
/tangentコマンドまたはCtrl+Tで起動します。
現在のトピックに関する疑問の解消、概念理解の確認、代替アプローチの一時的な探索、Kiro CLIヘルプの取得などに適しています。通常の/tangentで終了すると分岐した会話は破棄されますが、/tangent tailで終了すると最後のQ&Aペアのみをメイン会話に統合できます。
Claude CodeやCodex CLIには対応する機能がなく、Kiro CLI独自の実装です。メインの開発タスクを進めている途中で、ちょっとした調査や検証を行いたい場合に、会話のコンテキストを分岐させることができます。「ちょっと調べ物したいな〜 ターミナルのタブ開いて、claudeって打って…」というちょっとした面倒を回避できます。
Tangent Modeのイメージ図
Checkpoints（ベータ）
ファイル変更をGitのようにスナップショット化し、復元や比較ができる機能です。
以下のスクリーンショットではinitを行っていますが、Git管理されたリポジトリであればチャットセッションを開始すると自動的に有効になります。
checkpointsを初期化してcommitを確認してみる
このcommit履歴からコマンドで任意の時点に戻ることが出来る
/checkpoint listでターン単位のスナップショット一覧を表示、/checkpoint diff <tag1> [tag2|HEAD]でバージョン間の比較、/checkpoint restore [<tag>] [--hard]で以前の状態への復元が可能です。会話のターンごとに自動的にチェックポイントが作成されるため、開発中の任意の時点に戻ることができます。
Claude Codeでは2025年9月のv2.0で同様の機能が導入されています。Claude Codeでは各編集前に自動的にコード状態を保存され、Escを2回押すか/rewindコマンドで以前の状態に戻れます。ただしClaude Codeのチェックポイントは、Claudeの編集にのみ適用され、ユーザーの手動編集やbashコマンドの変更には適用されません。
Kiro CLIでは/checkpoint list、/checkpoint diff、/checkpoint restoreなどのGitライクなサブコマンドが用意されており、セッション内での柔軟なバージョン管理が可能です。
正直なところClaude Codeのほうが直感的で使いやすく思いますが、Checkpoints機能のほうが管理は丁寧ですね。
実装支援系
Thinking（ベータ）
複雑な問題に対してAIがどのように推論しているかを可視化する機能です。
複雑なマルチステップ問題の解決、トレードオフの分析、段階的な実装計画、アーキテクチャの決定などで自動的に推論プロセスが表示されます。最近はCoding AgentだけでなくWebのAIツールでも一般的になってきた表現です。
Claude CodeのExtended Thinking Modeは"ultrathink"コマンドで思考バジェットを増やせる仕組みですが、Kiro CLIでは設定でON/OFFのみの制御となっており、指示の内容によって自動的に使い分けを行う仕組みになっているようです。
Thinking機能により、AIの推論プロセスが可視化される
Auto Agent
タスクに合わせてAgentが自動でClaudeのモデルを使い分けることでクレジット使用量が約23%削減されるそうです。
これは継続的に使ってみないと評価は難しいので、公式の説明文の引用に留めます。
Kiro CLI には、Kiro IDE を強化するのと同じインテリジェントな Auto エージェントが含まれています。Auto は各タスクに最適なモデルを動的に選択し、速度、コスト、品質のバランスを取ります。その結果、優れた効率性—Autoモードで使用するとXクレジットかかるタスクが、手動で Sonnet 4 または Sonnet 4.5 を選択すると 1.3X クレジットかかるでしょう。どのモデルを使用するか考えることなく、より良い価格でより良い結果を得るために Auto に任せましょう。
(Kiro CLI の紹介：Kiro エージェントをあなたのターミナルへ|Amazon Web Services ブログ)
Delegate（ベータ）
背景タスクで並列チャットセッションを実行できる機能です。
長時間かかる操作（テスト実行、ビルド、コード分析）、ユーザー入力が不要な独立したタスク、複数タスクの同時実行、バックグラウンドモニタリングタスクなどに適しています。自然言語でタスクを記述すると、Kiroが必要なエージェント/ツールを判断し、承認後にバックグラウンドで実行されます。メイン作業を続けながら自然言語で進捗確認が可能で、完了時に結果を取得できます。
Claude Codeではセッションで進めているタスクのサブタスクをsub agentに並列実装させることは可能です。
Kiro CLIでのDelegate機能がどこまでCodex Cloudのような本格的な並列実行基盤を目指しているのかは今後の実装次第ですが、複数タスクを効率的に処理する点では共通しています。
実装を進めながら、完了した実装についてのドキュメントを書かせたり、依存関係がない小さなタスクを進めさせておくには便利かもしれません。
Delegate使用例
マルチモーダル
画像の読み込み
Claude Codeでは対応していたクリップボードからの画像読み込みに対応しました。
これにより、ブラウザで開いているダッシュボードやエラー画面を簡単に渡すことが出来るようになりました。
/paste
でクリップボードから画像が取得され、Claude APIで認識されます。
ドラッグ・アンド・ドロップでも読み込ませることができますが、ctrl + Vショートカットにも対応が期待されます。
実際の挙動
Kiro CLIで認識した結果
クリップボードから画像を読み込み、Kiroの一般公開プレスリリースのスクリーンショットを正確に認識できることを確認しました。日本語テキストも問題なく読み取れます。
詳細はKiro が一般提供開始: IDE とターミナルでチームと共に開発|Amazon Web Services ブログを参照してください。
主要機能の他ツールとの比較
ここまで紹介してきた機能について、Claude Codeなど他の主要なAI開発ツールとの違いを整理します。
Claude Codeとの機能比較
| 機能 | Kiro CLI | Claude Code | 主な違い |
|---|---|---|---|
| Todo Lists | ○ セッション跨ぎ可能 /todos resumeで継続 |
○ セッション内のみ |
Kiroはファイルベース管理でセッション間継続が可能 |
| Thinking | ○ 自動判断 設定でON/OFF |
○ultrathinkコマンド思考バジェット調整可 |
Kiroは自動、Claude Codeは明示的制御 |
| Tangent Mode | ○/tangentまたはCtrl+Tメイン会話と分岐可能 |
× | Kiro独自機能 |
| Checkpoints | ○ Gitライクなコマンド /checkpoint list/diff/restore
|
○Esc2回または/rewindClaudeの編集のみ対象 |
KiroはGitライク、Claude CodeはClaude編集のみ |
| Delegate | ○ バックグラウンドタスク 並列実行 |
△ Sub agent 並列実装可能 |
Kiroは独立セッション、Claude Codeはサブタスク |
| Knowledge | ○ セマンティック/語彙検索 ~/.kiro/knowledge_bases/
|
◯ CLAUDE.md |
Kiro独自機能 Cursorのコードベースインデックスに類似 |
| Context管理 | ○ パーセンテージ表示 色分けインジケータ |
△/contextコマンドサードパーティ ccusageで色分け可 |
Kiroはネイティブ実装 |
| 画像読み込み | ○/pasteコマンドドラッグ&ドロップ |
○ クリップボード Ctrl+V/Cmd+V対応 |
実装方法の違い |
Claude Codeとの主な違い
上記の比較から、Kiro CLIとClaude Codeの違いとして以下が見えてきます：
- ファイルベースの永続化: Todo Lists、Knowledge、Checkpointsなど、セッション間でのコンテキスト継続を重視
- Gitライクな操作性: Checkpointsのコマンド体系など、開発者に馴染みのある操作方法
- 独自の会話管理: Tangent Modeによる会話の分岐と統合
- 自動最適化: Thinking機能やAuto Agentによる自動判断
一方、Claude Codeは：
- 明示的な制御: ultrathinkなど、ユーザーが細かく制御できる仕組み
-
シンプルな操作: 直感的なキーボードショートカット（
Esc2回など） - 柔軟なカスタマイズ: スラッシュコマンドのカスタマイズが容易
どちらを選ぶかは、チームの開発スタイルやプロジェクトの性質に依存します。長期プロジェクトでコンテキストの永続化を重視するならKiro CLI、軽快な操作性と細かい制御を重視するならClaude Codeが適しているでしょう。
AI-DLCとKiro CLIの関係
ここまで紹介してきたKiro CLIの機能群を見ていると、AWSが提唱する新しいソフトウェア開発方法論「AI駆動開発ライフサイクル（AI-DLC）」との親和性が高いことがわかります。これらの機能は、AI-DLCの方向性と一致する設計になっていると考えられます。
AI-DLCとは
AI-DLCは、従来のソフトウェア開発ライフサイクルをAI中心のアプローチへ再構築する方法論です。人間主導の長期的プロセスから、AIを中核に据えた革新的な開発手法への転換を目指しています。
単にAIをアシスタントとして後付けするのではなく、AIを開発プロセスの中心的な協力者およびチームメイトとして位置づけます。
AI-DLCには2つの重要な要素があります：
- AIが実行し人間が監視する：AIが体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。
- ダイナミックなチームコラボレーション：AIがルーティンタスクを処理する一方で、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定のために協力します。
AI-DLCの3つのフェーズ
AI-DLCでのソフトウェア開発は、以下の3つのシンプルなフェーズで行われます：
- 開始（Inception）フェーズ：AIがビジネス意図を詳細な要件、ストーリー、ユニットに変換します。「モブエラボレーション」を通じて行われ、チーム全体がAIの質問や提案を積極的に検証します。
- 構築（Construction）フェーズ：開始フェーズで検証されたコンテキストを使用します。AIが論理アーキテクチャ、ドメインモデル、コードによる実装、テストを「モブコンストラクション」を通じて提案し、チームが技術的決定とアーキテクチャの選択についてリアルタイムで明確化していきます。
- 運用（Operation）フェーズ：AIが前のフェーズから蓄積されたコンテキストを適用します。チームの監督のもとでInfrastructure as Codeとデプロイメントを管理します。
重要なのは、AIがプロジェクトリポジトリに計画、要件、設計成果物を保存することです。すべてのフェーズにわたって永続的なコンテキストを保存・維持することで、複数のセッションにわたって作業をシームレスに継続できます。
SDDとAI-DLCの違いについて実感のこもるスライドがありましたので、是非読んでみてください。
Kiro CLIとAI-DLCの親和性
Kiroで追加された機能群を整理すると、AI-DLCの各フェーズとの対応関係が見えてきます：
| AI-DLCフェーズ | 主な活動 | Kiroの対応機能 |
|---|---|---|
| 開始 | 要件の詳細化、ストーリー分解 | Spec Driven Development、Todo Lists |
| 構築 | アーキテクチャ設計、実装、テスト | Auto Agent、Delegate、Checkpoints、Thinking |
| 運用 | インフラ管理、デプロイメント | AWSエコシステム統合（今後の方向性） |
| 全フェーズ共通 | コンテキストの永続化 | Knowledge、ファイルベースの管理（.kiro/ディレクトリ） |
特に、以下の機能はAI-DLCの「永続的なコンテキストの保存・維持」という重要な要素と方向性が一致しています：
- Knowledge：セッション間での情報永続化
- Todo Lists：作業単位の分解と進捗管理の継続
- Checkpoints：開発状態のスナップショット管理
- Spec Driven Development：仕様ファイルのマークダウン管理
また、CheckpointsやTangent Mode、Delegateは、前述のAI-DLCの原則と親和性があります。AIの推論プロセスを可視化し、疑問を解消しつつメイン作業を継続できる仕組みは、人間が適切なタイミングで介入し重要な決定を行うためのものです。
このように見ていくと、KiroはAI-DLCという新しいソフトウェア開発方法論との統合を目指しているように思えます。単なるコーディング支援ツールではなく、より構造化されたAI駆動開発の実現を志向しているのかもしれません。
機能から見るAWSの戦略的方向性
ここまで、Kiro CLIで追加された主要機能を見てきました。これらの機能から、AWSがKiroを通じて目指すAI開発の姿を考察します。
Kiroの差別化ポイント
紹介した機能群から見えてくるKiroの明確な強みは以下の3つです。
Spec Driven Development（SDD）という軸
スペック→実装→検証のループを自動化し、即興的な指示よりも仕様の正確性や進捗証跡を重視します。Vibe Codingとは対極にあり、プレビュー版リリース以降、業界でも広く採用され始めています。
ファイルベースのコンテキスト管理
Todo Lists、Knowledge、Checkpointsなどの実験機能は、すべてファイルベースで永続化される設計です。コンテキストウィンドウの限界を超えて、セッション間・チーム間で情報を引き継げます。
CLI/IDE統合
2025年11月の一般提供で両環境が統合され、同じ設定でエージェントとツール群を使えるようになりました。Claude CodeやCursor、OpenAI Codexも2025年にCLI強化を実施しており、業界トレンドとして明確です。
ユーザー視点での期待
開発現場からは、主に以下のような機能強化を期待する声が想定できます。
Specワークフローの自動化
スペック更新が自動テストやプロパティ検証に反映され、影響範囲を自動追跡して実装・テスト・ドキュメントへの反映を支援する機能。テンプレート化や差分レビューなどチーム合意形成を楽にする仕組み。
CLI/IDE間のシームレスな体験
セッション途中でCLIとIDEを行き来しても、作業コンテキスト（Todo、Knowledge、Checkpointsなど）が完全に引き継がれる体験。Auto AgentやDelegateを両環境で同水準で扱えること。
AWSエコシステムとの深い統合
KiroエージェントがIAMロールやCloudWatchログを直接扱い、Lambda影響範囲調査やIaC差分設計を支援。CodeCatalyst、CodeWhisperer、Cloud9との連携強化。
マルチエージェントの可視化と並列実行
エージェントが何をしているかをGUI/CLIで追跡できるダッシュボード。Delegate機能の本格的な並列実行基盤への進化。CloudWatch EvidentlyやBedrock Guardrailsと組み合わせたKPI追跡。
AWSの戦略的意図
Kiroの機能設計を見ていると、AWSが目指すAI開発の姿が見えてきます。それは、前述したAI-DLCという新しい開発方法論との統合を目指している可能性が高いと考えられます。
KiroがSpec Driven Developmentを推進しているのは、AI-DLCの「開始フェーズ」と方向性が一致しています。即興的なLLM指示よりも仕様の正確性や進捗証跡を重視する文化を押し出そうとしている点は、前述したAI-DLCの思想と共通しています。プロパティベーステストの導入など、仕様の正確性を検証する仕組みを強化している点も、この方向性と整合的です。
内製ツールとAIをシームレスに統合
Auto Agentがタスクごとに最適なAIモデルを選んで、コスト23%削減を実現しています。将来的には、インフラリソース（ECSタスクやStep Functions）をAI指示で操作し、エージェントがAWSリソースを自動的に使い分ける体験に進化するかもしれません。
チームコラボと集中管理を一手に
一般提供発表では、集中管理機能付きチームプランを提供して、スペック検証・進捗可視化・カスタムエージェントまで含めた"一社まるごとAI開発スタック"を目指す姿勢が見えました。CodexやClaudeがSaaS連携で伸ばす領域に、AWSならではのIAM/組織アカウント統制を持ち込む狙いがあるように思えます。
開発ライフサイクル全体の可視化を目指す
Todo Lists、Checkpoints、Knowledgeといったファイルベースのコンテキスト管理機能は、AI-DLCの「開始→構築→運用」という3フェーズでの永続的なコンテキスト管理と考え方が似ています。これにより、CLI/IDE双方での体験差を可視化し、Kiroのワークフローがどう現場の課題を解決するかが明確になります。
特に、スペック更新がどう実装・テスト・デプロイメントに波及するか、そのトレーサビリティを見せることで、構造化されたAI駆動開発の価値を示し、採用企業を増やす戦略が見えます。
まとめ
2025年11月、Amazon Q Developer CLIがKiro CLIへと統合され、Kiroファミリーの一員として生まれ変わりました。
本記事で紹介した機能群から見えてきたのは、AWSがAI-DLC（AI駆動開発ライフサイクル）という新しい開発方法論との統合を志向している可能性です。特に以下の点が重要です。
- ファイルベースのコンテキスト永続化: Knowledge、Todo Lists、Checkpointsなど、セッション間での情報継続を重視
- 構造化されたアプローチ: Vibe Codingとは対極にある、計画駆動の開発スタイル
- CLI/IDE統合: 両環境でシームレスに利用できるツール群
Claude Code、Cursor、OpenAI Codexといった競合が機能競争を繰り広げる中、Kiroは独自のポジションを確立しつつあります。今後、開発ライフサイクル全体を通じた可視化機能の強化や、AWSインフラとの深い統合が進めば、エンタープライズレベルでのAI駆動開発プラットフォームへと進化していくかもしれません。
AWSが提唱するAI-DLCという新しい開発パラダイムの行方とともに、Kiroの進化に引き続き期待していきたいと思います。
（おまけ）AI駆動開発についての個人的な評価
ここまでKiroとAI-DLCの機能と方向性を客観的に紹介してきましたが、実際の開発現場での使用感を率直に共有します。
以下は筆者の主観的な意見であり、用途や開発スタイル、チーム構成によって評価は大きく異なる点にご留意ください。本文で紹介した機能の有用性を否定するものではなく、あくまで一つの使用例として参考にしていただければと思います。
SDD
SDDはAIを労働力にしたウォーターフォール開発だと感じています。
ドキュメントが量産されるため、レビューするのがまず辛い。
spec-kitやcc-sddも使っていますが、レビューは真面目にやらずにプロトタイプ作成のガードレールに使うぐらいの感覚でいます。
Vibe Codingを丁寧にやるという意味ではとてもいいと思います。
受け入れ要件を丁寧に詰め、仕様書を丁寧に詰めていけば、エンジニア自身の習熟度に応じて完成度は高くなる印象です。大量の自然言語ドキュメントから矛盾点を洗い出すことが大変なので、向き不向きは間違いなくあります。
また、エージェントによる実装に対して適格な指示をして軌道修正をするのが苦手な人が60〜80点を出すのに向いています。非エンジニアがプロトタイプを作るには良い選択肢かもしれません。
AI-DLC
AI-DLCは同期的コミュニケーションによって人間のコミュニケーションというボトルネックを無くすという、SDDを内包した超短期アジャイル風の開発ライフタイムサイクルという印象です。
実際に何度か試しましたが、AIによって壁打ちやモック作成、仕様の言語化を高速化することでハッカソンのスピード感を業務に持ち込むことに価値があると思っています。
ファイルベースコンテキスト
SDDもAI-DLCもファイルベースコンテキストに重点を置くことが特徴です。
実際に、コンテキストが膨れ上がるとエージェントの挙動はろくでもないものになりがちなので、コンテキストの外部化は良いアプローチです。
しかし、現状のコードベースに対してある程度大きな機能を追加する場合は、ツールを使わずとも調査させて実装計画を立てて.mdに出力、チェックリストを満たすように実装させるぐらいである程度のガードレールにはなります。セッションをリセットしたときに参照するべきファイルパスを伝えるのも簡単になります。
私は個人開発でも業務でも、この単体の{date}_{task}.mdをリポジトリのdocs/ssdに放り込んでレビューに出しています。
レビュワーに意図を伝えるにも役立ちますし、その時点での仕様であり、調査の足しになるもの程度の認識で1ファイル残す分には邪魔ではないので今のところはこの簡易SDDが一番付き合いやすいと感じています。
そもそも深くコードベースを理解して最小限の文章で該当Agentにとって過不足なく指示ができれば一番良いのですから、次世代のググり力と思って鍛えた人が強いかなあと思っています。
参考資料
Discussion