本記事は MIXI DEVELOPERS Advent Calendar 2025 シリーズ2の 15日目の記事です。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
小規模なシステムを作る機会がありました。
軽く要件定義をしたかったので Claude Code に手伝ってもらいました。
生成 AI に向いてそうな作業だという印象でしたし、実際に驚くほど短時間で納得のいくドキュメントができました。
備忘ついでに記事を書きます。
作るシステム
今回作るシステムの概略です。
Slack からスレッドで会話しながら社内データソースを操作するというものです。
Claude Code Agent Skills を使う
世の中にはプロンプトで要件定義を行うナレッジが溢れていると思います。
同じような内容を書いても面白くありませんのでモダンな方式を考えたいと思います。
今回は Claude Code Agent Skills を使います。
Agent Skills とは何かを引用します。
Agent Skills package expertise into discoverable capabilities. Each Skill consists of a SKILL.md file with instructions that Claude reads when relevant, plus optional supporting files like scripts and templates.
ある専門的なペルソナを定義し、それに関連する参照資料やヘルパースクリプトを用意します。
かつ、スキルがいつ呼び出されるかを具体的に記述しておきます。
Claude Code が何かの作業を実施する際に、ユースケースに合致した場合に限りそのスキルが使用されます。
公式のスキル例だと以下が挙げられています。
- コミットメッセージ生成
- コードレビュアー
- PDF ファイル処理
スキルを作る
スキルを作ってみましょう。
今回は機能要件・非機能要件ドキュメントの生成をアシストするスキルを作ります。
スキルの作り方は Build with Claude Code Agent Skills に記載があります。
ただ、ゼロから作るのは難しいので、今回は skill-creator を使います。
Claude Code を起動したら Plugin MarketPlace に Anthropic のスキルを登録します。
/plugin marketplace add anthropics/skills
skill-creator は example-skills に含まれています。これをインストールします。
/plugin install example-skills@anthropic-agent-skills
OK です。一度 Claude Code を再起動しましょう。
再起動後にスキル作成を指示します。
skill-creator スキルを使ってスキルを作って
1. スキルの目的
- システムをクラウド上に構築するために必要な機能要件・非機能要件を定義する
2. 具体的なユースケース
- 機能要件・非機能要件の各項目をリストアップし、詳細な説明を加える
- Human と対話しながら機能要件・非機能要件を明確化する
- Web サイトを検索しながら機能要件・非機能要件のベストプラクティスを収集する
3. トリガー条件
- Human が「機能要件を定義したい」「非機能要件を定義したい」と言ったとき
しばらくするとスキルが作成されます。もしかしたら、いくつか質問されるかもしれません。
質問に答えてあげてください。
スキルはディレクトリに作成されます。私の場合は cloud-requirements-designer でした。
人によって違うはずです。それを .claude/skills/ に移動させます。
.claude/
└── skills
├── cloud-requirements-designer
│ ├── references
│ │ ├── functional_requirements.md
│ │ └── non_functional_requirements.md
│ └── SKILL.md
└── ...
それぞれのファイルを確認し、必要に応じて修正してください。求めている水準ではない場合が多いはずです。
修正は自分で行っても構いませんし、Claude Code に修正を指示しても構いません。Claude Code と何度か試行錯誤しながら完成させるのが良いでしょう。
機能要件定義を開始する
スキルが完成したら要件定義に進みます。
要件定義の前に以下のようなディレクトリとファイルを用意しました。
README.md にプロジェクトの背景や目的、ゴール、概要、関係者などを書いています。プロジェクト憲章みたいなものです。
他の2つは空ファイルで大丈夫です。
designs/
├── README.md
├── functional_requirements.md
└── non_functional_requirements.md
以下のプロンプトで機能要件定義を開始します。
機能要件を開始したい。
@/workspace/designs/README.md にプロジェクトの背景が書かれている。
機能要件をリストアップして、Human と対話しながら機能要件を明確化していってほしい。
機能要件はドキュメントに残す。ドキュメントは @/workspace/designs/functional_requirement.md に保存する。
cloud-requirements-designer スキルを使う。
早速質問が返ってきました。なお、今回のデータソースは JIRA です。
1. アクターについて
依頼者は全社員ですか？それとも特定部署のみですか？
対応者（JIRAを操作する人）は誰ですか？（各部署の担当者？SREチーム？）
2. 自動起票機能について
振り分け先のJIRAプロジェクトは何種類くらいありますか？
起票前に依頼者への確認ステップは必要ですか？（「この内容で起票しますか？」等）
起票失敗時のエラーハンドリングはどうしますか？
3. 双方向コミュニケーションについて
通知対象のJIRAイベントは何ですか？（コメント追加、ステータス変更、担当者変更、etc.）
Slackからチケットのステータス変更も可能にしますか？（例: Slackから「完了」と言えばJIRAをクローズ）
まず上記について教えていただけますか？
Claude Code が要件を作りやすい回答をしてあげましょう。
1. アクターについて
- 依頼者は全社員
- 対応者は特定部署の担当者のみ
2. 自動起票機能について
- 振り分け先のJIRAプロジェクトは5種類前後
- 「起票しますか？」のステップは必要。
- 起票失敗時にはエラーメッセージをSlackに返し、全てをロールバックする。
3. 双方向コミュニケーションについて
- JIRA から Slack の通知は不要（本機能のスコープ外）
- Slack からのステータス変更は可能にする。
次の項目について質問が返ってきました。
4. 5種類のJIRAプロジェクトについて
どのような分類ですか？（例: IT依頼、経費申請、人事相談など）
振り分けの判断基準は？（キーワード？部署？依頼内容のカテゴリ？）
「どのプロジェクトか判断できない」場合の挙動は？
5. 起票確認（FR-003）について
確認画面で表示する項目は？（タイトル、説明、振り分け先プロジェクト、優先度など）
ユーザーが内容を修正できるようにしますか？
確認後のタイムアウト（返答がない場合）はどう扱いますか？
6. Slackからのステータス変更（FR-007）について
変更可能なステータスは何ですか？（例: 対応中→完了、キャンセルなど）
全ステータスを変更可能？それとも特定のもののみ？
操作方法は？（「完了」と返信？ボタン操作？スラッシュコマンド？）
7. Slack→JIRAコメント同期（FR-006）について
Botとのスレッド内の返信が対象ですか？
添付ファイル（画像など）も同期しますか？
同じく Claude Code が要件を作りやすい回答をしてあげましょう。
4. 5種類のJIRAプロジェクトについて
担当者と協議するので宿題しておいて。
直近では MVP として以下の1種類を想定している。
- 経費申請
5. 起票確認（FR-003）について
- タイトルと説明文を確認対象にする
- ユーザーが内容を修正できるようにする
- タイムアウトはキャンセル扱いにする
6. Slackからのステータス変更（FR-007）について
- JIRA で操作可能なステータス変更の全てを対応する
- 操作方法は「完了」などの返信で対応する
7. Slack→JIRAコメント同期（FR-006）について
- Bot とのスレッド内の返信が対象
- 添付ファイルも同期する
以後、やりとりが続きます。
8. ユーザー認証・紐付けについて
SlackユーザーとJIRAユーザーの紐付けは必要ですか？
起票者（Reporter）はどう設定しますか？（Bot固定？Slackユーザーに紐付け？）
9. 起票確認の修正機能（FR-003）について
修正方法は？（「タイトルを○○に変更」と返信？再度全文を入力？）
何回まで修正可能ですか？
10. ステータス変更（FR-007）の操作方法について
「完了」「対応中」などの自然言語で対応しますか？
JIRAのステータス名と異なる表現（例:「終わり」→「完了」）も認識しますか？
11. 管理機能について
プロジェクト振り分けルールの設定画面は必要ですか？
利用状況のログ・統計は必要ですか？
12. エラー・例外ケースについて
JIRAがダウンしている場合の挙動は？
依頼内容が不明瞭な場合、AIは質問を返しますか？
8. ユーザー認証・紐付けについて
- SlackユーザーとJIRAユーザーはメールアドレスで紐付ける
- 起票者はSlackユーザーに紐付ける
9. 起票確認の修正機能（FR-003）について
- 「タイトルを○○に変更」などの自然言語で対応する
- 回数制限は設けない
10. ステータス変更（FR-007）の操作方法について
- 自然言語で対応する
- 異なる表現も認識する、曖昧な表現で判断がつかない場合は確認を返す
11. 管理機能について
- 一切の管理機能は不要
- Slack の会話、JIRA の操作履歴はログに残す
12. エラー・例外ケースについて
- JIRAがダウンしている場合はエラーメッセージをSlackに返す
- 依頼内容が不明瞭な場合はAIが質問を返す、明確になるまで先に進まない
まとめ
非機能要件も同様のプロンプトと何回かの対話でドキュメントが完成しました。
これらのドキュメントを叩き台にして関係者とレビューを行い、最終的な要件定義を完成させました。
それらしいサンプルを収集してくる、テンプレートを作成する、テンプレートを改良する、これらのタスクは生成 AI に向いていると感じています。要件定義作成タスクにまさに合致しています。
「業務フローを AI に合わせる」とはこのことで、近未来のシステム構築手法の1つに一歩踏み出した感覚になります。
Discussion