はじめに
こんにちは。AIトランスフォーメーション推進部に所属している遠藤怜です。 本記事では、食べログの検索システムの障害対応における初動をSlack上のAIエージェントで効率化した事例について紹介します。
この取り組みはSalesforce主催のイベント「Agentforce World Tour Tokyo 2025」でも事例として紹介されました。
記事内では、AIエージェントをどのように設計・実装し、運用に乗せたかを解説します。
今回作成したAIエージェントは、Slackのスレッドから会話の文脈を読み取り、必要に応じてデータ分析や社内ナレッジ検索、Web検索といったツールを呼び出します。そして、調査結果を整理した上で、状況に応じた回答や提案を行います。
障害対応の流れと役割
本事例における障害対応フローと、AIと人間が協働するための役割分担は以下の通りです。
- 現状把握・原因調査（🤖 AI）
- ログ分析、社内ナレッジ検索、Web検索を行い、状況を整理する
- 対応手順の提案（🤖 AI）
- 調査結果に基づき、具体的な対応手順を提案する
- 妥当性確認・承認（👤 人間）
- AIの提案内容と根拠を確認し、実行するか判断する
- 実行（👤 人間）
- 承認した手順を実行し、復旧させる
安全性を重視して、AIの出力はあくまで「提案」とし、人が妥当性を確認・承認してから実行する Human-in-the-Loop を前提としています。
障害対応の課題
食べログは多くのユーザーに利用されており、検索システムの停止はユーザー体験の悪化に直結するため、1分1秒を争う復旧が求められます。しかし、これまでの障害対応には、迅速かつ正確な対応を阻むいくつかの課題がありました。具体的には以下の3点です。
まず、着手までのタイムラグです。 対応者が障害の通知を受けてから、PCを起動してVPN接続や各種ツールへのログインを経て状況を把握するまでには、どうしても数分間のタイムラグが発生します。このオペレーション上のオーバーヘッドが、初動を遅らせるボトルネックとなっていました。
次に、システム構成の複雑さと属人化です。 複数の検索エンジンやAPI層が連携しているため、障害発生時には大量のログから「どこで」「何が」起きているかを瞬時に特定しなければなりません。この調査にはシステム全体への深い理解が必要となり、どうしても特定の経験者に依存（属人化）しやすいという課題がありました。
そして、復旧手順の難しさと心理的負担です。 高トラフィック環境では、単純な再起動は二次障害を招くリスクがあるため、流入制御などを含めた慎重なオペレーションが不可欠です。緊迫した状況下、特にパフォーマンスが低下しやすい夜間対応などにおいて、ミスが許されない判断を迫られることは、対応者にとって大きな心理的負担となっていました。
これらの課題に対し、AIエージェントを活用して以下のような解決を図りました。
- 初動の自動化: アラートをトリガーにAIエージェントが即座に調査を開始し、対応者が着手する時点で状況把握と手順提案を完了させておくことで、タイムラグを解消する
- 調査の標準化: ログ分析やナレッジ検索をAIエージェントが代行・集約することで、スキルや経験への依存を減らし、属人化を防ぐ
- 負担の軽減: 対応者が作業を開始する時点ではAIエージェントによって状況整理や原因の当たり付けが済んでいるため、対応者は「ゼロからの調査」ではなく「報告の確認」から着手でき、心理的負担を軽減できる
Slack上で動かす理由
2025年、カカクコム全社でチャットツールがSlackに移行しました。 この移行を機に、今回の取り組みではSalesforceが提唱する「Slack is Agentic OS」というコンセプトを実践しました。これは、Slackを単なるチャットツールとしてではなく、人間とAIが協働するための統合環境として捉える考え方です。
障害対応を効率化するため、「コミュニケーション」「データ」「ツール連携」をSlackに集約し、会話の流れの中で自然にAIエージェントを利用できるようにすることで、人間とAIのスムーズな連携を目指しました。
具体的には、チーム全員が見ているチャンネルのスレッド上でAIエージェントを動かす設計にしました。
これにより、会話の文脈に沿ってAIエージェントが必要な情報を収集・整理し、その結果をそのままスレッドに残せます。
結果として、ツールや画面の切り替えが減り、対応者のコンテキストスイッチを抑えられます。
また、調査プロセスが可視化されることで、リアルタイムな状況共有やスムーズな引き継ぎ、属人化の抑制にもつながると考えました。
作成したAIエージェント
利用の流れ
AIエージェントは障害のアラート通知をトリガーとして、自動的に調査を開始します。 具体的な流れは以下のとおりです。
- アラート通知: 監視システムから、対応者への電話連絡と同時にSlackにアラートが投稿される
- メンション検知: アラートの通知文面にあらかじめAIエージェントへのメンションを埋め込んでおくことで、AIエージェントが呼び出される
- 調査開始: 呼び出されたAIエージェントはアラートの内容を読み取り、調査を開始する
これにより、アラート発生と同時にAIエージェントが調査を開始するため、初動の遅れを短縮できます。 対応者が通知に気づいてSlackを開いたときには、すでに調査が進行し、対応手順の提案まで完了しています。人間は「ゼロから調査する」のではなく、「AIの報告を確認する」ところからスタートできます。 着手時点で状況の見通しが立っているため、対応スピードが上がり、心理的負担も軽減されます。
プロンプトの内容
AIエージェントには、初動として以下のタスクを実行するように指示しています。
- 現状把握: いつから、どのシステムで、どんな影響が出ているかをまとめる
- 原因調査: ログ・社内ナレッジ・Web情報から事実を集め、あり得る原因の当たりを付ける
- 対応手順の提案: 既存の手順書（社内ナレッジ）をベースに、状況に合わせた対応手順を提案する
実際のシステムプロンプトは以下のようになっています（内容は一部抜粋・簡略化しています）。
あなたは食べログの検索システムの障害対応AIエージェントです。 ## 行動方針 - 事実はツールで確認してから回答する - 出力には出典を必ず明記する - 指示に不明点があれば対応者へ質問する ## 前提知識 - 検索システムは、複数の機能領域（例: レストラン検索、サジェスト等）に分かれている - システムは、検索エンジンと、その前段でリクエストを受けるAPI層から構成される ## 障害対応手順の作成 アラートを受け取り、障害対応手順の作成を指示された場合に、以下の流れで進める。 1. 現状の把握 - Confluenceで食べログ検索の構成や運用を調査して把握 - 関連するアラートを確認 - BigQueryでエラーログやQPSを確認 - いつから、どのシステムで、どのような障害が発生しており、どのような影響があるかをまとめ、把握結果を出力 2. 原因の調査 - ConfluenceとWebで類似事例や技術情報を調査 - 収集した情報から仮説を立て、調査結果を出力 3. 対応手順を提案 - Confluenceで障害対応手順を調査 - これまでの調査結果や収集した情報をもとに、具体的な対応手順を作成して出力 ## ツール実行時の回答フォーマット ### BigQuery分析 出典として実行したSQLクエリを出力する。 例: SELECT * FROM ... ### Confluence検索 出典として参照したページのリンクを出力する。 例: [ページタイトル](https://xxx/<スペース>/pages/<ページID>) ### Web検索 出典として参照したページのリンクを出力する。 例: [タイトル0](URL0)
プロンプトの工夫
プロンプトの設計において特に重視したのが、提案や仮説の検証のしやすさです。対応者が「なぜその結論に至ったのか」を追跡できるよう、実行したSQLや参照したページのリンクを必ず出典として明記させることで、Human-in-the-Loopを確実に機能させています。
あわせて、応答の即時性を高めるため、調査結果を一度にまとめて返すのではなく、現状把握・原因調査・対応手順提案の各フェーズで逐次出力するようにしました。 すべての処理が完了するまで待つと2〜3分ほどかかりますが、フェーズごとに結果を返すことで、AIエージェントが後続の処理を進めている間に対応者が先行して内容を確認でき、判断と次のアクションへ迅速に移れます。
全体の仕組み
全体像は次のような構成です。AIエージェントは、必要な情報をツールを使って取得します。
- Cloud Run
- メンションイベントを受け取り、スレッド情報を取得する
- Agent Engine（Vertex AI Agent Engine）
- AIによる推論、ツール呼び出し、セッション管理など「エージェントとしての振る舞い」を担う
- エージェントが呼び出すツール
- BigQuery（データ基盤）分析: エラー傾向、QPS（Queries Per Second）、特定ステータスの増加などを確認する（読み取り専用に設定）
- Confluence（社内Wiki）検索: システム構成、運用手順、過去事例などを検索する（読み取り専用に設定）
- Web検索: ミドルウェアの公式ドキュメントや既知Issueなど、社外情報を補完する
- アラートの取得: トリガーとなったアラートや、その後に発生したアラートの本文・発生時刻を取得し、調査に反映する
技術選定
エージェント実装のフレームワークには様々な選択肢があるため、ADK（Agent Development Kit）やLangGraphなどを比較しました。最終的には、運用コスト面を重視し、GoogleのADKを採用しました。
- 組織の標準クラウドであるGoogle Cloudと相性が良い
- BigQuery等の連携がしやすい
- 既存の運用基盤に自然に乗せられる
- Agent Engineと組み合わせることにより、エージェントの実行基盤をフルマネージドにできる
- スケールやデプロイといった運用をサービス側に委ねられる
- セッション管理などの共通機能を自前実装せずに済む
実際に使ってみて、Agent Engineにデプロイするだけでダッシュボードやプレイグラウンドが用意され、動作検証しやすかった点も開発上のメリットでした。
UXの工夫
Slack上での使い勝手を良くするために、いくつか工夫しました。
人とAIの会話を共存させる設計
AIエージェントは、メンションされた場合にのみ応答するように設計しました。
技術的には、スレッド内のすべての返信に自動的に反応させることも可能です。 しかし、障害対応のスレッド内では、対応メンバーでの議論や関係者への状況共有など、人間同士の会話も頻繁に行われます。 そこにAIエージェントが毎回反応して割り込んでしまうと、スムーズな連携の妨げになります。
そのため、あえて毎回メンションを必須にしました。これにより、人間同士の会話を阻害せず、必要なタイミングでのみAIエージェントを呼び出せるようにしています。
この設計により、AIエージェントによる調査結果と、それを受けた人間の判断や議論を1つのスレッドに集約できます。結果として、スレッドを見れば対応の全経緯（調査データ、議論、決定事項）が時系列で把握できる状態を作れました。
不安を減らす進捗表示
障害対応では、AIエージェントの待ち時間が数十秒あるだけでも、対応者は不安になります。「固まったのか？」「いま何をしているのか？」が分からないからです。 そのため、「いま何をしているか」を対応者へ逐一フィードバックする設計にしました。
具体的には、まず処理の開始を伝え、その後のツール実行の進捗状況をリアルタイムに表示し続けます。これにより、対応者はAIエージェントが止まっていないことを視覚的に確認でき、安心して結果を待てるようになります。
これは、進捗表示用の投稿メッセージの本文を随時更新することで実装しています。
ちなみに、Slackの新しいAIアシスタント専用UIである「Assistant View」には、set_statusというネイティブな進捗表示機能が存在します。
執筆時点（2026年1月）ではset_statusは通常のスレッドでは動作しなかったため今回は使用していませんが、見栄えの良い進捗表示が簡単に実装できるので、Assistant Viewを利用する際はぜひ試してみてください。
ストリーミング投稿の採用
AIエージェントが生成した長文のMarkdownをSlack上で読みやすく表示するため、メッセージの投稿は chat_stream を使ったストリーミング投稿方式にしました。
この方式を採用した背景には、従来の投稿方式における課題があります。
まず、一覧性の低下です。
通常、Slack Bolt（Slackアプリ開発フレームワーク）でメッセージを送信する際はchat_postMessageを使います。しかし、この投稿方式で長文を投稿すると、Slackクライアント上ではメッセージが途中で省略され、「続きを見る」ボタンで折りたたまれて表示されてしまいます。
特に今回のように応答を逐次出力しようとすると、各出力がすべて折りたたまれてしまいます。結果として、AIエージェントの1つの応答の途中で何度も「続きを見る」を開く手間が発生し、体験が悪くなっていました。
次に、変換処理の実装コストです。
chat_postMessageでは、本文をSlack独自のマークアップ記法であるmrkdwn形式で渡す必要があるため、AIエージェントが生成したMarkdownをmrkdwnに変換する処理も必要になります。
chat_postMessageを使ったPythonでの実装イメージは以下の通りです。
client.chat_postMessage(
channel=channel_id,
thread_ts=thread_ts,
text=text,
blocks=[
{
"type": "section",
"text": {"type": "mrkdwn", "text": mrkdwn_text},
}
],
)
このような課題がある中、AIが生成した文章を投稿するためのストリーミング投稿が2025年10月に登場しました。
この方式により、長文でも折りたたまれず表示されるようになり、一覧性の低下という課題を解決できました。また、Markdownをそのまま渡せるようになったため、変換処理の実装コストも解消されています。 さらに、生成された文章を少しずつ流せるようになりました。
stream = client.chat_stream(channel=channel_id, thread_ts=thread_ts) for chunk in chunks: stream.append(markdown_text=chunk) # mrkdwnではなくMarkdownを渡せる stream.stop()
このストリーミング投稿は非常に便利なので、Slack上で動くAIエージェントを作成する際には、ぜひ使ってみてください。
スレッド乱立の防止
AIエージェントの実装だけでなく、周辺の仕組みも工夫しました。
1つの障害で類似アラートが連投されると、AIエージェントもその数だけ動き、スレッドが乱立してしまいます。対応者も「どこで対応すべきか」迷いやすくなります。
そのため、アラート送信側で「発生時刻」と「発生システム」でアラートをグルーピングし、最初のアラートのみをSlackに投稿してAIエージェントを起動するようにしました。
これにより、必要以上にスレッドが増えないように制御しています。
導入後の利用状況
現在、AIエージェントは平時のデータ分析や運用トラブルへの対応において積極的に活用されており、日々の運用をサポートしています。
導入後は幸いにも検索システムが安定しており、緊急の障害対応が必要な場面にはほとんど遭遇していません。そのため、障害対応における十分な効果検証はこれからとなりますが、すでに以下のような場面で具体的な成果が出ています。
データ分析の効率化
頻繁に利用されているのが、エラー状況の確認です。Slack上でざっくりと依頼するだけでも、意図を汲み取って必要なデータを集計してくれます。
実際に利用している運用チームのメンバーからは、以下のような声が寄せられています。
- クエリ作成の手間がなくなった: 「自分でBigQueryを叩く場合、集計の目的ごとにクエリのテンプレートを探したり、粒度（時間単位やIP単位など）を変えるためのクエリ修正に時間がかかっていました。AIエージェントなら目的に合わせてクエリ作成から実行まで行ってくれるため、これらの作業に時間がとられなくなり便利です」
- 分析のハードルが下がった: 「以前はBigQueryで分析するには、まとまった時間を確保してじっくり取り組む必要がありました。導入後は準備コストなく、気になったらすぐにSlackへ投げてリアルタイムに分析を進められるようになりました」
- チーム内の状況共有がスムーズになった: 「Slackで手軽に依頼できる点が良いです。また、分析の依頼や結果がスレッドに残るため、他のメンバーが何を調べているかが可視化され、チーム内で今どのような問題が起きているのかの把握や共有もしやすくなりました」
運用トラブル対応でのリスク防止
効率化にとどまらず、既存の手順書だけではカバーしきれない状況下で、リスクを未然に防ぐ場面もありました。
検索システムを再起動するジョブが失敗した際、手順書には「ジョブを再実行する」と書かれていました。しかし、失敗箇所によってはそのまま再実行した場合、検索システムのレプリカ数が一時的に減り、可用性の低下につながるリスクがありました。
これに対して、AIエージェントは問題が起きている箇所に絞って対応する手順を提案し、手順書の通りに再実行するよりも影響範囲を抑えられる手順を提示しました。結果として、不要に広い範囲へ影響を波及させずに、リスクを抑えた対応につなげられました。
今後の展開
今後の方向性としては、大きく3つあります。
1つ目は、展開範囲の拡大です。検索システム以外の領域（食べログ本体や他サービス）や、障害対応以外（問い合わせ対応など）へ、同様の仕組みを展開していきたいと考えています。
2つ目は、連携ツールの拡充です。現状はログ・社内ナレッジ・Web検索が中心ですが、例えばコード参照など、利用可能なツールを増やすことで、障害対応の質のさらなる向上を図ります。また、AIエージェントができることの幅を広げ、より多様な業務領域で利便性を高めていきたいと考えています。
3つ目は、手順実行の自動化です。理想は「人間が承認ボタンを押せば、あとはAIエージェントが実行する」世界です。現時点ではクラウドから検索システム本体へ到達するための経路などの技術的な課題があるため、それを解消できた段階で取り組みたいと考えています。
まとめ
本記事では、食べログ検索の障害対応における初動を、Slack上のAIエージェントで効率化した事例を紹介しました。
この取り組みを通じて得られた、人と協働するAIエージェント設計のポイントは以下の通りです。
- 適切な役割分担: AIだけですべてを自動化するのではなく、人間による承認を前提とした役割分担（Human-in-the-Loop）とし、安全かつ効率的な協働を実現する
- 情報の集約: 調査結果や議論をスレッドに集約し、状況共有を効率化するとともに、AIとも文脈を共有して連携をスムーズにする
- 判断根拠の可視化: 出典の明記により、AIによる提案の妥当性を確認し、安心して意思決定を行えるようにする
- 不安を解消するUX: 進捗表示などで待ち時間のストレスを最小化し、対応者の不安を取り除くことで現場への定着を図る
今回の事例が、皆様の現場でAIを運用に組み込む際の参考になれば幸いです。
AIトランスフォーメーション推進部では、今回紹介した事例をはじめとするさまざまな生成AI活用プロジェクトを推進しています。 生成AI活用プラットフォームの改善や、生成AI活用ソリューションを創り上げることに興味がある方など、幅広く募集しています。 カジュアル面談だけでも歓迎ですので、ご連絡お待ちしています。
