AIにコードを書かせる開発を続けていて、自分の仕事の中身が変わってきました。手を動かす時間より、「何を、なぜ作るのか」を考えて伝える時間のほうが、ずっと長くなっています。
株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。この記事では、私たちが社内で使い始め、このたび OSS として公開した Intent CLI（プロジェクト名 intent-system）という開発支援ツールについて、その背景にある考え方を書いてみます。手を動かして使う手順は、続けて公開する実践編にまとめました。
AIへの指示をめぐる試行錯誤
これまで私は、AIに適切な指示を出すために、いろいろなやり方を試してきました。どう作るかをタスクファイルに残したり、プランモードを使ったり、設計を書き出して複数のエージェントにチェックしてもらったり、といった具合です。
このあたりの工夫は、以前こんな記事にも書きました。
仕様駆動開発（SDD）も試しました。ただ、成果物がタスクごとに分かれてしまい、全体を見通して管理するのが難しいと感じました。TAKT も使ってみましたが、コンテキストの消費が大きいことや、エージェントを呼び出して動かす方式が、私の使っている Claude Code のやり方と噛み合わないところがあり、しっくりくる形をずっと探していました。
こうした工夫で、確かに良い設計はできます。そして気づいたのは、その過程で書いた文書には、実はとても重要な情報が載っているということです。「こんなふうにしたい」「この手法を使ってほしい」「このインターフェース方針で行きたい」。プロダクトの判断を左右する意図が、そこにはたくさん書かれています。
問題は、その重要なドキュメントが、常に読まれる場所に整理されていないことでした。書いたそばから埋もれていく。次に似た判断をするとき、また一から書き直す。意図はあるのに、適切な場所に置かれていないので、毎回うまく渡せない。ここが一番の課題だと感じていました。
AIに任せると拡大する「意図のずれ」
意図がうまく渡らない状態でAIに任せると、ずれはさらに大きくなります。
意図の解像度が低ければ、どんなに優秀なモデルでも、期待とは違うものを作ってしまう。しかも困ったことに、AIエージェントは放っておくと止まりません。一時間なら目の前の問題を解いてくれますが、一週間動かし続けると、いつの間にか別の問題を解いていたりします。
似たことは人間同士でも起きていました。実装前に書いた仕様書は、最初のPRがマージされた瞬間から実物とずれ始める。二週間も経つと、仕様書はもう存在しないシステムについて語っている。AIエージェントが速く大量にコードを書くようになって、このずれが起きるスピードも一気に上がった、という感覚です。
最大のレバレッジは「良いIssue」
ではAIが実装を担う時代に、人間の役割はどこに移るのか。私は「意図を明確にすること」だと思っています。
その意味で、良いIssueを書くことが、いま一番レバレッジの効くスキルになりました。何を、なぜ作るのかがはっきり書かれたIssueがあれば、実装は迷わないし、レビューも「コードの好み」ではなく「意図とずれていないか」で判断できます。
問題は、その「良いIssue」を毎回ゼロから書くのが大変だということです。アーキテクチャの方針、過去に決めた約束ごと、UIのパターン。本当はそういう文脈を全部背負ったIssueを出したいのに、毎回手で書き直していたら身が持ちません。
真実の源としての意図（IDD）
そこで私たちは、管理の中心をコードから意図に移すことにしました。これが Intent-Driven Development（意図駆動開発、IDD）という考え方です。
Intent-Driven Development では、意図と仕様とコードを積み上げて考えます。意図（なぜ・何を達成したいか）を一番上に置き、その下に仕様、さらに下に実装が連なります。コードや仕様は、意図から何度でも導き直せる「再生可能なもの」として扱います。逆に、意図だけは下から自動生成できません。ここだけは人間が育てる必要があります。
こうすると、もう一つ良いことがあります。LLMの非決定性（同じ入力でも出力がぶれる性質）を、下流のレイヤーだけに閉じ込められるのです。意図という一番大事な層は人間が握り、ぶれてもいい部分だけAIに任せる、という切り分けができます。
着想元はSekibanの「追記」
そもそもこの発想は、私たちが開発しているイベントソーシングのソリューションフレームワーク Sekiban（sekiban.dev）から来ています。
イベントソーシングでは、大事なデータを上書きせず、起きたことを追記で書き加えていきます。私はこの概念がとても気に入っています。過去を壊さずに、変化を事実として積み重ねていけるからです。
この「追記で育てる」やり方を、プログラミングエージェントにも活かせないか。そう考えたときに、今回のアイデアが浮かびました。意図も同じように、上書きではなく追記で育てればいい。推定から始め、確認を積み重ねて基準へ昇格させる。不具合が出ても意図を直接いじらず、修正を新しいタスクとして足していく。このあと説明する昇格状態や作業単位の扱いは、まさにこの考え方から来ています。
先行する「意図駆動開発」の動き
意図で駆動するという一点にフォーカスしてツールを作っていくうちに、意図駆動開発（Intent-Driven Development）への取り組みが、すでに他の人たちによっても行われていることに気づきました。
呼び方やアプローチはさまざまですが、「AI時代には、仕様より一段上の"意図"を扱うべきだ」という問題意識は、私だけのものではなかったわけです。先行する議論があるのは心強いことでした。私たちのやり方は、その中でも「意図をツリー状に構造化して、運用のループまで回す」ことに寄っています。重なりながら、自分たちの形を見つけていければと思っています。
意図の構造 ─ intent-tree
意図は、ただのドキュメントとして置いておくと、やっぱり隙間に消えていきます。そこで Intent CLI では、意図を intent-tree（意図の木） という階層構造で明示的に持ちます。実体は、ディスク上のMarkdownファイルの集まりです。
骨格は3つの系統に分かれています。
- Purpose（なぜ作るのか） — Mission / Vision / Value / Product Goal
- User Context（誰のためか） — 誰が、どんな状況で、どんなテンポで使うか
- Means（どうやって実現するか） — 操作の体験、システムの振る舞い、技術戦略など
ここで大事なのは、Means は実装の詳細ではないということです。「ReactとVueのどちらを使うか」ではなく、「ブラウザファーストで行くか」「サーバーを権威とする前提に立つか」といった、迷ったときの判断基準を固定する場所です。
意図の成熟度（昇格状態）
もう一つ、このツリーで気に入っている仕組みが、意図に成熟度（昇格状態）を持たせていることです。
- inferred（推定） — AIや既存コードから推定しただけの段階。まだ仮説
- clarified（確認済み） — 対話で確認が取れた段階。意思決定に使える
- canonical（基準） — 下流の仕様や実装を縛る、確定した判断基準
最初から完璧な要件定義を書く必要はありません。推定から始めて、対話を通じて少しずつ確度を上げていく。AIが「こういう意図に見えますが、合っていますか？」と確認を求め、答えるとその意図が一段昇格する。この繰り返しで、プロダクトの方向性が自然と言葉になっていきます。確度は「当てずっぽう」ではなく「状態」なんだ、という割り切りが気持ちいいところです。
Intent CLI ─「AIを内蔵しない」設計
Intent CLI を作るときに工夫したのは、OpenAI や Anthropic のサブスクリプションを通常の使い方の範囲で使いながら、intent-cli を最大限に活かせるようにしたことです。
Intent CLI の中には、AI機能は一つも入っていません。
intent-cli は、意図をまとめるためのプロンプト集と、メタデータ（意図ツリーと、どの作業がどこまで進んでいるかという運用状態のデータ）を変更する機能を持っているだけです。「どう考えるか」は、それを動かしている側のAI（私の場合は Codex や Claude）に考えてもらう設計になっています。
だから使い方も独特です。人間がコマンドを順番に覚えて操作する、という入り方をしません。最初にAIへ「intent-cli に聞いて、使い方を理解して」と頼む。するとAIがツールに同梱されたガイドを読み込み、以後は人間のかわりに意図をまとめていってくれます。私自身、最近は意図が具体的にどうまとめられているかを、あまり細かく見なくなりました。
この割り切りには、もう一つ実務的な効果があります。intent-cli 自体はAIを持たず、プロンプトのガイドとメタデータ管理だけを提供します。それを呼び出すのは、私たちが普段使っている Codex や Claude のエージェントです。
AIにかかる費用は、自分の Codex や Claude のサブスクリプション側で発生します。エージェントが、AIを持たない intent-cli を呼び出して、最新のプロンプトガイドを受け取る。そういう設計です。
記録はすべて手元のファイルに
もう一つ、安心材料を書いておきます。intent-cli は、記録をすべてリポジトリ内のファイル（Markdown と JSON）に書きます。意図ツリーも、作業の進捗といった運用状態も、手元の git リポジトリに残るだけです。
intent-cli 自体がネットワーク通信を直接行うことはありません。どこかの自社サービスに接続して情報を送る、といった処理も入っていません。外部とのやり取りは、gh（GitHub CLI）を通じた git の操作だけです。ふだん使っている GitHub のほかに、知らないうちにデータが送られる、という心配は要りません。
使ってみて感じていること
使っていて一番ありがたいのは、開発の認知負荷が下がることです。
意図を固めるインタビューが終わって開発フェーズに入ると、たとえループが途中で止まっても、深く考える必要がありません。「止まっているから、intent-cli に聞いて直して進めて」と返すだけでいい。細かい判断を毎回やり直さなくてよいので、私は今、3つくらいのプロジェクトを同時に流していても頭がついていけています。
感覚としては、開発会社のマネージャーと話しているのに近いです。自分が元請で、設計のやり取りをする相手が、実装当人ではなくマネージャー。「進捗どうですか」「これはちゃんとできていますか」と聞いて、報告をもらって、「じゃあ次はこれをお願いします」と頼む。そういう距離感です。
不具合が出たときも、コードを直接いじりにいきません。変更の履歴が残らないからです。かわりに intent-system に「これ、うまくいっていないんじゃないですか」と伝える。すると「確かに考えが足りませんでした、修正用のタスクを出します」と返ってきて、意図のほうを正しく保ったまま、修正が新しいタスクとして積み上がっていきます。
「Grill Me」との共通点
最近、Matt Pocock さんが公開して話題になった「Grill Me」という Claude Code 向けのスキルがあります。見てみると、Intent CLI でやろうとしていることとかなり近いものでした。
Grill Me は、機能を作り始める前に Claude Code を「インタビューモード」に切り替え、設計上の決定を一つずつ質問していくスキルです。ポイントは、作りたいものを一つのプロンプトとしてではなく、決定の木（design tree）として扱い、上流の選択を解決してから下流へ進むこと。質問のたびに、コードベースを調べたうえで「おすすめの答え」も一緒に提示してくれます。AIコーディングの失敗の多くは「モデルがコードを書けない」からではなく「要件が詰められていない」から起きる、という課題に正面から向き合うスキルです。
決定を木として扱い、選択肢に推奨を添えて一つずつ確認していく。この進め方は、Intent CLI のインタビューや intent-tree とかなり近い発想です。
Grill Me については、ムーザルちゃんねるの回でも詳しく議論されていて、参考になりました。
その上で、Intent CLI は一歩先まで踏み込みます。Grill Me が「一つの機能を作る前の要件詰め」にフォーカスしているのに対し、Intent CLI は固めた意図をプロジェクト全体のメタデータとして残し続け、どのタスクが終わっていて、いまどのタスクを扱っているのか、までを管理します。前さばきだけでなく、その後の運用ループまで回すわけです。ただ、根っこの方針はとても近い。まず人間がどうしたいかをしっかり聞いてまとめ、それを構造化する、というところは同じです。
この方針は、理にかなっていると感じています。先ほど「開発会社のマネージャーと話す感覚」と書きましたが、これは偶然ではありません。信頼している開発者や開発会社には、細かく口を出さず「何をしたいか」をブリーフしますよね。AIのスキルが上がるほど、同じことが言えると思います。一つひとつの実装をマイクロマネジメントするより、しっかり伝わる意図をまとめて渡すほうが、良い結果になる。Intent CLI は、その「意図を渡す」を構造的にやりやすくするための道具です。
Intent CLI は、人間とAIのあいだの共通言語になっています。
設計・実装・レビューが回るループ機構
Intent CLI のいちばんの強みは、意図駆動開発を、設計・実装・レビューのループ機構として回るように設計していることです。ただ意図をまとめるだけでは終わりません。
具体的にはこうです。意図のツリーからタスクを作り、そのタスクを GitHub の Issue として切り出します。実装スレッドがそれを実装してPRにし、レビュースレッドが「意図ツリーのとおりに作られているか」を照らし合わせてレビューする。ずれていれば変更依頼を出し、実装スレッドが直す。よければマージして、次のタスクがあれば、それをまた次の Issue として切り出します。
この 意図 → タスク → Issue → 実装 → レビュー → 修正 → マージ → 次の Issue という開発ループが、状態をしっかり管理できるCLI（メタデータ管理）によって回り続けます。意図をまとめる入口だけでなく、意図から実装・レビュー・マージまでをつなぐ「開発プロセス」そのものとして作られている。ここで、Intent CLI は単なる「意図を整理するツール」ではなく、開発プロセスを回すための道具になります。
本番運用の現状
これは構想だけの話ではありません。社内ではすでに複数のプロジェクトで本番運用していて、AIによる実装とレビューのループを継続的に回しています。あるプロジェクトでは、Issue と PR を合わせて1000近くを積み上げてきました。
正直に書くと、夢のように間違いのないものができるわけではありません。バグは起きます。だから定期的に、人間がコードの方針をレビューし、動作を確認し、AIエージェントにも動作確認をさせています。意図どおりに実装されていなければ、意図を補強して直すか、「意図が実装されていない」というバグとして報告する。そうした調整を経て進んでいきます。できるだけ問題の起きにくい Issue になるよう最善を尽くしますが、完全に問題がないわけではない、というのが実感です。
それでも、開発プロセスとして、良いアウトプットを出す助けになっていると感じています。「思った通りに作れているか」を、いつでも意図にさかのぼって確認できる ── この状態には、これまでになかった安心感があります。
向いていないケース
万能だとは思っていません。使い捨てのスクリプトや、一人で作る小さなプロトタイプには、Intent CLI はオーバーキルです。意図を構造化する手間のほうが大きくなってしまう。
これが効くのは、ある程度の期間、複数の人やAIが関わって、意図がぶれると困るような開発です。私たちが日々やっているのは、まさにそういう仕事でした。
オープンソース公開
このたび、Intent CLI を OSS（Apache-2.0）として公開しました。
公開リポジトリはこちらです。
すぐに触れるように、NuGet 経由の .NET グローバルツール（dotnet tool install -g JTechJapan.IntentSystem.Cli）として配布しています。具体的な手順は実践編にまとめました。
将来的には、意図のツリーをプロジェクトを越えて再利用できる小さなエコシステムにしたいと思っています。npmパッケージやHelmチャートのように、あるプロジェクトで育てた意図を別のプロジェクトから参照できる。意図が「そのプロジェクト限りのドキュメント」ではなく「再利用できる知識の単位」になる、という世界です。
まずは触ってみてください。次の実践編では、インストールから「3つのAIを並走させて自律開発する」ところまで、実際の手順を追っていきます。
質問や相談は、J-Tech JAPAN OSS Discord でも受け付けています。意図駆動開発や Intent CLI について、ぜひ気軽に声をかけてください。
Discussion