AIコーディングエージェントに「クリーンなコードを書いて」と頼むと、多くの場合、当たり障りのない平均的なコードが返ってきます。では「『Clean Code』の原則に従って」と本の名前を挙げれば、質は上がるのでしょうか。agent-rules-books の作者が実際に検証したところ、答えは「本の名前を挙げるより、その本の具体的なルールを列挙したほうが、はるかに効く」でした。
agent-rules-books は、この知見をそのまま形にしたオープンソースです。『Clean Code』『Refactoring』『ドメイン駆動設計（DDD）』といったソフトウェア設計の名著の原則を抽出し、Codex・Cursor・Claude Code向けの「AGENTS.mdルール／スキル」に蒸留しています。MITライセンスで、GitHubのスターは2,000を超えます。本記事では、このagent-rules-booksが何を収録し、mini/nano/fullの3版をどう使い分け、そして「本当に効くのか」の検証結果まで、公式リポジトリの一次情報から解説します。
Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
- ・agent-rules-booksは、名著13冊＋Refactoring.Guruの設計原則を、AGENTS.mdルール／スキルに蒸留したOSS（MIT）。
- ・Codex・Cursor・Claude Code・Copilotで使える。各ルールはmini（推奨）/ nano（最小）/ full（正典）の3版。
- ・作者の検証では「本の名前を挙げる」より「具体ルールを列挙」が効いた（74点 vs 46点／ただし初期の定性シグナル）。
- ・本の要約でも代わりでもない。本文は再現せず、軽量な「作業上の取り決め」として使う。
1. agent-rules-books とは — 名著の原則をエージェントの規範に
ciembor/agent-rules-books は、開発者Maciej Ciemborowicz氏が公開する、MITライセンスの「コーディングエージェント向け・汎用プロジェクトルール」集です。中身は、ソフトウェア設計・アーキテクチャ・リファクタリング・レガシーコード・信頼性・データ集約システムといったテーマの名著から着想を得た、そのまますぐ使えるルールセットです。GitHubのスターは2,000を超え、AIコーディングエージェントの規範づくりに関心を持つ開発者の間で、静かに支持を集めています。
このリポジトリが解こうとしているのは、「AIエージェントに、良いコードを書かせるにはどう指示すればいいか」という問題です。冒頭で触れたとおり、本の名前を挙げるだけでは弱い。そこでagent-rules-booksは、名著の原則を具体的なルールの箇条書きとして抽出し、AGENTS.mdやCLAUDE.mdに置ける形にしました。エージェントは、コードを生成・レビュー・リファクタするたびに、この規範を参照します。
考えてみれば、これは人間のチームでやっていることと同じです。優秀なチームには、明文化されたコーディング規約やレビュー観点があり、新しいメンバーもそれを見て水準に合わせます。「良いコードを書け」と精神論を説くのではなく、「関数は一つの責務に」「テストなしに変更しない」といった具体的な取り決めを共有する。agent-rules-booksがやっているのは、その「チームの規約」を、名著という信頼できる源泉から作り、AIエージェントというチームメンバーに渡すことです。エージェントは疲れず、忘れず、毎回同じ規範を適用してくれるので、規約を明文化する効果は人間相手より大きいとさえ言えます。
。ここが「良い設計をして」という漠然とした指示や、「この本に従え」という丸投げとの決定的な違いです。
対応するのは、Codex・Cursor・Claude Codeといった主要なコーディングエージェント。プレーンなMarkdownなので、ツールを選びません。各ルールセットはtool-agnostic（ツール非依存）に書かれており、CLAUDE.mdにコピーしても、Cursorのプロジェクトルールに変換しても、Copilotのカスタムインストラクションに流用しても機能します。GitHub Pagesにはドキュメントサイトも用意されています。
なぜ「ツール非依存」が重要なのか。いまやAIコーディングエージェントは乱立しており、チーム内でもClaude Codeを使う人、Cursorを使う人、Codexを使う人が混在するのが普通です。そこでルールが特定ツール専用だと、同じ設計規範をツールごとに書き直す羽目になります。agent-rules-booksはプレーンなMarkdownという最大公約数で書かれているため、どのツールにも同じ規範を配れる。「AGENTS.md」という、コーディングエージェント向け指示ファイルの共通規約に乗っていることも、この移植性を支えています。エージェントが変わっても、蓄積した規範はそのまま使い回せる——これは長い目で見て大きな利点です。
読者が当サイトのOSS解説に求める「①結局何ができる／②何を解決する／③何を代替できる」に当てはめれば、agent-rules-booksは「①名著の設計原則をエージェントに適用させる／②『本の名前を挙げるだけでは効かない』問題を解決する／③場当たり的なコーディング指示や、自分でゼロからAGENTS.mdを書く手間を代替する」ツールだと言えます。
2. mini / nano / full — 3つの粒度で提供する
agent-rules-booksの実用性を支えているのが、各ルールセットを3つのバージョンで提供するという設計です。これは、AIエージェントの「コンテキスト予算（context budget）」という現実的な制約に配慮したものです。名著の原則をすべて漏れなく書き出せば、当然ながら分量は膨れ上がります。しかしエージェントに渡せる指示には限りがあり、長すぎるルールは読まれないか、他の重要な文脈を押しのけてしまう。ここに「1つのルールセットを、粒度違いで3版持つ」という工夫が効いてきます。
3版の違いは、粒度です。
・mini：実運用で推奨される標準版。要点を絞ってあり、多くの実タスクはこれで足りる
・nano：コンテキスト予算が非常に厳しいときのコンパクトなフォールバック
・full：出典や参照を含む正典・完全版。リファレンスとして使う
数字で見ると、この違いは鮮明です。たとえば『Clean Code』のルールセットは、fullが約220ルール（297行）、miniが約29ルール（47行）、nanoが約14ルール（32行）。『ドメイン駆動設計』に至っては、fullが約523ルール（979行・42KB超）と大部で、miniの約30ルール（48行）とは桁が違います。
| バージョン | 位置づけ | 例（Clean Code） | 使いどころ |
|---|---|---|---|
| mini | 推奨・標準 | 約29ルール／47行 | 日常のコーディング・レビュー |
| nano | 最小フォールバック | 約14ルール／32行 | コンテキストが逼迫している時 |
| full | 正典・完全版 | 約220ルール／297行 | 深掘り・リファレンス |
なぜ3版なのか。エージェントに渡せる指示の量には上限があり、ルールを詰め込みすぎれば、肝心のコードやタスクに割ける文脈が減ってしまいます。かといって削りすぎれば原則が伝わらない。miniは、その「効き目」と「軽さ」のバランスを取った実用解です。多くの場合はminiで十分で、コンテキストが逼迫したらnanoに落とし、じっくり参照したいときだけfullを開く——この使い分けが、限られた文脈を賢く使うコツになります。
この3版構成は、AIエージェントを実運用する人の悩みに、よく応えています。CLAUDE.mdやAGENTS.mdにあれもこれもと規範を詰め込むと、ファイルが肥大化し、毎回のリクエストでトークンを食い、かえって重要な指示が埋もれます。逆に軽くしすぎると、エージェントは自由に振る舞い、品質がぶれる。fullをそのまま常駐させれば数百ルールでコンテキストを圧迫しますが、miniなら数十ルールに凝縮されているので、常駐させても負担が小さい。「普段はminiを置いておき、特定タスクで深掘りしたいときだけfullを参照する」という運用が、現実的な落とし所になります。ルールを機械可読な粒度で刻んでおくことは、エージェント運用のコスト管理そのものに直結するのです。
なお、リポジトリはルール数の数え方も「決定論的なリリース規約」で統一しており、full/mini/nanoそれぞれの行数・ルール数・バイト数をメトリクスとして公開しています。どのバージョンがどれくらいの重さなのかが数字で分かるので、自分のコンテキスト予算と照らして選びやすくなっています。
3. 収録された13冊の名著 ＋ Refactoring.Guru
では、どんな本が蒸留されているのでしょうか。収録されているのは、ソフトウェアエンジニアリングの「古典」と呼べる13冊の名著＋Refactoring.Guru（計14ルールセット）です。いずれも、ソフトウェア開発者の間で長く読み継がれ、設計やコード品質を語るうえで避けて通れない定番ばかり。逆に言えば、流行り廃りの激しいフレームワークやライブラリの話ではなく、「良いソフトウェアとは何か」という普遍的な原則を扱う本に絞られているのが特徴です。だからこそ、AIエージェントに持たせる規範として、長く使える土台になります。
| ルールセット | 著者／出典 | 主眼 |
|---|---|---|
| A Philosophy of Software Design | John Ousterhout | 深いモジュール・複雑さとの戦い |
| Clean Architecture | Robert C. Martin | 境界と依存性ルール |
| Clean Code | Robert C. Martin | 可読性・命名・小さな関数 |
| Code Complete | Steve McConnell | 構築の実践・防御的プログラミング |
| Designing Data-Intensive Applications | Martin Kleppmann | 信頼性・一貫性・レプリケーション |
| Domain-Driven Design | Eric Evans | ユビキタス言語・境界づけられた文脈 |
| Domain-Driven Design Distilled | Vaughn Vernon | DDDの実践的入門 |
| Implementing Domain-Driven Design | Vaughn Vernon | 集約・ドメインイベント・実装 |
| Patterns of Enterprise Application Architecture | Martin Fowler | 層・リポジトリ・データマッパー等 |
| Refactoring | Martin Fowler | 挙動を変えず構造を改善する |
| Release It! | Michael T. Nygard | 本番で生き残る設計・サーキットブレーカ |
| The Pragmatic Programmer | Hunt / Thomas | DRY・直交性・自動化 |
| Working Effectively with Legacy Code | Michael Feathers | 特性テスト・依存の切り離し |
| Refactoring.Guru | Refactoring.Guru | コード臭カタログ・リファクタ手法 |
顔ぶれを見れば、このリポジトリの狙いがよくわかります。設計（APoSD・Clean Architecture・PoEAA）、コード品質（Clean Code・Code Complete・Pragmatic Programmer）、リファクタリング（Refactoring・Refactoring.Guru・Working Effectively with Legacy Code）、ドメインモデリング（DDD三部作）、信頼性・データ（Release It!・DDIA）——ソフトウェアエンジニアが「読んでおくべき」とされる領域を、幅広くカバーしています。特定の言語やフレームワークに寄らない、言語横断的な原則ばかりなので、どんな技術スタックのプロジェクトにも適用できるのも利点です。
これらは単なる書名リストではありません。各ルールセットには、その本が何を主眼とし、どんな場面のルールセットとして役立つかが明記されています。たとえば『Working Effectively with Legacy Code』は「テストの乏しい難しいコードを安全に変更する」ためのルール、『Release It!』は「サービス・API・キュー・本番の重要経路」向けのルール、といった具合に、適用場面まで含めて整理されているのです。
この「場面ごとに使い分ける」という発想は、実務で効いてきます。すべての本のルールを常に全部読ませるのは、コンテキストの無駄ですし、焦点もぼやけます。新規のドメインモデリングをするならDDD三部作のどれか、既存の危ういコードに手を入れるならWorking Effectively with Legacy CodeとRefactoring、本番の信頼性を詰めるならRelease It!とDDIA——というように、いま取り組んでいるタスクに合った一冊（か数冊）のルールを選んで渡すのが、賢い使い方です。agent-rules-booksは、この「タスクに合わせてルールを選ぶ」ことを前提に、各ルールセットの守備範囲を明示しています。だからこそ、docs/COMPATIBILITY.md に「複数の本を組み合わせるときの相性」まで用意されているわけです。名著をただ並べたのではなく、「エージェントに、いつ・どのルールを効かせるか」まで設計されている点が、このリポジトリの実用性を高めています。
4. 「本当に効くのか」— 74点 vs 46点の検証
このリポジトリで最も誠実なのが、「Does it work?（効果はあるのか）」というセクションを自ら設けている点です。この手のツールは「これを使えば劇的に良くなる」と喧伝しがちですが、agent-rules-booksの作者は、効果を過大に主張するのではなく、初期の検証結果を——都合の悪いデータも含めて——正直に共有しています。この姿勢自体が、リポジトリへの信頼を高めています。
検証の中身はこうです。まず、意図的に雑に生成した（vibe-codedな）ヘルプデスクCLIのプロジェクトを用意します。これを2通りにリファクタして比較しました。片方は本リポジトリの『A Philosophy of Software Design』のminiルールを使い、もう片方は「# OBEY A Philosophy of Software Design by John Ousterhout」——つまり本の名前だけを指示。どちらもCodexで計画（PLAN.md）を生成し、同じモデルで実行しました。
そのうえで、両方のコードをChatGPTに「どちらが本の原則をよく実装できているか、どれくらい差があるか」と尋ねたところ、miniルール版が約74/100、本の名前だけの版が約46/100という評価が返りました。「本を挙げるだけでなく、具体的なルールを列挙するほうが、著者の設計原則を適用させる効果が高い」ことを示唆する結果です。
作者は、この結果を「ベンチマークではなく、初期の定性的なシグナル」として扱うよう明言しています。実際、静的解析ツール（Reek）によるコード臭の数は、ルールなし版が1083、miniリファクタ版が1077と、ほぼ差がありませんでした。差が出たのは、生の臭の数ではなく、モジュールの深さ・責務の境界・情報隠蔽・「読者が一度に理解すべきコード量を減らせたか」といったアーキテクチャ的な判断の面です。他の本での同等の実験や、より深い計測は、トークン予算と手作業レビューの負担が大きいため、現時点では予定されていないとのこと。あくまで一つの参考データとして受け止めるのが適切です。
それでも、この検証には価値があります。「AIに良い設計をさせたい」と思ったとき、多くの人は本のタイトルを唱えたり、抽象的な理念を伝えたりしがちです。しかしこの実験は、抽象を具体に落とし込むこと——原則を、エージェントが従える箇条書きのルールにすること——の効果を、素朴ながら定量的に示しています。agent-rules-booksが提供しているのは、まさにその「具体に落とし込んだルール」なのです。
なぜ本の名前だけでは弱いのか、少し考えてみると腑に落ちます。LLMは確かに『Clean Code』の内容を学習データとして知っているでしょう。しかし「この本に従え」という指示は、モデルにとって解釈の幅が広すぎます。何を優先し、どの原則をどこまで適用するのか——その判断がモデル任せになれば、結局は平均的な出力に流れやすい。一方、「関数は小さく」「命名は意図を表す」「重複を排除する」といった具体ルールが目の前にあれば、モデルはそれを直接のチェックリストとして使えます。人間のコードレビューでも、「良いコードを書け」より「この観点で見て」のほうが機能するのと同じ理屈です。agent-rules-booksの核心的な価値は、この「解釈の幅を狭め、従えるルールにする」という一点に凝縮されています。
そして、コード臭の数がほとんど変わらなかった（1083 vs 1077）という事実も、正しく読めば示唆に富みます。静的解析が数える「臭」は、命名の長さや関数の引数の数といった表層的な指標が中心です。miniルールがもたらした差は、そうした表層ではなく、「モジュールをどう切るか」「責務をどこに置くか」という、機械では測りにくい構造的な判断に現れた。つまり、良い設計の本質は静的解析のスコアには表れにくく、だからこそ人間（やLLM評価者）の目で構造を見る必要がある——という、設計そのものへの洞察にもつながる結果なのです。ルールを与えることの効果は、「臭を1つ減らす」ような局所最適ではなく、「構造をどう組み立てるか」という大局的な判断に現れる。これは、agent-rules-booksが扱っている名著の多くが、まさにその「大局的な設計判断」を主題にしていることとも呼応しています。
5. どう使うか — Codex / Cursor / Claude Code での導入
導入は、プレーンなMarkdownを配置するだけなので簡単です。特別なインストールもランタイムも要りません。必要なファイルを選んで、エージェントが読む場所（AGENTS.mdやCLAUDE.md、あるいはスキルのディレクトリ）に置くだけ。使い方の全体像を図にすると、こうなります。
設計 / リファクタ / DDD / 信頼性"] --> B["対応する本のルールセットを選ぶ
13冊 + Refactoring.Guru"] B --> C{"コンテキスト
予算は"} C -->|"通常"| M["mini（推奨）"] C -->|"逼迫"| N["nano（最小）"] C -->|"参照/深掘り"| F["full（正典）"] M --> D["配置する"] N --> D F --> D D --> E["AGENTS.md / CLAUDE.md に貼る
or スキルとして登録"] E --> G["エージェントが生成・レビュー・
リファクタ時に適用"]
具体的には、まず自分の課題（設計を良くしたい／安全にリファクタしたい／DDDで考えたい／本番の信頼性を上げたい等）に対応する本のルールセットを選び、コンテキスト予算に応じてmini/nano/fullを選びます。そして、その内容をAGENTS.mdやCLAUDE.mdにプロジェクトメモリとして貼るか、焦点を絞ったminiルールをClaude Codeのスキルとして登録します。あとはエージェントが、コードを生成・レビュー・リファクタするたびに、その規範に従います。
いきなり全部を入れる必要はありません。むしろ、最初は自分のプロジェクトに最も関係が深い一冊を選び、そのminiルールだけを置いてみるのがおすすめです。たとえばレガシーな社内ツールを触っているなら Working Effectively with Legacy Code、新規のドメインロジックを組むなら Domain-Driven Design Distilled、といった具合に。効果を感じたら別の本のルールを足し、COMPATIBILITY.md を見ながら相性の良い組み合わせに広げていく。小さく始めて、手応えを確かめながら育てるのが、規範づくりの現実的な進め方です。全部盛りは、コンテキストを圧迫するだけで効果が薄れがちなので避けたほうが無難です。
エディタごとの推奨セットアップは、リポジトリの docs/USAGE.md に詳しくまとまっています。常時オン（always-on）でプロジェクト全体に効かせるのか、オンデマンドでスキルとして必要時だけ読ませるのか、スコープ付きルールにするのか、MCPやRAGのパターンで参照させるのか——エディタの特性に応じた使い分けが解説されています。複数の本を組み合わせて使いたい場合の相性は、docs/COMPATIBILITY.md が指針を示します。
「常時オン」と「オンデマンド」の違いは、運用設計として重要です。プロジェクト全体で常に守らせたい普遍的な規範（Clean Codeの基本など）は、CLAUDE.mdに常駐させて常時オンにするのが向いています。一方、リファクタするときだけ・レガシーコードに触るときだけ効かせたいルールは、スキルとして登録しておき、その作業に入ったときだけ読み込ませるほうが、普段のコンテキストを圧迫しません。この「常駐かオンデマンドか」を、ルールの性質に応じて選べるのが、mini/nano/fullの3版構成と噛み合っています。軽いminiを常駐させ、深いfullを必要時にオンデマンドで参照する、といった組み合わせが自然に組めるわけです。
FAQでも触れられているとおり、Claude Codeなら「選んだルールセットをCLAUDE.mdにプロジェクトメモリとしてコピーする」か「miniルールをスキルに仕立てる」のが定番。Cursorならプロジェクトルールへ、Copilotならカスタムインストラクションやプロンプトファイルへ——と、ツールに合わせて柔軟に取り込めます。いずれの場合も、やることは「Markdownを選んで、エージェントが読む場所に置く」だけ。難しい設定は要りません。CLAUDE.mdの設計そのものに興味があれば、awesome-claude-md 解説｜CLAUDE.mdのベストプラクティス集 や、AIに判断基準を持たせる考え方をまとめた taste-skill 解説 もあわせて読むと、規範づくりの視野が広がります。
6. agent-rules-books は何を代替し、誰に向くか
agent-rules-booksが代替するのは、「自分でゼロから、名著の原則をAGENTS.mdに書き起こす手間」です。Clean CodeもRefactoringもDDDも、読んで理解したうえで「エージェントに効くルール」に翻訳するのは、それ自体が大仕事。しかも、粒度をmini/nano/fullに分けて整理し、適用場面まで書き添えるとなれば、片手間でできる作業ではありません。そこを、13冊ぶんの蒸留済みルールセットとして肩代わりしてくれるのが、このリポジトリの実用的な価値です。自分でやれば何日もかかる整備を、クローンして貼るだけで済ませられます。
このプロジェクトが向くのは、次のような人・チームです。
・AIエージェントに一定の設計品質を守らせたい人：名著の原則を、具体ルールとしてプロジェクトに常駐させられる
・AGENTS.md / CLAUDE.md を整備したいが、何を書けばいいか迷う人：出発点として質の高いテンプレートになる
・リファクタやレガシーコード対応を安全に進めたい人：Refactoring・Working Effectively with Legacy Codeのルールが効く
・チームでコーディング規範を揃えたい人：ツール非依存なので、Codex・Cursor・Claude Codeが混在しても同じ規範を共有できる
・名著は積んでいるが実務に落とせていない人：原則を「エージェントが従うルール」として日々のコードに効かせる入口になる
一方で、注意すべき前提もあります。作者が明言しているとおり、これらは名著の公式資料ではなく、本を読む代わりにもなりません。本文を再現しないよう意図的に作られた、実践的な作業指示です。要約やスタディノートとして扱うのではなく、あくまで「軽量な作業上の取り決め」として使うのが正しい姿勢です。名著そのものの深い理解は、やはり本を読むことでしか得られません。agent-rules-booksは、その理解をエージェントの日々の振る舞いに反映させるための「橋渡し」だと捉えると、位置づけを誤りません。
この「本の代わりにはならない」という但し書きは、著作権への配慮という意味でも誠実です。本の文章をそのまま抜き出して配れば、それは著作権上の問題になりかねません。agent-rules-booksは、あくまで原則を自分の言葉で「作業指示」に翻訳することで、その一線を守っています。だからこそ、これを読んでClean Codeを理解したつもりになるのは筋違いで、原則の背景にある思想や具体例は、原著にあたるべきです。ルールは「何をすべきか」を教えてくれますが、「なぜそうすべきか」の深い理解は本にしかありません。両者は補完関係にあり、agent-rules-booksを使いこなす人ほど、実は原著を読む価値を実感するはずです。
もう一つ、過信への戒めも添えておきます。ルールを置いたからといって、エージェントが必ず良い設計を出すわけではありません。ルールはあくまで「効きやすくする」ための土台であり、最終的なコードの良し悪しは人間がレビューして担保する必要があります。前述の検証が「初期の定性シグナル」に留まることを思えば、agent-rules-booksを万能薬のように扱うのは禁物です。規範を与えたうえで、出力を人間が確かめる——この基本を外さなければ、名著の知恵をAIコーディングに活かす強力な足場になります。
agent-rules-booksは、Clean CodeやRefactoring、DDDといった名著の設計原則を、Codex・Cursor・Claude Code向けの具体的なAGENTS.mdルール／スキルに蒸留したOSSです。mini/nano/fullの3版でコンテキスト予算に配慮し、13冊＋Refactoring.Guruの幅広い領域をカバー。さらに「本を挙げるより具体ルールが効く」という検証を、過度に誇張せず正直に共有しています。本を読む代わりにはなりませんが、その理解をエージェントの振る舞いに落とし込む橋渡しとして、AIコーディングの品質を底上げしてくれる一本です。名著を積んだままにしている人にも、AGENTS.md整備に悩む人にも、まず触れてみる価値があります。
まとめ
本記事では、ソフトウェア設計の名著の原則を、AIコーディングエージェント向けのAGENTS.mdルールに蒸留したOSS、agent-rules-booksを、公式リポジトリの一次情報にもとづいて解説しました。
その核心は、「原則を唱えるのではなく、具体的なルールに落とし込む」ことにあります。名著の知恵は、本棚に眠らせておいても、AIエージェントの出力には反映されません。それを、エージェントが毎回参照できる具体ルールの形にして初めて、日々のコードに効いてきます。『Clean Code』『Refactoring』『DDD』など13冊＋Refactoring.Guruの原則を、mini/nano/fullの3版でAGENTS.md／CLAUDE.mdに置ける形にし、Codex・Cursor・Claude Codeで使えるようにする。しかも「本の名前を挙げるより、具体ルールを列挙したほうが効いた（74点 vs 46点）」という検証を、ベンチマークではなく初期シグナルだと断ったうえで正直に示しています。本を読む代わりにはならないと明言する誠実さも含め、AIにコードを書かせる時代の「規範づくり」の実践例として、押さえておく価値のあるプロジェクトです。まずは自分のプロジェクトに、関係する一冊のminiルールを置いてみるところから始めるのが良いでしょう。そこから、名著の知恵が自分のコードにどう効いてくるかを、手を動かしながら確かめてみてください。小さな一歩ですが、AIにコードを任せる時代の「規範づくり」を体感する、良い入口になるはずです。
参照ソース
・agent-rules-books（ciembor 公式リポジトリ） — 本記事が解説した一次情報。14ルールセット・3版・検証のすべて
・agent-rules-books（GitHub Pages ドキュメント） — 収録ルールと使い方のドキュメントサイト
・AGENTS.md（コーディングエージェント向け指示ファイルの規約） — 本リポジトリが前提とするAGENTS.mdの仕様
