Harnessを壊さずBANを避ける安全運用|本番変更・個人情報・復旧
LINE・Instagramの停止リスクを下げ、本番変更、個人情報、ユーザー統合、障害復旧を安全に扱う運用ルールです。 承認、対象限定、バックアップ、差分、戻し方を揃えてから変更します。 公式API、Webhook署名、送信条件、権限、レート制限を運用チェックへ落とします。 表示名ではなく安定IDと本人操作を使い、別人を同一人物にしない設計を確認します。
この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。
この記事の目次
最初に確認すること
- 本番変更前の5つの安全装置: 本番変更の直前にGO/NO-GOを自分で判断できる
- LINE・Instagramの停止リスクを下げる: アカウント停止につながる危険な自動化を公開前に見つけられる
- 個人情報とユーザー誤統合を防ぐ: LINE・Instagram・顧客DBを安全に紐付け、誤統合を検知・解除できる
- 壊れたときの復旧と質問テンプレート: 初心者でも障害の初動を行い、技術担当へ必要情報を安全に渡せる
本番変更前の5つの安全装置
承認、対象限定、バックアップ、差分、戻し方を揃えてから変更します。
この工程のゴール: 本番変更の直前にGO/NO-GOを自分で判断できる
相談者が最も怖がっていたのは、AIやカスタマイズが既存環境を壊すことでした。本番変更は、①対象、②影響、③バックアップ、④検証結果、⑤rollbackが揃うまで実行しません。
D1はTime Travelの対象と保持期間を現在の契約で確認します。復元操作自体は破壊的なので、復元コマンドを準備することと実行することを分けます。
手順
1. 対象を限定
検証アカウント、検証人物、検証タグ、変更ファイルを固定します。
2. 復旧地点を記録
commit、Worker/Pages deployment、D1 bookmark、現在設定を記録します。
3. 差分と検査
git diff、build、test、検証用E2Eを確認します。
4. 人間が承認
送信数、公開先、DB変更、停止方法を読み、GOの場合だけ実行します。
完了条件
- 変更対象と本番影響が明確
- 正常なcommit・deployment・DB地点を記録
- 自動検査と検証E2Eが成功
- 実行前に明示承認が入る
注意: D1の復元は本番DBを上書きします。復旧手順の確認だけでは実行せず、影響範囲を再確認します。
Academy教材: 壊さない・BANされない安全運用 / Lesson 11-1
LINE・Instagramの停止リスクを下げる
公式API、Webhook署名、送信条件、権限、レート制限を運用チェックへ落とします。
この工程のゴール: アカウント停止につながる危険な自動化を公開前に見つけられる
「絶対にBANされない」とは約束できません。公式APIと現行規約を使い、対象者の同意、送信頻度、24時間内のDM可否、エラー率、停止導線を公開前に確認します。
Webhookは外部から届く入力です。LINE署名とMeta署名を検証し、同じイベントの再送で二重処理しない設計にします。
手順
1. 公式経路を確認
非公式スクレイピングや個人アカウント自動操作がないか確認します。
2. 受信を守る
Webhook署名、timestamp、冪等キー、ログの秘密情報を確認します。
3. 送信を絞る
同意、対象、頻度、時間帯、配信停止、有人対応への切替を設定します。
4. 異常時に止める
4xx/5xx、token失効、配信失敗急増を監視し、停止責任者を決めます。
完了条件
- 公式APIだけを使用
- Webhook署名と重複防止を確認
- 送信対象・頻度・停止方法が明確
- 規約確認日と根拠URLを記録
注意: 安全性・規約・審査通過を保証する教材ではありません。公開時点の公式規約と、必要に応じて専門家の確認を優先します。
Academy教材: 壊さない・BANされない安全運用 / Lesson 11-2
個人情報とユーザー誤統合を防ぐ
表示名ではなく安定IDと本人操作を使い、別人を同一人物にしない設計を確認します。
この工程のゴール: LINE・Instagram・顧客DBを安全に紐付け、誤統合を検知・解除できる
過去に別アカウントを同一人物として扱ったという顧客の経験がありました。表示名、username、電話番号の部分一致だけで自動統合しません。
LINE user IDはProviderが変わると同じ人でも異なる値になります。既存アカウント移行ではProvider、Messaging API channel、LINE Login channelの関係を最初に確認します。
手順
1. 識別子を棚卸し
LINE user ID、IGSID、内部UUID、外部顧客IDの発行元と変更条件を表にします。
2. 本人操作で結ぶ
LIFF、track link、nonceなど一回限りの導線で対応を保存します。
3. 競合を止める
別IDが既存結合を上書きしないことと、重複候補が保留になることを確認します。
4. 解除と監査
誰がいつ何を根拠に結合・解除したかを残し、配信前に再確認します。
完了条件
- 安定IDと表示名を区別
- 本人操作で相互リンク
- 競合時に上書きしない
- 解除・監査・影響確認ができる
Academy教材: 壊さない・BANされない安全運用 / Lesson 11-3
壊れたときの復旧と質問テンプレート
変更を増やす前に止め、ログ・直前操作・影響範囲を揃えてサポートへ相談します。
この工程のゴール: 初心者でも障害の初動を行い、技術担当へ必要情報を安全に渡せる
相談できる安心は教材そのものと同じくらい重視されていました。質問は技術用語を知っている必要はなく、「何をした」「何を期待した」「実際はどうなった」を揃えれば十分です。
秘密情報、顧客のDM全文、個人IDをスクリーンショットへ含めません。緊急時は原因調査より先に誤配信とデータ更新を止めます。
手順
1. 被害を止める
配信、Cron、自動化、変更作業を止め、開始時刻を記録します。
2. 直前操作を固定
最後に成功した時刻、直前の一操作、エラーの最初の行を記録します。
3. 正常版へ戻す
承認済みのrollback手順がある場合だけ既知の正常版へ戻します。
4. テンプレートで相談
環境、再現手順、期待結果、実結果、影響、試したことをChatwork等へ送ります。
完了条件
- 影響拡大を止めた
- 最初のエラーと直前操作を特定
- 秘密情報なしで相談できる
- 復旧後E2Eと再発防止を記録
Academy教材: 壊さない・BANされない安全運用 / Lesson 11-4
公式ソース
- Cloudflare D1 Time Travel — D1の復旧地点と保持期間
- LINE Harness / .github/workflows/worker-ci.yml — LINE CI
- IG Harness / CONTRIBUTING.md — IGの開発・検査手順
- LINE webhook security — 署名検証と非同期処理
- LINE Harness / apps/worker/src/routes/webhook.ts — LINE Webhook処理
- IG Harness / apps/worker/src/routes/webhook.ts — Instagram Webhook処理
- LINE user IDs — Provider単位のuser ID
- LINE account linking — 本人操作によるアカウント連携
- LINE Harness / apps/worker/src/routes/users.ts — LINE論理ユーザー
- IG Harness / apps/worker/src/services/line-cross-link.ts — IG↔LINE相互リンク
- LINE Harness / apps/web/src/app/emergency/page.tsx — 緊急コントロール
- LINE Harness / apps/web/src/app/health/page.tsx — 健全性確認
- Cloudflare Workers logs — Workerログ
関連ガイド
Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。