CONTACT →
Daily AI Briefing
毎日のようにAI関連のニュースが届きますが、その多くは一次情報ではなく、ノイズも少なくありません。研究機関・開発企業・第一線の専門家による発信の中から、本当に押さえておきたい情報だけを厳選してお届けします。
Anthropic が新しい Claude 5.5 ファミリーの最初のモデルとして Claude Opus 5.5 を発表した。多くのタスクで Claude Fable 5.1 と同等の性能を発揮し、実行コストは Opus 5 より40%低いという。
「Fable 級の性能を Opus 5 より安く」という位置づけ。コスト面で Opus 5 を使っていた処理は、そのまま置き換えを検討する価値がある。
Claude Developers によると、Opus 5.5 はタスクあたり Opus 5 より約30%速く、約40%安い。Claude Code では同日から5時間セッションの上限が20%引き上げられ、Opus 5.5 の価格が下がったぶん上限内で25%多く使えるようになる。Pro・Max・Team のユーザーには、任意のタイミングで使える利用量リセットが1回付与される。
モデル更新と同時に上限の実質引き上げが入るのは実務上ありがたい。長時間のエージェント実行を Claude Code に任せている人は、上限の当たり方が変わるはず。
Anthropic は、Opus 5.5 が同社が「フロンティアのペースを調整すべき」と呼びかけて以降で初めてのモデルだと説明している。これまでのモデル同様、METR や Frontier Design などの外部評価機関によるテストを公開前に受けた。同社の最も包括的なアライメント評価では、これまでで最高のスコアを記録したという。
性能とコストの話に隠れがちだが、外部評価の体制と結果を毎回明示するのは一貫している。エージェントに任せる範囲を広げるほど、この種の情報が判断材料になる。
OpenAI Developers が GPT-6 ファミリーの新モデル Sol と Luna を発表した。いずれも同日から利用でき、API 価格は GPT-5.6 より50%低い。「Sol で作り、Luna でスケールさせる」という位置づけで、Greg Brockman は Astra の高い性能を支える技術を、より速く手頃なモデルに持ち込んだものだと説明している。
Anthropic と同じ日に、こちらも「フロンティア級を安く速く」の方向。2社が同時に値下げしたことで、API 費用の前提が一段下がった。
OpenAI が GPT-6 向け API のプロンプトキャッシュを改善した。デフォルトでキャッシュヒット率が上がり、より多くの入力トークンに最大90%のキャッシュ割引が適用される。あわせて platform.openai.com に Prompt Caching Dashboard が加わり、何が再利用され何がヒットを妨げているかを確認できる。診断 API では、再利用を妨げた変更の特定と影響トークン数の見積もりが可能になった。
エージェントはシステムプロンプトとツール定義が毎ターン繰り返されるので、キャッシュの効き方がそのままコストになる。ヒットを壊している変更を可視化できるのは実用的。
Ethan Mollick は初期テストで Opus 5.5 を「良いモデル」と評価し、Fable でも Astra でもないモデルとして初めて Fable 級に感じたと述べている。一方で、最近の Claude に見られる「文章が密になりすぎる」問題はまだ完全には解消されていないという。同じシェーダー課題を解かせた出力も公開している。
公式ベンチと別に、いつも同じ課題で比べている人の所感は参考になる。文体の癖はプロンプトで調整できる範囲かどうか、自分の用途で確かめたい。
Google Colab が Google AI プランの一部になった。加入者は高速なアクセラレータと高性能マシンに優先的にアクセスでき、Ultra ユーザーはさらに長時間のバックグラウンド実行と Premium GPU も利用できる。
Colab Pro を別契約していた人は、Google AI プランに寄せるかどうかの判断が必要になる。長時間のバックグラウンド実行は学習ジョブを回す用途でありがたい。
DeepLearning.AI が、1万体の AI エージェントが88時間をかけて Navier-Stokes 方程式に Lean で取り組んだ事例と、そこから生まれた論争を取り上げている。エージェントは複雑な数学的証明を大規模に形式化できる一方、その証明がなぜ機能するのかを解釈するには人間の評価が依然として不可欠だとまとめている。
「形式的に通る」と「人が理解して受け入れる」は別物、という話。エージェントの大規模並列は出力量を増やすが、検証と解釈の側がボトルネックになる。
PyTorch Foundation のケーススタディで、Shopify が GraphQL エージェント向けに PyTorch と vLLM を使った継続学習ループを構築した事例が紹介されている。フロンティアモデルは AI プロダクトを最速で立ち上げる手段だが、利用が拡大したときにどうするかという問いに対し、日々の本番での失敗を学習に回す仕組みで答えている。
「まずフロンティア API で出し、スケールしたら自前モデルに寄せる」の具体例。本番の失敗ログを評価と学習の両方に使う設計は、規模が小さくても参考になる。
Hamel Husain が評価 FAQ の一項目として、正解データセットが陳腐化したときの対処を示している。答えは、定期的なエラー分析で新しい問題を見つけ、プロダクトとユーザーの変化に合わせて評価を更新し続けること。
評価セットは一度作って終わりではなく、本番の失敗から継続的に補充するもの。上の Shopify の事例とも通じる考え方。
Ethan Mollick は、知識労働の工業化は肉体労働の工業化と同程度に破壊的な変化になると述べている。かつてと同じように、職人的だった分野は、その仕事を面白く意味あるものにしていた技巧を減らしながら、標準化された成果物を大量に生産する圧力にさらされるという。
コーディングも例外ではない。自動化には型があるが、人の技巧を活かす「拡張」には型がないので、そこを設計するのは開発者側の仕事になる。
こうした動きを、自社の業務にどう活かせばいいか ―
迷ったときに相談できる窓口があります。