Flaiwheel

flaiwheel MCP server Available on Glama

AIコーディングエージェントのためのセルフホスト型メモリ＆ガバナンスレイヤー。あらゆるバグ修正を永続的な知識に変えましょう。クラウドゼロ。ロックインゼロ。

🚀 Flaiwheelが存在する理由

AIコーディングエージェントは、セッション間で全てを忘れてしまいます。それが、繰り返されるバグ、失われたアーキテクチャの決定、そして知識の劣化につながります。

Flaiwheelは以下を保証します：

エージェントがコーディング前に検索する
エージェントが修正後にドキュメント化する
コミットが自動的に知識をキャプチャする
メモリが時間とともに蓄積される

バグを修正するたびに、次のバグの修正コストが下がります。

Related MCP server: MCP VectorStore Server

🧠 Flaiwheelの違い

蓄積される永続的なAIメモリ — セッション間で知識がリセットされません。
Gitネイティブな自動化 — コミットが自動的に構造化された知識になります。
単なるストレージではなくガバナンス — 品質ゲートと強制的なドキュメント化。
ハイブリッド検索 + リランキング — 実際のコードベースに対する高精度なコンテキスト。
完全セルフホスト — 単一のDockerコンテナ、外部インフラ不要。
ロックインゼロ — すべての知識がGit内の構造化されたフラットファイルとして保存されます。

✅ Flaiwheelの対象ユーザー

実際のプロジェクトでAIコーディングアシスタントを使用しているエンジニアリングチーム
繰り返されるバグがコストのかかるコードベース
完全なデータ制御を必要とするチーム
AIネイティブな開発環境

❌ 対象外

数千行未満の小規模な趣味のプロジェクト
より良いオートコンプリートだけを求める開発者
セルフホストに興味のない純粋なSaaSワークフロー

🆚 Flaiwheelの立ち位置

AIコーディングツールはコードを生成します。
RAGツールはドキュメントを検索します。
Flaiwheelは、あなた自身のインフラ内で構造化されたエンジニアリング知識を管理し、蓄積します。

これはAIアシスタントを置き換えるものではありません。大規模な開発において、AIを信頼できるものにします。

📄 ホワイトペーパー (PDF) — ビジョン、アーキテクチャ、設計の詳細。

⚙️ 主な技術的特徴

Flaiwheelは、3つのレベルで動作する自己完結型のDockerサービスです： Pull — エージェントがコーディング前に検索する (search_docs, get_file_context) Push — エージェントが作業中にドキュメント化する (write_bugfix_summary, write_architecture_doc, …) Capture — AIエージェントがいなくても、post-commitフックを介してGitコミットが自動的に知識をキャプチャする

プロジェクトのドキュメント (.md, .pdf, .html, .docx, .rst, .txt, .json, .yaml, .csv) をベクトルデータベースにインデックス化します
AIエージェント (Cursor, Claude Code, VS Code Copilot) が接続するためのMCPサーバーを提供します
ハイブリッド検索 — セマンティックベクトル検索とBM25キーワード検索をReciprocal Rank Fusion (RRF) で組み合わせ、両方の利点を活かした検索を実現します
クロスエンコーダーリランカー — 語彙の不一致クエリに対して大幅に高い精度を実現するため、クロスエンコーダーモデルで候補を再スコアリングするオプションのステップ
行動指令 — AIエージェントは、すべての応答の前にFlaiwheelを静かに検索し、すべてのタスクの後に自動ドキュメント化し、再作成する前に再利用します。これらすべてが指示なしで行われます
get_file_context(filename) — エージェントが編集しようとしているファイルの空間的知識をプリロードします（完全な時間的・空間的コンテキストのために get_recent_sessions を補完します）
post-commit git hook — すべての fix:, feat:, refactor:, perf:, docs: コミットを構造化された知識ドキュメントとして自動的にキャプチャします
リビングアーキテクチャ — AIエージェントは、システムコンポーネントとフローの自己更新型Mermaid.js図を維持するように指示されます
実行可能なテストフロー — テストシナリオは、QA自動化のために機械可読なBDD/Gherkin形式 (Given, When, Then) でドキュメント化されます
バグ修正から学習 — エージェントがバグ修正の要約を書き、それが即座にインデックス化されます
構造化された書き込みツール — ソースで品質を強制する7つのカテゴリ別ツール（バグ修正、アーキテクチャ、API、ベストプラクティス、セットアップ、変更履歴、テストケース）
プリコミット検証 — validate_doc() が知識ベースに入る前に自由形式のマークダウンをチェックします
取り込み品質ゲート — 重大な問題があるファイルはインデックス作成時に自動的にスキップされます（削除はされません。ファイルはあなたのものです）
Gitによる自動同期 — 専用の知識リポジトリに対してプルおよびプッシュを行います
ツールテレメトリ（永続的） — プロジェクトごとのすべてのMCP呼び出し（検索、書き込み、ミス、パターン）を追跡し、知識のギャップを検出し、エージェントにドキュメント化を促します。再起動後も永続化され、Web UIで表示されます
インパクトメトリクスAPI — /api/impact-metrics が推定節約時間と回避されたリグレッションを計算します。CIパイプラインはガードレールの結果を /api/telemetry/ci-guardrail-report に投稿できます
プロアクティブな品質チェック — 再インデックスのたびに知識ベースを自動的に検証します
知識ブートストラップ — 「これが道（This is the Way）」：乱雑なリポジトリを分析し、ファイルを分類し、重複を検出し、クリーンアップ計画を提案し、ユーザーの承認を得て実行します（ファイルを削除することはありません）
コールドスタートコードベースアナライザー — analyze_codebase(path) は、ソースコードディレクトリを完全にサーバーサイドでスキャンします（トークンゼロ、クラウドゼロ）。Pythonの組み込み ast モジュール、TypeScript/JavaScript用の正規表現、分類と重複検出のための既存のMiniLM埋め込みモデルを使用します。言語分布、カテゴリマップ、ドキュメント化可能性スコアでランク付けされた最初にドキュメント化すべき上位20ファイル、重複ペア、カバレッジギャップを含む単一の bootstrap_report.md を返します。レガシーコードベースでのコールドスタートトークンコストを約90%削減します。
マルチプロジェクトサポート — 1つのコンテナで、プロジェクトごとに分離された複数の知識リポジトリを管理します
設定、監視、テストのためのWeb UIが含まれています

v3.9.29の新機能

Glamaツール検出の修正 — MCPサーバーが起動する前に AuthManager が読み取り専用の /data でクラッシュしていました（Glamaがツールを0と認識した真の理由）。stdioコールドスタートモードではスキップされます。
stdoutへのprint()ゼロ — ウォッチャー、インデクサー、リーダー、ブートストラップに残っていた36個の print() を diag() (stderr) に置き換えました。検証済み：完全なMCPハンドシェイクがstdio経由ですべての28個のツールを返します。
config.save() の回復力 — 読み取り専用ファイルシステムでクラッシュする代わりに警告をログに記録します。

前バージョン: v3.9.28

Glama / MCP stdio修正 — すべての診断出力をstderrに移動しました。stdoutはJSON-RPCのみになりました。Glama Inspectorがすべての28個のツールを正しく検出するようになりました。
コールドスタート検出の改善 — stdioコールドスタートロジックが空のDockerボリュームを正しく処理します（Glama検査中のブートストラップ/モデルダウンロードなし）。

前バージョン: v3.9.27

ライセンスのクリーンアップ — 正しいGitHub/Glama検出のために1つの LICENSE ファイル (BSL 1.1) を使用。すべてのドキュメントとヘッダーが LICENSE を指すようにしました (LICENSE.md ではなく)。
Glama / stdio検査 — 軽量なMCPディレクトリビルドのためのオプションの [inspect] 依存関係とコールドスタートstdioパス。

前バージョン: v3.9.26

Claude Coworkスキル — FlaiwheelワークフローがネイティブなClaudeスキルとして配布されるようになりました。インストーラーは .skills/skills/flaiwheel/SKILL.md をプロジェクトに書き込みます。Claude (Cowork) でプロジェクトを開くと、スキルが自動的に利用可能になります（追加設定不要）。このスキルは、セッション開始時のコンテキスト復元、コーディング前の知識検索、バグ修正後の必須ドキュメント化、セッション終了時の要約を促進します。
スキルソースも参照および手動インストール用にこのリポジトリの skills/flaiwheel/SKILL.md にコミットされています。

前バージョン: v3.9.25

WSL2自動プリフライトセットアップ — WSL2が自動的に検出され、メインのインストーラーフローの前に専用のプリフライトブロックが実行されます。手動ステップは不要です：
1. iptables をレガシーバックエンドに切り替えます（Dockerネットワーキング/DNATエラーを修正）
2. 現在のユーザーを docker グループに追加します（permission denied が発生しなくなります）
3. service を介してDockerデーモンを起動します（WSL2にはsystemdがないため）
4. ~/.bashrc にDocker自動起動スニペットを追加します（冪等性があり、WSL2ログインごとに実行されます）
スクリプト全体に散らばっていたWSL2チェックを単一のプリフライトブロックに統合しました。

前バージョン: v3.9.24

修正: python3が欠落している場合の自動インストール — インストーラーはJSON操作のために python3 を多用します。python3のない最小限のLinux/WSL2システムでは、設定ファイルの書き込みがサイレントに失敗していました (/dev/fd/63: line N: python3: command not found)。python3が前提条件 #0 としてチェックされ、欠落している場合は apt/dnf/yum/pacman/brew を介して自動インストールされるようになりました。

前バージョン: v3.9.23

修正: iptables-legacyを使用したWSL2でのDockerデーモン起動 — WSL2上のDockerは、デフォルトの iptables-nft バックエンドがサポートされていないため、サイレントに起動に失敗することがよくあります。インストーラーは、Dockerを起動する前に update-alternatives を介して iptables-legacy に切り替えるようになりました。また、現在のユーザーを自動的に docker グループに追加します。
すべてのインストールコマンドを bash <(curl ...) に更新 — スクリプト全体で表示されるすべてのインストール/再実行コマンド（エラーメッセージ、AGENTS.md、Cursorルールなど）で、WSL2のパイプ問題を回避するためにプロセス置換を使用するようになりました。

前バージョン: v3.9.22

修正: WSL2での curl | bash パイプ書き込みエラー — curl | bash は、パイプ/tmpの権限問題によりWSL2で curl: (23) Failure writing output と失敗することがあります。READMEの主要なインストールコマンドは、パイプを完全に回避する bash <(curl ...) (プロセス置換) になりました。再実行ブロックも、/tmp 書き込みが失敗したときにフォールバック一時ディレクトリとして $HOME を試行します。エラーメッセージは bash <(curl ...) 形式を明示的に推奨しています。

前バージョン: v3.9.21

修正: sudoガードを再実行ブロックの前に移動 — sudo curl | bash が使用されたとき、curl: (23) パイプエラーが以前のsudoガード（色/関数の後）に到達する前にスクリプトを切り捨てていました。ガードが最初の実行可能行（set -euo pipefail は除く）になったため、ダウンロードが切り捨てられた場合でも実行されます。色の後の重複ガードを削除しました。

前バージョン: v3.9.20

修正: WSL2でのDockerデーモン起動ポーリング — 固定の5秒スリープの代わりに、service docker start の後、最大30秒間、2秒ごとに docker info をポーリングするようになりました。また、service docker start の実際の出力を表示するため、起動エラーがサイレントに飲み込まれるのではなく可視化されます。

前バージョン: v3.9.19

修正: WSL2でのDockerデーモン起動 — WSL2には通常 systemd がないため、systemctl start docker はサイレントに失敗していました。インストーラーは /proc/version を介してWSL2を検出し、代わりに sudo service docker start を使用するようになりました。インストール後もDockerが実行されていない場合は、正確な修正コマンドとログイン時の自動起動のために ~/.bashrc に追加するヒントを含む、WSL2固有の明確なエラーが表示されます。

前バージョン: v3.9.18

修正: sudo curl | bash および sudo bash install.sh をブロック — sudo を介してrootとしてインストーラーを実行すると、GitHub CLI認証が壊れます：gh auth は資格情報を実際のユーザーのホームではなく /root/.config/gh/ に保存するため、その後のすべての gh 呼び出しが失敗します。また、WSLで curl: (23) Failure writing output パイプエラーを引き起こしていました。インストーラーは起動時に SUDO_USER を検出し、sudo なしで再実行するようにユーザーに伝える明確なメッセージを表示して即座に終了します。パッケージインストールのための権限昇格は内部的に処理されます。

前バージョン: v3.9.17

修正: gh auth login はsudoで実行してはならない — Linux/WSL上で gh を自動インストールした後、インストーラーはユーザーに対し、sudo なしで gh auth login を実行するように明示的に伝えます。以前に sudo で認証が行われた場合、資格情報が /root/.config/gh/ に入り、現在のユーザーから見えなくなり、認証チェックが失敗していました。インストール後と認証チェックの両方のステップでのエラーメッセージは、「gh auth にsudoを使用しないでください」と明確に警告するようになりました。

前バージョン: v3.9.16

修正: インストーラーがWSLおよび非root Linuxで動作する — すべてのLinuxパッケージマネージャーコマンド (apt-get, dnf, yum, zypper, pacman)、Dockerコンビニエンススクリプト、および systemctl 呼び出しは、インストーラーがrootとして実行されていない場合、自動的に sudo を使用するようになりました。rootインストールは影響を受けません。WSLおよび標準のLinuxデスクトップユーザーでの Permission denied / ロックファイルエラーを修正しました。

flaiwheel