1. はじめに
こんにちは、システム基盤チームでSREをしている安藤と申します。普段はDB負荷の改善、開発者プラットフォーム改善、AIOpsなどに取り組んでいます。
今回はSREが所属するシステム基盤チームのAI活用事例と今後の展望をご紹介したいと思います。
システム基盤チームにおけるAIOps
システム基盤チームにおけるAIOpsとは、AIを活用して日々増大する運用課題を根本から効率化・自動化し、成長フェーズの組織を支えるプラットフォームを実現する取り組みです。
私たちは現在、開発組織の拡大とプロダクト数の増加が同時に進む10→100フェーズを迎えており、10倍規模を見据えた基盤の構築に取り組んでいます。（詳しくは弊チームマネージャーが執筆したこちらの記事をご覧ください。）
このような急激な拡大環境において、自動化に踏み込みにくい領域はスピードと品質の両立が困難であり、AIによる自動化・支援が不可欠であると考えています。
AIOpsで目指すのは、こうした技術の活用・自動化を通じてチームのパフォーマンスを最大化し、組織の成長をしっかりと支えていける基盤を実現することです。
次のセクションから今まで自動化が難しかった3つの領域における、具体的なAI活用事例について紹介していきます。
- オンボーディング支援
- 運用業務の効率化
- コードレビュー改善
2. オンボーディング支援
オンボーディングの課題・背景
新しく入ったメンバーは、業務に必要な専門知識（ドメイン知識）を理解するのに時間がかかり、スムーズに仕事を始めるのが難しいという課題がありました。
また、既存のメンバーも、日々の雑務やドキュメントの整理、レポート作成などに多くの時間を取られ、重要な業務に集中しづらい状況でした。
こうした課題を解決するために、まずナレッジベースを活用したAIアシスタントの導入を決定しました。
RAGを使用したオンボーディング支援
当初は Bedrock Knowledge Bases（RAG）を使って Slack Bot を構築し、社内用語や略語を気軽に質問できる環境を整えることを目指しました。これにより、スムーズなオンボーディングやキャッチアップを支援できる状態を理想としていました。
しかし以下のような問題に直面し、本格的に運用していくのはまだ難しい状況でした。
シンプルに精度が低い
当初、チャンキング戦略が不適切で、チャンクサイズが小さすぎるまま進めてしまったため、精度が低い状況でした。
そのため以下のように一般的な回答をしたり整合性のない回答をしてしまい、社内の情報や会社固有のナレッジに関する質問には答えることができない状況でした。
ナレッジ更新の負担
最新の情報をとってくることができないので新しいドキュメントは都度、ナレッジベースに追加して更新していく必要がありました。
現在はGitHub ActionsやMakefileで自動化を進め改善することができましたが、当初は自動化の仕組みを作るまで手が回らず、手動での更新により負担がかかっていました。
なお、後述するMCP導入後も引き続きこのナレッジベースは検索のベースとして活用していきます。
MCP活用へ
試行錯誤を繰り返し、チャンキング戦略の比較検証を行い階層型チャンキングを採用したり、ベクトルストアのパラメータ調整を行ったりすることである程度精度を向上させることに成功しました。
しかし参照元がBedrock knowledge Baseに限られる構成では根本的な精度向上に限界を感じていました。
そこで、NotionやSlackといったSaaSツールをリアルタイムに横断できる MCP サーバーであれば、最新情報・スレッド・設計資料といった多様なコンテキストを統合し、さらに柔軟で高精度な応答が可能ではないかと判断し、MCP導入に踏み切りました。
構成について
今回のMCP導入では、EKS上にデプロイしたmcp-serverを、Slack Bot経由で操作する構成を採用しました。構成図は以下のとおりです。（構成図は簡略化しています）
メンションされたリクエストはEKS上で稼働するmcp-serverに送られ、LLM呼び出し（Azure OpenAIのo4-miniやBedrock上のClaude Sonnet 4）→ツール実行→Slackにて回答が送られるような仕組みです。
従来のMCPは個人のローカル環境での利用が中心でしたが、Slack Bot + EKS構成によりシステム基盤チームの標準MCPを実現することができました。
MCPをリモートで稼働させるメリットとしては以下の通りです。
-
利用ハードルの低下
- Slack Botにメンションするだけで使用できるため複雑な実装などは不要で、誰でも簡単に利用することができます。
-
セキュリティの向上
- MCP Client の設定ファイルに認証情報や API キーを個々の端末で管理する必要がなくなり、Secrets Managerで一元管理できるためより安全に利用することができます。
MCP導入効果
MCP Slack BotにWealthnaviの取引システムについて尋ねるとうまく回答することができ、現在行われている取り組みについても回答することができました。これにより回答の精度は格段に向上し、RAGの最新情報を取得することができないという課題も解決することができました。
3. 運用業務の効率化
MCP Slack Botの導入によりAI活用の幅は大きく広がりました。そこでシステム基盤チームにランダムに割り当たるインフラチケットと呼ばれる運用タスクにも活用できるのではないかと考え、さらに守備範囲を広げていきました。
インフラチケットの例としては以下のようなものがあります。
- Warningレベルアラートの対応
- 開発チームからの問い合わせ対応
- AWS Health Evnetなどの定期メンテナンス作業
インフラチケットの課題・背景
インフラチケットには、新規メンバーの理解・対応が難しいというオンボーディングの課題に加えて、以下のような課題がありました。
低頻度タスクの対応手順忘れ
発生頻度が稀なタスクでは、既存メンバーでも過去に対応したことがあっても手順を正確に思い出せず、毎回調査から始める必要がありました。
即時対応が必要なケースでは属人化が進行
即時対応が必要なものは、知識のある担当者が素早く対処してしまうため、他のメンバーが対応スキルを習得する機会が限られてしまいます。
活用事例
アラート検知後、担当者がランダムにメンションされる処理に、MCP Slack Botへのメンションを追加しました。
これにより、インフラチケットのスレッド上で、自動的に対応手順が表示されるようになりました。
以下はアラートを検知し、botが対応手順を提示してくれる流れを書いた図です。
導入効果
過去の対応履歴をSlackの会話から取得し、類似ケースを確認することができたり、Notionにまとまっている設計書や手順書のリンクを提示してくれたりしました。
さらに誰に相談すれば良いかまで提示してくれるので、対応スピードは大幅にアップし属人化が進行していた問題も解消することに成功しました。
実際の出力例
4. PR AgentとCopilot code reviewによるコードレビュー改善
システム基盤チームではAIコードレビューツールにPR AgentとGitHub Copilot code reviewを導入し効果的な運用を目指しました。
導入当初、GitHub Copilot code reviewはTerraformに対応しておらず、PR-Agentでないとレビューすることができませんでした。そのため、TerraformをはじめとするIaCのレビューはPR Agentに任せつつ、Copilot code reviewを補完的に活用する運用を開始しました。
導入理由
- 新規プロダクトの増加やチーム拡大により、レビューの件数とボリュームが急増することで、レビュアーの負担が大きくなりました。
- 結果としてレビュー速度と品質維持の両立が難しい状況に直面しました。
具体的には、以下のような課題がありました。
-
変更の概要が適切に記載されていない
- レビュイーが変更の背景や目的を適切に記載していないケースがありました。
- その結果、レビュアーがコードの意図を正しく把握するのに時間がかかってしまいました。
-
指摘漏れの発生
- レビュアーの負担が増加したことによりタイポや非推奨の記法、アンチパターンといった基本的なコーディングミスの見落としが増えていました。
- 品質の低下や余分な修正コストにつながる恐れがありました。
２つのツールを同時に導入した結果を様々な観点から評価してみました。
導入ツールの比較
Copilot code reviewが当初、terraform非対応だったこともありシステム基盤チームではPR-Agentをメインで使用しています。
| 項目 | PR Agent | Copilot code review |
|---|---|---|
| 精度・信頼性 | ◎ セキュリティ指摘・SQL可読性・品質改善に高精度対応 | ◯ typo／文法チェック中心。Terraform の文法チェック・サジェストが可能だが、高精度なレビューはPR Agentより劣る |
| 自動要約・改善案 | ◎ describeで要約、improveで改善案。テンプレートも見やすい |
◯ 要約あり。改善提案は限定的 |
| 対応言語・フォーマット | ◎ Golang・Terraform・SQL 等に幅広く対応しておりほとんど網羅できている。 | ◯ 一般開発言語中心。Terraformは簡単な文法チェック・サジェストなら可能 |
| コスト | ◯ 弊チームではBedrock 経由で使用しているため使用するモデルに準拠する。 Claude Sonnet 4の場合: 入力$3、出力$15／Mトークン |
◎ GitHub Enterprise に含まれるため追加費用なし |
| 導入／運用工数 | ◯ .pr_agent.toml設定 + GitHub Actions ワークフローの準備が必要 |
◎ GitHub 上で即使えてセットアップ不要 |
| 採用状況 | ◎ 精度と出力品質の高さから、PR Agentを優先的に利用 | ◯ 軽度なレビューに定着 |
PR Agentは文法チェックの他、セキュリティ懸念などにもレビューが行き届いています。
PR Agentによる指摘の概要
画像はDBのテーブルレコード数やサイズ数を取得するクエリに対して、パフォーマンスを考慮した改善提案を行ってくれた事例です。
実際の指摘事項
導入による効果
AI レビューツールの導入によって今までPR作成→レビュー依頼だったのがPR作成→AIレビューの指摘を修正→レビュー依頼というフローに定着しました。これにより今まで気づけなかった細かいコーディングミスは激減し、レビュー速度と品質維持の両立が難しいという課題を解消することに成功しました。
5. 今後の展望
これまでオンボーディング支援や運用業務の効率化といった領域でAI活用を進めてきましたが、今後はさらに日常業務の効率化を目的として、以下のような取り組みを進めていく予定です。
Claude Code Action の活用による開発支援の強化
現在、AI関連の開発やPoCは限られた人数で進めており、リソースが不足している状況です。AIを活用した取り組み自体はチーム内でもニーズが高まっている一方で、エンジニアの工数が追いついていないという課題があります。
そこでClaude Code Actionの導入を考えています。GitHubに立てたIssueをトリガーにコードの修正・提案などを行い、自動的にIssueの内容に応じたPull Requestを生成してくれるような環境の構築を目指していきます。
またClaude Code Actionが生成したコードを、前述したPR Agentがレビューすることで、AI同士が連携してタスクを完結させるような開発プロセスも十分可能であると考えています。
AWSコストの自動分析・最適化
現在、AWS利用料金に関してはCost Explorerのデータを手動で確認し、Notionにまとめる といった運用を行っていますが、ある程度工数のかかる作業であり担当者の負担になっています。
今後はMCPから定期的にコストデータを取得し、レポート作成→コスト分析・最適化のフローを実現しFinOps推進にも役立てていきたいと考えています。
6. おわりに
システム基盤チームでは、10→100フェーズという急激な成長期において、AI活用によりチームの生産性向上と運用品質の両立を実現してきました。
RAGによるナレッジベース構築から始まり、MCP導入によるオンボーディング支援、運用業務の効率化、そしてAIコードレビューツールの活用まで、AI活用の範囲を拡大してきました。
特にMCPのリモート稼働によるSlack Bot化は、個人環境に依存しない標準的なAI活用基盤として大きな成果を上げることができました。
今後もAI活用の幅を広げていき、組織全体のパフォーマンス最大化を目指していきます。
この事例紹介が、同様の課題を抱える方々の参考になれば幸いです。
著者プロフィール
システム基盤グループ システム基盤チーム
安藤（あんどう）
Discussion