• 初期要望からRDRA定義をAIで生成

• 定義されたRDRA定義からRDRAGraphを表示

• 定義された内容をRDRASheetに連携する

• 定義したRDRAの内容をChatで問い合わす

• 非アーキテクチャ依存の仕様のたたき台作成

  • アクター別、BUC・アクター別の画面項目の表示

  • 論理データモデルの作成

  • ビジネスルールのたたき台作成

  • イベント一覧のたたき台作成

• 仕様駆動開発のための機能仕様たたき台作成

  • ３レイヤー(UI,application,domain)の仕様生成

  • 各仕様の繋がりを示すCallgraphを表示

• 定義したRDRASdd（機能仕様）の内容をChatで問い合わす

• 要件定義

  • 要件定義をAIで行い、RDRASheetで手直しする

• 既存システムの可視化

  • 入出力資料からAIがRDRAを定義し、RDRAGraphで可視化

• 仕様駆動開発

  • 要件から仕様をAIで生成し、仕様を元に実装する

• 見積り

  • UCベースの見積もり根拠に使う

生成に使用するモデルを変更する場合は「モデル設定.json」を変更します。providers内のプロバイダーの名前を「default/provider」デフォルト設定に記述すると実行するモデルを変更できます。プロバイダーの設定内に具体的なモデル名を設定する

ClaudeとCursorが利用でき、デフォルトでClaudeが設定されている

「モデル設定.json」のProvider設定をAIを使って追加することで、Codex、Geminiなどを追加可能

RDRAAgentは早いモデル「Claude Haiku」をデフォルトで開発した

• Terminal上でプロジェクトフォルダーをカレントフォルダーにする

• 「node menu.js」を実行し、メニュー番号を入力

  • １~3：４つのフェーズでRDRA定義を行う

  • 11,12：RDRA定義からGraph表示、RDRASheetへ連携

  • 21,22：非アーキテクチャ依存仕様の生成

  • 31-33：仕様駆動開発用の仕様の生成

  • 34：仕様のCallgraphを表示

• 初期要望を作成

  • その時点で分かることを作成

  • 初期要望からRDRA定義を作成しRDRAGraphで全体を俯瞰

  • 初期要望を見直し、再実行し洗練化する

  • 顧客との打ち合わせを全体俯瞰した中で進める

  • 一通りのRDRAの要素が揃ったらRDRASheetに移行

初期要望に既存システムの機能一覧や画面一覧を記述することで、業務やアクター、外部システムなどの上流のたたき台を生成する

• 機能や画面などの下流の資料から上流の資料を生成する

• ボトムアップとトップダウンの分析で詳細な情報から業務やシステム全体を俯瞰できる

• 仕様駆動開発のための初期の仕様をRDRAから作成する

  • 仕様のたたき台を自動作成し、実装しながら仕様を改善する

• RDRAとのトレーサビリティを維持して仕様を作成

  • RDRAの構成要素単位に仕様を分割する

• ある程度CodeができたところでVibe Coding に移行する

• 最初から完全な初期要望を目指さない

• その時点で分かることを記述し、AIの生成結果を確認し見直す

• 初期段階ではRDRAZeroOneの中間成果物から初期要望の解像度を上げる

• RDRAの構成要素が揃った段階で、RDRAGraphから初期要望を見直す

メニュー１１：RDRAGraphで定義内容を把握する

メニュー１２：RDRASheetで定義の詳細を詰める

Claude CodeまたはCursorなどのCLIでProjectのフォルダーを作業フォルダーにして以下の問合せを行う

RDRA定義の内容を自然言語で問い合わす。

　「窓口担当者がこのシステムから得られるメリットは？」

定義内容から必要な情報を抜き出す

　「窓口担当者が使う画面の一覧を出力してください」

• RDRA定義の各画面について項目を生成し、要件定義時にイメージを確認する

• BUC/アクター毎とアクター毎の２つの切り口から画面の項目が確認できる

• メニュー22番でサーバーを実行し、Browserに画面を表示します

※この生成は重い処理なのでモデルによっては途中で止まったり、画面項目が出力されないことがあります。

• RDRAの情報構造を具体的な構造として把握する

• Entitiy間の多重度や属性名から具体的なデータ構造を把握する

• MarkdownにMarmaid形式で出力する

• Marmaidを表示できるビューワーを利用する

たたき台として活用する

条件の仕様化は一気にハードルが高くなるので、たたき台があることで立ち上がりが一気に早くなる

• RDRAで示した条件の具体的な例として参照する

• Markdown形式で全ての条件の詳細が出力されるので、そこから成形する

イベントの詳細を定義し、Code生成用の仕様に反映する

• 連携項目

• 連携手段

• データ連携方向

• RDRASddのアプリケーションサービス内での外部システムとの連携に参照される

• Domain：

  • システムレイヤーのコンテキストをドメインとする

  • コンテキスト単位に仕様ファイルを生成

• Application：

  • システム境界レイヤーのUCをApplicationレイヤーとする

  • BUC単位に仕様ファイルを生成

• UI：

  • システム境界レイヤーの画面をUIレイヤーとする

  • BUC単位のフォルダー内に画面単位のファイルを作成

• application

  • BUC単位の定義ファイルの中で複数のUCを定義

  • UC内にアプリケーションサービスを定義

• domain

  • コンテキスト単位のファイルの中に複数のドメインサービスを定義

• ui

  • BUC単位のフォルダーを定義

  • フォルダー内に画面単位のファイルを定義

機能仕様は量が多くなるので、選択された仕様を表示し３レイヤーの繋がりを可視化する

• CallGraph

  • UI：画面アイコンを表示

  • Application：UCアイコンを表示

  • Domain：サービスアイコンとEntity

• 選択された仕様を表示

• 3_RDRASddフォルダー内のJSONファイルから直接Diagramを作成する

• 開発プロジェクトを作成し3_RDRASddフォルダーをコピーする

• AGENT.md

  • プラットフォーム、言語、フレームワーク、ライブラリ～

  • 設計方針

• プロジェクトの方針に従って作業指示して再生成

• 作業指示、RDRASdd仕様、システムアーキテクチャからCodeを生成する

• 複数の仕様にまたがる仕様の見直しはRDRASpecを見直す

• 生成されたCodeをVibe Codingする

素早く実装が開始出来るように実装用のProjectを準備

• 開発用のProjectをSampleフォルダー内のProjectフォルダーからコピーする

• コピーしたProjectに「2_RDRASpec」「3_RDRASdd」フォルダーをコピーする

• AGENTS.mdの内容を見直す

  • 最低限度の設定なので追記する

  • コード生成のルールを追加する

  • 言語、フレームワーク、ライブラリなどの指定