AI & 機械学習

AI エージェント事例アワード開催！指示するから、自律する AI へ。

Mon, 13 Jul 2026 02:00:00 +0000

前身の「生成 AI 事例アワード」を始めてから、2 年あまりが経ちました。この場には、ビジネスを大きく動かした取り組みから、日々の業務を助ける等身大のアイデアまで、素晴らしい事例が数多く集まってきました。そして、この 2 年で生成 AI そのものも、試す段階から業務に組み込む段階へと移ってきています。

指示を一つずつ出す使い方から、目的を伝えて自律的に動かす使い方へ。この変化は、AI を業務にどう生かすかという問いそのものを変えつつあります。そして、アワードに応募いただく事例の顔ぶれも、この 2 年で確かに変わってきました。

こうした変化に合わせて、今回から名称を 「AI エージェント事例アワード」へと改め、次の一歩をつくる活用事例をあらためて募集します。ビジネスを前に進める最先端の取り組みから、アイデアが光る業務効率化まで。分野や規模は問いません。みなさんの事例をお待ちしています。

事例アワードへの応募・詳細はこちら

スケジュール

エントリーからピッチコンテストまでの日程は次のとおりです。

エントリー開始: 7 月 7 日（火）
エントリー締切: 9 月 2 日（水）
ファイナリストのピッチコンテスト : Agentic AI Summit '26 Fall（10 月 29 日）内で実施

評価基準

審査では、次の 3 つの観点から事例を見ます。

技術的革新性（特に AI エージェントの活用）
実用性と実現可能性
社会的・経済的な影響

表彰内容

受賞した企業には、次の賞を用意しています。※ 表彰内容は予告なく変更になる場合があります。

最優秀賞（1 社 2 名）

トロフィー
Google Cloud Next 27（ラスベガス開催）への特別招待

優秀賞（3 社）

トロフィー
Google Cloud グッズ

ファイナリスト賞（8 社）

Google Cloud グッズ

みなさんの応募をお待ちしています。

日立「Gemini Enterprise 活用コンテスト」開催レポート ― 112 件の応募から選ばれた、現場を変える 10 の AI エージェント

Thu, 09 Jul 2026 02:00:00 +0000

6 月 17 日（水）渋谷ストリームグーグルオフィスにて AI エージェントは、現場のどんな仕事を本当に楽にしてくれるのか。その答えを、日立製作所のみなさん自身が見せてくれる一日がありました。今年 4 月からデジタルシステム＆サービスセクターの社員を中心に利用が広がった Gemini Enterprise。その活用アイデアを競う「Gemini Enterprise 活用コンテスト」には、総勢 112 件もの応募が集まりました。選り抜かれた 10 組が登壇した発表会の熱気を、そのままお届けします。

112 件の応募から、現場発の 10 組が登壇

発表会は、日立とグーグル・クラウド・ジャパン両社の挨拶で幕を開けました。AI を業務にどう根付かせるかという強い意志が、冒頭から明確に打ち出されていました。

日立デジタルシステム&サービス/ AI &ソフトウェアサービスビジネスユニット事業主管を務める西孝治氏は、AI への期待をこう語りました。「AI は非常に活況を呈していますが、一番やりたいのは日立の社内トランスフォーメーションです。みなさんが AI を使いこなして、お客様の前でもマーケットの中でも、 Gemini をこんな風に使っているぞと宣伝してくれる、そんな AI のショーケースになってほしい」。 1 人で考えるには限界がある、隣の人が何をしているかという知見をぜひ共有してほしい、という呼びかけもそえられました。

続いて登壇した Google Cloud 執行役員自動車・産業営業本部本部長の浅井は、会場を見渡してこう切り出します。「壇上から見ると、みなさんの顔が自信に満ちあふれているのがひしひしと伝わってきて、私自身もワクワクしています」。日頃 Google Cloud と一緒にビジネスの変革を進められていることへの感謝を述べました。

現場の「困った」から生まれた 10 のエージェント

10 組の発表はどれも、日々の業務でぶつかる具体的な「困った」を出発点にしていました。発表順にご紹介します。

失注ポストモーテム AI 「失注リフレクター」: 失注した案件の経緯を SharePoint の社内資料から再構成し、「3 つの分岐点」「顧客の発言と真意」「次回への教訓」を 3 分で構造化レポートにまとめます。レポートは社内のナレッジ DB にためて、営業担当者が商談前に過去の知見として参照できるようにします。原因分析にかかる時間を短縮するとともに、分析の実施率を大幅に高めることで、失注を組織の武器に変える仕組みを提案しました。
Power Automate × Gemini Enterprise による定例会議議事録作成の「完全自動化」 : Microsoft の Power Automate と Gemini Enterprise を組み合わせ、定例会議の議事録づくりを入口から仕上げまで自動でつなぎました。
業務改善アドバイザー: 複数のエージェントが手分けして、自分の業務をヒアリングし、分析し、ボトルネックを洗い出して改善案まで示します。業務の流れは Mermaid 形式の図にして一目で見渡せるようにしました。業務のヒアリングから分析、改善提案までのプロセスを大幅に短縮できる可能性が示されました。これまで数日かかっていた作業が、約 10 分に縮みます。
議事録「ワンショット 5 方向展開」マルチエージェント: Gemini Enterprise の Agent Designer で 5 つのサブエージェントを組み、 Teams のトランスクリプトから Markdown レポート、 Word 議事録、 Excel の Q&A 、 Teams 向けの展開メッセージ、 Redmine チケットを一度に生成します。議事録1 本あたりの二次加工は 90 分から 5 分へ、 94 % 削減。年間およそ 7,000 時間の削減になります。
開発チーム、転生したら AI だった件: 開発が一段落してメンバーが抜けた後の問い合わせや軽微なバグ修正を引き受ける仕組みです。離任する前に「AI 転生テンプレート」で自分の思考の進め方や口調まで写したサブエージェントを残し、人が減ってもチームが回ります。問い合わせ対応や初期調査は 1 時間〜半日から 5 〜 10 分に短くなり、問い合わせの 8 割以上に対して、AIが妥当な回答案を提示できると見ています。
ExcelScribe 手書き帳票の Excel 自動転記ツール: 端末を持ち込めないデータセンターなどの現場で手書きした帳票を、 Gemini Enterprise が文字認識して元の Excel に書き戻します。アウトプットをより精緻に行うために組み合わせるツールを作成しました。
画面録画 × Gemini で PC 操作のムダを可視化: PC 上の自分の作業を画面録画して渡すだけで、 Gemini が操作を読み取り、ショートカットや関数で速くできる箇所を具体的に示します。リモートワークで「隣の人の操作を見て盗む」機会が減った今だからこそ効くアイデアで、マウス操作などをおよそ 20 〜 30 % 減らせます。
NotebookLM と Gemini Enterprise を活用したグラフィックレコーディング作成 : 会議資料や記事を NotebookLM で要約し、その結果を Gemini Enterprise に渡して、グラレコの構成案・レイアウト・イラストの案、さらに画像までを生成します。技術のある社員が、構成作りも含めて 2 時間かかっていた作業が、10 分で実施できるケースも見られました。
提案の質と速度を極める財務分析 with 3 つの AI エージェント: 決算短信サーチ、財務諸表分析、可視化の 3 つのエージェントが連携し、企業名を入れるだけで IR 資料を集め、在庫の回転日数など供給網に効く指標まで自動で計算します。 1 社あたり 3 時間かかっていた情報収集・分析が 45 分に、工数を 75 % 削減しました。
Gemini マルチエージェントによる設計書レビュー支援: チェックリストや日立がこれまで積み上げてきた社内の設計ガイドをレビュー観点として整理し、複数の専門エージェントがシステムの設計書を多角的に確認します。観点不足による見逃しを抑え、レビューがレビュアーの経験に左右されにくくなりました。

どの発表にも共通していたのは、 AI に丸投げするのではなく、「どこを AI に任せ、どこは人が判断するか」をていねいに切り分けていたことです。発表のあとは毎回 Q&A が活発に飛び交い、自分の業務にどう応用できるかを考える声が会場のあちこちから上がっていました。

受賞した 5 組と、審査員からの言葉

審査員が選んだ受賞者の 5 組には、それぞれの着眼点に対して温かいコメントが寄せられました。

オーディエンス賞: 画面録画 × Gemini で PC 操作のムダを可視化。会場の投票で一番多くの支持を集めました。審査員からは「なぜこの人たちは、資料を書かないという選択をしなかったのか。ふつうは AI に資料そのものを作らせたくなるのに、この人たちはあえて、作る作業を速くするほうへ情熱を注いだ。そこがすごい」「現場で起きている泥臭い作業をいかに AI で効率化していくか。これはフィジカル AI の基本で、とても期待できます」と熱のこもった講評がありました。

Google Cloud 賞: 開発チーム、転生したら AI だった件。 Google Cloud の執行役員カスタマーエンジニアリング統括技術本部長渕野は「アイデアとしてとても面白い」と評価したうえで、応用の広がりに触れました。「コーディングを助けるエージェントは増えていますが、実際のシステム開発はプロジェクトの背景を踏まえて進める必要があります。その文脈までエージェントに引き継げる、という意味で応用が効く発想だと思いました」。

Google Cloud 賞: ExcelScribe 手書き帳票の Excel 自動転記ツール。賞品を手渡した Google Cloud 浅井は、「他社のツールであっても、ちゃんと書き込めるモジュールを開発してほしい、という熱いプレッシャーを感じました。フィールドの声として、しっかり開発チームに届けます」とコメントしました。

日立賞: 失注ポストモーテム AI 「失注リフレクター」。日立の内藤氏は、失注分析の難しさに踏み込みました。「受注は意外と再現性が低く、失注は再現性が高いという事実をよく見ていくと、受注確度を上げることに繋がります。そこをきちんと言語化できているのがとても良かった。ぜひお客様の営業活動にも役立てられる形へ、 Gemini と一緒にアイデアを練り上げていってください」。

日立賞: Gemini マルチエージェントによる設計書レビュー支援。日立のものづくりで培ってきた設計の知見を、そのままレビューの観点としてエージェントに持たせた点が評価されました。

5 組とも、削減できた時間や工数といった数字だけでなく、現場の心理的な負担まで軽くしている点が印象的でした。

これからも、日立の挑戦とともに

閉会のあいさつで、 Google Cloud の渕野はこの日の手応えをこう振り返りました。「今日のプレゼンはどれも Q&A が活発で、発表を見て自分のアイデアはこうできるんじゃないか、と考えている様子が伝わってきました。みなさんを支援している私たち Google のメンバーも、やりがいと達成感を感じる素晴らしい会でした」そして、これからへの期待も。「 1 回目でこのレベルの高さです。 2 回、 3 回と続けていけば、どんどん上がっていくはずです。私たちも引き続き、しっかり支援させていただきます」。

また、審査員を務めた日立デジタルシステム&サービス/経営戦略統括本部統括本部長内藤氏からは、30年のキャリアを振り返りつつ、日立の未来への明るい展望が語られました。

「私自身、社内で Gemini Enterprise を毎日5回以上は必ず使う愛用者ですが、今日の皆さんのアイデアを聞いて『こういう使い方もあったのか！』と非常に理解が深まりました。今すぐにでもやってみたいアイデアがたくさんあり、とても楽しいひとときでした」と感謝を述べました。

また、コンテストを通じて見えた社内の変化についても、次のように熱く語りました。「この活動は、自分たちの業務を良くしていく『カスタマーゼロ』につながることはもちろんですが、何より発表者の皆さんが本当に楽しそうでした。これまで30年間会社にいますが、横の人がこんなに楽しそうに仕事をしている姿は見たことがありません。今日そういう一面が見えて、日立の未来は明るいんじゃないかと勝手に思ったりしています」

挨拶の最後には、「日立の取り組みと、Google さんの発展を心から祈念して、ぜひ皆さんと一緒にやってみたいと思います！」と会場に呼びかけました。内藤氏の「すごいぞ！」という掛け声に、会場全体が「Gemini！」と大きな声で応え、イベントは最高潮の盛り上がりのなか締めくくられました。

開会で西さんが語った「日立を AI のショーケースに」という思いは、この日の 10 組の発表で、もう確かな形になり始めていました。現場の「困った」から生まれたアイデアが、 112 件という数になって集まり、その一つひとつが誰かの仕事を軽くしていく。 Google Cloud はこれからも、日立のみなさまのこうした挑戦に、 Gemini Enterprise とともに伴走していきます。

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

Thu, 09 Jul 2026 01:00:00 +0000

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

AlloyDB は AI ネイティブなデータベースです。単なる受動的なデータストアではなく、データをインテリジェントに理解して処理します。AlloyDB では、業界をリードするベクトル検索とハイブリッド検索、会話型エージェントを構築するためのほぼ 100% の精度を誇る自然言語から SQL への変換機能、好みのエージェント型 IDE で構築できるツール、AI 関数を通じて Gemini などの基盤モデルのインテリジェンスをデータに直接適用する機能を利用できます。

このブログ投稿では、AI 関数処理における大きなブレークスルーと、一連のまったく新しい AI 関数について説明します。

まず、AI 機能とは具体的にどのようなものでしょうか？AI 機能は Gemini の世界中の知識を AlloyDB のデータに適用します。ユーザーからの生のフィードバックを管理する課題について考えてみましょう。そのようなフィードバックは構造化されておらず、解析が困難です。このデータを検索に活用するには、前処理とエンティティ抽出が必要になる場合があります。知識抽出のために複雑なカスタムパイプラインを維持する代わりに、AlloyDB 内で Gemini の生成機能を直接使用して、未加工のテキストを構造化された検索可能な分析情報に変換できます。たとえば、ai.generate を使用して、生のフィードバックをクリーンで構造化された JSON に即座に変換する方法は次のとおりです（その他の例はこちら）。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n log_id,\r\n raw_content,\r\n -- Gemini 3.0 を使用して、ユーザーからの生のフィードバックについて推論し、構造を抽出する\r\n ai.generate(\r\n model_id => 'gemini-3.1-pro-preview',\r\n prompt =>\r\n 'Analyze this raw customer feedback entry. Extract the country, service name, and a 1-sentence summary of the feedback. Return as JSON.'\r\n || raw_content) AS structured_feedback\r\nFROM raw_feedback_logs\r\nWHERE user_type <> 'internal';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617ac5f490>)])]>

結果の例を次に示します。

log_id	raw_content	structured_analysis
1001	2025-12-16 08:00:01 [ERROR] Service: OrderSvc \| DbConnectionTimeout: 5,000 ミリ秒経過後、プール「primary-shard-04」から接続を取得できませんでした。	{"errorCode": "DbConnectionTimeout", "serviceName": "OrderSvc", "rootCause": "サービスが 5,000 ミリ秒のタイムアウト制限内にプライマリシャードプールからデータベース接続を取得できませんでした。"}
1002	2025-12-16 08:05:12 [WARN] Service: IdentityProvider \| 401 Unauthorized: user_id=9942 の署名なしトークンの検証に失敗しました。署名が一致しません。	{ "error_code": "401", "service_name": "IdentityProvider", "root_cause": "署名が一致しないため、署名なしトークンの検証に失敗しました。" }
1003	2025-12-16 08:12:45 [CRITICAL] Service: AnalyticsEngine \| OutOfMemoryError: Java ヒープスペース。1.2 GB の配列の割り当てに失敗しました。ヒープ使用率 99%。	{ "error_code": "OutOfMemoryError", "service_name": "AnalyticsEngine", "root_cause": "サービスが 1.2 GB の配列を割り当てようとした際に、利用可能な Java ヒープメモリを使い果たしました。" }
1004	2025-12-16 08:25:33 [ERROR] Service: WebFrontEnd \| 404 NotFound: リソース /api/v3/users/profile/settings が見つかりません。アップストリームから 404 が返されました。	{ "error_code": "404", "service_name": "WebFrontEnd", "root_cause": "ユーザープロファイル設定に対してリクエストされた API リソースが、アップストリームサービスで見つかりませんでした。" }
1005	2025-12-16 08:35:50 [WARN] Service: NotificationGateway \| GatewayTimeout: 外部プロバイダ「SendGrid」が 30 秒以内に応答できませんでした。再試行がスケジュールされました。	{"error_code": "GatewayTimeout", "service_name": "NotificationGateway", "root_cause": "外部プロバイダ SendGrid が 30 秒のタイムアウト制限内に応答できませんでした。"}

要約や感情分析を行う関数を追加

Google のコア AI 関数である ai.generate、ai.rank、ai.if、ai.forecast の一般提供が開始されました。最初の 3 つの関数のユースケースについて詳しくは、こちらのブログ投稿をご覧ください。予測機能の実際の動作を確認するには、こちらの詳細をご覧ください。

この勢いに乗り、Google は 3 つの新しい関数、ai.summarize、ai.agg_summarize、ai.analyze_sentiment を導入しました。

ai.analyze_sentiment: テキストの感情的なトーンを肯定的、否定的、中立的として自動的に分類します。
ai.summarize: 長文のテキストを、元のトーンとニュアンスを維持しながら、最も重要な情報に凝縮します。
ai.agg_summarize: 列内の複数の行を処理して、（GROUP BY 句などを使用して）グループ全体の統合された単一の要約を生成する集約ツール。

ai.agg_summarize を使用して、小売ウェブサイトの商品レビューを統合する方法の例を以下に示します。

code_block: <ListValue: [StructValue([('code', 'SELECT productname, ai.agg_summarize(review) as reviews_summary\r\nGROUP BY productname;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617ac5f5e0>)])]>

2 つのゲーム機製品のレビューを要約した結果の例を以下に示します。

productname

reviews_summary

AlphaCore Console

ユーザーは、美しい 4K グラフィック、スムーズな 120 Hz のフレームレート、人間工学に基づいたコントローラのデザインを高く評価しています。

しかし、複数のレビューで、長時間ゲームをプレイすると冷却ファンの音がうるさくなるという不満が示されています。

全体として、熱や騒音に関するわずかな不満はあるものの、最高水準のゲーム機と見なされています。

NeoCore Console

ユーザーは、外出先での携帯ゲームに最適な、優れたバッテリー駆動時間と鮮やかな OLED ディスプレイを気に入っています。

多くのユーザーが、UI が遅く感じられることと、ゲームライブラリが現在限られていることを指摘しています。

カジュアルゲーマーには大きな価値がありますが、パワーユーザーはパフォーマンスが不十分だと感じる可能性があります。

LLM の力をデータに: 大幅な高速化とコスト削減を実現

Google は、AI 機能の処理において前例のないパフォーマンス向上と費用削減のブレークスルーを達成しました。以前は、大規模なデータベースの各行で基盤モデルの呼び出しを実行することで、費用とレイテンシの制約が生じていました。2 つの画期的な機能を導入することで、これらの障壁を打ち破りました。

AI 関数のスマートバッチ処理: この AI 関数アクセラレーション機能は、AI 関数呼び出しのインテリジェントなバッチ処理を実現し、パフォーマンスと品質を最適化します。この効率性は、プロンプトのオーバーヘッドの重複を排除することで実現されます。LLM の定型的な指示は、個々の行で繰り返されるのではなく、バッチごとに 1 回送信されます。「これをアプリケーションレイヤで実行してはいけないのか？」と疑問に思われるかもしれません。そうしない理由は、AlloyDB が最適な結果を得るための適切なバッチサイズをインテリジェントに決定するからです。バッチサイズを過小評価すると、費用とレイテンシのメリットが得られません。バッチサイズを過大評価すると、LLM へのプロンプトが膨張してハルシネーションが発生したり、モデルのトークン制限を超えたりする可能性があります。AlloyDB は、それぞれのリクエストに最適なバッチサイズを計算するだけでなく、設定なしで自動的に再試行を処理するため、パイプラインの復元力を維持できます。社内でテストを行ったところ、大きな成果が得られました。たとえば、従来の 1 行ずつの LLM 呼び出しと比較して、パフォーマンスが最大 2,400 倍向上しました（1 秒あたり 10,000 行を処理）。現在、この機能は ai.if 関数と ai.rank 関数で利用できます。今後、他の関数もサポートされる予定です。

このユースケースを解決するために、ai.if でスマートバッチ処理 / アクセラレーションを使用する例を見てみましょう。ある顧客が、水深 60 メートル以上でも使用できるカメラをガジェット販売サイトで検索しているとします。従来のハイブリッド検索では、最も近い意味的一致と全文一致が抽出されますが、数値データの厳しい制約が考慮されません。つまり、水深 20 メートルでしか使用できないカメラが表示される可能性があります。AlloyDB の ai.if ベースのインテリジェントフィルタリングを使用すると、データベースは水深のニュアンスを実際に理解し、水深 60 メートルの基準を満たすか、それを上回る商品をクエリで返します。以下の例では、バッチサイズを指定する必要がないことに注目してください。ai.if を使用すると、AlloyDB がすべての最適化を内部で処理します。

code_block: <ListValue: [StructValue([('code', "-- スマートバッチ処理 / AI 関数アクセラレーション\r\nSET google_ml_integration.enable_ai_function_acceleration = on;\r\nSELECT productid, productname, category,description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617ac5ff40>)])]>

架空のガジェットサイトでの検索結果の例を以下に示します。商品の詳しい説明が、水深 60 メートルで使用できるという条件に合致していることに注目してください。

最適化された AI 関数: 効率性をさらに高めるために、まずは ai.if に、最適化モードを導入しました。埋め込みを利用し、特定の LLM 出力に基づいてトレーニングされた小さなプロキシモデルをデプロイすることで、データベース内でネイティブに意思決定を処理できます。これにより、外部 LLM を呼び出す必要性が大幅に減ります。Google の内部テストでは、驚くべき成果が見られました。たとえば、1 秒あたりに処理される行数が最大 100,000 行（23,000 倍増加）に達し、費用が 6,000 分の 1（0.1 セント）に削減されました。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。最適化された ai.if を使用すると、AlloyDB は次の処理を行います。

プロキシモデルをトレーニングする: AlloyDB は、データのサンプルに基づいて軽量なプロキシモデルをトレーニングします。これは、最適化されたクエリのモデルをトレーニングするために、ai.if 関数で PREPARE ステートメントを使用すると、バックグラウンドで行われます。
クエリを実行する: EXECUTE ステートメントを使用すると、AlloyDB はトレーニング済みのプロキシモデルを使用してクエリをローカルで処理します。
LLM にフォールバックする: モデルの精度が低い場合や、モデルが見つからない場合、AlloyDB は自動的に LLM の使用にフォールバックします。

水深 60 メートル以上で使用できるカメラを検索する先ほどの例で、最適化された ai.if を使用する場合を見てみましょう。ここでは、PREPARE ステートメントを使用してプロキシモデルをトレーニングし、その後 EXECUTE ステートメントを実行します。

code_block: <ListValue: [StructValue([('code', "-- 最適化された関数 / プロキシモデルを準備する\r\nPREPARE waterproof_camera_60m AS\r\nSELECT productid, productname, category, description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description,\r\n description_embedding);\r\n\u200b\r\n-- プロキシモデルを実行する\r\nEXECUTE waterproof_camera_60m;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617ac5f2b0>)])]>

上のスクリーンショットのように、水深 60 メートルで動作するという基準に実際に合致する商品が表示されます。説明をより詳しく確認できるように、最初の 3 つの商品を表にしたものを以下に示します。

productname	description
Pulsetron Action Camera MZ314	このカメラで次の冒険を制覇しましょう。厳しい自然環境でも使用可能。水深 60 メートルまで潜水できるほか、耐衝撃性に優れたアドベンチャー仕様のシャーシで、過酷なトレイルにも対応します。高度な水平手ぶれ補正により、ジャンプ、ターン、水しぶきなど、あらゆる動きが完璧にスムーズにレンダリングされ、比類のない流動性で映像がストーリーを伝えます。
Hyperbyte Action Camera LG688	激しいアクティビティでも、世界を息をのむほど細部まで捉えます。このカメラは、驚くほど頑丈なポケットサイズのフレームに、1 インチの強力なセンサーを搭載しています。プロ仕様の機器に匹敵する、美しい 5K 動画と鮮明な 20MP の静止画を撮影できます。水深 60 メートルの優れた防水性能で、これまで以上に深く潜水できます。
Alphasync Action Camera WW897	このコンパクトでパワフルなカメラは、あらゆる自然環境に対応。1 インチの大型センサーが、息をのむような瞬間を 5K 動画と 20MP の鮮明な静止画に変換します。水深 60 メートルの防水性能と革新的な水平手ぶれ補正により、深海から高山まで、あらゆる環境で使用可能で、驚くほど安定した映像を実現します。

デモのご紹介

こちらのデモ動画で、これらの機能がどのように連携するかをご覧ください。

始め方は簡単

AI ワークロードに前例のないスピードと費用対効果をもたらす準備はできていますか？

AlloyDB を初めてご利用の場合: 30 日間の無料トライアルで AlloyDB をお試しください。
AI 関数のクイックスタート: いくつかの簡単な前提条件を満たして、SQL クエリ内で ai.if、ai.generate、ai.analyze_sentiment などの関数を直接呼び出しましょう。まずは、実用的な例をご覧ください。
パフォーマンスの向上と費用の最適化: 最大限のパフォーマンス向上と費用削減を実現するには、最適化された関数に関するガイドに従ってください。この最適化は ai.if のプレビュー版で利用可能であり、まもなく他の関数でも利用可能になる予定です。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。
スループットのスケーリング: スマートバッチ処理を使用して AI 関数を高速化する（ai.if と ai.rank のプレビュー版で利用可能）か、配列ベースの関数（すべての LLM ベースの AI 関数で一般提供）を使用して、大量のプロンプトをスムーズに処理することができます。

- グループプロダクトマネージャー、Darshana Sivakumar

- ソフトウェアエンジニア、Pushkar Khaldikar

Gemini Omni Flash と Nano Banana 2 Lite が圧倒的なスピードと費用対効果をもたらす

Wed, 08 Jul 2026 02:00:00 +0000

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

アイデアのスピードに合わせてツールが動くとき、創造性は最大限に発揮されます。より豊かで信頼性の高いエクスペリエンスを提供しつつ、再生成にかかる時間と費用の削減を実現するために、Gemini Enterprise Agent Platform に新たに 2 つのモデルを追加します。

まず、Nano Banana 2 Lite（Gemini 3.1 Flash-Lite Image）の一般提供を開始します。このモデルは、Nano Banana モデルファミリーの中で最も高速かつ費用対効果の高い画像生成・編集モデルです。アイデアを次々と生み出す場合でも、広告バリエーションの A/B テストを行う場合でも、数百万人のユーザー向けのソーシャルアプリを強化する場合でも、このモデルを使用すると、探索、反復処理、スケーリングを迅速に行うことができます。

もう 1 つは、Gemini Omni Flash です。こちらは、公開プレビュー版としてご利用いただけます。Gemini の実世界に関する知識を基盤とするモデルで、高品質な動画生成と会話型編集が可能になり、キャラクターや商品の入れ替え、動的なスタイル変換、オブジェクトの追加、ライティングの再調整など、動画アセットの編集や改良をきめ細かく制御できます。

Gemini Omni Flash と Nano Banana で、どんなに斬新な構想でもカタチにできます。

どちらのモデルも、画像や動画の生成・編集において、市場をリードする最先端モデルの中でも最高レベルのコストパフォーマンスを実現します。

Gemini Omni Flash: 高品質な動画生成・編集

Gemini Omni Flash を活用すれば、会話型の動画生成・編集機能をアプリケーションに直接実装できます。ユーザーは、強力なメディアモデルを自身のエージェントワークフローに簡単に組み込むことができ、プラットフォームを切り替えることなく、動画の作成、リミックス、ブラッシュアップを行えます。

Google DeepMind による包括的なベンチマーク情報については、Gemini Omni をご覧ください。

Gemini Omni Flash は、以下の 4 つの主要分野に重点を置いて構築されています。

会話型編集: 自然言語を使用して、キャラクターの入れ替え、ライティングの再調整、アングルの変更などを行うことができます。元の音声トラックと動画トラックはネイティブに維持されます。
マルチモーダル入力: テキスト、画像、動画の入力を組み合わせて、動画生成をガイドします。Gemini Omni Flash は、キャラクター、オブジェクト、スタイルの整合性を維持しつつ、すべての動画出力でネイティブに音声を生成します。
実世界の知識とシミュレーション: 物理法則に関する直感的な理解に加えて、歴史、科学、文化的背景に関する Gemini の知識を組み合わせることで、写実的な表現と意味のあるストーリーテリングとの間のギャップを埋めます。
テキストとアクションの同期: 読みやすいテキストやグラフィックを動画内に直接レンダリングし、キネティックタイポグラフィや解説テキストを画面上の動きと同期させます。

注: Gemini Enterprise Agent Platform API を介した Gemini Omni Flash での音声参照、動画参照、最終フレーム、シーン拡張、高解像度のサポートは近日中に提供開始予定です。

モデルの機能の完全なリストと統合方法については、ドキュメントと料金をご覧ください。

Gemini Omni Flash は、最高レベルのコストパフォーマンス（動画出力 1 秒あたり $0.10）で動画生成・編集機能を提供します。

Gemini Omni Flash を使用して次世代のアプリケーションやクリエイティブなエージェントワークフローを構築しているお客様

「Google の最新モデルである Gemini Omni Flash や Nano Banana 2 Lite を、当社のオールインワンクリエイティブ AI スタジオである Adobe Firefly に導入できることを大変嬉しく思います。これにより、クリエイターは、アイデアからコンテンツ完成に至るまでのプロセスをより迅速に進められるようになります。これらの新しいモデルは、プロフェッショナル向けツールと業界最高水準のクリエイティブ AI モデルを連携したワークフローで提供するという Adobe の戦略をさらに強化するものであり、クリエイティブなアイデアを形にする方法をより柔軟かつ高度に制御できるようになります。」- Adobe、プロダクト担当シニアディレクター、Matt Chotin 氏

「まず目を引いたのは、Gemini Omni Flash モデルでできることが想像以上に多彩だったことです。VFX の能力には驚かされましたし、プロデューサーの視点で見ると、非常に面白い可能性を感じました。しかし、私が最も期待しているのはハイブリッドな活用の可能性です。従来の実写撮影で一緒に仕事をしてきたスタッフをそのまま起用しつつ、AI が現在実現できる幅広い機能を同じ制作現場に採り入れることができるのです。」 - Invideo、クリエイティブディレクター、Nishant Tahilramani 氏

「Google との継続的なパートナーシップを通じて、WPP は新しい Gemini Omni Flash モデルへの早期アクセス権を獲得し、当社のエージェント型マーケティングプラットフォームである WPP Open に統合しました。Gemini Omni Flash のマルチモーダル機能（画像、音声、動画の入力参照をシームレスに扱える能力）と直感的な会話型編集機能の組み合わせは、コントロールされた AI 制作の飛躍的な進歩を意味します。各チームではすでに、クライアントの案件に向けて、アセットのローカライズや高精度な商品の差し替え、動的なスタイル変換などの検証を重ねています。Google Cloud とのパートナーシップを通じて、AI 主導のクリエイティビティの可能性を絶えず広げ、極めて柔軟かつインテリジェントな成果を提供していけることを、大変嬉しく思います。」- WPP、最高イノベーション責任者、Elav Horwitz 氏

Nano Banana 2 Lite: 費用とスピードを重視した設計

Nano Banana 2 Lite は、わずか 4 秒で画像を生成できます。デザインコンセプトを数秒で生成して反復修正できるため、白紙の状態から完璧なレイアウトを瞬時に作成できます。

Nano Banana 2 Lite generates images in as little as four seconds.

Nano Banana（Gemini 2.5 Flash Image）からの大幅な改良

Nano Banana 2 Lite は、高速かつ費用対効果の高い画像生成が可能なほか、従来モデルの Nano Banana と比較して視覚品質と機能性が大幅に向上しています。また、複雑なタスクも高速で実行できるよう、中核機能を強化しています。

実世界の知識: 文脈に即した的確なシーンや、データの簡易的な視覚化、特定の場所を想定したモックアップを、素早く書き出すことができます。
キャラクターの一貫性: 複数の高速生成にわたってキャラクターのアイデンティティやオブジェクトの忠実性を維持できるため、ストーリーボードツールの構築や、e コマースのバーチャル試着機能の組み込みが容易になります。
テキスト作成やローカライズの迅速化: 画像の高速生成と同時に鮮明なテキストを直接レンダリングして、コピー案をその場で作成します。ローカライズされた広告バリエーション全体で、タイポグラフィの効果を即座に確認できます。

モデルの機能の完全なリストと統合方法については、ドキュメントと料金をご覧ください。

注: 画像生成は非常に高速ですが、画像編集では応答時間が若干長くなる場合があります。

高速かつ費用対効果に優れた画像生成を実現。従来モデルの Nano Banana と比較して、画質と機能性の両面で飛躍的な進化を遂げています。

Nano Banana 2 Lite でより高速なビジュアルエクスペリエンスを構築している業界のリーダー

「スピードはもはや制約ではありません。生成速度が想像力を上回れば、クリエイターはツールの処理を待つことなく、アイデアを形にすることに集中できます。Nano Banana 2 Lite は、その感覚をクリエイティブなプロセスに吹き込み、思考をほぼ瞬時にビジュアルへと変えてくれます。Artlist のユーザーにとっては、進行状況バーを眺める時間が減り、創作やブラッシュアップ、パーソナライズに費やす時間が増えることを意味します。これにより、時代の潮流に合わせたスピード感で制作を進められるようになるのです。」 - Artlist、AI コンテンツおよびイノベーション担当ディレクター、Idan Yonas 氏

「Nano Banana 2 Lite は高速かつ信頼性が高いツールであり、デザイナーが Figma Weave のノードベースのキャンバス上でより多くのアイデアを探求し、ユニークな画像を作成するのをサポートしてくれます。制作のフローを維持しながら、迅速なブラッシュアップを行うのに理想的です。」 - Figma、共同創設者兼クリエイティブディレクター、Itay Schiff 氏

「当社では、スライド資料からウェブページに至るまで、Manus の自律型ワークフロー内でリアルタイムの画像生成を実現するために、Nano Banana 2 Lite をテストしてきました。そのスピードはこうしたシナリオに非常に適しており、当社の AI エージェントはビジュアルのブラッシュアップを迅速に行い、わずか数秒で結果を出せるようになりました。画質も優れており、フルバージョンの Nano Banana 2 に匹敵するレベルです。今後もパートナーシップを継続し、より優れたエクスペリエンスを共に構築していけることを楽しみにしています。」 - Manus AI、共同創業者 / 最高製品責任者、Tao Zhang 氏

安全性と企業ガバナンス

C2PA コンテンツ認証情報と人の目には見えない SynthID 透かしがデフォルトで有効になっており、両方のモデルでコンテンツの真正性を検証できます。

Gemini Enterprise Agent Platform では、大規模かつ同時実行が多い API リクエストを確実に処理するために、本日より Nano Banana 2 Lite のプロビジョンドスループット（PT）の提供を開始いたします。Gemini Omni Flash のプロビジョンドスループットは、近日中に提供開始予定です。

今すぐ始めましょう

これらの画像や動画の生成・編集機能を、ご自身のアプリケーションやクリエイティブワークフローに早速実装してみましょう。ご利用開始にあたっては、以下のリソースをお役立てください。

モデルの試用: Gemini Enterprise Agent Platform 内の Agent Studio
API ドキュメント: Nano Banana 2 Lite、Gemini Omni Flash
Colab ノートブックへのアクセス: Nano Banana 2 Lite、Gemini Omni Flash
料金: Agent Platform の料金（両方のモデル）
プロンプトガイド: Nano Banana、Gemini Omni Flash
Gemini Omni Flash エージェントスキルのプロンプト

- Cloud AI、プロダクトマネジメント担当バイスプレジデント、Michael Gerstenhaber

BigQuery の AI.AGG 関数で全体像を把握し、傾向を分析する

Tue, 07 Jul 2026 02:00:00 +0000

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

Google は先日、BigQuery の AI.AGG() 関数のプレビュー版を発表しました。AI.AGG() を使用すると、1 行の SQL 内で自然言語による指示を与えるだけで、数百万行に及ぶ非構造化データやマルチモーダルデータに関する情報を要約、合成できます。

1 行の SQL で数百万行を要約: AI.AGG

BigQuery には、データの個々の行を分析するのに役立つ強力な AI 関数がすでに用意されていますが、非構造化データを大規模に分析するには、別のアプローチが必要となります。 AI.AGG() を使用すると、ログやドキュメントなどの非構造化データに対して、以下のような質問をすることができます。

製品に対する否定的なレビューの中で、要望が多かった機能の上位 3 つはどれですか？
ユーザーが最も頻繁に遭遇しているエラーの種類は何ですか？また、何から調査を始めるべきですか？
当社の自動エージェントが顧客の問題解決に一貫して失敗しているのは、どのようなシナリオですか？

この投稿では、AI.AGG() 関数について詳しく説明するほか、この関数によって実現できるユースケースをいくつかご紹介します。また、複雑かつインテリジェントなデータ分析を行うために、BigQuery の他のマネージド AI 関数と組み合わせて使用する方法についてもご説明します。

AI.AGG() を使用したシステムログの分析

AI.AGG() の威力を示す好例が、システムロギングの分析です。ログメッセージ、警告、エラー、スタックトレースには、サービスを改善するうえで非常に役立つ情報が含まれている可能性がありますが、手動で調査するには時間と労力がかかります。特に、大規模な運用を行っており、確認すべきログが数千件もある場合はなおさらです。

AI.AGG() を使用すると、多数のログを一度に簡単に分析できるため、グループ化や優先順位付けを行って、どのログを最初に詳しく調査すべきかを判断できます。実際、BigQuery エンジニアリングチームは AI.AGG() を開発する際にこのアプローチを採用しており、この機能自体の入力処理に関連するエッジケースを特定するためにこの関数を利用していました。

このことを実証するために、Loghub から入手できる Apache Spark 標準の INFO ログの公開データセットを分析してみましょう。クラスタでは、FATAL エラーがスローされることなく、メモリスラッシング、クロックドリフト、ブロードキャストボトルネックといった問題に直面することがよくあります。AI.AGG() を使用すると、こうした一見正常に見えるログから隠れた非効率性を分析できます。サンプルデータファイルは、UI、CLI、クライアントライブラリなど、対応している任意の方法を使用して BigQuery に読み込むことができます。以下の例では、bq_logs_demo というデータセットと spark_logs_unstructured というテーブルにログファイルを読み込んだことを前提としています。

ここでは、プロンプトをどのように作成しているかに注目してください。モデルに対して「すべて正常」と回答することを明示的に許可することで、エラーのハルシネーションを防ぎながら、特定の異常を検出するように指示しています。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n Component AS spark_component,\r\n COUNT(*) AS log_count,\r\n AI.AGG(\r\n Content,\r\n 'これらの Spark システム INFO ログを分析してください。2 文で簡潔にまとめてください。まず、このコンポーネントの通常の動作を説明してください。次に、隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターンを明示的に特定してください。'\r\n ) AS performance_analysis\r\nFROM\r\n `bq_logs_demo.spark_logs_structured`\r\nGROUP BY\r\n Component\r\nORDER BY\r\n log_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2de940>)])]>

これらの結果から、AI.AGG() が「正常に動作している」というメッセージを適切に認識しつつ、重要な診断情報を抽出していることがわかります。

クエリ結果のペイン: ログデータセットに対する AI.AGG() が生成した分析情報を表示

非構造化テキストや画像データからのカテゴリ抽出

次に、BigQuery の一般公開データセットの一つである、cymbal_pets（架空のペット用品店）を使用して、AI.AGG() の柔軟性がわかるユースケースをいくつか見ていきましょう。このデータセットには、店舗が取り扱う商品のカタログが用意されています。商品の名前、説明、画像といった非構造化データが含まれているため、非構造化データを処理する AI 関数の威力を示す好例です。

たとえば、データセット内の商品を分類するとします。この場合の最初の課題は、商品にラベルを付けることではなく、商品カタログ全体にどのようなカテゴリが存在するかを把握することです。AI.AGG() を使用すると、元の商品名や説明を分析するようにモデルに指示でき、カテゴリを包括的に特定できます。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2debb0>)])]>

このクエリは、カテゴリについてシンプルな平文のリストを返します。

商品データセットに対して AI.AGG() によって特定されたカテゴリの平文の結果。

この最初のクエリは探索には最適ですが、信頼性の高い自動化されたデータパイプラインを構築するには、シンプルな平文の文字列では不十分です。実際にデータをタグ付けするには、AI.AGG() に JSON 配列などの構造化された形式を返すように指示する必要があります。その後、構造化されたカテゴリを別の AI 関数である AI.CLASSIFY() のパラメータとして使用することで、各商品にカテゴリのラベルを実際に付与できます。

以下の SQL ステートメントは、これらの各ステップを 1 つのスクリプトで完了します。

code_block: <ListValue: [StructValue([('code', "-- 1. カテゴリの配列を保持する変数を宣言する\r\nDECLARE generated_labels ARRAY<STRING>;\r\n\u200b\r\n-- 2. 結果を保存するデータセットを作成する\r\nCREATE SCHEMA IF NOT EXISTS categorized_cymbal_pets;\r\n\u200b\r\n-- 3. AI.AGG で JSON 文字列を生成し、変数に抽出する\r\nSET generated_labels = (\r\n SELECT\r\n JSON_VALUE_ARRAY(\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n '主な商品カテゴリを特定してください。文字列の有効な JSON 配列を 1 つだけ返してください。マークダウンのコードブロック、バッククォート、会話テキストは含めないでください。'\r\n )\r\n )\r\n FROM `bigquery-public-data.cymbal_pets.products`\r\n);\r\n\u200b\r\n-- 4. 変数を AI.CLASSIFY に直接フィードする\r\nCREATE OR REPLACE TABLE `categorized_cymbal_pets.categorized_products` AS (\r\nSELECT\r\n product_name,\r\n description,\r\n AI.CLASSIFY(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n generated_labels\r\n ) AS assigned_category\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2dee50>)])]>

結果のテーブルが表示されます。このテーブルには assigned_category が含まれています。

AI.AGG() と AI.CLASSIFY() で作成された新しい assigned_category 列を含む categorized_products テーブルのプレビュー。

中間テーブルをよく見ると、構造化されたカテゴリが最初の平文の結果からわずかに変更されていることがわかります。これには 2 つの理由があります。1 つは、LLM が非決定論的であるということです。そのため、同じプロンプトに対してまったく同じ回答を常に返すとは限りません。もう 1 つは、新しい出力構造に対応するようにプロンプトが調整されたことです。

返された商品カテゴリは、プロンプトの一部として要求されたとおり、AI.AGG() によって JSON として構造化されている。

テーブルにカテゴリのラベルが付けられたので、カテゴリごとにグループ化して従来の SQL 集計を行うことも、AI.AGG() を使用して各カテゴリを個別に扱うこともできます。

たとえば、以下のクエリでは、従来の指標（行数など）に加え、グループ化された特定の商品に共通する点について AI が生成した要約も併せて取得します。

code_block: <ListValue: [StructValue([('code', "-- 新しく割り当てられたカテゴリごとに分析情報を統合する\r\nSELECT\r\n assigned_category,\r\n COUNT(*) AS item_count,\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'このカテゴリの商品の共通する特徴や目的を簡潔に説明する要約を 1 文で作成してください。'\r\n ) AS category_summary\r\nFROM\r\n `categorized_cymbal_pets.categorized_products`\r\nGROUP BY\r\n assigned_category\r\nORDER BY\r\n item_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2de670>)])]>

クエリ結果: AI.AGG() による分析と従来の SQL 手法による分析を併せて表示。

非構造化データはテキストに限定されません。AI.AGG() はマルチモーダル入力にネイティブに対応しているため、画像ファイルから、直接集約された分析情報を返すことができます。

cymbal_pets Google Cloud プロジェクトには、商品写真が豊富に含まれた Cloud Storage バケットも用意されています。外部オブジェクトテーブルを作成することで、画像 URI を AI.AGG() に直接安全に渡して、コレクション全体の視覚的コンテンツを要約するようにモデルに指示できます。

code_block: <ListValue: [StructValue([('code', "-- オブジェクトテーブル内の画像コンテンツを要約する\r\nSELECT\r\n AI.AGG(\r\n STRUCT(OBJ.GET_ACCESS_URL(ref, 'r')),\r\n 'これらの画像の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.product_images`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2de430>)])]>

クエリ結果: Google Cloud Storage にある商品画像を分析して、AI.AGG() が商品カテゴリを抽出。

AI.AGG() の仕組みとベストプラクティス

AI.AGG() をご自身の環境で効果的に使用するには、その内部でのデータ処理の仕組みを理解することが役に立ちます。ここでは、コンテキストウィンドウ、エラー処理、パイプラインの最適化について知っておくべきことを紹介します。

1. コンテキストウィンドウとマルチレベル集計LLM には特定のコンテキストウィンドウがあり、大量の入力を処理することが難しい場合があります。AI.AGG() は、入力行を自動的にバッチに分割し、それらのバッチを集計した後、その集計結果を最終的な回答としてまとめることで、この問題を解決します。つまり、大量の行を渡す際に、コンテキストウィンドウを手動で管理する必要はありません。なお、AI.AGG() は、データの行を複数のバッチに分割することはありません。そのため、行がスキップされないように、各行がコンテキストウィンドウよりも小さくなるようにしてください。行数が多く、かつ各行が小さいほど、AI.AGG() は各行のバッチ処理においてより柔軟に対応できます。

2. マルチレベル集計におけるトークン使用量 AI.AGG() はマルチレベルの集計構造を使用するため、モデルに送信される入力トークンの合計数は、開始テーブルの元のトークン数よりも多くなる場合があります（必要な集計のラウンド数によって異なります）。ベストプラクティスとして、LIMIT を使用するか、データを AI.AGG() に渡す前に上流で事前フィルタリングすることで、トークン数を常に減らすようにしてください。

3. モデルエンドポイントの指定モデルエンドポイントを指定しない場合、AI.AGG() はデフォルトで最新のモデルを使用します。ただし、本番環境のパイプラインでは、多くの場合、明示的な制御が必要となります。

短縮形の名称: 短縮形のエンドポイント（例: gemini-2.5-flash）を使用できます。その場合、AI.AGG() はクエリ実行リージョンでそのモデルを使用します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'gemini-2.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2dea30>)])]>

完全修飾名: 希望するモデルがクエリ実行リージョンで対応していない場合、またはグローバルエンドポイントやマルチリージョンエンドポイントを使用する場合は、モデルを完全修飾名で指定します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'https://aiplatform.googleapis.com/v1/projects/[YOUR_PROJECT]/locations/global/publishers/google/models/gemini-3.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2de310>)])]>

4. 入力と出力のモダリティ

入力: AI.AGG() では、テキスト（文字列またはテキストファイルへの参照）と画像データに対応しています。これらの型の配列にも対応していますが、既知の問題に関するドキュメントをご参照のうえ、画像の配列に関するエッジケースの注意事項をご確認ください。
出力: この関数は常に文字列を返します。モデルに対して、JSON や Markdown の形式で出力するようにプロンプトで指示することは可能ですが、このことがデータベースエンジンで厳密に適用されるわけではないことにご注意ください。マルチモーダル出力（画像の生成など）は、現在対応していません。

5. NULLの処理AI.AGG() は、NULL の入力行を処理せずに自動的にスキップします。ただし、構造化データを渡す場合は注意が必要です。他の BigQuery AI 関数のように、AI.AGG() は標準の CONCAT() 関数と同様に STRUCT フィールドを連結します。つまり、STRUCT 内のフィールドが 1 つでも NULL である場合、その行全体が NULL として扱われ、スキップされます。

最初のカテゴリのクエリをもう一度見てみましょう。たとえば、products テーブルのいくつかの行で description が欠落している場合、NULL の連結ルールにより、これらの行は何の警告もなく分析から完全に除外されてしまいます。以下に、IFNULL() を使用してフォールバック文字列を指定し、説明が空白であってもすべての商品が確実に考慮されるようにする方法を紹介します。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明（オプション）から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', IFNULL(description, '説明なし')),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a2defd0>)])]>

6. エラー処理 AI.AGG() は、無効な入力を受け取った場合や LLM 処理中にエラーが発生した場合に、部分的な結果を提供しようとします。無効な入力を含む行や、LLM モデルによって拒否された行は、最終結果には反映されません。

AI.IF() などのスカラーマネージド AI 関数と同様に、BigQuery ジョブの統計情報を確認することで、処理に失敗した行数を正確に把握できます。

生成 AI 関数エラーの詳細情報の例。

お試しください

上記は、非構造化データの分析に役立つ AI.AGG() の機能のほんの一例です。現在、AI.AGG() 関数は、すべての BigQuery ユーザー向けにプレビュー版として提供しています。ぜひ、ご自身のユースケースでお試しください。

また、BigQuery の他のマネージド AI 関数（AI.CLASSIFY()、AI.IF()、AI.SCORE()）や、AI.GENERATE() などの汎用関数もぜひお試しください。皆様がこれらの関数を活用してどのような成果を達成されるのか、今後を楽しみにしています。

- ソフトウェアエンジニア、Thomas Anchor

- デベロッパーアドボケイト、Alicia Williams

Alphaevolve で分子発見を 4 倍に高速化した Schrödinger の事例

Mon, 06 Jul 2026 19:00:00 +0000

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

計算化学の研究者は、従来より、分子間相互作用をシミュレートする際に、精度を犠牲にする高速な古典的力場を使用するか、大規模なジョブでは実行速度が遅すぎる高精度の量子力学的手法に頼るかという、悩ましいトレードオフに直面してきました。

ML 力場（MLFF）は、高忠実度の量子データでニューラルネットワークをトレーニングすることで、そのギャップを埋めます。しかし、現代の創薬や材料設計では、膨大な化学ライブラリを処理するために、さらに高速な処理速度が求められています。このようなパフォーマンスの制約を克服するために、Schrödinger は Google Cloud と提携して AlphaEvolve をデプロイしました。これは Google DeepMind が開発した進化型 AI コーディングエージェントで、アルゴリズムのボトルネックを克服する最も効率的なコードパスを見つけるために、アルゴリズムを繰り返し生成して改良します。

AlphaEvolve とのコラボレーション

30 年以上にわたり科学ソフトウェアの開発をリードしてきた Schrödinger は、MLFF トレーニングパイプライン内でパフォーマンスを制限する重要なアルゴリズムとして、近傍リスト計算法とエバルト総和法の 2 つを特定しました。これらのアルゴリズムは、原子の近傍からのデータを集計して長距離ポテンシャルを計算しますが、どちらもトレーニングと推論の速度において制限要因となっていました。

Schrödinger の技術面での最大の目標は、エネルギーと力の計算のための AI モデルのトレーニングを高速化することでした。具体的には、分子力学で使用される、重要ではあるものの計算負荷の高い機能であるエバルト総和法をターゲットとしました。Schrödinger の PyTorch コードにおいて、エバルト総和法が主なパフォーマンス上の制約となっていました。ベクトル化されたアルゴリズムは確立されておらず、通常は単純な for ループに頼っていたため、大規模なシミュレーションでは処理が遅くなっていました。

AlphaEvolve をモデルに組み込むことで、システムは並列バッチ行列乗算を使用して、エバルト総和法のバッチ実装を生成できるようになりました。これにより、PyTorch コードが進化し、既存のカスタムカーネルを上回るパフォーマンスを実現できました。

評価指標

Schrödinger は、厳格な多層的評価フレームワークを使用して、進化したコードがパフォーマンスと科学的正確性の両方を備えていることを確認しました。

逆時間（主要指標）: 計算時間をベースラインスコア 7.9 から短縮して、スループットを最大化することが主な目標でした。
機能的正確性: 進化したプログラムはすべて、無秩序水モデルなどの複雑なシステムに対する回帰テストを含む、完全なテストスイートに合格する必要がありました。
成功率: 機能的に正確で、ベースラインよりも高速なプログラムの割合で測定しました。

「AlphaEvolve を使用することで、これまでよりも迅速かつ効率的に、より広範な化学空間を探索できるようになりました。MLFF 推論の高速化は、創薬、触媒設計、材料開発における研究開発サイクルを短縮し、企業が分子候補のスクリーニングを数か月ではなく数日で完了できるようにすることで、ビジネスに現実的な効果をもたらします。」- Schrödinger、ML テクニカルリード、Gabriel Marques 氏

結果: 4 倍の高速化とボトルネックの解消

AlphaEvolve を適用することで、Schrödinger はエバルト総和法のコード内の単純な for ループを並列バッチ行列乗算に置き換えました。この最適化により、プログラムの成功率は 1% 未満（5,000 件の評価のうち 40 件）から 60% 以上に向上し、パフォーマンス指標はベースラインの 7.9 から 30 近くまで改善されました。

これらの基本的なアルゴリズムを最適化することで、MLFF のトレーニングと推論の両方で 4 倍の高速化が実現しました。この高速化により、研究者は分子スクリーニングのタイムラインを短縮できます。これは、いくつかの重要な研究分野に直接的なメリットをもたらします。

創薬: 緊急の医療ニーズに対応するため、有望な治療候補を迅速に特定できます。
触媒設計: 産業用途向けに効率的な化学プロセスを開発できます。
材料開発: 電子機器やエネルギー貯蔵向けに、カスタムプロパティを持つ次世代材料を設計できます。

次なる進化

Schrödinger は、この進化的なアプローチをカスタム GPU カーネルに適用し、AI によって生成されたコードが、人間が設計した実装よりも優れているかどうかをテストする予定です。

進化型 AI エージェントが科学的なコードベースを最適化する方法については、AlphaEvolve に関する技術論文の全文をお読みください。また、研究ワークフローの高速化についてご相談されたい場合は、Google Cloud AI チームにお問い合わせください。

- Google、プログラムマネージャー、Kartik Sanu

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

英国の成長企業が AI 時代にどのようにビジネスを構築しているか

Thu, 02 Jul 2026 02:00:00 +0000

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

英国の 500 万を超える中小企業（SMB）は、英国経済の屋台骨です。現在、こうした重要な役割を担う企業は AI の導入を進めており、業務の効率化や迅速化、そして最終的には顧客により良い成果を提供できるようになりつつあります。

この変化は、日々の具体的な成果によってもたらされています。Google とのパートナーシップで Enterprise Nation が発表した最近の調査によると、英国で調査対象となった AI 導入企業の 71% が、AI によってルーチン業務の時間を節約できていると回答し、64% が生産性の直接的な向上を報告しています。さらに、AI 対応の生産性向上ツール（Google Workspace with Gemini など）は、中小企業の生産性を 20% 向上させており、これは実質的に、毎週 1 日分の労働時間を中小企業に還元していることになります。

Google Cloud は、この変化を最前列で見てきました。中小企業は長年にわたって Google Workspace などのプラットフォームを利用しており、現在では Google AI プラットフォームとモデルで変革を遂げています。実際、Google Cloud AI を利用している英国の中小企業の数は、前年比でほぼ 2 倍になっています。これには、Gemini モデルや、Gemini Enterprise、AI Studio などのプロダクトが含まれます。これらは、中小企業が次のようなことを行えるよう支援しています。

より優れたカスタマーサポートシステムを導入し、電話対応のエスカレーションと解決をより迅速に行えるようにする。
給与計算や会計などの分野で、反復的な作業を自動化する。
データアナリストとしての専門教育を受けていない従業員も含め、より多くの従業員が業務でデータを理解し、活用できるようにする。
マーケティング関連資料の新しいデザインを迅速に作成し、導入する。
より多くの人が、日々の業務をサポートする独自の AI エージェントを構築できるよう支援する。
これまでにないスピードと低コストで、複雑な調査プロジェクトを実施する。

今回の Google Cloud ロンドンサミットでは、Google AI ツールを積極的に使用して業務を変革している、革新的な中小企業のお客様を多数ご紹介します。その中には、最近 Google との連携を拡大した企業も含まれます。

サステナビリティフィンテック企業の Neural Alpha は、Gemini モデルを使用して、非構造化の環境レポートや企業のサステナビリティレポートを読み取り、数千もの重要な事実を自動的に抽出および整理しています。これにより、数か月を要していた手動での調査を、ほんのわずかな時間に短縮しました。
デジタルセキュリティプロバイダの Sep 2 は、Gemini Enterprise を使用して、24 時間 365 日体制で脅威をモニタリングする自律型 AI エージェントをデプロイしています。これにより、インシデント検出を迅速化し、顧客に対するセキュリティ脅威を素早く排除しています。
戦略的なブランドデザインエージェンシーである Sunhouse は、Gemini Enterprise を使用して Google ドライブに保存されたアーカイブ済みのデザイン制作物を簡単に見つけられるようにしています。これにより、チームはファイル検索に費やす時間を減らし、グローバルブランドとのビジネスを成長させるためにより多くの時間を使えるようになっています。
グローバルな B2B イベント企業である Terrapinn は、Gemini モデル、NotebookLM、Looker、BigQuery を活用して手作業を自動化されたワークフローに置き換え、世界クラスのカンファレンスの企画、マーケティング、開催までのスピードを加速させることで、業務を変革しています。
通信プロバイダの VoCoVo は、Google Cloud AI をシステム全体に統合して、孤立したデータを活用可能なインテリジェンスに変え、自律的なワークフローを構築しています。これにより、ルーチン業務を効率化し、チームがインパクトの大きいイノベーションに集中できるようにしています。

チームの強化: 英国企業の成長を支援する AI スキル向上リソース

中小規模のチームがインパクトを最大化し、最新の AI 環境を自信を持って活用できるよう、Google は専用の無料スキル向上リソースを用意しました。既存のチームをトレーニングする場合でも、全従業員がデータツールを利用できるようにする場合でも、これらのプログラムは AI 活用に向けた組織づくりに役立ちます。

中小企業向けプログラム: 新しい中小企業向け学習プログラムをチェックするか、Gemini Enterprise Agent Ready（GEAR）プログラムに登録して、エージェント型 AI の専門的なトレーニングを受けることができます。
組織向け Google Skills: Google Cloud と Google DeepMind のエキスパートが作成した 3,000 以上の AI コースとハンズオンラボを備えた、無料のオンデマンドラーニングプラットフォームを利用できます。
Get Certified Program: チームの専門知識を実証する準備ができたら、このプレミアムなコホートベースのプログラムを活用しましょう。ここではクラスルームトレーニング、技術メンターシップ、AI を取り入れたスキルバッジが提供されており、業界で認められた認定資格の取得に向けてチームが準備できるよう設計されています。

Google は、Workspace の生産性向上ツールから、すべての広告サービス、そして強力な AI ツールまで、中小企業向けのテクノロジーとトレーニングのフルパッケージを提供することで、中小企業が将来どのような状況になっても成長し続けられるよう支援しています。

- 英国、アイルランド、サハラ以南のアフリカ担当バイスプレジデント、Maureen Costello

検証可能なプライベート AI: Google Cloud が Confidential Computing の新たな領域を切り開く

Wed, 01 Jul 2026 02:00:00 +0000

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

AI で使用される機密データの保護は、Google の先進的でセキュアなクラウドインフラストラクチャを提供するという取り組みにおいて極めて重要です。Confidential Computing は、ハードウェアベースの高信頼実行環境（TEE）で、使用中のデータを暗号で保護しながら、データの完全性を検証可能にします。

このたび、Cloud AI のデプロイにおける検証可能なプライバシーをさらに強化する、ハードウェアエコシステム全体にわたる最新の Confidential Computing のイノベーションを発表いたしました。

グローバル規模での Confidential AI

Confidential AI の機能をグローバルに拡大することで、AI の推論やファインチューニングのワークロードが、強制力のあるプライバシー保証のもとで実行されるようにします。

Confidential AI の民主化: NVIDIA RTX PRO 6000 Blackwell GPU を搭載した Confidential G4 VM のプレビュー版の提供開始

このたび、グローバル規模でアクセス可能な Confidential AI を発表できることを嬉しく思います。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載したアクセラレータ最適化 G4 マシンシリーズにおいて、Confidential VMs と Confidential GKE ノードが利用可能になりました。

これが革新的なのは、そのグローバルな規模と柔軟性にあります。Confidential G4 は、標準の G4 が利用可能なすべての Google Cloud リージョンで提供されており、オンデマンド、予約、DWS Flex Start、Spot / プリエンプティブルなど、複数の使用量モデルに対応しています。

「組織が複数のインフラストラクチャ環境にわたって AI をスケールするにつれ、データや実行環境に対するプライバシーと制御の維持がますます難しくなっています。NVIDIA RTX PRO 6000 Blackwell GPU を搭載した Google Cloud Confidential G4 VM は、拡大を続ける Confidential AI のインフラストラクチャエコシステムにとって重要な追加要素といえるでしょう。AI ワークフローは現在、エージェント、データソース、インフラストラクチャの境界を越えて広がっています。Super Protocol は、Google Cloud Confidential VM、他社のクラウド、オンプレミス環境にわたり一貫した Confidential AI 運用モデルを提供することで、Confidential Computing の複雑さを抽象化し、チームが AI による成果の創出に集中できるようにしています」と、Super Protocol の COO である Yulia Gontar 氏は述べています。

AMD SEV を活用した第 5 世代 AMD EPYC Turin CPU と NVIDIA RTX PRO 6000 Blackwell GPU を搭載する G4 マシンシリーズは、堅牢なハードウェアベースのセキュリティを実現します。このアーキテクチャにより、TEE 内での処理中に機密データが確実に保護されるだけでなく、CPU と GPU 間のデータ転送時にもデータが暗号化されます。

「Vertebrae が、GCP の Confidential G4 VM を選択したのは当然のことでした。当社のお客様にとってプライバシーとセキュリティは譲れない条件だからです。当社のプロダクトは業務上の機密性の高い議論を処理するため、CPU と GPU の両方が TEE 内で動作していることを示す、ハードウェア署名による証明をサポートする必要があります。Google Cloud の Confidential Computing を使用することで、クラウドにおける最先端の AI のプライバシーを実現しています」と、Vertebrae の CEO である Andy Qin 氏は述べています。

Confidential G4 を使用することで、パフォーマンスへの影響を最小限に抑えながら、AI 推論、ファインチューニング、HPC を実行できるほか、厳しく制限されたデータ、機密性の高いモデル、プライベートプロンプトを扱うユースケースにも対応できます。Confidential G4 VMs と Confidential G4 GKE Nodes の利用を今すぐ開始しましょう。

エンドツーエンドのプライベート推論を実現: オープンソースの Prompt Encryption SDK

Confidential AI の利用を促進する一方で、AI ワークロードにおける機密データの保護は、モデルの実行環境を保護するだけでは不十分であることも理解しています。プロンプトやレスポンスそのものに、機密性の高い情報が含まれている可能性があるからです。推論のライフサイクル全体を暗号で保護するために、Google は Prompt Encryption SDK のオープンソース版をリリースしました。現在、GitHub で公開されています。

このツールキットにより、AI 推論ワークロードのエンドツーエンドのセキュアなチャネルを確立することができます。プロンプトがクライアントから送信された瞬間から TEE で処理されるまで暗号によって保護され、モデルのレスポンスも同様に、クライアントに戻るまで保護されます。

Prompt Encryption SDK を使用したプロンプトとレスポンスの暗号化。

クライアント SDK はクライアントアプリケーションに組み込まれ、TEE で実行される推論サーバーに組み込まれたサーバー SDK と連携して動作します。SDK を使用して証明済みの TLS セッションが確立されると、クライアントは、サーバーが検証済みの Confidential Computing 環境内で認証されたワークロードを実行していることを確認できます。

これにより、クライアントアプリは、TEE でプロンプトを復号して処理できるのはこのサーバーのみであることを前提として、暗号化されたプロンプトを推論サーバーに送信できます。サーバーはレスポンスの準備ができると、暗号化された同じチャネルを介してクライアントアプリにレスポンスを返します。

GitHub リポジトリと Codelab の利用を今すぐ開始しましょう。

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

Google のプライバシーへの取り組みは、Google Cloud での Private Cloud Compute（PCC）の拡張に向けた Apple とのコラボレーションに深く表れています。

このたびの Apple とのコラボレーションにより、Apple のプライバシーとセキュリティへの取り組みを Google Cloud 上の PCC に拡張できることを大変誇りに思います。PCC における Apple のプライバシーへの取り組みは、Google Cloud のインフラストラクチャ上に構築されている多層的なセキュリティアプローチによってサポートされます。これには、Intel TDX を使用した Google Cloud Confidential Computing、NVIDIA Blackwell GPU を使用した NVIDIA Confidential Computing、Titan チップを使用した Titanium セキュリティアーキテクチャ、検証可能な透明性を確保するための共同設計されたオープンソースのホストスタックの活用が含まれます。

これらのテクノロジーを組み合わせることで、Google Cloud 上の Apple PCC で、データ保護とユーザーのプライバシーに関する厳格な要件を満たすことができます。このコラボレーションについて詳しくは、ブログ投稿「次世代の Confidential AI を推進」をご覧ください。

機密性の高い基盤の進化

Google Cloud は、インフラストラクチャ全体で Confidential Computing 機能を広く利用できるようにすることに取り組んでいます。Google の目標は、ハードウェアベースのセキュリティ機能を基本的なコンピューティングサービスに深く統合し、お客様がパフォーマンスや運用の柔軟性を損なうことなくデータ保護を強化できるようにすることです。

C4 マシンシリーズにインテルトラストドメインエクステンションズ（TDX）を導入

C4 マシンシリーズのインテル TDX を搭載した Confidential VMs は、まもなくプレビュー版が提供される予定です。

最新の第 6 世代 Intel Xeon プロセッサを搭載したこのインテグレーションにより、データ量の多いワークロードでのコンピューティング密度とパフォーマンスが大幅に向上します。インテル TDX を使用することで、C4 インスタンスはハードウェア的に分離された信頼ドメイン（TD）を作成し、基盤となるホストやハイパーバイザから機密性の高いアプリケーションやデータを保護します。

このアーキテクチャは、機密性とプライバシーを確保すると同時に、リモート認証も可能にするため、機密データを処理する前に環境が安全であることを暗号で検証できます。しかも、コードを変更することなく、数回クリックするだけで Confidential Computing を有効にできます。

ライブマイグレーション機能の拡張

ミッションクリティカルな本番環境の運用には、クラウドの定期メンテナンス中であっても、高可用性と継続的な稼働時間の確保が求められます。

C3D ベースの Confidential VMs におけるライブマイグレーションの一般提供が開始されています。この機能により、Google Cloud はワークロードを中断したり、暗号化されたゲストメモリを公開させたりすることなく、計画的なハードウェアメンテナンスを行うことができ、長時間実行される機密アプリケーションのシームレスな稼働時間を確保できます。

信頼とコラボレーションの強化: Confidential Space のイノベーション

Confidential Space は、セキュアなマルチパーティコンピューティングとデータ共有を実現するために設計された Confidential Computing 環境です。これにより、組織は共同での ML やデータ分析といった機密データを扱ったコラボレーションを、互いの組織や Google Cloud にデータを明かすことなく行えるようになります。

「Google Cloud Confidential Space を使用することで、オンプレミスサービスと同等、あるいはそれ以上のセキュリティ保証を金融機関に提供できるようになりました」と、Symphony のプラットフォームおよびサイト信頼性エンジニアリング担当バイスプレジデントである Olivier Richaud 氏は述べています。「Confidential Computing を活用できなければ、セキュリティとプライバシーへの配慮が特に必要なお客様を、クラウドベースの SaaS サービスに移行させることは不可能だったでしょう。」

Confidential Space の重要な設計原則の 1 つは、ワークロードオペレーターを信頼境界から排除し、認証された証明済みのワークロードのみがデータにアクセスできることを暗号によって保証することです。

「金融サービスにおいて、AI システムが消費者に代わって行動することが増える中、データの処理方法に対する信頼が極めて重要になっています。Sahamati では、Google Cloud Confidential Space を、インドのオープンファイナンスエコシステムでプライバシーを保護する AI を実現するための基盤技術と位置付けています。これにより、強固なセキュリティと説明責任を維持しながら、イノベーションに必要な信頼を築くことができます」と、Sahamati の最高イノベーション責任者兼 Sahamati Labs の責任者である Kiran Gopinath 氏は述べています。

Confidential Space の新たな機能強化により、柔軟性が向上し、保証がさらに強化されています。主な更新内容は次のとおりです。

独立した検証: インテル Trust Authority とのインテグレーション

このたび、Confidential Space 向けの独立した証明書検証サービスとして、インテル Trust Authority（ITA）の一般提供が開始されたことをお知らせします。

このインテグレーションにより、組織は、暗号鍵がワークロードにリリースされる前に、インテルのハードウェアルート証明書を使用して Confidential Space 環境の完全性を独立して検証できます。証明書の検証をクラウドサービスプロバイダから切り離すことで、お客様は透明性の向上、保証の強化、より堅牢な信頼モデルの恩恵を得ることができます。

「Google Cloud とインテルは、Confidential Computing をコアインフラストラクチャに組み込むことで、ハードウェアルートのセキュリティと独立した証明書を、現代のコンピューティングにおける標準機能の一部にしています。本番環境ワークロードを実行するインテル TDX 搭載の C4 Confidential VMs から、検証可能なマルチパーティコラボレーションを可能にするインテル Trust Authority を備えた Confidential Space（一般提供中）まで、お客様は極めて厳格な規制環境下でも、アプリケーションの書き換えやパフォーマンスの低下を招くことなく、最も機密性の高い AI およびデータワークフローを暗号化、検証、スケールできるようになりました」と、Intel Corporation の Intel Product Assurance and Security（IPAS）担当ゼネラルマネージャー兼バイスプレジデントである Anand Pashupathy 氏は述べています。

セキュアなコラボレーションの加速: Confidential Space の H100 GPU のサポート

セキュアなマルチパーティの AI と ML を強化するため、Confidential Space での NVIDIA Hopper GPU のサポートが一般提供されるようになりました。これにより、複数のパーティが Confidential Space 環境内で Hopper GPU を活用し、データをプールしてトレーニングや推論を行うことができます。その際、各パーティのデータは、他の参加者や Google Cloud から確実に保護されます。

Confidential Space を使用すると、機密性の高いデータセットでのフェデレーションラーニングや、データを一元化せずに共同でモデルを構築するなどのユースケースが可能になります。

「Google Cloud Confidential Space での Confidential GPU のサポートは、セキュアな AI を導入する上での最大の障壁の 1 つ、機密性の高いワークロードの保護と本番環境レベルのパフォーマンスの実現というトレードオフを解消します」と、Duality のプロダクト担当バイスプレジデントである Adi Hirschtein 氏は述べています。「これにより、ヘルスケア、金融サービス、行政機関における Duality のお客様は、機密データ上でフェデレーションラーニング、機密 AI、暗号化された RAG ワークフローを大規模に実行しながら、処理全体を通じてデータとモデルを保護することが可能になります。」

次のステップ

AI 時代において、Confidential Computing はクラウドコンピューティングに不可欠な要素となりつつあります。拡大を続ける Google の Confidential VM、アクセラレーションハードウェア、オープンソースツールのポートフォリオをご覧いただき、組織内でセキュアなコラボレーションとプライベート AI のイノベーションを実現する方法をご確認ください。

詳細については、2026 年 6 月 23 日および 24 日に開催される Confidential Computing Summit にぜひご参加ください。

- Google Cloud、Confidential Computing 担当プロダクトリード、Sam Lugani

-Google、Confidential Computing 担当エンジニアリングリード、Ranjit Narjala

AI の可能性からエージェント型の現実へ: 英国の新たな章を切り拓く

Wed, 01 Jul 2026 01:00:00 +0000

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

英国、特にロンドンは、ヨーロッパおよび世界における AI 開発の主要な拠点の一つであり続けています。もちろん、Google DeepMind の本拠地でもあり、Ineffable Intelligence のような重要な AI ユニコーン企業（Google Cloud のお客様）も存在します。Ineffable Intelligence は本日、Google との重要なパートナーシップを発表しました。

1 年前、Google はロンドンサミットに参加し、英国の公務員のスキルアップへの大規模な投資など、生成 AI の大きな可能性を紹介しました。本日、パートナー様を再び歴史ある Tobacco Dock の空間にお迎えするにあたり、その可能性は産業規模の現実となっています。ホワイトホール（政府機関）とシティ（金融街）のリーダーたちとの対話を通じて、焦点がチャットボットやメディアでの実験的な試みから、実運用を伴う本格的な実行へと移っていることを実感しています。今はエージェント型企業の時代です。単に会話するだけのシステムから、自ら推論し、計画を立て、複雑なワークフローを実行できるシステムへと進化を遂げようとしています。

この移行は、2030 年までに AI が英国経済にもたらすと予測される 4,000 億ポンドの経済効果の礎となるものです。Google Cloud は、エージェント型企業を現実のものにするために必要な完全統合スタック（カスタムシリコン、最先端モデル、グローバル規模のインフラストラクチャ）を提供する唯一のプロバイダです。

英国の企業と研究の新たなフロンティア

銀行業界は、この変化を実証する重要な場です。そして、世界最大級かつ極めて重要な金融機関の一つである HSBC は、その先駆者として道を示しています。このたび、Google は HSBC との複数年にわたる変革的なパートナーシップを発表し、HSBC のプロダクトとサービス全体で AI の導入をグローバルに加速させることになりました。この新たなコラボレーションにより、HSBC のグローバルな業務全体で AI を活用した働き方への移行がさらに加速します。

HSBC は、Google Cloud および Google DeepMind のエンジニアリングチームと連携して、新しい AI 搭載ツールとプログラムを共同開発します。これには、Gemini モデルや Gemini Enterprise Agent Platform などの Google の最新のエージェント型 AI 機能へのアクセスが含まれます。初期の展開では、3 つの分野に重点を置きます。具体的には、高度にパーソナライズされた資産管理サポート、金融犯罪リスク管理の強化、そして現場の担当者やリレーションシップマネージャーの顧客サービスを向上させる AI ツールです。

英国のスタートアップは、Ineffable Intelligence のような最先端の研究所の取り組みに示されているように、テクノロジー、特に AI で新たな境地を開拓し続けています。今年初めに設立された同社は、Google Cloud を優先クラウドパートナーとして選び、Google の AI 最適化ハードウェアとツールのフルスタックを活用して、Ineffable の第 1 世代の基盤モデルを構築、トレーニングしています。

AlphaGo プロジェクトで重要な役割を果たした元 Google DeepMind 研究者の David Silver 氏が率いる Ineffable Intelligence は、AI 開発に独自のアプローチを採用しています。このチームは、言語モデルの背後にあるような、人間が生成した大規模なデータセットに依存するのではなく、主に強化学習を通じて独自の経験から学習するシステムを構築しています。その野望は、試行錯誤を通じて知識を深める「スーパーラーナー」を作り出すというものです。今年、Ineffable Intelligence はヨーロッパのシードファンディングラウンドで 11 億ドルの記録を樹立しました。現在、同社は Google Cloud 上の NVIDIA Vera Rubin NVL72 プラットフォームを搭載した A5X の最大規模のクラスタの一つをデプロイすることで、トレーニング作業をサポートし、大規模なコンピューティングスケールを実現しています。

試験運用から本格的な実運用へと移行するには、企業はモデルを導入するだけでなく、明確なロードマップを必要としています。その道筋を示すため、Google は Deloitte とのパートナーシップを強化します。これに伴い、Deloitte はロンドンのキャンパスに新たな AI Studio を開設する予定です。Google Cloud とのコラボレーションで開発されたこのスタジオは、英国の組織が AI の試験運用から一歩進んで、自律的で行動指向の AI システムを大規模にデプロイできるよう支援します。

また、Deloitte は英国の AI およびデータ担当の従業員 1,000 人を対象に、Gemini Enterprise に関するスキルアップを支援することも表明しています。この認定プログラムにより、デロイトの AI およびデータエンジニアが Google の最先端のエージェントアーキテクチャを実装するための技術的専門知識を身につけ、英国のお客様に地域最大規模の認定 AI 人材プールを提供できるようになります。

将来を見据えた公共部門の構築

現代的なデジタル政府の青写真を実現するには、硬直化したレガシーな契約から脱却し、アジャイルで AI 主導の公共サービスへと転換することが求められます。住宅・コミュニティ・地方自治省（MHCLG）、i.AI インキュベーター、Google Deepmind、および Faculty との連携により、英国の「建設を促進する」という国家目標を直接的に支援する、実効性のある公共部門の改革と刷新のためのツールを実現しています。

MHCLG などの行政機関は、Google のテクノロジーを使用して構築された Extract というツールをすでに導入しています。このツールは、文書処理時間を 2 時間からわずか 2 分に短縮することで、計画策定プロセスの変革を推進しています。同時に Google は、バーネット、ドーセット、カムデンの各自治体と共同開発した AI 都市計画ツールの試験運用を支援しています。このツールは、一般的な申請における意思決定時間を 50% 短縮することを目指しています。さらに、英国運輸省（DfT）は、Gemini を活用してパブリックコンサルテーションの分析を効率化しており、年間 400 万ポンドの節約が見込まれています。

この規模のイノベーションには、安全で主権が確保された基盤も必要です。そのため、Google Cloud は英国におけるデータ所在地に関する取り組みを強化しており、その一環として、国内での AI 処理を特徴とする Gemini 3.5 Flash を、2026 年 6 月末までに機密性の高い主権ユースケース向けに提供する予定です。また、英国の組織が厳格なコンプライアンスの境界内でイノベーションを起こせるよう支援しています。

AI やその他のデジタル脅威を利用する悪意のあるアクターがもたらす課題からビジネスを保護するために、Google は最近、包括的な AI 搭載サイバーセキュリティプラットフォームである Google AI Threat Defense を発表しました。このプラットフォームは、Wiz、Mandiant、Gemini、CodeMender を組み合わせて、お客様の脆弱性を発見および修正し、安全を確保します。

小売業界から公共サービスまで、実証されたインパクト

自律型エージェントはもはや将来の予測ではなく、すでに英国経済全体に価値をもたらしています。e コマースソリューションプロバイダである THG Ingenuityとの取り組みでは、AI ショッピングアシスタントを通じてコンバージョン率が 8 倍に向上しました。同様に、Starling は、「支出インテリジェンス」ツールを提供することで、お客様が購入や支出の傾向を即座に分析できるようにしています。また、Rightmove は、Google の Gemini モデルを基盤とした AI 搭載の会話型物件検索ベータ版をリリースし、ユーザーが自分の言葉で物件を検索できるようにしました。

このインパクトの広さはあらゆる分野で確認できます。Kingfisher は小売業に特化したエージェント型アプリケーションを先駆けて開発し、Openreach は通信業界でフィールドサービスの最適化を推進しています。また、Unilever はバリューチェーン全体で AI を大規模に活用し、成長を促進して新時代の消費財において魅力的なブランドを構築しています。

一方、VMO2 は複雑なデータオペレーションを合理化し、Vodafone はネットワークパフォーマンスを再定義する 10 億ドルのパートナーシップを推進しています。また、WPP は、高品質なキャンペーンアセットの迅速かつ大規模な生成、AI エージェントの駆動、ロボットカメラオペレーターのトレーニングなど、クリエイティブワークフロー全体に Gemini を統合しています。

中小企業とスタートアップの成長エンジンを強化

英国の AI の成功の真価は、中小企業とスタートアップのエコシステムにあります。Google の AI Works 調査では、重要な転換点が浮き彫りになっています。AI は、中小企業の生産性を 20% 向上させ、英国経済に 1,980 億ポンドの生産額を創出する可能性を秘めています。小規模企業の 56% がすでに支援を求めていることを受け、Google は、どの企業も取り残されないように、AI Works for Britain スキル向上の取り組みを開始しました。

また、ロンドン AI ハブでは、Tech Nation との継続的なパートナーシップを通じて、次世代の英国ユニコーン企業の育成にも取り組んでいます。この継続的なコミットメントにより、創業者には事業拡大に必要なリソースとコミュニティが提供されます。今年 9 月には、ロンドンで Gemini Startup Forum: Cybersecurity を開催し、スタートアップが設計段階からセキュリティを考慮した AI アプリケーションを構築できるよう支援することで、このミッションをさらに推進します。

Platform 37 の Model Garden

英国の可能性に対する Google の信念は、物理的な拠点にも反映されています。Google は、増大する需要に対応するため、英国のデジタルインフラストラクチャへの投資を継続しています。2025 年 9 月にはウォルサムクロスに最先端のデータセンターを開設しました。これは、英国の AI 経済を活性化するために 2 年間で 50 億ポンドを投資する計画の重要な一環です。また、今年初めには、ロンドンのキングスクロスに新しいオフィス Platform 37 を開設しました。あわせて、AI の理解を深めるための新しい公共スペース「The AI Exchange」の計画も発表しています。

この勢いを活かし、2026 年第 4 四半期には Platform 37 の Model Garden を開設できることを嬉しく思います。ロンドンを拠点とするこのハブは、単なる物理的なスペースではありません。Google の最も重要なお客様との関わり方を根本的に向上させることを目的とした戦略的投資です。時代を超越した英国庭園の美学と、リビングデジタルウォールや 3 階建てのアトリウムなどの没入型ハイテクイノベーションを融合させた Model Garden は、Google の最高のアイデアを物理的に体験できる場所です。

エージェント型企業の青写真

英国の企業、行政リーダー、各種組織が AI の潮流をリードし続けるためには、活用するテクノロジーだけでなく、仕事の進め方の根本的なあり方も再考する必要があります。国内外の数千の組織と数百万のチームをサポートする中で、Google は AI で成功を収めるための 3 つのコア戦略を見出しました。

文化: 将来を見据えて組織を再構築する必要があります。真の変革とは、チームが AI エージェントとまったく新しい方法で協働できるよう、チームの意欲を高め、実行できる体制を整え、必要な環境を完備することです。これは単なる自動化ではなく、人と AI の協働を目指すものです。
責任: 設計段階から安全性とセキュリティを念頭に置いて構築する必要があります。ユーザー、顧客、ブランドの保護は最優先事項です。Google のフロンティアモデルは、厳格な AI 原則と、設計段階からセキュリティを考慮したインフラストラクチャを基盤として構築されています。
サステナビリティ: コンピューティング需要が高まる時代において、経済的に持続可能であり、かつ地球環境に貢献する方法で規模を拡大させる必要があります。Google は、24 時間 365 日カーボンフリーエネルギーを利用することに取り組んでおり、英国の AI の成長が気候変動目標の犠牲にならないよう確実なものにしています。

共に未来を築く

Google Cloud は、英国のエージェント型への移行における主要なパートナーです。私たちは、試験的な試みによる期待先行の段階を脱し、実運用における厳格なフェーズへと足を踏み入れています。キングスクロスの研究室から、小売業界を支える多様な企業まで、私たちは英国のレジリエントで、主権が確保された、繁栄ある未来を設計しています。

昨日、今日、そして未来に向けて、ロンドンで活動を共にしてくださる皆様に感謝申し上げます。今年は、特別なオンデマンドエクスペリエンスをご用意しました。ロンドンサミットの決定的な瞬間を、いつでもどこでもストリーミングで視聴いただけます。

- 英国、アイルランド、サハラ以南のアフリカ担当バイスプレジデント、Maureen Costello

Sakana AI: Gemini Enterprise Agent Platform をサービス基盤に全面採用し、日本発の斬新なマルチエージェントサービスを実装

Mon, 29 Jun 2026 01:00:00 +0000

目覚ましい技術進化が続く生成 AI。その分野において異彩を放っているのが、日本発のスタートアップ、Sakana AI株式会社（以下、Sakana AI）です。同社は巨大な単一モデルに頼らず、複数の AI モデルを協調させて「集合知」を引き出すという独自のアプローチで、斬新な生成 AI の研究開発を推進。2026 年 6 月には、Google Cloud を運用基盤に据えたマルチエージェントオーケストレーションシステム、「Sakana Fugu」をローンチしています。今回はプロジェクトの中心となった 3 名のサイエンティストに、開発の舞台裏を聞きました。

利用しているサービス:
Gemini, Gemini Enterprise Agent Platform, Cloud Run, Cloud SQL, Memorystore for Redis, BigQuery, Cloud Armor, Cloud Load Balancing, Identity Platform, Cloud Scheduler, Cloud Logging

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

日本のスタートアップが実現した、新世代のマルチエージェント AI モデル

現在の生成 AI 技術は、LLM（大規模言語モデル）の容量を拡大する方向で世界中で開発が続いています。そのような中、Sakana AI は社名の由来でもある「小さな魚が集まって 1 匹の大きな魚のように振る舞う生態」や、進化の原理にインスピレーションを受け、複数の AI モデルを動的に組み合わせる独自の研究を推進。2026 年 4 月には、「Sakana Fugu」のコアテクノロジーとなる AI モデルを発表しています。プロジェクトを率いたチーフサイエンティストの Yujin Tang 氏は、開発の背景をこう振り返ります。

「私たちは Google、OpenAI、Anthropic といった主要な企業が提供する AI モデルと同等、またはそれを上回る性能を持つ基盤モデルを開発することを目指してきました。しかし、自分たちですべての基礎研究をゼロから行うのは、現実的でも効率的でもありません。そこで Sakana AI では、オープンソースやクローズドソースの API サービスとして提供されているモデルを協調させ、タスクをより効率的に処理できる『Sakana Fugu』を開発しました。原点となったのは、2025 年 1 月に『Nature Machine Intelligence』誌に論文として寄稿した、『進化的モデルマージ（基盤モデル群の融合・活用）』^（※1）という手法です。」

このようなモデル開発は、市場の潜在的なニーズに応え、新たな事業の展開を可能にするものでもありました。

「現在の LLM は、あるモデルはコーディングに強く、別のモデルは経済分野に強いというように、得意分野が分かれています。そのためユーザーは用途に応じて AI を使い分けなければならず、非効率な作業を強いられていました。しかし『Sakana Fugu』を利用すれば、ユーザーは単一のエンドポイントを呼び出すだけで、背後にある多様な AI にアクセスして最適な回答を得られます。このシステムをサブスクリプションモデルとして提供することは、世界中の AI 研究者やエンジニア、企業、ビジネスパーソンなどのニーズに応えつつ、新たなビジネスを展開するという意義も持っていました。」（Tang 氏）

「集合知」を活用できるプラットフォームを、Gemini Enterprise Agent Platform で構築

「Sakana Fugu」の特徴は、単に既存の AI を決まったパターンで組み合わせるのではなく、クエリの複雑さに応じて最適なモデルと処理を選択する「オーケストレーション」機能にあります。学習を担当した Stefan Nielsen 氏は、その動作原理を次のように説明します。

「『Sakana Fugu』はスポーツに例えるなら、さまざまな選手（AI モデル）やフォーメーション（組み合わせ）、戦術（タスク処理）を対戦相手（クエリ）に応じて使い分けるコーチのような存在です。つまり『AI のチームを指揮する AI』として『集合知』にアクセスし、個々のモデルを上回るパフォーマンスを発揮できるシステムになっています。実現にあたっては、モデルの選択を最適化する『進化戦略』と、モデルの連携方法を学習する『強化学習』を実施しました。いずれも 2026 年の国際学会 ICLR で発表した研究成果です^（※2）。また、学習過程でモデルが自分自身を呼び出す手法を組み込み、『推論時スケーリング』も可能にしています。」

専用設計のアーキテクチャも奏功し、「Sakana Fugu」ではモデル間の遷移を感じさせないほどシームレスな利用環境が確保されています。

「今回のサービスローンチでは、私たちは推論速度を重視した『Fugu』と、高いパフォーマンスを発揮する『Fugu Ultra』という 2 つのバリエーションを用意しました。これらのシステムではコーディングや対話能力などに卓越した Gemini も、動的に呼び出すフロンティアモデルの 1 つとして中核に組み込まれています。」（Nielsen 氏）

「オーケストレーション」を通じて、個々のモデルを上回る結果を引き出す。この難しい要件を実現するために選ばれたのが、Google Cloud です。もともと Sakana AI は Google や Google DeepMind 出身のエンジニアを中心に設立されたため、Google Cloud が採用されたのは自然な流れでした。しかし、インフラ設計を担当した Qi Sun 氏は、運用プラットフォームとしての適性の高さを再認識したと強調します。

「インフラ構築における最優先事項は、常に高品質なレスポンスを時間通りに返せる安定性の確保です。一方で、可能な限り多くの処理ができる、非常に高いスループットも重視していました。Google Cloud は、これらの要件をしっかり満たしています。さらに述べれば、『Sakana Fugu』では、Gemini をはじめとする各モデルを同一基盤上でフレキシブルに統合・連携できることが不可欠となります。この点、Gemini Enterprise Agent Platform は GPU をホスティングしつつ、マネージドサービスで管理や運用の負荷も軽減してくれるので最適でした。」

Sun 氏は、サービス構築に必要な各種ツールが十全に揃っていたことも、採用理由に挙げています。

「『Sakana Fugu』は、フロントエンド層、中間処理層、モデル層という 3 つのレイヤーで構成されています。フロントエンドでは Cloud Armor や Model Armor で不適切な入力や DDoS 攻撃からモデルを保護し、ランタイムセキュリティを確保。Firebase によるユーザーの認証と保護、API キーの管理などを実施しています。中間処理層は、基盤モデルの呼び出しやログとキャッシュの処理、BigQuery へのデータ書き込みなどを担当。そしてシステムのコアにあたるモデル層が、クエリに応じて最適な処理を行います。Cloud Run と Gemini Enterprise Agent Platform は、自動でロードバランシングとスケーリングをする機能も備えており、どのようなリクエストが来てもすぐに対応できます。」

Google Cloud のサポートを受け、わずか半年でサービスローンチに成功

2025 年 10 月に始動した開発プロジェクトは、2026 年 4 月に完了。6 か月という短期間で実装にこぎつけています。Tang 氏によれば、それを支えたのが Google Cloud によるサポートでした。

「彼らとは毎週のようにミーティングを行うだけでなく、専用のチャットスペースでも密にコミュニケーションをとっていました。質問に応じて、各専門分野に最も詳しいエキスパートを連れてきてもらったり、事前に理想的なユースケースやベストプラクティスを示してもらえたりしたのも助かりました。通常のように、ドキュメントを頼りにソリューションを探していたなら、開発は数週間から数か月単位で遅れていたと思います。」

サポートは GPU ワークロードにおける Cloud Run、Gemini Enterprise Agent Platform、Google Kubernetes Engine（GKE）の使い分けといった設計判断から、スケーラビリティの確保、権限管理の効率化といった詳細にも及びました。

「Google Cloud の担当チームは、Firestore のスケーリング制限や Cloud Logging のデータ制限といった、本番の運用で直面する課題をうまく回避する方法も一緒に考えてくれました。私たちも Terraform を導入し、運用の再現性と整合性を担保しつつ、IAM 権限を含む環境を、すべてコードで管理できる体制を整えました。」（Tang 氏）

こうして開発された「Sakana Fugu」は、社内の研究者やエンジニアが、リサーチ、コード作成、アイデアの創出などの幅広い業務で活用。すでに高い評価を得ています。

「定量的な成果としては、代表的な 6〜7 種類のベンチマークで、主要な AI モデルを上回る SOTA（最高水準）のスコアを記録したことも挙げられます。Google Cloud のダッシュボードを活用して、システムを精緻にモニタリングしたことも改善につながりました。細部を見直した結果、キャッシュヒット率は 5％向上しています。」（Tang 氏）

約 2 か月に及ぶ PoC（概念実証）を経て、Sakana AI は 2026 年 6 月に有料の AI 開発プラットフォームである「Sakana Fugu」の提供を開始。このサービス実装は、グローバルなレベルでもすでに大きな注目を集めつつあります。最後に Tang 氏は、開発プロジェクトを総括しつつ、今後への展望を語ってくれました。

「今回のプロジェクトでは、やはり Gemini Enterprise Agent Platform が非常に役立ちました。BigQuery からデータを取得し、Model Garden を柔軟に活用するフローを、エンタープライズクラスの安定した環境で構築できるからです。『Sakana Fugu』は、Sakana AI のさまざまな製品を支えるコアテクノロジーとなっていく予定です。生成 AI の可能性を探りながら、社会の幅広い分野に貢献していくためにも、今後も Google Cloud と連携しながら、独自の技術開発を続けていきたいと考えています。」

^{※1 Akiba, Shing, Tang, Sun, Ha. Evolutionary optimization of model merging recipes. Nature Machine Intelligence 2025. https://doi.org/10.1038/s42256-024-00975-8}

^{※2 Xu, Sun, Schwendeman, Nielsen, Cetin, Tang. TRINITY: An Evolved LLM Coordinator. ICLR 2026. https://arxiv.org/abs/2512.04695. Nielsen, Cetin, Schwendeman, Sun, Xu, Tang. Learning to Orchestrate Agents in Natural Language with the Conductor. ICLR 2026. https://arxiv.org/abs/2512.04388}

Sakana AI株式会社
世界トップクラスの AI 研究者が集まり、2023 年 7 月に日本で設立。自然界の生物や進化の仕組みに着想を得た「進化的モデルマージ」を提唱。巨大な単一モデルに頼らない、効率的かつ省エネルギーな AI システムの研究・開発に強みを持つ。その独創的な理論とテクノロジーは注目を集め、世界の名だたる企業から出資を受ける。創業 1 年足らず、日本最速でユニコーン企業となった。

インタビュイー（写真左から）
・チーフサイエンティスト　Yujin Tang（ユージンタン）氏
・リサーチサイエンティスト　Qi Sun（チーサン）氏
・リサーチサイエンティスト　Stefan Nielsen（ステファンニールセン）氏

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

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ń

豊田自動織機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 0x7f617ad7f070>)])]>

各コンセプトドキュメントには、構造化されたフィールド用の 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 0x7f617ad7f370>)])]>

コンセプトは通常の 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

レポート: 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 0x7f617a3fcb20>)])]>

ユースケース 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 0x7f617a3fc490>)])]>

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 氏

Managed Service for Apache Spark クラスタの新機能

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

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

Google Cloud は、お客様が大規模な分析ワークロードやデータサイエンスワークロードを最大限の効率で実行できるようにすることを目指しています。これにより、大規模なデータパイプライン、ML、ETL のタスクを処理できます。

最近、Dataproc サービスが Managed Service for Apache Spark に変更されたことを発表いたしました。これは、Agentic Data Cloud との緊密なインテグレーションを反映したものです。

現代のデータチームのアーキテクチャに対する多様なニーズに対応するため、このサービスはサーバーレスとマネージドクラスタの 2 つの異なるデプロイモードで提供されます。サーバーレスデプロイモードでは、エフェメラルなジョブやアドホックジョブ向けにインフラストラクチャ管理が完全に抽象化されます。一方、マネージドクラスタデプロイモードは、インフラストラクチャのきめ細かいカスタマイズ、永続的な環境、長時間実行されるステートフル処理、またはカスタムの Compute Engine ハードウェア構成とのネイティブなインテグレーションを必要とするチーム向けに設計されています。

マネージドクラスタでのデプロイに関しては、3 つの主要な柱に焦点を当てて、エクスペリエンスをゼロから再構築しました。具体的には、実行速度を向上させて Spark を高速化し、リソースの入手可能性を最大化して運用オーバーヘッドを削減することで Spark の実行をより簡単にし、開発と運用のライフサイクルに AI を直接組み込むことで Spark をよりスマートにしています。

このブログ投稿では、Managed Spark クラスタデプロイモードについて Google Cloud Next ‘26 で発表した内容を紹介します。このモードでは、ネイティブ実行エンジン、よりスマートなスケーリングポリシー、Gemini を活用した拡張機能により、パフォーマンスと費用を微調整できる柔軟性が向上しています。サーバーレスデプロイモードの最新情報については、こちらのブログ記事をご覧ください。

ネイティブ実行エンジン Lightning Engine で高速化

Managed Spark クラスタの最大のアップデートは、Lightning Engine でしょう。Lightning Engine は、Spark DataFrame / Dataset API や負荷の高い Spark SQL クエリのパフォーマンスを大幅に向上させます。また、Velox と Gluten をベースに構築されたネイティブの C++ ベクトル化実行エンジンと、専用の内部機能強化を備え、クエリプランを SIMD（単一命令複数データ）ベクトル化向けに最適化されたネイティブ命令にコンパイルすることで、JVM 実行のボトルネックを回避します。

このネイティブ実行エンジンは、以下を実現します。

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

重要な点として、こうしたパフォーマンス向上を利用するために、既存の Spark アプリケーションのコードを変更する必要はありません。ジョブがより高速で完了することが、Compute Engine の合計ランタイム時間と全体的な費用の削減にそのままつながります。

マネージドクラスタで Lightning Engine を有効にするには、クラスタの作成時に Lightning Engine オプションを指定するだけです。

Lightning Engine の技術的な詳細と Lowe’s の事例の紹介

より簡単に: フレキシブル VM でリソースの入手可能性を最大化

特定のマシンタイプがローカルで一時的に不足し、クラスタの作成や自動スケーリングが滞ることがあります。こうした容量の制約に対するクラスタの復元力を大幅に向上させるために、Managed Spark クラスタ向けのフレキシブル VM の一般提供が開始されました。

フレキシブル VM では、マスターノード、プライマリワーカーノード、セカンダリワーカーノードに最大 10 個のランク付けされたマシンタイプを定義できます。Managed Service for Apache Spark は、この設定と、リージョン内のゾーン自動配置を組み合わせ、リージョン全体を動的にスキャンしたうえで、利用可能な最適なハードウェアレイアウトを使用して容量リクエストを満たします。これにより、パイプラインを予測どおりにスピンアップできるようになり、リソースの可用性エラーが大幅に削減され、需要がピークに達する期間に費用対効果の高い Spot VM 容量を最大限に活用できるようになります。

より簡単に: ゼロスケールクラスタとスケジュール設定による停止

永続的な環境と開発環境の財務管理を強化するため、Google は最近、特に要望の多かった 2 つの FinOps 機能（ゼロスケールクラスタとスケジュール設定によるクラスタの停止）の一般提供を発表しました。

ゼロスケールクラスタ: セカンダリワーカー（Spot VM）のみを使用する環境をプロビジョニングできるようになりました。処理がアクティブでないとき、クラスタはワーカーノードを完全にゼロまで自動的にスケールダウンし、メタデータを保持するためにマスターノードのみをオンラインのままにします。
スケジュール設定によるクラスタの停止: この機能を使用すると、特定のアイドル時間制限または正確な将来のタイムスタンプに基づいて、クラスタの自動シャットダウンポリシーを構成できます。

これらの機能はネイティブに統合されているため、環境を削除して再構築しなければならないという運用上の負担が軽減されます。また、夜間や週末に生じるアイドル状態のコンピューティングオーバーヘッドに対する支払いを停止できます。

よりスマートに: Managed Service for Apache Spark MCP サーバー

生成 AI とデータエンジニアリングのギャップを埋めるために、Google は Managed Service for Apache Spark 向け Model Context Protocol（MCP）サーバーをリリースしました。このオープンスタンダードなインテグレーションにより、LLM と AI アシスタントは、自然言語を使用して安全かつ動的に Managed Spark クラスタとやり取りできます。

MCP サーバーを利用することで、AI エージェントは既存の IAM 権限でデータプラットフォームに安全に接続できます。そのため、エージェントはクラスタの作成、ジョブの送信、自動スケーリングポリシーの調整などのクラスタベースの処理を、AI アプリケーションから直接実行できます。

よりスマートに: Data Agent Kit で AI 導入を加速

Google Cloud Data Agent Kit は、データサイエンティスト、エンジニア、デベロッパーが、任意の開発環境内でデータワークロードのライフサイクル全体を直接管理できる拡張機能です。Managed Spark クラスタでこの拡張機能のネイティブサポートをロールアウトしたため、コード生成とデータラングリングのための専用のデータエージェントをシームレスに構築、デプロイできるようになりました。

デベロッパーは、Google のスタンドアロンのエージェント型開発プラットフォーム Antigravity 2.0 を使用するか、Data Agent Kit の拡張機能やプラグインを使用して、これらのエージェント機能を VS Code、Claude Code、Codex など任意の IDE に取り込むことができます。この効率化されたワークフローと、マネージドクラスタに備わる処理能力を組み合わせることで、これらのインテリジェントエージェントは、ペタバイト規模のデータレイク上で直接、複雑なワークフローを安全に実行できます。具体的には、デベロッパーは Data Agent Kit を使用して、次のことができます。

パイプラインの構築とオーケストレーション: 自然言語を使用してマルチノードのデータパイプラインを作成し、包括的なコードドキュメントを生成できます。
リアルタイムでデバッグを実行: Gemini Cloud Assist を活用して、エグゼキュータのログを精査し、ジョブ失敗の根本原因を特定して、実行可能な修正案を検討できます。
Spark リソースに簡単に接続: 手動によるネットワーク構成やローカルでの Spark インストールなしで、サーバーレス Spark ランタイムやマネージドクラスタに即座に接続できます。
Git と CI / CD の管理を合理化: 任意の IDE から直接コードを commit、マージ、デプロイし、自動でのテストとデプロイのパイプラインをスムーズにトリガーできます。

よりスマートに: 次世代の Lakehouse

Google は最近、Managed Service for Apache Spark や BigQuery などのエンジン間で読み取り / 書き込みの相互運用を可能にする Lakehouse をリリースしました。統合されたサーバーレスのメタデータレイヤとして Lakehouse ランタイムカタログが活用されることで、データサイロが解消され、複雑な変換レイヤが不要になります。このエージェントファーストのアプローチにより、組織は Google Cloud Storage からオープンフォーマットを直接処理したり、新たに導入されたクロスクラウド Lakehouse を使用してリモートの AWS データセットをクエリしたりできます。その際には、セキュリティとガバナンスのための信頼できる唯一の情報源が維持されます。

Managed Spark クラスタをご利用のお客様には、このインテグレーションにより、いくつかの強力な新機能が提供されます。データチームは、最適化された Lightning Engine を使用して、最も要求の厳しい ETL やデータサイエンスのワークロードを最大 4.9 倍高速化できます。

次世代ランタイム: Spark 4.1 を搭載したクラスタイメージ 3.0

オープンソースエコシステムにペースを合わせ、Google はクラスタイメージ 3.0 をプレビュー版としてリリースしました。これは Apache Spark 4.1 で構築され、デフォルトの Java ランタイムが Java 21 にアップグレードされています。Spark 4.1 では、構造化ストリーミングのリアルタイムモードなど、一連の主要なオープンソース機能が導入されています。これにより、1 秒未満のレイテンシで継続的に処理されるリアルタイムストリーミングを Spark 環境でサポートできるようになります。

使ってみる

これらのアップデートは公開済みであり、Managed Spark クラスタで今すぐご利用いただけます。新機能を有効にするには、Google Cloud コンソールを操作するか、gcloud CLI を使用します。

新しいマネージドクラスタをスピンアップし、Lightning Engine のパフォーマンスをネイティブに引き出すには、ターミナルで次のコマンドを実行します。

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 \\'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f617a32e3a0>)])]>

別の方法として、コンソールで Managed Service for Apache Spark のページに移動します。[クラスタを作成] をクリックして、クラスタ構成で [Lightning Engine を有効にする] を選択すると、Spark ジョブ向けに Lightning Engine が自動的に有効になります。

Managed Service for Apache Spark クラスタとして、皆様がどのような環境を構築、実行するのか、ご報告をお待ちしております。

- Google Cloud、シニアプロダクトマネージャー、Qiqi Wu

フルマネージドの AlloyDB 向けリモート MCP サーバーが一般提供開始

Tue, 16 Jun 2026 15:30:00 +0000

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

AI エージェントは優れた推論能力を備えており、ますます複雑なアクションを実行できるようになっています。しかし、エージェントによる成果の信頼性は、アクセスできるコンテキストの品質に大きく左右されます。そして、そのコンテキストは多くの場合、オペレーショナルデータベースの中に閉じ込められています。

このギャップを埋めるため、Google は AlloyDB 向けリモート Model Context Protocol（MCP）サーバーの一般提供を開始しました。

Model Context Protocol（MCP）は、LLM を外部データソースに安全かつ一貫した方法で接続できるようにするオープンソース標準です。Google Cloud が最近リリースした 50 以上の Google マネージド MCP サーバーの一部として提供されるこの新しい統合により、対話型エージェントと自律型エージェントのどちらも企業データの力をこれまで以上に簡単かつ安全に活用できるようになります。たとえば、AI エージェントを AlloyDB 内のリアルタイムロジスティクスデータに接続することで、配送フリートの最新状況をミリ秒単位で確認できます。これにより、古いデータによる不正確さを避け、手動でレポートを作成する必要も減らせます。

AlloyDB がエージェント型アプリの強固な基盤となる理由

MCP を AlloyDB に接続すると、エージェントはエンタープライズグレードの AI 向けに構築された高性能なデータベースにアクセスできます。AlloyDB は、要求の厳しいエージェント型ワークロードに必要なスケール、スピード、インテリジェンスを提供します。

強化されたベクトルパフォーマンス: ScaNN インデックスにより、100 億を超えるベクトルにスケールし、ベクトルクエリでは標準の PostgreSQL の最大 6 倍、フィルタ付きクエリでは最大 10 倍の速度を実現できます。
高度な検索と再ランキング: プレビュー版の RUM によるハイブリッド検索と、Reciprocal Rank Fusion（RRF）または Gemini Enterprise Platform モデルによるインテリジェントな再ランキングにより、マルチモーダルアプリケーションを強化できます。
リアルタイムインテリジェンス: 組み込みの AI Functions を使用して数百万件のエンベディングを効率的に生成し、低レイテンシのリアルタイムエージェント体験を実現できます。
統合されたデータアクセス: エージェントに単一の PostgreSQL インターフェースを提供し、Lakehouse Federation を通じて、AlloyDB の運用データ、BigQuery の分析データ、Iceberg テーブル内のアーカイブデータをシームレスに結合できるようにします。
エンタープライズグレードのスケール: 99.99% の SLA、Autopilot によるデータベース最適化、最大 20 ノードまで自動スケーリングできる読み取りプールにより、安心して運用できます。

AlloyDB にとってリモート MCP が重要な理由

ローカル MCP サーバーはローカル開発には最適ですが、本番環境のワークロードにスケールさせる場合、標準入出力（stdio）ストリームを介した通信は難しくなります。機密性の高い運用データを扱う高価値のユースケースでエージェントを実行するには、必要なインフラストラクチャやセキュリティガードレールをすべてプロビジョニングし、管理しなければなりません。これはアーキテクチャ上複雑で、管理面でも大きな負担になります。

AlloyDB 向けリモート MCP サーバーは、フルマネージドの Google Cloud インフラストラクチャ上で実行され、AI アプリケーションをデータに接続する HTTP エンドポイントを公開します。これにより、PostgreSQL 上でエージェントを構築するチームが直面する主な課題を解決できます。

一元的な検出: Agent Registry を使用して、データベースの MCP サーバーを検出、保護、管理できます。
フルマネージド HTTP エンドポイント: 接続に必要なインフラストラクチャをデプロイしたり維持したりする必要はありません。エージェントでそのエンドポイントを使用するよう構成するだけで、すぐに使い始められます。
きめ細かい認可: 共有データベースパスワードや API キーを使用する代わりに、Identity and Access Management（IAM）を使用して、エージェントのアクセスを特定のテーブル、スキーマ、ビューに制限できます。読み取り専用の SQL 実行ツールを使用すれば、エージェントが誤ってデータベースに変更や削除を加えることを防げます。
運用インスタンス管理: AlloyDB ツールセットにより、エージェントはクエリの実行だけでなく、インスタンスの更新、データのエクスポートとインポート、バックアップの作成、クラスタの復元も行えます。
Model Armor による保護: Model Armor は、プロンプトとレスポンスに対する任意のセキュリティ機能を提供し、データをスクリーニングおよびフィルタリングします。これにより、プロンプトインジェクションや偶発的なデータの引き出しから保護できます。
監査ロギング: すべてのクエリ、アクション、ツール呼び出しが Cloud Audit Logs に記録されるため、セキュリティチームは完全な監査証跡を得られます。

動作を確認してみる: 簡単なデモ

AlloyDB リモート MCP サーバーは、簡単な手順で使い始めることができます。ご自身の環境で実際の動作を確認するには、新しい Codelab に沿って、以下の主要な手順を実行します。

API と環境の準備: Google Cloud プロジェクトで AlloyDB、Compute Engine、Gemini Enterprise の各 API を有効にします。
データベースのプロビジョニング: AlloyDB クラスタをデプロイし、データベースを作成して、サンプルデータをインポートします。
データアクセス API の有効化: AlloyDB インスタンスでデータアクセス API を許可します。
エージェントの接続: リモートエンドポイント（https://alloydb.googleapis.com/mcp）を指定して MCP クライアントを構成します。HTTP Authorization ヘッダーで OAuth 2.0 ベアラートークンを使用し、Google Cloud IAM 認証情報を渡します。

接続が確立されると、エージェントはリアルタイムの運用データを使用して、複雑なビジネス上の質問に対して、信頼性が高く根拠に基づいた回答を提供できます。エージェントはイントロスペクションクエリを実行することで、テーブルや列を含むデータベーススキーマを自動的に理解します。これにより、ユーザーのリクエストに正確に応えるための高度な結合やクエリを構築できます。

エージェントが AlloyDB ツールセットにアクセスできるようになると、クエリの実行、運用傾向の分析、AI.RANK() などの AlloyDB AI Functions を使用したテキストデータの動的なランク付けが可能になります。

セキュリティは引き続き最重要事項です。AlloyDB 向けリモート MCP サーバーは Model Armor とシームレスに統合されます。これにより、エージェントのサービスアカウントがデータベース内で広範なアクセス権限を持っている場合でも、機密データの漏洩を防ぐことができます。

デモの全編を以下でご覧ください。

AI エージェントをエンタープライズデータに直接接続する方法: AlloyDB リモート MCP サーバーのご紹介

次のステップ

トランザクションデータとの安全なやり取りを可能にすることで、AI エージェントは企業の信頼できる唯一の情報源にアクセスし、それに基づいて行動できるようになります。

構築を始める準備はできましたか。30 日間の無料トライアルで AlloyDB をお試しください。また、Remote MCP for AlloyDB Codelab を活用して、エンタープライズ向けエージェント型アプリケーションの構築を今すぐ始めましょう。

- Google Cloud、AlloyDB / Cloud SQL 担当プロダクトマネージャー Paul Ramsey

- Google Cloud、データベース担当クラウドアドボケイト Gleb Otochkin

Claude Fable 5: Google Cloud で一般提供を開始

Fri, 12 Jun 2026 00:50:00 +0000

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

Anthropic の最新のフロンティアモデルである Claude Fable 5 の一般提供版が、Google Cloud でリリースされました。今回のリリースは、業界の最新モデルを Agent Platform に直接提供するという Google の継続的な取り組みを示す新たな事例です。

Claude Fable 5 は、Anthropic モデルの優れた機能をすべてのお客様に提供します。また、一般的な用途で安全に使用できるよう設計された強力な保護機能も備えています。複雑なマルチステップの推論向けに設計された Claude Fable 5 は、高度なソフトウェア開発、長期的なタスクを遂行するエージェント、高度なマルチモーダルドキュメント分析など、要求の厳しいタスクに適しています。このリリースの詳細については、Anthropic によるブログ投稿をご覧ください。

Claude Fable 5 のほか、Claude Opus 4.8 や Claude Sonnet 4.6 など、Anthropic の他のモデルを使用して、今すぐ Agent Platform で構築しましょう。

- Cloud AI、プロダクトマネジメント担当バイスプレジデント、Michael Gerstenhaber

Gemma で実現するデータ拡充のリアルタイムアーキテクチャ: Trustpilot の事例

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

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

厳しいレイテンシとコストの制約のもとで、数百万件のユーザーレビューをリアルタイムに処理するのは簡単なことではありません。Trustpilot は、大規模言語モデル（LLM）が注目を集めるはるか前から、カスタム ML を活用してこの課題に取り組んできました。そして現在、同社はコアスタックを生成 AI へと移行しています。ここでは、Google と Trustpilot が協力して、ファインチューニング済みの Gemma モデルを活用する大量処理向けストリーミングパイプラインをどのように構築したのかをご紹介します。

大規模で高度なレビューインテリジェンスを実現

Trustpilot のコアビジネスは、実用的で深いレビューインテリジェンスを提供することにあります。透明性と信頼できるフィードバックを重視するプラットフォームとして、データの完全性を守り、その価値を最大限に引き出すことが欠かせません。そのためには、受信するレビューからあらゆるメタデータを抽出する必要があり、このタスクには LLM が最も適しています。

LLM は、人が書いた雑多なテキストを解析し、固有表現抽出（NER）、ビジネスドメインの分類、感情スコアリング、顧客意図の特定を行うことに優れています。しかし、数件のレビューを LLM に処理させるのは簡単でも、コストを膨らませずに数百万件のレビューをリアルタイムで処理するとなると、エンジニアリング上の大きな課題になります。

オープンモデルをファインチューニングする理由

このような大規模なタスクに取り組む場合、Gemini のような強力な既製のフロンティアモデルに接続するだけでは、なぜ十分ではないのでしょうか。レビュー処理は Trustpilot のコアビジネスを支える重要なパイプラインであるため、クローズドモデルが最適な選択肢になることはほとんどありません。代わりに、Gemma のようなオープンウェイトモデルをファインチューニングすることで、Trustpilot は AI 戦略を自社で主体的に管理できます。具体的には次のとおりです。

モデルの完全な独立性: Trustpilot はモデルを自社で管理することで、再トレーニングのライフサイクルを自ら制御できます。これにより、サードパーティベンダーの更新スケジュールや突然の API 変更に左右されなくなります。
予測可能なコスト構造: トークン単位の変動料金モデルから、固定的なインフラストラクチャコストに移行することで、数百万件の予測処理を財務面で現実的かつ最適化可能なものにできます。
MLOps 機能の拡張: これらのモデルを社内で構築することで、Trustpilot はオープンウェイトモデルに関する専門性を高めながら、レビューインテリジェンスにおける独自のノウハウをモデルに組み込むことができます。
アーキテクチャの継続性: オープンウェイトモデルの系統に標準化することで、ベースモデルの将来のイテレーションも活用し続けられます。これにより、エンジニアリングの負担を最小限に抑えながら、パフォーマンス向上を取り込むことができます。

Trustpilot は、1 つの巨大なモデルをデプロイするのではなく、軽量な google/gemma-2-9b をベースに、高度に特化したモデル群を構築しました。

小さなフットプリントで高いパフォーマンスを実現するため、Trustpilot は自社のレビューコーパスから層化サンプリングしたデータに対し、Gemini 2.0 / 2.5 Pro / Flash ファミリーから選定した教師モデルを使用して、コンセンサスアノテーションを行いました。このプロセスにより、トピック分類、NER、感情抽出などの専門タスクに対応する高品質なトレーニングデータセットが生成されました。

その後、これらのデータセットを使用して、目的別に設計されたカスタムモデル群をファインチューニングしました。その結果、従来のソリューションを大幅に上回る精度を達成し、教師モデルのコンセンサスと比べても、わずか数ポイント低い程度の精度を実現しました。

システムアーキテクチャ

このアーキテクチャは、Dataflow と Gemini Enterprise Agent Platform エンドポイントの上に構築されています。VertexAIModelHandlerJSON をそのまま使用できるため、両者は非常にスムーズに連携します。

ビジネスロジックと LLM 推論そのものを分離するため、2 つのエンドポイントを作成しました。

分類器: FastAPI ベースのエンドポイントで、前処理 / 後処理、プロンプトテンプレート、チェーンなどの複雑な処理を担います。
LLM: vLLM 経由で Gemma モデルをサービングすることに特化した独立型の Agent Platform エンドポイントです。

このアプローチにより、Dataflow ジョブをシンプルに保ちながら、LLM エンドポイントを得意分野であるテキスト生成に専念させることができます。さらに、分類器と LLM エンドポイントを、トラフィックに応じて個別にスケールできます。

パフォーマンスチューニング

vLLM ベースの Agent Platform エンドポイントを最大限に活用するため、Trustpilot はパイプライン全体のパフォーマンスを可能な限り引き出すことに注力しました。特に、A100 GPU を搭載した A2 VM の性能を最大限に活かすことを重視しています。また、Gemini Enterprise Agent Platform が管理するカスタマイズおよび最適化された vLLM バージョンも活用しました。

パフォーマンスチューニングでは、処理のボトルネックを防ぐため、vLLM バックエンド構成の最適化に重点を置きました。エンジンパラメータを慎重に調整し、適切なデータ型を選択したうえで、プレフィックスキャッシュなどの有用な設定を有効にすることで、大量のストリーミングをモデルがスムーズに処理できるようにしました。

さらに、vLLM 推論サーバーの最適なサービング容量を見極め、パフォーマンス特性を把握するために、再利用可能な負荷テストフレームワークも共同で作成しました。これにより、必要なインフラストラクチャのベースラインを設定し、リクエスト数ベースの指標を使用して自動スケーリング設定をチューニングできるようになりました。加えて、vLLM で待機中のリクエスト数を使用する新しい指標のほうが、この用途にはさらに適している可能性があります。

課題

この構成を構築するにあたり、Trustpilot はいくつかの大きな課題に直面しました。

プライベートネットワーキング: このアーキテクチャでは、プライベートエンドポイントと Private Service Connect を使用して完全に分離された構成を目指していました。しかし、別個のエンドポイント間で直接プライベート通信を行うためのネイティブサポートがなかったため、実現には至りませんでした。
デプロイのオブザーバビリティと信頼性: エンドポイントのデプロイは時間がかかる場合や、内部の状態が見えにくい場合があります。そのため、正常でない状態になった際には、追加のトラブルシューティングが必要になることがあります。Trustpilot は現在も Gemini Enterprise Agent Platform のプロダクトチームと緊密に連携し、今後のオブザーバビリティ機能やプラットフォームの改善に取り組んでいます。
GPU の不足: EU リージョンで A100 GPU を確保するのは難しく、オンデマンド VM は多くの場合、現実的な選択肢になりません。そのため、予約の活用が望ましいものの、開発、本番環境、トレーニング、推論、試験の間で予約をどのように配分するかは非常に難しい課題です。

結果

Trustpilot は Google Cloud と協力し、Gemini Enterprise Agent Platform 上で Gemma の可能性を最大限に引き出すことで、1 日に数百万件のレビューをほぼリアルタイムで処理できるようになりました。その結果、Gemini に近いパフォーマンスをわずかなコストで実現しました。これにより、Trustpilot Business Platform は、日々寄せられる何百万件もの顧客レビューを、即座に活用できるインサイトへと変換できるようになりました。詳しくは、Trustpilot の Medium ブログ投稿をご覧ください。

^{このブログ投稿は、2025 年末に実施された共同プロジェクトの成果に基づき、Assulan Nurkas 氏（Trustpilot）、Subu Ramasubramanian 氏（Trustpilot）、Konrad Stanek 氏（Trustpilot）、Dario Banfi（Google）、Michael Cohen Hjertén（Google）が執筆しました。}

- Google、フォワードデプロイドエンジニア、Dario Banfi

- Trustpilot、スタッフ ML エンジニア、Assulan Nurkas 氏

AI & 機械学習

AI エージェント事例アワード開催！ 指示するから、自律する AI へ。

スケジュール

評価基準

表彰内容

日立「Gemini Enterprise 活用コンテスト」開催レポート ― 112 件の応募から選ばれた、現場を変える 10 の AI エージェント

112 件の応募から、現場発の 10 組が登壇

現場の「困った」から生まれた 10 のエージェント

受賞した 5 組と、審査員からの言葉

これからも、日立の挑戦とともに

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

LLM の力をデータに: 大幅な高速化とコスト削減を実現

デモのご紹介

始め方は簡単

Gemini Omni Flash と Nano Banana 2 Lite が圧倒的なスピードと費用対効果をもたらす

Gemini Omni Flash と Nano Banana で、どんなに斬新な構想でもカタチにできます。

Gemini Omni Flash: 高品質な動画生成・編集

Nano Banana 2 Lite: 費用とスピードを重視した設計

Nano Banana 2 Lite generates images in as little as four seconds.

Nano Banana 2 Lite でより高速なビジュアル エクスペリエンスを構築している業界のリーダー

安全性と企業ガバナンス

今すぐ始めましょう

BigQuery の AI.AGG 関数で全体像を把握し、傾向を分析する

AI.AGG() を使用したシステムログの分析

非構造化テキストや画像データからのカテゴリ抽出

AI.AGG() の仕組みとベスト プラクティス

お試しください

Alphaevolve で分子発見を 4 倍に高速化した Schrödinger の事例

AlphaEvolve とのコラボレーション

評価指標

結果: 4 倍の高速化とボトルネックの解消

次なる進化

英国の成長企業が AI 時代にどのようにビジネスを構築しているか

チームの強化: 英国企業の成長を支援する AI スキル向上リソース

検証可能なプライベート AI: Google Cloud が Confidential Computing の新たな領域を切り開く

グローバル規模での Confidential AI

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

機密性の高い基盤の進化

次のステップ

AI の可能性からエージェント型の現実へ: 英国の新たな章を切り拓く

英国の企業と研究の新たなフロンティア

将来を見据えた公共部門の構築

中小企業とスタートアップの成長エンジンを強化

Platform 37 の Model Garden

エージェント型企業の青写真

共に未来を築く

Sakana AI: Gemini Enterprise Agent Platform をサービス基盤に全面採用し、日本発の斬新なマルチ エージェント サービスを実装

日本のスタートアップが実現した、新世代のマルチ エージェント AI モデル

「集合知」を活用できるプラットフォームを、Gemini Enterprise Agent Platform で構築

Google Cloud のサポートを受け、わずか半年でサービス ローンチに成功

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

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

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

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

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

使ってみる

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

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

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

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

Open Knowledge Format のご紹介

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

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

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

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

設計の 3 つの原則

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

今後の展開

次世代の Confidential AI を推進

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

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

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

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

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

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

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

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

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

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

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

AI エージェント事例アワード開催！指示するから、自律する AI へ。

Nano Banana 2 Lite でより高速なビジュアルエクスペリエンスを構築している業界のリーダー

AI.AGG() の仕組みとベストプラクティス

Sakana AI: Gemini Enterprise Agent Platform をサービス基盤に全面採用し、日本発の斬新なマルチエージェントサービスを実装

日本のスタートアップが実現した、新世代のマルチエージェント AI モデル

Google Cloud のサポートを受け、わずか半年でサービスローンチに成功

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

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

より簡単に: ゼロスケールクラスタとスケジュール設定による停止

次世代ランタイム: Spark 4.1 を搭載したクラスタイメージ 3.0

Gemma で実現するデータ拡充のリアルタイムアーキテクチャ: Trustpilot の事例

大規模で高度なレビューインテリジェンスを実現

システムアーキテクチャ

パフォーマンスチューニング