Spanner Omniとは？自前環境で動くSpannerの導入手順・要件・エディションと採用判断を実装者目線で解説

Spanner Omniは、Google Cloudの分散データベースSpannerを、オンプレミスや他社クラウド、手元のノートPCで動かすためのダウンロード版です。マネージドサービスとしてのSpannerの仕組みや料金の数え方はCloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説にまとめてあります。この記事ではそこから提供形態だけを切り出し、マネージド版との差分、システム要件、Dockerでの起動とクライアント接続の手順、エディションごとの無償範囲を、着手前に確かめる順序で整理しました。

まとめ｜Spanner Omniは自前環境で動くSpannerで、本番は有償ライセンスが前提

• Spanner Omniは、Paxosによる同期レプリケーションと自動シャーディングをそのまま持ち込み、原子時計に頼るTrueTimeだけをソフトウェア実装へ置き換えたダウンロード版です。
• マネージド版と比べると、SLAが無く、APIはgRPCのみ、クライアントはJava・Go・Pythonの3言語に限られます。BigQuery連携やData Boostなど13項目は使えません。
• 試すだけならDockerで1コマンドです。単一サーバーかつ4 vCPU以下のDeveloper editionは期限なしで使えますが、複数サーバー構成は90日で書き込みが止まります。
• 本番はCommercial editionのvCPU単位の年間サブスクリプションが必要で、金額は公開されておらずGoogleへの問い合わせで決まります（2026年10月時点）。
• 採用してよいのは「Google Cloudの外で、強い整合性と水平スケールを両方求める」要件が先にあるときです。SLAを契約で求める基幹系では見送ります。

Spanner Omni｜Cloud Spannerとの差とソフトウェア版TrueTime

公式のSpanner Omni overviewは、本製品を「deploy-anywhere version of Spanner」と説明しています。水平スケール・高可用性・ACID準拠・強い外部整合性という中核の性質は、Paxosベースのレプリケーション、自動シャーディング、ソフトウェア定義のTrueTime APIで実現する、という整理です。2026年4月のプレビュー公開を経て、2026年9月30日にGoogle Cloudが正式版のリリースを発表しました（Publickeyの報道）。

配置できる範囲｜オンプレミス・他社クラウド・ノートPCへ置くダウンロード版

配置先として公式が挙げるのは、自社データセンター、Google CloudやAWSなどのパブリッククラウド、そして開発者のノートPCです。デプロイ方式は仮想マシン、Linuxコンテナ、Kubernetesクラスタの3つで、GKE・Amazon EKS・Amazon EC2での動作が明記されています。データモデルはリレーショナルに加えてキーバリュー・グラフ・ベクトルを扱え、モデルをまたいだクエリやACIDトランザクションも書けます。Spannerの論文に由来するTrueTimeは、本来GPS受信機と原子時計に支えられた仕組みでした。Omniではこれをどの環境にも置けるソフトウェア実装へ置き換え、外部整合性の保証を維持しています。

マネージド版との差分｜SLAなし・gRPCのみ・3言語に限られる接続

公式のDifferences between Spanner and Spanner Omniに差分がまとまっています。実装者が最初に押さえるべきは次の4点です。

公式は「Availability depends on your infrastructure and configuration」と明記しており、可用性の責任は配置する側へ移ります。また各デプロイには instances/default というインスタンスが1つだけ事前に作られ、マルチテナンシーには対応しません。複数チームで1つのクラスタを分け合う設計は、データベース単位で分けるしかない点に注意してください。

使えない機能の一覧｜BigQuery連携やData Boostなど13項目の扱い

同じ差分ページには、Omniで非対応の機能が列挙されています。BigQuery連携（フェデレーション・外部スキーマ・リバースETL）、Gemini Enterprise Agent Platform連携、MODEL DDLとML・AI関数、Data Boost、Knowledge Catalog連携、ジオパーティショニング、全文検索の拡張クエリモード、大規模な近似最近傍検索、階層型ストレージ、増分バックアップ、組み込みのCMEK連携、デュアルリージョンの自動再構成、スケールアップ型グラフアルゴリズムの13項目です。

影響が大きいのはBigQuery連携です。マネージド版で組める連携クエリや変更ストリームの経路（Cloud SpannerとBigQueryの連携方法｜外部データセット・連携クエリ・変更ストリームの使い分けで解説）を前提にした分析基盤は、Omniでは別の取り込み処理を自分で用意することになります。

システム要件とトポロジの決め方｜単一サーバーから複数リージョン構成まで

導入で最初に詰まるのは、検証機のスペックと台数の見積もりです。要件とトポロジは同じoverviewページにまとまっています。

動作環境の下限｜RHEL 9・Ubuntu 22とvCPUあたり4GBのメモリ

ストレージは専用SSDとext4ファイルシステムが推奨されています。共有ストレージや性能の読めないネットワークディスクの上で評価すると、Paxosの同期書き込みがディスク待ちで伸び、Spanner本来の書き込み性能を見誤ります。Windowsは要件に挙がっていないため、試すならLinuxの仮想マシンを用意してください。

4つのトポロジの選び方｜単一サーバー・単一ゾーン・複数ゾーン・複数クラスタ

構成はリージョン・ゾーン・サーバーの3階層で表し、公式は4つのトポロジを示しています。

1. 単一サーバー：開発用途。更新のたびに停止を伴います。
2. 単一ゾーン：最低3台。ゾーン障害でサービスが止まり得ます。
3. 複数ゾーン（リージョナル）：最低3ゾーン、各ゾーン1台以上。推奨は各ゾーン3台以上です。
4. 複数クラスタ（マルチリージョナル）：2つ以上のクラスタにまたがる3ゾーン構成で、各ゾーン3台以上を推奨しています。

本番の下限は複数ゾーン構成と考えるのが実務的です。推奨どおり各ゾーン3台なら9台、vCPU単位で課金されるライセンス費もこの台数から積み上がります。検証段階から「何台・何vCPUで本番を組むか」を決めておかないと、後の見積もりで桁がずれます。

Dockerで単一サーバーを起動しサンプルDBにSQLを投げるまでの手順

手元で挙動を確かめる最短経路は、Spanner Omni quickstartのDocker手順です。Set up Spanner Omniによれば前提はsudo権限とDockerのみで、TARファイルからの導入も選べます。

コンテナ起動の手順｜ボリューム作成と2026.r4-ltsタグでの単一サーバー起動

データを残すためのボリュームを先に作り、単一サーバーモードで起動します。2026年10月時点の公式手順が示すイメージタグは 2026.r4-lts です。

docker volume create spanner

docker run -d --network host \
  --name spanneromni \
  -v "spanner:/spanner" \
  us-docker.pkg.dev/spanner-omni/images/spanner-omni:2026.r4-lts \
  start-single-server

docker ps

--network host を付けるため、ホスト側でポート15000〜15025（サーバー）と15026（コンソール）が開きます。既存のサービスとポートが衝突しないか、起動前に確認してください。コンソールは読み取り専用で、データベースやデプロイの変更には使えません。タグは可変の指定に頼らず、検証した版で固定しておくと後の更新計画が立てやすくなります。

サンプルDBで試す手順｜retailサンプル作成からSQLシェルでの確認まで

CLIはコンテナ内の /google/spanner/bin/spanner にあります。Google Cloud CLIとは別の専用ツールで、--instance の指定は要りません。小売を題材にしたサンプルデータベースを作り、スキーマを確かめてからSQLシェルへ入ります。

docker exec -it spanneromni /google/spanner/bin/spanner databases create-sample-db retail --database-name=retail-sample
docker exec -it spanneromni /google/spanner/bin/spanner databases list
docker exec -it spanneromni /google/spanner/bin/spanner databases ddl describe retail-sample
docker exec -it spanneromni /google/spanner/bin/spanner sql --database=retail-sample

SQLシェルで SHOW TABLES; を実行すればテーブル一覧が返ります。quickstartに掲載されているのは、同じサンプルに対して実行する全文検索・COSINE_DISTANCE() によるベクトル検索・GRAPH 句によるグラフクエリの具体例です。マルチモデルを1つのDBで扱える感触は、ここで一通り確かめられます。

GoクライアントとPGAdapterからSpanner Omniへ接続する設定

アプリからの接続は、既存のSpannerクライアントライブラリをそのまま使えます。ただしClient library support for Spanner Omniが述べるとおり、接続文字列と認証方式が違います。

Goクライアント設定｜v1.94.0以上でのType: spanner.OMNI指定

Use the Go client library to connect to Spanner Omniの要件は、Goクライアントv1.94.0以上とGo 1.25以上です。spanner.ClientConfig の Type に spanner.OMNI を指定し、接続先を option.WithEndpoint で渡します。単一サーバーを手元で動かした状態なら、平文接続で次のように書けます。

go get cloud.google.com/go/[email protected]

clientConfig := spanner.ClientConfig{
    Type:         spanner.OMNI,
    UsePlainText: true,
}

databaseClient, err := spanner.NewClientWithConfig(ctx, "DATABASE_NAME", clientConfig,
    option.WithEndpoint("localhost:15000"),
)
if err != nil {
    // エラー処理
}
defer databaseClient.Close()

DATABASE_NAME にはデータベースのリソース名を渡します。公式の規定では、ライブラリから project と instance の指定を要求された場合、それぞれの項目に渡す値は、どちらも共通で default です。本番でTLSを使う場合は UsePlainText を外して CaCertificateFile を、mTLSなら加えてクライアント証明書と秘密鍵のパスを設定します。プレビュー期の記事にある実験的ホスト指定の書き方は旧方式なので、新規実装では上の形に揃えてください。

PostgreSQL方言での接続｜PGAdapterの3つのセキュリティモードと使い分け

PostgreSQLのワイヤプロトコルで接続したい場合は、Connect using PGAdapterのプロキシを挟みます。セキュリティモードは平文・TLS・mTLSの3種類です。TLSではSpanner OmniのCA証明書をJavaの既定のtruststoreへ追加し、mTLSではクライアント証明書と秘密鍵の両方を用意します。Java以外のアプリから接続する場合やpsqlから手で操作する場合に必要なのは、PGAdapterをスタンドアロンのプロセスとして起動する構成です。既存のPostgreSQL向けツールを流用できる反面、プロキシ1段分の運用は増えます。

Kubernetesへの展開｜公式HelmチャートでGKE・EKS・AKSへ載せる流れ

複数サーバー構成を組むなら、公式のHelmチャートが出発点です。Kubernetes自体の構造はKubernetes（クバネティス）とは？メリット・デメリットと仕組み、Dockerとの違いを解説で扱っています。

公式リポジトリの中身｜Helmチャートと5種類のトポロジ別サンプル

GitHubのGoogleCloudPlatform/spanner-omniはApache License 2.0で公開されています。中身はHelmチャート本体、GKE・EKS・AKS向けの値ファイル、そしてsingle-server・regional・scaleout・multi-region・multi-cloudという5つのトポロジ別サンプルです。プラットフォームは --set global.platform=<platform> で切り替えます。PrometheusとGrafanaとJaegerを含む監視用サブチャートも任意で有効化でき、READMEにはTLSとmTLSの有効化、段階的なアップグレードの手順が載っています。

本番前に自分で組む部分｜TLS・mTLS・保存時暗号化と認証方式の設定

マネージド版でGoogleが肩代わりしていたセキュリティの層は、Omniでは全て利用者側に戻ります。差分ページによると、保存時の暗号化は組み込みで提供されず、ディスクかファイルシステムの層で設定が必要です。通信はTLS 1.3とサーバー間のmTLSを自分で構成し、認証はOPAQUEプロトコルによるパスワードかクライアント証明書を使います。認可はIAMに似た独自のロール体系で、カスタムロールは作れません。ネットワーク境界はファイアウォール設計で作り、監査や認証取得の要件も実行環境側で満たします。

エディションとライセンス｜Developer editionの無償範囲と商用版の課金単位

費用構造はマネージド版の従量課金とまったく別物です。Spanner Omni editions overviewの条件を、検証計画に入る前に読んでおくと手戻りがありません。

Developer edition｜4 vCPU以下の単一サーバーの無期限利用条件

90日を過ぎても読み取りはできますが、書き込みは止まります。永続ライセンスキーは無償で申請できる一方、譲渡できず単一デプロイに限られ、適用するとバックアップと復元が使えなくなります。プレミアムサポートとワーカー機能はDeveloper editionに含まれません。複数ゾーン構成での障害試験は90日の枠内で終える段取りにしてください。

Commercial editionの課金｜PoCは四半期・本番は年間のvCPU単位

有償のCommercial editionには2種類のライセンスがあります。本番に近い規模で評価するProof of conceptはvCPU単位の四半期課金で90日で失効し、本番向けのCommercial licenseはvCPU単位の年間サブスクリプションです。どちらもデータ保護機能を含む全機能を規模の制限なく使え、本番ライセンスにはCloud Customer Careのプレミアムサポートを追加できます。単価は公開されておらず、購入と延長はGoogleの問い合わせ窓口を通します（2026年10月時点）。同系列のAlloyDB Omniとは？自前環境で動かす導入手順・要件・ライセンスと採用判断を実装者目線で解説が製品ページで月額のvCPU単価を示しているのとは扱いが違い、見積もりの初期段階から窓口との調整期間を見込む必要があります。

Spanner Omniの採用条件とCloud Spanner・別DBを選ぶ判断軸

ここまでの差分と費用を踏まえ、採否を条件付きで言い切ります。

採用してよい条件｜Google Cloud外での強整合と複数クラウドにまたがる可用性

Omniを採るべきなのは、次のどちらかが要件として先にあるときです。1つは、規制やデータ所在の都合でGoogle Cloudの管理下へデータを置けないが、複数行トランザクションの強い整合性と単一サーバーを超える水平スケールは譲れない場合。もう1つは、AWSと自社データセンターのように複数の基盤へ1つのデータベースをまたがせ、特定クラウドの障害に耐える構成を組みたい場合です。いずれも「マネージド版では要件そのものを満たせない」という理由であり、費用差を動機にした選択とは性質が違います。同じ「どこでも動く分散SQL」の候補としては、CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説やYugabyteDBとは？分散SQLの仕組み・YSQLのPG15系移行と採用判断を実装者目線で解説も並びます。Spannerのスキーマ設計やGoogleSQLの資産を持っているならOmni、PostgreSQL互換の広さを優先するならこの2製品、という順で比べてください。

見送るべき場面｜SLAが要る基幹系とBigQuery連携が前提の分析基盤

見送る判断も明確です。取引先や社内規程が稼働率をSLAとして求める基幹系では、SLAの無いOmniは選べません。Google Cloud上に置けるなら、マネージド版のSpanner（Cloud Spannerとはで採否の条件を整理）を選ぶほうが運用負荷も契約面も素直です。BigQuery連携やData Boostで分析と運用を同じデータで回す設計も、非対応項目に当たるため成り立ちません。そもそも単一サーバーに収まる規模なら、Paxosの台数とvCPU課金を背負う理由はなく、Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説で扱ったマネージドRDBか素のPostgreSQLで足ります。既存DBからの移行可否やトポロジの台数見積もりを含めて検討したい場合は、データベース設計・移行支援で現行スキーマの棚卸しからご相談いただけます。

よくある質問

Spanner Omniの導入前に出やすい質問を5つ取り上げます。

Spanner Omniは無料で使えますか？

Developer editionは無償です。単一サーバーかつ4 vCPU以下なら期限なしでバックアップも含めて使えます。複数サーバーや4 vCPU超の構成は90日で書き込みが止まるため、継続利用には無償の永続キー申請か有償のCommercial editionが必要です。本番・商用利用はCommercial editionのライセンスが前提になります。

Cloud Spannerのデータベースをそのまま移せますか？

SQL方言はGoogleSQLとPostgreSQLの両方に対応しているため、スキーマとデータの移行自体は設計できます。ただしBigQuery連携、MODEL DDL、ジオパーティショニングなど13項目の非対応機能を使っている部分は動きません。移行前に差分ページの一覧と自社の利用機能を突き合わせてください。

Windowsのパソコンで試せますか？

公式のシステム要件に挙がっているのはRHEL 9・Ubuntu 22とmacOS（M1〜M3）で、Windowsは含まれていません。Windows環境で試す場合は、Linuxの仮想マシンを用意してその中でDockerを動かす構成にしてください。開発機の推奨はメモリ4GB・ディスク10GBです。

どのプログラミング言語から接続できますか？

公式に対応しているクライアントライブラリはJava・Go・Pythonの3つで、APIはgRPCのみです。Node.jsなど他の言語から使う場合や、psqlなどPostgreSQL向けのツールを使う場合は、PGAdapterをスタンドアロンで起動してPostgreSQLのワイヤプロトコル経由で接続します。

TrueTimeは原子時計がなくても正しく動きますか？

Omniはハードウェアの時計ではなく、ソフトウェア定義のTrueTime APIで強い外部整合性を維持すると公式に記載されています。どの環境にも置けるよう設計された実装で、利用者が原子時計やGPS受信機を用意する必要はありません。時刻同期の精度は配置するサーバー側のNTP運用にも左右されるため、基盤の時刻設定は事前に確認してください。

関連記事

• Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説
• AlloyDB Omniとは？自前環境で動かす導入手順・要件・ライセンスと採用判断を実装者目線で解説
• Cloud SpannerとBigQueryの連携方法｜外部データセット・連携クエリ・変更ストリームの使い分け
• Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説
• Kubernetes（クバネティス）とは？メリット・デメリットと仕組み、Dockerとの違いを解説