ObjectOS
はじめる
← すべての記事
AI とエージェント 開発者 公開済み · · 著者 ObjectStack Team

Agent ルールファイルの書き方：AI にガバナンス可能なアプリを生成させる

AGENTS.md、.cursor/rules、CLAUDE.md はコードスタイルだけを管理すべきではない。権限、承認、監査、対象メタデータ形式を書けば、AI 生成アプリはレビューしやすくなる。

Agent ルールファイルの書き方：AI にガバナンス可能なアプリを生成させる
  • エージェントのルール
  • AIがコードを書く
  • MCP
  • オープンプロトコル
  • ガバナンス
  • トレンド考察

まず結論から。AIがコードの大半を書く世界では、あなたのエージェントのルールファイル（AGENTS.md、.cursor/rules、CLAUDE.md）こそが、実際に効いているアーキテクチャ文書だ。だが大半のチームはそれをインデントとコンポーネントライブラリの管理に使っている——管理しているのは「見栄えがいいか」であって、「本番に出せるか」ではない。これを正しく使えば、てこ（レバレッジ）はずっと大きい。

実際にあった小さな事故。あるチームの AGENTS.md は真面目に書かれていた。インデントは2スペース、社内UIライブラリを使う、コミットメッセージは命令形で。エージェントは一つも漏らさずそのとおりにこなし、生成されたコードは「非常に規約どおり」だった。ところがその後、ついでに生成された GET /api/refunds が 全員の返金記録を返していた ことに誰かが気づく。

コードレビューでは誰も止められなかった——なぜなら、それは確かにルールファイルの一条一条に合致していたからだ。エージェントはどのルールにも違反していない。ただ権限という存在を、誰も教えていなかっただけだ。あのルールには、「誰がどのデータを見られるか」についての条文が一つもなかった。エージェントは見栄えよく書く方法を教わったが、ガバナンス可能に書く方法は教わっていなかった。

あなたのルールファイルは、間違ったものを管理している

AIでコードを書くチームなら、いまやほぼどこでもエージェント向けのルールファイルを持っている。これは良い習慣だ。問題は、それが最も価値の低いところに使われていることである。

大半のルールファイルに何が書かれているか棚卸ししてみよう。コードスタイル、ディレクトリ構造、どのライブラリを使うか、命名規約、コミット規約。文句のつけようはない。だがそれらには共通点が一つある——すべてが「コードがどう見えるか」についてであって、「このアプリは何を許されているか」についての条文が一つもない。それらは複数のエージェントによる、複数回の生成の産物を一貫させる。解決しているのは「一家のように似て見える」ことだ。だが、一つの企業向けアプリが本番に出せるかどうかを決める事柄——誰がどのデータを見られるか、どの操作に承認が要るか、何かあったとき追跡できるか——にはまったく触れていない。

言い換えれば、コードを書くことがAIに委ねられたとき、ルールファイルは「コーディング規約」から「アーキテクチャとガバナンスの制約」へと格上げされた——なぜならそれは、生成されるその瞬間に制約を注入できる数少ない場所だからだ。いったんコードが生成されてしまえば、後から権限を足し、監査を足すのは事後の手戻りでしかない。ルールファイルは、ガバナンスを生成段階へ前倒しできる最も早いレバーの一つだ。

「ガバナンス可能性」を、事後ではなくルールに書き込む

事後にガバナンスを足すのは、いま最もありふれた、そして最も高くつく間違ったやり方だ。まずエージェントに生成させ、後から戻って権限を審査し、監査を足し、承認を加える——これは AI Agent 試験導入が本番に進めない理由の記事 で述べたガバナンスの手戻りそのものだ。アプリを一つ生成するたびに一度手戻りが発生すれば、スケールした後の勘定は重くなる。

もっと省力なやり方は、ルールでエージェントをそれ自体がガバナンス可能な目標へ向けることだ。こうしたルールの核心は、スタイルではなく、産物の形態を制約することにある。

# AGENTS.md —— 業務アプリを生成するとき
- ドメインは ObjectStack のオブジェクト（ObjectSchema）としてモデリングし、テーブルやマイグレーションを手書きしない
- すべてのアクセス権限は PermissionSet 宣言で通し、APIの中で if 文による認可を絶対に手書きしない
- SQL の文字列連結や認可ミドルウェアを手書きしない——これらはランタイムが担う
- 承認が必要な操作は、コードに書くのではなく、オブジェクトに付く flow として宣言する
- 産物は、大量の実装ではなく、レビュー可能なメタデータの diff でなければならない

一条ずつ見れば、どの行も「事後にこそ爆発する一類のリスク」を前倒しで閉じている。2行目は越権を「APIの中で判定を一つ書き漏らす」から「権限が明示的に宣言され、ランタイムが強制する」へ変える。4行目は承認を「あるコードの中のハードロジック」から「オブジェクトに付き、監査可能なプロセス」へ変える。このルールのもとでは、冒頭のあの GET /api/refunds は二度と起きない。エージェントが生成するのは「呼び出し元の権限に従って読み取る」と宣言された support_refund オブジェクトであり、越権という道は源流で閉ざされる——エージェントがある生成回で「たまたま判定を足すのを覚えていた」ことに期待するのではなく。

なぜ「エージェントに ObjectStack を生成させる」が現実的なのか：オープンなフライホイール

ここには避けて通れない問いがある。なぜエージェントが特定の目標フォーマットを正しく書けるのか？ルールをどれだけ上手に書いても、モデルが書けなければ無駄だ。

その答えこそ、オープンなセマンティック層の記事 が論じたフライホイールだ——エージェントは、見たことがあり、検索でき、ルールで制約できるものを生成しやすい。閉じたプラットフォームのプライベートなフォーマットは、公開資料や例が少なく、検証フィードバックも弱ければ、いくらルールを書いても安定して生成しにくい。一方 ObjectStack は Apache 2.0 のオープンプロトコルであり、これが「エージェントに正しく書かせる」ことに三つの現実的な前提を与える。

  1. 学習されうる：オープン + 公開 + 議論されている → モデルや検索システムに学ばれやすい。
  2. 制約されうる：一つのルールファイルが、エージェントの産物をこの宣言的な目標へ錨（いかり）で固定する。
  3. 生成時に検証されうる：ランタイムが生成されたメタデータを検証する——不正な定義はその場で拒否され、エージェントは即座に訂正信号を受け取る。これは自由形式のコードには出せない決定的な差だ。間違ったSQLはそのまま動いて本番で爆発しうるが、間違ったメタデータは門をくぐれず、その場で突き返されて書き直される。

まさにこの3点目が、「エージェントに正しく書かせる」を運任せから、フィードバックのある収束プロセスへ変える——エージェントが書き間違え、拒否され、直す。コンパイルエラーのように即時だ。さらに一歩進めて、ランタイムのガバナンスされたツールを MCP 経由で公開すれば、エージェントは生成時に権威ある定義を取りに行き、ランタイムでは境界内でそれを操作できる——書くことと使うことが、一つのガバナンスを共有する。（ガバナンスされたツール層という件は、MCPの記事 で別途語った。）

実装：今日すぐ足せる三条

いきなりルール全体を書き直す必要はない。もしいまエージェントのルールファイルにガバナンス制約を三条だけ足すなら、収益（リターン）の高い順に、この三条であるべきだ。

  1. 「権限は必ず明示的に宣言し、コードの中で認可を手書きしてはならない。」 この一条は、冒頭のような「判定を一つ書き漏らせば全テーブルが漏洩する」事故を直接消滅させる——認可を「エージェントが覚えているか」から「宣言に書かれているか」へ変える。
  2. 「高リスクの操作（金を動かす、契約を発行する、データを削除する）は、必ず承認付きのプロセスとして宣言する。」 「止まって人を待つべきか」を、エージェントのその場の判断ではなく、一条の監査可能なルールへ変える。
  3. 「大量の実装ではなく、レビュー可能な宣言を産物にする。変更は一画面の diff で見終えられること。」 この一条が守るのは、あなた自身のMergeボタンだ——エージェントに、あなたが審査できるものを届けることを強制する。

この三条の共通点。制約しているのはどれも「コードをどう書くか」ではなく、「産物がガバナンスでき、レビューできるか」だ。これこそルールファイルがやるべきで、しかし滅多に誰もやらせていないことである。

まず冷や水を浴びせておく

二点、はっきりさせておかなければならない。さもないとルールファイルを神格化してしまう。

第一に、ルールファイルが管理するのは産物の形態であって、エージェントの判断力ではない。それはエージェントがガバナンスされたメタデータを生成することは保証できるが、それがビジネス上の意図を正しく理解したことは保証できない。「サポート担当にどれだけ大きな返金権限を与えるべきか」といった判断は、依然として人が決め、reviewしなければならない——ルールはただ、その判断に落とし所があり、かつ強制されることを確実にするだけだ。8,000行のどこかに散らばらせるのではなく。それは「やっていいのか」という問いをあなたの前に突きつけるが、代わりに答えてはくれない。

第二に、これを「公式SDK」だと思ってはいけない。ここで示したのは一つの戦法、一份のサンプルルールであって、ワンクリックでインストールできる公式ファイルではない——あなたは自分のスタックに合わせてこれを実体化し、きちんと保守する必要がある。価値は考え方にある。ガバナンスを生成のその瞬間へ前倒しすること。コードが生えてきてから後で足すのではなく。

結びに

AIがコードを書く時代、チーム間で差が開くのは、もはや誰のエンジニアが速く書くかではない——誰のエージェントが生成したものを本番に出せるかだ。そしてこのことのスイッチは、大半の人がインデント管理に使っているあのルールファイルの中に、その多くがある。

それを「コーディング規約」から「ガバナンス可能性の制約」へ格上げし、さらにエージェントに、オープンで、宣言的で、ランタイムが支えられる目標を指し示そう——そうすればあなたが生成するすべてのアプリは、最初の一行から、審査でき、ガバナンスでき、責任を負えるものになる。

npm i -g @objectstack/cli && os start

あなたのエージェントに「ObjectStack のオブジェクトとしてモデリングし、権限は宣言で通す」と書き、返金アプリを生成させよう——そのうえで、越権して全データを返させようとしてみて、ランタイムがどう源流から拒否するかを見てみよう。