Claude Managed AgentsのIaC化：ant CLIによる構成管理の衝撃

深夜の障害対応で、コンソールをポチポチとクリックして設定を修正し、その変更内容がどこにも記録されずに「あの設定、誰がいつ変えたんだ？」と頭を抱えた経験はないだろうか。我々エンジニアにとって、GUIベースの管理画面は便利である反面、常に『再現性の欠如』という爆弾を抱えている。Anthropicが提供するClaude Managed Agentsにおいて、ついにこの悪夢を終わらせるための強力な武器が実装された。ant CLI v1.30.0で追加された『apply』コマンド、これこそがエージェント開発におけるInfrastructure as Code（IaC）の幕開けである。

これまで、エージェントのプロンプトやMCPサーバーの設定は、ブラウザ上の管理画面で完結することが多かった。しかし、本番環境で動くエージェントの挙動をコードとして管理できないことは、CI/CDパイプラインの構築を阻む最大の障壁だった。今回導入されたant CLIのapply機能は、単なる設定の同期ツールではない。ローカルのYAMLファイルやMarkdownで定義されたエージェント構成を、リモートのClaude Developer Platformと同期させるための、極めてTerraformに近い思想で設計されたツールだ。

具体的には、ant applyを実行することで、ローカルの定義ファイルとリモートの状態を比較し、差分を適用する。この際、claude-lock.jsonというロックファイルが生成される。これはTerraformにおけるtfstateに相当するもので、リソースのIDやハッシュ値が記録される。このファイルをGitで管理することで、エージェントの構成変更をプルリクエストベースでレビューし、デプロイを自動化することが可能になる。これは、単なる「設定の保存」を超え、エージェントという「動的な知能」を、我々が普段使い慣れたソフトウェア開発のライフサイクルの中に完全に組み込めるようになったことを意味する。エンジニアとして、この「コードによる統治」の感覚は、非常に心地よい。

今回のant CLIの設計を詳細に分析すると、Anthropicが意図的に「Terraformの成功体験」を模倣しつつ、エージェント特有の安全性を担保しようとしていることが見て取れる。例えば、ant apply --dry-runによる事前確認機能は、Terraformのplanコマンドそのものだ。適用前にどのようなリソースが作成・更新・削除されるのかを明示的に表示するこのプロセスは、本番環境での事故を未然に防ぐための必須要件である。しかし、CloudFormationとの決定的な違いとして、ロールバック機能が存在しない点には注意が必要だ。更新が途中で失敗した場合、スタック全体が巻き戻ることはない。この設計は、一見すると不親切に思えるかもしれないが、エージェントという「状態を持つリソース」を扱う上では、中途半端なロールバックによる不整合を防ぐための賢明な判断だと私は評価する。

また、管理対象のリソースタイプが厳格に制限されている点も興味深い。現在、applyで管理可能なのは以下の5種類に限定されている。

特筆すべきは、セッションデータやAPIキー、組織管理といった「実行時データ」や「機密情報」が意図的に管理対象外とされている点だ。これは、シークレットをリポジトリに混入させるという、IaCにおける最も初歩的かつ致命的なミスを、ツール側で物理的に封じ込めている。開発者が「便利だから」といって何でもかんでもコード化しようとする誘惑を、Anthropicはあえて拒絶しているのだ。この「何をやらせて、何をやらせないか」という明確な線引きこそが、エンタープライズ環境でエージェントを運用する際の信頼性の根拠となる。

最後に、我々エンジニアが明日から取るべきアクションについて触れたい。このIaC化によって、エージェント開発は「プロンプトエンジニアリング」という属人的な職人芸から、「エージェント・インフラエンジニアリング」という再現可能な工学へと昇華した。今後は、エージェントのプロンプトをGitで管理し、GitHub Actions等のCIツールでant applyを自動実行するフローを構築することが、標準的な開発スタイルになるだろう。しかし、ここで一つ、我々が直面せざるを得ない問いがある。それは「エージェントの挙動をコードで固定することの是非」だ。

LLMの出力は確率的であり、同じプロンプトでも実行のたびに結果が異なる可能性がある。IaCで構成を管理できたとしても、エージェントの「知能の品質」までをコードで保証することはできない。我々は、インフラの構成管理という「箱」を整えることには成功したが、その箱の中身である「知能の振る舞い」をどうテストし、どう品質保証（QA）していくのかという、全く新しい課題に直面している。単に設定をapplyして終わりではない。そのエージェントが期待通りに推論し、安全に動作しているかを検証する「評価パイプライン」の構築こそが、これからのシニアエンジニアに求められる真のスキルセットではないだろうか。

あなたは、この「コード化されたエージェント」を、単なる設定ファイルとして扱うのか、それともテスト可能なソフトウェアコンポーネントとして扱うのか。このツールが提供された今、その答えを出すのは我々自身である。既存のIaCの知見をエージェント開発に持ち込むことは、単なる効率化の手段に過ぎない。真の目的は、AIという予測不能な存在を、我々のエンジニアリングの枠組みの中にいかにして「制御可能なもの」として取り込むかにある。この問いに対する答えを、日々の開発の中で見つけ出してほしい。