AI に書かせる前に 何を設計するか Kiro x Claude Codeによる 基盤設計の仕様駆動開発実践

GovJAWS#7で発表させていただいた資料です
KiroとClaudeCodeを使ったCDKコード生成の方法を書いています

Transcript

1. © 2026 NTT DATA Japan Corporation © 2026 NTT DATA Japan Corporation AI に書かせる前に 何を設計するか Kiro x Claude Codeによる 基盤設計の仕様駆動開発実践 NTTデータ 川村 吏
2. © 2026 NTT DATA Japan Corporation 2 はじめに AWS上でのCDK構築にあたり、KiroとClaudeCodeを組み合わせた仕様駆動開発を現在実証中です。 完了した事例ではありませんが、現在進行中の状況から得られた知見や課題を説明します。 ※今回ご紹介する事例は、会社を代表する取り組みではなく、独自に実施している取り組みになります。
3. © 2026 NTT DATA Japan Corporation 3 自己紹介 ・名前：川村 吏（かわむら つかさ） ・所属：株式会社NTTデータ 社会基盤ソリューション事業本部 ・業務： 2015年中ころ～2019年初頭まで：オンプレミス環境(VMware、Xen、Hyper-V等)を中心とした、基盤設計、構築、運用等 2019年初頭～2020年10月：パブリッククラウド(AWS中心、Azureも少し)へのリフト、シフト、新規開発における提案、基盤設計、構築 2020年11月～：NTTデータ社へ中途入社 公共機関向けシステムのクラウド移行に関するコンサル、提案、設計、構築など ・好きなAWSサービス： S3、CloudFront、Route53 ・趣味： 猫、Disney、グラス収集、紅茶、料理、etc…
4. © 2026 NTT DATA Japan Corporation 4 前提 • AWS上での基盤構築（小規模） • 現在試行錯誤中 • 基本的にコードは自分で書かない • 一般的な要件定義、設計、コード作成、構築、テストの流れ
5. © 2026 NTT DATA Japan Corporation 5 Specs（仕様の構造化） Kiroとは？ Kiroは、「仕様駆動開発（Spec-driven development）」を特徴とする、Amazon Web Services (AWS) のAIエー ジェント型IDE（統合開発環境）です。 単にコードを書いてほしいという指示を出すのではなく、手前からSteeringで制約を定義、Specsで仕様の構造化、実装、Skills での作業の標準化、Hooksで品質チェックなどの自動検証というサイクルで連携することが可能です。 Steering (制約・ルールの定義) Requirements (何を作るか？) design (どうつくるか？) tasks (実装タスク) Skills 作業の標準化 Hooks 品質チェックなどの 自動化 仕様駆動開発とは？ 仕様駆動開発（SDD: Spec-Driven Development）は、コードを書く前に詳細な仕様書 （Spec）を定義し、それを基にAIを活用して設計・ 実装を進める手法 AIエージェントに「正しい」実装を させるためのガードレール
6. © 2026 NTT DATA Japan Corporation 6 ClaudeCodeについて Anthropic社が提供するターミナル上で動作するAIエージェント コーディングその他様々な用途で利用可能。 今回は、計画立案、レビュー、人間向けドキュメント生成をClaudeCodeで実現。 Kiro(メインツール) ClaudeCode(補助ツール) Spec定義、実装 多角的な レビュー検証 可読性の高いドキュ メント生成 PJ全体の思想設計 タスク抽出 PJ管理 デバッグ
7. © 2026 NTT DATA Japan Corporation 7 人間とAIの役割分担 Kiro Spec、コード生成 人間 承認、介入、フォール バック ClaudeCode 計画・レビュー・文書 化・デバック
8. © 2026 NTT DATA Japan Corporation 8 全体の開発フロー 各フェーズにAIによる多角的なRVと、人間による介入、承認ゲートを挟む 最大のリスクは、人間が確認可能なタイミングで確認しないこと 計画作成 Steering作成 (product、 structure、tech) Spec作成 CDK実装 テスト RV 承認 RV 承認 RV 承認 RV 承認 RV 承認
9. © 2026 NTT DATA Japan Corporation 9 KiroのSteeringとは？ • Steeringを一言で言うと「KiroへのAIへの常時コンテキスト注入ファイル」。人間が新しいチームメンバーにルールブックを渡すの と同じ感覚で、KiroにプロジェクトのルールをSteeringとして渡す。重要なのは「常時」という点。Kiroはチャットのセッションをま たいで記憶をリセットするが、inclusion:alwaysのSteeringだけは毎回自動で読み込まれる。つまりSteeringに書いてある ことはKiroが「常識」として保持し、書いていないことは毎回ゼロから考え始める。何もかかなければ、Kiroは一般的なAWS実 装を生成し続ける。 • .kiro/steering/ フォルダに置くMarkdownファイル群。 • 命名規約、CDKコード規約、禁止操作、スタック構成など守ってほしいことを定義 • 1ファイル100～150行以内を目安。長大になったらファイルを分割、inclusionで読み込み対象を制御 • WHEN/SHALL記法で条件と制約を明示。例: WHEN S3バケットを作成する場合 SHALL 暗号化(SSE-S3)を必ず有 効にすること • Steeringの鮮度 = AIコード生成品質の鮮度: アーキテクチャ変更・SCP追加・新スタック追加のタイミングで必ず更新
10. © 2026 NTT DATA Japan Corporation 10 Steering設計方法 • 実績のある案件のコード規約等をClaudeCodeで参照、作成 • 過去案件のインプットから、特徴、メリデメを比較分析（例：コード規約やスタック構成、CICD構成など） • ClaudeCodeのAgentTeamに定義したペルソナ（専門ロール）で、ディスカッション、多角的に方針検討 • 最終的にSteering、Hooks、Skillsを生成（要件抽出、設計、テンプレート作成とフェーズを分割） • 生成したSteeringをAgentTeamで定義したペルソナ（専門ロール）でレビュー 参考：今回の設計 .kiro/steering/ ├── product.md # プロダクト概要・目標（PLACEHOLDER形式） ├── structure.md # リポジトリ構成・スタック分割（PLACEHOLDER形式） ├── tech.md # 技術スタック・CDKバージョン・ガバメントクラウド固有制約 ├── config-management.md # Config管理ルール（TypeScript Config / SSM / featureFlags） ├── branch-strategy.md # ブランチ戦略・コード規約・ai/プレフィックスルール ├── security-controls.md # セキュリティ統制（cdk-nag / SG / KMS）← 最上位 ├── cdk-standards.md # CDK設計標準（Construct使い分け・Stack分割原則） ├── ai-agent-boundaries.md# AIエージェントの権限境界（操作可/不可の明示） ├── ops-change-constraints.md # 運用期変更制約（変更禁止リソース・ORR要件） └── spec/operations.md # DRフェイルオーバー手順・障害対応フロー
11. © 2026 NTT DATA Japan Corporation 11 Hooks設計 • コード生成等で自動実行してほしい動作を定義 コード生成 即時ブロック判定 cdk-nag/シークレッ ト検知/tsエラーな ど 却下 警告判定 ESLint/CDKSynt hなど 合格 参考：一例
12. © 2026 NTT DATA Japan Corporation 12 Skills 誰が実行しても同じ品質になることを意識してスキル化 参考：例 • デプロイ • セキュリティチェック • Runbook生成 • コスト分析 など
13. © 2026 NTT DATA Japan Corporation 13 AIによる多角的レビュー（Claude Code） • 多角的なRVでは相互にトレードオフな関係性 を持つ指摘がでてくることがある。例えばAWS 特化Agentの指摘が、Kiro特化Agent的に は書きすぎであったり、運用コストが上昇するこ となど • 重要なのは、成果物が何に使われるかという 視点で判断を行うこと、最後に人間が責任を 持つこと 成果物 Kiro特化専門 Agent AWS特化専門 Agent CDK特化 Agent 運用コスト特化 Agent 人間による判断 例 ※専門Agentの定義は一例です • 様々なペルソナ定義に基づき多角的レビューを実施 • 網羅性、固有度、実装可能性、指摘の鋭さなどでスコアリング（SteeringRVを例）
14. © 2026 NTT DATA Japan Corporation 14 多角的レビューから導き出されたKiroが動きやすいSteering設計原則 1. 常時読み込み / 条件付き読み込みの適切な分離 — 常時適用すべき制約とタスク固有の設計を分け、コンテキストウィンド ウを無駄に消費しない 2. 仮値の除去 — 仮値が残っているとKiroが誤認してコードに混入させるリスク。 3. ファイル1本100～150行以内 — 長大なドキュメントはKiroのコンテキスト利用効率を下げる 4. スタック単位でSpecを分割 — NetworkStack・SecurityStack等を独立Specに割り当て 5. パラメータの命名規則と参照先を明記 — スタック間の値渡しでKiroが取得先を誤解しない 6. クラウド基盤管理リソースのCDK対象外リスト — CDKで重複実装するとデプロイ失敗や競合が発生 ※特にガバメントクラ ウド
15. © 2026 NTT DATA Japan Corporation 15 品質管理ゲート 自動化できるチェックはAIに任せて、レビュー負荷を軽減、本質的な判断を人間が行う ただし重要なのは、AIの生成した成果物に対して人間が責任を負える体制にしておくこと 計画作成 Steering作成 (product、 structure、tech) Spec作成 CDK実装 人間RV 承認 人間RV 承認 AI RV 人間RV 承認 AI RV 人間RV 承認 AI RV Hools RV （Nagな ど） CDK実装 デプロイ テスト 人間RV 承認 人間RV 承認 AI RV AI RV
16. © 2026 NTT DATA Japan Corporation 16 コードレビューの指針 1. Hooks自動チェック（ローカル）: ESLint / CDK Nag / Secrets検出 2. CI自動検証: cdk synth / CDK Nag / セキュリティスキャン 3. AI判断チェック:設計指針、AWSベスプラなど 4. 人間レビュー: セキュリティ・コスト・設計判断の本質的な確認 5. デプロイ後チェック：エラー有無、ドリフトチェックなど
17. © 2026 NTT DATA Japan Corporation 17 役割のシフト Before 設計もコードも実装にかかる時間が最も多い After 制約や前提を与えれば、AIが自走して実装を行う、人間 は制御とRVに注力、AIが動作しやすいチーム体制や、仕 組みの設計を行う 人間が集中すべき仕事: 仕様の磨き込み / トレードオフ判断 / Steering設計 / レビュアー設計 / AIが働きやすい粒 度の設計 / 顧客・発注者との調整
18. © 2026 NTT DATA Japan Corporation 18 従来型開発からの追加検討項目例 1. Steeringファイルの設計・管理運営: 誰がいつ更新するか、承認フローを事前に設計 2. Hooksの品質ゲート設計: 設定するだけでは不十分。 3. AI生成コード固有のレビュー設計: 人間が書いたコードと同じレビューでは不十分 4. 成果物形式と変換: Markdown形式やdocsなどの方式への変換などの設計 5. 追加成果物管理: Steering/ Skills・Hooks開発 6. チーム体制：ペアプロ、Specなどをどうわけていくかなどに応じてチーム設計やレビューフローなどの整備が必要 AIは人間と異なりプロジェクト固有の文脈・暗黙知を持たない 人間のエンジニアが自然に補完していた設計意図・制約・背景知識を、すべてファイルとして明示的に与える必要があるため事前 準備が重要
19. © 2026 NTT DATA Japan Corporation 19 今後の課題 大規模案件へ適用する上で以下のような課題が存在 • 人数・ロール面: AI経験者がSPOF化するリスク、育成タイムラインとピーク工数タイムラインの衝突 • Spec管理面: 複数スタック x 複数グループでSpecが分散。整合性管理とマージ戦略 • ガバナンス面: 提出用の従来型設計書とSpecの二重管理問題 • Steeringのスケール: 複数人が並列更新する際のコンフリクト・一貫性維持 • コミニケーションコストの低減と、チーム構造の最適化 Before PM 最終承認 PL 承認・調整 TL-A 人 人 人 TL-B 人 人 人 TL-C 人 人 人 AIが速くても承認フローがボトルネックに → After ハイレベル設計チーム（少数精鋭） 全体分解・制約定義・ガードレール マイクロ A 人 1～3名 + Agent 群 ↓ マイクロ B 人 1～3名 + Agent 群 ↓ マイクロ C 人 1～3名 + Agent 群 ↓ 制約の中で自律的に判断・実行
20. © 2026 NTT DATA Japan Corporation 20 まとめ 1. Steeringの品質がAI出力品質を直接決定する 2. 「書く人」から「設計し、レビューし、自動化する人」へ 3. AI生成物は出発点であり完成形ではない 人間が裁定して品質が確定