UTAGEからLINE Harnessへ移行する前に、1〜2週間かけて調べた13項目｜事例ゼロからの調査記録

「LINE Harnessに乗り換えたら、今いる友だちは消えるのか」
「UTAGEで付けたタグや属性は、どこまで引き継げるのか」
「OSSなら、本当に月額0円で運用できるのか」

UTAGEから LINE Harnessへの移行を考えたとき、私が最初にぶつかったのがこの3つでした。

ところが、検索しても同じ条件の移行事例が見つかりません。複数のLINE公式アカウントをUTAGEで運用し、友だちは合わせて約5,000人規模。その状態から、Cloudflare Workers と D1 で動くOSSのLINE CRMへ切り替える事例です。

事例がないので、自分で調べるしかありませんでした。管理画面、APIの公式仕様、エクスポートCSV、実機テストを一つずつ照合して、かれこれ1〜2週間かかっています。

先にお伝えすると、この記事は移行完了後の成功事例ではありません。 2026年7月時点で「本番移行前にリスクを洗い出した」調査記録です。

そしてもう一つ、正直に書いておきます。この調査で出した結論のうち1つは、その後のテスト移行であっさり覆りました。 どこが覆ったかは記事の中ではっきり書きます。

同じようにUTAGEからLINE Harnessへの移行を考えている事業者さんが、月額料金だけで判断せずに済むよう、材料として使ってください。

もくじ[ タップで開閉 ]

1. 1乗り換えの理由は月額2.2万円ではなく、AIを載せる土台だった
2. 2Webhookを切り替えるだけなら、友だちは理論上1人も減らない
3. 3移行前に一番警戒すべきは、旧ツールからの二重配信
4. 432桁のIDはMD5で一致した。ただしこの結論は、後に覆った
5. 5既存友だちの復元速度は、アカウントの認証状態で変わる
6. 6「OSSだから月0円」は成立しない
7. 7複数アカウント運用は、技術より先に規約を確認する
8. 8切替当日は「旧ツール停止 → Webhook切替」の順で、最小アカウントから
9. 9まとめ：移行の仕事は、Webhook変更の前後にある

乗り換えの理由は月額2.2万円ではなく、AIを載せる土台だった

最初に、移行を考えた理由から書きます。ここを飛ばすと、この記事の判断がすべてコスト削減の話に見えてしまうからです。

きっかけは確かにお金でした。ただ、決め手は別のところにありました。

発端は、UTAGEの月額約2.2万円

私たちが利用しているUTAGEの月額は、約2.2万円です。移行してUTAGEを解約すれば、この利用料は削減できます。

きっかけとしては、これが最初でした。

本命は、AI botによるユーザー・顧客管理の省力化

ただ、月額2.2万円だけなら払い続ける選択肢もありました。それでも動いたのは、別の見込みがあったからです。

AI botを導入して、社内のユーザー・顧客管理と運営コストを大幅に削減するという見込みです。

LINE Harnessは Cloudflare Workers、D1、Pages などで動くオープンソースのLINE CRMです。Claude Code から操作するための MCP Server も同梱されています。AIを前提にした作りになっていました。

UTAGEでも不可能ではない。ただし1から開発するのに等しい

誤解のないように書くと、UTAGEのままでAI連携ができないわけではありません。

ただ、技術的なハードルは高いと判断しました。公式LINE×AIツールを1から開発するようなものだからです。生成AIがあるとはいえ、そこにかかる時間コストが見合いませんでした。

つまり私の判断軸は、金額ではなく時間でした。自分たちでAI連携を作る時間と、AI前提の土台へ移る時間を比べて、後者を選んだということです。

Webhookを切り替えるだけなら、友だちは理論上1人も減らない

いちばん不安だった問いから整理します。

同じLINE公式アカウントを使い続け、接続先だけをUTAGEからLINE Harnessへ変える。この場合、友だちそのものはLINE公式アカウント側に残ると考えられます。友だちを別のアカウントへ移す作業ではないからです。

ただし、この記事を書いた時点で私はまだ本番移行を終えていません。ですので「絶対に減らない」ではなく、同一チャネルでWebhookを切り替える場合の理論上の結論としてお伝えします。

ツールとの接続は、1本のWebhookで切り替わる

LINEでメッセージや友だち追加などのイベントが起きると、その情報はLINE Developersで設定した Webhook URL へ送られます。

UTAGEからLINE Harnessへの切替は、この送信先を新しいURLへ変更する作業です。

同じLINE公式アカウントと Messaging API チャネルを使う限り、友だちに再登録をお願いする必要はありません。別アカウントへ引っ越す移行とは、構造がまったく違います。

「友だちを移す」という発想は、大量離脱を招きかねない

別のLINE公式アカウントを新設して、登録し直してもらう方法もあります。ただ、全員が再登録してくれるとは限りません。

それはツールの乗り換えではなく、友だち基盤そのものの引っ越しです。

移行の相談では、まずこの2つが混同されていないかを確認してください。

移行前に一番警戒すべきは、旧ツールからの二重配信

Webhookをハーネスへ切り替えれば、UTAGEは完全に止まる。最初は私もそう考えていました。

しかし、Webhookで変わるのは主にLINEからツールへ届く受信経路です。UTAGEに残っている予約配信やステップ配信は、別の仕組みで送られる可能性があります。

ここを見落とすと、新旧両方のツールから同じ相手へ配信する事故につながります。

Webhook切替だけでは、旧ツールの送信経路は残る

ツールからLINEへメッセージを送るときは、チャネルアクセストークンを使います。

つまり、受信先のWebhookを変更しても、旧ツールが有効なアクセストークンを持ち、配信予定を保持していれば、送信経路はそのまま残ります。

切替前に、UTAGE側の予約配信、進行中のステップ、申込み通知、自動処理を棚卸しして、先に停止する計画が必要です。

準備中に、アクセストークンを再発行しない

32桁のIDはMD5で一致した。ただしこの結論は、後に覆った

ここがこの記事の山場です。

友だち自体がLINE側に残っても、UTAGEで付けたタグや属性が自動的にLINE Harnessへ移るわけではありません。旧ツールのデータと新ツールのLINE UIDを、同一人物として結びつける処理が要ります。

今回のUTAGEエクスポートには、似た名前のID列が3つありました。表示名ではなく、機械的に一致を判定できるIDを探しました。

「LINE友だちID」という列名だけでは、照合できない

「全シナリオ共通読者ID」と「LINE友だちID」は、どちらも12桁の英数字でした。

名前だけを見ると後者がLINE UIDに思えます。ところが今回のCSVでは、これはUTAGE内部の識別子とみられ、LINE Harness側のUIDとは一致しませんでした。

一方で「アカウント共通LINE友だちID」は、32桁の16進数でした。この列が手がかりになりました。

自分の1件では、MD5が完全に一致した

自分のLINEアカウントを新旧の両ツールへ登録し、LINE Harness側で取得したUIDへMD5をかけました。

その結果、UTAGEの「アカウント共通LINE友だちID」と完全に一致しました。

LINE UIDはプロバイダー単位で発行されるため、同じ本番チャネルを使う今回の方式が前提です。そして当時の私は、これを「UTAGEの公開仕様として保証された変換規則ではない」と書き、本番前に複数件で再検証するつもりでいました。

テスト移行で、この方法は使えないと分かった

この記事の最後に、私は「『計算上一致』と『運用で実証』は別だ」と書いています。その警告を書いた本人が、まさにその境目でつまずいたわけです。

だからこそ、この章はあえてそのまま残しました。1件の一致を仕様だと思い込むと、こうなります。

既存友だちの復元速度は、アカウントの認証状態で変わる

Webhookを切り替えた直後、LINE Harnessのデータベースに既存の友だちが揃っていない可能性があります。

新しいメッセージ、ボタンのタップ、友だち追加などのイベントを受け取って、初めてツール側に記録されるからです。

どれだけ早く復元できるかは、LINE公式アカウントの認証状態と、LINE Harnessへ取り込む仕組みに左右されます。

認証済みなら、followers APIが使える

LINE Developers の Messaging API リファレンスを確認しました。認証済みアカウントであれば、友だちのUID一覧を取得できます。1回の取得上限は1,000件で、続きはページングします。

ただし、ブロック済み、退会済み、プロフィール情報の取得に同意していない利用者は含まれません。管理画面の友だち数と取得件数が一致するとは限りません。

さらに、今回試したLINE Harness環境には一括同期用のエンドポイントが見当たりませんでした。取得後の投入は自作スクリプトが必要だと判断しています。

未認証なら、反応した人から順に復元する設計になる

未認証アカウントでは、この友だち一覧取得APIを利用できません。

その場合は、メッセージ送信やボタンタップなどのWebhookを受けた人から、段階的にLINE Harnessへ記録していく設計になります。

切替直後から全員へ過去タグを復元できるとは限りません。セグメント配信をいつ始めるかも、計画に入れてください。実際の復元率は、本番移行後に測る数字です。

「OSSだから月0円」は成立しない

LINE Harnessの公式リポジトリでは、Cloudflareの無料枠で動かせると案内されています。小規模な検証環境では、これは大きな魅力です。

ただし本番の費用は、ツール利用料だけでは判断できません。私は費用を、UTAGE・Cloudflare・LINE公式アカウントという3つの層に分けました。

UTAGEの利用料が消えても、インフラ費と人の時間は残る

UTAGEを解約すれば、月額約2.2万円は削減できます。

ただ、UTAGEはLP、予約フォーム、決済まで、販売導線（ファネル）を一つにつなげられるツールです。代替機能の実装・デプロイ・障害調査を自分たちで回せないなら、月額を払うほうが結果的に安い可能性もあります。

そしてLINE Harnessを動かすCloudflareの費用と、構築・保守にかかる人の時間は残ります。OSSの利用料が0円でも、運用全体が0円になるわけではありません。

Cloudflareの無料枠には、停止リスクがある

Cloudflareの料金ページによると、D1の無料枠は1日500万行の読み取り、10万行の書き込みです。

無料枠を超えると、UTCのリセットまでクエリがエラーになると案内されています。

複数アカウントを同じCloudflareアカウントで運用するなら、使用量は合算で考える必要があります。本番前に実測して、必要なら月額最低5ドルのPaidへ上げる判断をします。

私の試算では、LINE配信料が最大のコストだった

出典: LINE公式アカウント 料金プラン / Cloudflare D1 Pricing（いずれも2026年7月時点で確認）

LINE公式アカウントのスタンダードプランは、2026年7月時点で月額1.5万円です。この料金はLINE Harnessへ移行しても残ります。

一斉配信・絞り込み配信・ステップ配信やPush APIはカウント対象で、Reply APIは対象外です。

つまり、私の環境で最大のコストはツール利用料ではなく、LINEの配信料でした。

複数アカウント運用は、技術より先に規約を確認する

複数のLINE公式アカウントを1つのCRMで扱えることは、運用上とても便利です。

しかし、技術的にできることと、規約上してよいことは同じではありません。

LINE公式アカウントAPI利用規約では、利用者情報を「LINE公式アカウント毎に管理」することが求められています。

利用者情報の横断利用は、規約に抵触するおそれがある

たとえば、アカウントAで得たタグを、本人が登録していないアカウントBの管理画面に表示する。あるいはアイコン画像などを使い、複数アカウントの友だちを同一人物として横断表示する。

こうした設計は、規約の趣旨に抵触するおそれがあります。

個人情報保護法上の扱いとは別に、LINE側の規約として検討が必要です。

3つの選択肢のうち、私はデータ分離を選んだ

本番移行は完了していないため、これは実施結果ではありません。データ構造と管理画面の両方で、別アカウントの情報が混ざらないことを検証していきます。

タグ名の衝突は、誤配信につながりかねない

複数アカウントでタグを共通管理すると、「社会人」「大学生」「申込済み」のような汎用名が重なります。

表示上の分かりにくさだけなら、後で整理できるかもしれません。しかしタグ付与をきっかけにシナリオが始まる場合は、別アカウントへの誤配信につながります。

特に tag_added をトリガーにした自動処理では、名前の衝突が意図しないシナリオ起動につながります。これは実際に誤配信が起きた結果ではなく、データ構造から想定したリスクです。

切替当日は「旧ツール停止 → Webhook切替」の順で、最小アカウントから

データが消えるかどうかだけを考えていると、切替日の選び方を誤ります。

本当に止めたくないのは、申込み通知、予約配信、タグ付与、決済後の案内など、進行中のオペレーションです。

イベントやキャンペーンと重ならない日を選び、旧ツールの現Webhook URLも必ず控えておきます。

当日は、この順番で確認する

1. 旧ツールの配信停止 — 予約配信・進行中ステップ・自動処理を止める
2. Webhook切替 — 送信先URLをLINE Harnessへ変更する
3. Verify — LINE Developers上で疎通を確認する
4. 新規友だち追加 — 実機でテスト登録する
5. 受信確認 — メッセージがLINE Harnessに届くか見る
6. 既存友だちの見え方 — データベース上でどう記録されるか確認する
7. リッチメニュー — 表示崩れがないか確認する

その後、ログやエラーを監視してからタグを復元し、必要な案内を配信します。

先にWebhookだけを変えないでください。 作業者、時刻、合格条件、切り戻しの判断基準も事前に決めておきます。

切り戻しても、完全には元へ戻せない

一度に変える変数は、1つだけにする

複数アカウントを一斉に切り替えると、問題が起きたときに原因を切り分けられません。

私は、友だち数が少なく進行中の施策も少ないアカウントから始める予定です。そこで復元率、作業時間、Cloudflareの使用量、配信エラー、ブロック率を測ります。

Webhook、タグ設計、ステップ配信、AI応答、決済連携を同時に変えると、異常の原因が分かりません。まずは受信と基本配信。次にタグ復元。その後にシナリオや外部連携を追加します。

なお、旧ツールはすぐに解約せず、過去データや購入履歴を参照できる期間を設けます。

まとめ：移行の仕事は、Webhook変更の前後にある

今回、私の条件と一致するUTAGEからLINE Harnessへの移行事例は、調査した範囲では見つけられませんでした。

だからといって、情報がないまま賭ける必要はありません。仕様書、管理画面、API、CSV、自分のテストデータを組み合わせれば、本番前に確かめられることは増やせます。

料金は料金ページ、利用条件はAPIリファレンス、規約は原文で確認する。古い記事のバッジ色や無料枠を、そのまま信じない。実際、2026年4月には認証済みアカウントが緑のチェックマークへ統一されました。制度が変われば、過去の記事が正しくても現在は誤りになります。

移行前に確認したい13項目

「計算上一致」と「運用で実証」は別だった

MD5が自分の1件で一致したことと、数千人を問題なく復元できることは別です。

Webhookの仕様上で友だちが残ることと、本番切替で1人も影響を受けないことも別です。

この記事では前者を、調査結果として共有しました。そして冒頭に書いたとおり、その前者と後者の境目で、私は実際につまずきました。 MD5照合はテスト移行で使えないと分かり、別の方法を採ることになります。

なお、本記事は2026年7月時点の仕様と、私の環境での検証に基づきます。料金、API、規約、LINE Harnessの実装は変わる可能性があります。実行前には、必ず最新の一次情報とご自身の環境で再確認してください。