Slack上でインフラをトラブルシュートする！ Agentic Platform Engineeringの第一歩

https://studist.connpass.com/event/401612/
AIエージェント時代のPlatform Engineering(2026.09.14)

1. 2026/09/14 AIエージェント時代のPlatform Engineering Slack上でインフラをトラブルシュートする！ Agentic Platform Engineeringの第一歩 Teruya Ono
2. 自己紹介 小野 輝也(Ono Teruya) • SRE/Platform Engineer@Ubie • Like • ◦ Google Cloud ◦ k8s 最近はネットワークエンジニア修行中 @teru0x1 2
3. Ubieについて 3
4. 本日お話しすること • Ubieの内製AI Agent 「infra-agent」 の仕組み • 自律性を保ちながらAI Agentを安全に動かすには • 他の社員にどのように浸透させていくか • AI Agentにうまく働いてもらうために大事なこと 4
5. SRE/Platformチームの課題 • 人間が対応しないといけないことが多すぎる ◦ ◦ トラブルシューティング ▪ 「アプリケーションのデプロイが失敗した」 ▪ 「Terraformのapplyが失敗した」 質問・作業対応 ▪ 「新しいサービスどう立てれば良いか」 ▪ 「これってどういう経緯でこの構成になってるんだっけ」 ▪ 「これレビューして」 5
6. SRE/Platformチームの課題 • 人間が対応しないといけないことが多すぎる ◦ トラブルシューティング AIによってさらに悪化 チームのキャパは限界に近づく ◦ ▪ 「アプリケーションのデプロイが失敗した」 ▪ 「Terraformのapplyが失敗した」 質問・作業対応 ▪ 「新しいサービスどう立てれば良いか」 ▪ 「これってどういう経緯でこの構成になってるんだっけ」 ▪ 「これレビューして」 6
7. そこで生まれたのがinfra-agent • Slack botとして動く内製 AI Agent • GCP, Sentry, GitHub, 社内docsなど各種リソース にアクセス可能 7
8. よくある問い合わせ例 : リリースの失敗 • リリースパイプラインのどこで失敗しているのか切り分け ◦ そもそもビルドが失敗していたりする • デプロイツールのログを見る • コンテナのログを見にいく • 必要に応じて関係者とコミュニケーションをとり原因の究明 8
9. よくある問い合わせ例 : リリースの失敗 • リリースパイプラインのどこで失敗しているのか切り分け ◦ そもそもビルドが失敗していたりする 担当者の時間、認知が取られる • コンテナのログを見にいく リリースの遅延 • 必要に応じて関係者とコミュニケーションをとり原因の究明 • デプロイツールのログを見る 9
10. よくある問い合わせ例 : リリースの失敗 with infra-agent • リリース失敗時に自動的に原因究明 スキルが呼び出される • 人手を介さずに各種ログを調査し、解決 方法を提案。可能なら修正PRまで出す 10
11. infra-agentの思想 • 性質上、外部とのやりとりが多発（github, gcp, sentry etc..) • 必ず防ぐ必要があるもの • ◦ 外部への情報の漏洩 ◦ 本番環境の破壊 単に公式mcpなどのtoolを使うだけではポリシーを強制できない ◦ • 攻撃者が用意したリソースへAgentが書き込んでしまう、などの事故は防げない エージェント自体は多様なツール/コマンドを自由に使う、通信レイヤでポリシーを強制する、 という方針をとった 11
12. infra-agentの実装 • • App ◦ AI Agentの本体。 多様なツールを使える ◦ Proxyへの経路しかないsubnetで動く ◦ 実装はClaude SDK on Cloud Run Proxy ◦ Appからの通信をinternetへ流す ◦ Deep Packet Inspectionをする ▪ PathやHeaderレベルのフィルタリン グが可能（例: GitHubなら /repos/ubie-inc/ のみ許可） ◦ 実装はmitmproxy →Agentとポリシーを実装する層を分離、集約。Proxyだけ気にすれば良い https://zenn.dev/ubie_dev/articles/b712ec880ac038 12
13. 2026/08の利用実態 呼び出し総数 人が投げた依頼の分類（上位） 件数 2,145 回 GCP/GitHubなどの権限・IAM付与依頼 155 PRレビュー依頼 90 ログ・メトリクスの調査 78 仕様の調査 71 障害・原因調査 66 デプロイ・リリース失敗の調査 51 任意のPR作成 32 • 人間: 1,257回 (58.6%) / Bot: 888回 (41.4%) 作成PR / マージ率 284 件 • マージ率: 71.5% リリース失敗に関する問い合わせ数 週平均 1.29 (導入前) → 0.45 13
14. 社内に浸透させるためのポイント • 最初は既に浸透している作業プロセスに統合する ◦ リリース失敗時に特定のSlack通知を見て対応を 開始する、はすでに浸透していたため、多くの人の目 についた • 利用者が拡張可能なプラットフォームにする ◦ infra-agentは社内用Agent Skillsリポジトリから スキルを自動で読む ◦ • 利用者が振る舞いをカスタマイズできる 社内チャットツール(slack, teams)に統合するのが一番 近道 14
15. Slack bot型の良いところ • 中央集権的に管理可能 ◦ 個々人にツールやAgent Skillsのセットアップを要求 しない • 他メンバーとの会話の流れで呼び出せる ◦ 「これアクセスできないんだけど？」「あーそうだ。 @infra-agent 一時権限つけてPR出して」 ◦ • 結果をわざわざ共有する必要もない Slackをハブとして他の既存機構とシームレスに接続できる ◦ 例えば通知系。e2e/デプロイ/エラー発生などの通知が届く ならそれを起点に呼び出せる 15
16. AIにうまく働いてもらうには • 1にも2にもコンテキスト • 社内のナレッジベースを整えることが非常に 重要 ◦ インフラは会社ごとに特有の制約が多いた めコンテキストの重要度は高い ◦ AIで雑に生成するといわゆるAI Slopに なりがちなので注意 ◦ PRから自動生成、みたいなのは大通りが できてからの方がおすすめ • 応用例: 社内用語オントロジー 16
17. まとめ • infra-agentは通信レイヤにセキュリティ要件を押し込めることでエージェントに自由度を持たせている • 既存のプロセスにうまくAgentを差し込む、拡張可能にすることが浸透のポイント • 賢く動いてもらうにはコンテキストをまず整備・メンテしよう 17