L Harnessプラグインマーケットβ版をOSS公開｜SDK・作り方・掲載方法

L Harnessのプラグインマーケットβ版は、配信・自動処理・外部連携の拡張を探し、本体とは別の場所で育てるためのカタログです。2026年9月7日にOSSのmainへ反映しました。独自コードの上書きを避ける開発環境と、最初の公式プラグインを公開しています。 公開PR #327

「その数行を、あなたのプラグインに。」

本体を少し変えて自分の運用に合わせたい。その変更を、アップデートのたびに入れ直したくない。そんな要望に対して、今回用意したのが本体の外へ独自処理を切り出す導線です。この記事では、どこで見つかるのか、何を作れるのか、どう導入するのか、作ったものをどう掲載するのかまで、公開実装に沿って説明します。

L Harness本体の導入を動画で確認する

L Harnessをこれから導入する方は、まず本体のセットアップを動画で確認できます。プラグイン開発の前に必要となる、本体導入の解説です。

L Harnessプラグインマーケットβ版で公開したもの

今回の変更は、プラグインという名前の画面を追加するだけのものではありません。探す → 作る → 動作を確かめる → 掲載を申請するまでの入口をつないでいます。

追加したもの	読者・開発者ができること
管理画面のプラグインマーケット	キーワードとカテゴリから、拡張や開発リソースを探す
本体外にひな形を作るコマンド	本体のコードを編集せず、独立したプロジェクトを始める
公式の「条件タグ付け」	条件に合う友だちへ既存タグを追加する
開発ガイド	接続、設定、動作確認、更新時の注意点を確認する
掲載申請フォーム	自作プラグインのソースと導入手順を添えて申請する
アップデートニュース	何が追加され、どこまで使えるのかを読む

The Harness Lab調べ（2026年9月7日、公開commit dc9a35ff の実装を確認）。出典：変更一覧、開発ガイド。

ここでいう「マーケット」は、導入ガイド付きのカタログです。β版には決済やワンクリック導入を含みません。ボタンを押すと第三者のプログラムが本体内で動き始める仕組みでもなく、利用者がソースと導入方法を確認して、各拡張を別途セットアップします。

マーケットはどこに、どういう形で掲載されるのか

入口は、公式サイトと利用者の管理画面の2か所です。役割が異なるため、見る場所を分けて説明します。

公式サイトは「理解して選ぶ」入口

このページが、プラグインマーケットβ版の詳しい公式記事です。トップページの最新記事、記事一覧、L Harnessの製品ガイド、アップデート情報からたどれるようにしています。

記事からは、公式GitHubの開発ガイド、プラグインのソース、掲載申請へ移動できます。導入前の担当者や開発者が、L Harnessへログインする前に内容を確認するための入口です。

管理画面は「拡張を探して導入へ進む」入口

今回のコードを含む管理画面では、サイドバーの上部に「プラグインマーケット」を追加しています。ダッシュボードにも入口を置きました。画面内では「自動化」「外部連携」「開発ツール」で絞り込めます。マーケット画面の実装

管理画面内のパスは /plugins です。管理画面を /console 配下に配置する構成では /console/plugins になります。これは自分が運用する管理画面のURLであり、the-harness.com 上に共通のインストール画面があるという意味ではありません。

GitHubは「コードを取得する・掲載を申請する」入口

ひな形、SDK、実装例は公式リポジトリから取得できます。掲載申請はGitHubのフォームから公開Issueとして送ります。申請内容を確認したうえでカタログへ追加し、管理画面のリリースに同梱して届ける方式です。カタログ定義、掲載手順

場所	主な役割	次に進む先
この公式記事	内容・対応範囲・手順を理解する	開発ガイド、公式ソース
利用中の管理画面	拡張と開発リソースを探す	各リソースの導入ガイド
公式GitHub	コードを取得し、独自開発する	動作確認、掲載申請
掲載申請フォーム	他の利用者へ届けるために申請する	内容確認後のカタログ追加

なぜ「本体の外」に置くとアップデートと共存しやすいのか

本体のファイルへ直接変更を加えると、そのファイルが公式バンドルの更新で置き換わる可能性があります。そこで、独自の条件判定や外部連携を別のプロジェクトへ移し、SDK経由で本体へ接続します。設計と運用のガイド

あなたの拡張

独立したプラグイン

独自の条件・外部API連携
別リポジトリ・別Workerで管理

SDK / API↔

公式アップデートの対象

L Harness本体

友だち・タグ・シナリオ・配信
既存の管理機能を利用

たとえば「来店回数が3回以上ならタグを付ける」という条件は、独立したプラグインに持たせます。友だちやタグの管理は本体が担います。本体を更新するときに、プラグインのファイルまで公式ソースで置き換える必要がなくなります。

ただし、コードが残ることと、必ず動き続けることは同じではありません。 本体APIの仕様や権限が変われば、プラグイン側の修正が必要になる場合があります。そのため、SDKのバージョンを固定し、本体更新前にテスト環境で接続を確認します。「一度作れば更新確認は不要」という約束はしていません。

最初の掲載物：公式プラグイン1件と開発リソース3件

初期カタログには4件のリソースを掲載しました。すべてを完成済みの業務プラグインとして数えると、できることを誤解させてしまいます。用途と完成範囲を分けます。

掲載名	種別	提供するもの	利用者が設定・実装する部分
条件タグ付け	公式プラグイン	条件に合う友だちへ既存タグを追加する処理	本体への接続、対象アカウント、タグ、独自条件
外部サービス連携スターター	テンプレート	データ同期・通知・MCP連携のコード例	接続先API、署名検証、イベント単位の重複防止など
TypeScript SDK	開発ツール	本体APIを呼び出すためのクライアント	業務に合わせた処理そのもの
L Harness MCP Server	開発ツール	AIエージェントから本体を操作する接続口	利用するAIツール側の接続設定・運用方針

The Harness Lab調べ（2026年9月7日）。件数と分類の出典：初期カタログ。連携スターターは特定の予約・ECサービスとの接続を完成させた商品ではありません。

公式プラグイン第1弾「条件タグ付け」の使い方

最初の公式プラグインは、友だちのメタデータを確認して、条件に合う人へ既存のタグを追加します。初期設定では、visitCount が数値で3以上の友だちを対象にします。実装とREADME

メタデータは、友だちに付随する独自の情報です。たとえば、別の仕組みから登録した来店回数を保存しておき、その値を条件判定に使います。このプラグイン自体が来店を検知したり、レジから来店回数を取得したりするわけではありません。対象の値は事前に登録しておきます。

タグから既存のシナリオへつなげる

タグ付けは、配信ルールの入口にもなります。L Harness側でタグ追加をトリガーとするシナリオを用意すれば、プラグインが対象の友だちにタグを付けた後、そのシナリオへつなげられます。タグ追加APIの処理

ここで大切なのは、タグを付けることが配信の開始につながる場合があるという点です。「メッセージを直接送らないプラグインだから、本番で試してよい」と判断せず、対象タグに接続しているシナリオやオートメーションも確認してください。

数行の条件変更から始められる

変更の中心になるのは src/rules.ts の matchesRule です。初期状態では次の条件を使います。

export function matchesRule(friend: RuleFriend): boolean {
  const visits = friend.metadata.visitCount
  return typeof visits === 'number' && Number.isFinite(visits) && visits >= 3
}

visits >= 3 を visits >= 5 に変えれば、判定する来店回数が変わります。メタデータの別項目を使うこともできますが、その値が実際に保存されているか、数値なのか文字列なのかを確かめてから条件を作ってください。文字列の "3" は、この初期ルールでは一致しません。条件判定のソース

初期プラグインの動作範囲

• 指定したLINEアカウントの、フォロー中の友だちを確認します。
• 対象タグをすでに持っている人は除外し、書き込み直前にも再確認します。
• 1回の確認は最大1,000件です。上限を超えた場合は書き込み前に停止します。
• 初期状態は確認モードで、定期実行も無効です。
• 条件から外れた人のタグを自動で削除する処理は含みません。
• 複数のWorkerが同じタグを同時に付ける場合の、厳密な排他はありません。

件数上限や再実行時の仕様は、公式READMEとテストで確認できます。大規模な顧客データを処理する場合は、差分同期やキュー方式への拡張が必要です。

プラグインを作る・試す・有効にする手順

ここからは、条件タグ付けの導入手順です。Node.js 22以上、pnpm、Gitを使える開発環境を用意します。既存の本番環境を直接書き換えるのではなく、まず別のフォルダで作成とビルドを確認してください。公式導入手順

1. 今回のコードを含む公式リポジトリを取得する

まだリポジトリを持っていなければ、次のように取得します。すでに本番用の作業フォルダがある場合も、検証用に別途取得すると切り分けやすくなります。

git clone https://github.com/Shudesu/line-harness-oss.git
cd line-harness-oss

コマンドの存在を確認するときは、リポジトリ内に examples/plugins/create-plugin.mjs があるかを見ます。古い配布版だけがある環境では、今回追加した作成コマンドは利用できません。

2. 本体の外へ、独立したひな形を作る

pnpm plugin:create ../my-tag-plugin
cd ../my-tag-plugin
npm install
npm run typecheck
npm run build
git init

../my-tag-plugin は、本体フォルダの隣に作る新しいフォルダです。作成コマンドは本体内への生成と、既存フォルダの上書きを拒否します。生成したプロジェクトは本体のworkspaceや親のTypeScript設定へ依存しない形に調整されます。作成コマンドの実装

このプラグインの npm run build は、配置用ファイルを確認する wrangler deploy --dry-run です。この段階で本番へ公開されることはありません。独自コードと、インストール時に生成された package-lock.json を自分のGitリポジトリで管理します。

3. 本体API・アカウント・タグを設定する

wrangler.jsonc の次の項目を設定します。Workerは、プラグインの処理を実行するための小さなサーバーの役割を持ちます。

設定	入れる内容
LINE_HARNESS_API_URL	自分のL Harness本体APIのHTTPSオリジン。管理画面の /console は付けない
LINE_ACCOUNT_ID	処理対象のLINEアカウントID
TARGET_TAG_ID	あらかじめ作成した対象タグのID
DRY_RUN	初回は文字列の "true" のままにする

APIキーはローカルの .dev.vars へ設定します。ファイルの内容をGitHubや記事、公開Issueへ貼らないでください。公開先ではCloudflare Workerのsecretとして保存します。設定ファイル、接続手順

LINE_HARNESS_API_KEY=ここに自分のAPIキーを設定

4. 確認モードで対象人数を調べる

DRY_RUN が "true" の状態で、ローカルのプラグインを起動します。

npm run dev

別のターミナルから、起動したローカルWorkerの定期処理を呼びます。

curl 'http://localhost:8787/__scheduled?cron=0+*+*+*+*'

ログの scanned は確認した件数、matched は条件に合い対象タグが未付与の候補数、applied は実際に付与した件数です。確認モードでは書き込みを行わないため、applied は0になります。ただし、接続先APIからの読み取りは行います。処理のソース

候補数が想定と違えば、対象アカウント、メタデータの項目名、数値と文字列の違い、すでに付いているタグを順に確認します。

5. テスト用アカウントでタグ付与を確かめる

設定と条件を確認したら、DRY_RUN を "false" に変え、テスト用アカウントで実行します。対象の友だちにだけタグが付くか、再実行で同じタグを付け直さないか、接続している配信が意図した動作になるかを確認します。

この確認を省いて、いきなり本番の全友だちへ適用しないでください。タグを付ける処理と、その後に起きるシナリオ配信を合わせて確認するのが導入の単位です。

6. 独立したWorkerへ配置し、必要なら定期実行する

本体とは異なるWorker名を使います。接続先と動作を確認してから、プラグインのフォルダで実行します。

npx wrangler secret put LINE_HARNESS_API_KEY
npm run deploy

毎時実行したい場合は triggers.crons を ["0 * * * *"] に変更して配置します。初期値の [] では定期実行しません。プラグインの設定と本体の配置設定を混同しないでください。初期設定と有効化

7. 停止方法も先に把握する

定期実行を止める場合は triggers.crons を [] に戻して、プラグインを再配置します。付与済みタグと開始済みシナリオは残るため、配信も止めたい場合は本体側で対象のシナリオを確認してください。処理を停止することと、処理済みの結果を取り消すことは別です。

SDKを使って、どこまで独自の処理を作れるのか

TypeScript SDKは、L Harness本体のAPIをコードから呼び出すための道具です。プラグインは、そのSDKなどを使って業務上の仕事を行う独立した処理です。今回の作成コマンドは、公開済みの @line-harness/sdk@0.24.0 を固定して生成します。SDKパッケージ、生成処理

業務ルールはプラグイン、本体の操作はAPIへ

外部サービスの契約状態を読み、L Harnessのメタデータへ反映する。条件を満たした友だちへタグを付け、既存のシナリオへつなげる。こうした仕事では、外部データをどう解釈するかをプラグイン側へ持たせ、本体の友だち管理や配信機能をAPI経由で利用できます。SDKリファレンス

これは作れる処理の例であり、特定サービスへの接続が実装済みという意味ではありません。接続先の仕様、データの対応関係、失敗時の再実行を個別に設計します。

外部サービス連携スターターを使う場合

本体リポジトリのルートで、次のコマンドを使います。

pnpm plugin:create ../my-integration integration

このテンプレートには、外部データの同期、通知、MCP連携のコード例があります。ただし、外部APIの実装、Webhookの署名検証、通知のイベント単位の重複防止などは追加が必要です。未実装のWebhookは受領済みとせず501を返し、通知例も明示的に接続するまで実行しない初期状態にしています。テンプレートのREADME、初期ハンドラー

AIへ依頼するときも、完成条件を具体的にする

AIコーディングツールに任せる場合は、「プラグインを作って」だけで始めず、対象データ、判定条件、変更先、実行頻度、停止方法を伝えます。次は依頼文の例です。

L Harnessの公式プラグインガイドと現在のソースを確認してください。
本体とは別のフォルダに、条件タグ付けを基にしたプラグインを作ります。

対象：テスト用のLINEアカウントだけ
条件：メタデータvisitCountが数値で5以上
操作：指定済みの既存タグを追加する
初期状態：確認モード、定期実行は無効
検証：対象数、対象外の除外、再実行、API失敗、停止方法

APIキーをソースに書かず、本体のファイルとDB構造は変更しないでください。
実データへの書き込みと本番配置は、設定と検証結果を確認してから行います。

この依頼文は作業範囲を共有するための例です。秘密情報をAIへ渡す必要はありません。作業前に、どのAPIを使い、どのデータが変わるのかを具体化してください。

自作プラグインをマーケットへ掲載する方法

自分の運用に合わせて作った処理を、他の利用者にも届ける入口として、掲載申請フォームを用意しました。GitHubでログインし、必要項目を記載して申請します。

申請時に必要な情報

項目	書く内容
プラグイン名・バージョン	何の拡張か、どの版を申請するか
解決する課題	誰の、どの作業を助けるものか
ソース・ライセンス	公開コードのURLと利用条件
導入・停止手順	セットアップ方法、止め方、停止後に残る状態
動作確認したバージョン	本体、SDK、実行環境、テスト内容、既知の制限
使用するAPI・データ	読み書きする情報、外部送信先、必要なキーの種類
作者・サポート窓口	質問や不具合を報告できるURL

申請項目の出典：掲載申請テンプレート。公開Issueになるため、APIキーや顧客情報は記載しないでください。 キーの「種類」を説明することと、キーそのものを貼ることは違います。

申請から掲載までの流れ

申請後に内容を確認し、カタログへ追加します。カタログはコードで管理され、管理画面のリリースに同梱されます。申請した瞬間にすべての利用者の画面へ表示されるわけではありません。掲載ルール

最初から多機能にする必要はありません。小さくても、何をするか、どのデータを扱うか、どう止めるかが明確な処理なら、他の利用者が評価しやすくなります。独自条件を数行書き換えた経験を、導入手順や制限とセットで共有してください。

公開前に把握しておく互換性・権限・費用

SDKとロックファイルを固定する

使っていたSDKのバージョンが気付かないうちに変わると、どの変更が影響したのかを調べにくくなります。生成したプラグインではSDKを固定し、package-lock.json も管理します。本体やSDKを更新するときは、型検査とビルドだけでなく、テスト環境で読み取り・書き込み・失敗時の動作を確かめます。開発・リリースの約束

カタログの「利用するデータ」は権限制限そのものではない

マーケットのカードには、各リソースが利用するデータや操作を表示します。これは機能を理解するための説明であり、APIキーの権限をプラグイン単位で狭める仕組みではありません。キーは信頼できるサーバー側で管理し、接続するコードを確認してから使ってください。マーケットの説明表示

独自のデータ保存はプラグイン側へ

通知済みのイベントや外部サービスとの対応表を保存する場合は、プラグイン専用のデータ保存先を設計します。本体のD1へ独自テーブルを追加すると、本体の変更から切り離す目的が薄れます。通知は、同じイベントを重ねて処理したときと、送信に失敗したときの両方を考える必要があります。プラグインの設計方針

LINE送信を追加する場合は、自分のL Harness本体をAPI接続先にし、本体が送信とログを管理する経路を使います。プラグインからLINEの送信APIへ直接処理を分散させる設計にはしません。

ソースの利用条件と運用費は分ける

条件タグ付けと連携テンプレートは、MITライセンスのソースとして公開しています。一方で、プラグインの実行に使うCloudflare、LINE公式アカウントの配信、接続先サービス、開発・保守の費用は別に確認してください。マーケットβ版には決済機能を実装していません。ライセンス、公式の費用説明、β版の対応範囲

どこまで動作確認したのか

公開PRでは、プラグイン作成・タグ判定の追加テスト9件、Webテスト40件、管理画面の静的ビルドを確認しました。GitHub上でも、管理画面と2種類の独立したひな形のインストール・型検査・ビルドのチェックが成功しています。公開PRと検証記録、GitHub CI実行結果

これはコードとビルドの検証結果です。すべての利用者の本体バージョン、設定、実データでの動作を保証する結果ではありません。実アカウントへの接続と配信を含む受け入れ確認は、導入先ごとに実施してください。

よくある質問

L Harnessのプラグインマーケットとは何ですか？

L Harnessの配信・自動処理・外部連携を拡張するプラグインと開発リソースを探せるカタログです。β版では導入ガイドとソースを確認し、各拡張を個別にセットアップします。

本体をアップデートしても独自変更は残りますか？

独自コードを本体外の別リポジトリ・別Workerに置けば、本体更新によるソースの上書きを避けられます。ただし、APIの仕様変更や権限変更の影響までなくなるわけではありません。更新時の接続確認は必要です。

v0.24.0へ更新すればマーケット画面が出ますか？

2026年9月7日の確認時点では、マーケットはv0.24.0の公開後にmainへ追加されています。既存のv0.24.0配布版への収録を意味しません。配布状況は公式リリースノートで確認してください。

SDKとプラグインは何が違いますか？

SDKは本体のAPIをTypeScriptから呼び出すための道具です。プラグインは、そのSDKなどを使って特定の仕事を行う独立した処理です。条件タグ付けはSDKを使うプラグインの一例です。

プログラミング経験がなくても利用できますか？

β版の導入には、コマンド実行、APIキー管理、設定ファイルの変更、Cloudflare Workerの配置が含まれます。完成した拡張の利用から始め、初回の設定とテストは技術担当者と確認するのが現実的です。

予約サービスやECとの連携は完成していますか？

今回掲載する外部サービス連携スターターは開発用のひな形です。特定サービスの完成した連携製品ではありません。接続先のAPI処理、Webhook署名検証、通知の重複防止などを追加して使います。

プラグインの利用に費用はかかりますか？

今回の条件タグ付けと連携テンプレートはMITライセンスのソースとして公開しています。Cloudflareの契約・利用量、LINE公式アカウントの配信、接続先サービス、開発・保守にかかる費用は別に確認してください。

マーケットで有料販売やワンクリック導入はできますか？

β版には決済、ワンクリック導入、プラグインの自動更新は実装していません。現在は、導入手順付きのカタログと掲載申請の仕組みを提供しています。

管理画面の見た目や表示項目も変更できますか？

今回の拡張対象はAPIで操作できる配信・自動処理・外部連携です。管理画面の表示を差し替える拡張ポイントは未実装です。

プラグインを停止すれば配信も取り消されますか？

条件タグ付けの定期実行を停止しても、付与済みのタグや開始済みシナリオは自動で取り消されません。必要に応じてL Harness本体側でも対象の配信を停止してください。

FAQの根拠：開発ガイド、条件タグ付けREADME、公開PR、v0.24.0のリリース記録。

まずは、自分のための数行から

最初の一歩は、大きな連携システムを完成させることではありません。自分の運用に必要な条件を1つ決め、確認モードで対象を調べ、テスト用アカウントで確かめる。その処理と導入手順を、本体から独立した形で残すところから始められます。

それが他の人にも役立つなら、ソース、利用するデータ、動作確認したバージョン、止め方を添えて共有してください。自分のために書いた数行を、誰かが使えるプラグインへ。 その入口として、マーケットβ版を公開しました。

• 使ってみる： 条件タグ付けの導入ガイド
• 作ってみる： プラグイン開発ガイド
• 届けてみる： マーケットへの掲載申請
• 本体を知る： L Harness公式ガイド ／ アップデート情報

この記事の一次ソースと確認範囲

この記事は、開発元が公開した実装と検証記録を基にしています。機能の説明は2026年9月7日時点のcommit dc9a35ff7a5fece0fd70a3294b2c8b06004997d1 へ固定して参照し、導入の入口には最新のmainを案内しています。

1. プラグインマーケット追加PR #327 — 変更内容、マージ日時、検証範囲。
2. 開発ガイド — 独立構成、掲載方式、対応範囲。
3. 初期カタログ — 掲載物と分類。
4. 条件タグ付け — 条件、上限、初期状態、導入と停止。
5. 独立プロジェクトの作成処理 — 本体外への生成、SDK固定、設定の独立化。
6. 掲載申請テンプレート — 申請に必要な情報。
7. GitHub CI — 管理画面と独立したひな形のチェック。
8. v0.24.0リリース — マーケット追加より前の公開配布版。

The Harness LabはL Harnessの開発元が運営する公式メディアです。第三者の利用者レビューや、導入効果の実測調査として書いた記事ではありません。著者・運営と編集基準は編集方針、開発者情報は野田修一のプロフィールを参照してください。