melech-buy-vs-build

購入するか、構築するか

「バックグラウンドジョブを追加して」と依頼されたエージェントは、喜んで tasks テーブル、ポーリングワーカー、リトライ用のカラム、デッドレター用のフラグを書きます。動作はします。しかし、それは BullMQ、Trigger.dev、Cloud Tasks、あるいはすでに package.json にあるキューライブラリを、下手に再構築したものにすぎず、しかも今後ずっと自分たちで管理することになります。

誰も意図的に判断しているわけではありません。リポジトリレベルのレビューで問われるのは、いつも「これはすでに自分たちのコードに存在するか」だけです。また、モデルの記憶は、外部についての質問に自信満々で答えますが、そのパッケージ名は古かったり、ときには作り話だったりします。実装を自分たちで保有するのか、それとも機能をサードパーティに任せるのかという、コストが高く後戻りしにくい判断が、根拠に基づかずデフォルトで下されてしまいます。

melech-buy-vs-build は、その判断を担います。外部に目を向け、その機能のために世の中がすでに公開しているものを、最新の情報源で検証しながら探します。そして、まず内部の確認を1つ行います。つまり、採用するか再構築するかを判断し、その機能がすでに利用中の依存関係やベンダーでカバーされているかを調べます。そのうえで、候補の絞り込みと結論を提示します。採用するか、構築を続けるかです。

「これに使える AI はある？」という問いを考えてみてください。ただし、構築するか購入するかの判断に特化し、雰囲気ではなく根拠に基づいて答えます。

---

2 つのインテント

どちらのインテントも、構築するか購入するかの判断につなげる外部調査です。どちらが発動した場合でも、まず内部の採用するか再構築するかの確認（ステップ 2）を行ってください。すでに保有している機能は、これから探したり構築したりするものより優先されます。

インテント	発動条件	目的
インターセプト	コード、計画、または差分が存在し、何かを再発明している可能性がある。	再構築されたものを特定し、既存の有力な選択肢を探し、採用するか構築を続けるかを判断します。
探索	自由形式の質問：「X には何がある？」「X の新しいツールはある？」「今、人々は X をどう実現している？」	分野の全体像を把握し、注目すべきものや最近のものを見つけ、ユーザーが選択できるよう情報を提供します。

入力からどちらのインテントか明らかな場合は、どちらに当たるか尋ねないでください。差分や提案があればインターセプトです。機能についての簡潔な質問であれば探索です。

---

すべてを左右する唯一のルール

名詞ではなく、機能を検索してください。

この調査が失敗する唯一の理由は、ユーザー独自の語彙で検索することです。ウェブで "postgres polling table worker" と検索するエージェントは、ブログ記事を見つけます。その機能を永続的なバックグラウンドジョブの実行と認識するエージェントは、そのカテゴリ全体を見つけます。

そのため、検索を始める前に、実装を業界で使われている標準的な用語に置き換えてください。

エージェントが構築したもの	実際に検索するもの
テーブル内の行＋ポーリングワーカー＋リトライ回数	ジョブキュー、バックグラウンドジョブ、永続的なタスク実行
ハンドラー登録機能付きの独自イベントバス	pub/sub、メッセージブローカー、イベントバス
ジッター付きリトライを手書きしたラッパー	リトライライブラリ、レジリエンス／バックオフライブラリ
独自のロール／権限マッチャー	認可／ポリシーエンジン、RBAC／ReBAC
Cron 風の setInterval ＋ロックファイル	ジョブスケジューラー、分散 Cron、ワークフローオーケストレーション
ウィザード用の差分比較・適用ステートマシン	ステートマシンライブラリ、ワークフローエンジン
独自の CSV／Excel エクスポートライター	スプレッドシート／シリアライズライブラリ

標準的な用語がわからない場合は、最初にその用語自体を検索します。「…の場合、何と呼ばれる？」という形で調べてください。まず語彙を正しく把握し、その後に検索範囲を広げます。

---

ワークフロー

1. Name the capability  ─►  2. Read the ground truth  ─►  3. Fan out lanes  ─────────►  4. Reduce  ─►  5. Shortlist + verdict  ─►  6. Hand off
   (canonical vocabulary)     (stack, constraints)          adopt-vs-rebuild (inward) ┐   (dedupe, kill dead)   (ask_question)
                                                            outward lanes (web)       ┴─ same concurrent batch;
                                                                                          inward hit short-circuits

1. 機能を特定する

ローカルな実装の詳細を取り除き、その仕組みが何をするのかを一行で述べてください。標準的な検索語を 2～5 個と、明らかな同義語を挙げます。検索範囲を広げる前に、これをユーザーに示してください。機能の名前を間違えると、調査全体が無駄になります。

2. 現状を把握する（インラインで実施。最初に行う）

この簡単な確認はメインスレッドで行います。これがないと、外部の各レーンに必要な情報を伝えられません。適合性を判断する制約を確認します。

• 言語とランタイム、およびマニフェストにすでに記載されている内容 （package.json、requirements.txt／pyproject.toml、go.mod、Cargo.toml、 Gemfile、pom.xml）
• すでに費用を支払っているインフラ：クラウドプロバイダー、Postgres／Redis／Kafka、 請求対象に含まれているベンダー
• 厳格な制約：セルフホストのみ、データの保存場所、ライセンス方針、 エアギャップ環境、新規ベンダー不可、予算
• 実際の規模：1日100件のジョブと1秒あたり10万件のジョブでは、候補となる ツールは異なります

この簡単な確認だけですでに明白な候補が見つかった場合、つまりその機能が文字どおり直接依存関係に含まれているか、明らかに有効化済みのベンダー機能である場合は、ここで終了して報告してください。すでに所有しているものを買いに行ってはいけません。それ以外の場合は、制約をステップ3に引き継ぎ、深掘りする導入対再構築の確認を並行して実行します。

3. 複数のレーンを並行して展開する

独立した調査レーンを並行して割り当てます。各レーンにサブエージェントを1つ割り当て、それぞれの経路で複数のウェブ検索を行います（導入対再構築のレーンは、主にローカル調査です）。レーンごとに異なるキーワードではなく、異なる種類の答えを探します。内部レーンと外部レーンは同じ並行バッチで開始し、内部確認を逐次的に実行することで遅延が増えるのを防ぎます。

レーン	探すもの
導入対再構築 (内部、優先)	ステップ2の確認を深掘りします。推移的依存関係、フレームワーク／標準ライブラリの組み込み機能、すでに要件を満たすベンダープラン、社内モノレポライブラリなどを調べます。主にローカルで調査し、必要に応じてドキュメントを絞り込んで確認します。早期終了の判断権限については、以下を参照してください。
標準的な選択肢	そのカテゴリーの標準的な名称と、比較記事で必ず取り上げられる3～8個の選択肢。Awesomeリスト、カテゴリー別のページ、「XとYの比較」のまとめ記事など。
エコシステム	このプロジェクトの言語向けのライブラリとOSS。パッケージレジストリ、GitHub、フレームワーク標準の選択肢など。
商用サービス	マネージドサービス、開発者向けツール、SaaS、クラウドのプリミティブ。誰も話題にしないような定番のクラウドソリューションも含みます。
評価	実務者の実際の意見。HN／Redditのスレッド、「Xから移行した」という話、ポストモーテム、各選択肢を後悔する理由など。
反論	独自構築が適切な場合と、既存ソリューションの既知の障害モード。このレーンで候補リストを客観的に保ちます。

探索意図の場合は、過去6～12か月にリリースされたものを調べる最前線レーンを追加します。モデルの記憶がまさに古くなっている領域だからです。

**早期終了ルール：**導入対再構築のレーンで、要件を満たす、実際に利用可能な既存の機能が確認された場合、実行を終了します。外部レーンの結果は破棄します（内部と外部の調査をゲートせず並行して実行した代償として、計算リソースが無駄になります）。すでに所有している選択肢を報告して終了し、すでに費用を支払っているものの代替を探してはいけません。

重要度に応じてレーン数を調整します。「リトライライブラリはあるか」なら3レーン、「独自のオーケストレーターを構築すべきか」なら6レーンです。ウェブサイトごとにレーンを作ってはいけません。情報源はレーンが調査する対象であり、作業単位ではありません。

ユーザーから候補名、情報源、「Xも確認して」といった指定があった場合は、他のレーンに混ぜず、専用レーンに割り当てます。

レーンの指示、検索パターン、調査先、候補行のスキーマはreferences/lanes.mdにあります。各レーンには、機能の説明、ステップ2の制約、そのレーンで調べる質問を1つ、情報源の上限、エビデンスの条件を渡してください。

4. 絞り込む

すべてのレーンを統合してから、検証または除外 → 稼働停止したものを除外 → 同一性の重複を排除 → 名前ではなくアプローチごとに分類 → ステップ2の制約への適合度で順位付け（人気は同点の場合の判断材料にすぎず、評価基準ではありません）の順に進めます。全統合ルール（稼働停止の判定基準、同一性と由来の統合、厳格な制約による除外）はreferences/lanes.mdにあります。

5. 候補を絞り込み、結論を示す

3〜6 個までに絞ってください。20 個のリストは調査結果の羅列であり、 推奨ではありません。

### ⚖️ Buy vs Build: durable background jobs (Node/TypeScript, Postgres, no new vendors)

| Option | Kind | Why it fits | Cost | What you give up | Adoption effort |
|---|---|---|---|---|---|
| `pg-boss` | OSS lib | Runs on the Postgres you already have; no new infra. | Free | Throughput ceiling vs. Redis-backed. | ~half a day |
| BullMQ | OSS lib | Mature, huge ecosystem, good observability. | Free + Redis | Requires Redis you don't run today. | ~2 days incl. infra |
| Trigger.dev | SaaS/OSS | Durable workflows + retries + UI out of the box. | Paid tier / self-host | New vendor; violates the stated constraint. | ~1 day hosted |

**Already in your stack**: none — `bull` is not installed; Redis is not provisioned.

**What no option gives you**: the per-tenant fairness rule in `worker.ts:88`.
Any adoption keeps that logic as your own scheduling layer.

**When rolling your own still wins here**: fewer than ~1k jobs/day, no fan-out,
no cross-process coordination — then your table plus a cron is genuinely less
total complexity than a queue runtime.

そのうえで、ask_question を使ってユーザーに判断を仰いでください。

1. 推奨する選択肢を採用し、手作業で実装したものを削除する
2. 採用するが、何もカバーしていない部分についてはカスタムレイヤーを維持する
3. カスタム実装を維持する（理由を記録する）
4. さらに調査する — 制約を変えるか、ほかの選択肢を検討する

自分の判断で、動作しているコードを決して削除しないでください。 このスキルは、購入か自作かの判断材料を提示し、推奨するものです。決めるのはユーザーです。

6. 引き継ぐ

• 採用する → 最小限の方法で統合するか、置き換えによって設計が変わる場合は設計を整合させます。
• 開発を続ける → 開発を進め、評価して却下した内容を記録する WHY コメントを 1 つ残し、次のエージェントが同じ議論をやり直さずに済むようにします。
• ニーズ自体が疑わしくなった → そのニーズが本当にあるのかを再検討します。
• 候補を採用する前に負荷テストが必要 → コードを書く前に候補の実証を行います。

---

エビデンスに関する約束

モデルは、自信たっぷりにもっともらしい架空のパッケージを幻覚することがあります。@vercel/queue-kit を捏造するようなら、このスキルに価値はありません。

必ずウェブ検索してください。記憶から仮説は生まれますが、候補を見つけられるのは検索だけです。

• 各候補には、今回の検索結果に実際に表示された URL を付けます。
• 各候補には、最終リリース、最終コミット、または現在の料金やドキュメントのページなど、活動状況を示す情報を付けます。
• 思い出したものの未検証の名前にはその旨を明記し、候補リストに入れる前に確認します。
• バージョン番号、料金、制限、ライセンス条件は、情報源から引用するか、省略します。推定してはいけません。
• 候補が見つからなかった分野については、正直に報告します。「このエコシステムでは信頼できるものが見つかりませんでした」も、有用な調査結果です。

---

すること／しないこと

すること： 「これはジョブキューです。標準的な用語は、バックグラウンドジョブ、永続的なタスク実行、ワークキューです。まずはこれらの用語で検索します。」

しないこと： ユーザーの言い回し（"tasks table with status column"）で検索し、何も存在しないと結論づける。

すること： まずマニフェストを確認します。「p-retry はすでに推移的依存関係として入っています。カスタムのバックオフラッパーは、その機能を 40 行で実装したものです。」

しないこと： すでにインストール済み、または費用を支払い済みの機能について、新しいベンダーを推奨する。

すること： 「このうち 3 つはすでに使われていません。最終リリースは 2021 年、リポジトリはアーカイブ済み、会社は買収され、サービスは終了しています。候補から外します。」

しないこと： 十分な調査をしたように見せるため、放棄されたプロジェクトを候補リストに加える。

すること： 「どの候補も、テナントごとの公平性ルールには対応していません。いずれにしても、その部分は独自に維持します。」

しないこと： ライブラリが対応できない部分を説明せずに、すぐに置き換えられるかのように示す。

すること： 「現在の規模なら、自作版のほうが本当にシンプルです。維持しましょう。」

しないこと： いつも「ライブラリを使うべき」と結論づける。必ず採用を勧めるスキルは、調査ではなく反射的な判断です。

すること： 候補リストを提示し、ユーザーに選んでもらう。

しないこと： より人気のある選択肢があるという理由だけで、動作しているコードを置き換え始める。