正本化は今だけの手作業なのか｜ChatGPTの記憶と自動正本候補の実践ログ

この実践ログで分かること

正本化とは何か
なぜ今は人間が正本化しているのか
ChatGPTの記憶と正本は何が違うのか
Memoryだけではなぜ足りないのか
将来AIが正本候補を自動で出す流れが自然に見える理由
それでも人間承認が必要な理由
AIガイド群やCodex作業で正本化をどう使っているか

正本化とは、今後も使う前提を「正しい基準」として残すこと

ここでいう正本化とは、一時的な会話ではなく、今後の作業でも使うルール、方針、判断基準を明示して残すことです。AIサイト群では、URL命名、公式誤認防止、Search Console反応語の扱い、実践ログ化、STOP条件などを、繰り返し使える基準として整理しています。

正本はMemoryよりも明示的な作業基準として使います。長期プロジェクトでは、好みや文体のような記憶だけでなく、「何をしてよいか」「何をしてはいけないか」「どこで止まるか」を文書化しておくことが重要になります。

公開してよいサイト名や一般的な作業名は出せますが、サーバーパス、認証情報、秘密情報、実在の顧客情報や個人情報は正本にも実践ログにも載せません。

今はまだ、人間が「これは正本にする」と判断している

会話の中には、今だけの条件と、今後も使う方針が混ざっています。AIがすべてを勝手に正本化すると、古い方針、一時的な条件、検証中の仮案まで残る危険があります。

個人情報、会社情報、秘密情報を正本化してはいけないことも大事です。だから今は、人間が「これは今後も使う」「これは今回だけ」と判断する必要があります。この判断を積み重ねること自体が、将来AIが正本候補を出すための型にもなります。

ChatGPTの記憶と正本化は何が違うのか

OpenAI Helpでは、ChatGPTのMemoryは saved memories と chat history reference の2系統で説明されています。Dreamingは記憶をより新鮮で関連性の高い形に整理する方向の改善として紹介されています。ただし、それはプロジェクト正本の完全な代替ではありません。

項目	向いている情報	向いていない情報	誰が管理するか	更新タイミング	注意点
Memory	好み、文体、長期的な傾向	厳密な停止条件、公開前チェック、秘密情報	ユーザーが確認・管理する	会話や設定に応じて変わる	すべての詳細を保持する前提にしない
チャット履歴参照	過去の会話から役立つ文脈を参照すること	常に保持したい固定ルール	設定と利用状況に依存する	時間と文脈で変わる	保存済みメモリとは扱いが違う
カスタム指示	回答の方針、口調、基本条件	作業ごとの細かい停止条件	ユーザー	ユーザーが更新する	プロジェクトごとの正本とは分ける
正本	URL命名、STOP条件、公開前確認、公式誤認防止	一時的な仮案、秘密情報、実例の個人情報	人間が採用する	明示的な更新時	古い正本は更新・廃止判断が必要
接続ブロック	新しいスレッドへ渡す前提	全履歴の丸ごと移動	人間とAIで整理する	スレッド移動時	不要な情報を混ぜない
作業ログ	実際に完了したこと、確認結果、次回テンプレート	認証情報、ローカルパス、内部レポート詳細	人間が公開可否を判断する	作業後	実践として一般化する
その場の指示	今回だけの条件	長期的な運用ルール	その会話内で扱う	今回限り	正本化するかは別途判断する

Memoryだけでは、プロジェクトの正しい前提を保ちきれない

Memoryは便利ですが、すべてのルールを正確に管理するための文書ではありません。古い記憶、新しい指示、別プロジェクトの前提が混ざる可能性があります。

Search Console反応語、AdSense注意、URL命名、STOP条件のようなものは明文化した方が扱いやすくなります。作業オーダーや正本にしておくと、次のスレッドや次のGOALでも再利用しやすくなります。

AIが記憶を使えるようになっても、重要な前提は明示した方が安全です。Memoryに任せきるのではなく、正本、接続ブロック、作業ログとして分けて扱うのが現実的です。

将来は「正本候補」をAIが出す流れになるかもしれない

DreamingやMemoryの進化により、AIは過去の文脈を整理しやすくなっています。会話の中から「これは今後も使う方針らしい」と候補化する流れは自然に見えます。

たとえば、何度も出てくるSTOP条件、URL命名、公開確認手順、報告形式は正本候補にしやすい情報です。一方で、AIが勝手に正本化すると危険な情報もあります。そのため、将来的にはAIが候補を出し、人間が採用、修正、却下する形が自然だと考えています。

これは見立てであり、未発表機能の断定ではありません。「可能性がある」「自然な流れに見える」という範囲で扱います。

自動化されても、人間承認は残る

AIができそうなこと	人間が確認すること
繰り返し出る方針を候補化する	本当に今後も使う方針か
過去の正本と矛盾する点を見つける	一時的な条件ではないか
古い正本の廃止候補を出す	秘密情報が混じっていないか
作業ログから次回テンプレートを作る	公式誤認や保証表現がないか
STOP条件候補を抽出する	既存正本と矛盾していないか、公開してよい表現か

AIが正本候補を出せるようになっても、人間承認は必要です。秘密情報を正本化しないこと、一時的な条件を残さないこと、古い正本を更新・廃止することは、人間側の判断として残ります。

正本化してよいもの・してはいけないもの

項目	正本化してよいか	注意点	代替方法
URL命名ルール	よい	既存URLと矛盾しないようにする	正本とテンプレートに残す
公開前チェック	よい	noindex、canonical、robots、404を含める	チェックリスト化する
STOP条件	よい	DB、cron、DNS、認証情報は停止条件に入れる	GOALテンプレートへ入れる
報告書形式	よい	内部情報を出さない形式にする	公開用と内部用を分ける
実践ログ化候補	よい	公開できる形へ一般化する	work-logに残す
Search Console反応語の扱い	よい	数値を過剰掲載しない	分類ルールとして残す
サーバーパス	だめ	内部構造の露出になる	「対象ファイル」など一般表現にする
APIキー、token、Secrets、.env	だめ	実値を絶対に載せない	ダミー表現に置き換える
メールアドレス、顧客情報、個人情報	だめ	実例化しない	匿名化・一般化する
一時的な気分や仮案	原則だめ	あとで矛盾の原因になる	作業ログの背景としてだけ残す

AIガイド群では、正本化で作業が安定してきた

AIガイド群では、作る、Search Consoleで見る、反応語を拾う、既存ページを軽補強する、実践ログに残す、という流れを正本化しています。Codex報告書に実践ログ化候補を付ける運用も、URL命名や公式誤認防止も、繰り返し使える型として扱っています。

このような正本があると、スレッド移動や連続作業でも迷いにくくなります。将来的にAIが正本候補を出せるようになれば、さらに作業が早くなる可能性があります。ただし、秘密情報や具体的な内部パスは出しません。

次回使えるチェックリスト

□ これは今後も使う方針か
□ 一時的な条件ではないか
□ 既存正本と矛盾していないか
□ 秘密情報が入っていないか
□ 公式誤認や保証表現がないか
□ 公開してよい表現か
□ 接続ブロックに入れるべきか
□ work-logに残すべきか
□ 古い正本を更新・廃止する必要があるか

参照したOpenAI公式情報

公式本文の長文転載、公式スクリーンショット、公式ロゴは使っていません。提供範囲や設定名は変わる可能性があるため、最終確認は公式情報で行ってください。

正本化は今だけの手作業なのか