公式LINE運用ルール ひな形Claude Code × LINE Harness

業務は基本すべて自動化してかまいません。唯一の例外が公式LINEの集客配信（broadcast / push / multicast）です。

• なぜ: 集客配信は導線の最上流。1通の誤送信が登録者の離脱・信用失墜に直結し、取り消せません。
• やり方:「これは公式LINEの集客配信か?」を毎回最初に判定。集客配信なら以下2〜4を厳守、それ以外は一気に進めてOK。

• 「本人テスト送信ですか? 全体配信ですか?」をAIに必ず確認させる。
• 明らかに個人宛の文脈でも一言添えさせる。
• なぜ: pushかbroadcastか曖昧なまま送ると、全登録者へ誤送信するリスクがある。

• いきなり全体配信しない。まず自分だけにpushでテスト送信 → 自分のLINEで実機確認 → OKを出してから全体配信。
• リンク付き配信は特に、テスト送信でリンクの遷移先を必ず実機で開いて確認。

• 送る前にAIに「以下の内容で送信します。よろしいですか?」と、送信先アカウント名・人数・本文を明示させる。
• 「進めて」「やって」だけを送信承認とみなさない。内容を見てから承認する。

• cron・定期実行・補助スクリプトから公式LINEへ自動配信させない。人間の明示承認（送信フラグ）がある時だけ送る。
• なぜ: 無人ジョブが公式アカウントへ自動送信する構造は、事故ったとき止められない。

• 配信・返信・タグ操作などLINE操作は、すべてLINE Harnessのモジュール／APIを通す。LINE Messaging APIの直叩きは禁止。
• なぜ: 直叩きすると配信履歴・タグ・スコアリング・不達トラッキングがすべて記録されず、以降の自動化が機能不全になる。
• 「モジュール不足」「エラーが出た」等を理由に直叩きへ逃げない。詰まったら手を止めて確認する。

• 友だちデータ・タグ等を管理画面から手で書き換えない。操作はAPI経由に統一。
• なぜ: AIがAPIで追跡している状態と管理画面の手動変更がズレると、自動化が不安定になる。管理画面は「見る専用」。

• 「送信しました」という画面表示を鵜呑みにしない。配信後にDBの実レコードで配信ステータスと件数を確認してから完了とする。
• 件数は「API受付数」と「実際に届いた数（実リーチ）」を分けて扱う。取れていない数字は「未取得」と正直に書く。推測で埋めない。
• 報告はチャンネル名を主語に。「〇〇（アカウント名）の友だち△△人へ送信」。チャンネル名なしの「全員に送りました」は使わない（全チャンネルに送ったと誤解される）。

• CTAボタン付き（申込・予約リンク等）の配信は、本文とボタンを1通のFlexにまとめる。本文の直下にボタンが固定表示される形。
• なぜ: 本文とボタンを2通に分けると、順番が入れ替わったりボタンが本文から離れて、押されにくくなる。1通統合なら配信順の事故ゼロ・視認性も高い。