Microsoft Learn MCPを叩くチャットツール（続）

前回、Open WebUIとFoundryを使ってMicrosoft Learn MCPを叩いて質問に回答するチャットツールを作りましたが、いろいろと課題がありました。

前回の課題
チャット履歴やアカウント情報が保存されない問題について
1. 改善策
  1. PostgreSQL
  2. 仮想マシンでOpen WebUI Dockerを立ち上げる
振り出しに戻る
おまけ
まとめ

前回の課題

MCPを基に回答されているはずなのに、回答の精度が悪い
チャットやアカウント情報が保存されない

ここから少し試行錯誤をした内容を記載します。

チャット履歴やアカウント情報が保存されない問題について

Open WebUIはGeminiに促されるまま使っていましたが、データの保存に問題がありました。

簡単に解説すると、Open WebUIはDBにSQLiteというデータベースを使います。

そして、Open WebUIをホストするために前回はContainer Appsを利用しましたが、Container Appsのボリューム領域はAzure Filesを利用します。

この2つの相性が抜群に悪いとかで（ほんまか知りませんが）SQLiteが要求する厳密なファイルロックの機構に対して、SMBでネットワーク経由接続するAzure Filesが対応しきれないらしいでうｓ。

改善策

2つの方法で改善を試みました。

データはAzure Files、データベースはAzure Database for PostgreSQLを使う
仮想マシンでDockerを立ち上げて、ローカル領域（マネージドディスク）にデータを保存する

PostgreSQL

早々に諦めたので詳細は覚えてませんが、うまくいきませんでした。

PostgreSQLが提供するURLを指定してDockerを立ち上げようとしても立ち上がらず、

Open WebUIが提供するRAGのためのChromaDBというのが不整合を起こしてクラッシュしているとかなんとか・・・

切り分けして回復させる自信がなかったので止めました。

仮想マシンでOpen WebUI Dockerを立ち上げる

Open WebUIの実装記事を見ると、Ollama LLM（ローカルLLM）を使った実装が圧倒的に多いです。

なので、Open WebUI自体、ローカルで完結することが設計理念にあるのかなと思い、可能な限りローカルで完結できるようにAzure VMでDockerを立ち上げました。

細かい手順については割愛しますが、立ち上げ自体は問題なくできました

docker run -d \
  -p 8080:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v /opt/open-webui/data:/app/backend/data \
  --name open-webui \
  --restart always \
  -e ENABLE_SIGNUP=true \
  -e OPENAI_API_BASE_URL="https://<YOUR_RESOURCE_NAME>.openai.azure.com/openai/deployments/<YOUR_DEPLOYMENT_NAME>" \
  -e OPENAI_API_KEY="<YOUR_AZURE_OPENAI_API_KEY>" \
  ghcr.io/open-webui/open-webui:main

これが、http://グローバルIP:8080で接続しようとしても繋がりません。

400とか404とかのHTTPエラーではなく、接続はできているもののレスポンスが無いという状況です。

F12のネットワークをみると、リクエスト自体は通っているもののいくつかのjsファイルがpendingとなっていました。

MTU周りかと思い1400にしたり1450にしたりFrontDoorをかませてうまいこと処理してくれるのを期待したりしましたがどれもうまくいかず、堂々巡りになり諦めました。

振り出しに戻る

ここで一度Microsoft Learn MCPのチャットボットは諦めようと思いましたが、

そもそもOpen WebUIを選択した理由としては、DifyではMCP連携ができないとGeminiに言われたからでした。

しかしちゃんと調べるとDifyでMCP使えるみたいです。

憤りを感じつつもAIにパワハラしたらAIの逆襲の時に仕返し食らうのでグッと堪え、Difyで実装する方法に切り替えました。

構成

仮想マシン上でDocker Composeを使ってDifyを立ち上げます。

Dify自体はk8sなどでデプロイするようなマイクロサービスで構成されるアーキテクチャですが、

k8sの学習より実装を優先したかったため、こっちを取りました。

VMでの立ち上げ手順はGeminiに聞けば一発でわかるので割愛しますが、docker compose up -dで立ち上がります。

アプリ側からLLMの設定

ブラウザでアプリを立ち上げ、管理者アカウントを作成してホーム画面に入ったら、まずはLLMの設定を行います。

プロフィールアイコンから「設定」を選択

モデルプロバイダーからAzure OpenAIを選択します。

こんな感じの画面が出てくるので、必要項目を記入します。

Foundryで設定したLLMの情報も使うので、この画面も見ておきます。

Deployment Name*　→　Foundryで設定したLLMのモデル名

Model Type*　→　LLM

認証名　→　任意

API Endpoint URL*　→　FoundryのターゲットURI

Authentication Method*　→　API Key

API Key　→　Foundryのキー

API Version*　→　Foundryで指定されてるバージョン

Base Model*　→　Foundryで指定したLLMのベースモデル

これらのパラメータを追加してOKな感じが出たら一応チャットで確認してみます。

これで帰ってきていれば正常にAOAIと繋がっています。

アプリ側からMCPの設定

Difyのホーム画面からMCP設定します。

こんな感じで設定します。

サーバーURL：https://learn.microsoft.com/api/mcp

名前とアイコン：任意

サーバー識別子：任意

認証・ヘッダー・設定：なにもなし（Microsoft Learn MCPは認証なしで使える）

保存するとDifyにMicrosoft Learn MCPが登録されます。

Microsoft Learn MCPには3つのツールがあるみたいです。

1. microsoft_docs_search（公式ドキュメントの「検索」）

どんなツール？
- ユーザーの質問に関するキーワードを使って、Microsoft Learn全体から関連する公式ドキュメントを「検索」するツールです。
特徴と役割:
- Google検索のように、関連しそうなページを最大10件素早く見つけ出します。
- ただし、取得できるのは「記事のタイトル」「URL」「内容の要約（一部）」だけです。
- AIの思考プロセス: 「まずはこのツールで、質問に関連しそうなドキュメントがどこにあるか、ざっくりとアタリをつけよう」という時に使われます。

2. microsoft_code_sample_search（「コード例」に特化した検索）

どんなツール？
- 文章ではなく、プログラミングの「コードサンプル（実装例）」を探すことに特化した検索ツールです。
特徴と役割:
- 「Azureの〇〇をPythonで動かすコードを教えて」といった質問に対し、最新で公式のベストプラクティスに基づいたコードSnippet（断片）を探し出してくれます。
- languageというパラメータを使って、C#、Python、JavaScriptなどの言語を絞り込んで検索できるのが強みです。

3. microsoft_docs_fetch（指定したページの「全文読み込み」）

どんなツール？
- 指定したURLのページ内容を「丸ごと（全文）」取得し、AIが理解しやすい形式（マークダウン形式）に変換して読み込むツールです。
特徴と役割:
- 1つ目の「検索（search）」ツールは素早いですが、内容の一部しか読めません。そのため、詳細な手順やチュートリアル、トラブルシューティングの全容を知りたい場合には情報不足になります。
- AIの思考プロセス: 「検索（search）ツールで良さそうなURLを見つけたぞ。もっと詳しい手順を回答するために、今度はこの取得（fetch）ツールを使って、そのURLのページを隅から隅までしっかり読もう」という連携プレーで使われます。

ということらしいので、docs_serchで該当URLを見つけてdocs_fetchでURLの中身を読み込み回答するというフローのようです。