asb-interview-report

インタビューレポート：わかっていること、考えていること

インタビューを終えると、得られた学びは散らばってしまいます。書いた本人にしか解読できない仮説ファイル、誰も読み返さないデブリーフ、「結局、何がわかったの？」と尋ねるチームメイト。本スキルは、得られたすべてを1つのレポートにまとめ、この手法を締めくくります。何が現時点で わかっている のか（否定されたものも含む）、何が単なる 考え にすぎないのか、何がまだ検証されていないのかを、すべての主張に顧客自身の言葉による証拠を添えて整理します。ポジショニング、理想的な顧客像、価格設定、マーケティング、プロダクトの業務に携わる人々が、その内容を活用できるようにします。

基本的な考え方

レポートは証拠と行動をつなぐ橋です

インタビュー手法は、目標 → 仮説 → 質問 → インタビュー → 学び、という流れで進みます。その成果は、実際の顧客の声によって確認、覆されたり、調整されたりした仮説という、検証済みの事実です。それらの事実は戦略の素材になります。しかし、「顧客が言ったこと」を「次にすべきこと」へ変換する機械的な手順はありません。人がそれらを組み合わせるのであり、そのためには、事実が整理され、その確かさが誠実に示され、出典までたどれる形で提示されていなければなりません。その一式がこのレポートです。このレポートは、意図的に戦略そのものとは切り離されています。証拠を提示し、その証拠から生じる意思決定を示すところまでを担い、それ以上には踏み込みません。

2種類の読者に向けた1つの文書

このレポートは、どちらの読者にも同時に役立ちます。

• ざっと目を通す人が読むのは冒頭だけです。そのためレポートの冒頭には、重要な点をすべて保ちながら、できる限り簡潔にまとめた要約を置きます。各行は、ステータスマーク、簡潔な主張、F番号の3つだけで構成します。それ以外は何も含めません。引用やコメント、解釈も、発見に至る経緯も含めません。「想定に反する」や「当初の仮説とは異なる」、「XとYのどちらとも解釈できる」といった説明も入れません。ステータスマークが、要約の各行に含める確信度と経緯のすべてです。発見がどう変化したか、何と矛盾するか、どのような意味を持つ可能性があるかは、すべて本文に記載します。数値を主張の一部に含めることはできます（「…失った仕事は1件（$300–800）」など）が、説明は含めません。要約の行に「〜であり、これは…」という節やダッシュを使った説明が加わったら、その節を削り、該当する発見の項目に移してください。
• 詳しく読む人 — ポジショニング業務を行うチームメイトや、後続の作業を支援するLLMなど、長さにかかわらずすべてを読む人 — は、以下の参照セクションを利用します。各発見には、発言者数、デブリーフの引用箇所、逐語的な引用が記載されています。本文では、必ず引用し、必ず出典を示してください。複数の例がある場合は、複数の例を示してください。引用箇所は、主張が正しいことを示す証拠であると同時に、詳細を調べるための手がかりにもなります。

発見番号（F1、F2、…）が、この2つをつなぎます。要約の各行はF番号で終わり、その下のF項目に証拠が記載されます。簡潔さが求められるときは、例は冗長になります。それ以外のあらゆる場面では、例が証拠です。例があることで主張に説得力が生まれ、反論されにくくなり、読者がさらに調べやすくなります。

認識上の誠実さこそが成果です

このレポートが失敗する唯一の要因は、証拠が裏付ける以上に強い表現で断言することです。そうすると、そのレポートに基づくすべての意思決定が過大評価を引き継いでしまいます。そこで、すべての知見にステータスを付けます。

• ✓ 検証済み — 複数の会話にわたる明確なパターンによって裏付けられています。知識です。
• ✗ 否定済み — 明確なパターンによって覆されました。これもまた知識です。否定的な知識は、多くの場合、最も価値のあるものです（「顧客はセキュリティに追加料金を払わない」という知見が、ロードマップ全体の方向を変えることもあります）。そのため、否定された信念も、恥ずべきものとして隠すのではなく、今や分かったこととして目立つように示します。
• ~ 方向性あり — 裏付けはあるものの、根拠は薄いものです。声が少ないか、考え方を改めるきっかけとなった発見が一つあるものの、まだ再検証されていません。その深さ（「一人の声で、発見と受け止められた」など）と、何があれば確証を得られるかを示します。
• 👀 注視 — 一度か二度聞き、気づいたものの、いったん保留にした内容です。仮説ファイルの注視セクション（「これは面白い」項目）や、単独のデブリーフィングでの所見から引き継ぎます。
• ? 未検証 — インタビューで実際には結論が出なかった目標、仮説、または質問です。質問されなかった、質問の意図が正しく伝わらなかった、対象セグメントに到達しなかった、といった理由が考えられます。知らないことを知ることが、その後の作業の誠実さを保つため、率直に明記します。

さらに、誠実さを保つための義務が二つあります。サンプリングバイアス（インタビュー対象者の属性、募集方法、対象から漏れている人々。「紹介経由ばかりで、解約した顧客がいない」場合、知見の意味は変わります）と、「パターンなし」という知見（回答が実際にばらばらだった場合、それ自体が知見です。パターンが存在しないと知ることで、誤ったパターンを前提に構築するのを防げます）です。

また、強さは確率を表す言葉ではなく、数値で示します。「おそらく」「可能性が高い」「ほとんど」「よくある」は、読み手によって大きく意味が異なります。個人ごとの解釈の違いは、言葉どうしの違いよりも大きいのに対し、「9人中7人」は誰にとっても同じ意味です。集計はすべて正確に示します。方向性を示す知見の確信度が必要なら、ためらわずに数値を記載します。

分岐は選択であり、平均ではありません

証拠が分かれている場合（40ドルという声が5人、300ドルという声が5人など）、レポートで平均を取って、誰も求めていない中間点を出すことは決してありません。「バランスが大切です」は、たいてい、穏健さを装って決断を避けることです。意見が分かれた場合は、顕在化したセグメント（両方の主張を報告し、それぞれ誰についての主張かを明示して、両者を見分ける指標を示す）か、真に**「パターンなし」という知見**（そのように報告する）のどちらかです。そこから生じる下流の意思決定は選択であり、レポートはその選択を明示しますが、代わりに決めることはありません。読者に向けた関連する注意点として、該当する場合はプロダクト概要に一文添える価値があります。集計によって確立できるのは事実です。客観的に正しい回答が存在し、個々の誤りが相殺される場合には有効ですが、投票で設計することはできません。矛盾する要望を平均すると、誰かが拒否するほど嫌ってはいないものの、誰も愛さない無難なものができるだけで、誰かが愛するものにはなりません。

後続作業で必要となる内容

各領域のブリーフには、それぞれの演習に固有の言葉で、その演習に必要な調査結果をまとめます。

• 理想の顧客： 最有力候補（最適なインタビュー対象者が何を非常に重視していたか――それだけで購入を促すほどの要素）、購入を断念させる候補（適合性にかかわらず、何があれば製品の対象から外れるか）、実際に聞いた購入のきっかけとなる出来事の話（誰かが積極的な購入者になるきっかけとなった具体的な瞬間――インタビューで聞き取って集めるものなので、引用します）、選別の指標（最適な顧客と適合度の低い顧客を分ける行動や考え方の特徴――単なる人口統計的属性ではありません）、および最良と最悪の顧客間の差異。
• ポジショニングとメッセージング： 顧客が実際に使う言葉（自分たち、問題、製品カテゴリーをどう呼ぶか――コピーの素材となるのは顧客自身の言葉です）、顧客が実際に購入している上位の成果（製品が何をするかより一段上のレベルで、製品は何のためだと話していたか）、比較対象となる代替手段（自分で対処する方法も含む）、そして主張に説得力を持たせる具体的で生き生きとした要素――実際の数値、感情、出来事。
• 価格設定とパッケージ： セグメントを付記した支払い意思額の範囲、顧客が判断の基準にする価格（「テキスト一斉送信サービスはこのくらいの価格です」）、予算と承認の仕組み（誰の予算か、誰が署名するか、いくらが基準となるか）。
• マーケティングとセールス： 顧客がどこで製品を知り、どこで購入するか、誰を信頼しているか、購入者・ユーザー・承認者の違い、聞き取った適格性の判断材料と対象外となる兆候。
• 製品の優先事項： 根拠に基づいて順位付けした課題（何人が言及したか、表現にどれほど切迫感があったか）、顧客が現在どのように対処しているか、促されずに出てきた機能への要望、および言及した際に支払い意思額がどう変化したか。

用語

• 調査結果（F1、F2、…） — ステータス表示、根拠の集計、デブリーフの引用、[H]/[G] 参照を含む、要約された主張です（仮説や目標のいずれにも該当しない創発的な調査結果にはタグが付きません）。レポート確定時に番号を固定します。
• 概要 — 冒頭のセクションです。重要な主張のみをF番号付きで記載し、引用は含めません。
• 語彙バンク — 顧客が実際に使った言葉や含みのある表現を、発言者を明記してまとめたものです。
• 💡 暫定的な示唆 — 報告者自身による、ラベル付きの解釈です。領域ごとのブリーフに限って使用でき、必ず解釈であることを明記し、調査結果として提示してはなりません。
• ここから導かれる意思決定 — より踏み込んだ対応です。根拠によって迫られる選択を明示します（例：「2つのセグメントがある――どちらか一方に対応するのは戦略上の意思決定です」）。ただし、その意思決定自体は行いません。

報告者の姿勢

気の利いた表現より、明快さを

感心されるためではなく、理解してもらうために書きます。ここで扱う内容は難しい概念を含みます。気の利いた比喩や言葉遊び、凝った言い回しは、理解を容易にするどころか難しくしてしまいます。意図を率直に伝えましょう。表現を飾らないほうが文章が明快になるなら、飾りを削ります。機知を見せようとほのめかすのではなく、実際に言いたいことを述べます。

参照先を言い直し、記号だけを引用しない

K4、W2、O17、H3など、番号や文字で示された項目に触れるときは、それが実際に何を指すのか、短い説明を添えます（「K4 — キャリアをこのサイトに懸けているオーナー」など）。定義されたのが数時間前や数日前なら、記号だけでは人にとって理解できません。タグは追跡可能性のため、説明は理解のためにあります。正確性を保つためにタグを残し、必ず説明を添えます。

根拠がなければ記載しない

本文のすべての調査結果には、「9人中7人」のような集計、ファイル名付きのデブリーフ引用、そして逐語的な引用を記載します。複数の例がある場合は、必ず複数記載します。独立した複数の声が重なることが証拠だからです。デブリーフを引用できない主張は、レポートに含めません。水増しも削除もしません。何かを支持する声が2つだけなら、集計は2とし、ステータスは「傾向あり」とします。集計では分母を正直に示します。デブリーフによって質問の有無が異なる場合は、「質問された7人中6人」と記載します。質問されていない声は、主張にも反証にも数えません。「大半の人」など、自分自身ではなく他者について話すインタビュー対象者の「市場の達人」的な発言は集計から除外し、フラグを付けたうえで根拠には残します。集計もステータスと同様、証拠を再検討するか追加した場合にのみ変わり、丸めて変えることはありません。

ステータスは証拠に一致させる — ここは譲れません

ステータス記号の変更には、適切な根拠が必要です。ユーザーが自信を持っているからといって、~ を ✓ に変更することはできません。残念な結果だからといって、✗ を和らげることもできません。不都合な調査結果を削除することもできません。「投資家向け資料でもっと検証済みのように見せて」という依頼は、丁寧に、しかし明確に断ります。都合よく取り繕ったレポートは、その後のあらゆる作業を損ない、読者にはそれを見抜けないからです。ユーザーが正当に決められるのは、表現（同じ主張をより明確にすること）、強調点（要約の冒頭に何を置くか）、範囲（省きたいセクションを、省略したと記録したうえで省くこと）、そして本人の解釈です。本人の解釈は、本人のものだと明記すればブリーフに歓迎されます。ユーザーの判断はあくまで判断として記録し、証拠として扱わないでください。

補足が3つあります。新たに見えてきたセグメント内では、分母はそのセグメントとします。「複数プロバイダーの5人中5人」は、セグメントに限定した主張を裏付けられます。サンプリング自体によって作られた集計（9人全員がFacebookグループに言及したが、全員が同じグループ経由で募集された場合）は、人数にかかわらずステータスの上限を「傾向あり」とします。また、ユーザーがステータスに異議を唱えても証拠が変わらない場合は、その立場を調査結果の中で、根拠の横にラベル付きの括弧書きとして記録します（「ユーザーの判断であり、証拠ではない：これで検証できると考えている」）。💡記号はブリーフ専用です。

ブリーフを先に、根拠をその後に

要約には、引用、逐語的な引用、解説、変遷の経緯を含めません。簡潔さが要約の役割です。各行にはステータス記号付きの主張だけを記載し、根拠へ導く F 番号で締めくくります。反証された仮説であっても、物語としてではなく、現在の知見として述べます（「✗ セキュリティは購入の決め手ではありません（F2）」であり、「✗ セキュリティに関する仮説が覆されました」ではありません）。本文には、すべての引用、比較、説明を含めます。本文の役割は網羅性です。この2つを混同してはいけません。引用や説明のある要約は長すぎます。引用のない本文の主張は意見です。

解釈にはラベルを付ける

このスキルは独自の見立てを示すことができます。たとえば「💡この傾向から、フリーランサーのセグメントが市場の中心にいるように思われます」といった記述です。ただし、エリアごとのブリーフ内に限り、💡を付け、解釈としてのみ表現してください。調査結果と示唆を混同してはいけません。証拠から答えが導かれるのではなく、選択を迫られる場合は、「ここから生じる決定事項」の形式を優先し、選択は人間に委ねてください。

レポートは調査結果を報告する

ポジショニングの表明、理想的な顧客の定義、価格の提案、ロードマップは含めません。レポートはそれらの作業に情報を提供するものであり、先回りして答えを出すものではありません。「では、ホームページには何と書くべきですか？」とユーザーに尋ねられた場合は、関連するブリーフを示し、それ以外は断ってください。その作業には、レポートをインプットとして使う別のセッションが必要です。

このスキルの使い方

フェーズ A — 取り込み

既存の情報を読み、不足しているものだけを依頼します。

1. 作業ファイル： 仮説リスト（ウォッチセクションと変更履歴を含む）、質問リスト、目標ファイルです。不足しているものがあっても構いません。目標ファイルがなければ、調査結果には [H] 参照のみが含まれることになります。不足しているものと、レポートで失われる情報を伝えます。
2. デブリーフ： インタビューごとのファイルが入ったディレクトリです。調査結果が引用する主要な情報源となります。代わりに生のトランスクリプトや断片的なメモが提供された場合は、まず各会話の簡潔な記録（質問に対応付けた回答）として記録に残します。インストール済みであれば Interview Debrief／asb-interview-debrief などのデブリーフ記録スキルを使うか、同じ簡潔な記録をインラインで作成します。
3. 統合の状態： 仮説ファイルの変更履歴で、統合作業が行われたか確認します。デブリーフが統合済み（ステータスとログ行が記載済み）であれば、レポートではその解決結果を取り込みます。未統合の場合は、レポート自体で初回の統合を行うこと、また仮説ファイルにはその結果が反映されないことを明確に伝えます。先に統合ステップを実行する方法（インストール済みであれば、Learning／asb-interview-learning などの統合スキルを利用）を提案し、ユーザーが希望する場合はスナップショットとして作業を進めます。
4. 範囲： 基準日時点の状態、つまりデブリーフの件数、対象期間、インタビューが完了しているか一時停止中かを明記します。プロセスの途中で作成するレポートにも意義があります。その場合は、途中段階であることを明記します。

デブリーフがゼロ件の場合は報告する内容がないため、インタビューに戻るよう案内します。検証済みの調査結果を1つも裏付けられないほどコーパスが少ない場合（通常はデブリーフが3件以下）、その旨を冒頭で伝え、検証済みセクションを設けず、方向性とウォッチ項目をまとめた簡易レポートを正直に作成することを提案します。

フェーズ B — 全件確認（非表示）

草案を作成する前に、すべての情報を収集します。

• 仮説ファイルから： 検証済み、調整済み、否定済みの解決結果はすべて（変更履歴を含めて）調査結果の候補にします。未検証のまま残っている仮説は「分かっていないこと」に、ウォッチセクションの項目は 👀 の候補にします。
• デブリーフから： 実際に使われた語彙、きっかけとなった出来事や行動のエピソード、支払い意思額とその根拠、購入者・ユーザー・承認者に関する証拠、発見経路、対処方法、自発的に挙がった機能への要望、意外な発見（❗マーク）、割り引いて扱う教祖的な意見、さらに仮説ファイルには反映されていないものの、追記で繰り返し触れられている内容を収集します。
• 構成： 浮かび上がったセグメントとその特徴、セグメントに分かれて解消した矛盾と、実際にパターンが見つからなかったケースを整理します。
• 誠実さに関する情報： 募集経路とサンプリングの不足、うまく機能しなかった質問、達成されなかった目標を把握します。

調査結果が明確になった時点で F 番号を割り当て、各調査結果は1つの主張にします。証拠をそれぞれ個別に対応付けられるよう、複合的な主張は分けます。

フェーズ C — 全体を書いてからレビューする

まず、仮説ファイルと同じディレクトリに、完成稿全体を FINAL-REPORT.md として先にディスクへ書き込みます（パスが分からない貼り付け入力の場合は、書き込む前に手法のファイルが置かれている場所を尋ねます）。ファイル名が示すとおり、これは手法による完全な回答であり、その場にいなかった人に渡す唯一のファイルです。作業中のヘッダーを付けます。セッションは終了し、会話は途中で切れるため、ファイルが記憶の役割を果たします。その後、全体を提示して（ユーザーがファイルを直接読むことを希望しない限り、会話内に表示して）、ユーザーと小分けにレビューします。1回のやり取りでレビューするのは、1～2セクションです。デブリーフとの事実確認（記憶よりデブリーフを優先します。ユーザーの記憶も、あなたの記憶も同様です）、言い換え、要約の強調点の変更、ユーザーの解釈として明記した追加などを行います。ステータスの変更は、証拠を再確認し、実際に変更を裏付ける場合に限ります。各回のレビューがまとまるたびにファイルを更新し、ヘッダーのレビュー済み箇所を示すポインターを最新の状態に保ちます。これにより、新しいセッションでもディスク上の情報だけで再開できます。再開したセッションではソースファイルも読み直します。残りのレビューでは、引き続きデブリーフに照らして修正を確認するためです。レビューの途中で新たな証拠（忘れていたデブリーフや、遅れて届いたインタビューなど）が加わった場合は、すべてを再点検します。既存の F 番号はそのまま維持し、新しい発見には新しい番号を追加します。番号は決して振り直しません。内容が変わった確定済みのセクションは、要約を含め、もう一度レビューします。

レポートの構成

# Interview findings — <company / project>, <date>

> ⚠️ IN PROGRESS — draft under review with the user; reviewed through
> <section name — or "review not started; begin at Summary">. (This
> note is removed at finalization.)

<One line of scope: N interviews, date range, interviewing concluded
or ongoing. If the debriefs were never synthesized, the snapshot
caveat lives here AND in Provenance: "snapshot — this report performs
first-pass synthesis; HYPOTHESES.md does not reflect these findings.">

## Summary

<As brief as possible without losing salient information. Each line:
status mark + crisp claim + F-number, and nothing else — no citations,
no quotes, no commentary, no comparisons to prior beliefs, no history.
Wrong: "~ An established plumber still reports missed-call fallout —
which cuts against the assumption that tenure dulls the pain (F1)."
Right: "~ Established solo plumbers still lose jobs to missed calls
(F1)." The evolution story lives in the finding below.>

- ✓ <the most consequential validated fact> (F1)
- ✗ <the disproved belief, stated as present-tense knowledge> (F2)
- <segment split in one line, if one emerged> (F4, F5)
- ~ <the strongest directional claim> (F7)
- ? <the biggest open question> (F12)

## Who we talked to

<N conversations with dates and segments; how interviewees were
recruited; known sampling biases and who's missing.>

## What we know   (✓ validated · ✗ disproved)

<When a bar is empty, say so visibly — "Nothing validated yet: three
conversations cannot establish a pattern" or "No beliefs were
disproved this round" — emptiness stated is honesty; emptiness hidden
is spin.>

**F1.** ✓ <claim> — 8/8 debriefs.    [H4, G2]
  Evidence: 2026-06-12-tony.md: "two full weekends — call it 20
  hours" · 2026-06-29-jen.md: "a week of evenings — 25 hours, maybe
  more" · six more in the 18–25 band.

**F2.** ✗ <the overturned belief, restated as what is now known> —
  6/7.    [H7]
  Evidence: <citations and quotes, several when several exist>.

## What we think   (~ directional · 👀 watch)

**F7.** ~ <claim> — one voice, marked a revelation.    [H5]
  Evidence: <citation and quote>. Would settle it: <what evidence>.

**F9.** 👀 <parked observation, imported from the watch list>.
  Evidence: <citation and quote>.

## What we don't know

**F12.** ? <untested goal or hypothesis, and why — question misfired,
  never reached, segment missing>    [G6]
- <sampling gap and what it could distort — gaps are prose bullets;
  unresolved goals/hypotheses get F-numbers so the summary and later
  documents can cite them>

## Segments   (when segmentation emerged)

<Per segment: its markers, how to sort a prospect early, and the
per-segment differences in pain, price, and priorities — cited.>

## In their words

<The vocabulary bank: what they call themselves, the problem, the
product category, the pain — verbatim, attributed, loaded phrases
flagged as theirs.>

## For defining your ideal customer

Keystone candidates: <…> [F1, F4] · Deal-breaker candidates: <…> [F2]
Inciting events heard: <the actual trigger stories, quoted> [F5]
Sorting markers: <…> [F9] · Best-vs-worst signals: <…>
Decisions this raises: <…>
💡 <tentative implication — labeled with whose read it is and
"judgment, not a finding"; optional>

<When an expected input was never captured — no inciting events heard,
no channels probed — the brief says "none heard; a gap for the next
round" rather than silently omitting the line.>

## For positioning & messaging
## For pricing & packaging
## For marketing & sales
## For product priorities

<Same shape as the ideal-customer brief: marshaled [F-numbers] in the
exercise's own terms, decisions raised, labeled 💡 lines optional.>

## Provenance

Built from <files> as of <date>; synthesis runs through <date>;
<N> debriefs (<filenames>). The debriefs remain the primary sources.

フェーズ D — 最終化する

すべてのセクションのレビューが終わったとき、またはユーザーが残りのレビューを明示的に免除したときに、最終化します。作業中のヘッダーを削除し、F 番号を確定します。後の文書で参照される可能性があるため、将来改訂する場合は新しい番号を追加し、古い番号の振り直しや再利用はしません。そして最後に、要約をもう一度読み返します。人の目に触れる部分の大半は要約なので、最後に磨き上げます。最後に引き継ぎ内容を記載します。このレポートは、理想の顧客の定義、ポジショニング、価格設定など、後続の作業へのインプットであり、各領域の概要がその作業の出発点です。後日インタビューを続ける場合は、新しいデブリーフを統合してからレポートを改訂し、履歴を黙って上書きするのではなく、レポートの来歴に改訂内容を記録します。

拒否する条件

• デブリーフがない場合。 記録がなければ、報告できることもありません。デブリーフが作成されていないインタビューについて、ユーザーの記憶から発見事項を再構成することは断り、記録の手順を案内します。
• 事実を誇張する場合。 「上方修正して」「反証されたセクションを削除して」「もっと検証済みに見えるようにして」といった依頼には応じません。ステータスが成果物そのものであり、読者は目に見えない誇張を見抜けないためです。代わりに、誠実に調整できる点として、強調、表現、解釈であることを明記した追加を提案します。省略には下限があります。セクションまたは重要な箇条書きを削除できるのは、Provenance に「著者の依頼により省略。元ファイルには保持」と記載する場合に限ります。省略を目にできない読者は、その分を差し引いて評価できないため、この注記自体は交渉の余地がありません。これは、発見事項と同様に、「分かっていないこと」やサンプリングバイアスなど、誠実さに関わるセクションにも当てはまります。黙って省略してはいけません。
• 証拠を捏造またはシミュレートする場合。 発見事項で引用するのは、実際に行った会話の実際のデブリーフです。ロールプレイや AI が生成した「インタビュー」はレポートに含めません。
• 後続の作業を代行する場合。 ポジショニングステートメントの作成、理想の顧客の定義、価格設定、ロードマップの優先順位付けは断り、該当する概要を案内します。レポートはその作業へのインプットであり、作業そのものではありません。
• 証拠を覆す場合。 ユーザーが変更できるのは、言い換え、強調の調整、注記付きの省略、解釈であることを明記した追加です。ただし、証拠が変わらない限り、発見事項のステータスは変更しません。ユーザーが発見事項に同意しない場合は、その意見を証拠の代わりにするのではなく、証拠の横に、ユーザーによる判断であると明記して記録します。