Kiro時代のIaC設計：AI生成コードを「人間がレビューしやすく」

なぜ「可読性」がAI開発で重要なのか？

Kiroを使えば、複雑なロジックも瞬時にコード化されます。
しかし、AIに任せてばかりでいると、時として人間には理解しがたい複雑なコードを生成する可能性があります。
例えば、ネストされた 「!If」 関数を生成することがあり、可読性や保守性を低下させることがあります。
質の良いレビューや運用を維持するためにも「一目で構成が理解できるコード」が大切になってきます。
可読性が低いと、以下のようなリスクが生じます。
・レビュー漏れ : 複雑なネストの中に潜む設定ミスを見逃す
・確認コストの増大 : 期待通りの動作をするか、コードのカッコを数えながら解読する羽目になる
・メンテナンスの破綻 : 後から条件を追加した際、どこまでが既存の影響範囲か判断できなくなる

検証シナリオ：複雑な分岐条件

以下の3つのパラメータを組み合わせたALB構成を例に、設計の差を見てみましょう。
ALB台数 : 1台 または 2台
トラストストア(mTLS認証)利用(TS) : 有 または 無
ターゲットグループ(TG)の選択 : TSが有であればTG-A、無ならTG-B

【リソース作成マトリクス】
このパラメータ群から、人間が確認すべき「4つの完成図」を定義します。

避けるべき「!If」埋め込みパターン（レビュー困難）

一つのリソース内で全てを完結させようとすると、プロパティの中にロジックが埋もれてしまいます。
レビュー担当者は「今のパラメータ設定だと、結局どのプロパティが有効なのか？」を、45行目や53行目の論理式を頭の中で解いて確認しなければなりません。
これが「レビューの疲れ」と「見落とし」に繋がり、結果としてシステム障害に繋がる可能性があります。
・行数 44-49：MutualAuthentication（トラストストア設定）を出すかどうかを 「!If」で判定
・行数 53：TargetGroupArn（送り先）を A か B か 「!If」で判定

※補足：「!If」関数とは？
「もしAならB、そうでなければC」という条件分岐を実現するための組み込み関数
!If [ 条件名, 真（true）の時の値, 偽（false）の時の値 ]

01 | # ------------------------------------------------------------
02 | # 1. パラメータ定義
03 | # ------------------------------------------------------------
04 | Parameters:
05 | Alb2Enabled:
06 | Type: String
07 | AllowedValues: ["true", "false"]
08 | Default: "false"
09 | Alb1TsEnabled:
10 | Type: String
11 | AllowedValues: ["true", "false"]
12 | Default: "false"
13 | Alb2TsEnabled:
14 | Type: String
15 | AllowedValues: ["true", "false"]
16 | Default: "false"
17 | TgA:
18 | Type: String
19 | TgB:
20 | Type: String
21 | MyTrustStore:
22 | Type: String
23 | 
24 | # ------------------------------------------------------------
25 | # 2. コンディション定義
26 | # ------------------------------------------------------------
27 | Conditions:
28 | # リソース自体の有無を判定する条件のみ定義
29 | IsAlb2Enabled: !Equals [ !Ref Alb2Enabled, "true" ]
30 | 
31 | # ------------------------------------------------------------
32 | # 3. リソース定義（!Ifによる内部分岐）
33 | # ------------------------------------------------------------
34 | Resources:
35 | 
36 | # --- ALB1用リスナー：内部でTSの有無を判定 ---
37 | Listener1:
38 | Type: AWS::ElasticLoadBalancingV2::Listener
39 | Properties:
40 | LoadBalancerArn: !Ref Alb1
41 | Port: 443
42 | Protocol: HTTPS
43 | # ⚠️ 構造の分岐：TSありなら設定、なしなら項目ごと削除(NoValue)
44 | MutualAuthentication:
45 | !If 
46 | - !Equals [ !Ref Alb1TsEnabled, "true" ]
47 | - Mode: "verify"
48 | TrustStoreArn: !Ref MyTrustStore
49 | - !Ref "AWS::NoValue"
50 | DefaultActions:
51 | - Type: forward
52 | # ⚠️ 値の分岐：TSありならTG-A、なしならTG-B
53 | TargetGroupArn: !If [ !Equals [ !Ref Alb1TsEnabled, "true" ], !Ref TgA, !Ref TgB ]
54 | 
55 | # --- ALB2用リスナー：Conditionでリソース作成を制御しつつ、内部はIf分岐 ---
56 | Listener2:
57 | Type: AWS::ElasticLoadBalancingV2::Listener
58 | Condition: IsAlb2Enabled
59 | Properties:
60 | LoadBalancerArn: !Ref Alb2
61 | Port: 443
62 | Protocol: HTTPS
63 | # ⚠️ 1台目と同じIfロジックを繰り返す必要がある
64 | MutualAuthentication:
65 | !If 
66 | - !Equals [ !Ref Alb2TsEnabled, "true" ]
67 | - Mode: "verify"
68 | TrustStoreArn: !Ref MyTrustStore
69 | - !Ref "AWS::NoValue"
70 | DefaultActions:
71 | - Type: forward
72 | TargetGroupArn: !If [ !Equals [ !Ref Alb2TsEnabled, "true" ], !Ref TgA, !Ref TgB ]

推奨：Conditionによる「リソース分離」パターン（可読性重視）

あらかじめConditionでパターンを定義（31-48行目）し、リソース側は「固定値」のみで記述します。
「どのリソースが有効か」が決まった時点で、その中身（設定値）が決定します。
例えば 「L1WithTs」（68行目）がデプロイされているなら、それは確実に「トラストストアあり、宛先はTG-A」の設定であることを即座に確認できます。
・行数 31-48：パラメータの組み合わせ（ALB台数 × TS有無）に、「IsAlb2Ts」などの分かりやすい名前を付与
・行数 68-80（L1WithTs）：TS有の「完成品」です。プロパティ内には 「!If」 が1つもなく分岐を考慮しなくて良い

※補足：「Condition」とは？
「特定のリソースを作成するかどうか」や「どの設計図を適用するか」を制御する論理フラグ
　Conditions:
　　IsProd: !Equals [ !Ref Env, "prod" ] # 論理（ロジック）
　Resources:
　　ProdRes:
　　　Condition: IsProd # prodであればこのブロックのResources:を作成

01 | # ------------------------------------------------------------
02 | # 1. パラメータ定義
03 | # ------------------------------------------------------------
04 | Parameters:
05 | Alb2Enabled:
06 | Type: String
07 | AllowedValues: ["true", "false"]
08 | Default: "false"
09 | Alb1TsEnabled:
10 | Type: String
11 | AllowedValues: ["true", "false"]
12 | Default: "false"
13 | Alb2TsEnabled:
14 | Type: String
15 | AllowedValues: ["true", "false"]
16 | Default: "false"
17 | TgA:
18 | Type: String
19 | Description: "Target Group for mTLS (TS enabled)"
20 | TgB:
21 | Type: String
22 | Description: "Target Group for Standard (TS disabled)"
23 | MyTrustStore:
24 | Type: String
25 | Description: "Trust Store ARN"
26 | 
27 | # ------------------------------------------------------------
28 | # 2. コンディション定義（A, B, C, Dのパターンを名前で整理）
29 | # ------------------------------------------------------------
30 | Conditions:
31 | # パターンA: 1台目・TSなし
32 | IsAlb1NoTs: !Equals [ !Ref Alb1TsEnabled, "false" ]
33 | 
34 | # パターンB: 1台目・TSあり
35 | IsAlb1Ts: !Equals [ !Ref Alb1TsEnabled, "true" ]
36 | 
37 | # 2台目自体の作成判定
38 | IsAlb2Enabled: !Equals [ !Ref Alb2Enabled, "true" ]
39 | 
40 | # パターンC: 2台目有効 かつ TSなし
41 | IsAlb2NoTs: !And 
42 | - !Condition IsAlb2Enabled
43 | - !Equals [ !Ref Alb2TsEnabled, "false" ]
44 | 
45 | # パターンD: 2台目有効 かつ TSあり
46 | IsAlb2Ts: !And 
47 | - !Condition IsAlb2Enabled
48 | - !Equals [ !Ref Alb2TsEnabled, "true" ]
49 | 
50 | # ------------------------------------------------------------
51 | # 3. リソース定義（完成品の出し分け）
52 | # ------------------------------------------------------------
53 | Resources:
54 | 
55 | # --- 【パターンA】1台目 ALB：トラストストアなし ---
56 | L1Standard:
57 | Type: AWS::ElasticLoadBalancingV2::Listener
58 | Condition: IsAlb1NoTs
59 | Properties:
60 | LoadBalancerArn: !Ref Alb1
61 | Port: 443
62 | Protocol: HTTPS
63 | DefaultActions:
64 | - Type: forward
65 | TargetGroupArn: !Ref TgB # TSなしなのでTG-B固定
66 | 
67 | # --- 【パターンB】1台目 ALB：トラストストアあり ---
68 | L1WithTs:
69 | Type: AWS::ElasticLoadBalancingV2::Listener
70 | Condition: IsAlb1Ts
71 | Properties:
72 | LoadBalancerArn: !Ref Alb1
73 | Port: 443
74 | Protocol: HTTPS
75 | MutualAuthentication:
76 | Mode: "verify"
77 | TrustStoreArn: !Ref MyTrustStore
78 | DefaultActions:
79 | - Type: forward
80 | TargetGroupArn: !Ref TgA # TSありなのでTG-A固定
81 | 
82 | # --- 【パターンC】2台目 ALB：トラストストアなし ---
83 | L2Standard:
84 | Type: AWS::ElasticLoadBalancingV2::Listener
85 | Condition: IsAlb2NoTs
86 | Properties:
87 | LoadBalancerArn: !Ref Alb2
88 | Port: 443
89 | Protocol: HTTPS
90 | DefaultActions:
91 | - Type: forward
92 | TargetGroupArn: !Ref TgB # TSなしなのでTG-B固定
93 | 
94 | # --- 【パターンD】2台目 ALB：トラストストアあり ---
95 | L2WithTs:
96 | Type: AWS::ElasticLoadBalancingV2::Listener
97 | Condition: IsAlb2Ts
98 | Properties:
99 | LoadBalancerArn: !Ref Alb2
100| Port: 443
101| Protocol: HTTPS
102| MutualAuthentication:
103| Mode: "verify"
104| TrustStoreArn: !Ref MyTrustStore
105| DefaultActions:
106| - Type: forward
107| TargetGroupArn: !Ref TgA # TSありなのでTG-A固定

「Condition分離」を推奨する理由

プロパティ内が 「!If」 ではなく固定値で書かれているため、レビュー時に迷いがありません。
「この条件の時はこの設定になる」という確信を持って承認できます。
「新しいパラメータを追加して」と頼んだ際、分離された構造であれば、既存の正常に動いているリソースを書き換えることがありません。
新しいブロックを追加することになるため、人間も確認しやすくなります。
また、「2台目の設定だけが反映されない」といったトラブル時も、原因が 「Conditionの論理式にあるのか」それとも「リソース定義にあるのか」を即座に切り分けられます。

Kiroを使いこなすための「確認力」

Kiroは最高のアシスタントですが、最終的な品質を担保するのはあなたです。
AIに効率よくコードを書かせつつ、人間がその正当性を判断できる状態を作ることが大切です。
そのためにも、生成AIに任せっきりではなく、「Conditionを使ってリソースを分ける」ことが、IaC設計への大切な考え方の1つになります。

次回は、人間がレビューしやすくなるようなコードを生成するための「Steering」について記載したいと思います！