きっかけ

2026年3月、AWS は Copilot CLI のサポート終了を発表しました。2026年6月12日をもって、新機能の追加もセキュリティアップデートも止まります。

Announcing the end-of-support for the AWS Copilot CLI | Containers

私が Copilot に見出していた価値は、単純に「便利なツール」ということではありませんでした。それが終わるという知らせを受けて、改めてその価値の正体を言語化してみたくなりました。

宣言的記述と手続き的記述

まず前提となる概念を整理しておきます。

プログラムの記述スタイルは大きく二つに分類できます。宣言的（Declarative）と手続き的（Procedural）です。

同じ「偶数だけ取り出して2倍にする」処理を TypeScript で書き比べてみます。

手続き的

const result = [];
for (let i = 0; i < numbers.length; i++) {
  if (numbers[i] % 2 === 0) {
    result.push(numbers[i] * 2);
  }
}

宣言的

const result = numbers
  .filter(n => n % 2 === 0)
  .map(n => n * 2);

手続き的な記述は「インデックスを進めて、条件を確認して、配列に追加して」という手順を書きます。宣言的な記述は「偶数を選んで、2倍にする」という意図を書きます。

ただし、これは二値ではなくグラデーションだという点に注意が必要です。filter().map() にも順序はあります。「完全に宣言的」というのはほぼ理想概念であり、現実のコードはどこかにグラデーションとして位置しています。本質的な違いは「順序があるかどうか」ではなく、「制御フローを自分で記述しているかどうか」にあると考えています。

また、宣言的記述は関数型言語の専売特許ではありません。SQL は宣言的の典型例ですが、関数型言語ではありません。TypeScript でも Python でも、書き手の選択次第で宣言的にも手続き的にも記述することができます。

CloudFormation・Copilot・CDK を並べてみる

この宣言的／手続き的という軸と、もう一つの軸である抽象度を組み合わせると、AWS の IaC ツール群の立ち位置が見えてきます。

ツール	記述スタイル	抽象度	メンタルモデルとの距離	ベストプラクティスの規定
AWS CloudFormation	宣言的	低	遠い（AWSリソース視点）	なし（自分で判断）
AWS Copilot CLI	宣言的	高	近い（サービス視点）	強い（AWS が規定）
AWS CDK	宣言的〜手続き的	自由	設計次第	弱い（開発者の規律次第）

AWS CloudFormation

CloudFormation は宣言的です。「あるべき状態」を YAML または JSON で記述し、AWS がその状態に収束させます。冪等性があり、差分管理もできます。

一方で抽象度は低いです。「ロードバランサー付きの Web サービスを動かしたい」という意図を表現するのに、VPC・サブネット・セキュリティグループ・ECS クラスター・タスク定義・ALB・ターゲットグループ・AutoScaling……と、数百行の記述が必要になります。

つまり CloudFormation では、「自分が何をしたいか」を記述するのではなく「AWS が何を必要とするか」を記述しているのです。宣言的ではありますが、人間のメンタルモデルからは遠いと言えます。

AWS Copilot CLI

Copilot のマニフェストはこうです。

name: my-web-service
type: Load Balanced Web Service

image:
  build: Dockerfile
  port: 80

cpu: 256
memory: 512
count: 1

type: Load Balanced Web Service の一行が、VPC・ALB・ECS クラスター・Fargate・AutoScaling をまとめて意味します。これは人間が「ロードバランサー付きの Web サービス」と考えるときのメンタルモデルそのものです。

最終的には CloudFormation に変換されて実行されます。しかしその変換を意識させません。「変換される先が何か」よりも、「書いている人間が何を考えながら書けるか」の方が重要だと考えています。

AWS CDK

CDK は抽象度の自由度が高いです。L3 Constructs を使えば Copilot に近い高抽象度の記述も可能です。最大の利点は、インフラをプログラムとして扱うことで、複雑な要件を論理的に整理し、再利用可能なコンポーネントとして管理できる点にあります。

一方で、プログラミング言語の性質上、リソース間の「依存関係」を明示的に記述するスタイルが基本となります。「VPC を定義し、それを Cluster に参照させ、Service を紐付ける」といった、リソース同士の配線を人間がコントロールする必要があります。これは「記述の簡潔さ」よりも、「システム全体の構造を詳細に把握・制御すること」に重きを置いた設計思想と言えます。

そして CDK もまた最終的には CloudFormation に変換されます。

三者に共通する事実と、それでも違うこと

CloudFormation・Copilot・CDK、いずれも最終的には CloudFormation のテンプレートとして実行されます。その意味では「同じものを作っている」とも言えます。

しかし、書いている人間が何を考えながら書くかはまったく異なります。

CloudFormation: AWS の「リソースの定義」そのものを記述する（確実な基盤）
AWS CDK: インフラの「構造と関係性」をプログラマブルに構築する（柔軟な設計）
AWS Copilot: 特定のパターンに基づき「サービスの意図」を表明する（高速なデリバリー）

変換される先が同じでも、書き手の思考コストは同じではありません。

Copilot が肩代わりしていたもの

ここが核心だと考えています。

Copilot が「考えなくて済む」ようにしてくれていたのは、記述量や抽象度の話だけではありませんでした。「何がベストプラクティスか」という判断そのものを肩代わりしてくれていたのです。

type: Load Balanced Web Service と書いた瞬間に、VPC の構成・セキュリティグループの切り方・ヘルスチェックの設定・AutoScaling の組み方という AWS の知見が暗黙的に注入されていました。ドキュメントを読んで自分で判断する必要がなかったのです。

CDK に移ると、この「判断の肩代わり」が消えます。L3 Constructs はある程度それを引き継ごうとしていますが、Copilot ほど強い意見は持っていません。そして強い意見を持たないということは、悪いプラクティスを選ぶ自由も同時に与えられるということです。

宣言的記述の本質的な価値は、単に「コードを短くすること」ではない。本来はプラットフォームが担うべき「最適解への到達手順」をツールに委ねることで、人間が「構成の細部」ではなく「本来の目的」に集中できる環境を作ることにある。

Copilot はまさにその判断を AWS 側に留保することで、開発者を本来集中すべき問題に向かわせようとしていました。

この性質は、職能別チームからプロダクトチームへと移行した私たちの組織にとって、親和性の高いものでした。各メンバーがより幅広いスキルセットを求められる体制において、AWS に精通していないメンバーであっても Copilot が実装指針をベストプラクティスとともに示してくれる点は、実際の運用上の助けになっていたと認識しています。

ただし、この高い抽象度には「表現力の制約」という側面もありました。Copilot がカバーしていないリソースが必要になった際、結局は CloudFormation での直接記述が求められるなど、利便性と柔軟性の境界線が課題となる場面もありました。

おわりに

Copilot のサポート終了を受けて、後継として ECS Express Mode や CDK L3 Constructs への移行が案内されています。

移行にあたって整理しておきたいのは、Copilot が担っていた「ベストプラクティスの規定者」としての役割のうち、何が引き継がれていて、何は私たち自身の解像度を上げて対応しなければならないのか、という点です。

その視点を持ちながら、これからのインフラ記述のあり方を考えていきたいと思います。

QUARTETCOM TECH BLOG カルテットコミュニケーションズ開発部ブログ

宣言的記述とメンタルモデル ── AWS Copilot CLI のサポート終了に寄せて