この記事はシリーズ構成となっており▶️マークが現在の記事となります
プロローグ
AIは「新人」であり「Web開発」である - 成果を最大化する生成AIとの付き合い方
第1部 僕がAIを最高の相棒にするまで：ブログ運営改善プロジェクト全記録
第2部 PMP資格の学習教材を、AIを相棒にしてゼロから作り上げる
第3部 AIを相棒にしたシステム開発プロジェクト全記録
【第1回】AIとの「壁打ち」が、曖昧な要求を「勝てる仕様書」に変えるまで
▶️【第2回】ゼロから始めるWebアプリ設計：AIと一緒にモダンなAWSアーキテクチャを描く
【第3回】AIにコードを書かせる前に人間がすべきこと：高品質な成果物を生む「設計書」の作り方
【第4回】巨大なタスクを分解する技術：AIに「開発ロードマップ」を作らせてプロジェクト全体を見通す
【第5回】ログイン機能のセキュリティと利便性、その最適なバランス
【第6回】開発プロセスにおけるAIとの協働：ログイン機能設計のケーススタディ
【第7回】認証管理の弱点とボトルネック：AIは「見えないリスク」をどう可視化するか【第8回】1つの対話から無限のコンテンツを：AIとの開発プロセスを新人研修資料やインフォグラフィックに変える方法
今回のテーマ:アーキテクチャ設計フェーズ
前回の記事はこちら：https://axis.migalo.co.jp/column/k028
① はじめに（導入）
要件定義が完了し、プロジェクトの「何を作るか」が明確になった次に取り組むべきは、「どう作るか」を定義するアーキテクチャ設計です。特にクラウド（AWS）を前提とした現代のWebアプリケーション開発では、無数のサービスをどう組み合わせるかという複雑な意思決定が求められます。
この工程は、まるで未知の大陸を探検するための「地図作り」に似ています。道なき道を進むこの重要なフェーズで、もし経験豊富なベテランアーキテクトが隣でアドバイスをくれたら、どれほど心強いでしょうか？
この記事では、前回作成した要件定義書を基に、生成AI（本記事ではGoogleのGeminiを使用）をその「ベテランアーキテクト」として活用し、具体的な技術スタックの選定からシステム全体の構成図作成までを二人三脚で進めていくプロセスをご紹介します。
この記事を読めば、複雑なシステム設計という「地図作り」を、AIと共にいかに効率的かつ確実に行うかの具体的なヒントが得られるはずです。
② 課題・目的
第1回で作成した要件定義書により、実装すべき機能は明確になりました。しかし、それを実現するための技術的な選択肢は無限に存在します。
【この時点での課題】
フロントエンド、バックエンド、データベース、インフラ… どの技術スタックを選定するのが最適か？ AWSの多様なサービスをどう組み合わせれば、スケーラブルでセキュアなシステムを構築できるか？ * 設計した構成を、エンジニアや関係者にどうすれば正確に伝えられるか？
特に、クラウドネイティブな開発経験が浅い担当者にとっては、「何から手をつければいいのか分からない」という状況に陥りがちです。
そこで、今回の目的を以下のように設定しました。
目的: 第1回で作成した要件定義書を満たす、モダンで実践的なWebアプリケーションのアーキテクチャを設計すること。
課題: AIとの対話を通じて、技術選定の妥当性を検証し、複雑なシステム構成を誰にでも分かりやすく可視化すること。
この課題を解決するため、Geminiに「システムアーキテクト」としての役割を担ってもらうことにしました。
③ AIへの指示（プロンプト）
まずは、たたき台となる技術スタック案をAIに提示し、レビューを依頼することから始めました。
【プロンプト】 これから、システム構成とプロジェクトのリソースの構成を検討します。 現在検討しているものは下記ですが、不足している部分を充足してください。 また、そもそも用語や分類を間違えている場合、指摘してください。
動作環境： AWS フロントエンド： Vue.js（typescript） バックエンド： java（SpringBoot） database： インメモリデータベース IaC： AWS cdk CICD： terraform, code pipeline ...（以下略）
【プロンプトのポイント】
思考のプロセスを共有: 完璧な案を提示するのではなく、あえて不完全な「検討中の案」を共有し、「不足部分の充足」「間違いの指摘」を依頼しています。 多角的なレビューを要求: 単純なコード生成ではなく、用語の整理や分類といった、より高次のレビューを求めています。
④ AIによる生成物（アウトプット）
このプロンプトに対し、Geminiは単に案を受け入れるのではなく、経験豊富なアーキテクトのように、各項目を精査し始めました。
【Geminiからの初期レビュー（抜粋）】
4. データベース 要検討・注意点: 永続性: インメモリデータベースは高速ですが、データが消失する可能性があります。ユーザー情報など、永続性が必要なデータの保存場所としては不向きです。Amazon RDS (例: PostgreSQL) や Amazon DynamoDBなどの永続データベースの採用を強く推奨します。
5. IaC (Infrastructure as Code) * Terraformとの関連: CI/CDの項目にTerraformがありますが、IaCツールです。CDKとTerraformをどのように使い分けるか、あるいはどちらかに統一するか方針を明確にする必要があります。
この的確なフィードバックを受け、データベースを「Amazon RDS (PostgreSQL)」に変更し、IaCツールを「AWS CDK」に統一するなどの意思決定を行いました。
さらに議論を重ね、0最終的なアーキテクチャが固まった段階で、私は次の指示を出しました。
【プロンプト】 これまでのレビュー内容を踏まえて、システム全体の構成図（主要なコンポーネントとデータの流れがわかるもの）を作成してください。Mermaid記法でお願いします。
この指示に対し、Geminiはシステム全体の構成を見事に表現したMermaidコードと、その詳細な解説を生成しました。
【Geminiが生成した構成図（Mermaidコード）】
mermaid graph TD subgraph "ユーザー" UserBrowser["ブラウザ (Vue.js)"] end subgraph "AWS Cloud" Route53["Amazon Route 53"] CloudFront["Amazon CloudFront"] S3FE["AWS S3 (フロントエンド)"] ALB["Application Load Balancer"] AppContainer["Java SpringBoot on Fargate"] RDS_PG["Amazon RDS (PostgreSQL)"] ElastiCacheRedis["Amazon ElastiCache (Redis)"] %% ...以下略... end UserBrowser --> Route53 --> CloudFront --> S3FE UserBrowser --> Route53 --> CloudFront --> ALB --> AppContainer AppContainer --> RDS_PG AppContainer --> ElastiCacheRedis
【生成物のポイント】 対話による設計の深化: AIは単に指示を待つだけでなく、初期案の弱点を指摘し、代替案を提示することで、より堅牢な設計へと導いてくれました。 構造化データの生成能力: 自然言語での対話の結果を、Mermaid記法という構造化されたテキスト（コード）として出力する能力を持っています。これにより、設計内容を曖昧さなく、かつ視覚的に表現することが可能になります。
⑤ 考察・ポイント
今回の対話から、AIをシステム設計のパートナーとして活用する上で、以下の3つの重要なポイントが見えてきました。
・AIは思考の「増幅器」である AIは、私たちが提示した断片的なアイデアや知識を基に、業界のベストプラクティスや膨大な選択肢と照らし合わせ、考慮すべき点を網羅的に提示してくれます。これにより、一人で設計するよりも遥かに広く、深く思考することが可能になります。AIは私たちの思考を代替するのではなく、増幅してくれる存在なのです。
・複雑な関係性を「見える化」する力 クラウドアーキテクチャのように多数のコンポーネントが複雑に絡み合うシステムを、人間が頭の中だけで完璧に把握するのは困難です。Mermaid記法のようなテキストベースの図をAIに生成させることで、複雑な関係性を瞬時に「見える化」し、チーム内の認識齟齬を防ぐことができます。
・設計プロセスの再現性とバージョン管理 AIとの対話ログと、生成されたMermaidコードをGitで管理することで、設計がどのように進化していったかの全プロセスを後から追跡できます。 なぜその技術を選んだのか、どのような懸念事項があったのかが記録として残るため、将来の設計変更やメンバーの引き継ぎが非常にスムーズになります。テキストベースの図は、Gitでのバージョン管理と非常に相性が良いのです。
あなたのプロジェクトで試すには あなたのプロジェクトで検討している技術スタック（言語、フレームワーク、DBなど）をAIに提示してみましょう。
そして、「この技術スタックで〇〇というシステムを構築する場合、どのようなアーキテクチャが考えられますか？Mermaid記法で構成図を提案してください」と依頼してみてください。AIが、あなたのアイデアを具体的な「設計図」に落とし込んでくれます。
⑥ まとめと次回予告
今回は、AIを経験豊富なアーキテクトとして活用し、Webアプリケーションの全体像を描くプロセスをご紹介しました。AIとの対話を通じて、技術選定の妥当性を高め、複雑なシステム構成を分かりやすく可視化することができました。
こうして、AIを「ベテランアーキテクト」として活用し、プロジェクトの全体像を示す「地図」を手に入れることができました。しかし、どれほど優れた地図があっても、AIという超高速な旅人が道を踏み外さないための「ガードレール」がなければ、旅は混乱してしまいます。
次回、 「第3回：AIにコードを書かせる前に人間がすべきこと：高品質な成果物を生む「設計書」の作り方」 では、このアーキテクチャを基に、AIが高品質なコードを一貫して生成するための「ガードレール」となる各種設計書をどう作るかについて解説します。ご期待ください。
