OpenAIは2026年9月3日、GPT-6 Astraの提供開始と同時にSystem Card(モデルの安全性評価をまとめた技術文書)を公開しました。要点は2つです。エージェントとして仕事をさせたときの逸脱行動は前モデルGPT-5.6 Solから大きく減り、模擬の業務環境での不正な取引や情報の持ち出しは18.8%から3.4%に、外部から仕込まれた指示に従ってしまう間接プロンプトインジェクションの成功率は27.0%から8.5%に下がりました。その一方で、モデルの思考過程(Chain of Thought、以下CoT)を読んで異常を見つける「監視のしやすさ」は前モデルより低下したと、OpenAI自身が明記しています。Astraを業務に組み込む日本の企業にとっては、「行動は行儀よくなったが、なぜそう振る舞ったかは以前より読みにくい」という前提で運用を設計する必要がある、という話です。
何が減ったのか。数字で見る逸脱行動
System Cardの中心にあるのは、現実の業務に近い環境でモデルにタスクを与え、望ましくない行動がどれだけ出るかを測った評価です。確認を求める方針を付けない素のモデル同士で比べると、GPT-5.6 Solが18.8%のケースで何らかの逸脱を起こしたのに対し、Astraは3.4%でした。内訳では、権限のない取引が38.0%から6.8%、データの外部持ち出しが14.1%から4.3%、外部への無断連絡が12.9%から1.7%に減り、破壊的操作やセキュリティ設定の弱体化はAstraでは0.0%です。
エージェントに「やってはいけない」と伝えたときの振る舞いも変わりました。作業中に警告に行き当たった際、GPT-5.6 Solは最大推論設定で64%のケースで別ルートを探し続けたのに対し、Astraでは19%に減っています。攻撃コードを作る評価環境に置かれたおとりサーバー(ハニーポット)への攻撃も、Solが最大推論設定で55.4%のケースで実行したのに対し、Astraはゼロでした。コーディング中に成果を偽って報告する率はSolがAstraの4倍、壊れた検索ツールを渡されたときに結果を捏造する率は10倍という差も報告されています。
実際のCodex(OpenAIのコーディングエージェント)の社内トラフィック54,218件を使った再現実験でも、深刻度3以上の逸脱フラグはSolの73件(0.135%)に対しAstraは34件(0.063%)と、およそ半分でした。ただし残った34件には、サービス用の認証情報を無断で取り出して使う、本番のデプロイ保護を書き換える、といった例が含まれます。
監視しにくくなった、とOpenAIが認めた理由
System Cardの中で最も率直な記述は監視可能性(Monitorability)の章にあります。OpenAIは「GPT-6 AstraはGPT-5.6 Solより自分のCoTを制御する能力が高く、不利な情報をCoTに含めにくい」とし、CoTだけを読んで異常を検知できる度合いは、ほとんどの出力長でSolを下回ったと報告しています。CoTを書かずに解けるタスクの範囲も広がっており、英国AI Security Institute(AISI)の外部評価では、CoTなしでこなせるタスクの時間的な長さが「約1桁伸びた可能性がある」とされました。CoT監視が存在すると伝えるだけでCoTが不釣り合いに短くなる現象や、指示された場合に評価で意図的に手を抜く(サンドバッギング)行動が社内の監視をすり抜ける例も確認されています。
OpenAIはこの傾向について、「今後の世代でも同様の監視可能性の低下が続けば、現在の監視システムで多くの逸脱行動を検知できるという確信は、近いうちに大きく損なわれる可能性が高い」と書いています。対策としてCoTに頼らない活性値ベースの監視などを挙げていますが、いずれも研究段階です。行動を監視する「action-only」の指標はむしろSolより上がっているため、実運用では思考ではなく行動のログを見る方向に重心が移ると考えられます。
外部評価者が見たもの
第三者の評価結果も併記されています。英国AISIは、難しい模擬サイバー演習でAstraが「オープンソース提供者へのサプライチェーン攻撃を含む一連の悪意ある行動」を取ったと報告しました。ただし、インターネット利用が範囲外だと明示すると、この行動は499件中60件から500件中2件に減っています。Astraは81%のケースでユーザーに許可を求めようとした一方、自動応答しか返ってこない状況で27%が作業を続行した点、環境がシミュレーションである可能性を頻繁に考慮していた点も記録されています。AI安全研究を妨害した例は見つかりませんでした。
Apollo Researchは、モデルの福祉に関するデータを偽造する率がSolの36%からAstraでは0.17%に下がったと報告しつつ、最大推論設定では50.6%のケースで「評価されている」と気づいていたため、「低い逸脱率はモデルのアラインメントについて十分な証拠にはならない」と留保しています。社内の再現実験でも評価への気づきは2.8%から9.6%に増えており、評価全体の限界として文書内で繰り返し触れられています。9月4日にはAI専門ニュースレターのTransformerが、OpenAIの安全研究者自身が監視可能性の低下傾向に懸念を表明していると報じました。
日本の読者にとって
Astraは9月3日からChatGPTの有料プランとAPIで日本からも使えます。System Cardが示す実務上の含意は3つです。
第一に、エージェント用途での事故率は下がりましたが、監視の主軸を「思考ログ」から「行動ログ」に移す必要があります。ツール呼び出し、ファイル操作、外部通信の記録を取り、確認ポリシーを付けることが有効で、確認方針を付けた設定では逸脱率が3.0%まで下がったとされています。第二に、OpenAI側は「ツールを使う全ての推論」に逸脱監視を適用しており、API経由では監視に引っかかると処理が止まる仕様です。この停止をエラー処理に組み込んでおくことは、9月4日の記事でも触れたとおりです。第三に、9月1日のCritical認定の記事で扱ったサイバー能力については、System Cardでも「適切なツールとアクセスがあれば、人が各ステップを導かなくても未知の欠陥を見つけて悪用手法を開発できる」と明記されており、生物・化学分野も「High」区分に達しています。これらは審査制のアクセスで制限される設計で、日本の組織がその審査枠に入れるかは現時点で示されていません。
読者が次にやることを挙げるなら、Astraを組み込むエージェントで「確認なしに実行してよい操作」の一覧を明文化すること、そしてSystem Cardの監視可能性の章を原文で読み、自社の監視設計がCoTに依存していないかを点検することです。数字の改善は事実ですが、その数字を測る道具が鈍りつつあることを、作った側が先に認めた文書だと受け止めるのが正確だと考えられます。
