OpenAI、Codex の中核フレームワーク Agent Harness をオープンソース化：Agent を自社の業務システムに簡単に組み込める

なぜモデルだけでは、本物のエージェントにならないのか

通常の大規模言語モデルの呼び出しはシンプルです。質問を入力し、回答を待つだけです。しかし、タスクが「答える」から「完了させる」に変わると、欠けている部分がすぐに明らかになります。

モデルは、自分がどのオブジェクトを処理しているかを把握し、これまでに行ったことを記憶し、ファイルやログ、業務記録を読み取り、外部ツールを呼び出し、失敗したら別の方法を試し、自動実行できるアクションと、人間の承認を必要とするアクションを区別できなければなりません。タスクが数十分以上に及ぶ場合や、複数回のやり取りにわたる場合、古いコンテキストを圧縮しつつ、初期の重要な判断を忘れないようにする必要もあります。

Agent Harness は、進捗の記憶、ツールのスケジューリング、権限の制限、タスクの遂行を担当する実行システムです。

Harness が重要な理由として、最も直接的な問いはこれです。同じモデルでも、実行方法が変わると結果はどれだけ変わるのか。OpenAI は、非常に重みがありながらも、誤用されやすい数字を示しました。

ARC-AGI-3 という公開タスクセットでは、エージェントは未知のインタラクティブな環境で継続的に観察し、試行錯誤しながらルールを見つけ出す必要があるため、これまでの判断や行動履歴を保持できるかどうかが特に重要です。GPT-5.6 Sol が ARC-AGI-3 公式の汎用 Harness を使用した場合、RHAE（相対人間行動効率）は 13.3% でした。一方、これまでに形成された reasoning（推論状態）を保持し、compaction（古いコンテキストを引き続き使用可能なサマリーに圧縮すること）を用いて単純に最も古いコンテンツを破棄する方式を採用したところ、RHAE は 38.3% に上昇し、出力トークン数は約6分の1に削減されました。

背後にあるメカニズムはそれほど神秘的ではありません。reasoning を破棄すると、エージェントは実行のたびにゲームを再理解することになります。また、古いものから順に切り捨てる方式では、より初期の観察やアクションが徐々に消えていきます。推論を保持することで計画を継続でき、コンテキストを圧縮することで、エージェントは長時間のタスクでも単に古い内容を忘れるのではなく、重要な認識を維持できます。

ただし、この結果は特定のモデル、特定の公開タスクセット、特定の評価指標に限ったものです。「Codex を接続すればすべてのエージェントが3倍向上する」と一般化することはできません。この結果が示すのは、モデルを取り巻く実行アーキテクチャも、モデルが最終的に発揮できる能力に影響を与えるということです。

13.3%→38.3% の完全な実験については、別途解説記事をご用意しています：

関連記事API設定2つでGPT-5.6 SolのARC-AGI-3が13.3％→38.3％　OpenAI自報モデルは据え置き。変えたのはハーネス——プライベート推論の保持と、削除に代わるコンパクション（文脈圧縮）で、1ゲームあたりの出力トークンは約6分の1に。→

業務システムに組み込んだ場合、3つの層はそれぞれ何を担当するのか

Harness が「就業システム」であると分かれば、次の実用的な疑問が浮かびます。Codex をプロダクトに組み込んだとき、ホストアプリケーション、Codex app-server、MCP はそれぞれ何を担当するのでしょうか。

このアーキテクチャは、責任を明確に3つの層に分け、それぞれが役割を担います。

3層は上下関係ではなく、3つの所有権です

業務はアプリに残し、エージェントループはCodexに、信頼できる読み書きはMCPに

ホストアプリ 業務の現場と最終的な制御を持つ

現在のオブジェクト · ページ状態 · 業務ルール · 人による承認

↓ オブジェクト、コンテキスト、制約 ↑ 進捗、イベント、承認リクエスト

Codex app-server エージェントの実行ライフサイクルを維持

スレッドとターン · 推論ループ · サンドボックス · ストリーミングイベント

↓ ツール呼び出し ↑ 信頼できる結果

アプリ独自のMCP 専有システムを制御可能なツールにする

信頼できるデータ · クエリツール · 業務アクション · 権限境界

承認後に実行し、書き戻す

公開元のオリジナルアーキテクチャ図

第1層はホストアプリケーション、つまり既存の物流管理システム、チケットシステム、税務申告ソフトウェアなどです。ユーザーがどのアラート、どのチケット、どの注文を選択したか、現在のページに表示されているステータスは何か、業務上どのような操作が許可されているか、どのステップで人間の同意が必要かは、すべてこの層が定義します。

第2層は Codex app-server です。この層は、これらのコンテキストを受け取り、タスクの進捗を保存し、エージェントが継続的にツールを呼び出すことを推進し、実行をサンドボックスと承認ルール内に制限します。プロダクト側もプロセスを確認し、いつでも中断し、承認リクエストに応答できます。

第3層は、アプリケーション独自の MCP サービスです。これは、エージェント専用の業務インターフェース群と考えることができます。MCP は業務データベースそのものではありません。エージェントはこれを介して信頼できる記録を読み取ったり、再予約、チケット作成、ステータス更新などの業務アクションをリクエストしたりできます。アクションが実際に実行されるのは、ホストアプリケーションのルールと承認条件を満たした場合のみです。

完了後の変更は、元のプロダクトのインターフェースに反映されます。エージェントの結論は正式な業務システムに入力され、元のシステムが最終的な記録とコントロールセンターとして機能し続けます。

この役割分担により、エージェントプロダクトで混同されがちな3つの点が整理されます：

• Codex はタスクを遂行する責任を持ちます。
• MCP は信頼できるデータと制御されたアクションを Codex に提供します。
• ホストアプリケーションは、両者に何が重要で、何が許可され、最終結果がどこに記録されるべきかを伝えます。

単発タスクからプロダクト機能まで、3つの接続方法の選び方

ほとんどのタスクに app-server は必要ありません。3つの接続方法は、まず一文で覚えられます。スクリプトやバックグラウンドタスクには codex exec、業務コードからの呼び出しには SDK、エージェントをプロダクト機能にするなら app-server です。

codex exec は、境界が明確な単発タスクに適しています。例えば、自動チェックプロセスでのコードレビュー、定期的な記録整理、バックグラウンドでの一連の入力の一括処理などです。最終テキストを返すことも、プログラムが処理を継続できるイベントや構造化された結果を出力することもできます。タスクの開始、実行、終了というライフサイクルは比較的シンプルです。

Codex SDK は、業務コードから直接 Codex タスクを開始・管理する場合に適しています。アプリケーションは新しいタスクを開始したり、過去の作業を継続・再開したりできます。プロダクトチームは app-server の基盤プロトコルを自分たちで処理する必要はありません。

Codex app-server は、エージェントを直接プロダクト機能にする場合に適しています。アプリケーションはタスクを長期間保持し、実行プロセスを確認し、いつでも中断し、一時的なツールを提供し、Codex からのリクエストに応じて承認を処理できます。

これら3つの方法を「低スペック、中スペック、高スペック」と理解してはいけません。選択する際は、次の3つの問いだけを考えます。タスクが継続的な状態を必要とするか、プロダクトが実行プロセスを観察・介入する必要があるか、エージェントがユーザーの現在のインターフェース内で結果を伴う業務アクションを完了する必要があるか、です。

単発のバックグラウンド分析だけなら、app-server を直接導入するのは統合コストが増えるだけです。逆に、エージェントが運営管理画面に長期間存在する必要があるなら、codex exec コマンド1つでは、セッション管理、承認、インターフェース同期を担うのは難しいでしょう。

どの層を選ぶかは、単なる実装の問題です。より大きなプロダクト上の問いは、これらの機能を最終的にどのようなインターフェースに組み込むかです。その答えは、必ずしも新しいチャットボックスを追加することではありません。

エージェントを組み込むことは、チャットボックスを追加することと同じではない

プロダクトチームが次に決めるべきは、AI をどこに配置するかです。OpenAI の答えは、エージェントを作業が本来行われる場所に置くことであり、すべてのソフトウェアに一律でチャットボックスを追加することではありません。

業務システムから切り離され、現在のコンテキストを取得できない汎用チャットボックスは、現場の整理という面倒な作業をすべてユーザーに押し付けます。処理中の注文、ページの状態、業務ルール、操作の目的を、すべてプロンプトとして再度入力しなければならないからです。

ユーザーは自分が見ているレコードを改めて説明し、ダッシュボードのステータスをモデルにコピーし、モデルの提案が最新データに基づいているかどうかを判断する必要があります。モデルが解決策を提示した後も、ユーザーは業務システムに戻って実行しなければなりません。コンテキスト、分析、アクションが2つの場所に分断され、重要な境界線もコピー＆ペーストの過程で失われがちです。

同じ作業を並べて比較すると、違いはモデルが回答できるかどうかではなく、コンテキストを誰が整理するか、業務上の境界線をどこから得るか、そして結果が最終的にどこに記録されるかです。

そのため、ダッシュボード、チケットページ、税務申告フォーム、セキュリティインシデントキューは、AI が登場しても価値を失いません。これらの画面には、作業に必要なオブジェクト、ステータス、証拠、ボタンがすでに揃っています。エージェントのより合理的な位置づけは、これらのインターフェースに入り込み、既存のコンテキストを直接活用することで、ユーザーが空白の入力ボックスから状況を再説明する手間を省くことです。

もちろん、チャットがなくなるわけではありません。自由な探索、曖昧な質問、一時的な分析には、依然として対話が適しています。やめるべきなのは、汎用チャットボックスをすべてのエージェントプロダクトの唯一の形態と考えることです。

Relay デモ：AI が物流管理システムでどのように作業を完了するか

Relay は架空のシードデータを使用しており、実際の顧客システムではありません。前述した3層の役割分担と接続方法を、一連の完全な物流操作として具体化しています。

空白の入力ボックスではなく、業務オブジェクトから始まる

読み取り、判断、申請、実行、書き戻し、すべてが元のワークフロー内で行われる

01異常貨物を選択

ディスパッチャーが実際の作業対象を選択します。

→

02ページのコンテキストを注入

ルート、約束時間、貨物価値、異常がタスクに入ります。

→

03MCPで現在の記録を読み取る

Codexが信頼できる運用状態を取得します。

→

04調査して選択肢を比較

分析は自動で進められます。

↘

人間による制御ポイント05重要な書き込み操作には人の承認

再予約、記録変更、費用発生時には一旦停止します。

→

06承認されたアクションを実行

明確に許可された変更のみを実行します。

→

07書き戻して業務状態を更新

結果がシステム記録とUIに反映されます。

Relay公式デモ画面

管理者は「物流の遅延を分析して」とゼロから入力するわけではありません。まず異常キューから貨物を1件選択し、次に「遅延を調査」または「是正策を比較」をクリックします。このクリックだけで、業務オブジェクトとユーザーの意図が伝達され、ページはルート、約束時間、貨物価値、現在の異常などの可視的なコンテキストを提供し続けます。

続いて Codex は、Relay の MCP ツールを介して現在の運営記録を読み取り、問題がどこで発生しているかを判断し、利用可能な対策を比較します。分析は自動で進められますが、次のステップが再予約、業務記録の変更、費用の発生などであれば、システムは一旦停止して管理者の承認を求めます。アクションが承認され実行されると、変更は物流記録に反映され、業務ビューが更新されます。

この一連の流れは、次の7つのステップに要約できます：

オブジェクトを選択 → コンテキストを注入 → 信頼できるデータを照会 → 調査と比較 → 人間の承認 → 業務アクションを実行 → 正式な記録を更新

「チャットボックスにツールをいくつか接続する」こととの違いは、まさにプロダクトデザインにあります。いつ自動的にコンテキストを提供するか、どのツールを利用可能にするか、どのアクションに結果が伴うか、そして人間がどこで決定を引き継ぐべきか、ということです。

同様のパターンは、すでにさまざまな分野に浸透しています。GitHub と JetBrains は Codex を既存の IDE ワークフローに統合し、Cisco は Cloud Control の App Builder で Codex SDK を使用しています。Thrive Holdings、Crete、OpenAI は、Codex を税務申告準備と実務者からのフィードバックループに組み込んでいます。

Thrive Holdings、Crete、OpenAI による税務申告準備のパイロット では、7,000件の税務申告書を処理し、協力先は準備時間を約3分の1短縮できたと報告しています。この数字は独立した第三者による評価ではありませんが、ワークフロー統合の第二の価値を示しています。エージェントは一度きりのタスクを完了するだけでなく、本番記録を読み取り、専門家による修正を吸収し、評価タスクを形成し、次の製品改善を推進できるのです。

最後に明確に：何がオープンソース化され、何がされていないのか

もう一つ、誤解されやすい境界線があります。Harness をプロダクトに組み込めることと、Codex 全体を自由にセルフホストできることはイコールではありません。公式に公開された範囲は、それほど広くありません。

開発者が手にするのは、閲覧・変更・プロダクトへの組み込みが可能な Agent 実行基盤と、単発タスクから深いプロダクト統合までをカバーする複数の入り口です。その一方で、モデルやクラウドサービスのオープンソース実装は提供されません。

さらに重要なのは、Harness がビジネス領域を自動で作り出すわけではないという点です。どのレコードが信頼できるデータか、どのツールを呼び出せるか、どの操作に承認が必要か、そして結果をどうシステムに書き戻すか。これらの定義は、引き続きホスト側のアプリケーションが行う必要があります。

つまり OpenAI は、開発者が Agent 実行基盤 を構築する際の大きな手間を省いてくれるのです。しかし、ビジネスプロダクトそのものは、チーム自身が作り上げる必要があります。その成否は、ビジネスへの理解と、データ・ツール・権限・人の判断を信頼性の高いフローとして統合し、AI が既存システム内で実際に作業を完了させられるかどうかにかかっています。

関連資料：Harness エンジニアリングの 12 の実践原則。

関連記事ハーネスエンジニアリング12の心得：Google 首席工程师の1年間の実践を凝縮した、すぐ使えるプロセスとテンプレート中核となる操作は直感に反するもの。選択したモデルとエージェントは固定し、パラメータは一切調整せず、その周囲のコンテキストとツールだけを変更するのです。→