本記事は 2026 年 7 月 20 日 に公開された「 Connection pooling strategies in Amazon Aurora DSQL 」を翻訳したものです。 本記事では、Aurora DSQL の接続負荷を減らし、1 秒あたり 100 接続のレート制限を超えず、再接続が一斉に集中する thundering herd を避けるための、具体的な 4 つの戦略を解説します。読み終える頃には、大規模でも安定した性能を発揮する接続プールを構成するための、本番運用に使えるチェックリストが手に入ります。 接続プーリングの戦略次第で、 Amazon Aurora DSQL アプリケーションが安定してスケールするか、負荷で破綻するかが決まります。Amazon Aurora DSQL 独自のアーキテクチャは、接続プーリングの効果をさらに大きくします。トランザクション単位の多重化と AWS Identity and Access Management (IAM) による認証により、Aurora DSQL では適切なプーリング戦略が、従来の PostgreSQL の接続管理では実現できない形で性能を高めます。 注: 本記事は、PostgreSQL の接続管理の概念と基本的な IAM 認証を理解していることを前提としています。Amazon Aurora DSQL を初めて使う場合は、これらの戦略を適用する前に、まず Getting Started ガイド から始めてください。 サーバーレス環境での接続プーリング Amazon Aurora DSQL は運用の複雑さを自動的に処理しますが、それでも接続プーリングは欠かせません。新しい接続のたびに、コストの高い TLS ハンドシェイクと認証情報の交換が発生します。プーリングは確立済みの接続を再利用し、この負荷を抑えてレイテンシーを削減します。また、トラフィックが急増すると、1 秒あたり 100 接続 (バースト時 1,000) のレート制限に達することがあり、既存の接続を再利用すればサービスの制限内に安全に収まります。さらに、Amazon Aurora DSQL には接続の最大有効期間があり、クライアントは 1 時間で切断されます。適切に構成したプールはこの制限に達する前に接続をリサイクルし、セッションを透過的に維持します。 トランザクション単位のプーリング: アーキテクチャに組み込み済み Amazon Aurora DSQL はトランザクションプーリングモデルを採用しています。接続を Query Processor に割り当てるのは、セッション全体ではなくトランザクションの実行中だけです。標準的な PostgreSQL では、接続はバックエンドのサーバープロセスと 1:1 のセッション関係を持続的に維持します。一方 Amazon Aurora DSQL はこの対応関係を切り離すため、少数の Query Processor ではるかに多くの接続を処理できます。 この設計は、接続の使用率が低いこと、つまりほとんどの接続が大半の時間アイドル状態であることを前提としています。使用率が低いほど、接続プールに必要な Query Processor は少なくて済みます。そのため、PgBouncer や pgpool-II のようなデータベース側のプロキシは使うべきではありません。トランザクション単位の接続多重化がデフォルトで組み込まれているため、これらのツールはサービスの接続アーキテクチャと重複します。 さらに、一部の PostgreSQL 機能はサポートされていません。SQL レベルの PREPARE/DEALLOCATE ステートメント (ただし拡張クエリプロトコル経由のプリペアドステートメントは正常に動作します)、WITH HOLD カーソル、セッションレベルのアドバイザリーロックです。 Amazon Aurora DSQL の 4 つの接続プーリング戦略 以下の 4 つの戦略は、それぞれ Amazon Aurora DSQL の接続管理の特定の側面に対応します。組み合わせて適用すれば、アプリケーションがサービスの制限内に収まり、負荷がかかっても安定した性能を保てます。新しいアプリケーションを構築する場合は戦略 1 から始め、既存の PostgreSQL アプリケーションを移行する場合はチェックリストとして活用してください。 戦略 1: 公式の AWS コネクタを使う 公式の Amazon Aurora DSQL コネクタ の利用をお勧めします。トークンの生成、有効期間の 80% でのキャッシュ、透過的な更新など、IAM トークンのライフサイクル全体を自動的に処理します。 表 1: プログラミング言語別の推奨接続プールライブラリと主要な設定パラメータ 言語 プーリングライブラリ 主要な設定 Java HikariCP maximumPoolSize Python psycopg ConnectionPool min_size Node.js node-postgres (pg.Pool) max Go pgxpool MaxConns Java (HikariCP) — Spring Boot、Quarkus、Micronaut のアプリケーションでは HikariCP を使います。 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:postgresql://<cluster-endpoint>:5432/<db>?ssl=true&sslmode=verify-full&sslrootcert=<path>"); config.setMaximumPoolSize(20); config.setMaxLifetime(55 * 60 * 1000); // 55 minutes config.setIdleTimeout(10 * 60 * 1000); // 10 minutes config.setConnectionTimeout(30 * 1000); // 30 seconds config.setKeepaliveTime(5 * 60 * 1000); // 5 minutes HikariDataSource ds = new HikariDataSource(config); Python (psycopg ConnectionPool) — Django、Flask、FastAPI のアプリケーションでは psycopg ConnectionPool を使います。 from psycopg_pool import ConnectionPool pool = ConnectionPool( conninfo="host=<endpoint> dbname=<db> sslmode=verify-full", min_size=2, max_size=20, max_lifetime=55 * 60, # 55 minutes in seconds max_idle=10 * 60, # 10 minutes idle timeout reconnect_timeout=30, # 30 seconds to reconnect ) Node.js (node-postgres) — Express.js、NestJS、サーバーレスの Node.js 関数では node-postgres の Pool を使います。 const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 20, idleTimeoutMillis: 10 * 60 * 1000, // 10 minutes connectionTimeoutMillis: 30 * 1000, // 30 seconds }); Go (pgxpool) — Gin、Echo、AWS Lambda Go ランタイムで構築する Go アプリケーションでは pgxpool を使います。 connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 20 config.MinConns = 2 config.MaxConnLifetime = 55 * time.Minute // 55 minutes config.MaxConnIdleTime = 10 * time.Minute // 10 minutes idle pool, _ := pgxpool.NewWithConfig(ctx, config) AWS Lambda: プールはハンドラーの外でインスタンス化する AWS Lambda は Aurora DSQL のワークロードでよく使われるコンピューティングサービスです。Lambda の実行モデルには特有のプーリングパターンが必要です。接続プールをモジュールスコープ (ハンドラー関数の外) で作成し、同じ実行環境のウォーム呼び出し間で保持されるようにします。 Lambda が実行環境を再利用すると、モジュールスコープで作成したプールはアクティブなまま残ります。以降の呼び出しでは TLS ハンドシェイクと IAM トークンの交換を完全にスキップできます。コールドスタート時にはプールが一度だけ初期化され、その環境が存続する間は再利用されます。 同時に実行される各 Lambda 呼び出しはそれぞれ独立した実行環境で動くため、プールも個別に持ちます。多数の同時実行にわたって接続を過剰に確保しないよう、プールサイズは小さく (Lambda インスタンスあたり 1〜3 接続) 保ってください。 Lambda の主なガイドライン: プールはハンドラーの外でインスタンス化する。これが最も重要なルールです。 最大プールサイズを 1〜3 に設定する。各 Lambda インスタンスは (バッファ呼び出しを使わない限り) 一度に 1 リクエストしか処理しないため、大きなプールは無駄になります。 アイドルタイムアウトを設定しない。接続は実行環境が存続する間ずっと維持させます。 Lambda 以外のワークロードと同様に、1 時間のハード制限に達しないよう、最大有効期間を 55 分にしてジッターを加える。 コールドスタートのレイテンシーを考慮する。最初の呼び出しでは TLS と IAM 認証の負荷が発生します。以降のウォーム呼び出しではプールされた接続を再利用します。 Python (psycopg ConnectionPool) — Lambda # pool is created ONCE at module scope, reused across warm invocations from psycopg_pool import ConnectionPool import boto3 pool = ConnectionPool( conninfo="host=<cluster-endpoint> dbname=<db> sslmode=verify-full", min_size=1, max_size=2, max_lifetime=55 * 60, # 55 minutes reconnect_timeout=30, ) def handler(event, context): """Lambda handler — pool is already initialized.""" with pool.connection() as conn: result = conn.execute("SELECT * FROM orders WHERE id = %s", [event["order_id"]]) return result.fetchone() Node.js (node-postgres) — Lambda // Pool is created ONCE at module scope, reused across warm invocations const { Pool } = require("pg"); const pool = new Pool({ host: "<cluster-endpoint>", database: "<db>", ssl: { rejectUnauthorized: true }, max: 2, // small pool per Lambda instance idleTimeoutMillis: 0, // don't close idle connections connectionTimeoutMillis: 30 * 1000, // 30 seconds }); exports.handler = async (event) => { // Pool is already warm on subsequent invocations const client = await pool.connect(); try { const result = await client.query("SELECT * FROM orders WHERE id = $1", [event.orderId]); return result.rows[0]; } finally { client.release(); } }; Go (pgxpool) — Lambda package main import ( "context" "time" "github.com/aws/aws-lambda-go/lambda" "github.com/jackc/pgx/v5/pgxpool" ) // Pool created at package scope — initialized once per execution environment var pool *pgxpool.Pool func init() { connStr := "host=<cluster-endpoint> dbname=<db> sslmode=verify-full" config, _ := pgxpool.ParseConfig(connStr) config.MaxConns = 2 config.MinConns = 1 config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute pool, _ = pgxpool.NewWithConfig(context.Background(), config) } func handler(ctx context.Context, event map[string]string) (string, error) { row := pool.QueryRow(ctx, "SELECT name FROM orders WHERE id = $1", event["order_id"]) var name string err := row.Scan(&name) return name, err } func main() { lambda.Start(handler) } ヒント: Lambda 関数の同時実行数が多い場合 (数百の同時実行)、各実行環境がそれぞれプールを作成します。最大プールサイズ 2 で 500 の Lambda が同時実行されると、Aurora DSQL への接続は最大 1,000 になり得ます。接続の総数を監視し、クラスターあたり 10,000 同時接続のクォータ内に収めてください。 重要: クライアント接続には sslmode=verify-full を設定し、証明書を完全に検証して経路上の攻撃 (on-path attack) を防ぎます。Aurora DSQL は verify-ca や require といった弱いモードでも接続を受け付けますが、これらはサーバーの正当性を検証しません。 安定した接続プールを維持するには、IAM トークンのライフサイクルの理解が重要です。 新しい接続ごとに、新しい IAM 認証トークンを生成します。トークンの生成はローカルでの署名操作で、負荷はごくわずかです。公式の AWS コネクタはこれを自動的に処理します。独自のプールを使う場合は、トークンを手動でキャッシュするのではなく、接続ファクトリの beforeConnect フックで generate-db-connect-auth-token コマンドを呼び出してください。 トークンは、基となる IAM 認証情報より長くは有効になりません。1 時間のセッションでロールを引き受けた場合、 --expires-in の値に関係なく、トークンは最大でも 1 時間で失効します。 データベースロールは最小権限に絞る。 IAM 認証は誰が接続できるかを制御しますが、接続後にそのセッションが何をできるかは制限しません。各アプリケーションのデータベースロールには、必要な最小限の権限だけを付与します。たとえば、読み取り専用のサービスには SELECT を付与し、書き込みアクセスは特定のスキーマやテーブルに限定します。アプリケーションの接続プールで管理者ロールを使うのは避けてください。 手順の詳細は、 Authorizing database roles to use SQL in your database を参照してください。 戦略 2: 最大接続有効期間にジッターを設定して接続の失効を防ぐ Amazon Aurora DSQL には、1 時間という接続の最大有効期間のハード制限があります。接続がこの期間に達すると、アイドル中でもトランザクションの途中でも、サービスはその接続を閉じます。プールはそうなる前に接続をリサイクルする必要があります。 ジッターが重要な理由: プール内のほとんどの接続がほぼ同じタイミング (たとえばアプリケーションの起動時) に作成された場合、それらはほぼ同時に失効します。すると新しい接続リクエストが一斉に集中する「thundering herd」が発生し、1 秒あたり 100 接続のレート制限を超えることがあります。最大有効期間にランダムなジッターを加えると、接続のリサイクルが時間的に分散されます。 // Go (pgxpool) — Use native per-connection jitter config.MaxConnLifetime = 55 * time.Minute config.MaxConnLifetimeJitter = 5 * time.Minute // Each connection independently gets a lifetime between 55-60 minutes // Java (HikariCP): maxLifetime already applies per-connection jitter automatically // Python: use max_lifetime with a randomized offset in your pool factory 期待される結果: 接続のリサイクルが個々の接続にわたって時間的に均等に分散し、新しい接続リクエストが 1 秒あたり 100 のレートクォータを十分に下回った状態を保てます。 戦略 3: プールサイズを最適化する Amazon Aurora DSQL は多数の同時接続でも高い性能を発揮しますが、スループット、レイテンシー、リソース消費のバランスをとれるようにプールサイズを設定する必要があります。 表 3: 接続プールのサイズ設定パラメータの推奨初期値 パラメータ 推奨初期値 理由 最小プールサイズ 2〜5 接続 低負荷時にリソースを無駄にせず、プールをウォームに保つ 最大プールサイズ アプリケーションインスタンスあたり 10〜20 控えめに始める。アプリケーションインスタンスを追加してスケールアウトする 接続タイムアウト 30 秒 トラフィックが多いイベント中に、DSQL の接続バーストキュー (100/秒) を消化できるようにする アイドルタイムアウト 無効 (または MaxConnLifetime に合わせる) アイドル接続にコストはかからない。開いたままにしておけば、再接続時の不要な TLS/認証の負荷を避けられる Amazon CloudWatch で DPU (Distributed Processing Unit) の消費を監視し、容量の追加が必要なタイミングを把握します。トラフィックの急増が予想される場合 (スケジュールされたバッチジョブやマーケティングキャンペーンなど) は、事前にプールをウォームアップしておきます。インスタンスあたりの接続数を増やすのではなく、小さめのプールを持つアプリケーションインスタンスを増やして水平方向にスケールアウトします。Amazon Aurora DSQL は、短期的な負荷増加には垂直スケーリングで、長期的な変動にはフリート全体の水平スケーリングで対応します。クラスターあたり 10,000 同時接続のクォータを活用し、必要であれば AWS Support に連絡して上限を引き上げてください。 期待される結果: ワークロードに合わせてプールが適切にサイズ設定され、接続の負荷とプール枯渇エラーの両方を最小限に抑えられます。 戦略 4: マルチリージョンでのプーリングの考慮事項 Amazon Aurora DSQL のマルチリージョン active-active デプロイを使うグローバル分散アプリケーションでは、接続プーリングにもう一段の検討が必要です。 このサービスのマルチリージョンアーキテクチャでは、SQL の実行、読み取り、書き込みのスプーリングをクライアントのリージョン内でローカルに処理します。リージョン間の通信は、コミット時に Adjudicator と Journal のレプリケーションプロトコルを通じてのみ発生します。マルチリージョンモードでも読み取りはローカルなので、読み取り専用トランザクションはリージョン間のレイテンシーなしで完了します。読み書きトランザクションでリージョン間レイテンシーが発生するのは COMMIT 時のみで、実行した SQL ステートメントの数に関係なく、リージョン間のラウンドトリップ約 1〜1.5 回分です。各ステートメントごとにラウンドトリップが発生する転送ベースの設計と比べ、レイテンシーを削減できます。リージョンの選択も重要です。接続性の良いリージョンの組み合わせほどコミットレイテンシーが低く、地理的に離れた組み合わせほどそれに比例して大きくなります。 マルチリージョンでのプーリングでは、リージョンごとに個別の接続プールを作成し、それぞれローカルの Amazon Aurora DSQL エンドポイントを指すようにします。トークン更新のロジックがリージョンごとの IAM エンドポイントを考慮していることを確認してください。アプリケーションは active-active アクセスを前提に設計します。このサービスにはプライマリリージョンという概念がなく、各リージョンは対称的に動作します。 期待される結果: リージョン間レイテンシーはコミット時にのみ発生し、読み取りはローカルリージョンの速度で完了します。 オブザーバビリティ: データベースだけでなく接続プールも監視する Aurora DSQL の CloudWatch メトリクス (TotalTransactions や CommitLatency など) はデータベースレベルの挙動を示しますが、接続プールがボトルネックかどうかまではわかりません。プールの健全性を把握するには、アプリケーション側に計測を組み込む必要があります。次に挙げるクライアント側のメトリクスが、接続プーリングの問題を捉える重要なシグナルです。 アプリケーションに組み込むべきメトリクス メトリクス 示す内容 アラートのしきい値 発生時のアクション プール取得レイテンシー (.get() の所要時間) プールから接続を取得するまでアプリケーションが待つ時間 P95 > 500 ms プールが飽和している。最大プールサイズを増やすか、アプリケーションインスタンスをスケールアウトする アクティブ接続数 現在トランザクションを実行中の接続数 最大プールサイズに張り付いている すべての接続が使用中。プールサイズを増やすか、トランザクションの実行時間を短くする アイドル接続数 プール内で使われていない接続の数 0 のまま張り付いている トラフィックのバーストに対する余裕がない。最小プールサイズを増やすか、急増が予想される前にウォームアップする リクエストの同時実行数 対 プールサイズ 処理中の同時リクエスト数と最大プールサイズの比率 同時実行数が最大プールサイズの 80% を超える プール枯渇に近づいている。スケールアウトするか、プールサイズを増やす プール枯渇イベント 利用可能な接続を待って接続リクエストがタイムアウトした回数 > 0 直ちに対応が必要。プールサイズを増やす、トランザクションの実行時間を短くする、またはアプリケーションインスタンスを追加する 接続作成レート プールが 1 秒あたりに開く新規接続の数 100/秒 に近づく Aurora DSQL のレート制限に達するリスクがある。ジッターを加える、インスタンスの起動をずらす、または最小プールサイズを増やして接続の入れ替わりを減らす ほとんどの接続プールライブラリは、これらの統計をネイティブに公開しています。 Java (HikariCP): HikariPoolMXBean を使って getActiveConnections() 、 getIdleConnections() 、 getThreadsAwaitingConnection() 、 getTotalConnections() にアクセスします。Micrometer 経由で CloudWatch やアプリケーションパフォーマンスモニタリング (APM) ツールにエクスポートします。 Python (psycopg ConnectionPool): pool.get_stats() を使います。 pool_min 、 pool_max 、 pool_size 、 pool_available 、 requests_waiting 、 requests_num を返します。 Node.js (node-postgres): pool.totalCount 、 pool.idleCount 、 pool.waitingCount に直接アクセスします。一定間隔で、またはリクエストごとに出力します。 Go (pgxpool): pool.Stat() を使います。 AcquireCount() 、 AcquiredConns() 、 IdleConns() 、 TotalConns() 、 AcquireDuration() を提供します。 これらはカスタム CloudWatch メトリクスとして発行するか ( PutMetricData API またはログ内の CloudWatch Embedded Metric Format を使用)、既存の APM ツール (AWS X-Ray、Datadog、Prometheus/Grafana など) に送信します。 補足: Aurora DSQL の CloudWatch メトリクス 主要なシグナルはクライアント側のメトリクスであるべきですが、プールサイズを決めるうえで役立つ Aurora DSQL のメトリクスが 1 つあります。 メトリクス プーリングに役立つ理由 TotalTransactions プール取得レイテンシーと関連付けて見ます。トランザクションが増えているのに取得レイテンシーが横ばいなら、プールサイズは適切です。両方が増えているなら、容量の追加が必要です。 よくある接続プールの問題のトラブルシューティング アラートが発生したら、この表を使って最もよくある障害シナリオを診断し、対処してください。 表 5: よくある Amazon Aurora DSQL 接続プール問題のトラブルシューティングガイド 症状 考えられる原因 診断ステップ 対処 プール枯渇 (接続タイムアウトエラー) トラフィックに対して maxPoolSize が低すぎる アクティブ接続とアイドル接続を比較して監視する 最大プールサイズを増やすか、アプリケーションインスタンスを追加する 約 55 分後の認証失敗 トークンの失効が処理されていない トークン更新のログを確認する 公式コネクタを使っているか確認する。MaxConnLifetime の設定を確認する 新規接続レートのエラー 起動時の thundering herd 接続作成のタイムスタンプを確認する MaxConnLifetime にジッターを加える。アプリケーションインスタンスの起動をずらす クイックリファレンス: 主要な制限と設定 接続の有効期間、トランザクションタイムアウト、接続レート、同時実行数などの最新の制限については、 Cluster quotas and database limits を参照してください。 まとめ 本記事では、Amazon Aurora DSQL のトランザクション単位のプーリングモデルが従来の PostgreSQL とどう違うかを解説しました。また、コネクタの選択からマルチリージョンでのプーリングまで、アプリケーションの性能と回復力を保つための具体的な 4 つの戦略も紹介しました。PgBouncer や pgpool-II のようなデータベース側のプロキシは使わないでください。このサービスはトランザクション単位の多重化をネイティブに処理します。マルチリージョンのデプロイでは、リージョン間レイテンシーがコミット時にのみ発生することを覚えておいてください。トランザクションはローカルの読み書きを活かせるように設計しましょう。 これらの戦略に従えば、アプリケーションは Amazon Aurora DSQL の自動スケーリング、強整合性、高可用性を最大限に活用できます。接続の負荷を最小限に抑え、大規模でもレイテンシーを予測可能に保てます。 著者について Tejas Dubey Tejas は、 Tejas は AWS のテクニカルアカウントマネージャーで、エンタープライズのお客様が回復力とセキュリティに優れ、AI 対応のクラウドアーキテクチャを構築できるよう支援しています。新しいテクノロジーを実際のビジネス価値に変えることに情熱を注いでいます。仕事を離れているときは、息子を追いかけたり、ピックルボールをしたり、最新のテクノロジーをいじったりしています。 Dhvani Shah Dhvani は、 Dhvani はテクニカルアカウントマネージャーで、クラウドの回復力、セキュリティ、生成 AI の導入に関する戦略的なガイダンスでエンタープライズのお客様を支援しています。デジタルトランスフォーメーションを加速する、スケーラブルで安全なソリューションの設計を支援しています。仕事以外では、旅行やバドミントン、家族と過ごす時間を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。

G-gen の杉村です。当記事では、Google Cloud Next Tokyo 26 の、1日目のキーノートに関する速報レポートをお届けします。 Google Cloud Next Tokyo 26 イベント概要 キーノートの概要 AI による産業の革新 NTTデータの事例 Google の AI エージェントエコシステム Gemini Enterprise のデモ 損害保険ジャパンの事例 Ｓｋｙの事例 スクウェア・エニックスの事例 Agentic Workplace の実現 AI 時代のサイバーセキュリティ 関連記事 Google Cloud Next Tokyo 26 イベント概要 Google Cloud の旗艦イベントである Google Cloud Next の東京版、Google Cloud Next Tokyo 26 は、2026年7月30日（木）と31日（金）の2日間で開催されます。本年は昨年と同様、東京ビッグサイトで開催されました。 東京ビッグサイト ビッグサイト入口 G-gen 社によるセッションレポートは、以下の記事一覧から確認できます。 blog.g-gen.co.jp キーノートの概要 初日のキーノート（基調講演）では、AI の社会実装に向けた Google Cloud の AI エージェントエコシステムの紹介や、Google Workspace を活用した自律的なワークプレイスの実現、そして Gemini Enterprise app を中心としたエンタープライズ企業における導入事例が紹介されました。 今回の講演は、技術的なアップデートや新製品の新発表をするというよりも、過去の Google Cloud Next や Google の関連イベントの発表内容を踏襲し、Google の AI エコシステムの紹介や、エージェンティックな仕事改革といった概念の紹介、また日本国内の Google 製品事例にフォーカスしたものでした。 キーノート会場 AI による産業の革新 最初に登壇したのは、Google Cloud Japan 代表の三上智子氏です。 同氏は、産業革命において電気の発明から産業構造の変革まで30年を要したことと現代の AI ブームを比較します。産業革命では工場の各個別の機械にモーターを組み込んだことで革新が起きたことから、現代でも各個別の業務に AI を組み込んで再設計することでこそ、より速いスピードで革新が訪れるのである、という考えを示しました。 Google Cloud 三上智子氏 AI 利用者の約半数がシャドー AI を経験しているという調査結果について言及し、AI ガバナンスの重要性を強調しました。また2030年に向けて、AI を活用した労働力不足への対策や、個人の「暗黙知」「匠の技」を継承していくことが課題となっていくであろうという展望を示しました。 また従来から強調されているとおり、Google が Gemini モデルや AI アプリケーション、プラットフォームのみならず、TPU といった物理レイヤに至るまで、AI 関連技術をフルスタックで開発していることを強調しました。 Google は AI 関連技術をフルスタックで開発 NTTデータの事例 続いて、株式会社NTTデータの常務執行役員 テクノロジーセグメント長 Chief AI Officer、西村忠興氏が登壇しました。 同氏は、NTTデータが2026年6月に Google Cloud と包括契約を締結し、 Google Workspace と Gemini Enterprise を大規模に活用していくことを決定したと述べました。提供者自らが最初の顧客としてソリューションを大規模に導入・活用する「クライアントゼロ」の取り組みを通じてノウハウを蓄積し、顧客へ提供していくとしています。 NTTデータ 西村忠興氏 「クライアントゼロ」 Gemini Enterprise は、Google Cloud が提供する AI エージェント Web アプリケーションです。正式名称は Gemini Enterprise app ですが、多くの公式ドキュメントで単に Gemini Enterprise と言及されていることから、当記事でも Gemini Enterprise の呼称を使用します。 blog.g-gen.co.jp Gemini Enterprise の導入の理由として、 自律的 AI ワークプレイスの実現 というビジョンへの共感や、Google Workspace と Gemini Enterprise が厳格な検証をクリアし、高いセキュリティとガバナンスを備えていることを挙げました。同社は、「チャット型 AI」主体の AI 利用から「自律型 AI エージェント」の利用へと移行し、これを社会に実装することで価値を実現していく考えを示しました。 Google の AI エージェントエコシステム Google Cloud アウトバウンド プロダクト マネジメント ディレクター、リリー・マクニーラス氏が登壇し、Gemini Enterprise Agent Platform などの全体像を解説しました。同氏は、Gemini Enterprise Agent Platform がシンプルさ、安全性、費用対効果を備え、エンタープライズクラスの企業の課題に対処できることを強調しました。 Google Cloud リリー・マクニーラス氏 Gemini Enterprise Agent Platform は、Google Cloud が提供する AI エージェント開発・運用のための統合プラットフォームです。リモート AI エージェントをホストするフルマネージドサービスである Agent Runtime 、エージェントを登録するレジストリとなる Agent Registry 、エージェントの通信制御を担う Agent Gateway のほか、先述の Gemini Enterprise も、Gemini Enterprise Agent Platform のサービス群の1つです。 blog.g-gen.co.jp 同氏は、以下のような紹介を行いました。いずれも新発表ではなく、2026年4月に米国ラスベガスで行われた Google Cloud Next 等のイベントで発表済みのものを、再度強調するものでした。 最新の生成 AI モデル、Gemini 3.5 Flash、Gemini Flash-Lite、Gemini 3.6 Flash、Gemini 3.1 Pro Gemini 3.5 Pro は従来どおり「Coming Soon」 Gemini 3.5 Flash は日本リージョンに対応しており、データ所在の規制要件などに対応可能であること 動画の生成やインタラクティブな編集が可能な Gemini Omni Flash 高度なアルゴリズム開発や課題解決用のエージェントである AlphaEvolve（ロジスティクス、半導体、ゲノミクス向け） 顧客向け（B to C）の AI エージェントを提供する Gemini Enterprise for Customer Experience また、AI と統合されたアプリケーション開発環境である Google Antigravity の企業向けバージョンである Google Antigravity for Enterprise についても再度、紹介されました。Google Antigravity は Gemini Enterprise Agent Platform の API を通じて Gemini モデルなどを呼び出せるようになっており、今後、管理・統制関係の機能も強化されていくことが従来から発表されています。今回の講演では、統制機能に関する詳細やロードマップなどは発表されませんでした。 Gemini Enterprise のデモ Google Cloud のアプライド AI エンジニアである岡本充洋氏により、小売業における Gemini Enterprise のデモが行われました。 同氏は、スーパーバイザーが店舗に臨店し、店舗の状況を音声で記録して報告書を自動作成し、Teams で共有するまでの一連の業務を、Gemini Enterprise の画面から離れずに完了させる様子を実演しました。 また、Gemini Spark を使用し、前日に分析レポートの作成を指示しておき、翌朝に Inbox で結果のレポートを受け取り、PDF として OneDrive に保存するというデモも披露しました。 Gemini Spark は、ユーザーが指示を出すとバックグラウンドで非同期にタスクを処理し、後から結果を得ることができる AI エージェント機能です。2026年7月現在、日本では「数週間以内に個人向けの Google AI Pro プランで利用可能になる」ことが発表されています。 参考 : 「Gemini Spark」： 24 時間 365 日対応する自分だけの AI エージェントが日本の Pro ユーザーにも拡大 Gemini Spark 今回の講演では、Google Workspace や Gemini Enterprise で Gemini Spark が利用可能になるかどうかは明言されませんでした。またイベント終了後の2026年8月3日、複数のユーザーから Google Workspace で Gemini Spark が使用可能になったことが報告されましたが、これは手違いによって一時的に利用可能になったものであり、すぐに使用不可能に（機能が画面に表示されなく）なりました。今後、正式なリリースがあるのかないのか自体、2026年8月初旬現在では不明です。 Gemini Spark 損害保険ジャパンの事例 ＳＯＭＰＯホールディングス株式会社 デジタル・データ戦略部長 兼 損害保険ジャパン株式会社 執行役員 ＣＤＯ ＤＸ推進部長の中島正朝氏が登壇し、既存事業を横断的に DX する「ヨコのDX」における AI 活用事例を紹介しました。 ＳＯＭＰＯホールディングス株式会社 中島正朝氏 同社は、新規事業等における DX を「タテの DX」、既存事業等を横断するものを「ヨコの DX」と位置づけています。 同氏は、Gemini Enterprise 導入の決め手として Gemini Notebook（旧称 NotebookLM）を挙げました。社内の規定類をデータソースとして登録して利用しているほか、会議の録音を自動的に Gemini Notebook に追加することで議事録の作成を不要にした事例を紹介しました。本社公式のノートブックを作成しており、本社へ問い合わせる前にまず AI に確認する習慣が醸成されているとしました。 また、以下のような業務特化型エージェントの市民開発が進んでいることを紹介しました。 モクさぽ（目標設定のためのエージェント） モジおこ（会議の内容を文字起こし） レカみる（レッカー費用などの一次検証） トップダウンでの発信により、AI エージェントの WAU（Weekly Active Users）は80％に達し、AI によって浮いた時間は高付加価値業務に充てられていると述べました。 モクさぽ モジおこ レカみる Ｓｋｙの事例 Ｓｋｙ株式会社の執行役員 太田雅尚氏が登壇し、Gemini Enterprise の全社導入事例を紹介しました。 Ｓｋｙ株式会社 太田雅尚氏 同社では、「コーディング」「検索、質問」「文章作成」などが AI の用途の半分を占めていること、残りの半分が、それらの混合と思われ分類できない「その他」の用途であることを述べました。 AI の用途 同氏は、選定の理由として「処理精度」、「高度な検索」、そして「ガバナンス」を挙げました。導入から5か月間で20,000個のエージェントが作成され、個人の暗黙知やローカルデータの可視化に大きく貢献していると語りました。 スクウェア・エニックスの事例 株式会社スクウェア・エニックスの AI&エンジン開発ディビジョン ジェネラル・マネージャー、荒牧岳志氏が登壇しました。 スクウェア・エニックス 荒牧岳志氏 同氏は、同社における「新しいゲーム体験の創出」と「開発サポート」という2つの異なる場面における AI 活用を紹介し、AI がゲーム画面を見て、考えて、動くことができるマルチモーダル性の重要性を説きました。 Gemini Enterprise Agent Platform を採用し、「ドラゴンクエスト10オンライン」において、ゲーム画面を見て自ら話しかけてくる「おしゃべりスラミィ」を実装した事例を紹介しました。また、開発現場では QA の自動化にも活用されていると述べました。 Agentic Workplace の実現 Google Cloud の Google Workspace プロダクト担当 バイス プレジデント、ユリー クォン キム氏が登壇しました。 Google Cloud ユリー クォン キム氏 同氏は、企業におけるデータの断片化という課題を指摘し、Agentic Workplace の時代が到来したことを述べました。 Workspace Intelligence により分散したデータが統合され、AI に安心して業務を任せられる環境が構築されることを強調しました。 Workspace Intelligence は、2026年4月に発表された、Google Workspace の標準機能です。Gmail、Google ドライブ、Google カレンダー、Google チャットなどを横断して、AI が情報を収集し、コンテキストとして使用してユーザーのタスクを実行します。Gmail 等のサイドパネルで AI に指示をするだけで、これらのアプリを横断した情報収集とタスクの実行が可能です。 参考 : 生成 AI 機能の Workspace Intelligence を制御する 加えて、以下のような実例が紹介されました。 朝、Gmail から優先して読むべきメールをピックアップし、自然言語で質問するとファイルを検索してサマリを表示 Sheets Canvas を使用し、スプレッドシート上で AI がカンバンボードなどのミニアプリを自動作成 Google Meet で、複数言語で会話してもお互いの言語へリアルタイムに AI 同時翻訳を実行 Sheets Canvas で作成されたカンバンボード 続いて、カスタマー エンジニアである服部淳氏によるデモが行われました。Google Pics での画像編集や、Slides のサイドパネルから指示を出して Google チャット、Gmail、Google ドキュメントなどの情報を読み取り、Google スライドで資料を自動生成する様子が紹介されました。 AI を使ったスライドの作成と編集 なお Google Pics とは、AI を使った画像編集ツールです。近日中に Google Workspace で使用可能になることが発表されています。 参考 : Google Pics: AI 画像生成および編集ツール | Google Workspace AI 時代のサイバーセキュリティ 最後に、三上智子氏が再び登壇しました。 同氏は、AI 時代におけるサイバーセキュリティの重要性を強調し、 AI Threat Defense とその機能の一部である CodeMender を紹介してキーノートを締めくくりました。 CodeMender AI Threat Defense は、Google が提唱する AI エージェントを活用したセキュリティフレームワークです。AI モデルである Gemini、セキュリティ製品である Wiz、ソースコードの脆弱性修復エージェントである CodeMender、脅威インテリジェンスである Mandiant を組合わせて、セキュリティを向上させる考えです。 参考 : Google AI Threat Defense 発表：攻撃者の先を行くために 関連記事 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

商社系DX組織3社（Digital Experts様、MBKデジタル様、Insight Edge）が集まり、AI活用戦略から組織改善の取り組みなど互いの知見を共有する情報交流会を開催しました。 ※本記事では、企業名を併記する際は、Insight Edge以外をアルファベット順に記載しています（各社の取り組みLTは発表順）。 今回はInsight Edgeが発起し、CTO猪子のリードのもと、この記事の筆者の肥塚が共有会の企画や運営を行わせていただきましたので、共有会を企画するに至った経緯、共有会の内容、企画・運営した際の学びを共有させていただきます。 Insight Edgeについて Insight Edge（弊社）は、住友商事グループのDX内製組織として https://insightedge.jp/business/ で紹介されている通り、総合商社のDX施策を非常に幅広い面から支援・実装しています。 ソフトウェアエンジニア、データサイエンティスト、プロジェクトマネージャー、コンサルタント、デザイナーなど幅広い人材が所属し、価値を共創していることが特徴です。 今回の交流会の企画に至った経緯について 弊社は、住友商事グループのDX内製組織ですが、他の総合商社グループにも技術面から価値創造を行っている企業様がいらっしゃいます。 それらの企業様と組織改善のヒントを互いに伝え合う手段が欲しいという声が上がったため、丸紅グループのDigital Experts様、三井物産グループのMBKデジタル様と共に、今回の「商社系企業情報交流会」の企画に至りました。 交流会の概要について 以下の要領にて実施しました。 場所: MIRAI LAB PALETTE 日時: 2026年5月21日 参加企業: Digital Experts様、MBKデジタル様、Insight Edge 参加人数: 42名 ※参加企業は、Insight Edge以外をアルファベット順に記載しています。 アジェンダ 以下のアジェンダにて実施しました。 オープニング 弊社CTO猪子からご挨拶 各社の概要紹介 各社の取り組みLT 立食 クロージング 弊社CEO小坂からご挨拶 立食形式にて皆さんにご歓談いただきましたが、大変盛況でした！ 立食の様子。写真は参加者の許可を得て掲載しています。 各社の取り組みLTについて アジェンダの中でも、各社の取り組みLTでは各社のカラーがよく出ていたので、ご紹介いたします！ ※本記事に記載されている他社製品情報は公開情報です ※各社の取り組みLTは、発表順に記載しています。 MBKデジタル様のご発表 MBKデジタル様のCTO岩尾様から 「AI モデルが賢くなるほど強くなる組織をつくる — 情報資産・プロダクト・プロセスの設計 —」 という題にてご発表いただきました。 従来はAIの新しいモデルやツールを個別に追いかけるのが主流でしたが、MBKデジタル様では会社としてAIの進化を享受しやすいように、以下の点にて整備を行っているということでした。 情報資産 議事録、案件情報、商談履歴などのデータをAIが読める形に蓄積し、後でAIが活用しやすくする プロダクト AIの進化を会社の提供価値とするべく、データからAIが自然言語で示唆出しを行う「BI Suite」や、業務に特化したAIアプリをGUIで構築できる「AI Craft」を開発・外販している 開発・業務プロセス 実装などの開発プロセス、資料づくりなどの業務プロセスを人間が最初からやるのではなくAIに実行させ、人間は「判断・検証・説明責任」に寄せる Digital Experts様のご発表 Digital Experts様の技術部長の松原様から 「組織強化の観点から見るDigital Experts の取り組み - 制度・技術・人財」 という題にてご発表いただきました。 「内製組織」と「外部展開」の2つを支える軸として「組織強化」を据え、以下の観点についてご共有いただきました。 社内プロセス改善 制度をプロダクトとして捉え、継続的にアップデートする トップダウンではなく、全員がフラットに議論してその場で決める、現場発の意思決定 技術カルチャー 2週間に1回の頻度で持ち回りでLT会を行う AIを業務に導入。有志でプロトタイプ開発を行い、効果検証後に標準化 丸紅グループ全体に展開されたMarubeni Chatbot 外部展開体制の強化 内製したプロダクトの外販を行う。限られたリソースで運用するべく自動化や生成AIの利用を徹底すると共に、商社の幅広い販売チャネルを活用 FTO調査や自社特許の取得促進などの知財戦略の強化 採用 生成AIを活用した自走力の高い方を採用する一方、心理的安全性を担保する組織づくり Insight Edge 弊社では「みんなでやる」精神のもと、市川とニャットの2名にて発表を行いました。 市川からは「技術向上WGの取り組み」、ニャットからは『「やってみる?」のひとことから始まった、初めてのアドベントカレンダー』という題で発表いたしました。 技術向上WGの取り組み 業務で利用するLLM周辺領域をテーマに、ケイパビリティ向上や認知拡大、客観的な技術力の証明を目的とした取り組みを紹介しました。 特に言語処理学会第32回年次大会（NLP2026）においては、Insight Edgeは大手企業を上回る7件の発表（参加企業中5位、社内集計より引用）を行い、注目を集めました。 「やってみる?」のひとことから始まった、初めてのアドベントカレンダー 2025年度にテックブログのアドベントカレンダーに挑戦した時の取り組みを紹介しました。記事のレビューエージェントや企画を盛り上げるSlackボットなど、ユニークな施策のもとアドベントカレンダーを無事に完走し、Insight Edgeのバリューである「やってみる」「みんなでやる」「やり抜く」を体現した企画でした。詳細は こちら からご覧ください。 交流会実施の結果 実施後、Insight Edgeの参加者に対してアンケートを行いました。 発表や食事含めて大変好評でした。 Insight Edge社内アンケート結果（2026年5月実施） いくつかの声をご紹介します。 Digital Experts様、MBKデジタル様が推進している自社プロダクトの外販について興味を示す声が多いのが印象的でした。 各社の変遷やその中での課題についてInsight Edgeと通ずるものがあり参考になりました。 生成AIの社内業務活用の例をもっと聞きたかったです。 このように、各社の多彩な取り組みに興味を示す声がとても多く寄せられました。 個人的には、LTをお聞きし、OAMチームの一員として保守運用における生成AI活用深化や社内事例の整備を行っているので、とても参考になりました。 ご参加いただきましたDigital Experts様、MBKデジタル様につきましても、情報交換する中で刺激になったためまたご相談させてほしいという声や、同業他社でありながら異なる規模の会社の話を聞けて面白かったという声をいただきました。 交流会実施の感想 今回の商社系企業情報交流会では、CTO猪子のリードのもと、自分が運営全般業務や司会を担当しました。 Insight Edge内外の皆さんが、準備や後片付けに快くご協力くださり、大変ありがたく感じました。 また、発表時やご歓談時は大変盛り上がり、商社らしいなあと感じました。 特にLT発表会では、「AI技術をどう使い、自社、ひいては自社グループの価値創造に貢献するか？」という点に各社それぞれのカラーが出ていて興味深かったです！ 次回実施する機会があれば、またぜひ運営に参加したいと思います。 一緒に価値を創る仲間を募集しています 今回の交流会を通じて改めて感じたのは、生成AIの進化によって技術そのものは急速に変化していく一方で、組織として学び続け、挑戦し続ける文化こそが競争力になるということです。 技術を磨くだけではなく、 新しい技術を実際の事業価値につなげたい方 生成AI時代のエンジニアリングやデータ活用のあり方を一緒に切り拓いていきたい方 そんな方とぜひ一緒に働きたいと考えています。 少しでもInsight Edgeに興味を持っていただけた方は、ぜひ採用ページもご覧ください。カジュアル面談も歓迎しています。 👉 https://herp.careers/v1/insightedge 今後も、このような企業間の交流を通じて得られた知見を積極的に発信し、日本全体のDX・AI活用の発展にも貢献していきたいと思います。