開発mdx-playground

Codex SDK と App Server は何が嬉しいのか

Codex SDK について、「API key なしでも使える」「ChatGPT のサブスク範囲で動く」という話を見かけた。最初はかなり驚いたが、整理するとこれは OpenAI API SDK ではなく、Codex CLI をプログラムから操作するための SDK だと見た方がよさそうだった。

結論から言うと、Codex SDK や App Server は「クラウドアプリから OpenAI API を無料で叩ける抜け道」ではない。むしろ、Codex CLI でできる開発作業を、ローカルや信頼済みの実行環境からプログラム制御するための仕組み と考えるのが正確だと思う。

Codex SDK の正体

Codex の TypeScript SDK は、内部で codex CLI を起動する。SDK が OpenAI API に直接リクエストするというより、CLI を子プロセスとして立ち上げ、標準入出力で JSONL イベントをやり取りする。

つまり、できることの本質は CLI と同じ。

ただし、人間がターミナルで codex を叩く代わりに、Node.js から以下を制御できる。

  • 同じ thread で継続実行する
  • CI/CD や社内ツールから Codex に作業させる
  • streaming event や進捗を受け取る
  • structured output を扱う
  • 自作の修復ループやレビュー支援ツールに組み込む
  • CLI の認証済みセッションを再利用する

なので、嬉しさは CLI と違う能力を得ることではなく、CLI の Codex 体験を自動化・組み込みしやすくすること にある。

サブスク範囲で使える、の意味

手元で試す限り、OPENAI_API_KEY や CODEX_API_KEY を消しても、既に Codex CLI でログイン済みなら SDK 経由で動く。これは SDK 独自の認証ではなく、CLI 側のログイン状態を使っているからだと考えられる。

Codex の認証は大きく分けると次の2系統がある。

  • ChatGPT ログイン: ChatGPT のプランに紐づく Codex 利用
  • API key: OpenAI Platform の従量課金 API 利用

このため、ローカルの開発環境で「ChatGPT にログイン済みの Codex CLI」を SDK から呼ぶ、という使い方は自然に成立する。

ただし、これを 自分の SaaS にデプロイして、不特定多数ユーザーに API key なしで使わせる という発想にそのまま持ち込むのは危険だと思う。サーバー上に自分の Codex 認証情報を置き、その権限で shell やファイル操作を含むエージェントを動かすことになるからだ。

用途としては、ローカル開発、社内 runner、CI、個人用自動化などの「信頼済み環境」に寄っている。

Claude Code SDK の代替になるか

ある程度は代替候補になる。

特に近いのは、CLI エージェントをプログラムから呼び出して、リポジトリ操作・修正・レビュー・テスト実行を任せる用途。

たとえば以下のような使い方なら相性がよい。

  • CI で失敗したテストを Codex に調査させる
  • issue やログを渡して修正案を作らせる
  • 社内のコードレビュー支援ツールに組み込む
  • ローカルの定型作業を Codex に任せる
  • GitHub Actions や自前 runner から修復ジョブを実行する

一方で、ユーザー向けアプリに AI 機能を埋め込むなら、Codex SDK よりも OpenAI API、Responses API、Agents SDK の領域だと思う。Codex SDK は「開発作業をするエージェント」を制御する道具であって、一般的なプロダクト内 AI 機能の基盤ではない。

Codex App Server とは何か

Codex App Server も名前だけ見ると「OpenAI がクラウド側に用意しているアプリ用サーバー」に見えるが、そうではない。

実体は、codex app-server を起動して、クライアントアプリから JSON-RPC で Codex を操作するための仕組み。VS Code 拡張や独自 IDE、ブラウザ UI のような リッチな Codex クライアントを作るためのプロトコル と捉えるのがよさそうだ。

App Server で扱えるものは、たとえば以下。

  • thread の作成・継続
  • turn の実行
  • streaming events
  • 承認フロー
  • 会話履歴
  • 認証状態
  • planType や rate limit 状態

要するに、SDK よりも低レベルで、UI 統合寄りの仕組み。

公式にも、CI や自動化には Codex SDK を使うように書かれている。App Server は、単にジョブを走らせるためというより、Codex を操作する独自クライアントを作りたい場合 のものだと考える。

App Server はクラウドで使えるのか

クラウド上の VM や社内サーバーで codex app-server を起動すること自体はできるはずだ。WebSocket transport を使えば、自前のフロントエンドから接続する構成も考えられる。

ただし、これは OpenAI が提供するマネージド Codex API サーバーではない。

自分で用意する必要があるものは多い。

  • codex バイナリ
  • 実行環境
  • workspace
  • ファイルシステム
  • shell 実行権限
  • 認証情報
  • 承認・権限管理
  • ネットワーク公開時の認証設定

さらに、WebSocket transport は experimental / unsupported とされている。外部公開する場合は、かなり慎重に設計しないと危ない。

そのため、App Server も「クラウド本番アプリから API key なしで Codex を呼べる魔法」ではない。現実的には、remote dev box、社内の開発支援基盤、独自 IDE、信頼済みユーザー向けの開発環境 UI などが主戦場だと思う。

使い分け

自分の中では、ひとまずこう整理した。

用途向いているもの
ローカルで Codex を自動実行したいCodex SDK
CI/CD で修復・レビュー・テストを回したいCodex SDK
独自の Codex UI や IDE 連携を作りたいCodex App Server
ブラウザから remote dev box の Codex を操作したいCodex App Server
ユーザー向けアプリに AI 機能を入れたいOpenAI API / Responses API / Agents SDK
不特定多数にサブスク枠で推論機能を提供したいたぶん用途として不適切

まとめ

  • Codex SDK は OpenAI API SDK ではなく、Codex CLI をプログラムから操作する SDK
  • サブスクで使えるように見えるのは、CLI のログイン済みセッションを使えるため
  • CLI と本質的にできることは同じだが、自動化・CI・社内ツールへの組み込みがしやすい
  • Codex App Server は独自 Codex クライアントを作るための JSON-RPC サーバー
  • クラウドで起動することはできても、OpenAI のマネージド Codex API ではない
  • 本番のユーザー向け AI 機能には、素直に OpenAI API / Responses API / Agents SDK を使うのが筋

いまの理解では、Codex SDK / App Server の嬉しさは 「Codex をプロダクトの推論エンジンにすること」ではなく、「開発作業エージェントを自分の開発基盤に組み込むこと」 にある。

応用: 個人向けエージェント運用のひとつの形

ここで整理した使い分けを、実際に自分の用途に当てはめてみる。

検討中のものに アナリスト予想ビート率ウォッチャー がある。米国主要銘柄の四半期決算について、Whisper Beat やガイダンス vs コンセンサスの乖離を毎四半期トラッキングして、Beat-and-Raise / Beat-and-Cut の銘柄を通知してほしい、というやつ。詳細は memo/2026-05-18/earnings-beat-watcher-spec.md。

最初は Anthropic API を従量で叩く構成を考えていたが、毎年使う + 毎四半期 80 社程度 だと API 課金が地味に積み上がる。月額固定費の既製サービス（Benzinga Corporate Guidance API $99 など）も同じ問題で、サブスクが雪だるま式に増える。

このとき、いまの整理がそのまま使える。

  • 使うのは 自分一人だけ
  • 走る場所は 自分の PC か自宅機（信頼済み環境）
  • 認証情報も自分のものだけ
  • 不特定多数に推論機能を提供するわけではない

つまり Codex SDK / CLI の典型的なスイートスポットに入っている。

想定構成

  • エージェント本体: Codex CLI + Codex TypeScript SDK
  • 認証: ChatGPT サブスクで codex login 済み（API key 不要、既存サブスクの範囲）
  • 実行基盤:
    • Phase 1: メイン PC（Windows） + タスクスケジューラで PoC
    • Phase 2: 自宅 mini PC（Intel N100 or Raspberry Pi 5） + cron で 24/7 運用
  • 発火: 日本時間 朝 6:00（米AMC 後）/ 夕方 20:00（米BMO 前）
  • タスク:
    1. SEC EDGAR から 8-K Exhibit 99.1 を取得
    2. Codex SDK で codex を起動 → 「Outlook セクションを構造化 JSON で返せ」
    3. Whisper / Street コンセンサスと突き合わせて Beat-and-Raise / Beat-and-Cut フラグを判定
    4. Slack Webhook で通知、結果は Turso DB に蓄積
  • クラウドに置くもの: 蓄積先の Turso DB のみ（読み取りデータだけ、認証情報は出さない）

この構成の何がいいか

  • 月額追加コストは 0〜19（既存の ChatGPT サブスクで完結、必要なら FMP 無料枠 or $19）
  • 自分専用 = 信頼済み環境のままで、サーバーに認証情報をばら撒く話にならない
  • ルール調整・新銘柄追加は Claude Code 経由で会話的にできる
  • 5 年運用しても累計サブスク増分はほぼゼロ

この構成にしないこと

  • VPS / Cloudflare Workers / GitHub Actions に Codex CLI を置く構成は避ける
    • 認証情報リスクと、Codex CLI の動作前提（バイナリ + ログイン済みセッション）に合わない
  • Codex App Server を WebSocket で外部公開する構成も避ける
    • experimental / unsupported、信頼境界が曖昧になる
  • 不特定多数向け SaaS にこの仕組みを載せる発想はしない
    • メモ本文で繰り返し書いた通り、用途として不適切

結論

Codex SDK / App Server の嬉しさは「開発作業エージェントを自分の開発基盤に組み込むこと」だったが、「自分専用の継続業務エージェント（決算ウォッチ・市況メモ・税務リマインダーなど）を、サブスクの範囲で動かす」 という用途にも素直にハマる。

業務 SaaS の推論エンジンとして使う発想は引き続き持たない。ただし「自分の手元で動く専属アナリスト」を、API 課金を増やさずに作れる、というのが個人実務での落としどころになりそう。

参考