はじめに
プログラマはAIに代替されると言われて久しいが、「じゃあどうやって学ぶか」という問いに対するひとつの答えを形にしてみた。
問題意識自体はずっとあったのだが、Xで見かけたあるポストがきっかけで一気に動き出した。
構想
そもそものきっかけはこのポストだ。
「むしろAIの書いたコードをレビューする試験をやればいいのでは…」
おもしろいと思い着手したのだが、「試験」を作るにはまず題材が必要になる。
とりあえずAIに何かを書かせてみることにした。
みんな大好き Hello World や ToDo アプリは規模が小さすぎて、なんかいい感じにしかならないので却下した。
じゃあ日頃の便利ツールを作らせてみてそれをレビュー…も、ツールとして動いていたら、それをレビューするモチベーションが全く湧かない。
あれこれ考えていたら、いつの間にか「試験」よりも面白いコンセプトに辿り着いた。
- 適当なECサイトをAIに作らせる
- ドキュメントは用意しない
- それに対してAIを使って機能追加をする
- その時に「何を考えるべきか」を設問にする
この方式であれば、保守開発案件に投げ込まれたエンジニアの追体験ができるのではないだろうか？
ドキュメントもなくなんだか分からないソースが渡され、曖昧な指示だけは出てくる。
それをAIを使ってなんとかこなす。
あたかも2026年の働き方ではなかろうか？
ここで、立ち止まって考えてほしい。AIが普及した今、「フロントエンドができる」「この言語が書ける」という個別スキルの価値は相対的に下がっている。求められているのはむしろ、「この開発案件をどう着地させるか」という大きな視点で動ける人間だ。立ち止まって考えられる人こそが、AIに置き換えられない人材となるのではないだろうか。
壁打ち
AIの書いたコードをレビューできるようになるには、最終的にはAI時代の自分なりのベストプラクティスを構築できることが必要だ。そこに向けては、結局膨大な量の学習と反復が避けられない。
それを「大変やりがいがあって面白い」と思い込まないと、長く続かないし身にもつかないのではないか。
…子供に嫌いなものをどうやって食べさせるか考えるお母さんの気持ちはこんなものかもしれないなと思いながら壁打ちを進めた。
ペルソナの明確化
- わたし:
> コードは読める、設計はあまり意識したことない
このあたりです。
SESで最も多いタイプだと思っていまして。
この層が今AIに取って代わられますと言われているけど、じゃあどこから手を付ければというところで困っているのかなと思いまして。
（そもそも業務指示以外で勉強するという概念がないというか、「動く」以上に「良い設計がある」という概念がないような）
- Claude Sonnet 4.6:
なるほど、かなりリアルな課題設定ですね。
この層の実態を整理すると
- 「動けばいい」が成立体験のすべて
- 設計の良し悪しを判断する体験をしたことがない（比較対象がない）
- 「勉強しよう」というモチベーション自体が発生しにくい
- AIが出したコードをそのままコピペして「できた」になる
つまり**「設計が悪い」という痛みを感じたことがない**、というのが根本かもしれないですね。
だとすると学習設計の鍵は「痛みの再現」
本来は運用・保守フェーズで初めて痛みが来るんですが、そこまで経験が回ってこない人も多い。
ここでいう「設計が悪い」とは、難解なアーキテクチャパターンの話ではない。命名や細かい実装はAIが上手くやってくれる。問題は、PoC的にAIへ指示し続けると、規模に合わない設計のまま無計画に肥大化していくことだ。「このコードは保守できるか」という視点が持てるかどうか、それがここで問われていることだ。
もう一点、保守案件で入ると、スキルレベルも所属会社もバラバラな多くの人が無秩序に増改築したソースに出会う。それを「もともとこういうものだ」と受け止めてしまうのも、設計の痛みを感じていない状態のひとつだ。問題のあるコードを問題として認識できること——それがスタート地点になる。
座学 vs 実践
- わたし:
座学といったり来たりがいい気もしている気がするのですが、そこらはどうですかね？
（必要な基礎力なしで課題に取り組んでも全く何もできない）
- Claude Sonnet 4.6:
まず座学との行き来について考えを整理しますね。
「詰まり方」で2パターンある気がして
- 概念が全くない状態で詰まる → 座学が先に必要
- 概念はあるけど使い方が分からなくて詰まる → 課題が先でいい
今回の対象層（設計の概念がほぼゼロ）だと、完全に課題ファーストだと「何をしていいか分からない」で終わる可能性があって。
ただ座学を先に置くと「つまらなくて離脱」になる。
この分析を踏まえ、座学と実践が自然に行き来できる構成を意識して設計した。
試作
ここまでコンセプトが決まれば後は簡単だ。
このコンセプトをAI(Claude Sonnet 4.6)に伝えたところ、「いい感じに問題があるECサイト」を一瞬で作ってくれた。
これに対して問題もサクサクと作ってくれた。
思想：ランディングページ
いつの頃からか Claude Sonnet 4.6 のデザイン力が飛躍的に向上したと感じている。
であれば、一見キレイなランディングページも作るのがいいだろう。
ニンジンを食べたくない子供も、シチューの中に入っていたら美味しく食べられるだろう。
『この教材にそって学習すればなにか出来るようになる気がする』という思い込みが大事だ。
なんだか怪しい情報商材のようだが、無料なので安心してほしい。
AIに真っ先に駆逐されると言われているSES業界に残る人間には、前向きに課題に取り組んでもらい、ゆくゆくは自分で課題設定をして道を切り開いていってもらいたい。
思想：チュートリアル
AIレビュー力試験ツールを作ろうから始めたせいもあるが、チュートリアルを最初に配置しなかった。
これは、SES案件を再現してみようという試みからだ。
自分のスキルセットに関係なく案件は決まる。
ソースだけ渡されてあとよろでできる、いわゆる「一人称で動ける人」にはチュートリアルは不要だろう。
SESの求人は「一人称で動ける人」ばかりになっているのでそこを目指さなければ生存はできない。
ランディングページの奥まったところや、クローンしたリポジトリのファイルを隅々まで確認した人はチュートリアルにたどり着けるだろう。
たどり着いたチュートリアルは「仕様書がないなら自分でAIを使って作ればいい」という内容になっている。
設問よりもこの体験自体で、SES開発案件で必要になる考え方を学べる設計としてみた。
思想：ログイン
とりあえずサンプルサイトを立ち上げて動かしても、ログインユーザーとパスワードが分からないと思う。
本来であれば、案件の誰かに聞いて解決してほしいところだが、この案件は実在しない。FAQにヒントを書いておいたので、そちらを一読してほしい。
おわりに
「むしろAIの書いたコードをレビューする試験をやればいいのでは…」
こういうものにはならなかったものの、割と有用な学習リソースができたと思う。
業界の外にいる「未経験からエンジニア」を目指している人にも、業界がどんなものかを垣間見る一助となったらうれしい。
最後に重要な事実を書いておきたい。
この学習リソース全体とランディングページは、Copilot (Claude Sonnet 4.6) によって1日かからずに制作できたものだ。
2026年現在、エンジニアに求められている生産性というのはそのようなオーダーのものだということは知っておくべきだろう。
今回、Claude は良いコードも悪いコードも理解した上で悪いコードを書いてくれた。
AIが学習したビッグデータの中には良いコードも悪いコードもあり、使う人間の指示が悪ければ、悪いコードを書いてしまうということが分かる。
また、良いコードはプロジェクトの内容や規模によって異なり、必ずしも正解は一意ではないと感じている。
「今回のプロジェクト」に対して最適解をAIに伝えるのは人間の仕事として残るのではないかと思う。
この課題を完走できた人は、ぜひ自分で課題を設定して次に進んでほしい。それができるなら、もはや駆け出しでも指示待ちのエンジニアでもない。完走できなかった人は、まずそこを目標にしてほしい。類似の教材による反復については、需要があれば検討するつもりだ。
学習をしている方、メンターまたは採用者の方、興味がわいたら覗いてみてほしい。