TECH PLAY

株匏䌚瀟G-gen

株匏䌚瀟G-gen の技術ブログ

å…š804ä»¶

G-gen の歊井です。圓蚘事では、BigQuery ず Git リポゞトリを連携する機胜である BigQuery リポゞトリ を解説したす。 はじめに 機胜説明 リポゞトリ リポゞトリの利甚圢態 取り扱い可胜なファむル バヌゞョン管理 IAM ロヌル 料金 怜蚌1セットアップ セットアップの抂芁 リポゞトリの䜜成 ワヌクスペヌスの䜜成 ディレクトリの䜜成 SQL ファむルの䜜成 怜蚌2バヌゞョン管理 デモの抂芁 commit push pull 埩元 ク゚リ実行 怜蚌3GitHub リポゞトリずの接続 関連蚘事 はじめに BigQuery リポゞトリ ずは、BigQuery ず Git リポゞトリを連携する機胜です。Google Cloud コン゜ヌルの BigQuery 操䜜画面である BigQuery Studio においお、組み蟌みの Git リポゞトリたたは GitHub 等の Git リポゞトリず接続しお、SQL ファむル等のバヌゞョン管理をしたり、Git ワヌクフロヌを操䜜するこずができたす。 これにより、以䞋のようなメリットを埗るこずができたす。 Git リポゞトリ䞊の SQL をそのたた BigQuery 䞊で実行できる BigQuery Studio 䞊で SQL のバヌゞョン管理ができる チヌムでの共同䜜業が容易になる 圓蚘事では、BigQuery リポゞトリの機胜、セットアップ方法、ならびに操䜜手順に぀いお説明したす。 参考 BigQuery リポゞトリの発衚: BigQuery Studio での Git ベヌスのコラボレヌション 参考 : Introduction to repositories なお圓機胜は、2025幎4月時点でプレビュヌです。 参考 : Preview版のサヌビスを䜿うずはどういうこずなのか 機胜説明 リポゞトリ BigQuery リポゞトリでは、 組み蟌みの BigQuery リポゞトリ を䜿甚するか、以䞋の サヌドパヌティヌリポゞトリ ず接続可胜です。 Git プロバむダ 接続方法 Microsoft Azure DevOps Services SSH Bitbucket SSH GitHub SSH たたは HTTPS GitLab SSH たたは HTTPS 参考 サヌドパヌティのリポゞトリ リポゞトリの利甚圢態 リポゞトリの利甚圢態は以䞋の2通りです。 プラむベヌトリポゞトリ リポゞトリ䜜成者のみ利甚可胜 共有リポゞトリ 耇数のプリンシパルで共有可胜 参考 リポゞトリを共有する 取り扱い可胜なファむル リポゞトリにお取り扱い可胜なファむルは以䞋の通りです。 SQL ク゚リ Python ノヌトブック デヌタキャンバス デヌタプレパレヌション 䞊蚘以倖のファむル 参考 ワヌクスペヌス内のファむルを操䜜する バヌゞョン管理 リポゞトリでは以䞋のバヌゞョン管理操䜜が実行できたす。 オプション 説明 倉曎 ワヌクスペヌスたたは遞択したファむルのロヌカル倉曎を commit する push commit をデフォルトブランチmainたたは指定のブランチに push する pull デフォルトブランチをワヌクスペヌスに pull する 埩元 ワヌクスペヌスにあるファむルを前回の commit に埩元する 参考 ファむルでバヌゞョン管理を䜿甚する IAM ロヌル 共有リポゞトリずワヌクスペヌスの操䜜に必芁な暩限は以䞋の通りです。 操䜜 IAM ロヌル 共有リポゞトリの䜜成・管理 コヌドオヌナヌ roles/dataform.codeOwner  ワヌクスペヌスの䜜成・削陀 コヌド゚ディタ roles/dataform.codeEditor  ファむルの䜜成・倉曎・バヌゞョン管理 同䞊 リ゜ヌスの衚瀺 コヌド閲芧者 roles/dataform.codeViewer  たた、プラむベヌトリポゞトリずワヌクスペヌスの操䜜に必芁な暩限は以䞋の通りです。 操䜜 IAM ロヌル プラむベヌトリポゞトリの䜜成・管理 コヌド䜜成者 roles/dataform.codeCreator  ワヌクスペヌスの䜜成・削陀 同䞊 ファむルの䜜成・倉曎・バヌゞョン管理 同䞊 参考 必芁なロヌル 料金 BigQuery リポゞトリの利甚に料金はかかりたせん。 参考 料金 怜蚌1セットアップ セットアップの抂芁 圓蚘事では、BigQuery Studio に BigQuery リポゞトリ暙準の組み蟌みリポゞトリを接続し、SQL ファむルのバヌゞョン管理を行いたす。 リポゞトリの䜜成 BigQuery Studio > リポゞトリを衚瀺 > リポゞトリの远加 の順で BigQuery リポゞトリを䜜成したす。 䜜成時点ではプラむベヌトリポゞトリですが、 [ïž™]アむコン > 共有 の順で 共有リポゞトリ に倉曎できたす。䜜成者以倖のプリンシパルに暩限を付䞎するこずができたす 参考 リポゞトリを䜜成する 参考 リポゞトリを共有する ワヌクスペヌスの䜜成 先ほど䜜成したリポゞトリ名をクリックし、 ワヌクスペヌスタブ > ワヌクスペヌスを远加 の順でワヌクスペヌスを䜜成したす。 なお、ワヌクスペヌスずは 同じリポゞトリで䜜業しおいる他のナヌザヌに圱響を䞎えるこずなく、リポゞトリでファむルの䜜成、線集、削陀を行うための仮想的な䜜業空間 を意味したす。 䜜成埌は 開く > 確認 の順でクリックするず、BigQuery Studio にリポゞトリを接続できたす。 ディレクトリの䜜成 次に、ワヌクスペヌスにディレクトリを䜜成したす。今回のデモでは、ク゚リ先の構成に合わせおディレクトリを䜜成したす。 . └── sample ├── customers │ └── demo.sql ├── products │ └── ... └── sales └── ... [+] アむコン > リポゞトリに䜜成 > ディレクトリ の順でディレクトリを䜜成したす。 SQL ファむルの䜜成 各ディレクトリに SQL ファむルを䜜成し、ク゚リのバヌゞョン管理を行いたす。 各ディレクトリの [ïž™] アむコン > リポゞトリに䜜成 > SQL ク゚リ の順で SQL ファむル䜜成したす。 ファむルにク゚リを入力するず倉曎が怜知したため、 Commit X Change ず衚瀺されたした。 怜蚌2バヌゞョン管理 デモの抂芁 先ほど䜜成した SQL ク゚リをもずに、バヌゞョン管理操䜜を行いたす。 commit 倉曎を commit したす。 Commit X change をクリックするず、倉曎内容が確認できたす。commit メッセヌゞ必須を入力埌、 すべおあるいは X 個のファむルを commit をクリックしたす。 push 次に、先ほどの commit をデフォルトブランチmainに push したす。 プルダりン > デフォルトブランチに push を実行するず、デフォルトブランチにマヌゞされたす。 pull 共有リポゞトリにおいお、他メンバヌが push した内容を取り蟌みたい堎合、 プルダりン > デフォルトブランチから pull を実行したす。 埩元 倉曎の過皋で前回の commit に戻したい堎合、 プルダりン > 前回の commit に戻す を実行したす。 ク゚リ実行 リポゞトリで管理する SQL ファむルは、BigQuery Studio 䞊で盎接実行できたす。 怜蚌3GitHub リポゞトリずの接続 GitHub リポゞトリを BigQuery Studio に接続する堎合、以䞋の準備が必芁です。 GitHub リポゞトリ Secret Manager HTTPS の堎合は個人アクセストヌクン、SSH の堎合は秘密鍵を栌玍したシヌクレットを䜜成 IAM Policy 䞊蚘にアクセスできるよう、Dataform デフォルトサヌビスアカりントに察し以䞋の IAM ロヌルを付䞎 Secret Manager シヌクレットアクセサヌroles/secretmanager.secretAccessor 䞊蚘の準備が完了したら、 リポゞトリの远加 から GitHub リポゞトリ接続甚の BigQuery リポゞトリを䜜成し、 リポゞトリの構成タブ > Git 接続を線集 の順で蚭定を進めるず GitHub リポゞトリを接続できたす。 参考 HTTPS 経由でリモヌト リポゞトリに接続する 参考 リモヌト リポゞトリ接続を線集する 関連蚘事 blog.g-gen.co.jp blog.g-gen.co.jp 歊井 祐介 (蚘事䞀芧) クラりド゜リュヌション郚クラりド゚ンゞニアリング課。 Google Cloud Partner Top Engineer 2025 遞出。 趣味はロヌドレヌスやサッカヌ芳戊、あずはゎルフず筋トレ。 Follow @ggenyutakei
G-gen の杉村です。2025幎3月のむチオシ Google Cloud旧称 GCPアップデヌトをたずめおご玹介したす。蚘茉は党お、蚘事公開圓時のものですのでご留意ください。 はじめに Security Command Center Enterprise で Amazon EC2 のスキャン Vertex AI Agent Engine が Preview → GA Google スラむドの Gemini サむドパネルが日本語に察応 Spanner で階局型ストレヌゞが登堎GA Analytics Hub の egress controls ず Data clean room が党 BigQuery Edition に察応 Gemini 2.0 Flash の fine-tuning が GA Google Meet でバヌチャル背景生成や画質・音質向䞊など生成 AI 機胜 Google Meet で自動議事録およびリアルタむム音声文字起こし Deep Research ず Gems が党゚ディションで利甚可胜に Cloud Storage に新機胜 Anywhere Cache が登堎GA Gemini のコンテキストキャッシュがPreview→GA Compute Engine に M4 VM が登堎 BigQuery ず Spanner の連携が匷化 Google ドキュメントで AI 芁玄のビルディングブロックを䜜成できるように Gemini アプリに「Canvas」が登堎 NotebookLM にマむンドマップ機胜が远加 Vertex AI Search の answer メ゜ッドが匷化 Google、マルチクラりドセキュリティ゜リュヌションの Wiz を買収 Dataform が Secret Manager ず統合 BigQuery workflows が BigQuery pipelines に改名 BigQuery Studio ず Git の統合が Preview BigQuery ML で Claude モデルが利甚可胜にGA Cloud Storage の管理情報閲芧ツヌル Storage Intelligence Cloud SQL でむンスタンス削陀埌もバックアップを保持可胜に Cloud SQL に read pools が登堎Preview Gemini 2.5 Pro Experimental が発衚 Gemini が日本語 PDF を読み蟌み可胜に BigQuery の Search Index に column granularity 機胜が远加 Cloud Run で呌び出し時の IAM チェックの無効化が可胜に Google Docs の Help me create が日本語を含む远加蚀語に察応 BigQuery pipelines が Preview -> GA はじめに 圓蚘事では、毎月の Google Cloud旧称 GCPや Google Workspace旧称 GSuiteのアップデヌトのうち、特に重芁なものをたずめたす。 たた圓蚘事は、Google Cloud に関するある皋床の知識を前提に蚘茉されおいたす。前提知識を埗るには、ぜひ以䞋の蚘事もご参照ください。 blog.g-gen.co.jp リンク先の公匏ガむドは、英語版で衚瀺しないず最新情報が反映されおいない堎合がありたすためご泚意ください。 Security Command Center Enterprise で Amazon EC2 のスキャン Enable VM Threat Detection for AWS (2025-03-03) Security Command Center の Enterprise ティアで、Amazon EC2 のディスクのマルりェアスキャンができるようになったPreview。 AWS Lambda ず AWS Systems ManagerSSMを利甚しお、EC2 むンスタンス䞊のマルりェアをスキャンしお Security Command Center ぞ通知する。 Vertex AI Agent Engine が Preview → GA Vertex AI Agent Engine overview (2025-03-04) Vertex AI Agent Engine旧LangChain on Vertex AI、Vertex AI Reasoning Engineが Preview→GA。 Langchain、LangGraph などのフレヌムワヌクをデプロむ可胜なフルマネヌゞドの Agent プラットフォヌム。 Google スラむドの Gemini サむドパネルが日本語に察応 Use Gemini in the side panel of Google Slides in seven new languages (2025-03-05) Google スラむドの Gemini サむドパネルが日本語を含む7蚀語に新たに察応。画像生成も可胜になる。 日本語 フランス語 ドむツ語 むタリア語 韓囜語 ポルトガル語 スペむン語 Spanner で階局型ストレヌゞが登堎GA Tiered storage overview (2025-03-10) Spannerで階局型ストレヌゞが登堎GA)。 SSDずHDDから遞んでデヌタを保存できる。デフォルトではSSDに保存されるが「ロヌカリティグルヌプ」を䜜成しおテヌブル/列を指定し、時間経過したデヌタを HDD に自動移行。HDD はレむテンシ・スルヌプットに劣るがサむズあたりの費甚が安い。 Analytics Hub の egress controls ず Data clean room が党 BigQuery Edition に察応 BigQuery release notes - March 10, 2025 (2025-03-10) Analytics Hub の egress controls ず Data clean room が党 BigQuery ゚ディションに察応オンデマンド含む。 埓来はオンデマンドたたは Enterprise Plus ゚ディションが必芁だった。 Gemini 2.0 Flash の fine-tuning が GA Tune Gemini models by using supervised fine-tuning (2025-03-11) Gemini 2.0 Flash の fine-tuning が GA。 トレヌニングデヌタずしおテキスト、画像、音声、PDF を䜿ったファむンチュヌニングが可胜。 最䜎100個以䞊のデヌタを甚意するこずが掚奚されおいる。 Google Meet でバヌチャル背景生成や画質・音質向䞊など生成 AI 機胜 More AI-powered features in Google Meet and Google Chat are coming to Google Workspace Business and Enterprise editions (2025-03-11) Google Meet で、バヌチャル背景生成や、スタゞオ颚の画質・音質の再珟などの生成 AI 機胜が組み蟌たれる。 Business Standard 以䞊の゚ディションに2025-03-10から順次ロヌルアりトされる。 Google Meet で自動議事録およびリアルタむム音声文字起こし More AI-powered features in Google Meet and Google Chat are coming to Google Workspace Business and Enterprise editions (2025-03-11) Google Meet の "Take notes for me"自動議事録およびリアルタむムの音声文字起こしが日本語に察応する。録画した動画にも字幕を付䞎可胜。 Business Standard 以䞊の Google Workspace ゚ディションに付垯。 2025-03-12から順次ロヌルアりトするが、「性胜ず品質を泚芖するため、通垞よりずっず遅いペヌスでロヌルアりト」される予定。 Deep Research ず Gems が党゚ディションで利甚可胜に Deep Research and Gems in the Gemini app are now available for more Google Workspace customers (2025-03-13) Gemini りェブアプリにおいお、Deep Research ず Gems が、これたで提䟛されおいなかった Business Starter、Enterprise Starter、Education、Frontline、個人無償アカりントなどでも利甚可胜になった。 Cloud Storage に新機胜 Anywhere Cache が登堎GA Overview of Anywhere Cache (2025-03-13) Cloud Storage に新機胜 Anywhere Cache が登堎GA。ゟヌンごずに読取キャッシュを䜜成。 キャッシュず同ゟヌンの VM からの読み取りで、読取の高速化ずマルチリヌゞョンバケットからのデヌタ転送料金節玄に圹立぀。機械孊習や分析ワヌクロヌドを想定。GB/Hour ごずの課金が発生する。 Gemini のコンテキストキャッシュがPreview→GA Context caching overview (2025-03-13) Gemini のコンテキストキャッシュがPreview→GA。 システム指瀺プロンプトを事前にキャッシュしおおき料金を節玄できる。画像や長倧なテキストが毎回プロンプトに含たれおいる堎合に有甚。トヌクン/時間ごず課金。Gemini 1.5 Pro/Flashで利甚可胜。 Compute Engine に M4 VM が登堎 M4 machine series (2025-03-14) Compute Engine に M4 VM が登堎。メモリ最適化マシンタむプの新型で最倧 224 vCPUs / 3 TB RAM。 SAP HANA 等を想定。普通の Persistent Disk は䜿えず、Hyperdisk がサポヌトされる。 BigQuery ず Spanner の連携が匷化 BigQuery release notes - March 17, 2025 (2025-03-17) BigQuery ず Spanner の連携が匷化された。 External dataset別名 Federated datasetで Spanner の党テヌブルが BigQuery から芋える EXPORT DATA 文で BigQuery から Spanner ぞデヌタをリバヌス ETL できる Google ドキュメントで AI 芁玄のビルディングブロックを䜜成できるように Introducing a new building block that summarizes content with Gemini in Google Docs (2025-03-17) Google ドキュメントで、AI 芁玄のビルディングブロックを䜜成できるようになった。 ドキュメントの先頭に芁玄を茉せるなどが容易になる。ドキュメントが倉曎されたずきに芁玄に反映する曎新オプションも蚭定可胜。 スクリヌンショットは公匏ドキュメントから匕甚 Gemini アプリに「Canvas」が登堎 Try Canvas, a new way to collaborate with the Gemini app (2025-03-18) Gemini アプリに「Canvas」が登堎。生成した文章を手動で線集し぀぀、Gemini に調敎を指瀺できる UI。 生成した文章に察しお、文章の長さやフォヌマル具合の調敎、修正の提案等を行うこずができる。䜜成した文章は Google ドキュメントに゚クスポヌト可胜。 無償アカりント含む党 Google アカりントで、すぐに利甚可胜。 Canvas NotebookLM にマむンドマップ機胜が远加 New features available in NotebookLM and NotebookLM Plus (2025-03-19) NotebookLM にマむンドマップ機胜が远加。りェブサむト、動画、アップロヌドした PDF など、読み蟌たせたデヌタ゜ヌスを解釈しお、マむンドマップ匏に描画しおくれる。 䌚議の議事録やドキュメントを構造化しお衚瀺しおくれるので、資料の迅速な理解や思考の敎理に圹立぀。 無償アカりント含む党 Google アカりントで、すぐに利甚可胜。 NotebookLM のマむンドマップ Vertex AI Search の answer メ゜ッドが匷化 Vertex AI Agent Builder release notes - March 19, 2025 (2025-03-19) Vertex AI Search の answer メ゜ッドが匷化。 非構造化デヌタストアから画像ファむルを取埗できるように 回答内でチャヌト棒グラフ、折れ線グラフ等を生成できるように いずれも以䞋の泚意点がある。 Preview リリヌスである 英語ク゚リのみ察応 API のみ察応 Google、マルチクラりドセキュリティ゜リュヌションの Wiz を買収 Google + Wiz: Strengthening Multicloud Security (2025-03-19) Google、マルチクラりドセキュリティ゜リュヌションの Wiz を買収。 320億ドル玄4.8兆円、党額珟金取匕。Google にずっお最倧芏暡の買収ずされる。埓来から持぀ Google SecOps や Mandiant などの「䟵害埌」に匷い゜リュヌションに加え、Wiz の「未然に防ぐ」匷さが远加されるず芋られる。 Dataform が Secret Manager ず統合 Use Secret Manager to store sensitive data (2025-03-20) Dataform が Secret Manager ず統合。 PostgreSQL、MySQL、Oracle など、BigQuery 以倖の ID/Pass を芁する倖郚デヌタベヌスず接続する際に䜜るコネクションプロファむルの認蚌情報の保存先ずしお䜿える。 BigQuery workflows が BigQuery pipelines に改名 Introduction to BigQuery pipelines (2025-03-20) BigQuery workflows が BigQuery pipelines に改名された。 BigQuery workflows は、Web コン゜ヌル䞊で簡単に実装できるフルマネヌゞドのパむプラむンツヌル。珟圚ではただ Preview 公開。 BigQuery workflows BigQuery Studio ず Git の統合が Preview Announcing BigQuery repositories: Git-based collaboration in BigQuery Studio (2025-03-20) BigQuery StudioBigQuery コン゜ヌル画面ず Git の統合が Preview。 BigQuery コン゜ヌル画面で GitHub、GitLab 等のリモヌト Git レポゞトリを接続しお commit、push、diff、PR 䜜成などができる。 画像は公匏発衚より匕甚したもの BigQuery ML で Claude モデルが利甚可胜にGA The ML.GENERATE_TEXT function (2025-03-20) BigQuery ML で Claude モデルが䜿えるようになったGA。 ML.GENERATE_TEXT 関数で Vertex AI のリモヌトモデルを呌び出しお BigQuery のデヌタを䜿っお簡単に掚論できる。 Cloud Storage の管理情報閲芧ツヌル Storage Intelligence Storage Intelligence (2025-03-21) Cloud Storage に管理情報閲芧ツヌル Storage Intelligence が登堎。組織やフォルダレベルで閲芧可。 加えお管理情報を BigQuery に゚クスポヌトする Storage Insights datasets も登堎。これらで利甚状況を可芖化し、セキュリティ向䞊やコスト最適化を図るこずができる。 Cloud SQL でむンスタンス削陀埌もバックアップを保持可胜に Retained backups (2025-03-24) Cloud SQL でむンスタンス削陀埌もバックアップを保持できるようになった。 埓来たでは、むンスタンスを削陀するず最高365日保存の Final Backup を残しおバックアップは削陀されおしたう仕様だったが、残るようになった。オンデマンドバックアップは無期限保存、自動バックアップは保持日数蚭定に応じお自動削陀される。 Cloud SQL のバックアップの䞀通りの仕様は、以䞋の蚘事も参照。 blog.g-gen.co.jp Cloud SQL に read pools が登堎Preview About read pools (2025-03-25) Cloud SQL に read pools が登堎Preview。Cloud SQL Enterprise Plus ゚ディションMySQL、PostgreSQLで利甚可胜。 リヌドレプリカの集合䜓であり、単䞀 IP アドレスを゚ンドポむントずしお、読み取りワヌクロヌドを負荷分散。ノヌド数は調敎可胜で、最倧20ノヌド。以前からあるリヌドレプリカずの違いは、読み取り゚ンドポむントが単䞀 IP アドレスであるこずず、プヌルずしお䞀括管理できるこず。 Gemini 2.5 Pro Experimental が発衚 Gemini 2.5: Our most intelligent AI model (2025-03-25) Google が最新版生成AIモデル Gemini 2.5 Pro Experimental を発衚。 1.5 Flash Thinking ず同じく思考プロセスも出力される「思考型」。圓初100䞇トヌクンのコンテキストりむンドりで埌日200䞇に拡倧予定。先行しお Google AI Studio や Gemini りェブアプリGemini Advancedで利甚可胜。 たた、2025幎3月28日、Google Cloudの Vertex AI でも利甚可胜になった。 Gemini りェブアプリで Gemini 2.5 Pro Experimental が利甚可胜 Gemini が日本語 PDF を読み蟌み可胜に Gemini in Drive PDF Viewer is now available in 20+ additional languages (2025-03-26) Google ドラむブで、Gemini が日本語 PDF を読めるようになった。 Google ドラむブの Gemini サむドパネルにおいお、通垞の PDF やスキャンされた PDF 等を生成 AI が読み取り、芁玄したり、質問に答えたり、PDF 内容に基づいおメヌルを䜜成したりできる。埓来の英語に加え、今回は日本語を含む20以䞊の蚀語に察応。 BigQuery の Search Index に column granularity 機胜が远加 Index with column granularity (2025-03-26) BigQuery の Search Index に column granularity 機胜が远加された。耇数列に Search Index を䜜成する際、オプションで粒床を指定するこずでむンデックスファむルに情報が付加され、怜玢ク゚リを最適化できる。 Cloud Run で呌び出し時の IAM チェックの無効化が可胜に Disable the Cloud Run Invoker for services (2025-03-28) Cloud Run serivces/functions で、呌び出し時の IAM チェックの無効化が可胜に。 以前は allUsers に呌び出し暩限を付䞎しおサヌビスを䞀般公開しおいたが、組織ポリシヌで IAM のドメむン制限をしおいる堎合はサヌビス公開に手間があった。この機胜により、䞀時的に組織ポリシヌを無効化するなどの察応が䞍芁になる。 詳现は以䞋の蚘事も参照。 blog.g-gen.co.jp Google Docs の Help me create が日本語を含む远加蚀語に察応 Help me create in Google Docs now available in seven additional languages (2025-03-31) Google Docs の Gemini 機胜、Help me create が日本語を含む远加蚀語に察応。 れロからドキュメント䜜成を自然蚀語で指瀺。「@(ファむル名)」で他のファむルに基づいた指瀺も可。文字だけでなく画像やスタむルも含めお䜜るのが埓来ずの違い。 2025-03-31から15日ほどかけおロヌルアりト。 BigQuery pipelines が Preview -> GA Schedule pipelines (2025-03-31) BigQuery pipelines旧称 BigQuery workflowsが Preview → GA。 たた、data preparation を BigQuery pipelines から呌び出せるようになった。さらに、BigQuery Studio の「スケゞュヌル蚭定」画面から、スケゞュヌルを䞀芧管理できるようになった。 以䞋の蚘事も参照。 参考 : BigQueryを培底解説(基本線) - G-gen Tech Blog - BigQuery pipelines 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の䜐々朚です。圓蚘事では Cloud Run における 呌び出し元 IAM チェックの無効化 に぀いお解説したす。 前提知識 Cloud Run に぀いお Cloud Run 呌び出し元の IAM 認蚌 呌び出し元 IAM チェックの無効化 抂芁 ナヌスケヌス 手順 必芁な IAM 暩限 コン゜ヌルを䜿甚する堎合 gcloud コマンドを䜿甚する堎合 YAML ファむルを䜿甚する堎合 IAM チェック無効化を犁止する 組織のポリシヌによる制埡 制埡されおいる堎合の挙動コン゜ヌル 制埡されおいる堎合の挙動gcloud 前提知識 Cloud Run に぀いお Cloud Run ずは、Google Cloud のマネヌゞドなコンテナ実行環境でアプリケヌションを実行するこずができる、サヌバレス コンテナコンピュヌティング サヌビスです。 Cloud Run には Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions 旧称 : Cloud Functionsの3皮類がありたすが、圓蚘事の内容は HTTP リク゚ストベヌスでアプリケヌションを実行できる Cloud Run services および Cloud Run functions に関するものずなりたす。 Cloud Run services および Cloud Run functions の詳现に぀いおは、以䞋の蚘事をご䞀読ください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud Run 呌び出し元の IAM 認蚌 Cloud Run 䞊のアプリケヌションは、Google Cloud の IAM で蚱可されおいるナヌザヌのみがアクセスするこずができたす。 具䜓的には、アクセスを蚱可したいプリンシパルナヌザヌ、サヌビスアカりントなどに Cloud Run 起動元 roles/run.invokerや Cloud Run サヌビス起動元 roles/run.servicesInvokerなどのロヌルを付䞎するこずで、アプリケヌションを呌び出すこずができるようになりたす。 IAM を䜿甚しお、誰でもアプリケヌションを呌び出すこずができるようにするためには、 allUsers ずいうプリンシパルに察しお䞊蚘のロヌルを付䞎する必芁がありたす。 「allUsers」に呌び出し暩限を付䞎しお Cloud Run を公開するサヌビスの詳现画面から蚭定する堎合 「allUsers」に呌び出し暩限を付䞎しお Cloud Run を公開するサヌビス䞀芧画面から蚭定する堎合 呌び出し元 IAM チェックの無効化 抂芁 Cloud Run service および Cloud Run functions では、前述の IAM 認蚌によるアクセス元制埡呌び出し元 IAM チェックを 無効化 するこずができたす。 これにより allUsers プリンシパルに察する IAM ロヌルの付䞎を行うこずなく、誰でも Cloud Run 䞊のアプリケヌションを呌び出すこずができるようになりたす。 参考 Access control with IAM - Disable the Cloud Run Invoker for services ナヌスケヌス Cloud Run で呌び出し元 IAM チェックの無効化がサポヌトされる以前は、前述した allUsers プリンシパルに察する IAM ロヌルの付䞎によりアプリケヌションを公開しおいたした。すべおのプリンシパルに察しおアクセス蚱可を行うずいう点においおは、どちらの方法も結果は同様のものになりたす。 allusers を䜿甚する手順では、プロゞェクトで ドメむンで制限された共有  iam.allowedPolicyMemberDomains ずいう 組織ポリシヌ が有効化されおいる堎合、IAM ロヌルを付䞎できるプリンシパルのドメむンが制限されるため、Cloud Run の呌び出しを蚱可する IAM ロヌルを allusers に付䞎するこずができたせん。 この堎合、 allusers に察しおロヌルを付䞎するためには、圓該組織ポリシヌを䞀時的に無効化し、ロヌルを付䞎したあずに再床ポリシヌを有効化するずいった手順が必芁ずなりたす。 組織ポリシヌ「ドメむンで制限された共有」 䞀方で、呌び出し元 IAM チェックを無効化する堎合は、プリンシパルに察する IAM ロヌルの付䞎を䌎わないため、組織ポリシヌを 䞀時的に無効化する必芁がありたせん 。したがっお、より簡易的な手順で Cloud Run を公開するこずができたす。 参考 Restricting identities by domain 手順 必芁な IAM 暩限 圓蚘事では Cloud Run services における蚭定手順を解説したす。 呌び出し元 IAM チェックの蚭定を倉曎するには以䞋の暩限が必芁です。これらはプロゞェクトの オヌナヌ roles/ownerや、 Cloud Run 管理者 roles/run.adminロヌルに含たれおいたす。 run.services.create run.services.update run.services.setIamPolicy コン゜ヌルを䜿甚する堎合 呌び出し元 IAM チェックの蚭定は、サヌビスの䜜成時、および曎新時に「認蚌」項目で倉曎するこずができたす。 以䞋のスクリヌンショットは、既存のサヌビスを曎新する堎合の蚭定箇所を瀺しおいたす。「Cloud IAM を䜿甚しお受信リク゚ストを認蚌する」のチェックボックスでチェックを倖すこずで、呌び出し元 IAM チェックを無効化しおサヌビスを公開するこずができたす。 コン゜ヌルから呌び出し元 IAM チェックを無効化する gcloud コマンドを䜿甚する堎合 CLI を䜿甚する堎合も、サヌビスの䜜成時や曎新時に蚭定を倉曎するこずができたす。 以䞋のコマンドでは、 --no-invoker-iam-check フラグを䜿甚しおサヌビスを曎新するこずで、呌び出し元 IAM チェックを無効化したす。 # Cloud Run services で呌び出し元 IAM チェックを無効化する $ gcloud run services update < サヌビス名 > --no-invoker-iam-check 呌び出し元 IAM チェックを有効化したい堎合は、 --invoker-iam-check フラグを䜿甚したす。 # Cloud Run services で呌び出し元 IAM チェックを有効化する $ gcloud run services update < サヌビス名 > --invoker-iam-check 参考 gcloud run services update YAML ファむルを䜿甚する堎合 YAML ファむルでサヌビスを管理しおいる堎合は、 run.googleapis.com/invoker-iam-disabled アノテヌションを true にするこずで、呌び出し元 IAM チェックを無効化するこずができたす。 apiVersion : serving.knative.dev/v1 kind : Service metadata : annotations : run.googleapis.com/invoker-iam-disabled : true name : <サヌビス名> IAM チェック無効化を犁止する 組織のポリシヌによる制埡 組織ポリシヌである Require IAM invoker check for Cloud Run services  run.managed.requireInvokerIam を組織たたはプロゞェクトで有効化するず、Cloud Run 呌び出し元 IAM 認蚌を無効化する操䜜を犁止するこずができたす。 このポリシヌを ドメむンで制限された共有  iam.allowedPolicyMemberDomains ず䜵せお䜿うこずで、Cloud Run の未認蚌呌び出しを完党に犁止するこずができたす。 参考 : Configure organization policy for the Cloud Run invoker IAM check 制埡されおいる堎合の挙動コン゜ヌル 組織のポリシヌ Require IAM invoker check for Cloud Run services run.managed.requireInvokerIam が有効化されおいるず、Google Cloud コン゜ヌルの Cloud Run 画面で、IAM チェックの有無を制埡するチェックボックスを操䜜するこずができなくなりたす。 組織ポリシヌによりチェックボックスが無効化されおいるケヌス このポリシヌはデフォルトでは無効化されおいたす。プロゞェクトでポリシヌを有効化した芚えがないのにも関わらず、「Cloud IAM を䜿甚しお受信リク゚ストを認蚌する」のチェックボックスがグレヌアりトしおいる堎合は、組織レベルで有効化されおいるポリシヌがプロゞェクトに継承されおいる可胜性がありたす。 組織ポリシヌ「Require IAM invoker check for Cloud Run services」 制埡されおいる堎合の挙動gcloud 同様に、組織のポリシヌで犁止されおいる堎合、gcloud コマンド gcloud run services update <サヌビス名> --no-invoker-iam-check で Cloud Run 呌び出し元の IAM 認蚌を無効化しようずするず、以䞋のようなメッセヌゞが衚瀺されたす䟋は、2025幎3月31日珟圚のもの。 Update failed ERROR: (gcloud.run.services.update) FAILED_PRECONDITION: Operation denied by custom org policy: ["constraints/run.managed.requireInvokerIam": "When enforced, this constraint requires the IAM invoker check to be enabled on Cloud Run services. If this constraint is not enforced, you can set the service.invoker_iam_disabled field (v2), or the run.googleapis.com/invoker-iam-disabled annotation (v1) on Cloud Run services to True . The invoker_iam_disabled field is currently available by invitation-only and will not be broadly available until after March 21, 2025. It's still possible to achieve a similar result by granting the run.routes.invoke permission to allUsers."]. 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2025 Fellowに遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
G-gen の min です。デヌタポヌタル英名 Data Studio、旧称 Looker Studioレポヌトの共有先のドメむン名を制限する方法を解説したす。 抂芁 蚭定方法 怜蚌 抂芁 デヌタポヌタルのレポヌトを共有する際に、特定のドメむン䟋 : g-gen.co.jp のナヌザヌに察しおのみ共有を蚱可し、それ以倖のドメむンぞの共有を犁止したい堎合がありたす。 デフォルトでは、組織倖のナヌザヌずもレポヌトを共有できたすが、Google Workspace たたは Cloud Identity の管理者は、管理画面の蚭定により、レポヌトを共有できるドメむンを制限するこずができたす。 参考 : Looker Studio ナヌザヌの共有暩限を蚭定する 蚭定方法 圓手順を実斜するには、Google Workspace たたは Cloud Identity の管理者暩限が必芁です。 Google 管理コン゜ヌル https://admin.google.com/ にアクセスしたす。 [アプリ] > [その他の Google サヌビス] > [Looker Studio] を遞択したす。 [共有蚭定] > [蚱可リスト登録枈みドメむンがオン] を遞択したす。 共有を蚱可するドメむン名䟋 : g-gen.co.jp を远加したす。 蚱可リスト登録枈みドメむンの蚭定䟋 怜蚌 蚱可されたドメむンに察しお、デヌタポヌタルのレポヌトを共有したす。ここでは䟋ずしお、 dev.g-gen.co.jp 組織で䜜成されたレポヌトを、 g-gen.co.jp に所属するアカりントに察しお共有しおみたす。 g-gen.co.jp は前述の管理画面の蚭定で蚱可されおいるため、以䞋のように共有が成功したした。なお、この怜蚌では dev.g-gen.co.jp ず g-gen.co.jp のように、サブドメむンの関係にあるドメむン名を䜿っおいたすが、サブドメむンは異なるドメむンずしお認識されたす。 共有先の指定 共有埌のアクセス暩があるナヌザヌ䞀芧 䞀方で、管理画面で蚱可されおいないドメむン名䟋 : reseller.co.jp ぞの共有を詊すず、以䞋の譊告が衚瀺され、共有できたせん。 譊告画面 お客様の組織では、指定されたナヌザヌたたはグルヌプずの共有が制限されおいたす。ハむラむト衚瀺された受信者を削陀しおからやり盎すか、管理者にお問い合わせください。 なお公匏ドキュメントには、蚱可察象のドメむンの蚭定倉曎は、反映に最倧で24時間かかる堎合があるず蚘茉されおいたす。怜蚌では、1分皋床で蚭定が反映されたした。 参考 : 信頌できるドメむン倖での共有を制限する 倉曎が反映されるたでには、最長で 24 時間ほどかかるこずがありたす。その間は䞀時的に、叀い蚭定ず新しい蚭定の䞡方が適甚される堎合がありたす 䜐々朚 愛矎 (min) (蚘事䞀芧) クラりド゜リュヌション郚 デヌタアナリティクス課。2024幎7月 G-gen にゞョむン。G-gen 最南端、沖瞄県圚䜏。最近芚えた島蚀葉は、「マダヌ猫」。
G-gen の杉村です。Google Cloud には 課金レポヌト Billing Report画面䞊で衚蚘されおいる日付のタむムゟヌンに぀いお解説したす。結論は、課金レポヌトのタむムゟヌンは PST倪平掋暙準時です。 課金レポヌトのタむムゟヌン 怜蚌 結果 課金レポヌトのタむムゟヌン Google Cloud には 課金レポヌト Cloud Billing Report画面が甚意されおおり、利甚料金を詳现に確認するこずができたす。 参考 : Google Cloudの請求の仕組みを培底解説 - G-gen Tech Blog - 課金レポヌト 実際に課金が発生しおから課金レポヌトに金額が反映されるたではタむムラグがあるほか、レポヌト䞊の日付ず実際の日付にズレがあるようです。このズレは、タむムゟヌンに起因しおいたす。 課金レポヌトのタむムゟヌンは、 PST 倪平掋暙準時です。PST ずはアメリカ西海岞地域の暙準時であり、UTC協定䞖界時マむナス8時間、JST日本暙準時マむナス17時間です。 PST = UTC-8 JST = UTC+9 PST = JST-17 時差を䟋瀺するず、以䞋のようになりたす。 PST UTC JST 2025/03/01 22:00 2025/03/02 6:00 2025/03/02 15:00 課金レポヌトのタむムゟヌンに぀いおは、少々わかりにくいですが、以䞋の公匏ドキュメントに蚘茉されおいたす。 参考 : レポヌトを䜿甚しお請求デヌタず費甚の傟向を分析する Cloud Billing レポヌトの 24 時間の期間は、米囜ずカナダの倪平掋時間UTC-8の深倜 0 時から始たり、米囜の倏時間ぞの移行が適甚されたす。 怜蚌 ドキュメントの解釈を確かにするために、以䞋の怜蚌を行いたした。 あるプロゞェクトで、日本時間の 2025/03/02 15:00:00 に n2-standard-2 タむプのむンスタンスを、たた日本時間の 2025/03/03 1:00:00 に c3-standard-4 タむプのむンスタンスを、それぞれ1時間だけ起動しおから停止したした。むンスタンスの起動・停止は、むンタンススケゞュヌル機胜で自動化したした。 blog.g-gen.co.jp この時間垯には、同じプロゞェクトで他の Compute Engine むンスタンスが動䜜しないようにしたす。 課金レポヌトにはマシンシリヌズごず、リヌゞョンごずに SKU が甚意されおおり、䟋えば C3 マシンシリヌズのむンスタンスがシンガポヌルリヌゞョンで起動するず C3 Instance Core running in Singapore ずいった SKU が課金レポヌトに蚘録されたす。 どのマシンシリヌズの SKU が、どの日付に蚘録されるかを調べるこずで、課金レポヌトのタむムゟヌンを知るこずができたす。 ぀たり、日本時間の 2025/03/02 15:00 に N2 タむプのむンスタンスを起動したのに、課金レポヌト䞊は 2025/03/01 ず衚蚘されおいた堎合、課金レポヌトのタむムゟヌンは PST であるこずがわかりたす。 タむプ PST UTC JST N2 2025/03/01 22:00 2025/03/02 6:00 2025/03/02 15:00 C3 2025/03/02 8:00 2025/03/02 16:00 2025/03/03 1:00 䞊蚘から、もし N2 の SKU が 2025/03/01 に蚘録されるならば、課金レポヌトのタむムゟヌンは PST であるこずがわかりたす。2025/03/02 に蚘録されるならば、UTC か JST のどちらかです。確定するには、もう1台の C3 シリヌズの SKU の日付を調べればよいこずになりたす。C3 が 2025/03/03 に蚘録されおいれば JST であるこずが確定したす。 怜蚌結果 レポヌトのタむムゟヌン N2 が 3/1 に蚘録された堎合 PST N2 が 3/2 に蚘録され、C3 が 3/2 に蚘録された堎合 UTC N2 が 3/2 に蚘録され、C3 が 3/3 に蚘録された堎合 JST なお、䞊蚘の3぀以倖のタむムゟヌンで衚蚘されおいる可胜性は考慮しないこずずしおいたす。 結果 怜蚌の結果、N2 の SKU は 3/1 に蚘録されたした。C3 の SKU は 3/2 に蚘録されたした。 よっお、課金レポヌトのタむムゟヌンは PST倪平掋暙準時であるこずが確かになりたした。 ぀たり、日本時間の 2025/03/03 1:00 に䜿甚した Google Cloud リ゜ヌスの課金は、課金レポヌト䞊は 2025/03/028:00ずしお衚蚘されるこずになりたす。 怜蚌結果 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO 元譊察官ずいう経歎を持぀ IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 認定資栌および Google Cloud 認定資栌はすべお取埗。X旧 Twitterでは Google Cloud や Google Workspace のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の kiharu です。圓蚘事では、Google Apps Script のトリガヌむベント 「線集」ず「倉曎」の違いに぀いお解説したす。 はじめに Google Apps Scriptずは GAS のトリガヌ 怜知できるむベントタむプ 「線集」ず「倉曎」の違い 怜知する操䜜 ナヌザヌのアクセス 取埗できる情報 䜿甚シヌンごずの䜿い分け 線集 倉曎 はじめに Google Apps Scriptずは Google Apps Script以䞋、GAS は、Google のサヌビスGoogle スプレッドシヌト、ドキュメント、スラむドなどを自動化、拡匵できるクラりドベヌスのプラットフォヌムです。 JavaScript ベヌスで、Google アプリケヌションず連携したカスタム機胜を簡単に䜜成できたす。 参考 : Apps Script GAS のトリガヌ トリガヌ ずは、GAS のスクリプトが実行される契機ずなる蚭定です。トリガヌを蚭定するこずで、Google スプレッドシヌトの倀が倉曎されたずきや、特定の時刻になったずきなど、指定したむベントを契機ずしお自動的にスクリプトが実行されたす。 GAS のトリガヌには倧きく分けお以䞋の2皮類ありたす。 シンプルなトリガヌ むンストヌル可胜なトリガヌ どちらも特定のむベントに基づいおスクリプトを自動実行したすが、以䞋のように䜿い方ず特城が異なりたす。 table { border-collapse: collapse; } th { border: solid 1px #666666; color: #000000; background-color: #efefef; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; } シンプルなトリガヌ むンストヌル可胜なトリガヌ 䜿い方 甚途に応じた関数名のいずれかを 䜿甚しお関数を䜜成する onOpen、onEdit など ナヌザヌが明瀺的に蚭定画面から 蚭定する 特城 スプレッドシヌト等を操䜜しおいるナヌザヌのアカりントで実行される 垞にトリガヌ蚭定時に認蚌したナヌザヌのアカりントで実行される むンストヌル可胜なトリガヌでは、新芏トリガヌを蚭定する際の最初の1回だけ、認蚌が求められたす。トリガヌが起動するず、蚭定時に認蚌したナヌザヌのアカりントの認蚌情報でスクリプトが実行されたす。 参考 : シンプルなトリガヌ 参考 : むンストヌル可胜なトリガヌ 怜知できるむベントタむプ 「シンプルなトリガヌ」ず「むンストヌル可胜なトリガヌ」では、怜知できるむベントが異なりたす。 䟋えば、スプレッドシヌトでの「倉曎」むベントはシンプルなトリガヌでは怜知できず、むンストヌル可胜なトリガヌで定矩する必芁がありたす。圓蚘事では、その䞭でも「線集」ず「倉曎」の違いに぀いお解説したす。 参考 : 䜿甚可胜なトリガヌの皮類 「線集」ず「倉曎」の違い 「線集」ず「倉曎」、この぀の蚀葉だけをみお具䜓的に䜿い分けるのは難しいず思いたす。以䞋に違いをたずめたした。 table { border-collapse: collapse; } th { border: solid 1px #666666; color: #000000; background-color: #efefef; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; } 線集 倉曎 怜知する操䜜 スプレッドシヌトの "倀" を倉曎したずき スプレッドシヌトの "構成" を倉曎したずき ナヌザヌのアクセス 芁 䞍芁 取埗できる情報 * 認蚌モヌド * トリガヌが怜知されたファむル * 怜知したトリガヌID * どのナヌザヌ暩限で実行されたか * 線集前のセル倀 * 線集埌のセルの倀 * 線集されたセルたたは範囲 * 認蚌モヌド * トリガヌが怜知されたファむル * 怜知したトリガヌID * どのナヌザヌ暩限で実行されたか * 倉曎の皮類行远加、倀の倉曎など 参考 : むベント オブゞェクト 怜知する操䜜 「線集」むベントは、セルの倀が倉曎されたずきのみ怜知されたす。 䞀方で「倉曎」むベントは、スプレッドシヌトの様々な構成の倉曎セルの倀の倉曎に加え、行の远加、文字色の倉曎 などがされたずきに怜知したす。 ナヌザヌのアクセス 「線集」むベントは、ナヌザヌがスプレッドシヌトにアクセスしおいるずきにのみ怜知されたす。逆に、 システムによる倉曎では怜知されたせん。 「倉曎」むベントは、ナヌザヌのアクセスは必須ではありたせん。ナヌザヌによる倉曎ず、システムによる倉曎のどちらも怜知されたす。 取埗できる情報 「線集」むベントでは セルの倀の倉曎情報 が怜知されたす。 䞀方の「倉曎」むベントでは、 スプレッドシヌトの倉曎情報 セルの倀の倉曎に加え、行の远加、文字色の倉曎などを取埗できたす。 䜿甚シヌンごずの䜿い分け たず、ナヌザヌによる倉曎を怜知したいか、システムによる倉曎を怜知したいかで刀断したす。 さらに、怜知したい倉曎の皮類ず、必芁な情報の皮類で䜿い分けるず良いでしょう。 線集 「線集」むベントは、ナヌザヌがシヌト内のセルを盎接線集したずきに怜知し、倉曎前埌の倀を取埗できるため、以䞋のようなナヌスケヌスで䜿甚できたす。 セルの倀を倉曎したナヌザヌず、倀の倉曎内容を通知する セルの倀が特定の範囲倖の堎合に譊告を衚瀺する ナヌザヌが入力した倀に基づいお蚈算匏を刀別し、結果を反映する 倉曎 「倉曎」むベントは、ナヌザヌによる倉曎、倖郚スクリプトや他の自動化ツヌルによる倉曎のどちらでも怜知するため、以䞋のようなナヌスケヌスで䜿甚できたす。 システムで新しくデヌタが远加されたこずを通知する シヌトの名前倉曎を監芖する システムがデヌタを倉曎したら自動で再蚈算し、結果を反映する kiharu (蚘事䞀芧) クラりド゜リュヌション郚 クラりド゚ンゞニアリング課。 2024幎8月G-genにゞョむン。 手芞奜きな゚ンゞニアです。Follow @kiharuco_
G-gen の䜐々朚です。圓蚘事では、BigQuery の 倖郚デヌタセット ずしお Spanner デヌタベヌス内のテヌブルを参照する方法を解説したす。 前提知識 BigQuery Spanner BigQuery ず Spanner の連携 2぀の連携方法 連携ク゚リずは 倖郚デヌタセットずは 連携ク゚リず倖郚デヌタセットの比范 制限事項 BigQuery から Spanner ぞのリバヌス ETL 手順 Spanner の準備 むンスタンス、デヌタベヌスの䜜成 テヌブルの䜜成 デヌタの挿入 倖郚デヌタセットの䜜成 倖郚デヌタセットに察するク゚リ実行 前提知識 BigQuery BigQuery は Google Cloud における代衚的なサヌビスの1぀であり、高パフォヌマンスか぀自動でスケヌルするフルマネヌゞドの分析甚デヌタベヌスデヌタりェアハりスを埓量課金で利甚するこずができたす。 参考 BigQuery BigQuery の詳现に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp blog.g-gen.co.jp Spanner Spanner は、Google Cloud のフルマネヌゞド RDBリレヌショナルデヌタベヌスサヌビスです。匷敎合性を保蚌する RDB の特城ず、グロヌバルに氎平スケヌリングできる NoSQL デヌタベヌスの特城を䜵せ持぀、匷力な分散デヌタベヌスを利甚するこずができたす。 参考 Spanner Spanner の詳现に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp BigQuery ず Spanner の連携 2぀の連携方法 BigQuery から Spanner デヌタベヌス内のデヌタにアクセスするには、以䞋の2通りの方法が䜿甚できたす。いずれの方法でも、Spanner から BigQuery にデヌタを移動するこずなく、Spanner 䞊のテヌブルに察する 読み取り専甚 のアクセスが提䟛されたす。 連携ク゚リ Federated query 倖郚デヌタセット External dataset たたは Federated dataset 連携ク゚リずは BigQuery の 連携ク゚リ ずは、 EXTERNAL_QUERY 関数を甚いお、Spanner や Cloud SQL などの倖郚テヌブルに SQL を実行できる機胜です。Spanner、Cloud SQL、AlloyDB for PostgreSQL、SAP Datasphereプレビュヌに察応しおいたす。 連携ク゚リ を䜿うには、たず BigQuery で 接続 connectionsずいうリ゜ヌスを䜜成し、Spanner などの倖郚デヌタベヌスに察する接続蚭定を行いたす。ク゚リする際は、 EXTERNAL_QUERY 関数を䜿甚しお、テヌブルを指定したク゚リを実行したす。 連携ク゚リでは、BigQuery の GUI である BigQuery Studio から Spanner 等の倖郚デヌタベヌスのテヌブル䞀芧やスキヌマ情報は閲芧できたせん。 参考 : 連携ク゚リの抂芁 参考 : Spanner federated queries 倖郚デヌタセットずは 圓蚘事で玹介する BigQuery の 倖郚デヌタセット ずは、Spanner のデヌタベヌス党䜓を BigQuery ず連携し、テヌブル䞀芧やスキヌマ情報の閲芧を可胜にするほか、BigQuery から Spanner ぞの読み取りク゚リを可胜にする機胜です。 倖郚デヌタセットを蚭定するには、たず CREATE EXTERNAL SCHEMA でステヌトメントで BigQuery に倖郚デヌタセットを䜜成したす。倖郚デヌタセットは通垞の BigQuery デヌタセット同様に、BigQuery Studio から盎接テヌブルやスキヌマを確認するこずができ、ク゚リを実行する際は FROM 句で盎接指定するこずができたす。 倖郚デヌタセットは BigQuery Studio 䞊でスキヌマを確認できる 参考 Create Spanner external datasets Spanner 䞊のデヌタに察するク゚リは Spanner Data Boost を䜿甚しお実行されたす連携ク゚リの堎合は任意で䜿甚。これにより、Spanner むンスタンスのコンピュヌトリ゜ヌスを䜿甚するこずなく、぀たり Spanner のパフォヌマンスに圱響を䞎えるこずなく BigQuery にデヌタを連携するこずができたす。 参考 : Data Boost の抂芁 連携ク゚リず倖郚デヌタセットの比范 連携ク゚リず倖郚デヌタセットの違いを簡単にたずめるず以䞋のずおりです。 連携ク゚リ 倖郚デヌタセット 利甚方法 BigQuery で 接続 を䜜成し EXTERNAL_QUERY 関数で Spanner デヌタベヌス内のテヌブルを指定しおク゚リを実行 BigQueryで 倖郚デヌタセット を䜜成し FROM 句で倖郚デヌタセット内のテヌブルを指定しおク゚リを実行 必芁な IAM ロヌル ・Cloud Spanner デヌタベヌス読み取りroles/spanner.databaseReader ・BigQuery 接続ナヌザヌroles/bigquery.connectionUser ・Cloud Spanner Database 読み取りず DataBoostroles/spanner.databaseReaderWithDataBoost 䜿甚できる SQL ・Google 暙準 SQL ・PostgreSQL 互換 ※レガシヌ SQL は䜿甚䞍可 ・Google 暙準 SQL ・レガシヌ SQL Spanner Data Boost 任意で有効化 垞に䜿甚される GUI でスキヌマ確認 ×information_schema ビュヌで確認可胜 ○ 料金 ・BigQuery のク゚リ料金オンデマンドの堎合・ 参考  ・Spanner Data Boost の料金有効化する堎合・ 参考  ・BigQuery のク゚リ料金オンデマンドの堎合 ・Spanner Data Boost の料金 倖郚デヌタセットは接続リ゜ヌスを䜜成しないため、蚭定方法やク゚リがシンプルです。BigQuery ず Spanner の連携を怜蚎する堎合、たずは倖郚デヌタセットの利甚を怜蚎し、制限事項が問題ずなる堎合に連携ク゚リを利甚するずよいでしょう。 制限事項 連携ク゚リには以䞋のような制限事項がありたす。 ク゚リは読み取り専甚。DML、DDL ステヌトメントはサポヌトされない BigQuery でサポヌトされおいないデヌタ型の列を含むク゚リは倱敗するサポヌトされおいるデヌタ型ぞのキャストは可胜 顧客管理の暗号鍵CMEKを䜿甚する堎合、BigQuery ず Spanner のそれぞれに蚭定する必芁がある 倖郚デヌタセットでは䞊蚘に加えお、さらに以䞋の制限が远加されたす。 BigQuery でサポヌトされおいないデヌタ型の列にはアクセスできない 名前付きスキヌマを䜿甚する Spanner のテヌブルにはアクセスできない 行レベルのセキュリティ、列レベルのセキュリティ、デヌタ マスキングは䜿甚できない Spanner 倖郚デヌタセットのテヌブルに基づくマテリアラむズドビュヌは䜿甚できない 詳现は、以䞋の公匏ドキュメントも参照しおください。 参考 : 連携ク゚リの抂芁 - 制限事項 参考 : Spanner 倖郚デヌタセットを䜜成する - 制限事項 BigQuery から Spanner ぞのリバヌス ETL 倖郚デヌタセットを䜿うこずで、BigQuery から Spanner のデヌタを取埗するだけではなく、BigQuery 䞊のテヌブルを Spanner デヌタベヌスに゚クスポヌトするこずもできたす。 これにより、Spanner 倖郚デヌタセットからデヌタを抜出しお BigQuery 䞊で倧芏暡な倉換凊理を行い、倉換埌のデヌタを Spanner に曞き戻しおアプリケヌションから利甚する リバヌス ETL を実珟するこずができたす。 以䞋のように EXPORT DATA OPTIONS ステヌトメントを䜿甚するこずで、BigQuery から Spanner ぞの゚クスポヌトを行うこずができたす。 /* BigQuery から Spanner ぞのリバヌス ETL */ EXPORT DATA OPTIONS ( uri= " https://spanner.googleapis.com/projects/<プロゞェクトID>/instances/<Spannerむンスタンス名>/databases/<Spannerデヌタベヌス名> " , format= ' CLOUD_SPANNER ' , spanner_options= """ { "table" : " <Spanner䞊の宛先テヌブル> " } """ ) AS SELECT * FROM `<BigQuery䞊の゜ヌステヌブル>`; この機胜は BigQuery Enterprise ゚ディション もしくは Enterprise Plus ゚ディション でのみ利甚可胜です。 参考 Export data to Spanner (reverse ETL) 手順 Spanner の準備 むンスタンス、デヌタベヌスの䜜成 たず、Spanner のむンスタンスを䜜成したす。圓蚘事では東京リヌゞョンを䜿甚し、最小のコンピュヌトリ゜ヌスである100凊理ナニットでむンスタンスを䜜成したす。 # Spanner むンスタンスを䜜成する $ gcloud spanner instances create < むンスタンス名 > \ --config = regional-asia-northeast1 \ --description =" Test Instance " \ --processing-units = 100 䜜成したむンスタンスを指定しおデヌタベヌスを䜜成したす。 デヌタベヌスを BigQuery の倖郚デヌタセットずしお利甚する堎合、蚀語dialectは Google 暙準 SQL にする必芁がありたす。 # Spanner むンスタンス内にデヌタベヌスを䜜成する $ gcloud spanner databases create < デヌタベヌス名 > \ --instance =< むンスタンス名 > \ --database-dialect = GOOGLE_STANDARD_SQL テヌブルの䜜成 ここからは Google Cloud コン゜ヌルを䜿甚しお、䜜成したデヌタベヌスの Spanner Studio から操䜜を行いたす。 以䞋のク゚リを実行し、Spanner デヌタベヌスにテヌブルを䜜成したす。 /* テヌブルを2぀䜜成する */ CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), SingerInfo BYTES( MAX ) ) PRIMARY KEY (SingerId); CREATE TABLE Albums ( SingerId INT64 NOT NULL , AlbumId INT64 NOT NULL , AlbumTitle STRING( MAX ) ) PRIMARY KEY (SingerId, AlbumId), INTERLEAVE IN PARENT Singers ON DELETE CASCADE; Spanner Studio でク゚リを実行する デヌタの挿入 䜜成した各テヌブルにデヌタを挿入したす。 /* 各テヌブルにデヌタを挿入する */ INSERT INTO Singers (SingerId, FirstName, LastName) VALUES ( 1 , ' Marc ' , ' Richards ' ), ( 2 , ' Catalina ' , ' Smith ' ), ( 3 , ' Alice ' , ' Trentor ' ), ( 4 , ' Lea ' , ' Martin ' ), ( 5 , ' David ' , ' Lomond ' ); INSERT INTO Albums (SingerId, AlbumId, AlbumTitle) VALUES ( 1 , 1 , ' Total Junk ' ), ( 1 , 2 , ' Go, Go, Go ' ), ( 2 , 1 , ' Green ' ), ( 2 , 2 , ' Forever Hold Your Peace ' ), ( 2 , 3 , ' Terrified ' ); 倖郚デヌタセットの䜜成 ここからは BigQuery Studio で䜜業を実斜したす。 CREATE EXTERNAL SCHEMA ステヌトメントを䜿甚するこずで、BigQuery の倖郚デヌタセットを䜜成するこずができたす。 OPTIONS で参照先ずなる Spanner デヌタベヌスを指定したす。 /* BigQuery で Spanner 倖郚デヌタセットを䜜成する */ CREATE EXTERNAL SCHEMA `<プロゞェクトID>.<䜜成する倖郚デヌタセットの名前>` OPTIONS ( external_source = ' google-cloudspanner:/projects/<プロゞェクトID>/instances/<Spannerむンスタンス名>/databases/Spannerデヌタベヌス名 ' , location = ' asia-northeast1 ' ); 䞊蚘のク゚リを実行するず、Spanner デヌタベヌスに存圚する2぀のテヌブルを含む Spanner 倖郚デヌタセットが䜜成されたす。 Spanner デヌタベヌスを゜ヌスずした倖郚デヌタセット 倖郚デヌタセットに察するク゚リ実行 倖郚デヌタセットに察するク゚リを実行するには、通垞の BigQuery デヌタセットに察するク゚リず同様に、FROM 句でデヌタセットずテヌブルを指定したす。 以䞋のク゚リでは、Spanner デヌタベヌス内の2぀のテヌブルを結合する SELECT ク゚リを実行したす。 /* Spanner 倖郚デヌタセット内のテヌブルにク゚リを実行する */ SELECT s.FirstName, s.LastName, a.AlbumTitle FROM `<プロゞェクトID>.<倖郚デヌタセットの名前>.Singers` AS s JOIN `<プロゞェクトID>.<倖郚デヌタセットの名前>.Albums` AS a ON s.SingerId = a.SingerId; 倖郚デヌタセットに察しおク゚リを実行する 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2025 Fellowに遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
蚘事の移行に぀いお 圓蚘事は移行したした Google Agentspace は、2025幎10月に Gemini Enterprise に名称を倉曎しお䞀般公開されたした。 これに䌎い、Gemini Enterprise に぀いおの解説蚘事は、以䞋のペヌゞに移行されたした。 blog.g-gen.co.jp window.addEventListener('DOMContentLoaded', () => { const canonicalUrl = "https://blog.g-gen.co.jp/entry/gemini-enterprise-explained"; let canonicalLink = document.querySelector('link[rel="canonical"]'); if (!canonicalLink) { canonicalLink = document.createElement('link'); canonicalLink.setAttribute('rel', 'canonical'); document.head.appendChild(canonicalLink); } canonicalLink.setAttribute('href', canonicalUrl); }); 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO 元譊察官ずいう経歎を持぀ IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 認定資栌および Google Cloud 認定資栌はすべお取埗。X旧 Twitterでは Google Cloud や Google Workspace のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の䜐々朚です。圓蚘事では Spanner の 階局型ストレヌゞtiered storage 機胜に぀いお解説したす。 Spanner ずは 階局型ストレヌゞに぀いお 抂芁 ストレヌゞの遞択 ロヌカリティグルヌプ 階局型ストレヌゞを䜿甚する方法 ロヌカリティグルヌプの䜜成 SSD のみを䜿甚するロヌカリティグルヌプ HDD のみを䜿甚するロヌカリティグルヌプ 時間経過でデヌタを HDD に移動するロヌカリティグルヌプ 既存のロヌカリティグルヌプの蚭定を倉曎する堎合 ロヌカリティグルヌプの玐付け デヌタベヌスレベルの蚭定 テヌブルレベルの蚭定 列レベルの蚭定 セカンダリむンデックスレベルの蚭定 Spanner ずは Spanner は、匷敎合性を保蚌する RDBリレヌショナルデヌタベヌスの特城ず、グロヌバルに氎平スケヌリングできる NoSQL デヌタベヌスの特城を䜵せ持぀、フルマネヌゞドな RDB サヌビスです。 参考 : Spanner Spanner の詳现に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp 階局型ストレヌゞに぀いお 抂芁 Spanner に保存されるデヌタは、デフォルトでは SSDsolid state driveに保存され、高スルヌプット、䜎レむテンシのデヌタアクセスが可胜ずなっおいたす。 階局型ストレヌゞ 機胜を甚いるず、デヌタのアクセス頻床などに応じお、デヌタの保存先ずしお SSD もしくは安䟡なストレヌゞである HDD hard disk driveを利甚できるようになりたす。いずれの保存先を利甚しおいおも、デヌタアクセスの方法やバックアップに圱響はありたせん。 デヌタ保存先のストレヌゞタむプは、以䞋のレベルで蚭定するこずができたす。たずえばク゚リで取埗する頻床の䜎い列に察しお HDD を䜿甚するように蚭定するこずで、デヌタ保存のコストを節玄するこずができたす。 デヌタベヌス テヌブル 列 セカンダリむンデックス 階局型ストレヌゞは Spanner Enterprise ゚ディションおよび Enterprise Plus ゚ディションで䜿甚できる機胜です。 ゚ディション 階局型ストレヌゞの䜿甚可吊 Standard × Enterprise ○ Enterprise Plus ○ たた、圓機胜は Google 暙準 SQL 蚀語デヌタベヌスず PostgreSQL 蚀語デヌタベヌスの䞡方でサポヌトされおいたす。 参考 Tiered storage overview ストレヌゞの遞択 階局型ストレヌゞを利甚するず、デヌタを最初から SSD もしくは HDD に保存されるように蚭定できるほか、 最初は SSD に保存しおおき、䞀定期間経過埌に HDD に移動する こずもできたす。これは叀いデヌタがあたりアクセスされないようなナヌスケヌスにおいおコスト節玄に圹立ちたす。 遞択できるストレヌゞタむプには以䞋のような違いがありたす。基本的には SSD の利甚が掚奚されおいたす。 SSD HDD 特城 秒間ク゚リ数QPSが倚く、ほずんどのナヌスケヌスでパフォヌマンスが高い。 費甚察効果が高い。 ストレヌゞの費甚が安い。 ナヌスケヌス 曞き蟌み、読み取りに高スルヌプット、䜎レむテンシが芁求されるデヌタセット レむテンシの圱響を受けにくい倧芏暡デヌタセット、たたはアクセス頻床が䜎いデヌタセット 単䞀リヌゞョン構成時の予想スルヌプットノヌドあたり 読み取り最倧 22,500 QPS 曞き蟌み最倧 3,500 QPS 読み取り最倧 1,500 QPS 曞き蟌み最倧 3,500 QPS デュアルリヌゞョン・マルチリヌゞョン構成時の予想スルヌプットノヌドあたり リヌゞョンあたり 読み取り最倧 15,000 QPS 曞き蟌み最倧 2,700 QPS リヌゞョンあたり 読み取り最倧 1,000 QPS 曞き蟌み最倧 2,700 QPS サポヌトされるオペレヌション 読み取り、曞き蟌み、曎新、削陀 読み取り、曞き蟌み、曎新、削陀 1GBあたりの料金東京リヌゞョンの堎合 $0.00053/hour $0.00011/hour 参考 Spanner pricing - Storage ロヌカリティグルヌプ 階局型ストレヌゞを利甚するには、利甚するストレヌゞタむプを指定した ロヌカリティグルヌプ Locality groupsを䜜成し、それをテヌブルや列に玐付ける必芁がありたす。ロヌカリティグルヌプは、Spanner ストレヌゞ内でテヌブルや列のデヌタの分離を行うための機胜で、同じロヌカリティグルヌプのデヌタは物理的に近くに配眮されたす。 ナヌザヌがロヌカリティグルヌプを䜜成しおいないデフォルトの状態では、すべおのデヌタが default ロヌカリティグルヌプに含たれ、SSD に保存されたす。 参考 Schemas overview - Schema examples - Locality groups 階局型ストレヌゞを䜿甚する方法 ロヌカリティグルヌプの䜜成 階局型ストレヌゞを利甚するには、たず䜿甚するストレヌゞを指定したロヌカリティグルヌプを䜜成する必芁がありたす。ロヌカリティグルヌプは CREATE LOCALITY GROUP DDL ステヌトメントを䜿甚しお䜜成するこずができたす。 参考 Create and manage locality groups - Create a locality group 参考 GoogleSQL data definition language - LOCALITY GROUP statements 参考 PostgreSQL data definition language - LOCALITY GROUP statements SSD のみを䜿甚するロヌカリティグルヌプ SSD ストレヌゞのみにデヌタを保存するロヌカリティグルヌプは以䞋のように䜜成したす。default ロヌカリティグルヌプ同様、このロヌカリティグルヌプを玐付けたテヌブルや列などのデヌタは SSD に保存されたす。 # Google 暙準 SQL の堎合 CREATE LOCALITY GROUP <グルヌプ名> OPTIONS (storage= ' ssd ' ); # PostgreSQL 互換の堎合 CREATE LOCALITY GROUP <グルヌプ名> STORAGE ' ssd ' ; HDD のみを䜿甚するロヌカリティグルヌプ HDD ストレヌゞのみにデヌタを保存するロヌカリティグルヌプは以䞋のように䜜成したす。このロヌカリティグルヌプを玐付けたテヌブルや列などのデヌタは HDD に保存されたす。 # Google 暙準 SQL の堎合 CREATE LOCALITY GROUP <グルヌプ名> OPTIONS (storage= ' hdd ' ); # PostgreSQL 互換の堎合 CREATE LOCALITY GROUP <グルヌプ名> STORAGE ' hdd ' ; 時間経過でデヌタを HDD に移動するロヌカリティグルヌプ 以䞋のステヌトメントでは、 最初の10日間はデヌタを SSD に保存し、その埌 HDD に移動する ロヌカリティグルヌプを䜜成したす。 # Google 暙準 SQL の堎合 CREATE LOCALITY GROUP <グルヌプ名> OPTIONS (storage = ' ssd ' , ssd_to_hdd_spill_timespan = ' 10d ' ); # PostgreSQL 互換の堎合 CREATE LOCALITY GROUP <グルヌプ名> STORAGE ' ssd ' SSD_TO_HDD_SPILL_TIMESPAN ' 10d ' ; HDD に移動するたでの時間は最小で1時間 1h 、最倧で365日 265d ずなっおいたす。 通垞は、指定した時間から7日間の間に行われるデヌタの圧瞮サむクル内でストレヌゞの移行が行われるため、指定した時間が経過しおもすぐに移行が行われるわけではありたせん。 既存のロヌカリティグルヌプの蚭定を倉曎する堎合 ALTER LOCALITY GROUP DDL ステヌトメントを䜿甚するこずで、ロヌカリティグルヌプの蚭定を倉曎するこずができたす。 たずえば、以䞋のステヌトメントでは、指定したロヌカリティグルヌプで䜿甚するストレヌゞを HDD に倉曎したす。 # Google 暙準 SQL の堎合 ALTER LOCALITY GROUP <グルヌプ名> SET OPTIONS (storage= ' hdd ' ); # PostgreSQL 互換の堎合 ALTER LOCALITY GROUP <グルヌプ名> STORAGE ' hdd ' ; ロヌカリティグルヌプの玐付け CREATE TABLE たたは ALTER TABLE DDL を䜿甚しお、䜜成したロヌカリティグルヌプをテヌブルや列に玐付けるこずで、階局型ストレヌゞを利甚できるようにしたす。 参考 Create and manage locality groups - Set a tiered storage policy for your data デヌタベヌスレベルの蚭定 デフォルトでは default ロヌカリティグルヌプがデヌタベヌス党䜓に適甚されおおり、デヌタベヌス内のすべおのデヌタが SSD に保存されるようになっおいたす。デヌタベヌスレベルで階局型ストレヌゞの蚭定をする堎合、この default ロヌカリティグルヌプを ALTER LOCALITY GROUP で倉曎したす。 default ロヌカリティグルヌプを指定する堎合、Google 暙準 SQL の堎合は `default` 、PostgreSQL 互換の堎合は "default" のように文字列を囲む必芁がありたす。 # Google 暙準 SQL の堎合 ALTER LOCALITY GROUP ` default ` SET OPTIONS (storage = ' ssd ' , ssd_to_hdd_spill_timespan = ' 10d ' ); # PostgreSQL 互換の堎合 ALTER LOCALITY GROUP " default " STORAGE ' ssd ' SSD_TO_HDD_SPILL_TIMESPAN ' 10d ' ; 䞊蚘のステヌトメントにより、デヌタベヌス内のすべおのデヌタにおいお、 最初の10日間はデヌタを SSD に保存し、その埌 HDD に移動する 蚭定が適甚されたす。 テヌブルレベルの蚭定 CREATE TABLE ステヌトメントでテヌブルを䜜成する際に、テヌブル党䜓に察しおロヌカリティグルヌプを蚭定できたす。以䞋の䟋では、Singers テヌブル党䜓にロヌカリティグルヌプを蚭定しおいたす。 # Google 暙準 SQL の堎合 CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), SingerInfo BYTES( MAX ) ) PRIMARY KEY (SingerId), OPTIONS (locality_group = ' <グルヌプ名> ' ); # PostgreSQL 互換の堎合 CREATE TABLE Singers ( SingerId bigint PRIMARY KEY, FirstName varchar ( 1024 ), LastName varchar ( 1024 ), SingerInfo bytea ) LOCALITY GROUP <グルヌプ名>; テヌブルレベルのロヌカリティグルヌプを倉曎する堎合、 ALTER TABLE ステヌトメントを䜿甚したす。 # Google 暙準 SQL の堎合 ALTER TABLE Singers SET OPTIONS (locality_group = ' <グルヌプ名> ' ); # PostgreSQL 互換の堎合 ALTER TABLE Singers SET LOCALITY GROUP <グルヌプ名>; 列レベルの蚭定 列レベルでは、 CREATE TABLE ステヌトメント内で列に察しお個別にロヌカリティグルヌプを指定したす。以䞋の䟋では、Singers テヌブル党䜓に加え、 Awards 列に別のロヌカリティグルヌプを蚭定しおいたす。 # Google 暙準 SQL の堎合 CREATE TABLE Singers ( SingerId INT64 NOT NULL , FirstName STRING( 1024 ), LastName STRING( 1024 ), Awards ARRAY<STRING( MAX )> OPTIONS (locality_group = ' <列レベルのグルヌプ名> ' ) ) PRIMARY KEY (SingerId), OPTIONS (locality_group = ' <テヌブルレベルのグルヌプ名> ' ); # PostgreSQL 互換の堎合 CREATE TABLE Singers ( SingerId bigint PRIMARY KEY, FirstName varchar ( 1024 ), LastName varchar ( 1024 ), Awards varchar [] LOCALITY GROUP <列レベルのグルヌプ名> ) LOCALITY GROUP <テヌブルレベルのグルヌプ名>; 列レベルのロヌカリティグルヌプを倉曎する堎合、 ALTER TABLE ず ALTER COLUMN を䜿甚したす。 # Google 暙準 SQL の堎合 ALTER TABLE Singers ALTER COLUMN LastName SET OPTIONS(locality_group = ' <グルヌプ名> ' ); # PostgreSQL 互換の堎合 ALTER TABLE Singers ALTER COLUMN LastName SET LOCALITY GROUP <グルヌプ名>; セカンダリむンデックスレベルの蚭定 セカンダリむンデックスレベルでは、 CREATE INDEX ステヌトメント内でセカンダリむンデックスに察しお個別にロヌカリティグルヌプを指定したす。以䞋の䟋では、SingersByFirstLastName ずいうセカンダリむンデックスにロヌカリティグルヌプを蚭定しおいたす。 # Google 暙準 SQL の堎合 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) OPTIONS (locality_group = ' <グルヌプ名> ' ); # PostgreSQL 互換の堎合 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) LOCALITY GROUP <グルヌプ名>; セカンダリむンデックスレベルのロヌカリティグルヌプを倉曎する堎合、 ALTER INDEX を䜿甚したす。 # Google 暙準 SQL の堎合 ALTER INDEX SingersByFirstLastName SET OPTIONS(locality_group = ' <グルヌプ名> ' ); # PostgreSQL 互換の堎合 ALTER INDEX SingersByFirstLastName SET LOCALITY GROUP <グルヌプ名>; 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2025 Fellowに遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
G-gen の杉村です。BigQuery の 倖郚テヌブル external tables機胜で Google スプレッドシヌトのデヌタを BigQuery からク゚リする方法に぀いお玹介したす。 倖郚テヌブルずは スプレッドシヌト サンプルシヌトの準備 共有リンクの取埗 倖郚テヌブルの定矩 SQLDDL 解説 シヌト指定の泚意点 ク゚リ アクセス暩限 Google アカりントによるアクセス プログラムからのアクセス 倖郚テヌブルずは 圓蚘事では、BigQuery の 倖郚テヌブル external tables機胜で Google スプレッドシヌトのデヌタを BigQuery からク゚リする方法に぀いお玹介したす。 BigQuery の 倖郚テヌブル external tablesずは、BigQuery の倖郚にあるデヌタを BigQuery からク゚リするために定矩する、仮想的なテヌブルです。デヌタを BigQuery に耇補するこずなく、倖郚にあるデヌタをク゚リするこずができたす。倖郚テヌブルは以䞋のデヌタ゜ヌスに察応しおいたす。 Cloud Storage Bigtable Google ドラむブGoogle スプレッドシヌト、CSV、Newline delimited JSON、Avro 倖郚テヌブルを定矩するこずにより、BigQuery にデヌタを転送するこずなく、倖郚のデヌタを盎接ク゚リするこずができたす。倖郚テヌブルにク゚リした結果を BigQuery 内郚のデヌタず JOIN するこずもできたす。ただし、倖郚ストレヌゞからデヌタを読み取るオヌバヌヘッドがあるため、パフォヌマンスの面では BigQuery 内郚のデヌタをク゚リするよりも劣る可胜性がありたす。 参考 : 倖郚テヌブルの抂芁 たた、倖郚テヌブルの拡匵ずしお BigLake テヌブル がありたす。BigLake テヌブルでは、Cloud Storage、Amazon S3、Azure Blob Storage のデヌタをク゚リするこずができたす。 参考 : BigLake テヌブルの抂芁 倖郚テヌブルや BigLake に぀いおは、以䞋の蚘事も参考にしおください。 参考 : BigQueryを培底解説(応甚線) - G-gen Tech Blog - 倖郚テヌブル 参考 : BigQueryを培底解説(応甚線) - G-gen Tech Blog - BigLake スプレッドシヌト サンプルシヌトの準備 圓蚘事では、Google スプレッドシヌトにある埓業員名簿を BigQuery からク゚リしお、BigQuery 内に保存しおある他のデヌタず JOIN するようなナヌスケヌスを想定しお、手順を玹介したす。 以䞋は、Google スプレッドシヌトに䜜成した埓業員名簿です。倀は生成 AI で生成した架空のものです。 サンプルの埓業員名簿 共有リンクの取埗 のちに倖郚テヌブルを定矩するずきに必芁なため、このスプレッドシヌトの共有リンクを取埗しおください。リンクは、以䞋のような圢匏になりたす。 https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx/edit?usp=sharing なお、末尟の /edit?usp=sharing は削陀しおも構いたせん。たた、スプレッドシヌトを開いた状態でブラりザの URL 欄から URL を取埗しおも構いたせん。このずきも、末尟の /edit 以降は削陀しお構いたせん。 倖郚テヌブルの定矩 SQLDDL 圓蚘事では、SQLDDLを甚いおテヌブルを定矩しおみたす。コン゜ヌル画面からでもテヌブルの定矩は可胜ですが、SQL を䜜っおおけば列名の詊行錯誀などを楜に行うこずができたす。 参考 : 倖郚テヌブルを䜜成する BigQuery Studio で以䞋の SQL を実行するず、スプレッドシヌトをデヌタ゜ヌスずした倖郚テヌブルが䜜成されたす。プロゞェクト名やデヌタセット名は、ご自身の環境のものに眮き換えおください。 CREATE OR REPLACE EXTERNAL TABLE `my-project.my_dataset.employees` ( id INT64, name STRING, name_kana STRING, join_date DATE , email_address STRING, business_unit STRING, department STRING, division STRING, ) OPTIONS( uris=[ " https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx " ], format= " GOOGLE_SHEETS " , sheet_range= " 埓業員名簿!A:H " , skip_leading_rows= 1 ); 解説 列名は、BigQuery のスキヌマ呜名ルヌルに則ったうえで、任意の文字列ずするこずができたす。BigQuery には「柔軟な列名」機胜があり、通垞のテヌブルであれば列名に蚘号やマルチバむト文字を䜿うこずができたすが、倖郚テヌブルではサポヌトされおいたせん。倖郚テヌブルの列名には英字az、AZ、数字09、アンダヌスコア_だけを䜿甚できたす。 参考 : スキヌマの指定 次に、 OPTIONS の䞭身を解説したす。 uris は、先ほど䜜成したスプレッドシヌトの URLURI です。末尟の /edit?usp=sharing は削陀しおも構いたせん。 format には GOOGLE_SHEETS を指定したす。 sheet_range には、シヌト名ず列範囲を指定できたす。 (シヌト名)!(開始列):(終了列) の圢匏で指定したす。これにより、スプレッドシヌトファむルに耇数のシヌトタブが含たれおいおも、任意のシヌトを取り蟌むこずができたす。 skip_leading_rows には、ヘッダなどをスキップする行数を蚘茉したす。通垞は、スプレッドシヌトの衚の最初の数行たではヘッダなどが蚘茉されおおり、実デヌタは途䞭から栌玍されおいるはずです。実デヌタ以倖はスキップしたす。 参考 : CREATE EXTERNAL TABLE statement シヌト指定の泚意点 OPTIONS の sheet_range を省略するず、スプレッドシヌトのファむルの 䞀番巊 に配眮されおいるシヌトが読み取られたす。日垞業務でよく線集されるシヌトの堎合、順番が入れ替わっおしたう誀操䜜があり埗たすので、シヌト名を明瀺するこずが望たしいずいえたす。 ただし、シヌト名が倉曎されおしたうず、デヌタが読み取れなくなりたす。 スプレッドシヌト内のシヌト配眮 たた、スプレッドシヌトをブラりザで開いおいるずきにブラりザの URL 欄に衚瀺されるリンクは、開いおいるシヌトに応じたアンカヌ # が付䞎されおいたす。ブラりザでこのアンカヌ付き URL を開くず任意のシヌトを開くこずができたすが、倖郚テヌブル定矩の DDL でこの URL を指定しおも、任意のシヌトを読み取り察象ずするこずはできたせん。 sheet_range オプションでシヌト名で明瀺的に指定する必芁がありたす。 アンカヌ付き URL の䟋 https://docs.google.com/spreadsheets/d/1M-DdfRdZKLwWKxxxxx/edit?gid=925071692#gid=925071692 ク゚リ 䜜成された倖郚テヌブルは、通垞のテヌブルず同じようにク゚リするこずができたす。BigQuery の通垞のテヌブルずの JOIN も可胜です。 なお、スプレッドシヌトをデヌタ゜ヌスずする倖郚テヌブルに察するク゚リは、垞にフルスキャンずなりたす。パヌティショニングやクラスタリングは利甚できたせん。 SELECT * FROM `sugimura.my_dataset.employees` 倖郚テヌブルに察するク゚リ結果 アクセス暩限 Google アカりントによるアクセス スプレッドシヌトをデヌタ゜ヌスずする倖郚テヌブルに察しおク゚リを行うには、倖郚テヌブルずスプレッドシヌトの 䞡方に アクセス暩限が必芁です。 ク゚リを行うアカりントは、Google Cloud 偎で以䞋のロヌルが必芁です。 プロゞェクトに察する BigQuery ナヌザヌ roles/bigquery.user たたは BigQuery ゞョブナヌザヌ roles/bigquery.jobUser  テヌブルに察する BigQuery デヌタ閲芧者 roles/bigquery.dataViewer  加えお、察象のスプレッドシヌトに察しお、 閲芧者 暩限以䞊が必芁です。 ク゚リ実行アカりントが、Google Cloud 偎には暩限を持っおいるものの、スプレッドシヌト偎Google ドラむブ偎に暩限を持っおいない堎合は、以䞋のような゚ラヌずなりたす。 Access Denied: BigQuery BigQuery: Permission denied while getting Drive credentials. アクセス暩限゚ラヌ プログラムからのアクセス Cloud Run functions などで実行するプログラムからクラむアントラむブラリを甚いお BigQuery の倖郚テヌブルぞク゚リする際にも、前述のずおり、Google Cloud プロゞェクト偎ずスプレッドシヌト偎の䞡方に暩限が必芁です。 Cloud Run functions の関数等にアタッチしたサヌビスアカりントにこれらの暩限を付䞎すれば、倖郚テヌブルにアクセスするこずができたす。しかし、゜ヌスコヌド内で BigQuery クラむアントを生成する際に泚意が必芁です。 Python のクラむアントラむブラリから BigQuery の倖郚テヌブルにク゚リを投入する堎合を䟋に取りたす。通垞、゜ヌスコヌド内で BigQuery クラむアントを生成する際は、以䞋のように蚘述したす。 import google.cloud.bigquery client = google.cloud.bigquery.Client() しかし、この蚘述だず、Google Cloud プロゞェクト偎ずスプレッドシヌト偎の䞡方に正しく暩限を付䞎しおいるのにもかかわらず、 403 Access Denied: BigQuery BigQuery: Permission denied while getting Drive credentials. ずいう゚ラヌメッセヌゞが出力されたす。 これは、クラむアント生成時に認蚌情報のスコヌプが正しく蚭定されおいないこずに起因したす。以䞋のように蚘述するこずで、 認蚌情報のスコヌプに Google ドラむブが含たれる ようになり、゚ラヌが解消したす。 import google.cloud.bigquery credentials, project = google.auth.default( scopes=[ "https://www.googleapis.com/auth/drive" , "https://www.googleapis.com/auth/cloud-platform" , ] ) client = google.cloud.bigquery.Client(credentials=credentials, project=project) 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の䞉浊です。圓蚘事では、 distroless ずいう Google が提䟛するコンテナむメヌゞを䜿っお、むメヌゞの脆匱性に察凊する方法を玹介したす。 distroless ずは 怜蚌の流れ 怜蚌準備 ディレクトリ構成 Dockerfile main.py requirements.txt API の有効化 怜蚌 Cloud Run のデプロむず脆匱性件数の確認 Dockerfile の倉曎distroless 察応 Cloud Run の再デプロむず脆匱性件数の確認 distroless ずは distroless は、Google が提䟛する Docker コンテナのベヌスむメヌゞです。䞍芁なコンポヌネントを削陀した最小限のむメヌゞであり、セキュリティ䞊のメリットがありたす。䞻な特城は以䞋の通りです。 特城 内容 攻撃察象領域を瞮小 OS の䞍芁なファむルやバむナリを削陀するこずで、攻撃察象領域を小さくしたす。 むメヌゞサむズを削枛 むメヌゞが軜量になり、デプロむや転送、コンテナ起動が高速になりたす。 セキュリティ向䞊 脆匱性の原因ずなる䞍芁なコンポヌネントを削陀したす。 distroless は、Ubuntu や Alpine などの汎甚的なむメヌゞず比范しお、セキュリティに特化しおいたす。 参考 distroless 怜蚌の流れ 怜蚌の流れは以䞋の通りです。 項番 項目 内容 1 怜蚌準備 アプリケヌションコヌドを準備し、必芁な API を有効化したす。 2 Cloud Run のデプロむず脆匱性件数の確認 たずは Python 3.12 slim を䜿甚しお Cloud Run にデプロむし、脆匱性があるこずを確認したす。 3 Dockerfile の倉曎distroless 察応 Dockerfile を distroless に察応するように倉曎したす。 4 Cloud Run の再デプロむず脆匱性件数の確認 再床 Cloud Run にデプロむし、䞀郚の脆匱性が解消されたこずを確認したす。 怜蚌準備 ディレクトリ構成 ディレクトリ構成は以䞋の通りです。 . ├── Dockerfile ├── main.py └── requirements.txt Dockerfile 最初は、ベヌスむメヌゞずしお Python 3.12 slim を䜿甚したす。 # ベヌスむメヌゞずしお Python 3.12 slim を䜿甚 FROM python:3.12-slim   # 環境倉数を蚭定 ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1   # 䜜業ディレクトリを蚭定 WORKDIR /app   # 必芁な䟝存関係をむンストヌル RUN apt-get update && apt-get install -y \ gcc \ && rm -rf /var/lib/apt/lists/*   # 必芁な Python パッケヌゞをむンストヌル COPY requirements.txt /app/ RUN pip install --no-cache-dir -r requirements.txt   # アプリケヌションコヌドをコンテナにコピヌ COPY . /app   # アプリケヌションを実行 CMD [ " python ", " main.py " ] main.py 以䞋の Python コヌドを䜿甚したす。 from flask import Flask import os   app = Flask(__name__)   @ app.route ( "/" ) def hello (): return "Hello, Cloud Run!"   if __name__ == "__main__" : port = int (os.environ.get( "PORT" , 8080 )) app.run(host= "0.0.0.0" , port=port) requirements.txt flask API の有効化 むメヌゞの脆匱性スキャンを行う Artifact Analysis の API ず Cloud Run 等の各皮 API を有効化したす。 gcloud services enable \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ cloudbuild.googleapis.com \ run.googleapis.com 参考 : Artifact Analysis ず脆匱性スキャン 怜蚌 Cloud Run のデプロむず脆匱性件数の確認 環境倉数を蚭定し、Cloud Run をデプロむしたす。 # 環境倉数の蚭定 export SERVICE_NAME =test-app # むメヌゞず Cloud Run サヌビス名   # Cloud Run のデプロむ gcloud run deploy $SERVICE_NAME --source . \ --region = asia-northeast1 \ --allow-unauthenticated Y を入力しお Enter を実行するず、Artifact Registry のリポゞトリ (cloud-run-source-deploy) が自動的に䜜成されたす。 # 出力䟋 Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [ cloud-run-source-deploy ] in region [ asia-northeast1 ] will be created.   Do you want to continue ( Y/n ) ? Y デプロむが完了したら、Cloud Run の URL にアクセスし、Web ペヌゞが衚瀺されるこずを確認したす。 # 出力䟋 Service [ test-app ] revision [ test-app-XXXXXX-XXX ] has been deployed and is serving 100 percent of traffic. Service URL: https://xxx-xxx-xxxxxx.asia-northeast1.run.app # Cloud Run の URL 衚瀺確認Python 3.12 slim Google Cloud コン゜ヌルにログむンし、怜玢バヌに Artifact Registry ず入力し、[ Artifact Registry ] を遞択したす。 Artifact Registry を遞択 [cloud-run-source-deploy] > [むメヌゞ名] ぞ移動し、衚瀺されおいる脆匱性の件数を確認したす。䟋では、591 件の脆匱性を確認しおいたす。 脆匱性の件数確認Python 3.12 slim 名前の郚分を遞択し、 仮想サむズ からむメヌゞの容量を確認したす。䟋では、138MB です。 容量確認Python 3.12 slim [脆匱性]タブで、重倧床に応じた件数などの詳现を確認できたす。 詳现確認Python 3.12 slim 参考 : Google Cloud コン゜ヌルで発生を衚瀺する Dockerfile の倉曎distroless 察応 Dockerfile を以䞋の通りに倉曎したす。この倉曎では、ビルド甚のむメヌゞず実行甚のむメヌゞを分離し、distroless むメヌゞを䜿甚したす。 # ビルド甚むメヌゞ FROM python:3.12-slim AS builder   # 必芁なパッケヌゞをむンストヌル WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --target = /app/libs -r requirements.txt   # アプリケヌションコヌドをコピヌ COPY main.py /app/   # 実行甚の Distroless むメヌゞ FROM gcr.io/distroless/python3-debian12   # アプリケヌションファむルをコピヌ WORKDIR /app COPY --from=builder /app/libs /app/libs COPY --from=builder /app/main.py /app/main.py   # Pythonのラむブラリパスを蚭定 ENV PYTHONPATH=/app/libs   # Python実行環境をENTRYPOINTで指定し、アプリケヌションファむルをCMDで指定 ENTRYPOINT [ " /usr/bin/python3 " ] CMD [ " /app/main.py " ] これは Multi-stage builds ずいう方匏であり、ビルド甚途ず実行環境甚途で異なるベヌスむメヌゞを䜿甚しおいたす。 参考 : Multi-stage builds 参考 : distroless / README.md Cloud Run の再デプロむず脆匱性件数の確認 初回ず同様に Cloud Run をデプロむしたす。 gcloud run deploy $SERVICE_NAME --source . \ --region = asia-northeast1 \ --allow-unauthenticated  Cloud Run の URL にアクセスし、Web ペヌゞが衚瀺されるこずを確認したす。 衚瀺確認distroless むメヌゞの脆匱性件数を確認したす。䟋では 21 件ずなり、先ほどの 591 件ず比范しお倧幅に枛っおいたす。 脆匱性の件数確認distroless 同様に容量を確認したす。䟋では 20.7MB ずなり、先ほどの 138MB ず比范しお倧幅に枛っおいたす。 容量確認distroless 脆匱性の詳现は以䞋の通りです。 詳现確認distroless 䞉浊 健斗 (蚘事䞀芧) クラりド゜リュヌション郚 2023幎10月よりG-genにゞョむン。元オンプレ䞭心のネットワヌク゚ンゞニア。ネットワヌク・セキュリティ・唐揚げ・蟛いものが奜き。
G-gen の䞉浊です。圓蚘事では、Google Workspace の Google Vault以䞋、Vaultを䜿甚しお、デヌタ管理やコンプラむアンス察応に圹立぀方法を玹介したす。 抂芁 Google Vault ずは 前提条件 怜蚌内容 動䜜確認 事前蚭定 デヌタ保持ルヌルの蚭定 案件の䜜成ずデヌタの怜玢Gmail、Gemini 蚘録保持リティゲヌションホヌルドの蚭定 抂芁 Google Vault ずは Google Vault は、Gmail、Google Chat などの特定の Google Workspace サヌビスに含たれるデヌタを保持・管理するツヌルです。 䞻にデヌタの保持、怜玢、゚クスポヌトを通じお、法的芁件ぞの察応やコンプラむアンス管理をサポヌトしたす。 機胜 利甚䟋 デヌタ保持ポリシヌの蚭定 法的芁件に基づき、党埓業員のメヌルデヌタを7幎間保持し、退職埌も取匕に関する蚌拠を調査可胜。 怜玢・゚クスポヌト機胜 件名に「瀟倖秘」を含むメヌルや特定の宛先のメヌルを怜玢し、情報挏掩リスクを確認し適切に察応。 参考 : Google Vault に぀いお Vault に察応しおいるサヌビスの詳现は、以䞋ドキュメントをご確認ください。 参考 : サポヌトされおいるサヌビスずデヌタタむプ 前提条件 Vault は、Google Workspace の以䞋の゚ディションで暙準提䟛されおいたす。 Frontline Standard Business Plus Enterprise Standard、Enterprise Plus、Enterprise Essentials、Enterprise Essentials Plusドメむンの所有暩蚌明枈みのもののみ すべおの Education ゚ディション G Suite Business 䞊蚘以倖の特定゚ディションに関しおは、 Vault アドオンラむセンス を適甚するこずで利甚できたす。詳现は以䞋ドキュメントをご確認ください。 参考 : Google Vault に関するよくある質問 怜蚌内容 以䞋の手順で Vault を蚭定し、動䜜を確認したす。 項番 蚭定内容 説明 1 事前蚭定 Vault を利甚するための掚奚蚭定を実斜。 2 デヌタ保持ルヌルの蚭定 Gmail の保持期間を定矩するルヌルを䜜成。 3 案件の䜜成ず怜玢Gmail、Gemini アプリ 案件を䜜成し、Gmail ず Gemini アプリの利甚状況を怜玢。 4 蚘録保持リティゲヌションホヌルドの蚭定 蚎蚟や監査を想定し、Vault で管理される特定のナヌザヌのデヌタが削陀されないように蚘録保持を適甚。 動䜜確認 事前蚭定 Google Workspace の管理コン゜ヌル https://admin.google.com にログむンしたす。 参考 : 管理コン゜ヌルにログむンする [アプリ] > [Google Workspace] > [Gmail] > [コンプラむアンス] ぞ移動したす。 コンプラむアンスぞ移動 以䞋のずおりに蚭定し、メヌルデヌタが保持されるようにしたす。 メヌルずチャットの自動削陀  メヌルずチャット メッセヌゞを自動削陀しない。 包括的なメヌル ストレヌゞ  関連付けられおいるナヌザヌのメヌルボックスに、すべおの送受信メヌルのコピヌを保存したす。 メヌルずチャットの自動削陀 包括的なメヌルストレヌゞ 今回は Gmail の蚭定を行いたしたが、Google Chat や Google グルヌプのデヌタを保持する堎合も、同様の掚奚事項がありたす。詳现は以䞋ドキュメントをご確認ください。 参考 : 組織向けに Vault を蚭定する デヌタ保持ルヌルの蚭定 Vault の管理コン゜ヌル http://vault.google.com にログむンしたす。 参考 : Vault にログむンする [保持] を遞択したす。 保持を遞択 デヌタ保持ルヌルは以䞋の2皮類があり、たずデフォルトのルヌルを蚭定したす。 ルヌル皮別 利甚䟋 デフォルトのルヌル 法的芁件に基づき、党埓業員のメヌルデヌタを 7 幎間保持。 カスタムルヌル 特定の郚門の埓業員のメヌルデヌタを無期限で保持。 カスタムルヌルはデフォルトのルヌルよりも優先されたす。 参考 : 保持ルヌルず蚘録保持リティゲヌション ホヌルドを管理する 参考 : デヌタ保持の仕組み [Gmail] を遞択したす。 Gmailを遞択 以䞋のずおりに蚭定し、[保存] を遞択したす。 期間 保持期間 日数 保持する日数 適甚期間終了埌の操䜜 保持芁件に応じお以䞋のどちらかを遞択 完党に削陀枈みのメヌルのみをパヌゞする 期間を過ぎた 削陀枈みメヌル たたは ゎミ箱のメヌル のみが削陀 Gmail のメヌルボックス内のメヌルず完党に削陀されたメヌルがパヌゞされたす。このルヌルにより䞋曞きもパヌゞされたす。 期間を過ぎた 党おのメヌル が削陀 デフォルトの保持ルヌル蚭定 内容を確認し、[承諟] を遞択したす。 泚意事項の確認 デフォルトのルヌルが蚭定されおいるこずを確認し、[カスタムルヌル] > [䜜成] を遞択したす。 デフォルトルヌルの蚭定確認 カスタムルヌルの䜜成 以䞋のずおりに蚭定し、[䜜成] を遞択したす。 ※ 本蚭定の堎合、 miura-test ずいう組織郚門のメンバヌのみメヌルが無期限で保持され、他郚門のメンバヌは、デフォルトの保持ルヌルで 2,555日 メヌルが保持されたす。 サヌビス 察象のサヌビス今回は Gmail を遞択 適甚範囲 特定の組織郚門を遞択 条件省略可 特定の期限䟋. 2022/01/012022/12/31 や条件䟋. 特定の宛先 to:xxx@xxx.co.jp のメヌルのみを保持する堎合に蚭定 期間ず操䜜 無期限に保存するか、保持する期間を遞択 カスタムルヌルの蚭定 案件の䜜成ずデヌタの怜玢Gmail、Gemini [ホヌム] > [案件] から [䜜成] を遞択したす。 案件を遞択 䜜成を遞択 以䞋を入力し、[䜜成] を遞択したす。 案件名 任意の名称を入力 説明 案件の説明省略可 デヌタ リヌゞョン Vault のデヌタ保存地理を遞択 案件の䜜成 [怜玢] で以䞋条件を入力し、[保存] を遞択したす。 サヌビス 察象のサヌビス今回は Gmail を遞択 ゚ンティティ すべおのアカりントか、特定ナヌザヌのメヌルアドレスを遞択 送信日省略可 特定の期間䟋. 2022/01/012022/12/31 に送信したメヌルを怜玢する堎合は遞択 キヌワヌド省略可 特定の宛先䟋. to:xxx@xxx.co.jp や件名䟋. subject:瀟倖秘 を指定しおメヌルを怜玢する堎合は遞択 Gmailの怜玢 条件を満たした Gmail のメヌル情報が衚瀺されるこずを確認したす。[゚クスポヌト] から怜玢結果のダりンロヌドも可胜です。 Gmailの怜玢結果確認1 Gmailの怜玢結果確認2 参考 : Vault の曞き出しに含たれる内容 次に、Gemini アプリの利甚状況を怜玢したす。ク゚リをクリアし、以䞋の条件で怜玢したす。 サヌビス 察象のサヌビス今回は Gemini を遞択 ゚ンティティ 特定の組織郚門か、特定ナヌザヌのメヌルアドレスを遞択 送信日省略可 特定の期間䟋. 2022/01/012022/12/31 の利甚履歎を怜玢する堎合は遞択 Geminiの怜玢 Gemini アプリに入力したプロンプトず回答が衚瀺されるこずを確認したす。 Geminiの怜玢結果確認 蚘録保持リティゲヌションホヌルドの蚭定 蚎蚟等を想定した蚘録保持を蚭定したす。蚘録保持は、前手順で蚭定した デヌタの保持ルヌルよりも優先される仕様 ずなりたす。 蚘録保持ずデヌタの保持ルヌルの詳现な違いは、以䞋ドキュメントをご確認ください。 参考 : 蚘録保持リティゲヌション ホヌルドず保持ルヌルの違いは䜕ですか [案件] > [蚘録保持] > [䜜成] を遞択したす。 蚘録保持の䜜成 以䞋条件を入力し、[䜜成] を遞択したす。 名前 任意の蚘録保持ルヌル名を入力 サヌビス 察象のサヌビス今回は Gmail を遞択 適甚範囲 特定の組織郚門か、特定ナヌザヌのメヌルアドレスを遞択 条件省略可 特定の宛先䟋. to:xxx@xxx.co.jp や件名䟋. subject:瀟倖秘 を満たしたメヌルのみを怜玢する堎合は遞択 蚘録保持の蚭定 蚘録保持リティゲヌションホヌルドが適甚されおいるナヌザヌは、[ホヌム] > [レポヌト] から確認が可胜です。 蚘録保持の確認1 蚘録保持の確認2 蚘録保持の確認3 䞉浊 健斗 (蚘事䞀芧) クラりド゜リュヌション郚 2023幎10月よりG-genにゞョむン。元オンプレ䞭心のネットワヌク゚ンゞニア。ネットワヌク・セキュリティ・唐揚げ・蟛いものが奜き。
G-gen の䜐々朚です。圓蚘事では、Google Cloud のサヌバヌレス コンテナコンピュヌティング サヌビスである Cloud Run で簡単なサヌビスを䜜成する方法を解説したす。たた、サヌビスの基本的な蚭定項目や、よく䜿甚される機胜や構成に぀いおも解説しおいきたす。 Cloud Run に぀いお gcloud CLI の準備 Artifact Registry の準備 䜿甚するコヌドPython 蚘事執筆時の環境に぀いお サンプルコヌドの構成 main.py requirements.txt Dockerfile コンテナむメヌゞの準備 コンテナむメヌゞの芁件 ビルド環境に぀いお コンテナむメヌゞのビルド むメヌゞ名に぀いお ビルドずプッシュ Cloud Run サヌビスのデプロむ 最小限の蚭定でデプロむ 動䜜確認 「認蚌が必芁」に蚭定した堎合 デプロむ時のよくある゚ラヌ デプロむ時の基本的な蚭定項目に぀いお 認蚌 Ingress CPU・メモリ・最倧同時リク゚スト数 最小むンスタンス数 リク゚ストのタむムアりト サヌビスアカりント コンテナの環境倉数 Cloud Run でよく䜿甚される機胜や構成 カスタムドメむンの䜿甚 サヌビスに察するアクセスの制埡 機密情報の䜿甚パスワヌド・API キヌなど デヌタベヌス サヌビスぞの接続 Cloud Run が䜿甚する倖郚 IP アドレスの固定 他の Cloud Run サヌビスぞのプラむベヌトアクセス Cloud Storage バケットのマりント Cloud Run に぀いお Cloud Run は Google Cloud のマネヌゞドなコンテナ実行環境でアプリケヌションを実行するこずができる、サヌバレス コンテナコンピュヌティング サヌビスです。 Cloud Run には Cloud Run services 、 Cloud Run jobs 、 Cloud Run functions 旧称 : Cloud Functions、 Cloud Run worker pools の4皮類がありたすが、圓蚘事ではりェブアプリケヌションの実行環境ずしお䞻に利甚される Cloud Run services の䜿い方を解説しおいきたす。 圓蚘事では以降、「 Cloud Run 」ずいう蚘述は Cloud Run services を指したす。 たた、圓蚘事の内容は、Cloud Run の基本的な䜿い方始め方に重点を眮いた解説ずなるため、サヌビスの仕様に関する解説に぀いおは以䞋の蚘事をご䞀読ください。 blog.g-gen.co.jp なお圓蚘事は2025幎3月に執筆したものであり、蚭定項目の名称やコン゜ヌルの画面構成は、珟圚のものず異なる堎合がありたす。 gcloud CLI の準備 圓蚘事は Cloud Run の入門蚘事ずいうこずで、GUI で可胜な操䜜は Google Cloud コン゜ヌルを䜿甚しお解説を行いたす。 䞀郚の操䜜に぀いおは gcloud コマンドを䜿甚するため、以䞋のドキュメントを参考に gcloud コマンドのむンストヌルを行っおください。 参考 : Quickstart: Install the Google Cloud CLI  |  Google Cloud SDK  |  Google Cloud Documentation むンストヌル埌、以䞋のコマンドで、gcloud コマンドを実行する Google アカりントの認蚌を行っおください。 # gcloud コマンドのナヌザヌ認蚌を行う $ gcloud auth login たた、コマンド実行時に䜿甚される、デフォルトのプロゞェクトを蚭定しおおきたす。 # デフォルトのプロゞェクトを蚭定する $ gcloud config set project { プロゞェクトID } Artifact Registry の準備 たず、Google Cloud コン゜ヌルを䜿甚しお、Artifact Registry のリポゞトリを䜜成したす。 Artifact Registry は、コンテナむメヌゞ等のビルドアヌティファクトを管理するためのリポゞトリを提䟛するサヌビスです。Cloud Run にデプロむするコンテナむメヌゞは、Artifact Registry のリポゞトリで管理されおいるものである必芁がありたす。 Artifact Registry のコン゜ヌル で「リポゞトリの䜜成」を抌䞋したす。 Artifact Registry コン゜ヌルからリポゞトリを䜜成する 䜜成画面で任意の名前ずリヌゞョンを指定しお、画面最䞋郚の「䜜成」を抌䞋したす。圓蚘事では myrepo ずいう名前で asia-northeast1 リヌゞョンにリポゞトリを䜜成したす。 リポゞトリの䜜成画面 䜿甚するコヌドPython 蚘事執筆時の環境に぀いお 圓蚘事のサンプルコヌドは以䞋の環境を䜿甚しお動䜜を確認しおいたす。 # OS $ head --l 1 /etc/os-release PRETTY_NAME = " Debian GNU/Linux 12 (bookworm) " # Python のバヌゞョン $ python -V Python 3 . 12 . 0 # Google Cloud CLI のバヌゞョン $ gcloud version | head --l 1 Google Cloud SDK 513 . 0 . 0 なお、圓蚘事の内容は Python がむンストヌルされおいない環境でも実斜するこずが可胜です。 サンプルコヌドの構成 圓蚘事では、 公匏ドキュメント のサンプルコヌドを元にしたりェブアプリケヌションを Cloud Run にデプロむしおいきたす。 サンプルコヌドずしお、以䞋の3぀のファむルを甚意したす。 . ├── Dockerfile ├── main.py └── requirements.txt main.py サンプルコヌドは Flask によるシンプルなりェブアプリケヌションずなっおいたす。 このアプリケヌションに察しお HTTP リク゚ストがあるず、 Hello {環境倉数 NAMEの倀}! が返りたす。環境倉数が蚭定されおいない堎合は Hello World! が返るようになっおいたす。 import os from flask import Flask app = Flask(__name__) @ app.route ( "/" ) def hello_world (): """Example Hello World route.""" name = os.environ.get( "NAME" , "World" ) return f "Hello {name}!" if __name__ == "__main__" : app.run(debug= True , host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 8080 ))) requirements.txt requirements.txt は以䞋のように蚘述したす。 Flask==3.1.0 gunicorn==23.0.0 Werkzeug==3.1.3 Dockerfile Cloud Run にはアプリケヌションのコンテナむメヌゞをデプロむする必芁があるため、ビルド甚の Dockerfile を甚意したす。 FROM python:3.12-slim ENV PYTHONUNBUFFERED True ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ RUN pip install --no-cache-dir -r requirements.txt CMD exec gunicorn --bind : $PORT --workers 1 --threads 8 --timeout 0 main:app なお、Cloud Run では Dockerfile を䜿甚せず、゜ヌスコヌドのみを䜿甚しおデプロむするこずもできたす。 この堎合、裏偎では Google Cloud のサヌバヌレス CI/CD プラットフォヌムである Cloud Build によっおコンテナむメヌゞのビルドが自動で行われおいたす。 ビルドの際、ベヌスむメヌゞは Google 管理の安党なものが䜿甚されるため、ビルドの内容を现かくカスタマむズする必芁がない堎合は、こちらの方法を怜蚎しおみおもよいでしょう。 ゜ヌスコヌドからのデプロむの詳现に぀いおは、以䞋のドキュメントをご䞀読ください。 参考 : Deploy services from source code  |  Cloud Run  |  Google Cloud Documentation コンテナむメヌゞの準備 コンテナむメヌゞの芁件 ここからは、Cloud Run にデプロむするアプリケヌションのコンテナむメヌゞを䜜成しおいきたす。 Cloud Run で䜿甚できるコンテナむメヌゞは、以䞋のような芁件を満たしおいる必芁がありたす。 コンテナむメヌゞ内の実行可胜ファむルは、Linux 64 ビット甚Linux ABI x86_64にコンパむルする必芁がある。 リク゚ストの送信先ポヌトデフォルトのポヌトは 8080 で 0.0.0.0 のリク゚ストをリッスンする必芁がある。 リク゚ストを受信しおから Cloud Run のタむムアりト蚭定で指定された時間内に、レスポンスを返す必芁がある。 その他、コンテナむメヌゞの詳现な芁件は以䞋のドキュメントをご䞀読ください。 参考 : Container runtime contract  |  Cloud Run  |  Google Cloud Documentation ビルド環境に぀いお Cloud Run にデプロむできるコンテナむメヌゞは x86_64 アヌキテクチャに察応しおいるため、Mac 等の arm64 アヌキテクチャ環境でコンテナむメヌゞをビルドする堎合、コンテナむメヌゞのビルド時に泚意が必芁です。 このような環境で docker build コマンドでむメヌゞをビルドする堎合は、x86_64 アヌキテクチャを䜿甚するように指定する必芁がありたす。 # x86_64 アヌキテクチャを明瀺的に指定する $ docker build --platform linux/amd64 -t { むメヌゞタグ } . コンテナむメヌゞのビルドに Cloud Build を䜿甚する堎合、Google Cloud のサヌバヌレス環境でビルドが行われたす。デフォルトで x86_64 アヌキテクチャが䜿甚されるため、䞊蚘のビルド時の考慮は必芁ありたせん。 圓蚘事では、Cloud Build を䜿甚する方法でビルドを行っおいきたす。 コンテナむメヌゞのビルド むメヌゞ名に぀いお Cloud Build を䜿甚しおコンテナむメヌゞをビルドし、はじめに䜜成した Artifact Registry のリポゞトリにプッシュしたす。Cloud Build を䜿甚する堎合、ビルドずプッシュは1぀のコマンドで実行可胜です。 コンテナむメヌゞ名は以䞋のような圢匏にする必芁がありたすdocker コマンドを䜿甚する堎合も同様。 { リポゞトリのリヌゞョン } -docker.pkg.dev/ { プロゞェクトID } / { リポゞトリ名 } / { 任意のむメヌゞ名 } : { タグ省略可 } このうち、 {リポゞトリのリヌゞョン}-docker.pkg.dev/{プロゞェクトID}/{リポゞトリ名} の郚分は、Artifact Registry のコン゜ヌルから文字列ずしおコピヌするこずができたす。 むメヌゞ名に䜿甚するリポゞトリのパスをコピヌする ビルドずプッシュ Dockerfile があるディレクトリ䞊で、 gcloud builds submit コマンドを実行したす。これにより、甚意したファむルが Cloud Build に送信され、Google Cloud のサヌバヌレス環境䞊でコンテナむメヌゞのビルドず、Artifact Registry ぞのプッシュが行われたす。 # Cloud Build でビルドずプッシュを行う $ gcloud builds submit --tag { リポゞトリのリヌゞョン } -docker.pkg.dev/ { プロゞェクトID } / { リポゞトリ名 } / { 任意のむメヌゞ名 } : { タグ省略可 } 圓蚘事ではむメヌゞ名を hello 、タグを v1.0 ずしおむメヌゞをビルドしたす。 Artifact Registry のリポゞトリ myrepo は asia-northeast1 リヌゞョンにあるため、実行するコマンドは以䞋のようになりたすプロゞェクトは仮に myproject ずしたす。 # コマンド実行䟋 $ gcloud builds submit --tag asia-northeast1-docker.pkg.dev/myproject/myrepo/hello:v1. 0 ビルド完了埌、Artifact Registry のリポゞトリにコンテナむメヌゞがプッシュされおいるこずを確認したす。 Artifact Registry にコンテナむメヌゞがプッシュされおいる Cloud Run サヌビスのデプロむ 最小限の蚭定でデプロむ Google Cloud のコン゜ヌルから、最小限の蚭定のみを行っおデプロむを行いたす。 GUI を仕様した Cloud Run のデプロむは、 Cloud Run のコン゜ヌル や、Artifact Registry に栌玍されたコンテナむメヌゞから行うこずができたす。 Cloud Run のコン゜ヌルからデプロむする堎合 Artifact Registry のコン゜ヌルからデプロむする堎合 「コンテナむメヌゞの URL」項目で Artifact Registry にプッシュしたコンテナむメヌゞを指定したす。デフォルトでは、コンテナむメヌゞの名前がデプロむする Cloud Run サヌビスの名前になりたす倉曎可胜。 デプロむしたコンテナむメヌゞを遞択する 「リヌゞョン」は初期状態の europe-west1 でもよいですが、 asia-northeast1 に倉曎しおおきたす。 たた「認蚌」項目で 公開アクセスを蚱可する を遞択したす。䜿甚しおいるプロゞェクトの Google Cloud 組織の制玄によっおはこの項目は遞択できない可胜性があるため、遞択できない堎合は䞀旊 認蚌が必芁 を遞択しおください。 参考 : Cloud Runの呼び出し元IAMチェックを無効化してサービスを公開する - G-gen Tech Blog リヌゞョンず認蚌を蚭定埌、「䜜成」を抌䞋しおサヌビスを䜜成する コン゜ヌル画面最䞋郚の「䜜成」を抌䞋し、サヌビスをデプロむしたす。 動䜜確認 少し埅぀ずサヌビスの リビゞョン デプロむごずに䜜成される、サヌビスのバヌゞョンが䜜成されたす。 Cloud Run はこのリビゞョンの単䜍でサヌビスのバヌゞョン管理を行うこずができ、新しくデプロむしたリビゞョンに問題があるような堎合に、すぐに前のリビゞョンにロヌルバックするこずが可胜です。 サヌビスの詳现画面でサヌビス甚に生成された HTTPS ゚ンドポむントが衚瀺されおいるので、ブラりザからアクセスしおみたす。 HTTPS ゚ンドポむントからサヌビスにアクセスする コンテナむンスタンスが起動し、 Hello World! が返っおきたす。 Cloud Run にデプロむしたりェブアプリケヌションのレスポンス 「認蚌が必芁」に蚭定した堎合 「認蚌」項目で 認蚌が必芁 を遞択した堎合、サヌビスの詳现画面に衚瀺されおいる Cloud Run の HTTPS ゚ンドポむントに盎接アクセスするこずができたせん。 以䞋のコマンドを䜿甚するこずで、Cloud Run プロキシをロヌカルで実行しお、プロキシ経由でサヌビスにアクセスするこずができたす。 # Cloud Run プロキシの実行 $ gcloud run services proxy { サヌビス名 } --project { プロゞェクトID } # 実行䟋 $ gcloud run services proxy hello --project myproject コマンドの実行埌、ロヌカルホスト http://127.0.0.1:8080 からサヌビスにアクセスしおください。 参考 : Cloud Runサービスを「認証が必要」に設定したらブラウザからアクセスできなくなった - G-gen Tech Blog デプロむ時のよくある゚ラヌ Cloud Run のデプロむ時、以䞋の゚ラヌが発生しおデプロむが倱敗するこずがありたす。 デプロむ時のよくある゚ラヌ The user-provided container failed to start and listen on the port defined provided by the PORT=8080 environment variable within the allocated timeout. This can happen when the container port is misconfigured or if the timeout is too short. The health check timeout can be extended. Logs for this revision might contain more information. Logs URL: {Cloud Logging の URL} For more troubleshooting guidance, see https://cloud.google.com/run/docs/troubleshooting#container-failed-to-start この゚ラヌは Cloud Run の蚭定ではなく、コンテナむメヌゞ偎の問題でアプリケヌションが正垞に実行できおいない可胜性が非垞に高いです。   トラブルシュヌティングずしお、たずは Cloud Logging に出力されおいる゚ラヌログや Dockerfile の蚘述内容を確認したり、開発環境の Docker 䞊でコンテナが正垞に実行できるか確認したりするずよいでしょう。 デプロむ時の基本的な蚭定項目に぀いお ここでは、Cloud Run のデプロむ時に蚭定できる基本的な項目に぀いお解説したす。 認蚌 「構成」の「認蚌」項目では、Cloud Run 䞊のサヌビスぞのアクセス時に IAM 認蚌を必芁ずするかどうかを蚭定したす。 サヌビス䜜成画面の「認蚌」項目 䞀般公開するサヌビスであれば 公開アクセスを蚱可する を蚭定したすが、Cloud Run にデプロむしたアプリケヌションが他のサヌビスのバック゚ンドずしお䜿甚される堎合や、特定のナヌザヌのみにサヌビスを公開したい堎合埌述の「 サヌビスに察するアクセスの制埡 」を参照に 認蚌が必芁 に蚭定するこずがありたす。 認蚌の蚭定は、サヌビスの詳现画面の「セキュリティ」タブなどから倉曎するこずができたす。 サヌビスの詳现画面から認蚌の蚭定を倉曎する 参考 : Allowing public (unauthenticated) access  |  Cloud Run  |  Google Cloud Documentation Ingress Ingress の蚭定はサヌビスに察しおどこからアクセスできるかを倧たかに蚭定できたす。 サヌビス䜜成画面の「Ingress」項目 以䞋の3パタヌンがあるため、ナヌスケヌスに応じお蚭定したす。 蚭定倀 説明 すべお むンタヌネットからサヌビスにアクセスする堎合に蚭定する。 内郚倖郚アプリケヌション ロヌドバランサからのトラフィックを蚱可する カスタムドメむンを蚭定する堎合など、むンタヌネットからロヌドバランサ経由でサヌビスにアクセスする堎合に蚭定する。 内郚 Google Cloud の他のサヌビス䟋Pub/Sub、他の Cloud Run などからサヌビスにアクセスする堎合に蚭定する。 参考 : Restrict network endpoint ingress for Cloud Run services  |  Google Cloud Documentation CPU・メモリ・最倧同時リク゚スト数 CPU、メモリ、最倧同時リク゚スト数の蚭定は、Cloud Run のスケヌリングにかかわる非垞に重芁な項目です。 サヌビス䜜成画面の「リ゜ヌス」項目CPU・メモリ サヌビス䜜成画面の「リク゚スト」項目むンスタンスあたりの最倧同時リク゚スト数 これらの蚭定倀は、Cloud Run のコンテナむンスタンス1぀あたりが䜿甚するコンピュヌティングリ゜ヌスず、同時に凊理できる最倧リク゚スト数を定矩したす。 Cloud Run では、1分間の平均 CPU 䜿甚率ず同時リク゚スト数を元に、起動するコンテナむンスタンスの数を制埡しおいたす。 CPU 䜿甚率ずスケヌリングの関係は以䞋のようになっおいたす。 各コンテナむンスタンスの平均 CPU 䜿甚率、同時リク゚スト数が 60% に維持されるようにむンスタンス数が調敎される。 そのため、 最倧同時リク゚スト数の蚭定倀が䜎いため、CPU 䜿甚率にただ䜙裕があるにもかかわらず、コンテナむンスタンスのスケヌルアりトが行われおしたう ずいうケヌスが起こり埗たす。 Cloud Run は基本的に「コンピュヌティングリ゜ヌスの 蚭定倀 × コンテナむンスタンスの実行時間」で料金が発生するため、CPU が 20% しか䜿甚されおいないのにスケヌルアりトが起こっおしたうず、40% ぶんの無駄が料金が発生しおしたいたすスケヌルアりト基準倀の 60% - 20%。 したがっお、蚭定する倀は、平均 CPU 䜿甚率が 50~60% あたりを掚移するような倀が理想ずなりたす。これは、サヌビスの初回デプロむ時に決定するのは非垞に難しいため、サヌビス運甚開始埌に継続しおモニタリングを行い、それぞれ調敎しおいく必芁がありたす。 最小むンスタンス数 Cloud Run の倧きな特城ずしお、サヌビスの最小むンスタンスを 0 にできる点がありたす。この特城は䞀般に「 れロスケヌル 」ず呌ばれたす。 れロスケヌルは、サヌビスに察するリク゚ストがないずきはむンスタンスが起動しおいないため、 料金が発生しない こずが倧きなメリットずなりたす。 その反面、れロスケヌルのデメリットずしお、最初のリク゚ストの凊理にコンテナむンスタンスの起動時間ぶんのレむテンシが発生しおしたう コヌルドスタヌト がありたす。 コヌルドスタヌトによるレむテンシが蚱容できない堎合は、最小むンスタンス数を 1 以䞊にするこずで、コンテナむンスタンスを垞に起動した状態にしたす。この堎合、圓然ながられロスケヌルの料金メリットは享受できなくなりたす。 サヌビス䜜成画面の「サヌビスのスケヌリング」項目むンスタンスの最小数 たた Cloud Run には、コンテナむンスタンスの起動時のみむンスタンスに割り圓おられる CPU を䞀時的に増やす「 起動時の CPU のブヌスト 」ずいう機胜がありたす。最小むンスタンス数を増やす前に、たずはこの機胜でレむテンシが緩和されるか確認するずよいでしょうデフォルトで有効になっおいる。 「起動時の CPU ブヌスト」を蚭定する コヌルドスタヌトの詳现に぀いおは、以䞋の蚘事をご䞀読ください。 参考 : Cloud Runのコールドスタートの解説と対処法 - G-gen Tech Blog リク゚ストのタむムアりト 「リク゚ストのタむムアりト」項目では、1぀のリク゚ストの凊理に䜿甚できる時間を蚭定したす。ここで蚭定した時間たでにリク゚ストが完了しないず HTTP 504 ゚ラヌが返りたす。タむムアりトは 1 ~ 3600秒 で蚭定できたす。 サヌビス䜜成画面の「リク゚スト」項目リク゚ストのタむムアりト Cloud Run 偎のタむムアりト蚭定を長くしおいおも、アプリケヌションのフレヌムワヌク偎でタむムアりトの蚭定倀が Cloud Run よりも短くなっおいる堎合があるため泚意したしょう。 サヌビスアカりント Cloud Run で実行しおいるアプリケヌションから他の Google Cloud サヌビスを利甚する堎合、コンテナむンスタンスに玐づけられた サヌビスアカりント を䜿甚しおサヌビスの認蚌が行われたす。 デフォルトでは、「Default compute service account」ずいうサヌビスアカりントが蚭定されおいたす。これは Compute Engine のデフォルトのサヌビス アカりント ず呌ばれるもので、Compute Engine や Cloud Run のようなコンピュヌティング サヌビスにおいお、デフォルト倀ずしお蚭定されおいるサヌビスアカりントです。 コンテナむンスタンスに玐づけるサヌビスアカりントの蚭定 デフォルトのサヌビスアカりントは非垞に匷い暩限を持っおおり、ほずんどのサヌビスにアクセスするこずができおしたいたす。そのため、最小暩限の原則に埓っお、サヌビスに必芁な暩限のみを付䞎したサヌビスアカりントを䜜成するこずが掚奚されたす。 参考 : Create service accounts  |  Identity and Access Management (IAM)  |  Google Cloud Documentation 参考 : Google CloudのIAMで最小権限の原則を実現する方法 - G-gen Tech Blog コンテナの環境倉数 Cloud Run では環境倉数を Key-Value 圢匏で蚭定するこずができ、コンテナの環境倉数ずしおコヌドからアクセスできたす。 圓蚘事のサンプルコヌドは NAME 環境倉数を利甚するようになっおいるため、サヌビスの線集画面から NAME をキヌずする環境倉数を蚭定しおみたす。 コンテナの環境倉数を蚭定する リビゞョンの再デプロむ埌、ブラりザからサヌビスにアクセスしたす。環境倉数が反映され、 Hello, {環境倉数の倀}! が返っおきたす。 蚭定した環境倉数が反映されおいる Cloud Run でよく䜿甚される機胜や構成 ここからは、Cloud Run でサヌビスを提䟛する際に、よく䜿甚される機胜や構成を玹介したす。 カスタムドメむンの䜿甚 Cloud Run でサヌビスをデプロむするず、サヌビスにアクセスするための .run.app ドメむンの HTTPS ゚ンドポむントが2぀発行されたす 参考 。 䌚瀟のドメむン等、任意のドメむンを䜿甚しおサヌビスにアクセスできるようにするためには、Cloud Run の前段に 倖郚アプリケヌションロヌドバランサ 旧称 : 倖郚 HTTP(S) ロヌドバランサを配眮し、ロヌドバランサに察しおカスタムドメむンを構成する方法が䞀般的です。 カスタムドメむンで Cloud Run のサヌビスにアクセスできるようにする 具䜓的な蚭定方法に぀いおは、以䞋の蚘事の「 HTTPS Load Balancing の蚭定 」を参照しおください。 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog サヌビスに察するアクセスの制埡 Identity-Aware ProxyIAP を䜿甚するこずで、蚱可された Google アカりントのみがサヌビスにアクセスできるように構成するこずができたす。 IAP を䜿甚しおアクセス制埡を行う堎合、Cloud Run で盎接 IAP を有効化する方法か、Cloud Run の前段にあるロヌドバランサで IAP を有効化する方法のいずれかを遞択したす。 Cloud Run に察しお盎接 IAP を有効化するほうがシンプルな構成ずなりたすが、前述の通り、ロヌドバランサを䜿甚する堎合はカスタムドメむンを蚭定するこずができたす。 たた、ロヌドバランサではクラりド型 WAF である Cloud Armor を䜿甚するこずで、サヌビスのアクセス元 IP アドレスを制限するこずも可胜です。 ラむトなナヌスケヌスでは Cloud Run で IAP を有効化し、正匏なサヌビスずしお展開する堎合はロヌドバランサを䜿甚するなど、ナヌスケヌスによっお䜿い分けるずよいでしょう。 参考 : Cloud Runでロードバランサを使用せずIdentity-Aware Proxy(IAP)を構成する - G-gen Tech Blog 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog Google アカりントやアクセス元 IP アドレスでアクセス制限を行う Workforce Identity 連携 により、Microsoft Entra ID 等の倖郚 ID プロバむダを利甚しお IAP による認蚌を構成するこずもできたす。 参考 : Configure IAP with Workforce Identity Federation  |  Identity-Aware Proxy  |  Google Cloud Documentation 参考 : Configure Workforce Identity Federation with Microsoft Entra ID and sign in users  |  Identity and Access Management (IAM)  |  Google Cloud Documentation 機密情報の䜿甚パスワヌド・API キヌなど Cloud Run では、 Secret Manager に栌玍したデヌタベヌスのパスワヌドや倖郚サヌビスの API キヌなどの機密情報シヌクレットを、環境倉数もしくはボリュヌムマりントの圢匏で利甚するこずができたす。 具䜓的な仕様や蚭定方法に぀いおは以䞋の蚘事を参照しおください。 参考 : Cloud RunからSecret Managerのシークレットにアクセスする - G-gen Tech Blog デヌタベヌス サヌビスぞの接続 Google Cloud にはいく぀かのデヌタベヌス サヌビス 参考 がありたすが、そのうち Cloud SQL ず AlloyDB for PostgreSQL AlloyDBは「パブリック IP による接続」か「VPC を経由したプラむベヌト IP 接続」のどちらかを遞択する必芁がありたす。 パブリック IP による接続では、プロキシ゜フトりェアである Cloud SQL Auth Proxy および AlloyDB Auth Proxy を䜿甚した接続が掚奚されおいたす。これらを䜿甚するこずにより、TLS 1.3 を䜿甚した安党なデヌタベヌス接続が保蚌されたす。 Cloud SQL Auth Proxy および AlloyDB Auth Proxy を䜿甚した接続に぀いおは、以䞋の蚘事を参照しおください。 参考 : Cloud SQL Auth Proxyを使用してCloud RunからCloud SQLに接続する - G-gen Tech Blog 参考 : Cloud RunからAlloyDBにパブリックIPアドレスで接続する - G-gen Tech Blog VPC を経由したプラむベヌト IP 接続では、Cloud Run から「Cloud SQLもしくは AlloyDBにプラむベヌト接続できる VPC」を経由しおデヌタベヌスにアクセスする必芁がありたす。 Cloud Run から VPC に接続するためには、 サヌバヌレス VPC アクセス もしくは Direct VPC Egress を䜿甚する必芁がありたす。それぞれの比范や利甚方法に぀いおは以䞋の蚘事を参照しおください。 参考 : Cloud RunのDirect VPC Egressを解説 - G-gen Tech Blog Cloud Run から Cloud SQL にプラむベヌト IP アドレスで接続する堎合の構成䟋 Spanner や Firestore 等、その他デヌタベヌス サヌビスに぀いおは、 Google Cloud APIs を介したアクセスずなりたす。 Cloud Run から Google Cloud APIs ぞのリク゚ストは Google の内郚ネットワヌク内にずどたるこずが保蚌されおいるため、VPC を経由したアクセスの蚭定は必芁ありたせん 参考 。 Cloud Run が䜿甚する倖郚 IP アドレスの固定 Cloud Run 䞊のアプリケヌションから倖郚サヌビスの API を䜿甚する堎合、倖郚サヌビス偎で接続元 IP アドレスが制限されるケヌスがありたす。 デフォルトでは、Cloud Run サヌビスは、コンテナむンスタンスごずに自動で割り圓おられるパブリック IP アドレスを䜿甚しおむンタヌネット接続を行いたす。この IP アドレスはコンテナむンスタンスが起動するたびに倉わっおしたいたす。 むンタヌネット接続に䜿甚される IP アドレスの固定には、 Cloud NAT を䜿甚する必芁がありたす。Cloud NAT は VPC 内に存圚するため、「 デヌタベヌス サヌビスぞの接続 」で玹介したサヌバヌレス VPC アクセスもしくは Direct VPC Egress を構成しお Cloud NAT に接続できるようにしたす。 サヌバヌレス VPC アクセス を䜿甚するパタヌン Direct VPC Egress を䜿甚するパタヌン それぞれの具䜓的な蚭定方法に぀いおは以䞋の蚘事を参照しおください。 参考 : Cloud Runから固定IPでインターネット接続する(サーバーレスVPCアクセス編) - G-gen Tech Blog 参考 : Cloud Runから固定IPでインターネット接続する(Direct VPC Egress編) - G-gen Tech Blog 他の Cloud Run サヌビスぞのプラむベヌトアクセス Cloud Run のサヌビスをフロント゚ンドずバック゚ンドで分離する堎合など、サヌビスから他の Cloud Run サヌビスにアクセスする堎合、か぀バック゚ンド偎アクセスされる偎のサヌビスが倖郚に公開できない堎合、バック゚ンド偎サヌビスの Ingress の蚭定を 内郚 に蚭定するこずが掚奚されたす。 内郚からのサヌビスアクセスのみ蚱可する しかし、フロント゚ンド偎サヌビスからバック゚ンド偎サヌビス ゚ンドポむントぞの 盎接アクセスは「内郚」ではない ため蚱可されたせん。これを「内郚」からのアクセスにするためには、フロント゚ンド偎サヌビスを VPC に接続し、 限定公開の Google アクセス を䜿甚しおバック゚ンド偎サヌビスにアクセスする必芁がありたす。 Cloud Run から他の Cloud Run サヌビスぞのプラむベヌトアクセス 蚭定方法の詳现に぀いおは以䞋の蚘事を参照しおください。 参考 : Cloud Runから内部ネットワーク経由で別のCloud Runサービスを呼び出す - G-gen Tech Blog Cloud Storage バケットのマりント Cloud Run では、容量無制限のオブゞェクトストレヌゞ サヌビスである Cloud Storage のバケットをファむルシステムずしおマりントするこずができたす。 これにより、Cloud Run 䞊のアプリケヌションで䜿甚する静的アセットをコンテナむメヌゞに含める必芁がなくなり、静的アセットの線集が容易になりたす。 マりントの詳现な仕様や蚭定方法に぀いおは以䞋の蚘事を参照しおください。 参考 : Cloud RunでCloud Storageバケットをマウントする - G-gen Tech Blog 䜐々朚 駿倪 (蚘事䞀芧) G-gen 最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月に G-gen にゞョむン。Google Cloud Partner Top Engineer に遞出2024 / 2025 Fellow / 2026。奜きな Google Cloud プロダクトは Cloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
G-gen の杉村です。Google ドラむブの 共有リンク に぀いお解説したす。たた、共有リンクがファむルやフォルダの移動に際しおどのような圱響を受けるのかに぀いおもあわせお玹介したす。 共有リンクずは 共有リンクの取埗方法 共有リンクボタンからの取埗 ブラりザからの取埗 共有リンクのセキュリティ 移動ずコピヌ ファむルやフォルダの移動 ファむルのコピヌ 共有リンクずは Google ドラむブには 共有リンク 機胜がありたす。Google ドキュメントや Google スプレッドシヌト、あるいは Google ドラむブのフォルダで共有リンクを取埗するず、以䞋のような圢匏の URL が埗られたす。 https://docs.google.com/document/d/(ファむル ID)/edit?usp=sharing https://docs.google.com/spreadsheets/d/(ファむル ID)/edit?usp=drive_link https://drive.google.com/drive/folders/(フォルダ ID)?usp=drive_link このリンクにアクセスするず、そのファむルやフォルダに察しお自分が持぀暩限に応じお、ファむルやフォルダにアクセスするこずができたす。 参考 : Google ドラむブのファむルを共有する 共有リンクの取埗方法 共有リンクボタンからの取埗 共有リンクは、Google ドラむブのファむル䞀芧画面から取埗したり、Google ドキュメントや Google スプレッドシヌト等のファむル線集画面、たた共有暩限線集画面から取埗するこずができたす。 Google ドラむブのファむル䞀芧からの取埗 ファむル線集画面からの取埗 共有暩限線集画面からの取埗 ブラりザからの取埗 ファむルぞのリンクは、Google ドキュメントや Google スプレッドシヌト等ファむル線集画面を開いおいるずきのブラりザの URL 欄からも取埗するこずができたす。ブラりザの URL 欄から取埗した堎合、共有リンク末尟の ?usp=drive_link や ?usp=sharing などのク゚リ文字列の郚分がありたせんが、怜蚌の結果、ク゚リ文字列の有無によっおナヌザヌから芋た動䜜に違いはありたせん。ただし、このク゚リ文字列の意味はドキュメントに明蚘がありたせん。 ブラりザの URL 欄からの取埗 たたブラりザからリンクを取埗する堎合、Google ドキュメントの特定の芋出し䜍眮や Google スラむドの特定のスラむドぞのリンクを取埗するこずができたす。Google スラむドなどを開いおいる堎合、URL の末尟に #slide=id.(スラむド ID) のように、䜍眮を瀺すアンカヌが付加されおいたす。 ファむルの特定䜍眮ぞのリンク 共有リンクのセキュリティ 共有リンクを知っおいおも、そのファむルやフォルダに察しお暩限を持っおいなければアクセスするこずはできたせんので、このリンク自䜓が挏掩したずしおもファむル自䜓の挏掩には繋がりたせん。 ただし、暩限の蚭定ミスなどの可胜性はれロではありたせんので、知る必芁がない人には共有リンクを知らせないこずが望たしいずいえたす。 移動ずコピヌ ファむルやフォルダの移動 ファむルやフォルダを Google ドラむブ内で移動しおも、共有リンクは倉曎されたせん。同じリンクで、匕き続き同じファむルやフォルダにアクセスするこずができたす。 たた、ファむルやフォルダをマむドラむブから共有ドラむブに移動したり、あるいは共有ドラむブから別の共有ドラむブに移動するなどしおも、リンクは倉わりたせん。 移動先ず移動元が違う Google Workspace 組織であっおも、リンクが倉わるこずはありたせん。 ファむルのコピヌ ファむルをコピヌした堎合、コピヌ先のファむルは新芏䜜成した堎合ず同様になりたすので、共有リンクは新しいものになりたす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の奥田です。圓蚘事では、Amazon Web ServicesAWS、Microsoft Azure、Google Cloud旧称 GCPが提䟛するフルマネヌゞドな AI ゚ヌゞェントサヌビスの比范 を行いたす。 はじめに 圓蚘事に぀いお AI ゚ヌゞェントずは ツヌルずは マルチ゚ヌゞェントシステムずは RAG ず䜵甚する効果 3瀟比范 前提条件 機胜比范 料金シュミレヌション 想定シナリオ AWS Azure Google Cloud 総評 AWS Azure Google Cloud 詳现の解説 Amazon Bedrock AgentsAWSの詳现 構成図 プロダクト䞀芧 できるこず 察応モデル ツヌル 料金 Azure AI Agent ServicesAzureの詳现 構成図 プロダクト䞀芧 できるこず 察応モデル ツヌル 料金 PlaybooksGoogle Cloudの詳现 構成図 プロダクト䞀芧 できるこず 察応モデル ツヌル 料金 たずめ Amazon Bedrock AgentsAWS Azure AI Agent ServiceAzure  Vertex AI PlaybooksGoogle Cloud はじめに 圓蚘事に぀いお 本蚘事では、生成 AI アプリケヌションの開発や PoC実蚌実隓を怜蚎しおいる方向けに、 Amazon Web ServicesAWS、Microsoft Azure、Google Cloud の3瀟が提䟛する AI ゚ヌゞェントサヌビス を玹介したす。 なお、圓蚘事の情報は、2025幎3月珟圚のものです。最新情報は各クラりドベンダヌの公匏ドキュメント等をご参照ください。 AI ゚ヌゞェントずは AI ゚ヌゞェントAI Agent ずは、耇雑な目暙を自埋的に遂行する AI システム のこずです。これらの゚ヌゞェントは、自然蚀語凊理NLP、機械孊習ML、ルヌルベヌスの意思決定などの技術を掻甚し、指定されたタスクを自動的に凊理したす。 たた、AI ゚ヌゞェントは さたざたなツヌルやデヌタ゜ヌスず連携するこずで、曎に高床なタスクの実行が可胜です。䟋えば、䌁業内のナレッゞベヌスず統合し、瀟内 FAQ の自動応答を行う AI ゚ヌゞェントや、顧客察応を最適化する AI チャットボットなどが挙げられたす。 近幎では、 クラりドベンダヌが提䟛する AI ゚ヌゞェントサヌビスを掻甚するこずで、開発コストを抑え぀぀、高床な゚ヌゞェントを構築するこずが可胜 になっおいたす。 本蚘事では、耇数の AI ゚ヌゞェントを組み合わせた瀟内ナレッゞシステムの構築をナヌスケヌスずしお想定し、各クラりドベンダヌのサヌビスの特城や掻甚方法に぀いお詳しく解説したす。 たた、本蚘事で玹介するものの䞭には、蚘事を執筆した2025幎3月珟圚でプレビュヌ段階のサヌビスも含たれおいたす。実装の際は各クラりドベンダヌの最新版ドキュメント等を参照するこずをおすすめしたす。 ツヌルずは ツヌルは、AI ゚ヌゞェントが倖郚の情報やサヌビスず連携するための「橋枡し」ずなる仕組みです。゚ヌゞェントはこれらのツヌルを掻甚するこずで、API の呌び出しやデヌタの凊理を行い、タスクを効率的に実行できたす。 Google が発衚したホワむトペヌパヌである「Agents」によるず、ツヌルには以䞋の3皮類がありたす。 参考 : Agents (Authors: Julia Wiesinger, Patrick Marlowand Vladimir Vuskovic) ゚クステンションExtensions API ずのむンタヌフェヌスを暙準化し、゚ヌゞェントが倖郚サヌビス䟋Google Flights APIを利甚できるようにする仕組み ゚ヌゞェントぱクステンションを通じお、必芁なパラメヌタや API の䜿甚方法を孊習しながら、適切に API コヌルを実行 ファンクションFunctions ゚ヌゞェントが必芁な凊理を実行するために、クラむアントサむドのコヌドを呌び出す仕組み 盎接 API を呌び出すのではなく、゚ヌゞェントが生成したパラメヌタを元に、倖郚システム偎で関数が実行される デヌタストアData Stores ベクトルデヌタベヌスなどを掻甚し、゚ヌゞェントが最新の情報や、構造化・非構造化デヌタにアクセスできるようにする仕組み ゚ヌゞェントは蚓緎時の知識だけでなく、リアルタむムのデヌタを参照しながら回答を生成できる マルチ゚ヌゞェントシステムずは マルチ゚ヌゞェント システムMulti-Agent System、MASずは、 耇数の自埋的な゚ヌゞェントが連携し、それぞれの専門性や圹割を掻かしおタスクを分担・実行するシステム を指したす。各゚ヌゞェントは、蚀語モデルや倖郚ツヌルAPI、デヌタストアなどを掻甚し、情報の取埗や意思決定、具䜓的な操䜜を自埋的に行いたす。これにより、単䞀の゚ヌゞェントでは察応が困難な耇雑な問題や倚段階のタスクにも、協調しお察凊できるようになりたす。 䟋えば、1぀の゚ヌゞェントが垂堎情報を収集し、もう1぀の゚ヌゞェントがそのデヌタを分析しお投資戊略を自動的に策定するずいった圹割に応じた゚ヌゞェントを耇数構築する、ずいったこずが可胜です。 RAG ず䜵甚する効果 RAG Retrieval Augmented Generationず䜵甚するこずで、AI゚ヌゞェントが、 事前に孊習したデヌタだけでなく、倖郚のデヌタ゜ヌスから情報を取埗し、それに基づいお応答を生成する こずを可胜にしたす。 各パブリッククラりドにおけるRAGの比范に぀いおは、以䞋の蚘事をご参照ください。 参考 : 生成AIのRAG構成を倧手3瀟AWS、Azure、Google Cloudで培底比范しおみた 3瀟比范 前提条件 AI ゚ヌゞェントを構築するにあたり、どのベンダヌのサヌビスでも耇数のデヌタ゜ヌスや基盀モデルに察応しおいたす。 たた、RAG 構築ず同様に「マネヌゞドなサヌビスだけの構成」、「OSS である LangChain をベヌスずしお適宜クラりドサヌビスを甚いる構成」など、アヌキテクチャの遞択肢も耇数甚意されおいたす。 圓蚘事では以䞋の実珟を芁件ずしお比范したす。 フルマネヌゞドサヌビスのみで構築 各プラットフォヌム䞊の開発ツヌルを利甚しお開発 耇数の゚ヌゞェントを組み合わせるマルチ゚ヌゞェントを実装するこずが可胜 䞊蚘芁件を満たすサヌビスずしお、以䞋の3サヌビスを遞定したした。 クラりド サヌビス AWS Amazon Bedrock Agents Azure Azure AI Agent Service Google Cloud Vertex AI Agent Builder の Playbooks ※ ※以前は「Vertex AI Agents」ずいう名称で利甚されおいたサヌビスが該圓したす。 2024 幎埌半から 2025 幎初頭にかけお、䞀郚の補品名、機胜名、コン゜ヌルに倉曎が行われるこずが発衚されおおりたす。本蚘事では新しい名称の 「Playbooks」 で統䞀衚蚘したす。 参考 : Renaming and console consolidation plan 機胜比范 以䞋は、各サヌビスの提䟛機胜の比范です。 Amazon Bedrock Agents Azure AI Agent Service Playbooks マルチ゚ヌゞェントの実珟 ◎ △ ◎ 倖郚デヌタの怜玢 ◎ ◎ ◎ 倖郚りェブサむトの怜玢 △ ◎ ☆ 䌚話履歎の保存 ◎ ◎ ◎ 評䟡の実斜 ◎ ◯ △ コンテンツフィルタリング ◎ ◎ ◎ ◎プレビュヌ画面から蚭定可胜 ◯ : プレビュヌ画面から蚭定䞍可だが API や代替手段が提䟛されおいる △ : 実装する等で利甚可胜 or 䞀郚のみプレビュヌ画面より蚭定可胜 ☆ドメむン所有暩を確認したりェブサむトのコンテンツを゜ヌスずしお蚭定可胜 料金シュミレヌション 想定シナリオ ずある瀟内向けシステムを仮定したす。 情報システム担圓者の負担を軜枛するため、゚ヌゞェントによる自動応答ずチケット発刞の2぀の機胜を䞭心に構成されおいたす。 システム芁件 は䞋蚘です。 24時間、365日皌働 1日あたりの問い合わせは500ä»¶ 1回の䜿甚に぀き 10 件のク゚リが発生 平均の入力文字数は100文字、出力は300文字 各瀟の独自サヌビスを利甚するLangChain などの OSS は䜿わない 3぀の゚ヌゞェントで構成 本システムは マルチ゚ヌゞェントずなり、各゚ヌゞェントはそれぞれ異なる圹割を担いたす。以䞋に 各゚ヌゞェントの機胜抂芁 を瀺したす。 1. 問い合わせ凊理゚ヌゞェント ナヌザヌからの問い合わせを受け付け、適切な応答を行う 入力内容を解析し、他の゚ヌゞェントぞ必芁な凊理を䟝頌する 2. ナレッゞ怜玢゚ヌゞェント 瀟内デヌタベヌスを参照し、問い合わせに関連する情報を怜玢する FAQ や過去の察応履歎を基に適切な回答を提䟛する 3. チケット発刞゚ヌゞェント 解決が難しい問い合わせに察しお、ナヌザヌに必芁な情報を確認し、サポヌト察応のためのチケットを䜜成する 䜜成されたチケットはデヌタベヌスに保存され、埌日、担圓者が察応を行う 䞊蚘の条件の䞋、1 ヶ月間の利甚料を蚈算したす。なお実際には API サヌバ等、RAG サヌビス以倖の料金やデヌタストレヌゞ料金などが発生する可胜性がありたすが、今回は単玔化のため考慮から倖したす。 いずれも詊算に甚いた単䟡は蚘事を執筆した2025幎2月珟圚のものです。ご自身で詊算する際は、必ず公匏から発衚されおいる料金衚をご参照ください。たた、ドル・円換算は1ドルを150円ずしお蚈算しおいたす。 AWS 1ヶ月の利甚料は玄99,360円です。 Aurora Serverless v2  86.4USD※1 Anthropic - Claude 3.5 Sonnet Amazon Bedrock Edition入力トヌクン1 文字 0.8 トヌクン蚈算36USD Anthropic - Claude 3.5 Sonnet Amazon Bedrock Edition出力トヌクン1 文字 0.8 トヌクン蚈算540USD ※1Amazon Aurora Serverless は自動停止時のコンピュヌティングコストは0USD ずなりたすが、本システムでは24時間、365日皌働であるず想定しおいるため1.0 ACU の Aurora Serverless v2 を730時間起動する蚭定で算出をしおたす。 Azure GPT o1 2024-12-17 を利甚した堎合、1ヶ月の利甚料は418,500円です。 コヌド むンタヌプリタヌ450USD GPT o1 2024-12-17 Global 入力トヌクン 1 文字 0.8 トヌクン蚈算180USD GPT o1 2024-12-17 Global 出力トヌクン 1 文字 0.8 トヌクン蚈算2,160USD GPT o1-mini を利甚した堎合、1ヶ月の利甚料は144,720円です。 コヌド むンタヌプリタヌ 450USD GPT o1-mini 入力トヌクン 1 文字 0.8 トヌクン蚈算39.6USD GPT o1-mini 出力トヌクン 1 文字 0.8 トヌクン蚈算475.20USD Google Cloud 1ヶ月の利甚料は玄270,000円です。※2 Playbooks ク゚リ1800USD ※2むンデックス デヌタ ストレヌゞの䟡栌は1ヶ月あたり10GiB たでの無料割圓があり、無料割圓の範囲内での利甚ず想定したす。 10GiB を超えた堎合、生デヌタ1GiB あたり月額5.00 USD が発生したす。 総評 AWS Amazon Bedrock Agents は、生成AIモデルが倖郚ツヌルや Knowledge Tool ず連携しお、ナヌザヌの芁求に応じお自埋的に行動するシステムのこずです。 たた、Bedrock Agents は Amazon 自瀟の基盀モデルAmazon Titan 及び Amazon Novaだけでなく、Anthropic 瀟や Cohere 瀟が提䟛する基盀モデルも遞択可胜です。利甚するモデルの皮類によっお、甚途や性胜、䟡栌などを最適化できたす。 2024幎12月のアップデヌトにより、耇数の゚ヌゞェントを協調させお動䜜させる「マルチ゚ヌゞェント」機胜が導入されたした。これにより、異なる専門性を持぀゚ヌゞェントが連携しお耇雑なタスクを効率的に凊理できたす。 Amazon Bedrock Flows を利甚するこずでロヌコヌドでの開発が可胜であるこず、Knowledge Tool を掻甚するこずで様々な応甚が効くこずから 初玚者から䞭玚者向け のサヌビスであるず蚀えたす。 参考 : Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガむド] Azure Azure AI Agent Service は、Microsoft のマネヌゞドサヌビスず組み合わせお、゚ンタヌプラむズ向けに機胜拡匵したサヌビスです。゚ヌゞェントは生成AIモデルを掻甚し、倚様なツヌルず連携しながらナヌザヌの芁求に応じお自埋的にタスクを実行したす。 Azure AI Agent Service では、䌚話の状態コンテキストを「Threadスレッド」で䞀元管理したす。たた、゚ヌゞェントが凊理を実行する際は「Runラン」ずいう単䜍でタスクを明確に分割できたす。 Azure AI Agent Service は基本的な機胜のみナヌザヌむンタヌフェヌスUIを提䟛しおいたすが、すべおの機胜を掻甚するにはコヌディング知識が必芁ずなりたす。 これらの理由から、Azure AI Agent Service は 䞊玚者向け のサヌビスず蚀えたす。特に゚ンタヌプラむズ環境で高床なカスタマむズや詳现な管理を求める開発者や䌁業に最適です。 Google Cloud Google Cloud の Vertex AI Playbooks は、生成 AI 機胜を新たに組み蟌んだ高床な䌚話型 AI サヌビスです。埓来の自然蚀語凊理NLPプラットフォヌムであるDialogflow をリブランディングしたものです。ロヌコヌドでの開発が可胜なため、専門的な知識がなくおも迅速に高機胜な゚ヌゞェントを構築できたす。 Vertex AI Playbooks はリク゚スト数に応じお課金される仕組みずなっおおり、コスト蚈算が明確で管理しやすいのが特城です。Google Cloud の RAGRetrieval-Augmented Generationである Vertex AI Search ず同様、むンスタンス料金が䞍芁であるため、利甚時のコストを抑えるこずが可胜です。 Google が提䟛する生成 AI モデルである Gemini を掻甚するこずで、より自然で高床な察話シナリオを実珟できたす。 デヌタストアずしお、 BigQuery にも察応 しおいたす。これにより、倧芏暡なデヌタセットをリアルタむムに掻甚する堎合においおも、高速か぀正確なデヌタアクセスを実珟できたす。特に倧芏暡デヌタを扱う䌁業やシステムで効果的な運甚が可胜ずなりたす。 明快な料金䜓系ず芖芚的に分かりやすいむンタヌフェヌスのため、初玚者から䞭玚者向けのサヌビスであるず蚀えたす。 詳现の解説 Amazon Bedrock AgentsAWSの詳现 構成図 プロダクト䞀芧 Amazon Bedrock Agents Amazon Bedrock Agents は、AWS が提䟛する察話型アプリケヌションを構築できるサヌビスです。 Knowledge bases for Amazon Bedrock Knowledge Bases for Amazon Bedrock は、RAGRetrieval-Augmented Generation を掻甚し、基盀モデルず組み合わせお RAG アプリケヌションを開発できるマネヌゞドサヌビス です。 Amazon S3 Amazon S3Simple Storage Service は、スケヌラブルなオブゞェクトストレヌゞサヌビスであり、倧量のデヌタを安党に保存・管理できたす。 AWS Lambda AWS Lambda は、サヌバヌレスアヌキテクチャを実珟するむベント駆動型のコンピュヌティングサヌビスです。 AWS Lambda は、Amazon Bedrock Agents のツヌルずしお、倖郚システムずの連携やカスタムロゞックの実行を担う重芁な圹割を果たしたす。具䜓的には、゚ヌゞェントのワヌクフロヌ内で API コヌルを実行したり、デヌタ凊理を行ったりするためのバック゚ンド凊理を自動化する こずができたす。 本事䟋では DynamoDB ぞのデヌタ曞き蟌みを実行する関数を䜜成したす。 RDSAurora Serverlessクラスタヌ Amazon RDSRelational Database Service の Aurora Serverless は、オンデマンドでスケヌルするリレヌショナルデヌタベヌスです。 本構成ではベクトルデヌタ゜ヌスずしおの圹割を担いたす。 ベクトルデヌタ゜ヌスは䞋蚘でも代替可胜です。 Amazon OpenSearch Serverless Amazon Aurora Pinecone Redis Enterprise Cloud DynamoDB DynamoDB は、Amazon が提䟛するフルマネヌゞド型の NoSQL デヌタベヌスサヌビスです。 できるこず マルチ゚ヌゞェントの実珟 Amazon Bedrock for Agents では、新たに 「マルチ゚ヌゞェントコラボレヌション機胜」 が発衚されたした。 埓来の AI システムでは、1 ぀の゚ヌゞェントが単独でタスクを凊理するケヌスが䞀般的でした。しかし、本機胜を掻甚するこずで、耇数の゚ヌゞェントが協力しおタスクを分担し、より高床な問題解決が可胜です。 参考 : Amazon Bedrock のマルチ゚ヌゞェントコラボレヌション機胜の玹介 プレビュヌ 察応モデル Amazon Bedrock ゚ヌゞェントは Amazon Bedrock のすべおのモデルをサポヌトしおいたす。 察応モデル䞀芧 その䞭でも ゚ヌゞェントのアヌキテクチャずの統合甚に埮調敎されたモデル は䞋蚘ずなりたす。 Amazon Nova Pro 1.0 Amazon Nova Lite 1.0 Amazon Nova Micro 1.0 Anthropic Claude 3.5 Sonnet V2 Anthropic Claude 3.5Haiku v1 Anthropic Claude Instant v1.2 Anthropic Claude v2.1 Anthropic Claude v2 Anthropic Claude 3 Sonnet v1 ツヌル Amazon Bedrock Agents では、「 アクショングルヌプ 」 を掻甚しお゚ヌゞェントの動䜜を蚭定できたす。 アクショングルヌプは Lambda 関数 たたは OpenAPI を甚いお定矩するこずが可胜です。 今回のサンプルアプリでは、3぀目のマルチ゚ヌゞェントずしお 「チケット発刞゚ヌゞェント」 を実装したした。 この゚ヌゞェントは、チャットボットによるヒアリングの埌、サポヌト察応のためのチケットを䜜成し、デヌタベヌスに栌玍する圹割を担いたす。 本サンプルアプリでは、Lambda 関数にデヌタを曞き蟌むための゜ヌスコヌドを蚘述し、゚ヌゞェントがトリガヌを起こすこずでデヌタベヌスぞの曞き蟌みを実珟しおいたす。 参考 : Amazon Bedrock の゚ヌゞェントにアクショングルヌプを远加する 料金 抂芁 Amazon Bedrock Agents では䞻に2぀のサヌビスで費甚が発生したす。 基盀モデル利甚料金 ベクトルデヌタベヌス料金 基盀モデル利甚料金 察応しおいる基盀モデルのうち、蚘事執筆時点で 非掚奚ずなっおいない モデルの費甚は䞋蚘ずなりたす。 モデル名 入力トヌクンあたりの料金1,000トヌクン 出力トヌクンあたりの料金1,000トヌクン Amazon Nova Pro 1.0 $0.0008 $0.0032 Amazon Nova Lite 1.0 $0.00006 $0.00024 Amazon Nova Micro 1.0 $0.000035 $0.00014 Anthropic Claude 3.5 Sonnet V2 $0.003 $0.015 Anthropic Claude 3.5 Haiku V1 $0.0008 $0.004 Anthropic Claude 3 Sonnet V1 $0.003 $0.015 モデルトヌクン数の蚈算は、衚珟方法や文脈によっお異なるため、正確な掚枬を行うこずは困難です。特に、単語の長さや特殊な蚘号、改行、゚ンコヌディングの違いなどが圱響を䞎える可胜性がありたす。 ClaudeAnthropic の AI モデルの堎合、Anthropic が提䟛する Client SDKs 、あるいは Google Cloud 䞊で count-tokens ゚ンドポむントを䜿甚する こずで実際のトヌクン数を確認するこずが可胜です。この SDK を利甚するこずで、トヌクンのカりントを正確に把握し、適切なプロンプト蚭蚈やコスト管理を行うこずができたす。 䟋えば G-gen のホヌムペヌゞより匕甚した代衚メッセヌゞは文字数953改行を陀いた文字数ずなり、トヌクン数は688ずなりたした。 私たちは、2006幎7月に蚭立したトップゲヌトず2021幎8月に蚭立した G-gen が合䜵し新生 G-gen ずしお新たにスタヌトしたした。䞡瀟ずもに Google Cloud のプレミアパヌトナヌでありこの合䜵によっお Google Cloud におけるアプリケヌション開発からむンフラ構築たで高い技術力を持ち、お客様により高い付加䟡倀を提䟛できるこずになりたした。 たた、私たちは AWS 専業むンテグレヌタヌである株匏䌚瀟サヌバヌワヌクスを芪䌚瀟ずし、䞖界でマルチクラりドむンテグレヌションを提䟛しおいる Bespin Global Inc. ずのゞョむントベンチャヌです。 サヌバヌワヌクスでは2009幎から AWS に特化したむンテグレヌション事業を開始し、 AWS においおは囜内トップクラスの技術力ず実瞟を有しおいたす。䞀方でクラりド掻甚においおは倚様化が進み、様々なクラりドサヌビスを適切に掻甚しおいくこずが今埌のお客様の IT システムにおける最適解になりそうだず感じ始めおいたす。そのなかで Google Cloud は生成 AI やデヌタ分析などにおいおナニヌクな技術を有しおおり、お客様の倚様化するニヌズに応えるために重芁な圹割を果たすず考えおいたす。この私達が持぀ Google Cloud のノりハりずサヌバヌワヌクスの持぀ AWS のノりハりを連携しマルチクラりド環境においおも各々の経隓倀を掻かしたカスタマヌサクセスを既に提䟛し始めおいたす。 G-gen では Chromebook での業務も実践し、 Google の考える新しい䞖界を身を持っお実珟しおいこうず取り組んでいたす。Google Cloud や Google Workspace を䞭心にクラりドサヌビスを適切に掻甚するこずにより、堎所に瞛られず、高セキュリティで、アゞリティの高い IT システムを実珟したす。この新しい IT システムの䞖界を党おのお客様に提䟛するこずが私達のミッションであり、その先の DX によるお客様のビゞネスの成功にも繋がっおいくず確信しおいたす。 私たちは Google Cloud のプロフェッショナルずしおお客様の「クラりドで、䞖界を、もっず、はたらきやすく」を実珟しおいきたす。 ベクトルデヌタベヌス料金 Bedrock で察応する Knowledge base は䞋蚘ずなりたす。 Amazon OpenSearch Serverless Amazon Aurora PostgreSQL Serverless Amazon Neptune Analytics 今回の事䟋ではAmazon Aurora PostgreSQL Serverless を利甚しおいるため、Amazon Aurora PostgreSQL Serverless に絞った説明をいたしたす。 Amazon Aurora Serverless の料金はAurora Capacity UnitACUの利甚時間に応じお発生したす。 ACUは凊理胜力の指暙で、 1 ACU は以䞋に盞圓したす。 項目 性胜 メモリ 箄2GiB 米囜東郚バヌゞニア北郚リヌゞョンでは、Aurora Standard の料金は1 ACUあたり0.12 USD/時間です。 Azure AI Agent ServicesAzureの詳现 構成図 プロダクト䞀芧 Azure AI Agent Service Azure AI Agent Service は、Microsoft Azure 䞊で提䟛される AI ゚ヌゞェントの開発・デプロむを支揎するサヌビスです。䌁業がカスタム AI アシスタントや自動化゜リュヌションを構築するための基盀を提䟛したす。 Azure Cosmos DB Azure Cosmos DB は、Microsoft Azure が提䟛する グロヌバル分散型のマルチモデル デヌタベヌス サヌビス です。柔軟なスケヌリング、䜎レむテンシ、99.999% の可甚性を提䟛し、NoSQL デヌタベヌスずしお利甚されたす。 Azure AI Foundry旧Azure AI Studio Azure AI Foundry旧 Azure AI Studioは、䌁業向けの AI 開発環境を提䟛するプラットフォヌムです。開発者やデヌタサむ゚ンティストが、AI モデルの開発、トレヌニング、デプロむを䞀元管理できるツヌルセットを備えおいたす。 できるこず マルチ゚ヌゞェントの実珟 珟時点で、 Azure AI Agent Service はシングル゚ヌゞェントの構築をサポヌト しおいたすが、䞋蚘手段によりマルチ゚ヌゞェントを実珟可胜です。 AutoGen や Semantic Kernel などのフレヌムワヌクず連携 Azure AI Agent Service の AgentTeam クラスを利甚 察応モデル Azure AI Agent Service で察応可胜なモデルは䞋蚘ずなりたす。 gpt-4o, 2024-05-13 gpt-4o, 2024-08-06 gpt-4o-mini, 2024-07-18 gpt-4, 0613 gpt-4, 1106-Preview gpt-4, 0125-Preview gpt-4, turbo-2024-04-09 gpt-4-32k, 0613 gpt-35-turbo, 0613 gpt-35-turbo, 1106 gpt-35-turbo, 0125 gpt-35-turbo-16k, 0613 Meta-Llama-405B-Instruct Mistral-large-2407 Cohere-command-r-plus Cohere-command-r ツヌル Azure AI Agents は OpenAI の Assistants API を基盀ずし、LLM の胜力を汎甚的なプログラムによるアクションず結び぀けるこずで、匷力な自動化機胜を提䟛したす。 Azure AI Agents は、「ナレッゞツヌル」 ず 「アクションツヌル」 の2皮類のツヌルを提䟛し、゚ヌゞェントのパフォヌマンスず利䟿性を向䞊させたす。 ナレッゞツヌルは以䞋の3぀のオプションを利甚可胜です。 Grounding with Bing Search File Search Azure AI Search アクションツヌルは以䞋の4぀のオプションを利甚可胜です。 Function Calling Code Interpreter OpenAPI Specified Tools Azure Functions 今回のサンプルアプリでの3぀目のマルチ゚ヌゞェント 「チケット発刞゚ヌゞェント」では、 Function Calling を利甚 し、デヌタベヌスに曞き蟌むための関数を実行するこずで実珟可胜です。 料金 Azure AI Agent Service は、䞋蚘料金に基づいお算出されたす。 基盀モデル利甚料金 ツヌルに察しお発生する費甚 基盀モデル利甚料金 察応しおいる基盀モデルのうち、蚘事執筆時点で非掚奚ずなっおいないモデルの費甚は䞋蚘ずなりたす。 モデル名 入力料金100䞇トヌクンあたり 出力料金100䞇トヌクンあたり gpt-4o, 2024-05-13 $5.00 $15.00 gpt-4o, 2024-08-06 $2.50 $10.00 gpt-4o-mini, 2024-07-18 $0.15 $0.60 gpt-35-turbo, 0125 $0.50 $1.50 ツヌルに察しお発生する費甚 各ツヌルに関係する費甚に関しおは各ドキュメントをご参照ください。 参考 : Assistants API 参考 : Grounding with Bing Search 参考 : Azure AI Search さらに、 Azure Logic Apps や Azure Functions など、珟圚利甚可胜たたは将来远加される自動化に察しおも料金が発生されるこずが公匏ドキュメントに蚘茉されおおりたす。 PlaybooksGoogle Cloudの詳现 構成図 プロダクト䞀芧 PlaybooksVertex AI Agents Playbooks ずは、チャットボット甚の゚ヌゞェントを構築するためのフルマネヌゞドサヌビスです。 構築されたチャットボットは API 経由で利甚したり、Conversational Agents 旧称Dialogflow CXを利甚するこずでカスタマむズするこずができたす。 Playbook旧称Vertex AI Agents に぀いお詳しくは以䞋の蚘事をご芧ください。 参考 : Vertex AI Agent BuilderVertex AI Search/Agentsを培底解説 Cloud Run functions サヌバレスのコンピュヌティングサヌビスです。 2024幎倏にCloud Functions から Cloud Run functions ずしおリブランディングされたした。 詳しくは以䞋の蚘事をご芧ください。 参考 : Cloud Run functionsを培底解説 Firestore スケヌラブルでリアルタむム同期が可胜な NoSQL ドキュメントデヌタベヌスです。 Cloud Storage Cloud Storage はフルマネヌゞドなオブゞェクトストレヌゞです。 Google Agentspace参考 Google でマネヌゞドで管理されるAI ゚ヌゞェントずなりたす。 Gemini の高床な掚論、Google 品質の怜玢、自瀟のデヌタが集玄された゚ヌゞェントを䜿甚しお、埓業員が䌁業の専門知識を掻甚するこずができたす。 法人利甚の堎合は Google Cloud 䞊で゚ンタヌプラむズ向け Agentspace を構築するこずが可胜です。 蚘事執筆時点ではプレビュヌ段階のサヌビスずなっおおりたすため、本蚘事では詳しくは取り䞊げたせんが、詳しくは䞋蚘蚘事をご芧ください。 参考 : Google Agentspaceを培底解説 できるこず マルチ゚ヌゞェントの実珟 Instruction 郚分に他の゚ヌゞェントを呌び出す旚を指瀺するこずで実珟可胜です。 察応モデル 䞋蚘モデルを利甚するこずが可胜です。 Gemini 1.5 flash Gemini 1.5 flash 002Preview Gemini 1.0 pro 001 ツヌル ツヌルは䞋蚘を遞択可胜です。 名称 組み蟌みツヌル OpenAPI ツヌル デヌタストアツヌル Function ツヌル 圹割 Google によっお管理 OpenAPIツヌルを䜿っお倖郚APIに接続可胜 デヌタストアからナヌザの質問に回答できる クラむアントコヌドからアクセス可胜だがOpenAPI ツヌルからはアクセスできない機胜がある堎合に利甚 ツヌル | Vertex AI Agents | Google Cloud 料金 Playbooks のリク゚スト回数に応じた費甚が発生したす。 サヌバレスでフルマネヌゞドなため、垞時起動のむンスタンス料金は発生したせん。 Playbooks Chat は 1,000ク゚リで12USD ずなりたす。 たずめ Amazon Bedrock AgentsAWS 専門的な知識を䞀定皋床持った初玚者から䞭玚者に適したサヌビスです。 様々な基盀モデルに察応しおおり、高床な機胜をロヌコヌドで実装可胜です。 Azure AI Agent ServiceAzure  ゚ンタヌプラむズ向けの高床な゚ヌゞェントシステム構築が可胜な䞊玚者向けのサヌビスです。 Microsoft のマネヌゞドサヌビスず連携するこずが可胜です。高い柔軟性ず機胜性を持぀ため、䞀定以䞊の技術力を持぀開発者や䌁業に特に適しおいたす。 Vertex AI PlaybooksGoogle Cloud 明快な料金䜓系ず芖芚的に分かりやすいむンタヌフェヌスを備えおいるため、初玚者から䞭玚者向けのサヌビスであるず蚀えたす。 埓来の NLP プラットフォヌムである Dialogflow に生成AIを統合するこずで、より匷力な䌚話型゚ヌゞェントをロヌコヌドで構築可胜にしおいたす。たた 高床なデヌタ凊理胜力を備え、さたざたな芏暡の組織やビゞネスにおいお、利䟿性の高いサヌビスです。 たた、倧幅な名称倉曎の予定があり、2025幎4月に開催予定の Google Cloud Next にお倧きな倉曎が発衚される可胜性がありたす。今埌のリリヌス情報が楜しみなサヌビスです。 Risa (蚘事䞀芧) クラりド゜リュヌション郚クラりドデベロッパヌ課 Google Cloudの可胜性に惹かれ、2024幎4月G-genにゞョむン。 Google Cloud Partner Top Engineer 2025 Google Cloud 11 資栌保有。日々修行䞭です Follow @risa_hochiminh
G-gen の min です。先日、デヌタポヌタル英名 Data Studio、旧称 Looker Studioを䜿い、Google Cloud旧称 GCPの BigQuery のデヌタ可芖化を詊みた際に困ったこずがありたした。今回は、発生した問題ず解決方法を蚘茉したす。同じ課題に盎面した方の参考になれば幞いです。 やりたかったこず 発生した問題 原因調査 怜蚌 解決方法 やりたかったこず デヌタポヌタルでは、耇数のデヌタを結合しお1぀のデヌタセットずしお扱うこずができたす。 参考 : デヌタポヌタルでのブレンドの仕組み たた デヌタポヌタルでは、グラフから CSV 圢匏などでデヌタを゚クスポヌトできたす。 参考 : グラフからデヌタを゚クスポヌトする 今回は、Google Analytics 4GA4のデヌタず BigQuery のデヌタを デヌタポヌタルで結合し、可芖化する必芁がありたした。最終的に、可芖化したデヌタを CSV 圢匏で゚クスポヌトするこずを考えおいたした。 具䜓的な手順は以䞋のずおりです。 デヌタポヌタルで新芏レポヌトを䜜成し、GA4 をデヌタ゜ヌス A ずしお远加したす。 デヌタポヌタルに BigQuery の玄210䞇行のデヌタを持぀テヌブルをデヌタ゜ヌス B ずしお远加したす。 デヌタ゜ヌス A ずデヌタ゜ヌス B を内郚結合し、結合されたデヌタ゜ヌス C を䜜成したす。デヌタ゜ヌス C は玄30䞇行です。 デヌタ゜ヌス C をもずに衚圢匏のグラフを䜜成したす。 䜜成したグラフから、 CSV 圢匏でデヌタを゚クスポヌトしたす。 発生した問題 手順5で、以䞋の譊告メッセヌゞが衚瀺されたした。 このグラフには切り捚おられたデヌタが含たれおいるため、゚クスポヌトされたデヌタは完党なものではありたせん。 ゚クスポヌトボタンを抌すず、ダりンロヌドが実行されたしたが、ダりンロヌドされたデヌタは7侇5千行のみでした。しかし゚クスポヌトしようずした衚には、実際には玄30䞇行が蚘録されおいたす。 原因調査 たず、譊告メッセヌゞずダりンロヌド行数に関連があるか調査したした。デヌタポヌタルの公匏ドキュメントを確認したずころ、以䞋の蚘述がありたした。 1 ぀のグラフから゚クスポヌトできるデヌタは、750,000 行が䞊限ずなりたす。 参考 : グラフからのデヌタの゚クスポヌトに関する制限 この情報から、譊告メッセヌゞずダりンロヌド行数は関連がなく、別の問題であるこずがわかりたした。 次に、BigQuery コネクタに関する蚘述を芋぀けたした。 BigQuery コネクタを䜿甚しお返すこずができる最倧行数は 200 䞇行です。デヌタポヌタルでは、200 䞇行を超えるデヌタがある堎合は衚瀺されたすが、行数は明瀺されたせん。 参考 : 割り圓おず䞀般的な䞊限 BigQuery のデヌタ可芖化には、200䞇行の制限があるこずがわかりたした。 怜蚌 制限を回避するために、「やりたかったこず」の手順3で、結合前にデヌタ゜ヌス B を200䞇行以䞋になるように絞り蟌みたした。その結果、譊告メッセヌゞは衚瀺されなくなりたした。 公匏ドキュメントの「行数は明瀺されたせん」ずいう蚘述が気になったため、BigQuery 単䜓で衚圢匏のグラフを䜜成し、行数が200䞇行を超えた堎合の挙動を確認したした。 衚圢グラフでは、行数の最倧が「2,000,000+」ず衚瀺されたした。200䞇行を超える行ぞのペヌゞ送りはできたせんでした。 次に、スコアカヌドを䜿甚しお同様のデヌタを衚瀺したずころ、正確な集蚈倀が衚瀺されたした。 これは、スコアカヌドが集蚈結果のみを取埗するため、行数制限の圱響を受けなかったず考えられたす。 実行されたク゚リを確認したずころ、以䞋でした。 SELECT COUNT ( 1 ) AS t0_qt_kpwfrzt8pd FROM `m-sasaki.sample_dataset.sample_data` AS t0 LIMIT 2000001 ; なお、デヌタポヌタルから BigQuery に発行されるク゚リは、以䞋の手順で確認できたす。 BigQuery コン゜ヌルを開きたす。 画面䞋郚の[ゞョブ履歎]から、察象のク゚リのゞョブ ID を遞択したす。 参考 : BigQuery に発行された SQL を衚瀺する 解決方法 解決策は、デヌタ゜ヌスの結合前に、BigQuery から取埗するデヌタを200䞇行以䞋にするこずです。 䟋えば、特定の条件でデヌタを絞り蟌みたい堎合、デヌタポヌタルのデヌタの統合画面でフィルタを適甚できたす。このフィルタリングは、デヌタ結合の前に実行されたす。 参考 : 統合ず明瀺的な期間およびフィルタ 䜐々朚 愛矎 (min) (蚘事䞀芧) クラりド゜リュヌション郚 デヌタアナリティクス課。2024幎7月 G-gen にゞョむン。G-gen 最南端、沖瞄県圚䜏。最近芚えた島蚀葉は、「マダヌ猫」。
G-gen の溝口です。この蚘事では NotebookLM in Pro を䜿い、架空の䌚瀟に存圚する瀟内デヌタを甚いたAIアシスタントの䜜成方法ず機胜の解説をしたす。 はじめに NotebookLM ずは NotebookLM Enterprise ずは Gemini アプリずの違い 事前準備 怜蚌方法 ケヌス1 : 䌚瀟説明を䜜成させる ケヌス2 : 取り扱い補品に぀いお質問する ケヌス3 : 人事制床に぀いお質問する Studio 機胜を䜿う Discover、音声抂芁、マむンドマップ はじめに NotebookLM ずは NotebookLM は、Google が提䟛する AI リサヌチアシスタントです。ナヌザヌがアップロヌドしたドキュメントに基づいお、情報の芁玄、質問応答、ノヌト䜜成などを支揎したす。Google アカりントがあれば Web ブラりザから利甚でき、料金は発生したせん。無償で簡単に独自の生成 AI アシスタントを甚意できるのが匷みです。 NotebookLM in Pro ずは、NotebookLM の有料プランです。無償プランずの䞻な違いずしお、ノヌトブック数や゜ヌス数、1日のク゚リ数、音声生成数などの䞊限が挙げられたす。たた、高床な機胜や優先的なサポヌトも提䟛されたす。NotebookLM in Pro は、NotebookLM のヘビヌナヌザヌや、ビゞネスでの利甚に適しおいたす。 NotebookLM NotebookLM in Pro 料金 無料 有料もしくは、GoogleWorkspace の察象プランに組み蟌み ノヌトブック数 100 500 ノヌトブックあたりの゜ヌス数 50 300 1日のチャットク゚リ数 50 500 高床な機胜 なし ・ 回答スタむルのカスタマむズ ・ 利甚状況分析 など 1日のチャットク゚リ数 50 500 1日の音声抂芁生成数 3 20 圓蚘事では、倚数のナヌザヌが NotebookLM を利甚するビゞネスシヌンを想定しお、無償版の NotebookLM ではなく、Google Workspace に組み蟌みの NotebookLM in Pro を利甚したす。 参考 : NotebookLM ヘルプ 参考 : NotebookLM の Pro 機胜の詳现 参考 : NotebookLM を Pro プランにアップグレヌドする なお、NotebookLM in Pro は以前2025幎5月頃たで NotebookLM Plus ず呌ばれおいたした。個人向けサブスクリプションのプラン名が Google AI Pro に倉曎されたのに䌎い、NotebookLM Plus は NotebookLM in Pro ぞず改名 されたした。 NotebookLM NotebookLM Enterprise ずは Google Cloud ず統合され、より䌁業向けの䌁業が匷化された NotebookLM Enterprise も存圚したす。NotebookLM Enterprise は Google Cloud ず統合されおおり、より高床なセキュリティや統制を敷くこずができたす。 NotebookLM Enterprise で䜜成されたノヌトブックは、無償版 NotebookLM や Google Workspace の NotebookLM in Pro に察しお共有するこずはできたせん。 NotebookLM の各゚ディションの違いに぀いおの詳现は、以䞋の蚘事を参照しおください。 blog.g-gen.co.jp Gemini アプリずの違い Google は、NotebookLM のほかにも、 Gemini アプリ ずいう察話型 AI ツヌルを提䟛しおいたす。NotebookLM ず Gemini アプリの違いに぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp 事前準備 たずは、NotebookLM in Pro が組み蟌たれおいる゚ディションBusiness Standard/Plus や Enterprise Standard/Plus 等の Google Workspace アカりントにログむンした状態で、NotebookLM のペヌゞ https://notebooklm.google.com/ ぞアクセスしたす。 画面右䞊に「PRO」の衚蚘があれば、お䜿いの゚ディションは NotebookLM in Pro です。 PRO の衚蚘 画面䞭倮の「+ 新芏䜜成」ボタンを抌䞋しお、新しいノヌトブックを䜜成したす。ノヌトブック画面が開いたら、画面巊郚分の「+ ゜ヌスを远加」ボタンを抌䞋しお、デヌタ゜ヌスを远加できたす。 ゜ヌスを远加 デヌタ゜ヌスずしお、以䞋のようなものが利甚できたす。 PC 䞊のファむルの盎接アップロヌド Google ドラむブ内にあるGoogle ドキュメント、Google スラむド りェブサむトリンクや Youtube リンク クリップボヌド内のテキスト ファむルのアップロヌドの際は、フォルダの䞀括アップロヌドはできたせんが、ファむルを耇数遞択するこずができたす。 ゜ヌスをアップロヌド NotebookLM in Pro には、回答のスタむルや、長さをカスタマむズする機胜もあり、生成 AI からの回答をナヌザヌのニヌズに合わせお調敎できたす。これは、無償版には備わっおいない機胜です。 カスタマむズ画面 䜜成されたノヌトブックは同じ Google Workspace 組織に所属する他のナヌザに共有するこずができたす。これにより、同じ組織の䞭で、カスタマむズした AI アシスタントを共同利甚するこずができたす。Google Workspace アカりントで NotebookLM in Pro を䜿っおいる堎合、無償版個人アカりントの NotebookLM ナヌザヌや、他の Google Workspace 組織のナヌザヌには、ノヌトブックを共有するこずはできたせん。 共有画面 怜蚌方法 実際の運甚されおいるデヌタに近いものをサンプルずしお甚意したした。本蚘事に登堎する䌚瀟情報、倀及び䜜成された文章はすべお生成 AI で生成した架空のものです。 サンプル商事株匏䌚瀟の抂芁 サンプル商事株匏䌚瀟は、倧阪に本瀟を眮く石油化孊補品を扱う総合商瀟です。創業50幎の歎史を持ち、囜内倖に倚くの取匕先を持぀、業界屈指の䌁業です。 今回は䞀般的な䌁業が所有する「就業芏定」や「絊䞎芏定」などの10以䞊の芏定の他に、䞻に取り扱う化孊補品の Wikipedia ず、Youtube に掲茉のある化孊補品を玹介しおいるペヌゞを参照元にしたす。 アップロヌド埌の゜ヌス画面 ケヌス1 : 䌚瀟説明を䜜成させる プロンプト 新人研修甚にわかりやすく䌚瀟抂芁説明をお願いしたす サンプル商事株匏䌚瀟の新人研修向け䌚瀟抂芁説明 サンプル商事株匏䌚瀟は、 瀟員の胜力を最倧限に匕き出し、䌚瀟の発展に貢献するこずを目的 ずしおいたす。 事業の基本方針 胜力䞻矩 経営理念や事業戊略に合う人材を胜力に基づいお採甚したす。 胜力開発 瀟員の胜力開発を支揎し、䌚瀟の成長に貢献できる人材を育成したす。 人事評䟡 瀟員の胜力、業瞟、貢献床を公正に評䟡する人事評䟡制床を蚭けおいたす。評䟡結果は、昇進、昇栌、異動、賞䞎、絊䞎に反映されたす。 組織掻性化 瀟員の胜力開発、キャリア圢成、組織掻性化のため、異動を呜じるこずがありたす。 絊䞎 埓業員の絊䞎は、基本絊、諞手圓、賞䞎で構成されたす。 䌚蚈凊理 公正劥圓ず認められる䌁業䌚蚈の基準に埓い、䌚蚈期間は毎幎4月1日から翌幎3月31日たでです。 顧客関係 顧客ずの良奜な関係を構築し、顧客満足床向䞊を目指したす。 情報管理 情報の適切な保護ず利甚を図りたす。 これらの情報から、サンプル商事株匏䌚瀟は、 瀟員の成長ず公正な評䟡を重芖し、効率的で掻性化された組織運営を目指しおいる ず考えられたす。 䞎えられたデヌタ゜ヌスから䌁業抂芁を簡朔にたずめおくれたした。 ケヌス2 : 取り扱い補品に぀いお質問する プロンプト キシレンの有害性はトル゚ンずどう違いたすか キシレンずトル゚ンの有害性の違いに぀いお、゜ヌスから埗られる情報は以䞋の通りです。 キシレンの有害性: トル゚ンず比范しお、 皮膚腐食性、県刺激性、生殖毒性、党身毒性が高い 。 毒劇物取締法 の劇物に該圓する。 トル゚ンの有害性: 毒劇物取締法 の劇物に該圓する。 シンナヌ䞭毒の原因ずなる。䞭枢神経系に圱響を䞎える。 これらの情報から、キシレンはトル゚ンよりも 皮膚や目ぞの刺激性、生殖機胜ぞの毒性、党身ぞの毒性が匷い ず考えられたす。 取扱補品の比范ず泚意点を出力しおくれたした。 ケヌス3 : 人事制床に぀いお質問する プロンプト 人事評䟡で重芖するポむントはどこですか 人事評䟡で重芖するポむントは、サンプル商事株匏䌚瀟の人事芏定によるず、瀟員の 胜力、業瞟、貢献床 です。 人事評䟡制床に関する詳现は以䞋の通りです 目的 : 瀟員の胜力を最倧限に匕き出し、䌚瀟の発展に寄䞎するこず 評䟡制床 : 瀟員の胜力、業瞟、貢献床を公正に評䟡するための人事評䟡制床を蚭ける 評䟡方法 : 目暙管理制床、360床評䟡、その他適切な方法 評䟡結果の掻甚 : 昇進、昇栌、異動、賞䞎、絊䞎などに反映 サンプル商事株匏䌚瀟では、 胜力䞻矩 を基本ずし、瀟員の 胜力開発 を支揎し、䌚瀟の 成長 に貢献できる人材を育成するこずを重芖しおいたす。人事評䟡は、瀟員の 昇進・昇栌 、 異動 、 賞䞎 、 絊䞎 などに反映され、瀟員の モチベヌション向䞊 や キャリア圢成 に繋がるように蚭蚈されおいたす。 各芏定から抜粋し蚘述しおくれたした。 Studio 機胜を䜿う NotebookLM の Studio 機胜は、アップロヌドされた゜ヌス文曞から、さたざたなコンテンツを生成するための機胜です。 Studio 機胜を利甚するこずで、アップロヌドされた文曞や音声ファむルから、以䞋のようなコンテンツを生成するこずができたす。この機胜により、倧量の情報を効率的に把握するこずができたす。 音声抂芁の生成2人の登堎人物がコンテンツに぀いお抂芁を語りあう音声を AI が生成。2025幎2月珟圚、英語のみ察応 よくある質問 孊習ガむド タむムラむン蚈画を時系列で敎理 ブリヌフィングドキュメント Studio 機胜 サンプル商事では、Studio 機胜を利甚するこずで、石油化孊物質、プラスチックの歎史、化孊に関する FAQ、甚語集などの解説ドキュメントやブリヌフィング甚のドキュメントを䜜成しおくれたした。 䜜成されたドキュメント䞀芧 䜜成されたブリヌフィングメモ 䜜成されたドキュメントは、NotebookLM の゜ヌスずしお利甚するこずができたす。 Discover、音声抂芁、マむンドマップ NotebookLM には、さらに「Discover゜ヌスの発芋」「音声抂芁」「マむンドマップ」などの応甚機胜がありたす。これらの機胜に぀いおは以䞋の蚘事で玹介しおいたすので、䜵せおご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 溝口 目 (蚘事䞀芧) ビゞネス掚進郚 営業2課 2023幎10月よりG-gen にゞョむン。 HRサヌビスを展開するベンチャヌ䌁業から、Google専業の営業ぞ。関西圚䜏でGoogle Cloudをメむンに掻動䞭。育児ず仕事のバランスを垞に暡玢䞭・・
G-gen の杉村です。2025幎2月のむチオシ Google Cloud旧称 GCPアップデヌトをたずめおご玹介したす。蚘茉は党お、蚘事公開圓時のものですのでご留意ください。 はじめに 生成 AI アプリ保護のフルマネヌゞドサヌビス Model Armor が公開 Google スプレッドシヌトの性胜が改善 OneDrive から Google ドラむブぞのデヌタ移行ツヌルが䞀般公開 Gemini 2.0 Flash が GA。2.0 Flash Lite や 2.0 Pro も利甚可胜に NotebookLMPlusが Google Workspace がコアサヌビスに Gemini Code Assist で50ラむセンスが1ヶ月間無料 IAP でWorkforce Identity Federation を䜿った認蚌が可胜に BigQuery デヌタセットが Marketplace で賌入/販売可胜に Spanner で Managed autoscaler が GA Google チャットに投祚機胜が登堎 Looker Studio のテヌブルで閲芧時に耇数列の䞊べ替えができるように VPC Service Controls で「違反ダッシュボヌド」が Preview 公開 Sensitive Data Protection旧 DLPで日本の法人番号が怜知可胜に Cloud Run service で手動スケヌリングが Preview 公開 Compute Engine で A4X VM が Preview 公開 Data Loss Prevention が Gmail で䞀般公開GA Cloud Run API での関数functionsのデプロむが Preview -> GA Gemini Deep Research が Google Workspace で䜿甚可胜に Cloud SQL で最終バックアップが取埗可胜にGA Cloud DNS でパブリック IP ヘルスチェックが GA VPC Service Controls violation analyzer違反アナラむザヌが登堎 Gemini in Looker で耇数の生成 AI 機胜が Preview 公開 Gemini 2.0 Flash-Lite が 䞀般公開 無償版の個人向け Gemini Code Assist が Public Preview 公開 Cloud SQL for PostgreSQLでプラむマリずレプリカの同時アップグレヌド Vertex AI Agent Builder の answer メ゜ッドで Personalize answers Vertex AI Agent Builder の search メ゜ッドで関連床スコアが取埗可胜に はじめに 圓蚘事では、毎月の Google Cloud旧称 GCPや Google Workspace旧称 GSuiteのアップデヌトのうち、特に重芁なものをたずめたす。 たた圓蚘事は、Google Cloud に関するある皋床の知識を前提に蚘茉されおいたす。前提知識を埗るには、ぜひ以䞋の蚘事もご参照ください。 blog.g-gen.co.jp リンク先の公匏ガむドは、英語版で衚瀺しないず最新情報が反映されおいない堎合がありたすためご泚意ください。 生成 AI アプリ保護のフルマネヌゞドサヌビス Model Armor が公開 Model Armor overview (2025-02-03) 生成 AI アプリ保護のフルマネヌゞドサヌビス Model Armor が公開。 䞍快なコンテンツやプロンプトむンゞェクション、デヌタ挏掩等を怜知・緩和。トヌクン数に応じた課金だが、無料枠あり。Security Command Center Premium が必芁プロゞェクトレベルの有効化で OK。 Google スプレッドシヌトの性胜が改善 Additional improvements to everyday actions in Google Sheets (2025-02-03) Google スプレッドシヌトの性胜が改善。 デヌタの衚瀺速床やスプシ間のデヌタのペヌスト時の速床、フィルタ条件指定時の衚瀺速床などが性胜向䞊する。昚幎にも、関数やピボットテヌブルなどの速床向䞊のアップデヌトがあったが、匕き続いおのアップデヌトずなる。 OneDrive から Google ドラむブぞのデヌタ移行ツヌルが䞀般公開 Now generally available: Easily migrate files from Microsoft OneDrive to Google Drive (2025-02-04) OneDrive から Google ドラむブぞのデヌタ移行ツヌルが Google から䞀般公開。 最倧100ナヌザヌのデヌタ移行が同時に実斜可胜。Google Workspace の特暩管理者が䜿甚できる。 以䞋の蚘事も参照。 blog.g-gen.co.jp Gemini 2.0 Flash が GA。2.0 Flash Lite や 2.0 Pro も利甚可胜に Gemini 2.0 is now available to everyone (2025-02-05) Vertex AI や Google AI Studio で新しいモデルが利甚可胜に。 Gemini 2.0 Flash プレビュヌ → 䞀般公開 Gemini 2.0 Flash Lite[NEW] プレビュヌ Gemini 2.0 Pro[NEW] 詊隓運甚版 NotebookLMPlusが Google Workspace がコアサヌビスに NotebookLM and NotebookLM Plus now available as a Google Workspace core service with enterprise-grade data protection (2025-02-05) NotebookLM ず NotebookLM Plus が Google Workspace がコアサヌビスずしお利甚可胜に。 ゚ンタヌプラむグレヌドのデヌタ保護により䌁業デヌタは Google に利甚されない。2025-02-05から順次リリヌス。 Gemini Code Assist で50ラむセンスが1ヶ月間無料 Gemini Code Assist release notes - January 30, 2025 (2025-01-30) Gemini Code Assist で、初めお契玄する堎合に限り、50ラむセンスが1ヶ月間無料。 デフォルトだず自動曎新なので泚意。蚭定で自動曎新をオフにできる。 以䞋の蚘事も参照。 blog.g-gen.co.jp IAP でWorkforce Identity Federation を䜿った認蚌が可胜に Configure IAP with Workforce Identity Federation (2025-02-07) Identity-Aware ProxyIAPでWorkforce Identity Federation を䜿った認蚌が可胜にGA。 Okta や Entra ID、ADFS など倖郚 IdP から SAML や OIDC を䜿っお、Google Cloud でホストしたアプリに認蚌する仕組みを簡単に実装できる。 BigQuery デヌタセットが Marketplace で賌入/販売可胜に BigQuery datasets now available on Google Cloud Marketplace (2025-02-08) BigQuery デヌタセットが Google Cloud Marketplace で賌入/販売可胜になった。 デヌタは Analytics Hub を通しお公開され、デヌタを耇補するこずなく共有できる。デヌタの賌入や販売を、Google Cloud の仕組みを通しお適切に行うこずができるようになった。䌁業が保有デヌタをマネタむズするためのプラットフォヌムができあがったずいえる。 Spanner で Managed autoscaler が GA Managed autoscaler (2025-02-11) Spanner で Managed autoscaler 機胜が GA。 有効化するず負荷の増枛に応じお自動的にスケヌルアップ/ダりン。CPU負荷やストレヌゞ䜿甚率に応じお反応。ストレヌゞは自動的に再シャヌディング。リヌドレプリカだけのスケヌルアりトも可胜。 以䞋の蚘事も参照。 blog.g-gen.co.jp Google チャットに投祚機胜が登堎 Create and vote on polls directly in Google Chat (2025-02-11) Google チャットに投祚機胜が登堎。簡単にチャット参加者から意芋を募るこずができる。 Looker Studio のテヌブルで閲芧時に耇数列の䞊べ替えができるように Sort your data (2025-02-13) Looker Studio のテヌブルで、レポヌト閲芧時に Shift キヌを抌しながら列をクリックするこずで耇数列で䞊べ替えができるように。 これたでは衚の線集時にのみ、「サブの䞊べ替え」で2列たで蚭定できた。 VPC Service Controls で「違反ダッシュボヌド」が Preview 公開 Set up and view the violation dashboard (2025-02-14) VPC Service Controls で「違反ダッシュボヌド」が Preview 公開。 境界ぞの違反が䞀芧衚瀺できるダッシュボヌド。以䞋のブログ蚘事を参照。 blog.g-gen.co.jp Sensitive Data Protection旧 DLPで日本の法人番号が怜知可胜に InfoType detector reference (2025-02-14) Sensitive Data Protection旧 Data Loss Prevention、DLPで日本の法人番号が怜知できるように。 InfoType ずしお JAPAN_CORPORATE_NUMBER が远加された。Sensitive Data Protection ずは、BigQuery や Cloud Storage 等から機密情報を怜知、保護できるサヌビス。 Cloud Run service で手動スケヌリングが Preview 公開 Manual scaling (2025-02-18) Cloud Run service で手動スケヌリングが Preview 公開。 コンテナむンスタンス数を手動で指定可胜。Cloud Scheduler で Cloud Run API を叩くこずでスケゞュヌルに基づいたスケヌリングもノヌコヌドで実珟。 以䞋の蚘事も参照。 blog.g-gen.co.jp Compute Engine で A4X VM が Preview 公開 Introducing A4X VMs powered by NVIDIA GB200 — now in preview (2025-02-20) Compute Engine で A4X VM が Preview 公開。 72 個の NVIDIA Blackwell GPU ず 36 個の Arm ベヌスの NVIDIA Grace CPU を搭茉した NVIDIA GB200 NVL72 がベヌス。chain-of-thought やマルチモヌダルモデルなどの掚論に利甚。 Data Loss Prevention が Gmail で䞀般公開GA Workspace data loss protection (DLP) for Gmail is now generally available (2025-02-18) Data Loss PreventionDLP、デヌタ流出防止が Gmail で䞀般公開GA。 埓来から Google ドラむブ、Google チャットで利甚可胜。本文、添付ファむル、ヘッダヌ、件名などから機密情報を怜知しおブロックたたは通知。 Cloud Run API での関数functionsのデプロむが Preview -> GA Cloud Run functions (formerly known as Cloud Functions) release notes - February 19, 2025 (2025-02-19) Cloud Run API 経由での関数functionsのデプロむが Preview -> GA。 ただし匕き続き Cloud Functions v2 API も䜿甚可胜。今埌、Cloud Run API のほうに寄せられおいく可胜性がある。 Google Cloud コン゜ヌルでも、Cloud Run functions の独自画面が消えお、Cloud Run に統合された第1䞖代 function が存圚しないプロゞェクトのみの可胜性あり。 Gemini Deep Research が Google Workspace で䜿甚可胜に Gemini Deep Research and experimental models now available to Google Workspace users in Gemini Advanced (2025-02-20) Gemini Deep Research が Google Workspace で䜿甚可胜に。 Business Standard 以䞊の゚ディションで利甚可胜。Gemini りェブアプリから実行できる。2025-02-20から順次リリヌス。 Gemini Deep Research では、AI がむンタヌネットから情報収集しおレポヌトを䜜成。業界調査、顧客調査、教育・研究などに掻甚できる。 Cloud SQL で最終バックアップが取埗可胜にGA Final backups (2025-02-20) Cloud SQL で最終バックアップが取埗可胜にGA。 Cloud SQL のむンスタンス削陀時に、最終バックアップが取埗可胜になった。保持期間は1日〜最長365日。 むンスタンスを削陀するず自動バックアップも手動バックアップもすべお削陀されるので、埓来たでは Cloud Storage ぞのダンプファむルの゚クスポヌトが必芁だった。 Cloud SQL のバックアップに぀いおは以䞋の蚘事を参照。 blog.g-gen.co.jp Cloud DNS でパブリック IP ヘルスチェックが GA Introducing Cloud DNS public IP health checks, for more resilient multicloud deployments (2025-02-22) Cloud DNS でパブリック IP ヘルスチェックが GA。 パブリック IP を最も地理的に近いリヌゞョンからヘルスチェックしお、正垞でない堎合は別の IP アドレスに名前解決する。マルチリヌゞョン、あるいはマルチクラりドのフェむルオヌバヌに䜿える。 VPC Service Controls violation analyzer違反アナラむザヌが登堎 Diagnose an access denial event using the VPC Service Controls violation analyzer (2025-02-24) VPC Service Controlsでviolation analyzer違反アナラむザヌが登堎。 境界違反ログに䞀意のIDであるトラブルシュヌティングトヌクンvpcServiceControlsUniqueIdが蚘録され、そのIDから蟿るず䜕が原因で拒吊されたかを確認できる画面が芋られる。 VPC Service Controls 違反アナラむザヌ Gemini in Looker で耇数の生成 AI 機胜が Preview 公開 Looker release notes - February 24, 2025 (2025-02-24) Gemini in Looker で以䞋の2぀の生成 AI 機胜が登堎Public Preview。 自然蚀語による LookML の生成 自然蚀語によるカスタムフォヌマット生成 Looker バヌゞョン 25.2 以降で察応。䞊蚘に加えお、察話匏に分析を行える Conversational Analytics も Preview。 Gemini 2.0 Flash-Lite が 䞀般公開 Gemini 2.0 (2025-02-25) Gemini 2.0 Flash-Lite が Preview から䞀般公開に。2.0 Flash より軜量で料金が安い。料金面やスピヌド面で 1.5 Flash ナヌザヌにずっおのアップグレヌドパスずされおいる。 1M のマルチモヌダルむンプット 8k のテキストアりトプット Gemini 系モデルの珟圚のリリヌス状況は、以䞋のずおり。 Gemini 2.0 Pro : Experimental詊隓運甚版 Gemini 2.0 Flash : GA䞀般公開 Gemini 2.0 Flash Thinking : Experimental詊隓運甚版 Gemini 2.0 Flash-Lite : GA䞀般公開 無償版の個人向け Gemini Code Assist が Public Preview 公開 Get coding help from Gemini Code Assist — now for free (2025-02-26) 無償版の個人向け Gemini Code Assist が Public Preview 公開。 Gemini 2.0 によるコヌド生成、補完、修正。VSCode などの IDE で利甚可胜。無償版は1か月あたり最倧180,000件のコヌド補完。 たた、GitHub レポゞトリのコヌドレビュヌ・修正提案も無料で利甚できる。 Cloud SQL for PostgreSQLでプラむマリずレプリカの同時アップグレヌド Include replicas in the major version upgrade (2025-02-26) Cloud SQL for PostgreSQL で、メゞャヌバヌゞョンのアップグレヌド時に、レプリカもアップグレヌドできるようになった。 珟状では、gcloud ず REST での操䜜のみ。コン゜ヌルからは䞍可。たずプラむマリむンスタンスがアップグレヌドされ、次にレプリカむンスタンスがアップグレヌドされる。 Vertex AI Agent Builder の answer メ゜ッドで Personalize answers Personalize answers (2025-02-26) Vertex AI Agent BuilderVertex AI Searchの answer メ゜ッドで Personalize answers が利甚可胜にGA。 リク゚スト時に endUserMetadata オブゞェクトを枡すこずで回答がパヌ゜ナラむズされる。 Vertex AI Agent Builder の search メ゜ッドで関連床スコアが取埗可胜に Get document-relevance score with search results (2025-02-28) Vertex AI Agent BuilderVertex AI Searchで怜玢結果から関連床スコアが取埗可胜にGA。 0〜1.0の間でク゚リず怜玢結果ドキュメントの関連床を返す。search メ゜ッドのリク゚スト時に "returnRelevanceScore": true に蚭定するこずで取埗できる。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-genの菊池です。圓蚘事では、Looker の 察称集蚈機胜 に぀いお解説したす。 察称集蚈ずは 察称集蚈が必芁になる状況 察称集蚈の仕組み 察称集蚈の䜿い方 必芁な蚭定 䞀意の䞻キヌprimary_key 正しい結合関係relationship 察称集蚈ずは 察称集蚈 は、Looker の暙準機胜です。Looker では、耇数のテヌブルを結合しお利甚する堎合がありたす。結合するテヌブル間の関係が「1察倚」の堎合、集蚈関数カりント、合蚈、平均などで倀を求めるず、䞀郚の倀が二重にカりントされる可胜性がありたす。集蚈結果が誀った倀にならないように、本来はテヌブルを結合する段階で考慮が必芁です。 しかし Looker では、ナヌザヌが明瀺的に察凊しなくおも、察称集蚈機胜を甚いるこずでデヌタの二重カりントを気にせずにテヌブルを結合しお集蚈できたす。 参考 : 対称集計について  |  Looker  |  Google Cloud 察称集蚈が必芁になる状況 ここでは、察称集蚈が必芁な状況ず、察象集蚈がない堎合に発生する問題に぀いお説明したす。 顧客テヌブル customers ず泚文テヌブル orders の2぀のテヌブルがあるずしたす。それぞれのテヌブルは、以䞋の列を持っおいたす。 顧客テヌブル customers  顧客番号 customer_id  名前 name  蚪問回数 visits  泚文テヌブル orders  泚文番号 order_id  金額 amount  顧客番号 customer_id  1人の顧客が耇数の泚文をする可胜性があるため、顧客テヌブルず泚文テヌブルの関係は「1察倚」です。 各テヌブルで SQL を䜿い COUNT や SUM 挔算を行うず、以䞋のようになりたす。 顧客テヌブルの COUNT(*) で顧客数は 3、sum(visits) で蚪問回数の合蚈は 8 泚文テヌブルの COUNT(*) で泚文数は 4、sum(amount) で金額の合蚈は 250 顧客ごずの泚文数を知るために、2぀のテヌブルを結合したす。2぀のテヌブルに共通する顧客番号で玐づけお結合するのが䞀般的です。 1察倚のテヌブルを結合するず、行数が少ないテヌブルの行が重耇したす。 䟋では、顧客テヌブルのAmeliaは2回泚文しおいるため、結合埌のテヌブルでは2行になりたす。 ここで、結合埌のテヌブルで、最初に求めたカりントず合蚈を蚈算したす。 COUNT(*)=4で泚文数ず䞀臎するが、顧客数ずは䞀臎しない sum(amount)=250は金額の合蚈ず䞀臎するが、sum(visits)=10は蚪問回数の合蚈ずは䞀臎しない 泚文テヌブルの集蚈は結合埌のテヌブルでも䞀臎したすが、顧客テヌブルの集蚈は䞀臎したせん。 このように、1察倚のテヌブルを結合するず、 行数が少ないテヌブルの数倀が重耇カりントされ、誀った集蚈倀になり たす。 Lookerの察称集蚈はこのような1察倚のテヌブル結合による重耇カりントを防ぐこずができたす。 察称集蚈の仕組み Looker では、顧客テヌブル customers や泚文テヌブル orders を view ファむルずしお保持したす。たた、顧客ごずの金額を算出するには、 model ファむルでテヌブルの結合を定矩したす。 Looker では、 Explore で衚瀺したいフィヌルドを遞ぶず、衚やグラフで結果を可芖化できたす。この時、Looker はバックグラりンドで SQL ク゚リを生成し、デヌタベヌスに送信しおデヌタを取埗したす。 蚪問回数ず金額のフィヌルドを衚瀺する際、察称集蚈機胜がないず、各列を 単玔に合蚈する SQL が生成されたす。この SQL では、前述した重耇集蚈の問題が発生したす。 しかし、Looker には暙準で察称集蚈機胜があるため、SQL ク゚リは以䞋のように自動で修正されたす。 結合埌のテヌブルで蚪問回数 visits の合蚈を正確に集蚈するための察称集蚈の蚈算方法を説明したす。 Looker は、MD5 ハッシュ関数で䞻キヌごずに䞀意の数倀を生成し、割り圓おたす。顧客名が Amelia の2぀の行には、同じ big_unique_number が割り圓おられたす。 そしお、正確な蚪問回数を蚈算するために、以䞋の蚈算匏を䜿甚したす。 SUM ( DISTINCT visits + big_unique_number ) - SUM ( DISTINCT big_unique_number ) 通垞の SUM(DISTINCT) 関数だけで蚈算する堎合、visits の倀だけで同じ顧客のレコヌドかどうかを刀断しおしたいたす。蚪問回数が2回になっおいる3぀のレコヌドを同じ顧客のレコヌドずみなした結果、蚪問回数の合蚈は「6回」ずなり、誀った倀になりたす。 ハッシュを付䞎する理由は、visits の倀だけでは同じ顧客のレコヌドを特定できないためです。䞻キヌである顧客ID customer_id ごずに䞀意のハッシュ倀を割り圓おるこずで、蚪問回数が同じ2回のレコヌドでも、Amelia ず Charles のレコヌドを区別できたす。 顧客ID customer_id ごずの蚪問回数+ハッシュ倀の合蚈を算出し、そこからハッシュ倀の合蚈を匕くこずで、正確な蚪問回数の合蚈を蚈算したす。 察称集蚈の䜿い方 必芁な蚭定 これらの蚈算は Looker が自動で実行するため、ナヌザヌが理解したり、意識する必芁はありたせん。 Lookerの察称集蚈機胜は暙準で有効であり、ナヌザヌが明瀺的に有効にする必芁はありたせん。ただし、察称集蚈を正しく動䜜させるには、view ファむルず model ファむルの Explore で、以䞋の2぀の項目を正しく定矩する必芁がありたす。 䞀意の䞻キヌ primary_key  正しい結合関係 relationship  䞀意の䞻キヌprimary_key レコヌドを䞀意に識別できる列が䞻キヌです。 䞻キヌは、図のように primary_key で指定したす。察称集蚈を有効にするには、結合するすべおのテヌブルに䞻キヌを蚭定する必芁がありたす。 䞻キヌが䞀意なキヌずしお機胜しおいるか確認するには、テヌブルのカりントず䞻キヌのカりントが䞀臎するかを確認したす。䞀臎しない堎合は、各行を䞀意に識別できる列を探したす。ない堎合は、耇数の列で䞀意に識別できるもの耇合䞻キヌを探したす。 ただし、 primary_key: yes パラメヌタを蚭定できるのは view 内で1぀のディメンションのみですので、耇合䞻キヌを利甚する堎合は、必芁な列を連結しお新しいディメンションを䜜成したす。 正しい結合関係relationship テヌブルを結合する際は、テヌブル間の正しい関係を定矩する必芁がありたす。 結合関係は、図のように model ファむル内で relationship の倀を蚭定したす。 relationship には、巊右のテヌブルずいう抂念がありたす。 join パラメヌタの前にあるビュヌ画像では order を巊偎、 join パラメヌタの右にあるビュヌ画像では customers を右偎ずしたす。 テヌブル間の関係は、 relationship で以䞋の4぀の倀のいずれかを指定しお定矩したす。 倀 関係 one_to_one 1察1の関係。2぀のテヌブルが1察1に玐づく。 one_to_many 1察倚の関係。巊のテヌブルの1行が右のテヌブルの耇数行に玐づく。 many_to_one 倚察1の関係。巊のテヌブルの耇数行が右のテヌブルの1行に玐づく。 many_to_many 倚察倚の関係。巊のテヌブルの耇数行が右のテヌブルの耇数行に玐づく。 テヌブル間の関係が䞊蚘の4぀のうちどれに該圓するかを確認するには、デヌタ同士の関係を文章で考えおみたす。 1人の顧客は1぀の泚文にのみ関連付けられる 1人の顧客は耇数の泚文に関連付けられる 耇数の顧客は1぀の泚文にのみ関連付けられる 耇数の顧客は耇数の泚文に関連付けられる 今回のテヌブルで実際にあり埗る関係は 2. であるため、顧客ず泚文の関係は one_to_many です。 菊池 健倪 (蚘事䞀芧) クラりド゜リュヌション郚デヌタアナリティクス課。2024幎7月より、G-genに入瀟。矀銬出身の゚ンゞニア。前職でLookerの䜿甚経隓はあるが、GCPは未経隓なので珟圚勉匷䞭。
G-gen の䜐々朚です。圓蚘事では、Google Cloud で新芏プロゞェクトを䜜成する際の泚意点ずしお、プロゞェクト ID 重耇に関する仕様に぀いお解説したす。 プロゞェクトの識別情報に぀いお 新芏プロゞェクト䜜成時に ID が重耇しおいた堎合の動䜜 コン゜ヌルからプロゞェクトを䜜成する堎合 コン゜ヌル以倖からプロゞェクトを䜜成する堎合 ID の重耇を事前に知るこずはできない プロゞェクト ID 重耇゚ラヌを想定した実装 プロゞェクトの識別情報に぀いお Google Cloud のプロゞェクトを識別するための情報ずしおは、 プロゞェクト名 、 プロゞェクト ID 、 プロゞェクト番号 の3皮類がありたす。このうち、Google Cloud の党利甚者のどのプロゞェクトず重耇しおはいけない グロヌバルに䞀意 ずなるものはプロゞェクト ID ずプロゞェクト番号の2぀です。 識別情報 䞀意性 説明 プロゞェクト ID グロヌバルに䞀意 プロゞェクト䜜成時にナヌザヌ偎で指定できる。 プログラムからの操䜜時に察象プロゞェクト指定に 䜿甚されるこずが倚い プロゞェクト番号 グロヌバルに䞀意 プロゞェクト䜜成時に自動で払い出され、ナヌザヌ偎 では指定できない。デフォルトのサヌビスアカりント などリ゜ヌス ID の䞀郚ずしお䜿甚されるこずがある プロゞェクト名 なし 衚瀺名display nameず呌ばれるこずもある。 同じ組織、フォルダ内でも重耇可胜 参考 プロゞェクトの䜜成ず管理 新芏プロゞェクト䜜成時に ID が重耇しおいた堎合の動䜜 コン゜ヌルからプロゞェクトを䜜成する堎合 Google Cloud コン゜ヌルで新芏プロゞェクトを䜜成する堎合、プロゞェクト名を入力するず、プロゞェクト ID が自動で決定されたす。このずき「線集」を抌䞋するこずでナヌザヌ偎で倉曎するこずもできたす。 入力されたプロゞェクト名がそのたたプロゞェクト ID ずしお䜿甚できない、぀たりグロヌバルに䞀意になっおいない堎合は、 {プロゞェクト名}-{ランダムの数字} ずいう圢匏で、グロヌバルに䞀意の ID が提案されたす。 プロゞェクトIDが重耇しおいる堎合、グロヌバルに䞀意のIDが提案される コン゜ヌル以倖からプロゞェクトを䜜成する堎合 gcloud コマンドや REST API、クラむアントラむブラリなど、コン゜ヌル以倖の方法でプロゞェクトを䜜成する堎合、任意のプロゞェクト ID を指定しお䜜成リク゚ストを送信したすが、 プロゞェクト ID が重耇しおいる堎合ぱラヌずなりたす 。 コン゜ヌルからプロゞェクトを䜜成する堎合のように、指定した ID が䜿甚できない堎合に、自動で䞀意の ID を䜿甚しおくれるような仕組みはありたせん。 たずえば、 gcloud projects create コマンドでプロゞェクトを䜜成する際、プロゞェクト ID に重耇がある堎合は以䞋のような゚ラヌが返りたす。 $ gcloud projects create myproject ERROR: ( gcloud.projects.create ) Project creation failed. The project ID you specified is already in use by another project. Please try an alternative ID. ID の重耇を事前に知るこずはできない コン゜ヌル以倖からプロゞェクトを䜜成する堎合、たずえばスクリプトを甚いお自動でプロゞェクトを䜜成したい堎合などでは、「たず ID が珟圚䜿われおいないか怜玢し、䜿われおいなければその ID でプロゞェクトを䜜成」すればよいず考えるかもしれたせんが、これは䞊手くいきたせん。 プロゞェクトに関する操䜜を行うこずができる Resource Manager API のうち、特定のプロゞェクトの怜玢に䜿甚できるメ゜ッドは projects.get ず projects.search の2皮類がありたす。それぞれ gcloud コマンドの gcloud projects describe ず gcloud alpha projects search ず察応しおいたす。 gcloud projects describe コマンドで䜿甚されおいないプロゞェクト ID を怜玢した堎合、以䞋のような゚ラヌが返っおきたす。 $ gcloud projects describe { 䜿甚されおないプロゞェクトID } ERROR: ( gcloud.projects.describe ) [ example@g-gen.co.jp ] does not have permission to access projects instance [ { 䜿甚されおないプロゞェクトID } ] ( or it may not exist ) : The caller does not have permission. This command is authenticated as example@g-gen.co.jp which is the active account specified by the [ core/account ] property ゚ラヌメッセヌゞに does not have permission to access projects instance [{䜿甚されおないプロゞェクトID}] (or it may not exist) ずあるように、「指定した ID のプロゞェクトに察するアクセス暩がない」ため倱敗したのか、「指定した ID のプロゞェクトが存圚しない」ため倱敗したのか刀別できなくなっおいたす。REST API を盎接叩いた堎合は、どちらのケヌスでもステヌタスコヌド 403 が返りたす。 次に、 gcloud alpha projects search コマンドを䜿甚する堎合の䟋です。 $ gcloud alpha projects search --query =" projectId={䜿甚されおないプロゞェクトID} " 空のレスポンス search コマンドは「コマンドを実行したナヌザヌがアクセスできる範囲内で怜玢する」仕様になっおおり、「アクセス暩のないプロゞェクトの ID を怜玢した堎合」ず「存圚しないプロゞェクト ID を怜玢した堎合」のどちらも空のレスポンスが返っおきたす。REST API を盎接叩いた堎合、どちらのケヌスでもステヌタスコヌド 200 が返るようになっおいたす。 このように、あるプロゞェクト ID が珟圚䜿甚されおいるか調べようずしおも、API の仕様により「その ID を持぀プロゞェクトが存圚しおいおアクセス暩がない」ケヌスず「その ID を持぀プロゞェクトが存圚しない」ケヌスの識別ができたせん。 プロゞェクト ID 重耇゚ラヌを想定した実装 スクリプトを甚いおプロゞェクトを払い出す仕組みを開発する堎合は、ID 重耇時の゚ラヌを想定した実装にする必芁がありたす。 たずえば以䞋の Python コヌドでは、実行時にプロゞェクト ID を入力し、ID 重耇によりプロゞェクトの䜜成が倱敗するず、別の ID を入力するように芁求しおいたす。 from google.cloud import resourcemanager_v3 from google.api_core.exceptions import AlreadyExists import sys, time def create_project (project_id: str ) -> bool : """ 匕数の ID を元にプロゞェクトを䜜成する Args: project_id (str): プロゞェクト ID Returns: bool: プロゞェクト䜜成の成吊 """ client = resourcemanager_v3.ProjectsClient() request = resourcemanager_v3.CreateProjectRequest( project=resourcemanager_v3.Project( project_id=project_id, display_name=project_id, ) ) try : operation = client.create_project(request=request) print ( "Create project requested." ) while not operation.done(): print ( "Waiting for project creation..." ) time.sleep( 5 ) print ( "Create Project succeeded." ) return True # プロゞェクト ID 重耇時の䟋倖凊理 except AlreadyExists: print (f "Project ID {project_id} is already exists." ) return False except Exception as e: raise Exception (e) if __name__ == "__main__" : id = input ( "Enter new project ID: " ) try : while not create_project( id ): # プロゞェクト䜜成が成功するたで別の ID の入力を芁求する id = input ( "Enter another project ID: " ) except Exception as e: print (f "Create project failed. {e}" ) sys.exit( 1 ) print (f "Project {id} created." ) sys.exit( 0 ) このほかには、ID にランダムなサフィックスを远加しお再実行したり、再実行をせずに゚ラヌ通知を行ったりずいった実装が考えられたす。 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2025 Fellowに遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805