amiiby

[Claude Code]指摘の無限ループに終止符を

  • Claude Code
  • AGENTS.md

ぬにょす(挨拶)。

Claude に「そこ違う」と指摘すると、ちゃんと直してくれます。ただ、直るのはその成果物だけなんですよね。

次のセッションは同じ指示ファイルを読んで、同じところで同じように間違えます。で、私がまた同じ指摘をする、と。なんかイヤ。

と言うことで、指摘を受けたときの直し方を skill にしました。

この直し方を作るにあたっては、こちらの動画を大いに参考にさせていただきました。ありがとうございます。

回数で直し方を変える

キモは、同じ指摘を何回受けたかで、直す範囲を広げていくところです。

  • 1回目: 成果物を直し、指摘ログに1行足す
  • 2回目: 間違いを生んだ指示ファイル（AGENTS.md・CLAUDE.md・skill など）も直す
  • 3回目: grep・lint・hook などの機械の検査にする

回数を数えるために、指摘ログを置いています。1行の形はこんな感じ。

feedback-log.md
- 2026-10-04 <指摘の要旨> → <そこから言える決まり>（原因の置き場）

これが1週間ほどで50件を超えました。我ながら、指摘しすぎじゃないですかね(´･_･`)

実例

ブログの下書きを Claude と作っていたときのことです。

Claude が例を5つも並べてきたので、「一例で十分」と返しました。そのあと今度は細かい注記をビッシリ書き込んできたので、「文章量が多くて正確だからいい記事ではない」と返しました。

すると Claude は、これを同じ趣旨の指摘の2回目と数え、下書きを削ったうえで、AGENTS.md の「ドキュメント・コメントの書き方」に1項目足しました。

AGENTS.md
- 読み手に向けた文章（記事・紹介文・説明）では、確かめた範囲・期間・数え方などの注記や例は、読み手の理解や判断を変えるものだけを書く。例は1つで足りるなら1つにする。

これで、次のセッションからは最初から削った形で書いてくれる、という寸法です。

書き漏らしを拾う

とはいえ、指摘したのに Claude がログに書かないこともあります。そこで、毎朝の定期ジョブに、前日の会話から指摘の候補を拾わせています。

仕組みは3つのファイルでできています。

  1. feedback-draft.sh（ジョブのスクリプト）: launchd が毎朝6時に呼ぶシェルスクリプト。やることは、claude -p を1回呼んで、その出力を日付のフォルダに保存するだけです
  2. feedback-draft.md（claude -p への指示）: 「発言を集めるスクリプトを走らせる → 指摘ログを読んで、ログにまだ無い指摘だけを選ぶ → ログと同じ形の1行案を書く」という手順を書いてあります。同じ指摘の繰り返しなら「2回目以上」と書かせます
  3. collect-user-turns.mjs（発言を集めるスクリプト）: Claude Code の会話ログ（~/.claude/projects/ の下の JSONL）から、直近24時間の私の発言と、その直前の Claude の発言の末尾を集めて、Markdown で出します。どれが指摘かは決めず、材料を並べるだけ。一文字の返事（y・p など）は指摘にならないので落とします。これはジョブのスクリプトではなく、claude -p の中で Claude が自分で走らせます

ジョブのスクリプトの中身は、ほぼこの claude -p の呼び出しだけです。

feedback-draft.sh
claude -p --model sonnet --no-session-persistence \
  --settings '{"disableAllHooks": true}' \
  --permission-mode dontAsk \
  --allowedTools "Bash(node scripts/collect-user-turns.mjs:*)" Read Grep Glob \
  -- "$(cat scripts/jobs/feedback-draft.md)" </dev/null >"$dir/feedback-draft.md"
  • 指示のファイルの中身をそのまま claude -p に渡し、Claude の最後の応答を $dir（その日の日付のフォルダ）に書き出します
  • --allowedTools で、使えるのを発言を集めるスクリプトと読むだけのツールに絞っています。人のいない時間に動くので、ファイルの書き換えや git はさせません
  • --no-session-persistence は、このジョブ自身の会話を、次の日の材料に混ぜないため
  • disableAllHooks は、ふだんのセッション向けの hook（起動時の処理や、終わったときの通知音）を走らせないため

定期ジョブの出力は、こんな形です。

<日付>/feedback-draft.md
### 手順に待ちが入っているのに、今すぐできる分と分けずに頼んだ
- `- 2026-10-03 todo の手順が、登録完了のメールが届くまで進められない順序だったのに、「やること」として一括で頼んだ → 待ちが挟まる手順は、待たずにできる分と、待った後の分に分けて書く（AGENTS.md）`
- 「todo 読んだけどメールが届くまで進められないじゃん」（アプリ 1）

ログへの書き足しはさせず、案を出すまでにしています。取り込むかどうかは自分で決める、と。

skill の全文

手元のフォルダ構成に依存するところだけ、一般的な書き方に変えています。

fix-from-feedback/SKILL.md
---
name: fix-from-feedback
description: ユーザーやレビューの指摘で直すときに、成果物だけでなく間違いを生んだファイルまで直す手順。指摘を受けて直すとき、同じ指摘が繰り返されたときに使う。
---

# 指摘を受けたときの直し方

## 仕事

指摘の原因になったファイルを突き止め、同じ指摘を受けた回数に応じて、成果物・原因のファイル・機械の検査のどこまでを直すかを決めて直す。成果物だけ直すと、次のセッションも同じ所で間違える。

## やらないこと

- 指摘を確かめずに直す — 指摘はコード・一次資料・実例で確かめてから直すかを決める。
- 2回目の直しで原因のファイルを全文書き直す — 箇条書きの単位で足すか訂正する。全文を書き直すと、関係の無い決まりまで変わる。

## 出力

- 直した成果物。
- 回数に応じて、`feedback-log.md` の1行、原因のファイルの直し、検査のスクリプトや hook。

## 終わる条件

回数に応じた直しが全部済み、`feedback-log.md` に今回の1行がある。

## 止まる条件

次のときは推測で埋めずに止まり、ユーザーに聞く。

- 指示や資料が食い違うとき: 指摘が既存の決まりと食い違い、決まりの方を組み直すことになるとき（方針の変更になる）。

## 手順

1. 原因の置き場を決める。
   - 事実の誤り: 事実を書いたファイル
   - 全プロジェクトに共通する運用: 共通の `AGENTS.md`（Claude 固有なら `CLAUDE.md`）
   - 1 プロジェクトの運用: そのリポジトリの指示ファイル
   - skill のやり方: その skill
   - 機械で拾える漏れ: 検査のスクリプトや hook
2. 同じ指摘を受けた回数を、`feedback-log.md` を grep して数える。
3. 回数で直し方を変える。
   - 1回目: 成果物を直し、`feedback-log.md` に1行足す（指摘の要旨・そこから言える決まり・原因の置き場。形はファイルの冒頭）。
   - 2回目: 1回目に加え、原因のファイルを直す。
   - 3回目: 2回目に加え、grep・lint・hook などの機械の検査にする。機械で拾える指摘は1回目からそうする。機械が止めるようになった決まりは、文章からは消してよい。

## 合格条件

- 人が見る: 原因のファイルの直しが、指摘から言える決まりと合っている。全文を書き直していない。
- 機械が見る: `feedback-log.md` に今回の日付の行がある。機械の検査にしたなら、その検査が今回の間違いで落ちる。

まとめ

  • 指摘の回数で、成果物 → 指示ファイル → 機械の検査と、直す範囲を広げる
  • 回数は指摘ログで数える。書き漏らしは毎朝の定期ジョブに拾わせる

同じ間違いに同じ指摘をする、という無限ループからは抜け出せました。指示ファイルを育てたい方の参考になれば幸いです。

でわでわ。

記事の一覧へ