古い文脈は、AIの誤答になる——前提を更新するための見直しルール

AIに背景を渡すことは大事だ。しかし、渡した背景が古ければ、その丁寧さがかえって誤答を強くする。過去に正しかった数字、使わなくなった言い回し、変わった制度、方針転換前の判断。AIは古さを自動で見抜いてはくれない。

「記憶させたから安心」がいちばん危ない

会話履歴やカスタム指示に入れた情報は、便利な一方で見えにくい前提になる。いつ入れたのか、今も使ってよいのかを確認しないまま、新しい原稿の土台にしてしまう。文脈は増やすほど、更新の責任も増える。

更新が必要な情報を先に決める

すべてを同じ頻度で見直す必要はない。数字、制度、役職、リンク、価格、投稿方針など、時間で変わるものを先に決める。反対に、本人が大切にする判断基準や語り口は、頻繁に変わらない。変わる前提と、比較的残る前提を分ける。

原稿の冒頭に「時点」を置く

政治や経済を扱う記事では、何年何月時点の話かを示すだけで誤解が減る。AIへの依頼でも同じだ。「2026年8月時点で確認する」「この資料の日付を優先する」と渡す。時点を省かないことは、単なる注記ではなく、判断の条件を渡す行為だ。

更新は、上書きより履歴を残す

前の判断を消すと、なぜ変えたのか分からなくなる。更新日、変えた内容、理由を短く残す。たとえば「制度改正により対象条件を更新」「現在はこの表現を使わない」と記しておけば、AIに渡す文脈も人が引き継ぐ仕事も安定する。

見直しのきっかけを決めておく

・新しいテーマに入る前

・制度変更や公式発表があったとき

・AIの出力に古い前提が混ざったとき

・月に一度、よく使う文脈だけを見るとき

重要なのは、見直しを「余裕があるときの作業」にしないことだ。仕事の節目に小さく組み込む。

AIの誤答を、文脈の不具合としても見る

出力がずれたとき、AIの性能だけを疑うと改善が止まる。どの前提が古かったのか、何が曖昧だったのかを確認する。その記録は次回の指示を強くする。誤答は、文脈台帳の点検箇所を教えてくれる。

文脈を蓄積する出発点は、こちらの記事で整理しています。

▼あわせて読む

・AIに「教え込む」ことは、自分の思考を資産にすること

https://note.com/poliplus/n/nd64736fd1a83

・AIに毎回説明しないために、noteに「コンテキスト」を残す

https://note.com/poliplus/n/n5db350f6c292

・1本の動画を複数媒体へ展開するAI運用設計――人間に残す判断と責任

https://note.com/poliplus/n/nfa84bc37af7a

・AIに渡す「自分の取扱説明書」の作り方——判断基準と語り口を一枚にする

https://note.com/poliplus/n/ncafc036474ab

・AIの文脈を腐らせない——週30分で行うコンテキスト点検

https://note.com/poliplus/n/n19123424b568

▼このテーマのまとめ

・AI×発信ノウハウまとめ

https://note.com/poliplus/n/ncd6194c20727

古い前提が見つかったら、まずその一文を止める

AIが前の担当者名を、いまの担当者として書いた。そんなときは、原稿を全部作り直す前に、その一文を公開候補から外す。どの文が怪しく、何を確かめれば使えるのかを決めるところから始めたい。

ただし、誤答の原因が古い資料とは限らない。根拠のない補完、別の人物との混同、指示の読み違いもあり得る。「古い文脈が原因だった」と結論づけるには、実際に渡した資料や依頼文を確かめる必要がある。原因を特定できなくても、裏付けのない一文を使わない判断はできる。

先に書いた「AIは古さを自動で見抜いてはくれない」は、必ず見抜けないという性能の断定ではない。AIが日付の矛盾を指摘する場合もあるが、それを前提に確認を省かない、という運用上の注意だ。

「最新の資料」でも、いま適用されるとは限らない

新しい発表に来月からの変更が書かれていれば、今日の説明にはまだ使えない場合がある。公表日が新しいというだけで、現在の担当者や条件を置き換えない。いつから、誰に、どの範囲で適用する変更なのかを読む。

逆に、昔の出来事を説明する記事なら、その当時の担当者名が正しいこともある。古い資料を新しい資料に一律に差し替えると、過去の経緯を現在の状態で書き換えてしまう。先ほどの「この資料の日付を優先する」という依頼も、日付の新旧だけで決める指示にはしない。説明する時点と、資料が扱う時点をそろえる。

図：政経プラス作成「古い前提を見つけたら」。本記事独自の編集手順。2026年9月7日作成。原因の特定と、その一文を使ってよいかの判断は別です。図の手順を終えても、記事全体の正しさを保証するものではありません。

台帳を直しても、下書きや公開記事は直らない

見直す場所は、少なくとも三つに分ける。次に渡す資料、すでに作った下書き、読者が見ている公開物だ。台帳の担当者名を直しても、前日に出力した原稿や公開ページはそのままかもしれない。

「古い情報を使わない」と指示しただけで、保存された会話やサービスの記憶から消えたことにもならない。どこに保存され、次の作業で何が参照されるかは利用環境ごとに確認する。ここでは特定サービスの設定変更や記憶の削除手順は扱わない。

公開済みの内容に重要な誤りがあれば、台帳の整理や原因調査が終わるまで対応を待たない。影響する記事を確認し、必要な訂正を進める。まだ調べていない記事を「影響なし」に数えないことも大切だ。

再開する条件を、一文で書く

「今後は気をつける」では、次の原稿を出してよいか判断できない。「公式の担当者一覧で対象日の担当者を確認し、下書きの氏名と肩書きを照合したら、この段落を再開する」と書けば、残っている作業が分かる。確認できないなら氏名を外せるか検討するが、説明に不可欠な情報まで削って話を成立させない。

NISTのAI RMF 1.0は、AIリスクへの対応を継続して行うことや、文脈などの変化に応じて見直しを続けることを扱っている。これは任意に使う枠組みであり、本記事の修正票や三つの確認場所を指定したものではない。私たちは、その継続的な見直しの考え方を、原稿の修正作業に合わせて具体化している。

出典：NIST AI RMF 1.0「5 AI RMF Core」、冒頭および5.2 Map末尾。2026年9月7日確認。公式ページには1.0の改訂作業中との表示があるため、ここでは確認した1.0の記述を参照する。

この先で使えるもの

ここからは、担当者変更の架空例で「何が分かり、何がまだ分からないか」を修正票へ記入する。入力資料・下書き・公開物の確認表、AIへの再依頼文、作業を再開するための判定例をまとめた。コピーして使える記入用ファイルも付ける。