AI導入の進め方：試験運用から本格展開までの90日ロードマップ

AI導入では、対象を絞った一つの業務フローについて、90日の評価期間内に改善効果を測定できる状態を目指します。責任者を明確にし、問題が起きても業務を続けられる代替手段を用意することが前提です。まず業務を定め、必要なデータとアクセス権を確保し、実現方法を選びます。そのうえで、現行業務と比較する試験運用によって効果を確かめ、展開範囲を広げていきます。期限は次の判断を下すための区切りです。確認項目を満たしていない業務フローを、期限に合わせて本番投入する理由にはなりません。

AI導入とは何をすることですか？

AI導入とは、承認されたユースケースを、現場で運用し、効果を測り、維持できる業務プロセスにする取り組みです。動作するモデルは、その一部にすぎません。利用が認められたデータ、既存業務との連携、訓練を受けた確認担当者、不具合への対処、そして稼働後の責任者まで必要です。

試験運用は、舞台の通し稽古に似ています。見栄えのよい場面ができても、演出家がせりふを一つずつ教えなければ成り立たないなら、本番への備えができたとはいえません。構築担当者が隣にいなくても、普段の利用者が業務を完了し、問題から復旧できること。それが展開範囲を広げる条件です。

MicrosoftのAI導入ガイドも、事前準備、人材、モニタリングを導入の一部として扱っています。実務上、区別すべきなのは、AIから回答を得ることと、プロセス全体を通じて業務の合格基準を満たす成果を得ることです。

事業上の目的がまだ決まっていない場合は、AI戦略ガイドで整理してください。目的に合意できたら、次に示すべきものは、特定の業務フローが機能するという証拠です。

出典のガイドは2026年10月28日に確認しました。以下の日程と合格条件は、運用方法の提案です。計算例の数値は仮定であり、実際の導入成果ではありません。

AI導入のロードマップ：90日で進める七つのステップ

日程は、判断を先送りせず、前提となる作業を明らかにするために使います。次の段階へ進むのは、十分な根拠がそろってからです。必要なら対象業務を狭めたり、試験運用を延長したりします。

ここで提案する進め方は、既存システムと利用可能なAI機能を使い、対象を絞った業務フローに取り組むことを前提としています。大規模なデータ整備、新たなモデルの学習、影響の大きいシステムの承認まで、同じ期間内に終えられるという約束ではありません。対象業務が決まったら、データアクセス、調達、専門担当者による審査の手配を始めてください。

一人が複数の役割を兼ねても構いません。ただし、それぞれの責任に担当者名を紐づけ、必要な時間と権限を確保します。運用責任者の候補は開始時点で決めておきます。最後のステップは、その人が実際に引き継げることを確認する場です。

1. 完了条件が明確な業務を選ぶ

入力情報、合格とみなせる出力、業務責任者が特定できる、繰り返し発生する作業を選びます。最初の対象は、内容を点検できる規模に収まり、試験運用中に判断材料が集まる程度の頻度があるものが適しています。

カスタマーサポートの責任者にとって、「AIで顧客対応を改善する」では範囲が広すぎます。たとえば、承認済みのヘルプ記事を使い、よくある製品質問への回答案を作成して、担当者の確認に回すという範囲なら実行可能です。返金の判断、アカウント情報の変更、契約上の約束、返信の送信は対象に含めません。

変更に着手する前に、実際の案件が現在の業務をどう流れるかを追います。作業のきっかけ、必要な情報、実施した処理、引き継ぎ、完了と判断する時点を記録してください。情報不足で対応が止まっているなら、回答案の作成を速くしても、主な待ち時間は減らないかもしれません。

次の項目を、簡潔な業務定義書にまとめます。

• **開始と完了：**何をきっかけに作業が始まり、どの状態になれば合格とするか。
• **対象案件：**どの依頼を試験運用に回し、どれを現行業務で処理するか。
• **権限：**AIが何を読み、提案し、変更してよいか。何に人の判断が必要か。
• **合格条件：**問題のない出力、修正すれば使える出力、使えない出力を、確認担当者がどう判定するか。
• **責任分担：**成果が改善したかを誰が判断し、例外に誰が対処するか。

サポートの回答案なら、正しい案内、案件に適用できる出典、根拠のない約束を含まないこと、情報源で答えられない場合の適切なエスカレーションなどが評価基準になります。文章が丁寧でも、アカウントに適用する規定を間違えていれば合格にはできません。

**注意すべき失敗：**魅力的なデモを見るたびに対象業務が増え、回答案を作るはずのアシスタントが、いつの間にか紛争解決や記録更新の権限まで持ってしまいます。

**見抜くための確認：**最近のさまざまな案件を使い、業務責任者と現場担当者が、それぞれ独立して対象内か対象外かを判定します。判断の違いは開発前に解消してください。システムに何を任せるかで合意できないなら、対象範囲の定義はまだ不十分です。

AI導入の例：役に立つ最小限の範囲から始める

サービス事業の創業者なら、共有前にアクション項目を確認する社内会議の要約から始められます。経理担当者なら、支払い承認を切り離したまま、請求書の項目を抽出する方法があります。一人で開発する技術者なら、自ら次の行動を選んで実行するエージェントに取り組む前に、届いた依頼を既存の処理キューへ振り分けるところから始められます。

これらは設計の候補であり、特定の製品なら確実に実行できるという主張ではありません。検証材料を入手でき、失敗しても元に戻せて、何が「正しい」かを確認担当者が説明できる候補を優先します。既存のルールベースの処理で十分に対応できているなら、その仕組みを維持してください。

2. モデルをつなぐ前に、データとアクセス権を検証する

必要な情報を、対象業務で利用でき、利用も認められている状態にします。限定した業務を試すために、社内の全データを整備する必要はありません。ただし、その業務で信頼してよい情報源は把握する必要があります。

サポートの例では、承認済みのヘルプ記事群、各規定の管理責任者、記事を現行版または廃止扱いにする手順を特定します。過去の返信が対応済みのチケットに残っているからといって、正しい根拠として扱ってはいけません。その場限りの例外、失効した規定、他人の個人情報が含まれている可能性があります。

選んだ情報源について、データとアクセス権の管理台帳を作ります。保管場所、管理責任者、認められた利用目的、アクセス可能な利用者グループ、情報の鮮度要件、保存期間のルール、アクセス権を削除する方法を記録してください。検索インデックス、キャッシュ、ログに情報を複製するなら、その保存先も含めます。

次に、実際の依頼を想定した経路に通してみます。アプリケーションは、該当する承認済み記事を取得できるでしょうか。現行の規定と旧版を区別できるでしょうか。確認担当者は、回答案の妥当性を判断するのに十分な出典の文脈を確認できるでしょうか。情報源が見つからない場合や、内容が矛盾する場合には、どう動くでしょうか。

IBMのAI導入ガイドは、データの品質とアクセス可能性を、明確な導入ステップとして扱っています。管理者によるデモで済ませず、業務で実際に使うアカウントと文書をテストして、このステップを具体化します。

生成AIの導入：アクセス制御をプロンプト任せにしない

生成AIは、回答案などのコンテンツを生成します。関連文書を渡せば、生成時に使う材料になります。ただし、どの文書を渡してよいかを制御する必要がなくなるわけではありません。

アクセス権は、アプリケーションとストレージの権限設定で強制します。「機密情報を開示しないでください」という指示は、権限のない情報取得を防ぐ仕組みの代わりにはなりません。回答案を作る業務フローには、必要な操作だけを許可し、送信に関する制約はアプリケーション側で守らせます。

**注意すべき失敗：**高い権限を持つアカウントではデモが動く一方、一般の利用者には不完全な回答が返ったり、本来閲覧できない情報を取得できたりします。

**見抜くための確認：**アクセスを許可された利用者と、拒否されるべき利用者の両方でテストします。後者には見せてはいけない、テスト用に承認された文書を使い、情報取得の経路全体で文書の削除やアクセス権の取り消しも試してください。派生した保存先や既存のセッションについても、定めたとおりに動くか確認します。一度のテスト合格で分かるのは、そのケースでの挙動です。あらゆる条件での安全性が証明されたわけではありません。

管理責任、利用許可、利用可能なデータに未解決の点がある場合は、AI導入準備の評価ガイドを使い、残る作業の担当を決めます。アクセスの準備が整うまでは、許可されたサンプル資料だけで試験運用を進めてください。

3. 購入・設定調整・独自開発を、共通のテストで選ぶ

業務の合格条件、アクセス要件、運用要件を満たすなかで、最もシンプルな実現方法を選びます。導入方法を決める前に、自社の案件と制約を使って候補を比較してください。

AI導入の方法を選ぶための判断基準

**既存製品が業務に合い、その制御機能も確認に合格するなら、購入します。**サポート業務なら、実際の情報源への接続、確認作業のしやすさ、権限、処理結果の記録、代替手段まで検証します。欠点は、ベンダー側の仕様や、用意された設定項目に依存することです。営業資料に機能名が載っているだけでは、自社の業務に適している証拠にはなりません。

**製品の基本機能は適していても、承認された業務に合わせる必要があるなら、設定を調整します。**指示、情報源の選び方、振り分けルール、確認手順などを調整する方法です。不要な独自開発を避けられますが、設定も保守が必要なロジックです。バージョンを管理し、変更をテストし、情報源への接続を維持する担当者が必要です。

**必須要件を満たせず、完成後のシステムに責任を持てるなら、独自開発します。**独特な承認経路や特殊なシステム連携が必要なら、開発する理由になります。業務フローを開発することは、必ずしもモデルを学習させることではありません。既存のモデルサービスの周囲に、権限、検索・取得、確認、ログ記録の仕組みを作る場合もあります。その代わり、連携の不具合、アップグレード、サポートへの責任を負います。

Anthropicのエージェント構築ガイドは、効果を得られる最もシンプルな方法から始め、必要性がある場合に複雑さを加えることを勧めています。導入方法にも同じ原則を当てはめます。回答案を作り、人が確認するという定まった流れで済むなら、モデル自身に作業手順を考えさせる必要はありません。

絞り込んだ候補には、同じ利用許可済みのサンプル案件、出力の評価基準、必要な制御要件を与えます。扱いにくい入力、利用できない情報源、一般利用者の権限、サービス障害もテストに含めてください。契約や利用関係が終わった場合に、必要な記録をどう取り出し、業務をどう続けるかも確認します。

導入支援パートナーに依頼するなら、文書化や引き継ぎとともに、これらの検証も契約上の成果物にします。パートナーは導入に必要な実行力を補えますが、成果を受け入れ、その後の業務を担う責任者は、自社に必要です。

**注意すべき失敗：**完成度の高いデモが決め手となり、契約後に連携やアクセスの要件を満たせないと判明します。

**見抜くための確認：**権限のある依頼の受け付けから、確認済みの成果が得られるところまで、最小限でも一連の動作を実演してもらいます。復旧可能な失敗も含め、すべての候補を同じ基準で評価してください。未解決の要件は明記します。生成文が優れていても、重大な要件が欠ける候補を合格にはできません。

4. 現状の測定値と比較する試験運用を行う

試験運用で確かめるのは、定めた条件のもとで、提案した業務フローが仕事を改善するかどうかです。比較対象となる業務プロセス、実態を代表する案件、そして結果を見る前に合意した合格基準が必要です。

データの準備や導入方法の検討を進めている段階から、現行業務の記録を始めます。ベースラインとは、試験運用と同じ定義で測った現行業務の値です。Google Cloudの効果測定ガイドも、開始前にベースラインを確立し、測定方法を設計することを勧めています。

サポートの回答案作成なら、返信が合格と認められるまでの実作業時間、完了までの経過時間、評価基準に照らした品質、エスカレーションの理由を記録します。実作業時間には、読む、確認する、編集する、誤りを修正するといった作業を含めます。経過時間には待ち時間も含まれるため、モデルが速くなっても、顧客への返信は遅くなる場合があります。

比較方法は、業務に合わせて選びます。可能なら、条件の近い対象案件を、現行業務で処理する群とAIを利用する群に無作為に割り当てます。同じ顧客とのやり取りのように案件同士が影響し合う場合は、関連する案件を同じ群にまとめてください。導入前後で比較せざるを得ない場合は、人員配置、業務量、依頼内容の構成の変化を記録します。こうした変化があると、結果をどこまでAIの効果とみなせるかが限られます。

業務フローの調整に使う事例と、評価に使う案件は分けます。ホールドアウトセットとは、調整時に繰り返し使わず、評価用に取り置く案件のことです。通常の依頼に加え、情報不足、情報源同士の矛盾、普段と異なる言い回し、承認済みの資料では答えられない質問など、難しい案件も含めてください。

試験運用は、管理された順序で進めます。

1. 1

   利用が認められた過去の案件で再現する

   実際の業務に作用する操作をせず、候補の仕組みを過去の案件に適用します。業務に詳しい確認担当者が評価基準に沿って判定してください。取得した根拠は案件に適していたか、回答案は根拠を正しく使っていたか、裏付けられない依頼に対して適切に回答を控えるかエスカレーションしたかを確認します。

2. 2

   業務結果を変えずに、本番の入力で挙動を見る

   シャドーモードでは、候補の仕組みに利用が認められた実際の業務を処理させつつ、最終的な結果は引き続き現行業務が担います。不足する入力、処理の遅延、利用できない依存先、想定外の案件種別を探します。シャドーモードでも、適切なデータ利用の許可は必要です。

3. 3

   対象を絞った利用者グループに支援機能を提供する

   訓練を受けた担当者が、合意済みの範囲で候補の仕組みを使います。顧客への返信には、引き続き人の承認を必須とします。利用を試みた案件、利用しなかった案件、不具合、確認、修正、最終結果を記録してください。結果を調査できるよう、設定や情報源のバージョン情報も残します。

支援機能を使い始める前に、判断ルールを合意します。必要な品質、許容できる作業時間、遅延の許容上限、発生したら直ちに業務フローを停止する不具合を決めてください。この回答案作成のみの例では、権限のない情報開示や、未承認の送信が起きたら、停止して調査します。重大な不具合を平均スコアの中に埋もれさせてはいけません。

**注意すべき失敗：**積極的な利用者が簡単な案件だけを選び、構築担当者が裏で誤りを直し、成功した回答案だけが報告に載ります。

**見抜くための確認：**対象案件を一件残らず試験運用のログと照合します。AIを使わなかった案件や、処理に失敗した案件も含めてください。構築担当者による支援も作業として記録します。評価の進め方と判定のサンプルは、構築担当者以外の人が確認します。

あらゆるAI業務フローの安全性を保証する、共通のサンプル数や精度目標はありません。案件のばらつき、誤りの重大さ、判断に必要な精密さから、どの程度の根拠が必要かを決めます。件数の少ない業務で、評価期間内に十分な根拠が集まらないなら、試験運用を延長するか、人による管理を厳しく保ちます。

5. 業務全体の効果を測り、次の判断を下す

改善効果は、AIを使わなかった案件、確認作業、代替手段での処理も含め、対象業務全体で判断します。AIを使った作業だけが速くなっても、責任を持つ業務全体での改善幅は、ずっと小さい場合があります。

次の仮の計算例で考えます。比較する案件の構成は同程度で、品質の評価基準も共通とします。必要な修正を経て、すべての案件が最終的には合格となり、所要時間には修正作業も含まれると仮定します。品質の件数は、初回確認時の結果です。理解のために置いた前提であり、ベンチマークでも、顧客の実績報告でもありません。

この例で、AIを利用した案件だけを見ると、実作業時間は25%減っています。12分から9分になり、利用した案件あたり3分の短縮です。しかし、ほかの案件には引き続き手作業が必要なため、業務全体で見ると、**実作業時間の削減率は15%**です。

計算式は、60 × 9 + 40 × 12 = 1,020分です。ベースラインの1,200分に対して、100件の対象案件全体で180分、つまり3時間の余力が生まれます。ただし、これだけでは支出が減ったとはいえません。品質確認の合格件数のわずかな違いも、品質が改善した証拠にはなりません。

成果、作業時間、利用状況、不具合の指標をまとめて、判断の記録を残します。この例では、対象案件の60%でAIを利用しています。この数字を利用者の抵抗感の表れと決めつける前に、残りの案件を調べてください。情報源の不足、対象に適さない依頼、かえって時間のかかる確認作業など、使われない理由はさまざまです。

結果は、全体に加えて、意味のある案件種別や担当者グループごとにも確認します。平均値が良好でも、重要な依頼区分での低い性能が隠れているかもしれません。未完了や遅延中の案件も確認してください。完了した業務だけを測ると、処理待ちが増えていても見落とす可能性があります。

National Institute of Standards and Technology（NIST）のAI Risk Management Framework Playbookは、導入後の挙動を導入前の検証結果と比較し、人が担う確認の責任を明確にすることを勧めています。日常運用に移っても、測定の定義は変えずに保ちます。

**注意すべき失敗：**生成した出力の数だけを報告したり、成功した一部の案件から全体の成果を推計したり、推定した時間短縮をそのまま金銭的なリターンに換算したりします。

**見抜くための確認：**すべての対象案件と必要な全作業を含めて結果を計算し直し、品質と重大な不具合は別に点検します。生まれた余力が支出や事業上の成果をどう変えるか評価する段階になったら、AIのROIガイドを使ってください。

検証済みの範囲を拡大するのか、特定した不具合を直して再テストするのか、不確実な点を解消するため測定を延長するのか、停止するのかを決めます。どの判断にも理由と責任者が必要です。何を明らかにするかを定めずに「実験を続ける」だけでは、試験運用の有用な結論にはなりません。

6. 元に戻せる範囲で、段階的に展開する

何が変わったかを把握できるよう、重要な変更は一度に一つずつ進めます。利用者を増やす、扱う案件を変える、別の部門へ広げる、操作権限を増やす、といった変更はそれぞれ別物であり、必要な検証も異なります。

サポートの回答案作成なら、承認済みの依頼種別と確認ルールをそのまま使って、次の利用者グループに展開します。新しい言語、新しい情報源、自動送信を同時に追加してはいけません。限定した条件で試験運用が成功しても、そうした拡張まで検証できたわけではありません。

担当者には、正常に動く場合だけでなく、失敗する場合も訓練します。根拠のない記述を見抜き、証拠を確認し、回答案を却下し、依頼を手作業の経路に回せるようにしてください。制御の仕組みは、実際に業務を行う場所に組み込みます。別の場所にある研修スライドでは、アプリケーションによる返信送信を止められません。

展開前に、障害や、意図的に情報源を利用できなくした状態を想定して訓練します。依頼が、作業を続けるのに十分な情報とともに手作業用のキューに届くこと、責任者が明確なままであること、同じ依頼を誤って重複処理しないことを確認してください。外部に影響する操作を行う業務では、すでに実行した操作をどう検知し、修正するかも定めます。モデルを停止しても、送信済みのメールやデータベースの更新は元に戻りません。

試験運用と同じ成果・作業時間の指標に加え、不具合の原因を説明する運用指標を監視します。依存先の稼働状況、待ち時間、情報源の鮮度、人による判断の上書き、インシデント報告などです。対応が必要なアラートには、通知先と求める対応を定めます。

**注意すべき失敗：**試験運用の成功が、熟練した確認担当者や構築担当者の常時支援に依存しており、次の利用者グループでは再現できません。

**見抜くための確認：**最初の試験運用に参加していなかった担当者に、研修内容と運用手順書を使って、難しい案件の処理と復旧訓練を完了してもらいます。助言せずに観察してください。説明、制御機能、対応能力の不足を直してから、利用者を増やします。

展開の判断には、追加する範囲、確認した根拠、承認者、停止条件、再開条件を記録します。代替手段が、必要になり得る業務量を実際に処理できると確認するまでは、以前の業務プロセスを使える状態に保ちます。

7. 継続運用の責任者に業務フローを引き継ぐ

運用責任者には、導入プロジェクトが終わった後も、業務フローを役立つ状態に保てることが求められます。そのためには権限、サポート能力、変更管理の手順が必要です。完了を知らせるメールだけでは足りません。

事業上の説明責任は、成果に責任を持つ人に残します。サポートの例では、サポート責任者が返信品質とサービス水準を受け入れます。技術保守担当者は連携や設定の不具合を扱い、情報源の管理責任者は承認済みのナレッジを維持します。代理の連絡先を明記し、通常の担当者が不在の場合に誰が対応するかも決めてください。

引き継ぎ資料には、次の内容を含めます。

• 承認済みの業務範囲、利用者グループ、操作権限。
• ベースライン、評価用の案件、評価基準、最新の結果、既知の制約。
• 情報源の保管場所、管理責任者、更新要件、アクセス権を削除する手順。
• 変更の調査に必要な設定と依存関係の記録。
• 監視方法、インシデントの連絡先、停止・再開の権限、復旧手順。
• 研修、確保したサポート時間、次回の運用レビュー。

NISTのMANAGEガイドは、システムを迂回したり停止したりする権限に加え、監視、インシデントからの復旧、変更管理を扱っています。それぞれの責任を、この業務フローで誰が担うかまで具体化します。

モデルの更新、指示の修正、情報源の入れ替え、新たな連携の追加は、成果に影響し得る変更として扱います。変更後の構成を広く展開する前に、該当する評価を実施し、その後、本番での挙動を確認してください。ベンダー側が管理する更新を止められない場合は、更新をどう検知し、影響を評価し、必要に応じて対象業務を停止するかを定めます。

AI導入は、稼働開始後も続きます

実際の結果と未解決のインシデントをもとに、運用レビューを行います。新たに見つかった失敗例を評価用の案件に追加し、古くなった情報源を取り除きます。効果が失われたり、維持に必要な作業が確保した対応能力を超えたりした場合は、業務フローを廃止するか、範囲を縮小します。

AIセンター・オブ・エクセレンスが、共通のアクセス基盤、評価、技術支援を提供する場合は、その支援内容とエスカレーション先を記録します。共通支援の組織があっても、現場の責任者が業務プロセスに負う責任はなくなりません。

**注意すべき失敗：**プロジェクトが終了し、性能の低下、情報源の変更、サポート依頼には誰か別の人が対応するはずだと、全員が思い込んでいます。

**見抜くための確認：**引き継ぎ先の責任者に、資料を使って模擬インシデントと変更提案に対応してもらいます。構築担当者は対応を指示しません。91日目から業務を担うためのアクセス権、権限、対応能力がそろって初めて、引き継ぎの受け入れを記録します。

過剰な期待は何か。今、動くべきなのは誰か？

自律化を当然の到達点にする必要はありません。人の監督下で有用な仕事を安定してこなす業務フローを、恒久的な設計として選んでもよいのです。権限を増やすのは、それによって変わる影響を評価してからにします。

既製品を導入するだけで、取り組みが完了するわけでもありません。情報源の選定、許可する操作、利用者の研修、業務成果には、引き続き自社が責任を持ちます。また、結果が期待に届かないからといって、モデルの再学習がそのまま解決策になるとは限りません。根拠の不足、検索・取得の誤り、指示、システム連携、人への引き継ぎのどこで問題が起きたかを調べてから、対処方法を選びます。

**業務の運用担当者は、条件がそろっているなら今、着手すべきです。**合意済みの成果、範囲を限定した作業、利用許可のあるデータ、結果を確認する時間があることが条件です。まず業務定義書とベースラインを用意し、その後は各リリース判断の根拠をそろえます。

**資金を確保している創業者は、対象範囲を守るべきです。**関連部門へ広げる前に、運用上の改善を実証するよう求めます。開発だけでなく、確認担当者とサポート担当者の時間にも資金を配分してください。

**CTOや開発者は、権限、状況を把握する仕組み、復旧に未解決の点があるなら、自律性を高めるのを待つべきです。**一人で開発する場合は、保守に割ける能力が限られていること自体が、よりシンプルなシステムを選ぶ理由になります。

**調達担当者は、合格を示す証拠と契約上の約束を結び付けるべきです。**連携、テスト、文書化、継続サポートを誰が提供するか確認します。魅力的なデモを見ても、その責任分担が決まったことにはなりません。

既存の業務プロセスで要件を満たしている部門は、そのまま続けて構いません。社内のほかの場所でAI施策が進んでいることは、健全な業務フローを置き換える理由にはなりません。

週明けに、まず取り組むこと

業務責任者、現場担当者、技術保守担当者が集まり、最近の案件を一緒に確認します。対象範囲と合格基準を書き出してください。情報源の管理責任者を決め、アクセス許可・拒否のテスト日程を押さえ、現行業務の測定を始めます。

同じ記録に、試験運用の判断日と、運用責任者になる予定の人の名前を記載します。その日に問うのは、根拠に照らして次の段階へ進めるかどうか、進めないなら何の作業が具体的に残っているかです。

AIを日々の業務に取り入れる実践ガイドは、ニュースレターに登録してお読みください。