Shopify CEO Tobi Lütke、AGENTS.mdをめぐりClaude Codeを禁止検討 ――この「小さな」ファイルがAIコーディングをどう変えるか

主なポイント

. ShopifyのCEO、Tobi Lütkeは2026年8月25日、Claude CodeがAGENTS.md、.agents/skills/および同様のベンダー中立なエージェント設定を直接読み取れるようになるまで、ShopifyでのClaude Codeの使用を禁止することを検討していると述べました。 . この論争は、実質的には特定のMarkdownファイル名に関するものではありません。リポジトリレベルのAI指示が、特定のコーディングエージェントベンダーに属すべきか、それともツール間で移植可能であるべきかという問題です。 . Claude Codeは現在もCLAUDE.mdをネイティブのプロジェクトメモリファイルとして扱っています。チームはAGENTS.mdをインポートしたり、CLAUDE.mdから参照したり、シンボリックリンクを使用したりできますが、これらの方法は大規模なリポジトリでは調整のオーバーヘッドを増やします。 . Shopifyはこの問題に特に敏感です。そのWorldモノレポには、コード、スキル、規約、実行手順書、AGENTS.mdファイル、および企業規模でAIエージェントが使用するその他の機械可読なエンジニアリング知識が含まれているためです。 . 長期的に最も可能性の高いアーキテクチャは、ベンダー中立な指示レイヤー1つに、オプションのツール固有のオーバーライドを加えるものであり、すべてのAIコーディング製品ごとに同じルールの別個のコピーを持つことではありません。 . 2026年8月26日時点で、Claude Codeは移行および相互運用性の機能を改善していますが、その公式のプロジェクトメモリの挙動は依然として、CLAUDE.mdとネイティブなAGENTS.mdの発見とを区別しています。

ShopifyとClaude Codeの間で何が起こったのか？

2026年8月25日、ShopifyのCEOであるTobi Lütkeは、Claude Codeがリポジトリの指示をどのように扱うかについて、Anthropicに対して公に異議を唱えました。

Lütkeは、このツールがAGENTS.md、.agents/skills/および関連する共有エージェント設定を直接読み取れるようになるまで、ShopifyでのClaude Codeの使用を禁止することを検討していると述べました。彼の懸念は、CLAUDE.mdを要求することが、同じリポジトリで作業するエンジニアが異なるAIコーディングエージェントを使用する場合に、分割脳問題を引き起こす可能性があることでした。

言葉の選び方が重要です。Shopifyは会社全体での完全な禁止を発表したわけではありません。この声明は、組織規模で高くつくツール設計上の決定に対する公の警告でした。

Claude CodeチームのメンバーであるThariq Shihiparは、AnthropicがClaude Codeをよりハックしやすくするために作業中であり、Agents.MDの容易な使用や、より広範なシステムプロンプトのカスタマイズも含まれると応答しました。

この応答により、この出来事は単なるソーシャルメディア上の議論以上のものとなりました。それは、AIコーディングエージェントが依存するプロジェクトコンテキストを誰が所有するかという、急速に成長しているインフラ問題を明らかにしています。

AGENTS.mdが重要な理由

AGENTS.mdは、コーディングエージェントに永続的なプロジェクトコンテキストを提供するために設計されたリポジトリレベルの指示ファイルです。

有用なAGENTS.mdは、エージェントに以下を伝えることができます：

• リポジトリがどのように構造化されているか；
• どのパッケージマネージャーとコマンドを使用すべきか；
• テストをどのように実行すべきか；
• どのアーキテクチャの境界を越えてはならないか；
• どの生成ファイルを手動で編集してはならないか；
• データベースマイグレーションがどのように処理されるか；
• どのセキュリティまたは互換性の制約が適用されるか；
• どのディレクトリ固有のルールがより広範なデフォルトをオーバーライドするか。

簡略化された例は次のようになります：

# リポジトリの指示

パッケージマネージャー: pnpm

プルリクエストを開く前に:
- pnpm lint を実行する
- pnpm test を実行する
- pnpm typecheck を実行する

生成されたGraphQLファイルは手動で編集しないでください。

packages/payments以下の変更は後方互換性を保つ必要があります。

重要な特性はMarkdown自体ではありません。重要な特性は移植性です。

同じリポジトリがCodex、Gemini CLI、Cursor、GitHub Copilot、Claude Code、および将来のエージェントで使用される場合、意味的に同等の6つのコピーを管理するよりも、1つの正規のプロジェクトルールセットを維持する方が安全です。

CLAUDE.md 対 AGENTS.md：真の違い

Claude CodeはCLAUDE.mdをネイティブなリポジトリメモリメカニズムとして使用します。

これにより、AnthropicはClaudeモデルとClaude Codeのワークフローに特化して指示を最適化する余地を得ます。ツール固有の設定は本質的に悪いものではありません。実際、特定の指示はClaude Codeでのみ有用な場合があります。

問題は、ツール固有の設定が共有リポジトリポリシーへの唯一の信頼できる経路になったときに始まります。

健全な区別は以下の通りです：

この階層化されたモデルにより、チームはプロジェクトの真理を、今期たまたま人気のあるエージェントとは独立して維持できます。

コーディングリポジトリにおける「スプリットブレイン」とは？

入れ子になった指示を持つ大規模なモノレポを考えてみましょう：

world/
├── AGENTS.md
├── CLAUDE.md
├── checkout/
│   ├── AGENTS.md
│   └── CLAUDE.md
├── payments/
│   ├── AGENTS.md
│   └── payments-api/
│       └── AGENTS.md
└── storefront/
    ├── AGENTS.md
    └── CLAUDE.md

ここで、payments-api/AGENTS.mdに重要なルールが含まれていると仮定します：

すべての決済API変更は後方互換性を保つ必要があります。

決済状態遷移を変更する前に統合テストスイートを実行してください。

入れ子になったAGENTS.mdファイルを自動的に発見するエージェントは、このルールを受け取る可能性があります。

CLAUDE.mdファイルの異なる階層構造のみに依存するClaude Codeセッションは、リポジトリが意図的にミラーリングまたはインポートしていない限り、同じ情報を受け取らない可能性があります。

したがって、2人のエンジニアが同じパッケージを変更するように異なるエージェントに依頼しながら、それらのエージェントに異なるポリシーセットを与えていることに気づかない可能性があります。

これがスプリットブレインです：

リポジトリの真理
 |
 +--> エージェントAはルート + payments + payments-apiルールを認識
 |
 +--> エージェントBはルート + paymentsルールのみを認識

コードは共有されます。AIコンテキストは共有されません。

小さなプロジェクトではこれは不便かもしれません。大規模な企業では、これはエンジニアリングガバナンスの問題になります。

なぜシンボリックリンクが完全な企業向けソリューションではないのか

明白な回避策は単純明快です：

ln -s AGENTS.md CLAUDE.md

もう一つの選択肢は、共有指示をインポートするCLAUDE.mdファイルを作成する方法です：

@AGENTS.md

## Claude Code

src/billing/配下の変更にはプランモードを使用してください。

どちらの方法も有用であり、中小規模のリポジトリでは完全に合理的な選択肢となる場合があります。

問題は回避策が機能するかどうかではありません。問題は、巨大なディレクトリツリーのどこにおいても、その機能が決して停止しないことを保証することです。

大規模な環境では、チームは以下のような質問に答えなければなりません：

• すべてのネストされたAGENTS.mdに対応するClaudeから参照可能なパスが存在しますか？
• チームが新しいパッケージを作成し、アダプターを忘れた場合はどうなりますか？
• シンボリックリンクはWindowsおよびすべての開発環境で一貫して扱われていますか？
• 生成されたCLAUDE.mdは正規のAGENTS.mdから乖離していませんか？
• CIはこの関係性を検証していますか？
• ローカルでの上書き設定は一貫して解釈されていますか？
• マイグレーションツールは設定を一度だけコピーするのか、それとも時間とともに同期を維持するのか？

したがって、この回避策は、それ自体がテスト、リンター、自動化、所有権を必要とする追加のシステムを生み出す可能性があります。

これが、この意見の相違を「Markdownに関する議論」ではなく「複雑性コストに関する議論」として理解するのが最適な理由です。

なぜShopifyが重要なテストケースなのか

Shopifyはすでに、AIエージェントを中心にエンジニアリング環境の重要な部分を再構築しています。

Worldと呼ばれる大規模モノレポは、単なるコードのコンテナではありません。Shopifyはこれを、コードに加えてスキル、規約、意図ドキュメント、ランbook、AGENTS.mdファイル、および文書化されたドメイン知識を含むものと説明しています。

これは、リポジトリ指示がもはや装飾的なドキュメントではなく、機械可読な組織的記憶として機能しつつあるため重要です。

Shopifyの内部エージェント「River」は、その規模を示しています。報告された30日間で、Riverは数千のSlackチャネルにわたる数万セッションを処理し、数千のマージ済みプルリクエストを共同執筆しました。

RiverはShopifyのエージェントプラットフォーム「Aquifer」上で動作しており、このプラットフォームは永続セッション、エージェントハーネス、サンドボックス、認証情報、ゲートウェイ、可観測性を分離しています。

このプラットフォームにおける重要なアーキテクチャ目標の一つは「交換可能性」です：モデル、ランタイム、ハーネス実装は、周囲のシステム全体を変更することを強制することなく交換可能であるべきです。

単一ベンダーに強く結びついたリポジトリ知識層は、この哲学に反します。

深層アーキテクチャ：リポジトリの知識はエージェントより永続すべき

Shopifyの論争から最も重要な教訓は、リポジトリがAIの実行時環境になりつつあるということです。

歴史的に、リポジトリには以下が含まれていました：

README.md
package.json
.gitignore
CI設定
ソースコード
テスト

エージェント対応のリポジトリには、次第に以下が含まれるようになってきました：

README.md
AGENTS.md
skills/
runbooks/
アーキテクチャ決定事項
ツールポリシー
評価ルール
自動化フック
リポジトリ固有のメモリ

これらのファイルは、数年後にわたって有用であり続ける可能性があります。

チームが使用するAIコーディングツールは、数か月ごとに変更されるかもしれません。

そこから、基本的な設計原則が導き出されます：

永続的なプロジェクト知識は、単一のエージェントベンダーよりも長いライフサイクルを持つべきです。

これは、チームが環境変数、パッケージメタデータ、ソース管理、プロトコルインターフェースに対して移植性の高い標準を好むのと同じ理由です。

Claude Codeが現在サポートするもの

2026年8月26日現在、Claude Codeには意味のある相互運用性機能がありますが、そのネイティブのプロジェクトメモリモデルは依然としてCLAUDE.mdを中心としています。

この区別は見落としやすいです。

移行サポートは、継続的なネイティブ発見と同じではありません。

/importが一度Claude設定に指示をコピーした場合、元のAGENTS.mdへの将来の編集は、結果の設定が正規ファイルを参照していない限り、同期戦略が必要です。

.agents/skills/ が同じ議論の一部である理由

リポジトリの指示 (AGENTS.md) は次のような質問に答えます：

このプロジェクトでは、エージェントはどのように動作すべきか？

一方、スキルは別の質問に答えます：

エージェントが特定のタスクを実行する必要がある時、どのような再利用可能な能力を読み込めるか？

スキルには以下が含まれる場合があります：

release-check/
├── SKILL.md
├── scripts/
├── references/
└── assets/

例えば、リリーススキルはエージェントに以下の方法を教えることができます：

/ 変更履歴 (changelog) を検証する。 / バージョニングルールを確認する。 / リリーステストを実行する。 / パッケージの出所 (provenance) を検証する。 / リリースチェックリストを作成する。

Agent Skills フォーマットは、スキルの構造と段階的な読み込み動作に焦点を当てています。.agents/skills/ という場所は、コアフォーマットによって定義された唯一のインストール場所というよりも、複数のクライアント間での相互運用性を確保するための慣習として登場しています。

このニュアンスが重要です。

エコシステムは、2つの異なる層で同時に標準化が進んでいます：

1. エージェントスキルのフォーマット。
2. 複数のクライアントがスキルを発見すべき場所。

Shopify の要望は両方の層に関連しています。なぜなら、移植性のあるスキルであっても、すべてのコーディングエージェントが異なるディレクトリ構成を要求するのであれば、その有用性は低くなるからです。

Anthropic が CLAUDE.md を望むかもしれない理由

Anthropic 側にも正当な技術的論点があります。

異なるモデルファミリーは、必ずしも同じシステム指示に対して最適な応答をするとは限りません。

Claude 専用のファイルは、以下のような好みを表現できます：

@AGENTS.md

## Claude 固有のガイダンス

複雑なリファクタリングの場合：
-C 編集前に隣接する抽象化を調査せよ；
-C 3つ以上のパッケージに手を加える前に計画モードを使用せよ；
-C 実装メモは簡潔に保て；
-C 生成された成果物を確認してから完了とせよ。

このような設定は、移植性のあるベースと共存できます。

誤りは、移植性とモデル固有の最適化を互いに排他的なものとして扱うことです。

より強固なアーキテクチャは以下の通りです：

          リポジトリ
               |
            AGENTS.md
      共有プロジェクト方針
               |
     +---------+---------+
     |         |         |
  Claude    Codex    Gemini CLI
     |         |         |
  CLAUDE.md overrides overrides
  オプショナルチューニング

このモデルでは、ベンダー固有の設定は上書きレイヤーとなり、真実の源が重複することはありません。

AGENTS.mdがエコシステム標準になりつつある

この議論が重要であるもう一つの理由は、AGENTS.mdがもはや無名の慣習ではないからです。

2025年8月のリリース後、このフォーマットは6万以上のオープンソースプロジェクトとエージェントフレームワークで採用されていると報告されました。このエコシステムには主要なコーディングエージェント製品や開発者環境が含まれています。

2025年12月、AGENTS.mdはLinux Foundation傘下のAgentic AI Foundationに寄贈され、この慣習の中立的なガバナンスの道筋が作られました。

Anthropic自体もこの広範なFoundationの取り組みの一部であり、同社のModel Context Protocolはオープンエージェントインフラのもう一つの主要な構成要素を表しています。

これにより重要な戦略的パターンが形成されます：

• MCPは、エージェントがツールやデータに接続する方法を標準化
• AGENTS.mdは、リポジトリがプロジェクト指示を伝達する方法を標準化
• Agent Skillsは、手続き的知識の再利用可能なバンドルを標準化
• ベンダー固有ファイルは、特定のエージェント向けに動作を最適化

これらのレイヤーは異なる問題を解決し、互いに連携して動作できます。

台頭するオープンエージェントスタック

成熟したエージェント対応プロジェクトは最終的に次のようになる可能性があります：

project/
├── AGENTS.md
├── .agents/
│   └── skills/
│       ├── deploy/
│       │   └── SKILL.md
│       ├── database-migration/
│       │   └── SKILL.md
│       └── security-review/
│           └── SKILL.md
├── CLAUDE.md
├── .claude/
│   └── skills/
├── .cursor/
├── package.json
└── src/

長期的な目標は、すべてのベンダーディレクトリを排除することではありません。

目標は、ベンダーディレクトリをオプションの専門化レイヤーとすることです。

チームは、プロジェクトのアーキテクチャの記憶を失うことなく、あるコーディングエージェントを削除し別のエージェントを採用できるべきです。

今日のマルチエージェントチームのための実践的セットアップ

ネイティブな動作が収束するまで、チームはcanonical-source（標準ソース）戦略でリスクを軽減できます。

1. 共有ポリシーをAGENTS.mdに配置

アーキテクチャ、コマンド、テスト、安全ルール、ディレクトリ固有の制約をポータブルファイルに保持します。

コアリポジトリの真実をCLAUDE.mdだけに置かないようにします。

2. CLAUDE.mdに標準ファイルをインポートさせる

@AGENTS.md

## Claude Code固有の指示

パッケージ横断的なリファクタリングにはplan modeを優先。

これにより重複を最小限に抑えつつ、Claude固有の調整を保持できます。

3. ネストされたファイルのCIチェックを追加

大規模モノレポは、互換性のあるClaude Codeパスなしに新しいネストされたAGENTS.mdが作成された場合を検出すべきです。

概念的チェックでは以下を強制する可能性があります：

すべてのネストされたAGENTS.mdに対して：
  Claude Codeが同じ標準指示に到達できることを確認

正確な実装は、リポジトリ階層と選択されたインポート戦略に依存します。

4. エージェントのコンテキストをテストする（ファイルだけでなく）

リポジトリには正しい Markdown ファイルが含まれていても、間違ったコンテキストが読み込まれる可能性があります。

チームは定期的に以下を検証すべきです：

• エージェントが実際にどのメモリファイルを読み込んだか；
• 現在の作業ディレクトリでどのネストされた指示が適用されるか；
• インポートされたコンテンツが最新かどうか；
• 矛盾するルールが存在するか；
• ローカル設定が共有ポリシーを意図せず上書きしていないか。

5. ベンダー固有の指示は小さく保つ

もし CLAUDE.md が完全な第二のプロジェクトハンドブックになってしまうと、設定の乖離はほぼ避けられません。

良い目標は以下の通りです：

AGENTS.md = プロジェクトの真理
CLAUDE.md = Claude 固有の差分

よくある落とし穴

指示セット全体の複製

同じ 500 行のポリシーを複数のベンダーファイルにコピーすることは、最初は安全に感じられます。

通常、これは最もリスクの高いアプローチです。なぜなら、コピーは黙って分岐するからです。

一時的なインポートを同期と見なす

移行ツールは導入を助けます。しかし、将来の変更が自動的に同期されることを保証するわけではありません。

チームは以下を区別すべきです：

• 設定をコピーすること；
• 設定を参照すること；
• 設定をネイティブに発見すること。

ネストされたディレクトリのセマンティクスを無視する

最も大きな失敗は、リポジトリルートの下でよく発生します。

ルートレベルのアダプターは正しく見えるかもしれませんが、パッケージレベルの指示が一つのエージェントには見えていない可能性があります。

移植可能なポリシーとモデルプロンプトチューニングを混同する

データベース互換性要件などのルールは、共有プロジェクトポリシーに属します。

特定のモデルが大規模なリファクタリングをどのように計画すべきかなどの指示は、ベンダー固有の設定に属します。

これらの関心事を分離することで、移行がはるかに容易になります。

すべてのスキルディレクトリが同等であると仮定する

クライアント間で発見パスが異なる場合でも、スキルフォーマットは移植可能であることがあります。

チームは、各クライアントがプロジェクトレベルとユーザーレベルの両方のスキルをどのように発見するかをテストすべきです。

次に何が起こるか？

最も可能性の高い結果は、CLAUDE.md がなくなることではありません。

より可能性の高い結果は、相互運用性の向上です。

Claude Code はすでに、他のコーディングツールによって作成された設定に対して、より強力な初期化とインポートパスを追加しています。Anthropic はまた、より簡単な Agents.MD の使用が Claude Code をよりカスタマイズ可能にする取り組みの一部であると公に示しています。

次に注目すべき重要なマイルストーンは：

• アダプターなしでのネイティブな AGENTS.md 発見；
• AGENTS.md と CLAUDE.md 間の文書化された優先順位ルール；
• ネイティブまたは公式に標準化された .agents/skills/ 発見；
• ネストされた指示ファイルに対するより明確な動作；
• モデル固有の最適化を保持する互換性レイヤー；
• 企業が各ツールが実際にどの指示を読み込んだかを検証できるクロスエージェントテスト。

これらの詳細は、相互運用性が個々の開発者にとって便利なだけなのか、それとも大規模組織にとって十分に信頼できるものなのかを決定します。

この論争がClaude Codeよりも重要な理由

コーディングエージェントの競争は、単なるモデルの品質を超えています。

企業は、インフラストラクチャに関する以下の問いに答える必要性を増しています：

• リポジトリは、ナレッジレイヤーを書き換えることなくコーディングエージェントを変更できるか？
• スキルはクライアント間で移動できるか？
• エージェントは同じアーキテクチャの制約を共有できるか？
• 組織は、自動化されたコード変更にどの指示が影響したかを監査できるか？
• 基盤となるモデルが変わっても、エージェント設定は有効なままか？
• モノレポは、AIが読み取れる権威あるポリシーセットを1つ維持できるか？

これらの問いが、AIコーディングが個人の生産性ツールの集合のままか、持続可能なエンジニアリングインフラストラクチャになるかを決定します。

Shopifyの事例が重要なのは、Shopifyが既にその変革の第二段階で運営しているからです。

結論

トビ・リュトケによるClaude Codeへの批判は、AGENTS.mdが単なるテキストファイルとして見られる場合にのみ、些細に見えます。

企業規模では、それははるかに大きなもの：機械可読なエンジニアリング知識の所有権と移植性を表しています。

Claude CodeのCLAUDE.mdは、Claude固有の最適化に有用です。AGENTS.mdは、ベンダー中立なリポジトリの真実に有用です。最も堅牢な未来は、両方をサポートし、チームに設定の複製を強制するのではなく、明確な優先順位とネイティブな相互運用性を持つことでしょう。

今日、複数のAIコーディングエージェントを使用しているエンジニアリングチームにとって、実践的なルールはシンプルです：共有プロジェクト知識を規範的に保ち、ベンダー固有のレイヤーを薄くし、エージェントが実際に読み込むコンテキストを検証します。

次のAIコーディングフェーズの勝者は、最も独自性の高い設定を持つツールではなく、オープンで移植性の高いエージェントスタックに最もすっきりと適合するツールかもしれません。