Agent Harness 比較2026 — Copilot・Codex・Claude Code・Cursor・OSS を12の軸で比べる

はじめに

Agent Harness を導入するときに比べるべきなのは、搭載モデルやファイル編集の可否より、作業を安全に実行し、観測し、失敗から戻せる設計になっているかである。

具体的には、次の問いに答えられるかを比べる。

• どこで実行され、どの状態を持ち、どこまで隔離されるのか
• ツール呼び出しは誰が制御し、どの時点で止められるのか
• コンテキストはどう集められ、どう圧縮され、どう忘れられるのか
• 長時間タスクや並列タスクを、破綻せず追跡できるのか
• 失敗したとき、何を再現し、何を監査し、どこから戻せるのか

本稿では、代表的な商用/OSS プロダクトに点数や順位を付けず、各製品がどの設計責務を引き受け、どの責務を利用者側に残しているかを、次の12軸で比較する。

1. 実行場所（local / cloud / hybrid）
2. オーケストレーションの公開度
3. ツール拡張
4. 権限制御
5. コンテキスト戦略
6. 長時間タスク
7. マルチエージェント
8. Git/PR 統合
9. 観測性
10. 企業統制
11. OSS 透明性
12. 評価容易性

対象は、GitHub Copilot（cloud agent / IDE Agent Mode / CLI sandboxes）、OpenAI Codex、Anthropic Claude Code、Cursor、Cline、Aider、OpenHands、SWE-agent / mini-SWE-agent、そして歴史的参照として Continue である。Continue は2.0.0 final release 後に公開リポジトリーが read-only 化されているため、現行選定の主対象ではなく、OSS エージェントの系譜として扱う。

本稿は2026-09-10時点の公開情報に基づく比較である。価格、プラン、制限値、対応モデル、ベータ機能は変化が速いので、導入時は必ず一次情報で再確認してほしい。

先に結論

2026年時点の Agent Harness は、ローカルかクラウドかの二分より、次の3つの設計重心に分けると整理しやすい。

この3分類は製品ではなく使い方の重心を分けたもので、同じ製品でも CLI、IDE、クラウド、SDK のどれを使うかで性質が変わる。たとえば GitHub Copilot cloud agent と IDE Agent Mode は、同じ Copilot ブランドでも、実行責任・監査の粒度・待ち時間・人間の関与点が大きく異なる。

Agent Harness とは何か

本稿でいう Agent Harness は、LLM そのものではなく、LLM に開発作業を任せるための実行基盤を指す。主な構成要素と処理の流れは次の通りだ。

製品ごとの違いは、この図のどの段階を製品側で作り込み、どの段階をユーザーや組織に委ねているかに表れる。

全体マップ

「強い軸」は、各軸の節の比較をもとに、他製品より仕組みが充実していると本稿で判断した軸や特徴で、「注意点」は導入時に制約や負担になりやすい点である。数字は冒頭に挙げた12軸の番号を指す。

この12軸の読み方

読者の運用形態ごとに、先に読むとよい軸を次の表に示す。全軸を順に読む必要はない。

各軸の節では、製品ごとの扱いを説明したあと、確認すべき項目、失敗モード、調査から見えた設計差を挙げる。

軸1: 実行場所

実行場所を比べるときは、ローカルかクラウドかだけでなく、少なくとも次の5層をそれぞれ確かめる必要がある。

1. モデル推論がどこで走るか
2. ツール実行がどこで走るか
3. ファイルシステム変更がどこに発生するか
4. ネットワークアクセスがどの境界から出るか
5. セッション状態がどこに保存されるか

GitHub Copilot cloud agent は、GitHub 上のエージェントセッションから GitHub Actions ベースの一時環境でリポジトリーを操作する。実行環境、認証、監査記録、成果物が同じプラットフォームにまとまり、作業はブランチ上のコミット、ログ、PR として残る。一方で、対象が GitHub 上のリポジトリーに限られること、1タスク1ブランチ/PR であること、セッション時間に上限があることが設計上の制約になる。

Codex、Claude Code、Cline、Aider などのローカル型は、ユーザーの作業ディレクトリーを直接読んで編集し、ローカルの CLI や認証済みのセッションをそのまま使い、ローカルのテストやビルドをすぐに実行できる。反復は速いが、秘密情報、未コミット変更、ローカルサービス、認証済み CLI にエージェントがどこまで触れられるか、外部への副作用をどこまで許すかを設計しなければならない。

Copilot CLI sandboxes（public preview）や Codex permission profiles（beta）のように、対話型・ローカル寄りの実行にもサンドボックスを挟み、ローカルの反復速度を保ちながらクラウドに近い隔離を得る設計が増えている。Copilot local sandbox は OS ごとのサンドボックス機構を使い、cloud sandbox では GitHub ホストの一時 Linux 環境を使う。Codex の permission profiles は、filesystem と network へのアクセスを profile として記述し、:read-only、:workspace、:danger-full-access のような設定を切り替える。対象はローカルのサンドボックス内で実行するコマンドで、MCP server、cloud 設定、承認済みの escalation などは別の仕組みで制御する。

見るべき具体項目:

• ファイル編集はローカル作業ツリーか、隔離された worktree か、クラウド checkout か
• ネットワークはデフォルト deny か、ドメイン allowlist か、完全許可か
• セッション停止後に状態が残るか、snapshot されるか、完全破棄か
• 途中成果はブランチ/コミット/PR として残るか、会話ログだけか
• ローカルの .env、SSH 鍵、Docker socket、クラウド CLI 認証へ到達しうるか

失敗モード:

• ローカル型で ~/.ssh や .env を読める状態のまま作業させる
• クラウド型でローカル再現に必要なサービスや秘密情報がなく、テストが通らない
• サンドボックス上では通るが本番 CI では落ちる
• 複数エージェントが同じ作業ツリーを同時編集して競合する

調査から見えた設計差:

• sandbox 型はクラウド型とローカル型の中間にあり、実行場所そのものより、filesystem と network の境界、状態の snapshot と破棄をどう表現するかで差が出る。
• Cursor Cloud Agents や OpenHands Cloud は、クラウド実行を、GitHub 連携、チーム管理、使用量管理、権限管理と組み合わせたサービスとして提供する方向に進んでいる。

軸2: オーケストレーションの公開度

オーケストレーションは、モデルが次に何をするかを決める制御ループである。その中身を利用者がどこまで触れるかで、大きく4段階に分けられる。

公開度が高いほど柔軟になる一方、利用者が負う責任も増える。たとえば Claude Agent SDK を使うと、Claude Code のツール実行、hooks、subagents、MCP、sessions をアプリから扱える。ただし、それを組み込んだプロダクトを公開するなら、認可、テナント分離、ログ保全、ユーザー同意、失敗時の復旧を自分で設計することになる。

GitHub Copilot cloud agent は、オーケストレーションの細部を隠し、作業を Issue/PR/Actions の運用に載せる。制御ループを細かく変えられるようにするより、組織が受け入れやすい成果物の形式を優先している。

Codex と Claude Code はその中間にあり、hooks や subagents を細かく設定できる。Codex hooks は SessionStart、PreToolUse、PermissionRequest、PostToolUse、PreCompact、SubagentStart、Stop などのイベントを持つ。ただし現行の Codex hooks は command handler が中心で、PreToolUse / PostToolUse の対象も Bash、apply_patch、MCP tool call などの対応経路に限られる。それでも hook の入力には transcript_path、permission_mode、tool の入出力が渡るので、自動化には使える。Claude Code hooks はイベントの種類がさらに多く、InstructionsLoaded、ConfigChange、FileChanged、TaskCreated、TaskCompleted、WorktreeCreate など、ツール呼び出しの外側にある設定変更やタスク完了まで扱える。

見るべき具体項目:

• ツール実行前に制御できるか（PreToolUse）
• 権限プロンプト直前に制御できるか（PermissionRequest）
• ツール実行後に結果を検査できるか（PostToolUse）
• 停止直前に「まだ終わっていない」と差し戻せるか（Stop）
• compaction 前後に介入できるか
• subagent 起動/終了を観測できるか

hook event の名前は製品ごとに異なる。Codex/Claude Code は PreToolUse や PermissionRequest のような PascalCase 名を使う。GitHub Copilot hooks はリポジトリー配下の .github/hooks/*.json と個人用の hooks で定義し、sessionStart、preToolUse、postToolUse、agentStop などの lower camel case 名を使う。公開ドキュメント上は PermissionRequest という同名 hook type を持たない。そのため、hook の仕組みは名前ではなく、実行前の制御、実行後の観測、停止前の差し戻しができるかで比べる。

設計上の勘所:

• UI 主導の製品は導入が簡単だが、自社固有の統制を差し込みにくい
• SDK 主導の製品は統合しやすいが、マルチテナント/監査/権限の実装責任を負う
• hook の shell script や HTTP endpoint 自体が攻撃面になる

調査から見えた設計差:

• 内部ループを隠す UI 主導型でも、Copilot cloud agent のように PR、ログ、Actions、レビューコメントに成果を残せれば、組織は十分に制御できる。

軸3: ツール拡張

ツール拡張の接続方式は MCP に収斂しつつある。ただし、「MCP 対応」というだけでは製品の差は分からない。差は次の6つの層に出る。

1. transport: stdio / HTTP / SSE / remote executor
2. 認証: bearer token / OAuth / local env / managed secret
3. tool allowlist: サーバー単位か、tool 単位か
4. approval: MCP tool ごとに自動承認/都度承認/拒否を設定できるか
5. instruction: MCP server instructions をモデルにどう渡すか
6. 配布: 個人設定、リポジトリー設定、チーム/組織配布、marketplace

Codex MCP は stdio と streamable HTTP をサポートし、bearer token や OAuth、tool allowlist/denylist、tool 単位の approval mode を設定できる。Claude Code は MCP tools を通常の tool event として hooks で扱え、mcp__server__tool 形式で matcher を書ける。Cursor は plugins、skills、MCPs、subagents、rules、commands、hooks を Customize 画面にまとめ、Marketplace/Team Marketplace と組み合わせる。GitHub Copilot は MCP を Copilot Chat、CLI、Copilot app、cloud agent/code review など複数サーフェスへ広げつつ、組織ポリシーと紐づける。

OSS では、Cline が plugin/MCP/SDK の自由度を前面に出している。Aider は MCP より、LLM provider との接続、repo map、git 統合を軽量に組み合わせることを重視する。OpenHands は SDK と Cloud/Enterprise を通じて、ツールの追加をアプリケーション基盤の側で扱う。利用者がエージェントプラットフォームを自前で運用する形に近い。

失敗モード:

• MCP server を増やしすぎて tool descriptions がコンテキストを圧迫する
• 似た名前のツールが増え、モデルの tool selection が不安定になる
• OAuth token や環境変数が、ローカル/クラウド/サブエージェント間で伝播しない
• plugin に同梱された hook や MCP server を、中身をレビューせずに有効化する

導入時に確認すること:

• この MCP は読み取り専用で十分か
• 書き込みツールは別サーバー/別 toolset へ分離できるか
• tool ごとに承認モードを変えられるか
• サーバーの instructions は短く、最初の数百文字で自己完結しているか
• チームに配布したあと、誰が更新し、誰が無効化できるか

調査から見えた設計差:

• Codex のように server ごとの enabled_tools、disabled_tools、tool 単位の approval mode を設定として持つ製品では設定の管理が、UI や Marketplace を中心に配布する製品では配布と更新の管理が、運用の中心になる。
• Claude Code は MCP tool を通常の tool event として扱い、mcp__server__tool のような名前で hooks や permission rule の対象にできる。MCP tool も組み込みツールと同じ仕組みで統制できる。
• Cursor のように拡張の発見・配布・チーム共有を UI にまとめると、拡張の管理はサプライチェーン管理に近づく。

軸4: 権限制御

権限制御は、Agent Harness の品質の差が最もはっきり表れる軸である。承認ダイアログの有無より、権限がどの層で効いているかを比べる。権限は次の層を重ねて構成され、層ごとに防げる失敗が異なる。

Codex の permission profiles は、filesystem と network の境界をプロファイルとして定義する。read、write、deny のアクセス指定、workspace roots、network domain の allow/deny、localhost/private network の扱いまで設定できる。Claude Code は permission modes、deny/allow rules、hooks、managed settings、subagent ごとの tools/permissionMode を重ねる。GitHub Copilot cloud agent は GitHub 側のポリシー、Actions 環境、hooks、MCP 設定、監査ログと連動する。

Cline のエディター体験は「every action requires explicit approval」を基本にし、Plan/Act とチェックポイントで人間が差分を確認しやすくしている。一方、CLI/headless や Kanban では auto-approve や実験的な権限バイパスを使う運用もあるため、サーフェス別に既定値を確認する。Aider は git を安全弁にし、編集ごとのコミット、/undo、dirty file の事前コミットで、変更を戻せるようにしている。

よくある誤解:

• hooks は sandbox ではない。hook が止める前に別経路で同じ副作用が起きる場合がある。
• PostToolUse は事後検査であり、副作用を取り消せない。
• instruction は強制ではない。禁止したい操作は permission/sandbox/hook で止める。
• danger-full-access や bypass permissions は、短期実験では便利でも組織標準にしてはいけない。

設計の実務パターン:

1. 既定は read-only または workspace-write no-network
2. ネットワークはドメイン allowlist から始める
3. .env、keys、cloud credentials、package manager hooks は deny
4. 対応製品では destructive command を PreToolUse 相当でブロック
5. deployment、migration、production DB は PermissionRequest 相当または承認 UI で人間承認
6. Stop hook で「テスト未実行のまま完了」を止める

調査から見えた設計差:

• Codex permission profiles では、ローカルコマンド実行の filesystem/network 境界が明示的な設定データになる。deny は write や read より優先され、設定は workspace roots からの相対パスで適用される。
• Claude Code では、静的な allowlist（permission rules や subagent ごとの tools）と、hooks による動的な検査を分けて設計できる。

軸5: コンテキスト戦略

コンテキスト戦略は、モデルの回答の質に加えて、コスト、速度、セキュリティー、再現性にも直接影響する。

主な方式は次の5つ。

1. リポジトリー全体の構造要約
2. 検索/grep/semantic search による局所取得
3. 明示的な rules/instructions
4. 長期 memory
5. compaction / summarization

比較のために、コンテキスト戦略を次のデータ構造の組み合わせとして表す。各製品の内部実装そのものではなく、本稿で正規化したモデルである。

type ContextLayer =
    | InstructionLayer
    | RepoMapLayer
    | RetrievalLayer
    | MemoryLayer
    | TranscriptLayer
    | CompactionLayer
    | SubagentLayer
    | ToolMetadataLayer;
 
type ContextItem = {
    id: string;
    source: "repo" | "memory" | "rule" | "tool" | "transcript" | "mcp";
    scope: "user" | "project" | "local" | "managed" | "session" | "subagent";
    content: string;
    tokenEstimate: number;
    freshness: "startup" | "lazy" | "live" | "compacted" | "stale-risk";
    authority: "hint" | "instruction" | "policy" | "evidence";
};

ContextItem では、content に加えて source、scope、freshness、authority が比較の要点になる。たとえば CLAUDE.md や AGENTS.md は authority: "instruction" だが、操作を強制する力はない。deny rule や sandbox policy は context ではなく enforcement なので、別のレイヤーに置くべきである。tool output は authority: "evidence" だが、古い transcript 由来なら freshness: "stale-risk" になる。

リポジトリーマップ

Aider の repo map は、ファイル全文の代わりにシンボルのグラフとしてコンテキストを圧縮する代表例で、概念的には次の構造になる。

type RepoMap = {
    files: FileNode[];
    edges: DependencyEdge[];
    tokenBudget: number;
};
 
type FileNode = {
    path: string;
    symbols: SymbolDef[];
    rank: number;
};
 
type SymbolDef = {
    name: string;
    kind: "class" | "function" | "method" | "type" | "constant";
    signature?: string;
    keyLines: string[];
    references: number;
};
 
type DependencyEdge = {
    from: string;
    to: string;
    kind: "imports" | "calls" | "references";
    weight: number;
};

Aider は tree-sitter で定義や参照を抽出し、ファイルを node、依存関係を edge とするグラフランキングで重要部分を選ぶ。これにより、LLM は全ファイルを読む前に、どのファイルが重要そうかを把握できる。--map-tokens のような token budget は、このグラフからどの SymbolDef.keyLines をプロンプトに入れるかを決める制約になる。設計の差は、検索精度に加えて、どの情報を捨てるかに表れる。

指示・ルール・メモリー

Claude Code の CLAUDE.md / .claude/rules/ / auto memory は、おおむね次の3種類のデータ構造に分けられる。

type InstructionFile = {
    path: string;
    scope: "managed" | "user" | "project" | "local";
    loadMode: "startup" | "lazy-by-path" | "imported";
    pathGlobs?: string[];
    content: string;
};
 
type MemoryIndex = {
    entrypoint: "MEMORY.md";
    loadedPrefixLimit: { lines: 200; bytes: 25_000 };
    topics: Array<{ path: string; summary: string; lastTouched?: string }>;
};
 
type MemoryNote = {
    topic: string;
    fact: string;
    evidence?: string;
    staleWhen?: string;
};

InstructionFile は起動時または遅延ロード時に context window に入るのに対し、MemoryNote の詳細ファイルは必要になったときに読まれる。つまり memory は、MEMORY.md をインデックスとする小さな知識ベースに近い。staleWhen のような棚卸し条件を持てないと、古い学習が残り続ける。

Transcript と trajectory

コンテキスト戦略を評価するなら、会話履歴の構造も見る必要がある。Claude Code や Codex の hooks は session_id、transcript_path、tool_name、tool_input などを渡す。mini-SWE-agent は .traj.json に info と messages を保存し、SWE-agent は thought、action、observation、state、query を持つターンとして trajectory を保存する。

これらを正規化すると、実行履歴は次の構造で表せる。

type AgentTranscript = {
    sessionId: string;
    messages: AgentMessage[];
    artifacts: ArtifactRef[];
};
 
type AgentMessage = {
    role: "system" | "user" | "assistant" | "tool" | "exit";
    content?: string;
    toolCalls?: ToolCall[];
    extra?: {
        cost?: number;
        timestamp?: number;
        returncode?: number;
        actions?: Array<{ command: string }>;
        response?: unknown;
    };
};
 
type ToolCall = {
    id: string;
    name: string;
    input: unknown;
    output?: unknown;
    approvalState?: "auto" | "prompted" | "approved" | "denied";
};
 
type ArtifactRef = {
    kind: "file" | "patch" | "log" | "pr" | "screenshot";
    uri: string;
    hash?: string;
};

履歴がこの構造で残っていれば、「どのファイルを読んでから編集したか」「どの tool result が最終判断に影響したか」「compaction 後にどの証拠が失われたか」を評価しやすい。

Compaction と subagent context

compaction は、会話履歴を、次の推論が使う状態へ変換する処理だ。Claude Code の subagent では、subagent transcript がメイン会話とは別に保存され、compaction boundary には trigger や preTokens のようなメタデータが記録される。

type CompactionRecord = {
    trigger: "manual" | "auto";
    preTokens?: number;
    summary: string;
    preservedFacts: string[];
    droppedArtifacts: ArtifactRef[];
};
 
type SubagentContext = {
    agentId: string;
    agentType: string;
    parentSessionId: string;
    startupContext: {
        systemPrompt: string;
        taskMessage: string;
        inheritedInstructions: boolean;
        inheritedGitStatus: boolean;
        preloadedSkills: string[];
    };
    transcriptPath?: string;
};

製品間で比べるべきなのは、subagent が fresh context で始まるのか、fork のように親会話を引き継ぐのか、探索結果を要約だけ返すのか、transcript 全体を resume できるのか、である。コンテキスト汚染を避けるには fresh context が有利だが、説明コストは増える。fork は逆に説明コストを下げるが、親会話のノイズも継承する。

MCP tool metadata

MCP は、外部ツールを呼び出せるようにすると同時に、tool metadata を context としてモデルに渡す。比較するときは、少なくとも次の構造を見る。

type McpServerContext = {
    name: string;
    transport: "stdio" | "http" | "sse";
    instructions?: string;
    tools: Array<{
        name: string;
        description: string;
        inputSchema: unknown;
        approvalMode?: "auto" | "prompt" | "approve";
        enabled: boolean;
    }>;
};

instructions と tools[].description は、モデルの tool selection に直接効く。長すぎる説明、似た名前の tool、未使用 tool の大量登録は、コンテキスト消費と誤選択を増やす。MCP を導入するときは、tool が動くかに加えて、tool metadata が context window をどれだけ消費し、誤選択をどれだけ招くかも調べるべきだ。

製品ごとの構成と確認点

Claude Code は CLAUDE.md、.claude/rules/、auto memory、subagent memory、compaction を組み合わせる。auto memory の内容を棚卸しできなければ、古い学習がチーム標準と衝突しうる。

Codex は AGENTS.md や rules、hooks、session transcript、subagent context を持つ。GitHub Copilot cloud agent では、repository instructions、Copilot Memory（対応プラン/preview 条件で有効な場合）、MCP 経由の Issues/PR/履歴などがコンテキスト源になる。Cursor は rules、skills、subagents、MCP、plugins を Customize 画面に集約している。

見るべき具体項目:

• 起動時に必ず入る context は何か
• ファイルアクセスで遅延ロードされる rules はあるか
• memory は誰が書き、誰が消せるか
• compaction 後に何が残り、何が落ちるか
• subagent が親会話の context を持つか、fresh context で始まるか
• large repo で重要ファイルの発見精度をどう上げるか

失敗モード:

• CLAUDE.md が長すぎて、重要ルールの遵守率が下がる
• memory に古い build command が残り、毎回失敗する
• path-specific rules が読み込まれていないのに、読み込まれた前提で作業する
• subagent に必要な文脈を渡さず、探索をやり直す
• compaction で根拠や未完了 TODO が落ちる

調査から見えた設計差:

• コンテキスト戦略の差は、何を入れるかより、何を入れないかの設計に出る。Aider は repo map で symbol-level の要約を作り、Claude Code は instructions/memory/subagent で文脈を分離し、SWE-agent 系は trajectory で後から再現できる履歴を残す。
• rules や memory は、scope と loadMode を持つデータ構造として見ると比較しやすい。起動時に入る情報、ファイルアクセス時に遅延ロードされる情報、compaction 後に再注入される情報は、それぞれ扱いが異なる。
• transcript や trajectory は、モデルへの入力であると同時に、後から失敗を分析するためのデータセットでもある。mini-SWE-agent の .traj.json のように config、messages、cost、submission を一緒に保存する形式は、評価容易性にも直結する。

軸6: 長時間タスク

長時間タスクで差が出るのは、モデルが長く考えられるかより、作業を分割し、待ち、再開し、観測できるかである。

GitHub Copilot cloud agent はバックグラウンドで作業し、ブランチや PR に成果を残す。GitHub 上で開始・追跡・コメントによる反復ができる一方、セッション時間制限や1リポジトリー/1ブランチ/1PR の制約を意識する必要がある。

Claude Code は CLI/desktop/web/IDE など複数サーフェスにまたがり、background agents、scheduled tasks、subagents、hooks、Agent SDK/Managed Agents など、長時間の作業に使える仕組みが多い。Stop hooks や TaskCompleted hooks で、タスクを完了としてよい条件も定義できる。

Codex は subagents や non-interactive execution、hooks、cloud 連携で長時間作業を支える。Cline は、dev server や test watcher のように動き続けるプロセスの出力を監視し、それに反応する使い方に向く。OpenHands Cloud/Enterprise は、エージェントをサービスとして運用し、長時間・多人数・多タスクへ広げる方向に進んでいる。Aider は terminal での対話的なペアプログラミングが中心で、git に記録しながら短く反復する作業に最適化されている。長時間の非同期運用が手薄なのは、この設計上の選択による。

長時間タスクで見るべきこと:

• idle 時に自動終了するのか、resume できるのか
• dev server や watcher の出力を継続監視できるか
• API rate limit や tool failure 時にどうリトライするか
• 途中状態は transcript/branch/task board に残るか
• user steering が途中で効くか

失敗モード:

• 1ターンで巨大タスクを抱え、context rot が起きる
• 長時間テストを同期 hook で実行し、エージェント全体を止める
• バックグラウンドタスク完了後の結果がモデルに戻らない
• クラウド環境の時間制限で中途半端なブランチが残る

調査から見えた設計差:

• 長時間タスクでは、長く動けるかより、途中状態をどこに退避するかで設計が分かれる。GitHub Copilot cloud agent はブランチ/PR/ログに、Claude Code や Codex は transcript/session/subagent に、OpenHands は Cloud/Enterprise のセッション管理に退避する。
• watcher 型の長時間実行と cloud PR 型の長時間実行は性質が違う。前者は stdout/stderr や dev server の継続監視が中心で、後者は branch や PR への状態保存が中心になる。
• hooks で長時間処理を同期実行すると、エージェントの推論ループ自体が止まる。Claude Code の async hook のように、完了後に結果を追加の context として戻す設計なら、長時間の検証と対話の継続を分けられる。

軸7: マルチエージェント

マルチエージェントに価値が出るのは、タスク分解の境界が明確で、各エージェントの権限と成果物が分離され、最後に統合できる場合だけだ。

Claude Code の subagents は、context isolation を重視している。Explore や Plan のような組み込み subagent は読み取り中心で、探索の出力でメイン会話を埋めない。custom subagent では tools、disallowedTools、model、permissionMode、mcpServers、hooks、memory、background、isolation: worktree などを指定できる。subagent 定義はこうした項目を持つ小さな実行プロファイルなので、subagent を分けるとプロンプトだけでなく権限と文脈も分割される。fork は親会話を引き継ぐため、説明コストは低いが、context isolation の利点は弱まる。

Codex subagents は、明示的に依頼したときに spawn し、sandbox policy を継承し、並列調査や CSV batch のような実験的ワークフローにも向く。Cline は SDK の subagents や Kanban（Research Preview）で、カード単位・worktree 単位の並列作業を志向する。Copilot CLI の複数 cloud sandbox session、GitHub cloud agent の複数セッション、Cursor Cloud Agents も、並列作業の入口になる。

良い分解例:

• security reviewer / docs researcher / code mapper の並列レビュー
• frontend reproduction / backend trace / test fixer の分担
• 100ファイルの同型監査を1ファイル 1worker で実行

悪い分解例:

• 複数エージェントが同じファイルを編集する
• 仕様が固まっていないのに実装を並列化する
• 誰が最終判断するか決めずにレビューだけ増やす

設計時に決めること:

• coordinator は誰か
• worker は読み取り専用か、編集可能か
• worker ごとのコンテキストは fresh か fork か
• 成果物は diff か、report か、PR か
• 統合時の衝突を誰が解くか

調査から見えた設計差:

• 製品の差は、並列数より context isolation の設計に出る。Claude Code の named subagent は fresh context で始まり、fork は親会話を継承する。Codex subagents は親の sandbox policy や runtime override を引き継ぐ。何を継承させるかが設計の中心になる。
• Cline Kanban や Cursor Cloud Agents のようなタスクボード型は、並列作業を UI 上の作業単位に写像する。研究系の SWE-agent/mini-SWE-agent は、batch 実行と trajectory で並列実験を再現できるようにする。
• fan-out はコスト、latency、統合作業を増やすので、元が取れるのは主に「探索」「レビュー」「同型監査」の並列化である。

軸8: Git/PR 統合

Agent Harness を実務で使えるかは、作業結果がレビューできる差分として残るかで決まる。

git 統合が最も分かりやすいのは Aider で、編集ごとに自動コミットし、dirty file を事前に分離し、/diff、/undo、/commit で差分を扱える。Cline は IDE 上で diff review、checkpoint、revert を重視する。Claude Code は git 操作、commit、PR 作成、worktree isolation、hooks と組み合わせる。GitHub Copilot cloud agent は branch 作成、commit、PR 作成、レビューコメントによる反復までを GitHub 上で行う。

見るべき具体項目（PR を作れるかに加えて）:

• dirty worktree をどう扱うか
• エージェントの変更と人間の変更を分離できるか
• commit author/committer attribution は明確か
• branch protection や required checks と衝突しないか
• PR 本文、テスト結果、根拠リンクを自動で残せるか
• 途中で人間が引き継げるか

GitHub Copilot cloud agent の強みは、作業が最初から GitHub の協業の流れに載ることだ。一方で、GitHub 以外の VCS や、複数リポジトリー横断変更には向きにくい。Cursor GitHub integration は GitHub App 経由で、repository access、PR、issues、checks/actions、branch protection などに関わる権限を使う。Enterprise では GitHub Enterprise Server、IP allowlist、PrivateLink/Cloudflare Tunnel のような接続方式も論点になる。

失敗モード:

• エージェントが人間の未コミット変更を上書きする
• PR は作るが、なぜその変更をしたかの根拠が残らない
• branch protection のためにエージェント PR が merge できない
• 生成コミットが大きすぎてレビュー不能になる
• rollback 手順が git 履歴に依存しすぎ、DB や外部状態を戻せない

調査から見えた設計差:

• Git/PR 統合の差は、差分を作れるかより、変更の由来をどこまで説明できるかに出る。PR 本文、commit 分割、テスト結果、関連 Issue、エージェントの作業ログがつながっているほどレビューしやすい。
• Claude Code の worktree isolation や subagent worktree は、同じリポジトリー内で複数案を並べるときの衝突回避に効く。
• 外部状態を伴う変更、たとえば DB migration やクラウドリソース変更は、Git の rollback だけでは戻らない。Git/PR 統合が強い製品でも、外部副作用の記録と復旧手順は別途必要になる。

軸9: 観測性

観測性の差は導入後に表れる。デモで成功しても、本番で「なぜそのコマンドを実行したのか」「誰が承認したのか」「どの MCP tool がどの引数で呼ばれたのか」を追えなければ運用できない。

観測すべきイベントは少なくとも次の通り。

• session start/end
• user prompt
• tool request / approval / denial
• tool output / failure
• file edit
• command execution
• subagent start/stop
• compaction
• memory load/write
• config change
• PR/commit/check status

Claude Code hooks は prompt_id、session_id、transcript_path、tool_name、duration_ms、subagent transcript など、かなり細かい観測点を持つ。Codex hooks も session_id、turn_id、permission_mode、transcript_path、model、tool input/output などを渡す。Cline Enterprise は OpenTelemetry、Datadog、Grafana、Splunk との連携を打ち出している。GitHub Copilot cloud agent は GitHub 上のログ、PR、Actions、usage metrics、audit log との親和性が高い。

会話ログと監査ログは区別する。会話ログはモデルの文脈復元に役立つが、監査ログには改ざん耐性、検索性、保持期間、個人情報/秘密情報のマスキング、承認者の情報が必要になる。

設計の実務パターン:

• tool call は JSONL で保存する
• approval/deny はユーザー ID、理由、時刻、対象 tool を残す
• shell stdout/stderr は大きすぎるため要約と原本への参照を分ける
• 保存するログにも secret scan をかけ、secret を除去する
• session_id と PR 番号、commit SHA を紐づける

調査から見えた設計差:

• 観測性の中核データは session_id、user_id、tool_name、tool_args_hash、approval_state、artifact_ref、commit_sha のような join key である。これらがないと、会話ログ、tool call、PR、CI 結果を横断して追跡できない。
• Cline Enterprise や OpenHands Cloud/Enterprise のような商用・Enterprise 向けの製品は、OpenTelemetry や外部監視基盤、使用量レポートと接続する傾向がある。OSS/ローカル系は、ログスキーマを利用者が設計する余地が大きい。

軸10: 企業統制

企業統制は、個人利用では見えにくいが、組織導入では最重要になる。

見るべき領域:

1. ID/SSO/RBAC
2. モデル許可/禁止
3. MCP server allowlist/denylist
4. hooks/permissions の managed config
5. ネットワーク制限
6. 監査ログ
7. コスト/予算管理
8. データ保持とリージョン
9. PR/branch protection との整合
10. 開発者端末の MDM/Intune 等との連携

GitHub Copilot cloud agent は、GitHub Enterprise/Business のポリシー、GitHub Actions、MCP repository settings、usage metrics、AI credits、GitHub App/audit log と接続しやすい。Copilot cloud/local sandbox では、local sandbox policy や cloud sandbox access policy も論点になる。

ただし、GitHub Copilot の content exclusions は cloud agent には適用されない。除外設定を cloud agent のアクセス境界として扱うと、除外したつもりのファイルを見られる/更新されるリスクが残る。

Claude Code は managed settings、managed CLAUDE.md、availableModels、MCP allow/deny、hooks、permissions など、端末側統制が厚い。Codex にも managed requirements.toml、permission profiles、managed hooks がある。Cursor は Team/Enterprise で GitHub integration、Protected Git Scopes、Private Connectivity、Marketplace/Team Marketplace、Cloud Agents/Bugbot などの組織機能を持つ。OpenHands Cloud/Enterprise は RBAC、permissions、usage reporting、budgeting enforcement、多人数対応を前面に出す。Cline Enterprise も SSO、RBAC、model/tool controls、remote configuration、observability を掲げる。

一方、Aider や mini-SWE-agent のような OSS/研究寄りツールは、軽量性や再現性と引き換えに、SSO/RBAC、ログ保全、例外申請、緊急停止、コスト制御といった企業統制を利用者側で組む必要がある。

導入時に決めること:

• 誰がエージェントを有効化できるか
• どのリポジトリーで使えるか
• どのモデルを使えるか
• どの MCP server を使えるか
• 誰が hooks を配布・更新できるか
• 予算超過時に止めるのか、モデルを落とすのか
• 監査ログを何日保持するか

失敗モード:

• 個人が勝手に MCP server を追加し、内部データが外部 tool へ流れる
• BYOK で個人 API key が散在する
• hooks がローカルにしかなく、チームで同じ制御が効かない
• 監査ログより会話ログの保持期間が短く、調査不能になる
• コスト上限がなく、subagent fan-out で急増する

調査から見えた設計差:

• 製品の差が大きく出るのは、ポリシーの配布経路である。個人設定、リポジトリー設定、チーム marketplace、managed config、MDM 配布では、更新速度と強制力が大きく異なる。

軸11: OSS 透明性

OSS 透明性は、無料で使えるかではなく、検証・改変・監査できるかで評価する。

比較する観点:

• ライセンスは何か
• core runtime が OSS か、UI だけ OSS か
• enterprise 機能は source-available か closed か
• tool execution や permission logic を読めるか
• release cadence とメンテナンス状態は健全か
• fork して社内 policy を入れられるか
• telemetry や認証の挙動を追えるか

Cline、Aider、OpenHands core、SWE-agent/mini-SWE-agent は、OSS 透明性が高い。Cline は SDK/CLI/IDE/kanban のコアを見られる。Aider は git 統合や repo map の挙動を追いやすい。OpenHands の core や agent-server は MIT だが、Enterprise ディレクトリーは別ライセンスである。SWE-agent は MIT ライセンスの研究プロジェクトで、trajectory や batch/eval の設計を追いやすい。

Continue は歴史的には重要な OSS coding agent だが、現状は final 2.0.0 release 後、read-only/non-active maintenance と明示されている。現行導入の主候補というより、設計系譜や fork 元として見るのが妥当だ。

OSS は自由度が高く、provider や model も切り替えやすい。その代わり、SSO/RBAC、監査、予算、インシデント対応、セキュリティーレビューは自分たちの責任になる。

closed 製品はコード可視性の代わりに、監査ログ export、設定 export、データ保持説明、第三者認証、インシデント時の証跡取得可否で比較する。

調査から見えた設計差:

• OSS 透明性は、コードを読めるかに加えて、tool execution、permission check、prompt assembly、memory 保存、telemetry、provider 認証の経路まで追えるかで決まる。
• OSS のコアを公開している製品でも、Enterprise 機能や Cloud 運用は別ライセンスや商用契約になることがある。

軸12: 評価容易性

評価容易性は、エージェント導入の効果を測定し、その結果に基づいて改善できるかを左右する軸だ。

評価は次の3段階に分けられる。

1. ベンチマーク評価: SWE-bench、ProgramBench、社内課題セット
2. 運用評価: lead time、intervention count、rollback rate、defect escape
3. 失敗分析: trajectory、transcript、tool call log、root-cause taxonomy

SWE-agent/mini-SWE-agent はこの軸で強い。SWE-bench や batch mode、trajectory inspector、output files、yaml config など、評価と再現のための道具が揃っている。SWE-agent の公式ドキュメントは、SWE-agent と同等の性能を持ち、はるかに単純な後継として mini-SWE-agent を推奨している。現行の研究/評価用途では第一候補にしやすい。

Aider は独自の LLM leaderboard を持ち、編集能力の比較に使える。GitHub Copilot cloud agent では評価の対象が個々の会話から PR のライフサイクル（ブランチ作成、レビュー、CI、merge、コメントによる反復）に移るので、PR outcomes、merge 率、time-to-merge など組織運用データと接続しやすい。Claude/Codex/Cline/Cursor のような開発者向けハーネスは、公式ベンチだけでは見えない実リポジトリー上の文脈取得、承認、復旧、レビュー品質を別途見なければならない。

良い評価セットの条件:

• 実際の過去 Issue から作る
• 正解がテスト/レビューで判定できる
• 小/中/大のタスクを混ぜる
• 読み取りだけ、単一ファイル修正、複数ファイル修正、調査、リファクタリングを分ける
• 成功/失敗だけでなく、介入回数と根拠品質を見る

避けるべき評価:

• 1つのデモタスクだけで決める
• モデルとハーネスを分離せず比較する
• 人間のレビュー時間を測らない
• 成功した PR だけを見る
• セキュリティー/権限失敗を評価から外す

可能な範囲で同じモデル、同じタスク、同じ権限、同じ MCP 構成に揃え、揃えられない差分を記録したうえで、失敗原因を model reasoning、context retrieval、permission block、tool failure、human handoff、external environment に分類する。失敗をこう分類すれば、成功率からは読み取れない改善箇所を特定できる。分類に必要な記録を残せるハーネスほど改善しやすい。

調査から見えた設計差:

• SWE-agent/mini-SWE-agent は、trajectory を第一級の成果物として扱う。thought、action、observation、state、query、または .traj.json の info、messages、extra といった構造が、失敗分析と再現実験の土台になる。
• Aider の編集ベンチや leaderboard は、組織運用の評価とは別物である。編集能力、レビュー可能性、監査可能性、ロールバックは分けて見る必要がある。

12軸をまとめた選定フレーム

12軸の比較を踏まえると、運用形態ごとの候補と条件は次のようになる。

GitHub 中心の組織

第一候補:

• GitHub Copilot cloud agent
• 補助として Copilot IDE Agent Mode / Codex / Claude Code / Cursor

重点軸: 1実行場所、4権限制御、8 Git/PR 統合、9観測性、10企業統制、12評価容易性

採用しやすい条件:

• 開発の大半が GitHub Issue/PR で回っている
• 監査と権限統制が重要
• PR 単位で成果をレビューできる
• GitHub Actions でテスト/ビルドが完結する

避ける条件:

• 複数 VCS/複数リポジトリーを一括変更する必要がある
• 主要タスクが長時間ジョブ中心
• ローカル専用依存が多い

高速な少人数プロダクトチーム

第一候補:

• Claude Code
• Codex CLI
• Cursor
• Cline
• Aider

重点軸: 1実行場所、3ツール拡張、4権限制御、5コンテキスト戦略、8 Git/PR 統合

採用しやすい条件:

• 意思決定者と実装者が近い
• ローカルでテストがすぐ回る
• rollback を git で管理できる
• 中央での統制より速度を優先できる

避ける条件:

• 厳格な職務分掌や中央監査が必須
• 開発者端末に強い secret が多い
• local-only policy が整備できない

エージェント基盤を自社運用したいチーム

第一候補:

• OpenHands SDK/Cloud/Enterprise
• Cline SDK
• Claude Agent SDK
• Copilot SDK

重点軸: 2オーケストレーション、3ツール拡張、4権限制御、6長時間タスク、7マルチエージェント、9観測性、10企業統制

採用しやすい条件:

• 既存の内製ポータルやチケットシステムへ統合したい
• 複数ユーザー/複数テナントの agent runtime を作りたい
• hooks、tools、MCP、telemetry を自社仕様に合わせたい

避ける条件:

• 運用チームがない
• sandbox/session/audit を自前で保守できない
• 既製 UI で十分

研究・評価チーム

第一候補:

• mini-SWE-agent
• SWE-agent
• OpenHands benchmarks / SDK

重点軸: 5コンテキスト戦略、7マルチエージェント、9観測性、11 OSS 透明性、12評価容易性

採用しやすい条件:

• trajectory を保存して失敗分析したい
• モデル比較やプロンプト比較をしたい
• 再現性が速度より重要

避ける条件:

• 日常開発 UX が最優先
• 非技術者も使う
• 監査/SSO/RBAC をすぐ要求される

横断的な調査結果

12軸を通して見ると、Agent Harness は次の4つの方向に進んでいる。

1つ目は、context と enforcement の分離である。CLAUDE.md、AGENTS.md、rules、memory、repo map、MCP metadata はモデルに与える文脈であり、操作を強制的に止める仕組みではない。強制には permission、sandbox、hook、managed policy が必要になる。

2つ目は、transcript/trajectory の重要性である。エージェントが何を読んだか、どの tool を呼んだか、どの観測結果を得たか、どこで compaction されたかが残るほど、失敗を後から分析できる。SWE-agent 系はこの思想を研究向けに徹底しており、Claude/Codex は hooks や transcript_path を通じて、これらの記録を運用側から参照できるようにしている。

3つ目は、拡張性がサプライチェーン問題になっていることだ。MCP server、plugin、skill、hook、subagent は便利だが、増えるほど tool metadata、認証情報、承認境界、配布経路、更新責任が増える。拡張の管理には、追加する手段だけでなく、無効化し、範囲を絞り、監査する手段も要る。

4つ目は、クラウド型とローカル型の差が、実行場所だけでなく成果物モデルの差になっていることだ。クラウド型の成果物は PR、branch、task board、usage report が中心で、ローカル型では working tree、terminal output、git commit、transcript が中心になる。どちらを選ぶかは、組織がどの成果物をレビュー・監査・保管したいかで決まる。

再現可能性ノート（2026-09-10検証スナップショット）

本稿の主張を更新する場合は、次の順で確認する。

1. 対象製品の実行面（CLI/IDE/cloud/SDK）を分ける
2. 12軸のうち、更新対象の軸だけを確認する
3. 公式ドキュメントの制限値・ベータ注記・プラン条件を確認する
4. 比較表と該当節だけを更新し、検証日を変える

おわりに

Agent Harness の実務上の差は、モデル名や「自律実装できます」という宣伝文句より、12軸のうちどこを製品が引き受け、どこを利用者の運用責任として残しているかに出る。

個人開発なら、多少の手動承認やローカル運用を引き受けても速さを取る価値がある。組織開発では、PR、監査、ポリシー、コスト、復旧まで含めた運用設計が決め手になる。研究開発では、trajectory と再現性が最も重要になる。

だから、「どのエージェントが一番賢いか」を問う前に、次の問いに答えておくとよい。

自分たちは、どの失敗を許容し、どの失敗を技術的に不可能にしたいのか。

この答えがあれば、Agent Harness の選定を要件に基づく技術判断として進められる。