📡
Slack上でインフラのトラブルシューティングができるAgentの設計と実装

Teruya Ono
2026/05/11に公開
SRE
Agent
tech
 はじめにUbieでプラットフォームエンジニア兼SREをしているonoteruです。
今回は、Slackからメンションするだけでインフラの調査や問い合わせ対応を自律的にこなしてくれるBot「Infra Agent」について紹介します。本記事ではInfra Agentの仕組みに加えて、自律駆動するエージェントの挙動をネットワークレベルで安全に制御する1つのアプローチを紹介します。

 背景
 Ubieインフラの運用課題Infra Agentを作った背景として、まずUbieのインフラ運用で日常的に発生していた課題について触れておきます。UbieのSREチームには、調査や問い合わせ対応といったタスクが日々発生しており、それらが積み重なるとチームの時間を相当量消費してしまいます。
たとえばリリース失敗時の調査です。UbieではCloud BuildとCloud Deployを組み合わせてGKEやCloud Runにデプロイしており、パイプラインがやや複雑になっています。リリースが失敗したとき、それがコンテナビルドの失敗なのか、インフラ側の一時的なネットワークエラーなのかは、順を追ってログを見にいかないと判断できません。慣れた人であればすぐに原因を特定できますが、そうでなければ調査に時間がかかり、プラットフォームチームへのエスカレーションが発生します。
開発チームから起票される問い合わせの対応もその一例です。「新しいサービスを立てたいがどう設定すればいいか」「Terraformのapplyが失敗したがどう対処すればいいか」といった質問がSlackで日常的に飛んできます。社内にはインフラに関するドキュメントが整備されていますが、目的のドキュメントを探すだけでも手間がかかりますし、内容を理解するにもインフラの前提知識が必要だったりします。結果として聞いたほうが早いとなり、個別のコンテキストに依存する質問がプラットフォームチームに集まってきます。


日々SREチームに届く質問
こうしたトラブルシューティングやドキュメント検索は、今やAIエージェントが代替してくれる領域です。そこでまずはUbieのインフラ事情を考慮してトラブルシューティングを行うagent skillを社内のエンジニアに配布しました。これによりデプロイ失敗の調査やTerraformのエラー対応といったタスクが、各自のPCで動くClaude CodeやCursorから実行できるようになりました。
この取り組みには一定の効果がありましたが、ローカル型のエージェントゆえの課題も見えてきました。開発者のマシンには重要なデータや認証情報が置かれることが多く、エージェントの操作で環境が壊れると復旧に手間がかかります。またMCPサーバーやツールの設定を各個人がそれぞれの環境に入れる必要があり、セキュリティ設定もまばらになりがちです。さらに、エージェントの実行ログやセッションをチームで共有しにくいという問題もあります。
こうした課題を踏まえると、エージェントをクラウド上に置くアプローチが自然に浮かびます。クラウド型であればサンドボックスによる環境分離ができ、ツールやMCPサーバーの設定も一箇所で管理できます。さらにエージェントの実行ログや結果も容易にチームで共有可能です。
Slackからメンションするだけで調査が走り、結果がスレッドに返ってくる。そんなBotを作れば、ローカル型の課題を解消しつつ、プラットフォームチームの負荷も大きく減らせるのではないか。それがInfra Agentの出発点でした。

 Infra Agentの概要まず何を作ったかの全体像を簡単に紹介します。
Infra AgentはCloud Run上で動作するSlack Botであり、Claude Agent SDKを使ってインフラ調査を実行します。以下のようなツールを利用可能にしています。
gcloud CLI
GitHub
Sentry
Slack
Honeycomb
Terraform Registry
Google Developer Knowledge
Tech Docs(Ubieのインフラに関する社内ドキュメント）
調査対象はインフラ・プラットフォーム領域に限定しています。エージェントがアクセスできるのは、Cloud Monitoringのメトリクスやログ、Cloud BuildやCloud Deployのビルド・デプロイ状況、GitHubのコードやCI/CDログ、SentryのエラーやHoneycombのトレースなどです。プロダクト固有のリソース（アプリケーションランタイム、データベース、シークレット）にはアクセスしない設計としています。

 クラウド型エージェントのセキュリティ課題エージェントの調査能力を最大限に引き出すには、多くのツールを効果的に与える必要があります。例えばgcloudのようなCLIツール、HoneycombやSentryとやり取りするようなMCP tool、さらには柔軟なデータ加工のためのシェルのパイプラインなどです。しかしシェル実行のツールなどを与えてしまうと、エージェントは実質的に任意のコマンドを実行でき、任意のホストへHTTP通信を送れる状態になります。
ローカルで動くエージェントであれば、ユーザーがターミナル上でツール実行の許可・拒否をその場で判断できます。しかしリモートでヘッドレスに動かすエージェントでは、そうしたHuman-in-the-Loopの承認を挟むのが難しく、全ツールを自動承認するモードで動かすことになります。
こうなると当然リスクが出てきます。エージェントが指示を誤解してデータベースを削除してしまったり、機密情報をpublicリポジトリに投稿してしまうかもしれません。また、調査の過程で読み取るSentryのエラーログやGitHub Issueに悪意のある指示が埋め込まれていれば、Prompt Injectionによって機密データを外部に送信させられるリスクもあります。
エージェントの挙動を完璧に制御するのは難しい以上、何かしらのハーネスが必要です。方向性としては、ツールを厳格に実装して攻撃面を最小化するか、エージェントは自由に振る舞わせつつインフラレベルで被害を封じ込めるかが考えられます。理由は後述しますが、Infra Agentでは後者を採用し、アーキテクチャレベルで安全性を担保するような設計にしました。

 アーキテクチャInfra Agentは、大きく二つのコンポーネントで構成されています。
1つ目はこのbotの本体となるinfra-agent appです。Slackからプロンプトを受け取り、Claude Agent SDKを使って調査を実行します。ここではエージェントの自律性を制限せず、シェルやnodejsなどを含んだ与えられたツールを自由に使って調査を行います。
2つ目はinfra-agent proxyです。infra-agent appから外向きのHTTP/HTTPS通信をすべてプロキシし、リクエストのペイロードを検証して問題ないものだけを外部に通します。GCP系API、Slack、GitHub、Sentry、Honeycombなど許可されたホストへの通信のみを許可し、さらにホストごとにパス、メソッド、ボディといったレベルまで検証を行います。
ここで重要なのは、infra-agent appからインターネットへの直接の通信経路が存在しない点です。infra-agent appが動作するCloud Runはsubnet-1に配置されており、このサブネットにはCloud NATを設定していません。VPCカスタムルートにより 0.0.0.0/0 宛のトラフィックはすべてsubnet-2のinfra-agent proxyにルーティングされます。つまりネットワーク経路自体がプロキシを強制する透過プロキシ方式であり、HTTPS_PROXY のようなアプリケーションレベルの設定には一切依存していません。Prompt Injectionでどんなコマンドを実行されても、プロキシを迂回することはできません。
infra-agent proxyはmitmproxyで実装しています。よくあるSandbox機構やネットワーク制御はホスト単位での許可・拒否しかできませんが、ホストレベルの制御では粒度が荒すぎます。たとえばgithub.comを許可すると自組織のリポジトリだけでなく任意のリポジトリにアクセスできてしまいますし、Prompt Injectionで攻撃者のトークンに差し替えられれば、許可済みホストであっても攻撃者のテナントに通信されてしまいます。一方でmitmproxyはTLS通信を復号してHTTPリクエストの中身まで読めるため、URLパスやHTTPヘッダのレベルでフィルタリングが可能になります。フィルタロジックはPythonのアドオンとして記述でき、ホストの許可リスト照合、URLパスによるスコープ制限（例: GitHubなら /repos/ubie-inc/ のみ許可）、Authorizationヘッダの正規トークン検証を行っています。
加えて、Cloud Runのサービスアカウントには最小限のIAM権限のみを付与し、プロキシとあわせた多層防御としています。
つまり、エージェント自体は好き勝手に振る舞える一方で、外部との通信はすべてプロキシが検証・制御するという構造です。エージェントの能力を制限するのではなく、エージェントが外部に与えられる影響を制限するという考え方です。
この方式を採用した理由を、他のアプローチとの比較を通じて説明します。

 他のアプローチとの比較
 エージェントに持たせるツールで制御するプロキシを置かず、エージェントに与えるツール自体を安全に実装することで制御する方式です。Anthropicが公開しているBuilding effective agentsでも紹介されているように、LLMが判断を行うbrainと、実際に外部とやり取りするhandを分離し、handの実装で安全性を担保するというパターンです。
この方式では、エージェントが直接シェルコマンドを実行するのではなく、あらかじめ安全に実装されたカスタムツールだけをエージェントに提供します。APIトークンなどの認証情報もhand側で管理するため、brain（LLM）からは直接触れません。ツールの実装が正しければ、エージェントがどんな指示を受けても破壊的な操作はできないため、プロキシで通信の検査を行わずとも単体で堅牢な構成になります。
ただし、ツールを安全に実装するのはそこまで簡単ではなく、新しいツールを追加するたびに実装とセキュリティ観点でのレビューが必要になります。また、シェルのパイプラインのような柔軟なデータ加工がツール経由では行えないため、エージェントの調査能力が一定制限される懸念もあります。
一方プロキシ方式だと、エージェントにはシェルを含む自由なツールを与えつつ、セキュリティの関心はHTTPリクエストに対するallow/denyというひとつのレイヤーに集約させることができます。特定のHTTPリクエストに対してフィルタが意図通りに許可・拒否するかをテストすれば良いので、検証も容易です。さらに、セキュリティの境界がアプリケーション層ではなくネットワーク層にあるため、今後MCPサーバーを追加したり、CLIツールを入れ替えたり、エージェントの挙動を変えたりしても、プロキシのフィルタが正しく実装されている限りセキュリティは維持されます。いわばセキュリティの責務をアプリケーションからインフラに下ろすことで、エージェントの機能開発とセキュリティの担保を独立して進められるようにしています。
また監査の点においては、mitmproxyがエージェントとは独立して全HTTPリクエストのアクセスログ（許可・ブロック問わず）を記録するため、エージェントがどの外部サービスと通信したかを一元的に追跡できます。Prompt Injectionの試行もブロックログとして残ります。
なおこの二つのアプローチは排他的ではなく、両立させることもできます。Infra Agentでも必要に応じて安全なツールを実装していますが、それだけを信用するのではなく、プロキシによるインフラレベルの封じ込めを最終防御線として位置づけています。

 実際に運用した効果Infra AgentはSlack Botとして動作するため、既存のSlack上のワークフローに自然に組み込むことができました。
一例としては、Cloud Deployの通知チャンネルにInfra Agentを参加させており、失敗通知が来たら自動でトラブルシューティングを開始するようにしています。


デプロイの失敗原因と修正案を提案してくれる
Infra Agentが使ってるClaude Agent SDKの中身はClaude Codeなので、このまま修正してPRを投げることもできます。
さらにSentryのエラー通知についても同様で、通知スレッドからそのままInfra Agentにメンションして調査を依頼できます。普段の会話の流れでシームレスに呼び出せるのが、ローカルのエージェントにはない利点だと感じています。


Sentryアラートからエラーの修正
冒頭の課題として上がっていた問い合わせ対応については、Infra Agentに一次対応を委譲する運用を始めました。プラットフォームチームへの問い合わせチャンネルにInfra Agentを配置し、まずAgentが回答を試みる形です。


AIによる一次回答だけで解決している例
導入前後の2週間で比較したところ、以下のような変化がありました。
チケット件数: 30件 → 24件（-20%）。Agentの回答で解決し、起票が不要になるケースが出てきた
解決までの時間（中央値）: 3.4h → 2.3h（-31%）
AI単独解決率: 0% → 12.5%。人の手を借りずにAgentだけで解決するケースが生まれた
問い合わせのスレッド長（中央値）: 14 → 9.5（-32%）。やり取りがコンパクトになり、関係者の時間が節約された
特にチケット件数の減少と解決時間の短縮は、プラットフォームチームの負荷軽減に直接つながっています。Agentが一次対応で回答やログの収集を済ませてくれるため、人間が対応する際にも必要な情報が揃った状態から始められるようになりました。

 まとめAIエージェントをクラウドで自律的に動作させる際、Prompt Injectionやエージェントの意図しない挙動は避けて通れないリスクです。Infra Agentではこの問題に対して、エージェントの挙動自体を制御するのではなく、仮に問題が起きても被害が出ないようインフラで封じ込める方針を取りました。VPCネットワーク分離と透過プロキシによる多層防御がその具体的な実装です。
こうしたエージェントのセキュリティ制御は、今後プラットフォームレベルでマネージドにサポートされていく流れにあると感じています。AnthropicのManaged Agentsはクレデンシャル分離やネットワーク制御をマネージドで提供し始めていますし、GCPのAgent Gatewayのようなエージェント向けのゲートウェイサービスも登場しています。こうしたプラットフォームが成熟していけば、より手軽に安全なリモートエージェントを運用できるようになるのではないかと期待しています。