この記事は playpark Blog からの転載です。
この記事で分かること
- SKILL.mdが肥大化する本当の理由
- 「決定論的」vs「非決定論的」処理の判断基準
- スクリプト化を選ぶべき場面
背景: こういう課題があった
Claude CodeでSkillを作ると、気づけばSKILL.mdが300行超え。「次の火曜を計算して」「このディレクトリが存在するか確認して」といった処理を自然言語で書くと、毎回AIが解釈し直す必要があり、context tokenを消費し続けます。
選択肢の検討
SKILL.mdの肥大化に対して、いくつかのアプローチがあります。
| アプローチ | メリット | デメリット |
|---|---|---|
| 自然言語で詳細記述 | 柔軟、変更容易 | token消費大、解釈ブレ |
| プロンプト圧縮 | token削減 | 可読性低下、保守困難 |
| スクリプト分離 | token消費なし、結果一定 | 初期実装コスト |
なぜスクリプト化を選んだか
判断基準: 入力が同じなら出力も同じか？
| 処理 | 決定論的？ | 選択 |
|---|---|---|
| 次の火曜/木曜を計算 | ✅ Yes | スクリプト |
| ファイル存在チェック | ✅ Yes | スクリプト |
| ブログ記事の本文生成 | ❌ No | AI |
| カテゴリ推定、タグ提案 | ❌ No | AI |
「決定論的」な処理はスクリプトで一発解決。AIには創造性が必要な処理だけを任せます。
実装例
#!/bin/bash
# 次の火曜or木曜を計算
set -euo pipefail
BASE_DATE="${1:-$(date +%Y-%m-%d)}"
day_of_week=$(date -j -f "%Y-%m-%d" "$BASE_DATE" "+%w" 2>/dev/null || \
date -d "$BASE_DATE" "+%w")
case $day_of_week in
0) days_to_tue=2; days_to_thu=4 ;;
1) days_to_tue=1; days_to_thu=3 ;;
2) days_to_tue=7; days_to_thu=2 ;;
3) days_to_tue=6; days_to_thu=1 ;;
4) days_to_tue=5; days_to_thu=7 ;;
5) days_to_tue=4; days_to_thu=6 ;;
6) days_to_tue=3; days_to_thu=5 ;;
esac
[[ $days_to_tue -le $days_to_thu ]] && days=$days_to_tue || days=$days_to_thu
if date -v +1d > /dev/null 2>&1; then
date -j -v +${days}d -f "%Y-%m-%d" "$BASE_DATE" "+%Y-%m-%d"
else
date -d "$BASE_DATE + $days days" "+%Y-%m-%d"
fi
このスクリプトを呼び出すだけで、毎回同じ結果が得られます。
まとめ: どういう場面で使うべきか
「入力→出力が固定」の処理はすべてスクリプト化の候補。
自然言語の曖昧さをなくし、token消費とエラー率の両方を削減できます。結果、SKILL.mdは「何を呼ぶか」だけの42行に収まりました。
さらに深掘りしたい方へ
この記事ではスクリプト化の判断基準を解説しました。
SKILL.mdの書き方｜Claude Code Skills設計ベストプラクティス【肥大化防止】 ではさらに：
- 複数スクリプト（orchestrate.sh, detect_mode.sh）の連携パターン
- 実運用で遭遇した落とし穴（macOS/Linux互換性、JSONエスケープ）
- 他Skill（generate-thumbnail, sns-announce等）への応用例と効果測定
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
