生成AIでエンジニアは消えるのか？――SIer・自社開発の役割は「作る」から「判断する」へ

Posted at 2026-08-26

生成AIやコーディングエージェントの進化を見ていると、「このままAIの性能が上がれば、エンジニアはいらなくなるのではないか」という話をよく目にします。

確かに、実装という作業だけを見れば、これまで必要だった人数が大きく減る可能性はあると思います。特に個人開発では、一人のエンジニアがAIを使い、設計、実装、テスト、レビュー、修正まで進められるようになりました。

ただし、これをそのまま大規模な自社開発やSIプロジェクトへ当てはめて、「エンジニアそのものが必要なくなる」と考えることには懐疑的です。

私が考えているのは、エンジニアの仕事がなくなるというより、価値の重心が「作ること」から「理解し、検証し、判断すること」へ移っていくという変化です。

AIが速くする工程と、速くしにくい工程

ソフトウェア開発を一つの作業として捉えると、AIによる生産性向上を見誤りやすくなります。実際のプロジェクトには、企画、要件定義、設計、実装、テスト、レビュー、E2Eテスト、リリース判断といった複数の工程があります。

工程	AIによる高速化	主な理由
企画	小さい	暗黙知、事業背景、関係者の意向への依存が大きい
要件定義	小〜中	整理や文書化は速くなるが、ヒアリングや妥当性判断が必要
設計	大きい	設計案の作成、比較、影響分析を高速化できる
実装	非常に大きい	コーディングエージェントとの相性が良い
テストコード作成	非常に大きい	自動生成しやすい
レビュー・検証	小〜中	AI支援できる一方、確認対象そのものも増える
E2Eテスト	小〜中	実際の業務や利用者視点の確認が必要
リリース判断	小さい	リスク判断と最終責任が残る

企画や要件定義では、AIによって資料作成や情報整理そのものはかなり速くできると思います。会議記録の整理、過去資料の検索、要件のたたき台作成、抜け漏れの指摘などはAIと非常に相性が良い領域です。

一方で、本質的な部分は必ずしも文書化されていません。

「なぜ今この機能が必要なのか」「顧客が本当は何に困っているのか」「経営として何を優先したいのか」「現場ではどこまで変更を受け入れられるのか」といった情報は、人間へのヒアリングや過去の経験、組織内の暗黙知に依存します。

もちろん、こうした情報を継続的にコンテキストとして蓄積し、AIへ渡せるようにすれば、AIが作る企画や要件の精度も上げられるでしょう。ただし、そのコンテキストを作るためにも、まず人間から背景や意図を引き出す必要があります。

そのため、要件定義書を作る速度が上がることと、「そもそも何を作るべきなのか」「この要件で本当に良いのか」を決める速度が同じ割合で上がることは別問題です。

「コードを書くこと」と「リリースすること」は違う

この考え方と興味深く整合するデータがあります。

2026年5月に公開されたNBERの「Writing Code vs. Shipping Code」では、10万人以上のGitHub開発者とAI利用データを分析しています。自律型コーディングエージェントでは、コミット数への累積効果が+180%だった一方、プロジェクト数では+50%、実際のリリースでは+30%まで効果が小さくなっています。研究では、この結果をAIによる大きな生産性向上が、人間側の工程によって減衰する「Weak-link hypothesis」と整合するものとしています。

もちろん、この研究は日本の大規模SI案件そのものを測定したものではありません。それでも、コードを書く能力の向上と、最終的にソフトウェアを届ける速度の向上には大きな差があることを示すデータとして興味深いと思います。

さらに、2026年のFSEで発表された「The Fast and Spurious: Developer Productivity with GenAI」では、生成AI利用による成果量や速度の向上と同時に、レビューや検証に伴う負荷についても分析されています。

Sonarの「State of Code Developer Survey 2026」でも、1,100人以上のプロフェッショナル開発者のうち38%が「AI生成コードは人間が書いたコードよりレビューに多くの労力がかかる」と回答しています。また96%がAI生成コードを完全には信頼していないと回答しています。

つまり、AIによって仕事そのものが消えているというより、仕事の重心が「生成」から「確認」へ移っている可能性があります。

100人日のプロジェクトで考えてみる

ここで、非常に単純化したシミュレーションをしてみます。

従来100人日かかっていたプロジェクトを次のように仮定します。

工程	従来工数
企画	10
要件定義	20
設計	15
実装	25
テストコード作成	10
レビュー・検証	10
E2Eテスト	7
リリース	3
合計	100

AIによって設計が2倍、実装が4倍、テストコード作成が3倍速くなるとします。一方、企画や要件定義は人間へのヒアリングや暗黙知、事業判断への依存が大きいため、ここでは保守的に大幅な短縮は見込みません。

さらにAIによって成果物が増えることで、レビュー・検証工数が10から12〜15へ増えるケースも想定します。

工程	従来	AI活用後の仮定
企画	10	10
要件定義	20	20
設計	15	7.5
実装	25	6.25
テストコード作成	10	3.3
レビュー・検証	10	12〜15
E2Eテスト	7	7
リリース	3	3
合計	100	約69〜72

実装が4倍、設計が2倍、テストコード作成が3倍になっているにもかかわらず、プロジェクト全体では100人日から約69〜72人日です。

この仮定では、全体の高速化は約1.4倍程度にとどまります。

もちろん、これは実測値ではなく、開発工程の構造を考えるための机上のシミュレーションです。ただ、AIモデルそのものが何倍高速化したかではなく、開発工程全体のどこがボトルネックになるのかを見る必要があることは分かります。

大規模開発ではHuman-in-the-loopが基本になる

ここで私が前提としているのが、Human-in-the-loopです。

SIerや大規模な自社開発組織には、すでに多くのエンジニアがいます。AIにすべてを任せて最後だけ確認するのではなく、既存のエンジニア自身がAIを使いながら、各工程の成果物を理解し、妥当性を確認して次へ進むという形が現実的だと考えています。

AIが要件を整理する。人間が確認する。AIが設計する。人間が確認する。AIが実装する。人間がコードを理解して確認する。

Human-in-the-loopは最後のレビューだけに存在するのではなく、開発工程そのものに組み込まれるという考え方です。

なぜなら、最終的には人間が成果物の妥当性を説明できなければならないからです。特に金融、行政、医療、社会インフラ、大企業の基幹システムなどでは、「AIがそう言ったから」という理由だけで設計やリリースを決めることは難しいでしょう。

AIは確認工数を消すより、確認品質を高める

Human-in-the-loopが残ることは、必ずしも悲観的な話ではありません。

AIは成果物を作るだけではなく、レビューにも使えます。要件定義や設計を高性能なモデルに確認させれば、人間だけでは気づかなかった矛盾、抜け漏れ、例外ケース、非機能要件、セキュリティ、既存設計との不整合などを発見できる可能性があります。

つまり、

人間による確認工数 ≒ 大きくは変わらない

確認できる範囲 ↑
見逃し ↓
後工程での手戻り ↓
品質 ↑

という効果が期待できます。

ここでは、「仕様通りに作られているか」と「そもそもその仕様で良いのか」を分けて考える必要があります。

単体テスト、結合テスト、静的解析、セキュリティチェック、回帰テスト、AIコードレビューなど、仕様通りかを確認するVerificationは今後かなり自動化できるでしょう。

一方、「この要件で本当に良いのか」「この設計上のトレードオフを許容してよいのか」「このリスクを受け入れてよいのか」といったそもそもの妥当性を確認するValidationには、人間の暗黙知、事業判断、責任が大きく関わります。

AIは確認をなくすというより、人間の確認能力そのものを強化する道具として捉えた方がよいと思っています。

中間成果物でHuman-in-the-loopを回す

Human-in-the-loopを効率よく回すために重要になるのが、中間成果物です。

人間へのヒアリングや既存資料をもとにAIが要件を整理する。それを人間が確認する。確認された要件をもとにAIが設計する。それを人間が確認する。そして確認済みの設計をもとにAIが実装する。

中間成果物には二つの役割があります。

一つは、人間が「ここまでは理解し、妥当だと判断した」と確認するためのチェックポイントになること。

もう一つは、次のAIへ渡すコンテキストを具体化することです。

後者によって次工程でAIに考えさせる範囲を狭められるため、中間成果物は品質だけでなく、AIの利用コストを考える上でも重要になってきます。

AIの利用コストまで含めて、モデルを使い分ける

AIによって人間の実装工数を減らせたとしても、AIを使えば使うほど無条件に開発費が下がるわけではありません。

コーディングエージェントは大量のコードやドキュメントを読み込み、推論し、ツールを実行し、テストし、失敗すれば再試行します。数十人、数百人、数千人という単位で利用が広がれば、トークンやクレジットそのものが新しい開発上の変動費になります。

実際、The Informationが報じたUberの事例では、Claude CodeなどのAIコーディングツール利用が急増し、2026年の年間AI予算を数か月で使い切ったとCTOが説明しています。

TechCrunchの2026年6月の報道では、Uberだけでなく、PricelineでCursorの契約更新額が従来の4〜5倍となり、一部グループにトークン上限が設けられた事例なども紹介されています。企業がAIエージェントの急激なトークン消費に対して、利用制限やコスト管理へ動き始めていることが分かります。

Microsoftでも、The VergeがClaude Codeの社内ライセンスの大部分を終了し、GitHub Copilot CLIへ標準化する動きを報じています。ただし、これは単純に「Claude Codeが高すぎたからやめた」という話ではなく、開発環境の標準化が中心で、コスト削減も背景にあるとみられる、という理解が適切です。

つまり、

人間の実装工数 ↓

一方で

AI利用量 ↑
トークン消費 ↑
AI利用コスト ↑

ということも十分に起こり得ます。

ここで重要になるのが、どの工程でも最高性能のモデルを使うのではなく、タスクに応じてモデルを使い分けることです。

この方向性はAnthropic自身も紹介しています。

Anthropicは2026年7月、「Claude Fable 5 and model orchestration patterns」の中で、モデル・オーケストレーションの一つとして「Advisor Strategy」を紹介しています。高性能モデルが戦略や計画を担当し、より小さく安価なモデルが実作業を担当するという考え方です。

また、Anthropic Economic Indexでも、上位モデルは複雑で価値の高いタスクに使い、より単純なタスクでは他のモデルを選択するという、コスト・性能・速度のトレードオフが示されています。

これは、私が考えている開発プロセスともかなり近い方向性です。

ただし、私が重視したいのは、AI同士だけで計画から実装までを完結させるのではなく、その間にHuman-in-the-loopを入れることです。

まだ要件が曖昧で、多数の背景情報や既存システムを横断しながら考えなければならない工程では、高性能・高推論モデルを使う。

そこで作られた要件や設計を人間が理解し、妥当性を確認して中間成果物として確定する。

何を作るべきか、どのように作るべきかが十分具体化された後は、AIに求める推論範囲を狭められるため、高速・低コストなモデルへ具体的な実装を任せる。

そして人間が実装結果を確認する。影響範囲が大きい変更や最終成果物については、必要に応じて再び高性能モデルを使い、横断的にレビューする。

つまり、

高性能AIで考える → 人間が確認する → 中間成果物を確定する → 低コストAIで具体化する → 人間が確認する → 必要な箇所だけ高性能AIで再レビューする

という構造です。

もちろん、すべての実装を小型モデルへ任せられるわけではありません。複雑な実装や大規模な変更では、実装工程そのものに高性能モデルが必要になることもあります。

重要なのはモデル名を固定することではなく、そのタスクにどれだけの推論能力が必要なのかを見極め、高性能モデルを必要な場所へ集中させることです。

これによって、単にトークン代を節約するだけではなく、AIへ自由に判断させる範囲も限定できます。

これからの開発プロセスでは、

人間の工数 × AI利用コスト × 品質

をまとめて最適化する必要があるのではないでしょうか。

SIerや大規模自社開発の役割はどう変わるのか

ここまで考えると、「SIerは生成AIによってなくなるのか」という問いへの私の答えは、「現在の形のまま残るわけではないが、役割を変えながら残る可能性が高い」です。

従来のSIerの価値の一つには、多数のエンジニアを集め、大規模なソフトウェアを実装できることがありました。この部分については、AIによって必要人数が減る可能性があります。

一方で、SIerや大規模な自社開発組織には、

顧客や利用者から背景や意図を引き出す
暗黙知や業務上の前提を理解する
AIが整理した要件を確認する
設計の妥当性を判断する
中間成果物を確認・確定する
タスクに応じて適切なAIモデルを選択する
AIが作ったコードを理解する
セキュリティや運用リスクを判断する
複数のシステムを統合する
AI利用コストも含めて開発プロセスを最適化する
顧客や社内へ説明する
最終的にリリースを判断する

といった役割が残ります。

そのためSIerの価値は、「多くの人を集めて大量にコードを書くこと」から、「人間が持つ業務知識や文脈とAIの生成能力を組み合わせ、複雑なシステムを品質と経済合理性の両面から成立させること」へ移っていくのではないでしょうか。

これから求められるのは「AIに反論できるエンジニア」

そして、この開発方法を成立させるために、人間側にも重要な能力が求められます。

Human-in-the-loopは、単に人間が「承認」ボタンを押す仕組みではありません。AIが出した成果物を理解し、正しいか判断できなければ意味がありません。

AIが「この設計が最適です」と答えたとします。そのときに「なるほど」で終わるのではなく、なぜその設計なのか、他の選択肢はないのか、どんなトレードオフがあるのか、既存システムとの整合性はどうか、障害時にはどうなるのか、ビジネス要件と一致しているのかを判断できる必要があります。

つまり、これから求められるのは、

AIが出した答えを理解し、正しいか判断し、必要なら技術的に反論できるエンジニア

だと思います。

AI時代に価値が高くなるのは、単純にAIを操作できることだけではありません。

AIの回答に対して技術的に「No」と言える能力です。

まとめ

2025年に話題になったMETRの開発者生産性実験では、経験豊富なOSS開発者が当時のAIを使用した場合、対象タスクの完了時間が19%長くなるという結果が出ました。

その後2026年2月の続報では、旧参加者では18%高速化、新規参加者では4%高速化という方向の生データも得られています。ただし信頼区間はゼロを含み、さらにAIなしで作業することを嫌って実験へ参加しない開発者が増えるなど、選択バイアスが大きくなっています。METR自身も、現在のAIによる生産性向上率を正確に推定することは難しいとしています。

つまり、現時点では「AIを使えば必ず遅くなる」とも、「AIによって開発全体が数倍速くなる」とも単純には言えません。

ただし、NBERの研究を見ると、AIによるコード生成活動の大幅な向上が、そのままリリース数の増加にはつながっていません。Sonarの調査でも、Verificationが新しいボトルネックになる可能性が見えてきます。

さらに、UberやPricelineなどの事例を見ると、AIを大規模に利用する企業では、トークンやクレジットの費用そのものも新しい問題になり始めています。

だから私は、大規模なソフトウェア開発ではHuman-in-the-loopを前提にし、中間成果物を人間が一つひとつ確認しながらAIを使う方法が現実的だと考えています。

高度な推論が必要なところでは高性能モデルを使う。人間が確認した中間成果物によって問題が具体化したところでは、高速・低コストなモデルを使う。そして影響の大きい成果物については、必要に応じて高性能モデルでもう一度レビューする。

Anthropic自身もモデル・オーケストレーションのパターンとして、上位モデルに戦略や計画を担わせ、より安価なモデルへ実作業を委任する方向性を紹介しています。私がそこに加えたいのが、各工程で人間が内容を理解し、妥当性を確認するHuman-in-the-loopです。

そうすることで、

AIの性能
× 人間の理解
× 品質
× AI利用コスト

を同時に最適化する。

生成AIによって、実装を担当する人数は減るかもしれません。しかし、人間が不要になるというより、エンジニアに求められる能力が変わっていく。

これからSIerや自社開発組織に問われるのは、単純に「何人のエンジニアを抱えているのか」ではなく、人間が持つ暗黙知や業務文脈をAIへ接続し、適切なモデルを適切な工程へ配置し、AIが作った成果物を正しく理解・確認しながら次の工程へつなげられるのかだと思います。

生成AIはエンジニアを単純に消す技術というより、エンジニアに「本当に技術や業務を理解しているのか」「AIの回答にNoと言えるのか」を突きつける技術なのではないか。

私は今のところ、そう考えています。

参考資料・出典

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up