AWS Copilotとは？copilot initが作るECS構成とコマンド体系をv1.34.1で解説

AWS Copilot（AWS Copilot CLI）は、DockerfileひとつからAmazon ECS on FargateまたはAWS App Runnerへの本番デプロイ一式をコマンド化したAWS公式のCLIです。ただし2026年6月12日にサポート終了を迎えており、いま「aws copilot」を調べている人が最初に知るべきなのは使い方ではなく、このツールが何を自動化していて、その成果物が手元に何として残っているかです。最終リリースv1.34.1をIntel Mac上で実行しながら、ワークスペースの構造、サービスとジョブの種別、コマンド体系を確認していきます。

まとめ：AWS Copilotの要点

• AWS Copilotは、ECS on Fargate（Load Balanced Web Serviceなど）とApp Runner（Request-Driven Web Service）へのデプロイを、manifest.ymlという独自形式1枚に畳み込んだCLIです。
• AWSは2026年3月6日に終了を告知し、2026年6月12日にend-of-supportを迎えました。GitHubリポジトリは読み取り専用（archived）で、最終リリースは2025年4月10日のv1.34.1です。
• Amazon ECSデベロッパーガイドは「既存のデプロイは引き続き機能しますが、継続的なメンテナンスは行われません」と明記しています。いきなり止まるわけではありません。
• Copilotが生成するのは標準のCloudFormationスタックなので、CLIを捨てても自分たちのIaCとして引き継げます。ただしcopilot svc packageにもAWS認証が必要なため、テンプレートの書き出しはアカウントが生きているうちに済ませてください。
• 新規プロジェクトで採用する理由はありません。移行先の比較と選び方はAWS Copilot CLIサポート終了｜2026年6月12日EOLと移行先3択にまとめています。

名前が重なる「Copilot」とAWS Copilotの守備範囲

コード補完のCopilotとは別物

「copilot」という名前はベンダーをまたいで使われていますが、AWS Copilotは生成AIアシスタントではなく、AWSへのデプロイを管理するCLIです。GitHub CopilotはIDE上のコード補完とエージェント、Microsoft 365 Copilotは業務アプリのアシスタント、これに対してAWS Copilotはコンテナアプリのデプロイ専用CLIで、生成AIの機能は一切持ちません。AWSが提供するコーディング支援はAmazon Q Developerとは？終了日程・料金とKiro移行【2026年8月】で扱っているQ DeveloperやKiroの系統で、Copilotとは系譜が異なります。「aws copilot」で検索してAIアシスタントの解説が出てきたら、それはAWS Copilotの記事ではありません。

Copilotが面倒を見ていたAWSリソース

AWS Copilot CLIのリポジトリ説明は、対象を「AWS App Runner or Amazon ECS on AWS Fargate」と書いています。実際にcopilot initでLoad Balanced Web Serviceを選び、新規環境へのデプロイまで進めると、既定構成ではVPC・サブネット・セキュリティグループ・ECSクラスター・Application Load Balancerが作られます。AWS ECSとAWS Fargateを手で組むと数十のリソース定義になる部分を、CLIの対話1本に置き換えたのがCopilotの提供価値でした。

ここで注意すべきなのが、もう一方の実行基盤であるApp Runnerの状況です。AWSのApp Runnerデベロッパーガイドは「AWS App Runner は新規顧客に公開されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます」と記載しています。つまりCopilotの6種類のうちRequest-Driven Web Serviceは、CLIが動いたとしても新規アカウントでは基盤側が作れません。詳細はAWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説を参照してください。

copilot配下のワークスペースとCloudFormationスタックの対応

application・environment・serviceの3層

copilot --helpの説明文は、3つの概念をそれぞれ「Applications are a collection of services and environments.」「Environments are deployment stages shared between services.」「Services are long-running ECS or App Runner services.」と定義しています。アプリケーションという箱の中に、test・prodといった環境と、フロントエンド・バックエンドといったサービスが並ぶ構造です。

この概念はそのままCloudFormationに写像されます。AWSの移行解説ブログは「Copilot uses AWS CloudFormation to create stacks that correspond to the app (representing the ECS cluster with networking information) and for each service」と説明しており、アプリケーション用・環境用・サービス用のスタックが分かれます。ただし、このブログの括弧内の説明には注意が必要で、VPCやECSクラスターを管理するのは環境用スタックです。移行のときに「どこから手を付けるか」を決める単位が、このスタック分割になります。

ローカルに残るファイルの並び

Copilotが手元に置くファイルは、リポジトリのソースコード（internal/pkg/workspace/workspace.go）のコメントに構造がそのまま書かれています。プロジェクト直下のcopilotディレクトリがアプリケーションディレクトリで、.workspaceがアプリケーション名を保持するサマリーファイルです。

.
├── copilot                        (application directory)
│   ├── .workspace                 (workspace summary)
│   ├── my-service
│   │   └── manifest.yml           (service manifest)
│   │   environments
│   │   └── test
│   │       └── manifest.yml       (environment manifest for the environment test)
│   ├── buildspec.yml              (legacy buildspec for the pipeline's build stage)
│   ├── pipeline.yml               (legacy pipeline manifest)
│   ├── pipelines
│   │   ├── pipeline-app-beta
│   │   │   ├── buildspec.yml
│   │       └── manifest.yml
└── my-service-src                 (customer service code)

サービスのmanifest.ymlは短く、AWSブログが掲載しているLoad Balanced Web Serviceの生成例は次の内容です。CPUとメモリはFargateのタスクサイズ、countはタスク数に対応します。

name: loadbalanced-svc
type: Load Balanced Web Service
image:
  build: Dockerfile
  port: 80
cpu: 256
memory: 512
count: 1
http:
  path: '/'
variables:
  LOG_LEVEL: info

この十数行から、ALBへのルーティングやターゲットグループ、タスク定義などのCloudFormation設定が生成されます。count: 1はタスク数を1に固定する指定で、自動スケーリングにはcount配下の範囲やスケーリング指標の設定が別途必要です。裏を返せば、Copilotをやめるということは、この省略されていた数百行を自分たちで持つということです。

ワークロード種別は「サービス5種＋ジョブ1種」

公式ドキュメントのmanifest一覧もAWSの移行ブログも6種類を並列に挙げ、ブログは「Copilot supports six distinct service patterns」と書いています。しかしCLIの実装では区分が2つに割れています。copilot svc init --helpが受け付けるのは5種類で、Scheduled Jobだけはcopilot job init --job-type側の唯一の選択肢です。両方をまとめて受け取れるのはcopilot init --typeだけで、ここに6種類が列挙されます。種別名は引用符込みの文字列で指定します。

Worker Serviceだけは--subscribe-topicsでSNSトピックを指定する設計になっており、サービス間の非同期連携を前提にしています。Scheduled Jobの--scheduleはcron式のほか@dailyのような定義文字列とrate(10 minutes)形式のAWS Schedule Expressionも受け付けます。

コマンド体系と、移行で効く2つのサブコマンド

copilot --helpの出力は、コマンドを5つのグループに分けて提示します。

storage initが作れるのはDynamoDB・S3・Auroraの3種で、--lifecycleにworkloadかenvironmentのどちらかを渡して、サービスと同時に消えるのか環境と寿命を共にするのかを決めます。pipelineはAWS CodePipelineベースのデプロイパイプラインを生成します。

サービス操作のcopilot svcには12個のサブコマンドがあり、この中の2つが移行作業で直接効きます。

$ copilot svc --help
Available Commands
  init        Creates a new service in an application.
  ls          Lists all the services in an application.
  package     Print the AWS CloudFormation template of a service.
  override    Override the AWS CloudFormation template of a service.
  deploy      Deploys a service to an environment.
  delete      Deletes a service from an application.
  show        Shows info about a deployed service per environment.
  status      Shows status of a deployed service.
  logs        Displays logs of a deployed service.
  exec        Execute a command in a running container part of a service.
  pause       Pause running App Runner service.
  resume      Resumes a paused service.

svc packageは、デプロイに使われるCloudFormationテンプレートを標準出力に出すコマンドです。--output-dirでテンプレートとテンプレート設定をディレクトリに書き出せ、--diffを付けると生成結果とデプロイ済みスタックの差分を比較できます。もう一方のsvc overrideは、生成テンプレートを拡張するためのIaCファイルを足場として作るコマンドで、--toolにcdkかyamlpatchを指定します。cdkを選んだ場合の既定言語はTypeScriptです。Copilotの既定構成から外れた要求が出たときの逃げ道が、この時点ですでにAWS CDKだったことになります。

サポート終了後の配布状況と既存環境の管理

AWS Copilotの最終リリースと更新履歴

aws/copilot-cliリポジトリには「This repository was archived by the owner on Jun 22, 2026. It is now read-only.」と表示されており、終了日の10日後に読み取り専用化されました。最後のpushは2026年5月11日です。リリース履歴を見ると、最終版v1.34.1の公開は2025年4月10日、その1つ前のv1.34.0は2024年6月26日でした。しかもv1.34.1のリリースノートは全文が「Upgrades the tool to Go 1.23 to address CVE-2024-24790.」の1行で、機能追加はゼロです。終了告知が出た2026年3月の時点で、v1.34.0の公開から約1年8か月が経過していました。ただしリリース間隔だけでは開発の実態はわかりません。そこでv1.34.0の公開翌日から最後のコミットである2026年3月6日までを数えると、コミットは40件あります。内訳は依存ライブラリのバージョン更新、リリース用ワークフローの修正、READMEとドキュメントサイトの変更に限られ、CLIの機能を追加したコミットは1件もありません。保守はされていたが機能開発は終わっていた、というのが終了告知前の実態です。

一方でドキュメントサイトaws.github.io/copilot-cliは2026年9月時点でも日本語版を含めて公開されており、全ページ上部のバナーは「⚠️ Upcoming end-of-support」と未来形のままです。終了日を過ぎてもこの文言が残っているため、日付を読まずにバナーだけを見ると「これから終わる」と誤読します。

日付そのものにも食い違いが残っています。2020年公開のAWS公式紹介記事「Introducing AWS Copilot」に貼られたバナーは、終了日を「AWS Copilot CLI will reach end-of-support on May 22, 2026.」と表示したままです。専用の終了告知記事とECSデベロッパーガイドはいずれも6月12日で一致しているため、正しいのは6月12日です。古い記事のバナーが更新されずに残っているだけですが、検索で先に旧記事へ着地すると3週間ずれた日付を読むことになります。

いまインストールすると入るバージョン

配布経路はどちらも残っています。aws/homebrew-tapにはcopilot-cli.rbが今も存在し、対応するbottle-configsのversionは1.34.1です。GitHub Releasesのバイナリも取得でき、darwin-amd64版（約53MB）をIntel Macで実行すると次の応答が返りました。

# Homebrewの場合
$ brew install aws/tap/copilot-cli

# バイナリを直接取得する場合（macOS Intel）
$ curl -Lo copilot https://github.com/aws/copilot-cli/releases/download/v1.34.1/copilot-darwin-amd64
$ chmod +x copilot
$ ./copilot --version
copilot version: v1.34.1

つまり「インストールできない」状態ではありません。ただし入るのはGo 1.23でビルドされた2025年4月のバイナリで、これ以降のCVEに対する修正は来ません。踏み台となるCI環境に常駐させる用途は避けるべきです。

テンプレート書き出しに必要なAWS認証

svc packageはテンプレートを表示するだけなのでオフラインで動きそうに見えますが、実際は動きません。認証情報を外した状態でcopilot配下のワークスペースを用意して実行したところ、次のエラーで停止しました。

$ copilot svc package -a demo-app -n api -e test
✘ default session: RequestCanceled: request context canceled
caused by: context deadline exceeded

$ copilot svc init --name api2 --svc-type "Backend Service"
It looks like your AWS credentials are misconfigured or missing:
✘ RequestCanceled: request context canceled

アプリケーションのメタデータをAWS側から読むため、テンプレート生成であってもアカウントへのアクセスが前提になっています。ここから導ける実務上の判断は明確です。Copilotで作った環境をいずれ手放すつもりなら、アカウントとIAM権限が生きているうちにテンプレートを書き出し、リポジトリにコミットしておいてください。移行の検討を始めてからCLIを探すのでは、手順が1つ増えます。

書き出しはサービスだけでは足りません。copilot svc package -n frontend -e test --output-dir ./infrastructureを実行すると、v1.34.1のヘルプが示す出力はfrontend-test.stack.ymlとfrontend-test.params.jsonの2ファイルです。公式ドキュメントのWebページはfrontend.stack.ymlとfrontend-test.config.ymlという旧いファイル名のまま残っているので、書き出し結果と照合するときはCLIのヘルプ側を正としてください。同じpackageサブコマンドはcopilot env packageとcopilot job packageにも用意されており、環境スタックと定期ジョブはそれぞれ別に取り出す必要があります。VPCやECSクラスターを抱えているのは環境側のスタックなので、サービス分だけ保存して満足すると土台が欠けます。

AWS Copilotの新規採用回避と既存環境の移行判断

判断は2つに分かれます。これから作るシステムでCopilotを選ぶ理由はありません。サポートが終了し、新機能やセキュリティ更新を受けられないCLIへの依存を新たに増やすためです。AWSが推奨する移行先は、最小構成ならAmazon ECS Express Mode、細かい制御が要るならCDKの2択です。

一方、すでにCopilotで動いている本番環境には一律の移行期限はありません。いつ剥がすかは、CLIへの依存度とセキュリティ要件から決めることになります。生成物は標準のCloudFormationスタックで、AWSブログも「Since Copilot generates standard CloudFormation templates and stacks, they can be adopted and managed by your teams」として、スタックをそのまま引き継ぐ選択肢を最初に挙げています。先に手を付けるべきはテンプレートの確保で、そのうえでCLIへの依存を減らしていきます。App Runnerについては既存顧客向けの稼働とセキュリティ対応が続くため、移行時期は新機能の必要性や運用要件から個別に判断します。移行先ごとの比較はAWS Copilot CLIサポート終了｜2026年6月12日EOLと移行先3択で詳しく扱っています。

よくある質問

AWS CopilotとGitHub Copilotは同じものですか？

別物です。AWS CopilotはコンテナアプリをECSやApp Runnerへデプロイするためのコマンドラインツールで、コード生成やチャットの機能はありません。名前が共通しているだけで、開発元も用途も異なります。

copilot initは何をするコマンドですか？

アプリケーションの作成とサービスの初期化をまとめて行います。--appでアプリケーション名、--nameでサービス名、--typeで種別、--dockerfileでDockerfileのパスを指定します。--deployを付けると環境の作成とデプロイまで続けて実行されます。

AWS Copilot CLIは今もインストールできますか？

できます。aws/homebrew-tapのcopilot-cli.rbとGitHub Releasesのバイナリはどちらも残っており、入るのは最終版のv1.34.1です。ただしセキュリティ更新は提供されないため、新しい環境への常設は推奨されません。

AWS Copilotのサービス種別にはどんなものがありますか？

サービスが5種類（Load Balanced Web Service、Request-Driven Web Service、Backend Service、Worker Service、Static Site）、ジョブが1種類（Scheduled Job）です。copilot svc initで選べるのは前者の5つで、Scheduled Jobはcopilot job init側の選択肢になります。

サポート終了後、Copilotでデプロイした環境はどうなりますか？

Amazon ECSデベロッパーガイドは「既存のデプロイは引き続き機能しますが、継続的なメンテナンスは行われません」と記載しています。稼働中のECSサービスやApp Runnerサービスが自動で削除されることはありません。ただしCLI経由の新機能やバグ修正は提供されないため、運用の主体をCloudFormationスタック側へ移す準備が必要です。

関連記事

• AWS Copilot CLIサポート終了｜2026年6月12日EOLと移行先3択
• ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】
• AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い
• AWS App Runnerは終了する？2026年の新規受付停止・メンテナンスモード移行と移行先を解説
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】