メモ
【2025/12/12 追記】 アップデートを行いました！ 「DBを使わずにデータを共有する機能」や「VPC（グループ化）機能」を実装した開発裏話（続編）を公開しました！ AWSの請求におびえながら、意地でステートレスを貫いた技術解説記事です。
👉 続編記事：AWSの請求が怖いので、DBなしで「データ共有」を実装した話（と、React Flowの200ドル有料壁 vs AIの幻覚）
はじめに：インプットだけじゃ、設計できるようにならなくない？
突然ですが、みなさん。「システム設計」の練習、どうやってますか？
「大規模データ指向アプリケーション」や「システム設計の面接試験」……名著と呼ばれる本はたくさんあります。私も読みました。読み終わった瞬間は、なんとなく「強くなった気」がするんですよね。
でも、ふと思うんです。 「で、この知識、どこで使うの？」
個人開発じゃそんな大規模トラフィック来ないし、業務でいきなり「君、ゼロからアーキテクチャ考えて」なんて言われる機会もそうそうない。 既存コードの改修（As-Is）はあっても、白紙からの設計（To-Be）をするチャンスって、実はめちゃくちゃレアじゃないですか？
「練習場所がないなら、作るしかない」
そんな勢いだけで、AIを相手に要件定義から設計、評価までをガッツリやり合えるプラットフォームを開発しました。RustもAWSも手探り状態からのスタートでしたが、なんとか形になったので、その開発の裏側を少し語らせてください。
作ったもの：Architecture Sandbox
名前はそのまま、『Architecture Sandbox』。 一言でいうと、「めんどくさい顧客（AI）と戦いながら、システム構成図を描いて、AI上司に採点してもらうアプリ」です。
ただ図を描くだけのツールじゃありません。「交渉」と「評価」があるのが最大のミソです。
主な機能は以下の5つです。
- シナリオ選択画面
- カスタムシナリオ定義画面
- チャット画面
- システム設計画面
- 評価結果画面
それぞれの機能について紹介します。
シナリオ選択画面
アプリの入り口です。プリセットされた「デフォルトシナリオ」か、自分で設定を作る「カスタムシナリオ」を選択できます。
社内勤怠管理システム（初級）: 社員50名規模。ITに詳しくない担当者に対し、具体例を出しながらヒアリングする練習ができます。
画像投稿SNS（上級）: 次世代の世界規模SNS。スケーラビリティや高可用性が求められる複雑な設計課題です。
カスタムシナリオ定義画面
オリジナルのテーマで設計練習を行いたい場合はこちらを使用します。 システムの概要だけでなく、「規模感（アクセス数など）」や「会話相手（顧客）の人格」を定義できます。
特に「会話相手の人格」は体験を大きく変えます。気難しい相手であれば要件を引き出すのが難しくなり、規模感が大きければ求められる非機能要件（可用性など）のレベルが跳ね上がります。
チャット画面
ここが本アプリのこだわりの一つ、「交渉」のフェーズです。
いきなり設計に入るのではなく、AI（顧客）とチャットをして要件を詰めていきます。 AIは隠された「裏要件」を持っており、こちらから「予算感は？」「想定ユーザー数は？」と質問しない限り、重要な情報を教えてくれません。実務同様、ヒアリング能力が試されます。
得られた情報は右側の「要件メモ」に記録し、設計時の指針とします。
システム設計画面
React Flowを用いたドラッグ＆ドロップUIで設計を行います。 サイドバーからコンポーネント（LB, Web Server, DB, Cacheなど）を配置し、接続していきます。
現在は基本的な構成のみですが、今後はMulti-AZやDBレプリケーションなども表現できるように拡張予定です。設計が完了したら、ボタン一つでAIアーキテクトによる評価が始まります。
評価結果画面
作成した図と要件定義の内容を元に、AIがスコアリングとフィードバックを行います。 「可用性が低い」「コストがかかりすぎている」といった具体的な指摘に加え、レーダーチャートで総合評価を可視化します。これにより、客観的な視点で設計を見直すことができます。
技術選定
「せっかく個人開発するんだから、学習したい技術を全部詰め込もう！」という欲張りセットで構成しました。
- Backend: Rust(Axum)
- 学習中のRustを使用。型安全性とパフォーマンス、コンテナとの親和性を重視。（Goでも良かったが学習中のRustを使用してみました）
- Frontend: React + React Flow
- ノードベースのUI構築のたい採用。
- AI: Google Gemini API(Gemini 2.5 Flash)
- 高速なレスポンスと安価なコストで、リアルタイムな対話と評価を実現しました。
- Infrastructure: AWS App Runner + S3 + Cloud Front
- コンテナ実行環境としてApp Runnerを採用。フロントエンドはS3とClound Frontという王道の構成で構築してみました。
こだわったところ
1. いきなり「交渉」から始まる
このアプリ、いきなり設計させてくれません。まずは「顧客（AI）」へのヒアリングからです。
例えば「社内勤怠システムを作りたい」というシナリオ。 相手はITに疎い人事担当者（という設定のAI）です。「いい感じにお願いします」みたいなフワッとしたことしか言わなかったりします。
「社員規模は？」
「予算感は？」
「朝9時にアクセス集中しますか？」
こちらから食い気味に質問しないと、重要な**非機能要件（隠しパラメータ）**が出てきません。 この「要件を引き出す泥臭さ」こそ、現実の設計プロセスっぽくて燃えませんか？
2. 「マクロ視点」で設計する
要件が固まったら、React Flow製のキャンバスで設計です。 ここでは「Redis」や「Kafka」といった具体的な製品名ではなく、あえて「Cache」や「Queue」といった「役割（コンポーネント）」で配置します。
「ツール自体の設定」に時間を溶かすのではなく、「どこに何を置くべきか？」というアーキテクチャの意思決定だけに集中したいからです。
3. AI上司による「容赦ない評価」
設計が終わると、裏でGemini 2.5 Flashが走り出し、あなたの設計図を採点します。 これが結構厳しいんです。
「この規模でNoSQLはオーバースペックでは？」「SPOF（単一障害点）がありますよ」 ……ぐうの音も出ない指摘が飛んできます。でも、それがいい。誰かにレビューされるって、独学だと一番難しい体験ですから。
開発でハマったところ
正直、アプリのロジックを書いている時間より、インフラとDockerと戦っている時間のほうが長かった気がします。
1. AWSの請求が怖い！「脱RDS」の決断
個人開発者にとって、AWSのRDS（リレーショナルデータベース）は高嶺の花です。 「月数千円か……勉強代とはいえ、痛いな……」
そこで決断しました。「よし、DBを捨てよう」。
今回のアプリは「設計の練習」ができればいい。データの永続化は（一旦）諦めて、完全ステートレス構成に振り切りました。 データはフロントエンドのメモリに持たせて、評価時はそのJSONをAIに投げるだけ。おかげでApp Runnerのコンテナ代だけで済む超低コスト運用が実現しました。 （お金が貯まったらDynamoDBあたりで永続化します……！）
2. Mac(ARM) vs AWS(AMD) の仁義なき戦い
開発はM4 Mac mini（ARM64）。でも本番のApp Runnerはx86_64（AMD64）。 ローカルではサクサク動くのに、デプロイした瞬間にコンテナが死ぬ。ログを見てもよくわからない。
原因はOpenSSLでした。クロスコンパイルの罠にまんまとハマり、深夜に一人で頭を抱えました。 結局、OpenSSLへの依存を断ち切るために、Rust側のHTTPクライアントの設定で rustls を使うように変更して解決。 「コンテナならどこでも動く」なんて幻想だと思い知りました。いい勉強になりました。
おわりに
RustもReactもAWSも、一気にやったせいで脳のキャパシティは限界突破しましたが、満足度はめちゃくちゃ高いです。
なにより、「自分が欲しかったもの」が動いている画面を見るのは最高です。 書籍で読んだ知識が、コードとインフラを通して血肉になった感覚があります。
まだ「認証機能がない」「DBがない」「URLが固定化されていない」などツッコミどころは満載ですが、とりあえずメインの機能である「AIと設計バトル」はできるようになりました。
もしよかったら、GitHub覗いてみてください。そして、あわよくばStarをいただけると、私のモチベーションとAWS代の足し（気持ち的に）になります！
GitHub: リポジトリ
App: Architecture Sandbox