GPT-5.6とChatGPT Work：本番環境に対応したエージェント制御プレーンの設計

はじめに

2026年7月にリリースされたGPT-5.6は、単なる新モデルの発表と見なされがちです。Solは最高性能路線、Terraはバランス型の選択肢、Lunaはより高速で低コストのグレードです。公式リリースには、コーディング、専門業務、科学、コンピュータ利用、セキュリティにわたる広範な評価が含まれています。

この解釈は正確ですが、不完全です。

GPT-5.6をより有用に理解する方法は、運用面にあります。OpenAIは、これまでエージェント開発者がカスタムオーケストレーションコード内に隠蔽せざるを得なかったいくつかの判断——推論にどの程度のリソースを割り当てるか、並列エージェントをいつ使用するか、すべての中間結果をモデルに返さずにツールを連携させる方法、タスクの価値とリスクに応じてモデルの性能をマッチさせる方法——を公開しました。

同時に、ChatGPT Workは、Codexに関連する長時間実行タスクモデルを、ドキュメント、スプレッドシート、スライド、ウェブサイト、接続アプリケーション、ブラウザ操作、コンピュータ利用、スケジュールされた作業を含む、より広範なワークスペースにもたらします。

これらの機能は、より大きなエンジニアリング上の責任を生み出します。より強力なモデルにより多くのツールを与えるだけでは、自動的に信頼性の高いデジタルワーカーは生まれません。より長く動作し、より広いデータ範囲にわたり、より重大な変更を加えることができるシステムが生まれるのです。

プロダクションデザインでは、実行開始前にいくつかの問いに答えなければなりません：

• 誰がタスクを承認したのか？
• エージェントは何を読み取ってよいのか？
• 何を変更してよいのか？
• どのアクションに承認が必要か？
• どれだけの時間と費用を費やしてよいのか？
• 結果が正しいことを証明するエビデンスは何か？
• 問題が発生した場合、チームはどのようにワークフローを停止または復旧するのか？

本書は、GPT-5.6、ChatGPT Work、Codex、またはカスタムエージェントを構築するチーム向けの制御プレーンアプローチを提示します。モデルの能力と運用上の権限を分離し、具体的なシナリオ、ルーティングルール、評価ガイダンス、再利用可能なポリシーテンプレートを提供します。

主要ポイント

• GPT-5.6は、能力とコンピューティングのメニューとして捉えるのが最善です。Sol、Terra、Lunaはモデルルートであり、推論努力とマルチエージェント実行は別の予算管理対象です。
• ChatGPT Workは、委任の単位を単一の回答から、ファイル、接続アプリ、ブラウザ作業、コンピュータ利用、スケジュールタスクにまたがる完了した成果物へと変えます。
• プロダクションエージェントには、モデルの周囲に制御プレーンが必要です：タスク分類、スコープ付きアイデンティティ、ツールポリシー、承認ゲート、可観測性、評価、予算、復旧。
• 公開ベンチマークは候補モデルの発見には有用ですが、プロダクション導入の判断にはプライベートなタスクセットが不可欠です。
• チームは、可逆的でレビュー可能なワークフローから始め、エビデンスを収集した後にのみ自律性を拡大すべきです。

GPT-5.6で実際に変わったこと

GPT-5.6は、ChatGPT、Codex、API全体で3つの能力階層を提供します：

• Sol： 最高能力ルート
• Terra： 日常業務向けバランスルート
• Luna： 最速かつ最も手頃なルート

OpenAIはこれらの名称を、一時的な日付付きモデル名ではなく、耐久性のある能力階層として説明しています。この区別はプロダクションシステムにとって有用です。

「定期的なリポジトリメンテナンスにはバランスティアを使用する」といった方針は、将来のスナップショット変更にも耐えられます。再現性が重要な場合、チームは正確なスナップショットを別途固定できます。これは、モデルIDをプロンプト、スクリプト、ジョブキュー、環境変数に散りばめるよりもクリーンです。

推論努力とマルチエージェント実行

GPT-5.6では、より明示的な計算制御も追加されています。

maxは、1つのモデルルートに、より多くの推論時間、代替案の探索、チェックの実行、作業の修正を可能にします。ultraは、複数のエージェントが並行して作業を行うワークストリームを調整します。

これらは異なる制御です：

• より多くの推論は、1つのルートがより長く調査・検証することを可能にします。
• マルチエージェント実行は、並行ワークストリームに追加の計算を費やし、その後結果を統合します。

タスクによっては、一方、両方、またはどちらも役に立たない場合があります。特にサブタスクが同じ不確実な前提を共有したり、同じ制限された資格情報を必要とする場合、並列実行が自動的に優れているとは限りません。

プログラムによるツール呼び出し

OpenAIは、プログラムによるツール呼び出しを、モデルがツールを調整し、中間結果を処理し、どの情報をモデルに返すべきかを決定する軽量プログラムを作成・実行する方法として説明しています。

これにより、繰り返されるコンテキスト転送を削減できます。すべてのデータベース行、ブラウザ応答、ツール結果をモデルに返す代わりに、インメモリプログラムが最初にデータをフィルタリングおよび集約できます。

この効率性には運用上のトレードオフが伴います。より多くのロジックが実行層に移行するため、チームはそれらの中間ステップに対して明確なトレース、制限、データ処理ルールを必要とします。

GPT-5.6リリースでは、Responses APIにマルチエージェントベータ版も導入されています。したがって、並列実行はアプリケーション側のオーケストレーションパターンだけでなく、APIレベルの機能になりつつあります。

価格設定はルーティングのインプット

リリース時点での公式価格は以下の通りです：

これらの価格はルーティング決定のインプットであり、決定そのものではありません。

より安価なモデルは、繰り返しリトライしたり、不必要なコンテキストを読み込んだり、レビュアーに拒否される成果物を生成したりする場合、承認された結果あたりのコストが高くなる可能性があります。より強力なモデルは、小さく検証済みの変更でタスクを一度で完了する場合、実際にはより安価になる可能性があります。

正しい指標は、単にトークンあたりのコストではありません。承認された成果あたりのコストです。

ChatGPT Workが委任の単位を変える

ChatGPT Workは、アプリケーションやファイルを横断して作業し、何時間も継続し、目標をより小さなステップに分解し、完成したアーティファクトを作成できるエージェントとして提示されています。

OpenAIはCodex技術が製品に組み込まれていると述べていますが、ターゲットはソフトウェアエンジニアリングよりも広範囲です。ワークフローの例としては以下が含まれます：

• 予算分析
• キャンペーンブリーフ
• リードレビュー
• 製品発売チェック
• 競合調査
• ドキュメント
• スプレッドシート
• プレゼンテーション
• ウェブサイト

重要な変更点は、委任の単位です。

通常のチャットターンは回答を求めます。Workタスクは成果を求めます。

その成果を得るために、システムは以下のことを行う必要があるかもしれません：

1. 複数の情報源を読む。
2. 新しい情報が入ったら方向転換する。

情報が表示されます。
3. 複数のアーティファクトを作成する。
4. 人間の承認を待つ。
5. ユーザーが離席中にスケジュールされたタスクを続行する。
6. 接続アプリ、組み込みブラウザ、またはデスクトップコンピュータを使用する。

OpenAIは製品の表面を統合しつつある。Chat、Work、Codexは更新されたデスクトップ体験内で利用可能となり、ブラウザ機能はより広範な製品環境に移行している。

これにより、ローカルファイル、ウェブページ、接続サービス、ブラウザ操作、長時間実行タスクにまたがる単一の権限境界が生まれる。

したがって、エンタープライズコントロールはインターフェースと同じくらい重要である。管理コネクタ管理、コンプライアンス機能、レビュー機構はすべて同じ問題を指し示している。すなわち、エージェントは適切なID、最小限のコンテキスト、可視的な効果、そして回復経路を持って動作しなければならない。

チームがChatGPT Workを直接使用せずにカスタムAPIエージェントを構築する場合でも、Workは有用な参照運用モデルとなる。アシスタントが永続的なワーカーとなったときに現れる問題を浮き彫りにする。

• 状態
• ツールのアイデンティティ
• 承認
• スケジューリング
• アーティファクト
• ガバナンス

理解すべき用語：モデル、ハーネス、エージェント、コントロールプレーン

モデル

モデルは入力コンテキストを出力およびツール決定にマッピングする。能力、制限、価格、レイテンシ、安全性の振る舞いを持つ。

Sol、Terra、Lunaはモデル階層である。モデル自体は組織の権限を決定しない。

エージェントハーネス

エージェントハーネスはモデルを取り巻くソフトウェアである。コンテキストを選択し、ツールを公開し、コマンドを実行し、状態を保存し、失敗を再試行し、実行完了を判断する。

モデルとタスクが同じでも、ハーネスを変更することでコストと信頼性が大きく変わり得る。中間結果をフィルタリングするハーネスよりも、大きなコンテキストウィンドウを繰り返し送信するハーネスの方がはるかにコストがかかる可能性がある。

このため、ハーネスも指定されない限り、「モデル性能」は不完全である。

エージェント

エージェントは以下を組み合わせる：

• モデル
• 目標
• ツール
• 状態
• ハーネス

エージェントは複数のステップを踏み、ツールの結果に反応できる。長時間実行エージェントはサブタスクやサブエージェントを作成する場合があるが、並行ワーカーが自動的に安全なマルチエージェントシステムを形成するわけではない。それらは依然として予算、権限、最終承認判断を共有する。

コントロールプレーン

コントロールプレーンはエージェント実行を管理するポリシーと運用の層である。

以下を行う：

• タスクを分類する
• ルートを選択する
• スコープ付きの認証情報を発行する
• 承認を強制する
• トレースを記録する
• 結果を評価する
• 作業を停止する
• 作業をロールバックする

実行プレーンはタスクを実行する。この二つを分離することで、チームは本番コードのデプロイや外部メッセージの送信を許可されている人を変更することなく、モデルを変更できる。

承認ゲート

承認ゲートは、権限のある人物または決定論的ポリシーなしではエージェントが通過できない判断ポイントである。

承認は特定のアクションとその証拠に結び付けられるべきである。

有用な承認リクエストは以下の通り：

この最終確定メールを、添付の受信者リストと承認済みコンテンツを使用して、これら412人の受信者に送信することを承認してください。

弱い承認リクエストは以下の通り：

マーケティングタスクを承認してください。

受け入れテスト

受け入れテストは、

要求された成果は完了しています。

以下のものが該当します。

• ユニットテスト
• スキーマ検証
• レンダリング文書のレビュー
• 照合合計
• 人間による評価ルーブリック
• セキュリティスキャン
• コード所有者による承認

モデルが「完了」と述べることは、ステータスの主張であり、受入テストではありません。

プロダクションエージェントコントロールプレーン

実用的なプロダクションコントロールプレーンには、8つの責任があります。

1. タスクの分類

分類は以下をカバーする必要があります。

• ドメイン
• 影響
• 可逆性
• データの機密性
• あいまいさ
• 期待値
• 検証の強度

「FAQの下書きを更新する」と「認証ポリシーを変更する」は、どちらもテキスト編集を含む可能性がありますが、異なるルートに属します。

2. モデルと労力予算の選択

最も安価な適格ルートが合理的なデフォルトですが、適格性は価格よりも優先されなければなりません。

例：

• 低リスクの抽出にはLuna
• 強力なソースチェックを伴う中程度の分析にはTerra
• アーキテクチャレビュー、セキュリティレビュー、または困難なリポジトリ診断にはSol
• タスクが明確に分解され、追加の並列コストが正当化される場合のみUltra

3. スコープ付き実行IDの作成

エージェントは、タスクに必要な正確なリポジトリ、フォルダ、アプリケーション、またはレコードに対する短期間の資格情報を受け取る必要があります。

単に便利だからといって、開発者の完全なブラウザセッションを継承すべきではありません。

実行IDはログに表示され、チームがすべての外部アクションを特定できるようにする必要があります。

4. ツールポリシーの適用

これらは個別の機能です。

• 読み取り
• 書き込み
• 送信
• 購入
• 削除
• デプロイ
• 権限の変更

メールボックスを検索できるコネクタが、自動的にメールを送信できるべきではありません。リポジトリを検査できるGitHub統合が、自動的にプルリクエストをマージできるべきではありません。

5. 承認と決定論的チェックの実施

承認ゲートは、結果を伴うアクションの直前に表示され、影響と証拠の簡潔なプレビューを示す必要があります。

ソフトウェアの場合、証拠には以下が含まれます。

• 差分
• ユニットテスト
• 型チェック
• セキュリティスキャン
• デプロイ計画

財務の場合、以下が含まれます。

• ソース合計
• 照合
• 数式検証
• 差異チェック

6. イベントトレースの記録

トレースには以下を含める必要があります。

• 目標の変更
• ソースの取得
• ツール呼び出し
• 承認
• 成果物
• エラー
• 再試行理由
• トークン使用量
• 経過時間
• 最終状態

短い要約は運用に役立ちますが、インシデントレビューには十分ではありません。

7. 予算と停止条件の実施

有用な制限には以下が含まれます。

• トークン予算
• ツール呼び出し予算
• 壁時計制限
• 再試行制限
• 金銭的上限
• ファイル数制限
• 差分サイズ制限

弱い実行やループ実行を停止することは、自律性の失敗ではありません。それはポリシーの成功した適用です。

8. リカバリの所有

リカバリには以下が含まれます。

• ファイルの復元
• コミットの取り消し
• 資格情報の失効
• スケジュールされたタスクのキャンセル
• 下書きの削除
• インシデントの起票

システムが実行前にリカバリを説明できない場合、そのタスクは無人運用の準備ができていません。

タスク形状によるSol、Terra、Lunaのルーティング

モデルルーティングは、エンジニア、プロダクトマネージャー、セキュリティレビュー担当者が読めるように明示的である必要があります。

以下の表は

出発点であり、普遍的なランキングではありません。

最後の列が最も重要です。

モデルの能力によって権限が増加してはいけません。

LunaからSolに切り替えた際に、書き込みアクセスが黙って追加されてはいけません。推論の労力を上げても、下書きが承認済みの外部メッセージに変わってはいけません。Ultraが、すべて無制限の本番環境用クレデンシャルを共有する複数のワーカーを作成してはいけません。

エビデンス駆動型エスカレーション

Lunaルートは以下の場合にエスカレーションされる可能性があります：

• 信頼度が閾値を下回った場合。
• 必須フィールドを抽出できない場合。
• ソースが矛盾している場合。
• 検証に失敗した場合。

Terraのコーディングタスクは以下の場合にエスカレーションされる可能性があります：

• 2回の範囲内の試行後も、失敗したテストの説明がつかない場合。
• 変更がセキュリティ境界を越える場合。
• 差分が予想ファイル数を超える場合。

Solルートは、要件が競合する場合、または残された唯一のアクションが不可逆的である場合に、停止して人間に問い合わせる必要があります。

ダウングレードも有用

Solが計画を策定すると、TerraまたはLunaが、狭いチェックの下で反復的なサブタスクを実行できます。

強力なモデルは、すべての項目を処理するのではなく、サンプルをレビューできます。これにより、判断と量が分離され、コストを大幅に削減できる可能性があります。

権限アーキテクチャと承認境界

権限システムは動詞から始めるべきです。

read（読み取り）
search（検索）
create_draft（下書き作成）
modify（修正）
send（送信）
merge（マージ）
deploy（デプロイ）
delete（削除）
purchase（購入）
grant_access（アクセス権付与）

これらの動詞は異なる結果をもたらします。

多くのプロダクト統合では、複数のアクションを1つの広範なOAuthスコープの背後に配置しています。したがって、コントロールプレーンは、より狭い操作を公開するアプリケーション側のプロキシを必要とする場合があります。

動詞をリソースにバインドする

「Google ドライブを読み取る」は、多くのワークフローにとって広すぎます。

より狭いルールは次のようになる可能性があります：

UTC 18:00まで、第3四半期の計画フォルダと承認済みブランドテンプレートフォルダを読み取る。

リポジトリの場合、アクセスはネットワークアクセスが無効になった1つのワークツリーに制限される場合があります。データベースの場合、読み取りレプリカまたは管理されたビューが通常、本番環境のクレデンシャルよりも安全です。

条件を追加する

例：

• メールの下書きは自動的に作成できますが、送信には承認が必要です。
• プルリクエストは自動的に作成できますが、マージにはグリーンCIとコードオーナーが必要です。
• スケジュールされたタスクはダッシュボードを更新できますが、

データソースの変更は管理者権限が必要です。

職務分掌の維持

変更を作成するエージェントが、その正確性を判断する唯一の存在であってはなりません。

有用な証拠は以下から得られます：

• 決定論的テストランナー
• 独立したレビューモデル
• 人間の責任者

第二のモデルは責任ある人間の代わりにはなりませんが、アクションが外部に発信される前に不一致を明らかにすることがあります。

プロバイダーによる保護は一層に過ぎません。特定のリポジトリをテストする権限がユーザーにあるか、変更を顧客が承認したか、本番メンテナンスウィンドウが開いているかどうかは認識できません。

アプリケーションの認可はビルダーの責任です。

具体的なシナリオと障害モード

シナリオ1: リリース準備エージェント

チームはChatGPT Workやカスタムエージェントに以下を依頼します：

• ローンチ計画
• Jira課題
• リポジトリ
• 市場投入ドキュメント

必要な成果物は、責任者と障害事項をリストアップした準備状況レポートです。

エージェントは4つの情報源をすべて読み、レポートを作成できます。承認なしに課題ステータスを編集したり、関係者にメッセージを送信したりすることはできません。

障害モード：古いコンテキスト

エージェントがキャッシュされたドキュメントを使用したため、レポートに既に解決済みの課題が記載されます。

制御プレーンは、直接情報源へのリンクとタイムスタンプを必須とする必要があります。

障害モード：誤った完了

チェックリストのすべての行にテキストが入力されているため、エージェントはリリース準備完了と宣言します。

代わりに、受け入れテストでは、すべてのブロック依存関係に確認済みの責任者、日付、現在のステータスがあることを必須とする必要があります。

シナリオ2: コードエージェント依存関係アップグレード

タスクはモノレポ全体でライブラリをアップグレードすることです。

マイグレーションが文書化され、テストスイートが強力であるため、Terraが開始します。ブランチを作成し、ロックファイルと影響を受けるパッケージを編集し、対象を絞ったチェックを実行します。

コンパイラエラーにより、認証モジュールで文書化されていないAPI変更が明らかになります。これにより、Solへのエスカレーションが発生します。

モデルは変わりますが、権限は変わりません。

Solは同じワークツリーを受け取り、デプロイメントトークンは付与されません。差分が認可ロジックに影響を与える場合、ポリシーはセキュリティレビューゲートを追加します。

完了には以下が必要です：

• 単体テスト
• 型チェック
• 依存関係監査
• レビューア承認済みのマイグレーションノート

動作するように見えてもこれらのチェックをスキップするパッチは受け入れられません。

シナリオ3: スケジュールされた顧客フィードバックワークフロー

毎朝、エージェントが新しいサポートチケットを読み、テーマをクラスタリングし、プロダクト概要を更新します。

Lunaは、機密フィールドが削除された後にチケットを分類できます。Terraはソースリンク付きの概要をドラフトできます。

どちらのルートも以下を行うことはできません：

• チケットをクローズする
• 機能を約束する
• 顧客に連絡する

障害モード：スコープの段階的拡大

エージェントが「明らかな応答も処理する」という新しい指示が追加されます。

これにより、内部分析ワークフローが外部コミュニケーションに変わります。

タスク分類子は、新しい「送信」動詞を検出し、別個のポリシー、承認されたテンプレート、サンプリング計画、人間の責任者を必須とする必要があります。

シナリオ4: 高価値調査タスク

ある企業が3つのアーキテクチャオプションを評価しています。

Sol ultra は以下に個別のワークストリームを割り当てます：

• パフォーマンス
• セキュリティ
• 移行コスト
• ベンダーリスク

ワークストリームが独立しているため、並列実行は正当化されます。

独立しており、その判断には価値があります。各ワーカーはソース要件と固定予算を受け取ります。

障害モード：相関する証拠

すべてのワーカーが同じベンダーのベンチマークを引用し、意見が一致しているように見えます。

統合ゲートは、ソースの多様性を測定し、共有された根拠のない前提をフラグし、各オプションに対して少なくとも1つの反論を要求する必要があります。

エージェントが増えれば、カバレッジを向上させるのと同じくらい簡単に、誤った前提を増幅させることができます。

公開コーディングベンチマークが発見ツールである理由

公開ベンチマークは有用ですが、プロダクションのデフォルトを直接決定すべきではありません。

OpenAIによるSWE-Bench Proの監査では、公開タスクのかなりの割合に次のような問題があることが報告されました。

• 過度に厳格なテスト
• 仕様が不十分なプロンプト
• カバレッジの低いテスト
• 隠しテストと矛盾する動作を誘導するプロンプト

これは、すべての公開ベンチマークが無意味であることを意味するわけではありません。

スコアがそのデータセットとハーネスの測定誤差を継承することを意味します。

公開評価は以下のために有用です。

• 候補モデルの発見
• 公開された手法の比較
• 広範な能力の変化の特定
• 内部評価キューの構築

公開評価だけでは、モデルが特定のモノレポ、ビジネスワークフロー、データ環境において安全な変更を加えるかどうかを判断することはできません。

コントロールプレーンは、各ルーティング判断とともにベンチマークの来歴を保存する必要があります。

• データセットのバージョン
• タスクの除外
• ハーネス
• ツール設定
• 推論努力
• 試行回数
• コストの前提

これらの詳細がなければ、ベンチマックスコアはマーケティングの決まり文句になります。

実務からプライベート評価を構築する

Databricksは、数百万行のコードベース評価で有用な例を示しています。

同チームは、以下の言語で実際の人間が作成したプルリクエストからタスクを構築しました。

• Python
• Go
• TypeScript
• Scala
• Rust
• Java
• Protobuf
• gRPC
• Bazel

意味のあるテストを含む最近の代表的な変更を選択し、解決策を明かさずに意図を保持するようにタスクの説明を書き直し、各サンプルを手動でレビューしました。

また、チームは初期設定で情報漏洩を発見しました。エージェントがGit履歴から将来のコミットを復元できたのです。評価実行中は、ワークツリーがリポジトリの履歴から分離されていました。

この詳細は、最終的なランキングよりも重要です。ベンチマークがエンジニアリング能力ではなく、ショートカットの発見を誤って測定する可能性を示しています。

より小規模な内部セットの構築

チームは30～60のタスクから始めることができます。

以下の特徴を持つ、承認された過去の変更を使用します。

• 明確な課題
• 意味のあるテスト
• 限定された範囲

以下の組み合わせを含めます。

• 定期的なメンテナンス
• バグ診断
• ファイル間のリファクタリング
• フロントエンド作業
• 設定
• 1～2のセキュリティに敏感な例

変更前のリポジトリ状態を保存し、最終的なパッチを隠します。

まず決定論的な証拠で評価する

人間またはモデルによる判断の前に、決定論的なテストを使用します。

その後、以下のために人間によるレビューを追加します。

• 要求の忠実性
• 差分の品質
• 保守性
• 不要な変更

LLMジャッジがあらゆる正確性チェックを代替することを許してはいけません。ジャッジモデルは、正しく聞こえる回答を優先する可能性があります。

モデルとハーネスを一緒に測定する

以下を記録します。

• 成功率
• 総コスト
• 経過時間
• 送信された総コンテキスト量
• ツール呼び出し
• リトライ回数

以下のファイルに影響がありました。

• レビュアー修正
• ロールバック率

最も優れた経路とは、チームの制約の中で承認された成果を生み出す経路であり、単に公開スコアが最も高い経路ではありません。

再利用可能なエージェントポリシーテンプレート

以下のYAMLはポリシーアーティファクトであり、APIスキーマではありません。実際の環境に合わせて、IDプロバイダー、ジョブキュー、コネクタ、リポジトリ制御、監査システムに適応させてください。

policy_version: 1
workflow: release_readiness
owner: product-operations

classification:
  impact: medium
  reversibility: high
  data_sensitivity: internal
  ambiguity: medium
  verification: strong

routing:
  default:
    model_tier: terra
    reasoning_effort: medium
  escalate_to_sol_when:
    - conflicting_sources
    - unresolved_blocker_after_2_attempts
    - security_boundary_detected
  ultra:
    allowed: false

budget:
  max_wall_minutes: 45
  max_tool_calls: 120
  max_retries_per_step: 2
  max_estimated_usd: 12

access:
  jira:
    verbs: [read]
    projects: [NX]
  github:
    verbs: [read]
    repositories: [We0 AI/product]
  drive:
    verbs: [read, create_draft]
    folders: [launch-plans]
  external_send: deny
  deploy: deny
  grant_access: deny

approvals:
  - action: publish_report
    role: product-director
    evidence:
      - source_links_present
      - blockers_have_owner_and_date
      - unresolved_conflicts_listed

acceptance:
  required_checks:
    - schema_valid
    - all_sources_fresh_within_24h
    - no_unattributed_claims
    - human_approval_recorded

recovery:
  on_budget_exceeded: stop_and_notify
  on_tool_error_repeat: stop_and_attach_trace
  on_policy_violation: revoke_credentials_and_open_incident

このテンプレートには、いくつかの意図的な選択が反映されています。

• エスカレーションは権限を変更するのではなく、能力を変更します。
• Ultraは、ワークフロー所有者が明示的に有効にしない限り、無効のままです。
• 外部送信とデプロイは、個別に拒否されます。
• 承認はモデルの信頼度ではなく、チェックとして表現されます。
• リカバリは実行前に定義されます。

コーディングワークフローの場合は、レポートチェックを以下に置き換えてください。

• 対象テスト
• 型チェック
• Lint
• セキュリティスキャン
• 差分サイズ制限
• コードオーナーレビュー

スプレッドシートワークフローの場合は、以下を必須とします。

• 数式の検証
• ソースの整合性確認
• レンダリング結果の検査

エビデンスが変わっても、コントロールプレーンの構造は安定したままです。

観測可能性、予算、およびリカバリ

長時間実行されるエージェントは、新たな観測可能性の問題を引き起こします。

従来のリクエストログには、1回のAPI呼び出しのみが表示される場合があります。エージェントのトレースには、数百もの決定、ツール呼び出し、リトライ、中間アーティファクトが含まれる可能性があります。

チームには両方が必要です。

1. 調査のための完全なトレース。
2. 運用のための簡潔な実行台帳。

実行台帳のフィールド

有用な台帳には以下が含まれます。

• 安定した実行ID
• 開始ユーザー
• ポリシーバージョン
• 目標
• モデル階層とスナップショット
• 推論の努力量
• サブエージェント数
• ツールスコープ
• 承認
• コスト
• 経過時間
• 承認チェック
• 最終アーティファクトリンク
• 最終状態
• エスカレーション理由

これにより、以下のような質問に答えることが可能になります。

• Terraが失敗した後、Solは承認率を改善しましたか？
• どのワークフローが最も多くのレビューア時間を消費していますか？
• どのツールが最も多くのリトライを引き起こしていますか？
• どの経路が最も高いロールバック率を生み出していますか？

多次元予算

金銭的な制限だけでは、安価なモデルが長時間ループし続ける可能性がある。

時間制限だけでは、高価な並列処理が突発的に発生する可能性がある。

有用な予算の軸には以下が含まれる：

• 金額
• 実時間
• トークン使用量
• ツール呼び出し
• リトライ回数
• ファイル数
• 差分サイズ
• サブエージェント数

リカバリのテスト

リカバリは他の機能と同様にテストされるべきである。

有用なテストには以下が含まれる：

1. 実行中にコネクタを切断する。
2. リトライ後にエージェントが外部アクションを繰り返さないことを確認する。
3. 認証情報を期限切れにし、トレースが障害を説明していることを確認する。
4. スケジュールされたタスクをキャンセルし、将来の実行が停止することを確認する。
5. 生成されたコミットを元に戻し、関連する成果物を「差し替え済み」とマークする。

インシデントレビューでは、以下を区別すべきである：

• モデルの障害
• フレームワークの障害
• ポリシーの障害
• ツールの障害
• 人間の承認の障害

「AIのせい」にするだけでは、実際に改善できるコンポーネントが見えなくなる。

導入プレイブックとレビューチェックリスト

頻繁で、測定可能で、元に戻せる1つのワークフローから始めること。

適切な候補には以下が含まれる：

• リリース準備レポート
• 課題トリアージ
• ドキュメント更新
• テスト失敗サマリー
• 社内調査概要

最初のデプロイでは、以下を避けること：

• 外部コミュニケーション
• 本番環境への変更
• 決済
• アクセス権の付与
• 削除ワークフロー

人間のベースラインを記録する

以下を測定すること：

• ワークフローにかかる時間
• 使用される情報源
• 発生するエラー
• レビューアが期待するエビデンス

ベースラインがないと、エージェントの高速な出力によって、単に修正作業が増える可能性がある。

シャドウモードで実行する

人間が実際のワークフローを独立して完了する間、エージェントに成果物を生成させる。

結果を比較し、障害モードにラベルを付ける。これらの実行結果を使って、権限を拡大する前にプライベート評価を構築する。

レビューチェックリスト

ドラフト専用アクセスから限定書き込みアクセスに移行する前に、以下を確認すること：

• タスクの定義は、採点可能なほど具体的か？
• モデル階層と推論努力はポリシーに基づいて選択されているか？
• 権限を拡大せずにエスカレーションが可能か？
• すべてのツールに明示的な動詞とリソーススコープが設定されているか？
• 認証情報は有効期限が短く、実行に紐づけられているか？
• すべての不可逆的または外部から見えるアクションにゲートが設定されているか？
• 受理チェックはモデルの完了申告から独立して行われているか？
• トレースには、情報源、アクション、承認、エラー、コストが含まれているか？
• 予算は金額、時間、リトライ、ツール、ブラスト半径をカバーしているか？
• 認証情報の無効化、キャンセル、ロールバックがテストされているか？
• プライベート評価には、一般的かつリスクの高いエッジケースが含まれているか？
• ワークフローの成果に責任を持つ指名された人間のオーナーがいるか？

一度に1つの軸だけを拡大すること。

チームは、ドラフト専用出力を維持したまま新しいデータソースを追加したり、同じモデルとタスクを維持したまま限定書き込みアクセスを追加したりできる。

モデル、ツール、権限、スケジュールを同時に変更すると、後退の原因を特定することが難しくなる。

今、ビルダーがすべきこと

GPT-5.6とChatGPT Workは、エージェントインフラが独自のプロダクトカテゴリになりつつある証拠である。

モデル層は変化し続ける。永続的な価値を持つのは、以下のような制御プレーンである。

該当するモデルの変更は安全です。

ルートレジストリの作成

Sol、Terra、Luna、およびOpenAI以外の候補モデル向けに、小規模なレジストリを作成します。

以下を保存します：

• 適用条件
• データポリシー
• 許容される労力の範囲
• コストの前提条件
• 既知の障害モード

プライベートな評価キューを追加し、新しいモデルがソーシャルメディアの印象のみに基づいて本番環境のデフォルトにならないようにします。

認証プロキシの追加

エージェントと重要なツールの間に認証プロキシを配置します。

以下を公開します：

• 限定された動詞
• 短期間有効な認証情報
• 承認フック
• 冪等性キー

タスクがChatGPT Work、Codex、カスタムアプリケーション、またはスケジュールされたバックエンドジョブのいずれで開始された場合でも、同じ境界を維持します。

自律性の前に受入基準を定義

タスクの検証方法を説明できるチームは、それを段階的に安全に自動化できます。
検証を定義できないチームは、ベンチマークスコアに関係なく、エージェントを数時間稼働させる準備ができていません。

結果レベルでのコストの確認

以下の単位ごとに、ドルと人時間を追跡します：

• 受け入れられた成果物
• マージされた変更
• 解決されたチケット
• 承認された分析

これにより、モデルルーティング、ハーネスの効率、レビューアの作業負荷が調整されます。
また、次世代のフラッグシップモデルが登場した際に、チームは根拠のある回答を得ることができます。

境界と未解決の質問

リリース資料に記載されているいくつかの主張は、ベンダー報告に基づいています。
クロスプロバイダーのベンチマーク比較では、以下が異なります：

• ハーネス
• 推論設定
• 価格前提
• ツール設定
• データセット

これらの主張は、内部テストのための仮説として扱います。

プログラムによるツール呼び出しとマルチエージェント実行は、コンテキストのオーバーヘッドを削減する可能性がありますが、トレースが弱い場合には中間ロジックの可視性が低下する可能性もあります。
規制対象のワークフローでこれらの機能を使用する前に、以下を確認します：

• APIが記録する内容
• アプリケーションログが保持する内容
• 機密性の高い中間データの処理方法
• ワークフローが必要な保持ポリシーと互換性があるかどうか

ChatGPT Workの接続アプリケーションとコンピューター使用機能は、有用性を高める一方で、権限範囲を拡大します。
可用性、管理制御、コネクタの権限は、プランやデプロイメントによって異なる場合があります。

プロダクトの発表は、ワークスペース固有のセキュリティレビューの代わりにはなりません。

また、人間とシステム間の問題もあります。エージェントが長時間稼働する場合、ユーザーは十分に観察していない作業を承認する可能性があります。
より良い要約は役立ちますが、承認の質は、決定時点で提案された効果、不確実性、失敗したチェックを示すかどうかに依存します。

プロダクトデザインは、人間の注意を保護しなければならず、単なるクリックを要求するものではありません。

したがって、最強のモデルが最終的なアーキテクチャというわけではありません。
本番品質は、以下の関係から生まれます：

• モデル
• ハーネス
• ポリシー
• ツール
• 証拠
• 責任を持つ所有者

この関係こそが、エージェントコントロールプレーンが明確にするものです。

FAQ

GPT-5.6とは何ですか？

GPT-5.6は、OpenAIの2026年7月のモデルファミリーであり、Sol、Terra、Lunaの能力階層に編成されています。Solは最高能力のルート、Terraは能力とコストのバランス、Lunaは速度と手頃さを優先します。

ChatGPT Workとは何ですか？

ChatGPT Workは、ファイル、アプリケーション、ブラウザ操作、コンピューター使用などを横断する長時間実行タスクのためのエージェント型ワークスペースです。

予定された作業です。通常のチャットターンとは異なり、Workタスクは完了した成果物やアーティファクトを中心に設計されています。

エージェントコントロールプレーンとは何ですか？

エージェントコントロールプレーンは、エージェントの実行を管理するポリシーと運用の層です。タスクの分類、モデルルートの選択、スコープ付き認証情報の発行、ツール制限の適用、承認の実施、トレースの記録、結果の評価、予算の管理、リカバリーの管理を行います。

エージェントハーネスはコントロールプレーンとどのように異なりますか？

ハーネスは、コンテキストを組み立て、ツールを公開し、状態を保存し、アクションを実行し、リトライを管理するソフトウェアです。コントロールプレーンは、権限、ルーティング、予算、承認、評価、リカバリーなど、ハーネスがどのように動作するかを統制します。

チームはいつSol、Terra、またはLunaを使用すべきですか？

Lunaはリスクの低い抽出、分類、フォーマットに適しています。Terraは日常的なリポジトリ作業、ドキュメント作成、強力なチェックを伴う適度な分析に適しています。Solは曖昧な診断、アーキテクチャ、セキュリティレビュー、価値の高いリサーチにより適しています。

Solに切り替えると、エージェントにより多くの権限が与えられますか？

いいえ。モデルの能力と運用上の権限は分離されたままであるべきです。LunaやTerraからSolにアップグレードすると、推論能力は変わりますが、ツールへのアクセス、書き込み権限、デプロイ権限、承認要件は変わりません。

プロダクション環境での選択において、公開ベンチマークだけでは不十分なのはなぜですか？

公開ベンチマークには、欠陥のあるタスク、ハーネス固有の仮定、またはリークが含まれている可能性があります。候補を見つけるには有用ですが、実際の環境でのコスト、信頼性、レビューの負担、安全性を測定するには、実際の社内作業から構築されたプライベートな評価が必要です。

長時間実行エージェントでは何をログに記録すべきですか？

ログには、目標、モデルルート、推論努力、ツール呼び出し、ソース、承認、エラー、リトライ、トークン使用量、コスト、経過時間、アーティファクト、検証結果、エスカレーション理由、最終状態を含める必要があります。

関連ツール

• ChatGPT: OpenAIのチャット、Work、接続ツール、長時間実行タスクのための製品インターフェース。
• OpenAI API: GPT-5.6とResponses APIでアプリケーションを構築するための公式プラットフォーム。
• Codex: OpenAIのリポジトリ作業、ソフトウェアエンジニアリング、エージェントスキルのためのコーディングエージェントプラットフォーム。
• プログラムによるツール呼び出し: インメモリプログラムでツールを調整し、中間結果を処理するためのOpenAI公式ガイド。
• NIST AIリスク管理フレームワーク: AIリスクを特定、測定、管理するためのガバナンスフレームワーク。
• Databricks: データとAIプラットフォーム。エンジニアリングチームが実際のリポジトリ変更に基づいたプライベートなコーディングエージェント評価を公開。

関連リンク

• GPT-5.6 一般提供: OpenAI公式のGPT-5.6リリース。モデル階層、機能詳細、可用性、価格を含む。
• GPT-5.6 Solのプレビュー: OpenAIの

Solモデルの初期技術プレビュー。

• 野心的な仕事のためのChatGPT：OpenAIによる公式発表。ChatGPT Workとその長時間実行タスクモデルについて説明。
• プログラムによるツール呼び出しのドキュメント：ツール呼び出しのプログラムによる連携に関する公式開発者向けドキュメント。
• コーディング評価におけるシグナルとノイズの分離：公開コーディングベンチマークにおける信頼性問題に関するOpenAIの監査と議論。
• GPT-5.6システムカード：GPT-5.6に関するOpenAIの公式セーフティ・機能評価書類。
• Databricksコーディングエージェントベンチマーク：数百万行規模のコードベースにおける実際のプルリクエストから構築されたプライベート評価。

まとめ

GPT-5.6は、チームに対して能力、コスト、推論の労力、マルチエージェント実行の明確なメニューを提供する。ChatGPT Workはこれらの機能を、ファイル、アプリケーション、ブラウザ、スケジュールされたワークフローをまたがる永続的なタスクへと拡張する。

本番環境での課題は、単に最も強力なモデルを選択することではない。チームには、スコープ化されたアイデンティティ、狭いツール権限、承認ゲート、独立した受け入れチェック、完全なトレース、多次元の予算、プライベート評価、テスト済みのリカバリが必要となる。

まずはリバーシブルなワークフローを1つから始め、人間のベースラインを記録し、シャドウモードで実行し、権限は一度に1つの次元だけ増やすこと。

本番グレードのエージェントとは、単にツールを備えた強力なモデルではない。測定可能で、元に戻せ、説明責任のある制御プレーン内で動作するモデルである。