AI支援コーディングはソフトウェアエンジニアリングをどう変えるのか：不都合な真実
(newsletter.pragmaticengineer.com)- GenAI（LLM）は、コードの自動生成や補助機能によって開発者の生産性を高めている
- これまでも「コーディング不要ツール」は存在していたが、実際のソフトウェアエンジニアリングの過程には依然として固有の複雑さがある
- ChatGPTの登場以降、AIツールの進化の速さは際立っているが、すべての工程を抜本的に変えるというより、与えられた問題の一部工程を大幅に短縮する役割を果たしている
開発者の実際の使い方は二つに分かれる
- ブートストラッパー（bootstrappers）
- Bolt、v0、Screenshot-to-code のようなツールで新規プロジェクトやMVPを素早く実装
- デザイン（Figmaなど）やラフなコンセプトから、AIが完全な初期コードベースを生成する
- 数日ではなく数時間で動くプロトタイプを作れる
- 本番品質としては不完全でも、アイデア検証に強みがある
- 迅速な検証と反復を重視する
- イテレーター（iterators）
- Cursor、Cline、Copilot、WindSurf などを日常の開発プロセスで活用する
- コード補完、自動リファクタリング、テスト・ドキュメント生成などにAIを使う
- 複雑なテスト、ドキュメント化、リファクタリングなどをAIに任せつつ、結果を絶えず点検する
- 「ペアプログラマー」のように問題解決を一緒に進める用途で活用する
- 開発者がAIの提案を選択・修正・補完する過程を繰り返し、より良いコードへ発展させる
70%問題：「最後の30%」の難しさ - AIの学習曲線の逆説
- AIは70%程度までは素早くコードを作れるが、最後の30%が大きな足かせになる現象
- 小さなバグを直すと別の部分が壊れる、という悪循環が生まれる
- 特に非専攻者やジュニアは、AIが提案するコードをすべて受け入れてしまい、問題を連鎖的に引き起こしやすい
- AIが提案する修正がなぜ問題を起こすのか把握しにくい
- 熟練したシニア開発者は、バグ原因を素早く推論し、コードを再構造化し、セキュリティや性能も追加で考慮して、AIが見落とした部分を補う
- AIを積極的に活用しつつも、絶えずレビューとリファクタリングを行い、「保守可能なコード」に仕上げる
- ジュニアや非開発者がAI生成コードを無批判に受け入れると、実運用環境で簡単に崩れる「砂上の楼閣コード」が生まれる危険がある
- 知識の逆説
- シニアはすでに知っている問題をAIと一緒に素早く実装できる
- ジュニアはAIを通じて学ぶ必要があるが、基礎知識が不足しているとデバッグや検証の過程で大きな困難に直面する
効果的な利用パターン
- AIで草案を作り、その後に細分化
- AIが初期実装を行ったら、人間がそれを直接レビュー・リファクタリング・テストする
- エラー処理や例外ケースを手動で追加し、自動テストとレビュー工程を強化して信頼性を高める
- モジュール性、エラー処理、型定義、アーキテクチャ設計を強化し、保守可能にする
- 作業単位ごとに対話を維持
- 一度に大きな文脈を渡すより、小さな問題ごとに独立したプロンプトを使って集中的な回答を得る
- 変更を頻繁にレビューしてコミットし、短い周期でフィードバックを反映する
- 「信頼するが検証する」アプローチ
- AIに草案を作らせつつ、重要なロジックやエラー処理、セキュリティ問題などは人間が直接確認する
- 常にテストケースを書き、性能・セキュリティ・構造的妥当性などを入念に点検する
開発者への示唆
- 小さく始める
- よく定義された小さな作業、範囲が明確な問題からAIを活用し、生成されたコードを丁寧にレビューする
- 大きな機能に進む前に、テストと文書化を徹底する。そして段階的に範囲を広げる
- モジュール化を維持
- コードベースを適切に分離し、AIが作ったコードが構造的に混在しないようにする
- ファイルや機能を小さな単位に分け、インターフェースと依存関係の流れを明確に定義する
- 経験を信頼する
- AIを補助者として活用しつつ、最終判断は自分の経験を基準にする
- 怪しいコードや設計は疑い、エンジニアリング標準を守るほうがよい
エージェント型（agentic）ソフトウェアエンジニアリングの台頭
- 従来はAIツールが命令に応じてコードを生成するレベルだったが、今後は エージェント（Agentic） という概念へ進化する
- エージェント型AIは、自ら目標を計画・実行・検証し、より自律的に動作する
- Claude（Anthropic）、Cline などは単なる自動補完を超え、ブラウザを自動で立ち上げてテストまで実行する
- デバッグの過程も変わる
- エージェントが自ら潜在的な問題を見つけ、テストセットを実行し、UIの状態まで点検して修正案を提案できる
- 将来のツールはコードだけを扱うわけではない
- UIスクリーンショット、図表、音声対話など複数の入力チャネルを理解して統合できる
- この流れの中で開発者がすべきこと
- AIが創造的に作業を進めつつも、人間のガイドを受け、健全なアーキテクチャの中で動くよう維持する
- 人間とAIの間に強力なフィードバックループを構築する
- 人間が大枠と目標を設定し、エージェントが詳細作業を処理する協業モデルが生まれると予想される
- 「最も重要なプログラミング言語は英語だ」という言葉のように、明確で正確な自然言語で要件を表現する能力が重要になる
ソフトウェア職人技は戻ってくるのか？
- AIのおかげでプロトタイプやデモは素早く作れる
- しかし、実際のユーザーが多様な環境やエッジケースでソフトウェアを使い始めると問題が発生する
- ユーザーには理解不能なエラーメッセージ
- クラッシュを引き起こす特殊環境（エッジケース）
- アクセシビリティをまったく考慮していない設計
- 遅い端末で発生する性能問題
- UI/UX などの細部が品質を左右する
- 消費者視点で「よく磨かれた」製品になるには、細やかさと人間的な配慮が必要だ
- AIが反復作業を減らしてくれれば、開発者はこうした細部の完成度に集中できる
- ユーザー体験、エッジケース、意味のあるエラー処理など、人間的でありつつ専門的な領域により多くの時間を注げる
追加の考え
- ソフトウェアエンジニアリングの過程 には、企画、設計、実装、検証、監視、保守などさまざまな領域があり、現在のAIは主に「コードを書く」領域を大きく効率化している
- 過去にも COBOL、Visual Basic、ノーコードプラットフォームなどによって「非開発者でも簡単にソフトウェアを作れる」という試みは続いてきたが、複雑さが増すと結局は熟練開発者が必要だった
- LLMツールがコード量を爆発的に増やすほど、複雑なプロジェクトではより多くのシニアエンジニアが必要になる見通しだ
- AI活用能力を備えた熟練開発者は、自身の価値をさらに高められる
- 結論として、AIツールは開発者を完全に置き換えるというより、洞察と経験を持つ開発者をさらに強力にする方向へ進化すると見られる
追加の考え（Gergelyのコメントを含む）
- ソフトウェアエンジニアリングにおいて、コーディングそのものが占める比重は昔からそれほど大きくなかった
- かつてフレッド・ブルックスは、ソフトウェア作業時間をおおよそ
- ⅓ 企画
- ⅙ コーディング
- ¼ コンポーネント・システムテスト
- ¼ システムテスト（すべてのコンポーネントを手作業で）
に分類していた
- 現在の見方ではコーディング（テスト込み）の時間は増えたが、計画、コードレビュー、監視、ロールアウトなどは依然として重要な割合を占める
- 20% 企画
- 40% コーディング（コード + テスト）
- 20% コードレビュー（他人のコード）
- 20% 本番準備 + ロールアウト + その期間中の小さな修正 + 監視 + アラート
- ソフトウェアをうまく作るプロセス
- 1. What: 何を作るか決める
- ブレインストーミング、デザイン、ユーザーテスト、プロダクトマネージャー・ビジネス関係者との協業などを含む
- スタートアップではこの段階が非常に短いこともある（「まず作って反応を見よう」という形）
- すでに定着した企業なら、既存顧客を混乱させないよう、何を作るか決めるのにより多くの時間がかかる場合がある
- 2. How: どう作るか計画する
- 製品・機能・サービスをどう実装するか具体的に設計する
- アーキテクチャへの影響、依存関係、テスト戦略などを検討する
- スタートアップはこの工程を省いてすぐ実行に入ることもあるが、大きな組織では事前設計を無視すると後で問題が大きくなりうる
- 多くのチームは Design doc、RFC、ADR などを活用して、ある程度の計画プロセスを踏んでいる
- 3. Build: 実際に機能を実装する
- 望む機能・製品をコードとして書き、正常に動作することを確認する
- 4. Verify: 検証する
- 本番にデプロイする前に、想定どおりに動くかを入念に確認する
- 特に金融サービスのように誤動作が致命的な結果を招きうる場合は、QA工程を徹底する
- 5. Ship it: リリースする
- 変更をマージして顧客へリリースする
- 本番デプロイの方法はさまざまだ
- 6. Monitoring and oncall: 監視とオンコール
- 製品に問題が起きたら即座に検知して解決する
- 同じ障害が再発しないよう、事後対応もあわせて進める
- 7. Maintain: 保守する
- ユーザーの不満・フィードバックを収集し、どのバグを直すか、どの機能改善を優先するかを決める
- 無視してよいフィードバックを選別する過程も含む
- 8. Migrate: 移行する
- 製品そのものが大きく変わったり技術スタックが変わったりする際には、大規模なマイグレーションが必要になることがある
- AIツールは現在「Build」段階で大きな助けになるが、上記の残り7つの部分でもどこまで有用か考える必要がある
- 1. What: 何を作るか決める
- 1960年代以降、「非開発者でも開発者なしでソフトウェアを作れる夢」は続いてきた
- COBOL、Visual Basic、ノーコードなどがその例だ
- 簡単なWebサイト程度ならまったくコーディングなしでも作れるが、複雑な製品では依然としてエンジニアリング作業が必要だ
- 表現力が高まるほど、具体的に「どう動くべきか」をAIに細かく指示しなければならず、複雑性は増していく
- AIが大量のコードを書けるようになるほど、それを保守しアーキテクチャを扱う専門エンジニアの必要性はむしろ高まる可能性が高い
- 今日のLLMを使った働き方を身につけたシニア開発者ほど生産性が高まり、企業でより大きな価値を発揮できる
AIエージェント：大きな約束だが、2025年時点では「未知の領域」でもある
- LLM登場から2年が経ち、多くの開発者がLLMをコーディング・ソフトウェアエンジニアリングに活用する方法を学んできた
- 試作、未知の言語への切り替え、成果物の正確性を検証して誤答（幻覚）を見抜くといった作業で、LLMは大きく貢献している
- しかしAIエージェントはまだ初期段階にある
- 現在広く使えるエージェントはDevin程度で、月額500ドルと高価で評価も割れている
- ベンチャー資金が流入する中で、より多くのAIコーディングエージェントツールが登場すると予想される
- 価格も徐々に下がる可能性が高い
- GitHub Copilot は2025年にエージェント型の Copilot Workspace を一般提供するとみられる
- Stripeの元CTOが設立した /dev/agents なども登場予定だ
- AIエージェントは、より遅い応答（「思考」プロセス）と高いコストを受け入れる代わりに、精度向上を目指す
- 実際にこの方式がどれほど精度を高め、どのようなエンジニアリング事例で大きな生産性向上をもたらすかは、なお未知数だ
熟練ソフトウェアエンジニアへの需要増加の可能性
- 熟練した（シニア以上の）ソフトウェアエンジニアは、今よりさらに必要になるかもしれない
- 彼らはAIツールをより効果的に扱え、「優れた成果物」がどんなものかを理解し、正確に「指示」できる
- 誤ったコード生成を検知したとき、生成プロセスを止めて自らソースコードを修正すべき地点を判断できる
- AIツールの助けで、はるかに多くのコードが書かれ、より多くの個人・企業が独自ソリューションを作るようになるだろう
- しかし複雑性が増すほど、それを制御できる熟練エンジニアが必要になる
- 既存のテック企業でも、AIによって増える複雑性に対応する人材が必要になる可能性が高い
- ソフトウェアエンジニアが AIと協働する能力を高めれば、より生産的で、より価値の高いエンジニアになれる
- ツールを完全に「手なずける」方法を身につけるまでには時間がかかるため、急速に変化するツール環境の中で積極的に実験し学ぶことが重要だ
11件のコメント
本当にとても良い内容の記事ですね。
最後の段落である「熟練したソフトウェアエンジニアへの需要増加の可能性」にはとても共感します。知っているほど上手く使える、ということなのでしょうね？ ^^
Expo 52 のように、最近大きな変化が起きた領域では、賢い Claude もあまり役に立ちませんでした。
古くてすでに消えたコードをしきりに提案してきて、むしろ邪魔になった経験があります。
やはり AI は「見る目」が鍛えられていてこそ、うまく使えるのだと思います。
些細な話ですが、
/dev/agentsはコーディングエージェントではないと理解しています。まだリリース前ですが、自らを「AIエージェントのためのOS」と説明しています。個人的には、将来的に（あるいは見方によっては中期的に）、すべてのエンジニアの役割においてコーダーとしての役割は縮小し、TPMとしての役割は拡大すると考えており、そこに賭けています。
コードはCursorのほうがより上手く書けるので委任し、人間はその上の抽象化されたレイヤーで業務の大半を担うようになるのではないかと思います.
共有ありがとうございます。私も関連する文章を最近1本書いたのですが、似ている面がありますね。 https://www.stdy.blog/can-junior-beat-coding-agent/
要約：AIによる開発者の未来（希望編）
?? : もう開発者は必要ないね（ブラック中小企業編）
まさかｗｗｗｗｗ
1+ ｗｗｗ
笑 100点