AIコーディング時代における開発者の役割変化：コーディング実行者から文脈・検証・プロダクト化の設計者へ

要約概要

• 核心的な主張

  • AIがコードを直接書き、修正し、テストする水準に到達したことで、開発者の役割は単純なコーディング中心から、問題定義、作業設計、検証、文脈管理、プロダクト化支援へと移りつつある。

• 構造的な要因

  • AIはコード生成の速度を大きく高めたが、コードがそのまま良いプロダクトになるわけではない。
  • 要件、ドキュメント、テスト、構造化、UX判断、保守性といった非コーディング領域の重要性がさらに高まった。

• 主な事例

  • Playwrightを通じて、AIにブラウザテストまで実行させた経験。
  • 反復作業をコマンド・スキル・ワークフローとして明文化した経験。
  • AIで作ったフロントエンドのプロトタイプが、見た目は優れていても内部構造は脆弱だった事例。

• 解決の方向性

  • AIにコードだけを任せるのではなく、開発全体の手順と基準もあわせて設計すべきである。
  • 開発者はAIの成果物をレビューし、文脈を残し、持続可能なプロダクトにつながるよう構造を整える必要がある。

---

序論

AIコーディング時代への転換

• この投稿は、「人が直接コーディングしない時代に、開発者は何をすべきか」という問いから出発する。
• 筆者は以前、AIは幻覚やミスを起こすため、最終判断は人が担うべきだと考えていた。
• しかし最近のAIモデルの性能向上により、AIが課題把握、ファイル探索、コード修正、テスト通過までこなせる水準に達したと評価している。
• この変化によって、開発者は単にAIを補助ツールとして使う段階を超え、AIに開発手順そのものを実行させる方向を考えるようになる。

核心的な問題意識

• AIがコードをうまく書けるようになったからといって、開発者の役割がなくなるわけではない。
• むしろコーディングが自動化されるほど、開発の他の要素がより鮮明に現れる。
• 要件整理、意思決定の記録、テスト設計、コード構造の管理、プロダクト体験のレビューなどが、開発者の中核課題として浮上する。

---

本論

1. AIはコード作成ツールから作業実行の主体へ移行した

• 筆者は、AIが単なるコード断片の生成を超えて、実際の開発作業フローを処理できるようになったと見る。
• 以前はAIの成果物を人が継続的に監視・修正しなければならなかったが、今ではAIに作業を任せて結果を検収する方式が可能になった。
• SWE Benchのようなベンチマーク性能の向上は、この変化を示す指標として言及されている。
• 核心的な変化は、「AIはコードを書けるか」ではなく、「AIにどこまでの範囲を任せられるか」へと問いが変わった点にある。

2. AIが失敗するとき、問題は「能力不足」だけではない

• AIはいまも常に成功するわけではない。
• エラーが繰り返されたり、修正したと言っても実際の画面では問題が残っていたりする場合がある。
• 筆者は当初、人がエラーをコピーしてAIに渡す方法で対応していた。
• その後、Playwrightを使ってAIにブラウザを直接開かせてテストさせることで、人が行っていた検証手順もAIに任せられると気づいた。
• この事例は、AIの限界だと思っていたものの一部が、実際にはユーザーが指示していなかったために生じた限界だったことを示している。

3. AI Native的な発想は、手順全体を委任するやり方である

• 筆者は、AIを単なる補助ツールとして使う見方から離れ、自分が行っていた手順全体をAIに実行させる方向へと転換する。
• 反復作業をコマンド、スキル、ワークフローとして作り、自身の暗黙知を明文化しようと試みる。
• 例として、/plan, /prd, /debug, /refactor, /verify, /retrospect のようなコマンドフローを作る。
• 重要なのは、AIに単に「コードを書け」と言うのではなく、いつ質問し、いつ止まり、いつ検証するかまでルール化することだ。
• これにより、開発者は自分の作業方式と判断基準を、AIが再利用できる構造へと変えていく。

4. 個人のノウハウは急速にツール機能へ吸収される

• 筆者が自作していたコマンドやワークフローは、時間が経つにつれて Skill、memory、hooks、orchestration のような公式機能や概念として現れる。
• 個人が見出したAI活用方法論は、効果があるほど素早く製品機能や共通手法へ吸収される。
• そのため、AIをうまく使う特定のプロンプトやコツだけでは、長期的な差別化を作りにくい。
• 重要なのは方法論そのものより、その方法論を実際の問題に適用して、どこまで作り込み、どのような限界を経験したかである。

5. AIは開発者が扱える問題の大きさを広げる

• AIは、筆者が過去にはコストと時間のため試せなかった大きなアイデアを、実際に実験できるようにした。
• たとえば、コードとドキュメントをキャンバスのように広げて見るツール、MDビューア、コード分析ツール、開発支援ツールなどを素早く作ってみる。
• 核心は、AIが完成品を即座に作ってくれることではなく、着手のハードルを下げてくれる点にある。
• 開発者は「これを作れるだろうか？」から、「ひとまずどこまで作れるだろうか？」へと思考を切り替えるようになる。

6. 大きな問題を扱うと、コーディング以外の開発業務が見えてくる

• AIによってコード生産量が増えると、開発者はすべてのコードを直接読み、文脈を頭の中に保持することが難しくなる。
• 自分でコーディングしていると自然に蓄積されていた文脈、判断、構造理解は、AIにコーディングを任せると自動では残らない。
• そのため、ドキュメント、テスト、イシュー、作業報告書、変更理由の記録が重要になる。
• これは管理業務ではなく、AI時代に開発の文脈を維持するための中核的な装置となる。
• コーディング能力と同じくらい、文脈と判断を保存する能力が重要になることが強調される。

7. コミットとテストの増加が、そのままプロダクト改善を意味するわけではない

• AIを活用すると、コミット、ファイル、テスト、ドキュメントの数は急速に増える。
• しかし数値が増えたからといって、プロダクトが実際によくなるとは限らない。
• 機能は追加されてもUXがぎこちなかったり、テストは通っても実際の画面フローが不安定だったりする問題が発生する。
• 筆者は当初、これをコード品質や構造の問題としてのみ見ようとしていた。
• しかしコード構造を改善しても、プロダクト体験が自動的によくなるわけではないことを経験する。
• 結局、コード生成とプロダクト改善は別の問題であり、プロダクト性に対する判断が別途必要になる。

8. フロントエンドは、AIが特に不安定になりやすい領域である

• AIはダッシュボード、ランディングページ、管理画面のような、それらしい初期UIを素早く作れる。
• しかし実際のプロダクト水準のフロントエンドには、デザインシステム、状態管理、アクセシビリティ、キーボード操作、例外状態、ユーザーフローなど、複雑な基準が求められる。
• フロントエンドの多くの要求は、「自然に」「あまり違和感なく」「選択されている感じがするように」といった曖昧な言語で表現される。
• AIは、こうした曖昧な要求をコードに変換する過程で、結果が容易に発散する。
• そのためフロントエンドでAIをうまく使うには、うまくできた部分は固定し、不足している部分だけを再修正させるための基準と判断力が必要になる。

9. 良い成果物は一度では出てこず、収束の過程を通じて作られる

• 筆者は、ある企画担当者がAIで作った完成度の高いプロトタイプを見て認識を改める。
• その成果物は、特別なプロンプトひとつで作られたのではなく、「できるまで」繰り返し修正した結果だった。
• この事例は、AI活用の核心が単なる自動生成ではなく、不足している部分を見続けて再度要求する収束プロセスにあることを示している。
• 良い結果を作る人は、AIが作った成果物の何が足りないかを判断し、望む水準に達するまで粘り強く調整する。
• AI時代でも、人の基準、感覚、継続的なレビューが成果物の差を生む。

10. 開発者は、有望な成果物をプロダクトへつなげる役割を担う

• AIで作られた成果物は、見た目は良くても内部のコード構造が脆弱なことがある。
• 状態管理が不安定だったり、コンポーネントの責務が曖昧だったり、テストが実際のフローを保証できなかったりする問題が生じる。
• 開発者の役割は、こうした成果物を無条件に低く評価したり廃棄したりすることではない。
• 同時に、そのままプロダクト化してもいけない。
• 開発者は、有望な成果物がさらに先へ進めるように構造を整理し、リスクを示し、テスト可能な単位を作り、文脈を残さなければならない。
• つまり開発者の役割は、「最後まで一人で作る人」から、「AIと人が作った成果物を持続可能なプロダクトへつなげる人」へと拡張される。

11. AI時代の開発の役割は一つに収束しない

• コーディングのハードルが下がると、開発に参加する人のタイプも多様になる。
• 企画担当者、デザイナー、PM、現場担当者も、AIを通じて動くプロトタイプや内部ツールを作れるようになる。
• これは開発者の必要性がなくなるという意味ではなく、開発に関わる役割がさらに細分化されることを意味する。
• 筆者はこれをYouTubeのエコシステムにたとえる。
• YouTubeが映像の専門家をなくしたのではなく、出演者、編集者、企画者、チャンネル運営者、プラットフォーム制作者などの役割を多様化したように、AIも開発の役割を多様化しうる。
• 今後は、深いシステムを作る人、プロトタイプをプロダクトへ磨き上げる人、AIがうまく作業できるレイヤーを作る人、問題を直接解決する人が共存する可能性が高い。

---

結論

開発者は、コーディング後の開発を設計しなければならない

• この投稿の結論は、「コーディングを続けるべきか、手放すべきか」という二項対立ではない。

• AIがコーディングを実行できるようになった以上、開発者はAIに何を任せ、何を自分で判断すべきかを経験的に学ばなければならない。

• 特に次の能力が重要になる。

  • 問題をより大きく設定する能力
  • 反復手順をスキルやワークフローにする能力
  • 要件、ドキュメント、テスト、イシューを構造化する能力
  • AIの成果物をレビューし、不足部分を再指示する能力
  • 粗い成果物を持続可能なプロダクトへ磨き上げる能力
  • コード外のツールや業務フローまでAIと接続する能力

核心メッセージ

• AIは開発者の期待ほど完璧ではないが、思っている以上に多くのことを実行できる。
• AIにできないと判断する前に、実際にどこまで任せられるかを実験すべきだ。
• 逆に、AIが簡単にしてくれるからといって、成果物をそのまま信頼してはならない。
• 開発者は、AIが作った結果を判断し、収束させ、文脈を保存し、プロダクトへつながるようにする役割を担うべきである。
• 結局、AI時代の開発者はコードを直接たくさん書く人というより、AIと人が作った成果物がより良い結果へつながるよう、問題・手順・基準・文脈を設計する人に近づいていく。