エージェントと自動化の「制御」をどこに置くか

ツールを替えたらレビュー精度が落ちた話——指示の設計が見直しの鍵だった

GitHubのCopilot code reviewチームが、コード探索ツールの移行で思わぬ落とし穴に遭遇した。独自ツールから、Copilot CLIでも使われている共有ツール（grep、glob、view）へ乗り換えたところ、ベンチマークでレビューコストが上がり、検出できる問題数が減ったという。

直感に反する結果だ。よりメンテナンスされていて、複数製品で共有できるツールの方が、性能も良いはず。しかし実際は逆だった。

原因はツールそのものではなく、エージェントへの指示にあった。

移行前, Copilot code reviewは独自のツールセットを使っていた。list directories、search files、search directories、read code——いずれも専用設計で、検索結果に周辺コードの文脈を自動で付加する厚いラッパーだった。古いモデルはツール呼び出しの回数が少なく、自力で必要な文脈を引き込むのも苦手だった。だから1回の呼び出しでなるべく多くの情報を返す設計が理にかなっていた。

一方、移行先のgrep、glob、viewはUnix風の薄いツールだ。Copilot CLIやクラウドエージェントでも使われている共有基盤で、保守性や横展開の観点では明らかに有利。単純な置き換えで済むはずだった。

ところがオフラインベンチマークのトレースを見ると、エージェントの挙動が変わっていた。PRの差分から問題を絞り込むのではなく、リポジトリ全体をブラウジングするように動いていた。広く検索し、推測でパスを当て、大量のコードを読み込み、さらに関連しそうな箇所を探し回る。リポジトリの理解が目的ならこの動きも理にかなっている。しかしPRレビューの仕事は「どこで呼ばれているか」「同じパターンのテストはあるか」といったピンポイントの問いに答えることだ。必要最小限の文脈だけで足りる。

ツールの戻り値は、エージェントにとって捨てられる出力ではない。コンテキストウィンドウに残り続けるトークンだ。

（コンテキストウィンドウとは、AIモデルが一度に処理・記憶できる情報の最大量であり、この上限を超えると古い情報から消去される）余分なファイルの中身が後段の推論に持ち越されれば、コストが増え、焦点もぼやく。

チームが手を入れたのは指示の書き換えだった。ツールではなく、エージェントに「どう読むか」を教え直した。結果として、平均レビューコストが約20%低下し、レビュー品質は維持された。

この話から読み取れるのは、エージェントの振る舞い設計においてツールの性能は一部でしかないということだ。どんなに優れたツールを渡しても、使い方の指示がタスクに合っていなければ逆効果になる。特にコードレビューのような「どこを見るか」が成果を決める作業では、ブラウジングと調査の違いを指示レベルで制御しないと、エージェントは探索を広げてしまう。

共有ツールのメリット——保守の集約、改善の横展開——は当然ある。ただ、移行時にはツールの機能差だけでなく、エージェントにどんなワークフローを踏ませるかまで見直す必要がある。ツールを替えると指示も替える。この前提を外すと、性能低下は気づかないうちに進むかもしれない。

止まらない自動化が生むリージョン障害──EKSの静的安定性という設計原則

AWSがEKSで数百万のKubernetesクラスターを運用して学んだ教訓は、想定外のところにあった。ゾーンがきれいに死ぬなら問題は起きない。サーバーが落ちたら別のサーバーを立ち上げる。この自動復旧の動きは、普段は正しい。しかし実際のゾナル障害は「きれいに死ぬ」ことが少ない。一部のトラフィックを捨てつつヘルスチェックは通る。遅いが応答は返す。この灰色の領域で、自動化が裏目に出る。

EKSのコントロールプレーンはAPIサーバーとetcdで構成され、複数のアベイラビリティゾーンに分散している。あるゾーンでネットワーク障害が起きると、そのゾーンのAPIサーバーはヘルスチェックに失敗する。原因はサーバー自身ではなく、手前のネットワークの劣化だ。それでもAuto Scalingグループはインスタンスを終了し、同じ障害ゾーンでの再起動を試みる。起動に失敗すると、今度は30分間のバックオフに入る。30秒のネットワーク瞬断が、フリートの大部分を終了させ、ウォームキャッシュを捨て、依存先への負荷を増やし、元のイベントが解決しても30分は回復を拒む。単一ゾーンの問題がリージョン全体の障害に変わる瞬間である。

AWSが到達した原則は「静的安定性」だ。

（静的安定性：外部からの変更や自動的な復旧動作なしに、システムが現在の状態を維持し続けられる設計思想）ゾナル障害の間にシステムが最も価値のある行動は、反応を止め、既存のキャパシティを維持し、障害ゾーンを迂回し、待つこと。EKSはこれを実装した。約2分でコントロールプレーンのアクティビティを障害ゾーンから移動させる自動ゾナルシフトが、複数のレイヤーで並列に発動する。DNS層では障害ゾーンのヘルスチェックを失敗させ、新規接続を健全なゾーンに向かわせる。スケーリンググループ層では、障害ゾーンのヘルスチェック失敗に対する終了動作を停止する。Kubernetes層では、リーダーが障害ゾーンにいるコントローラーのリーダーシップを健全なゾーンに移す。APIサーバーは自らのIP広告を止め、Podからのリクエストが健全なAPIサーバーに向かうようにする。

この設計の根底にある原則は「健全なゾーンが作業を行う」ことだ。障害ゾーンに何かをさせようとするから事態が悪化する。マイクロサービスをKubernetesで運用しているチームなら、この教訓は自前のインフラにも当てはまるはずだ。ヘルスチェックに基づく自動置き換えは、日常のホスト障害には有効だが、ゾナル障害の灰色の領域では毒になる。自前のオートスケーリングやフェイルオーバーのロジックを見直すべき時期かもしれない。障害時によりも、障害時に止まる勇気。そこに本当の耐障害性がある。

AIにAIの使い方を判断させる皮肉な機能

Anthropicが「reflection」機能をベータリリースした。Free、Pro、Maxユーザーでメモリ機能をオンにしていれば利用できる。過去1、3、6、12ヶ月のClaude利用状況をダッシュボードで振り返る仕組みだ。何に使っているか、どんな話題が多いか、具体的な利用パターンまで提示してくれる。「メールの下書きを自分の声で書き直している」「戦略を決めてからタスクを任せている」――そういう例をAnthropicは挙げている。

コンセプト自体は悪くない。AIを使いすぎているか、適切か。振り返りのきっかけが必要な人もいるだろう。ただ、さっそく懐疑的な声が出ている。GoGlobyの共同創業者CTO、Sergey Matikaynenは「利用を考えるきっかけを与えるツールが、判断力を向上させるわけではない」と指摘する。Columbia大学の助教でもあるTraversalの共同創業者CEO、Anish Agarwalも似た感覚だ。「コーディングの80%をAIでやったと分かっても、働き方は変わらない」と彼は言う。

ここでAgarwalが求めているのは、もっと成果に直結するシグナルだ。「どのAI生成変更がインシデントを引き起こしたか」「どれが大幅な人間のレビューを要したか」「何秒で承認したコードのデバッグに何時間かかったか」――そういう問いに答えるシステムが欲しいという。おっしゃる通り。私がKubernetesのマニフェストをAIに書かせているとして、利用頻度の統計は要らない。merge後にpodがCrashLoopBackOffを繰り返したかどうかが知りたい。

Matikaynenも同様で、AIアシストのPRレビューにどれだけ時間がかかっているかといった「デリバリーシグナル」が必要だと言う。今のreflectionが示すのは「エンゲージメントシグナル」に過ぎない。「出荷に値するものを生み出したかどうかとは無関係な活動のカウント」――彼のこの表現は痛いところを突く。

もう一点、構造的な問題がある。AIの使い方をAIに判断させるという皮肉だ。しかも判断を提供するのは、利用増加がビジネスモデルのベンダーだ。Veracodeの共同創業者でチーフセキュリティエバンジェリストのChris Wysopalは「AIベンダーはモデルの強みと限界を説明すべきだが、いつAIを使うかの最終的な権威であるべきではない」と語る。組織のエンジニアリングやセキュリティのリーダーが判断し、独立したガバナンス層で執行すべきだという。Agarwalも「モデルが知っているのはあなたとの会話だけだ」と指摘する。チームの数年のプロダクション履歴、アーキテクチャの知識、インシデントデータ。そういう文脈が欠けたままAIが適切な助言を出力できるのか。おそらく無理だ。

reflectionが今後どう進化するかは分からない。現時点では、利用頻度の可視化に留まっている。成果指標と結びついた振り返りができるかどうか。そこが次の論点になるはずだ。

エージェントのランタイムを誰が握るか、という問題

OpenAIが7月9日にChatGPT Workを発表した。GPT-5.6で動き、ローカルファイルを開き、Google WorkspaceやMicrosoft 365のドキュメントを編集し、複数ステップのタスクを最終成果物まで完遂する。AnthropicのClaude Coworkと同じ領域を狙う。ターゲットはコードを書かない人。ターミナルなしでエージェントの力を使いたい層だ。

ここで面白いのは、各社がエージェントを「誰向けか」で分類している点。ナレッジワーカー、パワーユーザー、デベロッパー、エンタープライズの4ペルソナ。ただしこれは表向きの話。裏では、ランタイムを誰が動かすか、状態をどこに永続化するか、認証情報を誰が管理するか、ポリシーを誰が適用するか。この4点で各社の立ち位置がはっきり分かれる。

ナレッジワーカー向けのChatGPT WorkやClaude Coworkでは、ベンダーがランタイムを運用し状態を保持する。ユーザーはアクセスを許可し、結果を監督するだけ。手元のMacで動かすOpenClawやHermesのような自己ホスト型は、オペレーターが制御面を管理する。ただしホストされたモデルにアクセスし、外部サービスの認証情報を保存する点では、完全なローカル管理ではない。

デベロッパー向けはさらに複雑だ。Claude Code、OpenAI Codex、GitHub Copilotのエージェントモード。実行環境がローカルIDEからベンダー管理のサンドボックス、非同期クラウドワーカーへと広がっている。エンタープライズ向けは、LangGraphやCrewAIのようなオープンなエージェントフレームワークを管理されたランタイム上で動かす。ベンダーがインフラを運用し、顧客がアイデンティティやポリシー、保持期間を設定する。

Anthropicは自社の設計を「脳と手を分離する」と説明している。Claudeを呼び出すハーネスとコードが実行されるサンドボックスを分け、セッションが両者をつなぐ。セッションは追加のみのログ。サンドボックスが分かれているため、コンテナが存在する前に推論を始められ、実行コードは開発者の認証情報から遠い場所に置かれる。

Kubernetesでマイクロサービスを運用している立場から見ると、この構造は馴染み深い。コントロールプレーンとデータプレーンの分離。マニフェストを適用する主体と実際にコンテナを動かすノード。エージェントの世界でも同じ分離が起きている。

ただし疑問もある。各社が「誰が実行するか」では合意しているものの、「何を取り戻せるか」では合意していない。状態のポータビリティ、ポリシーの可搬性、ベンダーロックインの回避。これらがどこまで現実的なのか、まだ分からない。セッションログをエクスポートできたとして、別のランタイムで同じように再生できるのか。Agentic AI Foundationの設立など標準化の動きはあるが、実効性は未知数だ。

実務で何が変わるか。チームがClaude Codeを採用すれば、セッションの保持期間と認証情報の管理をAnthropicの設計に委ねることになる。Copilotを選べばMicrosoft 365の信頼境界内で完結する代わりに、その外へは出にくい。選択の基準は「どのエージェントが賢いか」ではなく「どのコントロールプレーンに預けるか」に移りつつある。インフラの選定と同じだ。

E2Eテストが壊れる問題に、AIエージェントが別の道を開く

Slackのエンジニアリングチームが「agentic testing」という取り組みを公開した。従来のE2Eテストは、固定されたステップとセレクタに依存する。UIの構造が変わったり、要素の配置が移動したりするだけでテストが赤になる。機能的な後退がないのに壊れる。この保守コストが、継続的デリバリの現場でずっと問題になっていた。

agentic testingがやろうとしているのは、テストを「厳密な操作手順」から「到達すべき目的」へ書き換えること。AIエージェントが上位の意図を受け取り、アプリケーションの状態を観察しながらアクションを動的に選択する。ボタンの位置が変わっても、別のパスを探して実行を続ける。即座に失敗とはならない。エンジニアが定義したアサーションで最終的な結果を検証する流れだ。

SlackのチームはPlaywright MCPとPlaywright CLI、

（MCP: Model Context Protocol。AIモデルが外部ツールやデータソースに標準化された方法でアクセスするためのオープンプロトコル）エージェントが生成したPlaywrightテストを使い、200以上のagentic E2Eワークフローをテスト用ワークスペースで実行した。ここで一つ明確にしているのは、agentic testingは決定論的テストの置き換えではないということ。クリティカルなロジックや契約の正しさを検証する役割は、従来の決定論的テストが担い続ける。agentic testingが対象にするのは、UIや構造の変化で脆くなりやすいE2Eレイヤーのワークフローだ。

ただし、コストの壁がある。Slackのエンジニアも認めているように、現状ではCIパイプラインでの頻繁な実行よりも、ターゲットを絞ったデバッグや探索的テストに向いている。エージェントの実行には時間も計算資源もかかる。毎回のコミットで回すには、おそらくまだ早い。

それでも面白いのは、テストピラミッドの最上位に「Agentic Testing」という新しい層を置いている点。Unit、Integration、E2Eの上に、ゴール志向で動くエージェントによるテスト層を追加する構成だ。観測可能性も考慮されていて、実行ログが構造化され、エージェントの判断と操作の履歴をトレースできる。失敗時のリプレイと分析ができる設計になっている。

自分がマイクロサービスのE2Eテストを書いていると、まさにこの脆さに悩まされる。セレクタの更新、フローの微調整。機能は変わっていないのにテストだけが赤くなる。agentic testingがどこまで実用になるかは、コストと実行時間の兼ね合い次第だろう。しかし、「目的を渡してエージェントに探索させる」という方向が、E2Eテストの保守問題に対して一つの現実的な解になりうるのかは、もう少し見極めたいところだ。

まとめ

エージェントや自動化は、任せれば任せるほど上手く回るわけではない。Copilotのレビュー精度低下も、EKSのリージョン障害も、同じ教訓を示している。ツールを替えれば指示も替える必要があるし、障害時には自動復旧を止めて待つ設計が必要だ。ブラウジングと調査の違い。自動復旧と静的安定性の違い。タスクや状況に合わせて「どう動かすか」「どこで止めるか」を制御しなければ、自動化は毒になる。

制御の線引きには、成果をどう測るかも含まれる。Anthropicのreflection機能に対する懐疑的な声は的を射ている。AIベンダーが提示するのは利用頻度というエンゲージメントシグナルであって、デリバリーシグナルではない。どの変更がインシデントを引き起こしたか。AIの使い方をAIに判断させる構造的な矛盾を抱えたまま、漫然と利用を増やすことになる。組織が独自に成果指標を定義しなければ、振り返りの意味はない。

エージェントのランタイムやテストのあり方も、制御をどう設計するかの問題だ。Slackのagentic testingは、操作手順という制御を手放し、目的という制御に置き換えることで脆さを回避しようとしている。一方で、エージェントのランタイムを誰が握るかは、インフラのコントロールプレーン選定と同じ重さを持つ。どのベンダーに認証や状態を預けるか。エージェントが賢いかどうかではなく、制御面をどう設計するかで選ぶべきだ。

参照記事

記録日: 2026-07-11