Microsoft Agent Framework for .NET最新動向：3つのAgent Skills実装と承認機構の実務ポイント

Microsoft Agent Framework for .NETの2026年4月13日時点の注目点は、Agent Skillsを「ファイル」「C#クラス」「インラインコード」の3方式で作成し、1つのProviderに混在させて動かせるように整理されたことです。さらに、スクリプト実行前に人間の承認を挟める仕組みが示されたことで、AIエージェント開発は“デモ用の自動化”から“業務システムに組み込める実装モデル”へ近づいています。Microsoft公式ブログ「Agent Skills in .NET: Three Ways to Author, One Provider to Run Them」は、.NET開発者がAIエージェントやオーケストレーションワークフローを実務に展開するうえで、かなり重要な方向性を示す内容です。(Microsoft for Developers)

Microsoft Agent Framework for .NETの最新動向を一言で言うと「混在できるAgent Skills」

Microsoft Agent Framework for .NETの今回のポイントは、Agent Skillsの作り方そのものよりも、複数のスキル提供元を1つのエージェントに自然に合成できる設計にあります。

従来のAIエージェント開発では、ツール呼び出し、プロンプト、社内ドキュメント、業務ロジック、承認フローが個別に実装されがちでした。その結果、最初は動いても、機能追加やチーム分担が進むほど保守が難しくなります。

Microsoftの投稿では、HRセルフサービスエージェントを例に、次のような現実的な開発シナリオが示されています。

開発段階	使うAgent Skillsの形	実務上の意味
最初の立ち上げ	ファイルベースのスキル	`SKILL.md`や参照資料を置くだけで始めやすい
他チームの機能を追加	C#クラスベースのスキル	NuGetパッケージとして配布・再利用しやすい
正式版を待てない機能を暫定実装	インラインスキル	アプリ内コードで素早く穴を埋められる
本番運用を意識	スクリプト承認	副作用のある処理を人間が確認できる

これは単なるAPI追加ではありません。Microsoftが、.NET開発者に向けて「AIエージェントのスキルを、小さく作り、チームごとに所有し、必要に応じて差し替えられる部品として扱う」方向へ押し出していることを示しています。

Agent Skillsとは何か

Agent Skillsは、AIエージェントに特定領域の能力を追加するためのパッケージです。Microsoft Learnでは、Agent Skillsを「instructions、scripts、resourcesを含むポータブルなパッケージ」と説明しており、エージェントが必要なタイミングで必要なコンテキストだけを読み込む「progressive disclosure」の考え方も示されています。(Microsoft Learn)

.NET開発者向けに言えば、Agent Skillsは次のようなものです。

業務手順をまとめたSKILL.md
エージェントが参照する社内ルールやFAQ
必要に応じて実行するスクリプト
C#で定義した業務ロジック
NuGetで配布できる再利用可能なスキル

たとえば経費精算エージェントなら、「申請ルールを説明する」「領収書の条件を確認する」「金額上限をチェックする」「承認フローへ送る」といった一連の業務知識をAgent Skillとしてまとめられます。

重要なのは、Agent Skillsが単なるプロンプト集ではない点です。説明文、参照資料、実行可能な処理を含められるため、AIエージェントに「答える力」だけでなく「業務を進める力」を持たせやすくなります。

3つのAgent Skills作成方式と使い分け

今回の投稿で示された中核は、.NETでAgent Skillsを作る3つの方式です。どれか1つに統一するのではなく、用途に応じて混ぜられる点が実務向きです。

ファイルベーススキル：まず始めるなら最も扱いやすい

ファイルベーススキルは、ディレクトリ内にSKILL.mdや参照ファイル、スクリプトを配置して作る方式です。Microsoft Learnでも、スキルはSKILL.mdを含むディレクトリとして構成され、必要に応じてscriptsやreferencesなどのサブディレクトリを持てると説明されています。(Microsoft Learn)

向いているケースは次の通りです。

向いているケース	理由
業務手順書をAIエージェント化したい	Markdownベースで管理しやすい
非エンジニアも内容をレビューしたい	C#コードを読まずに指示内容を確認できる
Gitでスキルを管理したい	ファイル単位で差分レビューしやすい
まず小さくPoCを始めたい	アプリ本体の設計変更を抑えやすい

たとえばオンボーディング支援エージェントなら、SKILL.mdに「社員名と入社日を確認する」「ITアカウントの有効化状況を確認する」「チェックリストを案内する」といった手順を書き、参照資料としてオンボーディングチェックリストを置けます。

ただし、ファイルベーススキルでスクリプトを実行する場合は注意が必要です。公式ブログでも、サンプルのSubprocessScriptRunnerについて、本番環境ではサンドボックス化、リソース制限、入力検証、監査ログなどを追加したRunnerを検討すべきだと説明されています。(Microsoft for Developers)

C#クラスベーススキル：チーム開発やNuGet配布に向く

C#クラスベーススキルは、AgentClassSkill<T>を継承したクラスとしてスキルを定義する方式です。公式ブログでは、[AgentSkillResource]や[AgentSkillScript]属性によって、リソースやスクリプトをFrameworkがリフレクションで検出できる例が紹介されています。(Microsoft for Developers)

この方式が強いのは、スキルをライブラリとして配布できる点です。

たとえば、社内のHRシステムチームが「福利厚生登録スキル」をNuGetパッケージとして提供し、各プロダクトチームが自分たちのエージェントに組み込む、といった運用ができます。アプリ側はスキルの内部実装を知らなくても、Providerに追加するだけで利用できます。

C#クラスベーススキルが向いている場面は次の通りです。

向いているケース	判断基準
複数アプリで同じスキルを使う	NuGet化して配布したい
スキル内でDIや既存サービスを使う	C#の型安全性や依存性注入を活用したい
テストを重視する	単体テストやCIに乗せやすい
所有チームを明確にしたい	パッケージ単位で責任範囲を分けられる

実務では、「ファイルベースで始めたスキルを、利用範囲が広がった段階でC#クラスベースに移す」という流れが自然です。最初からすべてをパッケージ化しようとすると開発速度が落ちますが、長期的に使うスキルはクラスベースのほうが保守しやすくなります。

インラインスキル：暫定実装や動的生成に強い

インラインスキルは、AgentInlineSkillを使ってアプリケーションコード内でスキルを定義する方式です。公式ブログでは、正式なNuGetパッケージがまだ提供されていない機能を一時的に実装し、後からクラスベーススキルに差し替える例が紹介されています。(Microsoft for Developers)

これは実務でかなり重要です。AIエージェント開発では、必要なスキルが最初から完全に揃っていることはほとんどありません。

たとえば次のような状況です。

別チームが正式なスキルを開発中だが、リリースは数週間後
特定顧客向けに一時的な業務ルールを追加したい
地域や部門ごとに異なるスキルを実行時に生成したい
設定値やデータベースの内容に応じてスキル内容を変えたい

この場合、インラインスキルを使えば、アプリケーションコード内で素早くスキルを定義できます。正式なパッケージが提供されたら、Providerに登録するスキルを差し替えるだけで済む設計にできます。

ただし、インラインスキルは便利な反面、乱用するとアプリケーションコードに業務知識が散らばります。長期運用する場合は、次の基準で整理するとよいでしょう。

状況	推奨
数日から数週間の暫定実装	インラインスキル
顧客別・部門別に動的生成したい	インラインスキル
複数プロダクトで共通利用する	C#クラスベース
業務部門がMarkdownでレビューしたい	ファイルベース
監査やバージョン管理を強く求められる	ファイルベースまたはC#クラスベース

1つのProviderに混在できることが実務上の大きな変化

今回の投稿で最も重要なのは、3つの作成方式を個別に紹介したことではなく、AgentSkillsProviderBuilderでそれらを1つのProviderにまとめられる点です。

イメージとしては、次のような構成です。

var skillsProvider = new AgentSkillsProviderBuilder()
    .UseFileSkill("skills")
    .UseSkill(new BenefitsEnrollmentSkill())
    .UseSkill(timeOffSkill)
    .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
    .UseScriptApproval(true)
    .Build();

この例では、ファイルベーススキル、C#クラスベーススキル、インラインスキルを同じProviderに登録しています。エージェント側から見ると、どの方式で作られたかを意識せず、ユーザーの依頼内容に応じて適切なスキルを選べます。

この設計が実務で効く理由は、次の3つです。

チームごとにスキルを所有しやすい

AIエージェント開発では、すべての業務知識を1チームが管理するのは現実的ではありません。HR、法務、経理、営業、サポートなど、それぞれの業務チームがドメイン知識を持っています。

Agent Skillsを混在できると、各チームは自分たちに合った形式でスキルを提供できます。

業務部門はMarkdown中心のファイルベース
プラットフォームチームはNuGetパッケージ
アプリ開発チームは一時的なインラインスキル
セキュリティチームは承認・監査の共通ポリシー

この分担ができると、AIエージェントを「1つの巨大なプロンプト」ではなく「複数チームが管理する能力の集合」として扱えます。

機能追加のたびにエージェント本体を作り直さなくてよい

エージェント開発で失敗しやすいのは、最初に作った設計が後から追加される業務要件に耐えられないことです。

たとえば最初はFAQ回答だけだったエージェントに、次のような機能が追加されることがあります。

申請状況の確認
社内システムへの登録
チケット作成
承認依頼
顧客別ルールの適用
監査ログ出力

このたびにエージェント本体を大きく変更すると、テスト範囲が広がり、障害リスクも増えます。Agent SkillsをProviderに追加していく形にすれば、機能単位で変更を閉じ込めやすくなります。

一時実装から正式実装へ移行しやすい

AIエージェント開発では、検証段階のスピードと本番運用の堅牢性を両立する必要があります。

最初はインラインスキルで素早く作り、利用頻度が高くなったらC#クラスベースに移行する。業務部門のレビューが必要な部分はファイルベースに分離する。このような段階的な進化がしやすいことは、長期運用では大きなメリットです。

built-in approvalが重要な理由

今回の投稿でもう1つ見逃せないのが、スクリプト実行前の承認です。公式ブログでは、UseScriptApproval(true)を設定すると、エージェントがスクリプトを実行しようとした際に即時実行せず、承認要求を返す流れが説明されています。承認されればスクリプトを実行し、拒否されればエージェントはアクションが実行されなかった理由を説明できます。(Microsoft for Developers)

これはAIエージェントを本番業務に入れるうえで非常に重要です。理由は、Agent Skillsがスクリプトや業務システムへの書き込みを含められるからです。

たとえば次の処理は、AIが自動で実行するとリスクがあります。

処理例	リスク	承認が必要な理由
福利厚生プランへの登録	誤登録、本人確認不足	従業員情報に影響する
有給残日数の更新	データ不整合	勤怠・給与に影響する
本番環境のアカウント確認	権限・情報漏えい	インフラ情報に触れる
チケットのクローズ	対応漏れ	顧客対応品質に影響する
請求処理	金銭的損失	監査・承認が不可欠

Microsoft Learnでも、human-in-the-loop approvalsについて、承認が必要な場合はエージェント実行が最終回答ではなくユーザー入力要求を返し、呼び出し側が承認または拒否を渡して再開する流れが説明されています。(Microsoft Learn)

つまり、Microsoft Agent Framework for .NETは「AIに全部任せる」方向ではなく、AIが提案・準備し、人間が重要な操作を確認する設計を取り込み始めていると読めます。

実務での設計例：社内HRエージェントの場合

今回の公式ブログではHRセルフサービスの例が使われています。これを実務設計として整理すると、次のようになります。

機能	実装方式	理由
新入社員オンボーディング案内	ファイルベース	手順書やチェックリストをMarkdownで管理しやすい
福利厚生登録	C#クラスベース	HRシステム連携や入力検証をC#で実装しやすい
休暇残日数確認	インラインスキル	正式スキルができるまで暫定対応しやすい
登録・更新処理	承認付きスクリプト	人事データへの書き込み前に確認できる
共通スキルの絞り込み	Providerのフィルタ	承認済みスキルだけを使わせられる

この構成の良い点は、機能ごとに開発速度と安全性のバランスを変えられることです。

オンボーディングのように文章中心の機能はファイルベースで素早く改善できます。一方、福利厚生登録のように業務システムへ書き込む処理は、C#で型安全に実装し、承認を挟む設計にできます。

.NET開発者が今チェックすべき実装ポイント

Microsoft Agent Framework for .NETでAgent Skillsを検討するなら、最初に見るべきポイントは「どの方式で書けるか」ではなく、「スキルのライフサイクルをどう管理するか」です。

スキル名とdescriptionはルーティング品質に直結する

Agent Skillsでは、スキルの名前と説明文が重要です。Microsoft Learnでは、descriptionはスキルが何を行い、いつ使うべきかを示す項目として説明されています。さらに、Agent Skillsは最初にスキル名と説明をエージェントへ提示し、必要になったときに詳細を読み込むprogressive disclosureの流れを取ります。(Microsoft Learn)

そのため、descriptionが曖昧だとエージェントが正しいスキルを選びにくくなります。

悪い例：

description: HR related tasks.

改善例：

description: 新入社員の入社初週に必要なITアカウント確認、必須研修、オンボーディングチェックリストを案内する。入社手続きや初期設定について質問されたときに使用する。

descriptionには、次の要素を入れると実用性が上がります。

何をするスキルか
どんな質問・依頼で使うべきか
対象ユーザーや業務範囲
使ってはいけないケースがあればその条件

AIエージェントの品質は、モデル性能だけでなく「どのスキルをいつ使うか」の判断にも左右されます。スキル説明は軽く扱わないほうがよい部分です。

スクリプトは「実行できる」より「安全に実行できる」を優先する

Agent Skillsにスクリプトを含めると、エージェントは情報提供だけでなく実操作に近づきます。これは強力ですが、同時に危険も増えます。

本番利用では、最低限次の観点をチェックすべきです。

チェック項目	確認内容
入力検証	想定外の引数、空文字、過大な値を拒否できるか
権限	スクリプトが必要以上の権限で動いていないか
実行環境	サンドボックスやコンテナで隔離できるか
リソース制限	無限ループ、大量メモリ消費、長時間実行を止められるか
監査ログ	誰が、何を、どの引数で承認・実行したか残るか
再実行性	同じ処理を複数回実行しても問題ないか
失敗時の戻し方	部分的に成功した場合の補正手順があるか

特に、AIエージェントが自律的に判断してスクリプトを呼び出す設計では、承認機構だけに頼るのは危険です。承認画面に表示する内容も重要です。

承認時には、少なくとも次の情報を人間に見せるべきです。

実行するスクリプト名
対象ユーザーや対象リソース
渡される引数
想定される変更内容
実行後に戻せるかどうか
参照したスキル名
エージェントがその操作を必要と判断した理由

「承認しますか？」だけでは、実務上の確認として不十分です。

インラインスキルは便利だが、放置すると技術的負債になる

インラインスキルは開発速度を上げますが、暫定実装がそのまま残ると保守性を下げます。

おすすめは、インラインスキルを使う時点で次のコメントや管理情報を残すことです。

// Temporary skill:
// Replace with Contoso.Hr.TimeOffSkill package when available.
// Owner: HR Systems Team
// Review date: 2026-05-31

あわせて、チケット管理システムにも「正式スキルへ移行する条件」を書いておくとよいでしょう。

移行条件の例：

月間利用回数が一定以上になった
複数アプリで同じスキルが必要になった
セキュリティレビューが必要になった
業務ロジックが複雑化した
監査ログやバージョン管理が必要になった

インラインスキルは「雑に書ける場所」ではなく、「正式化までの橋渡し」として扱うと、開発速度と保守性を両立できます。

どの方式を選ぶべきか

Agent Skillsの方式選びは、次のように考えると判断しやすくなります。

判断軸	ファイルベース	C#クラスベース	インライン
初期開発の速さ	高い	中程度	高い
非エンジニアのレビュー	しやすい	しにくい	しにくい
型安全性	低い	高い	高い
再利用性	中程度	高い	低〜中
NuGet配布	不向き	向いている	不向き
動的生成	工夫が必要	工夫が必要	向いている
暫定実装	可能	やや重い	向いている
長期保守	内容次第	向いている	放置すると弱い

迷った場合は、次の順序で始めるのが現実的です。

業務手順や参照資料が中心なら、ファイルベースで始める
業務ロジックや外部システム連携が増えたら、C#クラスベースにする
正式実装までの穴埋めや動的生成には、インラインスキルを使う
副作用のある処理には、承認と監査ログを組み込む

この流れなら、PoCから本番運用まで段階的に進めやすくなります。

Microsoftの狙いは「エージェントの部品化」と「安全な自動化」の両立

今回の投稿から読み取れるMicrosoftの方向性は、AIエージェントを単発のチャットボットではなく、企業システムに組み込める実行基盤へ進化させることです。

特に重要なのは、次の2点です。

まず、Agent Skillsを部品化し、チームや配布形態に合わせて管理できるようにしている点です。ファイル、C#クラス、インラインコードを1つのProviderに混在できることで、現場の開発プロセスに合わせた構成を取りやすくなります。

次に、スクリプト承認によって、AIエージェントの実行力にブレーキを用意している点です。AIが業務システムを操作するほど、承認、監査、権限管理は避けて通れません。Microsoft Learnのhuman-in-the-loop approvalsでも、承認が必要な関数呼び出しでは、エージェントが承認要求を返し、呼び出し側がその判断を渡して処理を継続するパターンが示されています。(Microsoft Learn)

この方向性は、.NET開発者にとって分かりやすいものです。既存のC#資産、NuGet配布、DI、テスト、CI/CD、監査ログといった開発文化を活かしながら、AIエージェントの能力を増やせるからです。

導入前に決めておきたい運用ルール

Microsoft Agent Framework for .NETでAgent Skillsを導入する前に、次の運用ルールを決めておくと失敗しにくくなります。

決めること	具体例
スキルの所有者	HRスキルはHR Systems Team、経費スキルはFinance Platform Team
命名規則	`benefits-enrollment`、`expense-validation`のように用途が分かる名前にする
レビュー方法	ファイルベースは業務部門、C#スキルは開発チーム、承認設定はセキュリティチームが確認
承認対象	書き込み処理、外部送信、本番データ参照、金銭・権限に関わる操作
ログ項目	ユーザー、スキル名、スクリプト名、引数、承認者、実行結果
昇格基準	インラインからC#クラスへ移す条件
廃止基準	使われなくなったスキルの削除・無効化ルール

特に、スキルが増えるほど「どのスキルが承認済みか」「どのエージェントから利用されているか」が見えにくくなります。共有ディレクトリやパッケージリポジトリを使う場合は、承認済みスキルだけをProviderに登録するフィルタリングも検討すべきです。

よくある失敗と回避策

すべてを1つの巨大なスキルにまとめてしまう

最初にやりがちなのが、業務領域全体を1つのSKILL.mdに詰め込むことです。これは短期的には楽ですが、エージェントが必要な情報を選びにくくなり、更新時の影響範囲も広がります。

回避策は、業務単位ではなく「ユーザーの依頼単位」でスキルを分けることです。

たとえばHRなら、次のように分けるほうが扱いやすくなります。

onboarding-guide
benefits-enrollment
time-off-balance
policy-faq
employee-profile-update

descriptionが曖昧でスキル選択を誤る

descriptionが短すぎたり抽象的すぎたりすると、エージェントが不適切なスキルを選ぶ可能性があります。

「社内手続きを支援する」では広すぎます。「新入社員の初週オンボーディング手順を案内する。アカウント、研修、備品、初回ログインに関する質問で使用する」のように、利用場面を明確に書くべきです。

承認を入れたのに、承認画面の情報が足りない

承認機構を入れても、承認者が何を実行するのか理解できなければ意味がありません。

承認UIでは、AIが生成した自然文だけでなく、実行対象、引数、変更内容、リスクを構造化して表示する必要があります。可能であれば、承認前に「読み取り専用の確認結果」を出し、その後に書き込み処理を承認させる二段階設計にすると安全です。

PoCのインラインスキルが本番に残る

インラインスキルはスピード重視の開発に向いていますが、本番で長期運用するなら責任者、テスト、ログ、移行計画が必要です。

「一時的に作っただけ」のスキルが数カ月残ると、誰も仕様を把握していない業務ロジックになります。インラインスキルには必ず所有者と見直し期限を設定しましょう。

.NET開発者が次にやるべきこと

Microsoft Agent Framework for .NETを触るなら、いきなり大規模な業務エージェントを作るより、1つの実務シナリオを選んでAgent Skills化するのが近道です。

おすすめの進め方は次の通りです。

ステップ	やること	成果物
1	既存の業務手順を1つ選ぶ	FAQ、手順書、チェックリスト
2	ファイルベーススキルにする	`SKILL.md`と参照資料
3	スクリプトが必要な処理を分ける	読み取り処理と書き込み処理の整理
4	副作用のある処理に承認を入れる	承認フローとログ設計
5	再利用したい部分をC#クラス化する	NuGet化可能なスキル
6	足りない機能をインラインで補う	暫定スキルと移行計画

最初の題材は、問い合わせ頻度が高く、業務ルールが明確で、失敗時の影響が限定的なものが向いています。たとえば社内FAQ、オンボーディング案内、申請前チェック、ナレッジ検索などです。

逆に、給与計算、契約締結、権限付与、請求処理などは、最初の題材としては重すぎます。扱う場合は、読み取り専用から始め、承認・監査・権限管理を整えてから書き込み処理へ進めるべきです。

まとめ：Agent Skillsは.NETエージェント開発を現場運用へ近づける

2026年4月13日のMicrosoft公式ブログは、Microsoft Agent Framework for .NETが、より実務的なAgent Skills authoring modelへ進んでいることを示しています。ポイントは、ファイルベース、C#クラスベース、インラインコードという異なるスキル作成方式を1つのProviderに混在させられること、そしてスクリプト実行に承認を組み込めることです。

これにより、.NET開発者は次のような設計を取りやすくなります。

小さなファイルベーススキルで素早く始める
再利用するスキルはC#クラス化してNuGetで配布する
足りない機能はインラインスキルで暫定的に補う
書き込みや本番操作には承認と監査を入れる
複数チームのスキルを1つのエージェントに合成する

AIエージェント開発で重要なのは、モデルに何でも任せることではありません。業務知識を適切に分け、実行権限を管理し、必要な場所に人間の判断を残すことです。Microsoft Agent Framework for .NETのAgent Skillsは、そのための現実的な土台になりつつあります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。