生成 AI を業務に導入する際、外部ベンダーに開発や評価を依頼することは合理的な選択です。一方、モデルの出力をどの業務に使い、どの条件を満たせば本番で採用するかは、利用企業が決める必要があります。
例えば、問い合わせ対応で AI が回答候補を生成できたとしても、それを担当者の下書きにするか、顧客へ自動送信するかで、必要な品質と責任の範囲は変わります。生成機能を実装できることと、その運用を許可できることは別の判断です。
本稿では、実装作業は外部に委託し、業務上の合否基準と採用判断は自社で保持する という考え方を、問い合わせ回答支援システムの要求定義から受け入れ判定までに当てはめます。特定の製品やプログラミング言語を前提とせず、システム開発の発注側と受注側が確認できる条件を整理します。
生成 AI の導入対象を業務単位で定義する
架空の企業が、顧客からの問い合わせに対する回答案を AI で作成し、担当者の確認後に返信する仕組みを導入するとします。
最初に定義するのは、AI の機能一覧よりも業務上の適用範囲です。
| 問い合わせの種類 | AI に許可する役割 | 業務上の最終判断 |
|---|---|---|
| 営業時間や手続きの案内 | 承認済み資料から回答案を作成する | 担当者が内容を確認して送信する |
| 契約条件に関する質問 | 関連資料を提示し、回答案を作成する | 担当者が契約内容を確認して回答を確定する |
| 返金の例外申請 | 規程と申請内容を整理して担当部署へ引き継ぐ | 権限を持つ担当者が返金可否を決定する |
| 権限外の顧客情報を求める質問 | システム側のアクセス制御で許可された情報だけを回答案に使用する | 情報の開示可否は社内規程に従う |
この例では、AI は回答案の作成を担い、顧客への送信と例外的な返金判断は人間が担当します。業務範囲を先に定めれば、ベンダーへの依頼内容も「問い合わせに回答できる AI」から「許可された資料で回答案を作成し、判断を要する案件は担当者へ引き継ぐシステム」へ具体化できます。
対象業務、使用できる資料、承認者、例外時の引き継ぎ先が要求定義書に記載されていることを、業務責任者と開発担当者で確認します。
技術的に実現できることと業務で許可することを分ける
AI に顧客向けの文章を生成させる機能と、その文章を顧客へ送信する機能は、技術的には接続できます。しかし、送信まで自動化するかは別の承認事項です。
例えば、ベンダーが自動回答機能を提案した場合、利用企業は次の観点で採用を判断します。
| 技術的な実現可能性 | 業務側で定義する条件 |
|---|---|
| 回答候補を生成できる | 対象となる問い合わせの種類が明示されている |
| 社内文書を検索できる | 参照を許可する資料と利用者権限が定められている |
| 回答を自動送信できる | 自動送信の対象と承認省略の条件が承認されている |
| 応答時間を短縮できる | 確認・修正を含む業務全体の処理時間が評価されている |
NIST の Artificial Intelligence Risk Management Framework（AI RMF 1.0）は、AI の設計、開発、利用、評価を通じてリスクを管理するための任意利用の枠組みです[1]。モデル単体の性能に加え、使用目的や利用状況を含めて評価する考え方を参照できます。
技術検証で回答生成が成功したという報告は、機能が成立することの証拠です。本番運用の承認には、業務範囲、権限、例外処理、確認手順に関する証拠も必要になります。
外部ベンダーへ委託する作業と社内で決める事項を分ける
委託範囲を決める際は、作業の実施者と判断の決定者を別々に記載します。外部ベンダーは評価方法や運用設計を提案できますが、その提案を業務要件として採用するかは利用企業が決定します。
| 項目 | 外部ベンダーへ依頼できる作業 | 利用企業が決める事項 | 確認できる成果物 |
|---|---|---|---|
| 導入対象 | 現行業務の分析、候補業務の提案 | 自動化の対象と除外範囲 | 業務範囲定義 |
| 品質評価 | 評価データの整備支援、試験の実施 | 合否条件と許容する誤り | 受け入れ基準、試験結果 |
| 権限制御 | 認証・認可と参照制御の実装 | 情報ごとの閲覧権限 | 権限表、アクセス試験結果 |
| 承認処理 | 確認画面、承認履歴の実装 | 承認を必須とする操作と承認者 | 業務フロー、承認記録 |
| 本番移行 | 検証結果の報告、切り戻し準備 | 残存リスクの受容と移行の可否 | 判定記録、移行計画 |
| ベンダー変更 | データ出力、移行手順の整備 | 移行時も維持すべき業務要件 | 引き継ぎ資料、再評価用データ |
ISO/IEC 42001:2023 は、AI を提供または利用する組織が AI マネジメントシステムを確立し、維持し、継続的に改善するための要求事項を定めた国際規格です[2]。本稿の表はその規格で指定された役割分担表ではなく、導入プロジェクトで判断主体を明示するための設計例です。
この分担は、委託先の実装品質や契約上の責任を免除する意味ではありません。委託契約上の責任と、利用企業内で業務判断を承認する権限は区別して取り扱います。
モデル性能と業務上の受け入れ基準を分けて定義する
回答精度や応答時間は必要な評価指標です。ただし、問い合わせ対応では、AI が回答を作る時間だけでなく、担当者の確認と修正、例外案件の引き継ぎまで含めて評価します。
例えば、業務全体の処理時間は、次の作業を分けて記録できます。
- AI による回答案の作成時間
- 担当者による根拠確認と承認の時間
- 誤回答の修正や追加調査に要する時間
- 例外案件を別部署へ引き継ぐ時間
回答生成が短時間で終了しても、確認や修正の作業が増えれば、業務全体の時間短縮は限定されます。平均処理時間を比較する際には、AI 利用前後で対象となる問い合わせの種類や難易度をそろえる必要があります。
受け入れ基準は、次のように対象、期待動作、判定者を組み合わせて記述します。
| 評価対象 | 受け入れ条件の例 | 判定者 |
|---|---|---|
| 定型回答 | 回答案の内容が承認済み資料と整合し、参照根拠を確認できる | 業務担当者 |
| 例外判断 | 返金可否を AI が確定せず、権限を持つ担当者へ引き継ぐ | 業務責任者 |
| 情報アクセス | 権限外の資料とその内容が回答に現れない | 情報管理担当者 |
| 承認履歴 | 誰がどの回答案を確認・承認したか追跡できる | 運用責任者 |
| 業務時間 | 回答案の生成から送信までの処理時間が、事前に設定した目標を満たす | 業務責任者 |
これらは受け入れ基準の書き方を示した例であり、実際の試験結果ではありません。合格率、許容時間、評価件数などの数値は、問い合わせの重要度と業務上の損失を考慮して案件ごとに決めます。重大な情報漏洩や権限外操作のように件数だけでは扱いにくい失敗については、許容条件と発生時の対応を個別に定義します。
NIST の Generative Artificial Intelligence Profile は、生成 AI に固有のリスクと、それぞれの組織の目的や優先事項に応じた管理策を整理しています[3]。受け入れ基準を単一の精度指標に集約せず、出力の誤り、情報保護、利用者の過信などを業務用途に応じて評価する際の参考になります。
通常ケースと例外ケースで受け入れ条件を検証する
委託先が実施した試験を受け入れるには、試験入力だけでなく、期待結果と判定根拠を利用企業が確認できる状態にします。以下は、問い合わせ回答支援に対する試験仕様の例です。
| 試験 ID | 入力条件 | 期待結果 | 不合格とする条件 |
|---|---|---|---|
| T-01 | 承認済み資料に回答が載っている定型質問 | 該当資料に沿った回答案を作成し、担当者の確認へ送る | 根拠資料と異なる条件を付け加える |
| T-02 | 社内規程に個別審査が必要と記載された返金申請 | 規程と申請内容を整理し、担当者の判断を求める | AI が返金可否を確定して顧客へ送信する |
| T-03 | 閲覧権限のない顧客情報を求める質問 | 許可外情報を参照・出力せず、権限に応じた処理を行う | 権限外資料の内容や一部を回答に含める |
試験時には、入力文に加えて参照資料の版、利用者の権限、使用したモデルや設定、実際の回答、承認経路を記録します。T-03 は権限の異なる利用者で実施し、検索結果と生成回答の双方を検査します。
受け入れ判定では、まず委託先が試験を実施して結果を提出し、利用企業の担当者が業務規程と照合します。失敗が出た場合は、実装修正の対象なのか、適用範囲や業務規程の見直しが必要なのかを切り分けます。最後に業務責任者が定められた承認手順に従って本番移行の可否を判断します。
この検証は特定のモデルが常に同じ出力を返すことを保証するものではありません。試験で確認した対象範囲、入力分布、設定、判定結果を記録し、その範囲で得られた証拠として扱います。
ベンダー変更後も判断基準を維持できるようにする
導入時に評価基準をベンダー側だけで管理していると、モデルや委託先を変更する際に、以前の採用判断を再現することが難しくなります。例えば、合格と判定したテストの入力条件や評価理由が残っていなければ、新しいモデルとの比較条件が失われます。
次の情報を、利用企業が参照・更新・引き継ぎできる状態にしておきます。
| 保持する情報 | ベンダー変更時の用途 |
|---|---|
| 対象業務と適用除外 | 新しい実装にも同じ業務境界を指定する |
| 参照資料と利用権限の定義 | 情報アクセスの条件を再設定する |
| 受け入れ基準と試験入力 | 移行前後の合否を同じ条件で比較する |
| 承認条件と業務フロー | 自動化範囲と人間の判断箇所を維持する |
| 既知の失敗と対応履歴 | 移行時に過去の問題を再検査する |
保持とは、すべてを自社のサーバーへ保存することだけを意味しません。外部の管理基盤を利用する場合でも、必要な情報を取り出し、評価を引き継ぎ、業務上の採用判断を行えることが条件です。
生成 AI の競争がモデル提供から業務実装へ広がるほど、利用企業は実装面で外部の専門性を活用できます。一方、業務範囲、リスク許容、評価基準まで委託先に依存すると、変更時に自社で採用可否を判断するための根拠が失われます。この区別は、企業向け AI の業務実装を論じた記事でも扱われています[4]。
導入後に判断基準を見直す条件を決める
本番移行時の合格判定は、その時点の業務とシステム構成を前提とします。運用中に前提が変われば、評価も更新します。
| 変更・事象 | 再確認する内容 | 判断主体 |
|---|---|---|
| モデルや推論設定の変更 | 回答品質、例外処理、応答時間 | 業務責任者と技術担当者 |
| 参照資料や契約条件の変更 | 回答根拠、適用範囲、承認要否 | 業務担当者 |
| 利用者権限の変更 | 参照制限、監査記録 | 情報管理担当者 |
| 重大な誤回答や情報漏洩の疑い | 影響範囲、利用停止条件、再開条件 | 業務・情報管理の責任者 |
| 外部ベンダーや実行基盤の変更 | 既存の受け入れ条件が維持されるか | 利用企業の受け入れ責任者 |
変更が発生した場合に必要な再試験と承認の範囲は、業務リスクに応じて事前に決めます。例えば、回答文の体裁だけに関わる変更と、参照権限を変える変更とでは、確認すべき条件が異なります。障害時の停止・再開権限も同じ手順に含めます。
まとめ
生成 AI の導入では、モデルの選定、既存システムへの接続、評価環境の整備を外部ベンダーに委託できます。その専門性を活用することで、利用企業は実装作業を効率的に進められます。
ただし、何を自動化するか、どの失敗を許容するか、何を合格とするか、誰が本番利用を承認するか は、業務に責任を持つ組織が定める事項です。
発注時には判断事項と実装作業を分け、受け入れ時には期待結果と判定者を明示し、運用時には同じ基準で再評価できる状態を維持します。こうしておけば、実装担当者や利用モデルが変わっても、採用判断の根拠を自社で説明できます。
参考文献
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)（2023-01-26）. https://www.nist.gov/itl/ai-risk-management-framework
- ISO, ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system（2023-12-18）. https://www.iso.org/standard/42001
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile（2024-07-26）. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/