AGENTS.mdとCLAUDE.mdはどう違い、会社ではどう使い分ければよいですか？
どちらも、AIに仕事の目的・手順・確認点を伝える指示書です。CodexはAGENTS.mdを使い、Claude CodeはCLAUDE.mdに加え、バージョンや設定、ファイルの配置によってAGENTS.mdも読めます。会社の共通方針の正本を一つ決め、使うツールが実際に読む指示書から案内するのが出発点です。指示書は権限を制限する仕組みではないため、公開や削除には実行側の制限と人の確認も必要です。
毎回の『うちの会社では』を、次の仕事にも残す
『毎回、うちの会社の説明から始めている』。AIと仕事をしていると、そんな手間が増えてきます。何を大切にするか、どの資料を正本にするか、どこで人の確認に戻すか。これらを指示書として残すと、次の仕事へ同じ前提を渡しやすくなります。
業務アプリを開発する場合も同じです。画面を作る前に、利用者、扱う情報、試作の範囲、公開前の確認をそろえます。思いつきの依頼を重ねるだけでは、途中で設計の前提が変わったことに気づきにくくなるからです。
違いは名前だけでなく、何を読み込むか
CodexはAGENTS.mdを指示として読みます。プロジェクトのルートから現在の作業フォルダまでにある指示を重ね、近い階層の指示が先の指示を上書きします。作業フォルダがどこか、指示が実際に読み込まれたかを、仕事の開始時に確認しましょう。
Claude CodeではCLAUDE.mdが使われますが、公式説明ではv2.1.277以降、条件付きでAGENTS.mdを直接読む機能もあります。既定では作業フォルダやその上位にCLAUDE.md・CLAUDE.local.mdがあると、そちらを読みます。古いバージョンや設定が異なる環境へ、そのまま同じ挙動を期待しないことが大切です。
同じ方針を二つにコピーして育てない
会社の承認条件をAGENTS.mdとCLAUDE.mdの両方へコピーすると、片方だけ直して食い違うことがあります。会社の正本を一つ決め、各ツールの入口から必要な文書へ案内する運用をおすすめします。
JIKABI AIの全社規程はAGENTS.mdを正本にしています。Claude Codeでそのファイルを直接読まない環境では、CLAUDE.mdの@AGENTS.mdという取込記法を使う方法もあります。ただし、参照を書いただけで全ツールが同じように読むとは限りません。読み込まれた指示を確認してから任せる範囲を広げます。
最初の指示書に入れる5項目
長い理念文より、毎回の判断に使える内容を優先します。例えば、製造業の現場担当者が不具合報告アプリを試作する場合なら、次のように書けます。これは説明用の仮例で、実際の顧客事例ではありません。
- 目的：現場の報告を整理し、確認漏れを減らす。使うのは現場担当者と確認責任者。
- 正本：要件メモと現在の報告様式。内容が食い違ったら確認し、古い資料から推測しない。
- 作業範囲：架空のデータで画面と保存の試作を作る。実際の顧客情報や認証情報は使わない。
- 完了条件：入力・一覧・修正の流れを確かめ、結果と未確認事項を案件フォルダへ残す。
- 人へ戻す点：実データの利用、権限の変更、本番公開・削除は、対象と差分を示して承認を得る。
全社の方針、案件の手順、会社の知識を分ける
全社の指示書には、情報管理や承認、正本の場所など、どの仕事にも共通する原則を置きます。案件フォルダには、利用者、画面、データ、テスト方法など、そのアプリだけの条件を置きます。繰り返す手順はスキルへ、再利用できる説明や判断はナレッジへ残します。
GoogleやAzureで運用するアプリなら、会社の利用環境、アカウント、保存先、権限を案件の設計へつなげます。クラウド名を指示書に書くだけで公開や安全確認が済むわけではありません。試作ができた後も、誰が使い、誰が直し、どう復旧するかを具体化します。
『公開前に確認』と書くだけでは、公開を防げない
指示書はAIへ判断基準を伝える文章です。操作を技術的に禁止する設定ではなく、間違いや見落としをゼロにはできません。公開、データの削除、外部送信などは、実行権限、承認の仕組み、試作環境を分ける方法と組み合わせます。
まずは一つの小さな開発題材で5項目を書き、AIに『目的、作業範囲、人へ戻す点を説明して』と頼んでみてください。読み込まれた文書と回答を確認し、ずれがあれば指示書を直します。その修正理由も残すと、次のアプリ開発で同じ説明をやり直す負担を減らせます。
出典・参考情報
情報は最終更新時点の内容です。サービスの仕様・料金・利用条件は公式情報をご確認ください。