「ローカルLLM」という戦略的選択肢

—— 情勢不安・ベンダーリスク・技術革新が交差する今、経営者が知っておくべきこと

Executive Summary

2026年2月末、米国国防省がAnthropicを「サプライチェーンリスク」と指定するという前代未聞の事態が発生しました。同時に、人気AIツールOpenClawのユーザーが各社AIプラットフォームから続々とバンされる事例が相次いでいます。これらは、「クラウドAIに全面依存する」という戦略の脆弱性を明確に示しています。本レターでは、「ローカルLLM」——自社インフラで動かすAIモデル——が経営リスクのヘッジ手段として急速に現実解となりつつある背景を分析します。

「サプライチェーンリスク」指定が意味すること

2月28日、ヘグセス国防長官はAnthropicを「サプライチェーンリスク」と指定しました。これは通常、HuaweiやKasperskyのような「敵対的国家の企業」に適用される措置であり、米国内企業への適用は初めてのことです。

発端は、Anthropicが軍によるClaudeの「無制限利用」を拒否したことです。具体的には、大規模な国内監視と人間の介在なしの自律型兵器への利用を禁止するガードレールを契約に明記することを求めましたが、国防省はこれを「ベンダーが軍の運用に口を出すな」と拒絶。交渉は決裂し、トランプ大統領は全連邦機関にAnthropic製品の使用停止を指示しました。

この出来事の意味は、AIベンダーの選択が地政学的リスクと直結したということです。
Anthropicは300億ドルの資金調達を完了したばかりで、評価額は3800億ドル。IPOも取り沙汰されていた矢先でした。それが、政治的紛争により一夜にして「危険なベンダー」とラベリングされたのです。

PYMNTS.comの分析が指摘する通り、AIモデルはハードウェアとは異なり、一度組織に組み込まれるとその影響がコード・データ・意思決定のあらゆる層に浸透します。「ベンダーを切り替える」という行為は、ハードウェアの入れ替えよりはるかに複雑な「認知的依存の剖離」となる可能性があります。これは、米国だけでなく日本企業にとっても、特定AIベンダーへの依存が大きなBCPリスクとなりうることを示しています。

OpenClawバン波——「フラットレートAI」の終焉

もう一つ、現在進行中の重要な動きがあります。AIエージェント「OpenClaw」のユーザーが、Anthropic・Googleの両方からアカウント停止処分を受ける事例が急増しています。

背景はこうです。2026年1月9日、AnthropicはClaudeのサブスクリプションプランのOAuthトークンをサードパーティツールから利用することを技術的にブロックしました。事前通告なく、ある朝突然、世界中の開発者のワークフローが止まりました。2月18日には公式ドキュメントで明文化され、「Pro/MaxプランのOAuthをClaude CodeやClaude.ai以外で使うことは利用規約違反」と明記されました。Googleも同様に、Antigravity経由でOpenClawに接続していたユーザーのアカウントを停止しています。

これは単なる「ズルいユーザーの締め出し」ではありません。構造的な問題は、「フラットレートのサブスクリプションで無制限にAIを使う」というモデルが、AIベンダーにとって経済的に持続不可能だという点にあります。実際、Claude Opusをエージェント的に使えば、1日で数百万トークンを消費します。月額200ドルのMaxプランでは、API課金で換算すると数千ドル相当のコストが発生します。

つまり、今後もフラットレート型のAIサブスクリプションは、エージェント的なワークロードが増えるほど制限が厳しくなることが予想されます。これは、「クラウドAIに依存した業務自動化」の前提そのものを揺るがす動きです。

API料金の構造的問題

2026年現在、主要プロバイダーのAPI料金は競争により前年比で60～80%下落しています。しかし、この「デフレ」は永続するとは限りません。現在の価格帯を見ると、Claude Opus 4.6は入力5ドル/出力25ドル（100万トークンあたり）、GPT-5.2は1.75ドル/14ドル。一見安く見えますが、エージェントが24時間稼働し始めると、トークン消費は指数関数的に増大します。

McKinseyの推計では、2026年のグローバルAI運用コストは5000億ドルを超え、その40～60%が統合・保守に費やされているとされます。さらに、プロバイダー側のビジネスモデルの変更リスクがあります。2025年にOpenAIが実施したトークン単価の引き上げが示すように、今日の価格が明日も維持される保証はありません。

特に懸念すべきは、エージェント時代のコスト構造です。従来の「人間がチャットする」使い方ではトークン消費は管理可能でした。しかし、OpenClawやClaude CodeのようなAIエージェントが自律的に動き、ツールを呼び、コードを書き、テストを繰り返すワークフローでは、トークン消費は予測不能になります。「使った分だけ」という透明性は、裏を返せば「誰も上限を制御できない」というリスクでもあるのです。

「ローカルLLM」が現実解になった理由

ここ数週間で、ローカルLLMの実用性は劇的に変わりました。「性能が足りない」「設定が難しい」という従来の課題が、技術革新によって急速に解消されつつあります。

モデル品質の飛躍

2026年初頭時点で、オープンソースモデルは商用APIとの性能差を事実上埋めています。GLM-5（Reasoning）はコーディング・推論の両方でオープンソースのトップに立ち、AIME 2025（数学オリンピック）では95.7%と、GoogleのGemini 2.0 Pro Thinkingと同等のスコアを記録しています。DeepSeek V3.2は総合推論で最もバランスが良く、Qwen3-235Bは日本語に特に強いモデルとして知られています。

特筆すべきは、OpenAIが初めてオープンウェイトモデルとしてリリースしたgpt-oss-120Bです。117BパラメータのMoEアーキテクチャを採用し、o4-miniに匹敵する性能を自社インフラで動かせるようになりました。また、XiaomiのMiMo-V2-Flashは309Bパラメータ中わずか15Bしか活性化しないハイブリッドアテンション設計で、256Kコンテキストウィンドウを実現しています。

そして3月2日、最も衝撃的なニュースが届きました。AlibabaのQwenチームが発表したQwen3.5 Smallシリーズ、特にその旗艦モデルQwen3.5-9Bは、ローカルLLMの「常識」を根底から覆しました。わずか9Bパラメータのこのモデルが、gpt-oss-120B（117Bパラメータ）をGPQA Diamond（大学院レベルの科学推論）で上回ったのです――81.7対71.5というスコアで、13.5倍もサイズが大きいモデルを超えました。

Qwen3.5-9Bの技術的な特徴は三点に集約されます。第一に、Gated DeltaNetworkとsparse MoEを組み合わせたハイブリッドアーキテクチャにより、262,144トークン（約200万文字相当）のコンテキストウィンドウをわずか9Bで実現しています。第二に、テキスト・画像・動画を単一のアーキテクチャでネイティブに処理する「Early Fusion型マルチモーダル」を採用しており、アダプター経由で視覚を後付けした従来の小型モデルとは根本的に異なります。第三に、百万エージェント規模の環境でのスケールドRLにより、ツール呼び出し・構造化推論・複数ステップの自律タスクに最適化されています。

ベンチマーク上の成果も際立っています。視覚的推論（MMMU-Pro）では70.1を記録し、Gemini 2.5 Flash-Lite（59.7）やQwen3-VL-30B-A3B（63.0）を上回りました。指示追従（IFEval）では91.5と、前世代のQwen3-72B（88.9）を超えています。長文脈処理（LongBench v2）でも55.2対48.0と、3倍以上のサイズのモデルをリードしています。ライセンスはApache 2.0で、GGUFやMLX形式での量子化版もHugging Face上で即日公開されており、llama.cpp・vLLM・SGLangを通じてOllamaにも対応しています。
経営的な含意は明確です。「ローカルLLMは大型サーバーが必要」という前提が崩れただけでなく、「小さいモデルは性能が劣る」という常識も崩れました。Qwen3.5-9Bは、量子化すればAMD Ryzen AI Max+のような統合メモリ搭載ラップトップで十分に動作します。エージェント型ワークフローを、クラウドAPIへの依存なしに、コスト予測可能な形でオンプレミス展開できる時代が、今まさに到来しています。

ハードウェアの民主化

ハードウェア側も変わりました。AMD Ryzen AI Max+ 395のような統合メモリアーキテクチャが登場し、128GBの共有メモリでVRAM制約を事実上解消しました。かつては「ローカルLLMにはNVIDIA H100が必要」と言われていましたが、現在は数十万円台のラップトップで「商用APIと同等の品質」のモデルが動作します。実際に、当社でも同チップ搭載機を導入し、Qwen3-Coder-30B-A3BやGLM-4.5-Airといったモデルを日常的なコーディング・AIエージェント業務に活用しています。

ツールエコシステムの成熟

Ollama、LM Studio、llama.cppといったツールにより、ローカルLLMの立ち上げは「3つのコマンドで完了」するほど簡単になりました。また、Aider、Cline、Continue.devといったコーディングエージェントがローカルLLMとの統合を深めており、Claude CodeやGitHub Copilotに近い体験をローカルで実現できます。OpenClaw自体も、Claudeからの締め出しを受け、Ollama経由でローカルLLMに接続する構成を公式にサポートしています。

経営判断への示唆

これらの動きを総合すると、以下のことが言えます。

第一に、AIベンダーへの単一依存は、もはや「技術選定の問題」ではなく「BCPの問題」です。Anthropicの事例が示すように、政治的リスク・規制リスク・ビジネスモデル変更リスクのいずれかが、予告なく業務を止める可能性があります。ローカルLLMは、このリスクに対するヘッジとして機能します。

第二に、ローカルLLMはもはや「妥協」ではありません。オープンソースモデルが商用APIと同等の品質に達した今、「プライバシー」「コスト」「オフライン運用」「カスタマイズ」というメリットを加えれば、多くのユースケースでローカルが合理的な選択となります。

第三に、「両方持つ」戦略が最も現実的です。ローカルLLMで日常業務の8割をカバーし、残りの複雑なタスクにのみクラウドAPIを利用する。このハイブリッド構成は、コストとリスクの両方を最適化できます。Ollama経由でローカルLLMを立て、フォールバックとしてクラウドAPIを設定するという構成は、既に実用段階にあります。

結びに

Anthropicの「サプライチェーンリスク」指定とOpenClawのバン波。この2つの事象は、一見無関係に見えますが、共通の教訓を示しています。それは、「クラウドAIの利用可能性は、自社では制御できない要因に左右される」ということです。

政治的紛争、ベンダーのビジネス判断、戦争や地政学的緊張によるサービス障害。これらは予測不可能であり、かつ発生した場合の影響は即座的です。一方、ローカルLLMは電気とハードウェアさえあれば動き続けます。インターネットがなくても、APIが止まっても、ベンダーが方針を変えても。

「ローカルLLMを持つかどうか」は、もはや技術的な趣味の問題ではありません。それは、事業継続性に関わる経営判断です。そして、その判断をするのに必要な技術的条件は、既に整っています。