AIREITER

Funesで構築するCoding Agent Memory：Claude Code + Codexセットアップガイド

最終更新日: 2026-09-03 19:26:47

パーサーをなぜ変更したのか、その根拠を1時間かけて突き止めても、次のタスクで別のエージェントを開けば経緯は途切れがちです。Funesはエージェントのセッションをローカルにインデックス化し、出典付きの原文証拠を返します。Claude Code、Codex、pi、Hermesで同じメモリを共有することも可能です。ただし、Funesができるのは履歴の検索までです。過去の判断を今の状況に適用すべきかどうかは、エージェント側で判断する必要があります。

ここでは、Claude CodeからCodexへ引き継ぐ実践的な構成を中心に、ローカル限定のメモリ運用、任意のHugging Face同期、汎用MCPクライアントとの接続、そして検索結果を有用に保つための確認手順を紹介します。

インストール前にメモリの共有範囲を決める

Funesを試す段階や、機密性の高いリポジトリを扱う場合は、まずローカルメモリから始めるのが安全です。別のマシンやチームとの間で履歴を共有したい場合にだけ、Hugging Face Datasetを紐付けましょう。

モード保存先最初に向く用途主な注意点
localローカルのLanceデータセット開発者1人・マシン1台別ホストへメモリが自動的に引き継がれるわけではない
<org>/<repo>ローカルのLanceデータとHugging Face Datasetリポジトリエージェントやマシンをまたぐ作業セッショントレースには機密コード、プロンプト、パス、認証情報が含まれる可能性がある

Funesのセキュリティポリシーによると、解析、チャンク分割、埋め込み、リランキングはデフォルトでローカル実行です。データがマシン外へ出るのは、funes pushを実行したとき、または共有メモリ連携がセッション境界で公開処理を行うときです。HubベースのメモリはDatasetリポジトリなので、最初のpush前に公開範囲を必ず確認してください。

最初の検証ではlocalを選びましょう。紐付け先は後からfunes add <agent> <memory>を再実行して変更できます。

Funesを導入して最初のインデックスを作る

Funesの公式リポジトリには、プラットフォームを検出し、タグ付きバイナリをダウンロードしてリリースチェックサムを検証するシェルインストーラーが用意されています。実行ファイルはデフォルトで~/.local/bin以下、つまりPATH上に配置されます。

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh

すぐにfunesが見つからなければ新しいシェルを開き、インストール状態を確認します。

funes status

リポジトリで配布されているタグ付きバイナリは、Linux x86_64、Linux aarch64、macOS Apple Silicon向けです。利用中の環境が一覧にない場合は、ビルド済みインストーラーが対応していると決めつけず、プロジェクトのソースからのビルド手順を使ってください。

5分で終える初期セットアップ

記憶させたいエージェントセッションがすでに存在する環境で、次を実行します。

funes add claude

Claude Codeでは、これにより初回インデックスの構築、読み取り用ツールの登録、連携自動化のインストール、完了したターンの継続的なインデックス化まで行えます。初回処理はテキスト優先で、確認後およそ1分とされています。巨大なツール出力よりも、文章や推論を先に取り込みます。(Funesセットアップドキュメント)

続けて状態を確認します。

funes status

Claudeのセッションを手動で初期投入または更新したい場合は、次を使います。

funes index --harness claude

パスを指定しないfunes indexは、~/.claude/projectsや~/.codex/sessionsを含む、Claude、Codex、pi、Hermesの標準セッション保存先を検索できます。--harness claudeを付けると、対象はClaude Codeだけに絞られます。インデックス作成ガイドでは、パスなし更新のテキスト優先予算もおよそ60秒と説明されています。古いセッションや大きなツール結果は、後続の実行で取り込む必要があるかもしれません。

Funesのインデックス作成は増分方式なので、再実行してもすでに書き込まれたチャンクを再埋め込みしません。明示的に指定したトランスクリプトのパスとHubのトレースリポジトリは、パスなし実行時の予算を使わず完全にインデックス化されます。(インデックスの詳細)

Claude CodeにFunesを接続する

Claude Code用にローカルメモリを設定するには、以下を実行します。

funes add claude local
funes status

localはデフォルト値なので、省略しても構いません。ターミナルでHFトークンが利用できる場合、Funesはユーザー所有の<user>/funes-memoryリポジトリを設定するか尋ねることがあります。ローカル限定の検証では、この確認を断ってください。

Claude連携は、フック専用プラグインと別途登録されるMCPで構成されています。FunesはClaude Codeのsettings.jsonを編集しません。自動化は完了ターンをインデックス化し、共有メモリ設定ではセッション境界での公開処理も加わります。(自動化の動作)

Claude Codeを開いたら、インストールの成否だけで判断せず、既知の過去の判断を検索して試してください。

Find the previous decision about the streaming parser. Use Funes recall if the repository history does not explain it, and cite the session you used.

良い結果なら、過去の該当箇所を示し、そのセッションを特定したうえで、古い実験と現在のリポジトリ状態を区別してくれます。

保存済みデータを削除せずに連携だけ解除するには、次を実行します。

funes remove claude

削除に関するドキュメントによれば、これでFunesの連携設定は削除されますが、ローカルメモリ、元のトランスクリプト、キャッシュ、公開済みメモリは保持されます。

同じメモリをCodexにも接続する

Claude Codeで動作を確認できたら、同じローカルメモリにCodexを追加します。

funes add codex local
funes status

Hubベースの共有メモリを使う場合は、両方のエージェントに同じリポジトリ識別子を指定します。

funes add claude <org>/<repo>
funes add codex <org>/<repo>

Codexには見落としやすい信頼設定があります。Funesはフックを~/.codex/hooks.jsonに書き込みます。Codex内で/hooksを実行し、Funesのエントリを確認して信頼してください。フックを信頼するまではCodexがそれらをスキップするため、新しいターンはインデックス化されず、メモリも公開されません。ドキュメントにあるメモリ紐付けワークフローにはCodex 0.151.0が必要です。(Codex自動化の要件)

エージェント間の引き継ぎを実際に試す

片方のセッションには存在し、もう片方には存在しない、特徴的な判断を使って検証します。

  1. Claude Codeでパーサーに関する判断を見つけ、議論中の特徴的な用語を控える。
  2. セッションを終了し、インデックス化と境界時の自動化が実行されるようにする。
  3. Codexでその用語について尋ね、以前の判断理由を要求する。
  4. 回答がソースハーネスとしてClaudeを特定し、元のセッションまたはターンを示していることを確認する。

証拠はターミナルから直接確認できます。

funes recall "why did we switch away from the streaming parser"

recallが返すのは生成要約ではなく、順位付けされた原文パッセージです。各ヒットにはソース情報と生成されたgetコマンドが含まれます。周辺ターンも確認したいときは、そのコマンドをコピーして実行してください。

Codexから何も返らない場合は、バージョン、/hooksの信頼状態、funes status、Claudeセッションが連携設定より前のものではないかを確認します。そのうえで、元の議論に含まれていた特徴的な用語でもう一度試してください。

pi、Hermes、その他のMCPクライアントをつなぐ

FunesはClaude CodeとCodexに加えて、piとHermesも直接サポートしています。piでは拡張機能イベントを使い、Hermesではシェルフックを利用します。Hermesのターン単位インデックス化はベータ機能として記載されています。(対応エージェントの詳細)

この4つ以外のMCP対応クライアントでは、Funesをローカルのstdioサーバーとして起動します。

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp"]
    }
  }
}

サーバーを共有メモリに紐付けるには、mcpの後ろにリポジトリを追加します。

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp", "<org>/<repo>"]
    }
  }
}

MCPドキュメントで公開されているのは、recall、get、statusです。funes mcpは読み取り専用であり、セッションのインデックス化やデータ公開は行いません。これらの処理には、funes index、funes push、または対応するfunes add連携を使用してください。

個別のMCP呼び出しで指定したメモリは、サーバーレベルの紐付けより優先されます。どちらも指定しなければ、Funesはローカルメモリを使います。

証拠を失わずにrecallを使う

Funesには3つの異なる利用方法があります。

コマンド出力使う場面
funes recall "…"出典情報付きで順位付けされた原文パッセージ証拠そのものを確認したいとき
funes get …参照されたターンと周辺コンテキストヒットは関連しているが情報が足りないとき
funes ask <agent> "…"根拠に基づく自然言語の回答1件連携を導入せず、ClaudeまたはCodexから素早く回答を得たいとき

ドキュメント上のrecallのデフォルトは、ヒット数8件、リランキング対象の候補プール30件、新しさの半減期30日、隣接チャンク1件です。(recallのフラグとデフォルト値)

デバッグでは、次の流れが堅実です。

  1. エラー、コンポーネント名、判断に使った表現でfunes recallを実行する。
  2. 生成されたgetコマンドでターン全体を確認する。
  3. 取得した判断を現在のブランチと照らし合わせる。
  4. 変更を加える、または実験を実行する。
  5. その結果を使って再び検索し、次のセッションで見つけられるようにする。

funes askの用途はより限定的です。まず検索を行い、選ばれたパッセージと質問をClaudeまたはCodexに渡して、1つの回答を生成します。子エージェントにはツール、stdin、MCPサーバーが渡されず、検索結果が不適切でも再検索できません。検索自体はローカルですが、質問と検索されたパッセージは、選択したエージェントに設定されているプロバイダーへ送信されます。そのためaskのドキュメントでは、プロバイダーに送信したくない内容にはfunes recallを使うよう勧めています。

信頼できる、運用可能なメモリに保つ

Funesはソースパッセージと出典情報を保持しますが、過去の回避策が今も有効かどうかまでは判断できません。

「メモリを退屈なインフラにすると、Coding Agentはずっと変な挙動をしなくなる。ローカルインデックス、正確な出典情報、そしてデフォルトは非公開。」 — Xの@TheArtemisHunts

本番運用前の小さなチェックリスト

状況確認項目対応
Codexが何も検索しないフックの信頼状態とバージョン/hooksを実行し、Funesのエントリを信頼して、Codexが0.151.0であることを確認する
古いセッションが見つからないインデックス範囲と処理枠funes index --harness claudeまたは--harness codexを実行し、大きな出力は後続処理で補完されるようにする
リモートへのpushがブロックされるTruffleHogとトークンのスコープTruffleHogをインストールするかFUNES_TRUFFLEHOGを設定し、pushするマシンだけで細粒度の書き込みトークンを使う
検索結果にシークレットが含まれるローカルのスクラブ状態funes scrubを実行してから再度pushする。元のトランスクリプトは変更されない
リモートメモリを共有している公開範囲と信頼性意図して公開する場合を除きデータセットは非公開に保ち、第三者由来の検索テキストは信頼できないエージェント入力として扱う
最後のセッションがHubに反映されていない境界処理のタイミングマシンを手放す前にfunes push <org>/<repo>を実行する

Funesはインデックス作成時に認証情報をマスキングし、公開前にはfail-closed方式のTruffleHogスキャンを実行します。pushのドキュメントによると、スキャナーがない場合は公開がブロックされます。生きた認証情報がリモートDatasetに到達してしまった場合は、後のコミットをスクラブしてもリポジトリ履歴を消せないため、直ちにローテーションしてください。

Hugging Faceトークンは最小権限で運用します。公開するマシンには書き込みスコープ、検索だけを行うチームメイトやホストには読み取り専用スコープを使ってください。同じリモートメモリに2台のマシンから公開すると競合する可能性もあります。自動化のドキュメントでは、マシン間の直列化は保証されていません。

実用上の選び方

最初からすべての連携を入れるのではなく、用途に応じて次の構成から始めるとよいでしょう。

ワークフロー推奨構成理由
永続メモリを評価する開発者1人funes add claude localデータ共有リスクが最も低く、ロールバックも簡単
Claude Codeで計画し、Codexで実装またはレビューする両方を同じlocalメモリに紐付ける同一ホスト上でエージェント間の推論を保持できる
複数マシンでエージェントを使う両方を同じ非公開の<org>/<repo>メモリに紐付けるHub Datasetを通じて開発者にメモリを追従させられる
チームのプロジェクト履歴非公開Datasetと、閲覧者向けの読み取り専用トークン公開権限と検索アクセスを分離できる
未対応のMCPエージェントfunes mcp [memory]インデックス作成を明示的な処理として残しつつ、読み取りアクセスを追加できる
機密性の高いソース資料ローカルメモリとrecallリモート公開と、プロバイダーへの一度きりの送信を避けられる

Funes coding agent memory FAQ

Funesはローカルで動作しますか？

Funesはデフォルトでメモリをローカル処理・ローカル保存します。ただし、ローカルファーストであって、自動的にローカル限定になるわけではありません。push、共有メモリフック、askでは、ローカルプロセスの外へデータが送られる可能性があります。

FunesはClaude CodeとCodexに対応していますか？

はい。funes addはClaude CodeとCodexに加え、piとHermesにも対応しています。Codexでのメモリ紐付けには0.151.0と、信頼済みフックが必要です。

Funesはセッションを自動でインデックス化しますか？

funes addの実行後、対応する連携ではターン単位のインデックス化自動化がインストールされます。初回セットアップには処理上限があるため、古いセッションや巨大なツール結果は後続の実行で取り込む必要がある場合があります。

Claude CodeとCodexで同じメモリを共有するには？

funes add claudeとfunes add codexの両方に、同じ<org>/<repo>引数を指定します。Funesは作業用インデックスをローカルに保持し、セッション境界で共有Datasetを公開します。

Funesが古い判断を検索した場合は？

funes recallで内容を確認し、生成されたgetコマンドで範囲を広げ、実行前に現在のブランチと照合してください。最初の検索で外れた場合は、クエリの表現を変えます。

funes askのデータはマシン内に留まりますか？

検索とリランキングはローカルですが、askは質問と検索されたパッセージを、設定済みのClaudeまたはCodexプロバイダーへ送信します。機密性の高い証拠にはrecallを使ってください。

メモリを削除せずにFunesを外せますか？

はい。funes remove claude、funes remove codex、funes remove pi、funes remove hermesは連携設定だけを削除し、インデックス済みメモリと元のトランスクリプトは保持します。