Driveフォルダの資料を丸ごとLLMに読ませる（夜間ダイジェスト + 再開可能バッチ）

案件フォルダ・プロジェクトフォルダに散らばった PDF / スライド / Office / 写真 を、 AIが「毎回ぜんぶ読んでいる」状態にするための設計。サーバーレス実行基盤（Apps Script 等、 実行時間や送信サイズに上限がある環境）で動かす前提で書く。

1. 最初に潰すべき誤解: Office形式は直接読めない

pptx / docx / xlsx をそのまま受け付ける主要LLM APIは存在しない。 ドキュメント理解は実質 PDF（＋画像）だけ。「あのモデルなら PPT を読める」は誤解で、 チャットUIで読めているのは提供側が裏で変換しているから。

→ 変換工程を設計に必ず含める。逆に変換さえ挟めばどのモデルでも読める。

# Drive REST v3: pptx をプレゼン形式へ変換コピー → PDF 化
POST https://www.googleapis.com/drive/v3/files/{fileId}/copy?supportsAllDrives=true
{ "name": "conv_{fileId}_{lastUpdatedMs}",
  "mimeType": "application/vnd.google-apps.presentation",
  "parents": ["<変換キャッシュフォルダID>"] }
→ 返った id を PDF としてエクスポート

• ネイティブのスライド/ドキュメントは、多くのSDKで 取得した時点で既にPDF になる（変換コード不要）。 実装前に「変換が要るのか」を1回だけ実測して確かめる。
• 変換物は元フォルダに置かない。次回のスキャンで自分の生成物を拾う汚染が起きる。 専用キャッシュフォルダに conv_<元fileId>_<元更新時刻> 名で置き、同名があれば再利用（再変換しない）。
• 表計算は PDF 化しても表が崩れやすい。値をテキストとして読んで渡すほうが確実。

2. 二層構成にする（片方だけでは成立しない）

層	実行タイミング	対象	役割
直添付	ユーザーが生成を実行した時	予算内の上位数件（原本）	精度。原本を直接見せる
ダイジェスト	夜間バッチ	フォルダ全部	網羅。要約テキストを作り置き

生成時は「原本 数件 ＋ ダイジェスト全文」を渡す。 リクエストサイズ上限（数十MB）と実行時間上限がある以上、 全ファイルを毎回そのまま添付するのは物理的に不可能。ここを正直に設計する。

ダイジェストには安価で長文脈のモデルを使う（100万トークン級・入力が桁違いに安いモデル）。 高価なモデルは「要約を読んで判断する」側に回す。結果的に総コストは下がる。

3. 選別ロジック（直添付レイヤー）

やってはいけない: ファイル名キーワードの allowlist

「名前に "図面|パース|デザイン" を含むものだけ拾う」は一見安全だが、 現場写真が全部落ちる。カメラやダウンロード由来のファイル名（IMG_1234.jpg 等）は 意味を持たないので、キーワード方式では永久に拾われない。

推奨: 除外リスト + 予算 + 枠予約

候補 = フォルダ配下(深さ4〜5)の PDF/スライド/文書/Office/画像
除外 = ファイル名  … 見積|請求|申込|申請|スクリーンショット 等
       + フォルダ名 … 金額系フォルダ（見積|請求|支払|入金|発注|契約）
順位 = ①関連キーワード一致 → ②その他、各群の中で更新日時の新しい順
予算 = 最大件数 / 合計バイト / 1ファイル上限 / 画像枚数
予約 = 画像に最低1枠（名前に意味が無いので予約しないと永久に入らない）

フォルダ名でも除外するのが重要。実測で 見積り（社外見積もり）/施工会社/<会社名>.pdf という、 ファイル名に「見積」を含まない見積書が混入した。金額情報が生成プロンプトに入る事故になる。

実体のないリンクだけのファイル（数KB未満のネイティブ文書）は枠を食うだけなので落とす。

落としたファイルは理由付きで記録する（over_max_files unsupported_mimeType excluded_folder 等）。無音の切り捨ては「全部読んでいる」という誤解を生む。

4. 夜間ダイジェストを「落ちても損しない」形にする

サーバーレス実行には数分の上限がある。素直に全チャンクを1回で処理すると、 支払ったAPI料金ごと落ちる。次の4点で守る。

1. チャンク分割は元サイズで行い、変換とbase64化は送信直前にそのチャンクだけ （先に全件エンコードすると数十MBがメモリに乗って落ちる）
2. 1実行=1チャンク。処理したら即座に部分結果を保存する
3. 状態を保存先に持たせる: フィンガープリント / 状態(部分|完了) / 進捗(2/5) ＋ チャンクごとの中間要約
4. 次回起動時、フィンガープリントが一致し状態が「部分」なら保存済みを再利用して続きから。 一致しなければ資料が変わったので最初からやり直す

夜間スケジュールは1本ではなく 30分刻みで数本 用意する（1回で数件しか進まないため）。

時間ガードは2種類に分ける（ここを1本にすると死ぬ）

• 項目内の予算（次のチャンクを始めてよいか）
• 新規項目の着手締切（新しい案件に着手してよいか）

同じ値を使うと「締切ぎりぎりで新規着手 → 上限超過で強制終了」が起きる。 着手締切は「1項目の最大所要時間」を引いた値にする。

5. コスト制御: フィンガープリントで呼ばない

対象ファイルの fileId:lastUpdated を連結してハッシュ化し、保存先に持たせる。 次回、値が同じならAPIを呼ばない。これが無いと毎晩フォルダ全部を読み直して課金が積み上がる。

実測（安価な長文脈モデル）:

• 10ファイル / 4チャンク → 1件あたり約 $0.03
• 46ファイル / 5チャンク → 1件あたり約 $0.10
• 以降、資料を触った項目だけ再生成 → 定常状態はほぼゼロ

6. 保存先の上限を踏む前に割る

表計算に本文を書き出すなら、1セルの文字数上限（数万文字）がある。 超えると落ちるか黙って切られる。改行境界で分割して複数行に書く。 1行が上限を超える場合は強制的に切る。読み出し側は行を結合する。

7. 要約プロンプトの必須要件

• 出力は見出し付きプレーンテキスト
• 資料に無い情報は書かない。不明は「資料に記載なし」と明記（捏造の自己増殖を止める）
• 各項目に出典ファイル名を付ける（後から一次資料へ辿れる）
• 抽出させる項目を業務語で列挙する（仕様/寸法/数量/色・現況条件・確定事項・未確定事項）

8. 自分の生成物を読み直さない（重要な落とし穴）

同じフォルダに AIが過去に生成した成果物 が保存されていると、それを「資料」として読み直す。

• 過去の生成物の誤りが「資料に書かれた事実」として次回に固定される（ハルシネーションの自己強化）
• 一次資料（規定・図面）と二次生成物が同じ重みで混ざる

→ 生成物には識別できる命名規則（接頭辞など）を与え、収集時に除外する。 議事録や打合せメモは一次情報なので残す。

9. 検証導線を最初から作る

読み取り専用の点検コマンドを3本用意しておくと、実機の挙動が一撃で分かる。

• debugMaterials(項目ID) … 選ばれた資料 ＋ 除外されたものと理由
• debugAttachProbe(ファイルID) … 変換後のMIMEタイプ・バイト数・添付可否
• debugDigest(項目ID) … 対象一覧・フィンガープリント・本文の先頭

「実装した」ではなく「実機で何が選ばれ何が落ちたか」を見るまで完了と言わない。 実測して初めて分かったこと（見積フォルダの混入・自己生成物の再取り込み・案件による4倍の規模差）が 設計を決めた。