agent定義をどこに置くか

2026年3月13日の Show HN で紹介された GitAgent は、AI agentをフレームワーク固有の設定やホスト型サービス内部の状態ではなく、通常のgitリポジトリ内ファイルとして表現しようとする提案だ。中心になるのは agent.yaml、SOUL.md、SKILL.md で、必要に応じて memory、tools、knowledge、hooks、compliance 用の構造を足せる。クロール時点でこのHacker News投稿は114ポイント、24コメントだった。

発想は明快で、agentが単なるrepoなら、version control、branch、pull request、review history、rollbackが最初から使えるというものだ。GitAgentのサイトもこの運用面を前面に出している。branch-based deployment、monorepoでのshared context、さらに「stateless compute, git as state」として、実行中イベントを外部SaaSではなくrepo historyへ残す考え方まで提示している。

なぜHNで目を引いたのか

重要なのはブランド名より、agent ecosystemの断片化に正面から触れた点だ。投稿文では、agent frameworkを替えるたびにagent定義そのものを書き直す問題があると述べる。GitAgentはそれに対し、複数runtimeへ適応可能なfilesystem形状の契約としてagentを置く。公式サイトも単一実行エンジンではなく、framework-agnosticな標準として位置づけている。

これは、agent toolingがよりstatefulでproprietary、しかもUI中心になっていく流れと逆向きだ。git-nativeな定義なら、prompt、skill、runtime memory、governance artifactをすべてdiffとreviewの対象にできる。規制対応やチーム開発の観点では、この性質が単なる新しいagent frameworkより価値を持つ可能性がある。

まだ残る論点

HNの反応は実務的だった。どのadapterが実際に動くのか、schemaはどこまで安定しているのか、repo型の設計が本当に運用摩擦を減らすのか、といった疑問がすぐに出ていた。その検証はこれから必要だ。ただ、GitAgentが示した方向性は明確で、agent定義を不透明なプラットフォーム状態から、監査可能なファイル構造へ戻そうとする流れが現れ始めている。

原典: GitAgent。コミュニティ議論: Hacker News.

#open-standard

Show HN: GitAgent、AI agentをフレームワーク設定ではなくGitリポジトリとして扱う提案