はじめに
最近、私には悩みがあります。
コーディングAIを使うようになってから、逆に新しい知識が身につかなくなったんです。
AIはとても便利で、エラーが出たら治してくれるし、私に分からない実装でもすぐ書いてくれます。
おかげで開発は相当速くなりました。
でも後から振り返ると 自分は今日何を理解したんだっけ？ となっちゃうんです。
この「動くものはできているのに、自分の中には何も残っていない……」という虚しさが分かるでしょうか？
とはいえ、いまさらAI なしの開発に戻る気はありません。
アウトプットに差が出すぎてしまいますからね。
そこで考えたのが今回の方法です。
AI を「OJT の先輩」にする！！
OJTは新人が現場で教えてもらいながら仕事を覚えるアレです。
あの OJT を AI で再現する、というのが今回の話です。
しかも先輩はAIなので退屈な作業や時間のかかるところは引き受けてくれて、自分は "おいしい経験"だけ持っていけます。
つまりこれは速度を捨てずにちゃんと身につくというやり方です。
近頃の私はそういう学び方を、実際に SaaS を 1 本作りながら回しています。
OJTの流れ
細かい話に入る前に、全体像をざっと出しておきます。
進め方はこの 5 ステップです。
- 作りたいものを決める — 何を作るか。どんな技術を学びたいか
- 設計を決める — 技術スタック・データ構造・分離方針などの大枠
-
全体設計ができたら、指示書に分解する — Sprint を「1 タスク = 1 PR」の作業指示書に割る（これは
sprint-planというスキルにしてある） -
指示書に従って、質問+理解を確認しながら作業する — 伴走モードで 1 手順ずつ（これは
pair-startというスキル） - レビューしてもらう — 書いたコードを AI にレビューさせてから PR を出す。指摘でまた学べてうれしい
1と2はAIと相談しながらでやるところで、ここ自体もおいしい経験です。（"上流"ってコト！）
ただこの記事の本題は3〜4の部分をどんなふうに回すか、というところになります。
なので以下ではなぜこの形にしたのかと、OJTの具体的な回し方について書いていきます。
再確認：なぜAIを使うと「身につかなくなる」のか
そもそも、なぜ AI を使うと学べなくなるのか。
理由はシンプルで、手を動かす量が減るからです。
人は、自分で書いて・詰まって・調べてようやく覚えます。
でも今はAI が全部肩代わりしてくれるのが流行りです。
ありがたいんですが、ここを飛ばすと記憶に残らないですね。
しかも厄介なのが丸投げは超気持ちよく進むことです。
エラーは即解決！ 実装は一瞬！ 方向性だけ確認してればどんどん進む！
進捗だけ見ると最高なので、学べていないことに気づきにくいです。
そして気づくと「動かせるけど説明できないコード」だけが増えていく。
OJT がちゃんと学べるのは、この逆だからです。
タスクを振られて、実装を自分でやり、先輩に確認をお願いする。
だから実際の知識が身につきます。
ならこれを AI との開発に持ち込めばいい、というのが発想の出発点でした。
ポイント①：おいしいところは自分、雑用は"先輩"に振る
今回の疑似OJT の肝は、何を自分でやって何をAIに任せるかの線引きです。
ここは基準 1 つで機械的に決めています。
「これどうやって作った？ と聞かれて、その場で説明できる必要があるか」
YES なら自分で書く。
NO なら AI に振る。
迷ったら自分で書く側に倒します。
後で「説明できないな」となるのが一番もったいないので。
私がOJTの題材にしているマルチテナントチャットボットの SaaS で言うと、こう分かれます。
自分でやる（＝おいしい経験）
- テナント分離をどう守るか（RLS の方針、JWT クレーム設計）
- ハイブリッド検索のランキング設計（BM25 とベクトルをどう混ぜるか）
- 起票先を抽象化する Adapter のインターフェース定義
- LLM に渡すプロンプトの設計
先輩（AI）に振る（＝雑用・時間泥棒）
- マイグレーション SQL や EF Core のエンティティクラスの量産
- CRUD フォームや CSS などの定型 UI
- 同じパターンのコードの複製
- CI の YAML や Dockerfile などの設定ファイル
設計判断や肝になるロジックは「おいしい経験」です。
我々はここに時間を使います。
一方、ボイラープレートや手数の多い作業は、うまみが少ないし時間だけ食う。
なのでここは迷わずAIに投げる。
こうすると学びたいところにだけ手を動かす時間を集中できるので、速度を保ったまま覚えるべきところは覚えられます。
ポイント②：コードは自分で書いて、先輩には質問だけする
自分でやると決めたところは、AI に書かせず質問だけします。
「書いて」ではなく「どう書くべき？」と聞く。
- 「この処理、どういう方針で書くのがいい？」
- 「ここでこう書いたんだけど、何か見落としてる？」
- 「この設計、選択肢それぞれの欠点は？」
- 「ここの処理の理解は○○をしてる、で合ってるんでしたっけ？」
答えのコードをもらうのではなく、考え方をもらう。
最終的にキーボードを叩くのは自分なので、手が動いてちゃんと残ります。
これがまさに OJT で、先輩は隣で口は出すけど手は動かさない、という関係です。
自分のお気に入りはVSCode の拡張機能（Claude Code）を開きっぱなしにして、書きながら聞く、を繰り返す感じです。
ポイント③：「最初の何個か」だけ自分で書く
おいしい経験と単純作業の中間にあるものには、もう一工夫します。
要は型をいくつかだけ自分で作って、残りは AI に複製させる。
いま実際にやったのが RLS ポリシーです。
テナント分離は漏れたら一発アウトなので、まず 1 テーブル分を自分で書いて、条件の意味を理解する。
そこまでやれば、残りのテーブルは「これと同じ方針で」と AI に複製させても、何が起きているか分かったままです。
スキルで仕組みにする（Webサイト実装を例に）
上記の①〜③を毎回指示するのは大変なので、Claude Code のスキルに落として仕組みにしています。
使っているのは自作の 2 つです。
sprint-plan — Sprint のゴールを「1 タスク = 1 PR」の粒度に割って、日次の作業指示書を生成する。
pair-start — その指示書からタスクを 1 つ選んで、伴走モードで 1 手順ずつ進める。
SaaS のテナント分離まわりを作った週を例にすると、流れはこうです。
まずはじめに「Sprint 1 の作業指示書を作って」とお願いする。
すると sprint-plan が 3 日分のタスクに割って、各タスクに 目的 / 手順 / 完了確認 / [自分]・[AI] の分担タグ を付けてくれます。
たとえば、具体的にはこんな割り方になります。
【タスク割りの例】
-
[自分]RLS ポリシーを knowledge_entries 1 テーブル分だけ書く -
[AI]残りのテーブルへ同じ方針の RLS ポリシーを複製する -
[AI]上記をかける migration SQL を生成する
タスク割りができたら「一緒に作業を始めよう」と言うだけです。
pair-start がタスクを出してきて、[自分] の担当の RLS ポリシーから 1 手順ずつ伴走してくれます。
ここで AI は答えを書かず質問に答えたり、レビューして導いてくれる役です。
1 テーブル分を自分で書き切ったら、残りのテーブルは [AI] タスクとして複製を任せる。
おいしい経験（RLS の設計）は自分、雑用（複製と SQL 量産）は先輩、がそのままスキルのレールに乗っている状態です。
環境構築の方法
特別なものは要りません。Claude Code とテキストファイルだけです。
実際に使っているファイルは下にリンクを貼ったので、そのまま中身を見られます。
- Claude Code を入れる（VSCode 拡張でも CLI でも可。でも書きながら話すのでvsCode拡張が楽）
- プロジェクト直下に
CLAUDE.mdを置く（技術スタック・禁止事項などの規約。AI が毎回読む土台になる） -
.claude/skills/sprint-plan/SKILL.mdと.claude/skills/pair-start/SKILL.mdを置く -
design/に設計メモと、生成された作業指示書（sprintN/dayX.md）を貯めていく
あとは「Sprint N の作業指示書を作って」「今日の作業始めよう」と話しかけるだけで回り始めます。
スキルの中身は普通の Markdown なので、使いながら「ここはもっとこう動いてほしい」と思ったら直せます。
この記事で出てくる工夫（後述の丸写しチェックなど）も、pair-start/SKILL.md を直接いじって入れています。
スキルの工夫点：指示書が「丸写し」になっていないか着手前に確認する
仕組みにして一番ハマったのがこれでした。
sprint-plan に任せると、たまに [自分] タスクの手順に答えのコードがそのまま書かれてしまう。
これだと、いざ pair-start で着手しても手順を上から写すだけ。
自分で書いているつもりで、やっていることは写経です。
OJT の意味がない。
そこで pair-start の着手前に 「丸写しチェック」 を 1 段入れました。
[自分] タスクを始める前に、AIが手順を読んで丸写しタスクになってないかを判定します。
- NG（丸写し） — 指示に処理の本体や SQL 全文が完成形で書いてある。打つだけで考える余地がない
- OK（伴走になる） — 指示はせいぜい型・シグネチャ・満たすべき条件まで。実装本体は自分が埋める前提
NG だったら着手させず、「この手順は答えが書いてあるので写すだけになります」と止めて、手順を方針レベルまで落とすか指示書を直す方へ倒します。
地味ですが、これがないと気を抜くと丸投げコーディングに戻るので、一番効いている工夫です。
やってみての感想
まだサイトは作成途中ですが、それでも実装中の感覚ははっきり変わりました。
以下のようないい手ごたえがあります。
- 手が動くので、ちゃんと覚えている — 自分で書いた RLS は、なぜその条件にしたかを今でも説明できる
- でも遅くない — 雑用は全部先輩に振っている + 質問しまくれるので速度は出せる
- 詰まらない — 分からなければその場で聞けるので、独学みたいに止まらない
「速いけど身につかない」と「身につくけど遅い」の、ちょうど間に着地できた感覚です。
ボイラーコード書いたりもいい経験ではあるので、損失がない訳でもないですが、AI時代の学習法としてはちょうどいい落としどころではないでしょうか。
いい感じなんでこの方法でどんどん新しいドメインの知識を身に着けていきたいですね。
おわりに
AI を使うと学べなくなる、というのは半分本当で半分は使い方の問題でした。
全部やってもらうから残らないだけで、AI を OJT の先輩にすると話が変わります。
退屈な雑用は先輩に振って、おいしい経験を取りにいける。
これをやると自分の中に知識がたまっていく感覚を取り戻せます。
AI を使い始めてから手応えがなくなった、と感じている人に、同じ悩みの抜け道として届けば嬉しいです。
それではまた。