調査：シニア開発者の3分の1が、自身のコードの半分以上がAI生成であると回答

2025年8月31日原文(fastly.com)

概要

Fastlyの2025年7月調査 によると、AI生成コードの本番導入率に経験差が存在
シニア開発者 はAIコードを積極的に利用しつつ、修正にも多くの時間を割く傾向
ジュニア開発者 はAI利用に慎重で、信頼性や修正負担を懸念
AIツール は効率向上だけでなく、仕事満足度やモラール向上にも寄与
グリーンコーディング やAIの環境負荷への意識も経験と共に高まる傾向

Fastly調査：AI生成コードの本番導入における経験差

シニア開発者（経験10年以上） の約3割が、「本番コードの半分以上がAI生成」と回答
- ジュニア開発者（0-2年） では同割合が13%、シニアの半分以下
AIによるコード修正・編集 の頻度もシニア層で高い傾向
- シニアの約30%が「AI出力の修正で時短効果がほぼ相殺」と回答
- ジュニア層では17%
AIツールによる納品スピードの向上 を感じる割合はシニアで59%、ジュニアで49%

シニア開発者のAI活用に対する楽観と自信

AIで「かなり速くなった」 と回答したシニア層は26%、ジュニア層の2倍
ジュニア層 は「やや速くなった」と感じる割合が高い（50%以上）
シニアは AIの誤りを見抜く能力や修正力 が高く、AIを積極的に本番運用
ジュニアは AIへの信頼や自信の不足 から、本番適用を控える傾向

AI生成コードの現実と認識ギャップ

全体の28% が「AIコードの修正で時短効果が大きく相殺」と回答
「ほとんど修正不要」と感じるのは14%のみ
それでも 半数以上 が「AIで作業全体は速くなる」と実感
RCT（ランダム化比較試験） では、AIツール利用で作業時間が19%増加という結果も
心理的には「速く進んでいる感覚」 があるが、実際は修正・テストで時間消費

開発者の声：AIツールの光と影

GitHub Copilot などで「工数削減・提案力向上」を実感
一方で、「複雑なアルゴリズムで微妙なバグが生じ、何時間もデバッグ」する事例も
ボイラープレートコード の自動生成で時短、ただし非効率部分の手直しが必要

AIツールと開発者の仕事満足度

約8割 が「AIツールでコーディングが楽しくなった」と回答
単純作業の省略 や「コード生成の達成感」がモチベーション向上に寄与
「詰まったタスクの突破口」「必要な答えの発見」にAIが役立つとの声

グリーンコーディングとAIの環境負荷意識

グリーンコーディング（省エネコーディング） の実践率は経験と共に上昇
- ジュニア層56%、ミッド・シニア層は約80%
AIツールのカーボンフットプリント について、全体の約2/3が認識
「全く知らない」開発者は8%未満
サステナビリティ意識 が開発者文化に定着しつつある傾向

調査方法

Fastlyによる2025年7月10日～14日実施
791名のプロ開発者 が対象
米国内配信・品質管理済み
自己申告型調査 であり、一定のバイアス可能性あり

参考記事

The Register: Older developers trust AI code more, but spend more time fixing it

Hackerたちの意見

自分が年寄りだとは思わないけど、Google APIに対してPythonの自動化を書く必要があって、急にコーディングエージェントの世界にハマっちゃった。ドキュメント用に3〜4つのサイトを開いて、3つのライブラリの間でコンテキストスイッチするのが大変だったよ。かなりの情報量だったから、「AIを使ってみよう」と思ったんだ。そしたらすごく助けられた！それ以来、AIの助けを借りて少なくとも6つのプロジェクトを公開したよ。リファクタリングもしてくれるし、ボイラープレートも書いてくれる。何よりも、異なるトピック間のコンテキストスイッチが得意なんだ。自分の仕事はDevOps、オートメーション、システム統合に関わっているから、トピックはかなり幅広い。だから全然気にしてないけど、年寄りじゃないよ。一番大事な教訓は、AIを絶対に信じちゃダメってこと。どれだけAIが妄想を膨らませるか、言い切れないよ。存在しないライブラリやモジュールを作り上げたりするからね。テーマを理解しているなら、すごく良いツールだけど、自分の代わりを育ててるかもしれないって気づいたんだ。間違いを修正するたびに、データベースに「より良いAIになる方法」を教えてることになるから、最終的には自分が必要なくなるかも。ありがたいことに、もう年寄りだから、その時には引退してるだろうけど。

└

ここは二重人格の雰囲気があって好きだな。

└

クソみたいなプラットフォームに対処する時、AIは本当に最高だよ。アトラシアンのリフレッシュキーの扱いが変で、自動化を書く羽目になった不運があったけど、AIがアトラシアンがリフレッシュキーを一回使ったら無効にするっていう天才的なアイデアを指摘してくれなかったら、もっと時間を無駄にしてたと思う。この手の手作業には、AIが最高のツールだね。

LOCの観点ではそうかもしれないけど、重要性の観点ではずっと低いと思う。少なくとも、俺はLLMをそんな風に使ってる。確かに肉厚な部分も作れるかもしれないけど、実際にコードを理解してる人がいない状態でトラックファクターがほぼ0ってのは、災害のレシピだと思うし、長期的なコードベースのメンテナンス性にも影響する。どんなチームでも、非自明な問題を解決するためには、そのレベルの理解を持った人が必要だと思う。でも、LLMを使って全てのスキャフォールディングやテストフィクスチャを作るのは全然アリだよ。だって、そのエネルギーを他のことに使えるから。

└

同意する。トリビアルな関数のかなり包括的なユニットテストを生成するためにLLMを使うからって、それがコアの複雑なビジネスロジックと同じくらい有用だとは限らないよ。そっちの方が微妙なミスをしやすいからね。

└

テストフィクスチャー。気になるんだけど、AIはどうやってあなたの欲しいものを知るの？

この記事は今までの経験と全く逆だな。俺はインターンシッププログラムで教えてるけど、2023年以降のインターンたちの主な問題はAIツールへの過度な依存だよ。AIを何でも使うのをやめさせて、問題を考えるように教えなきゃいけない気がする。一方で、周りの先輩たちは自分のやり方に固執して、printf()デバッグの習慣を置き換えるためにインタラクティブデバッガーを使おうとしないし、AIツールなんて論外だよ…。

└

一方で、周りの先輩たちは自分のやり方に固執して、printf()デバッグの習慣を置き換えるためにインタラクティブデバッガーを使おうとしないし、AIツールなんて論外だよ…。俺が業界に入った頃は、インタラクティブデバッグをよく使ってた。経験を積むにつれて、だんだん使わなくなったけど。printf()は意外と便利なんだよね。ちょっとアップグレードしてログレベルを意識したフレームワークにすれば、デバッグ用の行をコードに残しておいて、loglevel = TRACEやINFOでオンオフできるから。

└

インタラクティブデバッガーとprintf()はどちらも完全に有効で、いくつかの重複はあるけど別々のユースケースがあるよね。もしどちらか一方だけを使おうとしてるなら、考えるべきことがいくつかあるよ。

└

ちょっと細かいことを言うけど、printfデバッグには何の問題もないよ。並行プログラムをデバッグするのにすごく役立つし、一部を止めると状態が崩れちゃったり、再現しようとしてたバグを回避できたりすることもある。ツールについて言えば、AIコーディングが本当に好きなんだ。私のワークフローは、ChatGPTにインターフェースを貼り付けて、そこからコピー＆ペーストする感じ。接着コードは手で書くことが多いかな。テストケースも定義して、面倒な部分はAIに任せる。問題を解決するのが好きだし、タイピングが本当に嫌いなんだよね :)

└

インタラクティブデバッガーを試してみたけど、印刷よりも良い結果が出た状況にはまだ出会ってないな。インタラクティブコンソールを使って何がどう動くかテストするけど、アプリ内では印刷が一番簡単で早い解決策だった。

└

古い連中はデバッガーが使えないからprintfに頼ってるわけじゃなくて、デバッガーはプログラム全体を止めちゃうし、一歩一歩進めなきゃいけないからなんだよね。printfだと、全体のトレースやログを一目で見れるから、全体の流れが把握しやすいんだ。

Hacker Newsで議論の続きを見る