プロジェクト概要

審査部門の人員が数十名規模の金融系事業者で、与信判断の前段にあたる審査書類の処理を AI 駆動開発 で効率化したプロジェクトです。提出された申込書・本人確認書類・収入関連の証憑などを担当者が一枚ずつ目視で確認し、システムへ転記し、不備があれば差し戻すという流れに工数が集中していました。

私たちが構築したのは、書類から必要な項目を抽出し、典型的な不備パターンを事前にチェックして担当者に提示する補助の仕組みです。最終的な可否判断や差し戻しの意思決定は必ず人間が行う前提で設計し、AI はあくまで確認作業の下ごしらえを担います。規制業界らしい監査要件とトレーサビリティを満たしながら、確認工数を約半分に削減できた堅牢性重視の実証ケースとして、設計判断と実数値を公開します。

金融領域は誤りが直接的な損失や規制上の指摘につながるため、精度よりも「間違え方をコントロールできること」が問われます。本記事では、その制約の中でどう AI を組み込んだのかを具体的に書きます。

業務上の課題

着手前の審査書類処理には、規模の大きな事業者で繰り返し見られる課題が揃っていました。

ひとつは確認工数そのものです。1 件の審査につき複数種類の書類があり、担当者は記載項目の読み取り、システム入力、整合性の目視確認を手作業で行っていました。1 件あたり平均で 15 分前後、繁忙日には審査部門全体で数百件が積み上がります。

ふたつめは見落としの問題です。氏名や住所の表記ゆれ、書類間での金額・日付の不一致、必要書類の欠落といった不備は、人間が長時間続けて確認するほど検知率が落ちます。差し戻しが後工程で発覚すると、申込者への再依頼が発生してリードタイムがさらに延びていました。

みっつめは繁閑差です。キャンペーンや月末月初に申込が集中すると処理が滞り、逆に閑散期は人員が余ります。人手だけで山谷を吸収するのは難しく、ピークに合わせた要員確保はコスト増に直結していました。

そして金融特有の制約として、監査要件があります。誰がいつ何を確認し、どの判断に基づいて承認・差し戻ししたのかを後から追跡できなければなりません。新しい仕組みを入れるなら、この追跡可能性を一切損なわないことが前提条件でした。発注検討段階で「AI を入れて精度が下がったら本末転倒」という懸念を強くお持ちだったため、ベンダー選定の観点については AI ソフトウェア開発会社の選び方 の論点とも重なる議論を初期に丁寧に行いました。

アプローチ1: 書類の項目抽出と不備パターンの構造化

最初に取り組んだのは、業務でやっていることの「言語化」です。ベテラン担当者が無意識に行っている確認手順を、Claude Code で業務ヒアリングのメモと既存マニュアルを読み込ませながら整理し、書類種別ごとに「抽出すべき項目」と「チェックすべき不備パターン」の一覧へ構造化しました。

抽出項目は、氏名・住所・生年月日といった基本情報から、書類種別に固有の項目までを定義域として明示しています。AI に書類を自由に読ませて要約させるのではなく、抽出する項目をあらかじめ確定させ、各項目に対して値・確信度・抽出元の位置を返す形にしました。確信度が一定を下回る項目は自動で「要確認」フラグを立て、担当者に判断を委ねます。

不備チェックは、現場の知見をルールとして構造化したものを中核に置きました。たとえば書類間での氏名表記の不一致、有効期限切れ、金額や日付の論理矛盾、必須書類の欠落などです。AI による抽出結果に対してこれらのルールを機械的に適用することで、「なぜ不備と判定したか」を必ず根拠付きで説明できる状態にしています。説明できない判定は審査の現場では採用できないため、ここは早い段階で方針を固めました。

実装そのものは TypeScript で進め、項目定義やチェックルールを設定として外出しにして、現場の担当者と一緒に育てられる構造にしています。Cursor と Claude Code を併用し、ルール追加に対するテストを先に書いてから実装を生成する進め方で、仕様変更に強い土台を作りました。

アプローチ2: 人間最終判断を前提にした補助設計とログ設計

このプロジェクトで最も重視したのは、AI を「判断する主体」にしないことです。抽出と不備チェックの結果は、担当者の確認画面に根拠とともに提示されるだけで、承認・差し戻しのボタンを押すのは常に人間です。AI の出力は判断材料の 1 つであり、最終的な責任の所在を人間側に置く設計を貫きました。

具体的には、担当者の画面に「AI が抽出した項目」「確信度の低い要確認項目」「検知した不備候補とその根拠」を並べて表示し、担当者は元の書類画像と見比べながら確定します。AI の抽出値をそのまま採用するか、修正して採用するか、不備候補を採用するか却下するかを担当者が選び、その操作がすべて記録されます。

ログ設計は後付けではなく、最初の設計段階から中心に据えました。1 件の審査について、どの書類からどの値が抽出され、AI がどの不備を提示し、担当者がそれを採用・修正・却下したか、最終的に誰がいつ承認したかまでを一連のイベントとして時系列で保存します。これにより、後から「この判断はなぜこうなったのか」を抽出から承認まで一連の流れとして再構成できます。

担当者が AI の提示を却下した記録は、単なる監査用データではなく改善の燃料にもなります。却下が多い不備ルールは精度が低いか業務実態に合っていない証拠なので、定期的に却下傾向を集計してルールを見直す運用を組み込みました。人間の判断を起点に仕組みが賢くなっていく流れを作っています。

アプローチ3: 堅牢性・監査証跡・障害時フォールバックの作り込み

金融領域で動かす以上、平常時の精度よりも「うまくいかなかったときにどう振る舞うか」のほうが重要になります。ここは dodai が得意とするインフラと堅牢性の領域として、特に時間をかけました。

監査証跡については、保存するログを改ざんが検知できる形で残し、保持期間や参照権限を規程に沿って設計しています。誰がいつどのデータにアクセスしたかも記録対象としました。審査データは機微情報を含むため、ネットワーク分離やアクセス制御、保管領域の暗号化といった基本的な防御は当然の前提として組み込んでいます。

障害時のフォールバックは設計の肝でした。AI による抽出やチェックの処理が遅延・失敗した場合でも、業務全体が止まらないようにします。私たちは、AI 補助が利用できないときは従来どおりの全手動フローへ即座に切り替えられる構造を用意しました。AI はあくまで上乗せの補助であり、土台の業務フローは AI なしでも完結する、という二層構造です。これにより、外部要因で AI 処理が使えなくなっても審査業務そのものは継続できます。

加えて、AI が想定外の出力を返す可能性も常に見込んでおきました。抽出値が定義した形式に合わない、確信度が極端に低い、想定しない応答が返ってきた、といったケースはすべて「自動では確定させず人間に回す」方向に倒します。AI を信頼しすぎず、迷ったら必ず人間へエスカレーションする保守的な設計が、金融領域では結果的に最も安全でした。こうした堅牢性重視の設計思想は AI エージェント開発サービス でも共通して取っている方針です。

成果の実数値

本番運用に乗せてから一定期間の運用データをもとに、効果を確認しました。数値は事業者の事情に配慮して丸めていますが、傾向は正確です。

確認工数は、1 件あたりの平均処理時間が従来比でおおむね半分になりました。項目の転記と一次的な不備確認を AI が下ごしらえし、担当者は提示された結果の確認と最終判断に集中できるようになったためです。審査部門全体で見ると、同じ人員でこれまでより多くの件数を捌けるようになり、繁忙期の積み残しが大きく減りました。

不備の検知率も向上しています。人間だけでは見落としやすかった書類間の不一致や論理矛盾を、AI とルールチェックが機械的に拾い上げるため、後工程での差し戻し発覚が減りました。検知漏れに起因する手戻りが減ったことで、申込から審査完了までのリードタイムも短縮されています。

重要なのは、これらの改善が「人間の最終判断を外さずに」実現された点です。承認の意思決定は一貫して担当者が握ったまま、その前段の作業負荷だけを軽くしたため、精度や監査対応のレベルを落とすことなく効率化できました。

学びと再利用可能なナレッジ

この案件から得た知見は、規制のある業界全般で再利用できると考えています。

第一に、人間の承認を必ず残す設計は、効率を犠牲にしません。AI に全部を任せず確認の下ごしらえに限定したことで、現場の心理的な受け入れも早く、運用開始後のトラブルもほとんどありませんでした。「AI が間違えても人間が止められる」という安心感が、結果として導入スピードを上げます。

第二に、トレーサビリティは後から足せません。何をどう記録するかは、抽出・チェック・判断の流れを設計する最初の段階で決め切る必要があります。ログを後付けしようとすると、データの取り方を根本から作り直す羽目になりがちです。最初から監査を前提にデータモデルを組むことが、規制業界では遠回りに見えて最短でした。

第三に、ルールと AI の役割分担を明確に分けたことが堅牢性につながりました。説明責任を負うべき不備判定はルールで、読み取りの手間がかかる部分は AI で、と切り分けることで、「なぜその結論になったか」を常に説明できる状態を保てます。こうした業務システムへの AI 組み込みの進め方は AI 駆動開発 のページでも整理しています。

ありがちな落とし穴

最後に、同種のプロジェクトで陥りやすい点を共有します。

ひとつは自動承認の誘惑です。AI の抽出精度が上がってくると、確信度の高い案件は自動承認してしまいたくなります。しかし金融領域では、その判断ミスのコストが大きく、監査上の説明も難しくなります。確信度が高くても最終判断は人間に残すという線引きを崩さないことが、長期的には事業を守ります。効率化の目標は「人間が確認する件数を減らす」のではなく「1 件あたりの確認を軽くする」に置くのが安全です。

もうひとつは監査ログ設計の後回しです。まず動くものを作ってからログを整えよう、という進め方は、規制業界では破綻しやすいパターンです。ログは機能ではなく前提条件として扱い、最初の設計レビューで保存項目・保持期間・参照権限まで詰めておくべきです。

そして、AI の精度に過度な期待を寄せないことも大切です。書類の品質は申込者によってばらつき、想定外の様式や記載は必ず出てきます。すべてを自動化しきろうとするより、迷ったら人間に回す保守的な設計のほうが、結果的に現場で長く使われる仕組みになります。

よくある質問

費用感はどのくらいですか。 書類の種類数、抽出項目やチェックルールの複雑さ、既存システムとの連携範囲によって変動するため一律ではありませんが、業務分析から仕組みの構築、監査証跡まで含めた実証フェーズで数百万円規模が 1 つの目安です。まずは対象書類を絞った小さな範囲で効果を検証し、確認できてから対象を広げる進め方を推奨しています。

セキュリティや機微情報の取り扱いはどう担保しますか。 ネットワーク分離やアクセス制御、保管領域の暗号化、操作ログの記録を前提に設計します。データの保持期間や参照権限は事業者の規程に沿って組み、改ざんが検知できる形で監査証跡を残します。外部に出してはいけないデータの扱いについても、設計初期に方針を固めてから実装に入ります。

既存の基幹システムと連携できますか。 可能です。本プロジェクトでも審査の前段に補助の仕組みを差し込み、最終的な登録や承認は既存フローに戻す形を取りました。一度に全体を置き換えるのではなく、AI 補助なしでも業務が完結する土台を保ったまま上乗せする構造にすることで、連携リスクと業務停止リスクを抑えられます。

審査・与信・ドキュメント処理など、規制と精度の両立が求められる業務に AI を組み込みたいとお考えなら、堅牢性と監査証跡を前提にした設計を私たちがご一緒できます。まずは対象業務を絞った実証から、AI 駆動開発の無料相談 でお気軽にご相談ください。