🔗 RDRAAgent Phase1にUSDMを適用して精度を上げる

はじめに

RDRAAgent v0.6 は、初期要望テキストから RDRA2.0 モデルを段階的に自動生成する Coding Agent ツールです。Phase1（基礎要素の特定）は自由記述を入力とするため、要求の分離や根拠の抽出を AI の推測に依存しています。

本記事では、USDM（Universal Specification Describing Manner）の記法を Phase1 の前段に組み込み、入力を構造化して後続フェーズの精度を向上させるアプローチを紹介します。

RDRA2.0 とは

概要

RDRA（Relationship Driven Requirement Analysis）は、2012 年に神崎善司氏（ValueSource Inc.）が提唱した要件定義モデリング手法です。システムとビジネスの関係性を明示的にモデル化し、要件の完全性・一貫性を確保します。

4 レイヤー構造

RDRA2.0 は要件定義を 4 つの階層レイヤーで体系化します。各レイヤーは「なぜ？」という Why 依存関係で結合されます。

10 種類のアイコン体系

RDRAAgent v0.6

RDRAAgent は、神崎善司氏が開発した AI アシスタント型の RDRA 自動化ツールです。Claude Code や Cursor で実行できます。

git clone https://github.com/kanzaki/RDRAAgent_v0.6.git
cd RDRAAgent_v0.6
npm install
node menu.js

4 つのフェーズで段階的に要件を詳細化します。

USDM とは

概要

USDM（Universal Specification Describing Manner）は、清水吉男氏が提唱した要求仕様記述法です。要求を階層的に分解し、各要求に「なぜそれが必要か」を明示する点が特徴です。

https://zenn.dev/suwash/articles/usdm_xddp_20260325

本記事での採用記法

USDM の元来の 4 階層（要求→理由→説明→仕様）から、本記事では 3 階層に絞ります。

「説明」は理由に吸収し、「仕様」は設計側の担当として除外しています。要件定義の範囲では、要求の構造化と根拠の明示で十分です。

USDM の強み

USDM が効果を発揮するのは、要求のブレイクダウンです。

• 要求の分離: 1 つの要求に 1 つの関心事を対応させる
• 理由の必須化: 根拠のない要求を排除するフィルタリング機能
• 要件の検証可能性: 「〜できること」形式で記述し、テスト設計につなげる

RDRAAgent Phase1 の課題

現状の Phase1 は「初期要望.txt」（自由記述）を入力として、AI が基礎要素を抽出します。

【背景】受注業務がFAXベースで月20時間かかっている
【目的】受注業務のデジタル化
【スコープ】受注入力、在庫確認、出荷指示
【制約】既存ERPとの連携必須

この自由記述からの抽出には 3 つの課題があります。

これらは Phase1 の出力品質に直結します。Phase2 の BUC 抽出、Phase3 の UC 定義まで連鎖的に影響します。

提案: Phase1 に USDM 分解を組み込む

全体フロー

Phase1 の前段に USDM 分解を挟むだけで、Phase2 以降は変更不要です。

Step 1-A: USDM 分解（新規追加）

初期要望.txt を入力として、Coding Agent が USDM 3 階層に分解します。
USDMはExcelで管理することが多いですが、AIエージェントの扱いやすさ、schema validationなどを活用するため、YAML形式を採用します。

入力（従来の初期要望.txt）

【背景】
受注業務がFAXベースで、営業担当者が手入力している。
月20時間の工数がかかり、入力ミスによる出荷トラブルが月3件発生。

【目的】
受注業務のデジタル化による効率化と品質向上。

【スコープ】
受注入力、在庫確認、出荷指示、顧客管理

出力（USDM 構造化要件 - YAML 形式）

requirements:
  - id: R1
    description: 受注業務を効率化したい
    reason: FAX受注→手入力→確認電話で月20時間かかっている
    conditions:
      - id: K1-1
        description: 受注データをWebフォームから直接取り込めること
      - id: K1-2
        description: 受注入力後の確認を自動メール通知で代替できること

  - id: R2
    description: 受注入力ミスを防止したい
    reason: 手入力ミスによる出荷トラブルが月3件発生している
    conditions:
      - id: K2-1
        description: 受注入力時にマスタデータとの整合性チェックを行うこと
      - id: K2-2
        description: 過去の類似注文をサジェストできること

  - id: R3
    description: 在庫状況をリアルタイムに把握したい
    reason: 受注時に在庫が分からず後から欠品連絡になるケースがある
    conditions:
      - id: K3-1
        description: 受注入力時に在庫数を自動表示すること
      - id: K3-2
        description: 在庫が閾値以下の場合にアラートを表示すること

  - id: R4
    description: 出荷指示を自動化したい
    reason: 受注確定後の出荷指示が手作業で遅延が発生している
    conditions:
      - id: K4-1
        description: 受注確定時に出荷指示を自動生成できること

YAML フォーマットの利点

YAML スキーマ定義

# requirements.schema.yaml
type: object
required: [requirements]
properties:
  requirements:
    type: array
    items:
      type: object
      required: [id, description, reason, conditions]
      properties:
        id:
          type: string
          pattern: "^R\\d+$"
        description:
          type: string
        reason:
          type: string
        conditions:
          type: array
          minItems: 1
          maxItems: 4
          items:
            type: object
            required: [id, description]
            properties:
              id:
                type: string
                pattern: "^K\\d+-\\d+$"
              description:
                type: string

このスキーマにより、USDM 分解の出力を自動検証できます。reason が空、conditions が 0 件または 5 件以上、id のフォーマット不正などを機械的に検出できます。

分解ルール

Step 1-B: 基礎要素の特定（既存 Phase1 の改修）

USDM 出力を入力として、従来の Phase1 処理を実行します。

変更点

最大の改善点は、USDM の要件が Phase2 の BUC 候補として直接機能する点です。従来は AI がゼロから BUC を推測していましたが、構造化された要件が導出の根拠になります。

RDRA の要求モデルとの関係

RDRA の 4 レイヤーのうち、Layer1（システム価値）の要求モデルは他レイヤーと比べて記法が緩い部分です。アイコン関係によるトレーサビリティはレイヤー間で機能します。一方、要求そのものの内部構造（なぜその要求があるのか、どこまでが 1 つの要求か）は RDRA では規定されていません。

USDM 記法を要求モデルに適用すると、この構造の弱さを補えます。

USDM の適用範囲を Layer1 の要求モデルに限定し、BUC 以下は RDRA のモデリングに委ねます。

従来フローとの比較

自動化

Step 1-A の自動化プロンプト

以下は、USDM 分解を Coding Agent に実行させるためのプロンプト例です。

あなたはUSDM要件分析の専門家です。
以下の初期要望テキストを、USDM記法のYAML形式で構造化してください。

## USDM記法ルール
- 要求（description）: 「〜したい」形式。ビジネス視点で記述
- 理由（reason）: 現状の課題を定量データ付きで記述
- 要件（conditions）: 要求を満たす具体的条件。1要求あたり1〜4件

## 分解ルール
- 1つの要求に複数の関心事が混在する場合は分離する
- 理由が不明な要求は reason: "要確認" として残す
- 要件は検証可能な記述にする（「〜できること」形式）
- 仕様（実装方法）は書かない。要件（実現条件）に留める

## 出力フォーマット（YAML）
requirements:
  - id: R{N}
    description: {要求テキスト}
    reason: {理由テキスト}
    conditions:
      - id: K{N}-{M}
        description: {要件テキスト}

## 初期要望テキスト
{初期要望.txtの内容}

RDRA_Knowledge への追加

Phase1 カスタマイズに伴い、RDRA_Knowledge/ にナレッジファイル USDM_Decomposition.md を追加します。記載する内容は以下の 4 項目です。

変更管理への適用

新規開発だけでなく、既存システムの変更管理にもこのフローを適用できます。

従来の USDM 単体での変更管理の課題

従来、USDM で要求仕様を記述した場合、変更の影響範囲を追跡するには XDDP（eXtreme Derivative Development Process）の 3 点セットを別途作成・維持する必要がありました。

USDM はテキスト記述であり、要素間の関係性を構造的に保持しません。「この要求を変えたら何に影響するか」を USDM 単体では追跡できず、XDDP のマトリクスが必要でした。

RDRA モデルの変更差分による代替

RDRA の場合、モデル自体がアイコン間の関係性を構造として保持しています。モデルを変更すれば、その差分がそのまま影響範囲を表現します。

最終ステップの「変更設計」は、Spec 駆動開発における Spec に相当します。RDRA の影響分析で特定された変更範囲と、USDM の理由による正当性を組み合わせた変更設計書が、Coding Agent の実装 Spec として機能します。

RDRA モデルが Markdown / PlantUML / YAML 等のテキスト形式で Git 管理されていれば、git diff で以下を機械的に取得できます。

• 追加されたアイコン: 新規 BUC、UC、情報エンティティ
• 変更されたアイコン: 属性の追加・削除、関連の変更
• 影響を受ける既存アイコン: 変更アイコンから依存関係をたどった先の要素

USDM の「理由」が変更の正当性を担保し、RDRA モデルの構造的な差分が影響範囲を自動的に表現します。XDDP の 3 点セットを別途維持する必要がなくなります。変更設計がそのまま Spec 駆動開発の Spec として Coding Agent に渡せるパイプラインが成立します。

まとめ

RDRAAgent の Phase1 に USDM 分解を組み込むと、自由記述に依存していた入力品質が向上し、後続フェーズの精度が上がります。変更管理においては、RDRA の影響分析から導出された変更設計が Spec 駆動開発の Spec となり、要求定義から実装までが一貫したパイプラインでつながります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• GitHub
  • RDRAAgent v0.6
• 公式ドキュメント
  • RDRA 公式サイト
• 記事
  • 技術調査 - USDM・XDDP
• 書籍
  • RDRA2.0 ハンドブック（神崎善司著）
  • 「要求を仕様化する技術・表現する技術」（清水吉男著）