2026年6月9日に公開された「ICYMI: Inside the Microsoft Agent Framework: How we designed a layered SDK」は、新バージョンの配布や仕様変更を告知する記事ではありません。Microsoftの技術メディア「Command Line」に掲載された設計解説を、Microsoft Agent Frameworkの開発者ブログで改めて紹介したものです。
そのため、今回の投稿だけを理由に設定変更やパッケージ更新を行う必要はありません。重要なのは、Microsoft Agent Frameworkを「Agent loops」「Workflows」「Harnesses」の3層で設計し、単純なチャットから複雑なマルチエージェント処理まで段階的に構築できる方針が示された点です。(Microsoft for Developers)
Semantic Kernel DevBlogsの2026年6月9日更新で何が変わったのか
今回のSemantic Kernel DevBlogs関連の更新は、実装変更を伴うリリースノートではなく、Microsoft Agent Frameworkの設計思想を理解するための「ICYMI」、つまり見逃した人向けの再案内です。
確認結果を整理すると、次のようになります。
| 確認項目 | 今回の発表内容 | 利用者の対応 |
|---|---|---|
| 新機能 | 新しい機能の提供開始ではない | 即時対応は不要 |
| 設定 | 必須の設定変更は示されていない | 現行設定を維持できる |
| パッケージ更新 | 対象バージョンや更新コマンドの案内はない | 更新履歴を別途確認する |
| 移行 | Semantic Kernelからの移行期限は示されていない | 対象システムの棚卸しを始める |
| 料金 | 料金改定の発表はない | モデルやホスティングの料金を個別に確認する |
| 対応期限 | 期限の指定はない | 正式なライフサイクル告知を継続監視する |
投稿本文には、特定のパッケージ名、更新バージョン、料金、強制移行日などは記載されていません。設定変更を急ぐよりも、自社のAIエージェントを3層のどこまで作り込むべきか検討することが、今回の情報に対する適切な対応です。(Microsoft for Developers)
Microsoft Agent Frameworkを構成する3つの層
今回の設計解説では、Microsoft Agent Frameworkの中心概念として、Agent loops、Workflows、Harnessesの3つが挙げられています。
| 層 | 役割 | 適した用途 |
|---|---|---|
| Agent loops | モデルの推論、ツール実行、結果確認を繰り返す | チャット、検索、単一エージェント |
| Workflows | 処理順序や分岐、複数エージェントの連携を制御する | 承認処理、業務フロー、長時間タスク |
| Harnesses | ツール、メモリ、権限、ログなどの実行環境を整える | 本番運用、セキュリティ、監査対応 |
Agent loopsはエージェントの基本動作
Agent loopは、次の処理を目的が達成されるまで繰り返す仕組みです。
- ユーザーやシステムから入力を受け取る
- モデルが状況を判断する
- 必要に応じてツールやAPIを呼び出す
- 実行結果をコンテキストへ追加する
- 次の処理を判断する
- 完了したら回答や成果物を返す
通常のチャットでは「質問を受けて回答する」だけですが、AIエージェントでは、データベース検索、ファイル確認、コード実行、他のエージェントへの引き継ぎなどが途中に入ります。
Agent loopを明示的に管理することで、使用可能なツールの制限、危険な操作の承認、会話履歴の圧縮、処理ログの記録といった制御を組み込みやすくなります。(Command Line)
Workflowsは予測可能な業務処理を作る
自由に判断するAgent loopは柔軟ですが、企業システムでは処理順序や承認条件を固定したい場面があります。
たとえば問い合わせ対応を自動化する場合、次のような流れが考えられます。
- 問い合わせ内容を分類する
- 顧客情報を取得する
- 回答案を作成する
- 社内ポリシーに違反していないか確認する
- 必要な場合は担当者へエスカレーションする
Microsoft Agent FrameworkのWorkflowsでは、順次実行、エージェント間の引き継ぎ、作成者と評価者による反復、調整役を置いたマルチエージェント処理、独自フローなどを構成できます。
すべてをAIへ任せるのではなく、失敗時の影響が大きい処理には、人間の確認や明示的な分岐を入れることが重要です。(Command Line)
Harnessesは本番運用に必要な周辺機能
Harnessesは単独の製品名というより、エージェントを安全かつ継続的に動かすための実行環境を表す設計概念です。
具体的には、次の要素が含まれます。
- ファイル操作やコード実行などのツール
- システムプロンプトや業務コンテキスト
- 会話履歴や長期メモリ
- サブエージェント
- 権限チェック
- 人間による承認
- コンテキストの圧縮
- ログ、トレース、監視
- ミドルウェア
高性能なモデルを使っても、参照情報が不正確で、ツールの権限が広すぎ、実行履歴を確認できなければ、本番システムとしては安全に運用できません。モデル選定だけでなく、周辺のHarnessesまで含めて設計することが今回の重要なポイントです。(Command Line)
Semantic Kernel利用者に関係する実務上の変更点
Microsoft Agent Frameworkは、AIエージェント開発におけるSemantic KernelとAutoGenの後継として位置付けられています。2026年4月3日には.NETとPythonのバージョン1.0が発表され、安定したAPIを備える本番向けリリースとなりました。(Microsoft Learn)
ただし、Semantic Kernel全体が直ちに利用できなくなるわけではありません。影響が大きいのは、Semantic KernelのAgent Frameworkを使っている開発者や、これから新しいAIエージェントを構築するチームです。
代表的な違いは次のとおりです。
| 項目 | Semantic Kernel | Microsoft Agent Framework |
|---|---|---|
| 基本構成 | Kernelを中心にサービスやプラグインを構成 | AgentまたはAIAgentを中心に構成 |
| .NET名前空間 | Microsoft.SemanticKernel | Microsoft.Agents.AI |
| Pythonパッケージ | semantic-kernel | agent-framework |
| ツール登録 | KernelFunctionやPluginを使用 | 関数やツールを直接登録できる |
| 実行メソッド | Invoke、InvokeStreaming | Run、RunStreaming |
| 会話状態 | 呼び出し側がスレッド種別を意識する | エージェントがセッションやスレッドを作成する |
| エージェント型 | サービスごとに異なるクラスが多い | 共通のエージェント抽象化へ集約 |
単純な名前変更だけではなく、依存性注入、ツール登録、戻り値、ストリーミング、会話状態の管理方法まで変わります。パッケージだけを置き換える一括移行は避け、機能単位で動作を確認する必要があります。(Microsoft Learn)
誰に影響するのか
一般ユーザー
一般ユーザー向けの画面や操作方法を変更する発表ではありません。利用中のアプリケーションがSemantic KernelやMicrosoft Agent Frameworkを内部で使用していても、今回の投稿だけで利用者側の設定変更が発生することはありません。
新規開発を始める開発者
新しいAIエージェントを.NETまたはPythonで開発する場合は、Microsoft Agent Frameworkを第一候補として比較する段階です。
ただし、最初からマルチエージェントや複雑なWorkflowを導入する必要はありません。単一のモデル呼び出しや通常の関数で解決できる処理に、エージェントを使うとコストと障害点が増えます。まずAgent loopだけで構築し、処理順序や承認が必要になった時点でWorkflowを追加する方法が現実的です。(Microsoft Learn)
Semantic Kernelでエージェントを運用している開発者
既存システムを直ちに停止する必要はありませんが、今後追加する機能をSemantic KernelとMicrosoft Agent Frameworkのどちらで実装するか、方針を決める必要があります。
特に次の機能を使っている場合は、移行調査の優先度が高くなります。
ChatCompletionAgentAzureAIAgentOpenAIAssistantAgentKernelFunction- 複数エージェントのオーケストレーション
- プロバイダー固有のスレッド管理
InvokeAsyncやInvokeStreamingAsyncへの依存
管理者・セキュリティ担当者
エージェントがAPI、ファイル、シェル、業務システムなどを操作する場合、管理者はモデル設定だけでなく、ツール権限、承認フロー、ログ、データの保存場所まで確認する必要があります。
第三者のモデル、エージェント、サーバーを接続する場合は、独自の利用条件や料金が適用される可能性があります。データが組織の管理境界や地域外へ送信されないかも確認が必要です。(Microsoft Learn)
設定・更新・移行で確認すべきポイント
現在の利用箇所を棚卸しする
最初に、Semantic Kernelをインストールしているかだけでなく、エージェント機能を実際に使っているかを確認します。
最低限、次の情報を一覧化してください。
| 確認対象 | 確認内容 |
|---|---|
| 言語 | .NETまたはPython |
| パッケージ | 現在のパッケージ名とバージョン |
| エージェント | 使用中のエージェントクラス |
| プロバイダー | Foundry、Azure OpenAI、OpenAIなど |
| ツール | 外部APIや業務処理への接続 |
| 状態管理 | スレッド、セッション、会話履歴の保存方法 |
| 運用制御 | 承認、再試行、タイムアウト、ログ |
| データ | 保存場所、保持期間、削除方法 |
小さい機能から移行する
全面移行ではなく、副作用の少ない機能を1つ選んで検証します。
たとえば、社内情報を検索して回答するだけのエージェントを先に移行し、その後にデータ更新やメール送信などの操作系ツールを移す方法です。
Pythonでは、既存のKernelFunctionをAgent Frameworkのツールへ変換する互換機能も案内されています。この機能にはsemantic-kernel 1.38以降が必要です。既存資産を一度に書き直さず、段階的に移行できます。(Microsoft Learn)
.envの読み込みを明示する
Microsoft Agent Frameworkは、.envファイルを自動的には読み込みません。
Pythonで.envを使用する場合は、アプリケーション開始時にload_dotenv()を呼び出すか、シェルやIDEで環境変数を設定します。Semantic Kernel側の動作を前提に移行すると、APIキーやエンドポイントが読み込まれず、起動時に失敗する可能性があります。(Microsoft Learn)
会話履歴の削除方法を確認する
Agent Frameworkの共通セッション型には、すべてのプロバイダーで使用できる一律の履歴削除APIがありません。
サービス側に会話履歴を保存する構成では、作成したセッションIDをアプリケーション側で管理し、必要に応じて各プロバイダーのSDKから削除する設計が必要です。個人情報や機密情報を扱う場合は、移行前に削除処理と保持期間をテストしてください。(Microsoft Learn)
料金と移行期限はどうなるのか
今回の2026年6月9日の投稿では、料金変更や新しい課金体系は発表されていません。
Microsoft Agent Framework本体はMITライセンスで公開されていますが、実際のシステム運用では次の費用が発生する可能性があります。
- モデルAPIの入力・出力料金
- Microsoft FoundryやAzureリソースの利用料金
- データベースやベクトル検索の料金
- ログ、トレース、ストレージの料金
- 外部ツールや第三者サービスの料金
- 長時間実行や再試行による追加消費
SDKがオープンソースであることと、構築したエージェントを無料で運用できることは別です。開発前に、1回の処理で呼び出すモデル回数、最大トークン、ツール実行回数、再試行上限を決めてください。(GitHub)
移行期限についても、6月9日の投稿では指定されていません。過去の公式説明では、Semantic KernelはMicrosoft Agent Frameworkの一般提供開始後も少なくとも1年間サポートし、重大な不具合やセキュリティ問題へ対応する方針が示されています。ただし、これは正式なSemantic Kernelの終了日を指定するものではありません。(Microsoft for Developers)
今回の変更を受けて実施すべきこと
一般ユーザーは、今回の投稿に対して操作や設定を変更する必要はありません。
新規のAIエージェント開発では、まずMicrosoft Agent Framework 1.0を評価し、単純な処理はAgent loop、処理順序を固定する場合はWorkflow、本番運用ではHarnessesまで設計します。
Semantic Kernelで既存エージェントを運用しているチームは、パッケージをすぐに置き換えるのではなく、エージェントクラス、ツール、セッション、ストリーミング、データ削除の順に棚卸ししてください。そのうえで、副作用の少ない機能を1つ選び、Microsoft Agent Frameworkで同じ結果を再現できるか検証するのが安全です。
コメント