Hugging Face funes とは:データの持ち出し境界と8倍の分母

この記事は海外の一次情報をAIエージェントが調査・検証して整理したもので、実際に試した体験談ではありません。

結論:既定ではローカル完結、外に出るのは自分でバインドしたときだけ

Hugging Face が2026年9月3日に公開した funes について、押さえる点は3つです。

既定(バインドなし)では索引化が手元で完結する。ただし「ホストされたモデルが処理しない」のは索引化についてで、推論は利用者のエージェントの側
Hub へ出るのは funes add でメモリをバインドしたとき。funes が作ったリポジトリは既定で非公開だが、既存のリポジトリは現在の可視性を保つ
公開メモリにした時点から不可逆。リモートは追記のみで、上がったセッションは取り消せない

以下はすべて Hugging Face 自身の発表に依拠しています。2026年9月4日時点で、第三者による追試や検証記事は英語圏でも確認できませんでした。

何が公開されたのか

Hugging Face は funes を、コーディングエージェント(Claude Code / Codex / pi / Hermes)のための永続的なメモリ層だと説明しています。

項目	内容
公開日	2026年9月3日(Hugging Face 公式ブログ)
コード	github.com/huggingface/funes
ライセンス	Apache License 2.0
主要言語	Rust

ライセンスと言語は GitHub のリポジトリ記録を2026年9月4日に取得した値です。

対応エージェントには段階差がある

「4エージェント対応」と一括りにすると、次の段階差が落ちます。

エージェント	原典が記す条件
Hermes	ターンごとの索引化は beta(shell hooks)
Codex	セッション境界での publish に Codex 0.151.0 が必要
Claude / Codex / Hermes	`funes add` が初回ブートストラップ(索引構築・フック導入・初回 push)を実行

条件別:データはどこに置かれ、誰が読めるのか

段階	操作	データの置き場所	読める人
1	何もしない(既定)	ローカルの Lance データセット	自分のマシンのみ
2	`funes add <エージェント> <組織>/<リポジトリ>`	利用者が所有する Hugging Face データセット	リポジトリの権限を持つ人
3	Hub でリポジトリを公開に変更	同上(可視性が public)	誰でも(`--memory` で読める)

段階1でローカルに閉じるもの・閉じないもの

処理	どこで動くか
パース・チャンク化・埋め込み・再ランキング	利用者のマシン
推論(reasoning)	利用者のコーディングエージェント

原典の該当文は「ホストされたモデルは、索引化のためにあなたのセッションを処理することはない」であり、同じ文が「推論はあなたのコーディングエージェントが行う」と続きます。呼び出された抜粋はそのエージェントのコンテキストに入るため、「セッションが一切外に出ない」とは言えません。SECURITY.md も、funes push を実行するか共有メモリをバインドしない限り何も手元から出ない、という条件つきの書き方です。

段階2の既定値の読み方

対象のリポジトリ	可視性
funes が新規作成したもの	既定で非公開
既存のものを指定した場合	現在の可視性を維持
公開に変える操作	Hub 上での意図的な変更

SECURITY.md は、公開したくない履歴を push する前に Hub で可視性を確認するよう求めています。

段階3が不可逆である理由

docs/push.md は、リモートが追記のみ(append-only)で、公開対象の選別は公開前のゲートであり取り消しではないと明記しています。公開メモリの実例 huggingface/funes-memory のカードには、2026年9月2日時点でチャンク数27,118、埋め込みモデル BAAI/bge-small-en-v1.5 と記載されています。

秘密情報スキャンが担保する範囲

層	動作	原典が付けている条件
索引時のリダクション	保存前に認証情報を削除	docs/push.md は「TruffleHog が利用可能なとき」の best-effort とし、無ければ警告して索引化を継続
公開時のゲート	全チャンクを走査し、秘密が残る行を差し止めて非ゼロ終了	fail-closed。スキャナが無い・落ちた場合は何も公開されない
`funes scrub`	ローカルの行から秘密を除去	公開済みのリモートは変更しない

SECURITY.md は、ゲートが止められるのはこれから入る行であり、公開済みのものは取り消せないとしています。fail-closed は「秘密が必ず止まる」ではなく「スキャナが動かないなら何も出さない」という意味です。

「8倍・4倍安い」は何と何を比べた値か

Hugging Face は handoff-vs-recall ベンチマークで、recall が一方のタスクでは書かれた handoff の8分の1、もう一方では4分の1のコストだったと述べています。測定の枠組みは次のとおりです。

項目	内容
規模	5経路 × 2タスク × 各3レップ = 30ラン
タスク	`rerank-triage` と `recall-features` の2件のみ
軸	成功したタスクあたりの重み付きトークン
重みの定義	入力 + 1.25×キャッシュ作成 + 0.1×キャッシュ読み + 5×出力
ドル建て	結果ページから除外(課金階層がコンテキスト窓の設定で決まるため)

経路別の結果(成功あたり重み付きトークン)

経路	rerank-triage	recall-features
A 何も持ち越さない	到達せず	到達せず
B 書かれた handoff	851k	637k
C recall(funes)	101k	169k
D 切らずに全コンテキスト維持	822k	651k
E compact して継続	778k	到達せず

851÷101 は8.43倍、637÷169 は3.77倍で、公式表記の「4倍」は3.8倍の切り上げです。

倍率を決めているのは一度きりの準備費用

経路	一度きりの費用の扱い	rerank-triage	recall-features
B(handoff)	3レップで割らず満額を1回加算	808k	538k
E(compaction)	同上	734k	549k
C(recall)	計上なし(`funes index` にAPI課金が無いため)	―	―

1レップの本番ターンだけなら、B は39k・39k・50k、C は148k・78k・78k です。準備費用を除けば handoff のほうが安く、データセットカード自身が「たいていこの費用が両者の勝敗を決める」と認めています。同じ handoff を何度も使い回す運用では、この比較はそのままでは成立しません。

なお原典は、rerank-triage の B の一度きり費用808kについて、領収記録が失われたための再構成値だと注記しています(recall-features 側の538kには記録あり)。851k の大半がこれにあたります。

compaction は2タスクで結果が割れた

Hugging Face によれば、compaction は3方式のうち唯一結果が割れた経路で、rerank-triage では毎レップ到達し、recall-features では到達しませんでした。要約が重要な発見を平板化したためだとしています。到達しない経路には成功あたりのコストが存在しませんが、費用が発生しなかったわけではなく、recall-features では648kを費やして「何も持ち越さない」経路と同じ地点に着地した、と原典は書いています。ただし results/README.md はこれを「この調査の発見を compaction が落とした」話であって「compaction 一般についての主張ではない」と自ら限定しています。

引用するときに落としやすい点

「セッションログが外部に一切出ない」── 原文の限定は索引化についてです。推論は利用者のエージェントが行います
「共有メモリは必ず非公開」── 既定で非公開なのは funes が作ったリポジトリだけです
「8倍安い=請求額が8分の1」── 軸は重み付きトークンで、原典はドルを比較不能として外しています
「recall は常に8倍安い」── 実測は2タスク分の8.43倍と3.77倍のみで、準備費用を満額1回計上した扱いに依存します
「compaction は要約で情報を落とすので使えない」── 原典が一般化を明示的に禁じます
「日本語のセッションでも同じように検索できる」── 原典は日本語での挙動に触れていません

IBM Researchが8モデルで実測、エージェントの記憶は「多いほど良い」ではない — 記憶をどれだけ注入するかの最適値
@huggingface/kernels の2.57倍とは:母数と測定条件 — 倍率の母数を戻した別の例