「BigQuery最適化、もう試した?休眠アカウント、放置してない?」~【googlecloud】人気記事TOP5(2025/08/31)
【2025/8/31】「BigQuery最適化、もう試した?休眠アカウント、放置してない?」人気記事TOP5(2025/08/31)
クエリそのままパフォーマンスを改善 BigQuery パフォーマンス向上テクニック
BigQueryのクエリパフォーマンスを向上させるための4つの機能を紹介。
- Advanced Runtime: 設定一つで有効になり、拡張ベクトル化や小規模クエリ最適化によりパフォーマンスが大幅に向上。
- History based optimization: 過去のクエリ履歴を元に結合順序や並列度を最適化。
- Optional Job Creation Mode: 小規模クエリのジョブ作成オーバーヘッドを削減しレイテンシを短縮。
- CMETA: データの読み取りを効率化するメタデータ管理機能。
これらの機能はデフォルトで有効になる予定であり、BigQueryは常に改善されている。
マルチプロダクト構成を支える KANNA のインフラアーキテクチャ
KANNAのインフラアーキテクチャは、AWSを中心にGCPを補完的に活用したハイブリッド構成。ECS on Fargateによるコンテナオーケストレーション、Blue/Greenデプロイ、Aurora/PostgreSQLによるデータストア戦略を採用し、Datadogでモニタリング。GitHub ActionsでCI/CDを自動化、TerraformでIaCを実現。セキュリティ対策も多層的に実施。コスト最適化としてFargate Spot/ARM、VPC Endpoint、AutoScaling、RI/Savings Planを活用。今後はALB間通信の内部化、データレイク整備、グローバルリージョン展開を検討。
Google Cloud で休眠状態のサービスアカウントを見つける
Google Cloudで増えがちなサービスアカウントの管理に関する記事です。単一目的のサービスアカウントが増加する状況に対し、休眠アカウントを定期的に見つける重要性を指摘。gcloud policy-intelligence query-activity
コマンドによる利用状況の確認方法を紹介しています。発見された休眠アカウントの例として、廃止された社内サービス用、Terraform実行用、設定ミスのアカウントを挙げ、セキュリティリスクに繋がる点を強調。サービスアカウントの命名規則策定など、管理のベストプラクティスも推奨しています。
【Next Tokyo 25 レポート】Expo で最新技術を体験してきた
Google Cloud Next Tokyo '25のExpoで、Google CloudのAI活用事例を体験したレポート。特に印象的だったのは、エッジ環境向けのインフラ「Google Distributed Cloud (GDC)」、AIを活用したバーチャル試着「Virtual Try-On」、AI対話型買い物アシスタント「Shopper Concierge」。GDCはデータ主権や低遅延処理に貢献し、Virtual Try-OnはECサイトの返品率削減、Shopper Conciergeは顧客に寄り添ったショッピング体験を提供する。AIとインフラが企業変革を支える未来を感じさせる内容だった。
ミニマムかつ未来を見据えたGoogle Cloudアーキテクチャ
Cloud RunとSQLiteを活用し、低コストでスケーラブルなGoogle Cloudアーキテクチャを提案。
Cloud Runのドメインマッピングでロードバランサー費用を削減し、SQLiteをCloud Storageに保存することでDBコストを抑制。
初期は低コストだが、要件に応じてCloud SQLへのDB移行、Cloud Runのスケーリング、フロントエンド分離など柔軟な拡張が可能。
バックエンドAPIを重視し、技術スタックの変更にも対応しやすい構成を目指す。
初期コストを抑えつつ、将来的なスケーラビリティを確保するMVPに最適なアーキテクチャ。
【2025/8/24】「Google Cloud、次の一手は「生成AI/LLMOps」?」人気記事TOP5(2025/08/24)
Virtual Try-On APIをPythonで試す方法
GoogleのVirtual Try-On APIをPythonで試す方法を紹介。リポジトリをクローンし、環境変数を設定後、main.py
を実行することで、人物画像と服装画像を指定して仮想着せ替え画像を生成できる。APIのパラメータ(人物フィルタリング、安全フィルタリング、出力形式等)も調整可能。アニメ画像にも対応。詳細はGitHubリポジトリ参照。
可用性、冗長性を考慮したGoogle Cloudのインフラ構築の考え方
この記事では、Google Cloud Platform (GCP) を用いたWebサービスのインフラ構築における可用性と冗長性の考え方を解説しています。SLA 99.9% を目標に、Cloud Run と Cloud SQL を例に、冗長構成(複数サービス、HA構成)と災害対策(マルチリージョン展開、クロスリージョンレプリカ)を検討。可用性確保にはCloud Runの複数サービス構成、Cloud SQLのHA構成が有効であると結論づけました。また、リージョン障害に備え、Cloud Runのマルチリージョン展開とCloud SQLのクロスリージョンレプリカ構成を推奨しています。
Google Cloudで検索基盤を作ろうとして迷ったら(Vertex AI Serach,Vertex AI Vector Search)
Google Cloud での検索基盤構築時に、Vertex AI Search と Vertex AI Vector Search の選択で迷うケースについて解説。Vertex AI Search はフルマネージドな検索基盤で手軽に試せるが、名称変更が頻繁な点に注意。Vertex AI Vector Search はベクトル検索向けだが、VM マシンタイプによりコストが大きく変動する。全文検索には Vertex AI Search、ベクトル検索には Vertex AI Vector Search が推奨。BigQuery での検索や Elastic Cloud Serverless も選択肢。
Gemma3 270M がでたらしいのでスペックを見てみる
Gemma3 270MをローカルとCloud Runで検証。ローカル環境(M3 MacBook Pro)で問題なく動作し、Cloud RunのGPU NVIDIA L4 1台で簡単な文章を200ms程度で返却可能。Dockerで公開されており、ollamaを利用した感情分析やXML-JSON変換タスクも実行可能。Cloud Runにデプロイし、k6sで性能テストを実施した結果、CPUやGPU使用率は低いまま、同時リクエスト数100程度まで対応可能。小規模タスクに最適で、容易に組み込める点が魅力。
【生成 AI 時代の LLMOps】モデル マイグレーション編
この記事では、生成AIモデルのアップデートに伴うモデルマイグレーションの必要性と、その効率化に役立つGoogle Cloudの「Prompt Optimizer」を紹介しています。
モデルのライフサイクルを考慮し、モデルアップデートに対応するために、Prompt Optimizerを利用して既存のプロンプトを新しいモデルに適応させることができます。Prompt Optimizerは、少量のデータセットでプロンプトを最適化し、評価指標と言語を設定することで、新モデルでも同等の生成結果を得られるようにします。これにより、ゼロからプロンプトエンジニアリングを行う手間を省き、効率的なモデル移行を実現します。
【2025/8/17】「Google Cloudでマルチエージェント開発、始めない理由はある?」人気記事(2025/08/17)
マルチエージェントシステムのアーキテクチャーを紐解く
Google Cloud Next Tokyoのデモで反響の大きかったマルチエージェントシステム構築について、ADKを用いた実装例を基にアーキテクチャ設計の基本を紹介。記事作成業務を例に、リサーチ、ライター、レビューのエージェントを役割ごとに分割し、さらに作業ステップで再分割する設計を解説。
実装例として、各エージェントを定義し、Sequential Agentで連携、Root Agentで制御する構成を紹介。リモートエージェント構成やA2Aプロトコルについても触れ、LLMの出力内容を他のLLMに評価させるフィードバック方式の有効性を示唆。
A2A リモートエージェント対応のマルチエージェントシステム
この記事では、Google CloudのAgent Development Kit(ADK)とA2A SDKを用いて、リモートエージェントを活用したマルチエージェントシステム構築の手順を解説。
記事作成業務を例に、調査、執筆、レビューを行う4つのエージェントをAgent Engineにデプロイし、各エージェントへのA2AサーバーをCloud Runに構築。
プロキシーエージェントを定義し、リモートエージェントを呼び出すコールバック関数を実装し、セッション情報を共有。
Sequential Agentで業務フローを構築し、記事作成を自動化。
ADKとAgent EngineのA2A対応は開発が急速に進んでいるため、アーキテクチャの理解を優先すべきと結論。
Agentspace を使用したエージェント開発
AgentspaceはGoogle Cloudのエージェント開発プラットフォームであり、Custom Agent(Agent Engine)を登録して機能を拡張できます。2025年7月にGAとなりました。Custom AgentはCLIを使用して登録し、特定のタスクやデータソースに特化できます。登録にはconfig.json
の設定が必要です。登録されたAgent EngineはAgentspaceの機能を拡張し、特定のタスクに特化したエージェントを迅速に提供できます。AIエージェント開発では、非決定論的な挙動を理解し制御することが重要です。
Rust × WebAssembly(Wasm) × Edge処理 Google Cloudで「サービス拡張」を試してみた
Google Cloudの「サービス拡張」を利用し、RustとWebAssembly(Wasm)で簡易Basic認証をEdge処理として実装。Proxy-Wasmのサンプルコードを参考に、Authorizationヘッダーのチェックを行い、認証成功時はヘッダーを削除、失敗時は401エラーを返す。WasmはDockerでラップしArtifact Registryにアップロード後、ロードバランサーに適用。Rustはコンパイルチェックが強力だが、Wasm起因のエラーは解読が難しい場合がある。Proxy-Wasmはサンプルが豊富で、リダイレクトやOGP画像設定も可能。Google Cloudのサービス拡張はEdge処理を容易にするが、反映にタイムラグがある点が課題。
Cloud Run Worker Pools で Redash をサーバーレス化する
Cloud Run Worker Poolsを利用してRedashをサーバーレス化する手順を解説。ValkeyとPostgreSQLをデータベースに構築し、Cloud RunでRedashのServer、Worker、Schedulerをデプロイ。Workerは処理キューに応じて分割。BigQuery/Cloud SQLへの接続、Google OAuth、Sendgridによるメール設定も行う。これにより、Redashのようなバックグラウンドジョブが多いアプリもCloud Runで運用可能に。
【2025/8/13】「Cloud Run x Gemini CLI、サーバーレスの未来が見えた?」人気記事(2025/08/13)
【最新】GitHub ActionsでGemini CLIを活用してみよう
Gemini CLI GitHub ActionsがGoogleからベータ公開。これは、ターミナル向けAIエージェントGemini CLIをGitHub Actionsから利用し、Issueのラベル付け、PRレビュー、タスク委譲などを自動化するものです。個人はAI Studioの無料枠、エンタープライズはVertex AIで利用可能。導入はgemini /setup-github
コマンドで、サンプルワークフローをカスタマイズします。今後は画像生成やドキュメント自動化など、機能拡張が予定されています。
Google Cloud Next Tokyo '25 の Developer Stage が熱い!
Google Cloud Next Tokyo '25のDeveloper Stageでは、Cloud RunとGKEの使い分け、CI/CDにおけるオブザーバビリティ、Cloud RunでのLLM/MCPサーバー運用とセキュリティ、Telemetry APIによるGoogle Cloud ObservabilityとOpenTelemetryの活用、そしてEval-Centric AIによるAgent開発のベストプラクティスが議論されました。特に、Cloud Run worker poolsの活用、CI/CDへのオブザーバビリティ適用、生成AIアプリケーションのセキュリティ対策、そして継続的な評価によるAI開発改善が重要視されました。
Agent Development Kit 1.10.0 で追加された ツールの並列実行
GoogleのAgent Development Kit (ADK) 1.10.0で、ツールの並列実行がサポートされました。従来のADKではツールが順次実行されていたため、処理に時間がかかっていましたが、今回のアップデートで複数のツールを同時に実行できるようになり、処理時間が大幅に短縮されます。
利用には、ツール関数をasync関数で作成することと、プロンプトでLLMに並列実行を指示することが重要です。これにより、Agentの応答速度が向上し、ユーザーエクスペリエンスの改善に繋がります。
【Private Preview】Docker ComposeからCloud Runへ直接デプロイする新機能を検証してみた
Cloud Runの新機能「gcloud alpha run compose up」は、Docker ComposeからCloud Runへ直接デプロイを可能にする。従来はDockerイメージのビルド・プッシュが必要だったが、この機能によりcompose.yaml
からワンコマンドでデプロイ可能。
検証では、3コンテナ(Frontend, API, Redis)構成のWebアプリケーションを使用。CPU/メモリ設定の制約やコンテナ名の不一致などの問題も発生したが、解決策も提示。
内部ではcompose.yaml
をKnative Service YAMLに変換、Cloud BuildでイメージをビルドしArtifact Registryにプッシュしている。開発効率の向上に繋がる一方、Docker Composeの互換性や設定制御に制限がある。
Cloud Run Worker Pools で Redash をサーバーレス化する
Cloud Run Worker Poolsを活用し、Redashをサーバーレス化する手法を紹介。ValkeyとPostgreSQLでデータベースを構築し、Cloud RunでRedashのServer、Worker、Schedulerをデプロイ。Workerは役割別に分割。BigQuery、Cloud SQLとの連携、Google OAuth認証、Sendgridによるメール設定も実施。GKEやGCEが必要だったRedashのようなバックグラウンドジョブ処理を、Cloud Runで実現可能にした。
Discussion