コマンドの混乱にさよならを：AGENTS.mdとAIエージェント統一仕様言語ASL

Cursorにしろ、Claude Codeにしろ、AiderやRooCodeのようなツールにしろ、様々なAIプログラミング・ツールが、命令構成に独自のアプローチを持ち込んでいる（例えば .cursor/rules/そしてGEMINI.md (など）を市場に投入している。このような多様性は、さまざまなチームの革新的な思考を反映しているが、同時に指揮系統の生態系に「バベルの塔」を生み出し、大きな分断を招いている。

開発者は、さまざまなAIツールのタスクを効果的にガイドするために、独自のフォーマットによる多数の設定ファイルを学習し、維持しなければならなかった。これらのファイルの中心的な目標は、複雑なプロジェクトのコンテキスト、ドメイン知識、動作制約をAIプログラミングツールに明確に伝えることである。しかし、プロジェクトがツール間で切り替えられると、コミュニケーションの複雑さは劇的に増幅される。あるツール用に作られたコマンドファイルが、別のツールでは完全に失敗する可能性があるのだ。標準化の欠如は、開発効率を低下させるだけでなく、より広範で相互運用可能なAIエージェントのエコシステムの形成を妨げる。

AIプログラミングツールのエージェント構成の比較分析

現在、AIプログラミング・ツールは、コーディング・エージェントの振る舞いを導く3つの主要な方向に沿って独自に進化してきた。機械が読みやすいことを重視する構造化アプローチ、人間が読みやすいことを重視するヒューリスティック、複雑な構成を役割に抽象化する「擬人化」アプローチである。これら3つのアプローチが絶対的に優れているわけではなく、効率的な人間と機械のコラボレーションを実現する上で、各製品が異なる設計上のトレードオフを反映している。

構造化アプローチ：機械可読性の重視

このタイプのエージェントは、コンフィギュレーションにYAML、JSON、TOMLなどの高度に構造化されたフォーマットを使用します。これには、動作パラメータ、モデルの選択、動作の境界を正確に定義し、エージェントの動作に明確な指示を与えるという利点があります。しかし、このアプローチは、コーディングスタイルやアーキテクチャの原則のような微妙な自然言語ガイダンスを伝えるには不十分です。

• 助っ人.aider.conf.yml)YAML ファイルはエージェントの振る舞いを管理するために使用され、開発者がモデルを指定し、Git コミットを設定し、リントコマンドを設定し、テストコマンドを定義することを可能にします。これは、エージェントの振る舞いが正確なパラメータ制御によってプロジェクトの仕様に適合することを保証する、開発者中心の設計哲学を反映しています。
• オープンコードopencode.jsonc)JSONC（コメント付きJSON）フォーマットを使用し、堅牢で安全なコンフィギュレーション・システムを提供します。その opencode.jsonc ファイルは異なるエージェント用に特別にモデリングすることができ、機密情報は変数の置換によって柔軟に管理することができます。きめ細かいパーミッションシステムは特に印象的で、開発者はファイルの編集やシェルコマンドの実行のような重要な操作に対して、明確な承認要件を設定することができます。 "ask" もしかしたら "allow")、エージェントに自律性を与える一方で、最終的なコントロールは開発者に戻す。
• ジェミニCLI (settings.json, .toml)ハイブリッド構造化アプローチを実証settings.json ファイルは、サンドボックス環境、MCP サーバー、およびその他のコア設定を構成するために使用されます。同時に、ユーザーはコア設定を .gemini/commands/ ディレクトリに .toml ファイルを使って、複雑なコマンドを単純なエイリアスにカプセル化したカスタムコマンドを定義することができる。 /plan)、システムレベルのコンフィギュレーションの厳密さとユーザーレベルの命令の柔軟さのバランスをとっている。

ヒューリスティック：人間の読みやすさを優先する

構造化されたアプローチとは対照的に、ヒューリスティックは自然言語（通常はMarkdownファイル）を使用して指示を伝えることを優先します。このアプローチは、人間にとって書きやすく理解しやすいものであり、コーディングスタイルやドメイン知識など、コードで定量化することが難しい定性的なガイドラインをキャプチャするのに特に適している。

• カーソル.cursor/rules, .mdc)そのルールシステムは、ヒューリスティックで確立された実装である。そのルールシステムは .mdc（カーソルはネストされたルールをサポートしており、プロジェクトの異なるサブディレクトリに特定のルールを定義することができます。
• 助っ人CONVENTIONS.md)より軽量な発見的ガイドが提供される。開発者は CONVENTIONS.md コーディング規約が記載された文書（例えば、"Preferred use of httpx").によって /read コマンドは、このファイルをセッションにロードし、エージェントは、その後コードを生成するときに、シンプルで効果的な方法で、これらの規約に従います。
• ゼット.rules)内蔵のAIエージェントは、"arrow "を配置することをサポートします。 .rules ファイルを作成します。このファイルのコンテンツは、プロジェクトレベルの命令としてエージェントとのすべてのインタラクションに含まれ、永続化コンテキストを注入する迅速な方法を提供します。

パーソナリティ・アプローチ：役割ベースのシステム

3つ目のアプローチは、複雑な構成と命令セットをペルソナに抽象化することです。このアプローチでは、システムのプロンプト、使用可能なツール、および権限を役割ベースのプロトタイプに統合することで、ユーザーエクスペリエンスを劇的に簡素化します。AIエージェントが強力である場合、その能力を理解しやすい役割（例えば「アーキテクト」）にカプセル化することで、ユーザーに直感的なメンタルモデルを提供します。

• キロコード／ルーコードこれら2つのVS Codeの拡張機能は、「モード」という概念の実装が非常に豊富で、以下のような機能があらかじめ組み込まれている。 CodeそしてArchitectそしてDebug 歌で応える Orchestrator 様々なモードがある。各モードには特定のシステムプロンプトが含まれるだけでなく、特定のタスクに集中できるよう、さまざまなツールにアクセスできるようになっている。
• 助っ人簡略化されたスキーマ・システムも実装されている。 codeそしてask 歌で応える architect 3つのモデル。code モードでは、エージェントはコードを直接修正する；ask そのモードでのみ議論に参加すること；architect このモデルは2段階のプロセスを採用しており、"アーキテクト "モデルが提言を行い、それを "エディター "モデルがコードに変換する。
• クロード・コードMarkdownファイルで特定の名前、説明、ツールセットを持つエージェントを定義することができるサブエージェント機能は、擬人化アプローチのもう一つの実践です。

既存のメカニズムの限界とセキュリティ・リスク

YAMLのような構造化されたコンフィギュレーションは、機械の実行に必要な精度を提供し、一方、Markdownのような非構造化命令は、人間のコラボレーションに必要な意図を表現するのに適している。現在のツールは、どちらか一方を支持するか、ハイブリッドシステムによって溝を埋めようとする傾向があるが、この2つをエレガントに統合する普遍的なソリューションは存在しない。

Agentの機能が急速に進化する中で、セキュリティの問題は見過ごされがちです。例えば、Amp Codeに深刻なセキュリティ脆弱性が見つかり、攻撃者がAgentの settings.json この脆弱性により、Agent の動作範囲がそれ自身の設定の管理範囲から効果的に分離されていないという、 設計上の重大な欠陥が明らかになります。この脆弱性は、エージェントの操作範囲が、エージェント自身のコンフィギュレーションの管理範囲から効果的に分離されていないという重大な設計上の欠陥を明らかにしています。優れたエージェントの仕様は、その権限の境界を定義するだけでなく、エージェントが自己承認するのを防ぐために、その仕様自体がエージェントにとって読み取り専用であることを保証すべきです。

AGENTS.md 規範の出現

このような問題に対処するため、OpenAIが主導する AGENTS.md この仕様は、シンプルさと予測可能性という設計思想の中核から生まれた。この仕様は、共通の非独占的なフォーマットを定義することで、コードベースが標準化された方法で互換性のあるあらゆるAIプログラミング・ツールとのインターフェイスを可能にすることを目指している。

シンプルで予測可能

Markdownは、人間が読み書きしやすいシンプルな構文でありながら、機械が解析するのに十分な構造を持っている。固定ファイル名 AGENTS.md を作成し、それをプロジェクトのルートディレクトリに置くことで、プロトコルはすべてのエージェントに明確で予測可能なルート制約を提供します。

ベストプラクティス構造

(躊躇なく AGENTS.md 仕様自体は柔軟だが、コミュニティは推奨されるベストプラクティスの構造を策定しており、一般的に以下のセクションを含んでいる：

• プロジェクトの概要とアーキテクチャプロジェクトの目標、中核となる機能、技術スタックを説明し、エージェントが素早くマクロ的な理解を深められるようにします。
• ビルド、テスト、開発コマンドスクリプトの主要コマンドをすべてリストアップします。 pnpm install, pnpm test)を使用して、エージェントが自律的に検証プロセスを実行できるようにします。
• コードのスタイルと規約プロジェクトのコーディング仕様を明確にすることで、エージェントは既存のコードベースのスタイルと一貫性のあるコードを生成することができます。
• テストガイドライン特定のテストを実行し、一般的な障害を修正するための詳細な手順を提供します。
• セキュリティへの配慮プロジェクト関連の安全ガイドラインをリストアップする。
• レイヤードアプリケーション大型のモノレポの複雑さに対応するため。AGENTS.md この仕様は入れ子に対応している。サブディレクトリにはさらに AGENTS.md そのディレクティブは上位ディレクトリの一般的なディレクティブを上書きし、よりきめ細かい指導を可能にします。

AGENTS.md 基本的には宣言的な設定のセットです。YAMLコンフィギュレーションファイルはエージェントに lint-cmd："eslint --fix"これは命令形である。 AGENTS.md そして、このファイルは利用可能なアクションを宣言する：pnpm check:fix「これは、エージェントが推論する際にその文を理解し、より広範な問題を解決するための有用なツールとして使用することを要求するものである。

AGENTS.md 生態系

標準の成功はエコシステムによる採用の度合いに左右され、グーグルのJulesエージェントは、リポジトリルートの AGENTS.md ドキュメント同様に、Cursor IDEは、プロジェクト・ルールの簡略化された代替仕様としてこの仕様をサポートしています。

AGENTS.md MCPはツールの機能と入出力モードを定義する。もし AGENTS.md は、エージェントの意図と知識（「何をすべきか」）を定義する。 エムシーピー そして、その能力とツール（「やり方」）を定義する。この標準化は、重要なアーキテクチャーの分離をもたらす：エージェント知識とエージェント・コア・ロジックの分離.プロジェクト固有の知識は、バージョン管理されたコードに外部化されます。 AGENTS.md ファイルを使用することで、開発者はこの1つのファイルを管理するだけで、互換性のあるAgentに豊富なプロジェクトコンテキストを提供し、「一度書けば、どこでも実行」を可能にします。

汎用エージェント仕様言語（ASL）の概念

コードを超えて：ドメインにとらわれない仕様の構築

AGENTS.md は、AIプログラミング分野における命令の断片化を緩和することを目的としているが、その価値はそれだけにとどまらない。AIエージェントを定義するという中核的な課題（そのアイデンティティ、目標、知識、ツール、境界を明確にすること）は、ドメイン全体に蔓延する問題である。

しかし、Agentがマーケティング、デザイン、プロジェクト管理などの非プログラミング領域でより深く使用されるようになると、これらの領域で複雑なタスクを処理するために必要な命令の構造は、Markdownフォーマットで表現できるものをはるかに超えるようになります。したがって、次の自然な進化は、より正式で、構造化され、拡張可能なバージョンの 汎用エージェント仕様言語（ASL）この言語は、クロスドメインで相互運用可能なAgentエコシステムを構築するための基盤となる。この言語は、クロスドメインで相互運用可能なエージェントエコシステムを構築するための基盤となる。

ASLの基本原則

ASLは次のように設計されている。 AGENTS.md 高い可読性を維持しながら、よく構造化され、モジュール化され、容易に拡張可能な構文システムを提供するというアイデアのスーパーセットです。1つの可能な実装は、YAMLフロントマターで構造化されたMarkdownを使用すること、または最適化されたヒントにコンパイルできるドメイン固有言語（DSL）を設計することです。以下はASLのコアとなる構成要素です：

• ペルソナエージェントのアイデンティティ、コミュニケーションスタイル、中核となる責任を明確にする。
• 目標と目標タスクの明示的な成功基準で、ユーザの暗黙の意図をエージェントの測定可能な明示的な目標に変換します(例えば、エージェントのOKRを定義します)。
• 知識と文脈ファイル、URL、APIへの参照リストなど、エージェントの情報ソースを定義します。
• ツールと機能エージェントが実行できるアクションを宣言し、その能力の境界と接続可能な MCP サーバを指定します。
• ルールと制約機微な操作（例：機密性の高い操作）を微調整するための行動ガードレールを確立する。 send_email: "ask")のセキュリティとコンプライアンスを確保する。

ASLプラクティス：ドメイン固有の実装

ASLの柔軟性を示すために、3つの異なる専門分野向けに設計された仕様の例を以下に示す。

デザインエリア。 brand-guardian.asl

# 角色设定
persona:
identity: 品牌守护者
tone_of_voice: [权威, 精准, 富有创意]
core_function: "确保所有对外发布的素材100%符合公司的品牌规范。"
# 目标
goals:
primary_goal: "在所有线上和线下物料中，保持品牌形象的一致性。"
key_results:
- "将营销活动中的不合规素材减少 95%。"
- "素材审批周期控制在 24 小时以内。"
definition_of_done: "素材正确使用了官方Logo、字体、调色板和图像，即可视为合规。"
# 知识库
knowledge:
sources:
- "@./brand_guidelines_v4.pdf"
- "@./logo_assets_v3/"
initial_instructions: |
1. 对照知识库中的参考资料，分析待审素材。
2. 检查Logo、配色和字体是否合规。
3. 如果合规，则批准。如果不合规，提供具体的修改建议。
# 工具
tools:
enabled_tools: [file_read, image_analysis, color_palette_checker, pdf_parser]
# 规则
rules:
must_not_do:
- "禁止批准任何使用了已弃用颜色代码 #FF00FF 的素材。"
- "禁止提出修改品牌规范的建议。"
permissions:
approve_asset: "allow"
reject_with_feedback: "allow"
suggest_logo_redesign: "ask"

マーケットエリア growth-hacker.asl

# 角色设定
persona:
identity: 增长黑客
tone_of_voice: [数据驱动, 大胆, 简洁]
core_function: "设计、执行并分析一系列快速实验，以驱动用户增长。"
# 目标
goals:
primary_goal: "实现新用户注册量每月5%的环比增长。"
key_results:
- "每月至少发起 4 项新的 A/B 测试。"
definition_of_done: "实验完成结果分析、归档记录，并为后续步骤给出明确建议。"
# 知识库
knowledge:
sources:
- "@https://analytics.example.com/api"
- "@./past_ab_test_results.csv"
initial_instructions: |
1. 基于最新数据提出一项新的增长实验方案。
2. 提出一个清晰的假设（例如：“将CTA按钮颜色改为绿色，点击率将提升10%”）。
3. 定义实验的目标用户和衡量指标。
# 工具
tools:
enabled_tools: [web_search, social_media_poster, ab_test_setup_tool, data_analysis, sql_query_runner]
# 规则
rules:
must_do:
- "在发起任何测试之前，必须先提出一个清晰且可被证伪的假设。"
must_not_do:
- "未经批准，禁止针对现有付费用户开展任何实验。"
permissions:
launch_experiment_under_1000: "allow"
launch_experiment_over_1000: "ask"
post_to_social_media: "ask"

プロジェクト管理分野。 project-owner.asl

# 角色设定
persona:
identity: 项目负责人
tone_of_voice: [有条不紊, 清晰明确, 直接]
core_function: "确保所有软件项目在规定范围内按时上线，并符合‘完成’的标准。"
# 目标
goals:
primary_goal: "在本季度结束前，成功将‘凤凰项目’部署到生产环境。"
key_results:
- "部署前完成发布清单中 98% 的检查项。"
- "发布后 24 小时内，严重级别的 Bug 报告数量为零。"
definition_of_done: "项目成功上线，系统性能稳定，且已发送上线公告。"
# 知识库
knowledge:
sources:
- "@https://jira.example.com/api"
- "@./release_checklist_template.md"
initial_instructions: |
1. 获取最新的发布清单。
2. 通过查询Jira和CI/CD系统，逐一核实清单状态。
3. 若所有事项均已完成，则执行部署。否则，立即中止并通知相关负责人。
# 工具
tools:
enabled_tools: [calendar, ticket_creator, git_tagger, deployment_trigger, slack_notifier]
# 规则
rules:
must_do:
- "在触发部署前，必须确认发布清单上的所有检查项都已完成。"
must_not_do:
- "若有任何自动化测试未通过，禁止执行部署。"
permissions:
trigger_deployment: "ask"
create_jira_ticket: "allow"
tag_git_release: "allow"
send_slack_notification: "allow"
abort_release: "allow"

相互運用可能なエージェント・エコシステムへの道

ASLの実装は、単に優れたプロファイル・フォーマットを作成するだけではない。それは、一般的な「AIワークフォース・オペレーティング・システム」を指している。このモデルでは、組織は以下の方法で独自のAIワークフォース・オペレーティング・システムを構築することができる。 .asl この文書はタスクを定義し割り当て、人間の意図とAIの実行の橋渡しをする。この統一された仕様は、大規模な調整、ガバナンス、自動スケーリングを可能にするフレームワークを提供する。

• エージェント・マーケットプレイス独自のエージェントを開発する代わりに、組織はASLを使って要件を記述するだけで、オープンな市場から最も効率的なサービス・プロバイダーを選択することができます。
• コンポーザブル・エージェント・コラボレーション複雑な部門横断的ワークフローも可能です。例えば project-owner.asl ドリブン・エージェントは、必要に応じてデザイン・レビューのタスクを、次のようなドリブン・エージェントに自動的に委任することができます。 brand-guardian.asl コントロールのためのエージェント。
• 実行可能なナレッジ・マネジメント企業の中核となる知識（ブランド・ガイドラインやセキュリティ・ポリシーなど）は、実行可能なASL文書にエンコードされ、企業内のすべてのAIエージェントの行動を直接ガイドし、制約することで、知識の伝達と適用における一貫性を確保します。

このビジョンの実現は、「エージェント・アーキテクト」や「AIインタラクション・デザイナー」といった新たな役割の創設も予告している。彼らの役割は、人間の専門家とAIのパフォーマーとの橋渡し役として、暗黙のビジネスインテリジェンスを明示的に実行可能なマシンの仕様に変換することである。より AGENTS.md ASLへの進化は、特定の技術的問題を解決することから、すべての知識労働に力を与える共通のコラボレーションフレームワークを構築することへの試みである。ASLが最終形ではないとしても、同様の仕様が出現し、AIエージェントが信頼でき、制御可能で、デジタルチームのコンポーザブルなメンバーとなる新しい時代へと私たちを導くに違いない。