ClaudeにLooker Studioの計算フィールドを書かせ、式を検算する

Looker Studioの計算フィールドは、SQLに似ていてSQLではありません。Claudeに式を頼むと、BigQueryやPostgreSQLの書き方がそのまま混ざった式が返ってくることがあります。貼り付けた瞬間にエラーになる式はまだ親切で、困るのは、エラーなしで違う値が出る式です。

この記事では、Claudeに計算フィールドの式を書かせる前に渡すもの、書かせたあとに潰す3つの誤り、手元で期待値を確かめる検算の順に進めます。題材は、URLからのパス抽出(REGEXP_EXTRACT)と、流入元の分類(CASE)です。

なお、Googleのドキュメントでは製品名がLooker StudioからData Studioに変わっています。画面やドキュメントでData Studioと出てきても、同じ製品の話です。この記事ではLooker Studioで通します。

式の誤りは3種類に分かれる

Claudeが書いた式の誤りは、見つかり方で3つに分けると直しやすくなります。

1つ目は目で見つかります。2つ目と3つ目は、式の文面だけを眺めても見つかりません。だから、期待値を先に決めて、実際の出力と突き合わせる手順が要ります。

スキーマと期待値を先に渡す

式を頼む前に、Claudeには次の3点を渡します。

• フィールド名とデータ型の一覧(データソースの画面のスクリーンショットでよい)
• 入力の例を3〜5行
• その行に対して返ってほしい値

Claude Codeは画像を会話に取り込めます。ターミナルへのドラッグ&ドロップ、Ctrl+V での貼り付け(WindowsとWSLは Alt+V)、画像パスの指定の3通りです。データソースのスキーマ画面を貼ったうえで、次のように頼みます。

添付はLooker Studioのデータソースのスキーマ画面です。
Page URLからトップのパス区間(例: /blog/ の blog)を取り出す計算フィールドを
作ります。入力と期待値は次の表のとおりです。
 
Page URL                                      期待値
https://example.com/blog/claude-tips?utm=x    blog
https://example.com/                          (空)
https://example.com/docs/api                  docs

スクリーンショットは、フィールド名の綴りとデータ型を確定させる役に立ちます。計算フィールドのデータ型は式に使う関数で決まります。SUM や COUNT のような集計・算術の関数なら数値、CONCAT や SUBSTR のような文字列の関数ならテキストです。型を取り違えた式は、あとでグラフに載せるときに困ります。

期待値の表が大事なのは、2行目のような「取り出せない行」の挙動を、頼む側が先に決めておけるからです。Claudeに任せると、ここは黙って流されがちです。

関数の許可リストをCLAUDE.mdに置く

存在しない関数名への対策は、使ってよい関数を先に書いておくことです。Looker Studioの関数一覧には、SPLIT も SAFE_DIVIDE も ILIKE も載っていません。文字列の先頭を取るのは LEFT ではなく LEFT_TEXT です。SQLに慣れたモデルほど、ここで間違えます。

プロジェクトの CLAUDE.md に、次のような節を置きます。

## Looker Studio 計算フィールド
 
- 使う関数は Looker Studio の関数一覧にあるものだけ。SQL の関数を持ち込まない
- 文字列: CONCAT / SUBSTR / LEFT_TEXT / RIGHT_TEXT / LOWER / TRIM /
  CONTAINS_TEXT / REGEXP_EXTRACT / REGEXP_MATCH / REGEXP_CONTAINS / REGEXP_REPLACE
- 条件: CASE / IF / IFNULL / NULLIF / COALESCE
- 正規表現は RE2 構文。バックスラッシュを含むパターンは R'...' で書く
- REGEXP_MATCH は全体一致。部分一致は REGEXP_CONTAINS を使う
- 式を出すときは、入力例ごとの期待値の表を一緒に出す

許可リストは網羅しなくて構いません。使う予定の関数だけで足ります。リストにない関数が必要になったら、Claudeが「リスト外の関数を使いたい」と言う前提にしておくと、黙って持ち込まれません。

REGEXP_EXTRACTで抽出する

ドキュメントのサンプルは、REGEXP_EXTRACT(Campaign, 'TYPE:(.*)') の形です。取り出したい部分を括弧で囲み、戻り値はテキスト型になります。ドキュメントの別の例では、URL https://support.google.com/looker-studio/answer/7050487 から looker-studio を取り出しています。

先ほどのPage URLの例なら、式は次のようになります(ドキュメントの例に沿った形です)。

REGEXP_EXTRACT(Page URL, R'^https://[^/]+/([^/]+)/')

R'...' はraw文字列リテラルです。\ を含むパターンは、通常の文字列だと追加のエスケープが要ります。raw文字列にすれば避けられると、ドキュメントに書かれています。Claudeに書かせるときは、\d や \. を使うパターンで R'...' が付いているかを必ず見ます。

この式で期待値の表を埋めると、次のとおりです。

2行目は、ホストのあとに / はあっても、続くパス区間がありません。括弧の中に何も入らないので、一致しません。この行をレポートでどう見せたいか(空欄のままか、「トップ」と置き換えるか)は、式を足す前に決めておきます。置き換えるなら IFNULL や COALESCE が使えます。

CASEとREGEXP_MATCHの全体一致に注意する

流入元の分類は、CASE で書くのが定番です。ドキュメントの例は、国名を地域に振り分ける次の形です。

CASE
    WHEN Country IN ("USA","Canada","Mexico") THEN "North America"
    WHEN Country IN ("England","France") THEN "Europe"
    ELSE "Other"
END

条件は上から順に評価され、最初に真になった WHEN の結果が返ります。どれも真にならず ELSE もなければ、結果は NULL です。ELSE を省いたまま、集計で「その他」が消えて合計が合わなくなる、というのが典型的な事故です。

Claudeに「Source Mediumに cpc を含む行をPaidにして」と頼むと、次のような式が返ることがあります。

CASE
    WHEN REGEXP_MATCH(Source Medium, R'cpc') THEN "Paid"
    WHEN REGEXP_MATCH(Source Medium, R'email') THEN "Email"
    ELSE "Other"
END

一見よさそうですが、REGEXP_MATCH は文字列全体が一致したときだけ真を返します。ドキュメントの例でも、REGEXP_MATCH(field_expression, 'A') に ABC123 を入れると false で、'A.*' なら true です。google / cpc に対して R'cpc' は false になります。エラーは出ず、全行が Other に落ちます。

部分一致で分類したいなら、REGEXP_CONTAINS に替えます。

CASE
    WHEN REGEXP_CONTAINS(Source Medium, R'cpc|ppc') THEN "Paid"
    WHEN REGEXP_CONTAINS(Source Medium, R'email') THEN "Email"
    WHEN REGEXP_CONTAINS(Source Medium, R'organic') THEN "Organic"
    ELSE "Other"
END

CONTAINS_TEXT という選択肢もありますが、大文字と小文字を区別します。表記ゆれがある流入元には正規表現のほうが向きます。

手元のPythonで期待値と突き合わせる

式を貼る前に、Claude Codeで検算用のスクリプトを作らせます。Looker Studioの正規表現はRE2構文で、Pythonの re と完全には同じではありません。それでも、全体一致か部分一致かの区別と、取り出しの結果は確かめられます。

import re
 
def extract(x, p):            # REGEXP_EXTRACT: 最初の一致の括弧部分
    m = re.search(p, x)
    return m.group(1) if m else None
 
def match(x, p):              # REGEXP_MATCH: 全体一致
    return re.fullmatch(p, x) is not None
 
def contains(x, p):           # REGEXP_CONTAINS: 部分一致
    return re.search(p, x) is not None
 
urls = ["https://example.com/blog/claude-tips?utm_source=x",
        "https://example.com/",
        "https://example.com/docs/api"]
for u in urls:
    print(extract(u, r"^https://[^/]+/([^/]+)/"))
 
for sm in ["google / cpc", "newsletter / email", "google / organic"]:
    print(match(sm, r"cpc"), contains(sm, r"cpc|ppc"))

上のスクリプトの出力は、次の6行です。

blog
None
docs
False True
False False
False False

後半の3行が、match と contains の結果の組です。1行目の google / cpc だけ、全体一致が False、部分一致が True と食い違います。

同じ結果を、期待値の表に直して比べます。

全体一致の式は、検算の時点で google / cpc を拾えていません。画面上で全行が Other に落ちる症状と一致します。

検算を頼むときは、次のように指示します。

上の式を Python に直して、期待値の表の全行を通してください。
差が出た行は、式のどこが原因かを1行ずつ書いてください。
Looker Studio で使える関数だけを使った式に直したら、もう一度通してください。

置換・日付の式でも同じ型を使う

REGEXP_REPLACE は、引数が3つです。サンプルは REGEXP_REPLACE(Campaign, '(Sale):(Summer)', '\\2 \\1') で、括弧で取った2つの部分を入れ替えて返します。置換先の \\2 は、2つ目の括弧で取った部分を指します。Pythonの re.sub では \2 とバックスラッシュ1本で書くので、式を写し替えるときは本数を揃えます。

日付の式は、関数の定義を読み違えやすい領域です。DATETIME_DIFF は「2つの日付のあいだにある単位の境界の数」を返します。文字列を日付にするなら PARSE_DATETIME("%d/%m/%Y %H:%M:%S", DateTimeText) のように、書式文字列を先に置きます。Claudeが引数の順を逆にした式を返したら、サンプルの形と見比べます。

どの関数でも、頼み方は同じです。入力例と期待値を渡し、式を出させ、手元で全行を通します。関数ごとの癖は、通らなかった行を見れば分かります。

式の修正を繰り返すときの頼み方

検算で差が出たら、式の全文を書き直させず、差が出た行から原因を言わせます。たとえば「3行目だけ期待値と違う。式のどの部分が原因か、1つずつ挙げて」と頼みます。全文を書き直させると、直ったはずの行が崩れることがあります。

直したあとは、前に通っていた行を含めて、表の全行をもう一度通します。期待値の表は、レポートを直すたびに増やしておくと、次に式を変えるときの回帰テストになります。表は、チームで共有するリポジトリのCSVにしておくと、担当が替わっても残ります。

データソース側かグラフ側か

式が正しくても、作る場所で使えないことがあります。計算フィールドは、データソースに作る方法と、グラフ単位で作る方法の2通りです。違いは次の表のとおりです。

Claudeには、どちらに作るかも伝えます。流入元の分類を複数のグラフで使い回すなら、データソース側です。ブレンドしたデータに対する式なら、グラフ側でしか作れません。グラフ側の項目が他のグラフ側の項目を参照する式は、同じグラフ内でも作れないので、参照が必要なら部品をデータソース側に移します。

集計の指定にも気をつけます。Price * Quantity Sold のように集計関数を含めない式をデータソースに作ると、行ごとの値になり、グラフでは既定の合計集計が掛かります。利益率のような比は SUM(Profit) / SUM(Revenue) と書いて、集計の方法を式に明示します。Claudeに比率を頼むときは「集計はSUMを式の中に書く」と添えると安全です。

条件を絞るだけなら計算フィールドを書かない

固定のラベルに振り分けるだけなら、CASE を書かなくても済みます。Looker Studioには、グラフ単位で作れるカスタムグループとカスタムビンがあります。ドキュメントの例では、州を地域にまとめるのがカスタムグループ、公開年を10年ごとの区間にまとめるのがカスタムビンです。

条件が単純な値の列挙なら、画面の操作で作るほうが、式の誤りを持ち込みません。正規表現で部分一致させる、複数の条件を組み合わせる、といった場面だけ、Claudeに式を書かせるのが整理しやすい分担です。

つまずきやすい点

• フィールド名にスペースがあっても、ドキュメントの例では引用符なしでそのまま書かれています。名前を勝手に変えた式が返ったら、スキーマ画面の綴りと照らします
• Supermetricsなどでデータを持ち込む接続の話と、計算フィールドの式の話は別の作業です。接続の手順はClaudeとSupermetricsを連携する方法にまとめています。式の検算は、接続が済んだあとのレポート側の作業になります
• 検算の型(期待値を先に決め、出力と突き合わせる)は、Excelの式でも同じです。例はゲージR&RをExcelで計算し判定基準で読むにあります
• Claudeが「このフィールド名は存在しない」と言ってきたら、スクリーンショットを貼り直します。型の取り違えもここで見つかります

まとめ

Looker Studioの式は、SQLの記憶で書くと壊れます。ただし、壊れ方はたいてい3種類に収まります。存在しない関数名は CLAUDE.md の許可リストで、全体一致の見落としは期待値の表で、作る場所の制約はデータソースかグラフかを先に決めることで防げます。

依頼の最初に入力例と期待値の表を渡す、というのがいちばん効く一手です。式の出来を眺めて判断するより、表の全行が通ったかを見るほうが、早くて確実です。