meeting-notes

ミーティングメモ

1対1やミーティングのライフサイクル全体を対象とするスキルです。準備 → ミーティング → 口述または写真撮影したメモ → 共有可能な学習ドキュメント → 次回の準備まで対応します。すべてのモードで共通のファイル規則を使うため、各ミーティングの成果物が次回の入力になります。

すべてのミーティングが会議とは限りません。利用規約（ToR）や実装計画のレビューサイクルでは、文書の余白で決定事項がまとまることがあります。その場合も、通話の場合と同じメモ、同じアクションテーブル、同じトラッカーの行が必要です。これが余白コメントモードです。

モードの選択

Ane からの合図	モード	参照先
「口述したい」、「ミーティング／1対1の振り返りをしたい」、話し言葉のようなトピックの要約	口述メモ	references/dictation-mode.md
「1対1の準備をして」、「[manager] とのミーティングの準備をして」、「マネージャーに何を提出する必要がある？」	1対1の準備	references/prep-mode.md
画像またはスキャンのパスと「この写真／スキャンからメモの下書きを作って」、手書きメモ	手書きメモ（写真／スキャン）	references/photo-mode.md
音声／動画の録音ファイル、または文字起こし（Teams .vtt/.docx、txt）	録音と文字起こし	references/transcript-mode.md
決定事項がコメントに含まれるレビュー済みの .docx：「決定事項はコメントにある」、「余白コメント」、「レビューコメントをメモにまとめて」	文書の余白コメント	references/marginalia-mode.md
「学習ドキュメント」、「このミーティングの共有可能な要約」と、完成済みのメモ	学習ドキュメント	references/learning-document-mode.md

選択したモードの参照ファイルだけを読みます。モードが曖昧な場合は、1行で確認してください。準備とメモのどちらかを推測してはいけません。それ以外の記録方法（チャットログ、議事録としてのメールスレッド、ホワイトボードの写真）はテキストに正規化したうえで、手順2から references/transcript-mode.md に従います。これにより、どのような方法で記録されたミーティングも、共通のメモ構成にまとめられます。

共通ルール（全モード）

保存先。 定期的な1対1のメモと準備資料は C:/Users/AGasser/OneDrive/1. Ane's PROJECTS/Ane Plans/ に保存します。プロジェクトミーティングのメモは、Ane が指定するプロジェクトフォルダーに保存します。命名規則は Meeting note - Ane-<counterpart> - YYYY-MM-DD.md と 1-1 prep - Ane-<counterpart> - YYYY-MM-DD.md です。.md が信頼できる唯一の情報源です。.docx は .md から生成し、両方を別々に編集することはありません。

事実の信頼性。 口述や手書き文字では、名前、数値、日付が最初に誤認されます（これが聞き取りを行う理由です）。パターンから名前を推測したり「修正」したりしてはいけません。Ane に確認するか、コンテキスト文書で検証してください。正しいと確認済みの情報は ~/.claude/CLAUDE.md、メモリ、またはプロジェクトフォルダーから取得します。検証できない情報にはすべて ⚠️ を付けて確認します。

マイルストーンでの書き込み。 会話の中で下書きと修正を行い、確認済みのマイルストーン（すべてのトピックの確認完了、準備資料の承認）でのみファイルに書き込みます。メッセージごとに書き込まず、1回だけ書き込みます。 ノートの構成（実証済みのテンプレート、2026-07-16確定）：

1. ヘッダー：日付、参加者、種別行、安定したタグ（T1、T2、...）付きのトピック一覧。ノート間でタグを安定させ、相手ごとにT1が常に同じ作業分野を指すようにします。**Participants:** は、名前をカンマ区切りで並べ、括弧内にはカンマを入れずに記載します。update_tracker.py はこの行をカンマで分割し、Ane以外で最初に現れる名前を相手として取得します。そのため、Ane Gasser (IPPF EN, technical lead), <counterpart> ... のように役割の補足を入れると、相手として technical を解析し、すべてのアクション、決定事項、保留事項の行に書き込みます。役割の補足は別の **Roles:** 行に記載します。
2. ## Next actions at a glance：期限順に並べた2つの表（期限 | トピック | アクション）。1つはAne用、もう1つは相手用（「要確認」）です。ノートが再度開かれるのは「今日、自分が対応すべきことは何か」を確認するためなので、期限順に並べます。第三者が担当するアクションは、実際の担当者をアクション欄に明記し、確認する側（Aneまたは相手）の表に記載します。
3. トピックごとに ## T<n> - <name> を設け、それぞれに ### Key takeaways（要約した箇条書き、最大5項目）、### Decisions（確定事項のみ）、### Next steps（Ane／相手、期限付き）、### Open / parked（再度取り上げるべききっかけの日付またはイベントを各項目に記載）を設けます。保留事項がないトピックでは、### Open / parked 全体を省略します。「Nothing parked.」のようなプレースホルダーは絶対に記載しないでください。この見出しの下にある箇条書きはすべて実際の保留事項として update_tracker.py に解析されるため、プレースホルダーがPendingタブに対応不能な行として追加されてしまいます。2026-09-08に実証済みです。2つのプレースホルダーがPendingの行になり、更新ツールは追記のみを行うため、削除するには行を手動で削除し、テーブルの参照範囲も手動で変更する必要がありました。
4. フッター：作成経緯とAI支援の開示。

文体と語調。 Tier 1の作業記録です。平易な英語を使い、能動態で、各文を25語未満にし、出力全体でダッシュ記号を使わず、数値と日付を明確に記載します。後から参照できるよう、決定事項には番号を付けます（「T3 decision 2, 16 Jul」）。

Word出力。 会議ノートには一般テンプレートではなくレターヘッドテンプレートを使います（Aneの決定、2026-09-08）。ロゴと住所ブロックは1ページ目のみに表示し、2ページ目以降には簡潔なヘッダーを付けます。ノートの構成がレイアウトに合う場合は、ane_package.reporting.word_export.write_word_report(template="letterhead") を使って .md から .docx を生成します。表が多いノートを直接作成する場合は、ane_package.reporting.brand.IPPF_FORMAT_TEMPLATE の定数（Barlow Medium、dream #00313C、赤背景に白文字の見出し #EB3300、dreamのヘッダー行）を使って python-docx で作成します。ブランドに合わない色やフォントをハードコードしないでください。

直接作成する場合は、write_word_report の letterhead 分岐と同じ手順を、次の順番で正確に実行します。_open_branded_base()、sections[0].different_first_page_header_footer = True、_add_pillar_footer()、_restrict_header_to_first_page()、_ensure_brand_styles()。ベースにページ設定がすでに含まれているため、_apply_a4_portrait は呼び出さないでください。また、ベースのデフォルトヘッダーにはすでにロゴがあるため、_add_logo_header も呼び出さないでください。呼び出すとロゴが二重に入り、住所ブロックがすべてのページで繰り返されます。ファイルを再度開いて、w:titlePg が存在すること、先頭ページのヘッダーに画像が含まれること、デフォルトヘッダーには画像が含まれないことを確認します。 ビルド失敗でそれぞれ実証された、3つの落とし穴：

• IPPF_FORMAT_TEMPLATE の色定数には先頭に # が付いていますが、これは OOXML の色属性（w:shd の fill、w:color）では無効です。Word は警告なしに網かけを削除します（2026-09-03）。生の XML の色値を書き込む前に # を取り除いてください。run の色については、word_export._hex_to_rgb がすでに処理しています。
• 書式を取り除いたレターヘッドのベースには組み込みの Word スタイルがありません。そのため、table.style = "Table Grid" を設定すると KeyError: "no style with name 'Table Grid'" が発生します（2026-09-08）。これは word_export._add_bullet が List Bullet について説明しているのと同じ落とし穴で、このルールが規定する手順の対象である、表の多いすべてのメモで発生します。スタイルを割り当てる代わりに、table._tbl.tblPr に w:tblBorders 要素を追加して罫線を描画してください。
• メモフォルダーのパスにアポストロフィ（1. Ane's PROJECTS）が含まれているため、長いヒアドキュメントは Bash で失敗します（2026-09-08）。OneDrive の外に置いた Python スクリプトから書き込みを行ってください。これは、OneDrive への書き込みとコミットに関するルールでも推奨されています。

編集内容の保持。 対象ファイルが存在する場合は、mel_wiki/wiki/concepts/edit-preservation-protocol.md を適用してください。特に、Ane が生成された .docx を手動編集した時点で、その .docx が正式なファイルになります。それ以降の変更は、.md から再生成するのではなく、対象を絞った python-docx の編集で行ってください。

プライバシー。 議事メモは個人的な作業記録であり、名前が含まれることがあります。共有可能なもの（学習ドキュメント、または Ane が送ると言ったメモ）には、要約時の匿名化を適用します。名前ではなく役職と組織の種類を記載し、内部分析セクションは削除してください。5 JURNAL の保管庫の内容を引用してはいけません。

一元管理のアクショントラッカー。 確定したメモはすべて、1つの Excel ブック（Ane Plans/Meeting actions tracker.xlsx）にも反映します。期限とステータスを含むアクションを担当者ごとに1つのタブにまとめ、「決定事項ログ」と、保留項目用の「保留中」タブを設けます。メモを作成するモードの最後のステップとして scripts/update_tracker.py を実行してください。このスクリプトは追記のみを行う（安定した ID を使用し、冪等性を確保する）ため、Ane が手動で編集した「ステータス」と「進捗」には触れません。詳細：references/action-tracker.md。準備モードではステータス確認のためにこのトラッカーを読み込みます。トラッカーの「ステータス」列は、古いメモの記述より優先されます。

メモリの締めくくり。 メモが確定したら、プロジェクトの永続的な事実（確定した決定、変更された予算、新しい期限など）をオートメモリに保存することを提案してください。重複を避け、既存のプロジェクトメモリを更新してください。メモには会議の内容を記録し、今後のセッションで必要となる情報はメモリに記録します。