AIエージェント展開後の「冷ややかな沈黙」はなぜ起きる？ 定着を促すチェンジマネジメント設計：Copilot StudioでAIエージェント内製を定着させる実践論
せっかく導入したAIエージェントが使われなくなる背景には、現場の心理と構造的要因があります。本稿では「冷ややかな沈黙」を防ぎ定着させるため、ルールの策定や導線の用意など、チェンジマネジメントの設計を解説します。
この連載について
せっかく導入したAIエージェントがなぜ定着しないのか。本連載では、パーソルビジネスプロセスデザインによるMicrosoft Copilot Studio導入支援の知見を基に、AIを組織の新たな能力として定着させるための「再現性ある型」を全5回で解説します。「作ったが使われない」といった、導入後に陥りがちな失敗を先回りして回避するための具体策を提示します。
第3回では、「Microsoft Copilot Studio」（以下、Copilot Studio）におけるエージェント開発の「10の勘所」を解説しました。
例外処理や「Microsoft SharePoint」などのナレッジとの接続、権限設計といった技術的な壁を乗り越え、いよいよ「実務に耐えうるAIエージェント」が完成しました。テストで挙動も問題ないことを確認でき、現場の業務は劇的に楽になるはずです。
しかし、ここに多くの推進者が直面する壁が立ちはだかっています。それは「せっかく展開したのに、誰も使ってくれない」という現実です。
導入直後のお披露目会では「すごい」「便利そう」という声が上がったにもかかわらず、1週間後にはアクセスログが急減。現場は何事もなかったかのように元の業務フローに戻っている。使いにくい点や不足している機能が分かれば改善の余地もあるのですが、推進担当者からは明確な不満の声すら返ってきません。
新しいツールが現場の肌に合わなかったとき、従業員がクレームを言ったり明確に非難したりすることはめったにありません。彼らはただ「冷ややかな沈黙」をもってツールをPC画面の隅に追いやり、そっと元のやり方に戻っていきます。
連載第4回となる今回は、この「使われない」という現象を解体し、テクノロジーの導入以上に重要な「人間の心理と行動を変えるための設計（チェンジマネジメント）」について、実戦的なアプローチを解説します。
「使われない」の構造的要因と現場の心理
AIエージェントを使わなくなる理由は、決して「新しい変化に対する意欲の低さ」ではありません。極めて合理的で切実な理由が潜んでいます。
1．忙しすぎて「試す」余裕がない
現場は日々の業務で疲弊しがちです。新たに導入されたAIエージェントに学習コストを払うより、いつもの手順を無心でこなす方が短期的には効率が良く、合理的でもあるのです。
2．「誰の責任か」が怖くて萎縮する
「AIが生成した下書きやチェック結果に間違いがあった場合、最終的に誰が責任を取るのか」
この問いに対するルールが曖昧なままでは、全ての出力結果や成果物を目視チェックせざるを得ません。「人間は確認だけでいい」と言われても、結局全て確認するなら、最初から自分でやった方が早い（二度手間である）と判断し、AIを使わなくなります。
3．一度の期待外れによる「見切り」
人間は、AIに対して無意識に「完璧」を求める傾向があります。最初に使ったときの出力が的外れだったり、自社の複雑な（時には属人的で泥臭い）業務ルールをくみ取れていなかったりすると即座に見切りをつけます。期待値が高い分、一度失った信頼を取り戻すのは困難です。
定着フェーズの「リアルな苦労」「リアルな現場の声」
日々の支援における定着フェーズで聞いた生の声を紹介します。
- 事業部門担当者：「一見ちゃんとしたアウトプットが出てきて期待をしたが、そのまま使うにはちょっと詰めが甘くて、直しがそれなりに必要だった。その手間が当初思っていたよりも重かった」
- DX推進者：「マニュアルを配り、説明会でデモも実施したが、その後ほとんど誰も触らずに終わった。『Microsoft Teams』のチャネルにナレッジを溜めたAIを常駐させても、AIで解決しようとはせず、従来通りのやり方で担当者に質問が飛んでいる」
- IT担当者：「最初は物珍しさもあってか好意的だったが、現場の意識や業務フローがAIに業務を合わせる『Fit to Standard』の考え方になじまず、例外処理の仕組化が完璧ではなかったために結局ほとんど利用されなかった」
この課題を解消し、定着させるためには何をしなければならないのか。ソフト面とハード面から説明します。
ソフト面：「利用の約束事」で心理的ハードルを下げる
最初のアプローチは、AIに対する「利用の約束事（グランドルール）」を明文化し、組織として合意することです。
具体的には、以下の3点を明確にします。
- AIの立ち位置の定義（あくまで「下書き・前さばき」である）：「AIは完璧な答えを出すシステムではなく、優秀だがたまに間違えるアシスタントだ」と宣言します。第2回でも触れた通り、最終的な判断と責任は人間が持つことを明確にします。
- 使っていい範囲と禁止領域の明示：「この業務には積極的に使ってよい（例：一般的な経費精算の質問、一次調査）」「この業務には絶対に使ってはいけない（例：最終的な人事評価、未公開のM&A情報の入力）」という線引きをします。
- 困ったときの「逃げ道」の用意：AIが的外れな回答をした場合や、エラーで止まった場合に「どこにどうやってエスカレーションすればいいか」を定めます。逃げ道があるからこそ、安心して試せるのです。
ハード面：Microsoft 365業務導線への「埋め込み」設計
「ブラウザを開いてブックマーク登録したAIエージェントのURLにアクセスする」。このわずか数秒の手間が定着を阻みます。
Copilot Studioの最大の強みは、ユーザーが日常的に使っている「Microsoft 365」の業務導線上にエージェントを「埋め込める」ことにあります。以下に埋め込み先の例を記載します。
| 埋め込み先 | 具体的な定着アプローチ |
|---|---|
| Teamsチャネル／チャット | エージェントをTeamsのアプリとして公開し、部門のチャネルに常駐させます。誰かが質問するとAIが答え、間違っていれば他のメンバーがスレッドで補足するといった「人間とAIの協働空間」が自然に生まれます。 |
| SharePoint（業務ポータル） | ほぼ全社員が毎日見る社内ポータルのトップページに、WebパーツとしてAIチャット画面を埋め込みます。「お問い合わせ」画面のファーストビューに配置することで、検索するより先にAIに聞く習慣を付けます。 |
| Outlook（メール作成画面） | 特定の業務（例：顧客への定期的な通知業務など）において、OutlookのアドインやCopilot機能と連携させ、メールを開いた瞬間に「過去の経緯を踏まえたドラフト候補」が横に提示されるようにします。 |
| Power Automate連携 | ユーザーがFormsで申請を出した瞬間に、裏側でPower Automateが起動し、AIが内容をチェック。不備があれば自動でTeamsのチャットに「ここを修正してください」と差し戻す。ユーザーは「AIを使いにいこう」と意識せずとも、業務フローの中で自然に恩恵を受けます。 |
「AIを使わせる」のではなく、「いつもの業務フローの中に、最初からAIが組み込まれている状態（デフォルト設定）」を用意することが、定着への最短ルートです。次は定着度合いの測定を進めましょう。
メトリクス設計：ROIを継続測定し、予算を守る
AIエージェントが定着しつつあるかどうかは、感覚ではなく「数値」で追跡しなければなりません。そのためにはどういった「数値」を追うのか、第2回で設定したKPIを、さらに運用フェーズに落とし込んだ「メトリクス（測定指標）」を設計します。これがないと、導入半年後の役員報告で「で、いくらもうかったの？」という問いに再び沈黙することになります。
以下の指標を基に改善サイクルを回していくことで、定着しているかどうかをウォッチしましょう。
| 指標カテゴリー | 具体的指標 | 測定方法／情報源 |
|---|---|---|
| 利用状況 | 月間利用セッション数、ユニークユーザー（UU）数 | Copilot Studioの標準分析ダッシュボード |
| 解決品質 | 一次解決率（AIだけで完結した割合）、エスカレーション率 | ログ分析、終了時のユーザーアンケート |
| 時間削減 | 対応工数削減時間（月次）、処理リードタイムの短縮 | 前後比較（ベースラインとの差分） |
| 満足度 | ユーザー評価スコア（5段階）、定性的なフィードバック | エージェント内でのワンクリックアンケート |
| 改善活動 | プロンプトの修正頻度、ナレッジ（SharePointなど）の更新頻度 | 開発チームの変更履歴・運用ログ |
第2回で紹介した「ROI（投資対効果）の立て方」でも触れた通り、上記メトリクスを追跡し、ROIを継続測定できれば、経営会議で胸を張って予算を守ることができます。
以下は、ROI継続測定のロードマップのイメージです。理想的にも見えますが、本稿で紹介してきたような運用設計と改善サイクルを着実に回すことで、現実的に到達可能なラインでもあります。
改善サイクルの作り方：「週次のログレビュー」という泥臭い作業
定着をさらに押し進めるためには改善サイクルを回すことが重要です。AIエージェントは、リリースしたその日が「最も賢くない状態」です。定着するか否かは、リリース後の運用サイクルをどう回すかにかかっています。
そこで、推進チームによる「週次のログレビュー」を必ずスケジュールに組み込んでください。Copilot Studioの分析画面から、ユーザーがどのような質問を投げ、AIがどう間違えたか（あるいは答えられなかったか）を目視で確認します。
「現場はこういう言い回しで指示するのか」「古いフォーマットのままの規定集を参照して間違えているな」といった内容を発見したら、プロンプトに条件分岐を追加したり、裏側にあるSharePointのドキュメントの表記を統一したりといったメンテナンスをします。
この泥臭いチューニングを繰り返すことでしか、実務に耐えうるAIは育ちません。現場からの「これ、うまく処理できなかったよ」という報告に対して、数日内に「直しておきました。もう一度試してください」と返せる体制があれば、現場の冷ややかな沈黙は、次第に協力的な動きに変わっていきます。
「1on1の伴走」から「現場の自走」へ
ここまで見てきたように、AIに対する意識の醸成や導線設計、ルール整備、改善サイクルの構築が重要になります。しかし現実には、これらを推進チームだけで回し続けるのは困難です。現場ごとに業務の文脈や例外が異なる中で、全てを中央集権的に最適化するには限界があります。
だからこそ重要になるのが、現場起点で改善を回せる状態をつくることです。そして、その立ち上げにおいて有効なのが、外部の専門家によるハンズオン形式の1on1伴走です。
個別の業務を題材に、手を動かしながら進めるハンズオンの1on1を通じて、「どこまでAIに任せるか」「どう調整すれば実務にフィットするか」といった具体的な改善を現場とともに進めることで、単発の利用に終わらない継続的な活用へとつながります。
次回予告：AIエージェントを「組織能力」へと昇華させる
第1〜4回を通して、業務の選定から開発、そして現場への定着まで、プロジェクトを進めるための基本的な型を紹介してきました。特定の部門におけるAIエージェント導入の進め方は見えてきたかと思います。
しかし、真のDXとは、点での成功を「面」に広げた先にあります。一部の熱心な担当者や特定の部署だけでなく、会社全体でAIを使いこなし、次々と新しいエージェントが現場発で生み出される状態です。
最終回となる第5回では、組織全体で内製化を推進するための体制（CoE：Center of Excellence）の作り方や市民開発者の育成プログラム、そしてAIエージェントがもたらす少し先の未来の働き方について展望します。単なる「便利なツール」を「会社の強み」に変えるための最終章にご期待ください。
著者プロフィール：佐藤寛太（パーソルビジネスプロセスデザイン株式会社 CX事業本部 DX統括部 プロセスサイエンス部 マネジャー／AXコンサルタント）
前職にてEC事業におけるフルフィル業務設計、物流・決済、カスタマーサポート等をワンストップで受託。PL兼SVとして従事し、バックオフィス運営のノウハウを多く保有。
パーソルビジネスプロセスデザイン入社後は、主に各種ツールの導入によるDX推進を行うプロジェクトを軸に業務整理/再設計から業務の自動化、開発など各工程を担当。
顧客のECリプレースや、生成AI×RPAによる業務プロセス/事務作業の”ゼロ化”を推進し、コンタクトセンターのDX化推進にも従事。多業種多業態における全体最適化×CX向上に深い知見を持つ。
Copyright © ITmedia, Inc. All Rights Reserved.
