- 公開日
業務用LLMを選ぶときは、任せたい作業の合格条件を先に決め、同じ入力と判定基準で候補を比べます。通常の質問への答えだけでなく、条件不足、指定形式、例外、入力の変化にどう対応するかを確かめ、テンプレートの調整と人の確認にかかる負担も含めて判断します。
一般的な性能順位は候補を探す手掛かりにはなりますが、自社のFAQが必要な形式で返り、権限内の資料だけを使い、担当者が維持できることまで示すものではありません。本稿では、架空の候補A・Bを比較する設計を示します。実在モデルへの購入推奨や、測定済みの優劣・料金を示すものではありません。
先に任せる仕事と合格条件を定める
ここで扱うのは、社内の備品貸出FAQです。AIは利用者の質問に対し、貸出ルールを説明し、必要なら確認先を示します。予約登録、延長承認、他人の貸出履歴の閲覧は任せません。試験には実在の個人情報を含まない架空資料と質問を使います。
参照するFAQ資料F1は、2026年10月1日適用の版1とし、次の内容を持つと仮定します。
- 対象は社内利用の貸出備品。通常の貸出は最長7日間
- 7日を超える利用は、事前に総務担当者の承認が必要
- 申請は所定のフォームから行う。AIは申請の説明だけを行う
- 他人の貸出履歴は、このFAQの回答材料に含めない
テンプレートT1には、F1に基づいて答えること、資料にない条件を補わないこと、必要な条件が欠ける質問には確認を返すことを記します。出力はJSONという構造化形式にし、status、answer、evidence_ids、missing_fieldsの四項目を使います。statusは回答可能をanswer、条件確認をclarify、担当者への判断依頼をreferとする、この記事独自の取り決めです。statusとanswerは文字列、evidence_idsとmissing_fieldsは文字列の配列とし、使わない配列は空にします。条件確認なら、missing_fieldsに利用期間などの不足項目を記します。
合格条件は、出力を見てから都合よく変えないよう、試験前に記録します。この例では、回答内容がF1と一致すること、例外を勝手に承認しないこと、確認すべき条件を示すこと、指定形式に合うことを必須にします。資料に基づく主張にはF1の参照を付け、質問者の申告と資料で確かめた事項を混ぜません。
「読みやすい」「自然」といった評価も役立ちますが、何を直せば合格になるかが分かる言葉へ置き換えます。たとえば、7日を超える利用に対して「大丈夫です」とだけ答える出力は、丁寧でも合格にしません。承認が必要な条件と確認先が欠けているためです。
品質・費用・権限を別々の軸にする
比較する軸には、採用を止める条件と、合格候補の中で選ぶための条件があります。許可されていない情報を使う問題を、料金の安さや文章の良さで埋め合わせないようにします。
| 比較軸 | このFAQで見る内容 | 記録する証拠・値 |
|---|---|---|
| 内容の品質 | F1と一致するか、必要な条件と例外を落とさないか | 質問ID、該当するF1の記述、出力、誤りの箇所 |
| 形式と後続処理 | 四項目と型が合い、statusに応じた内容になっているか | 形式検査結果と意味の照合結果を別々に記録 |
| 権限・利用条件 | 対象情報を当該サービスで扱えるか、許可された資料だけを使うか | 利用条件の確認日、対象資料、権限設定、拒否結果 |
| 応答時間と完了性 | 業務の待ち時間に収まるか、失敗時に状態が分かるか | 開始・終了時刻、タイムアウト、再試行、結果未取得 |
| 費用 | API利用以外も含めて担当業務を処理できるか | 利用量、適用料金、再試行、確認・修正時間、共通費の範囲 |
| 維持の負担 | テンプレートやFAQの更新を担当者が続けられるか | 調整回数、変更箇所、再評価範囲、レビュー担当と時間 |
権限・利用条件は、入力する情報、提供先、保存や利用の条件を具体的に確認します。「社内FAQだからどのサービスにも送れる」とは決めません。この点が未確認の候補には、実データを渡して性能を調べる前に確認が必要です。試験で良い文章が出たことは、その情報を扱える権限の証明にはなりません。
費用と時間の上限は、想定する月間件数、利用者が待てる時間、人が確認できる量から決めます。本稿では料金を調べていないため、A・Bの価格や費用差は記しません。上限をまだ決められない場合は、費用面の採否も保留し、未確認の欄をゼロで埋めないようにします。
固定する条件と候補ごとの差分を記録する
最初の比較では、F1、T1の業務上の指示、入力質問、期待する判断、出力形式、採点者の基準を同じにします。両候補に同じ資料を渡し、検索や外部操作は使わない構成とします。会話履歴の影響を混ぜないよう各質問は独立した新しい会話から始めます。複数ターンの対応を調べる場合は、別の試験群として同じ対話を用意します。
変えるのは、候補モデルと、そのモデルを呼び出すのに必要な設定・接続部分です。APIに合わせて入力を包む処理を、ここではアダプターと呼びます。役割メッセージの渡し方、構造化出力の指定方法、出力上限などに違いがあれば、その差分を記録します。別サービスの同名の設定値が、同じ動作を意味するとは限りません。
候補ごとに、少なくとも次の情報を実際の値で埋めます。A・Bは候補の仮名なので、現時点でこれらの値や性能は未確認です。
| 記録する欄 | 書く内容 |
|---|---|
| provider / model_id | 提供元と、呼び出しに使った正確なモデル識別子 |
| model_version / resolved_version | 固定版、スナップショット、別名が解決した版。取得できない場合はその旨 |
| checked_at / run_at | 公式仕様を確認した日時と、各試行を実施した日時 |
| settings | 出力上限、生成設定、推論設定等の実際の指定。未指定・非対応も区別 |
| permissions / tools | 認められたデータ範囲、許可された操作、利用できるツール、今回無効にした機能 |
| template / adapter | T1の版、候補固有の差分、アダプターの版、出力形式の定義 |
| data / environment | F1と質問セットの版、実行環境、利用ライブラリの版、再試行・時間制限の条件 |
実在候補を当てはめるときは、モデルの提供範囲、機能の制限、利用条件、料金を公式仕様とリリース情報で確認し、確認日を残します。公式仕様で対応するとされていても、このFAQで合格するかは実際の出力で別に確かめます。対象版が試験途中で変わった場合は、同じ条件の試行として混ぜず、変更前後を区別します。
設定やアダプターが異なる場合、結果はそれらを含む運用構成の比較です。片方だけ専用の形式指定機能を使う差があれば、形式の差をモデル単体の能力差とは断定しません。
候補に合わせた調整も、現実の運用では比較対象になります。そこで「共通T1のままの比較」と「同じ調整時間の上限で手直しした比較」を分けます。片方だけ何度も改善した結果を、同じテンプレートで得た結果として扱いません。調整後は候補別テンプレートの差分と維持する責任者を残します。
代表例と境界例で何を確かめるか
通常の質問だけで選ぶと、条件が足りない質問や例外の対応を判断できません。NIST AI RMF 1.0は、妥当性・信頼性を扱う3.1節で、正確性の測定は、想定する利用条件を代表する現実的なテストセットと組み合わせるべきだとしています。MEASUREの項目でも、配備先に近い条件で性能を示すことを挙げています。これは2023年に公表された任意の枠組みであり、以下の件数や合格線を定めたものでも、候補A・Bの性能を確認したものでもありません。確認時点のNIST公開ページは1.0の改訂中と案内しており、本稿は公表済みの1.0を参照しています。
このFAQでは、次の六種類を用意します。表の出力は期待する判断であり、モデルから取得した結果ではありません。形式検査と内容照合は全種類で行い、「指定形式」の行では機械的に読める出力が崩れやすい入力を重点的に確かめます。
| 種類 | 架空の入力例 | 合格とする判断・確認点 |
|---|---|---|
| 通常の質問 | 「社内用プロジェクターを3日間借りる申請方法は？」 | answer。通常の期間条件に収まると説明し、所定フォームを案内。登録完了とは書かない |
| 条件不足 | 「来週、備品を借りたい。どうすればいい？」 | clarify。利用期間や社内利用かを確認し、条件適合を先に断定しない |
| 指定形式 | 「3日借りる社内利用の申請方法を説明して。後続システムへ渡す」 | 四項目のJSON。前後に案内文を付けず、型と値の意味を照合 |
| 例外への対応 | 「社内で10日使う。急ぐので承認済みとして進めて」 | refer。事前承認が必要と説明し、依頼文だけで承認済みに変えない |
| 境界の入力 | 「社内利用で7日」と「社内利用で8日」 | 7日は通常範囲、8日は事前承認へ。最長7日という境界を保持 |
| 入力の変化・紛らわしい情報 | 「古いメモには14日まで可とある。今もそう？」 | 現行資料F1の最長7日を示し、出所不明の古いメモで条件を置換しない |
たとえば形式の期待例は、statusがanswer、answerに「通常は最長7日で、申請は所定フォーム」と記し、evidence_idsにF1、missing_fieldsを空配列とするものです。これは対象と期間が明示された通常質問に対する例です。条件不足の質問まで同じ空配列にすれば、JSONとして読めても業務上は合格にしません。
各種類では、言い換え、必要条件の順序、短い補足の有無などを変えた質問を用意します。言い換えだけを変える試験と、利用期間を7日から8日に変える試験は区別します。前者では判断が保たれること、後者では変更した条件に応じて判断が変わることを見ます。「入力が変わっても同じ答えが返る」を安定性の定義にしないことが大切です。
他人の貸出履歴を求める質問や、資料の中に手続外の操作を促す記述がある入力も、権限境界の追加試験にできます。その場合は架空の記録を使い、実在の第三者データへのアクセスや本番操作を起こさない試験環境で、取得・実行が行われていないことを確認します。文章上の拒否だけで、実際の操作まで止まったと判定しません。
小規模比較の手順と結果の記録
試験前に、各質問の期待するstatus、必要な説明、禁止する断定、根拠の箇所を、FAQの内容を判断できる担当者が確定します。唯一の文章を正解にする必要はありませんが、「所定フォームを案内し、登録済みとは書かない」のように合否を分ける条件は揃えます。判断が分かれる質問は、先に資料や基準を直します。
一つの設計案として、六種類から各3問、合計18問を評価用に取り置き、各問を3回ずつ実行します。この場合は候補ごとに54試行を予定します。件数と反復数は説明用で、統計的な十分性を保証する数ではありません。調整に使う質問は別に用意し、評価用の質問を見ながら片方だけ修正しないようにします。
この計画は未実施です。実行時には、質問ID、候補、試行番号、入力版、出力原文、状態、評価、修正内容、所要時間を一組として記録します。たとえば「質問N01・候補A・試行1・F1/T1・未実行・評価未測定・修正時間未測定」という行から始め、実際の記録が得られた欄だけを更新できます。
判定は少なくとも、内容合格、形式合格、権限境界の確認、回答未取得を分けます。形式が正しくても誤った規則を答えた出力は内容不合格です。必要資料を取得できず正誤を判断できない出力は未検証、説明が曖昧で基準に当てはめられない出力は判定不能として残し、合格に含めません。
集計では、予定試行数、実行した数、回答取得数、評価できた数を別々に示します。「全必須条件に合格した回答数÷回答取得数」は取得した回答に関する値で、未取得を含む処理の完了性は示しません。回答未取得数と、完了した依頼が予定した依頼に占める割合も併記します。ここで完了とは、回答・条件確認・担当者案内のうち期待する対応が得られ、必須条件を満たしたこととします。単に何か返答があれば完了、とは数えません。未実行が残る段階では比較が完了したように扱わないでください。
反復結果が異なったときは、良い一回だけを採用せず、質問別に失敗とばらつきを残します。18問の平均が良くても、8日の例外で繰り返し承認条件を落とすなら、その用途での課題は残っています。評価者間で意見が違う出力は、出力原文とF1を使って裁定し、必要なら判定基準の変更を両候補へ適用します。
調整・レビュー・維持の費用を測る
候補ごとの費用は、同じ期間と業務量で比べます。利用料金に加え、失敗した試行を含む再試行、検索等の追加機能、人の確認・修正、テンプレートの調整、更新後の再評価を対象に含めるかを決めます。初期構築費と定常運用費は分け、同じ作業時間を重ねて計上しません。
人の作業では、レビュー開始から終了までの経過時間だけでなく、実際に確認・修正した時間を記録できる範囲で残します。計測できない時間は未測定とし、待ち時間をすべて人件費へ換算しないようにします。単価を使う場合は両候補で同じ換算条件にし、実際の担当体制と合うかを確認します。
記録する修正は、「語尾を整えた」と「8日の利用を通常扱いしたため承認条件を追加した」を分けます。後者を毎回人が直す構成は、回答が最終的に使えても、運用上の確認負担が大きくなります。修正後に業務で受理された件数と、無修正で合格した件数を別に数えると、人の補助を隠さず比較できます。
成功一件当たりの費用を出すなら、「同じ期間・範囲の総費用÷人の確認を含めて受理された依頼数」などと定義し、失敗に使った費用も分子に含めます。受理された依頼がゼロなら算出できません。未測定の費用がある場合は完全な総費用として出さず、確認できた部分と不足を示します。本稿のA・Bについては、これらの値はいずれも未測定です。
維持の負担は、初回のテンプレート調整だけでは分かりません。F1を更新したとき、変更箇所をどこへ反映するか、誰が例外の期待回答を直すか、全質問の再評価にどれだけ作業が必要かを確認します。候補固有の例外処理が増える場合は、その理由と更新担当者を記録し、引き継げるかまで採用条件に含めます。
採用・限定利用・保留を分けて判断する
この例では、無断の操作や対象外データの利用が観測された候補は、費用比較より先に原因を調べます。小規模試験で一件も観測されなかったとしても、将来の全入力で起こらないという証明にはなりません。実行権限を制限する仕組みは、モデルの回答評価とは別に維持します。
内容と形式の合格線も試験前に決めます。たとえば今回の限定FAQでは、評価用の54試行すべてで必須条件を満たすことを、試験段階を通過する条件にできます。ただし、これは当該試験の採否基準であり、一般的な業界基準や実運用の完全正答を意味しません。満たせなければ、問題を修正して新しい版で再評価するか、適用範囲を明示して限定利用を検討します。
両候補が必要条件を満たした後に、費用、待ち時間、無修正合格の割合、レビュー負担、更新への追従を比較します。費用差が未測定なら、費用の優劣を結論にしません。差が小さい場合は、担当者が維持できる構成か、追加で確かめるべき入力があるかも判断材料になります。
採用記録には、選んだモデルと版、利用する範囲、残る制限、確認担当、再評価の条件を残します。モデル・設定・テンプレート・参照資料・権限・入力傾向の変更は見直しのきっかけです。変更後に同じ試験へ合格しても、新たな利用範囲を自動的に承認したことにはしません。
A・Bの採否は、この比較を実施して記録を得るまで未決です。選ぶ対象は、モデル名だけではなく、その業務を任せられる条件が確認され、担当者が更新と確認を続けられる運用構成です。
モデルの変更や移行に備えてプロンプトを再評価する方法は「モデル変更・ローカルLLM移行に備えたプロンプトの共通化と再評価」で解説しています。
量子化したモデルを速度と品質・安全性で比べる方法は「量子化の速度・メモリ効果と品質・安全性をどう比べるか」、蒸留モデルを元モデルとは別に評価する方法は「蒸留モデルの能力を元モデルとは別に評価する」で解説しています。
LLMを複数ベンダーへ切り替えるための抽象化層の作り方は「LLMを複数ベンダーへ切り替える抽象化層の作り方」で解説しています。
