試用版が本番化する前に確認する、AI利用開始・切替判定表

AIの検証を急ぐと、まず少人数に試用環境を配り、使い方は後から考える流れになりがちです。しかし現場は、便利だと感じた時点から会話履歴、個人用の定型指示、プロジェクト設定、参照資料、外部連携の設定を仕事に組み込みます。担当者にとっては、それらも業務を進めるための資産です。環境を切り替える日に初めて棚卸しをすると、何を失うのか、何を作り直すのかが分からず、利用が止まりやすくなります。

AWSとNECの公表記事では、2026年5月時点のClaude Enterpriseを契約する方式とAmazon Bedrockに接続する方式の間で、会話履歴、メモリ、プロジェクト設定を引き継ぐ仕組みはないと説明されています。スキルはファイルとして移植できる一方、一括取得の手段や、有効化していた状態の引き継ぎには制約があり、人手による再構築が必要になるとされています。 [1]

ここでの目的は、試用を遅らせることではありません。試用中に何が蓄積されるかを先に見える化し、「この環境のまま継続するのか」「切替前に再設定するのか」「そもそも保存を認めないのか」を対象業務ごとに決めることです。試用開始の承認と、本番利用の承認を別の判断として扱いましょう。

利用開始前の確認では、AIが正しい回答を出すかだけに集中しないことを勧めます。あわせて、利用者がAI内または周辺サービスに何を作成・保存するかを書き出します。対象は、会話履歴、メモリ、プロジェクト、定型指示、アップロード資料、ナレッジ、接続先、権限設定、共有設定です。業務の成果物ではなくても、日々の作業を再現する条件になっているものを含めます。

棚卸しは「保存されるもの」と「毎回入力するもの」に分けると実務で使えます。毎回入力する依頼文は、業務手順カードや共有文書へ退避できる場合があります。一方で、会話の文脈、利用者だけが調整した設定、個別に接続した外部サービスは、同じ状態を別環境で再現できるかを個別に確認する必要があります。

例：人事部が面接後の評価メモを要約する業務では、面接評価の原文、要約用の定型指示、評価観点を記した参照資料、出力を確認する採用責任者、保存先を分けて記入します。「要約文が作れるか」だけでなく、試用終了日に誰が設定と資料を回収・削除・再登録するかまで決めます。

移行可否の欄は「可能」と一言で終わらせず、「確認済み」「未確認」「不可」の三つで記録することを勧めます。確認済みには、確認日、確認した担当者、確認方法、対象となる設定の範囲を残します。ベンダー資料で確認したのか、管理画面でエクスポートとインポートを試したのか、実機で再現試験をしたのかによって、判断の確かさが異なるためです。

特に注意したいのは、「データを取り出せる」ことと「業務を同じように再開できる」ことを混同するケースです。ファイルを保存できても、登録順、権限、共有範囲、参照先、定型指示の適用条件が再現されなければ、利用者は従来と同じ手順で仕事を再開できません。切替確認では、対象者以外の担当者にも同じ業務を実行してもらい、必要な設定が揃うかを確認しましょう。

AWSとNECの公表記事で紹介されたNECの事例では、2026年5〜6月時点のClaude Desktop on Amazon Bedrockと接続先SaaSのMCPおよびOAuth実装に差異がありました。そのため、接続先ごとに、接続が成立することと期待どおりに動作することをそれぞれ確認する必要があったと記されています。移行や連携の判断でも、接続可否だけを合格条件にせず、対象業務の最後まで完了するかを確認対象にします。 [1]

試用には必ず終了日を設けます。期限がなければ、検証用の環境が事実上の本番となり、後から切替を提案しにくくなります。終了日は利用者を締め出すためではなく、継続、切替、終了を判定する日です。開始時に通知し、終了の1〜2週間前には、蓄積物の棚卸しと移行試験を行う予定を利用者へ伝えます。

本番へ進む条件は、少なくとも四つに分けます。第一に、対象業務と利用者が特定されていること。第二に、入力してよい情報と保存先が確認されていること。第三に、設定・資料・連携の移行可否または再設定手順が記録されていること。第四に、業務側と情報システム側の確認者が切替後の再現を確認することです。条件が未達なら、利用を広げるのではなく、対象業務を限定して追加確認する判断ができます。

利用開始判定を情報システム部門だけで完結させないことを勧めます。情報システム側の確認者は、認証、権限、保存、ログ、接続、削除手順などの環境条件を確認します。業務側の確認者は、必要な資料と設定がそろい、担当者が対象業務を再開でき、出力の確認手順が維持されるかを確認します。両者が同じ欄に署名するのではなく、担当範囲を分けて記録します。

切替当日は、利用者全員に再設定を任せないようにします。情報システム担当は、配布する初期設定、利用停止の時刻、問い合わせ窓口を案内します。業務責任者は、優先度の高い業務から再開試験を依頼し、使えない設定や資料を集約します。利用者は、個別の工夫を抱え込まず、再現できなかった手順を判定表へ返します。この分担により、問題を個人の習熟不足として処理しにくくなります。

移行の確認は、全利用者を対象にしなくても始められます。対象業務ごとに、実際に使う担当者、業務責任者、情報システム担当の三者で小さな切替演習を行います。試用環境で作った定型指示や参照資料を一覧化し、本番候補環境で必要なものを再設定します。その後、別の担当者が同じ業務を実行し、開始から確認まで進められるかを確かめます。

演習で見つかった問題は、「移行できなかったもの」「再設定に時間がかかったもの」「誰の判断待ちになったもの」に分けます。前二者は手順書や初期配布設定の改善対象です。最後の一つは担当分担の不足です。次の試用では、判断者と回答期限を判定表に追加します。利用件数の増加だけを成功指標にせず、切替後に対象業務を再開できたかを観測項目に加えると、環境選定と定着支援をつなげられます。

判定表は一度の導入審査で捨てず、環境変更、プラン変更、連携追加、担当交代のたびに更新する台帳として扱いましょう。AIの利用方法は、現場の工夫によって変化します。最初は会話だけだった業務でも、共有資料、プロジェクト、外部連携が増えれば、切替時に守るべき資産も変わります。月次または変更申請時に、対象業務と蓄積物の欄だけでも見直します。

重要なのは、試用の速さと本番化の判断を混ぜないことです。すぐに触れる環境を用意することは有効でも、利用者が作る資産の扱いを未確認のまま利用範囲を広げる必要はありません。業務、情報、設定、確認者、終了日を一枚に置き、切替が起きる前に再開可能性を確かめる。その運用が、試用環境を意図せず本番化させない土台になります。

AI利用開始・切替判定表

• 対象業務：＿＿＿＿＿＿＿＿＿＿　業務責任者：＿＿＿＿＿＿＿＿＿＿
• 対象利用者・利用人数：＿＿＿＿＿＿＿＿＿＿　試用開始日：＿＿＿＿＿＿＿＿＿＿
• AI内または周辺に作成・保存するもの（会話履歴／プロジェクト／定型指示／参照資料／連携設定）：＿＿＿＿＿＿＿＿＿＿
• 各項目の保存先・保持期間・共有範囲：＿＿＿＿＿＿＿＿＿＿
• 別環境への移行可否（確認済み／未確認／不可）と確認方法・確認日：＿＿＿＿＿＿＿＿＿＿
• 切替時の再設定作業、担当者、完了確認方法：＿＿＿＿＿＿＿＿＿＿
• 業務側の確認者：＿＿＿＿＿＿＿＿＿＿　情報システム側の確認者：＿＿＿＿＿＿＿＿＿＿
• 試用終了日：＿＿＿＿＿＿＿＿＿＿　本番利用へ進む条件／進まない場合の削除・周知手順：＿＿＿＿＿＿＿＿＿＿

出典・参考資料

1. AWS / NEC（確認日：2026-10-21）
2. AI coach株式会社（確認日：2026-10-21）