LLM導入の相談前に整理すべき要件をまとめる方法

なぜ「相談前の要件整理」でLLM導入の成否が決まるのか

LLM（大規模言語モデル）を業務に取り入れたいと考えたとき、多くの企業が最初にぶつかるのが「何から相談すればいいか分からない」という壁です。ベンダーやSIerに連絡しても、返ってくる質問は「目的は？対象業務は？データは？予算と期限は？」と抽象的に見えがちで、結果として打ち合わせが長引き、PoC（試験導入）が増え、費用だけが膨らむケースもあります。

ここで重要なのは、LLM導入は“ツール選び”ではなく“業務設計”だという点です。たとえば「メール返信を自動化したい」という要望でも、実態は「一次返信の定型化」なのか「過去の対応履歴を踏まえた提案文」なのかで、必要なデータ、精度、セキュリティ、運用体制が変わります。要件が曖昧なまま進めると、出てきた成果物が「それっぽい文章は出るが、現場では怖くて使えない」になりがちです。

また、LLMは従来のシステムと違い、出力が確率的で“揺れる”特性があります。Excelの計算結果のように常に同じ答えが返るわけではありません。だからこそ「どこまでを許容し、どこからを人が確認するか」「誤りが起きたときにどう止めるか」といった運用要件が最初から必要になります。さらに、社内データを使うなら情報漏えい対策、外部サービス利用なら契約・ログ・学習利用の可否など、情シス・法務・現場の観点が絡みます。

本記事では、開発の専門知識がなくても、相談前に「自社が決めるべきこと」を漏れなく整理できるように、要件をまとめる具体手順とテンプレートの考え方を解説します。読み終えたときに、社内合意の材料が揃い、ベンダーから見積もりや設計案を引き出しやすくなる状態を目指します。

まずは「目的」を業務KPIに落とす：LLMで何を良くしたいか

要件整理の出発点は「LLMで何ができるか」ではなく、「今の業務のどこが痛いか」です。ありがちな失敗は、「AIで業務改革したい」という大きな旗だけ立てて、現場がどの作業をどの基準で楽にしたいのかが不明なままPoCに入ってしまうことです。目的は“効果の測り方”まで含めて言語化すると、要件が自然と具体化します。

目的を整理するときは、次の3点をセットで書き出すのがおすすめです。

• 対象業務：例）問い合わせメール対応、議事録作成、社内規程検索、見積コメント作成
• 現状の困りごと：例）確認に時間がかかる、属人化している、抜け漏れが出る、繁忙期に追いつかない
• 改善の物差し（KPI）：例）平均対応時間を30%短縮、一次回答率を60%に、議事録作成を当日中に、検索時間を半分に

ここでのコツは「定量KPI」と「定性KPI」を両方置くことです。定量は工数削減や処理件数、品質指標（誤回答率など）。定性は「新人でも一定品質で作れる」「夜間対応の心理負担が減る」など、現場の納得感に直結します。LLM活用は、効果が“見えにくい良さ”も多いため、定性指標を無視すると評価が割れます。

また、「LLMで自動化したい」と言っても、完全自動化が必要なケースと、下書き生成で十分なケースがあります。例えばメール返信なら「下書きを作る→人が確認して送る」だけで、ミスリスクを抑えつつ大きな時短になります。議事録なら「要点抽出→人が修正→社内共有」という形が現実的です。“人が最後に責任を持つ設計”を前提にすると、導入のハードルが一気に下がります。

ユースケースを分解する：入力・出力・判断・例外を洗い出す

目的が決まったら、次にやるべきはユースケースの分解です。LLMは「文章を作る」だけでなく、「分類する」「要約する」「抽出する」「候補を列挙する」「手順を提案する」など多様な使い方があります。だからこそ、業務の流れの中で、どの部分をLLMに任せ、どの部分を従来ロジックや人が担うかを切り分けます。

分解には、次の観点が効きます。

• 入力（Input）：何を渡すか。例）メール本文、FAQ、製品仕様、過去対応ログ、社内規程
• 出力（Output）：何を返すか。例）返信文案、回答候補と根拠、要約、分類ラベル、チェックリスト
• 判断（Decision）：どんな条件で分岐するか。例）クレームは上長承認、個人情報が含まれるときは自動送信禁止
• 例外（Exception）：うまくいかないときの逃げ道。例）不明点が多い場合は質問文を生成、根拠が出せない場合は「要確認」

たとえば「社内規程の問い合わせ対応」を想定すると、入力は「質問文＋関連部署＋社員区分」、出力は「回答文＋参照条文＋注意点」、判断は「人事・法務系は必ず根拠提示」「条文が見つからない場合は案内先を出す」、例外は「曖昧な質問には確認事項を返す」といった形になります。

この分解ができると、相談時に「どのデータをどの粒度で用意するか」「どこにチェックポイントを置くか」「どういう画面や導線が必要か」が見えてきます。さらに、LLMに任せる範囲が明確になるため、過度な期待（魔法の箱扱い）を防げます。“LLMにやらせないこと”を決めるのも要件です。例えば、契約書の最終判断、送金指示、対外的な確定回答の自動送信など、リスクが大きい領域は原則として人の承認を前提に設計します。

データとセキュリティ要件：社内利用で必ず押さえる観点

LLM導入の相談で最も差が出るのがデータとセキュリティです。「社内の情報を読ませたい」という要望は多い一方で、実際にどの情報を、どこに、どの状態で置くのかが整理されていないと、技術選定も見積もりもブレます。ここでは非エンジニアでも押さえやすいよう、確認項目を業務言語でまとめます。

まずデータ要件は、次の棚卸しから始めます。

• 参照したい情報：FAQ、マニュアル、規程、製品仕様、議事録、案件履歴、ナレッジ
• 所在：SharePoint、Google Drive、社内ファイルサーバ、SaaS（Zendesk等）、紙→PDF
• 更新頻度：毎日更新か、月次か。古い情報が混ざると困るか
• 品質：重複、古い版、表記ゆれ、機密の混在、誤記の有無

次にセキュリティ要件です。ポイントは「技術的に安全か」だけでなく「社内ルール・契約・監査に耐えるか」です。最低限、次の観点は相談前に社内で方向性を決めておくとスムーズです。

• 取り扱う情報の区分：公開情報のみ／社内限定／個人情報／顧客機密／営業機密
• 外部LLMサービス利用の可否：入力データが学習に使われない契約が必要か、ログ保管方針はどうするか
• アクセス制御：部署ごとに見せる情報を変える必要があるか（権限連携）
• 監査・記録：誰が何を入力し、どんな出力を得たかを残す必要があるか

たとえば情シス視点では「SSO連携（Azure AD等）」「権限に応じた検索制御」「ログの保管期間」「データの持ち出し禁止」「端末制限」などが論点になります。経営視点では「顧客情報を外部に送ってよいのか」「事故時の説明責任を果たせるか」が重要です。

なお、社内文書をLLMに活用する代表的な方式としてRAG（検索拡張生成）があります。これは、社内文書を検索して関連部分を取り出し、その内容を根拠として回答文を生成するやり方です。RAGは万能ではありませんが、「根拠提示」「最新情報への追従」「学習不要で始めやすい」などの利点があり、相談時に候補として挙がりやすいです。“どの情報を根拠として出力したか”を示せる設計は、現場の安心感と監査性に直結します。

品質・運用要件：精度より先に「止め方」と「責任分界」を決める

LLM導入でよくある誤解は「精度が高ければ運用できる」という考えです。実務では、精度がそこそこでも運用設計が良ければ回りますし、逆に精度が高くても運用が曖昧だと事故が起きます。相談前に、品質の考え方を“合格ライン”として定義し、運用でコントロールする方針を決めておきましょう。

品質要件は、次のように分けて考えると整理しやすいです。

• 正確性：事実誤認がどの程度許されるか。誤り時の影響は大きいか
• 再現性：同じ入力で出力が揺れるのを許容できるか（温度設定等の影響）
• 説明可能性：根拠（参照文書、引用、計算過程）が必要か
• 安全性：機密漏えい、差別表現、攻撃的表現を防げるか

さらに、運用要件として必須なのが「責任分界」と「承認フロー」です。例えば以下のようなルールを決めます。

• 誰が使うか：全社員／特定部署のみ／特定ロールのみ
• どこまで自動化するか：下書きまで／送信まで／判断まで
• 人の確認ポイント：対外文書は必ず確認、金額や納期が絡むときは承認必須
• 失敗時の動線：「回答できません」と返す、担当部署にエスカレーションする

ここで役立つのが「NGリスト」と「安全側に倒す設計」です。たとえば、個人情報が入力された可能性がある場合は回答を止めて注意喚起を出す、根拠文書が取れない場合は断定しない、などです。“うまく答えない勇気”をシステムに持たせることが、現場で使われ続けるLLM活用のコツです。

評価方法も相談前に決めておくと、PoCが終わりやすくなります。例えば問い合わせ対応なら、過去チケットを使って「正答率」「根拠の妥当性」「一次回答で完結した割合」「作業時間」を測る。議事録なら「要点の抜け漏れ」「固有名詞の誤り」「清書時間」。評価データをどこから取るかも要件の一部です。

相談に持ち込める「要件定義テンプレ」：最低限この項目を埋める

ここまでの内容を、相談時にそのまま渡せる形に落とし込みます。文書は立派である必要はありません。重要なのは、ベンダーが追加質問せずに「選択肢」「概算」「進め方」を提示できる粒度になっていることです。1〜2ページに収まる“要件サマリ”を作るイメージで、以下の項目を埋めてください。

テンプレを埋めるとき、難所になりやすいのが「出力要件」と「品質の合格ライン」です。ここは、過去の実データを2〜5件持ってきて、「理想の回答例」と「ダメな回答例」を並べると一気に伝わります。例えば問い合わせ対応なら、良い例は「結論→理由→手順→注意点→参照」の順で簡潔、悪い例は「断定しているが根拠がない」「社内ルールと矛盾」などです。ベンダー側も、例があるとプロンプト設計やRAG設計の方針を出しやすくなります。

もう一つのコツは「できれば嬉しい」と「必須」を分けることです。最初から多機能を求めると期間も費用も読めません。必須要件は3つまで、あると良い要件は別枠にすると、現実的な提案になりやすいです。

まとめ

LLM導入を成功させるには、相談の前に「目的→ユースケース→データ/セキュリティ→品質/運用→テンプレ化」の順で要件を整理することが近道です。特に、精度だけでなく“止め方・確認の仕組み・責任分界”までを要件に含めると、現場が安心して使える設計に近づきます。

本記事のチェックポイントを使って要件サマリを1〜2ページにまとめておけば、ベンダーへの相談が「抽象論」から「具体案と見積もり」へ進みやすくなります。また、社内の合意形成（情シス・法務・現場・経営）も早くなり、PoCが長期化しづらくなります。

LLMは導入して終わりではなく、データ更新・プロンプト改善・利用状況の分析を通じて育てていく取り組みです。まずは小さく始め、評価可能なKPIを置き、運用で安全性を担保する設計から始めてください。