Intent-Driven Development とは何か

定義

Intent-Driven Development は、意図 — システムがなぜ存在し何を達成しなければならないかの永続的な記述 — を、ソフトウェア仕事の主たるアーティファクトとして扱う規律。

コードは spec / プロンプト / 直接生成のいずれかを経由して、意図から生まれる。意図は人間がキュレーションし、コードはスライスに応じて人間 / エージェント / AI が生む。

IDD の前提にある賭けは、能力のあるモデルを使うときは「縛る」のではなく「方向を渡す」 ── 地図とコンパスを渡す ── のが正解だ、というものです。その地図に載っているのが意図です。これがうまくいったとき、LLM は一歩ごとに許可を求めるのをやめ、チームがマージしたいと思える仕事を運び始めます。

"開発チームの意図は自然言語で表現され、コードは last-mile のアプローチとなります。"— GitHub Spec-Kit · spec-driven.md

SDD との重なり

IDD は SDD の一層上に位置します。意図が上流、spec は実装への橋渡し、コードは last mile。

ツリーには何が入るか

Intent ツリーは、辿れる構造に並んだ小さな markdown ファイルの集まりです。中心の 3 系統 ── Purpose（なぜ）／ User Context（誰が、いつ）／ Means（どうやって）── が「なぜ・誰のために・どう実現するか」に答え、その周りに rules / specs / execution / clarifications という 4 つの運用フォルダが並びます。

Means の下には、2 つの面をあえて同居させます。プロダクト体験の意図 ── ユーザーが何を感じ、何ができ、最終的に何を達成するのか、さらにはプロダクトが存在する大きな目標まで ── と、技術の意図 ── アーキテクチャ・契約・検証戦略 ── は、互いを制約し合うので同じツリーに置きます。ユーザー側を単に「フロントエンド」と呼ぶと軽く見えてしまいますが、ここはプロダクトの価値が決まる面です。両者を別々のツールに分けてしまうことが、「言っていたこと」と「実際に作ったもの」の間に drift を生む出発点になります。

実際のディレクトリ構成・ファイル形式・昇格状態は Intent Tree ページを参照してください。

意図はどう育つか — クラリフィケーション・ループ

IDD は最初から完璧な仕様を要求しません。Intent-System の実装では、AI が蓄積された意図を継続的にレビューし、「ここはどうしますか？」という問いを推奨案と共に大量に提示します。人間はこだわりのない部分は推奨案を受け入れ、こだわりたい部分だけ自分で答える — 自分の判断が本当に効く場所に集中できます。これを繰り返すたびに意図ツリーは厚くなり、最初に巨大な仕様書を書く必要がなくなります。

厚くなった意図ツリーは運用面で効いてきます。各 GitHub Issue が関連する意図のスライス（アーキテクチャ・契約・UI パターン）を受け継ぐので、AI 支援開発で最もレバレッジの効くスキル ──「分かりやすい Issue を書くこと」── が現実になります。実装は最初から文脈が揃った状態で進み、レビューは個人の好みではなく意図との差分で行えます。

最初の答えはどこから来るのでしょうか。プロダクトの初期段階では Intent Storming と呼ぶプロセスを行います ── プロダクトオーナーとして技術と意図をまとめていく作業です。ブレインストーミングや Event Storming と同じ姿勢で行いますが、手元に残るのは Intent ツリー。チームのワークショップでも、AI にヒアリングしてもらう一人作業でも成立します。

全体のループ ── 5 拍子で

全体としては、IDD は意図に始まり意図に戻る 1 つのサイクルです。各拍子には専用ページがあります。ここで示すのは、それらをつなぐ全体の形です。

1. 種まき。 Intent Storming を行う ── プロダクトオーナーとして技術と意図をまとめる作業を、チームで、あるいは AI にヒアリングしてもらう一人作業で進める。出てきた答えはそのまま Purpose / User Context / Means の各ノードとしてツリーに書き込む ── あとで「議事録から intent に翻訳する」工程は要りません。
2. 鋭くする。 AI がツリーを継続的にレビューし、「ここはどうしますか？」を推奨案つきでバッチ提示する。チームはこだわりのない部分は推奨を採用し、こだわりたい部分だけ自分で答える。受け入れた答えはその意図を一段昇格させます（inferred → clarified → canonical）。
3. Issue にコンパイル。 ツリーのスライスがそのまま GitHub Issue になり、関連するアーキテクチャ・契約・UI パターンを最初から持っています。文脈が構造化された状態で添付されるので、「分かりやすい Issue を書くこと」が苦行でなくなります。
4. 実装 → AI レビュー → 人間承認。 エージェント（または人間）が Issue に埋め込まれた情報のみを文脈にして ai-develop 上で実装する。Intent ツリー全体を読み込んだ別の AI レビュアーが、実装・Issue・ツリーを横断して読み、コードとテストが意図を守っているかを判定する。main への昇格前に、人間が最終承認を出します。
5. 現実とつなぎ直す。 ひと回しで完成品ができる前提は置きません。設計スレッドと人間が、マージされたプロダクトを定期的に実際に動かし、それが守るべきだった意図と照らしてチェックします。クローズアウトでは、受け入れた diff を canonical としてツリーに書き戻す。ズレは ── 先回りで気づいたものも、リリース後に出てきた不具合も ── Intent-Bug Issue として再投入され、「実装バグ（意図は正しい / コードを修正）」か「意図の漏れ（意図が述べていなかったことを実装が妥当に推測した / 先に意図をより詳細に述べ、その後で修正）」に分類されます。どちらの場合も同じレビュー・承認経路で出ていきます。最初の意図が保存されているからこそ、この 2 つの切り分けも、そもそも結果が意図どおりかのチェックも無理なく行える ── これがツリーを「ただ膨らむ」のではなく「鍛えて強くする」ものにします。

IDD であるもの / ないもの