Nahuali

Nahuali

エージェントが信頼する前に検証できるメモリ。

_{空のメモリから証拠に裏付けられた想起まで：Nahuali は使用可能な情報を示し、レビューが必要な情報は保留します。}

メモリ検索は通常、*どのコンテキストが関連していそうか？*という問いから始まります。Nahuali ではさらに、次の4つの問いを個別に確認できます。

• このメモリを裏付ける観察結果は何ですか？
• 何がこのメモリと矛盾するか、または古くしていますか？
• 現在記録されている履歴のチェックに合格していますか？
• 利用可能な証拠と健全性チェックは、この結果の使用を裏付けていますか？

その結果、決定論的な信頼性判定、改ざんの痕跡を検出できる記録履歴、持ち運び可能な証拠を備えたローカルファーストのメモリエンジンが実現します。コア機能にモデル、アカウント、API キー、ホスト型サービス、Docker は必要ありません。

60秒でわかる Nahuali

macOS または Linux 用のバイナリをインストールします。インストーラーには、一致する SHA-256 アセットが必要です。以下の固定パスでは、Sigstore バンドルも必須にできます。

curl -fsSLo /tmp/nahuali-install.sh \
  https://raw.githubusercontent.com/Arakiss/nahuali/main/scripts/install.sh
sh /tmp/nahuali-install.sh
export PATH="$HOME/.nahuali/bin:$PATH"

ターミナルで nahuali --version を実行すると、ビルド識別情報とともに、本物のアホロートルのスプライトシートが動き出します。コマンドの出力が取得またはリダイレクトされる場合は、エージェント、インストール確認、ベンチマークツールが想定する安定した nahuali <semver> の行を出力します。

観察結果を記録し、そこから主張を導き出し（--source-last は直前に記録したエピソードを引用します）、想起時に証拠を必須にします。

nahuali remember "Lena owns the release notes" --mention Lena --tag product
nahuali claim Lena owns "release notes" --source-last --confidence 0.92
nahuali recall "Who owns the release notes?" --authority --require-evidence
nahuali explore

nahuali explore は単なる記録ブラウザーではありません。互いに独立した3つの問いを常に確認できます。

軸	確認する内容
MEMORY	このメモリは使用できるだけの裏付けがありますか？
HISTORY	このストアの記録履歴チェックに合格していますか？
EXTERNAL	この状態は、このストアの外部に保管された許可済みの参照情報と照合されましたか？

/ を押すと、表示されているすべてのメモリアイテムのフィールドを検索できます。Tab でメモリの種類を絞り込み、j／k で結果の根拠となる証拠を調べられます。アホロートルはメモリを見守り、その状態に応じて変化します。上の GIF は、scripts/render-readme-tui-gif.sh を使い、macOS 上の実際の Ghostty ウィンドウから再生成できます。正規版の README アセットが、低品質のテキスト代替版に置き換えられることはありません。

nahuali demo を実行すると、特定の記録がその場で変更されたことを Nahuali がどう検知し、裏付けのないメモリが行動を左右しないようにするかを、状態を変更せずにナレーション付きで確認できます。このデモでは、稼働中のストアだけに頼らず、外部に保持した参照情報が必要となる変更も説明します。

Nahuali の適した用途

ローカルまたは運用者が管理するメモリが必要で、結果を使う判断に証拠、健全性シグナル、明示的な完全性の制約を伴わせたい場合は、Nahuali を選んでください。特に、あらゆる検索システムを置き換えるものとしてではなく、重大な影響を伴うメモリを取り巻く信頼性レイヤーとして役立ちます。

主な要件がホスト型の運用、幅広いフレームワークのエコシステム、または公開された LoCoMo／LongMemEval の回答品質に関する結果である場合は、実績のある想起優先型またはマネージド型のメモリプラットフォームを選んでください。Nahuali は、現時点でこれらの面での優位性を主張していません。アプリケーションでは、別の検索システムに Nahuali の証拠確認とガバナンスチェックを組み合わせることもできます。

Nahuali が確認すること

証拠は記憶の一部です

観察は、第一級のエピソードです。主張、関係、手順、意図は、それらを裏付けるエピソードを参照できます。その参照経路がない結果については、確信を示す表現で不足分を補うのではなく、想起時に提示を拒否できます。

判定は関連性とは別に保たれます

権威性を考慮した想起では、次の4つの決定論的な判定のいずれかが付与されます。

判定	意味
certify	利用可能なチェックにより、添付された証拠とともに使用できることが裏付けられています。
advisory	手掛かりとしては有用ですが、条件を付けずに事実として繰り返すには適していません。
warn	証拠、新鮮さ、またはストアの健全性に問題があるため、検証が必要です。
block	矛盾が解決するまで、その記憶を行動の根拠にしてはなりません。

certify 判定は、真実であることも、著者が誰であるかも証明しません。利用可能な証拠とコンテンツの健全性チェックに合格したことを意味します。内部の履歴チェックについては HISTORY を、任意の外部比較については EXTERNAL を、それぞれ別途確認してください。Nahuali は、こうした制限を文書に隠すのではなく、機械可読な形式で保持します。

履歴を検査できます

正式な台帳は追記専用で、ハッシュチェーンで連結されています。Merkle 包含証明と整合性証明により、検証を簡潔に行えます。また、Ed25519 チェックポイントにより、ツリーサイズ、ルート、チェーンの先端、オリジン、台帳の系譜が、外部オペレーターのポリシーに結び付けられます。

Nahuali はブロックチェーンではありません。プライベートな記憶を公開ネットワークに公開したり、合意形成を必要としたりせずに、RFC 9162 で標準化された透明性ログの基本要素を適用します。独立した証人による共同署名は将来の取り組みであり、現時点の機能として謳うものではありません。

1つの主張を証明書とともに持ち運べます

ポータブルな主張の証明書には、選択した主張、その証拠となるエピソード、任意のソースエンベロープ、それぞれの Merkle 包含パス、署名済みチェックポイント1つのみが含まれます。検証はオフラインで行われ、証明書とは別に保持されるポリシーが必要です。

CLAIM_ID="$(nahuali data --json | jq -r '.claims[-1].id')"
nahuali receipt-export \
  --claim-id "$CLAIM_ID" \
  --checkpoint checkpoint.json \
  --policy policy.json \
  --output claim-receipt.json

nahuali receipt-verify claim-receipt.json --policy policy.json

検証ツールは、receipt_integrity と content_authority を別々に報告します。台帳へのコミットメントは、記憶された記述が真実であること、著者が本人であること、または外部ソースに同じバイト列が現在も含まれていることを主張するものではありません。

オフラインでの証明書検証では、選択されたエンベロープ、その Merkle パス、来歴リンク、チェックポイントの認可のみをチェックします。認可された署名者がそのルートにコミットしていることを信頼しますが、台帳のプレフィックス全体を再生したり検証したりはしません。より強力なチェックには、台帳とともに checkpoint-verify を使用してください。証明書には、選択された記憶がそのまま含まれているため、デフォルトで公開せず、機密データとして扱う必要があります。

エージェント向けに構築され、人間が操作可能

CLI が基準となります。TUI、stdio MCP サーバー、ローカル HTTP API、Rust クレートは、すべて同じ決定論的エンジンを使用します。

インターフェース	用途	リファレンス
nahuali	シェルを使用できるエージェント、スクリプト、継続的な取り込み、検査、復旧、レシート、TUI	CLI
nahuali-mcp	MCP ツールを公開するものの、ローカルコマンドを直接実行できないホスト	MCP
nahuali-api	OpenAPI コントラクトを使用するローカル HTTP 統合	HTTP API
nahuali-core	Rust へのエンジンの組み込み	コア

ターミナルベースのエージェントワークロードには CLI を優先してください。CLI は直接操作できるスクリプト対応インターフェースであり、MCP ツール呼び出しの往復なしにバッチコマンドをサポートし、呼び出しごとにデータベースと JSON の正確なコントラクトを明示します。MCP は、統合境界がツールプロトコルであるクライアント向けのアダプターです。どちらのインターフェースも信頼性の意味は同じです。CLI を選んでも検証は回避されません。組み込みストアのプロセスオーナーは常に 1 つです。短時間の CLI コマンドは（NAHUALI_STORE_LOCK_TIMEOUT_MS で制限され、デフォルトは 30 秒）、そのプロセスのためにキューに入ります。一方、実行中の MCP サーバー、HTTP API、または TUI は、そのライフサイクル全体にわたってストアを保持します。独立した長時間実行プロセス間で共有アクセスが必要な場合は、リモート SurrealDB（--store ws://…）を使用してください。

nahuali init を実行すると、サポートされている環境に同梱のエージェントスキルがインストールされ、ネイティブの MCP 設定が出力されます。Nahuali は公式 MCP Registry に io.github.Arakiss/nahuali としても公開されています。ネイティブおよびコンテナの設定については、MCP の導入を参照してください。

HTTP API は意図的に認証を行わない設計のため、信頼できないネットワークに公開してはいけません。

ストレージと復旧

SurrealDB の memory_record が信頼できる唯一の情報源です。現在のメモリービュー、グラフテーブル、スナップショット、セマンティックベクトルは、そこから派生するものであり、再構築できます。

• 通常の書き込みでは、台帳イベントを 1 つ追記し、インメモリービューを更新して、目的のグラフと最後に検証済みのグラフプロジェクションを比較し、新規または変更された行だけを書き込みます。存在しなくなった行は削除されます。
• 保存済みプロジェクションのチェックポイント、スキーマバージョン、エラー状態、またはコンテンツマニフェストを信頼できない場合、Nahuali は派生グラフをクリアして、台帳から再構築します。復旧によって信頼できる履歴が書き換えられることはありません。
• 組み込みの SurrealKV は、サービス不要のデフォルトです。
• リモート SurrealDB は、意図的に共有するデプロイメントをサポートします。
• Qdrant や埋め込みモデルがなくても、語彙的な想起は機能します。
• Qdrant とローカル埋め込みは、オプションのセマンティック層です。
• グラフプロジェクション v2 は、同時再構築をフェンスし、行数だけでなく、台帳から派生するすべてのプロジェクション対象テーブルについて、正規化されたコンテンツマニフェストを検証します。SurrealDB のプロジェクションに依存するエンティティ、タイムライン、保留中の作業、ヘルスの読み取りは、再構築中、またはマニフェスト、スキーマバージョン、台帳の先端にずれがある場合、フェイルクローズします。
• セマンティック検証器は、その派生層を信頼する前に、ベクトルインデックスのずれを検出します。
• バックアップからの復元では、台帳を再生して派生状態を再構築します。

組み込みストアのプロセスオーナーは常に 1 つです。2 つ目のプロセスは上限付きのバックオフを伴ってロックを待つため、並行する短時間のコマンドは失敗せずにキューに入ります。また、無期限に待機したり、同時書き込みのリスクを冒したりすることなく、NAHUALI_STORE_LOCK_TIMEOUT_MS の経過後に明確なエラーで失敗します。--store <PATH|URL> はストアの保存場所を選択し、--database <NAME> はその中のデータベースを選択します。

nahuali forget <id> --reason ... は、監査可能な記録を残しながら ID でメモリーを消去します。そのメモリーを保持する台帳レコード（およびそこから派生したメモリー）は、ハッシュチェーンの検証を可能にする墨消し済みのスタブになり、memory_forgotten レコードには、誰が、いつ、なぜ要求したかが記録されます。バックアップ、エクスポート、レシート、または未再構築のセマンティックインデックスには反映されません。正確な制限については、GDPR に関する見解を参照してください。

エビデンスと評価の限界

アダプター方式の Agent Memory Trust Benchmarkは、 来歴、回答の保留、矛盾、情報の古さ、変更を伴わない検査、改ざん検知を 個別のケースとして、製品横断の評価を行うよう設計されています。リポジトリに 含まれる結果は、独立した比較ではなく、Nahuali 自身のエビデンスです。 検索ベンチマークでは、 バージョン管理された24件のメモリと12件のクエリからなるコーパスについて、 順位付けされたすべての項目とレイテンシーのサンプルを公開しています。

リポジトリに含まれる0.8.0-beta.9の結果は、自プロジェクトのソースからの ビルドで、バージョンが一致しています。バイナリの SHA-256 とソースの リビジョンに紐付けられていますが、公開済みリリースアーカイブであるとは 主張していません。新たに公開するリリースの結果では、 リリースタグ、ターゲット、アーカイブ名、アーカイブのダイジェスト、 および正確なバイナリも、scripts/verify-benchmark-artifact-identity.py で一致させる必要があります。

この小規模な検索コーパスは回帰テストの基準であり、最先端であることを 主張するものでも、LoCoMo や LongMemEval の代替でもありません。リポジトリに 含まれる、より広範な ガバナンススイートでは、信頼性に関する固有の 失敗クラスをテストします。制御されたベータのゲートを実行するには、次のようにします。

bash scripts/verify-controlled-beta.sh

メンテナーは、必要な GitHub リポジトリ設定を個別に確認できます。

NAHUALI_VERIFY_GITHUB_SETTINGS=1 bash scripts/security-supply-chain-check.sh

ベータ版の制約

• エビデンスが証明するのは追跡可能性であり、事実の正しさではありません。
• 信頼されたチェックポイントが証明するのは、コミット済みの台帳の状態であり、独立した時刻ではありません。
• ロールバックや、履歴全体を再チェーンしたことの検出には、外部チェックポイントとポリシーを保持する必要があります。
• スコープラベルはコンテキストを整理するものであり、アクセス制御の境界ではありません。
• 自己検査では作業を提案しますが、自律的にメモリを書き換えることはありません。
• forgetはストアとそこから派生した階層からコンテンツを削除しますが、以前に作成されたコピーは削除しません。完全な消去を証明するものではありません。
• アカウント、ホスト型同期、課金、マネージドコントロールプレーンは含まれていません。
• API とストレージの動作は、1.0より前に変更される可能性があります。

取り替えのきかないデータを使用する前にBETA.mdを読み、 判定を認可の境界として扱う前に、完全な 信頼モデルを確認してください。

バージョンを固定してリリースをインストールする

上記の簡易インストーラーでは、対応する SHA-256 アセットが常に必要です。 Sigstore バンドルも必要となる、バージョンを固定したインストールでは、 リリースタグを選び、同じタグのインストーラーを実行してください。

VERSION=vX.Y.Z-beta.N
curl -fsSLo /tmp/nahuali-install.sh \
  "https://raw.githubusercontent.com/Arakiss/nahuali/${VERSION}/scripts/install.sh"
NAHUALI_VERSION="$VERSION" NAHUALI_REQUIRE_SIGSTORE=1 \
  sh /tmp/nahuali-install.sh

この方法ではcosignが必要です。アーカイブのチェックサム、署名ID、 またはバンドルを検証できない場合は処理を停止します。正確なID、来歴、 SBOM、および手動検証の手順については、 リリースの検証を参照してください。

更新通知

新しいリリースがご利用のプラットフォーム向けに存在する場合、 nahuali briefingとnahuali session-resumeの人間向け出力の末尾に 次の1行が表示されます。

Update available: X.Y.Z-beta.N (you have X.Y.Z-beta.M) · https://github.com/Arakiss/nahuali/releases/tag/vX.Y.Z-beta.N

Nahuali が独自に行うネットワーク呼び出しはこれだけです。24時間に最大1回、 1.5秒のタイムアウトで匿名のGET https://api.github.com/repos/Arakiss/nahuali/releases を実行します。メモリの内容、ストアのパス、識別子は送信しません。 GitHub の要件に従い、User-Agentヘッダーには Nahuali のバージョンのみが 含まれます。失敗した場合も含め、結果は$NAHUALI_HOME/update-check.json （デフォルトは~/.nahuali）にキャッシュされます。この通知は--json出力、 その他のコマンド、MCP、HTTP API には表示されず、Nahuali が独自に何かを インストールすることもありません。nahuali update-checkはすぐに確認を行い、 バージョンが固定されたインストーラーコマンドを出力します。

NAHUALI_NO_UPDATE_CHECK=1を設定すると、update-checkを含むすべての更新確認が 無効になります。CIが設定されている場合も、自動確認はスキップされます。

ソースからビルドする

cargo build --workspace
cargo test --workspace
cargo install --path crates/nahuali-cli --locked

Docker が必要なのは、オプションのリモート開発スタックと Qdrant を使用する場合のみです。

さらに詳しく

• 信頼モデル
• 検証済みの法則（Kani による証明とプロパティテスト）
• リリースの検証
• 自己修復の契約
• ガバナンスのベンチマーク
• セキュリティポリシー
• コントリビューション

質問や設計に関するフィードバックは、 GitHub Discussionsにお寄せください。バグ報告や ベンチマークへの貢献には、専用の Issue テンプレートをご利用ください。

ライセンス

Nahuali は、FSL-1.1-MIT（MIT への将来の移行条項を含む Functional Source License 1.1）の下でソースコードを公開しています。許可された目的であれば、閲覧、使用、複製、変更、セルフホスト、再配布が可能です。現行コードを競合する商用製品またはサービスとして提供することは制限されています。公開された各バージョンは、2 年後に MIT ライセンスに移行します。このライセンスは、製品のアイデアを独立して再実装することを妨げるものではありません。実務に即したライセンスに関する FAQをお読みください。ライセンス本文が法的拘束力を持つ情報源です。