Managed Agentsの本番運用が増えるほど、「このエージェントは誰がいつ設定を変えたのか」「Console上の変更が他の環境に反映されているか」が追いづらくなります。エージェント・スキル・デプロイをConsoleでGUI操作していると、コードのようにレビュー・差分・ロールバックが効かないためです。2026年9月3日公開のant CLI 1.30.0が追加したant applyは、この管理をコードベースのワークフローに揃える機能です。
ant applyとは何か
ant applyはエージェント・環境・スキル・メモリストア・デプロイをリポジトリのファイルから作成・更新するコマンドです。
ant applyは、Managed Agentsのリソース（エージェント・environment・skill・memory store・deployment）をMarkdown・YAML・JSONファイルとしてリポジトリに置き、それをAPIの状態と同期させるコマンドです。エージェントであればMarkdownのfrontmatterにname・model・toolsなどのAPI設定を書き、本文がそのままシステムプロンプトになります。ファイルを編集してant applyを再実行すると、差分（作成/更新/変更なし）をプランとして表示し、承認してから反映する——TerraformやPulumiと同じ「宣言・プラン・適用」のモデルをManaged Agentsに持ち込んだ形です。
claude-lock.jsonはどう差分を追跡するか
初回applyが書き出す
claude-lock.jsonが各ファイルのリソースIDと2種類のハッシュを記録し、外部変更を検知します。
初回のant applyはカレントディレクトリにclaude-lock.jsonを書き出します。中身は各ファイルパスに対するkind（agent/skill等）・APIが払い出したリソースID・hash（最後に送信した内容のフィンガープリント）・remote_hash（APIから返った内容のフィンガープリント）です。次回実行時はこの2つのハッシュを比較し、ローカルファイルが編集されていれば更新プランを、Console等でリソースが外部から書き換えられていればThis plan cannot be appliedで処理を止めます。外部変更を上書きするには--forceが必要です。このロックファイルはコミット対象で、CIでも同じリソース群を指し示すために必須です。
リソース間の依存関係はどう解決されるか
リソースは相対パスで参照し合い、
ant applyが依存順に適用してバージョンをピン留めします。
エージェントが使うスキルやサブエージェント、deploymentが参照するagent・environment・memory storeは、APIのID欄に相対パスを書くだけで参照できます。例えばdeploymentのfrontmatterにagent: ../agents/reviewer.mdと書くと、ant applyはそのファイルを先に適用してIDを解決し、依存順に反映します。参照は適用時点のバージョンにピン留めされるため、reviewer.mdを更新すればそれを参照する全リソースが同じ実行内で更新されます。GitHubリポジトリのディレクトリをスキルとして直接参照することもでき、その場合は解決したコミットに固定され、--upgradeを指定するまで動きません。
CI/CDにどう組み込むか
ターミナルの無いCIでは
--yesか--dry-runが必須で、認証はWorkload Identity Federationが推奨されます。
ターミナルの無いCI環境でant applyをそのまま実行すると、承認を求められずcannot ask for confirmation without a terminalで止まります。公式ドキュメントは、デフォルトブランチへのマージ後にant apply --yes .で反映し、プルリクエスト上では--dry-runでプランをレビュアーに提示する2段構成を推奨しています。認証は長期間有効なAPIキーをCIに置くのではなく、GitHub ActionsのOIDCトークンなどをその場で交換するWorkload Identity Federationを使うことで、鍵の保管・ローテーションが不要になります。claude-lock.jsonはapplyが途中失敗した場合でも更新分を反映するため、ジョブの最後に必ずコミットする必要があります。またロックファイルへの排他制御は無いため、同時実行するapplyは1つに限定します。
規模別の留意点（SMB / エンタープライズ）
SMBでは、1人か少人数のチームがエージェント設定ファイルをリポジトリで管理するだけで、Console操作の属人化を避けられます。追加のインフラは不要で、Managed Agents導入の初期段階からGitレビューに乗せられる点が着手しやすさです。エンタープライズでは、複数チームがエージェント・スキル・デプロイを同一組織内で管理する状況になりやすく、--pruneによるリソース削除やConsole経由の変更が--forceなしに上書きできない設計を、変更管理プロセスの一部として明文化すべきです。大規模な調達・ガバナンス設計はKuuの高度化支援サービス（RDE）が対応します。
参考
- Manage resources as code with ant apply（公式ドキュメント）
- Claude Platform release notes（公式リリースノート）
- Workload Identity Federation（公式ドキュメント）
まとめ
ant applyは、Managed Agentsのエージェント・スキル・デプロイをConsoleのGUI操作から切り離し、リポジトリのファイルとコードレビューを経由する運用に揃えるコマンドです。claude-lock.jsonによるハッシュ比較で外部変更を検知し、相対パス参照で依存関係を宣言的に解決する設計は、Terraform等のIaCツールに慣れたチームなら学習コストが小さく導入できます。CIに組み込む際は、--dry-runによるプルリクエストレビューとWorkload Identity Federationによる鍵レス認証を組み合わせることが、静的なAPIキーをCIに置かないための実務上の基準になります。
Managed Agentsの運用設計・CI組み込みのご相談はKuuの運用管理サービス（AI Ops）からどうぞ。