AIエージェントが自走できるTerraformリポジトリ

Transcript

1. HARNESS ENGINEERING LT AIエージェントが自走できる Terraformリポジトリ 〜 conftest と最小権限で作るハーネス 〜 木暮 拓巳 / テイラー株式会社 · Tailor Platform SRE 2026
2. 01 · 自己紹介 自己紹介 ・ 木暮 拓巳（きぐれ たくみ） ・ テイラー株式会社 / Tailor Platform SRE ・ Headless ERP開発プラットフォームを作っている会社 － PS事業 = Tailor Platform を使ってクライアントの業務システムを開発する事業 ABOUT
3. 02 · 題材 THE REPO 題材: 各種infra/toolを管理する Terraform モノレポ ・ GitHub repo / Datadog / GCP / Tailor Platform のTerraformを 1レポで管理 - リソースの作成に承認ゲートを挟める 設定が１箇所にコード化されることで構成の把握や 別プロジェクトでの再利用がしやすい ・ 1ディレクトリ = 1 Terraform ワークスペース － tfstateやTerraformが実行可能な権限を管理する ・PR mergeで terraform apply 実行 ・リソースが欲しい人（担当者・PM）が 自分でPRを作る /terraform ├── datadog/ ├── github-a/ ├── github-b/ ├── gcp-a/ ├── gcp-b/ └── tailor-pf/
4. 03 · 課題 課題: SREレビューがボトルネック ・ 「監視モニター1個」「リポジトリ1個」のたびにSREレビュー待ち ・ プロジェクトは並行して複数走る。SREはスケールしない ・ さらに最近は AIエージェント（Claude Code）にPR作成を任せたい 人間の self-service とエージェントへの委任、必要な環境は同じだった 「レビューで担保する」から「仕組みで担保する」へ ? THE PROBLEM
5. 04 · 全体像 THE HARNESS ハーネスの全体像 エージェント（と人間）を取り囲む「モデルの外側の環境」 1 スキャフォールド 2 静的解析 3 フィードバック 4 最小権限の原則 5 CODEOWNERS workflow_dispatch で雛形一式を自動生成 conftest（OPA/Rego）+ tflint がポリシー違反を CI で弾く tfcmt が plan 結果を PR コメントで返す スコープを絞った API キー / トークンだけを渡す プロジェクトチーム＋ PM の承認でマージ可能
6. 05 · conftest とは WHAT IS CONFTEST conftest とは ・ 構造化された設定ファイルを ポリシーでテストする OSS ツール － https://www.conftest.dev/ （Open Policy Agent プロジェクト傘下） ・ 対象: Terraform (HCL) / YAML / JSON / Dockerfile など ・ ポリシーは Rego 言語で deny ルールとして書く → 違反があれば非 0終了 deny contains msg if { some label, instances in input.module some t in instances t.source == "../modules/github_team" object.get(t, "privacy", "") != "closed" msg := sprintf("module.%s: github_team must set privacy = \"closed\"", [label]) } conftest test --parser hcl2 -p policy *.tf を CI で実行するだけ
7. 06 · 工夫① conftest conftest — 暗黙知をコード化する SREの頭の中にあった規約を Rego のポリシーにして CI で強制: ・ 細かい命名規則 ・ Aの条件に一致したら、Bとセットでの定義が必須、等 [org] tailor_organization_folder.dev (name=dev) must have a tailor_organization_folder_ip_restriction (platform-planning#1297) 例外は policy/data/*.yaml に宣言的に管理。ポリシー自体にもユニットテスト 01 POLICY AS CODE
8. 07 · 工夫② 最小権限 02 LEAST PRIVILEGE 最小権限の原則 — 失敗のコストを環境側で下げる Datadog GitHub permission-scoped なロール + APIキーを配布 SREが許可した権限のみ実行可能な GitHub app tokenを配布 ✅ monitor / synthetics / RUM の編集 ❌ APIキー・ユーザー / ロール・org設定 ✅ repo作成やメンバーの招待 ❌ Organization levelリソース全般 壊せる範囲が限られている → レビューで全てを見なくてよい
9. 08 · フィードバックループ フィードバックループ PR作成 → conftest / tflint / tfcmt plan がPR上で返答 ↓ CI red なら エラーメッセージを読んで修正 → 再push（人間もエージェントも同じ） ↓ CI green なら PM・プロジェクトチームの承認でマージ → 自動apply ・ plan の差分・ポリシー違反が 全部PRコメントに現れる = エージェントが読める ・ CODEOWNERS は PM＋プロジェクトチーム＋SRE の co-owner 制 － SREの承認を待たずにマージできる（SREも見られるが必須ではない） THE LOOP
10. 09 · エージェントに渡す エージェントに渡す ・ CLAUDE.md: リポジトリ構造・命名規約・CIの仕組みを記述 ・ スキル（定型手順の文書化）: － /github-manage — orgメンバー追加・チーム・リポジトリ管理 － /create-otlp-exporter — Datadogのintegration設定の追加 ・ Claude Code が対象ファイルを特定 → 編集 → PR作成まで自走 ・ conftest に落ちたら エラーメッセージを読んで自分で直す HANDOFF
11. 10 · 気づき ハーネスは SRE の仕事と地続きだった ! THE INSIGHT ・ 人間の self-service のために作った環境が、ほぼそのままエージェントのハーネスとして機能した ・ guardrails / policy as code / least privilege… 全部昔からあるSREの道具 ・ ただし、エージェント時代に「勘所」が変わった点: － エラーメッセージの説明性 — 理由・チケット番号まで書くと背景情報を含めて理解させられる － 手順の文書化（スキル化） — 口伝をやめると委任できる － フィードバックの機械可読性— PRコメントに集約するとエージェントが読みやすい コンテキストを如何にして上手に渡せるかが重要！
12. 11 · まとめ WRAP-UP まとめ conftest 暗黙知をコード化し、説明的なエラーで返す 最小権限 失敗のコストを環境側で下げる tfcmt / CI フィードバックを PR 上に集約する ハーネスエンジニアリングは DevOps / SRE 文化と地続き 失敗を防ぐのではなく、失敗しても壊れにくい環境を作る