GCP News - 2026-10-02

At Google Cloud, we know that you count on us to maintain the durability and integrity of your data at all times, both at rest and in transit. And now we’re making it easier for developers to take advantage of native data integrity features in Cloud Storage, by enabling end-to-end checksumming by default in all the Cloud Storage SDKs.

Like in any disk-based storage system, bits can flip anywhere in their journey, from the application all the way down to the disk. Cloud Storage has always let clients provide a checksum of the object data being uploaded, and receive a checksum of the data being downloaded. Also since its inception, Cloud Storage stores a checksum for every object in its metadata, regardless of how the object was uploaded into Cloud Storage.

But until recently, ensuring end-to-end data integrity required extra work on the part of developers to calculate and provide checksums to Cloud Storage. Cloud Storage always calculates the crc32 (32-bit cyclic redundancy check) of data it receives and ensures data stored on disk matches this checksum. When a client request includes the object’s checksum, Cloud Storage ensures that this checksum also matches. However, when an upload request doesn’t include a checksum, that upload is vulnerable to a bit flip while the data is in-flight, prior to the server-side checksum computation. Not all customers and clients enable client-side checksums by default, leaving data in this phase unprotected. 

To address this gap, the latest version of all Cloud Storage SDKs now internally checksums data being uploaded and passes this checksum to Cloud Storage, if it’s not provided by the application. The SDKs also support verifying the object’s checksum when an object is being downloaded.

Finally, there are many use-cases where applications download select ranges of objects instead of the full object. When using Cloud Storage SDKs with our gRPC API to perform a range read, the SDKs take advantage of gRPC’s built-in end-to-end range checksum, using it to verify the data it receives.

We highly recommend updating to our latest SDK versions to take advantage of these important integrity features.

And now, let’s peek under the hood

Ensuring continuous “chain-of-custody” between the data and its associated checksum from your application down to the disk platter, with no gap where a bit flip could go unnoticed, is quite challenging. And it’s critical to get this right: at our current scale of hundreds of thousands of Cloud Storage frontends, bit flips aren’t theoretical and do happen from time to time.

For instance, consider this simple example: when Cloud Storage receives your data in its frontend, this data gets encrypted with per-object encryption keys. This involves a data copy: the plaintext data is passed through an encryptor into a new memory buffer containing ciphertext. Extremely rarely, a bit in the source or destination memory buffer flips during this process. However, at our scale, extremely rare things happen routinely. 

In this situation, we maintain chain-of-custody by reversing the whole process: after encrypting the data (1), we calculate a checksum that protects the ciphertext. Then we decrypt the ciphertext (2), and if the resulting plaintext doesn’t match the original (3), we throw everything away and start over. This adds up to a lot of extra CPU time spent on encryption and checksumming, but it’s a necessary step to ensure data integrity.

Another challenge is how data gets broken up and aggregated as it passes through layers of our stack. As data gets uploaded to Cloud Storage, it gets split up into chunks, each of which has its own checksum. To manage data efficiently at scale, Cloud Storage groups thousands of chunks together into a storage unit we call a shard file. These gigabyte-sized files are how Cloud Storage ultimately delivers data to our cluster-level storage system, Colossus. Internally, Colossus uses Reed Solomon encodings to spread data across many disks and protect against the failures of individual disks, machines, and racks. This requires chopping up the shard file data into blocks, each of which is again protected by a checksum.

To maintain chain-of-custody of the data as it goes through all these transformations, we take advantage of some nifty properties of cyclic redundancy checks (CRCs), for example, concatenation. When you have two data buffers that each have their own CRC, you can cheaply compute the CRC of the two concatenated buffers without having to re-checksum the data. This comes in handy in many situations, such as when concatenating chunks together into shard files: Colossus can cheaply determine the CRC of the entire shard file from its constituent chunks and store that in its metadata.

Ultimately, the data lands on disks managed by our “D” file server (our network attached disks). D stores inline checksums for each range of data within a Colossus block. Whenever data is read from the disk, it is verified at several layers: The Colossus client verifies the data it reads against D’s inline checksums, and the Cloud Storage frontend reads data chunk-by-chunk, verifying each chunk against its checksum before sending it to the client. These chunk-level checksums are what enable our gRPC protocol to provide a checksum for a range read that can be verified by our SDKs, all without losing chain-of-custody.

The above image shows the data integrity handoff across multiple layers under the hood of Google Cloud Storage. On reads, checksums are verified inline at multiple layers to prevent silent corruptions.

1. Client passes full object checksum to Cloud Storage Frontends.

2. Data is split into chunks and individual chunk level checksums are computed.

3. Shard level checksums are computed based on concatenated chunk level CRCs.

4. Shards are stored across disk blocks with another level of block level inline checksums.

Here on the Cloud Storage team, we remain dedicated to maintaining the highest standards of data integrity for our customers. By making end-to-end checksumming the default in our SDKs and maintaining chain-of-custody throughout our internal storage stack, data remains exactly as intended from the moment of upload to the final download. This continuous vigilance reflects our commitment to protecting your data at any scale. To take full advantage of these protections, we recommend updating to the latest version of our SDKs.

In a data-driven world, PayPal’s ability to deliver timely and actionable insights is central to staying ahead. At PayPal, data powers everything from fraud detection to user experience enhancements. Data is also central to unleashing the potential of agentic solutions and experiences. 

Over time, though, our analytics environment had become a complex ecosystem of various technologies and solutions assembled on-premise to address growing demands. While this approach supported our needs at the time, it began presenting new challenges to scale and maintain.

Navigating a challenging analytics landscape

Due to expedited growth and acquisitions, our data analytics platform gradually turned into an uneven landscape. Each new platform or integration addressed a specific business need, but together, they increased operational overhead and introduced performance blockages. Scalability became increasingly difficult, and time-to-insight slowed as processes grew more complex. 

Complexity breeds stagnation

PayPal’s legacy data analytics platform was powerful—handling petabytes daily—but it was also increasingly rigid following rapid growth. Scaling up during peak retail events or global launches meant months of planning, slow manual provisioning of hardware, and too often, a compromise between speed and cost.

As PayPal continued to scale globally, we recognized the need for a streamlined, unified infrastructure to drive data efficiency and accelerate innovation.

The solution: Unified, cloud-native analytics

To overcome these obstacles, we migrated our analytics workloads from legacy Hadoop on-premise platforms to Google’s Managed Service for Apache Spark.

Key reasons for this choice included:

• Rapid provisioning and elastic scaling: Managed Spark enabled us to deploy clusters in minutes and scale based on processing needs, eliminating lengthy setup and idle resource costs. 

• Unified infrastructure: Standardizing on Apache Spark created consistency across teams while leveraging Managed Service for Apache Spark and other managed services reduced operational complexity.

• Seamless integration: Native hooks into Google Cloud Storage (GCS), BigQuery, and other Google Cloud services streamlined end-to-end data movement.

This move enabled PayPal to modernize our data processing capabilities, leveraging the flexibility, scalability, and reliability of cloud-native solutions. By consolidating previously disparate workflows and batch jobs that run on multiple platforms onto a single cloud-based analytics platform, we reduced data silos and built a unified data foundation that provides faster, richer insights. 

This empowered developers and application teams to focus on delivering business value rather than being limited by infrastructure. Crucially, this shift was about more than re-platforming. We fostered a new culture of experimentation, enabling teams to test, tune, and deploy analytics workloads quickly in response to changing business needs.

The results: Faster insights, lower overhead

The impact of our modernized Google Cloud-based ecosystem leveraging Managed Spark has been profound:

• Processing times for core analytics workloads improved by 25%, enabling near real-time insights for key business operations.

• SLA adherence rose substantially by 30%, even during traffic surges such as seasonal sales events.

• Operational costs dropped as we consolidated tooling and reduced manual maintenance.

But perhaps most importantly, our engineers now spend less time firefighting and more time innovating, rapidly prototyping new analytics capabilities that deliver value to customers and partners.

Transitioning from a fragmented environment to a cohesive, cloud-native platform has fundamentally strengthened PayPal’s analytics capabilities. As business needs evolve, investing in a scalable, unified data foundation ensures that we can deliver insights with speed, precision, and impact—driving continued innovation for customers worldwide. Our journey with Managed Service for Apache  Spark is an important step in building that modern analytics foundation.

Learn more about how you can get started with Managed Service for Apache Spark and BigQuery to build your Agentic Data Cloud today.

Enterprise AI agents need persistent memory to execute complex, multi-day workflows and long-horizon tasks. In this blog, we examine how a 2-tier memory architecture using Memorystore for Valkey for short-term buffer memory and AlloyDB AI for long-term persistent memory can help reduce token spend by up to 70%, while maintaining critical data and enterprise guardrails.

Imagine building a personalized travel agent designed to help users book vacations. The user interacts with the agent many times over the course of several days, asking questions that range from brainstorming itineraries to actual purchase intent. To provide a truly seamless experience, this agent must remember flight preferences (e.g. “I only want non-stop flights”), hotel budgets, and dietary restrictions (e.g. “I need Gluten Free dining options”) established in previous sessions. More importantly, it has to hold onto these core facts even when the conversation gets deep into the weeds of sightseeing recommendations and itinerary planning. The agent must ensure that all the follow-up questions and exciting details about places to visit doesn’t cause it to forget or overwrite the user's fundamental requirements and decisions. 

Stateful workflows inherently conflict with LLM’s stateless nature

AI agents are being used for multi-turn conversations and long-running workflows, but large language models (LLMs) remain stateless across sessions. When a user returns to an agent days later, the model starts with an empty context window. Unless your application is built to reconstruct past context using long-term agent memory, your users have to explain their goals and context all over again, resulting in a frustrating and fragmented experience.

With million-token context windows now the norm, a common shortcut to this problem is "context stuffing" -  dumping everything you can fit into the prompt at every turn, from raw chat histories to tool execution logs. In fact, this was a common pattern in the early days of AI model usage. But this shortcut quickly creates issues at scale: token costs multiply with every message, response times can drag out past 30+ seconds for otherwise simple prompts, and the model starts suffering from "lost in the middle" degradation, overlooking critical instructions buried in mountains of prompt text.

Another common workaround is to use rolling summaries; asking an LLM to periodically compress older messages into a summary paragraph. While this trims prompt size, LLM-based summarization is inherently lossy. After a few rounds of compression, subtle but important details get filtered out as background noise. A few turns later, your agent quietly breaks the exact constraints you set earlier. Clearly, you  need a more scalable approach for keeping a memory from previous conversations or multi-turn tasks, but without degrading the experience or creating new bottlenecks.

Implementing a 2-tier memory architecture

To build reliable, cost-effective enterprise agents that respect your guardrails and constraints, we recommend a 2-tier memory architecture:

• Short-term session buffer: Caches active conversation turns in memory using a token-bounded sliding window, allowing the context window size to remain stable across multiple rounds, even across devices, while keeping the latest messages fresh. This tier requires sub-millisecond, high-throughput lookups on every turn, making Memorystore for Valkey well suited for maintaining active session state. 

• Long-term persistent memory: Stores important facts, user preferences, and episodic facts across sessions. This tier requires transactional integrity, data governance, and hybrid retrieval across relational data and vectors - capabilities provided natively by AlloyDB AI.

While it’s possible to store both long-term memory and active session buffers directly in a relational database, a two-tier architecture with an in-memory cache provides better performance and scalability. Active session buffers are highly ephemeral and require sub-millisecond, high-throughput updates on every single conversation turn. Handling these rapid-fire writes in an in-memory key-value cache prevents write amplification and table bloat in your relational database, which would otherwise require frequent row deletions and intensive vacuuming. This is analogous to adding a caching tier in front of your database to offload high-frequency lookups for hot rows. The division of labor keeps your primary database lean and responsive, allowing it to focus its resources on what it is designed for: transactional consistency, complex hybrid vector search, and long-term analytical query execution. 

By pairing short-term caching in Memorystore for Valkey with native AlloyDB AI capabilities, you can run entity extraction, memory compaction, cross-session memory, and hybrid retrieval directly inside the database tier, keeping active prompts lean, fast, and cost-efficient.

Understanding the four memory types

To organize long-term agent state effectively, we further divide agent memory into four complementary types across the short-term and long-term storage tiers we described above:

By isolating short-term conversation context from structured long-term rules, your agent retrieves relevant context on demand without filling token windows with raw interaction logs.

The tiered memory architectural blueprint

The diagram below outlines the read and write paths connecting the application orchestration layer, the Memorystore for Valkey short-term buffer, and the AlloyDB AI long-term repository:

The system operates across two coordinated execution paths:

• The read path: When a user asks a question, the application fetches the active sliding window from Memorystore for Valkey, runs in-database query normalization using ai.generate, and queries AlloyDB using ai.hybrid_search to retrieve scoped entity rules and relevant episodic facts.

• The write path: After generating the response, the turn is immediately cached in Memorystore for Valkey. An asynchronous background queue worker extracts structured entities from the exchange and writes them directly into AlloyDB, where transactional auto-embeddings immediately compute and store vector representations in the database.

Business impact and ROI

In our benchmark testing across multi-turn development dialogues (45+ turns with heavy tool executions), separating short-term caching from long-term persistence delivered measurable cost and performance improvements compared to naive context stuffing:

Note: The metrics above reflect internal benchmark results from a simulated developer workload that mimics a real-world enterprise AI pair-programming assistant interacting with a developer over multiple sessions, projects, and context switches. Actual savings and latencies vary based on prompt structure, query frequency, and data volume.

These results demonstrate how tiered memory changes agent unit economics: instead of an escalating cost curve on every additional turn, prompt sizes remain bounded, reducing ongoing LLM API expenses while keeping response times fast.

Core AlloyDB AI technical advantages

AlloyDB AI reduces the operational overhead of implementing persistent agent memory by embedding core AI functions directly into the database engine:

• Transactional in-database auto-embeddings (ai.initialize_embeddings): AlloyDB automatically generates vector embeddings for text columns using a native integration with Agent Platform (formerly Vertex AI), generating up to 3,000 embeddings per second. Using incremental_refresh_mode => 'transactional', AlloyDB keeps embeddings up to date as source data changes within the same transaction, removing the need for custom embedding pipelines, external schedulers, or complex retry logic.

• In-database generative AI functions (ai.generate): AlloyDB allows you to execute foundation models, such as Gemini, directly from SQL queries. You can use this for in-database query decomposition - breaking compound user questions into single-aspect sub-queries and resolving relative time phrases (like "last session") into explicit identifiers - without making separate roundtrips from your application.

• Native hybrid search with built-in Reciprocal Rank Fusion (ai.hybrid_search): AlloyDB provides a built-in SQL function that executes Reciprocal Rank Fusion (RRF) directly inside the engine. It combines vector cosine similarity (<=> over HNSW or ScaNN indexes) with PostgreSQL full-text search (using BM25, RUM, or GIN) in a single database call, blending semantic matching with exact keyword retrieval while supporting metadata filter pushdown (filter_condition) for improved performance and deterministic scope isolation.

• Direct Agent Platform integration with IAM credentials: AlloyDB connects directly to Agent Platform foundation models over Google Cloud's private network using Google Cloud IAM service account roles and database authentication, avoiding the need to store, rotate, or pass API keys in application code.

• Unified operational, vector, and governance engine: AlloyDB consolidates relational business data, vector embeddings, full-text indexes, and enterprise permissions in a single ACID-compliant PostgreSQL database, avoiding data drift and integration complexity across separate operational and vector databases.

Key implementation patterns

Below are the core database patterns used to configure the 2-tier memory architecture. For complete, runnable Python and SQL scripts, refer to the companion AlloyDB Agent Memory Codelab.

1. Setting up schema and auto-embeddings

In AlloyDB, install the necessary extensions and define the agent_entities table with structured metadata, a generated tsvector column for full-text search, and a vector embedding column.

Then, generate embeddings using ai.initialize_embeddings. Using transactional mode ensures the embeddings are kept up to date as source data changes.

Finally, create the HNSW vector index and the RUM full-text search index to ensure your hybrid searches are fast and efficient.

2. Querying long-term memory with native hybrid search

On the read path, retrieve relevant long-term entities using ai.hybrid_search. This native SQL function executes Reciprocal Rank Fusion (RRF) directly in AlloyDB, seamlessly reranking and combining vector similarity search and full-text keyword search results in a single database query:

3. In-database memory compaction with AI functions

To manage long-term storage growth without writing custom pruning scripts, you can run automated extraction and compaction queries directly in AlloyDB to identify the important parts which can benefit from being stored. This pattern uses a SQL common table expression (CTE) with ai.generate to consolidate older episodic entries into a high-density summary:

For example, a long interaction regarding the complexities of changing flights with kids can result in a summary of “I prefer non-stop flights”.

4. Connecting the 2-tier memory architecture to an ADK agent

With the core 2-tier memory architecture configured, you can now extend the default ADK Memory provider to use this 2-tier memory architecture as shown in the accompanying Codelab (e.g. ADKTieredMemoryProvider). To attach the long-term memory to an ADK agent, you simply provide it as a tool (e.g. longterm_memory_tool) like this:

Enterprise governance and multi-tenant security

Running agent memory in enterprise production environments requires strict security boundaries and access controls. First of all, we need to maintain scope and multi-tenant isolation. By indexing user_id, project_id, and scope columns in agent_entities and enforcing PostgreSQL Row-Level Security (RLS), you can isolate memory stores across departments, teams, and individual users within the same database cluster. Parameterized Secure Views (PSV) offer another layer of deterministic application-level security, helping you protect against malicious prompts and overly-broad SQL queries.

In addition, we need to provide automated memory lifecycle management as shown in the implementation pattern above. Combining scheduled SQL compaction queries with time-based partition pruning helps maintain predictable database footprint and query latencies over time. See the accompanying Codelab for more details on this approach.

Summary and next steps

Decoupling active context windows from persistent storage is a practical approach to building production-ready AI agents. By pairing Memorystore for Valkey for sub-millisecond session caching with AlloyDB AI for transactional long-term storage, you can achieve substantial token cost savings and faster response times while maintaining strict business rules throughout long-horizon tasks and many-turn agentic experiences.

To get started:

• Step through the complete hands-on tutorial in the companion AlloyDB Agent Memory Codelab to deploy the working 2-tier memory architecture.

• Learn more about database-side machine learning features in the AlloyDB AI documentation.

• Explore guides on generating auto vector embeddings and running hybrid vector search.

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

ベクトル検索は、生成 AI、検索拡張生成（RAG）、データ エージェント アーキテクチャの重要なコンポーネントですが、ベクトル検索だけでは不十分な場合もあります。ベクトル エンベディングは概念的な意味を理解するのに優れていますが、特定の英数字 ID や正確な商品 SKU 番号を扱うのは苦手です。真に堅牢な検索アプリケーションや AI アプリケーションを構築するには、セマンティック ベクトル検索と従来の完全一致キーワード全文検索を組み合わせる必要があるかもしれません。これは、ハイブリッド検索と呼ばれます。

検索において、Best Matching 25（BM25）は、特定のクエリに対するドキュメントの関連性を推定するために使用される重要なアルゴリズムです。これまで、AlloyDB や Cloud SQL で BM25 ランキングを使用するには、全文検索バックエンドを追加する必要がありました。これにより、データサイロ、同期の遅延、運用の複雑化が生じていました。このたび、Tiger Data が作成したオープンソースの pg_textsearch 拡張機能により、AlloyDB と Cloud SQL for PostgreSQL 17 以降でネイティブ BM25 インデックスのプレビュー版が利用可能になりました。これにより、個別の全文検索バックエンドを維持する手間がなくなります。

統合されたハイブリッド検索バックエンドにより、最先端の全文検索を実現するために、個別のシステムをプロビジョニング、管理、または購入する必要がなくなりました。これらはすべて、運用データが保存されているデータベース内で直接行われ、以下を実現します。

• 業界標準のキーワード ランキング: Tiger Data の pg_textsearch を活用して、C 言語で最適化された超高速の BM25 スコアリングを Postgres テーブルに直接適用できます。

• 複雑さを排除し、完全な整合性を実現: ベクトル検索と全文検索のために複数のバックエンドを維持する場合に発生する、データの重複、ETL パイプライン、同期の遅延を排除します。

• 強化されたセマンティック検索（AlloyDB 限定）: ScaNN および HNSW インデックス タイプにより、ベクトル検索クエリが（標準の PostgreSQL と比較して）最大 6 倍および 10 倍高速になります。

pg_textsearch を使用する理由

PostgreSQL に組み込まれている ts_rank を使用して、ある程度の規模で全文検索を行ったことがある方なら、その限界をご存じでしょう。コーパスが大きくなるにつれて、ランキングの品質が低下します。逆文書頻度はサポートされていないため、一般的な単語は珍しい単語と同じ重み付けになります。用語頻度飽和がないため、「データベース」という単語が 50 回出現するドキュメントは、1 回しか出現しないドキュメントよりも上位にランクされます。

BM25 は、情報検索のゴールド スタンダードであり、逆文書頻度（珍しい用語ほど重要）、用語頻度飽和（繰り返しに左右されない）、文書長正規化を提供します。Tiger Data のブログ投稿では、PostgreSQL ページで BM25 検索エンジンを構築した方法について詳しく説明しています。

全文検索の例

AlloyDB と Cloud SQL の両方で BM25 全文検索を始める方法をご紹介します。サンプル テーブル cymbal_products を考えてみましょう。このテーブルには、固有識別子 uniq_id、product_name 列、各商品のテキスト説明を含む product_description 列、生成された product_embedding 列が含まれています。cymbal_products には、屋内植物や屋外植物など、さまざまな小売商品に関する情報が含まれています。

インデックスの作成

BM25 を使用するには、pg_textsearch 拡張機能を有効にします。

 cymbal_products テーブルの product_description 列にインデックスを作成します。

BM25 全文検索クエリは、<@> 特殊演算子を使用して実行できます。以下のスニペットでは、「cherry tree」を検索しています。

出力例を以下に示します。スコアが低いほど、関連性が高いことを示します。

AlloyDB ハイブリッド検索の例

AlloyDB でハイブリッド検索システムを設定するのは簡単です。同じテーブルにベクトル インデックスとキーワード インデックスの両方を作成し、ハイブリッド検索ユーザー定義関数（UDF）を使用して結果をシームレスに統合できます。

ベクトル インデックスの作成

ScaNN ベクトル検索インデックスを作成する方法は次のとおりです。

ハイブリッド検索

AlloyDB には、ハイブリッド検索クエリを非常に簡単に実行できる、すぐに使用可能なハイブリッド検索 UDF が用意されています。UDF は、Reciprocal Rank Fusion（RRF）アルゴリズムを使用して、各検索コンポーネントのランク付けされた結果を 1 つの統合リストにマージします。このクエリは、UDF を利用して、商品説明で「trees that grow taller than houses（家よりも高く成長する木）」のベクトル検索と「California（カリフォルニア）」のキーワード検索を実行します。

以下のサンプル出力に示すように、結果は RRF スコアの降順でランク付けされます。

ここで、ハイブリッド検索は、セマンティックな直感と正確なキーワード マッチングのギャップを埋めます。ベクトル エンベディングは「家より高く育つ木」のような概念的なクエリの理解に優れていますが、従来の全文検索は「カリフォルニア」のような厳密な識別子に求められるピンポイントの精度を提供します。この 2 つを融合することで、AlloyDB は、アプリケーションが「California Sycamore」のような、地域に関連性の高い具体的な結果をリストの最上位に優先的に表示できるようにします。

Cloud SQL ハイブリッド検索の例

Cloud SQL では、同じテーブルにベクトル インデックスとキーワード インデックスの両方を作成し、共通テーブル式（CTE）を使用して結果をシームレスに結合し、以下に示すように RRF スコアを統合できます。

ベクトル インデックスの作成

Cloud SQL で HNSW インデックスを作成する方法は次のとおりです。

ハイブリッド検索

こちらがハイブリッド検索クエリです。

結果の出力は、上記の AlloyDB ハイブリッド検索の結果と同じです。

実際の操作を見る

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

関連リソース 

Google は、Tiger Data と協力できることを大変嬉しく思っています。また、皆さまにネイティブ BM25 サポートを活用いただき、より高速でスマート、かつシンプルな AI アプリケーションを構築していただけることを楽しみにしています。今すぐ pg_textsearch 拡張機能を有効にして、AlloyDB と Cloud SQL で究極のハイブリッド検索エンジンを体験してください。

お試しになりたい場合は、以下のリソースをご確認ください。

• AlloyDB のリソース

• AlloyDB をまだご利用でない場合は、30 日間の無料トライアルで AlloyDB をお試しください

• AlloyDB AI でベクトル インデックスを選択する

• AlloyDB BM25 のドキュメント

• AlloyDB ハイブリッド検索 UDF のドキュメント

• Cloud SQL のリソース 

• Cloud SQL BM25 のドキュメント

• Tiger Data pg_textsearch リリース ページ

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

この投稿では、ボーダーレスな Lakehouse の機能強化についてお知らせします。これは、データ エンジニア、データ サイエンティスト、そして急速に導入が進む AI エージェントが、管理されたデータをその保存場所で直接クエリできるようにするためのソリューションです。

正確な推論を行い、複雑なエンタープライズ ワークフローを自動化するには、あらゆるタイプのエージェントとデータ利用者が、組織のデータ資産すべてに迅速かつ統合的にアクセスできる環境が必要です。そうした環境であれば、クラウドをまたいで顧客レコード、トランザクション ログ、運用テレメトリーを結合することが可能になります。しかし、現代の企業データが 1 か所に収まっていることはほとんどありません。データ資産は、Amazon S3、Azure Data Lake Storage（ADLS）、Google Cloud Storage、オペレーショナル データベース、さらには Salesforce、SAP、Workday などの SaaS プラットフォームに分散しているのが一般的です。これまで、こうした分散したデータセットの統合には、不安定な ETL パイプライン、ストレージの重複、極めて高額なクロスクラウド データ転送費用がつきものでした。

組織がクラウドをまたいでデータをクエリして有効活用できるようにするため、今年 Google はボーダーレスな Lakehouse を導入しました。Apache Iceberg REST カタログ仕様を採用することで、Databricks Unity Catalog、AWS Glue、Snowflake Horizon などのカタログとの直接連携が可能になりました。また、他のクラウド プロバイダへの高帯域幅のプライベート リンクを確立する Partner Cross-Cloud Interconnect も導入しました。この接続により、1 ギガバイトあたりの転送費用を公共のインターネットを使用するよりも削減できます。

今回の機能強化では、「そもそもネットワーク経由で転送する必要があるデータの量を最適化する」ことで、マルチクラウドの効率化をさらに一歩進めました。

クロスクラウド データのクエリ費用をさらに削減する、2 つの新機能をご紹介します。1 つは、Lakehouse 向けのクロスクラウド キャッシュのプレビュー版です。頻繁にアクセスされるデータを Google Cloud 内にローカル キャッシュすることで、ユーザーに意識させることなく BigQuery でのクロスクラウド クエリを高速化し、リモート転送の費用も削減することができます。標準的な Iceberg の列圧縮とクロスクラウドでのキャッシュ保存を組み合わせることで、クラウド間で実際に転送するデータの量を処理データの 5% 未満にまで抑えられることも珍しくありません。これにより、総所有コスト（TCO）を削減して、エンタープライズ規模でのクロスクラウド分析と AI 活用を実現できます。もう 1 つは、BigQuery のクロスクラウド接続のプレビュー版（こちらも提供中）です。この機能を使用すれば、他のクラウドにある Iceberg 以外のデータをクエリしてワークロードを高速化できます。

クロスクラウド キャッシュの仕組み

クロスクラウド キャッシュは、パラメータ調整やストレージ管理を一切必要とすることなくクエリを高速化し、企業が求める高度なパフォーマンスとセキュリティ要件を両立させます。それを実現する内部メカニズムの一部をご紹介します。

• サブファイル ブロック単位での処理: Apache Parquet などのカラム型フォーマットでは、クロスクラウド キャッシュはサブファイル ブロック レベルで動作します。そのため、クエリが数列にしかアクセスしない場合、数ギガバイトに及ぶファイル全体をクラウド間で転送する必要がなくなります。BigQuery は、クエリで指定された特定の列チャンクと辞書ページのみをキャッシュ保存します。キャッシュミスが発生すると、BigQuery はクエリに応答するために必要なデータをリモート クラウドから取得し、将来のクエリのためにコピーをローカルにキャッシュ保存します。これにより、繰り返し発生するワークロードのネットワーク転送とレイテンシを大幅に削減できます。

• デフォルトの保存データの暗号化: キャッシュに保存されたデータブロックは、Google が管理する暗号鍵（GMEK）によってデフォルトで暗号化されます。一時的なキャッシュ ストレージであっても、追加のオーバーヘッドなしで、通常の BigQuery ストレージと同様のエンタープライズ グレードのセキュリティ ポスチャーを維持します。

• テナントとリージョンの分離: キャッシュ エントリは、プロジェクトとカタログの境界ごとに厳密に分割され、テナント間でのデータ漏洩を防ぎます。Lakehouse は、ローカル キャッシュとクエリ実行の両方を、指定された Google Cloud リージョン（例: us-east4）に厳密に限定します。これにより、リモート クラウドへのクエリ実行時にも、各リージョンのデータ所在地要件への準拠を支援します。

• 更新頻度チェック: マルチクラウド キャッシュでは、処理速度と鮮度のトレードオフを強いられることがよくあります。ステイル読み取りを防ぐため、BigQuery はキャッシュに保存されたデータを使用する前にリモート オブジェクトのメタデータを取得して、データが変更されておらず、ユーザーが引き続きアクセスできることを確認します。元データのテーブルが変更されると、BigQuery は新しいファイルをフェッチし、参照されなくなったキャッシュ ブロックは自動的に破棄します。これにより、信頼できる唯一の情報源の正確性を維持しながら、ローカルクエリと同等の速度を実現します。

キャッシュの仕組み、統計カウンタ、リージョンに関する留意事項について詳しくは、Lakehouse のインテリジェント キャッシュに関するドキュメントをご確認ください。

クロスクラウド キャッシュの実際の操作

では、日常業務において、この仕組みはどのように動作するのでしょうか。例として、e コマースチームが、Databricks Unity Catalog から Lakehouse に統合された Amazon S3 の 10 TiB の Iceberg 売上テーブル（aws_lakehouse_catalog.sales.web_sales）に対してクエリを実行する場合を考えてみましょう。夕方のタイムセールの時間帯（午後 8 時～9 時）には、アナリストが過去の取引データをクエリし、購入意向の強いユーザー層において、どのオンライン店舗がピーク時の取引量と収益を押し上げているかを特定します。

初回実行: コールド状態でのカラム型データ取得

この最初のコールド実行では、ローカル キャッシュは空の状態です（cacheBytesRead: "0"）。BigQuery は、パーティションのプルーニングと列投影を適用して、必要な Parquet バイト範囲のみを Partner Cross-Cloud Interconnect 経由で Amazon S3 から転送します。

• 処理される論理データ: BigQuery は、10 TiB のデータセット全体のうち 214.5 GiB を処理します。

• 標準的な Iceberg の圧縮効率: Zstandard（zstd）を使用した標準的な Iceberg 列圧縮により、BigQuery が S3 から読み取るのは24.1 GiB のみです。これは8.9:1 の圧縮率に相当します。これらのサブファイル Parquet ブロックが Google Cloud に到着すると、BigQuery はそれらのデータをリージョン キャッシュに保存します。

追加の探索: ディメンションの追加

実際には、アナリストやエージェントがまったく同じクエリを 2 回続けて実行することはほとんどありません。フルフィルメントの詳細をさらに深堀りするため、アナリストは配送方法ディメンション（sm.sm_type）を追加してクエリを修正します。

この後続クエリのジョブ統計は次のようになります。

• 94.8% のキャッシュ ヒット率: BigQuery は、以前にクエリを実行した列の 24.1 GiB をローカル キャッシュから直接返します。

• 最小限のリモート取得: BigQuery は、新しい ws_ship_mode_sk 列と ship_mode テーブルを対象に、S3 から 1.33 GiB だけを転送します。

• サブファイル単位の柔軟性: キャッシュに保存された列チャンクが再利用されるため、クエリを修正しても新たに必要になったバイトのみが転送されます。

エンタープライズ規模で効率性を向上

クロスクラウド クエリの TCO を検討する際に重要となる、上位 2 つの要素は次のとおりです。

• 圧縮率: Iceberg でデフォルトの圧縮アルゴリズム（Zstandard / zstd）を使用すると、カラム型データは高い圧縮効果を発揮します。データの圧縮率が 8:1 であると仮定した場合、処理される論理データ 1 TiB ごとに、ネットワーク経由で移動する必要があるデータは約 128 GiB のみとなります。

• キャッシュ ヒット率: 最近アクセスされたデータをネットワーク経由ではなくキャッシュから取得できれば、ネットワーク転送を回避できます。データの 80% がキャッシュ ヒットになると仮定すると、アクセスされる物理データ 100 GiB ごとに、ネットワーク上を移動するデータは 20 GiB のみとなります。

これらの 2 つの要素と前提条件を掛け合わせると、組織が処理するデータ 1 TiB あたり、ネットワーク経由で転送する必要があるデータ量は約 26 GiB（処理されるデータ全体の 3% 未満）で済みます。この削減効果と Partner Cross-Cloud Interconnect を組み合わせることで、TCO を削減し、ペタバイト規模のクロスクラウド分析や AI 活用を極めて優れた費用対効果で実現できます。

BigQuery クロスクラウド接続のプレビュー版を提供開始

クロスクラウド キャッシュと併せて提供開始となった BigQuery クロスクラウド接続のプレビュー版では、BigQuery を Amazon S3 や Azure Storage のオープン形式データに直接接続することができます。

カタログ連携とクロスクラウド接続のどちらを使うべきかの判断基準はシンプルです。

• BigQuery のクロスクラウド接続（元ファイル用）: Iceberg カタログで管理されていないスタンドアロン ファイル（CSV、JSON、アドホックな Parquet）の場合、クロスクラウド接続を利用することで、リモートのバケットパスを直接参照する BigQuery 外部テーブルを作成できます。

• Lakehouse カタログ連携（Iceberg 向け）: Databricks Unity、AWS Glue、Snowflake Horizon などのカタログで管理されている Iceberg データの場合、Lakehouse がスキーマとテーブル スナップショットを自動的に同期します。これにより、ユーザー エクスペリエンスが簡素化され、ユーザーが常に最新のデータに対してクエリを実行できるようになります。

クロスクラウド接続は、他のクラウドのコンピューティング ワーカーではなく、Google Cloud リージョン内の標準 BigQuery コンピューティング ワーカーを使用する、最先端のアーキテクチャを採用しています。このアプローチにより、世界各地のリージョンでの利用が可能になるほか、リモート ファイルでも BigQuery と同等の機能（BigQuery AI や Gemini を含む）が提供されます。

Lakehouse のクロスクラウド キャッシュ機能は、BigQuery のクロスクラウド接続からクエリされたデータと、Lakehouse カタログ連携のデータの双方に適用されます。接続の作成方法や外部バケットパスへのクエリ実行方法については、BigQuery のクロスクラウド接続の設定に関するドキュメントをご確認ください。

- グループ プロダクト マネージャー、Will Ochandarena

- スタッフ ソフトウェア エンジニア、Jason Ganetsky

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

最も重要な AI 駆動型ワークロードを実行するために、Google Kubernetes Engine（GKE）を標準として採用する企業が増えています。高スループットのデータアクセスを実現する Cloud Storage FUSE から、カスタム コンピューティング クラス（CCC）や高度な GPU スライス法まで、GKE は最新のアプリケーションに必要なスケールと効率性を備えています。

しかし、複雑な Kubernetes 環境を AWS EKS から GKE に移行することは、従来、エンジニアリング上の大きな課題であり、多大な手間を伴うものでした。プラットフォーム チームは、複雑な Infrastructure as Code（IaC）を手動で分析し、クラウド固有のアーキテクチャの違いを把握して、カスタム変換スクリプトを構築する必要があります。

エンジニアリング チームは、汎用 LLM を使用してコード変換のドラフトを作成することをよく試みていますが、アドホックなプロンプトはすぐに運用上の落とし穴になる可能性があります。未加工のモデルは、存在しないリソース プロパティのハルシネーションを起こしたり、重要なネットワーク構成や ID 構成を欠落させたり、相互に依存するファイル間でコンテキストを失ったりします。プラットフォーム エンジニアがモデルエラーを監査、解決、デバッグするために費やす時間は、当初得られるはずだったスピード向上効果を相殺し、手作業による労力と予測不可能性を生み出します。

このたび、Google は GKE エージェント型移行のオープンソース リリースを発表いたしました。これは、不安定なアドホック プロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェント プラグインです。

「大企業のお客様にとって、クラウドのモダナイゼーションにおける最大の障壁は、実行リスクと予測不可能性です。コンテキストを失い、構成をハルシネーションする未加工のチャット プロンプトとは異なり、Google の GKE エージェント型移行は、生成 AI のスピードと、企業が必要とする決定論的なガードレール（構造化された状態の永続性、プラットフォーム チームとアプリチーム間のマルチペルソナ境界、交渉の余地のない人間の承認ゲート）の両方を備えてます。これにより、当社のグローバル エンジニアリング部門は、コンパイラ並みの精度で検証可能な移行ファクトリーを手に入れることができ、デリバリー リスクを大幅に削減できました。- Persistent、EVP、Rahul Shrivastava 氏

インフラストラクチャの移行に伴う課題

インフラストラクチャの移行プロセスについてお客様と話すとき、ガバナンスに関するいくつかの課題をよく耳にします。

• 自動化の信頼ギャップ: Kubernetes 構成を手動でリファクタリングすると、非常に時間がかかることがあります。しかし、汎用的な AI コーディング アシスタントを使用すると、許容できないリスクが生じます。標準的な LLM は、インフラストラクチャ コードをハルシネーションしたり、非推奨の API フィールドを使用したり、重要なセキュリティ ルールを省略したりすることがあります。「ほぼ正しい」コードを生成しても、ボトルネックがコードの作成からデバッグに移行するにすぎません。

• ライブクラスタの可変性の危険性（ClickOps）: 従来の移行ツールは多くの場合、ライブクラスタに直接接続し、API 呼び出しを介してデプロイします。これにより、組織の Git リポジトリ（信頼できる情報源）がバイパスされて、CI / CD パイプラインが中断され、ロールバックが非常に困難になります。

• サイロ化されたハンドオフのボトルネック: 移行は多くの場合、複数週にわたる長期的な作業となります。プラットフォーム エンジニアがランディング ゾーンを構築し、アプリケーション デベロッパーがワークロードを移行します。標準的な AI ツールを使うと、引き継ぎ時にコンテキストが失われます。

• 断片化されたツールチェーン: Velero などのバックアップ ツールは障害復旧には優れていますが、AWS 固有の構成（ALB など）をそのままキャプチャするため、Google Cloud 向けには変換されません。一方、リバース エンジニアリング ツールは、デベロッパーの本来の論理的な意図を排除したフラットな構成を生成します。

GKE エージェント型移行の概要

GKE エージェント型移行は、LLM の推論機能と厳格で決定論的なツールを組み合わせることで、これらの課題に対処します。エージェント スキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを、自動化された pull リクエスト経由で GKE ランディング ゾーンに直接変換します。

GKE エージェント型移行の特徴となっている主な機能は次のとおりです。

1. ハイブリッド検証 - LLM で生成し、決定論的に検証。危険な IaC ハルシネーションに対処するため、LLM ワーカーが Terraform と Kubernetes YAML の複雑な作成を処理し、サーバーが Workload Identity アノテーションやイメージ レジストリなどの正確なマッピングのために決定論的な変換を実行します。重要なのは、AI が生成したこれらの変換は、ユーザーに提示される前に、厳格な決定論的検証（terraform validate、Kubernetes マニフェスト コントラクトなど）にかけられることです。このアプローチは、ハルシネーションに対する安全性を維持しつつ、あらゆる操作を人間参加型（HITL）の承認によって制限するのに役立ちます。

2. GitOps ネイティブの PR ワークフロー: プラグインがライブクラスタに変更を直接適用することはありません。代わりに、信頼できる情報源を読み取り、ターゲット状態を生成して、pull リクエストを開きます。これにより、すべての変更が標準の人間参加型（HITL）CI / CD 審査プロセスをとおして処理されるようになります。「ClickOps」は不要です。

3. 変換と転送の分離を保護: プラグインは、アーキテクチャ変換の面倒なロジックを自動化しますが、ステートフル データを意図的に転送しません。最も機密性の高いアセットを保護するため、プラグインは、専用の SLA に裏付けられたツール（Google Cloud の Database Migration Service や Storage Transfer Service など）の使用をチームに指示する、コンテキストに応じたランブックを生成します。

4. マルチペルソナの状態管理: 移行はチームが行う取り組みです。プラグインは、長時間実行される移行状態を保持します。これにより、保護された非同期のハンドオフが可能になります。プラットフォーム エンジニアがベースラインのランディング ゾーンを確立し、アプリ デベロッパーは各自のマシンからワークスペースに個別にアクセスして、権限が分離されたフォルダ内で個々のワークロードを変換します。

仕組み: 移行のライフサイクル

内部的には、GKE エージェント型移行は実行可能関数の移行状態グラフを利用し、チェーンに沿ってコンテキストを体系的に渡します。オープンソースのエージェント プラグインとしてパッケージ化されているため、カスタム CLI バイナリをインストールする必要も、中央のコントロール プレーンを管理する必要もありません。チームは既存の開発ハーネスを通じてコラボレーションし、検証済みの pull リクエストと実用的なランブックをソース リポジトリに直接配信できます。これには、次のような利点があります。

• EKS リポジトリの念入りな検出: プラグインは、ソース Git リポジトリのクローンを作成するか、EKS クラスタのライブスキャンを実行し、ソース マニフェストをプログラムによりインデックスに登録して、依存関係をマッピングし、インベントリを構築します。

• 評価とブロッカー ガバナンス: アーキテクチャの非互換性を特定する準備状況レポートを生成します。設計を開始する前に、すべてのブロッカーにオーナーと解決目標日を割り当てる必要があります。プラットフォーム エンジニアは、変換を開始する前に移行の境界を承認します。

• ランディング ゾーンの設計: プラグインは、プラットフォームの明示的な決定（GKE Autopilot か GKE Standard かなど）に基づいて、基本的な Google Cloud Terraform モジュール（VPC、サブネット、GKE クラスタ、組織のポリシー）をスキャフォールディングします。

• AI を活用したクラウド変換: プラグインは、AWS IRSA から Workload Identity への変換、ALB Ingress から Gateway API へのマッピング、Karpenter ノード クレームから GKE ノード自動プロビジョニング（NAP）またはカスタム コンピューティング クラス（CCC）への変換など、独自の移行を処理します。

• オフライン検証: 生成されたモジュールとマニフェストは、オフラインでコンパイルされ、検証されます（terraform validate、マニフェスト構造のチェック、出力コントラクト）。

• デプロイ（pull リクエスト経由）: 最終的な構成がローカルで検証され、レビューのために PR が開かれます。

使ってみる

GKE エージェント型移行は、クラウド移行を、まとまりのないリファクタリング作業から、予測可能で AI が支援する、レビュー可能な GitOps ワークフローへと変革します。GKE への移行を加速させる準備は整いましたか？

• GitHub の GKE エージェント型移行リポジトリにスターを付け、クローンを作成してみましょう。

• オンボーディング ガイドを読み、サンプルの EKS リポジトリに対してプラグインを実行しましょう。

• Google Cloud コミュニティに参加して、フィードバックの共有、質問、投稿を行ってください。

- GKE プロダクト マネージャー、Sunny Hwang

- GKE エンジニアリング マネージャー、Hamed Seifoddini

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

リアルタイム ストリーミングでは、1 ミリ秒の違いが結果を左右します。

たとえば、30 フレーム/秒（fps）の場合、デベロッパーはカメラフレームの取り込み、ニューラル セグメンテーションの実行、シェーダーの適用、出力の合成を、わずか 33.3 ミリ秒（60 fps の場合は 16.6 ミリ秒）という厳格なフレーム バジェット内で行う必要があります。このバジェットを 1 ミリ秒でも超えると、ドロップフレーム（コマ落ち）やスタッタリング（カクつき）が発生します。

これを手動で最適化するのは、フレームグラフの分析や Swift、C++、Metal での低レベルコードの手動調整に何週間もかかるため、非常に面倒な作業になります。標準的な AI コーディング支援を使用すれば、ボイラープレートを生成することは可能です。しかし、ターゲット ハードウェアに合わせた最適化や実際の環境で生じるレイテンシへのベンチマークには対応できず、また最適化後に視覚的な忠実度を完全に維持することもできません。

この状況を打破するには、自律的なクローズドループの進化史的最適化が有効です。AlphaEvolve のようなツールが、クラウド規模のモデル推論をローカル ハードウェアでの実行と組み合わせ、すでに実用環境に効果をもたらしています。DoIt は、Google との提携により、AlphaEvolve を使用して、macOS のライブ ストリーミング アプリにおける本番環境 Swift コードの自律的最適化を実現しました。これにより、手動プロファイリングでは見つけられなかった伸びしろが見出され、パフォーマンスが改善されました（詳しくは完全版の技術レポートをご覧ください）。

この投稿では動画パイプラインに焦点を当てていますが、分割ループパターンは、マイクロサービスのスループットやデータベースのクエリから、ML テンソル パイプラインや組み込みシステムまで、パフォーマンスが重要となるあらゆる場面に適用できます。どのユースケースにおいても仕組みは同じで、クラウドにおける Gemini のコード生成を、ドメイン固有のベンチマーク ハーネスおよび自動品質ゲートと組み合わせます。

ここでは、AlphaEvolve を使用して動画処理を高速化する方法と、ユーザー固有のパフォーマンス ボトルネックに以下の原則をどのように適用できるかについて確認していきましょう。

1. 分割ループ アーキテクチャを理解する: AlphaEvolve が、マネージド クラウド生成（Google Cloud 上の Gemini モデル アンサンブル）をローカルでの評価プロセス（ネイティブ Swift / Metal コードのコンパイルと実行時間の計測など）からどのように分離しているのかを理解します。

2. 評価ツールの設計と品質ゲートを適用する: 構造的類似性指数（SSIM）などの指標を使用してスコアリング関数を構築し、進化ループがベンチマークの裏をかく（例: 速度を上げるためにレンダリングを完全にスキップする）のを防ぎます。

3. 自律的なアルゴリズム検出を活用する: Gemini 主導の進化史的最適化検索により、プロンプトなしでフレームワーク API を自律的に検出し、エンジニアリングのバランス（フレーム キャッシュの制限など）をインテリジェントに調整します。

4. 現実的なパフォーマンス境界を設定する: 物理的なハードウェアの限界に対応するコードの最適化を測定します。

1. AlphaEvolve の分割ループ アーキテクチャを理解する

AlphaEvolve は、クローズドループの進化プロセスを実行します。つまり、シードプログラムとカスタム スコアリング関数を使用して、Gemini モデルの混成がコードのバリエーションを提案し、各候補に対してスコアリング関数を実行します。その過程で最もパフォーマンスの高いコードを保持し、複数の世代にわたって反復的に最適ソリューションへと進化していく仕組みです。

AlphaEvolve アーキテクチャの主な利点は、次の 2 つの要素に明確に分けられていることです。

1. 生成サイド（Google Cloud マネージド サービス）: プロンプト サンプラー、Gemini モデル アンサンブル、プログラム データベースが含まれます。スケーリング、プロンプト オーケストレーション、生成メカニズムが Google Cloud で処理されます。

2. 評価サイド（ユーザー管理のコンピューティング）: コード品質のスコアリングが、厳密にドメイン限定で実行されます。評価モジュールは完全にユーザーが所有し、独自のハードウェアまたはターゲット アーキテクチャ（この場合はネイティブ Swift コードを実行する macOS）で実行されます。

AlphaEvolve は、クラウド生成サイドでは Python ファーストですが、評価サイドは任意の言語で記述できます。カスタム評価ツールでは、Swift コードの各候補を Swift を使用してコンパイルし、標準の参照ウェブカメラ クリップに照らして評価を実行します。

2. 評価ツールの機能と品質ゲートを適用する

AlphaEvolve のような自動最適化ループは、実際には動画ストリームを「見る」ことはありません。評価ツールが返す数値の適合度スコアを確認するだけです。評価指標に盲点がある場合、進化史的最適化によるコード生成はそれを積極的に利用してしまいます。

たとえば、初期の実行では、未熟な適合度スコアが元のレイテンシを重視するあまりに、処理が異常に高速化されました。モデルはぼかしレンダリングを完全にバイパスし、未修正のフレームを 0 ミリ秒で返したのです。

構造的類似性指数（SSIM）:

モデルがベンチマークの裏をかく行為を防ぐには、以下のように、スループットと構造的類似性指数（SSIM）などの構造的忠実度指標を組み合わせた 2 段階のスコアリング関数を記述します。

これにより、以下のことが可能になります。

• 極めてハードルの高いクリップでテスト可能に: 静止フレームや空白のカメラ映像をベンチマークにすることは絶対に避けるべきです。コードの各候補は、静的な背景のフレームでは平均 SSIM ゲートを簡単に通過できてしまいますが、人がさっと振り向くような映像では必ず不適格になります。

• 平均だけでなく最小値も追跡可能に: 平均しきい値とフレームごとの最小値の両方を適用して、ドロップフレームやマスク更新の遅延を検出できます。

自律的なアルゴリズム検出を活用する

一般的に、デベロッパーは生成 AI を使用して、ローカルのマイクロ最適化（ヘルパー関数のインライン化、ループの展開、メモリプールの調整など）を行っています。しかし、アーキテクチャの余地を与えれば、進化ループがシステム的な最適化手段を自律的に発見することができます。

エンジニアリングのヒント:

• 分離されたループではなく、フレームワークのコンテキストを提供する: 公開 SDK ヘッダー、インターフェース定義、API リファレンス識別子をプロンプトまたは検索ハーネスに含めます。LLM のコンテキスト ウィンドウに、分離されたフレーム処理コールバックのみが含まれている場合、LLM はシーケンス対応サブシステムを使用できません。

• マルチフレーム ライフサイクル フックを利用可能にする: 純粋なステートレス関数を適用するのではなく、コードの候補が前の実行から次の実行に制限付きの状態データ（マスクの履歴やキャッシュのタイムスタンプなど）を引き継げるようにします。

• 品質ゲートで動画の質と処理速度のバランスを管理する: AlphaEvolve に一時的なマスク キャッシュを導入した際、当初はマスクのキャッシュが過剰に行われ、動画にゴーストなどが残ってしまいました。そこで、SSIM ゲートによって動きのブレを規制し、パラメータを手動調整することなく、本番環境に対応したキャッシュ ウィンドウに検索を収束させました。

現実的なパフォーマンス境界を設定する

パフォーマンス エンジニアリングでよくある落とし穴は、闇雲に最適化を行うことです。2 倍の高速化を達成した場合、それで満足すべきでしょうか。それとも、さらに 3 倍を目指す余地があったのでしょうか。

リアルタイムのメディアにおいて、合計フレーム時間は次の 2 つのカテゴリに分けることができます。

1. 変更可能なソフトウェアのオーバーヘッド: メモリ割り当て、バッファ形式の変換、スレッド コンテキストの切り替え、API ディスパッチの摩擦などがこれに相当します。

2. 変更不可のハードウェア ベースライン: 未処理のニューラル エンジン推論レイテンシ、GPU シェーダー コンピューティング時間、ハードウェア ディスプレイ同期などがこれに相当します。

AlphaEvolve を最大限に活用するには、理論上の最大ヘッドルームを基準に測定する必要があります。

最適化ループを実行する際は、次の原則を考慮しましょう。

1. NoOps パイプラインを構築する: Swift / C++ オーケストレーション、データ マーシャリング、フレーム変換は排除し、ウォームアップ済みの ML モデルと未加工 GPU のレンダリング パスのみをダミーバッファにディスパッチします。結果として得られる時間が、物理ハードウェアの下限となります。

2. 対応可能な上限を計算する: 最適化可能な最大値は次の式で計算できます。

3. ハードウェアの制約を考慮して測定する: 任意の高速化倍率ではなく、最適化効率を測定します。

実際に使ってみる

すべてのベンチマーク コード、テストクリップ、評価スクリプト、未加工の候補ログはオープンソースです。

• GitHub リポジトリ: AlphaEvolve Camera Background Blur Example

• DoIt の事例紹介に関する詳細な技術レポート: Running AlphaEvolve on Your Own Code

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

- DoIt、プリンシパル AI リード、Sascha Heyer 氏