はじめに#

きっかけは「シェル芸人こそ最強なのでは？」という、わりとどうでもいい思いつきだった。

AIコーディングツールを触っていると、結局あれこれ調べる速度がそのまま作業の速度になる。ログを掘る、設定値を探す、ビルドが終わったか確認する。この手の作業を一番速くこなせるのは、いつの時代もシェル芸が達者な人だ。ならばClaude Codeはどうなのか。あれだけBashを叩いているのだから、そのシェル芸から学べる部分があるのではないか。

そう思って「Claude Codeが多用するシェル芸を調べて」と投げた。返ってくるのはgrepとsedの一般的な解説だろうと予想していた。

ところが実際に始まったのは、ローカルの~/.claude/projects/配下に溜まっていたトランスクリプトを全部パースして、過去に実行されたBashコマンドを数え上げる作業だった。つまり「一般にAIはこう書くらしい」ではなく、「この環境で実際に13,564回叩かれたコマンドはこうだった」というデータが出てきた。

これが想像以上に面白かったので、記事にしておく。

集計の前提#

先に素性を出しておく^1。

抽出方法は単純で、各JSONL行のmessage.content[].type == "tool_use"かつname == "Bash"からinput.commandを取り出しているだけ。パースエラーは0件だった。

ひとつ先に断っておくと、この数字には筆者の環境バイアスが強く乗っている。あとで注意点としてまとめるが、adbが2,568回も出てくるのはAndroid開発をしていたからで、一般的なClaude Code利用でこうはならない。一方で、構文的な傾向（詰め込み方・出力の絞り方・待ち方）のほうはタスク領域にほぼ依存しないはずなので、そちらを主に見ていく。

全体像：1コールに調査シーケンスを詰め込む#

まず驚いたのが、構文の分布だった。

結合演算子が0個、つまり本当に単発のコマンドはわずか6.9%しかない。逆に10個以上詰め込んでいるケースが11.4%ある。

人間がターミナルで作業するときは、lsして、cdして、catして、と対話的に1つずつ叩く。画面を見て次を決められるからそれで困らない。しかしエージェントは1回のツール呼び出しごとに往復のレイテンシとトークンを払うので、「見てから決める」を減らして「まとめて投げて結果から推測する」ほうが合理的になる。その圧力が、この63.5%と60.0%という数字に出ている。

もうひとつ象徴的なのが、バックグラウンド化（&）がゼロだったこと。これはClaude Codeがシェルの&ではなく、Bashツール側のrun_in_backgroundパラメータを使う設計だからだ。シェルでできることを、あえてシェルの外の仕組みに寄せているわけで、ここは人間の作法と明確に分岐している。

原則1：出力量を必ず自衛する#

エージェントにとって、コマンドの出力はそのままコンテキストを食う。ここに一番強い最適化圧力がかかっていて、上位のイディオムはほぼ全部これに関係していた。

1
# 探索：候補を広く見たいので20〜40行
2
grep -rn "def train" --include='*.py' . | head -40
3

4
# 確認：終わったかどうかだけ知りたいので3行
5
tail -3 run.log

1
sed -n '185,196p' docs/SPEC.md
2
sed -n '990,1110p' "$SP/base.py"

1
# 1段目：位置を特定する
2
grep -n "class Trainer" model.py
3
# → 342:class Trainer:
4

5
# 2段目：その周辺だけを読む
6
sed -n '342,420p' model.py

1
echo "=== ファイル構成 ==="; find exp -type f | head -20
2
echo "=== 設定値 ===";      grep -n "LEARNING_RATE\|BATCH" config.py
3
echo "=== 直近ログ ===";    tail -20 run.log

1
# 実行系：失敗の理由が知りたいのでstderrを混ぜてから絞る
2
npm run build 2>&1 | grep -iE "error|warn" | head -25
3

4
# 探索系：存在しないパスのPermission deniedはノイズなので捨てる
5
find / -name "libcuda*" 2>/dev/null | head

1
# 定番：ps aux から grep 自身を除く
2
ps aux | grep -E "sweep_spatial" | grep -v grep | awk '{print $2, $9, $11}'
3

4
# 拾いすぎた語をsecond-passで削る
5
grep -iE 'error|fail' app.log | grep -viE 'errors=|error_bad|failsafe' | head -10

原則2：ブロックせずポーリングする#

ここが一番の目玉。「ログが出てくるのを待つ」という動作について、人間とはっきり違う設計思想が出ていた。

13,564件のうちtail -fはたったの3件。 人間なら真っ先にtail -fする場面で、エージェントはほぼ使っていない。

理由は明確で、tail -fは終わらないのでタイムアウトするまでツールをブロックする。しかもその間、流れてくる出力を逐次判断できない。エージェントにとっては「結果を返さないまま時間だけ溶ける」最悪の選択肢になる。

1
LOG="/private/tmp/.../scratchpad/task039_full_ab.log"
2
until grep -q "VERIFY039_DONE" "$LOG" 2>/dev/null; do sleep 60; done
3
echo "=== RUN COMPLETE ==="
4
grep -E "score|elapsed" "$LOG" | tail -20

1
until grep -q "VERIFY041_DONE\|Traceback" "$LOG" 2>/dev/null; do sleep 120; done

1
f="$SCRATCH/build.output"
2
until grep -qE "BUILD FAILED|FAILURE: |Error: |CommandError|Starting: Intent|Opening on " "$f" 2>/dev/null; do
3
  sleep 10
4
done
5
grep -nE "BUILD SUCCESSFUL|FAILURE" "$f" | tail -5

1
until grep -qE "EXIT=" /tmp/submit_push.log 2>/dev/null; do sleep 20; done
2
tail -8 /tmp/submit_push.log

1
# プロセスが消えるまで待つ
2
until ! pgrep -f "arena.py /tmp/ab_land" >/dev/null; do sleep 20; done; echo DONE
3

4
# 複数条件
5
until ! pgrep -f "harv_sweep" >/dev/null && ! pgrep -f "land_sweep2" >/dev/null; do sleep 20; done

1
while kill -0 $PID 2>/dev/null; do sleep 20; done
2
while [ ! -f "$SCRATCH/wait.txt" ]; do sleep 2; done; echo finished

1
i=0
2
until [ $i -ge 110 ]; do
3
  S=$(kaggle kernels status user/my-kernel 2>&1 | tail -1)
4
  echo "[$(date -u +%H:%M:%S)] $S"
5
  case "$S" in *COMPLETE*|*ERROR*|*CANCEL*) break ;; esac
6
  i=$((i+1)); sleep 30
7
done

原則3：シェルの限界を越えたらPythonに落とす#

これも数字がはっきり出ていた。

• python3 - <<'PY' 形式のヒアドキュメント：717コール（5.3%）
• python3 -c ワンライナー：1,432コール（10.6%）
• awk：246回
• sort：298回 / uniq：68回
• xargs：47回
• jq：全13,564コール中1回

シェル芸人的にはjqが1回というのが衝撃だと思う。JSONを触る場面はいくらでもあったはずなのに、ほぼ全部Python側で処理している。

1
python3 - <<'PY'
2
import json
3
nb = json.load(open('notebooks/exp005.ipynb'))
4
print(''.join(nb['cells'][3]['source']))
5
PY

判断基準は「シェル芸で頑張れる境界を越えたら、迷わずPythonに切り替える」に集約される。JSON操作、正規表現による構造的置換、複数ファイルにまたがる集計は、ほぼ全部Pythonだった。

awkが246回、xargsが47回と少ないのも同じ話で、シェル芸の中級テクを駆使するくらいならPythonを書いたほうが確実という判断が働いている。

ここは正直、シェル芸人としての矜持みたいなものを問われる部分だと思う。ただエージェントは「読みやすさ」ではなく「一発で正しく動く確率」で選んでいるので、この割り切りには合理性がある。人間も、jqのクエリを3回書き直すくらいなら最初からPythonにしたほうが速い場面は多い。

原則4：防御的に書く#

エージェントは失敗したらリトライされることが前提なので、書き方が全体的に防御的だった。

1
cd "/Users/new/.../kaggle_experiments/arc-prize-2026" && grep -n "spatial" exp/exp004/dp_core.py | head -60

1
SP="/private/tmp/claude-501/-Users-new-.../scratchpad/src"
2
grep -n "def solve" -A 25 "$SP/ls20.py"
3
sed -n '1,40p' "$SP/util.py"

1
# 「無い」ことも情報として出力する
2
adb shell which sqlite3 2>/dev/null || echo "no sqlite3"
3

4
# 真偽を人間可読な文字列に変換する
5
pgrep -f "train.py" >/dev/null && echo "[実行中]" || echo "[終了]"
6

7
grep -rn "old_api" --include='*.md' . || echo "  なし ✅"

1
cat > "$D/astar_sc25.py" <<'EOF'
2
"""sc25 L0: A* with patched dedup hash."""
3
from __future__ import annotations
4
import heapq, sys, time
5
EOF

検索の芸：候補をまとめて投げる#

grepのオプション使用頻度も出しておく。

-Eが多いのは、当たりそうな語を一度に全部投げるからだった。

1
grep -n "gs\b\|GR\|nan\|isfinite\|interp\|fillna" exp/exp004/dp_core.py | head -60
2
grep -iE "payload|contract|error|traceback|candidate|written|rows" run.log | head -40

1語ずつ試すと、外すたびにツール呼び出しが1往復増える。だから10語まとめて投げてheadで切るほうが効率がいい。人間のシェル芸との差がはっきり出る部分で、人間は「まずerrorで引いてみて、ダメならfailで」と1つずつ試す。

これは真似する価値があると思っている。ターミナルで1語ずつ試している時間より、思いつく限り並べて一発で投げたほうが速い場面は普通にある。

-oで構造抽出する使い方も見られた。jqが使えない相手に対する擬似パーサになっている。

1
kaggle kernels status user/k 2>&1 | grep -oE 'KernelWorkerStatus\.[A-Z]+'
2
grep -o 'resource-id="[^"]*"[^>]*bounds="[^"]*"' ui.xml | tail -40

なおfindは597回あるが、-execやxargsとの組み合わせは43回だけ。ほとんどがツリー構造の把握に使われていて、-not -path '*__pycache__*'のようなノイズ除去や-maxdepth 2での深さ制限がよく付いていた。ここでも出力量の自衛が効いている。

人間のシェル芸との差分#

まとめると、こういう対比になる。

そして最終的に、実データから読み取れる原則は5つに集約された。

で、人間は何を盗めるのか#

最初の問い（シェル芸人こそ最強では？）に戻る。集計を眺めた結論としては、エージェントのシェル芸は人間より上手いわけではないが、制約が違うぶん違う最適解に着地しているという感じだった。

そのうえで、人間がそのまま盗めると思ったのは次の4つ。

1. headは20行、tailは3行と決めておく

探索と確認で見る行数を分ける、というだけの話だが、意識するとログ掘りが明確に速くなる。「とりあえず全部出して目で追う」が一番遅い。

2. grepは候補をまとめて投げる

grep -E "error|fail|traceback|exception"と最初から並べる。1語ずつ試して外す時間のほうが、正規表現を組む時間より長い。

3. 完了待ちはuntil grep -qにする

tail -fで画面を眺めている時間は、実は何もしていない時間である。マーカーを決めてuntilで待てば、その間ほかのことができる。成功マーカーと失敗マーカーの両方を待つのを忘れないこと。ここを忘れると、ジョブが死んだのに待ち続けることになる。

1
until grep -qE "DONE|Traceback|FAILED" build.log 2>/dev/null; do sleep 30; done
2
tail -20 build.log

4. jqで粘らずPythonに逃げる

これは人によって好みが分かれると思うが、jqのクエリを3回書き直した時点でPythonに切り替えたほうが速い、というのは経験的にも正しい。

逆に、真似しなくていいものもある。echo "==="のセパレータ注入は、対話的に叩く人間には不要だ。毎回cdし直すのも、シェルの状態が保持される人間の環境では冗長でしかない。これらはエージェント固有の制約から出てきた作法であって、良い書き方だから採用されているわけではない。

注意点：この数字をどこまで信じるか#

最後に、集計の限界も書いておく。数字だけ一人歩きすると困るので。

環境バイアスが強い。 コマンド頻度トップの中にはadb（2,568回、Android開発）、kaggle（1,266回）、backlog（1,127回、タスク管理ツール）が入っている。これは筆者の環境固有で、Web開発中心の環境ならnpmやdockerやcurlの比率がもっと高くなるはず。「コマンド頻度」は汎用的な代表値ではない。

長時間バッチが多い環境である点も効いている。 untilポーリングの2.65%という比率は、機械学習ジョブやモバイルビルドを頻繁に回すこの環境ゆえにやや高めの可能性がある。ただし、tail -fを使わないという事実自体は比率と無関係に成立する。

集計方法の粗さもある。 コマンド頻度はセグメント先頭トークンの単純集計なので、ヒアドキュメント本文の行（defが486、constが98など）が混入している。主要コマンドの相対順位には影響しないが、絶対数は数%の過大側になっている。>の2,829件も>/dev/nullを含むため、「ファイル書き込み」より広い集合を数えている。傾向（全置換優位）は確実だが、絶対数はやや盛られていると見たほうがいい。

時系列は追っていない。 全期間を一括集計しているので、Claude Codeのバージョン更新に伴う作法の変化はこのデータからは読み取れない。

そのうえで、汎用的に妥当なのは構文的特徴（詰め込み度・出力抑制・ポーリング作法・Pythonへの委譲）のほうだと考えている。これらはタスク領域ではなく「エージェントであること」から導かれる制約なので、他の環境でも再現するはずである。

まとめ#

• 実トランスクリプト607ファイル・Bash呼び出し13,564件を全件集計した。一般論ではなく実データ
• 単発コマンドはわずか6.9%。&&とパイプで調査シーケンスを1コールに詰め込むのが基本形
• tail -fは3件（0.02%）しかない。until grep -q ...; do sleep ...; doneでポーリングし、失敗マーカーも一緒に待つ
• headは探索用で20の倍数、tailは確認用で1〜3行。役割が完全に分かれている
• sedは-nの範囲プリントが1,125回に対し-iは54回。エディタではなくページャとして使われている
• echo "==="が25.7%。自分が後で読むための見出しを出力に埋め込むエージェント固有の作法
• jqは全体で1回。シェルの限界を越えたら迷わずPythonに落としている
• ただしコマンド頻度は環境依存が強い。構造的な傾向のほうを見るべき

「シェル芸人こそ最強なのでは？」という当初の問いに答えるなら、最強なのはシェル芸そのものではなく、制約を理解したうえでコマンドを選べることだった。エージェントは「出力はコンテキストを食う」「ブロックすると何も返せない」「リトライされる前提」という制約から逆算して、人間とは違う作法に着地している。

そう考えると、人間側の制約（目で追える、対話的に叩ける、状態が保持される）も、意識してみる価値がある。そこを疑うと、tail -fで画面を眺めている時間が本当に必要だったのか、みたいなところから見直せる。少なくとも筆者は、あの日以来until grep -qをよく書くようになった。

参考文献#

1. 解析対象データ：ローカルのClaude Codeトランスクリプト ~/.claude/projects/**/*.jsonl（607ファイル、Bashツール呼び出し13,564件、2026-08-04時点の集計）
2. Claude Code 公式ドキュメント https://docs.claude.com/en/docs/claude-code/overview
3. GNU Grep マニュアル https://www.gnu.org/software/grep/manual/grep.html
4. GNU Sed マニュアル https://www.gnu.org/software/sed/manual/sed.html
5. Bash Reference Manual — Here Documents https://www.gnu.org/software/bash/manual/bash.html#Here-Documents