長大な報告書の本当の難所

年次報告書のような長大な文書を扱う案件で、私たちが向き合ったのは「文書が長い」こと自体ではありませんでした。本当に難しいのは、専門知識がないと見逃してしまう記述が、文書全体に散らばっていることです。

しかもそうした箇所は、たいてい「レビュー漏れの影響が大きい」箇所と重なります。財務リスクの記載、内部統制の不備、契約条件の細かな注記——これらを見逃さずに拾い上げる仕組みが必要でした。

気づき：辞書ベースだけでは、人間の負荷が増えていく

最初から、用語辞書とAugmented キーワードによる検索は行っていました。レビューサイクルの中で辞書を育てていく運用です。

ただ、これでは類語や意味的に近い表現の漏れがどうしても蓄積します。「為替リスク」は拾えても「外貨建て負債」や「円安の影響」といった、意味的には関連するが辞書に無い表現は拾えません。

この状態を放置すると、AIが拾いきれない分だけ人間のレビューに依存し続けることになります。効率化のためのAIが、かえって人間側に負荷のかかるヒューマンインザループを生んでしまうリスクは、日経の記事でも指摘されている通りです。この問題は先回りして設計段階で見越しておく必要がありました。

設計の拡張：用語検索 + 言い換えaugmentation + Embedding

そこで、用語検索・言い換えaugmentationに加えて、embeddingによる意味検索を組み合わせる設計に拡張しました。効果はシンプルに図解できます。

用語辞書ベースでは拾えなかった意味的に近い表現も、embeddingを加えることで検索対象に入る

左側（辞書 + augmentationのみ）では、辞書に登録された表現とその言い換えしか拾えません。右側のようにembeddingによる意味検索を加えることで、辞書に無い表現でも「意味的な近さ」を手がかりに拾えるようになります。

embeddingにもいろいろな手法がある

一口にembeddingと言っても、目的や文書の性質によって選択肢は複数あります。

• Word2Vec：単語単位の分散表現。周辺の単語との共起関係から意味の近さを学習する、比較的シンプルな手法。計算コストが低く、まず試す選択肢として扱いやすい
• fastText：Word2Vecを拡張し、単語をサブワード単位で扱う。専門用語の表記ゆれや未知語にもある程度強い
• 文（Sentence）単位のembedding：BERT系のモデルなどを使い、文脈を踏まえた文単位の意味表現を得る手法。単語の並び方や前後関係まで含めて「意味の近さ」を判定できるため、長い報告書の文単位の検索には向いている
• ドメイン特化でファインチューニングしたembedding：専門用語や業界特有の言い回しが多い文書では、汎用モデルのままでは意味の近さの精度が落ちることがある。ドメインのコーパスで追加学習したembeddingを使うことで、専門家が使う語彙に沿った検索精度に近づけられる

どこから始めるかは文書の専門性やデータ量次第ですが、まずWord2Vec相当の軽量な手法で効果を確認し、精度が足りない箇所からBERT系やドメイン特化の手法に広げていく、という段階的な進め方が現実的です。

優先順位づけの仕組み：確信度で人間とAIの役割を分ける

意味検索で拾える範囲を広げても、すべてを人間がレビューしていては意味がありません。そこで、章やファイルごとに分類したうえで、AIモデルの確信度をもとにレビューの優先順位を決める仕組みを組み込みました。

重要度が高い記述（赤）と、AIモデルの確信度が低い記述（黄）を分けて表示するレビューUIのイメージ

• 重要度が高い箇所（財務リスクや統制不備など）は、確信度に関わらず優先的に人間の目を通す
• AIモデルの確信度が低い箇所は、判断が難しい／学習データが少ない可能性が高いため、こちらも優先的にレビュー対象にする

この2軸で優先順位を分けることで、「AIに任せる部分」と「人間が見るべき部分」の役割分担が明確になりました。

副次効果：確信度の低いデータほど、学習データとして価値がある

確信度が低い箇所を人間に優先的にレビューしてもらう設計には、もう一つ狙いがありました。確信度が低い＝モデルがまだ学習できていない箇所でもあるため、そこにレビューが入ることで、モデル改善に効くデータから優先的に学習データ化できます。

いわゆるアクティブラーニングの考え方に近い形で、レビューのコストをモデル改善にも還元できる設計です。

データ蓄積を加速する仕組み

さらに、レビューフェーズで「この記述が漏れていた」と指摘された際に、その漏れの周辺キーワードから「このキーワードも漏れていないか」を推薦する仕組みも入れました。これはembeddingベースの探索モデルをそのまま活用できます。

これにより、

• レビューする側の体験（見逃しの周辺も一緒に確認できる）
• 辞書やアノテーションデータが育つ速度

の両方を底上げできます。レビューが単なる「チェック作業」ではなく、データを蓄積・改善するループの一部になる設計です。

理想の形：業務を手伝いながら、正しい学習データが自然に貯まる

ここまでの仕組みはどれも「レビューという作業」を起点にしていますが、本当に目指したいのはもう一段先です。専門家に「レビューしてください」と特別な作業をお願いするのではなく、専門家が普段通りの業務を完了させるだけで、その過程で正しい学習データが自然に貯まっていく——これが理想の形だと考えています。

人間の業務を"手伝う"AIが、同時に人間の業務の結果から学び続ける。データ収集のための追加作業を専門家に強いるのではなく、業務そのものが学習データの供給源になるように設計する。レビュー優先度づけや漏れ推薦の仕組みも、突き詰めればこの理想に近づくための手段の一つです。この視点を持っておくと、「どこまで人間に作業をお願いするか」の設計判断がぶれにくくなります。

PoC段階の自分に伝えたいこと

もしPoC段階の自分にアドバイスできるなら、こう伝えます。

モデルの精度を追求する前に、専門家のドメイン知識や語彙をどう効率的に集めるか、専門家のレビュー負荷をどれだけ下げられるかというUI/UXの部分を、PoC段階からしっかり設計検討すること。 そのためには、専門家と直接議論する時間を早い段階で確保すべきでした。

精度は後からでも上げられますが、専門家が「レビューを続けたい」と思える体験は、後付けでは直しにくいものです。

まとめ

長大な文書のレビュー支援は、モデルの精度勝負に見えて、実際には「人間とAIの役割分担」と「専門家の負荷をどう設計するか」の勝負でした。

辞書ベースの限界を先回りして見越し、embeddingで検索範囲を広げ、確信度で優先順位をつけ、レビューがデータを育てるループを作る——精度の追求は、その設計の上に乗るものだと捉え直すと、PoCの立て方そのものが変わってきます。

参考: ヒューマンインザループの負荷に関する日経の記事 / 参考書籍