LINE Harnessのアップデート方法｜forkへの取り込み・競合解消・戻し方
LINE Harnessの稼働版・手元・公式最新版を比較し、upstream更新を検証ブランチへ取り込み、安全に戻せる状態で更新する方法です。 稼働中・手元・公式最新版を分けて比較し、環境に合う更新方法を選びます。 検証branchとPRで本家更新をmergeし、custom差分との衝突を解決します。 Worker、Pages、D1を分けて、変更前の正常地点へ戻します。
この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。
この記事の目次
最初に確認すること
- 自分と公式のバージョンを確認してupdateする: 今のバージョンと公式最新版を自分で確認し、改造を壊さない更新経路を選べる
- 自社forkへupstreamを取り込む: mainへ直接mergeせず、更新差分だけをレビューする
- 更新失敗から戻す: 焦って変更を重ねず、サービスを最短で復旧する
自分と公式のバージョンを確認してupdateする
稼働中・手元・公式最新版を分けて比較し、環境に合う更新方法を選びます。
この工程のゴール: 今のバージョンと公式最新版を自分で確認し、改造を壊さない更新経路を選べる
最初に『何のバージョンか』を分けます。稼働中アプリ、ローカルソース、セットアップCLI、公式最新版は別物です。npm view create-line-harness versionで分かるのはインストーラーCLIの版で、稼働中LINE Harness本体の版ではありません。
LINEの本番で最も確かな現在値は、稼働中WorkerのGET /admin/versionです。公式最新版は同じWorkerのGET /admin/manifestまたは管理画面の更新表示で比較できます。管理画面は『v0.20.0（最新）』『v0.20.0が利用可能（現 v0.19.0）』のように表示します。v0.0.0-devは古いsource deploy、hash不一致はcustom buildの可能性があるため、無条件updateしません。
LINE公式updateはrelease manifest、hash、migration、Worker、Admin/LIFFを扱います。公式のままならnpx create-line-harness@latest update、Adminだけ壊れた場合は実装に存在することを確認してupdate --repair-adminを使います。custom buildやforkは運用・開発編 2の差分mergeへ進みます。
IGの現行updaterは.ig-harness-deployed.jsonを読み、D1 migration、Worker、Admin Pagesを再デプロイします。一方、LINEと同じdeployed version/manifest/hash比較はまだ揃っていません。管理画面footer、現在のdeploymentとcommit、公式package/releaseを突き合わせ、数字が一致しない場合は『判定保留』として先に実装を確認します。
2026年8月10日の本家確認値はLINE v0.20.0、IG v0.12.0です。これは教材の確認時点であり、実際の作業では必ずその場で公式情報を取得し直します。
手順
1. 環境の種類を判定
途中導入、公式のまま、古いsource deploy、自社fork/custom buildのどれかを確認します。
2. 4つのversionを表にする
稼働中アプリ、手元のsource、セットアップCLI、公式最新版を根拠付きで並べます。
3. 更新経路を選ぶ
setup再開、Admin修復、公式update、forkの差分mergeから一つだけ選びます。
4. 変更内容を先に確認
release notes、migration、Worker、Pages、LIFF、自社改造への影響と戻し方を確認します。
5. updateとスモークテスト
承認後に更新し、管理画面・Webhook・検証ユーザー一人の主要動線を確認します。
完了条件
- アプリ版とCLI版を混同しない
- 現在版と公式最新版を根拠付きで比較
- vanilla・途中導入・customで更新経路を分岐
- 更新後の管理画面とWebhookが正常
注意: 最新versionの数字だけを見て実行しません。hash不一致や自社forkを公式updaterで上書きすると、独自改造を失う可能性があります。D1のbackupとrollback地点を確認してから更新します。
Academy教材: 本家の更新を安全に取り込む / Lesson 8-1
自社forkへupstreamを取り込む
検証branchとPRで本家更新をmergeし、custom差分との衝突を解決します。
この工程のゴール: mainへ直接mergeせず、更新差分だけをレビューする
カスタマイズ用forkではoriginとupstreamを分け、upstream/update-日時 branchへmergeします。自社の新機能を同じPRへ混ぜません。
手順
1. 差分確認
fetch後、commit、files、migration、package変更を確認します。
2. 検証branchへmerge
conflictを意味単位で解決します。
3. PRとCI
全検査後に更新専用PRを作ります。
完了条件
- 更新専用branchが作成
- conflictの判断理由が記録
- CI成功後にPR化
Academy教材: 本家の更新を安全に取り込む / Lesson 8-2
更新失敗から戻す
Worker、Pages、D1を分けて、変更前の正常地点へ戻します。
この工程のゴール: 焦って変更を重ねず、サービスを最短で復旧する
コードrollbackとDB rollbackは別物です。additive migrationなら旧Workerへ戻せるかを先に判断します。破壊的な逆migrationを即実行しません。
手順
1. 影響停止
配信やCronを止める必要があるか判断します。
2. 正常deploymentへ戻す
Worker/Pagesを既知の正常版へ戻します。
3. DBを評価
schema変更はデータ保全を優先して別途判断します。
完了条件
- 新規変更より復旧が優先
- Worker/PagesとD1が別判断
- 復旧後の主要動線確認
Academy教材: 本家の更新を安全に取り込む / Lesson 8-3
公式ソース
- LINE Harness / apps/worker/src/routes/admin-version.ts — 稼働中versionと公式manifest
- LINE Harness / apps/web/src/components/update/update-banner.tsx — 管理画面の最新・更新可能・custom判定
- LINE Harness / apps/web/src/lib/update-client.ts — version/manifest取得
- LINE Harness / packages/create-line-harness/src/commands/update.ts — LINE公式updateとAdmin修復
- LINE Harness / docs/wiki/26-Manual-Update.md — custom環境の手動更新
- IG Harness / packages/create-ig-harness/src/commands/update.ts — IG公式update
- LINE Harness / .github/workflows/update-from-upstream.yml — fork同期workflow
- IG Harness本家 — IG upstream
関連ガイド
Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。