Internal Developer Platform（IDP）設計入門｜Platform Engineeringチームがクラウドで構築するセルフサービス開発基盤の実践ガイド

チームが50人を超えたころ、開発者からこんな声が上がり始める。「新しいマイクロサービスを立ち上げたいんですが、インフラはどこに頼めばいいですか？」「Terraformのリポジトリがいくつかあるんですけど、どれを使えばいいか誰も知らなくて…」

そのたびにインフラチームが対応し、同じような設定を何度も書き直し、レビューを待つ間に開発が止まる。セキュリティ設定の一貫性も怪しくなってくる。これがスケールした組織が必ず直面する「プラットフォームの壁」だ。

Internal Developer Platform（IDP）は、この問題に正面から向き合うための解法だ。開発者がインフラの専門知識なしに、ゴールデンパスを通じて安全・迅速にサービスを立ち上げられる仕組みを、Platform Engineeringチームが構築・運営する。

この記事では、IDPの設計思想から、AWS上での具体的な実装パターン、ガバナンス・コスト設計の組み込み方まで、現場で使えるレベルで解説する。

なぜIDPが必要なのか？DevOpsが抱える「認知負荷」の問題

DevOpsの普及によって、各開発チームがインフラを自律的に操作できる時代になった。しかし「自律」と「野放し」は違う。チームの数が増えると次のような問題が起きる。

・各チームが独自のTerraformモジュールを書き、微妙に異なる設定が乱立する
・新チームがオンボーディングするたびに、インフラチームへの問い合わせが大量発生する
・セキュリティポリシーのアップデートを全チームのリポジトリに反映するのが困難になる
・開発者がCI/CDの設定、ログ収集の設定、IAMポリシーの設定まで自分で覚えなければならない

この「開発者が本来やりたくないことに時間を取られる」状態を、Platform Engineeringの文脈では認知負荷（Cognitive Load）の問題と呼ぶ。

IDPは、開発者がアプリケーションの開発に集中できるよう、インフラの複雑さを適切に抽象化する。難しいのは「隠しすぎると柔軟性が失われる」「薄すぎると結局また全部覚えなければならない」というバランス設計だ。

「開発者ポータル」と「IDP」の違いも押さえておこう。Backstageのような開発者ポータルはIDPの入口（UI層）にすぎない。IDPは「ポータル＋テンプレートエンジン＋パイプライン＋観測基盤＋ポリシーエンジン」を統合した、より広い概念だ。

DevOps・SRE・Platform Engineeringの役割の違いについては、DevOps・SRE・Platform Engineeringの違いとは？クラウドエンジニアが知るべき3つの運用モデル完全比較で整理しているので、前提知識として参照してほしい。

IDPを構成する5つのコンポーネント

IDPの全体像を把握するには、5つのレイヤーに分けて考えると整理しやすい。

すべてを最初から作り込む必要はない。まず②テンプレートエンジンと③CI/CDから始めて、①ポータルは後からかぶせるアプローチが現実的だ。

AWS上でのIDP実装：3つのアプローチ

AWSで実際にIDPを構築するとき、チームの規模・成熟度・既存ツールセットによって適切なアプローチが異なる。代表的な3パターンを見ていこう。

1. AWS Service Catalog × Terraform でインフラをプロダクト化する

最もAWSネイティブなアプローチが、AWS Service Catalogを中心とした構成だ。

Platform Engineeringチームが承認済みのCloudFormationテンプレートやTerraformモジュールを「製品（Product）」として登録し、開発者はポートフォリオからセルフサービスでプロビジョニングできる。

設計のポイントは次の通りだ。

・製品の粒度: 「VPC」「ECSクラスター」「RDS+Secrets Manager」などを個別製品として分割し、開発者が組み合わせる設計にする。モノリシックな「アプリ全部入り」製品は更新時の影響範囲が大きくなる
・バージョン管理: テンプレートをGitで管理し、マイナーバージョンは自動更新、メジャーバージョンは開発者に選択権を与える
・タグの強制: プロビジョニング時にコスト配分タグ（Environment・Team・CostCenter）を必須パラメータにすることで、後付けのタグ付け運用から脱却できる

# Service Catalogの製品バージョン登録（AWS CLI）
# 既存のCloudFormationテンプレートをS3に置いてから実行

aws servicecatalog create-provisioning-artifact \
  --product-id prod-xxxxxxxxxx \
  --parameters '{
    "Name": "v1.2.0",
    "Description": "ECSクラスター標準テンプレート: Fargate + ALB + CloudWatch Logs",
    "Info": {"LoadTemplateFromURL": "https://s3.amazonaws.com/my-catalog/ecs-standard-v1.2.0.yaml"},
    "Type": "CLOUD_FORMATION_TEMPLATE"
  }'

Terraformを使う場合は、AWS Service CatalogがTerraform Cloudとの統合をサポートしているため（External Providerタイプ）、既存のTerraformモジュールをそのまま製品化できる。Terraform実践設計入門で解説しているtfstateの分割設計と組み合わせると、各チームのtfstateが適切に分離された状態で運用できる。

2. Backstage on AWSで統合開発者ポータルを構築する

Spotifyが開発してCNCFに寄贈したオープンソースのBackstageは、2026年時点で中大規模組織のIDPポータルとして事実上の標準に近い位置づけになっている。

AWSでの展開先としては、ECSかEKSが主な選択肢になる。チームのKubernetes習熟度が低い段階ではECS Fargateが低コストで始められる。

Backstageの中核機能を整理しよう。

・Software Catalog: 組織内の全サービス・ライブラリ・データセットをYAMLファイルで登録し、一覧・依存関係・オーナーを管理する
・Software Templates（Scaffolder）: 新規サービス立ち上げ時に、GitHubリポジトリ作成・CIパイプライン生成・AWS Service Catalogプロビジョニングまでをウィザード形式で自動化する
・TechDocs: リポジトリ内のMarkdownドキュメントをポータル上に自動公開する
・プラグインエコシステム: AWS Cost Explorer、PagerDuty、DatadogなどのプラグインをOSSで追加できる

AWS IAM Identity Center との連携は必須設計項目だ。AWS IAM Identity CenterをIDPとして設定することで、SSOでBackstageにサインインしながら、バックエンドではIAMロールでAWSリソースにアクセスする構成が実現できる。

# Backstage Software Template の例（catalog-info.yaml の一部）
# 新規Reactアプリ立ち上げテンプレート

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: react-app-template
  title: "React Webアプリ（ECS Fargate）"
  description: "ECRリポジトリ・ECSサービス・ALBを一括プロビジョニング"
spec:
  owner: platform-team
  type: service
  parameters:
    - title: サービス情報
      properties:
        serviceName:
          type: string
          description: "英小文字とハイフンのみ（例: user-service）"
        teamName:
          type: string
          description: "コスト配分タグに使用"
  steps:
    - id: create-repo
      name: GitHubリポジトリ作成
      action: publish:github
    - id: provision-infra
      name: AWSインフラプロビジョニング
      action: aws:servicecatalog:launch
      input:
        productId: prod-xxxxxxxxxx
        parameters:
          ServiceName: ${{ parameters.serviceName }}
          TeamName: ${{ parameters.teamName }}

3. GitOps（ArgoCD / Flux）で宣言的デプロイを連携させる

テンプレートエンジンでインフラをプロビジョニングした後、実際のアプリケーションデプロイはGitOps（ArgoCDやFlux）で管理するパターンが増えている。

IDPとGitOpsの組み合わせにおける設計判断は次の通りだ。

・アプリリポジトリとGitOpsリポジトリの分離: アプリのコードと、デプロイ設定（Kubernetesマニフェストや Helm Values）を別リポジトリに分ける。これにより「誰がどの環境に何をデプロイしたか」の履歴がGitに残る
・Backstage Scaffolderとの接続: 新規サービス作成テンプレートの一ステップとして、GitOpsリポジトリにプルリクエストを自動作成するアクションを追加する。開発者がウィザードを完了した時点でArgoCD上にアプリが登録される
・EKS vs ECS の判断: GitOpsはKubernetesとの相性が良いが、ECSでも CodePipeline + EventBridge の組み合わせで同等のGitOps的なフローを実現できる

ガバナンスとコスト設計の組み込み方

IDPのゴールデンパスは「速く安全に」でなければならない。セキュリティとコストのガードレールをテンプレートに組み込む設計が重要だ。

ガバナンスのガードレールは、AWS OrganizationsとAWS Control Towerで構成するのが基本だ。各チームには専用のAWSアカウントを払い出し（アカウント自動払い出しはControl TowerのAccount Factoryを使う）、SCPで禁止アクションを上位から統制する。

コストのガードレールは、テンプレート設計時に次の仕組みを組み込む。

・必須タグポリシー: AWS Organizationsのタグポリシーで、`Environment`・`Team`・`Service` タグなしのリソース作成を拒否するSCPを設定する
・予算アラートの自動設定: Service Catalogのプロビジョニング時に、Lambda関数をトリガーして当該チームのAWS Budgetsアラートを自動作成する
・開発環境の自動停止: 開発・ステージング環境は夜間にEC2・ECSサービスを自動停止するLambdaをセットで展開する

想定例: 10チームがIDPを通じてサービスを立ち上げるケースを考えると、タグの統一だけで月次コストレポートの精度が大きく変わる。タグなし・タグ不揃いの状態では「どのチームのコストか」が分からず、削減提案ができない。IDPで強制することで、FinOpsの前提となるコスト可視化が初めて機能する。

段階的導入の3フェーズ

IDPを一度に全部作ろうとすると、プラットフォームチーム自体が開発に追われてアウトプットが出なくなる。段階的に進めることが重要だ。

フェーズ1（1～3か月）: ゴールデンパスの確立

最もよく使われる「標準的なサービス構成」（例: ECS Fargate + RDS + CloudWatch）を1つのService Catalog製品として作り、まず1チームに試験導入する。フィードバックを反映しながら品質を上げる。この段階では開発者ポータル（Backstage）は必須ではない。

フェーズ2（3～6か月）: セルフサービスの範囲を拡大

製品数を増やし（DBの種類、コンテナ基盤の選択肢など）、オンボーディングドキュメントを整備する。チームからの問い合わせ件数を計測し、IDPの効果を定量化し始める。

フェーズ3（6か月以降）: ポータル統合とFeedback Loop

Backstageを導入し、全製品・全サービスを一元ポータルで管理する。開発者の利用状況（どの製品が多く使われるか、どこで詰まるか）をメトリクスで観測し、継続的に改善する。

よくある落とし穴と対処法

落とし穴1: 「使われないポータル」問題

豪華なポータルを作っても、開発者が「SlackでインフラチームにDMした方が早い」と感じると使われなくなる。解決策は、IDPを通じた方が明らかに速い体験を設計することだ。セルフサービスで5分以内に環境が作れるなら、DM待ちの1日と比較できる。

落とし穴2: テンプレートが硬すぎて開発者が迂回する

承認済みテンプレートにない構成を使いたい開発者が、IDPを迂回してインフラを手動構築し始めると、IDPの意味がなくなる。エスケープハッチ（申請すればカスタム構成も使える）とフィードバックチャンネル（新しいニーズをIDPに反映する手順）を設けることが必要だ。

落とし穴3: プラットフォームチームがボトルネック化する

製品のアップデートやバグ修正がプラットフォームチームのみに集中すると、開発チームの待ち時間が生じる。製品テンプレートのコントリビューション手順を整備し、開発チームがプルリクエストを送れる仕組みにすることで分散化できる。

落とし穴4: SCPとIDPの設定が矛盾する

AWS OrganizationsのSCPでEC2のインスタンスタイプを制限しているのに、Service Catalogの製品テンプレートが制限されたタイプを指定している、というケースがよくある。IDPの設計段階でSCP・Control Tower・タグポリシーを横断的に確認し、競合しないよう整合を取る必要がある。

落とし穴5: Day 2 Operationsが設計に含まれない

新規プロビジョニングは動くのに、既存環境のスケールアップ・証明書更新・パッチ適用といった運用（Day 2 Operations）がIDPに含まれない設計は不完全だ。最初から「作る」「変える」「削除する」の3オペレーションをIDPでカバーする計画を立てておく。

本記事のまとめ

Internal Developer Platformは、一度作れば終わりのツールではなく、開発者からの継続的なフィードバックを受けて進化させていくプロダクトだ。

・IDPの目的: 開発者の認知負荷を下げ、安全なゴールデンパスを通じて自律的にサービスを立ち上げられる環境を提供する
・AWS上の3アプローチ: AWS Service Catalog（最もAWSネイティブ）、Backstage（OSSポータル）、GitOps連携（ArgoCDなど）を組み合わせる
・ガバナンスはテンプレートに組み込む: SCPとタグポリシーを設計段階から組み込み、後付けで統制しようとしない
・段階的に進める: フェーズ1でゴールデンパス1本を確立し、利用されることを確認してから拡張する
・使われなければ意味がない: 開発者の体験設計（UX）を最優先にして、常に「IDPを使った方が速い」状態を維持する

Platform Engineeringの実践は、インフラエンジニアが「インフラを設定する人」から「開発者の生産性を設計する人」へと変わる転換点でもある。クラウドの知識を組み合わせて「開発者向けプロダクト」を作る視点が、これからのインフラエンジニアには不可欠になっていくだろう。