課題

行内の規程は膨大で、しかも改定されます。どの版が最新なのか、この取引にはどの規程が当たるのか。確認に時間がかかり、確認そのものが業務になっていました。

生成AIで解けそうに見える課題です。ただし金融機関では「たぶん合っている」では使えません。導入の可否を決める前に、実際の業務でどこまで精度が出るのかを確かめる必要がありました。

打ち手

行内の問い合わせと規程参照を想定したチャットボットを試作し、精度と業務適用の可能性を検証しました。

  • 規程文書を取り込み、質問に対して該当箇所を引いて回答する
  • 回答が何を根拠にしたかを必ず示す
  • 想定質問を用意し、回答が正しいかを人が採点する

PoC の目的は「動くものを見せること」ではなく「導入していいかを判断できる材料を出すこと」です。動くデモは作れば作れますが、それだけでは稟議に出せません。

進め方

先に評価の物差しを決めました。何問中何問正解なら合格なのか。惜しい誤答と危険な誤答をどう区別するのか。

金融機関では、間違った回答の種類によって重大さが変わります。「答えられなかった」は許容できても「もっともらしく間違えた」は許容できない。この区別を採点基準に入れました。

検証の結果は、できたことだけでなくできなかったことと、その理由まで整理して引き渡しています。導入を見送る判断も、根拠があれば正しい判断です。

この事例から言えること

PoC は「作ってみる」ではなく「判断材料を作る」工程です。ゴールと合格ラインを先に決めておかないと、動くものはできても意思決定には使えません。

【公開前に埋める】検証期間と体制/評価に使った質問数と正答率(実数)/検証後の判断と、その後どう進んだか