The Harness ／公式情報・ツール比較

LINE Harnessが動かないときの切り分け｜導入・ログイン・Webhook・複数アカウント

· 執筆: The Harness 編集部
THE HARNESS LAB
LINE Harnessが動かないときの切り分け｜導入・ログ…

LINE Harnessのインストール停止、管理画面ログイン、Webhook、友だち未反映、複数アカウント、Cloudflare無料枠を症状別に切り分けます。 完成済みの部分を消さず、診断票から続きの一操作だけを決めます。 Pages、Worker、スタッフ用APIキー、CORSを混ぜずに確認します。 LINE Webhook→署名→アカウント特定→friends→messages_logの順で一件を追います。

この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。

この記事の目次

    最初に確認すること

    • 自分で途中までインストールした・止まった: サポートへ必要情報を安全に渡し、D1や本番データを消さずに続きから再開できる
    • 管理画面URL・APIキー・ログインエラーを直す: ログイン失敗がURL・認証・CORS・古いAdminのどこにあるか判定できる
    • 友だち・メッセージがHarnessに出てこない: 設定を増やさず、受信が途切れた最初の地点を特定できる
    • どの画面で設定するか迷ったとき: リッチメニュー、フォーム、返信、LIFF、画像を作る場所を判断できる
    • 複数アカウントで違うLINEへ飛ぶ: アカウントBのリンクがアカウントAへ飛ぶ原因を、勘ではなく設定の鎖で特定できる
    • 0円の範囲・配信通数・Cron・R2を確認する: 無料だと思って配信停止や請求事故を起こさず、現在の利用量を確認できる
    • AIへ渡すだけで原因を切り分ける: 自力で直せない問題も、秘密情報を漏らさず再現可能な報告へ変えられる

    自分で途中までインストールした・止まった

    完成済みの部分を消さず、診断票から続きの一操作だけを決めます。

    この工程のゴール: サポートへ必要情報を安全に渡し、D1や本番データを消さずに続きから再開できる

    途中まで自分で進めた状態でもサポート対象です。最初からやり直す必要はありません。まず、Cloudflareに何が作成済みかと、最初に失敗した工程をread-onlyで確認します。サポート側も、いきなり削除や再インストールを案内せず『次の一操作』だけを返します。

    @latestは『公開されている最新のセットアップCLIを使う』という指定です。LINE Harnessのセットアップは.line-harness-setup.jsonへ完了済み工程を記録するため、通常は同じnpx create-line-harness@latestを再実行すると続きから再開します。エラーのたびにCloudflareのWorker、D1、Pagesを手で消してはいけません。

    WorkerとD1は更新済みなのにAdmin UIだけ失敗した場合、現行CLIにはnpx create-line-harness@latest update --repair-adminがあります。Adminだけを再デプロイし、D1 migrationやWorker本体をやり直しません。

    WindowsではPowerShellにMac用コマンドを貼らず、WSL2のUbuntu内で作業します。IG HarnessでNEXT_PUBLIC_API_URL is not setなどの古い初期ビルドエラーが出た場合も、まず最新版CLIと現行deploy-admin.tsを確認し、環境変数を思いつきで追加しません。

    サポートへ送るのは、製品、OS、管理画面/Workerのhostname、実行コマンド、最初のエラー、完了したと思う工程だけです。APIキー、token、secret、.line-harness-config.jsonや.ig-harness-deployed.jsonの全文は送りません。スクリーンショットにも秘密値が写っていないか確認します。

    手順

    1. サポート用診断票を作る

    製品・OS・URLのhostname・実行コマンド・最初のエラー・完了済み工程を一枚にまとめます。

    2. 壊さず現状確認

    Node、Git、Wranglerログイン先、setup state、D1/R2/Worker/Pagesを値を伏せて確認します。

    3. 再開方法を選ぶ

    通常再開、Adminだけ修復、公式update、古いsourceの引き継ぎ、fork/custom更新、認証違いのどれか一つに分類します。

    4. 一工程だけ再実行

    同じ失敗を再現し、最初に失敗した工程だけを直します。

    5. URLとバージョンを照合

    Worker、Pages、D1、管理画面の表示バージョンが同じ環境を指すか確認します。

    完了条件

    • 秘密値なしのサポート診断票ができる
    • 既存D1・R2・Worker・Pagesを削除していない
    • 一つの再開経路と次の一操作が決まる
    • 管理画面とWorkerの組合せ・versionを確認

    注意: 『最初から』を選ぶ前に、既存D1へ顧客データがないことを必ず確認します。Cloudflare Dashboardで手当たり次第に削除しません。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-1

    管理画面URL・APIキー・ログインエラーを直す

    Pages、Worker、スタッフ用APIキー、CORSを混ぜずに確認します。

    この工程のゴール: ログイン失敗がURL・認証・CORS・古いAdminのどこにあるか判定できる

    管理画面URLはCloudflare Pages、APIはWorkerです。見た目が開いても、Adminが別のWorker URLを向いていればログインや一覧取得は失敗します。ブラウザに表示されたAPIキー入力欄は、学習サイトのメール・パスワードログインとは別物です。

    APIキーは所有者の共通キーを全員へ渡さず、Harnessのスタッフ管理で一人ずつ発行します。Cloudflare Secretは登録後に値を読み返せないため、Dashboardで空欄に見えても消えたとは限りません。値をチャットへ貼らず、登録有無と認証結果で確認します。

    CORSエラーはWorkerのADMIN_ORIGINと実際に開いた管理画面originが違うと発生します。pages.dev、独自ドメイン、Preview URLを混ぜず、使う本番originを一つ決めます。

    手順

    1. 3点を固定

    管理画面URL、Worker URL、Cloudflare account IDを一行ずつ記録します。

    2. Adminの接続先を確認

    デプロイ済みAdminがどのWorker URLを参照しているか確認します。

    3. 認証とCORSを分離

    401/403ならキー・権限、ブラウザCORSならADMIN_ORIGIN、404/5xxならAPI/deployを調べます。

    4. 個人キーで再確認

    自分専用staffを作り、シークレット入力後に一覧取得だけを試します。

    完了条件

    • PagesとWorkerのURLを別々に特定
    • 401/403とCORSを分けて判定
    • 個人別staff keyを使用
    • credentialを出力していない

    注意: APIキーをLINEグループ、Chatwork、GitHub Issue、AIチャットへ貼りません。漏えいが疑われる場合は原因調査より先に失効・再発行します。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-2

    友だち・メッセージがHarnessに出てこない

    LINE Webhook→署名→アカウント特定→friends→messages_logの順で一件を追います。

    この工程のゴール: 設定を増やさず、受信が途切れた最初の地点を特定できる

    HarnessはLINEからWebhookを受信して友だちと会話を記録します。現行実装はfollowだけでなく、署名済みのメッセージやpostbackでも未登録の友だちを補完します。ただし、Harness接続前から存在し、その後一度も反応していない友だち全員を完全なUID付きで自動復元できるわけではありません。

    LINE Developersの『Webhookの利用』と、LINE Official Account Managerの応答メッセージ／あいさつメッセージは別設定です。Harnessで返信やシナリオを管理するなら、二重返信を避けるため公式側の自動応答を止め、Webhookを有効にします。

    公式LINEの管理画面から直接送った返信は、Harnessが送信したものではないためHarnessの送信ログと一致しないことがあります。運用履歴を一か所に残したい場合はHarnessの個別チャット、または接続済みAIから返信します。

    手順

    1. 検証人物を一人決める

    自分のLINEから固有の短いテスト文を一回だけ送ります。

    2. Webhook到達を見る

    対象Workerのログで時刻、event type、HTTP status、署名判定を確認します。

    3. DBの2地点を確認

    friendsの対象accountとmessages_logのincoming一件を個人情報を伏せて照合します。

    4. 画面と返信を確認

    友だち管理、個別チャット、未対応に表示され、自分へ一回だけ返信できるか確認します。

    完了条件

    • WebhookからDBまで時系列で確認
    • 検証人物一人だけを使用
    • 既存友だちの取得限界を理解
    • 公式LINEとHarnessの送信履歴を混同しない

    注意: ログを共有するときは表示名、本文、完全UID、署名、tokenを伏せます。Webhook署名検証を無効化して直したことにしません。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-3

    どの画面で設定するか迷ったとき

    LINE Developers、公式アカウント、Harness、Cloudflare、Codexの担当を固定します。

    この工程のゴール: リッチメニュー、フォーム、返信、LIFF、画像を作る場所を判断できる

    日常業務はHarnessかCodexで行います。LINE DevelopersはChannel、Webhook、LINE Login、LIFFの初期接続、LINE Official Account Managerは料金プラン・権限・応答設定、CloudflareはWorker/D1/R2/Domain/Secret/Logを担当します。

    リッチメニューの実体はLINE Platformにありますが、作成・画像アップロード・デフォルト設定はHarnessから操作できます。テンプレート、シナリオ、フォーム、予約、タグ、個別チャットはHarnessです。画像はHarness経由でR2へ保存し、Flex JSONを毎回手作業で貼らない運用にできます。

    スマホでも管理画面の閲覧や軽い確認はできますが、初期導入、複数アカウント設定、エラー復旧、差分レビューはPCでCodex／Claude Codeへ任せるのが基本です。

    手順

    1. やりたいことを一文にする

    例：リッチメニューの相談ボタンから予約フォームを開きたい、と成果で書きます。

    2. 担当を分解

    入口、画面、データ、配信、外部設定を5つの担当先へ割り当てます。

    3. Harness内で下書き

    対象アカウントを固定し、テンプレートやシナリオを停止状態で作ります。

    4. 自分で一動線を確認

    リッチメニュータップからフォーム、タグ、返信、予約まで一人で通します。

    完了条件

    • 5つの担当先を混同しない
    • 既存設定を先に確認
    • 停止状態で下書き
    • 自分一人で一動線を検証

    注意: 『公式LINEで作るかHarnessで作るか』を機能名だけで決めず、履歴・計測・自動化をHarnessへ残したいかで判断します。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-4

    複数アカウントで違うLINEへ飛ぶ

    リファラルリンク、所有アカウント、Pool、LIFF ID、Endpoint URLを順番に確認します。

    この工程のゴール: アカウントBのリンクがアカウントAへ飛ぶ原因を、勘ではなく設定の鎖で特定できる

    複数アカウントでは、LINE公式アカウント、Messaging API Channel、LINE Login Channel、LIFF ID、LIFF Endpoint URLが一組です。一つでもアカウントAの値が残ると、B用のリンクでもAの同意画面や友だち追加へ進みます。

    現行L Harnessのトラックリンクは、リンク所有アカウント→紐づくシナリオのアカウント→環境の既定LIFFの順に解決します。Poolを使う/r/では、指定Poolと有効な所属アカウントを確認します。更新前の環境にはアカウント別LIFF修正が入っていない場合があるため、まずversionとrelease notesを確認します。

    main Poolは安全な既定値ですが、用途別Poolの指定漏れを見えにくくすることがあります。新しいリンクを一つだけ作り、PCのQRとスマホの両方で検証します。

    手順

    1. 対応表を作る

    アカウント名、Channel ID末尾、Login Channel、LIFF ID末尾、Endpoint、Poolを一行にします。

    2. リンク所有者を確認

    対象リンクのline_account_id、scenario、entry route、Pool指定を照合します。

    3. LIFFを確認

    対象LIFFのEndpoint URLが現在のWorker URLで、該当LINE公式アカウントへリンク済みか確認します。

    4. 新規リンクで再試験

    キャッシュや古い配布URLを避け、自分のスマホでBへ到達するか確認します。

    完了条件

    • Channel・Login・LIFF・Endpointを一組で照合
    • リンク所有accountとPoolを確認
    • main fallbackを認識
    • 新規リンクで期待アカウントへ到達

    注意: 本番で配布済みのリンクを先に削除・無効化しません。古いQRやSNS投稿への影響を確認してから切り替えます。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-5

    0円の範囲・配信通数・Cron・R2を確認する

    Harness本体、LINEの送信枠、Cloudflareの実行枠、R2契約を別々に管理します。

    この工程のゴール: 無料だと思って配信停止や請求事故を起こさず、現在の利用量を確認できる

    Harnessがオープンソースでも、LINE公式アカウントとCloudflareの利用条件は別です。2026年8月2日時点の日本向けLINE公式例では、無料プランは月200通、ライトは5,000通、スタンダードは30,000通です。通数は吹き出し数ではなく、基本的に送信リクエスト数×送信対象人数で数えます。Harnessを使ってもこの上限は回避できません。

    Cloudflare Workers Freeは1日100,000 request、Cron Triggerは1 accountあたり5個です。Harnessの定期処理を増やすたびにCronを増設せず、一つのCronから期限到来ジョブを処理する設計を優先します。

    R2には無料利用枠がありますが、利用開始にはR2 subscriptionのcheckoutが必要です。画像アップロードが失敗したときはコードだけでなく、subscription、bucket、binding、公開方法を確認します。料金・上限は変わるため、教材の数字より各公式ページと自分のDashboardを優先します。

    手順

    1. 4つを別会計にする

    Harness、LINE、Cloudflare Workers/D1、R2/外部APIを分けて記録します。

    2. 現在量を取得

    LINE通数、Workers request、D1 rows、R2 storage、Cron数をread-onlyで確認します。

    3. 上限時の挙動を決める

    送信停止、429/1027、画像保存失敗時の通知先と手動復旧を決めます。

    4. 月次点検を固定

    毎月1日に利用量、plan、payment、異常増加を確認します。

    完了条件

    • LINEとCloudflareの枠を分離
    • 現在量と上限を公式情報で比較
    • R2 subscriptionとbindingを確認
    • 上限時の通知・停止方法を決定

    注意: 料金と上限は変更されます。このガイドの数字は2026年8月2日時点の目安で、実行時は公式ページと契約画面を再確認します。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-6

    AIへ渡すだけで原因を切り分ける

    スクリーンショット一枚ではなく、再現条件と最初のエラーをAIへ安全に渡します。

    この工程のゴール: 自力で直せない問題も、秘密情報を漏らさず再現可能な報告へ変えられる

    『動きません』だけでは、AIもサポート側も原因を絞れません。一方で、APIキーや長いログ全文を貼る必要もありません。製品、OS、version、実行コマンド、期待、実際、最初のエラー、再現手順、影響範囲があれば十分です。

    まずCodex／Claude Codeにローカルのリポジトリ、Cloudflareのread-only情報、対象時刻のログを読ませます。同じ問題の調査中は同じチャットを使い、別顧客・別Harness・別目的に変わるときは新しいチャットとフォルダへ分けます。

    現行コードでは、トラックリンクに明示したシナリオは再訪時も最初の即時stepを再送できます。一方、タグ追加は初回だけです。またrich menuのpostbackは自動返信とログ記録には使えますが、現行webhook.tsではpostback分岐からIF–THENのfireEvent()を呼んでいません。要望と不具合を混ぜず、追加開発として切り出します。

    手順

    1. 事実を8項目へ整理

    製品、環境、version、操作、期待、実際、最初のエラー、再現回数を書きます。

    2. AIがread-only診断

    コード、設定名、ログ、DB件数を読み、最初に途切れた層を出します。

    3. 仕様か不具合か判定

    現在の実装、公式仕様、期待を比較し、設定・既知制約・bug・追加要望に分けます。

    4. 再現可能な質問へ変換

    直らない場合だけ、秘密情報を除いた最小再現と根拠ファイルをIssue／サポートへ渡します。

    完了条件

    • 最初に失敗した地点を特定
    • 仕様・bug・追加要望を分類
    • 秘密情報なしの最小再現
    • 次の一操作が一つに絞られる

    注意: 公開Issueやオープンチャットへログ全文を貼る前に、APIキー、token、署名、メール、電話、完全UID、顧客メッセージを除去します。

    Academy教材: 困ったときの症状別FAQ / Lesson 15-7

    公式ソース

    関連ガイド

    Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。