なぜ5人のProductlaneは、顧客対応AIをLinearの上に作ったのか

Productlaneは、Linearを基盤に据えた顧客対応ツールだ。

メール、Slack、Microsoft Teams、ライブチャットの問い合わせを一つの受信箱に集め、AIエージェントが自社のコードベースとヘルプセンターを読んだうえで一次回答する。

バグならLinearにissueを立て、修正がデプロイされたら、質問してきた顧客へ自動で返信する。

2021年に創業し、累計80万件以上の会話を処理、5人で黒字経営を続けている。出典

創業者のRaphael Fleckensteinは、自社ブログのなかで「Nothing was technically broken. The system was doing exactly what it was supposed to. The problem was the underlying assumption.」と書いている。出典

Productlaneが最初に世に出たのは2022年6月。

Linearのインテグレーションディレクトリで公開され、フィードバック収集、公開ロードマップ、チェンジログの自動生成をLinearユーザー向けにまとめた製品だった。出典

2024年10月の「Productlane 2.0」で、フィードバックと顧客対応をひとつにまとめる。

ウィジェット、アプリ内チェンジログ通知、カスタマーデータのサイドバーを追加し、サポートまでを製品の範囲に取り込んだ。出典

2025年にサポートポータル、ドキュメント、AIチャット、2026年にサポート受信箱、ライブチャット、MCPサーバー、自動ループクローズと、機能をほぼ毎月追加してきた。出典

その速度を支えたのが2026年4月の同期基盤の刷新だ。

ReplicacheからZeroへ数か月かけて移行し、クエリ単位の部分同期に作り直した。

現在は5人・黒字で累計80万件の会話を処理している。出典

顧客対応の痛みは、ツールの機能不足よりも「開発とサポートが別の場所にある」ことに起因する。

ProductlaneはLinearのissueと顧客の会話を同じスレッドで扱うため、バグ報告がそのまま開発のバックログになり、修正が顧客への返信につながる。出典

5人で累計80万件の会話を処理し、黒字を維持している事実は、この導線が実際に運用コストを下げていることを示す。出典

コードベース、ヘルプセンター、Linearのissue履歴、過去の会話という4種類の文脈を同時に参照する点が実質的な参入障壁になる。

運用するほど履歴と記事が蓄積し、エージェントの回答精度が上がるため、乗り換えコストが時間とともに上がる。出典

顧客同士が直接つながる効果は弱い。

ただしLinearのインテグレーションディレクトリ経由の流入と、導入企業の事例がSEO資産として積み上がる間接的な効果は働く。出典

Linearで開発しているB2Bソフトウェア企業で、サポート担当が数人以下のチーム。

Clerk、Bitcoin.com、Whop、Inngest、Linearity、Hero Softwareなどが導入している。出典

第一に、Linearのエコシステムに乗ったこと。

乗り換えではなく追加導入で売れるため、導入の意思決定が軽い。出典

第二に、自分たちの少人数運用をそのまま製品化したこと。

5人で80万件を処理する必要が、自動化機能の仕様そのものになった。出典

第三に、価値を「ループを閉じる」単位で定義し、解決件数で課金したことだ。出典

フィードバック管理ツールとしての出発はCannyなどとの価格競争になりやすく、差別化が薄かった。

Replicache前提の設計は大規模ワークスペースで初回同期が数分かかるなど破綻し、数か月の作り直しを強いられた。

5人体制ではSSOや監査要件など大企業向けの要求に応えにくく、ARRも非公開のため成長の持続性を外部から評価しづらい。出典

Linearユーザーへの追加導入を起点に、Intercom、Zendesk、Cannyの代替比較記事で検索流入を取り、MCPサーバーによって開発者がCursorやClaudeから自分でセットアップできる導線を用意する。

無料トライアルから月額29ドルのStarterへ入り、AI解決件数が増えるほど従量課金が積み上がる設計だ。出典

主要チャネル: content, partner, seo

業務ツールの「上」に作ると営業の摩擦が減る。

ProductlaneはLinearの利用企業に対し、既存ワークフローを変えずにサポートを足せる形で入った。

AI機能も、要約や下書きではなく顧客への返信まで含めて引き受ける単位で設計すると、価格に転嫁しやすい。出典

日本ではLinearを採用する開発組織に絞り、Slack Connect中心の共有受信箱として導入するのが現実的だ。

日本語のヘルプセンターと社内規程をMCP経由で読み込ませ、一次回答を自動化する。

ただしUIとサポートは英語前提で請求は米ドル、国内代理店も確認できないため、導入時は請求と運用体制の確認が必要になる。出典