Codex Computer History 安全運用ガイド - local memory・収集範囲・prompt injection

「さっき見ていた資料はどこだったか」「中断前に何をしていたか」を Codex Computer History に聞けたら便利です。一方で、ブラウザ、チャット、社内文書を横断する履歴を無条件で有効にすると、便利さより先にデータ境界が崩れます。

2026年8月13日に公開された ChatGPT Computer History は、macOS上のアプリやWebサイトでの操作を timeline と local memory に変え、ChatGPT と Codex が後から参照できる機能です。codex computer history で調べている人も、実際に知りたいのは「何が記録されるのか」「どこまで memory に残るのか」「prompt injection をどう持ち越さないか」の3点です。画面録画ではありませんが、クリック、入力、ショートカット、アプリ切り替えなどの interaction event を扱います。

この記事では、Computer Historyを「全部覚えさせる機能」ではなく、許可した作業レーンだけを再利用可能な文脈へ変える仕組みとして設計します。Codex memory全体の役割分担は Codex memories governance 設計ガイド、顧客データと社内データを混ぜない判断は AIエージェントのデータ境界設計ガイド、外部コンテンツ由来の命令対策は MCP prompt injection 対策ガイド、組織ルールのひな形は AIコーディングツールの社内ガイドラインに分けています。

先に結論: 全社一括ONではなく、低リスクな作業レーンから始める

Computer Historyは次の条件を満たす作業から試すのが安全です。

個人の開発環境である
収集を許可するアプリとWebサイトを列挙できる
顧客情報、医療、金融、人事、認証情報を扱わない
historyを定期レビューし、不要なmemoryを削除できる
Computer History由来のmemoryを命令ではなく参考情報として扱う

反対に、次の状態なら有効にしません。

ブラウザ全体を許可しないと仕事にならない
Slackや会議中の他者発言を同意なく収集する可能性がある
production consoleやpassword managerを除外できていない
memoryの保存場所と削除責任者が決まっていない
external contentを読んだ後、そのままwrite toolを実行する

便利さの評価より先に、何を収集しないかを決めます。

Computer Historyは何を記録するのか

公式docsでは、Computer Historyは許可されたアプリとWebサイトからinteraction event streamを作り、一定間隔でテキスト要約とlocal memory fileへ変換すると説明されています。

対象	収集の扱い
クリック、入力、keyboard shortcut	interaction eventになり得る
アプリ切り替え	eventになり得る
macOS Accessibilityが公開するcontext	eventの文脈になり得る
screenshot、screen recording	収集しない
microphone、system audio	収集しない
private browsing	対象外

「screenshotを撮らないから安全」とは言い切れません。入力イベントとAccessibility contextだけでも、文書名、入力内容、開いていたアプリ、作業順序から機密情報を推測できる場合があります。

私が導入レビューをするなら、画面取得の有無ではなく、eventから復元できる情報の感度で判断します。

Chronicleの名前変更ではない

Computer Historyは以前のChronicle research previewを置き換えます。ただし、公式docsは単なる名称変更ではなく、仕組みを作り直したものと説明しています。

Chronicle: screenshotを使用
Computer History: interaction eventを使用し、screenやaudioを記録しない

既存のCodex memory運用でChronicleを許可・禁止していた場合、ルール名だけを置換して終わらせない方がよいです。データの形、保存期間、除外方法、prompt injection面を再評価します。

データの流れを4段階に分ける

Computer Historyの安全性は、「ローカルにあるか、クラウドにあるか」の二択では整理できません。実際には次の4段階があります。

許可されたアプリとWebサイトからinteraction eventを収集する
temporary event fileをMac上に保持する
ephemeralなCodex sessionがeventを処理し、memoryを生成する
生成されたMarkdown memoryを将来のChatGPT / Codexが参照する

公式docsでは、temporary event fileは最大48時間で削除されます。一方、生成されたmemory fileは、ユーザーが削除またはclearするまでfilesystemに残ります。

ここで重要なのは、eventの48時間削除とmemoryの削除は別だという点です。元eventが消えても、要約された機密情報がmemoryに残る可能性があります。

local memoryの保存場所まで確認する

Computer Historyが作るmemoryは、Codexのlocal memoryと同じplain-text Markdownです。標準構成では次の場所に保存されます。

$CODEX_HOME/memories/extensions/skysight/

一般的には次のpathへ解決されます。

~/.codex/memories/extensions/skysight/

plain textなのでレビューしやすい反面、Computer History自体が暗号化するわけではありません。同じmacOS user権限で動く別processから読める可能性があります。

導入前に最低限、次を確認します。

Macのuser accountを共有していないか
backup対象にmemory directoryが含まれるか
endpoint security製品やindexerが内容を収集しないか
退職・端末返却時の削除手順があるか
incident時にmemoryを保全するか削除するか

「ローカル保存」は「アクセス不能」ではありません。

組織導入では4つの許可を分ける

Business / Enterpriseでは、管理者がComputer Historyへのaccessを許可しても、個人の収集は自動で始まりません。公式docsの制御面は次の4層に分かれています。

制御面	誰が決めるか	意味
workspace access	管理者	featureを使う権利を付与する
personal opt-in	各利用者	自分の端末で収集を始める
Memories	各chat / 利用者	memoryを利用・生成する
app / website permissions	各利用者または運用ルール	収集sourceを限定する

この4つを1つの同意として扱うと、責任境界が崩れます。管理者のenableは全員への収集指示ではありません。個人のopt-inは、すべてのアプリを許可する同意でもありません。

組織ポリシーには、次のように分けて書くと運用しやすくなります。

computer_history_policy:
  workspace_access: pilot_roles_only
  personal_opt_in: required
  default_source_mode: include_only
  allowed_apps:
    - code_editor
    - local_terminal
  denied_apps:
    - password_manager
    - production_console
    - hr_system
    - customer_support
  review_interval_days: 7
  owner: ai-platform-team

これは製品設定そのものではなく、導入判断を揃えるためのpolicy例です。

allowlist型で収集sourceを決める

Computer Historyには、除外リストとinclude-onlyの両方があります。低リスクに始めるなら Include only these apps と Include only these websites を使い、許可したsourceだけを対象にします。

denylist型は、新しいアプリやsubdomainが増えたときに漏れます。特にブラウザは、同じアプリ内で公開docs、社内管理画面、個人メール、金融情報を横断するため、ブラウザアプリ単位の許可だけでは粗すぎます。

私なら初期pilotでは次の順にします。

local editorとterminalだけを許可する
公開docsのdomainを個別追加する
社内SaaSは業務ownerの審査後に追加する
password manager、production、health、finance、HRは恒久denyにする

source追加は「便利だったから」ではなく、用途とdata classを記録して判断します。

prompt injectionをhistory経由で持ち越さない

公式docsは、Computer Historyにprompt injection riskがあることを明記しています。悪意あるWebページや文書を開くと、その内容がinteraction eventやmemoryを通じて後のChatGPT / Codexへ影響する可能性があります。

危険なのは、その場で命令を実行するケースだけではありません。

1日目: 悪意あるページを閲覧する
1日目: 内容が「作業上の注意」としてmemoryに要約される
3日目: Codexが別taskでmemoryを参照する
3日目: 外部送信や設定変更の判断へ混ざる

時間をまたぐため、原因を追いにくくなります。

対策は、memoryをtrusted instructionとして扱わないことです。

AGENTS.mdやmanaged policyをmemoryより優先する
external source由来のmemoryには出所を残す
memoryだけを根拠にwrite / deploy / sendを許可しない
外部操作は毎回approvalへ戻す
不自然な命令文を含むmemoryを定期レビューする
sensitive taskでは /memories で利用を止める

Computer Historyはcontextを探すために使い、権限を広げるためには使いません。

他者とのcommunicationは事前同意を取る

公式docsは、他者とのcommunicationを含む可能性がある場合、事前の明示的な同意なしに収集しないよう注意しています。

対象になり得るものは、Slack、チャット、メール、Web会議、共同編集文書です。自分が端末を操作していても、内容の主体は自分だけではありません。

実務では次のどちらかに寄せます。

communication appを常時除外する
使用前にpauseし、同意のある特定作業だけresumeする

「あとで消せる」は収集時の同意の代わりになりません。

便利な使い方はsource探索とworkflow発見に限定する

Computer Historyの価値が出やすいのは、次の用途です。

中断前の作業を再開する

「休憩前にどのissueとfileを見ていたか」を聞き、source候補を特定します。historyの要約を最終根拠にせず、実fileやissueを開き直して確認します。

曖昧に覚えている文書を探す

文書名を忘れたときに、timelineから候補を出します。内容を回答させるより、原本へのlocatorとして使う方が安全です。

反復作業をskill / automation候補にする

繰り返し作業が見えたら、すぐ自動化せず候補としてレビューします。

workflow_candidate:
  source_period: "2026-08-11..2026-08-14"
  repeated_steps:
    - inspect_git_status
    - check_open_prs
    - run_build
  excluded_steps:
    - use_personal_chat
    - open_production_console
  human_review: required

historyからskillを作るときも、秘密情報、個人path、一時的な例外を除いてから共有します。

削除は3種類を分ける

Computer Historyでは、収集停止と既存データ削除は別操作です。

操作	効果
Pause / Turn off	新しいeventの収集を止める
timeline item削除	個別のeventと生成memoryを削除する
Clear history	直近10分、1時間、1日、全履歴などを削除する

permission変更も未来の収集にだけ効きます。すでに作られたitemを消したい場合は、history側の削除が必要です。

削除は取り消せないため、incident調査中に機械的にclearしないようにします。通常のprivacy deletionと、incident holdの手順を分けておくべきです。

2週間のpilot手順

いきなり全社展開せず、次の小さいpilotで十分です。

対象者を1〜3人に限定する
editorとterminalだけをinclude-onlyで許可する
/memories の使い分けを説明する
毎日timelineとlocal memoryをレビューする
sensitive content、誤要約、prompt injectionらしき文を記録する
1週間後に許可sourceを見直す
2週間後に継続、縮小、停止を判断する

評価指標は「何件覚えたか」ではありません。

中断からの再開時間が短くなったか
原本を正しく特定できたか
不要または機密なmemoryが何件できたか
削除とpauseが実際に運用できたか
skill / automation候補が人間レビューに耐えたか

利便性と事故兆候を同じ表で評価します。

よくある失敗

ブラウザを丸ごと許可する

公開docsとproduction consoleが同じブラウザに混ざります。domain単位のinclude-onlyへ寄せます。

eventは48時間で消えるから安心する

生成memoryは残ります。event retentionとmemory retentionを別に監査します。

管理者enableを利用者の同意とみなす

workspace accessとpersonal opt-inは別です。個人の選択を残します。

memoryを事実のsourceにする

memoryは要約です。source file、issue、PR、chatを開き直します。

収集停止だけで削除したと思う

turn offは未来の収集を止めるだけです。既存itemはhistoryから削除します。

導入前チェックリスト

まとめ

ChatGPT Computer Historyは、最近の作業を思い出すための強力なcontext layerです。ただし、価値は「すべてを記録すること」ではなく、原本を探し、作業を再開し、反復workflowの候補を見つけることにあります。

安全に使う要点は、workspace access、personal opt-in、Memories、source permissionsを分けることです。さらに、temporary eventの48時間削除とlocal memoryの残存を区別し、history由来の内容をtrusted instructionにしない運用が必要です。

最初はeditorとterminalだけのinclude-only pilotから始め、memoryの中身を毎日レビューしてください。それで価値が出ないなら、収集範囲を広げる前に停止する方が正しい判断です。