最初のプロジェクト
このガイドでは、民泊管理システムにおける「客室予約およびポイント利用による注文」という要件を題材に、Toco AI のコアプロセスを実践形式で学びます。これにより、AI時代のモデリング駆動開発 (Model-Driven Development) の考え方を素早く理解することができます。
業務背景: 会員が部屋タイプと数量をカートに入れた後、一括で注文を行います。システムは空室状況を検証し、在庫が十分であれば支払いを確定して予約完了の注文を生成します。同時にポイントを減算し、利用明細を記録します。
前提条件
- Toco AI IntelliJ IDEA プラグイン の インストールと設定 が完了していること。（VS Code プラグインは現在開発中です。）
Toco プロジェクトの新規作成
Toco 独自の モデリング駆動開発 (MDD) 機能は、Toco Project 内でのみ利用可能です。現在は Java Spring エコシステムをサポートしており、対応言語は順次拡大予定です。
注：通常のプロジェクトでは、Toco は従来の AI Coding アシスタント として機能します。
要件ドキュメントの入力
Agent Chat ウィンドウに、要件ドキュメントを添付ファイルとして入力します。
ドメインモデリング
AI アーキテクト (Domain Architect) が要件に基づき、ドメインモデル（ER図、値オブジェクト、集約など）を自動生成します。
- 本例のコア: 「注文情報」という集約（注文メインテーブル
booking_order、注文明細テーブルorder_itemなどを含む）。 - 柔軟な修正: チャットでの対話を通じて Toco に修正を依頼したり、ビジュアルエディタで手動調整したりすることが可能です。
Tips：設計モデルの確認
チャットボックス内の Toco アイコン をクリックすると、いつでも全モジュールのドメインモデルやサービスモデルの確認・編集画面にアクセスできます。
要件の分解
Toco Agent が要件を複数の API に分解します。
- 現在のセッションでこれらのAPIを一括処理するか、Todoリスト に入れて後で処理するかを選択できます。Todoリスト内のAPIは手動で編集可能です。
Tips：Todo管理
チャットボックスの Todoアイコン から、いつでも全てのタスクを確認できます。完了したタスクは手動で完了ステータスに変更します。
独立セッションでのAPI実装
Todoリストから「カートに基づいた注文作成」インターフェースを選択し、独立したセッション を開始します。
注：複数のAPIを1つのセッションで処理することも可能ですが、コンテキストを減らして回答精度を高めるため、複雑なインターフェースは個別のセッションで扱うことを推奨します。
設計プランの策定
- Planner Agent が初期の詳細設計を行います。これにはAPIの入出力パラメータ、処理フロー、Read/Write経路の予備設計などが含まれます。
- 内容確認後、Designer Agent がプランに基づき、関連するサービスモデリングを完了させます：
- リードモデル (Read Model)：
- Toco-DTO（サービス転送オブジェクト）：外部キーに基づいて拡張された、複数テーブルを集約したデータ構造です。例：「部屋タイプ詳細DTO」の中に、その部屋タイプに紐づく注文明細リストを組み込みます（外部キー
room_type_idを介したオブジェクト拡張）。
- Readプラン：DTOを戻り値とし、オブジェクト指向的なクエリ方式で、効率的なクロス検索をサポートします。例：
- ID、コード、総部屋数などの条件で部屋タイプをフィルタリング：
id in #roomTypeIdListANDroom_type_code in #roomTypeCodeInANDtotal_quantity >= #totalQuantityBiggerThanEqual - 特定の日付範囲内の有効な注文明細を同期的に取得：
filter orderItemList:order_item_status in #orderItemListOrderItemStatusIn AND order.check_in_date >= checkInDateBiggerThanEqual AND order.check_out_date <= checkOutDateLessThanEqual
- ID、コード、総部屋数などの条件で部屋タイプをフィルタリング：
- Readプランは効率的なReadモデリング表現です：戻り値、クエリ方法、データ組み立て方法、入力パラメータ、対応するService/APIを同時に確定させます。
- Toco-DTO（サービス転送オブジェクト）：外部キーに基づいて拡張された、複数テーブルを集約したデータ構造です。例：「部屋タイプ詳細DTO」の中に、その部屋タイプに紐づく注文明細リストを組み込みます（外部キー
- ライトモデル (Write Model)：集約オブジェクト指向の業務変更とトランザクションロジックを定義します。例：「注文」フローにおいて、Writeプランを通じて注文および明細の作成（Writeプラン1）、ポイント減算と利用明細記録（Writeプラン2）などの操作を同期的に実行します。
- 【Writeプラン1】注文および明細の作成：2つのテーブル（
booking_order,order_item）のレコード同時作成を記述します。
- 【Writeプラン2】ポイント減算と利用明細記録：
memberのポイント更新と同時に、対応するpoints_transactionレコードの作成を記述します。
- 【Writeプラン1】注文および明細の作成：2つのテーブル（
- Writeプランは効率的なWriteサービスモデリング表現です：入力パラメータ、対応するService/API、対象となる業務オブジェクト、変更方法を同時に確定させます。
- リードモデル (Read Model)：
コード生成：80:20 の法則
Toco には M2C (Model To Code) エンジン が内蔵されており、コードは以下の2つの部分に分けて生成されます。
- 構造コード (約 80%)： エンジンが上記のすべてのモデリング情報に基づいて直接生成します。DDD および CQRS 規範に準拠しており、アーキテクチャは標準的かつ100%正確であるため、人手によるレビューは不要です。
- グルーコード (約 20%)： Developer Agent が残りのビジネスロジックを記述します。ユーザーはこの「グルーコード（接着コード）」部分（例：予約したい部屋数が確保可能か、ポイントが不足していないかの判定、誕生日クーポンのロジックなど）をレビューするだけで済みます。
実行とテスト
- データベース同期： スキーマ同期 (Schema Sync) と管理を自動/手動で行います。
- Mock テスト：Toco の内蔵ツールを使用して、APIロジックを直接検証できます。