はじめに
こんにちは、nwiizoです。2025年4月22日と23日、スケジュールの都合で連続して2つの技術イベントに登壇することになりました。それぞれのイベントは異なる切り口でしたが、どちらも「生成AI」をテーマにしたものでした。1日目は「生成AI」と「クラウドネイティブ」の融合、2日目は「生成AI」の「Model Context Protocol（MCP）」に焦点を当てました。
生成AI技術は近年急速に進化し、私たちエンジニアの働き方に大きな影響を与えています。私自身も数年前からnvimでGitHub Copilotを日常的に使い、その後Clineなどのコーディングエージェントブームのバズに押されつつもCursorやVSCodeを利用しています。同時に、Cloud Native技術も着実に成熟し、多くの企業のインフラ戦略の中核となっています。
現在、これら二つの技術領域が交わることで、特にIaC（Infrastructure as Code）分野での応用が活発化しています。多くの開発者がこの統合に関して様々な課題に直面しており、今回の登壇では、そうした課題に対する私なりの考察と解決策を共有しました。本ブログでは、この2日間の登壇内容を振り返りながら、技術的な洞察やコミュニティでの議論から得た気づきを記録したいと思います。
生成AIとクラウドネイティブ技術の統合が開発・運用プロセスを根本から変革しています。本稿はエンジニアが直面する「70%問題」（AIがコードの70%は正確に生成するが、残り30%で致命的ミスを犯す現象）に対して、ガードレールとModel Context Protocol (MCP)の相補的活用による解決策を提案します。インフラ/アプリケーションエンジニアは「思考パートナー」としてAIを活用し、検証文化を確立することで、開発効率と品質を両立できます。本記事では、両イベントでの登壇内容をもとに、AIを単なるツールから戦略的パートナーへと位置づけ直す視点と、認知労働の新たな分担を実現する実践的なフレームワークについて詳しく解説します。
Day 1: 生成AIとCloud Nativeの融合を語る
イベント: CloudNative Days Summer 2025 プレイベント
登壇タイトル: 生成AIによるCloud Native 基盤構築の可能性と実践的ガードレールの敷設について
日時: 2025年4月22日
https://cloudnativedays.connpass.com/event/351211/cloudnativedays.connpass.com
1日目は、CloudNative Days Summer 2025のプレイベントに参加しました。このイベントの参加者層は主にインフラエンジニアやSRE（Site Reliability Engineer）が中心で、Cloud Native技術への関心が高い方々です。私のセッションでは、生成AIを活用したCloud Native基盤構築について、実践的な観点から解説しました。
発表資料
発表の詳細
セッション内容は以下の4つの大きなセクションに分けて構成しました：
1. 生成AIとCloud Nativeの現在地（2025年）
まず、現在の生成AIによる開発プロセスの変化について解説しました。従来のコード生成から問題解決支援へと進化しており、AIは単なる「道具」から「思考パートナー」へと変わりつつあります。これは根本的な変化であり、単なる機能向上ではありません。AIが書かれるコードの構文パターンだけでなく、構築されるものの概念モデルに関与できるようになった結果、協働のダイナミクスが質的に変化しています。
AIの利用パターンも単発指示→会話型→継続的協働へと発展し、長期的な文脈理解ができるようになっています。これにより、開発ワークフローも大きく変化しています。 - コードレビューの前段階をAIが担当し、人間は高次の設計判断に集中 - ボイラープレートコードからの解放で、より創造的な作業への時間が増加 - テスト品質の標準化によるソフトウェア信頼性の向上
しかし実際のところ、AIによるCloud Native実装は「完璧」ではなく、「ある程度必要」な取り組みとして捉えるべきだと強調しました。現場では、以前は「動かない定義」や「架空の機能」に悩まされましたが、モデルの精度向上により問題は大幅に減少しています。それでも、いわゆる「ハルシネーション」と呼ばれる問題は依然として存在するため、AIの出力を盲信せず、検証する姿勢が重要です。
特にIaC（Infrastructure as Code）においては、コードと実際のインフラの間に差異が生じることも珍しくありません。AIが生成したインフラ定義は、理想的な環境を想定していることが多く、実際の環境の制約やレガシーシステムとの互換性といった現実的な問題に対応できていないケースがあります。そのため、多くの組織では完全自動化ではなく、ある程度抽象化したり省力化したりしながら、人間による確認と調整を組み合わせたハイブリッドなアプローチを採用しています。これにより、AIの効率性と人間の判断を最適に組み合わせたCloud Native環境の管理が実現されています。
2. 実践的なプロンプト設計
効果的なAI活用のための「プロンプト設計の5原則」を紹介しました：
方向性を与える（Give Direction）
- 具体的な指示や目的を明確に示す
- 例：「高可用性と費用対効果を重視したプロダクション環境向けECSクラスタを作成するTerraformコード」のように具体的に
フォーマットを指定する（Specify Format）
- 望ましい出力形式を明確に定義する
- 例：コーディングスタイル、ファイル分割方針などを明示的に記述
例を提供する（Provide Examples）
- 期待する出力のサンプルを示す
- 既存の成功パターンを参考に提示する
品質を評価する（Evaluate Quality）
- 生成された結果の品質を測定・改善する方法を組み込む
- セキュリティ、可用性、コスト最適化などの観点を明示
作業を分割する（Break Down Tasks）
- 複雑なタスクをより小さな段階に分割する
- ステップバイステップのアプローチを促す
これらの原則を実践することで、生成AIからより質の高い出力を得られることを実例とともに解説しました。また、コンテキスト同梱の重要性についても言及し、意思決定の背景や根拠を明示的に残すことで、組織の暗黙知が形式知化される利点を強調しました。
3. ガードレールの構築の手引き
生成AIの出力に対する「ガードレール」の重要性を解説しました。ここで特に強調したのが「70%問題」です。これは単なる効率の問題ではなく、ロジスティクスにおける「ラストマイル問題」やロボティクスにおける「不気味の谷」に類似した現象です。完成に近づくほど、残りの課題は不釣り合いに困難になります。しかし、インフラストラクチャにおいて、この残りの30%は単に非効率なだけでなく、潜在的に壊滅的な問題を引き起こす可能性があります。
生成AIは通常、コードの約70%は驚くほど正確に生成できますが、残りの30%で致命的なミスを犯すことがあります。特にIaCのような厳密性が求められる領域では、この問題が顕著です。
- AWS IAMポリシー生成時に過剰な権限を付与する傾向
- リソース間の複雑な依存関係の理解不足
- コスト最適化を考慮しない設計提案
これを「優秀だが何も確認しない若手開発者」と表現し、スピードは速いがIaC特有の制約を無視してしまう傾向があることを指摘しました。
この問題への対策として、以下のようなガードレールを提案しました：
コード品質検証
- 構文チェック、静的解析、コーディング規約の自動適用
セマンティック検証
- リソース間の整合性や依存関係の正確性を検証
セキュリティ検証
- 脆弱性スキャン、最小権限原則の適用
コンプライアンス検証
- 組織ポリシーや法規制への適合性確認
コスト最適化検証
- リソース効率や予算管理の自動チェック
これらのガードレールは、特にPull Requestの段階で自動適用することで、問題の早期発見と修正を可能にします。また、単なる検証だけでなく、AIの解釈コストを考慮した仕様の記述方法についても言及しました。
4. ガードレールを超えて行動するMCP
最後に、Model Context Protocol（MCP）を活用した次世代のAI活用法について紹介しました。MCPはAIモデルが外部ツールやデータにアクセスするための標準プロトコルで、「AIとシステムをつなぐUSB規格」とも表現できます。しかし、この比喩は理論的な重要性を過小評価しています。USBは物理的な接続を標準化しましたが、MCPは認識論的な接続—知識がどのようにアクセス、検証、適用されるかを標準化しているのです。
- ガードレールは出力の「安全性」「品質」を確保（アウトプット品質）
- MCPは入力の「情報量」「正確性」を向上（インプット品質）
この相補的な関係は、次のような弁証法的パターンを形成します。
- テーゼ：AIは限られたコンテキストに基づいてコードを生成
- アンチテーゼ：人間はガードレールを通じてこのコードを検証・修正
- 統合：MCPはAIのコンテキストを拡張し、検証の必要性を減少（ただし排除はしない）
両者を組み合わせることで、70%問題の克服に近づける可能性を示しました。ただし、人間の判断の必要性は排除されるのではなく、人間の役割が「構文の検証者」から「概念的アプローチの検証者」へとシフトします。これは認知的労働の分担の進化を示唆しています。
実際の活用例として、AWS MCP ServersやGoogle Cloudのkubectl-aiなどを紹介し、これらがクラウド環境とAIの連携を実現し、複雑なインフラ管理を自然言語で操作可能にする機能について説明しました。
質疑応答での議論
セッション後の質疑応答では、特に以下の点について活発な議論がありました：
- AIによるIaC生成の信頼性向上のための具体的な取り組み
- 組織への導入方法とチーム全体でのAI活用ポリシー
- CI/CDパイプラインへのガードレール組み込みの実践例
特に印象的だったのは、「AIを100%信頼せず、人間の検証を常に行う文化をどう作るか」という質問で、これはまさに今のAI活用における核心的な課題だと感じました。
Day 2: MCPの世界を掘り下げる
イベント: AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒-
登壇タイトル: ここはMCPの夜明けまえ
日時: 2025年4月23日
https://hack-at-delta.connpass.com/event/350588/hack-at-delta.connpass.com
2日目は、AI駆動開発に特化したイベントで登壇しました。こちらは主にアプリケーション開発者やAI研究者が中心の聴衆で、より技術的に深い内容を求められる場でした。私のセッションではModel Context Protocol（MCP）について詳しく解説し、実装例や将来展望について語りました。
発表資料
発表の詳細
MCPの基本概念から始め、その主要構成要素について詳しく解説しました。MCPは単なる技術標準ではなく、AIシステムが知識を獲得・検証する「認識論的インターフェース」とも言えるものです。この枠組みは、人間の認知プロセスを模倣しながらも、機械による利用のために標準化しています。
1. Resources（リソース）
MCPにおけるResourcesは、LLMにコンテキストを提供する読み取り専用のデータソースです。テキスト形式とバイナリ形式のデータをURIで一意に識別し、AIの会話コンテキストとして活用します。
- アプリケーション制御型設計: クライアントがリソースの使用時期と方法を決定
- 人間が読みやすい名前や説明: AIの理解を促進するためのメタデータ付き
- 動的リソース: URIテンプレートを提供して、パラメータ化されたリソースアクセスが可能
クライアントはresources/listエンドポイントでリソース発見、resources/readで内容取得、さらに購読機能で更新通知を受信できます。これにより、AIは最新のドキュメントや構成情報などを参照しながら回答を生成できるようになります。
2. Prompts（プロンプト）
Promptsは標準化された対話パターンを定義するテンプレートです。ユーザー制御型の再利用可能なテンプレートとして設計され、一貫したLLM体験を提供します。
- 動的な対話フロー: 引数を受け取り、リソースから文脈を含め、複数の対話をチェーン化
- 構造化された定義: 各プロンプトは名前・説明・引数の構造で定義
- クライアントインターフェース:
prompts/listエンドポイントで発見し、prompts/getで使用
プロンプトはリソースからの情報を埋め込み、複数のメッセージ交換を事前定義して複雑な対話フローを作成可能です。クライアントUIではスラッシュコマンドやクイックアクションとして表示され、ユーザーに直感的な操作を提供します。
3. Tools（ツール）
Toolsは LLM に実世界での行動力を与える機能です。サーバーが公開する実行可能な機能を介して計算処理やAPI操作を実行できます。
- 明確な構造: 各ツールは名前、説明、入力スキーマ、アノテーションで定義
- 動作特性の明示: 読取専用・破壊的操作・べき等性などの情報を含む
- エンドポイント: クライアントは
tools/listで発見し、tools/callで実行
ツールの用途は多岐にわたり、システム操作、外部APIラッパー、データ変換など様々なパターンでAIの能力を拡張し、実世界での影響力を高めます。
4. Sampling（サンプリング）
Samplingは、サーバーがLLMに補完を要求できる機能です。クラスチートを行うことなく、会話中にLLMの判断を活用できる仕組みを提供します。
- メカニズム: サーバーが
sampling/createMessageを要求し、クライアントがレビュー後にLLMから結果を取得 - ヒューマンインザループ設計: ユーザーが介在することでセキュリティとプライバシーを確保
- 柔軟な設定: 様々なパラメータで出力を調整可能（temperature、maxTokens、stopSequencesなど）
サンプリングによって、エージェント的ワークフローが可能になり、データ分析、意思決定、構造化データ生成、複数ステップのタスク処理などの高度な機能を実現できます。
5. Roots（ルーツ）
Rootsはサーバーの操作範囲を定義する機能です。クライアントがサーバーに対して関連リソースとその場所を伝える手段として機能します。
- 操作境界の定義: ファイルシステムパスやHTTP URLなどの有効なURIを使用
- ワークスペース明確化: クライアントは接続時に推奨ルーツのリストを提供
- 柔軟な範囲設定: プロジェクトディレクトリ、リポジトリ、APIエンドポイントなどを定義
Rootsにより、AIの操作範囲が明確化され、異なるリソースを同時に扱う際の組織化が容易になります。
実装例と活用可能性
セッションの後半では、実際のMCP実装例を紹介しました。よく紹介されているMCPを紹介してもどうしようもないので他に知見になりそうでかつ応用が効きそうなMCPを紹介しています。
AWS MCP Servers
- AWS Documentation MCP Server: AWS公式ドキュメント検索と情報提供
- Bedrock Knowledge Bases MCP Server: カスタムナレッジベース連携
- CDK MCP Server: AWS CDKプロジェクト支援
- Terraform MCP Server: Terraformプロバイダー情報参照
- Lambda MCP Server: 任意のLambda関数をMCPツールとして実行
kubectl-ai
Google Cloudの大規模言語モデルを活用したkubectlプラグインについても解説しました。
kubectl ai "nginxのDeploymentを作成して、レプリカ数は3、リソース制限ありで" kubectl ai "なぜPodがPendingのままなのか調査して" kubectl ai "payment-serviceのレプリカを3から5に増やして"
このような自然言語コマンドでKubernetesクラスタを操作できる例を紹介し、MCPによる実用的な活用方法を示しました。
自作MCP実装の可能性
MCPの実装を通じて得られる知見の価値について触れ、「MCPは実装してこそ理解できる。実装を通じて感覚を掴み、独自の拡張も検討できる」と強調しました。
MCPの課題と展望
MCPの将来性について議論する中で、現状の課題も率直に指摘しました：
- レスポンス時間の増加: 外部API呼び出しによる遅延
- 情報統合の難しさ: 矛盾する情報の調停
- コンテキスト長の制限: 大量のデータ処理における限界
- ハルシネーション問題: 情報アクセスは改善するが、解釈ミスの可能性は残る
70%→100%ではなく、実際には70%→80%程度の改善が現実的な期待値であり、人間による最終確認は依然として重要であることを強調しました。これは漸近的な信頼性向上であり、段階的な変化ではないことを示唆しています。
この分野には以下のような興味深い理論的緊張関係が存在します。
- 信頼 vs 検証: 人間による検証の持続的な必要性は、完全に自動化された開発の約束と矛盾します。
- 一般性 vs 特殊性: AIは一般的なパターンに優れていますが、ドメイン固有の制約に苦戦する一方、人間はその逆の傾向があります。
- 速度 vs 信頼性: AIによる開発の加速は、増加する検証負担とのバランスが必要です。
- 抽象化 vs 実装: エンジニアがより抽象的な思考にシフトするにつれ、実装の詳細とのつながりが弱まり、新しい種類のエラーが生じる可能性があります。
連日登壇を通じて感じたこと
2日間の登壇を通じて、生成AIとクラウドネイティブの融合が急速に進んでいることを実感しました。特に印象的だったのは、両者の接点において：
1. 補完し合う技術領域
Day 1で話したガードレールとDay 2で紹介したMCPは、互いに補完する関係にあります。ガードレールがAIの出力の「安全性」「品質」を確保し、MCPが入力の「情報量」「正確性」を向上させます。この組み合わせこそが、AIの能力を最大限に引き出すための鍵です。
例えば、MCPで外部情報を参照しながらIaCコードを生成し、それをガードレールで検証するというパイプラインを構築することで、より信頼性の高いインフラ構築が可能になります。
これは認知労働の新たな分担を示唆しています。パターンマッチングとリコールが機械のドメインになり、概念的統合と判断が人間のドメインとして残ります。この協業体制がもたらす最も深い洞察は、我々が「プログラミングの終焉」ではなく「プログラミングの新たな改革」を目撃しているということかもしれません。
2. 実装の成熟度の差
技術の普及段階にも明確な違いがあります。Cloud Native環境でのAI活用は既に実用段階に入っていますが、MCPはまさに「夜明け前」の状態です。標準化は進んでいるものの、実装はまだ発展途上であり、今後急速に普及していくでしょう。
特に興味深いのは、大手クラウドプロバイダーが相次いでMCP実装を提供し始めていることで、これはMCPが業界標準になりつつある証拠と言えます。現在、私たちは重要な技術的変曲点に立っているのです。
3. 共通する課題
どちらの領域でも、ハルシネーション（幻覚）問題や70%問題など、AIの限界をどう乗り越えるかが共通の課題となっています。完全自動化への過信は危険であり、人間による検証と理解が依然として不可欠です。
重要なのは、AIをただの便利ツールではなく、自分の技術的判断力を強化するための「知的パートナー」として活用する姿勢です。優れたエンジニアは、AIの提案を鵜呑みにせず、自らの専門知識と経験に基づいて評価し、改善します。つまり、エンジニアとしての基本的な理解力や技術センスがあってこそ、AIとの協働が真に価値を生み出すのです。
両イベントの参加者との議論を通じて、多くの組織がAIツールの導入に熱心である一方で、その限界や適切な活用方法についての理解はまだ発展途上であることを実感しました。
MCPは単なる技術標準ではなく、AIシステムが知識を獲得し検証する「認識論的枠組み」を表しています。これはAIと人間のコラボレーションにおける根本的なシフトを示唆しています。
認知労働の新たな分業
開発現場では、AIを全能の魔法ではなく、特定の目的に特化した強力な助手として位置づけています。これは認知労働の新たな分業を形成しています。
戦略的なAI活用アプローチ
私のチームでは、AIツールを以下のような明確な目的で活用しています。
- プロトタイピングの加速: 新機能やアイデアの初期実装を迅速に行い、議論の土台を作る
- ルーティン作業の自動化: テストコード生成やボイラープレートコードなど、創造性を必要としない作業の効率化
- 知識探索の支援: ドキュメント検索やAPI仕様の理解など、情報収集を効率化
- コードレビューの補助: 基本的なコーディング規約やベストプラクティスのチェック
これらの活用方法は、AIと人間の間の認知労働の分業を最適化するものです。AIはパターン認識や情報検索に優れている一方、人間はコンテキスト理解や倫理的判断に長けています。この相補的な関係を活かすことで、開発効率と品質の両方を高めることができます。
レビュープロセスと制約の重要性
生成AIの限界を認識した上で、以下のようなガードレールを設けています。
- 書き込み権限の制限: 生成コードは必ずレビューを経てから取り込む、というかまだ道具として適切に動作し続けることができない
- 重要な判断の人間による最終確認: 特に権限設計やセキュリティ関連の実装
- 対話的な生成プロセス: 一度に大量のコードを生成するのではなく、段階的に生成・修正を繰り返す
これらの制約は一見効率を下げるように思えますが、長期的には品質と信頼性の向上につながっています。これは、速度と信頼性のトレードオフを認識し、適切なバランスを取る試みと言えるでしょう。
まとめ
生成AIとCloud Nativeは、かつて独立した技術領域として発展してきましたが、現在その境界線は急速に溶け合いつつあります。この2日間の登壇を通じて、両技術の融合がもたらす無限の可能性と避けられない課題を、互いに補完し合う視点から考察できたことは非常に意義深い経験でした。
技術の交差点に立つ私たちは、単に新しいツールを導入するだけでなく、開発プロセス全体の再構築と認知労働の新たな分担という本質的な変革の只中にいます。連日の登壇準備は骨の折れる作業でしたが、技術コミュニティの旺盛な好奇心と革新への情熱に触れることができ、その労力を遥かに上回る充実感を得ることができました。
この変革の中心には、いくつかの興味深い理論的緊張関係が存在します。信頼と検証のジレンマでは、AIの自律性向上と人間による検証の継続的必要性が矛盾します。一般と特殊の相克では、AIが一般パターンに秀でる一方、ドメイン固有の制約に弱く、人間はその逆の強みを持つという相補性があります。速度と信頼性のトレードオフでは、開発速度の飛躍的向上と増大する検証負担のバランスが求められます。そして抽象化と実装の乖離では、エンジニアの思考が高次の抽象レベルへ移行するほど、具体的実装との接点が希薄化する現象が起きています。
これらの緊張関係は、単なる技術的課題ではなく、ソフトウェア開発の本質的な変容を示唆しています。クラウドネイティブと生成AIの交差点に立つ私たちは、新たな技術パラダイムの構築者として、これらの緊張関係を認識しながら、持続可能な開発文化の創造に取り組む必要があります。
今日から俺は
今後、プログラマの役割は根本から変容していくでしょう。コードを書く職人からドメインを抽象化し構成要素を再構築する建築家へと、その専門性は高度化していきます。この変化は、ソフトウェアエンジニアリングの本質における歴史的な転換点を示唆しています。
この転換点で、エンジニアの進化には二つの道筋が開かれていると思っています。ひとつはドメインエキスパートとしての道で、AIが容易に獲得できない専門知識を磨き、AIを疑い検証するメンタリティを養い、専門知識をMCPやFunction Callingとして実装し、自らが「検証者」としての価値を高める方向性です。もうひとつはパイプライン設計者としての道で、コードを直接書くのではなく、コードを生成・検証・デプロイするシステムを構築し、プロンプトエンジニアリングの技術を磨き、言語化・設計・検証のスキルを研ぎ澄まし、AIの限界を理解しそれを補完するシステムを構築する方向性です。
これらの進化は、かつてのアセンブリから高水準言語への移行や、手続き型からオブジェクト指向プログラミングへの移行に似ています。各移行は低レベルの懸念事項を抽象化し、エンジニアがより高レベルのアーキテクチャに集中できるようにしてきました。私たちはいま、そのような歴史的変革の真っただ中にいるのです。
最後に、この貴重な機会を提供してくださったCloudNative Days Summer 2025プレイベントおよびAI駆動開発実践の手引きイベントの運営チームの皆様に心より感謝申し上げます。両イベントの緻密な運営と温かいサポートのおかげで、充実した登壇体験ができました。また、質疑応答で鋭い質問を投げかけ、議論を深めてくださった参加者の皆様にも深く感謝いたします。これからも技術コミュニティの発展に微力ながら貢献していきたいと思います。
あとがき
1日目の資料は出来があまりよくなかった。良い資料だとは思うが自分の中でもう少し整理や深堀りができたはずだし、語り尽くせなかった部分もとても多い。時間がなかったという言い訳をさせてください。そもそも、CfPも落ちて本イベントでの登壇の機会も逸してしまっている。
一方、2日目のMCPの資料はよくできたと思う。元々のブログがあったというのもある。正直これは100点満点中90点ぐらいの出来栄えだと自負していた。夜を徹して準備し、最新の技術動向を盛り込み、実装例も丁寧に解説した。聴衆からの反応も上々で、「これ以上ない資料ができた」とさえ思っていた。
そんな矢先、mizchi氏のAfter Cline - あるいは語りえぬ者について語ろうとする時代についてという資料を目にした瞬間、天と地の差を見せつけられた気分だった。あれは単なる150点の資料ではない。次元が違う。まるで将棋で「自分は十分に読んだ」と思った直後に、相手が5手先の必勝手順を淡々と指し示すような絶望感。
技術的な深さ、哲学的考察、そして何より言語化能力の圧倒的差...。悔しさで夜も眠れない。次回こそは、このリベンジを果たしてみせる。いや、リベンジすらおこがましい。あの高みに少しでも近づけるよう、もっと考察を深めなければ。とにかく、とても、とても悔しい...。
