LLM × 多層レビューでSDLCを自動化、SKILLSを増やせば成果物の粒度は上がる？ — 半分は誤解です

TL;DR

• 「要件 → 設計 → 実装 → テスト → リリース」の各ゲートに専門ロール LLM (SKILL) を配置する多層レビュー構想は、機械チェック可能な領域では確かに強い。
• ただし 「SKILLS を増やすほど成果物の粒度が上がる」は半分しか正しくない。
• 伸びない領域は次の 4 つに整理できる。
  • Grounding ギャップ— SKILL は前提を発明できない
  • 意見の非収束— レビュアーが増えるほど判断コストが上がる
  • 静的レビュー ≠ 実行時正しさ— レビューで OK でも本番で落ちる
  • 上流誤りの下流合理化— SKILL は整合性を取りに行くので前提誤りを増幅する
• 本当のレバレッジは SKILLS の枚数ではなく「何を入力に渡すか × どう判定するか」にある。

想定する構想

私が想像するLLMを活用した最強のアーキテクチャです！！

「専門 SKILLS を厚くすればするほど、品質・セキュリティ・信頼性が上がる」というのが基本仮説で一気通貫型の基盤を作って日々奮闘してました。

ですが、この画像をClaudCodeに見せ、ClaudCodeで生成しているツールが今どういう状況か、この考え方が正しい方向性なのか？と問うた時...

ClaudCodeはこんなことを言いました。

「半分正しいが、半分誤解している」....と！！

私はこの反論が来たとき、嬉しさのあまり脳汁が飛び散りそうでした。
LLMはここまで来たかっ...と!!

さて。。。ここからは本題です。この考え方がなぜ「半分正しいが、半分誤解している」のか解説していきます。

✓ 効く領域: 「機械チェックに翻訳可能なもの」

ここは SKILL を厚くした分だけ素直に検出粒度が上がる領域です。

これらは「LLM が判定するまでもなく、ツールが決定論的に pass/fail を出せる」もの。

ここに SKILL を追加するのは効きます。例えば「コンプライアンス SKILL」を増やすと、PCI / HIPAA / 個人情報保護法ごとの追加ルールセットがオーケストレーションされる、というのは現実的。

問題はここから先。

✗ 伸びない 4 領域

① Grounding ギャップ — SKILL は前提を発明できない

LLM SKILL は与えられた前提に対するレビュアーであって、現場固有の前提を生成する人ではありません。

例えば、ある AWS 構築案件で次のような事情があったとします。

• 顧客の既存 VPC は東京リージョンに /16 が 2 つ、すでに VPC Peering 済み
• SCP で

  ap-northeast-1

  以外の作成は禁止
• IAM Identity Center で SAML 連携済み、Permission Set は既定の 12 セット
• 半年前にコスト超過で経理から「予算アラート 50 万 / 月」をハード要件として申し渡された
• 監視は Datadog で統一、CloudWatch アラームは Datadog 側に Forward する規約

これらが入力に入っていないまま、要件 SKILL → 設計 SKILL → 実装 SKILL を回しても、「新規 VPC を作ろう」「マルチリージョン構成にしよう」「CloudWatch Alarm でメール通知しよう」という現場と齟齬のある成果物が淀みなく出てきます。

「現場と整合性が取れているように見える出力」が一番危ない。レビュアーが多いほど、その出力は

自信を持って提示される。

これは SKILL の枚数では解決しません。入力の grounding(現場固有情報の差し込み) がボトルネックです。

② 意見の非収束 — レビュアーが増えるほど判断コストが上がる

専門 SKILL を増やすと、当然のように衝突する推奨が出ます。

セキュリティ SKILL:  「S3 は KMS CMK 必須」
コスト SKILL:        「KMS CMK は月額 1USD/key × n、SSE-S3 で十分」
コンプライアンス SKILL: 「PCI DSS 範囲なら CMK 必須」
パフォーマンス SKILL:  「KMS は API 制限あり、ホットパスでは注意」

オーケストレーター LLM はこれを統合しなければなりませんが、現実には「プロジェクトの文脈による」「両論併記」になりがち。最終判断は人間に押し戻されます。

これは人間組織の多部署レビューと同じ構造です。ステークホルダーが増えるほど、意思決定はコストが上がる。「SKILL を増やせば賢くなる」という素朴な期待は、組織論の現実を無視している。

SKILLS の枚数 ↑ → カバレッジ ↑、だが

収束しない判断 ↑。トレードオフを忘れがち。

③ 静的レビュー ≠ 実行時正しさ

コードレビュー SKILL が「コード OK」と言っても、本物の AWS アカウントで

cdk deploy

• IAM 境界の罠: Permission Boundary と SCP の組み合わせで「ポリシー上 OK だが実行時に AccessDenied」
• リソース作成順の暗黙依存: ACM 証明書のリージョン要件、CloudFront とのタイミング
• リージョン固有の挙動: Lambda の OS が古いリージョン、特定サービスが GA 前の差
• Quota / Service Limit: NAT Gateway、Lambda 同時実行、ENI 上限
• CFN タイムアウト: Custom Resource のリトライ・タイムアウト

静的解析でこれらを全部潰すのは不可能。実環境で動かすフィードバックループが無いと、SKILL を 100 枚並べても粒度は天井にぶつかります。

④ 上流誤りの下流合理化 — 最も恐ろしいモード

これが多層 SKILLS の最大の落とし穴です。

要件 SKILL が次のように書いたとします。

「メッセージ配信のリアルタイム性は要件として優先度低。10 秒程度の遅延は許容。」

しかし、これが顧客の本当の業務理解として誤りだった場合(例: 実は IoT デバイス制御で 100ms 遅延は致命的)、下流の SKILL はどう動くか?

要件 SKILL: 「リアルタイム性 不要」
↓
設計 SKILL: 「SQS Standard で受けて Lambda 処理。整合性◎」
↓
実装 SKILL: 「Lambda 通常設定。ベストプラクティス準拠」
↓
テスト SKILL: 「平均遅延 3 秒で合格判定」
↓
リリース SKILL: 「全ゲート通過。デプロイ可」

全員が前提を疑わず、整合性だけを取りに行く。本番リリース後に「実は遅延要件があった」が発覚する。

これは人間組織でも起きるが、LLM 多層レビューではさらに起きやすい。SKILL は文脈整合性を強く取りに行くため、上流の前提を疑うインセンティブが構造的に弱いからです。

多層レビューは前提誤りを

検出する仕組みではなく、前提に整合させて増幅する仕組みでもある。

まとめ

「SKILLS を厚くすれば成果物の粒度が上がる」を整理しなおすと:

本当のレバレッジは:

SKILLS の枚数 < Grounding × 決定論判定 × 実行ループ

「専門 SKILLS を増やす前に、まず SKILL に渡す前提情報と、判定の機械化と、サンドボックス実行の枠組みを整える」。これが投資順序として正しい、という主張です。

次の記事では、これを実際の自作 OSS (

cdk-pattern-factory