Claude Code、Codex、Gemini のマルチプラットフォーム戦略を比較する

Anthropic Claude Code、Google Gemini、OpenAI Codex。AI コーディングツールの主要 3 社は、いずれも CLI、Web アプリ、デスクトップアプリ、IDE 拡張と、複数のプラットフォームに展開しています。

自分がマルチプラットフォーム対応のプロダクトを設計する立場だったら、この 3 社のアーキテクチャは最高のリファレンスになります。それぞれ異なるアプローチを採りながら、同じ「1 つのコアロジックを複数のサーフェスに届ける」という課題を解いているからです。

本記事では、3 社のマルチプラットフォーム戦略を比較し、自社プロダクトの設計に活かせるパターンを整理します。

3 社のプラットフォーム展開状況

まず、各社がどのプラットフォームに展開しているかを確認します。

プラットフォーム	OpenAI Codex	Claude Code	Google Gemini
CLI	Codex CLI	Claude Code CLI	Gemini CLI
Web アプリ	Codex Web（chatgpt.com）	claude.ai/code	gemini.google
デスクトップアプリ	Codex macOS アプリ	Claude Desktop	Gemini アプリ（モバイル中心）
VS Code 拡張	Codex VS Code	Claude Code VS Code	Gemini Code Assist
JetBrains 拡張	Codex JetBrains	Claude Code JetBrains	Gemini Code Assist
Xcode 統合	Codex Xcode	Claude Agent SDK for Xcode	なし
モバイルアプリ	ChatGPT アプリ内	Claude iOS アプリ	Gemini アプリ
API	Responses API / Codex App Server	Claude API / Agent SDK	Gemini API / Vertex AI
エージェント IDE	なし	なし	Antigravity

3 社とも CLI、Web、IDE 拡張という主要サーフェスをカバーしていますが、その実現方法は大きく異なります。

OpenAI Codex: App Server プロトコルによる統一

OpenAI は Codex のマルチプラットフォーム展開を、Codex App Server という双方向 JSON-RPC プロトコルで解決しています。

設計の経緯

Codex は TUI（ターミナルユーザーインターフェース）として始まりました。VS Code 拡張機能を開発した際、同じエージェントループを IDE UI から再実装せずに駆動する方法が必要になりました。

最初に MCP（Model Context Protocol）サーバーとして公開することを試みましたが、VS Code にとって意味のある形で MCP のセマンティクスを維持するのが難しいことがわかりました。IDE には、ワークスペースの探索、エージェント推論中の進捗ストリーミング、差分出力といった、リクエスト/レスポンスを超えた豊富なインタラクションパターンが必要だったからです。

代わりに、TUI ループを反映した JSON-RPC プロトコルを導入し、これが App Server の初期バージョンとなりました。

Codex のアーキテクチャ全体像

graph TB
    subgraph "自社プロダクト"
        A["Codex Desktop App"]
        B["Codex TUI / CLI"]
        C["Codex Web Runtime"]
    end

    subgraph "サードパーティ統合"
        D["JetBrains IDEs"]
        E["VS Code (Codex)"]
        F["Xcode"]
    end

    G["Codex Harness<br/>(via App Server)"]

    A -- "JSON-RPC<br/>over stdio" --> G
    B -- "JSON-RPC<br/>over stdio" --> G
    C -- "HTTP + SSE" --> G
    D -- "JSON-RPC<br/>over stdio" --> G
    E -- "JSON-RPC<br/>over stdio" --> G
    F -- "JSON-RPC<br/>over stdio" --> G

すべてのクライアントサーフェスは、同じ Codex ハーネス（エージェントループとコアロジック）を App Server 経由で利用します。トランスポートは JSON-RPC over stdio（JSONL）です。

3 つの会話プリミティブ

App Server プロトコルは 3 つのコアプリミティブで構成されています。

graph TB
    subgraph Thread["Thread（スレッド）"]
        direction TB
        T1["永続的なセッションコンテナ"]
        subgraph Turn1["Turn（ターン）"]
            direction LR
            I1["Item<br/>item/started"]
            I2["Item<br/>item/*/delta"]
            I3["Item<br/>item/completed"]
            I1 --> I2 --> I3
        end
        subgraph Turn2["Turn（ターン）"]
            direction LR
            I4["Item"] --> I5["Item"] --> I6["Item"]
        end
        Turn1 --> Turn2
    end

Item（アイテム）: ユーザーメッセージ、エージェントメッセージ、ツール実行、承認リクエスト、差分といったタイプを持つ最小単位。item/started → item/*/delta → item/completed という明確なライフサイクルがある
Turn（ターン）: ユーザー入力によって開始されるエージェント作業の 1 単位。ユーザーが入力を送信した時点で始まり、エージェントがその入力に対する出力を完了した時点で終了する
Thread（スレッド）: ユーザーとエージェント間の継続的な Codex セッションを保持する永続的なコンテナ。作成、再開、フォーク、アーカイブが可能

サーバー起動リクエスト

App Server の特徴的な設計は、サーバーからクライアントへのリクエストです。エージェントがコマンド実行前にユーザーの承認を必要とする場合、サーバーがリクエストを送信し、クライアントが「許可」または「拒否」で応答するまでターンを一時停止します。

// サーバー → クライアント: 承認リクエスト
{
  "method": "item/commandExecution/requestApproval",
  "id": 42,
  "params": {
    "reason": "run tests"
  }
}
 
// クライアント → サーバー: 承認レスポンス
{
  "id": 42,
  "result": {
    "decision": "allow"
  }
}

この双方向性により、各クライアントは自身の UI パターンに合わせて承認フローを実装できます。VS Code ならダイアログ、CLI ならインラインプロンプト、Web ならモーダルといった具合です。

3 つのデプロイパターン

パターン	トランスポート	特徴
ローカルアプリ / IDE	stdio	プラットフォーム固有の App Server バイナリをバンドルし、子プロセスとして起動
Web	HTTP + SSE	コンテナ内で App Server を起動し、ブラウザとは HTTP/SSE で通信
TUI / CLI	stdio（同一プロセス）	歴史的にはネイティブクライアントだったが、App Server 経由に移行中

パートナー統合（JetBrains、Xcode など）では、クライアントを安定させたまま新しい App Server バイナリを指すことでリリースサイクルを分離できます。App Server の JSON-RPC インターフェースは下位互換性を保つよう設計されているため、古いクライアントも新しいサーバーと安全に通信できます。

Codex のアプローチから学べること

プロトコルファースト: コアロジックを独自のプロトコルで公開し、各クライアントがそのプロトコルのクライアントになる設計。プロトコルが安定していればクライアントのリリースサイクルを分離できる
MCP では不十分だった理由: IDE が必要とするストリーミング差分、承認フロー、スレッド永続性は MCP のツール指向モデルには収まらなかった。自社プロダクトのインタラクションパターンに合ったプロトコル設計が重要
下位互換性の設計: パートナー統合では頻繁なクライアントアップデートが難しいため、サーバー側の改善をクライアントのリリースを待たずに展開できる設計にした

Claude Code: Agent SDK によるハーネスのライブラリ化

Anthropic は Claude Code のマルチプラットフォーム展開を、Claude Agent SDK というライブラリで解決しています。

設計の経緯

Claude Code は CLI として始まり、そのコアエンジン（エージェントループ、ツール実行、パーミッション管理、コンテキスト管理）が「エージェントハーネス」として分離されました。このハーネスを Claude Agent SDK として Python と TypeScript のライブラリで公開し、CLI、デスクトップアプリ、Web、IDE 拡張のすべてが同じハーネスを共有する構成になっています。

Claude Code のアーキテクチャ全体像

graph TB
    SDK["Claude Agent SDK<br/>(エージェントループ / ツール / パーミッション)"]

    SDK --> CLI["CLI"]
    SDK --> Desktop["Desktop App"]
    SDK --> Web["Web"]
    SDK --> IDE["IDE 拡張<br/>(VS Code, JetBrains)"]

    Config["~/.claude/<br/>共有設定・CLAUDE.md・MCP"]
    Config -. "全プラットフォームで共有" .-> CLI
    Config -. "全プラットフォームで共有" .-> Desktop
    Config -. "全プラットフォームで共有" .-> Web
    Config -. "全プラットフォームで共有" .-> IDE

ハーネスの構成要素

Claude Code のハーネスは以下のコンポーネントで構成されています。

パーミッションパイプライン: すべてのツール呼び出しを deny-first のルール評価システムで制御します。モデルが「何をしたいか」を決め、別のシステムが「それを許可するか」を判断する分離設計です。auto モードでは、バックグラウンドで別のモデルインスタンスが安全性を検証します。

ツールディスパッチ: Read、Edit、Bash、Grep、WebSearch など約 19-40 のパーミッションゲート付きツールを提供します。各ツールは独立してサンドボックス化され、ファイルシステムへのブランケットアクセスではなく、ツールごとの粒度の細かい制御が行われます。

コンテキスト管理: トークン使用量がコンテキストウィンドウの 98% に近づくと、自動的に過去の履歴を要約します。MCP ツールの出力は 25,000 トークンの上限を持ち、超過分はディスクに永続化されます。

セッション管理: セッションはローカルにメッセージ、ツール使用、結果の全履歴を保存します。変更前にスナップショットを取得し、ロールバックを可能にします。

SDK としての公開

Claude Agent SDK は、このハーネスをライブラリとして提供します。

from claude_agent_sdk import query, ClaudeAgentOptions
 
async for message in query(
    prompt="Find and fix the bug in auth.py",
    options=ClaudeAgentOptions(
        allowed_tools=["Read", "Edit", "Bash"],
        permission_mode="acceptEdits",
    ),
):
    print(message)

SDK には組み込みのツール実行が含まれているため、利用者はツールの実装を自分で行う必要がありません。ファイル読み取り、コマンド実行、コード検索といった機能がそのまま使えます。

クロスプラットフォームの統一

すべてのプラットフォームが ~/.claude/ の設定を共有し、CLAUDE.md ファイル、MCP サーバー設定、auto memory が全サーフェスで動作します。v1.8.0 ではクロスプラットフォームの動作パリティが強化され、同じルール、エージェント、スキルが 4 つのプラットフォームすべてで統一的に動作するようになりました。

さらに、セッションの移動も柔軟です。CLI で開始したセッションを /desktop コマンドでデスクトップアプリに引き継いだり、Web で開始した長時間タスクを claude --teleport でターミナルに取り込んだりできます。

Claude Code のアプローチから学べること

ライブラリファースト: コアロジックをプロトコルではなくライブラリ（SDK）として公開する設計。利用者はプロトコルのクライアント実装ではなく、関数呼び出しでエージェントを駆動できる
設定の共有: ~/.claude/ のようなユーザーレベルの設定ディレクトリを全プラットフォームで共有することで、プラットフォーム間の設定の一貫性を確保
セッションの可搬性: セッションをプラットフォーム間で移動できる設計は、ユーザーのワークフローの柔軟性を大幅に向上させる

Google Gemini: 3 プロダクトによるスペクトラム戦略

Google は OpenAI や Anthropic とは異なり、単一のコアエンジンを複数のクライアントに展開するのではなく、自律性のレベルに応じた 3 つの独立したプロダクトを提供するアプローチを採っています。

3 つのプロダクト

Gemini Code Assist: 既存の IDE（VS Code、JetBrains、Android Studio）の拡張機能として動作するコーディングアシスタント。開発者がドライバーで、AI がコパイロットという位置づけです。

Gemini CLI: Apache 2.0 ライセンスのオープンソース CLI ツール。ターミナルネイティブな開発者向けに、自動化とスクリプト可能なワークフローを提供します。

Antigravity: VS Code フォークのエージェントファースト IDE。エディター、マネージャー（自律エージェントのオーケストレーション）、ブラウザ統合（自動テスト）の 3 つのサーフェスで構成されています。

自律性スペクトラム

graph LR
    subgraph "低い自律性"
        A["Gemini Code Assist<br/>(IDE 拡張)<br/>AI = コパイロット"]
    end
    subgraph "中程度の自律性"
        B["Gemini CLI<br/>(ターミナル)<br/>AI = ユーティリティ"]
    end
    subgraph "高い自律性"
        C["Antigravity<br/>(エージェント IDE)<br/>AI = 自律する開発者"]
    end

    A --> B --> C

Google の戦略は、1 つのプロダクトを全プラットフォームに展開するのではなく、プラットフォームごとに最適化された専用プロダクトを提供するという考え方です。

IDE 統合のアプローチ

Gemini CLI の IDE 統合は、ACP（Agent Client Protocol）というオープンスタンダードを採用しています。IDE ごとに個別の統合を構築するのではなく、標準化されたプロトコルで JetBrains、Zed などの IDE と接続します。

VS Code に対しては専用のコンパニオン拡張機能も提供し、ワークスペースの認識（最近アクセスした 10 ファイル、アクティブなカーソル位置、選択テキスト）とネイティブの差分表示を実現しています。

バックエンドの多層構造

Google のもう 1 つの特徴は、バックエンドの認証方法によって異なるサービス層にアクセスする設計です。

認証方法	接続先	用途
Google アカウント	Gemini Code Assist サービス	個人利用（無料枠あり）
Gemini Developer API キー	Gemini API	開発者向け API アクセス
Vertex AI	Google Cloud	エンタープライズ向け

同じ CLI ツールでも、認証方法を変えるだけで接続先のサービスと適用される利用規約が変わります。

Google のアプローチから学べること

プロダクト分離戦略: 自律性レベルの異なるユースケースには、無理に 1 つのプロダクトで対応するのではなく、別プロダクトとして提供する選択肢がある
オープンプロトコルの活用: ACP のようなオープンスタンダードを採用することで、IDE 統合の開発コストを下げつつ、エコシステムの拡大を狙える
認証レイヤーによるサービス分離: 同じクライアントから認証方法を変えるだけで異なるサービス層に接続する設計は、個人ユーザーからエンタープライズまでの段階的な提供に有効

3 社の設計パターン比較

graph TB
    subgraph Claude["Claude Code: ライブラリファースト"]
        direction TB
        CL_Core["Agent Harness"]
        CL_SDK["Agent SDK<br/>Python / TypeScript"]
        CL_Clients["CLI / Desktop / Web / IDE"]
        CL_Core --> CL_SDK --> CL_Clients
    end

    subgraph Codex["Codex: プロトコルファースト"]
        direction TB
        C_Core["Codex Core (Rust)"]
        C_Proto["App Server<br/>JSON-RPC プロトコル"]
        C_Clients["CLI / Desktop / Web / IDE"]
        C_Core --> C_Proto --> C_Clients
    end

    subgraph Google["Gemini: プロダクト分離"]
        direction TB
        G_API["Gemini API / Vertex AI"]
        G_P1["Code Assist"]
        G_P2["Gemini CLI"]
        G_P3["Antigravity"]
        G_API --> G_P1
        G_API --> G_P2
        G_API --> G_P3
    end

設計判断	OpenAI Codex	Claude Code	Google Gemini
コア抽象化	独自プロトコル（App Server）	ライブラリ / SDK（Agent SDK）	プロダクト分離
統合方式	JSON-RPC over stdio	SDK の関数呼び出し	ACP + 専用拡張
MCP との関係	検討したが不採用。別途 MCP サーバーとしても公開	ツール統合に MCP を活用	ACP を主軸に採用
セッション永続性	Thread のフォーク・再開・アーカイブ	セッション ID での再開・フォーク	プロダクトごとに異なる
パートナー統合	サーバーバイナリの差し替えでリリースサイクルを分離	SDK のバージョンアップで追従	ACP レジストリで自動配布
オープンソース	Codex CLI（Rust）	Claude Code CLI は非公開。Agent SDK は公開	Gemini CLI（Apache 2.0）

自社プロダクトに応用するなら

3 社のアプローチを踏まえて、マルチプラットフォーム対応の設計パターンを整理します。

パターン 1: プロトコルファースト（Codex 型）

コアロジックを独自の双方向プロトコルで公開し、各プラットフォームがそのプロトコルのクライアントとなる設計です。

向いているケース:

サードパーティによる統合を広く受け入れたい
クライアントとサーバーのリリースサイクルを分離したい
豊富なインタラクション（ストリーミング、承認フロー）が必要

トレードオフ:

クライアント側で JSON-RPC バインディングの構築が必要
プロトコルの下位互換性の維持にコストがかかる

パターン 2: ライブラリファースト（Claude Code 型）

コアロジックを SDK（ライブラリ）として公開し、各プラットフォームが SDK を組み込む設計です。

向いているケース:

自社のプラットフォーム展開が中心で、サードパーティ統合は限定的
利用者にとって導入のハードルを下げたい（関数呼び出しで完結）
ツール実行などの組み込み機能を提供したい

トレードオフ:

SDK がサポートする言語に制約がある（Python、TypeScript など）
SDK のアップデートに各クライアントが追従する必要がある

パターン 3: プロダクト分離（Google 型）

ユースケースやプラットフォームごとに独立したプロダクトを提供する設計です。

向いているケース:

ユーザーの利用パターンがプラットフォームごとに大きく異なる
各プラットフォームで最適化された体験を提供したい
チームが十分に大きく、複数プロダクトの並行開発が可能

トレードオフ:

プロダクト間の機能パリティの維持が困難
ブランドの統一性の管理が複雑になる

どのパターンを選ぶか

筆者の考えでは、多くのスタートアップにとってはパターン 2（ライブラリファースト）が最も現実的な出発点です。まず CLI をコアとして開発し、そのコアロジックを SDK として分離する。その後、Web アプリや IDE 拡張が SDK を組み込む形で展開していく。

パターン 1（プロトコルファースト）は、サードパーティの IDE やツールとの統合が主要な要件になった段階で検討する価値があります。OpenAI が最初は CLI として始まり、VS Code 統合の必要性から App Server を設計したように、プロトコルの必要性はユースケースの拡大とともに自然に生まれます。

パターン 3（プロダクト分離）は、Google のようにリソースが潤沢で、各プラットフォームに専用チームを割ける組織向けです。

まとめ

OpenAI Codex、Claude Code、Google Gemini の 3 社は、それぞれ異なるアプローチでマルチプラットフォーム展開を実現しています。

OpenAI Codex: App Server という双方向 JSON-RPC プロトコルで統一。MCP を検討した上で独自プロトコルを選択し、サードパーティ統合のリリースサイクル分離まで設計に組み込んだ
Claude Code: Agent SDK というライブラリでハーネスを公開。すべてのプラットフォームが同じ SDK を使い、設定の共有とセッションの可搬性でシームレスな体験を実現
Google Gemini: Code Assist、Gemini CLI、Antigravity の 3 プロダクトで自律性スペクトラムをカバー。ACP というオープンプロトコルで IDE 統合のエコシステムを構築

共通しているのは、「最初から全プラットフォームを同時に開発したわけではない」という点です。Codex は CLI から始まり、Claude Code も CLI から始まりました。コアを確立してから、プラットフォームを広げていく。この順序は、リソースの限られた組織にとって特に重要な教訓です。

以上、3 社のマルチプラットフォーム戦略をリサーチした現場からお送りしました。

参考情報

Codex ハーネスの解放：App Server を構築した方法（OpenAI、2026 年 2 月 4 日）
ハーネスエンジニアリング：エージェントファーストの世界における Codex の活用（OpenAI、2026 年 2 月 11 日）
Codex App Server ドキュメント
Claude Code の概要
Claude Agent SDK overview
Gemini CLI GitHub リポジトリ
Gemini Code Assist overview
Gemini CLI: IDE Integration