前提が揺れる現場――物理から論理まで、当たり前が通じなくなっている

物理サプライチェーンがAIインフラの新たな弱点になった話

シカゴ郊外で約130万ドルのデータセンター機器と銅線が盗まれる事件が起きた。Cook County Sheriff's Officeが回収した2台のトレーラーには、アラバマ州パインヒルから発送された約30万ドルの銅線と、フロリダ州ジャクソンビルから発送された約100万ドルのデータセンターインフラ機器が積まれていた。どちらも数百キロ離れた場所から同じトラックヤードに集まっていた。サイバー攻撃でもプロンプトインジェクションでもない。物理的な荷抜きだ。

AIブームが続くなかで、データセンター建設に必要な機器が貨物ネットワークを通じて大量に移動している。サーバー、ネットワーク機器、ファイバー、電力配分設備、冷却システム、そして大量の銅。これらが工場からデータセンターへ届くまでの間、セキュリティの隙間がある。Verisk CargoNetの報告によると、2025年の米国とカナダにおける貨物盗難による損失は約60%増の7億2500万ドルに達した。事件数はほぼ横ばいなのに損失額が増えている。盗人が高価な貨物を狙い撃ちするようになったということだ。金属盗難は77%増加。銅の需要が主な要因で、組織的なグループはエンタープライズ向けコンピューティングハードウェアへもシフトしている。

ここで肝なのが、AIインフラ構築の「同期」問題だ。大規模なGPUクラスターは、サーバー、スイッチ、光トランシーバー、電力配分、冷却が揃って初めて動く。ネットワーク機器が届かなければラックはアイドルになる。電力設備が遅れればデプロイ全体が延期される。銅線が盗まれれば電気工事が止まる。一つのコンポーネントが欠けると、遅延が全体に波及する。KubernetesのマニフェストやTerraformのコードをいくら整えても、物理的な機材が届かなければクラスタは立ち上がらない。

インフラエンジニアの仕事はどこまで広がるのか。サイバー脅威に対する防御はクラウドプロバイダーやベンダーが既に厚くしている。しかし物理的なサプライチェーンのセキュリティは、これまで意識する必要がなかった領域かもしれない。デプロイのスケジュールを組むとき、荷物が途中で消えるリスクを前提にするのか。それとも調達経路の冗長化や追跡をインフラ管理の一部に組み込むのか。AIインフラの価値が数十億ドル規模に膨らむなかで、「インフラセキュリティ」の定義がファイアウォールやアイデンティティ管理の外へ広がっていくのは避けられない。

OpenAI単独バインドは間違いだった――25億ドルかけてモデルルーティングに舵を切るMicrosoft

MicrosoftがMicrosoft Frontier Companyという新組織を立ち上げた。25億ドルの資金を投じ、UnileverやNovo Nordiskといった顧客のAI導入を支援する。何を売るかというと、モデルのスワップ可能性だ。業界で最も深い単一モデルパートナーシップを持つ企業が、あえて「モデルは固定しない」という選択をプロダクトにしている。

MicrosoftのJudson Althoff氏は「CopilotをOpenAIモデルのみにバインドしたのは間違いだった」と認めた。DeepSeekやGoogleのGeminiがOpenAIに追いついてきた現実がある。顧客は特定のモデルよりも、自社データとモデルの組み合わせを重視している。SOTAが次々と変わる中で

（SOTA: State-of-the-Art。ある時点における最高水準の技術や性能を指す）、モデルを素早く入れ替える要件が実務に出てきたのだ。

バックエンドの観点で面白いのは、アプリケーションのアーキテクチャが変わる点だ。これまではAPIキーを一つ持ってきて一つのモデルを叩く設計で良かった。しかし今後は、サポートチケットの要約にはClaude Haikuのような小さく速いモデル、300ページの契約書解析にはGeminiのようなコンテキストウィンドウの大きいモデル、というようにリクエストごとにルーティングを変える必要がある。規制でオンプレミスが求められるならLlamaやMistralに流す。単一モデルで全てを賄う時代は終わりつつある。

問題は、そのルーティングの決定をどこに持たせるかだ。コストを優先するか、速度を優先するか、特定のプロバイダーがダウンしたときにどうフォールバックするか。これをアプリケーションにハードコードしては、結局別のロックインが起きる。エンタープライズスケールでは、この判断が日に何百万回も起きる。高速で信頼性が高く、運用しやすいルーティングレイヤーが求められる。

すでにエコシステムも動いている。LiteLLMやPortkeyのようなプロキシがAPIを正規化し、LangChainやLangGraphが複数モデル前提で組まれている。MCPがツール統合をモデル間でポータブルにしようとしている。

（MCP: Model Context Protocol。AIモデルが外部データやツールにアクセスするための共通規格）Bedrock、AI Foundry、Vertex AIといったクラウド側のマネージドも同じ方向だ。モデルの性能がビジネスユースで収束していくなら、差別化の主戦場はオーケストレーションに移る。マイクロサービス間のルーティングやフォールバックをKubernetes上で設計するのと同じように、AI呼び出しのオーケストレーションをどう構築するか。そこが次の設計の肝になるだろう。

GodotがAI生成コードを禁止した本当の理由

Godot Engineがコントリビューションポリシーを改定し、AI生成コードの大部分を禁止した。自律的なAIエージェントや「vibe-coded」なプルリクエストは、既にGitHubリポジトリで自動banの対象になっていた。今回の更新はそれを明文化するだけでなく、人間がAI出力を貼り付けてからレビューした場合でも、実質的なコード生成にAIを使えば禁止対象とする。例外はコード補完、正規表現、検索・置換などの狭い用途のみ。開示条件付きで認められる。

背景にはPRのバックログ膨張がある。メンテナが追いつけなくなった。ただしGodot Foundationが強調しているのは、レビュー負荷の話だけではない。「AI contributions have the added pain of being demoralizing.」レビューは元々つらい作業だが、報酬があった。フィードバックが相手の学習になり、将来のメンテナーを育てるという報酬だ。AIが相手ではこの前提が崩れる。レビュー指摘を吸収するのは機械で、次に活かされる人間がいない。

ZigのLoris Croが「contributor poker」と呼んだ考え方がある。ポーカーで「人を読む」というのと同じで、コントリビューターの将来性に賭ける。最初のPRの中身より、その背後にいる人に投資する。だからこそAI生成PRは計算を壊す。レビュー時間が人を育てないなら、無給のボランティアが休日を割く理由が薄れる。

ここで論点になるのは、OSSのメンタリングモデルと企業のジュニア育成が同じ構造を持っていることだ。MicrosoftのMark RussinovichとScott Hanselmanも、シニアエンジニアとAIの組合せに偏れば「職業のタレントパイプラインが崩壊する」と警告している。GodotやZigの現場で起きているのは、その前段だ。ジュニアはコードを提出している。ただしAIが書いたコードを。人間はいるのに、育成の経路が機能しなくなっている。

新規コントリビューター（マージ済みPRが3件以下）に対し、新機能や大規模リファクタリングの前に明示的なサインオフを求めるルールも追加された。AIを介さない貢献でも門を狭める動きだ。メンタリングのコストを守るための措置と読める。

ディスカッションでのAI生成テキストも原則禁止になった。機械翻訳のみ例外。人間同士の対話までAIに置き換えると、結局誰がコードを理解しているのか分からなくなるという懸念だろう。

自分が普段書いているコードにAI補完が入ることはある。ただ、レビューの文脈で考えると、Godotの判断は筋が通っている。コードが合うかどうかの確認と、書いた人を育てる作業は別ものだ。後者を切り捨ててまでPRを処理する意味があるのか。おそらくない。

1200万トークンを線形近くで処理するSSAと、アテンションを捨てようとしている人々

Subquadraticという会社が今年前半に設立され、1200万トークンのコンテキストウィンドウを扱えるモデルを作った。ただし、当初はベンチマークを公開せず、懐疑的な目を集めていた。6月になってSubQ 1.1 Smallのモデルカードとベンチマークを公開し、Appenによる第三者検証も添えた。まだ実際に使った人は少ない。

このモデルの根幹はSubquadratic Sparse Attention（SSA）。

（通常のアテンションが全トークン間の関係を計算するのに対し、重要度の高い一部の接続のみを計算することで効率化する手法）通常のアテンションはコンテキスト長に対して二次でスケールする。1000トークンの入力で約100万組のトークン関係が生まれる。SSAは「すべてのトークン関係が重要ではない」という前提で、計算量をコンテキスト長に対して線形に近いスケールに抑える。CTOのAlex Whedonは、フルdense attentionでも99%以上のトークンの重要度が0.1未満だと指摘する。「大部分の計算を無駄にしているだけでなく、ノイズを増やしている」という見方だ。

数値は確かに目を引く。100万トークンでdense attentionより64.5倍少ない計算量、FlashAttention-2より56倍高速。単一アテンションレイヤーの比較とはいえ、1200万トークンでは計算量削減が約1000倍に達する。Needle-in-a-haystackテストでは100万から1200万トークンまでほぼ完璧。NvidiaのRULERテスト（128Kコンテキストで複数事実を追跡・集約）でも99.12%を記録した。

一方で、汎用能力はSonnet 4.6の領域に収まる。GPQA Diamondで85.4（Sonnet 4.6は87.5）。LiveCodeBenchで89.7とSonnet 4.6をわずかに上回るが、Opus 4.8やGPT-5.5には及ばない。パラメータ数は100B未満で、OpenAIやAnthropicの既存モデルより小さいとWhedonは話す。

実務でどこが変わるか。長大なコンテキストを扱うエンタープライズのデータ処理タスクこそ、このアーキテクチャの狙いどころだ。大規模な社内文書やログの検索・要約といった用途では、コンテキスト長の制約がボトルネックになる。RAGは事前にテキストを切り捨てるが

（RAG: Retrieval-Augmented Generation。外部知識を検索してプロンプトに注入する手法）、SSAは全トークンをモデルに見せた上で冗長な比較を省く。検索精度が向上する可能性がある。

ただし、まだ設計パートナー限定の段階だ。広く使えるようになる時期も不明。Whedon自身が「スパースアテンションの会社ではない」と言い切っている点も興味深い。アテンションを使わないアーキテクチャにも取り組んでおり、次のモデルで自らを飛び越えるつもりらしい。SSAが一つの到達点であって終着点ではない、というわけだ。

果たしてアテンションなしでどこまで汎用性を維持できるのか。その答えが出るまでは、SSAのベンチマーク数字を鵜呑みにしつつも、実務での検証を待つしかない。

20,000件のシークレットアラートを9ヶ月でゼロにしたGitHubの実際

GitHubが自社の15,000以上のリポジトリでSecret Scanningをパイロット運用したとき、出てきたのは20,000件を超えるアラートだった。さぞかし絶望的な数字に見える。だが、中身を掘ると話は変わってくる。たった5つのリポジトリが約18,000件を占めていた。しかもそのすべてが、テスト用フィクスチャや無効化済みの認証情報、本物そっくりのフェイクシークレットだった。GitHubはSecret Scanningを開発している組織だ。テストコードに本物と見分けがつかないシークレットが大量に置かれているのは、ある種当然の姿とも言える。残る2,000件こそが、実際のリスクとして向き合うべき相手だった。アラートの数字がそのまま危険な洩露の数ではない。ここをトリアージできなければ、対応は永遠に終わらない。

シークレットが潜むのはソースコードだけではない。サポートチケットに顧客がトークンを貼り付けていたり、バグバウンティのレポートにAPIリクエストごと認証情報が載っていたり、インシデントのメモやWikiにも見つかった。コード以外の場所にどう対応するか。これを無視すれば、せっかくの対応が穴あきになる。

GitHubがとった手順は、運用上のバックログ処理として筋が良い。まず新たな負債を止め、それから既存の負債を減らす。Phase 1では、GitHub Advanced Securityの組織レベル設定を使い、15,000のリポジトリに一括でSecret Scanningとpush protectionを有効化した。個別のリポジトリやチームがこっそりオプトアウトできないよう、設定を強制した点もポイントだ。push protectionがソースで新規のシークレットをブロックすることで、バックログの膨張を止めた。Phase 2のトリアージでは、テスト用リポジトリにあり、一度も有効化されず、既知のテストパターンに合致するものを一括クローズの対象とし、数日で約18,000件を処理した。

一方で、難しい判断も残る。Issueにシークレットが含まれている場合、本文を編集して監査証跡を消すべきか。Git履歴にコミットされたシークレットを履歴ごと書き換えるべきか。大規模にgit履歴を書き換えた経験がある人なら、force-pushが引き起こす惨状を知っているはずだ。正解はシンプルには出ない。チームの規模、システムの複雑さ、許容できるリスクによって判断は変わる。GitHubの事例は、20,000件という数字に怯む前に、まず実態を捉え、新規の洩れを塞ぎ、ノイズを機械的に排除する。その先に立つ難所に、リソースを集中させるという手順を示している。

まとめ

4つの動向に共通するのは、「これまでは気にしなくてよかったこと」に向き合わされている感覚だ。データセンターの機材が途中で消えるリスクをデプロイスケジュールに組み込むのか。モデルを1つに固定する設計が通用しなくなって、リクエストごとにルーティングを変えるレイヤーをどこに持たせるのか。レビューが人を育てる場だった前提が、AI生成PRの流入で揺らいでいる。アテンション機構なしでどこまで汎用性を維持できるのかも、まだ分からない。どれも「当たり前」が崩れている現場だ。

もう一つ共通するのは、オーケストレーションの比重が増していることだ。モデルのスワップ、コンポーネントの調達、レビューのトリアージ、計算のスパース化。どの課題も「何をどこに流すか」の設計に解答を出している。GitHubが20,000件のアラートをゼロにした手順も、新規の洩れを塞ぎノイズを機械的に排除してから難所に集中するという運用の設計だった。コードを書くことより、流れを制御することに実務の重心が移っている。

ただし、これらを一つの大きな流れに無理に繋げるべきではない。物理的な盗難とアテンション機構の計算量は、スケールの異なる問題だ。Godotのレビュー負荷とMicrosoftのモデルルーティングも、直結するわけではない。共通するのは「前提が揺れている」という感覚だけだ。それぞれが個別に注目すべき動きで、通底する筋としては「当たり前が通じなくなっている現場が増えている」程度に留めておくのが正直だろう。

参照記事

記録日: 2026-07-03