ブログ • AI / Agent

AI Coding Agent はもうコード補完だけではない：Codex、Claude Code、OpenCode、DeepSeek Harness は何を争っているのか？

二年前、「AI がコードを書く」と言えば、まだエディタの次行提案だった。2026 年、ターミナルで動いているのは別種の製品だ。Codex、Claude Code、OpenCode、DeepSeek Harness——ファイルを変え、テストを走らせ、MCP を呼び、Subagents を並行で立ち上げて調査までする。

表向き、四社は同じ能力を売っている。LLM + ツール + Agent loop。本当の戦場は機能一覧ではなく、アーキテクチャの中心にある。誰が Agent を強化し、誰が実行境界を握り、誰がモデル非依存に賭け、誰がランタイム自体を差し替え可能にするか。

この記事では次を整理する：

• Coding Agent が補完に対して足しているもの
• 四社がそれぞれ最適化している中心問題
• Claude Code / Codex / OpenCode / DeepSeek Harness のアーキテクチャ差
• 制御権マップ：モデル、ランタイム、ポリシー、人がそれぞれ何を握るか
• JSON Schema とツール契約がなお共通の土台である理由と、JSONNote でローカル検証する方法

本当に争っているもの

補完が解くのは「次の一行は何か」。Coding Agent が解くのは「この目標を実リポジトリでどうやり切るか」——文脈を読み、ツールを選び、コードを変え、コマンドを実行し、結果を見て、また判断する。

下層のループはほぼ同じだ：

User goal
  → Agent loop
  → LLM decides next action
  → Tool / environment executes
  → Result returns to context
  → Agent decides again

モデルは推論と次のアクションを担う。harness は何が見えるか、どのツールを呼べるか、ツールが実際に何をするか、状態の保存、どの操作に承認が要るか、完了の定義を決める。モデルが強くても、文脈が欠け、ツール契約が緩く、権限が広すぎ、失敗から戻れなければ結果は崩れる。

だから 2026 年の競争は「誰のベンチマークが高い」だけではなく、「知能・実行・ポリシー・ツール・人の制御を誰がより明確に組織するか」だ。四層の組み立ては次を参照：

2026 AI Agent 技術スタック：LLM、MCP、Function Calling、JSON Schema

四つのアーキテクチャ中心

まず境界を引く。機能一覧は似てくるが、中心の問いは違う：

最後の行は順位ではない。製品境界だ。「より強いアシスタント」を買うのか、「より制御可能な実行環境」か、「拡張可能な Agent プラットフォーム」か。

Claude Code：Agent 中心

Claude Code は主 Agent を中心にした製品だと捉えるのがいちばん近い。Skills、MCP、Subagents、Hooks、権限はいずれも同じ Claude Agent をより有効にするためのものであって、Agent loop 自体を差し替え可能なカーネルに分解する設計ではない。

典型的な拡張点は次の通り：

• CLAUDE.md：プロジェクト級の文脈と規約
• Skills：再利用可能な経験とワークフローの束
• MCP：外部システムへの接続
• Subagents：専門サブタスクと文脈の隔離
• Hooks / Permissions：ライフサイクルに確定的なルールを掛ける

エンジニアリング上の妥協は明確だ。確率的な Agent + 確定的な Hooks。編集後のテスト実行、危険コマンドの遮断、保護パスの事前承認——これらをモデルの「毎回の記憶」に頼ってはいけない。

向いているのは：ワークフローがはっきりしており、体験と文脈品質を重視し、Skills と Subagents で主ループを拡張するチーム。

Codex：実行中心

Codex（Codex CLI 含む）は問題を実行層に押し出す。Agent がファイル変更、shell 実行、依存関係のインストール、ネットワークや資格情報に触れられるなら、答えなければならない問いは二つある——能力の境界と、いま許されているか。

二つの仕組みが役割分担する：

原則は最小権限だ。まずフル権限を与えて「気をつけて」と頼むのではなく、環境を締めてから必要に応じて緩める。Rust 実装の CLI、OpenAI エンドポイント寄りの既定、強いサンドボックスの語りは、「Agent は実コンピュータで働く」という線に沿っている。

向いているのは：副作用のリスクが高い場面、監査可能な実行軌跡が要る場面、承認と隔離を第一級にする場面。オープンソースのリポジトリは

openai/codex。

OpenCode：モデル非依存

OpenCode の差別化は「別の Skills 構文」ではない。既定の立場だ——モデルは替えられる。MIT オープンソース、ターミナル優先、多数のプロバイダとローカルモデル（Ollama / LM Studio など）を支える。柔軟性は主に設定層——providers、models、permissions、themes——にあり、harness カーネルをプラグイン・バスに分解するわけではない。

ここから現実的な製品結論が出る。単一ベンダーのロックインを信じない、あるいは同一セッションで複数モデルを切り替えたいなら、OpenCode の中心の問いは「モデル供給者に縛られないには」だ。

勝ちやすい点は：

• マルチモデル／マルチプロバイダを既定の能力にする
• オープンソースの許諾とコミュニティ生態系
• 「モデルを替える」を第一級の操作にし、ベンダーのおまけにしない

代償もある。実行境界とプラグインの深さは、必ずしも売りの第一位ではない。買うのはモデル差し替えの harness であり、最も重いサンドボックス製品でも、「Everything is a plugin」のプラットフォーム核でもない。

DeepSeek Harness：ランタイム中心

DeepSeek Harness（dsh）は問題をもう一段内側へ押し込む。Agent Loop 自体も、永続のカーネルである必要がないとしたら？公開プレビューのスローガンは Everything is a plugin——モデル、ツール、skills、セッション、サンドボックス、ストレージ、loop、スケジューリング、UI まで差し替え可能だ。

これは「安定した核 + 外周の拡張点」とは違う。境界を内側へ押し、Agent を駆動する仕組み自体を再構成できる。能力の継ぎ目（capability seam）により、消費者は単一実装ではなく契約に依存する。ローカル shell とコンテナ shell、遠隔モデルとローカル推論、ReAct loop とワークフロー loop——提供側を替えても、すべてのツールを書き直さなくてよい。

だからよりプラットフォームに近い：

• Coding Agent：ReAct ループ
• Workflow Agent：ワークフロー + Agent
• 長時間タスク：目標 + スケジューリング + Job
• 異種 Subagents：他製品のバックエンドまで接続可能

組み合わせ可能性には代償がある。Plugin / Service / Provider / Effect / Session などの概念面が広い。「リポジトリを直してほしいだけ」のエンドユーザーには、Claude Code や Codex より学習曲線が高くなりうる。拡張可能な Agent プラットフォームを作るチームには、それが売りになる。

DeepSeek モデル API と JSON 出力に関心があるなら、まずこちらを：

DeepSeek V4-Pro 完全解説

制御権マップ

機能にチェックを入れるより有用なのは、各判断が誰に属するかを問うことだ。下表は四社の制御スタイルを圧縮したもの（OpenCode と dsh は「差し替え可能性」では近いが、深さは違う）：

もう一段下へ。タスク理解と計画生成はモデル寄り。引数検証、権限判断、ツール実行、実行の停止はプログラムとポリシー寄り。高リスク操作にはまだ人が要る。四社はこれらの語をすべて覆うが、重みを置くマスが違う。

JSON 契約はなお共通の土台

どの harness を選んでも、ツール呼び出しは最終的に機械実行可能な構造——関数名 + 引数 JSON——に落ちる。MCP の inputSchema / outputSchema、Function Calling の parameters、Structured Output の response_format。下層の言語はなお JSON Schema だ。

契約が現れる場所：

よくある失敗：モデル側の parameters と MCP inputSchema を別々に書き、フィールドや enum がずれ、「モデルがいつもツールをうまく呼べない」ように見える。直し方は一つの契約、二つのマウント。背景は

AI に JSON Schema が必要な理由とAI Agent の JSON Schema 完全解説。

{
  "name": "run_tests",
  "description": "Run the project test suite and return a structured summary.",
  "parameters": {
    "type": "object",
    "properties": {
      "suite": { "type": "string", "enum": ["unit", "integration", "e2e"] },
      "path": { "type": "string", "minLength": 1 }
    },
    "required": ["suite"],
    "additionalProperties": false
  }
}

この経路をデバッグするときは、ブラウザローカルで完結できる。データはアップロードしない：

1. 1
   arguments を整形する

   モデルが返した arguments 文字列をJSON フォーマットに貼り、まず合法な JSON か確認する。

2. 2
   Schema と照合して検証する

   JSON Schemaで required、enum、additionalProperties を確認する。

3. 3
   ドリフトを比較する

   モデル側 parameters と MCP inputSchema をJSON Diffでフィールドが一貫しているか見る。

どう選ぶか

熱量ではなく制約で選ぶ：

• ワークフローが明確で、強い体験と Skills が要る：Claude Code 寄り
• 実機の副作用が大きく、サンドボックスと承認が要る：Codex 寄り
• マルチモデル、ロックイン回避、オープンソース優先：OpenCode 寄り
• 拡張可能な Agent プラットフォームを作り、loop を差し替えたい：DeepSeek Harness 寄り

組み合わせもできる。たとえば OpenCode / dsh でマルチモデル実験し、本番の副作用は Codex 型の境界へ。あるいは主ループは Claude Code、外部システムは MCP。重要なのは「モデルのスコア」を唯一の調達指標にしないことだ。

よくある質問

AI Coding Agent とコード補完の本質的な違いは？

補完は次の一行を提案するだけ。Coding Agent はリポジトリを読み、ファイルを変え、コマンドを実行し、ツールを呼び、結果に応じてループで判断を続ける。競争の重点は「生成品質」から「実行境界とランタイム制御」へ移る。

Codex、Claude Code、OpenCode、DeepSeek Harness のどれが一番良い？

統一の勝者はない。何を最適化するかで決まる。体験と Skills なら Claude Code、サンドボックスと承認なら Codex、マルチモデルとロックイン回避なら OpenCode、差し替え可能なランタイムとプラットフォーム化なら DeepSeek Harness。

DeepSeek Harness と OpenCode はどちらもオープンソース。違いは？

OpenCode の柔軟性は主にモデルとプロバイダ設定にある。DeepSeek Harness（dsh）はモデル、ツール、loop、サンドボックス、セッションなどを差し替え可能なプラグインにしており、組み合わせ可能な Agent ランタイム・プラットフォームに近い。

なぜ今でも JSON Schema を語るのか？

ツール引数、MCP の inputSchema/outputSchema、Structured Output の下層はいずれも JSON Schema。harness が強くても、汚れた引数が実行層に入れば事故る——契約検証はなお Runtime の責務だ。

Agent を選ぶとき、いちばん見るべき層は？

制御権を見る。誰がツールを決め、誰が引数を検証し、誰が高リスク操作を承認し、誰がタスクを止めるか。モデルのスコアは入力の一つにすぎない。安全に完了できるかは harness が決める。

まとめ

Codex、Claude Code、OpenCode、DeepSeek Harness は同じ語彙を共有する。LLM、ツール、loop、文脈、Skills、Subagents、権限、Sandbox。もはや「より強い補完」ではなく、制御権の落としどころを争っている。

Claude Code は一つの Agent を強化する。Codex は実環境で制御可能に動かす。OpenCode はモデル差し替えに賭ける。DeepSeek Harness はランタイムと能力を組み合わせ可能なプラットフォームにする。

重要な問いはもう「モデルの呼び方」ではない。「知能・実行・ポリシー・ツール・文脈・人の制御をどう組織するか」だ。ツール契約層の JSON は、いまもローカルで照合できる層だ。

← ブログに戻る