はじめに
今回は、2025年を通して個人的に取り組んできた「生成AIを活用した開発」を振り返り、その現在地を確認します。
また、さまざまな企業で生成AIの活用が進む中で、ある程度試行錯誤した企業が揃って似たような課題を抱えている現状を確認し、今後の開発における課題感を整理します。
今後、生成AIによる開発が当たり前になるかもしれませんが、現状はまだ試行錯誤を繰り返している段階です。後々、「2025年はこんな一年だったな」と振り返るための記録になればと思います。
2025年の生成AI活用開発の振り返り
2025年は生成AIの活用が一気に広がった年でした。私自身も複数のプロジェクトで生成AIを活用した開発に携わり、多くの知見を得ることができました。
特に、コーディングを支えるサービスが多くローンチされたことで開発効率への影響が大きく、各社の生成AI活用はAIベンダーのサービス提供に依存する形で進みました。
簡単に2025年に提供されたサービスの中で、私が利用したものをまとめてみます。
2月
Claude 3.7 Sonnet + Claude Codeの一般公開
この頃は主にCursorを利用しており、Cursor経由でClaude 3.7 Sonnetを利用していました。どちらかというとフロントエンドのコードを書く機会が多く、Cursorでも十分でしたが、バックエンドではPHPを利用していることもあり、JetBrains統合がない状態でのコーディングはかなりしんどかった印象があります。
5月
Claude CodeのMaxプランの登場 / OpenAIによるWindsurfの買収騒動
Claude Codeがレート制限はあるものの、定額で使い放題になりました。これにより、タスクに失敗した際に気軽に再実行できるようになり、ある種「ガチャ」を引くような気分で、生成AIに何度もコードを書かせるアプローチを取るようになりました。
また、CLIツールであるためJetBrains製品とも併用しやすく、本格的にPHPを使った開発にも活かせるようになってきました。
この頃の感触としては、TSやPythonなどは生成AIを活用しやすい一方、PHPはまだまだ活用しづらいといった評価をされることが多かった印象があります。
個人的にはCLAUDE.mdやCursor Rulesの整備に一番力を入れていた時期だと思います。また、PHPStanやテスト戦略など、PHPのエコシステムの重要さを改めて認識した時期でもありました。
7月
OpenAIのWindsurf買収は破談、Windsurfの上層部がGoogle DeepMindへ移籍との報道
Windsurfの利用も試していた時期です。エージェントとしてはかなり優秀でUIも好みでしたが、Claudeの一部モデルの提供が遅れたことで解約することにしました。
いろんなAIツールを試すにあたって、年間サブスクリプションではなく月額課金にしておくことの重要性を再認識した時期でもあります。
8月
GPT-5リリース
モデルの性能が大きく向上し、これまで苦手としていた部分にも活用ができるようになってきました。
この頃から、ほとんど自分でコードを書くことがなくなり、レビューに専念するようになりました。生成AIに対して修正の指示を出すことと、自分で修正するコストがほぼ同じくらいになってきたためです。
10月
Cursor 2.0リリース / Codexの登場
相変わらず生成AIにコードを書かせることがメインの開発スタイルです。Codexの登場により、仕様をある程度相談した後は丸投げすることができるようになってきました。Kiroなどの登場もあり、さまざまな勉強会で「仕様駆動開発」の話を耳にする機会が増えました。
CursorがVS Codeベースのため利用を避けていましたが、Cursor CLIの登場によりJetBrainsでも利用できるようになりました。
各サービスの差がなくなってきており、いろんなサービスの中間プランを選択して利用料を抑えるようにしています。例えば、Claude Code MaxではなくProを契約して、ChatGPT Plusを併用するなどです。
11月
Claude Opus 4.5リリース
Claude Opus 4.5のリリースにより、さらにコード生成の精度が向上しました。特に、複雑なロジックやドメイン固有の知識を必要とするコード生成において、その効果を実感しています。
ドメインモデルを利用した設計の相談や、アーキテクチャの相談など、これまでより高度な要求にも対応できるようになり、かつCodexと比較しても素早く、コストパフォーマンスにも優れています。
ボトルネックはコーディングではなかった
2025年秋頃から、AI駆動開発関連の勉強会などでよく言われるようになったのは「生成AIを活用しても開発生産性は上がらない」という話です。というのも、生成AIが劇的に生産性を上げるのはコーディングに限られており、実際の開発プロセス全体のごく一部にすぎないためです。
各社が開発プロセスに生成AIを活用する上で、コーディング以外の部分、例えば要件定義、設計、テスト、デプロイなどにおけるボトルネックを解消しないと全体の生産性は上がらないという課題感を抱えています。
コーディングの生産性が10倍になったとしても、レビュープロセスは人間が行う必要があり、この問題は生成AI登場以前から変わらず、ボトルネックがシニアエンジニアにあるという状況です。レビューをサポートする生成AIツールとして、CodeRabbitやGreptileなどが登場していますが、シニアエンジニアのレビューを完全に代替するには至っていません。
また、コーディングにおいても、生成AIの出力はシニアエンジニアのレベルには至らず、あくまで平均的なレベルか、シニアエンジニアの実力を薄く伸ばしたようなレベルにとどまることが多いです。ジュニアエンジニアが使用した場合はさらに深刻で、本人が管理できないレベルのコードが提出され、シニアエンジニアのレビュー負荷をさらに上げる結果になり、かえって生産性を下げている可能性さえあります。このため、生成AIを活用した開発が有効なのは、シニアエンジニアが中心となって利用する場合と、質より量が求められる場合に限られるという状態になっています。
この問題は、個人的には外注での開発やオフショア開発などが流行った時期に似た状況に見えています。t_wadaさんなどが指摘している通り、「労力は外注できるが、能力は外注できない」状態になっており、この性質はソフトウェア開発と特に相性が悪いと考えています。ソフトウェアは多くの場合、最初に作られた品質から向上していくことは難しく、エントロピーは増大していく傾向にあります。生成AIを活用するとこのスピードも数倍に跳ね上がってしまうため、結果的にシニアエンジニアの負荷が増大してしまうのです。
反対に、ジュニアエンジニアの多くはより成長を急かされてしまう状況にあります。シニアエンジニアが生成AIを活用した場合のスピードが比較対象になってしまい、これままでは簡単な作業などを通して利益を生みながら成長投資を受けていたジュニアエンジニアは、生成AIの登場によって、成長するまでの期間、単にコストを「投資されるだけの存在」になってしまいました。採用市場などでも、成長曲線の傾きが大きくない場合は早期に見切られる傾向が強まっているように感じます。
生成AIと組織の問題への考察
本業、副業を通していくつかの開発組織を見てきた中で、生成AIを活用できている組織とそうでない組織には一定の傾向があるように感じています。
生成AIを活用できている組織の特徴
- シニアエンジニアが中心となって生成AIを活用している
- これまでのソフトウェア開発のプラクティスの多くを実践している
- コードレビューやテスト、CI/CDなどの自動化が進んでいる
- ドキュメントが整備されている
生成AIを活用できている組織の多くは、自動テストやドメイン駆動設計、堅牢な設計など、これまでソフトウェア開発の歴史の上で培われてきたプラクティスをしっかりと実践している傾向があります。生成AIがこれらの文脈を理解していること、人間の認知負荷が下がることによる生成AIの成果物のレビュー工数低減などが背景にあります。
また、シニアエンジニアが中心となって生成AIを活用していることも重要です。ここでいうシニアエンジニアとは、単に年齢や経験を重ねているだけや、技術力が高いだけでなく、ドメイン知識や設計能力、レビュー能力なども含めた広範なスキルセットを持つエンジニアを指します。こういったエンジニアが開発組織に対して生成AIの活用を促したり、自身が積極的に活用している組織ほど、生成AIを活用した開発に前向きになっていたり、生成AI活用の負荷を特定のシニアエンジニアに集中させることなく取り組めている印象があります。
裏を返せば、これまで忙しいからといってソフトウェア開発の基本的なプラクティスをおろそかにしてきた組織ほど、生成AIを活用した開発に苦戦しているように感じます。
CI/CDが整備されていない、テストコードがないような場合はそもそも生成AIを活用できる文化ではなく、また、これらの文化がない状態ほど生成AIの導入が難しい状態にあります。「当たり前のことを当たり前に実行し続けてきた組織」ほど生成AIによる恩恵を多く受けています。しかしながら、体感ではこういった文化がある組織は全体の2割程度にとどまっており、そもそも一定レベルのシニアエンジニアが組織に一人もいない場合も多々あります。
こういった組織はこれから生成AI活用が進むに従って淘汰されると感じています。なぜなら、生成AIによって、これから非エンジニアが簡単にソフトウェアを作成できるようになり、エンジニアが求められる品質水準がより上がっていくからです。
特にソフトウェアの品質管理、つまりSREやQA工程、セキュリティといった分野により注目されるようになると感じています。また、生成AIが完全に開発を代替するまでの間、もしくは代替した後でも、エンジニアがコードや仕様を理解する必要がある限り、人間の認知負荷を下げるために、ドメイン駆動設計やクリーンアーキテクチャなどの設計は重要なままだと考えています。
上流への生成AI活用
ユニットテストやQAなどの工程など、コーディングより後にある工程がボトルネックになることはもちろん、コーディングの前段にある要件定義やデザインなどもボトルネックになり得ます。
ビジネスサイドなど意思決定者の決定が遅ければそこがボトルネックになります。
これらの問題には、ツールとしてはCodex、もっと上段の要件定義ではManusのようなツールを活用しています。作ることが速くなってきた今、仮説検証の精度を上げていく必要があると感じており、試作段階では生成AIをフル活用して叩き台を作り、実際の開発までに試行錯誤を完了させる動きがより重要になってくると感じています。
また、デザインによる製品の差別化も重要なポイントですが、生成AIは現状フロントエンドをデザイン通りに実現することは完全にはできていないため、ある程度利用するUIコンポーネントを制限するなどの取り組みも、生成AIによる開発のボトルネックをデザイン工程にしないための方法のひとつです。
こういった取り組みはパフォーマンス改善に似ており、ボトルネックを特定してひとつずつ解消していく作業を繰り返す必要があります。つまり、経験がものをいう作業になってくるため、組織の問題に対してある程度の裁量をシニアエンジニアに渡して、副業人材や技術顧問なども活用していく動きが活発になりそうです。
ジュニアエンジニアとシニアエンジニアの格差
ジュニアエンジニアはこれまで期待されていたレベルから大幅に期待値が上がりました。ただ作業をするようなタスクのほとんどは生成AIに奪われ、成長の機会を失いつつあります。これから求められるのはより学習に多くの時間を使い、早くジュニアレベルを卒業することです。生成AIが苦手としているレベルの作業ができるようにならないと開発に貢献できない状態になりつつあります。 そのため、副業やフリーランスの案件が減ったり、採用市場が厳しくなっているのが2025年の現状だと思います。
シニアエンジニアはこれまでより多くのタスクをこなすことが可能になりました。生成AI活用によって、従来のタスク量の数倍を処理可能になっています。より多くの案件を抱えたり、並列稼働する可能性が高くなり、負荷が高まることが予想されます。副業やフリーランスの案件は変わらず存在しており、採用市場でもより求められているのが現状です。 負荷が上がりつつもジュニアエンジニアの教育や複数チームのリードなどを任されることも多くなるはずなので、相変わらず組織にとっては重要なポジションだと思います。
今後の展望
生成AIによってコーディングがボトルネックではなくなったため、他の工程のボトルネックを解消していくことが重要になってきています。
個人的にも、チーム内のコミュニケーションや意思決定のフローの整理、品質に対しての文化づくりや教育にかける時間の増加を意識して立ち回ることが増えてきました。
また、副業でも前向きに改善や生成AI活用を考えているチームをお手伝いさせていただくこともあり、思っているより貢献できている実感があります。
まとめ
- 生成AIはコーディングの速度をn倍にした
- しかし、開発のボトルネックは生成AI登場前からコーディングではなかった
- 要件定義などの上流、テストやQAなどの下流をボトルネックにしないことで全体のプロセスを調整する必要がある
- 当たり前のことを当たり前に実践し続ける組織が、今後生成AI活用において生き残る
- しかし、ある程度のレベルのシニアエンジニアの需要が上がっており、そもそも社内にいない可能性すらある
- 副業や技術顧問などで他社の活用事例やアドバイスをもらう動きが活発化しそう
