3行まとめ
対象。
検証。
記録。
戻す。
一括操作は、実行ボタンより前の確認で安全性が決まります。
- Codexに管理画面の一括操作を任せる時は、対象選択、preview、dry-run、confirmation、上限、権限、audit log、undoを先に決めます。
- bulk update/deleteは、1回のクリックで広い影響が出ます。対象件数、サンプル、差分、実行者、理由、戻し方をUIとlogに残します。
- 途中失敗や二重実行に備え、operation ID、idempotency、status、retry、skip済み対象を設計してから実装します。
管理画面の一括操作は、とても便利です。ユーザーを一括停止する。記事をまとめて公開する。タグを付け替える。古いデータをarchiveする。CSVで対象を選ぶ。Codexに頼めば、checkbox、bulk action、API、jobはすぐ作れます。
ただ、一括操作は事故の影響も大きいです。対象filterを間違える。件数を見ずに実行する。二重に押す。途中で失敗する。誰が実行したか分からない。戻せない。こうなると、UIとしては動いていても運用では怖い機能になります。
この記事では、Codexに管理画面の一括操作を任せる前に決めることを整理します。運用手順全体は公開済みのCodexに運用手順を任せる前に決めることで扱いました。ここでは、管理画面やadmin APIのbulk operationへ絞ります。
この記事でわかること
範囲。
上限。
承認。
再実行。
bulk operationは、対象、回数、責任者、戻し方を明確にします。
- 一括操作をCodexへ頼む前に決める7項目
- previewとdry-runを分ける理由
- confirmationをただの「OK」ボタンにしない考え方
- idempotencyとoperation statusで二重実行を防ぐ方法
- audit logに残すべき項目
- undoできる操作とrollbackが必要な操作の分け方
- Codexへそのまま渡せる依頼packet
- reviewで止めるべきbulk operation差分
この記事は、破壊的操作を自動化するための記事ではありません。誤操作を減らすための設計整理です。Kubernetesのdry-runでは、API serverに検証させつつ永続化しない考え方が説明されています。Stripeのidempotency Docsでは、同じ操作を安全にretryする考え方が説明されています。GitHubのaudit log Docsでは、活動を後から確認・exportできる記録として扱う考え方が説明されています。
前提知識
| 項目 | 内容 | 見方 |
|---|---|---|
| Dry-run | 未保存。 | |
| Idempotency | 重複防止。 | |
| Audit | 記録。 | |
| Rollback | 復旧。 |
preview、dry-run、idempotency、audit logはそれぞれ役割が違います。
bulk operationは、UIではなく運用操作です。
見た目はcheckboxとbuttonでも、実際には多くのデータを変えるjobです。対象選択、権限、実行条件、実行履歴、失敗時の再開、undo、通知が必要になります。
bulk operationはUIではなく運用操作
「選択したものを一括で変更する」だけだと、対象が小さい時は動きます。しかし、対象が1万件、複数tenant、権限違い、外部API連携、メール送信を伴う場合は、運用設計が必要です。
dry-runとpreviewを分ける
previewは、ユーザーに対象や差分を見せることです。dry-runは、実行前にserver側で検証し、保存せずに結果を試算することです。どちらも必要ですが、役割は違います。
一括操作前に決める7項目
| 項目 | 内容 | 見方 |
|---|---|---|
| Target | 対象。 | |
| Action | 操作。 | |
| Limit | 上限。 | |
| Preview | 確認。 | |
| Approval | 承認。 | |
| Audit | 記録。 | |
| Undo | 戻し。 |
一括操作は、誰が何に何をするかを実行前に固定します。
Codexへ頼む前に、7項目を決めます。
| 項目 | 決めること | 曖昧なまま起きること |
|---|---|---|
| target | 対象条件と除外条件 | 誤対象を含む |
| action | 何を変えるか | 副作用が混ざる |
| limit | 件数、時間、rate | runawayになる |
| preview | 件数、sample、diff | 見ずに実行する |
| approval | 誰が承認するか | 責任が曖昧 |
| audit | 何を残すか | 後から追えない |
| undo | 戻し方 | 事故後に迷う |
CodexはUIとAPIを作れますが、どの操作を誰が承認すべきか、どの件数から危険か、戻せるかは知りません。
操作を分類する
bulk operationには、軽い操作と重い操作があります。タグ付け、状態変更、メール送信、削除、外部API呼び出し、権限変更では危険度が違います。
上限を持つ
件数上限、1回あたり時間、並列数、対象tenant、操作種類を制限します。上限を超える場合は、別承認やjob化へ回します。
reviewで見ること
reviewでは、対象filter、除外条件、件数表示、preview、dry-run、confirmation、audit log、undo、権限、rate limitを見ます。
対象選択とpreviewを固定する
- 1Filter
絞る。
- 2Count
件数。
- 3Sample
例。
- 4Diff
差分。
- 5Confirm
確認。
対象件数とサンプルを見せるだけで、誤操作をかなり減らせます。
一括操作では、対象がすべてです。
filter条件、選択件数、除外件数、代表sample、変更前後のdiffを見せます。CSV importなら、読み込んだ行数、対象一致数、失敗行、権限外行も出します。
件数を目立たせる
「3件」と「30,000件」では意味が違います。件数はbuttonの近くに出します。一定件数を超えたら追加確認を出します。
sampleを見せる
対象の一部をsample表示します。IDだけではなく、名前、状態、tenant、最終更新、変更後の状態を出します。
注意点
filter変更後にpreviewを再計算せず、古い対象で実行するのは危険です。previewしたoperation IDと実行対象を結びます。
dry-runとconfirmationを入れる
- 1Validate
検証。
- 2Dry-run
試算。
- 3Warn
警告。
- 4Approve
承認。
- 5Execute
実行。
dry-runは保存しない検証、confirmationは人間の実行判断です。
dry-runは、保存せずに検証する処理です。
Kubernetesのdry-runは、API serverにadmissionやvalidationを通しつつ永続化しない仕組みとして説明されています。管理画面でも同じ発想で、実行前にserver側で「何が起きるか」を計算します。
dry-runで見ること
- 対象件数
- 成功予定件数
- 権限不足件数
- validation失敗件数
- 変更前後の差分
- 外部副作用の有無
- 推定時間
confirmationで見ること
confirmationは、人間が実行を承認する画面です。単なる「OK」ではなく、操作名、対象件数、危険度、戻し方、実行者、理由を確認します。
条件
破壊的操作では、対象件数や操作名を入力させる、別ownerの承認を求める、時間帯を制限するなどのgateを入れます。
idempotencyと再実行を設計する
操作ID。
状態。
再試行。
処理済み。
途中失敗後に再実行しても、同じ対象を二重処理しない設計にします。
bulk operationは途中で失敗します。
network timeout、worker restart、外部API rate limit、DB lock、権限変更、ユーザー操作の二重click。これらに備えて、operation IDとstatusを持ちます。
Stripeのidempotency Docsでは、同じkeyでretryしても重複操作を避ける考え方が説明されています。bulk operationでも、同じoperationを再実行した時に二重変更しない設計が必要です。
operation IDを作る
実行ごとにoperation IDを作ります。対象snapshot、実行者、理由、dry-run結果、approval、status、attemptを紐づけます。
対象ごとのstatusを持つ
全体statusだけでなく、対象ごとのstatusを持ちます。pending、done、skipped、failed、rolled_backのように分けます。
評価基準
同じbuttonを2回押しても、途中失敗後にresumeしても、処理済み対象が二重に変わらないなら良い設計です。
audit logと権限を残す
| 項目 | 内容 | 見方 |
|---|---|---|
| Actor | 実行者。 | |
| Target | 対象。 | |
| Before | 前。 | |
| After | 後。 | |
| Reason | 理由。 |
audit logがあると、実行後に何が起きたかを説明できます。
一括操作ではaudit logが必要です。
GitHubのaudit log Docsでは、actor、action、created_atなどの活動記録をexportできることが説明されています。自社管理画面でも、誰が、いつ、何を、どの理由で、何件に対して実行したかを残します。
残す項目
- actor
- role
- operation ID
- target filter
- target count
- sampleまたはsnapshot参照
- action
- reason
- approval
- result
- before/after summary
権限を分ける
閲覧できる人、previewできる人、dry-runできる人、実行できる人、rollbackできる人を分けます。実行権限を持つ人だけが対象を見られるとは限りません。
undoとrollbackを決める
- Snapshot
控え。
- Execute
実行。
- Monitor
監視。
- Undo
戻す。
- Report
報告。
undoできる操作と、補償処理が必要な操作を分けます。
undoできる操作と、rollbackや補償処理が必要な操作を分けます。
タグ付けや状態変更はundoしやすい場合があります。削除、外部送信、メール配信、権限変更、課金処理は戻しにくいことがあります。
snapshotを残す
戻す可能性があるなら、変更前の値をsnapshotとして残します。ただし、PIIやsecretをsnapshotに入れすぎないようにします。
rollbackではなくroll-forwardのこともある
一部の操作は完全に戻せません。訂正通知、追加変更、再処理、手動確認で進めるほうがよい場合があります。
戻せない操作ほど、実行前のpreview、承認、対象snapshot、実行後reportを厚くします。
Codexへ渡す依頼packet
| 項目 | 内容 | 見方 |
|---|---|---|
| Scope | 範囲。 | |
| Gate | 確認。 | |
| Limits | 上限。 | |
| Audit | 記録。 | |
| Undo | 戻し。 |
packet化すると、Codexが危険な一括実行UIを作りにくくなります。
Codexへは、次のようなpacketで渡します。
目的:
管理画面で選択した記事にcategoryを一括付与する。
対象:
現在のfilter結果から選択したarticleのみ。
publish済み記事は対象外。
preview:
件数、sample 20件、変更前category、変更後categoryを表示する。
dry-run:
server側でvalidationし、保存せず成功予定/失敗予定を返す。
confirmation:
100件超はcategory名を入力して確認する。
idempotency:
operation IDを作り、二重clickやretryで重複実行しない。
audit:
actor、target count、filter、before/after summary、reason、resultを残す。
undo:
変更前category snapshotから戻せるようにする。このpacketがあると、Codexは危険な一括実行UIではなく、確認と監査のある機能を作りやすくなります。
よくある失敗
対象不明。
無制限。
追えない。
戻せない。
bulk操作の事故は、対象が見えないまま実行できる時に起きます。
previewなしで実行できる
対象が見えないまま実行できるbulk operationは危険です。件数、sample、diffを見せます。
filter変更と実行対象がズレる
preview後にfilterが変わると、見た対象と実行対象が違うことがあります。operation IDと対象snapshotを使います。
二重clickで二重実行される
button disableだけでは不十分です。server側でoperation IDとidempotencyを持ちます。
audit logがない
実行後に誰が何をしたか分からないと、復旧と説明ができません。audit logを残します。
undoできると思い込む
外部送信や削除は戻せないことがあります。undo可能性を操作ごとに分けます。
FAQ
| 項目 | 内容 | 見方 |
|---|---|---|
| Delete? | 厳格。 | |
| Update? | 差分。 | |
| Retry? | 冪等。 | |
| Undo? | 事前。 |
迷ったら、同じ操作をもう一度押しても安全かを確認します。
confirmation modalだけで十分ですか
十分ではありません。preview、dry-run、件数上限、権限、audit log、undoと組み合わせます。
すべてのbulk操作にdry-runが必要ですか
影響が小さい操作では簡易previewで足りる場合もあります。破壊的、外部副作用あり、大量対象ではdry-runを強く検討します。
undoは必須ですか
操作によります。undoできない操作では、実行前gateを強くし、rollbackではなく補償手順を決めます。
Codexに管理画面のbulk操作を作らせてもよいですか
作らせてもよいですが、対象選択、dry-run、権限、audit、undoは人間が条件を渡し、reviewします。
何件から危険ですか
固定の正解はありません。対象データの重要度、外部副作用、rollback可否、tenant影響で決めます。件数だけでなく操作内容を見ます。
次に読むなら
参照した主な情報源
- Kubernetes API Concepts: Dry-run
- Stripe API Reference: Idempotent requests
- GitHub Docs: Exporting audit log activity for your enterprise
- GitHub Docs: About audit log streaming
- OpenAI Developers: Codex Security
更新履歴
- 2026.06.01
初版。
管理画面の操作条件は変わるため、導入時に最新Docsと社内規程を確認します。
- 2026.06.01: 初版公開。Codexへ管理画面の一括操作を任せる前のpreview、dry-run、idempotency、audit log、undoを整理しました。