自社サーバー上での保険金請求、チケット、KYC 書類の AI 自動化:COO が契約前に会社に尋ねるべきこと

保険金請求、サポートチケット、KYC 書類を自社のサーバー上で AI を使って自動化すると申し出る会社と契約する前に、その会社のシステムが、自社のバックオフィスがいま行っている仕事にどう合うのかを尋ねる。良い答えには、自社の書類のサンプルから出した数字が伴う。たとえば、人による確認がなお必要な書類が何件あるか、システムの運用に毎月いくらかかるか、といった数字だ。自社の書類を見る前に数字を出す会社には、それがどの文書で測った数字なのかを尋ねる。

会社には、自社のどの書類を最初に見せるべきか

まず、自社のどの書類を見たいのかを会社に尋ねる。この仕事をしたことのある会社は、たいてい、実際に届いている書類を1か月分求める。そこには、スキャンやスマートフォンの写真、複数の添付ファイルが付いたメールのスレッド、半分しか記入されないまま戻ってくる書式、そして社員が上長に回すケースも含まれる。さらに、保険金請求の損害発生日や本人確認書類の有効期限のように、どのフィールドが自社にとって重要か、そしてそのどれかが誤って読み取られたときに現状で何が起きるかも尋ねる。

最初の打ち合わせの前に、自社のシステムから1か月分の書類を抜き出し、チームがそれぞれにかけた時間で並べ替える。会社を試すのに使うべきなのは、最も時間のかかった書類だからだ。種類ごとに何件あるかを数え、どれを上長が判断しなければならなかったかを書き留める。

候補リストに載せたすべての会社に、これらの書類について件数を添えて書面で説明したものを送る。実際の書類を渡すのは、有償のアセスメントのために選んだ会社だけだ。アセスメントとは、本契約に署名する前に、自社のサーバー上でその会社のシステムを試す、短い最初の契約である。以下の数字の大半は、そのアセスメントから得られる。

システムが読めない書類はどうなるのか

どのバックオフィスにも、斜めから撮った写真や、新しいレイアウトの銀行取引明細書のように、システムが処理に失敗する書類がある。そのどれもが、最後には判断を下せる人のもとに届かなければならない。

アセスメントのために、自社で最も扱いにくい書類を三つ選び、それぞれが届いてから判断する人の手に渡るまでに何が起きるのかを、一歩ずつ説明するよう会社に求める。会社が説明できない段階があれば書き留め、契約の前にあらためて取り上げる。

良い答えでは、その書類はレビューキューに入る。レビューキューとは、自社のチームの、名前の決まった担当者が順に処理していく書類の一覧である。担当者には、不明瞭なフィールドに印が付いたページが表示され、その人が判断するまで、保険金請求や KYC のシステムには何も届かない。

会社は、読めない書類と誤って読んだ書類をシステムがどう見分けるのかも説明するべきだ。見つけにくいのは後者である。誤った日付や金額はほかの値と同じように見え、何かがチェックしない限り、そのまま通ってしまうからだ。

システムの答えの確認に、社員の時間は何時間かかるのか

サンプルから書類を50件取り出し、いまチームがそれぞれにどれだけ時間をかけているかを計る。アセスメントの間に、同じ50件について、その時間のうちどれだけがなおレビューにかかるかを会社に尋ねる。その差が、運用コストを差し引く前の、システムが節約する時間である。差が小さければ、社員が新しいツールを覚えるのに必要な時間と天秤にかける。

システムは書類の一定の割合をレビューに回し、その割合によって必要な社員の数が決まる。会社は本契約の署名前に、その割合を見積もるべきだ。最初の数週間についてと、最もよくある誤りが直されたあとの数か月後についてである。こうした数字がなければ、ローンチ後のチームの仕事量を計画できない。

レビューは、いまこれらの書類を扱っている人たちが行うべきだ。正しい答えがどういうものかを知っているからである。会社は、その人たちが使う画面、つまりページと印の付いたフィールドが並んで表示される画面を見せ、レビュー1件に平均でどれだけ時間がかかるかを示すべきだ。

システムが自社の社員と同じくらい正確だと、どうすれば分かるのか

社員二人に、サンプルの書類50件について、互いに相談せずに正しい答えを書き出してもらう。二人の答えが食い違うところには、チームとして合意した答えがまだなく、それらの書類でシステムを採点することはできない。そうしたケースをどう決めるかは、テストを始める前に取り決めておく。

会社はたいてい、精度をシステム全体で一つのパーセンテージとして示す。役に立つスコアは、日付や金額のようなフィールドごと、そして文書の種類ごとに示される。スコアは自社のテストセットから出すべきだ。テストセットとは、自社のサンプルの書類に自社の社員が書いた正しい答えを付けたもので、会社がシステムの調整に使わなかったものである。社員も間違えるので、同じ書類で社員も測り、システムが何と比べられているのかを確かめる。

良い答えは、価格に合意する前に合格ライン、つまりシステムが達しなければならない最低のスコアを定める。そして、そのスコアに達したらシステムが人を介さずに埋めてよいフィールドと、常に人に回すフィールドを示す。合格ラインは、保険金を二重に支払うことや、本人ではない人に口座を開いてしまうことのように、誤りが自社にもたらす損失をもとに決め、書面で会社に渡す。

テストセットの作り方は、すぐ上でリンクした、本番にたどり着かなかった AI パイロットについての記事が説明している。

最も忙しい日には何が起きるのか

月末や嵐の翌朝のように、ほかの日よりはるかに多くの書類が届く日がある。平均的な日には処理が追いつくシステムでも、そうした日には遅れをとることがある。

自社の記録から、この1年で最も忙しかった日を、その日の書類の件数とともに探し出し、その会社のシステムならその日をどう処理していたかを説明してもらう。サーバーは自社のものなので、そうした日にキャパシティを増やすには何が必要で、どれだけ時間がかかるのかも尋ねる。

答えには、自社が用意するサーバーの上でシステムが1時間に何件の書類を受け付けられるか、そして書類が1時間を超えて待たされたときに誰に連絡が行くのかが含まれているべきだ。書類は緊急の種類を先にして順番に待ち、自社の側の誰かが、ある種類の文書を手作業の処理に戻せるようにしておくべきだ。滞留を早く解消するために、書類が捨てられたり、確認されないまま先へ回されたりすることはない。

システムの運用には毎月いくらかかるのか

運用コストは構築の価格に上乗せされ、システムが動いている限り続く。自社のサーバーで動かす場合、運用コストには少なくとも四つの部分がある:

• モデルを動かすサーバー
• システムを監視し、そのアラートに対応する人員
• 社員がレビューに費やす時間
• モデルや文書が変わったときに、システムを最新の状態に保つ作業

各社から、前提を書き出した月額の見積もりをもらう。前提とは、月あたりの書類の件数、書類1件あたりのページ数、種類ごとの件数、そしてその会社が想定するサーバーである。次に、その前提を自社の実際の量と比べる。前提を示さずに運用コストを出す会社には、その数字をほかの会社のものと比べる前に、前提を書き出すよう求める。

契約には、ローンチ後の会社の月額サポート料金に何が含まれるのかを列挙しておくべきだ。たとえば、新しい文書のテンプレートにシステムを合わせる作業が料金に含まれるのか、別途請求されるのか、といったことである。

この記事は価格を示さない。費用は自社の量とサーバーによって決まるからだ。各社には、自社の数字をもとに計算してもらうべきである。

自社の文書やモデルが変わったとき、誰が気づくのか

ローンチ後、自社の文書は変わっていく。たとえば、提携先の銀行が明細書のデザインを変えたときや、新しい商品ラインで新しい書式が加わったときだ。モデルも変わりうる。新しいバージョンが出たときや、自社のサーバーでモデルを動かしているソフトウェアが古いバージョンのサポートをやめたときである。

モデルが変わるときは、切り替えの前に、自社のテストセットでシステムをフィールドごとに採点し直すべきであり、元に戻せるようにもしておくべきだ。そうしたテストのたびに誰が費用を負担するのかは、前もって取り決めておく。

ある銀行の明細書が火曜日からすべてレビューに回り始めても、あるフィールドが1週間にわたって誤って読まれても、サーバーの画面には何のエラーも表示されないままだ。これに気づくには、自社の側の誰かが毎週、文書の種類ごとにどれだけの割合がレビューに回っているかを確認するべきであり、会社は、その割合が変わったときに何をするのかを示すべきだ。

最後に何が自社のものになり、会社が去ったあとは誰がシステムを運用するのか

プロジェクトの終わりには、会社がいなくてもシステムを運用し、変更するのに必要なものが、すべて手元にあるべきだ。具体的には、コード、プロンプト（モデルが従う書面の指示）、正しい答えの付いたテストセット、システムを採点するスクリプト、そしてドキュメントである。この一覧を契約に盛り込み、あわせて会社の再利用可能なコンポーネントをそれぞれ名前で挙げ、それらで何をしてよいのかも書いておく。

次に、自社の側で誰がシステムを運用するのかを尋ねる。会社はその役割と、その人が知っておくべきことを説明するべきであり、研修はローンチ前に終えておくべきだ。答えが「当社が代わりに運用する」なら、契約が終わったときにどうなるのか、引き継ぎにいくらかかるのかを尋ねる。

EU AI Act は自社のシステムに適用されるのか

EU AI Act 第4条は、2025年2月2日から適用されている。2026年7月の Regulation (EU) 2026/1744 が定めた現在の文言では、同条は、AI システムの提供者と導入者に対し、自らの従業員、および自らに代わってシステムを操作・利用するその他の人々の AI リテラシーを支える措置をとるよう求めている。どの個人に対しても、特定の水準の AI リテラシーを求めてはいない。

同法は一部の用途を高リスクとして挙げており、その中には、金融詐欺の検出を除く自然人の信用力の評価や、生命保険と健康保険におけるリスク評価と価格設定が含まれる。こうした用途については、第26条が、システムを導入する企業に義務を追加しており、2026年の改正により、これらの義務は2027年12月2日から適用される。その場合、人間による監視は「必要な能力、訓練および権限」を持つ人に割り当てられ、企業は稼働中のシステムをモニタリングする。システムが生成するログは、企業の管理下にあるものについて、ほかの法律に別段の定めがない限り、少なくとも6か月間保存される。

EU の金融サービス法の適用を受ける銀行、保険会社、その他の金融機関は、内部ガバナンスに関する既存のルールに従うことでモニタリングの義務を満たし、ログは、それらのルールがすでに求めている文書とあわせて保存する。

自社のシステムがこれらのルールの対象になるかどうかは、自社の弁護士が判断する問題であり、この記事は法的助言ではない。社員の研修と、自社の側でシステムを運用する担当者の指名は、どちらにしても役に立つ。

どんな答えが、その会社にこの仕事の経験がないことをうかがわせるのか

• 会社が、自社の書類を1件も見ないうちに精度の数字を出す
• 会社は、モデルが「エッジケースもうまく扱える」と言うが、読めない書類がどこへ行くのかを答えられない
• 計画にレビューキューがないか、時間の見積もりもないままレビューを自社の社員に任せている
• システムが処理できる以上の書類が届いたときに何が起きるのかを、会社の誰も答えられない
• 月々の運用コストが、前提とする量とサーバーを示さないまま出てくる
• 社員の研修がローンチ後に始まるか、まったく行われない

amBrain はどこに位置づけられるか

amBrain が公に説明している言語モデルのプロジェクトは、次の一件だ:「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではなく、クライアントの名前も挙げない。amBrain が保険金請求、サポートチケット、KYC 書類のためのシステムを構築したとは述べていない。そのプロジェクトでモデルがどこで動いたか、上で挙げたやり方のうちどれを使ったかは開示しない。amBrain の価格や期間も示さない。

amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方を一行でこう説明している:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」ほかのどの会社にもそうするように、amBrain にも、そのコンポーネントを名前で列挙した一覧を求めること。

amBrain が候補リストに入っているなら、ほかの会社と同じ質問を書面で amBrain にも送る。

よくある質問

• パイロットはすでに動いている。それでも、これらの質問は当てはまるのか。当てはまる。パイロットが示すのはたいてい、システムが自社の書類の一部を読めるということであり、上で挙げたほかの質問についてはほとんど何も示さない。パイロットを、自社のバックオフィスが運用できるシステムに仕上げる作業への支払い方は、冒頭でリンクしたターンキーの AI プロジェクトについての記事が扱っている
• 自社のサーバーで動かせば、外部のモデルプロバイダーにデータが一切渡らないということなのか。そう言えるのは、すべての段階がそこで動く場合だけだ。どのモデルがどこで動くのか、そして、ホスティング型のモデルや文字認識のサービスのような外部のサービスを呼び出す段階があるかどうかを、書面で明示するよう会社に求める
• こうした打ち合わせには、自社の側から誰が出るべきか。いまバックオフィスを取り仕切っている人と、会社にアクセス権を与え、自社のサーバーがどこまで処理できるかを把握している IT チームの誰かだ