🐧

文書AI PoCが失敗しやすい3つの理由と、再現性を高める評価設計の考え方

に公開
AI
LLM
生成 AI
文書ai
評価設計
idea

はじめに

社内で扱う文書をAIが自動で読み解くために、文書AIのPoCに取り組む企業が増えていますが、成果が出ないまま止まってしまうケースは少なくありません。

私自身、最初に受け取った数十種類の報告書を開いたとき、同じ項目なのに使用する語句や表記、レイアウトや記載方法まですべてが違っていて、手が止まったことがあります。

「人が見ても解釈が分かれそうな資料を、どうやってAIが自動化できるのだろう・・？」

この“揺らぎ”を処理する仕組みを整えないと、AIは安定して動きません。

PoCが進まなくなる理由は、「業務課題の定義が曖昧」「データ品質が低い」など多岐にわたりますが、特に実運用化を妨げる直接的なボトルネックとなるのが、「評価設計と改善サイクルの欠如」です。

AIの出力が「だいたい合っている」ように見えても、
最後の調整段階でどこを直せば精度が上がるのかが判断できない。
結果として、PoCはそこで終わってしまいます。

この記事では、実プロジェクトで「正規化一致率95%」を達成した経験をもとに、
評価設計をどのように考え、どう現場に落とし込むか
を具体的に紹介します。
後半では、改善を回すための実践的な仕組みや、再現性を高めるプロンプト設計の工夫にも触れていきます。

1. PoCが失敗する3つの典型パターン

文書AIのPoCでつまずく要因は、以下のパターンが多い印象があります。

パターン1: モデル精度が上がらない（と感じてしまう）

モデルの精度が追い付いていない場合はもちろんありますが、その裏側には「モデルの性能不足」ではなく、表記ゆれ・レイアウトの考慮・暗黙の業務ルール等に対する設計不足が原因で、精度が出ない場合が多いです。

私も初期段階では、複雑なケースをすべてAIに任せようとし、
プロンプトが肥大化して逆に精度が不安定になったことがあります。
結局、「まず標準ルールを決めて再現性を高める」ほうが、はるかに安定しました。

パターン2: 評価方法が曖昧

「だいたい合っている」「前より良くなった気がする」と感覚的に判断してしまうと、どこをどう改善するべきかの議論を数値で語ることが出来ません。

実際、クライアントから
「この5％の誤りは何が原因で、どうやったら改善出来ますか？」
と聞かれたとき、説明に詰まった経験があります。

評価基準や評価方法が曖昧なまま進めると、
「人がやったほうが確実だよね」という結論に至ってしまい、「精度が低くて使えない」「まだAIを活用するのは時期早々」と結論付けてしまいます。

パターン3: 改善サイクルが回らない

実際に検証を行って、ある程度の見込みが立った段階でも、数値化や継続的な検証/改善の仕組みが無いため、プロンプトやモデル変更の効果を定量的に比較できず、安定した精度改善を行えないケースがあります。

評価基準・正解の定義・改善のルールなどを定義しないまま場当たりにチューニングするとデグレや再現性欠如に陥る、という現場知見はすでに複数の実務記事でも強調されています。(Zenn)

2. 問題の本質：評価設計を後回しにする構造

「まず動かしてみる」ことの落とし穴

多くの現場で共通しているのが、「まず動かしてから考える」という進め方です。
最初にとりあえずモデルやプロンプトを動かして、結果を見ながら調整することがほとんどです。
しかしその時点では「何を基準に良し悪しを判断するか」が決まっていないため、改善しても成果が測れない状態になります。

AI導入が「動くかどうか」を確かめる実験から始まる以上、「評価」はつい"最後に考えるもの"になりがちです。
本来は、「何を測るか」「どう測るか」を最初に設計してPoCを行うことが大事になります。

技術指標と業務目標の乖離

もう一つの落とし穴は、技術的な指標と業務的な成果指標が噛み合っていないことです。

PoCを行うデータサイエンティストが「F1スコア90%！」と喜んでも、現場担当者に見せると「結局、人手確認が必要」と冷めている―― これはよくある話です。

  • 技術指標：精度、適合率、再現率など
  • 業務指標：手戻り工数の削減、確認時間の短縮、クレームの減少

評価設計の目的は、これらの指標を橋渡しすることにあります。

私の経験では、
「どの項目の精度が業務的に一番重要か」
を整理することで、自ずと改善の優先順位や評価基準が決まっていきました。

「完全一致」に引っ張られすぎる

  • 例えば、「1,000,000円」と「100万円」は文字としては一致しませんが、実務では同じ値です。
  • また、「90日前に通知」と「三ヶ月前にご連絡」も、同じ意味になります。

このような、「意味的に一致するかどうか」を判定する仕組みを、ここでは「正規化一致」と呼びます。

文書AIの精度を正しく測るためには、この「意味の一致」をどう定義するかが鍵です。
現場に適した正規化設計を後回しにすると、モデルの良し悪しが判断できなくなります。

3. 評価設計の3つのポイント

今まで経験してきたプロジェクトでは、以下の3つを意識して評価設計を行っています。

① スキーマ定義で構造化を強制する

抽出項目をJSON形式のスキーマ（項目と値のパターンを指定したフォーマット）で定義すると、
LLMの出力が安定し、評価も自動化しやすくなります。

{
  "契約日": "2025-10-29",
  "契約金額": 1000000,
  "契約者名": "山田太郎"
}

マルチモーダルLLMの抽出でもStructured Output／型付き出力を使い、項目ごとのdescription等で抽出の誘導を掛ける設計が効果的と報告されています。(Zenn)

② 意味レベルの評価（業務ルールを評価に組み込む）

少し踏み入った話をすると、実際の現場では点検・解約・承認といった言葉が企業や業界ごとに異なる意味を持っています。

例1：
「点検」とは、動作確認に加え、目視のみの確認も含む。

例2：
「解約通知」とは、中途解約の通知だけでなく、自動更新を停止する旨の通知も含む。

こうした企業・業界固有の解釈を明示的にプロンプトや評価設計に落とし込み、PoC段階から反映させます。
つまり「技術的に正しい」よりも「業務で使えるか」を意識して評価する設計です。

評価基準とデータセットを揃える重要性は、こちらでも語られています。(再掲:Zenn)

③ 根拠の出力でトレース可能にする

いざAIの出力を評価する際に重要なのは、「なぜそう答えたのか」まで辿れるということです。
単に正答率を比較しても、モデルの思考過程が見えなければ、改善につながりません。

たとえば契約書から「契約終了日」を抽出する場合を考えます。

出力：2025-12-31
根拠：第10条（契約期間） 本契約は2024年1月1日から2025年12月31日までとする。

このように出力と根拠をペアで記録すれば、
誤抽出が起きた際に「どの文をどう解釈したか」を即座に検証できます。

さらに、
「根拠が存在する回答だけを評価対象にする」というルールを設けることで、
AIが想像で補完した誤回答（いわゆる"ハルシネーション（幻覚）"）を除外することが出来ます。

4. 改善サイクルを回す（評価設計をPDCAに）

評価設計が完了したら、PDCAサイクルとして継続的に検証・改善のプロセスを回せるようにします。単発のチューニングで終わらせず、「測る → 分析する → 修正する → 再評価する」流れを可能な限り自動化＆見える化することで、本番移行もスムーズになります。

以下に改善サイクルを回しやすくするための設計のヒントを紹介します。

タスクを分けてチューニングしやすくする

抽出・整形・加工といった処理を1つのプロンプトやコードに抱え込みすぎないようにします。
単純で定型的な文書では一度に実行しても良いですが、複雑なケースではどの段階で誤差が発生したのかを明確に出来るように設計します。

たとえば、

  • ステップ1：OCRで文字抽出
  • ステップ2：構造化抽出（JSON化）
  • ステップ3：正規化処理（表記ゆれ、単位変換）
  • ステップ4：意味評価と一致率算出

というように、タスクを分けてログを残すことで、"どこで間違えたのか"を把握できるようになります。

評価基盤を可能な限り自動化・見える化する

PoCを重ねてゆくと、「モデルを変えた」「プロンプトを直した」などの変更が頻繁に発生します。
そのたびに人手で比較評価を行うのは労力や工数がかかります。

理想としては、スキーマ・正解データ・比較ロジックをテンプレート化し、
改善サイクルを自動で回す仕組みを目指します。

例えばLangfuseなどの評価基盤を用いる場合、

  • 各試行の出力・根拠・スコアをログとして保存
  • LLM-as-a-Judgeによる自動評価を併用
  • 人手評価との一致率（Cohen’s κなど）を監査

といった運用が可能です。

こういった仕組み導入することで、変更のたびに検証と確認を0から手作業で行う必要がなくなり、
過去の比較データが「評価資産」として蓄積されていきます。

Langfuseを用いた評価運用の具体例については、こちらのZennの事例で詳しく書かれています。

再現性を高めるプロンプト設計の工夫

評価設計がうまく機能するためには、AIから出力される内容の再現性が高いことも重要です。PoC段階で安定した結果を得るための実践的ノウハウを紹介します。

直接証拠主義を徹底する
　文書に明記された情報のみを根拠として、わからない場合は「わからない」と出力させる。
　→ 「AIが想像で補う」誤差を防ぎ、評価の一貫性を確保。

ルール間の優先順位を明示する
　複数の条件が競合する場合、優先順を明記する。
　→ ルール衝突による出力ゆらぎを抑制。

用語定義を文脈レベルで指定する
　業界や企業ごとの暗黙の定義（例：「点検」「解約通知」の解釈）を明示する。
　→ モデルが誤った"常識"で補完するのを防ぐ。

「一度動いたが、次回は出力が変わった」という典型的なPoCの失敗を防ぐための工夫で、LLMが迷わずに答えられるガイドライン作りが大事になります。

5. 実務での成果と学び

これらの仕組みを取り入れたプロジェクトでは、非定型文書の抽出精度（正規化一致）が平均95%まで向上し、手作業確認の大幅削減と本番移行が実現できました。

特に大きかった学びは、

  • AIに複雑さを詰め込むのではなく
  • ルールを整理し、評価軸を固定し
  • 改善サイクルを仕組み化する

ことが、本番運用へ進む上で最も重要だったという点です。

6. まとめ：適切な評価設計で、再現性と実用性を目指す

評価設計 → 自動評価 → 人のレビュー → 改善のPDCAサイクルをPoC初期から設計することが、PoCを"1回きりの実験"で終わらせないためのポイントです。

評価設計を適切に行い、定量的な改善サイクルを整備することで、PoCから本番導入までスムーズに進めることが可能です。

参考記事

Discussion