生成AIでコードを書く時間が短くなれば、システム開発全体も同じ割合で速くなるのでしょうか。
実際の企業開発では、コードを書いた後にセキュリティを確認し、クラウド環境を用意し、監視を設定し、サービスの責任者を登録し、運用部門の承認を得ます。AIが初稿を速く作っても、この経路がチームごとに違えば、リリースまでの時間は短くなりません。
Spotify、Google、Microsoftが公開しているプラットフォームエンジニアリングの資料を読むと、共通する方向が見えます。開発者一人ひとりへ手順を覚えさせるのではなく、安全な開発経路を社内プラットフォームへ組み込み、開発者とAIエージェントの両方が再利用できる状態を作るという考え方です。
この変化は、SIerにとって脅威だけではありません。個別システムを一つずつ作る仕事から、顧客企業の開発を継続的に支える「社内開発基盤」を提供する仕事へ移れる可能性があります。
この記事では、Internal Developer Platform（IDP）を単なるポータル製品としてではなく、SIerが継続サービスとして設計するための成果物、契約単位、受入条件まで整理します。
最終更新：2026年10月4日
結論：コード生成の次に詰まる場所を、SIerの商材にする
AIコーディングが普及すると、コードを書く作業の一部は安く、速くなります。一方で、次の仕事は残ります。
- どの技術・設計パターンを標準にするか決める
- システム、API、データ、担当チームの関係を把握する
- CI/CD、クラウド、監視、セキュリティを安全につなぐ
- 権限、例外承認、監査証跡を管理する
- 開発者が実際に使っているかを測り、基盤を改善する
これらを毎回のプロジェクトで個別に実施するのではなく、再利用できるサービスとしてまとめたものが社内開発基盤です。
SIerが提供できる価値も、「何人で何か月開発するか」から、安全な開発経路を何種類提供し、どれだけの開発チームが自律的に利用できるかへ変わります。
Spotify：AIでコードを書く速度より、組織の文脈が重要になる
Spotify Engineeringは2026年6月の「Coding Is No Longer the Constraint」で、AIコーディングをチームへ広げるうえでBackstageが果たす役割を説明しています。
Spotifyでは、ソフトウェアカタログにコンポーネントの所有者、文書、状態などを集約し、Backstageの機能をMCPやCLIからAIエージェントにも利用させています。また、推奨技術と設計パターンを「golden state」として定義し、静的解析やlintを通じてエージェントへフィードバックしています。
ここで重要なのは、AIエージェントへ自由にコードを書かせてから人が全部直すのではないことです。エージェントが参照する文脈と、守るべき標準をプラットフォーム側へ置いています。
Spotifyは2025年の記事で、Backstageを社内ツールからオープンソースへ展開し、さらにSaaSやサポートを含む企業向け事業へ発展させた経緯も公開しています。社内で培った開発基盤を、外部企業が利用する製品とサービスへ変えた事例です。
Spotify自身が公表した利用社数や生産性の数値は、独立した比較試験ではありません。ただし、内部の開発標準をオープンソース、プラグイン、SaaS、コンサルティングへ展開する事業モデルは、SIerにとって参考になります。
Google：品質責任を開発者へ足すのではなく、基盤へ「shift down」する
Google Cloudは2025年8月のプラットフォームエンジニアリング解説で、「shift down」という考え方を紹介しています。
セキュリティ、信頼性、効率、性能といった品質責任を、開発者へチェック項目として追加するだけでは規模が大きくなるほど負担が増えます。そこで、共通する判断や制御を社内開発基盤へ埋め込み、個々の開発チームが毎回考えなくても安全な経路を選べるようにします。
ただし、Googleはすべてを一つの厳しい標準へ統一すべきだとは述べていません。事業の利益構造、リスク、必要な品質に合わせ、自由度と統制の強さを選ぶ必要があるとしています。
これはSIerの提案にも重要です。標準化率を高くすること自体を目的にすると、顧客固有の業務を阻害します。提案すべきなのは、次の三つを分けた設計です。
- 全システムが必ず守る最低限の統制
- 多くのチームが選べる推奨経路
- 理由と期限を記録して認める例外経路
「正しい開発方法を教える」だけでなく、正しい方法を選びやすく、例外を追跡できる仕組みまで作ることが社内開発基盤の役割です。
Microsoft：ポータル導入ではなく、六つの能力を育てる
MicrosoftのPlatform Engineering Capabilities Modelは、プラットフォームエンジニアリングを次の六つの能力で整理しています。
- 投資
- 利用・定着
- ガバナンス
- プロビジョニングと管理
- インターフェース
- 計測とフィードバック
この整理から分かるのは、開発者ポータルを入れただけでは社内開発基盤にならないことです。予算と責任者がなく、利用状況を測らず、改善のロードマップもなければ、ポータルは新しいリンク集になって終わります。
Microsoftは大規模な一括導入ではなく、利用者を顧客として扱い、価値のある経路から段階的に整えることを勧めています。既製品だけで全工程を置き換えるのではなく、共通部品を利用しつつ、顧客企業に固有の接続部分へ投資する考え方です。
SIerの成果物も、画面やインフラだけでは足りません。利用者調査、サービスロードマップ、利用指標、運用体制まで含めて初めて受け入れられる仕事になります。
AWSの事例が示す、構築後も続くパートナー市場
AWS Partner Networkは2025年8月、Portを使った開発者ポータル構築例を公開しています。サービスカタログ、セルフサービス、ワークフロー自動化に加え、Amazon Q Developer CLIからPortのMCPサーバーを利用する構成を紹介しています。
これはAWSと製品ベンダーによるパートナー記事であり、中立な製品比較ではありません。それでも、社内開発基盤がクラウド、SaaS、MCP、運用支援を組み合わせる市場になっていることは読み取れます。
Google CloudがESGと実施した2025年のプラットフォームエンジニアリング調査でも、回答企業の多くがオープンソースを利用し、その管理を外部ベンダーと共同で行っていると報告されています。こちらもベンダー主導の調査であり、市場全体の確定値としては扱えません。しかし、導入企業が製品購入だけでなく、統合・運用支援を必要としていることを示す材料にはなります。
SIerが狙えるのは、初期構築だけではありません。顧客固有の開発経路を更新し、プラグインと権限を保守し、利用状況を見ながら改善を続ける仕事です。
SIerが商品化できる五つのサービス
1. 開発経路の可視化
最初に売るのはポータルではなく、現状の開発経路を見えるようにするサービスです。
アプリケーションの企画から本番運用までに、どのチケット、会議、手作業、担当者、ツールを通るかを調べます。開発者が待っている時間、同じ情報を再入力する場所、特定の担当者に依存する場所を特定します。
成果物はツール選定書ではなく、現行経路、待ち時間、責任分界、優先して共通化する候補です。期間と対象範囲を固定した診断サービスにできます。
2. ソフトウェアカタログと責任者台帳
AIエージェントが安全に作業するためにも、どのサービスを誰が持ち、どのAPIやデータへ依存しているかが必要です。
既存のCMDB、GitHub、監視、クラウド資産から情報を集め、サービス名、所有チーム、リポジトリ、運用レベル、依存先を一つのモデルへまとめます。登録件数より、所有者不明のサービスを減らし、情報の更新方法を自動化できたかを受入条件にします。
3. Golden Pathの設計と実装
新しいWeb API、バッチ、データパイプラインなど、利用頻度の高い一種類から安全な作成経路を作ります。
テンプレートには、ソースコードだけでなく、CI/CD、Infrastructure as Code、監視、ログ、セキュリティ検査、運用文書を含めます。プロジェクト開始時にコピーする雛形ではなく、標準の更新を利用チームへ届け続けられる仕組みにします。
4. 基盤のマネージド運用
社内開発基盤は完成して終わりではありません。クラウドサービス、依存ライブラリ、組織構造、セキュリティ基準が変われば、カタログとテンプレートも更新が必要です。
月額の運用契約に含める対象は、稼働監視だけではありません。バージョン更新、脆弱性対応、プラグイン審査、テンプレート改善、利用者サポート、利用指標のレビューまで明示します。
5. AIエージェント向けの文脈と統制
開発者向けに整えたカタログ、文書、標準、操作APIは、AIエージェントにも利用できます。ただし、検索できることと、変更を許可することは別です。
読み取り、提案、テスト環境への反映、本番変更を分け、操作ごとに権限、承認、監査ログを設定します。AI部分を単独で売るのではなく、社内開発基盤の利用者が人からエージェントへ増えるものとして設計します。
人月から継続型へ変える契約単位
社内開発基盤の仕事を通常の一括請負に押し込むと、機能一覧を完成させることが目的になり、利用者の定着が後回しになります。契約を次の単位へ分けると、成果を確認しやすくなります。
| 契約段階 | 主な成果物 | 検収で見るもの |
|---|---|---|
| 現状診断 | 開発経路、待ち時間、責任分界、優先候補 | 対象チームと現行値を合意できたか |
| 小規模実装 | カタログ、1本のGolden Path、権限設計 | 対象チームが支援なしで利用できるか |
| 展開 | 複数経路、移行手順、教育、例外管理 | 利用率、完了時間、例外理由を測れるか |
| 継続運用 | 更新、脆弱性対応、改善バックログ | 月次で品質と利用状況を改善できるか |
金額を人月だけで決めるのではなく、対象にする開発経路、接続するシステム、求めるサービスレベル、運用責任の範囲を価格の基礎にします。
ただし、利用率やリードタイムをSIerだけの成果保証にするのも危険です。顧客側の組織変更、承認制度、利用チームの協力にも左右されます。SIerが責任を持つ成果物と、共同で改善する事業指標を分けて契約します。
Backstageを入れれば完成、ではない
Backstageは、ソフトウェアカタログ、TechDocs、Software Templatesなどを提供するオープンソースの開発者ポータル基盤です。CNCFではIncubatingプロジェクトとして公開されています。
2026年10月4日時点で、公式リポジトリはアーカイブされておらず、9月29日にv1.55.3が公開され、10月にもコード更新が続いています。CI、E2E、アクセシビリティ、CodeQLなどのワークフローと、脆弱性報告用のセキュリティポリシーも確認できます。活発な公開実装ですが、導入企業側の保守が不要になるわけではありません。
Backstageの脅威モデルは、プラグインを外部パッケージと同様に審査すること、設定とシークレットを保護すること、必要に応じて権限システムを構成することを運用者の責任として挙げています。Scaffolderはリポジトリ作成やクラウド操作へつながるため、社内リンク集より高い権限を持ちます。
採用方法には、少なくとも三つの選択肢があります。
| 選択肢 | 向いている状況 | 主な負担 |
|---|---|---|
| Backstageを自社向けに構築 | 独自連携や細かな拡張が必要 | バージョン更新、プラグイン、認証・権限を自ら保守 |
| マネージド製品を利用 | 短期間で標準機能を使いたい | ベンダー依存、料金、拡張範囲の制約 |
| 既存クラウドとCI/CDから始める | 解決したい経路がまだ少ない | ツールが分散し、後から統合設計が必要になる可能性 |
Microsoftのオープンソース実装であるAzure Developer CLIのように、ポータルを先に作らず、テンプレートとCLIで開発経路を標準化する選択肢もあります。画面の有無ではなく、利用者が安全にセルフサービスできるかで選びます。
導入前に決めたい七つの受入条件
社内開発基盤を「導入しました」で終わらせないため、次の条件を先に決めます。
- 対象にする開発者と開発経路が決まっている
- 利用前の所要時間、待ち時間、失敗率を測っている
- 作成されたサービスの所有者と依存先を追跡できる
- 標準経路と例外経路を区別し、例外の理由と期限を残せる
- テンプレートの変更を既存利用者へ届けられる
- 権限、シークレット、プラグイン、操作ログを監査できる
- 利用率と利用者のフィードバックから改善項目を決められる
最初から全社共通基盤を完成させる必要はありません。一つの開発経路で、従来の申請と手作業をどこまで減らせるかを確認します。その後、別の経路へ広げても共通化できる部分だけをプラットフォームへ残します。
社内開発基盤を作らない方がよい場合
プラットフォームエンジニアリングは、すべての企業に大規模なポータルを必要とさせる考え方ではありません。
開発チームが少なく、経路もほぼ一種類なら、既存のPaaS、CI/CDテンプレート、クラウドの権限設定を整えるだけで十分な場合があります。また、基盤の責任者と改善時間を確保できない状態でポータルを作ると、新しい保守対象を増やします。
次の状態なら、製品選定より先に業務を整理します。
- 何に時間がかかっているか測っていない
- 利用する開発者が設計に参加していない
- 標準を決める責任者がいない
- 例外を認める条件が決まっていない
- 構築後の更新予算がない
この段階でSIerが売るべきものは、大規模な基盤構築ではなく、対象を絞った診断と一つの開発経路の改善です。
SIerの次の競争は、顧客の開発能力をどこまで残せるか
従来のSIerビジネスでは、顧客から要件を受け取り、システムを作って引き渡すことが一つの区切りでした。社内開発基盤では、顧客の開発チームが自分で安全に作り、変更し、運用できる状態を作ることが成果になります。
これは、SIerが不要になるという話ではありません。クラウド、CI/CD、セキュリティ、監視、組織ルールを一つの経路へ統合し続ける仕事は残ります。ただし、価値の測り方は、投入人数から再利用された開発能力へ変わります。
AIコーディングでコード作成が速くなるほど、企業間の差は、生成したコードの量ではなく、安全に本番へ届ける経路に現れます。
SIerが次に売るべきなのは、ポータルの画面でも、AIエージェントの利用枠でもありません。顧客企業の標準・責任・証拠を組み込み、人とAIが繰り返し使える開発基盤です。
関連記事
- 生成AI時代のSIerはどうなる？ビッグテックに学ぶ人月ビジネスの次 — SIerの収益構造を、人月から継続サービスへ変える全体像を整理しています。
- AIコードレビューの設計方法 — AIが生成した変更を、安全にレビューへ流すための設計です。
- AIエージェントに本番運用を任せてよいか — 権限、承認、監査ログを運用まで広げます。
- 生成AIでレガシーシステム刷新は本当に速くなる？ — 社内開発基盤へ載せる前に、既存システムをどう理解して移行するかを解説しています。
- 旧クライアントが残るMCP移行で、先に変える構成と残す責任 — AIエージェントとの接続方式を段階的に移す判断材料です。
参考資料
- Spotify Engineering：Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify
- Spotify Engineering：Celebrating Five Years of Backstage
- Google Cloud Blog：How Google does it: Your guide to platform engineering
- Microsoft Learn：What is platform engineering?
- AWS Partner Network Blog：Building a developer portal with Port on AWS
- CNCF：Backstage project page
- Backstage：Threat Model
- GitHub：backstage/backstage
- GitHub：Azure/azure-dev
確認日：2026年10月4日。企業ブログに掲載された導入効果や採用数は各社の自己申告またはベンダー主導調査を含み、独立した比較試験ではありません。製品の最新仕様、料金、サポート範囲は導入時に公式情報を再確認してください。
WRITTEN BY
コメント