19
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

休日もコードを書くのが好きな自分が、AIにその座を譲った理由。そして譲らなかった「読む」という領域。

Last updated at Posted at 2025-12-01

はじめに

みなさん、コーディングは好きですか? 私は大好きです。かつては休日もコーディングに没頭するほど、自らの手でロジックを組み上げることをやりがいの1つと感じていました。

しかし、ここ最近のAIの進化を目の当たりにし、私はその大好きな「コードを書く」という作業のほとんどをAIに譲ることにしました。
本記事では、生粋の「書くのが好きなエンジニア」だった私が、なぜAIにハンドルを握らせるようになったのか。そして、それでもなお人間が手放してはいけない「コードを読む」という行為について、自分の考えを共有したいと思います。

昨今のAIコーディングの進化速度は異常だ

この1年だけを切り取ってみても、Claude CodeやGitHub Copilotなど、AIコーディングエージェントの進化は凄まじいものがあります。

少し前までは「テストコードの修正」や「簡単な仕様調査」くらいにしか使えず、その精度すら怪しい場面も多々ありました。
しかし最近では、バグ修正はもちろんのこと、スコープや指示さえ適切に調整できれば、新機能の開発やPoC(概念実証)の実装まで任せられるレベルに達しています。 もはや「補助ツール」ではなく「優秀なジュニア〜ミドルクラスのパートナー」になりつつあるのが現状です。

実は最初は「抗っていた」

正直に言えば、最初は抵抗がありました。 自分で言うのも何ですが、コーディング力には自信があります。「AIなんかに俺の仕事が奪えるか」という、エンジニアとしてのプライドが許さなかったのです。

最初はテストの実装など「面倒な作業」だけを押し付けるつもりでした。しかし、対話を重ね、AIの特性を理解していくうちに、ある事実に気づいてしまったのです。

「これ、自分が書くより圧倒的に速いし、効率的だ……」

もろもろ勘案するとAIに任せた方がバリューが出る

事業会社でプロダクト開発をしていると、やりたいことは無限にあります。

  • 新機能の実装
  • 研究開発、PoC、A/Bテスト
  • 技術的負債の解消、リファクタリング
  • テストカバレッジの改善

これまでは「工数不足」「人材不足」を理由に泣く泣く諦めていたタスクも、AIを使えば着手できる余地が生まれます。もちろんAI利用料というコストは掛かりますが、人件費や得られる機会損失の解消と比較すれば微々たるものです。

であるならば、「任せられるところは徹底的に任せて、自分はAIが解ききれない問いにリソースを集中させる」 ほうが、エンジニアとして、そしてビジネスマンとして高いバリューが出せると腹を括りました。

実際に任せてみてどうだったか

結論から言えば、1チケットあたりにかける労力は劇的に減りました。 特に大きかったのは 「記述する作業(タイピング)」と「網羅的に検索する作業」をまるごと削減できた点 です。

もちろん、AIに対して「そうじゃない」「ここを修正して」といった指示出しは必要です。
しかし、自分がゼロから設計し、書き起こし、メソッドが肥大化したから分割して……といった一連の試行錯誤をするよりも、脳のメモリ消費量はグッと減らせています。

こうして圧縮した時間を、次のタスクの着手やメンバーのフォロー、あるいはより上流の設計検討に充てられるようになった今、素直に「素晴らしい技術だ」と感服しています。

かつての「人間主導+AI補佐」というスタイルから、気づけば「AI主導+人間監修」というスタイルへ比重が移ってきているのは間違いありません。
今後、人間がゼロからコードを書くパイはさらに減っていくのでしょう。

だけど「コードを読む」ことは辞めない

さて、ここからが本題です。 「書くこと」がAIに取って代わられていく中で、
私は 「コードを読むこと」だけは辞めずに続けています。

理由はシンプルです。
「どこにどんなロジックがあるのか」という地図を頭の中に持ち続け、「その修正が本当に妥当なのか」を正しくジャッジするためです。

前述の通り、今のAIは優秀ですが、時に「その場しのぎの動けばいいコード」を生成することがあります。
もし人間がコードを読まなくなれば、AIが生成した「割れ窓(Broken Windows)」のような粗悪なコードがプロダクトに紛れ込み、気づかぬうちに技術的負債が蓄積していくでしょう。

人間・AIのどちらが書いたかに関わらず、持続可能な開発を維持するためには、誰かが 品質の防波堤(ゲートキーパー) になる必要があります。

  • プロダクト全体の整合性は取れているか?
  • マイクロサービス間で「車輪の再発明」をしていないか?
  • セキュリティやパフォーマンスに悪影響はないか?

これらを見極める「読む力」、そこから適切に指示を出す「判断力」こそが、今の時代のエンジニアに求められる最も重要なスキルだと私は考えています。

おわりに

かつて私は、自分の手でコードを書くことにアイデンティティを感じていました。
しかし今は、AIという強力なエンジンを使いこなし、プロダクトの価値を最大化することにやりがいを感じています。

もしかすると数年後には、コードを読むことすら不要になり、完全にブラックボックス化されたAIモジュールを組み合わせるだけの時代が来るかもしれません。
しかし、そのリスクを完全に払拭できる日が来るまでは、私はコードを書き続けるAIの横で、誰よりもコードを読んで理解し、適切に判断できる人間でありたいと思います。

____そして、初心を忘れないためにも、コーディングそのものは引き続き適度に嗜んでいこう。
この記事を書きながら、改めてそう思いました。

次回予告

明日の うるる (ULURU) Advent Calendar@mtakehara21 さんの記事です!お楽しみに!

19
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?