当時のようす
- snamo.jp の外部とのつながりは、もれたら誰でも使える「長く使える鍵」で動いていました。問い合わせの通知はメールのアプリ パスワード、音声のデモはサービスアカウントの鍵ファイルです。
- 心配していたのは 3 つです。鍵がもれること、画面での手作業で設定がずれること、誰がいつ何を変えたか分からなくなること。
- いまは、どちらの鍵も使っていません。
事例（Google Cloud）
人がクラウドを直接さわらない土台
AI システムを、鍵ファイルを持たず、使いすぎたら止まり、変更の記録が必ず残る形で動かす
組織の設定の変更は「変更の提案（PR）→ 自動の検査 → 反映」の 1 本道を通り、人は Google Cloud の管理画面を見るだけです（例外は緊急時と復旧の 2 つ）。この土台の上で、AI ニュースのサイト trends.snamo.jp が月〜木の朝 7 時に自動で更新されています。
- 情報もれ鍵ファイルは組織のルールで作れない（オーナーでも拒否）
- 費用予算を超えたら自動で止まる（2026-09-13 の試験（試作環境）では約 14 秒で係が停止）
- 停止trends.snamo.jp の試運転 12 回がすべて出て、平日の欠けなし（2026-09-12〜29）
- 属人化変更はすべて記録に残る（提案・検査・結果）
この事例の答え
- 結論
人がクラウドを直接さわらない土台は、情報もれの元になる「長く使える鍵」「画面での手作業」「記録の残らない変更」を、Google Cloud の組織のルールで最初から無くした、AI システムのための土台です。
- 根拠
13 個の組織のルール（組織ポリシー）で、鍵ファイルの作成と持ち込み、誰でも見られる設定、アジアの外へのデータの置き場所などを拒否しています。試作環境では、自動の係にわざと鍵ファイルを作らせ、組織のルールの名前つきで拒否されることを確かめました（2026-09-11）。
- 最初の一歩
まず trends.snamo.jp の「このサイトのしくみ（新しいタブ）」で、実際に動いている様子をご覧ください。そのうえで、扱うデータとだいたいの予算をお知らせください。
確かめた事実には日付と場所を添えています。まだのことは「未実施」「本番での利用なし」と書いています。
押すと YouTube の埋め込みを読み込んで再生します(それまで YouTube には接続しません)。 YouTube で開く：クラウドの仕組み（新しいタブ）
始める前の状態
長く使える鍵と、画面での手作業
2026-09-08 に 3 つの原則を決めるまで、SNAMO（鈴木信弘）は一人で snamo.jp とほかのアプリを動かしていました。これから作るシステムも増える予定だったので、守りを人の注意力に頼らない形に作り直すことにしました。
そこで決めた 3 つの原則（2026-09-08）
人はクラウドを直接さわらない
変更は「変更の提案（PR）→ 自動の検査」を通したものだけ。管理画面は見るだけにします。
鍵は守るのではなく、持たない
もれたら困る鍵を、そもそも作れない・置かない形にします。
守りを先に作り、試作で確かめてから本番へ
守りを全部作ってから使い捨ての試作で 1 本確かめ、合格してから本番に進みます。
AI システムを任せるときの心配
4 つの心配と、この土台の答え
AI システムを外に任せるときの 4 つの心配（情報もれ・費用の膨張・停止・属人化）に、人がクラウドを直接さわらない土台がどう答えるかを、仕組み → 確かめたこと（日付と環境つき）→ 限界の順に書きます。できていないことも隠しません。
心配 1
情報がもれないか
この土台では、鍵ファイルを組織のルール（組織ポリシー）で作れなくしてあり、自動の係（サービスアカウント）は、そのつど発行される短命の身元証明（Workload Identity 連携）で入ります。
- 仕組み
- プロジェクトのオーナーでも鍵ファイルは作れず、持ち込みも拒否されます。誰でも見られる保管場所、組織の外の人への権限、アジアの外への置き場所も拒否します。秘密の値は設定のコードに書かず、入れた人自身も読めません。
- 確かめたこと
- 試作環境で、鍵を作れるはずの自動の係にわざと鍵ファイルを作らせ、持ち込ませました。どちらも組織のルールの名前つきで拒否されました 。snamo.jp でも同じ考え方で鍵をなくし、使っていた鍵ファイルは削除しました 。いまはユーザー管理の鍵 0 本・アプリ パスワード 0 本です。
限界
4 つの経路を見る →人が入れる値（外部の API を呼ぶシステムの秘密の値など）は残ります。残っている課題は文書に記録して管理しています（中身は公開しません）。
心配 2
費用がふくらまないか
予算の半分・9 割・全額で通知が届き、自動ブレーキを付けたシステムは、予算を超えたら本体を呼ぶ係と定時の係を自動で止めます。
- 仕組み
- 月末に予算を超えそうなときもメールが届きます。システムごとの予算には自動ブレーキを付けられます。鍵には触らず、元に戻すかどうかは人が決めます。trends.snamo.jp は、記事を書く AI を呼べる回数も 1 日 4 回までにしています。
- 確かめたこと
- 予算超過の通知をわざと送ると、約 14 秒で 2 つの係が止まり、元に戻せることも確かめました ・試作環境。
限界
受け入れの表を見る →組織全体の予算（月 5,000 円）は通知だけで、自動では止まりません。自動ブレーキは雛形では既定でオフで、システムごとに選んで付けます。
心配 3
止まらないか・壊れないか
公開の前に「テストに通る・管理者の権限で動かない・重大な弱点が 0」の関門があり、どれか 1 つでも落ちれば公開されません。
- 仕組み
- 入口は Cloudflare を通る道だけにして、攻撃のパターンと連打を止めます。サイトが落ちるような DNS の削除は、2 段階の提案を通さないとできません。
- 確かめたこと
- 攻撃に見せかけた通信が 403 と 429 で弾かれました。trends.snamo.jp は試運転の 12 回がすべて出て、平日の欠けはありませんでした 〜。本番への切り替えも止まらずに済みました 。
限界
進め方の記録を見る →複数の地域に分けて置く冗長化はしていません（意図して受け入れています。要件に応じてご相談ください）。
心配 4
その人しか分からなくならないか
組織の設定はコード（Terraform）で管理し、変更はすべて提案の記録に残ります。権限の一覧も毎週自動で作ります。
- 仕組み
- 変更の提案には、差分の予告と結果が残ります。権限の一覧が前回と違えば自動で提案が出ます。権限の付与の変化と、Cloudflare の設定を画面から直接変えた「ずれ」も、週 1 回見つけます。新しいシステムは一覧に 1 行足すだけで、同じ守りの外側が機械で作られます。
- 確かめたこと
- 組織の設定のリポジトリでは、約 1 か月でコミット 196、マージ済みの提案 89 本（GitHub 上の数）が、すべて記録に残っています 〜。
限界
常時の見張りを見る →設定のコードの外に、人の作業が残ります（Vercel の環境変数とファイアウォールのルール、GitHub の変数）。ファイアウォールのルールの入れ忘れが 2026-09-16 に見つかったので、「完全に自動」とは言いません。
この守りで、AI システムを始めたい方へ
進め方はこの事例と同じく、まず使い捨ての試作で確かめてから本番へ進みます。
本番で動いている例
trends.snamo.jp ― この土台で動く本番の第 1 号
trends.snamo.jp は、人がクラウドを直接さわらない土台で作った本番の第 1 号です。AI の動きを会話で伝えるニュースを、月〜木の朝 7 時に 3 件ずつ公開しています（2026-09-29 から本番）。本当に動いているかは、ご自身で開いて確かめられます。
AI の動きを、会話でわかりやすく
すずとしおりの AI ニュース
すずきく人
しおりこたえる人
AI の動きを、すず（きく人）としおり（こたえる人）の会話で、小学生にもわかる言葉で伝えるサイトです。月〜木の朝 7 時に 3 件ずつ出ます。公開までに人の手は入りません。
情報源は、各社・各機関の公式発表 83 か所だけ。AI は検索を使わず、集めた候補にある事実だけで書き、出典と結びつかない話は自動で落とします。
- 作り始め（リポジトリを作った 2026-09-12 23:06）から、試作環境の受け入れの記録のマージ（09-13 02:06）まで。アプリ作りを含む
- 約 3時間
- 試運転の回数（2026-09-12〜29）。平日の欠けなし
- 12回
- パスワードや鍵のファイル（入れ物そのものが無い）
- 0個
- 記事を書く AI を呼べる上限
- 4回 / 日
- 情報源の公式発表
- 83か所
- 予算。超えたら自動で止まる
- 1,000円 / 月
点は実際の数（試運転 12 回・1 日 4 回・公式発表 83 か所）を 1 つずつ描いたものです。
守り
- 本体は Google のサービスにしか通信できません（外への出口を閉じています）。
- 各回で、AI に見せた候補と下書きを、あとから全部確かめられます。
進め方の記録
作り始める（リポジトリを作る）
試作環境で受け入れに合格
- 〜
試運転 12 回。平日の欠けなし
止めずに本番へ切り替え（違いは環境を表す 1 項目だけ）
本番の自動の更新も成功
trends の試作環境を片付け
情報源を公式発表に作り直し 作り直しの話へ
2026 年 10 月
利用条件を読み直して、作り直しました
2026-10-08、trends.snamo.jp は記事の作り方を「AI が Google 検索で調べながら書く」から「公式発表 83 か所を集め、題と抜粋だけを読んで書く」に作り直しました。Google Cloud の利用条件にある、検索結果の表示と保存についての決まりに、合わない可能性があったためです。土台があったので、作り直しは軽く済みました。
それまで
AI が Google 検索で調べながら書く
Google 検索で根拠づけする機能（検索グラウンディング）を使って、記事を作っていました。
2026-10-08 から
公式発表を集め、題と抜粋だけを読んで書く
- 各社・各機関の公式発表（RSS / Atom、リリースノート、GitHub のリリース、Hugging Face、arXiv の新しい論文）を、GitHub Actions が毎朝集めます。
- AI は検索を使わず、集めた候補の題と抜粋だけを読みます。
- 集める先は一次情報だけ。報道・まとめ・個人のブログは入れません。配信の条件でページにすることを禁じている先も入れず、出典の書き方も配信先ごとの条件に合わせます。
気づいたこと
Google Cloud の利用条件には、検索結果の表示と保存についての決まりがあります。定時に作って保存し、誰でも読めるページにする作りとは、合わない可能性がありました。
戻らないように
検索の道具を渡すコードは消しました。コードに検索の道具が無いことを、テストで毎回確かめています。旧い 18 回は切り替えの時点で非公開にし、消す期限も決めてあります。
土台が効いたところ
外のサイトを読むのは集める工程だけなので、本体の出口は閉じたまま変えずに済みました。切り替えは裏側 → 公開の API の確認 → 画面の順で行いました（2026-10-08 の夜）。
利用条件の読み方は SNAMO の判断で、法律の助言ではありません。
しくみ
変更の通り道は 1 本だけ
人がクラウドを直接さわらない土台では、設定の変更は「変更の提案（PR）→ 差分の予告 → 人のマージ → 反映」の 1 本道だけを通ります。外側（組織のルールと共通の守り）は組織のリポジトリが、中身（システムの作り）は確かめ済みの雛形が持ちます。
変更が反映されるまで
- 人
変更の提案（PR）を出す
人が出すのはこの提案だけ。
- 読み取り専用の係
差分の予告を作る
何が変わるか（plan）を PR にコメントします。
- 人
読んでマージする
予告を読んで、よければ取り込みます。
- 書き込みの係
反映する
マージ済みの PR のコミットだと確かめてから反映（apply）します。
- 記録
記録が残る
提案・予告・結果がすべて残ります。
main に直接 push しても反映しない
無料の非公開リポジトリではブランチを保護する機能が使えないため、その代わりに入れました。最初の push で反映がすぐ走ってしまった反省からです。
人が直接さわる例外は 2 つだけ
1 つは緊急時で、記録を残して一時的に権限を付け、使い終わったら外します。もう 1 つは、自動の係が自分の土台を壊したときの復旧です。権限を全部外した後でも付け直せることを、演習で確かめました（2026-09-11）。
自動の係にも、組織の管理者の権限は付けない
自動の検査と反映の仕組みが破られても、組織の権限は書き換えられません。
外側は組織、中身は雛形
外側 ― 組織のリポジトリ
一覧ファイルに 1 行足すと、一式ができる
＋ 一覧に 1 行（新しいシステム）
プロジェクト標準の API用途別の係 4 つ（実行・デプロイ・plan・apply）鍵なしの CI 接続設定の記録の置き場秘密の入れ物（値は入れない）予算と通知個人情報を扱うなら監査ログ
業界の言葉では、ランディングゾーンやプロジェクト ファクトリにあたります。ファクトリ自身も守っていて、システム用の反映の係が付けられる権限は許可した範囲だけ、自分をオーナーにはできません。本番のプロジェクトと本番の記録は、設定のコードから消せません。
中身 ― 確かめ済みの雛形
最初から付いている守り
本体の呼び出しは認証が必須外への出口は閉じる管理者以外のユーザーで動かす土台のイメージを固定重大な弱点があれば公開を止める依存の更新の提案が毎週出る
中継口・自動ブレーキ・定時の実行は、設定 1 行で付けます。雛形のリポジトリには、秘密の値が 1 つもありません。
外への出口は 3 通り
closed（既定）0 円
Google のサービスにしか届きません。試作で測ると「拒否される」のではなく「経路が無い」状態でした。
open―
外へ自由に出られます。
nat月数百円〜
固定の出口を 1 本だけ持ちます。
言葉の言い換え
- PR
- 変更の提案書
- CI
- 自動の検査と反映の係
- 組織ポリシー
- 組織のルール
- Terraform
- 設定をコードで書く道具
- 雛形
- 確かめ済みのひな形
- サービスアカウント
- 自動の係（人ではないアカウント）
- plan / apply
- 差分の予告 / 反映
- Workload Identity 連携
- 短命の身元証明GitHub や Vercel が毎回署名する短命のトークンを、Google Cloud の一時的な認証に交換する仕組み。
- ランディングゾーン／プロジェクト ファクトリ
- 外側の一式を機械で作る仕組み一覧ファイルに 1 行足すと、外側の一式が機械で作られる仕組み。
- 検索グラウンディング
- Google 検索で根拠づけしながら書く機能trends.snamo.jp は 2026-10-08 にやめました。
- DMARC
- メールのなりすまし対策今は「拒否」にしています。
鍵なし
鍵ファイルを置かない 4 つの経路
人がクラウドを直接さわらない土台と snamo.jp では、外部とつながる 4 つの経路のどれも、長く使える鍵（鍵ファイルやアプリ パスワード）を使っていません。使っていた鍵ファイルは 2026-09-29 に削除し、ユーザー管理の鍵は 0 本、アプリ パスワードも 0 本です。
4 つの経路の以前と今
| 経路 | 以前 | 今 | 確かめたこと |
|---|---|---|---|
| 組織の設定を変える CI | はじめから鍵なしで作った | GitHub が毎回発行する短命の身元証明で入ります。書き込みの係になれるのは main ブランチだけで、PR はどのブランチからでも読み取りの係にしかなれません。 | 鍵を作れるはずの係でも、鍵ファイルの作成と持ち込みは組織のルールで拒否 |
| Web の中継口 → 本体 | はじめから鍵なしで作った | Vercel が毎回署名する短命のトークンを Google Cloud で一時的な認証に交換し、呼び出し専用の係のトークンを作って本体へ渡します。通れるのは本番の配信だけで、本体の URL はブラウザに渡しません。 | 正しい入口からは 200、本体を直接呼ぶと 403 ・試作 ・本番 |
| snamo.jp の問い合わせ通知 | メールのアプリ パスワード | Vercel が毎回署名する短命のトークンを Cloudflare Worker が確かめてからメールを送ります。保存しておく秘密は 0。送信専用サービスの API キーを使う案は、動かない秘密が 1 つ残るので見送りました。 このサイトのお問い合わせフォーム | フォームと URL はそのままで切り替え |
| 音声のデモ | サービスアカウントの鍵ファイル | 鍵なしの連携に替えました。鍵を読むコードは消し、テストで戻らないようにしています。 音声のデモを試す | 鍵を無効にした状態で配信し直し、音声が鳴る 。鍵は削除 |
問い合わせ通知と音声のデモは、同じ考え方で鍵をなくした snamo.jp の例として載せています。trends.snamo.jp は AI とデータベースを実行の係の権限で呼ぶので、秘密の入れ物そのものがありません。メールのなりすまし対策（DMARC）は段階的に上げ、今は「拒否」にしています。
中継口が本体を呼ぶまで（鍵を使わない受け渡し）
- 1. Vercel が署名毎回、短命のトークンを発行
- 2. Google Cloud で交換本番の配信だけが、一時的な認証に交換できる
- 3. 呼び出し専用の係本体を呼ぶためだけのトークンを作る
- 4. 本体が確かめる認証を確かめてから受け付ける
トークンの使い回しは 5 分まで。ブレーキを試したとき、使い回しが長いと止めた後も通り続けたためです（下の「つまずいたこと」）。
確かめ方
一度きりの受け入れと、常時の見張り
人がクラウドを直接さわらない土台は、守りを全部作ってから使い捨ての試作で 1 本確かめ、合格してから本番へ進みました。雛形も、雛形の試作環境で全項目に合格したあと、試作ごと削除しています（2026-09-10〜12）。
受け入れの表
鍵ファイルの検査は、組織のルールを理由に拒否されたときだけ合格にします。権限が足りずに失敗しても合格にはせず、通ってしまったらその場で取り消して不合格にします。
| 確かめたこと | 結果 | いつ・どこで | 頻度 |
|---|---|---|---|
| 正しい入口からは使える | 合格 200 | ・試作・・本番 | 一度きり |
| 本体を直接は呼べない | 合格 403 | ・試作・・本番 | 一度きり |
| 連打は止まる | 合格 429 | ・試作・・本番 | 一度きり |
| 予算を超えたら止まる | 合格 約 14 秒で 2 つの係が停止 | ・試作 | 一度きり |
| 戻せば使える | 合格 | ・試作 | 一度きり |
| 定時の処理の受け口は外から叩けない | 合格 401 | ・試作・・本番 | 一度きり |
| 鍵ファイルを作る・持ち込む（鍵を作れるはずの係で） | 合格 組織のルールの名前つきで拒否 | ・試作（あわせて 6 つの制約を確認） | 一度きり |
| 禁止したほかの操作（アジアの外への保管・誰でも見られる設定・組織の外の人への権限・呼び出しの検査の解除）も、組織のルールで拒否される | 合格 trends.snamo.jp で 4 つすべて | ・試作 | 一度きり |
| 本体の中から、Google のサービスにだけ届く | 合格 | ・試作 | 一度きり |
| 同じ出口の検査を本番でも | 未実施 | ― | ― |
| データベースのパブリック IP の禁止 | 未実施 試す対象が無い | ― | ― |
常時の見張り
通知先は管理者のメールです。
操作の記録を 1 か所に
組織全体（これから作るものも含む）の操作の記録を 1 か所に集めて保管し、400 日で自動で消します。書き込みは記録を運ぶ係に限っています。
常時異変を数分でメール
緊急用のアカウントによる管理の操作、自動の係以外による権限の変更、自動の係以外による組織のルールの変更、記録の保管場所への手出し。この 4 種類を知らせます（2026-09-16〜）。
常時セキュリティの診断
重大度の高い指摘はメールで届きます（2026-09-12〜）。試作環境で高い指摘が 2 件出たことをきっかけに、組織のルールを 1 つ足しました。
常時棚卸しと、ずれの検知
権限の一覧を毎週月曜に自動で作り、差分は提案になります。Cloudflare の設定のずれも毎週見つけます。
毎週見張りが本当に鳴るかも試しました
1 回目はメールが来ませんでした。仕組みを作り直し、3 回目で届いています（2026-09-16）。止める仕組みと同じく、鳴らしてみるまで信用しません。
失敗の記録
つまずいたことと、直したこと
人がクラウドを直接さわらない土台を作り、本番へ移して試作を片付けるまで（2026 年 9〜10 月）に、つまずいたことと直したことです。失敗しないことより、失敗に自分で気づいて直せることが大事だと考えています。同じ構成を入れるときの落とし穴の一覧にもなります。
起きたこと → 直したこと（8 件）
止める仕組みは、止めてみるまで信用しない
起きたことブレーキを実際に試したら、係を止めた後も 11 分以上通り続けました。発行済みのトークンを 50 分使い回していたためです。
直したこと
使い回しを 5 分に縮めました。
読み取り専用のはずの係が、中身まで読めた
起きたこと設定を読むだけの係が、個人情報や操作の記録の中身まで読めることに自分で気づきました。
直したこと
設定は読めても中身は読めない独自の権限に置き換えました（2026-09-10〜11）。権限が足りないときは作業が止まる、安全な側に倒れる作りです。
定時の処理の受け口の確認が甘かった
起きたこと雛形の最初の版で、定時の処理を呼ぶ相手の確かめ方が甘い所がありました。
直したこと
次の版で、呼び手のトークンを Google の公開鍵で自前で確かめる形にしました。
「一覧に 1 行」の提案で、予告が走らなかった
起きたこと一覧ファイルの変更で、差分の予告が作られていませんでした。これが動かないと土台そのものが成り立ちません。
直したこと
自動の検査の対象を足しました。
最初の壁は、お金の仕組みの側にあった
起きたこと1 つの請求先に紐づけられるプロジェクトの数の上限（既定 5）に当たりました。
直したこと
引き上げを申請してから作り直しました。
作る順だけでなく、消す順も確かめる
起きたこと試作環境を消すとき、ネットワークの解放待ちで止まりました（雛形の試作は 82 分、trends.snamo.jp の試作環境は約 54 分）。
直したこと
片付け専用の手順と、消す順番を用意しました。
便利そうな機能が、要らないものを連れてきた
起きたことイメージの署名の検査を有効にすると、要らない API が約 25 個ついてくると分かりました。
直したこと
標準からは外し、必要なシステムだけが選んで使う形にしました。
失敗が成功に見えた
起きたこと本番への切り替えで、仮に置いたイメージが何にでも 200 を返すため、失敗が成功に見えました。
直したこと
「相手が本物か」を確かめる手順を足し、切り替えの手順書に書きました。
正直な線引き
選んだこと・選ばなかったこと・まだのこと
人がクラウドを直接さわらない土台が対象にしないこと、まだできていないことを先に書きます。どれも一人で運用している組織での実績です。
選ばなかったこと
| 選ばなかったこと | 理由・代わりにしたこと |
|---|---|
| 有料の Google Workspace | 必要なのは組織だけで、組織は無料の Cloud Identity Free で作れます。 |
| 高価な防御サービス | ロードバランサ込みで月 約 2,500 円〜かかります。代わりに Cloudflare の無料プランを入口の防御に使っています。 |
| 複数の地域への冗長化 | 地域は 1 つで、そのことを受け入れています。 |
| 今あるプロジェクトの移行 | 移す手間とリスクに見合わないので、新しいシステムだけを最初から組織の中で作ります。 |
| 選べる形にしたもの | イメージの署名の検査（既定は無効）と、自動ブレーキ（既定はオフ）。システムごとに選んで付けます。 |
費用の考え方
- 外への出口 closed（既定）
- 0 円
- 固定の出口 nat
- 月数百円〜
- 見張りと異変の通知
- 無料枠の範囲
- データベースの既定（Firestore）
- 固定費 0 円
- SQL が必要なとき（Cloud SQL）
- 月 1,500 円前後（設計時の見積もり）
- 組織全体の予算
- 月 5,000 円（超えたら通知）
まだのこと・人の手が残ること
- 本物の個人情報はまだ個人情報の保管の型（非公開・期限を過ぎたら自動で消える・人には権限が無い・誰がいつ読んだかが残る）。架空のデータを使う公開デモ（患者情報管理デモ）が本番の区分で動いていますが、本物の個人情報を扱う本番はまだありません。
- 本番での利用なし同じ考え方の Azure 版（2026-10-20〜21 に作成。公開ゲームの eggfort.snamo.jp が試作用の区分で動いています）。
- 未着手同じ考え方の AWS 版（設計案だけ）。
- 人の手秘密の値を入れる作業（外部の API を呼ぶシステムだけ）、GitHub の変数、Vercel の環境変数とファイアウォールのルール。
- 課題残っている課題は文書に記録して管理しています。中身は攻撃の手がかりになるので公開しません。
- 規模一人で運用している組織での実績です。
よくある質問
相談の前によく聞かれること
社員が管理画面をさわれないと困りませんか？
いつでも見ることはできます。変えるときは提案を出し、自動の検査を通してから反映します。緊急時は記録を残したうえで一時的に権限を付け、終わったら外します。
鍵ファイルが無いのに、自動の係はどうやってつながるのですか？
GitHub や Vercel が毎回署名する短命のトークンを、受け手が確かめてから一時的な認証に交換します。長く使える鍵を持たないので、仮にもれても短い時間で使えなくなります。
予算を超えたらどうなりますか？
自動ブレーキを付けたシステムでは、本体を呼ぶ係と定時の係を止めて経路を閉じます。2026-09-13 の試験（試作環境）では、約 14 秒で 2 つの係が止まりました（中継口が発行済みのトークンを使い回すのは最長 5 分です）。元に戻すのは人の判断です。組織全体の予算は通知だけで、自動では止めません。
費用はどれくらいかかりますか？
見張りの通知、セキュリティの診断、外への出口を閉じた既定の形は、無料枠か 0 円で動いています。固定の出口が要る場合は月数百円から、SQL のデータベースが要る場合は月 1,500 円前後の見込みです（設計時の見積もり）。実際の金額は扱うデータと使い方で変わるので、ご相談ください。
個人情報を扱うシステムにも使えますか？
型を用意しています。非公開で、保持日数を過ぎたら自動で消え、人には権限が無く、誰がいつ読んだかが記録に残ります。架空のデータを使う公開デモ（患者情報管理デモ）がこの型で動いていて、画面から本物の API に操作を送って確かめられます。ただし、本物の個人情報を扱う本番はまだありません。
今あるシステムも載せられますか？
基本は、新しいシステムを最初からこの土台の上で始めます。今あるシステムを移すかどうかは、移す手間とリスクを比べて、事情を伺ってから一緒に決めます。
AWS や Azure でもできますか？
Azure では同じ考え方の土台を 2026-10-20〜21 に作り、公開ゲームの eggfort.snamo.jp（たまご城の守りびと）がその上で動いています（2026-10-27 公開・試作用の区分）。本番として続けて動かしている実績は、いまは Google Cloud です。AWS 版は設計案だけで、まだ手を付けていません。
一人で作っているなら、結局その人しか分からないのでは？
設定も手順も確かめた結果も、コードと文書に残しています。変更はすべて提案の記録に残り、権限の一覧も毎週自動で作っています。この土台は AI（Claude）と組んで作りました。
ご相談
AI システムを、同じ守りから始めませんか
この事例と同じく、まず使い捨ての試作で確かめてから本番へ進みます。ご相談のときは、次の 4 つを教えてください。
- 扱うデータ個人情報の有無
- だいたいの予算月額の目安
- 今のクラウド使っていなければ「なし」
- 時期いつまでに必要か
このフォームの通知も、保存した秘密を持たない仕組みで届きます（2026-09-16 から）。