Codex App Server を理解して、いまの自分には関係なさそうだと納得するまで

リード

OpenAI が「Codex App Server」というものを公開していて、その存在を知ったときに最初に感じたのは「これは Claude で言う MCP に近いのだろうか」という素朴な疑問でした。名前だけ眺めても何のための API なのか掴みきれず、調べながら整理することにしました。

結論から書いてしまうと、最終的には「いまの自分が触る必要はなさそう」というところに落ち着きました。ただ、その納得に至るまでに自分の中の理解がいくつか段階的に組み変わっていったので、その流れごと残しておこうと思います。

MCP と何が違うのか

最初に確かめたかったのは、Codex App Server と MCP の関係でした。両方とも JSON-RPC 2.0 を使う双方向プロトコルで、ドキュメント上でも「MCP のように」という表現で説明されています。同じ層の競合プロトコルなのかと思ったのですが、よく読むと 向きが違う ことに気付きました。

ざっくり図にするとこうなります。

[IDE / 自作アプリ] ──App Server──▶ [Codex エージェント] ──MCP──▶ [外部ツール/データ]

MCP は AI 側がクライアントになって、外部のツールやデータソースを呼びにいくための規格です。AI に道具を渡す側の仕組み、と言ってもいいかもしれません。一方の App Server は逆で、Codex エージェント自身がサーバーになっていて、それを VS Code 拡張や CLI、macOS アプリといったクライアント側から叩く形になっています。「エージェントをアプリに埋め込むための規格」と表現するのが一番しっくりきました。

なので両者は競合ではなく、別レイヤーで共存するものでした。実際 Codex 自身も MCP サーバーを接続して使えるので、App Server で Codex を呼び、その Codex がさらに MCP で外部ツールを呼ぶ、という入れ子も普通にあり得ます。

デスクトップ寄りという性質

次に気になったのは、これはどんな形態のソフトで使われるものなのか、という点です。トランスポートを見るとはっきりしていて、stdio、unix socket、ループバックの websocket と、いずれもローカル前提でした。非ループバックの websocket もありますが認証は整備途中、というステータスです。

加えて認証もユーザー単位で、エンドユーザー本人の ChatGPT OAuth か API キーで動く構造になっています。つまりモデル使用料を払うのは利用者本人で、開発者が肩代わりする SaaS の構造とは噛み合いません。

この時点で、Web の SaaS バックエンドに据える物ではなく、デスクトップアプリやローカルツール側に寄っていることがわかりました。集中ホスト型の用途には Codex SDK や Responses API が別に用意されているそうで、ここは住み分けがはっきりしていました。

API 組み込みの代用になるのか

ここでもう一歩、現実的な疑問が出てきました。これまで OpenAI の API で AI を組み込んでいたケースは、すべて Codex で置き換えられるのか?という話です。

調べていく中で、これは半分しか合っていない認識だとわかりました。App Server が提供しているのは、生の LLM エンドポイントではなく、Codex の harness 一式 だからです。harness というのはエージェントループ、ツール実行、承認、差分表示、スレッド永続化までを含んだ「コーディングエージェントとしての殻」のことで、要するに「Codex というエージェント本体」を丸ごと埋め込む API なのです。

ですので、自分でツール呼び出しのループを書いてコード操作させていたようなケースなら、harness ごと不要になるので置き換える価値があります。逆に、要約や翻訳、分類のような単発のテキスト処理に API を使っていたなら、Codex はコーディングエージェントとしてチューニングされているので過剰だし方向違いです。そのまま Responses API を使えばよい、という判断になります。

もとの用途	App Server で置き換えられるか
API + 自前エージェントループでコード操作	置き換えられる(harness ごと不要に)
要約・分類・翻訳・チャットボット	置き換え不要(Responses API で十分)
画像・音声・埋め込み	Codex の管轄外
モデルを細かく使い分けたい	不向き(モデル選択を内側に隠す設計)

そもそもエージェントループとは何か

ここまでで「harness」という言葉を使い始めたのですが、自分の中ではまだ実感が薄かったので、もう一段掘り下げて整理しました。

エージェントループというのは、ざっくり言えば LLM とツール実行を交互に回す while ループのことです。普通の API 呼び出しは「1 回呼んで終わり」ですが、コーディングエージェントは違います。LLM が「main.py を読みたい」と言ってきたらファイルを読んで結果を返し、「3 行目を書き換えたい」と言ってきたら確認を取って書き換え、「テストを走らせたい」と言ってきたら実行して結果を渡し、最後に「完了」と返すまで何ターンも回り続けます。

while True:
    response = llm.chat(messages, tools=tools)
    if response.finish_reason == "stop":
        break
    for call in response.tool_calls:
        result = execute_tool(call)  # read_file / write_file / run_shell など
        messages.append({"role": "tool", "content": result})

これだけだと骨組みで、実運用ではここに承認 UI、差分表示、スレッド永続化、トークン圧縮、暴走対策、並行ツール呼び出し、リトライ、モデル切り替え、ストリーミングといった付帯機能が一通り必要になります。これらを全部まとめたものが harness で、自前で作るとそれなりの工数になります。App Server はこの harness を丸ごと提供してくれるので、開発者が書くのは UI と承認の返事だけになる、というのがメリットの本体でした。

ループを乗せたアプリの形

抽象的な「harness」のままだとピンとこなかったのですが、身近な例に当てはめると一気に像が結ばれます。

Cursor や VS Code の Copilot Chat で「このバグを直して」と打ったときの画面を思い浮かべると、ファイルを読むアイコン、差分の提示、Accept/Reject ボタン、テスト実行のアイコンといった要素が順番に表示されますが、あれが裏で動いているエージェントループそのものです。read_file を呼べばファイル読み込みのアイコン、write_file の前で承認ボタン、run_shell を呼べばテスト実行、というふうに、ループの各ステップがそのまま UI 要素に対応しています。

これを一般化すると、エージェントループを使ったアプリは「人間が引き金を引くと、LLM が裏で何ターンも考えてツールを使い、必要なときだけユーザーに確認を取りに来る UI 体験」と定義できそうです。トリガーは何でもよくて、エディタのチャット入力でもメニューバーのクリックでもファイル監視でも構いません。

トリガー	UI	ループの中身
エディタのチャット	Cursor のサイドパネル	コードベース操作
メニューバークリック	Raycast パネル	ファイル整理
メモの TODO 行	macOS 通知	git + ファイル編集
音声	通知センター	Codex 標準ツール
Slack メンション	Slack スレッド	リポジトリ操作

Cursor も「VS Code に AI を埋めた専用エージェントアプリ」と捉えれば、この枠組みの中にすっぽり収まります。

専用エージェントを作る側のための基盤

ここまで来てようやく、App Server の本当の立ち位置が見えてきました。これは消費者向けではなく、専用エージェントアプリを作って配る側のための基盤 です。

普段から Codex CLI や Claude Code を使っていれば、エージェントループ、承認 UI、差分表示、スレッド永続化、MCP 拡張といったものはすでに手元に揃っています。ここに App Server を被せて自作 UI を作っても、CLI でできることを再発明するだけになりがちです。

価値が出るのは、汎用 CLI ではカバーできない方向に進みたいときでした。整理するとだいたい以下のパターンに分かれます。

• トリガーが特殊: git push hook、ファイル監視、Slack bot、音声起動など、対話前提の CLI では扱いにくい起動方法を取りたい
• UI が特殊: メニューバー、GUI 差分、スマホ通知、iPad など、ターミナルでは出せない体験にしたい
• ツールセットを絞りたい: 子供用、経理専用、執筆専用などで、「何でもできてしまう」を意図的に制限したい
• 他人に配りたい: 非エンジニアの家族、同僚、顧客といった、ターミナル前提では届かない相手に渡したい
• ワークフローを固定化したい: 毎回同じ手順をボタン一つに圧縮し、プロンプトを書き直す非効率をなくしたい

このどれかに当てはまる動機があるなら App Server を選ぶ意味があり、そうでないなら手元の汎用エージェントで十分、という線引きが自分の中で立ちました。

いまの自分にはひとまず関係なさそう

ここまで整理して、最後に「では自分は今これを使うか?」という問いに戻ってみると、答えはほぼ「いいえ」でした。

普段の作業はターミナルで Codex CLI や Claude Code を回せば成立しています。プロンプトを毎回書くのも特に苦ではないですし、標準のツールセットで困っていません。アプリとして他人に配りたい対象もいま手元にはなく、固定化したいワークフローも具体的には浮かんでいません。つまり「価値が出る 5 パターン」のどれにも、今の自分は当てはまっていない状態です。

ただ、これは「今は」という限定付きの結論でもあります。もし将来、家族や非エンジニアの同僚に自分の作業の一部を渡したくなったときや、特定のリポジトリでだけ動く専用レビュアーを誰かに使ってもらいたくなったとき、あるいは音声起動やメニューバー常駐のような少し変わったトリガーで動かしたくなったとき、そこで初めて App Server を引っ張り出してくる、というのが現実的な距離の取り方だと思っています。

「触らないと決めた」のではなく、「触る理由ができたら戻ってくる場所として頭に置いておく」という整理ができたのは、今回調べてみた一番の収穫でした。