# 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 # 本文を取得（有料は402→購入URLを出して exit 3） node tools/market-search.mjs --report --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は全部実際に走らせて出力を見る。 ---