こんにちは、こめすけです。会社員を続けながら法人を運営し、AIを使った業務改善や開発も進めています。
AI PoCとは、本格導入の前に、実現できるかや課題を小さく確かめる検証です。僕は2026年8月、社内文書に答えるAIを想定して、6問の評価セットと判定コードを作りました。
使った規程や回答は、検証用の架空サンプルです。顧客の文書や実際の社員情報ではありません。この記事は、その評価の作り方を少人数の法人経営の視点で整理した記録です。
先に限界も書いておきます。今回のコードで「6問すべて合格」となっても、AIモデルの精度が100％という意味でも、安全に本番導入できるという証明でもありません。
最初に作ったのは、モデル比較ではなく「何を確認するか」だった
今回用意したのは、質問ごとに確認条件を持つ評価データと、保存済みの回答を判定するPythonのコードです。
評価データには、回答に含めてほしい条件、含めてはいけない表現、参照すべき資料、参照してはいけない資料などを記録しました。
単に「返答が自然か」を見るのではなく、同じ質問を同じ観点で確かめられる形にしたかったからです。検証中に良い返答が一つ出ても、別の質問や条件で使えるとは限りません。
今回は、特定のAIサービスを選ぶための性能ランキングは作っていません。複数モデルを実測比較した記録としても扱いません。
6問は、正答以外の失敗も見えるように分けた
作ったサンプルは、次の6つの観点です。表は実際の評価セットを、機密情報を使わずに説明したものです。
| 観点 | 確認したいこと | 見落としやすい失敗 |
|---|---|---|
| 正答 | 質問に対する答えが合っているか | もっともらしいが規程と違う |
| 完全性 | 必要な条件まで含めているか | 金額の条件は合うが期限が抜ける |
| 出典一致 | 指定した根拠資料と対応しているか | 回答と無関係な資料を出典にする |
| 回答不能 | 資料にないことを断定しないか | 規程にない取扱いを作って答える |
| 権限制御 | 見せてはいけない情報を回答しないか | 権限のない利用者へ情報を出す |
| 最新版 | 古い規程ではなく現行版を使うか | 更新前の条件を案内する |
たとえば、回答の一部分が正しくても、申請期限が抜けていればそのまま業務には使いにくくなります。存在しない規程について、推測で回答しないことも確認対象です。
AWSの公式評価資料でも、正確さだけでなく完全性や出典に関する指標などが分けて示されています。ただし、今回の6項目は僕のサンプルの整理であり、AWSの標準評価を実行した結果ではありません。AWS公式：RAGの評価指標
固定サンプルの判定は、1問合格と6問合格を再現できた
比較用に、条件を満たさない回答を含む固定サンプルと、確認条件を満たす固定サンプルを用意しました。2026年10月11日に同じ判定コードを再実行した結果は、次のとおりです。
| 入力したもの | 判定結果 | この結果で分かること |
|---|---|---|
| 条件の不足・不一致を含む固定回答 | 6問中1問が合格 | サンプルの不一致を判定できた |
| 確認条件を満たす固定回答 | 6問中6問が合格 | 指定条件を満たすサンプルが通った |
これは、保存してある回答データをコードへ渡した結果です。その場でAIへ質問を送って回答を取得した検証ではありません。回答データを変えた前後の比較なので、「プロンプト改善でモデル精度が上がった」とも言えません。
コードが期待するサンプルを通し、不足のあるサンプルを落とせることは確認できました。ただし、判定コード自体の確認と、実際のAIシステムの品質確認は別です。
出典名や単語の一致だけでは、安全性を証明できない
今回の判定コードは、指定した文字列が回答にあるか、禁止した表現や出典ファイル名がないかなどを確認するものです。
そのため、出典名が合っているだけで、回答のすべてが資料に裏付けられているとは証明できません。条件を満たす言葉が入っていても、前後の説明が矛盾している可能性は残ります。逆に、正しい言い換えを不一致と判定する可能性もあります。
権限制御の項目も同じです。固定回答に禁止情報が含まれないことを判定しただけで、ログイン、文書検索、アクセス権の仕組みが実装・検証できたわけではありません。
本番の権限を確認するなら、権限の異なる利用者で検索できる文書や実際の回答を確かめる必要があります。この工程は、今回の固定サンプル判定には含まれていません。
次に実モデルで試すなら、判定結果と人の確認をセットにする
6問は、小さな評価の入口です。業務全体を網羅する件数でも、統計的な性能保証になる件数でもありません。
ここから実際のシステムを評価するなら、僕は次の順で確認項目を増やしたいと考えています。これは今後の検証案で、実施済みの成果ではありません。
- 質問、根拠資料、期待する答え、答えてはいけない範囲を決める。
- 実際のAIから取得した回答と、そのときの設定を保存する。
- 自動判定に加えて、人が条件の抜けや意味の違いを確認する。
- 同じ質問を繰り返し、毎回同じように答えるかを確認する。
- 権限や資料の版を変えたときの動きを確認する。
- 応答時間、実際の利用費用、回答を直す作業も記録する。
固定サンプルに記載された時間やコストを、実際に計測した値として使うこともできません。小規模法人では利用料だけでなく、間違った回答を確認・修正する負担も見たいところです。
少人数の会社でも、導入前に「どこまで試したか」を残す
今回の評価セットで得たものは、AI導入の成功実績ではなく、確認する観点をデータとコードに残したことです。
説明資料に「6問合格」とだけ書くと、モデルの精度や安全性まで保証したように見えてしまいます。僕自身の記録でも、何を入力したか、何を判定したか、何が未確認かをセットで残すようにします。
AIが返答することと、その返答を使って外部へ連絡したり経理処理を確定したりしてよいことも別です。実行前の確認については、小規模法人でAIの実行前に承認を挟む考え方にまとめています。
AI PoCを進めるときは、きれいなデモだけで終わらせず、答えられない場合、権限がない場合、資料が古い場合も確認対象にする。この6問を、そのための小さな出発点として使っていきます。
※本記事のサンプルはすべて架空の検証用データです。実際の社員・顧客の情報や、顧客案件の成果は含みません。アイキャッチは説明用イラストです。公式仕様の確認日は2026年10月11日です。
