meeting-minutes-taker

議事録作成

会議の生の文字起こしを、反復的なレビューを通じて、包括的で根拠に基づく議事録に変換します。

クイックスタート

前処理（任意ですが推奨）：

• ドキュメント変換：まず doc-to-markdown スキルを使って .docx/.pdf を Markdown に変換します（表や画像を保持できます）
• 文字起こしのクリーンアップ：文字起こしの品質が低い場合は、transcript-fixer スキルを使って ASR/STT の誤りを修正します
• コンテキストファイル：話者を正確に特定できるよう、チーム名簿を含む context.md を用意します

基本ワークフロー：

1. ユーザーが提供した文字起こしを読みます
2. ユーザーから提供されたプロジェクト固有のコンテキストファイルがあれば読み込みます（任意）
3. インテリジェントなファイル命名：内容からファイル名を自動生成します（以下を参照）
4. 話者の特定：文字起こしに「Speaker 1/2/3」がある場合は、まずユーザーに元のプラットフォームで話者を設定して再エクスポートするよう依頼します（Step 1.5 Phase 0 を参照）。テキストからの推測は最後の手段としてのみ行います
5. 複数回に分けた生成：コンテキストを分離して、複数回のパスまたはサブエージェントを使用し、UNION で統合します
6. references/completeness_review_checklist.md を使ってセルフレビューします
7. 人間が行ごとにレビューできるよう、ドラフトをユーザーに提示します
8. AI 間の比較（任意）：人間が他の AI ツール（Gemini、ChatGPT など）の出力を提供した場合は、バイアスを減らすために統合します
9. 人間が最終版を承認するまで、フィードバックを反映して修正を繰り返します

インテリジェントなファイル命名

文字起こしの内容から出力ファイル名を自動生成します。

パターン：YYYY-MM-DD-<topic>-<type>.md

要素	情報源	例
日付	文字起こしのメタデータ、または最初に言及された日付	2026-01-25
トピック	主な議題（2～4 語、ケバブケース）	api-design、product-roadmap
種類	会議のカテゴリ	review、sync、planning、retro、kickoff

例：

• 2026-01-25-order-api-design-review.md
• 2026-01-20-q1-sprint-planning.md
• 2026-01-18-onboarding-flow-sync.md

書き込む前に、提案したファイル名をユーザーに確認します。

基本ワークフロー

このチェックリストをコピーして、進捗を記録します。

Meeting Minutes Progress:
- [ ] Step 0 (Optional): Pre-process transcript with transcript-fixer
- [ ] Step 1: Read and analyze transcript
- [ ] Step 1.5: Speaker identification (if transcript has "Speaker 1/2/3")
  - [ ] Phase 0 FIRST: ask user to label speakers on the source platform (Feishu Minutes / Tencent Meeting), re-export, use labeled transcript
  - [ ] Fallback only (source labeling unavailable or declined by user):
    - [ ] Analyze speaker features (word count, style, topic focus)
    - [ ] Match against context.md team directory (if provided)
    - [ ] Present speaker mapping with per-speaker evidence to user for confirmation
- [ ] Step 1.6: Generate intelligent filename, confirm with user
- [ ] Step 1.7: Quality assessment (optional, affects processing depth)
- [ ] Step 2: Multi-turn generation (PARALLEL subagents with Task tool)
  - [ ] Create transcript-specific dir: <output_dir>/intermediate/<transcript-name>/
  - [ ] Launch 3 Task subagents IN PARALLEL (single message, 3 Task tool calls)
    - [ ] Subagent 1 → <output_dir>/intermediate/<transcript-name>/version1.md
    - [ ] Subagent 2 → <output_dir>/intermediate/<transcript-name>/version2.md
    - [ ] Subagent 3 → <output_dir>/intermediate/<transcript-name>/version3.md
  - [ ] Merge: UNION all versions, AGGRESSIVELY include ALL diagrams → draft_minutes.md
  - [ ] Final: Compare draft against transcript, add omissions
- [ ] Step 3: Self-review for completeness
- [ ] Step 3.5: Retrieval Self-Test (consumption-side verification)
  - [ ] Fresh-context subagent extracts future-query claims list from transcript ONLY (never sees draft) → intermediate/<transcript-name>/retrieval-claims.md
  - [ ] Hit-test each claim against retrievable layer (Key Decisions / Action Items / Parking Lot / Open Questions), by component, with lexical anchors
  - [ ] Revocation scan before ANY promotion; promote with [self-test promoted] tag + greppable verbatim quote; uncertain → Open Questions
  - [ ] Report "enumerated N / hits M / promoted K / uncertain list" (never a binary pass); fail-open with visible NOT-RUN note if extraction fails
- [ ] Step 4: Present draft to user for human review
- [ ] Step 5: Cross-AI comparison (if human provides external AI output)
- [ ] Step 6: Iterate on human feedback (expect multiple rounds)
- [ ] Step 7: Human approves final version

Note: <output_dir> = directory where final meeting minutes will be saved (e.g., project-docs/meeting-minutes/)
Note: <transcript-name> = name derived from transcript file (e.g., 2026-01-15-product-api-design)

Step 1：文字起こしの読み込みと分析

文字起こしを分析して、以下を特定します。

• 会議の議題と参加者
• 根拠となる引用を含む重要な決定事項
• 担当者を含むアクションアイテム
• 保留項目／未解決の質問

Step 1.5：話者の特定（必要な場合）

条件：文字起こしに「Speaker 1」「Speaker 2」「発言者1」などの一般的なラベルしかない場合。

Phase 0：元データ側でのラベル付け（必ず最初に試す）

文字起こしの取得元が、話者の手動ラベル付けに対応しているプラットフォーム（Feishu Minutes、Tencent Meeting、または話者ダイアライゼーションの編集ページがあるツール）の場合は、作業を中断し、議事録を作成する前に、元のプラットフォームで話者にラベルを付けて、ラベル付きの文字起こしを再エクスポート／再取り込みするようユーザーに依頼します。元のページへのリンクをユーザーに送ります。リンクは通常、文字起こしのフロントマター（minute_url、会議 URL）にあります。

推測よりもこの方法が優れている理由：

• プラットフォーム上でのラベル付けは、実際の声を聞いた人間が行うため、信頼できる情報源です。テキストからの推測では、会議中に名前を呼ばれた話者しか特定できず、それ以外の人は推測のままです。
• 複数の人がひとつのラベルにまとめられたダイアライゼーションの区間は、テキストだけでは復元できません。どれだけ推測しても解決できませんが、元データ側でラベルを付け直せば解決できます。
• 推測による出力では、あらゆる箇所に [inferred] マーカーが必要になり、話者ごとに人間によるレビューも必要になります。元データ側でラベル付けすれば、一度で正確な情報が得られます。

以下の場合のみ、下記の Phase A～C にフォールバックします。(a) ユーザーが推測で進めるよう明示的に指示した場合、または (b) 元データにラベルを付けられない場合（プラットフォームのページがない生の音声ファイル、編集権限がない場合など）。フォールバックする場合は、すべての対応付けに根拠と信頼度を付け、解決していないラベルはそのままにします（無理に割り当てないでください）。後でユーザーが元データにラベルを付けた場合は、議事録に戻って修正します。

フォールバックの方法（Anker Skill を参考）：

フェーズ A：特徴分析（パターン認識）

話者ごとに、以下を分析します。

特徴	確認する内容
単語数	発話した単語の合計数（多い＝シニア／リード、少ない＝オブザーバー）
セグメント数	発話した回数（頻繁＝積極的な参加者）
平均セグメント長	1回の発話あたりの平均単語数（長い＝プレゼンター、短い＝応答者）
フィラー比率	フィラー語（对/嗯/啊/就是/然后）の割合（低い＝準備された発言者）
話し方	フォーマル／インフォーマル、技術的な深さ、意思決定権限
トピックの焦点	主に話している分野（バックエンド、フロントエンド、プロダクトなど）
相互作用のパターン	他の人から質問されているか。タスクを割り当てているか。

分析出力の例：

Speaker Analysis:
┌──────────┬────────┬──────────┬─────────────┬─────────────┬────────────────────────┐
│ Speaker  │ Words  │ Segments │ Avg Length  │ Filler %    │ Role Guess             │
├──────────┼────────┼──────────┼─────────────┼─────────────┼────────────────────────┤
│ 发言人1  │ 41,736 │ 93       │ 449 chars   │ 3.6%        │ 主讲人 (99% of content)│
│ 发言人2  │ 101    │ 8        │ 13 chars    │ 4.0%        │ 对话者 (short responses)│
└──────────┴────────┴──────────┴─────────────┴─────────────┴────────────────────────┘

Inference rules:
- 占比 > 70% + 平均长度 > 100字 → 主讲人
- 平均长度 < 50字 → 对话者/响应者
- 语气词占比 < 5% → 正式/准备充分
- 语气词占比 > 10% → 非正式/即兴发言

フェーズ B：コンテキストのマッピング（コンテキストファイルが提供された場合）

ユーザーがプロジェクトのコンテキストファイル（例：context.md）を提供した場合：

1. チームディレクトリのセクションを読み込みます
2. 特徴のパターンを既知のチームメンバーに照合します
3. 役割と発話パターンを相互参照します

コンテキストファイルには以下を含めてください：

## Team Directory
| Name | Role | Communication Style |
|------|------|---------------------|
| Alice | Backend Lead | Technical, decisive, assigns backend tasks |
| Bob | PM | Product-focused, asks requirements questions |
| Carol | TPM | Process-focused, tracks timeline/resources |

フェーズ C：処理を進める前の確認

重要：話者の身元を決して黙って推測しないでください。

分析の概要をユーザーに提示します。

Speaker Analysis:
- Speaker 1 → Alice (Backend Lead) - 80% confidence based on: technical focus, task assignment pattern
- Speaker 2 → Bob (PM) - 75% confidence based on: product questions, requirements discussion
- Speaker 3 → Carol (TPM) - 70% confidence based on: timeline concerns, resource tracking

Please confirm or correct these mappings before I proceed.

ユーザーの確認後、文書全体でマッピングを一貫して適用します。

ステップ 1.7：文字起こしの品質評価（任意）

文字起こしの品質を評価し、処理の深さを決定します。

評価基準（1～10段階）：

要因	スコアへの影響
コンテンツ量	10k 文字超：+2、5～10k：+1、2k 未満：上限 3
フィラー語の割合	5% 未満：+2、5～10%：+1、10% 超：-1
話者の明瞭さ	メインの話者が 80% 超：+1（明確なプレゼンター）
技術的な深さ	技術的な内容が多い：+1

品質ランク：

スコア	ランク	処理方法
≥8	高	すべてのセクション、図、引用を含む、完全で構造化された議事録
5-7	中	標準的な議事録。主な決定事項とアクションアイテムに重点を置きます
<5	低	要約のみ。簡潔な要点をまとめ、詳細な文字起こしは省略します

評価例：

📊 Transcript Quality Assessment:
- Content: 41,837 chars (+2)
- Filler ratio: 3.6% (+2)
- Main speaker: 99% (+1)
- Technical depth: High (+1)
→ Quality Score: 10/10 (High)
→ Recommended: Full structured minutes with diagrams

ユーザーの判断が必要な場合：品質が低い（<5）場合は、ユーザーに尋ねます。

「文字起こしの品質が低い（断片的な会話／ノイズが多い）状態です。完全な議事録を生成しますか、それとも要約のみを生成しますか？」

ステップ 2：複数ターンでの初回生成（重要）

一度の処理では、必ず内容が失われます。 冗長性のある完全なパスを用いて、複数ターンで生成してください。

基本原則：複数の完全なパス＋UNION マージ

各パスでは、全文字起こしから**完全な議事録（すべてのセクション）**を生成します。コンテキストを分離して複数のパスを実行することで、それぞれ異なる詳細を拾い上げます。UNION マージで、すべての抽出結果を統合します。

❌ 誤り：対象を狭く絞ったパス（トークンを浪費し、偏りを招きます）

Pass 1: Only extract decisions
Pass 2: Only extract action items
Pass 3: Only extract discussion

✅ 正しい：コンテキストを分離した完全なパス

Pass 1: Generate COMPLETE minutes (all sections) → version1.md
Pass 2: Generate COMPLETE minutes (all sections) with fresh context → version2.md
Pass 3: Generate COMPLETE minutes (all sections) with fresh context → version3.md
Merge: UNION all versions, consolidate duplicates → draft_minutes.md

方針 A：逐次的な複数パス（各パスで完全な議事録を生成）

Pass 1: Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version1.md
Pass 2: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version2.md
Pass 3: Fresh context → Read transcript → Generate complete minutes → Write to: <output_dir>/intermediate/version3.md
Merge: Read all versions → UNION merge (consolidate duplicates) → Write to: draft_minutes.md
Final: Compare draft against transcript → Add any remaining omissions → final_minutes.md

戦略 B: 並列マルチエージェント (各エージェントが完全な議事録を作成) - 推奨

Task ツールを必ず使用して、分離されたコンテキストを持つ複数のサブエージェントを起動し、それぞれに完全な議事録を生成させます:

Task ツールを使用した実装:

// Launch ALL 3 subagents in PARALLEL (single message, multiple Task tool calls)
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version1.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version2.md
Task(subagent_type="general-purpose", prompt="Generate complete meeting minutes from transcript...", run_in_background=false) → version3.md

// After all complete:
Main Agent: Read all versions → UNION merge, consolidate duplicates → draft_minutes.md

重要: サブエージェントのプロンプトに必ず含めるもの:

1. 文字起こしファイルへの完全なパス
2. 出力ファイルへの完全なパス (文字起こし固有のサブディレクトリ内の version1.md、version2.md、version3.md)
3. 読み込むコンテキストファイル (提供されている場合はプロジェクト固有のコンテキスト、meeting_minutes_template.md)
4. ユーザーが提供した場合は参照画像/ドキュメント
5. 出力言語の要件 (ユーザーの言語設定に合わせ、技術用語は英語のまま保持する)
6. 引用のフォーマット要件 (後述の引用フォーマット要件セクションを参照)
7. 決定事項の認識ルール: 決定事項は言い回しではなく要素で識別する — ナラティブや事例検討の話に埋め込まれた指示であっても、権限 (誰が)、アクション (何をするか)、および任意で条件 (いつまでに) を備えていれば、それは依然として決定事項です。精度のためのガードレール: 本当に決定事項かどうか不明な場合は、主要な決定事項ではなく未解決の質問に振り分けてください (決定事項の表を決して水増ししないこと)。

複数回の完全なパスが機能する理由:

• 各パスは同じ内容を独立して分析します
• 異なるコンテキスト状態は異なる詳細を捉えます (単一のパスですべてを捉えることはできません)
• パス 1 は決定事項 X を捉えても、アクションアイテム Y を見落とすかもしれません
• パス 2 はアクションアイテム Y を捉えても、決定事項 X を見落とすかもしれません
• UNION マージによって X と Y の両方を捉えます

分離されたコンテキストが重要な理由:

• 各パス/エージェントは事前の思い込みなしに新しく開始します
• パス間の相互汚染がありません
• コンテキストの分離によって、異なる「視点」が自然に生まれます

段階的なコンテキストのオフロード (ファイルシステムを使用)

重要: 各パスの出力は会話コンテキストではなくファイルに書き込んでください。

パスの規約: すべての中間ファイルは、処理中の異なる文字起こし間の競合を避けるため、<output_dir>/intermediate/ の下の文字起こし固有のサブディレクトリに作成する必要があります。

重要: 文字起こし固有のサブディレクトリ構造を使用してください:

<output_dir>/intermediate/<transcript-name>/version1.md
<output_dir>/intermediate/<transcript-name>/version2.md
<output_dir>/intermediate/<transcript-name>/version3.md

例: 最終的な議事録が project-docs/meeting-minutes/2026-01-14-api-design.md になる場合:

• 中間ファイル: project-docs/meeting-minutes/intermediate/2026-01-14-api-design/version1.md
• これにより、同じセッションで複数の文字起こしを処理する際の競合を防ぎます
• intermediate/ フォルダーは .gitignore に追加する必要があります (一時的な作業ファイル)

// Create transcript-specific subdirectory first
mkdir: <output_dir>/intermediate/<transcript-name>/

// Launch all 3 subagents IN PARALLEL (must be single message with 3 Task tool calls)
Task 1 → Write to: <output_dir>/intermediate/<transcript-name>/version1.md (complete minutes)
Task 2 → Write to: <output_dir>/intermediate/<transcript-name>/version2.md (complete minutes)
Task 3 → Write to: <output_dir>/intermediate/<transcript-name>/version3.md (complete minutes)

Merge Phase:
  Read: <output_dir>/intermediate/<transcript-name>/version1.md
  Read: <output_dir>/intermediate/<transcript-name>/version2.md
  Read: <output_dir>/intermediate/<transcript-name>/version3.md
  → UNION merge, consolidate duplicates, INCLUDE ALL DIAGRAMS → Write to: draft_minutes.md

Final Review:
  Read: draft_minutes.md
  Read: original_transcript.md
  → Compare & add omissions → Write to: final_minutes.md

ファイルベースのコンテキストオフロードの利点:

• 会話コンテキストがクリーンに保たれます (トークンのオーバーフローを回避)
• 中間結果が永続化されます (必要に応じて再読み込み可能)
• 各パスは新しいコンテキストウィンドウで開始します
• マージフェーズは必要なものだけを読み込みます
• 人間がレビューのために中間ファイルを検査できます - 各パスが何を捉えたかを理解するために重要です
• コンテキストの上限を超える非常に長い文字起こしをサポートします
• 事後デバッグが可能になります - 最終出力に何かが欠けている場合、人間はどのパスが見落としたかを追跡できます

重要: 中間バージョンは常に文字起こし固有のサブディレクトリに保持してください:

• <output_dir>/intermediate/<transcript-name>/version1.md、version2.md、version3.md - 各サブエージェントの出力
• これらのファイルは、人間のレビュー担当者がマージプロセスを理解するのに役立ちます
• マージ後に中間ファイルを削除しないでください
• 人間が中間バージョンを比較してカバレッジのギャップを理解したいと考えるかもしれません
• intermediate/ を .gitignore に追加してください - これらは一時的な作業ファイルであり、最終的な成果物ではありません
• 文字起こし固有のサブディレクトリは、複数の文字起こしを処理する際の競合を防ぎます

出力要件

• 中国語での出力。ただし英語の技術用語はそのまま保持する
• 根拠に基づく意思決定 - 重要な意思決定にはすべて、裏付けとなる引用が必要
• 構造化されたセクション - エグゼクティブサマリー、主要な意思決定、ディスカッション、アクションアイテム、パーキングロット
• 適切な引用のフォーマット - 以下の引用フォーマット要件セクションを参照
• Mermaid 図（強く推奨） - 視覚的な図は議事録を単なるテキスト以上のものに引き上げます:
  • データベース／スキーマの議論には ER 図
  • データフローや API のやり取りには シーケンス図
  • プロセス／ワークフローの意思決定には フローチャート
  • 状態機械の議論には 状態遷移図
  • 図があると、人間が議事録をレビューして理解するのが格段に容易になります
• コンテキスト優先の文書構造 - レビュー対象の成果物（UI モックアップ、API ドキュメント、デザイン画像）はすべて、文書の先頭（メタデータの後、エグゼクティブサマリーの前）に配置して、意思決定の前にコンテキストを確立します。画像は meeting-media/<meeting-name>/ フォルダにコピーし、![description](meeting-media/...) 構文を使ってインラインで埋め込みます。視覚資料には簡単な説明を添えてください。これにより、読者がディスカッションを読む前に何が議論されたのかを理解できる、「次レベル」の人間に読みやすい議事録が生まれます
• 発言者の帰属 - 意思決定を正しく発言者に帰属させる

重要なルール

• 決して推測しない - 不明な場合はユーザーに確認を求める
• 議論を呼ぶ意思決定は逐語的に引用する
• アクションアイテムはチームではなく特定の個人に割り当てる
• 数値（範囲、件数、優先度）を保持する
• 常に複数パスを使用する - 1 回のターンではコンテンツが失われることが確実です
• 同等の用語を正規化する - 些細な違い（例:「バックエンドアーキテクチャ」と「バックエンド」、「API エンドポイント」と「エンドポイント」）は同等として扱います。発言者間でのそのような違いを指摘したり強調したりしないでください
• 単一の信頼できる情報源 - 各情報は 1 か所にのみ配置します。テーブル、リスト、要約をセクション間で重複させないでください（例: API リストはディスカッションまたはリファレンスのどちらか一方に属し、両方には属しません）
• 意思決定は言い回しではなく要素によって識別される - 「私たちは X を決定した」という表現は必須ではありません。誰が + 何をするか（+ 条件）を伴うナラティブ調の指示は、ディスカッションの散文に埋もれさせるのではなく、主要な意思決定に含めるべきです

ステップ 3: 完全性のためのセルフレビュー

初回生成の直後に、文字起こしと照らし合わせてレビューします:

Completeness Checklist:
- [ ] All discussion topics covered?
- [ ] All decisions have supporting quotes?
- [ ] All speakers attributed correctly?
- [ ] All action items have specific owners?
- [ ] Numerical values preserved (ranges, counts)?
- [ ] Entity relationships captured?
- [ ] State machines complete (all states listed)?

不足が見つかった場合は、何が漏れていたかに言及することなく、不足している内容を静かに追加します。

ステップ 3.5: 検索セルフテスト（消費側の検証）

このステップが存在する理由。 3 つの生成サブエージェントは、1 つのプロンプトと「意思決定とはどのようなものか」に関する 1 つの暗黙のモデルを共有しています。つまり、それらのエラーは相関しているため、UNION マージはコンテンツの損失からは守りますが、共有された盲点からは守りません。ステップ 3 のチェックリストは、すでに識別した意思決定を検証しますが、どのパスも意思決定として分類しなかったものを見つけることはできません。一方、議事録は検索によって消費されます。数週間後に誰かが「X は Y を必ず行うべきだと以前に言っていたか？」と尋ね、主要な意思決定／アクションアイテムのテーブルをざっと見るのです。ディスカッションの散文にしか存在しない指示は、コンテンツが「失われて」いなくても、そのクエリに応えられません。このステップは、その最終的な性質を直接テストします。（正直な範囲: これは 2 つ目の、部分的に相関を排除した想起レイヤーであり、神託ではありません。これがカバーしない既知の盲点: 語調が語用論的な力と矛盾する主張（「いいよ、ロードテストなしでやれば、警告しなかったとは言わせないからね」= 記録に残る異議）、および発話をまったく生まない暗黙の同意の瞬間。）

手順（マージ後、ドラフトを提示する前）:

1. 将来の問い合わせに関する主張リストを逆方向に抽出します。 コンテキストが新しいサブエージェントを1つ起動し、議事録だけを読み込ませます。下書きの議事録は絶対に見せてはいけません（話者名の対応表は問題ありません。アンカリングのリスクは名簿ではなく、下書きの構成に由来します）。タスクは次のとおりです。

   プロジェクトメンバーが1～8週間後に戻ってきて、「[person] は X について、指示／約束／決定／拒否／数値へのコミットをしたことがあるか？」と確認する場面を想定してください。そのような主張をすべて列挙します。各主張には、人物＋種類（指示／約束／決定／拒否／数値へのコミット／条件付き合意）＋内容＋対象範囲（あれば有効期限の条件も）＋タイムスタンプを含めます。明確な担当者がいる主張だけを含め、意見や背景説明は省きます。

   長い議事録（おおよそ60,000文字超、または90分超）の場合は、チャンクを重複させて抽出し、マージします。1回だけの処理では、長い会議の中で指示が埋もれがちな箇所で、文中情報の見落としが生じます。リストは <output_dir>/intermediate/<transcript-name>/retrieval-claims.md に書き込みます（チェックが実行されたことを監査でき、後から人間が確認できます）。

2. 各主張が検索可能なレイヤーに含まれているかヒットテストします（メインエージェント）：検索可能なレイヤーとは、重要な決定事項のタイトル＋決定事項の行、アクションアイテムの表、保留事項、未解決の質問です。ヒットとは、それらだけをざっと見た読者が、本文を読まなくても主張を見つけられることです。ヒットは要素ごとに判定します。人物／アクション／期限／有効期限の条件は、それぞれ記載されている必要があります（タスクを記載した表の行に有効期限の条件がない場合は、部分的な見落としです）。語彙上の手がかりを必須とします。行には主張の主要な人物名／アクションの語句が含まれていなければなりません。「LLMなら同じだと解釈できる」という意味上の一致だけでは認めません。将来それを読むのは、好意的に解釈してくれるモデルではなく、急いでいる人間だからです。

3. 見落としへの対処。 何かを追加する前に、撤回の確認を行います。議事録内で、同じトピックに関する後の撤回／変更／条件付けを検索します（「先ほど航空貨物と言いましたが、税関が確認するまで保留してください」など）。会議中に撤回された主張を、そのまま追加してはいけません。代わりに最終状態を記録します。この確認は必須です。撤回された決定を追加することだけが、このステップによって議事録を実施前よりも悪化させる可能性があるためです。その後、次のように処理します。

   • 見落としがあり、実際に指示／約束／決定である場合 → 重要な決定事項またはアクションアイテムに [self-test promoted] を付けて追加し、議事録内を検索して確認できる逐語引用とタイムスタンプを付記します（検索可能な引用がない追加は却下されます。これにより、幻覚的な主張のリスクを抑えます）。
   • 見落としがあり、不確かな場合 → 未解決の質問／保留事項に振り分けます。不確かな内容を決定事項の表に追加してはいけません。表の精度こそが、情報を検索可能にする要件です。
   • 見落としがあり、実際には単なる詳細である場合 → 議論のセクションに残し、問い合わせの対象にならない理由を説明できるようにします。

4. 二者択一の「合格」ではなく、結果を報告します。 出力は enumerated N / hits M / promoted K / uncertain list とし、下書きと並べて提示します。追加された行こそ、人間が特に慎重に確認すべき箇所です。ステップ3の暗黙の補完とは異なり、追加は決して黙って行われません。

5. 失敗時は処理を続行します。 抽出サブエージェントが停止する、または失敗した場合も、目立つ形で「Retrieval Self-Test: NOT RUN」という注記を付けて議事録を納品します。このゲートによって納品を止めてはいけません。正常な処理を誤ってブロックするゲートは、運用担当者に恒久的なスキップを促すことになります。

6. 反復ラウンドでは（ステップ6のフィードバックサイクル、複数AIのマージ）、納品前に少なくとも最終版に対してヒットテストを再実行します。そうしなければ、後のラウンドで追加された内容がチェックを完全にすり抜けてしまいます。

ステップ 4：人間によるレビューのためにユーザーに提示する

議事録全体を人間によるレビュー用のドラフトとして提示します。次の点を強調してください。

• 議事録は人間が注意深く一行ずつ確認する必要があります
• 分野の専門家は、AI が見落とす可能性のある用語の不整合に気づきます
• 最終版は、反復的なブラッシュアップを通じて完成します

ユーザーは次のことができます。

• そのまま承認する（複雑な会議ではまれです）
• 内容の抜けがないか、より詳細なレビューを依頼する
• 用語の問題を指摘する（例：既存システムとの命名の不整合）
• 比較用に、別の AI の出力を提供する

ステップ 5：複数の AI による比較（バイアスの軽減）

人間が別の AI ツール（Gemini、ChatGPT など）の出力を提供した場合：

このステップが有効な理由：

• AI モデルごとに異なるバイアスがあります — AI によって、拾い上げる詳細が異なります
• クロスバリデーション — 両方の出力に含まれる内容は、正確である可能性が高いです
• 抜けの検出 — 一方にのみ含まれる内容から、抜けの可能性を見つけられます
• 誤りの修正 — 一方の AI が、もう一方が見落とした事実誤認（誤った日付や出席者名など）に気づく場合があります

比較プロセス：

1. 外部 AI の出力を注意深く読む
2. 外部 AI の出力にあり、こちらのドラフトにない項目を特定する
3. 追加する前に、各項目を元の文字起こしと照合する（鵜呑みにしてコピーしない）
4. 外部 AI の出力に誤り（事実の誤認）がある項目を特定する — 記録はするが、誤りはコピーしない
5. 有効な新しい内容をこちらのドラフトに統合する
6. クロス比較に基づいて行った修正を記録する

複数の AI による比較で見つかった項目の例：

• API 認証方式に関する決定が抜けている ✓（こちらのドラフトに追加）
• 命名規則の仕様が抜けている ✓（こちらのドラフトに追加）
• 日付が誤っている（実際は 2026-01-14 なのに 2026-01-13）✗（誤りをコピーしない）
• 出席者名が誤っている ✗（誤りをコピーしない）
• データベースのパフォーマンスに関する懸念が抜けている ✓（保留事項に追加）

ステップ 6：人間からのフィードバックを反映して反復する（重要）

ユーザーがより詳細なレビューを依頼した場合（「詳細にレビュー」「もう一度確認」「抜けはある？」など）：

1. 文字起こしをセクションごとに読み直す
2. 各セクションを現在の議事録と照合する
3. エンティティ、フィールド名、数値範囲、状態遷移、トレードオフ、保留項目を確認する
4. 抜けている内容があれば追加する
5. セクションごとの徹底的なレビューをせずに、「抜けはありません」と決して断言しない

ユーザーが統合する別のバージョンを提供した場合：

統合の原則：統合し、削除はしない

1. 既存バージョンの内容をすべて保持する
2. 追加バージョンの新しい内容をすべて追加する
3. 重複を整理する（同じ情報を繰り返さない）
4. 詳細さに差がある場合は、より詳細なバージョンを残す
5. 論理的なセクション番号を維持する

図を積極的に含める（重要）

統合フェーズでは、すべてのバージョンの図を積極的にすべて含める必要があります。

図は、作成に労力を要する価値の高いコンテンツです。異なるサブエージェントが、注目した内容に基づいて異なる図を作成する場合があります。統合時に図を見落とすことは、大きな損失です。

図の統合方針：

1. 各バージョン（v1、v2、v3）のすべての図を一覧にする
2. 重複しない図はすべて含める — 図が冗長だと決めつけない
3. 似た図がある場合は、より詳細で完全なものを残す
4. 図が含まれる可能性のあるすべてのセクションを確認する：エグゼクティブサマリー、議論、API 設計、ステートマシン、データフローなど

確認する図の一般的な種類：

• シーケンス図（データフロー、API のやり取り）
• ER 図（データベーススキーマ、テーブル間の関係）
• 状態図（ステートマシン、ステータス遷移）
• フローチャート（判断フロー、プロセスワークフロー）
• コンポーネント図（システムアーキテクチャ）

例：v3 の図を見落とした場合 v3 に「ステータス照会メカニズム」のフローチャートがあり、v1 と v2 にはない場合、そのフローチャートは統合後の出力に必ず含めてください。他の図でカバーされていると決めつけないでください。

出力言語

• 基本方針： 文字起こしの言語（または指定がある場合はユーザーの希望）に合わせる
• 英語のまま保持： 技術用語、エンティティ名、略語（一般的な慣例に従う）
• 引用： 文字起こしの原文の言語を維持する

参照ファイル

ファイル	読み込むタイミング
meeting_minutes_template.md	初回の生成時 — テンプレートの構成が含まれています
completeness_review_checklist.md	レビュー手順の実施中 — 完全性チェックが含まれています
context_file_template.md	ユーザーによる context.md の作成を支援する際 — チームディレクトリのテンプレートが含まれています
プロジェクトのコンテキストファイル（ユーザー提供）	ユーザーがプロジェクト固有のコンテキスト（チームディレクトリ、用語、規約）を提供した際

推奨する前処理パイプライン

.docx の議事録向けのフルパイプライン：

Step 0: doc-to-markdown      # Convert .docx → Markdown (preserves tables/images)
        ↓
Step 0.5: transcript-fixer  # Fix ASR errors (optional, if quality is poor)
        ↓
Step 1+: meeting-minutes-taker  # Generate structured minutes

コマンド：

# 1. Install markitdown (one-time)
uv tool install "markitdown[pdf]"

# 2. Convert .docx to markdown
markitdown "录音转写.docx" -o transcript.md

# 3. Then use meeting-minutes-taker on transcript.md

組み合わせたワークフローのメリット：

• 表の保持：markitdown により、Word の表が Markdown の表に変換されます
• 画像の抽出：最終的な議事録に埋め込めます
• 引用の精度向上：transcript-fixer が引用の抽出前に ASR の誤りを修正します
• 話者の正確な識別：テキストが整っていると、スタイル分析の精度が向上します
• 直交設計：各スキルがそれぞれの役割に特化しており、組み合わせて使えるパイプラインです

よくあるパターン

アーキテクチャに関する議論 → Mermaid 図（次世代の議事録）

図を使うことで、議事録は単なるテキストを超えたものになります。 複雑な議論を、人間のレビュアーがすぐに理解できるようにします。図を追加できる機会を常に探してください。

図を使う場面：

• データフローに関する議論 → シーケンス図
• データベーススキーマに関する議論 → ER 図
• プロセス／ワークフローに関する決定 → フローチャート
• ステートマシンに関する議論 → 状態遷移図
• システムアーキテクチャ → コンポーネント図

例：データフロー（シーケンス図）

sequenceDiagram
    participant FE as Frontend
    participant BE as Backend
    participant SVC as External Service
    participant DB as Database
    FE->>BE: Click "Submit Order"
    BE->>SVC: POST /process (send data)
    SVC-->>BE: Return {status}
    BE->>DB: Save result
    BE-->>FE: Return success

例：データベーススキーマ（ER 図）

erDiagram
    ORDER ||--o{ ORDER_ITEM : "1:N"
    ORDER {
        uuid id PK
        string customer_name
        decimal total_amount
    }
    ORDER_ITEM {
        uuid id PK
        uuid order_id FK
        int quantity
    }

例：バージョン切り替え（ワークフロー図）

sequenceDiagram
    participant User
    participant System
    Note over System: Current: V2 Active
    User->>System: Create V3 (inactive)
    User->>System: Set V2 inactive
    User->>System: Set V3 active
    Note over System: New: V3 Active

引用の書式要件（重要）

引用には、必ず適切な Markdown の引用ブロック形式を使用し、別々の行に記述してください：

❌ 誤り：インラインの引用形式

* **Quote:** > "This is wrong" - **Speaker**

✅ 正しい：別々の行に記述する引用ブロック

* **Quote:**
  > "This is the correct format" - **Speaker**

✅ 正しい：複数の引用

* **Quote:**
  > "First quote from the discussion" - **Speaker1**
  > "Second quote supporting the same decision" - **Speaker2**

書式の主なルール：

• * **Quote:** は単独の行に記述します（この行に引用文を含めないでください）
• * **Quote:** の後に空行は不要です
• 引用文は2つのスペースでインデントし、その後に > を付けます
• 引用文の行末に話者の表記を付けます：- **SpeakerName**
• 複数の引用には同じインデントを使い、それぞれ別の行に記述します

技術的な決定 → 決定ブロック

### 2.X [Category] Decision Title

* **Decision:** Specific decision made
* **Logic:**
  * Reasoning point 1
  * Reasoning point 2
* **Quote:**
  > "Exact quote from transcript" - **Speaker Name**

保留項目 → ペンディング項目

「後で対応」「Phase 2」「MVP には含めない」などのキーワードを含む項目は、背景情報を添えてペンディング項目に記載します。

人間を介した反復（必須）

議事録は一度きりの出力ではありません。質の高い議事録は、複数回のレビュープロセスを経て作成されます。

人間によるレビューが重要な理由

1. 用語の競合：既存のシステムで使われている命名を人間は把握しています（例：「Note」は既存システムですでにコメントを意味している）
2. ドメインのコンテキスト：用語が別のものと混同される可能性がある場合、人間が気づきます（例：「UserProfile」と「Account」）
3. 組織に関する知識：人間はチームの規約や過去の決定を把握しています
4. 完全性の不足：何かが欠けていると感じた場合、人間は「詳細レビュー」を依頼できます

反復パターンの例

Round 1: Initial generation
  └─ Human review: "Check original transcript for missing items"
Round 2: Deep transcript review, add omitted content
  └─ Human review: "UserProfile conflicts with existing Account entity naming"
Round 3: Update terminology to use "CustomerProfile" instead
  └─ Human review: "Note field conflicts with existing Comment system"
Round 4: Update to use "Annotation" instead of "Note"
  └─ Human approval: Final version ready

主な原則

AI が初稿を作成し、人間が最終版に仕上げます。 初回の出力が完全である、または正しい用語を使っていると思い込まないでください。必ず人間によるレビューを促し、複数回の反復に備えてください。

アンチパターン

• ❌ ソースプラットフォームがラベル付けに対応しているのにテキストから話者を推定する - Feishu Minutes / Tencent Meeting で話者にラベルを付けてもらい、まず再エクスポートしてください (ステップ 1.5 フェーズ 0)。テキストからの推定では名前を呼ばれた話者しか判別できず、話者分離で統合されたセグメントは復元できません
• ❌ ドラフトを生成したのと同じメンタルモデルで自己レビューする - ステップ 3 のチェックリストは、各パスがすでに分類したものしか検証できません。共有された盲点 (例: ナラティブ調の指示) はすり抜けてしまいます。ステップ 3.5 のフレッシュコンテキストでの Retrieval Self-Test を実行してください。その抽出器はドラフトを決して見てはいけません
• ❌ 取り消しスキャンなしで自己テストの見落としを昇格させる - 会議の後半で覆された決定をそのまま昇格させると、誤った決定を表に書き込んでしまいます。これが、自己テストによって議事録がスキップするより悪くなる唯一のケースです
• ❌ 自己テストを単純な「合格」として報告する - 常に「列挙 N / ヒット M / 昇格 K / 不確実リスト」を報告してください。数字のない青信号は、人間が読むのをやめる習慣を植え付けます
• ❌ 単一パスでの生成 - 文字起こしを一度通すだけでは、コンテンツが確実に失われます
• ❌ 重複のない分割セクション - 各パスはセクションで分割せず、文字起こし全体をカバーしなければなりません
• ❌ 範囲を狭めたパス - 各パスは 1 種類のセクションだけでなく、完全な議事録 (すべてのセクション) を生成しなければなりません (トークンの無駄遣いとバイアスの原因になります)
• ❌ 裏付けとなる引用のない一般的な要約
• ❌ アクションアイテムを特定の個人ではなく「チーム」に割り当てる
• ❌ 数値 (優先度、範囲、状態数) の欠落
• ❌ 状態が不完全なステートマシン
• ❌ 要約せずに堂々巡りの議論をそのまま文字起こしする
• ❌ 複数バージョンのマージ時にコンテンツを削除する
• ❌ セクションごとのレビューなしに「何も欠落していない」と主張する
• ❌ 人間のレビューなしに初稿を最終版として扱う
• ❌ 既存システムとの競合を確認せずに用語を使用する
• ❌ サブエージェント間でのコンテキストの共有 (相互汚染とコンテンツの欠落を引き起こします)
• ❌ すべての中間出力を会話コンテキストに保持する (トークンオーバーフローを引き起こします。ファイルシステムを使用してください)
• ❌ 図のない純粋なテキストの議事録 - アーキテクチャやスキーマの議論には視覚的な表現がふさわしいです
• ❌ マージ後の中間ファイルの削除 - 人間のレビューとデバッグのために保持してください
• ❌ 外部 AI の出力を盲目的にコピーする - マージする前に必ず文字起こしと照合して検証してください
• ❌ AI 間の比較の機会を無視する - 異なる AI モデルは異なる詳細を捉えます
• ❌ サブエージェントの逐次実行 - 単一のメッセージ内で複数の Task ツール呼び出しを使用し、v1、v2、v3 のサブエージェントを並列で起動しなければなりません
• ❌ フラットな中間ディレクトリ - 競合を避けるため、文字起こし固有のサブディレクトリ intermediate/<transcript-name>/ を使用しなければなりません
• ❌ インラインでの引用フォーマット - 引用はインラインの > "quote" ではなく、別々の行にブロッククォート形式で記述しなければなりません
• ❌ マージ時の図の省略 - たとえ似ているように見えても、すべてのバージョンのすべての図を積極的に含めなければなりません
• ❌ 些細な用語の違いを指摘する - 話者間の「backend architecture」と「backend」や「API」と「endpoint」といった違いを指摘してはいけません。これらは同等の用語であり、そのような違いを指摘するのは敬意を欠きます
• ❌ セクション間でのコンテンツの重複 - 同じ情報を複数のセクションで繰り返してはいけません (例: API エンドポイントの表を「Discussion」と「Reference」の両方に記載する)。コンテンツは 1 つの信頼できる場所に配置し、必要に応じて参照してください
• ❌ 存在しないリンクの作成 - リポジトリに存在しないファイルへの Markdown リンクを作成してはいけません (例: [doc.md](reviewed-document))。リポジトリにない外部/ローカルドキュメントにはプレーンテキストを使用してください
• ❌ 統合時のコンテンツの喪失 - セクションを移動または統合する際は、すべての箇条書きと詳細が保持されていることを確認してください。「バッチ操作をサポート」や「ボタンで自動保存がトリガーされる」といった具体的な詳細を要約して失ってはいけません
• ❌ 役職名にドメインの詳細を追加する - 話者の帰属には Team Directory の Role 列のみを使用してください (例: 「Backend」、「Frontend」、「TPM」)。「Backend, Infrastructure」や「Backend, Business Logic」のような専門分野を追加してはいけません。同じ役職のチームメンバーはすべて同一の帰属を持つべきです

次のステップ：成果物形式でエクスポートする

議事録を整理した後、次の形式でのエクスポートを提案します。

Meeting minutes complete: [N] decisions, [M] action items captured.

Options:
A) Export as PDF — run /daymade-docs:pdf-creator (Recommended for sharing)
B) Export as slides — run /daymade-docs:ppt-creator (for presentation)
C) No thanks — the markdown is sufficient