最初のプロジェクト
このガイドでは、民泊管理システムにおける「客室予約およびポイント利用による注文」という要件を題材に、TocoAI のコアプロセスを実践形式で学びます。これにより、AI時代のモデリング駆動開発 (Model-Driven Development) の考え方を素早く理解することができます。
業務背景: 会員が部屋タイプと数量をカートに入れた後、一括で注文を行います。システムは空室状況を検証し、在庫が十分であれば支払いを確定して予約完了の注文を生成します。同時にポイントを減算し、利用明細を記録します。
プロジェクトの準備
前提条件
- TocoAI プラグインのインストールと設定：IntelliJ IDEA プラグイン または VS Code 拡張機能 が完了していること。
プロジェクトモードの選択
Toco プロジェクト以外の環境で TocoAI のチャットパネルを初めて開くと、モード選択画面が表示されます。
- DSL-Spec モード：モデル駆動開発（MDD）を中核としたモード。新規の Java バックエンドプロジェクトに最適で、設計からコード生成までを標準化されたフローで進めます。
- Vibe モード：既存のコードベースに対して、AI と対話しながら直接コーディングを進めるモード。多言語・多スタックに対応し、柔軟に開発できます。
注意： モードは選択後の変更はできません。DSL-Spec は Toco プロジェクト作成後に固定され、Vibe は選択と同時に固定されます。モデリング機能を利用する場合は、DSL-Spec を選択してください。
Toco プロジェクトの新規作成
Toco 独自の モデリング駆動開発 (MDD) 機能は、Toco Project 内でのみ利用可能です。現在は Java Spring エコシステムをサポートしており、対応言語は順次拡大予定です。
注：通常のプロジェクトでは、Toco は従来の AI Coding アシスタント として機能します。
VS Code での Toco プロジェクト作成方法：新しいウィンドウを開く（File ➔ New Window メニュー）➔ TocoAI アイコンをクリック ➔ プロジェクトを作成。
要件ドキュメントの入力
Agent Chat ウィンドウに、添付ファイルとして要件ドキュメントを入力します。
分析とモデリング
要件分析
新規プロジェクト、モジュールをまたぐフロー、または主要な業務ルールやシステム境界を先に揃える必要がある要件では、System Analyst が業務目標、システムのエントリーポイント、主要ルール、状態変化、主なフローを整理し、レビュー可能な要件分析を作成します。この工程はすべてのタスクで必須ではありません。既存のコンテキストが十分で、実施対象が明確な場合は、モデリング、ToDo 作成、プランニングへ直接進むことができます。本例では、分析結果を確認して修正を依頼でき、確定した結論が後続工程で共有する要件の基準になります。
業務知識の蓄積
長期的な業務知識は、DSL Spec の構造化された設計情報を補完するものです。モデルの詳細を重複して記録せず、全体的な背景、共通用語、主要ルール、中心的なステートマシンなど、複数の要件で再利用できる重要な業務情報だけを保持します。この知識は、要件と実装の進行に合わせて Agent のフローが自動的に保守します。生成された結果を確認して受け入れることで、後続のセッションでも同じコンテキストを再利用できます。
ドメインモデリング
AI アーキテクト (Domain Architect) が要件に基づき、ドメインモデル（ER図、値オブジェクト、集約など）を自動生成します。
- 本例のコア: 「注文情報」という集約（注文メインテーブル
booking_order、注文明細テーブルorder_itemなどを含む）。 - 柔軟な修正: チャットでの対話を通じて Toco に修正を依頼したり、ビジュアルエディタで手動調整したりすることが可能です。
Tips：設計モデルの確認 チャットボックス内の Toco アイコン をクリックすると、いつでも全モジュールのドメインモデルやサービスモデルの確認・編集画面にアクセスできます。
要件の分解
Toco Agent は、確認済みの要件を、個別にプランニング、開発、結合、受け入れ確認できる ToDo に整理します。ToDo は、API、定期実行ジョブ、メッセージ、コールバック、共通機能などの実行単位として作成されます。
- 各 ToDo には、業務目標、主要ルール、完了時の結果、対象となる業務シナリオが記載されます。
- 優先度は推奨する実装順序、複雑度は実装リスクと作業量を表し、それぞれ独立して評価されます。
- ワークベンチへ追加する前に ToDo をレビューして調整でき、追加後もワークベンチから継続して管理できます。
プランニングと開発
独立セッションで ToDo を実行
ワークベンチから ToDo を選択し、独立したセッション を開始します。ToDo リストを閉じた後でも、右下のボタンからリストを再度開き、実行する ToDo を選択できます。確定済みの目標、ルール、コンテキストがタスクとともに引き継がれるため、後続のプランニングを現在の実行単位に集中させることができます。
注：関連性の高い複数の ToDo は同じセッションで処理できますが、複雑なタスクを一度に追加しすぎないでください。コンテキストを絞ることで、より良い結果を得られます。
設計プランの策定
Planner Agent は、現在の要件コンテキスト、プロジェクト知識、既存の設計とコードを組み合わせ、レビュー可能な実装プランを作成します。プランには、目的、現状、影響範囲、主要な依存関係、リスク、次に担当する Agent、実行項目が整理されます。確認後は、設計、開発、テストが連携を続けるための共通コンテキストになります。
サービス設計
内容確認後、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、対象となる業務オブジェクト、変更方法を同時に確定させます。
コード生成：80:20 の法則
Toco には M2C (Model To Code) エンジン が内蔵されており、コードは以下の2つの部分に分けて生成されます。
- 構造コード (約 80%)： エンジンが上記のすべてのモデリング情報に基づいて直接生成します。DDD および CQRS 規範に準拠しており、アーキテクチャは標準的かつ100%正確であるため、人手によるレビューは不要です。
- グルーコード (約 20%)： Developer Agent が残りのビジネスロジックを記述します。ユーザーはこの「グルーコード（接着コード）」部分（例：予約したい部屋数が確保可能か、ポイントが不足していないかの判定、誕生日クーポンのロジックなど）をレビューするだけで済みます。
技術知識の蓄積
技術知識の蓄積は、通常、Developer Agent が実装を完了した後に行われます。Agent のフローは、まだ実現されていない構想ではなく、実際に実装・確認された技術的事実に基づいて、再利用可能な共通フレームワーク、連携上の制約、技術規約を長期知識として蓄積します。生成された知識のインデックス、概要、個別機能の説明を確認し、問題がなければ成果物を受け入れます。これらの知識は後続のプランニング、開発、テストで再利用されます。
テストと検証
ユニットテスト
Tester Agent： API 契約と業務ルールに基づいて API レベルの Mock ユニットテストを設計・実行し、必要なテストデータとアサーションを含むテストコードを生成します。実際の業務ロジックは可能な限りテスト対象とし、データベースや外部サービスなどの依存先は Mock 化するため、実データベースへの接続や実際の外部サービス呼び出しは不要です。本番コードや業務ロジックの問題を検出した場合は、失敗の根拠をプランニングと開発工程へ戻します。現在は API レベルの Mock テストに対応しており、今後は結合テスト機能も拡充する予定です。