Danny Postmaが提案する、購入者の使い方から改善を選ぶ方法

サービスの改善をAIに手伝わせるなら、購入した人の利用状況、アンケート、相談を一枚にまとめてもらう。そこから、何を直すかを人が選べるようにする。Danny Postmaの10月15日の投稿から、こうした仕事の任せ方を考えました。

どの層に合わせるかを、使い方と支払いから考える

Dannyが示したのは、製品と販売ページを作り、人を集めた後に、機能の利用状況やアンケートを分析する流れです。そのうえで、どの層がお金を払うかを確かめ、その層に合う機能を足し、合わない機能を削る。さらに説明文や集客の対象も調整する、と提案しています。10月15日の本人投稿

13日の投稿でも、利用状況、アンケート結果、サポートのメッセージを分析し、その結果をソフトウェアの改善に使うことに触れていました。10月13日の本人投稿

対象の製品や使ったツール、実際の変更とその結果は、この二つの投稿には示されていません。AIによる分析かどうかも不明です。以下では、この方針をAIへの依頼に応用します。

四つの記録があっても、四人の要望とは限らない

自分のサービスで使うなら、一つの商品と一つの期間に範囲を絞り、購入状況、利用ログ、アンケート、相談をAIへ渡します。公開してよい集計か、分析への利用を許された匿名の記録を使い、顧客の原文や個人情報をそのまま貼り付けないようにします。

以下は、同じ利用者ID「A01」に対応する架空の記録です。実在の顧客や調査結果ではありません。

購入後の使いづらさを調べるための入力例

資料ID	記録の内容
P01・購入	対象サービスを購入済み
L01・利用	PDF出力を開始。完了した記録はない
Q01・調査	アンケートの利用目的は「社内共有」
S01・相談	保存したファイルの場所についての問い合わせ

記録は四つでも、利用者は一人です。資料ごとの件数と、重複を除いた利用者数を分けて数えます。購入状況が不明な人を未購入者と決めつけたり、同じ人か確かめられない資料を結び付けたりしないことも必要です。

この例では、PDF出力が失敗したとはまだ言えません。完了が記録されなかった理由が分からず、保存先の案内が分かりにくかった可能性もあります。AIには、記録から確かめられることと、原因の候補を分けて書いてもらいます。

GOV.UKの利用者調査の手引きも、見聞きしたことを、その意味についての解釈と分けて記録するよう勧めています。観察した事実から原因を考える際の参考になります。GOV.UKの分析手順

AIには、改善候補一つと根拠を返してもらう

ここからは編集側の提案です。購入後の使いづらさを調べる仕事として、次のように依頼できます。購入前に買わなかった理由を探す場合は、未購入者の資料も含めて、別の問いとして調べます。

資料：＜対象商品、対象期間、購入状況・利用ログ・アンケート・相談の表を貼る。各記録に資料IDを付ける＞

購入した人が使いづらかった箇所を整理してください。まず資料から確認できる事実を、元の資料IDとともに抜き出してください。資料ごとの件数と、重複を除いた利用者数を分け、購入状況の不明も残してください。同じ人の記録と確認できない資料は結び付けないでください。

次に、使いづらさの原因の候補と、別の説明が成り立つ点を書いてください。改善候補は最大一つに絞り、根拠、その案と食い違う記録があるか、追加で確かめることを添えてください。資料不足なら選ばず、何が足りないかを返してください。今回は整理と提案までです。原本の変更、顧客への連絡、公開はしないでください。

受け取るものは、根拠をたどれる事実の一覧と、改善候補一つ、または選べない理由です。

AIが挙げた資料IDを、人が開いて確かめる

確認するのは、購入済みとした根拠、同じ人の記録を結び付けた理由、人数や件数の数え方、困りごとの内容です。AIが示した資料IDを開き、要約で意味が変わっていないかを照合します。

資料にない原因を事実として書いた、同じ人の相談を別々の人として数えた、欠けた記録をゼロにした。このような場合は差し戻します。説明を直せばよいのか、機能の修正が必要なのかを決める材料が足りなければ、その判断は保留します。

人が元資料を確認でき、改善候補の根拠、案と食い違う記録の有無、次に確かめることがそろえば、この整理の仕事は完了です。実際に機能を追加・削除するか、説明を変えるかは、その後に決めます。

初回は、AIの整理で事実を取り違えた箇所と、人の確認にかかった時間を残します。根拠を何度も探し直すなら、資料IDや入力の分け方を直して再度試します。この試行は未実施で、確認時間の短縮や売上への効果はまだ確かめていません。

出典と調査範囲

• Danny Postma：how to build a working startup（2026年10月15日）
• Danny Postma：利用状況・アンケート・サポートの分析に関する投稿（2026年10月13日。前回から持ち越した背景資料）
• GOV.UK：Analyse a research session（2016年5月24日公開。分析方法の背景資料）

確認日は2026年10月21日。前回の調査日10月14日以降を中心に、持ち越していた13日の原文も確認しました。Xはプロフィールで表示された主な投稿と上記の原文を読み、全返信や全履歴を網羅したものではありません。