Firekeep

Firekeep

エージェントを、互いに見知らぬ者同士のように働かせるべきではありません。

Claude Code、Codex、Kiro、OpenCode、その他の MCP クライアントを、1 つの共有セルフホスト型 Keep に接続します。

解決した問題の一つひとつが、次の問題をより簡単にするはずです。Firekeep は、作業の経験を、長期にわたって保持できるナレッジ、作業状態、手順、連携、検証可能な証拠として保存し、次のセッション、ツール、マシンで再び活用します。

1 台のワークステーションで、自分の作業の継続性を保つためにお使いください。チームのコンテキストを最初からやり直すことなく、必要に応じてチームメイトを追加できます。

ウェブサイト · インストール · 製品ツアー · Firekeep Studio · 証拠 · プライバシー · サポート

---

1 つの Keep を、複数のランタイムで

flowchart LR
    A["Claude Code<br/>stores a proven fix"] --> K[("your self-hosted<br/>Keep")]
    K --> B["Codex<br/>recalls the fix + evidence"]
    K --> C["Kiro<br/>reuses the procedure"]
    K --> D["OpenCode / MCP client<br/>continues informed"]

エージェントは、ネイティブのインターフェースとプロバイダーが管理するセッションをそのまま使います。引き継がれるのは、同じローカル MCP ゲートウェイを通じて、明示的に記録・呼び出された Firekeep のコンテキストです。つまり、1 人のユーザーが流れを失わずにツールを切り替えられ、チームは一度得たコンテキストを次へ引き継げます。

Claude Code と Codex が 1 つの Keep を共有する方法を見る →

Firekeep をインストールする

インストーラーは、Claude Code、Codex、Kiro、OpenCode をまとめて設定します（設定ディレクトリがある場合は Claude Desktop も含まれます）。続いて、Firekeep サーバーの設置場所を尋ねます。設定手順の全体は**インストールガイド**をご覧ください。

curl -fsSL 'https://firekeep.ai/latest/install?src=github' | sh    # macOS / Linux
irm 'https://firekeep.ai/latest/install.ps1?src=github' | iex      # Windows PowerShell

サーバーは linux/amd64 または linux/arm64 で動作します（サーバーの v1.6.2 より後のリリースが対象です。v1.6.2 以前は amd64 のみ対応）。Docker Compose v2、2 基の CPU コア、Git が必要です。デフォルトのスタックでは 16 GB の RAM を推奨します。デフォルトでは 127.0.0.1 にバインドします。ホストを選ぶ前に、**要件とサイジングの注意事項**をご確認ください。

Firekeep を初めてお試しですか？ うまくいった点や行き詰まった点を共有してください →

ランタイムの対応状況

• Client Kit： Claude Code、Codex、Kiro、OpenCode をまとめて設定します。設定ディレクトリがある場合は Claude Desktop も追加されます。その他の MCP クライアントは汎用パスを利用できます。
• Claude Code： MCP、指示、ライフサイクルフックを管理します。対応するプリツールフックで、編集、書き込み、シェル操作を確実にブロックできます。
• Codex： 管理対象の MCP と AGENTS.md のガイダンスを提供します。Codex にはネイティブフックがないため、ライフサイクルの自動化や編集前の制御は含まれません。
• Kiro CLI： MCP、ステアリング、ライフサイクルフックを備えた、Firekeep の名前付きエージェントです。検証済みの Kiro CLI 2.12.1 の機能では、編集前フックは助言のみを行います。
• Firekeep Studio： Codex、Claude Code、Kiro CLI、Grok を 1 つのデスクトップワークスペースで実行します。Grok の直接アダプターには Keep のメモリ、フック、ブリーフィングがありません。Studio は、別のランタイムのステータスを引き継ぐのではなく、その境界を報告します。

最新の詳細は、**インテグレーションガイドとStudio ランタイム対応表**をご覧ください。

手法を明示した検索評価

採用された 2026-08-28 の LongMemEval-S 実行で、Firekeep は**Evidence Recall@10 で 97.7%**を達成しました。採点対象の質問 470 件中 459 件で、ラベル付き証拠セッションが検索結果の上位 10 件に少なくとも 1 件含まれていました。この測定対象は検索であり、生成された回答の正確さではありません。また、複数回の実行による信頼区間ではなく、補正済みの決定論的な 1 回の実行結果です。

評価方法 · 結果データ

Firekeepが解決する問題

人は、メール、ドキュメント、チケット、ソースファイルをすべて最初から読み返して、専門的な判断力を身につけるわけではありません。何が起きたのか、なぜある判断がうまくいったのか、失敗をどのように診断したのか、どの手順が実際に有効だったのかを覚えています。その経験によって、次の問題への取り組み方が変わります。

エージェントも同じように改善していくべきです。Firekeepは、作業の背景にある知識、作業状態、連携、証拠をつなぎ、次のエージェントが前のエージェントの経験を活かして作業を始められるようにします。

機能の詳細マップ

機能	意味
メモリ	エージェントは、何がうまくいき、何が失敗し、何が重要なのかをセッションをまたいで記憶します。セマンティック検索とグラフ検索、確信度スコアリング、矛盾への対処、4 種類のメモリ（リファレンス／手順／エピソード／一時）とタイプを考慮した想起の減衰、復元可能なアーカイブ優先の経年処理、オプションの LLM による統合を利用したトークンを意識した想起を備えています。想起内容は、記録されたセッションの結果（結果で重み付けされたメモリ）と、実際に行動に移された知識に対するエージェントのフィードバック（memory_feedback）に基づいて再ランク付けされます。
ナレッジの自動運転	ナレッジベースは、自ら何かを決定することなく、自身を維持します。未確認のメモリ同士が実際に矛盾する場合、どちらも黙って削除されることはありません。人間が判定するまで、両方とも異議ありのマークが付いた状態で想起可能です（/memory/contested/resolve）。セッションリーパーは、クラッシュしたセッションや途中で離れたセッションを終了処理し、失敗が結果のスコアリングに反映されるようにします。すべてのレビューキュー（スキルのドラフト、古くなったスキル、手順の提案、異議のあるペア、評価のデッドレター）は、週次ダイジェストとともに 1 つの受信トレイに集約されます。また、/memory/{id}/evidence では、メモリのランク付けの根拠となったすべてのシグナルを一度に確認できます。
フリートを GPU として活用（ナイトシフト）	接続されたエージェントのマシンが、ローカルモデルを使って夜間にナレッジベースの作業を行い、生成するのは常にドラフトのみです。セッション終了時のフックがセッションごとに蒸留ジョブをキューに追加します。サーバーの夜間処理では、古くなったスキルごとに 1 つのジョブ（「再作成」）、異議のあるメモリペアごとに 1 つのジョブ（「判定を提案」）をキューに追加します。firekeep night-shift がキューを処理します。LM Studio または Ollama が起動している場合は、セッション開始時に自動で起動します。各ドラフトの有効化と各ペアの解決は、引き続き人間が行います。また、Autopilot タブにはジョブタイプごとの承認率台帳が表示され、フリートの作業を採用する価値があるかどうかを確認できます。
チームの継続性	メモリには、検証済みのワークスペース／メンバーの来歴に加えて、信頼されていない実行時の agent_id ラベルとプロジェクトが記録されます。コントリビューターごとの活動レポートと LLM が合成した引き継ぎ概要により、あるエージェントが別のエージェントの作業を引き継げます。
セッションの継続性	セッションツールを通じて記録された計画、決定、進捗は、コンテキストの圧縮後も保持されます。クラッシュしたセッションは次回起動時に自動検出され、定期的なワークスペースのスナップショット（git ブランチ、最近のコミット、差分統計）がシャドウに埋め込まれた状態で、再開するかどうかを提示します。
環境の把握	設定された Docker、git、ファイルのコレクターが、プロンプトだけに頼るのではなく、運用状態を監視します。コンテナの再起動、新しいコミット、ファイルの変更は、再生可能なイベントストリームに反映されます。
エージェントの連携	共有チャンネル、掲示板、構造化されたタスクキュー、単調増加するフェンシングトークンを用いたリソースリース、プレゼンスレジストリ、ダイレクトメッセージを備えています。並行して動作するエージェントは、作業を割り当てて進捗を追跡し、リースを使って編集の重複を防止できます。フック対応クライアントは、別のエージェントがすでにファイルのリースを保持している場合、編集をブロックします。
予測してから実行するゲートウェイ	エージェントは、重大な結果を伴う操作の前に意図を宣言し（action_before → `allow
スキル	エージェントは、skill_create ツールを通じて（クライアント側で、セッションコンテキスト全体を利用して）再利用可能な「X が起きたときの対処方法」をまとめたプレイブックを作成できます。また、ドキュメントからスキルを生成するパイプラインにより、Wiki やランブックから人間のレビュー用のドラフトをさらに作成します。一致度の高い項目は、次のセッションのブリーフィングに挿入されます。（サーバー側の自動合成機能は SKILL_SYNTHESIS_ENABLED を設定すると利用できますが、デフォルトではオフです。CPU のみのデプロイでは、生成用 LLM を実用的な時間内に実行できないためです。）
強制適用されるランブック	コマンドマッチャーを含む手順を持つスキルは、人間が有効化できるランブックになります。advise（第 1 ラウンドの助言）、require_ack（コマンドが一致すると、監査可能な確認を行うまで実行が保留されます。確認は、ワークスペース、メンバー、セッション、コマンドハッシュ、手順、バンドルのバージョン、実行にひも付く 1 回限りの許可です）、または block（フェイルクローズ方式で停止し、許可を有効にする前にクライアントが必要とするサーバーの受領証を返します）を設定できます。エビデンスは成功に基づいて評価されます。コマンドが終了コード 0 で終了した場合にのみ手順の実行としてカウントされます。また、すべての強制適用イベントは逸脱台帳（ダッシュボードと受信トレイ）に記録され、コマンドテキストではなくコマンドハッシュが保存されます。モードは管理者専用ルートで人間が設定します。エージェントはランブックを提案できますが、有効化はできません。PROCEDURE_ENABLED でオプトインできます。現在、独自のデプロイ環境で試験運用中です。docs/guides/living-procedures.md をご覧ください。
意思決定ボード	確認が数問を超える場合、エージェントは、チームメモリから取得したエビデンスを事前入力したローカルブラウザのボードを開きます。チームがすでに学んだことを踏まえ、より適切な質問を提示できます。ローカルゲートウェイが Decision Board プロセスと Cortex /decision/synthesize への接続を担います。
継続的に更新される指示	指示レイヤーは自らを測定します。リプレイから決定論的に算出する指示ごとの準拠テーブル（セッションが回答前に想起したか、作業中に記録したか、重大な結果を伴う操作を宣言したか）に、時間経過に伴う傾向、ランタイムごとの内訳、指示の適用を示す受領記録が含まれます。セッションには、実際に適用された指示テキストのコンテンツハッシュが記録され、検証できないものはカウントせず「不明」と報告されます。設計上、その限界についても正直です。測定するのは行動であり、その行動が役に立ったかどうかではありません。フリートが作成した指示の書き換えを人間が判定し、A/B 検証する機能はロードマップに含まれています。
信頼台帳	ゲートウェイを通じてエージェントがすでに行っている宣言（action_before／action_after）に基づき、エージェントごとの稼働記録を作成します。宣言された操作の数、照合率、予測の一致度の較正（申告された確信度と照合済みの結果の Brier スコア）、取り消し、セッション数、初回／最終確認日時を記録します。これは可視化のみを目的とし、報告は行いますが、制限を設けることはありません。設計上、誠実な評価を行います。較正は能力ではなく行動を示します。確認できるのは宣言された操作のみです。agent_id は自己申告のラベルであるため、記録は宣言された ID ごとに作成されます。また、しきい値に満たない場合は数値を捏造せず、「シグナル不足」と表示します。強制適用を担う部分（この記録に基づいて自律性を認める権限ブローカー）はロードマップに含まれています。
自動評価とパターンの発見	セッション完了時に、リプレイトレースから品質指標を算出します。パターン検出は有効になっています。自動的な昇格／検証と A/B 実験用のエンドポイントも実装されていますが、責任を持って利用できるだけのセッション数がデプロイ環境に蓄積されるまでは、デフォルトで無効です。
リプレイと説明可能性	すべてのメモリの読み書き、セッションのライフサイクルイベント、環境の変更、連携アクション、ゲートウェイの判断が、構造化トレースとして記録されます。任意の過去のイベント時点でコンテキストを調査、絞り込み、再構築できます。
暗号化されたシークレット	インフラストラクチャの認証情報、API トークン、接続文字列用の Fernet ベースのボールトです。メモリとは別に管理され、シークレットが想起結果に現れることはありません。
ビジネスナレッジ	会社のドキュメント（Wiki ページ、チケット、API ドキュメント）を、手動または Confluence コレクターの定期実行によって取り込みます。チャンクはベクトルストアに格納され、メモリの想起時に運用メモリとともに自然に表示されます。
コードインテリジェンス	Tree-sitter ベースのシンボル検索、呼び出し元グラフ、アーキテクチャマップ、ファイル全体ではなくシンボル単位の部分を返す影響分析を備えています。ローカルゲートウェイを介してクライアント側で実行されます（firekeep-symdex はキットとともにインストールされます）。MCP ツールは 38 個です（分析ツール 8 個はデフォルトで非表示で、SYMDEX_ANALYTICS_ENABLED の背後で制御されます）。

Firekeepが他と異なる理由

Firekeepは、単なるチャットボットのラッパーやプロンプトのオーケストレーション層ではありません。

接続されたAIエージェントのための運用レイヤーです。既存のツールの背後で動作し、それらをより強力にするインフラストラクチャです。

• デフォルトでセルフホスト可能です。 サーバー、データストア、埋め込み表現、デフォルトの生成モデルは、お客様のインフラストラクチャ上で動作します。サードパーティへのデータ送信は、コネクターまたは外部のSymdex AIプロバイダーを選択した場合にのみ発生します。
• 実際に作業する場所を深く支援します。 提供済みワークフローの中ではコーディングが最も充実しており、コードインテリジェンスにはSymdexを使用します。ただし、これが製品の境界ではありません。Docdexは選択したドキュメントフォルダーを同じKeepに取り込み、Maildexはメンバーのメール（読み取り専用のIMAP、常にメンバーのプライベート領域、firekeep maildex add）を取り込みます。また、共有の継続性、調整、ガバナンス、エビデンスの各レイヤーは、特定の分野に依存しません。
• 永続性と可観測性を備えています。 多くのエージェントツールは、その場でエージェントの能力を高めることに重点を置いています。Firekeepは、セッション間に起こることと、問題が発生した後の対応に重点を置いています。
• MCPネイティブです。 4つのリモートサービスと2つのクライアントローカルバックエンドが、1つのローカルなfirekeep stdioゲートウェイを通じてModel Context Protocolツールを公開します。提供済みアダプターはClaude Code、Claude Desktop、Codex、Kiro、OpenCodeを設定します。他のMCPクライアントは手動で設定できます。
• エージェントに依存しません。 基盤となるメモリと調整レイヤーを再構築せずに、エージェントクライアントを切り替えられます。Cursorには手動で設定するMCPの手順がドキュメント化されています。Aiderには現在、提供済みアダプターがありません。
• A2Aによる検出に対応しています。 Relayは、機能を検出するためのAgent-to-Agentエージェントカードを/.well-known/agent.jsonで公開します。これは検出専用であり、A2Aタスク実行エンドポイントではありません。

インストールと運用の詳細

コマンドは1つ、必須の質問は2つです。すべてのメモリ、セッション、再生イベントの帰属先となるエージェントIDと、Firekeepサーバーの場所です。Dockerを使ってこのマシンにセットアップする、参加コードを使用する、すでに稼働中のサーバーを指定する、または後で決める（その場合はfirekeep doctorが完了方法を案内します）のいずれかを選べます。ここにセットアップする場合は、firekeep initが自動的に実行されます。このインストーラーは何も質問せず、スタックの起動後にマシンが自動的に参加するため、ダッシュボードもトンネルもキーの貼り付けも必要なく、firekeep doctorは正常な状態になります。完了時には、2台目のマシンで貼り付けて実行できるコマンドが表示されます。

次にインストーラーでは、別のMCPクライアントのルールファイルを追加するかどうかを尋ねるプロンプトが1つ表示されます。これはスキップできます。提供済みの4つのアダプターは、どちらを選んでも生成されます。

v1.6.2以降のサーバーイメージはlinux/amd64とlinux/arm64向けに公開されているため、x86-64またはARM64のLinuxホスト（AWS GravitonやAmpereなど）、あるいはAppleシリコン搭載MacのDocker Desktopでネイティブに実行できます。v1.6.2以前はamd64のみ対応です。クライアントのブートストラップは、Ubuntu、Debian、Alpine、Fedora、Rocky、Arch、openSUSE（x86_64およびaarch64）でCI上でテストされています。macOSでも同じスクリプトを実行できますが、CIの対象ではありません。

• 要件とサイジング — firekeep.ai/docs.html#requirements
• サーバーのインストール — firekeep.ai/docs.html#server
• エージェントとチームメイトの接続 — firekeep.ai/docs.html#connect
• トラブルシューティング — firekeep.ai/docs.html#troubleshooting

このチェックアウトから

bash install.sh              # build the server from source
bash install.sh --pull       # the same installer against the published images
cd client && ./install       # the kit from this checkout (.\install.ps1 on Windows)
firekeep install             # re-render the runtime adapters only

install.sh は何も尋ねません。ホストアドレスは自動検出され、Neo4j のパスワードは自動生成されます（--ip／--neo4j-password、または FIREKEEP_VPS_IP／FIREKEEP_NEO4J_PASSWORD でそれぞれ上書きできます）。スタックが起動するとすぐに処理を返し、約 3.3 GB のモデルのダウンロード完了を待ちません。完了するまでは、メモリへの書き込みは status="partial" を返します（保存され、バックフィル用にキューに入れられていますが、まだ検索できません）。また、firekeep doctor にはその旨を示す embeddings の WARN 行が表示されます。代わりに bash install.sh --wait-for-models を実行すると、モデルの準備が整うまで待機します。

その後のサーバーの運用（アクセスと認証、ダッシュボード、バックアップ、アップデート、ポートの意図的な公開）については、docs/DEPLOYMENT.md をご覧ください。

削除する

firekeep uninstall            # remove the client kit from this machine
firekeep uninstall --server   # also tear down the server + ALL its data

firekeep uninstall は、このキットがインストールしたものだけを削除します。各ランタイムの設定にある Firekeep のブロック（ユーザー独自の設定はそのまま残ります）、ランチャーとその PATH エントリー、~/.firekeep が対象です。最初に確認を求めます（--yes で確認をスキップできます）。ユーザーが設定したサーバーには決して触れません。さらに --server を指定すると、このマシンでプロビジョニングしたスタックに対して docker compose down -v を実行し、Neo4j／Qdrant／Redis のボリュームを削除します。すべてのメモリ、セッション、シークレットが完全に消去されます。これは別個のデータ損失確認の後に実行され、通常のアンインストールや --yes だけで実行されることはありません。データを復元する可能性がある場合は、先にバックアップしてください（docs/DEPLOYMENT.md）。

Firekeep Studio

Windows 版をダウンロード · ユニバーサル macOS 版をダウンロード · Studio を見る →

studio/ は、Firekeep だけを起動するエージェントアプリケーションにしたい方向けの、独立したデスクトップクライアントです。Codex、Claude Code、Kiro CLI、Grok に、ランタイムに依存しない会話画面を提供します。サポート対象のランタイムを明示的にプライマリとして選択でき、ほかのランタイムは新しい読み取り専用コンテキストでレビューできます。また、/compare、/consensus、明示的な共有ワークスペース、Windows の音声入力とシステム音声出力、キャッシュを考慮したトークンガード、名前と色を付けたローカルセッション、プロバイダーのモデル／推論機能のライブ検出、型付き Client Kit コントロールが組み込まれています。選択中のランタイムは画面上で明示され、インスペクター全体を非表示にできます。また、Studio は認証情報を公開することなく、既存の Client Kit 接続からダッシュボードにリンクします。フェンスで囲まれた Mermaid の応答は、ネイティブのズーム可能な図として表示されます。また、既存の Firekeep Decision Board は、Studio 内のネイティブな質問／根拠／アクションパネルとして開きます。ローカルで認証されたプッシュにより、従来のロングポーリングを維持し、ボードの準備完了を確認するだけの余分なエージェントターンを回避します。 プライマリランタイムの選択メニューには、準備状況とトランスポートのコンテキストがリアルタイムで表示されます。応答のスクロールは、読者が末尾から移動した場合にその位置を尊重し、コピー／貼り付けには、範囲を制限したテキスト専用のネイティブクリップボード操作を使用します。各実行では完了した回答を先頭に表示し、詳細な作業イベントは折りたたみ可能な作業ログにまとめます。ランタイムに依存しないエージェントビューでは、Codex、Claude、Kiro、Grok、または今後のチャット対応アダプターを、個別のネイティブ継続処理が可能な選択式ペインとして表示します。共有コンポーザーは選択したペインを対象とし、ワークスペースの安全性を保つため、実行中の処理は順次実行されます。Mission Mode は、成果を範囲内に限定するハーネスを追加します。単一のプライマリライター、決定論的なローカルチェック、範囲を限定した修正、独立したレビュー根拠、明示的な人による承認を備え、タスクの結果はすべてのエージェントの文章とは別に保存されます。

Studio は、TUI をスクレイピングするのではなく、プロバイダーがサポートする構造化された境界を使用します。また、プロバイダー認証はプロバイダー側で管理されます（OS で暗号化された API キーを除く）。ランタイムのネイティブ設定で Keep のメモリ、フック、ポリシー、接続機能を利用できる場合は、既存の Python Client Kit を引き続き使用します。ランタイムカードには、その根拠が明示的に表示されます。直接接続する xAI Grok アダプターには Keep のメモリがないことが明記され、ほかのランタイムの主張を引き継ぐことはありません。プレビューの ビルドとインストーラーのコマンド、セキュリティ境界、ランタイム一覧、/ コマンドの全一覧については、Studio README をご覧ください。

Studio 0.5 では、独立した署名付きリリースチャネルから、x64 Windows インストーラーとユニバーサル macOS インストーラーを提供します。パッケージ版ビルドは起動後まもなく Studio の更新を確認します。Windows では再起動時に検証済みの更新をダウンロードしてインストールします。一方、macOS ではリリースが Apple の署名を受け、認証されている場合に限り、ネイティブの自動更新を使用します。最新のリリースページ、チェックサム、両方のインストーラーは、Firekeep Studio releases で公開されています。

実際のワークフロー

エージェントが Firekeep を使うと、次のようなことが起こります。

1. セッションが開始されます。 ライフサイクルフックを備えたランタイムでは、クライアントはまず、関連するメモリ、タスク、環境状態、スキルを含む Cortex の集約済み GET /briefing を取得します。その後、エージェントは ctx_start_session("fix auth middleware bug") を呼び出します。Bridge が永続的なセッションを作成し、shim がそのセッションをブリーフィングに紐付けます。

2. コードを調査します。 エージェントはすべてのファイルを読む代わりに、Symdex で search_symbols("auth middleware") と get_callers("require_scope") を呼び出します。ミリ秒単位で、対象を絞ったファイルと呼び出し元の一覧を取得できます。

3. 環境を確認します。 Sentinel は Docker を監視しています。過去 1 時間に cortex-api コンテナが 3 回再起動したことを検知し、Relay の #alerts チャンネルにアラートを送信しました。エージェントはこれをコンテキストで確認できます。

4. 作業を進めます。 エージェントはファイルを編集し、テストを実行して、重要な進捗を ctx_update で記録します。Bridge は明示的に記録された内容を永続化します。コンテキストウィンドウが圧縮されると、エージェントは ctx_get_shadow を呼び出し、計画、判断、進捗、ファイルに関する知識といった永続的な作業状態を再取得します。

5. セッションが完了します。 エージェントは ctx_complete_session を呼び出します。必要に応じて、構造化された自己評価として task_result（"success"／"partial"／"failure"。RPC の結果ではなく、TASK の結果）と、それを裏付ける短い task_evidence の主張を最大 10 件渡すこともできます。評価が受け入れられるのは、セッションの認証済み所有者からの場合に限られ、そのセッションの唯一の正式な結果として保存され、上書きされることはありません。Bridge はセッションをアトミックに完了済みとしてマークし、エピソード記憶へのバックグラウンドでの蒸留をキューに追加します。失敗した場合は再試行され、最終的には確認可能なデッドレターキューに移動します。自動評価では、リプレイトレースから品質指標を算出します。認識された評価がないセッションは、推測で成功とされず unknown として扱われるため、成果に基づくスコアリング（成果加重メモリ、品質の傾向）で沈黙が成功として数えられることはありません。蒸留が成功すれば、次に誰かが認証ミドルウェアの作業をするときには、メモリを利用できます。

6. 何か問題が起きましたか？ ダッシュボードの Replay タブを開き、セッションを読み込みます。すべてのアクション、メモリの読み取り、判断ポイントを確認できます。失敗イベントをクリックして絞り込みを実行すると、因果関係をたどり、根本原因の特定に役立てることができます。

アーキテクチャ

Local Machine                               VPS
┌──────────────────────────┐              ┌────────────────────────────────────┐
│ Claude / Codex / Kiro /  │              │ FirekeepCortex   — Memory & RAG    │
│ OpenCode / MCP client    │              │ FirekeepBridge   — Sessions        │
│           │              │              │ FirekeepSentinel — Monitoring      │
│  one `firekeep` gateway  │◄──── MCP ───►│ FirekeepRelay    — Coordination    │
│    ├─ symdex (local)     │              │ Dashboard        — Web UI          │
│    └─ decision (local)   │── Browser ──►│ Neo4j · Qdrant · Redis · Ollama    │
└──────────────────────────┘              └────────────────────────────────────┘

Symdex と Decision Board は、キットとともにインストールされる stdio ローカル MCP サーバーとして、クライアント側で実行されます。Symdex はインデックス対象の作業ツリー上でローカルに動作する必要があるため、VPS コンテナーではなくなりました。

この境界を越える 2 本の矢印は、デフォルトではパブリックにアクセスできません。 初期状態では、VPS 側はループバックでリッスンし、API キーを要求するため、 ローカルマシン側からは SSH トンネル、プライベートネットワーク、または 意図的に設定した HTTPS フロントエンド経由でアクセスします。詳しくは docs/DEPLOYMENT.md → アクセスと認証を参照してください。

サービス	機能
FirekeepCortex	長期メモリです。セマンティック RAG とグラフ RAG、アーカイブ／復元のライフサイクル、スリープサイクルによる統合、タイプに応じた減衰を備えた 4 種類のメモリ、信頼度スコアリング付きのバージョン管理されたメモリ、自動的な矛盾の置き換え、エージェント作成スキル（skill_create）とドキュメントからスキルへのパイプライン、Agent Gateway（予測してから実行するインターフェース）を提供します。
FirekeepBridge	セッションの永続化を担います。コンテキスト圧縮を経ても作業コンテキスト（計画、決定、進捗、ファイルに関する知識）を保持します。完了時に Cortex へ自動的に要約します。ワークスペーススナップショットからの再開機能を備えた、クラッシュしたセッションの検出機能があります。セッションリーパーは 72 時間を超えてアイドル状態のセッションを放棄し、途中で放置されたセッションが成果スコアリングで成功として記録されないようにします。セッションのライフサイクルイベントをリプレイストリームに送信します。
FirekeepSentinel	環境オブザーバーです。Docker のヘルス状態、git のコミット、ファイル変更を監視します。エラー時には Relay にアラートをブロードキャストします。コンテナーの再起動、新しいコミット、ファイル変更は、リプレイ可能なイベントストリームに流れます。
FirekeepRelay	エージェント連携を担います。リアルタイムの Pub/Sub チャネル、永続的な掲示板、構造化されたタスクキュー、単調増加するフェンシングトークン付きのリソースリース、プレゼンスレジストリ、ダイレクトメッセージ、外部からの検出に対応する A2A エージェントカードのエンドポイントを備えています。
Dashboard	連携、メモリ、診断、デバイス、メンバー、ポリシー、ボールト、運用を扱う Web UI です。
Firekeep Studio	プライマリエージェント向けの任意のローカルデスクトップコンソール兼 Mission ハーネスです。決定論的な検証、独立したレビュアー、Windows の音声入力、システム音声による返信、ランタイム間の比較、Client Kit の制御に対応します。VPS サービスではありません。

コードインテリジェンス（FirekeepSymdex — MCP ツール 38 個、フラグで非表示になる分析機能 8 個）と Decision Board（firekeep-decision）は、VPS コンテナーではなく、キットとともにインストールされる stdio ローカル MCP サーバーとしてクライアント側で実行されます。

共有モジュール（追加のコンテナーは不要）：Replay Engine（全サービスにまたがる構造化トレースログ）、Auth（API キーのスコープ）、Vault（Fernet で暗号化されたシークレットストレージ）、Corpus（業務文書の取り込み → ベクトルチャンク。スケジュール実行される Confluence コレクター）、Auto-Evals（Tier-1 品質指標 10 個とトレンド追跡、リグレッション検出）、Pattern Engine（戦略検出。昇格の検証と A/B 実験はデフォルトで機能フラグにより無効）、Policy Engine（編集前に実行する複合的な安全性チェック — リース、ファイルリスク、パス拒否、セッションの健全性、直近の失敗）、Agent Gateway（予測してから実行するインターフェース。繰り返される低リスクなアクション向けの高速パスキャッシュ付き）、Skills（skill_create によるエージェント作成と、人間のレビューを前提とするドキュメントからスキルへの下書き。サーバー側での合成はデフォルトで無効）、Memory Improvements（プレビュー／監査／復元に対応するアーカイブ優先の複合的な経年処理、トークン予算、LLM 合成パス、埋め込み入力の上限設定とサイズに合わせた縮小）。

完全な設計仕様については、docs/DESIGN.md を参照してください。

ダッシュボード

ホスト上で http://localhost:8040 にアクセスするか、別の場所からトンネル経由でアクセスします （docs/DEPLOYMENT.md → ダッシュボードへのアクセス）。 独自のベーシック認証ログインがあります（ユーザー admin。パスワードは dashboard/.htpasswd.cred に一度だけ書き込まれます）。その背後で、 nginx がバックエンドへのすべての呼び出しにダッシュボードの API キーを挿入するため、ブラウザーにキーを貼り付けなくても、SPA は認証で保護されたスタック上で動作します。

タブ	表示内容
概要	サービスの健全性、概要統計、最近のイベントとメモリー
セッション	アクティブ／一時停止／完了／放棄されたセッション、シャドウコンテキストインスペクター
イベント	発生元と重大度で絞り込める Sentinel イベントフィード
リレー	タスクキュー、チャネル、掲示板、ダイレクトメッセージ、アクティブなクレーム／リース
スコープ	FirekeepScope の明確化セッション — アクティブな画面、回答プロンプト
メモリー	想起検索、アクティブ／アーカイブのブラウザー、ワンクリック復元、メンテナンスのプレビュー／監査、保存フォーム、貢献者、名前空間／タグの統計
スキル	エージェント作成およびドキュメント由来のスキルカード — レビュー、有効化、編集、廃止 — と、Living Procedures のランブックカード：適用モードのバッジと管理者モードの制御、ステップごとの観察統計、逸脱ビュー、武装中のランブックに現在のバンドルを保持するセッションがない場合の「現在、適用されていません」という警告
ナレッジ	ドキュメントからスキルへの取り込み（貼り付け／URL）と、スキル草案の承認キュー
オートパイロット	レビュー受信箱（スキルの草案／古いスキル／再レビュー、手順の提案、ランブックの逸脱、フリートが提案する判定を含む競合メモリーのペア、評価のデッドレター）、今週の変更点のダイジェスト、Living Instructions の準拠状況テーブル（指示ごとの割合、傾向、ランタイムごとの内訳、露出状態）、Trust Ledger カード（エージェントごとの申告／照合／較正／取り消し）、ジョブごとの承認率を示すフリートテーブル — 読み取り専用。提案と報告のみを行い、変更は行いません
パターン	発見された戦略カード。機能フラグが有効な場合は、昇格の検証と実験の制御
運用	ワーカー、キューの深さ、アクティブなエージェント、ベクトルストア情報、規律カウンター（タグ付けされていないメモリー呼び出し）
ポリシー	編集前の安全性チェックに関するランタイムポリシールール。ルールごとに切り替え可能
ボールト	暗号化されたシークレット管理（Fernet ベース、Redis DB 7）
リプレイ	セッショントレースのタイムライン、イベントインスペクター、根本原因の絞り込み
評価	集計品質指標、セッションごとのスコアカード、品質の傾向
デバイス	デバイス認証情報と、1 回限りの登録コマンド
メンバー	メンバーと、1 回限りのメンバー招待

ダッシュボードは、依存関係のない静的 SPA です。ビルド手順も npm もフレームワークも必要ありません。

ドキュメント

ドキュメント	内容
docs/DEPLOYMENT.md	サーバーの実行：アクセスと認証、更新、バックアップ、トラブルシューティング、ローカル開発（インストールについてはfirekeep.ai/docs.htmlを参照）
docs/CONFIGURATION.md	すべての環境変数、Redis DB の割り当て、インテリジェンス機能
docs/MCP-TOOLS.md	サーバーおよび登録済みのクライアントローカルバックエンドにおける MCP ツールの完全なリファレンス。表示されるインベントリは、dex の登録状況と機能フラグによって異なります
docs/DESIGN.md	アーキテクチャ仕様、サービスコントラクト、統合ポイントの詳細
docs/COMPARISON.md	ベースの Claude Code との機能ごとの比較
docs/SETUP-CODEX.md	Codex 統合ガイド
docs/SETUP-CLAUDE-CODE.md	Claude Code 統合ガイド
docs/MULTI-AGENT.md	エージェントインテリジェンス：事前ブリーフィング、セッションの振り返り、マルチエージェント連携
studio/README.md	Firekeep Studio のランタイムマトリックス、コマンド、セキュリティモデル、開発、パッケージング

技術スタック

Python 3.11 のサーバーサービス（クライアントは Python 3.10 以降に対応）／FastAPI／FastMCP／Neo4j／Qdrant／Redis／Ollama／Docker Compose／tree-sitter／TypeScript／Electron／React

サーバー側の埋め込みと生成には、デフォルトでローカルの Ollama を使用するため、標準のサーバーパスではモデル API の料金は発生しません。Symdex では、シンボルの概要とスキャフォールディングに Anthropic、Gemini、または OpenAI 互換のエンドポイントをオプションで使用できます。これらのプロバイダーを有効にすると、コードスニペットがマシン外に送信され、プロバイダーの利用料金が発生する場合があります。バックグラウンドの自動インデックス作成では、AI による概要生成が明示的に無効化されています。

ロードマップ

現在実装済み

• メモリのライフサイクル全体（学習、想起、減衰、矛盾の検出、バージョン管理）
• 4種類のメモリ（reference／procedural／episodic／transient）と、種類に応じた想起時の減衰。直接学習した内容はデフォルトでepisodicとなり、生のイベントを統合する場合は抽出した知識を分類します
• オプションのLLM合成に対応した、トークンを意識した想起
• アーカイブを優先する複合的な経年処理（経過時間 × アクセス状況 × 信頼度）。ダッシュボードでのプレビュー、監査、復元に対応します。確認済みのメモリ、スキル、コーパスのチャンクは経年アーカイブされず、自動的な完全削除はデフォルトで無効です
• チームの継続性：検証済みのワークスペース／メンバーの来歴と、実行時の agent_id + project、貢献者レポート、LLMが合成する引き継ぎ概要
• コンテキストの圧縮をまたいだセッションの永続化。クラッシュ検出とワークスペーススナップショットからの再開に対応します
• セッションのライフサイクル（開始／更新／完了／放棄）に応じたBridgeリプレイイベントの送信
• Docker + git + ファイルの監視とRelayによるアラート。コンテナ／コミット／ファイルのアクティビティをリプレイストリームに流します
• エージェント連携：チャンネル、掲示板、フェンシングトークン付きリース、構造化タスクキュー、プレゼンスレジストリ、ダイレクトメッセージ
• セッション開始時にすべてのサービスから情報を集める事前ブリーフィング。メモリ呼び出しにIDヘッダーがない場合は、運用ルールに関する警告を表示します
• セッションの振り返り：タスクの更新とリースのクリーンアップを含む、ガイド付きの完了処理
• マルチエージェント対応（タスク割り当て、受信トレイのポーリング、ファイルリースの適用）
• スキル：skill_create（クライアント側）でエージェントが作成するスキルに加え、ドキュメントからスキルを生成するパイプライン（貼り付け／URL／スケジュールされたConfluenceコレクター）で、人間のレビュー用のスキル案を作成します。上位の候補は次のブリーフィングに挿入されます（サーバー側の自動合成も実装済みですが、SKILL_SYNTHESIS_ENABLED の背後にあり、デフォルトでは無効です）
• Night Shift：firekeep night-shift はフリートのジョブカタログを処理します。セッションの蒸留（セッション終了フックによってキューに追加）、古くなったスキルの再作成、意見の分かれた判定の提案（サーバーによって夜間にキューに追加）を、自分のマシン上でローカルモデル（LM StudioまたはOllama、自動検出）を使って実行します。元のセッションに帰属するメモリ、書き換え対象の古いスキルを reauthor_of で示す草案スキル、意見の分かれた組み合わせに記録される判定の提案を書き込みます。これらが適用されることはなく、常に人間の確認待ちになります。ローカルモデルのポートに応答があれば、セッション開始時にバックグラウンドで起動します（無効にするには FIREKEEP_NO_AUTO_NIGHTSHIFT=1 を設定）。生成処理はサーバー上では行われません。セッション内容がマシンの外に出ないよう、クラウドホスト型モデルはデフォルトで拒否されます
• Decision Board：取得済みのチームメモリの根拠をあらかじめ反映した、エージェントが起動するローカルの確認ボード（stdioサーバー firekeep-decision + Cortex /decision/synthesize）
• 個人／バイパスモード：セッション中に /personal（または firekeep personal ／ FIREKEEP_BYPASS=1）を使うと、プライベートな作業中はFirekeepが完全に休止します。フック、サイドカー、Decision Board、shimはすべて単一の is_bypassed() ゲートに従い、セッション終了時に自動解除されます
• Pattern Engine：戦略の検出、カテゴリ分類（procedural／risk／behavioral）、隔離制御に対応します。自動昇格／検証は PATTERN_VALIDATION_ENABLED=false の背後に実装されており、デフォルトでは無効です
• 実験フレームワーク：名前付きデータセット、カイ二乗有意性検定、効果量の信頼区間、制御された戦略ヒント実験に対応します。実験機能は PATTERN_EXPERIMENTS_ENABLED=false の背後にあり、デフォルトでは無効です
• パターン検証が有効な場合に、ブリーフィングのヒントが成果を改善するかを測定するオプションのフィードバックループ
• 実行時ポリシーエンジン：編集前の複合チェック（リース、ファイルのリスク、パスの拒否、セッションの健全性、直近の失敗）
• Agent Gateway（予測してから実行）：MCPの action_before ／ action_after に対応し、ゲートウェイが allow | rethink | block を返します。繰り返される低リスクのアクションには高速パスキャッシュを使用します
• MCPツールとREST APIを備えた暗号化シークレット保管庫（Fernet）
• 根本原因の絞り込みとイベントごとのコンテキスト再構築に対応したリプレイトレース
• 自動評価：セッション完了時にTier 1の品質指標10項目を算出し、傾向の追跡とリグレッションの検出を行います
• Knowledge Autopilot ラウンド1（可視化のみ、自律的な変更は行いません）：フィードバックで重み付けされた想起と memory_feedback ツール、クラッシュしたセッションを失敗として数えるBridgeセッションリーパー、人間の判定を伴う未確認メモリ間の矛盾の扱い（上書きせず意見の相違として扱う）、Autopilotレビュー受信トレイと週次ダイジェスト、メモリごとの根拠台帳（/memory/{id}/evidence）、および、どの草案が trial に、どの試行が active になるかを記録するシャドーモードのスキルラダー。docs/guides/knowledge-autopilot.md を参照してください
• Living Instructions ラウンド1 + 2（測定）：Autopilotタブに表示される指示ごとの遵守状況テーブル（判定条件は事前登録されたベースラインに固定）、経時的な傾向、ラウンド2の測定規約に対応します。レンダリングされたブロックに付与する指示内容のハッシュ、5つの帰属ヘッダー、実行環境ごとの内訳、公開／非公開／不明の状態を含み、検証できないものはすべて不明として報告します。人間の判定を伴う書き換えと、ブリーフィングで提示されるA/Bバリアントはロードマップ項目です。docs/ROADMAP.md の設計仕様を参照してください
• Dreaming：メモリの自動統合 + 人物プロフィール（DREAM_ENABLED、デフォルトでは無効）
• Living Procedures ラウンド1 + 2：人間のレビューのもと、手順として観察したスキルについて頻度／有効性の提案を行います。さらにラウンド2では、強制Runbookに対応します。コマンドステップの照合器、人間が有効化する advise／require_ack／block の強制、成功を条件とする根拠、challenge→ack→1回限りのpermitプロトコル、フェイルクローズのblockモード、ダッシュボードとAutopilot受信トレイに表示されるワークスペースごとの逸脱台帳を備えています（PROCEDURE_ENABLED、デフォルトでは無効。告知前に実環境で試用します）。docs/guides/living-procedures.md を参照してください
• Trust Ledger ラウンド1：リプレイゲートウェイのイベントから必要に応じて集計する、エージェントごとの稼働記録（GET /autopilot/trust + ダッシュボードカード）に対応します。申告数／照合済み数、予測一致度の較正、取り消し、セッションを記録します。可視化のみで、デプロイ全体に適用され、最初の数値を公開する前に計算式を事前登録して固定します。能力を強制的に仲介するブローカー（実績に応じた自律性）は後続ラウンドで対応します
• コーパスのテナンシー強化：すべての送信経路に共通の可視性フィルターを適用した、メンバー専用のドキュメントソース。メンバー間で同一のテキストが、削除可能な単一ポイントに統合されないよう、ソース単位のポイント識別を採用しています。プリンシパルを考慮したソース認可と、確定済み世代ゲートを備え、今後提供するクライアント側dexの基盤となります
• すべてのアダプターが登録する、劣化に強い単一のローカルMCPゲートウェイ。4つのリモートサービスに加え、クライアントローカルのDecision Boardと、登録されているdexを集約します
• dexレジストリ：dexはKeepが理解するドメインインデックスです。firekeep dex list|add|remove を使って ~/.firekeep/dexes.json を操作し、一覧表示や切り替えができます。3つのホイールはすべて、各リリースに同梱され、チェックサム検証済みです。登録が制御するのは有効化であり、インストールではありません。 Symdexとdocdexはデフォルトで登録されています（クライアント1.2.0以降、レジストリが存在しない場合は両方が登録されます）。無効化には firekeep dex remove を使い、削除状態はアップデート後も維持されます。同じファイルには機能も記録されます。これらはインデックスではなくドメインを操作するエントリーで、role: capability として示され、同梱も初期登録もされません。docs/guides/dexes.md を参照してください
• コードインテリジェンス：ゲートウェイの背後で動作するクライアント側の firekeep-symdex（38個のツールと、フラグで非表示になっている8個の分析機能）。dexとして登録するとマウントされます
• ドキュメント：クライアント側の firekeep-docdex。人間が登録したフォルダー（firekeep docdex add ~/Notes）からテキストを抽出してコーパスに取り込み、通常の memory_recall で検索できるようにします。共有Keepを使う場合もデフォルトではメンバー専用で、ワークスペース内で共有するには --shared を指定します。対応形式はmd/txt/pdf/docxで、OCRには対応していません。ローカルファイルを削除すると、次回の同期時にコーパス内の複製も削除されます
• メール：クライアント側の firekeep-maildex。メンバーが登録したIMAPメールボックス（firekeep maildex add）に対応し、読み取り専用です（開く操作はすべてEXAMINE、取得操作はすべてPEEKです。ホイールに送信機能はありません）。常にメンバー専用です
• デスクトップ：クライアント側の firekeep-hands。インデックスではなくレジストリ初の機能として、ドメインをインデックス化せずに操作します。実行環境がこのコンピューターのアプリとHands管理下のブラウザーを監視・操作し、重要な操作のたびに、実際のキー入力のみを受け付ける別個の承認ブローカーを通じた承認を必要とします。オプトイン方式で、同梱も初期登録もされません（firekeep hands enable）。画面ロック、昇格ウィンドウ、マシン外へのスクリーンショット送信、プロンプトインジェクションといった制約をdocs/guides/hands.mdに明記しています
• ドキュメントからスキルを生成する知識パイプライン（knowledge_ingest、URL取り込み）+ オプトイン方式のスケジュール済みConfluenceコレクター（SP3）
• メモリ、連携、リプレイ、ポリシー、運用管理に加え、DevicesとMembersの管理機能を備えたWebダッシュボード
• 外部からの検出に対応するA2Aエージェントカードエンドポイント（/.well-known/agent.json）
• 業務知識の取り込み：ドキュメントをチャンクに分割してベクトルストアに格納し、メモリ想起時に提示します
• Webhook通知（Slack、Discord、汎用HTTP）
• 認証：APIキーごとのスコープ（memory:read/write、session:read/write、replay:read、eval:read、admin、…）に対応し、デフォルトで有効です。キーはインストーラーによって初期設定されます

確約済み（firekeep.ai で公開しているロードマップの2項目）

• リンクされたインスタンス — 複数の Firekeep サーバーが組織内で知識を共有し、あるチームが学んだことを別のチームが呼び出せるようにします
• ドメインプロファイル — 共有の頭脳を通じて、同じクライアントキットのプロファイルとして別々の体験（現在はコーディングとドキュメント、今後はリサーチ）を提供します。別製品にも、別々のメモリストアにもなりません

両方の決定記録（クライアントではなくプロファイルを採用すること、リンク層の前提条件、成果シグナルによるゲーティング、順序付け）については、 docs/ROADMAP.md をご覧ください。

計画中（小規模な項目）

• Grafana メトリクスのエクスポート
• Jira コネクターによる取り込み（wiki/Confluence の自動同期はオプトイン方式で提供済み）
• スキルのバージョン管理とロールバック

ステータス

Firekeep は現在も積極的に開発されており、日々利用されています。メモリ、セッション、環境モニタリング、連携、リプレイ、クライアントキット、Symdex というコア実装は、現在のリポジトリにある4,000件を超える自動テストに合格しています。アーキテクチャは単一ホストへのデプロイを想定して設計されています。

この公開済みのソース利用可能なリポジトリは、早期アクセス段階です。

ライセンス

Firekeep は BUSL-1.1 のもとでソース利用可能です。セルフホストによる本番利用は個人にもチームにも無料で、管理下にあるインフラストラクチャ上で、規模を問わないワークスペースを利用できます。Firekeep の早期アクセス期間中は、チームも無料で利用できます。有償プランではエンタープライズ向けのガバナンスとサポートを提供します（[email protected] までお問い合わせください）。 各バージョンは、初回公開リリースから4年後に Apache-2.0 に切り替わります。ライセンスの全文は LICENSE、ステータスは docs/LICENSING.md をご覧ください。Symdex は、単独の Core が切り出され、Apache-2.0 のもとで別途リリースされるまでは、このライセンスの対象です。