インフラの設定ファイル（Terraform 等）の変更差分を、社内のセキュリティ基準に照らしてマージの前に判定し、公開範囲・暗号化・権限の指摘を返す

処理の起点を決める

プルリクエストが開かれたとき、更新されたとき、開き直されたときに動かします。 GitHub Actions の pull_request のイベントは、既定でこの3つ（opened、synchronize、reopened）で動きます。paths の指定で、設定ファイルのディレクトリが変わったときだけに絞ります。 アプリのコードだけの変更で動かすと、毎回空の判定が返ります。

更新のたびに、レビューを作り直します。 指摘を受けて開発のチームが直すと、新しい変更の計画でもう一度判定します。前のレビューの指摘が直ったかを、新しいレビューの冒頭に並べます。

フォークからのプルリクエストでは動きません。 フォークから動いたワークフローには、GITHUB_TOKEN 以外のシークレットが渡されず、GITHUB_TOKEN も読み取りだけになるとされています。Claude API の鍵はシークレットに置くため、この構成は社内のリポジトリのプルリクエストだけを対象にします。 外部からの貢献を受けるリポジトリでは、人がレビューします。

入力データを集める

質を決めるのは、下の2つです。 基準の条項の一覧には、条項ごとに「規則で判定できるか」の列を持たせます。 規則で判定できる条項はプログラムが受け持ち、そうでない条項だけがAIへの指示に入ります。

例外の承認の一覧には、対象のリソースの address を入れておきます。 名前やリソースの種類だけで承認を書くと、同じ種類の別のリソースにまで例外が広がって見えます。 期限も必ず入れ、期限切れの例外は無いものとして扱います。

プルリクエストの説明を入れるのは、権限の広さを判断するためです。 「バッチが毎晩このストレージに書き込むため」と書かれていれば、書き込みの権限が要る理由が分かります。説明が空のプルリクエストでは、権限の判定が needs_info になりやすくなります。

データの取得方法を決める

変更の計画は、GitHub Actions の中で作ります。 terraform plan で計画のファイルを書き出し、terraform show -json でJSONにします。この計画のファイルとJSONは、ワークフローの成果物として外に残さない設定にします。 機密の値が含まれるためです。

after_unknown を見落とさないでください。 適用するまで値が決まらない項目は、after に値が入らず、after_unknown に印が付きます。その項目を「設定されていない」と読むと、暗号化の鍵が後で決まるだけのリソースを「暗号化が無い」と指摘します。 印の付いた項目は、判定を unknown_until_apply にして、人に回します。

置き換えになるリソースも、ここで拾います。 actions が delete と create の組になっているリソースは、一度消えてから作り直されます。データを持つリソースが置き換えになると、中身が失われることがあります。 セキュリティの条項とは別に、レビューの冒頭に必ず示します。

基準の条項と例外の一覧は、レビューのプログラムと同じリポジトリに置きます。 一覧の変更もプルリクエストで受けるので、誰がいつ基準や例外を変えたかが、変更の履歴として残ります。

AIへ渡す前に整形する

1. 変更のあるリソースの取り出し … actions が no-op のリソースは除きます
2. 機密の値の伏せ … before_sensitive と after_sensitive で印の付いた値を、"***" に置き換えます
3. 値の伏せの二重確認 … 鍵や証明書に見える文字列が残っていないかを、パターンで探して伏せます
4. 規則の判定 … 規則で判定できる条項を、プログラムで当てます
5. 例外の当て … 規則に当たったリソースが、例外の承認の一覧にあり期限内なら「例外承認済み」とします
6. AIに渡す範囲の決定 … 規則で判定できない条項に関係するリソースの種類（権限、公開の設定など）だけを残します
7. 大きさの確認 … 残ったリソースが多いときは、リソースごとに分けてAIに渡します

2番目と3番目を、両方とも行います。 機密の印は、設定ファイルで機密と宣言されていない値には付きません。印だけに頼ると、宣言を忘れた値がそのままAIに渡ります。

5番目で例外を当てるのは、プログラムの側です。 例外の承認の範囲に入っているかを、address と期限で機械的に判定します。AIには、承認の文言の範囲を超えていないかという、文脈の要る判断だけを残します。

AIに処理させる

させるのは、規則で判定できない条項について、変更のあるリソースごとに判定し、指摘と直し方の案を書くことです。

最後の行が、指摘の質を揃える要です。 AIは、基準に書かれていない一般的なよい慣行まで指摘します。条項番号の無い指摘をプログラムで落とすと、指摘はすべて社内の基準に基づくものになります。 担当によって指摘が違う、という課題はここで解きます。

指示内容を固定する

あなたはクラウドのインフラのセキュリティのレビュー担当です。
Terraform の変更の計画のうち、規則で判定できなかったリソースを、
社内のセキュリティ基準の条項に照らして判定してください。

【判定すること】リソースごとに、関係する条項それぞれについて
- verdict:
  - compliant ..... 条項の要件を満たしている
  - violation ..... 条項の要件を満たしていない
  - exception_ok .. 例外の承認の文言の範囲に収まっている
  - needs_info .... 説明や値が足りず判断できない
- finding: 何が問題かを1〜2文で
- suggestion: 直し方の案を、設定の項目名を挙げて1〜2文で

【厳守事項】
- 判定には、必ず【基準の条項】の条項番号を付けてください。
  条項に無い観点での指摘はしないでください。
- "***" は伏せた値です。中身を推測しないでください。
- after_unknown が true の項目は、値が無いと扱わず needs_info にしてください。
- 例外の承認は、文言に書かれた範囲だけを認めてください。
  対象や操作が文言より広ければ violation です。
- 迷ったときは compliant を選ばず、needs_info にしてください。
- 承認やマージについて書かないでください。

【基準の条項】{policy_clauses}
【例外の承認】{exceptions}
【プルリクエストの説明】{pr_description}
【変更のあるリソース】{resource_changes_masked}

「after_unknown を値が無いと扱わない」を明記しないと、誤った指摘が最も多く出ます。 適用するまで決まらない値は、JSONでは空に見えます。AIはそれを「設定されていない」と読みます。

「例外の承認は、文言に書かれた範囲だけ」は、例外の広がりを止めるための指示です。 「読み取りの権限を例外として許可」という承認に対して、書き込みの権限を足す変更を exception_ok にさせないためです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "address": "",
  "action": "create | update | delete | replace",
  "findings": [
    {
      "clause_id": "",
      "verdict": "compliant | violation | exception_ok | needs_info",
      "finding": "",
      "suggestion": "",
      "exception_id": ""
    }
  ]
}

1つ目の理由は、規則の判定とAIの判定を同じ形にそろえられることです。 プログラムの規則の結果も、clause_id と verdict を持つ同じ形の行にします。レビューのコメントには、どちらの判定かを「規則」「AI」の印で示します。

2つ目は、チェックの成否を規則で決められることです。

AIの violation だけではチェックを失敗にしません。 AIの判定は誤ることがあり、誤った失敗でマージが止まると、開発のチームはこの仕組みを信用しなくなります。 AIの指摘は注意として示し、担当が読んで差し戻すかを決めます。

3つ目は、clause_id の無い指摘をプログラムで落とせることです。 条項の一覧に無い番号が返ってきたときも、同じく落とします。

プルリクエストに返すレビューの本文は、次のような形にします。

【セキュリティ基準のチェック】結果：注意（規則の違反なし）
基準の一覧：policy/clauses.yaml @ 3f2a1c9　例外の一覧：@ 3f2a1c9

【規則】
 - storage.logs_bucket　SEC-07 暗号化 …… compliant
 - network.app_sg　SEC-12 管理用ポートの開放 …… exception_ok（EX-2026-031、期限 2026-12-31）

【AI】
 - iam.batch_writer　SEC-21 権限は必要な操作とリソースに限る …… violation
   指摘：書き込みの対象がすべてのストレージになっている
   直し方の案：対象のリソースを、説明にある1つのストレージに限る

【適用するまで決まらない値】 1件（kms_key の参照）
【置き換えになるリソース】 なし

冒頭に、判定に使った一覧の版を必ず載せます。 一覧が後から変わっても、このレビューがどの基準で出されたかを、プルリクエストの上で確かめられます。

システムへ連携する

レビューは、event を COMMENT にして返します。 このAPIの event には APPROVE、REQUEST_CHANGES、COMMENT があり、APPROVE は使いません。 承認は人が行うためです。指摘はリソースごとに comments の配列に入れ、path と line で設定ファイルの該当行に付けます。

指摘は1回のレビューにまとめて返します。 このAPIで短い間に多くの投稿をすると、二次的な利用の制限にかかることがあるとされています。指摘ごとに別々に投稿せず、1回の実行で1つのレビューにします。

クラウドの環境には、この仕組みからは何も適用しません。 terraform apply は、従来どおりマージの後の手順で人が承認して行います。

人が確認する

承認するか差し戻すかは、すべてセキュリティの担当が決めます。

1. チェックが失敗のものを先に見る … 規則に当たった変更です。多くは直してもらえば済みます
2. 注意のあるものを見る … AIの violation と needs_info です。指摘が条項に合っているかを、変更の計画を開いて確かめます
3. unknown_until_apply の項目を見る … 適用するまで値が決まらない項目で、適用の後に確かめる必要があるかを決めます
4. 成功のものは要点だけを見る … 変わるリソースの一覧と、置き換えの有無だけを確かめて承認します
5. AIの判定を覆したら記録する … どの条項の判定を、なぜ覆したかを残します

2番目を省かないでください。 AIの指摘は、条項番号が付いていても、条項の読み方を誤っていることがあります。 誤った指摘のまま差し戻すと、開発のチームに無駄な修正をさせます。

目標は、160件をならして1件6分です。 成功のものは1〜2分で、注意のあるものは指摘の確認で10分前後かかります。

例外に対処する

上から5行目のとき、規則の判定は必ず返します。 AIが止まっても、言い切れる条項の見落としは起きないようにします。

記録を残す

• プルリクエストの番号と、判定した時点のコミット
• 判定に使った基準の条項の一覧と例外の一覧の版（同じリポジトリのコミット）
• 規則の判定とAIの判定の全体（伏せた後の入力と、返ったJSON）
• 返したレビュー
• 担当が判定を覆した記録
• 伏せる前の変更の計画は残さない

最後の行は、意図して残さないものです。 機密の値を含む計画をログに残すと、ログそのものが漏えいの経路になります。

担当が覆した記録は、規則とAIへの指示の両方を直す材料になります。 同じ条項でAIの violation が覆され続けるなら、その条項は規則で書けるか、条項の書き方が曖昧かのどちらかです。