「Cloud DNS、Analytics Hub、OpenTelemetryの進化に乗り遅れるな！」～【googlecloud】人気記事

この記事はZennからgooglecloudのLike数が多い記事のリストを自動的取得し、AIを利用して要約し、自動更新されています。

「Cloud DNS、Analytics Hub、OpenTelemetryの進化に乗り遅れるな！」人気記事

Google Cloudの名前解決機能解説！〜内部DNSからCloud DNSまで〜

Google Cloudにおける名前解決は、デフォルトの「内部DNS」とマネージドサービス「Cloud DNS」を適切に使い分けることが重要です。内部DNSはVPC内のVM間通信を自動で行いますが、カスタマイズ性は限定的です。

Cloud DNSは、インターネット公開用の「一般公開ゾーン」、VPC内での独自ドメイン利用に最適な「限定公開ゾーン」、複数VPC連携の「DNSピアリング」、そしてハイブリッド環境でオンプレミスとの連携を可能にする「転送ゾーン」と「受信サーバーポリシー」を提供します。これらを要件に応じて選択することで、柔軟でセキュアな名前解決設計が実現できます。

BigQuery Analytics Hubのデータクリーンルーム、チョット理解した

BigQuery Analytics Hubのデータクリーンルームについて、パブリッシャーとサブスクライバー双方の手順、権限設定、分析ルール（重複リスト等）、使用状況確認方法を解説。クリーンルームはセキュアなデータ共有手段であり、分析ルールでクエリ制限が可能。ただし、クエリ内容の監査は現状不可。クエリテンプレート機能はPreview段階で課題が多い。

Claude Codeなどに非公開のGoogle Spreadsheet/Docsをコンテキストとして楽にいれる

gcloud CLI を使用して、アクセス権のある Google Spreadsheet/Docs を CLI から取得する方法が解説されています。SpreadsheetはCSV形式、DocsはMarkdown/HTML形式でエクスポート可能で、LLMへのコンテキスト入力などに活用できます。手順として、gcloud CLIのインストール、Googleアカウントログイン、プロジェクト作成・設定、Driveアクセス権付与を経て、curlコマンドで各ファイルを取得します。

【クラウドセキュリティ】小規模チームが「明日からできる」最低限のAWS/GCP対策

小規模チーム向けのAWS/GCP最低限のクラウドセキュリティ対策として、ID管理（MFA強制）、ネットワーク（不要なポート閉鎖）、可視化（操作ログ有効化）、予算アラート設定が推奨される。これらは攻撃の侵入経路を塞ぎ、侵入後の被害拡大を防ぐために効果的で、コストもほぼかからず短時間で設定可能。完璧より「鍵をかける」ことから始めるべきという結論。

Cloud RunスケールアウトでPoints must be written in orderが出てメトリクス欠落した話

Cloud RunでOpenTelemetry Collectorを使用する際、負荷増加時にメトリクスが欠落する「Points must be written in order」エラーが発生。原因はCollectorの resourcedetection(gcp) 設定漏れで、インスタンス毎のホスト情報がメトリクスに付与されず、時系列のズレが生じたため。Collectorの設定に resourcedetection(gcp) を追加することで解決した。

「Gemini API入力コスト90%減！設定術。」今週の人気記事TOP5（2026/01/18）

【実例あり】Gemini APIの料金が高い？Context Cachingで入力コスト90%削減する方法

Gemini APIの利用コストが高い場合、Context Caching機能で入力コストを最大90%削減できます。これは、毎回同じシステムプロンプトなどの共通部分をキャッシュし、その部分の課金を大幅に割引する仕組みです。暗黙的キャッシュは設定不要で自動的に機能し、明示的キャッシュは有効期限などを設定できます。ただし、キャッシュ作成にはモデルごとの最小トークン数制限があり、共通部分はプロンプトの先頭に配置する必要があります。

Google Cloud の Billing Account の監査ログを設定する

Google CloudのBilling Account監査ログは、CLIからのみ設定・確認が可能。ADMIN_WRITEログでも、操作によってはBilling Account側ではなくプロジェクト側のログとして出力され、プロジェクト側の権限がないと確認できない場合がある。意図しないBilling Accountの活用を防ぐには、組織でのプロジェクト管理や権限付与のベストプラクティス遵守が重要。

Google AntigravityでYouTubeっぽいライブ配信サービスを作ってみた

Google CloudのLive Stream APIとNext.js等を用いて、チャット機能付きYouTube風ライブ配信アプリをGoogle Antigravityで開発。配信側はLive Stream API、視聴側はNext.js/React、Node.js/Socket.IO、Nginxの3コンテナ構成でCloud Runにデプロイ。OBSから配信し、リアルタイム視聴とチャットが可能。費用はLive Stream API中心で約1,145円。LLMによる迅速なUI生成も実証。

(GCPログエクスプローラ) ログ調査は突然に

GCPログエクスプローラーを活用し、Cloud Runのログ調査を爆速で行うための記事。
Cloud Runのログはリクエストログとコンテナログの2種類。
ログエクスプローラーでは、クエリペインでブール演算子や比較演算子を用いた検索、GUI機能（フィールドのワンクリック追加、時間絞り込み、前後ログ表示）の活用が鍵。
実践例では、時間・ユーザーID・エラーレベルで絞り込み、前後ログでコンテキストを把握する手順を紹介。
これらのテクニックで、突然のログ調査に迅速かつ的確に対応可能となる。

Google Cloud 公式 Calculator が多機能すぎるので、「無料枠に収まるか」だけ即答する計算機を自作した話

GCPの公式Calculatorは多機能すぎるため、個人開発で「無料枠に収まるか」だけ即答する簡易コスト計算機をNext.jsとFirebaseで自作。vCPU、メモリ、リクエスト数、処理時間のみ入力し、Cloud RunのAlways Free枠を自動差し引き、無料なら「¥0 (無料枠内です 🎉)」と表示。SRE視点で運用コスト最小化とパフォーマンスにこだわり、GitHub ActionsでCI/CDも構築。4時間で開発・デプロイ完了。

「生成AI、資格取得がプロジェクト推進の共通言語。」今週の人気記事TOP5（2026/01/11）

AWSコンテナ環境からGoogle CloudへWorkload Identity Federationで接続する

AWSコンテナ環境（App Runner等）からGoogle CloudへWorkload Identity Federationで接続するには、EC2とは異なるカスタム実装が必要です。具体的には、google-auth-libraryのAwsSecurityCredentialsSupplierインターフェースを実装し、@aws-sdk/credential-providersのfromNodeProviderChainを利用してAWS認証情報を取得します。これにより、コンテナ環境でもセキュアにGoogle Cloudリソース（例: BigQuery）へアクセス可能になります。

Blog series Google Cloud セキュアな土台作り: 番外編2

本記事は、Google Cloudにおけるサーバーレスサービス（Cloud Run等）とVPCの連携について、ネットワークエンドポイントグループ（NEG）とロードバランサを軸に解説します。

Serverless NEGを用いてロードバランサ（External/Internal ALB）とサーバーレスサービスを連携させる方法、サーバーレスからVPC内リソースへの接続にDirect VPC Egress（推奨）やVPC Connectorを使用する方法、さらにIngress設定、IAM、Cloud Armor、IAPによる多層防御・セキュリティ設計について、具体的なgcloudコマンド例と共に実践的に解説しています。

生成AI資格、何から学ぶ？日本語対応したGoogle Cloud認定「Generative AI Leader」を推す理由と学習方法

Google Cloud認定「Generative AI Leader」は、生成AIの基礎知識、Google Cloudの関連サービス、モデル出力改善手法、ビジネス戦略までを網羅する資格です。事業会社エンジニアにとって、プロジェクト推進の共通言語・判断基準の獲得や、最適なサービス選定解像度向上に繋がるメリットがあります。学習は公式ガイド、Google Skills、NotebookLM、模擬試験、Udemyでの演習が推奨されます。日本語訳のクセや最新技術のキャッチアップが必要な点に注意が必要です。

ADK × BigQuery MCP × Metabaseで作る自然言語データ分析エージェント

Unipos Tech Blogの記事では、Vertex AI Agent Development Kit (ADK) と BigQuery MCP、Metabase を連携させ、自然言語での指示（例：「過去30日間の商品カテゴリ別売上を棒グラフで見せて」）だけで BigQuery からデータを取得し、Metabase で自動的にダッシュボードを作成するエージェントを構築した事例を紹介しています。

このシステムは、Gemini 3 Flash Preview を利用してユーザーの意図を解釈し、BigQuery MCP でデータ取得、Metabase API で可視化を行い、生成されたダッシュボードのURLを返却します。

MCP の導入により、データソースの追加が容易になり、非エンジニアでもデータにアクセスしやすくなることで、組織全体のデータリテラシー向上と意思決定のスピードアップに貢献するとしています。

【Vertex AI】Gemini 2.0 Flash / Flash-Lite は 2026-03-03 に廃止。やるべき移行ポイント

Vertex AIのGemini 2.0 Flash/Flash-Liteは2026年3月3日に廃止されます。gemini-2.5-flash-preview-09-2025は2026年1月15日に廃止。移行先は安定版のGemini 2.5系（gemini-2.5-flash、gemini-2.5-flash-lite）が推奨され、新機能検証ならGemini 3.0 Flash Previewも選択肢。対応策として、まずモデルIDの棚卸しとコード・設定のモデル名変更、環境変数等でのモデルID管理、リージョン・料金・プロビジョンドスループット（PT）の確認が重要です。

「GeminiコンテキストキャッシュがLLMコストを劇的に変える。」人気記事TOP5（2026/01/04）

Google Antigravityで作る初めての暗号資産bot

TypeScript、Bun、Hono、Terraformを用いて、Hyperliquid取引所のFunding Rate異常を検知しTelegramに通知する暗号資産Botを328行で実装。AI開発ツール「Antigravity」を活用し、API連携、閾値チェック、リッチな通知、環境変数管理、インフラ自動化を実現。GCP Cloud Runへデプロイすることで月額0円運用も可能。モダンスタックと関心の分離により、シンプルかつ保守性の高いコードベースを構築。

A2A での認証認可を理解する

A2A (Agent2Agent Protocol) における認証認可について、Linux Foundation傘下のAIエージェント間通信仕様に基づき解説。AgentCardのsecuritySchemesで認証方式を定義し、securityで権限を示す。Google IDとOIDCを利用した認証フローの実装例や、Google Cloud ADKを用いた認証付きA2A通信の実装方法、特にa2a_request_meta_providerとbefore_agent_callbackによる認証トークン連携について詳述。ADKでの直接的なsecuritySchemesサポートは未実装のため、現時点での回避策が示されている。

【生成 AI 時代の LLMOps】モデル評価編

Google Cloud Vertex AI は、LLMOps のモデル評価を効率化する。ルーブリックベースでは、評価用モデルで指示への適合性を判断し、データセット不要で迅速な評価が可能。計算ベースでは、ROUGEやBLEUなどの標準指標や、JSONスキーマ検証・構造化データ抽出精度のカスタムメトリックで、応答と参照データとのギャップを定量化する。Vertex AI Experiments に結果が集約され、複数ジョブ比較による最適なモデル・パラメータ選定を支援し、データに基づいた意思決定とLLMOps実現に貢献する。

【備忘録】Terraformの設計について振り返る その①

5～10年の経験を持つフルスタックエンジニアとして、Terraformの設計に関する記事を200字以内で要約します。

要約:
機能ごとにTerraformのディレクトリを分割する設計は、機能間の依存が多いと複雑化し、ステートファイル間の参照や適用順序の管理が困難になる。特に、密結合なインフラ構成では「変更範囲の限定」というメリットを享受しづらく、変数・データソースの管理も煩雑になる。
再設計するなら、環境分離がなく少人数で開発する、密結合なインフラ構成では、機能別にファイルを分割し、単一ステートファイルで管理するフラット構成がシンプルで推奨される。これによりTerraformが自動で依存関係を解決し、変更時の影響把握も容易になる。

RAGはもう古い？Geminiの「コンテキストキャッシュ」を選んだ理由と、実運用で見えた使い分けの境界線

Geminiのコンテキストキャッシュは、大量の共通コンテキストを効率的に利用し、RAGと比較してコストを75-90%削減、レイテンシを大幅短縮します。100万トークン以内、頻繁に参照される資料、高速レスポンスが求められる場合に最適です。RAGは検索漏れや速度面で劣る一方、大規模データやリアルタイム更新にはRAGが適します。実運用では、キャッシュのTTL管理と更新による再作成回避がコスト最適化の鍵となります。