Looker 26.12がMFAをデフォルトで有効化、既知のXSS脆弱性も修正

Google Cloudは2026年7月30日、Looker 26.12の全インスタンスへの段階的ロールアウトを完了した。本リリースでは多要素認証（MFA）がデフォルトで有効化されたほか、クラウドホスト型環境において管理者アカウントの乗っ取りにつながるクロスサイトスクリプティング（XSS）脆弱性が自動修正された。セルフホスト型の運用者は、パッチ適用済みのバージョンへ至急アップグレードする必要がある。

■メール/パスワードログインでMFAがデフォルト有効に

Looker 26.12では、多要素認証（MFA）の適用について重要な変更が行われた。Okta、Azure AD、Google Workspace IAM、またはSAMLやOIDC互換のディレクトリなど、企業のシングルサインオン（SSO）プロバイダーにインスタンスをすでに連携させているLooker管理者の場合、その経路で認証するユーザーに変更はない。SSOユーザーはLookerのネイティブな認証情報ストアを完全にバイパスするため、26.12でのMFA強制は、Looker内で直接管理されるメールアドレスとパスワードを使用してログインするユーザーにのみ適用される。

サービスアカウント、埋め込みユースケース、SSO移行を完了していないテナントなど、Lookerネイティブのメール/パスワード認証情報に依存している組織にとって、この変更は即座に適用され、管理者の操作なしで有効になる。MFAを制御するトグルは以前はデフォルトでオフになっており、意図的に有効にする必要があったが、26.12以降は「オン」の状態で提供される。設定の確認や上書きが必要な管理者は、Looker管理パネルの「Authentication（認証）」セクションからアクセスできる。

準備ができていない環境における現実的なリスクは、セキュリティ侵害ではなく運用上の問題である。第2要素を登録していないユーザーは、次回のログイン時にMFAのプロンプトに直面することになり、サポートリクエストが発生する。また、一部の設定では、タイムアウト期間内にMFAの登録が完了しないと一時的にロックアウトされる可能性がある。次回のログインサイクルが始まる前に、SSO経由ではなくメール/パスワード経由で認証しているユーザーを監査することが、多くのLookerテナントにとって最も急を要する対応となる。

■セルフホスト型インスタンスの管理者が行うべき対応

7月22日のセキュリティ情報で、Lookerホスト型および顧客ホスト型インスタンスの両方に影響するXSS脆弱性（CVE-2026-15810）が公開された。この攻撃は、悪意を持って作成されたURLをLooker管理者に送りつけることで成立する。管理者がそのURLを開くと、攻撃者は管理者の権限で任意のスクリプトを実行できるようになり、すべてのデータ接続、ユーザー管理、API認証情報を含むLookerインスタンスの完全な制御を奪う可能性がある。

GoogleはLookerホスト型インスタンスの脆弱性を自動的に軽減しており、クラウドテナント側での対応は不要であることを確認している。顧客がホストするセルフデプロイ型インスタンスについては、サポートされているすべてのリリースブランチにパッチが存在する。対象となるパッチ適用済みバージョンは、Looker 26.8.7以降（26.8.xビルド）、26.6.28以降、26.4.36以降、26.2.47以降、26.0.66以降、25.18.68以降、25.12.65以降、25.6.103以降である。

26.12へのアップグレードによって、XSSパッチの要件が自動的に満たされるわけではない。セルフホスト型の運用者は、自身のリリースブランチ内の特定のパッチバージョンがインストールされていることを確認する必要がある。適切なパッチ適用済みビルドの26.12.xにアップグレードすることで、CVEへの対応とMFAのデフォルト変更の両方に同時に対処できる。

■Gemini Expression AssistantがGAとなり、Lexpの障壁を解消

LookerのExpression Assistantは26.12でプレビューから一般提供（GA）へと移行した。これにより、Google Cloudの標準的なサービスレベル契約（SLA）の対象となり、プレビュー版に伴う機能変更の警告なしに本番環境での利用が可能になった。

このアシスタントは、Lookerのセルフサービス分析モデルにおける最も根強い摩擦要因の1つを解消する。本リリース以前は、アナリストがカスタムフィールドや表計算を作成するには、Explore内でカスタムロジックを定義するためのLooker独自の数式言語であるLooker Expression（Lexp）の構文を学ぶ必要があった。この要件が障壁となり、カスタムフィールドの作成は、計算を最も必要とするビジネスアナリストではなく、データエンジニアやLookML開発者の手に委ねられていた。

Expression Assistantを有効にすると、アナリストが希望する内容を自然な英語で記述するだけで、Geminiを活用したアシスタントが対応するLexp構文を生成する。このアシスタントは現在のExploreのセマンティックレイヤーを基盤としているため、LookMLモデルで定義された実際のフィールド名やデータ型にアクセスできる。汎用的な疑似コードではなく、実際のフィールドを参照する数式を生成する。また、アナリストは生成された構文を手動で編集することなく、アシスタントに再プロンプトを出して反復作業を行うことができる（例：「特定のカテゴリを除外するようにパーセンテージ計算を変更して」と指示するなど）。

GAの指定はLooker（オリジナル）インスタンスに適用される。Expression Assistantは管理パネルの「Looker Assistants」設定で管理される。すでにプレビュー版で利用可能であったが、引き続き同じトグルで利用できる。

■Custom CalendarとEnhanced SearchもGAに

プレビュー段階にあった他の2つの機能も、同様にGAへと移行した。Custom Calendarを使用すると、LookML開発者は、小売業の4-4-5カレンダー、学年サイクル、カスタム期間構造など、グレゴリオ暦以外の会計カレンダーや運用カレンダーを、type: custom_calendarディメンショングループを使用してLookMLセマンティックレイヤーで直接定義できる。有効にすると、これらのカスタム期間がExploreのクエリにネイティブに表示されるため、アナリストはすべてのクエリに手動で日付オフセット変換を適用することなく、会計週や会計年度でフィルタリングやグループ化を行うことができる。

Enhanced Searchは、Lookerのコンテンツ発見バーに意味的理解をもたらす。ダッシュボードやLookのタイトルとキーワードを照合するのではなく、Geminiを使用して検索クエリの概念的な意味を解釈する。これにより、ユーザーが「地域別の総顧客獲得コスト」を検索した場合、タイトルにそれらの特定の単語が含まれていなくても、関連する指標をカバーするダッシュボードを表示できるようになる。

両機能ともGoogle Cloudの標準SLAの対象となり、プレビューステータスに伴う互換性の警告なしに、本番のLooker環境に展開できるようになった。

■Looker CIのメールアラート機能の進化

Looker Continuous Integration（CI）は、コード変更が本番環境に到達する前に自動化されたLookML検証スイートを実行するためのプラットフォーム組み込みフレームワークである。26.12からメールアラートをサポートするようになったが、この実装には注目すべき特定の設計上の決定が含まれている。それは、アラートが実行ステータスごとに設定可能であるという点だ。

CIスイートを作成または編集する際、管理者はメール通知を有効にし、Failed（失敗）、Error（エラー）、Passed（成功）、Cancelled（キャンセル）の4つの結果状態のうち、どれがメールをトリガーするかを個別に選択できる。失敗時のみ通知を受け取りたいチームは、PassedとCancelledの通知を抑制してアラートの量を減らすことができる。完全な監査証跡を必要とする品質保証ワークフローでは、4つすべてを有効にすることが可能だ。

Looker 26.8でGAとなったLooker CIには、26.12以前はメールアラートチャネルが含まれておらず、チームはCIの実行履歴を手動でポーリングするか、外部のWebhookと統合する必要があった。メールによる通知経路が追加されたことで、SlackやWebhookベースではなく、メール中心のアラートインフラストラクチャを持つ組織にとってのギャップが埋められた。

CI実行アラートのメールは、件名に実行ID（Run ID）が含まれている。これは、メールのスレッド化を防ぐことを意図した特定の設計上の選択である。件名に一意の識別子がない場合、件名でメッセージをグループ化するメールクライアントは、複数のCIアラートを単一のスレッドに折りたたんでしまい、各メールを個別に開かない限り、どの実行がどのアラートをトリガーしたかを区別できなくなる。件名に実行IDを含めることでスレッド化を防ぎつつ、メール本文には直接トリアージできるようにGitブランチとコミットの詳細が記載される。

■LookML Projectsページが3タブ構成に刷新

26.12のLookML Projects管理ページは、フラットなリストから、「Models and Projects」「Pending Projects」「Marketplace Projects」という3つの名前付きタブを持つタブレイアウトに変更された。Googleは、この再構築について、以前のフラットリスト形式では読み込みが遅くなったり、インスタンスが多数のプロジェクトをホストしている場合にナビゲートが困難になったりする可能性があった大規模なLooker展開向けのパフォーマンス改善であると説明している。

■Looker 26.12とGemini展開の全体像

26.12リリースは、Googleが2026年4月のGoogle Cloud Next '26で初めてプレビューした機能を前進させるものである。同カンファレンスでGoogleは、再構築されたExploreエクスペリエンスの一部として、Expression AssistantをInsight Assistant（自然言語によるExploreナビゲーション）やVisualization Assistant（自動チャートタイプ選択）とともに披露した。カンファレンス当時にRittman Analyticsが報じたように、これら3つのアシスタントは現在、GAまたはGAに近い段階にある。

基盤となるアーキテクチャに変更はない。Geminiアシスタントは、データウェアハウスに直接クエリを実行するのではなく、LookerのLookMLセマンティックレイヤーを基盤としている。この基盤こそが、Expression Assistantを本番環境で利用可能にする設計上の選択である。Geminiは現在のExploreの実際のデータモデルからフィールド名を参照する数式を生成するため、追加の編集を必要とする汎用的な疑似コードではなく、構文的に有効なLooker構文が出力される。GoogleがLookerで獲得した2026年のGartner Magic Quadrantの評価では、AIエージェントが検証済みのエンタープライズデータ上で動作し続けるためのアーキテクチャとして、このセマンティックレイヤーの基盤が強調されている。

Looker 26.8でプレビューとして導入されたLookerのマネージドMCP（Model Context Protocol）サーバーは、26.12のGAウェーブには含まれなかったが、引き続きプレビュー段階にあり、外部のAIエージェントがプログラムでLookerのセマンティックレイヤーにクエリを実行するためのインフラストラクチャを提供する。

■注目ポイントQ&A

●Looker 26.12のMFAデフォルト化は、Okta、Azure AD、Google Workspace経由でログインするユーザーに影響しますか？

いいえ。26.12の必須MFA設定は、Lookerに直接保存されたメールアドレスとパスワードで認証するユーザーにのみ適用されます。組織がすでにSAMLまたはOIDC経由でLookerをSSOプロバイダーに連携させている場合、それらのユーザーはIDプロバイダー経由で認証され、Lookerのネイティブな認証情報経路に触れることはありません。ユーザーが直面するMFAプロンプト（存在する場合）は、新しいLookerの設定ではなく、IDプロバイダーが強制するものです。多くのエンタープライズLooker管理者にとっての現実的な対応は、ネイティブのメール/パスワード経由で認証しているユーザーの数を監査することです。デフォルト変更の影響を受けるのはこれらのユーザーのみだからです。

●セルフホスト型のLookerインスタンスがCVE-2026-15810に対して脆弱かどうかを知るにはどうすればよいですか？

顧客ホスト型（セルフデプロイ型）のLookerインスタンスを実行しており、パッチ適用済みのビルド（26.8ブランチ内の26.8.7以降、26.6内の26.6.28以降、最も古いサポート対象ブランチである25.6.103まで）にまだアップグレードしていない場合、インスタンスは依然としてXSS脆弱性にさらされています。クラウドホスト型のLookerインスタンス（Googleが管理するもの）は7月22日までに自動的にパッチが適用されており、対応は不要です。Looker管理パネルでインスタンスのバージョン番号を確認し、CVEアドバイザリに記載されているパッチ適用済みのバージョンと比較してください。

●Looker Expression Assistantは数式を生成する際、実際に何を行っているのですか？

Expression Assistantは、カスタム計算の自然な英語による説明（例：「今四半期の注文の累積合計」）を受け取り、Geminiを使用して有効なLooker Expression（Lexp）構文に翻訳します。重要なのは、アシスタントが現在のExploreのLookMLセマンティックモデルを基盤としていることです。つまり、そのExploreで利用可能なフィールドの実際の名前とデータ型を認識しています。プレースホルダーの変数名ではなく、それらの実際のフィールドを参照する構文を生成します。アナリストは再プロンプトを出して反復作業を行うことができます（「返品を除外して」と指示すると、修正された数式が生成されます）。この機能により、アナリストがカスタムフィールドや表計算を作成する前にLexpの文法を学ぶ必要があった以前の要件が置き換えられます。

●Looker 26.12にアップグレードすると、セルフホスト型インスタンスのCVE-2026-15810は自動的にパッチ適用されますか？

はい、パッチが含まれる26.12ビルドをインストールする限り適用されます。この脆弱性は、26.8.7およびそれ以降のすべてのバージョンを含む、サポートされているすべてのリリースブランチで修正されました。現在の26.12ビルド（7月22日のパッチより後のもの）にアップグレードする顧客ホスト型の運用者は、1回のアップグレードでMFAのデフォルト変更とXSS修正の両方を受け取ることができます。アップグレードプロセスで段階的なテストが必要なため、古いリリースブランチにとどまる運用者は、26.12にスキップするのではなく、そのブランチ内のパッチ適用済みのマイナーバージョンにアップグレードする必要があります。サポートされているすべてのブランチのパッチ適用済みバージョンの完全なリストは、CVEアドバイザリに記載されています。

元記事: Looker 26.12 Turns MFA On by Default and Closes Known XSS Vulnerability