システム設計
システム設計ジャンルにおけるAIモデルの比較結果を確認できます。評価基準、ランキング、最新のベンチマーク例をまとめています。
ジャンル概要
アーキテクチャ設計、構成力、トレードオフの説明力を比較します。
このジャンルでは、主に 設計の質、完全性、トレードオフの説明力 のような力を見ようとしています。
コーディングよりも、構成の選び方、スケールの考え方、信頼性やトレードオフをどう扱うかを重く見ます。
ここで高得点でも、実装コードがそのまま強いとは限りませんし、初心者向けにやさしく説明できるとも限りません。
このジャンルで強いAIが向いている用途
アーキテクチャ検討、技術選定、拡張性や運用性を考えた設計相談です。
このジャンルだけでは判断しきれないこと
低レベルの実装品質、厳密な正確さ、非技術者向けの表現力までは判断しきれません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/04/25 09:38
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5.2 引退 | OpenAI |
100%
|
90
|
4 | 4 | GPT-5.2 の評価・スコアを見る |
| 2位 | GPT-5.5 NEW | OpenAI |
100%
|
89
|
1 | 1 | GPT-5.5 の評価・スコアを見る |
| 3位 | Claude Opus 4.6 引退 | Anthropic |
100%
|
88
|
4 | 4 | Claude Opus 4.6 の評価・スコアを見る |
| 4位 | GPT-5.4 NEW | OpenAI |
75%
|
88
|
3 | 4 | GPT-5.4 の評価・スコアを見る |
| 5位 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | GPT-5 mini の評価・スコアを見る |
| 6位 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Claude Sonnet 4.6 の評価・スコアを見る |
| 7位 | Claude Haiku 4.5 | Anthropic |
40%
|
82
|
2 | 5 | Claude Haiku 4.5 の評価・スコアを見る |
| 8位 | Gemini 2.5 Pro |
0%
|
75
|
0 | 4 | Gemini 2.5 Pro の評価・スコアを見る | |
| 9位 | Gemini 2.5 Flash |
0%
|
74
|
0 | 5 | Gemini 2.5 Flash の評価・スコアを見る | |
| 10位 | Gemini 2.5 Flash-Lite |
0%
|
71
|
0 | 4 | Gemini 2.5 Flash-Lite の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
設計の質
30.0%
この項目は、回答の 設計の質 を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
トレードオフの説明力
20.0%
この項目は、回答の トレードオフの説明力 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
拡張性・信頼性
20.0%
この項目は、回答の 拡張性・信頼性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
分かりやすさ
10.0%
この項目は、回答の 分かりやすさ を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
システム設計
スケーラブルな通知サービスの設計
あなたは急成長中のソーシャルメディア企業のシニアソフトウェアエンジニアです。あなたのタスクは、スケーラブルで信頼性の高い通知サービスを設計することです。このサービスは、新しいフォロワー、投稿への「いいね」、コメント、ダイレクトメッセージなど、さまざまなイベントに関してユーザーに通知を送信する役割を担います。
システム設計
リアルタイム通知サービスの設計
ソーシャルメディアプラットフォーム向けのリアルタイム通知サービスについて、高レベルなシステム設計を概説してください。サービスは次の要件を満たす必要があります。 - **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に対応する明確なセクションを持つ構造化プランとして提示してください。
システム設計
URL短縮サービスの設計
URL短縮サービス（bit.ly や tinyurl.com に類似）を設計してください。次の制約を満たす必要があります： 1. サービスは月間1億件の新しいURL短縮をサポートすること。 2. 読み取り対書き込み比率は100:1（すなわち、生成された各URLは平均で100回アクセスされる）。 3. 短縮URLは少なくとも5年間アクセス可能であること。 4. システムは99.9%の稼働率を達成すること。 5. リダイレクト遅延（短縮URLリクエスト受信からHTTPリダイレクト発行まで）は95パーセンタイルで50ms未満であること。 あなたの設計は以下のすべての領域に対処してください： A. **Short URL Generation Strategy**: どのように一意でコンパクトな短縮コードを生成しますか？エンコーディング方式、想定されるURL長、およびキー空間の衝突や枯渇をどのように処理するかについて議論してください。 B. **Data Storage**: どのデータベースを使用し、なぜそれを選ぶのか？5年間で必要となる総ストレージ量を見積もってください。スキーマ設計とパーティショニングやシャーディング戦略について説明してください。 C. **Read Path Architecture**: どのようにしてリダイレクト要求を大規模に提供し、レイテンシとスループットの要件を満たしますか？キャッシュ層、CDNの利用、およびレプリケーション戦略について議論してください。 D. **Write Path Architecture**: 月間1億件の新しいURLを確実に取り込むためにどのように処理しますか？キューイング、レート制限、整合性に関する考慮事項について議論してください。 E. **Reliability and Fault Tolerance**: ノード障害、データセンターの停電、またはキャッシュの無効化に対してシステムはどのように対処しますか？バックアップおよび復旧戦略は何ですか？ F. **Key Trade-offs**: 設計上の重要なトレードオフを少なくとも2つ挙げ（例：整合性と可用性、ストレージコストと読み取り性能、単純さとスケーラビリティ）、なぜその側を選んだのかを説明してください。 回答は、上記のAからFに対応する明確なセクションを持つ構造化された設計ドキュメントとして提示してください。
システム設計
グローバルなURL短縮サービスを設計する
Bitlyのような公開URL短縮サービスを設計してください。ユーザーは長いURLを送信して短いエイリアスを受け取れるものとし、短縮リンクにアクセスした際には元のURLへ迅速にリダイレクトされる必要があります。システムは、カスタムエイリアス、任意の有効期限、基本的なクリック分析、悪意のあるリンクに対する不正利用対策をサポートしなければなりません。 要件と制約: - 機能要件: - 長いURLに対する短縮URLを作成する。 - 短縮URLを元のURLへリダイレクトする。 - 利用可能な場合はカスタムエイリアスをサポートする。 - リンクごとに任意の有効期限をサポートする。 - 分析のためにクリックイベントを記録する。 - ユーザーがリンクを手動で無効化できるようにする。 - スケール前提: - 毎月1億2,000万件の新しい短縮URL。 - 1日あたり15億件のリダイレクト。 - リダイレクトトラフィックはグローバルに分散しており、読み取り負荷が高い。 - 分析データは15分以内にクエリ可能であるべき。 - 性能目標: - 大半のリージョンで、リダイレクトのp95レイテンシを80ms未満。 - 短縮リンク作成のp95を300ms未満。 - リダイレクトに対して99.99%の可用性。 - データと保持期間: - リンクは、有効期限切れまたは無効化されない限り、無期限に存続しうる。 - 生のクリックイベントは90日間保持してよく、集計済み分析は2年間保持する。 - 運用上の制約: - 一般的なクラウドインフラを使用すること。1つの特殊なマネージド製品ですべてが解決すると仮定してはならない。 - 予算は重要である。あらゆるレプリケーション、キャッシュ、ストレージの選択を正当化すること。 - 短縮コードはコンパクトで、大規模時にある程度推測しにくいものであるべきだが、完全な秘匿性は不要である。 回答では、以下を提供してください: 1. 主要コンポーネントとデータフローを含む高レベルアーキテクチャ。 2. リンクメタデータ、リダイレクト経路、分析イベントに対するストレージ選択と、その根拠。 3. 短縮コード生成戦略。衝突回避方法とカスタムエイリアスの扱いを含む。 4. キャッシュ、パーティショニング／シャーディング、マルチリージョンの考慮を含む、グローバルトラフィック向けのスケーリング計画。 5. 障害、ホットキー、災害復旧、性能劣化時の動作を扱う信頼性計画。 6. 主要APIとコアデータモデル。 7. 不正利用対策およびセキュリティ上の考慮事項。 8. 主にどのようなトレードオフを行ったか、その理由。