はじめに
こんにちは、スマートコンテンツ事業部の天野です。2025/5/18-24、MS Build に参加するため5泊7日でシアトルに行かせていただきました。少し考えれば今年の MS Build も AI 一色であろうことがわかったはずですが、AI について知識をつける時間を全く取らず。。実際セッションを受け始めて早々に「これはまずいぞ」となり、セッション後ホテルで勉強しながらなんとか噛み砕いていったという話をメインに書きたいと思います。あまりレベルが高くなくて恐縮ですが、一部でもためになるところがあればと思います。
AI のエージェント 化
初日の Keynote とそれに続くいくつかのセッションに参加し「単なる生成AI から AI エージェントとなり、（少なくとも PC ・ネット・Cloud 等電子でやり取りする世界の中では）AI が人間の代わりになれると伝えたいのだな」（かなりざっくり・・（- -; ） ）ということはわかりました。が、仕組みや土台となる技術の用語について知識「0」だったため、話が詳細に及ぶと「用語の意味や位置付けがわかってない自分」が浮き彫りに・・。
そのため、まず「AI のエージェント化」が示す要素の一つとして「AI が所定の判断のもと連携された tool を使うようになる」ことについて少し深掘りしてみました。「AI から tool として呼び出してもらう為には MCP サーバーとして機能を実装する必要がある」らしい、ことを皮切り MCP について調査し、以下のことがわかりました。
- MCP は LLM 側が持つ Function Calling（外部連携のための仕様）に沿って実装機能を呼び出せるようにIFを整備する役割
- 「サーバー」と呼ばれているのは WEB サーバーとして稼働するから （ LLM は MCP サーバーの API エンドポイントに HTTP POSTして連携する）
そして、ここにきて初めて「Azure Functionに対してMCP Extensionが提供された」の意味が理解できました・・。MCP Extension により
- Function の形のままで（少しおまじないをつける程度で）AI から呼び出し可能にラップされる
- OpenAPI 定義が自動生成される
- 認証の仕組みが提供される etc..
ということでかなり簡単に AI のための tool が作成できるようになったようです！
RAG について
MCP により AI が tool を使えるようになった、ということは RAG と呼ばれるものも MCP が仲介しているのか？という疑問が出てきたためこれも WEB や ChatGPT に聞くなどしてみました。当たり前かもしれませんが、これも MCP が IF の調整役として存在しているようです。その仲介のもと、AI 側でベクトル化されたユーザの入力を引数に外部のベクトル化された情報が検索され、その結果を AI が自然言語で返すという流れ。ベクトル検索については別途勉強することにします・・。
MS Build 中に GA となった Azure AI Foundry Agent Service（以前 Azure AI Agent Serviceと呼ばれていたもの）では RAG ベースのシステムがあっという間に作れるということだったので、個人で使っている Azure Portal から早速のぞきにいってみました。
Foundry ポータルというまた別のポータルに飛ばされ、そこで
- LLM のモデルを選んでデプロイ
- 上記 LLM にナレッジとして外部情報を追加
- Playgroud でプロンプトの調整
と流れていき、拡張・調整が終わった LLM のエンドポイントと呼び出し方のサンプルコードが吐き出されました。これは！と思い「息子が学校から持ち帰ったテストの写真撮って、それを食わせ苦手分野に沿った助言をしてもらうぞ」と考えましたが、どうやら Foundry では画像から意味を取り出してベクトル化して・・というのはまだサポートしていないようです。今後に期待できるとChatGPTが言っていました。
A2Aについて
さらに、MCP Extension で AI から tool が呼べるようになった、ということと「A2A」と呼ばれているものは別物なのか？という疑問が湧きました。「違います、エージェント同士の連携のことです」とGPTに言われましたが、「A」は万能で疲れもしないんだから A2A する必要があるのか ！？ という次の疑問が。。
異なるモデル同士を繋いでいるってことなのかな？と考えましたが、GPTによると同じモデルが使われることが多いとのこと。「1つで全部できるのになんで？」 と聞くと実際の業務に即してフローを構築する際、Agent と Agent の連携方式にした方が組み立てやすいし疎結合になるから拡張性もあるし、とのことでした。・・確かに。
GitHub Copilot
GitHub Copilot の Agent モードを使いプロンプトで「こうしてああして」というとコードを書いてくれるだけでもかなり便利ですが、GitHub 上で issue をcopilot に割り当ててタスクを実施してもらうことができるようになったとのことで、早速個人で使っている GitHub のアカウントで使ってみることに。
個人的にあるサービスの PoC を進めていたのでそのソースコードを使って実際に copilot にタスクをふってみたところ・・簡単なタスクだったからかもしれませんが、結構大雑把な自然言語でも思った通りの実装をしてくれるな、という感覚でした。実装をしてくれるだけではなくて Wiki で要求の整理とそれに対応する設計を書くこともしてくれます。レビュー時にこの Wiki を参照できるのが個人的にはかなりポイントが高いな、と感じました。
ローカルの VSC 上で copilot agent にコードサポートしてもらいながら GitHubで copilot に難易度低めのタスクを振る、という格好で進めるとかなりの時間短縮になりそうです。人間側としてはやりたいことを理路整然と説明する能力が問われるかもですね。
（補足）時差適応について
最後に時差適応力について書いておこうと思います。
時差への適応は初日が肝心、と誰かが言っていました（時差適応のため（？）に数日前に来ている人もいたくらい）が、私はかなり適応できませんでした・・w。夜1時に目が覚めそこからギンギンに冴えまくってしまい、仕方がないのでその日のセッション何受けるかの計画立てたりしていましが、案の定日中のある時間になると疲労が襲ってくるという状態。3日目になんとか適応した（のかこれは？）・・という感じでした。2日目の夜 Minecraft の音楽を聴きながら寝たのがよかったかもしれないので次（があるかわかりませんが）は初日からそうしようと思います！
