G-gen の菊池です。Gemini Enterprise のサブスクリプションでライセンス数を削減しようとした際に直面するエラーと、その解決策について解説します。 事象 原因 ライセンス削減の仕様制限 サブスクリプションを新規作成する際の壁 対処の手順 概要 手順1: 自動更新の停止 手順2: 契約の期限切れを待つ 手順3: 新しいサブスクリプションの購入 手順4: ライセンスの自動更新 事象 Google Cloud の請求先アカウントに紐づく、Gemini Enterprise のサブスクリプション（月間プラン、または年間プラン）を利用している環境を想定します。 利用者の減少などにより、不要になったライセンス分の課金を停止したいケースがあります。公式ドキュメントでは、Google Cloud コンソールのサブスクリプションの詳細画面からライセンス数の更新が可能であると記載されています。この画面からライセンス数を 増やす 場合は、問題なく変更を保存できます。 しかし、同じ画面でライセンス数を 減らそうと した際、以下のエラーが表示され、変更を保存できない事象が発生しました。 ライセンス数は、現在のライセンス数以上である必要があります 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Update subscription settings なお、Gemini Enterprise の正式名称は Gemini Enterprise app ですが、公式ドキュメントでも多くの場合で単に Gemini Enterprise と記載されているため、当記事でも Gemini Enterprise の名称を採用します。 原因 ライセンス削減の仕様制限 公式ドキュメントを確認すると、2026年8月現在、Gemini Enterprise の仕様上、有効なサブスクリプション契約の期間中にライセンスの合計数を減らすことはできないことが明記されています。 参考 : Frequently asked questions about Gemini Enterprise subscriptions and licenses - Can I reduce the license count Can I reduce the license count? No, you can't reduce the license count during an active subscription term. License reductions are only possible when the subscription term ends or is up for renewal. (引用者訳: いいえ、有効な契約期間中はライセンス数を減らすことはできません。ライセンス数の削減は、契約期間が終了するか、更新時期が近づいた場合にのみ可能です。) また、Gemini Enterprise では、途中解約、残期間分の支払いの免除や返金もできません。 そのため、契約途中に実際の利用人数に合わせて、Google Cloud コンソールの画面からライセンス数を減らすことはできません。なお、契約期間中であってもライセンス数を 増やす ことは可能です。 ライセンス数を減らすには、現在のサブスクリプションの自動更新をオフにして、契約期間が切れてから、適切なライセンス数で 新しいサブスクリプションを作成 する必要があります。 この対応は、月間プランであれば月単位で各月の契約満了時に実施でき、年間プランであれば年単位になります。 サブスクリプションを新規作成する際の壁 前述の通り、ライセンス数を減らすには「現在の契約が切れてから新規購入する」必要があります。しかし、Google Cloud コンソールでサブスクリプションを購入する際、契約の開始日を選択する項目はありません。未来の開始日を指定してサブスクリプションを予約購入することはできず、購入が完了した日から即座に有効になります。 よって、ライセンス数を減らして新しいサブスクリプションを購入しようとすると、古い契約が失効してから新しい契約を購入するまでの間に、Gemini Enterprise が利用できない空白期間が発生することになります。 そこで、このリードタイムをなくすための代替案として、「一時的な重複課金を許容してでも、元の契約期間がわずかに残っている時点で、あらかじめ少ないライセンス数の新しいサブスクリプションを購入しておく」というアプローチが考えられます。 しかしこの代替案にも、 Subscription already exists エラー というシステム上の仕様が存在するため、 実現できません 。 Gemini Enterprise のサブスクリプションは、プロジェクト単位ではなく、請求先アカウントレベルで管理されます。 同一の請求先アカウント内において、「同じエディション（例: Standard）」かつ「同じ期間（月間または年間）」のサブスクリプションを重複して保持しようとすると、Subscription already exists エラーが発生し、購入がブロックされます。 例えば、別プロジェクトでサブスクリプションを管理したいといった理由で、既存契約とは別のプロジェクトにサブスクリプションを新規作成しようとした場合であっても、同様にエラーが発生します。重複はあくまで、請求先アカウントのレベルでチェックされるからです。 単に別プロジェクトで Gemini Enterprise を利用したい場合であれば、既存サブスクリプションのライセンスを別プロジェクトへ配布（Distribute）することで対応できます。しかし、今回のように「ライセンス数を削減したい」という目的を達成するためには、配布による運用では対応できないため、次章で解説する手順が必要です。 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Distribute licenses 対処の手順 概要 前述のエラーと仕様制限を回避してライセンス数を削減するには、 現在のサブスクリプションが失効するのを待ってから新規購入 する必要があります。 この手順を採用する場合、契約期間が満了して古い契約が失効してから、新しい契約を購入するまでの間、Gemini Enterprise が利用できない空白期間が発生します。 その点に留意したうえで、以下の手順を実施します。 手順1: 自動更新の停止 Google Cloud コンソールの「サブスクリプションを管理」画面から、現在のサブスクリプションの [ 編集 ] を開きます。自動更新が有効なままだと、削減前のライセンス数のまま次回の契約が更新されてしまうため、自動更新をオフに設定し、現在の契約期間の満了を待ちます。 手順2: 契約の期限切れを待つ サブスクリプションの契約期間が終了し、完全に失効（Expired）状態になるのを待ちます。契約期間が満了するまでは新規購入がエラーとなります。 手順3: 新しいサブスクリプションの購入 既存契約の失効を確認した後、削減後の必要なユーザー数を指定した新たなサブスクリプションを購入します。 手順4: ライセンスの自動更新 ユーザーが Gemini Enterprise を使えない空白期間を最小限にするため、手動での割り当てだけでなく、新しいライセンスが自動的に割り当てられる設定が推奨されます。Google Cloud コンソールの Gemini Enterprise ページから [ ユーザーの管理 ] を開き、以下の設定を行います。 [ ライセンスを自動的に割り当てる ] を選択し、手順 3 で購入した新しいサブスクリプションを指定する。 [ 期限切れのライセンスを自動更新する ] を選択する。 この設定により、古いサブスクリプションの有効期限が切れたユーザーが次にログインした際、新しいサブスクリプションからライセンスが自動的に付与されます。 参考 : Get licenses for Gemini Notebook Enterprise - Automatically transfer users to an active subscription 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

はじめに こんにちは。クラウドエース株式会社 第一開発部の猪野です。 データ活用が当たり前になった昨今、Google Cloud が提供するエンタープライズ向け BI プラットフォーム「Looker（ルッカー）」はご存知でしょうか？ 「Looker って名前は聞くけど、なんだか難しそう……」 そんな Looker 初学者の方 に向けたチュートリアルです。 データポータルとの決定的な違いは「LookML」による一元管理 機能が似ている「データポータル (旧 Looker Studio)」は直感的にグラフを作れる反面、各レポート内に計算ロジックを持たせるため、「A さんと B さんの

株式会社 G-gen の菊池です。Looker では LookML （Looker Modeling Language）を用いてデータモデルを定義しますが、これらのコードはすべて Git リポジトリで管理されます。当記事では、Git 連携の仕組みや品質管理設定について解説します。 Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 開発モードと本番環境の分離 IDE 内での Git 操作 Git リポジトリとの接続方法 概要 HTTPS を使用した接続 SSH を使用した接続 ベア Git リポジトリ デフォルトのワークフロー 概要 開発ブランチへの変更のコミット 開発ブランチを本番環境ブランチにマージする Looker 本番環境への本番環境ブランチのデプロイ 品質と安全性を高める設定 概要 LookML バリデーションの必須化 データテストの必須化 プルリクエスト（PR）の統合 高度なデプロイモード Looker におけるバージョン管理の概要 LookML プロジェクトと Git リポジトリの連携 Looker の LookML プロジェクトは、 Git リポジトリと 1 対 1 に紐づけることでバージョン管理を構成します。バージョン管理構成にすることで、複数人での共同開発や変更履歴の追跡、安全な本番環境へのデプロイができます。 リモートリポジトリが準備できていない場合や素早く開発を始めたい場合は、Looker サーバー上にローカルの Git リポジトリを作成して単独でバージョン管理を開始することも可能です。 参考 : Git 接続の設定とテスト 開発モードと本番環境の分離 Looker には Development Mode （開発モード）と Production Mode （本番環境モード）という 2 つの環境が分離して存在します。 Development Mode は開発者が LookML を安全に編集、テストできる個人のサンドボックス環境であり、各ユーザーには他のデベロッパーに影響を与えない独自の開発ブランチ（dev- で始まりデベロッパー名を含むブランチ）が割り当てられます。 対して Production Mode はすべての一般ユーザーがアクセスする共有環境であり、ユーザーはこの環境でデータモデルを探索しダッシュボードを構築します。デフォルトの構成では、本番ブランチ（通常は master または main）の最新コードが本番環境で実行されますが、高度な設定を用いることで、特定のリリースバージョン（コミットやタグ）のコードを実行するよう厳密に管理することも可能です。 開発モードの場合、画面上部に「現在は Development Mode です。」というテキストが表示されたバナーが配置されます。右上にある「Exit Development Mode（Development Mode を終了）」という部分をクリックすると、本番環境モードへ切り替わり、このバナーは消えます。 開発モードから本番環境モードへの切替 本番環境モードから開発モードへ切り替える場合は、画面左上にあるメインメニューをクリックして開き、メニューの下部にある「Development Mode」をオンにします。開発モードと本番環境モードのオン・オフは、キーボードショートカット Mac : Control + Shift + D / Windows : Ctrl + Shift + D でもすばやく切り替えることが可能です。 本番環境モードから開発モードへの切替 LookML を変更する場合は、開発モードで作業する必要があります。LookML のコードを修正すると、「Save Changes」というボタンが表示されます。 LookMLの修正（例：列名の修正） このボタンをクリックすると変更内容が保存され、作業している個人の開発環境に変更が反映されます。 開発モードのダッシュボード 一方で、すべてのユーザーが共有する本番環境モードには、まだこの変更内容は反映されません。 本番環境モードのダッシュボード 個人の開発環境での変更を本番環境モードのユーザーにも見えるようにするためには、保存した変更を Git に「コミット」し、本番ブランチへ「デプロイ」するバージョン管理のステップを踏む必要があります。 参考 : Development Mode and Production Mode（開発モードと本稼働モード） IDE 内での Git 操作 Looker の統合開発環境（IDE）には、Git コマンドを操作するための GUI ボタン（IDE 右上、またはメインナビゲーションメニューの「Git Actions」パネル）が備わっています。開発者は複雑な Git コマンドを直接入力することなく、ボタン操作のみでコミットやリモートからのプル、本番環境へのデプロイといった一連のワークフローを実行できます。 特に便利なのは、この Git ボタンが現在の開発ステータス（ファイルの変更有無や他の開発者による更新状況など）に応じて、次に必要なアクションのみを動的に表示する点です。これにより、開発者は手順に迷うことなく、安全かつスムーズにバージョン管理を行うことができます。 参考 : Using version control and deploying（バージョン管理機能の使用とデプロイ） 参考 : Git コマンドのリファレンス Git リポジトリとの接続方法 概要 新規にプロジェクトを作成する際、まず Git リポジトリの構成設定を行います。 Git リポジトリは、外部の Git プロバイダと連携する「HTTPS を使用した接続」、「SSH を使用した接続」、または外部連携を行わずに Looker サーバー上にローカルリポジトリを作成する「ベア Git リポジトリ」の 3 つの構成オプションのいずれかを選択できます。 HTTPS を使用した接続 HTTPS 接続では、ユーザー名と 個人用アクセストークン（Personal Access Token） を使用して認証を行います。 運用方法として、プロジェクト全体で 1 つの Git アカウントを共有する設定と、Looker の「ユーザー属性」機能を用いてデベロッパーごとに個別の Git アカウントを使用する設定が選択可能です。 なお、単一の Git アカウントを共有する場合でも、Looker は各デベロッパーの Looker ユーザー名を使用してコミットを行うため、誰が変更を加えたかの履歴は正しく追跡されます。 ただし、注意点として Looker は現在、GitHub の きめ細かい個人用アクセス トークン（Fine-grained personal access tokens） をサポートしていません。そのため、GitHub を利用する場合は、必ず 「Tokens (classic)」 のオプションを使用してトークンを作成してください。 参考 : HTTPS を使用した Git への接続 参考 : GitHub - Managing your personal access tokens SSH を使用した接続 SSH 接続では、 Looker が生成する公開鍵を Git プロバイダー側に登録することで認証を行います。手順としては、 Looker 側で SSH 公開鍵を生成してコピーし、 Git プロバイダーのリポジトリ設定画面で「Deploy Key」として登録します。この際、 Looker からリポジトリへ変更をプッシュできるよう、書き込みアクセスを許可（Allow write access）を有効にする必要があります。 参考 : SSH を使用した Git への接続 ベア Git リポジトリ リモートの Git プロバイダーを準備していない場合や、すぐに開発を開始したい場合、 Looker サーバー上にローカルリポジトリを作成する ベア Git リポジトリ 構成も選択できます。 ただし、ベア Git リポジトリではプルリクエストの作成など一部の機能が使用できないため、あくまで一時的な利用にとどめることが推奨されます。最初はベアリポジトリで開始し、後からリモートの Git プロバイダーへ接続し直すことも可能ですが、その場合は「まだ Git 履歴を持たない空のリポジトリ」に接続する必要がある点に注意してください。 参考 : ベア Git リポジトリの構成 デフォルトのワークフロー 概要 Looker の標準的なデプロイフローは、開発モード（個人の開発ブランチ）での作業から、共通のリモートリポジトリを経由して、本番環境へと反映される一連のステップで進行します。 開発ブランチへの変更のコミット 開発モードで LookML の修正が完了したら、LookML の検証（Validate LookML）ボタンをクリックします。 LookML にエラーが見つからなければ、ボタンは「Commit Changes & Push」に変わります。 エラーがあった場合は、LookML の検証欄にエラー内容が表示されます。 LookMLの検証 「Commit Changes & Push」ボタンをクリックすることで、コミットのメッセージを入力する画面が表示されます。 コミットの内容をメッセージ欄に入力して、「Commit」ボタンをクリックすることで、変更を開発ブランチに保存（コミット）します。 この操作により、作業内容に名前を付けて保存し、後から履歴を追えるようになります。 メッセージを入力してコミット プロジェクトの設定によっては、変更をコミットする前に LookML Validator によるエラー修正や、データテストへの合格が必須となる場合があります。 開発ブランチを本番環境ブランチにマージする コミットされた変更は、共有のリモートリポジトリへプッシュされます。デフォルト設定の Looker では、IDE 上の「本番環境にデプロイ（Deploy to Production）」ボタンをクリックすることで、開発ブランチの内容が本番ブランチ（通常は master または main ）へマージされます。 本番環境にデプロイ Looker 本番環境への本番環境ブランチのデプロイ IDE での「本番環境にデプロイ」操作を行うと、マージに続いて Looker の本番環境（Production Mode）が自動的に本番ブランチの最新コミットを参照するように更新されます。これにより、エンドユーザーが参照するダッシュボードや Explore に最新の定義が即座に反映されます。 本番モード環境のダッシュボード 品質と安全性を高める設定 概要 「プロジェクト構成（Project Configuration）」ページの設定を変更することで、より厳格なリリース管理を実現できます。これらは、複数人での大規模開発においてコードの品質と環境の安定性を維持するために重要です。 参考 : Configuring project version control settings（プロジェクトのバージョン管理の設定） LookML バリデーションの必須化 LookML Validator によるエラーチェックを、変更をローカルブランチに コミットする前の必須条件 として設定できます。設定により「エラーと警告の両方を修正」または「エラーのみを修正」を必須にすることが可能です。これにより、構文エラーを含んだ不正なコードがプロジェクトの履歴に混入することを未然に防ぐことができます。 データテストの必須化 LookML 内に test パラメータを定義してモデルのロジックを検証するデータテストを作成している場合、本番環境へデプロイする前にこれらのテストに合格することを必須条件に設定できます。なお、新しく作成された LookML プロジェクトでは、このオプションがデフォルトで有効になっています。 プルリクエスト（PR）の統合 Pull Request Required 設定を有効にすると、デベロッパーは Looker IDE 内で直接本番ブランチへマージすることができなくなります。変更を本番環境に反映させるためには、必ず GitHub 等の外部サービス上でプルリクエストを作成し、第三者によるコードレビューを経てマージする必要があります。これにより、開発ガバナンスを大幅に高めることができます。 Looker は「マージコミット」方式のみをサポートしているため、この機能を利用する場合は、Git プロバイダ側で「スカッシュマージ」や「リベースマージ」のオプションを使用不可にしておくことが推奨されます。 参考 : プロジェクトの pull リクエストを統合する 高度なデプロイモード Advanced Deploy Mode（高度なデプロイモード） を有効にすると、常に本番ブランチの最新状態を自動デプロイするデフォルトの動作が解除されます。代わりに、デプロイ権限を持つ担当者が特定のコミット SHA や Git タグ（リリースバージョンなど）を明示的に指定して本番環境へ反映させることが可能です。 この機能により、Git 上でのマージと Looker へのリリース反映タイミングを完全に切り離し、Webhook や API を利用した複雑なリリースパイプラインを構築できます。ただし、このモードを有効にした場合、本番環境への「最初の1回目」のデプロイは、必ず Looker IDE 内の Deployment Manager から手動で実行する必要がある点に注意してください。 参考 : 高度なデプロイモード 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。