# L Harness Lab: full evidence index > LINE公式アカウント運用を、実装・移行・配信データから検証する開発元運営メディア。 Canonical catalog: https://line-harness.jp/research/ Machine-readable catalog: https://line-harness.jp/research/catalog.json Publisher: AIエージェント株式会社 Developer and editor: 野田修一 Conflict disclosure: This publication is operated by the product developer. It is not an independent review site. ## L Harnessの一斉配信は二重送信をどう抑えるか――冪等性・再試行・重複排除のコード読解 URL: https://line-harness.jp/articles/broadcast-idempotency-dedup-internals/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: 一斉配信の作成、キュー、再試行キー、複数アカウント重複排除を固定コミットのコードとテストから追跡します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 タイムアウトやCron重複が発生したとき、同じ受信者へ同じ配信を再送する経路をどこで識別し、どの層で止める設計か。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - HTTP入口のbroadcasts.tsとは別に、配信処理、retry key、複数アカウント重複排除が別モジュールへ分離されている。冪等性は単一のif文ではなく、受付・実行・再試行の複数境界で読む必要がある。 - D1側には配信キュー用migrationとbroadcastsデータアクセス層があり、UI上の作成状態と実際の送信処理を同一状態として扱わない構造になっている。 - 冪等性、retry key、dedupには対応するテストファイルが存在する。仕様を説明するときは実装ファイルだけでなく、どの入力を重複と見なすかをテストケースから確認する必要がある。 再現・追加測定の手順 - テスト用アカウントと受信者を用意する - 同じ配信IDに対する実行要求を短時間に複数回発生させる - D1のキュー状態、送信ログ、retry keyを時系列で保存する - 受信件数と内部試行回数を分けて報告する この資料だけでは証明できないこと - コード読解だけではCloudflare障害やLINE側タイムアウトを完全再現できない。 - 重複排除は正当な再送まで止める可能性があるため、誤送信率だけでなく未送信率も測定対象にする。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/routes/broadcasts.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/broadcasts.ts - line-harness-oss: apps/worker/src/routes/broadcasts-idempotency.test.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/broadcasts-idempotency.test.ts - line-harness-oss: apps/worker/src/services/broadcast-retry-key.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/services/broadcast-retry-key.ts - line-harness-oss: apps/worker/src/services/dedup-broadcast.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/services/dedup-broadcast.ts - line-harness-oss: packages/db/migrations/018_broadcast_queue.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/018_broadcast_queue.sql - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## ステップ配信の状態機械――待機時間・分岐・停止をコード上で追跡する URL: https://line-harness.jp/articles/step-delivery-state-machine/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: L Harnessのステップ配信を、登録、実行時刻、分岐、停止、送信結果という状態遷移として分解します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 利用者がシナリオへ登録されてから各ステップが実行されるまで、時刻と状態はどこに保存され、再実行時に何を根拠として進行するか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - ステップ配信は専用serviceとテストを持ち、HTTPリクエスト内だけで完結しない。実行予定時刻と現在状態を永続化してCronから再開できることが設計上の前提になる。 - DB migrationにはstep branchingとdelivery typeの追加履歴があり、直線的な順番配信から分岐・配信種別へ機能が拡張された経緯を追跡できる。 - 研究時には『登録者数』『実行対象件数』『API送信試行』『LINE側成功』『次ステップへ進んだ件数』を別の分母として扱う必要がある。 再現・追加測定の手順 - 即時・遅延・条件分岐を含む最小シナリオを作る - 各ステップ前後のD1行を保存する - Cronを重複実行し状態遷移の再現性を見る - 停止・ブロック・エラー時に次ステップが作られるか確認する この資料だけでは証明できないこと - テスト時刻を短縮した結果は長期間運用のドリフトを証明しない。 - LINE APIの成功応答と実端末での表示完了は同じ観測ではない。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/services/step-delivery.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/services/step-delivery.ts - line-harness-oss: apps/worker/src/services/step-delivery.test.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/services/step-delivery.test.ts - line-harness-oss: packages/db/migrations/005_step_branching.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/005_step_branching.sql - line-harness-oss: packages/db/migrations/009_delivery_type.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/009_delivery_type.sql - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## LINE Webhookの信頼境界――署名検証・Secret必須化・イベント保存の順序 URL: https://line-harness.jp/articles/webhook-verification-and-secret-boundary/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: Webhook受信を外部入力として扱い、署名、Secret、イベント処理、外部Webhookを分離して検証します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 受信したイベントを正規のLINEイベントと判断する前に何を検査し、検査失敗時にDB更新や自動返信が起きないことをどう確認するか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - LINE SDKのwebhook処理、WorkerのLINE受信route、一般Webhook routeが別ファイルに存在する。名称が似ていても、LINE署名検証と利用者が設定する外部Webhookは別の信頼境界である。 - migration履歴にはwebhook secret requiredがあり、Secretを任意設定から必須条件へ強化した変更を確認できる。現在仕様だけでなく、どの危険を後から閉じたかも一次情報になる。 - テストでは正常署名だけでなく、欠落、改変body、異なるSecret、再送イベントを用意し、永続化と副作用がゼロであることを確認すべきである。 再現・追加測定の手順 - 同一JSON bodyで正常署名と不正署名を生成する - Content-Typeとbody byte列を変えたケースを送る - HTTP応答、D1更新、自動返信の有無を同時に記録する - 同一イベント再送時の重複処理を確認する この資料だけでは証明できないこと - 署名検証の成功はイベント内容の業務上の正当性まで保証しない。 - 公開検証ではChannel Secretそのものをログや記事へ含めない。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/routes/webhook.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/webhook.ts - line-harness-oss: apps/worker/src/routes/webhook.test.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/webhook.test.ts - line-harness-oss: packages/line-sdk/src/webhook.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/line-sdk/src/webhook.ts - line-harness-oss: packages/db/migrations/034_webhook_secret_required.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/034_webhook_secret_required.sql - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## L Harness D1 migration進化地図――スキーマを完成形ではなく変更履歴として読む URL: https://line-harness.jp/articles/d1-migration-evolution-map/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: L HarnessのD1をmigration列から読み、配信、フォーム、複数アカウント、計測機能が追加された順序を記録します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 現在のschemaだけでは失われる互換性判断を、連番migrationと更新エンジンからどこまで復元できるか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - migrationにはentry routes、friend metadata、step branching、tracked links、forms、multi account、ad conversions、staff、broadcast queueなどが時系列で残る。製品の機能一覧をDB変更の履歴から検証できる。 - 同じ番号帯を持つmigrationも存在するため、単純な数字順だけで適用済み判定を推測してはいけない。実際の適用管理と更新エンジンのmigration処理を合わせて読む必要がある。 - 本番研究ではschemaの差分だけでなく、既存行へのdefault、index追加時間、途中失敗時の再実行、古いWorkerとの互換期間を記録対象にする。 再現・追加測定の手順 - 空DBへ全migrationを適用する - 旧リリースのschemaへ段階的に適用する - 各段階でテーブル・index・制約をdumpする - 失敗を注入し再実行とrollback可能性を記録する この資料だけでは証明できないこと - SQLite/D1のDDL制約により完全な逆migrationを作れない変更がある。 - 空DB成功だけでは既存データ量が多い環境の所要時間を証明しない。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: packages/db/migrations/003_entry_routes.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/003_entry_routes.sql - line-harness-oss: packages/db/migrations/008_multi_account.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/008_multi_account.sql - line-harness-oss: packages/db/migrations/018_broadcast_queue.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/018_broadcast_queue.sql - line-harness-oss: packages/update-engine/src/migrations.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/migrations.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## 管理APIの三重境界――認証・ロール判定・レート制限の適用順序 URL: https://line-harness.jp/articles/admin-auth-role-rate-limit/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: 管理画面APIを、ログイン確認、Owner/Admin/Staff権限、リクエスト制限という独立した防御層で読みます。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 有効なAPIキーを持つ利用者でも実行してはいけない操作をどこで止め、大量リクエストを業務権限と別にどう制限するか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - auth middleware、role guard、rate limitは別モジュールである。認証済みか、操作権限があるか、頻度が許容内かは異なる問いであり、一つの判定結果で代用できない。 - admin auth configにはテストがあり、設定不足時の挙動も検証対象としてコード化されている。安全な初期値を評価するときは正常ログインだけを見ない。 - レート制限の研究ではHTTP 429件数だけでなく、制限キーの粒度、時間窓、Cloudflare edgeの並列性、正当な一括操作への影響を測る必要がある。 再現・追加測定の手順 - Owner/Admin/Staffの最小アカウントを作る - 同一endpointへ各ロールで要求する - 同じ認証情報から並列要求を発生させる - 応答コードとD1副作用を権限・頻度別に表へする この資料だけでは証明できないこと - middleware単体テストは全routeへの付け忘れを検出しないためroute一覧監査が必要。 - IPのみを識別子にする制限は共有回線で誤検知する可能性がある。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/middleware/auth.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/middleware/auth.ts - line-harness-oss: apps/worker/src/middleware/role-guard.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/middleware/role-guard.ts - line-harness-oss: apps/worker/src/middleware/rate-limit.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/middleware/rate-limit.ts - line-harness-oss: apps/worker/src/middleware/rate-limit.test.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/middleware/rate-limit.test.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## 流入リンクをopen redirectにしない――安全な遷移先とURL tokenの検証 URL: https://line-harness.jp/articles/safe-redirect-and-url-token/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: 計測リンク、認証後遷移、予約URLで外部URLを扱う際のsafe redirectとtoken境界をコードから確認します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 利用者入力を含む遷移先を許可するとき、javascript scheme、偽装host、相対URL、改変tokenをどう拒否するか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - safe redirectとURL tokenは専用libへ分離され、safe redirectにはテストがある。リンク機能ごとに独自の文字列判定を複製しないことが監査可能性につながる。 - URLの見た目ではなくURL parserが解釈したscheme・host・pathを基準にする必要がある。example.com.attackerのような接頭辞一致は許可判定にならない。 - tokenは秘匿値とは限らない。改変検知、期限、用途、再利用可否を分け、URLへ含まれる個人識別子をアクセスログへ残しすぎない設計が必要になる。 再現・追加測定の手順 - 正常な同一origin・許可外origin・相対URLを列挙する - scheme省略や文字コードを変えた入力を追加する - tokenを1 byteずつ改変する - 拒否時のfallback先とログ内容を確認する この資料だけでは証明できないこと - 許可host自体が侵害された場合はredirect検査だけで防げない。 - 短縮URLの多段redirectは最終到達先まで別途観測する必要がある。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/lib/safe-redirect.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/lib/safe-redirect.ts - line-harness-oss: apps/worker/src/lib/safe-redirect.test.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/lib/safe-redirect.test.ts - line-harness-oss: apps/worker/src/lib/url-token.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/lib/url-token.ts - line-harness-oss: packages/db/migrations/006_tracked_links.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/006_tracked_links.sql - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## 予約とGoogle Calendarの整合性――二重予約をどの時点で再検査するか URL: https://line-harness.jp/articles/booking-calendar-consistency/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: L Harnessの予約DBと外部Calendarの二つの状態を、空き枠計算、確定直前検査、同期失敗に分けます。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 空き枠表示から確定までに外部予定が増えた場合、古い空き情報による二重予約をどこで検出し、片側だけ成功した状態をどう扱うか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - booking route、calendar route、booking-calendar-sync serviceが分離される。画面表示時の空き判定と、確定処理中の外部イベント作成は別の整合性問題である。 - 外部CalendarはD1 transactionの対象にできない。D1予約成功・Calendar失敗、Calendar成功・応答喪失などの中間状態を識別して再試行可能にする必要がある。 - 研究では成功予約だけでなく、競合、OAuth期限切れ、API timeout、同一要求再送を発生させ、残ったD1行とCalendar event IDを照合する。 再現・追加測定の手順 - 空き枠取得後に外部予定を追加する - 確定APIを同じ枠へ並列送信する - Calendar作成直後に応答失敗を注入する - D1・Calendar・通知の3状態を照合する この資料だけでは証明できないこと - Google側のeventual consistencyや利用Calendar設定で結果が変わる。 - テスト用Calendarの結果を全組織の権限設定へ一般化しない。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: apps/worker/src/routes/booking.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/booking.ts - line-harness-oss: apps/worker/src/routes/calendar.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/calendar.ts - line-harness-oss: apps/worker/src/services/booking-calendar-sync.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/services/booking-calendar-sync.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## セルフホスト更新の安全設計――preflight・snapshot・apply・verify・rollback URL: https://line-harness.jp/articles/update-engine-preflight-rollback/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: L Harness更新エンジンを段階処理として読み、更新途中で止まった場合に戻せる範囲を明確にします。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 コード、Worker Assets、D1 migrationが同時に変わる更新で、適用前検査と復旧材料をどこまで自動化しているか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - update-engineにはpreflight、snapshot、apply、verify、rollbackが独立phaseとして存在する。更新を単一のdeploy commandではなく、検証可能な状態遷移として扱っている。 - Cloudflare Worker、Assets、Pages、D1用のAPI処理が別モジュールに分かれ、失敗対象を特定できる。rollback可能性は対象リソースごとに異なる。 - D1 migrationの破壊的変更はコードversionを戻すだけでは元に戻らない場合がある。『Worker rollback成功』と『データ完全復旧』は別の結果として報告する。 再現・追加測定の手順 - 更新前versionとschemaをsnapshotする - 各phase直後に意図的な失敗を起こす - rollback後のWorker・Assets・schemaを比較する - 再度同じ更新を実行し冪等性を確認する この資料だけでは証明できないこと - 外部APIや利用者が更新中に書き込んだデータはsnapshot境界外になる可能性がある。 - rollbackテストは本番データの代替にならず、バックアップ方針が別途必要。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: packages/update-engine/src/phases/preflight.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/phases/preflight.ts - line-harness-oss: packages/update-engine/src/snapshot.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/snapshot.ts - line-harness-oss: packages/update-engine/src/phases/apply.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/phases/apply.ts - line-harness-oss: packages/update-engine/src/phases/verify.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/phases/verify.ts - line-harness-oss: packages/update-engine/src/phases/rollback.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/update-engine/src/phases/rollback.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## AIへCRM操作を渡す境界――MCPの読取・作成・送信toolを分類する URL: https://line-harness.jp/articles/mcp-write-operation-boundary/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: L Harness MCP Serverのtool群を、読取、下書き、設定変更、外部送信に分類して安全な承認点を設計します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 自然言語から呼び出されるtoolが、情報取得だけか、D1変更か、LINE利用者への外部送信かを利用者が事前に識別できるか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - MCP Serverにはlist/get系とcreate/manage/broadcast系が同居する。tool名だけで副作用強度を推測せず、HTTP method、対象endpoint、外部送信の有無を一覧化する必要がある。 - broadcast、scenario、form、rich menu、tracked link、conversationなど業務単位のtoolへ分かれるため、API key権限とAI承認をtool単位で設計できる余地がある。 - 安全性研究ではAIの文章品質より、誤った対象アカウント、件数、予約時刻を止められるか、実行前previewと監査ログが残るかを優先して測る。 再現・追加測定の手順 - 全toolをread/draft/write/sendへ分類する - 最小権限API keyで各toolを呼ぶ - 送信系には件数・対象・本文確認を挟む - 拒否・timeout・再実行時の副作用を記録する この資料だけでは証明できないこと - MCP client側の確認UIは利用環境により異なる。 - toolの説明文だけではサーバー側権限制御の代替にならない。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: packages/mcp-server/src/tools/index.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/mcp-server/src/tools/index.ts - line-harness-oss: packages/mcp-server/src/tools/broadcast.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/mcp-server/src/tools/broadcast.ts - line-harness-oss: packages/mcp-server/src/tools/create-scenario.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/mcp-server/src/tools/create-scenario.ts - line-harness-oss: packages/mcp-server/src/tools/list-conversations.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/mcp-server/src/tools/list-conversations.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## 複数LINE公式アカウントのデータ境界――account scope漏れを検査する URL: https://line-harness.jp/articles/multi-account-data-scope/ Type: 公開コードに基づく一次資料分析 Published: 2026-08-19 Updated: 2026-08-19 Description: 複数アカウントを一つの管理画面で扱う際、友だち、配信、タグ、シナリオをaccount単位で分離できるか検証します。 Disclosure: 本稿はL Harnessの開発元が、公開リポジトリの固定コミットを一次資料として分析した技術研究ノートです。第三者による独立評価ではありません。 同じD1とAPIを共有する複数LINE公式アカウント間で、検索・更新・配信対象のscopeが欠落する経路はないか。 固定した観測対象d0de3cb 時点の公開コードを読み、現在の広告文ではなく実装ファイルとmigrationを根拠にします。 コードから観測できること - multi account migration、line accounts route、cross-account token、identity keyが存在する。UI選択だけでなくDB queryとtoken検証の両方でaccount境界を維持する必要がある。 - 同一人物が複数アカウントに存在する場合、LINE user IDの一致だけで統合できない。製品内identityと公式アカウント固有識別子の関係を明示する必要がある。 - scope漏れの検証は正常取得より、account IDを欠落・改変したrequest、別accountのresource ID指定、集計endpointを重点対象にする。 再現・追加測定の手順 - 2アカウントへ同名・異IDのテストデータを作る - 各APIでaccount指定を入替える - 一覧・詳細・更新・配信を別々に確認する - 監査ログに操作accountが残るか検査する この資料だけでは証明できないこと - テストデータが完全に異なるとscope漏れに気づきやすく、本番の類似データ条件を再現できない。 - 外部LINE Platform側の権限境界はD1検査とは別に確認する。 このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。 Sources: - line-harness-oss: packages/db/migrations/008_multi_account.sql: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/packages/db/migrations/008_multi_account.sql - line-harness-oss: apps/worker/src/routes/line-accounts.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/routes/line-accounts.ts - line-harness-oss: apps/worker/src/lib/cross-account-token.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/lib/cross-account-token.ts - line-harness-oss: apps/worker/src/lib/identity-key.ts: https://github.com/Shudesu/line-harness-oss/blob/d0de3cb2173e5ad539aa4e76711dbd8cf694cc51/apps/worker/src/lib/identity-key.ts - L Harness 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## L Harness開発者本人の一次記録――公開コード・ビルド・失敗条件を検証 URL: https://line-harness.jp/articles/developer-first-party-verification-2026-08/ Type: 開発者本人による一次情報 Published: 2026-08-19 Updated: 2026-08-19 Description: 開発者・野田修一がL Harnessの公開リポジトリ、リリース、ビルドとテスト結果を、利益相反と未検証事項を含めて公開します。 Disclosure: 執筆・検証者の野田修一はL Harnessの開発者であり、運営会社AIエージェント株式会社の代表です。本記事は第三者レビューではありません。 これは利用者を装った推薦文ではなく、L Harnessを開発している野田修一本人の開発記録です。公開コードで再確認できる事実、開発環境で確認した結果、まだ証明していない成果を分けて記載します。 2026年8月19日時点の公開事実 GitHubリポジトリは2026年3月23日に作成され、観測時点で567 stars、364 forks、52 open issuesでした。既定ブランチの履歴は242 commits、公開リリースは27件で、最新リリースはv0.21.3です。数値は人気や品質を保証する評価点ではなく、同日のGitHub API観測値です。 公開コードから確認できる構成Cloudflare Worker、D1、Web管理画面、セットアップCLI、SDK、MCP Server、更新エンジンが同じ公開リポジトリに含まれています。製品表示名はL Harnessへ変更しましたが、GitHub URL、npm名、CLI名のline-harnessは互換識別子として維持しています。 開発者環境で行った再現確認 ブランド変更後のコミット候補に対し、2026年8月19日にモノレポ全体のビルドを実行しました。最初の実行はWeb側に必須のNEXT_PUBLIC_API_URLが未設定で停止しました。検証用URLを明示して再実行すると、対象11ワークスペースのビルドが完了し、リリース・migration関連を含むスクリプトテスト38件が合格しました。 この結果が示すのは「当該コミットが指定した検証環境でビルド・テストを通過した」ことです。すべての導入環境、LINE側設定、配信規模で無条件に動くことまでは意味しません。環境変数の不足で実際に一度止まったことも、導入条件として残します。 まだ成果として主張しないこと 本稿だけでは、売上増加率、作業時間の削減率、他社ツールからの移行成功率、すべての利用者の月額費用を証明できません。これらはD1、配信ログ、請求情報、導入前後の条件が揃った自社運用レポートと、本人確認済みの第三者事例に分けて今後公開します。 Sources: - L Harness公開リポジトリ: https://github.com/Shudesu/line-harness-oss - v0.21.3リリース: https://github.com/Shudesu/line-harness-oss/releases/tag/v0.21.3 - L Harness名称変更コミット: https://github.com/Shudesu/line-harness-oss/commit/d0de3cb2 - 取得時刻付きGit分析: https://line-harness.jp/git/ --- ## セルフホスト型LINE CRMの構造――データの所有者は誰か URL: https://line-harness.jp/articles/self-hosted-line-crm-architecture/ Type: 実装記録 Published: 2026-08-19 Updated: 2026-08-19 Description: L Harnessの実装を基に、SaaS型CRMとセルフホスト型CRMのデータ境界、費用、運用責任を整理します。 Disclosure: Editorial policy applies. L Harnessは、LINE公式アカウントの顧客データと配信処理を利用者自身のCloudflare環境で動かす設計です。本稿では宣伝文句ではなく、どこに何が保存され、誰が運用責任を持つのかを分解します。 観測対象を3層に分ける 構成は、LINE Messaging API、Cloudflare Worker、利用者が所有するD1データベースの3層です。アクセストークンはWorkerのSecretとして保持し、顧客属性・タグ・配信履歴はD1へ保存します。開発元の共通データベースへ顧客情報を集約するSaaS型とは、データ境界が異なります。 確認できる事実アプリケーションコードは公開リポジトリで監査でき、保存先はデプロイしたCloudflareアカウント内です。 月額0円と運用コストは分けて考える ソフトウェアのライセンス料は0円ですが、保守が0になるわけではありません。Cloudflare無料枠を超える利用料、LINE側のメッセージ通数料金、アップデート作業、障害調査は別のコストです。比較時は「ツール月額」だけでなく、データ移行性と運用担当者の時間も記録します。 再現確認の手順 - 新規Cloudflareアカウントへ検証環境を作る - テスト用LINE公式アカウントだけを接続する - D1のテーブルとWorker Secretを確認する - テスト配信後、保存されたイベントと配信結果を照合する 本番データを使う前に、削除・エクスポート・ロールバックまで確認して初めて「自社所有」と評価できます。 Sources: - L Harness公式リポジトリ: https://github.com/Shudesu/line-harness-oss - Cloudflare D1 documentation: https://developers.cloudflare.com/d1/ - LINE Messaging API: https://developers.line.biz/ja/docs/messaging-api/ --- ## LINE配信ツール移行で失敗を測る――移行観測シートの設計 URL: https://line-harness.jp/articles/migration-observation-template/ Type: 運用設計 Published: 2026-08-19 Updated: 2026-08-19 Description: 友だち数だけでは判断できないLINE CRM移行を、欠損・タグ・シナリオ・同意状態で検証する方法。 Disclosure: Editorial policy applies. 移行の成功条件は「友だち件数が合った」だけではありません。配信対象を再現できるか、同意状態を誤らないか、シナリオ途中の利用者を扱えるかまで測ります。 最低限記録する6項目 - 移行元の総件数と除外件数 - LINE userIdの有無 - タグとカスタム属性の対応表 - シナリオの現在位置 - 配信停止・ブロック・退会状態 - 移行前後の抽出条件による一致率 小さな母集団で照合する 本番一括移行の前に、状態の異なる20〜50件を抽出します。正常、属性欠損、ブロック、複数タグ、シナリオ途中を含め、移行後に同じセグメントが作れるかを確認します。 掲載方針今後、同意を得た導入企業の移行前後データを、企業名を公開する版と匿名集計版に分けて掲載します。 Sources: - L Harness移行ガイド: https://the-harness.com/line-harness-migration/ - LINE Developers: https://developers.line.biz/ja/