はじめに
Cursor、GitHub Copilot、kiro-cli など、生成AIを活用した CLI ツールが増える中で
「振る舞い定義ファイル（rules.md）」という概念が急速に広がっています。
主要AIツールの振る舞い定義ファイル一覧
| ツール名 | 種類 | 振る舞い定義ファイル | パス | 公式情報ソース |
|---|---|---|---|---|
| Kiro CLI | CLI |
rules.md（慣例） |
.kiro/steering/ 配下 |
https://github.com/kirodotdev/Kiro |
| Cursor | IDE |
.mdc（Project Rules） |
.cursor/rules/ |
https://docs.cursor.com/context/rules |
| Claude Code | AIコーディング | CLAUDE.md |
プロジェクト直下（多くは root） | https://docs.anthropic.com/claude/docs/claude-code |
| GitHub Copilot | IDE | copilot-instructions.md |
.github/copilot-instructions.md |
https://docs.github.com/en/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot |
ただし、最初に明記しますが
このファイルには業界で統一された正式名称は存在しません。
英語圏でも Rules File、Instructions File、Behavior Definition File など
複数の呼び方が混在しており、標準化されていないのが現状です。
本記事では便宜上、
「振る舞い定義ファイル」
と呼びます。
振る舞い定義ファイルとは？
振る舞い定義ファイルは、生成AI CLI や AI エージェントに対して
- どう振る舞うべきか
- 何をしてよいか／してはいけないか
- どんな口調で話すか
- どんな形式で返すか
- 例外時にどう対応するか
といった 行動仕様 を記述するファイルです。
rules.md（サンプル）
このファイルは kiro-cli における 振る舞い定義ファイル の例です。
AI がどのように振る舞うかを Markdown で定義します。
## 役割
- あなたは本プロジェクト専用の AI CLI アシスタントです
- 正確で再現可能な支援を提供してください
## 基本方針
- 出力は簡潔かつ実用的にする
- 実行可能なコマンドや具体例を優先する
- 不確実な内容は断定しない
## 出力ルール
- コマンドは必ずコードブロックで出力する
- 手順が複数ある場合は番号付きリストを使う
- エラー時は「原因」「対処方法」を分けて記載する
## 禁止事項
- 破壊的なコマンド（例：`rm -rf /`）を提案しない
- 権限昇格が必要な操作は必ず注意喚起する
## 例外対応
- 情報が不足している場合は質問する
- 判断できない場合は「不明」と明示する
※ 本サンプルは kiro-cli における rules.md の一例です。
実際の解釈や挙動はツールやバージョンによって異なる可能性があります。
振る舞い定義ファイルを導入するメリット
1. 出力が安定し、AI の“揺れ”が減る
LLM は同じ入力でも出力が揺れやすいですが、
振る舞い定義ファイルでルールを固定すると 再現性が大幅に向上 します。
- 出力フォーマットが毎回同じ
- 不要な雑談が減る
- 危険なコマンドを生成しなくなる
- 例外時の対応が統一される
CLI の品質が一気に上がるポイントです。
2. チーム開発で「AI の仕様」を共有できる
AI の振る舞いは個人のプロンプトスキルの差で大きく変わるので、属人化しやすいのが大きな問題です。
振る舞い定義ファイルを導入すると
- 仕様を Markdown で共有できる
- Pull Request でレビューできる
- 変更履歴を Git で追える
- 新メンバーがすぐ理解できる
といったメリットがあり、プロンプトスキルに依存しないAIの振る舞いを実現できます。
3. プロジェクト固有の観点をレビューに反映できる
rules.md があると、「このコードに対してこの観点でレビューを行う」 という基準が明確になります。
したがって、AI を使ったレビューでも プロジェクト固有の観点を反映したレビューが可能 になります。
- CLI の E2E テスト
- 出力フォーマットの検証
- 危険コマンドの拒否テスト
- 例外時のレスポンス確認
これにより、目的に沿った一貫性のあるレビューが実現できます。
4. LLM のバージョンアップに強くなる
GPT-4 → GPT-5 のようにモデルを変更すると、
AI の振る舞いが変わってしまう問題がよく起きます。
しかし振る舞い定義ファイルがあれば、
- どの振る舞いが仕様で
- どの振る舞いがモデル依存か
が明確になるため、移行コストが大幅に下がります。
5. プロンプトをコードから切り離せる（疎結合化）
プロンプトをコードにベタ書きすると、
- 修正が難しい
- 再利用しにくい
- バージョン管理しづらい
といった問題が発生します。
振る舞い定義ファイルに切り出すことで、
- 設計者は Markdown で編集
- 開発者はコードに集中
- CLI 起動時に読み込むだけ
という 役割分担が可能 になります。
6. AI エージェントの“人格”を自由に設計できる
振る舞い定義ファイルは制約だけでなく、
AI のキャラクターや専門性を設計するためのファイル でもあります。
- 口調（丁寧・フラット・技術寄り）
- 専門領域（DevOps、セキュリティ、データ分析など）
- 禁止事項（危険コマンド、推測回答）
- 出力形式（JSON、YAML、CLI フォーマット）
これらを明確に書くことで、
プロダクトの世界観に合った AI を作れる ようになります。
まとめ
振る舞い定義ファイル（rules.md）は、生成AI CLI において
- 出力の安定化
- チーム開発の効率化
- テスト容易性の向上
- モデル変更への強さ
- プロンプトの疎結合化
- AI の人格設計
といった多くのメリットをもたらします。
AI エージェントを“プロダクト”として扱うなら、
振る舞い定義ファイルは必須のコンポーネント と言えます。
導入も比較的簡単に行えるのでぜひ試してみてください。