こんにちは。Supership システム統括部の @ps010 です。
この記事は Supershipグループ Advent Calendar 2025 の 10日目の記事です。
今回はLLMを使って集計業務を自動化した話です。データカタログ運用においてMarkdownからJSONへ移行した理由と、その効果をまとめました。
TL;DR
- 社内のデータ抽出依頼（窓口対応）をGeminiで自動化し、工数を約86%削減。
- 更新が発生するデータカタログ（スプシ）をAIに連携するため、GASによるパイプラインを構築。
- 技術的結論: AIに読ませるデータ形式は、定石のMarkdownではなくJSONが最適だった。
- 理由: GASでの実装が容易（運用面）であり、かつネスト構造によりAIが「情報の親子関係」を正確に理解できた（精度面）ため。
1. はじめに
データ分析チームにおいて、避けては通れない業務の一つに「データ抽出依頼（窓口対応）」があります。
「〇〇キャンペーンの効果測定用に、先月のユーザーログを抽出してほしい」といった依頼は、定型的である一方で、社内データベースの構造やビジネスロジックへの深い理解が必要とされ、データ分析者の工数を地味に、しかし確実に圧迫します。
本記事では、Google Geminiを活用してこの窓口対応業務を半自動化し、仕様策定から実行コード（SQL/PySpark）の生成までを一気通貫で行うPoCの取り組みを紹介します。
単なるプロンプトエンジニアリングの話にとどまらず、 「定期的に更新されるデータカタログ（仕様書）を、いかに運用コストを抑えつつAIに連携するか」 という、エンジニアリングの試行錯誤と技術的判断（Markdown vs JSON）に焦点を当てて共有します。
2. 課題（モチベーション）
2.1 背景と目指す指標
他部署からのデータ抽出依頼に対し、仕様策定からクエリ作成までをデータ分析者が請け負っていますが、この定型的な業務をLLM活用によって効率化したいというマネージャーの要望を受け、本プロジェクトがスタートしました。
今回の自動化プロジェクトでは、単なるAIの回答速度ではなく、実務における以下の3つの合計時間を「工数」と定義し、これを削減することをKPIとしました。
- 事前処理: プロンプトの入力やファイル準備にかかる時間
- 実行時間: AIの生成待ち時間
- 事後処理: 人間によるレビューと修正にかかる時間（※ここが最も重く、重要）
2.2 技術的な壁：スプレッドシート直読みの限界
AIに正確なクエリを書かせるには、社内の詳細なテーブル定義（データカタログ）を正しく理解させる必要があります。
私たちのデータカタログはGoogleスプレッドシートで管理されており、テーブル一覧や詳細なテーブル定義シートが適宜更新されています。
プロジェクト初期、私たちはこのスプレッドシートをそのままGeminiに添付して指示を出してみましたが、結果は失敗でした。
Geminiは各シートを「独立したCSVファイル」として認識してしまい、「テーブル一覧（親シート）」と複数存在する詳細な「テーブル定義書（子シート）」の関連性を理解できなかったのです。その結果、必要な情報を引き出せず、ハルシネーション（嘘のテーブル名の捏造など）が多発しました。
2.3 要件：GASによる自動パイプライン
この経験から、AIに「これはひとまとまりの構造化されたデータベース地図だ」と認識させるためにはスプレッドシートのままでは不十分であり、何らかの構造化データへの変換が必要だと判明しました。
カタログは今後も更新され続けるため、手動変換は非現実的です。スプシの更新に合わせてAI用のファイルを自動生成する「GAS（Google Apps Script）によるパイプライン」の構築が必須要件となりました。
3. アプローチ / 環境
3.1 使用環境と自動化の進化
使用環境として、Gemini for Google Workspace を採用しました。自動化のアプローチについては、以下のような変遷を辿りました。
- 初期（逐次処理）： データ抽出依頼の確認プロセスを「抽出条件の確認」「加工内容の確認」「集計内容の確認」といった細かい子タスクに分解し、人間が都度AIに指示を出す「逐次処理（Sequential Processing）」を採用していました。この方法では、AIの成果物の精度は高いものの、人間の介入頻度が高く、期待したような劇的な効率化には至りませんでした。
- 改善（一括処理）： データカタログ、依頼情報、IO（入出力）定義書といった関連資料を一度に渡し、依頼の解釈からコード生成までを自律的に思考させる「一括処理」へシフトしました。これにより、AIが文脈を保持したまま処理できるようになり、大幅な効率化が見込めました。
3.2 検証の焦点：Markdown vs JSON
一括処理の精度を高めるため、パイプラインに乗せる「データカタログの形式」として、最終的に以下の2つを比較検証することにしました。
- Markdown形式: LLMの定石。見出しタグ等で構造化する手法。
- JSON形式: データ構造そのもの。
どちらが「AIの回答精度（構造理解）」と「開発・運用のしやすさ」を両立できるか。ここからが本プロジェクトの最大の山場となりました。
4. 実験詳細：Markdown vs JSON
データカタログをAIに連携し続けるには、スプレッドシートの更新に合わせてファイルを自動生成する「パイプライン」が不可欠です。私たちは、このパイプラインに乗せるデータ形式として最終的に「Markdown」と「JSON」を比較検証しましたが、そこには単なる形式比較だけでなく、開発アプローチの大きな転換がありました。
4.1 初期アプローチ：PythonによるMarkdown生成と限界
はじめに、LLMが解釈しやすいデータ形式を探るため、スプレッドシートの情報をMarkdown、Googleドキュメント、PDFに変換し、Geminiで内容確認のテストを実施しました。その結果、Markdownが最も高いパフォーマンスを示したため、スプレッドシートをMarkdown形式に変換する方針を採用しました。
変換にはPythonを使用し、ドキュメント駆動開発で厳密なロジックを構築していましたが、実データの複雑さが壁となりました。
-
構造の複雑さと保守コスト:
データカタログのスプレッドシートは、「1シートに1テーブル」という単純なものではありません。メインのテーブル定義の下に、テーブルのFilter情報の別表が配置されていたり、セル結合が多用されていたりと、人間向けのレイアウトになっています。
これらをPythonで解析し、正確なMarkdown構造に落とし込む処理は非常に複雑になり、開発工数が肥大化しました。 -
チームの決断:
「定期的に更新されるスプシに合わせて、この複雑なPythonスクリプトを保守し続けるのか？」
チームはこの運用リスクを問題視しました。そこで形式変換後の情報の再現性を担保しつつ、開発・保守工数を大幅に圧縮できる方法への転換を決定しました。
4.2 転換点：GAS × LLMによる再構築とJSONの勝利
私たちは開発言語を、スプレッドシートと親和性の高い Google Apps Script (GAS) に変更しました。さらに、人間のスクリプト開発に対する介入度合いを下げ、変換コードの大半をLLMに生成させるという、より軽量な開発スタイルへシフトしました。
この「低コストな開発環境」という条件下で、 改めて Markdown と新たに構造化データの JSON を選択肢に加え、どちらが優れているかを検証しました。
-
Markdown（GAS生成）の結果：
GASで簡易的に生成したMarkdownでは、複雑なレイアウトを表現しきれませんでした。Pythonで作り込んだ時とは異なり、構造化が不十分で「テーブルの抜け漏れ」が発生し、AIの回答精度も安定しませんでした。 -
JSON形式の結果（採用）：
一方で、JSONは「GAS × LLM」のアプローチと極めて相性が良いことが判明しました。- 開発が容易（運用メリット）: スプレッドシートの構造をそのままJSONのネスト構造（Key-Value）にマッピングできるため、複雑なロジックを組まずともデータの階層構造を保持できました。
- 文脈の保持とハルシネーション抑制（精度メリット）: Geminiに読ませたところ、JSONの厳密なオブジェクト構造により、「シート間の親子関係」や「テーブル間の文脈」が保持されていることが確認されました。これにより、上述のMarkdown使用時に見られた情報の断絶がなくなり、存在しないテーブルを参照するなどのハルシネーションが大幅に抑制されました。
「開発コストを下げたのに、AIの理解度（精度）は上がった」 という、理想的な結果が得られたのです。
5. 結果と最終アーキテクチャ
JSON形式の採用により、運用コストを抑えた「データカタログ自動更新パイプライン」が完成しました。これを用い、最終的に最も精度が高かったアーキテクチャを紹介します。
5.1 システム構成
情報の性質に応じて、AIへの渡し方を以下の3つに最適化しました。
-
Gem設定(知識・カスタム指示): データカタログ [JSON] ＋ ルール
GASで自動生成されたデータカタログ（JSON）をGemの設定にある知識(下図参照)に、役割や行動原則などの「ルール」をカスタム指示に格納します。これらは静的な参照情報として扱います。
-
指示 (Prompt): IO仕様書
出力フォーマット（IO仕様書）などの「絶対に守らせたい制約」は、あえて知識に入れず、タスク指示が記載されたプロンプト本文に追記します。これにより、指示としての強制力が働き、出力形式のエラーが減りました。 -
入力 (Attachment): 依頼内容
依頼者が入力したデータ抽出の依頼文をファイルとして添付します。
5.2 定量的な成果
この構成により、自動化のKPIとしていた「工数（事前準備＋実行待ち＋事後処理）」は大幅に改善しました。
- 工数の大幅削減: 手作業と比べ、作業全体の工数削減率は 約86% を達成しました。
- 事後処理の極小化: 特に工数が重かった仕様策定書の「人間による手直し」の時間が激減しました。JSONによる正確なスキーマ理解により、実務で使えるレベルの仕様策定書や、SQL/コードの生成ができるようになりました。
6. まとめ
本取り組みを通じて、LLM活用におけるデータ形式の選定は、「AIにとっての読みやすさ」だけでなく、「データパイプラインを保守する人間の都合（運用性）」 も同様に重要であるという知見を得ました。
結果として、運用の観点から着目した「JSON形式」がAIにとって理解しやすい論理構造を持っていたことは、エンジニアリングの観点からも非常に興味深い発見でした。
今後は、今回のPoCで得られた成果を実際の業務プロセスへ展開できればと考えています。
最後に宣伝です。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト
是非ともよろしくお願いします。