まず使える：構築後の日次・週次モニタリングチェックリスト
最初に、明日から使える形のチェックリストを置きます。項目そのものはリポジトリの運用ドキュメントに定義されているものですが、確認先のAPIを実装コードと照合し、「誰がやるか」と「異常が出たときの一次対応」を足して再構成しています。
なお、この記事のチェックリストは稼働後の日次・週次のものです。公開前に一度だけ確認する項目については、前述の運用基盤を作る手順の記事に公開前チェックリストがあります。役割が違うので、両方を混ぜないでください。
先に：APIで確認するための前提
APIキーがまだ無い場合は、先にBAN耐性3問へ進んでも構いません。
表の中にAPIが出てきますが、これらを叩くにはAPIキーが必要です。 キーの持ち方は1つではありません。メインアカウント分は環境変数として保持されており、それとは別に、スタッフごとの役割別のキーがデータベースのテーブル（staff_members）で管理されています。 どちらもLINE Harnessのデプロイを管理している人（多くの場合は開発担当）が発行するもので、運用担当が自分で発行することはできません。 ただし発行の「手段」自体は、コマンドラインやデータベース操作である必要はありません。ドキュメント（25-Staff-Management.md）によれば、管理画面のサイドバー「設定」→「スタッフ管理」（owner権限のスタッフにのみ表示される）から、フォーム入力だけでキーを発行できる画面が用意されています。この画面の存在とowner限定表示は、実装コード（管理画面のソース）でも確認できました。
まだ持っていない場合の分岐は3つです。
-
依頼する：「日次チェック用のAPIキーがほしい」と開発担当に依頼してください。実装コードを確認すると、スタッフごとに
owner／admin／staffの役割別キーを発行する仕組みがあり、staff権限のキーだと個別アカウント詳細APIのチャネルシークレット・アクセストークンは省かれます。ただし「読み取り専用」というAPIの区分自体があるとは限らない（役割はowner／admin／staffの3段階であり、機能単位の細かい読み取り専用スコープではない）ので、依頼としては用途と役割を伝える形にしてください。 - 管理画面で代替する：キーが届くまでは、管理画面に対応する表示があれば同じ項目をそこで確認して構いません。ただし表示があるかどうか自体を私たちは確認できていません。 画面名やボタン名、操作手順はこの記事では扱いません。実機での確認が取れていないためです。
-
依頼できる人がいない：社内に「開発担当」という肩書きの人がいなくても、詰みとは限りません。ドキュメントには、
staff_membersにキーが見つからない場合は環境変数API_KEYと比較し、一致すれば常にownerとして扱う、という後方互換の挙動が明記されています。 つまり、デプロイ時に発行された元のAPI_KEYを知っている人が社内に1人でも残っていれば、その人が上記の管理画面から自分で新しいキーを発行できます。この記事だけでは閉じない境界になるのは、元のAPI_KEY自体を社内の誰も把握していない場合に限られます。 その場合は記事末尾の相談範囲の節を見てください。
そしてもう1つ、キーを待つあいだの選択肢があります。APIキーがまだ手元にない場合は、このチェックリストを飛ばして、先に後述の「自社のBAN耐性を判定する3問」へ進んで構いません。 あの3問はAPIキーも管理画面もデータベースも要らず、今日そのまま実行できます。しかもこの記事の中でいちばん効きが大きいと考えている行動です。キーが届くまで手を止める必要はありません。
日次で見る5項目
複数のLINE公式アカウントを運用している場合は、表を読む前に1点だけ。日次1のアカウントの状態は、アカウント単位の確認です。 状態の判定も確認先のAPIもアカウントごとに分かれているので、運用しているアカウントIDの数だけ実行してください。 下の表は1アカウント分の書き方をしていますが、単一アカウント前提の日課として読まないでください。
残る日次2〜4（未返信のチャット、止まった一斉配信、失敗した自動化ログ）については、それぞれの確認先が全アカウント横断の集計を返すのか、アカウント単位なのかを、私たちは確認できていません。 ルートが実際にマウントされ呼び出せることまでは実装コードで確かめましたが、返ってくる数字がどの範囲を指しているかまでは読んでいません。どちらであるとも書けないので、複数アカウントを運用している場合は、数字の対象範囲を開発担当に一度確認してください。 なお日次5（未送信の通知）は、下の表のとおり現在のビルドでは呼び出せるルートがないため、この段落の対象から外しています。
複数アカウントを運用している場合、下表は1アカウント分の書き方です。日次1（アカウントの状態）は、運用しているアカウントIDの数だけ実行してください。
| # | 見る項目 | 確認先 | 担当 | 異常が出たときの一次対応 |
|---|---|---|---|---|
| 日次1 | アカウントの状態 | GET /api/accounts/{アカウントID}/health のリスクレベル | 自分 | 正常以外なら、後述のリスクレベル対応表へ |
| 日次2 | 未返信のチャット | GET /api/inbox/unanswered/count（一覧は GET /api/inbox/unanswered） | 自分 | 放置されている問い合わせを当日中に処理する |
| 日次3 | 配信中のまま止まった一斉配信 | GET /api/broadcasts で状態を確認し、個別の進捗は GET /api/broadcasts/{配信ID}/progress | 自分 | 止まっている配信を特定し、再送の可否を判断する（後述の再送の注意を参照） |
| 日次4 | 失敗した自動化ログ | GET /api/automations/{ルールID}/logs | 自分 | 失敗しているルールを一旦止めて、条件を見直す |
| 日次5 | 未送信の通知 |
廃止・現在のビルドでは呼び出せません。 GET /api/notifications のハンドラーファイル自体はリポジトリに残っていますが、実装コードのindex.tsのルート登録には含まれておらず、実際には404になります。index.tsには、インボックス機能（/api/inbox/unanswered、日次2で確認済み）に置き換えて廃止した、という開発者コメントがあります。管理画面に代替の表示があるかは確認できていません |
なし（現状はセルフチェックの手段がありません） | 通知の滞留が気になる場合は、日次2（未返信のチャット）で代替できないか検討するか、開発担当に代替手段の要否を確認してください |
日次2の呼び方について1点補足します。運用ドキュメント（22-Operations.md）のチェックリストは、この項目を「未読チャット」（/api/chats?status=unread）と呼んでいます。 この記事では、実装コードで存在を確認できた別のAPI（/api/inbox/unanswered）に差し替えて「未返信のチャット」としています。両者は同じものではありません。 status=unread はスタッフが対応ステータスを更新したかどうかのフラグで、/api/inbox/unanswered は自動応答も含めて返信の証跡があるかどうかを見ています。読んだ・触った後でも返信していなければ未返信のほうには残り続けます。用語が変わっているのはこの理由です。
日次1の確認先については、リスクレベルがどう決まるかを次々章で詳しく扱います。ここでは「どこを見るか」だけに留めます。
週次で見る4項目
複数アカウントを運用している場合、週次1・2の数値がアカウント横断の集計かアカウント単位かは確認できていません。開発担当に対象範囲を確認してください。
| # | 見る項目 | 確認先 | 担当 | 異常が出たときの一次対応 |
|---|---|---|---|---|
| 週次1 | コンバージョンの推移 | GET /api/conversions/report | 自分 | 落ち込みがあれば配信・導線側の変更履歴と突き合わせる |
| 週次2 | アフィリエイトの成果 | GET /api/affiliates-report（個別は GET /api/affiliates/{アフィリエイトID}/report） | 自分 | 数値の異常は配信側の変更と突き合わせる |
| 週次3 | スコアの分布 | 管理画面に該当する表示があればそこで確認。無い場合、またはセグメント別の集計が必要な場合は開発担当へ | 開発担当が主担当（自分は表示があれば見る程度） | 高スコアの友だちへのフォローアップを設計する |
| 週次4 | データベースの使用量 | Cloudflareのダッシュボードでの確認が必要（Workers側のAPIには該当するルートがありません） | 開発担当 | 上限に近づいていれば、後述のログ削除の依頼へ |
週次1・2についても、複数アカウントを運用している場合の注意があります。これらのレポートがアカウントをまたいだ集計を返すのか、アカウント単位なのかを、私たちは確認できていません。 どちらであるとも書けないので、複数アカウントを運用しているなら、数字がどの範囲を指しているのかを開発担当に一度確認してください。
週次3について補足します。スコアの分布を返す専用のAPIは、実装コードには存在しませんでした。 友だち単位でスコアを取るAPIはありますが、分布の集計はデータベースへの直接の問い合わせになります。だからここは開発担当の担当です。管理画面に分布の表示があれば自分でも見られますが、表示があるかどうかは確認できていないので、あることを前提にした手順は書きません。
担当の割り振り方の原則
データベースへの直接の問い合わせ、コマンドラインの操作、Cloudflareのダッシュボードへの直接アクセスが必要な項目は、運用担当の日次・週次のルーティンに入れません。 該当するのは週次4の全体、週次3の集計部分、そして日次5（現在のビルドではAPIが呼び出せないため、確認自体を開発担当に依頼する必要がある項目）です。いずれも記事の後半にある依頼文をそのまま開発担当に渡してください。
結果として、運用担当が自分で回せるのは日次4項目（日次1〜4）と、週次1・2の2項目です。ただしここは条件付きで読んでください。この6項目（日次1〜4と週次1・2）はいずれもAPIキーが前提で、そのキーを運用担当は自分で発行できません。 代替として案内した管理画面のほうも、該当する表示があるかどうか自体を確認できていません。つまり正確には「キーが手元にあれば自分で回せる6項目」です。日次5（未送信の通知）は、現在のビルドでは呼び出せるルートがないため、この数には含めていません。週次3は「管理画面に表示があれば追加で見る」という条件付きの分で、確定的な週課には数えません。
結論：BAN対策は「BANされてから」ではなく「友だち追加URLの作り方」で決まる
ここがこの記事でいちばん伝えたい部分です。
先に検証の水準を明示します。以下の移行の仕組みとUUID取得の条件は、フォークのリポジトリ内ドキュメント（18-Multi-Account-and-BAN.md と Friends.md）の記載に基づくものです。実装コードでの検証は今後の課題であり、この記事では「ドキュメントがこう記述している」という水準を超えません。
この慎重さには理由があります。同じドキュメント群の中に、実装と食い違っている記述が実際に2件見つかっているためです。1つはBAN検知の通知設定例が、実装コード上は動かない可能性が高いこと（詳しくは次章で扱います）。もう1つは、外部からのアクセス制限（CORS）の記述が実装と食い違っていること（詳しくは複数アカウント章で扱います）です。ドキュメントに書いてあることが必ずそのまま動く、という前提は置けません。
アカウント移行は、友だちを移すわけではない
LINE Harnessには、アカウントが使えなくなったときのための移行機能があります。移行の履歴を管理するテーブルがあり、移行を開始するAPIも用意されています。
問題は、この「移行」が何をするのかです。ドキュメントの記述はこうなっています。フォロー中の友だち全員を移行対象の件数としてカウントしたうえで、実際の移行はUUIDベースで、ユーザーが新しいアカウントを友だち追加した時点で内部の共通IDによって自動マッチされる、と。
つまりこれは、こちらから友だちを押し出す仕組みではありません。友だち本人が新しいアカウントを追加してくれたときに、こちら側で「この人は前のアカウントのあの人だ」と突き合わせる、受動的な仕組みです。「移行を実行すれば友だちが自動で移る」わけではない、と理解してください。
もうひとつ、書けないことも書いておきます。ドキュメントには、移行を開始するとステータスが即座に「進行中」になるところまでしか記載がありません。移行済みの件数がどの処理で増えるのか、どういう条件で「完了」や「失敗」に変わるのかは、ドキュメントに書かれていません。 したがってこの記事で書けるのは「移行を開始できる」ところまでで、完了の判定手順は書けません。
QRコードとLINE検索から追加された友だちには、共通IDが付かない
ここが噛み合う部分です。ドキュメントは、友だち追加の方法によって内部の共通IDが取れるかどうかが変わる、と明記しています。
| 友だち追加の方法 | 共通IDが自動で付くか | ドキュメントの説明 |
|---|---|---|
| /auth/line?ref=（推奨と明記されている経路） | 付く | LINEログインを経由して識別子を取得し、ユーザーを作成して友だちに紐づける |
| QRコードを直接読み取る | 付かない | 友だち追加の通知だけが届くため、友だちとしては登録されるが共通IDは空のまま |
| LINEのID検索から追加する | 付かない | 同上 |
| 追加後にLINE内のアプリでログインする | 付く（ただし本人のログイン操作が前提。ドキュメントもこの経路だけは「自動」ではなく「手動/自動」と区別して表記している） | ログイン時の識別情報から紐づける |
そしてドキュメントは、運用ルールとして「友だち追加URLは必ず /auth/line?ref= を使うこと」とはっきり書いています。
前節と組み合わせると、こうなります。QRコードやLINEのID検索で集めた友だちは共通IDが空のままである可能性が高く、その場合、アカウントが使えなくなったあとの移行で機械的に突き合わせることができません。 これはドキュメントが直接そう書いている主張ではなく、2つの記述をつないだ帰結です。断定ではなく、帰結として読んでください。
だから友だち追加URLを /auth/line?ref= に統一する
やることは1つです。LP、SNSのプロフィール、広告、リッチメニュー、メールの署名まで、友だちを増やす導線のURLをすべて /auth/line?ref= の形に差し替えます。
ここで大事なのは、この行動をとるべき理由は、前節で付けた留保に左右されないということです。理由は3つあります。
- 「友だち追加URLは必ずこの経路を使う」は、ドキュメントが運用ルールとして明記していることそのものです。移行の実装詳細がドキュメントと違っていたとしても、このルールは変わりません。
- この経路を使うと、共通IDの取得とは別に、どの導線から友だちになったかを示す値、UTMパラメータ、広告のクリック識別子も同時に記録されます。 流入元の分析がそのままできるようになる、という独立した利点があります。
- 差し替え作業そのものは運用担当が自分でできます。APIキーも管理画面の権限も要りません。
なお、既存の公開記事でも流入元ごとにパラメータを付けておくと計測しやすい、という案内はしています。この記事が足しているのは、そのパラメータ付与が「計測のため」だけでなく「アカウントが使えなくなったときの突き合わせのため」でもある、という因果の側です。
自社のBAN耐性を判定する3問
コピーして社内で使える形にしました。3問とも、運用担当が自分だけで答えられる粒度に収めてあります。 APIキーも管理画面も、データベースへの問い合わせも要りません。
Q1（いま：止血）いま稼働している友だち追加の導線が、すべて /auth/line?ref= に統一されているか。
対象はLP、SNSのプロフィール欄、広告のリンク先、リッチメニューのボタン、店頭やメールの案内など、現在も友だちが増え続けている導線すべてです。
- 統一されていない導線が1つでも生きている場合、共通IDの付いていない友だちは今日も増え続けています。
- 是正は運用担当の作業です。該当するURLを差し替えてください。Q2より先にこれを終わらせてください。
Q2（過去：回収）これまでに使った導線を時系列で書き出し、/auth/line?ref= を通っていなかった期間があるか。
QRコードでの案内、LINEのID検索での案内、過去のLPや広告のURLを、いつからいつまで使っていたかという期間の形で書き出してください。
- 何人残っているかは数えないでください。 未紐付けの件数を運用担当が確認できる手段を、私たちは検証できていません。検証できていない確認方法を手順として書くわけにはいかないので、代わりに期間を書き出してもらう形にしています。期間が分かれば回収施策の規模感はつかめます。
- 未統一だった期間があれば、その期間に入った友だちには共通IDが付いていない可能性が高い、と考えてください。
Q1とQ2の関係を1文にすると、Q1は蛇口を締める話、Q2はすでにこぼれた分を拾う話です。Q1を先に片付けないと、Q2の回収がいつまでも終わりません。
Q2の是正：あとから紐づけ直す経路と、その制約
ドキュメントには、共通IDが付いていない友だちをあとから紐づける経路が3つ記載されています。このうちLINE内のアプリでのログインとAPIでの手動リンクの2つについては、対応するAPIのルートが実装コードに存在することを確認しました。フォーム送信時のメールアドレス一致は、ドキュメントに記載があるところまでで、実装コードでは確認していません。
| 経路 | 何が起きるか | 実務上の扱い |
|---|---|---|
| LINE内のアプリでのログイン | 友だち本人がログインすると、ログイン時の識別情報から共通IDが紐づく | 運用上の本命。 ただし本人の操作が前提 |
| APIでの手動リンク | 運用側から特定の友だちとユーザーを対応づける | 対応関係を別途特定できる場合に限られる。実行は開発担当 |
| フォーム送信時のメールアドレス一致 | フォームの送信内容から自動で紐づく | 新たにフォームを送ってもらう接点が発生した場合のみ |
必ず併記しておきます。これは運用側から一方的・一括で発火できる処理ではありません。 本命であるLINE内アプリのログインも、友だち本人がもう一度ログインを通る必要があります。実務としては「LINE内アプリを使う施策（予約、フォーム、会員証など）を1本走らせて、そのついでに回収する」形になります。「ボタンひとつで全員を紐づけ直せる」とは書けません。
したがってQ2の結論は「手遅れ」ではなく、こうです。統一されていない導線から入った分は、LINE内アプリを通る施策で回収する計画を立てる。今後の獲得分は導線を /auth/line?ref= に統一して、これ以上増やさない。
Q3（体制）アカウントの状態が danger（危険）と判定されたときに、それが人に届く経路が用意されているか。
リスクレベルはツール側で normal（正常）／warning（警告）／danger（危険）の3段階として扱われます。この記事では、APIから実際に値として返る英語表記のほうを正本にします。 判定の中身は次章で扱います。
用意されていない場合、それ自体が開発担当への依頼が必要という判定です。 理由と依頼文は次章に置きます。
BANリスクはどう判定されるか：5分ごとに見ている3つのシグナル
以下の判定条件と間隔は、フォークのリポジトリ内ドキュメント（18-Multi-Account-and-BAN.md と 22-Operations.md）の記載に基づくものです。実装コードとの照合は行っていません。 この1文がこの章全体にかかります。個々の数値に「ドキュメントによれば」を付け直しませんが、確定した仕様として読まないでください。
403／429／直近1時間で5000通 — 何がどのリスクレベルになるか
ドキュメントの記述では、定期実行の仕組みが5分ごとにアカウントの状態を確認しています。有効な各アカウントについてLINE側の情報取得APIにリクエストを送り、その結果でリスクレベルを判定します。
| 観測されたこと | 付くリスクレベル | 意味 |
|---|---|---|
| 正常に返った（200） | normal | 正常 |
| 拒否された（403） | danger | アカウントが使えなくなっている可能性が高い |
| 制限に当たった（429） | warning | レート制限を超過している |
| 直近1時間の送信が5000通を超えている | warning | 大量送信の警告 |
| ネットワークエラー | 記録される | 判定不能として記録される |
判定の結果はログのテーブルに記録され、そのアカウントのリスクレベルは最新のログから取得されます。ログが1件もない場合は正常として扱われます。 ここは運用上わりと重要で、「normal という値が返る」ことと「実際に確認できている」ことは同じではありません。 稼働直後や定期実行が止まっているときも、返る値は normal になり得ます。
リスクレベル対応表
この表の判定条件と間隔も、上の帰属の範囲内です（フォークのリポジトリ内ドキュメントの記載に基づき、実装コードとの照合は未実施）。
| リスクレベル | どんなときに付くか | ツール側がすること | 運用側の一次対応 | 人が判断すること |
|---|---|---|---|---|
| normal | 情報取得が正常に返った | ログに記録する | なし | なし |
| warning | レート制限に当たった、または直近1時間の送信が5000通を超えた | ログに記録する | 送信頻度を下げる、配信間隔を広げる | 予定している配信のどれを止め、どれを遅らせるか |
| danger | 情報取得が拒否された（アカウントが使えなくなっている可能性） | ログに記録する（ドキュメント上、この先の挙動は後述） | 即座に状況を確認し、必要に応じてアカウント移行を開始する | 移行を始めるかどうか。ここは通常のエンジニア依頼とは別の層です（下記） |
dangerの行について、先に境界を明示しておきます。 「必要に応じてアカウント移行を開始する」は、運用担当が1人で完結できる作業ではありません。移行先のアカウントを用意しておくこと、権限を誰が持つか決めておくこと、緊急時に誰が実行判断をするかを決めておくことが前提になります。緊急移行の体制を事前に用意していない場合、この行は記事だけでは閉じません。 これは記事末尾の相談範囲の節につながる話です。
注意：dangerを検知しても、通知は飛ばないおそれがある
ここは実際にリポジトリを読まないと分からない部分なので、丁寧に書きます。
まず事実として確認できたこと。danger を検出したときの挙動について、ドキュメントに書かれているのはコンソールにエラーログを出力するところまでです。 外部への通知については記載がありません。「実装に通知機能が一切ない」と断定はできませんが、ドキュメントには書かれていない、というのが確認できた水準です。
そのうえで、運用ドキュメントには「danger を検出したときにチャットツールへ通知する」自動化ルールの設定例が載っています。ところがこの設定例が使っているきっかけの種類と処理の種類は、自動化の仕様書（14-Automation.md）が定義している一覧（きっかけ7種類・処理8種類）のどちらにも該当しません。ここまではドキュメント同士を突き合わせた結果です。 加えて、この2つの文字列は実装コード（イベントバスの定義）の中にも見つかりませんでした。こちらは実装コードを直接確認した結果です。
つまり、この設定例はそのままでは動かない可能性が高いということです。
ここは「動かない」と断定しません。 ドキュメントの誤りなのか、これから実装される機能の予告なのかを、私たちはまだ確定できていないためです。ただ、danger を検知しても、ドキュメント上はコンソールにログが出るだけで、誰にも届かないおそれがある、という実害の可能性は運用判断に直結します。
裏を返すと、この記事の日次チェックリストの日次1（アカウントの状態を毎日見る）は、通知が来ないかもしれない前提での代替手段でもあります。通知経路が整うまでは、目視の頻度で埋めるしかありません。
通知経路は開発担当に依頼する
外部から定期的に状態を取りに行って通知する仕組みの構築は、運用担当の作業ではありません。 次の依頼文をそのままコピーして渡してください。
LINE Harnessのアカウントヘルスを外部から5分間隔でポーリングして、
riskLevel が danger（または warning）になったら Slack かメールに通知する仕組みを作ってほしいです。
参照先は GET /api/accounts/{アカウントID}/health です。
公式の運用ドキュメントに載っているアラート設定例（health_check イベント ＋ send_notification アクション）は、
自動化エンジンのイベント一覧・アクション一覧に見当たらないため、
そのままでは動かない可能性が高いです（要確認）。
この仕組みがないと、BANの可能性を検知しても、
ドキュメント上はコンソールログに出るだけで誰にも届かないおそれがあります。
まず、この設定例が実際に動くかどうかの確認からお願いしたいです。
複数アカウントは、いつ・どう増やすか
増やす判断のトリガー
ここは運用担当が判断する領域です。 ただし「何をもって増やすか」の基準は、ドキュメントにも実装コードにも書かれていません。以下の3つは、ここまでで確認できた2つのこと — 警告が付く条件（レート制限に当たる、直近1時間の送信量が閾値を超える）と、状態の判定も配信もアカウント単位で管理されること — から導いた整理です。私たち自身の運用実績に基づくものではありません。
- 負荷の分散：1つのアカウントに配信が集中していて、警告レベルの判定が出やすくなっている。
- 警告の頻発：日次チェックでwarningが繰り返し出る。前章の対応（送信頻度を下げる、間隔を広げる）で吸収しきれない場合、配信量そのものを分ける判断が要ります。
- 用途の分離：新規向けとリピーター向け、ブランド別、店舗別など、混ぜないほうがよい導線がある。
アカウントを増やすこと自体はBAN対策ではありません。 前章のとおり、アカウントが使えなくなったときに友だちを引き継げるかどうかは、共通IDが付いているかで決まります。先にQ1の導線統一を済ませていないと、アカウントを増やしても引き継ぎの土台がありません。 順序が逆にならないようにしてください。
追加アカウントはデータベースに入る。環境変数はメインアカウントだけ
構成上のポイントがひとつあります。ドキュメントの記述では、環境変数として保持されているのはメインアカウントの認証情報だけで、追加したアカウントはデータベースのテーブルから動的に読み込まれます。
つまり追加作業は、設定ファイルを1行足すような作業ではなく、データベースへの登録と、必要に応じた環境変数の操作になります。ここは開発担当の作業です。依頼文はこちらです。
LINE公式アカウントを1つ増やしたいです。
追加分は line_accounts テーブルにDB経由で登録される想定で、
環境変数（wrangler secret put）で持っているのはメインアカウントの分だけと聞いています。
登録作業をお願いしたいのと、あわせて権限設計の相談をさせてください。
owner／admin／staffの役割別にAPIキーを発行できる仕組みがあり、
staff権限のキーだとチャネルシークレットとアクセストークンは省かれる
一方でowner／admin権限のキーだと含めて返ると聞いています。
誰にどの役割のキーを渡すかを一緒に決めたいです。
増えたあと、複数アカウントを日々どう見分けて回すか
アカウントが2つ以上になると、次に出てくるのは「どこで切り替えるのか」という問いです。先に整理しておきます。この記事の範囲でいう「切替」は、画面上の操作ではなく、対象アカウントIDの指定です。
実装コードのルート登録を確認すると、運用で使うエンドポイントはアカウント単位に分かれています。状態を見る GET /api/accounts/{アカウントID}/health がその代表で、どのアカウントを見るかは、このIDを差し替えることで決まります。 つまり日々の実務は「切替ボタンを探すこと」ではなく、運用中のアカウントIDの一覧を手元に持っておくことになります。一覧そのものは GET /api/line-accounts で取得できます。
ここが冒頭のチェックリストとつながります。日次1（アカウントの状態）は、持っているアカウントIDの数だけ実行する — これが複数アカウント運用での日課の形です。
アカウントを横断する経路として確認できているものは、いまのところ1つだけです。次章で扱う複数アカウント横断・重複排除つきの一斉配信（multi-account-dedup）で、実装コードにルートと型定義が存在することを確認しました。 ただし確認できているのはそこまでで、重複をどう判定するのか、優先順位がどう働くのかは書けません。これ以外に、複数アカウントの状態をまとめて1回で返す経路は見つかっていません。
なお、管理画面にアカウントを切り替える表示があるかどうかは、私たちは確認できていません。 実機での確認が取れていないためです。無いとも断定しません。この記事はAPIで見える範囲について書いている、と理解してください。
運用上の注意：役割別のAPIキーはあるが、範囲は自社で設計する
権限設計の話をもう少し具体的にします。実装コードを確認すると、スタッフ（owner／admin／staffの3段階）ごとに個別のAPIキーを発行する仕組みが実装されています（staff_membersテーブル、role列と一意なapi_key列）。アカウント詳細を返すAPIも、staff権限のキーで呼ぶとチャネルアクセストークンとチャネルシークレットは省かれ、owner／admin権限のキーで呼んだときだけ含めて返る、という役割に応じた出し分けが実装されています。
ただし、これは「発行すれば自動的に安全な体制になる」という意味ではありません。誰にowner／admin／staffのどの役割を割り当てるか、複数アカウントをまたいでキーをどう配るかは、機能として用意されているだけで、実際の割り当ては自社で設計する必要があります。 外部からのアクセス制限（CORS）は、実装コードを確認したところADMIN_ORIGIN環境変数で許可オリジンをあらかじめ指定する方式になっており、ドキュメントが示唆するような「全許可」の状態ではありませんでした。
これは「このツールは危ない」という話ではありません。セルフホスト型のツールを複数アカウントで運用するときは、用意されている役割区分をどう割り当てるかを自社で決める必要がある、という一般的な構成上の帰結です。誰にどの役割のキーを渡すか、どこからのアクセスを許すかを決めるのは開発担当の領域なので、アカウントを増やすタイミングで一緒に相談してください。
なお、URLのプレフィックスが2種類あって取り違えやすいので、ここで整理しておきます。実装コードのルート登録を確認したところ、これは矛盾ではなく役割の違う2系統でした。
| プレフィックス | 担当する範囲 |
|---|---|
| /api/line-accounts | アカウントの一覧、詳細、作成・更新・削除 |
| /api/accounts | アカウントの状態確認と、移行に関する操作 |
ドキュメントだけを読んでいると混ざります。状態と移行は /api/accounts、アカウントそのものの管理は /api/line-accounts と覚えてください。
一斉配信の運用判断：4つの配信方式の選び分けと、送ったあとに起きること
配信ステータスの遷移と、再送が重複を生みうるという帰結は、いずれもフォークのリポジトリ内ドキュメント（Broadcasts.md）の記載のみを根拠としており、実装コードとの照合は行っていません。特に「再送で重複しうる」はドキュメントに明記された仕様ではなく、記述から導いた推論です。
配信の状態は、下書き → 予約済み → 配信中 → 配信完了、という順に進みます。配信中と配信完了になったものは編集も削除もできません。予約日時を設定すると自動的に予約済みになり、予約日時を空に戻すと下書きに戻ります。
全員宛は速いが、配信数が取れない
全員宛の配信は、LINE側の一斉配信APIを使う最もシンプルで速い方式です。ただし正確な送信数が取得できません。 対象数は0として記録されます。
したがって、配信数や到達数を見て次を判断したい配信には向きません。 全員に同じ内容を最短で出す用途に限定してください。
タグ宛は500件ずつのバッチ。配信数と成功数が残る
タグ宛の配信は、500件ずつに分けて送る方式です。対象数と成功数が記録されるので、あとから検証できます。 フォローを外している友だちは、タグ宛の配信時に自動で除外されます。
なお、タグの設計そのもの（自動付与の経路や、増えすぎたタグの棚卸し）はこの記事では扱いません。特に、複数のシナリオが同じ友だちに重なって配信されるのを止めるタグ設計については、LINE Harnessで重複配信を防ぐシナリオの作り方で、履歴を表すタグと現在地を表すタグを分ける具体的な組み方を解説しています。
セグメント配信で「Aを持ちBを持たない」を作る
セグメント配信は、条件をANDとORで組み合わせて対象を絞る方式です。使える条件は6種類あります。
- 特定のタグを持っている／持っていない
- 保存されている属性値が特定の値と一致する／一致しない
- 特定の流入経路から来ている
- フォロー中かどうか
実務でいちばん使うのは「Aのタグを持っていて、Bのタグを持っていない人」という形です。購入済みの人を除外した案内、特定のシナリオに入っていない人だけへの案内などがこれにあたります。
予約配信は最大5分遅れる前提で時刻を決める
この遅延幅は、フォークのリポジトリ内ドキュメント（Broadcasts.md）の記載に基づくものです。実装コードとの照合は行っていません。
予約配信は、5分ごとに動く定期実行が「予約済みで、予約時刻を過ぎているもの」を検出して実行します。この構造上、予約時刻から最大5分の遅延が発生し得ます。
運用上の帰結はシンプルです。分単位で時刻が意味を持つ配信（タイムセールの開始通知、番組の開始告知、締切の直前案内）を、予約配信の時刻ちょうどに合わせないでください。 5分前倒しで予約するか、時刻の表現を「まもなく」のように幅のある書き方にするか、どちらかです。
配信が失敗したときの再送は、重複を生みうる
ドキュメントの記述では、失敗時の挙動は2段階に分かれています。500件ずつのバッチ単位で失敗した場合はそのバッチを飛ばして次のバッチへ進み、全体として失敗した場合はステータスを下書きに戻して再試行できるようにします。
ここから導かれる注意点があります。全体が失敗して下書きに戻ったものをそのまま再送すると、すでに送信が完了していたバッチの相手に二重で届く可能性があります。 これはドキュメントに明記された仕様ではなく、上の記述から導いた推論です。断定はしませんが、再送の前に、どこまで送られたのかを進捗APIで確認する運用にしておくほうが安全です。
日次3のチェック（配信中のまま止まった配信がないか）は、まさにこの状態を早く見つけるための項目です。
配信方式の選び分け表
| 配信方式 | 送信数が取れるか | 重複のリスク | 使う場面 |
|---|---|---|---|
| 全員宛（all） | 取れない（対象数は0） | — | 全員に同じ内容を最短で出す。効果検証をしない配信 |
| タグ宛（tag） | 取れる（対象数と成功数） | 全体失敗後の再送時に注意 | セグメントを絞った通常の配信。基本はこれ |
| セグメント配信 | 取れる | 条件の設計次第 | 「Aを持ちBを持たない」のような条件が要るとき |
| 複数アカウント横断・重複排除つき（multi-account-dedup） | 実行後にアカウント別の内訳を確認するAPIがある | 重複排除を意図した方式 | 複数アカウントを運用していて、同じ人への二重配信を避けたいとき |
4行目についてだけ、この記事の建付けから外れる注記をします。 この記事のほかの記述はリポジトリ内のドキュメントを主な根拠にしていますが、この方式はドキュメントに記載がなく、実装コードのルート登録と型定義でのみ存在を確認しました。 作成時に対象のアカウントIDと優先順位を指定する形で、事前確認用のAPIと、実行後にアカウント別の内訳を見るAPIがあります。
ただし、重複をどう判定するのか、優先順位が具体的にどう働くのかは書けません。 処理の中身までは読んでいないためです。「そういう方式が存在する」ところまでが、確認できた水準です。
ステルスモードが勝手にやっていること
以下の分散幅とジッターは、フォークのリポジトリ内ドキュメント（18-Multi-Account-and-BAN.md と Broadcasts.md）の記載に基づくもので、2つのファイル間で表記に差があります。実装コードで照合できたのは、レート制限の既定値（毎分1000回）のみです。
配信すると、意図しない挙動に見えるものが2つ起きます。先に運用上の実害だけ押さえてください。
1. 配信がすぐ終わらない。 送信規模に応じて自動的に時間をかけて分散されます。ドキュメントの記述では、100人以下ならミリ秒単位、約1000人以下なら約2分間、1000人を超えると約5分間に均等に分散されます。「送信ボタンを押したのに全員に届いていない」ように見えるのは、多くの場合これです。 配信直後に到達を確認して慌てないでください。
2. コピーした本文に見えない文字が混ざる。 テキストの一斉配信には、目に見えない文字が挿入されます。配信済みの本文をコピーして別の場所に貼り付けると、見えない文字がついてきます。 本文を再利用するときは、テンプレート側の原稿からコピーしてください。
この機能について、効果と規約上の是非は主張しません。 ドキュメントは「BAN防止のベストプラクティス」という位置づけで説明していますが、それによってBANされないという検証記録は存在しません。 この記事で書けるのは「実装がこう動く」までです。仕組みの詳細を確認したい場合は、LINE Harnessの公開OSSリポジトリ（Pathosionのフォーク元）にある18-Multi-Account-and-BAN.mdを参照してください。公開リポジトリでの到達性は2026年7月29日時点で確認済みですが、この記事が読んだスナップショット（5de1a47、2026年6月19日時点）以降の更新は反映されていない場合があります。
シナリオ運用：ステップ配信の時刻は前後5分ずれる前提で組む
見出しにある「前後5分のずれ」（実装上の呼称はジッター）は、フォークのリポジトリ内ドキュメント（18-Multi-Account-and-BAN.md と Scenarios.md）の記載に基づくものです。実装コードとの照合は行っていません。
すでに組んであるステップ配信は、稼働後に「時刻どおりに出ない」「途中で止まっている」という形で運用担当の手に戻ってきます。この章はその2つを扱います。
遅延の設定値と、時刻厳守の配信に使わないという判断
ドキュメントの記述では、ステップ配信の次回配信時刻にはマイナス5分からプラス5分のランダムなずれが加算されます。 複数の友だちを処理するときは、送信の間にもごく短いランダムな遅延が入ります。
運用上の判断はこうなります。
- 時刻に幅があってよい配信（追加から3日後のフォロー、1週間後の再案内など）は、そのまま組んで問題ありません。
- 分単位で時刻が意味を持つ配信は、ステップ配信で組まないでください。前章の予約配信と同じ判断です。両方に5分程度のずれが乗る前提で設計してください。
- 追加直後に送る初回ステップについては、待ち時間を0に設定したものは定期実行を待たずに即時配信される、とドキュメントに記載があります。
ステップが配信されないとき：症状を言語化して開発担当に渡す
止まったときの確認先は、シナリオの進行状態を持つテーブルの中身と、定期実行が動いているかどうかです。どちらも運用担当が自分で確認できる手段を、私たちは検証できていません。 データベースへの直接の問い合わせになるためです。
したがって運用担当がやるのは、症状の言語化までです。
- いつから止まっているか
- 対象は特定の友だちだけか、全員か
- 直前に何を変更したか（シナリオの編集、タグの付け替え、配信の実行など）
そのうえで、次の依頼文を渡してください。
ステップ配信が止まっているようなので、次の3点を確認してもらえますか。
1. 対象のシナリオの状態が有効（active）になっているか
2. 次回配信時刻（next_delivery_at）が過去のままになっていないか
3. 定期実行（cron）が実際に動いているか
こちらで分かっているのは次のとおりです。
・止まり始めた時期：
・対象範囲（特定の友だちか、全員か）：
・直前に行った変更：
自動化のルールは、どこまで組んでよいか
自動化は、決まったきっかけに対して決まった処理を実行するルールです。きっかけは7種類（友だち追加、メッセージ受信、タグの変更、スコアの閾値到達、コンバージョン発生、カレンダー予約、外部からの通知）、処理は8種類（タグの付与・削除、シナリオの開始、メッセージ送信、外部URLへの送信、リッチメニューの切り替え・解除、属性値の設定）です。
総当たりの表は作りません。 実務で必要なのは、組んでよいものと相談すべきものの線引きだけです。
- 組んでよい：単発で完結するもの。タグを1つ付ける、シナリオを1つ開始する、といった処理を1回実行して終わり、そこから別のルールが連鎖しないもの。
- 相談する：タグの変更をきっかけに別のルールが起動する連鎖。タグを付ける処理が「タグの変更」というきっかけを発火させるため、ルール同士が数珠つなぎになります。 ドキュメント自身が「無限ループに注意。循環参照する条件を設定しないこと」と警告しています。外部URLへの送信のように、自社の外へ出ていく処理も相談側です。
- 迷ったときの目安：「1回の友だちの行動で、ルールが何回発火するか数えられるか」。 数えられるなら組んでよく、数えられないなら相談してください。
実行の順序は優先度の値で制御でき、値が大きいものほど先に実行されます。 組んだあとは、日次4のチェック（失敗した自動化ログ）で結果を見てください。失敗と部分成功の両方が記録されます。
組み合わせの網羅は、公開OSSリポジトリ（Pathosionのフォーク元）の14-Automation.mdにあります（到達性は2026年7月29日時点で確認済み。この記事の読解スナップショット 5de1a47 以降の更新は反映されていない場合があります）。連鎖を実際に設計するときは開発担当と相談してください。AIを使って運用の反復作業をさらに減らす方法については、AIでさらに運用を効率化する方法を見るへ進んでください。
なお、複数の導線を並行して走らせていると、同じ友だちに似た案内が重なります。この症状の解き方（履歴を表すタグと現在地を表すタグを分ける設計、ボタンの種類による挙動の違い、古いシナリオを抑える送信条件）は前掲の重複配信の記事が担当しているので、この記事では再説明しません。
自分でできること／開発担当に依頼すること：担当一覧とデータ量の管理
ここまでの内容を、担当別に1枚にまとめます。依頼文の実物は各章に1箇所ずつ置いてあるので、この表では場所だけを示します。
| 項目 | 自分 | 開発担当 |
|---|---|---|
| 日次・週次チェック | 日次4項目（日次1〜4）と週次1・2。週次3は管理画面に該当する表示があれば追加で見る | 用途と役割を伝えたうえでのAPIキーの発行（依頼の趣旨はチェックリスト章の「APIで確認するための前提」に記載）。週次3のスコア分布の集計。日次5（未送信の通知）は現在のビルドでは呼び出せるルートがないため、代替手段の要否を確認する |
| BAN検知の通知 | dangerが出たときの一次判断とエスカレーション | 通知経路の構築（依頼文はBANシグナル章の「通知経路は開発担当に依頼する」の節） |
| 複数アカウント | 増やす判断（負荷分散・警告の頻発・用途分離） | 追加アカウントの登録と権限設計（依頼文は複数アカウント章の「追加アカウントはデータベースに入る」の節） |
| 友だち追加の導線 | 導線の棚卸しと /auth/line?ref= への差し替え、LINE内アプリを使う回収施策の計画 | APIでの手動リンクの実行 |
| シナリオが止まったとき | 症状の言語化（いつから／対象範囲／直前の変更） | 進行状態と定期実行の確認（依頼文はシナリオ運用章の「ステップが配信されないとき」の節） |
| データ量とログ | 保持期間と削除対象の妥当性の判断 | バックアップを先に取ったうえでの削除の実行と定期化、使用量の定期報告（依頼文は下の節） |
この表とチェックリストの担当列が食い違った場合は、チェックリストのほうを正としてください。
そしてこの2列に収まらない第3の層があります。通常のエンジニア依頼でも運用担当の判断でもなく、体制と権限の設計そのものを相談する必要がある領域です。BANシグナル章のdangerの行で触れた緊急移行の判断がこれにあたります。中身は最後の章でまとめて扱います。
データを溜めすぎない：定期削除するログ4種と使用量の監視
この節は全体が開発担当への依頼の話です。 ただし、何を残して何を消すかを決めるのは運用側の判断なので、そこだけ分けて書きます。
運用担当が決めること：どのログをどれくらいの期間残すか。ドキュメントが提示している目安は、メッセージのログが90日、スコアの履歴が180日、アカウントの状態ログが30日、自動化のログが60日です。この期間が自社の振り返りサイクルに合っているかは、運用側でないと判断できません。 たとえば四半期で振り返るなら、アカウントの状態ログの30日は短すぎるかもしれません。
開発担当に頼むこと：削除の実行と、その定期化。それと、Cloudflareのデータベース（D1）の使用量の監視です。依頼文は次の2つです。
D1の肥大化対策として、次のテーブルの定期削除を仕組み化してほしいです。
・messages_log（90日超）
・friend_scores（180日超）
・account_health_logs（30日超）
・automation_logs（60日超）
削除前のバックアップ（テーブル単位のエクスポート）を必ず先に入れてほしいです。
リストアはエクスポートしたデータからの手動投入になる想定と聞いています。
削除対象と保持期間の妥当性は運用側で判断するので、案を出してもらえれば確認します。
D1のストレージ使用量を定期的に確認して、上限に近づいたら知らせてほしいです。
上限値は運用ドキュメント内で記述が矛盾している（5GB と 2GB／10GB の2種類が書かれている）ため、
Cloudflareの現行値を確認したうえで閾値を決めてもらえると助かります。
こちらで見に行くのではなく、定期報告かアラートで受け取れる形にしてほしいです。
この記事では、データベースの容量上限を確定値としては書きません。 上記のとおりリポジトリ内のドキュメントで記述が矛盾しており、かつCloudflare側の値は改定されるためです。依頼文に2つの値を並べているのは、上限そのものを伝えるためではなく、記述が食い違っているという事実を開発担当に渡すためです。現行値は必ず公式のドキュメントで確認してください。
詰まったときの原則
症状別の網羅リストは作りません。原則だけ1つです。管理画面と参照系のAPIで見えるところまでは自分で確認し、そこから先（定期実行の実行状態、データベースの中身、Cloudflare側の状態）は開発担当に渡す。 切り分け手順の詳細は、公開OSSリポジトリ（Pathosionのフォーク元）の22-Operations.mdにあります（到達性は2026年7月29日時点で確認済み。この記事の読解スナップショット 5de1a47 以降の更新は反映されていない場合があります）。
記事だけで進められる範囲と、相談したほうがよい範囲
前章の一覧表が「自分」と「開発担当」の2列でした。ここではその外側、記事にも依頼文にも収まらない範囲を明示します。
先に確認しておくと、前章の表で「自分」に割り当てた行のうち、友だち追加導線の棚卸しと差し替え、配信方式の選び分け、自動化ルールの仕分け、BAN耐性3問への回答は、何の準備もなく今日そのまま着手できます。 チェックリストのAPI確認だけは、前述のとおりAPIキーの入手が前提になります。「開発担当」の列も、依頼文をそのまま渡せば依頼として成立します。 詰まるのは、次の3つに当たったときだけです。
-
元の
API_KEYを知っている人が社内に誰もいない場合。 前述のとおり、その人が1人でも残っていれば管理画面の「設定→スタッフ管理」から自分でキーを発行できるので、詰まるのはこのケースに限られます。その場合、チェックリストの日次・週次項目のうち、管理画面に対応する表示があるかどうかを私たちは確認できていません(前述のとおり)。表示があれば代替できますが、なければ日次1(アカウントの状態判定)を含む複数項目がAPIキー前提のまま残ります。 -
複数アカウントの権限設計。 前述のとおり、
owner／admin／staffの役割別キー自体は実装されていますが、それをどう割り当てるかは機能の設定ではなく体制の設計です。誰にどの役割のキーを渡し、どこからのアクセスを許すかを決める必要があります。 - BANが起きたときの緊急移行体制。 リスクレベル対応表のdangerの行が案内している「アカウント移行の開始」は、移行先のアカウントの準備、実行判断の担当、判断の基準が事前に決まっていて初めて成立します。加えて、移行の完了をどう判定するかはドキュメントに記載がありません。 ここは記事の記述だけでは埋まりません。
この3つは、いずれも「壊れたら売上が止まる」領域です。運用の失敗はたいてい機能の理解不足ではなく、この「誰の仕事か」が空欄のまま稼働し続けたことで起きます。 社内で決めきれない場合は、どこで止まっているかを持ち込んでいただければ、そこから整理できます。
まとめ
3行サマリー
- 稼働後にいちばん効くのは、友だち追加URLを /auth/line?ref= に統一することです。 リポジトリのドキュメントは、アカウント移行を共通IDでの自動マッチと説明しており、その共通IDはこの経路を通ったときにだけ自動で付く、と書いています。あとから紐づけ直す経路はありますが、本人の再訪が要るため一括ではできません。
- 毎日見るのは、アカウントの状態と、止まっている配信の2点に絞れます。 ただし danger を検知しても通知が飛ばないおそれがあるため、通知経路の構築は早めに依頼しておいてください。
- 配信は「送信数が取れるか」で選びます。 全員宛は速いが数が取れない、タグ宛は数が残る。予約配信とステップ配信には5分程度のずれが乗る前提で時刻を決めてください。
この記事の検証水準について
この記事の記述は、フォークのリポジトリ内ドキュメントを主な根拠とし、一部を実装コードで照合したものです。実装コードで照合できたのは、次の7点です。
- チェックリストが参照するAPIのルートのうち、日次1〜4・週次1・2、およびあとから紐づけ直す3経路のうち、LINE内アプリのログインとAPIでの手動リンクの2つについては、実際に
index.tsのルート登録にマウントされていて呼び出せることを確認しました。日次5（未送信の通知）が参照していた GET /api/notifications は例外です。ハンドラーファイル自体はリポジトリに残っていますが、index.tsのルート登録には含まれておらず、実際には呼び出せません（404）。 以前の版ではハンドラーファイルが存在することだけを確認して「ルートが実在する」としていましたが、それはルートが実際に呼び出せることの確認にはなっていませんでした。この版で日次5を廃止扱いに修正し、この記述もあわせて是正しています。 - スコアの分布を返す専用のAPIが存在しないこと
- レート制限の既定値
- 通知の設定例に使われている種別が存在しないこと（ドキュメントとの食い違いの1つ目）
- 複数アカウント横断の配信方式が存在すること
- 役割別のAPIキーを発行する仕組みと、権限に応じたシークレットの出し分け
- 外部からのアクセス制限が、許可オリジンをあらかじめ指定する方式であること（ドキュメントが示唆する「全許可」とは食い違っている。これが2つ目の食い違い）
逆に言えば、これ以外はドキュメントの記述が根拠です。 情報利得の中核である移行の仕組みと共通IDの取得条件も、ドキュメントの記述のみを根拠としています。同じドキュメント群に実装との食い違いが2件見つかっている以上（BAN検知の通知設定例、CORSの許可設定）、確定した仕様としては読まないでください。 また、チェックリストのAPIルートについても「ハンドラーファイルが存在すること」と「実際にマウントされ呼び出せること」は別であることが日次5の件で分かったため、この記事では両者を区別して書いています。
数値・エンドポイント・設定値は、運用に入れる前に自社の環境で1度確認することをおすすめします。前述のとおり、この記事が読んでいるのは2026年6月19日時点のコミットで、それ以降に本家側で加えられた変更は追跡していません。 製品の更新は速く、Cloudflare側の上限値も改定されます。
次に読むもの
- まだ構築していない場合：AIでLINE運用するには？公式アカウントの運用基盤を作る手順から始めてください。
- 重複配信を止めたい場合：LINE Harnessで重複配信を防ぐシナリオの作り方で、タグ設計の具体を扱っています。
- 製品の全体像を確認したい場合：本サイトの概要編の記事で、機能の全体像、有料ツールとの違い、「無料」の範囲を整理しています。
- AIで運用を効率化したい場合：本サイトのAI連携編の記事で扱います。