For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme
Aug 19, 2026 Codex

プラットフォームとしての Codex:オープンソースのエージェントハーネスを使った開発

ユーザーが使い慣れた製品やワークフローに Codex を組み込む方法を紹介します。

著者: Nicolas Bonamy, Derrick Choi

プラットフォームとしての Codex:オープンソースのエージェントハーネスを使った開発

多くの人にとって、Codex との接点は App、コマンドラインインターフェース、IDE 拡張機能です。どれも重要ですが、これらを支える共通のシステムには、ほかにもさまざまな使い道があります。

そのすべてを支えているのが、オープンソースの Codex ハーネスです。ハーネスがあることで、モデルはコンテキストを収集し、タスクの進め方を推論し、ツールを使えます。また、設定された範囲内で動作し、必要に応じて承認を求めながら作業を進められます。

この仕組みによって、開発者が作れるものの幅が広がります。すべてのチームに汎用のコーディングアシスタントへの移行を求める代わりに、実際の業務に合わせて設計したソフトウェアにエージェントを組み込めます。開発ワークフローや運用ダッシュボード、セキュリティ調査、カスタマーサポート用のコンソール、特定の専門チーム向けの社内アプリケーションなどがその例です。

再利用できるエージェントループ

実用的なエージェントには、プロンプトを受け取ってモデルの応答を返すだけでなく、タスクを理解し、作業を通してコンテキストを維持する仕組みが必要です。関連情報の確認、ツールの呼び出し、進捗の表示、失敗への対処も必要です。必要に応じて人間に承認を求め、最終的に役立つ結果を返すところまでがエージェントの仕事です。

こうした処理を支える実行システムがハーネスです。

ハーネスの設計は結果を大きく左右します。ARC-AGI-3 では、推論内容の保持とコンテキストのコンパクションにより、GPT-5.6 Sol のスコアが 13.3% から 38.3% に上昇し、出力トークン数は 6 分の 1 に減少しました。

Codex ハーネスは、会話の状態を管理し、実行状況をストリーミングし、ツールを利用し、設定されたサンドボックスと承認のポリシーを適用しながら、ターンをまたいで作業を引き継げるように設計しました。Codex app-server では、仕様を公開しているクライアントプロトコルを通じて、これらの機能を利用できます。アプリケーションからスレッドを作成し、ターンを開始し、イベントを受信し、承認リクエストに対応できます。

エージェントを必要とするソフトウェアを開発するなら、ランタイムを一から作る代わりに Codex を出発点にして、どこまでをアプリケーション側で担うかを決められます。

開発者が仕組みを確認し、製品に合わせて活用できるハーネス

ハーネスはオープンソースなので、アプリケーションとモデルの間で何が起きているのかをコードから理解し、自分の製品に合う形で統合できます。

開発者は次の点を調整して、エージェントを製品に合わせられます。

  • インターフェース。すべての操作を汎用のチャット画面に集約する必要はありません。チームが使っているダッシュボード、エディター、キュー、地図、レコード、承認フローをそのまま活用できます。

  • コンテキストとツール。アプリケーションは、自ら管理する MCP サービスも含め、特定のワークフローに必要なシステム、ドキュメント、データ、操作をエージェントに提供できます。

  • 運用上の制約。エージェントの実行場所、アクセスできるファイルやツール、承認が必要な操作はホストアプリケーションが決められます。作業の監視方法や、正式な記録を管理するシステムに結果を反映する方法も決められます。

Codex CLI、app-server、公式 Codex SDK は、オープンソースのコンポーネントとして公開しています。利用できるコンポーネントとそれぞれの公開場所は、オープンソースコンポーネントガイドにまとめています。

オープンソースとして提供しているのは、ハーネスと統合用のインターフェースです。モデルへのアクセスとマネージドサービスは別途提供しています。

用途に合った統合方法の選択

Codex の組み込み方は、用途に応じて選べます。

  • スクリプト、CI ジョブ、単発のバックグラウンドタスクには codex exec を使えます。範囲を限定したエージェントワークフローを実行し、構造化された出力を受け取れます。

  • アプリケーションのコードから Codex のタスクを開始、再開したり、実行状況をストリーミングしたりするには、公式 Codex SDK のインターフェースを直接利用できます。

実行可能なサンプルは、Codex SDK のドキュメントをご覧ください。

エージェントを製品自体の一部として組み込む場合は、Codex app-server を使います。アプリケーションからローカルの Codex プロセスに接続し、会話を維持しながら、イベントのストリーミング、作業の中断、ツールの提供、承認リクエストへの応答ができます。SDK はコードから一般的なワークフローを実行する手間を減らします。app-server を使えば、製品チームがエージェントのライフサイクルとユーザー体験を直接制御できます。

業務の流れに合わせたソフトウェア設計

Codex App のロゴだけを差し替えて再現するよりも、特定の担当者やチームが普段どのように仕事を進めているかを反映したソフトウェアを作る方が、はるかに大きな可能性があります。

たとえばセキュリティアナリストには、調査キュー、直近のアラート、影響を受けたサービスの情報に加えて、修正対応のチケットを起票する前の承認ステップが必要かもしれません。サポートエンジニアなら、アカウントの履歴、製品ログ、社内ドキュメント、返信の下書きが役立ちます。製品チームなら、課題を着手可能な状態に移すと、あらかじめ範囲を定めた実装ワークフローが始まるタスクボードを使いたいかもしれません。

どの例でも、インターフェースはユーザー体験の重要な部分を担います。ユーザーが見ているものをエージェントに伝え、適切なツールを提供すると同時に、ユーザーが次の操作を確認する場にもなります。

アプリケーションが管理するインターフェース、業務コンテキスト、ユーザーの同意、Codex app-server が担うエージェントループとサンドボックス内での実行、アプリケーションが MCP 経由で提供するデータと操作を示した構成図。

図 1。アプリケーションは製品のコンテキスト、業務ルール、ツールを管理し、Codex app-server はエージェントループとサンドボックス内での実行を担います。

実装例:Relay

Relay は、Codex app-server を使って開発した業務アプリケーションのサンプルです。架空の配送ダッシュボードの横にエージェントを配置し、アプリケーションが管理する MCP ツールに接続しています。配送予約を取り直すには、人間の承認が必要です。

ユーザーが最初にプロンプトを一から書く必要はありません。対象の配送を選択し、Compare recovery などのアクションをクリックします。アプリケーションが関連するコンテキストを提供し、Codex がサンプルの業務データから最新の情報を取得すると、エージェントが選択肢を説明します。業務に影響する書き込みには、必ず承認が必要です。

Codex は、アプリケーションの MCP ツールで最新データを取得したうえで、対応を提案したり、承認を受けて実行したりできます。ツールが元のレコードを変更すると、アプリケーションは業務画面の表示を更新します。ハーネスはエージェントループ、会話の状態、実行状況のストリーミング、ツールとのやり取りを担います。ダッシュボード、レコード、操作機能は引き続き製品側で管理します。

Relay には架空のデータをあらかじめ用意していますが、この統合方法は広く応用できます。インシデント対応、アカウント管理業務、調査ワークフローなど、既存の製品を使いながらエージェントに作業を任せたい場面で活用できます。

Relay の配送業務ダッシュボード。例外対応キュー、配送の詳細、配送遅延を調査している Codex エージェントが表示されています。

図 2。Relay は配送業務ダッシュボードに Codex を組み込んでいます。MCP ツールはアプリケーション側で管理し、業務に影響する操作には人間の承認を求めます。

開発者による活用事例

この統合方法を採用した事例はすでに公開されています。

  • GitHub と JetBrains は、既存の IDE ワークフローに Codex を組み込んでいます。

  • Cisco は、Cisco Cloud Control 内の App Builder で Codex SDK を利用しています。

  • Thrive Holdings と Crete は、実務担当者のフィードバックを取り入れた税務申告書作成ワークフローで Codex を利用しています。試験運用では 7,000 件の申告書を処理し、作成時間を約 3 分の 1 短縮しました。

活用の場はエンジニアリングに限りません。顧客の問題を調査するサポートチーム、業務の進行を調整する運用チーム、インシデントの優先順位を判断するセキュリティチーム、取引先を調査する営業チーム、キャンペーンを企画するマーケティングチームにも同じ方法を適用できます。どの場合も、アプリケーションがコンテキスト、ツール、承認の仕組みを提供し、その基盤となるエージェントループを Codex が担います。

チャットの枠を超えた開発

多くの業務では、判断に欠かせないコンテキストが、ダッシュボード、タイムライン、地図、ドキュメント、あるいはシステム上のレコードにあります。こうした画面には、見栄え以上の意味があります。担当者はそこに示される情報をもとに状況を把握し、判断を下し、自分で業務の進め方を決めています。

こうしたインターフェースを汎用のチャット欄に置き換えるよりも、エージェントを組み込むことで、今の画面でできることを増やせます。エージェントが業務を理解し、関連するコンテキストを調べ、次の手順を提案し、承認された操作を実行できるようになります。

Codex App、CLI、IDE 拡張機能は、ハーネスで何ができるかを示す実例です。ハーネスをオープンソースにすることで、開発者がその仕組みを確認し、自分の製品やワークフローに合わせて機能を取り込み、調整できるようにしました。

Codex ハーネスを使って開発するには、まずオープンソースの Codex リポジトリを確認し、製品に合った統合方法を選んでください。非対話型のジョブには codex exec、コードから実行するエージェントワークフローには Codex SDK、会話の継続、イベントのストリーミング、承認リクエストへの対応が必要なアプリケーションには Codex app-server が適しています。