Lookerとは｜LookMLの仕組みとTableauとの違い・案件単価
最終更新日：2026/09/21
Lookerとは、Google Cloudが提供するBIプラットフォームです。LookMLという独自言語で指標の定義を先に固め、そこからSQLを生成して分析する点に特徴があります。無料の「Looker Studio」とは別製品で、案件で求められるスキルも異なります。BIツールの実務経験があり、Looker案件への参画を検討しているフリーランスエンジニア向けに、LookMLの構造・運用フロー・単価の目安まで整理します。
先に結論
Lookerは「ダッシュボードを描くツール」ではなく、指標の定義をLookMLというコードに集約し、そこからSQLを生成させる仕組みが中心にある。
無料のLooker StudioとLookerは別製品。求人票に「Looker」とあっても、実態がLooker Studioのダッシュボード作成というケースがあるため、応募前に必ず確認する。
Tableau・Power BIとの一番の違いは描画力ではなく、指標定義がツールの外（LookMLファイル）にあり、Gitでバージョン管理される点。
案件を探すなら、BIツール名だけでなく「LookML」「BigQuery」「dbt」を併用して絞るのが実務的。Looker単独のタグを持たない媒体も多い。
単価は月60〜80万円の帯が中心。ただしこれは公開案件を観測した目安で、詳細は後述の母集団条件とあわせて読んでほしい。
この記事でわかること
LookMLのview・model・Exploreの役割分担と、SQLが生成されるまでの流れ
LookerとLooker Studio、Tableau・Power BIとの役割の違い
Git前提のLookML開発フローと、レビュー・デプロイの進め方
Looker案件の公開案件ベースの単価レンジと、評価されやすいスキル構成
BIツール経験者・SQL経験者・dbt経験者それぞれの入り方
目次
Lookerとは｜指標定義を先に固めるセマンティックレイヤー型BI
LookMLの仕組み｜view・model・Exploreの役割
LookMLのモデリング運用｜Git前提の開発フロー
LookerとTableau・Power BIの違い
Looker案件の動向と単価相場
ケース別｜Looker案件への入り方
LookML運用でつまずきやすい失敗と対策
Looker案件の実践チェックリスト
まとめ
よくある質問
Lookerとは｜指標定義を先に固めるセマンティックレイヤー型BI
Lookerは、データウェアハウス（DWH）に対してSQLを発行し、その結果を可視化するBIプラットフォームです。特徴は、可視化の前段にセマンティックレイヤー（売上や契約件数といった「指標の意味」を共通定義しておく層）を挟むことにあります。
一般的なBIツールでは、集計ロジックをダッシュボードごとに作り込みます。その結果、同じ「売上」でも画面によって数字が違う、という事態が起きやすくなります。Lookerはこの集計ロジックをLookMLというコードに書き出し、定義を一箇所に集約します。
Google Cloudの公式ドキュメントでも、LookMLは「SQL式を1回書けば、Lookerがそのコードを使って状況に応じたSQLクエリを繰り返し生成する」DRY原則の仕組みとして説明されています（Introduction to LookML｜Google Cloud）。つまりLookMLは、SQLを自動生成するだけでなく、指標定義を組織で共通化するための層として機能します。
LookerとLooker Studioは別の製品
ここを混同したまま案件に応募すると、面談で話が噛み合いません。
項目 | Looker | Looker Studio |
|---|---|---|
位置づけ | DWH接続前提のBIプラットフォーム | Webベースのレポート作成ツール |
料金 | 有償（プラットフォーム契約） | 無料版あり（公式） |
指標定義 | LookMLファイルに集約 | レポート・データソース側で定義する運用が中心 |
バージョン管理 | Gitリポジトリで管理 | Git前提の標準運用ではない |
求められるスキル | LookML・SQL・DWH設計 | GA4等の接続設定・可視化 |
名前が似ているうえ、日本語の比較記事の多くは「Looker Studio」側を扱っています。検索して出てきた情報がどちらの製品の話か、毎回確認するくらいで丁度いい。
Lookerが選ばれる場面
Lookerが候補に挙がるのは、複数部署が同じ指標を見る必要があり、かつ定義のズレが業務上の問題になっている組織です。逆に、一人のアナリストが自分用の分析を素早く回したいだけなら、LookMLの初期構築コストが重く感じられます。
ミニFAQ：Looker StudioからLookerの定義を使えますか？
Looker Studio側のコネクタからLookerのExploreに接続する構成は用意されています。ただし利用可否はライセンス条件によるため、契約内容を確認してください。
ミニFAQ：Lookerを使うにはBigQueryが必須ですか？
必須ではありません。Lookerは複数のSQLダイアレクトに対応しており、対応状況は公式のLooker dialectsで確認できます。対応範囲はバージョンによって変わるため、参画前に接続先の対応可否を確認してください。なお公開案件ではBigQueryとの組み合わせが頻出します。DWH側の選定観点はSnowflakeとは？データクラウドの特徴・BigQueryとの違い・案件動向をフリーランス視点で解説でも整理しています。
LookMLの仕組み｜view・model・Exploreの役割
LookMLの全体像は、3つの役割を押さえると一気に見通しが良くなります。「列の意味を決める」「テーブルの繋ぎ方を決める」「利用者に見せる入口」の3つです。
なお、これはファイル構成の話ではなく役割の整理です。実体としてはviewファイルとmodelファイルの2種類が中心で、Exploreはmodelファイルの中で定義されます。
viewファイル｜列の意味を定義する
viewファイルは、DWH上の1テーブルに対応し、そのテーブルの各列をどう扱うかを書く場所です。ここで定義するのが dimension と measure の2種類です。
dimension：テーブルの列に対応する項目。絞り込みやグループ化に使う（例：契約日、都道府県、職種）
measure：集計値。COUNTやSUMなどの集計関数を伴う指標（例：契約件数、売上合計、平均単価）
「売上」という言葉の定義が部署ごとにブレるなら、それをmeasureとして1回書き切る。これがLooker運用の出発点になります。
modelファイル｜テーブルの結合とExploreの定義
modelファイルには、どのDB接続を使うか、どのviewをどう結合するかを書きます。結合条件をここに集約するため、分析者が毎回JOINを書く必要がなくなります。
Explore｜分析者に開放する入口
Exploreは、modelファイルで定義された「分析の入口」です。分析者はExploreを選び、dimensionとmeasureをクリックで組み合わせます。裏側ではLookerがLookMLをSQLに変換し、DWHへ発行します。
SQLが生成されるまでの流れ
エンジニアがviewとmodelにLookMLを記述する
分析者がExploreで項目を選ぶ
Lookerが選択内容に応じてSQLを組み立てる
DWHでSQLが実行され、結果が可視化される
この一方向の流れを理解しているかどうかで、面談の受け答えがかなり変わります。「SQLを書かない人にSQLを書かせない仕組み」を作るのがLookMLエンジニアの仕事、と整理しておくと説明しやすい。
LookMLのモデリング運用｜Git前提の開発フロー
LookMLの運用がほかのBIツールと決定的に違うのは、開発がソフトウェア開発とほぼ同じ作法で進む点です。
Gitによるバージョン管理
LookMLプロジェクトは通常Gitリポジトリで管理されます。各開発者は開発モードで自分のブランチを持ち、変更をコミットし、プルリクエスト経由で本番ブランチへマージします。
つまりLooker案件では、BIツールの操作スキルよりもGit運用の経験が効いてくる場面があります。ブランチ戦略やコードレビューの経験は、そのまま持ち込めます。
開発モードと本番モードの分離
Lookerには開発モードがあり、作業中のLookMLは本人にしか見えません。検証を終えてからマージするため、本番の指標定義を壊さずに変更を試せます。この仕組みがあるおかげで、指標変更の影響範囲を事前に確認しやすくなっています。
変更時に確認すべきこと
指標定義を1箇所で管理するということは、1行の変更が全ダッシュボードに波及するということでもあります。measureの定義を変えるときは、そのフィールドがどのダッシュボードで使われているかを先に洗い出しておきます。
ミニFAQ：LookMLの習得にはどのくらいかかりますか？
LookMLは宣言的な記述で、SQLの実務経験があれば基本文法とview・modelの書き分けは比較的早く掴みやすい傾向があります。難所は文法ではなく、既存の業務定義をどうモデルに落とすかの設計判断です。公式のLookML学習ステップが学習順の参考になります。
LookerとTableau・Power BIの違い
比較の軸は描画機能ではありません。指標の定義をどこに置くかです。
観点 | Looker | Tableau / Power BI |
|---|---|---|
指標定義の置き場所 | LookMLファイル（ツール外・コード） | 主にワークブック／レポート内 |
定義の再利用 | 全Exploreで共通利用 | レポート単位での再利用が中心 |
バージョン管理 | Gitで差分管理 | ファイル単位の管理が中心 |
主な担当者 | LookMLを書くエンジニア | 分析者・BI担当者 |
厳密には、Tableau・Power BIにも共通のデータモデルを持つ仕組み（Power BIのセマンティックモデル等）はあります。違いは有無ではなく、Lookerがコードによる指標定義を運用の中心に据えている点にあると捉えてください。
Tableauは対話的な可視化の作り込みに強みがあり、Power BIはMicrosoft製品群との連携が評価される傾向があります。どちらが優れているという話ではなく、組織が「定義の統一」と「表現の自由度」のどちらを優先するかで選ばれ方が変わります。
各ツール単体の機能・料金・案件については、Tableauとは｜BIツールの特徴・できること・案件単価を解説とPower BIとは｜特徴・Tableauとの違い・案件単価をフリーランス視点で解説で詳しく整理しています。
なお、指標をコードで定義するという発想はdbtとは｜データ変換(ELT)の仕組み・使い方・案件単価とも重なります。dbtがDWH内の変換処理を担い、LookMLが参照時の指標定義を担う、という分担で併用される構成が案件でも見られます。
Looker案件の動向と単価相場
先に短答を書きます。Looker関連の公開案件は月60〜80万円の帯が中心で、上振れするのはデータ基盤の設計から任されるポジションです。
以下の数字は、2026年9月時点でフリーランス案件情報サイト2社（BIGDATA NAVI・ビズリンク）に掲載されていたLooker関連の公開案件、計48件を確認した観測ベースの目安です。首都圏の案件が中心で、週4〜5日稼働の準委任案件を想定しています。Looker単独の公開案件数はTableau・Power BIに比べると限られるため、レンジは参考値として読んでください。
公開案件で見られる単価レンジ
帯 | 月額の目安 | 案件内容の傾向 |
|---|---|---|
下限帯 | 55〜60万円 | 既存ダッシュボードの改修・レポート作成が中心 |
中心帯 | 60〜80万円 | LookMLでのモデリング、データマート構築 |
上位帯 | 90〜100万円 | DWH設計を含むアナリティクスエンジニア相当 |
突出例 | 160万円 | 少数。基盤全体のリード・コンサル領域 |
非公開案件については別の話として切り分けてください。エージェント面談で提示される案件は個別条件で上振れすることがありますが、公開案件のように件数で傾向を確認できるものではありません。
自分がどのくらいの単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。
募集要件で頻出するスキル
観測した公開案件の必須要件では、次の組み合わせが繰り返し出てきます。
SQLによるデータ抽出・集計の実務経験（2〜3年以上の記載が多い）
BigQuery・Snowflake等のクラウドDWHの利用経験
LookMLまたは他のBIツールでのモデリング経験
Gitを使ったチーム開発の経験
LookML未経験でも、SQLとDWHの経験があれば候補に入る募集は見られます。逆に、可視化の操作経験だけでは中心帯に届きにくい。
上位帯を狙える人の像
月90万円以上の募集で求められているのは、BIレイヤー単体ではなくデータ基盤全体を見られる人です。具体的には、DWHのテーブル設計を自分で引いた経験があり、ELTパイプラインの運用まで理解していて、事業部門と指標定義をすり合わせた経験がある層。BIツールの習熟度よりも、設計と合意形成の経験が効きます。
BIレイヤーを含むデータ基盤案件全体の単価感はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル、BI職種としての市場観はBIエンジニアのフリーランス単価相場｜Tableau・Power BI案件の実情を参照してください。
ミニFAQ：Looker案件はどこで探すのが効率的ですか？
Looker専用のタグを持たない媒体が多いため、「LookML」「BigQuery」「データ基盤」のキーワード検索を併用します。フリコンの案件一覧でも、DWH・BI関連の募集を確認できます。
ケース別｜Looker案件への入り方
Tableau・Power BIの実務経験がある場合
可視化の経験はそのまま活きますが、面談ではLookMLを書く側に回れるかを見られます。SQLの読み書きに加えて、「同じ指標が画面ごとに違う数字になる問題をどう解決したか」を語れると説明が通りやすくなります。BI職種としての全体像はBIエンジニアとは｜仕事内容・年収・データアナリストとの違いをフリーランス視点で解説にまとめています。
SQL・DWHの経験がある場合
こちらが最短ルートです。LookMLはSQLを置き換える言語ではなく、SQLを生成させるための記述なので、SQL設計ができる人ほど飲み込みが早い。BigQueryとは？特徴・できること・データ分析案件の単価をフリーランス視点で解説で扱うようなDWH側の知識は、そのまま面談材料になります。
dbtの経験がある場合
dbtで変換層を組んだ経験があるなら、LookMLとの役割分担を説明できる時点で強い。「どこまでをdbtのモデルで持ち、どこからをLookMLのmeasureで持つか」は実運用で必ず論点になるため、自分なりの判断基準を用意しておくと評価されます。
LookML運用でつまずきやすい失敗と対策
measureを増やしすぎて定義が迷子になる
依頼されるまま指標を足していくと、似た名前のmeasureが並び、結局どれが正なのか分からなくなります。命名規則と、指標を追加する際の承認フローを最初に決めておきます。
ダッシュボード側でロジックを書いてしまう
急ぎの依頼に対応するため、Explore上のカスタムフィールドで計算を作り込むケース。これをやると定義がLookMLの外に漏れ、Lookerを使う意味が薄れます。暫定対応にする場合も、LookMLへ戻す期限を決めておくのが安全です。
影響範囲を確認せずにmeasureを変更する
前述のとおり、1箇所の変更が全社のダッシュボードに波及します。変更前に利用箇所を洗い出す手順を運用に組み込んでおきます。
権限設計を後回しにする
部署ごとに見せてよいデータが違う場合、行レベルのアクセス制御が必要になります。構築が進んでから設計し直すと手戻りが大きいため、初期のモデリング段階で要件を確認しておきます。
Looker案件の実践チェックリスト
参画前・参画直後に確認しておくと、認識のズレを防げます。
求人票の「Looker」がLookerかLooker Studioか確認したか
既存のLookMLプロジェクトがGit管理されているか
開発モードと本番の運用ルールが決まっているか
接続先DWHはどれか（BigQuery／Snowflake／Redshift等）
dbt等の変換層が既にあるか、役割分担はどうなっているか
指標定義の意思決定者（事業部門の担当）が誰か
measure変更時のレビュー・承認フローがあるか
行レベルのアクセス制御要件があるか
既存ダッシュボードの棚卸しがされているか
まとめ
Lookerは指標定義をLookMLというコードに集約し、そこからSQLを生成させるBIです。可視化ツールとしてではなく、指標ガバナンスの仕組みとして捉えると案件の要件が理解しやすくなります。
LookMLはview（列の意味）・model（結合とExplore）の2種類のファイルが中心で、GitとPRで運用される
無料のLooker Studioとは別製品。求人票の表記は応募前に必ず確認する
Tableau・Power BIとの違いは描画力ではなく、指標定義をツール外のコードに置くかどうか
公開案件の単価は月60〜80万円が中心帯。90万円以上はDWH設計を含むポジションが中心
SQL・DWHの実務経験があるなら、LookML未経験からでも候補に入る募集は見られる
次のステップとしては、まず接続先DWHの知識を棚卸しし、そのうえでLookMLの基本文法に触れてみてください。案件を探す段階なら、案件一覧でデータ基盤・BI関連の募集要件を確認し、自分のスキルとの差分を把握するところから始めると動きやすくなります。
参照した一次情報は以下のとおりです。
よくある質問
LookMLはプログラミング未経験でも書けますか？
文法自体は宣言的で、SQLの経験があれば習得のハードルは高くありません。ただし案件で求められるのは文法知識ではなく、業務上の指標定義をモデルに落とす設計力です。未経験からいきなり単独で任される募集は限られます。
Looker Studioの経験はLooker案件で評価されますか？
可視化やデータソース接続の経験として一定の評価は受けますが、LookMLのモデリング経験とは別物として扱われます。職務経歴書では、どちらの製品を使ったかを明記してください。
LookerとTableauはどちらを学ぶべきですか？
案件数の観点ではTableau・Power BIのほうが募集の幅が広く、BI領域の入口としては入りやすい。一方、DWH設計やデータ基盤側にキャリアを寄せたいならLookerとLookMLの経験が効きます。目指す方向で選び分けるのが現実的です。
LookMLの資格はありますか？
執筆時点では、Google CloudがLooker関連の認定資格を提供しています。資格の構成や実施状況は改定されることがあるため、受験を検討する場合はGoogle Cloud認定資格の公式ページで最新情報を確認してください。取得が必須要件になっている公開案件は多くありませんが、LookML未経験から応募する際の補強材料にはなります。
Looker案件はリモート可が多いですか？
観測した公開案件では、フルリモートまたは週1〜2日出社の記載が目立ちます。ただしデータの取り扱い上、セキュリティ要件からオンサイトを求める案件もあります。
週2〜3日稼働のLooker案件はありますか？
公開案件では週4〜5日が中心で、稼働日数の少ない募集は限られます。短稼働を狙う場合は、Looker単独ではなくデータ基盤・分析基盤の支援として切り出された案件を探すほうが見つかりやすい。
LookMLとdbtは競合しますか？
競合ではなく、担当するレイヤーが違います。dbtはDWH内でテーブルを作る変換処理、LookMLは参照時に指標をどう計算するかの定義です。両方を導入している現場も見られます。
既存のLookMLプロジェクトを引き継ぐ際、最初に何を見るべきですか？
modelファイルのExplore定義とJOIN条件から読むのが効率的です。どのviewがどう繋がれているかが分かると、全体構造を把握しやすくなります。次にmeasureの一覧と命名規則を確認します。
Lookerの料金はいくらですか？
契約形態や利用条件で変わるため、公開情報だけでは総額を一律に判断しにくい製品です。フリーランスとして参画する場合はクライアント側の契約範囲になるため、詳細はLooker公式を参照してください。
BIエンジニアとアナリティクスエンジニアは何が違いますか？
明確な定義があるわけではありませんが、公開案件を見る限りでは、BIエンジニアは可視化・レポート側、アナリティクスエンジニアはDWH内のモデリング側に重心があります。LookMLの担当者は、両者の中間に位置づけられることが多いようです。
