クラウドもAIもプロトコルも、制御の境界線をどこに引くか

クラウド費用膨張の裏で始まったワークロードの見直し

AWSが登場して20年以上が経った。その間、AzureやGoogle Cloudも加わって、多くの企業が自社インフラからハイパースケーラーの借り上げへと移行した。Amazonのクラウド事業が第1四半期の営業利益のほぼ60%を叩き出している。この数字が、ハイパースケーラーというビジネスモデルの圧倒的な成功を物語っている。

だが顧客側の状況は変わりつつある。クラウドの請求額が膨らみ続けているのだ。利用量の増加もあるが、それ以上に「何でもかんでもクラウドに置く」という運用が定着した結果でもある。SummitのソリューションエンジニアリングディレクターByron Dillは、共有コンピュートとストレージには適した領域がある一方で、ワークロードをセグメント化し一部をオンプレに戻すべきだと指摘する。高リスクデータの管理がシンプルになり、コストも下がるという。

この議論はAIの現象と重なる。多くの企業がAIを急いで導入し、後から請求書を見て驚いた。パブリッククラウドも同じで、ゆっくりとしたペースの「カエル茹で」だ。かつて「コスト削減」として売られた製品が、管理を怠ると逆効果になる。Summitが提供するマネージドプライベートクラウドは、そうした企業の受け皿を狙っている。

KubernetesとTerraformでインフラを管理している立場から見ると、この主張には筋が通る。マイクロサービスアーキテクチャでサービスを細分化していると、各ワークロードの特性が見えてくる。常時稼働が前提のバッチ処理や、機密データを扱う認証基盤は、オンプレの専有環境に置いた方がコスト予測が立ちやすい。一方でトラフィックの変動が激しいAPIゲートウェイは、やはりクラウドの弾力性に頼るのが自然だ。

問題は「どこに線を引くか」だ。規制対象データを扱う金融や医療は、オンプレ移行の恩恵を受けやすい。だが移行には時間もかかる。レパトリエーションの費用と期間の試算をどう出すか。そこを詰めないと、単なる「クラウドは高い」という感想で終わる。ワークロード単位で「クラウドに置く理由」を再問する。その作業自体が、インフラ設計の精度を上げるはずだ。

モデルよりハーネスで決まるAIエージェントの実務性能

GitHubがCopilotのagentic harnessのベンチマーク結果を公開した。対象はClaude Sonnet 4.6、Claude Opus 4.7、GPT-5.4、GPT-5.5の4モデル。それぞれのモデルベンダー純正ハーネス（Claude Code、Codex CLI）と、GitHub Copilotのハーネスを比較している。結論はシンプルだ。同じモデル・同じタスクで比較して、タスク完了率はベンダー純正と同等。そのうえでトークン消費は大部分の構成で低く抑えられている。

ここで言うハーネスとは、モデルに渡すツール・コンテキスト・ワークフローを制御するレイヤーのこと。

（具体的には、ユーザーの入力を解析し、どの外部ツールを呼び出すか、どのドキュメントをコンテキストとして注入するかを決定するオーケストレーション層を指す）モデルが「生の知性」なら、ハーネスは「それをどう使うか」を決める。GitHubの記事ではこの比喩が使われているが、実務に照らすとその通りだ。同じGPT-5.5を呼ぶにしても、プロンプトの組み立て方、ツールの選び方、コンテキストの詰め方で出力もコストも変わる。ハーネスの設計が変われば、CIパイプラインの定義書を書くのと、ログのエラー行を抽出するのとで、同じモデルでもかかる時間と金額が違ってくる。

TerminalBench 2.0の分散分析が興味深い。各エージェント・モデルの組み合わせを5回以上実行し、タスク完了率と1タスクあたりのドルコストをプロット。±1σのばらつきを楕円で示している。GitHub Copilotのハーネスは、どのモデル構成でも競合の楕円と重なる位置にあり、完了率で下回ることはなく、コストで右に振れることもない。ただし差は実行ごとのばらつきの範囲内。統計的に有意な差かと聞かれると、このデータだけでは断言できない。GitHub自身も「有効な同位」と表現している。

実務で気になるのはコストと品質のトレードオフ。GPT系は低コストで高い解決率、Claude Opusは最高解決率だがプレミアム価格。GitHub Copilotのハーネスは20以上のモデルを選べるので、タスクに応じて効率重視か品質重視かを選べる。チーム運用で考えれば、コードレビューはGPT-5.4で回してコストを抑えつつ、アーキテクチャの検討にはOpus 4.7を充てるといった使い分けができる。

補足情報によると、このハーネスの改善にはプロンプトキャッシュ（Anthropic系モデルで約94%のキャッシュヒット率）と、ツール検索による遅延ロードの導入が含まれている。トークン効率が良いのは、モデルが賢いからではなく、無駄なトークンを最初から吐かせない仕組みがあるからだろう。CIパイプラインの無駄なステップを減らすのと同じ発想だ。

ハーネスというレイヤーが独立して最適化できること自体が、エコシステムの変化を示している。モデルの差し替えが容易になるだけでなく、モデルベンダーにロックインされずにツール・コンテキストの制御を自前で持てる。Kubernetesでランタイムを差し替えられるのと似ている。ただし、ハーネスの設計が黒箱になると、出力の再現性やデバッグの難しさが増す可能性もある。このあたりは実際の運用データが出てから判断したい。

CUBICのアイドル時間計算が引き起こすQUIC死亡ループ

Cloudflareが、自社のオープンソースQUIC実装「quiche」に潜んでいた輻輳制御バグの詳細を公開した。影響範囲は小さくない。quicheはCloudflareが扱うトラフィックの重要な経路に位置している。そして問題のあったCUBICは、RFC 9438で標準化され、Linuxのデフォルト輻輳制御アルゴリズムだ。

（輻輳制御とは、ネットワークの混雑状況に応じてデータの送信量を調整し、パケットロスや遅延を防ぐ仕組みのこと）つまりインターネット上のほとんどのTCP・QUIC接続を支配しているアルゴリズムで起きたバグということになる。

発端はイングレスプロキシのインテグレーションテストだった。接続初期の重いパケットロス下でCUBICを評価するテストケースが次々と失敗。原因を追うため、チームはシミュレーション環境を構築した。RTT 10ms、10MBのHTTP/3ダウンロード、最初の2秒間に30%のランダムパケットロスを注入する設定だ。本来4〜5秒で完了するはずが、100回中約60%が10秒タイムアウトに到達した。

計装を仕込んで詳細を見ると、奇妙な挙動が浮かび上がる。パケットロスが収まった後も輻輳ウィンドウが回復しない。さらにロスなし期間中、CUBICが「輻輳回避」と「リカバリ」の状態間で激しく振動していた。約6.7秒の間に999回の状態遷移。1回あたり約14ms。これは設定したRTT 10msに不気味に近い数字だ。別の輻輳制御アルゴリズムRenoで同じテストを走らせると100%合格。問題はCUBICに固有だと絞り込めた。

根本原因はCUBICのアイドル時間計算にあった。

（CUBICは、前回の輻輳発生からの経過時間に基づいてウィンドウサイズを回復させる特性を持つため、この時間計算の誤りが回復不能な状態を招いた）アイドル時間を最後に送信したデータからのみ測定する仕様が、ノイズ多いスロースタート中にACK着信でin-flightバイトがゼロになる状況と組み合わさり、無限リカバリループを引き起こす。最小輻輲ウィンドウが2パケットの状況下では、このアイドル期間最適化が自己成就予言になる。リカバリ時刻が常に未来に設定され、輻輳ウィンドウの増加が実質ブロックされるのだ。Redditでも、C-state遷移がレイテンシスパイクを生む高頻度タイマーワークロードで似た現象に遭遇したという報告があった。カーネルの電源管理判断とプロトコルレベルの再送挙動の相関——そうした低レイヤの相互作用が絡む問題は、実際の運用でも厄介だ。

修正は驚くほどシンプルだった。アイドル時間の測定基準を、最後に送信したデータだけでなく最後に受信したACKにも広げた。このほぼ1行の変更でループが断ち切られ、テスト合格率は100%に戻った。複雑な挙動に見合わぬ短い修正。ただ原因特定までの道のりは、インテグレーションテストの異常から始まり、シミュレーションでの再現、計装による可視化、アルゴリズムの差し替えによる絞り込みと、地道な調査の連続だった。Linuxカーネル側の変更が元でこの問題が顕在化したという背景もあり、あるレイヤの修正が別レイヤの前提を崩すという典型的な落とし穴だったと読める。

Rust Foundationの公式トレーニング認定——学習曲線の壁に向けた一手

Rust Foundationが「Rust Foundation Trusted Training（RFTT）」プログラムを発表した。Rustのトレーニング提供者を認定する仕組みで、信頼できる品質のシグナルを市場に提供するのが目的だ。創設コホートはMainmatter, Integer 32, Wyliodrin, Doulos, Ferrous Systemsの5社。いずれもRustトレーニングで実績のある組織ばかり。

Rustの学習曲線は、採用の最大の障壁として繰り返し指摘されてきた。所有権やライフタイムの概念は、GoやTypeScriptを書いてきた層には異質だ。

（Rustはガベージコレクションを用いず、コンパイル時にメモリの有効期間を厳格に管理するため、メモリ安全性を担保しつつ高いパフォーマンスを実現している）トレーニング需要は伸びているが、「誰の研修を受ければいいか」を見極めるのは難しい。RFTTはその判断材料を提供しようとしている。

認定は5領域で評価される。信頼性・倫理的実践、コンテンツ品質、インストラクターの能力、透明性・アクセシビリティ、評価・フィードバック。申請は委員会が公開ルーブリックに沿って独立採点し、最終決定はRust Foundationの上層部と取締役会が握る。費用は年額3,000ドル＋申請時の500ドル。2年ごとの更新で、更新時の申請料は不要。マイクロビジネス向けの割引もある。

実務で気になるのは資格要件だ。Rust Foundationメンバーで、2年以上の事業歴、1年以上のRustトレーニング提供歴が必要。3人以下・年間収益10万ドル未満の組織はケースバイケースで対応するという。独立トレーナーや小規模事業者がどこまで参加できるか、運用次第だろう。

非英語圏のプロバイダーも対象に入っている。教材の英語翻訳を提出すれば審査対象になり、地理的・言語的多様性は評価項目に含まれる。日本語で研修を提供している組織にも、理屈上は道がある。

一方で、ガバナンスに懸念が上がっている。認定基準の策定を担った4人の運営委員のうち3人——MainmatterのLuca Palmieri, Integer 32のCarol Nichols, WyliodrinのAlexandru Radovici——が、創設コホートの組織の創業者だ。Rumbul代表は重複を認めた上で、「自分の申請は自分で審査しない」「審査者は合格を決めず推薦のみ行う」「1人の審査者の懸念で不合格にはならず委員会の再審査が入る」という防衛策を説明している。基準が公開されている点も、恣意性を減らす工夫だろう。ただし、競合他社が審査に関わる構造自体は残る。この仕組みが実務として機能するかは、2年後の更新あたりで初めて判断できるかもしれない。

興味深いのは、全申請者が一発で合格したわけではないという点。不合格者にはフィードバックと再挑戦の道が示されたが、個別の結果は非公開だ。「名前を出せば応募を思いとどまらせる」という判断は妥当に見える。

チームでRustを導入する立場から言えば、トレーニング選びの判断軸ができるのは歓迎すべきだ。ただし認定マークがあるからといって、現場の文脈に合うとは限らない。組織が抱えているのは「Rustを学ぶこと」より「既存のGoサービスをどう移行するか」だったりする。認定は品質の最低ラインを示すもので、それ以上ではない。その境界線を意識して使う必要がある。

クラスタのデータを外に出さずにAI診断するエージェントをKubernetes上で動かす

MaryamTavakkoli/local-k8s-ai-agentというプロジェクトがCNCFブログで紹介された。Kubernetesクラスタ内で動く読み取り専用AIエージェントだ。OllamaでMistral 7Bを動かし、FastAPIでAPIを提供する。デリバリーはGitHub ActionsとArgo CD Image Updaterで完結する。

面白いのは、LLMとエージェントの明確な区別だ。/askエンドポイントはLLMだけで回答する。「CrashLoopBackOffとは何か」と聞けば一般的な説明が返る。/diagnoseエンドポイントは違う。Kubernetes APIでクラスタの実際の状態を読み取り、その情報をプロンプトに組み込んでから推論する。「Pod api-7b8dが過去1時間に14回再起動し、[INTERNAL_DOMAIN]に対してImagePullBackOffが発生している」という具体的な回答が返る。一般的な正しさではなく、そのクラスタでの行動可能性。ここが実務で効く部分だ。

データが外に出ない設計が肝だ。Ollamaのポッドがポート11434でモデルを提供し、FastAPIのポッドがポート8000でAPIとチャットUIを提供する。モデルウェイトはPersistentVolumeClaimに保持する。ネットワーク外への通信は起動時のモデルプルだけ。金融や医療などデータ保護が厳しい領域では、この制約が採用の前提になる。

読み取り専用という制約も重要だ。FastAPIポッドにマウントされたServiceAccountには、ClusterRoleでポッド・イベント・ログ・サービス・デプロイメントの読み取りだけが許可されている。AIエージェントがクラスタを変更できない。これが安心感の源泉だろう。書き込み権限を持たせたくなる場面はあるだろうが、まずは読み取り専用で始める判断は妥当だ。

デリバリー側も整理されている。GitにプッシュするとGitHub Actionsがマルチアーキテクチャイメージ（linux/amd64 + linux/arm64）をビルドし、7文字のコミットSHAでタグ付けする。Argo CD Image Updaterが2分間隔でDocker Hubをポーリングし、新しいタグを検出するとkustomization.yamlにコミットし直す。Argo CDがその変更を検知してクラスタを調整する。Argo CDはレジストリを知らず、GitHub Actionsはクラスタを知らない。Image UpdaterがGitへの書き込みで両者を橋渡しする。単一の真実の情報源が保たれる。

気になるのはMistral 7Bの実用性だ。7Bパラメータのローカルモデルは、クラウドの巨大モデルに比べて能力が劣ると記事でも認めている。Kubernetesのエラーパターンは比較的予測可能だから、7Bでもそこそこ動くかもしれない。ただ、複雑なネットワーク問題や複合的な障害では厳しいだろう。ここは実際に手を動かさないと分からない。

システムプロンプトの設計も興味深い。/askのプロンプトは「Kubernetes専門のDevOpsアシスタント」を指定し、エラーの説明・kubectlコマンドの提示・なぜその修正が効くのかを簡潔に答えるよう指示している。プロンプト一つでMistralが「一般的なアシスタント」から「Kubernetes専門家」に切り替わる。この境界線の薄さはLLMの面白さでもあり、脆さでもある。

このパターンをプラットフォームエンジニアリングに組み込むとしたら、どこに置くか。開発者のローカル環境か、ステージング環境か。本番での運用は別の考慮が必要だ。7Bモデルのメモリ要件とOllamaのリソース消費も見えない。小さなクラスタでは厳しいかもしれない。

まとめ

クラウド費用の膨張、AIエージェントのハーネス、QUICの輻輳制御バグ、Kubernetes上の読み取り専用エージェント。一見バラバラの話題だが、「制御の境界線をどこに引くか」という関心事が通っている。何でもかんでもクラウドに置く運用が定着した結果、請求書を見て驚くことになった。ワークロード単位でオンプレに戻す領域を見極める。これはインフラの制御をクラウドに委ねる線を引き直す作業だ。

AIエージェントでも同じ構図がある。モデルの生の知性に任せるのではなく、ハーネスという制御レイヤーを挟んでトークン消費や振る舞いを最適化する。KubernetesのAIエージェントが読み取り専用の権限に留めるのも、制御の境界線を明確にする判断だ。ただし、境界線の引き方を間違えるとCUBICのバグのような無限ループを生む。あるレイヤの修正が別レイヤの前提を崩す落とし穴は、マイクロサービスを書いていると日常的に遭遇する。

境界線を正しく引くには、対象の特性を知る必要がある。Rustのトレーニング認定が提供するのは品質の最低ラインという線だ。だが現場が抱えているのは「既存のGoサービスをどう移行するか」という文脈依存の課題だ。線を引く作業自体が設計の精度を上げる。クラウドに置く理由をワークロード単位で再問するのも、プロンプト一つでLLMを専門家に切り替える境界の薄さを認識するのも、実務に寄り添うなら避けて通れない。

参照記事

記録日: 2026-06-26