Claude Managed Agentsがリポジトリの.claude/skillsを自動で読むようになった──公式ドキュメントが明記する信頼境界の警告

2026年8月27日、Claude Managed Agents公式ドキュメント（platform.claude.com）を実際に開いて確認した内容です。 2026年8月7日のリリースノートに、次の1文があります（原文と訳）。

"Claude Managed Agents sessions can now load skills from a GitHub repository. When a session mounts a repository, any skills in its root .claude/skills directory are discovered automatically at session start and available to the agent for that session."

（訳：Claude Managed Agentsのセッションが、GitHubリポジトリからスキルをロードできるようになった。セッションがリポジトリをマウントすると、そのルートの.claude/skillsディレクトリにあるスキルがセッション開始時に自動検出され、そのセッションのエージェントが利用できるようになる）

このリンク先の専用ドキュメントページを読むと、検出されるディレクトリ構造の正確な条件と、セキュリティ上の注意点が具体的に書かれていました。同じ日のリリースノートには、Claude Managed Agentsのinference_geo（推論実行地域指定）を含む複数の機能追加がまとまって記載されています。

3行まとめ

• リポジトリスキルは、リポジトリのルート直下.claude/skills/<skill-name>/SKILL.mdという「1階層だけ」の構造でしか検出されない。ネストが深い・パスが違う場合は自動検出されない
• 検出にはエージェントのreadツール（デフォルトで有効）が必要。readを無効にしているエージェントはリポジトリスキルをロードできない
• 公式ドキュメントは「マウントしたリポジトリはエージェントの信頼境界の一部になる。コミットできる人（マージされた外部プルリクエスト、侵害された依存関係、コントリビューターなど）は誰でもスキルを追加・変更でき、プラットフォームはレビューを挟まずセッション開始時にそれをロードする」と明記して警告している

ドキュメントの図と首っ引きで確認したディレクトリ条件

公式ドキュメントが示す「検出される構造」と「検出されない構造」の3つの否定例を読み比べると、条件が想像よりも狭いことに気づきます。当サイトが把握している一般的なプロジェクト構成では、スキルやドキュメントに相当するものがリポジトリのあちこちに散らばっているケースが珍しくありませんが、この機能を使うには.claude/skills/<name>/SKILL.mdという専用の置き場を、ルート直下から1階層だけという条件に合わせて意図的に作る必要があります。「既存の構成をそのまま流用できる」機能ではない、という点は導入前に踏まえておくべきです。

検出されるディレクトリ構造

公式ドキュメントは、検出条件を図解付きで具体的に示しています。検出されるのは、正確に.claude/skills/<skill-name>/SKILL.mdという、リポジトリのルートから見て1階層だけの構造です。

your-repo/
  .claude/
    skills/
      code-review/
        SKILL.md
      release-process/
        SKILL.md
        scripts/
          run_checks.sh
  src/

一方、次のような構造は検出されない、と公式ドキュメントは明記しています。

• .claude/skills/SKILL.md：スキルディレクトリを介さず直接置かれたSKILL.md
• .claude/skills/tools/code-review/SKILL.md：1階層より深くネストされている
• skills/code-review/SKILL.md：.claudeの外にあるskillsディレクトリ

さらに、リポジトリのサブディレクトリ（パッケージのサブディレクトリの中など）にある.claude/skillsは、セッション開始時にはアナウンスされない（自動検出の対象外）ものの、エージェントがそのサブツリー内のファイルを読んだ際に表面化することはある、とも書かれています。

検出にはreadツールが必要

公式ドキュメントによると、リポジトリスキルの発見は、エージェントのagent toolsetにあるreadツールに依存しています。readはデフォルトで有効になっていますが、readを無効にしたエージェントはリポジトリスキルをロードできない、という制約があります。

セキュリティ上の警告：信頼境界の一部になる

公式ドキュメントには、次のような警告（Warning）が明記されています（原文と訳）。

"Repository skills are agent instructions, so a mounted repository is part of your agent's trust boundary. Anyone who can commit to the repository (a merged external pull request, a compromised dependency, a contributor) can add or change a skill, the platform loads it at session start without a review step, and session tools such as bash and web_fetch give those instructions real reach. Mount only repositories you trust, and review .claude/skills before mounting a repository that accepts outside contributions."

（訳：リポジトリスキルはエージェントへの指示であるため、マウントしたリポジトリはエージェントの信頼境界の一部になる。そのリポジトリにコミットできる人──マージされた外部プルリクエスト、侵害された依存関係、コントリビューターなど──は誰でもスキルを追加・変更でき、プラットフォームはレビューのステップを挟まずセッション開始時にそれをロードする。そしてbashやweb_fetchのようなセッションツールが、その指示に実際の到達力を与える。信頼しているリポジトリだけをマウントし、外部からのコントリビューションを受け付けているリポジトリをマウントする前には.claude/skillsをレビューすること）

この警告が具体的に指摘しているリスク経路は3つです。

1. マージされた外部プルリクエスト：オープンソースプロジェクトなどで、外部の貢献者が送ったプルリクエストが.claude/skills配下に悪意あるスキルを含んでいて、それがマージされてしまうケース
2. 侵害された依存関係：サプライチェーン攻撃で、正規のメンテナが把握しないまま依存パッケージ経由でリポジトリの内容が書き換わるケース
3. コントリビューター：単純に、書き込み権限を持つ人が意図せず・あるいは意図的に問題のあるスキルを追加するケース

そして重要なのは、これらのスキルが「レビューのステップを挟まずセッション開始時にロードされる」という点です。人間がコードレビューでスキルの中身をチェックする前提の運用でない限り、リポジトリを丸ごとマウントした瞬間にそのリポジトリの.claude/skillsは実質的にエージェントへの命令として機能してしまいます。ドキュメントが名指しするbash・web_fetchのようなツールは、まさにこの「命令」を実世界での操作に変換できるツールです。

補足：自己ホスト型サンドボックスでは非対応

公式ドキュメントには、もう1つ注記があります（原文と訳）。

"Repository skill discovery runs in cloud sandboxes. Self-hosted sandboxes don't support GitHub repository resources."

（訳：リポジトリスキルの発見はクラウドサンドボックスで実行される。自己ホスト型サンドボックスはGitHubリポジトリリソースに対応していない）

つまり、この機能はAnthropicが管理するクラウド実行環境限定で、自社インフラ上でサンドボックスを運用している組織にはこの機能自体が提供されていません。

マウントの実際の呼び出し方

公式ドキュメントが示すサンプルでは、セッション作成時にresources配列へgithub_repositoryタイプのリソースを指定します（ant CLIの例）。

SESSION_ID=$(ant beta:sessions create \
  --agent "$AGENT_ID" \
  --environment-id "$ENVIRONMENT_ID" \
  --transform id --raw-output <<'EOF'
resources:
  - type: github_repository
    url: https://github.com/org/repo
    mount_path: /workspace/repo
    authorization_token: ghp_your_github_token
EOF
)

mount_pathは省略可能で、省略時は/workspace/<repo-name>になる、と明記されています。

どのブランチ・コミットが参照されるか

同じドキュメントページの本文をさらに読み進めると、以前は確認できていなかった「どのブランチ・コミットが参照されるか」という点も明記されていました。

"Discovered skills follow the checked-out state of the repository: the checkout branch or commit when the resource sets one, otherwise the repository's default branch. The scan runs once, when the session starts. Commits pushed mid-session are not picked up; to load updated skills, start a new session."

（訳：検出されるスキルは、リポジトリのチェックアウト状態に従う。リソース側でcheckoutのブランチまたはコミットが設定されていればそれに従い、そうでなければリポジトリのデフォルトブランチに従う。スキャンはセッション開始時に1回だけ実行される。セッション途中でプッシュされたコミットは反映されない。更新後のスキルを読み込むには、新しいセッションを開始する必要がある）

つまり、リポジトリ側でスキルを更新しても、動いている最中のセッションには反映されず、次に新しいセッションを開始したときに初めて新しい内容が読み込まれます。また、同じドキュメントには「リポジトリ由来のスキルと、エージェントのskills配列で明示的に添付したスキルの名前が重複した場合、両方とも利用可能になり、それぞれ別々のパスとして案内される」という名前衝突時の挙動も書かれていました。

トークンの権限も「最小限」が公式の推奨

セキュリティ上の警告は、マウントするリポジトリの信頼性だけでなく、マウントに使うGitHubトークンの権限にも及んでいます。GitHubリポジトリのマウントを扱う別ページ「GitHub」の「Token permissions」節には、次の表がありました。

出典: platform.claude.com/docs/en/managed-agents/github「Token permissions」節（2026年8月29日確認）

同ページには「Use fine-grained personal access tokens with minimum required permissions. Avoid using tokens with broad access to your GitHub account.（きめ細かい権限設定のパーソナルアクセストークンを、必要最小限の権限で使うこと。GitHubアカウントへの広範なアクセス権を持つトークンの使用は避けること）」という注記もあり、リポジトリスキル機能を使う上では「どのリポジトリをマウントするか」と「そのトークンにどこまでの権限を持たせるか」の両方が信頼境界の管理対象になる、という構図が読み取れます。また、resources配列には複数のリポジトリを同時にマウントすることもでき、その場合はマウントしたリポジトリの数だけ、それぞれの.claude/skillsが独立した信頼境界として積み上がることになります。

なぜ「レビューなしで即ロード」が問題になるのか：Skillsの読み込み方式

Anthropicの汎用的な「Agent Skills」ドキュメントには、Skillがどう段階的に読み込まれるかを示す表があります。

出典: platform.claude.com/docs/en/agents-and-tools/agent-skills/overview（2026年8月29日確認）

この表が示す通り、Level 1（nameとdescription）は「常に・セッション開始時に」全スキル分読み込まれます。つまり、悪意あるリポジトリスキルであっても、少なくともそのメタデータはレビューなしで確実にエージェントの目に触れる、ということです。同じ汎用ドキュメントの「Security considerations」節には「Skills that fetch data from external URLs pose particular risk, as fetched content may contain malicious instructions.（外部URLからデータを取得するSkillは特にリスクが高い。取得したコンテンツが悪意ある指示を含む可能性があるため）」という注記や、claude.ai・Claude Cowork向けの「Skill content scanning」（Enterprise組織向け）という緩和機能への言及もありましたが、このスキャン機能は「Skills APIやClaude Console経由でアップロードされたSkillsはカバーしない」と明記されており、Claude Managed AgentsのリポジトリスキルもAPI経由である以上、このスキャン機能の対象に含まれるかどうかは、今回確認した情報源からは判断できませんでした。

GitHub以外のホスティングサービスへの対応は確認できなかった

この機能が対応しているのはGitHubリポジトリのみで、GitLabやBitbucketなど他のホスティングサービスへの対応があるかどうかは、今回確認したドキュメントページの範囲（Managed Agentsの「Agent Skills」「GitHub」両ページ）では記載がありませんでした。

関連記事

• Claude Managed Agentsの推論を特定地域に固定するinference_geo
• Claude APIが2026年8月に踏んだ変更点まとめ