前の記事で、Claude Code の usage は基礎コンテキストより往復（API 応答）の数が効くと分かりました。往復を減らす一番大きな手は「前の結果を必要としない道具の呼び出しは、同じ応答に並べる」ことです。私はこれを 1 か月前から設定ファイルと記憶に書いていました。
数えたら、61 回すべて単独でした。この記事の中心は「何をまとめて、何を分けるか」の 2 問判定です。数え方と、その後どう変わり、何を変わったと言わないかも記録します。
この記事の位置づけ（2026-09-26 追記）
- この記事で新しく示すこと: 転写の同じ message.id を束ねれば「1 応答に道具が何個」を数えられること。書いた規律が起点では 0/61 だったこと。
- 当てはまる範囲: 当方 1 人の Claude Code の転写。起点は定型作業 1 件で、1 か月の全体は数えていません。
- 言葉: 本文の「器」＝点検や処理のための自作スクリプトのことです。
先に結論
- 転写は道具の呼び出し（tool_use）を 1 行 1 個で書くが、同じ API 応答の行は同じ
message.idを持つ。id で束ねれば「1 応答に何個並べたか」は復元できる。 - 起点（定型の事務作業 1 件）は全応答 62・道具を含む応答 61・道具 61・複数を並べた応答 0。規律が文書に在っても行動は 0 だった。
- 同じセッションの中で、明示的な試験と議論のあと、その作業を直接指示していない通常作業で、区間ごとに 0%→50%→17%。最後の区間の単独応答は全部「前の結果に依存」で、独立なのに単独＝0 件。
- 率は目標にしない。率を上げようとすると、依存する処理まで束ねる誘因が生まれる。減らしたいのは「独立なのに単独で出した不要往復」だけ。
- セッションを跨いで持続するかは未確認。同じセッション内で自発化した、までしか言えない。
束ねるか、分けるか——2 問判定
Q1: 次の呼び出しの内容は、前の結果で変わるか？ YES → 分ける／NO → Q2
Q2: 同じ状態（同じファイル・同じ台帳）を書き換えて、順序が競合するか？ YES → 分ける／NO → 同じ応答に並べる候補
並べる例: 独立な 3 ファイルの書き込み／記帳と次の材料の読み／一覧を取る一括操作と台帳の読み。
分ける例: タブの ID を取ってから使う操作／失敗の原因を読んでから直す／zip を作ってから点検する。
率が何%になったかより、この 2 問が使えるかどうかがこの記事の中身です。数字は「本当に守られていたか」を確かめるためのものです。
何を数えるか
転写（~/.claude/projects/<プロジェクト>/<セッション>.jsonl）の type == "assistant" 行には message.content[] があり、その中に type == "tool_use" が入ります。1 行に 1 個です。ここで「1 応答に何個並べたかは分からない」と一度結論しました。誤りでした。同じ応答の行は同じ message.id を持ちます。
import json, sys, collections
by_id = collections.OrderedDict() # 応答 id → [道具名, ...]（本文だけの応答は空リスト）
for line in open(sys.argv[1], encoding="utf-8"):
d = json.loads(line)
if d.get("type") != "assistant":
continue
m = d["message"]
by_id.setdefault(m["id"], [])
for b in m.get("content") or []:
if isinstance(b, dict) and b.get("type") == "tool_use":
by_id[m["id"]].append(b["name"])
all_resp = len(by_id) # 全応答（本文だけの応答を含む）
tool_resp = sum(1 for v in by_id.values() if v) # 道具を含む応答
total = sum(len(v) for v in by_id.values()) # 道具の総数
multi = sum(1 for v in by_id.values() if len(v) >= 2) # 複数道具の応答
single = collections.Counter(v[0] for v in by_id.values() if len(v) == 1)
print(f"全応答 {all_resp}／道具を含む応答 {tool_resp}／道具 {total}／複数道具の応答 {multi}（{100*multi/tool_resp:.0f}%）")
print("単独で出した応答の内訳:", dict(single.most_common(6)))
出るのは 4 つ——全応答／道具を含む応答／道具の総数／複数道具の応答の数と率。「道具を含む応答」は全 API 往復ではありません（本文だけの応答が別にある）。この計測器が見ているのは「道具を含む応答をどれだけ減らせたか」で、往復全体の内訳は前の記事の集計で見ます。
起点: 0/61
規律を書いてから 1 か月後の、定型の事務作業 1 件（公開ページを読んで台帳に記帳する類）。前の記事と同じ区間です。
| 全応答 | 道具を含む応答 | 道具の総数 | 複数道具の応答 |
|---|---|---|---|
| 62 | 61 | 61 | 0 |
「まとめる」という一文は設定ファイルにも記憶にもあった。読んではいた。並べたことは一度もなかった。
言われてやった 1 回は証拠に数えない
「本当に並べられるのか」と言われて、独立な 3 つ（コマンド・検索・コマンド）を同じ応答に並べました。転写では同じ message.id に 3 個、往復は 1 回。実行は逐次で、先頭と末尾のタイムスタンプは約 1.9 秒差でした。今回のこの 3 呼び出しでは、確認できた便益は実行時間の短縮ではなく LLM 往復の削減です。
この 1 回は、指示されてやったので、規律が身についた証拠には数えません。測るべきは直接指示のない作業です。
直接指示のない通常作業で、どう動いたか（区間ごとの値）
同じセッションの中で、この議論のあとに通常の作業（自作の試作を数本組む・計測する）を続けました。指示は「作業を進めて」だけです。
| 区間 | 全応答 | 道具を含む応答 | 道具 | 複数道具の応答 |
|---|---|---|---|---|
| 前半（試作 3 本） | 48 | 47 | 47 | 0（0%） |
| 後半（試作 2 本） | 19 | 18 | 29 | 9（50%） |
| 最終区間（作業 1 件） | 7 | 6 | 11 | 1（17%・計測の呼び出しを除くと 5 応答中 1） |
最終区間の単独応答を全部見ると、どれも「前の結果を読んでから次を決める」型で、独立なのに単独＝0 件でした。前半の単独応答 47 件のうち、器の診断行（Bash・Edit・Write などの並び）を見て「並べられたのでは」と目で拾った候補 10 件を人手で判定すると、束ねるべきだった 8／単独が正しい 1／束ねられるが価値が小さい 1。無作為抽出ではないので 8/10 を 47 件全体の率に伸ばせません。言えるのは「独立なのに単独だった応答が少なくとも 8 件あり、束ねていれば往復が 12 減った（47 件中）」までです。取りこぼしの型は 2 つ——連続する独立な書き込みと、記帳と次の材料読み。どちらも後半で消えました。
後半の 50% は「率が高い＝良い」ではありません。同じ 2 問判定で NO・NO のものを並べた結果、たまたまその区間は独立な書き込みが多かっただけです。
率を目標にしない
「複数道具の応答率」を上げようとすると、Q1 で YES のものまで束ねる誘因が生まれます。並べていいのは Q1・Q2 が両方 NO のものだけ。率は診断計器で、減らしたいのは「独立なのに単独で出した不要往復」です。もう 1 つ、Bash の中で複数コマンドを 1 本に束ねたものは「1 回の道具」に数えるので率には出ません。総数の減りと合わせて読みます。
閉じる基準も先に決めました。A 独立なのに単独が少ない→終了／B 軽微→保留／C 同じ独立型を何度も単独で出す→そのパターンだけ器で警告（WARN 印字のみ・終了コードは変えない）。今回は A で閉じました。
言わないこと
- 「記憶と文書だけで身についた」。同じセッション内には議論と明示テストの文脈があった。
- 「次のセッションでも持続する」。未確認。次の通常セッションの終了時に測り、出ていれば追記します。人工の実験は作りません。
- 「並べると速い」。今回の 3 呼び出しは逐次だった。効くのは往復の再計上の分。
- 「道具を含む応答＝全往復」。本文だけの応答は別にある。
Lab 版（「測れない」と誤結論した経緯・0/72 と書いて数え直した記録・率を目標にしそうになった記録）: https://sumitsuke.jp/via/qiita/lab/tool-calls-batched-or-not/
AI の利用について
計測器と記事の下書きには AI（Claude）を使いました。数字（62／61／61／0・48／47／47／0・19／18／29／9・7／6／11／1・8／1／1）は自分の転写と作業記録から数え、判定と公開は自分で行っています。転写に含まれる案件の中身は書いていません。
受託でも同じ運用をしています
「守られているはず」を、記録から数えて確かめます。相談はテキストだけで完結します。
▶ Sumitsuke ／ 依頼から納品までの流れ
次に読む: 数える物差しそのものを疑う——期待値を別の根拠から作ったら自分の癖が 2 回捕まった
この記事は Zenn にも同じ内容を掲載しています。