はじめに
先日、Xで技術面接の質問集を紹介するポストが流れてきました。
「SQLインジェクションが発生する仕組みと対策を説明してください。」
「TypeScriptにおける anyと unknownの違いと、それぞれをどのような場面で使うべきか説明してください。」
眺めてみると、なんとなくは分かるんです。
でも「面接官の前で、自信を持って口頭で説明できるか？」と自問すると、答えられる問題が思ったより少ないことに気づきました。
思い当たる節はありました。
AIが進歩したおかげで、この手の知識はAIが出してくれた説明に「そうだよな」と頷いて確認することが増えています。
分かった気にはなるけれど、自分の記憶に定着しているかは正直怪しい。
そこで、システム開発の基礎的な考え方を定着させるために、Claude Codeのスキルとして技術面接の壁打ちスキルを自作しました。
名前は「engineer-drill」です。ネーミングセンスのなさは自覚しているので、そっとしておいてください笑
この記事では、engineer-drillでできること・使い方・仕組みを紹介します。
ターゲット
対象読者は幅広く想定しています。
- 基礎を固めたい初学者の人
- 転職活動中で技術面接の対策をしたい人
- AIになんとなくの実装を任せてしまっていて、知識の定着に不安がある人
問題バンクは差し替え前提の作りなので、自分の分野に合わせて問題を変更して使ってみてください。
engineer-drill でできること
やることはシンプルで、「出題 → 自分の言葉で回答 → 採点 → 模範解答」のサイクルを回すだけです。
実際のやりとりはこんなイメージです。
AI: 【FE-001】useStateとuseRefの使い分けについて、
それぞれの特性を踏まえて説明してください。
自分: useStateは値が変わると再レンダリングされて、
useRefは変えても再レンダリングされない…。
あとuseRefはDOM要素を参照するときに使います。
AI: 採点: ◯
カバーできた観点: 再レンダリングの発生有無 / DOM参照用途
抜けた観点: レンダー間で値が保持されるという共通点
（抜けた観点を中心に解説が続く）
回答は選択式ではなく、自分の言葉で書きます（口に出しながら書くとより面接っぽくなります）。
そして採点のあとに出てくる模範解答が、このスキルの推しポイントです。
知識の箇条書きではなく、面接官に向かって30〜60秒で話せる「話し言葉」の形で提示されます。
模範解答（例）:
「useStateは値の変化をUIに反映したいときに使います。
値を更新すると再レンダリングが走るためです。
一方useRefは、再レンダリングを起こさずにレンダー間で値を保持したいときや、
DOM要素への参照を持ちたいときに使います。
たとえばフォームのinputにフォーカスを当てる処理では…」
技術面接で問われるのは、知識そのものよりも「口頭で筋道立てて説明できるか」です。
知っているのに話せない、を潰せるのがこのスキルの狙いです。
問題バンクは、Markdownで差し替えられる作りです。
そのため、自分の分野に合わせて中身を入れ替えて使ってみてください（差し替え方は後述します）。
Ankiではなくスキルにした理由
最初は、暗記アプリの定番であるAnki（忘却曲線に沿って復習間隔を調整してくれるフラッシュカードアプリ）を使おうと考えていました。
でも、いざ使う場面を想像すると引っかかりました。
カードをめくって「思い出せた / 思い出せなかった」を記録するだけでは、理解を深めたいときに物足りないんです。
私が欲しかったのは次の2つでした。
- 自分の言葉で回答して、それを採点してほしい
- 腑に落ちないところは、その場でAIと壁打ちして納得してから次に進みたい
「◯◯の場合はどうなるんですか？」と聞き返せる相手がいる勉強と、一方通行のカードめくりでは、定着のしかたが違います。
この2つを満たせるのはClaude Codeのスキルでした。
そこで、Ankiの良いところ（忘却曲線ベースの復習）だけを設計に取り込んで、スキルとして作ることにしました。
使い方
インストール
npxでインストールできます。
npx skills add takuya-38/claude-skills --skill engineer-drill
リポジトリはこちらです。
スキルをnpxで共有する仕組み自体は、以前の記事で紹介しています。
初回セットアップ
初回だけ、2つの質問に答えます。
- 使っている言語・フレームワークと経験年数（例: Next.js/React + RailsAPI、実務2年）
- わからなかったときの扱い（すぐ解説してほしい / ヒントをもらって粘りたい）
回答は profile.md に保存され、以降の解説の深さや粘り方が自分に合わせて固定されます。
毎回自分の前提を説明し直さなくていいのは、スキル化ならではのメリットです。
出題モード
目的に応じて4つのモードを選べます。
| モード | 使いどころ |
|---|---|
| ランダム | 全分野からまんべんなく。日々の素振りに |
| 分野選択 | フロントエンドだけ、と集中して固めたいとき |
| 復習 | ✕や△だった問題を優先して出し直してもらう |
| 模擬面接 | 4分野から1問ずつ、途中の解説なしで通し。本番前の腕試しに |
モードを選んだら、あとは1問ずつ「出題 → 回答 → 採点・解説・模範解答」を繰り返すだけです。
n と打てば次の問題に進みます。
納得いかないところがあれば、次に進まずそのまま壁打ちに付き合ってもらえます。
記録が積み上がる仕組み
このスキルは「人は忘れる」という前提で設計しています。
1回解いて終わりではなく、記録を積み上げて何周も回すことで定着させます。
弱点分布が可視化される
採点結果は問題ごとに records/history.md へ記録されます。
| 問題ID | 最新評価 | 最終出題日 | 回数 | メモ |
|--------|----------|------------|------|------|
| FE-001 | △ | 2026-07-11 | 1 | 再レンダリングの説明は正確。DOM参照用途に言及なし |
メモには「前回どこで詰まったか」が残るので、次に同じ問題が出たとき、AIはそこを重点的に見てくれます。
毎回ゼロから壁打ちするのとの一番の違いはここです。
続けるほど、自分の弱点がどの分野に偏っているかも見えてきます。
忘れた頃に再出題される
採点は◎◯△✕の4段階で、評価が低い問題ほど早く復習候補に浮上します。
✕なら3日後、△なら7日後、◯なら14日後、◎なら30日後です。
エビングハウスの忘却曲線を意識した間隔で、「もう忘れたかな」というタイミングを狙って再出題してくれます。
このあたりは、Ankiから拝借した考え方です。
採点は最初の回答だけで確定する
地味なこだわりとして、ヒントをもらって正解にたどり着いても、採点は最初の回答のみで行います。
ヒント後に答えられた事実はメモに残りますが、評価には反映しません。
甘く採点してしまうと、記録が実力を反映しなくなり、復習すべき問題が復習候補から消えてしまうためです。
記録はすべてmdファイルに保存されるので、Claude Codeのセッションを /clear しても失われません。
もう一度「クイズ出して」と言えば続きから再開できます。
自分好みに育てる
問題バンクは questions/ ディレクトリ配下のmdファイルで、1問あたり数行のフォーマットです。
### FE-001: useStateとuseRefの使い分け
- 問題: useStateとuseRefの使い分けについて、それぞれの特性を踏まえて説明してください。
- タグ: react, hooks
- 難易度: ★☆☆
- 評価観点: 再レンダリングの発生有無 / レンダー間の値の保持 / DOM参照用途
評価観点は、AIが採点するときの基準になる論点です。
これを問題ごとに書いておくことで、採点がその日の気分でブレなくなります。
このフォーマットさえ守れば、問題の追加も分野の差し替えも自由です。
- Xで見かけた面接質問を、その日のうちに1問追加する
- RailsやGoなど、自分のスタックの分野ファイルを作る
- 資格試験の頻出論点を口頭で説明する練習に使う
私自身、このスキルはまだ作ってブラッシュアップしている最中です。
完成品を配るというより、お裾分けに近い感覚なので、ぜひ自分好みのスキルに育ててみてください。
最後に
AIの答えに頷くだけの毎日から、「自分の言葉で説明してみたら、思ったより話せなかった」に気づけたのが、このスキルを作って一番良かったことです。
話せなかった悔しさは、カードをめくって「覚えてなかった」と確認するより、ずっと記憶に残ります。
問題バンクはこれからも育てていく予定です。
「こんな問題を入れたら良かった」「こう改造して使っている」という知見があれば、ぜひコメントで教えてください。
株式会社シンシア
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
弊社には年間100人以上の実務未経験の方に応募いただき、技術面接を実施しております。
この記事が少しでも学びになったという方は、ぜひ wantedly のストーリーもご覧いただけるととても嬉しいです！