コンセプトサイト · v0.1

AI 時代は、詳細な仕様ではなく意図を伝えて AI と協働する ── Intent-Driven Development (意図駆動開発)

AI コーディングエージェントを本番運用するスタートアップのために。プロンプトではなく意図そのものを真実の源として扱う、語彙と運用システム。

PurposeUser ContextMeansSliceSliceSliceSliceINTENT TREE → SLICES
レイヤIDD — SDD の上流
真実の源Intent ツリー、プロンプトではありません
ステータスGitHub で OSS 公開中 · Apache-2.0
コンセプト

現在の AI コーディングが抱える問題

01

バイブコーディングは意図を失います。

Cursor や Claude Code での良いセッションは動くコードを生むが、六週間後にはその判断の理由を誰も覚えていません。

02

spec ドキュメントは陳腐化します。

実装前に書かれた spec は最初の PR がマージされた瞬間から乖離します。二週間後、spec はもう存在しないシステムを語っています。

03

共有された意図がなければ、エージェントの判断はぶれていきます。

自律エージェントを一時間動かせば目の前の問題を解きます。一週間動かせば別の問題を解いています。

コンセプト

Intent-Driven Development とは何か ── ひとことで

IDD は真実の源をコードの一層上に移す。「なぜ」と「何を達成したいか」は人間がキュレーションする永続的なアーティファクトとして生き、「どう実装するか」は下流で人間 / エージェント / AI のいずれかが扱います。

AI 支援の開発において、最もレバレッジが効くスキルは「良い Issue を書くこと」です。構造化された意図ツリーがあるからこそ、それが現実になります。各 Issue は関連する意図(アーキテクチャ・契約・UI パターン)を自動的に受け継ぐので、実装は迷いなく進み、レビューは個人の好みではなく意図そのものとの差分で行えます。

そして、ひと回しで完成品ができることを前提にしません。作られたものは、保存された意図と照らして ── 設計スレッドと、実際に動かす人間の両方が ── チェックし、ズレは修正パケットとして戻ってきます。プロダクトオーナー・デザイナー・エンジニアが最初に抱いていた意図が意図として残っているので、「思った通りに作れたか」は、いつでも答えられる問いであり続けます。

重なり方
intent(なぜ・何を)
spec(どう作るか)
code(ラストマイル)

IDD と SDD は競合しません。積み重なります。

プロダクト · INTENT-SYSTEM

私たちは、意図を中心に据えます。

Intent-System は、Tree-Structured Operational IDD の具体的な実装です。spec-as-source の立場が spec を中心に据えるのに対して、私たちは意図を中心に据えます。これを Intent-as-source と呼んでいます。

01
意図はリストではなくツリーで。
Purpose / User Context / Means.
02
プロダクト体験と技術の意図を一箇所に。
UX とアーキテクチャが同じツリーを共有するので、同じ変更が両側から同時に制約される。
03
人間が決め、エージェントが実装。
スライスごとに割り当て、あなたがレビュー。
04
すでに動いています。
Claude が /loop 5m で実装とレビューを別 cwd で並走駆動 ── アクティブなドメインで packet 10 個 / 3 時間 のスループット。Codex はクラウド自動化として並走。
GitHub で入手3 スレッドのループを見る
実例

誰のためのものか

01
スタートアップの技術リード
AI コーディングを本番運用していて drift 問題を感じています。
02
個人開発者
Cursor / Claude Code を毎日使い、意図に構造がと感じています。
03
リサーチャー・執筆者
IDD/SDD の全体像を公平に整理したいと考えています。
04
エンタープライズの技術戦略担当
IDD がガバナンスに適合するか評価したいと考えています。

使い捨てスクリプトや個人プロトタイプを書いているなら、Intent-System はオーバーキル。すべてのページでそう書いています。

Intent-System を試す