AGENTS.mdから始める: 日本のAI開発コミュニティで進むリポジトリ設計パターン 2026

2026年のQiita/Zennを見ていると、AI開発の生産性差は「モデル差」より「リポジトリ設計差」で決まる、という共通認識が強まっています。同じツールでも、構造化されたリポジトリは成果が安定し、未整備なリポジトリは出力がぶれます。

発想の転換

これまでの基準は「人間に読みやすい」でした。いま必要なのは 人間とエージェントの両方が実行可能な文脈 です。

必要になるのは、以下を明示した命令面です。

• 目的と非目的
• アーキテクチャ制約
• 検証フロー
• 危険操作の拒否条件

3層の命令モデル

実務で安定しやすいのは、次の3層構造です。

1. Identity層: 役割・口調・絶対に守る規範
2. Task層: プロジェクト固有の作業手順
3. Safety層: 禁止操作・承認必須条件

重要なのは、散らばったドキュメントにしないことです。正本の場所を定義し、オーナーを持たせます。

AGENTS.mdを「契約」にする

AGENTS.mdは宣言文ではなく契約として設計すると効きます。最低限、次を明文化します。

• 起動時の読み順
• 長期記憶の保存先
• 外部アクションの確認基準
• 実行しない行為（anti-goals）

抽象的な「安全に動く」は運用で機能しません。トリガー条件と行動をセットで書く必要があります。

検証ハーネスの重要性

命令面は放置すると崩れます。最近の実践では、次を機械的に検証する流れが増えています。

• 指定された初期読み込み順を守るか
• 外部副作用前に確認を取るか
• 出力言語制約を維持するか
• 禁止コマンドを回避するか

プロンプト品質の劣化を、コード回帰と同じ扱いにするのがポイントです。

現場で多いアンチパターン

• 1ファイルに全ルールを詰め込み過ぎる
• プライベート情報と共有可能情報の境界がない
• 「安全に」など抽象ルールのみで実行条件がない
• インシデント後にドキュメントへ反映しない

導入手順

Step 1

identity・境界・承認条件の最小契約を作成

Step 2

定常作業（記事生成、デプロイ、監視）をTask層へ分離

Step 3

CIで軽量検証（読み順、禁止操作、言語制約）を実装

Step 4

月次レビューで失敗事例を契約に反映

日本のコミュニティ実践が示しているのは、プロンプトの工夫より構造の工夫が再現性を生むという事実です。AIを本当に戦力化したいなら、まずリポジトリを教科書にするべきです。