PONOS Advent Calendar 2025 11日目の記事です。
前回はmon3612さんの記事でした。
はじめに
LLMを使い始めてから1年半ほど経ちました。
2025年の総括として、LLMを使用してきた自身の感想に加え、AI Coding Meetup #3での対談内容を交えて、AI時代のエンジニアリングについて考察します。
参考：【t-wadaさん, 一休CTO, LayerX】AI時代の開発スピードと品質 / 本当の意味で開発生産性を上げるために必要なこと by TECH WORLD
1. 楽にはなった、しかし成果は？
まず、LLMがエンジニアのQoL（Quality of Life）を劇的に向上させたことは間違いありません。
一休CTOの伊藤氏が「生産性が上がったというより『楽になった』」と語っていた通り、私自身も非本質的な作業から解放されました。
- タイポの修正や定型コードの記述
- エラーメッセージの解釈
- ドキュメントの参照・作成
これらが一瞬で完了することでストレスが減り、仕事の満足度は確実に上がりました。今やLLMなしでの開発は想像できず、もはや手放せないツールです。
アウトプットは増えたが、アウトカムは増えていない
しかし、ここで核心的な問題にぶつかります。「コードを書く量は増えた（アウトプット増）が、事業の成果（アウトカム）は増えていない」 のです。
動画内でモデレーターの山口氏が提起したこの問題は、私の最近の違和感を言語化するものでした。
些細な修正や実装は数分で終わるようになりましたが、それが顧客満足度や売上といったビジネス価値に直結しているかというと、疑問が残ります。
ボトルネックの移動
理由はシンプルで、「ボトルネックが移動しただけ」だからです。
実装フェーズが高速化された結果、その後のコードレビューやQAに負荷が集中しています。
LLMでコードを大量生産できても、それをレビューする人間の処理能力は有限です。特に重要なのは「実装の詳細」ではなく、「モデル変更の意図」や「ビジネスロジックの正しさ」を判断することです。ここには依然として深い業務理解が必要であり、AIが生成したコードがビジネスの根幹を正しく反映しているかの判断は、人間が担わなければなりません。
コア業務への適用の壁
また、普段の業務にLLMを活用できる場面は意外と少ないという現実もあります。
UI生成やスクリプト作成など、品質基準が柔軟な領域では有効ですが、料金計算や予約処理といったコアなドメインロジックへの適用は困難です。
特に長期間運用されているシステムでは、業務の95%が既存システムの保守・変更です。複雑に絡み合ったレガシーコードに対しては、LLMにゼロから生成させるよりも、エンジニアがコードベースを読み解き、モデルを理解した上で手作業で修正する方が、結果として確実で安全な場合が多いのです。
2. 新たな課題：AI疲れと民主化の功罪
実装が楽になった裏側で、私たちは新たな種類の疲れとリスクに直面しています。
大量の判断を迫られる「AI疲れ」
LLMを使うことは、絶え間ない「判断」の連続です。
「このコードは正しいか？」「モデルを反映しているか？」「副作用はないか？」
生成スピードが速い分、判断の頻度も爆発的に増えました。コードを書く肉体的な疲れは減りましたが、意思決定による脳の疲労、いわゆる 「AI疲れ」 を感じることが増えています。
また、実装が容易になったことで、「あれもこれも」と手を広げすぎてしまい、結果としてレビューや運用の負荷を自分で増やしてしまう現象も起きています。
「できること」が増えたからこそ、「本当にやるべきこと」を厳選する自制心が試されています。
開発の民主化は地獄のはじまりか
t-wada氏が言及した 「開発の民主化」 も無視できないトピックです。
非エンジニア（デザイナーなど）がコードを直接修正できるようになることは、細やかな改善が進むポジティブな側面がある一方、「地獄のはじまり」 になるリスクも孕んでいます。
私自身の経験でも、非エンジニアがLLMで生成したコードを実装しようとし、アプリケーション全体の設計方針と整合せず、結局止めてもらったことがありました。
変更の影響範囲を判断できないままプルリクエストが作成されれば、エンジニアのレビューコストは増大し、「最初からエンジニアがやった方が早かった」という事態になりかねません。
これは単なるツールの問題ではなく、エンジニアと非エンジニアの協力関係やコミュニケーションのあり方そのものが問われていると言えます。
おわりに： 魔法の杖ではなく「良き相棒」として
1年半の総括として言えるのは、やはりLLMは 「魔法の杖」でも「銀の弾丸」でもない ということです。
アウトプットの量は増やせますが、それだけでアウトカム（成果）が自動的に増えるわけではありません。
しかし、LLMが私たちのストレスを減らし、QoLを向上させる強力な 「ツール」 であることもまた真実です。
重要なのは、AI時代においても、ドメインモデリングや品質保証といった、人間にしか担えない本質的な役割は残るということです。
これからのエンジニアに求められるのは、コーディングの速さだけではありません。
LLMの特性を理解し、「どこで使うべきか（UI、ドキュメント、スクリプト）」と「どこで使うべきでないか（コアロジック、複雑な改修）」を見極める 判断力。そして、LLMを使いこなしながらも、ビジネスの本質を見抜くスキルを磨き続ける姿勢こそが、真の開発生産性につながるのだと思います。
明日はramune_jellyさんです！