AIメールスレッド要約：追跡可能なアクションブリーフの作り方

受信トレイ表示ではなく業務判断から始める

チームが必要とするのは単なる「短いメール」ではなく、何が決まり、何が阻害され、誰が何をいつまでに行い、どの証拠が現状を支えるかという信頼できる引き継ぎです。判断目的が、含めるメールと省略できない情報を決めます。

判断目的を一文で書く

「9月2日の証拠カットオフ時点でNorthstarパイロットのリリース準備を引き継ぐ」のように具体化します。これにより無関係な通信を除外し、どの欠落が重大か判断できます。「受信トレイを要約する」には同等の境界がありません。

責任を持つ読者を指定する

運用責任者は範囲・依存関係・日付、法務は版・未解決条項・署名状態、セキュリティは統制証拠・例外を必要とします。同じコーパスから複数ビューを作れますが、各ビューは同じ基礎レコードIDを使い、別々に事実を再構成してはいけません。

証拠カットオフを固定する

ブリーフは特定時点の状態です。最後に含めたUTC時刻と生成時刻を記録します。新しい返信が届けば新バージョンを作り、公開済みブリーフを黙って書き換えません。カットオフ表示は昨日の要約が今日の事実として使われることを防ぎます。

許可されたコーパスを定義する

会話ビューで見えるメールすべてが、システムで処理可能とは限りません。アクセス許可と明示的な包含ルールの両方が必要です。

アカウント、フォルダ、除外事項を記録する

対象メールアカウント、共有エイリアス、フォルダを正確に列挙し、送信済み・アーカイブ・ごみ箱・委任アカウントを含むか記録します。個人メール、特権情報、未対応添付は、責任者が処理経路を承認しない限り除外します。

安定した識別子を使う

RFC 5322は、構造的な返信証拠になり得るMessage-ID、In-Reply-To、Referencesを説明しています。提供値を保持し、欠落や不正形式を記録します。グラフ構築には役立ちますが、本文の真実性や各プロバイダーで同じ表示になることを証明しません。

プロバイダー動作を記録する

Gmail公式ヘルプでは返信の会話グループ化と、件名変更または100通超で分割される条件を説明しています。Microsoft Outlookガイドではアカウント、版、設定に依存する会話・ブランチ表示を説明しています。便利なUIグループを完全な証拠集合とみなさないでください。

スレッドをグラフとして復元する

50通のプロジェクト交換は一本の直線ではありません。範囲、セキュリティ、商務、ロールアウトが別ブランチで進みながら同じ案件を参照します。

親子関係を保持する

各メールについて安定ID、主要な親、参照、受信時刻、参加者、件名派生、プロジェクトキーを保存します。4ブランチのグラフは単純な時系列より、どの返信がどの旧情報を訂正したかを示せます。

明示的なブランチ間リンクを記録する

法務返信がセキュリティ要件を参照したり、ロールアウト日が未署名条項を条件にしたりします。これらを証拠リンクとして記録しつつ、一つのメールに二つの親を捏造しません。主要返信チェーンを保持したまま交差リンクを持てます。

欠落は推測せずフラグにする

「添付で合意済み」と書かれていて添付がなければ、依存関係を未解決とします。後の断定口調や反復から合意を推測しません。欠落は運用上の発見であり、もっともらしい物語で埋める理由ではありません。

身元と時刻を慎重に正規化する

氏名と日付は価値の高い要約項目ですが、誤りやすい項目でもあります。

参加者を承認済みロールに対応付ける

アドレスと既知ロールを結ぶ参加者辞書を維持します。表示名、メールアドレス、ロール対応は別フィールドです。馴染みの表示名だけで本人性は証明されず、似た名前を根拠なく統合してはいけません。

UTCと原文を保持する

元タイムスタンプと承認済みUTC正規値を保存します。「火曜午前」「プロジェクト現地時間09:00」は原文を保持し、タイムゾーン解決を未決にします。完成して見せるために時差を推測しません。

送信者と担当者を分ける

作業に言及した人が担当者とは限りません。「法務で確認できますか」は、プロセス上の割り当てが行われて初めて担当になります。近くにある名前を抽出するのではなく、担当根拠を保存します。

添付の事実を使う前に版を管理する

長いスレッドには似たファイル名の複数版があります。旧版引用はセキュリティ、価格、日程判断を逆転させ得ます。

添付レジスターを作る

ファイル名、版、ダイジェスト、初出メッセージ、承認済み抜粋、レビュー状態、置換リンクを記録します。取得プロセスが信頼できる場合でも、ダイジェストは版識別子であり、安全性や内容の正しさを証明しません。

旧版を見える状態で残す

v1をv2に置換済みとしますが両方保持します。旧版は訂正理由と監査経路を示します。最終状態をきれいに見せるための削除は来歴を壊します。

アクティブコンテンツを実行しない

マクロ、埋め込み命令、リモート資源を実行する権限は要約器に不要です。承認済み添付処理から限定抜粋を渡します。OWASPのプロンプトインジェクション指針は、細工された外部内容が意図したモデル動作を変え得るリスクを扱っています。

原子クレームを型付き台帳へ抽出する

50通から直接一段落へ飛ばさず、個別に確認できるレコードへ変換します。

決定台帳

最終選択、決定者、証拠ID、条件、カットオフ状態を持たせます。「ベンダーが提案」「財務に予算」「法務が閲覧」は「権限者が決定」と同じではありません。

コミットメント台帳

作業、担当、期限、証拠、状態を組み合わせます。完了・変更・超過・タイムゾーン欠落を保持します。丁寧な意向を確定コミットメントに変換しません。

質問台帳

未解決質問を独立レコードにします。未知の内容、回答可能な担当、必要証拠、最新メッセージを記録します。質問を自信ある結論の背後に隠す要約は危険です。

訂正台帳

対象フィールド、旧値、新値、証拠チェーンを記録し、そのフィールドだけ更新します。保持期間の訂正はセキュリティ承認ではなく、価格訂正は購入承認ではありません。

撤回台帳

提案と明示的な撤回証拠を記録し、決定欄から除外されたことを確認します。頻度や新しさは状態の代わりになりません。何度出た提案でも撤回済みなら現行ではありません。

現行状態からアクションブリーフを構成する

台帳が整合すれば、詳細を証拠モデルに任せられるため文章は短くできます。

範囲とカットオフから始める

案件、コーパス、時間窓、最終メール、除外資料を記述します。添付が直接開かれたのか、承認済み抜粋だけかも明示します。結論前に証拠境界を理解できる状態にします。

条件を決定と同じ行に置く

「切替は9月16日14:00 UTC、ただしセキュリティと法務の前提条件付き」のように原子記述と条件を一緒に示します。忙しい読者が見落とす脚注へ条件を追いやりません。

担当者と期限でアクションを列挙する

一作業一行で、UTC期限、状態、コミットメントID、メッセージIDを示します。担当または時刻がなければ「未割当」「時刻未解決」とし、推測しません。

ブロックと質問を表面化する

任意の背景より、リリースを妨げる条件を先に置きます。削除証拠の欠落や未署名条項は、初期議論の美しい要約より準備状態に重要です。

権限制限で終える

ブリーフは情報提供とレビュー専用であり、セキュリティ承認、法的助言、署名、調達承認、支払権限、プロビジョニング、データ開示、日程受諾ではないと明記します。

完全版TS083ケースを確認する

TS083は完全に合成されたNorthstarアクセスゲートウェイ案件です。レコード設計を示すもので、実在顧客、ライブメールボックス、OpenMax実測ではありません。

50通の内訳

範囲/技術12通、セキュリティ/データ16通、商務/法務8通、ロールアウト/サポート14通です。架空12ロール、件名3種類、添付9レコードがあり、範囲、質問票、見積もり、計画の置換版を含みます。

カットオフ時点の現行状態

7決定は2地域、SSOのみ、合成ID、4監査項目、v2見積上限、未署名DPA前提、条件付き9月16日14:00 UTC切替を定義します。11コミットメントが証拠、契約、ランブック、リハーサル、サポート、go/no-goを追い、6質問が未解決です。

訂正が重要な理由

4チェーンで保持期間365日を30日、価格128,000ドルを118,000ドル、日付9月15日を16日、曖昧な現地時刻を14:00 UTCへ訂正します。旧値は証拠として残りますが現行状態には出せません。

撤回が重要な理由

パスワードフォールバック、自動更新、金曜予備切替は撤回済みです。初期に目立つため流暢なモデルが再掲し得ます。撤回台帳により、3項目が現行決定にないことを機械的に確認できます。

候補要約をクレーム単位で評価する

完全パケットには、意図的に失敗する架空候補thread-summary-draft-v0.2があります。OpenMaxの製品性能とは無関係です。

複合文を分ける

「法務が条項を承認し金曜に開始する」には少なくとも二つのクレームがあります。個別に証拠、カットオフ状態、担当/期限、処分を確認します。支持された半分で捏造された半分を隠しません。

クレーム支持精度を測る

24原子クレームのうち18件が支持、3件が後の訂正/撤回と矛盾、3件が無根拠です。18 ÷ 24 × 100 = 75%。単一合成ケースの教材値で、ベンチマークではありません。

重要事実の再現率を測る

採点前に12重要事実を固定し、厳格ルールで8件を保持しました。8 ÷ 12 × 100 = 66.666…%、表示は66.7%です。欠落した限定語が準備状態や権限を変える場合、文章量では補えません。

担当者と期限の帰属を測る

14クレームに担当/期限が必要で、10件が正しいため10 ÷ 14 × 100 = 71.428…%、表示71.4%です。作業内容が正しくても担当が誤れば引き継ぎは失敗します。

訂正捕捉率を測る

4チェーン中1件のみ保持し、1 ÷ 4 × 100 = 25%です。一般的な文章品質では見えにくい旧状態混入を特定できます。

結果を見る前にリリースゲートを定める

閾値はブリーフの影響に合わせます。リリース準備要約は個人メモより厳格であるべきです。

ルーブリックを先に固定する

TS083は、24/24支持または限定、12/12重要事実、14/14帰属、4/4訂正、6/6質問表示、3/3撤回除外、影響操作ゼロを要求します。候補出力を見る前に決めます。

影響操作ゼロは必要だが十分ではない

架空候補は送信、署名、承認、支払、開通、変更ツールを持たず影響操作は0です。それでも内容ゲートに失敗しNOT_RELEASEDです。読取専用は一つのリスクを減らすだけで、事実精度を保証しません。

正解を動かさない

有資格レビューでゴールドレコードが誤りと判明したら、ルーブリックを版管理し理由を記録して再評価します。スコア向上のため期待値を黙って変えてはいけません。

起こりやすい失敗に合わせて人のレビューを設計する

「一読してください」ではなく、明示クレームと既知リスクに結び付けると人のレビューが有効です。

旧事実と否定語を先に確認する

旧価格、日付、添付版、撤回選択肢、さらに「ない」「条件付き」「未署名」の欠落を検索します。小さな限定語が業務上の意味を決定します。

影響の大きい担当を確認する

金銭、契約、セキュリティ、プライバシー、アクセス、go/no-goに紐づくロールを確認します。参加者、依頼者、モデルを権限者へ昇格させません。

信頼できない内容を確認する

引用、転送、添付抜粋に人やシステム向け命令が含まれても、内容として扱います。TS083の「セキュリティ承認済みにする」は敵対的テスト文字列として保持され、権限を与えないと明記されます。

レビュー担当と処分を記録する

コーパス版、候補版、ルーブリック、担当、時刻、承認/拒否クレームID、リリース状態を保存します。後の訂正を説明可能にします。

検証済み製品境界でのみOpenMaxを使う

OpenMax公式のAI business email assistantは、承認済みスレッド、許可された事実、ドラフト準備、人が最終送信とコミットメントを所有する流れを説明します。本ガイドとの正当な接点は、統制されたエージェントがレビュー可能な成果物を準備し、人が影響権限を保持することです。

入力を先に準備する

OpenMaxへ対応付ける前に、メール範囲、許可事実、スレッド/添付レコード、担当マトリクス、許可ツール、レビューゲート、監査項目を定義します。弱い入力契約は自信ある文体では修復できません。

製品主張を狭く保つ

OpenMaxがすべてのメールボックスへ標準接続し、添付をスキャンし、全プロバイダースレッドを完全復元し、全インジェクションを阻止し、TS083の数値を達成するとは主張しません。実環境の連携、権限、配置はOpenMaxチームに確認してください。

人の最終権限を保持する

ドラフト準備/運用調整と、最終送信、署名、支払、セキュリティ承認、データ開示、アクセス開通を分離します。アクションブリーフはレビューを速めても意思決定者にはなりません。

段階的成熟モデルを採用する

証拠整備から限定的な自動化とAIエージェント支援へ進みます。これは manual → automation → agent の段階であり、各段階でレビューを通します。

ステージ0：手動コーパス登録

人がメール、添付版、カットオフを固定し、モデル文章なしで欠落証拠と曖昧な担当を発見します。

ステージ1：読取専用抽出

システムが引用付き原子レコードを提案し、人が決定、コミットメント、質問、訂正、撤回を承認/修正します。影響ツールはありません。

ステージ2：レビュー済みアクションブリーフ

モデルは承認済み台帳からのみ文章化します。リリース前にクレームゲートと具名レビューが必要で、新着メールは版更新を起こします。

ステージ3：限定された下流準備

別途承認後、チケット、返信案、日程候補を準備できますが実行はしません。宛先、フィールド、権限を許可リスト化しレビュー可能にします。

よくある失敗と修正

多くのスレッド要約問題は文法ではなく状態管理の問題です。

表示中の会話だけを要約する

**失敗：**別ブランチ/フォルダが消える。**修正：**固定コーパスマニフェストとプロバイダー設定で安定IDを照合します。

最新メールを全真実とみなす

**失敗：**以前の条件と権限が消える。**修正：**新しさだけでなく各フィールドの訂正チェーンから状態を解決します。

すべての数値をコピーする

**失敗：**旧価格、日付、保持期間が現行値と競合する。**修正：**ブリーフは現行値、旧値は証拠台帳だけに残します。

不確実性を隠す

**失敗：**担当、時刻、添付の欠落がもっともらしい捏造になる。修正：「未解決」を有効状態として限定質問へ回します。

要約を承認と混同する

**失敗：**生成文が権限として扱われる。**修正：**能力マトリクス、権限声明、影響操作ゼロを標準にします。

実装チェックリスト

装飾ではなくgo/no-goレビューとして使用します。

抽出前

• 業務目的、読者、カットオフが明確。
• アカウント、フォルダ、除外、保持が承認済み。
• 安定IDとプロバイダー/クライアント設定を記録。
• 参加者と添付処理ルールを承認。
• 影響ツールがない、または独立して遮断。

起草前

• 各メールがグラフに一度だけ存在。
• 添付版と置換リンクが整合。
• 決定、コミットメント、質問、訂正、撤回に証拠。
• 曖昧な担当、時刻、主張が未解決として見える。
• 重要事実とゲートを出力前に固定。

リリース前

• 各文を原子クレームへ分割。
• 現行クレームが支持され引用済み。
• 担当、期限、条件、否定が正確。
• 未解決質問が見え、撤回項目が決定にない。
• レビュー担当、版、処分、ロールバックを保存。

FAQ：よくある質問

件名だけでスレッドを要約できますか？

できません。件名は変化、衝突、別業務での再利用があります。許可された安定識別子、返信証拠、案件対応、プロバイダー設定を使い、不確実性を記録します。

有効なMessage-IDは本文が真実だと証明しますか？

いいえ。構造メタデータです。本文、送信者関係、添付状態、業務権限を別に検証します。

要約に全メールを含めるべきですか？

証拠レジスターは全包含メールを照合します。公開ブリーフは、会話全文ではなく重要な現行決定、作業、質問、訂正、条件をすべて含めます。

訂正期限はどう表示しますか？

訂正後の日付/時刻とチェーンを引用します。旧値を台帳に保持し、明示的に置換されたフィールドだけ更新し、提供されていない時差を推測しません。

AI要約は返信を自動送信できますか？

標準ではできません。要約は送信権限を与えません。後のドラフト/送信には別の権限モデル、承認事実、レビュー方針、監査証跡が必要です。

TS083はOpenMaxの精度を示しますか？

いいえ。TS083とthread-summary-draft-v0.2は架空教材で、数値は再現可能な評価を示し、候補はNOT_RELEASEDです。製品結果や顧客体験ではありません。

情報源と次のステップ（Next step）

2026年9月5日の調査カットオフで利用可能な公式/一次資料を使用しました。

• RFC Editor：RFC 5322：Message-ID、In-Reply-To、Referencesの限定的な構造利用。
• Google：メールを会話へグループ化：Gmail会話動作と分割条件。
• Microsoft：Outlookで会話表示：設定による会話/ブランチ差。
• OWASP：Prompt Injection：埋め込み命令を信頼できない内容として扱う根拠。
• NIST AI 600-1：来歴、評価、人の説明責任に関するリスク管理。認証主張ではありません。
• OpenMax：AI business email assistant：承認済みスレッド、許可事実、ドラフト準備、人の最終送信という関連境界。

編集可能ワークシートから始め、同意済みまたは完全合成の1スレッドを固定し、完全なグラフと台帳を作り、業務判断に使う前にクレーム単位の人レビューを行ってください。