せっかく導入したAIエージェントがなぜ定着しないのか。本連載では、パーソルビジネスプロセスデザインによるMicrosoft Copilot Studio導入支援の知見を基に、AIを組織の新たな能力として定着させるための「再現性ある型」を全5回で解説する。「作ったが使われない」といった、導入後に陥りがちな失敗を先回りして回避するための具体策を提示する。
第2回では、AIエージェントの命運を分ける「業務選定とROI設計」について解説した。どの業務にAIを配置し、何を成果指標にするか。この戦略図が描けていれば、プロジェクトの成功率を高められる。
「構造」フェーズに進む
第3回では「構造」のフェーズに進む。「Microsoft Copilot Studio」（以下、Copilot Studio）の管理画面を開き、キャンバスにノード（処理のブロック）を並べ、AIエージェントを作成する工程である。
「ノーコードだから、誰でも簡単に作れる」――これはある側面としては事実ですが、ビジネスの現場で「信頼できる同僚」として機能するAIエージェントを作るとなると、話は別です。ただ「動く」ものを作るのと、現場の厳しい要求に対応できる「使える」ものを作るのとでは大きな違いがあります。
今回は、私が多くの現場で目撃してきた「失敗するAIエージェント」と「成功するAIエージェント」を分ける10の実践的なポイントを、具体的に深掘りします。
キャンバスを開く前に確認すべき「構造ステップ」
具体的なポイントに触れる前に、開発の全体像を整理しておきましょう。Copilot Studioによる開発は、単なる「プロンプト入力」ではありません。以下の5ステップを意識したサイクルを回すのが内製化の近道です。
- 要件整理：選択した業務において「ユーザーが何を入力し、AIがどのような結果を返すのか」を明確にする。
- 対話設計：AIが聞き返すべき項目や、例外時の振る舞いをシナリオ化する。
- ナレッジ／データ接続：「Microsoft SharePoint」（以下、SharePoint）や「Microsoft Dataverse」（以下、Dataverse）、APIなど、AIの「知能基盤」となるソースをつなぎ込む。
- テスト設計：正常系の動作だけでなく、意地悪な質問や範囲外の要求に対する挙動を確認する。
- 段階リリース：いきなり全社展開せず、まずは数名の「現場の協力者」に触ってもらい、フィードバックを得る。
このステップを無視して「取りあえず設定画面をいじる」ことから始めると、後述する落とし穴にはまることになります。
AIエージェント開発を成功させる「10のポイント」
それでは、実践で得られた10のポイントを解説します。開発中に迷った際のチェックリストとして活用してください。
1. 正解率よりも運用で倒せる設計（例外／エスカレーション）
AIの処理精度を100％にすることに執着してはいけません。生成AIである以上、どうしてもうまく処理できないケースや、誤った推論をする可能性はゼロにできないからです。
大切なのは、AIが答えられないと判断したときに、スムーズに「人間の担当者につなぐ（エスカレーション）」、あるいは「問い合わせフォームへ誘導する」といった出口設計です。現場で特に不満を招きやすいのは、AIが「分かりません」と答えるだけで、利用者を次の対応へ誘導できない状態です。
2. 説明の明文化（ログ、根拠提示、参照元の扱い）
「なぜAIがその回答を出したのか」という根拠が不明なAIエージェントは、業務では使えません。
Copilot Studioの生成回答機能を使い、必ず「参照元ドキュメント」へのリンクを表示させるように設定してください。ユーザーが「AIが言っていることは本当か？」と不安になった際、ワンクリックで一次情報（PDFやSharePointのページ）を確認できるようにすることで、AIエージェントへの信頼を高められます。
3. 品質の検証（テスト観点：ハルシネーション、機微、禁止領域、制限）
開発者だけがテストしてはいけません。テストには、以下の4つの観点を含めてください。
- ハルシネーション（事実と異なる回答）：事実と異なる内容を、もっともらしく回答しないか。
- 禁止領域：業務に関係のない雑談や、不適切な発言をブロックできているか。
- 制限：本来アクセスできないはずの他部署の機密情報を回答に含まないか。
- 整合性：同じ入力に対して、極端に異なる出力をしないか。
4. ナレッジの鮮度管理
AIエージェントに読み込ませたマニュアルが1年前のものだった――。これは、業務現場では致命的なミスにつながります。例えば「PDFを直接アップロード」して構築すると、マニュアル改訂のたびに再アップロードが必要になり、運用が形骸化します。
SharePointの特定のフォルダを「動的ナレッジソース」として指定してください。SharePoint上の文書を更新することで、AIエージェントが参照する情報にも変更を反映しやすい構造を作ることが、長期運用では重要です。
5. 制限・セキュリティ設計（誰が何を聞けるか）
「全社公開のボット」に役員だけが閲覧できる機密文書を参照させてはいけません。
「Microsoft Entra ID」（旧Azure AD）と連携し、ユーザーのサインイン情報に基づいて回答範囲を制限する設計をします。Copilot Studioなら、SharePointの制限設定をそのまま引き継いで検索させられるため、IT部門にとっても管理負荷が低いのがメリットです。
6. Microsoft 365（以下、M365）連携設計（どのコネクター、データをつなぐか）
Copilot Studioは「単なるチャットボット」ではなく「オーケストレーター（※）」です。
※複雑で大規模な情報システムの導入や運用を自動化、効率化することができるソフトウェアやサービスのこと。
後述する「Microsoft Power Automate」（以下、Power Automate）などを活用し、「メールを送る」「予定表を確認する」「Microsoft Excel（以下、Excel）を更新する」といったアクションを伴う設計が効果的です。情報の検索だけで終わらせず、業務の実行まで踏み込むことが、ROIを最大化するポイントです。
7. プロンプト設計の反復改善
最初に書いたシステムプロンプト（指示文）は完璧ではありません。リリース後のログを分析し、「ユーザーの意図をくみ取れていない箇所」を見つけたら、プロンプトを微調整する作業をルーティン化してください。「リリース＝完了」ではなく、「リリース＝学習の開始」という意識をチームで共有しましょう。
8. ユーザーへの"使い方の説明"の設計
どんなに優れたAIも、存在を知られなければ、あるいは使い方が分からなければ放置されます。
AIエージェントの「初回メッセージ」で、具体的に何ができるかを提示してください。「何でも聞いてください」ではなく、「経費精算の手順やPCの不具合、有給休暇の申請についてお答えします」と、できることの範囲（スコープ）を明示するのが親切な設計です。
9. 属人化を防ぐドキュメント化（設計書・変更履歴）
「エースのAさんしか、このチャットボットのプロンプトを触れない」という状態は、組織としてリスクがあります。
Copilot Studioの画面内だけで管理せず、「設計の意図（なぜこのトピックを作ったか）」「主要なプロンプトの内容とその役割」「参照しているデータの一覧」を、別途、設計書や変更履歴にまとめておきましょう。第5回で解説する「組織展開」を見据えた準備です。
10. "作って終わり"にしない改善トリガーの設計
現場からフィードバックを得る仕組みを、あらかじめシステムに組み込みます。
回答の最後に「解決しましたか？（はい／いいえ）」のアンケートを表示させ、「いいえ」が押された場合はその理由を入力してもらう。そのデータが自動的にチームの「Microsoft Teams」（以下、Teams）に通知されるようにしておけば、現場の不満を放置せずに済みます。
M365連携で広がるCopilot Studioの「つながる世界」
Copilot Studioが真価を発揮するのは、M365の膨大なデータ群とつながった時です。単独の生成AIチャットと異なり、ツールや業務フローといった組織の既存アセットを「手足」として動かすことができます。以下の表は、開発時に検討してほしい「連携リソース」の一例です。
| 接続リソース | 現場での具体的な活用イメージ |
|---|---|
| SharePoint | 社内文書や規定、FAQマニュアルの自動検索。常に最新の情報を回答の根拠にする。 |
| OneDrive | 個人やチームが持つ特定のプロジェクトファイルの要約やデータ抽出。 |
| Teams | 開発したAIエージェントをTeams上に公開。使い慣れたUIで、いつでも呼び出せる。 |
| Outlook | 回答内容に基づいたメールの下書き作成、会議スケジュールの空き時間確認。 |
| Power Automate | AIが受け取った情報を基に、ワークフロー（承認依頼や自動通知、データ登録など）を起動。 |
| Dataverse／Excel | 在庫データや顧客リストといった「構造化された数値データ」の照合。 |
| Forms | ユーザーが入力したフォームの内容をトリガーに、AIが追加のヒアリングやアドバイスを行う。 |
| Entra ID | ユーザーの部署や役職に基づいた、細やかな回答・アクセスの制御。 |
構造フェーズでの「リアルな苦労」
ここで、実際に構造に携わった方々の「生の声」を聞いてみましょう。
「ノーコードだからと楽観的に見ていました。変数の扱いや条件分岐を適当に作っていたら、後から修正するのがパズルのようになってしまって……。やはり最初に『どういう会話の流れになるか』を紙に書き出すべきでした」（IT推進担当・30代）
「SharePointのファイルを読み込ませる際、ファイル名や見だしがぐちゃぐちゃだと、AIがうまく情報を探せませんでした。結局、AIを作る前に『社内のドキュメント整理』という、なんとも地味な作業が必要だと気付かされました」（DX担当・40代）
これらはまさに「あるある」な体験です。ツールを触る時間は半分、残りの半分は「業務の整理」と「データの準備」に費やされるのが、AI開発の現実です。
開発上の工夫が成果につながった事例
次に、ポイントを押さえて開発したことで確かな成果を出した事例を紹介します。
社内FAQチャットボット（情報システム部門）
ただの検索ではなく、回答の最後に必ず「関連する申請フォームへのリンク」を出すように設計。結果、月300件の問い合わせの一次対応を代替し、担当者の工数を月40時間削減。さらに「対応が迅速になった」と現場の満足度も向上しました。
申請ガイドAIエージェント（総務部門）
Power Automateと連携して、従業員からの各種申請受付をトリガーにしてAIが申請内容を自動で迅速にチェックし、その場で不備を指摘する仕組みを導入。これにより手動の差戻し対応が大幅に削減され、申請不備率は32％から8％に低下、承認までのリードタイムも25％短縮しました。差戻し対応にかかっていた工数ベースで換算すると、部門全体で月間約60時間の業務削減に相当します。
報告書下書き生成AIエージェント（営業部門）
Teamsのチャット履歴から活動内容を抽出し、指定のフォーマットで週報の下書きを作成。報告書1件当たりの作成時間が平均60分から15分に短縮され、部門全体で月間約150時間の作業削減を実現しました。文章を書くのが苦手な従業員の心理的ハードルの低減にも貢献しています。
なぜ、Copilot Studioなのか？
数あるAIツールの中で、なぜ私たちがCopilot Studioを推奨するのか。その理由は以下の4点に集約されます。
- M365とのシームレスな統合：新たなセキュリティ基盤を作る必要がなく、今あるIDと制限で運用できる。
- ガバナンスの維持：IT部門が既に管理しているポリシーの枠内で、安全に「現場発」のツールを展開できる。
- 開発の柔軟性：業務部門がノーコードで構築し、複雑な処理をIT部門がローコード（Power Automateなど）で補完する「共同開発」がしやすい。
- 継続的な進化：Microsoftの巨額の投資により、Microsoftが継続的に提供する新機能を利用しやすい。
次回予告：作っても「使われない」壁をどう越すか？
ここまでで、戦略的な業務選定（第2回）と、実戦的な構造スキル（第3回）をお伝えしました。これで素晴らしいAIエージェントが出来上がるはずです。
しかし、ここからが本当の「AI導入の正念場」です。
「いいものができたのに、なぜか使われない」「導入当初は盛り上がったが、今は誰も触っていない」。そんなひややかな現実に直面するプロジェクトが後を絶ちません。
次回の第4回では、人間の心理や組織の習慣という、テクノロジーよりはるかに難しい障壁をどう乗り越えるか。現場を熱狂させ、AIを「なくてはならない日常の道具」に変えるための、地味だけど科学的なアプローチに踏み込みます。
AIエージェントを「作（運用）」まで含めて完成させるための方法論を、共に学んでいきましょう。
