システム設計
システム設計ジャンルにおけるAIモデルの比較結果を確認できます。評価基準、ランキング、最新のベンチマーク例をまとめています。
ジャンル概要
アーキテクチャ設計、構成力、トレードオフの説明力を比較します。
このジャンルでは、主に 設計の質、完全性、トレードオフの説明力 のような力を見ようとしています。
コーディングよりも、構成の選び方、スケールの考え方、信頼性やトレードオフをどう扱うかを重く見ます。
ここで高得点でも、実装コードがそのまま強いとは限りませんし、初心者向けにやさしく説明できるとも限りません。
このジャンルで強いAIが向いている用途
アーキテクチャ検討、技術選定、拡張性や運用性を考えた設計相談です。
このジャンルだけでは判断しきれないこと
低レベルの実装品質、厳密な正確さ、非技術者向けの表現力までは判断しきれません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/03/22 21:21
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5.2 | OpenAI |
100%
|
90
|
3 | 3 | GPT-5.2 の評価・スコアを見る |
| 2位 | GPT-5.4 | OpenAI |
100%
|
89
|
3 | 3 | GPT-5.4 の評価・スコアを見る |
| 3位 | Claude Opus 4.6 | Anthropic |
100%
|
87
|
3 | 3 | Claude Opus 4.6 の評価・スコアを見る |
| 4位 | GPT-5 mini | OpenAI |
75%
|
84
|
3 | 4 | GPT-5 mini の評価・スコアを見る |
| 5位 | Claude Sonnet 4.6 | Anthropic |
60%
|
85
|
3 | 5 | Claude Sonnet 4.6 の評価・スコアを見る |
| 6位 | Claude Haiku 4.5 | Anthropic |
50%
|
84
|
2 | 4 | 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 | 5 | Gemini 2.5 Flash の評価・スコアを見る | |
| 9位 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Gemini 2.5 Flash-Lite の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
設計の質
30.0%
この項目は、回答の 設計の質 を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
トレードオフの説明力
20.0%
この項目は、回答の トレードオフの説明力 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
拡張性・信頼性
20.0%
この項目は、回答の 拡張性・信頼性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
分かりやすさ
10.0%
この項目は、回答の 分かりやすさ を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
システム設計
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. 主にどのようなトレードオフを行ったか、その理由。
システム設計
グローバルなURL短縮サービスの設計
Bitlyに類似したグローバルに利用可能なURL短縮サービスを設計してください。サービスは、ユーザーが短縮リンクを作成して長いURLへリダイレクトできること、有料ユーザー向けのカスタムエイリアスをサポートすること、クリックの分析を追跡すること、そしてリンクを指定時刻に有効期限切れにできることを満たす必要があります。 要件: - 1日あたり1億2,000万件の新規短縮リンクを処理すること。 - 1日あたり40億回のリダイレクトを処理すること。 - ピーク時トラフィックは日次平均の3倍に達する可能性があること。 - リダイレクト遅延ターゲット: 北米、ヨーロッパ、アジアのユーザーに対してp95で80 ms未満。 - 短縮リンク作成遅延ターゲット: p95で300 ms未満。 - リダイレクトのサービス可用性目標: 99.99%。 - 分析データは最大5分の範囲で最終的一貫性でよい。 - カスタムエイリアスはグローバルで一意でなければならない。 - 期限切れまたは削除されたリンクは迅速にリダイレクトを停止しなければならない。 - システムは地域的な障害が発生してもサービス全体が停止しないよう耐性を持つこと。 利用可能な仮定: - 平均的な長いURLの長さは500バイト。 - 分析イベントにはタイムスタンプ、リンクID、国、デバイス種別、リファラーのドメインが含まれる。 - 読み取りトラフィックは書き込みトラフィックよりはるかに多い。 - 必要に応じてSQL、NoSQL、キャッシュ、ストリーム、CDN、メッセージング技術を選択してよいが、その選択理由を示すこと。 あなたの回答には以下を含めてください: 1. 主要コンポーネントとリクエストフローを示すハイレベルなアーキテクチャ。 2. リンク、エイリアス、分析のデータモデルとストレージの選択。 3. 読み取り重視トラフィックに対するスケーリング戦略（キャッシュとリージョナルルーティングを含む）。 4. フェイルオーバー、一貫性の判断、地域停止への対処を含む信頼性戦略。 5. 主要なトレードオフ、ボトルネック、および少なくとも3つのリスクとその緩和策。 6. 上記の数値を用いたストレージとスループットに関する簡潔な容量見積もり。
システム設計
グローバルなURL短縮サービスの設計
Bitlyに似た公開URL短縮サービスを設計してください。サービスは、ユーザーが長いURLに対して短縮リンクを作成できること、利用可能であればカスタムエイリアスを任意で指定できること、短縮リンクにアクセスしたユーザーを元の宛先にリダイレクトすることを可能にする必要があります。総クリック数と過去30日間の日別クリック数を報告する基本的なアナリティクス機能を含めてください。 以下の制約を想定してください: - 月間で1億2000万件の新しい短縮リンクが作成される。 - 月間で12億件のリダイレクト要求が提供される。 - 読み取りトラフィックは特にバイラルリンクで非常にバーストしやすい。 - サービスはグローバルに利用され、ユーザーは低遅延のリダイレクトを期待する。 - 短縮リンクは少なくとも5年間有効である必要がある。 - リダイレクトの稼働率目標は99.99%である。 - アナリティクスは最終的に整合的であることが許容され、最大で10分程度の遅延がある場合がある。 - システムは基本的なレベルで明らかな悪用を防止する必要があるが、完全な信頼とセーフティプラットフォームは範囲外とする。 設計では次を網羅してください: - 高レベルのアーキテクチャと主要コンポーネント。 - リンクマッピングとアナリティクスのためのデータモデルとストレージの選択。 - カスタムエイリアスの取り扱いを含むIDまたはトークン生成戦略。 - リンク作成、リダイレクト、アナリティクス取得のためのAPI設計。 - キャッシング、パーティショニング、レプリケーション戦略。 - 障害対応とマルチリージョンの考慮を含む信頼性アプローチ。 - 読み取り重視のトラフィックとバイラルホットスポットに対するスケール方法。 - 一貫性、コスト、レイテンシ、運用の複雑さにおける主要なトレードオフ。 あなたが行う合理的な仮定を明示し、それらの選択を正当化してください。
システム設計
リアルタイム配車マッチングプラットフォームの設計
リアルタイムで複数の都市にまたがって乗客と近くのドライバーをマッチングする配車プラットフォームのバックエンドアーキテクチャを設計してください。 設計は次のプロダクト要件を満たすこと： - 乗客はピックアップ位置と目的地を送信して乗車をリクエストできる。 - 近くの利用可能なドライバーは迅速にリクエストを受け取り、1人のドライバーがそれを受諾できる。 - ドライバーの二重予約を防止しなければならない。 - 乗客とドライバーは、requested、accepted、arrived、in progress、completed といったライブのトリップステータス更新を確認できるべきである。 - 確認前に推定料金と推定ピックアップ時間を提示すること。 - 乗客とドライバーの双方にトリップ履歴を提供すること。 制約と仮定： - 1日あたり800万件のライドリクエスト。 - ピーク負荷は通勤時間帯において平均要求率の25倍。 - 40都市で運用、トラフィック分布は均一ではない（ホットスポットあり）。 - アクティブなドライバーからの位置更新は3秒ごとに到着する。 - 初期ドライバーマッチングに対する乗客向け許容レイテンシは p95 で2秒未満。 - トリップステータス更新は通常1秒以内に反映されるべきである。 - 地域のデータセンターでサービス障害が発生してもシステムは可用性を維持すること。 - 正確な決済処理の詳細は対象外だが、請求のためにトリップ記録は耐久的に保存されなければならない。 - プライバシー、安全性、規制上の懸念については簡潔に触れてよいが、主な焦点はアーキテクチャとスケーリングである。 回答では以下を説明してください： - 主なサービスまたはコンポーネントとそれぞれの責任。 - ライドリクエストからドライバー割当、トリップ完了までのデータフロー。 - ドライバー位置を効率的に保存・検索する方法。 - ピークトラフィックやホットスポット都市に対するスケーリング処理。 - 重要な箇所での信頼性、耐障害性、データ整合性の確保方法。 - 設計上の主要なトレードオフ（どこで最終的整合性を許容し、どこで強整合性を選ぶかを含む）。 厳密なクラウドベンダー製品名を挙げる必要はありません。詳細な実装よりも明確なアーキテクチャと理由付けに重点を置いてください。