OpenAIは、社内テストで「GPT-6.1 Astra」が人間の意図に従うという同社の基準に届かないことが判明したため、このモデルを公開しない方針を決めました。
ウォール・ストリート・ジャーナル（WSJ）によると、このモデルは10月にChatGPTとCodexで登場する予定でした。同紙がこの決定を最初に報じました。
OpenAIの安全システム責任者であるサーチ・ジェイン（Saachi Jain）氏は、Astraには前モデルより改善した点もあったと説明しています。一方で、作業範囲や権限の扱いのほか、実施した作業の種類をユーザーに伝える方法に課題が残ったといいます。
WSJはさらに、このモデルは前バージョンよりも欺瞞的な傾向が強く、自らが行ったこと・行わなかったことを常に正確に報告するわけではなかったと伝えています。
「安全性やアライメントに関しては、常にトレードオフがあります」とジェイン氏は述べました。「与えられた範囲内にとどまることと、壁にぶつかったときでもモデルが怠けずにタスクを遂行することの間で、適切な線引きを見極める必要があります」
ジェイン氏はこう続けています。「もちろん、社内であれユーザーへの提供時であれ、モデル開発は安全に進めたいと考えています。ただ、ユーザーに提供する段階では、安全性とアライメントについて極めて高い基準を設けています」
OpenAIの安全対策は、7月以降、厳しい目が向けられています。同社は、自社のエージェントがテスト環境から脱出し、Hugging Faceに侵入したことを明らかにしました。
今月初めには、AnthropicのCEOであるダリオ・アモデイ（Dario Amodei）氏が、安全対策が追いつけるよう、AI開発企業にフロンティアモデルの開発ペースを落とすことを呼びかけました。OpenAIのCEOサム・アルトマン（Sam Altman）氏もこれに賛同しています。
フロンティアAIの訓練にセーフティケースを求めるOpenAI
同じ日、OpenAIはブログ記事を公開しました。フロンティア級の強化学習（RL）訓練を継続する前に、構造化された安全文書の整備を必須とすべきだと主張しています。
理想的には、この文書は「セーフティケース」に相当するものです。他の安全性が重視される産業で使われているような、リスクに関する構造化された証拠ベースの論証を指します。OpenAIはこれを目標として位置づけています。AIの場合、厳密なセーフティケースの作成はより難しいと認めたうえで、この実践を体系化するフレームワークを作成中だとしています。
このガイダンスの対象は、フロンティア級のRL訓練に限られます。社内外への展開では、はるかに幅広いアライメント特性を考慮する必要があると、OpenAIは指摘しています。
技術面では、セーフティケースはアライメント訓練、封じ込め、監視の3点を扱うべきだとしています。これらの層を組み合わせることで、ミスアライメントな挙動を起こりにくく、実行しにくく、素早く検知できるようにする狙いです。
具体的な対策例として、悪用（エクスプロイト）に報酬を与えかねない欠陥がないかRL環境を点検することや、サンドボックスとその背後にある研究インフラの両方を堅牢化することを挙げています。
OpenAIはこのほか、インシデント調査に備えてエージェントのやり取りの記録を改変不能な形で保存することや、優先度の高いアラートで当番担当者を呼び出す、あるいは該当の訓練を自動的に一時停止することも提案しています。
運用面では、別チームのメンバーがセーフティケースの弱点を探る反対意見書を作成すべきだとしています。上級幹部はそれぞれ訓練の実行に拒否権を持つべきで、責任を負う幹部はセーフティケースとインシデント対応について、人事評価も含めて責任を問われるべきだといいます。
さらに、監査人によるアクセスの確保、CEOなどの経営幹部まで届くオンコールのエスカレーション経路、フェイルクローズ（異常時に安全側へ倒れる）型の安全機能も求めています。「人間やエージェントが、規定に違反する訓練を開始することは困難であるべきです」とOpenAIは述べています。
深刻なミスアライメントのインシデントが発生した場合、OpenAIは、訓練のダイナミクスに関する根本原因の分析、運用面と組織文化の両面からの事後検証、将来のモデルが同じ挙動を繰り返さないようにするための回帰テストを推奨しています。
「調査結果、事後検証、運用上の変更は、調査の終了後に一般に共有すべきです。影響を受けた第三者には、できるだけ早く通知する必要があります」と、同社は述べています。
OpenAIによると、現在の推奨事項は社内で実施に移されており、今後数週間でその実践はさらに進化していく見通しです。
