「技術面接の壁打ち相手を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にしてみたいですか？ ぜひコメントで教えてください。