【2026年6月版】Context Engineering 完全入門(第8回・完結) － SKILL.mdとAGENTS.mdによる宣言的ガバナンスの設計

Last updated at 2026-07-18Posted at 2026-07-18

はじめに

本記事は「Context Engineering 完全入門」シリーズの第 8 回(最終回)です。今回は Skills & AGENTS.md を取り上げます。

第 2〜7 回ではランタイム制御や自己状態管理といった「動的な仕組み」を解説してきました。本記事では「宣言的拡張」として、マークダウンファイルを使って静的に能力・指示を定義する仕組みについてご紹介します。また、複数ベンダーのツールから設計パターンを抽出・統合するためのベンダー中立設計戦略についても解説します。

前回：第 7 回 TODO ツール
次回：補章 A VS Code Copilot Chat 1.109 機能調査

🗺️ 本編最終回:第 2〜7 回の知見を「宣言的ガバナンス」として統合します。本記事から読み始めても、シリーズ全体の到達点を把握できます。

📝 本記事は、生成 AI で作成した草案をベースに、筆者が加筆・修正し、技術的な正確性を確認した上で公開しています。

📝 本記事の要点

問題: ランタイム制御だけでは「チーム共有・Git 管理・複数ツール横断」の要件をカバーできない

解決: SKILL.md(能力定義)+ AGENTS.md(プロジェクト指示)+ ベンダー中立な抽象化レイヤ で宣言的ガバナンスを実現

実装の要点: Microsoft Agent Framework (MAF) の AgentSkillsProviderBuilder で SKILL.md を自動検出、AGENTS.md は独自 AIContextProvider で距離ベースの優先順位(proximity-based precedence)で解決

急ぐ方は §2 SKILL.md vs AGENTS.md 比較表 と §6 ベンダー中立設計戦略の 3 レベル が組織判断の指針になります。

🎯 本記事の対象者

AGENTS.md と SKILL.md の使い分けが分からない
Skills を MAF で実装したい
ベンダー中立設計戦略を組織能力にしたい
ベンダーロックインを避けたい
マルチテナントな業務 SaaS で context を分離したい
Few-shot Examples の正しい設計を学びたい

1. ⭐ 原則

Skills & AGENTS.md 設計の方針を整理すると以下の通りです。#1・#2 は本節、#3 は §2 で詳しく解説します。

#	原則	概要	参照項目
1	能力と指示を分離する	SKILL.md = 再利用可能な能力、AGENTS.md = プロジェクト固有指示	§1
2	Progressive Disclosure を徹底する	必要な情報のみを段階的にロードし、コンテキストの肥大化を防ぐ	§1
3	ベンダーに依存しない抽象化レイヤを持つ	複数ツール横断で使える宣言的ガバナンスを構築する	§2

シリーズ全体との関係:第 2〜7 回の集大成

本記事は、第 2〜7 回で扱った動的な仕組みを 宣言的な形で外部化する ためのパターンを扱います。

ランタイム制御(第 2〜5 回):ツール設計、結果ハンドリング、履歴圧縮、サブエージェント → C# / Python コードで動的に制御
自己状態管理(第 6〜7 回):Memory、TODO → エージェント自身がセッションを跨いで状態を持つ
宣言的ガバナンス(本記事):Skills、AGENTS.md → Markdown ファイルで静的に宣言、共有・管理

これらは競合ではなく 補完関係 にあり、業務系エージェントの本番運用では 3 つを組み合わせて活用します。

なぜ「宣言的拡張」が必要か

ランタイム制御だけでは以下の要件には不向きです:

✅ チーム全員で共有したい プロジェクト規約
✅ 複数プロジェクト間で再利用したい 専門能力
✅ 複数 AI ツール(Claude Code、Cursor、Codex、Copilot)で 横断的に 使いたい指示
✅ Gitなどでバージョン管理 したい設定

3 軸評価:宣言的ガバナンスの設計軸

Skills & AGENTS.md を 共有性 × 動的性 × 統制性の 3 軸 で評価すると、それぞれの用途が明確になります。

共有性:個人 / チーム / 組織横断で共有できるか
動的性:実行時にロード / 静的に宣言のみ
統制性:規約強制 / 提案ベース(ユーザーレビュー必須)

宣言方式	共有性	動的性	統制性	主な用途
SKILL.md	組織横断 ◎	動的ロード(Progressive Disclosure)	規約強制 ○	再利用可能な専門能力
AGENTS.md	プロジェクトチーム ○	静的宣言(セッション開始時に全読)	規約強制 ◎	プロジェクト固有指示
Session Memory(第 6 回)	個人 ×	動的更新	完全自動 ×	タスク固有の一時情報
サブエージェントカタログ(第 5 回)	組織横断 ◎	動的生成 + `immutable_constraints`	統制性 ◎	業務要件別のエージェント定義

この 3 軸で見ると、Skills と AGENTS.md は Session Memory と対極 にあり、組織横断で共有・統制される宣言的な仕組み として位置付けられます。

7 つのベストプラクティス

原則 1〜3 を実装する際の具体的なベストプラクティスは以下の通りです。

#	ベストプラクティス	概要
1	SKILL.md = 能力、AGENTS.md = 指示の役割分担	責務分離で保守性向上
2	Progressive Disclosure(必要な情報のみ段階的にロード)	トークン浪費を防ぐ
3	AGENTS.md の距離ベースの優先順位(proximity-based precedence、編集対象に近いものが優先)	モノレポでのサービス別ルール定義
4	ベンダー中立な抽象化レイヤを持つ(ベンダー中立設計戦略)	5 年後の技術的負債を防ぐ
5	Don't Get Few-Shotted:Few-shot の多様性を確保	判断力の維持
6	Output Contract:構造化出力による context 安定化	LLM 出力の予測可能性
7	Multi-tenant Context Isolation:業務 SaaS の必須要件	データ漏洩防止

2. 📐 パターン

本節では、Skills & AGENTS.md を設計するための実装ベースのパターンを扱います。まず §2-1 で SKILL.md と AGENTS.md の仕様(本記事の実装参考元)を確認し、§2-2 で Microsoft Agent Framework (MAF) での実装パターン、§2-3 で業務系システムへの適用時の制約を整理します。

2-1. SKILL.md と AGENTS.md の仕様(実装参考元)

本記事の MAF 実装(§4)は、Anthropic Claude Code の SKILL.md 仕様と、OpenAI Codex CLI 発祥の AGENTS.md 標準を参考にしています。ここでは、それぞれの仕様を確認します。

二大標準:SKILL.md と AGENTS.md

観点	SKILL.md	AGENTS.md
起源	Anthropic Claude	OpenAI Codex CLI
標準化	Anthropic spec、MAF 採用	Linux Foundation 配下
採用ツール	Claude Code、MAF、Codex 等	30+ ツール(Cursor、Aider 等)
形式	YAML frontmatter + Markdown 必須	Plain Markdown
範囲	単一の能力(タスク)	プロジェクト全体の指示
想定読み込み	必要時のみ(Progressive Disclosure)	セッション開始時に全読

Progressive Disclosure(段階的開示)

AGENTS.md の距離ベースの優先順位(proximity-based precedence)

編集対象ファイルに近い AGENTS.md が優先されます。モノレポでサービスごとに異なるルールを定義できます。

2-2. Microsoft Agent Framework (MAF) での実装パターン

MAF は SKILL.md を 公式 GA 機能 として提供しており、AGENTS.m` は独自実装で対応します。

4 つの主要実装パターン

パターン	概要	MAF での実装
File-based Skills	ディレクトリから SKILL.md を自動検出	`AgentSkillsProviderBuilder.AddFromDirectory`
Multi-tenant Skills	テナント別ディレクトリで Skills を分離	独自 `AIContextProvider` + キャッシュ
AGENTS.md ContextProvider	距離ベースの優先順位で読み込み	独自 `AIContextProvider`(§4-4)
Output Contract	JSON Schema で構造化出力を強制	`ChatResponseFormat.ForJsonSchema`

Don't Get Few-Shotted(業界研究で 2025/7 提唱)

業界研究では、Few-shot 例の設計に関する重要な原則が提唱されています:

"(訳) エージェントに類似リファクタリングの例を 5 つ示すと、6 件目のケースにも同じパターンを適用しようとする傾向があります。たとえ 6 件目のケースには別のアプローチが必要な場合であってもです。"

対策:多様性の確保

2-3. 業務系システムへの適用時の制約

Anthropic Claude Code や OpenAI Codex CLI の SKILL.md / AGENTS.md 実装は個人利用のコーディング支援を前提としているため、業務系システム(特にマルチテナント SaaS)では以下の制約を考慮する必要があります。

Claude Code / Codex CLI の前提	業務系システムでの制約
単一ユーザー(個人ローカル環境)を前提	マルチテナント SaaS ではテナントごとに別 Skill セットが必要
SKILL.md / AGENTS.md はローカルファイル	クラウド環境では DB / Blob Storage への保存が一般的
全 Skills を無条件にロード	テナント間でのカスタマイズやアクセス制御が必要
セッション終了後もファイルは残る	GDPR / 個人情報保護法対応で TTL や削除ポリシーが必要

マルチテナント Context Isolation

業務系 SaaS では、顧客テナントごとにコンテキストを分離する設計が必須です:

業務系で SKILL.md / AGENTS.md を本番運用する場合、第 6 回のメモリー機能・第 7 回の TODO ツールと同じく 「動的性(Skills の柔軟なロード)」を維持しつつ「統制性(テナント分離・アクセス制御)」を担保する ことが重要です。具体的な永続化戦略の詳細は補章 C「業界研究の業務系翻訳ガイド」で扱います。

3. 💡 実装の方針と設計判断

サンプルコードの実装方針は以下の通りです。

設計判断 1:Microsoft Agent Framework (MAF) の `AgentSkillsProvider` を直接使う

MAF は Skills を 公式 GA 機能 として提供しています。ディレクトリパスを渡すだけで配下の SKILL.md を自動検出し、Progressive Disclosure の Stage 1(Advertise)が自動的に行われます。自前実装より公式に乗る方が将来の機能追加を享受できます。

設計判断 2:AGENTS.md は独自の `AIContextProvider` で実装

MAF には AGENTS.md のネイティブサポートがないため、独自実装が必要です。距離ベースの優先順位は MAF 標準にないため、独自の AIContextProvider として実装します。

設計判断 3:Multi-tenant Skills Provider を「解決・キャッシュするリゾルバ」として実装

AIContextProvider の呼び出しエントリポイント(ProvideAIContextAsync 等)は protected のため、別インスタンスの provider に処理を委譲する設計は実装できません。そのためテナント別に AgentSkillsProvider を解決・キャッシュするリゾルバとして実装し、エージェント構築時に AIContextProviders へ直接組み込みます。毎回ロードはコストが高いため、キャッシュで「初回のみロード、以降は再利用」することでパフォーマンスとのバランスを取ります。

設計判断 4:Output Contract で構造化出力を強制

JSON Schema を ChatOptions.ResponseFormat に設定することで、LLM 出力を予測可能な構造に固定します。これにより後段の処理(パース、バリデーション、DB 保存)が安定します。

4. 💻 実装：C# / Microsoft Agent Framework (MAF)

以下のサンプルコードは、SKILL.md と AGENTS.md の 概念を理解するための実装例 です。本番の業務系システムでは、ローカルファイルではなく Cosmos DB / Blob Storage などの永続化バックエンド + テナント認証・認可の仕組みを利用することが推奨されます。業務系での永続化戦略の詳細は補章 C で扱う予定です。

4-1. File-based Skills

💻 FileBasedSkillsExample — SKILL.mdを自動検出するエージェントのサンプル実装（C#・約25行、クリックで展開）

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

namespace ContextEngineering.Skills;

public static class FileBasedSkillsExample
{
    public static AIAgent BuildAgent(IChatClient chatClient, string skillsDirectory)
    {
        // 🔑 MAF 公式: ディレクトリを渡すだけで配下の SKILL.md を自動検出する
        var skillsProvider = new AgentSkillsProvider(skillsDirectory);

        return chatClient.AsAIAgent(new ChatClientAgentOptions
        {
            ChatOptions = new ChatOptions { Instructions = "Company information expert." },
            // 🔑 ContextProvider として Skills を組み込む
            // → Progressive Disclosure Stage 1(name + description の常時提示)が自動で動く
            AIContextProviders = [skillsProvider],
        });
    }
}

⚠️ 注意:Tool Approval(承認フロー)への対応が必須: AgentSkillsProvider は load_skill / read_skill_resource / run_skill_script を自動的にツールとして公開しますが、これらは MAF の Tool Approval(human-in-the-loop)機構により 承認待ちになることがあります。呼び出し側で承認要求(ToolApprovalRequestContent)を処理しないと、agent.RunAsync() の応答テキストが空文字のまま返り続けます。読み取り専用の load_skill / read_skill_resource は agent.AsBuilder().UseToolApproval(new ToolApprovalAgentOptions { AutoApprovalRules = [AgentSkillsProvider.ReadOnlyToolsAutoApprovalRule] }).Build() で自動承認し、コード実行を伴う run_skill_script のみ明示承認を求めるのが安全です。詳細は Tool Approval を参照してください。

4-2. SKILL.md フォーマット

💻 Expense Report Skill — SKILL.mdのサンプル定義（YAML・約25行、クリックで展開）

---
name: expense-report           # 必須 (max 64 char)
description: |                 # 必須 (max 1024 char, 起動判断に使用)
  File and validate employee expense reports according to company policy.
  Use when asked about expense submissions, reimbursement rules, or spending limits.
license: Apache-2.0
metadata:
  author: contoso-finance
  version: "2.1"
---

# Expense Report Workflow

When asked about expense reports:
1. Collect receipt information
2. Validate against policy limits
3. Submit to approval queue

## Output format
...

description は Stage 1 で常時 context に載る部分 なので、「いつ使うか」を明示することが重要です。

4-3. Multi-tenant Skills Provider

実装の要点:

AIContextProvider の呼び出しエントリポイントは protected のため、別インスタンスの provider に処理を委譲する設計は実装できない
そのため、テナント別に AgentSkillsProvider を解決・キャッシュするリゾルバとして実装し、エージェント構築時に AIContextProviders へ直接組み込む
Skills ディレクトリの解決は ISkillsSource 経由に抽象化(テナントごとに異なる Skill セットを持つため)

💻 ISkillsSource — テナント別Skillsディレクトリ解決のサンプル実装（C#・約5行、クリックで展開）

ディレクトリ解決の抽象化(インターフェース定義):

// 🔑 サンプルではテナントIDからローカルディレクトリを解決、本番ではDB/Blob Storage等に置換可能
public interface ISkillsSource
{
    string ResolveSkillsDirectory(string tenantId);
}

💻 MultiTenantSkillsProvider — テナント別Skills解決・キャッシュのサンプル実装（C#・約30行、クリックで展開）

using System.Collections.Concurrent;
using Microsoft.Agents.AI;

/// <summary>
/// テナントごとに別の Skills セットを持つプロバイダ解決・キャッシュ。
/// 業務 SaaS 必須の機能。
/// </summary>
public class MultiTenantSkillsProvider
{
    private readonly ISkillsSource _source;

    // 🔑 テナント別キャッシュ:初回ロード以降は再利用
    private readonly ConcurrentDictionary<string, AgentSkillsProvider> _tenantCache = new();

    public MultiTenantSkillsProvider(ISkillsSource source) => _source = source;

    /// <summary>指定テナントの <see cref="AgentSkillsProvider"/> を取得(なければ初回ロードしてキャッシュ)する。</summary>
    public AgentSkillsProvider GetOrCreate(string tenantId)
    {
        return _tenantCache.GetOrAdd(tenantId, id =>
        {
            // 🔑 初回:テナント別ディレクトリから Skills をロード
            var tenantDir = _source.ResolveSkillsDirectory(id);
            return new AgentSkillsProvider(tenantDir);
        });
    }
}

設計判断の核心:テナント分離を実装レベルで強制

テナント別ディレクトリからのロードにより、物理的にテナント間の Skills が混ざらない ことを実装レベルで保証します。取得した AgentSkillsProvider はエージェント構築時に直接 AIContextProviders へ組み込みます:

💻 テナント別Skills Providerをエージェントへ組み込む構成例（C#・約10行、クリックで展開）

// テナント別ディレクトリから Skills をロード(物理的に分離)
var tenantDir = _source.ResolveSkillsDirectory(tenantId);
var provider = new AgentSkillsProvider(tenantDir);

// エージェント構築時に AIContextProviders へ直接組み込む
var agent = chatClient.AsAIAgent(new ChatClientAgentOptions
{
    AIContextProviders = [provider],
});

4-4. AGENTS.md ContextProvider(独自実装)

実装の要点:

workspace 配下の全 AGENTS.md を IAgentsMarkdownSource 経由で検出
編集対象ファイルからのパス距離で並び替え
「距離が遠い → 後ろ」に置くことで、近いものを末尾 attention 領域へ
maxTotalChars でトークン爆発を防止
AGENTS.md が 1 件も無い場合はヘッダも書かず空の AIContext を返す(無駄な system message を注入しない)

💻 IAgentsMarkdownSource — AGENTS.md検出処理のサンプル実装（C#・約8行、クリックで展開）

検出処理の抽象化(インターフェース定義):

// 🔑 サンプルではファイルシステム走査実装、本番ではDB/Blob Storage等に置換可能
public interface IAgentsMarkdownSource
{
    // パスは workspace ルートからの相対パス('/' 区切り)
    Task<IReadOnlyList<(string RelativePath, string Content)>> FindAllAsync(
        CancellationToken cancellationToken = default);
}

💻 AgentsMarkdownContextProvider — 距離ベース優先順位によるAGENTS.md注入のサンプル実装（C#・約90行、クリックで展開）

/// <summary>
/// AGENTS.md を proximity-based precedence で読み込む。
/// </summary>
public class AgentsMarkdownContextProvider : AIContextProvider
{
    private readonly IAgentsMarkdownSource _source;
    private readonly string? _currentFile;
    private readonly int _maxTotalChars;
    // 🔑 ロード結果をキャッシュ(同一セッション内で再利用)
    private string? _loadedContent;

    public AgentsMarkdownContextProvider(
        IAgentsMarkdownSource source,
        string? currentFile = null,
        int maxTotalChars = 50_000)
        : base(null, null)
    {
        _source = source;
        _currentFile = currentFile?.Replace(Path.DirectorySeparatorChar, '/');
        _maxTotalChars = maxTotalChars;
    }

    private static int Distance(string path, string[] currentParts)
    {
        var pathParts = path.Split('/');
        var commonLen = 0;
        // 🔑 共通パス部分の長さを計算
        for (var i = 0; i < Math.Min(pathParts.Length, currentParts.Length); i++)
        {
            if (pathParts[i] == currentParts[i]) commonLen++;
            else break;
        }
        // 🔑 「距離」は「currentFile から見た深さ - 共通部分」
        return currentParts.Length - commonLen;
    }

    private async Task<IReadOnlyList<(string RelativePath, string Content)>> FindOrderedAsync(
        CancellationToken cancellationToken)
    {
        var files = await _source.FindAllAsync(cancellationToken);

        if (_currentFile == null)
            // 🔑 currentFile が無ければルートに近い順
            return files.OrderBy(f => f.RelativePath.Count(c => c == '/')).ToList();

        var currentParts = _currentFile.Split('/');

        // 🔑 OrderByDescending で「距離が遠い方が先」
        // → 距離が近いものを「後ろ」に置くことで、LLM の attention が末尾に集中する効果を活用
        return files.OrderByDescending(f => Distance(f.RelativePath, currentParts)).ToList();
    }

    protected override async ValueTask<AIContext> ProvideAIContextAsync(
        InvokingContext context, CancellationToken cancellationToken = default)
    {
        // 🔑 キャッシュがあれば再利用
        if (_loadedContent == null)
        {
            var files = await FindOrderedAsync(cancellationToken);

            // 🔑 バグ修正: AGENTS.md が 1 件も無い場合にヘッダ行だけ書き込むと、
            // 無駄な system message が注入されてしまう。1 件も無ければ空文字を返す。
            if (files.Count == 0)
            {
                _loadedContent = "";
            }
            else
            {
                var sb = new System.Text.StringBuilder();
                sb.AppendLine("# AGENTS.md Instructions");

                var totalChars = 0;
                foreach (var (relPath, content) in files)
                {
                    var section = $"\n## From `{relPath}`\n\n{content}\n";

                    // 🔑 maxTotalChars を超えたら停止
                    // → トークン爆発を防ぐ
                    if (totalChars + section.Length > _maxTotalChars) break;
                    sb.Append(section);
                    totalChars += section.Length;
                }

                _loadedContent = sb.ToString();
            }
        }

        if (string.IsNullOrEmpty(_loadedContent))
            return new AIContext();

        return new AIContext
        {
            Messages = [new ChatMessage(ChatRole.System, _loadedContent)],
        };
    }
}

設計判断の核心:末尾 attention 領域の活用

「距離が近い AGENTS.md」を 末尾に配置 することで、LLM の attention が最後の内容に集中する性質を活用します:

💻 AGENTS.mdを距離が遠い順に並べる優先順位ロジック（C#・約5行、クリックで展開）

// OrderByDescending で「距離が遠い方が先」
// → 距離が近いものを「後ろ」に置くことで、LLM の attention が末尾に集中
return files.OrderByDescending(f => Distance(f.RelativePath, currentParts)).ToList();

4-5. Output Contract の実装

💻 StructuredOutputAgentBuilder — JSON Schemaで出力構造を固定するサンプル実装（C#・約30行、クリックで展開）

public record StructuredResponse<T>
{
    public required T Result { get; init; }
    public required string Reasoning { get; init; }
    public List<string> Warnings { get; init; } = new();
}

public class StructuredOutputAgentBuilder
{
    /// <summary>
    /// JSON Schema を ChatOptions に設定して、LLM 出力を構造化する。
    /// </summary>
    public static AIAgent BuildWithSchema<T>(IChatClient chatClient, string instructions)
    {
        return chatClient.AsAIAgent(new ChatClientAgentOptions
        {
            ChatOptions = new()
            {
                Instructions = instructions,
                // 🔑 ResponseFormat で JSON Schema を強制
                // → LLM は schema に従った JSON のみ返す
                ResponseFormat = ChatResponseFormat.ForJsonSchema<StructuredResponse<T>>(
                    schemaName: typeof(T).Name,
                    schemaDescription: $"Structured response with {typeof(T).Name} result"
                ),
            },
        });
    }
}

4-6. Diverse Few-shot Selector

💻 DiverseFewShotSelector — パターン多様性を確保するFew-shot選択のサンプル実装（C#・約30行、クリックで展開）

/// <summary>
/// Few-shot 例をパターン別に分類し、多様性を確保して選ぶ。
/// Don't Get Few-Shotted 対策。
/// </summary>
public class DiverseFewShotSelector
{
    private readonly List<(string Pattern, string Example)> _examples;
    private readonly Random _random = new();

    public DiverseFewShotSelector(IEnumerable<(string Pattern, string Example)> examples)
    {
        _examples = examples.ToList();
    }

    public List<string> SelectDiverse(int count)
    {
        return _examples
            // 🔑 パターン別にグルーピング
            .GroupBy(e => e.Pattern)
            // 🔑 各グループからランダムに 1 件
            .Select(g => g.OrderBy(_ => _random.Next()).First().Example)
            // 🔑 全体もシャッフル(順序の固定化を避ける)
            .OrderBy(_ => _random.Next())
            .Take(count)
            .ToList();
    }
}

5. 📊 ケーススタディ

主要ツールの Skills / AGENTS.md 対応状況

主要ツールの Skills / AGENTS.md 対応状況を、§1 で定義した 共有性・動的性・統制性の 3 軸 で比較すると、ツールごとの明確な差が現れます。

Skills 対応状況

ツール	SKILL.md	共有性	動的性	統制性	業務系適性
Claude Code(発祥)	◎	組織横断 ○	Progressive Disclosure	規約強制 ○	○
Microsoft Agent Framework(GA)	◎	組織横断 ◎	Progressive Disclosure	規約強制 + テナント分離可	◎
Codex CLI	△	個人 △	限定的	弱い	△

AGENTS.md 対応状況

ツール	AGENTS.md	共有性	動的性	統制性	業務系適性
Codex CLI(発祥)	◎	プロジェクトチーム ○	自動読込	規約強制 ◎	○
VS Code Copilot Chat	○	プロジェクトチーム ○	自動読込	規約強制 ◎	○
Cursor	◎	プロジェクトチーム ○	距離ベース優先	規約強制 ◎	○
Claude Code	○	プロジェクトチーム ○	自動読込(CLAUDE.md と併用可)	規約強制 ◎	○
MAF	×	—	—	—	独自実装で対応可能(§4-4)

教訓:

Claude Code は SKILL.md の発祥 であり、Progressive Disclosure による段階的ロードの設計思想を確立しました。個人利用のコーディング支援では業界最先端です
Microsoft Agent Framework は GA レベル で SKILL.md をサポートしており、AgentSkillsProvider によりテナント分離やアクセス制御を組み込みやすい設計です。業務系エージェントには最適
Codex CLI は AGENTS.md の発祥 で、Linux Foundation 配下の標準として 30 以上のツールに広がっています。ただし SKILL.md の対応は限定的です
VS Code Copilot Chat・Cursor・Claude Code はいずれも AGENTS.md 相当の仕組みを持っていますが、業務系では 距離ベースの優先順位 で編集対象に近いルールを優先する設計が重要です
MAF は AGENTS.md のネイティブサポートを持たない ため、業務系での本番運用には独自の AIContextProvider 実装(§4-4)が必要です

つまり、「Skills は組織横断で再利用可能な能力、AGENTS.md はプロジェクトチーム内でのルール共有」 という役割分担が明確です。業務系エージェントでは、MAF + 独自 AGENTS.md 実装 + マルチテナント Skills Provider の 3 点セットが長期運用の鍵となります。

宣言的ガバナンスの適用判断

宣言的ガバナンス(Skills / AGENTS.md)を いつ使うべきか の判断は、要件の性質に応じて決定します。

Skills を使うべき場面:

複数プロジェクトで再利用したい専門能力
チーム全員で共有したい業務ドメイン知識
Progressive Disclosure でトークンを節約したい

AGENTS.md を使うべき場面:

プロジェクト固有のコーディング規約
モノレポでサービスごとに異なるルール
チーム全員が Git でバージョン管理したい指示

使うべきでない場面(ランタイム制御を使うべき):

実行時にしか決まらない動的な情報
一時的な作業メモ(Session Memory を使う)
高頻度に更新される進捗管理(TODO を使う)

教訓:

宣言的ガバナンスは 静的宣言だからこそ Git 管理・チーム共有ができる 一方、動的な情報には向きません。第 6 回のメモリー機能・第 7 回の TODO ツールと組み合わせて、静的な知識(Skills / AGENTS.md)と動的な状態(Memory / TODO)を役割分担 することが、業務系エージェント設計の核心です。

6. ベンダー非依存な設計

業務系でAIエージェントを構築する場合、複数ツールの設計パターンを抽出・参考にしたベンダー非依存な設計 が有効です。特定ベンダーに依存せず、各ツールの優れた設計パターンを自社の抽象化レイヤに取り込むことで、長期的な技術的負債とベンダーロックインを回避できます。

ベンダー中立設計戦略の 3 つのレベル

レベル	内容	評価
1: ツール併用	用途別にツールを使い分け	個人生産性は上がるが組織能力にならない
2: パターン抽出	設計パターンを MAF に取り込む	本書のサンプルコード
3: 戦略的選別	ベンダーロックインを意図的に避ける	業務系で最も価値が高い

レベル 3 の設計原則

原則 1:抽象化レイヤを必ず持つ

顧客アプリケーション
    ↑
自社オーケストレーション層(MAF + 独自)
    ↑
LLM 抽象化(IChatClient、ベンダー中立)
    ↑
複数バックエンド(OpenAI / Azure / Anthropic / Bedrock)

原則 2:MCP を中核に据える

MCP(Model Context Protocol)を使えば、同じツール定義を Claude Code、Copilot、Codex、自社エージェントで使えます。ただし MCP プロトコル自体に context size hint がない点(第 3 回で扱った問題)には注意が必要です。

原則 3:宣言的ガバナンスを徹底

対象	宣言ファイル
エージェントの能力	SKILL.md
プロジェクト規約	AGENTS.md
サブエージェントの定義	サブエージェントカタログ YAML(第 5 回)

段階的実装ロードマップ

下記はあくまで参考ですが、もし現状ベンダーロックインしている場合は、中長期的に移行することを検討下さい。

Phase	期間	内容
Phase 1(短期)	3〜6 ヶ月	標準フレームワークを選定(MAFなど)、第 3 回と第 7 回を実装
Phase 2(中期)	6〜12 ヶ月	MCP 対応、AGENTS.md / SKILL.md / カタログを Gitなどで管理
Phase 3(長期)	12 ヶ月〜	抽象化レイヤで複数 LLM バックエンドに対応

7. ⚠️ アンチパターン

本記事で扱った Skills & AGENTS.md 設計の要点を、実装時のセルフレビュー用チェックリスト(アンチパターン)としてまとめました。
実装時は本表を「やってはいけないことリスト」としてご参照ください。特に #5・#6・#7 はベンダーロックイン、判断力低下、データ漏洩リスクに直結する重要項目です。

#	アンチパターン	問題点
1	AGENTS.md に Skill 的な情報を詰め込む	セッション開始時に毎回読まれてトークン消費が増える
2	SKILL.md の description が短すぎる	LLM が「使うべきか」を判断できない
3	両方に同じ情報を書く	メンテナンスが 2 倍になり矛盾が発生する
4	SKILL.md を 500 行以上にする	Progressive Disclosure の利点が損なわれる
5	単一ベンダーに完全依存	5 年後に確実に技術的負債になる
6	Few-shot を同質的に並べる	Don't Get Few-Shotted の問題が発生する
7	マルチテナント設計をしない	データ漏洩・カスタマイズ不可の二重リスク

8. 🎉 シリーズ全 8 回の総まとめ

本シリーズは、AI エージェントの本番運用に必要な Context Engineering を、7 つの設計観点として体系化しました。全 8 記事は「設計の前提(第 1 回)」を起点に、「ランタイム制御(第 2〜5 回)」でセッション内での動的な仕組みを、「自己状態管理(第 6〜7 回)」でセッションを跨いだエージェント自身の状態管理を、そして本記事「宣言的ガバナンス(第 8 回)」で組織横断の静的な宣言的仕組みを扱ってきました。

以下の図は、シリーズ全体の構造と、各パートの位置付けを示しています。

各記事における整理観点

第 5 回以降の記事では、「動的性(柔軟性)と統制性のトレードオフをどう解消するか」という業務系エージェント設計のテーマに重きを置いて記載してきました。業務系エージェントの本番運用では、このバランス設計が重要となります。
以下の表は、各記事においてどのような観点で要件を整理したのかをまとめたもので、単一の指標では業務系エージェントの複雑な要件を捉えきれないため、「動的性」「統制性」「保守性(または共有性・永続性など)」の主に3軸で多角的に評価する ことで、業務系での適性を判断できるようにしています。

記事	整理観点	3 軸で見ることの意義
第 5 回(サブエージェント)	動的性 × 統制性 × 保守性	動的化しつつプロンプトインジェクション対策と長期運用の両立を評価
第 6 回(Memory)	共有性 × 永続性 × 分離性	User / Repository / Session の 3 スコープの使い分けを明確化
第 7 回(TODO)	持続性 × 更新粒度 × 並行制御	セッション跨ぎ・単一タスク更新・同時 in_progress 制限を評価
第 8 回(Skills & AGENTS.md、本記事)	共有性 × 動的性 × 統制性	組織横断で共有しつつテナント分離とアクセス制御を担保

いずれの整理観点も、「柔軟性を追求するが、統制も担保する」 という共通の設計方針で整理しています。業務系エージェントの本番運用では、単一指標ではなく多角的な評価により、動的性と統制性のバランスを取ることが設計の指針となります。

おわりに

本シリーズ全 8 回を通じて、AI エージェントの本番運用に必要な Context Engineering を 7 つの設計観点で体系的に解説してきました。

各設計観点はどれも欠かすことができません。また、業界研究(Manus、Anthropic、LangChain 等)のベストプラクティスを「業務系の制約に翻訳」して適用することが重要です。特定ベンダーのツールに縛られず、ベンダー中立設計戦略で複数ツールから設計パターンを抽出・統合するのが本番運用での正解です。

続く補章 A・B・C では、VS Code 1.109 の最新機能解析、Claude Code V2 移行の教訓、業界研究の業務系翻訳ガイドをご紹介します。引き続きお読みいただければ幸いです。

参考文献

Skills & AGENTS.md 公式

Microsoft Learn「Microsoft Agent Framework — Agent Skills」
microsoft/agent-framework python/samples/02-agents/skills/
microsoft/agent-framework dotnet/samples/02-agents/AgentSkills/
AGENTS.md 公式サイト
Anthropic Engineering「Equipping agents for the real world with Agent Skills」(2025/10/16)
- 補足: Claude Agent SDK での実装は Claude Code Docs「Agent SDK overview」も参照。