AIエージェントに権限を渡す前に決める5つの実行境界

AIエージェントを本番や社内業務に入れるとき、最初に決めるべきなのは「どのモデルを使うか」ではありません。
先に決めるべきなのは、どこまで読めるか、どこへ書けるか、どこへ通信できるか、どの能力を読み込めるか、何を記憶してよいか です。

この数日から直近1週間程度の英語圏一次情報を見ると、Anthropic、GitHub、Google、NVIDIA、OpenAIはいずれも、AIエージェントを「チャットUI」ではなく、実行環境、権限、永続状態、能力カタログを持つソフトウェアとして扱い始めています。

この記事では、確認できるニュース事実と、そこから導く実装上の判断を分けながら、エンジニアと技術責任者が先に作るべき実行境界チェックリストを整理します。

結論

AIエージェントに権限を渡す前に、最低限この5つを明文化します。

境界	決めること	決めないと起きること
Workspace境界	読み取り、書き込み、削除可能なパス	想定外の設定、秘密情報、別案件ファイルを読む
Network境界	通信先、HTTP method、アップロード可否	許可済みドメイン経由でデータが外へ出る
Capability境界	skill、MCP、tool、connectorの導入条件	便利な拡張が権限昇格ルートになる
Memory境界	user / repo / sessionの保存範囲	一時的な判断や外部入力が永続化される
Goal境界	成功条件、停止条件、承認条件	エージェントが「進み続けること」を成功と誤解する

一言でいうと、AIエージェント運用は prompt engineeringではなくpermission engineering です。

1. Anthropic: blast radiusを先に上限づける

確認できる事実

Anthropicは2026年5月25日、Claude製品群におけるcontainment設計を公開し、AIエージェントの能力とアクセス範囲が広がるほど、影響範囲の上限設計が重要になると説明しました。

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

同記事では、human-in-the-loopだけでは承認疲れが起きること、sandbox、VM、filesystem boundary、egress controlのような環境側の制御が必要になることも説明されています。

実務解釈

「承認ダイアログを出すから安全」は弱い設計です。エージェントができること自体を減らす必要があります。

最初に作るべき境界は次の3つです。

agent_runtime_boundary:
  filesystem:
    read:
      - ./src
      - ./docs
    write:
      - ./src
      - ./tests
    deny:
      - ~/.ssh
      - ~/.aws
      - .env
      - ../
  network:
    default: deny
    allow:
      - host: api.example.com
        methods: [GET]
        upload: false
  process:
    shell: restricted
    destructive_commands_require_human: true

ポイントは、境界を「モデルへのお願い」ではなく、実行環境の設定として持つことです。

2. 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

GitHubは、保存されるmemoryがuser-level preferenceなのかrepository-level factなのかをpermission promptで明示すると説明しています。

実務解釈

Memoryは「覚えてくれて便利」ではなく、次回以降の判断に影響する永続設定 です。外部入力、障害対応メモ、個人の癖、顧客固有情報が混ざると、再現性と監査性が崩れます。

agent_memory_policy:
  user_level:
    allowed:
      - preferred_language
      - review_tone
    denied:
      - customer_names
      - credentials
      - incident_details
  repository_level:
    allowed:
      - build_command
      - test_command
      - architecture_constraints
    require_owner_review: true
  session_level:
    allowed:
      - temporary_assumptions
      - current_research_notes
    retention: delete_after_task

Memoryを書き込む前に「これは誰の判断を変える情報か」を確認するだけで、多くの事故を避けられます。

3. Google: managed agentでも永続環境の扱いを設計する

確認できる事実

Googleは2026年5月19日のI/O 2026 developer highlightsで、Gemini APIのManaged Agentsを発表しました。1回のAPI callで、tool利用とcode executionを行うagentをisolated Linux environmentで起動できると説明しています。

原文: "spin up an agent that reasons, uses tools and executes code"
日本語訳: 推論し、ツールを使い、コードを実行するエージェントを起動する。
出典: Building the agentic future: Developer highlights from I/O 2026

同記事では、各interactionが再開可能なpersistent, isolated environmentを作るとも説明されています。

実務解釈

managed agent runtimeは、環境構築の負担を減らします。ただし、永続環境があるなら、そこには状態、ファイル、credential proxy、tool設定、前回の生成物が残ります。

managed runtimeを使う場合でも、次の項目を自社側で持つべきです。

確認項目	実装判断
environment resume	再開可能な期間と破棄条件を決める
generated files	生成物を成果物、作業メモ、破棄物に分ける
tool credentials	agent固有tokenかuser権限継承かを明記する
audit export	tool call、file diff、network callを保存する
teardown	task完了時に何を削除するか決める

managedだから安全、ではありません。managedになった分、自社がどこを設定責任として持つか を明確にする必要があります。

4. NVIDIA: skillはpromptではなくdeployable capabilityとして検査する

確認できる事実

NVIDIAは2026年5月19日、NVIDIA-verified agent skillsを公開し、agent skillに対してsecurity scanning、skill card、cryptographic signingなどを組み合わせる方針を説明しました。

原文: "trust extends beyond the runtime"
日本語訳: 信頼は実行時制御の外側にも広がる。
出典: NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents

同記事では、SkillSpectorがvulnerable dependencies、suspicious scripts、credential access、data exfiltration pathsに加え、hidden instructions、prompt injection、tool poisoningなどのagent固有リスクも確認すると説明されています。

実務解釈

skill、MCP server、connector、tool定義は、ただの補助プロンプトではありません。エージェントに新しい行動能力を与えるdeployable capabilityです。

社内でskillを入れるなら、最低限このmanifestを要求します。

capability_manifest:
  name: invoice-review-skill
  owner: finance-platform-team
  source_repo: github.com/example/invoice-review-skill
  allowed_tools:
    - read_pdf
    - extract_table
  denied_tools:
    - send_email
    - write_payment_record
  data_access:
    reads:
      - invoices/*
    writes:
      - tmp/extracted/*
  provenance:
    signed: true
    reviewed_at: "2026-05-28"
    reviewer: security-owner
  known_risks:
    - prompt_injection_from_pdf
    - overbroad_table_extraction

「有名な提供元だから大丈夫」では足りません。ダウンロード後に改変されていないこと、宣言された目的と実際のアクセスが一致していることを確認します。

5. OpenAI: 長時間タスクには成功条件と停止条件を渡す

確認できる事実

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

原文: "define an outcome and success criteria"
日本語訳: 結果と成功条件を定義する。
出典: ChatGPT - Release Notes

同リリースでは、長いタスクを進めるために、作業文脈の理解やGoal modeを拡張していることも説明されています。

実務解釈

AIエージェントを長時間動かすほど、「何をするか」より「どこで止まるか」が重要になります。

agent_goal_contract:
  objective: "依存ライブラリ更新の影響を調査し、必要最小限の修正案を作る"
  success_criteria:
    - affected_packages_listed
    - tests_run_or_blocker_reported
    - no_unrelated_files_modified
    - review_summary_created
  stop_conditions:
    - credential_required
    - production_write_needed
    - destructive_command_needed
    - same_error_repeated_3_times
  human_approval_required:
    - publish
    - deploy
    - delete_data
    - change_visibility

この契約がないと、agentは「試行を続けること」を成功と誤解します。業務利用では、止まる条件を成果物の一部として扱います。

実装チェックリスト

本番AIエージェントを導入する前に、次のチェックを通します。

[ ] agentが読めるファイルパスをallowlistで定義した
[ ] agentが書けるパスと削除できるパスを分けた
[ ] networkはdefault denyにした
[ ] 許可ドメインごとにmethodとupload可否を決めた
[ ] user token継承とagent固有tokenを区別した
[ ] skill / MCP / connectorの導入レビューを作った
[ ] skillのowner、source、signature、access scopeを記録した
[ ] memoryのuser / repo / session分類を決めた
[ ] 外部入力をmemoryへ直接保存しないルールを作った
[ ] taskごとのsuccess criteriaとstop conditionsを渡した
[ ] tool call、diff、test result、approvalを監査ログに残した
[ ] task終了時の環境破棄または保存ポリシーを決めた

失敗パターン

失敗パターン	何が悪いか	対策
承認ダイアログだけに頼る	承認疲れで実質auto approveになる	環境側で権限を絞る
api.example.comを丸ごと許可する	同じドメイン内のupload機能を使われる	endpoint、method、token provenanceで制御する
skillをREADME感覚で追加する	hidden instructionや過剰権限を見落とす	capability manifestと署名検証を要求する
memoryに調査メモを保存する	古い前提が次回以降も使われる	session memoryとrepo factを分ける
managed runtimeに任せきる	自社の監査、破棄、権限設計が空白になる	runtime採用時の責任分界を作る
goalが曖昧	agentが不要な探索や変更を続ける	success criteriaとstop conditionsを明文化する

まとめ

直近のAIニュースは、AIエージェントが「賢い補助者」から「権限を持つ実行主体」へ移っていることを示しています。
だからこそ、導入時の中心はモデル比較ではなく、実行境界、永続状態、能力管理、監査ログです。

今日から使える最小単位は、次の3つです。

1. agent runtime boundaryをYAMLで書く
2. capability manifestなしのskill / MCP / connectorを入れない
3. taskごとにsuccess criteriaとstop conditionsを渡す

AIエージェントに仕事を任せるほど、人間側は「どこまで任せるか」をコードと設定で表現する必要があります。

参考リンク

• How we contain Claude across products
• Copilot Memory has more controls for deletion, scope, and the Copilot CLI
• Building the agentic future: Developer highlights from I/O 2026
• NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents
• ChatGPT - Release Notes

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