生成AIによるCloud Native基盤構築の可能性と実践的ガードレールの敷設について

by nwiizo

Embed

Start on current slide

Slide 1

Slide 1 text

生成AIによる Cloud Native 基盤構築の可能性と実践的ガードレールの敷設について 2025/4/22 CloudNative Days Summer 2025 プレイベント @nwiizo 30min #CNDS2025

Slide 2

Slide 2 text

nwiizo 株式会社スリーシェイクでプロのソフトウェアエンジニアをやっているものです格闘技、読書、グラビアが趣味でよく本を紹介してます人生を通して"運動、睡眠、読書"をちゃんとやりたい 2

Slide 3

Slide 3 text

about 3-shake 3

Slide 4

Slide 4 text

We are Hiring!! 3-shakeは一緒にSRE界隈を盛り上げてくれる仲間を大募集中です！ Mobility、FinTech、通信など大規模SREを存分に経験できます（最近社内はGenAI / GPU / Kubernetesが盛り上がってます）是非、カジュアル面談しましょう！！！！ 4

Slide 5

Slide 5 text

本日のアジェンダ 1. 生成AIとCloud Nativeの現在地 2. 実践的なプロンプト設計 3. ガードレールの構築の手引き 4. ガードレールを超えて行動するMCP 5. まとめ 5

Slide 6

Slide 6 text

1. 生成AIとCloud Nativeの現在地 6

Slide 7

Slide 7 text

2025年のAI活用状況 (1/2) 開発プロセスが本質的に変化しようとしています。完全に夜明け前です。単なるコード生成から「問題解決支援」へ AIは「道具」から「思考パートナー」に進化実装の正確さより意図の理解が重要に利用パターンの多様化単発指示→会話型→継続的協働へと発展コンテキスト理解力の向上で長期的な議論が可能に 7

Slide 8

Slide 8 text

2025年のAI活用状況 (2/2) コードレビュープロセスの変容 AIが事前レビューを担当人間は高次の設計判断に集中レビュー品質の標準化ボイラープレートコードからの解放定型コードの自動生成カスタマイズポイントの明示保守性を考慮した生成 8

Slide 9

Slide 9 text

生成AIによるCloud Nativeの実際⋯ 実際のところは⋯ 完璧を求めず「ある程度必要」な取り組み変化を楽しむマインドセットの醸成細かいハルシネーションを起こすので知識よりも探索能力を重視する現場での実感以前は「動かない定義」や「架空の機能」に悩まされた今ではモデルの精度が上がり問題が大幅に減少価値を生む作業に集中できる環境に 9

Slide 10

Slide 10 text

生成AIでIaCはさらなる変化を遂げている抽象度の向上コード記述 → 宣言的定義 → 意図ベース定義へ「何を」ではなく「なぜ」を中心とした記述(省略) ビジネス要件からインフラ定義への直接的な翻訳アクセシビリティの民主化専門知識の要求度が低下インフラ構築の裾野拡大 DevOpsの真の実現へのステップ 10

Slide 11

Slide 11 text

生成AIでIaCはさらなる変化を遂げている実験と探索の加速プロトタイピングサイクルの短縮複数アプローチの並行検証が容易に「もし〜だったら？」の実験コスト激減機能やドキュメントを調べて、実行できるか確認してみたいな作業がギュっとなりました 11

Slide 12

Slide 12 text

生成AI時代のIaCの価値ガバナンスとコンプライアンスの強化ポリシーのコード化と自動適用及び自然言語での表現変更理由の明示的記録と追跡及び背景の記録監査対応の自動化と簡素化知識の形式知化と共有暗黙知のコード化と組織資産化ベストプラクティスの自動適用個人スキルギャップの影響低減 12

Slide 13

Slide 13 text

生成AI時代のIaCの価値人間の創造性への集中反復的作業からの解放アーキテクチャ設計や戦略的判断への集中「何を構築するか」より「なぜ構築するか」に注力生成AIによるIaCは、インフラストラクチャをソフトウェアのように扱うというIaCの本来の約束をようやく完全に実現しつつある 13

Slide 14

Slide 14 text

生成AIによるIaCにはまだ課題が残っています依然として残る文脈理解の壁設定意図を完全に理解することが難しい企業固有のプラクティスの習得が困難プロジェクト全体を通した一貫性の欠如具体的な課題例 AWS IAMポリシー生成時に過剰な権限を付与しがちリソース間の複雑な依存関係の理解が不十分、作り直しがちコスト最適化を考慮しない設計提案 14

Slide 15

Slide 15 text

生成AIによるIaCにはまだ課題が残っています品質の非均一性同じプロンプトでも結果に一貫性がないモデルバージョンによる出力差が大きい IaCのリファクタリング能力に限界がある (背景を知らないので消しちゃいけないやつ消したりする) 人間との出力差未だにスピードが主な優位点となっている経験豊富なインフラエンジニアの知識を超えることは少ない 15

Slide 16

Slide 16 text

Vibe CodingはIaCと相性が絶望的に悪い Vibe Coding: The Future of Programming https://learning.oreilly.com/library/view/vib e-coding-the/9798341634749/ 生成AIの現実的な限界: 70%問題 IaCは精度が命綱だが、AIはテンプレート的な構成のみ正確に生成可能 IaCに必要な厳密さとAIの「だいたいあってる」精度の致命的なギャップ AIは「優秀だが何も確認しない若手開発者」 - 速いがIaC 特有の制約を無視 16

Slide 17

Slide 17 text

Vibe CodingはIaCと相性が絶望的に悪い Vibe Coding: The Future of Programming https://learning.oreilly.com/library/view/vib e-coding-the/9798341634749/ 残りの30%の難しさ 70%を登ってきた経験なしで30%を超える難しさインフラ構成では小さなミスが大惨事に直結、AIのVibe Codingでは検出困難コードの正確性確保するタイミングでインフラの機能を損なう可能性 17

Slide 18

Slide 18 text

課題を克服するための方向性を考えましょう効果的なAI活用ワークフロー AIを最初の草稿者として活用: 初期コード生成→人間による洗練 AIをペアプログラマーとして活用: 人間とAIの継続的な対話と検証 AIをバリデーターとして活用: 人間が書いたコードの検証と改善開発プロセスの適応 AIと人間の役割分担を明確に、プログラマーの終焉ではなく変容が求められるレビュープロセスの強化と頻繁なコミット生成→ガードレール/ポリシー適用→人による検証→調整のサイクル確立 18

Slide 19

Slide 19 text

課題を克服するための方向性を考えましょう AIを賢く使う具体的で明確な要件提示 AI出力の厳格な検証理解できないコードはマージしない技術の素振りのために一回作り直す前提で作る効果的なプロンプトの共有と再利用チーム全体でのAI使用基準の統一 19

Slide 20

Slide 20 text

2. 実践的なプロンプト設計 20

Slide 21

Slide 21 text

プロンプトにおける一般的な問題点 Prompt Engineering for Generative AI https://learning.oreilly.com/library/view/pr ompt-engineering-for/9781098153427/ 1. 曖昧な指示 - 日本語という言語の特性上、曖昧な指示が多い 2. 未定義の出力形式 - 出力の形式や長さが明確に定義されていない 3. 例示の欠如 - 良い名前の具体例が示されていない 4. 評価基準の不足 - 名前の良し悪しを評価する一貫した方法がない 5. タスクの分割不足 - 複雑な命名タスクが単一のプロンプトに任されている 21

Slide 22

Slide 22 text

プロンプト設計の失敗パターンと対策 (1/2) 失敗パターン 1. 曖昧な指示症状：「良いDockerfileを作って」→何が「良い」か不明確対策：具体的な条件（「セキュリティ強化」「ビルド時間短縮」など）を明示 2. 過度に複雑な要求症状：一度に多くの要件→コンテキスト混乱、一部無視対策：タスク分割、ステップバイステップアプローチ 22

Slide 23

Slide 23 text

プロンプト設計の失敗パターンと対策 (2/2) 3. 矛盾する指示症状：「軽量で高機能な」など相反する要件→最適化困難対策：優先順位を明確に（「軽量性を優先、ただし最低限の機能Xは必須」） 4. 専門知識の前提症状：「普通のやり方で」など暗黙知に依存→解釈違い対策：明示的なルール提示、例示 5. フィードバックループの欠如症状：一方的な指示のみ→改善機会損失対策：評価基準の明示、段階的改善 23

Slide 24

Slide 24 text

プロンプトの5つの原則 Prompt Engineering for Generative AI https://learning.oreilly.com/library/view/pr ompt-engineering-for/9781098153427/ 1. 方向性を与える - 具体的な指示や目的を明確に示す 2. フォーマットを指定する - 望ましい出力形式を明確に定義する 3. 例を提供する - 期待する出力のサンプルを示す 4. 品質を評価する - 生成された結果の品質を測定・改善する方法を組み込む 5. 作業を分割する - 複雑なタスクをより小さな段階に分割する 24

Slide 25

Slide 25 text

プロンプトの5つの原則の実践例 (1/3) 1. 方向性を与える（Give Direction） × 「ECSクラスタを作成するTerraformコードを書いて」 ○ 「高可用性と費用対効果を重視したプロダクション環境向けECSクラスタを作成するTerraformコードを書いて。　　マイクロサービスアーキテクチャを想定し、セキュリティ要件を満たすこと」 2. フォーマットを指定する（Specify Format） × 「Kubernetesマニフェストを生成して」 ○ 「以下の構造で、YAMLフォーマットのKubernetesマニフェストを生成して： - 各リソースは別ファイルとして - コメントは日本語で - リソース名は kebab-case で統一 - インデントは2スペース」 25

Slide 26

Slide 26 text

3. 例を提供する（Provide Examples）「以下の例に倣ってDockerfileを作成してください： FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci ...」 4. 品質を評価する（Evaluate Quality）「生成したTerraformコードに対して、以下の観点で自己評価してください： 1. セキュリティ（最小権限の原則に従っているか） 2. 可用性（単一障害点がないか） 3. コスト最適化（不要なリソースがないか） 4. メンテナンス性（変数、モジュール化など）」 26

Slide 27

Slide 27 text

5. 作業を分割する（Break Down Tasks）「マイクロサービスアーキテクチャの実装を以下のステップで進めます： Step 1: 全体アーキテクチャ図の作成 Step 2: 各サービスの依存関係の定義 ...」これらのプロンプトを組み合わせることで、生成AIの出力の質を大幅に向上させることができます。その他の細かいテクニックに関してはPrompt Engineering Guideや Prompt engineering overviewなどを読めば良いです。サンプルプロンプトはじゃあ、おうちで学べるブログで公開しています。ぜひ確認してください。 27

Slide 28

Slide 28 text

コンテキスト同梱の良さ(1/2) 1. ナレッジの保存と伝承意思決定の背景や根拠が明示的に残る組織の暗黙知が形式知化される人材の入れ替わりに対する耐性向上 2. 品質とコンプライアンスの向上コードレビューの質的向上（意図の理解）監査対応の容易化（なぜその設定か説明可能）セキュリティ要件のトレーサビリティ確保 28

Slide 29

Slide 29 text

コンテキスト同梱の良さ(2/2) 3. メンテナンス性の向上修正・変更時の副作用予測が容易にリファクタリングの安全性向上テスト戦略の適切な立案他にもいくつかテクニックやそれを補助するツールがありますので調べてみて下さい。ここで言いたいことは1つでドキュメントをGithubに全部載せてたほうが良いということです。 29

Slide 30

Slide 30 text

コンテキスト提供の最適化(rules) (1/3) Rules方式とは必要情報を事前にプロンプトに埋め込むアプローチ ClineやCursorが参照すべきルールを明示的に提供構造化された指示を体系的に組み込む方法 Rules方式のメリット一貫した出力品質が得られる結果が予測しやすくなる企業固有要件を反映させやすい 30

Slide 31

Slide 31 text

コンテキスト提供の最適化(rules) (2/3) 実装戦略 1. 汎用ルール業界標準パターン共通設計原則 2. 技術スタック固有ルール Kubernetes/Terraform等の特有の最適化プラットフォーム固有の制約フレームワーク推奨パターン 31

Slide 32

Slide 32 text

コンテキスト提供の最適化(rules) (3/3) 実装戦略 3. 組織固有ルール命名規則、セキュリティポリシー社内標準アーキテクチャコーディング規約 4. プロジェクト固有ルール特定アプリケーション要件環境固有の設定チーム合意事項 32

Slide 33

Slide 33 text

Rules定義プロセスと更新サイクル Rules定義プロセス 1. 既存の標準・ベストプラクティスの棚卸し 2. 知識ベースの体系化（ドキュメント/コード規約等） 3. プロジェクト要件の明確化 4. フィードバックループの確立このようなルールをプロンプトに含めることで、生成結果が大幅に改善します。 Awesome CursorRulesやrules_templateなどのリポジトリを参考にしてください。最終的には自プロジェクトの規模と運用フローに合わせてテンプレをスリム化すると、Cline の推論コストを抑えつつ高精度なアシストを得られます。 33

Slide 34

Slide 34 text

3. ガードレールの構築の手引き 34

Slide 35

Slide 35 text

70%問題とは何か生成AIの"Vibe Coding"がもたらす根本的な課題 70%は正確だが、残りの30%が致命的 AIは「だいたいあってる」精度でIaCを生成 IaCでは小さなミスが大惨事に直結「優秀なはずだけど確認を怠る若手開発者」のような振る舞い 35

Slide 36

Slide 36 text

70%問題の本質残りの30%を確実にする労力 70%を登ってきた経験なしで30%を超える難しさ「砂上の楼閣」インフラの回避が本質的な課題 AIの限界を認識することが重要完全自動化への過信は危険人間による検証と理解が不可欠 36

Slide 37

Slide 37 text

生成AI時代のガードレールの重要性 (1/3) 安全性と信頼性の向上本番環境への安全なデプロイを保証設定ミスの自動検出生成AIに対して斜に構えるのではなく積極的に活用する姿勢が重要ガードレールによって細かいハルシネーションを防止し、70%の精度を担保 AIが見落としがちな設定ミスによるダウンタイムを削減人間が見逃しやすいエッジケースの捕捉生成AIは再現性が担保されているわけではない一貫性のある検証の適用 37

Slide 38

Slide 38 text

生成AI時代のガードレールの重要性 (2/3) 開発者体験の向上 AIが提案する変更に対する確信と心理的安全性の確保「これで大丈夫」という確信の提供失敗への恐れを軽減人間によるレビュー工数の戦略的削減注力すべきポイントの明確化単純ミスの自動検出 38

Slide 39

Slide 39 text

生成AI時代のガードレールの重要性 (3/3) 組織的メリット組織全体での標準化と一貫性の担保個人の能力差に依存しない品質確保ベストプラクティスの自動適用イノベーションと規制のバランス過度な制限によるイノベーション阻害の回避創造性を維持しながらの安全性確保 39

Slide 40

Slide 40 text

生成AIへの過信がもたらした教訓 (1/2) 実際の教訓 1. 検証の自動化の必要性人的レビューだけでは見落としが発生「見た目は良い」コードの危険性 2. 多層防御の重要性設計・実装・運用の各段階での検証単一の検証方法への依存は危険 40

Slide 41

Slide 41 text

生成AIへの過信がもたらした教訓 (2/2) 3. 継続的監視の価値デプロイ後も定期的な検証が必須環境変化による新たなリスクの検出 4. コンテキスト理解の重要性 AIは全体的な文脈を把握しづらいドメイン固有の制約を理解させる工夫が必要 41

Slide 42

Slide 42 text

IaCの検証はコード生成の検証とは本質的に異なる (1/2) 根本的な違いコード生成の検証はコードの品質を担保構文エラー、ベストプラクティス準拠など IaCの検証はインフラの品質と動作を担保実際のリソース作成・更新の正しさ運用環境での挙動の予測 42

Slide 43

Slide 43 text

IaCの検証はコード生成の検証とは本質的に異なる (2/2) なぜこの違いが重要か開発者視点とインフラ視点の融合が必要コード品質だけでは不十分実際の動作検証が必須 AIはコードの見た目の正しさに強いが、動作の正しさには弱い構文的に正しくても実行時に問題が発生複雑な依存関係の理解が難しい 43

Slide 44

Slide 44 text

IaCのガードレールを敷設する場所(1/3) 1. コード品質検証構文、形式、静的解析、コーディング規約基本的な品質の担保 2. セマンティック検証リソース間の整合性、依存関係の正確性論理的な矛盾の検出 3. セキュリティ検証脆弱性スキャン、最小権限原則の適用セキュリティリスクの事前検出 44

Slide 45

Slide 45 text

IaCのガードレールを敷設する場所(2/3) 4. コンプライアンス検証組織ポリシー、法規制、業界標準への適合性規制要件の自動的な確認 5. コスト最適化検証リソース効率、予算管理、無駄の排除予期せぬコスト増加の防止 6. 変更影響分析変更範囲の把握、依存サービスへの影響予期せぬ副作用の検出 45

Slide 46

Slide 46 text

IaCのガードレールを敷設する場所(3/3) 7. テスト自動化ユニットテスト、統合テスト、E2Eテスト実際の動作確認の自動化 8. 運用準備性検証モニタリング、トレーシング、ロギング、バックアップ、復旧手順運用視点での検証 9. デプロイ戦略検証段階的デプロイ、ロールバック計画の評価安全なデプロイの保証 46

Slide 47

Slide 47 text

継続的検証と改善サイクル (1/2) 主要なチェックポイント Pull Request時の自動検証コミット前の早期フィードバック問題の早期発見と修正定期的な既存リソース検証設定ドリフトの検出と修正新たなセキュリティリスクの識別 47

Slide 48

Slide 48 text

継続的検証と改善サイクル (2/2) 環境ごとの段階的検証開発→検証→本番の段階的な検証強化環境特性に合わせた検証戦略デプロイ前の最終確認総合的なリスク評価と承認プロセスポイントオブノーリターンの設定 48

Slide 49

Slide 49 text

避けるべきアンチパターン (1/2) 1. 検証の先送り「後でまとめてチェックする」という罠問題の蓄積と複雑化 2. 過度な警告抑制警告を無効化して問題を隠蔽技術的負債の暗黙的増加 49

Slide 50

Slide 50 text

避けるべきアンチパターン (2/2) 3. 検証なしの自動修正非互換性や副作用のリスク増大責任の所在の不明確化 4. 一発本番適用テスト環境でのドライランスキップリスク評価の欠如 50

Slide 51

Slide 51 text

認知負荷を下げるためのガードレール (1/2) ガードレールの戦略的選定目的別の最適ツール選定動的検証、静的解析、セマンティック検証組み合わせによる多層防御ルール設定のカスタマイズ業界ベストプラクティス組織固有ポリシー 51

Slide 52

Slide 52 text

認知負荷を下げるためのガードレール (2/2) フォールスポジティブの戦略的管理重要度に応じた扱い分け誤検出の継続的改善自動修正機能の活用スタイルや軽微な問題の自動修正人間の注力すべきポイントの明確化 52

Slide 53

Slide 53 text

ガードレールの進化プロンプトのコンテキスト情報がガードレールの判断基準に意図の明確化による検証精度向上 PR-Agentなどによる自然言語のコンテキスト情報の活用正しい判断のための追加情報の活用意図とチェック内容の一貫性確保設計意図に基づく検証「なぜ」の理解に基づく検証の高度化 53

Slide 54

Slide 54 text

ガードレールの進化修正パターンの学習と自動適用反復的な問題の自動解決経験の蓄積と活用プロンプト改善の自動提案より良い結果を生むプロンプトの学習未然防止アプローチの強化ガードレール自体の継続的最適化誤検出の削減検出精度の向上 54

Slide 55

Slide 55 text

4. ガードレールを超えて行動するMCP 55

Slide 56

Slide 56 text

Model Context Protocol (MCP)の概要 (1/3) 定義と基本原理 AI大規模言語モデルが外部ツールやデータにアクセスするためのプロトコルモデルが質問生成 → 外部システムが回答 → AIが情報統合前章のガードレールとの関係ガードレールは「AIの出力を制限する」アプローチ MCPは「AIの入出力を拡張する」アプローチ両者の組み合わせで真の可能性を引き出す 56

Slide 57

Slide 57 text

Model Context Protocol (MCP)の概要 (2/3) Rules方式との根本的な違い Rules: 事前にすべての情報をコンテキストに埋め込む（静的） MCP: 必要な情報を実行時に動的に取得（動的） AIの視野を広げる意義 70%問題の新たな解決策最新情報やコンテキスト特化情報の活用「知っていること」と「アクセスできること」の融合 57

Slide 58

Slide 58 text

Model Context Protocol (MCP)の概要 (3/3) MCPの動作メカニズム 1. AI: 「追加情報が必要」と判断質問に答えるために不足している情報を特定具体的なクエリを生成 2. AI: 情報取得のためのクエリを生成構造化されたクエリの作成適切なデータソースの選択 58

Slide 59

Slide 59 text

Model Context Protocol (MCP)の動作続き情報取得と処理のフロー 3. 外部システム: 情報を収集・返却クエリに基づく情報取得フォーマット変換・最適化 4. AI: 情報をコンテキストに統合し応答取得情報の理解・解釈ユーザーの質問と関連付けた回答生成 59

Slide 60

Slide 60 text

MCPとガードレールの補完関係相互補完的な関係ガードレール：出力の「安全性」「品質」を確保 MCP：入力の「情報量」「正確性」を向上品質向上サイクル MCP → より良い情報 → より良い生成 → ガードレールでチェック 60

Slide 61

Slide 61 text

MCP実装の技術選定ガイド (1/2) 技術選定の判断基準 1. 既存システム状況既存APIの有無と品質認証・認可の仕組み統合難易度 2. 要件の複雑さ必要データの多様性リアルタイム性要求エラー処理の複雑さ 61

Slide 62

Slide 62 text

MCP実装の技術選定ガイド (2/2) 3. 運用面の考慮保守性とスケーラビリティモニタリングと監査の容易さセキュリティとデータ保護(riseandignite/mcp-shieldなどがある) 4. コスト効率 APIコールの頻度と量データ転送コスト実装・維持コスト 62

Slide 63

Slide 63 text

AWS MCP Servers (1/2) 出典: https://github.com/awslabs/mcp AWS Documentation MCP Server AWS公式ドキュメント検索サービス・API・パラメータ情報取得ベストプラクティス参照 Bedrock Knowledge Bases MCP Server カスタムナレッジベース連携自社ドキュメント・Wiki活用独自Q&Aデータベース 63

Slide 64

Slide 64 text

AWS MCP Servers (2/2) 出典: https://github.com/awslabs/mcp CDK MCP Server AWS CDKプロジェクト支援コンストラクト情報参照/プロパティ・メソッド詳細 Terraform MCP Server Terraformプロバイダー情報参照リソース・データソース詳細/モジュール構造解析 Lambda MCP Server 任意のLambda関数をMCPツールとして実行カスタムインテグレーション 64

Slide 65

Slide 65 text

kubectl-ai: Kubernetes用AIアシスタント (1/2) 出典: https://github.com/GoogleCloudPlatform/kubectl-ai 概要 Google Cloudの大規模言語モデルを活用したkubectl プラグイン自然言語でKubernetesクラスタを操作クラスタ状態を考慮した応答生成 MCPとしても利用可能 https://github.com/GoogleCloudPlatform/kubectl-ai 65

Slide 66

Slide 66 text

kubectl-ai: Kubernetes用AIアシスタント (2/2) 実用的なコマンド例： # デプロイメント作成 kubectl ai "nginxのDeploymentを作成して、レプリカ数は3、リソース制限ありで" # トラブルシューティング kubectl ai "なぜPodがPendingのままなのか調査して" # スケーリング操作 kubectl ai "payment-serviceのレプリカを3から5に増やして" 66

Slide 67

Slide 67 text

kubectl-aiの活用パターン # リソース最適化 kubectl ai "すべてのDeploymentのリソース使用状況を分析し、最適化案を提示して" # セキュリティ診断 kubectl ai "クラスタ内の潜在的なセキュリティリスクを検出して" 複雑なKubernetes操作を自然言語で実行可能に現在のクラスタ状態に基づいた適切な提案特定の状況に合わせたトラブルシューティング 67

Slide 68

Slide 68 text

各種サービスのMCP実装例各サービスベンダーもMCP実装を進めています。人の夢は!!! 終わらねェ!!! Datadog MCP(非公式) 監視データやログの自然言語分析インシデント検知と障害対応支援 PagerDuty MCP(非公式) PagerDutyのAPI機能をLLMに提供インシデント、サービス、チーム管理が自然言語で可能 68

Slide 69

Slide 69 text

MCPエコシステムの拡大サービスベンダー視点差別化ポイントとしてのMCP 製品の使いやすさ向上ユーザー体験の向上ユーザー視点複数ツールの統合インターフェースツール間の文脈の維持学習コストの削減 -> ユーザーはドキュメントやコードに質問できる 69

Slide 70

Slide 70 text

ドキュメントやコードに質問できる意義 (1/2) 従来のアプローチの限界キーワード検索の精度限界暗黙知のドキュメント化困難コンテキスト理解の欠如情報の断片化ドキュメント間関連性把握の困難さ 70

Slide 71

Slide 71 text

ドキュメントやコードに質問できる意義 (2/2) MCPによる質的変化自然言語による意図理解複数情報源からの統合回答コンテキストに応じた関連情報提供文脈の維持説明を含む回答生成理解しやすい情報提示 71

Slide 72

Slide 72 text

MCPとガードレールの統合による未来 MCPによる情報アクセスの拡張必要な情報へのリアルタイムアクセス文脈に応じた最適な情報提供ガードレールによる安全性確保生成コードの品質担保リスクの最小化と自動修正協調的な開発フロー AIが提案、人間が判断という役割分担 70%問題の克服と開発体験の向上 72

Slide 73

Slide 73 text

MCPの課題と現実的な限界レスポンス時間の増加外部API呼び出しによる遅延複数ソースへのアクセスによる待ち時間情報統合の難しさ矛盾する情報の調停コンテキスト長の制限との兼ね合い 73

Slide 74

Slide 74 text

MCPの課題と現実的な限界ハルシネーション問題は依然として存在情報アクセスは改善するが、解釈ミスの可能性は残る特に複雑な依存関係の理解に課題 70%→100%ではなく、より現実的には70%→80%程度人間による最終確認は依然として重要自動化と人間の判断のバランスが鍵斜に構えてたら終わる実感は持っている 74

Slide 75

Slide 75 text

5.まとめ 75

Slide 76

Slide 76 text

まとめ生成AIとIaCの相性の悪さとその解決策ガードレールの敷設、MCPの導入、プロンプト設計の5原則プロンプト設計は5原則で品質向上方向性・フォーマット・例示・評価・分割 IaCの70%問題はガードレールとMCPと人間で解決多層検証＋ルール化で信頼性担保 76

Slide 77

Slide 77 text

え、実践的なガードレールの敷設は？今回は方向性だけ示しました。それぞれのガードレールの設定方法は各自でやってください。参考リンクにいくつか紹介リンクを載せています。75％ぐらいは作ってくれると思います。 77

Slide 78

Slide 78 text

参考リソース OPA（Open Policy Agent） Kyverno AWS MCP Servers kubectl-ai kube-linter Trivy Conftest Datree PR-Agent hadolint 78

Slide 79

Slide 79 text

参考リンク Dynamic Admission Control Validating Admission Policy Terrascan Infracost Checkov Pluto Sealed Secrets 79

Slide 80

Slide 80 text

参考リンク MCPのドキュメント tflint tfsec kube-score Argo Rollouts Argo CD Kubernetesで実践する Platform Engineering AI Engineering 80

Slide 81

Slide 81 text

ありがとうございましたご質問・ご相談はお気軽にお問い合わせください @nwiizo | https://3-shake.com