あーECSね。おいしいよね。

ECS、Docker、タスク...このへん、用語がたくさんあってややこしや！
調べても小難しい説明ばかりで結局なんなのよ！
ってなりませんか？？
（「なりません」の方は暖かい目で読んでください。）

こういうのってイメージで覚えたいよね！
というわけで、

GitHub Copilot
Gemini 3 Pro
Googleスライド

のG3のみなさんにご協力を仰ぎ、図解してみました。
※ Geminiさんの作成する画像や動画はまだ日本語がわりと苦手ですが、御愛嬌
※ 画像はGeminiで作成し、一部スライドで加工してます

ECS

ではまず、ECS全体から！

ECSはキッチン（クラスター）がたくさんあるレストランです。
キッチンは本番用カレーキッチン、開発用カレーキッチンと細かくわけて使ったりします。

ECSで、Fargate使うか？EC2使うか？の選択イメージはこんなかんじ。

お手軽な~~レントル~~レンタルキッチンのほうが人気なイメージがありますが、コストメリットで選択する方も多いのではないでしょうか。

ECR

お次はパントリー！
要するにここは、開発したソースコードをぎゅっとしたカレールー（イメージ）をたくさん置いている場所です。

Geminiのプロンプトでは「カレールーを10個置いてあるパントリーの絵」と言ったんですが、100個くらいありそうですね。

タスク定義

カレールー（イメージ）をどのようにして提供するのか詳しいことを書いたのがレシピことタスク定義！
１個のタスク定義の中に複数のコンテナ定義が書けます。
つまりタスク定義は単品（コンテナ）をどう組み合わせてセットにするかの概要も含まれています。

サービス

それらを踏まえて！
ドヤ顔でお客さんにセットメニューを提供しているのがシェフ（サービス）です。
キッチン（クラスター）で、
レシピ（タスク定義）の通りにカレールー（イメージ）を使って、
注文数のセットメニュー（タスク）を提供します。

基本的に１シェフ１料理がスマートなやり方とされているため、
カレーシェフはカレーセットだけ、デザートシェフはデザートだけを作ります。
ひとりのシェフにフルコースをお願いするとてんやわんやですもんね。

ちなみに、シェフ（サービス）を無視して、野良のカレーセット（タスク）を提供することもできます。このタスクに関してはシェフは関与しません。
野良のタスクを提供するのはそう、あなたです。

deploy

ではECSのdeployってなにがどうなること？

というと、まず、おうち（ローカル）で開発チームがカレーをもっとおいしくします。（ソースコード改修）
出来上がったら、そのカレーをルー設計図（Dockerfile）に従ってDockerでルー（イメージ）にする！（docker build）
そしてDockerで出来上がったルー（イメージ）をパントリー（ECR）に送ります。（docker push）
これで新しいルーがキッチン（クラスター）で使えるようになったね✨

新しいルーが出来たので、レシピ（タスク定義）を変更します。
そしてシェフ（サービス）に、レシピの変更と次の必要セット数を伝えます。（ecs update-service ... --desired-count xx）

するとシェフは提供中のセットメニューをすべて破棄し、新しいセットメニューを作り直します🍛

ここで、1個破棄して１個作りなおしていくやり方がローリングアップデート、
裏で新カレーセットを3つ用意しておいて、すっと入れ替えるのがBGdeployです。

ちなみにこのdeployの流れをGeminiで動画にしてみたらこうなりました。
何度かプロンプト修正したんですが、うまく行かなかった
※10MBまでしかQiitaにアップできず、めちゃくちゃ縮小したら画質悪くなりましたが、Geminiさんが作った元動画はもちろん画質良く声も効果音もありなのです

１年後に同じプロンプトで動画作成したらどうなっているのかやってみたいですね！

さて、カレーのいい匂いがしてきたところで
それでは、メリークリスマス

最後まで読んでいただきありがとうございました。

株式会社ネクスウェイ Advent Calendar 2025では明日以降も、開発メンバーがそれぞれの「好き」と「学び」を自分の言葉で綴っていく予定です。

明日 12 日目の記事は、同じくネクスウェイ開発メンバーの @ryu_nxw さん です。

引き続き、お楽しみください🎄

もっと他の記事も読んでみたい方

当社に興味がある方はこちら👀

エンジニア採用について | 株式会社ネクスウェイ