AIコーディングで変わるインフラ運用 - Ansible × Claude Code × CI/CDの実践

先日、新しいサーバを手に入れました。

セットアップを始めた瞬間、「あ、これ全部手作業でやると、のちのち大変だな」と感じました。

サーバが増えたことにより、複数のサーバにシステムアップデートを実行するだけでも面倒くさいです。一見シンプルな作業ですが、台数とOSの種類が増えるたびに手間は指数関数的に増加します。

さらに厄介なのが、一つのミスが致命的になり得る作業があることです。

OSの設定変更、ファイアウォールルールの追加。これらを手動で実行するのは、正直ヤバイです。特にネットワーク廻りは失敗するとリモート接続ができなくなりますから、対応も厄介です。

わたしは過去に何度も、インフラ設定での失敗を経験してきました。その度に思うんです。「なぜ操作ログを保持していなかったのか」そして「chef で生かした経験を自宅サーバ運用へ活かさないのか」と。

本記事では、AnsibleというInfrastructure as Code（IaC）ツールに、Claude CodeというAIコーディングツールとCI/CDパイプラインを組み合わせることで、安全で効率的なインフラ運用を実現した方法をお伝えします。

なぜAnsibleを選んだのか

自動化ツールを選ぶときにいくつかの選択肢を検討しました。

以前に使っていた Rundeckのような運用管理特化ツールも良さそうでしたし、他のオーケストレーションツールも魅力的でした。過去にはChefを使っていた経験もあります。

今回は、Ansibleを選びました。

Ansibleの決め手となった特徴

べき等性の担保

何度実行しても同じ結果が得られる。これは本当に安心感があります。「間違えたかも」と思ったら、もう一度実行すれば確認できる。

エージェントレス

対象サーバーに特別なソフトウェアをインストールする必要がない。SSH接続だけで動作します。管理対象のサーバに余計なものを入れたくない派なので、ここは大きなポイントでした。

複数サーバへの一括適用

インベントリファイルで管理対象を柔軟に定義できます。「この設定は開発環境だけ」「本番環境全体に適用」といった使い分けが簡単です。

OS差異の吸収

しょっさんの環境はDebianとUbuntuだけですが、将来的に他のディストリビューションを使う可能性もあります。Ansibleなら、ディストリビューション間の違いを意識せずに書けるケースが多いと推測しました。

コミュニティと情報量

困ったときに検索すれば、たいてい誰かが同じ問題に直面して解決策を共有しています。これは大きい。

インフラ設定における「失敗の怖さ」

アプリケーション開発とインフラ運用では、失敗の重みがまったく異なると考えています。

わたしはこれを身をもって体験してきました。

アプリケーションの場合

バグがあっても、段階的に修正できます。影響範囲も限定的なことが多いし、ロールバックも比較的簡単。

最悪、「すみません、バグってました」で済むことが多い(そうもいきません、分かってます)。

いやアプリのバグでもえらい状況になることは分かってます。ただ、インフラはちょっとのミスでシステムをカンタンに全破壊できる基盤だということで重みを感じます。

インフラ設定の場合

たった一つの設定ミスが致命的になります。

しょっさんが過去に経験した（あるいは目撃した）失敗例をお話しします。

ファイアウォール設定での失敗

# SSHポートを誤ってブロックしてしまう
iptables -A INPUT -p tcp --dport 22 -j DROP

このコマンド一つで、リモートからの接続が完全に不可能になります。

Enterキーを押した瞬間、「あ…」という感覚。接続が切れて、もう二度とログインできない。

仕事で管理しているシステムだったら、データセンターへ出向いて、コンソールからやり直しです。イヤ、リモートでこんなヤバイ作業するなよって話ですけれども。

あるじゃん緊急対応とか(緊急で iptables いじる…?)

SSH設定での失敗

# /etc/ssh/sshd_config の誤った変更
PermitRootLogin no
PasswordAuthentication no
# しかし鍵認証の設定を忘れていた...

SSHを再起動した瞬間、誰もログインできなくなります。

自宅サーバあるあるです。雑に iptables と sshd の設定をしていると、あっというまにリモート接続を拒絶されるわけです。

教訓

インフラの場合、「とりあえず試してみる」は許されません。インフラは特にまったく同じハードウェアを準備してテストすることが望ましいのですが、実態はそうもいきません。ハードウェアは高い。

そして、雑に思いついたままに作業を実施してしまうと、何を変更したのか後から調べることすら困難です。リモートアクセスが不可能になるので、物理的なアクセスが必要になることもある。

だからこそ、インフラの変更作業こそ慎重にならざるを得ませんでした。本番を止めるなんて、いともたやすいことなのですよ。

AI時代の新しいAnsible運用フロー

この「失敗の怖さ」に対処するため、次の運用フローを作りました。

1. テスト環境で手動設定・動作確認
   ↓
2. Claude Codeに設定内容を伝えてPlaybook作成
   ↓
3. Docker/VMの仮想環境でPlaybookをテスト
   ↓
4. GitHub Actionsで自動チェック（CI/CD）
   ↓
5. ステージング環境へ適用（--check → --diff → 実行）
   ↓　
6. 本番環境へ適用（--check → --diff → 実行）

このフローの核心は、「動作確認済みの設定」をClaude Codeに伝えることです。

これが最も重要です。

あやふやな指示を出すと、期待していない設定変更を行うケースがあります。アプリ開発でも痛い目にあいました。否、毎日、痛い目にあっています。ここまでやっても痛い目にあう時はあります。

悪い指示の例

「nginxをセキュアに設定してください」

これだと、Claude Codeが「セキュア」をどう解釈するか分かりません。もしかすると nginx 以外のアクセスを全て拒絶してくれるかも知れません。

良い指示の例

「以下の設定をテスト環境で動作確認しました。
この内容でnginxのPlaybookを作成してください：

- nginx 1.24.0をインストール
- /etc/nginx/nginx.conf に以下の設定を追加
  - worker_processes auto;
  - worker_connections 1024;
- SSL証明書のパス: /etc/ssl/certs/example.com.crt
- 80番ポートは443へリダイレクト
- デフォルトサイトは無効化

具体的で検証済みの情報を伝える。これがコツです。設定済みの設定ファイルを提供することが一番まちがいがありません。

なぜこのフローが安全なのか

テスト環境での事前検証

失敗しても、影響範囲が限定的です。しょっさんは KVM での仮想環境とDockerコンテナ運用をしているので、壊れたら捨てて作り直せばいい。気が楽です。

まぁこういったテスト環境を準備することは当然のことですけれども。

Playbookが設定のドキュメントになる

何をしたかが後から分かります。半年後に「あれ、このサーバーどう設定したっけ?」となっても、Playbookを見れば一目瞭然。

log だけ残しておいても、その中からコマンドを抽出して正しい作業を明確にしようとしても、OS のバージョンやちょっと環境が異なればおじゃんです。

Ansible などであれば、ある程度のことを抽象化して担保できます。
抽象化できるってのがポイントです。

べき等性による再現性

同じ設定を複数サーバーに確実に展開できます。「あれ、このサーバーだけ設定が違う?」という事故が起きにくくなります。

複数のサーバを運用するものの宿命さだめです。

CI/CDによる自動チェック

人的ミスを機械的に防げます。Pull Requestを出すと、自動的に構文チェックやLintが走る。マージする前に問題を発見できます。

Claude Code でも lint や syntax-check させているのに、何故か素通りすることがあります。ホントに不思議。ここは最後の砦です。

ステージング環境へ適用する

ここまでやっておいてから、更に VM を立ち上げてステージングの環境へ適用させます。念には念を入れます。しょっさんは、過去に本番環境に両親を殺された過去があります。

＊ ﾟ･*:.｡.:*･゜＋ d(*´∀｀)b うそです ＋.:*･゜ﾟ･*:. ＊。

--check, --diffによる可視化

本番環境に何が行われるかを事前確認できます。「このファイルのこの行が、こう変わります」というのが、適用前に分かる。

これがあるから、しょっさんは安心して本番環境に適用できるんです。

ここから先は、実際の実装例や具体的なPlaybook、CI/CD設定など、より実践的な内容をお伝えします。