1．はじめに

Vol.1 では，GitHubリポジトリを解析してデプロイ計画を立てるエージェントのAIを作成しました．しかし、AIが生成するコード（Dockerfileなど）には、セキュリティ設定が甘かったり構文エラーを含んでいたりすることが多々あります．さすがにこれでは怖くて自動デプロイなんて任せられません．

そこで Vol.2 では，エージェントの信頼性をできるだけ高めるために「自己修正ループ」を実装してみます．

これは、AIが生成したコードに対して Hadolint や Trivy, cfn-lint といった静的解析ツールを実行し、検出されたエラーをAIにフィードバックして自動修正させる仕組みです．「AIにコードを書かせ、ツールにレビューさせる」というサイクルを実装し、実用的な品質のコードを生成できるようにします．

Vol.2 の対象読者
- AI⇔静的ツールでの「自己修正ループ」に興味のある方
- ハルシネーションを抑制したい方

全記事の内容は以下のようになってます．興味のある方はぜひ読んでみてください！

1．[DevOps-Agent開発 Vol.1] FastMCPとAWS Bedrockで「コードを読んで勝手にデプロイ計画を立てるAI」を作ってみた

2．[DevOps-Agent開発 Vol.2] AI⇔静的ツールでの「自己修正ループ」を作成してみた

3．[DevOps-Agent開発 Vol.3] AWS SAMでエージェントに特定プロジェクトのデプロイ・リソース削除機能を持たせてみた

本アプリケーションのコード（Vol.1, Vol.2, Vol.3統合版）は Github にて公開しているので，興味のある方はぜひ使用してみてください！

2．実装部

2.1．システム構成図

Vol.2では，Amazon Bedrock と静的解析ツールの間でのフィードバックループの実装を行います．図からでは，Amazon Bedrock が静的ツールのコマンドを直接叩いている様に見えますが（便宜上のため図のような記載にしています），Amazon Bedrockには「」の機能がないため，MCPサーバー越しにフィードバックループを作成する方針で実装を行っています．

2.2 なぜ，マルチエージェントでなく「AI⇔静的解析ツール」なのか

最近は「AI⇔AIで議論させる（マルチエージェント）」方式も出てくるなど，AI単体ではなく複数のAIを用いて生成品質を上げるようなものも出てきています．しかし，今回は以下の理由でマルチエージェント方式を採用せずに「AI⇔静的解析ツール」を採用しました．

確実性
AI同士のレビューは「なんとなく良さそう」で合意してしまうリスクがありますが，Lintツールは 1mm でもルールに違反している場合には指摘が入るため，確実性という意味では静的ツールが勝ります．
　
導入コストと速度
マルチエージェントのように複数のLLMを動かす場合，大量のメモリを消費したり生成に時間がかかってしまうといった課題があります．また，マルチエージェントでも～～のような外部で提供されているAPIもありますが，費用が加算でしまうといった課題もあります．そのため，ローカルの軽量なバイナリ（Hadolint等）を走らせ自己修正ループを形成する方がが圧倒的に速くて安価で済むといったメリットがあります．

3．実装

今回採用した 「静的解析ツール群」 の紹介と，それを用いてどのように自己修正ループを実装したかについて説明します．

3.1．静的解析ツール群（Trivy/ Hadolint / cfn-lint)

DevOps-Agentでは最終的にAWS SAMを使用してDockerfileをビルドして Amazon ECR を経由して AWS Lambda にデプロイします．そのため，AIの成果物としてはデプロイ用のDockerfileとAWS SAM テンプレートであるtemplate.yamlが必要になります．そのため，この二つのファイルを監査することができるツールを利用します．

Trivy
設定ファイルの脆弱性スキャンを行うことができるツールです．このツールはDockerfileとtemplate.yamlの両方に適用できます．
　
Hadolint
Haskell製のDockerfile用のLinterです．ベストプラクティス違反（sudo使用、バージョン未指定など）を検知してくれます．
　
cfn-lint
AWS CloudFormationのLinterです．構文エラーや必須プロパティの欠落をAWS仕様書に基づいて厳密に検知してくれます．

3.2．AIへのフィードバックの作成

「エラーが出たときに、どうやってAIに直させるか」をどのように実現しているかについて説明します．結論から言うと，AIへの入力プロンプトにツールからのエラーを直接入力する形で実現しています．
　例えば，AIが「rootユーザーのままコンテナを動かすDockerfile」を生成してしまい，監査ツールの Hadolint がそれを検知した場合を想定します．プログラムでは，この検知されたエラーメッセージをキャプチャし，再生成を依頼するプロンプトの末尾に以下のように追記します．

add_prompt

[IMPORTANT: Fix previous errors]
The previous attempt failed with the following checks:
[Hadolint] DL3002: Last USER should not be root
Please fix these issues.

3.3．自己修正ループの作成

最後に、これまで作成した生成機能と静的解析ツール群を統合し，自律的にループを回すロジックを src/server.py に実装します．以下は plan_deployment 関数からの抜粋です．ここでは「Dockerfileの修正」と「SAMテンプレートの修正」を独立した2つのフェーズとして実装しています．

Phase 1: Dockerfileの自律修正
まずはコンテナ定義である Dockerfile を作成します．

# ==========================================
# Phase 1: Dockerfile生成部 
# ==========================================
dockerfile_errors = "" # 1回目は空文字

print(f"   [1/2] Preparing Dockerfile...", file=sys.stderr)

# MAX_RETRIES (例: 3回) まで試行するループ
for attempt in range(settings.MAX_RETRIES):
    
    # 【生成】: 前回のエラー内容(dockerfile_errors)をAIに渡してコードを生成
    docker_content = decider.generate_dockerfile(context, attempt, dockerfile_errors, target)
    (work_dir / "Dockerfile").write_text(docker_content)
    
    # 【監査】: Hadolint / Trivy を実行して違反リストを取得
    violations = decider.audit_dockerfile(docker_content, target)
    
    # 違反がなければループを抜ける（成功）
    if not violations:
        print(f"     ✅ Dockerfile passed checks (Attempt {attempt+1})", file=sys.stderr)
        dockerfile_ok = True
        break
    else:
        # 違反がある場合、エラーメッセージを蓄積して次のループへ
        print(f"     ⚠️ Dockerfile issues (Attempt {attempt+1}): {len(violations)} found.", file=sys.stderr)
        dockerfile_errors = "\n".join(violations)

# 上限回数を超えても修正しきれなかった場合は計画を中止する
if not dockerfile_ok:
    return f"❌ Failed to generate valid Dockerfile after {settings.MAX_RETRIES} attempts.\nErrors:\n{dockerfile_errors}"

ポイントは下記の3点です．

フィードバックの注入
generate_dockerfile の引数に dockerfile_errors を渡しています．1回目は空ですが，2回目以降は静的解析ツールの生のエラーログが入るため，AIは具体的にどこを直せばいいかを理解できます．
　
物理ファイルへの書き出し
静的解析ツール（Hadolint等）はファイルを対象に実行するため，生成するたびに (work_dir / "Dockerfile").write_text(...) で実際にファイルを保存するようにしています．
　
フェーズの分離
Dockerfile の生成が確定した後， template.yamlの生成（Phase 2）へ移る構成にすることで問題の切り分けを容易にしています．template.yamlではDockerfileのファイル名のみが必要になるので，独立した生成が可能です．そのため，LLｍのトークン利用数を抑えることができます．

また，同様のロジックを Phase 2（SAMテンプレート生成部）でも採用しており，ターゲットが lambda の場合のみ cfn-lint 等を用いたループが回るような設計になっています．

この実装で，ユーザーが待っている間に裏側で「AIが書いては怒られ，直してはまた怒られ……」という試行錯誤が行われ，最終的に生成品質の高いコードが出力されます．

4．動作確認

ここでは，実際に生成してみたときのログを確認してみます．

log

2025-12-07T19:28:26.769Z ... "name":"plan_deployment" ...

🔍 Planning deployment: https://github.com/kz-ow/test_repo [lambda]
🔐 Authenticated clone enabled for private repo.
📥 Cloning https://github.com/kz-ow/test_repo...
🧠 Analyzing source code...
🧐 Detected Stack: This is a Python application ...

(中略: AIがコードを解析中)

🤖 Generating & Auditing code...      <-- ここから生成＆監査フェーズ開始
   [1/2] Preparing Dockerfile...      <-- AIが Dockerfile を生成
     ✅ Dockerfile passed checks (Attempt 1)  <-- 静的ツール(Hadolint/Trivy)が監査し「合格」判定

(中略: 通信上のノイズなので無視)

     ✅ SAM Template passed checks (Attempt 1) <-- AIが SAMテンプレートを生成し、cfn-lintが監査し「合格」判定

実際に生成した後に静的ツールを通しているので，フィードバックは反映されているっっぽいです！（今回は，一回の生成でしっかりとしたファイルが生成されたのでエラーログを加味した生成は行われていません）.

5．おわりに

今回はDevOps-Agent開発 Vol.2として，AI⇔静的ツールでの自己修正ループを作成してみました．これまでは，ChatGPTやGeminiなどのAPIを使用し生成結果を参照するときに，チェックしなくてはならない点が多くありましたが，静的ツールをかませたことで作業負担を減らしかつ生成品質が向上することを知れてよかったです．Vol.3では，ついに AWS SAM を使用してデプロイ機能とリソース削除の自動化を実施しDevOps-Agentが完成します．興味のある方がいたらこちらも読んでみてください！最後まで読んでいただきありがとうございます！

6．参考文献

各種静的解析ツールのドキュメント(Hadolint/trivy/cfn-lint)

AWS SAMについて