Conversation
|
|
||
| こんにちは、棚井龍之介です。本記事は [Terraform 連載 2026](/articles/20260518a/) の5本目です。 | ||
|
|
||
| Terraform のコードを Claude Code をはじめとした生成 AI に書かせる場面が、現場でも増えているのではないかと想像しています。私自身は Terraform からしばらく離れていますが、「VPC と RDS と CloudTrail を組んでほしい」と自然言語で頼めば、`.tf` ファイル一式が数秒で出てくる、というのは想像に難くありません。公式ドキュメントを開く時間より、AI に質問して出力を読む時間のほうが長い、というエンジニアも珍しくないでしょう。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "と" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "と"
- "と"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| そこで気になるのは、どうやってレビューするのか、という点です。 | ||
|
|
||
| 人間のレビュアーは完璧ではありませんし、そもそもインフラ規模の拡大に対してレビュアー数は増えてくれません。`Action = "*"` の IAM ポリシー、`publicly_accessible = true` の RDS、`encrypted = false` の EBS といった、人間が忘れがちなパターンや見落としがちな書き間違いを、AI は平然と書き上げてしまいます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "は" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "は"
- "は"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| 人間のレビュアーは完璧ではありませんし、そもそもインフラ規模の拡大に対してレビュアー数は増えてくれません。`Action = "*"` の IAM ポリシー、`publicly_accessible = true` の RDS、`encrypted = false` の EBS といった、人間が忘れがちなパターンや見落としがちな書き間違いを、AI は平然と書き上げてしまいます。 | ||
|
|
||
| 以前に執筆した記事([Claude Code 経由で AWS にアクセスする際の IAM ガードレール](https://future-architect.github.io/articles/20260525a/))では、AI エージェント自体が AWS にアクセスする時の「IAM ガードレール」について書きました。今回はその近接領域で、AI が Terraform コードを書いた後に、そのコード自体をどうチェックするのかを考えてみました。人間がレビューに入る前に機械的に弾く、シフトレフトされたガードレールをどう作るかという話です。なお本記事における「シフトレフト」は、コードレビュー前の段階に機械的チェックを前倒しで仕掛けることを指します。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "に" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "に"
- "に"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| `.rego` ファイル自体が Git で管理されていれば、「いつ、誰が、どんなチェックを追加したか」もすべて履歴として残ります。チェックそのものが履歴管理される形になり、冒頭で引用した「追跡可能・監査可能」という要件にも自然と応えられます。 | ||
|
|
||
| 「広く拾う」trivy / checkov と「狭く明示する」conftest という二段構えが、今回の検証から見えた運用上の落としどころです。組み込みルールのツールと自作ルールのツールを併用するパターン自体は PaC を扱う場面でしばしば語られる構成で、今回の検証でも実感としてそこに着地しました。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "で" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "で"
- "で"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
…し、追跡可能なガードレールへ.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
No description provided.