AI は「動く構成」を出せても、「本番で守れる構成」を出すには設計責任を肩代わりしません。
現場のクラウドエンジニア目線で、AIの提案が「とりあえず動く」方向へなびいてしまう構造的な罠を、実例とともに言語化していきます。
はじめに
生成 AI の進化により、クラウドの構成ファイル（Bicep / Terraform / CloudFormation）を、専門家でなくとも数分で書き起こせる時代になりました。
しかし筆者は、「動くこと」と「本番運用に耐えること」の間には依然として大きな溝がある と感じています。もちろんプロンプトの書き方で多くのことは解決が可能ですが、それでもプロンプトを作成するためにここで述べるような経験や知識が必要です。
本記事では、この溝を 4 つの設計の軸 と 2 つの実例 で整理し、AI とプロの役割分担を提案します。AI 活用を否定する意図はありません。「どこまで AI に任せ、どこからプロに任せるべきか」 を判断する材料を提供することがゴールです。
- 対象読者: 生成 AI でクラウドを触り始めたエンジニア、AI 活用を推進する意思決定層
- 扱うこと: AI 生成構成に潜む典型的リスクの全体像
- 扱わないこと: 個別ツールのハンズオン
背景：なぜ今この話をするのか
筆者の周囲でも、「生成 AI に Bicep を書かせてそのままデプロイした」という話を頻繁に耳にするようになりました。
一見すると az deployment は成功し、リソースは立ち上がります。問題は、その構成が組織のセキュリティ基準・可用性要件・コスト制約を満たしているかどうかは、誰も検証していない ケースが多いことです。
クラウドは「設定一つで全世界に公開できてしまう」性質を持ちます。設計の落とし穴は、本番投入後に事故という形で初めて表面化します。
AI が構造的に苦手な 3 領域
本論に入る前に、この後の 4 軸を読む際の「レンズ」を提示しておきます。生成 AI は以下の 3 領域において、モデル規模やプロンプトの工夫では埋まらない構造的なギャップ を抱えていると筆者は考えています。
| ギャップ | 内容 | なぜ AI には難しいか |
|---|---|---|
| 現場の経験値 | 「この設定で過去にハマった」という身体感覚 | 学習データはドキュメントの「成功例」に偏り、現場の失敗談は表に出にくい |
| 事例の採取 | 他社インシデントや整理された設計パターン | 最新事案や社内事例は学習されておらず、背景の説明ができないまま使われがち |
| コンテキスト理解 | SLA / RTO / コスト上限 / 部門間の力学などの業務文脈 | プロンプトに含めなければ推論できず、含めてもトレードオフ判断は機械的になる |
以下の 4 軸は、この 3 ギャップのいずれかに踏み込んだときに AI 任せでは壺にはまる領域 です。
軸 1：境界防御の理解 — NSG と NAT の落とし穴
まず前提として、生成 AI は「動くこと」を最優先に最適化されています。明示的に「セキュリティを考慮して」と指示しない限り、トラブルシュートやサンプルコードを学んだモデルは 「とりあえず通信が通る」方向にバイアスがかかります。
境界防御においては、段階的に許可が広がる流れ が起きます。ネットワーク領域では特に「切り分けに必要な観点」が AI には欠けているため、原因究明より先に ルール緩和の提案 に流れがちです。
- 最初は限定的なルールで提案される: AI も最初は「送信元 IP は社内レンジのみ」「Service Tag を絞る」など、それなりに妥当な NSG (Network Security Group) ルールを出してきます
- 想定外の経路で疎通しない: NAT Gateway の SNAT (Source NAT) 後の送信元 IP、プロキシ経由のアクセス、Service Endpoint と Private Endpoint の併用時の挙動など、経路依存の罠 で接続テストが失敗します
-
「
0.0.0.0/0で一旦通しましょう」となる: 経路を読み解く代わりに、AI は宛先・送信元を広げる修正を提案してきます。InternetService Tag 許可や、0.0.0.0/0 → SSH/RDP 許可が「テスト用」として残るのもこのパターンです
しかも厄介なのは、こうして広がったルールは 「動作確認」では一切エラーにならない ことです。az deployment は成功し、Defender for Cloud でアラートが上がる、あるいは監査ログを読み解いて初めて違和感に気づく、というのが現場の実感です（NSG の仕組み）。
ここで AI に足りないのは「現場の経験値」です。
境界防御の設計は 「このシステムは誰が・どこから・どの経路で使うのか」「守るべき資産はどれで、どの脅威モデルを想定するのか」 に紐づいた 個別解 が求められる領域です。同じ「Web アプリ + DB」構成でも、社内利用専用なのか、グローバル公開なのか、決済データを扱うのかで、必要な NSG ルール・Private Endpoint の貼り方・NAT Gateway の要否はまったく変わります。AI は一般論は出せても、この個別解にたどり着くための切り分け —「想定外の通信を踏んで原因を追った経験」— の蓄積がまだありません。
軸 2：Entra ID とゼロトラスト — 最小権限の本当の意味
権限設計でも AI は「許可を狭める」よりも「作業が止まらない」ことを優先します。ただし最初から広めの権限を提案してくるわけではなく、現場ではむしろ次のような 段階的に権限が広がる流れ をよく見かけます。
-
最初は最小権限で提案される: AI は素直に「
Storage Blob Data Readerを付けましょう」のような最小ロールを出してきます - その情報が古い／ハルシネーションで誤っている: クラウドの権限まわりは進化が早く、ロール名・操作対応・必要なデータプレーン権限が AI の学習時点とズレていることが頻発します
-
動かない: デプロイや実行時に
AuthorizationFailed等で失敗します -
「権限を広げましょう」と AI が提案する: 原因の特定よりも 「とりあえず
Contributorに上げれば通ります」 という提案に流れます
こうして当初の最小権限はなし崩しに広がり、最終的には Contributor や Owner がぶら下がった構成に落ち着きます。これは ゼロトラストの思想と真逆 です。
Microsoft の公式ガイダンスは、最小特権アクセスを中核原則の一つとして掲げています（ゼロトラストの基本原則）。具体的には次の判断が必要です。
- マネージド ID を使い、シークレット配布そのものを廃止する
- ロールはビルトインの最小単位、もしくはカスタムロールで「必要な操作のみ」に絞る
- 条件付きアクセス・PIM (Privileged Identity Management) で時限的に権限を付与する
たとえば「デプロイ用 SPN に Contributor を Subscription スコープで付ける」という提案は AI からよく出てきます。しかし現場では、Resource Group スコープ + Contributor より狭い RBAC（例：Website Contributor + Storage Blob Data Contributor）に分解するのが正解です。この「分解」はアプリの何がどのリソースに触るのかを知らないとできません。
AI は「アプリが動くロール」を選びますが、「最小のロール」を選ぶには業務文脈の理解が必要 です。
ここで AI に足りないのは「コンテキスト理解」です。
権限設計は「アプリの振る舞い × 運用者の人数と役割 × 監査要件」の換算で決まります。この三者はコードベースだけでは見えず、ヒアリングや運用規約の読み込みが不可欠です。
軸 3：設定不備とクラウドベンチマーク
業界には、設定不備を体系的に防ぐためのベンチマークが整備されています。代表例は CIS (Center for Internet Security) Benchmarks（CIS Benchmarks 一覧）や、Azure であれば Microsoft Cloud Security Benchmark (MCSB)（MCSB 概要）です。
これらは「Storage の匿名アクセスを無効化する」「診断ログを Log Analytics に送る」など、事故の事前条件を潰すための数百項目のチェックリスト です。
AI を活用すれば、「この構成は MCSB のどの項目に違反しているか」といった一次的な評価そのものは十分にこなしてくれます。背景となる事故事例や項目の意図についても、聞けば一通りの説明は返ってきます。
問題はその先です。現場では「この Storage は『社外公開なし』だから publicNetworkAccess: 'Disabled' にしよう」「この Cosmos DB は『コンプライアンス上ローカル認証禁止』なので disableLocalAuth: true」という判断を、ベンチマーク項目と社内規約・業務要件の両方を照らして選んでいます。さらに、ベンチマークどおりにすると業務が回らない項目については、代替コントロール（補完統制）でリスクを下げる折衷案 を検討する必要もあります。Defender for Cloud や Azure Policy で継続的に評価する運用設計まで含めて、初めて「設定不備を防ぐ」と言えます。
ここで AI に足りないのは「コンテキスト理解」です。
ベンチマーク項目の評価は AI に任せてかまいません。しかし 「この項目を自社のこの業務に当てはめると準拠すべきか、例外申請すべきか、補完統制で代替するか」 という判断は、社内のセキュリティポリシー・業務制約・監査要件を踏まえて初めて下せます。AI は「準拠／非準拠」のラベルは付けられても、準拠しない選択肢を含めた折衷案の提案 までは踏み込めません。
軸 4：Well-Architected の理解
Microsoft / AWS / Google いずれも、設計の柱として Well-Architected Framework を提示しています（Azure Well-Architected Framework）。柱は概ね次の 5 つです。
| 柱 | 観点 |
|---|---|
| 信頼性 | 障害時に止まらない / 復旧できるか |
| セキュリティ | 多層防御・最小権限・監査 |
| コスト最適化 | 必要な分だけ払う設計 |
| オペレーショナルエクセレンス | 運用しやすい / 観測可能か |
| パフォーマンス効率 | スケーラビリティと応答性 |
AI が出す構成は、しばしば 「信頼性」と「セキュリティ」が後回し になります。SLA・RTO/RPO・ログ保持期間といった 要件は人間が定義しなければならない からです。つまり、指示を出す人間側が考慮せずにやりたいことだけを書くという状況から「後回し」が発生しています。
さらにWell-Architected の本質は 柱同士のトレードオフ です。たとえば：
- コストを下げるために SKU を落とすと、信頼性（ゾーン冗長）を犠牲にしている
- セキュリティを上げるために Private Endpoint を入れると、運用複雑度が上がる
- 可観測性を上げるためにログ量を増やすと、コストが許容範囲を超える
この「どこを取ってどこを捨てるか」の判断は、顧客の事業・ステークホルダーの顔ぶれ・SLA に紐づくペナルティを知っていて初めて可能 になります。AI は「ベストプラクティス」を述べられますが、「特定の顧客のベストプラクティス」は提示できません。
ここで AI に足りないのは 3 領域のすべてです。
現場の経験値（柱をひとつ上げたときの肌感）、事例の採取（他社が同じトレードオフで何を選んだか）、そして顧客コンテキストの理解、この三者が揃って初めて「このシステムに合った Well-Architected」が描けます。Well-Architected はチェックリストではなく、設計者の思考フレームワークです。
現場で起きていること — 2 つの実例
ここまでの 4 軸は「設計として理解しておくべきこと」でした。
ここからは少し角度を変えて、実際に起きた／起きている事象 を 2 つ取り上げます。前者は公開された大規模事案、後者は筆者自身が現場で何度も遭遇してきた小さな積み重ねです。
実例 1：S3 のような事故はなぜ繰り返されるのか
クラウドの設定不備に起因する事故は、これまで何度も報道されてきました。代表例として、2019 年の Capital One 事案 では、WAF の設定不備をきっかけに S3 上の約 1 億件規模の顧客データが流出したと報じられています（米司法省プレスリリース）。
ポイントは、「S3 そのものの脆弱性」ではなく「設定と権限設計の組み合わせ」が事故の本質 だった点です。AI は個別リソースの安全な設定例は出せますが、組織横断の権限境界まで含めた脅威モデリング は守備範囲外です。
実例 2：シークレットを環境変数やコードに置いてしまう
これは筆者自身が実際に何度も遭遇してきた問題です。
プロトタイプ段階で「動かすため」に、接続文字列や API キーを次のように扱ってしまうケースです。
// アンチパターン：パラメータに平文で渡してしまう
param sqlConnectionString string
// アンチパターン：環境変数経由でアプリに直接渡す
const conn = process.env.SQL_CONNECTION_STRING;
短期的には動作しますが、ビルドログ / 環境変数ダンプ / コンテナイメージのレイヤー など、想定外の場所に痕跡を残します。AI に「シークレットを使うコード」を頼むと、こうした構成を平然と提案してきます。
本来は次の方針を取るべきです。
- マネージド ID + Key Vault 参照 を基本とし、シークレットそのものをコードから消す（Key Vault references for App Service）
- どうしても必要な場合のみ
@secure()パラメータと Key VaultgetSecret()を組み合わせる - リポジトリには シークレット検出ツール（GitHub secret scanning 等） を必ず適用する
// 推奨：Key Vault を参照（bicepparam 経由）
@secure()
param sqlConnectionString string
この判断は 「動く構成」を出すだけの AI には任せきれない領域 だと感じています。
ではAIをどう使うべきか
ここまで批判的に書きましたが、AI は明らかに有用です。何を AI に任せ、何を人間が背負うかの線引きは チームやシステムの事情によって変わる ものなので、本記事で正解を提示するつもりはありません。
ひとつだけ筆者の経験から言えるのは、AI を「下書きと壁打ち」、プロを「設計責任とレビュー」 という距離感に置いたときに、双方の強みが噛み合いやすいということです。最終的な線引きは、ぜひ皆さんの現場で議論してみてください。
まとめ
- AI は構文を出すのが速いが、設計判断は肩代わりしない
- AI が構造的に苦手なのは 現場の経験値 / 事例の採取 / コンテキスト理解 の 3 領域であり、4 軸も 2 実例もすべてこのいずれかに踏み込む
- 「動く」と「守れる」「止まらない」「説明できる」は別物です
- AI は 下書きを高速化する道具、プロは 設計責任を負う担い手 という役割分担が現実解
- 本番を背負う構成は、最後の一線でプロのレビューを通す ことを推奨します
さいごに — スペシャルサンクス
本記事を書き始めた直接のきっかけは、伊勢川 暁さん (@Akira-Isegawa) の記事 「エンジニア歴 20 年の私が、素人バイブコーディング勢に物申す」 に深く感銘を受けたことでした。
セキュリティ・コスト・データ設計・運用に対する敬意と、それでも挑戦者を迎え入れようとする温かさが両立した本記事は、「職業倫理を言葉にするとはこういうことか」 と筆者に原点を思い出させてくれました。本記事はその記事のインフラ / クラウド設計領域への 応答試案 として書いています。
伊勢川さんの記事と、それを読んで「自分も現場の言葉で何かを残さねば」と思えたこの気持ちに、この場を借りて心から感謝を申し上げます。本当に、ありがとうございました。