会議記録作成者

反復的なレビューを通じて、生の会議トランスクリプトを包括的でエビデンスベースの会議記録に変換します。

クイックスタート

前処理（オプションですが推奨）：

• ドキュメント変換：doc-to-markdownスキルを使用して、まず.docx/.pdfをMarkdownに変換します（テーブル/画像を保持）
• トランスクリプトクリーンアップ：トランスクリプト品質が低い場合は、transcript-fixerスキルを使用してASR/STTエラーを修正します
• コンテキストファイル：正確な話者識別のためにチームディレクトリを含むcontext.mdを準備します

コアワークフロー：

1. ユーザーが提供したトランスクリプトを読む
2. ユーザーが提供した場合はプロジェクト固有のコンテキストファイルを読み込む（オプション）
3. 知的なファイル命名：コンテンツから自動生成ファイル名を生成（以下を参照）
4. 話者識別：トランスクリプトに「話者1/2/3」がある場合、生成前に話者を識別
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

ファイルを書き込む前に、提案されたファイル名をユーザーに確認させてください。

コアワークフロー

このチェックリストをコピーして進捗を追跡します：

会議記録進捗:
- [ ] ステップ0（オプション）：transcript-fixerでトランスクリプトを前処理
- [ ] ステップ1：トランスクリプトを読み取り、分析
- [ ] ステップ1.5：話者識別（トランスクリプトに「話者1/2/3」がある場合）
  - [ ] 話者機能を分析（単語数、スタイル、トピックフォーカス）
  - [ ] context.mdチームディレクトリと照合（提供された場合）
  - [ ] 確認のため話者マッピングをユーザーに提示
- [ ] ステップ1.6：知的なファイル名を生成、ユーザーに確認
- [ ] ステップ1.7：品質評価（オプション、処理の深さに影響）
- [ ] ステップ2：複数ターン生成（タスクツールで並列サブエージェント）
  - [ ] トランスクリプト固有のディレクトリを作成：<output_dir>/intermediate/<transcript-name>/
  - [ ] 3つのタスクサブエージェントを並列で起動（1つのメッセージ、3つのタスクツール呼び出し）
    - [ ] サブエージェント1 → <output_dir>/intermediate/<transcript-name>/version1.md
    - [ ] サブエージェント2 → <output_dir>/intermediate/<transcript-name>/version2.md
    - [ ] サブエージェント3 → <output_dir>/intermediate/<transcript-name>/version3.md
  - [ ] マージ：すべてのバージョンをUNION、すべてのダイアグラムを攻撃的に含める → draft_minutes.md
  - [ ] 最終：ドラフトをトランスクリプトと比較、漏れを追加
- [ ] ステップ3：完全性のための自己レビュー
- [ ] ステップ4：ユーザーにドラフトを人間レビューのために提示
- [ ] ステップ5：クロスAI比較（人間が外部AIの出力を提供する場合）
- [ ] ステップ6：人間のフィードバックに基づいて反復（複数のラウンドを予想）
- [ ] ステップ7：人間が最終版を承認

注：<output_dir> = 最終的な会議記録が保存されるディレクトリ（例：project-docs/meeting-minutes/）
注：<transcript-name> = トランスクリプトファイルから導出された名前（例：2026-01-15-product-api-design）

ステップ1：トランスクリプトを読み取り、分析

トランスクリプトを分析して、以下を識別します：

• 会議のトピックと参加者
• サポートする引用のある重要な決定
• オーナーのあるアクションアイテム
• 保留中の項目/未解決の質問

ステップ1.5：話者識別（必要な場合）

トリガー：トランスクリプトに「話者1」、「話者2」、「発言人1」などの一般的なラベルしかない場合。

アプローチ（Ankerスキルから着想）：

フェーズA：機能分析（パターン認識）

各話者について、以下を分析します：

機能	探すもの
単語数	話された総単語数（多い＝シニア/リード、少ない＝オブザーバー）
セグメント数	話す回数（頻繁＝活動的な参加者）
平均セグメント長	ターンあたりの平均単語数（長い＝プレゼンター、短い＝レスポンダー）
フィラー比率	フィラー単語の% - 低い＝準備万端のスピーカー
話し方	正式/非正式、技術的深さ、決定権限
トピックフォーカス	最もよく議論する分野（バックエンド、フロントエンド、プロダクトなど）
相互作用パターン	他の人が彼らに質問しますか？彼らはタスクを割り当てますか？

分析出力例：

話者分析:
┌──────────┬────────┬──────────┬─────────────┬─────────────┬────────────────────────┐
│ 話者     │ 単語数 │セグメント│ 平均長      │ フィラー%   │ 役割推測                │
├──────────┼────────┼──────────┼─────────────┼─────────────┼────────────────────────┤
│ 発言人1  │ 41,736 │ 93       │ 449字       │ 3.6%        │ 主讲人（内容の99%）     │
│ 発言人2  │ 101    │ 8        │ 13字        │ 4.0%        │ 対話者（短い応答）      │
└──────────┴────────┴──────────┴─────────────┴─────────────┴────────────────────────┘

推論ルール:
- 占比 > 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：進行前に確認

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

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

話者分析:
- 話者1 → Alice（バックエンドリード）- 信頼度80%：技術的フォーカス、タスク割り当てパターンに基づく
- 話者2 → Bob（PM）- 信頼度75%：プロダクト質問、要件の議論に基づく
- 話者3 → Carol（TPM）- 信頼度70%：タイムライン関係者、リソース追跡に基づく

進行前にこれらのマッピングを確認または修正してください。

ユーザーが確認した後、ドキュメント全体を通じてマッピングを一貫して適用します。

ステップ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	低	概要のみ - 簡潔なハイライト、詳細なトランスクリプションをスキップ

評価例：

📊 トランスクリプト品質評価:
- コンテンツ：41,837文字（+2）
- フィラー比率：3.6%（+2）
- メイン話者：99%（+1）
- 技術的深さ：高（+1）
→ 品質スコア：10/10（高）
→ 推奨：ダイアグラム付きの完全構造化記録

ユーザーの意思決定ポイント：品質が低い場合（<5）、ユーザーに確認してください：

"トランスクリプト品質が低い（断片的な対話/ノイズが多い）。完全な記録と概要のどちらを生成しますか？"

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

単一パスは絶対にコンテンツを失います。 冗長な完全パスを使用した複数ターン生成を使用してください：

コア原則：複数の完全パス + UNIONマージ

各パスは、フルトランスクリプトからすべてのセクションを含む完全な記録を生成します。隔離されたコンテキストを持つ複数パスは異なる詳細をキャッチします。UNIONマージはすべての結果を統合します。

❌ 間違い：狭いフォーカスのパス（トークンを無駄にし、バイアスを引き起こす）

パス1：決定のみ抽出
パス2：アクションアイテムのみ抽出
パス3：議論のみ抽出

✅ 正解：隔離されたコンテキストを持つ完全パス

パス1：完全な記録を生成（すべてのセクション） → version1.md
パス2：新しいコンテキストで完全な記録を生成（すべてのセクション） → version2.md
パス3：新しいコンテキストで完全な記録を生成（すべてのセクション） → version3.md
マージ：すべてのバージョンをUNION、重複を統合 → draft_minutes.md

戦略A：連続した複数パス（各パスで完全な記録）

パス1：トランスクリプトを読む → 完全な記録を生成 → <output_dir>/intermediate/version1.mdに書き込み
パス2：新しいコンテキスト → トランスクリプトを読む → 完全な記録を生成 → <output_dir>/intermediate/version2.mdに書き込み
パス3：新しいコンテキスト → トランスクリプトを読む → 完全な記録を生成 → <output_dir>/intermediate/version3.mdに書き込み
マージ：すべてのバージョンを読む → UNION マージ（重複を統合） → draft_minutes.mdに書き込み
最終：ドラフトをトランスクリプトと比較 → 残りの漏れを追加 → final_minutes.mdに書き込み

戦略B：並列マルチエージェント（各エージェントで完全な記録）- 推奨

タスクツールを使用して、隔離されたコンテキストを持つ複数のサブエージェントを生成し、それぞれが完全な記録を生成する必要があります：

タスクツールを使用した実装：

// すべての3つのサブエージェントを並列で起動（単一のメッセージ、複数のタスクツール呼び出し）
Task(subagent_type="general-purpose", prompt="トランスクリプトから完全な会議記録を生成...", run_in_background=false) → version1.md
Task(subagent_type="general-purpose", prompt="トランスクリプトから完全な会議記録を生成...", run_in_background=false) → version2.md
Task(subagent_type="general-purpose", prompt="トランスクリプトから完全な会議記録を生成...", run_in_background=false) → version3.md

// すべて完了後:
メインエージェント：すべてのバージョンを読む → UNION マージ、重複を統合 → draft_minutes.md

重要：サブエージェントプロンプトに以下を含める必要があります：

1. トランスクリプトファイルへのフルパス
2. アウトプットファイルへのフルパス（version1.md、version2.md、version3.mdはトランスクリプト固有のサブディレクトリ内）
3. 読み込むコンテキストファイル（プロジェクト固有のコンテキスト、提供されている場合、meeting_minutes_template.md）
4. ユーザーが提供した参照画像/ドキュメント
5. 出力言語要件（ユーザーの言語設定に合わせる、技術用語は英語のままにする）
6. 引用フォーマット要件（下記の引用フォーマット要件セクションを参照）

複数の完全パスが機能する理由：

• 各パスは同じコンテンツを独立して分析
• 異なるコンテキスト状態は異なる詳細をキャッチ（単一パスはすべてをキャッチしません）
• パス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に追加する必要があります（一時的な作業ファイル）

// トランスクリプト固有のサブディレクトリを最初に作成
mkdir: <output_dir>/intermediate/<transcript-name>/

// すべての3つのサブエージェントを並列で起動（1つのメッセージ、3つのタスクツール呼び出し必須）
タスク1 → 書き込み先：<output_dir>/intermediate/<transcript-name>/version1.md（完全な記録）
タスク2 → 書き込み先：<output_dir>/intermediate/<transcript-name>/version2.md（完全な記録）
タスク3 → 書き込み先：<output_dir>/intermediate/<transcript-name>/version3.md（完全な記録）

マージフェーズ:
  読み込み：<output_dir>/intermediate/<transcript-name>/version1.md
  読み込み：<output_dir>/intermediate/<transcript-name>/version2.md
  読み込み：<output_dir>/intermediate/<transcript-name>/version3.md
  → UNION マージ、重複を統合、すべてのダイアグラムを含める → draft_minutes.mdに書き込み

最終レビュー:
  読み込み：draft_minutes.md
  読み込み：元のトランスクリプト.md
  → 比較して漏れを追加 → final_minutes.mdに書き込み

ファイルベースのコンテキスト削減の利点：

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

重要：トランスクリプト固有のサブディレクトリに中間バージョンを常に保持：

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

出力要件

• 中国語の出力（英語の技術用語は保持）
• エビデンスベースの決定 - すべての重要な決定には支援する引用が必要
• 構造化されたセクション - Executive Summary、Key Decisions、Discussion、Action Items、Parking Lot
• 適切な引用フォーマット - 下記の引用フォーマット要件セクションを参照
• Mermaidダイアグラム（強く推奨） - ビジュアルダイアグラムは記録を純粋なテキスト以上のレベルに引き上げます：
  • ER図 - データベース/スキーマディスカッション用
  • シーケンス図 - データフロー、APIインタラクション用
  • フローチャート - プロセス/ワークフロー決定用
  • 状態図 - ステートマシンディスカッション用
  • ダイアグラムは記録を人間がレビュー・理解しやすくします
• コンテキストファースト文書構造 - すべてのレビュー済みアーティファクト（UI モックアップ、API ドキュメント、設計画像）をドキュメントの最上部（メタデータの後、Executive Summary の前）に配置して、決定を読む前にコンテキストを確立します。meeting-media/<meeting-name>/ フォルダに画像をコピーし、![description](meeting-media/...) 構文を使用してインライン埋め込みします。ビジュアルに簡潔な説明を含めます - これにより、読者が議論を読む前に何が議論されたかを理解する「次のレベル」の人間が読める記録を作成します
• 話者の帰属 - 決定を正しい話者に帰属させます

主要ルール

• 仮定しない - 不明な場合はユーザーに確認を求める
• 物議を醸す決定を逐語的に引用
• アクションアイテムをチームではなく特定の人に割り当てる
• 数値（範囲、数、優先度）を保持
• 常に複数パスを使用 - 単一ターンはコンテンツを失うことが保証
• 同等の用語を正規化 - 些細なバリエーション（「バックエンドアーキテクチャ」対「バックエンド」、「APIエンドポイント」対「エンドポイント」）を同等として扱う。話者間のそのような違いを指摘したり強調したりしないでください
• 単一の情報源 - 各情報を1つの場所のみに配置する。セクション全体にテーブル、リスト、概要を複製しないでください（例えば、APIリストは「Discussion」または「Reference」にありますが、両方ではなく）

ステップ3：完全性のための自己レビュー

初期生成後、すぐにトランスクリプトに対してレビューします：

完全性チェックリスト:
- [ ] すべての議論トピックが対象となっていますか？
- [ ] すべての決定に支援する引用がありますか？
- [ ] すべての話者が正しく帰属していますか？
- [ ] すべてのアクションアイテムに特定のオーナーがいますか？
- [ ] 数値が保持されていますか（範囲、数）？
- [ ] エンティティの関係がキャプチャされていますか？
- [ ] ステートマシンが完全ですか（すべての状態がリストされていますか）？

ギャップが見つかった場合、見落とされたコンテンツを黙って追加します。

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

完全な記録をドラフトとしてユーザーにレビュー用に提示します。以下を強調します：

• 記録は注意深い行ごとの人間レビューが必要です
• ドメイン専門家がAIが見落とす可能性のある用語の矛盾をキャッチします
• 最終版は反復的な洗練を通じて出現します

ユーザーは以下を実行できます：

• そのまま受け入れる（複雑な会議では珍しい）
• 欠落しているコンテンツについてのより深いレビューをリクエスト
• 用語の問題を識別（例えば、既存システムとの命名の矛盾）
• 別のAIの出力をクロス比較のために提供

ステップ5：クロスAI比較（バイアスを軽減）

別のAIツール（Gemini、ChatGPTなど）の出力をユーザーが提供する場合：

このステップは価値があります。理由は以下の通り：

• 異なるAIモデルは異なるバイアスを持ちます - 各AIは異なる詳細をキャッチします
• クロス検証 - 両方の出力に表示されるコンテンツは正確である可能性が高い
• ギャップ検出 - 一方にあり、もう一方にないコンテンツは潜在的な漏れを明らかにします
• エラー修正 - AIがもう一方が見落とした可能性のある事実エラーをキャッチします（例えば、間違った日付、間違った出席者名）

比較プロセス：

1. 外部AIの出力を注意深く読む
2. 外部出力に存在するが当社のドラフトに欠けている項目を識別
3. 各項目を元のトランスクリプトに対して検証してから追加（盲目的にコピーしない）
4. 外部AIがエラーを持つ項目を識別（間違った事実）- メモに記載しますが、エラーはコピーしません
5. 有効な新しいコンテンツを当社のドラフトに UNION マージ
6. クロス比較に基づいて行われた修正を文書化

クロスAI比較から見つかった例：

• API認証方法についての欠落された決定 ✓（当社のドラフトに追加）
• 欠落された命名規約の仕様 ✓（当社のドラフトに追加）
• 間違った日付（2026-01-13対実際の2026-01-14）✗（エラーをコピーしない）
• 間違った出席者名 ✗（エラーをコピーしない）
• 欠落されたデータベースパフォーマンスの懸念 ✓（Parking Lotに追加）

ステップ6：人間のフィードバックに基づいて反復（重要）

ユーザーがより深いレビューをリクエストする場合（「深いレビュー」、「もう一度確認」、「何か欠けていますか」）：

1. トランスクリプトをセクションごとに再読
2. 各セクションを現在の記録と比較
3. 以下を探す：エンティティ、フィールド名、数値範囲、状態遷移、トレードオフ、保留中の項目
4. 省略されたコンテンツを追加
5. 徹底的なセクションごとのレビューなしに「何も欠けていない」と主張しないでください

別のバージョンをマージするときにユーザーが提供する場合：

マージの原則：UNION、決して削除しない

1. 既存バージョンのすべてのコンテンツを保持
2. 着信バージョンのすべての新しいコンテンツを追加
3. 重複を統合（同じ情報を繰り返さない）
4. 深さが異なる場合は、より詳細なバージョンを保持
5. 論理的なセクション番号を維持

攻撃的なダイアグラムの包含（重要）

マージフェーズ中、すべてのバージョンからすべてのダイアグラムを攻撃的に含める必要があります。

ダイアグラムは高価値のコンテンツであり、生成するのに努力がかかったものです。異なるサブエージェントは彼らが焦点を当てたことに基づいて異なるダイアグラムを作成する可能性があります。マージ中にダイアグラムが欠落するのは大きな損失です。

マージダイアグラム戦略：

1. すべてのダイアグラムをインベントリ化 - 各バージョン（v1、v2、v3）からすべてのダイアグラム
2. すべてのユニークなダイアグラムを含める - ダイアグラムが冗長だと仮定しない
3. 類似ダイアグラムが存在する場合、より詳細/完全なものを保持
4. すべてのセクションをチェック - ダイアグラムを含む可能性のあるセクション：Executive Summary、Discussion、API設計、状態機械、データフロー、など

一般的なダイアグラムタイプを探す：

• シーケンス図（データフロー、APIインタラクション）
• ER図（データベーススキーマ、テーブル関係）
• 状態図（ステートマシン、ステータス遷移）
• フローチャート（決定フロー、プロセスワークフロー）
• コンポーネント図（システムアーキテクチャ）

例：v3から見落とされたダイアグラム v3に「ステータスクエリメカニズム」のフローチャートがあるが、v1/v2にはない場合、そのフローチャートはマージされた出力に表示されなければなりません。他のダイアグラムで対象になっていると仮定しないでください。

出力言語

• 主要言語： トランスクリプトの言語に合わせる（またはユーザーが指定した場合）
• 英語で保持： 技術用語、エンティティ名、略語（標準的な慣行）
• 引用： トランスクリプトの元の言語を保持

リファレンスファイル

ファイル	いつ読み込む
meeting_minutes_template.md	最初の生成 - テンプレート構造を含む
completeness_review_checklist.md	レビューステップ中 - 完全性チェックを含む
context_file_template.md	ユーザーが context.md を作成するのを支援する場合 - チームディレクトリテンプレートを含む
プロジェクトコンテキストファイル（ユーザー提供）	ユーザーがプロジェクト固有のコンテキスト（チームディレクトリ、用語、規約）を提供する場合

推奨される前処理パイプライン

.docx トランスクリプト用の完全なパイプライン：

ステップ0：doc-to-markdown      # .docx → Markdown に変換（テーブル/画像を保持）
        ↓
ステップ0.5：transcript-fixer  # ASR エラーを修正（品質が低い場合はオプション）
        ↓
ステップ1+：meeting-minutes-taker  # 構造化記録を生成

コマンド：

# 1. markitdown をインストール（1回限り）
uv tool install "markitdown[pdf]"

# 2. .docx を markdown に変換
markitdown "录音转写.docx" -o transcript.md

# 3. 次に meeting-minutes-taker を transcript.md で使用

コンボワークフローの利点：

• テーブルが保持される：markitdown は Word テーブルを Markdown テーブルに変換
• 画像が抽出される：最終的な記録に埋め込むことができます
• クリーンな引用：transcript-fixer は引用抽出前に ASR タイプを削除
• 正確な話者 ID：クリーンテキストでのスタイル分析がより効果的に機能
• 直交設計：各スキルは1つのことをうまくやり、構成可能なパイプライン

一般的なパターン

アーキテクチャディスカッション → 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:** > "これは間違っています" - **話者**

✅ 正解：別の行のブロッククォート

* **Quote:**
  > "これが正しいフォーマットです" - **話者**

✅ 正解：複数の引用

* **Quote:**
  > "議論からの最初の引用" - **話者1**
  > "同じ決定をサポートする2番目の引用" - **話者2**

主要なフォーマットルール：

• * **Quote:** は独自の行です（この行に引用コンテンツはありません）
• * **Quote:** の後に空行は不要です
• 引用コンテンツは2スペースでインデント、その後 > プリフィックス
• 話者の帰属は引用行の末尾：- **話者名**
• 複数の引用は同じインデント、各行は独自の行です

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

### 2.X [カテゴリ] 決定タイトル

* **Decision:** 下された具体的な決定
* **Logic:**
  * 推論ポイント1
  * 推論ポイント2
* **Quote:**
  > "トランスクリプトからの正確な引用" - **話者名**

保留項目 → Parking Lot

「後で延期」、「フェーズ2」、「MVP に含まれない」などのキーワードを含む項目は、コンテキストとともに Parking Lot に移動します。

ヒューマンインザループの反復（必須）

会議記録はワンショット出力ではありません。高品質な記録は複数のレビューサイクルを通じて出現します：

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

1. 用語の矛盾：既存システムの命名を人間は知っています（例えば、「Note」は既存システムでコメントを意味する）
2. ドメインコンテキスト：人間は用語が別のものと混同される可能性があることをキャッチします（例えば、「UserProfile」対「Account」）
3. 組織的知識：人間はチーム規約と以前の決定を知っています
4. 完全性ギャップ：人間は何か欠けていると感じるときに「深いレビュー」をリクエストできます

例の反復パターン

ラウンド1：初期生成
  └─ 人間レビュー：「元のトランスクリプトで欠落した項目を確認」
ラウンド2：トランスクリプトの深いレビュー、省略されたコンテンツを追加
  └─ 人間レビュー：「UserProfile は既存の Account エンティティ命名と競合します」
ラウンド3：「CustomerProfile」の代わりに「Account」を使用するように用語を更新
  └─ 人間レビュー：「Note フィールドは既存の Comment システムと競合します」
ラウンド4：「Annotation」の代わりに「Note」を使用するように更新
  └─ 人間承認：最終版の準備完了

主要な原則

AIは最初のドラフトを生成します。人間は最終版に洗練させます。 最初の出力が完全であるか正しい用語を使用していると仮定しないでください。常に人間レビューを促し、複数の反復サイクルに備えてください。

アンチパターン

• ❌ 単一パス生成 - トランスクリプト全体の1ターンは絶対にコンテンツを失う
• ❌ オーバーラップなしの分割セクション - 各パスはフルトランスクリプトをカバーする必要があります
• ❌ セクションタイプごとの狭いフォーカスパス - 各パスは完全な記録（すべてのセクション）を生成する必要があります（トークンを無駄にし、バイアスを引き起こす）
• ❌ サポート引用がない一般的なサマリー
• ❌ チームではなく特定の人ではなく「チーム」に割り当てられたアクションアイテム
• ❌ 欠落された数値（優先度、範囲、状態数）
• ❌ 不完全な状態のステートマシン
• ❌ 要約ではなく逐語的に転写された円形の議論
• ❌ 複数バージョンマージ中のコンテンツ削除
• ❌ セクションごとのレビューなしに「何も欠けていない」と主張
• ❌ 人間レビューなしに最初のドラフトを最終として扱う
• ❌ 既存システムとの競合を確認せずに用語を使用
• ❌ サブエージェント間の共有コンテキスト（相互汚染を引き起こし、コンテンツを見落とす）
• ❌ 会話コンテキストにすべての中間出力を保持（トークンオーバーフロー、ファイルシステムを使用）
• ❌ ダイアグラムなしの純粋なテキスト記録 - アーキテクチャ/スキーマディスカッションはビジュアル表現に値します
• ❌ マージ後の中間ファイル削除 - 人間レビューとデバッグのために保持
• ❌ トランスクリプトに対する検証なしで外部AIの出力を盲目的にコピー - マージ前に常に検証
• ❌ クロスAI比較の機会を無視 - 異なるAIモデルは異なる詳細をキャッチ
• ❌ 顧序的なサブエージェント実行 - 複数のタスクツール呼び出しを単一のメッセージで使用して、v1、v2、v3 サブエージェントを並列で起動する必要があります
• ❌ フラットな中間ディレクトリ - 競合を避けるため、トランスクリプト固有のサブディレクトリ intermediate/<transcript-name>/ を使用する必要があります
• ❌ インライン引用フォーマット - 引用はインライン > "quote" ではなく、別の行でブロッククォート形式を使用する必要があります
• ❌ マージ中のダイアグラム省略 - すべてのバージョンからすべてのダイアグラムを攻撃的に含める必要があります
• ❌ 些細な用語バリエーションの強調 - 話者間の「バックエンドアーキテクチャ」対「バックエンド」や「API」対「エンドポイント」などの違いを指摘しないでください。これらは同等の用語であり、そのような違いを強調することは失礼です
• ❌ セクション全体での重複コンテンツ - 同じ情報を複数のセクションで繰り返しません（例えば、APIエンドポイントテーブルは「Discussion」または「Reference」にありますが、両方ではなく）。コンテンツを1つの正式な場所に配置し、必要に応じて参照します
• ❌ リポジトリに存在しないファイルへのリンク作成 - リポジトリにないファイルのマークダウンリンクを作成しません（例：[doc.md](reviewed-document)）。リポジトリ内にない外部/ローカルドキュメントの場合はプレーンテキストを使用
• ❌ 統合中のコンテンツ損失 - セクションを移動または統合するとき、すべての箇条書きと詳細が保存されていることを確認します。「バッチ操作をサポート」または「ボタンが自動保存をトリガー」などの特定の詳細を決して要約で失わないでください
• ❌ 役割名へのドメイン詳細の追加 - チームディレクトリの「役割」列のみを話者帰属に使用します（例：「Backend」、「Frontend」、「TPM」）。「Backend, Infrastructure」や「Backend, Business Logic」などの特殊化を役割に追加しません - 同じ役割の全チームメンバーは同一の帰属を持つべきです

次のステップ：配布可能形式にエクスポート

会議記録を構造化した後、エクスポートを提案します：

会議記録完了：[N]個の決定、[M]個のアクションアイテムをキャプチャ。

オプション：
A) PDFにエクスポート — /pdf-creator を実行（共有に推奨）
B) スライドにエクスポート — /ppt-creator を実行（プレゼンテーション用）
C) 結構です — markdown で十分です