TL;DR
- SDLC の各フェーズに 専門 SKILL(BA / Sec / Perf / Arch / DBA / QA / Ops / Compliance) を立てて多層レビューさせる構想は、図に描くと美しい。だが SKILLS を増やすだけでは成果物の粒度は上がらない。
- 効くようにするには SKILLS の手前に Grounding × 決定論判定 × 実行ループ の 3 つを整える必要がある。
- 本記事は前半でその 3 原則を一般論として説明し、後半に 筆者の自作 OSS への組み込み例 を事例として置く構成にしている。
- 結論: SKILL を増やすのは最後でいい。それより手前にやるべき投資がある。
はじめに: SKILLS を増やせば品質は上がる、という幻想
LLM を SDLC(ソフトウェア開発ライフサイクル)の各フェーズに組み込み、要件 → 設計 → 実装 → テスト → リリースの各段階で複数の専門 SKILL にレビューさせる、という構想が最近よく語られる。
絵としては魅力的だ。各観点の専門 SKILL が PR にコメントを残し、「すべての関門を通過したものだけがリリースされる」という多層ガードの世界観。
ところがこれを素直に組むと、LLM が自信ありげに承認した PR が、実際にデプロイすると壊れているという事故が普通に起きる。原因はだいたい次のどれかだ。
- Grounding が足りない: 顧客固有の制約・社内標準・過去事例を渡していないので、SKILL が「一般論として正しいが現場と合わない」提案をする
- 判定が LLM 主観: Pass/Fail を LLM に決めさせているので、LLM が「適切と判断します」と書けば通ってしまう
- 実行されていない: 静的レビューだけで判定しており、動かしてみないと分からない問題を取りこぼす
SKILLS を増やすのはこの 3 つを整えた後でいい。 整える前に SKILLS だけ厚くすると、自信ある誤りを大量生産する装置が出来上がる。
以下、3 つの投資をそれぞれ見ていく。
原則 1: Grounding 基盤を厚くする
SKILL が現場に合わない提案をしてくるのは、SKILL が悪いのではなく、現場の情報を渡していないから。
LLM は与えられたコンテキストの範囲でしか考えられない。「既存資産があるか」「社内ルールはどうか」「過去に似た案件で何を決めたか」を渡さなければ、SKILL は毎回ゼロベースで一般論を返してくる。
Grounding として渡すべき情報は大きく 3 種類ある。
(a) 過去案件の判断ログ
過去案件で「どの論点で」「どう判断したか」「なぜそう判断したか」を構造化して蓄積し、類似案件で参照できるようにする。
# 蓄積される 1 案件分の例
case_id: 2025-q4-fintech-api
industry: financial
pattern: serverless-api
decisions:
- point: storage_encryption
chosen: cmk
rationale: PCI DSS scope, BYOK 要件
- point: backup_dr
chosen: cross_region_warm
rationale: RTO 1h
embedding して類似検索できるようにしておけば、SKILL レビュー時に「業種 × パターンで過去どう決めたか」を渡せる。SKILL は一般論ではなく「自社の過去判断との整合」を語れるようになる。
(b) 顧客固有コンテキスト
ヒアリングや要件定義の段階で、既存資産プロフィールを構造化入力として取る。
| 項目 | なぜ必要か |
|---|---|
| 既存インフラ | 既存と整合しない提案を防ぐ |
| アカウント / 組織構成 | 全社統制と矛盾する提案を防ぐ |
| ID 基盤 | 既存認証と分断された提案を防ぐ |
| 監視・運用基盤 | 既存運用に乗らない提案を防ぐ |
| ハード制約 | 予算超過・禁止技術の提案を防ぐ |
| 過去インシデント | 同じ失敗を繰り返さない |
これが無いまま SKILL を増やしても、SKILL が増えた分だけ「一般論として正しいが現場と合わない指摘」が増えるだけだ。
(c) 組織ナレッジ(社内標準・命名規則・運用基準)
社内ルールを YAML 等で構造化して持ち、LLM プロンプトの冒頭に dump する。
naming:
pattern: "{env}-{service}-{resource}-{seq}"
tagging:
required: [CostCenter, Owner, Environment, DataClass]
monitoring:
forward_to: <社内標準ツール>
これを冒頭に置くだけで、LLM が「勝手にベストプラクティスを発明する」現象が大幅に減る。SKILL のレビュー指摘も「ベストプラクティス的にはこう」ではなく「社内標準ではこう」という具体性を持つようになる。
原則 2: 判定を機械可読にする
SKILL は「指摘の生成」「違反の意味を自然言語で説明」「リファクタ提案」にだけ使う。Pass/Fail を決めるのは LLM ではなく機械にする。
LLM SKILL に「セキュリティ的に問題ありません」と書かせて Pass にする運用は、構造的に壊れる。LLM は説得力のある文章を書くのが得意なので、間違っていても通ってしまう。
判定は決定論的なツールに任せる。
| 領域 | NG: LLM 主観判定 | OK: 機械判定 |
|---|---|---|
| セキュリティ | 「設定は適切と判断」 | 静的解析ツールの違反 0 |
| 最小権限 | 「ポリシー妥当」 | 権限解析ツールの Finding が 0 |
| コスト | 「コストは妥当」 | 見積もりツールが予算上限内 |
| 命名 | 「命名 OK」 | regex ルール pass |
| 依存 | 「ライブラリ問題なし」 | 脆弱性スキャナで High 以上 0 |
そのうえで、各成果物パターンが「通過すべき機械チェック」を自己定義する形にする。
# パターンごとの通過条件(例)
acceptance_criteria:
static_analysis:
required_pass: [rule-A, rule-B, rule-C]
cost:
max_monthly_usd: 200
integration_tests:
- happy_path
- cold_start_under_3s
- auth_denies_unauthorized
LLM はこれを満たすコードを生成し、CI がこれを判定する、という分業になる。
ゲートの Pass/Fail は CI に移譲する:
.github/workflows/
├── gate-2-design.yml # 設計書 lint, schema 検証
├── gate-3-implementation.yml # 静的解析, lint, 型チェック
├── gate-4-test.yml # integ test, contract test
└── gate-5-release.yml # drift check, approval required
LLM SKILL は PR コメントで指摘を残す役割。「通す/通さない」は CI の deterministic な結果。これだけで「LLM の心象次第で品質が変わる」現象が消える。
原則 3: サンドボックス実行ループを組む
静的レビューでは捕まらない実行時の問題を本番前に拾う仕組み。
静的解析や LLM レビューは「コードを読んで分かること」しか拾えない。一方で、現実のシステムで起きる問題の多くは「動かしてみないと分からない」: 実効権限、レイテンシ、初期化順序、依存サービスとの結合、etc.
使い捨て環境への自動 deploy
PR 単位で使い捨ての検証環境を払い出し、自動デプロイ → 検証 → 破棄する。
# CI 設定の概形
on: pull_request
jobs:
ephemeral-deploy:
steps:
- run: 環境を払い出す
- run: デプロイする
- run: 静的解析を実行
- run: 統合テストを実行
- run: コスト見積もりを取得
- if: always()
run: 環境を破棄
これで「実環境で初めて分かる問題」が PR の段階で表面化する。
実行結果を Grounding に戻す
サンドボックス実行で発生したエラー・警告を新規の判断ポイントとして記録し、原則 1 (a) の判断ログに蓄積する。
# 自動追記される例
runtime_findings:
- source: static_analysis
rule: least-privilege-5
status: deferred # 人間レビュー待ち
suggested_action: "Action を限定列挙へ"
- source: integ-test
test: cold_start_under_3s
result: failed
actual_ms: 4200
これにより「実環境で実際に何が起きたか」が判断ログに蓄積され、次案件の SKILL レビューに渡される(原則 1 (a) に戻る)。
Grounding → 判定 → 実行 → Grounding のループが閉じる。これが回り始めて初めて、システムは「案件をこなすたびに賢くなる」ようになる。
人間レビューはどこに置くか
全ゲートに人を置かない。置くべきところに置く。
3 原則を整えた上で、人間レビューの配置を決める。
| ゲート | 主判定 | 人間レビュー |
|---|---|---|
| ゲート 1: 要件 | LLM (SKILL) + 顧客レビュー | 必須(前提誤りを潰す) |
| ゲート 2: 設計 | SKILL 多角 + 過去案件 RAG | 推奨(不可逆判断の合意) |
| ゲート 3: 実装 | 機械判定 | 不要(差分レビューのみ) |
| ゲート 4: テスト | 機械判定 | 不要 |
| ゲート 5: リリース | 機械判定 + 承認権限 | 必須(本番投入は不可逆) |
設計の肝:
- 人間レビューの密度は 判断の不可逆性に比例させる
- ゲート 3-4 は機械判定のみで通せる設計にし、人間はそこに介在させない(さもないと人間がボトルネックになる)
- ただしゲート 1 と 5 は絶対に省略しない
ゲート 1 を省略すると「上流誤りを下流で合理化する」事故が起きる。要件の誤認を SKILL が引き継いだまま設計・実装・テストを通過させ、リリース直前に「そもそも要件が違っていた」と気づくパターンだ。多層 SKILL レビューは上流誤りを発見する仕組みではない(SKILL は与えられた前提の中で最適化する)。だから上流に人を置く。
ゲート 5 を省略すると、機械判定をすべてパスしたコードがそのまま本番に出る。機械判定は「ルール違反していない」ことしか保証しない。「今このタイミングで本番に出していいか」を判断するのは依然として人間の仕事だ。
実装フェーズ(現実的なロードマップ)
Phase A: Grounding 入力拡張
├ 既存資産スキーマ
├ 組織ナレッジ
└ 過去判断ログの蓄積基盤
Phase B: 機械判定の組み込み
├ パターン定義に通過条件
├ 静的解析 / 見積もり / 権限解析の CI 連携
└ ゲート判定の CI 移譲
Phase C: サンドボックス実行ループ
├ 使い捨て環境の払い出し
├ 統合テストハーネス
└ 判断ログへの自動フィードバック
Phase D (継続): SKILLS の厚み増 ← ここで初めて意味が出る
├ ロール別 SKILL の整備
└ オーケストレーター LLM の判断ルール
Phase D を最後に置いているのが本記事の主張です。 Grounding と決定論判定と実行ループが無い状態で SKILL を増やすのは、自信ある誤りを大量生産する装置を作ることになる。
まとめ
SKILLS を増やす前に Grounding × 決定論判定 × 実行ループを整えよ
- Grounding: 過去判断・既存資産・組織ナレッジを SKILL に渡す
- 決定論判定: Pass/Fail は LLM ではなくツールに決めさせる
- 実行ループ: 使い捨て環境で動かし、結果を判断ログに戻す
- SKILLS 整備: ここに来てようやく多層 SKILL を厚くする意味が出る
これが揃って初めて、図の世界観「LLM 多層レビューで品質・セキュリティ・信頼性を確保し、すべての関門を通過したプロジェクトのみリリース」が機能する形で動くようになる、というのが現時点の結論です。
SKILL を増やしたくなる気持ちはよく分かる(絵としても分かりやすいし、進捗としても分かりやすい)。だが「絵としての分かりやすさ」と「システムとして効くかどうか」は別の話だ、というのが筆者が回り道して得た教訓です。