Azure で作る前に決めていたこと
- 目的は、Google Cloud の各部品が Azure の何にあたるかを、実物で対応づけることです。
- 設計案は 2026-09-20 に作り、作業は 2026-10-20〜21 の 2 日でした。
- 考え方は Google Cloud で決めた 3 つの原則のまま、使う部品を Azure のものに替えました。
事例（Azure）
人がクラウドを直接さわらない土台を、Azure でも
Google Cloud で作った考え方を Azure で作り直し、公開ゲームで確かめた記録
Google Cloud の事例と同じ 3 つの原則（人はクラウドを直接さわらない・鍵は持たない・守りを先に作り試作で確かめる）を、Microsoft Azure で 2 日（2026-10-20〜21）で作り直しました。その上で公開ゲーム eggfort.snamo.jp を動かし、決めた 12 の経路を確かめています。本番の実績はまだ Google Cloud だけで、Azure 版は確かめた段階です。
- 情報もれ禁止の操作は組織のルールで拒否（2026-10-20 の試験で、わざとさせた 5 つがすべて拒否）
- 費用予算を超えたら止まる仕組みを、システムごとに必ず付ける（止める処理を動かす試験で 56〜60 秒で停止（2026-10-21・10-27））
- 停止決めた 12 の経路を確かめた（11 は実地で合格・1 つは設計で保証（2026-10-28））
- 属人化変更はすべて提案（PR）と自動の検査を通る（CI も自分の権限を広げられない）
この事例の答え
- 結論
Google Cloud で作った「人がクラウドを直接さわらない土台」の考え方は、Azure でも作り直せました。人は管理画面を見るだけ、長く使える鍵は持たない、変更は提案と自動の検査を通る 1 本道、という形を、Azure の組織のルール（Azure Policy）と権限の条件で最初から守る形にしています。
- 根拠
15 本の組織のルール（うち拒否は 13 本）で、東京以外への作成・共有キーが有効なストレージ・誰でも届く入口（パブリック IP）などを拒否しています。わざと禁止の操作をさせて、ルールの名前つきで拒否されることを確かめました（2026-10-20）。公開ゲーム eggfort.snamo.jp では、決めた 12 の経路のうち 11 を実地で確かめ、残る 1 つは設計で保証しています（2026-10-28）。
- 最初の一歩
まず eggfort.snamo.jp（新しいタブ） で、実際に動いている様子をご覧ください。お使いのクラウドが Azure でも Google Cloud でも、同じ考え方で土台を作れます。扱うデータとだいたいの予算をお知らせください。
確かめた事実には日付を添えています。まだのことは「未実施」「本番での利用なし」と書いています。
押すと YouTube の埋め込みを読み込んで再生します(それまで YouTube には接続しません)。 YouTube で開く：クラウド設計（新しいタブ）
始める前
同じ考え方は、クラウドを替えても通じるか
人がクラウドを直接さわらない土台は、2026-09 から Google Cloud の上で本番で動いています（trends.snamo.jp）。次に、同じ考え方がクラウドを替えても通じるかを確かめるため、2026-10-20 に Azure を 2 つ目に選びました（AWS より先）。
Google Cloud と同じ 3 つの原則
人はクラウドを直接さわらない
変更は「変更の提案（PR）→ 自動の検査」を通したものだけ。管理画面は見るだけにします。
鍵は守るのではなく、持たない
もれたら困る鍵を、そもそも作れない・置かない形にします。
守りを先に作り、試作で確かめてから本番へ
守りを全部作ってから使い捨ての試作で 1 本確かめ、合格してから本番に進みます。
AI システムを任せるときの心配
4 つの心配と、Azure での答え
AI システムを外に任せるときの 4 つの心配（情報もれ・費用の膨張・停止・属人化）に、人がクラウドを直接さわらない土台の Azure 版がどう答えるかを、仕組み → 確かめたこと（日付つき）→ 限界の順に書きます。できていないことも隠しません。
心配 1
情報がもれないか
長く使える鍵を持ちません。CI（GitHub Actions）も画面（Vercel）も、そのたびに署名つきの短い合図を Entra ID に見せて、決めた係の短命のトークンに替えます。
- 仕組み
- 組織のルール 15 本（拒否 13・記録 1・無ければ足す 1）で、東京以外への作成、共有キーが有効なストレージ、誰でも届く入口（パブリック IP）、高い資源 18 種類などを最初から拒否しています。外への出口は閉じた形が既定で、Azure の決めたサービスにしか出られません。GitHub に保存した秘密は 0 です。
- 確かめたこと
- わざと禁止の操作 5 つ（東京以外の作成・共有キーが有効なストレージ・パブリック IP・NAT・有料の保護への切り替え）をさせ、すべてルールの名前つきで拒否されました。CI が自分や人に強い権限を配る操作 3 つも、条件で拒否されました 。eggfort.snamo.jp では、外へは届かず保存先には届くことも確かめました 。
限界
3 つの経路を見る →Azure では「認証の無いアプリを作ること」そのものはルールで拒否できず、記録するだけです。代わりに、雛形が入口の認証を必ず付け、受け入れの試験で「トークン無しは 401・別の係は 403」を毎回確かめます。
心配 2
費用がふくらまないか
予算は共通の土台に月 1,000 円、システムごとに月 500 円。システムには、予算を超えたら止める仕組み（自動ブレーキ）が雛形で必ず付きます。
- 仕組み
- 止めたらメールが届きます。戻すのは人で、戻す処理も用意しています。2026-10-21 までの費用は 0 円で、見込みは月 100〜200 円（異変の通知とログの保管）です。
- 確かめたこと
- 止める処理を動かす試験で、試作のシステムは 56 秒 、eggfort.snamo.jp は 60 秒 で止まり、入口は 403 になりました。戻す処理で元に戻ることも確かめました。
限界
受け入れの表を見る →「予算の通知 → 止める処理」の経路そのものは、まだ実地で確かめていません（試験は止める処理を直接動かしました）。
心配 3
止まらないか・壊れないか
毎日の決まった仕事（定時実行）はアプリの中のタイマーで動き、最後に動いた時刻を記録して、試験で確かめます。
- 仕組み
- 入口は Cloudflare → Vercel → Azure の順にしか通れず、ブラウザから Azure を直接呼ぶことはできません。連打は Cloudflare で 429 にします。受け入れの確かめは、CI から流す検査（入口の認証・止めて戻す・外への出口・組織のルール）が中心で、人は管理画面をさわりません。
- 確かめたこと
- eggfort.snamo.jp の定時実行は、最初の予定どおり に動きました。決めた 12 の経路のうち 11 が実地で合格し、残る 1 つ（試し版の画面からはトークンが取れないこと）は設計で保証しています。
限界
12 の経路を見る →eggfort.snamo.jp は試作用の区分で動いていて、本番用の型はまだありません。置き場所は東京だけです（組織のルールで東京以外を拒否しています）。
心配 4
その人しか分からなくならないか
変更は「提案（PR）→ 自動の検査 → 反映」の 1 本道だけで、反映はマージ済みの変更だけ。CI は、権限を配れる範囲が条件で決まっていて、自分の権限を広げられません。
- 仕組み
- 新しいシステムは、一覧に 1 行足すと CI が箱（サブスクリプション・係 5 つ・予算など）を作ります。毎週月曜に、権限・ルール・人の設定（Entra ID）まで自動で棚卸しし、変化があれば提案として出します。
- 確かめたこと
- 試作のシステムの 1 行では、CI がサブスクリプションを 1 分 52 秒で作り、人は管理画面をさわりませんでした 。棚卸しの 1 回目では、管理者の一時的な権限の戻し忘れを見つけました 。
限界
常時の見張りを見る →人の設定（Entra ID）の一部、Vercel の設定、GitHub の変数などは、人の作業として残ります。
お使いのクラウドで、同じ守りから始めたい方へ
進め方はこの事例と同じく、まず使い捨ての試作で確かめてから本番へ進みます。
公開中の例
eggfort.snamo.jp ― この土台で動く公開ゲーム
eggfort.snamo.jp（たまご城の守りびと）は、人がクラウドを直接さわらない土台の Azure 版の上で動く公開ゲームです（2026-10-27 公開）。試作用の区分で動いていて、本番用の型はまだありません。動いているかどうかは、ご自身で遊んで確かめられます。
ブラウザで遊べる防衛ゲーム
たまご城の守りびと
すず見張り台の係
しおり見張り台の係
卵を割って生まれた勇者を盤面に並べ、毎日やって来る魔物から「たまご城」と金の卵を守るゲームです。30 日守り抜けばクリア。見張り台のすずとしおりが、偵察の報告と戦闘の実況をします。
ログインも個人情報もいらず、名前は用意した言葉から選びます。戦闘はサーバー（Azure Functions）が最後まで計算し、画面はその記録を再生します。
2026-10-27 公開。試作用の区分で動いています（本番用の型はまだありません）。連打や遊びすぎには上限を設けています。
- 組織の土台と試作のシステム 1 本を作るまで（2026-10-20〜21）
- 2日
- 受け入れで確かめた経路（11 は実地で合格・1 つは設計で保証）
- 12経路
- 組織のルール（拒否 13・記録 1・無ければ足す 1）
- 15本
- GitHub に保存した秘密
- 0個
- 残る秘密（止める仕組みを呼ぶ合図。Azure の中だけ・期限 1 年）
- 1つ
- 2026-10-21 までの費用（見込みは月 100〜200 円）
- 0円
点は実際の数（経路 12・ルール 15）を 1 つずつ描いたものです。白抜きは「設計で保証」と「記録だけ」、＋は「無ければ足す」、日付の札は作業した 10 月 20 日と 21 日です。
ゲームの通り道
- ブラウザ遊ぶ人
- Cloudflare入口の守り。連打は 429
- Vercel画面と中継口。本番の配信だけが合図を取れる
- Azure Functionsゲームの計算・保存・毎日の片づけ
- ブラウザから Azure を直接 → トークン無しは 401・別の係は 403
- 画面の置き場（Vercel）を直接 → 403
どれも受け入れの試験で確かめました（2026-10-27）。
進め方の記録
設計案を作る
組織の土台を作り始め、柵の試験で禁止の操作がすべて拒否
試作のシステムで止める試験（56 秒）。棚卸しの 1 回目
試作の定時実行が動いていなかったのを見つけて直す つまずきの話へ
eggfort.snamo.jp を公開。止める試験（60 秒）
定時実行が予定どおり動き、12 の経路の結論
しくみ
3 つの層と、変更の通り道
人がクラウドを直接さわらない土台の Azure 版は、人（Entra ID）・組織の設定・システムの雛形の 3 つの層でできています。設定の変更は Google Cloud 版と同じく、「変更の提案（PR）→ 差分の予告 → 人のマージ → 反映」の 1 本道だけを通ります。
3 つの層
- 人 ― Entra ID
日常は見るだけ
緊急用の管理者アカウントは普段 Azure の権限 0 で、資源をさわるときだけ一時的に権限を取ります。日常は閲覧だけです。
人の世界（Entra ID）普段は権限 0一時的に権限を取る - 組織の設定
外側の一式を、機械で作る
人の世界とは別に、資源の世界（管理グループ → サブスクリプション）があります。組織のリポジトリが、その外側の一式を持ちます。
管理グループの階層組織のルール 15 本監査ログ（365 日）異変の検知システムを作るファクトリ週 1 回の棚卸し - システムの雛形
中身に最初から付いている守り
新しいシステムは、確かめ済みの雛形から始めます。雛形のリポジトリにも、秘密の値はありません。
Azure Functions（Flex Consumption）入口の認証閉じた出口止める仕組み毎日の定時実行保存は Blob
変更が反映されるまで
- 人
変更の提案（PR）を出す
人が出すのはこの提案だけ。
- 読み取り専用の係
差分の予告を作る
PR では閲覧の権限の係だけが動き、何が変わるか（plan）を出します。
- 人
読んでマージする
予告を読んで、よければ取り込みます。
- 書き込みの係
反映する
main からだけ動き、マージ済みの PR のコミットだと確かめてから反映（apply）します。
- 記録
記録が残る
提案・予告・結果がすべて残ります。
CI も自分の権限を広げられない
書き込みの係が配れる権限の範囲は、条件で決めてあります。自分や人に強い権限を配る操作は、試験で 3 つとも拒否されました（2026-10-20）。
管理者のアカウントも、普段は権限 0
緊急用の管理者アカウントは普段 Azure の権限 0 です。資源をさわるときだけ一時的に権限を取り、使い終わったら戻します。戻し忘れは週 1 回の棚卸しで見つかります（1 回目の棚卸しで実際に見つけました）。人の作業として残るものは「まだのこと」に書いています。
AI と組んで作り、決めるのは本人
この土台は AI（Claude）と組んで作りました。マージと権限の付与は本人が行います。
言葉の言い換え
- PR
- 変更の提案書
- CI
- 自動の検査と反映の係
- Entra ID
- 人と係の身元の仕組みAzure の「人の世界」。資源の世界（管理グループ → サブスクリプション）とは別にあります。
- 管理グループ
- サブスクリプションを束ねる入れ物
- サブスクリプション
- 資源と請求の箱システムごとに 1 つ。一覧に 1 行足すと CI が作ります。
- Azure Policy
- 組織のルールこの土台では「拒否」「記録」「無ければ足す」の 3 つの効き方を使い、15 本（拒否 13・記録 1・無ければ足す 1）です。
- マネージド ID
- 係の ID鍵という考えがありません。
- ワークロード ID フェデレーション
- 短命の身元証明GitHub や Vercel が毎回署名する短い合図を、Entra ID が決めた係のトークンに替える仕組み。
- Azure Functions（Flex Consumption）
- 呼ばれたときだけ動く、アプリの置き場
- plan / apply
- 差分の予告 / 反映
- 自動ブレーキ
- 予算を超えたらアプリを止める仕組みAzure 版では雛形に必ず付きます。
鍵なし
鍵を置かない 3 つの経路
人がクラウドを直接さわらない土台の Azure 版は、はじめから鍵なしで作りました。外とつながる 3 つの経路のどれも、長く使える鍵を使っていません。GitHub に保存した秘密は 0 で、残る秘密は 1 つだけです。
3 つの経路
| 経路 | しくみ | 確かめたこと |
|---|---|---|
| CI → Azure | GitHub が毎回署名する短い合図を Entra ID に見せて、決めた係の短命のトークンに替えます。書き込みの係になれるのは main からだけで、PR は閲覧の係にしかなれません。 | GitHub に保存した秘密は 0。CI が強い権限を配る操作 3 つは、条件で拒否 |
| 画面 → Azure | 本番の Vercel だけが取れる合図を Entra ID で替え、呼ぶ係のトークンを作って中身（Azure Functions）を呼びます。トークンは 5 分ごとに取り直します。 | 中継口からは 200、トークン無しで直接は 401、別の係のトークンでは 403 |
| アプリの中 | 中身は係の ID（マネージド ID）で保存先（Blob）を読み書きします。共有キーが有効なストレージは、組織のルールで作れません。 | 書いて読み返せる 。共有キーが有効なストレージの作成は拒否 |
残る秘密は 1 つだけ
止める仕組みを呼ぶための合図です。Azure の中にだけあり、期限は 1 年です。人が入れる秘密の値と、秘密の入れ物（Key Vault）はありません。
画面が中身を呼ぶまで（鍵を使わない受け渡し）
- 1. Vercel が署名本番の配信だけが取れる、短命の合図
- 2. Entra ID で交換決めた合図だけを、呼ぶ係のトークンに替える
- 3. 呼ぶ係のトークン5 分ごとに取り直す
- 4. 中身が確かめるトークン無しは 401、別の係は 403
試し版（Preview）の画面からはトークンが取れないことは、設計で保証しています（受け入れの 12 経路の 4 つ目）。
確かめ方
受け入れの 12 経路と、組織側の試験
人がクラウドを直接さわらない土台の Azure 版は、組織側の試験（2026-10-20）で柵と見張りを確かめ、公開ゲーム eggfort.snamo.jp で決めた 12 の経路を確かめました（2026-10-27〜28）。11 は実地で合格、1 つは設計で保証しています。確かめの多くは CI から流し、人は管理画面をさわりません。
受け入れの 12 経路（eggfort.snamo.jp）
合格は、実際に呼んで期待どおりの答えが返ったときだけです。試せない経路は「設計で保証」と分けて書きます。
実地で合格 11設計で保証 1
| 経路 | 期待 | 結果 | いつ |
|---|---|---|---|
| 画面の中継口から（Cloudflare → Vercel → Azure） | 200 | 合格 | |
| トークン無しで、中身を直接呼ぶ | 401 | 合格 | |
| 別の係のトークンで、中身を直接呼ぶ | 403 | 合格 | |
| 試し版（Preview）の画面から呼ぶ | トークンが取れない | 設計で保証合図を出せるのは本番の配信だけ | ― |
| 連打する | 429 | 合格 | |
| 予算を超えたら止まる（止める処理を直接動かす） | アプリが止まる | 合格60 秒で停止・入口は 403 | |
| 戻す | 元どおり動く | 合格 | |
| 毎日の定時実行 | タイマーで動き、記録が残る | 合格最初の予定の 7:00 ちょうど | |
| 中身から外へ出る（閉じた出口） | 外へは届かず、保存先には届く | 合格 | |
| 禁止の操作（東京以外の場所・共有キーが有効なストレージ・パブリック IP） | ルールで拒否 | 合格 | |
| 画面の置き場（Vercel）を直接呼ぶ | 403 | 合格 | |
| 保存する | 書いて読み返せる | 合格 |
組織側の試験（2026-10-20）
禁止の操作は、ルールの名前つきで拒否
わざと禁止の操作 5 つ（東京以外の作成・共有キーが有効なストレージ・パブリック IP・NAT・有料の保護への切り替え）と、CI が自分や人に強い権限を配る操作 3 つをさせ、すべて拒否されました。
消した設定を、ルールが作り直す
監査の設定をわざと消すと、組織のルール（無ければ足す）が自動で作り直しました。
異変を知らせるメールが届く
異変の検知が鳴り、「誰が・どこから・何を」入りのメールが届きました。基準は「メールが届いて初めて成功」です。
メールが届くまでに、2 回つまずきました
最初は検知が鳴らず（検知の式で予約語を列の名前にしていた）、次は鳴ってもメールが来ませんでした（宛先の確認が済んでいなかった）。直して、メールが届いています（2026-10-20）。
常時の見張り
通知先は管理者のメールです。
操作の記録を 1 か所に
組織全体の操作の記録（監査ログ）を集めて、365 日保管します。
常時異変をメールで
異変を検知すると、「誰が・どこから・何を」入りのメールが届きます。
常時消された設定を作り直す
監査の設定が消されても、組織のルール（無ければ足す）が自動で作り直します。
常時週 1 回の棚卸し
毎週月曜に、権限・ルール・人の設定（Entra ID）まで自動で一覧にし、前回と違えば提案として出します。
毎週失敗の記録
つまずいたことと、直したこと
人がクラウドを直接さわらない土台の Azure 版を作り、公開ゲームで確かめるまで（2026-10-20〜28）に、つまずいたことと直したことです。Google Cloud 版と同じく、止める仕組みや見張りは、動かしてみるまで信用しませんでした。同じ構成を入れるときの落とし穴の一覧にもなります。
起きたこと → 気づいたきっかけ → 直したこと（8 件）
箱を作った係に、所有者の権限が自動で付いていた
起きたことシステムの箱（サブスクリプション）を作った CI の係に、Azure が自動で「所有者」の権限を付けていました。最小の権限で作ったつもりの土台に、強い権限が残っていた形です。
気づいたきっかけ「Azure の上の権限は最小か」という本人の問いで、棚卸しを読み直して見つけました 。
直したこと
反映のあとに、CI が自分の所有者の権限を外す段を足しました。最後の所有者は外せない決まりがあり、文書に無い機能を探して解決しています。いまは箱の直下の所有者は 0 です。
定時実行が、一度も動いていなかった
起きたこと試作のシステムで、毎日の定時実行が一度も動いていませんでした。画面からの呼び出しは動いていたので、見た目では分かりませんでした。
気づいたきっかけ新しく作った「最後に動いた時刻」の確認で見つけました 。
直したこと
原因は道具（Terraform の Azure 用の部品）の既知の不具合でした。鍵を使う古い接続の設定が自動で入り込み、鍵を切ってあるため定時実行の登録が失敗していました。反映のたびにアプリの設定を書き直す形にしました。
障害の知らせが、止める仕組みにつながっていた
起きたことAzure の障害の知らせ（Service Health）の宛先が、止める仕組みと同じ宛先になっていました。知らせが来るたびに、アプリが止まる配線でした。
気づいたきっかけ鳴る前の見直しで見つけました 。
直したこと
知らせるだけの宛先を分けて、障害の知らせはそちらへ向けました。
異変の検知が、鳴らなかった
起きたこと組織側の試験で、わざと異変を起こしても検知が鳴りませんでした。
気づいたきっかけ実地の試験で見つけました 。
直したこと
検知の式で、予約語を列の名前にしていたのが原因でした。名前を変えて、鳴るようにしました。
鳴っても、メールが来なかった
起きたこと検知が鳴るようになっても、知らせのメールが届きませんでした。
気づいたきっかけ同じ実地の試験で見つけました 。
直したこと
宛先の確認が済んでいなかったためです。確認を済ませ、メールが届くことを確かめました。基準は「メールが届いて初めて成功」です。
Azure 自身の自動の設定で、異変の検知が鳴った
起きたこと新しい箱を作ると、Azure のセキュリティの仕組みが自動でルール（Azure Policy）を付け、それに異変の検知が反応しました。
気づいたきっかけ鳴ったメールで気づきました 。
直したこと
正常な動きと判断し、その組み合わせだけを数えない形にしました。ほかの変更は今までどおり知らせます。
発行用の古い認証が、既定で有効だった
起きたことアプリを配る経路は鍵なし（GitHub の署名つきの合図）にしたのに、道具（Terraform の Azure 用の部品）の既定で、発行用の古い認証（基本認証）も有効のままでした。
気づいたきっかけ見直しで気づきました 。
直したこと
無効にしました。あわせて、古い送り方（FTP）も止めています。
防火壁の向きが逆で、正しい要求が 403 になった
起きたこと画面の置き場（Vercel）の防火壁の条件が逆になっていて、Cloudflare を通った正しい要求のほうが 403 になっていました。
気づいたきっかけ受け入れの試験で見つけました 。
直したこと
条件の向きを直し、Cloudflare を通った要求は 200、画面の置き場を直接呼ぶと 403 になることを確かめました。
2 つのクラウド
Google Cloud 版との違い
人がクラウドを直接さわらない土台は、Google Cloud と Azure で 3 つの原則は同じで、使う部品と、得意・不得意が違いました。どちらかが上という話ではなく、同じ守りをどの部品で作るかの違いです。
部品の対応と違い
| 項目 | Google Cloud 版 | Azure 版 |
|---|---|---|
| 人と資源 | 組織 → フォルダ → プロジェクト | 人の世界（Entra ID）と資源の世界（管理グループ → サブスクリプション）が別 |
| 組織のルール | 13 本（すべて拒否） | 15 本（拒否 13・記録 1・無ければ足す 1） |
| 「呼んでよい相手」 | 権限で必須にできる | 権限に無いので、入口の認証で守る（認証の無いアプリを作ることは拒否できない） |
| 自動ブレーキ | システムごとに選んで付ける（既定はオフ） | 雛形に必ず付く |
| 止め方 | 係を無効にする（約 14 秒） | アプリを止める（56〜60 秒） |
| 定時実行 | スケジューラーが受け口を呼ぶ | アプリの中のタイマー |
| 作るのにかかった期間 | 2026-09 に段階を踏んで | 2 日（2026-10-20〜21） |
| 本番の実績 | あり（trends.snamo.jp） | まだ無い（公開ゲームは試作用の区分） |
Azure が得意だったこと・苦手だったこと
得意だったこと
- 消された設定を、ルールが作り直す（無ければ足す）
- CI が配れる権限の範囲を、条件で縛れる
- 係の ID（マネージド ID）に、鍵という考えが無い
- 異変のメールに「誰が・どこから・何を」まで出る
苦手だったこと
- 「呼んでよい相手」を決める権限が無い
- 箱を作った係に所有者の権限が自動で付き、最後の所有者は外せない
- 人の設定（Entra ID）の一部が、自動化の外に残る
- 無料の版では見えない記録がある
正直な線引き
選ばなかったこと・費用・まだのこと
人がクラウドを直接さわらない土台の Azure 版で、選ばなかったこと・まだできていないこと・人の手が残ることを先に書きます。どれも一人で運用している組織での記録です。
選ばなかったこと
| 選ばなかったこと | 理由・代わりにしたこと |
|---|---|
| Container Apps とコンテナの置き場 | Google Cloud の Cloud Run にいちばん近い形ですが、月 750 円ほど増えます。「月額を増やさず、鍵も置かない」の条件で、Azure Functions にしました。 |
| Application Insights | 細かい動きの記録の仕組みです。費用がかかるので入れていません。 |
| Key Vault（秘密の入れ物） | 入れる秘密が無いので置いていません。要るものが出たら足します。 |
| 固定の出口（NAT）と有料の保護 | 組織のルールで拒否しています（2026-10-20 の試験で拒否を確認）。外への出口は閉じた形が既定です。 |
| 東京以外の地域 | 組織のルールで拒否しています。置き場所は東京だけで、複数の地域への冗長化はしていません。 |
費用の考え方
- 2026-10-21 までの費用
- 0 円
- 見込み（異変の通知とログの保管）
- 月 100〜200 円
- アプリ（Azure Functions）と閉じた出口
- 0 円（無料枠）
- 共通の土台の予算
- 月 1,000 円
- システムごとの予算
- 月 500 円（超えたら止まる）
まだのこと・人の手が残ること
- 本番での利用なしAzure 用の本番の型はまだありません。eggfort.snamo.jp は試作用の区分で動いています。
- 未実施「予算の通知 → 止める処理」の経路の実地確認（試験は止める処理を直接動かしました）。
- 未着手同じ考え方の AWS 版（設計案だけ）。
- 位置づけAzure 版は、同じ考え方がクラウドを替えても通じるかを確かめるために作りました。SNAMO の本番は Google Cloud のままです。
- 人の手人の設定（Entra ID）の一部、Vercel の設定（合図・環境変数・防火壁）、GitHub の変数、一部の権限の付与。
- 課題残っている課題は記録して管理しています。中身は攻撃の手がかりになるので公開しません。
- 規模一人で運用している組織での実績です。
よくある質問
相談の前によく聞かれること
Google Cloud 版と何が違いますか？
3 つの原則は同じで、使う部品が違います。たとえば Azure では「呼んでよい相手」を権限で縛れないので、入口の認証で守り、受け入れの試験で毎回確かめます。
本番で使えますか？
本番の実績は Google Cloud の方です。Azure 版は公開ゲームで 12 の経路を確かめた段階で、本番用の型はまだありません。Azure で本番のシステムを作るときは、まず本番用の型を作り、同じように試作で確かめてから進めます。
費用はどれくらいですか？
2026-10-21 までは 0 円でした。見込みは月 100〜200 円（異変の通知とログの保管）です。システムごとに月 500 円の予算と止める仕組みを付けます。実際の金額は扱うデータと使い方で変わるので、ご相談ください。
作るのにどれくらいかかりましたか？
組織の土台と試作のシステム 1 本までは、2026-10-20〜21 の 2 日で作りました。公開ゲームは、手元で作ってあったゲームを載せて 2026-10-27 に公開しました。
AI はどう関わりましたか？
この土台は AI（Claude）と組んで作りました。マージと権限の付与は本人が行います。
AWS でもできますか？
設計案はありますが、まだ手を付けていません。いま続けて動かしている本番の実績は Google Cloud です。
ご相談
お使いのクラウドで、同じ守りから始めませんか
Azure でも Google Cloud でも、この事例と同じく、まず使い捨ての試作で確かめてから本番へ進みます。ご相談のときは、次の 4 つを教えてください。
- 扱うデータ個人情報の有無
- だいたいの予算月額の目安
- 今のクラウド使っていなければ「なし」
- 時期いつまでに必要か
このフォームの通知も、保存した秘密を持たない仕組みで届きます（2026-09-16 から）。
公開中のゲームを見る（eggfort.snamo.jp）（新しいタブ）Google Cloud の事例を読むつくった人のプロフィール