--- title: "AIがコードを速く書く時代、開発者はまだ創造的な仕事なのか" url: https://www.thinnd.site/ja/kosatsu/ai-ga-hayaku-kaku-jidai-kaihatsusha-wa-souzou-suru-ka/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "考察" tags: ["省察", "創造性", "職人技", "AI", "プログラミング", "キャリア"] summary: "はい、まだ創造的です。ただし創造的な部分は移ります。コードを書くことが安くなると、代わりにくい仕事は、解く価値のある問題を見つけること、方向を選びトレードオフを引き受けること、結果を確かめること、システムとその周りの人を気遣うことです。リスクは本物です。書くことをすべて任せると、AIが作ったものを判断する力を失いかねません（Anthropicの小さな試験では、AI群のテストは約50%、自分で書いた群は約67%）。技を保つには、まず自分でアイデアを描き、採点者として読み、削る練習をし、楽しみのために小さなものを作ることです。" license: "Cite with the author name and the canonical URL above." --- # AIがコードを速く書く時代、開発者はまだ創造的な仕事なのか > これは**省察**です。私が論じ、問いを立てるもので、研究報告ではありません。どこが引用した数字で、どこが私の意見かを明記します。 > > 多くの数字は自己申告の調査か、ベンダーの発表なので、慎重に読んでください。大工のたとえは、イメージしやすいようにした私のたとえです。 --- ## 先に要点 - 私の短い答え：**まだ創造的。ただし創造的な部分は移る**。「コードを打つこと」から、「仕事を選び、方向を選び、結果に責任を持つこと」へ。 - 開発者の仕事を**5つの層**に分けます：問題を見つける、解決を形にする、コードを書く、確かめる、気遣う。AIが最も強く引き受けつつあるのは3つ目の層です。 - 案を作ることが安くなると、**貴重になるのは、センスと選ぶ力**で、打つ速さではありません。 - **本物のリスク**があります：書くことをすべて任せると、AIが作るものを判断する力を失いかねません。小さな試験にその兆しがあります。 - いくつかの小さな習慣と、毎週自分を測る1つの問いで、**意識して技を保てます**。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **職人技（クラフト）** | 自分の手と注意で良いものを作る技。実践を通して積み上がる。 | | **センス** | 多くの選択肢の中で、良いものと、ただ許容できるものを見分ける力。 | | **トレードオフ** | 一方を選ぶと他方で損をすること。たとえば速いが保守しにくい。 | | **フロー** | 中断されず、仕事に没頭している状態。 | | **スキルの衰え** | やらなくなって、少しずつできなくなること。 | | **自己申告** | 人が自分の感じ方を述べた数字で、直接測ったものではない。 | --- ## 1. たとえ：大工と電動のこぎり 昔の大工の作業場を想像してください。板はすべて手で挽かれます。そこに電動のこぎりが現れました。大工の仕事は死んだでしょうか？ 私は死んでいないと思います。ただ、**巧みさの置き場所が移りました**。大工は挽くことに使う力が減り、設計、接合部、仕上げにより多くの力を注ぎます。同時に、本当になくなるものがあります：**挽くときの手の感覚**で、人によっては、それがこの仕事の喜びでした。 このたとえは、問いを正確に立てる助けになります。「AIは創造性を奪うか」ではなく、こう問います：**巧みさはどこへ移り、同時に私は何を失っているのか？** またこのたとえには限界もあります：電動のこぎりはどんな机を作るかを「決め」ませんが、AIは設計まで提案できます。機械的に当てはめないでください。 --- ## 2. 開発者の仕事の5つの層 「コードを書く」と言うとき、私たちは多くの仕事をひとまとめにしがちです。私は5つの層に分けます： | 層 | 仕事 | 今AIがどこまで助けるか（私の意見） | |---|---|---| | **1. 問題を見つける** | 利用者が何を必要とするか、どの問題が解く価値があるかを理解する | 要約や問いの提案は助ける。どの問題に価値があるかの決定は、あまり | | **2. 解決を形にする** | 設計、トレードオフの選択、何を捨てるかの決定 | 案は出す。選択に責任を持つことは、できない | | **3. コードを書く** | 設計をプログラムにする | **最も強い**。特に繰り返しで、はっきりした部分 | | **4. 確かめる** | 読む、テスト、デバッグ、いつ「正しい」か知る | 補助はできるが、自信過剰になりがち | | **5. 気遣う** | 保守、人と働く、長期の責任 | 細かい雑務は助ける | この表は**私の意見**で、測定結果ではありません。それでも1つのことが見えます：3層目が安くなっても、**残る4つの層は消えず、むしろ重要になる**。 --- ## 3. センスと選ぶことが貴重になる 案を1つ書くのに1週間かかるなら、選べる案は数個です。AIが数分で1つ書くなら、10個になりえます。そのとき希少なのは、**10個を見て、どれが残す価値があるかを見分ける力**です。 これは、この仕事でいちばん創造的な部分だと私は思い、**センス**が要ります。センスは、作り、壊し、直した経験からしか得られません。古い話が示しています：1982年の初め、Appleのあるエンジニアは、話によると、グラフィックスのコードの一部をより単純なアルゴリズムに置き換え、約6倍速く、約2000行短くし、生産性の報告にマイナス2000行と書きました。この逸話は複数の情報源で語られているので、細部を正確と思わないでください。でも、**コードの創造性は、削ることにあることが多い**と思い出させます。コードを作ることがほぼ無料の今は、なおさらです。[生産性をコードの行数で測らない](https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/)で詳しく述べています。 --- ## 4. 楽しさと仕事の感覚について、数字は何を言うか データはいくつかあり、**向きがそろっていません**。 - **楽しさと集中（GitHub、自己申告）。** GitHubのCopilotの研究では、利用者の87%が、ツールが繰り返しの作業で頭の力を温存するのに役立ったと答え、73%が集中した状態を保つのに役立ったと答えました。60〜75%の層は、コードを書くときに、より充実し、いら立ちが減ったと答えました。これは、ツールを作った会社自身による自己申告の調査で、直接の測定ではありません。 - **開発者の満足を左右するもの（Stack Overflow 2025）。** 調査の要約によると、上位の要因は自律性と信頼、競争力のある給与、実際の問題を解くことで、AIの統合は低い順位です。「幸せ」な開発者の割合は前年よりわずかに上がりました（24%対20%）が、まだ低いままです。私は要約に頼っており、元の調査の各設問は読んでいません。 - **雇用への不安。** やはり要約によると、64%の開発者はAIを雇用への脅威とは見ておらず、前年の68%から下がっています。 合わせて読むと、私は1つの慎重な考えを引き出します：**AIは退屈な部分を減らせるかもしれないが、多くの人の仕事の喜びは、自律性と実際の問題を解くことから来て**、それらは1、2、5層にあります。AIが3層目を減らすだけで、他の層で自律性が増えないなら、楽しさは上がらないかもしれません。 --- ## 5. リスク：もうやらないことを判断する力を失う ここが私がいちばん心配する部分です。**うまく選ぶには、作った経験が要ります。** 自分でデバッグしたことのない人は、AIが間違ってデバッグしたときに気づきにくいのです。 Anthropicは（2026年1月）、見慣れないPythonのライブラリを学ぶ52人のプログラマー、多くは経験が浅い人への無作為化試験を公表しました。AI群の知識テストは約50%、自分で書いた群は約67%で、差が最大なのはデバッグの問題でした。標本は小さく（各群26人）、私は要旨を読んだだけで原文は読んでいません。 METRの別の研究（2025年7月）では、経験豊富な16人の開発者が246の実作業をし、2025年初めのAIツールで**約19%遅くなり**ました。本人たちは約20%速くなったと信じていました。ツールはその後大きく変わりましたが、**うまくやっているという感覚と、実際にうまくやっていることはずれうる**という注意になります。 これらの他に、断言するデータのない2つの心配があるので、**仮説**として挙げます：（1）みんながAIの最初の案を受け入れると、製品が少しずつ似てくるかもしれない。（2）仕事の学びが「自分で作る」部分を飛ばすと、次の世代にレビューできるだけのセンスを持つ人が足りなくなるかもしれない。 --- ## 6. より大きな文脈：AIは増幅器 GoogleのDORA 2025報告は、この話に合うと私が思う結論に至っています：AIは主に**増幅器**だというものです。良い組織の強みを強め、混乱した組織の弱みをあらわにします。報告によると、大きな見返りはツールだけからでなく、基盤の質、手順の明確さ、チームの足並みから来ます。（私は要約に頼っており、報告全体は読んでいません。） この仕事に当てはめると：AIは**あなたの仕事の仕方も増幅**しうるのです。センスと確かめる習慣のある人は、より速く進みます。ない人は、見た目は良いが、どれが壊れているか分からないものをたくさん作るかもしれません。 --- ## 7. 技を保つ5つの習慣 *これは私の提案で、多くの人では検証していません。* 1. **聞く前にアイデアを描く。** 15分、自分の設計を描くか書く。それからAIの提案と比べる。 2. **採点者として読む。** 動かすだけにしない。「なぜこの方法か、何が足りないか、誰が保守するか」を問う。 3. **削る練習をする。** 毎週、消せる、または単純にできるコードを1つ探す。創造性は、少ないことにあることが多い。 4. **AIなしの時間を持つ。** 手を鍛えるため、そして自分に何ができるかを知るため。 5. **楽しみのために小さなものを作る。** KPIのためでなく、自分のための小さなツール。仕事の喜びには、養うことが要る。 業界に入ったばかりなら、[新人のための12か月計画](https://www.thinnd.site/ja/ayumi/ai-jidai-no-shinjin-12kagetsu-keikaku/)が、先に自分で書く習慣を具体的にします。また[AIを鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)は、確かめることがなぜ大事かを説明します。 --- ## 8. 毎週自分を測る1つの問い > **今週、AIが代わりに下せなかった判断を、私はいくつ下したか？** ここでの判断とは、誰かが責任を持つ選択のことです：どの問題を先にやるか、どの機能を捨てるか、どのトレードオフを受け入れるか、どの依頼に「ノー」と言うか。この数字が下がり続けるなら、創造的な仕事から、レビューして「承認」を押す仕事へ滑っているのかもしれません。上がるなら、AIがあなたをより面白い部分へ解放しているのかもしれません。 --- ## 9. バランスの取れた見方 - **これは省察で、結論ではありません。** 5つの層と習慣は私の意見です。 - **データは薄く、向きがそろっていません。** 多くは自己申告かベンダーの発表で、研究の標本は小さく、ツールはとても速く変わります。 - **本当に何かを失う人もいます。** 人によっては、喜びはコードを1行ずつ書くこと自体です。その部分が縮むなら、惜しむ気持ちは正当で、「仕事は移るだけ」という言葉で片付けたくありません。 - **大工のたとえには限界があります。** AIは手道具だけでなく、設計も提案できます。 - **私は未来を知りません。** AIが1、2層でも上手になるかもしれません。そのときは問いを立て直さなければなりません。 --- ## 10. 結論 AIがコードを速く書く時代でも、**自分の創造的な部分を握り続ける**なら、開発者はまだ創造的な仕事をしています：問題を選び、解決を形にし、センスで確かめ、結果に責任を持つ。リスクは、いつの間にか「承認」を押す人に滑ってしまうことです。電動のこぎりは大工の仕事を奪いませんでしたが、もう手を鍛えない大工は、作る価値のあるものを設計しにくくなるでしょう。 今日の小さな一歩：今週、AIに仕事を頼む前に、自分ならどうやるかを3行書いてください。それから比べましょう。 --- ## 参考資料 - [GitHub：Research, quantifying GitHub Copilot's impact on developer productivity and happiness](https://github.blog/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) - [Stack Overflow Developer Survey 2025、AIの章](https://survey.stackoverflow.co/2025/ai) - [Anthropic：AI assistance and coding skills（2026年1月）](https://www.anthropic.com/research/AI-assistance-coding-skills) - [METRの生産性研究についてのSimon Willisonの解説](https://simonwillison.net/2025/Jul/12/ai-open-source-productivity/) - [DORA 2025: State of AI-assisted Software Development](https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/) - [Negative 2000 Lines Of Code、folklore.org](https://www.folklore.org/Negative_2000_Lines_Of_Code.html) - ブログ内の関連記事：[生産性をコードの行数で測らない](https://www.thinnd.site/ja/purodakuto-shiko/gyosu-de-seisansei-wo-hakaranai/)、[AI時代の新人：ジュニアになるための12か月計画](https://www.thinnd.site/ja/ayumi/ai-jidai-no-shinjin-12kagetsu-keikaku/)、[AIを鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)