e3d-pilot

e3d-pilot

複数モデルによる問題解決：個別に回答 → 批評 → 合意形成 → 人間による判断 → 実行 → レビュー → プロベナンス。

e3d-pilotは、単一モデルの回答を信頼するのではなく、複数のAIモデルに同じ問題へ取り組ませるオープンソースのシステムです。単発の質問から、人間の承認を経て完全に実行されるソフトウェア変更まで対応します。

まずは簡単に始められます。設定済みの複数のモデル（Claude、Codex、Grok、Devin、または自分で接続したモデル）に同じ質問をします。それぞれが独立して回答する様子を確認し、互いの立場を批評させ、修正させ、実際の異論を明らかにし、最も優れた回答へと収束させます。これが bin/e3d-debate です。リポジトリやパイプラインは不要な、単独で使えるツールです。MCP サーバーとしてエディター内でも利用できます。GitHub Copilot、Claude Code、Cursorから使用するには、npx の1行を設定するだけです。

さらにe3d-pilotは、このアプローチを実際のソフトウェア開発へと広げます：discover → ideate → approve → draft → negotiate → execute → review → publish → outcome。すべてのステップは追記専用の台帳に保存されるため、システム（または人間、あるいは新しいAIセッション）が後から、アイデアの発生源、それに影響を与えたモデルや人々、生み出された成果、その後に起きたことを再構成できます。

60秒でe3d-debateを試す

git clone https://github.com/spacepacket1/e3d-pilot.git
cd e3d-pilot

bin/e3d-debate \
  "Should e3d-pilot's provenance data be a graph, or is that over-engineering?" \
  --providers claude,codex --rounds 3

（lib/providers/<name> アダプターならどれでも参加できます。設定済みであれば、devin／grok-build／その他を追加してください。これを試す人の多くがすでに利用できるのは、claude／codex の2つです。）

ラウンド1では、すべてのプロバイダーが独立して回答します。ラウンド2以降では、各プロバイダーが他の参加者の前ラウンドでの立場を確認し、擁護、修正、反論、または譲歩を行います。実際に合意に達した場合は、議論が早期に終了します。その後、統合役が議論の全文を読み、最終回答、合意事項、残る異論を報告します。

この質問は仮定の話ではありません。実際にこの方法で議論を行いました。これは議論の全文を短くまとめたものです：

QUESTION
Should the E3D 3D graph generalize into a standalone product, or should
e3d-pilot instrument its own provenance instead?

CLAUDE (round 3, the only one to formally reach "approved")
Don't create e3d-graph yet — build a confidence-annotated, domain-neutral
provenance emitter inside e3d-pilot, prove attribution questions are
answerable from the data alone, add a 2D lens only if they are, and extract
a public repo only on external pull or paid demand.

CODEX (round 3)
Build outcome-linked Pilot provenance first, then open-source a narrow
standalone viewer only if measured workflow value and external pull
justify extraction.

DEVIN (round 3)
Instrument Pilot with a domain-neutral provenance schema from day one; gate
public extraction on the internal experiment succeeding, not on indefinite
deferral.

GROK-BUILD (round 3)
Do not ship standalone e3d-graph; instrument Pilot provenance first and
treat visualization as a 2D lens inside E3D.

SYNTHESIS
Do not ship a standalone e3d-graph product. Instrument e3d-pilot now with
an append-only, domain-neutral, confidence-annotated provenance schema —
the ledger stays canonical, the graph is an index, not memory. Validate by
answering real attribution questions from the data alone before any UI.

DISSENT (reported, not hidden)
Devin and partly Codex would gate public extraction on the internal
experiment succeeding; Claude and Grok-build require external pull or paid
demand instead — a real, named disagreement the tool didn't paper over.

**その後に起きたこと：**まさにこの内容を構築し、このリポジトリ自体の履歴にある3つの実際のアイデアを使って実行しました。いずれも「生の台帳を手作業で読むより有用」という結果になり、そのうち1つは提案元の仕様書にある実際の誤りを発見しました。その後、グラフインテリジェンスに関するクエリも同じように率直に評価しました。明確な成果が1つあり、実データがまだまばらだったため「シグナルなし」と明記したものが2つありました。結果は誇張せず、そのまま報告しています。この一連の経緯（仕様書、実際に使った結果、正直な失敗）は、docs/provenance-graph-experiment.md と docs/graph-intelligence-experiment.md に記載されています。

**実験段階：プロベナンスグラフ。**e3d-pilotは、変更不可能な独自のイベント台帳から、アイデア、関係者、モデル、判断、リポジトリ、コミット、エビデンス、成果などの構造的な関係を導出するようになりました。このグラフから、生の台帳だけでは見つけるのが本当に難しいパターンを明らかにできるかを検証しています。すでにできると主張しているわけではありません。

e3d-debate を単独で使うのに、e3d-pilotのほかの機能は必要ありません。フラグの全リファレンスについては、以下のe3d-debateを参照してください。議論の回答を、リリース済みでレビュー済み、プロベナンスが追跡された変更にまでつなげる機能については、この先をお読みください。

GitHub Copilot、Claude Code、Cursor から e3d-pilot を使う（MCP）

e3d-mcp は、依存関係のない Model Context Protocol サーバーです。AI コーディングアシスタントが、タスクの途中で複数のモデルにセカンドオピニオンを求められるため、1 つのモデルが出した最初の回答にそのまま決めてしまうことを避けられます。npm では e3d-pilot として公開され、公式 MCP レジストリには io.github.spacepacket1/e3d-pilot として登録されています。

ツール	機能
e3d_debate	複数の独立したモデルが回答し、統合役のモデルが、明確な結論、合意レベル（full / majority / split）、名前付きの異論があればその内容、各モデルの最終的な立場を、読みやすいテキストと構造化データ（dissent.present、dissent.summary、positions）の両方で返します。mode: "quick"（デフォルト）は 1 ラウンドで、数秒で完了します。mode: "thorough" では、モデル同士が反論する批評ラウンドが追加されます。全文の記録はオプションです（include_transcript）。
e3d_list_providers	このマシンで利用できるモデルプロバイダーを表示します。ディベートには少なくとも 2 つ必要です。
e3d_provenance_trace	読み取り専用：変更が生まれた経緯から、ディベート、承認、実行、レビュー、結果までを追跡します。
e3d_ideas_list	読み取り専用：リポジトリ内で e3d-pilot が追跡しているアイデアを一覧表示し、トレース用の ID を探せるようにします。

quick モード（11 秒、2 つのモデル）で、小さな CLI のデフォルトをフラットな JSON ファイルにするか SQLite にするかを尋ねた際の実際の結果です。

FINAL ANSWER: Default to a flat JSON file for a small CLI. It has no dependencies, is
human-readable and diffable, and is easy to hand-edit and debug. Write it atomically
(temp file, then rename). Move to SQLite once you need indexed queries, concurrent
writers, or data beyond a few MB.
CONSENSUS: split
DISSENT: Codex prefers SQLite as the default for any persistent mutable state because
it gives transactions, concurrency safety, and schema evolution at low cost.

意見の相違こそが重要です。1 つのモデルの自信満々な推測ではなく、回答と、それに対する最も強力な反論が得られます。

インストール

VS Code（GitHub Copilot エージェントモード）： ワンクリックでインストール、または .vscode/mcp.json に次の内容を追加します。

{
  "servers": {
    "e3d-pilot": { "type": "stdio", "command": "npx", "args": ["-y", "--no-update-notifier", "-p", "e3d-pilot", "e3d-mcp"] }
  }
}

Claude Code：

claude mcp add e3d-pilot -- npx -y --no-update-notifier -p e3d-pilot e3d-mcp

Cursor（~/.cursor/mcp.json）および mcpServers 形式を使うその他のクライアント：

{ "mcpServers": { "e3d-pilot": { "command": "npx", "args": ["-y", "--no-update-notifier", "-p", "e3d-pilot", "e3d-mcp"] } } }

stdio サーバーを起動できる MCP クライアントであれば動作するはずです。上記の設定形式は、それぞれのクライアントの標準形式です。

前提条件： Node 18 以降、jq、bash 4 以降（macOS には 3.2 が付属しています：brew install bash jq）、ログイン済みのモデル CLI が少なくとも 2 つ（例：claude と codex）。まとめて確認するには、次を実行します。

npx -y -p e3d-pilot e3d-mcp --doctor

--doctor は不足しているものと、その解決方法を報告します。フルパイプラインの e3d-code エグゼキューターは必要ありません（インストールされているかどうかを確認するだけです）。クローンしたリポジトリからは、bin/e3d-mcp --print-config --local を実行すると、チェックアウト先を指す設定が出力されます。

使い方

Copilot エージェントモード（または任意のクライアント）で、次のように尋ねます。「ストレージレイヤーを選ぶ前に、この CLI の SQLite とフラットな JSON を e3d_debate で比較してください。」 議論の余地がある設計上の選択について、アシスタントが明示的な指示なしでこれを実行するようにするには、examples/copilot-instructions.md を .github/copilot-instructions.md または AGENTS.md にコピーしてください。単純な検索や、明白な答えがある質問には使わないでください。時間がかかり、費用も発生します。

費用と制限

• quick ディベートは数秒から 1 分、thorough ディベートは数分かかります。どちらもお使いのモデルのクレジットを消費します。サーバーは E3D_MCP_MAX_ROUNDS（3）、E3D_MCP_MAX_PROVIDERS（4）、E3D_MCP_MAX_CONCURRENT（2）、E3D_MCP_TIMEOUT_SEC（900）で e3d_debate を制限します。
• サーバーの環境にあるプロバイダー CLI とキーを使用します（e3d-pilot providers list を参照）。
• Copilot の コーディングエージェント は GitHub ホストのランナー上で動作し、そこにはプロバイダー CLI がインストールされていません。現時点では、上記のローカル（stdio）設定を使用してください。

ディベートでのウェブ検索

すべてのディベートプロンプトには、その日の UTC 日付が記載されています。API プロバイダー（anthropic-api、openai-api、gemini-api、xai-api）は、ディベートの各ラウンドで各ベンダー独自のウェブ検索ツールも使用できます。これはデフォルトで有効で、その場合、質問文が検索プロバイダーに送信されることがあります。CLI の発言者、MCP サンプリングの発言者、統合役は検索を行いません。ウェブアクセスはできないと伝えられています。1 回のディベートで検索を無効にするには、e3d_debate または e3d_debate_start に web_search: false を渡すか、e3d-debate に --web-search off を渡してください。検索結果は信頼できないデータとして扱われます。各ベンダーが許可することと、残るリスクについては docs/web-search-providers.md を、結果の形式については docs/web-search-interface.md を参照してください。

変数	デフォルト	効果
E3D_DEBATE_WEB_SEARCH	on	off は緊急停止スイッチです。コードを変更せずに、あらゆる場所で検索を無効にできます。それ以外の値でも検索は無効になります。
E3D_DEBATE_WEB_SEARCH_PROVIDERS	anthropic-api,openai-api,gemini-api,xai-api	検索を許可するプロバイダーです。この 4 つ以外の名前は無視されます。
E3D_DEBATE_SEARCH_MAX_PER_CALL	3 (1-10)	モデル呼び出し 1 回あたりの検索上限です。Anthropic と OpenAI ではネイティブに設定され、xAI では利用可能な最も近い制御方法です。すべてのベンダーについて事後確認が行われ、上限を超えたベンダーには ALARM が発生します。
E3D_DEBATE_SEARCH_MAX_CITATIONS	8 (1-20)	呼び出しごとに保持する引用の上限です。超過分の引用は破棄され、その数が記録されます。
E3D_DEBATE_SEARCH_EXCERPT_CHARS	150 (0-300)	引用から保持する抜粋の文字数上限です。0 の場合、抜粋は保持されません。
E3D_DEBATE_SEARCH_ALLOW_DOMAINS	empty	ドメインのみ（example.com）をカンマ区切りで指定します。ベンダーが対応している場合はネイティブに適用され、すべての環境で事後フィルターされます。ベンダーがリストを 1 つしか受け付けない場合は、こちらが優先されます。
E3D_DEBATE_SEARCH_DENY_DOMAINS	empty	ドメインのみをカンマ区切りで指定します。可能な場合はネイティブに適用され、すべての環境で事後フィルターされます。
E3D_DEBATE_SEARCH_TIMEOUT_SEC	derived	1 回の検索呼び出しに対する実時間の制限です。デフォルトでは、ディベートのタイムアウトを（2 x ラウンド数 + 1）で割った値（最低 10 s）です。ディベートのタイムアウトが設定されていない場合は 120 s です。
E3D_MCP_DAILY_SEARCHES	0 (unlimited)	プリンシパルごとのウェブ検索の日次上限です。ディベートを実行する前に、最悪のケース（上限 x 検索を行う呼び出し回数）に相当する枠が確保されます。
GEMINI_API_NATIVE_BASE_URL	https://generativelanguage.googleapis.com/v1beta	Gemini の Interactions API のエンドポイントです。Gemini が検索する場合にのみ使用されます。
OPENAI_API_SEARCH_CONTEXT_SIZE	low	OpenAI の検索ツールに指定する search_context_size です。
ANTHROPIC_API_MAX_PAUSE_CONTINUATIONS	2 (0-5)	検索呼び出しで許可する pause_turn の継続回数です。これを超えると、フェイルクローズで失敗します。

検索呼び出しが失敗した場合、タイムアウトした場合、検索以外のツールを使用した場合、またはベンダーで検索が無効になっている場合、そのモデルには検索なしで再度問い合わせが行われ、回答にはその旨（「ウェブ検索を利用できませんでした……」）が記載されます。また、検索できたモデルの数（「M モデル中 N モデルで有効」）も回答に示されます。

• e3d_debate と読み取り専用ツールは、リポジトリに書き込みません。以下のパイプラインツールは、個人が実行する場合と同じ制限付き CLI パスのみを通じて書き込みを行います。また、e3d_pilot_propose はリポジトリの .e3d-pilot/ 台帳に書き込みます。

エディターからパイプラインを実行する

ステータス（0.2.0）： パイプラインツールとサンプリングのデフォルト設定は新機能です。スクリプト化された MCP クライアントと偽のプロバイダーを使ったテストは行われていますが、実際の VS Code Copilot セッション内ではまだ検証されていません。E3D_MCP_ALLOW_APPROVAL=1 を設定しない限り、エディターからの承認は無効です。また、パイプラインツールが操作するのは、許可したリポジトリのみです。

ディベートに加えて、e3d-mcp は人間の承認が必要なパイプラインを実行できるため、アシスタントはエディターを離れずに、意思決定からドラフト PR の作成まで進められます。ツールは個人が実行する場合と同じ CLI コードパスを呼び出します。ステージを再実装したり、ゲートを弱めたりすることはありません。

ツール	費用	内容
e3d_pilot_config_check	無料	.e3d-pilot/config.json を検証し、e3d-code（コード作成用エグゼキューター）がインストールされているかどうかを報告します。
e3d_pilot_propose	無料	リポジトリの台帳にアイデアを記録します。任意で、出所を示す証拠として e3d_debate の結果を添付できます。
e3d_pilot_start	クレジットを消費	discover または ideate をバックグラウンドジョブとして開始します。（all は提供していません。プランのプレビュー範囲を超えて実行されるためです。）
e3d_pilot_job_status	無料	ジョブの状態、到達したステージ、成果物、ログの末尾を表示します。ジョブは .e3d-pilot/mcp-jobs/ 配下のディスクに保存され、サーバーを再起動しても保持されます。wait_seconds を指定すると、ジョブが落ち着くまで待機します。
e3d_pilot_approve	ゲート	人間によるゲート 1。 デフォルトでは読み取り専用で、waiting_for_human と実行すべき正確なコマンドを返します（信頼モデルを参照）。
e3d_pilot_reject	ゲート	提案されたアイデアを却下します。エディターで確認するか、正確な confirm_phrase を指定します。
e3d_pilot_implement	クレジットを消費	承認済みのアイデアについて、仕様書を作成してレビュアーに交渉させた後、コードを書く前に一時停止します。
e3d_pilot_code_plan	無料	execute で何が行われるかを表示します。各フェーズ、ランナーとモデル、変更対象のファイル、検証コマンド、事前チェックの結果を示し、plan_token を返します。
e3d_pilot_execute	クレジットを消費してコードを書き込み	その仕様書に対する新しい plan_token が必要です。専用ブランチの分離されたワークツリーにコードを書き込み、検証とレビューを行い、ドラフト PR を作成します。
e3d_pilot_cancel_paused	無料	一時停止中の実装を中止します（理由を記録し、失敗した試行として残します）。
e3d_pilot_request_changes	ゲート	ドラフト PR の作成後に、アイデアを修正のために差し戻します。
e3d_pilot_artifact	無料	固定リストに含まれる実行成果物（仕様書、交渉ログ、レビュー、e3d-code マニフェストのフェーズごとの結果）を 1 つ読み取ります。サイズ制限があり、機密情報はマスキングされます。

Copilot エージェントモードでの実行例

1. 「ローカル永続化が必要です。JSON と SQLite について e3d_debate を実行してください。」 判定結果と異論が返されます。
2. 「議論の結果を根拠として添付して、アイデアとして提案してください。」 e3d_pilot_propose が proposed として記録します。
3. (任意) e3d_pilot_start で discover、続いて ideate を実行し、パイプラインにリポジトリ自体のアイデアを見つけさせます。
4. あなたが承認します（以下を参照）。それまでは何も作成も書き込みもされません。
5. 「実装してください。」 e3d_pilot_implement が段階的な仕様書を作成して交渉し、その後一時停止します。e3d_pilot_job_status で状況を確認します。
6. 「計画を見せてください。」 e3d_pilot_code_plan が各フェーズのモデル、変更対象のファイル、検証コマンドを一覧表示します。
7. 問題なければ e3d_pilot_execute を実行します。問題があれば e3d_pilot_cancel_paused を実行します。実行が完了すると、担当者がレビューするためのドラフト PR が作成されます。
8. MCP 経由でのマージはできません。 approve-merge と merge は意図的に CLI 専用としており、最後のゲートでは必ずターミナルまたは Web UI で担当者が操作します。

信頼モデル

• Gate 1 は人が判断します。 e3d_pilot_approve はデフォルトでは承認しません。サーバーオペレーターが E3D_MCP_ALLOW_APPROVAL=1 に設定し、さらにエディターが MCP のエリシテーションに対応している場合、エディター独自のプロンプトで人に確認を求めます。エージェントが代わりにそのプロンプトに回答することはできません。どちらか一方でも満たされない場合は、実行するコマンド（e3d-pilot ideas approve ...）を返します。または、ウェブダッシュボードを使用できます。
• confirm_phrase だけでは事故を防ぐにすぎません（エージェントはエラーメッセージから読み取れるため）。そのため、承認の仕組みとしては使われていません。reject と request_changes は作業を止めるだけなので、この値を受け付けます。
• 承認は CLI 自体が強制します。 変更を伴うすべてのステージで、ステージ内でダイジェストに紐付いた承認を確認するため、ここにあるツールが承認を回避することはできません。
• リポジトリの許可リスト。 パイプラインツールが操作するのは、E3D_MCP_REPOS（: 区切りのリスト）、クライアントのワークスペースフォルダー、またはそのどちらもない場合はサーバーの起動元の Git リポジトリのみです。パスはシンボリックリンクをたどって解決され、Git リポジトリのトップレベルである必要があり、範囲外のパスは拒否されます。（元からある 4 つのツールはこれより前に導入されており、変更されていません。）
• コードは実行ごとのブランチにある別個のワークツリーに書き込まれます。 既存の protected_paths、max_diff_files／max_diff_lines の上限と、公開前の検証ルールが適用されます。作業中のツリーは変更されません。
• ログ、アーティファクト、エラーは秘密情報の検出・削除を経由します。

コストモデル

• ツールの説明には、FREE または SPEND MODEL CREDITS のどちらかが記載されています。code_plan が使用するのは e3d-code --list と --preflight のみで、どちらも何も書き込みません（マニフェストに「完了」フェーズを記録するため、--dry-run は意図的に避けています）。
• 上限：リポジトリごとに同時に実行できるジョブは 1 つ、リポジトリ間での E3D_MCP_MAX_JOBS（2）、E3D_MCP_JOB_TIMEOUT_SEC（3600）、E3D_MCP_MAX_PHASES（8）。プランのトークンは E3D_MCP_PLAN_TTL_SEC（1800）後に期限切れとなり、仕様またはリポジトリの HEAD が変わると無効になります。
• 1 日あたりまたはセッションあたりの支出上限も、コストのレポート機能もありません。上記の上限は予算ではなく、安全策として扱ってください。

デフォルトでは Copilot 独自のモデルを使用

クライアントが MCP の サンプリング に対応している場合（ドキュメントによると VS Code は対応しています）、e3d_debate はクライアント独自のモデル（Copilot）を 1 つまたは 2 つの発言者として使用し、マシン上で検出したモデル CLI（claude、codex、gemini、...）を追加します。2 つの CLI を要求することはありません。初回のリクエストでは、サーバーがモデルを使用することを許可するよう求められます。MCP: List Servers > Configure Model Access で使用するモデルを制限できます。結果には実際に回答したモデルが示され、すべての発言者が同じモデルに解決された場合は警告が表示されます（これは同じモデルが自分自身と議論している状態であり、ディベートではありません）。サンプリングを使用しない場合、デフォルトは従来どおり claude + codex です。E3D_MCP_PROVIDERS=claude,codex で固定するか、E3D_MCP_AUTO_VOICES で数を制限できます。サンプリングを使用すると Copilot の利用量を消費します。

サンプリングで回答できるのは、入力も出力もテキストのプロンプトのみです。そのため、ディベート、およびリポジトリの providers に mcp-sampling を指定した場合の negotiate と review の各ステージで使用できます。discover、ideate、draft、execute ではリポジトリの読み取りまたは編集が必要なため、引き続きモデル CLI が必要です。e3d_pilot_config_check はこの点について警告します。サンプリングプロバイダーを使用するジョブの実行中にエディターまたはサーバーが停止すると、そのジョブは失敗します。

VS Code で動作しない場合（組み込みの Copilot Chat を使用した VS Code 1.142 での実際の実行で確認済み）：

• 「Start」コードレンズに「e3d-pilot Error」だけが表示される場合があります。原因は VS Code のエージェントホストのログにあります。新しいビルドでは、チャットセッションが存在するまで MCP サーバーを起動しません（「Cannot start an MCP server before the session runtime has been created. Send a message first.」）。チャットを開いて任意のメッセージを送信してから、サーバーを起動または再起動してください。
• VS Code で一度限りの「migration」メッセージが表示され、.vscode/mcp.json が空になり、形式の異なる (mcpServers、type: local、tools: ["*"]) .mcp.json が書き込まれることがあります。サーバーが消えた場合は、VS Code がどのファイルを読み込んでいるか確認するか、e3d-mcp --print-config から .vscode/mcp.json を復元してください。ローカルの stdio サーバーでは、「Local」チャットセッションタイプも必要な場合があります。
• サーバーによるモデルの使用を許可する権限プロンプトが表示されるのは、e3d_list_providers（モデルを呼び出しません）ではなく、最初の ディベート 時です。
• e3d-mcp --doctor で、個別の Copilot 拡張機能が登録されていないと表示される場合があります。最近の VS Code ビルドには Copilot Chat が組み込まれているため、これは想定どおりです。
• 1日の予算は 00:00 UTC（夏時間中の太平洋時間で午後5時）にリセットされるため、「1日」の区切りはローカルの日付と異なる場合があります。e3d_usage で正確な resets_at を確認できます。
• 実装が一時停止されている間、アイデアの台帳ステータスは引き続き implementing です。ジョブは paused_before とともに waiting_for_human を報告します。e3d_pilot_cancel_paused または e3d_pilot_execute の実行後、ジョブは cancelled または resumed としてマークされます。
• 最初の idea_proposed イベントを含め、MCP 経由で作成された台帳エントリーは mcp:<client>（または E3D_MCP_ACTOR）に帰属し、チェックアウトを所有する人の git ID に帰属することはありません。<client> はエディターが通知する名前です。VS Code は Visual Studio Code と名乗りますが、Copilot のエージェントホストは copilot-cli と名乗るため、ここでのアクターは mcp:copilot-cli と表示されます。固定名を使いたい場合は E3D_MCP_ACTOR を設定してください。承認を辞退した場合は、アイデアのメモとして記録されます。
• VS Code 独自のツール呼び出し確認で辞退しても、サーバーには届かないため、何も記録できません。 記録されるのは、サーバーが表示する「このアイデアを承認しますか？」フォームだけです（メモとして記録）。このフォームで辞退した場合でも、VS Code には response=accept と記録されることがあります。そのため、違いを確認するにはアイデアの台帳メモが確実です。
• ディベートは実行前に最悪のケースを予約し、実際に使用した量に応じて精算します（ロックファイルで複数のサーバープロセスが同じカウンターを共有する場合の競合を防止するため、処理はアトミックです）。そのため、同時リクエストが同じ上限をすべて通過することはありません。
• パイプラインジョブの支出もカウントされます。 e3d_pilot_start、e3d_pilot_implement、e3d_pilot_execute は、開始前にモデル呼び出し回数とトークン数の推定値を1日の予算に対して予約します（discover/ideate の開始では設定済みプロバイダーごとに約2回、implement ではドラフターごとに1回と交渉レビュアーごとに2回、execute ではフェーズごとに3回、約200,000トークンです。E3D_MCP_EST_TOKENS_PER_PHASE で調整できます）。上限を超える予約が必要な場合はジョブを拒否し、何も記録しません。開始できないジョブの予約は返却されます。これらは推定値であり、実測値ではありません。
• 使用量カウンターはマシン全体で共有され、リポジトリごとではありません。プリンシパルごと（stdio 経由では local）に1つのファイルが ~/.e3d-pilot/usage/ の下に作成され、サーバーがアクセスするすべてのリポジトリで共有されます。e3d_usage でファイルパスを確認できます。1日の使用量をリセットするには、このファイルを削除してください。
• エディター独自のモデルが回答する場合（MCP サンプリング）、エディターが約3分でタイムアウトする前にサーバーがタイムアウトを報告できるよう、ディベートは150秒（E3D_MCP_SAMPLING_TIMEOUT_SEC）で停止します。実際に回答した呼び出しのみがカウントされます。判定前に停止したディベートには、実行されなかった統合呼び出しの料金は請求されません。
• 実装に失敗した場合、ジョブの failure_detail に実際の原因が示されます（例：draft-rejected.md: status: too-large ...）。保存されたジョブレコードには warnings リストも含まれます。キャンセル後のステータスには、ログが履歴であることが記載されます。
• e3d-mcp は MCP プロンプト（表示に対応しているエディターでは /e3d-debate、/e3d-propose、/e3d-budget）も提供し、サーバーは package.json 内のバージョンを報告します（開発ビルドでは 0.2.0-dev.N と報告されます）。
• リポジトリにツールの使用タイミングを記載しておくと、エージェントがより確実にツールへアクセスできます。docs/mcp-agent-instructions.md を .github/copilot-instructions.md または AGENTS.md にコピーしてください。
• ディベート結果でベンダーファミリーが報告されるようになりました。Copilot の Claude と claude CLI は同じファミリーとして数えられ、重複は warnings で通知されます。 | 変数 | デフォルト | 意味 | | --- | --- | --- | | E3D_MCP_REPOS | ワークスペースのルート | パイプラインツールが使用できる、: 区切りのリポジトリです。 | | E3D_MCP_ALLOW_APPROVAL | オフ | 1 にすると、ユーザーがエディターからエリシテーションを介して承認できるようになります。 | | E3D_MCP_ACTOR | mcp:<client> | MCP アクションについて台帳に記録されるアクター名です。 | | E3D_MCP_MAX_JOBS / E3D_MCP_JOB_TIMEOUT_SEC | 2 / 3600 | 同時実行ジョブ数、ジョブごとのタイムアウトです。 | | E3D_MCP_MAX_PHASES / E3D_MCP_PLAN_TTL_SEC | 8 / 1800 | 実行時のフェーズ上限、プランの有効期間です。 | | E3D_MCP_MAX_ARTIFACT_BYTES | 100000 | 読み取り可能なアーティファクトの最大サイズです。 | | E3D_MCP_SAMPLING_TIMEOUT_SEC | 150 | エディターのモデルを使用するディベートを、この時間が経過したら停止します。 | | E3D_MCP_EST_TOKENS_PER_PHASE | 200000 | e3d_pilot_execute の開始時に、コード作成フェーズごとに確保されるトークン数です。 | | E3D_MCP_PROVIDERS / E3D_MCP_AUTO_VOICES | 自動 / 3（サンプリングなしの場合は 2） | デフォルトのディベート参加モデルを固定するか、上限を設定します。 | | E3D_MCP_SAMPLING_HINTS | claude,gpt | 2 つのサンプリング用モデルのモデル名ヒントです。 |

mcp.json のサーバーの env に追加します。例："env": { "E3D_MCP_REPOS": "/Users/me/work/app" }。

ホスティング／リモートでの利用

e3d-mcp --http [--host H] [--port N] は、MCP のストリーミング可能な HTTP トランスポートを介して同じサーバーを提供します。また、deploy/Dockerfile はコンテナとしてパッケージ化するため、ローカルツールを実行できないクライアント（Copilot コーディングエージェントなど）でもディベートをリクエストできます。**デプロイは行われていません。**クラウドアカウントは使用されておらず、deploy/README.md の AWS と Azure に関する説明は未検証です。

• 費用の負担者： 呼び出し元ではなく、運用者のモデル認証情報（azure-openai、bedrock、anthropic-api、openai-api プロバイダーを介した Azure OpenAI、Bedrock、またはローカルエンドポイント）です。各ベアラートークン（E3D_MCP_AUTH_TOKENS="name:token"）は、1 日あたりの呼び出し数と推定トークン数の上限を持つ予算主体です。ディベートの開始前に上限が確認されます。これらの上限はトークンごとに適用され、全体には適用されません。また、1 つのインスタンス上のファイルに保存されます。
• HTTP 経由で無効になる機能とその理由： e3d_pilot_* パイプラインツール、来歴情報、アイデア一覧は、サーバーのディスク上のリポジトリに対して操作するため、デフォルトで非表示です。サンプリング、エリシテーション、ルートはサーバーからクライアントへのリクエストが必要なため無効になり、承認は読み取り専用のままです。ループバック以外のアドレスへのバインドでは、トークンがないと起動しません。また、TLS はリバースプロキシで処理することを想定しています。
• 使用状況の報告はローカルでも利用できます： e3d_debate の結果には usage（モデル呼び出し数と推定トークン数）および budget が含まれるようになりました。e3d_usage では本日の合計を確認でき、E3D_MCP_DAILY_CALLS / E3D_MCP_DAILY_EST_TOKENS で stdio モードでも任意の上限を設定できます（デフォルトでは無制限です）。

外部の認証・従量課金サービスを使ったホスティング

有料顧客向けに e3d-mcp --http をホスティングし、請求サービス（自社のもの）がキーと残高を管理する場合に使用してください。サーバーはそのサービスに呼び出し元の身元を問い合わせ（introspect）、ディベートの前にクレジットを確保し（reserve）、実際の処理内容を報告します（settle。何も実行されなかった場合は release）。この機能を使用しない場合は、静的な E3D_MCP_AUTH_TOKENS とローカルの日次上限が従来どおり機能します。ワイヤープロトコル、スキーマ、状態マシン、実装者向けチェックリストは docs/external-auth.md にあります。参照用スタブ（examples/external-auth-stub.js、本番用コードではありません）と適合性テストランナー（examples/external-auth-conformance.js）では、互換性のあるサービスの例とテストを確認できます。

STUB_SERVICE_TOKEN=<24+ chars> STUB_RESERVATION_TTL_SEC=2 node examples/external-auth-stub.js   # prints its loopback URL; the runner's expiry vector needs a short hold lifetime
node examples/external-auth-conformance.js <that URL> <token>          # run against any implementation

このフックは身元と支出を確認するものです。コード作成ツールを顧客に公開しても安全にするものではありません。 顧客に対しては、e3d_pilot_* パイプラインツールを無効にしておいてください。

変数	デフォルト	意味
E3D_MCP_AUTH_URL	unset	サービスのベース URL（https、またはループバック上の http）です。設定するとフックが有効になります。--http のみです。
E3D_MCP_AUTH_SERVICE_TOKEN	none	サービスに対するサーバー自身の認証情報（印字可能文字が 24 文字以上）です。
E3D_MCP_AUTH_SERVICE_TOKEN_FILE	none	同じ認証情報をファイルから読み込みます（モード 0600）。2 つのうちいずれか一方を設定し、両方は設定しないでください。
E3D_MCP_AUTH_CACHE_SEC	30	有効な introspect の応答をキャッシュする時間（1～300）です。これが失効までの最大遅延になります。
E3D_MCP_AUTH_MAX_INFLIGHT	32	同時に実行中となる、個別の introspect 呼び出しの数（1～1024）です。
E3D_MCP_AUTH_IP_PER_MIN	30	サービスへの問い合わせなしで以降の不明なキーを拒否するまでに、1 つの IP アドレスから 1 分間に提示できる、拒否対象（不明または形式不正）のキー数です。有効なキーはカウントされません。
E3D_MCP_AUTH_HEALTH_SEC	15	/readyz の背後で実行されるバックグラウンド health プローブの間隔です。
E3D_MCP_OUTBOX_MAX	5000	新たな課金対象の処理を拒否するまでに許容される、未配信の決済処理数です。
E3D_MCP_OUTBOX_MAX_BYTES	67108864 (64 MB)	新たな課金対象の処理を拒否するまでに許容される、未配信レコード（最終確定レコードには議論の結果が含まれます）の合計サイズです。
E3D_MCP_ORPHAN_MAX_AGE_SEC	21600 (正の整数の秒数。これ以外の場合は起動を拒否)	プロセス ID が有効に見える場合でも、未完了の議論の計量インテントを照合するまでの経過時間です（クラッシュ後に PID が再利用されることがあります）。
E3D_MCP_TRUST_PROXY_HOPS	0	サーバーの前段にある信頼済みリバースプロキシの数です。N を設定すると、失敗キーのレート制限では、プロキシのアドレスの代わりに X-Forwarded-For の右から N 番目のエントリをクライアントアドレスとして使用します。0 の場合はヘッダーを無視します。
E3D_MCP_AUTH_KNOWN_ACTIVE_MAX	10000	失敗キーのレート制限で記憶する、最近アクティブだったキーの数です（最も古いものから削除されます）。
E3D_MCP_OUTBOX_MAX_DEAD	1	新たな課金対象の処理を拒否するまでに許容される、デッドレター化された決済処理数です。--outbox-status と --outbox-retry-dead で再試行または解決してください。
E3D_MCP_OUTBOX_CLAIM_SEC	300	これを超えて古い配信クレームは、クラッシュしたプロセスのものとみなされ、再試行されます。
E3D_MCP_ORPHAN_POLICY	charge	サーバーのクラッシュ時に実行中だった議論について、再起動時にどのように課金するかを指定します。charge（予約済みユニットを課金し、結果は orphaned）または release です。議論の開始前（予約済みで、モデルはまだ呼び出されていない）のクラッシュでは、常に保留分を解放します。

• フェイルクローズです。 サービスに到達できない場合、または不正な応答があった場合、リクエストは拒否され（HTTP 503 retry-after: 5、非アクティブなキーの場合は 401）、モデルは実行されません。配信できない決済処理は状態ディレクトリ内の永続的なアウトボックスに書き込まれて再試行されます。処理が破棄されることはありません。
• ローカル上限は第 2 の上限として維持されます。 E3D_MCP_DAILY_CALLS、E3D_MCP_DAILY_EST_TOKENS、およびレート制限は引き続きプリンシパルごとに適用されるため、課金上の障害によって支出が無制限になることはありません。
• 運用者向けコマンド（記録 ID、呼び出し名、経過時間、件数のみを出力します）：e3d-mcp --outbox-status、e3d-mcp --outbox-export <file>（新規ファイル、モード 0600。照合用に、ペイロードを含む保留中およびデッドレターのレコードをエクスポートします。トークンは含みません）、e3d-mcp --outbox-retry-dead <record_id>（デッドレターのレコード 1 件を保留中に戻します。ID の完全一致が必要です。変更を行う唯一のコマンドです）。e3d-mcp --doctor と e3d_usage は、フック、ヘルス状態、アウトボックスの件数を報告します。サービスまたはアウトボックスが正常でない場合、/readyz は 503 を返します。
• デッドレターとサービス停止時の手順：docs/external-auth.md のランブック。

非同期ディベート（今すぐ開始し、後で結果を取得）

ディベートには数分かかることがありますが、多くのクライアントはそれよりずっと前にツール呼び出しの待機を打ち切ります（Claude Codeでは約1分後です）。サービスが introspect の応答で finalize と fetch の両方を通知する場合（Debate contract v1、docs/external-auth.md）、顧客はさらに3つのツールを利用できます。

• e3d_debate_start はディベートを開始し、すぐに debate_id を返します。e3d_debate と同じ引数を受け取りますが、ラウンド数と回答あたりの単語数は拒否されず、顧客の上限（E3D_MCP_CUSTOMER_LIMITS）まで引き下げられます。プロバイダーのリストが長すぎる場合は拒否されます（何も予約されません）。呼び出し元が指定したベンダーを削除すると、回答者が変わってしまうため、リストを切り詰めることはありません。
• e3d_debate_status は、ディベートがキュー待ち、実行中、完了、失敗のいずれかを報告し、次に確認すべき時刻も示します。
• e3d_debate_result は回答、コンセンサスのレベル、異論、および各モデルの見解を返します。トランスクリプトは include_transcript: true の場合にのみ含まれます。

誰も状況を確認しなくても、ディベートはサーバー上で実行されます。終了すると、サーバーが最終処理します。サービスは1回の処理で料金を請求して結果を保存し、保存できなかった回答について料金を請求することはありません。完了した実行は E3D_MCP_RUNS_TTL_SEC の期間、ローカルに保持されます。その後のステータスおよび結果のリクエストには、サービスに保存されたコピー（fetch）を使って応答します。呼び出し元が読み取れるのは自身のディベートのみです。別のアカウントに属するIDには、存在しないIDと同じ not_found が返されます。サービスからの not_found は60秒間キャッシュされます。

2つの機能のうち片方しか通知されない場合、非同期ツールは一覧に表示されず、これらのツールへの呼び出しは不明なツールとして失敗します。e3d_debate、stdio モード、静的トークンモードはこれまでどおり動作します。

すべての上限は、何も予約される前に新しい開始を拒否します。対象となるのは、受付枠（キュー待ちの実行も含む）、アカウントごとに保持される実行数、実行ストアのバイト数上限、およびアウトボックス自体の上限です。サーバーが再起動すると、モデルの実行が開始されていた実行は、結果なしのエラーとして最終処理されます。まだキュー待ちだった実行は再開されるか、E3D_MCP_RUN_TIMEOUT_SEC を超えている場合は料金ゼロで最終処理されます。実行は <state dir>/runs/<hash of the account>/<debate_id>/ に保存されます（ディレクトリは0700、ファイルは0600）。質問と回答がログに記録されることはありません。e3d-mcp --doctor はこれらの設定を確認し、実行ストアのサイズを表示します。

変数	デフォルト	意味
E3D_MCP_RUNS_PER_PRINCIPAL	3	1つのアカウントで同時にキュー待ちまたは実行中にできる非同期ディベートの数です。これを超えると、開始はビジーとして拒否され、何も予約されません。
E3D_MCP_RUNS_GLOBAL	8	このサーバー上で、全アカウントを通じて同時にキュー待ちまたは実行中にできる非同期ディベートの数です。ディベートは e3d_debate と E3D_MCP_MAX_CONCURRENT の実行枠も共有します。
E3D_MCP_RUNS_KEEP_PER_PRINCIPAL	50	アカウントごとに保持する実行数です。最も古い完了済み実行から削除されます。最終処理がまだ配信されていない実行は削除されません。
E3D_MCP_RUNS_TTL_SEC	86400 (24 h)	完了した実行をローカルに保持する期間です。サービスは永続的なコピーを保持します。
E3D_MCP_RUNS_MAX_BYTES	67108864 (64 MB)	ローカル実行ストアの合計サイズです。この上限に達すると、新しい開始は拒否されます。
E3D_MCP_RUNS_POLL_PER_MIN	60	アカウントごとの1分あたりのステータスおよび結果のリクエスト数です。
E3D_MCP_RUN_TIMEOUT_SEC	1800	この時間を超えたキュー待ちの実行は、開始されずに料金ゼロで終了します。これは再起動後にも適用されます。
E3D_MCP_CUSTOMER_LIMITS	rounds=2,max_words=300,providers=3	顧客の非同期ディベートで使用できる値の上限です。呼び出し元が指定したラウンド数と単語数がこれを超える場合は引き下げられ、プロバイダーのリストが長すぎる場合は拒否されます。

ディベートパネル（回答するベンダー）

ホストモードでは、オペレーターがディベートで使用できるベンダーを決定し、各アカウント（pilot.e3d.ai 上）はその中からパネルを選択します。質問は最終要約も含め、有効なパネル上のベンダーにのみ送信されます。

• E3D_MCP_ALLOWED_PROVIDERS はホスト環境の許可リストです。設定されている場合、すべてのディベート（デフォルト、アカウントのパネル、ウェブ実行のリスト、クライアント独自の providers）で使用できるのはこれらのプロバイダーのみとなるため、ホストモードでは MCP サンプリングの発言者は拒否されます。E3D_MCP_PROVIDERS はこのリストに含まれている必要があり、各エントリーには既知のベンダーファミリーが必要です。そうでない場合、サーバーは起動を拒否します。
• 最終要約は常にディベートの最初のプロバイダーが作成し、明示的に e3d-debate に渡されます。（以前は、Anthropic が参加していないディベートでも、claude CLI がインストールされていれば要約を作成していました。）ローカル環境では、クライアント独自のモデルを使用します。クライアントが参加する場合は claude を使用し、それ以外は最初のプロバイダーを使用します。
• E3D_MCP_PANEL=1（外部フックを使用するホスト環境）を設定すると、各ディベートの前に、何も予約される前に、呼び出し元のパネルを課金サービスの POST /panel/v1/resolve に問い合わせます。この処理にキャッシュはなく、いずれかのエラー（HTTP エラー、タイムアウト、不正な応答）が発生するとディベートは拒否され、デフォルトへのフォールバックはありません。利用できないベンダーはアカウントのパネルから順に除外されます（その結果は panel.dropped とツールのテキストに示されます）。異なる2つのファミリーから2つ以上のベンダーが残らない場合、ディベートは拒否されます。クライアントの providers はアカウントのパネルのサブセットである必要があるため、ツールの引数でパネルを絞り込むことはできますが、ベンダーを追加することはできません。課金サービスのベンダーファミリーは、このサーバーのものと一致する必要があります。一致しない場合はディベートが拒否され（panel_config_mismatch）、アラートがログに記録されます。結果には panel（source、requested、used、dropped、families、synthesizer、設定されている場合は required）が含まれます。
• E3D_MCP_REQUIRED_PROVIDERS（ホスト環境のみ。stdio では無視されます）には、すべてのホストディベートに参加するプロバイダーを指定します。指定したプロバイダーは最初に、この順序で参加し、最初のプロバイダーが必ず要約を作成します。クライアントの providers で絞り込めるのはその他のプロバイダーのみです（必須プロバイダーは先頭に再追加され、残りはクライアントの順序が維持されます）。デフォルト、アカウントのパネル、ウェブ実行のリストでも、必須プロバイダーが先頭に追加されます。必須プロバイダーが利用できない場合、何も予約または実行される前にディベートは拒否され（required_provider_unavailable）、課金は発生しません。代わりのベンダーが要約を作成することはなく、ディベート中に要約の作成に失敗した場合、他のプロバイダーで再試行されることはなく、ディベートは失敗となります。すべての必須プロバイダーは E3D_MCP_ALLOWED_PROVIDERS に含まれている必要があり、リストは E3D_MCP_MAX_PROVIDERS（外部フックを使用する場合は E3D_MCP_CUSTOMER_LIMITS の providers の上限）以内に収まる必要があります。そうでない場合、サーバーは起動を拒否します。pilot.e3d.ai では、課金側の PILOT_PANEL_REQUIRED（例：anthropic-api）と一致している必要があります。

変数	デフォルト	意味
E3D_MCP_ALLOWED_PROVIDERS	未設定（利用可能なすべてのプロバイダー）	すべてのディベートで使用できるプロバイダーを限定する、カンマ区切りのリストです。
E3D_MCP_PANEL	未設定	1：ホスト環境でディベートを行う前に、各アカウントのパネルを課金サービスに問い合わせます。サービスでエンドポイントが提供されてから設定してください。
E3D_MCP_REQUIRED_PROVIDERS	未設定（必須プロバイダーなし）	ホスト環境のみ：すべてのディベートに参加するプロバイダーを指定するカンマ区切りのリストです。先頭のプロバイダーが要約を作成します。利用できない場合、ディベートは拒否されます（required_provider_unavailable）。E3D_MCP_ALLOWED_PROVIDERS に含まれている必要があります。

Web 実行（内部実行リスナー）

課金サービスの Web「Ask」ページでは、このサーバーを使って、サービスがすでに予約したディベートを実行できます。このための 2 つ目のリスナーを起動するには、E3D_MCP_RUN_PORT と E3D_MCP_RUN_TOKEN を設定します。外部フックが必要で、127.0.0.1 のみにバインドされます。また、このリスナーのパスがパブリックリスナーで提供されることはありません。トークンが 32 文字未満の場合、サーバーは起動を拒否します。

• {reservation_id, debate_id, question, providers?, rounds?, max_words?} を指定して POST /internal/runs を実行します。サーバーはまず、サービスの authorize-run を呼び出します。アカウントはその応答からのみ取得され、リクエストから取得されることはありません。また、サービスが許可しない限り、何も実行されません。実行はサービスの予約を使って計測され（新たな予約は行われません）、source: "web" を指定して一度だけ確定されます。受け付けられた実行には、ランダムな run_token とともに 202 が返されます。同じリクエストを再送すると、同じ実行と同じトークンを含む 200 が返されます。フィールドが変更された場合、またはいずれかの ID が異なるもう一方の ID と組み合わせて使われた場合は、409 conflict が返されます。確定的な拒否には、400 invalid、403 not_authorized、409 conflict、429 busy があります。503（unavailable または not_ready）の場合は何も受け付けられていないため、後で再試行してください。
• GET /internal/runs/{debate_id} は、ステータス、進捗状況、完了後は結果を返します。DELETE /internal/runs/{debate_id} は実行をキャンセルします。この場合、outcome: "error" で確定され、結果はありません。どちらのリクエストにも、サービスのトークンと実行固有のトークンが必要です。トークンは X-E3D-Run-Token ヘッダーで送信します。

すべてのリクエストには、Authorization: Bearer <E3D_MCP_RUN_TOKEN> が含まれます。トークンは一定時間で比較されます。1 分間に E3D_MCP_RUN_AUTH_FAILS_PER_MIN 回認証に失敗すると、最大 1 分間、すべてのリクエストが 429 で拒否されます。Web 実行は、非同期ディベートと同じスロット、制限、顧客ごとの最大数、実行ストア、再起動時の復旧機能を使用します。サービスが finalize、fetch、authorize-run を通知している間に限り、新しい実行が受け付けられます。サーバーは introspect の応答からこれらを取得するため、起動後に顧客のリクエストが確認されるまでは、リスナーは 503 not_ready を返します。本文、質問、トークンがログに記録されることはありません。実行トークンは実行の状態ファイルにのみ保存されます（モード 0600）。e3d-mcp --doctor でこれらの設定を確認できます。

変数	デフォルト	意味
E3D_MCP_RUN_PORT	未設定（オフ）	127.0.0.1 上の内部実行リスナーのポートです。
E3D_MCP_RUN_TOKEN	未設定	リスナー用のサービストークンです。32 文字以上である必要があります。ディベートプロセスには引き継がれません。
E3D_MCP_RUN_AUTH_FAILS_PER_MIN	20	リスナーが最大 1 分間、すべてのリクエストを拒否するまでの 1 分あたりの認証失敗回数です。

トークン料金（per_token_v1）

E3D_MCP_PRICING=per_token を設定すると、サーバーは請求サービス（その PILOT_PRICING_MODE=per_token）向けに、トークン数に基づいてディベートの料金を計算します。実行リスナーのヘルスチェック応答（空の実行リクエストが返す 400 invalid）には "capabilities": ["per_token_v1"] が追加され、ホスト型コネクターのディベートでは予約前にサービスに見積もりを要求し、すべてのディベートは見積もりに基づくプロバイダーごとの上限内で実行され、各呼び出しのベンダー報告トークン数はすべて、確定前にサービスへ送信されます。未設定の場合は何も変更されません。また、新しいフィールドを含まない実行リクエスト本文は従来どおり処理されるため、古い請求サービスも引き続き動作します。動作の詳細、ファイル、料金表に記載するバイト数については、docs/token-pricing.md を参照してください。

変数	デフォルト	意味
E3D_MCP_PRICING	未設定	per_token を設定すると、トークン料金が有効になり、per_token_v1 が通知されます。外部フックを使用するホスト型モードのみです。E3D_MCP_CUSTOMER_LIMITS の指定が必要です（rounds と max_words は、請求サービスの PILOT_TOKEN_MAX_ROUNDS と PILOT_TOKEN_MAX_WORDS に一致する必要があります）。
E3D_MCP_PER_TOKEN_ALLOW_XAI	未設定	1 を設定すると、xai-api をトークン単位で提供します（オーナーの許可が必要です。この機能をすぐに無効化できるよう、ゲートは維持されます）。xAI の推論トークンは請求されますが、max_tokens による上限の対象にはなりません。
E3D_MCP_PER_TOKEN_SEARCH	未設定	1 を設定すると、per_token_search_v1 を通知します。これは、トークン料金内で料金が計算されるウェブ検索です（実行フィールド max_searches と cite_bytes、見積もりバージョン 2、使用量レポートバージョン 2）。E3D_MCP_PRICING=per_token と、この環境でのウェブ検索の有効化が必要です。E3D_MCP_DAILY_SEARCHES のデフォルト値を 160 に設定します。docs/token-pricing.md を参照してください。
E3D_DEBATE_MAX_SEARCHES / E3D_DEBATE_CITE_BYTES_MAX	未設定	e3d-debate のみで使用します。E3D_DEBATE_MAX_TOKENS とともに、両方またはいずれも設定しないでください。{"<provider>": k} は検索を行うプロバイダーと、見積もりに基づく呼び出しごとの上限です。また、後続のプロンプトに挿入する引用リストの最大バイト数も指定します。e3d-mcp は見積もりに基づいてこれらを設定します。
E3D_DEBATE_MAX_TOKENS	未設定	e3d-debate のみで使用します。{"<provider>": n} は各呼び出しのベンダー出力上限です。ディベートをトークン単位モードに切り替えます（API プロバイダーのみ、再試行なし、E3D_DEBATE_MAX_SEARCHES の指定がない限りウェブ検索なし、usage.json を書き込みます）。e3d-mcp は見積もりに基づいて設定します。
E3D_DEBATE_ANSWER_BYTES_MAX	未設定	e3d-debate のみで使用します。{"<provider>": n} は、後続のプロンプトに挿入するプロバイダーの回答の最大 UTF-8 バイト数です。単独で動作します。
E3D_DEBATE_PROMPT_OVERHEAD	未設定	1 を設定すると、e3d-debate は各種プロンプトの固定テキストのバイト数を出力して終了します。

これを作った理由

自律型コーディングエージェントは、問題の 実行 側を解決しました。優れたモデルに優れた仕様を渡せば、忠実に実装してくれます。まだ足りないのは、その前段階のすべてです。何を作る価値があるかに気づき、それがクローズ済みの PR や先週放棄されたブランチの焼き直しではないことを確かめ、作業ツリーに手を加える前に、複数のモデルに計画が安全で妥当だと実際に合意させることです。この前段階を省くと、既存機能を喜んで再実装したり、誰も求めていない PR で自問自答したり、リポジトリの実質的な差分予算をひそかに超過したりするエージェントが生まれます。

e3d-pilot は、この欠けている部分を担うためにあります。e3d-code（旧 spec2code）を重複して実装するのではなく、その 上位 に位置する、小規模で監査可能なレイヤーです。e3d-code は、シンプルで信頼性の高いフェーズ実行役として、「この仕様を実行する」役割を保ちます。e3d-pilot の仕事は、そもそも仕様で何を実現すべきかを決め、それに取り組む価値があることを確かめ、人間が確認すべき段階を越えて監視なしで実行されないようにすることです。

もう一つの理由は、同じバックログをいくら見つめても、優れたアイデアはなかなか生まれないからです。e3d-pilot の discover ステージでは、リポジトリと異なるカテゴリの領域から明示的に発想を借ります。ゲームの進行ループ、マーケットプレイスの流動性を高める工夫、ソーシャルフィードの通知の仕組みなどです。また、ideate ステージでは、候補すべてを魅力と定着度（人を呼び込めるか、また戻ってきてもらえるか）で評価します。収益は二次的なタイブレーカーとして扱い、決定要因にはしません。目標は、社内の TODO リストの次の項目ではなく、人々が本当に望む機能を作ることです。

三つ目の理由は、個々の実行というより、何度も実行するなかで積み上がっていくものに関することです。一度下した決定を、次のセッションで作業を再開するたびに最初から説明し直す必要はありません。追跡対象のアイデアはすべて、台帳に永続的なセッション横断の記録として残ります。ideas context／ideas handoff を使えば、新しい Claude Code、ChatGPT、または Codex セッションで、以前の会話全体を再生することなく、アイデアについてすでにわかっていること（決定事項、調査結果、現在の状態）を正確に読み取れます。また、ideas note を使えば、そのセッションで新たに得た知見を書き戻せます。本当に意見が分かれる問いについて、一度の推論だけを信用しないという同じ考えから、単独で使えるツールとして e3d-debate も存在します。任意の問いを複数のモデルに複数ラウンド検討させ、意見が一致するか、具体的で明示された異論を残すまで続けます。これは、e3d-pilot が内部で依存している negotiate ステージと同じ仕組みを、コード変更に限らずあらゆる意思決定に利用できるようにしたものです。

他とは異なる点

• 作業を繰り返しません。 先へ進む前に、対象リポジトリのオープンブランチ、PR の履歴（オープンおよびクローズ済み）、過去のすべての e3d-pilot 実行と、すべてのアイデアを照合します。
• 1 つのモデルの意見だけで実行しません。 negotiate 段階では、設定済みのすべてのレビュアー（現在は 2 人で、今後は設定のみで追加可能）が、変更されていない同じドラフトを個別に承認する必要があります。意見が一致しない場合は、回数を制限して再試行した後、マージを強行せず、「人間による対応が必要」として正常に停止します。
• 承認がないことを承認とみなしません。 調査とアイデア出しは無人で実行できますが、ソースを変更する段階では ideas approve が必要で、ベースブランチへのマージには、対象 PR の正確な head SHA に対する approve-merge が必要です。
• 最初のゲートを通過する前にソースに触れません。 実行は実装承認後に限り、専用ブランチ上の独立した worktree で行われます。パスの拒否リストと、実行後の実際の差分上限を、レビューや公開の前に適用します。
• 異なるリビジョンをマージしません。 マージ承認は GitHub のレビュー承認とは別で、確認済みの PR URL、ベースブランチ、head SHA に紐付けられます。コミットがプッシュされると、人間が新しい head をレビューして承認するまで、その承認は無効になります。
• spacepacket1 のリポジトリと通信しているとは限りません。 対象リポジトリとの契約は、1 つの JSON 設定ファイルにすべて記述されます。固定の組織、固定のリモートホスト、パイプラインに組み込まれた e3d-* の命名規則はありません。
• セッション間でアイデアのコンテキストを失いません。 ideas note／ideas context／ideas handoff を使えば、e3d-pilot 自身のパイプライン実行に限らず、どの AI セッションでも、追跡対象のアイデアについて学んだことや決定したことを、そのライフサイクルの状態とは無関係に、永続的に読み書きできます。

ほかの人に役立つ点

リポジトリを管理していて、「次に何を作るべきか」について継続的にセカンドオピニオンを得たい場合、e3d-pilot の導入は 1 ファイルを用意するだけで済むことを目指しています。提案の前に十分な調査を行い、実行前に複数のモデルから独立した合意を得て、既成事実ではなく完全な監査証跡付きのドラフト PR を提示します。.e3d-pilot/config.json を作成して一度実行し、検証したら、任意のスケジュール（cron の設定やスケジュール済みジョブなど）で、対象リポジトリ（または複数のリポジトリ群）に向けて実行できます。e3d-pilot 独自のスケジューラーを用意することはありません。GitHub、リモートのないローカルリポジトリ、さらにはアーキテクチャ上、フォージアダプターがまだなくても、ほかのどの git ホストでも同じように動作します。フォージの種類を認識するのは、最後の公開ステップだけだからです。

パイプライン

flowchart LR
    A[discover] --> B[ideate]
    B -->|optional candidate_scoring| S[read-only ensemble]
    S --> I[[proposed idea ledger]]
    B -->|selected: none| STOP1((nothing to do))
    I -->|ideas approve| C[draft]
    I -->|ideas reject| STOPR((rejected))
    C --> D[negotiate]
    D -->|needs human| STOP2((stop for review))
    D --> E[execute]
    E -->|over ceiling| STOP2
    E --> F[review]
    F -->|verify failed| STOP3((blocked))
    F --> G[publish]
    G --> H[[implemented: draft PR / local branch]]
    H -->|approve-merge for exact head SHA| M[merge]
    M --> Z[[merged / partially_merged / merge_failed]]

1. discover — findings.md を作成します。Git の履歴、ブランチ、issue／PR、既存のドキュメントや TODO に加え、モデルが調査した「External Context」セクションを含めます。このセクションには、明示的な分野横断の「Analogous Patterns」サブセクションも含まれます（以下のアイデア出しの情報源を参照）。
2. ideate — 優先順位を付けて重複を除いた candidates.md を作成し、重複しないすべての候補を proposed のアイデアとして登録します。提案されたものがすべてすでに網羅されている場合、selected: none は有効な正常終了です。candidate_scoring が設定されている場合、読み取り専用ワーカーのアンサンブルが、重複しない候補の優先順位を再評価してから登録します。元のモデルによる選択結果は model_selected として保存されます。
3. approval gate 1 — 人間が対象のアイデアを承認または却下します。proposed は却下を意味するものではなく、現在の実装承認なしにソースを変更するステージは実行できません。
4. draft — 承認された候補を e3d-code 形式の spec-draft.md に変換します。フェーズごとに機械可読な pilot:touches 注釈を付けるため、後続のガードは文章から推測するのではなく、実際のパスを確認できます。
5. negotiate — 設定されたすべてのレビュアーが、変更されていない同じ草案を一度の確認で承認する必要があります。意見の相違がある場合は、上限付きの修正ラウンドに進み、成功時は spec-final.md を作成し、そうでない場合は「要人間対応」として正常に停止します。
6. execute — spec-final.md を、専用ブランチ上の隔離された worktree 内で設定済みの実行バックエンドに渡し、その後 protected_paths と実行後の実際の max_diff_files／max_diff_lines 上限を適用します。デフォルトのバックエンドは e3d-code（旧 spec2code）です。providers.execute: "grok-build" は実験的な代替手段で、同じ worktree、上限、レビュー、ドラフト PR のフローを使用します。
7. review — 検証コマンドを実行（または自動検出）し、独立したレビュー用プロバイダーに実際の差分を確認させます。
8. publish — 検証に合格した後に限り、実行の監査アーティファクトをブランチにコミットし、公開バックエンド（github または local）に引き渡してドラフト PR を作成するか、ローカルのレビューブランチを残します。
9. approval gate 2 — 人間がドラフト PR／ローカルブランチをレビューした後に approve-merge を実行します。GitHub を対象とする場合、e3d-pilot は現在の PR の head SHA を記録し、新たな承認がない限り、その後の head のマージを拒否します。

生成された実行アーティファクトは、対象リポジトリ内の .e3d-pilot/runs/<run-id>/ に保存されます。アイデアの台帳状態は .e3d-pilot/ideas/<idea-id>/idea.json に保存され、追記専用のイベントは .e3d-pilot/events.jsonl に記録されます。idea.json はイベントから生成されるため再構築できます。events.jsonl は不変の監査ソースです。--run-id を指定しない discover と all は、衝突を避けた新しい run-id を開始し、.e3d-pilot/latest-run を更新します。それ以外のすべてのステージは、--run-id <id> を明示的に渡さない限り、最新の run-id を再開します。対象リポジトリに .e3d-pilot/paused を作成すると、外部作業が始まる前にステージを停止できます。

アイデアの発掘とスコアリング

Discover のモデル呼び出しでは、単に「最先端技術」を要約するのではなく、設定可能な analogy_domains リスト（または、ゲーム、ソーシャルプラットフォーム、マーケットプレイス、開発者向けツール、フィンテックを幅広く含む適切な組み込みのデフォルト）から、最も応用可能な項目を 2～3 件選び、それぞれの仕組みを この リポジトリにどう適用できるかを具体的に挙げるよう求められます。

次に Ideate は、重複していないすべての候補について、Attraction と Retention（それぞれ 1～5）をスコアリングし、Category（data、workflow、social、gamification、testing、marketing、selling、other のいずれか）を付け、参照した Analogy を示して、Effort を見積もります。順位は主に Attraction + Retention に基づきます。任意の Revenue スコアは、他の候補と同点の場合にのみタイブレーカーとして使用でき、ユーザーの獲得や維持で優れた候補を上回ることはありません。この優先順位は意図的なものです。ユーザーを増やし、維持することが目的であり、収益はそれをうまく実現した結果として得られる二次的な成果です。

セマンティック重複検出（Jev、任意）

提案のハッシュ化（ideas_find_duplicate_by_digest）により、素材化する前に完全一致する候補を検出しています。これとは別に、TYPESAFE_API_KEY が設定されている場合、新たに素材化されたすべてのアイデアは、同じ台帳内の他の有効なアイデアと照合され、Jev（TypeSafe の System One Choice API）によってセマンティックな重複（根本の課題は同じで、表現が異なるもの）がチェックされます。これはハッシュ化では検出できません。このチェックはすべての ideas ingest／propose 呼び出しで自動的に実行されます。認証情報が存在する以外に有効化する設定フラグはなく、認証情報がない場合はエラーではなく、何もせずに終了します。

これはシャドーモードで動作し、判断の参考にすることのみを目的としています。一致があっても取り込みはブロックされず、候補が変更されることもありません。レビュー時に人が確認できるよう、指摘メモ（「<idea-id> とセマンティックに重複している可能性があります。信頼度 <level> — このアイデアはブロックされません」）が追加されるだけです。この特定の判定における Jev の誤検知率を、実際のキャリブレーションサンプルで検証できるまでは、参考情報としての扱いが続きます（idea-980bf5b4df6b／idea-82a5c2225266 を参照）。lib/ideas/jev_dedup.sh を参照してください。

任意のアンサンブルスコアリング

Ideate プロバイダーが候補を書き出した後、任意の candidate_scoring ブロックを使って、アイデアを素材化する前に、独立した読み取り専用ワーカー 3～5 個で順位を付け直すことができます。元のモデルによる選択は model_selected として保存され、selected には重複していない候補の中からアンサンブルが選んだものが設定されます。スコアリングによって実行、公開、承認が行われることはありません。人による 2 つのゲートは引き続き適用されます。

lib/providers のアダプターはどれもスコアリングプロバイダーとして使用できます。grok-build は選択肢の一つであり、フロンティアモデルによる negotiate と e3d-code による execute の前段で、低コストに複数へ振り分ける用途を想定しています。

"candidate_scoring": {
  "provider": "grok-build",
  "workers": 3
}

workers は 3～5 の整数である必要があります（デフォルトは 3）。成果物は実行ディレクトリ内に ideate-scoring.json、ideate-response.model.md、および ideate-scoring.artifacts/ 配下のワーカーごとのプロンプト／標準出力として保存されます。Fleet discover では .e3d-pilot-fleet/config.json 内の同じブロックを使用し、fleet-ideate-scoring.json に書き込みます。スコアリングを実行した場合、各アイデアレコードにはアンサンブルの平均値が scores.ensemble として保存されます。このフィールドは承認用ダイジェストには含まれません。

収益重視の実行

e3d-pilot run に --focus revenue を渡すと（任意のステージで）、専用の実行で優先順位を切り替えます。discover では ### Monetization Signals サブセクションが追加されます（リポジトリ内の既存の収益化の仕組みに加え、それを拡張できる隣接業界のモデルを2～3個提示します）。ideate では候補をまず Revenue で順位付けし、Attraction／Retention は同順位の場合にのみ考慮します。また、Revenue は任意の同順位判定項目ではなく、必須の数値フィールドになります。候補は既存機能の拡張に限らず、新たな収益化の仕組みでもかまいません。いずれの場合も重複チェックが適用されます。

フォーカスは実行ごとに一度だけ解決され、.e3d-pilot/runs/<run-id>/focus に保存されます。そのため、同じ実行内の後続ステージ（たとえば、discover の実行後に単独で --stage ideate を指定して実行する場合）では、再度 --focus を明示的に渡して上書きしない限り、自動的に引き継がれます。デフォルトの動作（--focus default、つまり Attraction／Retention を優先する動作）に変更はありません。

Fleet のライブ運用

Fleet の検出では、任意の .e3d-pilot-fleet/config.json フィールドから、読み取り専用の運用シグナルを2種類取得できます。

• live_instances：name と url のみを持つオブジェクトの配列です。name は空でない表示文字列である必要があります。url は空でない http:// または https:// の URL で、空でないオーソリティを含み、userinfo を含まない必要があります。収集処理は各インスタンスにつき GET リクエストを1回だけ行い、リダイレクトは最大1回まで追跡します。各リクエストのタイムアウトは10秒で、最初のリクエストとリダイレクト先のリクエストの両方で HTTP／HTTPS のみを許可し、再試行は行いません。
• ライブ状態の分類は決定論的です。HTTP 200 かつ応答時間が1500 ms以下の場合は healthy、HTTP 200 かつ応答時間が1500 msを超える場合、またはその他の2xx／3xx応答の場合は degraded です。curl の失敗、経過時間／ステータス出力の無効、または 000、1xx、4xx、5xx、6xx～9xx を含む、200～399以外のステータスの場合は down です。
• social_accounts：platform、name、channel_id、bot_user_id のみを持つオブジェクトの配列です。platform は文字列 discord である必要があります。bot_user_id は公開される正確な投稿者識別子であり、認証情報ではありません。Discord の収集処理は環境変数から DISCORD_BOT_TOKEN を読み取り、認証情報が設定されたアカウントごとにメッセージリクエストを1回だけ行います。トークンが未設定または空の場合は、リクエストを一切行いません。
• Discord の収集は読み取り専用で、再試行なしで GET https://discord.com/api/v10/channels/{channel_id}/messages?limit=50 を使用します。「最近のメッセージが見つかりません」、エンゲージメントがゼロのメッセージ、収集の失敗を区別します。リアクションは、author.id が bot_user_id と完全に一致するメッセージについてのみ合算されます。
• ## Live Operations は、どちらかの配列に要素が1つ以上ある場合にのみ追加されます。このセクションが含まれる場合、### Live Instance Status が常に最初に表示されます。ライブインスタンスがなく、Discord が設定されている場合は、No live instances configured. と表示されます。### Social Engagement は、social_accounts に要素が1つ以上ある場合にのみ表示されます。
• ### Operational Recommendations は、ライブインスタンスが degraded／down の場合、および Discord のエンゲージメントがゼロまたは収集に失敗した場合の箇条書きに限って、設定順に表示されます。観測された状態をそのまま記載し、原因を推測しません。状態が healthy のインスタンス、ゼロではない Discord エンゲージメント、「最近のメッセージが見つかりません」の場合は、推奨事項を表示しません。
• Moltbook のサポートは、後続の同系統ブランチとして計画されています。
• Fleet の設定に認証情報を含めないでください。実行時の環境変数として設定するのは DISCORD_BOT_TOKEN のみです。

架空の .example.com ライブインスタンスと架空の Discord アカウントが設定された、すぐに使える Fleet 設定をお探しの場合は、examples/sample-fleet-config-with-ops.json をベースにしてください。

要件とインストール

Bash、Git、jq、curlをインストールしてください。パイプライン全体の実行ステージには、仕様に基づいてフェーズごとにコードを記述するツールであるe3d-codeも必要です（以前の名称はspec2codeです。npm install -g e3d-codeでインストールするか、npm install -g e3d-pilotで自動的にインストールされます）。ディベートと読み取り専用のMCPツールには必要ありません。設定で使用するモデルCLIとForge CLI（claude、codex、devin、ローカルのOpenAI互換エンドポイント、またはgrok-build用のgrok）をインストールし、認証してください。このリポジトリのbinディレクトリをPATHに追加してください。

# From npm (also installs e3d-code, the execute-stage dependency, when it can):
npm install -g e3d-pilot
e3d-pilot --help

# Or from a clone:
git clone https://github.com/spacepacket1/e3d-pilot.git
export PATH="$PWD/e3d-pilot/bin:$PATH"
e3d-pilot --help

npmパッケージには、e3d-pilot、e3d-debate、e3d-mcpの3つのコマンドが含まれています。

Node.jsが必要なのは、オプションのe3d-pilot webダッシュボードを使う場合のみです（下記のWeb UIを参照）。それ以外のすべてのコマンドに必要なのは、Bash、Git、jq、curlのみです。

リポジトリを設定する

対象リポジトリに.e3d-pilot/config.jsonを作成します。examples/sample-config.jsonをひな形として使用してください。各フィールドは次のとおりです。

• verify：公開前に実行ワークツリーで実行するコマンドです。リストが空の場合は、package.json、requirements.txt、またはMakefileから自動検出されます。
• protected_paths：生成される仕様と実行時ガードで拒否されるglobパターンです。
• research_topics：ディスカバリー調査のヒントです。
• analogy_domains：ディスカバリーの類推パスで使う、任意の異分野シードリストです（上記を参照）。省略した場合は、組み込みのデフォルト値が使われます。
• providers：discover、ideate、draft、順序付きのnegotiateレビュー担当、独立したreview、および任意のexecute（デフォルトはe3d-code、実験的な選択肢はgrok-build）に使用するプロバイダー名です。discover、ideate、negotiate、reviewには、プロバイダー名の文字列または配列を指定できます。配列を設定すると、リスト内のすべてのモデルが実行されます（discoverとreviewは出力を連結し、ideateは候補を統合します。negotiateでは、変更のないドラフトによる合意形成パスが引き続き1回必要です）。draftに指定できるプロバイダーは1つです。grok-buildは通常のアダプターです。claude、codex、devin、localと同じフィールドに指定してください。
• candidate_scoring：任意の{ "provider": "grok-build", "workers": 3 }です。ideateが候補を提案した後、読み取り専用の独立したワーカー3～5個が候補を再評価します。providerには任意のlib/providersアダプターを指定できます。grok-buildも選択肢の1つです。スコアリングは実行、公開、承認を行いません。省略した場合、スコアリングは行われません。
• max_diff_filesとmax_diff_lines：実行後に適用される上限です。
• docs：任意のガイダンス文書のパスです。省略した場合は、一般的なファイル名から検出されます。
• live_verify：任意の{ "command": "..." }フックです。リポジトリのドキュメントで対応するE3D有料APIサーフェスが確認でき、e3d-agentを利用できる場合にのみ実行されます。それ以外の場合はスキップされます。
• pr：base_branch、ドラフトフラグ、ラベル、バックエンド（auto、github、local）を指定します。
• notify：任意の{ "email": { "to": "...", "command": "..." } }です。通知を参照してください。
• approval：任意の{ "implementation_required": bool, "merge_required": bool }です。どちらもデフォルトはtrueです。承認ゲート付きオペレーターワークフローを参照してください。
• tracking：任意の{ "project_url": "..." }です。このリポジトリではE3D_PILOT_TRACKING_PROJECT_URLを上書きします。プロジェクトボードのトラッキングを参照してください。

設定を検証して実行します。

e3d-pilot config validate /path/to/repository
e3d-pilot run --repo /path/to/repository --stage all

承認ゲート付きオペレーターワークフロー

デフォルトの run --stage all は、自律的に発見とアイデア出しを行い、アイデアを具体化した後、選択したアイデアに現在有効な実装承認がすでにある場合を除き、draft の前で停止します。これは正常な待機状態であり、クラッシュではありません。

提案されたアイデアを一覧表示して確認します。

e3d-pilot ideas list --repo /path/to/repository --status proposed
e3d-pilot ideas show --repo /path/to/repository idea-abc123def456

実装を承認または却下します。

e3d-pilot ideas approve --repo /path/to/repository idea-abc123def456 --actor [email protected] --note "Build this next"
e3d-pilot ideas reject  --repo /path/to/repository idea-abc123def456 --reason "Not aligned this cycle" --actor [email protected]

ideas approve は最初のゲートです。対象となるアイデアの内容と承認済みのターゲット計画に対して、ドラフト作成、交渉、実行、レビュー、公開を許可します。これは GitHub PR のレビューではなく、マージを許可するものでもありません。

アイデアに調査結果や判断を記録し、アイデアのライフサイクル状態に関係なく、それらをコンパクトなコンテキストとして取り出します。

e3d-pilot ideas note     --repo /path/to/repository idea-abc123def456 "Discovered the API rate-limits at 50 req/min" --actor [email protected]
e3d-pilot ideas note     --repo /path/to/repository idea-abc123def456 --decision "Ship the read-only slice first" --actor [email protected]
e3d-pilot ideas context  --repo /path/to/repository idea-abc123def456 [--json]
e3d-pilot ideas handoff  --repo /path/to/repository idea-abc123def456

これらの機能は、特定の不足を解消するためにあります。e3d-pilot 自身のパイプライン呼び出し以外から .e3d-pilot/ に書き込むものがないため、追跡対象のアイデアについて、アドホックな Claude Code、ChatGPT、Codex のセッションで見つけたコンテキストを永続的に記録する場所がありません。ideas note は、既存のアイデアの台帳レコードに、自由形式の調査結果（または --decision を指定した場合は判断）を、純粋な自己ループイベント（note_appended）として追記します。このイベントがライフサイクル状態のゲートになることも、ライフサイクル状態によってゲートされることもありません。proposed、implemented、merged を含め、どの状態のアイデアにも使用できます。ideas context は、そのアイデアを、短い要約と、蓄積された判断および調査結果を分けた形で読み出します。ideas handoff は同じ情報を、最初からすべて説明し直す代わりに、新しいモデルセッションへ渡せるコンパクトなパケット（GOAL / STATUS / RELEVANT DECISIONS / RELATED CONTEXT / RECENT FINDINGS）として出力します。これらによって、新しいスキーマや新しいアイデアの種類が追加されることはありません。既存のアイデアごとの台帳に対する、3 つのシンプルな動詞です。

プロベナンスのエクスポートとトレースの実験

プロベナンスコマンドは、同じイベント台帳から、破棄可能なグラフまたは単一アイデアのトレースを直接生成します。

e3d-pilot provenance export --repo /path/to/repository [--out /path/to/provenance.jsonl]
e3d-pilot provenance trace  --repo /path/to/repository idea-abc123def456 [--json]
e3d-pilot fleet provenance export /path/to/fleet.json [--out /path/to/provenance.jsonl]
e3d-pilot fleet provenance trace  /path/to/fleet.json idea-abc123def456 [--json]

provenance export は、フリートのアイデアが提案したリポジトリを含め、正規のノードとエッジを再生成します。provenance trace は events.jsonl を直接読み取り、判断、調査結果、Pilot が生成した作業、単に観測した外部コミット、成果、失敗を分けて表示します。ideas note に --evidence <path-or-url> を追加すると、裏付け資料を台帳にコピーせずに、リポジトリモードのトレースとエクスポートでその資料へのポインターを保持できます。これは e3d-graph の議論で合意された、意図的に UI を設けない実験です。可視化に取り組む前に、台帳を手作業で読むよりも、トレースによって実際の帰属に関する疑問へ、より速く、より正確に答えられることを検証します。

すべての provenance export は、兄弟ファイルとして <name>.manifest.json も書き出します（種類別のノード数とエッジ数、孤立ノード、次数が最も高いノード、導出されたグラフのサイズとソース台帳のサイズを比較する graph_events_ratio を含みます）。これは、グラフがひそかに肥大化したり構造を失ったりするのを検知するためのエンジニアリングテレメトリーであり、プロダクト分析ではありません。

固定の provenance query サブコマンドは、アイデアから成果までの lineage、繰り返し発生するレビューの reversals、実装の failures、フリート専用の cross-repo 伝播を要約します。各サブコマンドは --json をサポートします。フリートモードでは e3d-pilot fleet provenance query <name> /path/to/fleet.json を使用し、リポジトリモードでは e3d-pilot provenance query <name> --repo /path/to/repository を使用します（cross-repo は意図的に空の結果を返します）。 独立したスタンドアロンスクリプト bin/e3d-provenance-agreement --repo /path/to/repository（e3d-debate と同じく、サブコマンドツリーには組み込まれていないパターン）は、そのリポジトリの .e3d-pilot/runs/ にある過去の交渉ラウンドとレビューラウンドについて、プロバイダー間の一致状況を集計します。既存の lib/negotiate/parse-status パーサーと lib/review/parse-verdict パーサーをサブプロセスとして再利用し、パーサーの仕様を再実装することはありません。標準出力には JSON が出力されます。内容は、各プロバイダーの交渉承認率、プロバイダーの各ペアの一致率、および具体的な不一致（実行 ID、ラウンド、両プロバイダーのステータスと記載された理由）です。現在の形式より古いレスポンスファイルや、解析に失敗したファイルはスキップされ、別途件数が記録されます。一致または不一致として数えられることはありません。

レビューでの異議、レビューをすり抜けた不具合、履歴のバックフィルについては、docs/objection-capture.md に記載されています。

承認済みのアイデアを実装します。

e3d-pilot ideas implement --repo /path/to/repository idea-abc123def456
e3d-pilot ideas implement-approved --repo /path/to/repository

実装が成功すると、実行 ID、ブランチ／ワークツリー、変更したファイルと行、検証結果、レビュー結果、公開バックエンド、PR の URL／番号、最終的な PR の head SHA が記録されます。GitHub への公開ではドラフト PR が作成され、ローカルへの公開ではローカルのレビュー用ブランチと概要が残されます。

ideas implement は常に新しい実行を開始し、再試行時にはドラフト作成、交渉、実行を最初からやり直します。最後の段階（通常は公開。たとえば、まだ存在していなかった forge ラベルが原因の場合）が失敗しただけで、それ以外は検証とレビューがすべて済んでいる場合も同様です。特定の実行がすでにその段階まで進んでいる場合は、新たにドラフト作成／交渉／実行を行うのではなく、その実行を再開してください。

e3d-pilot ideas repair-run --repo /path/to/repository --run-id <run-id> [--from-stage <stage>] idea-abc123def456

--from-stage の既定値は publish です。再開地点より前のすべての段階について、実際の成功を示す成果物がディスク上に存在していなければなりません。これによりスキップできるのは、完了済みであることが確実に証明できる作業だけであり、実行されていない作業がスキップされることはありません。

コードを書く前に一時停止し、計画を確認してから続行するか中止してください。

e3d-pilot ideas implement --repo /path/to/repository --stop-before execute idea-abc123def456   # draft + negotiate, then stop
e3d-pilot ideas resume    --repo /path/to/repository idea-abc123def456                          # execute -> review -> publish
e3d-pilot ideas cancel-paused --repo /path/to/repository --reason "plan too broad" idea-abc123def456

--stop-before には negotiate、execute、review、publish を指定できます。一時停止したアイデアは implementing のまま保持され（新しい台帳状態は追加されません）、実行ディレクトリに paused-before.txt マーカーが作成されます。resume は、承認ダイジェスト、以前の各段階の成果物がすべて存在すること、ベース SHA が変わっていないことを再確認してから、通常どおり implemented または failed の結果で処理を完了します。cancel-paused は、指定した理由とともに implementation_failed の結果を記録するため、通常の ideas implement で再試行できます。

ドラフト PR をレビューした後、2 つ目のゲートで承認し、マージを実行します。

e3d-pilot ideas approve-merge --repo /path/to/repository idea-abc123def456 --actor [email protected] --note "Reviewed head"
e3d-pilot ideas merge         --repo /path/to/repository idea-abc123def456

approve-merge は、正確な PR URL、ベースブランチ、head SHA を記録します。ideas merge はマージ直前に forge の状態を更新し、head が古い場合、ベースブランチが変更された場合、ドラフト PR の場合、クローズ済みの PR の場合、または承認がない場合は処理を拒否します。GitHub のレビュー承認は有用な社会的証拠ですが、e3d-pilot のマージ承認ではありません。

変更をリクエストし、forge の状態を同期して、結果を記録します。

e3d-pilot ideas request-changes --repo /path/to/repository idea-abc123def456 --reason "Tighten scope"
e3d-pilot ideas sync            --repo /path/to/repository
e3d-pilot ideas outcome         --repo /path/to/repository idea-abc123def456 --window 7d --metric retained=true --metric revenue=42
e3d-pilot ideas rebuild         --repo /path/to/repository

sync は、PR の head の変更、ドラフト／準備完了の切り替え、チェック、クローズ、外部でのマージを確認しますが、何も承認しません。新しい PR head があると、マージ承認は無効になります。outcome は型付きメトリクスを追記し、履歴を上書きすることはありません。rebuild は events.jsonl から派生した idea.json スナップショットを再生成します。

移行

既存の .e3d-pilot/runs/<run-id>/ 成果物は引き続き読み取り可能です。既存の選択済み候補は、その実行のアイデア生成を再実行することで、proposed アイデアとして実体化できます。

e3d-pilot run --repo /path/to/repository --stage ideate --run-id <legacy-run-id>

このコマンドで proposed アイデアのレコードを作成できますが、実装承認が作成されることはありません。人が ideas approve を実行する必要があります。

既存のオープンな e3d-pilot PR を取り込む場合は、インストール済みのバージョンで利用可能な場合に限り、明示的な取り込みコマンドを使用してください。取り込み時には PR／実行の出所情報を記録し、アイデアを implemented として開始する必要があります。また、ベースブランチへマージする前には、引き続き approve-merge が必要です。オープンな PR、GitHub のレビュー承認、ブランチ名を台帳上の承認として扱わないでください。

プロバイダーと交渉

組み込みアダプターは、claude、codex、local、devin、grok-build、オプトインの試験用アダプターgemini、2つのクラウドアダプターbedrockとazure-openai、そして4つの直接APIアダプターanthropic-api、openai-api、gemini-api、xai-api（サーバーやコンテナ向けで、CLIは不要）です。e3d-pilot providers listで確認できます。 grok-buildは、他のアダプターと同じ方法で選択します。providers.*に指定してください。 PATH上にgrokバイナリがあれば利用できます（GROK_BUILD_BINで上書き可能です）。

discover、ideate、negotiate、reviewでは、それぞれ複数のモデルを指定できるため、設定済みの各アダプターに順番が回ります。文字列も引き続き有効で、「このアダプターのみ」を意味します。negotiateでは以前からこの方式に対応していましたが、discover、ideate、reviewも対応するようになりました。discover／ideate／reviewでいずれかのアダプターが未導入または失敗した場合でも、ほかのアダプターは実行され、ステージは続行されます。ステージが失敗するのは、指定したアダプターがすべて失敗した場合のみです。一方、negotiateでは、合意形成がこのステージの目的であるため、レビュー担当が利用できないと即座に失敗します。

grok-build — ヘッドレスモードでGrok Build CLIを実行します。推論ステージでは読み取り専用サンドボックスを使用します。curl -fsSL https://x.ai/cli/install.sh | bashでインストールしてから、grok login --device-authまたはXAI_API_KEYを使用してください。バイナリ、タイムアウト、モデルは、それぞれGROK_BUILD_BIN、GROK_BUILD_TIMEOUT（秒、デフォルトは900）、GROK_BUILD_MODELで上書きできます。追加の有効化フラグはありません。ほかのアダプターと同様、設定にgrok-buildを指定することがオプトインになります。

gemini — オプトインの試験用アダプターで、明示的に選択して実行するe3d-debate --providers ...gemini...を想定しています。e3d-debateのデフォルトには含まれず、デフォルトまたは推奨のproviders.*設定にも含まれません。ほかのすべてのアダプターと同様、明示的に指定する以外に個別の有効化フラグはありません。そのため、コード上はパイプラインのステージ独自のproviders.*設定に指定することもできますが、共有の利用枠制限付き無料枠（下記参照）があるため、常に成功する必要があるステージには適していません。Gemini CLIをインストールし、個人用Google OAuthの手順に従ってください。このアダプターは、有料の呼び出しを誤って行わないよう、APIキー、Vertex AI、Google Cloud、認証情報の上書き、認証情報の欠落や曖昧さ、超過料金が発生する認証を拒否します。settings.jsonのbilling.overageStrategyは厳密に"never"である必要があります（デフォルトは"never"ではなく"ask"です）。ヘッドレスモードで実行され、ポリシーによって組み込みツール、拡張機能ツール、MCPツールはすべて拒否されます。また、ユーザー設定、システム設定、システムデフォルト設定ファイルのいずれかに、Gemini CLIのフック、mcpServersエントリ、admin.mcp.config、admin.mcp.requiredConfig、adminPolicyPathsエントリが設定されている場合も実行を拒否します（フックはライフサイクルイベントでプロンプトにアクセスできる任意のコマンドを実行し、MCPサーバーは、Gemini CLIのドキュメントで「ユーザー設定にかかわらず」挿入されると説明されているエンタープライズ管理者必須のものも含め、検出中にCLIの起動時にコマンドを起動します。管理者ポリシーパスは、このアダプターが監査できない追加のポリシーファイルを参照します。これらはすべて、ポリシーが拒否するツール呼び出し経路とは独立しています）。制限を上書きするには、GEMINI_BIN（デフォルトはgemini）、GEMINI_MODEL（デフォルトでは未設定）、GEMINI_TIMEOUT（秒、デフォルトは120）、GEMINI_TOKEN_LIMIT（デフォルトは200000）を設定してください。Geminiが応答モデルとトークン数の両方を返す場合、成功した呼び出しではそれらの正確な値が報告されます。それ以外の場合は、計測されていないテレメトリが報告されます。タイムアウトやトークン上限に達すると、部分的な出力を返さずに呼び出しは失敗します。Gemini／Qwenプロバイダー追加をめぐる発端となった議論を参照してください。

Grokを低コストの候補ランカーとしてのみ使うには、既存のideate／negotiateプロバイダーはそのままにして、candidate_scoringを追加します（任意のアンサンブルスコアリングを参照）。このファンアウトでは実行されません。人による承認、negotiate、e3d-codeの実行は引き続き維持されます。 devin — Devin CLI を非対話型の印刷モードで呼び出します。デフォルトは claude-sonnet-4-6-thinking-1m です。環境変数で上書きできます。

export DEVIN_BIN=devin                          # binary path (default: devin)
export DEVIN_MODEL=claude-sonnet-4-6-thinking-1m  # model override
export DEVIN_PERMISSION_MODE=auto               # permission mode (default: auto)

bedrock — AWS CLI の Converse API を介して Amazon Bedrock を利用します（SDK は不要です）。PATH に aws があり、モデル ID とリージョンが必要です。認証情報は通常の AWS チェーン（環境変数、プロファイル、SSO、インスタンスまたはタスクのロール）から取得されます。

export BEDROCK_MODEL_ID=anthropic.claude-3-5-sonnet-20241022-v2:0   # or an inference-profile id
export AWS_REGION=us-east-1

providers list は CLI、モデル ID、リージョンが設定されているかどうかのみを確認します。権限が不足している場合は、最初の実際の呼び出し時に明確なエラーが表示されます。リクエストはペイロードファイルを介して送信されるため、大きなプロンプトも使用でき、ps に表示されることもありません。任意の設定：BEDROCK_MAX_TOKENS（4096）、AWS_BIN。

azure-openai — HTTPS 経由で Azure OpenAI のデプロイメントを利用します（curl + jq）。

export AZURE_OPENAI_ENDPOINT=https://my-resource.openai.azure.com
export AZURE_OPENAI_DEPLOYMENT=my-deployment          # the deployment name, not the model name
export AZURE_OPENAI_API_KEY=...                       # or AZURE_OPENAI_API_KEY_FILE=/path/to/file-with-only-the-key

キーはモード 0600 のヘッダーファイルから送信され、コマンドラインには表示されません。また、providers list で出力されたり、確認のために照会されたりすることもありません。任意の設定：AZURE_OPENAI_API_VERSION（2024-10-21）、AZURE_OPENAI_MAX_TOKENS、AZURE_OPENAI_TIMEOUT（120 秒）。どちらのアダプターもトークン使用量を報告し、E3D_PILOT_PROVIDER_TOKEN_LIMIT に従います。このリポジトリのテストでは、どちらも実際のサービスに対して実行されていません（テストでは偽の aws と偽のローカル HTTP サーバーを使用します）。

anthropic-api と openai-api — Anthropic Messages API と OpenAI chat completions を HTTPS 経由で利用します（curl + jq）。claude や codex の CLI は不要です。これらはサーバーやコンテナで独自の API キーを使って利用するもので、ディベートには異なるプロバイダーが 2 つあれば十分です（--providers anthropic-api,openai-api）。

export ANTHROPIC_API_KEY=...        # or ANTHROPIC_API_KEY_FILE=/path/to/file (the key alone, or an `export ANTHROPIC_API_KEY=...` line)
export ANTHROPIC_API_MODEL=claude-sonnet-5-5    # optional; this is the default
export OPENAI_API_KEY=...           # or OPENAI_API_KEY_FILE=...
export OPENAI_API_MODEL=...         # required: there is deliberately no default, because model names change
export GEMINI_API_KEY=...           # or GEMINI_API_KEY_FILE=...   (gemini-api: Google Gemini)
export GEMINI_API_MODEL=...         # required, no default
export XAI_API_KEY=...              # or XAI_API_KEY_FILE=...      (xai-api: xAI Grok)
export XAI_API_MODEL=...            # required, no default

gemini-api と xai-api は、各ベンダーの OpenAI 互換 chat completions エンドポイント（GEMINI_API_BASE_URL のデフォルトは https://generativelanguage.googleapis.com/v1beta/openai、XAI_API_BASE_URL のデフォルトは https://api.x.ai/v1）を Bearer キーで使用します。gemini-api は gemini CLI の試験用アダプターとは別のものです。4 つすべてを使用すると、ディベートでは 4 つのベンダーファミリー（Anthropic、OpenAI、Google、xAI）がカウントされます。

キーはモード 0600 のヘッダーファイルから送信され、コマンドラインには表示されません。また、providers list で出力されたり送信されたりすることもありません（キーが設定され、API に接続可能かどうかのみを確認します）。任意の設定：ANTHROPIC_API_MAX_TOKENS（4096）、OPENAI_API_MAX_TOKENS、GEMINI_API_MAX_TOKENS、XAI_API_MAX_TOKENS（後者 3 つは max_tokens として送信されます）、ANTHROPIC_API_BASE_URL / OPENAI_API_BASE_URL / GEMINI_API_BASE_URL / XAI_API_BASE_URL（互換性のある任意のエンドポイント）、および通常の E3D_PILOT_PROVIDER_TOKEN_LIMIT 上限。これらの呼び出しの料金はキーの所有者に請求されます。

local — OpenAI 互換のエンドポイントを呼び出します。セルフホスト可能なモデル（例：Ollama 経由の Qwen）を、3 人目のネゴシエーションレビュアーとして使う場合に便利です。

export LOCAL_MODEL_ENDPOINT=http://localhost:11434/v1
export LOCAL_MODEL_NAME=my-model

次に、providers.negotiate の任意の場所に "local" を追加します。レビュアー数はハードコードされていません。設定済みのレビュアーが利用できない場合は、すぐに失敗し、黙ってスキップされることはありません。

ローカルアダプターを介した実際の呼び出しはすべて、マシン全体で共有されるロック（${TMPDIR:-/tmp}/e3d-pilot-qwen.lock に作成される mkdir ベースのミューテックス。LOCAL_MODEL_LOCK_DIR で上書き可能）を通じてシリアル化されます。そのため、cron やフリートモードから、異なるターゲットリポジトリに対して実行される場合も含め、2 つの e3d-pilot 実行が共有ローカルモデルのエンドポイントに同時にアクセスすることはありません。ローカルエンドポイントは通常、複数のリポジトリのエージェントを支える、メモリ上に常駐する 1 つのモデルプロセスであるため、これは重要です。同時リクエストは競合にとどまらず、OOM のリスクがあります。実行はロックを取得するまで最大 LOCAL_MODEL_LOCK_TIMEOUT 秒（デフォルト 900）待機し、その後失敗します。プロセスの強制終了によって残された古いロックは検出され、自動的に回収されます。

任意の reason: フィールドを省略したネゴシエーションレビュアーには、解析失敗ではなく、生成された "(no reason provided by reviewer)" が設定されます。status: 行は有効でも reason フィールドを出力しない小型モデルは許容されます。 実行ステージのデフォルトは e3d-code で、現在は Codex と Claude に処理を振り分けます。実験的な providers.execute: "grok-build" 経路では、同じ承認ゲート付きの隔離された worktree 内で Grok を直接実行します。推奨される実行ツールは引き続き e3d-code です。Grok Build の統合とベンチマークを参照してください。

公開

auto は、github.com の origin には github を、それ以外には local を選択します。GitHub は実行ブランチのみをプッシュし、gh pr create --draft を呼び出します。マージやベースブランチのプッシュは行いません。Local はネットワークに接続せずに worktree ブランチをコミットし、publish-summary.md を書き込みます。lib/publish/ のスクリプトは、将来的な GitLab バックエンド向けの拡張ポイントを共有しています。

検証に合格した後に限り、公開処理では、概要のリンクがブランチ上で解決されるよう、検出事項、候補、交渉ログ、最終仕様、e3d-code マニフェストを実行の監査パスに強制追加します。pr.labels で設定したラベルは、GitHub PR の作成時に適用されます。

通知

実行が公開されると（新しいブランチが作成され、GitHub の場合はドラフト PR も作成され、人が確認できる状態になります）、e3d-pilot はベストエフォートでメールを送信できます。自分で確認しに行く必要はありません。オプトイン方式です。対象リポジトリの設定に notify.email を追加するだけで、それ以外に変更はありません。

"notify": {
  "email": {
    "to": "[email protected]"
  }
}

メールの件名にはブランチ名が含まれ、結果が needs-attention の場合（例：GitHub リポジトリで gh を利用できない場合）はその旨が示されます。本文には PR の URL、またはローカルのブランチ／パスに続けて、PR 本文と同じ概要（検出事項の抜粋、選択された候補と重複ではない理由、交渉の結果、すべての監査成果物へのリンク）が記載されます。

デフォルトでは、本文を標準入力で渡して mail -s "$E3D_PILOT_EMAIL_SUBJECT" "$E3D_PILOT_EMAIL_TO" を実行します。notify.email.command を上書きすれば、sendmail、msmtp、または SES／SendGrid などを呼び出すスクリプトを使用できます。環境変数は同じで、どの転送手段でも利用できます。

"notify": {
  "email": {
    "to": "[email protected]",
    "command": "msmtp \"$E3D_PILOT_EMAIL_TO\""
  }
}

notify がない場合、またはメールコマンドが設定されていないか PATH 上に見つからない場合でも、公開処理は成功します。通知ステップは実行を失敗させるのではなく、何も行わない状態（または一行の警告）にフォールバックします。

プロジェクトボードでの追跡

アイデアは PR に至るまでローカル台帳（ideas list／show）にしか記録されないため、誰かが確認しない限り、提案や承認の状況を把握できません。e3d-pilot を GitHub Projects（v2）ボードに接続すると、提案された時点からマージまで、実際のライフサイクル状況に合わせて各アイデアのカードが同期されます。

アイデアのステータス	ボードの列
proposed	バックログ
approved_for_implementation、changes_requested、implementation_failed	準備完了
implementing	進行中
implemented、approved_for_merge、partially_merged、merge_failed	レビュー中
merged	完了
rejected、closed、reverted	アーカイブ済み（削除されません）

オプトイン方式で、デフォルトでは無効です。環境変数を使って、各リポジトリで一度設定してください（LOCAL_MODEL_ENDPOINT と同じ形式で、どこでも共通の設定です）。

export E3D_PILOT_TRACKING_PROJECT_URL="https://github.com/users/<owner>/projects/<n>"

または、リポジトリごとに .e3d-pilot/config.json で設定できます（そのリポジトリでは環境変数より優先されます）。

"tracking": {
  "project_url": "https://github.com/orgs/<org>/projects/<n>"
}

提案されたアイデアには下書きカードが作成されます。実際の PR に至ると、e3d-pilot は、そのプロジェクト独自の「自動追加」ワークフローで作成されたものも含め、PR 用の既存のボード項目があればそれを再利用するため、古い下書きカードが残ることはありません。同期はすべてベストエフォートです。URL の設定ミス、project／read:project の gh 認証スコープの不足、一時的な API エラーが発生しても、標準エラーへの警告にとどまり、コマンドが失敗することはありません。追跡状態は、ほかのすべての情報と同じ追記専用の台帳の一部として記録されるため、ideas rebuild を実行しても、アイデアに紐づくボード項目の情報は失われません。

フリートモード

リポジトリパスの JSON 配列を指定します。

e3d-pilot fleet examples/sample-fleet.json

各リポジトリは独立して実行されます。フリートモードでは、失敗後も処理を続行し、リポジトリごとの結果と最終集計を出力します。いずれかのリポジトリで失敗した場合は、ゼロ以外の終了コードで終了します。

複数リポジトリにまたがるアイデアの創出

e3d-pilot fleet <repos.json> は、複数のリポジトリにまたがる機会を意図的に検出しません。それぞれのリポジトリで、独立したパイプラインが実行されます。e3d-pilot fleet discover はその補完機能です。フリートファイル内のすべてのリポジトリを対象に、ポートフォリオ全体で一度に discover+ideate を実行し、2 つ以上のリポジトリがそろって初めて意味を持つアイデア（たとえば、あるリポジトリのデータフィードと別のリポジトリの決済基盤を組み合わせるもの）を特に探します。単一のリポジトリだけで実現できるアイデアは提案しません。それには通常の fleet／run を使用します。

e3d-pilot fleet discover examples/sample-fleet.json
e3d-pilot fleet discover examples/sample-fleet.json --focus revenue

専用の小さな設定が必要です。providers.discover と providers.ideate に加え、任意で candidate_scoring を設定します（examples/sample-fleet-config.json を参照）。設定ファイルはフリートファイルと同じ場所の .e3d-pilot-fleet/config.json に置くか、--config <path> を渡して別の場所を指定してください。出力は .e3d-pilot-fleet/runs/<run-id>/findings.md と candidates.md に保存され、単一リポジトリの実行と同じ構成になります。findings.md には、リポジトリごとの ## Portfolio ダイジェスト（README／AGENTS／CLAUDE の内容、head sha）と、モデルが調査した ## Cross-Repo Context セクションが含まれます。candidates.md では、単一リポジトリの ideate と同じ方法で候補をランク付けしますが、各候補には Repos: フィールドで 2 つ以上のリポジトリを指定する必要があります。また、重複チェックは同じワークスペース内の過去の fleet discover 実行に対してのみ行われます。各リポジトリ固有のブランチや PR との重複はチェックされません。これは把握しておくべき実際の範囲制限です。

このステージは、フリートのアイデアを .e3d-pilot-fleet/ideas/ に作成した時点で終了し、イベントは .e3d-pilot-fleet/events.jsonl に記録されます。複数リポジトリにまたがる実装には、引き続き明示的な承認が必要です。

e3d-pilot fleet ideas examples/sample-fleet.json list --status proposed
e3d-pilot fleet ideas examples/sample-fleet.json show idea-abc123def456
e3d-pilot fleet ideas examples/sample-fleet.json approve idea-abc123def456 --actor [email protected]
e3d-pilot fleet ideas examples/sample-fleet.json implement idea-abc123def456
e3d-pilot fleet ideas examples/sample-fleet.json implement-approved

フリートのアイデアには、承認時点でリポジトリごとの対象が順序付きで記録されます。対象は順番に実装されます。一部の対象がマージされた後、後続の対象で失敗や変更が生じた場合、フリートのアイデアは partially_merged になります。e3d-pilot は、マージされたリポジトリとされていないリポジトリを記録します。複数リポジトリにまたがるアトミック性を保証することはありません。

フリートの改善をレビューする

フリートの実行後、fleet prs を使うと、リポジトリ全体で e3d-pilot が作成したオープン状態のドラフト PR をターミナルで確認できます。承認ワークフローではなく、状況の確認に使用してください。

e3d-pilot fleet prs ~/e3d-fleet.json

repo                    PR     state  idea                                          A   R   effort
────────────────────────────────────────────────────────────────────────────────────────────────
e3d-docs                #1     DRAFT  In-docs "Ask the Docs" AI assistant           5   5   high
e3d-sdk                 #1     DRAFT  MCP-native tool bindings for AI agents        5   4   high
e3d-trade               #1     DRAFT  Trade Decision Receipts                       4   5   medium
  └─ https://github.com/spacepacket1/e3d-sdk/pull/1

~/e3d-fleet.json が存在する場合は、デフォルトで使用されます。それ以外の場合は、明示的にパスを指定してください。

フリートの承認には、アイデア台帳を使用することをおすすめします。

e3d-pilot fleet ideas ~/e3d-fleet.json approve-merge idea-abc123def456 --actor [email protected]
e3d-pilot fleet ideas ~/e3d-fleet.json merge idea-abc123def456
e3d-pilot fleet ideas ~/e3d-fleet.json merge-approved

fleet ideas approve は実装の承認です。fleet ideas approve-merge は、レビュー済みの正確な head SHA に対するマージの承認です。GitHub のレビュー承認や fleet prs --approve アクションを、いずれかの台帳承認として扱ってはいけません。

Web UI（任意）

fleet prs と ideas list でターミナル上の操作をカバーできます。e3d-pilot web は、Node.js を追加しても構わない場合に、ブラウザーで 1 つ以上のリポジトリにまたがるアイデアを確認・判断するための任意のダッシュボードです。必須ではありません。ほかの e3d-pilot コマンドはすべて Bash、Git、jq、curl のみで動作し、Node が PATH にない場合、e3d-pilot web は明確なエラーを表示して起動を拒否します。

export E3D_PILOT_WEB_AUTH_USER=you
export E3D_PILOT_WEB_AUTH_PASS='a real secret, not this'
e3d-pilot web --repo /path/to/repo-a --repo /path/to/repo-b --port 4173

http://127.0.0.1:4173（ベーシック認証。認証情報は上記）を開くと、設定済みの各リポジトリ独自のアイデア台帳を統合した、フィルター可能な一覧が表示されます。また、各アイデアの詳細ページでは、概要、スコア、重複排除の理由、承認・マージの状態、イベント履歴、関連する実行成果物、アクションボタン（承認、却下、変更をリクエスト、マージを承認、同期、実装）を確認できます。各アクションは、手動で実行する場合とまったく同じ e3d-pilot ideas ... サブコマンドを同期的にシェルで呼び出すだけです。Web UI が台帳や承認のロジックを再実装することはないため、CLI の保証と食い違うことはありません。

Implement をクリックすると、e3d-pilot ideas implement が切り離されたバックグラウンドプロセスとして起動します（draft → negotiate → execute → review → publish には 30 分以上かかることがあります）。実行中は、アイデアのページに implementation-stage-log.md の内容がリアルタイムで表示されます。

E3D_PILOT_WEB_AUTH_USER と E3D_PILOT_WEB_AUTH_PASS の両方が必須です。認証なしでの利用には対応していません。信頼できるマシン上、または自身のリバースプロキシ／トンネルの背後で動作させることを想定しています。TLS、レート制限、複数ユーザーアカウントは組み込まれていません。

e3d-debate（実験的）

エディター内で使いたいですか？ e3d-debate は、Copilot、Claude Code、Cursor 向けの MCP ツール としても公開されています。

bin/e3d-debate は独立したスタンドアロンスクリプトです。bin/e3d-pilot のサブコマンドツリーや config.schema.json には組み込まれていません。これは、すでに bin/e3d-backend-benchmark や bin/e3d-grok-workers が組み込まれていないのと同様です。このスクリプトは、「複数のモデルに質問し、実際に意見が一致するかを確かめる」ループを、特にリポジトリ作業に限らず、あらゆる質問に適用します。discover／ideate／negotiate／review がすでに依存している、同じ lib/providers/<name> アダプターと lib/negotiate/convergence プリミティブを再利用します。ここで「実験的」とは、まだスタンドアロンで、パイプライン本体に組み込まれていないという意味であり、未使用や未テストという意味ではありません。以下の出所リンク関連フラグは tests/phase34.sh でカバーされており、このプロジェクトの実際のアーキテクチャや製品の方向性に関する判断をいくつも左右してきました。単なるデモではありません。

bin/e3d-debate "Should this service store timestamps as UTC or local time+offset?" \
  --providers claude,codex,devin,grok-build --rounds 3

第 1 ラウンドでは、指定された各プロバイダーが個別に回答します。第 2 ラウンド以降は、各プロバイダーが他のすべてのプロバイダーによる前回の回答を確認し、自分の立場を言い直す、反論する、または譲歩するよう求められます。回答の末尾は POSITION: <one-line answer> と status: approved|revise です。「approved」とは、この回答に基づいて行動する人と、他の各参加者の現在の回答に基づいて行動する人が、同じ行動を取るという意味です。補足や注意事項の追加は、意見の不一致には該当しません。すべてのプロバイダーが approved を返すと、lib/negotiate/convergence は残りのラウンドを消化せず、議論を早期終了します。最終ラウンドの後（早期終了した場合も含む）、指定された 1 つの --synthesizer（デフォルトは claude）が全トランスクリプトを読み込み、FINAL ANSWER／CONSENSUS／DISSENT の要約を作成します。

devin を含め、どの lib/providers アダプターでも参加できます。たとえば Devin／Windsurf のサブスクリプションを使わずにおく場合に便利です。トランスクリプト全体（プロンプト、各ラウンドの生の回答、統合結果）は、デフォルトで一時ディレクトリに書き込まれます。指定する場合は --out-dir <path> に出力されます。

デフォルトでは、議論の結論は stdout／トランスクリプトファイルに出力されるだけで、どのリポジトリの出所グラフにも記録されません。合成に成功した後、そのリポジトリの台帳にすでに存在するアイデアに結論を自動記録するには、--repo <path> --idea <idea-id>（両方とも同時に指定する必要があります。さらに、--out-dir には --repo 内のパス、たとえば docs/debates/<slug> を指定します）を渡します。これは、手動で e3d-pilot ideas note --decision --evidence <transcript-path> <idea-id> "<verdict>" を実行するのと同等です。

bin/e3d-debate "Should we ship it?" --providers claude,codex --repo /path/to/repo --idea idea-abc123 --out-dir /path/to/repo/docs/debates/ship-it

これによりエビデンスがリンクされますが、アイデアは作成されません。まず別途（たとえば ideas ingest を使って）提案してください。エビデンスへのリンクを永続的に保つには、既存の docs/debates/ のトランスクリプトと同様に、トランスクリプト自体もコミットする必要があります。

スケジュールに従った実行

e3d-pilot は意図的にデーモンではありません。呼び出しのたびに、ステージを実行（または再開）して終了する、短時間で完了する単一の CLI 呼び出しです。スケジューラーは組み込まれていないため、「継続的な」実行は呼び出し元に委ねられます。cron、systemd タイマー、スケジュール設定された CI ワークフロー、独自のオーケストレーターのいずれでも同様に機能します。

自律的なアイデア創出は、承認済みの実装、同期、データセットのエクスポートとは分けて実行してください。たとえば次のようにします。

# Autonomous single-repo ideation; stops before implementation approval.
0 */6 * * * /path/to/e3d-pilot/bin/e3d-pilot run --repo /path/to/repo --stage all --focus revenue >> /var/log/e3d-pilot-ideate.log 2>&1

# Implement only ideas that humans already approved.
15 * * * * PATH="/usr/local/bin:$PATH" /path/to/e3d-pilot/bin/e3d-pilot ideas implement-approved --repo /path/to/repo >> /var/log/e3d-pilot-implement.log 2>&1

# Observe forge state and invalidate stale merge approvals.
*/30 * * * * PATH="/usr/local/bin:$PATH" /path/to/e3d-pilot/bin/e3d-pilot ideas sync --repo /path/to/repo >> /var/log/e3d-pilot-sync.log 2>&1

# Weekly labeled dataset export for local Qwen evaluation/training.
0 3 * * 1 /path/to/e3d-pilot/bin/e3d-pilot fleet train export /path/to/fleet.json >> /var/log/e3d-pilot-export.log 2>&1

Fleet での同等の設定：

0 2 * * * PATH="/usr/local/bin:$PATH" LOCAL_MODEL_ENDPOINT="http://127.0.0.1:5050/v1" /path/to/e3d-pilot/bin/e3d-pilot fleet discover /path/to/fleet.json --focus revenue >> /var/log/e3d-pilot-fleet-ideate.log 2>&1
20 * * * * PATH="/usr/local/bin:$PATH" /path/to/e3d-pilot/bin/e3d-pilot fleet ideas /path/to/fleet.json implement-approved >> /var/log/e3d-pilot-fleet-implement.log 2>&1
*/30 * * * * PATH="/usr/local/bin:$PATH" /path/to/e3d-pilot/bin/e3d-pilot fleet ideas /path/to/fleet.json sync >> /var/log/e3d-pilot-fleet-sync.log 2>&1

ゼロ以外の終了コードは、実際の失敗を示す場合もあれば、正当な停止を示す場合もあります（ideate の「処理することがない」、人間の入力が必要な negotiate のデッドロック、失敗した verify など）。クラッシュと判断する前に、対象のリポジトリにある .e3d-pilot/runs/<run-id>/ を確認してください。スケジュールジョブに crontab を変更させずに何も実行させないようにするには、対象のリポジトリに .e3d-pilot/paused ファイルを置きます。

週間エクスポート

fleet ファイルに記載された fleet 台帳とすべてのリポジトリ台帳を集約するには、fleet トレーニングコマンドを使用します。

e3d-pilot fleet train readiness /path/to/fleet.json --since 2026-08-01T00:00:00Z
e3d-pilot fleet train export    /path/to/fleet.json --week 2026-W32

デフォルトでは、エクスポートによって .e3d-pilot-fleet/datasets/<YYYY-Www>/ の下に ideation.jsonl、preferences.jsonl、implementation.jsonl、manifest.json が書き込まれます。保留中のアイデアは、ラベルなしのアイデア創出レコードとしてエクスポートできますが、却下例としてエクスポートされることはありません。明示的な承認、却下、変更要求、失敗、マージ、部分的なマージ、クローズ、取り消し、型付きの結果がラベルになります。

安全性モデル

ディスカバリー、アイデア創出、任意の candidate_scoring はソースを変更しません。スコアリングは読み取り専用で、候補を実行できません。ドラフト作成、交渉、実行、レビュー、公開には、現在有効な実装承認が必要です。実行には、個別のワークツリーと実行ごとのブランチを使用します。保護対象パスは、ドラフト作成時と実行バックエンドの起動直前の両方でチェックされます。実際のファイル数や行数が上限に達した場合、レビュー前に停止します。検証に失敗すると、公開はブロックされます。公開では、ドラフト PR またはローカルレビュー用ブランチが作成されます。デフォルトの実行バックエンドは e3d-code です。providers.execute で Grok Build を選択しても、この外側のゲートを回避することはできません。

マージは独立した操作です。approve-merge は、観測された対象セットと PR の正確な head SHA に承認をひも付けます。マージは、古い head、変更されたベースブランチ、ドラフト PR、クローズ済み PR、承認の欠如、サポートされていないローカルマージバックエンドがある場合に拒否されます。e3d-pilot は、強制プッシュを行わず、保護されたベースブランチへ直接プッシュすることもありません。

プロジェクトボードの追跡（上記参照）はベストエフォートであり、安全性を担保する処理には含まれません。明示的に設定されない限り無効です。URL の設定ミス、gh の認証スコープ不足、一時的な API エラーが発生した場合は、ideate、approve、implement、merge をブロックするのではなく、標準エラー出力に警告を表示します。

任意の Web UI（上記参照）自体が新たな権限を加えることはありません。UI が提供するすべての操作は、同じ e3d-pilot ideas ... サブコマンドをシェルから直接実行します。そのため、意思決定がターミナルから行われたかブラウザーから行われたかにかかわらず、同じ承認ゲート、遷移ガード、マージ SHA のひも付けが適用されます。

リポジトリのテストスイートを実行するには、次のコマンドを使用します。

set -e
for test_file in tests/*.sh; do bash "$test_file"; done

ライセンス

MIT © 2026 FutCo LLC。FutCo のオープンソースエコシステムの一部です。