この記事が示すこと
- 問多くの自作スキルは 「適切なトークン量」になるよう設計されていない。動くが、無駄に重い。
- 因原因は、トークンが 「常時かかる分」と「発火時だけの分」（＋実行時）の2〜3種類 に分かれることが意識されていないから。
- 解成果物を変えずに効かせる 4つの設計レバー（A / B / C / D）。
- 証実在スキル1本での before / after 実測値。そして「削る」が主役ではないという逆説。
なぜ自作スキルは、放っておくと重くなるのか
自作スキルは「どんな成果物を、どう作るか」を中心に書かれる。当然だ。だが 「その記述が、いつ・何回読まれるか（＝コスト構造）」は、ほとんど設計されない。 機能は設計するのに、トークンは設計しない——ここに問題の根がある。
ドキュメントやプロンプトの延長でスキルを書くと、自然とこうなる。説明文に運用の細部まで盛り込み、同じ注意書きを各手順に重複させ、重い参照ファイルを工程ごとに何度も読ませる。どれも"動く"。成果物も正しく出る。 だからこそ厄介で、無駄がいっさい目に見えない。使うたび静かにトークンを払い続けることになる。
この記事で扱っているのは、抽象論ではなく、前回の記事「アプリのリリース素材5点を、AIに一気通貫で出荷させる手法」を作るために使っていた自作スキルです。最初の版は、記事やLPを“ポン出し”するには便利でした。ただ、実際に運用してみると、説明文に発火判定以外の情報が入りすぎていたり、記事生成時に同じ前提を何度も読ませていたりして、成果物とは関係ないところでトークンを食っていました。そこでAIに「成果物は変えず、トークン消費が少なくなるように設計を考えて」と指示し、スキルの構造そのものを作り直したのが、この実測の出発点です。
解決の第一歩は、削ることではない。「トークンには種類がある」と知り、構造から設計し直すことだ。
トークンには「2種類」ある（これを知らないと直せない）
スキルは段階的に読み込まれる。この構造を押さえないと、削る場所を必ず間違える。重さは下の3つのどこかに溜まっている。
説明文
(description)
無関係な会話も含め毎回すべての会話に積まれる。1回は小さくても回数で効く。
本文
(手順の中身)
スキルが起動したときだけ読まれる。ボリュームは大きいが回数は限られる。
外部ファイル
の読み込み
「このファイルも読んで」が読むたびかかる。同じものを2回読めば2回分。
直し方は4つ。設計レバー A / B / C / D
診断ができれば打ち手は明確になる。どれも成果物（寸法・挙動・文言）には一切触れない、構造側の手当てだ。
説明文に必要なのは「何をするか」と「いつ発火するか」だけ。運用の細かい指示は本文へ移す。発火判定に不要な文を全会話から外せる。
→ ①常時コスト・最強のレバー散らばった注意書きを冒頭の「共通ルール」に1回だけまとめ、以降は参照。要件は1つも消さず、言い回しの重複だけを畳む。
→ ②発火時コスト重い章を分割し「その工程で読む」に。1機能だけの依頼が安くなる。ただし毎回フル機能だと結局全部読むので旨味は薄い。
→ 部分的な依頼に効く（使い方次第）同じ大きい参照ファイルを2回読ませていないか。1回読んで使い回せば、成果物を1ミリも変えずまるごと1回分が浮く。
→ ③実行時コスト解決策は、本当に効くのか
対象にしたのは、ローカルに置いて運用していたブログ記事生成系の自作スキルです。Art1のような解説記事を作るためのスキルで、記事本文、HTML化、サムネや公開導線の前提まで抱えていました。この実在スキル1本へ A・B・D を適用した（C は「単発依頼がほぼ無い」運用のため見送り）。測定は文字数と概算トークン。机上論ではなく、数字で確かめる。
公開用に一般化した省トークン版の SKILL.md は、GitHub の「app-launch-neo-kit」に置いています。個人環境のパスやサイト固有の値はプレースホルダー化しているので、自分の公開先やパッケージ名に置き換えて使えます。
| レバー | 対象 | before → after | 効果 |
|---|---|---|---|
| A | 説明文 (毎回読まれる) | 449字 → 300字 | −33% |
| B | 本文 (発火時に読まれる) | 9,646字 → 9,076字 | −5% |
| D | 外部ファイルの 二度読み | 2回 → 1回 | ≈ −2,000〜2,350 tok / 制作 |
数字の読み方が大事。 A の −33% は「毎回の会話」に効く——1回の節約は小さくても累積は本文圧縮を軽く超える。B は頑張っても −5%。D はファイルサイズに現れないが、実際の1回の制作では A・B を合わせたより大きい削減になった。
核心：直すべきは「量」ではなく 「頻度・タイミング」
多くの人は「トークンを減らす＝記述を短くする」と考え、本文を削ろうとする。だが実測のとおり、本文圧縮（B）は −5% しか効かなかった。
理由は明確で、本文の大半は「成果物や挙動を決める実体のある指示」だから。レイアウトの寸法、フォームの挙動、免責の文言、品質チェックのゲート——削れば成果物が変わる。「成果物に影響を与えない範囲」を守ると、本文に削れる余地はほとんど残らない。だから自作スキルは、内容を削る発想のままでは適切な量に設計し直せない。
適切なトークン量への設計とは、「文章を短くする」ではなく「読み込まれる回数・タイミングを設計し直す」こと。常時コスト（説明文）と、実行時の重複読み込み。この2つが二大ポイント。
自分のスキルを「設計し直す」6ステップ
- まず測る。 ファイルを「説明文（冒頭）」と「本文」に分けて文字数を出す。セクションごとにも出すと重い章が見える。
- 説明文を点検（A）。 発火判定に不要な運用指示が紛れていないか。あれば本文へ移す。ただしトリガー文言は消さない（消すと発火しなくなる）。
- 重複を探す（B）。 同じ注意書きが複数の手順に出ていないか。冒頭の「共通ルール」に集約して参照させる。
- 外部ファイルの読み込み回数を数える（D）。 同じファイルを2回以上読ませていたら、1回にして使い回す。
- 使い方で C を判断。 1機能だけ呼ぶことが多いなら章を別ファイルに分割。毎回フル機能なら不要。
- before / after を測り直す。 どのレバーが効いたか数字で確認する。
まとめ：チェックリスト
- 説明文に「発火判定に不要な運用指示」が混ざっていないか (A)
- 同じ注意書きが手順をまたいで重複していないか (B)
- 同じ重い参照ファイルを2回以上読ませていないか (D)
- 単発依頼が多いなら、重い章を別ファイルに出せないか (C)
- 削った変更が「成果物」を変えていないか（寸法・挙動・免責・品質ゲートは死守）
- before / after を 実測 したか（推測で削らない）