Claude Code のスキル56本を棚卸しした。記事1本ごとに10万字の必読連鎖が走っていた

朝いちばんに、バックグラウンドで走らせていた dev サーバーが勝手に止まった。 ビルドが壊れたわけではなく、実行環境のメモリが足りずに落とされたという。

「これ Node のプロセス52個やばすぎるんで、ちょっと掃除してほしい」と投げて /procs を走らせたら、実際には55個あった。 掃除後は16個。 空きメモリは 6.0GB から 10.2GB に戻った。

プロセスを落とせばメモリは戻る。 戻らないのは、毎朝の記事づくりが1本あたりどれだけの指示を読み込んでいるかのほうである。 こちらは掃除しても1字も減らない。

記事を1本書くのに何を読ませていたのか

Eric Provencher の「GPT-6 Astra 時代に向けてスキルとプロンプトを考え直す」というポストを読んで、翻訳記事を1本書かせた。 そのとき起動したスキルは、content-management、japanese-tech-writing、doc-communication、svg-diagram、honda-sakubun の5本である。

図は1枚も入れていない。 それでも svg-diagram が入っている。

自分のスキルが今どういう状態になっているのか、そういえば一度も数えたことがない。 そこで、このリポジトリ直下のプロジェクトレベルと、全リポジトリ共通のユーザーレベルの両方を対象に、デューデリジェンスをさせた。

一覧に常時載っている量

対象はユーザーレベル42本とプロジェクトレベル14本の計56本。 あわせて、同じ一覧に載るコマンド46本の説明文と、Codex 用に置いてあるコピー9本も見た。

一覧に常時載る説明文は、スキル56本で合計10,110字。 平均181字で、最長は488字あった。 200字を超えるものが18本ある。 コマンドぶんを足すと、約14,000字がこのリポジトリで開く全セッションの冒頭に毎回載っていることになる。

長い説明文の中身を見ると、原因は2つしかなかった。 1つは、本文に置くべき運用ルール（アカウントの使い分け、経路の選択、テーブルの仕様）を説明文に書いていること。 もう1つは、発動しそうな言い回しを思いつく限り並べていることである。

ついでに、102本の frontmatter を PyYAML で読み直させたら、2本が構文エラーで落ちた。 どちらも、引用符なしの説明文に「TRIGGER: 」のような「コロンと空白」が入っていた。 これだと YAML の mapping として読めない。 一覧での見え方も違っていて、片方は説明文の代わりに本文の H1 が表示され、もう片方は名前だけが並んでいた。 説明文を書いたつもりで、いつ使うかをモデルに伝える手段を失っていたわけだ。

doc-communication が連れてくるもの

報告書が上がってきた時点で、私は doc-communication が犯人だと思っていた。 呼ばれる回数が多いうえに、中身も大きいのだろうと。

結論を聞いたら、半分外れていた。 doc-communication の本文は4,486字で、むしろ小さいほうだった。 問題は、そこから無条件に svg-diagram（36,333字）と grid-alignment.md（16,570字）を連れてくる指示が書いてあったことである。 合わせて52,903字。

さらに content-management が必ず doc-communication を呼ぶ。 つまり記事や日記を1本書くたびにこの連鎖が走る。 「必ず読む」と指示された量だけを合計すると、記事1本あたり101,884字になり、その52%が図解ルールだった。 5週間のログでは、content-management が151回、honda-sakubun が134回、doc-communication が112回呼ばれている。 毎朝の /make-diary が27回走った結果である。

犯人が本文の大きさではなく連鎖の張り方だとわかったので、修正案は項目ごとに Before と After の形で書いてほしいと頼んだ。 どこをどう書き換えるのかが文面で見えないと、承認したあとで何が起きるか判断できない。 報告書には8項目ぶんの Before と After が並んだ。

Codex レビューで出た指摘

決裁フォームを出す前に、報告書を Codex で3回レビューさせた。

効いたのは2回目で、指摘は2つだった。 1つは、決裁2と決裁3が同じ4本のスキルを二重に扱っていたこと。 もう1つは、Mac 側の集計をどの条件で行うかと、説明文の変更を誰が担当するかが、決裁の間で食い違っていたことである。 どちらも書いてある内容の誤りではなく、決裁の切り分けが重なっているという指摘だった。 自分で読んだときは、判断する項目が4つあるとしか見ていなかった。

4件の決裁と、実際に減った量

判断が必要な項目は4件で、いずれも推奨案が示されていた。 ローカルに立てた決裁フォームの3択ボタンで答えて、4件とも推奨案 A にした。

決裁1の分割では、節の本文を一字も変えずに参照ファイルへ移させた。 本文には要点と参照先だけを残す。 文章を書き直すと、あとで「効きが変わったのは分割のせいか、書き換えのせいか」が切り分けられなくなる。

決裁2だけは実施していない。 「5週間で0回」はあくまで Windows 機の話だからである。 8月からの主機は Mac のほうで、そちらのログは数えていない。 片方の機の記録だけを根拠に13本を退避させたら、向こうで毎日使っているものを消しかねない。

Codex 用に置いてあった9本のコピーは、8本が正本と食い違い、2026年5月15日の状態で止まっていた。 古い指示が読まれる状態を放置していたことになる。

1ヶ月後に戻せる形にする

コミットする前に、戻し方を先に決めさせた。 1ヶ月後に「やっぱり前のほうが書きやすかった」と思ったとき、どこを叩けば元に戻るのかがわからない変更は、実質やり直せない。

そこで決裁ごとに独立したコミットに分けた。 戻したい決裁のハッシュを git revert するだけで、他の決裁に影響を与えずに打ち消せる。 報告書にも、どのコミットを戻すと何が消えるのかを書かせてある。 たとえば svg-diagram の分割を戻すと、参照7本が消えて本文が36,333字に戻る。

学習ゲートはこの日の作業では LEARN_SKIP=1 で通した。

残した2つのルール

作業のあとで、教訓を2つ、ルールとして書かせた。 どちらも今日の事故がそのまま根拠になっている。

説明文（description）は必ず二重引用符で囲む。 引用符なしで「コロンと空白」を含むと YAML として壊れ、一覧に説明文が出ない。 102本を検証して2本が該当した。

説明文には「何をするか」と「いつ使うか」だけを120字前後で書く。 運用ルールも仕様も発動語の羅列も、本文へ移す。 本文自体も要点と索引にとどめる。 手順と作例と事故記録は参照ファイルへ置き、その作業をする日にだけ読ませる。

締めゲートに引っかかった副産物として、もう1つ規則が増えた。 以前書いた計画書が、対象として .claude/skills/ という置き場全体を宣言していたのである。 そのせいで、無関係なスキルを直しただけのコミットが止まった。 作る予定のスキルは、置き場ごと掴まずにスキル単位まで絞って書く。

残っているもの

Mac で同じ集計を取る手順は報告書に書かせて、Windows 側の結果と一緒にコミットしておいた。 向こうで pull したセッションが同じスクリプトを走らせれば、両機で0回のものだけを取り出せる。

コマンド側の棚卸しは別の機会に回した。 こちらは46本あり、/make-diary が32,408字、/update-korea-chip-exports が24,235字と、スキルより太いものが混じっている。 スキルを削った直後に同じ作業を続けると、どちらが効いたのかがわからなくなる。

朝に消した39個のプロセスは、放っておけばまた増える。 連鎖のほうは、図を描くと決めた日にだけ svg-diagram へ伸びる形になった。 明日の /make-diary が最初の実測になる。