AIに「全部のデータ」を渡してはいけない——Geminiで市場調査を自動化した設計の話

「とりあえず全データをAIに投げれば、いい感じにまとめてくれる」——この発想が、コストを膨らませ、精度を落とします。

---

① はじめに：私たちが作った「市場調査の自動化」

Papapapapaでは、自社プロダクトの開発を通じて、生成AIを業務に組み込むノウハウを蓄積しています。今回はその一つ、大量のWebデータを自動で収集し、AIが市場の傾向を要約するパイプラインの設計を、実装に踏み込んで紹介します。

題材にするのは、私たちが開発しているYouTube市場調査ツールです。やっていることはシンプルで、

1. キーワードに沿って動画・チャンネル・コメントを大量に集める
2. 集めたデータから統計を取る
3. その結果をGeminiに渡し、「市場概要・主要傾向・注目チャンネル・注意点」という形でレポートにまとめてもらう

——という流れです。ただし、このシンプルな流れを「実用に耐える」レベルにするには、いくつかの設計判断が必要でした。本記事ではその判断を、業種を問わず応用できる一般論として整理します。

---

② 技術的なポイント：実用化を支えた3つの設計

1. AIに渡す前の「前処理」がすべてを決める

生成AIを業務に使うとき、最もやりがちな失敗が「集めた生データをそのままAIに渡す」ことです。動画を数百件、コメントを数千件集めたからといって、それを丸ごとプロンプトに詰め込むのは悪手です。理由は3つあります。

• コスト：AIは入力した文字量（トークン）に応じて課金されます。生データを全部渡せば、その分だけ料金がかさみます。
• 精度：情報量が多すぎると、AIはかえって要点を外します。ノイズに引きずられるのです。
• 制限：そもそも一度に渡せる量には上限があります。

私たちのパイプラインでは、AIに渡す前に集計レイヤーを必ず挟みます。具体的には、

• 再生数の平均・中央値・最大値といった統計量を計算する
• 再生数上位の動画を10件だけ抜き出す
• 平均再生数の高いチャンネルを10件だけ抜き出す
• 投稿時期の分布をヒストグラム化する

このように「数百件の生データ」を「数十行の構造化された要約材料」へ圧縮してから、初めてAIに渡します。AIの仕事は”データの集計”ではなく”傾向の言語化”に限定する。これがコストを抑えつつ精度を上げる勘所です。

2. APIキーを持たない——クラウドネイティブな認証

生成AIをコードから呼ぶとき、多くの解説記事では「APIキーを発行して環境変数に入れる」方法が紹介されます。手軽ですが、業務システムではAPIキーそのものが管理コストとセキュリティリスクになります。漏洩すれば不正利用され、定期的な更新（ローテーション）も必要で、誰がどのキーを持っているかの管理も煩雑です。

私たちは当初APIキー方式で実装していましたが、これをVertex AI経由の呼び出しに切り替えました。Vertex AIはGoogle CloudのAIプラットフォームで、Geminiをこの基盤越しに呼ぶことで、実行環境（サーバー）自身の権限（サービスアカウント）でAIを認証できます。

// APIキーを一切持たず、実行環境の権限でVertex AIを呼ぶ
const client = new GoogleGenAI({
  vertexai: true,
  project,                 // Google CloudのプロジェクトID
  location: "us-central1", // 利用リージョン
});

これにより、コードからもシークレット管理からもAPIキーという存在そのものを消去できました。鍵を発行・保管・更新する手間がなくなり、「キーが漏れたらどうしよう」という不安からも解放されます。クラウド上で動くシステムなら、検討する価値の大きい選択肢です。

3. 「AIが失敗しても全体は止めない」設計

外部のAIサービスは、こちらの都合とは関係なく一時的にエラーを返すことがあります。混雑によるエラー、ネットワークの瞬断——こうした”たまに起きる失敗”を前提に設計しなければ、業務自動化は安定しません。私たちは2段構えで備えています。

(a) 一時的な失敗はリトライで吸収する

AIの呼び出しが失敗したら、すぐ諦めずに最大3回まで、間隔を空けながら再試行します。待ち時間を 0.5秒 → 1秒 → 2秒 と倍々に伸ばす「指数バックオフ」という定番の手法です。多くの一時障害は、これだけで自動的に回復します。

(b) 要約が最終的に失敗しても、収集の成果は捨てない

リトライしてもAIの要約が失敗することはあります。このとき、せっかく時間をかけて集めたデータまで無駄にしては本末転倒です。私たちの設計では、要約の失敗を握りつぶして（記録はする）、収集処理自体は「完了」として扱います。

try {
  summaryResult = await summarize({ /* ... */ });
} catch (e) {
  // 要約は失敗。でもデータ収集は成功しているので、ここで全体を止めない
  summaryResult = { summary: null, error: e.message };
}

「AIの部分だけ後でやり直せばいい」状態を保つ——これが、AIを業務フローに組み込むときの実践的な作法です。

---

③ ビジネスへの影響：中小企業が受け取るべきメッセージ

「これは開発者向けの技術論でしょ」と感じた方へ。ここには、AI活用を検討するすべての企業に通じる教訓があります。

🔑 ポイント1：AI活用のコストは「設計」で大きく変わる

同じことをAIにやらせても、生データを丸投げするか、前処理してから渡すかで、料金が何倍も変わり得ます。「AIは高い」という声の多くは、使い方の設計で解決できる部分を含んでいます。AI導入の検討時には、ツールの月額だけでなく「どう渡すか」の設計まで含めて見積もることが重要です。

🔑 ポイント2：「鍵の管理」は地味だが重い運用負担

APIキーの発行・保管・更新は、放置されがちですが、漏洩すれば直接的な金銭被害につながります。クラウドの仕組みを使えばキーそのものを無くせるケースがある——この発想は、セキュリティと運用負荷の両面で効いてきます。

🔑 ポイント3：AIは「たまに失敗する部品」として扱う

業務にAIを組み込むときは、「AIは100%成功する」前提で作ってはいけません。失敗を見越してリトライし、失敗しても他の処理は止めない。この”壊れにくさ”の設計があるかどうかが、PoC（試作）止まりか、実運用に乗るかの分かれ目になります。

---

④ Papapapapa の見解：AIは「魔法」ではなく「部品」

今回紹介した設計を通じて私たちが伝えたいのは、生成AIは万能の魔法ではなく、システムの中で適切に位置づけるべき”優秀な部品”だということです。

世間では「AIに任せれば何でも解決する」という空気もありますが、実際に業務へ組み込んでみると、本当に効くのは地味な部分です。

• AIに渡す前のデータ整形
• AIが失敗したときの振る舞い
• AIを呼ぶための認証とコストの管理

派手なAIモデルそのものよりも、こうした「AIを囲む設計」の質が、成果を左右します。そして、ここはまさに私たちのような開発パートナーが価値を出せる領域です。

私たちPapapapapaは、自社プロダクトで実際にこうした基盤を作りながら、その知見を活かして**「AIを業務に根付かせる」段階の支援**を提供しています。「AIで何かできないか」という相談から、「どう設計すれば安く・安定して回るか」まで、一緒に考えます。

---

⑤ まとめ：AI活用の成否は「囲み」の設計にある

本記事のポイントを整理します。

設計テーマ	やったこと	効果
前処理	生データを統計量＋上位10件に圧縮してから渡す	コスト削減・精度向上
認証	APIキーを廃止しVertex AI（サービスアカウント）に移行	鍵管理の撤廃・セキュリティ向上
信頼性	指数バックオフで最大3回リトライ	一時障害の自動回復
信頼性	要約失敗時も収集成果は完了扱い	部分的失敗でも価値を残す

生成AIの導入は、モデルを選んで呼び出せば終わり、ではありません。AIに何を渡すか、失敗したらどうするか、どう認証してコストを抑えるか——この「AIを囲む設計」こそが、実用と試作の境界線です。

「AIを使ってみたが、コストが読めない」「PoCは動いたが、本番に乗せる自信がない」——そんな段階でこそ、設計の経験が効いてきます。

---

合同会社Papapapapaでは、IT・DX・AIに関するご相談を随時受け付けています。「自社の業務にAIをどう組み込むか」を、実装の現場を知るパートナーと一緒に考えてみませんか。お気軽にお声がけください。