システム運用引継ぎの完了条件とAI試験例

2026 10/25

2026年10月8日 2026年10月25日

著者: Walkers編集部公開: 2026年10月8日最終更新: 2026年10月25日

AI支援システムの運用引継ぎでは、操作手順書の共有にとどまらず、受け手自身のアカウントで変更、停止、復旧、評価の4操作を実行し、客観的な証跡を残して判定者が確認する枠組みが実務上の目安となります。本稿で提示するすべての完了基準や試験要件は、編集部が独自に提案する受け入れ条件であり、個別の契約上の検収完了や本番稼働における完全な安全性を保証するものではありません。本稿では、社内規程問い合わせ支援の小規模な架空案件をもとに、指定環境・権限での操作仕様と、未達時の再試験管理、完了記録の構造を整理した実施前仕様を提案します。

運用の受け手・権限・隔離検証環境の前提条件

AI支援システムの引継ぎでは、運用手順書の整備や試験設計自体は先行して進められますが、受け手本人による操作試験は、担当者が正式に定まり必要な操作権限が個人アカウントに付与されてから開始します。担当者の不在や権限付与待ちが生じている段階では操作試験を実施できないため、予定日を迎えたという理由だけで試験を完了扱いにすることは避けます。また、権限不足を理由に支援側や他人の管理者アカウントを一時的に借りて受入試験を進めると、実際の運用開始後に受け手自身で作業を完結できなくなるため、必ず受け手自身の付与権限で実行します。

AIシステムを実務へ移管する準備に関して、DeploAI サービス紹介では内製化スキルの移管工程において内製担当メンバーのアサインが顧客準備事項として挙げられています。これは同社サービス説明に基づく体制例であり、本記事で提案する完了試験の合格基準を定めたものではありませんが、受け手側の担当者が事前に確定している重要性を示しています。

試験を安全に進めるため、本番環境に影響を与えない隔離検証環境、検証専用の架空データ、障害発生前の状態に戻せるバックアップデータ、そして各試験結果を確認して判定を下す担当者をあらかじめ揃えておきます。これらの前提が1つでも欠けている場合は「実施不可」として記録し、前提が整うまで該当試験を保留します。なお、本テンプレートでは障害の模擬や設定不備の注入は隔離検証環境内のみに制限し、本番環境への意図的な障害注入は行わないルールとします。

引継ぎの対象となる業務プロセスの整理や現場課題の棚卸しについては、事前にAI自動化診断を活用して自動化候補の範囲を整理できます。

受け手自身が実行する4つの運用試験仕様

運用引継ぎにおいて、受け手が指定された隔離環境・手順・権限で自立して運用できるかを確かめるため、「変更」「停止」「復旧」「評価」の4つの試験項目を設定します。すべての試験は、支援側の開発者ではなく運用の受け手自身が手順書を参照しながら操作します。ここで「証跡（ログや画面記録）」とは、誰がいつどのような操作を行い、システムがどう応答したかを第三者が後から客観的に検証できる記録を指します。以下の表は、各試験における受け手の具体的な操作、期待される結果、取得すべき証跡、判定担当者、および現在の試験状態を整理した実施前仕様です。全行ともに実施前のテンプレートであるため、試験結果および合否判定は未記入・未実施としています。

試験ID	操作区分	受け手の操作内容	期待結果	取得する証跡	判定担当と状態
TEST-01	変更	架空の新版規程データ（規程名・版・条項特定）を登録し検索インデックスを手動更新する	今回合意する対象問い合わせに適用する規程の名称・版・参照箇所が窓口画面の回答根拠に表示され、旧版が根拠に採用されないこと	更新完了ログ、画面の検索結果キャプチャ	技術確認担当＋業務受入担当（未実施・未判定）
TEST-02	停止	事前合意手順に従い推論APIの呼び出し設定を無効化する	新規回答候補の生成が停止し、手動対応案内メッセージが表示されること（既存候補や処理中要求の扱いは合意条件に従う）	API無効化ログ、窓口のエラー案内画面キャプチャ	技術確認担当＋業務受入担当（未実施・未判定）
TEST-03	復旧	架空の参照設定を破損状態に変更したうえで、受け手自身が直前バックアップをもとに設定ファイルとインデックスデータを復元する	保存版の設定に復元され、合意済みの確認ケースで回答候補と根拠が表示されること	復元完了ログ、確認ケース実行ログ	技術確認担当＋業務受入担当（未実施・未判定）
TEST-04	評価	合意済みの検証データを用いてバッチ評価スクリプトを実行する	評価レポートが出力され、合意された評価指標の意味・算定方法に基づく基準値を満たすこと	評価実行ログ、生成された精度レポートCSV	技術確認担当＋業務受入担当（未実施・未判定）

この表の判定担当は、システム基盤やインデックスの整合性を確認する「技術確認担当」と、窓口運用の影響や業務適合性を判断する「業務受入担当」の2者で分担しています。操作を実行する「運用の受け手（操作担当）」自身は合否判定を下さず、技術確認担当と業務受入担当の双方がそれぞれ個別に証跡を審査し、両者が「合格」と記録して初めて当該試験の総合合格とします。

規程の改定を反映する変更試験

変更試験では、運用の現場で発生する社内規程の改定作業を受け手自身が完了できるかを確かめます。AI検索システムでは、ファイルを配置しただけではAIが参照できず、文書を高速に検索・参照するための索引データである「検索インデックス」を更新する必要があります。試験では、隔離検証環境のストレージに対象規程の新版（規程番号、条項番号、版番号をそれぞれ明記した架空データ）を配置した上で、受け手が検索インデックス作成処理を手動で起動します。

更新完了後、窓口画面から該当の規程に関する架空の質問を入力し、あとから確認できる証跡として操作ログや実行画面の記録を残し、今回合意する対象問い合わせに適用する規程の名称・版・参照箇所が正しく回答根拠に表示されることを確認します。本試験は新版適用を想定した架空問い合わせを前提としており、旧版データ自体は履歴管理として保持されていても構いませんが、当該問い合わせの根拠として旧版が採用されないことを確認できた時点で期待結果を満たしたとみなします。

異常時に影響を抑える停止試験

停止試験では、誤った回答の頻発や外部連携の不調といった異常事態が発生した際に、受け手が迷わず生成機能を遮断できるかを確かめます。本ケースでは、AIモデルへ処理を要求する窓口である「推論API」の呼び出し設定を管理コンソールから無効化することで生成を停止させます。なお、停止手順はシステムのアーキテクチャによって異なるため、本例のAPI無効化設定がすべてのシステムに共通する停止操作を意味するわけではありません。

停止試験で確認する対象は、新規回答候補の生成停止と、手動対応を促す代替案内メッセージへの切り替えです。本システムは自動送信を行う仕様ではないため、停止操作は送信遮断ではなく回答生成の停止を目的とします。あわせて、停止操作時点で処理中だったリクエストや既存の回答候補の扱いについて、事前に合意した手順通りに制御されるかを確認します。隔離検証環境での操作許可と、本番環境での停止実行権限の移管は別個に管理します。本番環境での停止や再開に関する判断責任の所在は、FDEの役割分担表で明確にしておきます。

保存版データへ巻き戻す復旧試験

復旧試験では、データの破損や誤った設定変更が発生した想定で、受け手が安全な状態までシステムを復元できるかを検証します。この試験は本番環境ではなく、必ず隔離された検証環境でのみ実施します。

配布教材の手順仕様では、隔離検証環境において受け手自身が架空の参照設定を破損状態に変更したうえで、試験前に特定・取得しておいた直前バックアップをもとに設定ファイルとインデックスデータを保存版の状態へ復元します（なお、本番運用の組織設計として役割分離をより厳格にし、技術確認担当や支援側エンジニアが障害を事前注入する構成をとることも別設計の選択肢となります）。復旧処理の完了ログを確認した後、試験前に特定・合意しておいた定型確認ケースを入力し、正常に回答候補と根拠が表示されることを確かめて証跡とします。なお、本テンプレートで例示する復旧試験は実施前仕様であり、実際の環境での試験や復旧は未実施として定義しています。

合意済み基準に基づく評価試験

評価試験では、あらかじめ用意された合意検証データと指定環境において、受け手が定期的な精度計測手順（バッチ評価スクリプトの実行）を自力で再現できるかを確認します。「バッチ評価」とは、複数のテスト用の質問を一括でAIに入力して回答を生成させ、その出力をあらかじめ保持している正解や合意された採点方法と突き合わせて正しさを自動計算する処理です。本試験が確認するのは指定データセットに対する評価の実行手順と合意基準の充足であり、未知の入力全般や本番運用での永続的な精度を保証するものではありません。

評価指標に「適合率」や「正解率」を用いる場合、何を正例や正解とみなすのか、分母（全質問数か回答生成数か）や採点単位（文単位・参照条項単位）、採点方法を業務側と事前に定義・合意しておく必要があります。受け手は合意済みのデータを用いて評価スクリプトを実行し、得られたスコアを記録します。出力された評価レポートCSVファイルと実行ログを証跡として保存し、合意基準を満たしているかを判定者が確認します。試験前の要求抽出や判定条件の合意形成については、要件ヒアリングの整理手順を参考にしてください。

証跡ログの確認と合否判定の手順

運用の引継ぎ試験における合否判定は、操作を行った受け手本人が下すのではなく、あらかじめ定められた判断者が客観的な証跡に基づいて行います。証跡とは、操作日時、実行アカウントのユーザーID、実行した環境、設定や規程のバージョン番号、システムの処理結果が一意に特定できる電子記録を指します。

合否判定にあたっては、技術的な安全性の確認と業務上の受け入れ判断を別の責任者が分担して判定し、それぞれの観点から確認を行います。変更や復旧といったシステム基盤の整合性に関わる技術確認と、業務影響や回答品質に関わる業務受入判断の双方が揃って初めて合格と記録されます。判断者は取得されたログファイルのタイムスタンプと実行アカウントを突合し、受け手以外の特権アカウントで操作されていないことを確認した上で合否欄を記入します。

本稿が提供する配布台帳テンプレート（handover_blank/example各28列、completion_record12列、README）の実物構成を照合した枠組みでは、個別の試験状態と引継ぎ全体の完了状態をデータ上で区別して管理します。台帳CSVにおける個別の「実施状態」は「未実施」「実施中」「完了」「実施不可」の4区分、技術確認・業務受入・総合合否の各判定は「合格」「不合格」「未判定」の3区分で記録します。操作が完了して証跡を提出した直後の実務上の「判定待ち」状態は、実施状態が「完了」かつ合否が「未判定」の状態として表されます。前提条件の未達や権限不足で手順を実行できなかった場合は不合格ではなく実施状態を「実施不可」として理由を記録します。引継ぎ全体の判定はcompletion_record.csvで「合格」「不合格」「保留」「未判定」の区分を用いて管理され、全試験の個別合格や本番差分・支援体制の合意が揃わない段階では「保留」として扱います。

未達が発生したときの補完対応と再試験台帳の記録

試験を実施した結果、期待結果が得られなかったり、受け手の操作手順に誤りがあったりした場合は、未達として扱います。未達が発生した試験項目は、その場で適当に修正して完了扱いにすることは認められず、是正計画を立てて再試験を行う必要があります。

未達を記録する際は、試験管理台帳に未達の具体的な内容、それを補完するための担当者、修正の対応期限、および再試験を実施するための新規試験IDを紐付けて記入します。たとえば、TEST-01の変更試験で手順書の記載漏れにより更新が失敗した場合、補完担当者としてFDE実装担当者を指定し、手順書の改訂期限を定めた上で、再試験用の行「TEST-01-R」を台帳に新規作成します。

再試験では、補完された新しい手順書をもとに、再度受け手自身が同じ操作を一からやり直します。再試験で取得された新たな証跡とログを確認し、技術確認担当および業務受入担当の双方が合格と判定して初めて、元の未達項目が解消されたとみなします。この追跡記録を台帳に残すことで、どの不備がどのように解決されたのかを後から確認できるようになります。

運用引継ぎ完了の判定基準と契約検収との区別

隔離検証環境での試験に合格したことと、本番環境での安全な稼働が保証されることは同義ではありません。隔離環境と本番環境の間には、インフラ構成、付与権限、監視体制などの差分が存在するためです。なお、ここで提示する引継ぎ完了の判定基準はすべて編集部が提案する実務上の条件であり、必須項目の未達、本番差分の未確認、担当や連絡経路の未確定がある場合は「保留」として完了にはしません。運用引継ぎの完了を判断するためには、以下の条件を満たす必要があります。

運用引継ぎ完了判定フローと再試験の分岐

引継ぎ開始時 前提条件の確認 受け手のアカウント権限、隔離検証環境、バックアップ、評価データが揃っているか確認。不足時は「実施不可」として保留。
前提充足後 受け手による4試験の実行 運用の受け手自身が手順書を参照し、変更・停止・復旧・評価の操作を実行して客観的な証跡（ログ・画面）を取得。
操作完了後 技術・業務の証跡審査 技術確認担当と業務受入担当がそれぞれ証跡を突合審査。いずれか未達の場合は再試験台帳（TEST-xx-R）へ回流。
審査未達時 補完対応と再試験 是正担当と期限を定めて手順書や環境を修正し、新規試験IDを発行して受け手自身が一から再試験を実施。
全試験合格後 本番差分と残存支援の確認 隔離環境と本番の構成・権限・監視の差分確認と、残存外部支援の窓口・範囲を確定。未確定事項があれば「保留」。
全要件合意後 運用引継ぎ完了記録 両担当がcompletion_record.csvに最終合格を記録し運用引継ぎ完了（※契約検収手続きとは別個に管理）。

前提不足時は「実施不可」、審査未達時は再試験へ戻ります。個別試験の合格後でも本番差分や支援体制が未確定の場合は全体判定が「保留」となります。

定められた全試験項目で受け手自身による操作が行われ、技術・業務双方の合格証跡が揃っていること
発生したすべての未達項目に対して補完対応が完了し、再試験によって解消が確認されていること
隔離検証環境と本番環境における構成・権限・監視の差分が特定され、受け入れ方針が合意されていること（未確認の差分がある場合は保留）
引継ぎ後に合意のうえ許容する残存外部支援の担当範囲・連絡経路と、対処が必要な未解決事項とが明確に区別・確定されていること
技術確認担当および業務受入担当の双方が、完了記録（completion_record.csv）に最終判定を記録していること

これらの条件が揃わない限り、引継ぎ完了とはみなしません。また、本編集部提案の完了条件は現場運用の受け入れ可否を整理する実務的な基準であり、契約上の検収完了を法的に意味するものではありません。実装後の定着運用まで外部に委ねるか自社で引き継ぐかは、AI導入の頼み方4類型を比較を基準に契約前の段階で方針を定めます。

試験台帳および引継ぎ完了記録のフォーマットは、以下の配布ファイルから入手できます。配布ZIPにはREADME、handover_blank.csv/handover_example.csv（各28列、架空例4行）、completion_record.csv（12列、架空例2行）が格納されています。初期状態として各試験の日時・実行者は未記入、実施状態は「未実施」、証跡未取得、合否は「未判定」であり、完了記録判定はいずれも「保留」として定義された実施前ひな型です。

運用引継ぎ試験台帳テンプレート（ZIP）のダウンロード