メインコンテンツへスキップ

修復の操作方法

Terraform PR エージェントを接続すると、エージェントは対応可能な DoiT シグナルに応答して pull request を作成します。修復用 pull request は DoiT コンソールではなく、GitHub で作成・レビューされます。

エージェントは、リポジトリ内のプロバイダーのバージョンに合わせて修復内容を調整するために、Terraform 依存関係ロックファイル（.terraform.lock.hcl）と、任意で指定されている required_providers のバージョン制約を使用します。これにより、サポートされているリソースフィールドを選択し、バージョン特有のバグや注意点に対する既知のワークアラウンドを適用できます。

エージェントが正確なプロバイダーバージョンを解決し、より精度の高い変更を生成できるよう、.terraform.lock.hcl をリポジトリにコミットしてください。

エージェントのトリガー方法​

早期アクセス期間中、DoiT は対応可能な Composer Insight を選択し、DoiT の Trigger automated IaC remediation for an insight アクションを呼び出す CloudFlow を提供します。エージェントは、スケジュールや Integrations カタログからのオンデマンドでは実行されません。CloudFlow を使わないネイティブな Insights トリガーは、今後のリリースで提供予定です。

代表的な提供フローは次のとおりです。

  1. 開始します（例: Manually start トリガーを使用）。

  2. List insights を実行し、続けて Filter on List insights を実行して、どの Insights を修復するかを選択します。

  3. List resource results for an insight を実行し、影響を受けるクラウドリソース ID を収集します。

  4. LLM ノードを使用して、エージェント向けの修復ガイダンスを整形します。

  5. Cloud Intelligence ノード で Trigger automated IaC remediation for an insight を呼び出し、エージェントを起動します。

同じ最後の 2 ステップは Composer Insights に対しても使用できます。List recipes を実行し、必要に応じてアクティブな結果を持つレシピにフィルターしたうえで、List recipe findings を実行して、影響を受けるリソースを収集します。

この最終アクションには、トリガー元（CloudFlow と Insight）と、クラウドプロバイダー、Insight の柱（例: コストまたはセキュリティ）、影響を受けるリソース ID、修復テキスト、および任意でリソースごとの推定コスト削減額を含むシグナルペイロードが必要です。提供されるフローでは、これらの値は上流のノードから渡されます。

エージェントが、接続済みの GitHub リポジトリ内の Terraform コードにターゲットリソースをマッピングできない場合、そのリソースはスキップされます。ターゲットリソースを 1 つもマッピングできない場合、pull request は作成されません。

エンドツーエンドのフロー​

  1. シグナルの検出: 影響を受けるクラウドリソースを含む Insight が CloudFlow 経由でエージェントに渡されます。

  2. リソースのマッピング: エージェントが、接続されている Terraform（HCL）コードベースを検索し、それらのリソースが定義されている場所を特定します。

  3. コード生成: エージェントが、推奨される修復を実装するための最小限の Terraform 変更を生成し、既存のコードスタイルや設定済みのガードレールを尊重します。

  4. ローカル検証: pull request を作成する前に、エージェントは提案された変更に対してローカルチェックを実行します。これには、terraform fmt、tflint、trivy、およびリポジトリに Checkov 設定が存在する場合は checkov が含まれます。

  5. pull request の作成: エージェントは、対象リポジトリ内の専用ブランチ上に pull request を作成します（同じ Insight に対して既に修復用ブランチが存在する場合は、そのブランチを更新します）。修復が複数のリポジトリにまたがる場合、エージェントはリポジトリごとに 1 つの pull request を作成します。Terraform モジュールの依存関係がリポジトリ間に存在する場合、エージェントは依存関係の順序（まずプロバイダー側のリポジトリ、次にそのモジュールを利用するリポジトリ）で pull request を作成し、各 PR にマージ順のメモを含めます。

  6. レビューとマージ: チームは GitHub 上で pull request をレビューし、通常の変更管理プロセスに従ってマージします。マージ後は、通常のデプロイパイプラインが Terraform の変更を適用します。

修復用 pull request の見つけ方​

次の条件を満たす pull request を探してください。

  • リポジトリのデフォルトブランチをターゲットにしている
  • doit/iac-remediation/ ブランチから作成されている
  • タイトルが [IaC] で始まっている

pull request をレビューする​

各修復用 pull request には、レビューの際に役立つコンテキストが含まれます。

セクション確認内容
理由（"Why"）シグナルの内容と、なぜこれらの変更がシグナルに対応するのかを説明します。
提案された変更（"What changed"）エージェントが行った HCL コードの変更内容を要約します。複数リポジトリにまたがる修復では、各 pull request には、そのリポジトリ内の変更範囲に限定した AI 生成のサマリーが含まれ、バッチ全体の概要ではありません。
実装の正当性（"Why this way"）なぜエージェントが複数の実装方法のうちこの方法を選択したのかを説明します。PR レビュー担当者を支援するための情報です。
マージ順序同一の修復内で、リポジトリ間に Terraform モジュール依存関係が存在する場合、この pull request が推奨されるマージシーケンスの中でどの位置にあるかを示します。依存関係が検出された複数リポジトリ修復でのみ表示されます。
対象リソース（"Scope"）この PR によって変更されるリソースを参照します。
兄弟 PR（"Part of remediation"）同じ修復バッチ内の他の pull request をリンク付きで一覧表示し、リポジトリをまたいだ変更全体をたどれるようにします。複数リポジトリ修復でのみ表示されます。
コストコンテキストとリスク評価（"Tradeoffs and impact"）依存関係への影響や、潜在的なダウンタイムを強調します。コスト削減データが利用可能な場合は、その修復による推定コスト削減額の合計を表示します。トリガーにリソースごとの推定コスト削減額が含まれている場合、この pull request によってカバーされる削減額と、影響が大きいリソース（最大 5 件）のリソース単位の内訳も表示します。複数リポジトリ修復では、各 pull request は自分がカバーするリソースと削減額のみを表示します。
注意

修復用コードは AI によって生成されます。マージする前に、提案された変更が環境にとって正しく安全であることを必ず確認してください。

エージェントが修復用 pull request を作成した後、@doit を含むレビューコメントを残すことで、後続のイテレーションを指示できます。@doit を含まないコメントは取得されません。

エージェントが同じ修復ブランチで再実行されると、@doit コメントを収集し、自動ボットメッセージや短いリアクションを除外したうえで、残りのフィードバックを修復計画に反映します。たとえば「特定の環境のみに変更を限定したい」といった調整要求や、確認のための質問、提案された変更に関する問題の指摘を行うことができます。

承認・マージ・却下​

修復用 pull request は、リポジトリに設定されている必須承認やステータスチェックを含む、通常の GitHub レビュープロセスを通じてマージしてください。エージェントが pull request を自動的にマージすることはありません。

  • Merged: マージ後、通常のデプロイパイプラインが Terraform の変更を適用します。エージェントはロールバックを管理しません。

  • Closed without merge: インフラストラクチャには変更が適用されません。元の Insight は DoiT 上に残り、チームが引き続き調査したり、別の手段で対処したりできます。

修復がモジュール依存関係を持つ複数のリポジトリにまたがる場合は、コンシューマー側リポジトリの pull request より前に、プロバイダー側リポジトリの pull request をマージしてください。各 pull request に記載されたマージ順のメモが、推奨される順序を示します。

エージェントが行わないこと​

  • クラウド環境へアクセスしたり、terraform apply を実行したりすること。

  • Terraform state backend の読み書き。

  • 強制 push やブランチ保護ルールの迂回。

  • 同じ Insight と同じリソースに対して、すでにオープンな修復ブランチが存在する場合に、重複する pull request を作成すること（既存ブランチが更新されます）。

  • 接続されたリポジトリ内で Terraform によって管理されていないリソースの修復。

に最終更新