「システム設計の練習場所がない！」と嘆くのが嫌で、RustとAIで『最強の壁打ち相手』を自作した話

メモ

【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つです。

1. シナリオ選択画面
2. カスタムシナリオ定義画面
3. チャット画面
4. システム設計画面
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