TT Lab

한국어 English 日本語

はじめる
ブログ

ブログ

プラットフォームエンジニアリング & IDP 2026 完全ガイド — Backstage・Port・Cortex・Humanitec・Crossplane・ArgoCD・Pulumi・Terraform・OpenTofu 徹底解説

2026-05-16 · 33 分で読めます · #platform-engineering#idp#backstage#port#cortex#opslevel#humanitec#crossplane#argocd#pulumi#terraform#opentofu#devex#gitops#devops

対話で聞く · 14分二人がこの記事を解説します

プロローグ — 2026年、「Platform Team」はもう冗談ではない

2018年まで「プラットフォームエンジニアリング」という言葉は曖昧だった。Kubernetes 運用者、SRE、DevOps、インフラチーム — 誰がどこまで責任を持つか、誰もわかっていなかった。

2026年には答えがほぼ固まった。

本稿は 2026 年のプラットフォームエンジニアリングスタックを最初から最後まで整理する。IDP・GitOps・IaC・CI/CD・Dev環境・サービスメッシュ・シークレット・ポリシーまで — そしてその間で「どのツールをどの段階で使うか」を決める意思決定マトリクスまで。

第1章 · Platform Engineering vs DevOps — 何が変わったのか

「プラットフォームエンジニアリングは結局 DevOps と同じでは?」への 2026 年の答えは明確だ。

この差が生んだ最大の変化は、認知負荷(cognitive load) の再分配だ。2010 年代の "You Build It, You Run It" は良いスローガンだったが、マイクロサービスが増えるにつれ、すべてのチームが Kubernetes・Terraform・Vault・OPA・ArgoCD を全部知らないといけない負担になった。2026 年のプラットフォームチームは、その認知負荷を吸収し、ストリームチームに対しては「ボタン 1 回」に見えるようにする。

覚えておく一行: 「Platform Engineering は Platform-as-a-Product だ。内部開発者が顧客であり、NPS・DevEx スコアが KPI である。」

第2章 · Team Topologies — 4 つのチームと 3 つの相互作用

Matthew Skelton と Manuel Pais が 2019 年に著した "Team Topologies" は、2026 年に事実上の標準語彙になった。4 つのチーム類型:

  1. Stream-aligned team — 価値ストリーム(value stream)に整合したチーム。製品・機能単位で責任を持つ。
  2. Platform team — 他のチームの認知負荷を下げる内部サービス提供者。IDP を作る。
  3. Enabling team — 一定期間、他のチームに合流して能力を育てるコンサルティング系チーム(例: SRE Enabling)。
  4. Complicated-subsystem team — 深い専門性が必要なサブシステム(決済ドメイン、ML 推論)を専門に担当するチーム。

そして 3 つの相互作用モード:

プラットフォームチームの日常は、X-as-a-Service の品質を上げることだ。セルフサービスが詰まれば一時的に Collaboration に戻り、能力差が見えれば Enabling に移る。

第3章 · Golden Path & Paved Road — 開発者体験の中心メタファー

Spotify が 2020 年に R&D ブログで整理した "Golden Path" は、2026 年のプラットフォームチームの標準的な約束になった。

Netflix・Stripe が使う近い表現が "Paved Road" だ。コンクリートで舗装された道 = 黄金の道。土の道でもいいが、雨が降れば泥にはまる。

プラットフォームチームの最初の成果物は、ほぼ常に「Golden Path 定義書」だ。どの言語・ランタイム・DB・CI・デプロイ方式が一級市民か? その定義が IDP のテンプレートになり、OPA ポリシーになり、Backstage Software Template になる。

第4章 · IDP 四象限 — Backstage・Port・Cortex・OpsLevel・Humanitec

2026 年の IDP 市場は大きく 4 象限に分かれる。

IDPモデルホスティング強み弱み
Backstage (Spotify, CNCF)OSS フレームワークセルフホスト無料、プラグイン、TechDocs、Software Templatesセルフホスト運用負担、初期セットアップ長い
PortSaaS、Blueprint モデルSaaS早期起動、セルフサービスアクション、GitOpsロックインリスク、価格
CortexSaaS、サービスカタログ中心SaaSサービススコアカード、オンコール統合UI 学習曲線
OpsLevelSaaS、サービス成熟度SaaS成熟度測定、多様な統合韓国・日本進出は弱い
HumanitecSaaS、Score ワークロード抽象SaaSDynamic Config Management、Score 標準カタログより workload 中心

選択基準はシンプル。

第5章 · Backstage — Spotify が CNCF に寄贈した OSS IDP

Spotify は 2016 年に Backstage を社内で作り、2020 年に OSS 化し、2022 年に CNCF へ寄贈した。2026 年 5 月時点で 1.40 系が安定版で、次の中核概念を提供する。

最小限の catalog-info.yaml の例。

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout-service
  description: Handles checkout flow for storefront
  annotations:
    github.com/project-slug: acme/checkout-service
    backstage.io/techdocs-ref: dir:.
    argocd/app-name: checkout-service-prod
  tags:
    - golang
    - payments
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: storefront
  providesApis:
    - checkout-api
  dependsOn:
    - resource:postgres-checkout
    - component:kafka-orders

Software Template の例(スキャフォールディング)。

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: golang-grpc-service
  title: Golang gRPC Microservice
spec:
  owner: team-platform
  type: service
  parameters:
    - title: Basics
      required: [name, owner]
      properties:
        name:
          type: string
        owner:
          type: string
          ui:field: OwnerPicker
  steps:
    - id: fetch
      name: Fetch skeleton
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: $|parameters.name|
          owner: $|parameters.owner|
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=acme&repo=$|parameters.name|
    - id: register
      name: Register in catalog
      action: catalog:register
      input:
        repoContentsUrl: $|steps.publish.output.repoContentsUrl|
        catalogInfoPath: /catalog-info.yaml

Backstage の真価は プラグインエコシステム にある。ArgoCD プラグインはカタログページでデプロイ状態を表示し、Cost Insights は AWS/GCP のコストをサービス単位で分解し、Kubernetes プラグインは Pod・Deployment 状態をリアルタイムで見せる。

第6章 · Port — Blueprint モデルとセルフサービスアクション

Port(getport.io)は 2022 年に登場し、2024~2026 年に急成長した SaaS IDP だ。Backstage が「フレームワーク」なら、Port は「完成品」に近い。

中核概念は Blueprint だ。エンティティのスキーマを JSON Schema で定義し、そのインスタンスを自動で埋める。「Service」Blueprint を定義すれば、GitHub・ArgoCD・Datadog・PagerDuty からデータを引き寄せて自動で埋める。

二つ目の強みは Self-Service Actions だ。「新マイクロサービスを作る」「DB バックアップを復元する」「ステージング環境を立てる」 — こうした作業がワンクリックで実行可能になる。バックエンドは GitHub Actions、Jenkins、ArgoCD Workflow など何でも繋げる。

Backstage と Port の比較はよく問われる。

第7章 · Cortex & OpsLevel — サービススコアカードと成熟度

Cortex(cortex.io)と OpsLevel(opslevel.com)は、サービスカタログを越えて サービスの成熟度 を点数化する強みがある。

スコアカードの価値はガバナンスにある。セキュリティチームが「すべてのサービスは SAST・SCA・SBOM・ランタイムセキュリティを通過しなければならない」というルールをカード化すれば、各サービスオーナーは自分の点数を自分の画面で見られる。強制はしないが可視化する。

韓国市場では Backstage・Port が強く、Cortex・OpsLevel は外資フィンテック・スタートアップで主に使われる。

第8章 · Humanitec & Score — ワークロード抽象の新標準

Humanitec(humanitec.com)は他の IDP と少し毛色が違う。カタログより ワークロード抽象と動的環境構成 に集中する。

中核は Score(score.dev)というワークロード仕様標準だ。開発者が書く score.yaml は環境中立 — Kubernetes・ECS・Nomad どこでも同じ仕様を使い、プラットフォームチームが定義したマニフェスト生成器が環境別に変換する。

Score 仕様の例。

apiVersion: score.dev/v1b1
metadata:
  name: orders-api
containers:
  orders:
    image: ghcr.io/acme/orders:1.2.3
    variables:
      DATABASE_URL: ${resources.db.connection}
      REDIS_URL: ${resources.cache.connection}
    resources:
      requests:
        memory: 256Mi
        cpu: 200m
service:
  ports:
    http:
      port: 80
      targetPort: 8080
resources:
  db:
    type: postgres
  cache:
    type: redis
  dns:
    type: dns

この 1 ファイルが Humanitec の Dynamic Config Management を通じて、環境別に異なる Kubernetes・Terraform マニフェストになる。開発環境では SQLite に落ち、本番では Aurora に解決される。

Score は CNCF Sandbox プロジェクトに入って標準化が進んでおり、Backstage・Port とも統合される。

第9章 · Crossplane — Kubernetes を IaC コントロールプレーンに

Crossplane(crossplane.io)は、2018 年に Upbound が始めて 2020 年に CNCF へ寄贈した、Kubernetes をクラウドリソースのコントロールプレーンに するプロジェクトだ。

中核アイデアは単純だ。AWS RDS、GCP Cloud SQL、Azure Database — こうしたクラウドリソースを Kubernetes CRD(Custom Resource Definition)として表現し、kubectl で管理する。Terraform の代わりに Kubernetes そのものが IaC ツールになる。

最も強力な機能は Composition だ。複数のリソースを束ねて XRD(Composite Resource Definition)として抽象化する。「MySQLCluster」XRD を定義すれば、内部的に RDS インスタンス + サブネットグループ + セキュリティグループ + IAM ロールを束ねて一気に作る。

XRD の例。

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresclusters.platform.acme.io
spec:
  group: platform.acme.io
  names:
    kind: XPostgresCluster
    plural: xpostgresclusters
  claimNames:
    kind: PostgresCluster
    plural: postgresclusters
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    storageGB:
                      type: integer
                    instanceClass:
                      type: string
                  required: [storageGB, instanceClass]

開発者はこう請求する。

apiVersion: platform.acme.io/v1alpha1
kind: PostgresCluster
metadata:
  name: orders-db
spec:
  parameters:
    storageGB: 100
    instanceClass: db.t4g.medium

Crossplane の弱点は学習曲線が急なことだ。XRD・Composition・Function・Pipeline まで — Terraform 一行で終わることを複数レイヤーにする。だが プラットフォームチームが Composition を一度しっかり定義すれば、開発者は 5 行の YAML で RDS・VPC・IAM を同時に請求できる。

第10章 · ArgoCD — GitOps 標準の代表格

ArgoCD(argo-cd.readthedocs.io)は 2018 年に Intuit が作り、2020 年に CNCF へ寄贈した。2026 年時点で v3.x が安定版で、事実上の GitOps 標準だ。

中核モデルはシンプル。

Application マニフェスト。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout-prod
  namespace: argocd
spec:
  project: storefront
  source:
    repoURL: https://github.com/acme/manifests
    targetRevision: HEAD
    path: apps/checkout/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: checkout-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 10s
        factor: 2
        maxDuration: 3m

数十〜数百のマイクロサービスを扱うときは ApplicationSet が便利だ。1 つのテンプレートで多数の Application を自動生成する。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: services-prod
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/acme/manifests
        revision: HEAD
        directories:
          - path: apps/*/overlays/prod
  template:
    metadata:
      name: '{{path.basename}}-prod'
    spec:
      project: storefront
      source:
        repoURL: https://github.com/acme/manifests
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}-prod'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

ArgoCD の同類ツールには Argo Rollouts(Blue/Green、Canary)、Argo Workflows(ワークフローエンジン)、Argo Events(イベントトリガ)がある。合わせて「Argo ファミリー」と呼ばれる。

第11章 · Flux — もう一つの GitOps 標準

Flux(fluxcd.io)は Weaveworks が 2016 年に作り CNCF へ寄贈した、ArgoCD 最大の競合だ。2026 年時点で v2.x が安定版。

ArgoCD と Flux の違い。

大規模マルチクラスター環境では Flux の方が軽く回る傾向があり、UI/UX と RBAC を重視すれば ArgoCD が有利。韓国・日本では ArgoCD が圧倒的に使われ、グローバルインフラ企業(Weaveworks 影響圏)では Flux も時折見られる。

第12章 · Pulumi · Terraform · OpenTofu — IaC のトロイカ

IaC 市場は 2026 年に 3 強に整理された。

IaC言語ライセンス強み弱み
Terraform (HashiCorp)HCLBSL 1.1(非オープン)最も成熟、モジュールエコシステムライセンス変更後 OSS 陣営離反
OpenTofu (Linux Foundation)HCL(Terraform 互換)MPL 2.0(オープン)本物の OSS、Terraform 移行容易後発、一部新機能は遅い
PulumiTS/Python/Go/C#/JavaApache 2.0本物のプログラミング言語、IDE 支援コード標準の差、抽象コスト

2023 年に HashiCorp が Terraform のライセンスを BSL に変えた後、OpenTofu が分岐した。2026 年には OpenTofu が v1.10 系に入り、Terraform との互換性はほぼ 100% に近い。新規プロジェクトは OpenTofu を使い、既存 Terraform ワークスペースをそのまま移す企業が増えた。

Pulumi の強みは本物のプログラミング言語でインフラを書けることだ。ループ・条件分岐・テストが自然。短所はチーム標準を作りにくいこと — HCL は「こう書くのが正解」があるが、TypeScript で書くと 100 種類の書き方が出てくる。

OpenTofu のサンプル — RDS + サブネットグループ + セキュリティグループ。

terraform {
  required_version = ">= 1.10"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.80"
    }
  }
  backend "s3" {
    bucket = "acme-tfstate"
    key    = "rds/prod.tfstate"
    region = "ap-northeast-2"
  }
}

resource "aws_db_subnet_group" "this" {
  name       = "orders-prod"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "db" {
  name   = "orders-prod-db"
  vpc_id = var.vpc_id
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = var.app_sg_ids
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "orders" {
  identifier             = "orders-prod"
  engine                 = "postgres"
  engine_version         = "16.4"
  instance_class         = "db.r6g.large"
  allocated_storage      = 100
  storage_encrypted      = true
  username               = "ordersadmin"
  manage_master_user_password = true
  db_subnet_group_name   = aws_db_subnet_group.this.name
  vpc_security_group_ids = [aws_security_group.db.id]
  multi_az               = true
  backup_retention_period = 14
  deletion_protection    = true
}

同じことを Pulumi TypeScript で書くとこうなる。

import * as aws from '@pulumi/aws'

const subnetGroup = new aws.rds.SubnetGroup('orders-prod', {
  subnetIds: privateSubnetIds,
})

const dbSg = new aws.ec2.SecurityGroup('orders-prod-db', {
  vpcId: vpcId,
  ingress: [
    {
      fromPort: 5432,
      toPort: 5432,
      protocol: 'tcp',
      securityGroups: appSgIds,
    },
  ],
  egress: [{ fromPort: 0, toPort: 0, protocol: '-1', cidrBlocks: ['0.0.0.0/0'] }],
})

const orders = new aws.rds.Instance('orders', {
  identifier: 'orders-prod',
  engine: 'postgres',
  engineVersion: '16.4',
  instanceClass: 'db.r6g.large',
  allocatedStorage: 100,
  storageEncrypted: true,
  username: 'ordersadmin',
  manageMasterUserPassword: true,
  dbSubnetGroupName: subnetGroup.name,
  vpcSecurityGroupIds: [dbSg.id],
  multiAz: true,
  backupRetentionPeriod: 14,
  deletionProtection: true,
})

第13章 · Atlantis · Spacelift · env0 · Terraform Cloud — IaC コラボ自動化

PR から IaC を自動 plan/apply する協調ツールも市場が明確になった。

2026 年のトレンドは、Atlantis(無料) + 自前 OPA + 自前ドリフト か Spacelift / env0(SaaS) の二分に。Terraform Cloud はライセンス問題以後シェアがやや落ちた。

第14章 · CI/CD — GitHub Actions · GitLab CI/CD · Buildkite · CircleCI · Harness

CI/CD 市場も 2026 年に整理された。

韓国・日本では Toss・Naver・カカオ・LINE などが自前ビルドシステムの上に GitHub Actions を組み合わせるパターンが多い。Coupang は自前 Buildkite 変形を使うとの報告がある。

第15章 · Earthly · Bazel · Nx · Turborepo — ビルドシステムとモノレポ

CI の上下にあるビルドツールも進化した。

2026 年は Bazel は巨大モノレポ(Google, Uber, Spotify)、Nx/Turborepo は JS/TS モノレポ、Earthly は Polyglot CI 統一 という棲み分けに整理された。

第16章 · Devbox · Devpod · Coder · Gitpod · Codespaces · Daytona — 開発環境

「私の MacBook でしかビルドされないコード」問題は 2026 年にほぼ解決された。開発環境そのものをコード化する。

企業で最もよく使われる組み合わせは Codespaces(小チーム)/ Coder(中〜大、セルフホスト)/ Devbox または Nix(ローカル決定論) の 3 つ。

第17章 · Nix · NixOS · Devenv — 決定論的環境の到達点

Nix は 2003 年からあったが、2026 年になってようやく本格的に大衆化し始めた。中核の約束は「同じ入力には同じ出力」 — ビルドと環境が完全に決定論的だ。

学習曲線は依然急だが、一度習得すれば「このプロジェクトは macOS・Linux どこでも同じくビルドされる」という保証がついてくる。Determinate Systems が導入した Nix Installer がこの参入障壁を大きく下げた。

第18章 · Container-Native — Docker Build Cloud · BuildKit · Podman · Nerdctl

コンテナツールも 2026 年に分化した。

企業ポリシー面では、Docker Desktop のライセンス変更 → Podman / Finch / Rancher Desktop への移行 が 2024〜2026 年に広範に起きた。

第19章 · サービスメッシュ — Istio · Linkerd · Cilium · Consul Connect

サービスメッシュ市場も整理された。

Meshデータプレーン強み弱み
IstioEnvoy機能豊富、標準(Ambient Mode 安定化)複雑性、運用負担
LinkerdLinkerd2-proxy (Rust)単純、高速、メモリ軽量機能幅狭い
Cilium Service MesheBPF + Envoyサイドカー無し、CNI と統合eBPF 依存、カーネル要件
Consul ConnectEnvoyマルチクラウド、VM も対応Kubernetes-native は弱い

2024 年に Istio Ambient Mode が GA となり、サイドカー無しのメッシュが本格化した。2026 年には Istio Ambient + Cilium の組み合わせが増えた。Linkerd は単純さが魅力で、中小クラスターでは依然人気。

第20章 · シークレット — Vault · Doppler · Infisical · External Secrets Operator

シークレット管理も 2026 年に整理された。

中核パターンは「Vault / AWS SM / GCP SM などの外部ストア + ESO + ワークロードは K8s Secret または環境変数で受け取る」だ。2026 年には SOPS + Age の組み合わせも GitOps フレンドリーとして人気。

第21章 · Policy-as-Code — OPA Gatekeeper · Kyverno · Conftest · Checkov · tfsec

ポリシーをコードで表現するツールも分野別に整理された。

2026 年の標準的な組み合わせは Kyverno(ランタイムポリシー) + Checkov または tfsec(IaC 静的解析) + Conftest(任意ファイル) だ。OPA Gatekeeper は標準だが、Rego の参入障壁により新規導入は Kyverno に流れる傾向。

第22章 · DORA · SPACE · DevEx — 開発者生産性測定の三大フレームワーク

Nicole Forsgren の "Accelerate"(2018)から出発した DORA Metrics は、2026 年に事実上標準だ。

プラットフォームチームの KPI は次第にこの 3 つの混合で定義されるようになった。Backstage Cost Insights は DORA メトリクスを自動収集するプラグインを提供し、GetDX(getdx.com)は SPACE/DevEx アンケートを自動化する SaaS だ。

覚えておく一行: 「DORA はシステムを見て、SPACE は人を見て、DevEx は日常を見る。」

第23章 · 韓国事例 — Toss · Coupang · Naver のプラットフォームチーム

韓国大手テックのプラットフォームチームは 2024〜2026 年に本格的に形を整えた。

共通点は 「韓国型プラットフォームチームの初年度目標はカタログ・オンコール・CI 標準化」 というパターンだ。Backstage または Port をカタログとして導入し、ArgoCD/Flux で GitOps を標準化し、OPA/Kyverno でポリシー標準化 — この 3 トラックが同時に走る。

第24章 · 日本事例 — Mercari · ZOZO · CyberAgent

日本もプラットフォームエンジニアリングに積極的だ。

Mercari の発表は英語資料も豊富で、韓国のプラットフォームチームがよく引用する。「We solved [X] with this pattern」発表シリーズは GitHub Issues よりも詳しい。

第25章 · 米国・欧州事例 — Spotify · Netflix · Airbnb · ING

これらの共通点は 「IDP は作るものではなく運用するもの」 という認識だ。最初の半年作るのは簡単だが、5 年目に 1000 コンポーネント入ったカタログを維持するのが本当の仕事だ。

第26章 · 意思決定ツリー — 自社は何を選ぶべきか

会社規模と段階によって推奨スタックは異なる。

スタートアップ(10〜50人、マイクロサービス 5〜20個)

中堅(50〜500人、マイクロサービス 20〜100個)

大規模(500人以上、マイクロサービス 100+個)

第27章 · 移行ガイド — 自社製 PaaS から IDP へ

多くの企業に既に「自社 PaaS」がある。Jenkins・GitOps スクリプト・Slack ボットのようなものが蓄積されたもの。これを IDP に移す道のり。

  1. まずカタログから — Backstage または Port を立て、すべてのサービスを登録する(catalog-info.yaml または Blueprint)。
  2. オンコール・ドキュメント統合 — TechDocs でドキュメントを一箇所に、PagerDuty プラグインでオンコールを一箇所に。
  3. GitOps 標準化 — Jenkins デプロイを ArgoCD/Flux に。最初の 1 ヶ月は併走、翌月は新規サービスだけ GitOps。
  4. Self-Service Actions — Port または Backstage Software Templates で「新規サービスを作る」をワンクリックに。
  5. DORA 測定開始 — その次から KPI を見る。測らないものは直せない。
  6. Score / Crossplane 導入 — 最後に。ワークロード抽象を早すぎて導入すると、抽象コストが価値より大きくなる。

第28章 · まとめ — プラットフォームエンジニアリングは 2026 年の SRE である

2010 年代の SRE のように、2020 年代後半のプラットフォームエンジニアリングは 「良い会社なら必ず持っているはず」 の分野になった。違いがあるとすれば、SRE が「運用の自動化」だったのに対し、プラットフォームエンジニアリングは 「開発者体験のプロダクト化」 であることだ。

覚えておく一行: 「IDP は作るものではなく運用するもので、運用の秘訣は測定・反復・顧客インタビューである。」

プラットフォームチームの最初の半年は、ツール選定ではなく 誰が自分たちの顧客か を定義することに使うべきだ。Stream-aligned team が顧客だ。彼らの NPS を四半期ごとに尋ね、DORA を測定し、Backstage・Port・ArgoCD・Terraform — どのツールであれ、その NPS を上げる方向に磨いていく。それが 2026 年のプラットフォームエンジニアリングの本当のコードだ。

References

ログインするといいねできます

コメント

まだコメントはありません。

ログインするとコメントできます