2026.07.07
AI駆動開発でのシステム設計 ― アーキテクチャの詰め方
- AI
- 技術戦略

AI駆動開発でのシステム設計 ― アーキテクチャを対話で詰める実践フロー
「設計フェーズに2週間かけて、結局後で大幅な見直しが入る」「アーキテクチャ案が1つしか出てこなくて比較できない」「ADR(設計決定記録)を残す文化がなくて、3か月後に『なぜこの設計にしたか』が誰も覚えていない」 ― 中堅以上のソフトウェア開発組織で頻発する課題だ。原因は「設計フェーズに人間1人〜数人で挑んでいる」ことにある。AIとの対話を通じて、複数のアーキテクチャ案を網羅的に生成し、トレードオフを比較し、構成図・シーケンス図・ER図を自動生成し、ADRとして決定記録を残す ― これらが現代型のシステム設計の姿だ。本稿では、AI駆動システム設計の4特徴、5ステップフロー、アーキテクチャ案の例、6種類の設計ドキュメント、AIに任せる/任せない範囲、設計レビュー自動化、ADR、4落とし穴、ツール組み合わせ、経営価値を整理する。
要点:AI設計は「選択肢の生成→比較→決定→図表化」を対話で回す。設計の網羅性と速度が両立する。AIに任せる範囲と任せない範囲を明確にし、ADRで意思決定を残す。
1. AI駆動システム設計の4つの特徴
特徴は4つ。選択肢の自動生成でアーキテクチャ案を複数提示、トレードオフを明示。図表自動化で構成図・シーケンス図・ER図を自動生成。技術スタック比較で候補技術のメリデメを瞬時に並べる。先行検証で設計時点でPoC実装も可能。これら4特徴が組み合わさることで、設計の網羅性・速度・品質が同時に向上する。「設計は時間がかかるもの」「シニアしかできない」という従来の常識が覆される領域だ。ジュニアエンジニアでも、AIをパートナーにすれば、シニア相当の設計品質を出せる可能性が出てくる。
| 特徴 | 内容 | 効果 |
|---|---|---|
| 選択肢の自動生成 | 複数案+トレードオフ | 網羅性 |
| 図表自動化 | 構成図・ER図・シーケンス図 | 速度 |
| 技術スタック比較 | メリデメ瞬時 | 判断品質 |
| 先行検証 | PoC実装 | 妥当性確認 |
| ADR支援 | 決定記録 | 透明性 |
💡 ポイント:4特徴のうち「選択肢の自動生成」が最大の価値。「1案だけ提案」から「3案比較」へ移行することで、設計判断の質が一段上がる。
2. 進め方の5ステップフロー
進め方は5ステップ。Step 1:制約条件の整理でスケール・予算・スキル・期間・規制を整理。Step 2:アーキテクチャ案の生成で「3つのアーキテクチャ案をトレードオフ付きで提示」とAIに依頼。Step 3:比較・決定で「コスト・スケール・運用負荷で比較表を作成」。Step 4:詳細設計でデータモデル・API・コンポーネント設計。Step 5:図表化で構成図・シーケンス図・ER図を生成。これら5ステップを2〜3日で消化することで、設計フェーズが一気に進む。「制約条件の整理」を最初に明確化することが、その後のAI生成案の品質を大きく左右する。曖昧な制約からは曖昧な設計しか生まれない。
| Step | 内容 | 期間目安 |
|---|---|---|
| 1:制約条件 | スケール・予算・期間 | 半日 |
| 2:選択肢生成 | 3案提示 | 半日 |
| 3:比較・決定 | 比較表 | 半日 |
| 4:詳細設計 | データ・API | 1日 |
| 5:図表化 | 各種ダイアグラム | 半日 |
⚠️ 注意:「制約条件」の整理を飛ばすと、AIが「教科書的に立派だが自社に合わない」設計を出す。必ず最初に制約を明確化する。
3. アーキテクチャ案の例 ― ユーザー管理機能で3案比較
ユーザー管理機能の例で3案を比較する。案A:モノリス(最初の30人まで)は単一サービス・PostgreSQL、開発速度◎・スケール△。案B:マイクロサービス(100人以上)はユーザーサービス独立、スケール◎・運用負荷高。案C:BaaS(Auth0等)は認証部分を外部委託、開発速度◎・ベンダー依存。これら3案をAIに生成させ、自社の状況(規模・予算・期間)に応じて選択する。重要なのは「最適解は一つではない」という認識で、組織のフェーズによって最適解が変わる。「案A→案B→案C」のように成長に応じて段階的に進化させる戦略もありうる。
| 案 | 適合フェーズ | 特徴 |
|---|---|---|
| 案A:モノリス | 〜30人 | 開発速度◎・スケール△ |
| 案B:マイクロサービス | 100人〜 | スケール◎・運用負荷高 |
| 案C:BaaS | 全フェーズ | 委託・ベンダー依存 |
| 案A→B移行 | 成長期 | 段階的進化 |
| ハイブリッド | 中規模 | 部分マイクロ化 |
📊 経営判断のコツ:3案比較を経営会議に提示して「現在のフェーズで最適なのはどれか」を議論する。技術論ではなく経営論として進める。
4. 設計ドキュメントの6種類
設計ドキュメントは6種類。アーキテクチャ図でシステム全体像、構成要素・データフロー。シーケンス図で主要シナリオの流れ。データモデルでER図・スキーマ。API設計でエンドポイント・スキーマ、OpenAPI形式。コンポーネント設計でフロント側の構造、状態管理。非機能設計で性能・可用性・セキュリティ。これら6ドキュメントをAIで自動生成させると、設計成果物が網羅的に揃う。「アーキテクチャ図だけ」「ER図だけ」では不十分で、6種類の視点から設計を見ることで、抜け漏れと矛盾が検出できる。
| ドキュメント | 用途 |
|---|---|
| アーキテクチャ図 | 全体像 |
| シーケンス図 | フロー |
| データモデル | スキーマ |
| API設計 | I/F定義 |
| コンポーネント設計 | フロント |
| 非機能設計 | 品質特性 |
💡 ポイント:6種類のドキュメントを「テンプレート+AI生成」で半日〜1日で揃える。従来1週間かかっていた工程が劇的に短縮される。
5. AIに任せる範囲・任せない範囲
AIへの委任範囲を明確にすることが、設計フェーズの成功要因だ。任せる領域は選択肢の網羅、図表生成、比較表作成、一般的なパターン。任せない領域はビジネス判断、組織的トレードオフ、規制対応の最終判断、重要技術の最終決定。これら2領域の境界をCTOが明確化することで、AIと人間の役割分担が機能する。「全部AIに任せる」「全部人間がやる」のどちらも失敗パターン。「網羅的な情報整理はAI、最終判断は人間」という分業が、現代型の設計プロセスの基本構造になる。
| 任せる | 任せない |
|---|---|
| 選択肢の網羅 | ビジネス判断 |
| 図表生成 | 組織的トレードオフ |
| 比較表作成 | 規制対応最終判断 |
| 一般パターン | 重要技術最終決定 |
| 初稿作成 | 戦略的選択 |
⚠️ 注意:「AIに任せる/任せない」の境界が曖昧だと、責任所在が不明確になる。組織として明文化する。
6. 設計レビューの自動化
設計レビューもAIで自動化できる。AIによる事前レビューはセキュリティ観点、パフォーマンス観点、スケール観点、運用観点の4軸で実施する。例として「このアーキテクチャ図に対して、単一障害点・認証認可・データ漏洩リスク・運用負荷の観点でレビュー」とAIに依頼する。人間レビューの前にAIで一次レビューを行うことで、明らかな問題を事前に潰せる。「人間のシニアの目」と「AIのシニアの目」を組み合わせることで、レビュー品質が一段上がる。AIが指摘した問題のうち、対応する/しないの判断は人間が行う構造が望ましい。
| レビュー観点 | チェック項目 |
|---|---|
| セキュリティ | 認証・データ漏洩 |
| パフォーマンス | レスポンス・スループット |
| スケール | 水平・垂直 |
| 運用 | 監視・運用負荷 |
| 可用性 | 障害設計・冗長化 |
📊 経営判断のコツ:「AI一次レビュー+人間最終レビュー」を設計プロセスの標準にする。レビュー品質と速度が両立する。
7. ADR(Architecture Decision Record)
ADRはアーキテクチャ決定記録で、AIを使った作成が効率的だ。「以下の決定をADR形式でまとめて:状況、決定、理由、影響」とAIに依頼することで、ADRが自動生成される。効果は意思決定の記録、将来の振り返り、新メンバーのオンボーディングの3点。「3か月後になぜこの設計にしたか誰も覚えていない」という事態を防げる。ADRをGitリポジトリに残し、設計判断の履歴として組織知化することで、組織の設計成熟度が上がる。AIDD時代だからこそ、AIで楽に作れるADRを習慣化することが重要になる。
| ADR要素 | 内容 |
|---|---|
| 状況 | 背景・制約 |
| 決定 | 採用案 |
| 理由 | 選定根拠 |
| 影響 | プロジェクトへの影響 |
| 代替案 | 検討した他案 |
💡 ポイント:ADRをGitリポジトリで管理し、意思決定履歴を組織知化する。AIで自動生成できるため、習慣化のハードルが低い。
8. 設計フェーズの4落とし穴
頻発する落とし穴は4つ。AI生成案の鵜呑み ― 一見筋が良くても自社に合わない、対策は必ず人間判断。オーバーエンジニアリング ― AIは「立派な設計」を出しがち、対策はスケール・規模に合わせる。図表ドリフト ― 実装と図がズレる、対策はCIで自動更新検討。ADR不在 ― 決定理由が残らない、対策はADR必須化。これら4落とし穴を意識的に避けることで、AI設計の成功率が大きく上がる。「オーバーエンジニアリング」は特にAIに頼った設計で起きやすく、「将来のスケールに備えてマイクロサービス」のような過剰な設計が出てくる。「現在の規模に合った設計」を貫く判断軸が、CTOの責任になる。
| 落とし穴 | 対策 |
|---|---|
| AI生成案の鵜呑み | 人間判断 |
| オーバーエンジニアリング | 規模に合わせる |
| 図表ドリフト | 自動更新 |
| ADR不在 | ADR必須化 |
| レビュー省略 | AI+人間2重 |
⚠️ 注意:「オーバーエンジニアリング」は経営層には見えにくい。CTOが意識的に防がないと、技術負債が無駄に増える。
9. ツール組み合わせ
設計ツールの組み合わせは3層で構成する。Claude Code / Cursorで対話と図表生成、ADR作成。Mermaid / PlantUMLでテキストから図表、バージョン管理可。Figma / Excalidrawでホワイトボード議論、AI生成図のブラッシュアップ。これら3層を使い分けることで、設計フェーズの効率が大幅に上がる。Mermaid・PlantUMLはテキストベースのため、Gitでバージョン管理でき、CIで自動更新も可能。FigmaやExcalidrawはホワイトボード議論に向き、AIが生成した初稿を人間がブラッシュアップする用途に適合する。
| ツール層 | 役割 |
|---|---|
| Claude Code / Cursor | 対話・初稿生成 |
| Mermaid / PlantUML | 図表バージョン管理 |
| Figma / Excalidraw | ホワイトボード議論 |
| draw.io | 詳細構成図 |
| Lucidchart | 共有図 |
💡 ポイント:「テキストベース図表(Mermaid等)」を組織標準にすると、設計ドキュメントがコードと同じくバージョン管理できる。
10. 経営観点での4つの価値
経営観点の価値は4つ。設計品質で抜け漏れ・偏り削減。速度で数週間→数日。意思決定の透明性でADRで残る。教育効果でジュニアの育成加速。これら4価値が組み合わさることで、AI設計が「便利機能」ではなく「組織能力強化」として位置づけられる。「ジュニアでもシニア相当の設計品質を出せる」ことは、組織の設計能力を底上げし、シニア依存の脱却につながる。「シニアが少ない組織」「設計品質にばらつきがある組織」にとって、AI設計は組織課題の根本解決策になりうる。経営層がCTOと連携して、組織的な設計プロセス改革として取り組む価値がある。
| 経営価値 | 内容 |
|---|---|
| 設計品質 | 抜け漏れ削減 |
| 速度 | 数週間→数日 |
| 意思決定透明性 | ADR残る |
| 教育効果 | ジュニア育成 |
| シニア依存脱却 | 組織能力底上げ |
📊 経営判断のコツ:「シニア依存脱却」を経営課題として位置づける。AI設計プロセスの導入は、組織の根本的な能力強化施策。
まとめ
AI駆動システム設計は「選択肢の生成→比較→決定→図表化」を対話で回す高速サイクルで、4特徴(選択肢自動生成・図表自動化・技術比較・先行検証)と5ステップフロー(制約整理→案生成→比較決定→詳細設計→図表化)で進める。3案比較と6種類のドキュメント(アーキ図・シーケンス・データモデル・API・コンポーネント・非機能)を整備し、AIに任せる範囲と任せない範囲を明確化する。設計レビューを4観点(セキュリティ・パフォーマンス・スケール・運用)でAI自動化し、ADRで意思決定を記録する。4落とし穴(鵜呑み・オーバーエンジニアリング・図表ドリフト・ADR不在)を避け、Claude Code・Mermaid・Figmaなど3層ツールを組み合わせる。経営価値は品質・速度・透明性・教育の4方向で、シニア依存脱却という組織的課題の解決策にもなる。
AI駆動システム設計チェックリスト
- [ ] 4特徴(選択肢生成・図表自動化・技術比較・先行検証)を組織で理解している
- [ ] 5ステップフロー(制約→案生成→比較→詳細設計→図表化)で進めている
- [ ] アーキテクチャ案を3つ以上比較する習慣がある
- [ ] 6種類の設計ドキュメント(アーキ図・シーケンス・データモデル・API・コンポーネント・非機能)を生成している
- [ ] AIに任せる/任せない範囲が明文化されている
- [ ] AI一次レビューと人間最終レビューが運用されている
- [ ] ADRをGitで管理している
- [ ] 4落とし穴(鵜呑み・オーバーエンジニアリング・ドリフト・ADR不在)を避けている
- [ ] Mermaid・PlantUMLでテキストベース図表を運用している
- [ ] 経営層が「シニア依存脱却」として組織的に取り組んでいる
IT COMPASSのAI駆動開発支援
IT COMPASS では、CTO経験者が外部CTO・技術顧問として、AI駆動システム設計プロセスを伴走支援しています。
支援できること
- 🏗 AIシステム設計プロセス整備:選択肢生成・図表自動化・ADR運用、5ステップフロー
- 📐 設計ドキュメント標準化:アーキ図・API・データモデル、6種類ドキュメント
- 🛠 ツール選定とパイロット設計:Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
- 🛡 ガバナンス・セキュリティ整備:AI利用ポリシー、権限設計、知財・契約ルール
- 📈 経営会議への定例参加:取締役会・経営会向けのKPI設計と進捗レポート
こんな方におすすめ
- 設計フェーズの品質と速度を両立したいCTO・テックリードの方
- ADRなど意思決定の記録を運用化したい技術責任者の方
- AIによる設計レビューを取り入れたい開発リーダーの方
お問い合わせ
スポット相談(1回/契約不要・最短当日)から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。
経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。
監修者

西脇 靖紘(lanitech合同会社 代表取締役CEO 兼 CTO)
「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援している。著書はオライリー・ジャパンから複数刊行。
















