オンプレ生成AIの要件定義ガイド｜PoCで確認すべきデータ・権限・精度・運用【2026年版】

2026年8月4日 20:06

「機密情報を外部へ送れないので、オンプレ生成AIを検討したい。まず、どのモデルとGPUを選べばよいですか」

オンプレ生成AIの相談で、よく出る質問です。しかし、モデルやGPUから決めると、技術検証はできても現場で使えないシステムになりがちです。誰が、どの業務で、何を入力し、どんな成果物を受け取り、誰が確認するのか。この業務要件が決まっていなければ、必要な性能も権限も評価基準も決まりません。

本記事は、noteマガジン「オンプレ生成AI特集」の実装編です。オンプレ生成AIの概要やクラウドとの比較から一歩進み、発注前の要件定義、PoC、本番移行までを具体的に整理します。

この記事の要点

・オンプレ生成AIの要件定義は、モデルではなく対象業務・データ・利用者・確認責任から始める
・PoCは1業務に絞り、回答精度だけでなく出典、権限、応答時間、確認負担、運用可能性を評価する
・本番移行は採用・条件付き採用・再検証・停止の4段階で判断し、PoCの成功と運用の成功を分ける

オンプレ生成AIの要件定義とは

要件定義とは、導入したい製品を並べる作業ではありません。AIに任せる仕事と、任せない仕事の境界を決める作業です。

オンプレ生成AIでは、次の5領域を一つの設計として考えます。

製品比較は「何を使うか」を決めます。要件定義は「何を、誰が、どの条件で完了させるか」を決めます。順番は要件定義が先です。

オンプレ生成AIそのものの仕組みやクラウドとの違いは、ChatGPTを社内で使えない企業の解決策で解説しています。本記事では「導入するなら何を決めるか」に集中します。

最初にオンプレ化する業務を1つに絞る

PoCで「社内のあらゆる質問に答えるAI」を作ろうとすると、対象文書、利用者、正解、権限が広がり、評価できなくなります。最初は1部署・1業務・1種類の成果物に絞ります。

最初の対象に向く5つの条件

外部へ送信できないデータを扱う
繰り返し発生し、現在の工数を把握できる
入力と成果物を特定できる
正解や参照根拠を担当者が確認できる
誤りが起きても、人の確認で影響を止められる

たとえば、品質規程を根拠にした一次回答、過去の契約書からの条項候補抽出、院内マニュアルの検索、顧問先別の書類下書きなどです。いずれも、AIは検索や下書きを担い、人が確定します。

業界ごとの対象業務は、金融・保険業界のオンプレ生成AI活用、製造業の技術伝承AI、医療機関のオンプレ生成AI活用、士業事務所のオンプレ生成AI活用でも具体的に整理しています。

最初に選ばない方がよい業務

法務、医療、会計、安全などの最終判断
正解や合格条件を説明できない仕事
元データが散在し、正式版が分からない仕事
複数部門と複数システムを同時に巻き込む仕事
例外処理が多く、熟練者にも手順を説明できない仕事

大きな業務から始めるほど成果が大きいように見えますが、PoCでは原因を切り分けられることが重要です。回答が悪いときに、モデル、検索、元文書、指示、権限のどこが原因か分からなければ改善できません。

業務定義シートを作る

次の表を埋めると、技術担当者やベンダーとの会話が具体化します。

「工数を減らす」だけでなく、誰が確認するか、誤りが何につながるかまで書くのがポイントです。

データ要件｜何をAIへ渡し、どこへ置くか

オンプレ生成AIの精度は、モデルの性能だけで決まりません。参照させる文書の品質と権限設計が、回答品質の土台になります。

データ台帳を作る

PoCへ使う前に、文書やデータを次の項目で一覧化します。

RAGは社内文書を検索し、関連箇所をモデルへ渡す仕組みです。詳しい作り方は社内AI（社内GPT・RAG）の作り方で解説しています。

正式版と旧版を分ける

同じ規程の旧版と新版が混ざれば、AIは両方を根拠にする可能性があります。ファイル名だけに頼らず、版、施行日、失効日、承認者をメタデータとして持たせます。

画像PDFやスキャン文書は、文字を正しく抽出できるか確認します。表、脚注、図面、手書き追記などは、検索段階で情報が落ちることがあります。PoCでは、実際に使う形式を避けずに試します。

文書単位のアクセス権を引き継ぐ

人事、法務、案件別資料を同じ検索基盤へ入れる場合、検索結果にも元のアクセス権を反映させます。利用者が直接開けない文書を、AI経由なら読める状態にしてはいけません。

OWASPは、RAGで使うベクトルや埋め込みのアクセス制御が弱いと、権限のない情報が検索・開示される危険を指摘しています。OWASPのVector and Embedding Weaknessesでも、RAGを導入しただけでは安全にならないことが分かります。

入れる方法だけでなく、更新・削除を設計する

PoCでは文書を一括登録できても、本番では毎月更新されます。誰が差し替えるか、旧版をいつ検索対象から外すか、削除が検索インデックスへ反映されたかをどう確認するかまで決めます。

システム要件｜モデル・RAG・GPU・ネットワークを決める

業務とデータが決まった後で、必要なシステムを逆算します。

モデルは「最大」ではなく「必要十分」で選ぶ

ローカルLLMの候補を比較するときは、次を確認します。

日本語と自社文書形式への対応
必要な入力長と出力長
回答速度と同時利用数
構造化出力やツール実行の要否
モデル、コード、学習データに関するライセンス条件
必要なGPUメモリと量子化時の品質
更新頻度と保守の見通し

モデル名だけで決めず、自社の評価データで比較します。代表的なモデルとハードウェアの考え方はローカルLLM完全ガイドも参考にしてください。

GPUは同時利用数と応答時間から逆算する

「最も大きいモデルが動くGPU」ではなく、利用者が待てる時間、ピーク時の同時リクエスト数、入力文書の長さ、障害時の冗長性から決めます。

PoCで1人が使えたとしても、50人が同時に質問すれば待ち時間は変わります。監視項目には、リクエスト数、待ち行列、応答時間、生成速度、GPU・メモリ使用率、失敗件数を含めます。Hugging Faceの推論基盤資料でも、リクエスト時間やキュー、生成トークン、ハードウェア使用率などが運用指標として示されています。

3つの構成を比較する

「オンプレ」という名称だけで、外部通信がゼロだと判断しないでください。モデル取得、ライセンス認証、ソフトウェア更新、監視、バックアップ、検索、外部API、プラグインなど、通信する可能性のある接続先を棚卸しします。

権限・ログ・監査の要件

オンプレ環境に置けば、外部サービスへ直接入力するリスクは抑えられます。しかし、内部の過剰権限、誤操作、プロンプトインジェクション、ログ不足は残ります。

OWASPは、プロンプトへの指示だけを強いアクセス制御として使わず、認証・権限管理をLLMの外側で実装することを推奨しています。「この情報は出さないで」とAIへ頼むだけでは権限制御になりません。

認証とアクセス権

個人単位で認証する
部署、役職、案件単位で参照文書を制御する
管理者と一般利用者の権限を分ける
外部システムへ書き込む権限を別にする
退職・異動時に速やかに停止する
サービスアカウントの権限を最小化する

ログへ残す項目

入力と出力には機密情報が含まれるため、ログ自体も保護対象です。閲覧権限、保存期間、マスキング、削除方法を決めます。

人の承認を残す処理

外部送信、データ削除、確定登録、契約・医療・会計・安全上の判断、権限変更は、AIだけで完了させません。AIは候補提示や下書きまで、人が確認・承認して実行する設計にします。

生成AIの情報漏洩対策でも、入力ルールと技術的な制御を組み合わせる方法を解説しています。

PoCの評価設計｜精度だけで判断しない

PoCでありがちな失敗は、担当者が選んだ簡単な質問に答えられたため「精度が高い」と判断することです。本番では、曖昧な質問、古い資料、権限外情報、答えのない質問も来ます。

評価データを先に固定する

評価には次のケースを含めます。

正式文書に明確な答えがある通常ケース
複数文書を横断しないと答えられないケース
情報が不足し、追加質問が必要なケース
利用者の権限外に答えがあるケース
新旧文書が混在するケース
文書に答えがなく「分からない」と返すべきケース
文書内に不正な指示が含まれるケース

OWASPは、Webページやファイルに隠れた指示をAIが読み、意図しない操作や情報開示につながる間接的なプロンプトインジェクションを挙げています。RAGへ取り込む文書も「信頼できる命令」ではなく、処理対象のデータとして扱います。

PoC評価表

正答率の一つの数字だけで合格基準を決めません。誤りの重大性が違うからです。軽微な表現修正と、患者・契約・安全に関わる誤りを同じ1件として数えると判断を誤ります。

ハルシネーションの検証方法は生成AIのハルシネーション対策でも整理しています。

総時間で効果を測る

生成時間だけではなく、データ準備、質問入力、待ち時間、出典確認、修正、承認、転記を含む総時間を測ります。AIが数秒で回答しても、人が毎回元資料を30分確認するなら、業務全体では改善していない可能性があります。

PoCの採用・再検証・停止基準

PoC開始前に、終了時の判断を決めます。

停止は失敗ではありません。PoCの目的は、本番導入を正当化することではなく、投資すべき条件を見極めることです。

PoC止まりを防ぐ6つの確認

本番の利用者数・同時利用数で性能を見積もったか
運用管理者とデータ所有者が決まっているか
文書の登録・更新・削除手順があるか
誤回答・障害・情報事故の連絡先があるか
モデルやソフトウェア更新後の再評価方法があるか
導入後の業務KPIを継続して測れるか

PoCを作った人が去ると更新できない、という状態を避けます。設計書、設定、評価データ、テスト結果、運用手順を社内へ残します。

本番移行で追加する要件

PoCは「動くか」を確かめます。本番では「止まっても戻せるか」「変わっても評価できるか」が必要です。

可用性と障害対応

バックアップ対象と復元手順
目標復旧時間と許容停止時間
サーバー・GPU・検索基盤の監視
障害時の代替業務
利用者への通知方法
ベンダーと社内担当の責任分界

変更管理

モデル、推論エンジン、RAG設定、埋め込みモデル、文書、プロンプトを変更すると回答が変わります。変更前後で固定評価データを再実行し、問題があれば元へ戻せるようにします。

利用ルールと教育

操作説明だけでなく、入力してよい情報、出典の確認方法、AIが答えない場合の対応、事故報告、利用停止条件を教育します。利用者が安全側に倒れて全く使わない状態と、便利さを優先して確認しない状態の両方を避けます。

定着KPI

ログイン数だけでは成果を測れません。対象業務の総時間、回答の修正率、確認時間、例外件数、再利用率、問い合わせの解決率など、業務の変化を見ます。

そのまま使える要件定義チェックリスト

業務

[ ] 対象業務を1つに絞った
[ ] 入力と成果物を定義した
[ ] 利用者と確認者を決めた
[ ] AIへ任せない判断を明記した
[ ] 現在工数と導入後KPIを決めた
[ ] 失敗時の影響と戻し方を整理した

データ

[ ] データ台帳を作成した
[ ] 正式版・旧版・失効日を管理できる
[ ] 機密区分と所有部署を記録した
[ ] 画像PDF・表・図面の読取品質を試した
[ ] 文書単位のアクセス権を反映できる
[ ] 登録・更新・削除の担当者を決めた
[ ] 削除が検索インデックスへ反映される

システム

[ ] 自社データでモデルを比較した
[ ] モデルとソフトウェアのライセンスを確認した
[ ] 同時利用数と応答時間を定義した
[ ] 必要なGPU・ストレージ・ネットワークを見積もった
[ ] 外部通信する接続先を棚卸しした
[ ] バックアップと復元を試した

統制

[ ] 個人単位で認証できる
[ ] 部署・役職・案件で権限を分けられる
[ ] AIの外側で権限制御している
[ ] 入力・出力・参照文書・操作を記録できる
[ ] ログ自体の閲覧権限と保存期間を決めた
[ ] 外部送信・削除・確定処理に承認がある
[ ] 権限外質問とプロンプトインジェクションを試した

運用・評価

[ ] 通常・難問・情報不足・拒否ケースを評価した
[ ] 精度、根拠、権限、速度、確認負担を測った
[ ] 採用・条件付き採用・再検証・停止基準がある
[ ] 運用管理者とデータ所有者を決めた
[ ] 障害・誤回答・事故の連絡先がある
[ ] 更新後に固定評価を再実行できる
[ ] 代替業務と利用停止手順がある

チェックが付かない項目は、すべてをPoC前に完成させる必要はありません。ただし、誰がいつ決めるかを残してください。「あとで考える」のまま本番へ進めることが最も危険です。

よくある失敗

GPUとモデルから決める

高性能な環境を作っても、対象業務と正解がなければ成果を評価できません。業務から逆算します。

全社FAQを最初のPoCにする

部署、文書、権限、質問の種類が広すぎます。1部署の承認済み文書から始めます。

正答率だけで合格にする

出典、権限、拒否、応答時間、確認負担、運用性を含めます。重大な誤りは件数ではなく影響で評価します。

文書更新と削除を設計しない

導入時のデータだけなら動きますが、数か月後に古くなります。日常運用を要件へ入れます。

オンプレだから安全だと思う

内部権限、外部通信、委託先、ソフトウェア更新、ログ、バックアップを確認します。物理的な置き場所だけでは安全性は決まりません。

よくある質問（FAQ）

Q. オンプレなら情報は絶対に外へ出ませんか？

A. 構成によります。モデル取得、認証、更新、監視、バックアップ、外部APIなどが通信する場合があります。通信先と送信内容を個別に確認してください。

Q. PoCではどの規模のモデルを選ぶべきですか？

A. 最大モデルではなく、対象業務の品質、速度、同時利用数、ハードウェア、ライセンスを満たす必要十分なモデルを選びます。複数候補を固定評価データで比べます。

Q. RAGとファインチューニングはどちらを先に使いますか？

A. 社内文書を根拠に回答し、文書更新へ追随させたい場合はRAGから検討します。出力形式や特定の振る舞いを安定させたい場合に、ファインチューニングの必要性を別途評価します。

Q. GPUを購入する前に検証できますか？

A. 可能です。検証環境や専用クラウド等でモデル、量子化、同時利用、応答時間を確認し、本番構成を見積もる方法があります。機密データの持ち込み条件は事前に確認してください。

Q. PoC期間はどのように決めますか？

A. 日数だけでなく、評価ケースの消化、現場利用、負荷試験、権限試験、改善と再試験まで実施できるかで決めます。開始前に終了条件を定義します。

Q. 正答率は何％なら本番導入できますか？

A. 一律の合格率はありません。業務リスク、誤りの重大性、人の確認、拒否性能によって基準が変わります。重要業務では平均正答率より、重大な誤りを防げるかを優先します。

Q. 専用クラウドはオンプレに含まれますか？

A. 厳密には別の構成ですが、検討現場では「自社専用・閉域・外部送信を制御できる環境」として一緒に比較されることがあります。名称ではなくデータ、通信、運用責任を確認してください。

Q. 社内にAI人材がいなくても運用できますか？

A. 外部支援を使えますが、社内の業務責任者、データ所有者、利用判断者は必要です。すべてをベンダー任せにせず、評価表と運用手順を社内へ残します。

オンプレ生成AIを自社で実装するために｜AIworkerの支援

オンプレ生成AIは、モデルを社内へ置けば完成する製品ではありません。対象業務、参照データ、権限、人の確認、本番運用までを一つの業務システムとして設計する必要があります。

AIネイティブX研修｜発注・評価・運用の共通基準を作る

情シス、DX推進、現場責任者を対象に、オンプレ生成AIの対象業務選定、データ整理、回答確認、権限、PoC評価を演習します。製品操作だけでなく、社内で要件を説明し、ベンダー提案を評価できる基準を作ります。研修後には業務定義シート、評価観点、利用ルールが残ります。

AIネイティブX伴走｜要件整理から本番移行まで一緒に直す

業務棚卸し、要件定義、評価データ作成、PoCレビュー、現場試行、運用修正、本番移行までを一緒に回します。PoC結果を受けて、データ、権限、確認工程、KPIを週次で修正します。要件定義書、評価表、運用手順、改善サイクルを社内資産として残したい会社に向く支援です。

業務AIプロ｜機密業務を1つに絞って構築する

外部送信を抑える必要がある1業務から、ローカルLLM、RAG、認証、権限、ログ、既存システム連携を個別に構築します。モデル導入だけで終わらず、例外処理、監視、バックアップ、更新、保守まで本番要件へ含めます。汎用ツールでは扱えない機密データを、複数人が同じ手順で安全に活用したい会社に向いています。

無料カウンセリングでは、対象業務、データの機密区分、現在工数、確認者、外部通信要件、PoCの評価方法、社内とベンダーの役割分担を整理します。

最後まで読んでいただきありがとうございます。励みになりますので、参考になったらスキをお願いします。

▶️ サービス資料のダウンロード（資料請求）

▶️ 無料カウンセリング・AI活用診断のご予約

#生成AI #AI #オンプレ生成AI #オンプレAI #ローカルLLM #社内AI #社内GPT #RAG #AIエージェント #AI導入 #AI活用 #生成AI活用 #業務AI #要件定義 #PoC #概念実証 #AI開発 #システム開発 #情報システム #情シス #DX #DX推進 #業務効率化 #業務自動化 #AIセキュリティ #情報セキュリティ #アクセス制御 #データガバナンス #AIガバナンス #業務改善