SKYMENU Mobileのセーフカメラ機能を例に、製品へAI機能を組み込む際の基本的な流れ（AIモデル・サービスの選定、設計、検証、総合評価）を解説します。精度、速度、コストを考慮したモデル選定やプロンプト設計など、実運用に向けたポイントを紹介します。

はじめに こんにちは。データシステム部・MA推薦ブロックの伊藤（ @rabbit_x86 ）です。私たちのチームでは、ユーザーに最適な配信を届けるために、LINE・Push通知・メールなどのマーケティングオートメーション（MA）に関する推薦システムを開発・運用しています。 本記事では、推薦システムの運用で発生するアラート対応をAIで自動化した取り組みを紹介します。人間の対応フローを「障害分析・対応の考案・敵対的レビュー・実行」の4つのタスクに分解してAIで再現し、対応にかかる工数とコンテキストスイッチを減らすことを狙います。本番環境で安全に動かすため、AIの権限と実行できる操作を段階的に絞り込むハーネスも組み込んでいます。この仕組みの導入後、約3週間で本番環境の8件のアラートをAIが自動で解決しました。 目次 はじめに 目次 背景と課題 アラート対応によるコンテキストスイッチ AIを活用しても残っていた課題 課題に対するアプローチ 業務内容を分解する AIに任せるタスクと人間に残すタスク アラート対応を自動化するシステム 既存の監視の仕組み システムの全体の流れ AIによる自律的なアラート対応の4つのタスク 敵対的レビューの設計 採用基準の明文化による改善 ハーネスによる安全設計 AIの操作が届く範囲を権限で絞る 実行できるコマンドをallowedToolsで限定する スクリプトで操作を細かく制御する 運用事例と効果 再実行で解決した事例 効果と課題 まとめと今後の展望 最後に 背景と課題 アラート対応によるコンテキストスイッチ 私たちのチームは、メール配信のコンテンツなどをパーソナライズするための推薦システムを作っています。この推薦システムは、 Agent Platform Pipelines （旧Vertex AI Pipelines）のパイプラインとして実装しています。パイプラインが失敗すると最新の推薦結果を配信できなくなるため、アラートには早急に対応する必要があります。 ただ、そのアラート対応は割り込みで発生し、その度に担当者は他作業を止めて対応に当たる必要があります。対応では、エラーログから原因を調査し、必要に応じて再実行や修正などの処置をします。このコンテキストスイッチにより、元の作業に使えたはずの時間は失われ、作業に戻るための切り替え時間も必要になります。 AIを活用しても残っていた課題 私たちはすでに、AIを活用してアラート対応を効率化していました。エラーログをAIに与えて原因を調査させ、対応方針を検討させるところまでは日常的に行っており、1件あたりの対応は楽になっていました。ただ、調査結果の確認や方針の承認、再実行や修正の判断は人間のままで、アラートのたびに時間と集中を割く構造は変わっていませんでした。 さらに、対応の証跡はSlackのスレッドに残す程度で、ナレッジとして蓄積されていないという問題がありました。そのため、同種のアラートでも過去の調査結果を再利用できず、同じ調査を繰り返していました。また、対応の進め方は担当者ごとの判断に任されており、質とスピードもばらついていました。 そこで、アラート対応の調査から実行までをAIが自律的に行い、その証跡を残して次の対応で参照できるシステムを構築することにしました。 課題に対するアプローチ 業務内容を分解する 業務をAIに任せるにあたり、まず業務内容を人間の判断や作業を抽象化したタスクへ分解することを考えました。その結果、どのような業務にも当てはまる「タスクの発見」から「知見の蓄積」までの7つの一般的な単位に整理できました。それぞれの内容は次のとおりです。 タスク 一般的な内容 タスクの発見 アラート・Issue・定常業務の中から、対応すべきタスクを見つける タスクの理解 背景・制約・完了条件を理解し、整理する 解決方法の考案・承認 解決方法を考え、実行するかを判断する 実行と再試行 解決方法を実行し、失敗した場合は考案からやり直す 最終確認 完了条件を満たしたかを自身で確認する 第三者確認・完了 担当者以外が内容をレビューし、完了を判断する 知見の蓄積 成功・失敗から得た学びを、次のタスクに活かす AIに任せるタスクと人間に残すタスク 次に、分解したタスクを1つずつAIに置き換えることで、AIが自律的に業務を進める状態を目指しました。この方法なら、AIへ任せる範囲を段階的に広げつつ、意思決定を人間に残す部分も選べます。どのタスクをAIに置き換えるかは、次のように決めました。 タスク アラート対応での作業 担当 理由 タスクの発見 アラートが鳴り、対応が必要なことを認識する 人間 AIに対応させるアラートの選別を人間が握るため タスクの理解 アラート対象のシステムとエラー内容を理解し、完了条件を整理する AI 対応の中核であり、人間の時間と集中を奪っていた部分のため 解決方法の考案・承認 過去の対応事例を参考に原因への対応方法を複数考え、最適な案を選ぶ AI 同上 実行と再試行 選んだ案を実行し、失敗した場合は別の案を試す AI 同上 最終確認 完了条件を満たしているかを確認する 人間 Issueに残る対応記録を見て、解決したことを人間が確認するため 第三者確認・完了 Pull Request（PR）のレビューを依頼して第三者に確認してもらい、完了を判断する 人間 完了の判断とIssueのクローズを人間が担い、責任の所在を人間に置くため 知見の蓄積 対応の成功・失敗を知識として蓄え、チームにも共有する AI GitHub Issueへのコメント蓄積を自動化するため このように、対応の開始と終了は人間が判断します。人間が関与しないと、仕組み自体が止まっていても気づけず、障害を放置してしまうためです。加えて、開始を人間が判断することで、対応不要な通知や検証用のアラートに自動対応が走ることも防げます。 アラート対応を自動化するシステム 既存の監視の仕組み 前提として、アラートの検知と通知の仕組みはすでに運用されていました。パイプラインは、 Cloud Scheduler によりスケジュール実行されています。その失敗は、 Cloud Run functions が実行状態のポーリングで検知し、パイプラインのURLとともにSlackのチャンネルへ通知します。従来は、この通知を見た人間がアラート対応を始めていました。 システムの全体の流れ アラート対応は、Slack通知を受けたところから、次の図の流れで進みます。図中の丸数字は、表のステップ1〜3に対応します。 ステップ 内容 担当 対応するタスク 1 Slack通知のリンクをクリックし、アラート情報が本文に事前入力された画面から専用ラベル付きのGitHub Issueを作成する 人間 タスクの発見 2 専用ラベル付きIssueの作成をトリガーに Claude Code Action （CCA）が起動し、障害分析・対応の考案・敵対的レビュー・実行の4つのタスクを順に実行して、結果をIssueにコメントする AI タスクの理解、解決方法の考案・承認、実行と再試行、知見の蓄積 3 対応の記録を確認し、解決していればIssueをクローズする 人間 最終確認、第三者確認・完了 ステップ1では、Slack通知の末尾にあるAuto-Triage欄のTriggerリンクからIssue作成画面を開き、Issueを作成します。実際のSlack通知は次のような形です。 開いたIssue作成画面では、画面右のLabelsに2つの専用ラベルが事前に設定されています。alert-auto-responseは、自動対応の起動トリガーとなるラベルです。pipeline-failureは、次回以降のアラート対応で過去の類似Issueを検索する際の目印となるラベルです。 ステップ2では、4つのタスクが順に実行され、分析内容・対応案・レビュー結果・実行結果といった各タスクの出力がIssueのコメントとして残ります。 ステップ3で何を確認してクローズするかは、実行タスクの対応内容によって決まります。再実行であれば、パイプラインの正常終了を人間が確認した時点でクローズします。修正PRであれば、担当者がPRの内容を最終確認し、さらにレビューによる第三者確認を経てからクローズします。 対応を進めて記録を残す場所をGitHub Issueにしたのは、チームの タスク管理とAI活用による工数削減の計測 をIssueで行っており、アラート対応も同じ管理に載せたかったためです。対応の記録がIssueに蓄積されるため、次のアラート対応でAIが過去の類似Issueを検索して再利用できる利点もあります。AIの実行環境であるCCAは、AIコーディングエージェントである Claude Code を GitHub Actions のワークフローとして実行するための公式アクションです。Issueの作成をトリガーに起動できることと、チームの運用実績があることから選びました。 AIによる自律的なアラート対応の4つのタスク アラート対応は「障害分析・対応の考案・敵対的レビュー・実行」の4つのタスクによって構成され、Issueの作成をトリガーに起動した1回のCCAの実行の中で順に進みます。各タスクは結果をIssueのコメントとして出力し、次のタスクはそのコメントを入力として受け取ります。 各タスクは、 skill と呼ばれるMarkdownの指示書として定義しています。全体像は次のとおりです。 図の各タスクが行うことは、次のとおりです。 タスク skill 行うこと 障害分析 diagnose-pipeline-failure パイプラインの実行情報・エラーログ・実装コードを読み、問題・原因・解決策の候補を洗い出す 対応の考案 propose-pipeline-remedies 分析結果をもとに、再実行や修正PRの作成といった対応案を根拠つきで挙げる 敵対的レビュー review-pipeline-remedies 対応案の粗を意図的に探して審査し、実行案を承認する。※ Claude Codeの ベストプラクティス で推奨されているレビュー方法 実行 review-pipeline-remedies 承認された案を実行する なお、CCAが実行するClaude Codeへ渡すプロンプトには、各タスクの内容を直接書かず、skillを順に呼び出す指示だけを書いています。実際のプロンプトは次のとおりです。 以下の skill を順に実行してください: 1. /diagnose-pipeline-failure <Issue番号> 2. 1 がエスカレーション (needs-human) で終了した場合はここで終了。 そうでなければ /propose-pipeline-remedies <Issue番号> 3. /review-pipeline-remedies <Issue番号> 各 skill の進め方・出力フォーマット・エスカレーション基準はすべて skill 側に定義されています。 プロンプトにあるエスカレーションは、AIが対応を打ち切って人間へ引き継ぐ終了経路です。エラーログを取得できない場合や、上流チームとの調整や課金に関わる変更のように人間の判断が必要な場合、AIはタスクを問わずエスカレーション用のラベル（needs-human）を付けて対応を停止します。 敵対的レビューの設計 敵対的レビューの設計は、Claude Codeのベストプラクティスにある Add an adversarial review step の項を参考にしました。この項では、レビュアーへ成果物と判定基準だけを渡し、そこに至る経緯や背景といったコンテキストの影響を受けないレビューが推奨されています。 そこで、案を考える「対応の考案」と案を承認する「敵対的レビュー」を別のタスクに分けました。敵対的レビューには、元の会話とは別のコンテキストで動くエージェントである subagent を使います。このsubagentに渡すのは、Issueに書かれた障害分析コメントと対応案コメント、そしてレビューの指示の3つだけです。この指示は案を中立に評価させるのではなく、否定する理由を探させる敵対的な内容にしました。 採用基準の明文化による改善 ただし、この敵対的レビューは最初から狙いどおりに機能したわけではなく、本番導入前の検証では採用すべき案が却下され続けました。たとえば、修正PRを作成する案に対して、敵対的レビューは「修正が本番環境へ影響を与えないか確認できない」という懸念を挙げて却下しました。修正PRはdraftでのみ作成され、マージも人間が担うため安全なはずの案でも、こうした曖昧な懸念による却下やエスカレーションが続きました。 実際、 Add an adversarial review step には、粗を探すよう指示されたレビュアーは成果物に問題がなくても何かを報告する、という注意書きがあります。 A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. そこで、採用の基準を明確に定めました。却下してよいのは、次の2つを両方示せた場合だけです。 案を実行した場合に本番環境へ与える悪影響といった、実害が発生するシナリオを具体的に示せること そのシナリオが、後述するハーネスの制約で防げず実際に起こりうると示せること どちらか一方でも示せなければ、承認します。実際にレビューの指示へ書いた判定手順は次のとおりです。 1. この案を実行した場合に起こりうる、具体的な実害シナリオを考える （「念のため」「本番影響が心配」は実害シナリオではない） 2. そのシナリオが、再実行の上限・draft強制・人間によるマージ・操作対象の限定（同一パイプライン・対象リポジトリのみ）の いずれによっても防がれないことを示す 3. 1と2の両方を具体的に示せた場合のみ却下する。示せなければ承認する 4. 例外として、実行手順自体に技術的な矛盾がある場合は、その矛盾を指摘したうえで却下してよい 5. 「前提条件が完全には確認できていない」など、案の安全性と無関係な懸念は単独では却下根拠にならない 6. エスカレーション案を承認するのは、他のすべての案が却下された場合のみ これによって、直後の検証ではAIがパイプライン内のバグを修正するPRの作成まで完了できました。敵対的レビューを機能させるには、否定する理由を探させるだけではなく、却下する際の基準を設けることが重要でした。 ハーネスによる安全設計 アラート対応をAIが自律的に進めるには、Google CloudやGitHubといった外部サービスへアクセスする権限をAIに与える必要があります。ただ、与えた権限は安全に扱わせなければなりません。ここで鍵になるのがハーネス（harness）です。ハーネスとは、AIモデルの外側にあって、モデルが自律的かつ信頼できる形で仕事をこなせるようにする仕組み全体のことです。具体的には、使えるツールや権限の定義・実行環境・コンテキストの引き継ぎ・テストやレビューによるフィードバックループ・ルールの機械的な強制などを指します。 OpenAI や Anthropic も、エージェント設計の文脈でハーネスを整理しています。本節では、このうち安全に関わる部分である、権限とツールの制限、そしてスクリプトによるルールの強制を説明します。 今回、AIが外部に対して行う操作は、次の3つです。 目的 操作 タスク 種別 エラーの調査 パイプラインの実行情報・エラーログ・実装コードの取得 障害分析 読み取り（Google Cloud・GitHub repository） 対応の証跡の記録 Issueへのコメント投稿・ラベル操作 すべてのタスク 書き込み（GitHub Issue） 対応の実行 パイプラインの再実行・修正PR（draft）の作成 実行 書き込み（Pull Request・Google Cloud） これらの操作を、3つの段階に分けて安全に扱っています。 AIの操作が届く範囲を権限で絞る 1つ目の段階は、AIに与える権限です。CCA専用の認証の仕組みを用意し、そこへ必要最小限の権限だけを付与しています。具体的には次のとおりです。 対象 認証に使う仕組み 付与した権限 Google Cloud Service Account パイプラインジョブの参照・作成とログの読み取りのみ GitHub GitHub App Issueへの書き込み（コメント投稿・ラベル操作）、リポジトリの読み取り、修正PR作成に必要なブランチ・PRの作成のみ この権限により、AIはService Accountを通じたパイプラインの再実行や、GitHub Appを通じたIssueへの書き込みなどを実行できます。一方で、権限を絞るだけでは不十分です。GitHub Actionsの実行環境には、Service AccountとGitHub Appの認証情報が載っています。そのため、gcloudコマンドやcurlを使えば、AIは権限の範囲内のAPIを直接呼び出せてしまいます。たとえばジョブの作成権限を使えば、失敗したジョブをそのまま複製するのではなく、パラメータやコンポーネントを書き換えた別のジョブを本番環境で起動できてしまいます。 実行できるコマンドをallowedToolsで限定する この権限の範囲内の操作を縛るために、2つ目の段階では実行できるコマンドを限定します。CCAのワークフローでは、実行を許可するツールを allowedTools という設定で列挙し、列挙していないコマンドは権限があっても実行できません。シェルの任意コマンド、gcloudやbqコマンド、curl、生のAPI呼び出しはここで塞がれます。 実際のワークフローに書いている設定の一部は次のとおりです。 claude_args : | --allowedTools 'Bash(python3 .claude/skills/diagnose-pipeline-failure/scripts/fetch_pipeline_job.py:*)' 'Bash(python3 .claude/skills/diagnose-pipeline-failure/scripts/fetch_error_logs.py:*)' 'Bash(python3 .claude/skills/diagnose-pipeline-failure/scripts/fetch_repo.py:*)' 'Bash(python3 .claude/skills/review-pipeline-remedies/scripts/rerun_pipeline.py:*)' 'Bash(python3 .claude/skills/review-pipeline-remedies/scripts/create_fix_pr.py:*)' 'Bash(gh issue view:*)' 'Bash(gh issue comment:*)' 許可しているのは、スクリプトと、Issueのコメントを読み書きする GitHub CLI のgh issue系サブコマンドだけです。このスクリプトの中身を、次の3つ目の段階で説明します。 スクリプトで操作を細かく制御する さらに3つ目の段階として、スクリプトで実行内容を細かく制御しています。コマンドを何回・どの対象に使えるかという条件を、スクリプトのコードへ埋め込んでいます。スクリプトを使うタスクと内容は次のとおりです。 種別 スクリプト 使うタスク 内容 読み取り fetch_pipeline_job.py 障害分析 対象の失敗ジョブに限定して、詳細（失敗タスク・エラー）を読み取る 読み取り fetch_error_logs.py 障害分析 対象の失敗ジョブのエラーログだけを、 Cloud Logging から整形して読み取る 読み取り fetch_repo.py 障害分析 パイプラインを実装しているリポジトリに絞って、コードを読み取り専用で取得する 書き込み rerun_pipeline.py 実行 失敗したジョブの複製のみを、同一パイプラインに2回まで再実行する 書き込み create_fix_pr.py 実行 修正PRをdraftでのみ作成する このうちrerun_pipeline.pyは、失敗したジョブの設定を複製し、新しいジョブとして再実行するスクリプトです。複製したジョブにはrerun_count=1のような再実行の回数を表すラベルを付け、次の再実行でその値を読み取って上限を判定します。具体的には次のように、上限の2回に達していれば実行前に拒否し、エスカレーションへ進ませます。 MAX_RERUN_COUNT = 2 rerun_count = int (source_labels.get( "rerun_count" , "0" )) if rerun_count >= MAX_RERUN_COUNT: print ( f "REJECTED: rerun limit reached (rerun_count={rerun_count}). " "これ以上の自動rerunは禁止。needs-humanでエスカレーションしてください。" , file=sys.stderr, ) return 1 このように、条件を満たさない実行はAIの判断にかかわらずスクリプトがエラーで拒否し、エラーを受け取ったAIはエスカレーションなどの別の対応へ進みます。 権限が「どこまで届くか」を、allowedToolsが「どのコマンドを実行できるか」を、スクリプトが「どの条件とどの対象なら操作してよいか」を制限します。この3つの段階を重ねることで、本番環境でAIが暴走しないように設計しています。 運用事例と効果 ここでは、本番環境でAIが解決したアラートのうち、再実行で解決した1件の事例を紹介します。 再実行で解決した事例 対象のアラートは、Google Cloud側の一過性のエラー（internal error）でパイプラインが失敗したものです。このとき各タスクが実際に行った対応は次のとおりです。 タスク 内容 障害分析 エラーメッセージは「Internal error happened.」のみで、詳細なログを取得できないことを確認。これを一過性のエラーの兆候と推定し、原因としてIssueにコメント 対応の考案 分析コメントを受けて過去の類似Issueを検索し、同じパターンの失敗が再実行で復旧している実績を発見。これを根拠に再実行案を提案 敵対的レビュー 提案された再実行案を審査し、ハーネスの制約で防がれない実害シナリオがないことを確認して承認 実行 承認された案をハーネス経由で再実行し、パイプラインは正常に完了 一連の対応は、Issueの作成から再実行の開始まで約8分で完了しました。人間が行っていた「ログを見て、過去の事例を思い出し、再実行で直りそうだと判断する」という思考の流れを、AIがそのまま再現できました。 効果と課題 本システムの目的は、アラート対応のたびに発生していたコンテキストスイッチと対応の時間を、AIで減らすことでした。ただ、この効果は本番環境でまだ実証できていません。 実証できたのは、アラート対応の自動化です。導入から約3週間で8件のアラートをAIが解決し、調査から実行までを人間が担わずに完了できました。また、対応は毎回同じskillの手順で進むため、担当者ごとに異なっていた進め方も統一されました。ただし、8件はいずれも再実行で解決できる、もともと対応コストの小さい障害でした。そのため、導入の前後でコンテキストスイッチや対応の工数の変化は小さいです。 本システムの真価が出るのは、調査や判断に時間のかかる障害です。本番環境ではまだこの種のアラートは発生していませんが、本番導入前の検証では、パイプライン内のバグに対して原因の特定から修正PRの作成までをAIが完了できています。ただ、この種のアラートは頻発せず、導入から日も浅いため、本番環境での効果の実証がこれからの課題です。 まとめと今後の展望 本記事では、推薦システムのアラート対応を題材に、人間の業務をAIへ置き換えた取り組みを紹介しました。ポイントは2つです。 業務を人間の思考フローに沿って分解してAIで再現することで、どこをAIに任せてどこを人間に残すかをタスク単位で設計する 権限・allowedTools・スクリプトの3段階からなるハーネスでAIに制約を与えることで、本番環境でも安全に実行させる 一方で、運用を通じて課題も見えてきました。今後は次の2点に取り組みます。 調査や判断に時間のかかる障害への対応で、本システムによるコンテキストスイッチと対応時間の削減を定量的に実証する 人間が担っている対応の開始と終了まで自動化を広げ、アラート対応をAIに完全移譲する アラート対応は一例にすぎません。ほかの業務でも、フローを分解して一つひとつAIに置き換えていけば、AIが自律的に業務を進める状態へ近づけるはずです。業務をAIに任せることを考えている方の参考になれば幸いです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに 最近、AI Agentについて調べる中で、LLMそのものの性能だけでなく、Agentを動かすための周辺の仕組みが重要だと感じることが増えてきました。 LLMそのものが高性能でも、どの情報を参照するのか、どのToolを使ってよいのか、どのような手順で仕事を進めるのか、どこまで自動実行してよいのかといった部分が決まっていなければ、実際の仕事を安心して任せることはできません。 こうした仕組みはAgent Harnessと呼ばれることがありますが、言葉だけでは具体的にイメージしにくいところがあります。 そこで今回は、OpenClawをWindows環境に導入し、実際に自分専用のAI