この度、私たちはAI開発における一連のスキルと方法論であるIDD（Intent Driven Development）をオープンソース化いたしました。

私たちは、IDD（Intent Driven Development）と名付けた一連の方法論とツールチェーンをオープンソースとして公開しました。その核心となる理念は、簡潔に言えば、AIに「何を達成したいのか」を伝え、「何をすべきか」を指示するのではない、というものです。

AIによるプログラミング支援が日常的に浸透した今、従来の要件定義書、ユーザーストーリー、技術仕様といったものは、その役割を終えつつあるように見受けられます。これらは本来、人間同士の協業のために設計されたものです。しかし、人間とAIが協業する現代のシナリオにおいては、どれほど詳細なドキュメントを作成してもAIが意図を誤解し、結果として度重なる修正作業が必要となるケースが少なくありません。そこでIDDが提示するのは、発想の転換です。AIに「どう実装すべきか」を事細かに指示するのではなく、「何を達成したいのか」という目的を明確に伝えることで、AI自身に最適な実現方法を計画させるというアプローチです。本稿では、なぜ私たちがこのアプローチに至ったのか、そしてこのシステムが具体的にどのように機能するのかについて、掘り下げてご紹介いたします。

SDD 対 IDD

ソフトウェア工学の分野では、「じっくりと考えてから着手する」という課題に対し、多くの試みが積み重ねられてきました。SDD（Spec Driven Development）もその一つで、詳細な仕様書を先行して作成し、それに従いコードを実装するというのがその核となるアプローチです。これは極めて合理的に思えますが、AI時代においてはその限界が露呈し始めています。

SDDという形式主義については、私自身も肌で感じてきたところがあります。かつて、シアトルの大手ソフトウェア企業で働いていた頃、チームに一人のPMがいました。彼が担当すると、どんなものでも異常なほど長い「八股文」（形式ばかりを重んじた文章）と化し、数行で済むはずの説明が、なぜか十数個ものユーザー ストーリーにまで細分化されていました。その形式は完璧でどこにも抜かりないものでしたが、結局のところ、それが何を意図しているのかは全く理解できませんでした。昨年、AmazonのKiroを試用した際、あの時の記憶が蘇るような感覚に襲われました。Kiroは典型的なSDDツールであり、数多くの仕様ファイルを生成しますが、その構造は規範的であるにもかかわらず、「書くこと自体が目的になっている」という印象が強く感じられました。これはツールの問題ではなく、発想そのものの問題と言えるでしょう。従来のソフトウェアエンジニアリングの手法をAI時代にそのまま適用しているため、ツールは新しくなっても、根本的な思考様式は一切変わっていないのです。

SDDの課題は、情報を依然として従来の手法で整理している点にあります。具体的には、要件タイプ（機能要件、UX要件、技術要件）ごとに分類し、ユーザーストーリーに分割し、個別のタスクファイルを管理する方式です。この分類は、プロダクトマネージャーが機能要件を、デザイナーがUX要件を、アーキテクトが技術要件をそれぞれ確認するといったように、人間同士の協業においては意味を持ちます。しかし、AIにとっては、この分類は完全なコンテキストを分断してしまいます。AIは、5つのファイルから断片的な情報を集めるのではなく、モジュールの全体像を把握する必要があります。従来の手法で細かく分割すればするほど、AIは再構築により多くの労力を費やし、誤りがあれば修正作業が繰り返されることになります。

IDDのアプローチは、従来のTDDやSDDとは異なる独自のものです。まず、要求タイプではなくモジュール単位で構成されており、完全なコンテキストを維持します。また、タスクファイルを作成する必要がなく、AIが自律的にタスクを分解できるように設計されています。Intentの抽象度もより高く、「どのように実現するか」ではなく「どのような効果を求めるか」を記述することに重点を置いています。TDDと比較すると、IDDはTestの前にIntentの層を追加する点が特徴です。さらにSDDとは対照的に、IDDは実装の詳細を規定せず、AIがより優れたソリューションを計画する十分な余地を提供します。

IDDはなぜ実現できるのか

あなたはこう尋ねるかもしれません。詳細な仕様書を書かなくても、AIは具体的に何をすべきか、どうやって知るのか？ここに、直感に反する事実があります。多くの分野において、AIは人間よりも「どうすべきか」をよく理解しているのです。

先日、私は6502 CPUエミュレータを実装しようと考えました。こうしたタスクは、従来「ハードコア」な部類に属し、CPUアーキテクチャ、レジスタ設計、命令のエンコードとデコードといった深い理解が求められる上、設計段階だけでも膨大な量の技術マニュアルを読み解く必要があります。もしSDD（ソフトウェア設計ドキュメント）方式で進めるとなると、各命令やアドレッシングモードを一つ一つ明確に記述した数十ページにも及ぶドキュメント作成から始めなければならず、仕様書を書き上げる前にプロジェクト自体がお蔵入りになってしまう可能性すらありました。しかし、私がAIに伝えたのは、たった一言です。「標準命令セットを正確に実行でき、基本的なデバッグ機能を備えた6502エミュレータが必要です。」それだけでした。

この結果が私に気づかせたのは、ある一点でした。すなわち、1975年製のチップである6502は、Apple IIやNESゲーム機を駆動しており、その技術文書やオープンソースによる実装は数え切れないほど存在します。LLMは、いかなる人間の専門家よりも多くのエミュレータコードを学習しています。AIが提示したモジュール分割は、私自身の設計よりもさらに明確であり、TDDの要件と組み合わせることで、実装はまさに一気呵成に完成しました。かつては最も経験豊富なエンジニアを要すると考えられていたタスクも、AIにとってはかえって容易なものとなったのです。これは、このような古典的な問題が、AIのトレーニングデータにおいて最も徹底的に網羅されているためです。

IDDが実用性を発揮する基盤は、まさにこの点にあります。AIの訓練データが十分に網羅された領域においては、具体的な手順をAIに指示する必要はありません。私たちは「何を達成したいのか」を明確に伝えるだけでよいのです。AIは人間よりも遥かに多くのパターンを学習しており、その立案する解決策は、私たち自身の発想よりも合理的であるケースが少なくありません。人間の真価は、「何が正しい目標か」を判断することにこそあります。これこそが、まさに人間の英知が求められる本質的な部分と言えるでしょう。

Intent は新たなソースコード

この文の意味は：コードレビューはAIに任せられるが、インテントレビューは人間が実施する必要がある。

AIは、コードが仕様に準拠しているか、セキュリティ上の脆弱性がないか、プロジェクトのスタイルに沿っているかといった点検作業を得意とします。しかし、AIには「この機能が本当に我々が意図するものか」といった、本質的な判断を下すことはできません。そうした判断は人間だけが担えるものです。したがって、人間の労力は、AIが生成したコードを逐一行レビューするのではなく、その「Intent（意図）」、すなわち機能の目的や方向性を吟味することに集中すべきです。

Intentと従来の要件定義書との相違点：

Intentの抽象度はより高くなります。AIに、どのような技術を用いるか、どのように階層分けするかを指示する必要はありません。これらはAIが自ら計画するものです。あなたが明確にすべきは、最終的な効果、存在する制約、そして境界条件への対処法です。

Intent ファイル構造

IDDのIntentファイルは3層構造を採用しています：

1. 構造図 - ASCII図は、モジュール間の関係やデータの流れを示します。テキストよりも図の方が正確であり、LLMも直接その内容を理解できます。

2. 制約ルール - 依存関係の方向や境界ルールなど、必ず遵守しなければならない制限を指します。これらは、直接lintルールやテストアサーションとして具現化することが可能です。

3. 動作例 - 具体的な入出力、境界条件を含みます。これらは直接テストケースとして活用できます。

設計原則：各レイヤーは検証可能でなければなりません。 曖昧な記述ではなく、コードで検査可能な制約です。

ツールチェーン

私たちはClaude Codeプラグイン一式を開発しました：

全体の流れ：

/intent-assess        # 评估是否适合
    ↓
/intent-init          # 初始化结构
    ↓
/intent-interview     # 创建 Intent
    ↓
/intent-review        # 审批关键部分
    ↓
[AI 实现代码]
    ↓
/intent-check         # 验证一致性

インストール：

npx add-skill arcblock/idd

利用シーン

IDD 向け：

適さない場合があります：

終わりに

さて、冒頭の疑問に戻ります。人類はAIに何を伝えるべきなのか。私の考えでは、それはAIに「何を求めるか」を伝えることであり、「どうやるか」ではないでしょう。AI時代においては、仕様駆動型（Spec-driven）のアプローチは形式主義に陥りがちです。どれだけ詳細なドキュメントを作成しても、AIが真に「何を求めているのか」を理解できない、といった事態が生じます。そこでIDDは方向性を転換しました。詳細な手順を規定するよりも、「何を求めるか」を明確に提示し、AIに実装計画を自ら立案させるべきだ、というのです。

このシステムは、弊社で先行して導入・運用した結果、その方向性の正しさを強く実感しております。この度オープンソースとして公開することで、他の開発チームの皆様にも広くお役立ていただけることを願っております。

GitHub： github.com/ArcBlock/idd