# 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倍の規模差）が 設計を決めた。 ---