エージェント型AIで審査ワークフローを自律化する ― ツール呼び出し・判断・エスカレーション

Function CallingやMCPを活用し、審査の取得→判定→通知→エスカレーションを自律的に行うエージェント設計を、主要APIの比較とともに解説します。

従来のパイプライン型審査AIの限界

「AIを審査に使っている」と一口に言っても、多くの現場では固定的なルールベースのパイプライン――入力を受け取り、分類し、スコアを返して終わり――に留まっています。

この方式には構造的な限界があります。

つまり従来型は「判定」をAIが手伝うだけで、ワークフロー全体を動かすのは依然として人間です。ここにエージェント型AIが解決しうる大きな余地があります。

エージェント型AIとは ― 自律性・ツール呼び出し・計画能力

エージェント型AIとは、与えられた目的に対して、必要な情報を自ら集め、判断し、外部ツールを呼び出してアクションを実行し、例外時には人間にエスカレーションできるAIのことです。

この自律的な動作を支える共通の実装基盤が、**Function Calling（Tool Use）**です。LLMモデルが外部ツール（データベース検索、API呼び出し、通知送信など）を呼び出し、その結果をもとに次の判断を行う仕組みで、OpenAI・Anthropic・Googleの各社が標準的なAPIとして提供しています。

審査業務に写像すると、以下のような対応関係になります。

金融庁のAI Discussion Paper（2025年3月公表）でも、生成AIのユースケースとして「組織の意思決定に関わる文書ドラフト」「AML/CFT」「信用スクリーニング」「監査業務」が俯瞰されており、業務の"判定・審査"への適用が射程に入っていることがわかります。一方で、同資料は「顧客対応への直接提示はハルシネーション等のリスクにより限定的」とも整理しており、判断や通知を自動化するほどHuman-in-the-Loop（HITL）、権限管理、監査ログが要件化しやすい点が重要です。

審査ワークフローへの適用設計 ― Plan → Execute → Review パターン

エージェント型AIを審査業務に適用する際の基本設計パターンは、Plan → Execute → Reviewの3フェーズに分解できます。

このパターンの核心は、「判断」と「実行」を分離し、実行前に"止められるポイント"を明示することです。承認の確定、顧客通知の送信、システムのステータス更新——こうした不可逆なアクションの前には必ずレビューを挟みます。

KYC/AML領域では、この考え方がさらに発展し、複数のAIエージェントが工程を分担して人は例外処理と監督に寄せる"工場型"の概念が提案されています。各エージェントの相互作用に監査証跡が残る設計が前提とされており、Plan → Execute → Reviewの各段階でトレーサビリティが確保されます。

主要APIのFunction Calling比較 ― 審査設計の観点から

OpenAI：Responses APIへの移行とAgents SDK

OpenAIの審査ワークフロー実装において、最も重要な技術判断はAssistants APIの廃止です。2025年8月に廃止通知が行われ、2026年8月26日に停止予定で、推奨移行先はResponses APIと明記されています。実装パターンも「Assistantsが隠蔽していたループを、Responses側でより明示的に管理する」方向へ移行しています。

審査の自律化で効く具体の制御パラメータは以下の通りです。

さらにOpenAIはAgents SDKを提供しており、「ツール使用」「別エージェントへのハンドオフ」「フルトレース」を支えます。トレースに構造化スコアを付けて分析するtrace gradingまで公式ガイドに含まれており、審査のような説明責任が必要な業務では、この「何が起きたかの完全な記録」が監査ログの要件にそのまま合致します。

Anthropic：サンプリングループとpause_turn

AnthropicのTool Useは、クライアントツール（自前実装）とサーバーツール（Web検索などAnthropic側で実行）の2系統で整理されています。

サーバーツールは「サーバ側のサンプリングループ」で複数回ツール実行が走り、デフォルト上限に達すると**pause_turnで停止**し、追加の会話継続（再送）で完了させる仕様です。これは「審査が長引くケース（追加照会が連鎖する）」に直結するため、実装時に必ずハンドリングが必要になります。

コスト面では、ツール定義（schemas）やtool_use/tool_resultブロック分のトークンに加え、ツール使用のための追加システムプロンプトトークンも加算されます。審査のようにツール定義を多く渡す用途ほど、この固定上乗せが効いてきます。

Google：statelessゆえの設計含意

Gemini APIのFunction callingは「外部ツール・APIに接続し、モデルがいつ呼ぶか・どんな引数かを決める」仕組みとして整理され、知識拡張・能力拡張・アクション実行の3用途が提示されています。

審査設計で特に注意すべきは、Gemini APIがstatelessであるという点です。マルチターンでは「thought signatures」で文脈維持を行うため、実務上は毎ターンで必要情報を再送する設計になりやすく、トークンコストや最小権限・最小入力の設計が重要になります。

3社の比較まとめ

MCPによる業務システム連携の標準化

MCPとは何か

**Model Context Protocol（MCP）**は、LLMアプリケーションと外部のデータソース・ツールを繋ぐオープンプロトコルです（最新版：Version 2025-11-25）。JSON-RPC 2.0メッセージを使い、**Host（LLMアプリ）・Client（Host内のコネクタ）・Server（コンテキストと機能を提供）**の3者間の役割を定義しています。

審査の文脈では、「各業務システム（CRM、会計、KYC、文書管理、決裁）ごとに個別連携を作る」状態から、**「MCPサーバにツールを集約し、LLM側は共通のやり方で使える」**状態へ移行するのが基本戦略です。Language Server Protocolから着想を得たこの設計は、ツール接続の標準化を目指しています。

セキュリティの前提

MCP仕様は強力な能力（任意のデータアクセス・コード実行経路）に伴うセキュリティ要件を明示しています。

• ツールは任意コード実行であり、慎重な取り扱いが必要
• ツール説明（annotations等）は、信頼できるサーバからでない限りuntrustedとして扱うべき
• 認可はOAuth 2.1ベースで、監査やユーザー別の利用追跡にも対応
• Confused Deputy攻撃のようなOAuthプロキシ構成に特有の攻撃パターンも考慮が必要

審査の"根拠"にツール出力を使う場合、この前提は実装要件になります。

OpenAI・AnthropicでのMCP接続の実務ポイント

Anthropic側で**「閉域網オンリーにしたい」「ゼロデータ保持が必須」**という要件がある場合、ベータ機能がZDR対象外であることが設計上の分岐点になります。

マルチエージェント・フレームワークの選定

審査ワークフローの実装基盤として、主要なマルチエージェント・フレームワークの特性を整理します。

LangGraph：「状態」と「中断」の一次機能化

LangGraphは、長期実行・状態保持型のエージェントを念頭に、チェックポインタによる永続化を組み込みで提供しています。interrupt()によりグラフ実行を停止し、状態を保存して外部入力（人の承認や追加情報）を待ち、Commandで再開する仕組みが明確に用意されています。

これは**「申請Aは追加情報待ちで数日止まるが、状態を保持して再開したい」**という審査現場の要件に構造的に合致します。

CrewAI：役割分担と軽量な協調

CrewAIは、エージェントがタスクを実行し、ツールを使い、協調し、必要ならデリゲートできるフレームワークです。審査工程を「収集担当」「照会担当」「判定担当」「通知担当」のように役割分解し、逐次または並行に回す発想と親和性があります。ただし、規制・監査要件が強い場合は権限・中断・証跡の設計を別途補強する必要があります。

Microsoft Agent Framework：エンタープライズ統合

AutoGenは後継のMicrosoft Agent Frameworkへの重心移動が明確で、単一・複数エージェントの構築からオーケストレーション・デプロイまでをPython/.NETで支えるOSSとして位置づけられています。多言語SDK・標準化されたワークフロー記述・運用基盤まで含めた統合が必要な場面で検討に値します。

OpenAI Agents SDK：トレース前提の運用

ツール利用・ハンドオフ・フルトレースを提供価値として明示し、trace grading（トレースに構造化スコアを付けて失敗分析する）まで公式ガイドに含まれています。審査業務で求められる「説明可能性」「再現性」「改善サイクル」と整合性が高い選択肢です。

審査業務の要件別フレームワーク選定

暴走防止とHuman-in-the-Loop設計

リスクの3つの型

OWASPのTop 10 for LLM Applications（v1.1）は、審査ワークフローに直結する2つのリスクを明示しています。

加えて、MCP仕様が「ツールは任意コード実行」「ツール説明は信頼できない可能性がある」を前提に置いている以上、ツール出力をモデルが読む構造自体が攻撃面になることを認識する必要があります。

ガードレールを「実行基盤」で強制する

ガードレールを"プロンプトでのお願い"ではなく、APIパラメータやプラットフォームの仕組みで強制することが実務上の鉄則です。

HITLは「分岐点」に挟む

HITL設計が失敗する典型は、**「最後の承認だけ人が押す」**形に寄せてしまい、途中の誤解釈が温存されることです。

LayerXの実務事例では、エージェントが「どのフィールドを使うか」「どの演算子を使うか」といった重要分岐点で人間が必ず決定するステップを挟んでいます。さらに、利用可能な項目一覧をツールとして与え、「存在しないマスタや項目を勝手に生成する」問題を抑える（出力の選択肢を決定論的に制限する）テクニックも示しています。

監査ログを「運用の中心」に置く

審査自動化では「なぜその結論か」「どんなデータを使ったか」「誰の権限で実行したか」を説明できなければなりません。監査ログは最初から"監査用"で設計されるべきです。

OpenAIのtrace gradingでは、トレースにスコアやラベルを付けて改善点を特定できます。審査業務では以下のような指標に落とし込むことが可能です。

ただし規制業種では、データ保持要件が制約になります。OpenAIのZDR（Zero Data Retention）契約下では「OpenAI側にトレースを保存するダッシュボードが使えない」ため、自社システムへストリーミングするtrace processorsの活用が必要です。

コスト構造の分解

エージェント型ワークフローのコストは、最低でも以下の3層の合算になります（比率はシステム構成により大きく変動します）。

主要プロバイダーのツール課金比較

待機時間は「往復回数」と「並列性」で決まる

ツール呼び出しは多段往復になりやすく、待機時間が増えやすい構造です。これを緩和する主要手段が並列ツール呼び出しです。

• OpenAI：parallel_tool_callsパラメータで、同一ターンでの並列実行を制御
• Anthropic：サーバーツールがサーバ側で複数回実行されるため、1回のAPI呼び出しで完結する方向（ただし反復上限でpause_turnあり）
• 審査への含意：「外部照会→整形→判定」がセットになる業務では、どの方式がSLO（レイテンシ上限）に合うかで選定が分かれる

実務事例：日本市場の現実的な導入アプローチ

段階的導入の指針

金融庁のAI Discussion Paperでは、金融機関における生成AIの適用が3段階で整理されています。

この整理に従えば、審査ワークフローのエージェント化は、まず社内向けの稟議・経費・契約レビューから始め、(a) 根拠提示（規程へのリンク、証憑差分）、(b) 人間のレビュー、(c) 監査ログを揃えた形で本番化し、対外通知や自動承認は段階的に移行するのが現実的です。

McKinseyが提示するKYC/AMLの「エージェント工場」

McKinseyは、グローバル銀行がKYCトリガーから最終メモまでのend-to-end KYCワークフローをagentic AI factoryとして構築した事例を紹介しています。工程ごとに複数のエージェント"スクワッド"を繋ぎ、最後は人間がレビューする構成です。

重要なのは、単なる効率化ではなく以下の構造が明文化されている点です。

• 工程分割 ― 各ステップでエージェントの責任範囲を明確化
• 引き継ぎ（handoff） ― エージェント間のデータ受け渡しを標準化
• QA役の組み込み ― 品質チェック専任のエージェントを配置
• 監査証跡 ― すべてのエージェント相互作用にログが残る

同記事は、agentic AIによる生産性向上について200〜2000%というレンジにも言及しています。ただし、この数値は公開データに基づく統計ではなく"経験則"として提示されているため、自社PoCでは独自のKPIで再測定が必要です。

NTT Dataが示す「行動まで含めた代行」

国内の金融業務向け解説では、Function Callingにより審査システムのステータス更新や不備通知の下書き作成までAIが担うイメージが提示されています。これは概念提示の段階ですが、エージェント型AIが「判定」だけでなく「通知」「記録」まで含めたアクション実行に踏み込む方向性を示唆しています。

LayerXの「決定論化」と「要所HITL」

LayerXの実務事例は、審査ワークフロー自律化の鍵となる3つのテクニックを具体の運用フローに落としています。

1. ツールで選択肢を制限して決定論化 ― 利用可能な項目一覧をツールとして渡し、AIが存在しないマスタを勝手に生成する問題を防ぐ
2. 重要分岐点でHITL ― フィールド選択や演算子決定など、ロジックに影響する箇所で人間が介入
3. RAGで根拠を引く ― 検証済みルールに近いものをRAGで検索・評価し、根拠として提示

リファレンス設計：審査エージェントの構成テンプレート

一次情報の仕様と実務事例を踏まえ、審査ワークフローをエージェント化する際のリファレンス設計を示します。

設計の3原則

状態遷移モデル

審査エージェントは以下の5つの状態を持つ状態機械として設計します。

ツール呼び出しには回数上限（max_tool_calls相当）と並列化設定を先に決め、無限ループと遅延の上限を保証します。同時に、MCP仕様が強調するユーザー同意・ツール安全性の原則を満たすよう、ツール境界の統制をMCPレイヤで行います。

まとめ：まず社内審査の1工程から始める

エージェント型AIによる審査ワークフローの自律化は、「AIが判定する」段階から「AIがワークフロー全体を動かし、例外時に人間へ渡す」段階への転換です。ただし、すべてを一度に自動化する必要はありません。

従来のパイプライン型では「AIが点で手伝う」に留まっていた審査業務を、エージェント型AIは**「線（ワークフロー全体）で動かす」**ことを可能にします。ただし、その力を正しく制御するには、ツール境界の統制・分岐点でのHITL・監査ログの3つを最初から設計に組み込むことが不可欠です。まずは1つの審査工程でPoC（概念実証）を始め、実績データをもとに拡張範囲を判断してください。

Naosyでは、エージェント型AIを活用した審査ワークフローの設計から、PoC実施、本番環境の構築まで一貫して支援しています。まずは現状の審査フローの課題をお聞かせください。

この記事の著者

Naosy 編集部

レビュー・校正・審査プロセスの最適化に関する実践的なナレッジを発信しています。