生成AIでコードを書く時間が短くなったとき、SIerは何に対してお金をもらうのでしょうか。
「エンジニアが不要になる」「SIerはなくなる」という話ではありません。企業システムの難しさは、コードの量だけで決まらないからです。業務要件、既存システム、データ、部門間調整、セキュリティ、法規制、運用責任は残ります。
ただし、人を集め、時間をかけて作ること自体を価値にする商売は厳しくなります。
AWS、Google、Meta、Microsoft、Uberの技術ブログを読むと、各社がAIにコードを書かせるだけでなく、要件定義、レビュー、テスト、セキュリティ、権限管理、運用まで含めた開発の仕組みを作り直していることが分かります。
そこから見えるSIerの将来を、先に一文でまとめます。
SIerは「システムを作る会社」から、「顧客が安全に変わり続けられる仕組みを設計し、運営する会社」へ移る。
この記事では、ビッグテックが公開した一次情報をもとに、SIerの人月ビジネス、受託開発、内製化支援、運用サービスがどう変わるのかを考えます。
最終更新：2026年9月17日
SIer不要論では、本当の変化を捉えられない
生成AIが相対的に安くするのは、主に「すでに定義された作業」です。
- コードのたたき台を作る
- テストケースを生成する
- 設計書や手順書を下書きする
- 既存コードを調査する
- 定型的な改修候補を洗い出す
一方で、次の仕事は消えません。
- どの業務を変えるか決める
- 複数部門の利害を調整する
- 古いシステムと新しいサービスをつなぐ
- 品質、セキュリティ、監査の責任分界を決める
- 本番障害に対応し、継続的に改善する
つまり、開発需要がなくなるのではなく、価値の重心が実装量から、意思決定・統合・運営責任へ移ると考えるほうが自然です。
問題は、この変化と人月ビジネスの相性が悪いことです。人月では、売上はおおむね人数と期間に比例します。AIで10人月の仕事を5人月にできれば、顧客にとっては良いことですが、同じ単価体系のままではSIerの売上は減ります。
この矛盾を解かない限り、AIによる生産性向上は競争力ではなく、自社の売上を削る圧力になります。
ビッグテックは「AIツール」より開発の仕組みを変えている
各社の技術ブログには、SIerの将来を考えるうえで重要な5つの変化が表れています。
1. AWS：AIを足すのではなく、デリバリー全体を組み直す
AWS Professional Servicesは2026年、AIを既存工程へ追加するだけでなく、コンサルティングの進め方自体を再設計した事例を公開しました。
要件を人間向けの長い文書だけで管理せず、エージェントも読める構造化仕様へ変換。要件、アーキテクチャ検証、実装、セキュリティレビュー、テスト、デプロイを複数のエージェントでつなぎ、人は優先順位、品質判断、重要な承認へ集中しています。
AWSは、この方法によって一部の案件期間を月単位から日単位へ圧縮したと説明しています。これはAWS自身による事例紹介であり、すべての企業に再現できる独立検証済みのベンチマークではありません。それでも、クラウド事業者のプロフェッショナルサービス部門が、自らの提供モデルを作り直している点は重要です。
参考：AWS Professional ServicesがAIネイティブな提供体制へ移行した事例
SIerにとっての示唆は、コーディングAIの利用率だけを上げても不十分だということです。要件、成果物、レビュー、承認、契約までつながらなければ、速くなった作業の先で待ち時間が増えるだけです。
2. Google：AIの効果を決めるのは、モデルより組織の基盤
Google CloudのDORA 2025は、AI利用とソフトウェアデリバリーの関係を調査しています。
回答者の90％が仕事でAIを使い、80％超が生産性向上を感じていました。一方で、AI利用はデリバリーの安定性と負の関係も示しました。DORAは、コード変更が増えても、自動テスト、バージョン管理、素早いフィードバック、疎結合なアーキテクチャが弱ければ、下流の不安定さが増幅すると説明しています。
なお、これは調査上の相関であり、AIが直接障害を増やしたと断定するものではありません。それでも「AIを配れば生産性が上がる」という単純な図式を否定する材料にはなります。
参考：Google Cloud「2025 DORA Report」概要
ここから生まれる商機は、AIライセンスの販売ではありません。AIで変更量が増えても壊れない開発・運用基盤を提供することです。
3. Meta：レビューとリスク管理をプラットフォーム化する
Metaは、コード変更が本番障害を引き起こすリスクをAIで予測する「Diff Risk Score」を社内で運用しています。
変更内容とメタデータからリスクを推定し、テスト選択、レビュアー選定、リリース判断などへ活用します。Metaは2024年のある重要期間に、従来なら凍結していた1万件超の変更を、顧客影響を抑えながら取り込めたと報告しています。
プライバシーについても、製品ごとに担当者がチェックリストを回すだけではありません。データの流れを追跡する仕組みやポリシー適用を共通基盤へ組み込み、開発者が早い段階で問題を発見できるようにしています。
参考：MetaのPrivacy-Aware Infrastructure
SIerの品質管理も、レビュー要員を増やすモデルから、品質・セキュリティ・監査ルールをデリバリー基盤へ実装するモデルへ移っていくはずです。
4. MicrosoftとUber：AIエージェントは既存業務と権限に接続される
Microsoftは、Teams、Azure DevOps、GitHubなどを横断する社内開発エージェント「Athena」を紹介しています。単独のチャット画面を増やすのではなく、レビュー依頼、作業項目、セキュリティ審査、リリース準備を、開発者が日常的に使う場所へ統合しています。
Microsoftによれば、Athenaは週次で2,000人超のエンジニアに利用され、レビュアー推薦では94％の適合率を記録しています。これも同社による社内事例ですが、AIの価値が回答生成より、分断された仕事をつなぐことに移っている例です。
参考：Microsoft「Developer agents in action」
Uberはさらに、社内の数千のマイクロサービスをAIエージェントから利用できるようにする中で、「誰の依頼で、どのエージェントが、何を実行したか」を追跡するID・認可・監査の問題を取り上げています。
参考：Uber「Solving the Identity Crisis for AI Agents」
AIエージェントが読むだけでなく、メール送信、設定変更、申請、デプロイまで行うようになれば、権限と説明責任はシステム要件になります。この領域は、企業システムの統合と統制を得意としてきたSIerが価値を出しやすい領域です。
具体的な設計は、AIエージェントのセキュリティ設計チェックリストで整理しています。
5. 提供単位が「システム」から「業務ワークフロー」へ変わる
AWSのEnterprise Strategy Blogは、AIエージェント時代の提供単位が、アプリケーションやマイクロサービスから、事業上の意味を持つエンドツーエンドのワークフローへ移ると論じています。
参考：AWS「The New Unit of Software Delivery: The Workflow」
これまでの案件では、「販売管理システムを導入する」「基幹システムを更改する」がプロジェクトの単位でした。これからは、「受注から出荷までの時間を短縮する」「問い合わせから解決までを自動化する」といった業務成果が、設計・評価・改善の単位になります。
システムを納めても業務が変わらなければ価値が出ない。この当たり前の事実が、AIによって契約と体制の問題として表面化します。
SIerの価値は「作る力」から3方向へ移る
ビッグテックの事例をSIerの事業へ翻訳すると、価値は主に3方向へ移ります。
1. 業務を構造化する力
AIは、曖昧な業務を勝手に正しい仕様へ変えてくれません。例外処理、暗黙知、承認条件、責任分界が整理されていなければ、間違った業務を高速に実装します。
そのため、顧客の現場と一緒に業務を分解し、人にもAIにも理解できる仕様へ落とす力が重要になります。将来の上流工程は、大量の要件書を作る仕事ではなく、意思決定と業務知識を再利用可能な形で構造化する仕事です。
2. 変更を安全に流す基盤
AIによって実装量が増えるほど、テスト、レビュー、セキュリティ、監査、リリースが詰まりやすくなります。
そこで必要になるのが、標準開発環境、自動評価、ポリシーチェック、権限管理、監査ログ、ロールバックをまとめた共通基盤です。案件ごとに人を増やすのではなく、複数案件へ同じ統制を適用できれば、SIer側にも再利用の利益が残ります。
3. 本番運用を背負う力
AIシステムは、一度納品して終わりにしにくい性質を持ちます。モデル、プロンプト、参照データ、外部API、料金、リスクが変化するためです。
必要なのは障害対応だけではありません。品質の再評価、利用状況の分析、コスト管理、権限の見直し、業務KPIの改善まで含む継続運営です。
この領域では、従来の保守運用を「現状維持」から「価値を伸ばす運用」へ変えられるかが分岐点になります。
今後のSIerは4つのタイプに分かれる
業務変革パートナー
業界知識を持ち、対象業務、KPI、データ、組織変更まで一緒に設計します。システムの完成ではなく、リードタイム、売上、品質、顧客体験などの改善を目標にします。
必要なのは、ビジネスアーキテクト、プロダクトマネジメント、データ活用、現場定着の能力です。
共通プラットフォーム運営者
開発環境、データ基盤、AI評価、認証、監査、セキュリティを共通サービスとして提供します。
強みは、個別案件で得た知識を標準機能へ戻し、顧客が増えるほど品質と収益性を高められることです。一方、顧客固有の機能まで無理に共通化すると、使われない社内プロダクトになります。業界共通の規制、データ形式、審査、接続方式など、繰り返し現れる問題へ絞る必要があります。
高責任領域のインテグレーター
金融、公共、製造、医療などで、レガシー連携、法規制、安全性、24時間運用を引き受けます。
責任が重く、AIだけでは代替されにくい領域です。ただし、人による確認を増やすだけでは採算が悪化します。標準化と自動統制を進めながら、最終的な説明責任を持つことが価値になります。
汎用的な人月供給会社
決められた仕様に従い、実装要員を提供するモデルです。短期的には需要が残りますが、最も価格圧力を受けます。
顧客側もAIを利用でき、上位SIerも開発を自動化するため、「何人出せるか」だけでは差別化が難しくなります。多重下請けの下層ほど、生産性向上の利益を自社へ残しにくい点も課題です。
内製化が進んでも、外部パートナーはなくならない
IPAの「DX動向2025」では、日本でもDXに取り組む企業ほどシステム開発の内製化を進める傾向が示されています。一方で、必要な部分を内製化した企業や、外部開発を今後も利用する企業も存在します。
ここから予測できるのは、外部委託の消滅ではなく役割分担の変化です。
顧客が製品判断や業務知識を持ち、SIerが高度なアーキテクチャ、共通基盤、難所の実装、統制、運用を担う。SIerが顧客のIT部門を丸ごと代替する関係から、顧客の内製チームが自走できる能力を一緒に作る関係へ変わります。
顧客を囲い込み、仕様と運用をブラックボックス化するほど売上が安定するモデルは、内製化とAI活用の両方に逆行します。今後は「依存させること」ではなく、「自走させても高度な領域で選ばれ続けること」が信頼になります。
人月契約はすぐには消えない。ただし主役ではなくなる
成果報酬へ一気に変えれば解決するわけではありません。業務成果は市場環境や顧客側の意思決定にも左右され、SIerだけでは制御できないからです。
現実的には、次のような複合型へ移ります。
- 初期設計・移行は固定価格または準委任
- 共通基盤は利用料やサブスクリプション
- 運用・評価・監査は月額のマネージドサービス
- 改善活動は業務KPIと連動した追加報酬
- 不確実な探索は期間と予算上限を決めた伴走契約
重要なのは「人月を使ったか」ではなく、何に対して課金し、どの不確実性を誰が負担するかを明確にすることです。
固定価格にすれば、要件変更のリスクがSIerへ偏ります。成果報酬にすれば、SIerが制御できない要因まで背負う可能性があります。契約方式の名前を変えるより、対象業務、完了条件、変更ルール、評価方法、停止条件を具体化することが先です。
AI案件の受入条件と責任分担は、AIエージェントを本番で任せる前の10問で確認できます。
ビッグテックのやり方を、そのまま輸入してはいけない
ここまで紹介した事例には、注意点もあります。
第一に、ビッグテックは自社プロダクトを持っています。開発、運用、利用データ、事業成果を同じ組織でつなぎやすく、改善の利益も自社へ戻ります。受託契約で顧客ごとに環境が異なるSIerとは条件が違います。
第二に、巨大な共通基盤への投資を、多数のサービスと開発者で回収できます。数案件しか使わない社内プラットフォームを同じ規模で作っても、投資に見合いません。
第三に、企業ブログは成功事例を選んで公開する媒体です。クラウド事業者の記事には、自社サービスや方法論を有利に見せる動機もあります。公開された数字を業界平均として扱わず、「どんな仕組みを作ったか」と「自社でも再現できる条件は何か」を分けて読む必要があります。
SIerが模倣すべきなのは、特定のAI製品ではありません。
コードを書く前後を含めて、価値が届くまでの流れを一つのシステムとして扱う運営モデルです。
SIerが今から変えるべき6つのこと
1. AI利用率ではなく、価値が届くまでの時間を測る
コード生成量やAI利用者数だけでなく、要件決定から本番反映までのリードタイム、手戻り、障害、業務KPIを追います。
生成AIのROIを測る場合は、削減時間だけでなく、品質、利用状況、人による確認、運用費まで含める必要があります。生成AIのROI・KPIの作り方も参照してください。
2. 業務知識を、再利用できる構造化資産にする
要件、設計判断、用語、例外、規制、失敗事例を、担当者の頭や過去資料へ閉じ込めないようにします。人とAIの両方が参照でき、更新責任と版を追跡できる状態が必要です。
3. テスト、セキュリティ、監査を開発基盤へ埋め込む
最後の会議でチェックするのではなく、変更が作られた時点で自動評価します。高リスク操作だけを人が判断できるよう、リスクに応じて承認を配置します。
4. 業界固有の共通資産へ投資する
汎用チャットボットでは差別化しにくくなります。業界固有のデータモデル、標準API、審査ルール、評価データ、監査証跡など、顧客が単独で整備しにくい部分へ投資します。
5. 納品後の運用データを改善へ戻す
問い合わせ、障害、誤回答、利用されない機能、コスト超過を、次の設計へ反映します。保守部門を受け身のコストセンターにせず、プロダクト改善の入力を持つ組織へ変えます。
6. 顧客と一緒に受入条件を作る
AIの精度だけでGo／No-Goを決めず、業務価値、品質、安全性、データ、権限、運用、コストを確認します。実案件では、生成AI PoCの本番移行チェックリストを使うと、未決条件を洗い出せます。
結論：SIerは「変化を運営する会社」になる
生成AIによって、コードを書く能力は広く安く提供されるようになります。しかし、何を変えるべきかを決め、複雑な既存環境につなぎ、安全に運用し、成果が出るまで改善する仕事は残ります。
だから、SIerはなくなりません。
ただし、「何人を何か月投入したか」を価値の中心に置く会社と、「顧客の業務が変わり続けられる仕組み」を持つ会社では、今後の収益性に差がつきます。
これからSIerが売るものは、コードでも、AIツールでもありません。
業務を構造化する力、安全に変更を流す基盤、本番を継続的に運営する責任です。
人月ビジネスの次にあるのは、単純な成果報酬ではない。顧客と同じ業務成果を見ながら、変化そのものをサービスとして運営するビジネスです。
関連記事
- AIコーディング時代、SIerは何を売る？ — 人月開発の次に、社内開発基盤を継続サービスとして提供する設計を整理しています。
- 生成AIでレガシーシステム刷新は本当に速くなる？ — コード変換だけで終わらない、業務ルール・依存関係・現新比較を含む移行設計を整理しています。
- AIエージェントに本番運用を任せてよいか — Google SREとUberの事例から、運用保守を安全な自律運用サービスへ変える設計を整理しています。
- AIコードレビューの設計方法 — AIで変更量が増えた後のレビュー渋滞を、リスクベースの検証へ変える方法を整理しています。
- 生成AI導入の現在地から選ぶ実務ガイド — PoC、受入判断、SIerの事業設計から、次に読む記事を選べます。
- AIエージェントを本番で任せる前の10問 — 受入基準、責任分担、採算を案件単位で確認できます。
- AIエージェントのセキュリティ設計 — 権限、承認、監査ログ、停止方法を実務レベルで整理しています。
- 生成AI PoCの本番移行チェックリスト — Go／条件付きGo／No-Goを35項目で判定できます。
参考資料
以下は2026年9月17日に内容を確認しました。
- AWS Professional Services：Built from the inside out
- AWS Enterprise Strategy：The New Unit of Software Delivery: The Workflow
- Google Cloud：2025 DORA Report
- Meta Engineering：Diff Risk Score
- Meta Engineering：Privacy-Aware Infrastructure
- Microsoft Developer Blog：Developer agents in action
- Uber Engineering：Solving the Identity Crisis for AI Agents
- IPA：DX動向2025
WRITTEN BY
コメント