タグ: PoC

  • ローカルLLMをいきなり本番導入しない|PC・データ・試作範囲の決め方

    ローカルLLMをいきなり本番導入しない|PC・データ・試作範囲の決め方

    「社内資料をAIに読ませたい。でも、クラウドAIにそのまま送るのは不安」

    そう考えて、ローカルLLMや社内向けRAGを検討する小規模事業者は増えています。

    ローカルLLMは、社内PCや管理された環境でAIを動かす選択肢です。クラウドAIに出しにくい情報を扱う検討材料になりますが、「ローカルなら安全」「PCを買えばすぐ業務で使える」と考えると失敗しやすくなります。

    実際には、次のような問題が起きます。

    • どのPCで動かすべきか決められない
    • 社内資料を全部入れようとして整理が止まる
    • 回答が遅く、実務で使われない
    • 何をもって成功とするか分からない
    • RAGに入れた資料が古くなっていく
    • 試作と本番運用の線引きが曖昧になる

    ローカルLLM導入で先に決めるべきなのは、モデル名や高価なPCだけではありません。

    まずは、どの業務で、どの資料を使い、誰が質問し、どの程度の回答なら役に立つのかを小さく試すことです。

    この記事では、小規模事業者や少人数チーム向けに、ローカルLLMをいきなり本番導入しないための試作範囲、PC環境、対象データ、確認項目を整理します。

    ローカルLLMは「安全そう」だけで選ばない

    ローカルLLMを検討する理由として多いのは、情報管理への不安です。

    • 顧客情報を外部サービスへ入れたくない
    • 社内マニュアルや価格表をクラウドAIへ送れない
    • 契約書、提案資料、問い合わせ履歴を扱いたい
    • 業務上、外部送信を避けたい資料がある

    この不安自体は自然です。

    ただし、ローカルLLMにすれば自動的に安全になるわけではありません。社内PCに置く場合でも、誰が使えるのか、どの資料を入れるのか、ログを残すのか、バックアップはどうするのかを決める必要があります。

    ローカルで動くことと、業務として安全に運用できることは別です。

    最初に決めるのはPCより試す業務

    ローカルLLMの相談では、最初に「どのPCが必要ですか」と聞かれることがあります。

    もちろんPC環境は重要です。回答速度、扱えるモデル、同時利用、保存容量によって必要な構成は変わります。

    ただ、PC選びの前に、まず試す業務を決めた方が失敗しにくくなります。

    試す業務確認したいこと最初の判断材料
    社内マニュアル検索必要な回答が資料から出せるか原本文書、質問例、回答精度
    問い合わせ回答の下書き誤返信を防げるか過去回答、禁止表現、確認者
    議事録の要約要点とタスクを拾えるか音声文字起こし、担当者、期限
    商品説明の整理表記ゆれを減らせるか商品資料、用語集、更新ルール
    社内規程の確認根拠を示せるか規程PDF、更新日、参照箇所

    同じローカルLLMでも、文章作成をしたいのか、資料検索をしたいのか、回答下書きをしたいのかで設計は変わります。

    「とりあえず全部できる社内AI」を目指すより、最初は1つの業務に絞った方が検証しやすくなります。

    本番データを入れる前に試作用データを作る

    ローカルLLMやRAGの試作では、いきなり本番データを全部入れない方が安全です。

    最初は、次のような試作用データを用意します。

    • 公開しても問題ない資料
    • 個人情報を除いたサンプル文書
    • 古い資料ではなく、現在も使っている代表的な文書
    • よく聞かれる質問を10個から20個
    • 正解として期待する回答メモ
    • 答えてはいけない質問の例

    特に重要なのは、質問例です。

    資料を入れただけでは、業務で役に立つか判断できません。実際に聞かれそうな質問を先に用意し、回答が合っているか、根拠が分かるか、言い切りすぎていないかを確認します。

    RAGを使う場合は、原本文書と回答の対応も見ます。どの資料のどの部分を根拠にしているのかが分からないと、実務では確認しづらくなります。

    PC環境は「誰が、どこで、どれくらい使うか」で変わる

    ローカルLLM用のPC環境は、用途によって変わります。

    確認したいのは、単純なスペック表だけではありません。

    • 使う人は1人か、複数人か
    • 同時に質問する場面があるか
    • 長いPDFや大量の資料を扱うか
    • 回答速度をどの程度求めるか
    • 社内ネットワーク内で使うか
    • 外出先からも使うか
    • バックアップや再構築を誰が見るか

    自分だけの検証なら、手元のPCで小さく試せる場合もあります。

    一方で、複数人が業務で使うなら、設置場所、アクセス方法、更新担当、停止時の対応まで考える必要があります。

    「動いた」だけでは本番運用とは言えません。誰かが使いたいときに使えるか、古い資料を答え続けないか、壊れたときに戻せるかまで見る必要があります。

    RAGにするなら更新ルールも一緒に決める

    社内資料をAI検索したい場合、ローカルLLM単体ではなくRAGを組み合わせることがあります。

    RAGでは、社内文書やPDFを検索対象にして、質問に合う情報を参照しながら回答します。

    このときに見落とされやすいのが、更新ルールです。

    • 原本文書はどこに置くか
    • 差し替えた資料を誰が反映するか
    • 古い資料を検索対象から外すか
    • 権限の違う資料を混ぜないか
    • 回答テストをいつ見直すか
    • バックアップから復旧できるか

    RAGは、入れた瞬間だけ正しくても十分ではありません。

    料金表、社内ルール、商品説明、対応手順のように変わる資料を扱うなら、更新日と担当者を決めておく必要があります。

    ローカルLLM導入前の試作では、最初から完璧な運用を作る必要はありません。ただし、「資料が変わったらどう反映するか」だけは早めに決めておくと、後で作り直しになりにくくなります。

    成功条件を先に決めておく

    ローカルLLMの試作は、触っているだけだと終わりどころが分かりません。

    そのため、最初に成功条件を決めておきます。

    たとえば、次のような条件です。

    • 代表的な質問20個のうち、15個以上で実務確認に使える回答が出る
    • 回答に参照元の資料名が出る
    • 個人情報を含む資料を使わずに検証できる
    • 1回の回答待ち時間が業務上許容できる
    • 担当者が回答を確認し、修正できる
    • 資料を追加したときの反映手順が分かる
    • 本番導入しない場合の判断理由も残せる

    成功条件は、AIの性能だけで決めない方が現実的です。

    回答品質、確認しやすさ、運用負担、費用、担当者の手間を合わせて見ます。

    ローカルLLMが向かない場合もある

    試作の結果、ローカルLLMが最適ではないと分かることもあります。

    たとえば、次のような場合です。

    • そもそも資料が整理されていない
    • 質問よりも定型フォーム化した方が早い
    • 回答速度が業務に合わない
    • 担当者が確認する時間を取れない
    • 既存の検索やFAQページで十分な範囲だった
    • クラウドAIとマスキング運用の方が現実的だった

    これは失敗ではありません。

    小さく試す目的は、「ローカルLLMで本番化すること」だけではなく、AI、RAG、既存検索、小型ツール化のどれが現実的かを判断することです。

    導入前チェックリスト

    ローカルLLMを試す前に、次の項目を確認します。

    • 試す業務を1つに絞ったか
    • 対象資料を限定したか
    • 個人情報や機密情報の扱いを決めたか
    • 質問例と期待回答を用意したか
    • PC環境と利用人数を整理したか
    • 回答速度の許容範囲を決めたか
    • RAG化する資料の更新ルールを決めたか
    • 回答の確認者を決めたか
    • 本番導入する条件と、見送る条件を決めたか

    このチェックを先に行うと、「PCを買ったけれど使い道が曖昧」「資料を入れたけれど正しいか分からない」という状態を避けやすくなります。

    まとめ

    ローカルLLMは、クラウドAIに出しにくい資料を扱うための有力な選択肢になります。

    ただし、いきなり本番導入するのではなく、試す業務、対象データ、PC環境、質問例、成功条件を先に決めることが重要です。

    ローカルで動くことと、業務で使えることは同じではありません。

    まずは小さな試作で、回答品質、速度、運用負担、更新ルールを確認します。そのうえで、ローカルLLM、RAG、クラウドAI、既存検索、小型ツール化のどれが現実的かを判断します。

    CTA

    YOSHIO.devでは、ローカルLLM・RAG環境構築、社内資料のAI検索、業務自動化、小型ツール開発の相談ができます。

    「クラウドAIに出しにくい資料がある」「ローカルLLMで何を試せばよいか分からない」「PC環境やRAG化の前に、試作範囲を整理したい」という段階でも、今の資料や業務フローに合わせて小さく設計できます。

    まずは、試したい業務、扱いたい資料、使う人数、外部に出したくない情報の範囲を整理してご相談ください。

    関連リンク

    FAQ

    ローカルLLMなら社内情報を安心して使えますか?

    ローカル環境で動かすことは情報管理の選択肢になりますが、それだけで安全とは言えません。誰が使えるか、どの資料を入れるか、ログやバックアップをどう扱うかを決める必要があります。

    ローカルLLM導入では先にPCを選ぶべきですか?

    PC環境は重要ですが、先に試す業務、対象資料、利用人数、回答速度の期待値を整理した方が選びやすくなります。用途が曖昧なままPCだけ決めると、過不足が出やすくなります。

    RAGの試作では何を準備すればよいですか?

    代表的な原本文書、質問例、期待する回答、答えてはいけない質問、資料の更新ルールを用意します。資料を入れるだけでなく、実際の質問に対して根拠を確認できるかを見ることが大切です。

    小規模事業者でもローカルLLMを試せますか?

    試す範囲を1つの業務に絞れば、小さく検証できます。最初から全社向けの社内AIを目指すのではなく、マニュアル検索、問い合わせ下書き、議事録要約など、効果を確認しやすい範囲から始めるのがおすすめです。

    試作してローカルLLMが合わないと分かった場合は無駄ですか?

    無駄ではありません。試作の目的は、ローカルLLM、RAG、クラウドAI、既存検索、小型ツール化のどれが現実的かを判断することです。向かない理由が分かるだけでも、次の設計を絞りやすくなります。

  • AI導入の稟議で止まらないために|目的・対象データ・成功条件を1枚にまとめる方法

    AI導入の稟議で止まらないために|目的・対象データ・成功条件を1枚にまとめる方法

    AIを業務に使いたい。社内文書をRAGで検索したい。問い合わせ返信をAIで下書きしたい。Excel作業や転記作業を自動化したい。

    そう思っても、社内説明や稟議の段階で止まることがあります。

    「結局、何に使うのか」 「どのデータを扱うのか」 「費用に見合う効果をどう判断するのか」 「情報漏えいは大丈夫なのか」 「試してダメだったら、どこでやめるのか」

    このあたりが曖昧なままだと、AI導入の話は進みにくくなります。

    AI導入の稟議で大事なのは、AIで何ができるかを広く説明することではありません。どの業務を、どの範囲で、小さく試し、何をもって続行判断するかを具体的に書くことです。

    この記事では、小規模事業者や少人数チーム向けに、ローカルLLM、RAG、業務自動化、社内AIチャットを検討するときの「1枚実証計画書」の作り方を整理します。

    AI導入の話が止まる理由

    AI導入の提案が止まる原因は、技術への期待が足りないことではありません。

    むしろ、期待が大きすぎて範囲がぼやけることが原因になりやすいです。

    • 何の業務を楽にしたいのか分からない
    • 対象データが決まっていない
    • 利用者が誰なのか曖昧
    • 成功条件が「便利になったら」になっている
    • 費用の上限や段階が決まっていない
    • セキュリティや個人情報の扱いが説明できない
    • 本導入するかどうかの判断基準がない

    この状態で「AIを導入したい」と言っても、承認する側は判断できません。

    社内AIチャット、RAG、問い合わせ対応AI、業務自動化ツールは、どれも使い方次第で効果が変わります。だからこそ、最初から本導入を前提にするのではなく、小さな実証計画として切り出す方が進めやすくなります。

    稟議前に作るのは「AI導入計画」ではなく「実証計画」

    最初から立派なAI導入計画を作ろうとすると、話が大きくなります。

    全社展開、複数部署対応、既存システム連携、権限管理、ログ管理、教育、保守。どれも大事ですが、最初の稟議で全部を決めようとすると重くなります。

    小規模に始めるなら、まず作るべきなのは「実証計画」です。

    実証計画では、次のように範囲を限定します。

    • 対象業務を1つに絞る
    • 利用者を数名に絞る
    • 対象データを限定する
    • 検証期間を短くする
    • 成功条件と撤退条件を決める
    • 本導入判断の材料を残す

    たとえば「社内文書を全部AI検索できるようにする」ではなく、「営業資料とFAQだけを対象に、5名で2週間試し、よくある質問20件に答えられるか確認する」と書きます。

    この方が、費用もリスクも判断しやすくなります。

    1枚計画書に入れる項目

    AI導入の稟議前に作る1枚計画書には、次の項目を入れると説明しやすくなります。

    項目 書くこと 例
    目的 何を改善したいか 社内資料を探す時間を減らす
    対象業務 どの業務で試すか 問い合わせ返信前の過去資料確認
    利用者 誰が使うか 営業担当2名、管理担当1名
    対象データ 何をAIに参照させるか FAQ、提案書テンプレート、業務マニュアル
    対象外 今回やらないこと 顧客個人情報、契約判断、全社展開
    検証期間 いつまで試すか 2週間、または20件の質問まで
    成功条件 続ける判断材料 回答案の確認時間が半分になる
    撤退条件 やめる判断材料 根拠資料の誤りが多く、修正工数が増える
    費用範囲 初期費用、月額、外注範囲 小型PoCのみ、追加連携は別見積もり
    リスク対策 情報管理、確認ルール 個人情報は入れない、社外送信前に人が確認
    次アクション 承認後にやること 対象資料の棚卸し、質問例の作成

    この表を作る目的は、完璧な計画を作ることではありません。

    承認する人が「何を試すのか」「どこまでなら許容できるのか」「どうなれば次に進むのか」を判断できる状態にすることです。

    目的は「AIを入れる」ではなく業務の困りごとで書く

    稟議や社内説明で避けたいのは、「AIを使いたい」が目的になってしまうことです。

    AIは手段です。目的は、業務上の困りごとで書きます。

    悪い例:

    • AIチャットを導入する
    • RAGを構築する
    • 問い合わせ対応をAI化する

    よい例:

    • 社内マニュアルを探す時間を減らす
    • 過去の提案書を探しやすくする
    • 問い合わせ返信前の確認漏れを減らす
    • PDFやExcelから必要情報を転記する時間を減らす
    • 担当者ごとに違う回答をそろえる

    同じAI導入でも、目的が変わると必要な構成も変わります。

    社内文書検索なら、対象資料、権限、根拠表示、更新ルールが重要です。問い合わせ返信なら、個人情報の扱い、返信前の人間確認、テンプレート、誤返信防止が重要です。Excel転記なら、入力形式、例外処理、ログ、手動修正が重要になります。

    まずは「AIで何をするか」ではなく、「どの作業のどの負担を減らしたいか」から書きます。

    対象データを先に決める

    AI導入で詰まりやすいのが、対象データです。

    ローカルLLMやRAGを使う場合でも、クラウドAIを使う場合でも、何を読み込ませるのか、何を入れないのかを決めないと話が進みません。

    最初の実証では、対象データを広げすぎない方が安全です。

    対象データ 最初に向いている例 注意点
    社内FAQ よく聞かれる質問と回答 古い回答を混ぜない
    業務マニュアル 手順が決まっている作業 最新版を指定する
    提案書テンプレート 構成や見出しの参考 顧客名や金額を除外する
    問い合わせ文面 分類や返信下書き 個人情報の扱いを決める
    Excel・CSV 転記や集計の元データ 列名、例外、上書き防止を決める

    最初から全社ファイルを対象にすると、権限、重複、古い資料、個人情報、更新ルールが一気に問題になります。

    まずは、全員が見ても問題ない資料、または検証用に整理した資料だけで試す方が現実的です。

    成功条件は数字と行動で決める

    AI導入の成功条件を「便利になったら」にすると、続けるかどうかを判断できません。

    小さな実証では、数字と行動で成功条件を決めます。

    例:

    検証テーマ 成功条件の例
    社内FAQ検索 20問中15問以上で根拠資料を確認できる
    問い合わせ返信下書き 返信前の確認項目を毎回3つ以上抽出できる
    提案書作成補助 過去資料探しの時間が30分から10分に減る
    Excel転記自動化 50件中45件以上を手修正なしで転記できる
    RAG評価 回答不能な質問で無理に作り話をしない

    ここで大事なのは、AIの回答を正解にすることではありません。

    実務で使うために、人が確認しやすくなるか、探す時間が減るか、ミスを見つけやすくなるかを見ます。

    成功条件と同時に、撤退条件も決めておくと説明しやすくなります。

    • 根拠資料の誤りが多い
    • 個人情報の除外に手間がかかりすぎる
    • 手作業より確認時間が増える
    • 利用者が業務中に使う場面を見つけられない
    • 対象データの更新ルールを維持できない

    撤退条件があると、承認する側は「試したら終わりなく費用が増えるのでは」という不安を持ちにくくなります。

    費用は段階に分けて書く

    AI導入の費用は、機能を増やすほど大きくなります。

    だからこそ、稟議前の説明では、最初から全部込みにせず段階を分けます。

    段階 目的 含める範囲
    相談・整理 実証テーマを決める 業務整理、対象データ確認、リスク整理
    小型PoC 使えるか試す 限定データ、簡易画面、質問例、ログ確認
    業務導線化 日常業務に置く フォーム連携、権限、通知、運用手順
    本導入 継続利用する 保守、更新ルール、教育、改善サイクル

    このように分けると、「いきなり大きなAI導入費用が必要」という見え方を避けられます。

    小規模事業者の場合、最初は相談・整理と小型PoCだけで十分なこともあります。そこで効果が見えたら、業務導線化や本導入を検討します。

    書き方の例

    1枚計画書は、次のように書くと具体的です。

    例1: 社内FAQをRAGで検索する

    • 目的: 社内マニュアルやFAQを探す時間を減らす
    • 対象業務: 新人スタッフからのよくある質問対応
    • 利用者: 管理担当2名、新人スタッフ3名
    • 対象データ: 最新FAQ、業務マニュアル、申請手順
    • 対象外: 顧客情報、契約判断、給与や人事情報
    • 検証期間: 2週間、または質問30件
    • 成功条件: よくある質問の7割で根拠資料を確認できる
    • 撤退条件: 古い資料が混ざり、回答確認に時間がかかる
    • 次アクション: 対象資料の棚卸し、質問例の作成

    例2: 問い合わせ返信をAIで下書きする

    • 目的: 初回返信前の確認漏れを減らす
    • 対象業務: LPから来た制作相談の一次整理
    • 利用者: 代表者、受付担当
    • 対象データ: 問い合わせ本文、サービス説明、返信テンプレート
    • 対象外: 自動送信、金額確定、契約判断
    • 検証期間: 問い合わせ20件
    • 成功条件: 確認すべき項目と返信下書きが分かれて出る
    • 撤退条件: 誤った約束や過剰な表現が多い
    • 次アクション: フォーム項目と返信テンプレートの確認

    例3: Excel転記を小型ツール化する

    • 目的: PDFやCSVからの手入力を減らす
    • 対象業務: 見積書・請求書情報の一覧化
    • 利用者: 経理担当1名
    • 対象データ: 検証用PDF、CSV、既存の管理表
    • 対象外: 会計システムへの自動登録、最終承認
    • 検証期間: サンプル50件
    • 成功条件: 主要項目の転記ミスが大きく減る
    • 撤退条件: 例外処理が多く、手修正の方が早い
    • 次アクション: サンプルファイルの収集、列名の整理

    外注前に決めておくと相談が早いこと

    YOSHIO.devのような外部パートナーに相談する場合も、最初から技術仕様を完璧に決める必要はありません。

    ただし、次の項目があると、提案や見積もりの精度が上がります。

    • 解決したい業務
    • 現在の作業手順
    • 使っている資料やファイル形式
    • AIに入れてよい情報、入れたくない情報
    • 利用者数
    • 最初に試したい範囲
    • 成功条件
    • 予算感と希望時期
    • 連携したい既存ツール

    逆に、これらがないまま「AIで何かできませんか」と相談すると、提案の幅が広がりすぎます。

    まずは1枚計画書で、目的、対象データ、成功条件を決める。そこから、小さく試す方法を相談する。この順番にすると、AI導入の話が現実的になります。

    まとめ

    AI導入の稟議や社内説明で止まる原因は、AIに詳しくないことだけではありません。

    多くの場合、目的、対象業務、対象データ、成功条件、撤退条件が曖昧なまま話していることが原因です。

    最初から全社導入を目指す必要はありません。

    まずは、1つの業務、限られたデータ、少人数の利用者、短い検証期間で実証計画を作ります。何ができれば続けるのか、どこでやめるのかを決めておけば、承認する側も判断しやすくなります。

    ローカルLLM、RAG、問い合わせ返信AI、Excel転記、小型ツール化は、どれも「小さく試す範囲」を決めるところから始められます。

    関連リンク

    CTA

    AI導入やRAG、業務自動化を検討しているものの、社内説明や稟議で何を整理すればよいか迷っている場合は、まず「目的」「対象データ」「成功条件」を1枚にまとめるところから始めるのがおすすめです。

    YOSHIO.devでは、ローカルLLM・RAG環境構築、社内AIチャットの小型PoC、業務自動化、小型ツール開発について、現在の業務や資料状況に合わせた実証範囲の整理から相談できます。

    次のような段階で相談できます。

    • AI導入の稟議前に、何を1枚にまとめるべきか整理したい
    • RAGや社内AIチャットのPoC範囲を決めたい
    • 社内資料や問い合わせ対応にAIを使えるか小さく試したい
    • 情報管理や対象外の範囲を含めて、安全に始めたい
    • 本導入前に、成功条件と撤退条件を決めたい

    FAQ

    AI導入の稟議では、技術構成まで詳しく書くべきですか?

    最初の段階では、細かい技術構成よりも、目的、対象業務、対象データ、利用者、成功条件を明確にする方が重要です。ローカルLLM、RAG、クラウドAI、既存ツール連携などの構成は、扱う情報や検証範囲が見えてから決める方が現実的です。

    PoCと本導入は何が違いますか?

    PoCは、限定した業務、データ、利用者で「実務に使える可能性があるか」を試す段階です。本導入は、継続利用を前提に、権限、ログ、保守、教育、更新ルールまで含めて運用する段階です。最初から本導入に進むより、PoCで成功条件を確認する方が失敗を減らしやすくなります。

    予算が決まっていなくても相談できますか?

    相談できます。ただし、予算が完全に未定の場合でも「まずは小型PoCだけ」「既存資料の整理から」「フォーム連携は次段階」など、段階を分けると話が進めやすくなります。最初の相談では、上限金額よりも、どこまでを最初に試したいかを整理することが大切です。

    社内データをAIに入れるのが不安な場合はどうすればよいですか?

    まず、AIに入れてよい情報と入れない情報を分けます。顧客個人情報、契約情報、機密性の高い資料を最初から対象にしない方法もあります。必要に応じて、ローカル環境、匿名化、マスキング、権限設計、ログ確認を含めて検討します。

    実証計画書は誰が作るべきですか?

    業務の困りごとを知っている人と、実装や運用を考える人が一緒に作るのが理想です。現場だけで作ると技術範囲が曖昧になり、開発側だけで作ると実務の成功条件がずれやすくなります。まず現場の作業手順を書き出し、そこに外部パートナーや開発担当が実証範囲を重ねると整理しやすくなります。

  • RAGの精度をどう評価する?社内AIチャットの質問テスト集の作り方

    RAGの精度をどう評価する?社内AIチャットの質問テスト集の作り方

    RAGや社内AIチャットの精度を評価するなら、担当者が思いついた質問を数回試すだけでは不十分です。

    まず、実際の業務を代表する20〜30問程度の質問を用意します。各質問に「回答へ必ず含めたい要点」「参照すべき資料」「答えてはいけない内容」「合格条件」を付け、文書やモデルを変更した後も同じ条件で繰り返します。

    重要なのは、AIの文章が自然かどうかだけで判断しないことです。

    必要な資料を検索できたか。資料に書かれた範囲で答えたか。重要な条件を落としていないか。資料に答えがないときに、推測せず確認を促せたか。これらを分けて見ると、RAGのどこを直すべきか判断しやすくなります。

    この記事では、小規模事業者や少人数チーム向けに、RAG・社内AIチャットの評価に使う質問テスト集の作り方、採点項目、質問の種類、更新後の再テスト方法を整理します。

    すでに回答精度が低く、原因の切り分けから始めたい場合は、RAGの回答精度が低い時に見るべき原因も参考になります。

    結論:RAGの評価は4項目に分ける

    RAGの回答を一つの点数だけで評価すると、検索に失敗したのか、検索結果は正しいのに回答で間違えたのかが分かりません。

    最初は、次の4項目に分けると実務で扱いやすくなります。

    評価項目確認すること失敗時に見る場所
    検索必要な資料や該当箇所が取得されているか文書、分割方法、検索語、絞り込み
    回答質問に直接答え、必要な要点を含んでいるかプロンプト、モデル、回答形式
    根拠回答内容が取得した資料に基づいているか参照情報、生成指示、引用表示
    答えない判断資料にないことを推測せず、確認を促せるか対象範囲、拒否条件、案内文

    たとえば、就業規則の申請期限を聞いたとき、正しい規則ファイルが検索できていなければ検索側の問題です。

    正しい箇所が検索できているのに期限を間違えたなら、回答生成側の問題です。

    期限は合っていても、対象者や例外条件を落としていれば回答の完全性に問題があります。

    資料に制度が書かれていないのに、一般論から日数を作って答えたなら「答えない判断」の問題です。

    この分け方をしておくと、「RAGの精度が悪い」という曖昧な感想を、修正できる作業へ変えられます。

    デモでうまく答えた質問だけでは判断できない

    RAGのPoCでは、作った本人が資料名や表現を知っています。

    そのため、「経費精算マニュアルの提出期限を教えて」のように、文書の見出しと同じ言葉で質問しがちです。この質問に答えられても、実際の利用者が「領収書はいつまでに出せばいい?」と聞いたときに同じ資料へたどり着けるとは限りません。

    また、答えが一つの段落にまとまった簡単な質問だけを試すと、次の失敗が見えません。

    • 言い換えた質問で検索できない
    • 複数の資料を比べないと答えられない
    • 古い規定と新しい規定を取り違える
    • 対象者や条件によって答えが変わる
    • 資料に答えがないのに、それらしい内容を作る
    • 閲覧できない資料の内容を回答へ混ぜる

    良い質問テスト集は、AIが答えやすい質問の一覧ではありません。実際の利用場面で起きる言い換え、曖昧さ、例外、情報不足まで含む確認表です。

    質問テスト集に入れる項目

    最初から専用の評価システムを作る必要はありません。スプレッドシートでも、次の項目があれば始められます。

    項目記入内容
    質問IDQ001、Q002など変更しない識別子
    質問文利用者が実際に入力しそうな表現
    質問タイプ単純検索、言い換え、比較、対象外など
    期待する要点回答に必ず含めたい事実や条件
    参照すべき資料正解の根拠になる文書名、版、該当箇所
    禁止事項推測してはいけない内容、混ぜてはいけない旧情報
    期待する動作回答、追加質問、回答不可、担当窓口案内など
    検索結果必要な資料が上位に取得されたか
    回答結果必須要点、誤り、抜け、不要な断定
    合否合格、条件付き合格、不合格
    実行条件実行日、モデル、プロンプト、文書版、設定
    修正メモ失敗原因と次に変更する場所

    特に重要なのは、質問文だけでなく「参照すべき資料」と「期待する要点」を先に決めることです。

    回答を見てから正解を決めると、自然な文章に引っ張られて採点が甘くなります。

    正解文は一字一句決めなくてよい

    生成AIの回答は、同じ内容でも文章表現が変わります。

    そのため、長い模範回答との完全一致だけで採点すると、内容は正しいのに言い回しが違う回答を不合格にしてしまいます。

    実務では、次の3つを分けて定義すると採点しやすくなります。

    1. 必ず含めたい要点

    質問に答えるために欠かせない事実です。

    たとえば「経費精算はいつまで?」という質問なら、申請期限だけでなく、締め日、対象となる費用、例外申請の有無が重要な場合があります。

    要点は短い箇条書きにします。

    • 利用日の翌月5日まで
    • 原本提出が必要
    • 期限を過ぎた場合は上長確認

    2. 含めてはいけない内容

    旧版の期限、別部署だけのルール、一般的な会社の慣習など、混ざると危険な内容を決めます。

    「旧版の翌月10日を案内しない」「承認されたと断定しない」のように書きます。

    3. 許容できる表現差

    箇条書きか文章か、敬語の違い、同じ意味の言い換えなど、業務上問題のない差は許容します。

    評価対象は文章の見た目ではなく、必要な情報が正しく、安全に伝わったかです。

    質問は7種類を混ぜる

    質問テスト集が簡単な事実確認だけに偏ると、実際の利用時の弱点が見えません。

    次の7種類を混ぜます。

    1. 一つの資料で答えられる基本質問

    最も単純な確認です。

    例:

    • 交通費精算の提出期限はいつですか?
    • 見積書の承認者は誰ですか?
    • 休暇申請はどのフォームから行いますか?

    基本質問で失敗する場合は、文書が登録されているか、検索対象になっているか、見出しや表が正しく取り込まれているかを確認します。

    2. 利用者の言い換え質問

    文書に書かれた正式名称を使わない質問です。

    例:

    • 立て替えたお金は何日までに出せばいい?
    • お客さんに出す金額は誰に見てもらう?
    • 明日休みたいときはどこから申請する?

    社内では、略語、口語、古い呼び方、部署独自の言い方が使われます。実際の質問ログがある場合は、個人情報を除いたうえで表現の参考にします。

    3. 複数資料を確認する質問

    一つの文書だけでは答えが完成しない質問です。

    たとえば、出張申請の手順は出張規程、申請フォーム、経費精算マニュアルに分かれていることがあります。

    「大阪へ2泊の出張をするとき、事前申請から精算まで何が必要?」のような質問で、必要な資料を複数取得できるか確認します。

    ただし、最初のPoCで複数資料の統合が必須でないなら、無理に難問を増やす必要はありません。実際の利用目的に必要な範囲で入れます。

    4. 条件によって答えが変わる質問

    部署、雇用形態、金額、契約区分などによって答えが変わる質問です。

    例:

    • 10万円を超える発注は誰の承認が必要ですか?
    • 業務委託でもこの申請フォームを使いますか?
    • 営業部と制作部で精算期限は同じですか?

    条件が不足している場合は、勝手に一つへ決めず、「金額はいくらですか」「所属部署を確認してください」と追加質問できるかも評価します。

    5. 最新版を選ぶ質問

    文書更新後に、旧版ではなく現行版を使えるか確認します。

    改定前後で変わった期限、申請先、料金、担当窓口などを質問します。

    文書の追加・差し替え・削除ルールについては、RAGが古い資料を答え続けるのを防ぐ更新設計で詳しく整理しています。

    6. 資料に答えがない質問

    RAGの安全性を見るうえで重要な質問です。

    社内資料に書かれていない将来の方針、未決定の料金、個別案件の判断などを質問し、推測で埋めないことを確認します。

    合格例は、「登録資料では確認できません」「担当者へ確認してください」「判断に必要な条件が不足しています」のような応答です。

    流暢でも、資料にない答えを作れば不合格です。

    7. 権限外・対象外の質問

    利用者が閲覧できない人事資料、顧客別見積もり、契約情報などを質問します。

    検索結果にも回答にも権限外の内容が出ないことを確認します。

    権限テストは、回答文だけでなく取得された文書一覧も確認します。最終回答で隠れていても、システム内部で権限外の文書を取得していれば設計上の問題が残ります。

    アクセス制御の考え方は、社内AI検索で見えてはいけない資料を出さないためのRAG権限設計も参考になります。

    最初の20問をどう配分するか

    小規模なPoCなら、最初から数百問を作るより、利用頻度と失敗時の影響が大きい20問程度から始める方が運用しやすくなります。

    配分例は次のとおりです。

    質問タイプ問数例目的
    基本質問5問主要資料を検索して答えられるか
    言い換え質問4問実際の聞き方でも検索できるか
    複数資料3問情報を組み合わせられるか
    条件分岐・曖昧3問条件確認や追加質問ができるか
    最新版2問旧情報を混ぜないか
    答えなし2問推測を抑えられるか
    権限外1問取得と回答を制限できるか

    これは固定の正解ではありません。

    社内規程検索なら最新版と権限外を増やします。製品マニュアル検索なら、型番違い、症状の言い換え、複数手順を増やします。問い合わせ回答支援なら、回答不可、確認事項、担当部署への引き継ぎを増やします。

    重要なのは、利用目的に合わせて配分を決めることです。

    合否基準は3段階でもよい

    すべてを0点か100点で判断すると、改善の優先順位が分かりにくくなります。

    最初は、次の3段階でも十分です。

    判定基準対応
    合格必須要点と根拠が正しく、危険な断定がない変更不要
    条件付き合格主要な回答は正しいが、補足不足や表現改善がある利用影響を見て改善
    不合格事実誤り、重要条件の欠落、旧情報、権限外情報、根拠のない断定がある公開・展開前に修正

    質問ごとに重要度も付けます。

    社内ランチ補助の案内と、契約金額や安全手順の案内では、失敗時の影響が違います。重要質問は1問でも不合格なら公開を止める、一般質問は全体合格率で見るなど、業務に合わせて基準を変えます。

    単純な平均点だけで公開判断をしないことが重要です。

    検索と回答を別々に記録する

    RAGのテスト画面では、最終回答だけでなく、取得された資料やチャンクも確認できるようにします。

    失敗は、次のように分かれます。

    検索結果最終回答考えられる状態
    正しい正しい合格
    正しい誤り生成指示、モデル、回答構成を確認
    誤り誤り文書、分割、検索、絞り込みを確認
    誤り偶然正しい一般知識や推測で答えた可能性を確認

    「答えだけ合っている」状態を合格にすると、後で資料が変わったときに誤回答が増える可能性があります。

    社内RAGでは、正しい答えに加えて、正しい資料を取得していることも確認します。

    回答へ出典を表示する設計は、利用者が確認しやすくなるだけでなく、評価時の原因切り分けにも役立ちます。詳しくは、社内AIチャットに根拠表示が必要な理由で解説しています。

    一回の結果ではなく、同じ質問を繰り返す

    生成AIの回答は毎回完全に同じになるとは限りません。

    一度だけ合格した質問も、再実行すると要点が抜ける場合があります。重要な質問は複数回試し、「5回中5回合格」「5回中3回合格」のように安定性を確認します。

    特に次の変更後は、同じ質問セットを再実行します。

    • 社内文書を追加、差し替え、削除した
    • 文書の分割方法や検索設定を変えた
    • 埋め込みモデルや回答モデルを変えた
    • プロンプトや回答形式を変えた
    • アクセス権限や部署フィルターを変えた
    • 検索結果の件数や並び替えを変えた

    変更前の結果を基準として残しておけば、改善した質問と悪化した質問を比較できます。

    新しい機能が動いたかだけでなく、以前できていた質問が壊れていないかを見るのが回帰テストです。

    AIによる自動採点だけに任せない

    質問数が増えると、回答の要点確認をAIで補助したくなります。

    自動採点は、必須語の有無、参照文書、回答不可の表現、一定の評価基準を繰り返し確認する用途には役立ちます。

    ただし、採点するAIも判断を誤る可能性があります。採点基準が曖昧なら、もっともらしい説明付きで誤判定することもあります。

    小規模運用では、次の分担が現実的です。

    • 機械で確認しやすい項目は自動化する
    • 重要質問、不合格質問、境界事例は人が確認する
    • 自動採点と人の判断が違った質問を記録する
    • 採点基準を変えた場合は過去結果との比較条件を残す

    「AIが5点と評価したから正しい」ではなく、業務担当者が重要な事実と運用上の危険を確認できる形にします。

    実際の質問ログからテストを育てる

    導入前は、業務担当者へのヒアリングや既存FAQから質問を作ります。

    導入後は、実際の利用ログから次の質問を追加します。

    • 何度も聞かれている質問
    • 利用者が低評価を付けた回答
    • 担当者が回答を修正した質問
    • 検索結果が空だった質問
    • 追加質問が必要だった曖昧な質問
    • 文書更新後に答えが変わる質問

    ログをそのままテストデータへコピーすると、氏名、顧客名、案件名、契約情報などが残る場合があります。必要に応じて匿名化し、テスト環境へ入れてよい内容だけを使います。

    質問・回答・参照元・評価を改善に使うログ設計については、社内AIチャットのログ設計も参考になります。

    小規模なRAG評価の進め方

    最初は、次の順番で進めます。

    1. RAGで支援したい業務を一つ決める
    2. 利用者と文書の範囲を決める
    3. 利用頻度と重要度が高い質問を20問集める
    4. 各質問の必須要点、参照資料、禁止事項を決める
    5. 検索結果と最終回答を記録できるようにする
    6. 担当者が合格、条件付き合格、不合格を付ける
    7. 失敗を検索、回答、根拠、答えない判断に分類する
    8. 一度に一つの設定を変えて再実行する
    9. 変更前後の結果と実行条件を保存する
    10. 実際の利用ログから質問を追加する

    最初から高度な評価基盤を作るより、同じ質問を同じ基準で繰り返せる状態を先に作る方が重要です。

    スプレッドシートで限界が出たら、質問セット、実行結果、差分、担当者コメントを一覧化する小型ツールへ発展させられます。

    YOSHIO.devで相談できること

    YOSHIO.devでは、ローカルLLM・RAG環境構築、社内AIチャットのPoC、文書整理、評価用質問セット、小型の検証画面について相談できます。

    たとえば、次のような相談です。

    • RAGのPoCで何を合格条件にするか決めたい
    • 実際の業務から20〜30問の評価質問を作りたい
    • 検索結果と最終回答を分けて確認したい
    • 資料にない質問で推測しない設計にしたい
    • 文書更新やモデル変更後の回帰テストを行いたい
    • スプレッドシートの評価表を小型ツール化したい
    • クラウドAIとローカルLLMを同じ質問で比較したい

    「精度を上げたい」という相談だけでも、対象業務、利用者、文書、失敗すると困る質問を整理すると、評価範囲を具体化できます。

    機密情報を含む実データを最初から共有する必要はありません。文書の種類や質問例を匿名化し、小さな検証範囲から設計できます。

    まとめ

    RAGや社内AIチャットの精度は、数回のデモや文章の自然さだけでは判断できません。

    まず、実際の業務を代表する20〜30問の質問テスト集を作ります。

    各質問に、期待する要点、参照すべき資料、含めてはいけない内容、期待する動作を付けます。結果は、検索、回答、根拠、答えない判断に分けて確認します。

    文書、モデル、プロンプト、検索設定を変えたら、同じ質問を同じ基準で再実行します。これにより、改善した点だけでなく、以前できていた質問が悪化していないかも確認できます。

    大規模な評価システムより先に必要なのは、代表質問と合否条件を残し、比較できる状態です。

    よくある質問

    RAGの精度評価には何問必要ですか?

    小規模なPoCなら、利用頻度と重要度が高い20〜30問程度から始められます。基本質問だけでなく、言い換え、条件分岐、最新版、答えがない質問も混ぜ、実際の利用ログから追加します。

    RAGの回答は正解文と完全一致させる必要がありますか?

    通常は一字一句の一致より、必須要点、参照すべき資料、含めてはいけない内容を定義して評価します。文章表現が違っても、必要な事実が正しく安全に伝われば許容できます。

    検索結果と最終回答は別々に評価すべきですか?

    はい。正しい資料を取得できたのに回答を間違えた場合と、必要な資料を検索できなかった場合では、直す場所が異なります。取得文書と最終回答を分けて記録すると原因を切り分けやすくなります。

    資料に答えがない質問もテストする必要がありますか?

    必要です。資料にない内容を推測せず、確認できないことを伝えたり、担当者への確認を促したりできるかは重要な評価項目です。流暢でも根拠のない回答は不合格にします。

    AIを使ってRAGの回答を自動採点できますか?

    採点補助には使えますが、自動採点だけで重要な公開判断を行うのは避けます。重要質問、不合格、境界事例は業務担当者が確認し、自動採点と人の判断が違った事例を残します。

    文書を更新するたびに全質問を再テストすべきですか?

    影響範囲が小さい場合は関連質問を優先できますが、重要質問の基本セットは定期的に再実行するのがおすすめです。更新した箇所が別の検索結果や回答へ影響することもあるため、変更前後の結果を比較します。

    RAGの評価表だけを小型ツール化する相談もできますか?

    はい。質問セット、期待する要点、取得文書、実行結果、合否、変更前後の差分を一覧化する小型ツールから相談できます。最初はスプレッドシートで要件を確認してから必要な部分だけ実装できます。