.NETでAIアプリを作るとき、モデル、ベクトル検索、RAG、外部ツール連携、エージェントをどう組み合わせればよいのか迷いやすいところです。Microsoftが2026年4月30日に公開した「Building an AI-Powered Conference App with .NET’s Composable AI Stack」は、その答えを会議支援アプリ「ConferencePulse」という具体例で示した公式記事です。
結論から言うと、この更新のポイントは「.NETでAI機能を作るための部品が、個別ライブラリの寄せ集めではなく、組み合わせ可能なスタックとして整理されてきた」ことです。Microsoft.Extensions.AIを中心に、DataIngestion、VectorData、Model Context Protocol、Microsoft Agent Frameworkを使い分けることで、RAG、AIエージェント、リアルタイム分析、外部データ連携を.NETアプリの設計に落とし込みやすくなっています。(Microsoft for Developers)
Building an AI-Powered Conference App with .NET’s Composable AI Stackで何が変わったか
今回の公式記事は、単に「.NETでAIが使える」という紹介ではありません。ConferencePulseという実例を通じて、AIアプリ開発で発生しがちな複数の課題を、.NETのComposable AI Stackでどう分解するかを示しています。
ConferencePulseは、カンファレンスやセッションで使うAI搭載アシスタントです。参加者がQRコードからセッションに参加し、投票、Q&A、リアルタイムのインサイト生成、セッション終了後の要約を行います。バックエンドでは、セッション資料、Microsoft Learnのドキュメント、GitHub Wikiなどを参照しながら回答や分析を生成します。(Microsoft for Developers)
このアプリで使われている主な構成要素は次の通りです。
| 構成要素 | 役割 | 実務での見方 |
|---|---|---|
Microsoft.Extensions.AI | AIモデル呼び出しの共通インターフェース | Azure OpenAI、OpenAI、Ollamaなどの差し替えをしやすくする |
Microsoft.Extensions.DataIngestion | 文書の読み込み、分割、加工、保存のパイプライン | RAG用ナレッジベースの前処理に使う |
Microsoft.Extensions.VectorData | ベクトルストア操作の抽象化 | QdrantやAzure AI Searchなどの切り替えをしやすくする |
| Model Context Protocol | 外部ツールやデータソースとの標準化された接続 | Microsoft Learn、社内API、外部ナレッジとAIをつなぐ |
| Microsoft Agent Framework | 複数エージェントのワークフロー制御 | 並列分析や複雑なAI処理を整理する |
| .NET Aspire | ローカル開発・サービス構成の管理 | Qdrant、PostgreSQL、Azure OpenAIなどを含む構成を扱いやすくする |
重要なのは、これらをすべて常に使う必要はないという点です。公式記事でも、単純なインサイト生成はIChatClientの1回の呼び出しで実装し、複雑なセッション要約だけにMicrosoft Agent Frameworkを使っています。つまり、AIアプリを「最初から大げさなエージェント構成」にするのではなく、必要な複雑さに応じて部品を足していく考え方が示されています。(Microsoft for Developers)
ConferencePulseとは何か
ConferencePulseは、ライブイベント向けのAI会議アシスタントです。Blazor Serverアプリとして構築され、参加者の投票や質問を受け付け、AIがその場でインサイトや回答を生成します。
公式記事で紹介されている主な機能は次の4つです。(Microsoft for Developers)
| 機能 | 内容 | 利用シーン |
|---|---|---|
| ライブ投票 | セッション内容をもとにAIが投票項目を生成 | 登壇中に参加者の理解度や関心を把握する |
| Audience Q&A | RAGを使い、セッション資料や外部ドキュメントをもとに質問へ回答 | 登壇者が拾いきれない質問を補助する |
| 自動インサイト生成 | 投票結果や質問傾向からパターンを抽出 | 参加者が何に関心を持っているかを可視化する |
| セッション要約 | 複数AIエージェントが投票、質問、インサイトを分析して要約 | イベント後のレポート作成や振り返りに使う |
この例は、カンファレンス専用に見えますが、実務ではさまざまな用途に応用できます。たとえば、社内勉強会のQ&Aボット、製品ウェビナーの参加者分析、営業向けナレッジ検索、サポート部門の問い合わせ要約などです。
.NET開発者にとって特に参考になるのは、AI機能が「画面の一部」ではなく、アプリケーション全体の設計に組み込まれている点です。UI、データ取り込み、ベクトル検索、外部ドキュメント参照、AIエージェント、監視までが一つの構成として扱われています。
Microsoft.Extensions.AIはAI呼び出しの共通土台になる
.NETのComposable AI Stackで中心になるのがMicrosoft.Extensions.AIです。これは、生成AIサービスを.NETアプリから扱うための共通的な抽象化を提供します。公式ドキュメントでは、IChatClientやIEmbeddingGeneratorなどのインターフェースを通じて、さまざまなAIサービスを一貫した形で扱えると説明されています。(Microsoft Learn)
従来のAIアプリ開発では、Azure OpenAI、OpenAI、ローカルLLM、別のAIプロバイダーを使うたびに、SDKや呼び出し方が変わりがちでした。その結果、プロバイダー変更、モデル変更、ログ取得、キャッシュ、テレメトリの実装が散らばりやすくなります。
Microsoft.Extensions.AIを使うと、アプリ側はIChatClientを中心に設計できます。ConferencePulseでも、投票生成、Q&A、インサイト生成、データ取り込み時の要約、エージェント処理などが同じAIクライアントのパイプラインを通っています。(Microsoft for Developers)
実務上のメリットは、次の3つです。
| メリット | 具体的な効果 |
|---|---|
| プロバイダー差し替えがしやすい | Azure OpenAIから別の実装へ移るとき、アプリ全体の書き換えを減らせる |
| 横断処理を入れやすい | ログ、OpenTelemetry、関数呼び出し、キャッシュなどを共通化しやすい |
| テストしやすい | AI呼び出し部分を抽象化し、モックや差し替えをしやすくできる |
ただし、抽象化は万能ではありません。モデルごとの得意分野、トークン制限、レスポンス形式、料金、レイテンシは引き続き確認が必要です。IChatClientで呼び出し方を揃えても、モデルの品質差や運用コストまで自動的に吸収されるわけではありません。
DataIngestionとVectorDataはRAGの品質を左右する
AIアプリでよくある失敗は、モデルだけに注目してしまうことです。実際には、RAGの品質は「どの情報を、どの粒度で、どのように検索できる状態にするか」で大きく変わります。
Microsoft.Extensions.DataIngestionは、文書を読み込み、整形し、チャンクに分割し、必要に応じて要約やキーワード付与を行い、ベクトルストアへ保存するためのパイプラインを提供します。Microsoft Learnの説明では、AI向けのデータ取り込みは単なる変換ではなく、文書構造や意味を保ちながら検索可能にする工程だとされています。(Microsoft Learn)
ConferencePulseでは、GitHubリポジトリからMarkdownファイルを取り込み、ヘッダー単位でチャンク化し、AIによる要約やキーワード付与を行ったうえで、Qdrantに保存しています。さらに、投票結果、参加者の質問、Q&Aの回答、AIが生成したインサイトもセッション中にナレッジベースへ取り込まれます。(Microsoft for Developers)
この設計で注目すべき点は、事前資料だけでなく「イベント中に発生したデータ」もAIの文脈に加えていることです。これにより、AIは静的なドキュメントだけでなく、その場の参加者の反応を踏まえて回答や要約を作れるようになります。
Microsoft.Extensions.VectorDataは、ベクトルストアを扱うための抽象化です。公式ドキュメントでは、単一のAPIに対して高水準のコードを書き、下位のベクトルストアを最小限の変更で切り替えられることが説明されています。(Microsoft Learn)
実務では、次のように使い分けると判断しやすくなります。
| 判断項目 | まず確認すること |
|---|---|
| 文書形式 | Markdown、PDF、Word、Webページなど、何を取り込むのか |
| チャンク分割 | 見出し単位、ページ単位、固定トークン数、意味単位のどれが合うか |
| 更新頻度 | 一度だけ取り込むのか、日次・リアルタイムで更新するのか |
| ベクトルストア | Qdrant、Azure AI Search、PostgreSQL、SQL Serverなど、運用基盤に合うか |
| メタデータ | 文書名、章、更新日、権限、出典を保存できるか |
| 検索方式 | ベクトル検索だけでよいか、キーワード検索とのハイブリッドが必要か |
RAGを実装するときは、最初から複雑なエージェントを作るより、まず「検索結果が本当に回答に使える内容か」を確認する方が効果的です。検索結果の上位に不要なチャンクが多い場合、プロンプトを調整する前に、チャンク設計やメタデータ設計を見直すべきです。
MCPはAIアプリと外部データをつなぐ標準インターフェースになる
Model Context Protocol、いわゆるMCPは、AIアプリが外部ツールやデータソースを利用するためのプロトコルです。Microsoft Learnでは、MCPを使うことでAIアプリと外部ツール・データソースの統合を標準化し、より正確で文脈に合った応答を生成しやすくできると説明されています。(Microsoft Learn)
ConferencePulseでは、MCPを2つの方向で使っています。
1つ目は、外部のMCPサーバーを利用する側です。Microsoft Learnのドキュメント検索やDeepWikiへの問い合わせを通じて、ローカルのナレッジベースだけでは足りない情報を補っています。公式記事では、Q&A機能でローカル検索、Microsoft Learn、DeepWikiを組み合わせ、その結果をIChatClientで統合して回答を作る流れが紹介されています。(Microsoft for Developers)
2つ目は、ConferencePulse自身がMCPサーバーになる側です。セッション状態やナレッジ検索機能をMCPツールとして公開することで、GitHub Copilot、Claude、独自ツールなどのMCP対応クライアントから利用できる形にしています。(Microsoft for Developers)
実務で考えると、MCPは次のような場面で役立ちます。
| 活用シーン | MCPで実現しやすいこと |
|---|---|
| 社内ナレッジ検索 | AIが社内Wiki、FAQ、チケット情報を参照する |
| 開発支援 | CopilotなどのAIツールが社内APIや仕様書を使う |
| 業務アプリ連携 | AIが在庫、顧客、契約、障害情報などを取得する |
| イベント運営 | 参加者データ、アンケート、セッション情報をAIに渡す |
| 管理者向け運用 | システム状態やログ要約をAIツールから確認する |
注意点は、MCPでつなげば安全になるわけではないことです。AIに公開するツールは、読み取り専用か、書き込み可能か、個人情報を含むか、操作ログを残せるかを明確にする必要があります。特に管理系APIや社内データを扱う場合は、認証、認可、監査ログ、レート制限を設計に入れるべきです。
Microsoft Agent Frameworkは「複雑な処理」にだけ使うのが現実的
AIエージェントという言葉は便利ですが、実装では使いどころを間違えやすい領域です。今回の公式記事で参考になるのは、ConferencePulseがすべてのAI機能をエージェント化していない点です。
たとえば、投票結果から短いインサイトを生成する処理は、IChatClientへの単純な呼び出しで十分です。一方、セッション終了後の要約では、投票分析、質問分析、インサイト分析をそれぞれ専門エージェントに担当させ、最後に統合する構成が使われています。公式記事では、このようなfan-out/fan-in型の処理にMicrosoft Agent Frameworkを使っています。(Microsoft for Developers)
Microsoft Agent FrameworkのGitHubリポジトリでは、.NETとPythonに対応し、シンプルなチャットエージェントから複雑なマルチエージェントワークフローまで構築・オーケストレーションできるフレームワークとして説明されています。(GitHub)
導入判断は、次の表で考えると分かりやすくなります。
| やりたいこと | 適した実装 |
|---|---|
| 文章を要約する | IChatClientの単純呼び出し |
| 検索結果を使って回答する | IChatClient + RAG |
| AIに必要な関数を呼ばせる | IChatClient + tools |
| 複数の専門分析を並列実行する | Microsoft Agent Framework |
| 条件分岐や段階的なワークフローを組む | Microsoft Agent Framework |
| 社外・社内ツールと標準化して連携する | MCP |
AIエージェントを導入する前に、「単純なプロンプト」「RAG」「ツール呼び出し」で足りるかを確認することが重要です。エージェント化すると柔軟性は増しますが、実行コスト、デバッグの難しさ、再現性の低下、権限管理の複雑化も増えます。
.NET管理者・開発者・プロダクト担当者への影響
今回の内容は、.NET開発者だけでなく、Microsoftエコシステムを見ている管理者やプロダクト担当者にも意味があります。AI機能が「PoCのチャットボット」から、実運用を前提にしたアプリ構成へ移りつつあるためです。
開発者が見るべきポイント
開発者にとってのポイントは、AI機能をアプリの外側に置くのではなく、既存の.NET設計パターンに近い形で組み込めることです。
Microsoft.Extensions.AIは依存性注入やミドルウェアの考え方に近く、ASP.NET Coreに慣れた開発者なら理解しやすい構成です。VectorDataやDataIngestionも、プロバイダー差し替えやパイプライン化を意識した設計になっているため、長期運用で重要になる「変更しやすさ」を確保しやすくなります。
特に意識したいのは、AI機能を次のように分けることです。
| 分類 | 例 | 設計のポイント |
|---|---|---|
| 生成 | 要約、回答、説明文作成 | プロンプト、モデル選定、出力形式を管理する |
| 検索 | 社内文書検索、FAQ検索 | チャンク、メタデータ、検索評価を重視する |
| 実行 | 投票作成、データ取得、ツール呼び出し | 関数の権限と失敗時の挙動を設計する |
| 分析 | 質問傾向、投票結果、セッション要約 | 入力データの範囲と根拠を明確にする |
| 監視 | ログ、トレース、コスト把握 | OpenTelemetryやダッシュボードで可視化する |
管理者が見るべきポイント
管理者やインフラ担当者にとっては、AIアプリが複数のサービスで構成される点が重要です。ConferencePulseでは、Blazor Server、Qdrant、PostgreSQL、Azure OpenAI、MCP、Aspireなどが組み合わされています。(Microsoft for Developers)
つまり、AIアプリの運用では、単にWebアプリをホストするだけでは足りません。ベクトルストア、AIサービス、認証、監視、ネットワーク、データ保持、コスト管理を含めた設計が必要です。
特に確認すべき項目は次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| データ保管場所 | 投票結果、質問、AI生成結果をどこに保存するか |
| 個人情報 | 参加者情報や質問文に個人情報が含まれる可能性があるか |
| 外部接続 | Microsoft Learnや外部MCPサーバーへ接続する必要があるか |
| コスト | 生成、埋め込み、検索、ログ保存のコストを見積もっているか |
| 障害時対応 | AIサービス停止時に手動運用へ切り替えられるか |
| ログ | AIの入出力やツール呼び出しをどこまで記録するか |
プロダクト担当者が見るべきポイント
プロダクト担当者にとっては、「AIを入れること」ではなく「参加者や利用者の行動をどう変えるか」が重要です。
ConferencePulseの例では、AIが単に回答するだけでなく、参加者の理解度を可視化し、登壇者の意思決定を助け、イベント後の要約まで生成します。これは、AIをUIの飾りではなく、プロダクト体験の中心に置いている設計です。
自社サービスに応用するなら、次のように考えると企画に落とし込みやすくなります。
| プロダクト課題 | AI機能の例 |
|---|---|
| ユーザーが情報を探せない | RAGによるナレッジ検索 |
| 管理者が状況を把握できない | データ要約と傾向分析 |
| 入力作業が多い | AIによる下書き生成 |
| 利用後の振り返りが弱い | 自動レポート生成 |
| 専門知識が属人化している | AIアシスタントによる問い合わせ対応 |
AI機能を入れる前に、「誰の作業時間を何分減らすのか」「どの判断を早くするのか」「誤回答が起きたとき誰が修正するのか」を決めると、PoC止まりになりにくくなります。
すぐに試すならどこから始めるべきか
公式記事では、ConferencePulseのソースコードをGitHubから取得し、aspire runで動かしてスタック全体を確認する流れが紹介されています。(Microsoft for Developers)
ただし、実務でいきなりフル構成を導入する必要はありません。初めて試すなら、次の順番が現実的です。
| ステップ | やること | 目的 |
|---|---|---|
| 1 | Microsoft.Extensions.AIで単純なチャット呼び出しを作る | AI呼び出しの共通パターンを理解する |
| 2 | OpenTelemetryやログを入れる | AI処理の見える化を始める |
| 3 | 小さな文書セットでRAGを作る | チャンク分割と検索品質を確認する |
| 4 | VectorDataでベクトルストアを扱う | ストア差し替えを意識した設計にする |
| 5 | ツール呼び出しを追加する | AIがアプリ内の関数を使えるようにする |
| 6 | MCPで外部データとつなぐ | AIの参照範囲を広げる |
| 7 | 必要な部分だけAgent Frameworkを使う | 複雑なワークフローを整理する |
最初の検証では、社内の重要データや個人情報を使わず、公開ドキュメントやサンプルデータで始めるのが安全です。RAGの検証では、回答の自然さだけでなく、検索結果の根拠、誤回答時の挙動、不要な情報を拾っていないかを確認しましょう。
実装時に失敗しやすいポイント
.NETのComposable AI Stackは便利ですが、導入すれば自動的に品質の高いAIアプリになるわけではありません。特に次の点は失敗しやすいところです。
モデル差し替えだけに期待しすぎる
Microsoft.Extensions.AIでプロバイダーを抽象化しても、各モデルの性能、料金、レスポンス速度、ツール呼び出しの安定性は異なります。抽象化は実装の柔軟性を高めるものであり、品質保証そのものではありません。
本番導入前には、代表的な質問セットを用意し、回答品質、速度、コストを比較する必要があります。
RAGのチャンク設計を軽視する
RAGでは、文書をどの単位で分割するかが重要です。チャンクが大きすぎると不要な情報が混ざり、小さすぎると文脈が失われます。
技術ドキュメントなら見出し単位、FAQなら質問単位、議事録なら議題単位など、文書の構造に合わせて分割方法を選ぶべきです。DataIngestionにはヘッダー単位やセクション単位などのチャンク戦略が用意されていますが、最適な設定はデータの種類によって変わります。(Microsoft Learn)
エージェントを最初から多用する
複数エージェント構成は魅力的ですが、最初から使うとデバッグが難しくなります。なぜその回答になったのか、どのツールを呼んだのか、どこで誤った判断をしたのかを追いにくくなるためです。
まずは単純なIChatClient呼び出しで成立するかを確認し、次にツール呼び出し、最後にAgent Frameworkという順で広げるのが安全です。
MCPツールの権限を広げすぎる
MCPは外部ツール連携を標準化しますが、AIに何でも実行させてよいわけではありません。読み取り専用の検索ツールと、データを更新するツールではリスクが大きく違います。
本番環境では、少なくとも次のルールを決めるべきです。
| 項目 | 対応例 |
|---|---|
| 認証 | MCPクライアントごとに認証を必須にする |
| 認可 | ユーザー権限に応じて使えるツールを制限する |
| 監査 | ツール呼び出し履歴を記録する |
| 承認 | 重要操作は人間の確認を挟む |
| 入力検証 | AIから渡される引数をサーバー側で検証する |
| 失敗時処理 | タイムアウト、リトライ、フォールバックを設計する |
AIの入出力をログに残さない
AIアプリは、通常のWebアプリよりも「なぜその結果になったか」を説明しにくい場合があります。そのため、ログやトレースは後回しにしない方がよいです。
ConferencePulseでも、UseOpenTelemetry()やAspire Dashboardが構成要素として紹介されています。(Microsoft for Developers) 開発初期からAI呼び出し、検索結果、ツール呼び出し、処理時間、エラーを追えるようにしておくと、本番化の判断がしやすくなります。
今回の更新をどう評価すべきか
今回の「Building an AI-Powered Conference App with .NET’s Composable AI Stack」は、.NETのAI開発が「単発のAI API呼び出し」から「アプリケーション設計の一部」へ進んでいることを示す内容です。
特に評価すべき点は、次の3つです。
| 評価ポイント | 内容 |
|---|---|
| 抽象化が.NETらしい | DI、ミドルウェア、プロバイダー差し替えなど、既存の.NET設計に近い |
| RAGからエージェントまで一貫している | DataIngestion、VectorData、MCP、Agent Frameworkが役割分担されている |
| 実例が具体的 | ConferencePulseというアプリを通じて、各技術の使いどころが分かる |
一方で、実務導入では慎重に見るべき点もあります。AI関連ライブラリや周辺サービスは更新が速く、APIや推奨構成が変わる可能性があります。また、エージェントやMCPを使う場合は、セキュリティ、監査、権限管理、コスト管理を最初から設計する必要があります。
.NET開発者が今すぐ取るべき行動は、まずMicrosoft.Extensions.AIでAI呼び出しの土台を理解し、小さなRAG構成を作ることです。そのうえで、外部ツール連携が必要ならMCP、複雑な並列分析やワークフローが必要ならMicrosoft Agent Frameworkを検討すると、過剰設計を避けながら実用的なAIアプリへ進められます。
コメント