OpenOutreach 検証：ICPを文章で書くB2Bリード生成エージェントの実像
Open-source AI agent for B2B lead generation — describe your product, it finds the people who fit, explains why each one does, and emails them from your mailbox. Self-hosted CLI, one install.
ひと目でわかる
- これは何？
- 製品説明を書くと見込み客を探し、適合理由を添えて自分のメールボックスから送信する。その仕組みと、CLIを採用する際に確認すべき境界をREADMEの記述から読み解く。
- 誰に向いている？
- 採用を検討すべきなのは、製品説明とターゲット市場を文章で定義でき、送信元メールボックスを自分で管理でき、クレジット消費の仕組みを理解した上でCLI運用を受け入れられるチームだ。逆に、既にリードリストやシーケンス配信ツールへの投資があり、判定理由の言語化を必要としない場合や、GUIでの運用を前提とする場合は適さない。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 9 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
リストを持ち込まないリード獲得という発想
一般的なコールドメール配信ツールは、送信するリストを人間が用意することを前提にしている。OpenOutreachはその前提を逆転させる。READMEによれば「Unlike a cold-email sequencer, you don't bring a list. There is nothing to upload. The input is a sentence about your product.」とあり、入力はアップロードされた名簿ではなく、製品について書かれた一文だ。対象となるのは、製品説明とターゲット市場の記述からICP（理想顧客プロファイル）を組み立て、それに照らして見込み客を評価したいが、自分でリストを収集する工数は避けたい個人や小規模チームである。もう一つの特徴は出力の形にある。READMEは「Unlike a lead database, the output is not rows.」と述べ、行の集合ではなく、人物ごとの判定とその理由を平文で返すと説明している。つまり、当たり外れの調整はリストのフィルタ操作ではなく、製品説明の書き直しを通じて行う設計になっている。
3つのパッケージが1プロセスに同居する構成
OpenOutreachは単体のプログラムではなく、オーケストレータとして位置づけられている。READMEの表によれば、発見・資格判定・エンリッチメント・CRMを担うOpenOutFindと、送信エージェント・メールボックス・送信ガードを担うOpenOutSendが別々のプログラムとして存在し、OpenOutreachがその両方をインストールして1つのプロセス、1つのデータベース、1つのオンボーディングにまとめる。重要なのは、この統合が内部メモリでの受け渡しではない点だ。READMEは「the JSON Lines still cross the boundary, they just cross it in a buffer.」と説明しており、`outfind find 50 --json | outsend`という公開されたパイプと同じ契約が、runコマンドでも維持される。理由も明記されている。特権的な近道を作れば公開された経路が形骸化するためだ。子パッケージ側はそれぞれ独自のコンソールスクリプト、設定モジュール、テストスイートを保持しており、バンドルによって機能が削られているわけではない。設定の受け渡しは`OPENOUTFIND_*`と`OUTSEND_*`という環境変数で行われ、子プログラムは実行のたびに設定を読み込み、自分では何も記憶しない。ウィザードがOpenOutreach側に存在するのは、この無記憶な設計がスクリプトやエージェントには適していても、人間には向かないからだという説明になっている。
インストールから実行までの実際の手順
導入はREADMEのQuick Startに従えば短い。`uv tool install openoutreach`でインストールし、引数なしの`openoutreach`を実行する。この1コマンドが、必要ならオンボーディングを行い、適合するリードを見つけ、検証済みの勤務先アドレスを購入し、自分のメールボックスから送信する。動作は逐次説明される。初回の規模を指定したい場合は`openoutreach run 5`のように数値を渡す。READMEの説明では、これはアドレスを持つリードを5件見つけて送信し、最大5クレジットを消費する。動詞は他にも用意されている。`openoutreach init`はオンボーディングのみを行い、クレジットを消費しない。長い2つのフィールドは`openoutreach init --product-docs product.md --target target.md`のようにファイルから渡せる。`openoutreach find 10`は資格を満たすリードを10件CSVとして標準出力に出す操作で、クレジットを消費しない。`openoutreach find 10 emails`は勤務先メール付きで取得し、こちらは1件1クレジット。`openoutreach send`は保存済みの分を送信し、`openoutreach status`は設定・ブロック・カウントの状況を表示する。状態は`~/.openoutreach`に保存されるため、中断しても失われない。再実行時に指定する数は「既に持っている数を超える分」として扱われる。
クレジット消費と停止条件の読み方
コスト設計はコマンド体系に埋め込まれている。READMEから読み取れるのは、findが無料で、emailsを付けた場合のみ1件1クレジット、runは指定した件数が上限になるという点だ。`openoutreach find 0`は追加の処理を行わず、既に持っているリードを出力する。これは現在の手持ちを確認する手段として使える。出力CSVの列は`email, first_name, last_name, company, title, website, linkedin_url, reason, lead_id, qualified_at`と定義されている。reason列の存在が、このツールの性格をよく表している。判定の根拠がデータとして残るため、後から読んで同意できない点を確認し、製品説明の記述を直す手がかりにできる。終了コードの扱いも明示されている。exit 0は要求した件数が得られたことを意味し、それに満たない場合でも行は出力され、停止した理由が示される。つまり、CSVが空であることと、処理が失敗したことは別の情報として扱う必要がある。
エージェント経由で呼び出す場合の制約
リポジトリにはClaude Code用のプラグインが同梱されている。`/plugin marketplace add eracle/OpenOutreach`と`/plugin install openoutreach@openoutreach`で導入できる。スキルは`skills/find-leads/SKILL.md`にあり、Claudeに対してどのコマンドをいつ実行するか、どのフラグがクレジットを消費しどれが消費しないか、標準出力のCSVの読み方、`error: <type>`の意味を教える。READMEは、このスキルが依頼していないアドレスを購入せず、依頼なしに送信せず、法的通知の同意を代行しないと説明している。Claude Code以外の環境でも、このスキルはCLIの契約を記述したmarkdownファイルにすぎないため、CodexやCursorなどのエージェントから同じ`find`、`send`、`run`、`status`を直接呼べる。ただし、ここで注意すべき制約がある。エージェントに渡す指示ファイルがこのスキルを参照していなければ、クレジットを消費するフラグの区別やエラー型の意味はエージェントに伝わらない。安全性はスキルの記述に依存しており、CLI自体が同意や購入を強制的に止めるという説明はREADMEにはない。
向かないケースと代替となる構成
このツールが適さない場面は明確である。既に自前のリードリストと配信シーケンスを持ち、判定理由の言語化を必要としていないチームにとって、製品説明からICPを再構築する工程は追加の作業でしかない。GUIでの運用を前提とする場合も、提供されるのはCLIのみであり、READMEに管理画面の記述はない。また、READMEは「zero platform-ToS surface」を特徴として挙げ、ブラウザレスでソーシャルネットワークのアカウントもスクレイピングも使わないと説明している。この設計は、スクレイピングやブラウザ自動化でリストを構築するツールとは根本的に異なる。代替としてREADMEが示すのは、OpenOutFindとOpenOutSendを個別に使う構成だ。`uvx --from openoutfind outfind find 10`で発見と資格判定を行い、`outfind find 50 --json | outsend`のようにパイプで送信側へ渡す。エージェント、スクリプト、あるいは独自の送信手段を持つ利用者にはこの形が向くとされている。逆に、まず試したいだけなら統合された1コマンドを選ぶ。判断の分かれ目は、公開されたパイプの両端を自分で制御したいかどうかにある。
ライセンスと更新コストの見取り
ライセンスはGPL-3.0である。自己ホストして社内で使う範囲では、この選択が直接問題になる場面は少ない。ただし、改変した版を配布する場合や、自社製品に組み込んで提供する場合は、GPL-3.0の条件に従う必要が生じる。ここでは法的助言はできないため、配布や組み込みを計画している場合は別途確認が必要だ。保守の観点では、構成が3つのリポジトリに分かれている点を考慮に入れたい。OpenOutreach本体に加え、OpenOutFindとOpenOutSendがそれぞれ独立して更新されうる。READMEによれば子パッケージは独自の設定モジュールとテストスイートを保持しており、契約は公開されたパイプだ。この分離は、片方だけを差し替えたり独自の送信側に置き換えたりできる利点がある一方、統合側の更新が子側の変更に追随する必要があることを意味する。リリース情報は取得できていないため、更新頻度や互換性の実績は本稿では判断できない。導入前に、利用中のバージョン間で`OPENOUTFIND_*`と`OUTSEND_*`の設定キーに差異がないかを確認するのが現実的な出発点になる。
編集部の結論
採用を検討すべきなのは、製品説明とターゲット市場を文章で定義でき、送信元メールボックスを自分で管理でき、クレジット消費の仕組みを理解した上でCLI運用を受け入れられるチームだ。逆に、既にリードリストやシーケンス配信ツールへの投資があり、判定理由の言語化を必要としない場合や、GUIでの運用を前提とする場合は適さない。導入前に確認すべきは、openoutreach findがクレジットを消費しないこと、find 10 emailsのようにemailsを付けた場合のみ1件1クレジットかかること、そして~/.openoutreachに保存された状態が再実行時に「既存分を超える数」として扱われるという再開仕様である。GPL-3.0のため、改変して配布する場合はライセンス条件の確認が別途必要になる。
コミュニティノート