なぜ今 Intent-Driven Development が必要か
生成 AI は開発を簡単にしたのではありません。難しいところを移しました。実装は安くなりました。そして既存の作法 — vibe coding、仕様書、要件会議 — はその世界向けに作られていません。
AI がコスト構造を変えた
何十年もの間、コードを書くことが最もコストがかかる工程でした。仕様、要件、設計書はその工程を正当化するための入力でした。
それはもう真ではありません。Cursor、Claude Code、自律エージェントは数分で動くコードを出します。ボトルネックは上流に移った: 何を作るかを決める、昨日下したトレードオフが今日も成立すると判断する、出荷されたものが意図を反映しているか検証します。
実装コストは下がりました。判断と検証のコストは下がっていません。IDD はそのミスマッチへの応答です。
AI 活用チームに見られる 3 つの痛み
Drift (漂流)
自律エージェントを 1 時間動かせば、目の前の問題を解きます。1 週間動かせば、最初に始めた問題とは別の問題を解いています。根を張る意図がなければ、エージェントは漂流する起点を持てません。
再説明税
プロンプトのたびに、昨日決めたことを再び説明しています。「クライアント入力を信用しないので server authority にする」という意図が、システムプロンプトでも、コードレビューでも、新しい外注先との会話でも繰り返されます。
レビュー疲れ
人間がエージェントの PR をレビューするとき、比較対象は自分の好みになります。他に比較するものがないからです。1 週間に 10 件レビューすれば、好みは劣化します。レビュアーは形式的に通すか、スタイルで止め始めるかのどちらかになります。
意図 (Intent) はどんなものでなければならないか
- 構造化されている. 階層あるいは関係を持ち、読者が辿れます。フラットな一覧はノイズになります。
- 再利用可能. 新しい機能、新しいエージェント、新しい外注先がすべて同じ意図を参照します。
- 人間可読. 人間が育てます。生成ではなく、自然言語。YAML や schema だけではありません。
- 機械可読. AI エージェントの文脈として食える。自然言語でよいが、混沌は不可。
そうやって作られた意図は、一度きりの仕様書ではなく、開発作業そのものに流れ込みます。各 GitHub Issue が関連する意図のスライス（アーキテクチャ・契約・UI パターン）を受け継ぐので、「分かりやすい Issue を書く」ことが AI 支援開発で最もレバレッジの効くスキルになります。文脈が最初から揃っているので実装は迷わず進み、レビューも個人の好みではなく意図との差分で行えるため速く客観的になります。
そして意図は最初から完璧である必要はありません。Intent-System は「クラリフィケーション」と呼ばれる継続的なループを回します。AI が蓄積された意図をレビューし、「ここはどうしますか？」という問いを大量に出し、推奨案も併記する。人間は強いこだわりがない部分は推奨案を採用し、こだわりたい部分だけ自分で答える。これで意図は段階的に厚くなり、最初に巨大な仕様書を書く必要がなくなります。
IDD が過剰な場合
使い捨てスクリプト、意図がコード自体である探索的データ分析、週末だけの一人プロトタイプ、自分以外にレビュアーがいないツール — そういう場合は IDD はオーバーヘッドにしかなりません。本サイトのどのページでも明示しています。
IDD が割に合うのは、複数の人 (またはエージェント) が同じコードベースを触る場合、システムのライフサイクルが特定メンバーの記憶寿命より長い場合、「コードが何をするか」だけでなく「なぜそのトレードオフを選んだか」の記録が必要な場合。