Honcho レビュー: メッセージ保存とバックグラウンド推論で作るエージェント記憶

Honcho が埋めようとしているのは検索ではなく記憶の更新

RAG の多くは、質問に似たチャンクを引いてくる。Honcho が狙うのはそこではなく、会話やイベントから結論を抽出し、ピアと呼ばれる主体ごとの表現を時間とともに更新する部分である。README の表現を借りれば reasoning-first memory、つまり類似度マッチングではなく推論を先に置く設計だと説明されている。

対象は明快で、状態を持つエージェントを作る開発者である。ユーザー、エージェント、グループ、プロジェクト、アイデアといった主体が時間の中で変化することを前提に置く。README の導入表では、コーディングエージェントに記憶を持たせたい場合は MCP 経由、プロダクトに組み込む場合は SDK、ローカルで動かす場合は CLI という三つの入口が示されている。

ここで注意したいのは、Honcho がベクトル検索の置き換えを主張していない点である。保存したメッセージに対する検索も提供するが、中心にあるのはセッション上のメッセージを材料にしたピア表現の生成と、その表現に対する自然言語の問い合わせである。記憶を「引く」ものではなく「育つ」ものとして扱う立場だと言える。

ワークスペース、ピア、セッション、メッセージという四層

データモデルは README に明示されている。ワークスペースがピアを保持し、ピアがセッションに参加し、メッセージはセッション上に存在する。そして Honcho はピア単位の表現を構築し、それを Chat Endpoint か SDK から直接問い合わせる。

Python の例では honcho.peer("alice") と honcho.peer("tutor") で二つのピアを作り、honcho.session("session-1") に両者のメッセージを追加している。このとき alice.message(...) と tutor.message(...) という形で発話者がメッセージに紐づく。誰が何を言ったかがピアに帰属するため、後段の推論が主体ごとの表現を更新できる。

読み出し側は二系統ある。alice.chat("What learning styles does the user respond to best?") は自然言語の答えを返し、session.context(summary=True, tokens=10_000) はプロンプトに差し込むためのコンテキストを返す。後者は context.to_openai(assistant=tutor) で OpenAI 形式のメッセージ配列に変換できる。つまり Honcho は記憶の生成と、LLM 呼び出し直前の整形という二つの役割を分けて提供している。

マルチピアの観点も README の機能表に挙がっている。あるピアが別のピアについて何を知っているかをモデル化する、という記述である。ただし README の範囲では設定方法までは踏み込んでおらず、この機能の実効性はドキュメント側を確認する必要がある。

保存と推論が非同期に分かれている点が設計の要

Honcho Loop は四段階で説明される。Store、Reason、Query、Inject である。このうち Reason には「バックグラウンドでキューを処理する」と明記されており、メッセージ追加がその場で表現更新を完了させるわけではない。

この非対称性は実装上の帰結を持つ。session.add_messages(...) の直後に alice.chat(...) を呼んでも、追加したばかりの発話が反映されていない可能性がある。README のサンプルコードでも Reason の行はコメントだけで、待機や同期のコードは書かれていない。結果整合性を前提にアプリケーションを組む必要がある。

もう一つの含意は、推論そのものが別の LLM 呼び出しを伴うという点である。README にはどのモデルを使うか、キューがどの程度の遅延で回るかは書かれていない。セルフホストする場合、このバックグラウンド処理の設定とコストは自分で引き受けることになる。記憶を「保存するだけ」のライブラリと比べたときの最大の違いがここで、運用対象がデータベースだけでなく推論ワーカーにも広がる。

導入手順: CLI でローカルスタックを立てるか SDK から叩くか

マネージドを使う場合、app.honcho.dev で API キーを取得し、SDK の base_url を省略する。Python なら pip install honcho-ai、TypeScript なら npm install @honcho-ai/sdk で入る。環境変数は HONCHO_API_KEY を読み、セルフホスト時は base_url="http://localhost:8000" を渡すか HONCHO_URL を設定する。README のコメントにこの二通りが併記されている。

ローカルで動かす場合は honcho-cli を入れ、honcho start --setup を実行する。README の導入表では「Install CLI, then honcho start --setup」という順序が示され、起動後は SDK の向き先を http://localhost:8000 にする。

運用の確認用コマンドも CLI に用意されている。honcho workspace inspect はデプロイの状態を見る用途、honcho doctor は診断用として表に挙がっている。ソースからセルフホストする場合は Docker Compose かローカル開発の二経路が示されている。

構成として押さえておくべきは、このリポジトリが FastAPI サーバー本体をホストし、Python と TypeScript の SDK は sdks/ ディレクトリに、honcho-cli も同じリポジトリ内にあるという分割である。サーバーのバージョンは README 冒頭のバッジで 3.1.2 と表示されている。

同期前提のアプリには組み込みにくい

最も素直な制約は、記憶の更新が非同期であることだ。ユーザーの発話に対して「今この瞬間の記憶」を根拠に応答させたい場合、Honcho のループはその要求と噛み合いにくい。会話の途中で得た情報を同じターンで反映させたいなら、アプリケーション側の短期記憶を別に持つことになる。

二つ目はライセンスである。AGPL-3.0 はネットワーク越しに利用者へ機能を提供する形態でソース開示の条件が関わってくる。マネージドの api.honcho.dev を使えばこの条件は自社の配布物には及ばないが、自前でホストして外部に提供する場合は条件の確認が要る。ここでは法的助言はできないので、配布形態と改変の有無を整理したうえで判断されたい。

三つ目は、記憶の抽出を LLM に委ねる設計そのものの不確実性である。抽出された結論が誤っていれば、その誤りがピア表現に残り続ける。README には抽出結果を人手で確認する仕組みや、誤った記憶を選択的に削除する手順についての記述が見当たらない。訂正や削除の経路はドキュメントで確認すべき項目である。

最後に、Honcho は検索エンジンではない。大量のドキュメントから該当箇所を厳密に引く用途では、チャンク単位の検索を持つ既存の仕組みのほうが素直に機能する。Honcho の検索はあくまでピア表現を補助する位置づけだと読める。

Mem0 との違いは抽出の単位をピアに置くかどうか

比較対象として分かりやすいのは Mem0 である。どちらも会話から記憶を抽出して保存し、必要なときに呼び出すという枠組みを共有する。違いは抽出と保持の単位にある。

Mem0 は会話から事実や好みを抽出して記憶として蓄積し、検索して文脈に差し込む。記憶は基本的にフラットな集合として扱われる。Honcho は同じ抽出を行いつつ、それをピアという主体に紐づける。alice の表現、tutor の表現が別々に存在し、さらに「alice が tutor について何を知っているか」という関係まで扱おうとする。

この差は、単一ユーザーと単一アシスタントの対話ならほとんど現れない。効いてくるのは、複数の人間と複数のエージェントが同じセッションに参加する場面である。誰の視点で記憶を組み立てるかが変わるためだ。

運用面でも差が出る。Mem0 はライブラリとしてアプリに組み込む形が取りやすいのに対し、Honcho は FastAPI サーバーとして動く前提が前面に出ている。honcho start でローカルスタックを立てる手順が README の主要な導線になっていることがそれを示している。

セルフホストを選ぶ前に確かめる三つの設定

self-hosting の節では Docker Compose とローカル開発の二経路が示されているが、README の抜粋には具体的な compose ファイルの中身や環境変数の一覧までは含まれていない。Configuration の節が目次に存在することは分かるが、そこで定義されているキーの名前は手元の資料からは確認できない。設定の実体は docs.honcho.dev 側で確認する必要がある。

確認すべき項目は三つに絞れる。第一に、バックグラウンド推論がどのモデルプロバイダを使う設定になっているか。Reason の段階が別の LLM 呼び出しを伴う以上、ここが未設定なら記憶は更新されない。第二に、推論キューの滞留をどう観測するか。honcho doctor がどの範囲を診断するのかは README の表からは読み取れないため、実際に走らせて出力を見るのが早い。第三に、session.context の tokens パラメータとモデルのコンテキスト長の関係である。サンプルでは 10_000 が指定されており、この値が要約と生メッセージの配分をどう決めるかは実測で確かめるしかない。

アップグレードのコストについては、リリースが取得できていないため互換性の傾向を判断できない。README のバッジが Server 3.1.2 を示していること以外、バージョン間の移行に関する記述は手元の資料にない。サーバーと SDK が同一リポジトリで管理されている点は、追従の負担を下げる方向に働く可能性があるが、これは推測であって確認された事実ではない。

編集部の結論

向いているのは、ユーザーやエージェントをまたいだ長期の記憶を自前のデータとして持ちたい開発者と、Python か TypeScript の SDK から数行で記憶層を足したいチームである。向かないのは、同期処理だけで完結させたい場合や、AGPL-3.0 の条件を自社の配布形態と突き合わせられない場合である。導入前に確認すべきは、honcho start --setup でローカルスタックが立ち上がるか、セルフホスト時のバックグラウンド推論がどのモデルとキーで動くか、そして session.context が返すトークン数が自分のコンテキスト予算に収まるかである。この三点が確認できるまでは、マネージドの api.honcho.dev で試すほうが判断材料が早く揃う。

公式情報源

1. Issues
2. License: AGPL-3.0
3. plastic-labs/honcho on GitHub
4. Project website
5. README