プロジェクトを増やしすぎて方向性を見失ったので、「方向性を相談するプロジェクト」を立てた話

この記事は「AI エージェント基盤」シリーズの一篇です。Claude が書いています（題材は筆者自身のプロジェクト運営の実話）。

手を広げすぎて、方向性を見失った

正直に書くと、収拾がつかなくなっていた。

エージェント基盤のパイプライン、Web3 の仕組み、マンガ、動画制作、サイト、SNS——AI と一緒なら何でも作れてしまうので、思いついた端からプロジェクトが増えていった。一つひとつは前に進む。でも全体としてどこへ向かっているのかが、だんだん分からなくなる。

面白いのは、個別のプロジェクトでは AI はちゃんと頼れる相談相手だったことだ。「このパイプラインのここをどう設計する？」「このマンガの構成は？」——その単位では的確な答えが返ってくる。詰まらない。

詰まっていたのは、もっと上の層だった。「で、全部まとめてどっちに進むべきなんだっけ？」という問いに、答えてくれる相手がいなかった。各プロジェクトは自分の目的には答えるが、プロジェクト群の方向性は誰の担当でもない。

そこである日、思いついて 「全体の方向性を相談するためだけのプロジェクト」 を立てた。コードは書かない。ただ、何を・なぜ・どの順でやるかだけを決める司令部。総司令部、という意味で GHQ と呼んでいる。

すると、バラバラだったプロジェクトが、ひとつの意思をもってまとまりだした。

各プロジェクトの「個別の相談相手」は元から機能していた。足りなかったのは、その上で全部を束ねる一本の intent。GHQ はそれを供給する場所として刺さった。

賢さは何も足していない。同じモデル、同じツール。足したのは「方向性を明示する場所」だけ。これが今日の話の全部なのだが、なぜこれが効いたのかを、最近よく聞く言葉で説明できることに気づいた。

効かなかったのは intelligence ではなく intent

Intent Engineering という言葉がある（まだ業界で固まりきってはいない新しめの言葉なので、その前提で読んでほしい）。乱暴に要約すると——

核心命題: Agent が失敗するのは推論能力（intelligence）の不足ではなく、intent（意図）の過少指定（underspecification） のせい。処方箋は「指示を増やす」ことではなく「intent を明示化する」こと。

intent を明示しないと、Agent は——人間も同じだが——口に出したこともない何かを勝手に最適化し始める。モデルはもう十分に賢い。本番で動く Agent と、静かにズレていく Agent を分けるのは、intelligence ではなく intent だ。

これは、さっきの実話そのものだった。私のプロジェクト群が発散したのは、各 AI が馬鹿だったからではない。ポートフォリオ層の intent が過少指定だったからだ。個別タスクの意図は各プロジェクトで満たせても、横断する「目的」と「北極星」が無ければ、全体は当然のように散らばる。

GHQ がやったのは、そのメタな intent を外に書き出して供給することだけ。だから「賢さは変えていないのに、intent を明示化したらまとまった」。

intent は「書くだけ」では足りない——7つの要素

ここで大事なのは、「intent を書け」では雑すぎるということだ。「ちゃんと意図を伝えよう」で済むなら誰も苦労しない。Intent Engineering の文脈で共有されつつあるのは、intent が次の 7要素 で構成されるという分解だ。

1. Objective — 問題と、なぜそれをやるのか。指示が尽きた局面での判断基準になる。
2. Desired Outcomes — ユーザ視点で観察可能な成功状態。遅行指標ではなく。
3. Health Metrics — 最適化の最中に劣化させてはならない指標（Goodhart 対策）。
4. Strategic Context — システム・戦略・他の Agent の中での位置。全部をプロンプトに入れる必要はない。
5. Constraints — Steering（コンテキスト窓で誘導する）と Hard（アーキテクチャで強制する）の2層。
6. Decision Types & Autonomy — Full → Guarded → Proposal-first → Human-required の4階層を、blast radius（影響範囲）と reversibility（可逆性） で割り当てる。
7. Stop Rules — 停止・エスカレーション・完了の境界。提案ではなく、実行の境界線。

そして設計原則がひとつ。二層アーキテクチャ——Reasoning layer（推論）が「提案」し、Orchestration layer（オーケストレーション）が「強制」する。制約が重要なら enforce する。リスクのある判断なら gate する。失敗が高くつくなら、出荷の前に stop rule を定義しておく。

余談だが、この「推論が提案し、オーケストレーションが型で強制する」を、コードレベルで見事にやっている実例が Anthropic の公開エージェントにある。別記事「純正のバーティカルエージェントを分解したら、5層の防御がぜんぶ型で塞がれていた」で、ハンドオフを閉じたスキーマで縛る設計を読んでいる。原則は同じだ。

7要素を「組織運営」の単位で実装してみる

ここからが、私が実際にやったことだ。Intent Engineering はふつう「1プロンプト／1エージェント」に対して語られる。それを 複数プロジェクトの運営 という単位に引き上げると、7要素は運営の道具立てにそのまま対応した。

Intent の7要素	運営での実装
1. Objective	各タスク（Issue）に「意図」を必ず書く ＋ 全体を貫く 北極星。指示が尽きたら「北極星に照らして決める」
2. Desired Outcomes	Issue の Definition of Done（観察可能な完了条件）
3. Health Metrics	自分に課した規律（対外発信は1日1件／人間が判断するのは1日3件まで／サポート義務を生むリリースはしない）。スピードを出すために劣化させてはいけないもの
4. Strategic Context	「このリポジトリは何のための場所か」をグローバル設定で伝える対応表。個々のリポジトリには書かない
5. Constraints	Steering＝設定ファイル（CLAUDE.md / rules）で誘導／ Hard＝hooks や「外部公開は人間承認」でアーキ的に強制
6. Decision & Autonomy	自律ループ（ralph-loop / マルチモデル生成）は Full〜Guarded、文章の起草は Proposal-first、対外アクション（公開・申請・投稿・マージ）は Human-required。まさに blast radius と reversibility で割り当てる
7. Stop Rules	「人間の判断待ち」ラベル ＋ 撤退ライン ＋ 自律ループの上限（最大反復・コスト上限・タイムアウト）＝歯止め。完了境界は DoD

ポイントは、この表の右側はどれも特別な道具ではないということ。Issue、DoD、設定ファイル、承認ゲート、撤退ライン——運営をやっていれば自然に持つものだ。Intent Engineering は、それらが「実は intent の構成要素だった」と教えてくれる補助線になる。

全体は4層で積み上がっている

司令部を置いてから、自分の作業フロー全体がきれいに4層で見えるようになった。下が「手を動かす」、上が「意図を定める」だ。

• ① プロトタイピング — 対話的なセッションで試行錯誤（いわゆるバイブコーディング）。分〜時間。
• ② 作業（グラインド） — 反復実装やテスト通しを自動ループに委任。時間〜日。
• ③ プロダクト開発計画 — 1プロジェクトを意図駆動で循環させる。日〜週。
• ④ 複数プロジェクト統括 — 目標達成・優先順位・帯域配分。司令部（GHQ）。

下2層（青灰）は how の自動化、上2層（青）は 意図のガバナンス。上にいくほど、人間の関与は「キーを叩く」から「意図を宣言する」へ移っていく。Intent Engineering の重心移動が、そのまま縦軸になっている。

まとめ

• 発散の原因は、AI の賢さ不足ではなく、横断する intent の過少指定だった。
• intent は「書くだけ」では足りない。Objective / Outcomes / Health Metrics / Context / Constraints / Autonomy / Stop Rules の7要素で明示する。
• それを1プロンプトでなく運営の単位でやると、Issue・DoD・規律・設定ファイル・承認ゲート・撤退ラインというありふれた道具が、そのまま intent の構成要素になる。
• やったのは、賢いモデルを足すことではなく、意図を置く場所をつくることだけ。

実は今、この運営方法そのものを5つのプロジェクトで走らせている最中だ。うまくいったのか、どこで転んだのかは、もう少し回してから別記事で書こうと思う。