本記事は 2026 年 2 月 13 日に公開された Ranjith Ramakrishnan による “ Enterprise identity and usage metrics ” を翻訳したものです。 Kiro が 11 月 17 日に一般提供されて以来、Rackspace、Smugmug、Netsmart などの多くの企業が、エンジニアリングチーム全体でスペック駆動開発アプローチを採用し、AI 開発においてより構造化されたアプローチをもたらし、場合によっては最大 90% の効率向上を実現しています。 本日、外部 ID プロバイダーのサポートとユーザーレベルのアクティビティメトリクスにより、組織が Kiro をさらに簡単に使用できるようになりました。企業には、ID 管理の仕組みやコンプライアンス要件があり、またチームは「何がどのように使われているのか」を可視化して把握する必要があります。この分野は急速に変化しているため、企業は新しいユーザーを迅速にオンボーディングし、AI がエンジニアをどこでどのように支援しているかについての洞察を得たいと考えています。このデータがあれば、ツールとプロセスへの投資を迅速に拡大し、一貫して高い品質基準を保ちながら、はるかに速くリリースできます。 外部 ID プロバイダー: Okta と Microsoft Entra ID 組織が Okta または Microsoft Entra ID を通じて ID を管理している場合、Kiro はそのインフラストラクチャに直接接続できるようになりました。これは、 IDE 、 CLI 、Web アプリなど、Kiro ポートフォリオ全体で機能します。開発者は既に持っている認証情報で認証するため、新しいログインを設定する必要はありません。 管理者が既存の ID プロバイダーをオンボーディングすると、SSO ポリシー、条件付きアクセスルール、MFA 適用が設定どおりに Kiro で使用されます。Okta と Microsoft Entra から始めたのは、多くのお客様からのリクエストに基づいています。追加の OIDC プロバイダーのサポートに取り組んでいます。まだサポートされていないプロバイダーを使用している場合は、 お知らせください 。優先順位の決定に役立てさせていただきます。 これは、Kiro を人気のあるエンタープライズツールやシステム（ID プロバイダー、チケットシステムやバージョン管理システム、デプロイツールなど）に接続する最初のステップです。 ユーザーレベルのアクティビティメトリクス 組織の管理者は、チーム全体の利用状況を日次で集計したデータを提供するユーザーアクティビティレポートを有効にできるようになりました。レポートは、クライアントタイプ（IDE、CLI、IDE プラグイン）ごとにアクティビティを分類するため、開発者が実際に使用しているツールを可視化できます。これらの基本的なメトリクスは始まりに過ぎません。 生産性の測定と使用パターンの確立は繰り返し出てくるテーマであり、今日、私たちはより豊富な分析（トレンドビュー、チームレベルの集計、エクスポート可能なダッシュボード）だけでなく、エージェント型開発を効果的に活用することが、どのように生産性向上につながるのか、その洞察を得られるようにしていきます。企業が重視するソフトウェアデリバリー指標において、どのチームが最も顕著な向上を実現しているのか？ そしてその成果を牽引する利用パターンとは何か？ 2026年の展開にご期待ください。 エンタープライズ向けの次のステップ これら 2 つの機能は、企業が既に依存しているシステム内で Kiro を機能させるための、より広範な取り組みの一部です。既存のツールやサービスとのさらなる統合、および開発速度を安全に向上させるために必要なガードレールを提供する追加のガバナンス制御と機能に積極的に取り組んでいます。 組織での Kiro 導入を検討中の方、または既に利用中で特定のエンタープライズ機能の優先的な実装を希望される方は、 お知らせいただくか 、 GitHub で Issues を開いてください。 翻訳は Solutions Architect の吉村が担当いたしました。

AI コーディングアシスタントに簡単なこと、例えば関数名の変更やファイルの移動を依頼すると、突然復旧作業に追われることがあります。インポートが壊れたり、参照が存在しないファイルを指したりします。5 分前にコンパイルできていたコードベースが、至る所でエラーを投げ始めます。20 秒で終わるはずのリファクタリングが、5 分間のデバッグとクリーンアップセッションに変わってしまうのです。 エージェントにとってリファクタリングが難しい理由 リファクタリングは単なる大規模な検索置換ではありません。コードベースのセマンティック構造全体にわたるグラフトラバーサル問題なのです。関数名を変更すると、変更は連鎖します。ワークスペース全体のすべての呼び出し箇所、それを参照する型定義とインターフェース、import/export 文、テスト、そして（オプションで）ドキュメントとコメント。ファイルの移動はさらに複雑な波及効果を引き起こし、すべての依存ファイルのインポートパス、バレルファイル（ index.ts ）と再エクスポート、 tsconfig パスやバンドラー設定に組み込まれたモジュール解決の前提、Webpack 設定のような散在する設定ファイルなどに影響します。ここに根本的なミスマッチがあります。LLM はパターンマッチングを通じてもっともらしいコードを生成することに優れていますが、リファクタリングは もっともらしさよりも精度 を要求します。これは創造的なタスクではなく、シンボルの関係、言語固有のセマンティクス、プロジェクトの依存関係グラフの正確な理解を必要とする制約充足問題なのです。「正しく見える」が、深くネストさ れたモジュールの 1 つのインポートを見逃したエージェントは、単に小さなエラーを犯しただけではありません。本番環境まで表面化しないランタイム障害を導入したのです。これが、どれほど洗練されていたとしても、テキスト生成が構造的なコード変換において信頼性に欠けるツールである理由です。 問題：エージェントが効率的ではなく、非効率に動作するとき 多くの AI エージェントがリファクタリングでつまずくのは、 構造的 な編集を テキスト 編集として扱うからです。開発者が直面し続けている失敗モードをいくつか紹介します。 依頼内容： 「このメソッドの名前を変更して」 従来の失敗： エージェントはメソッド定義を更新しましたが、プロジェクト全体の呼び出し箇所を見逃しました。プロンプトで参照を更新するよう明示的に依頼した場合でも、プロセスは遅くエラーが発生しやすいループになりました。古い名前を検索して置換するのです。このプロンプトを考えてみましょう。 expression.js の get_loose_identifier を、それが何をするかをよりよく反映するように名前変更してください。このシンボルの名前変更は 4 つのファイルに伝播し、8 つの参照と 3 つのインポートに影響します。次の図の左側（従来のアプローチ）は、専用のリファクタリングツールなしでこの操作がどのように展開されるかを示しています。最初のファイル（ expression.js ）でシンボルの名前を変更した後、エージェントはコードベースで get_loose_identifier を検索し、複数の LLM 呼び出しとツール呼び出しを通じて CallExpression.js と AssignmentExpression.js を更新します。努力したにもかかわらず、残りの参照を見逃しています。 Kiro の対処法： 開発者が IDE でこのタスクを手動で実行する方法を考えてみましょう。 get_loose_identifier で F2 を押し、新しい名前を入力して、Enter を押します。IDE は、コードベース全体の 8 つの参照と 3 つのインポートすべてを更新しながら、自動的に名前変更を実行します。これがまさにセマンティックリネームツールが行うことです。次の図の右側（新しいアプローチ）は、Kiro が単一のツール呼び出しで名前変更全体を適切に実行する方法を示しています。 依頼内容： 「このファイルの lint エラーを修正して」 従来の失敗： エージェントは linter の出力をテキスト編集の ToDo リストとして扱いました。1 つのファイルでシグネチャの関数名を camelCase から snake_case に変更しましたが、他のファイルで「参照が見つからない」や「インポートが見つからない」エラーを導入しました。すべての使用箇所への変更の伝播に失敗したのです。 Kiro の対処法： ユーザーが直接名前変更を依頼しなくても、エージェントがセマンティックリネームツールから恩恵を受ける例を示します。ユーザーはエージェントに「 text_helpers.py の lint エラーを修正して」と依頼します。lint エラーは、 utils/text_helpers.py 内の normalizeText と slugifyTitle を snake_case に変更する必要があることを示しています。コードベースの部分的なスナップショットを以下に示します。 これらの修正をテキスト編集として扱うエージェントは、関数定義の名前を変更し、ローカル参照を修正するかもしれませんが、他の場所のインポートや呼び出し箇所を見逃す可能性が高く、実行時に ImportError / NameError を引き起こします。セマンティックリネームツールを使用することで、Kiro は定義だけでなく、 api/routes.py と services/indexer.py のインポートと呼び出しも更新します。以下の画像の通りです。 依頼内容： 「コンポーネントを再編成して – Button.tsx を src/components/ から src/shared/ui/ に移動して」 従来の失敗： エージェントはタスクを単純なファイル操作として扱いました。ファイルの移動は成功しましたが、古い場所を指すすべてのインポート文が壊れています。エージェントはその後、検索置換操作でファイルごとにインポートを修正しようとしましたが、動的インポートを見逃しました。 import('../components/Button') 。 Kiro の対処法： Kiro がインポートパスを自動的に更新する具体的な例を示します。図は、プロジェクト構造の部分的なスナップショットと依存するコードスニペットの一部を示しています。 Button.tsx を src/components/ から src/shared/ui/ に移動した後、Kiro は移動したファイルに関連するすべてのインポート文を自動的に更新します。 主な利点： 組み込みの言語サーバーが編集を処理するため、手動の検索置換は不要です。 言語認識：TypeScript/JavaScript モジュール解決を理解します。 より安全：動作するコードを壊す可能性が低くなります。 エッジケースの処理：パスエイリアス、モノレポなどに対応します。 これは、VSCode のエクスプローラーでファイルをドラッグアンドドロップしたときに起こることとまったく同じです。セマンティックリネームツールはエージェントベースの同等機能です！ Kiro エージェントのリファクタリング方法 IDE は、エージェント AI の台頭以前にこの問題をすでに解決していました。VSCode でシンボルの名前を変更するために F2 を押すと、IDE は推測しません。コードの構造を理解する言語サーバーに相談し、ワークスペース全体の編集を計算し、安全に適用します。VSCode のワークスペース編集機能により、単なるテキストパターンではなく、コードの構造を理解するプログラマブルなセマンティック検索置換が可能になります。Kiro エージェントは、LLM 推論だけでリファクタリングをシミュレートしようとはしません。代わりに、エージェントは上記と同じメカニズムを使用して、これらの実証済みの IDE 機能をプログラム的に公開する 2 つの新しいリファクタリングツールを登録します。エージェントがシンボルの名前を変更したりファイルを移動したりする必要がある場合、意図をインテリジェントに認識し、適切なリファクタリングツールを選択して呼び出します。エージェントはリファクタリングワークフローを調整し、IDE の言語サーバーが正確性の検証を支援します。 これらのエージェント登録リファクタリングツールが内部でどのように機能するかを見てみましょう。 セマンティックリネームツール：正しいリネームを実現 このツールは、VSCode のシンボル名前変更 API に直接接続します。F2 を押したときに使用するのと同じものです。 vscode.prepareRename を使用してシンボルが名前変更可能かどうかを検証し（例：キーワードではない）、 vscode.executeDocumentRenameProvider を使用してワークスペース全体で必要なすべての変更を含むワークスペース編集を生成します。TypeScript、JavaScript、TSX、JSX の場合、組み込みの VSCode 名前変更プロバイダーがすべてを処理します。Python、Go、Java などの場合、ツールはインストールされた言語拡張機能とそれらが提供する言語サーバーに依存します。 スマートリロケートツール：すべてを壊さずにファイルを移動 このツールは、VSCode のファイル移動機能を使用して、すべての参照を自動的に更新しながらファイルを再配置します。VSCode のエクスプローラーでドラッグアンドドロップするのと同等のプログラム的な操作ですが、エージェントがあなたのために実行できます。 vscode.WorkspaceEdit.renameFile と vscode.workspace.applyEdit を使用して、ツールは複数のファイルにわたる包括的な変更を生成し、影響を受けるインポートを更新します。 これが重要な理由 創造性よりも精度： リファクタリングは、コードがどのように見えるべきかを LLM に想像させる必要はありません。コードが 実際に何であるか を理解し、外科的に変更できるツールが必要なのです。 実証済みのインフラストラクチャを通じた信頼： これらは実験的な LLM 機能ではなく、開発者が日常的にすでに依存しているリファクタリングインフラストラクチャとの直接統合です。F2 を押したときに機能すれば、エージェントが実行したときにも機能します。 言語に依存しない： 重い作業は言語サーバーによって行われるため、このアプローチは技術スタックと言語全体に一般化されます。 生産性の維持： 20 秒の手動リファクタリングが、5 分間の AI 生成リカバリーミッションになるべきではありません。適切なツールを使用すれば、操作は高速でアトミックなままです。 より大きな視点 構築による正確性という私たちの哲学に基づいて、 IDE 診断統合 を導いたのと同じ原則で、VSCode のリファクタリング機能の全範囲をカバーするようにこのアプローチを拡張しています。エラーが複合する前にキャッチするためにリアルタイム診断を統合したのと同様に、これらの実証済みの決定論的 IDE 機能を、新しい内部スマートリロケートおよびセマンティックリネームツールに拡張しました。 しかし、リファクタリング機能は名前変更と再配置で止まりません。VSCode の言語サーバーは、エージェントが活用すべき豊富な自動コード変換スイートを提供します。コードブロックを再利用可能な関数に抽出するメソッド/関数の抽出、コードを簡素化する変数/関数のインライン化、すべての呼び出し箇所でメソッドパラメータを更新するシグネチャの変更、アロー関数への変換やその他の言語固有の変換は有力な候補です。 このアプローチを取ることで、エージェントが実行される基盤に正確性、セキュリティ、信頼性を組み込むことができます。これらのツールで確立したパターンは、ツールキットへの新しい追加を導きます。LLM に脆弱なテキスト置換スクリプトを生成するよう依頼する代わりに、インテリジェントなコーディングエージェントは、開発者がすでに信頼しているこれらの実証済みの IDE 操作を活用し続けます。IDE が正しく実行する方法を知っているとき、私たちはそれに作業をさせます。エージェントがより有能になるにつれて、これはその出力をより信頼できるものにするための良いテクニックでもあります。 違いを体験する準備はできましたか？ Kiro を無料で始めて 、開発ワークフローをどのように変革できるかを確認してください。 Discord の成長するコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで構築している他の開発者とつながりましょう。 謝辞 エンジニアリングの洞察と貴重なフィードバックを提供してくれた Al Harris に感謝します。 本記事は 2026 年 2 月 5 日に公開された Pardis Pashakhanloo と Rajdeep Mukherjee による “ Refactoring made right: how program analysis makes AI agents safe and reliable ” を翻訳したものです。翻訳は Solutions Architect の吉村が担当いたしました。

G-gen の菊池です。当記事では、Looker で BigQuery のデータを可視化するための一連のフローを、スクリーンショット付きで解説します。BigQuery との接続から、LookML の自動生成と調整、Explore での可視化などを説明します。 はじめに 当記事について Looker、ビュー、Explore、モデル 構成図 BigQuery 側の準備 デモ用データセットの作成 サンプルデータの投入 接続用サービスアカウント（SA） の作成と権限付与 Looker の接続設定 BigQuery への接続（Connection）の作成 接続テストと設定の保存 LookML プロジェクトの作成（新規モデルの作成） プロジェクトページへ移動 データベース接続を選択 テーブルを選択する 主キーの選択 作成する Explore を選択する モデル名を入力 LookML の定義と調整 自動生成されたファイルの確認 ディメンションからメジャーへの修正 日付データの修正 変更のコミットと本番反映 Explore でデータを可視化してみる Explore 画面の操作 フィルターの使い方 ディメンションからメジャーへの修正をしなかった場合 日付データの修正をしなかった場合 はじめに 当記事について 当記事では、Looker でデータを可視化する際の一連のフローである「BigQuery との接続・認証」「LookML の作成」、そしてビジュアリゼーション作成を含む「Explore での可視化」について解説します。 Looker、ビュー、Explore、モデル Looker とは、エンタープライズ向けのデータプラットフォームです。開発者向けのセマンティックレイヤーとユーザー向けの BI ツールの両方の特徴を併せ持っています。 Looker 独自のモデリング言語である LookML を使用することで、分析対象のデータの構造とビジネスルールを定義するデータモデルを作成、管理できます。 Looker は、この LookML で定義されたデータモデルから自動的に SQL を生成します。そのため、SQL を知らないユーザーでも、直感的なインターフェースからデータを探索し、分析できます。 参考 : Looker 参考 : LookMLの紹介 Looker は、データベースのテーブルと1対1で紐づく「 ビュー 」、どのビューをユーザーに見せるか定義する「 Explore 」、どのデータベースに接続するか、どの Explore をユーザーに公開するか定義する「 モデル 」の3つの構造で成り立っています。 参考 : LookMLの用語と概念 これら3つの構成要素についての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp 構成図 今回構成する Looker から BigQuery のテーブルを参照する環境は以下の通りです。 構成 BigQuery 側の準備 デモ用データセットの作成 以下の名前でデモ用のデータセットを作成します。 項目 設定値 データセット名 looker_demo_source サンプルデータの投入 BigQuery では、Google Merchandise Store （Google ブランドの商品を販売するオンラインストア）の Google アナリティクス 4 のデータがサンプルデータとして使用できます。今回はそのサンプルデータから以下の SQL の結果を取得して参照用のテーブルとします。 WITH UserData AS ( SELECT event_date AS date , user_pseudo_id, ( SELECT value.int_value FROM UNNEST(event_params) WHERE key = ' ga_session_id ' ) AS session_id, geo.country AS country, event_name, ( SELECT value.string_value FROM UNNEST(event_params) WHERE key = ' session_engaged ' ) AS session_engaged_flag, ( SELECT value.int_value FROM UNNEST(event_params) WHERE key = ' engagement_time_msec ' ) AS engagement_time_msec FROM `bigquery- public -data.ga4_obfuscated_sample_ecommerce.events_*` WHERE PARSE_DATE( ' %Y%m%d ' , _TABLE_SUFFIX) BETWEEN DATE ' 2021-01-01 ' AND DATE ' 2021-01-31 ' ) SELECT date , --日付 COUNT ( DISTINCT CASE WHEN session_engaged_flag = ' 1 ' THEN user_pseudo_id WHEN event_name = ' first_visit ' THEN user_pseudo_id WHEN engagement_time_msec > 0 THEN user_pseudo_id END ) AS active_users, --アクティブユーザー数 COUNT ( DISTINCT CASE WHEN event_name = ' first_visit ' THEN user_pseudo_id END ) AS new_users, --新規ユーザー数 COUNT ( DISTINCT CONCAT (user_pseudo_id, CAST (session_id AS STRING))) AS sessions, --セッション数 country, --国 FROM UserData GROUP BY date , country ORDER BY date このテーブルには 2021 年 1 月の日付、国ごとのアクティブユーザー数、新規ユーザー数、セッション数が含まれています。 列名 説明 date 日付 active_users アクティブユーザー数 new_users 新規ユーザー数 sessions セッション数 country 国 SELECT 文のクエリ結果は、[結果の保存]をクリックし、[ローカルへのダウンロード] > [ CSV ]を選択して保存します。 クエリ結果の保存 作成していたデータセット「looker_demo_source」の右側の三点リーダーをクリックし、[テーブルを作成]を選択します。 [テーブルを作成]画面では、以下のように設定して、[テーブルを作成]をクリックします。 項目 設定値 ソース > テーブルの作成元 アップロード ソース > ファイルを選択 ダウンロードした CSV ファイル ソース > ファイル形式 CSV 送信先 > プロジェクト 自身のプロジェクト 送信先 > データセット looker_demo_source 送信先 > テーブル ga4_daily_metrics_by_country スキーマ > 自動検出 チェックを入れる 詳細オプション > ヘッダー行のスキップ 1 接続用サービスアカウント（SA） の作成と権限付与 Looker が BigQuery データベースへのアクセスに使用する認証を構成します。 サービスアカウント作成 1.Google Cloud コンソールで[ API とサービス] > [認証情報]へ移動します。 2.[認証情報を作成] を選択し、[サービス アカウント] を選択します。 3.サービス アカウントの作成画面で以下を入力して、[作成して続行] を選択します。 項目 設定値 サービスアカウント名 looker-bq-connection-sa サービスアカウントID サービスアカウント名を入力すると自動で同じ値が入力される。 サービスアカウントの説明 Looker から BigQuery へのアクセス用 サービスアカウント作成画面 4.権限の設定画面で、[ロールを選択] フィールドで以下のロールを選択します。２つ目以降も[別のロールを追加] を選択して、同じようにロールを選択します。 BigQuery > BigQuery データ編集者 BigQuery > BigQuery ジョブユーザー サービスアカウントの権限設定画面 サービスアカウントの権限設定 5.[続行] を選択して [完了] を選択します。 サービス アカウントの認証を構成 1.[認証情報] ページで、新しく作成したサービス アカウントのメールを選択します。 サービスアカウントの選択 2.サービス アカウントの詳細画面で[鍵]タブを選択し、[キーを追加] のプルダウンから [新しいキーを作成] を選択します。 サービスアカウントに新しいキーを作成 3.[キーのタイプ] で [JSON] を選択し、[作成] を選択します。 キーのタイプを選択 4.秘密鍵（JSON ファイル）がコンピュータに保存されるので、ダウンロード先をメモしてから[閉じる]をクリックします。 秘密鍵のダウンロード 鍵を再度ダウンロードすることはできないため、ここで忘れずに保存先をメモしておきます。 Looker の接続設定 BigQuery への接続（Connection）の作成 1.以下の 2 つの方法のいずれかで、[データベースを Looker に接続] ページを開きます。 [管理者] パネルの [データベース] セクションで [接続] を選択します。[接続（Connections）]ページで、[接続を追加（Add Connection）] ボタンをクリックします。 管理者パネルから接続ページへ メイン ナビゲーション パネルの [作成] ボタンをクリックし、[接続] メニュー項目を選択します。 メインパネルの作成から接続ページへ 2.全般設定の画面で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 名前 conn-ga4-daily-demo SQL 言語（SQL Dialect） [Google BigQuery Standard SQL]を選択 プロジェクトの範囲 [すべてのプロジェクト]をチェック 全般設定 3.データベース設定の画面で以下の通りに設定します。 項目 設定値 課金プロジェクト ID データセットを作成したプロジェクトのID ストレージ プロジェクト ID なし プライマリ データセット looker_demo_source データベース設定 4.認証の設定で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 認証方法 [サービスアカウント]を選択 サービスアカウント証明書 ダウンロードしていた秘密鍵（JSONファイル）を指定 認証の設定 5.オプションの設定で以下の通りに設定し、[次へ]をクリックします。 項目 設定値 ノードあたりの最大接続数 30 接続プールのタイムアウト 120 この接続に関する同時実行クエリの最大数 200 この接続に関するユーザーあたりの同時実行クエリの最大数 25 最大課金ギガバイト数 なし その他の JDBC パラメータ なし メンテナンス スケジュール なし コンテキストの無効化 選択 SSL 選択 テーブルと列を事前にキャッシュに保存 選択 スキーマを取得してキャッシュに保存 選択 PDT を有効にする オフ データベースのタイムゾーン Asia - Tokyo クエリのタイムゾーン Asia - Tokyo オプションの設定（1） オプションの設定（2） オプションの設定（3） 接続テストと設定の保存 6.接続の該当するフィールドをすべて入力したら、必要に応じて接続をテストを実施します。 接続テスト 7.[次へ]をクリックして、接続設定の確認をしたら、[保存]をクリックします。 接続の保存 LookML プロジェクトの作成（新規モデルの作成） プロジェクトページへ移動 1.Development Mode（開発モード）になっていることを確認し、ナビゲーション パネルの [開発] セクションから、[プロジェクト] を選択します。 開発パネルからプロジェクトページへ 2.[LookML プロジェクト] ページで、[New Model] をクリックします。 プロジェクトページ データベース接続を選択 3.[データベース接続を選択]画面で以下の通り設定して、[次へ]をクリックします。 項目 設定値 データベース接続 conn-ga4-daily-demo LookML Project Name proj_ga4_analysis データベース接続を選択 テーブルを選択する 4.[テーブルを選択する]画面で、Looker で接続するプロジェクトとデータセットを選択し、右側の[Tables]をクリックします。 項目 設定値 GCPプロジェクト データセットが存在する Google Cloud プロジェクト データセット looker_demo_source GCP プロジェクトとデータセット選択 5.選択したデータセットに存在するテーブルの一覧が表示されるので、以下のテーブルを選択します。その他のオプションはデフォルトのままで[次へ]をクリックします。 項目 設定値 テーブル ga4_daily_metrics_by_country テーブルの選択 主キーの選択 6.[主キーの選択]画面では、テーブルを適切に結合するための主キーを設定します。この手順は省略可能です。今回は主キーは不要なので何も選択せずに[次へ]をクリックします。 主キーの選択 作成する Explore を選択する 7.[作成する Explore を選択する]画面では、Explore のビューとして使用するテーブルを選択します。テーブル「ga4_daily_metrics_by_country」の横にあるチェックボックスを選択して、[次へ]をクリックします。 作成する Explore を選択 モデル名を入力 8.[モデル名を入力]画面で以下のモデル名を入力して、[完了してモデルを表示]ボタンをクリックします。 項目 設定値 モデル名 ga4_daily_demo モデル名を入力 以上の手順で、LookMLプロジェクトとモデルが作成され、Looker IDE（統合開発環境）が開かれます。 Looker IDE 参考 : モデルの生成 LookML の定義と調整 自動生成されたファイルの確認 直前の処理から遷移した Looker IDE 画面へは、メイン ナビゲーション メニューの [開発] パネルからもアクセスできます。ナビゲーション メニューで [開発] を選択して、[開発] パネルを開きます。 [開発] パネルでプロジェクトの一覧が表示されるので、アクセスするプロジェクトの名前を選択します。「プロジェクトを検索」欄にプロジェクト名の一部を入れることで、簡単に探し出すことができます。 プロジェクトへ移動 Looker IDE 画面 遷移した Looker IDE 画面の左側にある「①IDE ナビゲーション バー」から「ファイルブラウザ」を選択します。すると、②機能パネルにファイルブラウザが表示されます。 ファイルブラウザでファイルを選択すると、③IDE エディタパネルに選択したファイルの内容が表示されます。 ファイルブラウザには2種類のファイルが既に作成されています。これらは、モデルを作成する際に選択したテーブルの定義を元に作成されたファイルです。 作成されたファイル views フォルダにある「ga4_daily_metrics_by_country.view」というファイルは、Looker のビュー（View）を定義するファイルです。データベースのテーブル「ga4_daily_metrics_by_country」と1対1で対応しおり、テーブル内の各列を定義します。 ビューファイル models フォルダにある「ga4-daily-demo.model」というファイルは、Looker のモデルを定義するファイルです。 このファイルでは、 explore パラメータを使用して Explore（エクスプロア）が定義されています。ユーザーが UI 上で見る「データ探索（Explore）」画面の元となる定義です。モデルファイルは、どのデータベースに接続するか、どの Explore をユーザーに公開するかを管理します。 モデルファイル 自動で生成されたモデルファイルとビューファイルは、この状態でも BigQuery のテーブルを BI として確認できる状態です。 しかし、自動生成されたファイルをそのまま使うのではなく、いくつか修正する必要があります。なぜ修正が必要かについては、データを可視化する部分で説明します。 ディメンションからメジャーへの修正 ビューファイルはテーブル内の各列をディメンションとメジャーとして定義します。ディメンションとは、日付や顧客名、商品カテゴリといったデータの属性や切り口を表します。メジャーとは、売上合計やユーザー数、平均年齢といった集計値や計算したい値を表します。 自動生成されたビューファイルでは、数値として表示したい列がディメンションとして定義されている場合があります。そのような列はメジャーに修正する必要があります。 以下の3つの数値列をディメンションからメジャーへ修正します。 物理名 論理名 active_users アクティブユーザー数 new_users 新規ユーザー数 sessions セッション数 修正箇所 修正前 修正後 dimension measure type: number type: sum メジャー（measure）への修正 日付データの修正 以下の列は日付のデータを YYYYMMDD 形式（例：2026年1月1日の場合、20260101）の数値で格納した列です。BigQuery でテーブルを作成する際、スキーマ自動検出にしていたため、数値の列として作成されました。 物理名 論理名 date イベント日 date 列を日付型として扱うために、以下のように修正します。 修正箇所 修正前 修正後 dimension dimension_group type: number type: time なし timeframes: [date, week, month, year, raw] なし datatype: yyyymmdd 日付型の定義 変更のコミットと本番反映 ファイルに変更点がある場合、以下のようにファイル名の右側に青い丸が付き、エディタパネルの右上に「Save Changes」ボタンが表示されます。 ファイルに変更点がある場合 Save Changes ボタン 「Save Changes」ボタンをクリックすると変更が保存され、画面右上にある Git ボタンが「Validate LookML」となります。 Git ボタン（Validate LookML） 画面右上にある Git ボタンは、プロジェクトの状態に応じて、プロジェクトを環境に反映するために必要なアクションが表示されます。 アクション 表示 LookML を検証 Validate LookML commit、ブランチをリモートに push Commit Changes & Push 本番環境にデプロイ Deploy to Production ファイルに変更点がある場合、Git ボタンは「Validate LookML」となり、それをクリックすることで変更内容にエラーがないか検証されます。 エラーがない場合、Git ボタンは「Commit Changes & Push」となり、画面右側のサイドパネルには LookML の検証結果が表示されます。 LookML の検証結果 「Commit Changes & Push」となっている Git ボタンをクリックすると、Commit 画面が表示されます。変更を反映するファイルにチェックを入れ、コミットメッセージを入力して [Commit] ボタンをクリックします。 Commit 画面 Commit と Push が行われると、Git ボタンは「Deploy to Production」と表示されます。 本番環境へデプロイ 「Deploy to Production」となっている Git ボタンをクリックすることで、変更内容が本番環境にデプロイされます。本番環境にデプロイされた変更内容は、Looker インスタンスを使用するユーザー全員が確認できます。 変更内容を作業者が確認するだけならば、「Deploy to Production」をクリックする手前までで充分です。 参考 : 開発モードと本稼働モード Explore でデータを可視化してみる Explore 画面の操作 ナビゲーション メニューで [Explore] を選択して、[Explore] パネルを開きます。Explore の一覧が表示されるので、アクセスする Explore の名前を選択します。 「Explore を検索」欄に Explore 名の一部を入れると、すぐに探しだすことができます。 Explore を開く Explore 画面が表示されます。左側の[すべてのフィールド]タブに一覧で表示されているフィールドから、グラフとして表示したいフィールドを選択していきます。 Explore の初期画面 フィールドの一覧から、以下のフィールドを順に選択していきます。Date フィールドについては、[Date Date] の左側にある▼マークをクリックすることで、Date、Month、Week、Yearというフィールドが展開されます。 Date Country Sessions Active Users New Users フィールドの選択 フィールドを選択すると右側にある [データ] パネルに選択したフィールドが追加されます。右上にある [実行] ボタンをクリックします。 データパネル 選択したフィールドのデータが取得されます。「行数上限に達しました。結果の一部が表示されない可能性があります。」というメッセージが表示されることがあります。右上にある「行数上限」が 500 になっていますが、取得したデータが500行以上ある場合にこのメッセージが表示されます。 全てのデータを表示したい場合は、行数上限の値を取得データの行数より大きい値（例 : 5000）のようにして、[実行] ボタンを再度クリックします。 [ビジュアリゼーション] パネルの左側にある▼マークをクリックすると、[ビジュアリゼーション] パネルが表示されます。 ビジュアリゼーションパネルの展開 今回は、Country フィールドに国名のデータがあったため、Google マップのビジュアリゼーションが自動で選ばれました。 ここから、ビジュアリゼーションを表（テーブル）形式へ変更する場合は、ビジュアリゼーションパネルにあるテーブルのマークをクリックします。 ビジュアリゼーションの変更 テーブル形式のビジュアリゼーション テーブルの Country フィールドを見ると、数値の他にデータの値を表す水平棒グラフのビジュアリゼーションが表示されています。 セルのビジュアリゼーション このビジュアリゼーションが不要な場合は、ビジュアリゼーションタブの右側にある [編集] タブをクリックします。 表示されたパネルの [系列] タブを選択し、[カスタマイズ] で Sessions を展開し、「セルのビジュアリゼーション」をオフにします。 セルのビジュアリゼーションをオフにする セルのビジュアリゼーションなし 参考 : Explore の作成と編集 参考 : Looker での Explore の表示と操作 参考 : セルのビジュアリゼーション フィルターの使い方 フィールドの値を絞り込みたい場合は、フィルタを追加します。フィルタの追加方法は以下の2通りです。 左側のフィールド一覧で、フィールド名の右側にある [フィールドでフィルタ] を選択します。 [データ] パネルの [結果] タブで、フィールドの見出しにある歯車を選択し、[フィルタ] を選択します。 フィルタの追加方法 [フィルタ] パネルが開き、選択したフィールドのフィルタが表示されます。フィルタの値を指定するには、「任意の値」の欄をクリックします。 フィルタする値の選択箇所 値の一覧が表示されるので、フィルタに使用する値を選択します。 フィルタの値の選択 [実行] ボタンをクリックすることで、[ビジュアリゼーション] パネルの表が、フィルタで指定した値で絞り込みされます。 フィルタの結果 フィルタ方法を「次を含む」や「次で始まる」などに変更する場合は、「任意の値」欄の左側で選択します。 フィルタ方法の変更 参考 : データのフィルタリングと制限 ディメンションからメジャーへの修正をしなかった場合 LookML の定義と調整の手順で数値の列を、ディメンションからメジャーへ修正していました。 メジャーにした列は以下のような挙動になります。 Country : Albaniaでフィルタした場合の結果は、以下の通りです。 Countryでフィルタした結果 ここで、DateフィールドをMonthフィールドに変えた場合、フィルタした国の1ヶ月の数値として集計された結果になります。 月単位の集計結果 ディメンションとメジャーの挙動の違いを確認するため、active_users を dimension に変えて、反映してみます。 active_usersをディメンションにした場合 1ヶ月の集計結果は以下の図の通り、3行になってしまいます。 active_usersをディメンションにした結果 これは、active_users がディメンションであることにより、集計対象の数値ではなく、数字の1、2、3で分類する項目とみなされるようになったためです。意図した集計結果を出すためには、集計したい列をメジャーとして定義する必要があることがわかります。 日付データの修正をしなかった場合 date 列の元となった Google アナリティクス4のデータの event_date 列は日付を YYYYMMDD 形式で表示した文字列でした。 そして、その列から作成したサンプルデータの date 列は自動でスキーマを読み取った際に数字データとして取り込まれました。 そのため、生成されたままの date 列の定義では、数字のディメンションとして読み取られます。 修正する前の date 列の定義 date列の定義を修正しない場合 ここで、タイプによる挙動の違いを確認するため、date フィールドの type を string（文字列）に変えてみます。この状態では、日付データとしては認識されないことがわかります。 date 列を type:string に修正 type を string に修正した date 列 菊池 健太 (記事一覧) クラウドソリューション部データエンジニアリング課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。