はじめに
はじめまして。データサイエンスグループで機械学習エンジニアをしている25新卒の森です。 私は主に機械学習を用いた検索ランキング改善に携わっています。
今回は、データ組織への「Claude Code」導入について、その概要と実際の活用状況を共有します。
導入概要については、Google Cloud (Vertex AI) 基盤を活用した導入/運用方法に焦点を当てています。
利用状況については、よく利用される場面と利用されない場面を整理し、さらにデータ分析特有の課題とその対策についても説明します。
導入の概要：Google Cloud基盤を活用した運用
私たちのチームでは、既存のGoogle Cloud基盤を活用して導入しました。 具体的なポイントは以下の通りです。
- 導入経路: Vertex AI Model Garden経由
- 予算管理: 1人あたり月額150ドル（Google CloudのBudget Alertsで監視）
- 利用モデル: Claude Sonnet 4.0 & 4.5 / Claude Opus 4.1
2025年8月から準備を始め、9月末にはチーム全体で利用可能な状態になりました。
なお、Vertex AI経由での具体的なセットアップ手順については、Anthropic公式ドキュメントが詳しく参考になります。
導入経路の詳細
Anthropic API経由ではなくVertex AI経由を選択したのは、 既存のGoogle Cloudプロジェクトに統合することで、権限管理や請求処理を簡単に実現できる というメリットがあったためです。
両者の違いを以下に示します。
| 項目 | Anthropic API経由 | Vertex AI経由 |
|---|---|---|
| 課金・請求 | Anthropic | Google Cloud |
| 権限管理 | Anthropic APIキーの発行・管理 | Google Cloud IAMで一元管理 |
| 予算監視 | Claude Consoleで設定 | Google Cloud Budget Alertsで設定 |
私たちのクラウド環境はGoogle Cloudを中心に構築されているため、同じプラットフォーム上で完結できるのは大きな利点でした。
なお、会話データをモデル学習に使用しない設定は、どちらの経路でもデフォルトで有効になっています。 詳細についてはAnthropic公式ドキュメントのデータ使用ポリシーをご参照ください。
予算管理の詳細
1人あたり月額150ドルという予算は、社内で先行導入していた他チームの実績値を参考に決定しました。
Google CloudのBudget Alertsの設定では、G-gen Tech Blogを参考にSlack通知を設定しました。
下記は実際の通知例です。予算の50%、90%、100%に到達した際にそれぞれメッセージが届きます。
チームでの活用状況
費用管理実績
導入から数ヶ月が経過し、予算消化率は50〜80%程度で推移しています。 多くのメンバーが日常的に利用しており、1人あたり月額150ドルの予算設定で問題なく運用できています。
次に、チームメンバーへのヒアリングをもとに、Claude Codeの「使える場面」と「厳しい場面」について共有します。
✅ 活用できているケース
以下のようなコーディング支援タスクでは、多くのメンバーが恩恵を受けています。
- バッチ処理のPR作成
- PRコメントやREADMEなどのドキュメント作成の壁打ち
- テストコードの実装
- 単純なユーティリティ関数の実装
また、過去事例のあるデータ分析タスクでも活用が進んでいます。
⚠️ 活用が難しかったケース
一方で、以下のようなケースでは、今のところ期待通りの成果が出ていませんでした。
- 一般的でない独自手法の実装: ネット上に情報が少ない社内独自の手法などは、使う側の深い理解が必要で、制御が難しい
- レポーティング業務: Confluenceなどテキストファイル以外へのアウトプットや、複雑なフォーマット調整は苦手
データ分析特有の課題と技術的解決策
ここからは、Web開発とは少し異なる、データ分析ならではの「つまずきポイント」とその解決策を紹介します。
課題1：Jupyter Notebook (.ipynb) のトークン爆発
私たちのチームではPoCや施策の効果測定・深掘り分析の際、主にJupyter Notebookを使っています。1つのNotebookで十数枚のグラフを出力することも珍しくありません。
Jupyter Notebookの実体はJSONファイルであり、出力結果（グラフ画像など）がBase64文字列として埋め込まれています。 これをそのままClaude Codeに読ませると、「Read時にトークン消費が爆発し、会話の圧縮（Compacting）が頻発する」 という問題が発生しました。 (ちなみに、Jupyter Notebookの読み込みが重いことは、すでにAlex Molas氏の個人のブログで言及されていました)
解決策：カスタムMCPサーバーによる前処理
この問題に対し、チームメンバーがプロキシとなるカスタムMCP（Model Context Protocol）サーバーをPython用sdkで開発しました。
このMCPサーバーは、Claude Codeにファイルを渡す前に 「不要なメタデータの削除」「Base64画像の分離」「軽量化」 を自動で行います。
たとえばClaude Codeとの対話時、以下の通りに指示して利用します。
# 通常 このnotebookを読んで分析してください: /path/to/analysis.ipynb # セル範囲指定 セル50から55までを読み込んでください: /path/to/analysis.ipynb
結果として、Notebook読み込み時のトークン消費を数十％削減することに成功しました。
課題2：BigQueryでのデータ抽出加工時の考慮漏れ
Claude Codeから bq コマンドを直接叩けるのは非常に強力です。
たとえば私はつぎのように指示してBigQueryのデータを抽出します。
データソースを確認する場合は、以下のコマンドを使ってください: bq query --format=csv 'select * from `project.dataset.table` where ...'
しかし、私のような新卒メンバーは、社内の膨大なデータに対してどこにどのようなデータがあるのか把握しきれていません。 その状態でClaude Code任せにクエリを書かせると、「存在しないテーブルを推測で参照する」「データの意味を誤解して集計する」といった問題がよく発生しました。
解決策：プロンプトの工夫
これらの問題を防ぐため、私個人はM3 Tech Blogも参考にしつつ、以下の3点をプロンプトや設定のコツとして意識するようにしました。
- いきなりクエリを書かせず、まずはデータの所在を確認させるステップを挟む
- テーブル情報をコンテキストとして蓄積させるために、主要なテーブル定義は
.claude/table_info.md,.claudercにまとめておいて、実行時に参照してもらう - データの探し方を教えておく。具体的には、データカタログやメタデータ検索の方法を指示する
特に3点目の「データの探し方」について、元記事では data-catalog search が紹介されていますが、現在はGoogle Cloud公式ドキュメントでは dataplex entries search が推奨されています。
そのため、CLAUDE.md 等に以下のコマンドを利用するよう指示を含めています。
データソースがどこかわからなくなった場合、以下のコマンドでスキーマ情報を検索できます:
$ gcloud dataplex entries search {query} --project={project}
とはいえ、こうした工夫で改善はしたものの、根本的な難しさはデータの持つコンテキストの深さにあります。
コンペティションのように目的と範囲が限定されたデータセットであればClaude Code等コーディングエージェントも比較的スムーズに力を発揮できる可能性が高いですが、実務のデータ環境は事情が異なります。
もちろん社内では関連部署の方々によってデータマート等の整備が進められていますが、長期にわたるサービスの歴史や膨大な事業規模ゆえに、そこに含まれるドメイン知識や文脈もまた膨大になります。
これまで限られてきたデータ量しか触ってこなかったので、こういった環境はできることも多くて嬉しい反面、コーディングエージェントにとっては「迷子になりやすい」環境であるとも言えます。
この経験から、単にツールを導入するだけでなく、「コーディングエージェントが迷子にならないようにメタデータやドキュメントを整備し、コンテキストを補完する」ことこそが、チームの生産性を上げる鍵だと今は思っています。
まとめ
導入自体はスムーズでしたが、本当に活用するためには「ツールを入れる」以上の工夫が必要だと実感しています。
今は、各々が試行錯誤しながら最適な使い方を模索している段階です。
今後は、チーム内でナレッジ共有や統一的なドキュメント整備・データ整備を進め、より効果的な活用法を確立していきたいと考えています。
