既存資料や会議文字起こし、ER図（A5-SQL）、業務フロー（Dorw.io）、非機能要件までAIエージェントに整理させる実践例を紹介します
はじめに
AIエージェントを使った開発では、AGENTS.md にコーディングルールやディレクトリ構成、テスト方針などを書いておき、
AIにプロジェクト固有のルールを守らせる使い方が増えてきました。
ただ、実際に使ってみると、AGENTS.md はコーディングだけに使うのはもったいないと感じています。
私は現在、AGENTS.md を活用して、AIエージェントに以下のような要件定義成果物を作成させています。
- 既存資料の整理
- 会議の文字起こし内容の分析
- 要件定義書の作成
- ER図の作成
- 業務フロー、スイムレーン図の作成
- 非機能要件の整理
- 課題・不明点一覧の抽出
特に、ER図は A5:SQL Mk-2で扱いやすい形式、業務フローは Draw.ioで編集しやすい形式 で出力させるようにしています。
この記事では、AGENTS.md を要件定義に活用する考え方と、実際にどのような指示を書いているかを紹介します。
AGENTS.mdは「開発ルール」だけのものではない
AGENTS.md は、AIエージェントに対してプロジェクト固有のルールや作業方針を伝えるためのファイルです。
一般的には、以下のような内容を書くことが多いと思います。
- 使用技術
- ディレクトリ構成
- コーディング規約
- テスト方針
- 禁止事項
- レビュー観点
- セキュリティルール
しかし、これは見方を変えると、
AIエージェントに対する作業指示書・業務手順書 としても使えます。
つまり、開発だけでなく、要件定義でも以下のようなルールを定義できます。
- どの資料を優先するか
- 推測で要件を書かないこと
- 不明点は課題として残すこと
- 顧客発言を優先すること
- 図の形式を統一すること
- 要件定義書の章立てを固定すること
- 非機能要件の分類を固定すること
これにより、毎回AIに長いプロンプトを書くのではなく、
AGENTS.md を見れば同じ品質・同じ構成で要件定義作業を進められるようになります。
要件定義で困っていたこと
要件定義では、以下のような情報がバラバラに存在します。
- 顧客から受け取った既存資料
- 打ち合わせの議事録
- 会議の文字起こし
- チャットのやり取り
- 既存システムの画面
- 既存DBのテーブル情報
- 業務担当者からのヒアリング内容
これらを人間が毎回読み直して、要件定義書に整理するのはかなり大変です。
特に大変なのは、以下のような作業です。
- 業務の登場人物を整理する
- As-Is / To-Be の業務フローを整理する
- 機能要件と非機能要件を分ける
- 既存DBからER図を作る
- 会議で出た曖昧な内容を課題として残す
- 顧客発言と推測を混ぜないようにする
- 図のフォーマットを毎回揃える
ここでAIエージェントを使うと非常に便利ですが、
何もルールを与えずに依頼すると、以下のような問題が起きます。
- 勝手に要件を補完してしまう
- 根拠のない機能を追加してしまう
- 図の粒度が毎回変わる
- 出力形式が安定しない
- 非機能要件が一般論になってしまう
- 課題と決定事項が混ざる
そのため、要件定義でも AGENTS.md にルールを定義しておくことが重要です。
AGENTS.mdでAIエージェントに指示する内容
要件定義用の AGENTS.md では、主に以下を定義しています。
基本方針
- 推測で記載しない
- 根拠のない要件を追加しない
- 不明点は課題として記録する
- 顧客発言を優先する
- 会議録の内容を優先する
- 既存資料と会議内容に矛盾がある場合は、矛盾点として記録する
- 現行業務からTo-Beを導出する
- 図は指定フォーマットで出力する
成果物
- 要件定義書
- アクター一覧
- 役割一覧
- 権限一覧
- 業務ルール
- 例外処理
- ユースケース一覧
- 機能要件
- 非機能要件
- ER図
- 業務フロー
- 課題一覧
- 用語集
出力形式
- 要件定義書はMarkdown
- ER図はA5:SQL Mk-2で扱いやすい形式
- 業務フローはDraw.ioで編集可能な形式
- 課題一覧は表形式
- 不明点は「確認事項」として分離
実際に作成させている成果物
1. 要件定義書
要件定義書は、基本的にMarkdownで作成しています。
章立ては以下のように固定しています。
# 要件定義書
## 1. 概要
- 背景・目的
- スコープ
## 2. 関係者整理
- アクター一覧
- 役割一覧
- 権限一覧
## 3. 業務整理
- As-Is業務フロー
- To-Be業務フロー
- 業務ルール
- 例外処理
## 4. 要件分析
- ユースケース一覧
- 機能要件
- 非機能要件
## 5. データ設計
- エンティティ一覧
- ER図
- データ項目一覧
## 6. 外部連携
- 連携先一覧
- 連携方式
- 入出力データ
## 7. 移行方針
- 移行対象
- 移行方法
- 移行時の注意点
## 8. 運用・保守
- 運用体制
- 監視
- バックアップ
- 障害対応
## 9. 課題・確認事項
- 未決事項
- 確認事項
- リスク
章立てを固定しておくことで、案件ごとに構成がブレにくくなります。
2. ER図
ER図は、A5:SQL Mk-2で扱いやすい形式を意識して出力させています。
AIには、単に「ER図を作って」と依頼するのではなく、以下のように指示しています。
# ER図作成ルール
- 既存資料、画面項目、会議文字起こしからエンティティ候補を抽出する
- 推測でテーブルを追加しない
- 根拠が弱いエンティティは「候補」として扱う
- 主キー、外部キー、ユニーク制約を明記する
- 物理名は snake_case とする
- 論理名は日本語で記載する
- A5:SQL Mk-2で取り込み・転記しやすいように、テーブル単位で整理する
出力例は以下のような形です。
## users
| 項目論理名 | 項目物理名 | 型 | PK | FK | NULL | 備考 |
|---|---|---|---|---|---|---|
| ユーザーID | user_id | bigint | ○ | | NO | ユーザーを一意に識別する |
| 氏名 | name | varchar(255) | | | NO | |
| メールアドレス | email | varchar(255) | | | NO | 一意制約 |
| 作成日時 | created_at | datetime | | | NO | |
| 更新日時 | updated_at | datetime | | | NO | |
3. 業務フロー（スイムレーン図）
業務フローは、Draw.ioで編集できる形式を前提にしています。
AIには、以下のようなルールを与えています。
## 業務フロー作成ルール
- As-IsとTo-Beを分けて作成する
- スイムレーン形式で作成する
- 登場人物、部門、システム、外部サービスをレーンとして整理する
- 業務の開始、判断、処理、終了を明確にする
- 例外処理も可能な限り記載する
- Draw.ioで編集可能な形式で出力する
- 不明な処理は推測せず、確認事項として記録する
レーン色もルール化しています。
## レーン色
- 人が担当するレーンはブルー系・ベージュ系・ミント系を優先利用
- システムはグリーン系で統一
- SaaSやAPIなど外部サービスはオレンジ系で統一
- AIエージェント、自動化処理、バッチ処理はパープル系で統一
- 分類できないレーンのみグレー系を使用
- 同一レーン内の色は統一する
- 隣接レーンで同系色を避ける
4. 非機能要件
非機能要件は、AIに任せると一般論になりやすい部分です。
そのため、分類を固定しています。
非機能要件は以下の分類で整理する。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境
- データ管理
- バックアップ
- 監視
- ログ
- 監査
- 障害対応
また、以下のルールも重要です。IPAも参考とするように一文を付け加えております。
## 非機能要件作成ルール
- IPA「非機能要求グレード2018」を参考基準にする。
- 一般論だけで記載しない
- 顧客要望、業務影響、運用体制を根拠に記載する
- 数値が不明な場合は仮定で書かず、確認事項にする
- SLA、RTO、RPOなどが不明な場合は確認事項にする
- セキュリティ要件は認証、認可、ログ、監査、データ保護に分ける
運用してみて良かったこと
実際に AGENTS.md を要件定義で使うと、以下のようなメリットがあります。
1. 出力のブレが減る
毎回プロンプトで細かく指示しなくても、章立てや成果物の粒度が揃いやすくなります。
2. 推測による要件追加を抑えられる
AIは良くも悪くも補完が得意です。
そのため、
Markdown推測で記載しない根拠のない要件は追加しない
不明点は課題として記録するその他の行を表示する
というルールを明記しておくことで、要件定義で危険な「勝手な仕様追加」を抑えやすくなります。
3. 図のフォーマットを統一できる
ER図や業務フローは、出力形式がバラつくと後で修正が大変です。
最初から、
ER図はA5:SQL Mk-2向け
業務フローはDraw.io向け
スイムレーン図はレーン色も指定
というルールを決めておくことで、後工程で使いやすい成果物になります。
4. 議事録や文字起こしを活用しやすくなる
会議の文字起こしをAIに読み込ませることで、
- 決定事項
- 未決事項
- 確認事項
- 顧客要望
- 業務ルール
- 例外処理
を抽出しやすくなります。
特に、会議で出た曖昧な内容を「仕様」として確定させず、
「確認事項」として残せるのは実務上かなり有効です。
注意点
便利ではありますが、注意点もあります。
1. AIの出力をそのまま確定資料にしない
AIが作成した要件定義書は、あくまでたたき台です。
最終的には、顧客・業務担当者・開発担当者でレビューする必要があります。
2. 根拠を残す
要件定義では、「なぜその要件になったのか」が重要です。
そのため、可能であれば以下を残すようにしています。
- 元資料名
- 会議日
- 発言者
- 該当する発言内容
- 判断理由
3. 不明点を無理に埋めない
AIに依頼すると、自然な文章でそれらしく補完してくれます。
しかし、要件定義ではそれが危険な場合があります。
分からないことは、分からないまま
「確認事項」
として残すことが重要です。
4. 図は人間がレビューする
ER図や業務フローは、AIが出したものをそのまま使うのではなく、必ず人間が確認します。
特に以下はレビュー必須です。
- 業務の順序
- 例外処理
- 権限
- データの持ち方
- 外部システム連携
- 手作業とシステム処理の境界
まとめ
AGENTS.md は、コーディングルールを書くためだけのものではありません。
AIエージェントに対する作業指示書として使えば、要件定義でもかなり活用できます。
特に、以下のような作業と相性が良いです。
- 既存資料の整理
- 会議文字起こしの分析
- 要件定義書の作成
- ER図の作成
- 業務フローの作成
- 非機能要件の整理
- 課題・確認事項の抽出
ポイントは、AIに自由に書かせるのではなく、
AGENTS.md に以下を明確に書いておくことです。
- 基本方針
- 成果物
- 章立て
- 出力形式
- 図のフォーマット
- 禁止事項
- 確認事項の扱い
コーディングだけでなく、要件定義にも AGENTS.md を活用することで、
AIエージェントをより実務に近い形で使えるようになります。