公開2026.07.06更新2026.09.16 AWS

ecspressoとは｜ECSデプロイをコードで管理する仕組みと導入手順を解説

ecspresso（エスプレッソ）は、Amazon ECS のサービスとタスク定義だけをコードで管理し、デプロイを回すためのCLIツールです。開発元は面白法人カヤック。Go製・MITライセンスで、GitHubの kayac/ecspresso で公開されています。この記事では読み方と開発元、ecspresso.yml を中心とした定義ファイルの構成、deploy・diff・rollback といった主要コマンド、インストールとinitでの取り込み手順、Blue/Greenデプロイ、Terraform や GitHub Actions との連携までを実装者の目線でまとめます。設定例はそのまま手元で試せる形で掲載し、仕様の根拠となる公式ドキュメントへのリンクもその場で確認できる構成です。CloudFormation や CDK との役割分担で採用を判断したい方向けに、見送るべき場面も条件付きで示します。

まとめ：ecspressoはECSのサービスとタスク定義に絞ったデプロイ管理ツール

ecspresso が扱う範囲は狭く、そこが利点です。VPCやALB、IAMといった土台のインフラは対象外で、ECSサービスとタスク定義の2つだけを宣言的に管理します。土台はTerraformやCloudFormationに任せ、その出力を tfstate プラグイン等で参照しながらデプロイだけをecspressoが受け持つ、という分業が基本形です。

日常運用は ecspresso diff で差分を確認し、ecspresso deploy で反映、問題があれば ecspresso rollback で戻す、という流れに集約されます。定義は ecspresso.yml と ecs-task-def、ecs-service-def の3ファイルです。JSONに加えてJsonnetとテンプレート関数を使い、環境変数やSecrets Managerの値を差し込めます。小〜中規模のECS運用で「土台はIaC、デプロイは軽量ツール」という構成を取りたいときに向きます。GitHubのリリース一覧で実測したところ、2026年9月時点の安定版は v2.8.6（2026年9月4日公開）で、系列としては2.8系が現行です。

ecspressoの基本｜読み方と開発元カヤック・ECS特化の設計思想

まず名前から整理します。ecspresso はコーヒーの espresso をもじった綴りで、読み方は「エスプレッソ」です。ECS の3文字を頭に含める言葉遊びになっています。

開発元は面白法人カヤック｜Go製・MITライセンスのOSSツール

ecspresso を開発・公開しているのは面白法人カヤック（KAYAC）で、ソースはGitHubの kayac/ecspresso にあります。リポジトリのメタ情報を2026年9月に確認した時点で、ライセンスはMIT、実装言語はGo、既定ブランチは v2、スター数は1,100台でした。Goの単一バイナリで動くため、実行環境にランタイムを追加で用意する必要がありません。CI環境やローカルに1つ置けば動く手軽さが、後述するGitHub Actionsでの使いやすさにつながっています。

「ECSサービスだけを宣言的に管理する」という設計思想の割り切り

ecspresso の思想は、対象をECSのサービスとタスク定義に絞り込んだ点にあります。ネットワークやロードバランサ、データベースまで面倒を見るCloudFormationやCDKとは狙いが違います。ECSクラスターやALBといった周辺リソースは既存のIaCで作ってある前提です。担当するのは、その上で動くコンテナのデプロイだけです。ECS自体の構成要素（クラスター・サービス・タスク）を先に押さえたい場合は、AWS ECSの基本構成の解説を先に読むと、ecspressoが管理する範囲の境界が理解しやすくなります。デプロイ対象のコンテナイメージを置く先については、AWS ECRの料金とpush手順を合わせて見ておくと、タスク定義に書くイメージURIの形が具体的につかめます。

ecspressoが呼ぶECS APIと必要なIAM権限の考え方

ecspresso がやっていることは、突き詰めれば ECS の API を順番に叩くことです。deploy であれば RegisterTaskDefinition で新しいタスク定義リビジョンを登録し、続けて UpdateService でサービスを差し替え、安定するまで待ちます。実行するIAMロールには、この一連のAPIに対する権限が要ります。どの権限を与えればよいかは、リポジトリに IAMポリシーのサンプルが置かれているので、そこを起点に自環境向けへ削るのが確実です。CIから実行する場合は、このポリシーを付けたロールをOIDCで引き受ける形にすると、長期キーを置かずに済みます。

ecspressoの定義ファイルとテンプレート機能で構成を管理する仕組み

ecspresso の設定は3つのファイルに分かれます。役割を分けておくと、どこを直せば何が変わるかが追いやすくなります。

ecspresso.ymlとタスク定義・サービス定義の役割分担

中心になるのが ecspresso.yml で、対象クラスター名・サービス名・リージョン、そして参照する定義ファイルのパスを書きます。ここからタスク定義ファイル（ecs-task-def）とサービス定義ファイル（ecs-service-def）を読み込む構成です。

ファイル	役割
ecspresso.yml	クラスター・サービス名・参照先を指定
ecs-task-def	コンテナ・CPU・メモリ等の定義
ecs-service-def	起動タイプ・台数・ネットワーク設定

タスク定義がコンテナそのものの仕様、サービス定義がそれを何台どう動かすかの設定、と覚えると混乱しません。最小構成の ecspresso.yml は次の形です。timeout は省略時10分、required_version はecspresso本体の版を縛るキーで、範囲から外れた版で実行すると失敗して止まります。

region: ap-northeast-1
cluster: default
service: myservice
service_definition: ecs-service-def.json
task_definition: ecs-task-def.json
timeout: 10m
required_version: ">= 2.0.0, < 3"
ignore:
  tags:
    - ecspresso:ignore

JSONとJsonnet・テンプレート関数で値を差し込む書き方

定義ファイルはJSONで書けますが、Jsonnetにも対応します。Jsonnetを選ぶ利点は、変数や関数で共通部分をまとめ、環境ごとの差分を小さくできるという点です。加えてテンプレート関数が用意されており、env や must_env で環境変数を、tfstate でTerraformの状態ファイルから値を、SSMパラメータやSecrets Managerの参照も定義内に埋め込めます。env は既定値を第2引数で渡せる一方、must_env は未定義なら即座に中断するので、イメージタグのように取り違えが致命傷になる値はこちらを使います。

{
  "family": "myapp",
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:{{ must_env `IMAGE_TAG` }}",
      "essential": true
    }
  ]
}

この状態で IMAGE_TAG=stable ecspresso deploy と実行すれば、タグだけが差し替わった新しいリビジョンが登録されます。パスワードやAPIキーは定義に直書きせず、タスク定義の secrets 経由でSecrets ManagerやSSMから渡す形にします。渡し方の仕様を確認できるのはAWSの機密データの受け渡しに関するドキュメントです。

required_versionとignoreタグで運用中の事故を減らす設定

チームで使い始めると、手元とCIでecspressoの版が食い違う事故が起きます。required_version に範囲を書いておけば、想定外の版で実行された時点で止まるため、差分が意図せず広がる前に気づけます。もう一つの ignore.tags は、diff と deploy の比較対象からタグを外す設定です。コスト配賦タグや監視ツールが後付けするタグをECS側で足している場合、これを指定しないと毎回差分として出続け、本当に見たい変更が埋もれます。運用が回り出してから足すのではなく、init直後に両方を入れておくと後が楽になります。

ecspressoをインストールしinitで既存ECSサービスを取り込む手順

これから使い始める場合、ゼロから定義を書く必要はありません。既存のECSサービスがあれば、そこから設定を生成できます。

インストール方法｜バイナリ・Homebrew・aquaでの導入

Goの単一バイナリなので、GitHubのリリースページから対象OS向けの実行ファイルを取得してパスを通せば動きます。macOSやLinuxではHomebrew、バージョン固定を厳密にしたい場合はaquaやasdf経由での導入も一般的です。Dockerイメージも配布されているため、ローカルに何も入れずコンテナ内で完結させる選択肢もあります。CIコンテナ内で使われる導入方法は、公式のインストールスクリプトでバージョンを指定して入れる形です。導入直後に ecspresso version で版を確認しておくと、後述のGitHub Actionsとの版ずれを防げます。

initコマンドで稼働中ECSサービスから定義ファイルを生成

既存サービスの取り込みに使うのが ecspresso init です。クラスター名とサービス名を渡すと、稼働中の設定を読み取って ecspresso.yml・タスク定義・サービス定義の雛形を書き出します。手書きゼロで現状をコード化できるため、AWSコンソールで作ってきたサービスを後からコード管理へ移す入口になります。生成直後に diff を走らせ、差分ゼロになることを確かめてから運用を始めるのが安全です。

$ ecspresso init --region ap-northeast-1 --cluster default --service myservice --config ecspresso.yml
[INFO] [myservice/default] saving service definition [path:ecs-service-def.json]
[INFO] [myservice/default] saving task definition [path:ecs-task-def.json]
[INFO] [myservice/default] saving config [path:ecspresso.yml]

$ ecspresso diff --config ecspresso.yml
$ ecspresso verify --config ecspresso.yml

既存ECSサービスの取り込み直後に差分が出る原因と定義の調整方法

init 直後の diff が空にならないことは珍しくありません。よくある原因は3つで、ECS側が自動で補完するフィールド（タグやプラットフォームバージョン）、Auto Scalingが書き換えた desiredCount、そして監視エージェントが後から付けたタグです。desiredCount はサービス定義から外してECS側に任せるか、スケール操作を ecspresso scale に寄せると衝突しなくなります。タグ由来の差分を抑える設定は、前述の ignore.tags です。ここを詰めずにdeployへ進むと、意図しない値で上書きしてしまうため、差分ゼロを確認してから次へ進みます。

主要コマンドで回すデプロイ運用｜diffからrollbackまでの流れ

ecspresso はサブコマンドで操作します。日々使うのは一握りで、まず4つ押さえれば実務は回ります。

まず押さえる4コマンド｜diff・deploy・rollback・run

ecspresso diff：手元の定義と稼働中のECSの差分を表示する
ecspresso deploy：タスク定義を登録しサービスを更新する
ecspresso rollback：直前のタスク定義リビジョンへ戻す
ecspresso run：単発のバッチ的なタスクを1回だけ実行する

本番反映の前に ecspresso diff で差分を目視し、意図しない変更が無いか確認してから ecspresso deploy に進む、という手順が事故を減らします。rollback は既定で、タスク定義ファミリーを降順に並べて現行の1つ前のリビジョンを選びます。ECSデプロイコントローラーのサービスで進行中のデプロイがある場合は、そのデプロイを止める動きになる点も押さえておくとよいでしょう。

コンテナに入るexec・定義を確認するverifyとrender

運用フェーズでは補助コマンドも効きます。ecspresso exec はECS Execを使って稼働中コンテナへ入るコマンドで、実行には session-manager-plugin がPATHにある必要があります。仕組みそのものはAWSのECS Execによるデバッグのドキュメントが一次情報です。ecspresso verify は、クラスターの存在、ターゲットグループとコンテナ名・ポートの対応、タスクロールが ecs-tasks.amazonaws.com から引き受けられるか、イメージが実在するか、シークレットが読めるか、ログストリームを作れるかまでを事前に点検します。ecspresso render はテンプレート展開後の最終的な定義を出力するので、環境変数やtfstate参照が期待どおり解決されるかを反映前に目視できます。

tasksとexecで稼働中タスクを調べ台数を変える操作手順

障害調査では、まず動いているタスクを特定するところから始まります。ecspresso tasks は設定に紐づくタスクを一覧し、find でJSONとして中身を見る、logs でCloudWatch Logsを引く、stop で止める、といった操作を提供します。v2以降、この部分の実装は ecsta をライブラリとして取り込む形です。ポートフォワードを張れば、ALBを通さずに手元のブラウザから直接コンテナへ届きます。台数の増減は deploy を通さずに ecspresso scale だけで済ませられます。

$ ecspresso tasks list --output table
$ ecspresso tasks logs --id abcdef0123456789
$ ecspresso exec run --command "sh"
$ ecspresso exec portforward -L 8080:localhost:80
$ ecspresso scale --tasks 10

デプロイ戦略の選択｜ローリング更新とBlue/Greenの使い分け

ecspresso はECSのデプロイ方式をそのまま扱えます。既定はローリング更新ですが、無停止で切り替えたい要件ではBlue/Greenを選べます。

ローリング更新とBlue/Greenデプロイの違いと選択条件

ローリング更新は稼働中のタスクを少しずつ入れ替える方式で、追加コストがかからず設定も単純です。一方のBlue/Greenは新環境（Green）を用意してから一斉に切り替えるため、切り戻しが速く、リリース時のダウンタイムを抑えられます。ecspresso はECSデプロイコントローラーによるBlue/Greenと、AWS CodeDeployを使うBlue/Greenの双方に対応するツールです。方式ごとの仕組みや切り替えの流れは、ブルーグリーンデプロイメントの仕組みで図解している内容が判断材料になります。

ECSデプロイコントローラーでBlue/Greenを設定する定義の書き方

ECSデプロイコントローラー方式なら、サービス定義に2つのキーを足すだけで切り替わります。deploymentController を ECS に、deploymentConfiguration の strategy を BLUE_GREEN にする形です。切り替え後に様子を見る時間は bakeTimeInMinutes で指定します。より細かく制御したい場合は lifecycleHooks に Lambda を紐づけ、PRE_SCALE_UP から POST_PRODUCTION_TRAFFIC_SHIFT までの各段階で検証を挟めます。設定可能な項目と挙動はAWSのECS Blue/Greenデプロイのドキュメントが根拠です。

{
  "deploymentController": { "type": "ECS" },
  "deploymentConfiguration": {
    "strategy": "BLUE_GREEN",
    "bakeTimeInMinutes": 1,
    "maximumPercent": 200,
    "minimumHealthyPercent": 100
  }
}

earlySuccessCriteriaでローリング更新を早く終わらせる設定

ローリング更新のまま待ち時間だけ縮めたい場合は、earlySuccessCriteria という仕組みが使えます。desiredCount のうち指定した割合が新リビジョンで健全になった時点でデプロイを完了扱いにし、残りのタスク入れ替えはデプロイ枠の外で進めます。旧タスクの後始末で選べるのは、DEFERRED（デプロイ完了後に片付ける）と BLOCKING（完了前に片付ける）の2方式です。挙動の一次情報はAWSのearly success criteriaのページです。ecspresso 側では verify がこの設定の妥当性も見てくれます。

{
  "deploymentConfiguration": {
    "strategy": "ROLLING",
    "minimumHealthyPercent": 50,
    "earlySuccessCriteria": {
      "enable": true,
      "healthyPercent": 50,
      "sourceServiceRevisionCleanup": "DEFERRED"
    }
  }
}

Fargate起動タイプとの組み合わせで運用負荷を下げる工夫

起動タイプにFargateを選ぶと、EC2インスタンスの管理から解放され、ecspresso側はコンテナ定義の管理に専念できます。サーバーの面倒を見ずにデプロイだけをコード化したいチームには相性が良い組み合わせです。コストを削りたい場合は、サービス定義の capacityProviderStrategy に FARGATE と FARGATE_SPOT を混ぜ、base と weight で比率を決める手もあります。単価そのものはAWS Fargateの料金ページが一次情報で、EC2起動タイプとの違いはAWS Fargateの料金とEC2との違いで数値とともに整理しています。

他のIaCツールとの違いと連携｜TerraformとGitHub Actionsの構成

ecspresso を単体で捉えると役割が見えにくいですが、周辺ツールとの分業で理解すると位置づけがはっきりします。

tfstateプラグインでTerraformの出力を参照する連携

土台のインフラをTerraformで構築している場合、ecspresso の tfstate プラグインでその状態ファイルを参照できます。ecspresso.yml に plugins として tfstate を登録し、S3上のstateやローカルファイルのパスを指すだけで、定義ファイル側から tfstate と tfstatef の2つの関数が使えるようになります。サブネットIDやセキュリティグループ、ターゲットグループのARNを取り出して差し込めるため、IDのハードコードが消え、環境を作り直しても定義側の修正が要りません。TerraformをHCP（Terraform Cloud）で運用している場合の管理像は、HCP Terraformによるインフラ管理の解説が参考になります。

plugins:
  - name: tfstate
    config:
      url: s3://my-bucket/terraform.tfstate

"networkConfiguration": {
  "awsvpcConfiguration": {
    "subnets": ["{{ tfstatef `aws_subnet.private['%s'].id` `az-a` }}"],
    "securityGroups": ["{{ tfstate `data.aws_security_group.default.id` }}"]
  }
}

CloudFormation・CDKとecspressoの役割の違い

CloudFormationやCDKはインフラ全体をスタックとして記述するのに向きます。ecspresso はそこには踏み込まず、ECSサービスとタスク定義だけを速く安全に更新する道具です。両者は競合ではなく、土台をCDKやCloudFormation、あるいはTerraformで作り、その上のデプロイをecspressoが担う、という重ね方が現実的です。CloudFormationで土台を組んでいる場合も、ecspresso には cfn_output や cfn_export といった参照関数があるため、スタックの出力値をそのまま定義へ流し込めます。CDK側の書き味や守備範囲を先に押さえたい場合は、AWS CDKの仕組みとTerraformとの違いを読むと分担の線が引きやすくなります。

GitHub Actionsでecspressoを実行するCI/CD自動化の構成

単一バイナリで動く特性が効くのがCI/CDです。GitHub Actions では kayac/ecspresso@v2 が公式に提供されており、action.ymlを見ると version・version-file・github-token・args の4入力を持つcomposite actionだとわかります。version-file に .ecspresso-version のようなファイルを指せば、ローカルとCIで同じ版に揃えられます。latest 指定も可能ですが、新版公開のタイミングで挙動が変わり得るため、公式READMEでも推奨されているのは版の固定です。mainへのマージをトリガーにdeployを走らせれば、レビュー済みのマージがそのまま本番反映につながる仕組みになります。

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: kayac/ecspresso@v2
        with:
          version-file: .ecspresso-version
      - run: ecspresso verify --config ecspresso.yml
      - run: ecspresso deploy --config ecspresso.yml

GitHub ActionsによるCI/CDパイプラインの基礎はGitHub ActionsでのCI/CD自動化で全体像をつかめます。土台のTerraform適用まで同じワークフローに載せるなら、OIDCで権限を渡す構成を解説したGitHub ActionsとTerraformでAWSのCI/CDを構築する手順が、ecspressoのdeployジョブにそのまま応用できます。

ecspresso 2.8系で増えた機能｜Express modeとエージェント連携

2.8系では、定義の書き方そのものを簡素化する方向と、ツールの使い方をLLMエージェントへ渡す方向の2つで機能が増えています。どちらも既存の運用を壊さずに足せます。

ECS Express modeを1ファイルの定義でデプロイする手順

ECS Express は、タスク定義とサービス定義を分けずに1ファイルで済ませるAWS側の仕組みで、ecspresso もこれに対応します。必要なのは実行ロール、Express用のインフラストラクチャロール、そして primaryContainer の3つだけです。最小構成なら次の5行程度で動き、細かいネットワーク設定はAWS側の既定に任せられます。仕様の範囲を確認できる一次情報はAWSのECS Expressの概要です。検証用の環境や社内ツールのように、凝ったロードバランサ設定が要らない用途から試すのが向いています。

{
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices",
  "primaryContainer": {
    "image": "nginx:latest"
  }
}

skillsコマンドでLLMエージェントに操作手順を読み込ませる

もう一つが skills コマンドです。ecspresso 自身が Agent Skill 形式の手順書を同梱しており、ecspresso skills install を実行すると利用者のホーム配下へSKILL.mdが置かれ、対応するコーディングエージェントが自動で見つけます。--scope repo を付ければリポジトリ直下へ入るので、コミットしてチーム全員のエージェントに同じ手順を配ることが可能です。list・status・update・uninstall・reinstall の各サブコマンドで管理でき、ツールの使い方を口頭やWikiで共有する手間が減ります。

Service Connect・EBSボリューム・VPC Latticeへの対応状況

定義側の対応範囲も広がっています。サービス間通信を名前解決で結ぶ ECS Service Connect、タスクへブロックストレージを付ける EBS ボリューム、S3上のファイルをボリュームとして渡す仕組み、そして VPC Lattice との連携が、いずれもサービス定義・タスク定義の記述だけで扱えます。CloudWatchメトリクスを高解像度で出す設定にも対応しました。ecspresso が「ECSの新機能に追随してくれるか」は採用判断で効く観点で、ここに手が入り続けている点は、土台をIaCに預けたうえでデプロイ層だけを任せる構成の前提になります。

ecspressoを採用すべき条件と見送るべき場面の判断基準

ここは言い切ります。ecspresso はあらゆるチームに当てはまる正解ではありません。向く条件と、あえて選ばない場面を分けて示します。

採用が向く条件｜ECS運用が既にあり土台をIaC管理している

採用が効くのは、次の条件がそろう場合です。すでにECS（できればFargate）でサービスを動かしており、VPCやALBなど土台をTerraformやCloudFormationで管理している。そのうえで、デプロイ手順がAWSコンソール頼りや手製スクリプトになっていて、差分確認と切り戻しを仕組み化したい。この状態なら、initで現状を取り込みdiff起点の運用へ移すだけで、デプロイの再現性と安全性が上がります。GitHub Actionsと組み合わせれば、レビュー済みのマージが本番反映まで一直線につながります。

見送るべき場面｜ECS未導入や単一ツールでの完結を優先するとき

逆に見送ったほうがよい場面もあります。そもそもECSを使っておらず、LambdaやApp Runner、あるいはKubernetes中心の構成なら、ecspressoの守備範囲から外れます。また、インフラもデプロイも1つのツールに寄せて学習コストを一本化したい組織では、CDKやTerraformだけで完結させる判断のほうが運用がぶれません。ECSサービスが1つだけで更新頻度も低いなら、専用ツールを足すより既存のIaCにデプロイを含める方が管理対象を増やさずに済みます。

本番導入前に決めておく3点｜権限・版固定・差分ゼロの確認手順

採用すると決めたら、走り出す前に3点を決めておくと後戻りが減ります。1つ目はCIが引き受けるIAMロールの範囲で、サンプルポリシーを削って必要最小限に絞る方針です。2つ目は required_version と version-file による版の固定で、手元とCIの差をここで潰します。3つ目は「diffが空である」をリリース前提条件として明文化することです。この3点が曖昧なまま本番に入れると、原因の切り分けに時間を取られます。ECS基盤の設計からデプロイ自動化までを外部の手を借りて進めたい場合は、AWSインフラ構築の支援で相談を受け付けています。

よくある質問

ecspresso の読み方や他ツールとの違いなど、導入前に迷いやすい点をまとめます。

ecspressoの読み方は何ですか？

「エスプレッソ」と読みます。コーヒーの espresso に ECS を掛けた綴りで、開発元の面白法人カヤックによる名付けです。発音上はコーヒーのエスプレッソと同じで問題ありません。

ecspressoとTerraformはどちらを使うべきですか？

二者択一ではなく併用が基本です。VPCやALB、IAMといった土台はTerraform、その上のECSサービスとタスク定義のデプロイはecspresso、と役割を分けます。ecspresso の tfstate プラグインでTerraformの出力を参照すれば、両者を無理なくつなげられます。

ecspressoでBlue/Greenデプロイはできますか？

できます。対応するのは、ECSデプロイコントローラーによるBlue/Greenと、AWS CodeDeployを用いるBlue/Greenの2方式です。前者はサービス定義に deploymentController と strategy を書くだけで有効になり、bakeTimeInMinutes で切り替え後の待機時間を指定できます。

ecspressoはどうやってインストールしますか？

Go製の単一バイナリのため、GitHubのリリースから対象OSの実行ファイルを取得してパスを通せば動きます。Homebrewやaqua、asdf、Dockerイメージ、公式インストールスクリプトでの導入も可能です。CIではバージョンを固定して入れると、環境間の版ずれを防げます。

ecspressoの最新バージョンはどれですか？

GitHubのリリース一覧を2026年9月に確認した時点では、安定版の最新は v2.8.6（2026年9月4日公開）で、2.8系が現行の系列です。nightlyのプレリリースも並行して出ているため、本番では安定版のタグを明示して固定する運用が無難です。

ecspressoとecs-deployやCodeDeployの違いは何ですか？

ecspresso はタスク定義とサービス定義をファイルとして手元に持ち、差分を見てから反映する点が違います。CodeDeploy はデプロイの進行とトラフィック切り替えを担うAWS側のサービスで、ecspresso からはBlue/Greenの実行手段として呼び出す関係です。競合ではなく、定義の管理者と切り替えの実行者という分担になります。