「Copilot Studio」によるAI開発はなぜPoCで終わる？ 組織のすれ違いとROIの壁を解説：Copilot StudioでAIエージェント内製を定着させる実践論

AIエージェントの実用化が進む今、Microsoft Copilot Studioによる内製化が広がってます。ただ、その一方で、多くの企業が“PoC止まり”の壁に直面しています。本稿では、経営層と現場の温度差やIT部門とのすれ違いなど、実務への定着を阻むリアルな実態を明かし、プロジェクトが停滞する根本原因を解き明かします。

[佐藤寛太（パーソルビジネスプロセスデザイン），ITmedia]

この連載について

せっかく導入したAIエージェントがなぜ定着しないのか。本連載では、パーソルビジネスプロセスデザインによるMicrosoft Copilot Studio導入支援の知見を基に、AIを組織の新たな能力として定着させるための「再現性ある型」を全5回で解説します。「作ったが使われない」といった、導入後に陥りがちな失敗を先回りして回避するための具体策を提示します。

　2025年は「AIエージェント元年」とも称され、関連する技術や概念が広く浸透する年になりました。そして2026年に入ってからは、実際の業務に導入する動きやニュースを目にする機会も増えています。開発、運用のための環境の整備も進み、AIエージェントは検証段階から実用段階に移行しつつあります。

　そうした中で、「Microsoft 365」を利用する多くの企業にとって、既存環境との親和性が高く、有力な選択肢として存在感を高めているのが「Microsoft Copilot Studio」（以下、Copilot Studio）です。「プログラミングの知識がなくても、自社専用のAIエージェントが簡単に作成できるらしい」――そんな期待から、社内規定やマニュアル、議事録などを組み込んだ開発プロジェクトが各地で発足し、全社にライセンスが配布される光景も珍しくありません。

　しかし、導入から数カ月が経過した現場を見渡すと、当初の熱量とは裏腹に、どこか停滞した空気が漂っているケースも多いようです。

　「せっかく作ったのに誰も使っていない」「いつまでもテスト運用（PoC）のままで、本番の業務フローに組み込まれない」「担当者が異動してしまい、誰も中身をさわれないまま放置されている」――日々、企業のDXを支援する中で、こうした導入後の壁に直面し、プロジェクトが静かに座礁している現場を数多く目にしてきました。AIエージェントへの期待は高く、その可能性も広く認識されているはずなのに、なぜ実務に定着しないのでしょうか。

　本連載（全5回）では、IT部門はもちろん、自ら業務改革を推し進めようと奮闘している事業部門のリーダー層に向けて、Copilot Studioを使ってAIエージェントを内製し、組織の新たな能力として定着させるための「再現可能な型」をお伝えしていきます。

　第1回の本稿は、多くのDX推進現場が陥っている停滞パターンと、プロジェクトがPoC止まりになってしまう根本的な原因について、リアルな実態に即して解き明かします。

経営層の熱狂と実務現場の冷ややかな沈黙

　AIエージェントの導入直後、多くの企業が「社内ナレッジのQ＆Aエージェント」や「ITヘルプデスク自動化AIエージェント」を作成します。経営陣や部門長を集めたお披露目会では、「おぉ、AIが自社の複雑な就業規則を要約してくれた」と、それなりに好意的な反応が得られます。

　しかし、いざ事業部門に展開されると、ひと月もたたないうちにアクセスはパタリと途絶えます。

　システムが使いにくく回答が的外れだったとしても、「これじゃ使えない」と改善要望やクレームが上がってくることはありません。彼らは何も言わず、ただ静かに去っていくのです。

　「なんだ、結局たまに誤情報を出すし、答えてくれないこともあるじゃないか」――そう見切りをつけた瞬間に、現場はエージェントの画面を閉じ、何事もなかったかのように元の業務フローへと戻っていきます。推進側がどれだけ「AIを活用しましょう」と旗を振っても、現場側が「これで自分の業務が確実に楽になる」と感じられなければ、見向きもされないのです。

　さらに、多くの現場では導入後に直面しがちな停滞パターンが顕在化しています。

　例えば「適用業務が曖昧」ということです。取りあえず社内ナレッジを参照して質問に答えてくれるエージェントを作った結果、「どの業務に、どのタイミングでこのエージェントを開けばいいのか」が現場に伝わっていないケースです。なんとなく便利そうだとは思うも、日々の業務のどういった課題の解決にエージェントが利用できるのか分からず、結果として誰も触らなくなります。

　また、「属人化によるメンテナンス不能」も厄介です。新しいツールに感度の高い、いわゆる“エース級”の社員が一人で孤軍奮闘し、見事なプロンプトを組んでエージェントを作り上げる。しかし、その人の頭の中にしか設計がないため、異動や退職を機に誰もメンテナンスできなくなります。社内規定が変わってもエージェントは古い情報を答え続けるようになり、やがて誰も信じない「放置されたエージェント」に成り下がるのです。

　そして「永遠のPoC病」。AIエージェントの出力の品質が100％期待通りにならないことや、業務フロー刷新の遅延、すなわち受け入れ体制が整わないことから、いつまでもテストユーザー向けの枠を出られず、本番業務への適用が見送られ続けます。

リアルな現場とIT部門のすれ違い

　ここで、AIエージェントの内製化に取り組む現場から聞こえてくる、より生々しい声に耳を傾けてみましょう。そこにあるのは、推進側と現場、あるいは業務部門とIT部門の間に横たわる深い溝です。

　あるバックオフィス部門のリーダーは、次のように当時の苦い経験を振り返ります。

　「経理部門で毎月大量に発生する請求書と発注書、納品書の『3点照合』。フォーマットもバラバラで、非定型な処理が多すぎるこの業務をAIで効率化したいと考え、IT部門に相談したんです。ところが『システム化するなら、まずは現在の業務要件と、全ての例外処理のパターンを整理して要件定義書を出してくれ』と突き返されました。彼らの主張は正論かもしれませんが、日々の業務に追われる現場にそんなドキュメントを作る余裕もノウハウもあるわけがなく、結局話はそこで止まっています」

　また、別のDX担当者は、次のように現場の要求と現実的なステップとの間で板挟みになっている実態を明かしてくれました。

　「利用者や代理店から送られてくる多種多様な申込書類の審査業務。現場の担当者にヒアリングすると『最終的な判断の直前までAIで自動化したい』と言われました。ですが、一気に対応するのは無理なので段階的に少しずつAIを組み込んでいくと伝えると、『部分的な活用だけでは効果を感じにくい』とのこと。結局、どこから手をつければいいのかスコープが定まらず、開発に着手できていません」

　実務部門は「AIエージェントで業務を自動化してほしい」と期待し、IT部門は従来通りの開発プロセスに沿ってAIエージェントを実装しようとする。このように、一見すると同じ目的を共有しているのに、異なるプロトコルによる会話と、業務のどこにAIを組み込めば最大の効果が出るのか見極め方が分からないせいで、いつまでも「ライセンスが配られただけの状態」や、PoCから脱却できないことが多いのです。

　AI実装の前提に大きな違いがあるため、まずはその前提となる認識をそろえ、両者の溝を埋めていくことが重要です。

失敗を招く3つの具体的な根本原因

　こうした事態は、決してツールの性能が低いために起きているのではありません。ツールを業務に適合させるためのアプローチが、根本的に間違っているために生じる必然の結果なのです。そして、その原因は大きく3つに分解できます。

　第1の原因は、「ツール起点の設計」をしてしまうことによる設計力不足です。「Copilot Studioでこんな機能が使えるから、これを使ってみよう」という発想でスタートすると、ほぼ確実に失敗します。本来、AIエージェントの設計は「業務プロセスのどこに一番のボトルネックがあり、そこにAIをどう配置するか」という業務起点でなければなりません。

　先ほどの「3点照合」や「申込書類の審査業務」のような複雑な業務を、いきなり丸ごとAIに任せて無人化しようとすれば、必ず破綻します。業務プロセスを細かく分解し、「AIには複数データの差異や該当箇所をリストアップする“前さばき”だけを任せ、最終的な判断と責任は人間が持つ」といった、人とAIの現実的な役割分担を見極める設計が不可欠です。

　第2の原因は、「ノーコードゆえの障壁」に起因する開発力不足です。例えば本連載で紹介するCopilot Studioも、プログラミング言語を書かずに開発できますが、それは「論理的思考やシステム的な考え方が不要」という意味ではありません。「どんな条件の時に、どの変数を参照させ、どう出力させるか」という分岐処理や、社内の他のシステムとAPIでどう連携させるかといった、「アーキテクチャ思考」が求められます。この基礎的な理解が欠けていると、複雑なプロセスに耐えうる水準のものを作るのは難しいでしょう。

　第3の原因は、「作って終わり」のリリース至上主義による運用体制の欠如です。従来のITシステムは、要件定義をして開発し、リリースした瞬間がゴールの一つでした。しかし、AIエージェントは違います。リリースした瞬間がスタート地点です。ユーザーがどんな入力をして、AIがどう間違えたのか。そのログを日々分析し、裏側のプロンプトを微調整し、参照データを最新のものに差し替えていく。この「運用サイクル」を回す体制を作らないままリリースしてしまうことが、AIがすぐに陳腐化し、見放される最大の要因です。

稟議を通せない「ROI視点の壁」

　そして、PoC止まりから抜け出せず、プロジェクトが自然消滅していく決定的な理由が「投資対効果（ROI）の証明が極めて難しい」という点にあります。

　クラウドであれオンプレミスであれ、AI導入プロジェクトが進めば、経営層は必ずこう問います。「で、このツールを入れて、結局どれだけコストが下がったのか。利益は増えたのか」と。

　しかし、バックオフィス業務の効率化や、非定型業務の支援といった領域において、その成果を正確に定量化するのは至難の業です。「AIのおかげで、マニュアルの検索時間が1回当たり10分減りました」「回答の質が上がりました」と報告しても、役員会では通用しません。「その浮いた10分で、社員は本当に別の利益を生む仕事をしたのか」「質が上がったというが、それは売り上げにどう直結するのか」と詰められれば、沈黙するしかないのです。

　実は、AIエージェントの導入において、プロジェクトの初期段階で「KPI設計（メトリクス設計）」をしていない企業がほとんどです。成果を証明する指標をあらかじめ合意しておかないと、いざテストが終わった際に「なんとなく現場からは好評でした」という定性的な評価しかできず、本格導入に向けた次年度の予算も、専任の運用担当者の配置も認められなくなってしまいます。「使われるAI」にするためには、システムを作ることと同じくらい、「成果をどう測り、どう上層部に報告するか」の設計が重要な意味を持ちます。

次回以降の予告：壁を越えるためのロードマップ

　AIエージェントの導入は、単なる新しいソフトウェアのインストールではありません。「新しいデジタルな同僚」を雇い入れ、彼らが機能するように業務プロセスや人間の働き方そのものを再構築していく、まさに組織のチェンジマネジメントです。

　これまでのやり方に固執する現場を和らげ、どのようにAIを当たり前の道具として日々の業務に組み込んでもらうか。一部のスキルの高い担当者に依存せず、組織全体で継続的にAIを活用し、育てていく仕組みをどう作るか。

　本連載では、今回お伝えした課題と落とし穴を回避し、AIエージェントを組織の能力として定着させるための「ロードマップ」と「型」を、以下のステップで提示していきます。

　まず第2回では、プロジェクトの成否を分ける「失敗しない業務の選び方」と、現場の課題をAIの要件へと正しく落とし込むための設計手順を解説します。

　続く第3回では、Copilot Studioの真価を発揮させるためのステップとして、開発時に直面しがちな課題への対策や、回答精度を劇的に引き上げるための実践的なノウハウを取り上げます。

　さらに第4回では、現場で「使われない」という事態を解体し、組織全体を巻き込んでいくためのチェンジマネジメントの設計方法や、経営層への稟議に不可欠なROI（投資対効果）を証明するためのメトリクス（指標）設計に踏み込みます。

　最終回となる第5回では、一部のコア人材に依存することなく、組織全体で継続的にAIを活用、改善していくための内製化人材の育成、そして「CoE」（組織横断の専門組織）戦略に焦点を当て、AIエージェントがもたらす組織の未来像を展望します。

　次回、第2回では、プロジェクトを立ち上げる際の最重要ポイントである「失敗しない業務選定と初期設計の型」について解説します。どの業務を選べば、AIは現場で“使える道具”として受け入れられるのか。事業部門が明日から使える具体的なアプローチにご期待ください。

著者プロフィール：佐藤寛太（パーソルビジネスプロセスデザイン株式会社　CX事業本部 DX統括部 プロセスサイエンス部　マネジャー／AXコンサルタント）

前職にてEC事業におけるフルフィル業務設計、物流・決済、カスタマーサポート等をワンストップで受託。PL兼SVとして従事し、バックオフィス運営のノウハウを多く保有。

パーソルビジネスプロセスデザイン入社後は、主に各種ツールの導入によるDX推進を行うプロジェクトを軸に業務整理/再設計から業務の自動化、開発など各工程を担当。

顧客のECリプレースや、生成AI×RPAによる業務プロセス/事務作業の”ゼロ化”を推進し、コンタクトセンターのDX化推進にも従事。多業種多業態における全体最適化×CX向上に深い知見を持つ。