今回の事例で獲得した成果
- 人の準備は「事前のログイン」と「ダッシュボードのURLの作成」だけで、データの接続からグラフの配置までをAIエージェントが進めました。 計画を承認してから完了までは1時間13分10秒でした。
- APIで操作できない画面の作業も含めて、長時間にわたって自律的に、一定の精度で完遂できることを確認できました。 4つの区分（サマリー／達成状況／日別・週別推移／コンテンツの再生状況）からなるダッシュボードができあがりました。
- 人が作業するよりも丁寧に作り込めそうだと分かりました。 付加価値が相対的に低いダッシュボード作成に担当者の時間を使うより、ずっと生産的です。
- 同じダッシュボードを Claude のダッシュボード機能でも作り、Looker Studio との違いを確認しました。 絞り込み操作の有無や閲覧に必要なアカウントなど、使い分けの判断材料が得られました。
取り組んだ課題
法人のお客様向けに、参加者がミッションを達成してポイントを貯める小規模なイベントを実施しました。イベント期間中は、参加者がどこまで進んでいるか（参加率、ミッションの達成状況、日別・週別の推移など）をお客様と一緒に確認できるダッシュボードが必要です。
ダッシュボードの作成は、データの接続、指標の定義、グラフの配置と、画面上の細かい操作が多い作業です。付加価値が相対的に低い一方で、人が作れば担当者の時間を1時間ほど使うことになります。 そこで、APIで操作できない画面の作業も含めて、AIエージェントに任せられるかを確かめました。
実施内容の概要
人とAIの役割
| 担当 | 役割 |
|---|---|
| 担当者（人） | Claude in Chrome で各サービスに事前にログインし、ダッシュボードのURLを作成する。AIが出した構成案に修正を指示し、計画を承認する |
| AIエージェント | 参考資料をもとに構成案を出す。承認後は、ブラウザを操作してデータの接続、指標の定義、グラフの配置まで進め、ダッシュボードを完成させる |
利用環境
- AIエージェント：Claude Code（Windows の PowerShell から起動）。モデルは Opus 5.5（Medium Effort）
- ブラウザ操作：Claude in Chrome
- 作成先：Looker Studio
- データ：BigQuery のイベント用テーブル
- 参考資料：プロンプトに添付した画像と、Looker Studio 内の既存のダッシュボード
進め方
- 構成案を出させる：参考資料とデータを読ませ、まずどのような構成にするかの案を出させる
- 計画に細かい修正を指示する：3往復で計画を確定
- 計画を承認し、自動実行（auto mode）に任せる：完了まで人は操作しない
実際に使ったプロンプトは次のとおりです（URLとテーブル名は伏せています）。
[Image #1]とBigQuery'〈テーブル名〉'テーブルを参照し、イベント参加者の進捗状況を見れるダッシュボードを〈URL〉で作成せよ。Looker Studio中の他のダッシュボードを参考にして、まずはどのような構成にするのか案を出せ。
作成されたダッシュボード
できあがったダッシュボードは、次の4つの区分で構成されています。
- サマリー：対象者数、参加率、当選倍率別の人数、合計ポイント別の人数
- 達成状況：ミッション別の達成者数と達成日数
- 日別・週別推移：日別のミッション達成人数、週別の活動人数・獲得ポイント
- コンテンツの再生状況：再生者数・再生率・累計再生回数と週別の推移
Looker Studio に作成されたダッシュボード（サマリー部分）。名称と数値はマスキングしています。
別の方法：Claude のダッシュボード機能でも作成
同じイベントのダッシュボードを、Claude のダッシュボード機能でも作成しました。
Claude のダッシュボード機能で作成したダッシュボード（サマリー部分）。名称と数値はマスキングしています。
Looker Studio との違いとして、次の2点を確認しました。
- 絞り込みの操作がない：スライダーなどで条件を変えて絞り込むことはできません。
- 閲覧にはアカウントが必要：見る人に claude.ai のアカウントが必要です。ただし共有設定で「URLを知っていれば誰でも閲覧可能」を選ぶこともできます。
結果と検証条件
| 項目 | 内容 |
|---|---|
| 対象 | 法人のお客様向けに実施した小規模イベントの進捗ダッシュボード（Looker Studio） |
| 実施回数 | 1回 |
| 人の準備 | Claude in Chrome への事前ログインと、ダッシュボードのURLの作成のみ |
| 計画の確定 | 構成案に対して修正の指示を3往復 |
| 作業時間 | 1時間13分10秒（計画の実行開始から完了まで） |
| 消費トークン | 約160K tokens（同じ期間の消費。チャット上の表示による） |
| 利用枠の消費 | 週の利用上限のうち47%（前日12時のリセット以降の消費量。期間中に行った別の作業も含む） |
| 人が作った場合の時間 | 計測していません |
この結果は当社の取り組みの記録です。同じ方法で同じ結果が得られることを示すものではありません。
うまくいかなかったこと・適用上の限界
- トークンの消費が大きくなります。 画面を見ながら操作するため、構造化されたデータだけを扱う場合より消費が大きくなります。従量課金のAPIで安易に行うべき性質の作業ではありません。
- データ構造が明確であることが前提です。 今回はデータベース側の構造がはっきりしていました。ここが曖昧だと、トークンの消費や作業時間が増えたり、ミスにつながったりするおそれがあります。
- プロンプトインジェクションへの注意が必要です。 今回はすべて社内で管理している環境で作業しました。社外のサイトを経由する作業では、Webページに仕込まれた指示にAIが従ってしまうリスクがあります。
- 実施は1回です。 別のデータや、より複雑なダッシュボードで同じ精度が出るかは確認できていません。
他の企業で検討する際のポイント
- いきなり作らせず、まず構成案を出させ、人が修正を指示してから承認する。
- 参考にしてほしい既存のダッシュボードや画像を、プロンプトで具体的に示す。
- データの構造（テーブルや項目の意味）を先に整理しておく。
- ブラウザ操作は社内で管理している環境に限り、社外のサイトを経由させない。
- 画面操作はトークンの消費が大きいため、利用枠や費用の上限を決めておく。
- そもそもそのダッシュボードが必要かを、業務として判断する。法人のお客様向けの案件では、必要がなければ「作成しない」ことをお客様と交渉する選択肢もある。
