AI に任せた作業のつまずきと決まり ― pgrep -f の空回り、sudo へのパスワードの渡し方、SMB で見えないリンク
家のサーバーやネットワークの作業を、AI（Claude Code）に任せています。1日でたくさんの作業が進む一方で、同じ種類のつまずきが何度か出ました。今日の分から3つを取り上げ、共通のルール（AI が最初に読むファイル）に決まりとして書いたものを紹介します。
1. pgrep -f で「終わるのを待つ」と空回りする
時間のかかる処理を裏で流し、「まだ動いているか」を pgrep -f "処理の名前" で確かめながら待つ、というやり方をしていました。ところが pgrep -f は、コマンドの文字列全体から探すので、確かめている自分のコマンド（SSH で送るコマンドを含む）にも一致します。処理が終わっているのに「動いている」と見えて、待ち時間の上限まで空回りしました。前の日と今日で、別々のチャットが合わせて40分ほど空回りしています。前の日には、pkill -f で自分の SSH のコマンドごと切ってしまったこともありました。
- 決まり：
pgrep -f・pkill -fを使わない。前面で実行して終わるのを待つ、起動したときの PID で確かめる（kill -0 PID）、終わったときに記録のファイルを残してそれを見る、のどれかにする。長く待つときは上限を付ける
2. sudo へのパスワードの渡し方
sudo のパスワードを画面に出さずに渡すため、sudo -S（パスワードを標準入力から読む）を使っています。そこで sudo -S mysql < ファイル.sql と書いたところ、sudo が SQL のファイルの中身をパスワードとして読み、3回失敗しました。別の機会には、パスワードの行を、スクリプトの1行目として実行させてしまったこともあります。
# よい形：1行目でパスワードを渡して sudo の許可だけ取り、残りは -n で
read -r p; printf "%s\n" "$p" | sudo -S -p "" -v || exit 1
sudo -n mysql < ファイル.sql- 決まり：パスワードは入力からだけ渡し、コマンドの本体はコマンドの引数として渡す。リダイレクト（
<）とsudo -Sを同じ行で使わない - 今回は締め出し（失敗が続いたアカウントのロック）は起きず、大事にはならなかった
3. SMB ではリンクが普通のフォルダーに見える
NAS の中にあった @Recycle というフォルダーを、Mac から SMB でつないで消そうとしました。ところが、これは NAS のごみ箱の中の別の場所へのリンクで、SMB からは普通のフォルダーに見えていました。そのため、削除の処理がリンクの先まで入り込み、ごみ箱に入っていた古いバックアップの部品を消してしまいました（もともと削除済みのもので、今のバックアップには影響なし）。
- 決まり：NAS の中のものを消すときは、NAS 自身の画面（File Station など）から消す。どうしても外から消すときは、NFS など、リンクがリンクとして見える方法で中身を確かめてから
- 実際、このあと別のフォルダーの中にも同じリンクがあったので、そちらは NAS の画面から消してもらった
4. 決まりを AI に届ける
共通のルールは、Vault（Obsidian のノート）の AGENTS.md に書き、各端末の AI が最初に読みます。AI 用の仮想マシン（vm1）には、mac3 が変更を見つけて送る仕組みです。この日は、mac3 が止まっていた間に、vm1 の写しが古いままになっていたので、手で写しました。決まりを書いても、届いていなければ意味がない、というのも今回の学びです。