AI導入は、AIから始まらなかった

Robot Column Vol.10 ― AI Adoption Didn’t Start with AI

「今話題のAIを使えば、何とかできるんでしょ？」

社内DXを担当していると、そんな言葉を耳にすることがあります。
確かにAIは便利です。
しかし、実際に業務で使える仕組みを作ろうとすると、AIを導入するだけでは何も始まりませんでした。
弊社では現在、社内の生産性向上を目的に、Microsoftのエージェント作成ツール「Copilot Studio」を使った問い合わせシステムの構築を進めています。
この連載では、社内SEの視点から、システムが完成するまでの試行錯誤をできるだけ率直にお伝えします。

第1回は、AI導入の前に立ちはだかった課題と、Copilot Studioを選ぶまでの経緯について紹介します。

1　まずは、社内問い合わせの仕組みづくりから

今回、手始めに取り組んでいるのは、パソコンに関する社内問い合わせに対応するエージェントです。
パソコンの設定やソフトの使い方、よくあるトラブルなどについて社員が質問すると、登録された社内資料をもとに回答する仕組みを目指しています。
これまで人がその都度対応していた問い合わせの一部を、AIで支援できないかと考えたのが始まりです。
ところが、実際に作り始めてみると、すぐに大きな壁にぶつかりました。
AIに読ませるための「正しい資料」が、十分に整っていなかったのです。

2　AIは「何でもできる魔法」ではない

昨今は「AI」という言葉が広く使われるようになり、実態がかえって分かりにくくなっているようにも感じます。ここでいうAIとは、文章や回答を生成する「生成AI」を指します。
生成AIは非常に便利ですが、何でも自動的に解決してくれる万能な存在ではありません。あえて極端に言えば、目的も前提条件も資料も与えられていないAIは、業務上の正解を判断できません。
生成AIは、学習した情報や与えられた文脈をもとに、もっとも可能性が高い回答を組み立てます。そのため、質問が曖昧だったり、参照する資料が不正確だったりすれば、期待した回答から外れる可能性があります。

3　AIが迷うのは、社内のルールが曖昧だから

例えば、社内のある仕事について、Aというやり方、Bというやり方、さらにCというやり方まで存在しているとします。
この状態で「この仕事はどうやるの？」と質問しても、AIはどの方法が今回の正解なのか判断できません。
資料に書かれているA・B・Cの方法を並べて示すだけになり、利用者からは「AIって、思ったより使えないね。これなら人に聞いたほうが早い」と思われてしまいます。
しかし、本当に足りないのはAIの能力でしょうか。
この質問には、「いつ」「どこで」「誰が」「何を」「なぜ」「どのように」という前提条件がありません。
どれほど知識のある人でも、条件が分からなければ明確な回答は難しいはずです。一緒に仕事をしている人が答えられるのは、その人が質問の背景や社内ルールを知っているからです。
AIにも同じように、判断の前提となる情報が必要です。

4　AI導入の第一歩はマニュアルの整備

生成AIを業務で活用するには、正しいルールや手順が書かれたドキュメントを準備する必要があります。
そして、これがAI導入における最初の大きな課題でした。

弊社でも、当初は「AIを導入しよう」というところからスタートしました。
しかし、検討を進めるうちに、「参照させるルールやマニュアルが足りない」「同じ業務でも担当者によって説明が違う」という問題が見えてきました。
その結果、実際の流れは次のようになりました。

AIを導入するつもりが、最初に始まったのは社内ルールの整理でした。 これは遠回りに見えますが、AIの有無にかかわらず、属人化していた知識を会社の共有財産に変える作業でもあります。

5　BOT・RAG・エージェントは何が違うのか

生成AIを使った仕組みを検討していると、「BOT」「RAG」「エージェント」という言葉が頻繁に登場します。 似た場面で使われるため混同しやすいのですが、単純な上下関係ではなく、それぞれ役割が異なります。

BOT:
利用者とシステムが会話するための窓口です。
あらかじめ用意された質問と回答を返すものもあれば、生成AIと組み合わせて柔軟に回答するものもあります。

RAG（検索拡張生成）:
登録された資料や文書から質問に関係する情報を探し、その内容を根拠として生成AIが回答を作る方法です。
社内規程やマニュアルをもとに問い合わせへ回答させる場合、このRAGが中心になります。

エージェント:
与えられた目的に応じて、必要な知識やツール、処理を選び、回答や行動につなげる仕組みです。
資料を検索して回答するだけでなく、外部サービスやAPIと連携し、処理を実行することもできます。

つまり、今回作ろうとしているものは、社員がTeams上のBOTに質問し、RAGによって社内資料を検索して回答するエージェント、と説明できます。

6　長く使えるプラットフォームを求めて

仕組みが見えてきたところで、次に検討したのが、どのプラットフォームを使って構築するかという問題です。

社内システムは、作って終わりではありません。 資料の追加や修正、利用者への展開、アクセス権限の管理、将来的な機能拡張まで考える必要があります。そのため、機能だけでなく、長く運用できることを重視しました。
今回、実際に試したのは、Copilot Studio、Dify、RAGFlow、NotebookLM、AWS Bedrock Agentsです。

AWS Bedrock Agentsは、弊社がAWS上に保有する情報資産との連携を検討できる点が魅力でした。しかし、今回の用途では相互に呼び出すほどの仕組みを必要とせず、RAGを構築した場合のコストも考慮して候補から外しました。

NotebookLMは、比較的手軽に資料を参照した回答環境を作れる点が魅力でした。 一方、今回重視していたTeamsからの利用という条件に合わず、採用には至りませんでした。

DifyとRAGFlowは、操作が分かりやすく、コストも現実的でした。BOTをTeamsに置いて問い合わせる構成も検討できましたが、今回想定した運用では、エージェントを修正した際の全社への再配布や管理に負担が生じることが分かり、断念しました。
特にDifyは、直感的な操作性、コスト、RAGの構築しやすさという点で、最後まで候補に残りました。

Teamsとの連携やMicrosoft 365環境での一元管理を重視しないのであれば、有力な選択肢だと感じています。

7　Copilot Studioを選んだ理由

最終的に選んだのが、MicrosoftのCopilot Studioです。
Copilot Studioには、直感的な操作、日本語によるガイド、RAGを前提とした知識の登録、Teamsへの展開、Microsoft 365との連携など、今回必要としていた機能がまとまっていました。

弊社ではMicrosoft 365を利用しているため、同一テナント内で管理でき、OneDriveやSharePointのファイルを知識源として利用しやすいことも大きな利点です。さらに、将来的には各種APIや外部サービスとの連携も検討できます。

Microsoft製品を使い始めて約30年になりますが、Copilot Studioの完成度と、MicrosoftがAIエージェントに力を入れている姿勢には、久しぶりに大きな驚きを感じました。
もちろん、外部アプリを自動操作する段階まで進めば、誤動作への対策、権限管理、責任の所在など、慎重に考えるべき問題が増えます。
まずは社内資料をもとに適切な回答を返す仕組みを作り、検証を重ねながら次の段階へ進む方針です。

ここまで、AI導入前の情報整理と、Copilot Studioを選ぶまでの経緯を紹介しました。
複数のサービスを実際に使ってみると、機能の多さだけで製品を選べないことが分かります。自社で利用している環境、社員が普段使っているツール、更新や配布の方法、将来の拡張性まで含めて考える必要があります。
そして何より、AIを導入する前に、AIが参照できる社内情報を整えることが欠かせません。

次回は、Copilot Studioの実際の画面を使いながら、エージェントを作成する流れと、作り始めて見えてきた課題を紹介します。