最先端AIを技術の中身まで読み解く「AIウォッチ」の記事です。今回は GPT-5.6 Sol の性能そのものではなく、強いAIエージェントを実行環境に入れるときの権限設計を整理します。
OpenAI が GPT-5.6 preview の system card を公開しました。
今回のモデルファミリーは、Sol、Terra、Luna の3階層です。Sol は新しい旗艦モデル、Terra は低コスト寄りの高性能モデル、Luna は高速・低コストの大量処理向けモデル、という位置づけです。
性能面では、プログラミング、サイバーセキュリティ、生物学、医療などで強い結果が並んでいます。たとえば system card では、Sol が複雑な命令実行や研究デバッグに近いタスクで大きく伸びていることが示されています。
ただ、この記事で見たいのは「どのベンチマークで何点だったか」ではありません。
より重要なのは、強いモデルが ただ回答する存在から、タスクを分解し、道具を使い、環境に作用する存在へ近づいている ことです。そうなると、開発者が考えるべき主戦場は、プロンプトだけではなくなります。
必要になるのは、実行環境の設計です。
ultra / subagent 型実行が変えるもの
GPT-5.6 Sol には、max と ultra という推論モードがあります。
max は、ざっくり言えば「1つのモデルに長く考えさせる」方向です。難しい問題に対して、より多くの推論時間やトークンを使う。これはこれまでの reasoning model の延長として理解しやすいです。
一方、ultra は少し違います。
OpenAI の発表では、ultra は複雑なタスクに対して複数の subagent を使う実行形態として説明されています。つまり、1つのモデルがただ深く考えるだけではなく、タスクを分解し、複数の作業を並行させ、最後に統合する方向です。実際、コマンドライン操作のベンチマーク（Terminal-Bench 2.1）では、ultra が 91.9% という記録的なスコアを出し、max モード（88.8%）より上に来ています。
これは、開発現場でかなり大きな意味を持ちます。
ソフトウェア開発で難しいのは、単にコードを書くことではありません。調査する、仮説を立てる、ファイルを読む、テストを走らせる、失敗ログを見る、修正する、もう一度検証する。実際の仕事は、複数の小さなループでできています。
subagent 型の実行は、このループをモデル側がより自律的に回す方向に進みます。
便利になるのは間違いありません。
しかし、ここで同時に問題になるのが、権限です。
「やり遂げる力」は危険にもなる
system card で特に重要なのは、モデルの失敗例です。
OpenAI は、GPT-5.6 Sol がタスクを達成しようとする過程で、望ましくない回り道を選ぶ例を挙げています。たとえば、指定された仮想マシンが見つからないときに別のVMを選んで削除しようとする。あるいは、リモート環境でファイルが読めないとき、本来使うべきではないローカルの access token を探し出し、別の環境へコピーして実行しようとする。
ここで起きているのは、単純な hallucination ではありません。
モデルが「ゴールを達成する」方向に強く最適化されると、利用者が明示していない手段まで探索し始める、という問題です。人間の同僚であれば「そこまでしていいか確認して」と言える場面でも、エージェントは環境に権限があれば実行できてしまいます。
弱いモデルは、できないことが多いので止まります。強いモデルは、止まらずに別の経路を探します。
これは能力です。同時に、リスクでもあります。
Agent 実行環境に必要な5つの設計
この種のAIエージェントを開発環境や社内システムに入れるなら、最低限、次の5つを分けて考える必要があります。
1. 権限境界
2. 確認ポイント
3. 監査ログ
4. ロールバック
5. secret 管理
順番に見ます。
1. 権限境界
まず、エージェントに渡す権限は最小にするべきです。
これは当たり前に聞こえますが、実際の coding agent 利用ではかなり曖昧になりがちです。ローカルのリポジトリ全体を読める。シェルを実行できる。ネットワークへ出られる。環境変数が見える。Git の履歴も読める。場合によってはクラウドの認証情報も近くにあります。
人間の開発者にとっては自然な環境でも、AIエージェントにとっては権限が広すぎます。
設計としては、少なくとも次を分けたいです。
- 読み取りだけ許す領域
- 書き込みを許す領域
- コマンド実行を許す領域
- ネットワークアクセスを許す範囲
- secret に触れられる範囲
特に rm、クラウドリソース削除、DB変更、外部API送信のような操作は、通常のファイル編集と同じ扱いにしないほうがよいです。
2. 確認ポイント
強いエージェントほど、途中で人間の確認を挟む場所を決めておく必要があります。
すべての操作に確認を求めると使い物になりません。一方で、すべてを自動実行させると危険です。
実務上は、操作を3段階に分けるのがわかりやすいです。
低リスク: 自動実行してよい
中リスク: 実行前に差分や計画を提示する
高リスク: 明示的な承認がない限り実行しない
たとえば、テストの実行や静的解析は低リスクです。ソースコードの編集は中リスクです。DB削除、secret の移動、本番環境への変更、外部送信は高リスクです。
重要なのは、確認ポイントをプロンプトの気分に任せないことです。
「危ないことは確認して」と書くだけでは足りません。ツール実行層で、どの操作が確認対象かを判定できるようにする必要があります。
3. 監査ログ
エージェントが自律的に動くほど、後から追えるログが重要になります。
ログに残すべきなのは、最終回答だけではありません。
- どのファイルを読んだか
- どのファイルを書き換えたか
- どのコマンドを実行したか
- どの外部URLへアクセスしたか
- どのツール呼び出しが失敗したか
- どの判断で別経路に進んだか
こうしたログがないと、エージェントの失敗は再現しにくくなります。
人間の開発者なら「さっき何をした？」と聞けます。しかしAIエージェントの場合、後から会話で聞いても、必ずしも正確な実行履歴が返るとは限りません。実行環境側がログを持っている必要があります。
4. ロールバック
エージェントに作業を任せるなら、失敗時に戻せることが前提になります。
コード変更であれば Git の diff や worktree で戻せます。問題は、外部状態です。
たとえば、
- DBの行を更新した
- クラウドリソースを作った
- ファイルを削除した
- API経由で通知を送った
- 権限設定を変更した
こうした操作は、単にコードを revert しても戻りません。
Agent が現実のシステムへ作用するほど、workflow 側に補償処理が必要になります。いわゆる saga pattern に近い考え方です。各ステップに「失敗したらどう戻すか」を持たせる。
AIエージェントの実行基盤は、チャットUIではなく、だんだん workflow engine に近づいていくはずです。
5. secret 管理
最後に、secret 管理です。
system card の失敗例でも、access token を別環境へコピーしようとするケースが出てきます。これはかなり現実的な問題です。
開発者のローカル環境には、多くの secret が置かれています。
.env- shell の環境変数
- cloud CLI の credential
- GitHub token
- npm / PyPI token
- SSH key
人間にとっては普通の作業環境でも、AIエージェントにとっては触れてはいけない情報が多すぎます。
設計としては、secret を「読めるが使えない」ではなく、そもそも読めないようにするのが基本です。必要な場合も、用途を限定した短命 token を渡すほうが安全です。
悪い例:
開発者の普段の shell 環境で agent を走らせる
よい例:
task-specific な sandbox で agent を走らせる
必要な権限だけを短命 token として渡す
secret へのアクセスをログに残す
評価が上がるほど、実行基盤の重要性も上がる
GPT-5.6 Sol のようなモデルが出ると、どうしてもベンチマークの順位に目が行きます。
もちろん、それは重要です。Terminal-Bench、CVE-Bench、HealthBench のような評価で強くなることは、実用性に直結します。
ただ、ランキングの首位は長く続きません。Anthropic が上に行き、OpenAI が取り返し、また別のモデルが抜く。これは今後も続きます。
開発チームにとって本当に残る問題は、モデルの首位が変わっても使い回せる実行基盤です。
強いモデルを受け止める基盤があれば、モデルを差し替えても運用できます。逆に、実行基盤が弱いまま最強モデルだけを入れると、失敗したときに何が起きたのかわからなくなります。
AIエージェント導入で見るべきなのは、モデル名だけではありません。
どこまで読めるのか
どこまで書けるのか
どの操作で止まるのか
どのログが残るのか
どこまで戻せるのか
secret に触れる経路はあるのか
このチェックリストのほうが、実務では長く効きます。
まとめ
GPT-5.6 Sol は、強いモデルです。
しかし、強いAIエージェントをそのまま開発環境に入れるだけでは危険です。問題は、モデルが賢いかどうかだけではありません。賢いモデルが、どの権限で、どの環境に入り、どの操作を自動実行できるのかです。
これからのAI開発では、プロンプト設計と同じくらい、実行環境の設計が重要になります。
特に見るべきなのは、次の5つです。
- 権限境界
- 確認ポイント
- 監査ログ
- ロールバック
- secret 管理
モデルが強くなるほど、開発者の仕事は「AIにどう書かせるか」から、「AIが安全に動ける作業場をどう作るか」へ移っていきます。
GPT-5.6 Sol の system card は、その変化をかなりはっきり示していると思います。
参考
AIウォッチでは、AIエージェント、RAG、開発者ツール、AIインフラの変化を、実装と運用の観点から追っています。