M-flow を採用する前に読む: 錐体グラフと経路コストで検索を組み替える設計
A bio-inspired cognitive memory engine — a new paradigm for Graph RAG.
ひと目でわかる
- これは何？
- M-flow は Episode / Facet / FacetPoint / Entity の4層錐体グラフを検索の採点器そのものとして使う Python 製メモリエンジンである。類似度ではなく根拠経路の強さで Episode を束ねて返す点が GraphRAG との実質的な差であり、その差が効く場面と効かない場面を分けて考える必要がある。
- 誰に向いている？
- 導入を検討すべきなのは、会話ログやインシデント記録のように「出来事の単位」が明確で、かつ検索の失敗がキーワードの重なりではなく因果の取り違えとして現れる用途を持つチームである。逆に、文書をそのままベクトル化して上位 k 件を返すだけで足りる検索、あるいはグラフ構築の前処理コストを許容できないバッチ処理には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 14 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
類似度が外す問いをどう扱うか
M-flow が解こうとしているのは、検索精度の平均値を上げる話ではない。README が挙げる例は「なぜマリアは月曜のスタンドアップで怒っていたのか」という問いで、従来の検索では standup、upset、team といった語の重なりによって『効果的なデイリースタンドアップの運営方法』のような一般論が上位に来る。語の重なりは高いが、その出来事の原因ではない。README はこの状態を「Looks relevant by words, not the cause of THIS event」と表現している。
対象読者は、エージェントの長期記憶や社内ナレッジ検索を扱うエンジニアである。とくに、検索結果の上位にそれらしい文書が並ぶのに、LLM が組み立てる答えが的外れになる、という失敗を繰り返し見てきた層に向いている。M-flow の主張は「似ている」と「根拠としてつながる」は別物だという一点に集約されており、その区別を検索スコアの計算方法に落とし込むことが設計の出発点になっている。
Episode から Entity までの四層と、粒度が合う層への着地
M-flow は知識を Episode、Facet、FacetPoint、Entity の4レベルで保持する。README の表によれば、Episode はインシデントや意思決定プロセス、ワークフローのような「区切られた意味的な焦点」、Facet はその Episode のある一側面、FacetPoint は Facet から導かれた原子的な主張や事実、Entity は人物やツール、指標などの固有名で、全 Episode をまたいでリンクされる。
検索の入口はベクトル検索である。ただし M-flow は全レベルに対して網を広く投げ、クエリの粒度に合う層へ着地させる。具体的な手がかりなら FacetPoint に、広いテーマなら Facet や Episode の要約に当たる。README の例では「締め切りについて知らされていなかった」という具体的な発言が FacetPoint にアンカーし、そこから belongs to で Facet、part of で Episode へと伝播し、最終的に返るのは1つの Episode の束である。
ここで重要なのは、返却単位がチャンクではなく Episode だという点だ。マリアの発言と、彼女が参照した週末の締め切り変更の経緯が同じ束に入っているため、LLM は両方を材料に答えを組み立てられる。チャンク検索では、この2つは別々の断片として返り、片方だけが上位に来れば因果は欠ける。
関連度をスコアではなく経路として扱う仕組み
M-flow の中心にあるのは、グラフを検索の採点器そのものとして使うという判断である。クエリがアンカーに着地したあと、型付きで意味的な重みを持つ辺に沿って根拠が伝播する。ホップごとに意味的な範囲は広がるが、辺ごとにコストが加算される。README はこれを「association is not a random graph walk」と説明しており、整合の取れた低コストの経路だけが競争に残る。
各 Episode は、クエリへ至る最強の根拠チェーンによって採点される。複数の経路の合計ではなく最強の一本で決まるという点が特徴で、README は「One strong path is enough」と書いている。人間の連想が1つの手がかりから記憶全体を引き出すのに似せた設計だという説明である。
ただし、この採点方法の詳細な定義は README には書かれていない。経路コストの具体的な計算式や辺の重みの付け方は docs/RETRIEVAL_ARCHITECTURE.md に委ねられている。導入判断をするなら、この文書を読んで重み付けが自分のドメインの根拠の強さと一致するかを確認する必要がある。ここを読まずに採用すると、検索結果の並び順が直感に合わない理由を後から説明できなくなる。
導入手順と設定の勘所
対応 Python は 3.10 から 3.13 までで、ライセンスは Apache-2.0、既定ブランチは main である。最新リリースは v0.3.4 で 2026年4月12日付、リポジトリ自体の最終更新は 2026年9月1日となっている。README には Quick Start 節へのリンクがあるが、本文中にインストールコマンドそのものは引用されていないため、実際の pip 名や初期化コードはリポジトリの Quick Start を直接確認する必要がある。
確認できる周辺物は揃っている。examples/ にサンプル、docs/RETRIEVAL_ARCHITECTURE.md に経路コストの説明、OpenClaw Skill として clawhub.ai 上の mflow-memory が案内されている。MCP がトピックに含まれているため、MCP 経由でエージェントにメモリを接続する使い方が想定されていると読める。
導入時に自分で決めることになるのは Episode の切り方である。README の例では「月曜のスタンドアップでの議論」が1つの Episode になっているが、これを会議単位にするか、議題単位にするか、週単位にするかで、返ってくる束の中身は変わる。この粒度設計は設定値ではなくデータ投入側の判断であり、ここを誤るとグラフ伝播の恩恵はほとんど出ない。
向かない場面と、グラフを採点器にすることの代償
M-flow が不要な場面ははっきりしている。文書をそのままベクトル化し、上位 k 件を LLM に渡すだけで答えの品質が足りているなら、4層のグラフを構築する手間は回収できない。とくに、検索対象が静的なマニュアルや仕様書で、根拠の連鎖よりも該当箇所の抜き出しが本質である用途では、Episode という束の概念がむしろノイズになる。
もうひとつの制約は、グラフが採点器である以上、グラフの品質がそのまま検索品質になる点だ。Episode、Facet、FacetPoint への分解が雑であれば、経路コストの計算も雑な根拠の上で行われる。README は「the graph is the scoring engine」と書いており、これは裏を返せば、グラフ構築の前処理を省略できないことを意味する。投入時にコストを払う設計であり、検索時に毎回コストを払う設計ではない。
また、README が示すベンチマークの優位は自ら報告したものであり、第三者の追試結果は提示された資料からは確認できない。数値を採用根拠にするなら、自分のデータで再現を取るべきである。
GraphRAG との差はグラフの有無ではなく採点への関与
比較対象として README 自身が挙げているのは GraphRAG である。両者の違いは、グラフを持つか持たないかではない。GraphRAG 系の多くはエンティティ、関係、コミュニティ構造を追加するが、README の整理ではグラフは文脈の組織化や要約、拡張を助ける補助的な役割にとどまり、採点は依然として類似度が支配する。
M-flow はグラフを採点そのものに使う。ベクトル検索は入口を見つけるために広く網を投げる役割に限定され、そこから先の順位は経路コストが決める。この役割分担の違いが、一般論の文書が語の重なりの多さで上位に来る現象を抑える方向に働く、というのが README の主張である。
ただし、この設計は GraphRAG の上位互換ではない。コミュニティ要約のように広い問いに対して全体像を要約する用途では、GraphRAG のほうが素直に機能する。M-flow が強いのは、特定の出来事とその原因をつなぐ問いであり、網羅的な要約ではない。どちらを選ぶかは、自分の検索クエリが「どこにあるか」を聞いているのか「なぜ起きたか」を聞いているのかで決まる。
Apache-2.0 での運用と更新の見取り図
ライセンスは Apache-2.0 で、特許条項を含む寛容型ライセンスである。商用利用や改変、再配布が可能で、変更点の明示などの条件が課される。ここから先は法的助言ではないため、自社製品に組み込む場合は法務の確認を経るべきだが、少なくとも copyleft 系のように派生物の公開を強いられる構造ではない。
更新の頻度は資料から読み取れる範囲では落ち着いている。v0.3.4 が 2026年4月、最終 push が 2026年9月であり、メジャー番号がまだ 0 である点は留意したい。0.x 系は API の破壊的変更が入り得るため、Episode の投入形式や検索 API のシグネチャに依存するコードを書くなら、リリースノートを追う前提で設計したほうがよい。
README にはテストが 963 件通過したというバッジが貼られているが、これはバッジであって、テストの内容や網羅範囲を示すものではない。運用に組み込む前に、自分のデータで Episode を切り、意図した束が返るかを小規模に確かめるのが、最も費用対効果の高い検証になる。
編集部の結論
導入を検討すべきなのは、会話ログやインシデント記録のように「出来事の単位」が明確で、かつ検索の失敗がキーワードの重なりではなく因果の取り違えとして現れる用途を持つチームである。逆に、文書をそのままベクトル化して上位 k 件を返すだけで足りる検索、あるいはグラフ構築の前処理コストを許容できないバッチ処理には向かない。採用前に確認すべきは、Episode をどう切るかという運用上の判断が自分のデータで再現できるか、そして docs/RETRIEVAL_ARCHITECTURE.md に書かれた経路コストの定義を読んで、その重み付けが自分のドメインの「根拠の強さ」と一致するかを自分の目で確かめることである。
コミュニティノート