モデル / データセット
microsoft/semantic-kernel avatar
microsoft/semantic-kernel

Semantic Kernelを読む:エージェント構成とMicrosoft Agent Frameworkへの移行

セマンティック カーネルは、アプリケーション コードを言語モデル、プロンプト、ツール、メモリ、エージェント ワークフローと接続します。

スター 28,562フォーク 4,769C#MIT

ひと目でわかる

これは何?
モデル、プロンプト、ツール、メモリ、複数エージェントを組み合わせるSemantic Kernelの機能と、READMEが示す後継プロジェクトへの移行を整理します。
誰に向いている?
Semantic Kernelは、アプリケーションコードから言語モデル、プロンプト、ツール、メモリ、複数エージェントを組み合わせるためのSDKとして、Python、.NET、Javaの入口を提供しています。モデルの選択肢やOpenAPI、MCP、ベクトルデータベースとの接続を一つの説明にまとめている点は、構成を検討する材料になります。
商用利用できる?
できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている?
されています。最後のコミットは 4 日前です。
何の言語で書かれている?
主に C# です(GitHub の言語統計による)。

回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Semantic Kernelの役割と後継への切り替え

Semantic Kernelは、アプリケーションコードと言語モデル、プロンプト、ツール、メモリ、エージェントのワークフローを接続するSDKです。READMEは、単純なチャットボットから複雑なマルチエージェント処理まで、AIエージェントを構築、調整、配備するためのモデル非依存の基盤として説明しています。C#を主なリポジトリ言語としながら、システム要件にはPython 3.10以上、.NET 10.0以上、JDK 17以上を挙げ、Windows、macOS、Linuxを対象にしています。

このリポジトリを読むときに最初に確認すべきなのは、README冒頭の告知です。Semantic KernelはMicrosoft Agent Frameworkになり、Microsoft Agent Frameworkがエンタープライズ向けの後継として提供されていると書かれています。1.0では安定したAPI、長期サポート、複数エージェントの調整、複数モデル提供者、A2AとMCPによるランタイム間連携を掲げています。Semantic Kernelの機能一覧だけを見て新規開発を始めるのではなく、Microsoftが案内する移行ガイドを起点に、既存コードを残すのか後継へ移すのかを決める必要があります。

モデル接続とエージェントの構成単位

機能一覧では、OpenAI、Azure OpenAI、Hugging Face、NVIDIAのサービスなど、複数のLLMへ接続できると説明されています。特定のモデルに固定せず、アプリケーション側のエージェントとサービス接続を分けることが狙いです。READMEのPython例ではChatCompletionAgentを生成し、AzureChatCompletionをサービスとして渡し、名前と指示文を設定して応答を取得します。.NET例ではKernel.CreateBuilder()でカーネルを作り、環境変数からデプロイ名、エンドポイント、APIキーを読み取ってチャット補完を登録します。

この例から読み取れるのは、エージェントの指示文、利用するモデルサービス、呼び出し側のメッセージを別の構成要素として扱う設計です。応答の正確性、コスト、レート制限、失敗時の再試行、プロンプトインジェクションへの耐性までがREADMEで証明されているわけではありません。実装を評価する場合は、モデルの切り替えが本当に設定だけで済むか、応答履歴をどこに保存するか、タイムアウトと例外をどう扱うかを対象コードと公式文書で確認してください。

プラグイン、構造化出力、MCPの接続面

Semantic Kernelは、ネイティブコード関数、プロンプトテンプレート、OpenAPI仕様、Model Context Protocolをプラグインの入口として挙げています。Pythonの例ではMenuPluginクラスにkernel_functionデコレーターを付け、メニューの特別料理を返す関数をエージェントへ渡します。.NETではKernelPluginFactory.CreateFromType<MenuPlugin>()によってカーネルへプラグインを登録する流れです。自然言語を受けるエージェントが、決められた関数を選び、結果を会話へ戻す構成を小さな例で示しています。

ツール呼び出しを導入すると、モデルの出力が外部処理を起動する境界になります。関数にどの引数を許可するか、読み取りだけか書き込みも許すか、実行者をどう識別するか、失敗結果をどのように会話へ伝えるかを設計しなければなりません。READMEはプラグインと構造化出力を機能として示していますが、各業務の権限設計や監査方法を提供するものではありません。OpenAPIやMCPを接続する場合も、公開するツールの一覧、入力検証、秘密情報の境界をアプリ側で定義する必要があります。

マルチエージェントと業務フローの分解

マルチエージェント機能は、役割の異なる専門エージェントを協調させ、複雑な処理を組み立てる考え方です。READMEのPython例は、請求を扱うBillingAgentと返金を扱うRefundAgentを別々に定義する形で始まります。請求方法、支払い周期、手数料、請求の不一致、支払い失敗と、返金資格や返金状況を別の指示文に分け、単一の会話担当へ全責任を集中させない例です。

この分割は、業務境界をコード上で明示するための教材になります。ただし、複数のエージェントがどの順序で動くか、最終判断者を誰にするか、同じ依頼を重複実行しないか、会話履歴と個人情報をどう共有するかは、導入するシステム側で決める項目です。READMEが「協調」を掲げても、業務処理の正しさや人間の承認を自動的に保証するわけではありません。Process Frameworkも複雑な業務プロセスを構造化する機能として挙げられていますが、実際のワークフロー、補償、停止条件は対象版のドキュメントで確認すべきです。

ベクトル検索とマルチモーダル入力の位置づけ

機能一覧には、Azure AI Search、Elasticsearch、Chromaなどのベクトルデータベースとの統合が記載されています。文書や記録をベクトル化して検索し、エージェントの回答へ参照情報を渡す構成を検討できます。テキストだけでなく、視覚と音声の入力を処理するマルチモーダル対応、Ollama、LMStudio、ONNXを使ったローカル実行も挙げられています。外部モデルへの接続だけを前提にせず、データの置き場所と実行環境を選べる設計を示している点が特徴です。

ただし、統合と品質は別に評価します。検索結果の順位、埋め込みモデル、データ更新、削除要求の反映、アクセス制御、音声や画像の保存先について、素材のREADMEは具体的な基準を示していません。ローカル実行も、利用できるモデル、端末性能、対応するAPI、ライセンスが環境ごとに異なります。導入時は小さな非機密データで検索精度と応答経路を観測し、入力、検索文脈、モデル応答、ツール実行のログをどこまで残すかを先に決めてください。

三つの言語ランタイムとインストール手順

インストール手順は、AIサービスの認証情報を環境変数へ設定してから始めます。Azure OpenAIではAZURE_OPENAI_API_KEY、OpenAIではOPENAI_API_KEYを使う例がREADMEにあります。Pythonはpip install semantic-kernel、.NETはMicrosoft.SemanticKernelとMicrosoft.SemanticKernel.Agents.Coreをdotnet add packageで追加し、Javaはsemantic-kernel-javaのBUILD.mdを参照します。言語別の依存関係を同じものとして扱わず、対象ランタイムの公式手順を選ぶ構成です。

APIキーをシェル履歴、ソースコード、CIログへ書き込まないことが初期設定の前提になります。サンプルは環境変数を読んでいますが、キーのローテーション、権限分離、利用額の上限、ログのマスキング、開発環境と本番環境の分離までは説明していません。PythonのBasic Agent例は非同期で応答を取り出し、.NET例はKernelを構築してChatCompletionAgentへ渡します。まず各言語で最小応答を確認し、次にプラグイン、検索、複数エージェントを一つずつ加える順序が、原因を切り分けやすい評価手順になります。

移行、ライセンス、採用判断

Semantic Kernelのメタデータ上のライセンスはMITです。コードの利用や改変を検討する際は、リポジトリのLICENSEと依存パッケージの条件を確認します。MIT表記は、接続先のOpenAI、Azure OpenAI、Hugging Face、NVIDIA、ベクトルデータベースの利用規約や料金、入力データの権利を置き換えるものではありません。エージェントが取得した顧客情報をモデルへ送る場合は、データの所在、保持、第三者処理、削除を別の審査項目にします。

新規プロジェクトで採用を検討する場合は、READMEが案内するMicrosoft Agent FrameworkとSemantic Kernelの移行ガイドを先に読みます。既存プロジェクトで継続する場合は、Python、.NET、Javaの対象版、パッケージのリリース履歴、利用中のエージェントAPI、プラグイン、履歴保存を一覧化し、移行時の置換範囲を確定します。結論として、Semantic KernelはAIエージェントとツール連携の構成を学ぶ資料としては有用ですが、現行の長期基盤と断定するには後継への移行状態を確認する必要があります。最初に試すべきなのは、機能数の比較ではなく、現在の推奨ランタイムと自分の業務で許される権限境界が一致しているかの確認です。

編集部の結論

Semantic Kernelは、アプリケーションコードから言語モデル、プロンプト、ツール、メモリ、複数エージェントを組み合わせるためのSDKとして、Python、.NET、Javaの入口を提供しています。モデルの選択肢やOpenAPI、MCP、ベクトルデータベースとの接続を一つの説明にまとめている点は、構成を検討する材料になります。ただし、README冒頭はSemantic KernelがMicrosoft Agent Frameworkへ移行し、後者が後継であると明記しています。新規採用では移行ガイドを先に読み、既存コードの継続では対象言語の版、API差分、認証情報の管理、エージェントが呼び出すツールの権限を検証してから範囲を決めるべきです。

公式情報源

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
コミュニティノート

コミュニティノート