AgentBridge (日本語)

§1 概要

AgentBridge とは？

IDE エージェント（例: GitHub Copilot、Cursor、Claude Code）が API を呼び出すと、上流の AI プロバイダー（OpenAI、Anthropic など）へ直接接続します。AgentBridge は、エージェント側の設定を変更することなく、その接続を TLS レベルで透過的に傍受し、リクエストが OmniRoute を経由するように書き換えます。

これにより、以下が可能になります。

任意のエージェントを任意のプロバイダーへ再ルーティング: Copilot が OpenAI と通信していますか？Anthropic Claude、Gemini、または OmniRoute が提供する 352 のプロバイダーのいずれかへリダイレクトできます。
モデルマッピングを適用: ハンドラーレベルで gemini-3-flash → claude-sonnet-4.7 のように透過的にマッピングできます。
すべてのエージェントトラフィックを監視: 傍受されたすべてのリクエストが Traffic Inspector に送信されます。
OmniRoute の耐障害性を適用: コンボルーティング、サーキットブレーカー、フォールバック、コスト追跡を IDE エージェントのトラフィックにも適用できます。

市場における位置付け

機能	9router	anti-api	llm-interceptor	OmniRoute AgentBridge
Antigravity	✓	✓	—	✓
GitHub Copilot	✓	✓	—	✓
Kiro (AWS)	✓	✓	—	✓
OpenAI Codex	—	✓	—	✓
Cursor IDE	✓	✓	—	✓
Zed Industries	—	✓	—	✓
Claude Code	—	—	✓	✓
Open Code	—	—	✓	✓
Trae	—	—	—	🔍 調査中
ダッシュボード UI	✓	✗	✗	✓
Traffic Inspector	✗	✗	✓	✓
OmniRoute ルーティング	✗	✗	✗	✓
モデルマッピング UI	✗	✗	✗	✓
バイパスリスト	✗	✗	✓	✓
上流 CA 証明書	✗	✗	✓	✓

§2 アーキテクチャ

2.1 コンポーネント概要

IDE Agent (VS Code / Cursor / etc.)
    │  HTTPS (ポート 443)
    ▼
/etc/hosts — 127.0.0.1 api.githubcopilot.com   ← DNS リダイレクト
    │
    ▼
src/mitm/server.cjs  (ポート 443、CJS 子プロセス)
    │  Host ヘッダーの SNI によってターゲットを解決
    │  AgentBridge CA によって署名された SNI ごとの TLS 証明書を生成
    ├── バイパスリストに一致？ → TCP パススルー（復号なし）
    ├── ターゲットに一致？ → fetch → OmniRoute ルーター（ポート 20128）
    │       └── handler.intercept() — TypeScript
    │               ├── リクエスト本文／ヘッダーに対して maskSecrets()
    │               ├── TrafficBuffer.push() — Traffic Inspector に公開
    │               └── fetchRouter() → /v1/chat/completions
    └── 一致なし？ → TCP パススルー（復号なし）

2.2 MITM サーバー（`src/mitm/server.cjs`）

中核となる MITM サーバーは、Node.js の CJS 子プロセスとして実行されます（既存の CJS コードベースを書き直さずに済むようにするためです）。このサーバーは以下を行います。

ポート 443 で待ち受けます（権限、または authbind/setcap が必要です）
OS から CONNECT トンネルを受信します（/etc/hosts の DNS リダイレクト経由）
AgentBridge CA（DATA_DIR/mitm/ca.crt）によって署名された SNI ごとの TLS 証明書を生成します
targets/index.ts レジストリを介し、Host ヘッダーに基づいて対象エージェントを解決します
http://127.0.0.1:20128 への HTTP 経由で TypeScript ハンドラーレイヤーにディスパッチします

TARGET_HOSTS は DATA_DIR/mitm/targets.json（起動時に targets/index.ts によって書き込まれます）から読み込まれるため、CJS サーバーを再起動せずに動的に更新できます。

ルート CA モデル（#6684）。 上述の SNI ごとに CA 署名証明書を使用する方式は、 #6684 で追加された永続化ルート CA モデルです（src/mitm/cert/rootCa.ts + src/mitm/_internal/rootCaShim.cjs。src/mitm/tproxy/dynamicCert.ts で TPROXY 用としてすでに実証済みの CA／リーフ暗号処理を再利用しています）。これは、ディスク上に単独の server.crt/server.key ペアが存在する場合に示される、以前の単一静的自己署名リーフ（src/mitm/cert/generate.ts。現在も antigravity ホストのみに限定されています）に代わるものです。移行時の動作：新規インストール（既存の server.crt がない場合）では、ルート CA モデルが自動的に使用されます。古い静的リーフをすでに信頼しているインストールでは、オペレーターが MITM_ROOT_CA_ENABLED=true を設定してブリッジを再起動するまで、引き続きそのリーフが使用されます（src/mitm/cert/migration.ts は純粋な判定関数です。 任意のホスト用のリーフに署名できる、信頼済みの MITM CA は、従来の固定 SAN リーフよりも実質的に強力であるため、すでに信頼済みのインストールでは暗黙的に切り替わることはありません）。CA 証明書は、古いリーフが使用していたものと同じ omniroute-mitm.crt トラストストアスロットにインストールされます（cert/install.ts::installCaCert）。二重信頼のクリーンアップは不要です。

2.3 ハンドラー基底クラス（`src/mitm/handlers/base.ts`）

すべてのエージェントハンドラーは MitmHandlerBase を拡張します。

export abstract class MitmHandlerBase {
  abstract readonly agentId: AgentId;

  abstract intercept(
    req: IncomingMessage,
    res: ServerResponse,
    body: Buffer,
    mappedModel: string
  ): Promise&lt;void&gt;;

  // 保護されたヘルパー：fetchRouter、pipeSSE、hookBufferStart、hookBufferUpdate
}

各ハンドラーは、プロキシ処理の前に hookBufferStart() を呼び出し、完了時に hookBufferUpdate() を呼び出します。これらは、InterceptedRequest エントリを globalTrafficBuffer にプッシュします（Traffic Inspector §4 を参照）。

2.4 ターゲットレジストリ（`src/mitm/targets/`）

各エージェントには宣言的なターゲットファイルがあります。

export const COPILOT_TARGET: MitmTarget = {
  id: "copilot",
  name: "GitHub Copilot",
  hosts: ["api.githubcopilot.com", "copilot-proxy.githubusercontent.com"],
  port: 443,
  endpointPatterns: ["/chat/completions", "/v1/chat/completions"],
  defaultModels: [{ id: "gpt-4o", name: "GPT-4o", alias: "gpt-4o" }],
  handler: () => import("../handlers/copilot"),
  riskNoticeKey: "providers.riskNotice.oauth",
};

レジストリ（targets/index.ts）は ALL_TARGETS をエクスポートし、起動時に DATA_DIR/mitm/targets.json を出力します。

2.5 パススルーとバイパスリスト（`src/mitm/passthrough.ts`）

バイパスリスト（最初に確認され、ターゲット一致より優先されます）：

デフォルトパターン：銀行関連ホスト、.gov.、OAuth/SSO プロバイダー（Okta、Auth0）など
ユーザーパターン：DB テーブル agent_bridge_bypass に保存
バイパス対象のホストには透過的な TCP トンネルが提供され、TLS が復号されることはありません

デフォルトのパススルー（ターゲットに一致せず、バイパス対象でもない場合）：

この場合も TCP トンネルが提供され、接続が中断されることはありません
AgentBridge が一般的なシステム HTTPS トラフィックを妨害するのを防ぎます

ルーティングの優先順位：

バイパスリスト → ターゲット一致 → パススルー

2.6 アップストリーム CA 証明書（`src/mitm/upstreamTrust.ts`）

カスタム CA を使用する企業ネットワーク環境向け：

AGENTBRIDGE_UPSTREAM_CA_CERT=/path/to/corporate-ca.pem

設定すると、追加の CA 証明書を使用するように undici のグローバルディスパッチャーが構成され、AgentBridge が企業の TLS 終端プロキシを経由してアップストリームプロバイダーに接続できるようになります。

2.7 シークレットのマスキング（`src/mitm/maskSecrets.ts`）

独立したクリーンルームスキャナーは、リクエスト本文および認証情報ヘッダーが Traffic Inspector バッファやログに入る前に適用されます。このスキャナーは、単一の線形パスで以下を処理します。

sk- / ak- / pk- プレフィックス付きトークン（OpenAI/Anthropic 形式）
RFC 6750 の Authorization: Bearer <token> 認証情報（トークン全体を優先）
汎用の長い不透明トークン（40 文字以上）。ドット区切り形式およびパディング形式を含む

sanitizeHeaders() は、保持する名前を小文字に変換し、配列値を決定論的に連結し、共有のホップバイホップ／フレーミング用拒否リスト（プロキシ認証を含む）に該当するものを削除し、 cookie と set-cookie を完全に秘匿化したうえで、認証情報の値をスキャナーに委譲します。

§3 セットアップ

3.1 MITM サーバーの起動/停止

/dashboard/tools/agent-bridge にある AgentBridge Server Card を使用します。

操作	説明
サーバーを起動	ポート 443 で `src/mitm/server.cjs` を起動
サーバーを停止	子プロセスを正常にシャットダウン
サーバーを再起動	停止してから起動（ターゲットの変更を反映）
証明書を信頼	`DATA_DIR/mitm/ca.crt` を OS の信頼ストアにインストール
証明書をダウンロード	手動インストール用の `ca.crt` をダウンロード
証明書を再生成	新しい CA キーペアを作成（既存のエージェント別証明書はすべて無効化）

3.2 証明書を信頼する

IDE が MITM 接続を受け入れるには、事前に AgentBridge CA 証明書を OS で信頼する必要があります。

Linux（NSS — Chrome/Firefox）：

certutil -A -d sql:$HOME/.pki/nssdb -n "OmniRoute AgentBridge" -t CT,, -i ~/.omniroute/mitm/ca.crt

macOS（キーチェーン）：

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain ~/.omniroute/mitm/ca.crt

Windows（certmgr）：

certutil -addstore -f Root $env:USERPROFILE\.omniroute\mitm\ca.crt

または、ダッシュボードの「Trust Cert」ボタンを使用します（OS に応じた適切なコマンドを実行し、必要に応じて sudo プロンプトを表示します）。

Electron ベースの IDE は OS の信頼ストアを無視する（`NODE_EXTRA_CA_CERTS`）

一部の IDE、特に Antigravity IDE やその他の Electron / VS Code 派生アプリには独自の Node.js ランタイムがバンドルされており、外向きの fetch/HTTPS で OS の信頼ストアを参照しません。OS/NSS レベルで CA を信頼すれば、IDE のネイティブなバックエンド（たとえば OS の CA バンドルを使用する Go 言語サーバー）には十分ですが、Electron フロントエンドでは引き続き TLS が失敗します。MITM ログにはバックエンドのブートストラップ呼び出しが 200 を返しているにもかかわらず、アプリでは_ログアウト状態_になったり、_“接続エラー”_が表示されたりします。次の 2 つの手順が必要であり、どちらも重要です。

ランタイムから CA を明示的に指定します。
ターミナルウィンドウ
```
export NODE_EXTRA_CA_CERTS=/path/to/omniroute-agentbridge-ca.crt
```
そのシェルから IDE を起動します。 デスクトップアイコン / Dock / スタートメニューから起動した場合、シェルの export は継承されません。また、~/.config/environment.d/*.conf は新しくグラフィカルログインした後にのみ適用されます。最初に IDE を完全に終了してください。Electron のシングルトンロックにより、2 回目の起動では既存のプロセスにフォーカスするだけで、新しい環境は無視されます。

上記の OS 信頼ストア + NSS の手順も引き続き必要です（一部の認証フローで使用される Chromium ネットワークスタックはユーザー別 NSS ストアを参照し、*.googleapis.com に対する独自の静的ピンも持っていますが、ローカルで信頼された CA によって上書きされます）。NODE_EXTRA_CA_CERTS は、それに加えて Node の fetch 経路をカバーします。

3.3 DNS ルーティング

インターセプトする各エージェントについて、その API ホストが 127.0.0.1 に名前解決される必要があります。Setup Wizard でエージェントの DNS を切り替えると、AgentBridge が /etc/hosts エントリを自動的に管理します。

GitHub Copilot 用の /etc/hosts エントリ例：

127.0.0.1 api.githubcopilot.com
127.0.0.1 copilot-proxy.githubusercontent.com

3.4 モデルマッピング

各エージェントカードの Model Mapping Table を使用して、ソース → ターゲットのマッピングを定義します。

ソースモデル（エージェント固有）	ターゲットモデル（OmniRoute）
`gpt-4o`	`claude-sonnet-4.7`
`*`（ワイルドカード）	`claude-haiku-4.7`

ワイルドカード * は、認識されないモデルを指定されたターゲットにマッピングします。設定は agent_bridge_mappings テーブルに永続化されます。

ヒント — エージェントの実際のモデル ID を確認する。 IDE が送信するモデル名は UI のラベルと異なる場合があり、メジャーバージョン間で変更されることもあります。たとえば Antigravity 2 は、古いドキュメントに記載されている gemini-2.5-pro ではなく、通信上では gemini-3.1-pro-low、gemini-pro-agent、gemini-3.1-flash-lite を送信します。一致するマッピングがない状態でチャットを 1 回送信してください。MITM は受信した正確な model: をログに記録し、リクエストをそのまま通過させます。そのリテラル値をマッピングすると、次のリクエストからインターセプトされ、ターゲットへルーティングされます。

3.5 リスクに関する注意

AgentBridge は、IDE がアップストリームプロバイダーの認証に使用する認証情報（OAuth トークン、API キー）をインターセプトします。これらはログ記録前にマスクされます（§2.7 を参照）が、OmniRoute の MITM レイヤーからは参照可能です。各エージェントを初めて有効化すると、閉じることができるリスク通知モーダルが表示されます。

3.6 メンテナンスと診断

ダッシュボードには Maintenance & Diagnostics カード（src/app/(dashboard)/dashboard/tools/agent-bridge/components/ 内の AgentBridgeMaintenanceCard）があり、これまで UI がなかった運用用 MITM ルートを表示します。サブタイトルは 「キャプチャパイプラインをセルフテストし、残存するシステム状態を元に戻し、セットアップをマシン間で移行します。」 です。カードのクライアントヘルパーは src/lib/inspector/agentBridgeMaintenanceApi.ts にあります。

ボタン	ルート	機能
診断	`GET /api/tools/agent-bridge/diagnose`	キャプチャパイプラインのセルフテストを実行し、チェック項目ごとのレポート（✓/✗ と修復のヒント）を表示します。
修復	`POST /api/tools/agent-bridge/repair`	クラッシュまたは SIGKILL によって残された、孤立した MITM システム状態（DNS スプーフィングエントリ、ルート CA、システムプロキシ）を元に戻します。冪等であり、状態がクリーンな場合は「修復するものはありません」と報告します。
CA を削除	`DELETE /api/tools/agent-bridge/cert`	OS の信頼ストアで MITM ルート CA の信頼を解除し、削除します（明示的かつ冪等）。CA が現在信頼されている場合にのみ表示され、インラインの「CA を削除しますか？」という確認が必要です。
設定をエクスポート	`GET /api/tools/agent-bridge/config`	ポータブル設定 JSON をダウンロードします（§3.7 を参照）。
設定をインポート	`POST /api/tools/agent-bridge/config`	以前にエクスポートした設定 JSON をアップロードします（§3.7 を参照）。

診断チェック（src/mitm/inspector/diagnostics.ts の summarizeDiagnostics()）。ルートは各項目に対して副作用を伴うプローブを実行し、その真偽値を純粋なサマライザーに渡します。単一の healthy 判定と、失敗項目ごとのヒントが返されます。

チェック名	検証内容	失敗時のヒント
`server-running`	MITM サーバープロセスが稼働していること	「MITM サーバーが実行されていません。AgentBridge タブから起動してください。」
`server-reachable`	MITM サーバーがそのポートで接続を受け付けること（TCP プローブ）	「MITM サーバーがそのポートで接続を受け付けていません。ポートが空いていること、およびそのポートをバインドする権限があることを確認してください。」
`cert-exists`	MITM 証明書がディスク上に生成されていること	「MITM 証明書がまだ生成されていません。AgentBridge タブから生成してください。」
`cert-trusted`	MITM ルート CA が OS の信頼ストアに登録されていること	「MITM ルート CA が OS の信頼ストアで信頼されていないため、TLS インターセプトは失敗します。AgentBridge タブから証明書を信頼してください。」
`dns-configured`	対象ホスト名が `/etc/hosts` でスプーフィングされていること	「対象ホスト名が /etc/hosts でスプーフィングされていないため、トラフィックがプロキシに到達しません。キャプチャするエージェントの DNS を有効にしてください。」

孤立状態バナー： クラッシュによって残された状態（DNS スプーフィング / CA / システムプロキシ）をページが検出すると、カードに琥珀色のバナー — 「以前のセッションによるシステム状態（DNS スプーフィング、CA、またはシステムプロキシ）が残っています。修復を実行してクリーンアップしてください。」 — が表示され、修復ボタンが強調表示されます。Repair は ProxyBridge の --cleanup フラグに相当するアプリケーション層の機能です（src/mitm/manager.ts の repairMitm() に処理を委譲します）。

MITM ルート CA は、sudo プロンプトが繰り返し表示されるのを避けるため、停止後もインストールされたままになります（mitmproxy/Charles と同じ動作）。そのため、停止時に自動的に削除されるのではなく、明示的な CA を削除操作によって削除します。

3.7 ポータブル設定のインポート/エクスポート

AgentBridge は、オペレーターが調整可能な状態をバージョン付きの JSON BLOB にシリアライズできるため、マシン間でセットアップを複製できます。シリアライザーは src/lib/inspector/configPortability.ts（exportConfig() / importConfig()）であり、AgentBridgeConfigSchema によって検証されます。

エクスポートには、次の 3 つの要素だけが含まれます（組み込みのデフォルト値は意図的にエクスポートされません。そのため、インポートによってそれらが重複したり競合したりすることはありません）。

フィールド	ソース	注記
`bypassPatterns`	ユーザー定義のバイパスパターン（`agent_bridge_bypass`）	デフォルトの bank/gov/okta パターンは除外されます
`customHosts`	Traffic Inspector のカスタムホスト（`inspector_custom_hosts`）	各項目：`{ host, kind: "llm"\|"app"\|"custom", label? }`
`agentMappings`	エージェントごとのモデルマッピング（`agent_bridge_mappings`）	マッピングを持つ各エージェントの `{ [agentId]: [{ source, target }] }`

// GET /api/tools/agent-bridge/config
{
  "version": 1,
  "bypassPatterns": ["*.internal.example.com"],
  "customHosts": [{ "host": "api.example.com", "kind": "llm", "label": null }],
  "agentMappings": {
    "copilot": [{ "source": "gpt-4o", "target": "claude-sonnet-4.7" }],
  },
}

インポート時の動作（POST /api/tools/agent-bridge/config）：バイパスパターンとエージェントごとのマッピングはすべて置き換えられます。カスタムホストは冪等に追加されます（INSERT OR IGNORE）。レスポンスでは、それぞれ何件が適用されたかが報告されます。

{ "ok": true, "bypassPatterns": 1, "customHosts": 1, "agents": 1 }

設定に含まれないもの: サーバーの実行状態、証明書のパス、エージェントごとの DNS 状態、アップストリーム CA のパス、および TPROXY 設定。これらは移植可能な環境設定ではなく、ホスト／ランタイムの状態です。

§4 エージェント別リファレンス

#	エージェント	ステータス	インターセプト対象ホスト	認証タイプ
1	Antigravity	✅ 対応済み	`daily-cloudcode-pa.googleapis.com`, `cloudcode-pa.googleapis.com`	Firebase OAuth
2	Kiro (AWS)	✅ 対応済み	`prod.kiro.aws`, `dev.kiro.aws`	AWS SigV4
3	GitHub Copilot	✅ 対応済み	`api.githubcopilot.com`, `copilot-proxy.githubusercontent.com`	GitHub OAuth
4	OpenAI Codex	✅ 対応済み	`api.openai.com`（Codex パス）、`chatgpt.com`	OpenAI キー
5	Cursor IDE	✅ 対応済み	`api2.cursor.sh`, `api.cursor.sh`	Cursor OAuth
6	Zed Industries	✅ 対応済み	`api.zed.dev`, `llm.zed.dev`	Zed OAuth
7	Claude Code	✅ 対応済み	`api.anthropic.com`（オプトイン）	Anthropic キー
8	Open Code	✅ 対応済み	`openrouter.ai`, `api.openai.com`（zen パス）	API キー
9	Trae	🔍 調査中	未定 — §8 を参照	未定

セットアップウィザードの手順（エージェントごと）

各エージェントカードには、3 ステップのセットアップウィザードがあります。

前提条件を確認 — サーバーは稼働中か？証明書は信頼されているか？IDE はインストール済みか（自動検出）？
DNS を有効化 — /etc/hosts にエントリを追加します（sudo が必要）。追加される行を正確に表示します。
モデルをマッピング — オプションのモデルマッピングテーブルです。ワイルドカードを使用できます。

エージェントの検出

エージェント 1～8 について、AgentBridge は IDE のインストールを自動検出しようとします。

export async function detectAgent(agentId: AgentId): Promise<DetectionResult>;
// 戻り値: { installed: boolean, version?: string, path?: string }

検出には、OS 固有のパスとバイナリチェックを使用します（例：Copilot の場合は code --list-extensions | grep github.copilot、Antigravity の場合は ~/.config/antigravity/）。

§5 セキュリティ

適用される厳格なルール

ルール	適用方法
#12 `sanitizeErrorMessage`	すべてのハンドラーエラーは、レスポンスまたはバッファへの格納前にサニタイズされます
#13 シェル環境変数渡し	`/etc/hosts` の編集には `env` オプションを使用し、パスの文字列補間は行いません
#15 + #17 `isLocalOnlyPath()`	`/api/tools/agent-bridge/` は LOCAL_ONLY + SPAWN_CAPABLE であり、認証前にループバック接続が強制されます

機密性の高いホストのバイパスリスト

バイパスリストにより、金融機関、OAuth/SSO プロバイダー、およびその他の機密性の高いホストは決して復号されません。これらの TLS トラフィックは透過的な TCP トンネルとして通過するため、OmniRoute が平文を参照することはありません。

デフォルトのバイパスパターンには、以下が含まれます。

*.bank.*, *.gov.*（金融機関／政府機関）
*.okta.com, *.auth0.com, *.microsoft.com（SSO／ID 管理）
*.apple.com, *.icloud.com（Apple システムサービス）

ユーザーが追加したバイパスパターンは agent_bridge_bypass テーブルに保存され、他のすべての設定より優先されます。

シークレットのマスキング

src/mitm/maskSecrets.ts の maskSecrets() は、以下に適用されます。

TrafficBuffer.push() の前に、すべてのリクエストボディに適用
ロギングまたはブロードキャストの前に、すべてのヘッダーに適用

対象パターン：sk-/ak-/pk- プレフィックス付きトークン、Bearer トークン、および 40 文字以上の汎用トークン。

アップストリーム CA 証明書

AGENTBRIDGE_UPSTREAM_CA_CERT が設定されている場合、起動時にそのファイルが読み込まれます。パスが存在していてもファイルを読み取れない場合、AgentBridge は明確なエラーをログに記録して起動を拒否します（企業環境におけるサイレントな TLS 障害を防止します）。

既知の制限事項

ポート 443 には権限が必要：Linux では、AgentBridge を使用するために Node バイナリへ setcap 'cap_net_bind_service=+ep' を設定するか、authbind 経由で実行する必要があります。セットアップウィザードには、OS 固有の手順が表示されます。
IDE の再起動が必要：DNS リダイレクト後、新しいホスト名解決を反映するには IDE を再起動する必要があります。
ハードコードされた OAuth トークン：一部のエージェント（Kiro、Antigravity）は、OAuth リフレッシュトークンをローカルに保存します。これらは AgentBridge に対して透過的です。AgentBridge は各リクエスト内の Bearer トークンを認識しますが、ログ記録前にマスキングします。
Electron フロントエンドでは NODE_EXTRA_CA_CERTS が必要：バンドルされた Node/Electron ランタイム上でフロントエンドを実行する IDE は、OS/NSS の信頼ストアを無視するため、NODE_EXTRA_CA_CERTS を設定したシェルから起動する必要があります（§3.2 を参照）。未設定の場合の症状：IDE バックエンドでは認証され（MITM には 200 が表示される）、UI はログアウト状態のままになります。
同じ IDE の複数のインストールはそれぞれ独立：システムインストール（例：/usr/share/antigravity/antigravity）とユーザーローカルの「Full」インストール（例：~/AntigravityIDE_Full/antigravity-ide）は、それぞれ独自のランタイムを持つ別プロセスです。各プロセスを CA が注入された状態で再起動する必要があります。再起動前に、バイナリパスからどちらが実行中かを特定してください。
ID はルーティング先モデルではなく、エージェントのシステムプロンプトによって設定される：エージェントのモデルを別のプロバイダーに再マッピングしても、IDE がその内容をシステムプロンプトへ注入するため、応答では引き続きエージェント本来の ID が名乗られます（例：Antigravity は「I am powered by Gemini」と回答します）。実際のバックエンドは、モデル自身に何者かを尋ねるのではなく、call_logs / proxy_logs（provider、model、target_format）で確認してください。

§6 トラブルシューティング

ポート443の競合

別のプロセス（Webサーバー、VPNなど）がすでにポート443をリッスンしている場合：

lsof -i :443          # プロセスを確認
sudo fuser -k 443/tcp  # 強制終了（取り扱いに注意）

または、AgentBridgeの設定で非特権ポートを構成し、iptables / pfのリダイレクトルールを設定します。

証明書が信頼されていない

AgentBridgeの起動後にIDEでTLSエラーが表示される場合：

証明書がインストールされていることを確認します：security find-certificate -c "OmniRoute AgentBridge"（macOS）またはcertutil -L -d sql:$HOME/.pki/nssdb（Linux/NSS）
一部のアプリは独自の信頼ストアを使用します（Firefox、Linux上のChrome）。「Trust Cert」を再度実行し、NSS/Firefox固有の証明書ストアを確認してください。
信頼設定後にIDEを再起動してください。進行中のTLSセッションでは、以前の信頼状態が使用されます。

CAが信頼されているにもかかわらずIDEがログアウト状態になる／「connection error」が表示される

症状：DNSをリダイレクトしてCAを信頼した後、ElectronベースのIDE（例：Antigravity）が ログアウト状態で起動するか、認証エラーまたは接続エラーを表示します。一方で、MITMログではブートストラップ呼び出し（loadCodeAssist、fetchAvailableModels、…）が200を返しています。

原因：IDEに同梱されているNode/ElectronランタイムがOSの信頼ストアを無視するためです。ネイティブバックエンド（Go言語サーバー）はOSのCAを信頼して認証しますが、Electronフロントエンドは信頼しません。そのため、UIはオフラインであると判断します。

修正方法（両方の手順が必要）：NODE_EXTRA_CA_CERTS=<ca.crt>をエクスポートし、デスクトップアイコンからではなく、 そのシェルからIDEを再起動します。最初にIDEを完全に終了してください。Electronのシングルトンロックにより、 2回目の起動では既存のプロセスにフォーカスするだけで、新しい環境は無視されます。§3.2を参照してください。これは、スタンドアロンエージェントはMITM経由で動作する一方、IDE版は同じ設定で失敗するという、公開されているアップストリームの報告と一致します。

DNSが反映されない

/etc/hostsが更新されたことを確認します：

grep "omniroute\|127.0.0.1.*github\|127.0.0.1.*cursor" /etc/hosts

DNSキャッシュをフラッシュします：

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux（systemd-resolved）
sudo systemctl restart systemd-resolved
# Windows
ipconfig /flushdns

IDEが検出されない

自動検出では一般的なインストールパスを使用します。IDEがインストールされているにもかかわらず検出に失敗する場合：

IDEのバイナリが標準以外の場所にあるか確認してください
セットアップウィザードは引き続き動作します。検出の失敗は、バッジにインストールパスが表示されないことを意味するだけです

ハンドラーエラー（アップストリームのフェッチに失敗）

AgentBridgeがインターセプトしているものの、すべてのリクエストが失敗する場合：

/dashboard/providersで少なくとも1つのプロバイダーが接続されていることを確認します
OmniRouteサーバーのログを確認します：.envでAPP_LOG_LEVEL=debugを設定
OMNIROUTE_BASE_URLが正しいルーターエンドポイントを指していることを確認します（デフォルト：http://127.0.0.1:20128）

§7 APIリファレンス

すべてのルートはLOCAL_ONLY（ループバックのみ。認証前に適用）かつSPAWN_CAPABLEです。src/server/authz/routeGuard.tsを参照してください。

ベースパス：/api/tools/agent-bridge/

メソッド	パス	説明
GET	`/api/tools/agent-bridge/state`	サーバー全体の状態 + エージェントごとの検出結果／ステータス
GET	`/api/tools/agent-bridge/agents`	登録済みエージェントの一覧（id、名前、ホスト、利用可否、状態）
GET	`/api/tools/agent-bridge/agents/{id}`	単一エージェントの状態（ターゲット設定 + 検出結果 + 保存済み状態）
PATCH	`/api/tools/agent-bridge/agents/{id}`	エージェントの `setup_completed` を更新
GET	`/api/tools/agent-bridge/agents/{id}/detect`	エージェントの検出プローブを実行（`installed`、`version?`、`path?`）
POST	`/api/tools/agent-bridge/agents/{id}/dns`	エージェントの DNS を有効化／無効化（`{enabled: boolean}`）
GET	`/api/tools/agent-bridge/agents/{id}/mappings`	エージェントのモデルマッピング
PUT	`/api/tools/agent-bridge/agents/{id}/mappings`	モデルマッピングを置換
POST	`/api/tools/agent-bridge/server`	サーバーを起動／停止／再起動（`action: "start"\|"stop"\|"restart"\|"trust-cert"\|"regenerate-cert"`）
GET	`/api/tools/agent-bridge/cert`	証明書のステータス（`exists`、`trusted`、`path`）
POST	`/api/tools/agent-bridge/cert`	MITM ルート CA を信頼（インストール）
DELETE	`/api/tools/agent-bridge/cert`	MITM ルート CA の信頼を解除（削除）— 冪等（§3.6 を参照）
POST	`/api/tools/agent-bridge/cert/regenerate`	自己署名 MITM 証明書を再生成
GET	`/api/tools/agent-bridge/cert/download`	ダウンロード用の PEM 証明書をストリーミング配信
GET	`/api/tools/agent-bridge/bypass`	バイパスパターンの一覧（`default` + `user`）
POST	`/api/tools/agent-bridge/bypass`	ユーザー定義のバイパスパターンを一括置換
DELETE	`/api/tools/agent-bridge/bypass?pattern=...`	ユーザー定義のバイパスパターンを 1 件削除
GET	`/api/tools/agent-bridge/diagnose`	キャプチャパイプラインのセルフテスト（§3.6 を参照）
POST	`/api/tools/agent-bridge/repair`	孤立した MITM システム状態を元に戻す（§3.6 を参照）
GET	`/api/tools/agent-bridge/config`	移植可能な設定 JSON をエクスポート（§3.7 を参照）
POST	`/api/tools/agent-bridge/config`	移植可能な設定 JSON をインポート（§3.7 を参照）
GET	`/api/tools/agent-bridge/upstream-ca`	設定済みのアップストリーム CA パスを取得
POST	`/api/tools/agent-bridge/upstream-ca`	アップストリーム CA パスを検証して永続化
POST	`/api/tools/agent-bridge/upstream-ca/test`	アップストリーム CA パスを検証のみ（ドライラン）— 永続化しない
GET / POST / DELETE	`/api/tools/agent-bridge/tproxy`	TPROXY 透過復号キャプチャモード — `docs/security/MITM-TPROXY-DECRYPT.md` を参照（git 内。`/docs` には組み込まれない）

完全な OpenAPI スキーマ：docs/openapi.yaml → タグ AgentBridge。

§8 ロードマップ

Trae の調査

Trae は比較的新しい AI コーディングアシスタントです。ハンドラーを実装する前に、以下を行います。

VS Code / JetBrains のマーケットプレイス、またはスタンドアロンアプリとしてバイナリ／拡張機能を特定する
mitmproxy でトラフィックをキャプチャし、API ホストとエンドポイントの形式を確認する
認証メカニズムを特定する
利用規約と API の検出可能性に基づいて、実施可否を評価する

調査が完了するまで、ダッシュボードの Trae カードには「調査中」バッジと「実現可能性を報告」リンクが表示されます。src/mitm/handlers/trae.ts のハンドラースタブは、構造化された Not yet implemented エラーをスローします。

バックログ対象エージェント（MITM 必須 — カスタムベース URL は未サポート）

以下のツールは現行バージョンでカスタムベース URL をサポートしていないため、MITM が唯一の傍受手段となります。実現可能性の評価は保留中です。

Windsurf（Codeium/Cognition）
Amp（Sourcegraph）
Amazon Q / Kiro CLI（AWS Bedrock — Kiro IDE とは別）
Cowork（Anthropic デスクトップ）

注: GitHub Copilot CLI ≥v1.0.19 は COPILOT_PROVIDER_BASE_URL をサポートしています。このツールでは MITM ではなく直接設定を使用してください。

OmniRoute ソースコード (a58000c7685f)

HagiCode

HagiCode は構造化ワークフロー、マルチエージェント実行、Hero Dungeon ビューを備えたエージェント型コーディングワークスペースです。

よりスマートで速く、楽しいエージェント型ワークフローで、使いやすいソフトウェアを形にします。

Smart構造化ワークフローは意図をアイデアから変更のリリースまで実行可能な道筋にします。
Efficientマルチエージェントのワークフローで調査、実装、レビューを並行して進めます。
FunHero Dungeon により長時間のコーディングを視覚的で協力的な体験にします。

HagiCode を見る