X Harnessの使い方｜AI投稿・返信・DM・キャンペーン・LINE連携

X Harnessで投稿、予約投稿、返信、DM、顧客管理、エンゲージメントゲート、LINE特典配布を安全に運用する方法です。 即時投稿と予約投稿を分け、対象アカウント・時刻・メディア・重複を確認して実行します。 受信確認と返信・反応を分け、相手・会話・投稿IDを固定して誤送信を防ぎます。 X上の人物をD1上の顧客データとして整理し、権限と配信対象を分離します。

この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。

最初に確認すること

• 投稿・スレッド・画像・動画・予約投稿を運用する: 一件の下書きから承認、投稿、履歴確認、必要時の取消まで安全に完了できる
• リプライ・引用・DMを一つの受信対応として扱う: リプライ、引用ポスト、DMを正しい相手と文脈に対して一回だけ処理できる
• フォロワー・タグ・ステップ配信・スタッフを管理する: 人物、タグ、配信シーケンス、スタッフ権限をIDで管理し、対象外配信を防げる
• エンゲージメントゲートとキャンペーンを設計する: 一つのキャンペーンを、条件・期限・polling・費用・重複防止まで含めて設計できる
• Xの反応条件からLINE特典配布へつなぐ: Xで条件達成した本人だけが、L Harnessのフォーム経由で特典を受け取れる

投稿・スレッド・画像・動画・予約投稿を運用する

即時投稿と予約投稿を分け、対象アカウント・時刻・メディア・重複を確認して実行します。

この工程のゴール: 一件の下書きから承認、投稿、履歴確認、必要時の取消まで安全に完了できる

投稿管理は通常投稿、返信、引用、画像・動画、スレッド、予約を扱います。予約投稿はD1へ保存され、auto_features_enabledが有効なときCronが処理します。時刻はISO 8601で保持されるため、JST表示とUTC保存を混同しないことが重要です。

投稿は取り消しても閲覧済み・通知済みの影響を戻せません。AIには必ず対象@username、本文、添付、投稿種別、実行時刻をプレビューさせ、明示承認後に一回だけ実行させます。

手順

1. 下書きを固定

本文、リンク、メディア、PR表示、返信・引用先をプレビューします。

2. 対象と時刻を確認

xAccountIdと@username、JST日時、過去時刻でないことを照合します。

3. 一回だけ実行

即時または予約のどちらかを実行し、再送防止のため返却IDを記録します。

4. 履歴で照合

D1の状態とX上のpost IDを確認し、失敗時は再投稿前に原因を特定します。

完了条件

• 対象@usernameとxAccountIdが一致
• 本文・時刻・添付を送信前に確認
• 重複投稿がない
• 返却IDとD1/Xの状態が一致

注意: 失敗応答だけを見て即再送すると、X側では成功している投稿が重複する場合があります。必ず履歴とpost IDを先に確認します。

Academy教材: XをAIから運用する / Lesson 18-1

リプライ・引用・DMを一つの受信対応として扱う

受信確認と返信・反応を分け、相手・会話・投稿IDを固定して誤送信を防ぎます。

この工程のゴール: リプライ、引用ポスト、DMを正しい相手と文脈に対して一回だけ処理できる

管理画面は受信リプライ、引用ポスト、DM会話を別画面で扱います。読み込み自体がX API課金対象になる経路があるため、更新ボタンを連打せず、取得時刻と対象アカウントを記録します。

返信、いいね、リポスト、引用返し、DMはいずれも外部状態を変更します。表示名だけで相手を決めず、投稿ID、conversation ID、participant ID、@usernameを照合します。

手順

1. 受信元を固定

対象アカウント、投稿IDまたは会話ID、相手usernameを照合します。

2. 履歴を読む

前後の会話、既存返信、対応済み状態を確認します。

3. アクションを一つ選ぶ

返信、like、repost、引用、DMのうち必要な一操作だけを下書きします。

4. 送信後に照合

返却IDと画面・X側の状態を確認し、二重対応を防ぎます。

完了条件

• 自社アカウントと相手をIDで照合
• 公開返信とDMの範囲を区別
• 既存対応を確認して二重送信を防止
• 承認した一操作だけを実行

Academy教材: XをAIから運用する / Lesson 18-2

フォロワー・タグ・ステップ配信・スタッフを管理する

X上の人物をD1上の顧客データとして整理し、権限と配信対象を分離します。

この工程のゴール: 人物、タグ、配信シーケンス、スタッフ権限をIDで管理し、対象外配信を防げる

フォロワー画面はゲート通過者や同期済み人物を管理し、タグでセグメント化します。ステップ配信はシーケンス、各メッセージ、enrollmentを分けて保存し、Cronで進行します。

スタッフはowner/admin/editor/viewerの役割を持ちます。共有の管理キーを全員で使わず、個人ごとのキーと最小権限を発行し、退職・担当終了時に無効化できる状態にします。

手順

1. 人物データを確認

x_user_id、username、first_seen、unfollowed、タグを確認します。

2. タグ設計

事実・興味・施策・状態を混ぜず、用途と解除条件を決めます。

3. ステップを停止状態で設計

遅延、action、文面、条件タグ、対象者をプレビューします。

4. 最小権限を付与

スタッフごとにroleとAPIキーを分け、利用終了時の無効化を確認します。

完了条件

• 大量API取得を避けてD1を優先
• タグの付与・解除条件が明確
• ステップ配信を対象一人で検証
• スタッフが個人キーと最小権限を使用

注意: フォロワー全件取得は課金事故の前例がある高リスク操作です。件数確認のつもりで無断実行しません。

Academy教材: XをAIから運用する / Lesson 18-3

エンゲージメントゲートとキャンペーンを設計する

リプライを入口に、いいね・リポスト・フォロー条件と特典アクションを安全に組み立てます。

この工程のゴール: 一つのキャンペーンを、条件・期限・polling・費用・重複防止まで含めて設計できる

ゲートは対象post、trigger、追加条件、action、template、polling strategy、期限を持ちます。リプライトリガーではsince_id差分とキャッシュを使い、全件走査を避けます。

hot_window、constant、manualでは呼び出し頻度が異なります。特典をLINEで渡す場合はverify_onlyを選ぶと、Cron配信ではなく受取時の一人分だけを判定できます。

手順

1. 参加条件を一文にする

対象投稿、必須キーワード、like/repost/follow、期限を明記します。

2. actionを選ぶ

mention_post、dm、verify_onlyの公開範囲と費用を比較します。

3. pollingを選ぶ

hot_window、constant、manualを期間と参加数から選びます。

4. 一人で検証

自分の検証アカウントだけで未達・達成・重複を確認してから公開します。

完了条件

• 条件・action・polling・期限が明確
• verify_onlyとCron型の費用差を理解
• 自分一人で未達・達成・重複を検証
• 緊急停止と費用監視が決まる

注意: バズ発生中の全件走査やconstant pollingは短時間で費用が増える可能性があります。期限と停止条件なしでactiveにしません。

Academy教材: XをAIから運用する / Lesson 18-4

Xの反応条件からLINE特典配布へつなぐ

verify_onlyゲート、LINEフォーム、refリンクをつなぎ、X APIの全件監視を避けます。

この工程のゴール: Xで条件達成した本人だけが、L Harnessのフォーム経由で特典を受け取れる

X HarnessはLINE接続先を保存し、キャンペーン作成時にverify_onlyゲートとLINEの受取導線を組み合わせられます。利用者がLINEフォームへX usernameを入力した時だけverify APIが条件を確認します。

Xの人物とLINEの友だちは最初から同一人物とは限りません。gate ID、form ID、ref、X username、LINE friend IDを検証記録で結び、既存友だち、新規友だち、条件未達、再訪を分けて確認します。

手順

1. 双方を固定

X Worker、LINE Worker、対象アカウント、form、ref、API keyの所有者を確認します。

2. verify_onlyを作る

対象postと条件を設定し、Cron送信ではなく受取時判定にします。

3. LINEフォームへ接続

X username入力、verify webhook、成功・失敗メッセージ、特典を設定します。

4. 四経路を検証

条件未達、達成、新規LINE友だち、既存友だちで一回ずつ確認します。

完了条件

• X gate・LINE form・refの対応が一意
• 条件未達と達成の両方を検証
• 新規・既存LINE友だちで動作
• 重複特典と全件pollingを防止

注意: X usernameの自己申告だけで高額特典を渡す場合は、なりすまし対策を別途設計します。gate IDを一般公開の秘密鍵として過信しません。

Academy教材: XをAIから運用する / Lesson 18-5

公式ソース

• X Harness / apps/web/src/app/posts/page.tsx — 投稿・スレッド・予約・履歴UI
• X Harness / apps/worker/src/routes/posts.ts — 投稿API
• X Harness / apps/worker/src/services/post-scheduler.ts — 予約投稿処理
• X Harness / packages/db/src/posts.ts — 予約投稿と履歴データ
• X Harness / packages/mcp/src/tools/posts.ts — 投稿MCP定義
• X Harness / apps/web/src/app/replies/page.tsx — 受信リプライと返信アクション
• X Harness / apps/web/src/app/quotes/page.tsx — 引用ポスト管理
• X Harness / apps/web/src/app/messages/page.tsx — DM会話UI
• X Harness / apps/worker/src/routes/dm.ts — DM API
• X Harness / packages/mcp/src/tools/dm.ts — DM MCP定義
• X Harness / apps/worker/src/routes/followers.ts — フォロワーAPI
• X Harness / apps/worker/src/routes/tags.ts — タグAPI
• X Harness / apps/worker/src/routes/step-sequences.ts — ステップ配信API
• X Harness / apps/worker/src/services/step-processor.ts — Cronでのステップ処理
• X Harness / apps/worker/src/routes/staff.ts — スタッフ権限API
• X Harness / apps/worker/src/routes/engagement-gates.ts — ゲート作成・更新・verify API
• X Harness / apps/worker/src/services/engagement-gate.ts — ゲート処理
• X Harness / apps/worker/src/services/reply-trigger-cache.ts — リプライ・フォロワーキャッシュ
• X Harness / apps/web/src/app/campaign/page.tsx — キャンペーンウィザード
• X Harness / packages/db/src/engagement-gates.ts — ゲートとdeliveryデータ
• X Harness / docs/LINE-HARNESS-INTEGRATION.md — X→LINEのE2E構成
• X Harness / apps/worker/src/routes/campaigns.ts — LINE連携キャンペーンAPI
• X Harness / apps/web/src/app/settings/page.tsx — LINE接続先管理
• X Harness / packages/mcp/src/tools/campaign.ts — create_campaign MCP

関連ガイド

• Harnessシリーズ公式ガイド索引
• X自動化ツール比較
• L Harness公式ガイド