【Google Cloud Next Tokyo 26】エキスパートの判断を AI エージェントで再現する: 「自律性と再現性の両立」に挑むマルチエージェント実装

はじめに

DX開発事業部の鹿嶋です。

7/31（金）に行われた「エキスパートの判断を AI エージェントで再現する: 「自律性と再現性の両立」に挑むマルチ エージェント実装」のセッションレポートとなります。

セッション情報

セッション概要（※公式ページより引用）

審査、監査、判定。膨大なマニュアルと経験に基づき「ネクストステップ」を決定する仕事は、AI エージェントの真骨頂です。少数のエキスパートが担ってきたこうした高度な判定業務は、精査できる件数に限界があり、ルールの漏れや人為的ミスを完全には防げない構造的課題も抱えています。しかし「マニュアルを渡せば AI が動く」という期待と現実の間には、制御するとルールベースに退行し、かといって自由にすれば動作が安定しないという AI エージェント開発が必ず直面する「自律性と再現性の両立」という壁があります。本セッションでは、いかにマニュアル ベースの業務を AI エージェントで実現するかの設計のポイントをお伝えします。

登壇者

後藤 拓矢 氏
（SOMPOホールディングス株式会社 / デジタル・データ戦略部・リードエンジニア）

セッション内容

1. AIエージェントの実用化を阻む2つの壁

AIエージェントを実業務へ適用する際に立ちはだかる大きな壁として、ルールベース化の限界と LLM への丸投げの限界が挙げられました。

ルールベース実装の限界

実務のマニュアルは数百ページに及ぶこともあり、そこには無数の例外、条件、依存関係が含まれています。
これらをすべてプログラムのコードとして書き起こそうとすると、条件分岐の組合せが膨大なものになってしまい、とても現実的な対応ではなくなってしまいます。さらに、業務マニュアルが改訂されるたびにエンジニアがコードを修正しなければならず、現場のスピードに追いつけなくなるという保守性の問題が生じます。

LLM への丸投げの限界

一方で、複雑なマニュアルをそのまま LLM に渡し、すべてを自律的に判断させようとすると別の問題が発生します。
LLM は現状100%確実な信頼性の情報を返すことは現実的ではありません。どれだけこちらがプロンプトを工夫して依頼を詳細に投げようとも、回答には LLM の独自性が含まれます。

皆さんも生成AIとのチャットを行った際、ソースが存在しない情報や、こちらが聞いていないことも気を利かせて回答に含めてくる場面に遭遇したことがあるのではないでしょうか。

この LLM の動き方（考え方）に対して、精度情報抽出・照合・判定といった処理ステップが増えるほど、LLM 特有の不確実性が掛け算で増幅していきます。例えば各ステップの精度が90%だったとすると、処理を重ねるごとに全体の精度は確実に低下します。すると、同じ入力に対しても異なる出力が返ってきたり、間違った情報をもとに自信満々に回答を生成するハルシネーションのリスクが高まるといった事態を引き起こしてしまいます。

2. 「おやつのルール」で考える業務の共通構造

この課題に対するアプローチを整理するため、身近な「おやつのルール」を例にした解説が行われました。

• おやつ代は1日300円までとする
• 17時以降（夕食の1時間前）は飲食を控える
• 果物は対象外とするが、バナナはおやつとして扱う
• 自分のお小遣いを使用する場合、1回500円を超えるなら親の承認を必要とする

このルールの上で、「150円のバナナを、お小遣いを使って15時に食べる」というケースを判定します。

結果として、親の承認は不要になりますが、このようにルールが明文化されていれば、人間であっても LLM であっても同じ結果にたどり着くことができます。

このように、審査基準や監査、査定といった業務フローも、ルールを読む → 現状と照らし合わせて状況を判定する → 次のアクションを決めるという流れで、基本的には同じ構造を持っています。

実際の業務においては、マニュアルに記載のない例外的な事象が発生することも珍しくありません。このような未知の状況下で LLM に判断を委ねると、既存のルールを独自に解釈し、もっともらしい回答を生成してしまうリスクがあります。

そのため、ルールに明記されていない事象については勝手な推測をさせず、システム的な統制を適切に組み込むことが不可欠です。

3. 影響度から線引きを逆算する「境界設計」

ルール変更に柔軟に追従できる自律性と、同じ入力に対して常に同じ結果を返す再現性はトレードオフの関係にあるため、どちらか一方に振り切るともう一方が損なわれてしまいます。セッションの中では、これらのステータスはひとつのプロンプトの中では両立できないという点が強調されました。

ここで鍵となるのが、処理のプロセスをレイヤーごとに分割し、どこまでを LLM の解釈に任せ、どこからをシステム的に制御するかという境界設計の考え方です。

LLM に推論を任せると、どうしても思考プロセスには毎回わずかな揺らぎが生じます。しかし実際のところ、最終的な結論と、なぜそれに至ったかという根拠さえしっかりと合致していれば、途中の過程が多少チグハグになったとしても実務上は問題にならないケースがほとんどです。

そう考えると、私たちが実務で直面する課題は具体的にどう境界線を引くか、という一点に絞られます。

セッションで提示されたのは、レイヤーの内容が誤ったものであるとき、誰がどう困るのかという視点でした。 万が一エラーが起きた際、ビジネスへの影響がクリティカルになるレイヤーであれば、そこはシステム的に制御する側に倒す、逆に、多少のブレが許容できる部分は思い切って LLM に任せるという切り分けが、境界設計を形作るための具体的なステップとなります。

4. プロンプトから制御を切り離す Multi-Agent の連携

では、この設計で引いた境界線を、どうやって実際のシステムに組み込めばよいのでしょうか。

一番のポイントは、絶対に守らせたいルールをプロンプトの指示として LLM に直接書き込まないことです。自然言語で長々と条件を記述するのではなく、JSON や YAML といったプログラムが解釈できる構造化データとしてルールの実体を外部に切り出します。

システム全体は、進行を管理するオーケストレーターを中心に、役割を持った複数のサブエージェントが連携する Multi-Agent アーキテクチャとして構成します。

自律的に動く部分には、抽出項目の計画を立てる Planner や、規定のマニュアルを参照する Retriever、そして判定の根拠を文章として生成する Summarizer といったLLMベースのエージェントを配置します。一方で、決してブレてはいけない決定的な部分には、申請内容から確実に情報を抜き出す Extractor や、外部化された構造化ルールに基づいて白黒をつける Evaluator といったルールベースのエージェントを割り当てます。

ルールを外部化・構造化する大きなメリットは、エンジニアがデータ化した内容を現場の担当者が直接レビュー・テストできるようになる点です。さらに、この構造化の過程で既存マニュアルの曖昧さや矛盾が浮き彫りになるため、結果として業務部門のドキュメント資産がより洗練されるという副産物も生まれます。

5. Human-in-the-Loopの適切な配置

このアーキテクチャの運用においても、LLM にすべてを任せるのではなく、Human-in-the-Loop を適切なポイントに配置する仕組みが必須です。

LLM は情報が不足していると内容を推測して補完しようとする傾向があるため、必要な情報が抽出できなかった場合や、参照した規定同士に矛盾が生じている場合には、システムが勝手に判断せず人間へエスカレーションするゲートを設ける必要があります。最終判定の際も、確信度が低いものや根拠の妥当性について人間がチェックを行うことで、ハルシネーションを防ぐ強力な安全装置として機能します。

6. アンダーライティング業務への適用と成果

このアーキテクチャは、SOMPOホールディングス社内のアンダーライティング業務ですでに適用されているとのことです。

専門知識を持ったエキスパートの判断プロセスを仕組み化することで、情報の整理や判定にかかる時間が約50%削減、判断の根拠が明確に提示されるため、新任の担当者であっても短期間で実務に対応できるようになるといったメリットがあります。

ルールの内容を差し替えるだけで同じ構造を他業務にも横展開できるため、非常に汎用性が高く、今後さらに多くの領域での活用が期待されるアーキテクチャです。

おわりに

私もついつい LLM の自律性に期待するあまり、プロンプトの工夫だけで全てを解決しようとしてしまいがちですが、本番業務での膨大な例外を全てカバーすることは現実的に不可能です。

自由に推論してもよい部分と、決定的な制御をかけなければいけない部分を業務影響から逆算し、どこに境界線を引くかの見極めが、生成AIによるDX化の勘所の一つであると感じました。

エンタープライズの現場でAIエージェントを真に役立てるための解像度が一段上がる、非常に有意義なセッションでした！