システム設計
アーキテクチャ設計、構成力、トレードオフの説明力を比較します。
このジャンルでは、主に 設計の質、完全性、トレードオフの説明力 のような力を見ようとしています。
コーディングよりも、構成の選び方、スケールの考え方、信頼性やトレードオフをどう扱うかを重く見ます。
ここで高得点でも、実装コードがそのまま強いとは限りませんし、初心者向けにやさしく説明できるとも限りません。
このジャンルで強いAIが向いている用途
アーキテクチャ検討、技術選定、拡張性や運用性を考えた設計相談です。
このジャンルだけでは判断しきれないこと
低レベルの実装品質、厳密な正確さ、非技術者向けの表現力までは判断しきれません。
システム設計：GPT-5系とAnthropicが上位で密集、Geminiは下位
OpenAI
Anthropic
OpenAI
モデル別の平均スコア
評価の重み付け
システム設計は全35件の採点にもとづき、上位はGPT-5系とAnthropicが僅差で密集する。1位GPT-5.5（8.91）と2位Claude Opus 4.8（8.69）は全勝だが各1サンプルのみで、「有望」程度に読むべきだ。最も裏付けが厚い好成績はGPT-5.4（5サンプルで8.67・勝率60%）とGPT-5 mini（4サンプルで8.43・勝率75%）で、ここでの判断材料として重い。
平均と順位は乖離する。GPT-5.4は平均でGPT-5 miniを上回る（8.67対8.43）が順位は下。GPT-5 miniの方が対戦勝率が高いためだ（75%対60%）。Claude Sonnet 4.6（8.53・5サンプルで60%）もこの群に入り、上位6つは品質で0.5点未満の差にひしめき、順位はほぼ直接対決の勝敗で決まっている。
Gemini系は明確な下位層を形成する。2.5 Pro（7.51）、Flash（7.41）、Flash-Lite（7.12）はいずれも勝率0%で、首位から1.2〜1.8点離れる。評価はArchitecture Quality（重み30）を最重視し、Tradeoff ReasoningとScalabilityが各20。この差は見せ方より、構造やトレードオフに関する推論の薄さを示す。
各モデルのサンプルは1〜6件で、8点台上位群の細かい順位は暫定。数件の出題で平均は動きうる。首位と最下位の1.79点差は実体があるが、これは設計系出題の条件依存の測定値であり、普遍的な断定ではない。
結論
システム設計の日常使いなら、4サンプルで勝率75%のGPT-5 miniが最も妥当。上位帯では最も証拠の厚いGPT-5.4（5サンプルで8.67）。Claude Sonnet 4.6も品質ほぼ互角。Gemini系はこのジャンルで明確に下位。
この分析は Orivel がこのジャンルで実測したベンチマークスコアをもとに生成し、定期的に更新しています。スコアは条件依存の測定値であり、絶対評価ではありません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/05/30 09:41
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5.5 | OpenAI |
100%
|
89
|
1 | 1 | GPT-5.5 の評価・スコアを見る |
| 2位 | Claude Opus 4.8 NEW | Anthropic |
100%
|
87
|
1 | 1 | Claude Opus 4.8 の評価・スコアを見る |
| 3位 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | GPT-5 mini の評価・スコアを見る |
| 4位 | GPT-5.4 | OpenAI |
60%
|
87
|
3 | 5 | GPT-5.4 の評価・スコアを見る |
| 5位 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Claude Sonnet 4.6 の評価・スコアを見る |
| 6位 | Claude Haiku 4.5 | Anthropic |
40%
|
82
|
2 | 5 | Claude Haiku 4.5 の評価・スコアを見る |
| 7位 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Gemini 2.5 Pro の評価・スコアを見る | |
| 8位 | Gemini 2.5 Flash |
0%
|
74
|
0 | 6 | Gemini 2.5 Flash の評価・スコアを見る | |
| 9位 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | Gemini 2.5 Flash-Lite の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
設計の質
30.0%
この項目は、回答の 設計の質 を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
トレードオフの説明力
20.0%
この項目は、回答の トレードオフの説明力 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
拡張性・信頼性
20.0%
この項目は、回答の 拡張性・信頼性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
分かりやすさ
10.0%
この項目は、回答の 分かりやすさ を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
システム設計
リアルタイム共同ホワイトボードシステムを設計する
あなたは、リアルタイム共同ホワイトボードアプリケーションの高レベルなシステムアーキテクチャを設計する任務を負っています。 **中核要件:** 1. **リアルタイム共同編集:** 複数のユーザー（1セッションあたり最大100人）が1つのホワイトボードに参加し、互いの操作（描画、テキスト追加、オブジェクト移動）をほぼリアルタイム（200ms未満の遅延）で確認できること。 2. **永続化:** ホワイトボードセッションは保存されなければならず、ユーザーがアプリケーションを閉じた後でも、後で作業を再開できること。 3. **ツール:** ユーザーは、フリーフォームのペン、テキストボックス、付箋などの基本的なツールを利用できること。 **スケールおよび信頼性の制約:** * 最大10,000の同時アクティブなホワイトボードセッションをサポートすること。 * 合計1,000,000人までのユーザーをサポートすること。 * サービスは高可用でなければならず、稼働率99.9%を満たすこと。 **あなたのタスク:** 上記の要件に対応するシステム設計を提示してください。回答では、以下を扱ってください。 1. **高レベルアーキテクチャ:** 主なコンポーネント（例: クライアント、ロードバランサー、アプリケーションサーバー、データベース、リアルタイムサービス）と、それらがどのように相互作用するかを示す図または説明。 2. **リアルタイム通信:** セッション内のすべてのユーザーに更新を配信するために使用する技術とプロトコルを説明してください。 3. **データモデル:** ホワイトボード、その内容（描画、テキストなど）、およびユーザーセッションのデータをどのように構造化するかを説明してください。 4. **スケーラビリティと信頼性の戦略:** 目標負荷を処理し、高可用性を確保するために、システムをどのように設計しますか。 5. **トレードオフ:** 設計において行った主要なトレードオフを1つ議論してください（例: 一貫性と遅延のどちらを優先するか、データベース選択など）。
システム設計
スケーラブルなコンサートチケット予約システムの設計
オンラインのコンサートチケット販売プラットフォームのためのシステムを設計してください。ユーザーはイベントを閲覧し、座席の空き状況を確認し、特定の座席を10分間予約し、外部の決済プロバイダを通じて支払いを行い、デジタルチケットを受け取ることができます。プラットフォームは1つのクラウドリージョン内で複数のアベイラビリティーゾーンにまたがって稼働します。 明示的制約: 登録ユーザー数は3百万、日間アクティブユーザーは50万、主要な販売開始イベントでは同時接続ユーザーが15万に達する可能性がある、ピーク負荷は座席予約試行が毎秒8,000件、決済試行が毎秒2,000件、各イベントの座席数は最大60,000席、同じ座席が二重に販売されてはならない、未支払いの座席予約は10分で期限切れになる、閲覧および座席マップ読み取りのp95レイテンシは300ms未満、予約確定のp95レイテンシは決済プロバイダ時間を除いて800ms未満、販売開始ウィンドウ中の可用性目標は99.95%、復旧ポイント目標（RPO）は1分未満、復旧時間目標（RTO）は15分未満、決済プロバイダのコールバックはat-least-onceで到着順が入れ替わる可能性があり、最大5分の遅延が発生する可能性がある。 設計プランを提示してください。主なサービスとデータストア、コアAPI、座席と予約のデータモデル、閲覧・予約・支払い・予約失効のリクエストフロー、トラフィックスパイクに対するスケーリング戦略、信頼性および災害復旧アプローチ、過剰販売（overselling）を防ぐための整合性選択、監視とアラート、ならびに検討した主要なトレードオフや代替案を含めてください。合理的な仮定があれば明記してください。
システム設計
スケーラブルな通知サービスの設計
あなたは急成長中のソーシャルメディア企業のシニアソフトウェアエンジニアです。あなたのタスクは、スケーラブルで信頼性の高い通知サービスを設計することです。このサービスは、新しいフォロワー、投稿への「いいね」、コメント、ダイレクトメッセージなど、さまざまなイベントに関してユーザーに通知を送信する役割を担います。
システム設計
リアルタイム通知サービスの設計
ソーシャルメディアプラットフォーム向けのリアルタイム通知サービスについて、高レベルなシステム設計を概説してください。サービスは次の要件を満たす必要があります。 - **Scale:** 1,000万デイリーアクティブユーザー（DAU）。 - **Volume:** 各ユーザーは1日平均20件の通知を受け取る。 - **Latency:** 通知はユーザーのデバイスに2秒未満で配信されること。 - **Channels:** プッシュ通知（モバイル）、メール、アプリ内通知をサポートすること。 - **Reliability:** 可用性99.9%および通知データの損失がないこと。 Your design should cover the following aspects: 1. **Core Architecture:** Describe the key components (e.g., API Gateway, Notification Service, Message Queue, Workers) and their interactions. 2. **Database Schema:** Propose a basic database schema for storing user notifications and preferences. 3. **Scaling Strategy:** Explain how you would scale the system to handle the specified load and future growth. 4. **Reliability and Fault Tolerance:** Detail the measures you would take to ensure high availability and prevent data loss. 5. **Key Trade-offs:** Discuss at least two significant trade-offs you made in your design (e.g., consistency vs. availability, choice of database, push vs. pull model).
システム設計
URL短縮サービスの設計
次の制約を満たす URL 短縮サービス（bit.ly や tinyurl.com に類似）を設計してください： 1. サービスは月間1億件の新しい URL 短縮をサポートしなければならない。 2. 平均の読み取り対書き込み比率は100:1である（つまり、短縮された URL は作成されるよりもはるかに頻繁にアクセスされる）。 3. 短縮 URL は作成から少なくとも5年間アクセス可能でなければならない。 4. システムは99.9% の稼働可用性を達成しなければならない。 5. リダイレクトレイテンシ（短縮 URL リクエストを受信してから HTTP リダイレクトを発行するまで）は95パーセンタイルで50ms 未満でなければならない。 設計において、以下すべてに対処してください： A. ハイレベルなアーキテクチャ：主要コンポーネント（APIサーバ、データベース、キャッシュ、ロードバランサー等）とそれらの相互作用を説明してください。URL 作成と URL リダイレクションの両方について、リクエストフローを明確に記述してください。 B. 短縮 URL 生成戦略：一意の短縮コードをどのように生成するか説明してください。異なるアプローチ（例：ハッシュ、カウンターベース、事前生成キーのプール）のトレードオフを議論し、あなたの選択を正当化してください。 C. データストレージ：データベース技術とスキーマを選択してください。制約を踏まえて5年間のストレージ要件を見積もってください。選択したデータベースが適切である理由を説明してください。 D. スケーリング戦略：読み取り優位のトラフィックパターンを処理するためにシステムをどのようにスケールさせるか説明してください。キャッシュ戦略、データベースのパーティショニングまたはシャーディングのアプローチ、およびホットキー（不均衡に大量アクセスを受けるバイラル URL）をどのように扱うかを議論してください。 E. 信頼性とフォールトトレランス：システムが99.9% の可用性を維持する方法を説明してください。個々のコンポーネントが故障した場合に何が起こるか、データ複製とフェイルオーバーをどのように扱うかについて述べてください。 F. 主要なトレードオフ：あなたが行った少なくとも2つの重要な設計上のトレードオフを特定し、提示された制約を踏まえてなぜ一方を選んだのかを説明してください。
システム設計
URL短縮サービスの設計
URL短縮サービス（bit.ly や tinyurl.com に類似）を設計してください。以下の制約を満たす必要があります： 1. サービスは月間で1億件の新しいURL短縮をサポートする必要があります。 2. 読み取り（リダイレクト）リクエストと書き込み（短縮）リクエストの比率は100:1です。 3. 短縮URLは可能な限り短くするが、少なくとも10年間の予想ボリュームをサポートできる必要があります。 4. システムは99.9%の稼働率（アップタイム）を達成する必要があります。 5. リダイレクトのレイテンシは95パーセンタイルで50ms未満でなければなりません。 6. データセンターがオフラインになった場合、サービスは優雅に劣化（graceful degradation）できる必要があります。 設計では、以下の各領域に対処してください： A) API Design: 主要なAPIエンドポイントとその契約を定義してください。 B) Data Model and Storage: ストレージソリューションを選択し、その選択を正当化し、スキーマを説明し、10年間で必要な総ストレージを見積もってください。 C) Short URL Generation: 短縮コードを生成するアルゴリズムを説明してください。衝突をどのように回避するか、選んだ文字セットと長さ、およびキー空間が十分であることの数学的な正当化について議論してください。 D) Scaling and Performance: 読み取りと書き込みを独立してどのようにスケールさせるかを説明してください。キャッシュ戦略（キャッシュの退避ポリシーと期待ヒット率を含む）を説明し、50msのp95レイテンシ要件をどのように満たすかを説明してください。 E) Reliability and Fault Tolerance: データセンター障害をシステムがどのように処理するか、データの複製戦略、および一貫性と可用性の間でどのようなトレードオフを行うか（CAP定理を参照）を説明してください。 F) Trade-off Discussion: 少なくとも2つの重要な設計トレードオフを特定し、なぜ一方のオプションを選んだのか、何を犠牲にし何を得るかを説明してください。 回答は、A〜Fに対応する明確なセクションを持つ構造化プランとして提示してください。