バイブコーディングは意図を失います。
Cursor や Claude Code での良いセッションは動くコードを生むが、六週間後にはその判断の理由を誰も覚えていません。
Intent-Driven Development · オープンソース
AI 時代は、詳細な仕様ではなく意図を伝えて AI と協働する ── Intent-Driven Development (意図駆動開発)。
私たちの OSS の CLI、intent-cli は、いま使っているコーディングエージェント(Claude Code・Codex・Cursor・Copilot・OpenCode)でこれを実践するための道具です。意図は git に残り、すべての変更は書いた本人ではないレビュアーに回り、判断はあなたの手元に残ります。
01意図を保持02herdr が連携03レビューで閉じる
オーケストレーションを見る 対応エージェントClaude Code · Codex · Cursor · Copilot · OpenCode
始め方1 スレッド + subagent · デスクトップアプリ・CLI・Orca で
オープンソースintent-cli v0.32.0 · Apache-2.0 · サーバー不要
コンセプト01 02 03
現在の AI コーディングが抱える問題
仕様書は陳腐化します。
実装前に書かれた仕様書は最初の PR がマージされた瞬間から乖離します。二週間後、その仕様書はもう存在しないシステムを語っています。
共有された意図がなければ、エージェントの判断はぶれていきます。
自律エージェントを一時間動かせば目の前の問題を解きます。一週間動かせば別の問題を解いています。
プロダクト
intent-cli がそれにどう応えるか
intent-cli はコーディングエージェントを置き換えません。エージェントが intent-cli に次の手順を聞き、intent-cli が具体的な手順を返し、起きたことを git と GitHub に記録します。
「なぜ」が会話より長く残る。
意図は git 上の小さなファイルとして残り、GitHub の Issue はそこから作られます。新しいセッションも新しいメンバーも、誰かの会話履歴ではなく記録された意図から始められます。
コードを書いていないレビュアー。
1 人で使うときは、レビューのたびに新しい subagent が担当します。チームではレビュー担当の席が、PR を意図と照らして確認します。承認の前に、別のランタイム(例えば Claude が書いたものを Codex が)によるレビューを必須にすることもできます。
新しいコマンドを覚えなくていい。
エージェントに「intent-cli に聞いて」と伝えるだけです。intent-cli がエージェントを起動することはありません。次の手順を返し、結果を検証し、GitHub と自身のメタデータに対して範囲の決まった明示的な変更だけを行います。
1 つのスレッドでループ全体を回す。
1 つの会話(Claude デスクトップアプリ、Claude Code、Orca Run など)が、レビュー用の subagent を自分で起動します。席を増やすのは、複数のユニットを同時に進めたくなったときだけです。
intent-cli は intent-cli で開発しています。2026-09-22 時点で、リポジトリでマージされた 891 件の PR のうち 643 件が intent-cli で切り出して追跡したユニットで、各 PR のレビュー記録は公開されています。 例を見る →
コンセプト
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 の立場が仕様を中心に据えるのに対して、私たちは意図を中心に据えます。これを Intent-as-source と呼んでいます。
01
意図はリストではなくツリーで。
Purpose / User Context / Means.
02
プロダクト体験と技術の意図を一箇所に。
UX とアーキテクチャが同じツリーを共有するので、同じ変更が両側から同時に制約される。
03
人間が決め、エージェントが実装。
スライスごとに割り当て、あなたがレビュー。
04
1 スレッドと、毎回新しいレビュアー。
1 つの会話がすべての手順を進め、レビューのたびに新しい subagent を起動します。複数のユニットを同時に進めたいときは、役割ごとに席を分け、herdr でチームの動きを見られます。
実例
誰のためのものか
01
スタートアップの技術リード
AI コーディングを本番運用していて漂流の問題を感じています。
02
個人開発者
Claude Code・Codex・Cursor を実際のコードベースで毎日使っている方。1 スレッドと、独立したレビュー用 subagent から始められます。
03
リサーチャー・執筆者
IDD/SDD の全体像を公平に整理したいと考えています。
04
エンタープライズの技術戦略担当
IDD がガバナンスに適合するか評価したいと考えています。
使い捨てのスクリプトや捨てる前提の試作なら、Intent-System は過剰です。コードが生き続けるなら、1 人の開発者でも得るものがあります。