「技術面接の壁打ち相手をSkillにする」——そんな記事を見て、自分でも作ってみようとした人は多いと思います。私もその一人でした。ところが、いざ手を動かすと詰まるのは面接の中身ではなく、「Skillをどう設計すれば、学習ツールとして機能するのか」 の部分でした。

Claude Code Skillsの「使い方」を紹介する記事は増えてきました。でも「作り方の型」——状態をどこに持たせるか、モードをどう分けるか、指示をどう構造化するか——を書いた記事は意外と少ない。この記事では、複数のSkillを自作してきて手に馴染んだ4つの設計パターンを、コピペできる形でまとめます。面接ドリルは、その型を当てはめる事例のひとつとして最後に触れます。

前提：Skillは「賢いプロンプト」ではなく「小さなアプリ」

まず認識を合わせておきます。Skillを「便利なプロンプトの保存場所」だと思っていると、学習ツールとしては続きません。学習ツールはセッションをまたいで進捗が残る必要があり、出題・採点・復習でAIの振る舞いを変える必要があり、しかも指示が肥大化しがちだからです。

つまりSkillは、状態管理・モード分岐・情報設計を持つ小さなアプリとして設計するのが正解でした。最小構造はこれだけです。

---
name: interview-drill
description: >
  技術面接の想定問答を出題し、回答を採点し、弱点だけを復習させる学習ツール。
  Usage: /interview-drill [start|grade|review]
---

# /interview-drill — 面接ドリル

あなたは経験20年の技術面接官です。以下の手順で学習を進めます。
（本体はここから。詳細は後述の「段階的開示」で薄く保つ）

description は「どういう時に呼ばれるか」をAIが判断する材料になるので、トリガーとUsageまで書いておくのがコツです。ここから4つのパターンを重ねていきます。

パターン1：状態は「Markdownの台帳」に外部化する

学習ツールの心臓部は状態管理です。「前回どこまでやったか」「何を間違えたか」が消えると、ただの一問一答で終わります。

私が最初にAIエージェントを組んだとき、セッションが途切れるたびに文脈を思い出せず、毎回ゼロから説明し直していました。そこで、セッション終了時に引き継ぎメモ（handoffファイル）を自動生成し、進行中タスク・保留事項・次のアクションを構造化して保存する仕組みを入れたところ、再開時の文脈復元が5秒で終わるようになり、「前回どこまでやったっけ？」のやり取りがゼロになりました。このとき学んだのは、AIの「記憶」はファイルシステムに外部化するのが現実解だということです。

学習ツールも同じで、状態はDBではなく1枚のMarkdown台帳に持たせます。これはCLAUDE.mdを「AIへの引き継ぎ書」として設計してきた感覚と地続きです。人間の新人向けドキュメントと同じ粒度で書くと精度が上がる、という経験がそのまま効きます。

<!-- .drill/progress.md — 学習台帳（Skillが読み書きする） -->
# 面接ドリル進捗

## 出題済み・成績
| 日付 | 分野 | 問題 | 自己採点 | 弱点タグ |
|------|------|------|---------|---------|
| 07-20 | DB設計 | 正規化の目的は？ | 3/5 | #正規化 |
| 07-21 | 非同期 | レースコンディションとは | 2/5 | #並行制御 |

## 復習キュー（採点3以下を自動蓄積）
- #正規化：第3正規形まで説明できる状態を目標
- #並行制御：楽観/悲観ロックの使い分け

ポイントは、台帳の「列」を先に決めること。 弱点タグの列があるからこそ、後述の復習モードが成立します。状態の設計がツールの機能を決めます。

パターン2：1つのSkillに「モード」を持たせて分岐させる

出題・採点・復習を別々のSkillにすると、台帳の読み書きが分散して壊れやすくなります。1つのSkillに引数でモードを渡し、内部で分岐させるのが管理しやすい形でした。

## モード分岐

- 引数なし / `start` → **出題モード**：台帳の弱点タグを優先して1問出す
- `grade` → **採点モード**：直前の回答を5段階で採点し、3以下なら復習キューに追加
- `review` → **復習モード**：復習キューから1つ選び、解説→再出題

> 各モードの実行後、必ず `.drill/progress.md` を更新すること。

分岐で効くのが、モードごとの採点基準を具体例で固定することです。以前AIにコードレビューを頼んだとき、指摘の粒度がバラバラで、些細なスタイル指摘と重大なバグが同列に並んでいました。そこで重要度（Critical/Warning/Info）の分類基準をFew-shot例として3パターン添付したところ、出力が整理され、確認時間が半分になりました。学びは明快で、ルールを文章で書くより、具体例を3つ見せる方が制御が効くということ。採点モードにも同じ手を使います。

## 採点モードの基準（Few-shot）

- 例1：定義を正確 + 具体例あり + トレードオフに言及 → 5
- 例2：定義は正しいが具体例なし → 3
- 例3：キーワードは出るが説明が誤り → 1

パターン3：段階的開示（progressive disclosure）で本体を薄く保つ

Skillは放っておくと肥大化します。以前CLAUDE.mdが500行を超えたとき、応答が遅くなり指示の優先度も曖昧になりました。ルートには方針だけ、詳細はサブファイルに分割し、最優先の制約だけ冒頭にIMPORTANTで書く——この階層化で応答速度が体感1.5倍になり、規約違反も減りました。

Skillでも同じ情報設計を使います。SKILL.md本体は「手順の骨格」だけにして、分野別の問題バンクや詳細な採点ルーブリックは別ファイルに逃がし、必要になった時だけ読み込ませる。これが段階的開示です。

skills/interview-drill/
├── SKILL.md            # 骨格（薄く保つ・50行以内が目安）
├── rubric.md           # 詳細な採点ルーブリック（採点モードで参照）
└── banks/
    ├── db.md           # DB設計の問題バンク
    └── concurrency.md  # 並行制御の問題バンク

<!-- SKILL.md 内 -->
出題する分野が決まったら、対応する `banks/{分野}.md` を読み込んでから出題する。
採点時は `rubric.md` の基準に従う。

本体を薄く保つと、AIが毎回全文を抱えずに済み、判断がぶれません。「全部を最初に読ませない」設計 が、そのままツールの安定性になります。

パターン4：段階を踏ませて、いきなり結論を出させない

最後は振る舞いの型です。学習ツールで一番やってはいけないのは、AIが問題文と模範解答を一気に出してしまうこと。これでは学習になりません。

これは、レガシーコードのリファクタリングをAIに任せたときの学びと同じでした。約1万行のコードを、いきなり書き換えさせずに「まず構造分析→依存関係マップ→段階的に分割」と手順を踏ませたら、3,500行まで圧縮しても既存テストが全部通りました。AIは淡々と一括処理してしまうので、こちらが段階を区切る必要があります。学習ツールでは、この「段階を区切る」をSkillのルールとして明文化します。

## 進行ルール（重要）

1. 出題したら、**解答を出さずに** ユーザーの回答を待つ
2. 回答が来たら採点し、**まずヒントだけ**返す
3. ユーザーが「答えを見る」と言った時だけ模範解答を提示する
4. 一度に複数問を出さない（1問ずつ完結させる）

実例：面接ドリルに4パターンを当てはめる

ここまでの4つを重ねると、冒頭の「面接の壁打ち相手」は次のように組み上がります。

台帳：progress.md に成績と弱点タグを蓄積（パターン1）
モード：start / grade / review で出題・採点・復習を分岐（パターン2）
段階的開示：分野別の問題バンクを必要時だけ読み込む（パターン3）
進行ルール：1問ずつ、答えを急がせない（パターン4）

面接ドリルはあくまで一例です。同じ型は「英単語の間隔反復」「設計レビューの練習」「資格試験の過去問演習」など、状態が残り・モードで振る舞いが変わる学習ツール全般にそのまま流用できます。

ハマったこと：台帳の更新を「毎回」と書かないと消える

一番の落とし穴は、台帳の更新をAIが忘れることでした。出題や採点に気を取られて、progress.md の書き込みをスキップしてしまう。結果、次のセッションで進捗が空になっている、という事故が最初の数日で何度か起きました。

対策はシンプルで、各モードの手順の末尾に「必ず台帳を更新する」を明示し、可能ならHooksで変更を機械的に検知する。AIの行動に自動チェックポイントを設けておくと、書き込み漏れの見逃しがゼロになります。「言わなくても分かるだろう」は通用しない、が教訓でした。

チートシート：学習ツールSkillの設計4パターン

パターン	何を決めるか	実装の勘所
①状態＝Markdown台帳	進捗・弱点をどこに残すか	列（スキーマ）を先に設計。DBでなく1枚のMDで十分
②モード分岐	出題/採点/復習の切替	引数でモード。実行後に必ず台帳更新
③段階的開示	本体をどう薄く保つか	骨格だけSKILL.md、詳細は別ファイルへ逃がす
④進行ルール	AIの振る舞いの制御	1問ずつ・答えを急がせない・段階を区切る

Skillは「賢いプロンプト」ではなく「小さなアプリ」——この視点に切り替えると、学習ツールに限らず、自分専用のツールがぐっと作りやすくなります。まずは1枚の台帳と2つのモードから始めるのがおすすめです。

この記事が参考になったら、いいね・ストック していただけると励みになります。

Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー しておくと新着が届きます。

みなさんは、どんな「自分専用の学習ツール」をSkillにしてみたいですか？ぜひコメントで教えてください。

関連記事