Cloud Blog JA

Antigravity 2.0 を使用して 1 日で Go を習得するための実践的な方法

Thu, 25 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

私は、NPM の依存関係オーバーヘッドからソフトウェアスタックを解放し、リソースを大量に消費する Node.js ランタイムをコンパイルされた単一バイナリの Go CLI に置き換える方法を模索してきました。その結果、skl という高速ツールが完成しました。エージェントスキルの管理に使用するツールで、起動時間はわずか 2 ミリ秒、使用するメモリはたった 11 MB です。

具体的に、私は何をしたと思いますか？

アーキテクチャに関する目標を設定して、ロジックを監査しただけです。その一方で、Antigravity がコードの変換、テストの生成、プラットフォームパスのマッピングといった機械的な作業をすべて実行してくれました。今回の投稿では、この移行ワークフローを順を追ってご紹介しますので、ご自身のワークフローの構築にお役立てください。

ステップ 0: 個人的な学習目標の「種まき」をする

コードを記述する前に、まずプロジェクトの境界を定義します。私たちの場合、外部パッケージの使用を最小限に抑えた、依存関係のないコアが必要でした。そして、開発する CLI ツールは高速である必要があり、セキュリティモデルは必要に応じてゼロトラストにしなければならないと決めました。その過程で、エージェントから具体的な制約が追加されました。すべての入力をサニタイズすること、パストラバーサルをブロックすること、フォルダスキャンに深さ制限を適用して CPU のハングを防止することです。

まず、代替スタックを監査し、そのトレードオフを比較検討するよう Gemini に指示しました。

code_block: <ListValue: [StructValue([('code', 'オンラインで TS の代替となる CLI ツール構築ソリューションを調査して 3～5 個教えてください。その理由（パフォーマンスとセキュリティを重視します）と、具体的な例およびリンクも記載してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6730>)])]>

私たちが検討した代替ソリューションは次のとおりです。

Rust: パフォーマンスが非常に優れていましたが、その借用チェッカーのルールを理解し、ライフタイムアノテーションを管理することは、私たちの単純なシンボリックリンクツールには負担が大きすぎました。
Python: ランタイムインタプリタを配布して仮想環境を管理する必要があり、pip を介したパッケージ化のオーバーヘッドを生じさせることになります。これは避けたいと考えました。
Zig: 優れた低レベルのメモリ制御とコンパイル速度を実現できましたが、HTTP 操作やアーカイブ抽出のための高レベルの標準ライブラリ抽象化がデフォルトで用意されていませんでした。
コンパイルされた Swift: macOS ではクリーンなスクリプトが提供されましたが、Windows と Linux 向けのクロスプラットフォームコンパイル機能は、私たちのマルチプラットフォーム要件には最適ではありませんでした。

私たちにとって、適切なバランスを備えていたのが Go でした。このツールは、同期型の線形コード、即時コンパイル機能、豊富な標準ライブラリを備えています。

他の誰かがすでに完了している作業を繰り返したくなかったため、プロジェクトを始めるにあたって、私は次のように直接的に質問しました。

code_block: <ListValue: [StructValue([('code', '「npx skills」を Go に移植したいのですが、以前にこれを行った人はいますか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb67f0>)])]>

エージェントはウェブを調査し、vercel-labs/skills リポジトリの公式 Go ポートがないことを確認しました。また、公式 CLI は TypeScript ベースで npm を介して配布されますが、エージェントスキル仕様自体はオープンで言語に依存しないことも確認しました。つまり、コンパイルされた Go ポートをゼロから自由に構築できるということです。

また、この過程で多くのことを学びたかったため、Go 固有のヒント、コツ、落とし穴についても尋ねました。

code_block: <ListValue: [StructValue([('code', 'GO の正しい使い方と正しくない使い方を 3～5 パターン特定し、説明してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6df0>)])]>

ステップ 1: スキルの重要性

馴染みのない言語のベストプラクティスを最大限に活用するために、最もよく利用されている、評価の高いエージェントスキル（AI コーディングアシスタントをガイドするカスタム指示）を探してインストールしてから、コードの記述や計画を開始することにしました。まず環境のグラウンディングを行うことで、その後記述または計画されるコードがコミュニティの合意されたスタイルに確実に準拠するようになります。

スキル検索のプロンプト

エージェントに、Go で利用できるコミュニティエージェントスキルを尋ねました。

code_block: <ListValue: [StructValue([('code', '「Go」の主要なコミュニティエージェントスキルは何ですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6f70>)])]>

エージェントから samber/cc-skills-golang が提案されたので、そのスキルパックをインストールするように指示しました。

code_block: <ListValue: [StructValue([('code', 'samber/cc-skills-golang のすべてのスキルを追加してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6250>)])]>

インストール後、/golang- と入力して予測入力機能を呼び出し、スキルが検出されて準備が整っていることを手動で確認しました。

ステップ 2: ギャップ分析と計画

エージェントに次の指示を与えて、アーキテクチャに関する目標を定義しました。

code_block: <ListValue: [StructValue([('code', '「npx skills」の機能を 100% Go に移植する計画を立ててください。安全性とベストプラクティスを重視し、単体テストのカバレッジは 90% とします。リポジトリを pull して全体をマッピングし、質問があれば何でも聞いてください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6a00>)])]>

最初のトピックタスクは、動的なオンボーディングフローでした。デフォルトをどうすべきか尋ねられたので、エージェントが見つからない場合は antigravity-cli のインストールを促すように提案しました。また、複数のアクティブなエージェントが検出された場合の universal ディレクトリへのフォールバック動作も定義しました。

code_block: <ListValue: [StructValue([('code', 'MVP では、Antigravity 2 のデフォルトのサポートと、標準に準拠した「.agents」ディレクトリを通じた universal へのフォールバック（複数のエージェントが検出された場合）を目指します。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6550>)])]>

実装

私が計画を承認すると、Antigravity は 51 件以上あるエージェント構成レコードすべての体系的な変換を実行しました（すべての変換を明示的に要求したわけではありませんが、AI はタスクが十分にシンプルであるため MVP の範囲に含めることができると正しく特定しました）。TypeScript から Go に Aider、Claude Code、Cursor、Zed などの個別のディレクトリをマッピングすることで、すべての環境に対応できました。

コア構造は 1 つのファイル types.go にまとめられていて便利です。

code_block: <ListValue: [StructValue([('code', 'type AgentType string\r\n\u200b\r\ntype AgentConfig struct {\r\n Name string\r\n DisplayName string\r\n SkillsDir string\r\n GlobalSkillsDir string\r\n ShowInUniversalList bool\r\n DetectInstalled func(home, configHome, cwd string) bool\r\n}\r\n\u200b\r\n…'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb6a60>)])]>

このマッピングは効果的に動作します。たとえば、Zed の検出ロジックは、Linux（Flatpak）、macOS、Windows の構成を、次のようにわずか数行で動的に処理します。

code_block: <ListValue: [StructValue([('code', '"zed": {\r\n Name: "zed",\r\n DisplayName: "Zed",\r\n SkillsDir: ".agents/skills",\r\n GlobalSkillsDir: filepath.Join(home, ".agents/skills"),\r\n DetectInstalled: func(h, c, w string) bool {\r\n return exists(filepath.Join(c, "zed")) ||\r\n (zedAppDataHome != "" && exists(filepath.Join(zedAppDataHome, "Zed"))) ||\r\n (zedFlatpakConfigHome != "" && exists(filepath.Join(zedFlatpakConfigHome, "zed")))\r\n },\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dffc70>)])]>

その後、Antigravity のユーザーオンボーディングコードが自動マッピングに混在していることに気づきました。このようなデフォルトはユーザーが個人的に選択するものであり、独自のファイル agy-onboarding.go として分離する方が適しています。

code_block: <ListValue: [StructValue([('code', 'デフォルトの Antigravity 2 プロンプトを agy-onboarding.go に移動してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff6d0>)])]>

バージョン 0 がスキャフォールディングされ、テスト段階に入りました。

ステップ 3: 品質保証（QA）ループの実施

Go ポートが元の TypeScript CLI と同じように動作することを保証するために、テスト駆動開発（TDD）ループを採用しました。私はまず、プロンプトで次の指示を出しました。

code_block: <ListValue: [StructValue([('code', 'TDD の原則と https://preslav.me/2026/05/19/10-golang-error-handling-commandments/ を適用してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff160>)])]>

これにより、TDD プロセスが開始されました。エージェントにスキルを使用するように明示的に指示するのではなく、サードパーティのベストプラクティスに関するブログ投稿を取得するように指示することで、関連するエージェントスキル（golang-how-to、golang-testing、golang-error-handling、golang-cli）をエージェントに思い出させました。Antigravity はサンドボックスを備えているため、これらのスキルを解析し、QA ループの実行を自動的に開始しました。今後も、機能コードを変更しようとするたびに、最新の軌跡でこれらの TDD 原則を再適用し続けます。

テストファーストのフロントマター解析

フロントマター解析で、エージェントはまず Go のテーブル駆動テストパターンを使用して frontmatter_test.go を記述しました（これは私にとって新しいパターンで、知ることができて嬉しく思いました）。

code_block: <ListValue: [StructValue([('code', 'func TestParseFrontmatter(t *testing.T) {\r\n tests := []struct {\r\n name string\r\n raw string\r\n wantData map[string]interface{}\r\n wantContent string\r\n }{\r\n {\r\n name: "valid frontmatter",\r\n raw: "---\\nname: my-skill\\n---\\n# Content\\n",\r\n wantData: map[string]interface{}{"name": "my-skill"},\r\n wantContent: "# Content\\n",\r\n },\r\n }\r\n for _, tt := range tests {\r\n t.Run(tt.name, func(t *testing.T) {\r\n gotData, gotContent, err := ParseFrontmatter(tt.raw)\r\n # 結果のアサート...\r\n })\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dffca0>)])]>

Antigravity が go test を実行すると、予想どおりにエラーが発生しました。次に、エージェントが frontmatter.go を生成しました。これは、ドキュメントを分割して YAML メタデータをアンマーシャルする線形文字列スキャンループを実装するものです。複雑な正規表現ではなく単純な線形スキャンを使用することで、アプリケーションをクラッシュさせる可能性のある正規表現サービス拒否攻撃（ReDoS）への脆弱性に対処するツールを強化しました。目標（最初のプロンプトで示したもの）に安全性を含めたことで、元の Node 実装では正規表現を使用していたにもかかわらず、より安全なコードが生成されました。

「エラーの十戒」によるグラウンディング

エラー処理の話が出たので、エラー構造をどのようにして Preslav Rachev 氏の 10 Golang Error Handling Commandments（Golang におけるエラー処理の十戒）に沿ったものにしたかについて、ここでご説明しておきましょう。Go では、エラー値を例外としてキャッチするのではなく、明示的に返す必要があります。これらのルールを統合することで、すべてのレベルでエラーを即座にチェックし（if err != nil）、コンテキストの詳細でラップ（fmt.Errorf("action: %w", err)）してから、コールスタックに継承するようエージェントに指示しました。生成されたコードの最終レビューを行っていると、Antigravity が次のベストプラクティスを忘れていることに気づいたので、思い出してもらいました。

code_block: <ListValue: [StructValue([('code', 'すべてのファイルでエラーメッセージを短くする、先頭の「failed to」を削除する、など。Golang の十戒を参照してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff5b0>)])]>

Antigravity は、コードベース全体で迅速に修正を行いました。

単体テストだけで十分？

簡潔に言えば、いいえです。

変換プロセス中に AI が小さなバグやハルシネーションを発生させることがないよう、テストスイートの合格という結果を盲目的に信頼せず、コードレビューを実施しました。

生成されたテストを監査したところ、合格を示す緑色のチェックマークが付いただけでは不十分であることがわかりました。多数のインストール場所を対象としたテストと、エージェントなしの場合、エージェント 1 つの場合、複数のエージェントが同時にアクティブになっている場合といった、さまざまな組み合わせのテストが欠けていました。ゼロから書き直したコードであったため、一連のユーザー操作が最初から最後まで正しく機能することを総合的にテストする必要があると考えました。このギャップに対処するために、私は対象とする一連のシナリオを Antigravity にプロンプトで指示しました。

code_block: <ListValue: [StructValue([('code', '次の統合テストを追加してください。\r\n1. エージェントがインストールされていない: Antigravity にインストールされ、agy-cli のオンボーディングのヒントを出力することを確認します。\r\n2. 1 つを除くすべてのエージェントをサポート\r\n3. エージェントが 1 つだけインストールされている（同じパスが複数のエージェントに割り当てられている場合を含む）\r\n4. パラメータ化されていないエージェントをサポート'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff820>)])]>

注: Claude Code や Codex などのパラメータ化されていないエージェントは、実行時にアクティブなワークスペースフォルダをスキャンするのではなく、パッケージの読み込み時に（または環境変数を介して）構成パスをグローバルに定義します。

これらのテストを追加した変更リストは、本番環境のファイルには一切触れておらず、ロジックは堅実なものでした。しかし、運に任せるのは嫌でした。特定の機能やワークフローが重要なのであれば、そのことを明確に伝える必要があります。総合的なテストの範囲を確認し、いくつかの堅実なテストを定義するために 5 分を費やすだけで、ユーザーがリリースの不具合に遭遇するのを防ぐことができます。

ステップ 4: CLI コマンド向けの並列サブエージェント

一連の CLI コマンド（init、add、list、remove、find、update など）をサブオプションとともに移植すると、対応が必要な範囲が広がってしまいます。順番に移行するのではなく、作業を並列化した方がよいかもしれません。今回のケースでは、各サブエージェントにツール全体を把握させるのではなく、特定のトピックに集中させることを目的としていたため、この方法が適していました。また、この方法によっていくつかのギャップを特定できました。

ただし、サブエージェントが常に最善の選択肢とは限りません。明確に境界が定められた、大量の独立したタスクの場合のみ、並列実行を優先する必要があります。適切に対処すれば、並列サブエージェントが消費するトークンが、長時間実行される単一のスレッドよりも大幅に多くなることはありませんが、並列サブエージェントは、大規模なコードベースの負担がかかっている場合に、メインのコーディネーターエージェントがコンテキスト圧縮の制限に達するのを防ぎます。ほとんどの単純なプロジェクトでは、このレベルの拡張は不要です。経験上、サブエージェントは、数十のサブ機能を持つ数十の機能に相当するワークロードに使用するとよいでしょう。

前のステップでは、MVP を迅速かつ効率的に構築するために、単一のエージェントを実行しました。しかし、コードが完全に移植されたかどうかはわかりませんでした。そこで、次のように直接的に尋ねてみました。

code_block: <ListValue: [StructValue([('code', '元の CLI の 100% を処理できましたか？\r\nサブエージェントに各オプションを個別に調査させ、各テストも調査させて、ギャップを埋めてください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff490>)])]>

結果的に、これは正しい判断でした。サブエージェントはコマンドの詳細な監査を実施し、いくつかのオプションのギャップと欠落しているテストを特定しました。その後、これらはこちらの監査 commit に統合されました。

code_block: <ListValue: []>

各サブエージェントは 1 つのコマンドのみを処理しました。-g/--global や --copy などのフラグの組み合わせを分析し、テーブル駆動型の単体テストを作成して、コードが問題なくコンパイルされることを確認しました。報告を受けたメインコーディネーターは、変更を統合し、競合を解決して、結合されたプロジェクト全体が正常にコンパイルされることを検証しました。

象（Elephant）と金魚（Goldfish）

エージェントをこの移行に集中させ続けるために、Google Research の Elephants, Goldfish, and the New Golden Age of Software Engineering で文書化されているアーキテクチャパターンである「象と金魚」の例えを使用しました。これは、象（設計ルールとコードベースのメモリを保持する長期的なコーディネーターセッション）と金魚（バックグラウンド履歴なしで単一のタスクを実行するために生成する、一時的かつクリーンなサブエージェント）という 2 つの個別の役割に基づくものです。

Antigravity は自動セッション圧縮を使用してコンテキストサイズを管理しますが、コンテキストが少ないほど明瞭になる場合は、独自のチェックリストを維持し、作業を分離された一時的なサブエージェントに分割することで、コンテキストウィンドウを積極的に管理することをおすすめします。

ステップ 5: パッケージ構造、コンパイル、CI / CD

何度かやり取りするうちに、Go パッケージの構造と、考慮すべき制限事項がわかってきました。そして、ネイティブインストールをサポートする、明確な構造と充実したドキュメントを備えたパッケージ main.go が完成しました。

code_block: <ListValue: [StructValue([('code', 'go install github.com/alexastrum/skl@latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dff1f0>)])]>

実装の詳細を把握し、後で参照できるように文書化するようエージェントに指示しました。

code_block: <ListValue: [StructValue([('code', '人間向けの結果を README.md に要約し、エージェント向けの考慮事項を AGENTS.md に要約してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7dfff10>)])]>

ビルドを確認し、テストを自動実行して、他のマシンでも動作することを確認するために、エージェントに次のように依頼しました。

code_block: <ListValue: [StructValue([('code', 'すべてのサポート対象プラットフォームでビルドされることを確認してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb2a00>)])]>

Antigravity は、マトリックスビルドを実行するための ci.yml ワークフローを設定しました。このワークフローには、驚くべき依存関係がありました。

code_block: <ListValue: [StructValue([('code', 'env:\r\n FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true" # HMMMMMM ???\r\njobs:\r\n test:\r\n strategy:\r\n matrix:\r\n os: [ubuntu-latest, macos-latest, windows-latest]\r\n# ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb2160>)])]>

予想外の注意点

矛盾しているようですが、Node から Go に移行したにもかかわらず、GitHub パイプラインは依然として、actions/checkout や actions/setup-go などの標準的な GitHub Actions ヘルパーに Node を使用しています。
このツールは、ローカルで実行およびコンパイルすることができます。ただし、事前にコンパイルされたバイナリを他のユーザーに配布する場合は、macOS と Windows 向けのコード署名を設定する必要があります。

コード署名を使用したカスタムアクションの構築は複雑なプロセスであるため、その説明はまたの機会に譲ります。

ステップ 6: エージェントスキルを作成する

プロセス自体を文書化する段階になりました。このワークフローを体系化するために、再利用可能なエージェントスキルを作成しました。

まず、最も重要な手順を含むスキル作成プロンプトを計画するようエージェントに指示しました。

code_block: <ListValue: [StructValue([('code', '最新の軌跡（受け入れられた結果を生成した私の具体的なプロンプトを含む）を確認し、「/cli-to-go-migration」スキルを作成する計画を立てましょう。スキルはどのような手順を踏むべきですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb22b0>)])]>

プロンプトのドラフトが提示され、それを繰り返し改良しました。何度かやり取りした後、5 つの基本ルール（ただし、人によって異なります）に基づいて最終的な指示をまとめました。私が使用した最終的なプロンプトは次のとおりです。

code_block: <ListValue: [StructValue([('code', '最新の軌跡（受け入れられた結果を生成した私の具体的なプロンプトを含む）を確認し、「/cli-to-go-migration」スキルを作成する計画を立てましょう。ルールは次のとおりです。\r\n\u200b\r\n#### 1. 目標\r\nエージェントは、コードを提案する前に調査を開始する必要があります。ユーザーのより広範な目標を特定し、複数のスタックの代替案を検討し、以前の作業を確認して 1 つのターゲット言語に絞り込み、そのイディオムを調査してください。\r\n\u200b\r\n#### 2. 設定\r\nエージェントは、ファイルを変更する前に Git リポジトリを検証または初期化して、履歴をクリーンな状態に保ちます。その後、ダウンロードの失敗を直接報告し、すべての独立した作業が完了したら失敗の処理を安全に行う必要もあります。プレースホルダや終了しないループにフォールバックすることはありません。\r\n\u200b\r\n#### 3. 既存の知識のインポート\r\n必要な基礎スキル（「golang-cli」や「golang-testing」など）が欠けているにもかかわらず、プロンプトで明示的に指定されている場合、エージェントはデベロッパーが従うべき手順を出力するのではなく、実行をブロックし、確認を求めたうえで自動的にインストールすることを提案します。\r\n\u200b\r\n#### 4. ブレークポイント\r\nこのスキルは、AI の既知の課題が発生した場合にシステムを強制停止させます。エージェントは、特定の問題に遭遇した場合や混乱が生じた場合は常に、人間またはアルゴリズムによる検証のために停止します。\r\n\u200b\r\n#### 5. 整合性チェック\r\n不整合の兆候が見られたら、明示的なルールを設定する必要があります。たとえば、エージェントが一部のドキュメントを過剰に編集し、他のドキュメントを見落としていることに気づいた私は、エージェントが「/humanizer」スキルを適用するのは「README.md」やヘルプドキュメントなどの人間向けのファイルのみとし、「AGENTS.md」などの構造化されたデベロッパーコンテキストは、スタイルを編集せずにおくことで、他のエージェントがそのメタデータを正確に解析できるようにするというルールを設定しました。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7fb2b50>)])]>

万能なアプローチはありませんが、まずはいくつかのガードレールに基づくスキルを作成するようエージェントに依頼するとよいでしょう。実際には、エージェントの回答が目標に沿っていると感じるまで、複数のプロンプトを順番に推敲することになるでしょう。その後、AI に校正を依頼し、最終的には人間が SKILL.md の内容をレビューします。

まとめ

Go での skl の再構築は、ツールに関する個人的なニーズの解決につながる、楽しく有益な経験でした。うまくいったので、そのプロセスを文書化することにしたのです。今回の経験を経て、この取り組みそのものに価値があったことに気づきました。アーキテクチャの選択肢を再利用可能なスキルと個人的な経験に体系化することで、エンジニアとして成長できます。コンパイルされたバイナリは、プロセスが機能したことを示す物理的な証拠となります。

驚くべきことに、この移行中に私が経験した最も大きな変化は行動面に現れました。

IDE（統合開発環境）から離れて Antigravity 2.0 を使用することで、全体像を把握しやすくなり、移行中に発生した問題をその場で修正しようとしなくなりました。その代わりに、問題が発生した理由を理解し、Go 言語固有の詳細を把握できるよう、Antigravity が導いてくれました。

従来の IDE では、アシスタントが問題に遭遇すると、本能的にキーボードを手に取ってデバッグしたくなります。エディタなしで操作するということは、船の機関室で発生した火災に自ら対処するのではなく、造船技術者として航海船橋から機械を操縦するようなものです。私たちはまさに、こうしてエージェントを大規模に管理する方法を学びました。

- Antigravity、デベロッパーリレーションズ、Alex "Sandu" Astrum

Siemens が「象の切り分け」（細分化）により産業用ソフトウェア開発のエージェントワークフローを推進

Thu, 25 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Siemens のようなテクノロジー企業では、ソフトウェアは世界中の工場、エネルギー網、輸送ネットワークを結びつける、人体で言えば神経系のような役割を果たしています。

産業用 AI、産業用ソフトウェア、産業オートメーションのグローバルリーダーである Siemens には、工場やプロセスの自動化、エネルギーインフラストラクチャ、インテリジェントな輸送など、数十年にわたるドメインの専門知識の蓄積があります。これは、既製の AI ソリューションでは再現できないものです。しかし、イノベーションにあたってはレガシーコードが重い足かせとなっています。

10 年以上にわたって開発された数億行に及ぶコードベースを持つ Siemens は、標準的な AI ツールでは解決できない課題に直面していました。それは、このコードと、その上で実行されるアプリケーションを理解し、モダナイズすることです。産業グレードのソフトウェアの規模と複雑さには、根本的に異なるアプローチが必要です。既存のコーディングアシスタントには、複雑な多層構造の産業用コードベースをナビゲートするために必要なコンテキストの深さが欠けており、このギャップを埋める必要がありました。

この問題を解決するために、Siemens と Google Cloud は、ソフトウェア開発ライフサイクルを自動化する AI システムである Knowledge Fabricを作成しました。このエージェントは、Spanner Graph のナレッジグラフ、Google Agent Development Kit、Gemini API、Agent Platform、Gemini CLI、Anthropic Claude Code を使用して構築されました。既存のフロンティアをウェブベースのインターフェースに移行するパイロット版では、Knowledge Fabric によって実装作業が軽減され、エンジニアはシステムとの完全な互換性を維持しながら、顧客のイノベーションに集中できるようになりました。

「ソフトウェアエコシステム全体を、カスタムナレッジグラフを備えたインテリジェントなエージェントシステムに取り込むことで、開発者が開発時間を最適化できるよう支援するだけでなく、自律エージェントが過去を推論して未来を構築できるようにします。これにより、エンジニアは反復作業から解放され、より価値の高い問題解決に集中できるようになります」と、Siemens のプロダクトクリエーションエクセレンス担当シニアバイスプレジデントである Franz Menzl 氏は述べています。

課題: 産業用ソフトウェアの複雑さ

大規模な産業グレードのソフトウェアシステムのモダナイゼーションは、飛行機を飛行中に改修するようなものだとよく言われます。Siemens が直面した課題には次の 4 つの側面がありました。

規模: リポジトリは膨大で、標準的な大規模言語モデルのコンテキストウィンドウをはるかに超えています。
断片化: 重要な知識が、コード、Jira チケット、Confluence ページ、2000 年代初頭にスキャンされた PDF マニュアルに散在していました。
複雑さ: 特定のコード行が 10 年前の機能要件定義書のどこに該当するのか追跡することは、手作業や従来のツールでは効率的に対処できない課題となっていました。これは業界全体が共通して抱えている現実です。
責任: システムは、多くの場合 15～20 年以上にわたる運用期間にわたって、厳格な品質、コンプライアンス、ライフサイクルの要件を遵守する必要があります。そのため、AI によって生成された出力は、説明可能で、追跡可能で、検証可能でなければなりません。ハルシネーションや検証されていない変更は、非効率的であるだけでなく、運用上も許容できません。

「標準の RAG（検索拡張生成）では不十分であることがわかりました。コードは単なるテキストではなく、固有の構造を持っています。クラスはファイルに属し、ファイルはモジュールに属します。これをベクトルデータベースにフラット化すると、コードベースの要素間の関係性の表現が失われてしまいます」と、Google Cloud のテクニカルリードである Agata Gołębiowska は言います。

解決策: ドメインを認識する Knowledge Fabric

この広大なソフトウェア環境を AI 主導のワークフローでナビゲートできるようにするため、チームは Knowledge Fabric エージェントを構築しました。このエージェントは、キーワードの一致だけでなく、アセット間の関係を「理解」します。

Spanner Graph を使用してコードベースの固有の構造をモデル化し、あらゆる形式のドキュメントに対しても同様に厳密なアプローチを適用しています。これらのドメイン間の接続をマッピングすることで、特定のコードスニペットを設計ドキュメントの要件に直接関連付けることができます。次にエージェントは、ツールを使用して Graph Query Language（GQL）で構造をクエリし、このグラフを走査します。

しかし、GQL はその一部にすぎません。セマンティックな理解を可能にするために、Spanner の近似最近傍（ANN）アルゴリズムを使用してすべてのノードのエンベディングを生成し、コードベース全体で効率的なベクトル検索を実行します。最後に、エージェントに全文検索機能を提供します。この機能は GQL と組み合わせて、ノードとエッジを正確に特定できます。

これら 3 つの方法を組み合わせることで、LLM エージェントは「Axis Control Panel のロジックを変更した場合、どの関数を更新する必要がありますか？」といった複雑なクエリに回答できます。システムは、キーワードと意味的類似性を考慮してグラフを走査し、依存関係を特定して関連ドキュメントを取得し、正確な影響分析を提示します。

この正確なコンテキストにより、コーディングエージェントは有効で、使用可能で、保守可能な実装を生成できます。

「象の切り分け」: エージェントワークフロー

このプロジェクトから得られた重要な知見は、AI エージェントは大規模で曖昧なタスクを苦手としているということです。成功を収めるために、チームは「象の切り分け」という設計パターンを採用しました。

このシステムは、「このモジュールをリファクタリングする」のような広範なリクエストを、より管理しやすい小さなタスクに分割します。各タスクは、Google Agent Development Kit（ADK）で構築された専門のエージェントによって処理されます。

検索エージェント: 詳細な調査のスペシャリストとして機能します。ツールを使用してコードグラフを探索し、エージェント検索でドキュメントと調査結果を相互参照します。
ユーザーストーリーエージェント: プロダクトオーナーにインタビューして要件を収集し、既存のシステムコンテキストにリンクされた受け入れ基準を含む詳細なユーザーストーリーの下書きを作成します。
アーキテクチャの影響エージェント: グラフに対して提案された変更を分析し、コード行の記述を開始する前に副作用を予測します。
タスク分解エージェント: アーキテクチャの影響エージェントからの分析結果を使用し、作業を管理しやすい小さなタスクに分解します。各タスクには、特定の変更に関連するすべてのコンテキストが含まれます。
コーディングエージェント: 特定のタスクで説明されている変更を実装します。コンテキストや事前分析なしにこのステップに進んでも、実用可能なコードは生成されません。

このシステムでは、すべてのステップで人間が関与するため、本番環境レベルの信頼性の高い成果が保証され、エンジニアはルーチン的な実装作業から解放され、有意義な作業に集中できます。

Siemens のプロジェクトリードである Alexander Lomakin 氏は次のように述べています。「象の切り分け、つまり、複雑なリファクタリングジョブを、エージェントが主導する小さなタスクに分割することで、生産性が大幅に向上しました。AI の複雑な構造をナビゲートするために必要なロードマップを与えたということです。」

パイロット運用の結果: エンジニアリングの迅速化と効率化を実現

デベロッパーはほぼ即座にその成果を確認できました。

新機能の依存関係を分析するには、以前はシニアエンジニアが数日かけてコードベースと従来のドキュメントを調べる必要がありました。Knowledge Fabric を使用すると、同じ作業にかかる時間が大幅に短縮されます。

最近の試験運用では、従来のコントロールパネルを最新のウェブベースのインターフェースに移行する際に、Knowledge Fabric によってシステムの完全性と産業品質基準を維持しながら、コーディング作業全体が削減されました。

エンジニアは、反復作業に費やす時間を減らし、顧客価値の創出により多くの時間を費やせるようになりました。

使ってみる

Knowledge Fabric は、生成 AI がボイラープレートコードの作成だけでなく、ビジネスが最も依存するレガシーシステムのモダナイゼーションにも役立つことを示しています。

グラフベースのエージェントを構築してレガシーをモダナイズする方法の詳細については、以下をご覧ください。

Spanner Graph について読む。
Agent Platform を確認し、Agent Garden で事前構築済みの本番環境グレードのエージェントを見つける。
Agent Development Kit を確認する。
Siemens が産業用 AI をどのように推進しているか詳細を確認する。

- Google、グループプロダクトマネージャー兼 AI エンジニア、Anant Nawalgaria

- Google、スタッフソフトウェアエンジニア、Tomasz Świtoń

次世代のグローバルイノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

Thu, 25 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

テクノロジー起業の世界はリスクが高く、優れたプロトタイプから市場を定義する拡大可能なビジネスへの飛躍は困難を伴います。創業者は資金だけでなく、詳細なアーキテクチャガイダンス、国家レベルの政策への対応、急速な成長が可能な技術システムも必要としています。

ジョイの法則からの抜粋:「誰であれ、最も賢い人のほとんどは他の誰かのために働いている。」

真のイノベーションは本質的に「他の場所」で起こるものだと Google は考えています。この理念に基づき、Google はイノベーション市場の多様な地理的フットプリントにわたってグローバルアクセラレータを積極的にサポートし、各地の優れた人材を活用しています。Google のアクセラレータプログラムは、10 年以上にわたり、この移行を促進する役割を果たしてきました。このプログラムは、起業家としての野心と Google の世界クラスのエンジニアリングエコシステムとのギャップを埋めることで、地球上で最も復元力が高く、パフォーマンスの高い数々のスタートアップ（ポートフォリオ）を静かに輩出してきました。

ネットワークの力: 10 年間の成果を数字で見る

多くのスタートアップアクセラレータは失敗率が高く、苦境に陥っていますが、Google のアクセラレータプログラムは長期的な成功のための高い基準を確立しています。このプログラムでは、トップクラスの創業者や CTO を適切なエキスパートと結び付け、Google からカスタマイズされた高度な技術的支援を提供し、過去の教訓から学んだ業界のベストプラクティスを示すことで、価値の高い企業やプロダクトの構築を継続的に支援しています。

このグローバルネットワークの影響範囲は驚くべきものです。

指標	これまでの成果
グローバルフットプリント	88 か国で 2,011 社のスタートアップを支援
プログラムの経験	10 年間で 144 のコホートが卒業
生存率	ポートフォリオの存続率は 93%
資金面の勢い	調達した資金は 463 億ドル、ポートフォリオの総評価額は 1,351 億ドル
スタートアップの雇用創出	スタートアップポートフォリオ全体で 305,900 人の従業員

開発者の付加価値: このプログラムは、ビジネスの概要を学ぶためのものではありません。アクセラレータのスタートアップの創業者たちは、高度な技術的問題を特定し、Google からカスタマイズされたサポートを受けながら、その解決に取り組みます。これらのスタートアップは、Google のエンジニアやプロダクトマネージャーと連絡を取れるほか、Google のプラットフォームやツールも利用できます。アーキテクチャに関するアドバイスから AI モデルパイプラインの最適化まで、Google のエキスパートが創業チームと直接連携して、最も複雑な技術的ハードルへの対処を支援します。

戦略的展開: 地政学、グリーンインフラストラクチャ、ロボット工学

スタートアップエコシステムは急速に変化しており、Google のアクセラレータプログラムもそれに合わせて進化しています。今年、Google は世界的な経済発展を支援し、重要な環境インフラストラクチャを調査して進化させるための新しい取り組みを開始しました。いくつか例をご紹介します。

国家レベルの政策と戦略的成果

オーストラリア: アクセラレータの卒業生は、Google AI スタックをオーストラリアの国家研究開発戦略に直接組み込むことに成功し、キャンベラの国会議員と直接連携しています。
カナダ: カナダのイノベーション・科学・経済開発省は、G7 サミットの公式レポートで、カナダのアクセラレータプログラムの影響を正式に認め、引用しました。

フロンティア領域の最先端プログラム

今年は、プログラムの対象が、フロンティア領域の専門的なテクノロジーの業種にまで大きく拡大しています。

Google DeepMind Accelerator（ヨーロッパ）: AI ネイティブのロボット企業向けの技術構築の強化に特化したプログラムで、ラボでのプロトタイピングと商業市場での成功のギャップを効果的に埋めます。
アジア太平洋地域の GDM Accelerator（AI for Planet）: Google DeepMind チームと Google のサステナビリティチームの共同イニシアチブ。このプログラムは、生物多様性基盤モデルに重点を置き、重要な ESG（環境、社会、ガバナンス）インフラストラクチャ市場の最前線に Google を位置付けることを目指しています。
日本での再開: アジアで最も重要なテクノロジーハブの一つで戦略的にプログラムを再開します。

集合知の可能性

このユニークなネットワークの力を最大限に引き出すため、今年、地域ごとに分かれていた卒業生ネットワークを Unified Alumni Community に統合しました。現在、90 か国以上で 1,750 社を超えるスタートアップと 3,000 人の創業者を、共有オンラインチャネルと対面式イベントへの参加機会を通じて結び付けています。創業者たちは、Google の上層部と連絡を取り、Google の最新のモデルやテクノロジーを利用し、ビジネスの成長をより効果的にサポートする新しい Google プロダクトの開発に直接影響を与える機会を得て、互いに学び、支え合っています。

お見逃しなく: 今後の Demo Day

各アクセラレータの集大成となるのが Demo Day です。このデモでは、トップレベルのコホートが技術的な構築と市場を定義する新しいコンセプトを紹介します。これらのマイルストーンは、YouTube の Google for Startups イベントで直接ライブ配信されます。2026 年の残りのデモの日程は以下のとおりです。

2026 年夏と秋

アフリカのアクセラレータ: 6 月 19 日
中東、北アフリカ、トルコのアクセラレータ: 6 月 26 日
韓国のアクセラレータ: 7 月 15 日
ブラジルのアクセラレータ: 7 月 16 日
ヨーロッパとイスラエルの DeepMind Accelerator（ロボット工学）: 9 月 11 日
インド: 9 月 30 日

2026 年冬

インドのアクセラレータ: 11 月 4 日
東南アジアのアクセラレータ: 11 月 13 日
北米のアクセラレータ（エネルギー）: 11 月 19 日
南アフリカのアクセラレータ: 12 月 11 日
ヨーロッパとイスラエル（エネルギー）: 12 月 11 日
グローバルな Google.org Accelerator（政府のイノベーション）: 12 月 11 日

お申し込み受け付け中または受付予定のプログラム

技術インフラストラクチャを大幅にスケールアップし、プロダクトの市場への適合性を最適化し、Google のグローバルな人材プールからエクイティフリーのサポートを受けたいと考えている創業者や CTO の皆様、お申し込みの受け付けが正式に開始されました。

現在お申し込み受付中のプログラム:

GFSA 東南アジア（東南アジアとシリコンバレーを結ぶ、新しく立ち上げられた AI スタートアップイノベーションコリドーを活用）
GFSA 中国
Google.org Accelerator: AI for Science

- デベロッパー採用担当ディレクター、Matt Thompson

Looker エージェントでダッシュボードをインタラクティブなデータエクスペリエンスに変革

Wed, 24 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

ダッシュボードは、データからインサイトを引き出すための主要な手段として長年活用されてきましたが、アジャイルな環境では不十分な場合があります。ダッシュボードはインタラクティブではなく、追加の質問をすることもできないため、必要な回答を得るために、ワークフローから離れたり、データアナリストに頼ったりする必要がありました。こうした課題に対処するために、このたび、Looker ダッシュボードエージェント（プレビュー版）を発表しました。これは、インテリジェントな会話型データエージェントをダッシュボードに直接組み込むことで、ユーザーが自然言語を使用してビジネスインテリジェンス（BI）データを探索できるようにするものです。

Looker ダッシュボードエージェントとの会話の例

エージェント主導のインタラクティブな調査

従来のダッシュボードはデータの静的なビューを表示するものでした。Looker のダッシュボードエージェントを使用すると、ユーザーはダッシュボードのインターフェース内で直接データを探索できます。Gemini アイコンをクリックして会話を開始し、自然言語で質問することで、コンテキストに沿ったインサイトを得ることができます。

データエージェントの精度は、提供されるビジネスコンテキストと、ユーザーの問い合わせに対して適切な指標やディメンションをマッピングする能力に依存します。Looker ダッシュボードエージェントは、ユーザーが適用しているフィルタ、クロスフィルタ、事前にキュレートされたタイルについてコンテキストを直接参照できるため、複雑なビジネス上の質問に対しても、極めて関連性が高く正確な回答を生成できます。

クエリにより多くのデータが必要な場合、エージェントは基盤となる Explore にアクセスして追加情報を抽出できます。これらのインサイトには、関連するグラフや自然言語の説明が添えられており、データ探索を簡素化できます。

ダッシュボードの枠を超えてデータを探索し、より深いインサイトを引き出す

ビジネスに合わせてエージェントをカスタマイズ

データアナリストは、ビジネスユーザーが組織のデータを正確に把握できるよう、ダッシュボードをキュレートしています。こうした一貫性と信頼性の高い分析環境を維持するために、Looker ダッシュボードエージェントは高度に構成可能な設計になっています。アナリストは、エージェントに対して自然言語で直接指示することで、Looker のセマンティックレイヤにコンテキストを追加できます。これにより、エージェントが独自のビジネスロジックを解釈する方法や、対象ユーザーに合わせて回答を調整する方法を正確に定義できます。ダッシュボードエージェントは、セルフサービスでのデータ分析を可能にすることで、ビジネスの増大するデータ需要にアナリストチームが対応できるよう支援します。

Looker ダッシュボードエージェントの構成

信頼性と透明性を継承

ユーザーが AI ベースのシステムを採用するには、そのシステムが提供する情報を信頼できる必要があります。Looker ダッシュボードエージェントは、インサイトを生成する際、中間の推論、参照したダッシュボードタイル、適用したフィルタを表示することで、そのプロセスを明示的に示します。さらに、管理者は、ユーザーがアクセスできるデータや分析情報が、そのユーザーに権限が付与されているものだけであることを信頼する必要があります。ダッシュボードエージェントは、標準の権限を通じて管理される Looker のガバナンスモデルによって支えられています。

iframe の埋め込みのサポートなど、Looker ダッシュボードエージェントの追加機能の開発も積極的に進めています。今後、Looker ダッシュボードとともにダッシュボードエージェントを重要なポータルやアプリケーションに組み込めるようにする予定です。

ダッシュボードエージェントを使ってみる

Looker バージョン 26.08.11 以降では、管理者が Gemini in Looker の設定で [ダッシュボードでチャットを有効にする] を切り替えることで、ダッシュボードエージェント機能を有効にできます。有効にすると、権限のあるユーザーには Gemini アイコンが表示され、ダッシュボードのデータとのチャットをすぐに開始できます。詳細については、サポートドキュメントをご覧ください。

- プロダクトマネージャー、Vaibhavi Sonavane

Gemini for Government: ミッション達成に向けた設計図

Wed, 24 Jun 2026 01:10:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

公共部門は重要な転換点に差し掛かっています。長年にわたり、組織は AI のパイロット版や試験運用版を試しながら、AI で何ができるかを模索してきました。そして現在、その問いは「何が効果を生み出すか？」へと変わっています。その焦点はもはや仮説ではなく、実質的な生産性の向上、サービスと成果の改善、ミッションの推進を今すぐ 実現することにあります。この転換点に対応するには、強力なモデルだけでは不十分です。公共部門のミッションに求められるセキュリティ、信頼性、スケール、そして費用効率を兼ね備えた統合的なアプローチが必要です。

現在、公共部門の組織は、AI アシスタントや chatbot から本格的なエージェントタスクフォースへと急速に移行しています。ここでは、その具体的な取り組み方についてご紹介します。

統合された基盤の上に構築

AI やエージェントを本番環境に大規模に移行するには、統合に伴う摩擦を取り除く必要があります。Google Cloud は、一つの統合システムとして機能するように設計された包括的な AI スタックを提供しています。私たちは、この統合スタックこそが、エージェントの時代における真の変革の原動力であると確信しています。

この統合スタックを詳しく見てみましょう。

すべての基盤となるのが AI Hypercomputer です。Google の専用インフラストラクチャ基盤は、エージェントの時代の物理特性と規模に合わせて最適化されており、GPU と TPU の両方を搭載しています。私たちは、ポートフォリオへの投資を継続しており、Cloud Next ‘26 では、第 8 世代 TPU のリリースや、クロスクラウドインフラストラクチャのアップデートなど、いくつかの発表を行いました。これには、Fluid Compute、安全なクロスクラウド接続、統合データレイヤ、デジタル主権に関する新しいイノベーションも含まれています。
Google DeepMind による研究やフロンティアモデルを提供し、インテリジェンスを迅速かつ効率的に実現します。最近発表された Gemini 3.5 をはじめとする Google の主要モデルに加え、その他のオープンソースやサードパーティのオプションも用意しています。
Google の Agentic Data Cloud は、信頼できるリアルタイムの組織の真実とコンテキストに基づいて AI をグラウンディングします。Cloud Next ‘26 で発表された最新の画期的な技術であるクロスクラウドの Lakehouse や Knowledge Catalog などを活用し、お客様が「行動するシステム」を構築できるよう支援します。
Google のエージェント型防御により、コードからクラウドまで、AI のライフサイクル全体をゼロトラスト保護で安全に守ります。エージェントの時代を安全に前進していけるよう、Google は先日 Google AI Threat Defense をリリースしました。これは、AI を利用した脅威がビジネスに影響を与える前に、継続的にモニタリングし、阻止することを目的とした自動セキュリティシステムです。
Cloud Next ‘26 において、Gemini Enterprise Agent Platform を発表しました。この包括的なプラットフォームでは、アーキテクチャの厳密性を維持しながらエージェントの構築、スケール、管理、最適化が行えます。モデル選択、モデル構築、エージェント構築の機能に加え、エージェントの統合、開発、オーケストレーション、セキュリティに関する新機能も備わっています。
これらすべてが、事前構築済みの専門のエージェントやアプリケーションと統合されているため、導入初日から組織を変革することができます。また、Cloud Next ‘26 では、Workspace Intelligence をはじめとする新機能を発表しました。この安全かつ動的なシステムは、Workspace アプリ（ドキュメント、スライド、Gmail など）、進行中のプロジェクト、共同編集者、組織内のナレッジにおける複雑でセマンティックな関係を本質的に理解します。

妥協のないセキュリティと管理を実現

多くの公共部門の組織にとって、セキュリティの確保そのものが任務といえます。ミッション対応の安全な AI というこの新たな時代は、サイロ化されたシステムやレガシーシステムを超えて連携できるかどうかによって決まります。IT システム管理者は、組み込みの AI コントロールダッシュボードを利用できます。組織の AI 環境全体を一括表示し、一元的に可視化、保護、監査することができます。また、Agent Registry により、管理者はアクティブなエージェントとそのグラウンディングされたデータソースを完全に可視化し、あらゆるやり取りが機関のポリシーやセキュリティ要件の厳格なガードレール内に収まることを確保できます。Model Armor は、プロンプトインジェクション、機密データの漏洩、有害なコンテンツに対する包括的な保護を提供します。ゼロトラストの基盤の上に構築された Gemini for Government は、FedRAMP High 認証を取得したセキュリティ機能およびコンプライアンス機能を備えており、Google が基盤モデルのトレーニングに顧客データを使用しないことを明記したデータプライバシー保証によって支えられています。Google Cloud Next ‘26 では、AI 生成コードを保護し、シャドー AI のリスクを軽減するための新しい開発ツールを発表したほか、Wiz を使用してあらゆるインフラストラクチャで AI とクラウドアプリを保護する方法についても紹介しました。

組織全体でのエージェントのスケーリング

AI の真の可能性を実現するには、ケースワーカー、調査官、アナリストなど、一人ひとりが AI を活用できる必要があります。Google Public Sector は、GenAI.mil にエンタープライズ AI ツールを提供する最初のテクノロジープロバイダとなり、Gemini for Government を通じて 300 万人以上の民間人と軍関係者を支援しています。最近、GenAI.mil 上の Gemini for Government に新機能として Agent Designer を導入しました。これにより、米国戦争省（DoW）の民間人と軍関係者は、非機密業務をサポートする独自のエージェントを構築できるようになります。

Agent Designer を使用すれば、技術者以外のユーザーでもノーコードインターフェースを通じて自然言語で高度な AI エージェントを構築できます。Google の目標は、組織内のすべてのユーザーが、既存のシステムやエンタープライズアプリケーションに安全に接続するエージェントを構築し使用できるようにするツールを提供することです。AI とエージェントを使用して、手作業や時間のかかるタスクを自動化し、生産性を向上させ、ユーザーやチームが業務の最も重要な部分に経験と判断力を活かせるようにすることを目指しています。

具体的な ROI の実現

Google の最近の公共部門における AI の ROI レポートによると、エージェント型 AI と生成 AI はすでに公共部門のチームの業務効率化に貢献しています。調査結果では、公共部門のリーダーの 70% が、生成 AI によって生産性が向上したと回答しています。生産性が向上したと回答した人のうち、46% が従業員の生産性が少なくとも 2 倍になったと述べています。これは、応答時間の短縮、公共サービスの効率化、そして全体的な成果の向上に直結します。Gemini Deep Research Agent と NotebookLM は、公共部門の業務効率を飛躍的に向上させ、複雑な調査、集中的な作業、分析の実施方法を変革しています。

ミッション達成に向けた設計図

Gemini for Government を利用すれば、AI の検証や試験導入の段階を超えて、実際のアプリケーションやエージェントを大規模に活用できます。重要なのは、テクノロジーを応用して人間の能力を強化し、戦略的な意思決定を加速させ、ミッションを推進させることです。

6 月 11 日に開催される Gemini for Government ウェブセミナーにぜひご登録ください。データ、セキュリティ、統合された AI スタックを活用する方法について、さらに深く掘り下げてご紹介します。組織全体で導入初日からユースケースをスケールすることや、社内の AI 支持者を支援することを検討している場合でも、AI の導入を始めたばかりの場合でも、成果を上げてミッションを推進するための明確な道筋を得ることができます。

- Google Public Sector、カスタマーエンジニアリング担当マネージングディレクター、Elizabeth Moon

Storage Insights データセット: アクティビティインサイトで組織全体のオペレーションを把握

Wed, 24 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

エンタープライズストレージのフットプリントは、オブジェクト件数数十億規模にまで拡大してきています。また、ストレージの役割も、AI アプリケーションとエージェント型ワークロードにより、これまでの受動的なリポジトリからデータプラットフォームの基盤へと根本的な進化を遂げつつあります。非構造化モデルデータの急増と、セッションログや監査証跡を含むこのようなオブジェクトに実行される数十億ものアクションが、この進化を加速させています。これを管理し、費用、運用、セキュリティの問題を解決するために、ストレージとプラットフォームの管理者は、データの中身だけでなく、データがどのようにアクセス、移動、変更されているかを正確に把握する必要があります。

この課題の解決を支援するために、このたび一般提供を開始したのが、Storage Insights データセットのアクティビティインサイトです。これは、Google Cloud Storage アセットの運用に関する詳細を可視化する新しいビューを提供し、データドリブンな費用最適化と迅速なトラブルシューティングを可能にするものです。たとえば、アクティビティインサイトで次のような疑問を解決することができます。

オブジェクトはバケット内の適切なストレージクラスに配置されているか？
バケットが最も頻繁にやり取りしているリージョンはどこか？（バケットの最適な配置を評価するための情報確認）
ストレージ資産の運用全般において、どこでどのような理由でエラーが発生しているか？

これらの質問に自信を持って答えられることが、費用最適化を実現し、エンジニアリングのための時間を節約する鍵となります。Cloud Storage の Storage Intelligence 機能である Storage Insights データセットは、日々のメタデータと頻繁な（通常はアクティビティから 4 時間以内の）アクティビティ分析情報を提供し、ストレージ資産の可視性を高めます。Storage Intelligence は、バケットの再配置、バッチオペレーション、Gemini Cloud Assist などの機能を備えた統合管理プロダクトですが、このブログ記事では、運用最適化のために Storage Insights データセットを活用する方法に焦点を当てます。

Storage Insights データセットとは

Storage Insights データセットは、ストレージ資産全体に対する自動化されたクエリ対応の BigQuery インデックスを、実際のメタデータとアクティビティに関する分析情報とともに提供します。これにより、これまでエラーが起きやすかった手動のデータ収集作業が不要になります。Storage Insights データセットのスコープはカスタマイズできます。たとえば、組織全体、特定のフォルダ、プロジェクト、一連のプロジェクト、さらには特定のバケットを対象にデータセットを作成できます。このデータセットは定期的なアップデートによって更新され、ストレージの包括的なビューを提供します。

静的なメタデータからライブインテリジェンスへ進化

Storage Insights データセットは、ストレージのメタデータを把握するのに最適なツールです。インベントリ管理ツールとして機能し、オブジェクトのメタデータ（ストレージクラス、ロケーション、経過時間、カスタムメタデータ）をスキャンして、BigQuery にリンクされた、クエリ可能で有用性の高いデータセットに整理します。これはデータの実態を把握するためには不可欠な情報です（Storage Insights データセットを使用してストレージ費用を最適化する方法について詳しくは、こちらをご覧ください）。

さらに、そのデータがいつ、どのように使用されているかも把握できたらどうでしょうか。

Storage Insights データセットでは、新たに次の情報も確認できるようになりました。

オブジェクトレベルのアクティビティ（書き込み、更新、削除、エラーなど）
バケットレベルの集計アクティビティ（オブジェクトオペレーションの合計数、オペレーションのタイプ別の内訳、エラーの合計数、最頻の接頭辞など）
バケットレベルのリージョントラフィックアクティビティ（バケットとやり取りするリージョンごとの上り / 下り（内向き / 外向き）両方のバイト数など）
プロジェクトレベルの集計アクティビティ（オブジェクトオペレーションの合計数、オペレーションのタイプ別の内訳、エラーの合計数など）

これらのデータは、データセット内の新しい BigQuery ビューに直接取り込まれるため、分析クエリを実行して特定の分析情報を得たり、Gemini を介してデータとやり取りしたり、単に Looker の高機能ダッシュボードに接続して可視化したりすることができます。

これにより、データ分析が静的なスナップショットから、データのライフサイクル全般にわたるクエリ可能な動的分析へと進化します。これは、言うなれば、ウェアハウスに何があるかを知ることから、何がいつ、どのように使用されたかを知ることへの進化です。

アクティビティインサイトを直ちに活用する 3 つの方法

Storage Intelligence データセットのアクティビティインサイトを使用すれば、直ちに以下のことを実現できます。

1. ストレージ資産のサイズを適正化する

課題: Standard クラスまたは Nearline クラスのストレージにテラバイト規模のデータがあり、しかもコールドデータであると考えられます。しかし、確証がないまま Coldline クラスや Archive クラスに移行するのは危険です。重要なプロセスによる読み取りが四半期に 1 回は必要な場合はどうすればよいでしょうか？
解決策: アクティビティに関する分析情報を表示する新しい Storage Intelligence ビューでは、過去 30 日、60 日、90 日間に読み取り / 書き込みアクティビティが最小限だったバケットを特定できます。
対応: ライフサイクルポリシーを適用し、必要に応じて微調整して、このデータを費用対効果の高いストレージクラスに移行します。

たとえば、過去 6 か月間にアクティビティがほとんど、またはまったくなかったバケットをすべて並べ替える SQL クエリは次のようになります。

code_block: <ListValue: [StructValue([('code', 'SELECT name, location, project, totalRequests\r\nFROM\r\n `[project]`.`[dataset]`.`bucket_activity_view`\r\nWHERE\r\n snapshotEndTime >= TIMESTAMP(DATE_SUB(DATE_TRUNC(CURRENT_DATE(), MONTH), INTERVAL 5 MONTH))\r\n AND snapshotEndTime < CURRENT_TIMESTAMP()\r\nORDER BY totalRequests ASC\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6305044c40>)])]>

2. データドリブンなバケット配置でグローバルパフォーマンスを向上させる

課題: グローバルアプリケーションをサポートするためにマルチリージョンのバケットをセットアップしました。しかし、それは 1 年後も適切なアーキテクチャでしょうか？トラフィックの 99% が単一リージョンから発生している場合はどうでしょうか？
解決策: 新しい bucket_region_activity_view テーブルでアクセスパターンを分析します。どのリージョンがバケットの読み取り / 書き込みアクティビティを促進しているかを、簡単に特定できます。
対応: データドリブンな意思決定により、バケットとコンピューティングを同一リージョンに配置します。マルチリージョンバケットをシングルリージョンバケットに（またはその逆に）変更することで、大幅な費用削減とパフォーマンスの向上を実現できる場合があります。

たとえば、リージョン間のバケットの下り（外向き）と上り（内向き）のトラフィックパターンを分析する SQL クエリは次のようになります。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n requestLocation,\r\n bucketLocation,\r\n SUM(requestBytes) AS total_request_bytes,\r\n SUM(responseBytes) AS total_response_bytes\r\nFROM\r\n `[project]`.`[dataset]`.`bucket_region_activity_view` \r\nWHERE\r\n name = '[bucket name]'\r\nGROUP BY\r\n requestLocation,\r\n bucketLocation;\r\n\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f63050449d0>)])]>

当日配達サービスを提供する小売テクノロジープラットフォームの Shipt は、Storage Intelligence の機能を活用して、データの配置に関する意思決定に役立てています。

「Storage Intelligence を使用することで、20 億個を超えるオブジェクトを効率的に管理し、費用とパフォーマンスを最適化できるようになりました。Storage Insights データセットで、マルチリージョンバケットからの下り（外向き）料金を検出、分析でき、コンピューティングとストレージの共存による効率性向上の機会を特定できます。バケット再配置機能を利用して、1.3 ペタバイトのデータをマルチリージョンから特定リージョンのストレージにシームレスに移行し、アプリケーションのパフォーマンスとデータパイプラインの継続性を維持しながら、大幅な費用削減を実現しました。」 - Shipt、エンジニアリング担当ディレクター - クラウドプラットフォーム、Ron Cuirle 氏

3. 運用上のホットスポットを解明して解決する

課題: チームで 429（リクエスト過多）エラーが急増しています。大規模な環境では、これは単にパフォーマンスを低下させるだけではなく、費用を増加させます。これらのエラーは自動再試行をトリガーし、多くの場合、高頻度の課金対象オペレーションサイクルにつながり、クラス A の費用を押し上げるためです。どのオブジェクトまたは接頭辞が原因かを正確に特定するには、トラブルシューティングが難しく時間がかかります。
解決策: 新しい Storage Insights データセットビューでは、これらのエラーに関する詳細を BigQuery で直接確認できます。429 エラーをクエリすることで、どのオブジェクトと接頭辞に負荷がかかっているかを正確に特定できます。
対応: 429 エラーの原因をさらにピンポイントで特定できるので、トラブルシューティングから即、解決へと導かれます。

たとえば、次の SQL クエリは、環境全体で発生している 429 エラーを分析し、発生場所と原因を特定します。

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n requestOperation,\r\n errorReason,\r\n objectName,\r\n bucketName,\r\n requestCompletionTimestamp,\r\n project\r\nFROM\r\n `[project]`.`[dataset]`.`object_events_view` \r\nWHERE\r\n responseStatus = 429\r\nORDER BY\r\n requestCompletionTimestamp DESC;\r\n\r\n\r\n//データセットでクエリを実行すると、BQ クエリ費用が発生します。詳細については、料金ページをご覧ください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6305f6b100>)])]>

ご利用にあたって

Google Cloud を利用しながら成長し続ける組織では、データの規模も拡大する一方です。もうアーカイブデータに依存するのはやめて、組織のストレージ資産の最適化に着手しましょう。Cloud Storage の Storage Insights データセットは、新しいアクティビティインサイトにより、大規模なデータ資産を、高度に最適化された完全に把握可能なアセットへと生まれ変わらせます。

まず手始めに、こちらの事前構成済み Looker Studio テンプレートを使用してデータセットに接続し、迅速な分析で価値を引き出してみましょう。

たとえば、バケットの合計読み取り数の経時的な傾向を確認します。

あるいは、バケットの上り（内向き）と下り（外向き）の両方のトラフィックパターンを分析してみましょう。

Storage Insight データセットで分析情報を活用する準備はできましたか。ご利用を開始するには:

Google Cloud コンソールで早速 Storage Intelligence を有効にしましょう。
データセットを今すぐ構成してみましょう。BigQuery で直接データをクエリするか、Looker テンプレートに接続して、迅速かつ簡単に可視化できるようになります。
Storage Intelligence とご利用を開始する方法の詳細は、動画でご確認いただけます。
Storage Insights データセットを使用して Cloud Storage のフットプリントを最適化する方法について詳しくは、こちらをご覧ください。

- Cloud Storage、プロダクトマネージャー、Misha Sheth

- Cloud Storage、APAC テクノロジープラクティスリード、Kumar Nachiketa

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

Wed, 24 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

エージェント型 AI を導入する企業にとって必要なのは、事後対応型のインテリジェンスシステムから、プロアクティブなアクションシステムへの転換です。これは、必要とされるコンテキストとパフォーマンスを備えたエージェントを構築するとともに、すべての意思決定について説明と監査が可能な、規制当局の要求に対応できるレベルの説明責任を担保するためです。

Google Cloud Next ‘26 では、Agentic Data Cloud でアクションシステムを実現する方法について解説しましたが、まさにこのビジョンの好例となるのが Yahoo のデジタルメディア購入プラットフォームです。Yahoo は Google Cloud と提携し、Google データクラウドのグラフ技術を活用して、Seller Agent デジタルメディア購入プラットフォームを構築しました。Seller Agent は、数週間かかる手動プロセスをわずか数秒に凝縮して、完全に管理されたライブキャンペーンを実行できます。自律システムが厳格な説明責任を維持しながら驚異的なスピードで動作できることを証明するこのシステムは、さまざまな業界で活用できる強力なブループリントとなります。

「Yahoo! の使命は、デジタルの世界を案内する、信頼されるガイドになることです。Google Cloud とのパートナーシップを通して迅速性、透明性、効果、信頼性を確保したエージェント型メディア購入を実現することで、私たちは広告主様に対してもこの約束を果たしていきます。」- Yahoo、収益化責任者、Gabriel DeWitt 氏

このブログでは、エージェント型 AI への移行について詳しく説明し、Yahoo の Seller Agent アーキテクチャがメディア購入におけるスピードと信頼性の課題をいかに解決しているかを検証します。また、このグラフベースのパターンを応用して、皆様の組織で信頼できるアクションシステムを構築する方法もご紹介します。

ケーススタディ: エージェント型メディア購入

長年にわたり、プレミアムデジタル広告キャンペーンのような複雑で価値の高いワークフローでは、人手を介した数週間にわたる引き継ぎ、断片化したスプレッドシート、そして手動の分析が必要とされてきました。Yahoo は、エージェント型 AI を使えば、このタイムラインを劇的に短縮し、わずか数秒でキャンペーンを計画して実行できる可能性があることに着目しました。「手動から自律的な実行へ」というこの飛躍は、運用効率を大幅に改善し、投入した予算をより確実に測定可能な成果へと結びつける大きなチャンスでした。

しかし、リスクの高いワークフローに LLM をただ組み込むだけでは問題は解決しません。もし、リアルタイムの広告在庫や、価格設定ルール、ビジネス上の制約を決定論的に理解できていないエージェントが契約や広告掲載の交渉を行えば、ハルシネーションが生じやすくなり、甚大な損失を招く取引となるおそれがあるからです。信頼できるエージェントプラットフォームには、統計的な推測ではなく、確固たる事実に基づいて行動するためのリアルタイムかつ決定版の情報源が不可欠です。

しかも、「スピード」と「事実へのグラウンディング」は必要とされる条件の半分にすぎません。AI エージェントが実際の予算を動かし始めた瞬間、その動作は規制当局の厳しい監視の対象となります。そして規制当局は、特定の決定がなぜ行われ、どのポリシーが適用されたのかについて即座に説明できることを求めてきます。事後にシステムログをさかのぼって調べるような手法は、自律的な実行を管理する手段としては不適切です。実用できるレベルのアクションシステムには、後付けではなくワークフローに直接組み込まれた、規制当局の要求に対応可能なガバナンスと監査可能性が必要です。

信頼できるアクションシステムのアーキテクチャ

Yahoo! の使命は、デジタル世界を案内する、信頼できるガイドになることです。エージェント型メディア購入は、予算を Yahoo に託し、真の説明責任が果たされることを期待する広告主、代理店、パブリッシャー、そして規制当局に対しても、その約束を広げていくものです。課題は、説明可能、管理可能、監査可能な方法でキャンペーンの実施を自動化することでした。

この課題に対処するため、Yahoo は Google Cloud で実行されるマルチエージェントシステムとして Seller Agent を構築しました。バイヤーのリクエストは、Google Kubernetes Engine（GKE）で実行され、Google の Agent Development Kit（ADK）でオーケストレーションされる計画スーパーバイザーエージェントを介して入力されます。スーパーバイザーは、在庫の検出、オーディエンスのマッチング、予測、価格分析、パッケージの推奨、ガバナンスのレビュー、実行など、各リクエストを専門的なタスクに分解します。エージェントは、オープンな Agent2Agent（A2A）プロトコルを介して連携します。一方、Gemini Enterprise Agent Platform は、エンベディング、予測、グラフ学習のためのモデルをホストします。

しかし真のブレークスルーは、自律的な実行における迅速性と完全な透明性を両立させている「デュアルグラフ基盤」のプラットフォームです。このプラットフォームは、行動に最適化されたナレッジグラフと、記憶と学習を担うコンテキストグラフという、意図的に役割を分離した 2 つの特殊なグラフシステムによって支えられています。

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

Spanner Graph を活用した Yahoo のナレッジグラフは、収益化ビジネスの各要素を相互に関連付けられた運用モデルとして表すことで、エージェントのあらゆる意思決定をビジネスの実態にグラウンディングします。広告サービス、プレースメント、オーディエンスセグメント、広告枠、契約、ガバナンス管理は、それぞれファーストクラスエンティティとして、その相互関係とともにモデル化されます。重要なのは、ポリシーをアプリケーションロジックに埋め込むのではなく、バージョン管理された関係としてグラフ内に直接組み込んでいることです。この設計により、商品、契約上の義務、同意に関する要件、規制上の制約を、単一の統合されたグラフ操作でまとめて評価することが可能になっています。

グラフは、エージェントプラットフォーム全体でセマンティックコントラクトとして機能します。キャンペーンの評価中、エージェントは 1 つのクエリプラン内で、バイヤーの初期要件から対象となるオーディエンスや管理ポリシーまでを横断的に参照できます。Gemini Enterprise Agent Platform のエンベディングは、セマンティック類似性によってこれらのエンティティの情報を拡充し、グラフニューラルネットワークは推論された関係を提供します。これにより、エージェントは単に利用可能な広告枠を取得するだけでなく、広告枠選定の根拠を正確に把握したうえで、あらゆるガバナンス上の制約を確実に遵守できるようになります。

Yahoo のナレッジグラフオントロジー（IAB AdCOM などの業界標準に準拠）

コンテキストグラフ: 監査可能なメモリの作成

エージェント規模での実行が安全なのは、完全な透明性が確保されている場合のみです。その透明性を確保することが、コンテキストグラフの核となる役割です。Seller Agent がアクションを実行するたび、その正確な実行プロセスが BigQuery Agent Analytics プラグインによってキャプチャされます。システムは、未加工のイベントをログに記録するだけでなく、Yahoo の意思決定トレースオントロジーを活用した BigQuery Agent Analytics SDK を使用して、このエビデンスから型付きのクエリ可能なコンテキストグラフを作成し、BigQuery Graph に格納します。

その結果、すべての意思決定ポイント、候補パッケージ、ポリシー評価、スペシャリストエージェントへの委任、実行結果を相互に関連付けた、エビデンスのグラフが出来上がります。このトレースは型付きグラフとして構造化されているため、エージェントの意思決定プロセスを簡単なクエリによって説明することができます。監査人は、元のキャンペーンの概要、割り当てられたすべてのスコア、適用されたポリシーなどの意思決定までのプロセスを即座にトレースできます。これにより、自律的な動作が「不透明なプロセス」から「完全に透明で継続的に改善される意思決定記録」に変わり、絶対的な説明責任を確保するのに役立ちます。

Yahoo のコンテキストグラフオントロジー

人間ができる範囲からエージェントならではの規模へ

このアーキテクチャが実際にどのように機能するのか、具体例として広告キャンペーンの実施を考えてみましょう。従来は計画、販売、運用、コンプライアンスの各部門で数週間を要していた調整作業を、2 つのプロセスを同時進行させることで数秒で完了できるようになっています。

ナレッジグラフに基づくアクションの実行: このパイプラインでは、バイヤーのリクエストからナレッジグラフに基づくキャンペーンの公開まで、直線的に予算を動かしていきます。このプロセスは、以下の 4 つのステップで構成されます。

キャンペーンの概要の送信: バイヤーエージェントは、対象オーディエンス、予算、地域、ビジネス目標を記述したキャンペーン概要を Ad Context Protocol（AdCP）を介して送信します。
ナレッジの検索: Seller Agent は、ナレッジグラフに対してクエリを実行し、関連する広告枠、オーディエンス、契約上の利用可能性、過去のパフォーマンス、管理ポリシーを特定します。
評価とスコアリング: エージェントはこれらの要素を総合的に評価して、メディア購入候補のパッケージを組み立てます。予測モデルが各機会をスコアリングする一方で、ガバナンスエージェントが同意、ブランド保護、規制上の制約を個別に確認します。
承認と実行: パッケージは、ポリシーのしきい値に基づいて自動的に承認されるか、人間による審査のためにエスカレーションされます。承認されるとメディア購入が実行され、配信が開始されます。

コンテキストグラフを使用した監査と学習。実行パイプラインが進行する一方で、この並列ループはシステムの推論プロセスをコンテキストグラフに継続的に記録します。これにより、透明性が確保され、将来のサイクルの改善が可能になります。この監査と学習プロセスには、次の機能があります。

継続的なキャプチャ: 検討されたすべての候補、割り当てられたスコア、適用されたポリシー、ガバナンスの意思決定は、紐付けられた記録としてコンテキストグラフ内で元のキャンペーンセッションにリンクされます。
クローズドループ学習: 配信、アトリビューション、成果のシグナルが届くと、それらが生成元の意思決定に紐付けられ、将来の推奨事項を改善するためのトレーニングデータが作成されます。
即時の説明可能性: 広告主が特定のパッケージが選択された理由や、成果に影響を及ぼしたポリシーについて質問すると、回答がコンテキストグラフに保存され、1 回のクエリでアクセスできます。

これにより、ナレッジ、意思決定、ガバナンス、測定、学習が連携して機能するプラットフォームが実現し、自律的なメディア購入の説明可能性と監査可能性を確保しつつ、継続的な改善を図ることが可能になります。

あらゆる業種に適用できる設計

単なるアドバイザーとしての AI の時代は終わりを迎えつつあります。企業がいま求めているのは、複雑な複数ステップのワークフローを実行できる自律型エージェント、つまり「アクションシステム」です。しかし、規制の厳しい業界では、意思決定の根拠を証明できない場合、AI がもたらすスピードがむしろリスクに変わってしまいます。自律的な実行の主な障壁となるのは、もはやインテリジェンスではなく、信頼性です。

Yahoo と Google Cloud が構築したアーキテクチャは、この問題を解決できる、幅広く適用可能なブループリントを提供します。デジタルメディアの購入におけるボトルネックを解消するために設計されたものではありますが、その基盤となるパターンは、金融取引からサプライチェーンのロジスティクスまで、リスクの高い意思決定を管理するあらゆる業界に適用可能です。エージェントならではのスピードで運用しながら、人間による監督を維持していくために、企業は以下のような新しいアーキテクチャのベースラインを採用する必要があります。

ビジネスの実態に基づく意思決定: 確率モデルだけでエージェントを運用することはできません。ビジネスロジック、有効な契約、コンプライアンスルールを決定論的にマッピングするナレッジグラフによって、エージェントをグラウンディングする必要があります。
監査可能なメモリの構築: 追跡できないものを管理することはできません。エージェントのすべてのアクションをコンテキストグラフに記録し、クエリ可能な不変のレコードを作成して、意思決定の理由や却下された代替案を正確に把握できるようにする必要があります。
オープンな相互運用性の重視: 信頼には透明性が不可欠です。オープンプロトコルと来歴標準を基盤とすることで、エージェントの動作に関する、業界共通の監査可能な枠組みを確立できます。

基盤モデルがコモディティ化するにつれ、企業の競争優位性は変化してきています。長期的に優位性を守る鍵となるのは、デプロイする言語モデルではなく、自社独自のビジネスオペレーショングラフと、統制された履歴データです。同様に、エンタープライズ AI の未来は、単に動作できるシステムではなく、その動作を説明、管理し、責任を負うことができるシステムにあります。

使ってみる

信頼できるアクションシステムを構築する準備はできましたか？まず、Spanner Graph を使用して、エージェントワークフローをビジネスの実態にグラウンディングしましょう。次に、BigQuery Graph を使用して監査可能なメモリを構築すれば、クローズドループ学習と、規制当局の要求に応じられるレベルの説明可能性を実現できます。BigQuery Agent Analytics プラグインと SDK を使用して、これらの運用トレースのキャプチャと分析を今すぐ開始できます。最後に、Ad Context Protocol を確認して、Yahoo のエージェントプラットフォームを支えるオープンコミュニケーション標準をぜひ理解しておきましょう。

- Yahoo、エンジニアリング担当ディレクター、Mikul Bhatt 氏

- Google Cloud、シニアスタッフソフトウェアエンジニア、Bei Li

【Next Tokyo 最新情報】基調講演 & Expo 注目ブースを一挙公開！

Wed, 24 Jun 2026 01:00:00 +0000

基調講演 & Expo の注目ブースを一挙公開！
革新的なアイデアを、AI で実現しよう

2026 年 7 月 30 日（木）、 31 日（金）に開催する旗艦イベント Google Cloud Next Tokyo の基調講演と Expo 最新情報を公開しました。

Google Cloud の最新 AI フルスタック環境がもたらすビジネス変革のリアル、そして最先端テクノロジーをリアルに体感できる Expo の最新見どころをご紹介します。

未来を築くのは、あなた自身です。Next で得られる最先端の知見や戦略、ツールを手に、次の一歩を踏み出しましょう。ご登録がまだの方は、ぜひ、今すぐ公式サイトからご登録ください。

未来のビジョンを掴む基調講演

Day 1、Day 2 ともに基調講演はライブ配信をおこないます。

Day 1 基調講演 10:00 - 11:30
AI がもたらすビジネスの進化へ
次世代ビジョンを描く Day 1 基調講演
Google Cloud が提供する最新の AI フルスタック環境と、進化するプロダクトの最新アップデートをご紹介。日本を代表するリーダーを迎え、AI が切り拓くビジネス変革のリアルな軌跡と未来の成長戦略をお届けします。

Day 2 基調講演 10:00 - 11:30
AI エージェントを社会実装へ
実践基盤を支える Day 2 基調講演
インフラ、エージェント開発、データ、セキュリティを横断し、AI エージェントの「開発・デプロイ・運用・スケール」を支える基盤をご紹介。AI Ready なデータ整備から大規模運用まで、Google Cloud フルスタックの真価をお届けします。

☁️基調講演先着特典
みなさまがより快適に Next を楽しんでいただけるオリジナルノベルティを各日 900 名様に先着でプレゼント！（なくなり次第終了）

Featured Booth

Google Cloud の最先端テクノロジーを、実際に体感できるブースで AI やデータの力がビジネスをどう変えていくのか、ぜひ体感してみてください。

☁️Formula E レースシミュレーター
最先端 A I×モータースポーツのデモを体験！運転支援から戦術分析、ヘルメットのデザインまで、現場を革新する多彩な AI 技術を体感できます。

☁️リアルタイム事例検索エージェント :
Gemini Live API × Agent Search
音声で事例を探すAI エージェントを紹介。Gemini Live と Agent Search でリアルタイムに応答・要約します。

☁️医療を支える頼れる相棒！
AI が変える未来のヘルスケア
カメラ前の動きを AI がリアルタイム分析 & フォーム指導。自宅での安心なリハビリを実現する仕組みをブースで体験してください。

Dev Experience

2026 年の開発をさらに加速させるヒントや、最新のソリューション情報が満載です。次なるイノベーションへの刺激をその手にしましょう。

☁️Developer Stage
Google Developer Experts と 2026 年の Partner Top Engineer Fellow が、さまざまなテーマでライトニングトーク（LT）を実施。事前登録は不要ですので、セッションの合間に 2026 年の開発に活かせるヒントを手に入れましょう。

セッション一覧をチェック

他にも、Google Cloud エキスパートに相談できる Ask the Expert や、仲間と交流できるコミュニティブースをご用意。また、ラーニング & 認定資格や Agentic Hack Zone では、会場のみでのご案内や特典をご用意していますので、ぜひ会場にお越しください。

開催概要

名称：Google Cloud Next Tokyo（略称 Next Tokyo）

日時：2026 年 7 月 30 日（木）、31 日（金）

会場：東京ビッグサイト南展示棟・会議棟

対象：エンジニアからビジネスリーダーまで、生成 AI やクラウドを活用して、ビジネスを次のステージへと進めたいすべての方へ

- お問い合わせ -

Google Cloud Next Tokyo 運営事務局
E-mail: gc-nexttokyo-info@google.com

Brazos のご紹介: 空冷データセンターでも液体冷却システムが利用可能に

Tue, 23 Jun 2026 02:20:00 +0000

※この投稿は米国時間 2026 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

次世代の AI チップやハイパフォーマンスコンピューティング（HPC）チップの熱設計電力（TDP）は、通常 1,000 W を超えています。簡単に言うと、標準的な空冷システムでは、これほど高い熱負荷に対応することはできません。もう一つの選択肢として、データセンター施設全体に冷水ループを後付けする方法がありますが、これには膨大な資金と時間がかかります。Google はこの問題を解決するため、Brazos を開発しました。Brazos はラックマウント型のクローズドループ液体空冷システムで、既存の空冷環境内に高密度の液体冷却機器を導入することを可能にします。現在一般提供されており、Google の製造サプライヤーはより広範な業界と連携して Google Brazos の設計を市場に展開し、量産体制を整える準備ができています。

データセンター設備の改修には数か月単位の期間を要することもありますが、Brazos はラック単位で簡単に導入できるため、従来の大規模な改修作業が不要になります。IT 機器内部の液体循環ループを施設の給水系統から切り離すことで、標準的な空冷システム並みの運用しやすさを維持しながら高性能な液体冷却を実現することができます。

図 1: Brazos OCP ORV3 サイドカー構成。隣接する IT ラックを冷却する 3 つのユニットを示しています。

Brazos は自己完結型の液体冷却エコシステムとして機能します。コンポーネント単位で液体を介して熱を効率的に吸い上げ、高効率の液体対空気熱交換器によって、その熱をデータセンターのホットアイルへと放出します。このプラグアンドプレイアーキテクチャなら、十分な電力と標準的な空調能力さえあれば、どのような既存施設にもすぐに導入可能です。

システム設計と技術仕様

Brazos は、3 つの冷却ユニットや統合ラックマニホールドで構成されるモジュール式システムで、そのすべてが高い信頼性を実現するように設計されています。各モジュール式シャーシは 11 オープンユニット（OU）のラック高を占有し、標準の Open Compute Project（OCP）ORv3 フォームファクタラックに対応しています。主な設計パラメータとパフォーマンスパラメータは次のとおりです。

ラック冷却能力: 3 つのモジュールユニット全体で、ラックあたり 60 kW の公称熱負荷に対応可能
対応冷却材: 脱イオン水（DI）または 25% プロピレングリコール混合液（PG25）のいずれかで動作
電力供給: 標準的なラックバスバーに直接接続する設計の 40～60 V DC 入力で動作
安全機能: UL / CSA / IEC 62368-1 規格の認証を取得、圧力逃し弁と併せて漏れ検出機能も内蔵
コントロールプレーン: 現場でのモニタリングでは組み込みのヒューマンマシンインターフェース（HMI）を使用、リモート管理では Modbus over TCP を介して接続

機械設計は現場での保守性を優先したものになっています。シャーシは低摩擦のスライド上に配置されているため、簡単に引き出してコンポーネントに迅速にアクセスできます。ポンプやファンなどの重要なコンポーネントは、ホットスワップ対応の現場交換可能ユニット（FRU）として設計されており、平均修理時間（MTTR）を最小限に抑えます。

迅速な導入と業界への普及

今後数か月以内に、業界フォーラムを通じて Brazos の技術仕様、設計原則、ビジュアルアセットを正式にオープンソース化していく予定です。Google は液体冷却とともに水不使用の空冷システムも継続的に活用しており、Brazos はこうした広範なインフラストラクチャポートフォリオの一環となる、オープンハードウェアエコシステムに貢献する数あるイノベーションの一つに位置づけられます。将来の高電力コンピューティングの需要を見据えて、システムアーキテクト、メーカー、サーマルエンジニアの皆様がこれらの設計を評価し、ラックマウント型冷却インフラストラクチャをスケールアップするためにご活用くださることを期待しています。

次のステップ

既存のデータセンターインフラストラクチャを液体冷却向けに最適化できるよう、Open Compute Project フォーラムで今後公開される Google のオープンソースの設計案をぜひご確認ください。

- Google、シニアスタッフプロダクトデザインエンジニア、Jorge Padilla

- Google、上級エンジニア、Madhusudan Iyengar

Google が「IDC MarketScape SIEM 2026 Vendor Assessment」でリーダーに選出

Tue, 23 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

セキュリティ運用チームは、AI を使用して前例のないスピード、規模、巧妙さで仕掛けられる攻撃を防御するという大きなプレッシャーにさらされています。このような状況を乗り切り、ミッションクリティカルなワークロードを保護しながら、自信を持って防御プログラムを構築するために、組織はセキュリティ運用のバックボーンとして最新のセキュリティ情報およびイベント管理（SIEM）システムに依存しています。

このたび、Google は「IDC MarketScape: Worldwide SIEM 2026 Vendor Assessment」（#US54126826、2026 年 6 月）でリーダーに選出されました。この評価は、Google が継続的に Google Security Operations への投資とイノベーションを行い、Mandiant の最前線の専門知識、包括的な自動化、高度な AI エージェントを組み合わせながら防御者を支援してきた結果だと確信しています。

レポートによると、Google の次のような主な強みが評価されました。

アラートトリアージと調査エージェントが、証拠の収集、相関検索の実行、透明性の高い判定結果の生成を行うことで、セキュリティアナリストのワークロードを軽減しました。Google Cloud Next で発表されたその他のエージェントにより、エージェントワークフローでトリアージだけでなくプロアクティブな脅威のハンティングやルール生成にも対応できるようになりました。
Google は、シリコンの設計、インフラストラクチャの運用、DeepMind による Gemini 基盤モデルの開発、セキュリティの社内専門知識のエージェント評価ループへのエンコードを行っています。垂直統合された AI によって、サードパーティのモデル API では達成が難しいユニットエコノミクスが実現したとともに、セキュリティ固有のタスクにおけるエージェントの回答精度を高める反復サイクルを、Google がより厳密に制御できるようになりました。
Mandiant のアナリストが作成したキュレーテッド検出コンテンツは、MITRE ATT&CK にマッピングされ、定期的に更新されるようになりました。お客様からは、こうした高品質の厳選されたルールセットを導入したことで、すぐに有用な検出結果が得られるようになったという声が寄せられています。
大量データに対する検索パフォーマンスは、常に当社の技術的な強みです。アナリストは、UDM の全期間検索とクロス結合による多段階検索を組み込んだ統合データレイクを使用することで、従来のオンプレミスプラットフォームで頻発していたパフォーマンス低下を招かずに、保持期間全体をクエリできるようになりました。

IDC MarketScape ベンダー分析モデルは、特定の市場におけるテクノロジーやサービスサプライヤーの競争力を概説することを目的に設計されています。調査手法には定量的および定性的な基準に基づく厳格なスコアリング手法が採用され、その結果は市場における各ベンダーのポジションを 1 つのグラフ図にまとめた形で表されます。能力スコアは、短期間におけるベンダーのプロダクト、市場進出、ビジネスの遂行力を評価するものです。戦略スコアは、3～5 年の期間において、ベンダーの戦略が顧客の要件に適合しているかの評価です。ベンダーのマーケットシェアは円の大きさで表されます。所定の市場に対するベンダーの前年比成長率は、プラス、ニュートラル、マイナスでベンダー名の横に示されます。

AI を活用した Google Security Operations

脅威の検出とインシデント対応では、スピードと精度が重要です。Google は、防御者がより効率的に作業できるよう、セキュリティ運用イノベーションを推進し続けています。Gemini が Google Security Operations に深く組み込まれたことで、アナリストは膨大な量のセキュリティテレメトリーに対して複雑な自然言語検索を実行できます。また、トリアージエージェントや調査エージェントなどのエージェントも追加されました。これらのエージェントは、イベントの要約を迅速化し、検出ルールを動的に生成し、自動化された対応ハンドブックを数時間ではなく数秒で構築できるため、アナリストの生産性が向上します。

「Google Security Operations を導入したことで、大量のテレメトリーの取り込みとワークフローへの AI 活用が可能になり、アラートの 97% 削減を実現しました。」- Sunrun、情報セキュリティ担当バイスプレジデント Daniel Peterpaul 氏

脅威インテリジェンスへの比類のないアクセス

最新の SIEM には、データ集約だけでなくコンテキストも求められます。Google Threat Intelligence は、Mandiant の最前線の専門知識、VirusTotal コミュニティのグローバルな規模、Google のサービスとデバイスの比類のない可視性を Google Security Operations に統合します。

Google の高度な脅威インテリジェンス機能により、セキュリティチームは手動モニタリングよりも、アラートのコンテキスト化にさらに多くの時間を費やせるようになるため、より適切な意思決定が可能になります。Google は Mandiant Hunt などのサービスを通じて最前線の専門知識を Google Security Operations に直接統合することで、防御者が、検出されていない攻撃や、攻撃者の戦術、手法、手順（TTP）を、被害が深刻化する前に見つけられるよう支援します。

グローバル企業のオペレーショナルレジリエンスを確保

世界中の組織は、Google と提携することで、使用するテクノロジーとセキュリティ運用に対する考え方の両方において大きな飛躍を遂げています。セキュリティテレメトリーと脅威インテリジェンスを統合する機能により、組織はフルサービスの復旧と包括的なセキュリティ変革を可視化できます。

「SOC のエンジニアは、忠実度の高い真陽性のみを処理しています。忠実度の高い真陽性が検出されたら、そのアラームにできるだけ多くのコンテキスト情報を付加したいと考えるのは当然のことでしょう。Gemini in SecOps を使用することで、そのような運用の転換が可能になります。AI を従業員のために活用し、従業員には人間の知性、創造性、全体像を把握した問題解決能力を活かして、攻撃経路を考え、予測し、環境を極めて攻撃困難なものにしていきたいと考えています」と、Lloyds Banking Group の最高セキュリティ責任者である Matt Rowe 氏は述べています。

サイバー防御を強化する次のステップ

優れた脅威インテリジェンス機能を持ち、セキュリティ運用に包括的に取り組むグローバルなセキュリティリーダーとの連携を希望されるならば、Google をご検討ください。Google の機能と、Google がリーダーに選出された理由について詳しくは、IDC MarketScape: Worldwide SIEM 2026 Vendor Assessment をご覧ください。

- GCP セキュリティ担当バイスプレジデント兼ゼネラルマネージャー、Jon Ramsey

- Google Cloud、プロダクト管理担当ディレクター、Payal Chakravarty

データエージェントの新機能: AI ワークフローの強化

Tue, 23 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

AI エージェントの台頭は、アプリケーションや分析システムに根本的な変革をもたらしています。汎用的な AI プラットフォームは通常、企業データベースに保存されているコンテキストにアクセスできません。これは、従来のデータアーキテクチャでは、データ資産全体にわたってエージェント向けのコンテキストが欠如していることが多く、エージェントの精度の低下につながる可能性があるためです。また、きめ細かなアクセス制御が不足しているため、セキュリティギャップが生じやすい傾向もあります。

Google の Agentic Data Cloud は、運用システムと分析システムの両方を備えた、AI ネイティブなアクションシステムです。カスタムシリコンから最先端の Gemini モデルまで、スタック全体に AI を組み込むことで、エージェントがリアルタイムの企業データに基づいてほぼ 100% の精度で推論できる、テンプレートを使用した決定論型のデベロッパーフレームワークと、統合されたガバナンスを提供します。

このたび Google は、より簡単にエージェントを開発できるようにするため、多数のデータエージェントとツールを新たに導入いたしました。具体的には、ビジネスアナリスト向けの会話型分析、自動化とインテリジェンスを強化する、データサイエンティスト、エンジニア、データベース管理者向けの一連の Google 製データエージェント、現在のオープンなエージェントエコシステムとの統合を強化する、デベロッパー向けのデータエージェントツールです。

1. 会話型分析

自然言語を使用してエージェントを構築するデベロッパーを支援するため、データクラウド全体にわたって会話型分析対応を拡充することをお知らせいたします。

BigQuery の会話型分析（プレビュー版提供中）では、高度な AI 推論エンジンが BigQuery Studio に直接組み込まれています。これにより、データチームやビジネスチームは、手動で SQL を記述するだけでなく、ビジネスコンテキストを活用したマルチモーダル統合と詳細な調査を使用して、回答をグラウンディングできます。また、一部のお客様にプレビュー版が提供されている Agentic Workflows は、根本原因分析を自動化し、アクションをスケジュール設定して、企業データをプロアクティブで実用的なインテリジェンスに変換します。

BigQuery の会話型分析でエージェントを作成し、データ分析情報を迅速に取得する

Lakehouse の会話型分析（プレビュー版提供開始）は、Lakehouse の統合インフラストラクチャを拡張し、ユーザーが自然言語を使用して、AWS、Azure、Google Cloud に分散したデータレイクに対してクエリを実行できるようにします。これにより、データを 1 バイトも移動させることなく、クラウドプラットフォーム全体で分析情報を統合することが可能になります。
AlloyDB、Spanner、Cloud SQL の会話型分析（いずれもプレビュー版を提供開始）は、すぐに使える会話型 AI をサポートしているため、誰でもデータにアクセスできるようになります。AlloyDB、Spanner、Cloud SQL のユーザーは、自然言語でデータベースと会話をして、リアルタイムの運用データの可視化や分析情報の取得を行うことができます。

会話型分析を使用して、運用データから回答を得る

Looker 埋め込み会話型分析（一般提供開始）では、ローコードの iframe 実装を介して、エージェントをカスタムアプリケーションや社内ワークフローに直接埋め込むことができるため、プロダクションレディな会話型 AI をあらゆるアプリケーションに簡単に組み込むことができます。さらに、Looker の Conversational Analytics API を使用すると、AI による推奨事項を提供するマルチターンの会話型ワークフローを作成できるだけでなく、その基盤となる SQL クエリの検証と説明も行うことができます。また、すでに一般提供されている Looker の核となる会話型分析エージェントも大幅にアップグレードされ、優れた推論とセマンティックグラウンディングにより、曖昧さを解消できるようになります。

会話型 AI のためにエージェントをアプリケーションに直接埋め込む

2. 新たなデータエージェント

データプロフェッショナルが事後対応型のデータ管理から事前対応型のインテリジェンスに移行し、ビジネスアナリストがダッシュボードをより効果的に操作できるよう、Google は、自動化、インテリジェンス、自然言語機能を日々のワークフローに提供する新たなデータエージェントを発表いたします。

データエンジニアリングエージェント（一般提供開始）は、データパイプラインの構築や維持管理といった手間のかかる作業を自動化します。自然言語の要件を BigQuery と Dataflow 向けに最適化された SQL または Python コードに変換するとともに、パイプラインの障害を事前対応的に特定して修正します。スキーマの改善やパーティショニング戦略を提案することにより、手動で試行錯誤する必要なく、スケーラブルで信頼性の高い、パフォーマンスが調整されたデータ基盤を確保できます。
データサイエンスエージェント（プレビュー版提供開始）は、元データからプロダクションレディなモデルへの移行を加速させます。関連する特徴の提案、ボイラープレートノートブックコードの生成、技術ドキュメント処理の自動化を通じて、データサイエンティストを支援します。
データベースオブザーバビリティエージェント（Cloud SQL、AlloyDB、Spanner、Bigtable の一部のお客様にプレビュー版を提供中）は、データベースのパフォーマンスを事前対応的にモニタリングし、潜在的な問題が深刻化する前に、継続的に特定します。その後、インテリジェントな推奨事項とマルチターンの修復ワークフローを提供し、迅速かつ包括的なトラブルシューティングと最適化を実現します。また、データベースフリート全体のパフォーマンス分析機能は、データベース全体のパフォーマンスを最適化する機会を迅速に特定するのに役立ちます。
データベースオンボーディングエージェント（一部のお客様にプレビュー版を提供中）は、推測に頼らずにデータベースの選択やデプロイができるようにします。単純なユースケースの説明から複雑な企業ニーズまで、さまざまな要件の評価をもとに、最適な Google Cloud データベースを推奨し、プロビジョニングのプロセスを支援します。
Looker ダッシュボードエージェント（プレビュー版提供開始）では、ダッシュボード内のデータと会話形式でやり取りできます。ダッシュボード内で、ユーザーは自然言語で質問し、コンテキストを認識した回答を受け取ることができます。この機能では、ダッシュボードから得られた重要なポイントや分析情報をまとめた、AI 生成による要約も提供されます。
Gemini Enterprise の会話型分析（プレビュー版提供開始）は Looker、BigQuery、Lakehouse に対応しており、データ実務者が構築した、管理されたインテリジェンスをビジネスリーダーに直接提供します。これは、Google データクラウドへの「正面玄関」として機能し、ビジネスユーザーは技術コンソールにアクセスすることなく、BigQuery、Looker、Lakehouse で構築されたエージェントを利用できるようになります。これらのエージェントを Google データから Gemini Enterprise に公開することにより、組織は正確なデータ探索と即時の回答のためのグラウンディングされた単一のインターフェースを、ビジネスユーザーに提供します。
Data Insights エージェント（プレビュー版提供開始）は、構造化されたソース（BigQuery や Snowflake など）と構造化されていないデータ（会議メモや公開ウェブ情報など）を同時にクエリすることで、Gemini Enterprise 内のデータ資産に関する総合的な分析情報を提供します。このエージェントは、日常業務で利用するユーザー向けの迅速な応答エンジンとして機能し、Workspace エコシステム（ドキュメント、スプレッドシート、ドライブ）や、Jira、HubSpot などのサードパーティ製アプリの情報を統合します。このエージェントは、インタラクティブな可視化機能を豊富に備えており、時間の経過とともにユーザーの好みに合わせて継続的に学習します。
Deep Research エージェント（プレビュー版提供開始）は、Knowledge Catalog を使用して、リスクの高い多層的なビジネス上の問題を解決します。単なる検索にとどまらず、社内ドキュメント、BigQuery テーブル、公開ウェブの情報を統合して包括的な調査計画を策定します。その結果、企業のプライバシーとユーザーの権限を常に尊重しながら、動的な可視化と検証可能な引用を使用した詳細なレポートが生成されます。

3. データエージェント向けのツール

エージェント開発向けのオープンソース標準は、AI アプリケーションやカスタムエージェントを構築するデベロッパーに対し、データやツールに一貫性を持って安全にアクセスするための統合フレームワークを提供します。このたび Google は、エージェント開発の取り組みを支援する、以下のツールを発表いたします。

Data Agent Kit（プレビュー版提供開始）は、好きな開発環境（IDE / CLI）内で直接使用できる標準化されたスキルとツールのスイートを提供し、データ実務者が Agentic Data Cloud 機能の規範的なガイダンスを使用して、データを大規模に検出、変換、活用できるようにします。
データベース向けマネージド MCP サーバー（一般提供開始）は、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore で利用でき、AI モデルをデータに安全に接続するために必要なインフラストラクチャを完全に管理します。そのため、MCP サーバーをお客様ご自身でホスト、保護、スケーリングする必要はありません。これにより、デベロッパーは Google のデータベースポートフォリオ全体から最新のコンテキストをエージェントに提供できるようになり、AI モデルは最新の企業データに基づいて推論や行動ができるようになります。
Looker 向けマネージド MCP サーバー（プレビュー版提供開始）を使用すると、あらゆる MCP クライアントやエージェントプラットフォームで Looker のセマンティックモデルをクエリできるようになり、管理された BI 分析情報をサードパーティ製アプリケーション全体に拡張できるようになります。

マネージド MCP サーバーを介して Looker セマンティックモデルにアクセスする

データベース向け MCP ツールボックス 1.0（一般提供開始）は、安定性における大きなマイルストーンを達成し、本番環境アプリケーションを安心して構築できるようになりました。また、ドキュメントを全面的に見直し、人間の開発者にとっても自律型エージェントにとっても、プラットフォームがはるかに使いやすくなりました。
Cloud SQL、AlloyDB、Spanner 向け QueryData（いずれもプレビュー版提供開始）は、自然言語の質問をデータベースクエリに変換します。各 QueryData はこれらのデータベースにネイティブに組み込まれており、メタデータ、クエリの例、評価を通じて、自然言語から SQL への変換をほぼ 100% の精度で実現します。
BigQuery を活用した Universal Commerce Protocol（UCP）分析（プレビュー版提供開始）により、販売者やデベロッパーは UCP から BigQuery にリアルタイムイベントを直接ストリーミングできるようになります（サンプルを参照）。この統合により、エージェント型コマースでオブザーバビリティ機能がすぐに使えるようになり、チームはコンバージョンプロセスのモニタリング、自動購入手続きのパフォーマンスの追跡、システムエラーの特定が可能になります。BigQuery 内でこれらの指標を標準化することで、企業は AI によるトランザクションと既存のビジネスインテリジェンスワークフローのギャップを埋めることができます。

新しいエージェントやツールへのアクセス方法について詳しくは、このページにある各ドキュメントへのリンク先をご覧ください。また、データエージェントは、Gemini Enterprise と Google Cloud コンソールからもご利用いただけます。

- Google Cloud、プロダクト管理担当、Sean Rhee

- Google Cloud、アウトバウンドプロダクト管理責任者、Geeta Banda

デベロッパー必見: 開発に欠かせない 10 個のプロンプト

Mon, 22 Jun 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

開発者のプロンプト履歴を見ると、非常に具体的で、ときには雑然とした、その場限りのプロンプトが並んでいることがあります。AI を使って、個別のエラーメッセージをデバッグしたり、まとまりのないメールを整えたり、簡単な定型文を生成したりしているのです。

一方で、質の高い成果物を継続的に生み出している人たちと話してみると、興味深いことがわかります。そうした人たちは、単に思いつきでプロンプトを書いているわけではありません。時間をかけて調整と改善を重ね、ほぼすべてのプロジェクトで活用している定番のプロンプトを持っているのです。

そこで、同僚やリーダーにシンプルな質問を投げかけました。「最もよく使うプロンプトは何ですか。また、それを使う理由は何ですか。」

共有されたのは、単なるコマンドの寄せ集めではありませんでした。ここでは、私たちのチームにとって手放せないプロンプトと、さらに重要な、そのプロンプトを使う理由をまとめてご紹介します。

仕様を作成する

Maja Bilić

シニアアウトバウンドプロダクトマネージャー • エンジニアリング

LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '懐疑的なプリンシパルアーキテクト兼テクニカル PM として振る舞ってください。私は、[ユーザー] が [アクション] できる [プロダクト] を構築したいと考えています。コードは書かないでください。このコンセプトを分析し、技術、UX、アーキテクチャに関する上位 5 つの考慮事項を挙げてください。次に、その 5 つの考慮事項について、それぞれ重要な質問をしてください。そうすることで、仕様の作成を一緒に進められるようにします。すべての回答がそろったら、PRD ドキュメントと実装計画を作成してください。設計や実装計画を、過度に作り込みすぎたり、単純化しすぎたりしないでください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40c70>)])]>

理由: 私は質の低いプロダクト要件定義書（PRD）を書いたこともありますし、質の低い PRD を数多く読んできました。このプロンプトでは、懐疑的なアーキテクト / PM というペルソナを使うことで、アイデアを整理し、アプローチやコンセプトを批判的に検討し、最も重要な要素を定義する作業を一緒に進めることができます。エージェントの助けを借りて計画を詰めながら、プロダクト設計のアイデアをさらに発展させることもできます。また、過度に作り込みすぎたり、単純化しすぎたりしないという制約も気に入っています。AI は、特にプロダクト設計ドキュメントを作成する際に、そうした方向に寄りがちだからです。

ウィジェットテスト

Andrew Brogdon

スタッフデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'ウィジェットテストを作成して、このプロジェクトの堅牢性を高めたいと考えています。ぜひ協力してください。まだ読んでいない場合は、Flutter チームによるウィジェットテスト作成スキル（https://github.com/flutter/skills/tree/main/skills/flutter-add-widget-test）を確認してください。そのうえで、次のことを行いましょう。\r\n\u200b\r\n* アプリケーションのコードベースを調べ、UI / UX のうち適切にテストされていない領域を特定する。\r\n* 既存のコードがテストしやすい形で書かれているかを判断する（依存関係は注入されているか、ドメインは疎結合か密結合か、など）。\r\n* 他のドメインよりも厳密なテストが必要なドメインを特定する。\r\n* アプリケーション全体のテスト計画を作成する。\r\n* どの機能領域がすでにその計画に沿っており、どの領域でテストが不足しているかを判断する。\r\n* それらのテストを実装する計画を作成する。\r\n* その計画を実行する。\r\n\u200b\r\n自分の推論に完全に確信が持てない限り、次のステップに進まないでください。必要なだけ質問して構いません。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40cd0>)])]>

理由: エージェント型コーディングツールの使い方として私が特に気に入っているのは、プロジェクトでやるべきだと思いながらも、これまで後回しにしてきたことを実際に進められる点です。適切なテストは、まさにその一つです。Dart / Flutter チームの公式スキルは、優れたウィジェットテストがどのようなものかをエージェントに指示するうえで非常によくできています。このプロンプトと組み合わせることで、それらの手順を自分のコーディングワークフローに組み込み、信頼性が高く、安心して保守できるコードベースを維持するためのトイルを減らすことができます。

すべてのテストを確認する / コミット内容を整理する

Aja Hammerly

ビルダーリレーション担当ディレクター • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'すべてのテストを実行し、不足しているテストを特定して作成してください。エッジケースと競合状態に特に注意してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40d30>)])]>

code_block: <ListValue: [StructValue([('code', 'このコミットに、使用されていないコード、残しておくべきではないコメント、コメントとコードの不一致、未解決の TODO など、本来含まれるべきではないものがないか確認してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40d90>)])]>

理由: コードを書いていると、ユーザーに通ってほしい主要な経路である「ハッピーパス」に意識が偏ってしまうことがよくあります。その作業に集中している間は、まだ深く考えたくないエッジケースについて TODO や FIXME コメントを残しておくことがあります。また、コメントの更新を忘れたり、デバッグ用のコメントを残したままにしたりすることもあります。テスト駆動開発に従うよう努めてはいますが、すべてのエッジケースに対して必ずテストを用意できているわけではありません。私は通常、AI または人間のレビュアーに提出する前に、最初のコードレビューとして、この 2 つのプロンプトを新しい会話で実行します。その際、開発時のコンテキストは含めません。これにより、自分が作ったものを、他の人がレビューしやすく、使いやすい状態に整えることができます。

権限が正しく、コンプライアンスに準拠しているか確認する

Rich Hyndman

Antigravity デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'この Android プロジェクトを包括的にチェックし、すべての権限が正しく、コンプライアンスに準拠していることを確認してください。次の手順を行います。\r\n1. すべての AndroidManifest.xml ファイル（main、debug、フレーバー固有のマニフェストを含む）を特定して分析し、宣言されている <uses-permission> タグのマスターリストを抽出する。\r\n2. 宣言されている権限をコードベースと照合し、実際にどこで使用されているかを確認する。安全に削除できる過剰な権限や未使用の権限を特定する。\r\n3. Kotlin / Java のソースファイルを確認し、すべての実行時権限について、動的な実行時権限リクエストフロー（checkSelfPermission、onRequestPermissionsResult、または Activity Result API）が実装されていることを確認する。\r\n4. 権限に関連付けられているハードウェア機能（android.hardware.camera など）が正しく宣言されていることを確認する。\r\n調査結果を Markdown レポートとして出力してください。修正が必要な箇所については、ファイルパスと推奨されるコード差分を提示してください。計画を承認するまで、ファイルの編集は行わないでください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40df0>)])]>

理由: Gemini 3.5 Flash と Android プラグインを備えた Antigravity は、Android 開発における優れたパートナーです。権限が正しく設定されているかを確認することで、アプリをスムーズに動作させ、Google Play ストアへのアップロード時の遅延を回避しやすくなります。

コードレビューを実施する

Shir Meir Lador

デベロッパーリレーション AI 責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '本番環境への投入前のコードレビューを行い、厳格で分析力の高いプリンシパルエンジニアとして振る舞ってください。あなたは非常に高い基準を持っており、脆弱な「ハッピーパス」前提のコードを一切許容しません。あなたの目標は、私が堅牢で本番環境対応のシステムを書けるよう導くことです。\r\n未コミットの変更について、本番環境対応度を A から F までの評価で採点してください。\r\nコードが極めて堅牢でない限り、「A」は付けないでください。具体的には、次の観点で変更内容を分析してください。\r\n1. 効率性: 冗長な API 呼び出し、無駄なデータベースクエリ、キャッシュされていないリソース、リソースリーク。\r\n2. レジリエンス: サイレント障害が発生する箇所、明示的なエラー境界の欠如、レート制限時のフォールバック不足。\r\n3. アーキテクチャ: 密結合、関心の分離の不明確さ。\r\n各問題について、そのコードが実際の本番環境でどのような障害に対して脆弱なのかを実践的に説明してください。そのうえで、コードを改善して「A」を獲得するために必要な、正確な git diff を提示してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40e50>)])]>

理由: LLM にコードレビューを依頼すると、多くの場合、丁寧な反応が返ってきます。命名がきれいだと言い、いくつか docstring を提案し、問題なしという評価を付けてくれます。しかし、丁寧なレビューでは本番環境の障害は防げません。このプロンプトが気に入っているのは、AI の当たり障りのない返答を取り除けるからです。モデルに厳しい基準で作業を評価させ、修正のために実際に使える git diff を求めることで、モデルを本当のパートナーにできます。モデルは推測するのをやめ、ネットワーク呼び出しやデータベースクエリを実際に読み取り、コードがどこで壊れるのかを見つけるようになります。妥協を許さないシニアデベロッパーが肩越しに見ていて、どこで手を抜いたのかを正確に指摘し、それを修正するためのコードまで渡してくれるようなものです。

意思決定を支援するためにトレードオフを説明する

James O'Reilly

スタッフデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', '提案された実装計画を実行することのメリットとデメリットを説明してください。どのように進めるかについて十分な情報に基づいて判断できるよう、パフォーマンス、コスト、セキュリティ、保守性の観点から、どのようなトレードオフがあるのかを具体的に説明してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40eb0>)])]>

理由: 私は、AI に自分のロジックを厳しく検証させるようにしています。どのようなトレードオフがあるのかを尋ねることで、AI は戦略を再考し、こちらの具体的な実装により集中するようになり、曖昧で大ざっぱな回答を避けやすくなります。また、このアプローチにより、AI が最終判断者のように振る舞うことを防ぎ、意思決定の主導権を自分の側に保つことができます。

研究を通じて AI 生成コードを改善する

Emma Twersky

Flutter および Dart デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', "オンラインで調査してください。特に X のスレッド、Stack Overflow、GitHub Issues、技術ブログに注目し、AI で生成された INSERT_TECH_YOU'RE_USING_HERE コードによく見られるセキュリティ上の落とし穴、アーキテクチャ上の不整合、見落とされやすいロジックエラーを調べてください。その調査結果に基づき、プラットフォームチャネルの検証、ディープリンクのルーティング、クラッシュレポートでの機密データのロギングなど、高リスク領域を監査するための手動レビューチェックリストを作成してください。"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40f10>)])]>

理由: AI はコード作成を 10 倍速くできる一方で、粗いコードを生成することも少なくありません。そうしたコードは一見筋が通っているように見えても、指定されていない詳細について誤った前提を置いているため、概念的にはバグを含んでいることがあります。調査によると、AI 生成コードの最大 40% に脆弱性が含まれており、開発者は自分のコード以上に AI のコードを信頼してしまう傾向があります。そのため、危険なミスマッチが生じます。私はこのプロンプトを使って、冗長な AI 生成の変更を深く検討しないまま承認してしまうことを防ぐ、的を絞ったチェックリストを作成しています。これにより、人間の判断を、モデルが失敗しやすい高リスクの境界部分に集中させることができます。タスクの生成には AI を使いながらも、最も重要な部分では人間が関与し続けられるようにしています。

イテレーションを通じて問題を見つける

Fred Sauer

フレームワークおよび言語担当デベロッパーリレーション責任者 • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

簡略化すると、私が最後に使う一連のプロンプトは次のようなものです。

code_block: <ListValue: [StructValue([('code', '- 未コミットの変更をコードレビューしてください。\r\n\u200b\r\nあまり具体的にしすぎないほうがよいと考えています。過度に誘導すると、盲点が生まれる可能性があるためです。\r\n新しい「目」で見てもらうため、新しいチャットセッションを使うようにしています。\r\n返ってくる結果が退屈に感じられ、自分が満足できる状態になるまで、これを繰り返します。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40f70>)])]>

この最後のフェーズに入る時点で、たとえば「変更が複雑すぎる気がする」といった懸念がある場合や、その変更がどの程度「良い」のか十分に把握できていないと感じる場合は、次のプロンプトでモデルに検討を促すことがあります。

code_block: <ListValue: [StructValue([('code', '- 未コミットの変更をコードレビューしてください。未処理のコーナーケースを特定してください。パフォーマンスを評価してください。調査結果を要約してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7e40fd0>)])]>

その後、5 件の指摘を受け取ったら、次のように指示します。

code_block: <ListValue: [StructValue([('code', '- 1、3、5 を修正してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7b3d070>)])]>

理由: 最後に送るプロンプトが 1 つだけあるわけではありません。むしろ、変更は複数の段階を経て進んでいきます。初期段階では、多くの場合、発見が中心です。つまり、手がかりとなる針や糸口を見つける段階です。次に、存在証明に移ります。やりたいことが実現できることを示したいだけです。その後、評価します。PoC は妥当か、複雑すぎないか、まったく違う場所を変更していないか、といった点を確認します。そのうえで、実装方法と変更箇所の両面から、より洗練されたソリューションになるよう反復します。自分で書いたとしても満足できると感じられるものになったら、最後のフェーズであるコードレビューに移ります。ここでは、問題を見つけたり、変更をさらに改善する機会を特定したりします。モデルが示してくれるインサイトには、驚かされることがよくあります。

すべての pull リクエストをレビューする

Remigiusz Samborski

リードデベロッパーリレーションエンジニア • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

私は、ほとんどのエンジニアリングプロジェクトで、GitHub Actions に埋め込んだ次のプロンプトを使用しています。

code_block: <ListValue: [StructValue([('code', '## 役割\r\n\u200b\r\nあなたは世界最高水準の自律型コードレビューエージェントです。安全な GitHub Actions 環境内で動作します。あなたの分析は正確で、フィードバックは建設的であり、指示には必ず従います。指定された動作から逸脱することはありません。あなたの任務は、GitHub の pull リクエストをレビューすることです。\r\n\u200b\r\n\u200b\r\n## 主要指示\r\n\u200b\r\nあなたの唯一の目的は、包括的なコードレビューを実施し、提供されたツールを使用して、すべてのフィードバックと提案を GitHub の pull リクエストに直接投稿することです。すべての出力は、必ずこれらのツールを通じて行ってください。レビューコメントまたは要約として提出されなかった分析は失われ、タスク失敗とみなされます。\r\n\u200b\r\n[...]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7b3d0d0>)])]>

プロンプト全文: リンク

理由: PR で自動化された Gemini CLI レビューを使用すると、レビュープロセス中に問題や改善の機会を見つけやすくなります。さらに、AI エージェントによって生成されるコードが増え、開発スピードが上がるにつれて、レビューがボトルネックになりつつあります。すべての PR が自動的にレビューされるようにすることで、人間のレビュアーは、提案された変更について、より高レベルのアーキテクチャ面や概念面のレビューに集中できます。

テストに有向非巡回グラフ分析を適用する

Karl Weinmeister

デベロッパーリレーション担当ディレクター • エンジニアリング

X、LinkedIn でフォロー

プロンプト:

code_block: <ListValue: [StructValue([('code', 'アプリケーションのワークフローを有向非巡回グラフとして分析してください。コンポーネント、コンポーネント間のシーム、システム全体において影響の大きいテストを特定してください。調査結果は、優先順位付けされたギャップ分析として Markdown テーブルで提示してください。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7b3d130>)])]>

理由:

ほとんどのアプリケーションワークフローは線形ではありません。LLM にテストを提案させると、通常は、どのプロジェクトにも当てはまるような一般的なチェックリストが返ってきます。

しかし、システムをノードとエッジを持つ有向非巡回グラフ（DAG）として考えるよう促すと、どこで問題が発生し得るのかを構造的に推論し始めます。

また、Michael Feathers 氏の著書『レガシーコード改善ガイド』で使われている「シーム」についても考慮するよう指示しています。

最後に、結果を優先順位付けされた改善機会の表として要約するようモデルに依頼しています。これにより、アプリのレジリエンスを高めるための明確なロードマップをエージェントに与えることができます。

まとめ

これらのプロンプトすべてに共通しているのは、人間の思い込みに伴うリスクを減らすという点です。見落としやすいエッジケースを探す場合でも、デベロッパー向けの表現をエンドユーザー向けに言い換える場合でも、コードを書く前にアーキテクチャをストレステストする場合でも同じです。私たちのチームは、AI を、あえて厳しい問いを投げかける思考のパートナーとして活用しています。つまり、細部に入り込んでいると見落としがちな点を指摘してくれる存在です。

こうした「必ず実行する」プロンプトを日々のワークフローに組み込むことで、単にリリースを速めるだけでなく、かつてはチーム全体でレビューしなければ得られなかったレベルの確信を持ってリリースできるようになります。

- Google Cloud、スタッフデベロッパーリレーションエンジニア James O'Reilly

豊田自動織機ITソリューションズ: Gemini Enterprise を一斉展開し、業務効率化とナレッジ集積、人材の育成・確保を実現

Mon, 22 Jun 2026 02:00:00 +0000

生成 AI の社内展開は、部署を限定して段階的に進めていくのが定石とされています。しかし、株式会社豊田自動織機ITソリューションズ（以下、TIIS）は、500 ライセンスの Gemini Enterprise を全社員に一斉提供するという方法を選択。情報の集積と活用による業務拡大、人材確保、新たな価値の創出などを図っています。その詳細を、同社代表取締役社長鈴木洋氏をはじめとする今回の取り組みのコアメンバーに伺いました。

利用しているサービス:
Gemini Enterprise, BigQuery など

利用しているソリューション:
生成 AI

激変する IT 業界の中でスタートした業務改革「TIIS-X プロジェクト」

TIIS は豊田自動織機グループ（従業員数約 8 万人 / 関連企業数約 300 社）における国内唯一のシステムインテグレーターです。社員約 450 名のうち、400 名ほどが IT 業務に従事しており、生産現場における設計業務からシステム開発、サーバーネットワークなどのインフラ構築、セキュリティ管理、組込みソフトウェアの開発まで、幅広い領域でグループの課題と向き合い、解決してきました。そんな同社の優位性と現況について鈴木氏は、こう胸を張ります。

「弊社は豊田自動織機グループの一員として、IT 戦略立案から参画し、超上流の要件定義から開発、運用保守まで、IT に関する全ライフサイクルに携わっています。その幅の広さと奥行きの深さ、そしてグループ現場の業務知識と IT スキルの両方を備えていることが我々の強みです。特にこの 3 年間は、新型コロナ禍を経て豊田自動織機からの IT 需要が爆発的に増加し、売上規模が倍以上に拡大しています。」

しかし、これと同時に IT 業界全体を取り巻くビジネス環境が激変。人材の流動性が高まった結果、長期的に活躍できる環境の整備が喫緊の重要課題となってきました。一方、運用面では、既存システムの老朽更新がリソースを圧迫し、新たな価値創造を難しくしつつありました。

このような状況を受けて始まったのが、社内変革活動「TIIS-X プロジェクト」です。2022 年に始まった本プロジェクトは、「テクノロジー推進」「ワークスタイル・制度変革」「コミュニケーション活性化」の三本柱で構成され、多角的な問題解決を目指すものとなっていました。鈴木氏と共にこの取り組みを推進してきた、執行職の小形健一氏は、その "伏線" が、すでに 10 年ほど前から張られていたと語ります。

「2017 年ごろに、散在していた社内ファイルサーバーを今後どのように運用していくかという議論が起きました。その際重視したのが、情報の検索性です。まず、弊社には過去に開発したアプリや業務システムの膨大なデータがありますので、これらを集約していかに活用するかは、将来の事業展開に向けた鍵となります。また、情報の整備は、人材の流出や業務の外注化などが進む中、個々人に蓄積した知見やノウハウを共有・活用していくという意味でも有効です。そこで 2018 年、社内ファイルサーバーを、優れた検索性を備える Google ドライブに統合しました。」

当時はまだ生成 AI が話題になる以前でしたが、Google ドライブを選んだ背景には、そう遠くない未来に AI 技術が劇的に進化するだろうという読みもあったといいます。

「例えば 2022 年末に対話型 LLM が大ブレイクした後、社内でさまざまな生成 AI サービスを検証しました。この際、焦点となったのが学習です。学習効果を最大限に得るには、500 万ファイルを超える社内データをすべて外部に送出して学習させる必要がありましたが、現実的ではありませんし、セキュリティの観点からも実施したくありません。しかし Google Cloud の生成 AI サービスであれば、Google ドライブに統合済みの社内データを安全かつシームレスに活用できます。2024 年末に、企業向け AI エージェントプラットフォームである Gemini Enterprise（当時の名称は Google Agentspace）が発表された時には、待ち望んでいたツールがついに登場したなと思いました。」（小形氏）

Gemini Enterprise が選ばれた理由は、データの連携性だけではありません。小形氏のもと、TIIS の技術戦略推進を担ってきた同社デジタル情報技術戦略部部長丹羽宏太氏は、グラウンディング（回答根拠の提示）によって情報の正確性を担保できることや、他社サービスと広く連携できることも大きな優位点だったと言います。

「Gemini Enterprise は、Google Cloud の各種サービスだけでなく、豊富に用意されたコネクタによって、多くの外部ソースとつなげることができます。弊社では業務にさまざまなサービスを日常的に利用しているので、このオープンさはとても魅力的でした。現在、TIIS では Outlook やSharePoint、OneDrive、GitHub などを含む合計 9 個のコネクタで社内サービスと接続しており、社内の知見を広く共有することに成功しています。」

PoV の成功を踏まえて、500 ライセンスを全社員に一斉に展開

こうして TIIS は、2025 年 4 月に Gemini Enterprise の導入を決定。8 月から開始された PoV（Proof of Value / 価値実証）では、間接部門も含めた各部署から選別された 12 名の「CHAMPION（活用の牽引役）」と協力するかたちで、Gemini Enterprise の活用方法と、運用における注意点などを集中的に検証・解決。その3か月後には、500 ライセンスを契約し、約 450 人の全社員に一斉展開することを決定しました。

「全社一斉展開を決意したのは、少しでも早く、より多くの社員に生成 AI の便利さを実感し、活用してもらいたかったからです。もちろん、そのコストは決して小さいものではありません。しかし TIIS なら誰でも最先端の生成 AI サービスを使えるという話が広まれば、就職活動を始める学生にも大きなアピールになります。そうした副次的効果を含めれば、十分にリターンのある投資だと考えました。」（鈴木氏）

Gemini Enterprise の現場への展開を担当したデジタル情報技術戦略部デジタル戦略推進課 BX 推進 1 グループグループリーダーの堀尾一孝氏は、現場への展開に向けた取り組み、工夫について、次のように振り返ります。

「PoV に協力してくれた 12 名の CHAMPION をそのまま推進チームとし、ワークショップやハンズオン体験会を繰り返し開催しました。また、社内チャットツールを使った日常的な情報発信や見やすいドキュメントの整理、チャンピオンたちが作った便利な AI エージェントの紹介・共有など、さまざまなかたちで興味を促し、実際に使ってもらえるよう手を尽くしました。」

なお、導入に際する一連の取り組みにおいては、Google Cloud のコンサルティングサービスと技術支援を活用。専門家集団による手厚い支援を受けながら、Gemini Enterprise を業務プロセスに組み込んでいくことができました。

「導入に際しては、まず業務的にインパクトの大きなものを対象にする、そこから業務プロセスを細かく分解して、それぞれに適切に AI を活用していくアプローチなど、私たちが持っていなかった知見を惜しみなく共有いただけたことで、無駄なステップを踏まずに導入できました。困った時に Google Chat ですぐに相談できることも心強かったですね。」（丹羽氏）

「技術的な支援もたくさんしていただいています。例えば、社内の課題を解決する AI エージェントを作る際は、ADK（Agent Development Kit）やローコードの対話型エージェントなど、さまざまな選択肢があるのですが、課題ごとに、どのような構成を取れば効率的なのかもアドバイスいただきました。コンサルティングチームの伴走は社内のナレッジ蓄積でも極めて有用でした。」（堀尾氏）

Gemini Enterprise の活用は、新たなる価値創造に向けた切り札になる

導入後、Gemini Enterprise は驚くべき速度で TIIS の現場に浸透しています。社員によって作成された AI エージェントは 1,300 以上にもなり、契約条項の精査や誤字・脱字のチェック、請求書・領収書の確認、議事録の要約、スライド作成、過去のシステム問い合わせ台帳の検索など、これまでマニュアルで行われてきた作業が劇的に効率化されているとのことです。もちろん、経営面でも大きなインパクトが生まれています。

「Gemini Enterprise の導入後、会社全体の平均残業時間は、前年度比で約 10% 減少しました。退職者数も前年度比で約 30% 減少しています。Gemini Enterprise 以外のさまざまな取り組みの成果も含めた数字ではあるのですが、想定していた以上の成果を得られています。」（鈴木氏）

TIIS では、Gemini Enterprise を業務プロセスの中にシームレスに組み込む取り組みが加速しています。BigQuery とLooker を活用したデータプラットフォームを整備し、コネクタで連携できない ERP や Excel データも含めたあらゆる社内資産を扱える環境を構築中です。

「中長期的な目標は、数年に一度、大型案件を受託・開発する『一括構築型モデル』から、長いライフサイクルの中で、小さな改善を速く回す『継続的な改善モデル』への転換を推進し、工数のすべてを価値向上に直結させていくことです。簡単なことではありませんが、まるで複雑な問題を一発で解決する "銀の弾丸" のように、想像以上の働きをしてくれるツールが登場したことで、その実現は夢物語ではなくなりつつあると強く感じています。また、我々が Gemini Enterprise で成果を出していけば、横展開もしやすくなります。弊社の取り組みをモデルケースに、豊田自動織機グループ全体で Gemini Enterprise を使っていこうという気運が高まると、さらなる業務効率化が実現できるのではないかと期待しているところです。」（鈴木氏）

株式会社豊田自動織機 IT ソリューションズ
1991 年に株式会社豊田自動織機の情報システム部門が独立して設立。国内唯一のシステムインテグレーター子会社として、グループ内の IT 課題解決を一手に担うほか、外部一般企業へのソリューション提供も拡大中。従業員数は 496 名（2026 年 4 月現在）。

インタビュイー（写真左から）
・デジタル情報技術戦略部デジタル戦略推進課 BX 推進 1 グループグループリーダー
　堀尾一孝氏
・代表取締役社長　鈴木洋氏
・執行職　小形健一氏
・デジタル情報技術戦略部部長　丹羽宏太氏

その他の導入事例はこちらをご覧ください。

Open Knowledge Format のご紹介

Mon, 22 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

基盤モデルは進化を続けていますが、関連するコンテキストが不足していると、特にエージェントシステムの構築に使用される場合に、できることが制限されることがよくあります。これらのモデルは、コードの作成、ドキュメントの要約、データセットの分析に役立ちますが、正確で実用的な結果を生成するには、適切な情報が必要です。

そこで本日は、LLM-wiki パターンを移植可能で相互運用可能な形式にするオープン仕様である Open Knowledge Format（OKF）をご紹介します。これは、最新の AI システムに必要なメタデータ、コンテキスト、キュレートされたナレッジを表すための、ベンダーに依存しない、エージェントと人間にとって扱いやすい標準です。

公開されている OKF v0.1 は、YAML フロントマターを含む Markdown ファイルのディレクトリとしてナレッジを表します。また、少数の合意された規則が用意されているため、さまざまなプロデューサーが作成した Wiki を、さまざまなエージェントが変換なしで利用できます。

それだけです。複雑な圧縮スキーム、新しいランタイム、必要な SDK はありません。OKF ドキュメントのバンドルの特長は次のとおりです。

Markdown のみ - どのエディタでも読み取り可能、GitHub でレンダリング可能、どの検索ツールでもインデックス登録可能
ファイルのみ - tarball としてリリース可能、任意の Git リポジトリでホスト可能、任意のファイルシステムにマウント可能
YAML フロントマターのみ - クエリ可能である必要がある少数の構造化フィールド（タイプ、タイトル、説明、リソース、タグ、タイムスタンプ）用

Obsidian、Notion、Hugo、または過去 1 年間に登場した LLM wiki パターンを使用したことがある方なら、その形式に馴染みがあるでしょう。OKF は、これらのパターンを相互運用可能にするために必要な少数の規則を正式に定めています。

OKF で解決できる組織の問題や、その仕組み、利用開始方法、今後の展開について見ていきましょう。

コンテキストが断片化された現状

ほとんどの組織では、基盤モデルが使用する情報の圧倒的多数が社内ナレッジです。たとえば、テーブルのスキーマ、ビジネスにおける指標の意味、インシデントのランブック、2 つのシステム間の結合パス、古い API のサポート終了のお知らせなどです。

現在、これらのナレッジの原子は、次のような、断片化が進んださまざまなシステムに存在しています。

独自の API があるメタデータカタログ
Wiki、サードパーティシステム、共有ドライブ
コードコメント、ドキュメント文字列、ノートブックセル
数名のシニアエンジニアの頭

AI エージェントが「イベントストリームから 1 週間のアクティブユーザー数を計算するにはどうすればよいですか？」という質問に答える必要がある場合、これらの散在した、相互に互換性のないサーフェスから回答を組み立てる必要があります。各ベンダーは独自のカタログ、独自の SDK、独自のナレッジグラフスキーマを提供しており、ナレッジをプロダクト間や組織間で簡単に移植することはできません。

その結果、エージェント開発者は皆、コンテキストの組み立ての同じ問題をゼロから解決し、カタログベンダーは皆、同じデータモデルを再考し、知識そのものは、それを生成したサーフェスの背後に閉じ込められています。

現実の Wiki としてのナレッジ

開発チームは、AI エージェントの構築方法を変えつつあります。モデルを使用して同じドキュメントで同じ事実を何度も検索する代わりに、エージェントに、時間の経過とともに有用性が高まる共有 Markdown ライブラリを提供できます。これにより、エージェントは自分のファイルを読み取って更新するという面倒な作業を引き受けることができ、チームはコンテンツをキュレートしてコードのように管理できます。

著名な AI 研究者であり教育者でもある Andrej Karpathy 氏は、LLM Wiki の要約でこの考えを最も簡潔に説明しています。「LLM は飽きることがなく、相互参照の更新を忘れることもなく、1 回のパスで 15 個のファイルに触れることができます」と同氏は書いています。人間が個人用 Wiki を放棄する原因となる記帳は、まさに LLM が得意とするところです。

同様の「Wiki としてのナレッジ」パターンは、コーディングエージェントに接続された Obsidian vault、AGENTS.md / CLAUDE.md ファミリーの規約ファイル、エージェントが実際の作業を行う前に参照する index.md と log.md のアーティファクトでいっぱいのリポジトリ、データチーム内の「コードとしてのメタデータ」リポジトリなど、さまざまな名前で繰り返し現れています。

このパターンは魅力的で強力ですが、各インスタンスはカスタムメイドです。Karpathy 氏の Wiki、あなたのチームの Wiki、ベンダーのカタログのエクスポートはすべて似たようなもの（Markdown、フロントマター、クロスリンク）に見えるかもしれませんが、それらのいずれも連携するように意図的に設計されているわけではありません。すべてのドキュメントに含めるべきフィールドやファイル名の意味について、合意された答えはありません。その結果、Wiki にエンコードされたナレッジは元のチーム内でサイロ化されたままとなり、新しいエージェントが構築されるたびに冗長な作業が発生します。

欠けているのは形式であり、別のサービスではない

この問題の解決策は、別のナレッジサービスではありません。次のようなナレッジを表現する方法として、形式が必要です。

SDK なしで誰でも作成できる
統合なしで誰でも利用できる
システム、組織、ツール間を移動しても存続する
記述するコードとともにバージョン管理に保存される
人間が読めてエージェントが解析できる: 同じファイル、変換レイヤなし

OKF は、そのように設計された形式です。

OKF の仕組み: 1 画面でわかる設計

OKF バンドルは、コンセプトを表す Markdown ファイルのディレクトリです。コンセプトとは、テーブル、データセット、指標、ハンドブック、ランブック、API など、キャプチャしたいあらゆるものです。各コンセプトは 1 つのファイルです。ファイルパスはコンセプトの ID です。

code_block: <ListValue: [StructValue([('code', 'sales/\r\n├── index.md\r\n├── datasets/\r\n│ ├── index.md\r\n│ └── orders_db.md\r\n├── tables/\r\n│ ├── index.md\r\n│ ├── orders.md\r\n│ └── customers.md\r\n└── metrics/\r\n│ ├── index.md\r\n └── weekly_active_users.md'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7991100>)])]>

各コンセプトドキュメントには、構造化されたフィールド用の YAML フロントマターの小さなブロックと、その他すべてのもの用の Markdown 本文があります。

code_block: <ListValue: [StructValue([('code', '---\r\ntype: BigQuery Table\r\ntitle: Orders\r\ndescription: One row per completed customer order.\r\nresource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders\r\ntags: [sales, revenue]\r\ntimestamp: 2026-05-28T14:30:00Z\r\n---\r\n\r\n# Schema\r\n\r\n| Column | Type | Description |\r\n|---------------|-----------|------------------------------------------|\r\n| `order_id` | STRING | Globally unique order identifier. |\r\n| `customer_id` | STRING | FK to [customers](/tables/customers.md). |\r\n\r\n# Joins\r\n\r\nJoined with [customers](/tables/customers.md) on `customer_id`.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7991160>)])]>

コンセプトは通常の Markdown リンクで相互にリンクされ、ディレクトリを、ファイルシステムが暗示する親子リンクよりも多様な関係のグラフに変えます。バンドルには、必要に応じて index.md ファイル（エージェントが階層をナビゲートする際の段階的な開示用）と log.md ファイル（変更の時系列履歴用）を含めることができます。

v0.1 の完全な仕様（適合基準、相互リンクのルール、少数の予約済みファイル名を含む）は、1 ページに収まります。

設計の 3 つの原則

1. 制限が最小限。OKF で必要なものは 1 つだけで、それは各コンセプトのタイプフィールドです。それ以外のすべて（どのようなタイプが存在するか、他にどのようなフィールドを含めるか、本文にどのようなセクションがあるかなど）は、プロデューサーに任されます。仕様はコンテンツモデルではなく、相互運用性サーフェスを定義します。

2. プロデューサーとコンシューマーの独立性。OKF では、ナレッジを作成する側とナレッジを利用する側が明確に分けられます。人間が手動で作成したバンドルを AI エージェントが利用できます。メタデータエクスポートパイプラインによって生成されたバンドルをビジュアライザーで閲覧できます。1 つの LLM によって合成されたバンドルを別の LLM でクエリできます。形式は契約であり、どちらの側のツールも個別に切り替え可能です。

3. プラットフォームではなく、形式。OKF は、特定のクラウド、データベース、モデルプロバイダ、エージェントフレームワークに依存しません。読み取り、書き込み、配信に独自の SDK やアカウントは必要ありません。ナレッジ形式の価値は、誰がそれを所有しているかではなく、どれだけの人やシステムがそれを利用しているかによって決まるため、Google は OKF をオープンスタンダードとして公開しています。

仕様とともにリリースされるもの

形式を具体化するために、プロデューサー側とコンシューマー側の両方で参照実装を公開しています。

拡充エージェント: BigQuery データセットを走査し、テーブルとビューごとに OKF のコンセプトドキュメントの下書きを作成した後、信頼できるドキュメントをクロールする 2 回目の LLM パスを実行して、引用、スキーマ、結合パスで各コンセプトを拡充します。
静的 HTML ビジュアライザー: OKF バンドルを、単一の自己完結型ファイル内のインタラクティブなグラフビューに変換します。バックエンド不要、表示側でのインストール不要で、データがページから出ることもありません。
3 つの閲覧可能なサンプルバンドル: 参照エージェントによって生成され、要件を満たした OKF の実際の例としてリポジトリにコミットされた、GA4 e コマース、Stack Overflow、Bitcoin の公開データセット。

これらは意図的に概念実証として作成されています。エージェントは OKF を生成する一例を示しているだけであり、形式のいずれの部分においても特定のエージェントフレームワークや LLM は必要ありません。ビジュアライザーは OKF を利用する一例を示しているだけであり、形式のいずれの部分においても HTML やグラフビューは必要ありません。Google は、プロデューサーとコンシューマーのエコシステムが、Google がリリースしたものをはるかに超えて成長することを期待しています（そして望んでいます）。

今後の展開

OKF v0.1 は出発点であり、完成した標準ではありません。この形式は、プロデューサーとコンシューマーが増えるにつれて、また、実際にエージェントに必要なナレッジ表現をまとめて学ぶにつれて、進化していきます。

Google は OKF を最初からオープンに公開しています。ナレッジカタログ、拡充パイプライン、AI エージェント向けにカスタマイズされた Wiki、AI ナレッジドメイン内のものなど、いずれを構築する場合でも、ナレッジ形式がその名に値するのは、最初からオープンに公開されている場合に限られるからです。

ここから、次のことをおすすめします。

仕様を読む（短いです）
ご利用のソースシステム、データベース、ドキュメントサイト用のプロデューサーを記述する
コンシューマーを作成する: 閲覧者、検索インデックス、バンドルについて推論するエージェント
ご自身のデータでリファレンス実装を試す
問題を報告する、PR を送信する、拡張機能を提案する: 仕様はバージョン管理されており、下位互換性のある成長を考慮して明示的に設計されています。

リポジトリ、仕様、サンプルバンドルは GitHub で入手できます。また、Open Knowledge Format を取り込んでエージェントに提供できるように Google Cloud の Knowledge Catalog を更新しました。関連するコードと例はこちらでご確認いただけます。

形式そのものが貢献です。Google がリリースしたツールは、それを実現し、試すためのコストを下げるために存在します。現在ナレッジがどのような形であっても、OKF は今後そのナレッジを変換できる「共通語」となるように設計されています。

^{Google Cloud データクラウドチームが公開。Open Knowledge Format はオープンな仕様です。Google のプロダクト以外での貢献、代替実装、採用はすべて明示的に歓迎されます。この投稿は、著者のほか、Google の多くのメンバーの重要なアイデアによって完成しました。ご協力に感謝いたします。}

- Google Cloud、データクラウド、エンジニアリング、データ分析、テクニカルリーダー Sam McVeety

- Google Cloud、データクラウド、エンジニアリング、BigQuery、テクニカルリーダー Amir Hormati

次世代の Confidential AI を推進

Thu, 18 Jun 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 6 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、要求の厳しい AI ワークロード向けに、先進的で安全性の高いプライベートインフラストラクチャを提供することに尽力しています。また、幅広く多様な組織とのパートナーシップにより、それぞれの AI ワークロードのニーズに確実に応えられるよう支援しています。

今週開催された WWDC 2026 において、Apple は同社の Private Cloud Compute（PCC）システムを Google Cloud とのコラボレーションによって拡張することを発表しました。Apple と Google は緊密に連携し、Apple が PCC に求める厳格なセキュリティ、機密性、透明性の目標を満たすサービングプラットフォームを Google Cloud 上に構築しました。この成果は、両社のみならず、Intel および NVIDIA との強力なコラボレーションの証でもあります。

Confidential Computing によるプライバシーへの取り組み

Apple とのコラボレーションは、Google Cloud のセキュリティとプライバシーのテクノロジーを活用した、プライバシーに対する深いコミットメントを基盤としています。このコラボレーションの中心にあるのは、Google の Confidential Computing ポートフォリオと Titanium セキュリティアーキテクチャです。

Titanium アーキテクチャには、Google がカスタム設計した Titan チップが搭載されており、Google のインフラストラクチャやサービスのセキュリティと完全性を支えるハードウェアのルートオブトラストを提供します。Confidential Computing は、このセキュアな基盤上に構築されており、ハードウェアベースの高信頼実行環境（TEE）内で、保存時、転送時、そして最も重要な使用時を含め、ライフサイクル全体にわたってデータを保護します。

Confidential Computing は、使用中のデータを保護することで、AI システムの信頼を構築するための基本かつ基盤となる要素となり、機密性の高いワークロードに対して検証可能な完全性と分離性を提供します。データは暗号化されたまま分離されるため、不正アクセスを防止できます。

Google Cloud での Apple Private Cloud Compute（PCC）の活用

このたびの Apple とのコラボレーションにより、PCC インフラストラクチャのプライバシーとセキュリティの機能を Google Cloud に拡張できることを大変誇りに思います。PCC における Apple のプライバシーへの取り組みは、Google Cloud のインフラストラクチャ上に構築されている多層的なセキュリティアプローチによってサポートされます。これには以下が含まれます。

Google Cloud Confidential Computing: コアとなる Confidential Computing プラットフォームは、PCC に必要なハードウェアベースの TEE を提供します。Intel TDX（Trust Domain Extensions）と NVIDIA Confidential Computing を活用することで、仮想マシン向けにハードウェアベースの分離を実現し、暗号化による保証の下でワークロードを実行できる、安全性の高いプライベートな環境を実現します。
Google Titanium セキュリティアーキテクチャと Titan チップ: Google Titan チップは、Google Cloud 上の PCC インフラストラクチャのセキュリティと透明性の確保に不可欠なコンポーネントです。Google のフリート全体に展開されている Titan は、強固なハードウェアのルートオブトラストを確立し、ブートプロセスとハードウェアプラットフォーム自体の完全性を確保します。
Intel TDX と NVIDIA Confidential Computing: Google Cloud は、Intel CPU と NVIDIA Blackwell GPU のセキュリティ機能を活用して、高パフォーマンスの AI 推論時の使用中のデータを保護することで、CPU から GPU に至るまでのコンピューティングパス全体を保護します。
オープンソースによる透明性: 検証可能なセキュリティに対するコミットメントの一環として、Apple と Google は、特に PCC の透明性をサポートするためにオープンソースのホストスタックを共同で開発しました。これにより、システムのセキュリティプロパティを独立して検査および検証できます。

これらのテクノロジーを組み合わせることで、Google Cloud 上の Apple PCC で、強制可能な保護機能、特権ランタイムアクセスの禁止、検証可能な透明性といった要件を満たせるようになります。

プライベート AI インフラストラクチャの未来を築く

Apple とのコラボレーションは、Apple、Google Cloud、Intel、NVIDIA の各社が持つテクノロジーと標準を基盤とした、AI 向けのセキュアなクラウドをさらに強化するうえで重要なマイルストーンとなります。ハードウェアからソフトウェアまで、スタックのあらゆるレイヤが検証可能かつセキュアなシステムとして機能するよう設計することで、PCC アーキテクチャが求める厳格なユーザープライバシーとデータセキュリティ基準を確実に満たす先進的なプラットフォームが実現しました。

このコラボレーションを通じて実現された機能強化は、すべての Google Cloud のお客様にメリットをもたらします。Google は、今後も継続的な改善に取り組み、あらゆる種類のワークロード、特に AI や機密データを扱うワークロード向けに、より透明性が高く、セキュアで、レジリエンスに優れたプラットフォームを提供してまいります。

Confidential Computing について詳しくは、こちらをご覧ください。

- Google Cloud、エンジニアリング担当シニアディレクター、Amit Patil

- Google、上級エンジニア、Andrés Lagar-Cavilla

サーフェスの選択: Antigravity 2.0、Antigravity CLI、Antigravity IDE、Antigravity SDK

Thu, 18 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

要約:

Antigravity 2.0: 独立したプロジェクトで並行して動作する複数の自律型エージェントをオーケストレートするデスクトップアプリ。
Antigravity CLI: コマンドラインワークフローとヘッドレス実行用に設計されたターミナルインターフェース。
Antigravity IDE: エージェントを利用しながら直接コードを記述したい開発者向けのエディタ。
Antigravity SDK: Antigravity Harness を使用する独自のカスタムエージェントを構築、デプロイするための Python ライブラリ。

比較早見表

機能	Antigravity 2.0	Antigravity CLI	Antigravity IDE	Antigravity SDK
インターフェース	デスクトップアプリ	ターミナル（TUI）	デスクトップアプリ	Python コード
最適な用途	複数タスクの同時実行	コマンドライン / ヘッドレス	コードの直接編集	カスタムエージェントの構築

Antigravity の 4 つのサーフェス

1. Antigravity 2.0

デフォルトのおすすめです。複数のプロジェクトにわたり、タスクを同時に管理します。

Antigravity 2.0 は、スタンドアロンのデスクトップアプリケーションです。メインのワークスペースをブロックすることなく、複数のタスクを実行できるよう設計されています。1 つの画面でさまざまなプロジェクトを簡単に切り替えてモニタリングすることができます。また、コードの品質チェックや古いパッケージの検出といったタスクを定期的に実行するようにスケジュール設定することも可能です。

2. Antigravity CLI

ターミナルワークフローとヘッドレス実行向けです。

高速性を追求して Go で構築された Antigravity CLI は、ターミナルで高速なキーボード操作やシンプルなショートカットを使って作業することを好むユーザーに適しています。アクティブなコマンドラインウィンドウをロックすることなく、ターミナルコマンドを使用してバックグラウンドエージェントを起動できます。ヘッドレス実行（SSH 経由での作業やリモートコンテナ内での作業など）が必要な場合は、CLI を選択してください。

3. Antigravity IDE

コードを直接表示して編集したい開発者向けです。

IDE サーフェスでは、エージェントが現在のワークスペース内に直接配置されます。エージェントが編集しているコードを正確に確認し、変更を 1 行ずつ承認または拒否したい場合は、これが最適な選択肢です。組み込みのデバッグ機能により、エージェントはランタイムエラーを確認し、エディタに修正案を表示できます。この修正は、ワンクリックで適用できます。

4. Antigravity SDK（Python）

カスタムエージェントロジックと自動化されたパイプラインの作成に最適です。

code_block: <ListValue: [StructValue([('code', 'import asyncio\r\nfrom google.antigravity import Agent, LocalAgentConfig\r\n\r\nasync def main():\r\n config = LocalAgentConfig(\r\n system_instructions="You are an expert assistant for codebase navigation.",\r\n # api_key="your_api_key_here",\r\n )\r\n async with Agent(config) as agent:\r\n response = await agent.chat("What files are in the current directory?")\r\n print(await response.text())\r\n\r\nasync def run():\r\n await main()\r\n\r\nif __name__ == "__main__":\r\n asyncio.run(run())'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7997850>)])]>

Google Antigravity SDK は、独自のカスタムエージェントをゼロから構築できる Python ライブラリです。同じ共有ハーネス上で実行されるため、Google の公式 Antigravity ツールを支えているものとまったく同じツールやルールに直接アクセスできます。エージェントをローカルで記述し、コードを一切変更することなく Google Cloud にデプロイすることが可能です。

まとめ

各インターフェースの外観は異なりますが、すべて同じ基盤エージェントハーネス上で動作します。Antigravity のどのサーフェスを選択しても、プラグインやスキルなどはサポートされます。エージェントは同じコアロジックにアクセスできるため、ご自身のプロジェクトに最適なものを選択してください。ガイドやドキュメントについては、antigravity.google をご覧ください。使用を開始する準備が整いましたら、Antigravity ダウンロードページにアクセスしてください。

- Firebase、デベロッパーリレーションズ、Alex "Sandu" Astrum

- Google Cloud、デベロッパーアドボケイト、Luke Schlangen

詳細解説: Lightning Engine が Apache Spark のパフォーマンスを 4.9 倍高速化する仕組み

Wed, 17 Jun 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

基本的な ETL と分析から最先端の生成 AI まで、Apache Spark はグローバルなデータ処理のアーキテクチャを支える柱として機能します。とはいえ、データ量が増大するにつれて、パフォーマンスとインフラストラクチャ費用の兼ね合いが成長の阻害要因となる可能性があります。自律型エージェントが数千ものマルチホップクエリを同時にトリガーできるエージェントの時代においては、このパフォーマンスのボトルネックがユニットエコノミクスに直接影響します。

このたび、Managed Service for Apache Spark 向け Lightning Engine の一般提供が開始され、サーバーレスとマネージドクラスタの両方のデプロイモードで利用可能になったことをお知らせいたします。上述のようなスケーリングの課題を直接解決するために設計されたこの Lightning Engine は、最新の Spark ワークロードに完全に対応しているため、既存のデータパイプラインに変更を加える必要はありません。

オペレーション不要のシンプルなサーバーレスデプロイモードと、インフラストラクチャを詳細に制御できるマネージドクラスタデプロイモードのどちらを選択しても、Lightning Engine は統合パフォーマンスエンジンとして機能し、ジョブの実行を強力に促進します。100 万件を超える実際のワークロードで Lightning Engine を検証することにより、産業グレードの安定性と信頼性の高いパフォーマンス向上を実現できるようファインチューニングしました。

この一般提供リリースにより、Lightning Engine は以下を実現します。

標準のオープンソース Spark と比較して最大 4.9 倍高速なパフォーマンス
主要な高速 Spark の代替プロダクトと比較して 2 倍の費用対効果

では、Managed Service for Apache Spark がどのようにしてこうした素晴らしい成果を上げているのか、詳しく見ていきましょう。

仕組み: ベクトル化したネイティブ実行

従来の Spark 実行では、JVM 実行のオーバーヘッドとガベージコレクションの一時停止がボトルネックになることが少なくありません。Lightning Engine では、Spark の物理クエリプランを、SIMD（単一命令、複数データ）ベクトル化に最適化されたネイティブ C++ 命令にコンパイルすることで、こうした制限を回避します。

Google 開発の専用拡張機能が組み込まれたオープンソースの Gluten および Velox ランタイム上に構築されたこのネイティブ実行レイヤは、以下の機能を活用して、最も要求の厳しいデータ処理タスクを高速化します。

並べ替えのベクトル化: ネイティブメモリでデータを列状に処理することで並べ替え処理を高速化し、CPU サイクルのオーバーヘッドを大幅に削減します。
ウィンドウ関数の高速化: ネイティブの C++ レイヤ内で直接実行することにより、行セット全体に対して行われる計算（移動平均、集計、重複除去など）を高速化します。
スマートなフォールバック: クエリに、ネイティブサポートされていない演算子やカスタム Java UDF が含まれている場合、エンジンのインテリジェントなプッシュダウンレイヤが、その特定のサブツリーを自動的かつスムーズに JVM に戻し、不要なデータ形式の変換を回避して、全体的な実行の安定性を維持します。

最適化された Cloud Storage と BigQuery のコネクタ

エンジンがデータ不足に陥ると、ハイパフォーマンスコンピューティングも役に立ちません。Lightning Engine では、Cloud Storage と BigQuery からのデータの読み取りがボトルネックにならないよう、ストレージコネクタを以下のように最適化しました。

パスの直接接続: 複数のノードホップをバイパスし、Cloud Storage との双方向ストリーミングを使用します。これにより、ストリームを再オープンしなくてもシーク操作やベクトル化した readV API を実行できるため、複雑で深くネストされた Parquet ファイルや ORC ファイルのスキャン時間を短縮できます。
メタデータ呼び出しの削減: 大規模なパーティション分割テーブルを管理する際は、ただファイルを一覧表示するだけで時間を消費するという、パフォーマンスの隠れた代償を伴うことがよくあります。Lightning Engine は、ドライバで辞書順のリストを利用してメタデータを収集し、それをエグゼキュータに直接送信します。これにより、冗長な Cloud Storage API 呼び出しが排除され、Cloud Storage のメタデータコストが大幅に削減されます。
ネイティブの BigQuery コネクタ: BigQuery データを Arrow 形式で直接使用します。Arrow から JVM UnsafeRow への、コストの高い変換を回避することで、エンジンはシリアル化のオーバーヘッドを排除し、スキャン時間を短縮できます。

ブロードキャスト結合と高度なクエリの最適化

Lightning Engine には、Google の F1 および Spanner クエリエンジンにインスパイアされたコストベースの高度なクエリオプティマイザーが組み込まれており、いくつかのカスタム最適化ルールが導入されています。以下に例を示します。

単一のハッシュテーブルキャッシュ: 標準のブロードキャスト結合では、Spark はタスク間で結合ハッシュテーブルを繰り返し構築します。一方、Lightning Engine では、エグゼキュータごとにハッシュテーブルを一度だけ構築してキャッシュに保存するため、冗長な CPU サイクルが排除され、エグゼキュータのメモリ使用量が減少します。
集計のプッシュダウン: 結合シャッフルの前に部分的な集計を自動的にプッシュします。これにより、ネットワーク経由で転送する必要があるデータ量を最小限に抑え、コストの高いシャッフルステージを大幅に減らすことができます。
自動シャッフルパーティショニング: ランタイム統計情報に基づいてクエリステージごとに最適なシャッフルパーティション数を動的かつ適応的に決定し、過剰なパーティショニングをなくして、メモリ不足（OOM）によるスピルを防止します。

Google Cloud Next ‘26 での Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

使ってみる

これらのアップデートはすでに公開されているため、すぐにご利用いただけます。Lightning Engine を有効にするには、Google Cloud コンソールから直接操作するか、gcloud CLI を使用します。

Lightning Engine を有効にして サーバーレス バッチジョブを送信するには、Spark プロパティでプレミアムティアを指定します。

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc batches submit pyspark my_script.py \\\r\n --region=us-central1 \\\r\n --properties=dataproc:dataproc.tier=premium \\\r\n --properties=spark:spark.dataproc.lightningEngine.runtime=native'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7983610>)])]>

Lightning Engine とネイティブクエリ実行（NQE）が有効な新しいマネージドクラスタをスピンアップするには、ターミナルで次のコマンドを実行します。

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create my-optimized-cluster \\\r\n --region=us-central1 \\\r\n --image-version=2.3 \\\r\n --engine=lightning \\\r\n --enable-component-gateway \\\r\n--properties=spark:spark.dataproc.lightningEngine.runtime=native'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7983e80>)])]>

別の方法として、Google Cloud コンソールで Managed Service for Apache Spark のページに移動します。[クラスタを作成] をクリックし、[Compute Engine 上のクラスタ] を選択して、クラスタ構成設定で [Lightning Engine] を選択すると、ワークロードのクエリ高速化が自動的に有効になります。

- エンジニアリング担当ディレクター、 Newton Alex

- Google Cloud、プリンシパルソフトウェアエンジニア、Abhishek Modi

レポート: GKE Inference Gateway が AI 応答を最大 92% 高速化

Wed, 17 Jun 2026 01:30:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI が試験運用から大規模な本番環境へと移行するにつれ、インフラストラクチャの効率が決定的な差別化要因になります。インフラストラクチャを最大限に活用し、コストのかかるアクセラレータのアイドル時間を最小限に抑える方法の一つが、Google Kubernetes Engine（GKE）Inference Gateway の活用です。GKE Inference Gateway は、リアルタイムのモデルサーバー指標に基づいて、生成 AI ワークロードをインテリジェントにルーティングします。

従来の単純なラウンドロビン方式のロードバランシングでは、アクセラレータでのコストのかかる再計算が頻繁に発生し、ユーザーレイテンシが急増することがあります。これに対し、GKE Gateway のネイティブ拡張機能である GKE Inference Gateway は、接頭辞キャッシュやモデル対応ルーティングなどの高度な機能を活用します。すぐに処理できる状態にある適切なアクセラレータにリクエストを確実に送ることで、GKE は大規模言語モデル（LLM）のサービング方法を変革し、優れたハードウェア使用率と極めて高速な応答時間を実現します。

実際、独立したベンチマークレポートによると、GKE Inference Gateway は、次に優れたマネージド Kubernetes サービスと比べて、スループットが 15.7% 高く、待機時間が 92.8% 短く、トークン間レイテンシが 62.6% 低いという結果を示しています。このパフォーマンスにより、LLM ベースのアプリケーションは、低速で高コストなものから、高速で本番環境対応のものへと変わります。

このパフォーマンスは、GKE Inference Gateway を使用した Snap の経験とも一致しています。

「Snap では、大規模で高性能な推論を実現するため、本番環境の AI インフラストラクチャに llm-d を統合しています。接頭辞キャッシュ対応ルーティングを採用することで、最大 75～80% の接頭辞キャッシュヒット率を達成しました。llm-d がオープンソースであることにより、Envoy ベースのサービスメッシュとシームレスに統合できる点を高く評価しています。」- Snap Inc.、ソフトウェアエンジニアリング担当シニアマネージャー、Vinay Kola 氏

このブログ投稿では、GKE Inference Gateway の接頭辞キャッシュについて、例を交えながら詳しく見ていきます。また、ベンチマーク結果の詳細もご紹介します。それでは詳しく見ていきましょう。

低レイテンシ AI の秘訣: 接頭辞キャッシュ

接頭辞キャッシュは、長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化します。連続するユーザーリクエストで、同じシステム指示、コンテキスト、ドキュメントが共有される場合、モデルはそれらのトークンの再処理を完全にスキップできます。GKE Inference Gateway は、受信リクエストの接頭辞を読み取り、そのデータをすでにメモリに保持している特定の Pod と照合します。これにより、GPU や TPU にかかる「思考」のコストを排除し、負荷の高い推論ループをほぼ瞬時の回答へと変えることができます。

ユースケース 1: 検索拡張生成（RAG）を使用したドキュメントとコードベースの Q&A

大規模なエンタープライズリポジトリをクエリする場合、RAG を使用してドキュメントセット全体を静的接頭辞としてキャッシュに固定することで、レイテンシを追加することなく、LLM の回答を根拠に基づいたものにできます。

GKE Inference Gateway は、ユーザーから質問があるたびに、数千行に及ぶ API リファレンスや社内 Wiki を LLM に再度読み込ませるのではなく、その特定のコンテキストがすでに KV キャッシュに保持されている Pod にクエリをルーティングします。これにより、LLM はユーザーの短い動的な質問のみを計算すればよく、コストの高いドキュメントの再評価を完全に回避できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持] あなたは技術ドキュメントを専門とする AI アシスタントです。以下は、このソフトウェアプラットフォームの完全な API ドキュメントです。このコンテキストを使用して、ユーザーの質問に正確に回答してください。ドキュメント内に回答が見つからない場合は、「提供されたコンテキストでは見つかりません」と答えてください。\r\n\u200b\r\n<documentation> [10,000 語以上の API リファレンスドキュメント、エンドポイント、エラーコードなど] </documentation>\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザーの質問: Python SDK を使用して 429 レート制限エラーを処理するにはどうすればよいですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f79bd160>)])]>

ユースケース 2: マルチターンチャット

接頭辞キャッシュを使用すると、コンピューティングコストを累積的に増やすことなく、数千もの同時セッションにわたってカスタマーサービスのやり取りを維持できます。これは、固定のシステムペルソナと中核的なビジネスルールを LLM サーバーに直接キャッシュ保存することで実現できます。

エンタープライズチャットアーキテクチャでは、基本となるシステムプロンプトと参照テーブルが、数百万件の顧客インタラクション全体で完全に同一のまま維持されます。GKE Inference Gateway は、コンテキスト対応ルーティングを使用してこうしたマルチターンの会話を処理し、繰り返し発生するトークン処理をバイパスします。これにより、トラフィックのピーク時でも chatbot は極めて高い応答性を維持できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持]\r\n- システムペルソナ: あなたは、ABC Banking Solutions の親切で共感力があり、コンプライアンスに準拠した仮想アシスタント「FinBot」です。次のルールを厳守してください。1. 具体的な投資助言は決して提供しないでください。2. ユーザーが当座預金口座について質問しているのか、貯蓄口座について質問しているのかを必ず確認してください。3. 回答は 3 文以内にしてください。4. ユーザーが怒っている場合は、人間のマネージャーにつなぐことを提案してください。\r\n\u200b\r\n2026 年 5 月時点の金利表は次のとおりです。\r\n- 貯蓄口座: 年利 4.2%\r\n- 当座預金口座: 年利 0.5%\r\n- CD（12 か月）: 年利 5.1%\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザー: 10,000 ドルを 1 年間預けた場合、いくら受け取れるのか知りたいのですが。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f79bd1c0>)])]>

GKE は他のマネージド Kubernetes ソリューションを上回るパフォーマンスを発揮

こうしたアーキテクチャ上の利点を検証するため、Principled Technologies は先日、GKE Inference Gateway を搭載した GKE と、従来のラウンドロビン方式の HTTP ロードバランシングを使用する標準的なサードパーティのマネージド Kubernetes サービスを比較した、独立したベンチマークレポートを公開しました。

同一のハードウェア（8 基の NVIDIA A100 40GB GPU）を使用し、Llama 3.1 8B Instruct の共有接頭辞ワークロードでテストした結果、2 つの Kubernetes サービスの間に大きなパフォーマンス差があることが明らかになりました。GKE は単に優位性を示しただけでなく、次の 3 つの重要な指標すべてにおいて推論効率のあり方を大きく変えました。

スループットの向上: 1 秒あたりに処理されるトークン数が 15.7% 増加し、リクエスト処理能力を高めることができます。また、同じワークロードに必要なハードウェアを削減することも可能です。
最初のトークンまでの時間（TTFT）の大幅な短縮: 待機時間が 92.8% 短縮され、インタラクティブなシナリオで、応答が始まるまでの体感時間を大幅に短縮できます。
トークン間レイテンシ（ITL）の低減: 62.6% の低減により、最初のトークン以降のトークンストリーミングがよりスムーズかつ高速になります。

図 3: 共有接頭辞のユースケースにおける Llama 3.1-8B Instruct LLM での、GKE Inference Gateway を使用した GKE とサードパーティのマネージド Kubernetes サービスの平均レイテンシ（出力トークンあたりの正規化時間）。どちらのソリューションも同じハードウェアを使用しました。出典: Principled Technologies

	GKE	サードパーティのマネージド Kubernetes サービス	GKE の利点
平均出力トークンスループット	7,169.21 出力トークン/秒	6,042.05 出力トークン/秒	出力トークンスループットが 15.7% 向上
最初のトークンまでの平均時間（TTFT）	188.36 ミリ秒	2624.73 ミリ秒	TTFT が 92.8% 短縮
平均トークン間レイテンシ（ITL）	30.20 ミリ秒	81.03 ミリ秒	ITL が 62.6% 低減

図 4: GKE Inference Gateway を使用した GKE は、標準的な HTTP ロードバランサを使用するサードパーティのマネージド Kubernetes サービスと比較して、優れた AI 推論パフォーマンスを実現しました。

生成 AI 推論ワークロードを加速させる準備はできていますか？

リアルタイムのカスタマーサポートエージェント、動的なコーディングアシスタント、サブ秒単位の不正検出モデルなどの推論ワークロードをデプロイする場合、インフラストラクチャのレイテンシがユーザーエクスペリエンスを左右します。GKE Inference Gateway は、共有プロンプトの接頭辞がアクティブキャッシュにほぼ 100% ヒットするようにすることで、LLM を低速で高コストな推論エンジンから高速で資本効率に優れた本番環境対応の強力な基盤へと変えます。

GKE Inference Gateway が生成 AI ワークロードにもたらすパフォーマンス上の優位性を確認してみませんか？ベンチマークレポートの全文はこちらからご覧いただけます。また、詳細については、こちらの解説動画をご覧ください。

Principled Technologies のシニアパフォーマンスアーキテクトである Dan Sullivan 氏に感謝いたします。

- ソフトウェアエンジニア、Bob Tian

- アウトバウンドプロダクトマネージャー、Susan Wu

ソフトウェア開発で真の費用対効果を引き出す方法: DORA の最新の調査を詳しく解説

Wed, 17 Jun 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 6 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI のビジネス価値をチームに示すにはどうすればよいでしょうか？

テクノロジー部門と財務部門のリーダーは、AI プロジェクトへの予算を継続的に確保するために、その明確なビジネス価値を示す必要があります。費用対効果の測定は、技術戦略の妥当性を確認するうえで重要な要素ですが、長期的な成功は最終的に、AI を有効に活用するうえで必要な組織の仕組みと文化を構築できるかどうかにかかっています。

AI のコストとビジネス上のメリットを評価できるよう、Google は先日、DORA の ROI of AI-assisted software development（AI を活用したソフトウェア開発の費用対効果）レポートを公開しました。この調査では、チームが初期導入に伴う課題に対処し、エンジニアリング計画の足並みをそろえ、ビジネス成長を促進するための実践的なアプローチを紹介しています。

ここでは、レポートの主な調査結果と、それらをテクノロジー戦略全体の強化にどのように活用できるかをご紹介します。

インサイト 1: AI の価値実現における J カーブを乗り切る

AI への投資からどれほど早く利益を得られるかについては、現実的に考えることが重要です。AI はソフトウェアエンジニアリングを強力に後押しする存在になり得ますが、財務的価値につながる道筋が一直線であることはほとんどありません。多くの組織はむしろ J カーブに直面します。これは、導入初期に伴う一時的な生産性の低下と不安定な期間を指します。

この一時的な低下は、戦略の失敗を示すものではなく、新しいテクノロジーの導入に伴う自然な過程です。レポートでは、この現象が起こる主な理由として次の 3 つを挙げています。

学習曲線: 日常のワークフローを適応させ、高度な手法を習得するために、チームには通常の機能提供から離れて集中的に取り組む時間が必要です。単純なプロンプト入力から、コンテキストと意図に基づくシステム構築へと進化していくためです。
検証コスト: AI によって生成されるコードの量が大幅に増えるため、開発者は生成された出力を厳密にレビューするための追加の時間を投じる必要があります。これは、信頼性を確保し、ハルシネーションを防ぎ、社内のアーキテクチャ標準を満たすうえで不可欠です。
パイプラインの適応: 個々の開発者がコードを大幅に速く生成できるようになると、テストや変更承認などの下流工程がボトルネックになることがあります。そのため、増加したスループットに対応できるよう、これらのプロセスを積極的に拡張する必要があります。

この初期の学習フェーズを予算に織り込んでおくことが、移行を成功させる鍵となります。生産性の低下が一時的なものであることを見越しておけば、初期の課題をチームの長期的なスピードへの投資であると捉え、自信を持って AI プロジェクトを前進させることができます。

AI の価値実現における J カーブ

インサイト 2: AI への投資の成果をめぐる市場の二極化を理解する

AI を活用したソフトウェア開発の現状に関する DORA のレポートによると、DORA の調査に参加した回答者の 90% が業務で AI を使用していると回答しています。導入がほぼ一般化している一方で、実際の財務的影響は組織によって異なります。市場全体を見ると、エンジニアリングへの投資から明確な価値を得ている企業もあれば、予期しないコストに苦慮している企業もあります。

プロジェクトが期待どおりの成果を上げられない場合、その多くは、成功に必要な組織的サポートを得られていないことが原因です。期待するリターンを得るには、新しいテクノロジーを導入できるよう、ワークフローとチームをあらかじめ整えておく必要があります。

インサイト 3: AI の費用対効果を計算することが不可欠

AI の現実的な財務モデルを構築する際は、AI が実際にどこで価値を生み出すのかを把握することから始めます。ソフトウェア開発ライフサイクル全体にわたり、AI はコスト削減、生産性向上、セキュリティ強化、開発者とユーザー双方のエクスペリエンス向上を支援できます。

組織でこのモデルを検討する際には、こちらの費用対効果を計算するインタラクティブなツールをご利用いただけます。

このツールを使用すると、AI 導入に伴う明確な費用と、見えにくい実態の両方を明確に予測することができます。
仕組みを確認し、自社の状況に合わせて前提条件を調整しながら、独自の見積もりを作成できます。

価値モデル - 導入から費用対効果の実現まで

始める

完全版レポートをダウンロード: AI への投資を定量化し、J カーブを乗り越え、AI への投資ロードマップを策定するための包括的なフレームワークをご覧ください。
費用対効果を計算するインタラクティブなツールを試用: https://dora.dev/ai/roi/calculator にアクセスして、お客様の組織が実現可能な利益を見積もり、説得力のあるビジネスケースを構築しましょう。
Cloud OnAir ウェブセミナーを視聴: From cost center to value engine: Building your business case for AI-assisted development（コストセンターから価値創出エンジンへ: AI を活用した開発のビジネスケースを構築する）をご覧ください。

- delta EMEA、AI 価値実現担当リード、Ursula Löbbert-Passing 博士

- Delta Americas、AI 価値実現担当、Eva Dong 氏

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング

Wed, 17 Jun 2026 00:40:00 +0000

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

成長中のレストランの例

レストランチェーンを経営している場面を想像してみてください。ビジネスがどのように動いているのかを、実際に一つひとつ見たり触れたりして把握することは至難の業です。ビジネスの健全性を把握するには、その状態を感知するためのツールと、ビジネスのデジタルレプリカが必要です。

成長に伴う摩擦

成長は、スプレッドシートだけでは解決できない特有の摩擦を生み出します。

ブルウィップ効果: 下流の需要の小さな変化が、上流では在庫の大きな変動へと膨らみます。
SOP の逸脱: 標準的な仕込み作業からのわずかな逸脱が、やがてブランド全体の雰囲気を損なっていきます。
食品安全上の影響範囲: 汚染された 1 つの食材が、ネットワーク全体に広がる複雑なリスクを生み出します。
管理外支出: 各店舗のマネージャーが契約外で食材を購入することで発生する「100 万ドル規模の漏れ」です。

デジタルツイン

デジタルモデルは、世界についてより深い問いを立てる力を与えてくれます。一方で、データをどのように構造化するかという重要な選択も迫っています。従来はリレーショナルテーブルが標準でしたが、今でもあらゆる用途に最適なツールといえるのでしょうか。私たちの世界が本質的に相互につながっていることを踏まえると、現実を捉えるためにグラフベースのモデルに移行することは、自然な進化と言えるかもしれません。

数千ものアセット、複雑なサプライチェーン、グローバルなロジスティクスネットワークを管理する場合、従来のリレーショナルデータベースでは、依存関係をたどるためにリソースを大量に消費する大規模な SQL 結合が必要になります。このアーキテクチャでは、現実世界で起きた事象を運用上の認識に反映するまでに、レイテンシのギャップが生じます。

BigQuery Graph でのモデリング

BigQuery Graph を使用すると、既存のデータプラットフォーム内で、サプライチェーン全体のデジタルツインを構築できます。現実世界のアイテム、レシピ、場所を、検索可能なノードとエッジのマップに変換することで、これまで以上に明確に関係性を把握できるようになります。

1. セマンティックレイヤを定義する

データを新しいデータベースに移動する代わりに、既存のテーブル上にグラフビューを作成します。これにより、テーブル同士がどのように関連しているかを BigQuery に正確に伝えることができます。

クエリ言語:

code_block: <ListValue: [StructValue([('code', '# グラフのノードとエッジを構築する\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7ab8430>)])]>

BigQuery Graph でモデル化した架空のレストランサプライチェーンの画像

実務で活きる精度

この変化は、日々の業務をどのように変えるのでしょうか。ビジネスを、混乱した対応から精度の高い対応へと移行させます。

外科手術のように正確なリコール対応: サプライヤーからリステリア菌の発生が報告された場合、グラフを前方にたどることで、どのレストランのどのメニュー項目が影響を受けるのかを正確に特定できます。
気象リスク分析: ハリケーンが配送センターに迫っている場合、単なる店舗リストではなく、影響が及ぶ範囲を把握できます。そのハブに大きく依存している拠点を特定し、物資の配送ルートを変更できます。

2. 検索を実行する

グラフクエリは、モデラーやデータサイエンティストがデータをクエリするための新しいツールです。複数のドメインにまたがる複雑なデータ概念を扱いやすくし、クエリを簡素化することで、データ分析を、問題の構造をより自然に表現するものにします。たとえば、鶏肉を扱っているすべての拠点を知りたい場合は、次のようなグラフクエリを実行できます。

特定の苦情やリスクを調査するには、グラフクエリ言語を使用してモデルを検索します。

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# 特定の食材に関する問題の発生源をたどる\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation)\r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f62f7ab8490>)])]>

悪臭の発生源をグラフとしてモデル化した例

将来を見据えて

デジタルツインを最大限に活用するには、次の基本原則に沿って進めることが重要です。

構造に重点を置く: 関係性や依存関係にはグラフを使用し、日次売上の合計などはリレーショナルテーブルに保持します。
キーを整備する: データエンジニアリングに時間をかけます。グラフの価値は、その接続の正確さによって決まります。
エッジのプロパティを取得する: リードタイムや送料などのメタデータをエッジに直接保存することで、モデルの有用性を高めます。

まとめ

レストラン業界は、ビジネスデータを単なるリストとして扱うリレーショナルな方法だけでは対応しきれない段階に来ています。BigQuery Graph を使用して、ドメイン間の関係をデジタルツインとして構築することで、事後対応型の問題解決から先を見越したモデリングへと移行できます。ネットワークをリストで管理するのはもうやめて、つながりを数秒で把握できるようにしましょう。

使ってみる

チュートリアルはこちら
BigQuery のドキュメントを見る: 概要とクイックスタートガイドをご覧ください。
フィードバックを共有する: コミュニティに参加するか、bq-graph-preview-support@google.com までお問い合わせください。
関連ブログ: BigQuery Graph のご紹介

- Google Cloud、クラウドトランスフォーメーション技術リード Guru Rangavittal

- BigQuery、プロダクトマネージャー Candice Chen

Cloud Blog JA

Antigravity 2.0 を使用して 1 日で Go を習得するための実践的な方法

ステップ 0: 個人的な学習目標の「種まき」をする

ステップ 1: スキルの重要性

ステップ 2: ギャップ分析と計画

ステップ 3: 品質保証（QA）ループの実施

ステップ 4: CLI コマンド向けの並列サブエージェント

ステップ 5: パッケージ構造、コンパイル、CI / CD

ステップ 6: エージェント スキルを作成する

まとめ

Siemens が「象の切り分け」（細分化）により産業用ソフトウェア開発のエージェント ワークフローを推進

課題: 産業用ソフトウェアの複雑さ

解決策: ドメインを認識する Knowledge Fabric

「象の切り分け」: エージェント ワークフロー

パイロット運用の結果: エンジニアリングの迅速化と効率化を実現

使ってみる

次世代のグローバル イノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

ネットワークの力: 10 年間の成果を数字で見る

戦略的展開: 地政学、グリーン インフラストラクチャ、ロボット工学

お見逃しなく: 今後の Demo Day

お申し込み受け付け中または受付予定のプログラム

Looker エージェントでダッシュボードをインタラクティブなデータ エクスペリエンスに変革

エージェント主導のインタラクティブな調査

ビジネスに合わせてエージェントをカスタマイズ

信頼性と透明性を継承

ダッシュボード エージェントを使ってみる

Gemini for Government: ミッション達成に向けた設計図

Storage Insights データセット: アクティビティ インサイトで組織全体のオペレーションを把握

Storage Insights データセットとは

静的なメタデータからライブ インテリジェンスへ進化

アクティビティ インサイトを直ちに活用する 3 つの方法

ご利用にあたって

グラフ技術を活用した信頼できるエージェント プラットフォームの構築: Yahoo の事例

ケーススタディ: エージェント型メディア購入

信頼できるアクション システムのアーキテクチャ

ナレッジグラフ: エージェントをビジネスの実態にグラウンディング

コンテキスト グラフ: 監査可能なメモリの作成

人間ができる範囲からエージェントならではの規模へ

あらゆる業種に適用できる設計

使ってみる

【Next Tokyo 最新情報】基調講演 & Expo 注目ブースを一挙公開！

基調講演 & Expo の注目ブースを一挙公開！革新的なアイデアを、AI で実現しよう

未来のビジョンを掴む基調講演

Featured Booth

Dev Experience

Brazos のご紹介: 空冷データセンターでも液体冷却システムが利用可能に

迅速な導入と業界への普及

次のステップ

Google が「IDC MarketScape SIEM 2026 Vendor Assessment」でリーダーに選出

AI を活用した Google Security Operations

脅威インテリジェンスへの比類のないアクセス

グローバル企業のオペレーショナル レジリエンスを確保

サイバー防御を強化する次のステップ

データエージェントの新機能: AI ワークフローの強化

1. 会話型分析

2. 新たなデータ エージェント

3. データ エージェント向けのツール

デベロッパー必見: 開発に欠かせない 10 個のプロンプト

仕様を作成する

ウィジェット テスト

すべてのテストを確認する / コミット内容を整理する

権限が正しく、コンプライアンスに準拠しているか確認する

コードレビューを実施する

意思決定を支援するためにトレードオフを説明する

研究を通じて AI 生成コードを改善する

イテレーションを通じて問題を見つける

すべての pull リクエストをレビューする

テストに有向非巡回グラフ分析を適用する

まとめ

豊田自動織機ITソリューションズ: Gemini Enterprise を一斉展開し、業務効率化とナレッジ集積、人材の育成・確保を実現

激変する IT 業界の中でスタートした業務改革「TIIS-X プロジェクト」

PoV の成功を踏まえて、500 ライセンスを全社員に一斉に展開

Gemini Enterprise の活用は、新たなる価値創造に向けた切り札になる

Open Knowledge Format のご紹介

コンテキストが断片化された現状

現実の Wiki としてのナレッジ

欠けているのは形式であり、別のサービスではない

OKF の仕組み: 1 画面でわかる設計

設計の 3 つの原則

仕様とともにリリースされるもの

ステップ 6: エージェントスキルを作成する

Siemens が「象の切り分け」（細分化）により産業用ソフトウェア開発のエージェントワークフローを推進

「象の切り分け」: エージェントワークフロー

次世代のグローバルイノベーションの拡大: 成功を収めている世界中のスタートアップを Google がどのようにサポートしているか

戦略的展開: 地政学、グリーンインフラストラクチャ、ロボット工学

Looker エージェントでダッシュボードをインタラクティブなデータエクスペリエンスに変革

ダッシュボードエージェントを使ってみる

Storage Insights データセット: アクティビティインサイトで組織全体のオペレーションを把握

静的なメタデータからライブインテリジェンスへ進化

アクティビティインサイトを直ちに活用する 3 つの方法

グラフ技術を活用した信頼できるエージェントプラットフォームの構築: Yahoo の事例

信頼できるアクションシステムのアーキテクチャ

コンテキストグラフ: 監査可能なメモリの作成

基調講演 & Expo の注目ブースを一挙公開！
革新的なアイデアを、AI で実現しよう

グローバル企業のオペレーショナルレジリエンスを確保

2. 新たなデータエージェント

3. データエージェント向けのツール

ウィジェットテスト

BigQuery Graph で食品サプライチェーンのデジタルツインをモデリング