こんにちは。 Legalscape VPoTの小林です。
最近、インフラ変更の進め方を少しずつ見直しています。
きっかけは、AIエージェントに任せられる仕事の範囲を広げたい、という課題感でした。
Terraform のような Infrastructure as Code は、AIエージェントとの相性がかなり良い領域です。差分はテキストで表現されますし、terraform plan によって変更内容も検証できます。エラーが出れば、そのエラーをもとに修正することもできます。
一方で、インフラ操作には強い権限が必要です。
個人の認証情報で自由に terraform apply できる状態のまま、AIエージェントに作業を任せるのは怖い。人間がローカルで apply していた運用をそのまま AI に渡すのではなく、権限管理とレビューの境界を作ったうえで AI に作業を任せたい。
そのための仕組みとして Atlantis を導入しました。
この記事では、Atlantis を使ってみて「これは入れておいた方がよさそう」と感じた便利オプションを紹介します。
Atlantis でやりたかったこと
やりたかったことは大きく3つです。
1つ目は、個人の認証情報でインフラを操作しないことです。
開発者のローカル環境に強い権限を持たせるのではなく、Terraform の実行主体を Atlantis に寄せます。人間や AIエージェントは Pull Request を作り、Atlantis が PR 上で plan を実行し、条件を満たした場合だけ apply できるようにします。
2つ目は、PR 上で terraform plan の結果を確認できることです。
Terraform の変更では、コード差分だけを見ても実際に何が変わるか分かりづらいことがあります。Atlantis を使うと、PR のコメントやチェックとして plan 結果が残るため、レビューの中心を「Terraform コード」だけでなく「実際のインフラ差分」に寄せられます。
3つ目は、AIエージェントに修正ループを回させやすくすることです。
たとえば Claude Code on the web のようなエージェントは、PR 上の Atlantis plan の失敗を見て、エラー内容に応じた修正を追加できます。人間がローカルで terraform plan を叩き、エラーをコピーし、AI に渡し、修正を取り込む、という手順を挟まなくてよくなります。
PR に push する。 Atlantis が plan する。 失敗したら AIエージェントが直す。 もう一度 Atlantis が plan する。
このループが PR 上で回るだけで、インフラ変更の作業体験はかなり良くなります。Devin のようなエージェントでも、同じような運用はできそうです。
便利オプション
apply_requirements
便利というか必須オプションです。
apply_requirements: [approved, mergeable]
これは、atlantis apply を実行するための条件を指定するオプションです。
approved を指定すると、PR が approve されていない状態では apply できません。mergeable を指定すると、PR がマージ可能な状態でないと apply できません。
AIエージェントに Terraform のコード修正を任せる場合でも、「コードを書けること」と「インフラに反映できること」は分けておきたいです。
AIエージェントは PR を作れる。 Atlantis は plan を実行できる。 ただし apply は、人間のレビューとマージ可能性を満たした場合だけ実行できる。
この境界を作るうえで、apply_requirements はかなり重要です。
Terraform の世界では、plan はレビュー材料ですが、apply は実際の変更です。AIエージェント活用を進めるなら、まずは apply の手前に明確なゲートを作るのがよいと思います。
repo_locks.mode: on_apply
次に便利なのが repo_locks です。
repo_locks: mode: on_apply
Atlantis にはロック機構があります。複数の PR が同じ Terraform project に対して同時に変更を加えると、片方の plan がもう片方の apply 後には古くなってしまうことがあります。ロックは、そのような衝突を避けるための仕組みです。
デフォルトでは plan 時点でロックを取る運用になりがちですが、これはチームによっては少し厳しすぎます。特に AIエージェントが複数の PR を作るようになると、「plan しただけの PR がロックを持ち続ける」ことが邪魔になる場合があります。
そこで mode: on_apply にすると、apply のタイミングでロックを取る運用にできます。
これにより、plan は比較的気軽に回しつつ、実際に反映する段階では競合を避ける、というバランスが取りやすくなります。
AIエージェントに何度も修正させる運用では、plan は頻繁に失敗します。失敗するたびにロックが強く効きすぎると、開発体験が悪くなります。on_apply は、AIエージェント時代の Atlantis 運用と相性が良い設定だと感じています。
pre_workflow_hooks で atlantis.yaml を動的生成する
Terraform のディレクトリ構成がある程度規則的なら、atlantis.yaml を手で管理するより、自動生成した方が楽です。
Atlantis には pre_workflow_hooks があります。
pre_workflow_hooks: - run: ./generate-atlantis-yaml.js description: Generate atlantis.yaml dynamically
pre_workflow_hooks は、plan や apply の workflow が実行される前に任意のスクリプトを実行できる仕組みです。
これを使って、リポジトリ内の Terraform project を走査し、atlantis.yaml を動的に生成するようにしています。
parallel_plan / parallel_apply
複数 project を持つリポジトリでは、parallel_plan と parallel_apply が有効です。
parallel_plan: true parallel_apply: true
Terraform project が増えてくると、PR に関係する plan が複数走ることがあります。これを直列に実行していると、単純に待ち時間が長くなります。
ATLANTIS_AUTOPLAN_MODULES
これは、ローカル module の依存関係を Atlantis に見てもらい、module 変更時に依存 project の plan を走らせるためのオプションです。
ATLANTIS_AUTOPLAN_MODULES=true
Terraform の構成が小さいうちは、project 直下の変更だけ見ていても問題になりにくいです。しかし、共通 module を使い始めると、「module は変わったが plan が走らない」という事態が起きます。
module 変更時の plan 漏れを減らす設定は、AIエージェントと Atlantis を組み合わせるうえでかなり大事です。
ATLANTIS_HIDE_PREV_PLAN_COMMENTS ・ ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS
Atlantis を使い始めると、PR コメントがかなり増えます。
特に monorepo で複数 project を plan する場合、変更なしの plan や古い plan コメントが大量に残ります。これは人間にとっても読みづらいですし、AIエージェントにとってもノイズになります。
そこで、以下の2つを有効にしています。
ATLANTIS_HIDE_PREV_PLAN_COMMENTS=true ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS=true
ATLANTIS_HIDE_PREV_PLAN_COMMENTS=true は、古い plan コメントを隠して PR を見やすくする設定です。
ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS=true は、変更なしの plan コメントを削除する設定です。
これらは地味ですが、かなり効きます。
AIエージェントに plan 失敗を見て修正させる場合、「どのコメントが最新の失敗なのか」が分かりづらいと精度が落ちます。人間のレビューでも同じで、PR 上に古い plan 結果が残っていると、どれを見ればよいのか迷います。
PR を綺麗に保つことは、単なる見た目の問題ではありません。
ATLANTIS_ALLOW_DRAFT_PRS
ATLANTIS_ALLOW_DRAFT_PRS=true
デフォルトでは、Atlantis は draft PR に反応しません。
しかし、AIエージェントに作業を任せる場合、draft PR の段階で plan を回したいことが多いです。
人間にレビューを依頼する前に、まずは AIエージェントに Terraform の構文エラーや provider 設定のミスを直してもらいたい。plan が通るところまで持っていってから Ready for review にしたい。
この運用をするなら、draft PR でも Atlantis が反応してくれる方が便利です。
draft PR は「まだ人間レビュー前の作業場」として使えます。その作業場で Atlantis plan が走ると、AIエージェントが自律的に直せる範囲が広がります。
AIエージェントに任せたいのは、最初から完璧な PR を作ることではありません。
むしろ、失敗した plan を見て、何度も小さく直すことです。そのためには draft PR でも plan が回る方が自然です。
まとめ
当初、Atlantis は「個人の認証情報でインフラを触らないようにするための権限管理基盤」として導入しました。
ただ、実際に使ってみてそれ以上に便利だったのは、PR 上の terraform plan の結果を AIエージェントが見て、勝手に修正ループを回してくれる体験でした。
Terraform のエラーや plan の失敗を人間がローカルで確認し、AI に貼り付けて修正させるのではなく、PR 上で Atlantis が plan し、その結果をもとに AIエージェントが追加修正する。この流れになるだけで、インフラ変更の作業体験はかなり良くなります。
Atlantis は昔からあるツールですが、AIエージェントと組み合わせることで、改めて価値が増しているように感じます。Terraform を PR ベースで安全に扱いたいチームはもちろん、AIエージェントにインフラ変更の一部を任せたいチームにもおすすめです。
導入する際は、この記事で紹介したようなオプションを入れておくと、かなり使いやすくなると思います。
Atlantis をこれから入れる方の参考になれば幸いです。
さいごに
Legalscapeではエンジニア全方面で募集中です。AIを用いた開発の効率化に興味がある方、弊社に興味に湧いた方がいればぜひお気軽にご連絡ください
