MENU
副業の始め方・おすすめ副業を紹介
  1. ホーム
  2. AI（GPT等）との会話や独り言
  3. Azure AI Agents を Claude Desktop などのMCPクライアントから“標準プロトコル経由で使えるようにする方法”の解説

Azure AI Agents を Claude Desktop などのMCPクライアントから“標準プロトコル経由で使えるようにする方法”の解説

AI（GPT等）との会話や独り言
著者：副業の宮殿｜製造業に携わる現役エンジニア。技術士試験対策書籍をKindleで複数出版。技術ブログ「副業の宮殿」にて製造業DX・AI活用の情報を発信中。

Introducing Model Context Protocol (MCP) in Azure AI Foundry: Create an MCP Server with Azure AI Agent Service

この記事の要点を一言でいうと 「Azure AI Agents を Claude Desktop などのMCPクライアントから“標準プロトコル経由で使えるようにする方法”の解説」です。Microsoftは「Azure側で作ったAIエージェントを、MCPという共通規格で外部ツールから呼び出せるようにしたい」という狙いがあります。(Microsoft for Developers)

背景：MCPとは？

Anthropic が提唱した Model Context Protocol (MCP) は、LLM/AIエージェント向けの“USB-C”みたいな標準規格です。

従来：

  • Claude用に個別連携
  • OpenAI用に個別連携
  • 自社アプリ用に個別API連携

→ 毎回 glue code が必要

MCP導入後：

  • AIツール側 → MCP Server
  • AIクライアント側 → MCP Client

で標準化できる。

Microsoftもこれに乗っており、Microsoft は Azure AI Foundry / Windows / GitHub / Copilot 側でMCP対応を進めています。(Microsoft for Developers)

目次

この記事でやっていること

Azure AI Agent Service 上で作ったエージェントを

  • Microsoft Azure AI Foundry
  • Claude Desktop
  • その他MCP対応クライアント

から呼び出せるようにします。

つまり構成はこうです。

Claude Desktop
   ↓
MCP Client
   ↓
MCP Server (自作)
   ↓
Azure AI Agent Service
   ↓
Azure OpenAI / Search / Functions / Data

Claude Desktopから見ると、
「Azureのエージェントがローカルツールのように見える」
というのがポイントです。

技術的な流れ

① Azure側でAgent作成

Azure AI Agent Serviceでエージェントを作る

  • モデル選択
  • 指示設定
  • Knowledge接続
  • Tool接続

ここは Microsoft 側。

② MCP Serverを作る

記事ではPython/TypeScriptでMCP serverを実装。

役割：

  • Claudeからリクエスト受ける
  • Azure Agent APIを呼ぶ
  • 結果を返す

つまり「翻訳レイヤー」。

③ Claude Desktop設定

Claude Desktop の設定ファイルにMCP serverを登録。

するとClaude上で

  • Azure検索
  • 社内DB検索
  • カスタムAgent呼び出し

などが可能になる。

(Microsoft for Developers)

なぜ重要か？

1. Azureの囲い込みを弱める

昔のMicrosoft:
「全部Azureでやってください」

今:
「ClaudeでもOpenAIでも使ってOK」

かなりオープン寄りになっています。

2. エージェントの再利用性向上

1回作れば

  • Claude
  • Copilot
  • 社内アプリ
  • IDE
  • 別Agent

から呼べる可能性がある。

3. Enterprise向け

Azureの強みはここです。

  • Entra ID
  • 権限管理
  • ログ監査
  • セキュリティ
  • 社内データ接続

単なるMCPサーバーではなく、
企業向けガバナンス付きMCP を狙っています。(Microsoft for Developers)

Microsoftの大きな戦略

最近の流れを並べるとかなり明確です。

  • GitHub Copilot Agent化
  • Windows MCP対応
  • Azure Foundry
  • Multi-agent orchestration
  • MCP対応強化

全部つなぐと

「MicrosoftをAI AgentのAWS/OSにしたい」

という戦略です。

OpenAI → モデル中心
Google → Gemini + Workspace中心
Anthropic → Claude + MCP標準主導

に対して、

Microsoft は

“企業が大量のAIエージェントを運用するための基盤”

を取りに行っています。

ReutersでもMicrosoft CTO Kevin Scottが
「エージェント同士が連携する未来には標準規格が必要」
と述べており、MCP推進はかなり本気です。(Reuters)

 

mcpはLLMにデータを利用させるためのインターフェイスですか

 

かなり近いですが、「データを利用させるためだけ」ではなく、LLMに“外部世界へアクセスさせるための標準インターフェース” と捉える方が正確です。

よく誤解されますが、MCP = RAG専用ではありません。

一番シンプルに言うと

MCPは

LLM ↔ 外部ツール/データ/アプリ

をつなぐ共通規格です。

LLM/Agent
   ↓
MCP Client
   ↓
MCP Server
   ↓
外部リソース

外部リソースには色々あります。

  • データ
  • API
  • SaaS
  • ファイル
  • DB
  • ロボット
  • 開発環境
  • OS機能

データ利用の例（よくある）

これはあなたの理解に近いです。

例:

  • Google Drive検索
  • Notion検索
  • Slack検索
  • 社内DB検索
  • GitHubコード検索

Claudeが

「社内仕様書読んで」

と言われた時にMCP経由で取りに行く。

これは従来のRAG/コネクタに近い。

ツール実行の例

こちらも重要。

  • GitHub issue作成
  • Slack送信
  • メール送信
  • カレンダー登録
  • SQL実行
  • AWS操作

つまり読むだけではなく書き込みもできる。

物理世界アクセス

ここが面白いところです。

あなたのSCOUTに置き換えると

  • move_robot()
  • capture_camera()
  • execute_vpr()
  • emergency_stop()

みたいなツールをMCP serverとして公開可能。

するとClaude/OpenAI agentが使える。

Claude
 ↓
MCP
 ↓
SCOUT executor
 ↓
ロボット

かなりMulmoChat思想に近いです。

なぜMCPが注目されているか

以前：

OpenAI plugin
LangChain tools
独自API
function calling

全部バラバラでした。

各AIごとに個別実装必要。

MCP後：

Claudeでも
OpenAIでも
Cursorでも
Copilotでも

共通化できる可能性。

Anthropicが「AI界のUSB-C」と呼ぶ理由です。

MCP ≠ モデルそのもの

MCPはモデル性能を上げる技術ではありません。

GPT-5が賢くなるわけではない。

代わりに

「何にアクセスできるか」

を増やす。

ざっくり整理

役割 例
モデル OpenAI GPT、Anthropic Claude、Google Gemini
ツール接続 MCP
実行基盤 Microsoft Azure、Amazon AWS
UI Anysphere Cursor、Microsoft Copilot
物理実行 ロボット、IoT、自動化

本質

MCPは

「LLMをチャットボットから“実行可能なエージェント”に変える接続規格」

と言うとかなり本質に近いです。

あなたが以前考えていた

AIが高レベル判断
実行層が安全にロボットを動かす

という構造、まさに今ソフトウェア業界全体で標準化しようとしている流れですね。

 

 

APIよりLLMより？

 

結論から言うと、**MCPはAPIの上位互換でもLLMの代替でもなく、「LLMがAPIを使いやすくするための標準化レイヤー」**です。

位置づけを階層で見ると分かりやすいです。

LLM（頭脳）
↓
MCP（道具の使い方の共通ルール）
↓
API / DB / SaaS / ロボットSDK（実際の機能）
↓
現実世界

APIとの違い

APIは個別仕様です。

例えば：

  • Google Google Drive API
  • Slack Slack API
  • GitHub GitHub API
  • あなたのSCOUT ROS API

全部呼び方が違う。

google_drive.search()
slack.send()
github.create_issue()
robot.move()

LLMが直接これ全部理解するのは大変。

MCP

MCPは

「このツールは何ができるか」
「必要な引数は何か」
「結果は何か」

を統一フォーマットで渡す。

例：

{
  "tool": "move_robot",
  "parameters": {
    "distance": 1.0
  }
}

裏ではROS APIでもREST APIでも何でもいい。

例えると

API = 家電ごとの専用コンセント
MCP = USB-C規格

家電そのものではない。

LLMとの違い

LLMは推論担当。

  • 会話理解
  • 計画立案
  • 推論
  • 意思決定

MCPは実行接続。

LLM単体:

「1m進んで」

→ わかるけど動けない

MCPあり:

「1m進んで」

→ robot API呼ぶ → 実際に動く

OpenAI function callingとの違い

ここが重要です。

OpenAIも function calling があるので

「MCPいらなくない？」

と思われがち。

違いは 標準化範囲。

OpenAI function calling:

  • OpenAI専用色が強い

Anthropic tool use:

  • Anthropic寄り

MCP:

  • ベンダー横断

なぜ最近重要か

Anthropic Anthropic がMCPを出す
→ Microsoft Microsoft採用
→ OpenAI OpenAIも実質類似方向
→ IDE（Anysphere Cursor など）も接続

AI業界が

「モデル性能競争」

から

「どれだけ外部世界に接続できるか」

に移りつつある。

 

あわせて読みたい

AI（GPT等）との会話や独り言
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

5億円ボタンのアバター 5億円ボタン

天才

関連記事

コメント

コメント一覧 （2件）

  • 関西の方にぶっちゃけます。

    ダラムs-1 3台設置してますが、四日連続で設定ｃ　全台やってますのでどうぞ

    ご来場ください。

    返信

    • 有益な情報ありがとうございます。
      関西の方は是非、足を運んでみてはどうでしょうか

      返信

コメントする

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

目次