第16章 クラウドとCI/CD

第16章では、第15章で整理したアプリの実行環境を、クラウド（AWS）とCI/CDへ接続する。ここでは、変更を確かめて環境へ届け、結果を見て、必要なら止める一連の流れに出てくる用語を解説する。AWSサービス名は研修用の標準構成として登場するが、実務でも広く使う固有名詞なので収録する。

クラウド

• 読み：クラウド（cloud / cloud computing）
• 一言で言うと：自分で物理サーバーを持たず、必要なときにインターネット越しに計算資源を借りて使う方式。
• くわしく：クラウドを使うと、サーバー、データベース、ストレージなどを必要なときに借りて、使った分だけ費用を払える。自前でハードウェアを用意する必要がないので、小さく始めて後から増やせる。本章では標準クラウド環境としてAWSを使う。ただし借りた資源は使い続けると費用が発生するので、作る責任と消す責任がセットになる点に注意する。
• 具体例：支援ステータス機能を含む研修用Webアプリを、自分のPCではなくAWS上のApp Runnerで動かし、利用者がインターネット経由でアクセスできるようにする。
• つまずきやすい点：「クラウドに置けば勝手に安全・安価になる」と誤解しやすい。権限、secret、監視、cleanupは自分で設計する必要がある。
• 関連語：AWS account（第16章）、region（第16章）、App Runner（第16章）
• テキスト本文での登場箇所：第16章「AWSをサービス名ではなく役割で見る」

CI

• 読み：シーアイ（Continuous Integration／継続的インテグレーション）
• 一言で言うと：変更を取り込む前後に、壊れていないかを継続的に確かめる流れ。
• くわしく：CIを使うと、Pull Requestのたびにinstall、lint、type check、test、buildなどを自動で実行できる。人が確認を忘れても、機械が同じ手順で検証してくれる。ここで失敗したら、reviewやmergeに進む前に直す。CIが通っていない変更をCD（環境への配布）へ進めないことが基本になる。
• 具体例：支援ステータス更新APIを直したPRで、CIがtestとbuildを自動実行し、失敗していればmergeに進まないようにする。
• つまずきやすい点：CIの失敗を無視して手動でmergeしてしまうと、検証の意味がなくなる。どの失敗で止めるかを事前に決める。
• 関連語：CD（第16章）、GitHub Actions（第16章）、workflow（第16章）、smoke test（第16章）
• テキスト本文での登場箇所：第16章「CIとCDを分ける」

CD

• 読み：シーディー（Continuous Delivery／継続的デリバリー、または Continuous Deployment／継続的デプロイ）
• 一言で言うと：CIで確かめた変更を、stagingやproductionへ届けて動作を確認する流れ。
• くわしく：CDを使うと、検証済みの変更をimage build、ECRへのpush、App Runnerへのdeploy、smoke testという同じ手順で環境へ届けられる。Continuous Deliveryは「いつでも出せる状態にする」、Continuous Deploymentは「自動で出すところまで進める」という違いがある。CDが成功したように見えても、deploy後の確認（ログやsmoke test）を省略しない。
• 具体例：mainへmergeされたら、支援ステータス機能のimageをECRへpushし、staging App Runnerへdeployして、health endpointが200を返すか確認する。
• つまずきやすい点：deploy成功＝正常と思い込みやすい。アプリ起動後にDB接続エラーが出ていることもあるので、ログまで見る。
• 関連語：CI（第16章）、デプロイ（第16章）、smoke test（第16章）、rollback（第16章）
• テキスト本文での登場箇所：第16章「CIとCDを分ける」

pipeline

• 読み：パイプライン（pipeline）
• 一言で言うと：変更を検証してから環境へ届けるまでの、つながった一連の自動処理。
• くわしく：pipelineは、PRでのCIから、merge後のbuild、push、deploy、smoke testまでを順番につないだ流れである。各段階が前の段階の成功を前提にするので、途中で失敗すれば先へ進まない。CI/CDはこのpipelineを毎回同じ考え方で実行できるようにする仕組みである。手作業だと手順漏れが起きやすいが、pipelineにすると流れがそろう。
• 具体例：支援ステータス機能の変更が「PR → CI → review → merge → image build → ECR push → App Runner deploy → smoke test」という1本の流れを通って利用者へ届く。
• つまずきやすい点：pipelineを組むこと自体が目的ではない。いつ・何を・どの順で・どの権限で実行するかを説明できることが大切。
• 関連語：CI（第16章）、CD（第16章）、workflow（第16章）、デプロイ（第16章）
• テキスト本文での登場箇所：第16章「CIとCDを分ける」

デプロイ

• 読み：デプロイ（deploy／deployment）
• 一言で言うと：作った変更を、利用者が使える環境へ反映して動かすこと。
• くわしく：デプロイは、環境で一度動かして終わりではなく、変更を繰り返し届ける作業である。そのたびに、何を出すか、何で確認したか、どこへ出すか、出した後に何を見るか、問題があればどう戻すかを扱う。手作業だけに頼ると、古いimageを出す、secretの反映先を間違えるといった失敗が起きやすい。CI/CDは、このデプロイの流れをそろえるための仕組みである。
• 具体例：支援ステータス機能の新しいimageを、staging App Runnerへデプロイし、確認できたらproductionへデプロイする。
• つまずきやすい点：「動かして終わり」と考えがち。deploy後のsmoke testとログ確認まで含めて1回のデプロイと考える。
• 関連語：CD（第16章）、staging（第16章）、production（第16章）、rollback（第16章）
• テキスト本文での登場箇所：第16章「デプロイは、一回動かす作業ではなく届け続ける流れである」

AWS

• 読み：エーダブリューエス（Amazon Web Services）
• 一言で言うと：Amazonが提供するクラウドサービスの総称。
• くわしく：AWSは、計算（compute）、データベース、ストレージ、ネットワーク、権限管理など多くのサービスを提供している。本章では標準クラウド環境としてAWSを使うが、サービス名を網羅的に暗記する章にはしない。account、region、IAM、network、compute、database、registry、secrets、logsといった役割で構成を見ることを優先する。実務ではECS、EKS、Lambdaなど別の選択肢もある。
• 具体例：支援ステータス機能のWebアプリを、AWSのApp Runner、ECR、RDSという組み合わせで動かす。
• つまずきやすい点：サービス名を線で結んだだけでは設計説明にならない。どこへ入り、どこで実行し、どこへ保存するかという役割で見る。
• 関連語：AWS account（第16章）、region（第16章）、IAM（第16章）
• テキスト本文での登場箇所：第16章（章導入）「第16章 クラウドとCI/CD」

AWS account

• 読み：エーダブリューエス アカウント（AWS account）
• 一言で言うと：請求、権限、リソースをまとめる、AWSの一番大きな境界。
• くわしく：AWS accountは、費用の請求先、誰が何をできるか（権限）、どんなリソースを持つかをまとめる単位である。会社や環境ごとにaccountを分けることもある。account IDは構成を特定できる情報なので、公開資料やPR、ログには書かない方針にする。account単位で境界を意識すると、どこまでが自分の管理範囲かが分かりやすくなる。
• 具体例：支援ステータス機能のstaging用とproduction用で同じaccountを使うか、accountを分けるかを設計時に決め、account IDは公開資料に書かない。
• つまずきやすい点：account IDをスクリーンショットやworkflowファイルにうっかり載せてしまいやすい。公開資料には書かない。
• 関連語：region（第16章）、IAM（第16章）、AWS（第16章）
• テキスト本文での登場箇所：第16章「AWSをサービス名ではなく役割で見る」

region

• 読み：リージョン（region）
• 一言で言うと：AWSのリソースを置く地理的な範囲。
• くわしく：regionは、サーバーやデータベースを物理的にどの地域に置くかを表す。利用者に近いregionを選ぶと通信が速くなりやすく、データの保管場所にも関わる。リソースは特定のregionに作られるので、別regionからは見えないことがある。接続エラーや「リソースが見つからない」ときは、見ているregionが正しいかを確認する。
• 具体例：支援ステータス機能のApp RunnerとRDSを同じregionに置き、CD workflowでもそのregionを指定して接続する。
• つまずきやすい点：操作しているregionと、リソースを作ったregionがずれていると、リソースが見つからないように見える。
• 関連語：AWS account（第16章）、network（第16章）
• テキスト本文での登場箇所：第16章「AWSをサービス名ではなく役割で見る」

IAM

• 読み：アイアム（Identity and Access Management）
• 一言で言うと：AWSで「誰が何をできるか」を決める仕組み。
• くわしく：IAMを使うと、人やサービスごとに許可する操作を細かく決められる。GitHub ActionsからAWSを操作するときも、IAM roleという役割を一時的に借りて動く。roleに与える権限は、必要な範囲に絞る（least privilege）。何でもできる権限を渡すと、設定が壊れたときの影響が大きくなる。trust policyで対象（repository、branch、environment）を絞り、IAM policyで操作を絞る。
• 具体例：支援ステータス機能のCD用IAM roleには「ECRへpushする」「App Runner serviceを更新する」「必要なログを見る」だけを許可する。
• つまずきやすい点：とりあえず広い権限を付けてしまいがち。なぜその権限が必要か説明できないIAM policyは採用しない。
• 関連語：least privilege（第16章）、IAM role（第16章）、OIDC（第16章）、AWS account（第16章）
• テキスト本文での登場箇所：第16章「IAM roleは、最小権限で設計する」

IAM role

• 読み：アイアム ロール（IAM role）
• 一言で言うと：AWSで許可する操作をまとめた「役割」で、人やサービスが一時的に借りて使うもの。
• くわしく：IAM roleは、特定の操作だけを許可した役割である。GitHub Actionsは、OIDCで認証されたうえでこのroleを一時的に借りて（assume role）動く。roleにはtrust policy（誰が借りてよいか）とIAM policy（何をしてよいか）の両方を設定する。production deployに使うroleは、staging deployより強い制約を置くことがある。固定の鍵を置くのではなく、その場で役割を借りる考え方である。
• 具体例：CD workflowが role-to-assume で支援ステータス機能のdeploy用roleを借り、ECRへのpushとApp Runner更新だけを実行できるようにする。
• つまずきやすい点：誰でも借りられるroleにしてはいけない。trust policyで対象repositoryやbranchを必ず絞る。
• 関連語：IAM（第16章）、OIDC（第16章）、least privilege（第16章）、trust policy（第16章）
• テキスト本文での登場箇所：第16章「IAM roleは、最小権限で設計する」

least privilege

• 読み：リースト プリビレッジ（least privilege／最小権限）
• 一言で言うと：必要な操作だけを許可し、それ以上の権限は与えない設計の考え方。
• くわしく：least privilegeは、単に権限を少なくするという意味ではない。そのworkflowやサービスが何をする必要があるかを説明し、その範囲だけを許可することである。権限を絞ると、設定や認証情報が漏れたときの影響を小さくできる。なぜその権限が必要か説明できないIAM policyは採用しない、という基準につながる。
• 具体例：支援ステータス機能のCD roleに、DBを削除する権限や他サービスを触る権限を付けず、deployに必要な操作だけに限定する。
• つまずきやすい点：「とりあえず動かすために広く許可」しがち。後で絞り込むのは難しいので、最初から必要範囲を説明できる形にする。
• 関連語：IAM（第16章）、IAM role（第16章）、trust policy（第16章）
• テキスト本文での登場箇所：第16章「IAM roleは、最小権限で設計する」

OIDC

• 読み：オーアイディーシー（OpenID Connect）
• 一言で言うと：長期の鍵を保存せずに、その場で短期の認証情報を借りるための連携の仕組み。
• くわしく：OIDCを使うと、GitHub Actionsの実行時にGitHubがidentity tokenを発行し、AWSがそれを信頼して短期認証情報を渡せる。長く使えるAWS access keyをGitHub Secretsへ置かずに済むので、鍵の漏えいリスクを下げられる。GitHub Actions側では id-token: write permissionが必要になる。AWS側では、GitHubのOIDC providerを信頼し、特定のrepositoryやbranchに絞ってIAM roleを引き受けられるようにする。
• 具体例：支援ステータス機能のCD workflowが、access keyを置かずにOIDCでAWSへ接続し、IAM roleを借りてECRへpushする。
• つまずきやすい点：trust policyの絞り込みを忘れると、想定外のrepositoryからroleを借りられてしまう。対象を必ず限定する。
• 関連語：IAM role（第16章）、credential（第16章）、IAM（第16章）、GitHub Actions（第16章）
• テキスト本文での登場箇所：第16章「OIDCで、長期access keyを置かない」

credential

• 読み：クレデンシャル（credential／認証情報）
• 一言で言うと：本人やサービスであることを証明するための鍵やトークンなどの情報。
• くわしく：credentialには、AWS access keyのように長期間使えるものと、OIDCで借りるように短期間だけ有効なものがある。長期credentialを置きっぱなしにすると、漏れたときの影響が大きく長く続く。本章では、GitHub ActionsからAWSへ接続するとき、長期access keyではなく短期credentialを借りる方針を基本にする。credentialそのものはPR、ログ、AI入力に貼らない。
• 具体例：支援ステータス機能のdeployで、固定のaccess keyを保存せず、OIDC経由で発行された短期credentialを使ってAWSを操作する。
• つまずきやすい点：「とりあえずaccess keyをSecretsへ」としがち。長期credentialは標準にしない。
• 関連語：OIDC（第16章）、IAM role（第16章）、secret（第16章）
• テキスト本文での登場箇所：第16章「OIDCで、長期access keyを置かない」

ECR

• 読み：イーシーアール（Elastic Container Registry／Amazon ECR）
• 一言で言うと：container imageを置いておくAWSのregistry（保管場所）。
• くわしく：ECRは、第15章のDockerfileから作ったcontainer imageを保管する場所である。CDではimageをbuildしてECRへpushし、App Runnerがそのimageを使ってアプリを実行する。あとから「どの変更を出したか」を追えるよう、imageには追跡できるtag（commit SHAなど）を付ける。latest だけに頼ると、どのimageがデプロイされたか分かりにくくなる。
• 具体例：支援ステータス機能のimageを app:<commit SHA> のtagでECRへpushし、App Runnerからそのtagを指定して動かす。
• つまずきやすい点：latest tagだけで運用すると、デプロイ済みの中身を特定できなくなる。
• 関連語：image tag（第16章）、App Runner（第16章）、デプロイ（第16章）、artifact（第16章）
• テキスト本文での登場箇所：第16章「ECRは、どのimageを出したかを追う場所である」

App Runner

• 読み：アップ ランナー（AWS App Runner）
• 一言で言うと：container imageからWebアプリを動かすAWSのmanaged service。
• くわしく：App Runnerは、サーバー運用の一部をAWS側に任せながらWebアプリを動かせるサービスである。本章では、ECRに置いたimageをsourceにしてApp Runner serviceを作る流れを想定する。ただし、使うimage、待ち受けるport、渡す環境変数、secretの参照先、RDSへの接続、health checkの内容、stagingとproductionの分け方などは自分たちで決める必要がある。imageが正しいだけでは足りない。
• 具体例：支援ステータス機能のimageをsourceに、stagingとproductionでそれぞれApp Runner serviceを作り、必要な環境変数とsecretを渡す。
• つまずきやすい点：managed serviceでも設計は不要にならない。port、secret、DB接続、ログまで含めて確認する。
• 関連語：ECR（第16章）、RDS（第16章）、managed service（第16章）、CloudWatch Logs（第16章）
• テキスト本文での登場箇所：第16章「App Runnerは、Webアプリを動かす場所である」

managed service

• 読み：マネージド サービス（managed service）
• 一言で言うと：サーバー運用の一部をクラウド側に任せられるサービス。
• くわしく：managed serviceを使うと、OSの管理やスケーリングなど運用作業の一部をクラウドに任せられる。App RunnerやRDSはその例である。運用の手間は減るが、設定や設計の責任までなくなるわけではない。どの環境変数を渡すか、どこにsecretを置くか、どう接続するかは自分たちで決める。
• 具体例：支援ステータス機能のWebアプリ実行をApp Runnerに、DB運用をRDSに任せ、アプリ側の設定と接続だけに集中する。
• つまずきやすい点：「managedだから何も考えなくてよい」と誤解しやすい。設定・接続・監視は自分の責任。
• 関連語：App Runner（第16章）、RDS（第16章）、クラウド（第16章）
• テキスト本文での登場箇所：第16章「App Runnerは、Webアプリを動かす場所である」

RDS

• 読み：アールディーエス（Relational Database Service／Amazon RDS）
• 一言で言うと：AWSが管理するリレーショナルデータベースのサービス。
• くわしく：RDSは、PostgreSQLなどのリレーショナルデータベースをAWSが管理してくれるサービスである。本章ではPostgreSQLを想定し、第10章で設計したschemaと第15章のローカルDB構成を、クラウド側のDBへつなぐ前提で考える。接続で詰まったときは、DB host、port、user、password、database名、network、security group、migrationの状態を分けて確認する。本番DBに練習用データをそのまま入れないことも重要である。
• 具体例：支援ステータス機能のApp Runnerが、staging用RDSとproduction用RDSにそれぞれ接続し、DBは環境ごとに分ける。
• つまずきやすい点：「接続できない」の一言では原因が分からない。どの段階（接続先・認証・network・DB準備状態）で失敗しているかを切り分ける。
• 関連語：App Runner（第16章）、network（第16章）、staging（第16章）、production（第16章）
• テキスト本文での登場箇所：第16章「RDSは、DBを置く場所である」

network

• 読み：ネットワーク（network）
• 一言で言うと：どことどこが通信できるかを決める境界。
• くわしく：networkは、AWSのリソース同士やリソースと外部が通信できる範囲を決める。App RunnerからRDSへ接続するには、その間で通信できるnetworkとsecurity groupの設定が必要になる。接続先情報や認証情報が正しくても、networkが通っていなければつながらない。RDS接続のトラブルでは、networkとsecurity groupも確認対象に含める。
• 具体例：支援ステータス機能のApp RunnerからRDSへ接続できないとき、認証情報だけでなくnetworkとsecurity groupが通っているかを確認する。
• つまずきやすい点：認証情報ばかり疑いがちだが、networkやsecurity groupが原因のこともある。
• 関連語：RDS（第16章）、region（第16章）、IAM（第16章）
• テキスト本文での登場箇所：第16章「RDSは、DBを置く場所である」

Secrets Manager

• 読み：シークレッツ マネージャー（AWS Secrets Manager）
• 一言で言うと：DB passwordやAPI keyなどのsecretをクラウド側で管理する置き場所。
• くわしく：Secrets Managerは、.env のような秘密情報をproductionへそのまま持ち込まず、安全に管理・参照するための仕組みである。DB password、SESSION_SECRET、外部API tokenなどを置き、App Runnerなどから参照する。文書には値そのものではなく、置き場所、使う場面、確認手順を書く。secretを変更したら、どの環境へ反映したかを確認する。
• 具体例：支援ステータス機能の DB_PASSWORD と SESSION_SECRET をSecrets Managerに置き、App Runnerから参照する。値はPRやログに貼らない。
• つまずきやすい点：stagingには反映したがproductionには未反映、という差分が起きやすい。反映先を必ず確認する。
• 関連語：Parameter Store（第16章）、secret（第16章）、credential（第16章）
• テキスト本文での登場箇所：第16章「Secrets ManagerとParameter Storeは、secretの置き場所である」

Parameter Store

• 読み：パラメータ ストア（AWS Systems Manager Parameter Store）
• 一言で言うと：設定値やsecretを置いて参照できるAWSの保管場所。
• くわしく：Parameter Store（Systems Managerの機能）は、通常の設定値やsecretを置いて、アプリやworkflowから参照するために使える。Secrets Managerと並んで、secretの置き場所の選択肢になる。通常値（APP_ENV、LOG_LEVELなど）とsecret（DB_PASSWORDなど）を分けて整理し、secretの値そのものは文書やログに書かない。
• 具体例：支援ステータス機能のsecretをParameter StoreまたはSecrets Managerで管理し、設定メモには置き場所と所有者だけを書く。
• つまずきやすい点：通常の設定値とsecretを混ぜて管理すると、扱いの厳しさが曖昧になる。両者を分ける。
• 関連語：Secrets Manager（第16章）、secret（第16章）、環境変数(env)（第16章）
• テキスト本文での登場箇所：第16章「Secrets ManagerとParameter Storeは、secretの置き場所である」

secret

• 読み：シークレット（secret）
• 一言で言うと：DB passwordやtokenなど、外部に漏らしてはいけない秘密の値。
• くわしく：secretは、DB password、SESSION_SECRET、外部API tokenなど、漏れると悪用される値である。通常の設定値（APP_ENV、DB_HOSTなど）とは分けて扱う。クラウドではSecrets ManagerやParameter Storeで管理し、.env をそのままproductionへ持ち込まない。secretの値そのものは、PR、issue、ログ、スクリーンショット、AI入力に貼らない。文書には値ではなく置き場所と確認手順を書く。
• 具体例：支援ステータス機能の DB_PASSWORD をsecretとして扱い、Secrets Managerに置き、設定メモには値を書かず置き場所だけを書く。
• つまずきやすい点：通常の環境変数とsecretを区別せず扱うと、誤って公開してしまう。secretは明確に分けて管理する。
• 関連語：Secrets Manager（第16章）、Parameter Store（第16章）、credential（第16章）、環境変数(env)（第16章）
• テキスト本文での登場箇所：第16章「Secrets ManagerとParameter Storeは、secretの置き場所である」

環境変数(env)

• 読み：かんきょうへんすう（environment variable／env）
• 一言で言うと：環境ごとに変わる設定を、アプリの外から渡す仕組み。
• くわしく：環境変数は、DB接続先、app port、ログレベルなど、local・staging・productionで変わる値を外から渡すために使う。クラウドではApp Runnerの環境変数として設定できる。通常の設定値はそのまま渡してよいが、secretに当たるものはSecrets ManagerやParameter Storeから参照する。同じimageを使い、環境ごとに変わる値を外から渡すと、環境差分を説明しやすくなる。
• 具体例：支援ステータス機能で、APP_ENV や LOG_LEVEL をApp Runnerの環境変数として渡し、DB_PASSWORD はsecret管理から参照する。
• つまずきやすい点：環境変数とsecretを同じ扱いにすると、秘密情報を平文で残してしまう。両者を分ける。
• 関連語：secret（第16章）、Parameter Store（第16章）、staging（第16章）、production（第16章）
• テキスト本文での登場箇所：第16章（クラウドでの設定とsecretの扱い）

CloudWatch Logs

• 読み：クラウドウォッチ ログズ（Amazon CloudWatch Logs）
• 一言で言うと：AWS上で動くアプリやサービスのログを見る場所。
• くわしく：CloudWatch Logsは、deploy後にアプリのログを確認するための場所である。deploy workflowが成功していても、アプリ起動後にDB接続エラーが出ていたり、health checkに失敗していたりすることがある。ログを見るときは、時間帯、service、revision、request、error種別を分ける。ログにsecretや個人情報が出ていないかも確認する。この確認は第17章のオブザーバビリティへつながる。
• 具体例：支援ステータス機能をdeployした後、CloudWatch Logsで起動時のDB接続エラーや重大なエラーがないかを確認する。
• つまずきやすい点：deploy成功だけで安心しがち。ログを見て初めて起動後のエラーに気づけることが多い。
• 関連語：App Runner（第16章）、smoke test（第16章）、デプロイ（第16章）
• テキスト本文での登場箇所：第16章「CloudWatch Logsは、出した後を見る場所である」

GitHub Actions

• 読み：ギットハブ アクションズ（GitHub Actions）
• 一言で言うと：リポジトリへの変更をきっかけに、決めた手順を自動実行するGitHubの仕組み。
• くわしく：GitHub Actionsは、PRやmainへのpushなどをトリガーに、CI/CDの手順を実行する場所である。workflowの中にjobがあり、jobの中にstepがある。PR時は変更前の検証を、main merge後はimage build、ECR push、staging deploy、smoke testを実行できる。AWSへ接続するときは、長期access keyではなくOIDCで短期credentialを借りる。id-token: write などのpermission設定も行う。
• 具体例：支援ステータス機能のリポジトリで、PRが作られたらCI workflowを、mainへmergeされたらdeploy workflowを自動で動かす。
• つまずきやすい点：YAMLを書くこと自体が目的になりがち。いつ・何を・どの順で・どの権限で実行するかが本質。
• 関連語：workflow（第16章）、CI（第16章）、CD（第16章）、OIDC（第16章）
• テキスト本文での登場箇所：第16章「GitHub Actionsは、いつ何を実行するかの記録である」

workflow

• 読み：ワークフロー（workflow）
• 一言で言うと：GitHub Actionsで実行する手順をまとめた定義（YAMLファイル）。
• くわしく：workflowは、いつ（on）、どんなjobとstepを、どの順番で実行するかをYAMLで記録したものである。1つのworkflowの中に複数のjobがあり、jobの中に複数のstepがある。CI用とCD用でworkflowを分けることが多い。YAMLは手順を記録する形式であって目的ではない。プロジェクトのruntime、test command、deploy先に合わせて中身を決める。
• 具体例：支援ステータス機能で、ci workflowがtestとbuildを、deploy-staging workflowがECR pushとApp Runner deployを担当する。
• つまずきやすい点：他プロジェクトのworkflowをそのまま貼ると、runtimeやcommandが合わず動かない。プロジェクトに合わせる。
• 関連語：GitHub Actions（第16章）、pipeline（第16章）、CI（第16章）、CD（第16章）
• テキスト本文での登場箇所：第16章「GitHub Actionsは、いつ何を実行するかの記録である」

artifact

• 読み：アーティファクト（artifact）
• 一言で言うと：buildなどで作られ、後の工程で使う成果物。
• くわしく：artifactは、CI/CDの過程で生成される成果物のことで、本章ではbuildしたcontainer imageが代表的なartifactにあたる。一度buildしたartifactをECRへ保存し、App Runnerがそれを使ってデプロイする。追跡できるtagを付けておくと、どのartifactをどの環境へ出したかを結びつけやすい。検証済みのartifactを使うことで、環境ごとに作り直さずに済む。
• 具体例：支援ステータス機能でbuildしたimage（artifact）に commit SHA のtagを付けてECRへ保存し、stagingとproductionで同じimageを使う。
• つまずきやすい点：環境ごとに別々にbuildし直すと、同じ変更を出しているはずなのに中身がずれることがある。検証済みのartifactを使い回す。
• 関連語：ECR（第16章）、image tag（第16章）、デプロイ（第16章）
• テキスト本文での登場箇所：第16章「標準構成を一つの流れとして見る」

image tag

• 読み：イメージ タグ（image tag）
• 一言で言うと：container imageを区別・追跡するために付ける名前やラベル。
• くわしく：image tagは、ECRに置いたimageを識別するためのラベルである。latest だけに頼ると、どの変更がデプロイされたか分かりにくくなる。commit SHAやrelease tagを使うと、Gitの変更、GitHub Actionsの実行、ECRのimage、App Runnerのdeployを一本につなげられる。release runbookには、今回出したimage tagと直前に動いていたimage tagを残し、rollbackの判断材料にする。
• 具体例：支援ステータス機能のimageに app:<commit SHA> のtagを付け、runbookに今回と前回のtagを記録しておく。
• つまずきやすい点：latest 運用だと、問題発生時にどのimageへ戻すか分からなくなる。追跡できるtagを使う。
• 関連語：ECR（第16章）、rollback（第16章）、runbook（第16章）、artifact（第16章）
• テキスト本文での登場箇所：第16章「ECRは、どのimageを出したかを追う場所である」

staging

• 読み：ステージング（staging）
• 一言で言うと：productionに近い条件で、リリース前に確認するための環境。
• くわしく：stagingは、localより本番に近く、productionより利用者への影響が小さい環境である。staging用のApp Runner service、RDS、secret、domain、logsを用意し、productionへ出す前に動作を確認する。環境を分ける理由は手順を複雑にするためではなく、利用者影響、データ、secret、権限、確認の厳しさが違うからである。
• 具体例：支援ステータス機能の変更をまずstagingへdeployしてsmoke testし、問題なければproductionへ進める。
• つまずきやすい点：stagingとproductionを同じ扱いにすると、確認の重みの違いが失われる。環境ごとに分けて考える。
• 関連語：production（第16章）、smoke test（第16章）、環境変数(env)（第16章）
• テキスト本文での登場箇所：第16章「stagingとproductionを分ける」

production

• 読み：プロダクション（production）
• 一言で言うと：実際の利用者に影響する本番環境。
• くわしく：productionは、実利用者が使う環境なので、デプロイ時の確認がもっとも厳しくなる。デプロイ前に、CI結果、変更内容、DBへの影響、secret変更、rollback候補を確認する。必要ならmanual approvalを入れる。production用のApp Runner service、RDS、secret、domainを用意し、本番DBに練習用データを入れないなど、データ保護も意識する。
• 具体例：支援ステータス機能をproductionへ出すとき、manual approvalを挟み、deploy後にhealth endpointやCloudWatch Logsを確認する。
• つまずきやすい点：stagingで確認していない変更をproductionへ出してしまいやすい。CIとstaging確認を経てから進める。
• 関連語：staging（第16章）、manual approval（第16章）、rollback（第16章）、smoke test（第16章）
• テキスト本文での登場箇所：第16章「stagingとproductionを分ける」

smoke test

• 読み：スモーク テスト（smoke test）
• 一言で言うと：deploy後に基本動作だけを短く確認するテスト。
• くわしく：smoke testは、deploy後に利用者が使える最低限の状態かを早く確かめるためのものである。大きな負荷をかけるテストではない。health endpointが200を返すか、主要画面が表示されるか、DB接続が成功しているか、ログに重大な起動エラーがないかなどを見る。smoke testで失敗したら、productionへ進めない。productionで失敗したら、rollbackなどの対応を判断する。
• 具体例：支援ステータス機能のdeploy後に、health endpoint、担当受講者一覧、支援ステータス更新APIが動くか、DB接続が成功しているかを確認する。
• つまずきやすい点：deploy成功＝動作確認済みと思いがち。smoke testで実際の動きを見るまで安心しない。
• 関連語：デプロイ（第16章）、CloudWatch Logs（第16章）、rollback（第16章）、runbook（第16章）
• テキスト本文での登場箇所：第16章「smoke testは、deploy後の最低限確認である」

manual approval

• 読み：マニュアル アプルーバル（manual approval／手動承認）
• 一言で言うと：自動の流れの途中で、人が確認して承認してから先へ進める仕組み。
• くわしく：manual approvalは、productionへのデプロイのように影響が大きい工程の前に、人の判断を挟むためのものである。GitHub Actions environmentsのrequired reviewersのような仕組みで実現できる。CIやstaging確認が済んでいても、最終的に出してよいかを人が確認する余地を残す。productionに使うroleやenvironmentに強い制約を置くことと合わせて使う。
• 具体例：支援ステータス機能のproduction deploy workflowにmanual approvalを設定し、承認者が確認してから本番反映する。
• つまずきやすい点：すべてに承認を挟むと流れが滞る。影響の大きいproductionなど必要な箇所に絞る。
• 関連語：production（第16章）、IAM role（第16章）、CD（第16章）
• テキスト本文での登場箇所：第16章「stagingとproductionを分ける」

rollback

• 読み：ロールバック（rollback）
• 一言で言うと：問題が起きたとき、前の正常な状態へ戻すこと。
• くわしく：rollbackは、デプロイで問題が起きたとき前のimageや状態へ戻す対応である。ただし、すべての変更が簡単に戻せるわけではない。アプリのimageだけなら前のtagへ戻せることがあるが、DB migrationが絡むと戻しにくい。データ変換を伴う変更では、戻すより前進して直すroll forwardのほうが現実的なこともある。release runbookに、今回と直前のimage tag、migrationの有無、戻せない変更を事前に書いておく。
• 具体例：支援ステータス機能のproductionで不具合が出たとき、runbookに記録した previous image tag へ戻すか、roll forwardするかを判断する。
• つまずきやすい点：失敗してから「どれが前のimageか」を探すと遅い。出す前に戻し方の候補を書いておく。
• 関連語：image tag（第16章）、runbook（第16章）、smoke test（第16章）、production（第16章）
• テキスト本文での登場箇所：第16章「rollbackは、失敗してから考えると遅い」

runbook

• 読み：ランブック（runbook）
• 一言で言うと：デプロイや問題対応の手順を、出す前にまとめておく文書。
• くわしく：runbookは、deploy前、deploy中、deploy後、問題時、cleanupの手順をまとめた文書である。今回のimage tag、直前のimage tag、migrationの有無、secret変更の有無、rollbackできる範囲、戻せない変更、問題時の連絡先などを書く。問題が起きてから慌てて作るものではなく、出す前に作ることで、何を確認してから進めるかが明確になる。
• 具体例：支援ステータス機能のrelease runbookに、deploy前チェック、smoke test項目、rollback候補、cleanup対象を書いてから本番デプロイに臨む。
• つまずきやすい点：実行できなかった手順を実行済みのように書いてしまわない。未実行・想定手順・確認が必要なことを分ける。
• 関連語：rollback（第16章）、smoke test（第16章）、cleanup（第16章）、image tag（第16章）
• テキスト本文での登場箇所：第16章「rollbackは、失敗してから考えると遅い」

cleanup

• 読み：クリーンアップ（cleanup）
• 一言で言うと：使い終わったクラウドリソースを削除して、費用やリスクを残さないこと。
• くわしく：クラウドでは、作る責任と消す責任がセットである。RDS、App Runner、ECR、CloudWatch Logs、data transferなどは費用が発生することがある。検証用リソースを放置すると、費用やセキュリティリスクが残る。研修では、リソース名、tag、終了時刻、削除担当、削除対象を決める。作成前に、account、region、費用見込み、終了後のcleanupを確認する。講師から環境・予算・削除手順が示されていない場合は、実リソースを作らない。
• 具体例：支援ステータス機能の検証用App RunnerとRDSを使い終わったら、runbookのcleanup欄に従って削除し、削除確認まで記録する。
• つまずきやすい点：作ったまま放置して費用が積み上がりやすい。終了時刻と削除担当を最初に決めておく。
• 関連語：runbook（第16章）、AWS account（第16章）、region（第16章）
• テキスト本文での登場箇所：第16章「costとcleanupは、クラウド作業の一部である」

trust policy

• 読み：トラスト ポリシー（trust policy）
• 一言で言うと：そのIAM roleを誰が借りてよいかを定義するルール。
• くわしく：trust policyは、IAM roleを引き受けられる対象を絞るための設定である。OIDCでAWSへ接続するとき、AWS側はGitHubのOIDC providerを信頼し、特定のrepository、branch、environmentなどに限ってroleを引き受けられるようにする。誰でも借りられるroleにしてはいけない。trust policy（誰が借りてよいか）とIAM policy（何をしてよいか）を分けて考える。production用roleには、staging用より強い制約を置くことがある。
• 具体例：支援ステータス機能のdeploy用roleのtrust policyで、対象を自分のリポジトリのmain branchに限定し、他リポジトリから借りられないようにする。
• つまずきやすい点：IAM policy（権限）ばかり気にしてtrust policy（誰が借りるか）の絞り込みを忘れがち。両方を絞る。
• 関連語：IAM role（第16章）、OIDC（第16章）、least privilege（第16章）、IAM（第16章）
• テキスト本文での登場箇所：第16章「OIDCで、長期access keyを置かない」

roll forward

• 読み：ロールフォワード（roll forward）
• 一言で言うと：問題が起きたとき、前の版へ戻すのではなく、新しい修正を前進デプロイして直すこと。
• くわしく：rollbackが「前の正常な版へ戻す」のに対し、roll forwardは「直した新しい版を出す」。DBのmigrationやデータ変換を伴う変更では、単純に前へ戻すとデータの整合が取れないことがあり、roll forwardのほうが現実的な場合がある。どちらで対応するかは、変更の性質と戻しやすさで判断する。
• 具体例：支援ステータスのカラム追加とデータ移行を含むリリースで不具合が出たら、スキーマを巻き戻すより、修正を当てた新しい版を前進デプロイするほうが安全なことがある。
• つまずきやすい点：rollbackが常に最善だと思い込む。データ構造が変わった後は、前進して直すほうが安全な場合がある。
• 関連語：rollback（第16章）、image tag（第16章）、runbook（第16章）
• テキスト本文での登場箇所：第16章「rollbackは、失敗してから考えると遅い」

feature flag / feature toggle

• 読み：フィーチャーフラグ／フィーチャートグル（feature flag / feature toggle）
• 一言で言うと：機能の有効・無効を、コードを出し直さずに設定で切り替えられる仕組み。
• くわしく：新機能をフラグの裏に置いておくと、デプロイと公開を分けられる。問題が起きたら、その機能だけをオフにして影響を止められる（feature off）。本番障害時の対応として、rollbackやroll forwardと並ぶ選択肢になる。段階的な公開や、一部の利用者だけへの公開にも使える。
• 具体例：支援ステータスの新しい絞り込みをフラグの裏で出し、問題が出たらフラグをオフにして、リリース全体を戻さずに該当機能だけ止める。
• つまずきやすい点：フラグを増やしたまま消し忘れると、分岐が積み重なって複雑になる。役目を終えたフラグは片付ける。
• 関連語：rollback（第16章）、smoke test（第16章）、staging（第16章）
• テキスト本文での登場箇所：第16章「rollbackは、失敗してから考えると遅い」「smoke testは、deploy後の最低限確認である」