LINE Harnessとは（30秒で分かる定義）
「LINE公式アカウントのCRMを、自分のインフラで動かす」という選択肢
LINE Harnessは、LINE公式アカウント向けのオープンソースのCRM／マーケティングオートメーションツールです。ステップ配信、友だち管理、タグ、リッチメニュー、フォーム、自動応答といった、有料のLINE運用ツールで提供されている領域を扱います。
決定的に違うのは、提供形態です。有料ツールは事業者が用意したサービスにログインして使いますが、LINE Harnessはコードが公開されていて、自社が契約したインフラの上に自分で設置して動かします。技術構成はTypeScriptで、サーバー側はCloudflare Workers、データベースはCloudflare D1、管理画面はNext.jsで作られています。LINE内でWebページを開くLIFFの機能もサーバー側に統合されています。
この「自分のインフラで動かす」形式をセルフホストと呼びます。ここから先の話は、ほぼすべてこの一点から派生します。費用の内訳も、責任の所在も、必要な人材も、セルフホストであることの帰結です。
なお日本語では「LINEハーネス」とカタカナで書かれることもありますが、リポジトリやドキュメントでの表記はアルファベットのLINE Harnessです（検索するときは、犬用ハーネスや自動車のワイヤーハーネスなど同名の別カテゴリ製品と表記が衝突することがあるため、「LINE Harness OSS」のように語を足すと絞り込みやすくなります）。
誰が作っていて、ライセンスはどうなっているか
LINE Harnessは、GitHub上で Shudesu/line-harness-oss として公開されているプロジェクトです。ライセンスについては、READMEとドキュメントのトップページでMITライセンスと明記され、商用利用・改変・再配布が可能とされています。ひとつだけ補足すると、リポジトリの直下にライセンスファイル自体は置かれていません。MITという表記はドキュメント上の表明であり、ファイルとして発行されたライセンスを確認したものではない、という点は導入判断の材料として知っておいてよいところです。社内の法務確認が必要な組織では、この点を先に確認しておくと後戻りが減ります。
この記事を書いているPathosionの立場も明確にしておきます。私たちはこのプロジェクトのフォークを保持し、自社用の変更をプルリクエスト経由で入れ、Cloudflareへのデプロイと本体側の更新取り込みを行う仕組みを備えています。一方で、稼働中の本番環境における実測コスト、実際に発生したトラブル、独自のセキュリティ運用については、この記事の執筆時点で検証できていません。したがってこの記事は「運用実績のレポート」ではなく、フォークを保持し、公式ドキュメントと実装コードを読み解いた立場からの整理です。金額や体験談として書けないことは、書きません。
この記事で決められること／決められないこと（読み進む前の道案内）
この記事で判断できるのは「自社が導入すべきかどうか」までです。判断材料は、この記事の最後にある導入可否チェックリストに集約されています。
金額については、無料枠の上限やLINEの配信単価といった数値そのものは扱いません。この種の数値は改定されるため、記事に固定値を書くと更新の遅れがそのまま読者の誤判断になります。判断に必要な考え方を示したうえで、実際の数値は公式の現行ページで確認してもらう形にしています。
すでに自分でサーバーの用意やデプロイを進められる方には、先に近道を示しておきます。定義や全体像を読み飛ばして、構成と要件の詳細から入りたい場合はOSS構成とセルフホストの要件・手順へ進んでください。この近道は末尾の導入可否チェックリストを置き換えるものではないので、判断に迷ったら記事の最後まで戻ってきてください。
何ができるのか：機能の全体像
ここでは「自社の業務のどれが置き換わるか」という視点で、機能の全体像を押さえます。個々の操作手順はこの記事では扱いません。
配信：いま有料ツールで送っている配信が、そのまま置き換わるか
シナリオに沿って順番に送るステップ配信、全体または条件に合う人へ送る一斉配信、日時を指定するリマインダー、繰り返し使うテンプレート、クリックを計測できるトラッキングリンクが揃っています。これらの配信処理は5分ごとに動く定期実行の仕組みがまとめて担当します。ステップ配信・予約配信・リマインダー配信に加えて、アカウントの状態チェックや、途中で止まった配信の復旧なども同じ仕組みの中で動きます。
複数の導線を並行して走らせると、同じ人に似た案内が重なる「重複配信」が起きやすくなります。この設計を先に押さえておきたい場合は、LINE Harnessで重複配信を防ぐシナリオの作り方で、履歴タグと現在地タグを分ける具体的な組み方を解説しています。
顧客管理：友だちの情報がどう溜まり、どう絞り込めるか
友だちはWebhook（LINEからの通知）を受け取った時点で自動登録され、タグ付け、条件によるセグメント抽出、スコアリング、重複検出、オペレーターによる1対1チャットが行えます。この「Webhookを受け取った時点で登録される」という挙動は、有料ツールからの乗り換えを考えている場合に効いてくるので、後の乗り換えの節でもう一度触れます。
接客まわり：リッチメニュー・フォーム・予約をどこまで賄えるか
タグに応じたリッチメニューの出し分け、LINE内で開くフォーム、カレンダーからの予約受付、スタッフの管理といった、接客側の機能も含まれています。予約まで含まれているのは、店舗や施術系のEC・D2Cにとっては検討材料になります。
自動化と複数アカウント：手作業とアカウント停止リスクをどこまで減らせるか
「この条件を満たしたらこの処理をする」という形の自動化ルール、キーワードに反応する自動応答、外部システムとの双方向のWebhook連携があります。
マルチアカウント関連では、複数のLINE公式アカウントをまとめて管理でき、アカウントの状態を3段階（正常・警告・危険）で判定して、危険と判定されたアカウントからの切り替えを検討できる仕組みがあります。設計上は、アカウントをまたいで同一人物を識別するIDを持つことで、アカウントを移しても友だち・タグ・シナリオの進行状況を引き継げる形になっています。ただしこれはリポジトリのドキュメントに書かれた設計であり、実際にこの自動マッチ処理を実装コード側で確認したものではありません。
なお「ステルス配信」という機能名が出てきますが、これは規約回避のための仕組みではありません。実装コードを確認すると、送信間隔の調整や配信時刻・本文表現へのばらつきを組み合わせた仕組みで、目的は「LINE側のレート制限を守ること」と「見た目・タイミングを自然にして不審なパターンを避けること」の両方にまたがり、どちらか一方だけに単純に切り分けられるわけではありません。「規約に沿った制御だから安全」と一括りにせず、レート遵守と自然さの両方を意識した設計だと理解してください。
複数アカウントの運用とアカウント切り替えの実務は、この記事の範囲を超えるため、複数アカウント運用とBAN対策の実務手順で扱います。
API連携とAI：管理画面の外からも同じ操作ができる設計
LINE Harnessは「API-first」という設計思想を掲げています。機能をまず外部から呼び出せる形（API）で用意し、管理画面はその外部呼び出しを使って動く画面のひとつという位置づけにする、という考え方です。あわせて、Claude CodeのようなAIツールから操作するための仕組み（MCP Server）も同梱されています。
ドキュメントがこの設計思想を表明していることは確認できましたが、すべての機能が漏れなくAPIとして公開されていることを実装レベルで検証したわけではありません（後述するように、ドキュメントに載っていて実装が見つからない機能も実際にありました）。ですので「すべての機能がAPIで操作できる」ではなく「APIを起点にする設計を取っている」と理解してください。
またAI連携についても、書き込みを伴う操作（メッセージ送信など）はユーザーの確認を前提とする設計になっています。AIが勝手に配信することはない代わりに、AIに任せきりにもできません。Claude CodeやMCPから具体的に何ができるかは、次の節でエンジニアの要否を押さえたあとで、この章の最後に案内します。
エンジニアがいなくても運用できるのか：管理画面でできることと、できないことの境界
専任のエンジニアがいない事業者にとって、ここがいちばん知りたいところだと思います。「APIが中心の設計」と聞くと、日々の運用にもコードが必要そうに見えるからです。
実装コードを読んで確認した範囲では、そうではありませんでした。管理画面アプリが使っている通信部分のコードには、日々の運用でデータを作成・更新・削除するための呼び出しがひととおり出そろっています。業務の言葉に置き換えると、次のようなことが管理画面から行える実装になっています。
- 配信の作成、テスト送信、条件を絞った送信、実際の送信実行
- シナリオの作成、ステップの追加と並べ替え
- 自動応答ルールの作成と編集
- リマインダーの設定
- リッチメニューの作成、公開、タグへの適用
- テンプレートの作成
- タグの作成と、友だちへのタグ付け
- 1対1チャットでの返信
- スタッフの追加とアクセスキーの再発行
- スコアリング、自動化ルール、予約とイベント、流入経路、成果計測、通知ルール、外部連携の設定
- 画像のアップロード
リッチメニューを画面上で配置するエディタや、自動応答を編集するダイアログといった編集用の部品も実際に存在します。
ただし、ここは限定つきで受け取ってください。確認したのは「管理画面のアプリがこれらの書き込み操作を行う実装になっている」ところまでで、実際に管理画面を立ち上げて一つずつ動かして確かめたわけではありません。 「操作できる実装になっている」と「操作した」は別のことなので、後者としては書きません。
一方で、エンジニア（またはコマンドライン操作ができる人）が必要になるのは、日々の運用ではなく立ち上げとインフラの保守に集中します。
| 担当領域 | 具体的な作業 | 誰が担うか |
|---|---|---|
| 日々の運用 | 配信、シナリオ、自動応答、タグ、リッチメニュー、チャット対応 | 管理画面から運用担当者が行える実装 |
| 立ち上げ | セットアップコマンドの実行、データベースの作成と初期設定、各種キーの登録、初回のデプロイ | コマンドライン操作ができる人 |
| インフラの保守 | デプロイのたびの設定管理、データベースのバックアップ確認、本体側の更新の反映（標準構成かカスタムビルドかで手順が変わります。詳しくは後述の「継続性リスク」で説明します） | 同上 |
この境界が、そのまま導入可否の判断材料になります。日々の運用を回す人と、立ち上げ・インフラを担う人は、別の人でかまいません。 後者が社内外に1人確保できるかどうかが分かれ目です。
AI（Claude CodeやMCP連携）は、この境界のどちら側にも必須ではありません。同じAPIを別の入口から叩く手段が増える、という位置づけです。「AIを使わないと運用できない」というものでもなければ、「AIに運用のすべてを委ねられる」というものでもありません。
そのうえで、この「上乗せの選択肢」で具体的に何が増えるのかを先に見ておきたい場合は、Claude Code・MCP連携でできることで扱います。
有料ツールとの違いを「比較軸」で理解する
機能差より先に理解すべき「責任範囲の差」
有料ツールとの比較というと機能表の突き合わせになりがちですが、先に押さえるべきは責任範囲です。ここを理解しないまま機能だけで比べると、導入後に想定していなかった作業が発生します。
| 項目 | セルフホスト（LINE Harness） | ベンダー契約型の有料ツール |
|---|---|---|
| 動かす場所 | 自社が契約したインフラ | 提供事業者のサービス |
| 鍵・認証情報の保管 | 自社の責任 | 提供事業者側で管理される範囲は契約内容による |
| バックアップ | Cloudflareが自動保持（無料枠7日／Paid30日）＋任意で手動エクスポート | 提供内容による |
| アップデートの適用 | 自社が取り込みを判断して反映する | 提供事業者側で適用されるのが一般的だが、範囲と時期は提供内容による |
| 障害時の一次対応 | 自社（またはデプロイ担当者） | 契約内容による |
| ソースコード | 公開されており、改変・再配布できる（ドキュメント上MIT表記） | 公開されないのが一般的 |
右列を「契約により異なる」と書いているのは、ごまかしではありません。この記事の根拠はLINE Harness側のリポジトリと、そこから参照されるインフラ側の公式ドキュメント（Cloudflareのバックアップ保持期間など）に限られており、他社の契約条件を検証したものではないからです。「有料だからサポートがある」と一括りにせず、検討中の有料ツールのサポート範囲・応答条件・設定代行の有無は、各社の公式情報で確認してください。
この表の左列、つまりセルフホストで自社に来る作業が、そのまま導入後の定常業務になります。具体的に何をやることになるかは、後半の「安全性と責任範囲」で作業単位に落とします。
方式の違いとして確認できる特徴
方式の違いとして自明に言えるのは、ソースコードが公開されていて自社のインフラで動かせる、という点です。ここは有料のSaaSと構造的に異なります。
その他に、この記事が根拠を持って挙げられるのは次の3点です。いずれも「他社にはない」という話ではなく、「LINE Harness側にはこうある」という話として読んでください。競合各社の機能有無を裏づける一次情報を持っていないためです。
- APIを起点にする設計を取っていること（前述のとおり、実装網羅性の検証済みという意味ではありません）
- アカウントをまたいで同一人物を識別するIDを持ち、アカウント移行時に引き継げる設計になっていること（リポジトリのドキュメントに書かれた設計であり、実装コードでの確認はしていません）
- 「通常のLINE公式アカウント運用に見えるようにする」という原則のもと、レート制御と文面のばらつき付与が組み込まれていること
いま使っている有料ツールから乗り換えられるのか（引き継げるもの・引き継げないもの）
「月額を払っているツールをやめて置き換えた」という趣旨の記事は検索結果の上位に複数あります。読者としていちばん気になるのは「乗り換えは実際どこまでできるのか」でしょう。リポジトリで確認できた範囲に限って整理します。
引き継げるもの：LINE公式アカウントそのものと、友だち。 乗り換えでLINE公式アカウントを作り直すわけではないので、LINE上の友だち関係は失われません。切り替え作業の実体は、Messaging APIチャネルの通知先（Webhook URL）を、LINE HarnessのサーバーのURLに向け直すことです。
引き継げないもの、というより「最初は空になるもの」：LINE Harness側のデータベース。 LINE Harness側は空のデータベースから始まります。友だちのレコードは、そのユーザーから最初の通知が届いたときにプロフィールを取得して登録される実装です。この「最初の通知」は友だち追加のイベントだけではなく、ボタンのタップやメッセージの送信でも同様に登録されます。つまり既存の友だちは、次にそのユーザーが何らかのアクションを起こした時点から順次データベースに載っていくことになります。既存の友だちのIDを一括で取得する仕組みは、リポジトリには見当たりませんでした。
この「LINE上の友だち数」と「手元のデータベースに載っている人数」のずれは、製品側も認識しています。LINE公式のフォロワー統計（フォロワー数、到達可能数、ブロック数）を取得して手元の状態と突き合わせるためのAPIが実装されています。ただしこれで取れるのは集計値だけで、個人単位のIDは取得できません。ずれの大きさは把握できますが、ずれを解消することはできない、という設計です。
引き継げないもの：タグ、シナリオの進行状況、顧客ごとのメモ。 ここが乗り換え検討でいちばん重い部分です。設計文書と競合機能の比較メモにはCSVの取り込み・書き出しがカバー済みとして記載されているのですが、APIリファレンスに該当する項目がなく、実装コードにもCSV処理が見つかりませんでした。ドキュメント上の宣言と実装が食い違っている状態です。したがってタグやシナリオは手作業で作り直す前提で見積もってください。
この結論は、こう確かめました。 製品の公開されている設計資料と、公開されているプログラム本体の両方を突き合わせて、有料ツールから顧客データを取り込む仕組みが実際に用意されているかを探しました。分かったのは、設計資料の機能一覧にはCSVでの取り込み・書き出しが「対応済み」として載っているものの、実際に動くプログラムの側にも、外部向けの操作一覧の側にも、それに当たるものが見つからなかったということです。この食い違い自体が、ここでの結論の根拠です。「乗り換えは簡単」という検索結果上位の論調とは逆の結論なので、自分でも確かめてください。 ただし確認先はひとつではなく、2つに分けて聞く必要があります。ひとつはいま契約している有料ツール側の担当者に、「タグ・セグメントと配信シナリオの進行状況を、他のツールに持ち出せる形（ファイルとして書き出すなど）で取り出せますか」。もうひとつはLINE Harnessの構築を任せる予定のエンジニアまたはベンダーに、「取り出したそのデータをLINE Harness側に取り込む方法はありますか。あるとすれば個別の開発が必要になりますか」。ここで確認できていないのは後者、つまりLINE Harness側に取り込む仕組みのほうです。したがって前者だけが「はい」でも、この記事の結論は変わりません。 取り出せることと取り込めることは、別の問題です。なお、この結論は（1）本体側で取り込み機能が実装される、（2）公式の移行手順が文書化される、（3）本記事が確認していない経路（外部のツールや個別の開発）で移行できることが確認される、のいずれかが起きれば変わります。確認したのは2026年7月26日から29日にかけてです。
そして、断定できないことも書いておきます。
- 既存の有料ツールとの並行運用ができるかどうかは、確認できていません。 LINEの公式ドキュメントによれば、Messaging APIチャネルに設定できるWebhookの送信先は1つだけです。ここから、構造上は同じチャネルでの同時併用は難しいと読めます。ただしこの先の「実際に同時併用したらどうなるか」についてはLINE Harnessのリポジトリ自身がこの点に触れていないため、断定はしません。
- 公式に定義された移行手順は存在しません。 マニュアル類には「既存のサービスから移行してきた人」が想定読者として挙げられている箇所がありますが、そのファイル自体が本文未執筆のプレースホルダーでした。
ひとつ混同しやすい点を補足します。LINE Harnessには「アカウント移行」という機能がありますが、これはアカウントが利用できなくなった際にLINE公式アカウント間で友だちを引き継ぐための内部機能であり、他社ツールからの移行機能ではありません。
「月0円」の正確な意味：コスト構造を分解する
「月0円」という言い方は間違いではありませんが、指しているのはサーバー費用だけです。実際の運用コストは3層に分かれます。
第1層：サーバー費用（ここは0円になり得る）
Cloudflareの無料枠に収まっていれば、サーバー側の費用は0円になり得ます。ここは事実です。
ただし本記事では、無料枠の具体的な上限値や有料プランの金額を書きません。リポジトリ内のドキュメントにも数値の記載はあるのですが、ファイルによって値が食い違っており、かつこの種の数値は改定されます。記事に固定値を書くと、記事の更新遅れがそのまま読者の誤判断になります。現行の上限と金額は、Cloudflare Workersの料金ページとCloudflare D1の料金ページで確認してください。
第2層：LINE公式アカウントの配信料金（ここは0円にならない）
ここが0円になりません。LINE Harnessを使っても、LINE公式アカウントのメッセージ配信料金はLINEヤフーとの契約に基づいて発生します。無料で送れる通数を超えると、料金プランに応じた費用がかかります。
こちらも通数や単価は記事に書きません。現行の料金プランはLINE公式アカウントの料金プランのページで確認してください。
つまり「LINE Harnessは無料」という表現が成立するのは、ツールのライセンス費用とサーバー費用についてであって、LINE運用全体の費用ではありません。有料ツールから乗り換えたときに消えるのはツールの月額であり、配信料金は残ります。
第3層：見落とされる運用工数（金額に表れない）
金額に表れない3つ目のコストが工数です。セルフホストである以上、次の作業は自社に残ります。
| 作業 | 頻度の目安 | 内容 |
|---|---|---|
| デプロイ | 更新のたび | コードの変更を反映する |
| 監視 | 日次・週次 | 配信の状況、アカウントの状態、エラーを確認する |
| バックアップ確認 | 契約プラン確認時に1回 | Cloudflareの自動保持期間（無料枠7日／Paid30日）で足りるかを確認し、必要なら手動エクスポートを追加する |
| 更新の追従 | 本体側の更新のたび | 標準構成なら、初回の更新用キー登録を済ませたうえで管理画面のボタン操作。独自改造ありなら取り込みの提案を確認し反映するかを判断する |
日次・週次で何を見るかは、ドキュメント側に監視項目として定義されています。ここに何時間かかるかは検証できていないため、数値化はしません。ただし**「0円」の裏側にこの列があることは、判断の前に知っておいてください。**
導入・デプロイの手順（全体像だけ）
この記事では手順の詳細には踏み込みません。全体像だけを押さえて、詳細は別記事に渡します。
必要なアカウントと環境
| 必要なもの | 補足 |
|---|---|
| Cloudflareのアカウント | サーバーとデータベースを動かす場所 |
| LINE公式アカウントとMessaging APIチャネル | 配信の入口 |
| LINE Loginチャネル | 必須。理由は次の節で説明します |
| Node.jsとpnpmが動く環境 | 必要バージョンはドキュメント間で20以上・22以上と記載が分かれているため、導入時にリポジトリのREADMEで最新の記載を確認してください |
| Cloudflare操作用のコマンドラインツール | デプロイと設定に使います |
全体の流れを1画面で
セットアップ用のコマンドが用意されていて、次の作業をまとめて代行します。
- Cloudflareの認証
- データベースの作成と初期設定の適用
- 各種キーや設定値の登録
- サーバーと管理画面のデプロイ
- LINEの認証情報の登録
- 最初のAPIキーの発行
LINE内で開くアプリ（LIFF）は自動作成ではありません。 実装コードを確認すると、コマンドはLIFFアプリの作成手順をその場で案内し、読者がLINE Developersコンソールで自分の手で作成してIDを貼り付ける形になっています。また「最初の管理者ユーザーの作成」も、実際にはAPIキーの発行であり、氏名やメールを持つユーザーアカウントが作られるわけではありません。後述する「継続性リスク」の節で触れる、管理画面の更新ボタンを動かすためのキーも、このコマンドの対象外です。READMEはこの一連の流れを短時間で終わるものとして案内していますが、所要時間は検証していないため、そのまま鵜呑みにはしないでください。
実際に手を動かす段階では、LINE Developers側の設定、Cloudflare側の設定、それぞれの画面で何をどこに入れるかという具体が必要になります。この部分はAIでLINE運用するには？公式アカウントの運用基盤を作る手順で、似た名前のURLの役割の違いや公開前チェックリストまで含めて解説しています。OSSとしての構成やセルフホストの要件をより深く確認したい場合は、OSS構成とセルフホストの要件・手順で扱います。
導入の全体像が見えたところで、Claude CodeやMCP連携を使ってこの基盤の操作をどこまで任せられるのかに関心が向いた方は、Claude Code/MCP連携で何ができるかを見るへ進んでください。
導入前に知っておくべきつまずきポイント
ここで挙げるのは、いずれも公式ドキュメント側が注意喚起している内容です。私たち自身が踏んだ事例としては書きません。共通しているのは、エラーが表に出ないまま失敗するタイプの問題が含まれていることです。
読み方の枠組みをひとつ提案します。この節は「導入作業を担当する人が知っておくべき落とし穴」の一覧です。裏返すと、これを読んで「担当できる人が思い当たらない」と感じたら、それ自体が導入可否の判断材料になります。
LINE側の設定はひとつでは足りない（ログイン用の設定も必須）
LINE公式アカウントの配信用の設定（Messaging APIチャネル）を用意すれば動く、と思って進めると詰まります。ログイン用の設定（LINE Loginチャネル）も必須です。
理由は、LINE Harnessの中核が「同一人物を一貫して識別すること」に依存しているからです。友だちを識別するIDの自動取得、どこから流入したかの追跡、広告のクリック情報の記録、複数のLINE公式アカウントをまたいだ同一人物の判定は、いずれもLINE Loginの仕組みの上に成り立っています。ドキュメントもこれを核心機能と明記しています。
事前にやること：Messaging APIチャネルとLINE Loginチャネルの両方を作る。片方だけで進めない。
スマホでは動くのにPCで友だち追加が失敗する
LINE Loginチャネル側に戻り先のURL（Callback URL）を登録し忘れると、PCのブラウザ経由での友だち追加が失敗します。厄介なのは、スマートフォンからLINE内で開いた場合は通ってしまうことです。担当者のスマホでは正常に動くため、設定漏れに気づかないまま公開してしまいます。
事前にやること：戻り先のURLを登録したうえで、スマホとPCの両方から友だち追加を試す。
デプロイのたびに管理画面ログインが壊れる
管理画面へのアクセスを許可する範囲を決める設定（ADMIN_ORIGINなど）を、リポジトリ側の変数として管理せずにデプロイすると、デプロイのたびに設定が落ちて管理画面にログインできなくなります。
事前にやること：この種の設定値をリポジトリ側の変数、またはサーバー側の秘密情報として管理する運用を、最初に決めておく。
構成の組み方によっては、管理画面にログインできない
管理画面のログイン状態はCookieで保持されます。ブラウザ側でサイトをまたぐCookieの制限が進んでいるため、管理画面とサーバーを別のドメイン構成で置くよりも、同じドメイン配下にそろえる構成が推奨されています。構成が条件を満たしていない場合、ログイン処理は黙ってCookieを発行するのではなく、エラーを返して拒否する作りになっています。
事前にやること：管理画面とサーバーのドメイン構成を、設置前に決めておく。
自動バックアップはあるが、期間に注意が必要
データベース（Cloudflare D1）自体は、Cloudflareが提供する「Time Travel」という仕組みで常時自動的に任意時点へ復元できます。特別な設定は不要で、追加費用もかかりません。ただしさかのぼれる期間はCloudflareのプランに依存し、無料プランは7日、Workers Paidプランは30日です。 この日数はこの記事で唯一、LINE Harnessのリポジトリではなくインフラ提供側のドキュメントに拠っている数値です。他の金額・上限値と同じく改定されうるので、現行値はCloudflare D1のTime Travelドキュメントで確認してください。リポジトリのドキュメントはこれとは別に、テーブル単位でJSONへ書き出す手動エクスポートのコマンドも案内していますが、これは移行やポータブルな控えを取るための補助手段であり、自動バックアップの代わりではありません。
事前にやること：どのCloudflareプランで運用し、7日または30日の復元可能期間で十分かを確認する。より長い期間の保全が必要なら、手動エクスポートを定期的に行う運用を別途決める。
安全性と責任範囲：OSSだから危険、ではない
「オープンソース＝危険」という理解は正確ではありません。コードが公開されていることと、セキュリティが弱いことは別です。ただし「安全である」と言い切るのも違います。何が標準で備わっていて、何が自社の責任になるのかを分けて見るのが実務的です。
標準で入っている防御
リポジトリで実装を確認できた範囲では、次の防御が入っています。技術的な名前は括弧に入れて、何のための仕組みかを先に書きます。
- LINEからの通知が本物かを検証する仕組み（Webhookの署名検証）。第三者が偽の通知を送り込むことを防ぎます。
- API利用時の認証（Bearerトークン）と、LINE内で開くアプリ側の本人確認（IDトークンの検証）。
- 管理画面への不正アクセス対策。ログイン状態をブラウザのスクリプトから読めない形で保持し、意図しない操作の送信を防ぐ仕組み（HttpOnly Cookieのセッションと、CSRF対策のダブルサブミット）を採用しています。これは以前、認証情報をブラウザ内に保存する方式だったものを、公開されている課題への対応として変更したものです。
- 権限の分離。Owner、Admin、Staffの3段階の権限があり、アクセスキーを個別に発行できます。
一方で、「誰が何を承認したか」「誰が何を見たか」を記録・追跡する仕組みは、リポジトリでは実装を確認できませんでした。 確認できたのは上記の3段階の権限管理とアクセスキーの個別発行、それに自動化やアカウント状態などの機能別のログテーブルです。この記事では、確認できないものを「ある」とは書きません。
自社が負う運用作業
前半の比較表で「セルフホストでは自社側」と書いた責任範囲を、実際の作業に落とすと次の4つになります。
| 項目 | 具体的にやること |
|---|---|
| 鍵・認証情報の管理 | CloudflareとLINEの認証情報を安全に保管し、定期的に更新する |
| 公開範囲の設定 | 管理画面へアクセスできる範囲を正しく設定する |
| バックアップ | 自動保持の期間（無料枠7日／Paid30日）で足りるか確認し、不足するなら手動エクスポートも行う |
| 脆弱性への追従 | 本体側で修正が入ったら、取り込むかどうかを判断して反映する |
いずれも高度な作業ではありませんが、「誰の仕事か」が決まっていないと確実に放置されます。 ここは導入可否チェックリストの運用体制の項目と直結します。
サポートは誰が担うのか
「サポートなしで運用し続けられるのか」という不安に、正面から答えます。
セルフホストなので、障害が起きたときの一次対応は自社（またはデプロイを担当する人）が担います。リポジトリで確認できる受け皿は、GitHub上の課題報告の導線と、脆弱性を非公開で報告するための方針が示された文書です。応答時間や対応範囲についての取り決めは示されていないため、この記事でも書きません。
ベンダー契約型の有料ツールでは、一次対応が事業者側に置かれるのが一般的ですが、繰り返しになるとおり、その内容は契約やプランによって異なります。検討中のツールの提供条件は各社の公式情報で確認してください。
この節が意味するのは結局ひとつです。障害時に自社で一次対応できる人がいるかどうか。 これが運用体制チェックの中身です。
「継続性リスク」への現実的な答え
「オープンソースのプロジェクトが続く保証はあるのか」という不安もよく挙がります。保証はありません。ただし、リスクの受け止め方は設計できます。
公式に推奨されているのは、本体のリポジトリをそのまま使うのではなく、フォークして自社の本番として持つ運用形態です。この形にしておくと、次の3つが成立します。
- 自社用の変更を自分たちのコードとして持てる
- 本体側に更新があったときは、取り込みの提案として受け取り、内容を確認してから反映するかを判断できる
- 仮に本体のプロジェクトが止まっても、手元のコードは残る（ドキュメント上MITライセンスと表明されているため、改変して使い続けられます）
つまり継続性リスクへの答えは「このプロジェクトが続くかを予想する」ことではなく、「続かなくても困らない持ち方をする」ことです。この「取り込みの提案を確認して反映する」作業が定常業務として発生するのは、自社用の変更を加えたフォーク（カスタムビルド）を運用する場合です。 実装コードを確認すると、標準構成のまま変更を加えずに運用している場合は、管理画面から一括で更新を取り込めるボタンが用意されており、その場合はこの確認作業自体が発生しません（現在のバージョンと、サーバー・管理画面・LIFFという3つの構成要素それぞれのビルド内容を、更新管理サーバー側が持つ既知リリースの記録と照合する仕組みです。バージョンがその記録にない場合や、3つの構成要素のうちどれか1つでも記録と一致しない場合は「カスタムビルド」、バージョンが記録にあり3つとも一致すれば「標準構成」と判定されます）。
ただしこのボタンは、置いただけでは動きません。 更新の実行にはサーバー側と管理画面側の両方に専用のキーが必要で、標準のセットアップコマンドはこのキーを設定しません（コマンドが管理画面に渡すのはサーバーのURLだけです）。しかも管理画面側のキーは、ログイン画面から入力できる種類のものではなく、管理画面をビルドする時点で埋め込まれる設定値です。つまりあとからキーを登録し、管理画面を作り直して置き直す必要があります。「更新ボタンで済む」状態そのものを、最初に一度コマンドライン作業で作らなければならない、ということです。作業は一度きりですが、誰がそれを担うのかは次のチェックリストで確認してください。
なおPathosionはこの記事の検証に、自社用の変更を加えたフォークを使っています。標準構成とカスタムビルドとで手順が分かれる箇所（本体側の更新など）は、上記のとおり実装コードで両方の分岐を確認したうえで書き分けているので、自社がどちらに当たるかに応じて該当する記述を読んでください。
自社に向いているか：導入可否チェックリスト
ここまでの内容を、自社で判定できる形にまとめます。コピーして社内で共有できるよう、そのまま使える形にしています。
判定はブロック1とブロック2の2つで到達できます。 規模ブロックは費用の見積もりに関わる部分なので、初回の読了時は飛ばしても構いません。ただし導入を最終決定する前には戻ってきてください。 いま有料ツールを使っている場合は、ブロック2の直後にある移行チェック（ブロック2.5）にも目を通してください。こちらは基本的に新しい行き先を生むものではなく、判定結果に確認事項を添えるブロックです。ただし最初の2問に「いいえ」がある場合だけは、後述の「向いていないケース」に該当します。
ブロック1：前提条件は揃っているか（アカウントと環境）
すべて「はい」であれば前提は満たしています。
| # | 確認項目 | はい / いいえ |
|---|---|---|
| 1 | Cloudflareのアカウントを作れる（または既にある） | |
| 2 | LINE Developersのアカウントがあり、Messaging APIチャネルを作れる | |
| 3 | LINE Loginチャネルもあわせて作れる | |
| 4 | Node.jsとpnpmが動く作業環境を用意できる | |
| 5 | 管理画面とサーバーをどのドメイン構成で置くかを決められる |
「いいえ」が1つでもある場合は、まずそこを解消してください。ここでつまずくのは技術力ではなく、多くの場合アカウントと環境の準備が整っていないことが原因です。
ブロック2：運用を続けられる体制があるか
ここが本題です。 判定の分かれ目はこのブロックにあります。
| # | 確認項目 | はい / いいえ |
|---|---|---|
| 6 | デプロイ作業を一度でも触れる人が社内外にいる | |
| 7 | 認証情報や鍵をどこに保管するかのルールがある（または決められる） | |
| 8 | Cloudflareの自動バックアップ保持期間（無料枠7日／Paid30日）で足りるか確認できる（不足するなら追加の手動運用を決められる） | |
| 9 | 本体側の更新を反映できる（標準構成なら、初回に更新用キーの登録と管理画面の置き直しを済ませたうえで管理画面のボタン操作。独自改造ありなら取り込み提案の確認とコマンドライン作業） | |
| 10 | 障害が起きたときに一次対応する担当を決められる |
判定の目安は次のとおりです。
- 6〜10がすべて「はい」：自社で運用できる体制があります。
- 6が「はい」で、7〜10のいずれかが「いいえ」：体制の設計から始めれば導入できます。「誰の仕事か」を決めるところが最初の作業です。
- 6が「いいえ」：現時点では見送るか、外部に委託する前提で検討してください。ここを埋めずに進めると、立ち上がった後で止まります。
ブロック2.5：いま有料ツールを使っている場合だけ、移行が現実的か（移行チェック）
新規に始める方は、このブロックは関係ありません。次のブロックへ進んでください。 いま何らかの有料ツールでLINE公式アカウントを運用している方だけ、次の4問に答えてください。検索結果の上位では「乗り換えは簡単」という論調が目立ちますが、実際に導入可否を左右するのは前提条件でも運用体制でもなく、この移行が現実的に成立するかどうかです。
| # | 確認項目 | はい / いいえ |
|---|---|---|
| a | いま有料ツール側で運用しているタグ・セグメントを、手作業で作り直せる規模・体制である | |
| b | 配信シナリオ（ステップ配信）の進行状況が切り替え時点で途切れ、組み直しになることを許容できる | |
| c | しばらく動いていない友だちほど新しい側への登録が遅れる（次にその人が何かアクションを起こすまで載らない）ことを許容できる | |
| d | 旧ツールとの並行運用が可能かどうかは公式に定義されていないが、その状態のまま切替日を決めてよい |
「はい」がすべてであれば、移行は現実的です。「いいえ」があった場合の受け止め方は、どの設問が「いいえ」だったかで変わります。
- aまたはbが「いいえ」の場合：この2問は、「引き継ぐ仕組みが見つからなかった」という確認済みの事実に基づいています。作り直す体制が取れないなら乗り換えそのものが成立しないため、後述の**「向いていないケース」を確認してください。**
- cまたはdが「いいえ」の場合：この2問は、移行が不可能だという判定ではなく、リスクの大きさを見積もるための設問です（cは時間の経過とともに解消していく話であり、dは「未確認」であって「できない」という結果ではありません）。行き先はブロック2の判定結果と同じ3分岐のままで構いません。ただし切替日を決める前に、いま使っているツール側の担当者に「タグ・セグメントと配信シナリオの進行状況を、他のツールへ持ち出せる形で取り出せるか」を、LINE Harnessの構築を任せる相手に「取り出したデータを取り込む方法があるか、個別の開発が必要か」を、それぞれ確認してください。
この4問は、乗り換えを思いとどまらせるためのものではありません。切替日を決める前に、必要な準備を洗い出すためのものです。
ブロック3：規模と費用が自社で成り立つか（記入式ワークシート）
この記事では「何人まで無料」「何通で何円」という数値を書きません。 上限額も単価も改定されるうえ、参照元のドキュメント間でも値が食い違っているためです。記事に固定値を書いて、それが古くなったまま読まれるほうが害が大きいと判断しました。代わりに、自分の数値を書き出して公式の現行値と突き合わせる形にしています。
ステップ1：自社の数値を書き出す
| 項目 | 自社の数値 |
|---|---|
| 現在の友だち数 | |
| 直近3か月の月間配信通数（1人あたり何通 × 何人か） | |
| 想定する増加ペース（月あたり） | |
| 管理画面を触る人数 | |
| 現在の有料ツールに支払っている月額（有料ツールを使っている場合のみ） |
最後の1行は、乗り換えを検討している場合にだけ書き込んでください。移行チェック（ブロック2.5）で洗い出したタグ・セグメントの作り直しやシナリオの組み直しの手間に見合うかどうかは、この月額が浮くこととの比較で判断してください。 ここでも金額の目安は示しません。自社の契約額をそのまま書き出してください。
ステップ2：公式の現行値を確認する
- サーバー側：Cloudflare Workersの料金ページとCloudflare D1の料金ページで、無料プランの上限を確認する
- 配信側：LINE公式アカウントの料金プランのページで、無料で送れる通数と超過分の単価を確認する
ステップ3：自分で判定する
ステップ1で書き出した数値が、ステップ2で確認した無料枠に収まるかを判定します。
| 判定 | 記入欄 |
|---|---|
| 無料枠に収まる | |
| 収まらないが、超過分は許容できる | |
| 収まらず、要再検討 |
「収まらず、要再検討」だった場合も、次に読む記事の分岐は変わりません。費用面の再確認を、最終決定の前に済ませてください。
向いていないケース
次に当てはまる場合は、導入しない判断のほうが妥当です。無理に進めず見送るのも、十分に正しい選択です。
- デプロイやコマンドライン操作に触れる人が社内外に確保できない：管理画面での日々の運用はできても、立ち上げとインフラ保守が回りません。
- 障害時に自社で一次対応できず、それを許容できない：問い合わせ窓口とSLAを用意しているベンダー契約型であれば、それに対応できる場合があります（提供内容はベンダーごとに異なるため個別に確認してください）。
- 鍵の保管を担当する人を決められない、またはデータをさかのぼれる期間で足りるかを誰も判断できない：セルフホストで最も事故につながりやすいのはここです。
- いま有料ツールで運用しているタグ・セグメント・シナリオの進行状況が事業の中核にあり、それを途切れさせられない、または作り直す体制が取れない（移行チェックのaまたはbが「いいえ」）：前述のとおり、引き継ぐ仕組みは確認できませんでした。現時点では見送るか、少なくとも切替日を決める前に、移行が成立するかを個別に検証してください。この条件が当てはまるのは、いま有料ツールを使っている場合だけです。 新規に始める場合は、移行という論点そのものが発生しません。
- すぐに使い始めたい、テンプレートや運用ノウハウが最初から欲しい：初期設定の代行やテンプレートまで含むプランを用意している有料ツールであれば、立ち上がりが速くなる場合があります。何がプランに含まれるかは各社で異なるため、そこは個別に確認してください。
判定結果ごとの次の一歩
| ブロック2の判定 | 次に読むもの |
|---|---|
| 6〜10がすべて「はい」 | 日々の運用設計へ。複数アカウントの運用とアカウント切り替えの実務は、複数アカウント運用とBAN対策の実務手順で扱います |
| 6が「はい」、7〜10に「いいえ」がある | 技術構成とセルフホストの要件から詰める。OSS構成とセルフホストの要件・手順で扱います |
| 6が「いいえ」 | まず「向いていないケース」を確認したうえで、必要な要件を具体的に把握する。AIでLINE運用するには？公式アカウントの運用基盤を作る手順で、実際に必要になる設定と確認項目を確認できます |
移行チェック（ブロック2.5）でcまたはdが「いいえ」だった場合も、行き先はこの表のままです。ブロック2.5に挙げた2つの確認を、切替日を決める前に済ませてください。aまたはbが「いいえ」だった場合だけは、この表より先に「向いていないケース」を確認してください。
運用編とセルフホスト編は、このシリーズで順次公開します。公開を待たずに今日から進められることを1つだけ挙げるなら、判定がどれであっても先に効くのは、ブロック2の5項目を社内で回覧して「これは誰の仕事か」を1つずつ埋めることです。ここが空欄のまま構築だけ進むと、立ち上がった直後ではなく、最初のアップデートやバックアップのタイミングで止まります。表の3行目に挙げた導入手順の記事は、必要になる設定と確認項目が具体的に並んでいるので、「誰の仕事か」を埋めるときの材料としても使えます。
まとめ：この記事の役割と次に読むもの
3行サマリー
- LINE Harnessは、LINE公式アカウントのCRMを自社のインフラで動かすオープンソースのツールです。日々の配信やタグ操作は管理画面から行える実装になっています。
- 「月0円」はサーバー費用のことで、LINE公式アカウントの配信料金と運用工数は別にかかります。有料ツールから乗り換えても、消えるのはツールの月額だけです。
- 導入可否の分かれ目は、デプロイと鍵の保管を担える人が1人いるかどうかと、データをさかのぼれる期間が自社の業務に足りるかを判断できるかどうかです（本体側の更新は、標準構成なら初回に更新用キーの登録と管理画面の置き直しを済ませておけば、以降は管理画面のボタン操作で反映できます）。いなければ、見送るのも正しい判断です。
次に読む記事の地図
判定結果に応じて進む先は、前節の分岐表のとおりです。判定がついたあとで、さらに踏み込みたくなったときの行き先も挙げておきます。
- 配信設計に進む：複数の導線が並行したときの重複配信を防ぐ設計は、LINE Harnessで重複配信を防ぐシナリオの作り方で扱っています。
- AI連携を検討する：Claude CodeやMCP連携で運用のどこまでを任せられるかは、本サイトのAI連携編の記事で扱います。必須ではなく、上乗せの選択肢として読んでください。
最後に念のため繰り返しておきます。フォークを保持し、公式ドキュメントと実装コードを一次読解してきた立場から書いているこの記事は、2026年7月時点で確認が取れた範囲のまとめです。製品の更新は速く、料金や無料枠の条件も変わります。金額と上限は必ず公式の現行値で確認してください。