記事の概要
ウェルスナビ株式会社が2026年9月26日の「Platform Engineering Kaigi 2026」で発表した資料。同社が内製で開発したSREエージェント「Clione」について、導入背景からアーキテクチャ、安全に使うための設計、継続的な改善の仕組み、そして実際の効果までを体系的に解説しています。
ClioneはEKS上で動作し、開発者とSREの双方がSlackから利用できる自律AIエージェントで、質問・依頼に対して調査からPull Request作成までを自律的に進めます。個別のセットアップや実行環境の準備は不要です。
1. 導入の背景と立ち上がり
課題
- 開発者は開発・調査を早く進めたいが、SREへの問い合わせが必要なケースが多かった
- 開発者ポータルやドキュメント、Software Catalogを整備しても、定型化しにくい個別対応はSlackや依頼チケットでSREへ届き、開発者は回答を待つ必要があった
提供形態の検討
「各々のローカル環境で使う形」と「Slack上で共有して使う形（Slack Bot）」を4つの観点で比較：
| 観点 | 各々のローカル環境 | Slack上で共有（Slack Bot） |
|---|---|---|
| 利用の始めやすさ | MCP / Skillなどの設定が必要 | メンションするだけで使える |
| 使いこなし | 利用者ごとのAI活用習熟度に依存 | SREが用意した機能を同じように使える |
| SREによるサポート | 経緯と結果が個人に閉じ把握しにくい | 経緯と結果がスレッドに残り、SREがサポートできる |
| 実行できる操作 | 開発者の権限下で任意の操作を試せる | 操作・権限を適切に制限する必要がある |
→ 準備なく使えてSREもサポートできるSlack上の共有AIエージェントを選択。
発展の歩み
- 2025年、SREチーム内でSlack上のナレッジ検索Botとして試験利用開始（オンボーディング課題の解消）
- ドキュメント検索・チケット書き込み・過去のやりとり検索・問題調査・Pull Request作成・AWSリソース確認へ機能拡張し、SREエージェントへ成長（MCP導入とモデル進化で精度も向上）
- SREチーム内利用 → 開発者とのスレッドでSREが利用 → 勉強会で使い方と注意点を共有 → 開発者が直接利用へ拡大
2. 調査・変更を進める仕組み
アーキテクチャ構成
- 基盤: EKS上で動作、Claude Agent SDK + Slack Socket Mode
- Skill: MarkdownとしてGitHubで管理し、SREチームがレビュー・更新。目的に応じて使い分け（Pull Request作成Skill、ナレッジ検索Skill、問題調査Skillなど）。エージェント自身にSkill改善のPRを作らせることも可能
- MCP・Custom Toolで Notion / GitHub / Datadog / Slackワークフロー / SRE依頼チケット に接続
- AWS DevOps Agent: AWSリソースの構成・状態、デプロイ履歴などの詳細調査は外部エージェントへ委任。本番用・非本番用のAgent Spaceを呼び分け、両方呼べば環境差分の比較も可能
- Amazon Bedrock AgentCore Memory: 過去の会話の要点を長期記憶として保存し、関連する依頼で参照。ただし「Memoryだけを根拠にせず、変化する情報は現在の情報源も確認する」設計
動作の特徴
- Slackスレッド上のそれまでの会話内容を読んだ上で作業を開始する
- 開発者からの依頼だけでなく、Datadogアラートをトリガーに調査を開始し、結論と根拠をSlackへ返す
内製を選んだ理由
権限・ログなどを自社のルールや目的に合わせて細かく制御するため。例えば「特定Prefixのブランチのみ操作を許可」「Slack投稿やログ出力前にマスキングを適用」「本番/非本番のDevOps Agentを呼び分けて差分比較」といった制御が挙げられます。
3. 安全に使うための設計（本文の核心）
参照・更新対象の制限
- Slack横断検索はパブリックチャンネルのみ、プライベートは呼び出し元の範囲のみ
- GitHubは社内Internal Repository・許可したRepositoryのみ
機密情報の保護
- 前提としてアプリケーションログに機密情報を出さない
- Datadog Sensitive Data Scannerでログ取り込み時にマスキング
- Slack投稿前にもマスキング
- エージェントのログにはTool名・呼び出し元・処理時間のみ記録し、Toolの入出力データは記録しない
外部通信経路の制限
- 汎用的なShell・任意のコード実行・無制限なWebアクセスは与えない
- 用途を限定したMCP・Custom Toolで許可した接続先のみ通信。許可していない接続先は実行前に拒否
LLMの外側に置く多層防御
- 利用できるToolを限定
- 実行前に入力を検査する
PreToolUse Hook - Tool内部のValidation、API実行時にも再検証
- 通信先を許可リストに限定する
AWS Network Firewall - API Token・IAM Role・Repository権限の最小権限
→ プロンプトによる指示に頼らず、いずれかの層で許可条件を満たさない／判定できない場合は機械的に実行を拒否する設計
Pull Requestを利用した変更フロー
- GitOps・IaCを前提に、変更はPull Requestの作成までとし、レビューとマージは人が行う
- 禁止事項: Default Branchへの直接Push、Force Push、Pull Requestのマージ、
.github/やWorkflowの変更
回答の根拠と透明性
- 回答を「確認できた事実／そこから推測した内容／確認できなかったこと」に分けて提示
- Notion・Datadogなど根拠となる情報へのリンクを提示し、推測は推測と明記
- 処理中の内容を表示し、意図と異なる場合はメンションで中断できる
4. 継続的な改善
- Datadog Agent Observabilityでエラー傾向・処理時間・コストなどの動作状況を確認
- Datadog Dashboardでセッション数・Skillごとの利用数・チームごとの利用数を確認（これらを参照できるのはSREだけでなく、SREエージェント自身も同じ情報を参照可能）
- SREエージェント自身による振り返り: Slackワークフローから定期起動し、開発者とのやりとりと自身の動作記録の両方から改善候補を提案。人は確認して取り込む（例: 非効率なTool呼び出しを発見し処理時間を改善）
5. 効果とまとめ
1,117件開発者による利用数（2026年8月）
178件マージしたPR数（同月・エージェント作成分）
約60分→約5分一次回答までの待ち時間（約92%短縮）
Before / After
- Before: 開発者が自分で情報を探す → 解決できなければSREへ相談 → SREの着手を待つ
- After: 開発者が目的・困っていることを相談 → 回答・初期調査・Pull Requestをエージェントが担当 → SREは補足・判断・レビューに集中、開発者は確認・対応
まとめのポイント
- AIエージェントは開発者プラットフォームの構成要素になる
- SREが持っているナレッジをAIエージェントに組み込み、開発者と共有できる
- IaC、GitOps、CI/CDなど、これまで整えてきた仕組みがAIエージェントを動かす土台になる
- 開発者による実際の利用を見て、継続的に改善を進めることが重要
この記事から学べること
- 自律AIエージェントを安全に社内展開する際の権限設計・多層防御・マスキングの具体策が実例ベースで理解できる
- 「ローカル環境 vs Slack共有型」という提供形態の比較軸は、自社でAIエージェントを展開する際の判断材料になる
- GitOps・PRベースの変更フローと組み合わせることで、AIエージェントの変更を人間のレビューで安全に制御するパターンが学べる
- エージェント自身に観測・振り返りさせる「自己改善ループ」の作り方も参考になる