AWSアカウント削除業務の改善施策で考えたこと - 局所最適にしない進め方と「隔離してから消す」削除用Organizations分離方式
どうも！オペ部の西村祐二です！
クラスメソッドでは、AWS総合支援サービスの一環として多数のAWSアカウントを管理しています。
アカウントの発行だけでなく、解約に伴う削除も日々発生する定常業務です。
アカウント管理業務の中でも、「AWSアカウントの削除」はとくに気が重い部類だと思います。操作は不可逆で、間違えれば顧客の環境が消えるため、人がダブルチェックを重ねながら慎重に手作業で進める形で長く運用されてきました。
一方で、管理するアカウント数の増加に伴って削除の件数は増え続けていました。機微な作業のため外部委託も難しく、他業務と兼任する少数のコアメンバーが手動で対応する体制では、リードタイムの長期化や顧客の希望日に応えられないといった課題がありました。
そこで、このAWSアカウント削除業務の自動化・効率化を主導し、条件を満たす一部のアカウントを対象に、受付から削除の実行まで人手をほぼ介さないフローを構築して運用を開始しました。この記事では、進めるうえで考えていたことと、不可逆な削除を安全に自動実行するためのアーキテクチャ（削除用Organizations分離方式）を共有します。
削除業務は「人の慎重さ」で成り立っていた
改善前の削除業務は、複数のチームをまたぐ手作業のリレーでした。
顧客からの解約申請
│
▼
アシスタント
- 申請内容の受付
- 手動事前チェック（リソース確認、契約状態、申請内容の確認など）
│
▼ 作業依頼
アカウントチーム
- 削除可否の確認（削除スケジュール調整など）
- ダブルチェックでOrganizationsの操作、アカウント閉鎖、内部システム解約処理
- 作業記録、完了報告
│
▼
完了
このフローの特徴は、品質のほとんどを「人が間違えないように気をつけること」で担保している点です。チェック項目は多く、1件ごとに人手の確認が入り、チーム間の依頼と受け渡しでは待ち時間が生まれます。そして削除は取り返しのつかない操作なので、実行する担当者には毎回それなりの緊張感がかかります。
最初にやったのは、コードを書くことではなく業務を並べること
この取り組みは、はじめは自分の所属部署が担当するアカウントチーム側の作業だけを効率化する話でした。改善というと、つい手近な範囲を対象に、ツールの実装から入りたくなります。しかし最初にやったのは業務フローの棚卸しでした。担当範囲に閉じず、アシスタントの受付からアカウントチームの削除実行・記録まで、「誰が何を確認し、どこで待ちが発生しているか」を通しで書き出しました。アシスタントが使っている作業手順のテンプレートも見せてもらい、チェック項目を1つずつ確認しました。
並べてみて分かったことが2つあります。
1つ目は、アカウントチームの作業だけを自動化しても、効率化を最大化できないということです。仮にそこだけ自動化しても、作業依頼を受けてアカウントチームの誰かがツールを起動し、対象を入力する、といった運用になります。作業がツール操作に置き換わるだけで、アカウントチームの作業はゼロになりません。そして削除業務は2チームにまたがるリレーなので、1区間だけ速くしても前後の手作業と受け渡し待ちはそのまま残ります。逆に受付側だけを効率化しても、後段の削除作業で詰まります。局所最適では、効果は限定的です。
2つ目は、人手のチェック項目の中に、システムなら即座に判定できるものが含まれていたことです。重複申請の有無、契約状態、対象アカウントの構成といった確認は、データを参照すれば機械的に答えが出ます。
そこで当初の予定から範囲を広げ、改善の単位を「チームの作業」ではなく「業務の流れ全体」に取り直して、部署の異なるアシスタント側の業務も含めて受付から削除完了までを1本のパイプラインとして設計しました。
- 申請チケットが起票されると、システムが自動処理できる案件かどうかをチェックし、結果をチケットにコメントする
- アシスタントは従来どおり事前チェックを行い、問題なければチケット上で削除予約を登録する
- 予約された案件は、アカウントチームを介さずスケジュールに沿って削除まで自動で進む
一気に切り替えない。「自動レーン」を1本増やす
新しい仕組みができたとき、既存フローを一斉に置き換える判断もあり得ますが、その方式は選びませんでした。切り替え直後こそ想定外が起きやすく、その影響はイレギュラー案件の扱い、切り戻し手順の習熟、新旧フローが混在する期間の混乱といった形で、システムではなく現場のオペレーションに現れるからです。こうしたコストは設計書には載りませんが、現場が確実に払うことになります。
代わりに、既存フローの横に「自動レーン」を1本増やす形にしました。
- 申請の入口（チケット運用）は変えない。アシスタントの操作追加は、チェックボックスの確認と予約登録だけに抑える
- 申請フォームの構成や「削除日は申請から一定期間後」といった既存の仕様もそのまま維持する。顧客から見ると従来の手動対応とほとんど違いがないため、切り替えに伴う混乱が起きにくい
- システムが案件ごとに自動処理の可否を判定し、可能な案件だけを自動レーンに流す。条件を満たさない案件は、これまでどおり手動フローで処理する
- 対象は構成がシンプルで影響範囲の小さいアカウントに絞って開始する。環境の構成が複雑なアカウントは、Organizations間の移動や SCP の適用が失敗するリスクがあるため初期対象から外す。管理アカウントや大量の一括削除といったイレギュラーも同様に対象外とする
この設計でとくに気をつけたのが、分岐を業務フローの途中に持ち込まないことです。段階的な自動化では、「このパターンは自動化できない」「これは特殊対応が必要」というケースが必ず残ります。これを手順書の途中の分岐として表現すると、現場は案件ごとに「ここから先は自動か、手動か」を判断しながら進むことになり、かえって負荷が上がります。実際、過去に別の仕組みで「手順書が複雑になるから利用をやめたい」と言われたことがあります。自動化しても、現場の手順を複雑にしてしまっては使ってもらえません。
そこで、分岐は入口の1箇所に集約しました。起票時点で自動レーンに乗った案件は最後まで自動、乗らない案件は最初から最後まで従来どおりで、途中での分岐や合流はありません。現場から見れば、手順書は「従来どおりの1本」と「チェックして予約するだけの1本」が並んでいるだけです。
ただし、どの案件がどこで特殊対応になるのかは、入口から出口までの運用を把握して初めて書ける条件です。最初の業務全体の棚卸しが重要になってきます。
この形なら、自動化システムに想定外の事態があっても、その案件を自動レーンから外して従来フローで対応するだけで、業務全体は止まりません。第1段階を安定運用できたら、手動対応との併存の解消、対象範囲の拡大、リードタイムの短縮へと1段ずつ進める計画です。あわせて効果測定用の計測シートに自動処理できた件数とできなかった理由を記録し、次にどの条件を自動化対象に加えるかを判断できるようにしています。
どうすれば安全にアカウントを削除できるか
自動化の設計で最後まで悩んだのが、アカウントを安全に削除する仕組みです。削除を自動化するには、システムに削除という強い権限を持たせる必要があります。顧客のアカウントが並ぶ既存のOrganizationsの構成にその権限を付けると、ツールのバグや誤操作がそのまま顧客環境へのリスクになります。
かといって、実行の直前に人の確認を挟む半自動の形にも課題があります。システムが処理を組み立て、最後は人が目視で確認してからボタンを押す。安心できそうに見えますが、これは人の注意力を安全装置にしているだけで、最後の確認が残る限り、人の作業時間も見落としの可能性もなくなりません。それに「最後に人が見るから大丈夫」という前提で作ると、システム側の安全設計も甘くなりがちです。
考えた末、人の注意力ではなく仕組みで安全を担保し、人はなるべく介入しない方針にしました。対象のアカウントIDなどの情報は、申請されたチケットをシステムが直接見に行く設計にして、人が転記・入力する場面をなくします。そのうえで削除の工程は、人が見ていなくても安全に動くことを設計の条件にしました。これをどう実現するか。その答えが、次の削除用Organizations分離方式です。
隔離してから消す: 削除用Organizations分離方式
AWSアカウントの閉鎖は CloseAccount API で実行できます。素直に考えると、アカウントが所属している既存の AWS Organizations の管理アカウントに閉鎖の権限を付与する方式になりますが、前述のとおりこの方式では、バグや誤操作が起きたときにOrganizations配下のすべてのアカウントが削除対象になり得ます。「本番のアカウントが並んでいる場所で、削除の権限を持ったツールを動かす」こと自体がリスクの源です。
そこで発想を変え、削除専用のOrganizations（削除用Org）を用意し、消すアカウントをそこへ隔離してから閉鎖する方式にしました。
削除予定日の当日までアカウントには一切手を触れず、当日になってから削除用Orgへ移動させる設計にしています。
2段階で消す: 論理削除と物理削除
削除は一発では実行せず、2段階に分けています。
- 論理削除: 削除対象アカウントを削除用Orgへ転送し、「削除待ちOU」（OUはアカウントをまとめる組織単位）へ移動する。このOUにはほとんどの操作を拒否するSCPを適用しており、アカウントは実質的に利用できない状態になる。ただしアカウント自体は残っているため、この猶予期間中であれば元に戻せる
- 物理削除: 猶予期間の経過後、スケジュール実行で「閉鎖済みOU」へ移動し、CloseAccountを実行する
不可逆な閉鎖の手前に、キャンセル可能な状態を1段挟む設計です。誤申請だと分かった場合、削除予定日の前ならスケジュールの登録を解除するだけで済みます。予定日当日でも、論理削除の猶予中なら元のOrganizationsへ戻すだけです。さらに AWSの仕様 として、閉鎖後も90日以内であればアカウントを復旧できます。取り消しの手段を三重に用意した形です。
安全性は権限の分離で担保する
この方式では、閉鎖を実行できる権限は削除用Orgの中にしか存在しません。
自動化ツールがバグで暴走し、誤ったアカウントIDに削除命令を出したとしても、命令が届く範囲は削除用Orgの中、つまり「削除のために隔離されたアカウント」だけです。既存のOrganizations側のアカウントを直接閉鎖することはできません。IAMポリシーの条件で絞り込むような論理的な制御ではなく、閉鎖の権限そのものが別のOrganizationsに分離されているためです。
このほか、閉鎖の実行前には、チケット情報と対象アカウントの突合や削除予定タグの確認といったチェックを挟み、結果を社内チャットに通知しています。権限の分離という土台の上に、実行前チェックを重ねる構成です。
「人がしっかり確認する」よりも「間違えても被害が出ない場所でしか動けない」ほうが確実です。人の介入を最小限にする判断は、この構造があって初めてできました。
追い風になった直接転送アップデート
この方式は、2025年11月の AWS Organizationsの組織間直接転送のアップデート で現実的になりました。
従来、Organizations間でアカウントを移動するには、一度組織から離脱してスタンドアロンアカウントにする必要がありました。その際には、支払い方法・連絡先情報・サポートプランの再設定も発生します。このアップデートにより、スタンドアロン状態を経由せず「招待→承諾」だけで直接転送できるようになり、アカウントを削除用Orgへ移動するステップをAPIだけで自動化できます。転送前後でガバナンス機能と一括請求も維持されます。
クォータも設計に織り込む
AWS Organizationsには、30日以内に閉鎖できるメンバーアカウント数のクォータがあります。
| 組織内のメンバーアカウント数 | 30日以内に閉鎖できる上限 |
|---|---|
| 1,250未満 | 最大250アカウント |
| 1,250〜5,000 | メンバーアカウントの20% |
| 5,000超 | 最大1,000アカウント |
このクォータにも追い風がありました。方式の検討時点では、小規模なOrganizationsで30日以内に閉鎖できるのは最大10アカウントという厳しい制限があり、削除用Orgを複数用意して分散する設計はこれを前提にしたものでした。その後、上限は最大250アカウントまで緩和され、単一の削除用Orgでも処理量に余裕を持てるようになっています。
このクォータはOrganizations単位で適用されるため、既存のOrganizationsの中で削除する方式では、他の運用と閉鎖枠を共有することになります。削除用Orgを分離しておけば、閉鎖枠を削除業務専用に確保できます。さらに削除用Orgを複数用意すれば、Org単位のクォータを分散して処理能力を増やせます。
なお、削除用Orgには「組織の最大アカウント数」のクォータ（こちらは引き上げ申請が可能）も別途かかります。閉鎖したアカウントは、完全閉鎖（閉鎖から最大90日後）までこのアカウント数にカウントされ続けます。そのため、削除ペースに応じて最大アカウント数のクォータを事前に引き上げておく必要があります。
既存Org内で削除する方式との比較
| 比較項目 | 既存Org内で削除する方式 | 削除用Org分離方式 |
|---|---|---|
| バグ・誤操作の影響範囲 | Org配下の全アカウントに及び得る | 隔離済みアカウントのみ |
| 既存環境への変更 | 削除権限の追加とSCP設計の見直しが必要 | 変更は最小（転送の操作のみ） |
| SCP設計 | 既存のSCP設計との兼ね合いを考慮 | 削除専用Orgなので拒否SCPを安全に適用可能 |
| 削除クォータ | 既存Orgのクォータを他の運用と共有 | 削除専用に確保でき、複数Orgで分散も可能 |
| 監査ログ | 既存Orgのログに削除操作が混在 | 削除用Orgに集約 |
結果: 「気をつける」作業がなくなった
この仕組みと進め方で運用を開始した結果、自動処理できる案件のフローは次のようになりました。
顧客からの解約申請
│
▼
アシスタント
- 申請内容の受付
- システムが自動チェックした結果を確認
- チケット上で削除予約を登録（削除日はシステムが自動算出）
│
▼ 作業依頼・受け渡しなし
自動化システム
- 削除予定日に削除用Orgへ隔離（論理削除）
- アカウント閉鎖、内部システムの解約処理
- 作業記録、完了報告
│
▼
完了
アカウントチームへの作業依頼はなくなり、人が担うのは受付とチェック結果の確認、予約登録だけです。以降は受け渡しなしでシステムが削除から完了報告までを自動で行います。効果をまとめると次のとおりです。
- アカウントチーム側は、1件あたり十数分かかっていた確認・削除・記録の作業がほぼなくなり、月間では数十時間規模の工数が浮いた
- アシスタント側は、チケット上の操作だけで削除予約まで完結するようになった
- チーム間の受け渡し待ちが消え、自動処理できる案件では顧客の希望日どおりに削除を実行できるようになった
- 不可逆な操作を人が実行する場面そのものがなくなった
とくに最後の1つには、時間の削減とは別の価値があります。「絶対に間違えられない作業」が業務から消えると、担当者は緊張を伴う確認から解放されます。対象範囲は、今後も段階的に拡大していく予定です。
まとめ
AWSアカウント削除業務の自動化を通じて意識した進め方は、次の3つです。
- 局所最適にしない: 1チームの作業ではなく、業務の流れがつながる範囲全体を把握してから改善対象を決める
- 一気に切り替えない: 既存フローの横に自動レーンを増やし、自動処理できる案件から流して範囲を段階的に広げる。分岐は手順の途中ではなく入口に集約する
- 人が介入する前提にしない: 人の注意力を安全装置にせず、アーキテクチャで安全性を担保する
あわせて感じたのは、AIの効果です。コードの実装はもちろんですが、担当外業務の調査やキャッチアップ、改善の仕組みの構築といった実装以外の部分こそ大きく高速化できました。「業務全体を把握してから手を入れる」という時間のかかる進め方を現実的にできたのは、AIの存在が大きかったと思います。
不可逆な操作の自動化ほど、「人が確認するから安全」ではなく「人が確認しなくても安全」を設計する価値があると感じています。
誰かの参考になれば幸いです。
参考リンク:
