はじめに
AIにコーディングを任せ始めたけれど、「自分の実装力が育っている実感がない」と焦っている若手・駆け出しエンジニア向けの記事です。
この記事を読むと、AIにコードを書いてもらいながらも、自分の「読める・書ける」を落とさないための学習ループが分かります。私が実際にやってみて手応えのあったやり方を共有します。
特別な前提知識はいりません。コード例は TypeScript ですが、考え方はどの言語でも同じです。
この記事の流れ
- 担当レイヤーが、1段上がった — AI時代に人間の仕事がどう変わったか
- 問題：設計を判断する基準は、コードを書ける土台の上にしか育たない — なぜ土台を落とせないのか
- やり方：業務の一部を切り出し、AIに「順番をコメント化した教材」を作らせる — 学習ループの3ステップ
- AIは、仮説を持って使う — 丸投げと何が違うか
- 実例：手で書く練習場を1つ作った — フォルダ構成つき
担当レイヤーが、1段上がった
最近、自分の仕事の感触が変わったと感じています。実装はAIがかなりの部分を書いてくれて、人間は「何を作るか」「どう組み立てるか」を考える側に回る。担当するレイヤーが、実装から設計へ1段上がった感覚です。
これ自体は良い変化だと思っています。ただ、ひとつ引っかかることがありました。
設計の良し悪しを、自分はちゃんと判断できているのだろうか？
問題：設計を判断する基準は、コードを書ける土台の上にしか育たない
AIが出してきた設計や実装を見て「これでいい」と思う。でもその「いい」は、何を基準にした「いい」なのか。
ここで気づいたのは、設計の良し悪しを判断する基準は、自分でコードを読めて書ける土台の上にしか育たないということです。
なぜこの関数はこう分割されているのか。なぜここでループではなくこのメソッドなのか。それを「自分なら書ける」レベルで分かっていないと、AIの出力に対して「なんか良さそう」以上の判断ができません。基準が自分の中にないと、AIに同意しているだけで、レビューしているつもりがレビューになっていない。
レイヤーが上がったからこそ、土台の「読める・書ける」を落とすわけにはいかない。ではどうやって、AIに任せながら土台を保つのか。私がたどり着いたやり方を書きます。
やり方：業務の一部を切り出し、AIに「順番をコメント化した教材」を作らせる
ポイントは3つです。
- 業務で出てくる処理を、部分的に切り出す
- AIに「実装の順番をコメントにした教材」を作らせる
- 人間がステップごとに、手で書く
順に説明します。
1. 業務の一部を切り出す
題材は、自分が普段の業務で触っている処理から持ってきます。教科書の練習問題ではなく、実際に意味のある処理の一部を切り出すのがコツです。「これは何のためにやるのか」が腹落ちしているぶん、頭に残りやすい。
たとえば私の場合は「あるリストの中から、特定の条件に当てはまる項目だけを拾って、重複なく集める」というよくある判定処理を1つ取り出しました。
2. AIに「順番をコメント化した教材」を作らせる
ここがこのやり方の肝です。AIに完成コードを書かせるのではなく、**実装の順番だけをコメントにした「穴あきの教材」**を作らせます。
// ===== Step1: データを定義する =====
// 1件のデータが持つフィールドを type で定義し、サンプル配列を用意する
// ===== Step2: 条件に合うものだけ残す =====
// 配列から条件に一致した要素だけを残すメソッドを使う
// ===== Step3: 必要なフィールドだけ取り出す =====
// 配列を別の形に変換するメソッドを使う
// ===== Step4: 重複を消す =====
// ===== Step5: Step2〜4 を1つの関数にまとめる =====
AIには「答えのコードは書かないで。やる順番と、各ステップで何をするかのヒントだけコメントで書いて」と頼みます。こうすると、地図はもらうけど、歩くのは自分という状態が作れます。
3. ステップごとに、手で書く（コピペしない）
あとは、コメントの指示に沿って1ステップずつ自分で書きます。ルールはシンプルです。
⚠️ AIが書いたコードはコピペしない。見ないで自分で打つ。 詰まったら、答えではなくヒントをもらう。
これは「写経」とは少し違います。写経は手本を見て書き写すことですが、ここでやりたいのはこれから実装する処理を、自分の手で再構成して理解することです。手が止まったところが、自分が分かっていないところ。そこだけAIにヒントを聞けば、ピンポイントで穴が埋まります。
実際、私はStep2で「条件に合わないものを削除しよう」とループを書いて手が止まりました。調べると、削除ではなく「条件に合うものを新しい配列に詰めて返す」メソッド（filter）を使えばいいと分かった。手で書いて詰まったからこそ、「なぜループで削除しないのか」まで理解が残りました。AIに最初から完成形をもらっていたら、この理解は素通りしていたはずです。
AIは、仮説を持って使う
もうひとつ大事にしているのが、AIに丸投げしないことです。
「これやって」ではなく、「たぶんこうだと思うんだけど、合ってる？」と自分の仮説を持って聞く。
| ❌ 丸投げ | ✅ 仮説を持つ |
|---|---|
| この処理書いて | ループで削除しようとして詰まった。配列から条件で絞るのは別の方法がある気がするけど何？ |
| エラー直して | この型エラーは、戻り値の型と返してる値が合ってないからだと思う。合ってる？ |
仮説を持って聞くと、返ってきた答えが「自分の予想とどう違ったか」という差分で頭に入ります。差分は記憶に残る。一方で丸投げすると、答えだけが手元に残って、理解は自分の外を通り過ぎていきます。同じAIを使っても、仮説の有無で残るものが全然違いました。
特に気をつけているのが、エラーや「出力が期待値にならない」場面で、内容をそのままAIに貼って終わりにしないことです。これが一番やりがちで、一番もったいない。詰まった瞬間こそ、自分の頭で「なぜこうなった？」を考える絶好のタイミングだからです。
ここでコピペに逃げると、実装の理解が育たないだけでなく、問題解決の思考そのものが育ちません。「どこが怪しいか」「何を試せば切り分けられるか」を自分で立てて、その仮説をAIにぶつける。仮説が当たっても外れても、その思考プロセスが血肉になります。私が鍛えたいのは、実装の理解だけでなく、こういう詰まったときに自力で前に進む思考力のほうです。
実例：手で書く練習場を1つ作った
このやり方で、業務の判定処理を1つ題材にした小さな練習場を作りました。フレームワークも設定ファイルも全部はがして、node 1コマンドで動くだけの最小構成です。
フォルダ構成はこれだけです。
practice/
├── README.md # AIに作らせた「お題」＝何を作るか・実装の順番
├── index.ts # README の順番に沿って、自分の手で書くファイル
└── LEARNING_LOG.md # 書いた処理を自分の言葉で説明 → AIに添削してもらう記録
node_modules も package.json もありません。node index.ts だけで動きます。環境構築でつまずいて学習が止まるのを避けたかったので、あえてここまで削りました。
役割は3つに分かれています。
- README.md … AIに作らせた教材。何を作るか（お題）と、実装の順番が書いてある
- index.ts … README の順番に沿って、自分の手で1ステップずつ書くファイル
- LEARNING_LOG.md … 書いた処理を「なぜこう書くか」自分の言葉で説明し、AIに添削してもらう記録
最後の LEARNING_LOG.md が地味に効きます。書けても説明できないものは、まだ理解できていない。説明しようとして詰まると、分かったつもりだった箇所があぶり出されます。
まとめ
AIがコードを書いてくれる時代でも、土台の「読める・書ける」を落とすと、上がったはずの設計レイヤーで足元が崩れます。今回試した学習ループはこうでした。
- 業務の処理を部分的に切り出す
- AIに「順番だけコメント化した教材」を作らせる
- 自分の手で1ステップずつ書く（コピペしない）
- AIは仮説を持って使い、丸投げしない
AIに任せる部分と、自分で握り続ける部分を分ける。そのための小さな練習場を1つ持っておくと、安心してAIに頼れるようになります。皆さんも、業務の処理を1つ切り出して試してみてください。