← 概念解説に戻る

Concept Fable

Semantic Kernel

先に結論:Semantic Kernel はマイクロソフトのオープンソース AI オーケストレーション SDK であり、企業アプリケーションに大規模言語モデル、プラグイン、プランナー、メモリ、ネイティブアプリケーションコードを統合することを目的としています。その中核となる抽象化には、Kernel(オーケストレーションの中核)、Plugins(Semantic Functions と Native Functions を含められる能力のカプセル化)、Planner(ユーザーの意図を多段階の実行計画に分解)、Memory(ベクトルストアによるセマンティックメモリと検索)があります。Semantic Kernel 最大の特徴はエンタープライズグレードの組み込みです。独立したサービスとして動作するのではなく、既存の .NET / Python / Java アプリケーションに組み込まれ、企業が既に持つ認証、ログ、設定、デプロイ体系を再利用します。RAG や Agent のシナリオにおいて、Semantic Kernel の価値は、AI 能力を SDK として既存の業務システムに注入することにあり、別途独立したサービスを立ち上げることではありません。

Semantic Kernel · Enterprise AI orchestration SDK

まず物語を読む。ここでは急いで定義を示さず、まず問題そのものを立ち上がらせる。

寓話

総合指令台は、すべての工房の技を覚える必要はない

王城には百工調度堂があり、手紙を書ける文士もいれば、帳簿を調べる経理係、図を描く匠人、使い走りの駅卒もいた。以前は客が複雑な用事を一つ済ませるのに、自分で各部屋の間を伝言して回らねばならず、足が棒になっても材料を漏らすことがよくあった。

新しい管事は、あらゆる技能を呼び出し可能な作業証として登録した。この者は帳簿を調べられるが、どの資料が必要か。あの者は図面を描けるが、どの形式で納品するか。駅伝の使いは手紙を届けられるが、住所と印鑑が要る。文士が一通の商業書簡を完成させたいなら、作業証に従って人を呼び、証拠を補い、下書きを描き、受領証を返送させることができる。

最初のバージョンの调度堂はとても乱れていた。文士は思いついた人を呼び、経理が必要とする資料は揃わず、駅伝は半分の住所を受け取った。客はただ「ホールはとても賢い」と感じたが、実際に用事を済ませる時には細部で詰まった。

管事は手順を書いた:まずリクエストを理解し、次に技術を選び、次に材料を渡し、次に結果を次のステップに接続する。各作業牌には、失敗時の報告方法、承認が必要な人、結果を誰に渡すかも記載する。技術を登録するだけでは不十分で、技術を順序に従って協働させる必要がある。

その後、よくある用事は小さなスイートにまとめられた。見積書の作成、在庫確認、返信の下書き、配送手配は、それぞれ組み合わせも交換もできる。客が見るのは円滑な一つのサービスだが、その裏では多様な技が約束に従ってつながっている。

ある時、経理係が一時的に閉まった。调度堂は完了したふりをせず、差し事を帳簿確認の段階で止め、文士に金額を含まない部分を先に起草するよう通知した。経理係が復旧すると、流れは続きから再開した。管事はこれで安心した。调度とはリスクを隠すことではなく、各段階を見えるようにすることだと。

调度堂の価値は、話せる文士と実行可能な工牌を組織することにある。単独の賢い人では足りず、意図、技能、記憶、手順を信頼できる流れに繋げてこそ、複雑な仕事が動く。

後に調度堂が拡張され、算盤、検品、刻印の技が加わった。管事は文士に勝手に呼びかけさせず、まず工牌とプロセスを補った。ホールが大きくなるほど、統一の取り決めが必要になる。さもなければ、技が増えるほど、客の用事は途中で途切れやすくなる。後に客は背後の工牌を見えないが、用事の断点と重複説明が減ったのを感じた。

明らかにする

この物語が語るのは:Semantic Kernel

Semantic Kernel はマイクロソフトのオープンソース AI オーケストレーション SDK であり、企業アプリケーションに大規模言語モデル、プラグイン、プランナー、メモリ、ネイティブアプリケーションコードを統合することを目的としています。その中核となる抽象化には、Kernel(オーケストレーションの中核)、Plugins(Semantic Functions と Native Functions を含められる能力のカプセル化)、Planner(ユーザーの意図を多段階の実行計画に分解)、Memory(ベクトルストアによるセマンティックメモリと検索)があります。Semantic Kernel 最大の特徴はエンタープライズグレードの組み込みです。独立したサービスとして動作するのではなく、既存の .NET / Python / Java アプリケーションに組み込まれ、企業が既に持つ認証、ログ、設定、デプロイ体系を再利用します。RAG や Agent のシナリオにおいて、Semantic Kernel の価値は、AI 能力を SDK として既存の業務システムに注入することにあり、別途独立したサービスを立ち上げることではありません。

重要なのは、それが単なる用語ではなく、実際のAI/Agentシステムで繰り返し現れる構造的な問題だという点だ。これを理解して初めて、いつモデルを足すべきか、いつプロセスを変えるべきか、いつガバナンスを補うべきかを判断できる。

メタファーのマッピング

  • 各分坊がすべての分坊の能力を把握:アプリケーションコードにすべての AI 呼び出し経路をハードコードし、拡張性が低い
  • 東家が一人で翻訳とスケジューリング:単一の LLM prompt ですべてのタスクルーティングを処理し、構造化されたオーケストレーションを欠く
  • 総合指令台は工程の詳細には関心がない:Semantic KernelのKernel抽象はタスク編成だけを担当する
  • インターフェース仕様の宣言:Plugins の関数シグネチャと説明により、Kernel が各能力で何ができるかを知る
  • タスク横断記憶帳:Semantic Kernel Memory、ベクトルストアで会話履歴、ユーザー選好、領域知識を保持
  • いくつかのステップに分けて割り当てる:Plannerが複雑な意図を多段実行チェーンに分解する
  • 標準スロット登録:プラグイン化アーキテクチャで、新機能は Plugin 形式で接続し、Kernel コアは変更しない
  • 分坊は最も得意なことだけを行う:関心の分離——LLMが推論、Pluginが実行、Kernelがオーケストレーション

Andy(任旭)判断

この概念の実戦的価値は、「賢く見えるAI機能」を納品可能、検収可能、ガバナンス可能な作業単位に分解する手助けをすることです。

pluginプランナーkernelfunctionmemoryMicrosoft Copilotスタック
京ICP备2026014272号