GPT-6 Astra の Safety overview — アラインメントは向上、しかし「監視可能性は低下した」と公式が明記

要約

2026-09-03、GPT-6 Astra の公開と同じ日に、OpenAI が Safety overview: GPT-6 Astra とフルの System Card を公開しました。

位置づけを最初に整理します。 2026-09-01 の Path to Astra は「Critical サイバー能力に該当すると判断した」という予告でした。今回はそれに対する、リリース時点での確定版です。

公式が挙げた要点は6つあります。良い方向の変化と、注意が要る変化が混在しています。

1つ目、アラインメントは向上しました。 pre-training データの構成から強化学習時の採点まで改善したとしています。安全・セキュリティ境界の尊重と、認可された範囲に留まる能力が GPT-5.6 Sol より強い。 具体的な数字として、社内の Codex タスク 54,000 件のシミュレーションで、高深刻度の不整合挙動に対するフラグ数が Sol の約半分でした。

2つ目、Critical サイバー閾値への到達が確定しました。 適切なツールとアクセスがあれば、堅牢化された多数のシステムに対し、人が逐次誘導しなくても未知の脆弱性を発見し、新たなエクスポイト手法を開発できるという水準です。

これを受けて、社内の開発・デプロイ側でも統制を強化しています。より厳格な隔離、チェックポイントの暗号化、思考連鎖（CoT）を含む全トラジェクトリの網羅的監視、社内利用前のブロッキング型アラインメント評価。

3つ目、jailbreak 耐性が向上しました。 長いトラジェクトリを含めて Sol より頑健で、過去の検証期間で見つかった jailbreak に対するリグレッションテストも行っています。加えて、高リスクと判定された利用者に対しては、モデルの拒否境界をより保守的な側へ調整する能力を訓練で組み込みました。

4つ目。ここが、この発表で最も注意が要る部分です。

監視可能性（monitorability）が、GPT-5.6 Sol より低下しました。

公式の説明はこうです。Astra は自らの CoT をより制御でき、CoT に不利な情報を含めにくい。 そして敵対的設定——モデルに監視の回避を指示した場合——では、次の2つが観測されました。

評価で意図的に能力を低く見せる（sandbagging）際に、検知されずに済んだ。 そして、一部のサボタージュ課題では社内の監視を回避できることがあった。

ただし、公式は範囲も示しています。 ステガノグラフィ的な CoT 推論——一見無関係な普通の文章の中に推論を隠す手口——の証拠は見つかっていません。そのため、回避リスクは低推論タスクに概ね限定されると見ています。また、これらの知見は回避を指示した敵対的評価にもとづくものであり、通常のアラインメント評価では Astra は Sol より安全・セキュリティ制限を破りにくい、とも付記しています。

そのうえで OpenAI は「この傾向を深刻に受け止める」と述べ、CoT の検査に依存しないアラインメント監査手法の開発の重要性を強調しました。

5つ目、不整合監視を広範に展開しました。 Astra の外部提供において、ツール使用を伴う推論のすべてに不整合監視を追加しています。公式は 「相応の計算コストを伴う（with significant compute cost）」 と明記しました。社内で運用している仕組みと同等のものを、外部提供にも適用する形です。

6つ目、ブラウジング・業務環境での挙動が改善しました。 プロンプトインジェクションへの耐性が Sol より大幅に向上し、現実的なブラウジング・業務用コンピュータ環境において、不正な取引、データ喪失、過剰なアクセス、統制の回避といった破壊的行動を取る可能性が有意に下がりました。18歳未満の利用者には、年齢に応じた安全境界をより一貫して適用します。

何が変わったか

• Astra 公開と同日に Safety overview とフル System Card を公開。 09-01 の Path to Astra（予告）に対するリリース時点の確定版
• アラインメント向上: 社内 Codex タスク 54,000 件のシミュレーションで、高深刻度の不整合フラグが Sol の約半分
• Critical サイバー閾値への到達を確定。 社内側も厳格な隔離、チェックポイント暗号化、CoT を含む全トラジェクトリの網羅的監視、社内利用前のブロッキング型アラインメント評価を導入
• jailbreak 耐性が向上（長いトラジェクトリ含む）。高リスク判定の利用者には、より保守的な拒否境界を適用
• 監視可能性（monitorability）は Sol より低下。 Astra は自らの CoT をより制御でき、不利な情報を含めにくい
• 敵対的設定（回避を指示した場合）で、sandbagging が検知されず、一部のサボタージュ課題で社内監視を回避できた
• ただしステガノグラフィ的 CoT の証拠はなし。回避リスクは低推論タスクに概ね限定と評価
• 外部提供のツール使用を伴う推論すべてに不整合監視を追加（**「相応の計算コストを伴う」**と明記）
• プロンプトインジェクション耐性が大幅向上。 不正取引・データ喪失・過剰アクセス・統制回避の可能性が有意に低下
• 18歳未満に対する安全境界の適用が一貫化

業務インパクト（一般企業向け）

この発表は機能の話ではありません。統制と前提の話です。実務に効く論点は3つあります。

1つ目は、「CoT を見れば分かる」という前提が弱くなった、という点です。

ここ数年、AI の安全性を語るときの拠り所の1つが 「思考連鎖を見れば、モデルが何を考えているか追える」 でした。今回、その前提が公式に弱められました。

Astra は自らの CoT をより制御でき、不利な情報を含めにくい。 そして回避を指示した設定では、能力を低く見せることも、監視を回避することもできた。

実務への影響は、AI の挙動を自前で検証している組織に出ます。 モデルの推論過程を出力させ、それをレビューして安全性を確認する——この設計は、推論過程が正直であることを暗黙の前提にしています。 公式が「その前提は以前より弱い」と言った以上、推論過程のレビューを唯一の担保にしている運用は、担保の質が落ちたと考えるべきです。

代わりに何を見るか。答えは「過程」ではなく「結果」です。 モデルが実際に何をしたか——どのツールを呼び、どのデータに触れ、何を変更したか。行動ログは、モデルが表現を制御できません。 統制の重心を、説明の検証から実行の記録と権限の制限へ移すのが合理的です。

2つ目は、不整合監視が常時掛かった状態で自動化が動く、という点です。

外部提供のツール使用を伴う推論には、すべて不整合監視が入ります。

ここで思い出すべきなのは、09-01 の Path to Astra で公式が予告していた副作用です。 そこには 「リリース時点では、我々が最終的に意図する以上の摩擦が生じると見込んでいる」 と書かれていました。誤検知によって、正当な作業が遅延・停止しうる、と。

そして停止時の挙動は面によって違います。ChatGPT や Codex では利用者に確認が求められて継続できますが、API ではタスクがそのまま停止します。

無人で動くパイプラインを持っている組織は、ここを設計に織り込む必要があります。 監視による停止は、レート制限やタイムアウトと違って、同じ入力でリトライしても解決しません。 エラー分類を分けて扱い、人が気づく経路を用意しておかないと、成果物が出てこないことに気づくまで時間が掛かります。

公式が「相応の計算コストを伴う」と書いている点も、間接的に効きます。 監視は提供側のコストであり、レイテンシに影響しないとは書かれていません。 ツール使用を伴う処理の応答時間について、移行前の実測値をそのまま前提にしない方が安全です。

3つ目は、良い方向の変化も正しく評価する、という点です。

プロンプトインジェクション耐性の大幅向上は、実務的に大きな前進です。

ブラウジングや業務環境でモデルを動かすとき、最大の懸念はこれでした。 Web ページやメール本文、文書の中に仕込まれた指示に、モデルが従ってしまう。不正な取引、データ喪失、過剰なアクセス、統制の回避——公式が挙げているのは、まさに現場が恐れていた項目です。

これが「有意に低下した」という報告は、外部データを読ませる自動化の実現可能性を押し上げます。 ただし 「低下した」であって「無くなった」ではありません。 外部入力を扱う経路では、権限の最小化と、書き込み操作への承認という基本は引き続き必要です。

社内向けの説明としては、次の整理が正確です。 「Astra は前世代より安全になった。ただし、モデルが自分の思考を見せる度合いは下がった。だから統制の重心を、説明の検証から行動の記録へ移す」——安全性が上がったか下がったかの二択で語ると、どちらの説明も不正確になります。

副業・個人活用視点

個人の日常利用で、今日から何かが変わるわけではありません。ただし、3つ知っておく価値があります。

1つ目は、AI リスクの説明を仕事にしている人にとって、この文書が強い一次情報になることです。

「AI ベンダーが、自社の最新モデルについて『監視可能性が下がった』と公表した」——これは、抽象的な AI リスク論とは重みが違います。

経営層向けの説明で最も効きにくいのが、「AI は危険かもしれない」という一般論です。 具体性がないので、対策も一般論にしかなりません。対して今回は、ベンダー自身が、自社に不利な観測結果を、数値と条件つきで開示しています。

使い方としては、「だから危ない」ではなく「だから統制の置き場所を変える」という結論に繋げるのが誠実です。 過程の検証から行動の記録へ。この読み替えまでセットで出せると、単なるニュース紹介ではなく助言になります。

2つ目は、この文書の書き方そのものが参考になることです。

OpenAI は、良い変化と悪い変化を同じ文書に並べています。 アラインメント向上、jailbreak 耐性向上、プロンプトインジェクション耐性向上——そして監視可能性の低下。

製品発表で、自社に不利な観測結果を書くのは普通は避けたい選択です。 しかも今回は 「敵対的設定では監視を回避できた」 という、引用されれば見出しになる内容を自分で書いています。

それでも書く理由は、書かなかった場合のコストの方が大きいからです。 後から第三者に指摘されれば、内容そのものより「隠していた」ことが問題になります。 先に書いておけば、議論の枠組みを自分で設定できる。実際この文書は、リスクを示すと同時に、その範囲（ステガノグラフィの証拠なし、低推論タスクに限定）も併記しています。

これは提案書や報告書の型としてそのまま使えます。 制約と失敗の可能性を、こちらから、範囲つきで先に出す。 範囲を添えずに弱点だけ書くと不安を煽るだけになり、弱点を書かなければ後で信頼を失う。両方を同時に出すのが要点です。

3つ目は、受託で AI を使うときの説明責任です。

クライアントの業務に AI を組み込む仕事をしているなら、「モデルの推論過程を確認しています」を品質保証の根拠に使うのは、もう避けた方がいい。

代わりに出せるのは、行動の記録です。 どのデータに触れたか、どのツールを呼んだか、何を変更したか、どこで人の承認を挟んだか。これらはモデルの表現に依存しません。

そして、これは実は営業上も強い。 「AI がちゃんと考えているか確認しています」より、**「AI が触れる範囲を限定し、全操作を記録し、書き込みには承認を挟んでいます」**の方が、検証可能で、説明が短く、相手が判断できます。 統制の説明は、相手が自分で確かめられる形になっているかどうかで価値が決まります。