Claude Code の CLAUDE.md や GitHub Copilot の AGENTS.md——最近のAIコーディングツールは、リポジトリにMarkdownファイルを置いてエージェントの振る舞いを定義する方向に収束しつつあります。

でも、ファイルが増えてくると困ることがあります。「このエージェント定義、別のフレームワークでも使いたいんだけど」「プロンプトの変更履歴を追いたい」「本番環境と開発環境でエージェントの設定を分けたい」。こういう要望に対して、既存のアプローチはちょっと力不足なんですよね。

GitAgent （GitHub ）は、この問題に正面から取り組んでいるオープン標準です。「Gitリポジトリそのものをエージェント定義にする」という発想で、バージョン管理・コンプライアンス・フレームワーク間のポータビリティを一気に解決しようとしています。

GitAgentとは

GitAgent は、AI エージェントの定義をGit リポジトリ内のプレーンテキストファイルとして管理するためのオープン標準（MIT ライセンス）です。コンセプトは「Clone a repo, get an agent」——リポジトリをクローンすれば、そのままエージェントが動く世界を目指しています。

自分が特に面白いと思ったのは「フレームワーク非依存」という設計思想です。同じエージェント定義から Claude Code、OpenAI Agents SDK、CrewAI、Lyzr など複数のフレームワーク向けにエクスポートできます。汎用のシステムプロンプトとしても出力可能です。ベンダーロックインを避けたいLLM エージェント開発者にとって、これはかなり魅力的な提案です。

ファイル構成：agent.yaml と Markdownファイル群

GitAgent のエージェント定義は、最小構成だと2ファイルだけで済みます。

必須ファイル

agent.yaml はエージェントのマニフェストです。名前、バージョン、モデル設定、コンプライアンスポリシーなどを宣言的に定義します。

1
2
3
4

spec_version: "0.1.0"
name: my-code-reviewer
version: 0.1.0
description: "コードレビューを行うエージェント"

最小構成はこれだけです。4行で始められます。

もう一つの必須ファイルが SOUL.md。エージェントの人格・コミュニケーションスタイル・行動原則を自然言語で書きます。「SOUL」というネーミングは大袈裟に感じるかもしれませんが、要は「システムプロンプトの構造化されたバージョン」です。

オプションのディレクトリ群

本格的に使う場合は、以下のようなディレクトリを追加できます。

ここで「あれ、これ CLAUDE.md や AGENTS.md でやってることと何が違うの？」と思った方もいるかもしれません。違いは次のセクションで整理します。

CLAUDE.md / AGENTS.md との違い

既存の CLAUDE.md や AGENTS.md は、特定のツール向けの設定ファイルです。Claude Code は CLAUDE.md を読み、GitHub Copilot は AGENTS.md を読む。シンプルで実用的ですが、いくつかの限界があります。

正直なところ、個人開発や小規模チームなら CLAUDE.md で十分なケースも多いです。GitAgent が真価を発揮するのは「複数フレームワークを跨ぐ」「チームでエージェント定義をレビューする」「規制対応が必要」といった場面でしょう。

試してみる：インストールからエクスポートまで

実際に手を動かして確認してみます。

前提条件

• Node.js 18以上
• npm

インストールと初期化

GitAgent の CLI をグローバルインストールします。

1

npm install -g gitagent

新しいエージェントをスキャフォールドします。--template で雛形を選べます。

1

gitagent init --template standard

standard テンプレートを選ぶと、コードレビューエージェントの雛形が生成されます。minimal（最小2ファイル）や full（コンプライアンス対応フル構成）も選択可能です。

バリデーション

定義が仕様に沿っているか確認します。

1

gitagent validate

コンプライアンスチェックを含める場合は --compliance フラグを追加します。

1

gitagent validate --compliance

Claude Code向けにエクスポート

ここが面白いところです。GitAgent で定義したエージェントを Claude Code のフォーマットに変換してみます。

1

gitagent export --format claude-code

これで CLAUDE.md 互換のファイルが生成されます。同様に --format openai で OpenAI Agents SDK 向け、--format crewai で CrewAI 向けの設定が出力されます。

逆に、既存の CLAUDE.md を GitAgent 形式にインポートすることも可能です。

1

gitagent import --from claude ./CLAUDE.md

自分の場合、すでに CLAUDE.md を書き込んでいるリポジトリがいくつかあるので、このインポート機能は地味にありがたいです。

設計パターンで見る GitAgent の使いどころ

GitAgent が提案している設計パターンの中で、特に実用的だと感じたものを紹介します。

ブランチベースのデプロイ

エージェント定義を dev → staging → main のようにブランチで段階的にプロモートできます。ソフトウェアのリリースフローそのままです。「本番のエージェントプロンプトを壊してしまった」という事故を防ぎやすくなります。

職務分離（Segregation of Duties）

agent.yaml 内で roles（maker / checker / executor / auditor）を定義し、conflicting なロールの組み合わせを宣言できます。金融系のコンプライアンス要件（FINRA Rule 3110 など）を満たすための機能ですが、一般のチーム開発でも「レビューなしでデプロイさせない」といった制約に使えそうです。

ライフサイクルフック

hooks/bootstrap.md と hooks/teardown.md で、エージェントの起動時・終了時の振る舞いを制御できます。「起動時に最新のナレッジベースを同期する」「終了時にメモリを整理する」といった処理を定義できます。

気になる点・課題

実際に触ってみて感じた課題もあります。

ポータビリティの限界

「フレームワーク間でエクスポートできる」とはいえ、各フレームワークの機能差は大きいです。CrewAI で使えるスキルが Claude Code にそのまま変換できるわけではない。エクスポート時に一部の機能がサイレントに落ちる可能性があるので、変換後の確認は必須です。

シークレット管理

現時点では .gitignore + .env によるシークレット管理のみです。Gitリポジトリにシークレットを置くリスクは自明で、Vault や AWS SSM などの外部シークレットバックエンドとの統合が今後の課題になるでしょう。本番運用にはまだ注意が必要です。

エージェント発見の問題

エージェントの数が増えてくると、本当のボトルネックは「定義フォーマットの標準化」ではなく「エージェントが適切なツールを見つける仕組み」かもしれません。ランタイムのディスカバリ機構がないと、仕様の標準化だけでは片手落ちになる可能性があります。

まだ v0.1.0

仕様自体がまだ v0.1.0 です。本番に導入するにはちょっと早い段階ですが、方向性としては理にかなっていると思います。

まとめ：「エージェント定義のInfrastructure as Code」

GitAgent の発想は、DevOps の文脈でおなじみのInfrastructure as Code（IaC）のエージェント版と言えます。エージェントの定義をコードと同じように Git で管理し、PR でレビューし、CI で検証し、ブランチでデプロイする。

現時点では CLAUDE.md や AGENTS.md で十分という開発者も多いでしょうし、自分もそう思います。でも、エージェントの数が増え、フレームワークを跨ぐ必要が出てきたとき、こういう標準があると助かる場面は確実に増えてくるはずです。

個人的には、既存の CLAUDE.md からのインポート機能があるので、まずは試しに変換してみて、GitAgent の構造化がどの程度自分のワークフローに合うか確かめてみるのが良いスタートだと思います。

参考リンク

• GitAgent 公式サイト
• GitAgent GitHub リポジトリ
• Hacker News ディスカッション
• Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則 — 当ブログ
• MCPは死んだ、CLIは永遠？ AIエージェントのツール接続設計を数値で比較する — 当ブログ