長時間AIエージェントを放置しないためのRunbook：Memory・Model・Remote承認の実装チェックリスト

AIエージェントは「1回のチャットで補助する道具」から、長時間動き、複数画面をまたぎ、記憶を保持し、途中で人間の承認を待つ実行主体へ変わりつつあります。

2026年5月下旬の英語圏一次情報では、GitHub Copilot Memoryのスコープ制御、Copilot model rules、Anthropicのagent containment、OpenAI CodexのGoal modeとlocked computer use、GitHub Copilot remote control、Google DeepMindのmulti-agent research workflowが同じ方向を示しています。

この記事では、ニュースで確認できる事実と、そこから導く実務上の設計判断を分けながら、長時間AIエージェントを本番・業務環境で使う前に作るべき Runbook を整理します。

結論

長時間AIエージェントは、プロンプトを詳しくするだけでは安全に運用できません。最低限、次のRunbookを先に作ります。

Runbook項目	決めること	失敗すると起きること
Memory Scope	user / repo / org / sessionのどこに記憶するか	個人の好みとリポジトリ事実が混ざる
Model Route	組織・用途・データ分類ごとに許可モデルを固定する	高リスク作業に未承認モデルが使われる
Runtime Boundary	file / network / credential / session stateを分ける	長時間作業の副作用が追えない
Remote Approval	途中承認、方針変更、停止条件を定義する	離席中に危険操作が進む
Multi-agent Review	生成・批評・順位付け・最終判断を分離する	sub-agent出力を過信して誤判断する
Evidence Log	入力、tool call、承認、差分、結果を保存する	事故後に説明できない

一言でいうと、長時間AIエージェント運用の中心は、「任せるタスク」ではなく「止め方・忘れ方・モデル選び・途中承認の記録」 です。

1. GitHub: Memoryは「便利な記憶」ではなくスコープ付き設定として扱う

確認できる事実

GitHubは2026年5月26日、Copilot Memoryに削除、repository-level off switch、Copilot CLIの/memory、保存時スコープ表示などの制御を追加したと発表しました。

原文: "Clearer scope at capture time"
日本語訳: 記憶を保存する時点で、より明確なスコープを示します。
引用元: Copilot Memory has more controls for deletion, scope, and the Copilot CLI

同記事では、保存対象がuser-level preferenceなのかrepository-level factなのかをpermission promptで明示する、と説明されています。

実務解釈

Memoryは「AIが賢くなる機能」ではなく、永続化される設定データ として扱うべきです。特に、次の混同が危険です。

混ぜてはいけないもの	理由
個人の好み	他のメンバーへ伝播するとレビュー方針が歪む
リポジトリ固有の事実	個人memoryに入るとチームで再現できない
一時的な障害対応メモ	長期memoryに残ると古い回避策が使われ続ける
秘密情報や顧客固有情報	削除・監査・共有範囲の問題になる

Runbookには、次のようにMemoryの分類を明記します。

agent_memory_policy:
  user_level:
    allowed:
      - preferred_review_style
      - preferred_language
    denied:
      - customer_names
      - credentials
      - incident_details
  repository_level:
    allowed:
      - build_command
      - test_command
      - architectural_constraints
    denied:
      - temporary_hotfix_notes
      - personal_workarounds
  session_level:
    allowed:
      - current_task_assumptions
      - temporary_research_notes
    retention: delete_after_task_close

2. GitHub: モデル選択は開発者の好みではなく組織ルールにする

確認できる事実

GitHubは2026年5月26日、Copilot Business / Enterprise向けに、組織ごとに利用可能なCopilot modelを制御できるtargeted model rulesをpublic previewとして発表しました。

原文: "fine-grained control beyond enterprise-wide defaults"
日本語訳: enterprise全体のデフォルトを超えた細かな制御。
引用元: Target Copilot models to organizations with model rules

実務解釈

長時間AIエージェントでは、モデル選択が成果物の品質、コスト、データ境界、説明責任に直結します。個人がその場でモデルを選ぶ運用ではなく、用途ごとのmodel routeを固定します。

model_route_policy:
  default:
    allowed_models:
      - approved_general_coding_model
    data_classification: internal
  security_review:
    allowed_models:
      - approved_security_review_model
    require_human_reviewer: true
    allow_external_context: false
  customer_data_task:
    allowed_models:
      - approved_enterprise_model
    require_redaction: true
    log_retention_days: 90
  blocked:
    - unapproved_preview_model_for_customer_data
    - personal_account_model_for_company_repo

重要なのは、モデルを「性能ランキング」で選ばないことです。業務では、精度だけでなく、データ取り扱い、監査ログ、コスト上限、契約条件、障害時の切り戻しもモデル選定条件になります。

3. Anthropic: 長時間agentのリスクはblast radiusを小さくする設計で抑える

確認できる事実

Anthropicは2026年5月25日、Claude across productsのcontainment設計について、agentの能力とアクセス範囲が広がるほどblast radiusを抑える設計が重要になると説明しました。

原文: "how to cap the blast radius"
日本語訳: 影響範囲をどう上限づけるか。
引用元: How we contain Claude across products

同記事では、永続memory、CLAUDE.md、mounted workspace、scheduled / long-running agentsのstate directoriesなど、sessionをまたいで残るcontextが増えることで、persistent memory poisoningのリスクが増えるとも説明されています。

実務解釈

長時間agentは、1回のtool callよりも、残った状態が次回起動時に再読込されること が危険です。

Runbookでは、agentのstateを次の4種類に分けます。

State分類	例	扱い
Ephemeral	現在の推論メモ、探索ログ	session終了時に破棄
Reviewable	diff、test result、根拠URL	PRまたは監査ログへ保存
Shared memory	repo規約、build command	owner承認後に保存
Toxic / untrusted	外部Web、issue本文、顧客入力	agent contextへ直入れしない

特に、外部入力から得た文字列をそのままmemoryや設定ファイルに保存するのは避けます。保存前に、次の検査を通します。

state_persistence_gate:
  before_write:
    - classify_source_trust
    - redact_sensitive_data
    - detect_prompt_injection
    - require_owner_for_shared_memory
  startup:
    - scan_persistent_state
    - show_loaded_memory_summary
    - allow_operator_to_disable_memory

4. OpenAI: 長時間作業にはGoalと終了条件が必要になる

確認できる事実

OpenAIは2026年5月21日のChatGPT Release Notesで、CodexのAppshots、Goal mode、browser annotations、locked computer use、browser use improvementsを発表しました。

原文: "keep longer tasks moving"
日本語訳: より長いタスクを進め続ける。
引用元: ChatGPT - Release Notes

同リリースでは、Goal modeで結果と成功条件を定義し、Codex app / IDE extension / CLIで使えるようになったことも説明されています。

実務解釈

長時間agentには「何をしてほしいか」だけでなく、いつ止まるべきか を渡す必要があります。

agent_goal_contract:
  objective: "依存ライブラリ更新の影響を調査し、必要最小限の修正案を作る"
  success_criteria:
    - affected_packages_identified
    - tests_run_or_blocker_reported
    - no_unrelated_files_modified
    - human_review_ready_summary_created
  stop_conditions:
    - credential_required
    - destructive_command_needed
    - production_write_needed
    - more_than_3_failed_attempts_same_error
  forbidden:
    - git_reset_hard
    - publish_or_deploy
    - edit_unrelated_files

この契約がないと、agentは「進め続ける」ことを成功と誤解します。業務運用では、進める能力と同じくらい、停止・保留・人間確認へ戻す能力が重要です。

5. GitHub: Remote controlは便利だが、承認ログ設計が必要になる

確認できる事実

GitHubは2026年5月18日、Copilot CLI sessionのremote controlがGitHub.comとGitHub Mobileで一般提供になったと発表しました。

原文: "Approve or deny permission requests"
日本語訳: 権限リクエストを承認または拒否できます。
引用元: Take your local GitHub sessions anywhere

記事では、CLIやIDEで開始したsessionをwebやmobileで監視し、進行中に追加指示を出し、実装計画や差分を確認できると説明されています。

実務解釈

Remote controlは、離席中でも作業を止めないために有効です。一方で、承認がチャット感覚になると、あとから「誰が何を許可したか」が曖昧になります。

Runbookでは、remote承認を次のように分類します。

承認種別	例	必須ログ
Read approval	private repoの読み取り、ログ確認	対象path、理由、承認者
Write approval	ファイル編集、設定変更	diff、対象branch、rollback方法
External action	API write、メール送信、Gist作成	endpoint、payload summary、再実行可否
Irreversible action	publish、deploy、delete、billing	原則agent禁止、人間が別経路で実行

承認ログは、agent UIだけに閉じず、Issue、PR、監査台帳、ticketなど、チームが後から検索できる場所にも残すべきです。

6. Google DeepMind: multi-agentは「議論」ではなくレビュー工程として設計する

確認できる事実

Google DeepMindは2026年5月19日、Co-Scientistを、Geminiを用いたmulti-agent AI systemとして紹介しました。

原文: "iteratively generates, debates, and evolves"
日本語訳: 反復的に生成し、議論し、進化させます。
引用元: Co-Scientist: A multi-agent AI partner to accelerate research

同記事では、generation agent、reflection agent、ranking agent、evolution agent、meta-review agentなどの役割が説明されています。

実務解釈

multi-agentを導入するなら、「複数agentが頑張る」ではなく、レビュー工程として設計します。

multi_agent_review_flow:
  generator:
    role: draft_options
    output: candidates
  critic:
    role: find_risks
    output: risk_list
  verifier:
    role: check_sources_and_tests
    output: evidence_table
  ranker:
    role: compare_tradeoffs
    output: ranked_options
  human_owner:
    role: final_decision
    output: accepted_plan

ここで危険なのは、sub-agentの出力を「内部から来たから信頼できる」と扱うことです。外部Web、顧客入力、issue本文、ログ断片を読んだsub-agentの出力は、構造化されていても元の信頼度を引き継ぎます。

実装チェックリスト

長時間AIエージェントを導入する前に、次のチェックリストを埋めます。

Memory

• user-level memoryとrepository-level memoryの違いを明文化した
• memory保存時にsource、owner、retention、削除方法を記録する
• 外部入力から得た文字列をshared memoryへ直保存しない
• memoryを無効化する手順をRunbookに載せた

Model

• 組織・リポジトリ・データ分類ごとの許可モデルを定義した
• preview modelをcustomer data taskで使わない
• 高リスク作業ではhuman reviewerを必須にした
• model変更時の差分検証項目を決めた

Runtime

• file scope、network allowlist、credential scopeを分けた
• session終了時に破棄するstateを決めた
• 永続stateの起動時scanを入れた
• destructive commandはagentから実行しない

Remote approval

• remote承認の種類をread / write / external / irreversibleで分けた
• 承認者、理由、対象、payload summaryを記録する
• publish / deploy / delete / billingは別経路の人間承認にした
• 同じエラーが続いたら停止する条件を入れた

Multi-agent

• generator、critic、verifier、ranker、human ownerを分けた
• sub-agent出力に元データのtrust levelを添付する
• 最終判断をagent同士の多数決にしない
• evidence tableなしの提案を採用しない

失敗パターン

1. Memoryに「一時対応」を保存してしまう

障害対応中の回避策をrepository memoryに保存すると、数週間後にもagentが古い制約として扱う可能性があります。一時対応はsession logまたはincident ticketに残し、shared memoryには昇格させません。

2. モデルを個人の好みで切り替える

高性能モデルを使えばよい、という判断は業務では不十分です。顧客データ、契約条件、ログ保持、コスト上限、監査要件でmodel routeを決めます。

3. Remote承認を「OKです」だけで済ませる

remote controlでは、短い承認が増えます。承認メッセージだけでなく、対象操作、差分、payload summary、rollback方法を記録しないと、後から説明できません。

4. Sub-agentの出力を高信頼扱いする

sub-agentが外部Webやissue本文を読んで要約した場合、その出力は「内部agentの発言」ではなく「外部入力を加工したもの」です。trust levelを上げず、verifierを通します。

そのまま使えるRunbookテンプレート

long_running_agent_runbook:
  owner: platform-ai-team
  applies_to:
    - coding_agent
    - research_agent
    - browser_agent
  memory:
    default: session_only
    repo_memory_requires_owner_approval: true
    delete_path_documented: true
  model:
    route_by:
      - organization
      - repository
      - data_classification
      - task_risk
    preview_models_for_customer_data: denied
  runtime:
    filesystem:
      default: workspace_only
      deny:
        - secrets
        - production_exports
    network:
      default: deny
      allowlist:
        - api.github.com
        - approved_docs_domains
    credentials:
      token_scope: per_session
      revocable: true
  approval:
    read: log_only
    write: human_required
    external_action: human_required_with_payload_summary
    irreversible: agent_forbidden
  stop_conditions:
    - missing_credential
    - destructive_command_needed
    - repeated_same_failure_3_times
    - source_fact_unverified
  evidence:
    required:
      - sources
      - tool_calls
      - diffs
      - tests_or_blockers
      - approvals

まとめ

直近のAIニュースを見ると、エージェントは「長く動ける」「記憶できる」「遠隔で承認できる」「複数agentで考えられる」方向へ進んでいます。

その進化に合わせて、運用側も変える必要があります。今すぐ作るべきなのは、魔法のプロンプトではありません。

Memoryの保存範囲、モデルの許可ルール、実行環境の境界、remote承認ログ、multi-agentレビュー工程をまとめたRunbook です。

長時間AIエージェントは、放置してよい自動化ではなく、止め方まで設計された実行基盤として扱うべきです。

参考リンク

• Copilot Memory has more controls for deletion, scope, and the Copilot CLI - GitHub Changelog
• Target Copilot models to organizations with model rules - GitHub Changelog
• How we contain Claude across products - Anthropic
• ChatGPT - Release Notes - OpenAI Help Center
• Take your local GitHub sessions anywhere - GitHub Blog
• Co-Scientist: A multi-agent AI partner to accelerate research - Google DeepMind

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