AIの記憶が古いまま業務に入る事故を防ぐ実装チェックリスト

2026年6月2日から6月4日に公開された英語の一次情報を追うと、AIの論点は「どのモデルが強いか」ではなくなっています。焦点は、どの記憶を信じ、どの業務文脈を渡し、どこで止め、どこで監査するかです。

OpenAI は memory をより新鮮に保つ方向へ進めており、Microsoft は Work IQ を通じて業務文脈を API 化し、Microsoft Foundry は runtime controls を checkpoint に落とし込み、Anthropic は攻撃側が AI をより深い工程で使う現実を示しました。つまり、AI導入の成否はモデル比較ではなく、境界設計で決まります。

結論

境界	事故の起点	実装ルール
記憶	古い好みや前提を正とみなす	memory と business state を分離する
文脈	生データをそのまま渡す	allowlist と schema で整形する
実行	送信・削除・公開を直結する	重大操作は dry-run と人間承認にする
制御	ポリシーがプロンプト止まり	evaluation と runtime controls を必須化する
統治	チームごとに例外運用が増える	owner / audit / budget / retention を固定する

1. OpenAI の memory 更新: 記憶は便利だが、正本ではない

OpenAI は 2026年6月4日、ChatGPT の memory をより新鮮で一貫したものにする更新を公開しました。ここで重視されているのは、記憶を増やすことそのものではなく、古さや不整合を減らすことです。

原文: "freshness, continuity and relevance"（OpenAI: Dreaming）

日本語訳: 「新しさ、継続性、関連性」。

実務で読むべきポイントは、会話メモリを業務状態と混ぜないことです。会話の継続性は便利ですが、受注状況、顧客属性、進行中タスクの正本は別管理にすべきです。

memory_policy:
  user_preferences:
    source: memory_store
    mutable: true
    reviewable: true
  work_state:
    source: app_db
    mutable: false
  time_to_live:
    chat_memory_hours: 24
    work_context_hours: 6

• memory は「次回の会話を楽にする」ための層にする
• 業務状態は DB、CRM、チケット、台帳などの正本に寄せる
• 古い記憶を前提に、再確認と上書きの導線を必ず用意する

2. Microsoft Work IQ APIs: 業務文脈は raw data ではない

Microsoft は 2026年6月2日、Work IQ APIs を公開し、エージェントが業務文脈を使って動く方向を明確にしました。重要なのは、エージェントが読むのは生データそのものではなく、業務に最適化された文脈だという点です。

原文: "work with business context, not just raw data"（Microsoft 365 Blog）

日本語訳: 「生データではなく、業務文脈で動く」。

ここでの実装ミスは、メール、会議、ファイル、チャット、CRM のデータをそのまま一括で渡してしまうことです。AI が賢くなるほど、入力の粗さがそのまま事故率になります。

context_contract:
  allowed_sources:
    - calendar
    - files
    - crm
    - ticketing
  denied_fields:
    - secrets
    - pii_unneeded
    - full_thread_raw_dump
  transforms:
    - redact_sensitive_fields
    - normalize_ids
    - attach_business_schema
  tool_surface:
    verbs:
      - read
      - summarize
      - draft
      - request_approval

• Context はフォルダ同期ではなく、選別された API 面にする
• Tools と Context を分け、読み取り権限と実行権限を別にする
• 生データを渡す前に、スキーマ、マスク、目的を明示する

3. Microsoft の open trust stack: ポリシーを runtime controls に変える

Microsoft Foundry は、書かれた方針だけでは本番の制御にならないと明言しています。実際には、入力、状態、ツール実行、出力の各地点で制御を掛けないと、エージェントは想定外の挙動に流れます。

原文: "written policies do not translate into working runtime controls"（Microsoft Foundry Blog）

日本語訳: 「書かれた方針は、そのまま動く実行時制御にはならない」。

この指摘はそのまま実装指針になります。プロンプトに注意書きを足すだけでは足りません。評価、制御、再評価を1つのループにする必要があります。

agent_controls:
  checkpoints:
    - input
    - state
    - tool
    - output
  default_action: deny_on_missing_policy
  lifecycle:
    - evaluate
    - control
    - re_evaluate

• input では注入や逸脱を検出する
• state では書き換え権限と履歴を管理する
• tool では dry-run と allowlist を優先する
• output では根拠と出典がない自動送信を止める

4. Anthropic の AI-enabled cyber threats: 攻撃側は深い工程に AI を使っている

Anthropic は 2026年6月3日、AI を使ったサイバー脅威の1年分を分析し、攻撃側が AI をより深い工程へ使っていると整理しました。AI は単なる入口の自動化ではなく、攻撃チェーンの後段にも入っています。

原文: "later, more complex stages"（Anthropic）

日本語訳: 「後段の、より複雑な工程」。

この現実を前提にすると、防御側の AI も同じ深さの責務分離が必要です。検出、再現、修正、検証を1本にまとめると、どこかで止まります。

security_lane:
  detect: auto
  reproduce: auto
  patch: draft_only
  verify: human_signoff

• AI が出した SQL を本番に即流さない
• AI が生成したメールや通知を自動送信しない
• AI が提案した修正は、再現手順と差分レビューを通す
• 破壊的操作は「検知」と「実行」のレーンを分ける

5. OpenAI の frontier governance blueprint: governance は durable でなければ意味がない

OpenAI は 2026年6月3日、frontier AI の統治について durable な federal framework を掲げました。ここでのメッセージは、AI のルールは一度決めて終わりではなく、技術と制度の変化に追随できる構造であるべきだということです。

原文: "a durable federal framework"（OpenAI）

日本語訳: 「持続可能な連邦レベルの枠組み」。

個人開発でも会社でも、同じ考え方がそのまま使えます。ポリシーは口頭説明ではなく、版管理された文書とレビュー手順で残すべきです。

• ルールはリポジトリに置く
• owner を決める
• 例外申請の経路を固定する
• 変更履歴を残す
• 外部環境の変化を定期的に見直す

実装チェックリスト

AI の記憶・文脈・制御を分けるなら、最初に入れるべき最低限はこの5つです。

1. memory と business state を分ける
2. Context は allowlist で作る
3. send / delete / publish / pay は人間承認にする
4. trace と evaluation を残す
5. owner と incident contact を決める

agent_registry:
  memory_source: separate_store
  context_scope: allowlisted
  irreversible_actions:
    - send
    - delete
    - publish
    - pay
  approval: required
  trace_retention_days: 30
  owner: platform-team
  incident_contact: oncall

よくある失敗

失敗パターン	なぜ危ないか	代替
memory を正本にする	古い前提が残り続ける	DB と CRM を正本にする
raw dump をそのまま渡す	機密と不要情報が混ざる	スキーマ化して整形する
prompt だけで制御する	実行時の逸脱を止められない	checkpoint と runtime controls を置く
送信・公開を自動化する	取り返しがつかない	human approval を必須にする
監査ログがない	事故後に説明できない	trace と owner を残す

まとめ

2026年6月上旬の英語AIニュースは、AIが「会話する道具」から「記憶し、文脈を理解し、行動するシステム」へ移ったことを示しています。だから最初に必要なのは、もっと大きなモデルではなく、もっと明確な境界です。

記憶は短命に、文脈は構造化し、実行は止められる形にし、制御は評価とセットにし、統治は更新可能な仕組みにする。ここを先に作ると、AI は初めて本番向きになります。

参考リンク

• OpenAI: Dreaming: Better memory for a more helpful ChatGPT
• Microsoft 365 Blog: Announcing the new Work IQ APIs
• Microsoft Foundry Blog: Build agents you can trust across any framework with open evals and a control standard
• Anthropic: What we learned mapping a year’s worth of AI-enabled cyber threats
• OpenAI: A blueprint for democratic governance of frontier AI

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。

https://itprodx.com
https://note.com/prodouga