静かに進行するAIコーディング運ゲー化の恐怖

対象読者

こんな方に読んでもらえると嬉しいです。

• コード生成を何度もやり直しているエンジニア
• ジュニア層のAI依存に悩んでいるエンジニア
• AIツール導入したのに開発効率が上がらないと感じている責任者

はじめに

「The Junior Developer Extinction」（ジュニア開発者の絶滅）というコラムを読んで考えさせられることがあったので、最近の感じているモヤモヤや思考を整理して言語化しました。

AIツール大好きな私が最近「あれ？これってちょっとマズい？」と感じていることです。コード生成の待ち時間にお茶でも飲みながら「うちのチームはどうだろう？」と振り返りのきっかけにしていただければ嬉しいです！

バイブコーディングという名の「運ゲー」

Andrej Karpathy 氏が提唱した「バイブコーディング」。自然言語でやりたいことを伝えて、AIにコードを生成させる手法です。

「コードがこんなに簡単に書けるの凄くない！？」と夢中になって試行錯誤し、社内メンバーにも積極的に活用するよう広めていきました。

でも、しばらくして気づきました。特にジュニアエンジニアがこれに依存し過ぎて、何度もAIにコードを生成させる「リセマラ」を繰り返している ような使いかたをしていることに...

• 機能追加の依頼が来た → ゴールが曖昧なままAIに依頼する
• エラーメッセージが出た → 意味を理解せずにエラーをコピペしてAIに修正させる
• 思った通りに動かない → リセットしてAIに再生成させる

元々自分でコードを書いていた方は生成されたコードを見てから指示を改善したり、自分でコードを修正すると思いますが、ジュニアエンジニアは与えられた時間の限り同じことを繰り返して生成結果がうまくいくことをお祈りし、ダメだったらベテランに相談するというような仕事の進め方になることがあるようです。（もちろん、すべての方がそうではないです）

現時点では、Kiro の「仕様書駆動開発（spec-driven development）」のワークフローも試してみましたが、フルオートでAIにお任せすると運ゲーです。

数年後の未来を考える

「運ゲー」を延々と繰り返すだけでは、成長はしません。

私はAIコーディングツールの活用を社内で推奨している立場ですが、本来やりたかった価値提供スピードの向上という観点でも、成果が不安定で達成できていないと言えます。

コードレビューでも「ここのコード変える必要あった？」でリテイクが発生して時間がかかり、逆に生産性が落ちているんじゃないかと感じてしまうこともあります。
※AIはシンプルな解決策より一般的によく見るコードを好む傾向があるようです

数年後、こんなことが起こるのではないかと思います。

• 技術負債の原因を特定できない
• 設計判断の根拠を説明できない
• 障害発生時に原因究明や対応に時間がかかる

これは個人の問題だけでなく、プロダクトの品質問題や、最終的には内製開発が困難になり外部パートナーへの依存という事態を招くことになります。

そして、外部パートナーへの依存度が高まると、自分達が分からないモノは外注費が高くつくということになりますし、外部パートナーの技術力を適切に評価できず、結果的にリセマラの民に依頼してしまうリスクも生まれます。

私たちができること

ジュニアエンジニア

「AIがあるから基礎は不要」という考えから脱却して、AIをうまく操れるエンジニアになっていけると良いかなと思います。

• 基礎を学び続ける
  データ構造やアルゴリズム、ネットワーク、セキュリティなどの基本は地味だけど大事です。AIが「なぜその選択をしたか」を理解し、正しい方向に導くために必要な土台だと思います。

• コードを読む習慣を身につける
  生成されたコードを一行ずつ理解し、「なぜこの書き方？」「なぜこの順序？」を考えます。エラーが出たら、まず自分で原因を推測してからAIに相談しましょう。

• AIに「頼る」から「相談する」へ
  生成結果を鵜呑みにせず「他の実装方法はありますか？」「この部分のリスクは？」など、AIと対話しながらコードの質を高めましょう。

ミドル・シニアエンジニア

ジュニアエンジニアの成長を支援して、組織全体の技術力向上させることが責任だと思います。

• 考える余白を作る
  スピード重視で「とりあえずAIにやらせて」と指示するのではなく、「なぜそうなるのか」を考える時間を意図的に作ってあげた方が良いと思います。

• 基礎学習の重要性を伝え続ける
  「AIがあるから基礎は不要になる」という意見もありますが、AIを効率よく使うためにこそ基礎が必要だと思っています。

• ペアプログラミングでの気づきを共有
  AIに丸投げしそうになったとき、一緒に考えるプロセスを体験してもらいましょう。

• コードレビューで「なぜ」を問う
  AIが生成したコードであっても、実装者が説明できるかを確認しましょう。

組織として取り組むべきこと

組織全体ではこのような取り組みができそうです。

• AI利用状況の把握と分析
  AIツールの使用状況（企業向けプランに付いてるパターン多いです）を定期的にチェックして、過度な依存がないかや、適切な使い分けができているかを確認しましょう。

• プロンプトレビューを開発フローに組み込む
  コードレビューのようにプロンプトもレビュー対象にするのが良いかもしれません。よいプロンプトや使い方コツの事例共有も効果がありそうです。

• 学習支援エージェントを構築する
  コード生成だけではなく、学習ポイントや背景知識を教えてくれる仕組みを構築できると良いかなと思います。Cursorのドキュメントにも例として「Learn」が紹介されています。

おわりに

AIコーディングはこれまで開発手法を革新する技術で、全エンジニアにとってスルーできない存在ですが、「運ゲー」のような使い方では、長期的に見て自分たちの首を絞めることになるかもしれないと感じています。

私も含めて、エンジニアがAIとうまく付き合っていく方法を模索していく必要があるなと思います。基礎を大切にしながら、AIの力も借りて、より良いプロダクトを作っていきたいと考えています。

正解はまだ分かりませんが、少なくとも 「考えることをやめないこと」 だけは大切にしていきたいですね！

---

関連記事（2025/7/31 追記）

この記事を参考に、詳しく深掘りして分析してくださった記事を見つけました。

https://suzaku-tec.hatenadiary.jp/entry/2025/07/31/120000

AIコーディングが運ゲー化する具体的な原因（出力のランダム性、バグやセキュリティリスクの混入、訓練データの偏りなど）や、AI利用状況の把握方法について技術的な観点から詳しく解説されています。私の記事では触れきれなかった部分を深く掘り下げてくださっており、とても参考になります。

執筆者の suzaku0914 さま、貴重な分析をありがとうございました！

---