まず反論から始めます。それが正しい問いだからです。Canny と Productboard は今や同じソースを読んでいます。Canny の Autopilot は Zendesk、Intercom、Slack、Gong、Help Scout、Freshdesk、Zoom、tl;dv からフィードバックを吸い上げ、さらに G2、Capterra、Trustpilot、App Store、Google Play の公開レビューも読みます。Productboard も Zendesk、Intercom、Slack、Gong、G2、App Store、Google Play を取り込みます。両方とも見つけたものを AI でクラスタリングし、両方とも重複排除します。2つとも買うのは、同じ取り込みエンジンを二度買うように見えます。
重ならない部分こそが、このスタックが存在する理由です。Canny は顧客がログインし、投稿し、投票する board を運営し、要望が出荷されたときに投票者全員へ知らせる changelog を持ちます。Productboard の Portal はロードマップを公開しますが、これは配信面であって投票コミュニティではありません。引き換えに Productboard は優先順位付けの装置を握っています。目標に対するスコアリング、feature の定義、そして開発への引き渡しです。一方のツールは顧客が「何が重要か」を争う場所であり、もう一方はプロダクトチームが決める場所です。どちらか一方しか必要ないなら、一方だけを買ってください。このページはあなた向けではありません。
各ツールの役割
Zendesk はボリュームの供給源であり、フィードバックシステムではありません。feature 要望の大半は、別件のサポートチケットの2段落目として届き、そこで死にます。このスタックにおける Zendesk の仕事は存在し続けることです。エージェントはチケットを解決するだけで、ワークフローを一切変えません。
Canny は顧客に向いたレイヤーであり、重複排除のポイントです。Autopilot が Zendesk の会話を読み、要望を抽出し、既存の投稿があれば統合し、プロダクト領域に振り分けます。公開 board は要望が可視化され数えられる場所であり、changelog はループが閉じる方法です。
Productboard は社内のランキングレイヤーです。サポートと営業の会話を自前で取り込み、feature に紐づけ、目標に対してスコアを付け、確定した作業を Jira、Azure DevOps、GitHub、Trello、Shortcut へ送り出します。Spark はそのすべてに乗る AI レイヤーで、無料プランを含む全プランに含まれます。
Slack は、どちらのツールも開かない人たちにループを見せる場所です。Canny は新規投稿、コメント、投票の節目、ステータス変更を通知します。さらに Canny も Productboard も Slack を取り込み元として扱うため、#customer-feedback に書き込まれた要望が蒸発することはありません。
引き渡しの流れ
- feature 要望を含むチケットが Zendesk に届く → Canny の Autopilot が捕捉し、既存投稿と重複排除し、プロダクト領域へ振り分ける。
- 要望が Canny の board に現れる → 他の顧客が投票する。投票の節目とステータス変更が Slack へ流れる。
- 投稿が設定したしきい値に達する → Jira または Linear へ送られ、ステータスが双方向に同期される。
- Productboard が同じ Zendesk と Gong の会話を直接取り込み、feature に紐づけ、目標に対して優先順位を付ける。
- 作業が出荷される → Jira または Linear のステータスが Canny の投稿へ同期して戻る → Canny の changelog が投票した顧客全員に通知する。
ステップ4こそ、このスタックに穴がある箇所です。ここをごまかせば、ページの残り全部が無意味になります。Canny と Productboard の間には、どちらの方向にもネイティブ連携が存在しません。 Canny の連携ディレクトリに Productboard は載っておらず、Productboard 側にも Canny は載っていません。2026年8月16日時点で確認済みです。
対策は、両者を直接つなごうとするのをやめ、issue tracker を共通の背骨にすることです。両ツールとも Jira とネイティブに同期し、どちらも同じ issue に紐づくため、Jira のキーが公開投稿と社内 feature をつなぐ結合点になります。他の選択肢はより悪いです。Zapier や Make のブリッジは以降あなたが保守する羽目になりますし、Canny の API を Productboard の API に突き合わせる方式は、3か月目には所有者のいない小さな社内連携になります。
コストの基準線
2026年8月16日時点で確認。サポート担当8名と、ロードマップツールに書き込む必要のある4名のチームを想定します。
節約型の構成: Zendesk Suite Team が年間契約で $55/エージェント/月 ($440)、Canny Pro が年払いで $79/月、Productboard Plus が年間契約で $19/maker/月 ($76)。合計 $595/月、年間およそ $7,140 です。
より手厚い構成: Zendesk Suite Professional が $115/エージェント/月 ($920)、Canny Pro が $79、Productboard Business が年間契約で $59/maker/月、maker 2名からの最低ライン ($236)。合計 $1,235/月、年間およそ $14,820 です。Zendesk の Copilot アドオンは Professional 以上でさらに $50/エージェント/月かかり、Zendesk は AI エージェントを座席単位ではなく自動解決 (automated resolution) 単位で課金します。
フィードバック層はどちらの構成でも請求額のおよそ4分の1です。残りを決めるのはサポートの座席数であり、交渉相手のベンダーを間違える前に知っておく価値があります。
この数字が保つかどうかは、2つの課金の仕組みで決まります。Canny はチームの座席数で課金しません。Free は tracked user 25名と manager 5名、Pro は tracked user 100名以上と manager 10名、Business は 5,000名からです。ティアを押し上げるのは、追跡するエンドユーザー数の増加であって、チームの増加ではありません。Productboard は AI クレジットを maker あたり月単位で計測します。Free で 50、Plus で 250、Business で 500、Enterprise で 800 に基礎クレジット 1,500 が加わります。Spark は全プランに入っており、実際にそれを配給しているのはクレジットなので、maker 数を決める前にトライアル中の消費量を確認してください。
バリエーション
board を公開しないなら Canny を外す。 顧客が要望を見ることも投票することもないなら、Canny の重ならない側の半分は消え、ロードマップ公開は Productboard の Portal が担えます。これで年間およそ $948 を節約でき、コネクタの継ぎ目もなくなります。判断基準は、ログインして投票する顧客を具体的に名指しできないなら、すでに持っている重複排除エンジンを買っているだけだ、ということです。
チームが小さいなら Productboard を外す。 10名程度を下回るなら、優先順位付けはスコアリング用フィールドを持つ Jira か Linear に収まり、Canny と issue tracker だけでループ全体が回ります。
Zendesk を Intercom か Pylon に替える。 Canny も Productboard も Intercom をネイティブに取り込むため、引き渡しの流れは置き換えても壊れません。
このスタックが置き換えないもの
これは顧客が何をしたかではなく、何を求めたかしか教えません。行動は product adoption stack の領域です。チケットの自動解決もしません。それは AI support agent stack です。ディスカバリーの実践でもありません。投票数が測るのは、わざわざ投票する顧客の熱量であり、それはセグメントが保有する売上よりも、そのセグメントの声の大きさと相関します。CS のヘルススコアや更新管理のシステムでもありません。
対策とセットの注意点が2つあります。両ツールが独立に Zendesk を取り込むと、同じチケット群について異なる2つのクラスタリングが生まれます。 PM と CS が同じ要望について異なる件数を同じ会議に持ち込んだ瞬間、どちらの数字も信用を失います。対策は、ソースごとに記録の正本を1つに定めることです。顧客から見えるものはすべて Canny が持ち、Productboard は営業コールと社内メモに向けます。Productboard はピボットの途中です。 Hubert Palan は2026年4月15日に、同社が AI-only へ移行しチームの30%超と袂を分かち、Spark を軸に再構築すると発表しました。対策は、生の verbatim を書き出せる Canny と Zendesk に置いておき、Productboard は単独で所有していないコーパスの上に乗るランキング層として扱うことです。
このスタックが正解になるとき
公開 board が実際に票を集めるだけの顧客数があり、要望がチケットに埋もれるほどサポート量が多く、PM と CS のリードが共通のランク付きリストを持たないまま優先順位で対立していて、changelog を実際に維持する担当者がいる。そのときに選んでください。
顧客数が少なく単に電話すれば済むとき — 30社のエンタープライズアカウントに投票 board を広げてもノイズと偽の民意しか生みません — あるいはループの担当者が誰もいないときは見送ってください。要望を2年間「検討中」と表示し続ける公開 board は、最初から開かないより悪いです。それは、あなたが答えていないことの、恒久的でインデックスされ顧客から見える記録だからです。