開発者という職業の変遷：手書きコードからAIエージェント、そしてその先へ

トレンド調査レポート・作成日時：2026年10月29日 08:42

対象範囲：ソフトウェア開発全般（Web、モバイル、バックエンド、システム）、現場で働く開発者の視点から。

要約#

約35年の間に、開発者という職業のボトルネックは移り変わり続けてきました。コードを書けること → 解決策を見つけられること → システムを運用できること → 機械が書いたコードを検証できること → 問題を正しく定義し、AIを指揮できること。
ボトルネックが移るたびに、かつて「金」だったスキルは当たり前のものになり、新しいスキルが価値を持つようになります。うまく適応できる人は、ツールを最も使いこなす人ではなく、新しいボトルネックがどこにあるかにいち早く気づく人です。
2025〜2026年は、インターネット登場以来最大の転換点です。AIはコードを提案するだけでなく、一連の作業（リポジトリを読む、複数ファイルを修正する、テストを実行する、PRを作成する）を自ら実行し始めました。開発者の役割は「コードを書く人」から**「設計し、タスクを任せ、結果に責任を持つ人」**へと変わりつつあります。
ただし実際のデータを見ると、状況は手放しで楽観できるものではありません。AIの利用率は非常に高い一方で、その正確性への信頼はまだ低く、経験豊富な開発者が慣れたコードベースでAIを使うと、かえって遅くなる可能性を示す研究もあります。だからこそ、検証する力がますます重要になります。
2027〜2030年以降も通用するスキルは、システム思考、明確な仕様の記述、レビューとテスト、業務理解、セキュリティ、コミュニケーションです。CSの基礎（アルゴリズム、ネットワーク、データベース）は価値を失うのではなく役割が変わります。書くためではなく評価するために使うのです。

1. 手法と分析の枠組み#

本レポートでは、開発者が日々の問題解決に使う中心的なツールに基づいて、開発者の歴史を6つの時代に分けます。各時代について、次の5つの問いで分析します。

問い	意味
開発者はどんな姿だったか？	典型的な1日の働き方
中心的なツールは何か？	行き詰まったときに最初に開くもの
ボトルネックはどこにあるか？	最も時間がかかる／最も難しい作業
価値の高いスキルは何か？	優れた開発者と普通の開発者を分けるもの
適応するために何をすべきか？	取り残されないための具体的な行動

時期の区切りはあくまで目安です。各時代は互いに重なり合っており、移行のスピードは国、企業、分野によって異なります。ベトナムでは、多くのオフショア開発企業の移行が、米国のプロダクト企業と比べて1〜3年遅れています。

2. 開発者の6つの時代#

第0期（1990年以前）・前史：パンチカードとメインフレーム#

比較の基準として簡単に触れておきます。プログラマーは紙にコードを書き、カードに穴を開け、メインフレームでの実行結果を何時間も待っていました。構文エラー1つで丸1日を失うこともありました。ボトルネックはマシン時間です。コンピューターは人間よりも高価だったため、開発者は提出前に「頭の中でプログラムを実行する」ように入念に確認する必要がありました。

今も通用する教訓：実行する前によく考えるほうが、後から直すよりはるかに安上がりです。

第1期（≈1990〜2007年）・手書きコードと「分厚い技術書」#

開発者の姿

分厚い本の山（C++、Java、各言語の「バイブル」）、MSDNのドキュメントCD、掲示板やメーリングリストを傍らに置いて作業していました。
見慣れないエラーに遭遇したら、本を調べる、隣の人に聞く、掲示板に投稿して数日待つ、という具合でした。
ソフトウェアは年単位でリリースされ、ディスクに焼いて手作業でインストールしていました。ウォーターフォール型のプロセスが主流でした。

中心的なツール：書籍、公式ドキュメント、初期のIDE（Visual Studio、Eclipse、Borland）、掲示板、IRC。

ボトルネック：知識へのアクセス。良い本やメンターがいて、多くのAPIを覚えている人ほど、圧倒的に速く作業できました。

価値の高いスキル

構文と標準ライブラリを暗記していること。
メモリ、ポインタ、パフォーマンスを深く理解していること（ハードウェアがまだ非力だったため）。
print文やデバッガで自力でデバッグし、誰の助けも借りずにスタックトレースを読めること。

当時の適応方法：一次資料を読む、個人用のライブラリ（スニペット）を作る、掲示板コミュニティに参加する、ドキュメントを読むために英語を学ぶ。

今も価値のある遺産：一次資料を読む力と低レイヤーへの理解は、AIがAPIを「でっち上げた」ときや、パフォーマンスの悪いコードを書いたときに、それを見抜く助けになります。

第2期（≈2008〜2014年）・Stack Overflow とオープンソースの時代#

重要な出来事：Stack Overflow と GitHub がともに2008年に誕生しました。Google 検索が「第2のIDE」になりました。jQuery、Rails、Django、その後 Node.js、AngularJS が爆発的に普及しました。

開発者の姿

エラーに遭遇 → エラーメッセージをコピー → Google に貼り付け → 最初の Stack Overflow のリンクを開く → 最も票の多い回答をコピー。
自分で書く代わりにオープンソースライブラリを使い、パッケージマネージャー（npm、pip、Maven、Composer）が普及しました。
アジャイル／スクラムが広がり、スプリント単位でより速くリリースするようになりました。

中心的なツール：Google と Stack Overflow、GitHub、パッケージマネージャー、フレームワーク。

ボトルネック：探す力と組み合わせる力。知識はもはや希少ではなく、難しいのは正しい答えを見つけ、ライブラリを組み合わせて動かすことでした。

価値の高いスキル

「ググり力」：エラーを的確な検索キーワードに言い換える力。
回答を見極める力：どれが古いのか、どれが単なるハックなのか。
適切なライブラリ／フレームワークを選ぶ力、他人のソースコードを読む力。
Git を使いこなし、プルリクエストで協働する力。

この時代の落とし穴：「コピペプログラミング」（理解せずにコードを貼り付ける）、ライブラリへの過度な依存（小さな処理のために何百もの依存関係を取り込むプロジェクトも多くありました）。

適応方法：GitHub のプロフィールを育てる、オープンソースに貢献する、良い質問の仕方を学ぶ（最小限で再現可能な例を示す）、貼り付ける前にコードを理解する。

第3期（≈2015〜2020年）・クラウド、DevOps、マイクロサービス#

重要な出来事：AWS／Azure／GCP が成熟し、Docker（2013年）と Kubernetes（2014年）が標準になりました。CI/CD、Infrastructure as Code、マイクロサービス、モバイルファースト、そして SaaS やローコードが登場し始めました。

開発者の姿

コードを書くだけでなく、それを動かすことにも責任を持つようになりました。「You build it, you run it」です。
自動化されたパイプラインで1日に何度もデプロイし、ダッシュボード、ログ、アラートを監視し、オンコール当番を担います。
分散システムでは、不具合は1つのファイルの中ではなく、サービスとサービスの間に潜んでいます。

中心的なツール：クラウドコンソール、Docker／K8s、CI/CD（Jenkins、GitHub Actions、GitLab CI）、Terraform、監視ツール。

ボトルネック：運用の複雑さ。機能を書くこと自体は速くても、それを安定して、安全に、負荷に耐え、可観測な状態で動かすことが難しいのです。

価値の高いスキル

分散システムのアーキテクチャ、API設計、大規模なデータベース。
DevOps／SRE：自動化、オブザーバビリティ、障害対応。
セキュリティの基本（IAM、シークレット、OWASP）。
クラウドコストの理解。

落とし穴：必要もないのにマイクロサービスを採用すること、「履歴書駆動開発」（経歴のために技術を選ぶこと）、開発者の役割が多くの領域に膨らみすぎること。

適応方法：クラウドとコンテナを学ぶ、クラウド資格を取る、オンコールに参加する、ポストモーテムの書き方を学ぶ、1つのレイヤーだけでなくシステムをエンドツーエンドで理解する。

第4期（≈2021〜2024年）・AI Copilot：一緒にタイピングするアシスタント#

重要な出来事：GitHub Copilot が2021年にプレビュー版を公開し、2022年に正式リリースされました。ChatGPT（2022年11月）が検索の習慣を変え、その後さらに強力なモデル（GPT-4、Claude、Gemini など）や、Cursor のようなAI統合型IDEが続きました。

開発者の姿

関数名を打つと、AIが関数の本体まで提案してくれるので、Tab を押すだけ。
エラーに遭遇したら、Google ではなくチャットボットに聞きます。Stack Overflow への新規質問数は2022年以降大きく減少しました。
テスト、正規表現、SQL、ボイラープレートの作成、古いコードの解説、言語間の変換にAIを使います。

中心的なツール：IDE内のAIオートコンプリート、AIチャットボット。

ボトルネック：検証。コードを書くコストは大幅に下がり、そのコードを読み、理解し、正しいことを確認する作業が労力のかかる部分になりました。AIは「ハルシネーション」を起こすことがあります（APIをでっち上げる、誤ったロジックを自信満々に書く）。

価値の高いスキル

明確なプロンプト：コンテキスト、制約、例を与えること。
コードを素早く読み、微妙なバグを見つけること。
AIが生成したコードの「セーフティネット」としてテストを書くこと。
AIを使うべきでない場面を見極めること。

参考データ

GitHub による対照実験（2022年）：Copilot を使ったグループは、使わなかったグループと比べて、サンプルのプログラミングタスクを約55%速く完了しました。
この結果は小規模で独立したタスクで測定されたものであり、あらゆる種類の業務を代表するものではありません（第4章も参照）。

適応方法：AIを日常的に使いつつ必ず読み直す、テストとレビューのスキルを強化する、思考の「筋力」を失わないよう難しい問題を自力で解く習慣を保つ。

第5期（≈2025〜2026年）・エージェント型コーディング：AIが自ら作業する#

重要な出来事：プログラミング向けのエージェントツール（Claude Code、Cursor Agent、OpenAI Codex、GitHub Copilot coding agent、Devin など）は、要求を受け取り、自らリポジトリを読み、計画を立て、複数のファイルを修正し、コマンドとテストを実行し、プルリクエストを作成できるようになりました。「vibe coding」という言葉（Andrej Karpathy、2025年2月）が、「言葉で説明し、AIに書かせ、コードはほとんど読まない」やり方を指す用語として広まりました。MCP（Model Context Protocol）は、エージェントが社内のツールやデータに接続するのを助けます。

開発者の姿

タスクの説明／仕様を書く → エージェントに任せる → 計画をレビューする → 差分をレビューする → 修正を依頼する → マージする。
独立したタスクには複数のエージェントを並行して走らせます。開発者はAIチームのテックリードのような存在です。
専門家でない人（PM、デザイナー、アナリスト）が、自分で動くプロトタイプを作れるようになりました。
特にプロトタイプや新規プロジェクトでは、以前は小さなチームが必要だった仕事を1人でこなせることもあります。

中心的なツール：ターミナル／IDE／クラウド上のAIエージェント、エージェント向けの指示ファイル（CLAUDE.md、AGENTS.md など）、MCPサーバー、「審判」としてのCIシステム。

ボトルネック：仕様と検証。

入力側：AIに何が必要かを正確に伝えること（曖昧な要求 → もっともらしく間違った結果）。
出力側：結果が正しく、安全で、アーキテクチャに沿っていることを確認すること。コードの量は、人間のレビュー能力を上回るペースで増えています。

価値の高いスキル

仕様を書く力：受け入れ基準、制約、入出力の例、スコープ外の明示。
コンテキストエンジニアリング：エージェントが最初から正しく動けるよう、ドキュメント、規約、テストを整えること。
問題を分割する力：独立していて検証可能なタスクに分けること。
アーキテクチャレベルのレビュー：1行ずつ見るだけでなく。
AIツールチェーンのセキュリティ：プロンプトインジェクション、シークレットの漏洩、エージェントの権限、AIが追加した依存関係。

参考データ

Stack Overflow Developer Survey 2025：回答者の約84%がAIツールを使っている、または使う予定ですが、AIの正確性を信頼していない人（約46%）のほうが、信頼している人より多い結果でした。
METR によるランダム化比較研究（2025年7月）では、経験豊富なオープンソース開発者が自分の慣れたリポジトリで作業した場合、AIを使うと約19%遅くなりました。事前には約24%速くなると予測しており、事後もなお速くなったと感じていたにもかかわらず、です。

解釈：AIは新しく、ありふれていて、パターンが豊富な作業では明らかに速度を上げます。しかし、大規模で暗黙のコンテキストが多く、品質基準の高いコードベースでは、かえって遅くなることがあります。「速くなった」という感覚は実際の生産性と同じではないため、自分たちのチームのデータで測る必要があります。

適応方法

少なくとも1つのエージェントツールを使いこなし、リポジトリに指示ファイルとテストを整備する。
「仕様が先、コードは後」の習慣を身につける。
AIコードのレビュールールを定める：テストの必須化、エージェント権限の制限、セキュリティスキャン。
生産性は感覚やコード行数ではなく、実際の指標（リードタイム、不具合率、レビュー時間）で測る。

第6期（≈2027〜2030年以降）・開発者は「指揮者」に（予測）#

この部分は現在のトレンドに基づく予測であり、先の時期になるほど確実性は下がります。

最も可能性の高いシナリオ

エージェントはより長いタスク（数時間、数日）をこなせるようになり、テストや環境からのフィードバックに基づいて自らバグを修正するようになります。
仕様駆動開発（spec-driven）：要件ドキュメント、受け入れ基準、テスト、アーキテクチャモデルが「本当のソースコード」となり、コードは再生成可能な派生物になります。
マルチエージェントシステム：コードを書くエージェント、レビューするエージェント、セキュリティのエージェント、運用のエージェントがいて、人間は目標と境界を定め、重要なポイントを承認します。
自動検証の強化：プロパティベーステストや形式手法（formal verification）が、AIによる証明作成の支援によって、より実用的になります。
「パーソナライズされた」ソフトウェア：エンドユーザーが自分用の小さなツールを自作するようになり、ソフトウェアの数が大きく増え、それに伴ってプラットフォーム、セキュリティ、統合、ガバナンスへの需要も高まります。

開発者の姿

時間の大半を、ビジネス課題の理解、システム設計、仕様の記述、ガードレールの設定、重要な判断のレビュー、難しい障害への対応に費やします。
新しい役割が登場、あるいは拡大する可能性があります：AIエンジニア、エージェント／プラットフォームエンジニア、評価エンジニア（eval engineer）、AIセキュリティエンジニア、「プロダクトエンジニア」（技術とプロダクトを兼ね備えた人）。

ボトルネック：判断と責任。機械は多くのことができますが、何をすべきかを決め、トレードオフをどうするかを判断し、間違ったときに責任を負うのは誰でしょうか。

検討すべきその他のシナリオ

予想より遅い場合：計算コスト、信頼性の限界、法規制によって進展が鈍化し、開発者は引き続き多くのコードを書くものの、より強力なアシスタントを使うようになります。
予想より速い場合：エージェントがプロセスの大半を自律的に担い、「コードを書くだけ」の開発者の数は明らかに減少し、需要は業務を理解しAIを指揮できる人へと移ります。
どのシナリオでも、判断、仕様、検証のスキルの価値は高まります。

3. 総合比較表#

時代	中心的なツール	ボトルネック	最も価値の高いスキル	典型的な1日
1990〜2007年・手書きコード	書籍、ドキュメント、掲示板	知識へのアクセス	APIの暗記、低レイヤーの理解	本で調べ、自力でデバッグ
2008〜2014年・Stack Overflow	Google、SO、GitHub	解決策を探して組み合わせる	検索、ライブラリ選定、Git	エラーをコピー → Google → 修正
2015〜2020年・クラウド／DevOps	クラウド、Docker／K8s、CI/CD	運用の複雑さ	アーキテクチャ、DevOps、オブザーバビリティ	コード → パイプライン → ダッシュボード
2021〜2024年・Copilot	AIオートコンプリート、チャットボット	AIコードの検証	プロンプト、コードリーディング、テスト作成	タイピング・Tab・AIに質問
2025〜2026年・エージェント型	AIエージェント、MCP	仕様と検証	仕様、コンテキスト、アーキテクチャレビュー	タスクを任せる → 差分をレビュー
2027〜2030年以降・指揮者	マルチエージェント、仕様駆動	判断と責任	システム思考、業務理解	問題を定義 → 承認

導き出される法則

時代ごとに、抽象化のレイヤーが一段上がります：マシンの操作 → ライブラリの操作 → インフラの操作 → 意図（intent）の操作。
前の時代のスキルは消えるのではなく、下層に沈みます。依然として必要ですが、日常業務ではなく、評価や障害対応のために使われます。
どの波にも**「行き過ぎ」**の段階があります：コピペ（第2期）、乱立するマイクロサービス（第3期）、レビューなしの vibe coding（第5期）。エンジニアリングの原則を守り続けられる人が、この段階を最もうまく乗り越えます。
どの波もソフトウェアを作る人の数を広げ、最終的にはシステムを深く理解する人への需要全体を押し上げます。

4. データを直視する：AIはどこまで役立つのか？#

出典	主な発見	読む際の注意点
GitHub、対照実験（2022年）	Copilot を使ったグループはサンプルタスクを約55%速く完了	小規模で独立したタスク、実験環境
Stack Overflow Developer Survey 2025	約84%がAIを使用または使用予定、正確性への信頼は低い（約46%が信頼していない）	自己申告による調査
METR、ランダム化比較研究（2025年7月）	経験豊富な開発者が慣れたリポジトリでAIを使うと約19%遅くなったが、本人は速くなったと感じていた	小規模サンプル（開発者16人）、2025年初頭時点のツール
Stack Overflow のトラフィック	ChatGPT の登場後、新規質問数が大きく減少	検索習慣の変化を反映

データから言えること

AIはもはや選択肢ではなく、当たり前のツールになりました。
効果は状況に強く依存します：作業の種類、コードベースへの慣れ、テストの質、使う人のスキル。
体感の生産性と実際の生産性のギャップは、マネジメント上の本当のリスクです。チームは自ら測定すべきです。

注記：上記の数値は公開レポートから集計したものです。正式に引用する前に、出典（第9章）を改めて確認することをおすすめします。

5. 2027〜2030年以降の開発者に必要なスキルセット#

5.1 コアスキル（価値が高まる）#

スキル	なぜ重要か	鍛え方
システム思考	AIは局所最適をするため、人間が全体像を保つ必要がある	アーキテクチャ図を描く、ポストモーテムを読む、システム設計を学ぶ
明確な仕様の記述	入力の質がエージェントの出力を決める	すべてのタスクに受け入れ基準、入出力の例、「スコープ外」を書く
レビューと検証	コード量が読める量を上回るため、どこを読むべきかを知る必要がある	テストを先に書く、プロパティベーステストを学ぶ、チェックリストを使ってレビューする
業務（ドメイン）理解	AIはコードを知っていても、あなたの会社が何を必要としているかは知らない	顧客やPMと一緒に仕事をする、ビジネスの数字を学ぶ
セキュリティ	エージェントはコマンドの実行、パッケージのインストール、データの読み取りの権限を持つ	OWASP、プロンプトインジェクション、最小権限の原則を学ぶ
コミュニケーションと意思決定	価値は正しい方向を選び、他者を説得することへと移る	デザインドキュメントを書く、プレゼンテーションをする、意思決定を記録する（ADR）

5.2 役割が変わるスキル（引き続き必要だが、使い方が変わる）#

アルゴリズム、データ構造、ネットワーク、データベース、OS：AIが誤った解決策を選んだときに気づき、根深い障害をデバッグするために使います。
プログラミング言語：速く書けることより、すらすら読めることのほうが重要になります。

5.3 価値が下がるスキル#

構文やAPIの暗記。
ボイラープレート、繰り返しのCRUD、手作業でのフォーマット変換を書くこと。
根底にある原理を理解しないままの「1つのフレームワークの専門家」。

6. レベル別の行動ロードマップ#

学生／新卒#

CSの基礎をしっかり固め、AIに聞く前に自力で解き、その後で比較する。
AIを家庭教師として使う：答えをもらうだけでなく、説明を求める。
小さくてもよいので、エンドツーエンドの実プロジェクト（デプロイあり、ユーザーあり）に取り組む。
コードを読む力とテストを書く力を早いうちから鍛える。

ジュニア（0〜3年）#

1つのエージェントツールを使いこなし、コミット前には必ずすべての行を読んで理解する。
デバッグや障害対応を自ら引き受ける：最も速く学べる場であり、AIがまだ苦手な領域でもある。
メンターを見つけ、丁寧なレビューを依頼する。AI時代のジュニアにとって最大のリスクは、できているように見えて、実は本当には理解していないことです。

ミドル（3〜6年）#

重心を設計へ移す：デザインドキュメントを書く、タスクを分割する、エージェント向けの仕様を書く。
チームのための「コンテキスト」を整える：エージェント向けの指示ファイル、規約、テスト、PRテンプレート。
深掘りする専門領域を1つ学ぶ：セキュリティ、パフォーマンス、データ、インフラ、または AI エンジニアリング。

シニア／テックリード#

人とAIが協働するワークフローを設計する：エージェントの権限設計、レビュー基準、CIにおける品質ゲート。
AI導入の前後で、実際の生産性（DORA メトリクス、不具合率、レビュー時間）を測定する。
人材パイプラインに気を配る：ジュニアが学ぶための「簡単な」仕事がなくなるなら、チームには新しい育成方法が必要です。

マネージャー／企業#

AIを使う際のデータとセキュリティのポリシー（顧客データ、ソースコード、シークレット）。
ライセンスを購入するだけでなく、AIツールと教育のための予算を確保する。
採用基準を見直す：ホワイトボード上のアルゴリズムだけでなく、問題解決力、レビュー力、仕様を書く力を評価する。

7. リスクと落とし穴#

リスク	兆候	対策
スキルの衰え	AIがないと自力でコードを書けない／デバッグできない	定期的に「AIなし」で作業する、まず自力で解いてから質問する
過信	読まずにコードをマージする、AIが書いたテストはAIが想定したことしか検証しない	レビューの必須化、テストの基準は人間が定める
技術的負債の加速	コードが多く、重複し、統一されたアーキテクチャがない	明確な規約、定期的なリファクタリング、複雑度の測定
セキュリティ	プロンプトインジェクション、シークレットの漏洩、AIが提案した偽パッケージ	エージェントへの最小権限、依存関係のスキャン、サンドボックス
世代の断絶	ジュニアのポジションが減る → 将来シニアが不足する	意図的な育成プログラム、AIとメンターを組み合わせたペア作業
著作権とコンプライアンス	生成されたコードがライセンスに抵触する、機密データが外部に送信される	承認済みツールのポリシー、ライセンスチェック

8. 結論#

開発者という職業の歴史は、自分自身の仕事を自動化してきた歴史です。コンパイラはアセンブリを自動化し、ライブラリは一般的なアルゴリズムを自動化し、クラウドはハードウェアを自動化し、そしてAIはコードを書く作業を自動化しつつあります。そのたびに、職業は消えるのではなく、より高いレイヤーへと移ってきました。人間の本当の課題に、より近い場所へ。

開発者一人ひとりにとっての問いは、「AIは自分に取って代わるのか？」ではなく、次のようなものです。

「今のボトルネックはどこにあり、自分はちゃんとその場所に立っているだろうか？」

2026年のボトルネックは仕様と検証です。2030年には、判断と責任になっている可能性が高いでしょう。基礎を深く理解し、業務を理解し、AIを規律あるチームのように使いこなす人こそが、最も必要とされる人材になるはずです。

9. 参考文献（引用前に改めて確認することをおすすめします）#

Stack Overflow, Developer Survey 2024 および 2025 – survey.stackoverflow.co
Peng, S. et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590
METR（2025年7月）. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. metr.org
GitHub Blog – Copilot に関する各種発表（2021〜2025年）
Karpathy, A.（2025年2月）– 「vibe coding」の概念を紹介した投稿
Anthropic – Model Context Protocol のドキュメント（modelcontextprotocol.io）および Claude Code
DORA – Accelerate State of DevOps Report（2023〜2025年版）、AIの影響に関する部分
技術史：Stack Overflow（2008年）、GitHub（2008年）、Docker（2013年）、Kubernetes（2014年）、ChatGPT（2022年11月）

関連資料：アニメーション付きのスライド（ベトナム語・英語に対応）。