【Google Cloud Next Tokyo 26 参加レポート】新卒5か月目が見た Google Cloud セキュリティ

2026年9月2日

こんにちは！丸紅I-DIGIO の今戸です。
記念すべき第1回目のテーマは、Google Cloud Next Tokyo のレポートです。
私自身が一番興味を持ったセッションについて、
新卒ならではの視点でお話していきたいと思います！

INDEX

はじめに：なぜこの30分セッションを選んだのか

2026年7月30日・31日に開催された Google Cloud Next Tokyo に参加し、基調講演や AI 関連のセッションなどをいくつか聴講しました。その中でも特に印象に残ったのが、株式会社 G-gen 様による「迷わないための Google Cloud セキュリティサービス活用ガイド」です。

Google Cloud のセキュリティサービスを、「どの観点で何を意識すべきか」という切り口で整理してくれており、セキュリティ初心者の自分でも全体像をつかみやすい 30 分間でした。本レポートでは、私が特に重要だと感じたポイントと、今後の業務でどう活かしたいかを中心にまとめます。

クラウドセキュリティを6つの観点で捉える

セッションでは、クラウドセキュリティを次の6つに整理していました。

ID管理：誰にどんな権限を与えるか
証跡管理：いつ・誰が・何をしたかを残すか
予防的統制：そもそも危険な操作をできなくするか
発見的統制：異常にすぐ気付けるか
是正的統制：誤設定から自動で元に戻せるか
コスト管理：想定外のコスト増を防げるか

日本企業のAI活用に対する関心やツール導入自体は、他国と比較しても決して遅れているわけではありません。しかし、「導入したものの、期待していたような財務的リターンや成果が得られない」「PoCの段階では順調に進んでも、全社展開や本番運用の前にプロジェクトが中止になってしまう」といったケースが後を絶ちません。

それまで私はセキュリティ＝不正アクセスを防ぐことというイメージが強く、かなり狭い見方をしていました。今回、権限設計・ログ・自動修復・コストまで含めて一続きの仕組みとして捉える必要があると分かり、セキュリティは"設定のテクニック"ではなく"運用設計"なのだと認識が変わりました。

一般アカウントに権限を振らないという基本

最初に取り上げられていたのは、ID管理の重要性です。
特に印象に残ったのは、次の点でした。

Google Workspace / Cloud Identity のアカウントは、企業側で二段階認証の強制や退職時の停止ができる
一般アカウント（個人の Google アカウント）は、企業側からログイン方法や停止をコントロールできない

一般アカウントに IAM 権限を付与してしまうと、退職後も権限が残り続け、パスワード管理の不備などがそのまま企業のリスクになってしまいます。
どのサービスを使うかより前に、どのアカウントに権限を集約するかが土台になる、というメッセージはとても納得感がありました。まずは自分の所属チームで、

どの種類のアカウントを使っているのか
一般アカウントに権限を付与しているケースがないか

といった基本的なところから確認していくことが、最初の一歩になりそうだと感じました。

証跡と予防で事故になりにくい状態をつくる

次に印象に残ったのが、証跡管理と予防的統制の考え方です。

証跡管理では、Cloud Audit Logs や Data Access 監査ログ などで操作やデータアクセスを残し、その場で止めるだけでなく後からたどれるようにしておくこともセキュリティだと説明されていました。
この話を聞いて、これまで自分が意識していたのは問題が起きないようにすることばかりで、もし起きてしまったときに原因を説明できる状態をつくるという発想が抜けていたと気づきました。一方で予防的統制は、IAM や組織ポリシーなどでそもそも危ない操作をできなくしておく考え方です。

今後は、新しい仕組みや提案内容を考えるときに、

何かあったときに"誰が何をしたか"を説明できるか（証跡）
そもそもやってはいけない操作を、設定でどこまで封じられるか（予防）

という2つの観点をセットで考えるようにしたいです。最初は小さな資料作成や検討メモのレベルでも、どんなミスを事前に防げるか？と自分に問いかけるところから始めてみようと思いました。

発見と是正で「気付いて直せる」運用へ

どれだけ予防しても、設定ミスや新たな脆弱性をゼロにはできません。その前提に立って語られていたのが、発見的統制と是正的統制です。

発見的統制の話を聞いて印象的だったのは、今どこにリスクがありそうかを一覧できる状態をつくる、という考え方でした。個々のプロジェクトごとに点で管理するのではなく、Security Command Center のような仕組みで、設定ミスや脆弱性をまとめて見渡すイメージです。
問題が起きてから調べるのではなく、起きそうな場所に早めに気付くことが大事なのだと感じました。
是正的統制については、ルールを決めるだけでなく、そのルールどおりの状態を維持し続けるところまで設計するという説明が特に心に残りました。

SecOps や Config Controller などで、誤設定があっても自動で元に戻すイメージが紹介され、人がレビューし続けるのではなく仕組みが直し続ける方向に発想を変える必要があると感じました。

私はまだこうした運用の中心にいるわけではありませんが、今後どんな小さなタスクでも、

気付きやすくするために、何を可視化すべきか
直しやすくするために、どこまで自動化できそうか

という2つの視点を意識したいと思いました。チェックリストやドキュメント作成のような身近な仕事でも、決めたルールを維持しやすい形になっているか？と一歩先まで考える癖をつけていきたいです。

コストもセキュリティとして見る

個人的に意外だったのが、コスト管理もセキュリティの一部として扱われていたことです。
アカウント乗っ取りや設定ミスなどで、大量のリソースが意図せず起動されてしまうと、それ自体がコスト面でのインシデントになります。これを防ぐために、

予算アラート：設定した予算を超えそうなタイミングで通知する
コスト異常検知：通常と異なる利用パターンを検知する

といった機能が紹介されていました。
これまでコスト管理は主にお金の話だと思っていましたが、異常な利用の早期発見という意味では、セキュリティと密接につながっていることに気付かされました。今後は、利用料金の推移を見るときにも、単なるコスト削減だけでなく、異常の兆候がないかという視点も持つようにしたいです。