要点（30秒で）: 顧客データをAIに埋めさせたいなら、まず「確信度スコア」を出力させるのをやめたほうがいい。Comp AIがMITで公開したCRMは、モデルに自信を語らせず、何を見たかの種類だけを記録させる設計になっている。リポジトリを覗いて、evidence.md の分類表だけでも自分の実装に持ち帰る価値がある。

この記事の内容（約12分で読めます）

1. 自社用に作ったものを、そのまま投げた
2. エージェントはCRMの機能ではない
3. 「自信」ではなく「何を見たか」を書かせる
4. 一枚のページを二つに数えない
5. 18のツール、4つのスキル、1つのスケジュール
6. 砂場には回線も鍵も置かない
7. 7,164スターの裏側
8. 皮肉が一番効いている場所
9. 動くかどうかは別の話
10. 巨人たちは別の場所を走っている
11. 日本・個人開発の視点
12. 要点まとめ
13. 出典・リンク

セールスの現場でAIを使うと、たいてい同じ場所で転ぶ。肩書きも所属も、それらしい文章としては完璧なのに、事実として間違っている。しかも記録された瞬間、それが推測だった痕跡は消える。

コンプライアンス自動化のスタートアップComp AIが7月31日に公開したCRMは、この一点だけを執拗に潰しにいった設計をしている。公開から1週間で7,164スター、739フォーク。ライセンスはMIT。

自社用に作ったものを、そのまま投げた

Comp AIはもともとSOC 2やISO 27001、GDPRの取得を自動化する会社で、VantaやDrataの代替を名乗るオープンソース企業だ。本業のプラットフォーム（trycompai/comp）はAGPLv3のオープンコアで運営している。

今回公開されたのは、その会社が自分たちの営業のために社内で作っていたCRMだ。共同創業者のLewis Carhart氏はX上で「Comp AIで自分たち用に作ったCRMをオープンソースにすることにした。エージェンティック・ファーストというのは文字通りの意味だ」と書いている。

Next.js App RouterとNestJS、Prisma＋Postgres、認証はBetter Auth。ビルドはBunとTurborepo。ホスティングはVercelを前提にしている。

確信度スコア方式と証拠の等級方式の対比。Comp AIのCRMは左を捨て、右だけを残した。

エージェントはCRMの機能ではない

READMEの中心にあるのは一行の主張だ。エージェントはCRMの機能ではなく、CRMのほうがエージェントのメモ帳である、と。

言葉遊びに聞こえるが、実装はこの通りになっている。リサーチ用エージェントは独立したデプロイとして動き、自分のスケジュールで、自分の作業キューに対して働く。次に何を見るかを自分で決め、フォローアップを自分で予約し、リサーチ予算を使い切ったら止まる。ブラウザを閉じても走り続ける。

つまり画面は結果を眺める窓でしかない。データベースは、エージェントが調べたことを書き留めておく場所として存在している。AIに何かを覚えさせる設計の難しさは何も消さないのに忘れる——AIの記憶を畳む426トークンのOptMemでも触れたが、ここでの答えは単純明快で、記憶を圧縮する代わりにRDBに書く。

一つの観測が記録になるまで。証拠の等級で「更新」と「人間への提案」に分かれる。

「自信」ではなく「何を見たか」を書かせる

技術的にいちばん面白いのはここだ。エージェントの指示書には、確信度を出力させないという方針が明記されている。モデルは自分の確からしさを正しく採点できない、という前提に立っている。

代わりに導入されているのが証拠の等級だ。エージェントが報告できるのは観測の種類だけで、たとえば profile.email-match（保有しているアドレスがプロフィールに表示されている）、crm.signature-block（本人の署名欄に書かれた肩書き）、crm.meeting-attendance（カレンダー招待の承諾）、github.account-identity といったラベルが用意されている。

これらは一次証拠として、そのままレコードを書き換える。一方で web.cited-claim（URL付きでそう書いてあるページがある）や handle.name-form（ハンドル名が本名に似ている）は補助証拠に分類され、単独では事実にならず、人間に確認を求める「提案」として溜まる。

「CRMがエージェントの副産物」という構成。画面は窓、DBは調べたことを書き留める場所。

一枚のページを二つに数えない

分類ルールも細かい。一つの観測は一つのエントリだと定められていて、名前と会社名が一致するGitHubプロフィールは github.account-identity 一件であって、二件の証拠ではない。ドキュメントには、分割すれば一枚のページを二重に数えて偽の確信を作ってしまう、と書かれている。

矛盾も潰さない。情報源が食い違ったときは部分的な真実として平均せず、未解決のまま人間に回す。スキルファイルにはこんな一文がある。「提案という結果が正解であることは多い。線を越えさせるために追加の証拠を探しにいってはいけない。それが、間違った答えが正しい答えの服を着る経路だ」

思想を一行に凝縮したのが、指示書に書かれた次の言葉だ。空欄より、自信満々の間違いのほうが悪い。誰にもそれが間違いだと分からないから。

18のツール、4つのスキル、1つのスケジュール

エージェントの中身は、18の自作ツールと4つのスキル、そして1つのディスパッチスケジュールで構成されている。ツールは read_crm_history、search_crm、identify_contact、research_person、enrich_company、record_fact、schedule_recheck といった粒度で切られている。

スキルはバージョン管理されたMarkdownで、evidence.md、identity-matching.md、data-boundaries.md、writing-a-brief.md の4本。振る舞いのルールをコードではなく文書として持たせる、いま各社が採用しつつある形だ。

ディスパッチは dispatch.ts 一本で、Postgresの FOR UPDATE SKIP LOCKED によるリース方式を使う。複数のディスパッチャが同時に走っても、互いに重ならない仕事を掴む。

砂場には回線も鍵も置かない

土台はVercelが6月17日に公開したエージェントフレームワークeveだ。会話そのものを耐久ワークフローとして扱い、各ステップをチェックポイントする。クラッシュしてもデプロイを挟んでも、止まった場所から再開できる。Apache-2.0で公開されている。

CRM側はその上に、かなり厳しい隔離を敷いた。エージェントのシェルはサンドボックス内で動き、ネットワークはdeny-all、データベースの認証情報も持たない。理由は身も蓋もなく、顧客のメール本文を外に持ち出せないようにするためだ。

もう一つ割り切っているのが、マルチテナントを作らないという判断だ。単一テナントを前提に organizationId を排し、複雑さだけが増えて価値がないと切って捨てている。自分たちのために作った、という出自がそのまま設計に出ている。

7,164スターの裏側

ここから先は、褒めるだけでは済まない部分だ。GitHubのAPIを見ると、リポジトリの作成は7月31日、直近1週間のコミットは123。コントリビュータは実質2名で、carhartlewis氏が117、ripgrim氏が15、あとは1コミットが一人とボットが一つ。

Hacker Newsに8月2日に投稿されたスレッドは13ポイントと伸びず、並んだコメントは辛い。READMEが要領を得ず些細な誤りだらけだという指摘、二日で1,000スターが付くAI slopへの懐疑、そして「コーディングエージェントがあれば誰でも作れるものだ」という切り捨て。

擁護らしい擁護も混ざっていて、二日で48,000行を書いた人間にREADMEを書く時間はなかっただろう、という趣旨のコメントが付いている。この行数は投稿者の見立てであって公式の数字ではないが、リポジトリ直下に27個ほどの開発用スキル（shadcn、nestjs-best-practices、no-use-effect……）が置かれている構成を見ると、コーディングエージェントを総動員して一気に書き上げたのは間違いない。

皮肉が一番効いている場所

最も刺さった指摘は、CONTRIBUTING.mdをめぐるものだ。この文書には、貢献は人間が書いた文章の形で欲しい、同僚にSlackで話しかけるように非公式に投げてほしい、と書かれている。さらに続けて、一段落のアイデアをAIに膨らませて正式な提案書にしないでほしい、その一段落こそが有用な部分だったのだから、と。

その方針を掲げたリポジトリのREADME自体がAIの手つきをしている——HNのコメント欄はそこを突いた。これは意地悪ではなく、いま多くのチームが同時に踏んでいる地雷でもある。コードは機械に書かせ、判断は人間が持つ、と言ったときの境界線が、まだ誰にも引けていない。

動くかどうかは別の話

第三者による初期のコードレビューも出ている。explainxの分析は、アーキテクチャの土台は健全だとしたうえで、空の catch {} がリースや確定処理の失敗を握り潰していること、ステータスとリースが食い違ったタスクが宙ぶらりんになりうること、ディスパッチループの観測性が足りないことを挙げ、顧客データを預ける前に手当てが要ると結論づけている。

つまり現時点のこれは、製品というより参照実装だ。トップページの trycrm.ai にも価格表もホスティングもなく、「フォークしろ。あなたのものだ」とだけ書いてある。導入は git clone から bun install、docker compose up、bun run dev の流れで、必須の環境変数は認証まわりの4つだけ。APIキーが一つも無くても起動し、キーを足すたびに調査経路が一つ増える。

巨人たちは別の場所を走っている

比較対象を並べると位置がはっきりする。SalesforceのAgentforceはARR 8億ドル、前年同期比169%増という規模まで来ていて、Atlas Reasoning Engineが顧客のSalesforce環境の内側で行動を実行する。HubSpotは2026年春のSpotlightでAgentic Engagement Objectを発表し、Attioは信号を自動で拾って人手なしにレコードを更新すると謳う。

オープンソースの側では、Twenty CRMがAGPL-3.0で45,500スターを超え、クラウド版はClaudeやChatGPTから叩けるMCPサーバを備える。機能の厚みでも成熟度でも、Comp AIのCRMはこの列に並べる段階にない。「書かないのが最高のコード」——44000スターponytailの正体でも書いたとおり、スターの数は成熟度の指標ではない。

それでも見る価値があるのは、大手が「エージェントがCRMを操作する」方向に進んでいるのに対して、こちらは「CRMがエージェントの副産物である」という逆側から入っているからだ。Futurumの2026年第1四半期の調査では、企業の39%が生成AIはタスクを自動実行するエージェントの形で届くと見ている。その届き方の設計案が、いま複数あるということになる。

日本・個人開発の視点

日本の小さなチームにとって、このリポジトリの使いどころは「CRMを乗り換える」ことではないと思う。むしろ、証拠の分類表と予算の切り方という二つの部品だけを抜き出して、自分の業務ツールに移植するほうが早い。

問い合わせ管理でも採用管理でも、AIに項目を埋めさせる場面は同じ構造をしている。そこで確信度0.87という数字を保存する代わりに、「本人の署名に書いてあった」「検索結果にそう出ていた」というラベルを保存するだけで、後から人間が検算できるようになる。実装コストはほとんど変わらない。

そしてもう一つ、単一テナントで割り切るという判断は、一人や数人で作る側にこそ効く。エンジニア1人と1万ドルで”オフィス”が建った——GenOfficeの正体と同じ流れで、自分たちのためだけのソフトウェアを丸ごと持つ選択肢が現実的になってきている。

要点まとめ

• Comp AIが7月31日にMITで公開した「エージェント前提」のCRM。1週間で7,164スター、739フォーク、TypeScript、実質2名で123コミット。
• 中核はリサーチ用エージェント。独立デプロイ・独自キュー・調査予算を持ち、ブラウザを閉じても走り続ける。土台はVercelのeve。
• 確信度スコアを出力させず、観測の種類（署名欄、会議出席、メール一致など）だけを記録させる。強い証拠はレコードを更新し、弱い証拠は人間への提案になる。
• サンドボックスはネットワーク遮断＆DB認証情報なし、マルチテナントは意図的に不採用という割り切った設計。
• 一方でHacker Newsでは「AI slop」との批判、空のcatchなど耐久性の穴も指摘済み。いまは製品ではなく参照実装として読むのが正しい。

出典・リンク

• 出典: https://github.com/trycompai/crm
• Comp AI CRM 公式サイト: https://trycrm.ai
• Comp AI（コンプライアンス本体、AGPLv3）: https://github.com/trycompai/comp
• Vercel「Introducing eve」: https://vercel.com/blog/introducing-eve
• vercel/eve リポジトリ: https://github.com/vercel/eve
• Hacker News「CRM: An open-source, agentic-first CRM」: https://news.ycombinator.com/item?id=49141847
• explainx.ai によるコードレビュー記事: https://explainx.ai/blog/comp-ai-crm-agentic-open-source-eve-2026
• Trendshift リポジトリ統計: https://trendshift.io/repositories/99983
• Twenty CRM（オープンソースCRM比較用）: https://github.com/twentyhq/twenty
• Salesforce Agentforce / HubSpot Breeze の動向: https://communicateonline.me/insights/hubspot-salesforce-race-towards-agentic-crm/