microsoft/kernel-memory とは何ですか？

Kernel Memory は文書の取り込みから埋め込み、RAG 応答までを1本のパイプラインにまとめた .NET 製のメモリサービスだ。ただし README の冒頭で自ら archived research project と明記しており、採用判断は「動くか」ではなく「サポートなしを許容できるか」から始まる。

microsoft/kernel-memory は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

microsoft/kernel-memory は今もメンテナンスされていますか？

されています。最後のコミットは 99 日前です。

microsoft/kernel-memory はどのプログラミング言語で書かれていますか？

主に C# です（GitHub の言語統計による）。

microsoft/kernel-memory 採用レビュー: アーカイブ済み研究プロジェクトの実像

ひと目でわかる

これは何？: Kernel Memory は文書の取り込みから埋め込み、RAG 応答までを1本のパイプラインにまとめた .NET 製のメモリサービスだ。ただし README の冒頭で自ら archived research project と明記しており、採用判断は「動くか」ではなく「サポートなしを許容できるか」から始まる。
誰に向いている？: Kernel Memory を採用すべきなのは、RAG パイプラインの構成要素を .NET で組み立てる際の参照実装が欲しいチーム、あるいは Docker コンテナ kernelmemory/service を社内検証環境で動かして挙動を確かめたいチームだ。逆に、本番トラフィックを預ける先を探しているなら選んではいけない。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 99 日前です。
何の言語で書かれている？: 主に C# です（GitHub の言語統計による）。

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

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · microsoft/kernel-memory

Kernel Memory が埋めようとしている溝

RAG を組むとき、作業は大きく3つに割れる。文書からテキストを取り出す処理、テキストを検索可能な単位に刻んで埋め込みを付ける処理、そして質問に対して根拠付きの回答を組み立てる処理だ。この3つは普通、別々のライブラリと別々の設定ファイルに散らばる。Kernel Memory はここを1本のパイプラインとして扱う。README は KM を multi-modal AI Service と表現し、custom continuous data hybrid pipelines によるデータセットの効率的なインデックス作成を専門とすると説明している。想定読者は、Semantic Kernel や Copilot、ChatGPT のプラグインとしてメモリを持たせたい開発者、あるいは .NET アプリに埋め込む形で検索機能を足したい開発者だ。Python から使う場合は HTTP 経由で Web サービスに投げる形になる。

取り込みパイプラインの4段階

README が示すデフォルトの文書取り込みは4段階で進む。第一にファイル形式を自動判別してテキストを抽出する。第二にテキストを検索と RAG プロンプトに使える小さなチャンクへ分割する。第三に任意の LLM 埋め込み生成器で埋め込みを計算する。第四に Azure AI Search や Qdrant といったベクトルインデックスへ保存する。この流れは Lambda アーキテクチャ図として docs/img/kernel-memory-lambda-architecture.png に置かれている。注目したいのは、この4段階が固定の関数呼び出しではなくパイプラインとして差し替え可能な形で書かれている点だ。埋め込み生成器の種類は設定キーで選ぶ。Aspire の例では KernelMemory__DataIngestion__EmbeddingGeneratorTypes__0 に OpenAI を、KernelMemory__Retrieval__EmbeddingGeneratorType に OpenAI を、KernelMemory__TextGeneratorType に OpenAI を入れている。つまり取り込み時と検索時で別々の生成器を指定できる構造になっている。

タグがアクセス制御と絞り込みを兼ねる

Kernel Memory の設計で実務上いちばん効くのは Tags だ。README はタグの用途を、private information を守るため誰が各文書を所有するかを指定すること、そして検索とファセットナビゲーションのためにデータを整理すること、の2つと説明している。C# の例では Document("doc01") に対して AddTag("user", "devis@contoso.com")、AddTag("collection", "business")、AddTag("collection", "plans")、AddTag("fiscalYear", "2025") を付けている。同じタグは Python から HTTP で投げるときにも documentId と並べて tags 配列として渡す。検索側では MemoryFilters.ByTag("user", "devis@contoso.com") のようにフィルタを当てる。ここで注意したいのは、これが認可機構そのものではないという点だ。タグはあくまで検索対象を絞る条件であり、フィルタを付け忘れたクエリは全体を対象にする。セキュリティ境界として使うなら、アプリケーション側でフィルタの付与を強制する層が別に要る。

動かし方: Docker、Aspire、組み込みの3経路

配布形態は README によれば Web サービス、Docker コンテナ、ChatGPT/Copilot/Semantic Kernel 向けプラグイン、そして .NET ライブラリの4つだ。コンテナイメージは kernelmemory/service として公開されている。.NET Aspire から使う場合のコードは README にそのまま載っており、builder.AddContainer("kernel-memory", "kernelmemory/service") に対して KernelMemory__TextGeneratorType、KernelMemory__DataIngestion__EmbeddingGeneratorTypes__0、KernelMemory__Retrieval__EmbeddingGeneratorType、KernelMemory__Services__OpenAI__APIKey を環境変数として渡す。アプリに埋め込む場合は KernelMemoryBuilder().WithOpenAIDefaults(Environment.GetEnvironmentVariable("OPENAI_API_KEY")).Build<MemoryServerless>() で MemoryServerless を組み立て、ImportDocumentAsync を呼ぶ。サービス経由なら new MemoryWebClient("http://127.0.0.1:9001") を使う。Azure へのデプロイ手順は microsoft.github.io/kernel-memory/azure と infra/README.md に分かれている。

トークン消費が見える設計と、その代償

AskAsync の結果にはトークン使用量のレポートが付く。README の出力例では Azure OpenAI: gpt-4o (TextGeneration) に対して Input 24356 tokens、Output 103 tokens と表示されている。入力が2万トークンを超えているのは、RAG で複数のチャンクをプロンプトに詰め込んでいるためだ。この数値はそのままコストに直結する。Kernel Memory は引用元へのリンク付きで回答を返す設計になっており、検証可能性を優先した結果として入力トークンが膨らむ。回答の精度を上げようと取得チャンク数を増やせば、この入力側の数値がさらに伸びる。トークンレポートが標準で付くのは、このトレードオフを開発者に意識させるためだと読める。

アーカイブ済みであることの意味

README の冒頭は CAUTION ブロックで始まる。This is an archived research project. The code serves as a learning resource, not production software. Use it with caution, and at your own risk. No support is provided. リポジトリ情報でも Archived: no となっており、GitHub 上のアーカイブフラグは立っていないが、README の宣言はそれとは別に重い。研究プロジェクトとして公開されたコードが、そのまま本番の依存先になることは想定されていない。加えて、これは an officially supported Microsoft offering ではないと本文中で明言されている。ライセンスは MIT で、これはフォークして自チームで保守することを許す。ただし MIT が保証するのはコードの利用許諾であって、動作の継続や脆弱性対応ではない。サポートの欠如を補うのは自チームの工数になる。

Semantic Kernel との役割の違い

同じ Microsoft の .NET 向け AI 基盤として Semantic Kernel がある。両者は競合しない。Semantic Kernel は LLM 呼び出し、プラグイン、関数のオーケストレーションを担う層で、Kernel Memory はその下流にある文書の取り込みと検索を担う層だ。README も Kernel Memory を Semantic Kernel のプラグインとして統合できると書いている。したがって代替を検討するなら、比較対象は Semantic Kernel ではなく、LangChain 系のドキュメントローダとベクトルストアを自前で組み合わせる構成になる。違いは統合度にある。Kernel Memory は抽出、分割、埋め込み、保存、検索、引用付き回答までを1つの API 面にまとめる。自前構成は各段階を独立に選べる代わりに、段階間のデータ形式を自分で揃える必要がある。Kernel Memory を選ぶ理由は個々の部品の性能ではなく、この統合度だ。

どのチームが使い、どのチームが避けるか

向いているのは、RAG の各段階がどう繋がるかを .NET のコードで読みたいチーム、および社内の検証環境で kernelmemory/service コンテナを立ててタグ設計やフィルタの効き方を試したいチームだ。学習リソースとしての価値は README が自認するところでもある。避けるべきなのは、SLA を前提にした本番システムだ。No support is provided という一文は、障害時に読むべき保証がないことを意味する。判断を保留すべきなのは、リリースの間隔が今後の活動量を決める場合だ。最近のリリースは packages-0.98.250508.3 (2025-05-09)、packages-0.98.250324.1 (2025-03-24)、packages-0.98.250323.1 (2025-03-24) で、バージョン番号は 0.98 台に留まっている。1.0 に到達していないことと、README の archived 宣言を合わせて読むと、API の安定性を前提にした設計は勧められない。導入を検討するなら、まず packages-0.98.250508.3 を固定して、依存する埋め込み生成器とベクトルインデックスの組み合わせが自分の環境で再現するかを確認する。その確認が取れない限り、このリポジトリは読む対象に留めておくのが妥当だ。

編集部の結論

Kernel Memory を採用すべきなのは、RAG パイプラインの構成要素を .NET で組み立てる際の参照実装が欲しいチーム、あるいは Docker コンテナ kernelmemory/service を社内検証環境で動かして挙動を確かめたいチームだ。逆に、本番トラフィックを預ける先を探しているなら選んではいけない。README は自ら archived research project と書き、No support is provided と明示している。採用前に確認すべきは3点ある。第一に、packages-0.98.250508.3 以降のリリースが存在するか。第二に、依存する埋め込み生成器とベクトルインデックスの組み合わせが自分の環境で動くか。第三に、MIT ライセンスの下でフォークして自チームで保守する覚悟があるか。この3つに答えが出ない限り、Kernel Memory は学習教材として読む対象であって、依存先として選ぶ対象ではない。

公式情報源

コミュニティノート