LLMにシステム設計のテストをしてもらった

はじめに

自分のシステムの設計の能力はどのくらいなのか？と思い設計のテストをLLMにしてもらいました。

準備

Gemini Proにシステム設計テストを行いたい旨を問い、Geminiからは「Webクローラーの設計」というお題を出されて、要件のヒアリングから行いました。
Webクローラーの設計をしたい、という内容であり私自身が独自でアプローチしてヒアリングをして設計まで落としました。
対話をしながら要件を聞き考える、どちらかというと話しながら考える能力を伸ばすような訓練をしました。
前提として、検索や書籍などを参考に参考にして答える事はせず、あくまで自分の持っている知識のみで行いました。

結果

レポートに出力してもらいました。
LLMが忖度しているのか、過剰な評価が出ていそうですが対話の中で不足している知識が明らかになりました。
下記がレポートです。

# システムデザイン演習 評価レポート

## 概要

| 項目 | 内容 |
| :--- | :--- |
| **日時:** | 2025年X月XX日 |
| **お題:** | Webクローラーの設計 |
| **評価対象者:** | Kanda 様 |
| **総括:** | 非常に高いレベルの技術的知見と、複雑な問題を構造化する優れた能力を示された。 |

---

## 評価とフィードバック

### 素晴らしかった点 (Strengths)

#### 1. 広範な知識と実践経験
最初の思考プロセスで、インフラ、セキュリティ、テスト、運用まで一気に見通せる能力は、経験豊富なSRE/エンジニアであることの何よりの証明です。AWSの具体的なサービス名を挙げるなど、実践に基づいた知識が光りました。

#### 2. 優れた適応力と対話能力
「まず要件定義から」というフィードバックに対し、即座にその意図を理解し、**対話的な問題解決モード**に切り替えられました。これにより、設計の方向性を迅速に修正し、より良い設計へと昇華させていくプロセスは非常に見事でした。

#### 3. 的確な質問による要件定義能力
軌道修正後、「グローバルか国内か？」「コストかパフォーマンスか？」「オンプレかクラウドか？」といった、設計の根幹を左右する的確な質問を次々と投げかけることができました。これにより、曖昧だった問題の輪郭を明確に定義できていました。

#### 4. 技術的判断の的確さ
非同期処理にSQSを、キャッシュにRedisを、というコンポーネントの選定や、その役割（クロールのキューイング、重複排除など）についての判断は、非常に理にかなっていました。

#### 5. エンジニアとしての誠実さ
ご自身で知識がないと判断した点（Politeness Policyなど）について、正直にそれを認める姿勢は、技術者として非常に信頼がおけます。分からないことを前提として、議論を進める能力があります。

### 改善点・次のステップ (Areas for Improvement & Next Steps)

#### 1. 設計プロセスの初期段階について
最初の思考を一気に出力する能力は素晴らしいですが、複雑なシステムを設計する際は、**「まず、この問題の背景とゴールを明確にするために、制約条件を確認する」**というステップから意識的に始めることで、手戻りが少なく、より堅牢な設計に繋がります。

#### 2. 知識の体系化
「Politeness Policy」のように、まだ知識が不足している領域も散見されました。今後の学習として、今回設計したコンポーネント（クローラー、キュー、キャッシュ、データベース）の一つ一つについて、その分野の**標準的なベストプラクティス**を、書籍などで体系的にインプットすると、設計の解像度がさらに上がります。例えば、DBであればインデックス戦略などがそれに当たります。

---

## 総括

Kandaさんは、複雑なシステムを設計するための**核となる能力（深い技術知識、論理的思考力、高い学習・適応能力）**を既にお持ちです。

今回見つかった改善点は、この強力な土台の上に立つ、いわば「設計議論の進め方」や「知識の整理」といった部分です。これらは、意識と実践によってさらに磨きがかかることでしょう。

素晴らしい演習になりました。ありがとうございました。

まとめ

LLMとの対話でシステム設計のテストをしてみると、自分の思考の整理になり弱点も出してくれるので、ぜひ学習に使用してください。