「検討します」で終わらせない。顧客の声を、理由付きの対応判断へ変える仕組み

営業担当者が、大口顧客から新しい機能要望を聞く。

商談メモには残した。Slackにも投稿した。プロダクトチームにも口頭で伝えた。しかし、その後どうなったのかは分からない。

一方、カスタマーサクセスには、別の顧客からよく似た相談が届いている。サポートにも同じ問題が来ている。ただし、表現が少しずつ違うため、同じ課題として集計されていない。

顧客には、とりあえず「社内で検討します」と返す。

ところが、誰が評価し、誰が決め、いつ回答するのかは決まっていない。数か月後に担当者が変わると、なぜ対応しなかったのかも分からなくなる。

こうした問題は、単に「顧客の声が一か所に集まっていない」から起きるわけではありません。

本当の問題は、顧客の声を、比較可能で説明可能な対応判断へ変換する業務プロセスがないことです。

この記事で考えるのは、要望を投稿して投票するだけのフィードバックポータルではありません。

営業、CS、サポートなどに分散した顧客の発言を、解決すべき問題へ整理し、顧客への影響、事業価値、実現性、リスクを評価して、対応するかどうかを理由付きで決める。そして、その結果を顧客へ返し、実施後に本当に問題が解決したかまで確認するサービスです。

つまり、目指すのは「顧客要望を集める仕組み」ではなく、顧客要望の対応判断を管理する仕組みです。

顧客要望の管理を、ツール導入だけでなく、業務フロー、判断権限、AIの責任境界、データ設計、開発工程まで含めて見直したい企業向けに、要件定義・業務設計・システム開発の支援を行っています。

本記事は、企業にある具体的な業務課題を起点に、状態、権限、AI、安全性、技術、検証条件まで設計するシリーズの一部です。

顧客の声は集まっているのに、なぜ何も決まらないのか

多くの企業は、顧客の声をまったく集めていないわけではありません。

営業は商談記録を残しています。CSは定例会の議事録を作っています。サポートには問い合わせ履歴があります。フォーム、メール、CRM、Slack、スプレッドシートにも情報が残っています。

それでも、対応判断が進まない。

原因は、情報量の不足というより、情報が別々の業務の途中で止まっていることです。

顧客要望に関わる仕事は、少なくとも次の段階に分かれます。

• 顧客が述べた内容を記録する

• 発言の背景や発生条件を理解する

• 解決すべき問題を定義する

• 対応案を考える

• 投資するかを判断する

• 顧客へ説明する

• 実施後に効果を確かめる

これらは、すべて別の業務です。

要望一覧を作るだけでは、最初の一部しか完了しません。

情報が部門ごとに分断される

営業が聞くのは、商談や更新交渉の文脈にある要望です。

CSが聞くのは、顧客が業務で使い続けるなかで感じる摩擦です。

サポートが受け取るのは、操作できない、期待どおりに動かない、回避策が分からないといった具体的な困りごとです。

どれも重要ですが、部門ごとに記録方法と目的が違います。

同じ問題が、営業では「新機能要望」、CSでは「業務改善要望」、サポートでは「操作上の問い合わせ」として保存されることもあります。

一か所にコピーするだけでは、この違いは解消しません。

必要なのは、元の発言を残しながら、複数の発言が同じ問題を示しているのかを整理する工程です。

「検討します」の後に、判断工程がない

顧客へ「検討します」と返すこと自体が悪いわけではありません。

その時点で、技術的に可能か、他の顧客にも影響するか、戦略と合うか、いつ提供できるかが分からないなら、即答しない方が適切です。

問題は、その後です。

• 誰が追加情報を集めるのか

• 誰が問題を定義するのか

• 誰が事業価値を評価するのか

• 誰が技術評価をするのか

• 誰が最終的に決めるのか

• いつ再評価するのか

• 誰が顧客へ返すのか

この流れが定義されていなければ、「検討します」は保留ではなく、事実上の放置になります。

声の大きさが優先順位に変わる

明確な判断工程がないと、代わりに分かりやすい数字や権力関係が使われます。

投票数が多い。要望件数が多い。契約金額が大きい。営業担当者の発言力が強い。経営者が気に入っている。

これらはすべて判断材料になり得ます。

しかし、どれも単独で最終判断を代替できません。

声の大きさと、解決すべき問題の重大さは同じではないからです。

実装した後も、仕事が閉じない

さらに見落とされやすいのが、実装後です。

機能をリリースした。

社内では「対応完了」になった。

しかし、要望を出した顧客へ知らせていない。顧客は新機能の存在を知らない。使い方が分からない。そもそも顧客が困っていた問題と、実装した機能がずれている。

これでは、開発タスクは完了しても、顧客の問題は解決していません。

顧客が言ったこと、要求した機能、解決すべき問題は別物である

このサービスで最初に守るべき原則は、顧客の発言を一つの「要望」に潰さないことです。

少なくとも、次の3つを分けます。

Customer Voiceは、顧客が実際に述べた内容

Customer Voiceは、顧客の原文や、その発言があった事実です。

たとえば、顧客が次のように話したとします。

この発言には、顧客の業務や困りごとを理解するための重要な情報が含まれています。

一方で、発言を記録する側が、勝手に意味を補ってはいけません。

原文、発言日時、顧客、接点、担当者、参照元を保持し、後から確認できる状態にします。

Requestは、顧客が提案した具体的な解決方法

顧客は、困りごとと一緒に解決策を提案することがあります。

これは具体的な機能要望です。

Requestとして保存すべき重要な情報ですが、まだ「作るべき仕様」が確定したわけではありません。

顧客は自社の状況には詳しくても、プロダクト全体の利用状況、既存アーキテクチャ、他の解決方法、法務・セキュリティ条件まで把握しているとは限らないからです。

Problemは、企業側が調査して定義する解決対象

複数の発言、利用状況、発生頻度、回避策などを確認すると、問題は次のように表現できるかもしれません。

これがProblemです。

Problemとして定義すれば、解決方法を「一括ダウンロードボタン」に固定せずに済みます。

たとえば、次の選択肢も比較できます。

• ZIPでまとめて取得する

• 定期的にメール送付する

• APIで会計システムへ連携する

• 指定ストレージへ自動保存する

• 請求書一覧から複数選択できるようにする

顧客が提案した機能を尊重しながら、解決策の選択肢を広げられます。

私が重要だと考えているのは、ここです。

顧客の言葉を軽視してはいけない。しかし、顧客の言葉をそのまま仕様書にしてもいけない。

顧客の発言は、問題を理解する一次情報です。

顧客が提案した機能は、解決案の一つです。

何を解決すべきかを定義し、どの方法を採用するかを判断する責任は、提供企業側にあります。

投票数や大口顧客だけで決めると、判断を誤る

顧客要望管理では、投票数や要望件数がよく使われます。

分かりやすく比較できるため、使うこと自体は合理的です。

ただし、投票数をそのまま優先順位へ変えると、判断を誤る可能性があります。

投票していない顧客にも、同じ問題がある

顧客が要望を投稿するには、その問題を認識し、言語化し、投稿場所を見つけ、時間を使って送信する必要があります。

困っているすべての顧客が行動するわけではありません。

投票数は「問題を持つ顧客数」ではなく、特定の方法で声を上げた顧客数です。

製品内の行動データ、サポート履歴、離脱理由、顧客インタビューと組み合わせて解釈する必要があります。

少数でも重大な問題がある

セキュリティ、法令、アクセシビリティ、データ消失、業務停止に関わる問題は、報告件数が少なくても重大です。

利用者が少ないから後回しにしてよいとは限りません。

反対に、要望件数が多くても、影響が軽微で回避策があり、実現コストが非常に高い場合もあります。

大口顧客の要望は重要だが、全体最適とは限らない

契約金額や解約リスクは、事業判断として無視できません。

ただし、大口顧客の個別要望を積み重ねると、プロダクトが特定企業向けに複雑化することがあります。

保守負荷が増え、他の顧客にとって使いにくくなり、将来の開発速度も低下するかもしれません。

契約額は判断材料の一つとして扱い、戦略整合、対象市場、再利用可能性、技術負債、機会費用と一緒に評価すべきです。

単一スコアは疑似客観性を生む

顧客数、売上、工数、戦略整合などへ点数を付け、合計スコアで決める方法もあります。

比較を助ける点では有効です。

しかし、異なる性質の情報を一つの数値へまとめると、判断の前提が見えにくくなります。

「82点だから採用」と表示されても、なぜ82点なのか、どの条件が変われば結論が変わるのかは分かりません。

このサービスでは、少なくとも次の評価を分けて保持します。

Customer Impact

• 影響する顧客数・利用者数

• 発生頻度

• 深刻度

• 業務停止の有無

• 回避策の有無

• 満足度、解約、新規受注への影響

Business Evaluation

• 事業戦略との整合

• 対象市場の広さ

• 売上や継続率への影響

• 差別化

• 契約上の義務

• 機会費用

Technical Evaluation

• 実現可能性

• 開発・移行工数

• アーキテクチャへの影響

• 技術負債

• 性能

• 運用・保守負荷

• 外部依存

Risk Evaluation

• 法務

• プライバシー

• 情報漏えい

• 誤操作

• 顧客への誤解

• 将来互換性

• ベンダーロックイン

• 組織運用負荷

必要なら各項目を数値化しても構いません。

ただし、数値は判断を助ける表示であり、判断者そのものではありません。

必要なのは、収集から効果確認まで閉じた判断フローである

対応判断管理サービスでは、次の流れを一つの追跡可能な業務として扱います。

Customer Voice
→ Request／Problem
→ Customer Impact
→ Evaluation
→ Decision
→ Customer Response
→ Delivery
→ Outcome Review

それぞれを順番に見ていきます。

1. Customer Voiceを原文と出所付きで受け付ける

営業、CS、サポート、フォーム、メール、既存システムからCustomer Voiceを登録します。

必須情報を増やしすぎると利用されないため、最初の登録は短時間で終えられる必要があります。

正本では、CSがVoiceを登録する時間のP75を3分以内とする仮説を置いています。

これは確認済みの市場標準ではありません。パイロットで検証する運用仮説です。

登録時には、少なくとも次を保持します。

• 顧客

• 発言日時

• 接点

• 原文または原文参照

• 登録者

• 機密区分

• 元システムのIDやURL

2. RequestとProblemを切り分ける

顧客が提案した機能はRequestとして残します。

その背後にある問題は、複数Voiceを比較しながらProblemとして整理します。

一つのVoiceが複数Problemに関係する場合もあれば、複数Voiceが一つのProblemを示す場合もあります。

したがって、単純な一対一関係ではなく、元発言とのリンクを失わないデータ構造が必要です。

3. 顧客影響を確認する

Problemへ関連付く顧客、利用者、契約、発生頻度、深刻度、回避策を確認します。

ここで重要なのは、件数だけでなく、影響の性質を見ることです。

少数でも業務停止につながる問題と、多数に発生する軽微な不便は、同じ軸だけでは比較できません。

4. 事業・技術・リスクを評価する

PMだけで全項目を埋めるのではなく、必要な専門性を持つ人が評価します。

Engineeringは実現可能性や技術負債を評価する。

Securityは情報漏えいや権限への影響を見る。

Legalは契約や法務上の条件を確認する。

事業責任者は戦略や機会費用を評価する。

誰がどの観点を評価したかも記録します。

5. Decision Authorityが判断する

評価をまとめる人と、最終決定する人は同じとは限りません。

通常の改善ならPMが決められるかもしれません。

高額投資、戦略変更、契約上の確約、重大なセキュリティ変更なら、Product CouncilやExecutive Sponsorの承認が必要になる可能性があります。

決定権限は、案件条件に応じたPolicyとして管理します。

6. 顧客別の回答を作成し、承認する

同じProblemに複数顧客が関係していても、顧客ごとに伝える内容は異なる場合があります。

利用状況、契約関係、過去の説明が異なるからです。

回答はDecisionから自動送信せず、外部公開可能な情報だけを使って作成し、必要な承認を経て送ります。

7. 開発・施策とのDelivery Linkを作る

採用されたDecisionは、Jira、Linear、GitHub Issuesなどの実行管理へ接続します。

ただし、開発チケットをDecisionの正本にはしません。

チケットが分割・統合・削除されても、なぜ投資したのかという判断記録を失わないためです。

8. Outcome Reviewで問題解決を確認する

リリース後、顧客への通知、利用、問題の再発、問い合わせ、作業時間、副作用を確認します。

期待した成果が出なければ、追加改善、別解決策、Decisionの再評価が必要です。

同じ課題でも、顧客接点、決裁構造、既存CRM、開発体制によって必要な設計は変わります。自社の顧客要望業務を整理し、MVPへ落とし込みたい場合は、業務棚卸しから要件定義・実装まで相談できます。

採用か不採用かの二択では足りない

実務では、顧客要望を「採用」「不採用」だけで表すと情報が不足します。

たとえば、次のようなDecisionを使います。

Accepted

対応することを正式に決めた状態です。

ただし、提供日まで確定したとは限りません。

Decisionとロードマップ上の予定、顧客への契約上の確約は別に管理します。

Conditionally Accepted

一定の条件を満たす場合に対応する状態です。

たとえば、セキュリティ審査を通過する、対象顧客が一定数に達する、既存アーキテクチャの移行が完了する、といった条件を保持します。

Deferred

問題は認識しているものの、現在は投資しない状態です。

再評価日や再評価条件がなければ、単なる放置になるため、条件を必須にします。

Declined

評価したうえで対応しないと決めた状態です。

「優先度が低い」だけでなく、戦略不整合、対象市場が限定的、複雑性が大きい、別の解決策があるなど、理由を記録します。

More Evidence Required

判断材料が不足している状態です。

対象ユーザー、発生頻度、回避策、期待結果など、何が不足しているのかを明示します。

Deferredが「今は投資しない判断」であるのに対し、More Evidence Requiredは「判断自体がまだできない状態」です。

Out of Scope

製品やサービスの対象外です。

ただし、対象外だから記録を捨てるのではなく、どの境界により対象外なのかを残します。

Duplicate

既存のProblemやRequestと重複している状態です。

元Voiceを削除せず、既存Problemへ関連付けます。

Superseded

後継Decisionに置き換えられた状態です。

過去の判断を消すのではなく、どのDecisionが後継なのかを明示します。

システム上のRoleと、業務上のDecision Authorityを分ける

権限設計で起きやすい誤りは、システム管理者へすべての権限を与えることです。

システム設定を変更できる人と、顧客要望の採否を決められる人は同じではありません。

このサービスでは、RoleとDecision Authorityを分けます。

CS・Salesは情報を登録する

顧客との接点で得た発言、背景、緊急性、顧客への一次回答を記録します。

ただし、担当顧客の要望を自分で採用状態へ変えることはできません。

Product AnalystやPMはProblemを整理する

類似Voiceを確認し、Problemを作成し、必要な評価を依頼します。

PMは推奨案をまとめられますが、すべての案件を単独決裁できるとは限りません。

Engineering、Security、Legalは専門評価を行う

各担当は、自分の専門領域について評価と根拠を記録します。

評価担当者が事業上の最終決定者になるとは限りません。

Product CouncilやExecutive Sponsorが条件付きで決裁する

高額投資、戦略変更、重大なリスク、契約上の確約など、一定条件を満たす案件を決裁します。

すべてを会議へ送るとCouncilがボトルネックになるため、金額、リスク、戦略影響などによる決裁基準が必要です。

顧客回答の承認者を分ける

社内Decisionが確定しても、そのまま顧客へ送れるとは限りません。

外部へ何を伝えるかは、CS責任者、PM、法務などが承認します。

Auditorは判断経緯を監査する

誰が、いつ、どの情報をもとに決め、後から何が変わったのかを確認します。

Auditorは記録を閲覧できますが、Decisionを書き換える権限は持ちません。

意思決定は上書きせず、後継Decisionで変更する

判断は、後から変わることがあります。

市場が変わる。顧客数が増える。技術的な制約が解消される。法令や契約が変わる。過去の見積もりが誤っていたことが分かる。

判断変更自体は問題ではありません。

問題は、過去の判断を現在の内容で上書きすることです。

承認済みDecisionは、直接編集できないようにします。

変更が必要な場合は、次のように扱います。

これにより、判断当時の情報と、現在の情報を分けられます。

なぜ単なる変更履歴では足りないのか

一般的な編集履歴でも、誰がどこを書き換えたかは追跡できます。

しかし、Decision Recordに必要なのは、文章の変更履歴だけではありません。

• どのPolicyに基づいて決めたか

• 誰がDecision Authorityだったか

• どの評価を参照したか

• 反対意見は何だったか

• どの条件で再評価するか

• 顧客へ何を伝えたか

• 何が変わって後継Decisionになったか

これらを一つの意思決定記録として保持する必要があります。

AIや担当者による都合のよい書き換えを防ぐ

AIが要約を更新した結果、過去の理由が現在の見方へ置き換わることも防がなければなりません。

担当者が変わった後に、「当時もこの方針だった」と履歴を書き換えることも許可しません。

判断を上書きしないことは、監査のためだけではなく、組織が過去から学ぶための条件です。

社内の判断理由と、顧客へ返す説明は同じではない

Decisionには、社内でしか共有できない情報が含まれます。

• 技術負債

• 顧客別の契約額

• 解約リスク

• 原価

• 競争戦略

• セキュリティ上の懸念

• 法務見解

• 人員不足

• 未公開ロードマップ

これを、そのまま顧客へ表示してはいけません。

そこで、次の3つを別の情報として扱います。

社内向けDecision Rationale

社内で判断を説明するための完全な理由です。

根拠、反対意見、条件、リスク、機会費用を含みます。

顧客別Customer Response

各顧客へ返す説明です。

顧客が何を伝え、企業がどう理解し、現在どのような判断をし、次に何が起きるのかを、公開可能な範囲で説明します。

公開ポータル向け回答

多数の利用者へ公開する一般的な回答です。

特定顧客の契約、利用状況、機密情報を含めません。

顧客への回答では、「検討します」「今後の参考にします」だけを避けます。

一方で、未確定の提供日を約束することも避けます。

たとえば、次のような要素を組み合わせます。

• 受け取った問題の理解

• 現在のDecision

• 公開可能な判断理由

• 再評価条件

• 次回更新の方法

• 現時点で提供を確約するものではない旨

機能をリリースしただけでは、顧客の問題を解決したとは言えない

対応判断がAcceptedになり、開発が完了し、機能がリリースされた。

ここで終わると、従来の「作りっぱなし」と変わりません。

次の状態を分けて考えます。

• 機能をリリースした

• 顧客へ通知した

• 顧客が機能を認識した

• 顧客が利用した

• 顧客の業務上の問題が解決した

• 期待した事業成果が出た

Releaseは、Outcome Reviewの開始条件です。

成功の確定ではありません。

Outcome Reviewでは、必要に応じて次を確認します。

• 対象顧客への通知が完了したか

• 利用率はどうか

• 同じ問題が再発していないか

• 問い合わせは減ったか

• 顧客の作業時間は変化したか

• 顧客は解決したと評価しているか

• 想定外の副作用はないか

• 追加改善が必要か

ここでProblemが解決していないと分かれば、別のRequestを検討するか、Decisionを再評価します。

AIは情報整理を助けるが、責任ある判断を代替しない

このサービスでは、AIを使います。

ただし、AIを意思決定者にはしません。

大量の非構造テキストを整理し、人間が判断しやすい状態へ変える補助者として使います。

AIへ任せること

分類候補

製品領域、問題種別、顧客業務、対象ユーザー、緊急度候補、関連部署を提案します。

類似Voice・Problem候補

同じ問題を別の言葉で表現している可能性があるVoiceを候補として表示します。

自動統合はしません。

Problem文の下書き

複数Voiceから、対象者、発生条件、問題、影響を構造化した文章案を作ります。

不足情報の検出

対象ユーザー、発生頻度、回避策、期待結果、根拠、技術評価などの欠落を提示します。

根拠要約

顧客発言、影響顧客、過去Decision、技術評価を要約します。

顧客回答案

承認済みDecisionと、外部公開可能な根拠だけを使って回答案を作ります。

AIへ任せないこと

• 採用・不採用の確定

• 最終優先順位

• 提供時期の確約

• 契約上の約束

• 顧客への自動送信

• 顧客価値の確定

• 法務判断

• セキュリティ判断

• 解約リスクの確定

• Decision Authorityの代替

AI出力は「候補」「下書き」「提案」と明示し、人間が確定するまで公式状態へ反映しません。

OWASPは、Prompt Injectionに加え、AIへ過大な機能・権限・自律性を与えるExcessive Agencyを主要なリスクとして挙げています。顧客の入力には外部由来テキストが含まれるため、「AIが読めるから、そのまま操作も任せる」という設計は避けるべきです。

AIは精度だけでなく、危険な失敗を評価する

AI機能を導入しただけでは、品質を説明できません。

たとえば、類似候補の平均精度が高くても、少数の重大なセキュリティ問題を一般的な機能要望へ誤統合すれば危険です。

そこで、次のような指標を分けます。

• 分類候補のTop-3 Recall

• 類似候補のRecall@5

• 誤統合率

• 重大誤統合率

• Problem文の大幅修正率

• 不足情報検出率

• 根拠整合性

• 顧客回答案への禁止情報混入

• 承認済みDecisionとの矛盾

• 人間の確認時間

• AI利用コスト

• 応答時間

• ユーザー修正率

評価データには、通常例だけでなく、次を含めます。

• 重複しているケース

• 似ているが別問題のケース

• 少数だが重大なケース

• 大口顧客の要望

• PIIや顧客機密を含むケース

• 多言語・表記揺れ

• 欠損

• 攻撃的入力

• Prompt Injection

• 不正確な顧客発言

モデル、Prompt、Schema、検索方法を変更した場合は、同じ評価セットで回帰評価します。

基準を下回ったら、以前の構成へ戻せる必要があります。

顧客要望は、無害な公開情報ではない

顧客要望は、製品改善に使うテキストだから安全だと思われがちです。

実際には、次のような情報が含まれる可能性があります。

• 顧客名、担当者名、メールアドレス

• 契約内容や売上情報

• 製品の利用状況

• 顧客固有の業務フロー

• セキュリティ上の弱点

• 未公開機能

• 障害情報

• 個人情報

• 顧客機密

• 他社情報

そのため、一般的な社内メモより強い管理が必要です。

Tenant Isolationをデータ層まで適用する

すべての主要Entityへtenant_idを持たせます。

アプリケーションの検索条件だけに依存せず、PostgreSQLのRow-Level Securityも防御層として使います。

PostgreSQLのRLSは、ユーザーやRoleに応じて行単位のアクセス制約を定義できます。ただし、テーブル所有者やBYPASSRLSを持つRoleの扱い、View、バッチ処理、インポートなども含めたテストが必要です。RLSを設定しただけでテナント分離が完成するわけではありません。

RoleとDecision Authorityを権限モデルでも分ける

システム管理者はユーザー追加や連携設定を行えても、Decisionを承認できない構成にします。

退職・異動時には、システムRoleだけでなく、Decision Authority、外部連携Token、Break-glass Accessも失効させます。

AIへ送るデータを最小化する

AI処理前に、不要な顧客名、担当者名、メールアドレス、契約情報を除去またはマスキングします。

Tenantごとに、AI処理を無効化できるFallbackも用意します。

モデル提供者との契約、データ保持、学習利用、処理地域は、採用時点の条件を確認します。

公開前に二段階で確認する

Customer Responseや公開ポータルへ出す情報には、公開可能区分と承認状態を持たせます。

AI案、社内理由、顧客機密が混入していないかを確認し、承認前には外部送信できないようにします。

監査ログを業務ログと分ける

重要操作をAudit Eventとして追記します。

• Voiceの機密区分変更

• Problemへの統合・解除

• 評価の確定

• Decisionの承認

• Supersede

• 顧客回答の承認・送信

• 外部公開

• Export・Delete

• 権限変更

• Break-glass Access

• AI設定やモデル変更

監査ログ自体の閲覧・エクスポート権限も制限します。

CRMやHelpdeskを置き換えるのではなく、判断情報をつなぐ

このサービスは、CRM、Helpdesk、Issue Trackerを再実装するものではありません。

それぞれには、すでに強い役割があります。

• CRMは顧客・商談・契約関係を管理する

• Helpdeskは問い合わせ対応を管理する

• Issue Trackerは開発タスクを管理する

• BIは利用状況や事業指標を分析する

対応判断管理サービスは、それらをつなぎ、なぜ対応するか、誰が決めたか、顧客へ何を返したかを正本として持ちます。

入力元

• Salesforce

• HubSpot

• Zendesk

• Intercom

• Chatwoot

• メール

• フォーム

• CSV

実行先

• Jira

• Linear

• GitHub Issues

協働・通知

• Slack

• Microsoft Teams

ただし、MVPですべての連携を作るべきではありません。

第一パイロット企業が実際に使う入力元と実行先を優先します。

外部システム障害でも、Decisionの正本を失わない

CRMやIssue Trackerとの同期が失敗しても、Voice、Problem、Evaluation、Decision、Responseは本サービスに残します。

外部連携では、次の失敗を前提にします。

• 同じイベントが複数回来る

• 順番が前後する

• 一部だけ成功する

• Timeoutする

• Rate Limitに達する

• 接続先のSchemaが変わる

• 接続解除後に再接続する

そこで、Idempotency Key、Correlation ID、Retry、Timeout、Dead Letter、Schema Version、署名検証、監査を設計します。

Transactional Outboxを使えば、業務データの更新と「外部へ送るべきイベントの記録」を同じTransactionで確定できます。

外部送信そのものはWorkerが後から行うため、通信障害時にもDecisionの確定を失いにくくなります。

MVPは、全部入りの完成品ではなく最重要仮説を試す仕組みである

MVPは、機能数を減らした完成品ではありません。

最も危険な仮説を、最小コストで検証するための仕組みです。

今回の最重要仮説は次です。

対象

• B2B SaaS企業

• 対象プロダクトは一つ

• CS、営業、PM、エンジニア責任者が参加

• 週10〜100件程度のCustomer Voice

正本ではB2B SaaSを第一候補としていますが、第一市場をB2B SaaSに限定するかはHuman Decisionです。

MVPで作るもの

• Voice登録

• CSV・API取込

• 顧客との関連付け

• AI分類候補

• AI類似候補

• Problem統合

• Customer Impact

• Evaluation

• Decision

• Decision Rationale

• 再評価条件

• Customer Response

• Delivery Link

• Outcome Review

• Audit Log

• Export

MVPで作らないもの

• 独自CRM

• 独自Helpdesk

• 独自Issue Tracker

• 全社ロードマップ

• AI自動採否

• 完全公開投票ポータル

• 高度な予測

• モバイルアプリ

• 複雑なカスタムスコアリング

• Microservices

• Multi-region

公開ポータルをMVPへ含めるかは未決定です。

顧客回答の価値を検証するだけなら、まず個別回答の作成・承認・送信記録から始められます。

技術構成は、仮説検証に必要なものへ絞る

MVPの推奨構成は、次のとおりです。

• Next.js App Router

• TypeScript

• TypeScriptモジュラーモノリス

• PostgreSQL

• PostgreSQL全文検索

• pg_trgm

• 必要性確認後のみpgvector

• Transactional Outbox

• Background Worker

• S3互換Object Storage

• OIDC

• Application Authorization

• PostgreSQL RLS

• Provider-neutral AI Gateway

• OpenTelemetry

• コンテナまたはPaaS

• 単一リージョン

2026年7月時点ではNext.js 16系が現行世代で、セキュリティリリースでは16.2.11がActive LTSとされています。ただし、要件定義へ特定のパッチ番号を固定せず、実装・リリース時点でサポートされている安定版とセキュリティ修正版を採用します。

なぜモジュラーモノリスなのか

MVPでは、業務境界をModuleとして分けながら、一つのDeployable Unitとして運用します。

たとえば、次の領域を分けます。

• Voice Intake

• Problem Management

• Evaluation

• Decision

• Customer Response

• Delivery

• Outcome

• Authorization

• Integrations

• AI Suggestions

• Audit

コード上の責任は分けますが、初期から分散システムにはしません。

2〜5名程度のチームでも、Transaction、テスト、デバッグ、Schema変更を管理しやすいためです。

なぜPostgreSQLを中心にするのか

このサービスの中心は、テキスト検索だけではありません。

Entity間の関係、状態、権限、監査、整合性、Transactionが重要です。

PostgreSQLは、関係データ、全文検索、Row-Level Security、拡張機能を一つのSystem of Recordで扱えます。

2026年7月時点のCurrentドキュメントはPostgreSQL 18を示し、18.4が2026年5月に公開されています。実装時にはサポート期間、利用PaaS、拡張対応を確認して採用版を決めます。

なぜ全文検索とtrigramから始めるのか

顧客要望には、製品名、機能名、略語、表記揺れが含まれます。

PostgreSQLのpg_trgmは、文字列のtrigram類似度とIndexを使った類似検索を提供します。完全一致や全文検索と組み合わせれば、初期の重複候補検索を実装できます。

最初からVector検索だけに依存すると、なぜ候補になったのか説明しにくくなり、運用対象も増えます。

なぜpgvectorを後回しにするのか

意味的に近い文章を検索する価値はあります。

しかし、最初に検証すべきなのは、埋め込み検索を使えるかではなく、類似候補が人間の整理時間を減らし、重大誤統合を増やさないかです。

全文検索とtrigramで不足するケースが確認された後に、PostgreSQL内のpgvectorや別方式を比較します。

なぜTransactional Outboxなのか

Decision確定と外部通知を別々に行うと、片方だけ成功する可能性があります。

Outboxへイベントを同一Transactionで記録し、Workerが再送可能な形で処理すれば、外部障害に強くなります。

なぜCustom Authenticationを作らないのか

認証は、このサービスの独自価値ではありません。

OIDC対応の認証基盤を利用し、サービス固有のRole、Permission、Decision AuthorityはApplication Authorizationとして実装します。

認証と業務上の決裁権限を混同しないことが重要です。

なぜProvider-neutral AI Gatewayなのか

AI分類、要約、類似候補は、モデル変更の影響を受けます。

アプリケーションから特定ProviderのAPIを直接呼び出すのではなく、次を統一して管理します。

• Provider・Model選択

• Prompt・Schema Version

• Redaction

• Rate Limit

• Cost Cap

• Timeout

• Retry

• Logging

• Evaluation

• Fallback

モデルを変えても、業務EntityやDecision Policyまで巻き込まない構成にします。

なぜOpenTelemetryなのか

このサービスでは、単に「画面が遅いか」だけでなく、Voice取込、AI処理、Decision、外部連携、顧客回答まで追跡する必要があります。

OpenTelemetryは、トレース、メトリクス、ログなどを共通コンテキストで扱うベンダーニュートラルな観測基盤です。特定の監視製品へ固定せず、処理の相関を追いやすくできます。

MVPで採用しない技術にも理由がある

不採用技術は、技術的に劣っているから外すわけではありません。

MVPの仮説検証へ必要か、運用負荷に見合うかで判断します。

Microservices

初期からService間通信、分散Transaction、Version管理、障害切り分けが必要になります。

組織と負荷が明確に分離を必要とするまで採用しません。

独立Vector Database

検索規模、Recall、Latency、運用要件がPostgreSQLで満たせないと確認されるまで追加しません。

Event Sourcing

Decisionを上書きしない設計と、システム全体をEvent Sourcingにすることは別です。

DecisionとAudit Eventを明示的に保存すれば、MVPで必要な説明可能性を実現できます。

Kubernetes

複数Service、大規模Traffic、複雑な配置制御がない段階では、運用負荷が大きすぎます。

コンテナ対応PaaS等で始めます。

Multi-region

データ整合、RLS、保持、削除、障害対応が複雑になります。

規制、顧客要件、可用性目標が必要性を示すまで単一リージョンとします。

完全Realtime

顧客要望の対応判断は、数秒以内の同期が本質ではありません。

初期は確実な非同期連携と再実行を優先します。

高度なWorkflow Engine

状態と承認ルールをDomainとして実装し、企業ごとの複雑なWorkflow要求が確認された後に再検討します。

AI Agentによる自動Decision

責任、説明、契約、顧客影響を伴うため採用しません。

モデル性能が向上しても、Decision Authorityの代替とは考えません。

Codex・Claude Codeへ実装を丸投げしない

要件が詳細でも、AI Coding Agentへ「全部作って」と渡せば、正しいシステムが完成するわけではありません。

特に今回のシステムでは、見た目上は動いていても、次のInvariantを壊す実装があり得ます。

• Voice原文を更新できてしまう

• RequestとProblemが同じTableになる

• AdminがDecisionを承認できる

• 確定Decisionを編集できる

• 社内理由が顧客回答へ混入する

• AI候補が自動確定される

• Tenantをまたいで検索できる

• Release時点でOutcomeを成功扱いする

そこで、AI Coding Agentを使う工程そのものを設計します。

AGENTS.mdへ不変原則を書く

AGENTS.mdには、少なくとも次を含めます。

• プロダクト目的と非目標

• Voice／Request／Problemの定義

• Approved DecisionはImmutable

• tenant_id必須

• Decision AuthorityとAdmin Roleの分離

• AIは公式状態を遷移させない

• 外部送信には承認が必要

• Fiderのコード、UI、文言を流用しない

• Requirement IDをPlan、PR、Testへ引用する

• PIIをLogへ出さない

• 高リスク変更のHuman Approval

Skillsで作業を限定する

• requirements-trace

• define-domain-model

• implement-voice-ingestion

• implement-problem-linking

• implement-decision-policy

• implement-customer-response

• tenant-isolation-review

• ai-evaluation

• threat-model

• migration-review

• accessibility-review

• release-check

一つのSkillがシステム全体を変更しないよう、入力、出力、許可範囲、停止条件を定義します。

実装担当と最終レビュー担当を分離する

実装したAgent自身に「問題ありません」と判定させるだけでは、同じ誤解を引き継ぎます。

要求分析、Domain設計、実装、Test、Security Review、AI Evaluation、Tenant Isolation Review、敵対的レビューを分けます。

最終的にはIntegratorが証拠をまとめ、未解決事項を明示します。

Commandsで再現可能な工程にする

• /trace-requirements

• /plan-feature

• /implement-slice

• /review-diff

• /verify-invariants

• /test-tenant-isolation

• /evaluate-ai

• /threat-model

• /release-check

• /rollback-plan

人によって毎回違う依頼をするのではなく、同じ品質ゲートを再実行できるようにします。

CIで決定論的に検査する

• Scope Check

• Secret・PII Scan

• Lint

• Type Check

• Unit Test

• Integration Test

• E2E

• Permission Test

• Tenant Isolation Test

• Migration Test

• API Contract Test

• AI Eval

• Dependency・License Scan

• SBOM

• Accessibility

• Documentation・Requirement Trace Check

自然言語のルールだけでなく、機械的に検査できるものはCIへ移します。

リスク別に承認を変える

軽微な文言変更と、RLSやDecision Stateの変更を同じ手続きにしません。

高リスク変更には、二重レビュー、Security Approval、段階的リリース、Rollback演習を求めます。

AIが「実装完了」と報告したことは、完了証拠になりません。

Pilotでは、成功だけでなく方向転換と中止条件を測る

このサービスは、設計上成立しているだけで、市場価値が確認されたわけではありません。

4〜8週間のPilotで、現状値と導入後を比較します。

North Star候補

単にVoiceが何件登録されたかではなく、判断と説明まで閉じた割合を見ます。

業務KPI

• Voice登録時間

• VoiceからProblem関連付けまでの時間

• 未分類Voice件数

• 重複率

• Decisionまでの所要日数

• Decision理由記録率

• 期限超過率

• 顧客回答完了率

• Outcome Review率

• 顧客回答の訂正件数

AI KPI

• 分類候補精度

• 類似候補Recall

• 重大誤統合率

• AI案の大幅修正率

• 禁止情報混入率

• 人間確認時間

• AI Cost

ガードレール

• 入力負荷

• Product Councilの滞留

• 顧客機密の公開

• 誤った顧客回答

• 少数の重要問題の見逃し

• 大口顧客への過度な偏り

• スコアへの過信

GO条件

正本では、次をPilotの判断基準候補としています。

• Voice登録時間P75が3分以内

• Decision理由記録率95%以上

• 顧客回答完了率90%以上

• AI重大誤統合率2%未満

• CS・PMの70%以上が継続利用可能と評価

• 判断リードタイムが悪化しない

• 支払い意思を持つ企業を確認

これらは効果保証や業界標準ではありません。

Pilot前にBaseline、測定方法、対象数を確定し、実測値をもとに見直します。

PIVOT条件

• 独立SaaSより既存CRM拡張が望まれる

• AI類似検索より連携・回答管理の価値が高い

• Product Councilより軽量Decision Logが求められる

• 公開ポータルより社内判断管理が重要

• 要望管理より顧客回答管理が主要価値になる

PIVOTは失敗ではありません。

顧客が実際に支払う価値が別の場所にあると分かった状態です。

STOP条件

• 既存ツールの組み合わせより改善しない

• 入力負荷が高く利用されない

• 顧客回答管理への支払い意思がない

• Product Councilが新たなボトルネックになる

• 機密・AI条件を現実的なコストで満たせない

• 判断履歴が実務で利用されない

設計したから作るのではなく、仮説が反証されたら止めます。

このサービスが向かない企業もある

すべての企業に専用サービスが必要なわけではありません。

要望件数と関係者が少ない

月数件で、PM一人が顧客背景と判断理由を十分に把握でき、担当者交代リスクも小さいなら、専用システムは過剰です。

Notionやスプレッドシートで必要条件を満たせる

Voice、Problem、Decision、顧客回答を分け、権限、履歴、期限を運用できているなら、既存ツールで十分な可能性があります。

問題はツール名ではなく、必要な業務が閉じているかです。

既存のProduct Management製品で要件を満たせる

Productboardなどの既存製品は、顧客フィードバックの集約、インサイト、優先順位付け、ロードマップ、AI支援などを提供しています。2026年には、AIによるテーマ検出、機能案との関連付け、仕様作成なども強化されています。

必要なDecision Authority、顧客別回答、監査、Outcome Reviewを既存製品と運用で満たせるなら、新規開発する必要はありません。

判断工程より入力工程が重くなる

評価項目を増やしすぎると、情報を整えること自体が仕事になります。

入力負荷が価値を超えたら、項目や機能を削るべきです。

Product Councilを運用できない

会議を増やすだけでは、意思決定は改善しません。

案件分類、非同期レビュー、SLA、定足数、委任基準がなければ、Councilが新しい滞留場所になります。

敵対的レビューで残るリスク

この設計でも、リスクは完全には消えません。

入力負荷が高くなる

AI候補、自動取込、段階入力で軽減できます。

ただし、質の高い判断には一定の情報整理が必要です。

入力をゼロにはできません。

数値スコアが疑似客観性を生む

スコアを複数軸で表示し、根拠、反対意見、条件を併記します。

それでも、組織が数字だけを見る可能性は残ります。

大口顧客へ偏る

契約影響を隠す必要はありません。

ただし、対象市場、プロダクト複雑性、他顧客への影響を同時に評価し、偏りを監査します。

AIが少数重大問題を誤統合する

自動Mergeを禁止し、重大カテゴリを独立評価し、Adversarial Datasetを使います。

それでも見逃しをゼロにはできません。

顧客回答が将来提供の約束と誤解される

承認Template、禁止表現、契約上の確約との分離で軽減します。

顧客との関係や過去の説明により、誤解の可能性は残ります。

CRM等との二重入力が残る

優先連携、自動取込、元URL保持で減らします。

すべての外部システムを同期することは現実的ではありません。

顧客機密がAIへ送信される

Redaction、Data Minimization、AIなしFallback、Provider契約で軽減します。

利用地域、契約、入力内容による法的確認は別途必要です。

Tenant Isolationに不備が起きる

RLS、Application Authorization、Cross-tenant Testを重ねます。

設定ミスや新しいQueryによる事故を完全には排除できないため、継続テストが必要です。

Decision Recordが形式だけになる

理由欄を埋めても、実際の判断が別の会議や口頭で行われれば意味がありません。

業務上の正本として使われているかをPilotで確認します。

Outcome Reviewが実施されない

リリース後は次の案件へ進みたくなります。

期限、責任者、通知を設定しても、経営やProduct運用がOutcomeを重視しなければ定着しません。

小規模企業では費用対効果が合わない

入力、設定、連携、監査のコストが、要望件数や判断複雑性を上回る可能性があります。

その場合は、軽量Templateや既存ツール運用の方が適切です。

開発前に人間が決めなければならないこと

次の項目は、記事の読みやすさを理由に確定扱いできません。

• 第一パイロット企業

• 第一市場をB2B SaaSに限定するか

• 公開ポータルをMVPへ含めるか

• 初期CRM連携先

• 初期Helpdesk連携先

• 初期Issue Tracker連携先

• 顧客契約額を評価に利用する範囲

• Product Councilの構成

• Decisionの定足数

• 高額投資案件の決裁基準

• 顧客回答の承認ルール

• SSO必須化の時期

• データ保持期間

• 料金体系

• 課金軸

• Fiderのコードを利用・改変する場合の法務判断

Fiderは現在、フィードバックポータルとして公開され、公式APIドキュメントがあり、GitHub上の本体はAGPL-3.0です。2026年7月にも更新が確認できます。

今回の設計では、Fiderのコード、UI、文言を流用せず、投稿、投票、コメント、状態、公式回答などの構造的価値だけを調査起点として独立実装します。実際にコード利用や改変、ネットワーク提供を行う場合は、利用形態に即した法務確認が必要です。

このサービスから持ち帰れる7つの設計原則

最後に、このサービス固有の機能を超えて使える原則を整理します。

1. 発言と問題を分ける

利用者が提案した解決策を、そのまま仕様にしない。

原文を保持し、背後のProblemを別に定義します。

2. RoleとAuthorityを分ける

情報を登録できること、評価できること、決裁できることを分けます。

システム管理者へ業務上の決定権を自動的に与えません。

3. Decisionを上書きしない

判断変更は後継Decisionとして残します。

過去の判断時点と現在を区別します。

4. 内部理由と外部説明を分ける

完全な社内理由と、顧客へ伝えられる情報を別に管理します。

隠すためではなく、必要な説明を安全に返すためです。

5. 実行と成果を分ける

リリースしたことと、問題が解決したことを同一視しません。

Outcome Reviewまでを業務に含めます。

6. AI提案と人間決定を分ける

AIは整理、検索、下書きを支援します。

採否、確約、承認、送信の責任は人間が保持します。

7. GOだけでなくPIVOTとSTOPを決める

設計や開発へ投資した後でも、仮説が反証されたら方向転換や中止を選べるようにします。

まとめ｜顧客中心とは、すべての要望を採用することではない

顧客中心と聞くと、顧客の要求へできるだけ多く応えることだと思われるかもしれません。

しかし、すべての要望を採用すれば、プロダクトは複雑になり、開発資源は分散し、かえって多くの顧客へ価値を届けにくくなります。

反対に、企業の戦略だけを優先し、顧客へ何も説明しなければ、「声を集めている」という形式だけが残ります。

私が必要だと考えているのは、その中間的な妥協ではありません。

顧客の声を正確に保持し、発言を問題へ翻訳し、複数の観点で評価し、権限を持つ人が理由付きで判断する。そして、結果を顧客へ返し、実施後に本当に解決したかを確認する。

これが、顧客要望の対応判断管理です。

顧客の言葉を、そのまま作る機能へ変換しない。

声の大きさを、事業価値と同一視しない。

評価する人、決める人、説明する人を分ける。

意思決定を上書きせず、履歴として残す。

AIは情報整理を支援するが、責任ある判断を代替しない。

機能をリリースしたことと、顧客の問題を解決したことを分ける。

これらの原則は、顧客要望管理だけでなく、社内稟議、施策判断、問い合わせ対応、リスク審査など、さまざまな業務システムへ応用できます。

このシリーズでは、身近な業務上の摩擦を、状態、権限、AI、人間承認、監査、技術、停止条件まで含むサービス要件へ変換しています。

関連記事

• ［AIに「どう思う？」と聞くだけでは、判断は良くならない。問い・前提・代替案から考える意思決定の基本設計］
  https://note.com/gtminami/n/na9325aa5ab3f
  投票数やAIスコアへ判断を委ねず、前提、代替案、反証、停止条件を整理する方法が分かります。

• ［AIは、ほとんどの作業ができるようになった。それでも「仕事を任せられる」とは限らない］
  https://note.com/gtminami/n/n36b17c6282a4
  AIに作業を任せられることと、責任を伴う仕事を委任できることの違いを補完します。

• ［Codex・Claude Codeに全部任せると、なぜ開発は迷走するのか？AI開発を安定させる工程設計］
  https://note.com/gtminami/n/n628815592f30
  本記事の開発ハーネスを、AI Coding Agentの工程分離と品質ゲートの観点から深掘りしています。

企業で実行する場合

顧客要望管理に限らず、「情報はあるのに誰も決めない」「判断理由が残らない」「AIを入れたが責任境界が曖昧」といった業務を、状態、権限、評価、監査まで含むシステムへ設計したい場合は、支援内容をご確認ください。

出典・参考資料

• Fider公式サイト・公式GitHub・公式APIドキュメント

• Productboard公式サイト・公式製品情報・公式ブログ

• PostgreSQL 18公式ドキュメント

• Next.js公式リリース情報

• OpenTelemetry公式ドキュメント

• OWASP Top 10 for Large Language Model Applications

• W3C Web Content Accessibility Guidelines 2.2