AIエージェントを業務の本番投入まで持っていく——人間と約350件並走したフォワードテスト運用

昨今、AIの能力向上もあって業務改善用AIエージェントを開発している方が増えてきています。
しかし、作ったものの中で本番投入して価値を発揮し続けているものはどれだけあるでしょうか。

今回の記事では、AIエージェントを本番投入するまでにやったことを整理しました。
仕組みの開発は2ヶ月で形になったのですが、本番投入までの道のりこそが本質でした。

この記事はUnit1（製薬企業向けプラットフォームチーム）ブログリレーの1日目の記事です。執筆はUnit1チームリーダーの佐野です。

依頼チケットを受け取ってから1次返答のメールを送信するまでの手順は、内容理解、手順整理、データチェック、返信メールの検討・作成・送信と、ステップが多い作業でした。
依頼の多い日には開発をしている時間より依頼を読んでいる時間のほうが長いことも多々ありました。
そこで、私のチームでは依頼が届いて1時間未満で不備を見つけて、聞き返しメールの下書きまで用意してくれるAIエージェント「MOAI」を開発しました。

何を作ったのか？
依頼が届いて1時間以内に、不備検査が終わっている
フォワードテスト ——人間と同じチケットを処理させ、差分を測る
差分の正体 ——修正の行き先は、ほぼ手順書だった
手順書修正をループに載せる ——スプレッドシートに1行書けばPRが来る
学び ——主役はエージェントではなく手順書
We are hiring!!

何を作ったのか？

「MOAI(Managing Operations with AI)」という、依頼の前捌きをするAIエージェントを作成しました。
次のような流れで動作します。

依頼を定型作業に分類する
分類ごとに用意された手順書に従い、依頼の不備をチェックする
不備を確認する返信メールを下書きする

Pythonによる決定的な処理とAIによる柔軟な対応を使い分けて実装しています。

Pythonによるチケット情報読み取り、分類分け
AIが手順書に従い調査実施。AIには読み取り権限のみを渡してあり、書き込みや変更権限は与えていない。
Pythonにより不備チェックの結果をチケットに書き込み

万が一AIの挙動に不備があっても、権限の制限によって周囲への悪影響を未然に防ぐ設計になっています。

依頼が届いて1時間以内に、不備検査が終わっている

担当者がチケットを開くときには、既に「MOAI」によるチェック結果が書き込まれている状態になりました。
1次返答の起点が「人の着手時」から「依頼到着直後」に変わったことで、最初の作業が依頼内容の読解から「MOAI」のアウトプットの確認に変わりました。
それにより、1次返答までの時間は中央値で従来の約3分の1になりました。
また、副次的な効果として「MOAI」の事前処理のアウトプットが依頼内容の読解の手助けにもなっており、全体の作業スピード向上にもつながっています。
さらに、この仕組みができたことによって、いままで非定型として相談を受けていた案件を定型作業に落とし込めないか、という考え方の転換も生まれています。

フォワードテスト ——人間と同じチケットを処理させ、差分を測る

MOAIの仕組みそのものの開発自体は2ヶ月で完了しました。
意気揚々とAIに過去依頼とマニュアルを読み込ませて手順書を自動生成したのですが、それだけでは本番投入可能な品質には達しませんでした。
細かい対応の裏側にある運用ルールや大事な判断軸がMOAIに情報提供できていなかったからです。

そこで、フォワードテストを実施しました。
実際の依頼をMOAI用にコピーし、人間とMOAIが同時に対応して人間の対応完了後に答え合わせをする仕組みです。
評価は4段階（完全一致/方向一致・指摘過剰/方向一致・指摘不足/不一致）に分類し、完全一致以外はすべて振り返りの対象にします。
振り返りを担当するのは年間数千件の依頼を対応するベテランメンバーなので、暗黙知や危険察知の観点をMOAIに教え込むことができました。

フォワードテスト開始時の4月は人間とMOAIの回答の完全一致率は38%だったのが、3ヶ月にわたって約350件のフォワードテストを実施し、7月には66%まで向上しました。
最も並走を重ねた本番投入候補の依頼分類は、直近で12件中10件が完全一致という品質にまで向上しています。

テスト中に人間とMOAIの出力を比較していたところ、MOAIが人間の見落としに気づいたこともありました。
人間の判断力とAIの安定性は補完関係にある、というのが並走させてみての実感でした。
AIの調査結果を人間が利用するという運用にしているため、品質の向上が期待できます。

差分の正体 ——修正の行き先は、ほぼ手順書だった

では、一致率を上げるためにどのような調整をしたかというと、大きく2つです。

手順書の拡充、構造化
データ参照権限の整備

1は人間の頭の中にあった暗黙知や細かいルールをMOAI用に構造化して手順書に追記をしたということです。
MOAIが正しい判断をするためには、正しい現行のルールを正確に伝える必要がありました。
システム構成や実装面についてはほぼ修正は不要でした。

2はBigQuery（BQ）のデータ参照権限やデータセットの整備です。
手順書にSQLをあらかじめ書いておくことで正確なデータ抽出と判断が可能になり、品質がぐっと上がりました。

この2つの整備はまだAIには難しく、人間が普段どのデータをどのように判断し活用しているのかを整理して伝える必要があります。
ここに大きな労力がかかるのですが、品質と1次返答スピードの向上によるビジネススピードの加速の恩恵があるため、投資価値は十分にあると判断しています。

手順書修正をループに載せる ——スプレッドシートに1行書けばPRが来る

フォワードテストで差分に気づいた時に、手順書を直すのですが、そのコストが地味に大きく改善ループの妨げになってしまいました。
そこで、Loop Engineeringの概念を取り入れ、人間はフォワードテストの評価振り返りスプレッドシートに修正指示を書くだけで良いように仕組みを構築しました。

AIコーディングエージェントのDevinにはAutomationsという機能があり、WebHookやスケジュール実行で事前に与えられたプロンプトの通りの動作をさせることができます。
これによって、フォワードテストによる修正指示を自動的にDevinが読み込みPRを作ってくれる仕組みができました。
MOAI育成ループは、フォワードテストの差分検証 → 修正指示 → PR確認 → フォワードテスト... という形になり、大幅に負担が軽減され「継続可能な取り組み」に落ち着くことができました。

良いものを作るのも重要ですが、それを使い続けたり発展させ続ける仕組みそのものが無理なく運用できることも非常に重要と学びました。
また、MOAIによって浮いた時間をMOAIの育成に再投資することで改善が加速する点も非常に良いループだと感じました。

学び ——主役はエージェントではなく手順書

振り返ると、システムの構成構築にかけた時間よりも手順書の修正にかけた時間の方が長くなっています。
本番投入できる品質にたどり着くまでには、まずは人間の判断や作業を出し切る必要があると学びました。
AIエージェントはあくまで与えられた情報と指示に従って動くだけなので、人間レベルの品質を出すためにはその情報と指示の品質を上げる必要がありました。

また、もう1つ学んだことがあります。
それは導入のハードルが非常に低いことのメリットの大きさでした。
依頼フォームも依頼フローも一切変えずに提供価値だけを向上させることができるため、どの部署とも調整することなく内部の改善のみで進められました。
特に、本番投入をするための大きなハードルである関係者との調整がないのは絶大なメリットでした。

現在「MOAI」が対応できる依頼は全体の5%程度なので、まだこれから育てていく段階ですが、次のような発展型も考えているためROIは高いと考えています。