セマンティックカーネルとは？ MicrosoftのAIオーケストレーションSDK

Microsoftスタックでソフトウェアを構築していて、Pythonサービスを別途追加することなくAIを組み込みたい場合、Semantic KernelはMicrosoftがあなたのために開発したSDKです。これは、既存のコードとAPIを大規模言語モデルに接続するオープンソースキットであり、C#、Python、Javaで動作します。このガイドでは、それが何であるか、カーネルとプラグインがどのように連携するか、そしてそのOpenAPI仕様のサポートにより、あらゆるREST APIがモデルから呼び出せるようになる仕組みについて説明します。

button

Semantic Kernelの正体とは

Semantic Kernel (SK) は、Microsoftが提供する軽量なオープンソース開発キットで、AIエージェントの構築やモデルのコードベースへの統合を目的としています。Microsoftはこれをミドルウェアと表現しており、アプリケーションとモデルの間に位置し、モデルからの要求を実際の関数呼び出しに変換して実行し、結果を返します。開発者は通常のコードを書き、モデルがそれをいつ呼び出すかを決定します。

SKが他のエージェントライブラリ群の中で際立っている点は3つあります。

まず、真の多言語対応であること。SKはC#/.NET、Python、Java向けに公式SDKを提供しており、これら3つすべてにおいてバージョン1.0以上の安定性保証があります。ほとんどのエージェントフレームワークはPythonを優先し、他の言語は後回しにされがちです。バックエンドが.NETの場合、SKはネイティブに感じられる数少ない成熟した選択肢の1つです。

次に、モデルに依存しないことです。SKは、一連のコネクタを介してOpenAI、Azure OpenAI、およびその他のプロバイダーに接続します。モデルを切り替えたい場合、アプリケーション全体を変更するのではなく、設定を変更するだけで済みます。

3つ目に、エンタープライズの懸念事項を念頭に置いて構築されていることです。テレメトリー、フック、フィルターは第一級の機能であり、AIの動作をログに記録し、監査し、傍受することができます。この重点が、Microsoftおよび多くのFortune 500企業チームがこれを採用した理由です。

カーネル、プラグイン、および関数

コアとなるオブジェクトはカーネルです。AIのための依存性注入コンテナと考えると良いでしょう。モデルコネクタとプラグインをカーネルに登録し、その後に実行を依頼します。カーネルはオーケストレーション（プロンプト、モデル呼び出し、関数呼び出し、結果、繰り返し）を処理します。

プラグインとは、モデルに公開する関数群に名前を付けたものです。関数とは、モデルが呼び出すことができる単一の機能です。関数には2つの種類があります。

ネイティブ関数は、カーネルがそれらをモデルに説明できるようにアノテーションを付ける、コード内の通常のメソッド（C#メソッド、Python関数）です。
プロンプト関数は、モデル自体を呼び出すテンプレート化されたプロンプトで、テキストの要約、分類、または書き換えに役立ちます。

C#での構造は以下の通りです。カーネルを構築し、チャットモデルを登録し、プラグインを追加し、モデルが必要に応じて関数を呼び出せるようにします。

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-4o", apiKey);
builder.Plugins.AddFromType<LightsPlugin>("Lights");
Kernel kernel = builder.Build();

// The model can now invoke LightsPlugin functions during a chat
var result = await kernel.InvokePromptAsync("Turn the kitchen light blue");

モデルが応答を返し、カーネルが`change_light_state`を呼び出したいことを認識すると、カーネルはコードを実行し、結果を取得してモデルにフィードバックします。このループがSKの核となります。

OpenAPI-to-プラグインパターン

これは最も知っておくべき機能であり、既存のサービスへの最もクリーンな架け橋となります。SKはOpenAPI仕様をインポートし、すべてのオペレーションを呼び出し可能な関数に自動的に変換できます。ラッパーコードを書く必要はありません。SKに仕様を指定するだけで、各パス/オペレーションがモデルが呼び出すことのできる関数になります。

C#では、呼び出しは`ImportPluginFromOpenApiAsync`です。Pythonでは`add_plugin_from_openapi`です。Javaにも同等のインポーターがあります。以下は、URLから仕様を読み込むC#の例です。

await kernel.ImportPluginFromOpenApiAsync(
    pluginName: "lights",
    uri: new Uri("https://example.com/v1/swagger.json"),
    executionParameters: new OpenApiFunctionExecutionParameters()
    {
        EnablePayloadNamespacing = true
    }
);

内部的には、SKは仕様を解析し、すべてのパラメータの名前、説明、型、スキーマを抽出し、そのメタデータをモデルに渡します。モデルはどのオペレーションを呼び出すべきか、どの引数を渡すべきかを推論します。その後、SKはHTTPリクエストを構築し、認証コールバックを適用して送信し、応答を読み取ります。SKはOpenAPI 2.0および3.0をサポートしており、可能な場合は3.1の仕様を3.0にダウングレードします。

ただし、人間用に書かれた仕様が必ずしもモデルにとって明確であるとは限りません。Microsoftの独自のガイダンスでは、説明的なオペレーションIDを追加し、役立つパラメータ記述を記述し、エンドポイント数を少なく保ち、緩い文字列よりも列挙型や型付きパラメータを優先することを推奨しています。仕様の品質は、エージェントがAPIをどれだけうまく呼び出すかに直接影響します。そのため、仕様自体を後回しにするのではなく、慎重に設計しテストする価値のあるものにする必要があります。

エージェントとプランニング

SKは、目標を段階的に分解する明示的なプランナーから始まりました。その後、フレームワークは関数呼び出しへと移行しました。そこでは、モデル自体がどの関数をどの順序で呼び出すかを決定し、これは最新のモデルでより信頼性の高い方法です。さらに、SKはエージェントとマルチエージェントパターンを構築するためのエージェントフレームワーク層を追加しました。これには、セッションベースのステート、エージェントループ、および外部ツールを接続するためのモデルコンテキストプロトコル（MCP）サポートが含まれます。

アプローチを比較するなら、このブログで取り上げている他のエージェントSDKとSKがどのように比較されるかを示します。

フレームワーク	主要言語	オーケストレーションモデル	最適な用途
Semantic Kernel	C#/.NET、Python、Java	関数呼び出し + エージェント	.NETおよびエンタープライズチーム
LangGraph	Python、JS	明示的な状態グラフ	複雑で分岐するエージェントフロー
Google ADK	Python	エージェント + ツールモデル	Google CloudおよびGeminiスタック
OpenAI Agents SDK	Python、JS	エージェント + ハンドオフ	OpenAI中心のアプリ

これらの中で厳密に優れているものはありません。適切な選択は、使用する言語、モデルプロバイダー、および実行に対する明示的な制御をどの程度求めるかによって異なります。

Semantic KernelとMicrosoft Agent Frameworkの位置付け

この分野の動きは速いため、現状を正直に説明します。MicrosoftはMicrosoft Agent Framework (MAF) を導入し、ドキュメントではこれをSemantic KernelとAutoGenの両方の直接の後継であり、同じチームによって構築されたものと説明しています。MAFは、AutoGenのエージェント抽象化とSKのエンタープライズ機能を組み合わせ、マルチエージェントオーケストレーションのためのグラフベースのワークフローを追加します。

それが実際に意味すること：

Semantic Kernelは安定しており、現在もサポートされています。既存のSKアプリケーションは引き続き動作し、1.0+の後方互換性保証は維持されます。
新しいエージェントプロジェクトの場合、MicrosoftはAgent Frameworkを推奨しており、SKコードを移行するための移行ガイドも公開しています。
OpenAPI-to-プラグインのアイデアは引き継がれています。仕様を介してエージェントにREST APIへのアクセスを許可するパターンは、両方のフレームワークで共通です。

したがって、SKは堅実で本番環境で実績のある、現在もメンテナンスされている選択肢として扱い、最新の投資がMAFに注がれていることを認識してください。今日決断を下すとして、すでにコードがSKにあるのであれば、緊急の対応は不要です。新たに始めるのであれば、最新の方向性を把握するために、コミットする前にMAFのドキュメントを読むことをお勧めします。

Semantic Kernelを使用するタイミング

SKに手を伸ばすべきは次のような場合です。

あなたのスタックが.NETまたはJavaであり、Pythonのサイドカーではなくネイティブに感じられるAIオーケストレーションを望む場合。
既存のREST APIのポートフォリオがあり、モデルがそれらをOpenAPI仕様を介して呼び出すことを望む場合。
テレメトリー、フィルター、フック、およびAIの動作を監査する能力といったエンタープライズ向けの基盤機能が必要な場合。
モデルに依存せず、アプリケーションを書き直すことなくプロバイダーを切り替えたい場合。

チームがPythonのみで、最新のマルチエージェント機能を絶対的に必要とする場合は、MAFまたはグラフファーストのライブラリの方が適しているかもしれません。

Semantic Kernelエージェントの背後にあるAPIのテスト

ここでAPIツールが重要になり、Apidogがうまく適合します。SKはAPIを構築したり置き換えたりするものではありません。呼び出すものです。SKエージェントは2種類のエンドポイントに依存します。1つは通信するLLMエンドポイント、もう1つはOpenAPIプラグインとしてインポートするREST APIです。どちらも正しく、適切に記述され、信頼できるものである必要があります。そうでないとエージェントは誤った呼び出しをしてしまいます。

いくつかの実用的な作業：

インポートする前にOpenAPI仕様を設計・テストしてください。SKは各オペレーションを関数に変換し、パラメータ記述をモデルにフィードするため、ずさんな仕様はずさんなツール呼び出しを引き起こします。仕様を検証し、すべてのエンドポイントを実行し、応答がスキーマと一致することを確認してください。クリーンな契約は、より良いエージェントを生み出します。
開発中は依存関係をモックしてください。まだ構築されていないエンドポイントのためにモックAPIを立ち上げたり、オーケストレーションループのデバッグ中にトークンの消費やレート制限に達するのを避けるためにLLMエンドポイントをモックしたりできます。API呼び出しをモックする方法でパターンを確認してください。
応答の形状をアサートしてください。APIアサーションを使用して、エージェントが呼び出すツールエンドポイントがモデルが期待する構造と完全に一致することを検証し、バックエンドの変更がエージェントの動作を密かに破壊しないようにします。
環境ごとにキーを管理してください。LLMとAPIの認証情報をハードコーディングするのではなく、開発、ステージング、本番環境で分離して管理してください。

これは、エージェントの代わりに行うのではなく、エージェントの前および周辺で行われる通常のAPI作業です。さらに詳しく知りたい場合は、Apidogを使ったエージェントのツール呼び出しのテストでハーネスについて詳しく説明しています。

よくある質問

Semantic Kernelは無料かつオープンソースですか？

はい。Semantic Kernelはオープンソースであり、MicrosoftによってGitHubで寛容なライセンスの下で公開されており、C#/.NET、Python、Java用のSDKが提供されています。モデルの使用料（OpenAI、Azure OpenAIなど）はかかりますが、SK自体には費用はかかりません。

Semantic Kernelはどの言語をサポートしていますか？

C#/.NET、Python、Javaで、すべてバージョン1.0以上の安定性保証があります。C# SDKが最も成熟していますが、PythonとJavaのSDKもコアカーネル、プラグイン、OpenAPIインポート機能をカバーしています。

Semantic KernelはOpenAPI仕様をどのように使用しますか？

`ImportPluginFromOpenApiAsync` (C#) または`add_plugin_from_openapi` (Python) を使用して仕様をインポートします。SKは仕様を解析し、各オペレーションをパラメータのメタデータを持つ呼び出し可能な関数に変換し、モデルがこれらのオペレーションを呼び出せるようにします。モデルはあなたの記述に依存するため、まず仕様を検証することが重要です。それは、Apidogを使用して行うことができ、ライブエンドポイントもテストできます。

Semantic KernelとMicrosoft Agent Frameworkのどちらを使用すべきですか？

既にSKアプリケーションをお持ちの場合は、そのまま使い続けてください。サポートされており、安定しています。新しいプロジェクトの場合、MicrosoftはAgent Frameworkを後継と位置づけ、移行ガイドを提供しています。この分野は急速に変化しているため、新たに始める前に現在のMAFドキュメントを確認してください。どちらが呼び出すAPIをテストするには、ApidogでChatGPT APIをテストする方法を参照してください。

まとめ

Semantic Kernelは、MicrosoftスタックのチームにAIをオーケストレーションするクリーンな方法を提供します。モデルをコードに接続するカーネル、モデルが呼び出すことができるプラグインと関数、そして既存のREST APIをエージェントツールとして公開するOpenAPIインポートパスです。これは安定しており、本番環境で実績があり、Agent Frameworkが最新の方向性を推進しています。どちらを選択しても、その下にあるAPIは依然として堅牢である必要があります。エージェントが依存する仕様とエンドポイントを設計、モック、テストするには、Apidogをダウンロードし、エージェントが呼び出す前に契約を構築してください。