applyを誰が実行するかの設計 — 手元で流すかCIに寄せるか

Terraformなどインフラコードにおける「applyを誰が実行するか」という設計判断は、変更追跡・権限管理・緊急対応の設計と直結する。手元実行のまま本番を抱え続けると変更者の特定が困難になり、CIに全振りすると緊急時の対応が行き詰まる。環境数・チーム規模・リスク許容度を軸に、実行主体の設計判断を整理する。

各自の手元applyで誰の変更か追えなくなる構造

「最後にapplyしたのは誰か」が追えなくなる問題

チームで複数人が手元のマシンからapplyを実行する環境では、ステートファイルだけがリモートに残り、どの担当者がいつ何を変更したかの文脈が失われる。Gitにコードのコミット履歴があっても、どのブランチのコードで誰がapplyを実行したかのトレースがない状態では、後からインシデントが発生したとき原因の特定が困難になる。5人チームで本番環境を3系統抱えていたあるプロジェクトでは、ステートファイルの内容と実コードが乖離した状態が2週間気づかれなかったという事例がある。この問題の本質は「applyの実行がチームの誰も把握できない形で行われる」設計になっていることにある。

ステートファイルの競合が設計の問題を可視化する

複数人がほぼ同時にapplyを実行すると、リモートステートのロック機構が機能していないケースでは変更の上書きが起きる。ロック機構があっても「誰が実行中か」の情報はターミナル画面にしか表示されないため、Slackでの声がけやタイミング調整という人的コミュニケーションに依存した運用になりやすい。これは技術的な不具合というよりも、「実行の主体をツールに委ねず人の判断に任せている」という設計上の意思決定が生む構造であり、チームが大きくなるほど顕在化する問題だ。

変更履歴が3か所に分断される問題

applyの実行ログ・Gitのコミット履歴・ステートの変更履歴が別々の場所に散在する状態では、変更を追うために複数のシステムを横断する調査が必要になる。環境数が10を超えてくると、この横断調査は現実的でない工数に膨らむ。「誰がどの環境にどのコードをapplyしたか」が単一の経路から確認できない設計は、監査対応や障害調査の場面で設計上の負債として顕在化する。実行経路を絞り込み、ログが自動的に集約される仕組みを持つことが、変更追跡を担保する基本的な判断軸になる。

手元実行を残してよい場面とCIへ寄せるべき場面

手元実行が有効な開発・検証フェーズの条件

新しいモジュールの試作や、独立したdev・sandbox環境での実験は、手元実行の方が反復速度が高まる場面がある。ただし「手元実行が許容されるのはステートが他の環境と共有されていない独立環境に限る」という線引きを組織として合意しておくことが前提になる。本番のステートを参照するdev環境であれば、すでに「共有ステートに手元からapplyする」構造になっており、同じ追跡不能の問題が生じる。この許容範囲はルールとして文書化するだけでなく、権限設計として実装することが重要だ。

本番・ステージング環境でCIに寄せるべき判断基準

本番・ステージング環境では「誰でもapplyできる状態」をデフォルトにしておくべきではない。実行経路をCIに集約すると、applyの実行がパイプラインのログと一対一で対応するようになり、誰が・いつ・どのブランチのコードで実行したかが自動的に記録される。20台以上のインスタンスで構成されるサービス基盤を複数環境抱えているチームでは、CI実行への移行後に変更追跡のコストが大幅に削減されたという現場報告が複数存在する。変更頻度が週3回以上ある本番環境では、CIへの移行を先に設計しておくことが合理的な判断になる。

移行期に設計すべき実行許可の境界

手元実行からCI実行への移行期は、両方のルートが並存する最も危険なフェーズだ。この時期に設計すべきなのは「誰が・どの環境に・どのルートでapplyできるか」の境界を、ドキュメントではなくIAMの権限設定とCIの構成で実装することだ。ドキュメントに書いた運用ルールは時間とともに形骸化する。手元からのapplyが物理的にできない権限設計になって初めて「CIに寄せた」と言える状態になる。移行期にこの実装を先送りにしていると、移行が名目上だけの状態になりやすい。

手元apply・CI実行・マネージド実行基盤の比較

3つの実行パターンの特性を整理する

apply実行の主体としては、大きく3つのパターンがある。担当者が手元で実行する「手元apply」、GitHub ActionsやCircleCIなど自前のCIパイプラインで実行する「CI実行」、Terraform CloudやAtlantisなど実行基盤を持つ「マネージド実行基盤」だ。それぞれ変更追跡のしやすさ・権限管理のコスト・緊急対応の柔軟性が異なる。チームの規模・環境数・監査要件を軸に選択することになる。

比較軸	手元apply	CI実行（自前）	マネージド実行基盤
変更追跡	△ 担当者のログに依存	○ パイプラインログに集約	◎ 実行履歴・planログを一元管理
権限管理	× 人のアカウントに権限が必要	○ サービスアカウントに集約可能	◎ 実行基盤側で制御・監査ログ付き
初期構築コスト	◎ ほぼゼロ	○ 中程度（CI設定・権限設計）	△ 学習・移行・ライセンスコストを要する
緊急対応	◎ 手元で即実行可能	△ パイプライン経由が必須	△ 実行基盤が稼働している前提
チーム規模の目安	1〜3人・検証環境のみ	3〜20人・複数環境	10人以上・本番多数・監査要件あり
監査対応	× 手動でのログ収集が必要	○ CIログを監査証跡として活用可	◎ 監査向けレポート機能を備える

環境数とチーム成熟度で選択する

環境数が少なく変更頻度も低い段階では、CIへの移行コストがメリットを上回ることがある。一方、環境数が10を超え始めると手元実行の管理コストは増大するため、早い段階で移行設計を決めておくことが重要になる。CI実行の設計には「どのブランチへのマージでapplyを実行するか」「planとapplyをどのジョブで分けるか」の決定が含まれ、これらは構成を決めた後から変更しにくい。初期設計に時間をかける価値がある判断領域だ。

実行用の権限をどう持たせ、人からどう剥がすか

CI専用サービスアカウントに権限を集約する設計

権限設計の基本は「applyに必要な権限を持つアイデンティティをCI専用のサービスアカウントに限定する」ことだ。人のアカウントに本番へのapply権限を残したまま運用すると、退職や異動のタイミングで権限剥奪が漏れるリスクが生まれる。認証情報が外部に漏洩したときの影響範囲も広がる。CI専用のサービスアカウントであれば、影響範囲がそのパイプラインに限定され、ローテーションや無効化も人のアカウントより容易に対応できる。

人の権限を段階的に剥がす移行設計

人からapply権限を剥がす作業は「一気に全員から剥がす」よりも「環境ごとに段階的に移行する」アプローチが現実的だ。まずstaging環境での手元applyを権限レベルで不可にして運用を検証し、問題がなければproductionへと移行する順序が安全に進められる。ただしこの移行を進める前に、緊急時の例外経路を先に設計しておかないと、インシデント発生時に誰も対応できない状態が生まれる。例外経路の設計なしに権限剥奪を先行させることが、現場でよく見られる落とし穴だ。

最小権限の粒度をどう定義するか

CI用サービスアカウントの権限設計では、最小権限の原則を守ることが前提になるが、「必要な権限」の粒度の判断が難しい。Terraformのapplyが操作するリソースは構成によって広範囲になりうるため、権限を絞りすぎると実行が失敗し、広げすぎると漏洩時のリスクが高まる。設計上の基本方針として、環境ごとに独立したサービスアカウントを用意し、staging用のアカウントがproductionリソースに触れない構成にすることで、環境間での権限の横断を防ぐ。

planの確認と承認をパイプラインのどこに置くか

planを人が確認するゲートをパイプラインに設ける

CI実行に移行すると「自動で実行される」利便性が高まる一方、planの結果を人が確認する機会が失われやすい。破壊的な変更（deleteやreplaceを含むplan）を見逃したままapplyが走るリスクを防ぐには、planの出力を人が確認・承認するゲートをパイプラインに組み込む必要がある。このゲートはPRへのplan自動投稿と、承認されたPRのみがapplyジョブに進む構成として実装されることが多い。ゲートの位置をパイプライン設計の初期段階で決めておくことが、後からの設計変更を減らすポイントになる。

PRレビューとplan承認を統合する設計

コードレビューとplanの確認を同一のPRフローで完結させる設計は、レビューコストを最小化しながら変更内容の透明性を確保できる。ただし「PRが承認されたこと」と「planの内容を理解して承認したこと」は別物だ。レビュアーがplanの出力を確認せず、コードだけを見て承認するケースは現場で珍しくない。この問題を減らすには、planの出力にadded/changed/destroyedのリソース数をサマリとして強調し、破壊的変更が含まれる場合はボットで警告を追加するなど、承認者が気づく設計上の工夫が必要になる。

自動承認が許容される条件と禁止すべきパターン

変更が限定的かつ冪等であることが保証されているケース（特定のタグ更新のみ、非破壊変更のみなど）では、自動承認をパイプラインに組み込む設計もある。しかし「今回は安全な変更だから自動承認して問題なかった」という判断が積み重なると、やがて破壊的な変更も同じルートに乗るリスクが生まれる。自動承認は「承認不要と判断できる変更のパターンを事前に明文化し、それ以外はすべて人承認を要求する」という設計にすることで、例外の範囲が広がることを構成レベルで抑止できる。

CIに寄せきって緊急対応が回らなくなる境界

パイプラインが詰まるシナリオを事前に特定する

CIに実行を集約すると、パイプラインそのものが停止しているときや、承認ゲートの担当者がアクセスできない深夜・休日に緊急の変更が必要になるシナリオで対応が行き詰まる。また、CIのキューが大量のジョブで埋まっている状況で緊急のロールバック用applyを実行しようとしても、先着のジョブが完了するまで待つ構成になっていると、実質的に対応不能になる場合がある。このようなシナリオをあらかじめ特定し、設計に反映しておくことがCIへの移行で見落とされやすいポイントだ。

緊急実行の例外経路（Break-glass）を先に設計する

緊急時に担当者が手元からapplyを実行できる例外経路を設計に組み込んでおく必要がある。この経路は通常はロックされており、使用するためには「特定の承認プロセスを経る」か「使用後に自動でアラートが通知される」仕組みとセットにして設計する。例外経路の存在を秘匿するのではなく、「緊急時にはこの経路を使い、使用後はログを残したうえでCIとの整合を取る」という手順を明文化することで、乱用を設計的に抑止できる。この経路を事後に急造すると、権限設計が崩れる起点になりやすい。

緊急実行後の後処理フローを設計に含める

緊急対応で手元からapplyを実行した後、その変更内容をCIパイプラインと整合させる後処理フローを設計に含めておかないと、次のパイプライン実行で予期しない差分が生まれる。緊急実行した内容がステートには存在するがコードに反映されていない状態が続くと、次回のplanで余計な差分が表示され、担当者が混乱する事態になる。設計として「緊急実行の内容をコードに反映したPRを24時間以内に作成・マージする」という手順を規定しておくことで、緊急対応がCIフローの外に取り残されることを防ぐ。

apply実行設計チェックリスト

以下は、apply実行の設計を整理するための判断軸として活用できるチェックリストだ。手元実行からCI実行への移行時、または新規プロジェクトの基盤設計時に確認する。手を動かす操作の詳細は各ツールのドキュメントや実践の場で確認し、ここでは設計判断の漏れがないかの確認に使うとよい。

1. apply実行の主体（人・CI・マネージド基盤）を環境ごとに明示的に決定しているか
2. 手元applyが許容される環境と許容されない環境を、ドキュメントではなく権限設計として実装しているか
3. CI用のサービスアカウントを環境ごとに分離しているか。staging用が本番リソースに触れる権限を持っていないか
4. 人のアカウントから本番apply権限を剥奪するスケジュールを設計に含めているか
5. planの出力を人が確認するゲートをパイプラインに設けているか
6. 破壊的変更（destroy・replace）を含むplanに対して明示的な警告または別承認フローを設けているか
7. 緊急時の例外経路（Break-glass）を事前に設計しているか。使用後のアラート通知と後処理フローが定義されているか
8. パイプラインが停止した際の緊急対応手順をチームで共有・訓練しているか
9. 緊急実行後にCIと整合させる後処理フロー（コードへの反映・PR作成）の期限と担当を定めているか
10. 実行ログ・ステート変更履歴・Gitコミット履歴を横断せず、単一の経路から変更を追跡できる設計になっているか