【2025年6月時点】AI普及後のシステム開発現場はどうなるか妄想する

1. この記事は何？

　2025年のAI界隈ではエージェントが大ブームとなっています。2024年はLLMを使ったアプリとして皆がチャットボットとRAGのシステムを作っていましたが、2025年のこのジャンルのキラーアプリはどうやらコーディングエージェントということになりそうです。多くの会社がこぞってコーディングエージェントをフィーチャーした開発ツールやサービスを発表しています。今後システム開発にAIを使うことは必須となるでしょう。そのような状況下で、システム開発の在り方も変わっていかざるを得ないと考えます。そこで、実際に何がどう変わるのだろうかと考えてみた結果が本記事となります。技術の発展というのはとかく予想の斜め上を行くものなので外れも多くなりますが、2025年6月時点でいったん考えて見ました。ちょっと考えても今までの常識を見直さざるをえないのではないかと思われます。一種の思考実験としてお読みいただければ幸いです。

2. この記事で書かないこと

　群雄割拠する最新のAI支援型開発ツール／サービスにどんなものがあるか、具体的にどんな機能があるかの詳細については割愛します。そのような記事は今も日々量産されているので、そちらを見ていただければ幸いです。

3. 開発プロセスとプロジェクトの変化

• 今までの「開発者の大量動員による労働集約的開発」から「AI支援開発ツールを最大限に活かして生産性を上げる形態」に開発プロセスが見直される。１プロジェクトに参画する開発者の人数は減る。特に手作業をするためだけに参画していた要員は今後AIエージェントに代替され不要となっていく
• 現時点のAIにとっては小規模なコードベースの方が扱いやすいため、小規模案件が増える。それにともない短いスケジュール期間でまわす案件が増える
• 技術的なハードルが下がった結果、自社開発案件が増える。ITの専門家以外の職種からの参画者も増える
• プロジェクト管理業務にもAIを使うのが当たり前になる。細かいタスクの見積りやスケジュール策定、進捗管理はAIに任せた方が人間よりうまくいく可能性がある¹
• あらゆるドキュメントはAIで処理しやすいことが重要になり、MarkdownとMermaidで書かれた文書が主流となる。Excel方眼紙などのAIと相性の悪い文化は終焉に向かう

• 進捗をExcel線表で管理する時代も終わる。線表もMarkdown(Mermaid)にするか、JiraなどのサービスをAIがMCP経由で扱うようになる²
• AI支援ありの開発とAI支援なしの開発は同じシステム開発でも考え方がまったく異なる別種の業務となり見積の考え方も別ものになる。長期的にはビジネスとしてのシステム開発においてAI支援を使わない開発は絶滅する
• 既存の大規模システムの改修にはAIが入りづらいため、しばらくは従来の労働集約型開発体制が残り、昔ながらのやり方にこだわる開発者のラストリゾートとなる。ただしおそらくそこは買い手市場であるため低賃金重労働化が進む
  　

4. システム企画・要件への影響

• 開発費用の低コスト化が進み、システム化のハードルが全体に下がって様々なアイデアのシステム化が試みられるようになる。今までだったらボツになっていたようなアイデアにもGOサインが出やすくなる。一方で撤退や中止の判断も早くなる
• コストを削減するためのシステム化（守りのシステム化：失敗許容度低）よりもビジネス価値を創造するためのシステム化（攻めのシステム化：失敗許容度高）が増える。そのようなシステム開発では外注よりも内製が有利になる
• 要件定義と設計の不確定性が上がり、何が正解かやってみないとわからない要求が増える。そのような要求をウォーターフォールで開発するのは難しくなっていき、アジャイル開発が増える³

• もちろんAI支援によって要件定義プロセスそのものの精度は上がるけれども大きな流れは上記のようにと考える

5. 設計へのAIの影響

• 大規模なシステムはAIを適用しづらいため小規模単位に分割され互いに連携するようなアーキテクチャの採用が増える。そのような観点からマイクロサービスやモジュラーモノリスのアーキテクチャが見直される
• システムが想定するユーザーは人間ユーザーとAIエージェントの2種類となり、だんだんと後者が重要性を増しシステムにおける主要アクターとなっていく
• 詳細設計書（ここではソースを日本語に翻訳したようなドキュメントを指す）を人間が書くことはなくなり、基本設計をもとにAIが生成したソースからこれもAIによって詳細設計へリバースするのが当たり前になる。長期的にはAI支援によってプログラム知識がない発注者側担当者でもソースを直接理解できるようになるため、ソースさえあればよくなり、詳細設計書自体が不要となる（もし必要になってもその時点でAIに生成させる）
• ソースや設計の「複雑さ」の基準が人間基準ではなくAI基準になる。AIが処理しやすければ多少人間が読みづらくても良い（AI経由で理解できればよい）という考え方に変わる
• システムのUIはエージェントを想定したプロトコルベースのインターフェイスが中心になっていく。人間向けの画面も必要なので残るが、UIはチャット(または音声による会話)ベースの入力に対してその場で画面が生成されるような簡単なUIになっていく可能性がある。その結果画面操作手順を覚える必要はなくなりマニュアルが消滅する

6. コーディングへのAIの影響

• コードは９割以上エージェントに書かせ、人間はちょっとした手直し以上のコードを書かないのが普通になる
• 一人の担当者が並行で複数タスクを進めることが可能になり、それが当たり前となる。gitのブランチを同時に複数切ってそれぞれを担当するエージェントが並行作業するようになる

• 開発者が担当する機能のコードベースの中身全体をすべて理解しなくてもよくなる。すでにコード内容の理解を放棄し開発スピードを優先する開発スタイルが出てきており、Vibe Codingと呼ばれている

• AIが生成したコードをすべて理解して 隅々までレビューすべきと考える人々（AI慎重派） と、すべて理解しなくても細かいことは AIに任せればよいと考える人々(AI楽観派) が派閥を作って対立する。このあたりの考え方は対象のドメイン領域によっても変わってくる（金融系ならAI慎重派が主流になるなど）
• やがてAIの性能が上がるにつれてAI楽観派が勢いを増し、重要なのはコードの外部仕様や品質を管理しコントロールできることであり、AIでそれが可能になるなら必ずしも中身を完全に理解する必要はないという考え方が浸透していく。そうしないと人間の処理能力がネックとなって生産性が上がらないため、市場の要請からもそうなる
• 最終的に、人間がコードの中身をまったく理解しなくてよくなった結果(現在のITエンジニアがコンパイラの吐くマシン語を理解する必要はないのと同様)、コードが表面から隠蔽されノーコード化する動きが出てくる。この場合のノーコードは従来のような「機能に制約を付ける（＝不便にする）代わりに開発を楽にするトレードオフとしてのノーコード」とは根本的に異なる新しい次元のノーコードである。従来型のノーコードツールはAIを前提とした新型ノーコードツール（おそらく今のコーディング・エージェントが発展したもの）に置き換えられる

7. テストや品質管理へのAIの影響

• テストの実行（テストコード実行やE2E打鍵）はすべてAIが行うようになるので、人間がテストしていた時代とはけた違いの量のテスト項目が実施可能となる。人間がテストしていた時代には考えられなかったような密度でのテストが普通になる
• 当然テスト設計も自動化する。設計書から大量のPCLがAI生成によって作られるようになる。あるいはPCLすら書かれなくなり、テストコードから必要に応じてテスト仕様を抽出、閲覧するようになるかもしれない
• AIの性能が低い間（過渡期）はまだ人間がテスト仕様をレビューするが、レビュー自体もAIによって支援され、AI自体の進化とノウハウ蓄積によってだんだんとAIに完全に任せられる ようになる。

• AIによる脆弱性診断（SAST/DAST）の高度化も進むが、AIが生成したコードの監査・検証手法の確立が新たな課題となる

8. 技術選定への影響

• 技術選定の基準はあらゆる点で「AIで処理しやすいこと」となる
• 具体的には、以下のような点が重要になる
  1. テキストベースであること
  2. 普及率が高く学習対象にできる情報が多いこと
  3. OSSで公開されており無料で使えること
  4. アーキテクチャが重厚でなく自動生成しやすいこと
• 具体的には、これらの基準を満たしている TypeScript、React(Next.js)、Python などが有利となる。これは現在のコード生成系Webサービス(Bolt.newなど)が生成するソースの開発言語が軒並みTypeScript+Reactであることからも予想できる
• 文書は Markdown と Mermaid で書き、データ形式は yaml や json などテキストベースが主流となる。これらは git で管理しやすいことも重要
• Javaや.NET系言語はインテグレーションとデプロイが面倒なためAI時代には不利だが、バックエンド技術としてはTypeScriptよりも有利な面があり、生き延びる可能性はある

• Rubyは普及率が、VBAはファイルがバイナリベースであることがネックとなるが、IDEがAIに対応すれば生き延びるかもしれない
• 開発ツールは軽いものが好まれ、重厚なIDEを使う時代は終わる（デバッガでコードをステップ実行することはほぼしなくなる）。AI補完機能付きエディタとコマンド型開発エージェントの組み合わせが現状では最強。具体的にはVSCode+Claude Code。Cursorもこの形態の一種とみなせる
• 【2025.6.26追記】そう書いた途端に Gemini CLI が出たので、これも当然選択肢に入ってきます──

• システムアーキテクチャは SPA でフロントエンドを作り、バックエンドは RESTでAPIを作る形態が基本となる
• 基盤はクラウド上のIaaSが主流となる。基盤構築はMCPを経由して開発エージェント+IaCで行うのが当たり前になる
• バージョン管理は現時点では git の他にまともな競合が見当たらない。普及率で圧倒的ですでに gitHub と合わせてAI開発の生態系に組み込まれており、(GitLabなども健闘しているが)その地位は揺らがないとみる
• 将来的にはあらゆるツールやサービスのUIはMCP対応し、概念的な理解さえすれば細かい操作方法を覚えなくてよくなる
• 人間ユーザよりもエージェントユーザがシステム運用の主役となりエージェント用プロトコルであるMCP、A2Aへの対応が重要になる

9. 現状のAI開発の弱点

• 2025年6月時点においてAIの適用が一番難しいと思われるのは JavaとCOBOLで作られた既存レガシー案件、特に大規模なものだと思われる。これらのシステムではJavaの１クラスでソースが軽く１万行を超えるようなものが普通に存在する。この巨大なコード群は現状のLLMが有効に処理可能なトークン数の限界を容易に超えてしまう。現状のLLMの主流アーキテクチャであるTransformerの最大の弱点がこの点で、その中核機能である自己注意機構が本質的に入力トークン数の二乗でスケールしてしまう構造である以上、処理可能トークン数の上限は簡単には上げられない
• この種のレガシーな既存システムはすでに非常に多く作られており、AIで開発や保守をしたいという需要もかなり強いはずで、トークン数上限の問題に対しても何らかのソリューションが考案され解決されていくと思われる
• それまでの妥協策として現状のAIが処理できる粒度にシステムを整理したり分割する仕事の案件が今後増える可能性もある
• レガシー案件は課題である一方、AIを活用した分析・リファクタリング支援など、新たなビジネスチャンスにもなり得る。ただし、それに対応できる高度なAI開発スキルセットとレガシー技術への深い理解を併せ持つ技術者の存在が必須要件である

10. 労働スタイルの変化

• AIによるリアルタイム翻訳が当たり前となり、回線インフラも整備が進んでオンラインミーティングとリモートワークで進めるプロジェクトが当たり前となる

• そのため、プロジェクトの発注者側も参画者側も物理的なロケーションや国籍はあまり関係なくなっていく。それよりも身元の保証、ビジネスする相手として信頼できるかが重要となるため会社組織は依然として重要となる
• 今まで外国人技術者はコミュニケーションの難しさを理由に下流工程での採用が多かったが、今後はその点は関係なくなり上流工程も普通に担当するケースが増えるだろう

11. 契約面への影響

• 生産性の向上により慢性的な人材不足が改善する。副業エンジニアの仕事はなくなるかもしれない
• 手を動かすだけのスキルしか持たない要員(ジュニアレベル）は現場に入れなくなる、もしくは大きく単価減となる。新人を現場に入れてOJTで育てることができなくなり、どう育てるかが課題となる。AIを教師役としたシミュレーションベースのトレーニングや、基礎的なプロンプトエンジニアリング教育が新人研修の核となる可能性がある
• 既存のITスキルに加え、AIツールを使えることが前提となる。既存技術面で優秀でもAIツールを使えない要員は不要、あるいは低単価となる。逆にAIツールを使える要員の単価は上がり、今まで五人～十人のチームでやっていたような作業をAIツールを前提に一人～三人で担当するような事例が増える。その結果、単価の二極化が起きる
• スケジュールや工数へのAIの影響はまだ事例が少なく予想しづらい。生産性が上がった分を要件の増加と人手不足が食い尽くす可能性もあるので、単純に減らせるとは限らない
• AI開発のインパクトによって日本のIT業界独特の多重下請け構造＝外注メインの開発形態から内製へのシフトが起こるかは未知数。解雇規制の緩和などの法律改正の動きも鍵となるだろう
• SESという業態が残るとしても、単なる「労働力提供」から「AIを活用した高生産性開発ノウハウを持ったチームの提供」、「レガシーシステムへのAI適用コンサルティング」など、より付加価値の高いサービスへの転換が求められる可能性がある
• 生成されたコードの知財権の所在や、学習データに起因するライセンス汚染のリスク管理が、新たな契約上の論点として加わる

12. その他、共通的な考察

• 開発プロセスの各工程でAIを使うのが当たり前になると変わる部分は何かと考えるときの基本は、今まで人間の労力や認知能力という制約条件で決まっていた様々な上限が撤廃されるということ。「そんなこまかい、大量の作業までできない」と言っていたようなタスクが、AIだったら問題ないという観点で見直されるだろう

13.【まとめにかえて】システム開発はJazzセッションのようになっていく、または「石橋をたたいている間に手遅れになる」問題

• システム開発に限らず、日本のビジネスの現場では何をやるにもまず計画を作れと言われ、慎重に検討を重ねて一度計画を立てると今度は何があろうとなかなか見直そうとしない。スピードや即応性を犠牲にしてでも石橋を叩くようにして着実に進めようとする。別の言い方をすると失敗を一切許さない、不確定性を許容しない、リスクを取ろうとしない強固な慣習がある
• しかし、これからの時代のプロダクト開発におけるシステム開発（特に新しい価値を創出する攻めのシステム開発）の在り方はAIネイティブ化が進むとともに不確定性とスピードが高まり、事前に計画をつめたり隅々まで仕様や設計を固めてからでないと先に進まないなどという悠長なことをしていたら競争相手に負けてしまうという状況が生まれる
• AI時代における新しいビジネス価値の創出や開発という営みでは前例のない初めての試みや、やってみないとわからないということも多く、しかも開発の途中で使っている技術そのものが物凄いスピードで変化していく。これらについては臨機応変な対応をするしかなく、事前にどうなるか予定を見通して詳細な計画にするなど不可能に近い
• 音楽活動で例えるならJazzバンドの演奏のようなもので、それに対して 「うちのコンサートホールで演奏したかったら当日演奏するすべての楽曲の楽譜を事前提出しろ」と言っているようなものである。優れたJazzの演奏には即興演奏でしか生みだすことのできない体験や価値というものがある。あらかじめ楽譜を用意しなければ演奏させないというのはJazzをクラシック音楽のように演奏しろと言うことで、本質的に無理な要求ではないだろうか。事前に決められるのは、どんな曲目を演奏するか、どんなメンバーが参加するかくらいである（それすら状況次第で変わる）。それでもいいからやろう、と言えるかどうかが、大げさに言えば生死の分かれ目になるだろう⁴

• Jazzバンドに対してあらかじめバンドスコアを出せというようなことを言いがちなのが日本のビジネス慣行で、その背景にはリスクを取らずに成果だけは欲しいという考え方がある。当然ながらそういう土壌からは新しい価値はなかなか生まれない。そのような失敗をし続けた結果が失われた30年であるだろうし、日本からGAFAMが生まれない理由の一つとも言える
• 今後のシステム開発はそのような日本のビジネス慣行の壁をどう越えていけるかが課題になるのではないかと思われ、不確定要素の多い状況下でもリスクをコントロールしつつ果敢に決断できる人や組織が次の時代を制することになるのではないかと思われる

以上、いろいろ書きましたがどなたかの参考になれば幸いです。（なお、本記事はすべて人間が書いたものです）

1. プロジェクト管理の仕事の一部は実は人間がやるよりAIにやってもらう方が良くなる可能性があります。理由は以下の通りです。ただし最終的な責任は人間が取る必要があります。

   • 人間の脳は統計・確率的事象を扱うのが苦手だが、プロジェクト管理業務ではその能力が重要になる
   • AIは24時間働けるため、管理層が進捗のボトルネックになることがなくなる
   • AIの方が感情的に安定しており(というか感情がない)、プレッシャーによって重要な判断を誤るということもない
   ↩

2. ExcelをAIで簡単に読み書き管理する仕組みが開発されれば話は別だが、現状ではそうはならないものと想定 ↩

3. 日本人は不確定性を極端に嫌うため、日本だけガラパゴス的にアジャイル開発への移行を拒否する可能性もある ↩

4. もしかしたら、楽譜も生成AIに書き起こしてもらったらこの問題も一瞬で解決するのかもしれない ↩