1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

4.6万starのnanobotで、初回onboardのメモリ初期化が黙って壊れていた

1
Posted at

はじめに

pip install してコマンドを1つ叩くだけで動くと紹介されるCLIツールは多い。だが、その1コマンドの内部でGit操作が走っている場合、ホスト側のGit設定によっては結果が変わりうる。特に近年はサプライチェーン対策としてコミット署名を強制する環境が増えており、そうした環境でPython製の軽量Git実装（dulwich）を使うツールを動かすと、何が起こるのか。

OSSのAIエージェントランタイム「nanobot」（HKUDS/nanobot）の初期化コマンドをコミット署名必須の環境で実行したところ、コマンド自体は成功メッセージを返す一方で、裏側のメモリ用Gitリポジトリの初期化だけが例外を出して失敗していた。

TL;DR

  • nanobotは onboard 実行時にPython製Git実装dulwichでメモリ用リポジトリを初期化し、初回コミットを作成する
  • ホスト側のGit設定で commit.gpgsign=true かつ gpg.format=ssh（SSHコミット署名)が有効で、かつ ssh-keygen コマンドが存在しない環境では、この初回コミットが ssh-keygen command not available for SSH signatures で失敗する
  • onboard コマンド自体は例外を握りつぶして「準備完了」と表示するため、失敗に気づきにくい
  • GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null を付けて実行すれば回避できることを確認した

nanobotについて

nanobot は HKUDS（香港大学のData Intelligence Lab）が公開しているセルフホスト型の個人用AIエージェントランタイムである1。WebUI・API・Telegram・Slack・Discord・Feishuなど複数のチャットチャネルから同じエージェントに接続でき、ファイル操作・シェル・Web検索・MCP・画像生成をツールとして呼び出せる。会話履歴やゴールをまたいで状態を保持する「持続的メモリ」を売りにしており、その永続化にGitリポジトリを使っている点が今回の検証対象になる。

2026年7月22日時点でGitHubスター数は4.6万を超え、最新リリースはv0.2.2（2026年6月23日公開）である2。インストール方法は公式にワンライナー、uv tool install nanobot-ai、pip install nanobot-ai の3通りが案内されている1。

クラウド実行環境でのインストールと初期化

Python 3.11の仮想環境を作成し、pip install nanobot-ai を実行したところ、依存関係を含めて正常にインストールが完了した（nanobot-ai==0.2.2・dulwich==0.25.2 が入る）。

python3 -m venv /tmp/nanobot-venv
source /tmp/nanobot-venv/bin/activate
pip install nanobot-ai
nanobot --version
# 🐈 nanobot v0.2.2

続けて初期化コマンドを実行する。

nanobot onboard

出力の末尾だけを見ると成功したように見える。

🐈 nanobot is ready!

Next steps:
  1. Add your API key to /root/.nanobot/config.json
     Get one at: https://openrouter.ai/keys
  2. Chat: nanobot agent -m "Hello!" --config /root/.nanobot/config.json

メモリ用リポジトリの初期化が静かに失敗する

問題は、この成功メッセージの直前に大量のPythonトレースバックが出力されていた点にある。抜粋すると以下の内容だった。

2026-07-22 17:45:19 | ERROR | - | Git store init failed for /root/.nanobot/workspace
...
  File ".../dulwich/signature.py", line 1365, in get_signature_vendor
    raise ValueError("ssh-keygen command not available for SSH signatures")

ValueError: ssh-keygen command not available for SSH signatures

onboard コマンドはこの例外を捕捉した上で処理を継続し、最終的に終了コード0で「準備完了」と表示する。実際に初期化後のワークスペースを確認すると、.git ディレクトリ自体は作成されているが初回コミットは存在しなかった。

cd /root/.nanobot/workspace && git log --oneline
# fatal: your current branch 'master' does not have any commits yet

nanobotの永続メモリは「会話履歴・ゴール・スキルの変更をGit管理下に置くことで長期的な状態保持を実現する」という設計であるため、初回コミットが存在しない状態はこの機能の起点が欠けたまま運用を始めることを意味する。

原因の切り分け

トレースバックを遡ると、直接の原因は dulwich.porcelain.commit() がリポジトリのGit設定を読み、gpg.format=ssh かつ commit.gpgsign=true の場合にSSH署名用の ssh-keygen コマンドを呼び出そうとする箇所にある。今回の実行環境ではこのバイナリが存在しないため、署名ベンダーの取得処理そのものが例外を送出する。

この設定自体はnanobotが持ち込んだものではない。実際、nanobotのGitストア実装（gitstore.py）を検索しても署名関連の設定は一切見当たらず、dulwichが素直にホスト側のグローバルGit設定（~/.gitconfig）を継承しているだけだった。今回の実行環境は、リポジトリへのコミット署名を強制する gpgsign=true・gpg.format=ssh が設定済みで、SSH署名用の鍵生成コマンド ssh-keygen はインストールされていない構成である。この2つが揃うと、dulwichを使う内部Git操作は署名検証の手前で必ず失敗する。

まとめると、根本的な原因は「コミット署名を強制するホスト環境」と「ホストのGit設定をそのまま継承するdulwich」という組み合わせであり、ssh-keygen 不在は直接のトリガーに過ぎない。コミット署名の強制はサプライチェーンセキュリティの観点で採用が広がっている設定であり、devcontainerやCIランナーでも同様の構成は珍しくない。

回避策

nanobot側にこの状況を検知して署名をスキップするオプションは見当たらなかったため、実行時に環境変数でGit設定の継承を切る方法を検証した。

rm -rf ~/.nanobot
GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null nanobot onboard

この場合、ログは以下のように変わり、エラーは出なくなる。

2026-07-22 17:45:46 | INFO  | - | Git store initialized at /root/.nanobot/workspace

🐈 nanobot is ready!

ワークスペースを確認すると、初回コミットが実際に作成されていた。

cd /root/.nanobot/workspace && git log --oneline
# 20def87 init: nanobot memory store

GIT_CONFIG_GLOBAL と GIT_CONFIG_SYSTEM はGitが標準でサポートする環境変数で、それぞれグローバル設定・システム設定として読み込むファイルを上書きする。/dev/null を指定することで、ホストのグローバル設定（署名強制を含む）を無視した状態でdulwichの内部コミットだけを成功させられる。ユーザー自身の他のGit操作（このリポジトリへのコミット等）には影響しないため、nanobot onboard の実行時だけ環境変数を付ける運用で足りる。

実務上の含意

この事象は、コミット署名を必須にしたコンテナ環境・CI環境全般で起こりうる。Pythonの軽量Git実装（dulwich・GitPythonなど）を内部で使い、ホストのGit設定を継承するツールは他にも存在するため、onboard・init 系のコマンドがエラーなしで完了しても、内部でGit操作を伴う機能（履歴・スナップショット・自動コミット）が実際に動いているかは別途確認したほうがよい。今回のケースでは git log でコミットの有無を見るだけで判別できたが、ログの末尾だけを見ていると「ready」の表示に惑わされて見落としやすい。

著者視点の発見ポイント

実際に検証したところ、最も見落としやすかったのは「コマンドの終了コードとログの最終行が両方成功を示していても、内部の副作用が達成されていない場合がある」という点だった。今回は git log で初回コミットの有無を確認するという一手間で発覚したが、CLIツールの動作確認を終了コードやサマリー表示だけで済ませてしまうと、このような部分的な初期化失敗は把握できない。

まとめ

  • nanobotの onboard はメモリ用Gitリポジトリを初期化するが、コミット署名を強制しつつ ssh-keygen を持たない環境では初回コミットに失敗する
  • 失敗してもコマンドは成功として終了するため、git log 等で実際の状態を確認する必要がある
  • GIT_CONFIG_GLOBAL=/dev/null GIT_CONFIG_SYSTEM=/dev/null を付けて onboard を実行することで回避できる
  • 同種の問題は、ホストのGit設定を継承するPython製Git実装を使う他のツールでも起こりうる

参考リンク

  1. HKUDS/nanobot README （2026年7月時点） ↩ ↩2

  2. GitHubリポジトリページのスター数・リリース情報（2026年7月22日確認） ↩

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?