[検討] SKU別売れ数転記処理: SpreadsheetApp.openByIdの遅延をSheets API移行で解消できるか検証する

[Hide-JZX100]

背景

GetSalesSummaryAcquisition/06_売れ数転記_改修.gs の copyMakerData() にて、
コピー先スプレッドシートを開く処理(openSpreadsheet(config.targetId) =
SpreadsheetApp.openById())の所要時間が、メーカーによって大きく変動することが
DEBUG_TIMING の診断ログで確認された。

現状の計測結果

読み込み・書き込み自体(getValues/setValues)は常に安定して1秒未満だが、
「先を開く」処理だけが突出して遅いケースがある。

メーカー	元を開く	先を開く	開始行計算	元読込	先書込	合計
SNO	4ms	241ms	375ms	139ms	4ms	763ms
サービス分集計	4ms	501ms	390ms	127ms	254ms	1276ms
熊井綿業	4ms	772ms	827ms	122ms	5ms	1730ms
国内マットレス	3ms	30743ms	560ms	128ms	3ms	31437ms
国内寝装品	3ms	11259ms	510ms	333ms	7ms	12112ms
万鵬家具	3ms	223ms	363ms	100ms	6ms	695ms

計測時刻: 2026-08-13 15:08頃(ピーク時間帯 07:00〜22:00 に該当)。

同じメーカーでも実行回によって遅延する対象が入れ替わることを既に確認済みで、
コピー先ファイル固有の構造上の問題(数式・条件付き書式・入力規則)は
ヒアリングにより否定済み。Google側の一時的な状態(コールドスタート/
ファイルへの同時アクセス/バックエンド混雑)に起因すると推測している。

想定される原因

SpreadsheetApp.openById() は、指定した範囲だけでなくスプレッドシート
全体(全シート・書式・グラフ・保護範囲など)をオブジェクトモデルとして
構築するコストがかかる。この「全体を開く」オーバーヘッドが、
遅延の主因ではないかと推測している。

検討したい対応

openSpreadsheet() / getSheet() / copyMakerData() の一部を、
GASの Advanced Google Services で有効化できる Sheets API
(Sheets.Spreadsheets.Values.get / update)に置き換える。
Sheets APIは対象範囲のみをHTTPで直接やり取りするため、
オブジェクトモデル構築のオーバーヘッドを回避できる可能性がある。

過去の関連実績

78万セル規模のマスターコピー処理において、Sheets API導入により
高速化した実績がある。ただしそのケースは大量データの読み書き
(getValues/setValues)自体がボトルネックだったのに対し、
今回は「開く」処理がボトルネックである点で性質が異なる。
そのため、今回も同様に効果があるかは実証が必要。

検証ステップ(着手時)

• 遅延が再現しやすいメーカー(国内マットレス等)を対象に、
  Sheets API版の openById 相当処理を試験実装
• DEBUG_TIMING と同様の計測ログを追加し、既存方式とAPI呼び出し
  回数・所要時間を比較
• 複数回・複数時間帯で計測し、変動要因(時間帯/ファイル)との
  相関を確認
• 効果が確認できた場合のみ、認証スコープ追加を含めた本実装に着手

優先度・緊急性

現状の合計実行時間(約90〜100秒)はGASの6分制限に対して十分余裕があり、
緊急対応は不要。SRE的な安定化フェーズでの改善候補として着手する。

関連ファイル

• GetSalesSummaryAcquisition/06_売れ数転記_改修.gs

[Hide-JZX100]

[検証フェーズ] Sheets APIを活用した売れ数転記処理の高速化・安定化検証

目的

06_売れ数転記_改修.gs の copyMakerData() において、SpreadsheetApp.openById() (スプレッドシートを開く処理) が「国内マットレス」等で30秒を超える深刻な遅延を発生させている問題を解決するため、Sheets API (Advanced Google Services) を使用した実験用関数を作成し、処理時間の短縮および安定化効果を検証します。

---

ユーザーレビュー事項

Important

GASの「拡張サービス (Advanced Services)」の設定について
Sheets API を利用するには、GASエディタ側の「拡張サービス」で Sheets API を有効化しておく必要があります。（または appsscript.json に設定が追加されている必要があります）。
今回の検証コードは、Sheets オブジェクトが利用可能な前提で記述します。

---

提案する変更内容

GetSalesSummaryAcquisition コンポーネント

[MODIFY] [06_売れ数転記_改修.gs]

• スクリプトヘッダーおよび関数コメントを適切に記載
• Sheets API を利用したデータ取得用の実験関数 copyMakerData_SheetsAPI_ReadOnly(config) を追加(案A: 読み取り専用の第一段階検証)
  • Sheets.Spreadsheets.Values.get でコピー先A列を取得し、最終行を特定
  • 取得したA列データに対し、calculateStartRow() と同一の判定ロジック(コピー先直近7行分の日付とコピー元開始日を比較し、一致すれば上書き行・不一致なら追記行を返す)を再現して開始行を計算する。formatDateToString() による日付比較も既存関数をそのまま流用する
  • Sheets.Spreadsheets.Values.get でコピー元の指定行データも取得する(比較用。実際の書き込みは行わない)
  • 書き込み(values.update)は実行しない
  • 現行方式と同様のミリ秒単位のタイミング計測ログ ([TIMING (Sheets API / ReadOnly)]) を出力
• 書き込みまで含めたフル版 copyMakerData_SheetsAPI(config) の実装は本検証フェーズでは行わず、ReadOnly版の結果を見てから着手するかを判断する(次フェーズのIssueとして切り出す)
  • 実装する場合は Sheets.Spreadsheets.Values.update の valueInputOption を 'USER_ENTERED' に明示的に指定すること。'RAW' を指定すると日付が文字列/数値としてそのまま書き込まれ、SpreadsheetApp.setValues() が行っていた自動日付型変換と挙動が変わり、calculateStartRow() の日付比較(formatDateToString())に影響する可能性があるため
• 実験用テスト関数 test_compareSheetsApiVsOpenById() を作成
  • 遅延が発生しやすい特定メーカー（例: 国内マットレス、国内寝装品等）を対象に、現行方式 (copyMakerData) と Sheets API方式 (copyMakerData_SheetsAPI) の実行速度を比較出力

---

検証計画

自動テスト / 手動テスト手順

1. Google Apps Script エディタでの事前確認

   • プロジェクトの「拡張サービス」で Google Sheets API (v4) が追加・有効化されているか確認します。

2. テスト関数の実行

   • GASエディタ上で test_compareSheetsApiVsOpenById() を実行します。
   • 本関数は現行方式 copyMakerData(config) と、読み取り専用のSheets API版 copyMakerData_SheetsAPI_ReadOnly(config) を比較します。書き込みは現行方式・Sheets API版のいずれも本番の「SKU別売れ数」シートに対して行われる点に注意(現行方式は従来通り書き込みまで実行、Sheets API版は読み取り・開始行計算までに限定)。

3. ログの比較確認

   • 実行ログに出力される [TIMING] (現行方式) と [TIMING (Sheets API / ReadOnly)] (Sheets API方式・読み取りのみ) の所要時間を比較します。
   • 特に「先を開く」に相当するレスポンス時間が大幅に改善され、1秒未満で安定して完了することを確認します。
   • 開始行の計算結果(上書き行 or 追記行)が、現行方式と完全に一致することもあわせて確認します(ロジック再現の正しさの検証)。

4. 次フェーズの判断

   • ReadOnly版で明確な速度改善が確認できた場合のみ、copyMakerData_SheetsAPI(config) のフル実装(values.update を含む)を別Issueとして起票する。