デルタメモ

AI開発

情報メモの見出しと要約—要約はタイトルの言い換えにしない

漏えい・AI・決済などの情報メモで、見出しのすぐ下に要約が並ぶとき。タイトルの言い換え・メタ拒否文を要約にしない。並記テストと日付の正。

一覧やタイムラインでは、漏えい・AI・決済などの情報メモの見出しのすぐ下に短い要約が並ぶことが多いです。同じ意味を二度書くと、読者は「何が起きたか」ではなく「同じ文が続く」ことだけを見ます。モデルが「要約できません」と返した文も、影響やCVEの語を含むと本物の要約に見え、公開面に載ることがあります。放置すると、取り込みやエージェント生成が「短くした／1行にした／日本語で出した」で完了扱いになり、読者面の一文が良くなりません。読み終わると、並記テスト・日付の正・メタ拒否の切り捨てで合格／不合格を自分で判定でき、是正を規範と経路に残せます。

この記事でわかること

前提

見出しは「何の件か」を示す欄です。要約は「見出しが言っていない事実」を足す欄です。装飾でも、SEO用の言い換え欄でも、モデルの言い訳欄でもありません。

要約が見出しの言い換えなら、書かない方がマシです。空欄や非表示の方が誠実です。本文が薄くて事実が足せないときも、言い訳文ではなくdraft／保留にします。

出典の可否（公式優先・報道に※など）は要約の話とは別層です。長い「一次ソース確認中」タグをタイトルに足して差分の代わりにしないでください。

失敗1：完了バイアスで「短くした」を成功にする

状況: 要約を短くした／1行にした／出した、でタスクを閉じる。見出し横に置いた読み心地を見ていない。

悪い例: 「Xにおける複数の問題」の見出しに対し、要約が「Xに複数の問題（…）」で終わる。英語見出しを日本語にしただけで終わる。

良い例: 見出しが対象と問題の種類を言っているなら、要約は影響・リスク・取るべき対応（原文にある範囲）だけを足す。

合格条件: 見出しを隠しても、要約だけで追加情報がある（並記テスト）。見出しを消すと何も残らない文は不合格。

失敗2：定義・前置きで差分を埋める

状況: 用語解説や定型の前置きで枠を埋め、今回の差分が無い。

悪い例: 「〇〇とは〜です。詳細は原文を参照してください」だけ。原因・影響・対応が無い。「公表しました」だけ。

良い例: 事故・漏えいなら、原因または態様と、影響（件数・対象など原文にあるもの）を1行にまとめる。週次・定型見出しなら、個別の新規情報。なければ「定型ダイジェスト」と分かる一文。

合格条件: 一覧向けなら原則1行。長い定義や前置きは置かない。対象名や問題種別の再掲で始めない。

失敗3：日付と個別／一覧の取り違え

状況: 取得した日・検索した日を、原文の公表日の代わりに使う。方針・一覧・ハブだけのページを、その日の個別事案として扱う。

悪い例: 古いハブページを「今日見つけた」日で載せる。カタログ追加の見出しに、個別インシデント用の要約を当てる。

良い例: 表示や並びの日付は原文の公表・更新に合わせる。「N件をカタログに追加」なら、優先度の意味や対象の手がかり（分かるときだけ）を足す。

合格条件: 日付は原文の公表・更新。取得日でごまかさない。方針・一覧・ハブだけのページを、その日の個別事案として扱わない。推測で件数を作らない。

失敗4：メタ拒否を要約として載せる

状況: 本文が薄い（週報アンカーなど）とき、モデルが「本文にCVEが無いので要約できません」系を返す。APIは成功に見え、日本語で長く、「影響」「対応」を含むため薄要約や並記テストをすり抜けやすい。

悪い例: 拒否文をそのまま summary に書き、draft: false で公開する。「日本語で長いから合格」と通す。推測でCVEや影響を埋める。

良い例: メタ拒否は捨てる（null／保留プレースホルダ）。公開しないならdraft。書ける範囲の原文事実だけ1行にする。機械チェックとdraft化がtitle-echoと同様にメタ拒否を落とす。

合格条件: 「要約できません／本文に記載なし／情報不足」系が公開一覧の要約に残らない。本文不足は空かdraft。事実の捏造で埋めない。

失敗5：是正がチャットで揮発する

状況: 示された悪い文を1件だけ直して終わり。生成・取り込み・表示の層に不合格条件が無い。読者面は未確認。

悪い例: チャットで言い換えて「直した」。手元のファイルだけ直し、公開面は旧文のまま。

良い例: 不合格例を抽象化しすぎず残す。同型をまとめて直す。文が通る層に同じ不合格条件を入れる。規範に1段落足す。読者面で並記テストを通す。

合格条件: 読者が見る面で見出し＋要約を確認するまで未完了。チャット是正だけで終わらない。

失敗6：作業用の文字数メモを公開要約に残す

状況: 手埋めで「28〜120字」などの長さ条件を満たしたか数え、（77文字） を文末に付けたまま summary に書く。

悪い例: 「……適用が求められます。（77文字）」

良い例: 「……適用が求められます。」長さは頭の中か check:prepublish／polishに任せる。公開文に工程メモを書かない。

合格条件: （N文字） 等が公開一覧の要約に残らない。機械チェックがprocess-metaで落とす。

合格条件（一覧）

次をすべて満たすこと。

  1. 並記テスト: 見出しを隠しても、要約だけで追加情報がある
  2. 短さ: 一覧向けなら原則1行。長い定義や前置きは置かない
  3. 差分のみ: 対象名や問題種別の再掲で始めない
  4. 手がかり: 影響・対応・件数・識別子など、原文にある範囲。推測で件数を作らない
  5. 日付の正: 原文の公表・更新。取得日でごまかさない
  6. 個別と一覧: 方針・一覧・ハブだけのページを、その日の個別事案として扱わない
  7. メタ拒否なし: 「要約できません」系を公開要約にしない。書けないときはdraft／保留
  8. 作業メモなし: （N文字） など長さ・工程の自己確認をsummaryに残さない
  9. 読者面まで: 直したら、読者が見る面で見出し＋要約を確認する

是正が出たとき

1.示された悪い文を、不合格例として残す（抽象化しすぎない） 2.同型をまとめて直す（1件だけ直して終わりにしない） 3.生成・取り込み・表示の、実際に文が通る層に同じ不合格条件を入れる（メタ拒否もtitle-echoと同様） 4.チャット是正だけにせず、あとから辿れる規範に1段落足す 5.読者面で並記テストを通す

作業前にAIへ渡す入力

人間向けの長い手順は書きません。次はすべて、作業前に AIに読ませる／貼る文 です。

AI向け：永続ルール（rules / AGENTS.md）

情報メモはタイトルと要約を並記する前提。要約はタイトルの言い換え・翻訳だけで終わるな。
要約にはタイトルに無い原因・影響・対応のどれかを足す。日付は原文の公表日（取り込み日ではない）。
「要約できません／本文に記載なし／情報不足」系のメタ拒否文を summary に残すな。書けないときは draft か保留。推測で埋めな。
不合格要約は公開面に出さず draft にする。長い確認中タグをタイトルに足して差分の代わりにするな。
summary に（N文字）など作業用の文字数メモを残すな。長さ確認は頭の中か機械チェックに任せろ。

AI向け：この作業の開始時にチャットへ貼る文

この情報メモの要約を書く／直す。タイトルを消しても要約だけで意味が残るか（並記テスト）を満たせ。タイトル再掲は不合格。メタ拒否文は不合格。日付は公表日を使え。書けないときは draft／保留で、言い訳文を載せるな。（N文字）など作業メモも summary に書くな。

人間向け

なし。上をAIに渡すだけでよい。

まとめ

参考リンク