L Harnessのアップデート方法｜forkへの取り込み・競合解消・戻し方

L 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の版で、稼働中L 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

公式ソース

• L Harness / apps/worker/src/routes/admin-version.ts — 稼働中versionと公式manifest
• L Harness / apps/web/src/components/update/update-banner.tsx — 管理画面の最新・更新可能・custom判定
• L Harness / apps/web/src/lib/update-client.ts — version/manifest取得
• L Harness / packages/create-line-harness/src/commands/update.ts — LINE公式updateとAdmin修復
• L Harness / docs/wiki/26-Manual-Update.md — custom環境の手動更新
• IG Harness / packages/create-ig-harness/src/commands/update.ts — IG公式update
• L Harness / .github/workflows/update-from-upstream.yml — fork同期workflow
• IG Harness本家 — IG upstream

関連ガイド

• L Harnessアップデート情報
• L Harness操作マニュアル
• L Harness公式ガイド