L1 ─ Skill と Slash Command で「型」を持つ
階段の最初の一段、L1 から始めよう。型化 ── つまり「毎回似たようなプロンプトを書いている自分」から抜け出す段階。
L1 は地味だが、ここを飛ばして L2 以降に行くと型がないまま自動実行されて散らかる。最初の投資先として最重要 と覚えてほしい。
なぜ L1 から始めるのか
例えばあなたが毎日こんなプロンプトを打っているとする：
このディレクトリの変更を git diff で確認して、
コミットメッセージを Conventional Commits 形式で 3 案出して。
prefix は feat/fix/docs/style/refactor/test/chore から選んで。
日本語で書いて、本文は省略していい。これを 1 日 5 回打つと、書く時間 + 思い出す時間で 30 秒 × 5 = 150 秒/日 を消費している。年 250 営業日なら 10 時間 だ。
.claude/commands/commit-msg.md に 1 度書いておけば、/commit-msg 一発で同じ結果になる。型化は最も ROI が高い L1 の投資。
Slash Command vs Skill ─ どちらを使うか
Claude Code には似たような仕組みが 2 つある：
| 項目 | Slash Command | Skill |
|---|---|---|
| 定義場所 | .claude/commands/<name>.md | .claude/skills/<name>/SKILL.md |
| 起動 | ユーザーが /<name> と打つ | Claude が文脈から自動選択 / ユーザー明示 |
| 規模 | 1 ファイル | 1 ディレクトリ（補助ファイル可） |
| frontmatter | 必須 | 必須 |
| 使い分け | 「自分が呼ぶ」型化 | 「Claude にも気付いて使わせる」拡張 |
「自分が頻繁に呼ぶ」なら Slash Command、「Claude が状況に応じて使うべき道具」なら Skill。L1 で始めるなら Slash Command が単純で扱いやすい。
最小の Slash Command
.claude/commands/commit-msg.md：
---
description: 現在の変更からコミットメッセージ案を 3 つ生成する
---
## 現在の変更
!`git diff HEAD`
## ステージ済みの変更
!`git diff --cached`
これらの変更を見て、Conventional Commits 形式で
コミットメッセージを 3 案、日本語で出してください。
prefix は次から選択：
feat / fix / docs / style / refactor / test / chore
各案には変更の意図を 1 行で添えてください。ポイント 3 つ：
- frontmatter に
description：何のコマンドかを Claude に伝える !`cmd`で動的コンテキスト挿入：実行時に shell command を走らせて結果を inject- 本文は普通の自然言語：Claude に渡るのは展開後の markdown
これだけで /commit-msg が動く。! 記法のおかげで、毎回 git diff を貼り付ける手間が消える。
frontmatter で制御できること
公式 Slash Commands ドキュメント に詳しいが、よく使う項目：
---
description: コマンドの説明（必須）
allowed-tools: Bash(git *) Bash(npm *) # この command 中だけ許可するツール
arguments: <name> <value> # 引数定義
context: fork # subagent 化（独立 context で実行）
disable-model-invocation: true # ユーザーのみ起動可（Claude が勝手に呼ばない）
---allowed-tools が地味に重要。コマンド実行中だけ Bash(git *) を許可することで、毎回 permission prompt を avoidできる。一方で Bash(*) のような広すぎる許可は避ける。
動的コンテキスト挿入の威力
!`cmd` 記法は単なる便利機能ではなく、型化の質を決める。
例：単純な「PR レビュー」コマンドを比較してみる。
Bad：人が情報を集める
---
description: PR をレビューする
---
PR の内容を見てレビューコメントを書いてください。これだと Claude は「PR の内容って？」となる。ユーザーが手動で git log、git diff main..HEAD、関連 issue を貼る必要がある。
Good：型がコンテキストを集める
---
description: PR をレビューする
allowed-tools: Bash(git *) Bash(gh *)
---
## ベース branch との diff
!`git diff origin/main...HEAD`
## 変更ファイル一覧
!`git diff --name-only origin/main...HEAD`
## 関連 issue（PR 本文から抽出）
!`gh pr view --json body -q .body | grep -oE '#[0-9]+' | head -5`
## レビュー観点
以下の観点でレビューしてください：
- セキュリティリスク（SQL injection / XSS / 認証バイパス）
- パフォーマンス（N+1、不要なループ）
- 設計（責務違反、過剰な抽象化）
- テスト（カバレッジ、edge case）
各指摘には severity（high/medium/low）を付けて。型がコンテキスト収集まで担うことで、ユーザーは /pr-review だけで動かせる。これが L1 で型化する真の価値。
引数のあるコマンド
例：「特定ファイルにテストを追加する」コマンド。
.claude/commands/add-test.md：
---
description: 指定ファイルに対するテストを追加する
arguments: <file-path>
---
対象ファイル: $1
## 対象ファイルの内容
!`cat "$1"`
## 既存のテストファイル（同名で .test.* / .spec.* / __tests__ にあるか）
!`find . -path ./node_modules -prune -o -type f \( -name "$(basename $1 | sed 's/\..*$//').test.*" -o -name "$(basename $1 | sed 's/\..*$//').spec.*" \) -print 2>/dev/null | head -5`
## 指示
`$1` のテストを追加してください。
- 既存のテストファイルがあればそこに追記
- なければ同階層に `<basename>.test.<ext>` を新規作成
- happy path + edge case を最低 1 つずつ
- 既存のテストフレームワーク（jest/vitest/pytest 等）を踏襲/add-test src/utils/parser.ts で起動する。
引数を取るときの落とし穴：$1 が user 入力なので shell injection に注意。bash の中で使う場合は必ず "$1" のようにダブルクォートで囲む。
Skill ─ Claude が自分で気付く道具
Slash Command は「ユーザーが呼ぶ」前提だが、Skill は「Claude が状況に応じて使う」前提で書かれる。
.claude/skills/code-review/SKILL.md：
---
name: code-review
description: コードレビューを行う際に使う。PR / commit / 単一ファイルのいずれにも対応。security/performance/design/test の観点で評価する。
---
# Code Review Skill
このスキルは以下の状況で発動：
- ユーザーが「review」「レビュー」と言った時
- PR / commit / ファイルパスが文脈に出た時
- "コードチェック" のような非明示の依頼
## 観点
### セキュリティ
- SQL injection / XSS
- 認証バイパス
- secret の hardcode
### パフォーマンス
- N+1 問題
- 不要なループ
- 同期処理の過剰使用
(以下略)description が長く具体的なのがポイント。Claude はセッション開始時にこの description を見て「いつこの skill を使うか」を判断する。短すぎると見逃され、長すぎると context を圧迫する。100〜300 文字 が目安。
副業実例：型化が効く現場
調査で集めた事例から、L1 の効果が大きかった現場を 3 つ紹介する：
事例 1：定型 Web 制作の skill 化
個人ブログ「Claude Codeで月5万円のWeb制作副業を始めた全記録」 より：
80% は AI が書くが、残り 20% に時間の 60% がかかる。
180 日かけた個人記録の core insight。残り 20% ── つまりサイト固有のヒアリング反映、ブランド色合わせ、SEO 微調整 ── は Claude にも個別判断が要る。だが、最初の 80%（プロジェクト初期セットアップ / 共通コンポーネント / 型定義）は完全に型化できる。
このケースでの skill 例：
/init-website─ Astro テンプレートからプロジェクト初期化/component <name>─ Atomic Design に沿ったコンポーネント雛形/seo-check <page>─ titleタグ・OGP・schema.org 検証
「型化できる 80% を 1/10 の時間で済ませて、残り 20% に集中する」がこの現場の勝ち方。
事例 2：研究時間の削減
Anthropic 社内 Inference チームの事例：
リサーチ時間が 80% 短縮された。
その内訳の多くが 「論文を要約する型」「実験結果を表にまとめる型」「ベンチマーク結果を比較する型」 といった type 化された skill だった。L5 の multi-agent ではなく、L1 の地道な型化 が大半の効率化を生んでいる。
事例 3：コードレビュー準備
LINE ヤフー Tech Blog の PR レビュー準備自動化 は L3 の事例だが、その下敷きに L1 の type 化 がある：
/pr-context <PR_URL>
→ PR の diff、関連 issue、Confluence の仕様書、Jira の背景情報を集めるこれがあるから L3 で「PR が来たら自動で /pr-context を呼ぶ」が成立する。L3 は L1 の type 化を時間軸で動かしているだけ。
L1 の罠：型を作りすぎる
「型化が大事」と分かると、何でもかんでも skill にしたくなる。だが副作用がある：
罠 1：見つけられない skill
.claude/commands/ に 50 ファイル並ぶと、自分でも何があるか覚えていられない。「あの作業、確か skill にしたっけ？」と探すコストが、再利用の便益を上回る。
対策：/list 系のメタ skill を 1 つ作って、定期的に index を眺める。あるいは naming に prefix（git-*、pr-*、test-*）を入れる。
罠 2：description の質が低い skill
description: コードレビューする のような曖昧な定義では、Claude が「いつ使うか」を判断できない。結果として 作ったのに呼ばれない skill が量産される。
対策：description には「いつ使うか / 何をしないか」まで書く。
罠 3：型が硬すぎる
毎回少しずつ違う作業を 1 つの型に押し込むと、結局型を編集してから使うことになり、効率化されない。
対策：頻度 × 同形度 で評価。週 5 回 × 8 割同形なら型化、週 1 回 × 6 割同形なら型化しない。
L1 設計のチェックリスト
graph TB
Q1[週 3 回以上やる作業か?] -->|Yes| Q2[8 割以上同じ形か?]
Q1 -->|No| Skip[L1 化しない]
Q2 -->|Yes| Q3[コンテキスト集めも含めて型化できる?]
Q2 -->|No| Skip
Q3 -->|Yes| Make[Slash Command で型化]
Q3 -->|No| Q4[Claude に発見させたい?]
Q4 -->|Yes| Skill[Skill で定義]
Q4 -->|No| Make
style Make fill:#e1ffe1
style Skill fill:#d1f4e1
style Skip fill:#fffこの章の要点
- L1 = 型化。
.claude/commands/または.claude/skills/に SKILL.md を置く description/allowed-tools/arguments/context: forkなどで挙動制御!`cmd`記法で動的コンテキスト挿入、これが型化の質を決める- Slash Command は「自分が呼ぶ」、Skill は「Claude が気付く」
- 副業実例：型化できる 80% を 1/10 で済ませ、残り 20% に集中
- 罠：作りすぎ / description が曖昧 / 型が硬すぎる
- 頻度 × 同形度 で型化判断
次章への問いかけ
型化はできた。だが Claude が その型に従わない ことがある。
CLAUDE.md に「絶対 X するな」と書いても忘れる。skill を呼ばずに自前でやり始める。次章では Hooks で Claude を機械的に監視する 方法に進む ── 自分自身を見張らせる仕組み。