LINEオープンチャットの投稿を自分のPCに取り込む（トーク履歴エクスポート方式）

LINEのオープンチャットに流れる情報を、自分のPCに蓄積して要約・検索できるようにする手順。 スマホから3タップで送るだけで全文が入り、以降は無人で処理される。

この指示書の価値は「動く実装」より「塞がっている道を全部先に潰してある」ことにある。 下の §1 を読まずに着手すると、通知転送やAPIの調査に数日溶ける。

---

1. 先に結論：使えない経路（再調査しないこと）

経路	結果
LINE Messaging API	オープンチャット非対応。Bot参加もWebhookも不可。公式経路は存在しない
非公式クライアント	規約違反＋アカウントBANリスク。採用しない
Android通知の転送（MacroDroid等）	大規模オープンチャットでは通知自体が来ない。実測: 端末の通知履歴24時間分を全数確認しても対象チャットは0件。他のトークの通知は正常に届いていたので配線の問題ではない。LINE側が抑制していると判断。設定では解決不能
PC版LINEの通知を読む	Windowsの通知データベースにLINE本体の通知は1件も入らない（入るのはスマホ連携アプリが中継した公式アカウントのみ）。独自のトーストウィンドウは出現するが、UI Automation で子孫要素の Name/Value がすべて空でテキストが取れない（Qt/QMLがアクセシビリティに公開していない）
PC版LINEのローカルDB	暗号化されている。鍵の抽出はアプリの保護回避になり、更新のたびに壊れる
画面OCR	通知は本文が途中で切れる・取りこぼす。壊れやすい

残るのは「トーク履歴のエクスポート」だけで、これはデータとしても最良（全文・取りこぼしゼロ）。

---

2. 全体構成

スマホ: LINEで対象チャットを開く → ≡ → Export chat history → 共有先に自分のPWAを選ぶ
                                          ↓ その場で保存完了
                          <PWA>/share が受けてパース → JSONL に追記
                                          ↓
                      毎晩のバッチ: 未処理分を安価なLLMで選別・要約 → 作り置きを更新

PC版LINEから保存した .txt を監視フォルダに置く経路も同じパーサで受ける。

前提: 自分のPCで動く PWA（Next.js等）を持っていて、スマホからHTTPSで到達できること。 （トンネルサービス等でPCのローカルサーバを公開する。この指示書はその部分を扱わない）

---

3. 入口1: Web Share Target（スマホ経路）

manifest.json

{
  "name": "<アプリ名>",
  "short_name": "<共有シートに出る短い名前>",
  "start_url": "/",
  "display": "standalone",
  "icons": [ ... ],
  "share_target": {
    "action": "/share",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
      "title": "title",
      "text": "text",
      "url": "url",
      "files": [
        { "name": "files", "accept": ["image/*", "text/plain", ".txt"] }
      ]
    }
  }
}

落とし穴（実測）

• files に同じ name で複数エントリを書かない。Chromium が2つ目を無視することがある。1エントリの accept 配列にまとめる
• short_name は共有シートに出る名前になる。有名アプリと紛らわしい名前にしない（選び間違える）
• すでにホーム画面に追加済みのPWAには、変更後の share_target が反映されない。共有先の一覧に出てこないので、一度アンインストールして追加し直す必要がある。手順書に必ず書くこと

受け口 /share

既存の共有機能（画像共有など）がある場合、壊さないように分岐を足すだけにする。

// LINEの履歴らしさを判定。該当しないものは従来のフローへそのまま流す
function looksLikeLineHistory(value) {
  const head = value.slice(0, 2048);
  return head.includes('[LINE]') &&
    /(とのトーク履歴|Chat history|保存日時|Saved on)/iu.test(head);
}

• multipart の files に .txt が来る場合と、text フィールドに本文が直接来る場合の両方を受ける
• サイズ上限を設ける（実測で2MB超・3万行のファイルが来る。20MB程度を上限に）
• 認証は既存のものを踏襲する。共有シートから開かれるので Cookie が乗る。未ログインだと取り込まれずログイン画面に飛ぶだけになるため、手順書に「先に一度開いてログインしておく」を入れる

---

4. エクスポート .txt の実フォーマット

推測で書かないこと。 実物はこうなっている（Android・英語UIで確認）:

[LINE] Chat in <チャット名>
Saved on: 8/27/2026, 8:57 PM          ← PMの直前は U+202F (NARROW NO-BREAK SPACE)

Fri, 3/13/2026                        ← 曜日略称 + カンマ + M/D/YYYY（年が最後）
21:01<TAB>送信者<TAB>本文
本文の続き（タブ区切りの時刻で始まらない行）

空行をまたいでも同じ投稿の続き
21:08<TAB>送信者<TAB>本文
21:22<TAB>送信者<TAB>[Sticker]

間違えやすい3点

1. ヘッダは Chat history in ではなく Chat in（日本語UIだと <名前>とのトーク履歴）
2. 日付行は Fri, 3/13/2026。曜日が先頭、しかも M/D/YYYY（年が最後）。YYYY/MM/DD 決め打ちだと1行も認識できず、全メッセージが捨てられて無言で0件になる
3. 本文の継続行は空行をまたぐ。空行で切ると本文が分断される

日付のパース規則（曖昧さを残さない）

• 4桁の数字が先頭なら YYYY/M/D
• 4桁の数字が最後なら M/D/YYYY（米国式）
• 曜日は「括弧付き」「カンマ+略称」「スペース+曜日名」のいずれも許容する
• Saved on: 行を日付行として拾わないこと（これも日付で始まる。曜日側は数字とコロンを含まない語に限定すると分離できる）

システムメッセージの除外

参加しました / 退出しました / joined the chat / left the chat / unsent a message などの行と、 本文が [Sticker] [Photo] [Video] [File] だけの行を落とす。過剰に落とさないよう完全一致か行頭一致に限る。

---

5. 冪等性の設計（ここが一番重要）

エクスポートは毎回「表示されている全履歴」を含む。 週1回送れば毎回9割が既出になる。

• id を sha256(チャット + 日付 + 時刻 + 送信者 + 本文) で作る
  • 日時を含めないと、同じ文言を別の日に再投稿したものが1件に潰れる
• 重複判定は保存済みの全ファイルを読んで行う。月ごとにファイルを分けているなら全月を読む（月をまたぐ重複を防げない）
• 既定で直近N日分だけ取り込む（例: 14日）。全期間を入れると要約のLLM呼び出しが跳ね上がる

実測: 2.21MB・31,166行・168日分のファイルで、17,471件を85msでパース。うち直近14日は1,489件。

---

6. 失敗したときに実物が残るようにする（設計原則）

外部が吐くフォーマットを相手にするなら、失敗検体の保存を最初から入れる。

この仕組みでは、実物を見ずにフォーマットを推測して3回失敗した。2回目に「解釈できなかったファイルを保存する」を入れたので、3回目で実物が手に入り確定できた。これが無ければ、依頼者に何度もやり直しをさせていた。

• ヘッダが読めない/対象外/解釈0件 のいずれの場合も、受け取った .txt を rejected/ に保存する
• 画面にはヘッダの1行目と認識できた日付行の数を出す。「取り込めませんでした」だけでは何も分からない
• 診断ログには本文を残さない（ヘッダ先頭数十文字までに留める）

---

7. 取り込み対象の絞り込み（プライバシー）

共有シートから何でも送れてしまうため、**対象チャットの許可リストを持ち、未設定なら全拒否（fail-closed）**にする。

// 許可リストの語がチャット名に部分一致すれば通す。戻り値は「許可リストの項目そのもの」
function allowedChat(chat) {
  const candidates = (process.env.ALLOW_CHATS || '').split(',').map(s => s.trim()).filter(Boolean);
  const target = String(chat ?? '').normalize('NFKC').trim().toLowerCase();
  return candidates.find(c => target.includes(c.toLowerCase())) || null;
}

設計上のコツ: 保存するレコードには「実際のチャット名」ではなく許可リストの項目名を入れる。 こうすると実名がディスクに残らず、かつ複数チャットを取り込んでも由来を区別できる。

さらに、この設計だとヘッダからチャット名を厳密に抽出する必要がなくなる。 allowedChat(ヘッダ行そのもの) で照合すれば、LINEのヘッダ文言が変わっても壊れない。 名前の抽出は補助に格下げしてよい。これが §4-1 の罠に対する本質的な解決策。

許可リストを広げるのは「本文をディスクに保存する対象を増やす」ことなので、勝手に足さず持ち主に確認する。

---

8. CLIから使うときの落とし穴

Next.js は route のために .env を自動で読むが、素の node script.mjs は読まない。 共通ロジックをCLIから呼ぶと、許可リストが空になり allowedChat が全件 null を返し、 夜間バッチが全ファイルを黙って拒否する。CLI側で必要な変数だけ読み込むこと。

同様に、本番サーバがビルド済みで動いている場合（next start 等）、コードを直しただけでは反映されない。 CLIはソースを直接読むので先に直り、CLIだけで検証すると「直った」と誤認する。 変更のたびに実際にHTTPで叩いて確認すること。

---

9. 鮮度の警告と催促

取り込みが「直近N日分だけ」なら、N日を超えて空くとその間の投稿は永久に入らない。人に頼る運用なので、能動的に知らせる。

• 「最後に取り込んだ投稿の日時」から経過日数を判定する。 作り置きファイルの更新時刻を見てはいけない（バッチが毎晩走る限り更新され続け、入力が枯れても警告が出ない）
• 曜日固定で必ず送るのではなく、実際に空いたときだけ送る。 きちんとやっている人に無意味な通知を送ると、そのうち全部無視される
• 同じ状態で毎日鳴らないよう、再送は数日空ける
• 通知チャネルは「すでに動いている経路」を選ぶ。Web Push は購読にスマホ側の手作業が要るので、チャットツールのDM等のほうが早く確実

---

10. テストの注意（実際にバグを隠した例）

fixture は本番が書くレコードと同じ形にすること。

タイムスタンプを ISO 文字列で書いた fixture でテストが全部通っていたが、本番は epoch ミリ秒の数値だった。 存在しない形式に対してテストが通り、実データ1,489件がある状態で「まだ1件も取り込まれていません」と表示するバグを隠していた。

同様に、fixture のテストが通っても実物では0件ということが起きる（§4）。 外部フォーマットを扱うなら、実物を1つ手に入れて通すまで「動いた」と言わない。

---

11. 依頼者に渡す手順（この粒度で書く）

システムに詳しくない人が読む前提で、タップする項目はUIの表示言語そのままで書く。

初回だけ

1. ブラウザで <PWAのURL> を開く → メニュー → Add to Home screen → Install
   • すでに追加済みなら、一度長押しして Uninstall してから追加し直す（§3の落とし穴）
2. 追加したアイコンから一度開いてログインしておく

毎回（週1回程度）

1. LINEで対象のオープンチャットを開く
2. 少し上にスクロールして過去の投稿を読み込ませる （LINE公式仕様: "Only the messages that currently appear in the chat will be saved"）
3. 右上 ≡ → Export chat history
4. 共有先から自分のPWAを選ぶ
5. 「新規 N件 / 重複 N件」と出たら完了

頻度は取り込みの保持期間の半分を目安に。保持14日なら週1回（1回飛ばしても間に合う）。