「AIにコードを書かせて、画面を開いて、うん動いた。」
「これでいいか〜」で進めていっちゃう瞬間ってもう普通にめちゃくちゃあると思います。僕もAIを使って開発しているので、その感覚自体はめちゃくちゃ分かる。
ただSNSを見ていて感じたのが、未経験者や素人がものづくりに関心を持ってくれるのはすごく嬉しいんですが、
AIを使って作れるものは増えているのに、自分で説明できること、見抜けることができていない。「できるはず」なのにしていないケースが多い印象です。この状態のまま進むのは、ちょっと危ないです。
AI使うことの危険性を再認識
AIを使えていないから危ないんじゃないです。むしろ、多くの人はちゃんとAIを使っています（そう信じてます）。エラーを貼って、コードを書かせて、画面を作って、何回も修正している。時間もかけているし、頑張っていないわけではないはずなんです。
一番しんどいのは、これだけ頑張って作っているのに「このコード、何が正しいのか分かりません」「壊れたらまたAIに聞くしかありません」で「AIが解決できなくなった」で諦めてしまうことだと思います。
んで、ここで多くの人が何をするかというと、もっと新しいAIを探す、もっと強いプロンプトを探す、ハーネスやループの有力情報探す、もっとやばいのが「完璧全自動AIセット」を買ってくる...とかですかね。要するにAIのパワーアップに走ってるのが一定数います。
でも、それだけではあんまり状況変わってないんです。生成する量を増やす前に、出てきたものをどう見るかを変えないと、ずっと「動くけどよく分からないコード」だけが増えていきます。
AI時代に差が出るのは、コードを書く速さよりも、「これ、なんかおかしくないか」を見つけて、対応できるかだと思っています。
ここで言いたいのは、「もうコードを書かなくていい」とか、「AIを使うとダメ」とか、そういう話じゃなくて、
むしろ逆で、コードを読んで、直して、検証してきた経験があるからこそ、AIが出してきたもっともらしいコードに対しても「ちょっと待てぇ！」な判断ができるようにすることです。
自己紹介
こんにちは。現役8年目のエンジニア兼PMをやってる、やむぅ。です。
普段はWeb開発のPMをやりつつ、個人サービスを作ったり、プログラミングを教えたりしてます。
AIに任せて「動いた」だけを増やすと、あとで詰む
AIが出したコードを理解も検証もせず通す癖がつくと、作れるものは増えても、自分が受け持てる仕事の範囲は広がりにくいです。
僕が怖いのは、AIが間違えることそのものではありません。
間違っていても、何がおかしいか説明できないまま通ってしまうことです。
エラーを貼る。出てきた差分を貼る。動いた。また次へ進む。
これを繰り返すと、見た目上はいい感じにタスク進められます。でも自分の感触的には「AIに聞けば動く」というのだけで、「次に同じことが起きたら、どこを見ればいいか」という判断材料が把握できないままなんです。
とはいえAIを使うなではないです。僕も使っていますので。
AIに任せるほど、自分の役割は「出てきたものを通す人」になりがちですが、「何を確かめるべきかを決める人」に変わってきます。じゃないと、作れるものだけ増えて、自分では判断できない状態が残ります。
要するに「君じゃなくてもよくね？」状態です。
IPAも、AIの活用場面として要件定義、コード生成、レビュー、テストを挙げています。だからこそ僕は、AIの出力をそのまま採用せず、目的と挙動を確かめる側の力がますます大事になると感じています。
コードを書けることは、今でも大事な土台
コードを書く経験は、AIの出力を読む・直す・確かめるための語彙を増やすので、今でもちゃんと重要です。
AIに「ログイン画面を作って」と頼めば、それっぽいものはかなり速くできちゃいます。なんなら10秒ぐらいでできちゃうんじゃないでしょうか。しかも作りでコンポーネントもバリデーションも見た目も、最初からそこそこ整っていることが多いです。
でも、そのコードを見て「何をしているか分からない」「なぜこの書き方なのか理解できない」となったら、困るのはそれに修正が必要になったときです。
例えば、エラーが出た、仕様が変わった、別の画面に影響が出た、チェック時「この操作、できないんですけど」ってなった。
そうなった時にAIへ丸投げするのも一つの手ですが、何が起きているかを自分で追えないと、AIの次の提案も評価できません。最悪、「別の操作、できないんですけど」と無限ループするかも。
僕が言いたいのはAIが来たから「書く力なんていらない」というわけではないです。ただし自分で作って、うまくいかなくて、調べて、直して、他にも「この分岐、ちょっと怖いな」「この変更、他も見ないと危ないな」が感じるレベルは必要だ、ということです。
「なんかおかしい」を言葉にできる
コードレビューで「なんかおかしいですね」だけ言われても、直す側は困ります。それはAI側から見てもおんなじことで、具体的に何をどうしたいのかを明確にしないと直せるもんも直せません。
エラーが起きた時にどんな指示を出すことができるか、曖昧でなく的確な指示を出せるかどうかが重要です。
例えばバグが起こった時、僕が大事だと思っているのは違和感をこんな順番で紐解いていくことです。
- 本来は、何が起きるはずだったか
- 実際には、どんな条件で何が起きるのか
- なにで困っているのか
- 何を見れば確かめられそうか
- どこをどう変えればいいのか
たとえば「注文ボタンを連打すると二重注文になりそう」というケースが実際の仕事で出てきたりもします（あったら大問題ですが...）。
「連打されたとき、同じ注文リクエストが二回送られるかもしれない。利用者には二重に注文した認識がなくても、店舗側では二件入る。本来は...」
このように考えていくと、指示が単なる感想とか思ったことじゃなくなるので具体性のある指示が出せます。
僕はこうやるやつを勝手に『違和感の翻訳力』だと思っています。
AIがコードを出す速度が上がるほど、この翻訳力の価値は上がるはずです。出力が速ければ速いほど、チェックしないまま混ざるものも増えるからです。
開発現場で見るのは、コードのきれいさだけじゃない
実際の仕事では、コードが動くだけが仕事じゃないです。目的・既存設計・テスト・運用と整合し、チームが安全に変え続けられて初めて品質になります。
「可読性が大事」とよく言われますが、ただ見た目がきれいという意味ではないです。
次に直す人が、これは何のための処理か読める。変更したらどこに影響が出そうか判断できる。テストがあって、ぶっ壊したときに気づける。そういう状態のことです。
コードは、自分だけが読めればいいものでは断じてありません。他メンバーが見て、なぜそう書いたかを追えないコードはいくらちゃんと動いていても今後の負債になります。
AIが提案した実装を見て、僕なら最低でもこのあたりを確認します。
- 目的に合っているか: 依頼された機能もそうだが、全体ルールや大枠の仕様にて満たしているか
- 例外でも壊れないか: 空入力、失敗時、権限など、正常系以外を通しているか
- 既存と矛盾しないか: 既存の設計、命名、APIの約束、他の画面と食い違っていないか
- チームで保守できるか: 意図を説明できるか。理解しているか。テストできるか。半年後でも読める自信あるか
- 余計なことをしていないか: 不要な依存関係、存在しないAPI、関係ないファイルの変更など
特に最後は重点的に見ます。たまにいらんことする時があるので。
AIは、頼んでいない変更まで親切そうに入れてくることがあります。しかもぱっと見は筋が通っているのでそのまま通したくなる。
また、テストが通ったことも大事です。でも、テストが通ったことは「今あるテストを通った」というだけで、目的に合っている証明まではしてくれません。
GitHubの公式ガイドでも、AI生成コードは動作確認だけでなく、要求・設計との適合、品質、依存関係、AI特有のもっともらしい誤りまで確認する流れが案内されています。
これはAIを疑って使うというより、人が書いたコードにも同じように向き合う話です。AIによって実装量と速度が上がったぶん、確認が必要な場面も増えた、くらいに考えています。
未経験者にしてほしい練習
生成物の確認・レビューの練習をしよう
ただ、完璧にレビューしようとしなくて大丈夫です。AIで作るたびに確認、ググったりして調査、予測して、試して、というように効率は落ちますが「自分でも把握できてる」範囲を増やせるようにしましょう。
具体的には、
生成前にちょい書き
AIに頼む前に、メモとかでいいのでこれを書いておく。
- 何ができれば成功か
- 何を守るべきか
- どう構築・組み立てるか
たとえばログインなら、「利用者が自分のアカウントに入れる」「間違ったパスワードで入れてはいけない」「入力欄からjsで〜」です。
この予想をつける癖をつけていくと構築のイメージが掴めるようになります。
正常系以外を一つだけ試す
代表的なものだと空入力を試す。思い浮かぶもの全てを最初から全部できなくてもいいので、一つだけ選んでAIを困らせてみるみたいなのをしてください。
「普通に使えば動く」はみんなできるけど「想定外の動きする可能性もある」を考慮できなくてはならないのがエンジニアリングです。
AIの出力を自分で説明してみる
AIがどんなことしたのかを把握できるようになる練習です。
「今回何が目的で、どんなことを考慮して、こんなことを実装した」を自分の言葉で100字くらいで要約してください。
説明できない場所があったらそこの要素を調べたり勉強してください。
もっと理解力をつけたい場合は「このコードを行ごとに解説して」をするんじゃなく「この実装が壊れる条件を三つ出して」「この処理の要点は何？」と聞いてみてより掘り下げてみると、かなり理解力が身になりやすいなと思っています。
AIを使いながら、自分の判断を増やす
目指すのはAIを使わないことではなく、AIの出力をそのまま採用せず、自分の予測と検証を一つずつ増やすことです。
AIがコードを書けることを不安に思う人も多いと思います。
でも、大事なのはAIの出力によって自分の判断を減らすのではなく、毎回一つずつ増やすことです。
自分の判断を減らしてもいいのはもっと先の話だと思います。
それより大事なのは、何を作るのかを考える、やったことにより困るかを想像する、動かなかった理由を調べる、直した結果を確かめる、次に直す人が困らないように残す、です。
つまりAI使ってコードを出す速度を上げることを目指すのではなく、出力を自分で理解できるようにするです。
まとめ
- コードを書く経験は、AI時代でもレビューと検証の土台になる
- 実務では、動作だけでなく目的・例外・既存設計・保守性まで見る
- 「なんかおかしい」は、期待・条件・影響・確認方法・修正に翻訳して初めて仕事になる
- AIに任せるのはいい。ただし、予測・検証・振り返りまで手放さない
- まずは一機能につき、正常系以外を一つ試すところからで十分
あわせて読みたい記事