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

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

ユーザーが使い慣れた製品やワークフローに Codex を組み込みましょう。

著者: Nicolas Bonamy, Derrick Choi

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

多くの人は、AppコマンドラインインターフェースIDE 拡張機能を通じて Codex を知っています。これらは重要な利用形態ですが、共通の基盤システムを活用する方法の一部にすぎません。

これらすべてを支えているのが、オープンソースの Codex ハーネスです。モデルがコンテキストを集め、タスクについて推論し、ツールを使い、設定された制約の範囲内で動作し、承認を求め、作業を進められるようにします。

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

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

優れたエージェントには、プロンプトとモデルの応答だけでは不十分です。タスクを理解し、コンテキストを継続的に保持し、関連情報を調べ、ツールを呼び出し、進捗を示し、障害に対処し、必要に応じて人間の承認を求め、有用な結果を返す仕組みが必要です。

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

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

私たちは、会話の状態の管理、実行状況のストリーミング、ツールの使用、設定されたサンドボックスと承認ポリシーの適用、ターンをまたぐ作業の継続を担うものとして Codex ハーネスを構築しました。Codex app-server では、ドキュメント化されたクライアントプロトコルを通じて、これらの機能を公開しています。アプリケーションは、スレッドの作成、ターンの開始、イベントの受信、承認リクエストの処理を行えます。

エージェントを必要とするソフトウェアを開発する場合は、新しいランタイムを一から作る代わりに Codex を出発点にして、それを組み込むアプリケーションに何を担わせるかを決められます。

開発者が調査・調整できるオープンなハーネス

ハーネスはオープンソースなので、アプリケーションとモデルの間にあるレイヤーを調べ、その動作を理解し、製品に合うように統合方法を調整できます。

そのため開発者は、エージェントを自分たちの製品に合わせるうえで重要な、次の要素を制御できます。

  • インターフェース。すべてのやり取りを汎用的なチャットウィンドウに集約する必要はありません。チームは既存のダッシュボード、エディター、キュー、マップ、レコード、承認フローを使い続けられます。

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

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

私たちは、Codex CLIapp-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

私たちは Codex app-server を使い、業務アプリケーションのサンプルとして Relay を構築しました。架空の貨物配送ダッシュボードの横にエージェントを配置し、アプリケーション側で管理する MCP ツールに接続しています。配送を再予約する前には、人間の承認が必要です。

ユーザーは、プロンプトを一から書く必要はありません。貨物を選び、 リカバリー案を比較などのアクションをクリックします。アプリケーションが関連するコンテキストを提供し、Codex が最新のサンプル業務データを取得し、エージェントが利用可能な選択肢を説明します。重大な影響を伴う書き込みには、必ず承認が必要です。

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

Relay では事前に用意した架空のデータを使っていますが、この統合パターンは汎用的です。インシデント対応、アカウント運用、リサーチのワークフローなど、既存の製品体験の中でエージェントを動かすアプリケーションにも応用できます。

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

図 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 が適しています。