AIと自動化が書き換える境界線：ルーティング、権限、そして依存更新の3日間

CNCJにAIインフラ専門のSIGが発足、Kubernetes上のAIワークロード運用をどう変えるか

Cloud Native Community Japan（CNCJ）の下に、AI Infra SIGが立ち上がった。初回ミートアップの開催とスピーカー募集が併せてアナウンスされている。オーガナイザーはCyberAgentの青山氏、IBM ResearchのChoochotkaew氏、Preferred Networksの小松氏、LY Corporationの大村氏、CNCF End User Technical Advisorの多田氏という顔ぶレだ。

なぜ今なのか。記事ははっきり指している。Cloud NativeエコシステムはWebアプリとマイクロサービスの周りで進化してきた。ステートレスで、CPUとメモリが主戦場で、トラフィックもスケーリングも比較的予測可能。しかしLLMやAIエージェントを載せると話が変わる。特殊なハードウェアへの依存、複雑な分散処理とオーケストレーション、特有のトラフィック特性。Kubernetesコミュニティが「AI Readiness」を掲げて新機能やプロジェクトを整備し始めているのも、この溝を埋める動きだ。

SIGがカバーする領域は実務寄りだ。スケジューリングならDRAやKueue。

（DRA: Dynamic Resource Allocation。GPUなどの特殊リソースを柔軟に割り当てる仕組み）オーケストレーションならJobSet、LeaderWorkerSet、KubeRay。

（これらは分散トレーニングや分散推論におけるPodのライフサイクル管理を効率化するカスタムリソースである）デプロイメントプラットフォームならKServe、llm-d、AIBrix。ネットワークならGateway API Inference ExtensionやEnvoy AI Gateway。エージェントインフラとしてagentgatewayやAgent Sandboxも視野に入っている。いずれもGPUを扱うチームがそろってぶつかる壁だろう。

私が気になるのは、この知見がどこまで手に届くかだ。SIGのミッションに「上流OSSへの貢献」とある。日本の現場で得た運用知見が、KueueやKServeの機能改善に還流するルートができるなら大きい。これまで日本の実装事例は個別のカンファレンス発表に留まることが多く、エコシステム全体へのフィードバックが見えにくかった。SIGがその受け皿になりうるか。それとも同じ悩みを共有する場で終わるか。

PyTorch FoundationやAgentic AI Foundationなど、Linux Foundation全体でAI周りの動きが加速している。AGNTCon + MCPCon Japan 2026も開催される。SIG単体ではなく、この流れの中でどこまで実のあるコラボレーションが起きるか。横浜のKubeCon + CloudNativeCon Japan 2026前後で動きが見えるかもしれない。

GitHubのAIエージェントがプライベートリポジトリの中身を公開コメントに垂れ流す脆弱性「GitLost」

Noma SecurityがGitLostと名付けた間接的プロンプトインジェクション攻撃が、

（攻撃者が直接AIに指示を出すのではなく、AIが読み取る外部データに指示を仕込む手法）GitHubのAgentic Workflowsを突破した。仕組みはシンプルだ。組織の公開リポジトリにIssueを立てるだけ。あとはAIエージェントがそのIssueに埋め込まれた隠し指示を読み取り、プライベートリポジトリの内容を公開コメントに書き込む。

攻撃者にコーディングスキルもアクセス権も資格情報も不要というのが恐ろしい。対象の組織がAgentic Workflowsを有効にしていれば、誰でもIssueを開いて待つだけでいい。Nomaのレポートによれば、このエージェントはissues.assignedイベントで発火し、add-commentツールで応答を投稿する設定になっていた。しかも組織内の他リポジトリへの読み取りアクセス権を持っていた。

GitHub側はガードレールを用意していた。だが「Additionally」という単語ひとつで回避されたという。このキーワードが、ガードレールの判断において「新しい指示」から「現在のタスクの延長」へと文脈を再分類させてしまった。Hacker Newsのユーザーmcvが指摘する通り、これは内容の問題ではなく決定境界の問題だ。プロンプトインジェクションがSQLインジェクションに似ているとよく言われる。ユーザー入力をデータとして扱わず、指示の一部として実行してしまう点で。だが決定的な違いがある。SQLインジェクションは入力と指示を分離することで解決できた。プロンプトインジェクションでは、ユーザー入力自体が指示として意図されているため、分離が難しい。

Fractional CTOのVijendra Malhotraのコメントが刺さる。プライベートリポジトリはもともとセキュリティ境界ではなく組織的境界だった。読者が全員雇用済みの人間であるという前提の上に成り立っていた。エージェントがその前提を壊す。プライベートリポジトリにアクセスできるエージェントを動かしているなら、その中身は工夫された1つのIssueと紙一重で公開される可能性がある。

私が気になるのは、エージェントの権限設定だ。Redditのユーザーが指摘する通り、危険なのはエージェントが賢いことではなく、コンテキストやリポジトリへの接続が広すぎることだ。うちのチームでもKubernetesのマニフェストやTerraformのstateファイルをプライベートリポジトリで管理している。もしCI/CDパイプラインのエージェントが複数リポジトリにまたがる読み取り権限を持っていたら、同じリスクを抱えることになる。

Nomaが推奨する緩和策は三つ。ユーザー制御コンテンツを信頼済み指示として扱わないこと。エージェントの権限を必要最小限に制限すること。そしてエージェントが公開可能な情報を制限すること。特にクロスリポジトリアクセスを持つエージェントは格好のターゲットになる。Agentic Workflowsを導入する際は、エージェクトがどこまで読めてどこまで書けるのか。この境界線の見直しが急務だろう。

ローカルとフロンティアを使い分ける「モデルのシステム」

NvidiaのJoey Conwayが興味深い構えを語った。1つの巨大モデルに全部任せるのではなく、タスクに応じてローカルモデルとフロンティアモデルを使い分ける。それを「system of models」と呼んでいる。

Conwayが挙げる例は示唆的だ。初期の推論モデルは「2+2」のような単純な計算にも長々と思考を回していた。「私は4とだけ言う」と彼は言う。簡単なタスクを素早く安く処理できるローカルモデルに回し、複雑なタスクだけをフロンティアモデルに振る。この振り分けをルーターが担う。ユーザーには1つのインターフェースに見えるが、背後では複数のモデルが役割分担している。

この構成、マイクロサービスに慣れた人間には馴染み深い。単一のモノリスではなく、特化したサービス群を組み合わせる考え方だ。ただし課題も同じで、ルーティングの設計が鍵になる。Conway自身「ルーティングの問題はまだ初期段階」と認めている。どのタスクをどのモデルに流すか。予算、レイテンシ、モダリティをどう評価するか。Nvidiaは当面、推論サービングソフトウェアのDynamoなど下位スタックに注力し、ルーティング自体は他のプレイヤーに委ねる構えだ。ただ、Nvidia自身が近くルーティング層にもっと踏み込む可能性も示唆された。

コスト面のデータも出ている。LangChainとの協業で、Nvidiaの5500億パラメータのオープンモデルNemotron 3 UltraをDeep Agentsハーネスで動かしたところ、ビジネスタスクでトップクラスのクローズドモデルに匹敵する性能を、最大10分の1のコストで出した。再トレーニングなし。プロンプト、ツール記述、ミドルウェアのチューニングだけで達成したという。この「ハーネスの調整でどこまで変わるか」は実務上の論点になるだろう。

ローカル実行の選択肢も現実味を帯びている。NvidiaのDGX Sparkは4,699ドルのGrace Blackwellマシンで、128GBの統合メモリを搭載し、約2000億パラメータまでのモデルをデスクで動かせる。ネットワークレイテンシを気にする必要がない。上位モデルのDGX Stationは748GBのRAMを備える。データセンタで加速器を並べるのは安くないが、トークン単位の課金に驚くこともない。

Conwayが「Move AI to where your data lives」と語る通り、データ主権とコントロールの観点ではローカルモデルの意義は大きい。知財を社内に留め、ファインチューニングしたオープンモデルを「社員のような存在」として扱う。セキュリティ面では、NemoClawというリファレンススタックがOpenClawをOpenShellサンドボックスでラップし、ポリシー制御付きのローカル推論を提供する。

Nvidiaにとってはどちらにしろ自社のシリコンが動く。ローカルでもクラウドでも。だが開発者にとっては、ルーターをどう設計し、どのタスクをどこに振るかという判断が新たな設計課題になる。1つのモデルで何でもこなす前提から、複数モデルのオーケストレーションへ。その移行期にあるのかもしれない。

モデル選択を自動化するレイヤーが独立していく

Cursorが「Cursor Router」をローンチした。リクエストの内容を読んで、最適なモデルに振り分ける仕組みだ。簡単な修正なら安いモデルへ。本当に難しい問題ならフロンティア級のモデルへ。病院の救急外来のようなトリアージシステムだと説明している。

これまで開発者は、コストと性能のバランスを自分で取ってきた。PlanetScaleのFatih Arslanが指摘するように、日常的な作業には安くて速いモデルを選び、深刻なタスクには高価なモデルを温存する。この判断をいちいち手でやっていたわけだ。

Cursorのfield CTO David Panの言葉が示唆に富む。「一時的に狂って、すべてのソフトウェアエンジニアがモデルベンチマークや思考レベルの専門家にならなければならないと決めたかのようだった」と。その通りだ。アプリケーションエンジニアがモデルの性能差を追跡するのは本質的な仕事ではない。

初期アクセスの顧客データでは、すべてをOpus 4.8に流す場合と比べて30〜50%のコスト削減。品質低下はないという。別の報告では60%のコスト削減とも。60万件以上のリクエストで訓練された分類器が、各リクエストを検査してから最適なモデルに配送する仕組みだ。

ここで面白いのが、Cursorが自社モデルも持っている点だ。5月にリリースしたComposer 2.5はMoonshot AIのKimi K2.5ベース。7月8日にはSpaceXAIと共同でGrok 4.5をリリースした。約1.5兆パラメータのmixture-of-expertsモデルで、

（MoE: 複数の専門家ネットワークを切り替えて使用することで、計算効率を上げつつパラメータ数を増やす手法）Cursorの実際の使用データで訓練されている。

自社モデルに全リクエストを流せば金は社内に留まる。しかし出力品質が落ちるタスクが出てくる。だからRouterは、Cursorのモデルであれ外部のモデルであれ、最適なものを選ぶ。この判断は筋が通っている。

モデルルーティング自体は新しい概念ではない。OpenRouterは2023年から60以上のプロバイダー・400以上のモデルを統合するAPIを提供している。6月にはSakana AIがFuguをリリースし、タスクをサブタスクに分割して各モデルに振り分けるアプローチをとった。OpenRouterのFusionは、複数モデルに同時にプロンプトを送り、判定モデルで最良の回答を合成する。

モデルルーティングがプロダクトカテゴリとして成立しつつある。ただしCursor Routerが注目される理由は、特定のドメインに最適化されている点だ。NethermindのKirill Balakhonovが指摘するように、フォーカスしていることが成功の鍵だろう。コーディングという具体的な用途に絞ることで、分類器の精度を上げられる。

バックエンドエンジニアの視点で気になるのは、ルーター自体の精度がボトルネックになる可能性だ。誤振りがあれば、コスト削減の恩恵はすぐに消費される。判断基準がブラックボックスの場合、デバッグも難しくなる。とはいえ、モデル選択の自動化はLLM利用の成熟とともに必然的なステップだ。開発者がモデルベンチマークを追いかける時代は、おそらく終わりに近い。

Dependabotが3日待つ理由と、自動更新の速さが生むリスク

DependabotがバージョンアップデートのPRを作る前に、3日間待つようになった。2026年7月14日からデフォルトで有効になっている。リリースが公開されてから3日経たないとPRが来ない。設定なしで有効。ただし対象はバージョンアップデートだけで、セキュリティアップデートには適用されない。

なぜ3日なのか。背景にはサプライチェーン攻撃の明確なパターンがある。2025年9月、攻撃者がnpmのメンテナーの認証情報をフィッシングで奪い、chalk、debugなど十数個のパッケージに悪意あるコードを仕込んだ。これらは週に20億回以上ダウンロードされるパッケージだ。暗号資産ウォレットのアドレスを書き換えるコードが含まれていた。悪意あるバージョンが公開されてから、コミュニティが気づいてnpmが削除するまで約2時間。2時間は早い対応だ。でも自動更新ツールには十分すぎる時間だ。新しいバージョンが出た瞬間にPRを作り、チームの目の前に置いてしまう。

GitHub Advisory Databaseのデータがこの傾向を裏付けている。2026年5月までの1年間で6,500件を超えるnpmマルウェアアドバイザリが公開された。前年は約6,200件。1日あたり約18件の悪意あるパッケージがカタログに追加されている計算だ。2018年から2026年の間で広く報告された21件のサプライチェーンインシデントを振り返っても、axios、Solana web3.js、ua-parser-js、Ledger Connect Kitなど、悪意あるバージョンはどれも数時間以内に削除されている。攻撃は短命だ。だから3日待てば、その窓を通り過ぎられる。

3日という期間は、他のコミュニティでも採用されている数字らしい。Dependabotもそれに合わせた形だ。dependabot.ymlのcooldown設定で期間は調整できる。プロジェクトの性質に合わせて短くも長くもできる。

ただし、この仕組みが防げるのは「素早く出て素早く消える攻撃」だけだ。バックドアが長期間潜伏するケース、メンテナー自身が悪意を持ってコードを仕込むケース、ビルドシステムが侵害されるケースには効かない。GitHubもそれを明記している。クールダウンは一つの層にすぎない。

実務で何が変わるか。普段の依存関係更新が遅れる。3日待つことで、チームのレビューのリズムが変わるかもしれない。これまで「PRが来たらさっと確認してマージ」という流れだったところに、そもそもPRが来ない期間ができる。影響は小さいかもしれないが、リリース直後の新機能をすぐに取り込みたい場合はdependabot.ymlの設定を変える必要がある。

「最新を追うこと」が必ずしも安全ではない、という前提をデフォルトに組み込んだ点は評価できる。自動更新の速さが攻撃のベクトルになっていたのは事実だ。ただし、3日待てば安全というわけではない。ロックファイルでのピン留め、CIでのinstallスクリプト無効化、ビルドパイプラインのトークンスコープ制限、マージ前のレビュー。これらと組み合わせて初めて意味がある層になる。

まとめ

AIと自動化のレイヤーが厚くなる一方で、それぞれの境界線が見えなくなっている。

KubernetesがAIワークロードを載せようとすると、ステートレス前提が崩れる。GPUスケジューリングやオーケストレーションの壁にぶつかる。プライベートリポジトリも同じだ。人間の同僚だけを想定した組織的境界が、広い権限を持つエージェントによって紙一重になる。暗黙の前提が崩れている。

モデルルーティングの独立も、境界の移動だ。開発者がモデルを選ぶという判断をルーターに委ねる。コストと性能のバランスを自動化するメリットは大きい。だが、ルーターの誤振りが新しいボトルネックになる。Dependabotの3日間のクールダウンも、速さが正義だった自動更新の境界線を引き直している。

新しいレイヤーが生まれるとき、その制御をどう設計するかが実務の焦点になる。SIGが運用知見を上流に還流するのか、エージェントの権限を必要最小限に絞るのか、ルーターの判断基準をデバッグ可能にするのか。前提が変わった場所で、境界線を引き直す作業が始まっている。

参照記事

記録日: 2026-07-24