🧩 Redmine → スプレッドシート自動反映
目次
1. 概要
Redmineのチケット番号情報からチケット情報を取得し、Googleスプレッドシートに自動反映する仕組みを構築しました。メンバーがスプレッドシートの 「チケットフラグ（C列）」にチェックを入れるだけで、Redmineのチケット情報を取得し自動入力 します。
Redmineのチケット番号（赤線部）
この番号は プロジェクト全体で一意（重複しない）です。
スプレッドシート E列にチケット番号を入力後、C列のチケットフラグに✅を入れると、Redmineからデータ取得します。
青色のセルには自動でデータが反映されます。
白色のセルには手入力でご記入ください。
2. 主な目的
| 目的 | 内容 |
|---|---|
| 🔄 転記の自動化 | Redmine上のチケット情報をシートに自動反映し、手入力作業をなくす |
| 🧮 情報の統一 | 全員が同じ情報をリアルタイムで参照できるようにする |
| 👥 複数人対応 | 各メンバーが同じスプレッドシートを同時に扱っても安全に処理できる |
| 💡 業務効率化 | 担当者は「チェックするだけ」で最新情報に更新可能 |
3. 処理の流れ（ステップ概要）
| ステップ | 処理内容 | 補足 |
|---|---|---|
| ① チェック | 「チケットフラグ」に✅を入れる | 編集イベントを検知して自動処理開始 |
| ② ID確認 | 同じ行の「チケット番号」を取得 | 空欄ならスキップされる |
| ③ 行ロック | 同時操作を防ぐため、対象行を一時的にロック | ※TTL=10秒（後述） |
| ④ Redmineアクセス | チケットIDをまとめてRedmine APIに問い合わせ | 負荷分散（スロットリング処理）あり |
| ⑤ データ反映 | クライアント名・案件名・期日などを自動入力 | 各列に上書き反映 |
| ⑥ フラグ解除 | 反映が完了した行のチェックを自動でOFF | D列に実行日時を記録 |
4. 自動反映される項目
| スプレッドシート項目 | Redmine側の対応データ | 備考 |
|---|---|---|
| クライアント | トラッカー名 | 例：NAG |
| モール | カスタムフィールドID:40 | 例：本店・楽天など |
| プロジェクト(大) | チケット件名（subject） | 例：サンドイッチLP |
| プロジェクト(小) | カスタムフィールドID:41 | 例：広告、制作など |
| 作業内容 | カスタムフィールドID:73 | Redmine側の「作業内容」欄 |
| 開始日・期日 | start_date / due_date | Redmine標準項目 |
| 期日時間帯 | カスタムフィールドID:3 | 午前・午後など |
| 見積管理No | カスタムフィールドID:7 | 内部管理番号 |
| チケットチェック日付 | スクリプト実行時に自動記録 | 例：2025-10-28 16:20:20 |
5. 安全設計と同時実行の仕組み
🔒 ① 行ロック制御（TTL＝10秒）
TTL（Time To Live）とは？
処理中の行に「一時ロック」をかけて、他の人が同じ行を同時に処理しないようにする仕組み。
TTLは「ロックの有効時間」を意味し、10秒後に自動解除されます。
これにより「二重書き込み」や「上書き競合」を防ぎます。
例：
- 神谷さんと袖野さんが同じ行を同時にチェックしても、先に処理した方だけが反映されます。
- 後から来た処理は自動でスキップ（チェックがOFFに戻る）し、整合性が保たれます。
⏱️ ② スロットリング（API過負荷防止）
スロットリング（Throttling）とは？
Redmineサーバーへ短時間に大量のアクセスが行われるのを防ぐため、
リクエストを一定間隔で送る仕組みです。
設定内容：
- 一度に最大 5件のチケットをまとめて送信（BURST_SIZE）
- 送信後に 6秒の待機（BURST_INTERVAL）
- チケットが100件以上あっても、100件ずつ分割して処理
- サーバーが混雑している場合は10秒 → 20秒の再試行（バックオフ）を自動実施
→ 結果として、Redmine側に負荷をかけず、安全・安定的に取得できます。
🔧 スロットリングを入れている理由
✅ 目的：下記のAPI制限・サーバー負荷を防ぐため
| 制限の種類 | 内容 |
|---|---|
| Rate Limit（レート制限） | 「短時間に送れるリクエスト数」に上限がある（例：1秒に5回までなど） |
| 負荷対策制限 | 短時間に大量アクセスが来ると、Redmineが一時的にレスポンスを拒否（HTTP 429や503） |
| 同時接続数の制限 | APIサーバーが一度に処理できる接続数に上限がある |
🧮 ③ キャッシュと再試行制御
- 同時処理中の行をキャッシュに一時保存し、重複処理を防止。
- Redmine側で「一時的な通信エラー」(429 / 500 / 502 / 503 / 504) が出ても
最大2回まで自動再試行。
6. 運用時の動作イメージ
1️⃣ チェックON（TRUE）
↓
2️⃣ Redmineからデータ取得
↓
3️⃣ 各列に自動反映
↓
4️⃣ チェックOFF + 実行日時更新
↓
✅ 完了（3〜5秒で更新）
実測テスト
テストで実行したところ、1998行分のチケットフラグを一括で処理し、約11分（660.495 秒）で完了しました。
※業務シート（1998行分）を2人同時で起動させても11分～12分くらいで終わっていました。
※別スプレッドシートで、同様の条件で確認しましたが、600秒くらいで終わっております。
検証 N=5 1998行 大体600秒～700秒の範囲
7. 運用ルール
運用ルール
- チェック（✅）するだけで自動反映
- 同じ行を同時に触らないのが理想（触っても破綻しない設計）
- 並び替え・フィルタ操作は反映完了後に行うと安全
8. 技術仕様まとめ
| 項目 | 内容 |
|---|---|
| イベントトリガー | onEdit（インストール型） |
| ロック方式 | 行単位キャッシュロック（TTL＝10秒） |
| API取得方法 | Redmine REST API |
| バースト処理 | 5件ごと、6秒間隔 |
| 再試行 | 最大2回（10秒→20秒） |
| 処理対象 | C列がTRUEになった行のみ |
| エラー処理 | チケット番号なし → 自動スキップ＋FALSE化 |
| 同時実行対応 | 複数人可（行単位ロック制御） |
| 対象シート | 各メンバータブ（神谷・袖野など）独立処理 |
9. 用語の解説まとめ
| 用語 | 意味 | 簡単な説明 |
|---|---|---|
| TTL（Time To Live） | ロックの有効期間 | 一時的に処理対象を“予約”して、一定時間後に自動解除する仕組み。二重処理を防ぐ。 |
| スロットリング（Throttling） | リクエスト間引き処理 | APIに一気にアクセスしてサーバーが落ちないよう、間隔をあけて送信する技術。 |
| キャッシュ（Cache） | 一時保存領域 | 同時アクセス時に「誰がどの行を処理中か」を記録し、衝突を防止する。 |
| バックオフ（Backoff） | 再試行の待機処理 | エラー発生時に時間をおいて再実行する仕組み（例：10秒→20秒）。 |
| onEditトリガー | 編集イベント検知 | シート上で誰かがセルを編集した瞬間にスクリプトを自動起動する仕組み。 |
10. 要点まとめ
- ✅ Redmineチケット情報をワンクリックで取得
- ✅ 複数人同時操作でも安全（行ロック＋再試行機構）
- ✅ サーバー負荷を抑えた安定実行
- ✅ チェック後は自動リセットで整然
- ✅ 日報・タスク報告シートの更新が完全自動化
⚠️ 注意点（運用ルール）
🚫 絶対に変更・操作してはいけないこと
- ヘッダ名を変更しない
→ 各ヘッダは Redmineの項目名と連動 しており、名前を変更すると自動反映が正しく行われません。
例：チケット番号 / クライアント / プロジェクト(大) / 作業内容 / 期日など。 - C列（チケットフラグ）の位置を動かさない
→ スクリプトは「C列にチェックが入ったか」で動作を判定しています。列移動すると動作しません。 - チケット番号が空の行にチェックを入れない
→ 空欄の場合は処理されず、自動でフラグがOFFになります。
※全然チェックいれてもいいが、空欄のままだと処理されないだけです。 - トリガーを複数作成しない
→createOnEditTrigger()は最初の1回だけ実行してください。重複登録すると同じ処理が二重実行されます。 - Undo（元に戻す）Ctrl+Zで整合を取ろうとしない
→ スクリプト実行後のUI表示と内部値が一致しないことがあります。再実行はチェックON/OFFで対応。
※反映をやり直したい場合は「✅をOFF → 再度ON」にして再実行してください。
