For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ja/articles/gpt-56-chatgpt-work-agent-control-plane.md.
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は、ChatGPT、Codex、API全体で3つの能力階層を提供します：
OpenAIはこれらの名称を、一時的な日付付きモデル名ではなく、耐久性のある能力階層として説明しています。この区別はプロダクションシステムにとって有用です。
「定期的なリポジトリメンテナンスにはバランスティアを使用する」といった方針は、将来のスナップショット変更にも耐えられます。再現性が重要な場合、チームは正確なスナップショットを別途固定できます。これは、モデルIDをプロンプト、スクリプト、ジョブキュー、環境変数に散りばめるよりもクリーンです。
GPT-5.6では、より明示的な計算制御も追加されています。
maxは、1つのモデルルートに、より多くの推論時間、代替案の探索、チェックの実行、作業の修正を可能にします。ultraは、複数のエージェントが並行して作業を行うワークストリームを調整します。
これらは異なる制御です：
タスクによっては、一方、両方、またはどちらも役に立たない場合があります。特にサブタスクが同じ不確実な前提を共有したり、同じ制限された資格情報を必要とする場合、並列実行が自動的に優れているとは限りません。
OpenAIは、プログラムによるツール呼び出しを、モデルがツールを調整し、中間結果を処理し、どの情報をモデルに返すべきかを決定する軽量プログラムを作成・実行する方法として説明しています。
これにより、繰り返されるコンテキスト転送を削減できます。すべてのデータベース行、ブラウザ応答、ツール結果をモデルに返す代わりに、インメモリプログラムが最初にデータをフィルタリングおよび集約できます。
この効率性には運用上のトレードオフが伴います。より多くのロジックが実行層に移行するため、チームはそれらの中間ステップに対して明確なトレース、制限、データ処理ルールを必要とします。
GPT-5.6リリースでは、Responses APIにマルチエージェントベータ版も導入されています。したがって、並列実行はアプリケーション側のオーケストレーションパターンだけでなく、APIレベルの機能になりつつあります。
リリース時点での公式価格は以下の通りです：
| ルート | 入力100万トークンあたりの価格 | 出力100万トークンあたりの価格 |
|---|---|---|
| GPT-5.6 Sol | $5.00 | $30.00 |
| GPT-5.6 Terra | $2.50 | $15.00 |
| GPT-5.6 Luna | $1.00 | $6.00 |
これらの価格はルーティング決定のインプットであり、決定そのものではありません。
より安価なモデルは、繰り返しリトライしたり、不必要なコンテキストを読み込んだり、レビュアーに拒否される成果物を生成したりする場合、承認された結果あたりのコストが高くなる可能性があります。より強力なモデルは、小さく検証済みの変更でタスクを一度で完了する場合、実際にはより安価になる可能性があります。
正しい指標は、単にトークンあたりのコストではありません。承認された成果あたりのコストです。
ChatGPT Workは、アプリケーションやファイルを横断して作業し、何時間も継続し、目標をより小さなステップに分解し、完成したアーティファクトを作成できるエージェントとして提示されています。
OpenAIはCodex技術が製品に組み込まれていると述べていますが、ターゲットはソフトウェアエンジニアリングよりも広範囲です。ワークフローの例としては以下が含まれます：
重要な変更点は、委任の単位です。
通常のチャットターンは回答を求めます。Workタスクは成果を求めます。
その成果を得るために、システムは以下のことを行う必要があるかもしれません：
情報が表示されます。
3. 複数のアーティファクトを作成する。
4. 人間の承認を待つ。
5. ユーザーが離席中にスケジュールされたタスクを続行する。
6. 接続アプリ、組み込みブラウザ、またはデスクトップコンピュータを使用する。
OpenAIは製品の表面を統合しつつある。Chat、Work、Codexは更新されたデスクトップ体験内で利用可能となり、ブラウザ機能はより広範な製品環境に移行している。
これにより、ローカルファイル、ウェブページ、接続サービス、ブラウザ操作、長時間実行タスクにまたがる単一の権限境界が生まれる。
したがって、エンタープライズコントロールはインターフェースと同じくらい重要である。管理コネクタ管理、コンプライアンス機能、レビュー機構はすべて同じ問題を指し示している。すなわち、エージェントは適切なID、最小限のコンテキスト、可視的な効果、そして回復経路を持って動作しなければならない。
チームがChatGPT Workを直接使用せずにカスタムAPIエージェントを構築する場合でも、Workは有用な参照運用モデルとなる。アシスタントが永続的なワーカーとなったときに現れる問題を浮き彫りにする。
モデルは入力コンテキストを出力およびツール決定にマッピングする。能力、制限、価格、レイテンシ、安全性の振る舞いを持つ。
Sol、Terra、Lunaはモデル階層である。モデル自体は組織の権限を決定しない。
エージェントハーネスはモデルを取り巻くソフトウェアである。コンテキストを選択し、ツールを公開し、コマンドを実行し、状態を保存し、失敗を再試行し、実行完了を判断する。
モデルとタスクが同じでも、ハーネスを変更することでコストと信頼性が大きく変わり得る。中間結果をフィルタリングするハーネスよりも、大きなコンテキストウィンドウを繰り返し送信するハーネスの方がはるかにコストがかかる可能性がある。
このため、ハーネスも指定されない限り、「モデル性能」は不完全である。
エージェントは以下を組み合わせる：
エージェントは複数のステップを踏み、ツールの結果に反応できる。長時間実行エージェントはサブタスクやサブエージェントを作成する場合があるが、並行ワーカーが自動的に安全なマルチエージェントシステムを形成するわけではない。それらは依然として予算、権限、最終承認判断を共有する。
コントロールプレーンはエージェント実行を管理するポリシーと運用の層である。
以下を行う：
実行プレーンはタスクを実行する。この二つを分離することで、チームは本番コードのデプロイや外部メッセージの送信を許可されている人を変更することなく、モデルを変更できる。
承認ゲートは、権限のある人物または決定論的ポリシーなしではエージェントが通過できない判断ポイントである。
承認は特定のアクションとその証拠に結び付けられるべきである。
有用な承認リクエストは以下の通り：
この最終確定メールを、添付の受信者リストと承認済みコンテンツを使用して、これら412人の受信者に送信することを承認してください。
弱い承認リクエストは以下の通り：
マーケティングタスクを承認してください。
受け入れテストは、
要求された成果は完了しています。
以下のものが該当します。
モデルが「完了」と述べることは、ステータスの主張であり、受入テストではありません。
実用的なプロダクションコントロールプレーンには、8つの責任があります。
分類は以下をカバーする必要があります。
「FAQの下書きを更新する」と「認証ポリシーを変更する」は、どちらもテキスト編集を含む可能性がありますが、異なるルートに属します。
最も安価な適格ルートが合理的なデフォルトですが、適格性は価格よりも優先されなければなりません。
例：
エージェントは、タスクに必要な正確なリポジトリ、フォルダ、アプリケーション、またはレコードに対する短期間の資格情報を受け取る必要があります。
単に便利だからといって、開発者の完全なブラウザセッションを継承すべきではありません。
実行IDはログに表示され、チームがすべての外部アクションを特定できるようにする必要があります。
これらは個別の機能です。
メールボックスを検索できるコネクタが、自動的にメールを送信できるべきではありません。リポジトリを検査できるGitHub統合が、自動的にプルリクエストをマージできるべきではありません。
承認ゲートは、結果を伴うアクションの直前に表示され、影響と証拠の簡潔なプレビューを示す必要があります。
ソフトウェアの場合、証拠には以下が含まれます。
財務の場合、以下が含まれます。
トレースには以下を含める必要があります。
短い要約は運用に役立ちますが、インシデントレビューには十分ではありません。
有用な制限には以下が含まれます。
弱い実行やループ実行を停止することは、自律性の失敗ではありません。それはポリシーの成功した適用です。
リカバリには以下が含まれます。
システムが実行前にリカバリを説明できない場合、そのタスクは無人運用の準備ができていません。
モデルルーティングは、エンジニア、プロダクトマネージャー、セキュリティレビュー担当者が読めるように明示的である必要があります。
以下の表は
出発点であり、普遍的なランキングではありません。
| ルート | 適したタスク形状 | 必要なエビデンス | 標準的な権限 |
|---|---|---|---|
| Luna | 分類、抽出、フォーマット、低リスクの要約、限定されたコード検索 | スキーマ検証、サンプルレビュー、ソースリンク | 読み取り専用または下書きのみ |
| Terra | 日常的なリポジトリ変更、ドキュメント作成、既知のワークフロー、中程度の分析 | 対象を絞ったテスト、成果物検証、人間によるスポットチェック | 限定書き込み、不可逆的な外部アクションなし |
| Sol | 曖昧な診断、システム横断的な分析、アーキテクチャ作業、セキュリティレビュー、高価値の調査 | 広範な決定論的チェック、レビューアーから見える根拠、ソースの来歴 | 明示的な承認を伴う限定書き込み |
Sol max | より多くの探索と修正が品質を向上させる可能性がある、困難な単一スレッド推論 | チェックポイント、コスト制限、最終検証 | Solと同じ権限 |
Sol ultra | 独立したワークストリームを持つ、高価値で並列化可能なタスク | ワークストリームごとのエビデンス、統合レビュー、総予算上限 | 可能な限り個別のスコープ化されたID |
最後の列が最も重要です。
モデルの能力によって権限が増加してはいけません。
LunaからSolに切り替えた際に、書き込みアクセスが黙って追加されてはいけません。推論の労力を上げても、下書きが承認済みの外部メッセージに変わってはいけません。Ultraが、すべて無制限の本番環境用クレデンシャルを共有する複数のワーカーを作成してはいけません。
Lunaルートは以下の場合にエスカレーションされる可能性があります：
Terraのコーディングタスクは以下の場合にエスカレーションされる可能性があります：
Solルートは、要件が競合する場合、または残された唯一のアクションが不可逆的である場合に、停止して人間に問い合わせる必要があります。
Solが計画を策定すると、TerraまたはLunaが、狭いチェックの下で反復的なサブタスクを実行できます。
強力なモデルは、すべての項目を処理するのではなく、サンプルをレビューできます。これにより、判断と量が分離され、コストを大幅に削減できる可能性があります。
権限システムは動詞から始めるべきです。
read（読み取り）
search（検索）
create_draft（下書き作成）
modify（修正）
send（送信）
merge（マージ）
deploy（デプロイ）
delete（削除）
purchase（購入）
grant_access（アクセス権付与）
これらの動詞は異なる結果をもたらします。
多くのプロダクト統合では、複数のアクションを1つの広範なOAuthスコープの背後に配置しています。したがって、コントロールプレーンは、より狭い操作を公開するアプリケーション側のプロキシを必要とする場合があります。
「Google ドライブを読み取る」は、多くのワークフローにとって広すぎます。
より狭いルールは次のようになる可能性があります：
UTC 18:00まで、第3四半期の計画フォルダと承認済みブランドテンプレートフォルダを読み取る。
リポジトリの場合、アクセスはネットワークアクセスが無効になった1つのワークツリーに制限される場合があります。データベースの場合、読み取りレプリカまたは管理されたビューが通常、本番環境のクレデンシャルよりも安全です。
例：
データソースの変更は管理者権限が必要です。
変更を作成するエージェントが、その正確性を判断する唯一の存在であってはなりません。
有用な証拠は以下から得られます：
第二のモデルは責任ある人間の代わりにはなりませんが、アクションが外部に発信される前に不一致を明らかにすることがあります。
プロバイダーによる保護は一層に過ぎません。特定のリポジトリをテストする権限がユーザーにあるか、変更を顧客が承認したか、本番メンテナンスウィンドウが開いているかどうかは認識できません。
アプリケーションの認可はビルダーの責任です。
チームはChatGPT Workやカスタムエージェントに以下を依頼します：
必要な成果物は、責任者と障害事項をリストアップした準備状況レポートです。
エージェントは4つの情報源をすべて読み、レポートを作成できます。承認なしに課題ステータスを編集したり、関係者にメッセージを送信したりすることはできません。
エージェントがキャッシュされたドキュメントを使用したため、レポートに既に解決済みの課題が記載されます。
制御プレーンは、直接情報源へのリンクとタイムスタンプを必須とする必要があります。
チェックリストのすべての行にテキストが入力されているため、エージェントはリリース準備完了と宣言します。
代わりに、受け入れテストでは、すべてのブロック依存関係に確認済みの責任者、日付、現在のステータスがあることを必須とする必要があります。
タスクはモノレポ全体でライブラリをアップグレードすることです。
マイグレーションが文書化され、テストスイートが強力であるため、Terraが開始します。ブランチを作成し、ロックファイルと影響を受けるパッケージを編集し、対象を絞ったチェックを実行します。
コンパイラエラーにより、認証モジュールで文書化されていないAPI変更が明らかになります。これにより、Solへのエスカレーションが発生します。
モデルは変わりますが、権限は変わりません。
Solは同じワークツリーを受け取り、デプロイメントトークンは付与されません。差分が認可ロジックに影響を与える場合、ポリシーはセキュリティレビューゲートを追加します。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
完了には以下が必要です：
動作するように見えてもこれらのチェックをスキップするパッチは受け入れられません。
毎朝、エージェントが新しいサポートチケットを読み、テーマをクラスタリングし、プロダクト概要を更新します。
Lunaは、機密フィールドが削除された後にチケットを分類できます。Terraはソースリンク付きの概要をドラフトできます。
どちらのルートも以下を行うことはできません：
エージェントが「明らかな応答も処理する」という新しい指示が追加されます。
これにより、内部分析ワークフローが外部コミュニケーションに変わります。
タスク分類子は、新しい「送信」動詞を検出し、別個のポリシー、承認されたテンプレート、サンプリング計画、人間の責任者を必須とする必要があります。
ある企業が3つのアーキテクチャオプションを評価しています。
Sol ultra は以下に個別のワークストリームを割り当てます：
ワークストリームが独立しているため、並列実行は正当化されます。
独立しており、その判断には価値があります。各ワーカーはソース要件と固定予算を受け取ります。
すべてのワーカーが同じベンダーのベンチマークを引用し、意見が一致しているように見えます。
統合ゲートは、ソースの多様性を測定し、共有された根拠のない前提をフラグし、各オプションに対して少なくとも1つの反論を要求する必要があります。
エージェントが増えれば、カバレッジを向上させるのと同じくらい簡単に、誤った前提を増幅させることができます。
公開ベンチマークは有用ですが、プロダクションのデフォルトを直接決定すべきではありません。
OpenAIによるSWE-Bench Proの監査では、公開タスクのかなりの割合に次のような問題があることが報告されました。
これは、すべての公開ベンチマークが無意味であることを意味するわけではありません。
スコアがそのデータセットとハーネスの測定誤差を継承することを意味します。
公開評価は以下のために有用です。
公開評価だけでは、モデルが特定のモノレポ、ビジネスワークフロー、データ環境において安全な変更を加えるかどうかを判断することはできません。
コントロールプレーンは、各ルーティング判断とともにベンチマークの来歴を保存する必要があります。
これらの詳細がなければ、ベンチマックスコアはマーケティングの決まり文句になります。
Databricksは、数百万行のコードベース評価で有用な例を示しています。
同チームは、以下の言語で実際の人間が作成したプルリクエストからタスクを構築しました。
意味のあるテストを含む最近の代表的な変更を選択し、解決策を明かさずに意図を保持するようにタスクの説明を書き直し、各サンプルを手動でレビューしました。
また、チームは初期設定で情報漏洩を発見しました。エージェントがGit履歴から将来のコミットを復元できたのです。評価実行中は、ワークツリーがリポジトリの履歴から分離されていました。
この詳細は、最終的なランキングよりも重要です。ベンチマークがエンジニアリング能力ではなく、ショートカットの発見を誤って測定する可能性を示しています。
チームは30～60のタスクから始めることができます。
以下の特徴を持つ、承認された過去の変更を使用します。
以下の組み合わせを含めます。
変更前のリポジトリ状態を保存し、最終的なパッチを隠します。
人間またはモデルによる判断の前に、決定論的なテストを使用します。
その後、以下のために人間によるレビューを追加します。
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
このテンプレートには、いくつかの意図的な選択が反映されています。
コーディングワークフローの場合は、レポートチェックを以下に置き換えてください。
スプレッドシートワークフローの場合は、以下を必須とします。
エビデンスが変わっても、コントロールプレーンの構造は安定したままです。
長時間実行されるエージェントは、新たな観測可能性の問題を引き起こします。
従来のリクエストログには、1回のAPI呼び出しのみが表示される場合があります。エージェントのトレースには、数百もの決定、ツール呼び出し、リトライ、中間アーティファクトが含まれる可能性があります。
チームには両方が必要です。
有用な台帳には以下が含まれます。
これにより、以下のような質問に答えることが可能になります。
金銭的な制限だけでは、安価なモデルが長時間ループし続ける可能性がある。
時間制限だけでは、高価な並列処理が突発的に発生する可能性がある。
有用な予算の軸には以下が含まれる：
リカバリは他の機能と同様にテストされるべきである。
有用なテストには以下が含まれる：
インシデントレビューでは、以下を区別すべきである：
「AIのせい」にするだけでは、実際に改善できるコンポーネントが見えなくなる。
頻繁で、測定可能で、元に戻せる1つのワークフローから始めること。
適切な候補には以下が含まれる：
最初のデプロイでは、以下を避けること：
以下を測定すること：
ベースラインがないと、エージェントの高速な出力によって、単に修正作業が増える可能性がある。
人間が実際のワークフローを独立して完了する間、エージェントに成果物を生成させる。
結果を比較し、障害モードにラベルを付ける。これらの実行結果を使って、権限を拡大する前にプライベート評価を構築する。
ドラフト専用アクセスから限定書き込みアクセスに移行する前に、以下を確認すること：
一度に1つの軸だけを拡大すること。
チームは、ドラフト専用出力を維持したまま新しいデータソースを追加したり、同じモデルとタスクを維持したまま限定書き込みアクセスを追加したりできる。
モデル、ツール、権限、スケジュールを同時に変更すると、後退の原因を特定することが難しくなる。
GPT-5.6とChatGPT Workは、エージェントインフラが独自のプロダクトカテゴリになりつつある証拠である。
モデル層は変化し続ける。永続的な価値を持つのは、以下のような制御プレーンである。
該当するモデルの変更は安全です。
Sol、Terra、Luna、およびOpenAI以外の候補モデル向けに、小規模なレジストリを作成します。
以下を保存します：
プライベートな評価キューを追加し、新しいモデルがソーシャルメディアの印象のみに基づいて本番環境のデフォルトにならないようにします。
エージェントと重要なツールの間に認証プロキシを配置します。
以下を公開します：
タスクがChatGPT Work、Codex、カスタムアプリケーション、またはスケジュールされたバックエンドジョブのいずれで開始された場合でも、同じ境界を維持します。
タスクの検証方法を説明できるチームは、それを段階的に安全に自動化できます。
検証を定義できないチームは、ベンチマークスコアに関係なく、エージェントを数時間稼働させる準備ができていません。
以下の単位ごとに、ドルと人時間を追跡します：
これにより、モデルルーティング、ハーネスの効率、レビューアの作業負荷が調整されます。
また、次世代のフラッグシップモデルが登場した際に、チームは根拠のある回答を得ることができます。
リリース資料に記載されているいくつかの主張は、ベンダー報告に基づいています。
クロスプロバイダーのベンチマーク比較では、以下が異なります：
これらの主張は、内部テストのための仮説として扱います。
プログラムによるツール呼び出しとマルチエージェント実行は、コンテキストのオーバーヘッドを削減する可能性がありますが、トレースが弱い場合には中間ロジックの可視性が低下する可能性もあります。
規制対象のワークフローでこれらの機能を使用する前に、以下を確認します：
ChatGPT Workの接続アプリケーションとコンピューター使用機能は、有用性を高める一方で、権限範囲を拡大します。
可用性、管理制御、コネクタの権限は、プランやデプロイメントによって異なる場合があります。
プロダクトの発表は、ワークスペース固有のセキュリティレビューの代わりにはなりません。
また、人間とシステム間の問題もあります。エージェントが長時間稼働する場合、ユーザーは十分に観察していない作業を承認する可能性があります。
より良い要約は役立ちますが、承認の質は、決定時点で提案された効果、不確実性、失敗したチェックを示すかどうかに依存します。
プロダクトデザインは、人間の注意を保護しなければならず、単なるクリックを要求するものではありません。
したがって、最強のモデルが最終的なアーキテクチャというわけではありません。
本番品質は、以下の関係から生まれます：
この関係こそが、エージェントコントロールプレーンが明確にするものです。
GPT-5.6は、OpenAIの2026年7月のモデルファミリーであり、Sol、Terra、Lunaの能力階層に編成されています。Solは最高能力のルート、Terraは能力とコストのバランス、Lunaは速度と手頃さを優先します。
ChatGPT Workは、ファイル、アプリケーション、ブラウザ操作、コンピューター使用などを横断する長時間実行タスクのためのエージェント型ワークスペースです。
予定された作業です。通常のチャットターンとは異なり、Workタスクは完了した成果物やアーティファクトを中心に設計されています。
エージェントコントロールプレーンは、エージェントの実行を管理するポリシーと運用の層です。タスクの分類、モデルルートの選択、スコープ付き認証情報の発行、ツール制限の適用、承認の実施、トレースの記録、結果の評価、予算の管理、リカバリーの管理を行います。
ハーネスは、コンテキストを組み立て、ツールを公開し、状態を保存し、アクションを実行し、リトライを管理するソフトウェアです。コントロールプレーンは、権限、ルーティング、予算、承認、評価、リカバリーなど、ハーネスがどのように動作するかを統制します。
Lunaはリスクの低い抽出、分類、フォーマットに適しています。Terraは日常的なリポジトリ作業、ドキュメント作成、強力なチェックを伴う適度な分析に適しています。Solは曖昧な診断、アーキテクチャ、セキュリティレビュー、価値の高いリサーチにより適しています。
いいえ。モデルの能力と運用上の権限は分離されたままであるべきです。LunaやTerraからSolにアップグレードすると、推論能力は変わりますが、ツールへのアクセス、書き込み権限、デプロイ権限、承認要件は変わりません。
公開ベンチマークには、欠陥のあるタスク、ハーネス固有の仮定、またはリークが含まれている可能性があります。候補を見つけるには有用ですが、実際の環境でのコスト、信頼性、レビューの負担、安全性を測定するには、実際の社内作業から構築されたプライベートな評価が必要です。
ログには、目標、モデルルート、推論努力、ツール呼び出し、ソース、承認、エラー、リトライ、トークン使用量、コスト、経過時間、アーティファクト、検証結果、エスカレーション理由、最終状態を含める必要があります。
Solモデルの初期技術プレビュー。
GPT-5.6は、チームに対して能力、コスト、推論の労力、マルチエージェント実行の明確なメニューを提供する。ChatGPT Workはこれらの機能を、ファイル、アプリケーション、ブラウザ、スケジュールされたワークフローをまたがる永続的なタスクへと拡張する。
本番環境での課題は、単に最も強力なモデルを選択することではない。チームには、スコープ化されたアイデンティティ、狭いツール権限、承認ゲート、独立した受け入れチェック、完全なトレース、多次元の予算、プライベート評価、テスト済みのリカバリが必要となる。
まずはリバーシブルなワークフローを1つから始め、人間のベースラインを記録し、シャドウモードで実行し、権限は一度に1つの次元だけ増やすこと。
本番グレードのエージェントとは、単にツールを備えた強力なモデルではない。測定可能で、元に戻せ、説明責任のある制御プレーン内で動作するモデルである。
ひとことから始めて、数分で完全なサイトを手に入れましょう。
