前の記事(調査編)の最後に、私はこう予告しました。

「MD5照合はテスト移行で使えないと分かり、別の方法を採ることになります」

この記事は、その答え合わせです。UTAGEから LINE Harnessへの本番移行を、2つの公式LINEアカウント・合わせて友だち約5,000人の環境で実行しました。

先に結論を並べます。

切替作業そのものは数分で終わりました。しかし既存友だちは自動では1人も戻らず、2週間かけて戻ったのは実質2割です。MD5照合は、ハッシュの特定が正しかったにもかかわらず使えませんでした。そしてインフラの実測値は、事前見積の30倍を超えていました。

うまくいった話だけを書くつもりはありません。前編で立てた13項目の予想がどこまで当たり、どこが外れたのか。移行を検討している事業者さんが「自分の場合はどうなるか」を見積もれる材料として使ってください。

ハヤラボ(HAYALAB)の自己紹介カード
もくじ[ タップで開閉 ]
  1. 1切替は数分。実作業は丸1日だった
  2. 2既存友だちは、自動では1人も戻らない
  3. 3MD5照合が使えなかった、本当の理由
  4. 4タグは「復元」ではなく「取り直し」だった
  5. 5ブロックは増えず、配信数は測れなかった
  6. 6インフラ実測は、見積の30倍超だった
  7. 7まとめ:13項目の答え合わせ

切替は数分。実作業は丸1日だった

「LINE Harnessの乗り換えなら、Webhookを変えるだけですぐ終わるのでは?」

前編で立てた計画のとおり、移行は「切替」方式で実行しました。アカウントはそのまま、Webhookの向き先だけをUTAGEからLINE Harnessへ変える方式です。

Webhookの差し替えから疎通確認(Verify)の成功までは、数分でした。ここだけ見れば、拍子抜けするほど簡単です。

ただし、その日の実作業は丸1日かかりました。時間を食ったのはWebhookの前後にある周辺作業です。

時間を食ったのは、Webhookの外側

  • 登録経路URLの張り替え — 片方のアカウントだけで16本。もう片方もYouTube・インスタグラム・TikTok・ブログ・HPに散らばっていました
  • リッチメニューの移設 — 旧ツール側で設定していたメニューの作り直し
  • LIFFアプリの差し替え — 申込みフォーム等の向き先変更
  • ステップ暴発ガードの実装 — 既存友だちに新規向けシナリオが誤って飛ばないようにする安全装置

前編の結論「移行の仕事は、Webhook変更の前後にある」は、そのまま的中しました。むしろ想定より「前後」が重かった、が実感です。

2件目は、段取りを変えて楽になった

1件目のアカウントは深夜作業になり、確認のやり取りが3往復も発生しました。

そこで2件目は、必要な情報をすべて1通にまとめてから作業を始める形に変えました。同じ作業でも、進行はまるで違いました。

切替を複数アカウントでやるなら、1件目は「段取りの実験台」と割り切る
2件目からの改善分が、本当の作業時間です。

既存友だちは、自動では1人も戻らない

既存友だちは自動では戻らない。一斉配信のタップで登録され、2週間で実質2割が戻った実測図解
「切り替えたら、友だちデータも引き継がれるんですよね?」

ここが、この記事でいちばん重要な実測です。

Webhookを切り替えた直後、LINE Harnessのデータベースに載っていた友だちは、両アカウントともわずか十数人でした。約5,000人の友だちがいるのに、です。

友だち自体は公式LINE側に残っています。前編で書いた「Webhook切替なら友だちは減らない」は正しかった。しかし、LINE Harnessがその友だちを認識するのは、本人がタップや送信などのアクションをした瞬間です。

つまり「友だちは残る」と「ツールから見える」はまったく別の話でした。

ここを誤解すると計画が崩れます
切替直後のLINE Harnessは、ほぼ空の状態から始まります。既存友だちへのセグメント配信は、本人がアクションしてデータベースに載るまでできません。「切替日から今までどおり運用できる」前提で計画を立てないでください。

復元の実測:翌朝1割、2週間で実質2割

復元のペースは、実測でこうなりました。

時点データベースに載った友だち
切替直後ほぼゼロ(十数人)
翌朝約1割
2週間後実質約2割

正直に書くと、私の肌感は「1週間で3割くらい戻った」でした。ところが今回、データベースをAPIで数え直したら、実質2割です。

「実質」と付けたのには理由があります。片方のアカウントで、タグも登録経路もない空のレコードが約270件見つかりました。移行作業の副産物として混入したデータで、実在の友だちではありません。これを差し引いた数字が2割です。

肌感と実測のズレ、そして集計の水増しに気づけるか。前編で書いた「計算上一致と運用で実証は別」は、復元率の集計にもそのまま当てはまりました。

戻らない8割は「損失」なのか

8割が戻らないと聞くと、失敗に見えるかもしれません。ただ、運用して分かったことがあります。

戻ってくるのは、メッセージを開き、ボタンを押す人。つまりアクティブな友だちから順に戻ってきます

結果として、反応のない相手への配信が減り、無駄な配信数も減りました。公式LINEの配信料は通数課金なので、これはコスト面のメリットでもあります。

復元率2割は「友だちを8割失った」ではありません
公式LINE側に友だちは残っていて、反応した人から順にツールへ載る。リストの新陳代謝と捉えるかは、運用方針しだいです。

MD5照合が使えなかった、本当の理由

「結局、MD5の何がダメだったんですか?」

前編の山場だった「32桁のIDはMD5で一致した。ただしこの結論は、後に覆った」の種明かしをします。

先に結論です。ハッシュの特定は、正しかった。 UTAGEの「アカウント共通LINE友だちID」がLINE UIDのMD5であることは、その後の検証でも揺らぎませんでした。

使えなかった理由は、照合の前後が両方塞がっていたからです。

鍵を取り出すAPIに、触れなかった

照合するには、まず全友だちのUID一覧が必要です。認証済みアカウントならfollowers APIで取得できる、と前編で書きました。

ところがこのAPIには、チャネルアクセストークンが必要です。そして前編で自分が立てたルールが、ここで効いてきます。

「準備中にアクセストークンを再発行しない」——再発行すれば、UTAGE側の配信が本番切替の前に止まるからです。

つまり、トークン再発行の禁止(11項目め)を守った結果、followers API(4項目め)が封じられました。チェックリストの項目同士が衝突したわけです。

鍵を挿す穴が、存在しなかった

仮にUIDが全部揃っても、次の壁がありました。

LINE Harnessには、友だちレコードを外部から作成するAPIがありません。友だち一覧のAPIは取得専用で、登録の入口はWebhookイベントだけ。移行用に見える機能も、実体は「本人が友だち追加したときに自動でマッチングする」設計でした。

照合リストを作れても、流し込む先がない。これが「MD5照合は使えない」の正体です。

引っ越し方式なら、ハッシュ以前の問題です
今回とは別に「引っ越し」方式(新しいアカウントへ移す方式)も1件検証しました。LINEのUIDはプロバイダー単位で発行されるため、アカウントが変わるとUIDそのものが別物になります。この場合、MD5照合は理屈の上でも成立しません。タグの機械的な引き継ぎは不成立と確定し、ゼロからの取り直しになりました。

タグは「復元」ではなく「取り直し」だった

では、実際にどうやって既存友だちをLINE Harnessに載せたのか。

答えはシンプルで、照合をあきらめて、本人にタップしてもらいました

一斉配信のアンケートが、登録装置になる

移行当日の夜、属性を選んでもらうアンケートを全友だちへ一斉配信しました。

ポイントは、一斉配信がLINE純正の配信APIを使うことです。LINE Harnessのデータベースに載っていない友だちにも届きます。

そして受け取った本人がボタンをタップした瞬間、Webhookが発火します。その1タップで、UIDの登録と属性タグの付与が同時に完了します。

初日だけで、2アカウント合計450人以上が回答しました。タグは「旧ツールから復元」したのではなく、本人の自己申告で取り直したことになります。

既存友だちへの「ステップ暴発」は、設計で止める

このやり方には副作用があります。既存友だちがタップした瞬間、ツールからは「新規登録」に見えるため、新規向けのステップ配信が起動しかねません。

実際、タグの有無で配信を止める条件設定が、意図どおりに機能しない場面がログで確認できました。最終的には、条件分岐に頼らずシナリオの起動設定そのものを外すことで止めました。

既存友だちの取り込みは「一斉配信 → 本人のタップ」が現実解
ただし新規向けシナリオは、条件で防ぐのではなく物理的に止めてから配信する。

ブロックは増えず、配信数は測れなかった

移行でいちばん恐れていた「切替をきっかけにブロックが増える」は、起きませんでした。

切替方式はアカウントが変わらないため、友だちに移行を告知する必要がそもそもありません。友だち総数も切替前後でほぼ横ばいでした。

測れなかった数字は、測れなかったと書く

一方で、取れなかった数字もあります。

  • 配信ごとの成功数 — 一斉配信はLINE純正APIを経由するため、送信数がツール側で取得できない仕様でした。過去の配信もすべて未集計です
  • 母数全体に対するブロック率 — データベースに載った友だちの中のブロック率(2〜5%程度)は取れますが、約5,000人の母数に対する率は算出できません

実測を売りにする記事だからこそ、ここは正直に書いておきます。この2つは、今回の構成では測れません。

インフラ実測は、見積の30倍超だった

「無料枠でいけるって話じゃなかったの?」

前編の費用の章で、私はCloudflare D1の無料枠(読み取り1日500万行)に対して「本番前に実測して、必要なら月5ドルの有料版へ上げる」と書きました。

答え合わせをします。運用中の全アカウント合算で、読み取りは1日約1.3億行でした。

事前の見積は1日300〜400万行。実測はその30〜45倍、無料枠の約27倍です。

「念のため有料化」ではなく「有料化が必須」だった

D1の無料枠を超えると、追加課金ではなくクエリが止まります

つまり無料枠のまま切り替えていたら、初日でツールごと停止していました。移行前に有料化していたのは「念のため」のつもりでしたが、結果から見れば必須条件でした。

無料枠の見積は、桁で外れます
ボット型のツールは、1通の受信や1回の配信判定のたびに大量の読み取りが走ります。「友だち数×配信数」のような素朴な見積は、桁単位で外れました。月5ドルの保険を惜しんで本番を止めるのは、割に合いません。

なお、月5ドルの有料化を含めても、ツール利用料の月額約2.2万円と比べれば費用構造は大きく変わりません。費用の全体像は、前編の「費用の3層」の整理をご覧ください。

まとめ:13項目の答え合わせ

前編の最後に載せた「移行前に確認したい13項目」を、本番の実測で採点します。

#項目結果
1Webhook切替方式か◯ 切替で実施。差し替え自体は数分
2照合できるID列があるか△ 特定は正解。ただし実運用では使えず
3ID変換を自分で再検証したか◯ 再検証したから「使えない」と分かった
4followers APIの可否を見たか× トークンに触れず、取得を断念
5Cloudflareの有料化基準を決めたか◯ 有料化は必須だった(見積の30倍超)
6新旧のステップ通数を比べたか- 配信数が取得できず比較不能
7AI応答がReplyかPushか◯ 個別Pushは無効IDで失敗しうると判明
8アカウントごとに情報を分離したか◯ 分離を維持。副作用の空レコードは除外
9タグ衝突を防ぐ設計か△ 条件分岐が効かず、起動の物理停止で対処
10旧Webhook URLを控えたか◯ 切り戻しは使わずに済んだ
11トークン再発行を禁止したか◯ 守った。代償としてfollowers APIを失う
12配信が落ち着く切替日か◯ 施策の谷間に実施
13小さいアカウントから試すか◯ 1件ずつ実施。2件目は段取りを改善

13項目のうち、まるごと外れた予想はありません。ただし「当たっていたのに使えない」(2・4・11の連鎖)が起きたのが、今回の移行のいちばんの教訓です。

移行を検討している事業者さんへ

この実測から、判断材料を3つに絞ります。

実行編の結論
  1. 既存友だちは自動では戻らない。2週間で実質2割を前提に、一斉配信で「本人にタップさせる」設計まで含めて移行計画にする
  2. タグは復元ではなく取り直し。アンケートを移行当日の目玉施策として用意しておく
  3. インフラの無料枠見積は桁で外れる。月5ドルの有料化を最初から前提にする

MD5の顛末を一行でまとめれば、こうなります。

後編の結論
ハッシュの正体は当てた。でも、鍵を取り出すAPIと、鍵を挿す穴が両方塞がっていた。既存友だちを戻す方法は「一斉配信して本人にタップしてもらう」以外になく、2週間で戻ったのは実質2割。それを前提に組んだ移行計画だけが、本番で機能します。

なお、本記事の数字はすべて私たちの環境(2アカウント・計約5,000人・切替方式)での実測です。復元率や使用量は、友だちのアクティブ度と配信設計で大きく変わります。あなたの環境の見積の「出発点」として使ってください。

おしらせ

移行の判断材料、そろえます

UTAGEからの乗り換え判断は「金額」ではなく「移行後も運用が続くか」で決まります。この2本の記事で書いた調査と実測は、あなたの環境でも再現できる手順です。
公式LINEの導線設計や移行の相談は、ハヤラボまでどうぞ。

ハヤラボに相談する →