比較だけでなく、見送る条件を置いた。

初期仮説

中古PCの購入では「どれが良いか」を並べるだけでは決まらない。用途と予算と故障リスクを同時に照らす必要があり、かつ「今は買わない」と言える仕組みがないと、不安で Over-spec へ流れる。

採用した構成

• 静的HTMLを本体にし、判定ロジックをクライアント側の小さなスクリプトに閉じた
• 比較表と購入前チェックを同一導線に置き、順番を「条件→照合→停止判断」にした
• 判断表を印刷・コピーできる形にし、店頭でも使えるようした

採用しなかった構成

• サーバー側で判定結果を生成する動的構成（静的配信の堅牢さを捨てるため）
• 口コミ評価や星レビューの集計（一次情報ではなく、YMYL領域での誤情報リスク）
• 無限のスペック比較（選択肢を減らす方が決定を助けるため）

実際に起きた問題と修正

初版は「買う理由」の列挙が多く、不安層が Over-spec へ向かう傾向が見えた。そこで「見送る条件」を明示する導線を追加し、停止判断を最初の方に置いた。これは BUILD ORBIT が他サイトでも観測した「決定を助けるのは選択肢ではなく停止条件」という学びと一致する。

事実・解釈・未計測を分ける

公開サイトとProject dataから確認できる事実は、静的HTML、クライアント内判定、条件比較、購入前チェック、そして「見送る条件」を含むことです。そこから「停止条件を先に置くと不安を扱いやすい」と読むのは、このProjectの設計上の解釈です。購入率、返品率、検索順位、利用者の満足度は確認していないため、このケーススタディの成果指標にはしません。

• 事実：用途・スペック・価格を照合し、購入前の停止条件を置いた。
• 解釈：比較の終点を購入に固定しない方が、判断の逃げ道を残せる。
• 未計測：その導線が行動や検索パフォーマンスを改善したかは未確認。

再利用できる学び

• YMYLに近い題材では、評価の集計より「自分で確認する手順」を優先する
• 比較サイトは「どれが良いか」だけでなく「見送る条件」を置く
• 静的生成でも、クライアント内判定で十分な判断支援ができる

今なら変える点

判定ロジックをより小さな Island（React/Preact）として分離し、no-JS 時にも判断表だけは読める形を標準化する。現在は純JSだが、他サイトで得た「Islandで動かす範囲を絞る」知見を統合したい。