# ant applyでエージェントをコードとして管理する > ant CLI 1.30.0（2026年9月3日公開）の`ant apply`は、エージェント・スキル・デプロイをファイルで宣言しclaude-lock.jsonで差分管理する機能です。CI組み込みの手順を解説します。 - Canonical: https://kuucorp.com/blog/managed-agents-ant-apply-infrastructure-as-code/ - Date: 2026-09-30 - Last modified: 2026-09-30 - Publisher: Kuu株式会社 (https://kuucorp.com) --- 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](/blog/claude-api-workspace-team-management-wif/)が推奨されます。 ターミナルの無い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](/blog/claude-managed-agents-for-sme/)導入の初期段階からGitレビューに乗せられる点が着手しやすさです。エンタープライズでは、複数チームがエージェント・スキル・デプロイを同一組織内で管理する状況になりやすく、`--prune`によるリソース削除やConsole経由の変更が`--force`なしに上書きできない設計を、変更管理プロセスの一部として明文化すべきです。大規模な調達・ガバナンス設計は[Kuuの高度化支援サービス（RDE）](https://kuucorp.com/services/rde/)が対応します。 ## 参考 - [Manage resources as code with ant apply（公式ドキュメント）](https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply) - [Claude Platform release notes（公式リリースノート）](https://platform.claude.com/docs/en/release-notes/overview) - [Workload Identity Federation（公式ドキュメント）](https://platform.claude.com/docs/en/manage-claude/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）](https://kuucorp.com/services/ai-ops/)からどうぞ。