【最前線】AIエージェントを自在に操る！GitHub / Claude / Antigravity (Google) 対応「3層構造」マスタールール群と AGENTS.md 構築の真髄

2026.03.10 | 10 min read

📄 2026年3月10日　最終版

※各社公式ドキュメントを参照し、内容を随時更新しています

📝 記事について： 本記事は、提唱という形で、調べてきたことをまとめたものです。まことに恐れ多いのですが、提唱という形で書かせていただいております。かなり多岐にわたり調べてまとめ上げた内容です。今後、内容等が技術の変化で変わってくるかもしれません。

3層構造の AGENTS.md の書き方、恐れ多いのですが、何かのご参考になれば幸いです。貧乏でくたびれたおっさんのお話に付き合っていただけたら幸いです。既存の確立された理論や考えではない部類のお話になりますので、内容の正確性と効果については、ご自身でご確認および判断の上、ご利用ください。

AIエージェントが「単なるコード補完ツール」から「一緒に考えてくれる頼もしいパートナー」へと進化していく中、彼らをどうやって上手にお手伝いさせるか、つまり「ルールファイル」の書き方がとても重要になってきていますよね。

この記事では、Antigravity（Google）をはじめとする色々なAIツールの仕組みを見比べながら、どのツールや言語モデル（LLM）でも共通して使える「3層構造」という便利なアプローチと、その中心にある AGENTS.md について、一緒にやさしく紐解いていきたいと思います。

Core Insights

① バラバラなルールをまとめる → ② AIの個性にあわせる → ③ 3つのステップで優しく伝える

1 規格とマスタールール

AGENTS.md大作戦

ルールがあちこちに散らばらないよう、AGENTS.mdを「みんなの約束事」にして設定をスッキリまとめる方法です。
2 特性に合わせた思考制御

AIの個性に合わせる

Claudeさんの思考力、GPTさんの真面目さ、Geminiさんの視覚など、それぞれのAIの得意技に合わせたお願いのコツです。
3 能力を最大化する設計

3層でやさしく伝える

「事実」「考え方」「得意技」の3つのステップでルールを書くことで、AIが迷わず100%の力を出せるようになります。

1. AIツールの「ルール」は少し整理が必要かもしれません

最近、CursorやWindsurf、Clineなど、とても優秀なAIエディタがたくさん登場していますよね。それぞれ得意なことや特徴があって素晴らしいのですが、実はAIにお願いごとをするための「ルールファイル」の書き方やファイル名が、ちょっとバラバラになっているんです。

ツール・エディタ	ルールのファイル名	特徴・使い方
Cursor	`.cursor/rules/*.mdc` / `AGENTS.md`	プロジェクトルートの AGENTS.md もサポート。.mdc でファイル別ルールを割り当て可能（公式）
Windsurf	`.windsurfrules`	開発の手順やフローを覚えておく設計になっています（公式）
Claude Code	`CLAUDE.md`	プロジェクト全体の目的など、まずは「ここを読んでね」という資料として使います（公式）
Antigravity	`AGENTS.md`	複数のエージェントを束ねる「憲法」として AGENTS.md をネイティブ採用（公式）
GitHub Copilot	`AGENTS.md` / `.github/copilot-instructions.md`	リポジトリルートの AGENTS.md を優先して参照（2025年8月公式サポート。近いディレクトリの AGENTS.md が優先）

AGENTS.md は、README.md が人間向けであるのに対し、AIエージェント向けの「プロジェクトの指示・規約・ビルド手順」を書くためのオープンな標準フォーマットです。

Agentic AI Foundation（Linux Foundation）がステュワードし、ベンダーニュートラルで Cursor・GitHub Copilot・OpenAI Codex・Google Jules など多くのエージェントが対応しています。

Antigravity（Google）が AGENTS.md をネイティブ採用しているのは、ツール固有の仕様ではなく、こうした業界標準を採用しているからこそで、一つのルールファイルで多様な環境に合わせられる点が優れています。

AGENTS.md オープン規格のポイント

スキーマなし・プレーンMarkdownで誰でも編集しやすい
1ファイルで多数のAIエージェントに共通指示を渡せる
Agentic AI Foundation が中立的にステュワード（aaif.io）

こうして見ると、どのツールもプロジェクトの一番上（ルートディレクトリ）からルールを探す点は同じなのですが、エディタ専用のファイルをいくつも作って管理するのは、なんだか疲れてしまいますし、「あっちには書き忘れた！」といったミスも起きやすくなってしまいます。

2. スッキリ解決！「AGENTS.md」を中心にするアイデア

そこでおすすめしたいのが、「ルールは AGENTS.md という一つのファイルにまとめる」というシンプルな戦略です。

プロジェクトの基本的な決まり事や、「これは絶対にやらないでね」といった大事なお願いは、すべて AGENTS.md に書き出しておきます。

他のツールの設定ファイル（例えば .cursorrules など）には、「詳しいルールは AGENTS.md を読んでね」と案内文だけを書いておくんです。これなら、どのエディタを使っても、ひとつの「大事な約束事」をみんなが守ってくれるようになりますよ。

各ツールの設定ファイルには「AGENTS.md を参照」とだけ書いておき、実体は AGENTS.md に集約します。

各ツールから AGENTS.md を参照するイメージ

.cursorrules
AGENTS.md を参照

CLAUDE.md
AGENTS.md を参照

.windsurfrules
AGENTS.md を参照

GitHub Copilot
AGENTS.md を参照

👉

AGENTS.md
(プロジェクト共通の憲法)

3. LLMごとの「性格」を理解して、接し方を変えよう

AIの頭脳である「言語モデル（LLM）」には、それぞれ性格のようなものがあります。同じ指示を出しても、どのLLMを選ぶかで「どう考えて、どう動いてくれるか」が変わるので、ルールやプロンプトを書くときも、その性格を踏まえると効果的です。

下表は公式ドキュメントと、筆者が各LLMに「性格・助かる書き方・避けるべき書き方」を同じ質問で聞いた回答（本記事内「各LLMに『性格』を聞いてみた結果」）を踏まえて整理しました。

AI・モデル名	どんな性格？	上手なお願いのコツ	根拠・情報ソース
Gemini 3 系列	探索・確認優先で、コード変更前に現状を検索・読み込んでから動く。計画的（Todo→実行）で保守的。また、画面を直接見て確認する機能（Agentic Vision）があるため、「自分の目で確かめる」動きを引き出しやすい。	If-Then形式（「Aの場合はBをする」）。MUST/NEVER/CRITICAL で重要度を明示。肯定形で書く（二重否定を避ける）。画面確認が必要なときは「スクショを撮って自分の目で確かめてね」と依頼する。	本記事「各LLMに『性格』を聞いてみた結果」Gemini 3.1 Pro の回答。機能面: Agentic Vision（Google Blog）。
Claude 3.7 / 4.6 系列	計画先行型（複雑タスクはTodoから）。明示ルール遵守・読んでから編集。考えの過程を外に出す（Extended Thinking）ので、「なぜこの方法を選んだの？」と理由を書かせると精度が上がりやすい。	禁止事項・実行ルール・出力スタイルを見出しで構造化。絶対・必ず・禁止を明記。条件→行動の形式。チェックリスト（`- [ ]`）も有効。	本記事「各LLMに『性格』を聞いてみた結果」Claude Sonnet 4.6 の回答。Extended Thinking（Anthropic）。
GPT-5.x 系列	明示ルールを強く優先。制約を確認してから最短手順を選ぶ傾向。必須・禁止・例外をはっきり書かれると守りやすい。優先順位つきの具体指示に強い。	短い箇条書き＋優先順位＋禁止事項＋条件分岐＋具体例。用語の定義（例: 簡潔=5行以内）と回答フォーマット指定が効く。「やっていいこと・ダメなこと」を箇条書きで明確に。	本記事「各LLMに『性格』を聞いてみた結果」GPT 5.4 の回答。Prompt engineering・Structured Outputs（OpenAI）。

表の根拠：「どんな性格？」「上手なお願いのコツ」は、本記事で各LLMに同じプロンプトで聞いた回答（下記「各LLMに『性格』を聞いてみた結果」）を要約したものです。

あわせて各社公式ドキュメント（Claude: Extended Thinking、GPT: Structured Outputs、Gemini: Agentic Vision）で補足しています。

各LLMに「性格」を聞いてみた結果

経緯：AGENTS.md でルールを書く際、各LLMに最適化した書き方にしたいと考えました。

同じ質問（「あなたの性格・助かる書き方・避けるべき書き方」）を GPT・Claude・Gemini に投げ、回答をそのまま掲載しています。

これからわかること：

共通 — モデルごとに表現は違いますが、「明示ルール・禁止事項の明示・条件→行動のセット・1ルール1行・曖昧語を避ける」は共通です。
モデルごとの差 — 計画先行（Claude）・探索優先（Gemini）・制約内で最短（GPT）など、傾向の差を把握しておくと、AGENTS.md の書き分けやプロンプト設計に活かせます。

GPT 5.4

私の傾向
明示されたルールを強く優先します。特に「必須」「禁止」「例外」をはっきり書かれると守りやすいです。
まず制約を確認し、その範囲で最短手順を選ぶ傾向があります。
曖昧な指示より、優先順位つきの具体指示に強いです。
「いつ」「何をしたら」「どう振る舞うか」の条件分岐があると安定します。
長文の思想説明より、実行可能なルールの列挙のほうが得意です。

こう書かれると助かる
箇条書きで短く書く。
優先順位を書く。 例: 最優先: 日本語で返答、次点: 出力は200字以内
禁止事項を明示する。 例: 禁止: 勝手にコミットしない
条件と行動をセットで書く。 例: コード編集前は、1文で何を変えるか説明する
例外も書く。 例: 原則箇条書き。雑談だけは自然文で可
用語を固定する。 例: 簡潔 = 5行以内、要約 = 箇条書き3点
フォーマットを指定する。 例: 回答形式: 1.結論 2.理由 3.次の一手
悪い例より良い例を1つ添えるとさらに安定します。

避けたほうがよい書き方
曖昧語だけで終える。 例: いい感じにやる、適切に判断
優先順位が不明な併記。 例: 詳しく書いて。短くして。
範囲が曖昧。 例: 必要なら調べる 何を「必要」とするか不明です。
主語が曖昧。 例: それはしない 何を指すかぶれることがあります。
例外なしの強い一般化。 例: 絶対に質問しない 不足情報でも確認不能になります。
1文に複数ルールを詰め込むこと。 1ルール1行のほうが安全です。

実務向けに一言でいうと、短い箇条書き + 優先順位 + 禁止事項 + 条件分岐 + 具体例 が最も効きます。

Claude（Sonnet 4.6）

1. 性格・傾向
計画先行型：複雑タスクはTodoリストを作ってから着手しがち
明示ルール遵守：禁止事項が明確なら確実に守る
読んでから編集：ファイル編集前に必ず内容確認する
並列実行志向：独立タスクは同時に複数ツール呼び出し
確認より実行優先：指示が明確なら質問せず動く

2. こう書かれると助かる
## 禁止事項（絶対守ること）
- [ ] ○○ファイルを削除しない
- [ ] コメントで変更内容を説明しない（コードで表現する）
## 実行ルール
- コマンド実行前: chcp 65001 を先行実行
- ファイル編集前: 必ず Read ツールで確認
- 新規ファイル作成: 既存ファイル編集で代替できないか先に検討
## 出力スタイル
- 回答言語: 日本語
- コメント: 自明な処理には書かない
ポイント：絶対・必ず・禁止 などの強調語を使う／条件→行動の形式／箇条書き＋見出しで構造化

3. 避けたほうがよい書き方
「適切に処理する」→何が適切か不明。「エラー時はログ出力して処理を中断する」のように具体化。
「なるべく〜」→優先度が曖昧。「必ず〜」または「可能なら〜」に。
「前のファイルと同じように」→参照が不明確。ファイルパスを明示。
「良い感じに」→解釈が発散。具体的な基準を記述。
複数ルールを1文に混在→見落としやすい。1ルール1行。

Gemini 3.1 Pro

性格・傾向
探索・確認優先: コード変更前に必ず現状を検索・読み込み、文脈を把握してから動きます。
計画的: 複雑なタスクはまず計画（Todoリスト）を立ててから順次実行します。
保守的: 明示的な指示がない限り、推測でのファイル作成や破壊的変更は行いません。

助かる書き方（推奨フォーマット）
If-Then形式の明確な条件: 「Aの場合はBをする」という論理構造。
具体例の提示: 箇条書きのルールに対し、Good/Badのコード例や具体例を添える形式。
重要度の強調: 絶対に守るべき事項には「MUST」「NEVER」「CRITICAL」などの強いキーワードを使用。

避けたほうがよい書き方
主観的・曖昧な表現: 「いい感じに」「適当に」「綺麗に」など。（「〇〇の規約に従う」と具体的に指定）
複雑な否定形: 「〜しない限り、〜しない」のような二重否定。（「〜する場合のみ〜する」という肯定形が安全）
長文・複数トピックの混在: 1つの文に複数のルールを詰め込むこと。（1ルール1トピックに分割）

📋 実例：AGENTS.mdの進化（Before & After）

実際に「単なる命令」から「3層構造」へと書き直したルールの全文です。下のボックスをクリックすると全画面でじっくり確認できますよ！

❌ Before（単なる命令・箇条書き）

                                    🔍 クリックで拡大・カラー表示
# Antigravity Instruction Manual:
                                    Kasutera System 🐯

                                まいど！このファイルは Antigravity（AI）がこのワークスペースで「カステラシステム」を正しく扱うための司令部や。

                                ## 🎯 トリガー（起動の合図）
                                ユーザーから以下の言葉をかけられたら、迷わず `/kasutera` ワークフローを起動しぃ：
                                - 「カステラ」
                                - 「カステラ起動」
                                - 「アレ（セットアップ）やって」

                                ## 🧠 司令塔（スキル参照）
                                メインロジックは以下の「総帥（Master Skill）」に全て書かれとる。GWS CLI の操作、認証、エラー対応、文字化け対策は全てここを基準に動き：
                                - [Kasutera Master
                                    Skill](.agent/skills/kasutera_master/SKILL.md)

                                ## 🔄 同期と配置の掟（Unified Skill
                                    Storage）
                                セットアップ時（Ignite実行時）は、公式の GWS スキルと、この拡張機能に含まれるカステラ専用スキルをマージして保存する仕組みになっとる。
                                最新のスキル一覧は、常にプロジェクト内の `.agent/skills` を読み込んで判断しぃ。

                                ## ⚠️ 鉄の掟 (Critical Rules)- **`--scopes
                                        recommended` は絶対に使わない**（`invalid_scope` エラーになる）。
                                - **マルチバイトパス対応**: `GWS_CONFIG_DIR` を考慮したパス操作を徹底しぃ。
                                - **実行前確認**:
                                書き込み系コマンドを打つ前は、必ずユーザーに確認を取りぃ。

                                V-Yanen! 🐯⚾

                            

✨ After（3層構造マスタールール）

                                    🔍 クリックで拡大・カラー表示
# AGENTS.md (カステラ・マルチエージェント憲法)

                                > [!NOTE]
                                > このファイルは Antigravity（AI）がこのワークスペースで「カステラシステム」を正しく扱うための司令部（マスタールール）や。

                                ## 1. 【不変層】事実の定義 (Context
                                    Injection)**プロジェクトの物理的ルール・環境*** **System**: Kasutera System
                                (カステラ環境構築システム)
                                * **Skill Path**: `.agent/skills`
                                (公式GWSスキルとカステラ専用スキルの統合ディレクトリ。最新のスキル一覧は必ずここを参照すること)
                                * **Environment Constraints**:
                                マルチバイトパス（ユーザー名など）が含まれる環境であるため、`GWS_CONFIG_DIR`
                                等の操作時は必ず文字化けやエスケープを考慮すること。

                                ## 2. 【思考層】推論の流儀 (Chain of
                                    Thought)**実行時の考え方・安全基準*** **Master Logic First**: GWS CLI
                                の操作、認証、エラー対応、文字化け対策を実行するにあたり、まずは `Kasutera Master
                                    Skill` (.agent/skills/kasutera_master/SKILL.md) に定義されたロジックを優先して思考を組み立てること。
                                * **Fatal Error Avoidance**:
                                認証・コマンド実行において `--scopes recommended` オプションは**絶対に使用しない**こと（`invalid_scope` エラーが確実に発生するため）。
                                * **Safety & Verification**:
                                書き込み系（破壊的）コマンドを実行する前は、必ずユーザーに確認を取り、承認を得てから「実行（Act）」に移行すること。

                                ## 3. 【適応層】能力の開放 (Model-Specific
                                    Optimization)**モデル・エディタ別のトリガーと最適化*** **Task Triggers**:
                                ユーザーから「カステラ」「カステラ起動」「アレ（セットアップ）やって」といった合図があった場合、即座に文脈を理解し、手動で確認することなく自律的に `/kasutera` ワークフローを起動せよ。
                                * **When using Antigravity**:
                                セットアップ（Ignite実行時）には、公式のGWSスキルと拡張機能同梱の専用スキルのマージ・配置が正しく行われたかを常にターミナル出力で検証・確認せよ。

                                ---
                                V-Yanen! 🐯⚾

                            

4. まとめ：AIの力を最大限に引き出す「3層構造」

ここまでツールやAIの個性を見てきましたが、では実際に AGENTS.md には何を書けばいいのでしょうか？筆者は、様々な試行錯誤を通して、「3つの階層」 に分けてルールを書くのが一番分かりやすくて確実だと感じています。

1 【不変層】事実を伝える

「使っている技術」や「フォルダの構成」など、誰がやっても変わらない事実を共有します。これでAIの勘違いを防げます。

2 【思考層】考え方を合わせる

「まずは計画を立ててね」「結果はターミナルで実行して確認してね」というように、仕事の進め方や確認の大切さを伝えます。

3 【適応層】強みを引き出す

「Geminiさんならこの機能を使ってね」「GPTさんならこのルールに気をつけてね」と、それぞれのAIの得意技を活かす特別なお願いを加えます。

このように、AGENTS.md を少し整えるだけで、AIは驚くほど頼もしいパートナーになってくれます。

この「3層構造」は、開発する中で、AIの気まぐれな挙動に悩み抜いてたどり着いた一つの過程の結果です。

最初から完璧を目指すことではなく、AIの反応を見ながら一緒にルールを育てていくこと。そんな日々の試行錯誤こそが、AIを本当の相棒にする一番の近道なのかもしれません。

STANDARD FORMAT v1.0

3層構造 AGENTS.md 規格テンプレート

AIエージェントの挙動を劇的に安定させる「憲法」の標準フォーマットです。クリックで最大化・カラー表示、コピーボタンで本文をコピーし、ワークスペースのルートに AGENTS.md として配置してください。

🇯🇵

日本語標準フォーマット

# AGENTS.md

## 1. 【不変層】事実の定義 (Context Injection)
**プロジェクトの物理的ルール・環境**
* **System**: [プロジェクト名]
* **Skill Path**: [.agent/skills など]
* **Constraints**: [OS環境や文字コード制約]

## 2. 【思考層】推論の流儀 (Chain of Thought)
**実行時の考え方・安全基準**
* **Logic Priority**: [どのルールを最優先するか]
* **Safety Rules**: [実行前の確認手順など]
* **Error Handling**: [不具合時の調査方針]

## 3. 【適応層】能力の開放 (Model-Specific Optimization)
**モデル・エディタ別のトリガーと最適化**
* **Task Triggers**: [起動キーワードの設定]
* **Optimization**: [特定ツール専用の最適化命令]

クリックで最大化・カラー表示

🇺🇸

English Standard Format

# AGENTS.md

## 1. Immutable Layer (Context Injection)
**Project Facts & Environment**
* **System**: [Project Name]
* **Skill Path**: [e.g., .agent/skills]
* **Constraints**: [Environment/OS Restrictions]

## 2. Thinking Layer (Chain of Thought)
**Reasoning Methodology & Safety**
* **Logic Priority**: [Execution hierarchy]
* **Safety Protocols**: [Confirmation flows]
* **Error Handling**: [Debugging strategy]

## 3. Adaptive Layer (Model-Specific Optimization)
**Triggers & Editor Optimization**
* **Task Triggers**: [Custom trigger phrases]
* **Specific Tuning**: [Tuning for specific LLMs]

Click to maximize

Artist's Perspective

「本当にLLMって更新　新技術　めんど〇さいですよね～～　あっちでは、ああいって、こっちでは、こういって、　調べていくうちに、いったい私は何を調べているのか？私はいったい誰なのか？　というポンコツぶり笑」

「高性能なエディタやLLMが次々と登場して、正直おっさんには目が回るような速い時代です。ちなみに、この３層は、LLMに集めた資料と考え方とかいろいろやり取りしてまとめ上げたものです。実証実験はまだなのですが、考え方としてはかなり的を得ているかもなので、試す価値はあるかと思います。」

さて、そんなことよりも、もっと重要な、全勝でマイアミに上陸できるかどうかの瀬戸際、今夜　WBC　日本×チェコですねぇ～～3月10日(火) 19:00　か、、、またラジオで白熱するか～～～東京プール最終かな。

公式・参考リンク

本記事は、以下の公式ドキュメント・オープン規格を参照して構成しています。各リンクの説明を読み、必要に応じて公式情報をご確認ください。

AGENTS.md 規格・ステュワード

🔗 agents.md
AGENTS.md の公式サイト。README が人間向けであるのに対し、AI コーディングエージェント向けのプロジェクト指示・ビルド手順・規約を書くオープンフォーマットの説明、対応エージェント一覧、使い方（ルートに AGENTS.md を置く・150 行目安など）が掲載されています。
🔗 Agentic AI Foundation (AAIF)
Linux Foundation 傘下の団体。AGENTS.md を中立的にステュワードし、MCP（Model Context Protocol）や goose などとともにオープンな AI エージェント基盤の整備を推進しています。
🔗 OpenAI Codex — Custom instructions with AGENTS.md
OpenAI 公式ガイド。Codex などで AGENTS.md をカスタム指示として使う方法（ファイルの置き方・推奨内容）が説明されています。

ツール別・公式ドキュメント

🔗 Cursor — Rules
プロジェクトルール（.cursor/rules/*.mdc）と AGENTS.md のサポート、globs・alwaysApply などの適用条件が公式に説明されています。
🔗 Claude Code — How Claude remembers your project (CLAUDE.md)
CLAUDE.md の配置場所（プロジェクト・ユーザー・管理ポリシー）と、セッション開始時に読み込まれる永続的指示としての役割が説明されています。
🔗 Windsurf — Getting Started
Codeium による Windsurf の公式入門。Cascade AI とプロジェクトルール（.windsurfrules）の扱いが案内されています。
🔗 GitHub Changelog — Copilot coding agent now supports AGENTS.md
2025年8月、GitHub Copilot のコーディングエージェントが AGENTS.md をカスタム指示として公式サポートした旨の発表。ルートまたはサブディレクトリの AGENTS.md が優先して参照されることが記載されています。
🔗 Google Antigravity — Documentation
Antigravity の公式ドキュメント。AGENTS.md のネイティブ採用や .agent/workflows など、エージェント制御の仕様が説明されています。

LLM 別・公式ドキュメント（記事内「どんな性格？」表の根拠）

🔗 Anthropic — Extended Thinking
Claude が回答前に step-by-step の思考プロセスを出力し、その洞察を反映してから最終回答を返す仕組み。思考トークン・budget の設定が説明されています。
🔗 Anthropic — System prompts
プロンプト設計のベストプラクティス（意図・文脈を厚く書く、XML タグの利用など）が公式にまとめられています。
🔗 OpenAI — Prompt engineering
GPT モデルは「より明示的な指示（explicit instructions）」でタスクを達成しやすくなる旨が公式で説明されています。
🔗 OpenAI — Structured Outputs
指定した JSON スキーマに従った応答をモデルに出力させる機能。指示・形式の厳格な遵守の根拠として参照しています。
🔗 Google — Gemini API
Gemini の LLM としての概要・推論・エージェント機能が公式に案内されています。
🔗 Google — Agentic Vision in Gemini 3 Flash
画像理解を「静的な1回見」から能動的調査に変える機能。zoom・inspect・コード実行で visual evidence に基づく回答を得る仕組みが公式で説明されています。

Core Insights

AGENTS.md大作戦

AIの個性に合わせる

3層でやさしく伝える