目次
- 2026年のAI覇権レースと「中国オープンウェイト」の衝撃
- LLM時代のコーディング最前線：Codex、Claude Code、Cursorの“使い分け”
- スケーリング則はまだ生きている：事前学習・RL・推論時間の「三つ巴」
- エージェント化・ツール使用・GPU時代：モデルが“作業する”ほどインフラが勝負になる
2026年のAI覇権レースと「中国オープンウェイト」の衝撃
- ✅ 2026年の勝負は「技術の独占」よりも、研究者の移動と計算資源（予算・GPU）が左右しやすいです。
- ✅ 中国発の強力なオープンウェイトが連鎖し、「使われること」そのものが影響力になっています。
- ✅ 米国企業が中国APIを買いにくい現実があり、オープンウェイトが“回り道の覇権”として機能しています。
Lex Fridman氏は、2025年1月のDeepSeek R1の登場を「DeepSeekモーメント」として位置づけ、国際的にどちらが勝っているのかをSebastian Raschka氏とNathan Lambert氏に投げかけています。議論の焦点は、単純な性能比較ではなく、オープンウェイト（重みを公開しローカル実行できるモデル）が生む“分配”と“影響力”に移っていきます。
まず「勝っている」という言葉は、時間軸で意味が変わると感じています。今日の勝ち、来年の勝ち、10年後の勝ちでは話が違います。
それに、2026年の空気としては、どこか1社だけが“誰も触れない秘密の技術”を独占する感じがあまりしません。研究者は転職もするし、アイデアは回っていきます。
だから差が出るとしたら、アイデアそのものというより、実装できる予算やハードウェアの制約です。結局、計算資源をどれだけ確保できるかが効いてきます。― Raschka
「DeepSeekの次」が次々出る構造
Lambert氏が強調するのは、DeepSeekが“単発の成功”で終わらず、中国国内の複数社が強いオープンウェイトを連続的に出す流れを作った点です。ChatGPT以降に米国で「みんながチャットボットを出した」現象に近く、中国でも多様な企業が前線級のモデルを公開し、DeepSeekが象徴的な立場を少しずつ譲りつつある、という見立てが語られています。
中国側はDeepSeekだけではなくて、もっとたくさんのラボがあります。DeepSeekが火をつけたことで、強いフロンティア級のオープンウェイトがいろいろな企業から出てくるようになりました。
面白いのは、DeepSeekが弱くなったというより、周りが同じアイデアを吸収して追いつき、最新のモデルが一時的に“いちばん良い”状態が入れ替わっていくところです。
この連鎖が続くと、オープンウェイトの存在感そのものが米国企業の戦略に影響を与えます。閉じたサービスだけで戦うと、別の土俵で存在感を取られるリスクが出てきます。― Lambert
「使われること」が影響力になる
議論が一段深くなるのは、「なぜ中国企業がオープンウェイトを出し続けるのか」という動機の部分です。動画内では、米国の企業や組織がセキュリティ懸念から中国企業のAPI契約に慎重である、という現実が語られます。その代わり、重みを公開してローカルで動かせる形にすれば、“直接お金を払わない層”にも広がり、結果として国際的な採用と影響力につながる、という整理です。
正直、外から見ると「どうやって儲けるの？」という疑問は残ります。でも、オープンウェイトは“使われること”がまず大事だと思っています。
ローカル実行なら、どこか特定の国にデータを送らなくて済みます。企業は、クラウドに出したくないデータもあります。そういう場面で、重みが公開されているモデルは選ばれやすいです。
それに、米国側は中国企業のAPIにお金を払いたがらないという事情もあります。だからこそ、オープンウェイトは「影響力を持つための現実的な手段」になっている感覚があります。― Lambert
勝者が1社に固定されない時代の“勝ち方”
このテーマの結論はシンプルで、2026年の国際競争は「最強モデルを作った国が総取り」というより、「どの形で世界に配布され、誰の現場で使われるか」が勝負になりやすい、という見取り図です。Raschka氏が言うように、研究者の流動性が高い以上、技術の独占は起きにくく、最後は予算・ハードという“実装の体力”が差になります。一方でLambert氏が指摘するように、オープンウェイトは採用そのものが影響力となり、じわじわと勢力図を変えていきます。
LLM時代のコーディング最前線：Codex、Claude Code、Cursorの“使い分け”
- ✅ 2026年のコーディング支援は「チャットで補助」から「リポジトリ全体に触れる相棒」へ進み、ツールの思想差が使い分けの鍵になります。
- ✅ Codexは“手綱を握りたい人”に合い、Claude Codeは“英語で設計して任せる”体験を伸ばし、Cursorは“差分を見ながら理解する”動きと相性が良いです。
- ✅ 便利さの一方で、楽しさ（デバッグの達成感など）を奪いすぎない距離感が、長く使うコツとして語られています。
この回では「いま実際に何を使っているのか」がかなり具体的に語られます。コーディングは成果が動作で検証できるぶん、LLMの実力差やインターフェースの差が、日々の体験に直結しやすい領域です。そのため議論は、モデルの強さだけでなく「どの道具が、どんな作業スタイルを後押しするか」に移っていきます。
普段はVS CodeのCodexプラグインをよく使っています。プラグインで入って、リポジトリにアクセスできるチャットとして動くので、導入がすごく楽です。
個人的には、ある程度は自分で状況を把握しながら進めたい気持ちがあります。全部を勝手に進められると不安になります。だから今の自分には、助けてくれるけれど、完全に乗っ取らないバランスがちょうど良いです。― Raschka
「エージェントっぽさ」は便利だけど、怖さもある
Raschka氏は、Claude Codeのように“よりエージェント的”で、プロジェクト全体に触れて進めるタイプの道具に強い魅力を認めつつも、現時点では「任せきり」に少し抵抗がある、と整理します。ここは、AIが賢くなったからこそ出てくる感情で、コーディングの主導権をどう持つかがテーマになっています。
Claude Codeのような道具は、よりエージェントっぽくて、いろいろ触りながらプロジェクト全体を進めてくれます。たぶんそれが強みです。
ただ、私はまだ「そこまで任せて大丈夫」と思える段階ではないです。自分がコントロールしたい性格もあると思います。だから、いまは“状況が見える”範囲で助けてもらう形が安心です。― Raschka
英語で設計する体験と、差分で理解する体験
一方でLambert氏は、CursorとClaude Codeを「半々で使う」と話し、両者を“体験が根本的に違う”ものとして扱います。ポイントは、Cursorが差分（diff）を見ながら細部を管理しやすいのに対し、Claude Codeは自然言語で仕様や意図を渡して、より大きな粒度で導く体験になりやすいことです。ここから「プログラミングは、細部を手で組むだけではなく、設計空間を言語で動かす作業にも寄っていく」という見取り図が出てきます。
私はCursorとClaude Codeを半分ずつ使っています。体験が全然違うので、両方必要です。
Claude Codeを使う理由のひとつは、英語でプログラミングする感覚を鍛えたいからです。細かい手順をずっと管理するより、意図や設計を英語で渡して、マクロに誘導する感じになります。
逆に、差分を見てコードを読んで、理解しながら前に進むなら、Cursorの体験が合います。深く読みながら進めたいときは、そっちの方が安心です。― Lambert
「楽しい部分」を奪いすぎない距離感
さらに会話は、「AIコーディングは楽しいのか」という話にも寄ります。Raschka氏は、面倒で退屈な作業をAIが肩代わりしてくれる価値を認めつつ、バグを見つけたときの達成感のような“好きな部分”まで丸ごと省略すると、喜びが減ってしまう、とバランスを語っています。つまり、AIは近づけすぎても遠ざけすぎても不満が出るので、「自分が何を楽しみにしているか」を基準に距離を決めるのがコツ、という方向にまとまっていきます。
AIが退屈な作業を助けてくれるのは本当にありがたいです。やりたくない作業が減るだけで、気持ちが楽になります。
でも、難しいバグを追いかけて見つけたときの喜びみたいなものは、私にとって大事です。最初から全部AIに投げると、その体験がなくなってしまいます。
だから、自分で少し試して、それでも詰まったら助けてもらう、みたいな中間がいちばん心地いい気がしています。― Raschka
道具の進化で「開発者の役割」も寄っていく
このテーマを通して浮かぶのは、ツールが賢くなるほど、開発者の仕事が「入力→実装」から「仕様の言語化→評価→調整」へ寄っていくことです。Codexのように“見える形で補助”してくれる道具、Claude Codeのように“任せて回す”道具、Cursorのように“読みながら修正する”道具が並ぶことで、作業のスタイルが選べるようになりました。次のテーマでは、この変化が「学習（スケーリング）や推論のやり方」とどう結びついているのかが、さらに技術寄りの言葉で整理されていきます。
スケーリング則はまだ生きている：事前学習・RL・推論時間の「三つ巴」
- ✅ 2026年の性能向上は「事前学習で大きくする」だけではなく、RL（強化学習）と推論時間（長く考えさせる）を組み合わせる発想が中心になっています。
- ✅ どの軸もコスト構造が違い、「学習にお金を積むか」「推論のたびに払うか」「運用で回すか」の配分が戦略になっています。
- ✅ “全部やる”のが理想でも、現実には予算・GPU・安定稼働の制約があり、伸ばし方の設計が重要になります。
このパートでは、Lex Fridman氏が「スケーリング則はもう終わったのか」という問いを投げ、議論が「いま何をスケールさせているのか」に整理されていきます。従来は“データと計算を増やして事前学習（pre-training）を大きくする”話が中心でしたが、2026年の現場では、強化学習（RL）と推論時間（test-time compute）を含めた複数の伸びしろが、同時に語られています。
スケーリング則は、私はまだ効いていると思っています。ただ、いまは「何をスケールするか」が1本ではなくなりました。
事前学習でモデルを大きくするのは引き続き強いです。でも、それだけだとコストがとても高いです。だから、後段の学習や推論のさせ方で、賢さを引き出す方向も同じくらい重要になっています。― Raschka
事前学習は「強いけれど高い」
Raschka氏の整理は、事前学習が“土台として強力”である一方、必要な計算資源が非常に大きいという現実に向き合うものです。ここがポイントで、事前学習は一度走らせれば能力の底上げになりますが、学習そのものが巨大で、クラスタ運用の難易度も上がります。結果として、事前学習だけで勝ち切ろうとすると、資本力とGPU調達力がそのまま競争力になりやすい、という見取り図が出てきます。
事前学習は、いちばん素直に性能が伸びる手段です。ただ、コストが高いです。GPUも電力も必要で、運用も大変になります。
だから現実の開発では、事前学習に全部を賭けるより、他の方法と組み合わせて「同じ基盤から、もう少し賢さを引き出す」ことを考えるようになります。― Raschka
RLは「賢さの出し方」を変える
議論の中で何度も出てくるのが、RL（強化学習）を含むポストトレーニングの重要性です。ここでは、正解データをただ模倣するだけではなく、「望ましい出力」を報酬として与え、振る舞いを整える考え方が軸になります。Lambert氏は、最近の流れとしてRLVR（検証可能な報酬を使うRL）に触れ、モデルの“作業能力”や“推論の粘り”が、この方向で伸びている感覚を語っています。
最近の流れだと、RLの重要度がかなり上がっています。特に、検証できる形の報酬を使うRLの流れが強いです。
モデルに「これが良い振る舞いだよ」と伝え続けると、ただ答えるだけじゃなくて、手順を踏んだり、試してみたり、粘り強く進めたりする方向に寄っていきます。
私の感覚では、ここが“エージェントっぽさ”の土台にもなっています。― Lambert
推論時間スケーリングは「1回ごとに払う賢さ」
もうひとつの軸が、推論時間（test-time compute）を増やして長く考えさせる方法です。分かりやすく言うと、学習で全部を詰め込むのではなく、使うときに追加の計算を払って、推論の質を上げる発想です。ここには「使うほどコストが増える」という性質があり、学習コストと運用コストのどちらに寄せるかが戦略になります。動画では、こうした配分の話が“三つ巴”として整理されていきます。
推論時間を増やして賢くする方法は、すごく直感的です。もっと時間を使って考えさせれば、答えが良くなる場面は多いです。
ただ、これは1回の問い合わせごとにコストが発生します。学習にお金を積むのとは違って、使えば使うほど支払いが増えていきます。
だから「学習で前払いするか、推論で都度払いするか」という設計の問題になります。― Raschka
「全部やる」理想と、配分の現実
このテーマの落としどころは、事前学習・RL・推論時間のどれも有効でありつつ、同時に“ぜんぶ高い”という現実です。モデルを賢くしたいなら、基盤を大きくし、振る舞いをRLで整え、推論でも粘らせたい。しかし、GPU・電力・安定運用の制約がある以上、どこに資源を振るかが勝負になります。次のテーマでは、この資源配分が「エージェント化」や「GPUインフラ競争」と直結し、現場の設計がよりシステム寄りの話へ進んでいきます。
エージェント化・ツール使用・GPU時代：モデルが“作業する”ほどインフラが勝負になる
- ✅ 2026年のLLMは「答える」だけでなく、ツールを使って試行錯誤しながら進める“作業型”に寄っています。
- ✅ その裏側では、RL（強化学習）や推論時間スケーリングが効いており、モデルが手順を回せるようになっています。
- ✅ ただし“作業させる”ほど計算資源の消費が増え、GPU・電力・冗長設計などインフラの強さが競争力になります。
この回の後半は、エージェント（ツールを使いながら目的達成に向けて行動する仕組み）をどう捉えるか、そしてその実装がどれだけインフラ依存になるか、という話が中心になります。前のテーマで整理された「事前学習・RL・推論時間」のうち、ここでは特にRLと推論時間の方向が、エージェント化の体験を押し上げている、という流れで語られます。
私の感覚だと、最近のモデルは「答えを出す」よりも、「作業を進める」方向に強くなっています。
ツールを呼び出して試したり、結果を見て次の手を考えたり、そういう反復が上手になってきました。
その動きが積み重なると、いわゆるエージェントっぽい体験になります。単発の質問応答より、連続したタスク処理が得意になっていく感じです。― Lambert
「ツールを試す→戻る」が得意になる理由
Lambert氏が言う“作業型”の強さは、モデルが外部ツールを前提に振る舞うようになったことと結びつきます。ここがポイントで、モデルの中だけで全部解くより、実行環境（CLIや検索など）で確認しながら進めるほうが、現実のタスクには向いています。RLVRのように「結果が検証できる」学習が入ると、試行錯誤の手順そのものが鍛えられ、ツール使用が自然に強くなる、という見立てが語られています。
検証できる形の報酬があると、モデルは「一回で当てる」より、「試して確かめる」ことを学びやすいです。
たとえば、コマンドを実行して結果を見て、間違っていたら直して、また試す、みたいな流れです。
こういう手順が回ると、モデルは“賢い答え”というより、“前に進む動き”を見せるようになります。― Lambert
エージェントは便利だけど「計算の食い方」が変わる
ただし、エージェント化は良いことばかりではありません。理由は単純で、モデルが試行錯誤を始めると、推論の呼び出し回数が増えます。つまり、1回の質問に1回答える形よりも、計算資源の消費が大きくなりやすいです。ここで、推論時間スケーリングが効く反面、運用コストが積み上がるという議論とつながっていきます。
エージェントは、使う側の体験としてはすごく良いです。でも、裏側で何回も推論を回すので、コストのかかり方が変わります。
一回で答えを返すより、何度も考えて、何度もツールを呼ぶので、計算量は増えます。
だから、エージェントが普通になるほど、推論に使う計算資源の制約が前面に出てくると思っています。― Raschka
GPUクラスタは「大きいほど壊れやすい」
話題はさらにシステム寄りになり、GPUクラスタの運用の難しさにも踏み込みます。大規模学習では、GPUの台数が増えるほど、どこかが故障する確率が上がり、学習が止まるリスクが増えます。そのため冗長性や再開設計が重要になり、「巨大にするだけでは動かない」という現場のリアリティが示されます。さらに、RLの学習ではactor/learnerのように構成が変わり、単純な事前学習とは別の分散設計になる、という話にもつながっています。
GPUクラスタは、規模が大きくなるほど運用が難しくなります。台数が増えると、どこかが壊れる前提で設計しないといけません。
学習を止めずに続けるための冗長性や、障害からの復旧が重要になります。
それに、RLの学習は構成が少し違って、actorとlearnerのように役割が分かれます。そういう意味でも、システムの設計が勝負になります。― Raschka
価格と供給の話が「AGI観」まで引っぱる
このテーマの最後は、インフラの制約が価格や普及の仕方に直結し、それが「AGIに近づいているのか」という感覚にも影響する、という方向にまとまります。動画では、ギガワット級のクラスターの話や、強い能力をフルに使うと月額が上がり得る、といった見立ても出てきます。要するに、モデルが“作業する”ほど計算資源を食い、最終的にはGPUと電力、そして運用設計が現実の上限を決めやすい、という結論です。
出典
本記事は、YouTube番組「State of AI in 2026: LLMs, Coding, Scaling Laws, China, Agents, GPUs, AGI | Lex Fridman Podcast」（Lex Fridman Podcast／2026年1月31日公開）の内容をもとに要約しています。
読後のひと考察──事実と背景から見えてくるもの
生成AIをめぐる議論は、単純なベンチマーク順位だけでは説明しきれない局面に入っています。Stanford HAIのAI Indexは、技術進歩に加えて、計算資源・AIハードウェア・推論コスト推計など「実装と運用」に関わる指標の重要性を強調しています［1］。この視点に立つと、競争の焦点は「誰が最強モデルを作るか」だけではなく、「誰のモデルがどの形で普及し、どの条件で継続運用できるか」へ拡張されます。
とくに配布形態（クラウドAPI中心か、ローカル推論可能な形態を許容するか）は、採用の広がりと直結しやすい論点です。データ保護・機密性・規制対応の観点では、外部送信の扱いが慎重に検討される場面があり得ます。EDPBはLLMのプライバシーリスクと緩和策を体系的に整理し、用途や運用形態に応じたリスク管理の必要性を示しています［3］。ここからは、ローカルで扱える形態が選択肢として浮上し得る一方、責任や管理負担が利用者側へ移るという両面性も読み取れます［3,4］
問題設定／問いの明確化
本稿の問いは三つです。第一に、ローカル推論可能な配布形態が「使われること」を通じて影響力を持ち得るのはなぜか。第二に、性能向上が事前学習だけでなく、推論時間（テスト時追加計算）や後段学習へ広がることで、コスト構造はどう変わるのか。第三に、ツール使用や反復実行が一般化すると、GPU・電力・耐障害運用などインフラ条件が競争力をどう規定するのか、です［1,5,8］
定義と前提の整理
ここでいうローカル推論可能な形態とは、モデルの重み等を利用者側環境で扱い、外部API呼び出しを必須としない運用を指します。利点は、データ送信を最小化しやすい点です。一方で、モデル更新やアクセス制御、監査ログ、安全評価、インシデント対応など「運用の責任」が利用者側に寄りやすくなります。NISTのAIリスクマネジメント・フレームワーク（AI RMF）は、AIのリスクを設計・運用・評価の循環で扱う考え方を示しており、提供形態を問わずガバナンスが重要であることを示唆します［4］
次に、性能向上の「増やし方（スケーリング）」には複数の軸があります。Kaplanらは、モデル・データ・計算の増加と性能の経験則的な関係を提示しました［6］。一方、Hoffmannらは、計算予算が限られる場合に、モデルサイズだけでなく学習トークン数（データ量）も含めて最適配分すべきという観点を整理しています［7］。これらは「大きくするだけ」ではなく「何に計算を割り当てるか」が競争力になり得ることを示します。
さらに近年は、推論時に追加計算を投じて性能を引き出す方向が研究され、学習（前払い）と推論（都度払い）の配分が設計課題として前面化しています［8］。この前提に立つと、同じ“賢さ”でも、学習で作り込むのか、運用時に計算を使って引き出すのかで、必要な資源とコストの性質が変わります。
エビデンスの検証
配布形態が影響力に関わる背景には、規制と供給網の不確実性があります。Federal Registerに掲載された「Framework for Artificial Intelligence Diffusion」は、先端AIに関する拡散・移転をめぐる統制の方向性を示しており、調達・委託・提供形態の選択が政策環境の影響を受け得ることを示唆します［2］。この条件下では、クラウド契約の可否や要件が変動する局面もあり得るため、利用者側で推論できる形態が“運用上の選択肢”として意味を持つ可能性があります［2,3］
推論コストの観点では、IEAの報告書が、データセンターとAIの電力需要をグローバルに整理し、電力・設備・効率化の重要性を可視化しています［5］。推論回数や推論時間が増えるほど電力需要は高まりやすく、最終的に価格や供給制約に接続します。したがって、性能向上の議論は「モデル能力」だけでなく「電力・設備・効率」の議論を伴う、という前提が置けます［5］
推論時間（テスト時追加計算）の効用については、Snellらの研究が具体的な根拠を提示しています。同研究は、プロンプト難易度に応じてテスト時の計算を最適配分（compute-optimal）することで効率を高められるとし、FLOPs-matched（計算量を揃えた）評価で、条件次第では「14倍大きいモデル」を上回り得ると報告しています［8］。ここで重要なのは、効果が「いつでも最大」ではなく、難易度や基礎モデルの成功率など条件に依存する点です。つまり、推論時間スケーリングは万能薬ではなく、設計と適用範囲の選定が必要な“手段”として位置づきます［8］
また、ツール使用や反復的なタスク処理（いわゆるエージェント的振る舞い）が増えると、推論は単発の応答から複数回の実行へ変わり、計算資源の消費が増えやすくなります。Toolformerは、モデルが自己教師的にツール使用を学ぶ枠組みを提示し、外部ツール呼び出しが設計・学習の対象になり得ることを示しました［9］。この方向は、ユーザー体験の改善と引き換えに、推論回数・待ち時間・コストの管理が一段難しくなることを意味します［8,9］
さらに、学習面では「規模が大きいほど壊れやすい」という運用工学上の現実が重要になります。Salpekarらは、10万GPU級を想定した耐障害分散学習（FT-HSDP）を提案し、故障が頻発する環境での継続学習を工学的に扱う必要性を示しています［10］。これは、性能競争がモデル設計だけでなく、復旧・再開・冗長性・運用手順といったインフラ能力に依存することを裏づけます［10］
反証・限界・異説
ローカル推論可能な形態が普及しやすいとしても、無条件に望ましいとは限りません。第一に、重み等の配布が進むほど、改変・再配布・悪用への対応が難しくなり、責任分界が複雑化します。NIST AI RMFは、AIのリスクをコンテキスト依存として扱い、説明責任と継続的管理を重視していますが、これは配布形態の違いを超えて要求される論点です［4］
第二に、推論時間スケーリングは性能改善の余地を示す一方、利用のたびに計算コストが発生しやすく、利用量が増えるほど支出が積み上がる構造を強めます。Snellらの結果も、効果の条件依存性を含んでおり、常に追加推論が最適とは言えないことが示唆されます［8］。このため、価格体系が高品質利用ほど高コスト化する方向に寄る可能性は残ります。
第三に、電力と設備は現実の上限になり得ます。IEAは、AIとデータセンターの電力需要の増加を論点として整理しつつ、不確実性や前提条件の影響も含めて提示しています［5］。したがって、需要見通しを単線的に断定するのではなく、効率改善・立地・系統増強・需要管理など複数の要因を並行して検討する必要があります［5］
実務・政策・生活への含意
実務面では、モデル選定を「性能」だけで判断しない姿勢が重要です。データ保護や機密性の要請が強い場面では、外部送信の最小化、アクセス制御、監査ログ、評価と改善のプロセス設計が欠かせません［3,4］。ローカル推論可能な形態は選択肢になり得ますが、運用責任が増えることを前提に、組織の体制（監査・セキュリティ・更新管理）と合わせて判断する必要があります［4］
政策面では、AIの議論を「情報産業」だけに閉じず、電力・設備・供給網に接続して捉えることが求められます。IEAが示すように、AIとデータセンターはエネルギー需要と不可分であり、電源構成や系統容量、立地の制約が普及速度に影響し得ます［5］。また、技術拡散の枠組みが変化する局面では、企業側も調達と提供形態のリスクを織り込む必要があります［2］
生活者の観点では、便利さの向上と同時に、価格・アクセスの問題が浮上し得ます。推論時間を増やして品質を高める設計は、利用体験を向上させる一方、計算資源の偏在が利用格差につながる余地もあります［5,8］。教育・中小組織・公共サービスにとって、どの水準の性能がどの価格で利用可能かは、今後も検討が必要とされます［1,4］
まとめ：何が事実として残るか
第三者のレポートと査読研究に基づけば、生成AIの競争は「事前学習で巨大化」だけではなく、学習配分の最適化、推論時間の追加、ツール使用を含む反復的タスク処理へと、複数の軸で進んでいます［6,7,8,9］。その結果、勝敗を左右しやすい要因は、モデル単体の性能差から、配布形態（運用責任の所在）、規制とガバナンス（リスク管理とデータ保護）、そしてインフラ（電力・GPU・耐障害運用）へ広がっています［1,2,3,4,5,10］
したがって「どこが勝つか」を語る際は、研究成果や性能の伸びだけでなく、採用される条件、運用に耐える仕組み、物理的制約の吸収力を合わせて見る必要があります。性能向上の経路が増えたことは可能性である一方、コスト・責任・資源制約が前面化することも事実として残り、今後も検討が必要とされます［1,4,5,8］
本記事の事実主張は、本文の［番号］と文末の「出典一覧」を対応させて検証可能としています。
出典一覧
- Stanford Institute for Human-Centered Artificial Intelligence（2025）『AI Index Report 2025』Stanford HAI 公式ページ
- U.S. Department of Commerce, Bureau of Industry and Security（2025）『Framework for Artificial Intelligence Diffusion』Federal Register（90 FR 4544） 公式ページ
- European Data Protection Board（2025）『AI Privacy Risks & Mitigations – Large Language Models (LLMs)』EDPB 公式ページ
- NIST（2023）『Artificial Intelligence Risk Management Framework (AI RMF 1.0)』NIST AI 100-1 公式ページ
- International Energy Agency（2025）『Energy and AI』IEA 公式ページ
- Kaplan, J., McCandlish, S., Henighan, T., et al.（2020）『Scaling Laws for Neural Language Models』arXiv 公式ページ
- Hoffmann, J., Borgeaud, S., Mensch, A., et al.（2022）『Training Compute-Optimal Large Language Models』NeurIPS 2022／arXiv 公式ページ
- Snell, C. V., Lee, J., Xu, K., Kumar, A.（2025）『Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters』ICLR 2025（OpenReview） 公式ページ
- Schick, T., Dwivedi-Yu, J., Dessì, R., et al.（2023）『Toolformer: Language Models Can Teach Themselves to Use Tools』arXiv 公式ページ
- Salpekar, O., et al.（2026）『Training LLMs with Fault Tolerant HSDP on 100000 GPUs』arXiv 公式ページ
