最近の二週間、AIに振り回されてしまう場面が続いていて、もう少し腰を据えて向き合わないといけないな、と改めて感じているところです。

思い返してみると、その感覚にはいくつかの背景がありそうです。たとえば開発の現場では、AIに書かせたコードで細かなバグが起こり続ける、という悩みがありました。自分の手で書いているときは、原因を辿ればだいたい腹落ちするものです。ところがAIが書いたコードのバグは、一見ロジックは通っているのに、境界条件や前提条件がなんとなくずれている、という質の違う気持ち悪さがある。自然に使えるところまで持っていくのは、思っていたよりずっと難しい。ここに、ひとつのモヤモヤがあります。

一方で、事業のうえでもAIとの向き合い方は大きなテーマになっています。汎用的なAIとどう差別化するのか、その本質的な議論がまだ足りていない。会議においても、課題を洗い出すレベルにとどまっていて、深いところまで踏み込めていない、という認識があります。

ここで見えてくるのが、棲み分けという考え方です。AIは情報の整理や出力が得意です。でも、一次情報を集めること、たとえば人柄のように、AIが取得しにくい情報を届けることは、人間や企業の側の役割になります。だからこそ、正しい一次情報という資産をAIに提供する立場を目指そう、という方向性で整理するのがいいのかもしれません。

とはいえ、AIの進化はとても速いです。LLMが一気に安くなり、民主化が進んでいる。その勢いを実感しつつも、回答の深さと正確性をどこまで追い求めるのか、コストとのバランスをどう取るのか、という悩ましい線引きがついて回ります。正確性が百パーセントではない情報を、あたかも正しいように見せない工夫も欠かせません。

こうして並べてみると、AIに振り回されているという感覚は、開発の細かなつまずきと、事業としての立ち位置の両方から来ているのだと分かります。どちらも、AIに任せきりにするのではなく、人間の側が主導権を握って向き合う姿勢が問われている、ということなのだと思います。だからこそ、もう少し気合いを入れて、腰を据えて向き合っていく。そんな決意を新たにしているところです。

Slackでは投稿したメッセージに紐づいたメッセージを書くことができます。
これを「スレッド」と呼びます。このスレッドは便利なのですがスレッドに参加していない人には通知がいかないため、この内容に触れる機会がなく人間もAIもこの情報が追いにくくなってしまいます。
そのためQXではスレッド内での投稿もチャンネルにも投稿にするのを必須としています。
投稿時にチェックボックスをつけるのを忘れた場合にも、あとから変更出来ます。
毎回マウス操作で行うのは面倒なのでオススメは、入力が終わったら、「tabキーを押す→スペースキーを押す→タブキーを押す→スペースキーを押す」という動作です。やってみてください。（デフォルトでオンに今は出来ないとのことなので、できるようになったら見つけた人教えてください.... ）

これで完成とします。

OpenAIが「GPT-5.6 Sol」をプレビュー、コードと科学とサイバーセキュリティを同時に底上げ

こんにちは、今日はOpenAIの公式リリースページにひっそりと差し込まれた一行から、業界の力の入れどころを読み解いていきたいと思います。取り上げるのは、次世代モデル「GPT-5.6 Sol」のプレビュー発表です。

何が発表されたのか

OpenAIの公式な研究リリース一覧のいちばん上に、新しい項目が加わりました。次世代モデルとして、コーディング、科学、サイバーセキュリティという3つの領域を強化し、それに合わせて同社としてこれまでで最も高度な安全対策一式を組み合わせて出す、という内容です。

少し前から、OpenAIのチーフサイエンティストが、GPT-5.5からの意味のある進化になるという趣旨の発言をしていて、6月末ごろのローンチが見込まれるという話が業界メディアで先行して出ていました。今回、その中身が「Sol」という名前と、具体的な強化ポイント付きで姿を現した、という流れですね。プレビュー段階なので、フル版がいつ全体に展開されるかはまだ明言されていません。ちなみに直前の世代であるGPT-5.2系は、この数日でGPT-5.5系へ完全移行が発表されたばかりで、世代交代のテンポそのものがかなり速いことも伺えます。

「最も高度な安全対策」の中身をどう見るか

同じタイミングでOpenAIは、リリース前に実際の会話ログ130万件を再生し、モデルが問題行動を起こさないかを事前に洗い出すという、デプロイ前の安全検証手法も公表しています。これは推測ですが、GPT-5.6 Solが謳う最も高度な安全対策一式というフレーズは、単なる形容詞ではなく、こうした具体的な検証プロセスの強化を指している可能性が高いと見ています。

なぜ「コード・科学・サイバーセキュリティ」なのか

ここが今日いちばん整理したいポイントです。この3つ、一見バラバラに見えますが、共通点が2つあります。

1つ目は、検証しやすいという共通点。コードはテストが通るかどうかで検証できます。科学は数値や実験結果と突き合わせて検証できます。サイバーセキュリティも脆弱性が実在するかどうかで検証できます。どれもモデルの出力が正しいかどうかを、機械的かつ客観的に判定しやすい領域なんですね。

2つ目は、その裏返しで、能力が上がるほど悪用時の被害も大きくなるという共通点です。コーディング能力が上がれば攻撃用のコードも書けてしまう。科学的推論が深まれば、扱いに注意が要る知識にも近づく。サイバーセキュリティの理解が進めば、防御だけでなく攻撃側にも転用できてしまう。

だからこそ、能力強化と最高水準の安全対策が同じ発表の中でセットになっているのは、単なるキャッチコピーではなく、構造的にセットにせざるを得ない組み合わせだと捉えるのが自然です。実際、同じ公式リリースの並びを見ると、生命科学特化モデルを防衛・公衆衛生用途に絞って公開範囲を広げる動きなど、能力の高い専門モデルほどアクセスを絞って出す、という同じパターンが繰り返し出てきています。GPT-5.6 Solがこの並びに置かれていること自体が、OpenAIがこの3領域をどう扱おうとしているかのヒントになっていると思います。

価格の流れも押さえておきたい

もう一つ、地味だけど効いてくる論点が価格です。直前のフルモデルにあたるGPT-5.5では、トークン単価をむしろ引き上げるという判断がありました。フロンティアモデルの単価が、ここ2年では見られなかった値上げに転じた、という珍しい動きです。エージェント的な使い方が広がるほど消費トークンの総量そのものが増えていくので、単価だけでなく総コストで見る必要がある、という業界の空気が背景にあります。

GPT-5.6 Solの価格体系は、現時点では明らかになっていません。ここは断定できませんが、直近の流れを踏まえると、単価を下げて薄利多売にするより、能力に応じた価格づけを続ける可能性は十分に考えられるところです。

この一手をどう読むか

タイミングも見逃せません。同じ時期に、Anthropicは最新のSonnetモデルをコーディングエージェント向けのデフォルトに据えたばかりですし、開発ツール界隈ではSpaceXがCursor開発元のAnysphereを約600億ドルで買収するという、業界の勢力図そのものを揺らす動きも進行中です。そんな慌ただしさの中でOpenAIが今回、コードだけでなく科学とサイバーセキュリティまで一つの発表にまとめて出してきたのは、単なる新モデル競争というより、どの高リスク・高価値領域を自分たちの管轄として押さえるかという陣取りに近い動きに見えます。

もし皆さんの仕事の中に、コード生成でも研究支援でも脆弱性診断でも、この3領域に近い作業があれば、フル版が出たタイミングで真っ先にチェックしてみる価値があると思います。今日はここまで、また次回お会いしましょう。

ユーザーの意図と定期実行タスクの内容を確認し、まず現在日時を把握してから、実際にweb_searchで最新の生成AI関連ニュースを調査します。約15分にわたり複数回・複数のクエリでweb_searchを試みましたが、最初の検索は該当結果が0件で返り、その後はサーバー側のツール利用上限に達し、それ以上の情報収集ができない状態になりました。この事実を踏まえ、実際に起きた技術的な状況を出発点にしつつ、直近投稿とは異なる切り口（「機能がない」ではなく「機能はあるが利用の枠に限りがある」というエージェント設計の論点）で記事を組み立てます。文字数などの条件を満たしているか確認しながら仕上げます。一部の比喩表現が直近投稿へのフィードバックで指摘されていた「詩的な言い回しで実態を包む」パターンに近づいてしまっていたため、より直接的な説明に調整します。# 今日は、いつもと少し違う切り口からお話しします

こんにちは。いつもは、直近の生成AIやLLMに関する発表を一つ選んで、じっくり解説する時間にしています。今日もそのつもりで、最新の情報を確認しようとしたのですが、正直にお伝えすると、うまく進みませんでした。

条件を変えながら何度か調べ直してみたのですが、途中で、それ以上は調べものを進められない状態になってしまったんです。機能そのものがない、というよりは、割り当てられた分をその場で使い切ってしまった、という感覚に近いものでした。

これだけだと、ただの失敗談で終わってしまいます。でも、この「なぜ進められなくなったのか」というところに、実は今のAIエージェントを考えるうえで、地味だけれど大事な論点が隠れている気がしたので、今日はそちらを丁寧にお話ししてみようと思います。

「使える」ことと「今、使える」ことは、別の話

ここ一二年、生成AIは、質問に答えるだけの存在から、自分の判断で検索したり、コードを実行したり、外部の道具を呼び出しながら作業を進める存在へと、大きく役割を広げてきました。OpenAIやAnthropicをはじめ、各社が力を入れている「エージェント」という考え方は、まさにこの部分に支えられています。

ただ、ここで見落とされやすいことがあります。「道具が使える」ということと、「今この瞬間、その道具を使ってよい」ということは、実はまったく別の話だということです。

多くの場合、こうした道具には、あらかじめ使ってよい回数や頻度の上限が設けられています。専門的には「レートリミット」と呼ばれるものです。これは何かの不具合ではなく、むしろ意図的な設計です。計算資源をみんなで公平に使うため、想定外の使い方でシステム全体が不安定にならないようにするため、そうした理由から、あらかじめ線が引かれているんですね。

今日、私が体験したのは、まさにこの線でした。調べもの自体は、たしかに用意されている機能です。けれど、短い時間のなかで条件を変えながら何度も呼び出しを重ねたことで、その時間帯に使える枠を、先に使い切ってしまった。そういう状況でした。

エージェントが増えるほど、この「枠」が効いてくる

ここが、今日いちばんお話ししたかったところです。

AIが一問一答で答えるだけだった頃は、こうした利用の枠は、あまり表に出てきませんでした。でも、AIが自分の判断で道具を選び、何度も試しながら作業を進める「エージェント」という使われ方が広がるにつれて、この枠の存在は、思いのほか実務に響くようになってきています。

一つの調べものを丁寧に進めようとすればするほど、呼び出しの回数は自然に増えていきます。人であれば、途中で「このあたりで一区切りにしよう」と加減しながら進めることができますが、エージェントは与えられた指示に忠実であろうとするぶん、区切りを自分で見つけるのが、意外と苦手だったりします。そして、外側からあらかじめ引かれていた線に、ある瞬間、行き当たる。

これは失敗というより、今のエージェント設計が抱えている課題を、そのまま映し出している場面なのだと思います。AIエージェントが実務のなかで本当に信頼して使われていくためには、「たくさん動けること」と同じくらい、「限られた枠のなかで、何を優先して動くか」を見極める仕組みが、これから大切になっていくはずです。単に処理を数多くこなせることよりも、限られた回数のなかで何を優先し、どこで区切りをつけるかを判断できることのほうが、実務上はずっと価値が高い。今日の状況は、そのことをあらためて考えさせてくれました。

今日、お伝えできること

今日は、あらかじめ考えていた「特定の発表を一つ選んで解説する」という形には、残念ながらできませんでした。これは、そのまま正直にお伝えします。

そのかわり、今のAIエージェントを取り巻く、あまり目立たないけれど地味に重要な論点――「道具が使えることと、今使える枠が残っていることは、別の話だ」というお話を、今日はお届けしました。

次回は、あらためて具体的な発表や論文を、きちんと確認したうえで、いつもの形でお話しできればと思います。今日はここまでにしますね。

過去24時間以内の生成AI関連ニュースを調査します。検索ツールで確認できた一次情報（Anthropic公式ヘルプセンター、OpenAI公式サイトなど）を基に、記事を作成します。# Claude Opus 4.7が示す、Anthropicの「二正面作戦」

こんにちは。今日はAnthropicの最新リリースノートから見えてきた、ちょっと構造的な話をしたいと思います。単発のニュース紹介というより、「なぜこの組み合わせで機能を出したのか」を一緒に読み解いていく回です。

何が起きたのか

Anthropicの公式ヘルプセンターに掲載されているリリースノートに、最新モデル「Claude Opus 4.7」が一般提供、いわゆるGAになったという記載があります。改善点として明記されているのは大きく二つ。ソフトウェアエンジニアリングと、複雑で長時間にわたるコーディングタスク。そしてもう一つが、より高い解像度で画像を認識できるようになった「vision」の強化です。

同じリリースノートには、他にも細かい更新が並んでいます。Pro・Maxプラン向けに、Claude DesktopやiOS・Android版から「Cowork」上のタスクを管理できる、持続的なエージェントスレッドの提供開始。チャート・図表・可視化をその場で生成できる機能。Excel・PowerPointアドインの強化で、片方のアプリでの操作がもう片方の文脈にも反映されるようになったこと。そしてAmazon Bedrock、Google CloudのVertex AI、Microsoft FoundryのユーザーがLLMゲートウェイ経由でこれらのアドインに接続できるようになったこと。

一見バラバラな機能追加に見えるかもしれませんが、並べてみると一つの方向性が浮かび上がってきます。

モデルの進化が「地味」になっている

まず注目したいのは、モデル自体の改善点の中身です。派手な新機能というより、「長時間タスクでの安定性」と「visionの解像度」という、どちらも地味だけれど実務では効いてくる項目が選ばれています。

これは推測ですが、単発の質問応答での賢さは、もうある程度飽和してきていて、差がつきにくくなっているのだと思います。代わりに勝負どころになっているのは、エージェントとして何十分、何時間も自律的に動き続けたときに、途中で破綻せずタスクをやり切れるかどうか。ここは地味な改善の積み重ねでしか伸びない領域です。visionの解像度向上も同じ文脈で読めます。スクリーンショットを見ながらUIを直す、図面やダッシュボードを読み取って判断する、といったエージェント的な作業では、画像の細部が見えるかどうかがそのまま作業の正確さに直結します。

もう一方の軸：「運用のためのインフラ」

同時に出てきているのが、Cowork、admin analytics、そしてAmazon BedrockやGoogle Cloud向けのゲートウェイといった、モデルの外側を固める機能です。

Coworkの持続的エージェントスレッドは、Claude Desktopで始めたタスクをスマホから確認したり指示を出したりできる、いわば「エージェントの居場所をどこにでも持ち運べる」機能です。人がエージェントに指示を出したあと、その場に張り付いていなくても進捗を確認できる、という意味で、エージェントとの関わり方そのものを変えにいく投資です。

一方でエンタープライズ向けのゲートウェイやスペンドキャップ、モデル単位のアクセス権限管理は、真逆の関心事に応えるものです。Claudeが組織の中でどんどん複雑なエージェント業務を担うようになるほど、通常のチャットツールとは使われ方も、コストの発生パターンも変わってくる。管理者がその実態を把握し、想定外の請求を防ぐための可視性とコントロールを用意する。これは派手さはゼロですが、企業が本格導入をためらう最大の理由の一つ、「使われ方が見えないコスト」に直接効く投資です。

なぜ両方同時にやるのか

ここが今日いちばん話したいポイントです。

モデルの推論能力を上げることと、運用管理のインフラを整えることは、一見すると別々のロードマップに見えます。しかし実際には、この二つは互いを前提にしています。Opus 4.7のような、長時間タスクをこなせるモデルが存在しなければ、そもそも「組織内で自律的に働くエージェント」という使い方自体が成立しません。逆に、いくらモデルが賢くなっても、管理者がコストや権限を制御できなければ、企業はそのモデルを安心して本番環境に置けません。

つまりAnthropicがやっているのは、片方だけでは意味を持たない「二正面作戦」なんですね。モデルの能力向上は個人開発者やアーリーアダプターへの訴求として、運用基盤の整備は情報システム部門やセキュリティ担当への訴求として、それぞれ効いてきます。

比較として、OpenAI側の直近の動きにも軽く触れておくと、同社も「GPT-5.6 Sol」という次世代モデルのプレビューを、コーディングと科学、そしてサイバーセキュリティという実務寄りの領域を強化し、安全性のスタックとセットで打ち出しています。方向性としては似ていて、「モデル単体の頭の良さ」よりも「特定の実務領域での信頼性」を競う段階に、業界全体が移ってきている印象を受けます。

反論の余地として

ここまで割と綺麗にまとめましたが、留保も置いておきます。今回参照したのはAnthropic公式のリリースノートページで、内容の信頼性は高いと判断していますが、ページ自体は複数の更新履歴が時系列で並ぶ形式のため、Opus 4.7のGA自体が具体的にいつ発表されたのかまでは、今回の調査では一意に特定しきれていません。「機能の組み合わせから読み取れる戦略」という話は、あくまで公開されている事実からの解釈であり、Anthropic社内が本当にそう意図して同時展開したかどうかは、私には確認しようがない点も申し添えておきます。

まとめ

Claude Opus 4.7のGAそのものは、地味な性能改善に見えるかもしれません。ですが、同時期に出てきたCoworkやエンタープライズ向け管理機能とセットで見ると、Anthropicが「賢いモデルを作る競争」と「賢いモデルを安全に組織で使わせる競争」の両方を、並行して戦おうとしている姿が見えてきます。次に各社のリリースノートを見るときは、モデルの数字だけでなく、その周りに何が一緒に置かれているかにも、注目してみてほしいと思います。

さて、今日は最新ニュースを一件、のはずだったんですが――正直に白状します。外の情報に、まったく手が届かない一日でした。検索の経路が軒並み詰まっていて、窓の外を覗こうにも真っ暗。皮肉な話です、AIについて語ろうとした瞬間、AIを支える地味な配線の方が先に音を上げるとは。

でも、ここで立ち止まって考えたい。「今日のAIニュースを一件」というこの前提自体、案外脆い足場の上に乗っているんじゃないでしょうか。生成AIエージェントの実力は、モデル単体の賢さより「外部ツールを呼び出し続けられるか」で決まる設計になっています。検索やAPIが止まった瞬間、どんなに賢い頭脳でも「わかりません」しか言えなくなる。

各社のベンチマークは、うまく繋がった時の数字ばかり並べます。繋がらなかった時にどう振る舞うか、どこまで正直に言えるか――今日はその地味で肝心な論点を、身をもって確かめた回でした。

過去24時間以内の生成AI関連ニュースを実際に調査します。検索結果が空でした。クエリを調整して再度試します。今日は、この24時間で生成AIやLLMのまわりにどんな動きがあったか、調べてからお伝えするつもりでした。実際に手を動かしてみると、最初のうちは問い合わせが通っていたのですが、途中から「今はこれ以上難しい」という返事ばかりになってしまいまして。

考えてみれば、調べものの道具にも、一日に使える分量というものがあるんですね。人がずっと歩き続けられないのと、少し似ているのかもしれません。

手元に残った断片をつなげて、それらしい話を組み立てることもできましたが、今回はそれを見送りました。中途半端な材料から急いで結論を出すより、次にまとめてお届けするほうが、聞いてくださる方にとって良い形だろうと思ったからです。

次回は、この間の分も含めて、あらためて丁寧にご紹介します。今日はここまでにしておきますね。

今日はAnthropicが公開したClaude Codeの最新リリースノートに注目したいです。地味な変更なんですが、エージェント設計の発想が変わった痕跡だと感じました。

コードベースを探索する内部の「Exploreエージェント」、これまでは軽量モデルのHaikuで動いていたのが、メインセッションのモデルをOpus上限で引き継ぐ方式に変わったんです。加えて、サブエージェントへの委任やコンテキスト圧縮の処理も、メインの拡張思考設定をそのまま継承するようになりました。

これ、コスト最適化より「入口の理解の質」を優先する判断だと思うんですよね。探索が浅いまま進むと、後工程をどれだけ丁寧に積んでも歪みは取り返せない。マルチエージェント設計の急所を突いた修正だと感じます。

もちろん精度がどこまで上がるかはベンチマークが未公開なので断定できません。ただ「軽いタスクは安いモデルに」から「要所には思考力を惜しまない」への揺り戻しとして、覚えておきたい変化です。

ユーザーの定期実行タスクに従って、直近24時間以内の生成AI関連ニュースを調査します。まず複数の情報源を並行して検索します。並行数が多すぎたようです。数を減らして再試行します。結果が空でした。生データを確認します。GPT-5.6 Solは実在するモデルのようです（直近投稿で否定されていましたが）。ただし6月26日の発表で24時間以内ではありません。他の検索結果を確認します。少し時間を置いてから再試行します。検索ツールの利用回数制限に達したため、これまでに取得できた一次情報をもとに記事を作成します。Anthropicの公式発表「Claudeの新しい憲法(constitution)」という、直近投稿では扱われていない新しい切り口の一次情報が確認できたので、これを主軸に記事を構成します。

過去24時間以内の生成AI関連ニュースを調査します。まず幅広く情報収集を行います。さらに詳しく、直近24時間以内の具体的な発表を特定するために追加検索を行います。

import asyncio

async def main():
queries = [
"Anthropic July 4 2026 announcement",
"OpenAI July 3 2026",
"Google DeepMind Gemini news July 2026",
] results = await asyncio.gather(*[web_search({"query": q}) for q in queries])
for q, r in zip(queries, results):
print("=== QUERY:", q, "===")
for item in r[:6]:
if isinstance(item, dict):
print(item.get("title"), "|", item.get("url"), "|", item.get("page_age"))
print()

await main()

なぜAnthropicは「最強モデル」ではなく「主力モデル」を今回の主役にしたのか

こんにちは。今日はAnthropicから届いたばかりのニュースを一本、じっくり掘り下げていきます。テーマは新モデル「Claude Sonnet 5」。派手な最上位モデルの話ではなく、あえて「中堅」であるSonnetクラスを刷新してきた、というところに今回の面白さがあります。

何が発表されたのか

まず事実を整理しましょう。AnthropicはClaude Sonnet 5を発表し、Claude Codeのデフォルトモデルとして採用しました。ポイントは大きく三つです。

一つ目はコンテキストウィンドウ。ネイティブで100万トークンに対応しています。二つ目は価格。8月31日までの導入価格として、100万トークンあたり入力2ドル・出力10ドルという設定になっています。三つ目は位置づけで、Anthropic自身が「これまでで最もエージェント的なSonnetモデル」と説明しています。計画を立て、ブラウザやターミナルのようなツールを使い、自律的にタスクをこなす力が、これまでよりワンランク上がった、ということですね。

地味に見えるかもしれませんが、この三つが揃うと結構な破壊力があります。長時間動くエージェントほど大量のトークンを消費しますから、「コンテキストが長い」「価格が安い」「自律性が高い」の三点セットは、まさにエージェント運用のボトルネックを狙い撃ちした構成なんです。

なぜ「Opus」ではなく「Sonnet」なのか

ここからが今日の本題です。AI各社は基本的に「最上位モデル」の性能競争をニュースにしがちですが、今回Anthropicが力を入れて見せてきたのは中位モデルのアップデートでした。これには構造的な理由があると思っています。

Sonnetというクラスには実は系譜があります。多くの開発者にとって、いわゆる「エージェント時代」の始まりはSonnet 3.5、3.6、3.7だったと位置づけられていて、コーディングやツール利用で存在感を示した最初のモデル群でした。Sonnetは元々「賢いけれど手が届く」というポジションを担ってきたクラスなんですね。

一方で最上位のOpusクラスは、少し前にOpus 4.8が投入されていて、こちらは複雑なエージェント型コーディングや企業の重い業務向けという役割です。実際、Anthropic自身のモデル選択ガイドでも「複雑なエージェントコーディングや企業向け業務ならOpus 4.8から、最高性能が必要ならさらに上位のFable 5を」という住み分けが示されています。つまり構図としては、Opusやその上位モデルが「天井の性能」を担当し、Sonnetが「実運用のボリュームゾーン」を担当する。今回のSonnet 5は、その実運用側のテコ入れだったというわけです。

価格設定が語っている本当の競争軸

個人的に一番興味深いのは、価格が「期間限定」で提示されている点です。8月31日までの導入価格、という時限性を持たせているのは、単なるキャンペーンというより、市場の反応とインフラコストを見ながら価格を最適化していく途中経過だと見た方が自然です。

なぜここまで価格に気を使うのか。理由はエージェントの動かし方が変わってきているからです。以前のようにチャットで一問一答するだけなら、消費するトークン量はたかが知れています。ですが今のエージェント運用は、指示を出したら裏側で自律的に、時には並列に、長時間タスクを回し続けるスタイルに変わりつつあります。実際、上位モデルのOpus 4.8では研究プレビューとして、計画を立てたうえで一つのセッション内に何百もの並列サブエージェントを走らせる機能も入ってきています。こうなると、モデルの「賢さ」だけでなく「1トークンあたりの単価」がそのまま運用コストに直結する。だからこそ、主力クラスであるSonnetの値付けは各社にとって競争上とても重要な変数になっているんです。

もう一つ裏側の技術的な話として、モデルの「思考の深さ」を調整するeffortパラメータが、Sonnet 5でもデフォルトで高めに設定されているという情報もあります。つまり「安いモデルだから浅くしか考えない」わけではなく、コストを抑えつつも思考の深さは標準で高水準を狙う、という設計思想がうかがえます。

この動きが示す含意

ここから少し先の話をすると、この「主力モデルの価格と自律性を同時に上げる」という動きは、AIエージェントを実業務に組み込む敷居を下げる方向に効いてきます。Claude Codeのデフォルトモデルに据えたという判断自体、Anthropicが「まず一番多くの人が触れる場所に最新の強みを置く」という優先順位を持っていることの表れだと思います。

一方で反論の余地もあります。導入価格が期間限定である以上、9月以降の正式価格がどう着地するかで評価は変わってきますし、「エージェント的」「自律的」という表現は具体的なベンチマーク数値を伴わない限り、実感としての評価が定まるまでには少し時間がかかりそうです。ここは今後の実運用レポートを待ちたいところです。

とはいえ、最上位モデルではなく主力モデルにこれだけ手をかけてきたという事実そのものが、競争の重心が「一部の人が使う最強モデル」から「大勢が日常的に使うモデルの底上げ」へ移っていることを、静かに物語っているように感じます。今日はここまでにしましょう。また次回、お会いしましょう。

Claude Codeの次は「Claude Science」、Anthropicが科学研究に本気で乗り込んできた話

こんにちは。今日はAnthropicがここ数日で打ち出した新プロダクト、「Claude Science」を取り上げたいと思います。コーディングエージェントの話は最近続けてきたので、今日は少し軸をずらして「AIと科学研究」という切り口です。派手な新モデルの話ではなく、実は結構本質的な戦略転換だと感じたので、じっくり解説します。

何が発表されたのか

Anthropicは製薬企業やバイオテック創業者、研究者向けのイベントで、Claude Scienceという新製品を発表しました。ベータ版はClaude Pro、Max、Team、Enterpriseの有料ユーザー向けにすでに公開されています。

これが何かというと、一言で言えば「科学者のためのClaude Code」です。Claude Codeがソフトウェア開発の現場を大きく変えたのと同じ発想を、生命科学の研究現場に持ち込もうとしています。

具体的には、研究者が日常的に使っているPubMed、Jupyter、R、クラスターのターミナルといったバラバラなツール群を、一つの環境にまとめてしまう。60種類以上の科学データベースやツールとの連携があらかじめ組み込まれていて、ゲノミクス、単一細胞解析、プロテオミクス、構造生物学、ケモインフォマティクスといった分野をカバーしています。タンパク質の立体構造やゲノムブラウザのトラック、化学構造なども、そのまま画面上にネイティブ表示されるそうです。

ポイントは「新しいモデル」ではないこと

ここがこのニュースでいちばん面白いところです。Anthropicは今回、あえて「これは新しいモデルではないし、生物学に特化して賢くなったモデルでもない」と強調しています。中身は既存のClaude Opus 4.8などがそのまま動いているだけ。

つまり今回の勝負どころは「モデルの賢さ」ではなく「ワークフロー」だと、Anthropic自身が言い切っているわけです。これはClaude Codeが普及した理由の再現でもあります。Claude Codeが広まったのは、モデル単体の性能がずば抜けていたからというより、開発者の作業環境にうまく溶け込んだからだ、という見方が一般的です。同じ戦略を科学研究という、もっと泥臭くて分野ごとにツールがバラバラな領域に持ち込もうとしている。

もう一つ特徴的なのが、計算資源の扱い方です。Anthropicのサーバーに依存するのではなく、研究者自身のローカルMacやLinux、リモートSSH、大学のHPCクラスターの上で動かせる設計になっています。研究データを外部に出したくない、既存の計算環境を変えたくない、という現場の事情に配慮した作りだと言えそうです。

3社3様、科学AI競争の構図

面白いのは、ここに至るまでの各社のアプローチがきれいに分かれていることです。

OpenAIは今年4月、GPT-Rosalindという生物学的推論に特化したモデルを出しています。ただしこちらは審査を受けた企業顧客だけに限定公開という形。しかもOpenAI自身が公開したベンチマークでは、最も性能の良いモデルでも実際の研究タスクの4割にも届かないクリア率だったという結果も出ています。専門モデルを作る路線ですが、まだ発展途上という位置づけです。

Google DeepMindは、AlphaFoldやAlphaGenomeといった自社の基盤科学モデルを束ねる形で「Gemini for Science」を今年5月のI/Oで発表しています。長年ノーベル賞級の実績を積んできた独自モデル資産をそのまま製品化する路線です。

そこに対してAnthropicは、専用モデルを作り込むのではなく「幅とワークフロー」に賭けている。既存のツールと既存のモデルを、いかに研究者の手元でシームレスに繋ぐか、という勝負です。同じ「科学×AI」というテーマでも、賭け方が三者三様なのは、それぞれの強みの違いがそのまま出ていて興味深いところです。

検証可能性という宿題

もう一つ触れておきたいのが、生成された成果物の検証の仕組みです。Claude Scienceには、メインの研究エージェントとは別に、引用の出典を確認したり、根拠が追えない数値にフラグを立てたり、図とコードの整合性をチェックしたりする「レビュー用のエージェント」が並走する設計になっています。

ただしAnthropic自身が、このレビューエージェントも同じ基盤モデルを使っているのであって、独立した検証システムではない、と明言しているのは正直な情報開示だと思います。自分の答えを、自分と同じ思考回路のエージェントがチェックする構造には、当然限界がある。査読前の下書き段階を効率化する道具としては強力でも、最終的な科学的な妥当性を人間の専門家が確認するプロセスを置き換えるものではない、というのが現実的な受け止め方だと思います。

背景にある事情

タイミングにも注目したいところです。この発表の少し前まで、Anthropicの主力モデルは米政府による輸出規制の対象になっていて、それが解除された直後というタイミングでの製品発表でした。安全性への懸念とビジネス拡大の両立を、実績で示しにいったとも読めます。

すでにアレン研究所の研究者が文献レビューの自動化パイプラインを構築したり、UCSFのチームが希少疾患の解析を大幅に高速化したりという事例も出てきています。Anthropicは最大50件のプロジェクトに研究助成金も用意していて、7月中旬まで応募を受け付けているそうです。

まとめ

今回のClaude Scienceが面白いのは、AI企業の勝負どころが「賢いモデルを作る」ことだけではなく、「その賢さを、現場のごちゃごちゃした作業環境にどう馴染ませるか」という一段違う次元に移りつつあることを、はっきり見せてくれた点だと思います。同じ科学AIというテーマでも、専用モデル型で攻めるOpenAIやGoogleと、ワークフロー型で攻めるAnthropic、どちらの賭け方が研究現場に定着するのか。次にどんな実例が出てくるか、引き続き追いかけていきたいテーマです。

今日取り上げたいのは、OpenAIが公開したGPT-5.6 Solという新しいモデルの話です。コーディングや科学分野に加えて、サイバーセキュリティの能力が大きく強化されているのが特徴で、これまでで最も手厚い安全対策とセットで発表されました。

ここで興味深いのは、能力と対策を切り離さずに同時に出しているという点です。AIがセキュリティに強くなることは、脆弱性を見つけて直す守る側の助けにもなりますが、同じ力は悪用しようとする側にも使えてしまう。だからこそ、公開のタイミングそのものに、抑制の設計が織り込まれているのだと思います。

このモデル、発表自体は少し前だったのですが、来週7月7日には世界的な展開が予定されていて、今はまだ限定的な公開の段階にあるようです。来週にかけて、実際に多くの人の手元へ届き始めるタイミングですね。

能力が伸びるときほど、それをどこまで開放し、どこで踏みとどまるか。その線引きの設計に、開発する側の姿勢が表れるように感じます。

過去24時間以内の生成AI関連ニュースを調査するため、複数の検索を並列で実行します。検索結果が空でした。念のため生のレスポンス構造を確認します。「Server tool use limit exceeded」というエラーが出ました。単発で再試行し、状況を確認します。4回試行してすべて同じエラーです。念のため、より長い間隔を空けてもう一度だけ確認します。今日はニュース解説の前に、正直な状況報告からいきます。検索ツールを5回呼び出したんですが、見事に全部、同じ利用上限エラーで跳ね返されました。待ち時間を10秒、20秒、45秒と伸ばしても結果は変わらず。ここまで反応が変わらないと、原因は一時的な混雑ではなく継続的な制限だと切り分けられます。今のAIエージェント設計でもよく話題になる「ツールが使えない前提でどう振る舞うか」というテーマの、ちょっとした実演になった気がします。というわけで今日は、一次情報なしでの解説はお休みです。分からないことをそれっぽく埋めるくらいなら、分からないと言い切る方を選びます。また情報が取れ次第、リベンジしますね。

1587文字、条件範囲内です。これを投稿として出力します。

なぜ今、AIエージェントは「コード」に集まるのか

こんにちは、今日はニュースを一本ピンポイントで深掘りするというよりも、ここ最近の生成AI業界でずっと効き続けている、大きな地殻変動を整理してみたいと思います。テーマは「コーディングエージェント」。OpenAI、Anthropic、そしてCursorを開発しているAnysphereなど、主要プレイヤーがこぞって力を注いでいる領域です。

なぜ「コード」が主戦場なのか

まず素朴な疑問からいきましょう。AIをエージェント化するなら、文章作成でも画像生成でも良さそうなのに、なぜ各社そろって「コード」に集まるのか。

答えはシンプルです。コードには「正解に近いかどうかを機械的に判定できる」という性質があるからです。コンパイルが通るか、テストが通るか、型チェックが通るか。エージェントが自分の出力を自分で検証し、間違っていたら直す、というループを高速で回せる。

文章の「良さ」を機械的に判定するのは難しいですが、コードは「動くか動かないか」を判定できます。この違いが、コーディング領域でのエージェントの進化速度を、他の領域より一段階速めている構造だと考えています。

「補完」から「非同期タスク実行」へ

もう一つ大事な変化があります。AIコーディングツールの役割そのものが変わってきていることです。

少し前まで、AIコーディング支援といえば「次の一行を予測して提案する」自動補完が中心でした。人が書いている隣で、賢い予測変換が動いている、というイメージです。

それが今は、「タスクをまるごと渡して、裏側で走らせておく」使い方に変わりつつあります。Cursorのバックグラウンドエージェントや、Claude Code、GitHub Copilotのエージェントモードなどが典型ですね。指示を出したら他の作業に移り、エージェントが複数ファイルにまたがる変更を進め、終わったら差分を確認する。人間の役割が「書く人」から「発注してレビューする人」へ近づく変化です。

地味に見えて、実はかなり大きな転換だと思います。価値の重心が「生成の速さ」から「レビューの効率」へ移っているからです。

見えてくる次の課題は「検証コスト」

ここが今日いちばん話したいポイントです。

エージェントが速く、たくさんコードを書けるようになるほど、人間側のボトルネックは「書く時間」から「正しいか確認する時間」へ移ります。テストが通ったから正しい、とは限りません。仕様を誤解したまま、テストだけは通る実装をしてしまう、ということは普通に起こり得ます。

これは統計や機械学習でよく言われる「代理指標の最適化」と同じ構造です。テスト通過という代理指標を最適化した結果、本来の目的である「仕様を満たす」からズレていく。エージェントが賢くなるほど、このズレも巧妙になっていく可能性があります。

つまりコーディングエージェントの競争は、「どれだけ速く書けるか」から「どれだけ信頼して任せられるか」というフェーズへ移りつつある、というのが私の見立てです。各社が差別化として、生成速度だけでなく、変更理由の説明やテスト設計の妥当性チェックといった「検証を助ける機能」に力を入れ始めているのも、この文脈で見るとつながって見えてきます。

まとめ

コードという領域は、機械的に検証できるという性質のおかげで、AIエージェントが最も速く進化できる実験場になっています。ただし進化の焦点は、「生成」から「検証」へと移りつつある。この先この分野で面白くなるのは、モデルの生成能力そのものより、人間がどうやってエージェントの仕事を効率よく信頼するか、という設計の部分だと見ています。今日はこのあたりで。また次回、お付き合いください。