GPT-5.6正式提供が示すAIエージェント運用の転換｜Sol/Terra/Lunaをどう使い分けるか

目次

---

1. AIモデル選定は「最強を一つ選ぶ」段階を越えた

生成AIの導入で、企業が最初に聞きたくなるのは「どのモデルが一番賢いのか」です。文章作成や要約が中心だった時期なら、その問いでもある程度は足りました。しかし、AIがコードを書き、社内ファイルを読み、表計算を作り、複数のアプリをまたいで作業し、必要に応じてサブエージェントを動かすようになると、単純な性能比較だけでは判断できません。

OpenAIは2026年7月9日、GPT-5.6ファミリーの一般提供を発表しました。今回の重要点は、フラッグシップのSolだけではありません。日常業務向けのTerra、最も高速で低コストなLunaを含む3階層で提供され、ChatGPT、Codex、OpenAI API、ChatGPT Work、Microsoft 365 Copilotへ一気に展開される点にあります。

これは、企業のAI運用にとって大きな転換です。これからは「上位モデルを全員に使わせるか」ではなく、「どの業務を、どのモデルに、どの努力量で、どこまで任せるか」を設計する必要があります。この記事では、OpenAIの公式発表をもとに、GPT-5.6を企業のAIエージェント運用、モデルルーティング、コスト管理、安全設計の観点から整理します。

2. OpenAIの発表で何が変わったのか

OpenAIの公式発表によると、GPT-5.6は限定プレビューを経て、ChatGPT、Codex、OpenAI APIで提供が始まりました。モデルファミリーはSol、Terra、Lunaの3種類です。Solはフラッグシップ、TerraはGPT-5.5に競争力のある低コストモデル、Lunaは最速かつ最も手頃なモデルとして位置づけられています。

利用面では、ChatGPTのPlus、Pro、Business、EnterpriseユーザーがSolを利用でき、ProとEnterpriseでは複雑なタスク向けにSol Proも選べます。ChatGPT WorkとCodexでは、FreeとGoユーザーがTerraを利用でき、Plus以上のユーザーはSol、Terra、Lunaを選択し、努力量も設定できます。maxはGPT-5.6にアクセスできるChatGPT WorkとCodexユーザーで使え、ultraはChatGPT WorkではProとEnterprise、CodexではPlus以上で利用できます。

APIでは、Sol、Terra、Lunaの3モデルに加えて、Responses APIのProgrammatic Tool Callingとmulti-agent betaが発表されています。Programmatic Tool Callingは、モデルがメモリ上で軽量なプログラムを書いて実行し、ツール呼び出しや中間結果の処理を調整できる仕組みです。multi-agent betaは、複数のサブエージェントを並行して動かし、その結果を一つのリクエストで統合する方向性を示しています。

価格も企業にとって重要です。OpenAIは100万トークンあたりの価格として、Solを入力5ドル・出力30ドル、Terraを入力2.50ドル・出力15ドル、Lunaを入力1ドル・出力6ドルと発表しています。加えて、明示的なキャッシュ区切りと30分以上のキャッシュ保持、キャッシュ読み取りの90%割引も示されました。ここから見えるのは、モデル単価だけでなく、プロンプト設計、キャッシュ設計、タスク分解まで含めてコストを下げる時代になったということです。

3. Sol/Terra/Lunaをどう使い分けるか

GPT-5.6の3階層は、企業がモデルを役割で分けるための分かりやすい材料になります。Solは、重要な判断、長時間のエージェント作業、複雑なコードレビュー、セキュリティ調査、経営資料や提案書の最終品質に近い仕事へ寄せるべきです。特にmaxやultraを使う場合、精度だけでなく、誰が依頼し、どこまで実行し、どの時点で人間が確認するかをセットで設計します。

Terraは、日常業務の標準モデルとして考えやすい位置づけです。会議メモの整理、社内ドキュメントの初稿、FAQの下書き、定型的な調査、軽いコード修正案など、品質とコストのバランスが重要なタスクに向きます。OpenAIはTerraをGPT-5.5に競争力のある低コストモデルとして説明しており、全社利用のベースラインにしやすいモデルです。

Lunaは、速度と単価が重要な大量処理向けです。問い合わせの分類、文書のタグ付け、入力内容の整形、簡単な要約、RAGの前処理、ログの一次分類など、1件あたりの判断が軽く、件数が多い処理に向きます。ここでSolを使うと、精度の上積みに対してコストが大きくなりすぎる可能性があります。

大切なのは、モデル階層を社内の権限階層と混同しないことです。役員だけがSolを使う、一般社員はLunaだけ、という分け方ではなく、タスクの重要度、必要な推論量、扱うデータの機密性、操作権限で判断します。新人の定型作業でも機密データを扱うなら慎重な設計が必要ですし、熟練者の作業でも大量分類ならLunaで十分なことがあります。

4. ChatGPT WorkとMicrosoft 365 Copilotが示す業務AIの入口

今回の発表で見逃せないのは、GPT-5.6がモデル単体ではなく、業務アプリの入口に組み込まれていることです。OpenAIは、ChatGPT Workを「アプリやファイルをまたいで行動し、必要なら数時間にわたってプロジェクトを進め、目標を成果物へ変えるエージェント」と説明しています。単なるチャットではなく、資料、表、ドキュメント、Webアプリ、反復タスクを扱う作業面として位置づけられています。

さらに、OpenAIはGPT-5.6がMicrosoft 365 Copilotの新しい優先モデルになることも発表しました。Word、Excel、PowerPoint、Chat、Coworkで使われ、文書作成、分析、プレゼン作成、横断的な共同作業を支援するという説明です。これは、企業のAI導入が「専用AIツールを開いて使う」段階から、「普段使っている業務アプリの中でエージェントに任せる」段階へ進むことを示しています。

現場で起きる変化は具体的です。営業部門では、顧客調査、提案書、商談メモ、CRM更新の流れをひとつの作業として扱えるようになります。管理部門では、月次データを確認し、差異の理由を整理し、説明資料を作るところまでAIに任せやすくなります。開発部門では、Codexで調査、修正、テスト、レビュー準備までをまとめて依頼する場面が増えます。

ただし、入口が業務アプリに近づくほど、ガバナンスもアプリ横断で考える必要があります。Wordで作った文書、Excelで読んだ数字、SlackやTeamsの会話、CRMの顧客情報、Gitリポジトリのコードが一つの作業に混ざります。AIが便利になるほど、どのデータへアクセスできるか、外部送信や共有をどう防ぐか、管理者が使用量とリスクをどう見える化するかが重要になります。

5. Programmatic Tool Callingとmulti-agentが運用設計を変える

GPT-5.6で特に技術的に重要なのが、Programmatic Tool Callingです。従来のツール利用では、モデルがツールを呼び、結果を受け取り、次の判断をするという往復が増えがちでした。中間結果が大きいほど、トークンも時間も膨らみます。OpenAIの説明では、GPT-5.6は軽量なプログラムを使って中間データを処理し、必要な情報だけを残しながらワークフローを進められます。

企業の実務に置き換えると、これはかなり大きな違いです。たとえば、月次の売上分析で数十のCSV、CRMの履歴、商談メモ、過去のレポートを扱う場合、すべてをモデルへ丸ごと渡す設計は非効率です。プログラムで集計やフィルタリングを行い、モデルは判断が必要な部分に集中する。この分担ができると、精度、速度、コスト、データ最小化のすべてに効きます。

multi-agentも同じ方向を向いています。複雑な仕事では、調査担当、実装担当、検証担当、要約担当のように役割を分けたほうが進めやすいことがあります。OpenAIはultraで複数エージェントを並行させる方向性を示しましたが、企業側ではこれを「速くなる便利機能」とだけ見ないほうがよいでしょう。複数エージェントが動くほど、誰が何を判断したか、どの結果を採用したか、失敗時にどこまで戻るかをログで追う必要があります。

このため、AIエージェント基盤では、プロンプトだけでなく実行基盤の設計が重要になります。タスクキュー、ツール権限、ワークスペース分離、社内データ接続、承認フロー、監査ログ、再実行の仕組みを合わせて作る必要があります。モデル性能が上がるほど、周辺の運用設計が成果を左右します。

6. 安全性とコストを同時に設計する

GPT-5.6の発表では、安全性への言及も厚くなっています。OpenAIは、能力が高まるほど安全スタックを強化すると説明し、生物・サイバー領域ではCriticalしきい値を超えない一方、正当な防御業務を過度に妨げない設計を目指していると述べています。さらに、GPT-5.6 Solのサイバーセーフガードは以前のモデルより有害な可能性のある活動を大幅に多くブロックし、一般提供前には外部専門家を含む評価や大規模な自動レッドチーミングを行ったとされています。

企業にとって、この安全設計は「提供元が守ってくれるから安心」という意味ではありません。むしろ、自社側でも同じ考え方を採用すべきだというサインです。AIが高度なコード操作、セキュリティ調査、社内ファイル参照、顧客データ処理を担うなら、モデル側の安全策に加えて、社内の利用権限、環境分離、人間承認、ログ保存を設計する必要があります。

コストも同時に考えるべきです。Solは強力ですが、出力単価はTerraやLunaより高くなります。全社員のすべてのタスクをSolに流す設計は、費用面でも運用面でも現実的ではありません。一方で、重要な調査や顧客提出物の最終品質にLunaだけを使うと、手戻りやレビュー負荷が増える可能性があります。

現実的には、入力段階でタスクを分類し、軽い処理はLuna、標準業務はTerra、重要・複雑・高リスクな処理はSolへ送るルーティングが必要です。さらに、同じSolでもmedium、max、ultraのような努力量をタスクごとに変えます。AI運用の成熟度は、上位モデルを使えるかではなく、モデルを使い分けるルールを運用できるかで決まります。

7. 導入前に決める判断基準

GPT-5.6を導入する前に、最初に決めるべきなのはモデル名ではありません。自社の業務を、AIにどこまで任せるかです。読むだけ、下書きする、検証環境で実行する、本番へ反映する、外部へ送信する。この段階を分けずに導入すると、便利な使い方と危険な使い方が同じ権限で混ざります。

次に、モデルルーティングの基準を決めます。扱うデータが機密か、結果が顧客へ出るか、金額や契約に影響するか、実行系ツールを使うか、失敗時に人間がすぐ検知できるか。これらを判定し、どのモデルと努力量を使うかを決めます。最初は粗いルールで構いませんが、ログを見ながら改善できるようにしておくことが重要です。

三つ目は、評価指標です。AI導入の成否を「利用回数」だけで測ると、現場の本当の価値が見えません。削減できたレビュー時間、差し戻し率、完成物の再利用率、ツール実行の失敗率、追加承認が必要になった件数、想定外のデータ参照がなかったかを見ます。特にエージェント型の作業では、途中経過のログが評価材料になります。

8. 注意点

GPT-5.6の正式提供は大きなニュースですが、すぐに既存のAI基盤を全面移行する理由にはなりません。まずは、自社の実務タスクで評価することが必要です。公開ベンチマークで高い性能が示されても、社内の古い業務ルール、独自データ、権限体系、例外処理にそのまま合うとは限りません。

価格についても、単価表だけでは総コストは読めません。長いコンテキスト、ツール呼び出し、再試行、レビューや差し戻し、キャッシュ設計によって実際の費用は変わります。特にmulti-agentやultraは、時間短縮や品質向上の価値がある一方で、複数エージェント分のトークンが発生します。重要な仕事に絞って使う設計が必要です。

安全性では、モデル側のガードレールを過信しないことが大切です。OpenAI自身も、完全な安全は存在せず、新しい弱点や回避手法が見つかる前提で、継続的な監視と改善を行うと説明しています。企業側でも、ログを残し、異常な使い方を検知し、権限を見直し、利用者教育を続ける必要があります。

また、ChatGPT WorkやMicrosoft 365 Copilotへの展開は便利ですが、社内の既存ポリシーと衝突する可能性があります。ファイル共有、外部送信、顧客データ、個人情報、開発リポジトリ、会計情報など、AIが触れる範囲を事前に棚卸ししておくべきです。業務アプリに組み込まれるAIほど、導入前の情報整理が効きます。

9. まとめ

GPT-5.6の正式提供は、AIモデル運用が「強いモデルを選ぶ」段階から「業務ごとにモデルを振り分ける」段階へ進んだことを示しています。Sol、Terra、Lunaという3階層、ChatGPT WorkとCodexでの努力量設定、APIのProgrammatic Tool Calling、multi-agent beta、Microsoft 365 Copilotへの展開は、AIが業務の入口と実行基盤の両方に近づいていることを意味します。

企業が取るべき姿勢は、すぐに全社展開することでも、様子見だけで止まることでもありません。まず業務を分類し、軽い処理はLuna、標準業務はTerra、重要で複雑な作業はSolへ振り分ける。さらに、ツール権限、人間承認、監査ログ、コスト上限、キャッシュ設計を合わせて整える。この設計が、これからのAIエージェント運用の土台になります。

OpenBridgeでは、生成AI導入、AIエージェント開発、RAG、MCP、社内ツール連携、監査ログ設計まで含めて、企業ごとの業務に合わせたAIシステム開発を支援しています。GPT-5.6のような新しいモデルを活かすには、モデルを試すだけでは足りません。どの仕事を任せ、どの操作を止め、どの証跡で説明できるようにするかを設計することが、実用化への近道になります。