rehearse-qa

質疑応答のリハーサル

本番前に質疑応答の練習をします。会場に合わせて調整された、批判的な人や好奇心旺盛な人などの聴衆をシミュレーションし、ユーザーが実際に書いた論文やスライドに基づいて、一度に一つずつ質問します。回答はすべて、簡潔で誠実な、回答を先に述べる形式になるよう指導します。話者が「誰にも聞かれたくない」と思っている質問も、漠然と恐れるのではなく、意識して準備します。

使用するタイミング

• 「論文について厳しく質問して」／「講演の質疑応答をリハーサルして」／「模擬質疑応答」
• 「聴衆からはどんな質問が出る？」／「受ける可能性がある最悪の質問は？」
• 「博士論文の審査／口頭試問の練習をして」／「ジョブトークの質問に備えて」
• ポスターセッションの準備（継続的な質疑応答、2分間および5分間のピッチ）
• write-talk-script／make-slides の後 — 講演の準備ができたら、台本にない部分をリハーサルします。simulate-reviewers の後 — その弱点リストを、恐れている質問の一覧に反映します。

入力

1. 論文（存在する場合はスライド／台本も）、読み取り可能な形式で用意します。 一時的に処理し、論文の文章をこのリポジトリにコピーしないでください。
2. 会場の形式と持ち時間：学会講演／ライトニングトーク／基調講演／ポスター／論文審査／ジョブトーク、および質疑応答の時間（分）。不明な場合は尋ねます。
3. 任意ですが、用意するとよりよいものとして、会場のプロフィール venues/conferences/<venue>-<year>.yml （スキーマは venues/schema.yml）があります。これを使うと、聴衆をその会場の分野に合わせられます。 プロフィールがない場合は、parse-cfp で作成するか、汎用的な聴衆設定で実行します。

プロセス

1. ドリル計画を作成します。 次を実行します。

   python3 scripts/qa_drill.py --setting conference-talk --minutes 3 \
       --venue venues/conferences/<venue>-<year>.yml
   

   決定論的に動作し、オフラインで実行されます。スロットの計算結果（実際にライブの発表枠で収まる質問数と、ドリルする質問数）、ペルソナの構成と各ペルソナへの割り当て数（--venue を指定した場合は会場の分野に合わせて調整）、ラウンド計画、回答時間の目標、およびステップ 6 用のトランスクリプトのひな形を出力します。機械処理用の出力には --json を、設定一覧には --help を指定してください。終了コード：0 は正常終了、2 は引数が不正、またはプロフィールが存在しないか解析できない場合です。

2. スロットを再確認します — 必須です。 会場プロフィールには発表枠の長さが記録されておらず、質疑応答の長さは年、トラック、セッションによって変わります。会場の最新の発表者向け案内を確認し（プロフィールの cfp_url と website から確認してください）、発表枠の長さ、質疑応答の時間、形式（司会者進行の質疑応答、ライトニングトークで質疑応答なし、ポスター発表の運営方法）を確認します。時間を誤ってリハーサルすると、誤った回答を練習することになります。何をいつ確認したかを明記してください。

3. 論文を読み、答えにくい質問の一覧を作ります。 限界、主張、実験の範囲、前提、割愛した内容、反論の履歴、不自然な数値、倫理、データの出所を洗い出します。完全なチェックリストと質問ごとの準備カードのテンプレートは、references/dreaded-questions.md を参照してください。確率 × ダメージで 8～15 個の質問に順位を付け、それぞれに誠実な回答カードを作成します。発表前に修正できる弱点があれば、その旨を伝えてください。リハーサルより修正を優先します。

4. 一問ずつドリルを実施します。 ラウンド計画（ウォームアップ → 厳しい連続質問 → 答えにくい質問の最終ラウンド → 早押し質問 → 変化球）に従います。実際の論文やスライドに基づいて、それぞれのペルソナになりきって質問したら、ユーザーの回答があるまで待ってから次に進みます。質問一覧をまとめて提示してはいけません。ペルソナの話し方、追加質問の仕方、会場や状況に応じた調整については、references/audience-personas.md を参照してください。先行研究に関するルール：ドリルの質問で実在の論文を挙げる場合は、find-papers と verify-citations で確認済みの論文に限ります。それ以外は、論文名を挙げずに「先行研究で X が行われたと主張する人がいるとします」のようにします。引用を捏造してはいけません。

5. すべての回答をコーチングします。 ユーザーの回答ごとにペルソナを中断し、references/answer-coaching.md に従って、5 部構成のフィードバック（判定／うまくいった点／修正点を 1 つ／論文で裏付けられる情報のみを使った模範回答／不合格の場合は再ドリル）を行います。回答を先に述べるテンプレートを指導します。つまり、要点を述べる一文、根拠を 1 つ、そしてそこで止めます。厳しい不合格だった質問は後で再度尋ねます。回答は、2 回うまく答えられた時点で初めてドリル済みとします。

6. トランスクリプトを決定論的に採点します。 ステップ 1 のひな形にやり取り（ユーザーが実際に話した、または入力した回答）を記録し、次を実行します。

   python3 scripts/grade_answers.py transcript.md --target 45 --max 75
   

   目標値はドリル計画に基づきます。各回答について、推定発話時間と目標／上限の比較、未回答の質問、曖昧な言い回しで始まる回答、フィラーの頻度、「はい／いいえ」で答える質問に対する結論の先送りをフラグとして示します。終了コード：0 は準備完了、1 は再ドリルが必要、2 は入力不正です。機械処理用の出力には --json を指定してください。

7. 準備状況レポートを作成します。 うまく答えられた質問、もう一度ラウンドが必要な質問（それぞれ修正点を 1 つ添える）、答えにくい質問の要点シート（質問 → 暗記する要点 → 数値を 1 つ）、および make-slides ／ write-talk-script に差し戻す「スライド自体を修正」すべき項目をまとめます。

出力

対話形式のドリルセッションに加えて、最後に（チャット上に。ファイルへの書き込みはユーザーが求めた場合のみ）、grade_answers.py による採点済みトランスクリプトレポート、発表当日の朝に確認するための答えにくい質問の要点シート、再ドリルのリストを提示します。質問の予測はしません。ドリルで回答を練習することは準備であり、何を質問されるかを保証するものではありません。

専門分野に合わせる

聴衆の構成は、scripts/qa_drill.py の会場 family: フィールド（FAMILY_LINEUPS）に基づいて決まります。フォークして、あなたのコミュニティの聴衆（例：人文科学セミナーの参加者、臨床分野のグランドラウンドのパネル）と、新しいペルソナがあればそれらを PERSONAS および references/audience-personas.md に追加してください。設定テーブル（SETTINGS）にも同じ方法で新しい形式を追加できます。

ガードレール

• 誠実な回答のみ。 制約や結果を隠したり、過小評価したり、誤って伝えたりする表現を決して助言しないでください。「Xを認めずに済む方法を教えて」という趣旨の依頼には応じず、認めたうえで範囲を明確にする回答を提案してください（こちらのほうが効果も高いです）。修正可能な弱点は、うまく切り抜ける練習ではなく、修正してください。
• 質問にもモデルの回答にも、引用を決して捏造しないでください。演習で先行研究に言及する場合は、find-papers と verify-citations を使うか、著者名などを挙げないでください。
• 論文が裏付けられない主張を、ユーザーの口から述べさせないでください。モデルの回答には、論文自体のエビデンスのみを使ってください。
• 発表枠やセッションの事実は、最新の会場ページで再確認してください（ステップ 2 は省略できません）。プロフィールには、発表枠に関する確定情報を記載しないでください。
• 論文は一時的に処理し、このリポジトリに論文のテキストを保存しないでください。
• ユーザーに代わって、セッション座長、委員会、投稿・会議システムに連絡しないでください。
• これはリハーサルであり、予言ではありません。練習で扱った質問が実際に聞かれると主張したり、発表の受け止められ方を予測したりしないでください。