結論：ant applyはplanとlockfileを中心に段階導入する
Anthropic公式のPlatform release notesによると、ant CLI 1.30.0のant applyは、リポジトリに置いたファイルからagents、environments、skills、memory stores、deploymentsを作成・更新する機能です。実行前に表示されるplanを人間が承認し、生成されたclaude-lock.jsonをcommitして、次回以降も同じリソースを更新できる状態にします。
読者の課題は、コンソールで変更した設定とGitの定義がずれ、どの環境へ何を適用したか説明できなくなることです。読了後は、まず1つの非本番環境で定義、plan、承認、apply、readback、rollbackを一つの変更記録へつなげる判断ができます。
これは単なる一括デプロイではありません。ファイルが正本になる範囲、planを読む担当、実行主体の権限、lockfileの保管場所を先に決めます。公開されている仕様と、組織で追加する承認ルールを混同しないことも重要です。ant applyの正式な引数やresource schemaは、実行前に公式のant applyドキュメントでreadbackします。
1.30.0で変わる管理単位と注意点
2026年9月3日のClaude Platform release notesは、ant CLI 1.30.0のant applyを案内しています。対象はagent、environment、skill、memory store、deploymentです。各リソースをリポジトリ内のファイルで記述し、コマンドが出すplanを確認して承認します。変更内容が見えないまま即時反映する仕組みとして扱わず、planをレビュー可能な成果物にします。
同じ公式案内では、applyが書き出すclaude-lock.jsonをcommitし、手元やCIの後続実行で同じリソースを更新することが示されています。lockfileを無視すると、新規作成と既存更新の識別が不安定になり、意図しない重複を見逃す恐れがあります。lockfileを秘密情報の置き場と決めつけず、実際の内容を確認し、機密値は別の安全な管理経路へ分離します。
| 管理対象 | 最初に固定すること | 確認者 |
|---|---|---|
| 定義ファイル | schema、owner、対象環境、変更理由 | 開発担当と運用担当 |
| plan | 作成・更新・削除、差分、対象ID | 変更承認者 |
| 認証 | service account、workspace、期限、scope | セキュリティ担当 |
| lockfile | commit、差分レビュー、復旧時点 | リポジトリ管理者 |
安全に適用する8手順
- ant CLIのversionを1.30.0以上か、組織で承認したversionか確認します。
- 対象resourceを1種類、対象environmentを非本番1つに限定します。
- 公式ドキュメントのschemaと必須項目をreadbackし、定義ファイルを作ります。
- 変更理由、owner、入力データ、想定される作成・更新・削除をcommit説明へ書きます。
- 認証主体とworkspace scopeを確認し、出力へtokenや個人情報を含めません。
ant applyを実行してplanを保存し、差分を人間が承認します。- apply後にresource ID、version、状態、関連ログを公式仕様と照合します。
- 問題があれば適用前の定義とlockfileを基準に戻し、停止理由と再実行条件を記録します。
CIへ移すときは、pull requestで定義差分とplan差分を分けます。plan生成とapplyの認証主体を同じにせず、productionだけは手動承認を残す設計が説明しやすくなります。自動化の目的は承認を消すことではなく、同じ定義を再現し、適用漏れを減らすことです。
比較：コンソール変更、手動CLI、ant apply
コンソール変更は探索や緊急対応に向きますが、差分と再現性を別途記録します。手動CLIは小さな検証に向き、実行者とcommandを台帳へ残します。ant applyは複数resourceを同じ変更単位にできますが、定義、lockfile、planのレビューが必要です。すべてをコード管理へ移すのではなく、繰り返し適用する共有設定から始めます。
判断軸は再現頻度、影響範囲、rollbackの明確さ、権限の分離、差分レビューのしやすさです。memory storeやdeploymentのようにデータや実行へ影響する対象は、定義が短くてもリスクが小さいとは限りません。削除がplanへ出た場合は、作成や更新と同じ承認で流さず、業務ownerへ確認します。
チェックリスト：apply前後のreadback
versionと公式schemaを確認したか／対象environmentは正しいか／planの作成・更新・削除を読んだか／実行主体に過剰権限がないか／機密値を定義やログへ書いていないか／claude-lock.jsonをレビュー対象にしたか／apply後のresource IDを照合したか／rollback担当と停止条件が決まっているか／次回更新日とownerを記録したか、を確認します。
組織の権限設計はClaude Admin APIの自動化、変更の証跡はCompliance APIの監査証跡、運用全体の導入順序はClaude Code企業導入チェックも参照してください。ant applyだけで権限・データ・承認が完成するわけではありません。
導入後のレビューでは、定義ファイルの変更者とapplyの実行者を分け、planの差分を見た人が承認したことを記録します。適用後の画面だけを確認すると、別の手動変更や環境違いを見落とします。定期的に定義と実リソースを照合し、差分があれば手動変更を取り込むか、正本へ戻すかをownerが判断します。
よくある質問
既存リソースを壊さず更新できますか？
定義とlockfileを正本として扱い、planで変更対象を確認してから承認します。削除や対象環境の誤りがあればapplyを止め、公式仕様と現状態を照合します。
lockfileをGitへ置くのが不安です
まず内容を確認し、秘密情報が含まれないこと、レビュー対象として扱えることを確認します。認証情報をlockfileへ入れず、CIの安全なsecret管理へ分離します。
本番も自動applyできますか？
技術的な可否と組織の承認条件は別です。planの保存、手動承認、時間帯、監視、停止、復旧をそろえてから範囲を拡大します。
公式情報と無料診断
仕様、version、対応resourceは公式ドキュメントと公式release notesを公開直前にreadbackしてください。Miraigentの無料診断では、定義の正本、権限、承認、ログ、rollbackを業務単位で整理します。