こんにちは。ファインディのTeam+開発部でエンジニアをしている古田（ryu-furuta）です。
この記事は、ファインディエンジニア #2 Advent Calendar 2025の22日目の記事です。
はじめに
2025年下期、私は「DevとOpsを融合する」というミッションを掲げ、問い合わせやアラートといった運用業務の改善にAIをいくつか活用していきました。
この記事では、Claude Code GitHub ActionsやNotion MCPを使った運用業務改善の具体的な実装方法を紹介します。
また、効率化を実現した先に見えてきた「次にやるべきこと」についても共有します。
AIを活用した運用改善を検討している方や、改善施策を打っても成果が出ないと悩んでいる方に読んでいただけると幸いです。
- はじめに
- 問い合わせやアラートに生じていた課題
- Claude Code GitHub Actionsでアラートの初期調査コストを削減
- Notionのデータベースで問い合わせのチケット管理とデータ蓄積
- Notion MCPを使って過去事例の検索と自動調査
- 取り組みの成果
- 今後の取り組み：根本原因の特定と改善の仕組みづくり
- まとめ
問い合わせやアラートに生じていた課題
私が携わるFindy Team+はエンジニア増加による開発チームの細分化・多数の機能リリース・連携するサービスの増加といった変化の中にあります。これにより、問い合わせやアラートなどの機能開発以外の運用業務でも複数の課題が生じていました。
- 問い合わせ/アラートの数が増加して機能開発のボトルネックになっている
- 問い合わせ/アラートに関連した機能・実装のコンテキストを知らないため調査コストが高い
- 問い合わせのやりとりはSlackのスレッドで行っているためステータスが分かりにくい
- 問い合わせのデータが蓄積されないため対策や将来の改善に活かせない
こういった課題を解消すべくAIやツールを活用した改善をこの2025年下期で取り組みました。
Claude Code GitHub Actionsでアラートの初期調査コストを削減
アラート通知はこのようにSentryを経由してSlackへ通知されます。
これだけを見てもどういったエラーでどこで発生したのか分かりません。
そのため従来はSentryのイシュー詳細に遷移し、スタックトレースを確認したり、そこからエディタで関連コードを調査したり、まず 状況把握をするための初期調査コストが高い という問題がありました。
この問題の改善に用いたのがClaude Code GitHub Actionsです。
Claude Code GitHub Actionsは、GitHub ActionsのワークフローからClaude Codeを呼び出せる機能です。
SentryからGitHubのイシューを作成したら自動で次のようなプロンプトのコメントをClaudeにメンションします。
このissueのdescriptionに当リポジトリで発生したエラーが記述されています。 このissueのdescriptionにはSentryのissueのIDが記載されています。 mcp__sentry__get_sentry_issueで記載されたIDのissueの詳細情報を取得してください。 mcp__sentry__get_sentry_issueで取得した結果やエラー発生箇所・周辺ファイルを閲覧し、エラーの発生原因の調査結果をissueのコメントに記載してください。 可能であれば修正対応のプルリクエストを作成してください。 プルリクエストを作成する際は次の3ステップで実行してください： - エラーに対する初期の対応案（ドラフト）を作成してください。 - そのドラフトに対して、どこが良くてどこが改善できるかをレビューしてください。 - レビュー結果をふまえて、より良い最終的な対応案を提示してください。
これによってClaude Code GitHub Actionsが起動し、自動でエラー発生箇所の周辺調査や状況整理、うまく噛み合えばClaudeが作ったプルリクエストをマージするだけで対応が完了する時もあります。
▼実際にClaudeが作成したコメント例
この取り組みによってアラート発生時の初期調査コストを削減することができました。ケースによっては数時間かかっていた調査が数分で状況把握できるようになり、調査開始までの心理的ハードルも下がっています。
Notionのデータベースで問い合わせのチケット管理とデータ蓄積
前述したようにFindy Team+では数年間に渡ってSlackワークフローでの問い合わせ起票を行ってきました。
問い合わせのコミュニケーションに関してはSlackで過不足無いのですが、複数問い合わせが並行するとやりとりを追うのが大変だったり、現在のタスクの状況が分からなくなる問題が度々発生していました。
また問い合わせはプロダクトの改善に繋がる貴重な情報なのにそのデータが蓄積されずフィードバックループを回すことが出来ない、というのも大きな課題でした。
これを一気に解消したのがNotionのデータベースです。
Slackのワークフローでの問い合わせ起票を全てNotion Formに移行し、フォーム送信と同時に問い合わせの情報がデータベースに蓄積されるようになりました。
またデータベースでもチケット管理を行うようにしました。
対応期限のカラムやいわゆる「To Do」「In Progress」「Done」といった値を持ったステータスのカラムを用意し、Zapierを使ってリマインドの機構を設けました。
例えば対応期限を超過してもステータスが「Done」になっていない場合、Slackで担当者へリマインド通知を飛ばすといった自動化も行いました。
▼対応期限超過のリマインドメッセージ
Notionのデータベースを用いることでステータス管理や情報の蓄積が可能になり、問い合わせが抱えていた複数の課題を一気に解消することができました。
また、データが蓄積されることで次に紹介する取り組みにも繋がりました。
Notion MCPを使って過去事例の検索と自動調査
問い合わせ起票時には起票するメンバーに問い合わせに関連した「画面機能」「連携サービス」「メトリクス」といった情報をデータベースに入力してもらうようにしています。
さらに問い合わせの対応が完了したらLLMに問い合わせのやりとりを要約してもらい、その内容もデータベースに保存しています。
これにより半自動的に問い合わせについての情報を拡充していくことができています。
そしてアプリケーションのリポジトリに次の内容のClaude Codeのスラッシュコマンドを作成しました。
--- description: Notion上の問い合わせDBから類似の問い合わせを検索し、原因を調査する --- - $ARGUMENTSは `collection://***` の問い合わせデータベースの中の問い合わせ(ページ)です。 - notion-fetchを使って $ARGUMENTS の問い合わせ内容を確認してください。 - $ARGUMENTS の問い合わせと類似の過去の問い合わせを `collection://***` のデータベースから検索してください。 - 検索の際は`summary`,`detail`,`tag`の各プロパティから類似の問い合わせを検索してください。 - この検索結果から $ARGUMENTS の問い合わせを当リポジトリのコードから調査してください。 - 最終的に次の結果を出力してください。 1. 類似の問い合わせが見つかったかどうか 2. 類似の問い合わせが見つかった場合、その問い合わせIDと概要(summary) 3. $ARGUMENTS の問い合わせの原因調査結果
このスラッシュコマンドは内部でNotion MCPのtoolを利用しています。
これにより過去の問い合わせ情報というコンテキストを持ちながらClaude Codeがより詳細にコード情報を調査することを可能にしています。
出力サンプルを本記事に掲載したいところですが、あまりにも詳細に情報を出力しすぎてしまうため残念ながらここでの掲載は控えさせていただきます。
ただ私自身何度かこのスラッシュコマンドを問い合わせに実行してみて過去に類似問い合わせがあると問い合わせの要因等をかなり詳細に調査してくれることを確認しています。
また過去に類似問い合わせが無いとしても、問い合わせに関連した周辺処理の概況を説明してくれるので全くコンテキストを把握していない機能の問い合わせの調査コストを軽減できていると感じています。
取り組みの成果
今回紹介した取り組みにより、次のような成果を得ることができました。
- 問い合わせやアラートの状況が可視化され、分析可能な基盤が整った
- AIによる初期調査で調査の効率化が実現し、状況把握までの時間を大幅に短縮できた
- チケット管理によりステータスが明確になり、対応漏れを防げるようになった
一方で、可視化や効率化を行うだけでは問い合わせやアラートの件数自体は減少しませんでした。
機能開発が進み、利用者数も増加している中での自然な傾向でもあります。
可視化や効率化は部分的に対応コストを下げるものであり、それだけでは件数を減らす根本的な解決にはなりません。
今後の取り組み：根本原因の特定と改善の仕組みづくり
蓄積された問い合わせデータやアラート傾向を分析し、頻出する問題の根本原因を特定していきます。
暫定対処ではなく恒久対応を行うことで、問い合わせやアラートの件数自体を減らすことを目指します。
たとえば、問い合わせデータを「画面機能」や「連携サービス」ごとに集計し、特定の領域に問い合わせが集中していないかを可視化します。
集中している領域があればUIの改善やドキュメントの拡充、場合によっては機能自体の見直しを検討します。
また、これまでは改善活動に対する明確な行動指針がなく、暫定対処に留まりがちでした。
今後はインセンティブの設計をしっかり行い、改善活動が継続して実施される仕組みを作ります。
具体的には、来期から私も機能開発チームに合流し、改善対応もミッションの一部として進めていきます。
運用業務の当事者として改善に取り組むことで、フィードバックループを確実に回していきます。
まとめ
2025年下期開始当初、自分は昨今のAIの潮流もあって「AIがあれば運用業務の全てを改善できる！」と意気込んでいました。
実際に取り組んだ結果、AIやツールを活用していくらかの問い合わせやアラート対応の「可視化」と「効率化」を実現しました。
しかしこれらは対応を効率化するものであり、件数を減らす根本解決ではありません。今後は蓄積したデータを活用して恒久対応に繋げ、問い合わせやアラートの根本原因を取り除いていきます。
引き続きAIを活用しつつ、改善活動が継続する仕組みを作りながら本質的な改善に挑戦していきます！
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
