はじめに
こんにちは。リクルートの横断データプロダクト「Crois (クロイス)」の開発運用に携わっている南川です。
この記事では、2025年9月29日・30日に開催された POST Dev 2025 で発表した「リクルートの横断データプロダクト Crois での AIOps を活用したアラート対応」について、実際の取り組みや得られた知見を紹介します。
Crois はリクルートの様々な事業領域でデータ利活用を支える横断データプロダクトです。
利用量の増加に伴い、運用業務の工数も増加しています。
そこで、AI による運用業務改善の必要性が高まり、AIOps 導入に取り組んでいます。
本記事では、発表当時の情報をもとに、 Crois における AIOps を活用したアラート対応の実例や、導入のポイント・今後の展望について解説します。
横断データプロダクト「Crois」とは
Crois とは、ワークフローエンジン・ジョブスケジューラ機能を提供する横断データプロダクトです。
様々な事業領域において、機械学習の学習・推論、ETL をはじめ、多様なジョブが実行されています。
Crois は1日あたり2万件以上のジョブと8万件以上のコンテナタスクを実行しています。
ジョブとは Crois で作成したワークフローを実行したものであり、詳細画面 (図1) ではジョブのステータス (実行中、成功、失敗など) や開始時刻、タスクのログを確認することができます。
ワークフローには複数のタスクが含まれており、それぞれのタスクはコンテナタスクとして実行されます。
コントロールプレーンは AWS 上に構築され、コンテナタスク実行環境は AWS/Google Cloud 両方を提供しています。
図1 ジョブの詳細画面
Crois は2019年にリリースされました。
この6年間で、各事業領域でのデータ利活用の拡大を経て、年々利用量が増え続けています (図2) 。
また、それに伴い、利用者からの依頼や問い合わせ、アラートへの対応工数も増え続けています。
そのため、AI による運用業務改善が求められています。
図2 四半期ごとのジョブの実行数の推移グラフ
Crois については本記事以外にも関連記事が公開されているため、興味のある方はそちらもご確認ください。
AIOps 導入の目的
AIOps (Artificial Intelligence for IT Operations) とは、IT 運用の効率を向上させるために人工知能を活用する手法です。
AIOps 導入の目的は以下の2つです。
- Crois の運用業務に AI エージェントを取り入れ、運用工数を削減する。
- 対応コスト・習得コストの高い運用タスクを AI エージェントで代替できるか検証する。
先日公開された記事「AI エージェントによるプロダクト運用の自動化 - 社内横断プロダクト Crois における AIOps の実践」では、 Crois における AIOps 導入の全体像や技術的なアーキテクチャ、問い合わせ対応の事例について紹介しました。
そこで本記事では、POST Dev 2025での発表内容に基づき、AIOps の中でも特に 「アラート対応」の領域にフォーカスします。
単に AI を導入しただけでなく、 「人間用の手順書（ランブック）の質が、 AI の成果にどう直結したか」 という、導入後の具体的な検証結果や試行錯誤のプロセスを中心にお話しします。
今回のアラート対応における AIOps 活用では、AI エージェントが Crois で発生したアラート (例:定期実行されるヘルスチェックの失敗、API サーバーのエラーなど) に対する一次調査 (ログ調査、原因特定、対応策の提案など) を行います。
AI エージェントは調査に留め、リカバリ対応といった破壊的な変更は行わず、運用チームが調査結果をもとに判断し、対応を行います。
AIOps 導入前のアラート対応フロー
ここで、AIOps 導入前のアラート対応フローに触れておきます。
まず、AWS の各種リソースに対する CloudWatch のアラームが発火すると、Slack のアラートチャンネルに通知されます (図3) 。
図3 アラート発生から Slack 通知までの流れ
この Slack 通知 (図4) にはアラートの説明やランブックへのリンク、CloudWatch アラームへのリンクなどが記載されています。
図4 アラート発生時の Slack 通知
そして、運用チームはランブックに従って調査を行い、必要に応じてリカバリ対応や開発チームへの共有、広報、チケット作成などを行っています。
ランブック
ランブックとは、アラートに対する対応手順書であり、アラートごとにランブックが用意されています。
ランブックには以下のような内容が記載されています。
- アラートの背景
- 発報条件
- 対応手順フローチャート
- 調査・対応手順
- 各種エラーについて
- エラーの原因・背景
- 個別の対応手順
- エラーログのサンプル
アラート固有のランブックの例を図5に示します。
図5 アラート固有のランブックの例
また、発生するアラートも多種多様であり、ランブックがまだ整備されていないアラートも存在します。
そのようなアラートに対する共通ランブックというものも用意しており、汎用的な調査手順を記載しています (図6) 。
図6 共通ランブック
アラート対応の難しさ
Crois は以下のような要因で複雑なシステムとなっており、アラート調査・対応の難易度が高いです。
- 複数のクラスタ
- 50個以上の Lambda
- Step Functions による連携
- マルチクラウド (AWS/Google Cloud)
そのため、調査コストが高いことや、調査の質が運用担当者のスキルレベルに左右されてしまうといった課題があります。
そのような背景から、AIOps 導入による調査コストの削減と調査の質の担保を目指しています。
AIOps 導入後のアラート対応フロー
AIOps 導入後のアラート対応フロー (図7) は以下の通りです。
CloudWatch のアラーム発火から Slack への通知までは AIOps 導入前のフローと同じですが、その後、Slack 上で AI エージェントを呼び出し、一次調査を行います。
AI エージェントには、アラートの内容や発生日時、ランブックの本文などの情報が与えられます。
AI エージェントの調査結果と調査の過程から、運用チームが対応の要否を判断し、必要に応じてリカバリ対応や共有、チケット作成を行います。
図7 AIOps 導入後のアラート対応フロー
AIOps 導入でやったこと
アラート対応への AIOps 導入でやったことは以下のとおりです。
- 開発チーム
- AI エージェントの設計・開発
- 自作 MCP Server (Crois MCP) の設計・開発
- 運用チーム
- ランブックの整備
- AI エージェントによる調査の検証と評価
AI エージェントの設計・開発
現時点での AI エージェントのアーキテクチャは以下の通りです。
- インフラ
- AWS Lambda
- Amazon Bedrock
- モデル
- Claude Sonnet 4
- フレームワーク
Strands Agents では、「ユーザーからの入力を元に推論し、適切な Tool を使用して、その Tool の結果から再度推論し、また次の Tool を選択する・・・」のような Agent Loop と呼ばれる多段階的な推論とアクションを AI エージェントが行います。
この Agent Loop 内においてエージェントが使用する Tool は以下の通りです。
- Strands Agents 組み込みの use_aws
- boto3を通じて全ての AWS サービスにアクセス可能
- 読み取り権限のみ付与しており、破壊的変更を行わない
- Google Cloud Logging Tool (内製)
- GKE 上で実行されるタスクのエラー調査に使用
- 柔軟性や Crois 運用への最適化を重視したため内製
- Crois MCP (内製)
- Crois のワークフロー一覧やジョブの詳細などを取得する際に使用
- 詳しくは後述
AI エージェントにはアラートの内容、発生日時、アラートに対応するランブックの本文をプロンプトとして与えます。
それらの入力に対して、調査の過程として、使用したツールとその結果が出力されます。
そして、一次調査レポートとして、アラートの原因、調査内容、推奨される対応がまとめられます。
Crois MCP の設計・開発
Crois では、他のシステムやプラットフォームから利用するための API が用意されています。
用意している API の例は以下の通りです。
- 特定のプロジェクト配下のワークフローの一覧を取得する
- プロジェクト : ユーザが Crois 上で行える操作の権限管理を行うために、ワークフロー、シークレット情報などをまとめたもの
- 指定したジョブの詳細情報 (開始日時、終了日時、ステータスなど) を取得する
- 指定したジョブのタスクのログを取得する
Crois API の一覧は Swagger UI から確認することができます (図8) 。
図8 Crois API の Swagger UI
これらの情報はアラート調査において有用であることが多く、AI エージェントがこのような API を呼び出すための MCP Server を開発しました。
MCP (Model Context Protocol) は、AI モデルが外部ツールやデータソースにアクセスするための標準化されたプロトコルです。
Crois MCP を実装することで、AI エージェントが Crois API を統一的な方法で利用できるようになります。
今回は AI エージェントによる許可のない破壊的な変更を防ぐため、アラート調査に必要な API のみを許可しています。
ランブックの整備
Crois では以前からランブックは存在していたものの、手順が明確化されていない箇所がありました。
例えば、以下のランブック (図9) に記載されている「リクエスト ID」の調べ方がランブック内に記載されていないといった課題があります。
図9 手順が明確化されていないランブックの例
そこで、AI やこれから加わる新メンバーでも調査・対応しやすいように、手順を明確化しました。
具体的には、AWS マネジメントコンソールではなく、AWS CLI (コマンド) を使用する手順に書き換えました (図10) 。
これにより、ランブックから曖昧さを減らし、AI エージェントが適切なツールやパラメータを使用できることを狙いとしています。
図10 手順を明確化したランブックの例
なぜランブックが必要なのか？
High quality, condensed information combined with tools to access more details as needed produced the best results
https://blog.langchain.com/how-to-turn-claude-code-into-a-domain-specific-coding-agent/
LangChain の調査によると、特定のドメインに特化した AI エージェントのコーディングにおいて、以下が揃った時に最高の結果が得られるとされています (図11) 。
- Tool でアクセスできる詳細情報 (今回における MCP)
- 集約されたガイドライン (今回におけるランブック)
このことから、ランブックの整備はエージェントの調査性能に直結すると考えられます。
図11 Claude Code の設定ごとのパフォーマンスの比較
引用 : https://blog.langchain.com/how-to-turn-claude-code-into-a-domain-specific-coding-agent/
AIOps におけるランブック整備の意欲向上
AIOps はランブック整備のモチベーションの向上にも繋がると考えています。
ランブック整備は開発に比べて退屈・面倒であり、数回やればある程度覚えるため、たまにしか役立たないと思われがちでモチベーションが上がりにくい側面があります。
ただ、AIOps 導入下では、ランブックの質が上がると、AI エージェントの調査の質が上がり、運用コストが減るため、ランブック整備のモチベーションにもつながります (図12) 。
図12 AIOps におけるランブック整備のサイクル
AI エージェントによる調査の検証と評価
AI エージェントによるアラートの一次調査に対して、人手での評価を実施し、スプレッドシートで管理しています (図13) 。
AI エージェントの一次調査に対する評価項目は以下のとおりです。
- AI エージェントの調査・判断の正確さ、分かりやすさ、網羅性
- 調査結果によって、どのくらい時間を節約できたか
- AI エージェントの出力結果に対するフィードバック (自由記述)
- 原因特定に至るプロセスのどこまで分かったか？
- 出力結果に加えて、自分でやらなければいけなかったことは何か？
図13 AI エージェントの一次調査結果に対する評価・フィードバック
正確さ、分かりやすさ、網羅性の3つの観点で評価・集計したところ、半数程度は運用担当者と同等以上の調査ができていることが確認できました (図14) 。
図14 エージェントの調査・判断に対する評価の内訳
この AI エージェントによる一次調査に対するフィードバックをもとにエージェントやランブックを改善します。
AI エージェントによる一次調査の例
ここで、エージェントによる一次調査の例をいくつか紹介します。
成功例(1) ランブックに従った調査
整備済みのランブックが存在するアラートに対して、アラートの内容とそのランブックを参照しながらエラー調査を実施できていました。
AI エージェントはアラート固有のランブックが存在する場合はそのランブック、存在しない場合は共通ランブック(前述、図15)を参照するようにしています。
特に固有のランブックが存在しない AWS リソースに関するアラートに対して、CloudWatch アラームの発火条件から関連のあるリソースを探して適切な調査が行えていることから、ある程度の応用力があると考えられます。
図15 共通ランブック(図6の再掲)
成功例(2) スタックトレースからの原因特定と解決策の提示
CloudWatch のエラーログに含まれるスタックトレースから原因と解決策を提示してくれました (図16) 。
ソースコードの参照が未実装である中で、有用な情報を提供してくれています。
図16 AI エージェントによる一次調査の成功例
失敗例 不明確なランブックによる調査不足
ランブックの手順が明確でない場合、期待される調査結果が得られない場合があります。
以下のランブック (図17) では、CloudWatch メトリクスからエラー件数の算出を行う手順を記載していますが、具体的な手順が記載されておらず、AI エージェントの一次調査ではエラー原因の調査しか行えていませんでした (図18) 。
図17 手順が明確化されていないランブックの例
図18 AI エージェントによる一次調査の失敗例
これらの成功例と失敗例から分かることは、AIエージェントの調査品質はランブックの具体性に直接依存するという点です。
具体的には以下の通りです。
- OK : 明確なコマンド例や手順が記載されている場合 → 適切な調査が可能
- NG : 抽象的な表現や曖昧な手順の場合 → 期待される調査結果が得られない
そのため、「何を確認すべきか」だけでなく、「どのように確認するか」まで具体的に記載することが重要です。
今後の展望
今後は、ソースコードやドキュメントを参照し、より自律的に深掘りした調査を行えるようにしていきます。
既に前述した成功例(2)のようにスタックトレースから原因を推測してくれるケースもありますが、将来的にはソースコードを分析し具体的な改善案も提案してくれることを期待しています。
また、引き続きランブック整備も進めていき、AI、そして他のメンバーにとって運用しやすい環境を目指していきたいです。
そして、他プロダクトへの展開も視野に入れています。
Crois ではランブックが整備されていますが、ランブックが整備されていないプロダクトでの調査性能を検証していけたらと思います。
まとめ
Crois における AIOps 導入の取り組みを通じて、AI エージェントによるアラート調査はランブックの質に依存することが分かりました。AIOps はランブック整備のモチベーション向上や、運用の属人化解消にも寄与します。
今後も AI エージェントの担当範囲拡大や、他プロダクトへの展開を目指し、継続的な改善を進めていきます。
本記事が、AIOps 導入やランブック整備の重要性について考えるきっかけになれば幸いです。