AIに「完成済み指示書マーケット」を自動で読ませ、自動で出品させる指示書

AIエージェント（Claude Code / Cursor / Codex CLI 等）に、開発依頼を受けた瞬間に 「マーケットに既にある指示書を探して読む」を強制し、セッション終了時には 「今日得た汎用ノウハウを出品する」まで自動でやらせるための実装指示書。

チーム全台に配る仕組み（hook 登録・skill 配布）と、公開マーケットへ社内情報を 漏らさないための送信禁止スキャンまで含む。これを読ませれば、参照から出品、 全台配布までを AI が一気に作れる。

---

1. 何を作るのか（全体像）

3つの部品と、それを全台へ配る導線を作る。

部品	役割	起動タイミング
検索CLI	マーケットの全件を取得しローカル採点で関連順に並べる	手動 + hook から呼ばれる
参照 hook	ユーザーの依頼文を見て「使える指示書」を候補としてコンテキストへ注入	依頼受領時（毎回）
出品CLI	汎用ノウハウを審査キューへ投稿。秘密情報・社内固有情報を検出したら送信中止	セッション終了時

---

2. 検索CLI（参照の土台）

2.1 サーバー検索に頼らず、全件取得＋ローカル採点にする

多くのマーケットAPIの検索は、エージェント用途では次の理由で使えない。実測で確認すること。

• 複数語を渡すと AND が厳しすぎて 0 件になる（例: q=Discord 通知 → 0件。実際には タイトルに両方入っている出品が存在する）
• 依頼文をそのまま渡すと当然 0 件
• sort=roi 等は関連度を完全に無視するので、1語だけで検索しても無関係な高ROI出品が上位に来る

対策: q=（空）で全件を1回だけ取得し、ローカルで採点する。出品数が数百件規模までは 1リクエストで足り、24時間キャッシュすれば実質ネットワークゼロで動く。

2.2 採点の作り方（日本語で形態素解析なしに効かせる）

1. 依頼文からトークンを作る
   • ASCII 語: /[A-Za-z][A-Za-z0-9_+-]{1,}/g を小文字化（2文字以上）
   • 日本語: /[ぁ-んァ-ヶ一-龠々ー]{2,}/g で連続を取り出し、各連続から長さ2と3の文字n-gramを生成する （これで「通知」「売上」「毎朝」のような語が形態素解析なしで拾える）
   • 依頼の定型語（ください お願い して したい 作って 等）はストップワードとして除外
2. 出品側の haystack を重み付きで持つ: タグ×3 / タイトル×3 / 概要×2 / カテゴリ×1
3. トークンが部分一致したらその重みを加点（同一トークンは1フィールド1回まで）
4. 0点は捨てる。並べ替えは 得点降順 → ROI降順 → 読込トークン昇順

検証は「期待する1位」を書いた表で行う。例:

依頼文	1位に来るべき出品
毎朝チャットへ売上を通知するbotを作って	日報通知Bot
スクリプトの実行を毎回手で押さずに自動化したい	実行自動化テンプレ
会食のお店を探して提案してほしい	会食提案の秘書
全く関係ない雑談	0件（何も出さない）

これを満たすまで採点の重みを調整する。サーバー検索のまま実装すると全部外れるので、 必ずこの表でテストしてから次へ進む。

2.3 CLI の口

node tools/market-search.mjs "依頼文をそのまま"          # 関連順に一覧
node tools/market-search.mjs --raw <slug>               # 本文を取得（有料は402→購入URLを出して exit 3）
node tools/market-search.mjs --report <slug> --saved N  # 削減実績を報告
node tools/market-search.mjs --categories               # 出品時に使うカテゴリ一覧

• キャッシュは <設定ディレクトリ>/.market-cache.json に24時間。壊れていたら黙って捨てて作り直す
• 検索処理は export async function findRelevant(text, options) として関数化し、hook から再利用する （CLI とロジックを二重に書かない）

---

3. 参照 hook（人間が何もしなくても候補が入る）

エージェントの「ユーザー発話を受け取った時」に走るフックとして実装する。

1. stdin の JSON から発話を読む
2. 実装系の依頼かを判定（作って 実装 構築 セットアップ 自動化 連携 bot スクリプト cron デプロイ build implement automate などの部分一致）。短すぎる発話・ スラッシュコマンドだけの入力は対象外
3. findRelevant(発話) を タイムアウト4秒で呼ぶ
4. 得点が閾値未満の候補は注入しない（弱い部分一致だけで割り込むとノイズになり、毎回コンテキストを汚す）
5. 候補（3件まで）をコンテキストへ注入する。文面は「ゼロから設計する前に本文を読め」＋ タイトル・無料/価格・読込トークン・本文URL・取得コマンド・実績報告コマンド・「無関係なら無視してよい」

事故らないための必須条件

• 例外を絶対に外に出さない。JSON が壊れていても、ネットが切れていても、必ず終了コード0で静かに終わる
• 同一セッションで同じ出品を繰り返し注入しない（注入済みを状態ファイルに保存し、古い記録は7日で掃除）
• 1セッションの注入回数に上限を設ける（3回程度）
• コンテキスト注入する hook を非同期（fire-and-forget）で登録しない。多くのホストは 非同期フックの出力を捨てるため、注入が黙って無効になる

---

4. 出品CLI（セッション終了時に自動で投稿する）

4.1 APIキーは人間に取らせない

出品APIのキーが「メールアドレスに紐づく決定的な値」なら、初回利用時に エージェント自身が発行して保存できる（人間の作業ゼロ）。メールの取得順は 環境変数 → 保存済み設定 → エージェントのログインアカウント情報 → git config user.email。 取得できたら <設定ディレクトリ>/market.env に権限600で保存し、以後は再発行しない。

4.2 送信禁止スキャン（全自動出品の唯一の安全弁）

公開マーケットへ無確認で送るなら、ここが唯一の関門になる。厳しめに作る。 1行ずつ、以下のパターン名付きで判定し、1件でも当たったら 送信せず下書きへ退避して終了コード2を返す。

パターン名	例
APIキー	sk-… ghp_… AIza… AKIA… Bearer <20文字以上> -----BEGIN … PRIVATE KEY----- eyJ….（JWT）
Webhook URL	チャットサービスの …/api/webhooks/… 系
社内ドメイン	自社のメールドメイン・社内Wikiのホスト・VPN/メッシュのホスト名
クラウドの固有プロジェクト参照	://<ランダム15文字以上>.<サービス>.co 形式
ドキュメントのリソースID	表計算・文書・フォルダのURLに含まれる25文字以上のID
ID設定行	spreadsheetId scriptId folderId 等の近傍にある40文字以上の文字列
メールアドレス	実在ドメインのメール（example.com 等のプレースホルダだけは許可）
電話番号	市外局番付きの形式
ユーザーパス	%USERPROFILE% 相当の実パス（個人名が漏れる）
社内固有名	自社・グループ会社・自社ブランドの表記（定数リストで持つ）

• 報告に値そのものを出さない（マスクしてから表示する）
• プレースホルダだけの行は誤検知させない。ただし実値が同じ行に混ざっていたら検出は残す
• 誤検知が避けられない時のために「パターン名を指定して個別許可」できる口を付ける（既定は何も許可しない）

4.3 出品の手順

1. ローカル検証（タイトル/概要/本文の最小文字数、カテゴリがAPIの一覧に存在するか）
2. 本文の SHA-256 を出品ログに突き合わせ、同一内容なら投稿しない（重複出品防止）
3. POST /listings に Authorization: Bearer <キー> で投稿
4. 投稿ログ（日時・タイトル・カテゴリ・submissionId・状態・本文ハッシュ）を追記
5. --dry で payload を確認できるようにする

---

5. セッション終了手順に組み込む

エージェントの「セッションを閉じる」手順書に、成果の永続化と残TODOの間へ次を挿入する。

• 判定: 他人の環境でも再現できる汎用手順か。 出品する = 新しい仕組みの作り方 / hook・skillの型 / 外部API連携 / 失敗パターンと回避策。 出品しない = 社内データの集計結果 / 単発の調査 / 特定顧客の案件対応 / 既出品と同義のもの
• 重複確認: 検索CLIで同義の出品が既にないか見る
• 一般化が絶対条件: 社名・顧客名・個人名・メール・リソースID・URL・ローカル絶対パスを すべてプレースホルダへ置換する。置換を忘れてもスキャンが止めるが、スキャンは最後の砦であって設計ではない
• トークン見積り: ゼロから作った場合と、この指示書を読ませた場合の消費を実績から見積もる
• 送信禁止スキャンに当たったら（終了コード2）、一般化して書き直すか出品を諦める
• 出品したら1行で報告する。出品しなかった時も「出品対象なし」と1行書く（黙って飛ばさない）

---

6. チーム全台へ配る（ここが一番壊れる）

配布は「日次で正本リポジトリを取得し、hook を登録し、手順書を各PCへ配る」形にする。 実装時、以下の3つは実際に踏んだので必ず先に潰すこと。

6.1 手順書（skill）が実は配られていない

「リポジトリを更新する」処理と「エージェントが読むディレクトリへ手順書を置く」処理は別物。 前者だけ実装して満足すると、新しい手順書も更新も永久に届かない。 配布関数は次の性質を持たせる。

• 内容が同一なら書かない（毎日タイムスタンプだけ動くのを防ぐ）
• 上書き前にバックアップを1つ残す
• 正本に無いローカル固有の手順書は絶対に削除しない
• 更新した名前をログに1行出す

さらに、正本が各PCより古いことがある。配る前に「正本 vs 実機」を必ず差分確認する。 古い正本をそのまま配ると、改善済みの手順書を巻き戻して全台に配ってしまう（実際に起きかけた）。

6.2 起動判定が symlink/junction で外れ、CLIが「無言で何もしない」

import.meta.url === argv[1] のような文字列比較で「直接実行か」を判定してはいけない。 配布パスが symlink/junction（例: ホーム直下の名前が実体は別ディレクトリ）だと判定が外れ、 main() が一度も呼ばれず、出力ゼロ・終了コード0で終わる。手順書に書いたコマンドが まさにその経路だと、全員が「何も起きない」状態になる。

対策: 判定を共通関数に切り出し、realpath で解決したうえで比較（Windows は大文字小文字を無視）。 同じ判定をしている全ファイルを一括で置き換える。

6.3 取得の失敗が、配布と hook 登録まで巻き添えにする

「リポジトリ取得 → 手順書配布 → hook登録」を1つの try に入れると、 取得が1回失敗した端末は以後ずっと配布も登録もされない（ログ1行だけで無言）。 取得の失敗はネット断・認証切れ・未追跡ファイルの衝突などで普通に起きる。

対策: 取得だけを独立した try/catch にし、失敗しても配布と登録は続行する。 失敗はログファイルだけでなく標準出力にも出す（起動時に人が気づける）。

6.4 おまけ: 非同期関数の中で強制終了しない

処理を async function main() に包んだのに内部で process.exit() を呼ぶと、 top-level await の評価中に強制終了してランタイムがアサーション失敗でクラッシュすることがある （Windows の Node で実測: UV_HANDLE_CLOSING のアサーション）。早期終了は return にする。

---

7. 完了条件（ここまで実行して初めて「できた」と言う）

1. 期待1位テーブル（2.2）が全行一致する
2. hook: 実装依頼で候補が注入され、無関係な発話では無出力、壊れたJSONでも終了コード0
3. hook 登録が冪等（2回実行しても1本だけ・非同期フラグが付いていない）
4. スキャン: 汚いサンプルで全パターン検出＋終了コード2 / きれいなサンプルで0件＋終了コード0
5. 手順書配布: ①新規コピー ②同一内容なら書かない ③ローカル固有を消さない ④上書き前にバックアップ
6. 取得を意図的に壊した偽環境で、配布と hook 登録が完走する
7. symlink/junction 経由の起動で、実パス経由と同じ出力になる
8. 出品は --dry で payload を確認し、その後に実投稿して審査キューに入ったことを確認する

「たぶん動く」で完了報告しない。1〜8は全部実際に走らせて出力を見る。