Claude Code に TrueNAS を操作させる — RAIDZ検証を自動化するために変更した設定まとめ

前回の記事「TrueNAS で RAIDZ1 vs RAIDZ2 を実測比較」では、3構成×(通常時fio・SMB・縮退・resilver)という長丁場の測定を1日で完走しました。実はこの検証、測定の実行・監視・集計はほぼすべて Claude Code(AIコーディングエージェント)が自動で行っています。

本記事はその舞台裏として、「どんな環境を前提に」「何の設定を変更して」AIエージェントがNASを操作できる状態を作ったのかをまとめます。同じことをやってみたい方の参考になれば幸いです。

前提の環境
全体設計: どこまでAIに任せ、どこを人間がやるか
設定変更1: SSH鍵認証の整備(操作元 Debian 側)
1. ハマりどころ①: TrueNAS に ssh-copy-id は通用しない
2. ハマりどころ②: どのユーザーに鍵を登録するか
設定変更2: passwordless sudo の有効化(TrueNAS 側)
設定変更3: Claude Code 側の許可ルール
1. ここでの学び
自動化を支えた運用ノウハウ(設定以外)
後片付け(検証終了後の状態)
まとめ

前提の環境

役割	マシン	備考
操作元	Debian 13(Claude Code 稼働)	ここからSSHでNASを遠隔操作
検証対象	TrueNAS SCALE 25.10	ASUS P9D-I / Xeon E3-1226 v3 / 16GB RAM
測定クライアント	Windows 11(CrystalDiskMark)	SMB測定用。ここだけ人間が手動操作
ネットワーク	同一LAN(1GbE)	—

検証開始時点では、操作元からNASへのSSH接続手段は何もない状態(鍵ペアなし、パスワード認証のみ)でした。ここからのスタートです。

全体設計: どこまでAIに任せ、どこを人間がやるか

先に役割分担の結論を示します。設定変更の意図はすべてこの分担に基づいています。

作業	担当
環境調査・プール/データセット作成・測定実行・監視・結果集計	Claude Code(自動)
Web UI操作・パスワード入力	人間
破壊的コマンド(プール破棄・ディスク署名消去など)	人間(AIがコマンドを提示→人間が確認して実行)

破壊的操作を人間に残したのは設計というより、Claude Code の安全機構(危険なコマンドを自動実行前にブロックする仕組み)がそう仕向けた結果ですが、ディスクを消す操作の直前に必ず人間の目が入るこの分担は、結果的に理にかなっていました。

設定変更1: SSH鍵認証の整備(操作元 Debian 側)

自動化の大前提は「パスワード入力なしでSSHできること」です。対話的なパスワード入力はAIエージェントには代行できません。

# 鍵ペア作成(パスフレーズなし)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N "" -C "user@debian13"

~/.ssh/config に接続エイリアスを定義:

Host nas
    HostName <NASのIPアドレス>
    User truenas_admin
    IdentityFile ~/.ssh/id_ed25519

以後、Claude Code は ssh -o BatchMode=yes nas '<コマンド>' の形で操作します。BatchMode=yes は「対話的認証を禁止し、鍵認証が効かなければ即失敗する」オプションで、エージェントが認証プロンプトで永久に待ち続ける事故を防ぐため必須です。

ハマりどころ①: TrueNAS に ssh-copy-id は通用しない

最初に一般ユーザー宛てに ssh-copy-id を実行したところ、失敗しました。

Could not chdir to home directory /mnt/... : Permission denied
mkdir: cannot create directory '.ssh': Read-only file system

原因は2つ。そのユーザーのホームディレクトリがSMB共有用データセット(Windows ACL管理で書き込み不可)を指していたこと、そして TrueNAS SCALE はルートファイルシステムが読み取り専用であることです。

TrueNASでは公開鍵を ssh-copy-id で送り込むのではなく、Web UI のユーザー編集画面にある「Authorized Keys」欄へ貼り付けるのが正道です。middleware が適切な場所・パーミッションで配置してくれます。

ハマりどころ②: どのユーザーに鍵を登録するか

検証ではデータプールを何度も破棄・再作成します。一般ユーザーのホームをデータプール上に作ると、プール破棄のたびにホームごと消えて鍵認証も壊れます。

そこで鍵の登録先は truenas_admin(インストール時に作られる管理ユーザー) にしました。ホームがブートプール上(/home/truenas_admin)にあるため、データプールをどれだけ作り直してもSSH接続が影響を受けません。この選択は検証を通じて大正解でした。

設定変更2: passwordless sudo の有効化(TrueNAS 側)

zpool / midclt(TrueNAS middleware CLI)/ fio などはroot権限が必要ですが、truenas_admin の sudo は既定でパスワードを要求します。これでは自動実行できません。

Web UI から:

Credentials → Users → truenas_admin → Edit → 「Allow all sudo commands with no password」を有効化

これで Claude Code は ssh nas 'sudo -n <コマンド>' でroot操作が可能になります(-n は「パスワードが要求されたら即失敗」の意味で、これもハング防止)。

この設定は明確にセキュリティを弱めるので、検証期間限定と割り切り、終了後すぐ無効に戻しました。

設定変更3: Claude Code 側の許可ルール

Claude Code は実行するコマンドごとにユーザーの許可を求めます(設定による)。定型のSSHコマンドを毎回確認するのは非効率なので、プロジェクトローカル設定 ~/.claude/settings.local.json に許可ルールを追加しました:

{
  "permissions": {
    "allow": [
      "Bash(ssh nas *)",
      "Bash(ssh -o BatchMode=yes nas *)"
    ]
  }
}

ここでの学び

許可ルールはセッション開始時に読み込まれるため、追加しても実行中のセッションには反映されません(新しいセッションから有効)
ルールがあっても、破壊的コマンド(プール破棄・wipefs・システム設定変更)は安全機構が別途ブロックすることがあります。今回は「AIがコマンド文字列を提示→人間がターミナルで実行→AIが結果を確認して続行」という運用で乗り切りました。データ全消去を伴う検証において、この”強制的な人間の関所”はむしろ安心材料です
このルールも検証終了後に削除しました

自動化を支えた運用ノウハウ(設定以外)

設定変更ではありませんが、TrueNAS を SSH 越しに自動運用する際の躓きポイントを3つ:

長時間ジョブは nohup ではなく systemd-run で起動する — TrueNAS 25.10 では nohup によるバックグラウンド起動が「Function not implemented」で失敗しました。sudo systemd-run --unit=bench --collect bash /tmp/script.sh なら確実で、SSH切断にも耐えます
プール操作は midclt(middleware 経由)で行う — 生の zpool コマンドだけで完結させると、Web UI との整合(共有設定・システムデータセット等)が壊れます。ジョブ系APIはジョブIDを受けて core.get_jobs でポーリング
zpool import には -R /mnt が必須 — TrueNAS のプールは altroot 前提のため、素の import ではマウントに失敗します

後片付け(検証終了後の状態)

項目	検証後の対応
passwordless sudo	無効化(Web UI で元に戻す)
Claude Code 許可ルール	削除
SSH鍵ペア+configエイリアス	残置(今後の管理用に再利用)
truenas_admin の Authorized Keys	残置(鍵認証SSHは引き続き可能)

「自動化のために一時的に緩めた権限は、作業が終わったら戻す」——地味ですが、これをセットでやって初めて安全な自動化と言えると思います。

まとめ

AIエージェントにNASを操作させるための設定変更は、突き詰めれば次の3点でした。

パスワードレスなSSH経路(鍵認証+BatchMode。鍵の登録先はプール再作成に影響されないユーザーを選ぶ)
パスワードレスなroot昇格(sudo NOPASSWD。期間限定で付与し、終わったら戻す)
エージェント側の許可ルール(定型コマンドのみ許可。破壊的操作は人間の関所を残す)

そして運用面では「ハング防止(BatchMode / sudo -n)」と「人間による破壊操作の確認」の2つが、無人で回し続けるための鍵でした。測定そのものの結果は前回記事をどうぞ。

検証は2026年7月、TrueNAS SCALE 25.10 / Debian 13 / Claude Code の組み合わせで実施しました。

Claude Code でRAIDZ検証を(一部)自動化