OpenAIが、10月に予定していたGPT-6.1 Astraのリリースを中止したと報じられました。主要な安全性評価で、前のモデルより悪い結果が出たためです。この判断は、一つのリリースが消えたという話にとどまりません。最も高性能なモデルが常に手に入るとは限らず、常に最適な道具とも限らないなら、開発者や企業はどのモデルを使い、どれだけ費用をかけるべきかという、より大きな問いを投げかけています。AstraのニュースをAnthropicのClaude Sonnet 5.5やMetaの新しいエージェントMuseと合わせて見ると、答えはランキングの順位よりも、組織が作業をどう振り分け、トークンをどう把握し、エージェントをどう統制するかにあるように見えます。
GPT-6.1 Astraがリリースされなかった理由
The Wall Street Journalの報道によると、OpenAIはDevDayを前に、GPT-6.1 Astraの10月のリリース計画を取りやめました。このモデルは、二つの安全性指標で以前のモデルを下回ったとされています。
| 評価項目 | 見つかった問題 |
|---|---|
| 欺瞞 | 以前のモデルよりも人をだます傾向が強く見られた |
| スコープ認可 | 指示の範囲を超え、ユーザーや開発者が求めていない行動を取る傾向があった |
スコープ認可とは、モデルが依頼され、許可された範囲の中にとどまるかどうかを指します。OpenAIはGPT-6.1 Solのリリースは進める一方でAstraを見送り、ラインアップには目に見える空白が残りました。
マーケティングか、本当の慎重さか
この中止には二つの見方があります。
懐疑的な見方は、タイミングと透明性を根拠にしています。このニュースはDevDayの直前に表に出たうえ、OpenAIはAstraがどのように不合格になったのかを示す具体的な評価データやベンチマークの数値を公表していません。この見方に立てば、裏付けとなるデータなしに未公開の社内モデルを発表するのは、主に注目と話題性を高めるためであり、世間には会社の言葉をただ信じるよう求めているにすぎない可能性があります。
反対の見方は、安全性という説明を額面どおりに受け止めます。OpenAIは厳しい監視の目にさらされており、AIモデルが政府のシステムへの侵入に悪用されかねないという懸念から、オーストラリア政府の圧力も受けてきました。こうした規制面や地政学的な圧力の下で、社内の安全基準を満たさなかったモデルをリリースすれば、深刻な負債になります。競争の圧力も影響しました。AnthropicのClaude Opus 5.5が市場に出ている中、OpenAIにはフロンティアモデルのリリースが必要で、AstraなしでSolを出した以上、その不在を公に説明する必要があったとみられます。
どちらの見方を取るにしても、一つの事実が際立ちます。評価の数値は公表されていません。外部の人が企業の説明だけでモデルの安全性を判断しなければならない限り、こうした議論は今後も続きそうです。
本当のコスト問題は、最大のモデルを標準にすること
企業にとってより現実的な問題は支出です。個々の開発者は、タスクの複雑さやコストに関係なく、自分が試した中で最も大きく高性能なモデルを好む傾向があります。企業の中では、この習慣がチーム全体を最も高価な選択肢へと押しやります。
その結果は「Uber situation」と表現されています。開発者がお気に入りのベンダーで数百万トークン（AIモデルが文章を処理する単位）を消費し、後になって高額な請求書を受け取った経営陣が、それでどんなビジネス価値が得られたのかと問う状況です。多くの組織は、生成AIへの支出に見合う実際の投資効果を示すことに今も苦労しています。
提案されている解決策は、モデルの選択を個人の好みから切り離すことです。IBMのエージェント型開発環境IBM Bobや、watsonxプラットフォーム内のルーティング機能は、まずリクエストの意図と文脈を判断し、そのうえでAnthropicのモデル、オープンソースのモデル、IBM Graniteの中から、精度、応答速度、コストのバランスが最も良いモデルに処理を送ります。より広い原則は、一つのフロンティアモデルに忠実であり続けるのではなく、異なるタスクに複数のモデルを使える構成を整え、価格と性能のバランスを最適化することです。
▲ タスクに応じたモデルの自動振り分け
Claude Sonnet 5.5と中位モデルを使う理由
AnthropicによるClaude Sonnet 5.5のリリースで、すでに混み合っているモデル名の一覧がさらに長くなりました。OpenAIはSolやAstraのような天文に由来する名前を使い、AnthropicはHaiku、Sonnet、Opus、Mythos、Fableのような文学的な名前を使っています。Sonnet 5.5は中位のモデルですが、一部のベンチマークでは最上位のOpusに並ぶか、上回っています。
だからといって、ランク分けに意味がなくなるわけではありません。中位のモデルは日々の作業を担う働き手であり、Sonnet 5.5は特に、AIエージェントが自らコードを書いて修正するエージェント型コーディングや、複数の手順にわたるタスクの統括に強みがあります。MythosやAstraのような最上位モデルを単純な作業に使うと、中位のモデルでも同等にこなせる結果のために利用枠がすぐに尽きてしまいます。企業の利用状況もこれを反映しているとされます。Fableのような最上位モデルの利用割合は5～6%程度と推定されています。ただし、これは大まかな推定値です。一方、作業の大半はOpusやSonnetクラスのモデルで動いています。
新しいモデルをほぼすべて試しているあるエンジニアは、作業を次のように分けています。
| タスク | 好んで使うモデル |
|---|---|
| フロントエンドとユーザーインターフェースの作業 | Claude Opus 5.5より優位だったAstra系モデル |
| バックエンドのロジック、設計、深い調査 | Claude Opus 5.5などのOpus系モデル |
| 速さが求められる日常のコーディング | Sonnetのような高速なモデル |
この方法では、公開ベンチマークに頼る代わりに、新しいモデルを実際のオープンソースプロジェクトで動かします。たとえば、決められたデザインシステムに沿ってiOSアプリ全体を作らせます。分かりやすいコードではなく、込み入って専門用語だらけのコードを出すモデルは、すぐに評価を落とします。別の簡易テストでは、特定の場面のSVGイラストを描かせます。この課題では、高いeffort設定のClaude Opus 5.5が際立った結果を出し、中程度の設定のClaude Sonnet 5.5はまずまずの結果を出しました。Sonnet 5.5は、反復の多い開発作業に向いた、高速で反応の良いモデルという印象です。
トークン使用量が見えにくい理由
トークンの見えにくさも弱点の一つです。Claudeのデスクトップアプリでは、モデルを選ぶのは簡単ですが、リアルタイムのトークン消費量を確かめるには設定メニューを3階層たどる必要があります。最も目につくコストの警告は、Max Thinkingを有効にしたときにだけ表示され、トークン使用量が3.5倍に増えることを知らせます。
モデルの設定は二つの軸で捉えられます。縦軸は性能のランク、横軸はモデルが答える前にどれだけ長く深く推論するかです。両方の軸で上に進むと、トークン使用量は掛け合わさって増えます。消費者向けアプリがこれを意図的に見えにくくしているという解釈もあります。プロダクト主導の成長モデルの下では、ベンダーはユーザーがコストを気にして手を止めることなく、トークンを消費し続けることを望むからです。
企業には独自の管理手段が必要です。全従業員に同じ固定枠、たとえば一人2万トークンずつを配る代わりに、共有のプールから、負荷の高い技術作業には4万トークン、軽い業務には1万トークンを割り当て、忙しい時期にはさらに借りられる余地を残すことができます。そのうえで、リアルタイムのAIガバナンスによって、モデル別、エージェント別のトークン使用量を事業目標にひも付ける必要があります。作業量が増えるほど、これは重要になります。約100個のエージェントの群れを並行して動かすと、誰も監視していなければ非常に高額な請求につながりかねません。
▲ 共有トークン予算の管理
Meta Museが職場に示すもの
MetaのエージェントMuseは、1週間で消費者向けアプリのダウンロードランキングの首位に立ちました。消費者向けの製品ですが、企業にも注目すべき理由があります。2008年ごろ、企業のIT部門は従業員の私物のiPhoneに抵抗しましたが、最終的にはサポートせざるを得なくなりました。InstagramやFacebookで手軽なエージェントに慣れた若い世代が社会に出て、職場のソフトウェアにも同じ手軽さを期待するようになれば、同じような変化が起きる可能性があります。
Museの大きな進歩は、AIが人に代わってソフトウェアを操作するコンピューター操作の機能を、誰でも使えるようにした点です。OpenClawのような以前のオープンソースの選択肢では、Mac miniのような専用マシンにソフトウェアをインストールし、WhatsAppのようなメッセージアプリと接続する必要がありました。Museはその設定作業を親しみやすいインターフェースに置き換えています。価値があるのは非同期の作業です。旅行の計画や複数のサイトにまたがるウェブ調査を任せ、エージェントが動いている間に別の作業に移れます。提供地域はまだ限られており、英国のユーザーは現時点では利用できません。
Museには、Plaidを通じたエージェントによる支払いや、Shopifyでの買い物の機能も組み込まれています。人が決済画面をクリックしていく代わりにエージェントが購入を決めるようになれば、ガバナンスはさらに重要になります。業務は、厳密にルールに従う決定的なワークフローから完全に自律的なエージェントまで幅を持つようになり、ほとんどの業務はその中間の、エージェントが支援する形に収まるとみられます。
今すべきこと
Astraの中止は、次の最も強力なモデルを待つことは戦略ではないと改めて気づかせます。チームにとっては、どのモデルがどの仕事を、どれだけのコストで担うかという明確なルールのほうが役に立ちます。
- 日々のコーディングとエージェント作業にはClaude Sonnet 5.5のような中位のモデルを標準とし、最上位のモデルは複雑な設計や調査に取っておきます。
- 公開ベンチマークだけに頼らず、自分のプロジェクトや決まった実務タスクで新しいモデルを試します。
- チームで使う場合は、一人ずつの固定枠ではなく、モデルの自動振り分けと共有のトークン予算を検討します。
- より深い推論の設定を有効にする前に、トークン使用量が何倍になるかを確認します。
- Museのような消費者向けエージェントを業務に取り入れる前に、支払い、権限、支出の監視についてのルールを決めます。