結論：セルフホストは可能。分かれ目は「デプロイできるか」ではない
先に判断の枠組みを置きます。
セルフホストできるかどうかを考えるとき、多くの人は「デプロイの難易度」を見ます。しかしこのプロジェクトに関しては、そこは論点になりません。導入用コマンドがCloudflareの認証、データベースの作成とスキーマ適用、Workerと管理画面のデプロイ、シークレットの登録までを一括で実行するため、初回の立ち上げは自動化されている範囲が広いからです。
ただし、Cloudflare側が全自動という意味ではありません。導入コマンドは処理の途中で停止し、Cloudflareのダッシュボードで R2 の請求を有効化して戻ってくることを求めます。ダッシュボードで有効化を済ませてEnterを押すよう求め、押すまで先へは進みません（有効化されたかどうかをコマンドが検証するわけではありません）。これは完走後に残る作業ではなく、完走の前提条件です。「無料で始められるのか」を確かめに来た方にとっては、ここが最初に効く関門になります。課金情報の登録に社内決裁が必要な組織では、着手前にそこを通しておく必要があります。
そのうえで、実際の分かれ目は次の2つです。
| 判断軸 | 中身 | なぜここが分かれ目か |
|---|---|---|
| LINE側の設定を自社で維持できるか | LINE Developers ConsoleとLINE Official Account Managerでの設定は、導入コマンドの完走後に手作業として残る | 自動化の対象外であり、設定漏れの一部は画面上エラーにならず静かに失敗する |
| アップストリームの更新を誰が追うか | 本体側の更新を取り込むかどうかの判断と反映が、継続的な作業として残る | セルフホストである以上、更新の適用主体は自社になる |
デプロイは1回きりのイベントですが、この2つは終わりません。「立ち上げられるか」ではなく「立ち上げた後を担当できる人がいるか」が、セルフホストの可否判断そのものです。
この記事が扱う範囲と、扱わない範囲
範囲を先に明示します。
- 扱う：リポジトリの検証ポイント、アーキテクチャの構成、導入コマンドが実際に行う処理の順序、完走後に残る手作業、セルフホスト可否のチェックリスト
- 扱わない：Cloudflareへの詳細なデプロイ実作業手順、管理画面の操作手順、他社の有料ツールとの料金・機能の優劣比較
詳細なデプロイ実作業については、本サイトに別記事があります。読み終えて「進む」と判断した方向けの案内は、後半のチェックリストの後にまとめます。
「生きているOSSか」を自分で見極めるチェックポイント
OSSを業務で使うかどうかを決めるとき、最初に確認したいのは「このプロジェクトは本当に動いているのか」でしょう。
ここで注意したいのは、「活発かどうか」は他人が判定して渡せるものではないという点です。何をもって活発とみなすかは、自社が許容できるリスクによって変わります。この記事では評価を下さず、確認できた観測値と、どこを見れば自分で判断できるかという観点だけを渡します。
2026年7月29日時点の活動データ
GitHubの公開APIから取得した実測値です。取得日を添えているのは、これらの数値が日々変わるためです。
| 観測項目 | 2026年7月29日時点の値 |
|---|---|
| 最終コミット | 2026年7月21日 |
| 最新リリース | v0.17.0（公開日は2026年7月8日） |
| Star数 | 545 |
| Fork数 | 336 |
| オープン中のIssue数 | 41 |
日付は日本時間に換算しています。GitHubのAPIはUTCで返すため、そのまま読むと1日ずれて見えることがあります。 自分で確認するときは、ここを取り違えないでください。
Issue数についても1点補足します。GitHubのAPIが返すこの値は、仕様上IssueとPull Requestの合算です。純粋な不具合報告の数として読むと、実態より多く見えます。
これらの数値をどう受け取るかは、読者の状況で変わります。判断材料として使いやすいのは、絶対値よりも**「自分が導入を検討している時点から見て、最終コミットと最新リリースがどれくらい前か」**という相対的な見方です。上の表の日付は、あなたが読んでいる時点ではもう古くなっています。リポジトリのトップページを開けば、同じ数値が最新の状態で見られます。
公開リポジトリとライセンス表記
リポジトリの所在は github.com/Shudesu/line-harness-oss です。導入用コマンドが既定で取得しにいく先も、このURLです（後述）。
ライセンスについては、事実の水準を正確に書きます。
- 公開リポジトリのREADMEには「MIT License」と記載があり、ライセンスの節にも商用利用・改変・再配布が自由である旨が書かれています
- npmに公開されている3つのパッケージのメタデータも、ライセンス欄はMITです。読者が実際に実行することになる create-line-harness については、公開リポジトリ側のパッケージ設定（packages/create-line-harness/package.json）の記載とも一致します
- 一方で、リポジトリの直下にLICENSEファイルは置かれていません。 GitHub APIが返すライセンス欄もnullです（2026年7月27日時点で確認）
つまり、MITという表記はドキュメントとパッケージ設定上の表明であり、ファイルとして発行されたライセンス本文を確認したものではありません。これは「危険だ」という話ではなく、社内の法務確認が必要な組織では、この点を先に確認しておくと後戻りが減るという実務上の注意点です。
リリースの記録はどこにあるか
リリースの履歴は2か所にあり、それぞれ内容が違います。 ここを取り違えると、確認したつもりで見落とします。**npx create-line-harnessは実行時にupstream本体の最新リリースタグを取得する仕組みのため、以下はupstream本体（Shudesu/line-harness-oss）側の件数です。**当社フォーク自身の同名ファイルは、フォークした時点からの更新を取り込んでいないため件数が異なります（フォーク側は1件のみ）。
| 場所 | 2026年7月28日時点の件数（upstream本体） | 中身 |
|---|---|---|
| GitHubのリリース一覧 | 19件 | リリースノートを添えて公開された分の履歴（タグ自体は22件あり、リリース一覧に載らないタグも存在するため「完全な履歴」ではない） |
| リポジトリのドキュメント配下のリリースノート（docs/wiki/Release-Notes.md） | 3件（v0.17.0 / v0.16.0 / v0.14.1） | 機能単位で、追加内容・変更の理由・影響範囲まで記述 |
ドキュメント側は全リリースを網羅していません。 変更内容を詳しく読みたいときはこちら、履歴を漏れなく追いたいときはGitHubのリリース一覧、という使い分けになります。
もうひとつ、書式が一定でない点も見ておく価値があります。型チェック・テスト・ビルドの検証コマンドを実行した記録が添えられているのは、ドキュメント側3件のうちv0.14.1だけで、新しい2件にはありません。
ここから「新しいリリースは検証されていない」と読むのは行き過ぎです。正確な受け取り方は、リリースノートの記載だけを根拠に検証プロセスの有無は判断できない、というものです。 自社が使うバージョンの変更内容を読むための資料として扱ってください。
報告の窓口と手順が定義されているか
公開リポジトリの直下に、次の3つのファイルが置かれています。中身の要約も、公開リポジトリ側のファイルを開いて確認したものです（いずれも2026年7月29日時点）。
| ファイル | 中身 |
|---|---|
| SECURITY.md | 脆弱性の非公開報告フロー、サポート対象バージョンの方針（最新の公開リリースと現行のmainブランチ）、修正は前方に進める方針 |
| SUPPORT.md | Issue起票時に求める情報の定型（バージョン、Node/pnpm、Cloudflare設定の状況、実行したコマンド、エラー全文） |
| CONTRIBUTING.md | リポジトリモデル、メンテナ方針、Issueのトリアージ規則、Pull Requestの規則、リリースと同期のポリシー |
ここも評価は避けます。これらのファイルが存在することは、プロジェクトが継続することの保証ではありません。 確認できるのは「報告の窓口と手順が定義されている」という事実までです。
ただし、確認しておく価値はあります。SECURITY.mdのサポート対象バージョン方針は、裏返すと「古いバージョンのまま止めていると、修正が届かない」という運用条件を意味します。これはそのまま、次章以降で扱う「アップストリーム追従を誰が担うか」という論点につながります。
パッケージがnpmに公開されているか
READMEがリンクしている3つのパッケージが、npmレジストリ上に実在することを確認しました（2026年7月27日時点）。
| パッケージ | 最新バージョン | 役割 |
|---|---|---|
| create-line-harness | 0.2.5 | 導入用のコマンドラインツール |
| @line-harness/sdk | 0.18.0 | 外部から操作するためのSDK |
| @line-harness/mcp-server | 0.18.0 | Claude CodeなどのAIツールから操作するためのMCPサーバー |
リポジトリが存在してもパッケージが公開されていないケースはよくあるので、ここは自分で確認しておく価値があります。
アーキテクチャ：何をどこにホストすることになるのか
セルフホストするということは、この構成を自社のアカウント上に置くということです。何が自社側に来るのかを先に押さえます。
どこで何が動くのか
| 実行面 | 何が動くか | どこにホストするか |
|---|---|---|
| API・Webhook受信・定期実行 | Honoで書かれたサーバー本体。LINEからの通知を受け取り、定期処理を回す | Cloudflare Workers |
| データベース | 友だち、タグ、シナリオ、配信などのデータ | Cloudflare D1（SQLite） |
| 管理画面 | Next.js 15で作られた運用画面 | Cloudflare Pages、またはVercel |
| LIFFフロントエンド | LINE内で開くWebページ | Workerに統合済み。別デプロイは不要 |
4つ目について補足します。LIFFのフロントエンドは、Workerのデプロイ時にビルドプラグイン経由で同時にビルドされ、Workers Static Assetsとして配信されます。LIFF用のエンドポイントURLは、Worker本体のURLと同じになります。 過去に別デプロイだった構成から移行する手順がドキュメントに残っているため、以前は別だったことが分かりますが、現在の構成では統合されています。
管理画面だけがCloudflare以外（Vercel）も選べる形になっている点は、構成を決めるときに効いてきます。管理画面とサーバーを別ドメインに分けると、ログイン状態を保持するCookieの扱いが難しくなるためです。
モノレポの読み方
自分で検証したい人向けに、リポジトリのどこを読めば何が分かるかの地図を置きます。
| 場所 | 中身 |
|---|---|
| apps/worker | サーバー本体。APIルート、Webhook受信、定期実行のハンドラ、認証ミドルウェア |
| apps/web | Next.jsの管理画面 |
| apps/liff | LINE内で開くフロントエンド |
| packages/db | データベースのスキーマとマイグレーション |
| packages/line-sdk | LINEのAPIを叩く部分 |
| packages/sdk | 外部から操作するためのSDK |
| packages/mcp-server | AIツールから操作するためのMCPサーバー |
| packages/create-line-harness | 導入用コマンドラインツールの実装 |
| packages/plugin-template | 拡張用のテンプレート |
| packages/shared | 共通処理 |
| packages/update-engine | 更新の取り込みに関わる処理 |
この記事で扱う検証の多くは、packages/create-line-harness と apps/worker を読めば再現できます。
なお、データベースのスキーマについては、この記事ではテーブル数を書きません。 構成図に記載された数値と、実際のスキーマファイル内の定義数が一致していないためです。数え方の定義にも幅があります。扱っている領域は、友だち、タグ、シナリオ、配信、自動化、スコアリング、成果計測とアフィリエイト、フォーム、リマインダー、チャット、通知、外部Webhook、カレンダー連携、決済連携、アカウント状態の監視、管理者管理などに及びます。「LINE配信ツール」という言葉から想像するより広い、という理解が実務的です。
動き続けるのはCron
セルフホストで見落とされやすいのが、ここです。管理画面を閉じていても、Worker上の定期実行は動き続けます。
公開リポジトリの設定ファイルには、2種類のトリガーが定義されています。
| トリガー | 間隔 | 主な役割 |
|---|---|---|
| 短間隔トリガー | 5分ごと | ステップ配信、予約配信、リマインダー配信、詰まった配信の回復、キュー処理、アカウントの状態チェック、アクセストークンの更新などを並行して実行 |
| 長間隔トリガー | 6時間ごと | 予約枠の期限切れ処理など |
短間隔トリガーが実際に何件の処理を並列で走らせているかは実装の変更で動くため、この記事では件数を断定しません。押さえたいのは間隔と役割の性質です。
セルフホストするとは、この定期処理の結果を自分で監視するということです。 配信が止まっても、誰かがダッシュボードを見ていなければ気づきません。ここは費用ではなく体制の話であり、後半のチェックリストにそのまま入ります。何を日次・週次で見るのか、複数のLINE公式アカウントを持つ場合に何が増えるのかまで具体化したい場合は、本番運用(複数アカウント・BAN対策)の設計で扱っています。
ひとつ補足します。この短間隔トリガーの値は設定ファイル（wrangler.tomlのcrons）に書かれている値で、npx create-line-harnessはインストール時に直近のリリースタグへソースを固定する仕組みのため、実際に手元に入るのは5分ごとです（未リリースの開発中ブランチmainだけが1分ごとになっていますが、CLIはそこを参照しません）。フォークして自分で運用する場合は、この設定ファイルの値を自分で把握・変更できます。
認証は3方式、そして認証をスキップする公開パス
セキュリティ面の自己責任範囲を具体的にするために、認証の設計を押さえておきます。公開リポジトリのアーキテクチャ文書に、3つの方式が明記されています。
| 方式 | 対象 | 検証内容 |
|---|---|---|
| Bearer APIキー | 管理画面、SDK、コマンドラインからの呼び出し | Authorizationヘッダのトークン |
| 署名検証 | LINEからのWebhook | X-Line-SignatureヘッダのHMAC-SHA256 |
| LIFF IDトークン | LINE内で開くアプリ | LIFF用のAPIルートで検証 |
あわせて、Bearer認証をスキップする公開パスが定義されています。 Webhookの受信口、トラッキングリンクのリダイレクト、LINE Loginのフロー、LIFF用のAPI、外部からの受信Webhook、そしてAPIドキュメント（/docs と /openapi.json）などです。一覧は apps/worker/src/middleware/auth.ts に列挙されています。
これらは「認証がない」で一括りにできるものではありません。Webhookの受信口は署名検証、LIFF用のAPIはIDトークン検証、外部からの受信Webhookは登録ごとに発行されるシークレットを使ったHMAC-SHA256の署名検証（X-Webhook-Signatureヘッダ）で、それぞれ別の方式で守られています。一方でAPIドキュメントの2パスは、公開ドキュメントとして意図的に無認証で配信されます。 つまり「スキップ＝無防備」でも「スキップされたものはすべて別方式で守られている」でもなく、パスごとに何で守られているのか（あるいは守られていないのか）が違う、というのが実装から読み取れる正確な姿です。この対応関係を把握しておくことが、セルフホストする側の責任になります。負う責任範囲を具体的にイメージしたいなら、この一覧を読むのが最短です。
npx create-line-harness が実際にやること・やらないこと
ここがこの記事の中心です。READMEは導入用コマンドを「1コマンドで完全セットアップ」と説明していますが、実装を読むと、コマンドの実行中にも完走後にも人手が要ります。 実行中に要るのはCloudflare側でのR2の請求有効化、完走後に残るのはLINE側の設定です。訴求文ではなく実装から、自動化される範囲と残る範囲を分けます。
実装から読み取れる処理順
以下は、公開リポジトリの packages/create-line-harness/src/commands/setup.ts を読んで再構成した処理順です。私たちがインストーラを実行して取った実行ログではありません。ファイル内のステップ区切りのコメントと、関数の呼び出し順から起こしています。主要なステップの列であり、内部処理の細部まで網羅したものではありません。
出所をこう書くのは、留保のためではありません。根拠にしたファイルは実行環境ではなく1本のソースファイルなので、順序に疑問があれば、あなたが同じファイルを開いて同じ手順で確かめられます。
- 環境チェック（Node.jsのバージョンを実際に検証する）
- 公式リリースの解決とダウンロード、クローンをリリースタグに固定する
- Cloudflareへの認証
- アカウントの確認
- Cloudflare R2の有効化確認（ダッシュボードで請求設定を済ませてからEnterを押す対話ステップ）
- プロジェクト名の入力
- LINEの認証情報の入力
- LIFF IDの入力
- APIキーの自動生成
- D1データベースの作成とスキーマ適用
- R2バケットの作成
- ボットのベーシックIDの取得
- Workerのデプロイ
- シークレットの登録
- LINEアカウントのデータベースへの登録
- 管理画面のデプロイ
- 管理画面のログイン設定
- Worker側の設定反映
- （任意）AIツール用の設定ファイルの生成
2番目のステップは、この一覧の中で特に意味があります。クローンをリリースタグに固定するのは、デプロイするWorkerと、データベースのスキーマ、マイグレーション、管理画面のアセットを、同じリリースに揃えるためです。ここがずれると、更新のたびに整合しない状態が生まれます。逆に言えば、開発用のフラグを付けてソースから直接ビルドした場合は、この固定が効かず、更新コマンドの対象外になります。
12番目のボットのベーシックIDの取得が、13番目のWorkerのデプロイより前にあるのは、LINEのAPIを呼ぶだけでWorkerを必要としないためです。実装のコメントにもその理由が書かれています。処理順を読むと、こうした依存関係の設計意図まで見えます。
取得元は差し替えられ、中断しても再開できる
フォーク運用を検討している人向けに、実装から読み取れる性質を2つ挙げます。
取得元は差し替えられます。 導入用コマンドは、既定で公開リポジトリをクローンし、ホームディレクトリ配下の専用フォルダ（~/.line-harness）に配置します。この取得元は環境変数 LINE_HARNESS_REPO_URL で上書きできるため、自社のフォークを指定すれば、自社の変更を含んだ状態で同じコマンドを使えます。既定値の定義は packages/create-line-harness/src/steps/clone-repo.ts にあります。フォーク運用を前提にセルフホストを設計するなら、ここは押さえておく価値があります。
中断しても再開できます。 導入用コマンドはセットアップの進捗を保存し、完了済みのステップをスキップします。実装上も、各ステップが「完了済みか」を確認してから実行する構造になっています。途中でCloudflareのダッシュボードを開いて設定してくる対話ステップがあるため、この作りは実務的です。ただしCloudflareのアカウントを切り替えた場合は、前のアカウント側に結果が残っているステップをやり直す必要があることが、実装のコメント（packages/create-line-harness/src/commands/setup.ts）に明記されています。
完走したときに表示される内容
導入コマンドが最後に何を表示するかは、この記事の読者にとっていちばん実用的な情報です。ここに、残りの作業が列挙されているからです。
以下は、公開リポジトリの実装コードにある完了画面の生成部分から再構成したものです。私たちが実際にコマンドを実行して撮ったものではなく、その画面を出力しているコードを読んで整理したものである点は明記しておきます。
セットアップ完了！
① LINE 応答設定を変更してください
→ LINE Official Account Manager → 設定 → 応答設定
チャット: オフ / あいさつメッセージ: オフ
応答メッセージ: オフ / Webhook: オン
② Webhook URL を設定してください
→ LINE Official Account Manager → 設定 → Messaging API
Webhook URL に {WorkerのURL}/webhook を貼り付け、「Webhookの利用」をON
③ LINE Login チャネルの設定
→ LINE Developers Console → LINE Login チャネル
a. 「リンクされたLINE公式アカウント」で公式アカウントを選択
b. 「友だち追加オプション」を On (aggressive) に設定
c. Callback URL に {WorkerのURL}/auth/callback を登録
④ LIFF エンドポイント URL を更新してください
→ LINE Developers Console → LINE Login チャネル → LIFF
エンドポイント URL を {WorkerのURL}?liffId={LIFF ID} に変更
⑤ 友だち追加 URL（この URL を共有してください）
{WorkerのURL}/auth/line?ref=setup
⑥ 管理画面
{管理画面のURL}
API Key: （再表示できないため、安全な場所に保存すること）
この画面が示しているのは、完走した時点はゴールではなく、手作業の開始地点だということです。
自動化されないもの
まず、完走を待つまでもなく人手が要る箇所がひとつあります。Cloudflare側のR2の請求有効化です。 上の処理順の5番目にあたり、導入コマンドはここで停止して、Cloudflareのダッシュボードで請求を有効化し、済んだらEnterを押すよう求めます。押すまで先へは進みません。
これは完走後に残る作業ではなく、完走の前提条件です。あえて先に挙げるのは、この記事の読者が検索結果で繰り返し目にしているであろう「無料で動くOSS」という訴求に対して、実務上いちばん早く効いてくる留保だからです。課金情報の登録に社内決裁が必要な組織では、決裁を通す前にコマンドを走らせると、この5番目で止まったまま動けません。
そのうえで、完走した後にLINE側へ残る作業です。前節の①から④が、そのまま「自動化されないもの」の一覧になります。整理し直すと次のようになります。
| 残る作業 | 場所 | なぜ自動化されないか |
|---|---|---|
| 応答設定の変更（チャット・あいさつメッセージ・応答メッセージをオフ、Webhookをオン） | LINE Official Account Manager | 管理者としての画面操作が必要で、APIから設定する経路がない |
| Webhook URLの登録 | LINE Official Account Manager | LINE Messaging APIにはWebhook URLを設定するAPI（PUT /v2/bot/channel/webhook/endpoint）が公開されているが、導入コマンドはこれを呼び出さず、画面での貼り付けを案内する設計になっている |
| LINE Loginチャネル側の設定（公式アカウントとの紐づけ、友だち追加オプション、Callback URLの登録） | LINE Developers Console | 管理者としての画面操作が必要で、APIから設定する経路がない |
| LIFFエンドポイントURLの更新 | LINE Developers Console | LIFFアプリ自体を人間が作る前提のため（次節参照） |
さらに、これらの前段としてLINE Developers Console上でMessaging APIチャネル、LINE Loginチャネル、LIFFアプリを作っておく必要があります。導入コマンドはこれらの作成を代行せず、入力を求めます。
この記事では、それぞれのURLが何の役割を担っているのか、どの画面のどこに入れるのかまでは踏み込みません。 実作業の手順は本サイトの別記事が担当しており、そちらのほうが具体的です。ここで押さえてほしいのは「完走後に何が自分の責任として残るのか」という棚卸しです。
読み方をひとつ提案します。この一覧を見て**「これは誰の仕事になるのか」がすぐ思い浮かばないなら、それ自体が判断材料**です。1回設定して終わりではなく、チャネルを増やすたび、URLが変わるたびに戻ってくる作業だからです。
公開ドキュメントと実装が食い違っている2点
実装を読んで検証すると意味があるのは、こういうところです。以下の2点は、公開リポジトリのREADMEと実装コードの記述が一致していません。どちらも、あなたが同じファイルを開けば同じ結論に到達できます。
1つ目：LIFFアプリの自動作成
READMEの「1コマンドで完全セットアップ」の説明に、自動化される項目として「LIFF アプリの自動作成」が挙げられています。しかし実装（packages/create-line-harness/src/commands/setup.ts）は、LIFF IDの手入力を求めます。プロンプトの直前には、LINE Developers ConsoleでLIFFアプリを作る手順の案内文まで表示されます。
実際に必要なのは、次の3つです。
- LINE Developers ConsoleでLIFFアプリを作成する
- 公開状態にする
- スコープに openid、profile、chat_message.write を設定する
そのうえでLIFF IDをコマンドに入力する、という流れになります。導入計画を立てるときは、LIFFアプリの作成は自分でやる作業として見積もってください。
2つ目：必要なNode.jsのバージョン
READMEの「必要なもの」には「Node.js 22+」と記載されています。一方、導入コマンドの環境チェックの実装（packages/create-line-harness/src/steps/check-deps.ts）は、メジャーバージョンが20未満のときにエラーで中断します。つまり実際の下限は20です。ルートのpackage.jsonのengines指定も20以上、公式ドキュメントの前提条件表も20以上です。
実務的な整理は「READMEはNode.js 22+を求めるが、導入コマンドの最低要件は20」です。手元の環境が20系のままでも、導入コマンド自体は動きます。
この2点に共通するのは、READMEが実装より広い範囲を約束しているという構図です。これはこのプロジェクト固有の問題というより、OSSでよく起きることです。ここから引き出せる実践的な示唆はひとつで、導入計画の見積もりは、READMEではなく実装で確かめるということです。上に挙げたファイルパスは公開されているので、同じ手順で追試できます。
セルフホスト可否チェックリスト
ここまでの内容を、自社で判定できる形にまとめます。コピーして社内で共有できる粒度にしています。
自社で判定する11項目
各項目には、確認元となるリポジトリ内のファイルと、満たせない場合の代替を添えました。
| # | 確認項目 | 確認元 | 満たせない場合 | はい / いいえ |
|---|---|---|---|---|
| 1 | Cloudflareのアカウントを用意できる | packages/create-line-harness/src/commands/setup.ts（Cloudflare認証・アカウント確認のステップ） | 導入自体が進まない。ここは前提条件 | |
| 2 | Cloudflare側でR2の請求を有効化できる（導入コマンドは、この操作を促してここで停止する） | packages/create-line-harness/src/commands/setup.ts（R2の有効化確認のステップ） | 課金情報の登録に社内決裁が要るなら、着手前に決裁を通しておく。通らないならセルフホスト自体を見送る | |
| 3 | LINE公式アカウントとMessaging APIチャネルを自社で作れる | packages/create-line-harness/src/commands/setup.ts（LINEの認証情報の入力ステップ） | 導入自体が進まない | |
| 4 | LINE Loginチャネルを作れる | docs/wiki/Getting-Started.md（LINE Login必須の理由の記載） | 中核機能が成立しない。下の「見落とされやすい2点」を参照 | |
| 5 | LIFFアプリを自分で作成し、公開状態にしてスコープを設定できる | packages/create-line-harness/src/commands/setup.ts（LIFF ID入力プロンプト） | 導入コマンドが完走できない | |
| 6 | Node.js 20以上とpnpmが動く作業環境を用意できる | packages/create-line-harness/src/steps/check-deps.ts、ルートの package.json（engines） | 導入コマンドが起動時に中断する | |
| 7 | シークレットを wrangler secret put で管理する運用に耐えられる | docs/wiki/Configuration.md、docs/wiki/21-Deployment.md | 設定ファイルに鍵を書く運用になり、漏洩リスクが上がる | |
| 8 | 管理画面へのアクセス許可範囲（ADMIN_ORIGIN）を自分で判断・設定できる | apps/worker/src/middleware/admin-auth-config.ts | 管理画面にログインできない、または許可範囲の判断を放置することになる | |
| 9 | 定期処理の結果（配信、アカウント状態）を監視する体制がある | apps/worker/wrangler.toml（crons）、apps/worker/src/index.ts（scheduled ハンドラ） | 配信が止まっても気づけない | |
| 10 | アップストリームの更新を追い、取り込みを判断できる担当がいる | SECURITY.md（サポート対象バージョンの方針） | 修正が届かないバージョンで止まる | |
| 11 | 完走後に残るLINE側設定を維持できる（チャネル追加やURL変更のたびに戻る作業） | packages/create-line-harness/src/commands/setup.ts（完了画面の生成部） | 設定漏れが起き、その一部は画面上エラーにならない |
2番を独立した項目にしているのは、ここが「技術的にできるか」ではなく**「社内で課金情報を登録できるか」という別種の関門**だからです。手を動かす前に確認しておかないと、コマンドを走らせた場所で止まります。
判定の目安です。
- 1から6がすべて「はい」：前提条件は揃っています。ここで問われているのは技術力ではなく、アカウントと環境をどれだけ準備できているかです。
- 7から11がすべて「はい」：自社でセルフホストを続けられる体制があります。
- 7から11のいずれかが「いいえ」：そこが「誰の仕事か」を決めるところから始めてください。 導入自体は進みますが、止まるのは立ち上げ直後ではなく、最初の更新や最初の障害のタイミングです。
- 10または11が「いいえ」で、埋める見込みがない：自社で持たずに、運用を委ねる形を検討するか、導入を見送る判断も妥当です。ここで無理をせず見送るという判断も、十分にありです。
特に見落とされやすい2点
LINE Loginチャネルは実質的に必須です。 配信用の設定（Messaging APIチャネル）だけあれば動く、と思って進めると詰まります。友だちを識別する内部IDの自動取得、どこから流入したかの追跡、広告のクリック情報の記録、複数のLINE公式アカウントをまたいだ同一人物の判定は、いずれもLINE Loginの仕組みの上に成り立っています。公式ドキュメントもこれを中核機能として明記しています。
なお、設定ファイルによってはLINE Loginの環境変数を「任意」と記載している箇所があり、ドキュメント内で記述が揺れています。「任意」の記載を見て省略すると、上に挙げた機能が動きません。 「中核機能を使うなら必須」と理解してください。
CORSは全オリジン許可ではありません。 OSSのセキュリティを心配する文脈で「初期状態は緩い設定になっているのでは」と考える方がいますが、実装コードを直接確認したところ、管理画面のアクセス許可はADMIN_ORIGINで指定したオリジンを基本に許可する方式でした（主方式はPathosionのフォーク・upstream本体で共通）。開発時のループバック（localhost / 127.0.0.1 / ::1）を通す分岐も、フォーク・upstream本体の両方に同じ形で入っています。ただしこれは、Worker自身がループバック上で動いているとき（wrangler devなど）に限って効く分岐であり、デプロイ後の本番オリジンでは働きません。
フォークとupstream本体でCORSの実装が違うのは、次の1点だけです。 upstream本体にはisAllowedAdminOrigin()という関数があり、同じCloudflare Pagesプロジェクト内のプレビューデプロイ用オリジン（<ハッシュ>.プロジェクト名.pages.dev）を、本番オリジン（プロジェクト名.pages.dev）と同等に扱って許可します。Pathosionのフォークにはこの関数がなく、許可リストとの完全一致だけで判定します。npx create-line-harnessでセットアップした場合はupstream本体の挙動になるため、Pagesプレビューからのアクセスも通る場合がある点は把握しておいてください。実装ファイルは apps/worker/src/index.ts と apps/worker/src/middleware/admin-auth-config.ts です。
この点で実務的に重要なのは、設定の緩さではなく、この値を自分で設定・維持する必要があることです。デプロイのたびにこの設定が落ちれば、管理画面にログインできなくなります。チェックリストの8番はここに対応しています。
費用はどう見積もるか
金額の話より先に、順序として押さえておくことがあります。セットアップを始める時点で、Cloudflare側のR2の請求を有効化する必要があります。 導入コマンドはここで停止し、Enterを押すまで先へ進みません（処理順の5番目、確認元は packages/create-line-harness/src/commands/setup.ts のR2有効化ステップ）。つまり実務上は、「無料枠の範囲に収まるか」よりも前に、「課金情報を登録できる状態か」が着手の前提になります。
ただし、請求の有効化と課金の発生は別の話です。 有効化という操作が必要であることと、実際にいくら請求されるかは切り分けて考えてください。後者は下に挙げた公式の料金ページで確認する領域です。
そのうえで金額の話です。リポジトリ内のデプロイ用ドキュメントには、Cloudflareの無料枠と有料枠、LINE Messaging APIのプラン別の無料通数、友だち規模別の目安が記載されています。
ただし、この記事にはその数値を転記しません。 理由は2つあります。リポジトリ内の記載はドキュメントが書かれた時点の値であり、Cloudflare側もLINE側も料金は改定されるためです。記事に固定値を書けば、記事の更新遅れがそのまま読者の誤判断になります。
コスト構造として押さえるべき形だけを書きます。
| 層 | 内容 |
|---|---|
| サーバー費用 | Cloudflare側。無料枠に収まる規模なら費用が発生しない構成 |
| LINE配信料金 | LINEヤフーとの契約に基づいて発生。セルフホストにしても消えない |
| 運用工数 | 金額に表れない。上のチェックリストの7から11がこれに当たる |
現行の上限と単価は、Cloudflare Workersの料金ページ、Cloudflare D1の料金ページ、LINE公式アカウントの料金プランのページで確認してください。
判定が出たら、どこへ進むか
判定に応じた行き先を、ここに1か所だけ置きます。
| チェックリストの判定 | 次にやること |
|---|---|
| 1から11がすべて「はい」 | 実作業に進む。下の段落で受け皿を案内します |
| 7から11に「いいえ」がある | チェックリストの7から11を社内で回覧し、「これは誰の仕事か」を1項目ずつ埋める |
| 10または11を埋められない | 自社で持たずに委ねる形を検討するか、導入を見送る |
実作業に進む場合の受け皿：本サイトには、AIでLINE運用するには？公式アカウントの運用基盤を作る手順という記事があります。こちらはAIと対話しながら設定を進めていく別経路のガイドです。この記事で扱わなかった各URLの役割の違いや、公開前チェックリストまで具体的に扱っています。この記事のコマンドライン経路と同じ手順の前後関係にあるかまでは確認していませんが、実作業で必要になる設定項目と確認観点は重なります。
判断がつかない状態で今日から進められることを1つだけ挙げるなら、上の表の2行目です。ここが空欄のまま構築だけ進むと、立ち上がった直後ではなく、最初の更新や最初の障害のタイミングで止まります。
構築できたら次に何ができるのか
セルフホストの判断とは直接関係しませんが、構築後の展開について、実装とドキュメントで確認できた事実だけ触れておきます。
導入コマンドの最後のステップには、任意でAIツール用の設定ファイル（.mcp.json）を生成する処理があります。またリポジトリには @line-harness/mcp-server というパッケージが同梱されており、公開ドキュメント配下にはClaude Codeとの連携とMCPサーバーについての解説ファイル（docs/wiki/23-Claude-Code-Integration.md、docs/wiki/24-MCP-Server.md）が置かれています（2026年7月29日時点で確認）。
つまり、構築した基盤をAIツールから操作するための入口が、最初から用意されているということです。ただしこの記事では、MCP経由で実際に何がどこまでできるのかまでは検証していません。構築後にそこへ関心が移った方は、セルフホスト後のAI活用方法を見るへ進んでください。
セルフホストの可否判断という観点では、この部分は必須要件ではありません。 「AIから操作できるから導入する」ではなく、「導入したうえで、必要になれば使える選択肢がある」という位置づけで読んでください。
まとめ：この記事の結論と、確認し続けてほしいこと
- LINE Harnessは公開リポジトリとして実在し、Cloudflare Workers + D1 + Next.jsという構成のため、セルフホスト自体は現実的に可能です。導入用コマンドが初回の立ち上げの大部分を自動化します。
- ただし、そのコマンドは途中でCloudflare側のR2の請求有効化を人手に委ねて停止し、完走した後もLINE Developers ConsoleとLINE Official Account Manager側の設定が手作業として残ります。READMEの「1コマンドで完全セットアップ」は文字通りではありません。
- 判断の分かれ目は「デプロイできるか」ではなく、**「LINE側設定の維持とアップストリーム追従を担当する人がいるか」**です。いなければ、見送るか委ねるのが妥当です。
行き先は前節「判定が出たら、どこへ進むか」にまとめています。ここで繰り返さないのは、判断がついていない状態で行き先だけを増やしても選べないからです。
締めくくりに、もう一度この記事の立場を書いておきます。フォークを保持したうえで、公開リポジトリの実装コードとドキュメントを直接読んで検証してきた立場から、2026年7月時点で確認できた範囲を整理したのが、この記事の内容です。稼働中の本番環境での実測値は含みません。 リポジトリの更新は速いので、導入を決める段階では、この記事に挙げたファイルを自分で開いて現在の記述を確認してください。そのやり方まで含めて渡すことが、この記事の目的です。