はじめに
本稿は生成AIで作ったインフラのデプロイメントに、CI/CDガードレールを引いて安全なリリースを実現する話。対象は以前作ったオンプレ＋AWSで構築したダッシュボードである。
過去作：玄関にオリジナルダッシュボードを設置した
https://qiita.com/bd8z/items/d0c20d5f1cb0833d1bbc
おうち用のダッシュボードの運用においては、ちょっとした変更から逃れられない。センサの追加、ダッシュボードのUI改善、バス時刻情報の改定などデータ部分…。家族からのSLAも厳しい（SLA100%）。変更をコーディングエージェントにやってもらうと、ほんの小変更でもAPI基盤が壊れてしまい、復旧に莫大なトークンが消費され、時間もかかってしまう。生成AI開発にはガードレール開発が必要とよく言われるのでこれを実践し、デプロイ・テスト・ロールバックの仕組みを構築することで、継続的な改善に耐えられるようにしていく。
最終的に落ち着いたダッシュボードインフラ
ダッシュボードの物理・論理構成の特徴として、Mac mini上のAPI基盤、AWS側の各種データ層など、オンプレ（家庭内）と、AWS側にインフラが分かれた構造がある。これまでは端末からSSHログインして直にコマンドを打つ、powershellスクリプト（ps1）からデプロイメントを行うなど、コーディングエージェントに気ままにやらせていて、 デプロイに冪等性が存在しなかった。テストも存在しなかった。 この状態から、正規のCI/CDパイプラインを通らないとリリースができない構成にした。
アーキテクチャの工夫点
- 全てのパイプラインはGitHub Actionsで管理する
- オンプレミス側はMac mini上のSelf-Hosted RunnerからPull型のリリース
- Podmanでコンテナビルドとテストデプロイを担う
- Pull型なのでM4 Macでもイメージビルド環境に困らない
- AWSリソースはCodePipelineからCloudFormationでリリースされる
- Cloud RunnerにAWS CLIを入れたくないのでCodeシリーズでPull型構成とした
- 全てのデプロイの後にAPIテストがあり、失敗した場合はCommitIDを起点にロールバックされる
パイプラインの設計
AWS側のステージをActionsパイプラインの中に内包した1つのパイプライン構成とした。また最後にロールバックステージを入れて、失敗をガードできるようにした。
パイプライン作成時にコーディングエージェントが実装したアンチパターン
上記のMermaidの画像も、ADRも、すべてコーディングエージェントに委任したが、開発の中でいわゆるアンチパターンでエージェントが実装をしてくることがあったので書いておく。今回はGPT-5.3-Codexを利用した。
パターン1 セキュリティキーの直接ぶち込み
ケース：GitHubのリポジトリ間の親リポジトリとサブモジュール間の接続の実装
手持ちの手札で実装しようとするのでどうしてもセキュリティキーをURLにぶち込む様な実装に走りがちであるが、GitHubの場合リポジトリ間はGitHub Appで認証認可を設定すべきであり、必ずしもベストプラクティスを守ってくれない。
パターン2 意味のないテストステージ
ケース：パイプライン上のAPIテストステージ実装
ダッシュボードにはバス時間の取得が含まれている。例えば深夜帯に開発していると、リアルタイムにバスが動いていないなど、APIが正常動作でもクエリの結果が空になり、テストステージが失敗判定になる。最近使えるようになったautopilotを走らせていると、ステージ設計を楽な方向に（テストが通る方に）テストクライテリアを緩和していき、ガードレールとして意味のないステージが完成しそうだったので慌てて止めた。
最後に
冪等なデプロイプロセスと、ガードレールとなるパイプラインを手に入れたので、モバイルからIssueを投げる気軽な開発を安心してできるようになった。彼らは手札内で何とか実装しようとしてくるので、やはりレビュープロセスが必要だと感じている。レビューの底上げのために、レビューエージェントなどにも手を出していきたい。また、実装においては必要最低限のトークンだけ用意してgh/awsコマンドを打たせるなど、Sandbox化も少し工夫した。コーディングエージェントは、放置していると何でもかんでも.envに書いていくなど、セキュリティでも課題がある。私個人も人間としての学習も忘れず、しっかり気を付けながら使っていく。