---
title: Architectパイプライン
description: /architect:* の新規開発(グリーンフィールド)/既存改修(レガシー)の2つの進め方と、品質チェック・レビュー系スキルの一覧
seo:
  image: /ogp.png
---

Architectパイプラインには2つの経路があります。ひとつは新規開発の経路(グリーンフィールド経路)、もうひとつは既存システムを改修する経路(レガシー経路)です。

**グリーンフィールド経路**

この経路は、真新しいプロダクトやシステムを一から作るとき(新規開発)に使います。

```mermaid
flowchart LR
  A[define-requirements] --> B[map-domains] --> C[design-api] --> D[design-implementation]
  D --> E[generate-scalardb-code]
  D --> F["generate-infra-code など"]
```

<Accordion>
  <AccordionItem title="/architect:define-requirements — 要件定義(opus)">
    出力は要件定義書・データ&トランザクション要件・ScalarDB適用可否評価・Open Questionsの4文書(`--no-scalardb`指定時は3文書)。グリーンフィールド経路の入口で、レガシー経路では`investigate`の後に実行することもできます。

    1. **資料を読み込み、ギャップを洗い出す**

        RFP・議事録・既存設計書などの入力資料と既存コードベースを読み、テンプレートの各項目が「資料で答えられている」か「未回答」かを仕分けます(ギャップリスト)。productパイプラインの成果物があれば自動で取り込み、product→architectの引き継ぎとして扱います。

    2. **ギャップだけを聞く**

        ギャップリストにある項目だけを、2〜4択の候補とともに質問します。答えを保留する場合だけ「TBD」として記録し、要件を推測で埋めることはありません。

    3. **FR/NFRとして分類する**

        `FR-xxx`/`NFR-xxx`のIDと優先度を割り振り、業務プロセスごとにデータの一貫性要件(強一致・結果整合・ローカルトランザクション)を判定します。

    4. **ScalarDBの適用可否を評価する**

        決定木に従い、ScalarDBまたはScalarDB Sagaが向くかを判定します(`--no-scalardb`でスキップ可)。最終決定は`select-scalardb-edition`に委ねます。
  </AccordionItem>

  <AccordionItem title="/architect:map-domains — ドメインマッピング(opus)">
    `analyze`の分析結果をもとに、ドメインをCore/Supporting/Genericの3種類に分類し、業務の構造パターン(Pipeline/Blackboard/Dialogue/Hybrid)とマイクロサービス境界の種類(Process/Master/Integration/Supporting)を識別します。

    各境界コンテキストは9項目のBounded Context Canvasとして記述され、product側の`map-domains`が書く同形式のCanvasと項目ごとに比較できます。

    productパイプラインにも同名のスキルがありますが、そちらはビジネス機能から境界コンテキストを抽出するもので、入力と目的が異なります。
  </AccordionItem>

  <AccordionItem title="/architect:design-api — API設計(opus)">
    出力はOpenAPI/GraphQL/gRPC/AsyncAPIの仕様ファイル群です。ここで書く仕様は**契約そのもの**であり、後工程のコードはこの契約を超えて実装できません。

    | 決めること | 内容 |
    |---|---|
    | プロトコル選定 | REST/GraphQL/gRPC/AsyncAPIを、利用者の多様性や操作の形から選ぶ(サービス名やDB製品だけでは選ばない) |
    | トランザクション配置 | 各操作がACIDトランザクション内・Sagaのステップ・ローカルのどれに属するかを明記 |
    | 認可ルール | 操作ごとに必要なロール/スコープと、オブジェクト所有権の判定条件を明記(未定義のまま下流に渡すと「誰でも呼べる」として扱われる) |
    | エラー形式 | RFC 9457(Problem Details)形式に統一し、プロジェクト全体でエラー形式を1つに保つ |

    すべての操作に`operationId`・名前付きスキーマ・全ステータスコード・認可ルール・(必要な場合の)Idempotency-Key(同じリクエストを再送しても安全にする識別子)が揃っていることを検証してから完了します。
  </AccordionItem>

  <AccordionItem title="/architect:design-implementation — 実装設計(opus)">
    出力はコーディング可能な粒度の実装仕様(API層・ドメインサービス・リポジトリインターフェース・値オブジェクト・例外マッピング)です。

    - API層仕様は、`design-api`の各操作(operationId)を「どのクラスが受け、どのDTOで受け取り、どう検証し、どこでトランザクションを開くか」まで1対1で対応づけます。リクエストDTOはドメインオブジェクトや永続化エンティティと同一にしません(マスアサインメント脆弱性の防止)。
    - 例外マッピングは「内部(インフラ例外→ドメイン例外)」と「外部(ドメイン例外→RFC 9457レスポンス)」の2種類を別々に定義します。
    - `--layering=ddd|clean`で実装層の語彙を選べます。`clean`はoperationIdごとに1つのUse Case(入力バウンダリ)+Interactorを置き、`api/presenter/`配下にPresenter(出力バウンダリ)を持つClean Architecture形式です。選択は`api-layer-spec.md`のfrontmatterに`layering_style`として1回だけ書かれ、以降のすべての生成スキルがそこから読みます。リポジトリはどちらの形式でもDDDの命名とドメイン所有権を保ちます(集約マニフェスト・Fake・カバレッジ閾値がそれに紐づくため)。
  </AccordionItem>

  <AccordionItem title="/architect:generate-scalardb-code — ScalarDBコード生成(opus)">
    出力はSpring Boot + ScalarDBのJavaコード(エンティティ・リポジトリ実装・ドメインサービス・Spring Boot設定・build.gradle・Dockerfile)です。`design-implementation`と`design-scalardb`の仕様から生成します。

    - 担当するのは**domain/infrastructure**パッケージのみ。`api/`パッケージ(コントローラ・DTO)は`generate-api-code`が担当し、両方を実行してはじめて1サービスが完成します。
    - コードを書く前に、対象のScalarDBバージョン/エディションのナレッジバンドルを解決し、非推奨(deprecated)かどうかは実際のjarやリリースノートで検証します(テンプレートの記載を鵜呑みにしません)。
  </AccordionItem>

  <AccordionItem title="/architect:generate-infra-code — インフラコード生成(sonnet)">
    出力は`generated/infrastructure/`配下のKubernetesマニフェスト(Kustomize)・Terraformモジュール・Helm values・**品質ゲートを実行するCIワークフロー**です。

    このパイプラインの一工程として、設計から**足場となるコード(スキャフォルディング)**を生成する点が、`/infra:implement`(実際のインフラリポジトリへの、マージ前提のコードの書き込み)との違いです。詳しくは[infraプラグイン](/skills/infra)を参照してください。

    生成するCIワークフローはbuild/unit/contract/integration/sast/dependency-scan/image-scanの7ジョブ(+モデル駆動で行う2段階)を持ち、`continue-on-error`のようなゲートの無効化は禁止されています。
  </AccordionItem>

  <AccordionItem title="/architect:generate-docs — ドキュメント生成(sonnet)">
    `generate-scalardb-code`・`generate-infra-code`・`generate-frontend`の後、または`implement-backlog`のドキュメント作成ステップとして実行し、生成・実装されたコードに対する各READMEと`docs/`配下のページを作ります。

    - 再実行しても安全なように、生成した範囲を`<!-- nexus:begin:... -->`のような**所有マーカー**で区切ります。マーカー内だけを再生成し、人が書いた文章はそのまま残します。マーカーの無い既存のREADMEは、確認を得たうえで新しいセクションとして追記します(手書きの文章を上書きしません)。
    - コードと設計書の内容が食い違っている場合、取り繕わずfindingとして報告します。
  </AccordionItem>
</Accordion>

**レガシー経路**

この経路は、既存のシステムを調べ直し、改修や再設計を行うときに使います。

```mermaid
flowchart LR
  A[investigate] --> B[analyze]
  B --> C[evaluate-mmi]
  B --> D[evaluate-ddd]
  C --> E[integrate-evaluations]
  D --> E
  E --> F[redesign] --> G[design-microservices]
```

<Accordion>
  <AccordionItem title="/architect:investigate — 既存システムの調査(sonnet)">
    レガシー経路の最初のステップです。技術スタック分析・コードベース構造・課題と技術的負債(CRITICAL/High/Medium/Lowで重大度分類)・DDD(ドメイン駆動設計)適用への準備状況、の4文書を作ります。
  </AccordionItem>

  <AccordionItem title="/architect:analyze — ドメイン分析(opus)">
    `investigate`の結果をもとに、業務の用語辞書(ユビキタス言語。同じ言葉が指す意味をチーム全体で統一するための対応表)・アクター/ロール/権限マトリクス・ドメインとコードの対応表を作ります。
  </AccordionItem>

  <AccordionItem title="/architect:evaluate-mmi — MMI評価(sonnet)">
    `analyze`の後、`evaluate-ddd`と並列実行できます。モジュールごとに凝集度(Cohesion)・結合度(Coupling)・独立性(Independence)・再利用性(Reusability)の4軸を5点満点で評価し、重み付き平均(凝集度30%・結合度30%・独立性20%・再利用性20%)からMMI(Modularity Maturity Index。モジュールの分割しやすさを示す指標)を算出します。

    | MMIスコア | 成熟度 |
    |---|---|
    | 80〜100 | Ready(移行可能) |
    | 60〜80 | Moderate |
    | 40〜60 | Needs Improvement |
    | 0〜40 | Immature |
  </AccordionItem>

  <AccordionItem title="/architect:evaluate-ddd — DDD適合度評価(sonnet)">
    `evaluate-mmi`と並列実行できます。戦略的設計(30%。ユビキタス言語・境界コンテキスト・サブドメイン分類)・戦術的設計(45%。値オブジェクト・エンティティ・集約・リポジトリ・ドメインサービス・ドメインイベント)・アーキテクチャ(25%。層構造・依存方向・ポート&アダプター)の3レイヤー12基準で、DDDへの適合度を採点します。
  </AccordionItem>

  <AccordionItem title="/architect:integrate-evaluations — 評価の統合(sonnet)">
    `evaluate-mmi`と`evaluate-ddd`の結果を統合し、マイクロサービス化に向けた1つの改善計画にまとめます。
  </AccordionItem>

  <AccordionItem title="/architect:redesign — 境界コンテキストの再設計(opus)">
    評価結果にもとづき、新しい境界コンテキスト案(各コンテキストの責務・含まれる集約・公開インターフェース)と、コンテキスト間の関係(ACL・OHS・Conformistなど、DDDのコンテキストマップパターン)をMermaid図で作成します。

    ここでArchitecture Decision Records(ADR)のログも開き、`ADR-`のID体系を登録します。以降`design-microservices`・`design-scalardb`/`design-data-layer`・`design-api`が同じログに追記していきます(他スキルの記録を書き換えず、撤回する場合は新しいレコードで"supersede"します)。
  </AccordionItem>

  <AccordionItem title="/architect:design-microservices — マイクロサービス設計(opus)">
    サービスカタログ(Process/Master/Integration/Supportingの4分類)と段階的な移行ロードマップを作成します。

    サービス間トランザクションは、既定で「Saga/2PC」と決めつけず、次のどれを使うかを明示して`design-scalardb`に引き渡します。

    | 仕組み | 構成 |
    |---|---|
    | 1フェーズコミット | 全サービスが同じScalarDB Clusterインスタンスを共有する構成(可能な限り推奨) |
    | Global Transaction API(3.19+) | クラスタを分けつつ、Transaction Coordinatorノードが2PCを裏側で担う |
    | アプリケーション駆動2PC | Coordinatorノードなしでクラスタを分ける場合。2〜3サービスまでに留める |
    | ScalarDB Saga | 補償(コンペンセーション)による結果整合。Sagaを使う場合の設計は@rules/scalardb-saga-patterns.mdを参照 |
  </AccordionItem>
</Accordion>

## ドメインモデリングの詳細化系(任意)

境界コンテキストが定まった後、実装に進む前に集約とライフサイクルを固めるための任意フェーズです。DDD(ドメイン駆動設計)の戦術的な部分を、レビュー可能なJSON成果物として明文化します。集約リストがないと状態遷移を設計できないため、`design-aggregate`→`design-state-machine`の順に実行します。

<Accordion>
  <AccordionItem title="/architect:design-aggregate — 集約設計(opus)">
    出力は`reports/03_design/aggregates/aggregate-manifest.json`(`AGG-`ID)です。集約ごとに、ルート・内部エンティティ・値オブジェクト・不変条件(成立/違反の両方を具体例つきで)・コマンド(実行者・一貫性クラス・発行イベント)・ファクトリ・仕様(Specification)・1集約1リポジトリを定義します。

    「1コマンド=1集約=1トランザクション」の原則を含む7つの整形式ルールを`rules/aggregate-design.md`が定め、`tools/lib/aggregate_manifest.py`が検証します。この集約リストは後続の`design-state-machine`のライフサイクル候補になり、`design-scalardb`/`design-data-layer`・`design-api`・`design-implementation`・`generate-test-specs`・`review-consistency`・`report`が成果物を読みます。

    集約が発行するイベントは、Domain Event Catalog(`reports/03_design/domain-event-catalog.json`/`.md`)としても書き出されます。コンテキストマップのPublished Language(公開された言語)そのもので、発行者・購読するコンテキスト・配信契約(保証レベル・冪等性キー・バージョン)を記録します。`design-microservices`がサービス分割確定後に購読側を完成させ、`design-api`のasyncapi/はこのカタログから生成されます。
  </AccordionItem>

  <AccordionItem title="/architect:design-state-machine — 状態遷移設計(opus)">
    出力は`reports/03_design/state-machines/state-machine-manifest.json`です。ライフサイクルを持つ集約ごとに、状態・イベント・遷移(`(from, event) [guard] → to`。実行者・一貫性クラス・冪等性判定つき)を定義し、**状態×イベントの全マス**を`reject`/`ignore`/`defer`のいずれかで決め切ります(空欄を実行時の判断に委ねません)。

    - 集約を生成するイベント(`place`・`open`・`register`など)は`from`状態を持たない特別な列として扱われ、そのidempotency判定はAPIの冪等性契約から機械的に決まります。
    - 誰と誰が同じ集約に競合するか(オーケストレータ対リカバリワーカー、リクエスト経路対スイーパーなど)を1行ずつ書く「競合テーブル」も作ります。行がない組は「誰も設計していない競合」を意味します。
    - `tools/lib/state_machine_manifest.py`(29項目)が、初期状態が1つだけ・全状態が到達可能・未宣言のデッドエンドがない、といった整形式ルールを検証します。`design-scalardb`/`design-data-layer`・`design-api`・`generate-test-specs`・`review-consistency`・`report`がこのモデルを読みます。
  </AccordionItem>
</Accordion>

## テスト生成系

TDD(テスト駆動開発)を実装の前提に置くための2つのスキルです。`rules/tdd-workflow.md`が定めるRed→Green→Refactorのコミット単位・ATDD(受入テスト駆動開発)の外側ループ・Fake(リポジトリごとの1つのインメモリ実装)という構造を`implement-backlog`・`generate-scalardb-code`が実践し、品質ゲート(Stage 2)がカバレッジ(JaCoCo)・ミューテーションスコア(PIT)・test-firstの実施記録を測定します。

<Accordion>
  <AccordionItem title="/architect:generate-characterization-tests — 特性テスト生成(レガシー経路、sonnet)">
    出力は、稼働中のレガシーシステムから記録したゴールデンマスターテスト(モジュールごとのSeam一覧、コードが実際に出力した値をそのまま使うフィクスチャ、既知の不具合を壊さず固定する`@KnownDefect(DEBT-xx)`マーカー)と`reports/07_test-specs/characterization-test-coverage.md`です。

    `design-microservices`の移行計画は、各変換ステップにこの特性テストゲートを必須で紐づけるようになりました。既存の振る舞いを壊さずに変換を進めるための安全網です。
  </AccordionItem>

  <AccordionItem title="/architect:generate-acceptance-tests — 受入テスト生成(sonnet)">
    出力は、`reports/07_test-specs/`のGherkinシナリオ(`RULE-`/`EX-`に紐づく)に対応するCucumber-JVMのステップ定義と`reports/07_test-specs/acceptance-test-coverage.md`です。Fakeを使ったAPI/アプリケーション層のドライバと、固定した`Clock`で実行します。

    まだ実装が届いていないシナリオには`@wip`タグを付け、合否判定からは除外しつつ件数としては記録します。`rules/tdd-workflow.md`のATDD外側ループを実行可能にするスキルです。
  </AccordionItem>
</Accordion>

## 品質・運用系

本番での運用を見据えて、セキュリティ・監視・災害対策・コストを設計するためのスキル群です。

| スキル | 何を設計するか |
|---|---|
| `design-security` | 認証・認可・シークレット管理・ネットワーク・テナント分離。OWASP API Security Top 10への対応も見る |
| `design-observability` | 監視・分散トレーシング(処理が複数サービスをまたぐときの追跡)・ログ集約・アラート |
| `design-disaster-recovery` | RTO/RPO(復旧までの目標時間・失ってよいデータ量)・バックアップ・フェイルオーバー・復旧手順 |
| `estimate-cost` | クラウドインフラ・ScalarDBライセンス・運用コストの見積もりと、サイジング(必要な規模の算定) |

<Accordion>
  <AccordionItem title="/architect:design-security — セキュリティ設計(sonnet)">
    出力: 認証基盤(OAuth2/OIDC、サービス間mTLS)・認可モデル(RBAC/ABAC。ロール単位だけでなく**オブジェクト単位**の認可も含む)・テナント分離モデル・シークレット管理(Vault/KMS、ローテーション戦略)・ネットワークセキュリティ(ゼロトラスト、セグメンテーション)・データ分類(どの項目が機密で、APIレスポンス/ログ/エラー詳細に出してよいか)・監査ログ・コンプライアンスチェックリスト。OWASP API Security Top 10への対応も見ます。
  </AccordionItem>

  <AccordionItem title="/architect:design-observability — 可観測性設計(sonnet)">
    出力: SLI/SLO定義(サービス単位、ビジネスKPIと紐づけ)・分散トレーシング(OpenTelemetry。複数サービスをまたぐ処理をcorrelation IDで追跡)・ログ集約・メトリクス(RED/USE方式)・アラート設計・ScalarDB固有のメトリクス(トランザクション成功率、OCC競合率)。ScalarDB Sagaを使う場合は、サガの状態別件数や補償失敗率も追加します。
  </AccordionItem>

  <AccordionItem title="/architect:design-disaster-recovery — 災害対策設計(sonnet)">
    出力: サービス階層別のRTO/RPO(復旧までの目標時間・失ってよいデータ量)・バックアップ戦略(頻度・保持期間・復元テスト計画)・フェイルオーバー設計(リージョン間・AZ間)・データ復旧手順(ScalarDBのCoordinatorテーブルを含む)・障害シナリオ別のランブック・カオスエンジニアリング(意図的に障害を起こして耐性を確認する手法)を含む復旧テスト計画。
  </AccordionItem>

  <AccordionItem title="/architect:estimate-cost — コスト見積もり(sonnet)">
    出力: クラウド基盤費用(AWS/Azure/GCPのコンピュート・ストレージ・ネットワーク)・ScalarDBライセンス費用(エディション別、直接契約かAWS Marketplace経由か)・運用費用(監視ツール・サポート・人件費)・ScalarDBのサイジング(Pod数・クラスタ構成・DB容量)を多面的に見積もります。
  </AccordionItem>

  <AccordionItem title="/architect:design-infrastructure — インフラ論理設計(opus)">
    出力: Kubernetesクラスタ構成(ノードプール・リソースクォータ・namespace戦略)・コンテナオーケストレーション(デプロイ戦略・HPA・PDB)・ネットワーク設計(mTLS・NetworkPolicy・Ingress/Gateway)・IaC構成(Terraformモジュール・state管理)・複数環境戦略(dev/staging/prod、Kustomizeオーバーレイ)。ScalarDB Cluster使用時はHelmチャート構成とCoordinatorの配置も設計します。

    出力はあくまで**論理設計**で、[infraプラグイン](/skills/infra)の`/infra:design`が同じ領域をマルチクラウド前提の具体設計に落とし込みます(下のPanelを参照)。
  </AccordionItem>
</Accordion>

<Panel title="クラウド基盤を実際に構築する場合">
`design-infrastructure`・`generate-infra-code`・`review-operations`は論理設計やスキャフォルディングまでを担当します。
Terraform/Kubernetes/CIを実際のインフラリポジトリに実装・レビューするところからは、別プラグイン[infra](/skills/infra)の範囲です。
</Panel>

## レビュー系(並列実行可能な視点群)

設計や実装を複数の視点からチェックするスキル群です。それぞれ独立して(並列で)実行でき、最後に
`review-synthesizer`が全部の結果をまとめて、このまま進めるかどうか(Go/No-Go判定)を出します。

```mermaid
flowchart LR
  A[review-consistency] --> F[review-synthesizer]
  B["review-scalardb / review-data-integrity"] --> F
  C[review-operations] --> F
  D[review-risk] --> F
  E[review-business] --> F
  F --> G["Go/No-Go判定"]
```

| スキル | どの視点で見るか |
|---|---|
| `review-consistency` | 構造の一貫性・トレーサビリティ・用語の統一 |
| `review-operations` | 監視・災害対策・セキュリティ姿勢・デプロイの安全性 |
| `review-risk` | 分散システムのリスク・故障モード・Saga設計(分散トランザクションを補償で実現する方式)の妥当性。あえて敵対的な視点で、最も深く掘る |
| `review-business` | ビジネス要件からのトレーサビリティ・NFRが数値になっているか・ステークホルダーとの整合 |
| `review-scalardb` | ScalarDBを使う場合。2PC(2フェーズコミット)のスコープ・OCC(楽観的排他制御)の競合・スキーマ互換性 |
| `review-data-integrity` | ScalarDBを使わない場合。データ整合性・トランザクションの安全性・スキーマ品質 |
| `review-synthesizer` | 2〜6視点の結果を統合し、重複を除いて優先度をつけ、品質ゲートの合否を判定する |

<Accordion>
  <AccordionItem title="/architect:review-consistency — 一貫性レビュー(sonnet)">
    3つの視点(構造の一貫性35%・トレーサビリティ35%・用語の一貫性30%)を5点満点で評価します。孤立したセクション、要件→設計→実装のトレースが辿れない箇所、同じ概念に別名がついている箇所などをJSON形式のfindingsとして出力します。
  </AccordionItem>

  <AccordionItem title="/architect:review-operations — 運用レビュー(sonnet)">
    4つの視点(監視・可観測性30%・災害対策30%・セキュリティ姿勢20%・デプロイの安全性20%)で運用面の準備状況を評価します。
  </AccordionItem>

  <AccordionItem title="/architect:review-risk — リスクレビュー(opus)">
    4つの視点(分散システムのリスク30%・故障モード分析30%・Saga設計の妥当性25%・データ整合性リスク15%)を、あえて敵対的な立場から評価します。設計者自身が気づきにくいリスクを見つけることが目的で、6視点の中で最も深く掘ります。
  </AccordionItem>

  <AccordionItem title="/architect:review-business — ビジネスレビュー(sonnet)">
    4つの視点(要件トレーサビリティ35%・NFRの数値化30%・ステークホルダーとの整合20%・ROI/実現可能性15%)で、ビジネス要件から見た設計の妥当性を評価します。
  </AccordionItem>

  <AccordionItem title="/architect:review-scalardb — ScalarDBレビュー(sonnet)">
    ScalarDBを使うプロジェクト専用です。3つの視点(サービス間トランザクションの仕組み40%・OCC競合分析35%・スキーマ/API互換性25%)で評価します。
  </AccordionItem>

  <AccordionItem title="/architect:review-data-integrity — データ整合性レビュー(sonnet)">
    ScalarDBを使わないプロジェクト専用です。3つの視点(トランザクション安全性40%・データ整合性35%・スキーマ設計品質25%)で評価します。`review-scalardb`とは互いに排他で、どちらか一方だけが実行されます。
  </AccordionItem>

  <AccordionItem title="/architect:review-synthesizer — レビューの統合(sonnet)">
    2〜6視点の結果を受け取り、次の順で統合します。

    1. **重複の統合**

        同じ場所・同じ根本原因の指摘は1つにまとめ、どの視点から見つかったかを記録します(例: "CON-003, BIZ-007")。統合時は最も高い重大度を採用します。

    2. **優先度の分類**

        P0(重大。データ損失・セキュリティ侵害・システム障害につながる)からP3(参考程度)まで4段階に分類します。2つ以上の視点で「重要」判定された指摘や、risk/scalardb視点からの「重要」判定はP1に上がります。

    3. **品質ゲートの判定**

        `review-registry.json`のしきい値にもとづき、PASS(平均3.5以上・重大指摘0件など)/CONDITIONAL PASS(平均2.5以上・重大指摘2件まで)/FAILのいずれかを判定します。

    4. **修正の伝播チェック**

        設計書の修正で解消したはずの指摘が、OpenAPIの説明文など**別の場所に生き残っていないか**を確認します。後工程のコード生成はこの説明文を指示として読むため、取り消したはずの記述が残っていると同じ欠陥が形を変えて再発します。
  </AccordionItem>
</Accordion>

## ScalarDB移行系

既存のデータベースをScalarDBに移行するためのスキル群です。`migrate-database`が窓口(ルーター)となり、
移行元のデータベースの種類に応じて専用のスキルに振り分けます。

```mermaid
flowchart LR
  A["migrate-database(ルーター)"] --> B[migrate-oracle]
  A --> C[migrate-mysql]
  A --> D[migrate-postgresql]
```

| スキル | 担当範囲 |
|---|---|
| `migrate-database` | 移行元のデータベース種別を判定し、下の専用スキルに振り分ける窓口 |
| `migrate-oracle` | スキーマ抽出・移行分析・Advanced Queuing連携・ストアドプロシージャ/トリガのJava変換 |
| `migrate-mysql` | スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換 |
| `migrate-postgresql` | スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換 |

<Accordion>
  <AccordionItem title="/architect:migrate-database — 移行の窓口(sonnet)">
    どの移行元データベース(Oracle/MySQL/PostgreSQL)かを1つ選んでもらい、対応する専用スキルに振り分けます。実際のスキーマ抽出や変換は行いません。
  </AccordionItem>

  <AccordionItem title="/architect:migrate-oracle — Oracle移行(sonnet)">
    6つのサブエージェント(3段階の逐次実行 → 3つの並列実行)でスキーマ抽出からJavaコード生成までを行います。

    1. **DB接続確認とスキーマ抽出(逐次)**

        SQL*Plus経由の接続確認 → 抽出スクリプトによるスキーマ抽出 → レポート生成、の3ステップを順番に実行します。

    2. **移行分析・AQ連携・コード変換(並列)**

        「移行分析と複雑度スコアの算出」「Advanced Queuing(Oracleのメッセージキュー機能)のセットアップSQLとJavaコンシューマ生成」「PL/SQLのストアドプロシージャ/トリガをJavaに変換」の3つを同時に走らせます。逐次実行に比べて33〜55%ほど時間を短縮できます。
  </AccordionItem>

  <AccordionItem title="/architect:migrate-mysql — MySQL移行(sonnet)">
    `migrate-oracle`と同じ考え方(逐次抽出→並列分析・変換)で、スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換を行います。Advanced Queuing連携はOracle固有の機能のため対象外です。
  </AccordionItem>

  <AccordionItem title="/architect:migrate-postgresql — PostgreSQL移行(sonnet)">
    `migrate-oracle`と同じ考え方で、スキーマ抽出・移行分析・ストアドプロシージャ/トリガのJava変換を行います。Advanced Queuing連携はOracle固有の機能のため対象外です。
  </AccordionItem>
</Accordion>

---

この中でも、実際のプロジェクトで最もよく使われるのが**バックログ運用**の4つのスキルです。`export-backlog` →
`implement-backlog` → `review-issue` → `merge-issue` という流れで使います。次のページから、この4つを順番に解説します。

<CardGroup cols={2}>
  <Card title="export-backlog" icon="clipboard-list" href="/skills/backlog/export">
    reports/フォルダの内容をもとに、Epic(大きな機能のまとまり)・Sub-Epic・Issue(具体的な作業)を作成する
  </Card>
  <Card title="implement-backlog" icon="code" href="/skills/backlog/implement">
    サブエージェント(補助的に動くAI)を階層的に使って、実装を進める
  </Card>
  <Card title="review-issue" icon="search-check" href="/skills/backlog/review">
    Issue単体だけでなく、それが属するEpic全体も見てレビューする
  </Card>
  <Card title="merge-issue" icon="git-merge" href="/skills/backlog/merge">
    事前チェック(プリフライトチェック)を経てマージし、完了状況を上位のEpicにも反映する
  </Card>
</CardGroup>