トップ > AI > 業務特化型AIエージェントのHITLはどう組み込まれているのか？：Claude金融エージェントを動かしてみた

業務特化型AIエージェントのHITLはどう組み込まれているのか？：Claude金融エージェントを動かしてみた

AI 検証レポート

1.はじめに

NTT西日本の倉田 裕紀です。
本記事では、Anthropic が金融サービス業界向けに公開しているAIエージェントテンプレート群「Claude for Financial Services」*1を動かし、業務特化型AIエージェントにおける HITL（Human-in-the-Loop：人間が確認・承認する仕組み）がどのように組み込まれているかを観察しました。
※本記事は2026年5月時点の情報に基づいています。

ここでいうHITLを成立させる制御とは、AIに何を任せ、何を根拠として残し、どこから人間が確認・承認するかを、出力や処理の中に組み込むことです。

対象読者：AIエージェントの企業導入、業務特化AI、AIガバナンスに関心のある方

2.背景・目的：業務特化型AIエージェントに組み込まれた制御

AIエージェントの企業導入が進む中で、重要になるのは「どの作業を自動化できるか」という利便性だけではありません。業務データや外部システムと接続して使う場合には、出力の根拠をどう残すか、人間がどこで確認・承認するか、AIエージェント単独で実行させない操作をどう分けるかといったガバナンス設計も重要になります。

近年は、AIエージェントを管理・統制するための基盤や、外部ツール接続・エージェント間連携のためのプロトコルも登場しており、AIエージェントは単体の便利機能ではなく、運用・統制・監査を含む設計対象になりつつあります。

Anthropicが公開している「Claude for Financial Services」は、金融サービス業界向けの業務特化型AIエージェント群です（以降、Claude金融エージェントと呼びます）。金融分野はガバナンス要件が厳しい領域として知られており、AIエージェントに組み込まれた制御の観察対象として適していると考えました。

本検証では、公開されている Claude金融エージェントの一部を動作させ、HITLを成立させるための制御が、出力や実行ログにどのように表れているか、を観察して整理します。

3.検証対象：Claude金融エージェントと今回選んだエージェント

Claude金融エージェントはGitHub上でも公開されており*2、現時点で（2026年5月時点）次の10種類のエージェントが、4つの業務カテゴリに整理されています。

Claude金融エージェントの分類

カテゴリ エージェント 役割
Coverage & advisory（顧客対応・営業準備） Pitch Agent 提案資料の作成
Meeting Prep Agent 顧客ミーティング前のブリーフィング作成
Research & modeling（リサーチ・モデル構築） Market Researcher 業界や市場の調査
Earnings Reviewer 決算内容の確認と分析メモ作成
Model Builder 企業価値評価モデルなどの作成
Fund admin & finance ops（ファンド管理・経理オペレーション） Valuation Reviewer 投資先評価のレビュー
GL Reconciler 経理データと業務側データの差分チェック
Month-End Closer 月次決算の締め処理
Statement Auditor 投資家報告書の事前確認
Operations & onboarding（運用・口座開設） KYC Screener 口座開設書類の確認

※各エージェントの詳細は、Claude for Financial Services GitHubリポジトリを参照してください。

上記のとおり、4カテゴリに合計10種類のエージェントが整理されています。 本検証では、この中からMeeting Prep Agent（顧客ミーティング前のブリーフィング作成） とGL Reconciler（経理データと業務側データの差分チェック） の2つを動作確認しました。

Meeting Prep Agentでは、出典提示、未確認事項の明示、ドラフト扱いといった、主に出力内容の確認を支援する制御が確認できました。一方、GL Reconcilerでは、これらに加えて、差分ごとの担当部署のヒント、対応案、承認要否、記帳権限の分離、別役割による再確認といった、業務フローに接続しやすい制御も確認できました。

そのため、本記事では GL Reconcilerを中心に取り上げます。

4.検証の概要：GL Reconcilerの実行条件

本検証では、Claude Code CLI（コマンドラインから Claude を操作するツール）を用いて、GL Reconcilerを動作させました。

実行環境

項目 内容
実行基盤 Claude Code CLI
Claude Code CLI バージョン v2.1.139
使用モデル Claude Opus 4.7
プラグイン Anthropic の financial-services marketplace
導入エージェント gl-reconciler
実行方式 プラグインに同梱されたサンプルのMarkdownファイルを入力として実行

入力データの扱い

このエージェントは、MCP（Model Context Protocol：外部データソースとAIモデルを接続するためのプロトコル）経由で、CRM、市場データ、帳簿システムなどの外部データソースと接続する設計になっています。

本検証では外部接続を使わず、gl-reconciler プラグインに同梱されているサンプルデータ（gl_balances.md、subledger_balances.md、transactions.md、threshold.md）を、MCPのレスポンスの代わりに読み込ませました。これらはAnthropicがエージェント検証用に提供しているサンプルで、実在しない口座・取引を想定したデータです。

入力データは、経理データ（経理側の口座残高）、業務側の口座残高、取引データ（取引明細・仕訳・運用メモ）、閾値設定（差分判定）の4種類です。

検証対象は、Equity（株式）5口座とFixed Income（債券）4口座の計9口座です。差分の重要性を判定する閾値は10万米ドルに設定しています。

なお、これらのサンプルデータには、差分金額はあらかじめ記載されていません。エージェントが経理データと業務側の口座残高を突き合わせて差分を自力で計算し、取引データと照らし合わせて原因を特定する設計になっています。

※本検証はローカル環境で実施しており、実際の業務システムや外部サービスとは接続していません。

5.検証結果：出力からわかった制御観点

GL Reconcilerを動かす前は、主に差分金額や原因分類が出力されるものと考えていました。 実際に動かしてみると、担当部署のヒント、対応案、承認要否、記帳権限の扱いまで出力に含まれており、人間レビューや後続の業務フローにつなげるための情報が構造化されていました。

GL Reconcilerは、9口座を照合し、5件の差分（break）を自力で検出しました。残り4口座は整合（差分ゼロ）と判定しています。検出した5件のうち、4件は閾値（10万米ドル）を超える重要な差分、1件は閾値未満（監視のみ）です。

口座 銘柄 差分（経理 − 業務） 原因の分類 判定
EQ-1005 AMZN（株式） -75.0万米ドル 取引が経理側に未連携（記録欠落） 閾値超
FI-2002 AAPL（債券） -45.0万米ドル 利息計上が締め後にずれ込み 閾値超
EQ-1002 MSFT（株式） -27.5万米ドル 時価評価のバッチ処理が一部失敗 閾値超
FI-2004 GNMA（債券） +15.0万米ドル 元本償還の仕訳が未反映 閾値超
EQ-1004 NVDA（株式） -2.0万米ドル 時価評価のわずかなズレ 閾値未満（監視のみ）

今回の観察結果を大きく分けると、次の3層で捉えることができます。

HITLを成立させる制御
├─ 1. 出力の根拠を示す
│  ├─ 根拠提示
│  └─ 未確認事項の明示
├─ 2. 人間レビューを前提とする
│  ├─ 人間確認ポイント
│  ├─ 業務状態の構造化
│  └─ 責任・対応アクション
└─ 3. AIによる自動実行を制限する
   ├─ 権限分離
   └─ 独立検証

観察された具体的な制御

カテゴリ 観点 観察された具体的な制御
出力の根拠を示す 根拠提示 差分ごとに、どのデータをもとに判断したかを示す
未確認事項の明示 外部確認や照合先は未接続のため確認できない範囲を、環境制約として残す
人間レビューを前提とする 人間確認ポイント レビュー担当者、レビュー状態、人間承認の必要性を明示する
業務状態の構造化 差分ごとに、口座・原因・担当部署のヒント・対応案をセットで出力する
責任・対応アクション 差分ごとに、対応部署のヒントと次に取るべきアクションを明示する
AIによる自動実行を制限する 権限分離 経理データへの記帳は人間承認を経由する設計とし、AIエージェント単独で実行しないことを明示する
独立検証 別役割のエージェントが、差分計算や原因分類を再確認する

今回観察できた制御を、「出力の根拠を示す」「人間レビューを前提とする」「AIによる自動実行を制限する」 の3つのカテゴリと、「根拠提示」「未確認事項の明示」「人間確認ポイント」「業務状態の構造化」「責任・対応アクション」「権限分離」「独立検証」の7つの観点として整理しました。

このうち、HITLを成立させるうえで特に注目したのは、「責任・対応アクション」、「権限分離」、「独立検証」の3つの観点です。本記事では、検出された差分に対して、これら3つの観点がどのように出力やログに表れているかを確認しました。

責任・対応アクション

検出された差分について、出力には対応すべき担当部署のヒントと、次に取るべきアクションが含まれていました。差分を承認用にまとめた exception_report の一部を抜粋します。

{
  "exception_report": {
    "for_signoff": [
      {
        "account": "EQ-1005",
        "abs_variance_usd": 750000.00,
        "owner_hint": "Back-office trade-feed operations — investigate dropped record for T-7842 and post missing settlement JE"
      },
      {
        "account": "FI-2002",
        "abs_variance_usd": 450000.00,
        "owner_hint": "Fixed-income accruals team — confirm acc-fi-eod cutoff handling; consider moving job before 20:00 ET"
      }
    ],
    "monitoring_only": [
      {
        "account": "EQ-1004",
        "abs_variance_usd": 20000.00
      }
    ]
  }
}

それぞれのフィールドの値と意味は以下のとおりです（1件目のEQ-1005の例）。

フィールド名 値 意味
account EQ-1005 差分が出た口座（AMZN株式）
abs_variance_usd 750000.00 差分金額（75万米ドル）
owner_hint Back-office trade-feed operations ... 対応を担当する部署のヒント（バックオフィスの取引連携担当）

責任・対応アクションの観点で特に注目したいのは owner_hint です。差分1件ごとに、「どの部署が対応すべきか」が出力に記録されています。たとえば口座番号EQ-1005の差分はバックオフィスの取引連携担当、FI-2002の差分は債券の利息計上チーム、というように、原因の種類に応じて担当部署が振り分けられています。

また、閾値未満の EQ-1004の差分は monitoring_only（監視のみ）に分類され、承認対象とは区別されていました。検出された差分1件1件に対して、誰が対応すべきか、すぐに対応すべきか監視に留めるかが、データとして出力に組み込まれていることが確認できました。

権限分離

GL Reconcilerは、検出した差分に対して修正案を提示しますが、それを自分で経理データに記帳することはなく、人間承認を必須としています。

{
  "next_actions": [
    "Obtain controller sign-off on the four above-threshold breaks before any corrective JE is posted (no ledger writes from this agent)."
  ]
}

ログ上でも以下のように記録されています。

writes / side effects
---------------------
- no journal entries posted by this agent
- no ledger writes attempted

特に注目したいのは「no ledger writes from this agent（このエージェントは経理データへの記帳を行わない）」という記述です。エージェントは差分の修正案（どの勘定にいくら計上すべきか）まで出しますが、その計上（仕訳の投稿）は行わず、「経理責任者の承認を得てから」と明示しています。実際にログの「writes / side effects」にも「仕訳は一切投稿していない／記帳は試みていない」と記録されていました。

経理データへの記帳は人間承認を経由する設計とし、AIエージェント単独では実行されないことが、出力とログの両方に明示されていました。AIが修正案を作るところまでと、それを実際に帳簿に反映するところとの間に、人間承認の境界が引かれています。

独立検証

GL Reconcilerは処理を3つのフェーズ（reader → critic → resolver）に分け、読み込み・検算・取りまとめの役割を分けていました。

それぞれのフェーズの役割は以下のとおりです。

フェーズ 役割 内容
reader 読み込み 経理データ・業務側の口座残高・取引データ・閾値を読み込む。9口座を確認
critic 独立検証 9口座を口座コードで突き合わせ、4口座を整合、5口座を差分と判定。資産クラスごとの合計も再計算して照合
resolver 原因特定・対応案 各差分の原因を取引データから特定し、修正案と担当部署のヒントを付ける

このうち特に注目したいのは critic フェーズです。reader が読み込んで突き合わせた結果を、critic が独立に再計算・照合していました。ログの該当部分を抜粋します。

phase: critic
-------------
- account-level join (GL Account = SL Account): 9 of 9 paired
- match     count: 4   (EQ-1001, EQ-1003, FI-2001, FI-2003)
- break     count: 5
  - above threshold: 4  (EQ-1002, EQ-1005, FI-2002, FI-2004)
  - below threshold: 1  (EQ-1004 @ USD 20,000)
- totals by asset class
  - Equity:        GL 151,080,000.00  /  SL 152,125,000.00  /  net  -1,045,000.00
  - Fixed Income:  GL 244,100,000.00  /  SL 244,400,000.00  /  net    -300,000.00
- aggregate net variance: USD -1,345,000.00 (SL > GL)

critic フェーズでは、9口座すべてを突き合わせ、差分の件数、閾値超過の有無、資産クラスごとの合計、全体の差分合計を再計算しています。AIが一度読み込んだ結果を、別のフェーズで独立に検算する構成が、実行ログ上で確認できました。

6.考察：本検証で観察できた制御手法

今回観察できた制御は、大きく「根拠の明示」「人間レビュー前提」「実行制御」の3層で捉えることができます。

  • 根拠の明示：AIの出力が、どの入力データや判断材料に基づいて作られたかを示す制御です。人間が出力を検証するための前提になります。
  • 人間レビュー前提：AIの出力を最終判断ではなく下準備として扱い、人間が確認・承認するポイントをデータとして残す制御です。
  • 実行制御：AIエージェントが重要な業務操作を単独で完結させないよう、人間承認や別役割による確認を挟む制御です。

ただし、本検証で確認できたのは、サンプルデータを用いたローカル環境において、出力や実行ログに表れた制御に限られます。実際の経理システムや承認ワークフローとは接続していないため、AIからの書き込みをAPI認可やロール管理で強制的に拒否するところまでは確認していません。

実運用でHITLを成立させるには、AIエージェントの出力上の宣言だけでは不十分です。権限管理、承認ワークフロー、監査ログ、API制御など、外側の業務システム側で「AIが実行できること／できないこと」を強制する設計が必要になります。特に、AIエージェント内の役割分割による確認は、実運用上の権限制御や監査統制そのものを代替するものではありません。

そのため、本記事で確認した出力構造、例えば担当部署のヒント、対応案、承認要否、記帳権限の扱いなどは、そのまま業務システムに任せるのではなく、ワークフローエンジンや承認基盤、監査ログ基盤と接続して初めて実運用上の制御として機能すると考えます。

7.まとめ：HITLを成立させる制御観点からAIエージェントを見る

今回は、Claude金融エージェントからGL Reconcilerを動かし、HITLを成立させるための制御が出力や実行ログにどのように表れるかを観察しました。

検証では、出力の根拠、未確認事項、人間レビュー、業務状態の構造化、責任・対応アクション、権限分離、独立検証といった観点が確認できました。これらは、業務特化型AIエージェントを企業で利用する際に、単に「便利に使えるか」だけでなく、「人間がどこで確認するか」「AIエージェント単独で実行させない操作が分けられているか」を確認するための観点になります。

今回の検証結果は一つの実装事例に基づくものであり、そのまますべての業務特化型AIエージェントに一般化できるものではありません。それでも、本記事で整理した観点は、業務特化AIエージェントにおけるHITL設計を検討する際の評価・比較の参照軸として活用できると考えます。

付録：検証に使ったデータと手順

本検証では、gl-reconciler プラグインに同梱されているサンプルデータを使用しました。同じバージョンのプラグインを導入すれば、同じサンプルデータを使って検証できます（2026年5月時点）。

環境準備

本検証では、Claude Code CLIを利用し、次の流れでGL Reconcilerを導入しました。

/plugin marketplace add anthropics/financial-services
/plugin install gl-reconciler@claude-for-financial-services

導入後、gl-reconciler プラグインに同梱されている次の4つのサンプルデータを使用しました。

  • gl_balances.md
  • subledger_balances.md
  • transactions.md
  • threshold.md

これらは、実在しない口座・取引を想定したサンプルデータです。差分金額そのものはあらかじめ書かれておらず、原因特定の手がかりは取引明細、仕訳、運用メモに含まれています。

入力データの構造

ファイル 内容
gl_balances.md 経理データ。株式5口座・債券4口座の残高
subledger_balances.md 業務側の口座残高。同じ9口座の残高
transactions.md 取引明細、仕訳、運用メモ
threshold.md 閾値設定。10万米ドル、絶対値、株式・債券が対象

実行時の指示内容

Claude Code内で、外部MCPの代わりにローカルのサンプルデータを読み込ませる形で GL Reconcilerを実行しました。実行時には、取引日を 2026-04-30、対象をEquity（株式）とFixed Income（債券）、閾値を10万米ドルとして扱いました。

処理は、実行ログ上では reader、critic、resolver の3フェーズで進み、結果はJSON形式の出力とセッションログに記録されました。

執筆者


倉田 裕紀（NTT西日本　技術革新部　AI技術担当）
AIエンジニアとして、社内外のAIプロジェクトを技術支援しています。
趣味は筋トレです。

商標

  • 「Claude」「Anthropic」は Anthropic, PBC の商標または登録商標です。
  • 「GitHub」は GitHub, Inc. の商標または登録商標です。
  • 「Markdown」は、本文中では軽量マークアップ言語の名称として記載しています。
  • 「Model Context Protocol（MCP）」は、Anthropic が公開しているプロトコル名称です。
  • その他、本文中に記載されている会社名、製品名、サービス名などは、各社の商標または登録商標です。

*1:Anthropic「Claude for Financial Services」：https://www.anthropic.com/news/finance-agents

*2:Claude for Financial Services GitHubリポジトリ：https://github.com/anthropics/financial-services

© NTT WEST, Inc.