AI コーディングエージェントを使った開発では、リポジトリの中に AGENTS.md や CLAUDE.md といった「AI 向けの指示ファイル」が置かれます。書き方の解説は多くありますが、当社が確認した範囲では、開発チームの内側から書かれたものが中心です。この記事は、開発を外部に頼む発注側の事業責任者の視点で、このファイルをどう扱うかを整理します。受け入れ条件の決め方は前の記事（AI で作ったコードを受け取るとき、発注側が決めておく 5 つの受け入れ条件）で扱いました。この記事では、指示ファイルの所有と更新に絞ります。
このファイルは何で、なぜ発注側に関係するのか
AGENTS.md は、公式サイトで次のように説明されています。
A simple, open format for guiding coding agents,
つまり、人間向けの README に対する、エージェント向けの README です。ビルドやテストのコマンド、コーディング規約、やってはいけないことなどが書かれます。解説記事の一つは、このファイルが古くなったときの害を次のように述べています。
AGENTS.md が古くなると、AIは「嘘をつく」ようになります。
出典：CLAUDE.md・AGENTS.md の書き方解説（Aurant Technologies のブログ）
ここが発注側に関係する理由は 3 つあります。
- このファイルの中身が、AI が書くコードの品質と一貫性を左右する
- リポジトリにコミットされるので、プロダクトの一部としてソースコードと一緒に残る
- 開発会社が変わったとき、このファイルの有無で立ち上がりの速さが変わる
1. 納品物として扱う
外注の開発では、ソースコードと設計書が納品物になります。AI 指示ファイルも、同じ列に並べることを勧めます。これが「このプロダクトをどう開発するか」の現在の約束事だからです。
発注時に確認したいのは、次の 3 点です。
- リポジトリのルートに AGENTS.md または CLAUDE.md があるか。前述の解説記事は、サブディレクトリに置くとツールによっては無視される場合があると述べています
- 書かれている内容が、開発会社の社内ルールではなく、このプロダクトに固有の内容か。ビルド・テストの手順、ディレクトリ構成、禁止事項などです
- 開発会社が独自に持つノウハウや、他の案件の情報が混ざっていないか
これらを、契約書や仕様書の納品物一覧に一行加えるだけで、後の議論が楽になります。
2. 開発会社の変更（ベンダー交代）に備えて、引き継ぎ可能な形にする
開発会社を替えるとき、新しい担当者がまず読むのは、リポジトリとその説明書です。AI 指示ファイルがあれば、新しい担当者も、その担当者が使う AI エージェントも、同じ前提から始められます。
引き継ぎやすい状態の目安は、次のとおりです。
- 特定のツールの設定だけに依存していない。AGENTS.md は複数のコーディングエージェント向けの共通の形式として公式サイトが説明しています。CLAUDE.md を使っている場合は、AGENTS.md との関係（どちらが正か、両方置くか）を開発会社に確認してください
- コードやディレクトリ構成を読めば分かることではなく、プロダクト固有の判断や、過去に事故が起きた箇所の注意書きが残っている
- 個人の端末にしかない設定ではなく、リポジトリの中に入っている
また AGENTS.md は、公式サイトによると、作業対象に最も近いファイルが優先されます。
Agents automatically read the nearest file in the directory tree, so the closest one takes precedence
大きなプロダクトでは、ルートとサブディレクトリに複数のファイルが置かれることがあります。引き継ぎのときは、どのファイルが優先されるかも一緒に説明してもらうと、読み違いを防げます。
3. 更新を、変更の承認ルールに組み込む
指示ファイルは、一度書いて終わりではありません。古くなると AI が誤った前提でコードを書くからです。前述の解説記事は、プルリクエストの確認項目に、関連ドキュメントの更新の有無を入れることを勧めています。
発注側は、次の 3 つを開発会社と決めておくとよいでしょう。
- 誰が更新するか：機能追加のたびに、その担当者が更新する。更新を別作業にしない
- 誰が承認するか：指示ファイルの変更は、AI の振る舞いを変えるので、コードの変更と同じようにレビューの対象にする。禁止事項やセキュリティに関する記述の変更は、発注側にも共有してもらう
- どう確かめるか：変更の前後で、AI が書いたコードの傾向が想定どおりかを、レビューで見る。確かめ方の考え方は、前の記事「AI で作ったコードを受け取るとき、発注側が決めておく 5 つの受け入れ条件」も参考になります
4. 書いてはいけないものを決める
指示ファイルはリポジトリにコミットされます。前述の解説記事も、API キー、データベースのパスワード、秘密鍵などの機密情報は書かないよう述べています。発注側は、次の点を取り決めに入れておくと安心です。
- 機密情報、顧客情報、個人情報を書かない
- 他の案件の情報や、他社の社内ルールを書かない
- 不要になったルールは削除し、古い指示を残さない
発注前に確認したい 5 つの問い
- AGENTS.md または CLAUDE.md は、納品物に含まれていますか
- ルートに置かれ、このプロダクト固有の内容になっていますか
- 更新の担当者と、変更のレビュー方法が決まっていますか
- ベンダーを替えたとき、新しい担当者がそのまま使える形ですか
- 機密情報が書かれていないことを、どう確かめますか
AI を使った開発では、コードと同じくらい、AI に渡す前提が品質を決めます。その前提を発注側が把握し、引き継げる状態にしておくことが、長く使えるプロダクトにつながると考えています。
Urchin&Company の「SaaS・業務アプリ開発」「AIプロトタイプ・MVP開発」では、開発の進め方も含めてご相談を受け付けています。
お気軽にご相談ください
ECサイト構築やSaaS・業務アプリ開発、AIプロトタイプ・MVP開発について、
15年以上の経験を持つコンサルタントがお客様の課題を深く理解し、最適なソリューションをご提案します。