PoC設計と業務プロセスへの組み込み

PoCで再現すべき範囲

PoCの目的は、全社展開したときに何が起きるかを小さく先取りすることです。したがって、モデルへの入力と出力だけを切り出した検証では不十分です。業務の前後——誰がデータを用意し、誰が結果を受け取り、おかしいと感じたときにどこへ連絡するか——まで含めて再現します。

• 入力の実物：整形済みのサンプルではなく、現場が実際に扱う雑多なファイル（スキャンPDF、旧フォーマット、記入漏れ）を含めます。
• 確認者の動線：出力をどの画面で、どれだけの時間をかけて確認するか。
• 例外の扱い：AIが答えられない、答えが怪しい場合の分岐先。
• ログの保存：入力、出力、確認結果、修正内容を後から追跡できる形で残す。
• コストの実測：1件あたりの推論コストと、確認にかかる人件費。

生成AIの評価は精度だけでは足りない

生成AIでは、正解率だけでなく、根拠の提示、再現性、応答時間、コスト、誤出力時の影響を評価します。分類タスクのように単一の正解がない業務では、「何をもって良い出力とするか」を評価者間で揃える作業自体が設計の一部になります。

特に「根拠の提示」は、精度そのものより運用可否を左右します。出典が示されていれば確認者は該当箇所だけを読めばよく、確認工数が大幅に下がります。逆に根拠のない出力は、正しくても全文を読み直す必要があり、省力化になりません。

RAGを使う場合の設計項目

RAGを利用する場合は、文書の更新頻度、アクセス権限、チャンク分割、検索評価、回答の引用を設計します。生成側のモデルを高性能なものに替えても、検索が必要な文書を拾えていなければ回答は改善しません。

検索側を先に評価する

RAGの品質問題の多くは検索段階で起きています。回答の良し悪しを見る前に、想定質問に対して正しい文書が上位に入っているか（再現率）を単独で測ってください。検索評価用の質問と正解文書のペアを50〜100件用意すれば、チャンク分割やクエリ書き換えの変更が改善なのか改悪なのかを判定できます。

権限を検索インデックスに引き継ぐ

社内文書を対象にする場合、元のファイルサーバーやSaaS上のアクセス権限を検索側でも再現する必要があります。権限を無視して全文書をインデックス化すると、人事情報や役員資料が一般社員の検索結果に引用されます。これは技術的な不具合ではなく設計の欠落であり、後から追加するのは大きな手戻りになります。

更新の反映を運用に組み込む

文書が改訂されたときに、インデックスがいつ更新されるかを決めます。旧版を引用した回答は、誤情報として扱われます。更新頻度の高い規程やマニュアルについては、回答に文書の版数と更新日を必ず添えるようにすると、確認者が判断できます。

エージェントを使う場合の権限分離

エージェントを利用する場合は、ツール実行の権限を最小化し、承認が必要な操作を明確に分離します。読み取りと書き込み、社内と社外、可逆と不可逆——この3つの軸で操作を分類し、不可逆かつ社外に影響する操作は必ず人間の承認を挟みます。

また、エージェントが実行できるツールの一覧は、業務ごとに最小構成で定義します。「便利だから全ツールを渡す」設計は、想定外の操作連鎖を招き、原因追跡も難しくなります。

PoCから限定運用への引き継ぎ

PoCの成果物は、動くプロトタイプだけではありません。次の段階に引き継ぐべきものを明示しておくと、限定運用の立ち上げが大幅に短縮されます。

1. 評価用データセット：質問と期待結果のペア。モデル更新やプロンプト変更のたびに回帰確認に使います。
2. プロンプト・検索条件の版管理：いつ、誰が、なぜ変更したかを含めて記録します。
3. 既知の失敗パターン一覧：PoC中に見つかった誤出力の類型。教育教材にもなります。
4. 運用コストの実測値：1件あたりの推論費用と確認工数。
5. 未解決の課題：PoCの範囲外にした項目と、その理由。