IWE:Markdownノートをクエリ可能なナレッジグラフに変換
このプロジェクトは「Markdown knowledge graph, LSP for your editor, CLI + MCP memory for your AI agents.」を基盤として、実践的に使えるオープンソース実装を提供し、再利用可能なツールチェーンと統合手段を備えています。
ひと目でわかる
- これは何?
- IWEはローカルのMarkdownディレクトリをナレッジグラフに変換し、LSPベースのエディタ統合、CLIツール、MCPサーバーを提供して構造化されたノート検索を実現します。
- 誰に向いている?
- IWEの現在の公開ドキュメントには、READMEの「1秒未満で20,000ファイルを処理」という主張以外に、独立したベンチマークデータや詳細なパフォーマンス指標は含まれていません。リポジトリには1つの未解決イシューがあり、コミュニティディスカッションと貢献ガイドラインは公開されています。
- 商用利用できる?
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている?
- 主に Rust です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月14日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
IWEの核心:ノートをフォルダツリーではなくグラフとして扱う
IWEは、ローカルディレクトリ内のMarkdownファイルをナレッジグラフに変換します。従来のフォルダ階層とは異なり、2種類のリンクで情報を整理します。インクルージョンリンク(inclusion links)はトピックがサブトピックを含むことを示し、通常のインラインリンクはトピック間の相互参照を作成します。この構造により、1つのノートをファイルを複製することなく複数のトピックに属させることができます。例えば、「瞑想」に関するノートは「健康」と「生産性」の両方に存在できます。この設計は、データに対するユーザーの完全な所有権を重視しています。すべてのコンテンツはプレーンなMarkdownファイルであり、いつでも編集、バージョン管理、リモートリポジトリへのプッシュが可能で、クラウドサービスやプロプライエタリなデータベースに依存しません。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
`iwe find --fuzzy auth`で入口を探し、`iwe retrieve --key authentication --expand-includes 2`で親の文脈を含めて取得する流れがREADMEの例です。`iwe tree`や`iwe rename`は、検索結果を単なる文字列として扱わず、リンク構造を保ったまま整理する用途に向きます。 実行日時、版、環境、入力識別子、出力要約、警告を記録し、再現不能な結果は成功例として扱いません。
エディタ統合:LSPによるIDE機能
IWEは、VS Code、Neovim、Zed、Helixなど、サポートされているエディタにLanguage Server Protocol(LSP)統合を提供します。LSPを通じて、ユーザーは検索、ナビゲーション、プレビュー、オートコンプリート、名前変更、フォーマットなどの操作を実行できます。これらの機能は、専用のインターフェースに切り替えることなく、使い慣れたエディタ環境でナレッジグラフを閲覧・修正できるようにすることを目的としています。READMEにはこれらの機能がリストされていますが、各エディタプラグインの具体的なインストール手順や設定要件は詳しく説明されておらず、その情報は各エディタのドキュメントで確認する必要があります。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
書き込みには`expect`による対象文書数とブロック数のガードがあり、MCP経由ではこの宣言が必須です。frontmatterの型や必須項目は文書スキーマで検査され、`iwe schema validate`が同じ検査をCLIから実行します。
AIエージェントのアクセスインターフェース:CLIとMCPサーバー
IWEは、AIエージェントがノートにアクセスするための2つの方法を提供します。コマンドラインインターフェース(CLI)とModel Context Protocol(MCP)サーバーです。CLIには、`find`(ファジー検索)、`retrieve`(コンテキスト付きでノートを取得)、`tree`(階層を表示)、`squash`(サブツリーをフラット化)、`new`(ノートを作成)、`extract`(セクションを別のノートに抽出)、`inline`(リンクされたノートを親にマージ)、`rename`(ノートの名前を変更しリンクを更新)、`delete`(ノートを削除し参照をクリーンアップ)などのコマンドが含まれます。MCPサーバー(`iwec`)は、Claude Desktop、Cursor、WindsurfなどMCPをサポートするAIツールがノートを直接操作できるようにし、ファイルの変更を監視してエディタでの編集が即座に反映されるようにします。両方のインターフェースは同じ操作を公開しており、ユーザーはワークフローに基づいて選択できます。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
READMEの「20,000ファイルを1秒未満」という値は、`docs/benchmark.md`に結び付いたプロジェクト側の主張ですが、測定環境までは示されていません。導入判断では自分のMarkdown構成で速度とリンク警告を測る必要があります。
インストールと初期化
READMEには、CLIとLSPサーバーをインストールする3つの方法が記載されています。Homebrew(macOS/Linux)では`brew tap iwe-org/iwe`と`brew install iwe`、Cargoでは`cargo install iwe iwes iwec`、conda-forgeでは`conda install -c conda-forge iwe`(コミュニティメンテナンス)です。ワークスペースの初期化には`iwe init`を実行する必要があります。AIエージェント統合については、READMEにMCP設定の例が示されており、`iwec`コマンドがノートディレクトリを作業ディレクトリとして実行されます。これらのコマンドと設定はREADMEから直接引用されていますが、インストールパッケージの具体的な内容(たとえば`iwes`の役割)についてはさらなる検証が必要です。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
プロジェクトのステータスとコミュニティ情報
IWEはRustで書かれたオープンソースプロジェクトです。現在、リポジトリには1,359のスター、68のフォーク、1つの未解決イシューがあります。プロジェクトはApache 2.0ライセンスですが、リポジトリには一般的なLICENSEファイルが含まれておらず、この点は明確に指摘されるべきです。READMEは、ユーザーにディスカッションへの参加、イシューの報告、ドキュメントへの貢献を促し、コミュニティリンク(Twitter/X、Reddit、GitHub Discussions)を提供しています。プロジェクトが積極的にメンテナンスされているか、開発ロードマップがあるかについては、READMEは安定した統合インターフェースが計画されていると述べるだけで、具体的なタイムラインは示していません。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
パフォーマンスと制限の検証ポイント
READMEは、IWEが「1秒未満で20,000ファイルを処理」できると主張し、「ファジーおよび類似性検索」を検索エントリポイントとして言及しています。しかし、詳細なベンチマーク方法、ハードウェア環境、比較可能なデータは提供されていません。加えて、READMEはIWEに組み込みAIがないと述べていますが、外部AIツールとの認証や承認がどのように機能するかは説明していません。パフォーマンスデータの再現性、検索アルゴリズムの具体的な実装、セキュリティ(MCPサーバーのアクセス制御など)については、現在のドキュメントには十分な情報がなく、公式ドキュメントを確認するか、直接テストする必要があります。
`iwe init`、`iwe find --fuzzy`、`iwe retrieve --key`、`iwe schema validate`を検証用ディレクトリで実行し、Markdown、親コンテキスト、frontmatter検査の結果を確認してください。 iweのこの判断は、対象を小さく切り出して確認できることが前提です。入力値、実行日時、使用した設定、返されたデータ、終了コードを一組で保存します。期待と違う場合は、対象ファイルの内容、依存パッケージの版、環境変数、ネットワーク応答を順に照合します。READMEに記載されていない保証を補わず、確認できた事実だけを採用条件へ反映します。iweでは節ごとの機能を混ぜず、取得、変換、保存、表示のどこで差が出たかを分けて記録することが重要です。
編集部の結論
IWEの現在の公開ドキュメントには、READMEの「1秒未満で20,000ファイルを処理」という主張以外に、独立したベンチマークデータや詳細なパフォーマンス指標は含まれていません。リポジトリには1つの未解決イシューがあり、コミュニティディスカッションと貢献ガイドラインは公開されています。パフォーマンスの主張、長期的な安定性、統合のセキュリティを検証するには、公式ドキュメントやコミュニティフィードバックを確認する必要があります。
コミュニティノート