メインコンテンツへスキップ
  1. 記事/

Claude CodeでPM業務:第2章 - データ

Nuno Coração
著者
Nuno Coração
Principal Product Manager @ Docker
目次
PMing with Claude Code - この記事は連載の一部です
パート 2: この記事

第1章では、Claude CodeをPMのコマンドセンターとしてセットアップする方法について書いた。GitHubのイシュー、Notionのドキュメント、ローカルの戦略ファイル、すべてを一つのターミナルでつなげた。その中で最大のギャップとして挙げたのがデータだった。LookerやSigmaから手動でCSVをエクスポートして、フォルダに放り込んでいた。動きはするが、摩擦が大きかった。そのギャップは今、解消された。

欠けていたピース:SQLアクセス
#

問題はClaudeがデータを分析できないことではなかった。CSVを渡せばパターンを見つけ、トレンドをまとめ、考察を下書きしてくれる。問題はそもそもデータをClaudeに渡すまでの過程だった。最新の数値が必要になるたびに、ブラウザを開き、ダッシュボードに移動し、ファイルをエクスポートし、ワークスペースに移す必要があった。Claudeがデータを手にする頃には、5秒で済むべきことに5分を費やしていた。

解決策は振り返れば当然のことだった。Claudeにデータウェアハウスへの直接アクセスを与えればいい。分析基盤はSnowflakeにあり、SnowflakeにはCLIがある。(Abhiに感謝!)

Snowflake CLIのセットアップ
#

Snowflake CLIsnow)は、Snowflakeと対話するためのコマンドラインツールだ。インストールして接続を設定すれば、ターミナルから直接SQLクエリを実行できる。つまり、Claudeも実行できるということだ。

接続設定は~/.snowflake/connections.tomlに置く:

[my_org]
account = "your-account"
user = "your-user"
authenticator = "externalbrowser"
role = "ROLE_READONLY"
warehouse = "your-warehouse"

いくつか注目すべき点がある。externalbrowser認証は、認証が会社のSSOを経由することを意味する。ブラウザで一度認証すれば、セッションが維持される。設定ファイルにAPIキーやパスワードが残ることはない。そしてロールはリードオンリーだ。Claudeはデータをクエリできるが、何も変更できない。第1章のGitHub権限と同じ考え方で、ツールには必要な権限だけを与え、それ以上は与えない。

接続をセットアップすれば、クエリの実行はコマンド一つだ:

snow sql -c my_org -q "SELECT COUNT(*) FROM my_table" --format json

そして、Claudeにいくつかのテーブル、スキーマ、よくあるクエリパターンを探索してCLAUDE.mdにドキュメント化するよう指示した。それが終わってから、いくつかの計算値の詳細について議論し、SQLに反映できるようにした。Claudeは以下のような内容を記録した:

## Snowflake Access
- CLI: `snow sql -c my_org -q "..." --format json`
- Role: read-only
- Key tables:
  - `MARTY.ENTITIES.L3_DIM_MOBIULE>__USER` - User dimension
  - `PREP.AI_SERVICE.L1_AI_TRACE` - API event traces
- The ATTRIBUTES column is a JSON variant with: username,
  planName, model, origin, gordonTag, token counts, cost, etc.

これは第1章と同じパターンだ。CLAUDE.mdがClaudeに正しいクエリを書くために必要なコンテキストを提供するので、毎回スキーマを説明する必要がない。そして自分で書く必要もなく、Claudeに記録してほしい情報をキャプチャするよう依頼すればいい。

リテンション分析
#

ここからが面白くなった。AIアシスタントの5つの異なるプロダクトバージョンにおける初週リテンションを把握する必要があった。各バージョンは異なる機能、異なるUX、異なるオンボーディングフローでリリースされていた。問いはシンプルだった:最初の7日間で最もユーザーを維持したのはどのバージョンか?

従来のワークフローでは、これは数日の作業と他チームとの依存関係が必要だった。Snowflakeを開き、どのバージョンタグがどのリリースに対応するか調べ、コホートクエリを書き、実行し、エクスポートし、スプレッドシートを見つめ、パターンを見つけようとする。あるいはデータアナリストに依頼して、彼らのキューが空くのを待つ。

Claudeには、必要なものを自然言語で説明した:

「過去5つのメジャーバージョンにおけるGordonの初週リテンションを比較して。」

ClaudeはCLAUDE.mdからスキーマをすでに知っていた。gordonTagがプロダクトバージョンを識別すること、EVENT_TIMESTAMPがイベント発生時刻を追跡すること、ユーザーの識別方法も把握していた。SQLを書き、Snowflake CLIで実行し、結果を取得し、比較テーブルにフォーマットした。

5分もかからず結果が出た…

得意なこと(と苦手なこと)
#

これが何を置き換え、何を置き換えないのか、はっきりさせておきたい。

ダッシュボードは作らない。 毎日更新される永続的で共有可能なビジュアライゼーションが必要なら、LookerやSigma、チームが使っているツールを引き続き使うべきだ。Claudeは問いに答える。モニタリングインフラを作るわけではない。

データチームの代わりにはならない。 複雑なデータモデリング、パイプライン構築、ウェアハウスの最適化はエンジニアリングの仕事だ。Claudeは既存のテーブルに対してアドホッククエリを実行しているのであって、新しいデータモデルを構築しているわけではない。

Claudeがやってくれるのは、問いから答えまでの時間を圧縮すること。 PMのワークフローには常にこのボトルネックがあった。問いを思いつき、データの所在を特定し、クエリを書くか依頼し、結果を待ち、解釈し、追加の問いを考え、サイクルを繰り返す。セルフサービスできるかどうかで、各サイクルに数分から数日かかる。

Claude + Snowflake CLIなら、このサイクルは会話的になる。質問、クエリ、結果、追加質問 - すべて同じターミナルセッションで、すべて数秒で完了する。このスピードが働き方を変える。より多くの問いを投げかける。より多くの仮説を探索する。確認コストが非常に低いため、見逃していたであろうことに気づける。

複合効果
#

本当の力は単一の統合にあるのではない。その組み合わせにある。一つの会話の中で、Claudeは以下ができる:

  1. 最新のGitHubイシューを取得して、各バージョンで何がリリースされたかを確認する
  2. Snowflakeにクエリを投げて、それらのバージョンのリテンションデータを取得する
  3. Notionで各リリースの背景にあるプロダクト判断を検索する
  4. すべてをクロスリファレンスして、サマリーを下書きする

4つのツール、4つの異なるデータソースが、一つの会話で統合される。コンテキストが引き継がれる。バージョンXにリテンションの低下があると分かれば、Claudeはすぐにそのリリースで何が変わったかGitHubイシューを確認し、Notionのドキュメントでその判断の理由を調べられる。タブの切り替えも、ツール間のデータコピーも不要だ。

これが第1章で言った、Claudeが単なるAIアシスタントではなくワークフローハブであるということだ。新しい統合を追加するたびに、既存の統合すべての価値が倍増する。

更新されたセットアップ
#

参考までに、現在のワークスペースは以下のようになっている:

pm-workspace/
├── CLAUDE.md                # ワークフロー規約、テンプレート、Snowflakeスキーマ
├── .claude/
│   └── settings.local.json  # 権限: gh, snow sql, MCPサーバー
├── docs/                    # 戦略ドキュメント、分析、仕様
├── data_reports/            # エクスポートデータ(大規模データセットには引き続き有用)
└── roadmap.md               # 常に更新されるロードマップ

権限も増えた:

{
  "permissions": {
    "allow": [
      "Bash(gh issue list*)",
      "Bash(gh issue view*)",
      "Bash(gh issue create*)",
      "Bash(gh project*)",
      "Bash(gh api*)",
      "Bash(snow sql*)"
    ]
  }
}

1行追加しただけだ。「手動でCSVをエクスポート」から「Claudeにウェアハウスを直接クエリさせる」に変わるのに、それだけで十分だった。

次のステップ
#

data_reports/フォルダは廃れていない。大規模データセットや複雑なビジュアライゼーションには、エクスポートは依然として理にかなっている。しかし日常的なPMの問い - 「リテンションのトレンドは?」「プラン別の利用率は?」「先週この機能を使ったユーザーは何人?」 - もうブラウザを開くことはない。

第1章で挙げた残りのギャップは縮まりつつある。NotionはMCP経由で接続済み。GitHubはCLI経由で接続済み。SnowflakeはCLI経由で接続済み。まだ足りないのは、Google Docs(MCPがまだない)、Slack(MCPは存在するがまだセットアップしていない)、そしてカレンダー連携だ。追加するごとに、システム全体がより便利になる。

CLIアクセスのあるデータウェアハウスを使っているPMなら、これはClaude Codeのセットアップに追加できる最もレバレッジの高いものだ。Claudeが書くクエリは最初から完璧とは限らない。しかしイテレーションループが非常に速いので、それは問題にならない。30秒で3つの不完全なクエリを試す方が、1時間かけて1つの完璧なクエリを書くよりも勝る。

重要なのは完璧さではない。インサイトに至るスピードだ。

PMing with Claude Code - この記事は連載の一部です
パート 2: この記事

関連記事