自動化とエージェントが突く「制御の隙間」──K8sからAIコード、OSSライセンスまで

デプロイは自動化するのにリソース調整は手動、K8s現場の非対称な信頼

321のエンタープライズ組織のKubernetes実践者を対象にした調査で、面白い非対称性が出た。82%が自動デリバリーに高い信頼を置いている。一方、リソース最適化の推奨を適用する前に人間のレビューを要求する割合は71%。CPUやメモリの変更をガードレール内でさえ自動適用してよいと答えたのはわずか27%だ。

現場感として腑に落ちる。デプロイは「新しい価値を足す」行為に見える。ロールバックの道筋も見えているし、壊れればすぐわかる。でもリソースのライトサイジングは「安全マージンを削る」行為に感じられる。

（ライトサイジング：実際の負荷に合わせてCPUやメモリの割り当て量を最適化し、過剰なリソース確保を削減すること）失敗モードが根本的に違うのだ。

リソースリクエストを変えると、Kubernetesのスケジューリング、優先順位付け、リソース割り当てが全部変わる。コード変更と違ってデプロイパイプラインで追跡できない。2週間後にトラフィックスパイクが来て初めて閾値を超える、という事態も起こる。その頃には他の変更も重なって因果関係の証明はほぼ不可能。夜2時にページを受けるのは自分たちだということを、みんな知っている。

ここまでは「そうだろうな」という話。問題は、AI推論ワークロードがこの計算を変えている点だ。

GPUコンピュートはCPUより時間単価が大幅に高い。過剰プロビジョニングのコストが誤差の範囲で済まなくなっている。推論ジョブのバースト性も、チームが直感を持っていない領域だ。モデル更新や利用パターンの変化でトラフィックが変わり、リソースの次元もこれまでチューニングしてきたものと異なる。

手動最適化は1日250回の変更あたりで破綻し始めるというデータがある。推論ワークロードは、これまで管理してきたどのワークロードよりも早くこの閾値を超える。変更頻度が高く、間違えた時のコストが高いからだ。

では何が信頼を高めるのか。48%が「意思決定プロセスの可視性と透明性」、25%が「実証されたガードレール」、23%が「即時ロールバック」を挙げた。完全な手動制御を求める人はおらず、ブラインドな自動化を求める人もほとんどいない。段階的に信頼を獲得する自動化が求められている。

先を走っているチームも本番から始めていない。開発環境の単一ネームスペースから始め、挙動を観察し、推奨と結果を比較し、徐々に範囲を広げた。

CPU/メモリのリクエストとリミットだけでワークロードあたり4次元。それが数百のワークロードにまたがる。手動でも大変だが、いきなり自動化に任せるのも怖い。結局、自動化が「なぜその値を選んだのか」を説明でき、人間が確認してから段階的に委ねていく。そのプロセスを設計できるかどうかが、分かれ目になる。

Slackチャンネルに住み着くClaude──「Agent Identity」が変える権限設計

AnthropicがClaude Tagを発表した。Slackのチャンネルに@Claudeを常駐させ、チームメンバーとして扱う機能だ。従来の「Claude in Slack」アプリは2025年10月に登場したが、呼びかけに応答して終わる関係性だった。今回の置き換えは、そこから明確に1段上がっている。Claude Tagはチャンネルに居座り、タスクを数時間から数日かけて自律的に進める。他チャンネルの文脈も参照できる。誰かにタグられて動くのではなく、会話を監視して自らフォローする「ambient」モードもある。

一番面白いのは権限モデルだ。従来のAIアシスタントは「呼んだ人の権限を借りる」仕組みだった。GitHub連携なら自分のアカウントでPRを出す。でもClaude Tagは「Agent Identity」という独自のアイデンティティを持つ。管理者がワークスペース単位でClaudeに専用のサービスアカウントを与え、チャンネルごとにアクセス範囲を絞り込む。エンジニアリングチャンネルにはGitHub書き込み権限を、一般チャンネルには読み取りのみを付与、という設定ができる。「このユーザーは何ができるか」から「このエージェントはこのコンパートメントで何ができるか」へ問いが変わったとAnthropicのNoah Zwebenは書いている。KubernetesのServiceAccountとRoleBindingに近い発想だ。

（K8sにおいて、ServiceAccountはポッドにアイデンティティを与え、RoleBindingでそのアイデンティティに特定の権限を紐付ける仕組み）チャンネルという名前空間にエージェントをバインドする。馴染みのある設計と言える。

マルチプレイヤーであることも大きい。チャンネルに1つのClaudeがいて、全員が見える。ある人が依頼したタスクを別の人が修正し、さらに別の人が引き継ぐ。AIアシスタントが個人単位だった時代との差は明確だ。ただし懸念もある。トークン消費の上限を管理者が設定できるガードレールは用意されているものの、自律型エージェントが数日かけて動くとき、どこまでコストが膨らむか。実際の運用でどうなるかは未知の領域だ。また「ambient」モードが会話を監視し続けることの心理的影響も、導入チームが考えるべき論点だろう。チャンネルに常に見られている環境で、人はどう発言の仕方を変えるのか。技術的なアクセス制御とは別の問題として残る。

AIが書いたコードをレビューする苦しみ

GitLabがAI Accountability Reportを発表した。Harris Pollが6カ国の1,528人の開発者と技術バイヤーを対象に調査したものだ。数字を見ると、91%の組織が2つ以上のAIコーディングツールを日常的に使っている。78%がAI導入でコードの記述とコミットが速くなったと答えている。スピードは間違いなく上がっている。

問題はその後だ。43%が、自分のコードベース内でAI生成コードと人間が書いたコードを確実に区別できないと回答している。自分が書いていないコード、理解していないコードをレビューし、本番に通していいと判断しなければならない。85%の回答者が、ボトルネックがコードの記述からレビューに移ったと認めている。書くのが速くなっただけで、全体が速くなったわけではない。

GitLabのManav Khuranaは「AIはボトルネックを書くことからレビューに移した」と指摘する。まさにその通りだろう。コードを早く書けるようになっても、レビューで数日止まるなら全体のスループットは変わらない。むしろレビューの負荷だけが増える。PRのdiffが大きくなり、背景を追う調査が増え、承認のハードルが下がる。こういう現場はすでに起きているはずだ。

もう一つ、ツールチェーンの分断がある。SDLCツールが完全に統合されていると答えた組織は28%に留まっている。エージェントが生成したMRを見るとき、誰が起動したか、どのIssueと紐づいているかは見える。だが、どのセキュリティ検査に触れたか、どのポリシーが適用されたか、導入されたリスクが解決済みかは、複数のシステムを行き来しないと分からない。これがガバナンスの隙間を作っている。

GitLabの提案は、ガバナンスをプラットフォームに組み込み、レビュー時に自動で可視化すること。エージェントの全アクションをアイデンティティに紐づけ、ポリシーに対してログを残し、レビューフローに自動で表示する。開発者にはガバナンスを意識させず、人間の判断が必要な部分だけに集中させる狙いだ。

技術的な動きも出ている。GitLab Orbitがコンテキストグラフを提供し始めた。コード、パイプライン、作業項目、セキュリティ検査、本番のシグナルを1つのグラフ呼び出しで取得できる。テストでは、エージェントが最大11倍速く動作し、トークン消費は4.5分の1、ハルシネーションは45分の1に減ったという。新しいGitバックエンドとインターフェースも開発中で、最大50倍速い実行時間、最大1000分の1のネットワークトラフィックを実現すると主張している。これが実際の運用でどこまで効くかは、まだ分からない。

GitLabはAI説明責任を3つの質問で定義している。「このコードはどこから来たか」「何をするためのものか」「本番に入ったら誰が責任を持つか」。大多数の組織は今、これらに答えられない。AIでコードを速く書けるようになった先に何が待っているか。レビューの構造を変えないと、速く書けることがそのまま速く壊すことにつながる。

複数リポをまたぐAIエージェントの行き詰まり、NxのPolygraphが解決を試みる

NxがPolygraphを発表した。複数のリポジトリを「synthetic monorepo」として扱い、

（物理的には別々のリポジトリでありながら、AIからは単一の巨大なリポジトリ（モノレポ）であるかのように見せる仮想的な構造）AIコーディングエージェントがまるで1つのモノレポのように作業できるようにするサービスだ。現在はアーリーアクセスで無料提供されている。

Nxのモデリングによると、1人で作業する開発者はAIツールで約4.3倍の速度向上を得られるが、大規模な組織では約1.3倍に落ちる。エージェントが速くても、開発者同士の調整に時間がかかるからだ。さらに言えば、エージェント自体も数分動くと「やることがなくなり」制御を人に返す。触れるリポジトリが1つだけで、セッションをまたいで記憶を引き継げないからだ。

ここは実感がある。マイクロサービスを書いていると、APIの変更が複数リポに波及する。プロデューサー側を直して、コンシューマー側も追従させる。このときエージェントは、自分がいるリポの外にある依存関係を見えない。手動でリポを切り替えて、コンテキストを詰め直して、またエージェントを動かす。この往復が効率を殺す。

Polygraphがやるのは、コードを動かさずに依存関係グラフを構築することだ。社内リポと依存するOSSパッケージを解析し、どのパッケージがどのAPIを定義し、どのリポがそれを消費しているかをマッピングする。エージェントはこのグラフを使って、プロデューサーとコンシューマーを同じセッションで読み書きできる。

もう一つの柱が共有メモリだ。組織内の全エンジニアがエージェントと交わした対話が記録され、新しいセッションは過去の作業を参照できる。どのファイルを触ったかだけでなく、何をしようとしていたかで関連する過去セッションを引っ張ってくる。セッションはポータブルでもある。リポ、ログ、エージェントの実行状態を別のマシンで再現でき、別の開発者がそのまま作業を引き継げる。Savkinは「Star Trekのテレポートみたいだ」と言っている。

クロスリポの変更を流す部分も面白い。影響を受けるリポをセットアップし、下流のコンシューマーに変更を推送してエージェントに検証させ、各リポにプルリクを開く。ただし、各プルリクは別々にマージされる。アトミックなクロスリポコミットではない。ここは分散システムの悩みどころで、どう妥協したかが気になる。

エージェント自体は選べる。Claude Code、Codex、OpenCodeを現在サポートし、A2Aプロトコルで接続する。タスクの途中でモデルを切り替えることも可能だ。トークンが尽きたり行き詰まったりしたときに、別のモデルで続きを試せるのは実用的だ。

一方で気になる点もある。現時点でGitHubのみ対応。社内のGitホスティングを使っているチームは待つ必要がある。また、依存関係グラフの構築精度がどの程度か、動的なインポートやリフレクションをどう扱うか、詳細が見えない。Goのモジュール依存やPythonのパッケージ依存をどこまで正しく追えるか。ここは実際に触ってみないと分からない。

複数リポにまたがる変更をエージェントに任せたいという需要は間違いなくある。Polygraphがその入り口を開けた。ただ、アトミック性の欠如やホスティングの制限など、実務で使い続けるには課題が残る。どこまで解決できるか、今後の展開を見たい。

カリフォルニアAI透明性法がオープンソースライセンスと衝突する問題

GitHubがBlack Forest Labs、Hugging Face、Mozilla Corporationと連合を組み、カリフォルニア州のAI透明性法（SB 942、SB 1000で修正提案）の修正を求めている。問題は狭いが重要だ。法案の現行案では、下流ユーザーが一定の義務を満たさない場合、開発者にライセンスを取り消すことを求めている。しかしオープンソースライセンスは永続的で取り消し不可であることを前提に設計されている。MITやApache 2.0でコードを公開したら、後から「ルールを守ってないからライセンスを取り消す」ということができない。それがオープンソースの信頼の基盤だ。

この取り消し義務がそのまま通ると、ソフトウェアサプライチェーン全体に不確実性が入る。コミュニティ駆動のプロジェクトでは、誰がどこで何を使っているか追跡しきれない。ライセンスを取り消せと言われても、実務的には動けないだろう。

連合の主張はシンプルだ。AIシステムを修正・デプロイする開発者はすでに法律の直接の対象になっている。ライセンス取り消し条項がなくても法の目的は達成できる。代替案として、EUのAI法の透明性行動規範への整合を提案している。EUのアプローチはオープンソースエコシステムの特異性を認めた上で、下流ユーザーへのベストプラクティスの文書化通知で十分としている。

バックエンドでマイクロサービスを書いていると、OSSライセンスの永続性は空気のようなものだ。Kubernetesのマニフェスト、Terraformプロバイダー、CIのアクション、全部がOSSの上に成り立っている。そこに「条件次第で取り消し可能」という概念が入ると、依存関係の信頼が揺らぐ。ビルドが通るか以前に、「この依存、いつ使えなくなるか分からない」という状態は避けたい。

カリフォルニア州のAI規制は、透明性という目的自体は理解できる。ただ手段がエコシステムの構造と噛み合っていない。EUとの整合性を考えると、修正の余地はあるはずだ。

まとめ

デプロイもコード生成もエージェントも、自動化が進む現場で噴出しているのは「制御の隙間」だ。

K8sのリソース最適化を手動レビューに止める声、AIが書いたコードのレビューに苦しむ声。どちらも、自動化が「書く」「適用する」速度に比べて、「確認する」「責任を取る」速度が追いついていない。

ボトルネックが作る側から確認する側にシフトし、人間の負荷だけが増している。

エージェントが自律的に動く範囲が広がると、権限と責任の境界がさらに曖昧になる。ユーザーの権限を借りるモデルから、エージェント自身のアイデンティティでコンパートメントを絞る設計へ。一方で、複数リポをまたぐエージェントが単一リポの壁に阻まれ、AI規制がOSSライセンスの永続性と衝突する。既存のシステムやルールの前提が、新しいエージェントの振る舞いと噛み合っていない。

現場が求めているのは、ブラインドな自動化ではない。K8sのリソース調整で「なぜその値か」の透明性が求められ、AIコードの出所と責任の追跡が求められ、エージェントの権限が明示的にバインドされる。説明責任をシステムに組み込み、人間が段階的に信頼を置ける仕組みが必要だ。可視性と制御の粒度をどう設計するか。そこが、これからのインフラと開発プロセスの分かれ目になる。

参照記事

記録日: 2026-06-24