こちらの記事についてうちのClaude Codeに聞いた時の回答です。ご参考になれば。
以下 本文
記事拝見しました。やっていること自体は正しい方向です。3つの方策が効いた理由を理解した上で、もう一段レベルアップできるポイントをお伝えします。
まず、なぜスキップが起きるのか（30秒で分かる図）
核心: Claude Codeは「コーディングエージェント」として設計されているので、システムプロンプトが「簡潔に・最小限に」と強く指示しています。あなたの「全部書け」という指示とモデルが板挟みになり、より強いシステムプロンプト側に引っ張られてスキップが起きます。
効いた3方策の「なぜ効いたか」
| 方策 | なぜ効いたか |
|---|---|
AUTOCOMPACT_PCT_OVERRIDE |
コンテキストが膨れすぎると指示の記憶が薄まる。500Kに制限して指示の密度を維持した |
| TodoWrite + task-registrar | 「やることリスト」をモデルの内部記憶ではなく外部ツールに書き出すことで、コンパクション後も消えなくなった |
| 心理的プレッシャー | RLHFで「ユーザーの期待に応えたい」と学習しているので、「急がなくていい」「やり直しになる」が簡潔性バイアスを上書きした |
理屈を理解した上で、次のステップへ進みましょう。
今日からできる具体的な改善 5つ
改善1: CLAUDE.mdを50行以下にする（最重要）
公式ドキュメントにも明記されていますが、CLAUDE.mdが長いほど指示の遵守率が下がります。
"Bloated CLAUDE.md files cause Claude to ignore your actual instructions!"
— Claude Code公式ドキュメント
150を超える命令を書くと、先頭の指示ばかり重視される「primacy bias」が顕著になります。
やること:
- 今のCLAUDE.mdから本当に毎回必要なルールだけを残す（5〜10個）
- 残りは全てSkills（スキル） に移す
- CLAUDE.mdは「ポインタ（参照先）」として機能させる
# CLAUDE.md（悪い例 — 200行超）
- 省略禁止
- 全セクション書け
- コードブロック必須
- 画像説明入れろ
- ...(延々と続く)
# CLAUDE.md（良い例 — 30行以下）
## 最重要ルール
- 作業をスキップ・省略しない。全ステップを完遂する
- 出力は簡潔にしなくてよい。品質と網羅性を優先する
- 不明点はスキップせず質問する
## タスク別手順
- 記事執筆: /write-article を使う
- 動画台本: /write-script を使う
改善2: 用途別にSkillsを作る
「常に適用すべきルール」はCLAUDE.md、「特定の作業のときだけ必要な手順」はSkillsに書く。これが公式推奨の使い分けです。
.claude/skills/write-article/SKILL.md を作って:
---
description: "技術記事を執筆する"
---
## 記事執筆ルール
- 見出し数: 5個以上
- 各セクション: 300字以上
- コード例: 各セクション1つ以上
- 合計文字数: 3,000字以上
- 全セクション完了後に「執筆完了」と宣言する
## 手順
1. 構成案を作成して提示する（ここで確認を入れる）
2. 確認後、各セクションを順番に執筆する
3. 全セクション完了後、セルフレビューを行う
4. 「執筆完了」と宣言する
こうすることで、コーディング時にはこの指示が読み込まれず、記事執筆時にだけ /write-article で呼び出されます。
改善3: 出力仕様を「数値」で定義する
「ちゃんと書け」「省略するな」は曖昧で、モデルが自分に都合よく解釈します。数値で定義すると逃げ場がなくなります。
## 出力仕様（必須チェックリスト）
- [ ] 見出し数: 5個以上
- [ ] 各セクション文字数: 300字以上
- [ ] 合計文字数: 3,000字以上
- [ ] コードブロック数: 3個以上
- [ ] 末尾に「全セクション完了」と記載
これをプロンプトの冒頭に書いてください（末尾ではなく冒頭。Lost in the Middleの逆で、冒頭と末尾は記憶に残りやすい）。
改善4: 1タスク = 1セッション を徹底する
Claude Code公式ベストプラクティスにある「キッチンシンクセッション」の回避です。
❌ 悪い例: 1セッションで「構成案作成→執筆→画像生成→動画台本→TTS」
✅ 良い例: 各フェーズごとに /clear してセッション分離
タスクが混在すると、コンテキストに無関係な情報が増えて注意力が薄まります。特にPhase 6まであるような大きなワークフローは、フェーズごとにセッションを分けるのが鉄則です。
AUTOCOMPACT_PCT_OVERRIDE で500Kに制限したのは正しい判断ですが、そもそもセッションを分ければコンテキストが膨れること自体を防げます。
改善5: Hookで出力量を機械的にチェックする
Hookは「LLMの判断を介さない決定論的チェック」なので、最も信頼できる防御層です。今使っているHookを少し改良して、出力の文字数・行数を検証するものにしましょう。
#!/bin/bash
# .claude/hooks/check-output-length.sh
# Write/Editツール実行後に出力量をチェック
CONTENT="$1"
CHAR_COUNT=$(echo "$CONTENT" | wc -m)
LINE_COUNT=$(echo "$CONTENT" | wc -l)
if [ "$CHAR_COUNT" -lt 500 ]; then
echo "WARNING: 出力が${CHAR_COUNT}文字しかありません。省略していませんか？全セクションを含めてください。"
exit 1
fi
settings.jsonへの設定:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write",
"command": "bash .claude/hooks/check-output-length.sh"
}
]
}
}
優先順位まとめ
最後に一つだけ
記事で書かれている3つの方策は良い線いっています。ただ、根本原因はClaude Codeが「コーディング用」に最適化されていることです。非コーディング用途で使うなら、「コーディングエージェントの簡潔性指示を上書きする仕組み」を意識的に組み込む必要があります。
上の5つの改善を入れれば、「ギリ耐えられるレベル」から 「普通に使えるレベル」 に上がるはずです。