Aka Blog
Written by aka
on 

Intent Driven Developmentを調べてわかった, Sproutedが埋めている空白

#thoughts #framework #sprouted #intent-driven-development #IDD
Intent Driven Developmentを調べてわかった, Sproutedが埋めている空白

免責: この記事は生成AIにアイデアの添削, 文章の作成を手伝ってもらい, akaがレビューしてます.

どうもakaです.

前回の記事でSproutedというフレームワークを公開しました. 仮説木で意思決定を管理するフレームワークです.

公開してからしばらくして, Intent Driven Development（IDD） という概念が盛り上がっていることに気づきました. 「意図駆動開発」. 名前からして, Sproutedと近い領域を扱っていそうでしたので, これは調べないわけにはいかない.

結論から言うと, Sproutedと同じ領域をカバーしているものはありませんでした. 同じ「WHY/WHAT/HOW」という言葉を使っていても, 中身がまるで違いました.

この記事では, その調査の過程と, わかったことを共有します.

IDDについて

まず前提の整理から.

IDD（Intent Driven Development）には, 確立された定義がない. 複数の提唱者が独立して同じ名前を使っており, それぞれの関心もアプローチもバラバラだ. 共通しているのは**「AIに実装させる前に, 意図（Intent）を明確にしよう」**という方向性だけだ.

提唱者たちはどう言っているか

面白いことに, IDDは一人が提唱したものではない. 複数の人が独立して同じ方向にたどり着いている.

John Ferguson Smart

John Ferguson Smart は, 2017年にBDD（振る舞い駆動開発）の文脈で最初に「Intent-Driven Development」という言葉を使った. 「行動する前に意図を宣言する」というBDDの隠れた原則を言語化したものだ. ただし当時はAIコーディングの文脈ではなく, 今のIDDとは異なる話だ. 具体的な実装やツールはない.

Scott Molinari

Scott Molinari は, IDDを3つのフェーズで捉えている. Definition（定義）, Generation（生成）, Verification（検証）. さらに「Immutable Skeleton」という概念を提唱した. コントラクト, 制約, ポリシーで構成された不変の骨格をまず作り, AIはその枠内で実装する, という考え方だ. 彼の主張の核心は「AIが車を運転し, 人間が道を構築する」という比喩に集約される. アーキテクチャの主導権は人間が握るべきだ, という思想だ. 思想としては明確だが, 具体的なツールや実装はない.

Paulo Renato（Exadra37）

Paulo Renato（Exadra37） は, GitHubでより実践的なアプローチを公開している. Intent文書にWHY/WHAT/HOWセクションを設け, AIエージェントに「Staff SE（10年以上の経験）」として振る舞わせる. 1サブタスクごとにユーザー承認を挟み, TDDを強制する. 現時点ではElixir/Phoenix専用だが, 具体的な開発規約とテンプレートまで落とし込んでいる点で, IDDの中では最も実装が進んでいる.

Binoy Ayyagari

Binoy Ayyagari は, 「Adaptive Intent-Driven Development（AIDD）」を提唱している. アジャイルの反復・適応とIDDの意図定義を組み合わせ, 自律エージェントがIntentに基づいてイテレーションを回す, というビジョンだ. ただし具体的な方法論やツールはなく, 概念レベルの提案にとどまる.

copyleftdev

copyleftdev は, IDDを実際のプロジェクトに適用した実例を記事にしている. AsyncAPIで122のイベント型を定義し, 8つのRFCを書き, JSONスキーマ化してGitHub Issuesを自動生成する, という具体的なパイプラインだ. 解こうとしている問題は大きな設計をタスクに分解する作業の自動化であり, 意思決定の構造化や仮説管理はスコープ外だ.

KodeNerds

KodeNerds は, 「仕様を検証可能な仮説として扱う」というユニークな視点を持っている. リーンスタートアップ的なビルド・メジャー・ラーンのサイクルとIDDを組み合わせたアプローチだ. ただし具体的なツールや仕組みはない.

Patrick Debois

Patrick Debois（DevOpsの名付け親）も, ポッドキャストでIDDについて語っているらしい. まだ聴けていないので詳細は割愛する.

これらの提唱者は ― 詳細に差はあれど ― 同じ方向を向いている. 「AIに渡す前に意図を構造化せよ」. 複数の独立した思考者が収束するとき, そこには本質的な課題がある.

ワークフローはバラバラ

では具体的にどう開発するのか. ここも提唱者ごとにバラバラだ.

共通しているのは「まず意図を明文化し, それからAIに実装させる」という大枠だけで, 具体的なプロセスは統一されていない. IDDはまだ「考え方」であって, 確立された方法論ではない, というのが正直な印象だ.

ただ, この「まず意図を明確にする」という考え方自体は正しいと思う. 曖昧なプロンプトで「いい感じに作って」とやるよりも, 意図を明確にしてからAIに渡したほうが品質は上がる. 前回のSprouted記事でも, この流れ自体は肯定している.

ここまでがIDDの概要だ. ではSproutedとの違いはどこにあるのか.

Exadra37のIDDとSprouted ― 同じWHY/WHAT/HOWで中身が違う

調べていて最も面白かったのが, Exadra37（Paulo Renato）のIDDプロジェクトだ. IDDの中では最も完成度が高く, GitHub上でIntent文書のテンプレート, 開発規約, AIエージェントへの指示書まで公開されている.

Sproutedも同じくWhy/What/Howを使う. 言葉が同じだ. でも中身を比べると, まるで別物だった.

Exadra37のWHY/WHAT/HOW

IDDにおけるWHY/WHAT/HOWは, 1つのIntent文書の中のセクションだ.

つまり, 1つの機能に対して「背景→要件→タスク」を書く. 複数のIntent文書を作ることはできるが, 各Intentは「自己完結した文書」として独立しており, Intent間の親子関係や階層構造はない. カンバン方式（todo/work-in-progress/completed）でフラットに管理される.

SproutedのWhy/What/How

Sproutedでは, Why/What/Howは再帰的に連鎖する構造だ.

そして, あるノードのHowが次の階層のWhyの制約になり, WhatがWhyの動機になる. この連鎖が必要なだけ続く.

並べてみると

graph TD
    subgraph "IDDのWHY/WHAT/HOW"
        I_WHY["WHY: 背景説明（確定）"]
        I_WHAT["WHAT: 機能要件"]
        I_HOW["HOW: タスクリスト"]
        I_WHY --> I_WHAT --> I_HOW
    end

    subgraph "SproutedのWhy/What/How"
        S_W1["Why: 動機+制約（仮説, 確信度付き）"]
        S_What1["What: 達成したいこと（複数候補）"]
        S_How1["How: 手段の選択（却下理由保存）"]
        S_W1 --> S_What1 --> S_How1

        S_W2["Why: 上位のWhat→動機 / How→制約"]
        S_What2["What: ..."]
        S_How2["How: ..."]
        S_How1 -.->|"制約の連鎖"| S_W2
        S_What1 -.->|"動機の連鎖"| S_W2
        S_W2 --> S_What2 --> S_How2
    end

    style I_WHY fill:#8B4513,color:#fff
    style I_WHAT fill:#3a7bd5,color:#fff
    style I_HOW fill:#e67e22,color:#fff
    style S_W1 fill:#4a9e4a,color:#fff
    style S_What1 fill:#3a7bd5,color:#fff
    style S_How1 fill:#e67e22,color:#fff
    style S_W2 fill:#4a9e4a,color:#fff
    style S_What2 fill:#3a7bd5,color:#fff
    style S_How2 fill:#e67e22,color:#fff

同じ言葉を使っているが, 構造が根本的に違う.

IDDのWHY/WHAT/HOWはフラットな3セクション. 仮説性を管理する仕組みはない. Sproutedは再帰的な木構造. どの階層も同じ構造を持ち, 仮説として扱われ, 確信度で管理される.

Intentの扱い方も違う

構造だけでなく, Intentをどう扱うかも根本的に違う.

Exadra37のIDDでは, Intent文書に「仮説かどうか」を管理する仕組みがない. todo→work-in-progress→completedとステータスは変わるが, Intent自体の「確からしさ」を扱う機能はない. つまり, 暗黙的に「書かれた意図は正しい」前提で運用される構造になっている.

Sproutedはここに対して明確な立場を取っている. すべてのノードは仮説だ. 要求も仕様も設計も, 確信度のグラデーションの中にある. 確定物など存在しない.

Exadra37のIDDSprouted
Intentの扱い仮説性を管理する仕組みがないすべて仮説
確信度管理なしconfidence score
変更への対応Intent書き直し仮説の更新 + 影響伝播

Exadra37の強み

一方で, Exadra37の強みは「開発プロセスへの落とし込み」だ. Intent文書のテンプレート, AIエージェントへのロール定義, TDDの強制, 1サブタスクごとの承認フローなど, 実装現場で即座に使える仕組みが整っている. Sproutedは意思決定の構造化に注力しており, こうした開発プロセスの規約は現時点では提供していない.

他のIDD提唱者とSproutedの違い

Exadra37以外の提唱者とも比較してみる.

提唱者関心の中心Sproutedとの重なり
John Ferguson SmartBDDの原則としての意図宣言なし. AIコーディング以前の話
Scott Molinari人間がアーキテクチャの主導権を握る思想レベルでは近いが, 仕組みがない
Binoy Ayyagariアジャイル + IDDの融合ビジョン方向性は近いが, 概念レベルの提案のみ
copyleftdevIntent→RFC→Issues→実装の自動化パイプライン作業管理の効率化. 意思決定の構造化はスコープ外
KodeNerds仕様を検証可能な仮説として扱う最も近い. ただし仮説管理の仕組み（confidence score等）はない

KodeNerdsの「仮説として扱う」という発想はSproutedに近い. しかし「仮説をどう管理するか」― 確信度, 検証/棄却のライフサイクル, 前提が崩れたときの影響伝播 ― といった仕組みまでは提案されていない. 考え方は近いが, フレームワークとしての具体性が違う. ただし, Sproutedの確信度管理もまだ未熟な段階だ.

まとめ

以下, Sproutedと他IDDの差異をまとめました.

IDDSprouted
意図を明確にしてから実装する○○
WHY/WHAT/HOWの構造○○
Intent文書のテンプレート・フォーマット○-
AIエージェントへの指示書・ロール定義○-
TDD強制などの開発プロセス規約○-
タスク分解と進捗管理○-
仮説管理（confidence score）-○
再帰的な意思決定構造（木構造）-○
候補管理（却下理由の保存）-○
Why→What→Howの再帰連鎖-○
上位の前提が崩れたときの影響伝播-○

急遽IDDという概念を知り, 正直, もし全く同じフレームワークがあったらSproutedの記事ごと下げようかと思っていました. IDDの「意図を明確にしてからAIに渡す」という方向性は正しいし, 特にExadra37の開発プロセスへの落とし込みには学ぶところが多いです. 一方で, 「意思決定を仮説として構造化する」というSproutedの領域は, まだ誰も深く掘っていなかったので, そのまま残すことにしました.

Sproutedについての詳細は前回の記事を参照してください. リポジトリはGitLabで公開しています.

ではまた.

参考記事

IDDの提唱者・解説:

Loading comments...

← Top