こんにちは、Azureビジネス部の金重です。先日Microsoft様主催で開催された第4回 AI Challenge Dayに、ネクストスケープ及びJBS（日本ビジネスシステムズ）の混合チームで参加しました。
目次
AI Challenge Dayとは
イベント概要
AI Challenge Dayは業界の課題に対して参加した各社が生成AIを用いて解決する試みです。第1回に参加した際は世界遺産に関する質問に答えるチャットエージェントを構築しましたが、第4回の今回はFinancial Industryということで、金融業界における業界課題を生成AIを用いて解決する為の提案を3週間で考えました。
今回はエンジニア5人で参加し、金融の業務に詳しくない中で、どのように課題を定義し、ソリューションを提案したかご紹介します。また、その過程で技術的なソリューションを持つエンジニアが事業における課題を考えることの重要性を感じました。
取り組むテーマ
今回は生成AIのCapabilityを活かした4つのアプローチとして、テーマが紹介され、その中で各社一つずつテーマを選定しました。
- 監査や業務効率化を目的としたAIによるドキュメント処理
- 詐欺や不正検出
- ウェルスアドバイザーAIアシスタント
- Graph RAGを活用した金融業務の高度化
ネクストスケープ・JBS混合チームでは、一つ目の「監査や業務効率化を目的としたAIによるドキュメント処理」を選択しました。とはいえ、金融業界と一口に言っても対象の分野や業務も広い為、創業計画書のチェックのような融資業務に着目し、人手でのチェックを生成AIで補助する提案を行いました。
ネクストスケープ・JBSチームの提案
発表スライドを抜粋しながら課題、提案および技術的なソリューションをご紹介します。
融資業務における課題
今回融資業務として想定する業務として、顧客が申込書類を提出し、営業担当者が記載不備をチェックし、審査用の書類を作成する過程に切り込みます。
一つ目の課題として、申込書類の記載不備の確認・修正に時間と労力がかかる点です。各入力項目の内容をチェックする上で、単に空欄の有無をチェックするだけではなく、事業計画の数字の計算根拠が合っているかといったチェックに時間がかかる項目もあります。場合によっては申込書類のフォーマットが顧客によって異なり、どこに何が記載されているか探すだけでも時間がかかります。
二つ目の課題として、申込書類の活用が難しい点にあります。申込書類は様々なフォーマットがあり、これらは記載不備をチェックした後に顧客フォルダに格納されますが、PDF形式で保存され後から確認するのみで、BIをはじめとしたデータの利活用につなげられない形になっています。
ソリューション概要
この二つの課題に対して、AIを用いたデータの構造化及び記載不備の生成AIによるチェックの二つのソリューションを提案しました。
まず、申込書類を画像認識技術と生成AIを用いて、「事業計画はXXで、借入先はYYで…」といった意味をプログラムで扱える構造化データに変換します。そして、その各項目に対して、生成AIを用いて記載不備の有無をチェックします。
また、構造化データに変換することで、後で活用する際に、「各顧客の事業計画一覧」「借入先はどこが多いか」といった各項目を集計したデータやそれらを組み合わせた分析に活用できます（活用にあたって、データのコンプライアンスには留意する必要があります）。
アーキテクチャ
まずはクラウド基盤であるAzureを用いたアーキテクチャの概観を紹介します。
左から順に、申込者はPDF形式で申込書類を提出します。提出された書類は、Azure Functionsの処理の中で順々にデータ形式の変換や入力チェックが実施されます。
まず、Azure Document IntelligenceというOCR画像認識技術によって、PDF中の文字や画像、表が認識されてプログラムで扱えるようになります。しかし、書類のフォーマットによっては損益計画がそのまま「損益計画」と記載されているものもあれば、「事業の見通し」という項目で記載されているものもあり、統一的にチェックすることができません。
そこで、Azure OpenAI Serviceでフォーマットの統一化を実施します。ここでは、「この創業計画書の中で損益計画が記載されている箇所を抜き出してください」といった指示をするのですが、その際にデータの構造を定義します。例えば、「売上高は何円、売上原価は何円、計算根拠は文章で対応付けてください」といった形で指示します（実際にはSQLのスキーマを渡しますが、簡単の為に文章で表現しています）。
そして、統一フォーマット化されたデータを、再度Azure OpenAI Serviceを用いて入力チェックします。例えば「計算根拠と売上高に齟齬が無いかチェックしてください」といった指示を行います。ここで、チェック先のデータとして先ほど構造化された売上高の値、計算根拠の値といったデータを参照することで、元々PDFに記載されていたデータを生成AIでチェックすることが可能になります。
プロジェクトの進め方
課題を見極める
この提案を作成するにあたって、まず課題の定義からする必要がありました。今回のテーマ「監査や業務効率化を目的としたAIによるドキュメント処理」を見ていただけると分かる通り、ソリューションとなるAIによるドキュメント処理は指定されているのですが、監査や業務効率化の対象となる業務が何か？その業務の改善に効果はあるのか？といった点は定義されていない状態です。
生成AIに限らずプロジェクトの立ち上げでは、その問題を解く必要があるのか？と疑問が生じることがあります。安宅和人『イシューからはじめよ 「知的生産のシンプルな本質」』ではまさにこの点が指摘されており、解く価値のある問題の見つけ方が述べられています。世の中にある課題は解くべき価値があるかよく吟味する必要があります。その為、イベントの3週間という期間を、最初の1週間を課題の見極め、次の1週間を仮説検証、最後の1週間を検証結果に基づく提案のブラッシュアップという配分で、課題をいかに定義するかに注力しました。
今回エンジニア5名で金融業界に対する広い知識は無い中で課題を見つけ、その課題を解く価値を見極める為に、まずは情報収集を行いました。情報を集めるには業界の常識を本で勉強するだけでなく専門家の一次情報にあたることが重要と考え、社内の有識者へのヒアリングを実施しました。
ヒアリングの中で、ドキュメント処理に関する課題を聞くと、そもそも紙データのDX化が進んでいないといった話から始まり、記載不備のチェックという業務があることを知りました。そこで、実際に使用される書類を何種類か集めて見比べてみると、項目が多いうえにフォーマットもバラバラ、確かにこれを人手でチェックするのに時間がかかる上、そのまま保存しては後から利活用することも困難だと理解しました。
この過程を経た上で実際に人手でやっている業務を生成AIで補助した場合の人件費削減といったインパクトを概算し、融資業務における書類の入力チェックとデータ利活用の為の構造化が、今回のソリューションに合致する価値のある課題であると認識して進めることにしました。
仮説を検証する
今回のイベントはいわばアイデアソンで、プログラムを組むことが目的ではありません。しかし、課題とソリューションを提案する上で、その課題の解く価値があることに加えて、実現可能であることを示す必要がありました。
提案の骨子を固めながら、アーキテクチャ図にあるような実装レベルでの処理の流れを整理しました。様々なフォーマットの書類を構造化データに変換して入力チェックをする中で、3つの検証ポイントが抽出され、これらを期間内に進める必要がありました。
- 書類を綺麗に認識できるか
- データ構造にフォーマッティングできるか
- 構造化された各項目の入力チェックができるか
とはいえ、3週間のイベントの中で検証に失敗した場合に提案が困難になる為、打ち合わせ中に手元で簡単に確認してしまって「この検証ポイントはこの程度できそうなので進めましょう」とコメントする場面もありました。
一つ目の検証ポイントについては、Azure Document Intelligenceを用いてPDF形式のファイルを認識してMarkdown形式の文書に変換させた際、文字や表をどの程度綺麗に抽出できるか検証しました。実際の業務では顧客が複数の場所に申込書類を提出する為に手書きではなくExcelに入力する場合が多いと聞いていたこともありパソコンで入力した書類をメインにしたのですが、文字は綺麗に取得することができました。また、表は綺麗に認識できた部分も多いのですが、表の形が特殊な場合や文字に近い部分では認識できないこともありました。実はこの点については、表が崩れていても文字が認識できていれば次の検証ポイントでデータ構造を綺麗に格納できる場合がありました。
二つ目の検証ポイントについては、PDF形式のデータをSQLのレコード形式（検証時はSQLスキーマと互換性のあるJsonフォーマット）に変換しました。SQLのスキーマを自分たちで指定することで、業務としてチェックしたい項目を定義することで形式知化するメリットも暗に意識しています。実際に試してみると、Markdownの項目名は「今後の見通し」であっても内容を考慮して「損益計画」のスキーマに合致させることもでき、意味を考慮して各項目に対応づいています。
三つ目の検証ポイントについては、SQLのレコード形式で格納された各項目について、生成AIで入力チェックを行いました。スキーマの項目ごとにチェックしたい項目を指定し、それぞれ順番にチェックしていきます。例えば投資計画では、「必要な資金と調達する資金の合計金額が一致していること」、取扱商品・サービスでは「単価・席数・来店予想客数といった情報が記載されている」のように数字だけではなく、文字の意味を理解して書いてあるかを理解する必要があります。デモとしては数字の計算も含めある程度成功していたのですが、実際には数字の計算が弱いことが見込まれるため、そこは将来研究となりました。
今後の展望
今回のイベントはアイデアソンであり、実際にシステムを構築するものではなく、作成物もデモンストレーションを行うにとどまりました。アイデアを提案するにあたって仮説検証は行いましたが、精度を上げる余地があります。例えば、損益計画の計算根拠をgpt-4oモデルを用いてチェックしていたのですが、本来生成AIは数字の計算に弱いと言われています。
これに対して、プロジェクト内で解の質を上げるには、Function Callingという仕組みを用いて計算は他の方法で任せてその結果の整合性を生成AIでチェックする、より計算に強いモデルを使用するなどの方法が考えられます。丁度本記事の執筆中にo1モデルよりプログラミングなどの論理的な課題に強いと言われるo3モデルの登場がOpenAI社から発表されたこともあり、今後数か月、数年での生成AIの進歩を待つことも一つの案になると考えています。
一方で、PDFの書類を綺麗に認識する方法については、直近での解決が困難であるとも感じました。生成AIについてはプロンプトエンジニアリングや今後のサービスの発展による直近での改善が期待できますが、ドキュメント認識の技術についてはユーザー側での開発のオプションが比較的少なく、今後のサービスの発展を待つか、或いは本腰を入れて表の認識に強いモデルを開発するなど、質を上げる為のソリューションにより高い技術力が求められます。また、今回は対象外としましたが手書き文字の認識は困難な課題であり、技術で解決するのか、運用面で対処するのか検討する必要があると考えています。
また、統一フォーマット化についても、様々な書類から項目を抽出するにあたって書類の例を覚えることで、プロンプトエンジニアリングとして例示する手法が使用できます。「以下のSQLスキーマに合致するようデータを構造化してください。例えばこんな項目はA、こんな項目はBに、こんな項目は…に対応付けてください。」と例を与えることで、より正確に統一フォーマット化ができると考えています。このように、実際のデータを集める、業務を理解することで生成AIに与える指示を強化することも可能になります。
提案の中では、解の質を上げるだけではなく、このシステムが実現した先にあるデータの利活用についても展望を述べています。今回は融資業務に着目しましたが、ソリューションであるデータの構造化と入力チェックの仕組みによって、他の業務についても展開することで各種業務特化AIの導入につなげられるのではないでしょうか。
おわりに
今回、AI Challenge Day for Financial Industryに参加させていただいて、生成AIの技術への理解だけでなく、金融業界の業務や課題についても勉強させていただきました。特に、エンジニアの人達が金融業界に詳しい方々に囲まれて提案を行うことで、業務に理解がある人がコンサルティングを行うだけではなく、ソリューションを持ったエンジニアが業務を理解する重要性を感じました。
エンジニアが指示を受けて、エンジニアなりに考えて熱意をもって作ったものの現場にとって使いづらいシステムが出来上がり、使われないシステムとなってしまうことが多々あります。また、特に生成AIで顕著な課題として、生成AIに対する大きな期待から現実感の無いソリューションをイメージしてしまうことがあります。それに対して、エンジニアの側から、技術に即して実現可能性や工数も含めて地に足の着いたプロダクト実装を行う為の提案をするには、業務への理解が無いとまともに会話できないと理解しました。
私はよくイシューと解をWhat（何を）とHow（どのように）と表現します。何を解くか定義してどのように解くかという順番で物事を考えるよう意識しているのですが、現場ではこれが逆転することも多いと感じます。特に生成AIでは、生成AI（How）がある中で、どんな問題があるか（What）を探して定義する。一筋縄ではいきませんが、この順序で考える際に、HowばかりをきちんとWhatを考えて、最終的にイシューと解をセットにする力が求められるのだと思います。
