システム設計における最新AI性能検証一覧

システム設計

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

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に対応する明確なセクションを持つ構造化プランとして提示してください。

22

2026/03/22 21:21

システム設計

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

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に対応する明確なセクションを持つ構造化された設計ドキュメントとして提示してください。

47

2026/03/20 17:43

システム設計

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

グローバルな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. 主にどのようなトレードオフを行ったか、その理由。

46

2026/03/20 11:03

システム設計

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

グローバルな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. 上記の数値を用いたストレージとスループットに関する簡潔な容量見積もり。

56

2026/03/19 18:51

システム設計

Anthropic Claude Opus 4.6 VS Google Gemini 2.5 Pro

グローバルなURL短縮サービスの設計

Bitlyに似た公開URL短縮サービスを設計してください。サービスは、ユーザーが長いURLに対して短縮リンクを作成できること、利用可能であればカスタムエイリアスを任意で指定できること、短縮リンクにアクセスしたユーザーを元の宛先にリダイレクトすることを可能にする必要があります。総クリック数と過去30日間の日別クリック数を報告する基本的なアナリティクス機能を含めてください。以下の制約を想定してください: - 月間で1億2000万件の新しい短縮リンクが作成される。 - 月間で12億件のリダイレクト要求が提供される。 - 読み取りトラフィックは特にバイラルリンクで非常にバーストしやすい。 - サービスはグローバルに利用され、ユーザーは低遅延のリダイレクトを期待する。 - 短縮リンクは少なくとも5年間有効である必要がある。 - リダイレクトの稼働率目標は99.99%である。 - アナリティクスは最終的に整合的であることが許容され、最大で10分程度の遅延がある場合がある。 - システムは基本的なレベルで明らかな悪用を防止する必要があるが、完全な信頼とセーフティプラットフォームは範囲外とする。設計では次を網羅してください: - 高レベルのアーキテクチャと主要コンポーネント。 - リンクマッピングとアナリティクスのためのデータモデルとストレージの選択。 - カスタムエイリアスの取り扱いを含むIDまたはトークン生成戦略。 - リンク作成、リダイレクト、アナリティクス取得のためのAPI設計。 - キャッシング、パーティショニング、レプリケーション戦略。 - 障害対応とマルチリージョンの考慮を含む信頼性アプローチ。 - 読み取り重視のトラフィックとバイラルホットスポットに対するスケール方法。 - 一貫性、コスト、レイテンシ、運用の複雑さにおける主要なトレードオフ。あなたが行う合理的な仮定を明示し、それらの選択を正当化してください。

62

2026/03/19 08:02

システム設計

Anthropic Claude Haiku 4.5 VS Google Gemini 2.5 Flash-Lite

リアルタイム配車マッチングプラットフォームの設計

リアルタイムで複数の都市にまたがって乗客と近くのドライバーをマッチングする配車プラットフォームのバックエンドアーキテクチャを設計してください。設計は次のプロダクト要件を満たすこと： - 乗客はピックアップ位置と目的地を送信して乗車をリクエストできる。 - 近くの利用可能なドライバーは迅速にリクエストを受け取り、1人のドライバーがそれを受諾できる。 - ドライバーの二重予約を防止しなければならない。 - 乗客とドライバーは、requested、accepted、arrived、in progress、completed といったライブのトリップステータス更新を確認できるべきである。 - 確認前に推定料金と推定ピックアップ時間を提示すること。 - 乗客とドライバーの双方にトリップ履歴を提供すること。制約と仮定： - 1日あたり800万件のライドリクエスト。 - ピーク負荷は通勤時間帯において平均要求率の25倍。 - 40都市で運用、トラフィック分布は均一ではない（ホットスポットあり）。 - アクティブなドライバーからの位置更新は3秒ごとに到着する。 - 初期ドライバーマッチングに対する乗客向け許容レイテンシは p95 で2秒未満。 - トリップステータス更新は通常1秒以内に反映されるべきである。 - 地域のデータセンターでサービス障害が発生してもシステムは可用性を維持すること。 - 正確な決済処理の詳細は対象外だが、請求のためにトリップ記録は耐久的に保存されなければならない。 - プライバシー、安全性、規制上の懸念については簡潔に触れてよいが、主な焦点はアーキテクチャとスケーリングである。回答では以下を説明してください： - 主なサービスまたはコンポーネントとそれぞれの責任。 - ライドリクエストからドライバー割当、トリップ完了までのデータフロー。 - ドライバー位置を効率的に保存・検索する方法。 - ピークトラフィックやホットスポット都市に対するスケーリング処理。 - 重要な箇所での信頼性、耐障害性、データ整合性の確保方法。 - 設計上の主要なトレードオフ（どこで最終的整合性を許容し、どこで強整合性を選ぶかを含む）。厳密なクラウドベンダー製品名を挙げる必要はありません。詳細な実装よりも明確なアーキテクチャと理由付けに重点を置いてください。

60

2026/03/19 07:43

システム設計

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

グローバルなURL短縮サービスの設計

Bitlyに類似した公開URL短縮サービスを設計してください。ユーザーは長いURLを送信して短いエイリアスを受け取り、誰でも短縮リンクを使って元のURLへリダイレクトできるようにします。あなたの設計は次の要件と制約を満たす必要があります: 機能要件: - 任意の有効なURLに対して短縮リンクを作成すること。 - 低レイテンシで短縮リンクをリダイレクトすること。 - 利用可能な場合に任意のカスタムエイリアスをサポートすること。 - リンクごとの基本的なクリック解析を提供すること：総クリック数、過去24時間のクリック数、およびクリック数上位5か国。 - リンクの有効期限を設定可能にすること。スケール想定: - 1日あたり1億2,000万件の新規短縮リンク作成。 - 1日あたり80億件のリダイレクト要求。 - 読み取り中心のワークロードで強いトラフィックスキュー：リンクのごく一部が非常に高いトラフィックを受ける。 - ユーザーは北米、ヨーロッパ、アジアにまたがるグローバルな分布。制約: - リダイレクトに対して99.99%の可用性目標。 - 主要地域のユーザーに対するP95リダイレクトレイテンシを80 ms未満。 - 新規作成されたリンクはグローバルに2秒以内に利用可能になること。 - 解析は最終的整合性で構わないが、リダイレクトは正確でなければならない。 - 予算は重要：どこにより強い整合性やマルチリージョン複製に費用をかけるか、どこを避けるかを正当化すること。 - サードパーティのマネージド解析製品は利用しないものとし、コアシステムを設計すること。以下を提供してください: - 主要コンポーネントとデータフローを含む高レベルのアーキテクチャ。 - リンクマッピング、解析イベント、およびホットリンクのキャッシュに関するストレージの選択。 - 衝突処理やカスタムエイリアスのチェックを含むID生成またはエイリアス戦略。 - create-link、redirect、and analytics retrieval のAPI設計。 - ホットキー、キャッシュ、パーティショニング、およびマルチリージョントラフィックに対するスケーリング手法。 - フェイルオーバー、データ複製、バックアップ、および劣化時の振る舞いを含む信頼性戦略。 - 主要なトレードオフと、検討して却下した少なくとも2つの代替設計選択肢。

53

2026/03/19 04:33

システム設計

Google Gemini 2.5 Pro VS OpenAI GPT-5 mini

大規模なURL短縮サービスの設計

あなたは、次の制約を満たさなければならないURL短縮サービス（bit.lyやtinyurl.comに類似）の設計を任されています： 1. サービスは月間1億件の新規URL短縮をサポートすること。 2. 読み取り対書き込み比率は100:1（つまり月間100億回のリダイレクト）であること。 3. 短縮URLは最大7文字（英数字）でなければならないこと。 4. 短縮URLは、ユーザーが明示的に削除しない限り、一度作成されたら決して期限切れにならないことをシステムで保証すること。 5. リダイレクトのレイテンシ（リクエスト受信からHTTP 301/302の発行まで）は、99パーセンタイルで10ミリ秒未満であること。 6. データセンター全体がオフラインになってもシステムは稼働し続けること。 7. サービスは短縮URLごとのクリック数、地理分布、リファラーデータを表示するオプションの分析ダッシュボードをサポートするが、分析はリダイレクト性能を劣化させてはならない。以下の点に対応した包括的なシステム設計を提示してください： A. ハイレベルなアーキテクチャ：主要コンポーネントとそれらの相互作用を説明してください。 B. URL生成戦略：一意の短縮コードをどのように生成するか、なぜそのアプローチを選んだか、衝突をどのように処理するか。 C. データモデルとストレージ：どのデータベースやストレージシステムを使用するか、その理由。スキーマに関する考慮点を含めてください。 D. 読み取りパスの最適化：与えられたスケールでリダイレクトのレイテンシ要件をどのように達成するか。 E. 書き込みパス：新しいURLをどのように作成し、確実に永続化するか。 F. スケーリング戦略：増加に対応するためにシステムをどのように水平スケールさせるか。 G. 信頼性と耐障害性：データセンター障害、レプリケーション、フェイルオーバーをどのように扱うか。 H. 分析パイプライン：リダイレクトのホットパスに影響を与えずに分析データをどのように収集、処理、提供するか。 I. 主要なトレードオフ：設計で行った少なくとも3つの重要なトレードオフを挙げ、それぞれを正当化してください。関連する場合は、技術、プロトコル、数値見積もり（例：ストレージ計算、QPS見積もり、キャッシュサイズ）について具体的に記述してください。

50

2026/03/18 22:59

システム設計

OpenAI GPT-5.2 VS Anthropic Claude Sonnet 4.6

リアルタイムのライドシェア通知システムの設計

あなたは、人気のライドシェアアプリケーション向け通知システムのハイレベルなアーキテクチャを設計する任務を負っています。システムは、1,000,000人のデイリーアクティブユーザー（DAU）と、1日あたり平均500,000件の乗車を処理でき、ラッシュアワー時にはピークが発生することに対応できなければなりません。システムは以下の種類の通知を配信する必要があります: 1. ドライバーが割り当てられた。 2. ドライバーがまもなく到着する（例: 2分以内）。 3. 乗車が完了し領収書が利用可能になった。 4. 特定の地理的エリアにいるユーザーを対象としたプロモーションメッセージ。あなたの設計提案は、以下の点に対処する必要があります: - コンポーネントとその相互作用のハイレベルなアーキテクチャの説明。 - 主要な技術選択（例: メッセージキューイング、データベース、プッシュ通知サービス）とそれらの選択理由。 - 低レイテンシ（配信時間2秒未満）と高信頼性（少なくとも1回配信）を確保するための戦略。 - ピーク時の負荷を処理するためにシステムをどのようにスケールさせるか。 - 設計で行った主要なトレードオフの議論（例: コスト対性能、一貫性対可用性）。

60

2026/03/18 20:31

システム設計

Anthropic Claude Sonnet 4.6 VS OpenAI GPT-5 mini

スケーラブルなリアルタイム通知システムの設計

あなたは、急速に成長しているソーシャルメディアプラットフォームのためにリアルタイム通知システムを設計する責務を負うシニアソフトウェアエンジニアです。システムは、現在オンラインのユーザーに対して（例：'新しいいいね'、'新しいコメント'、'友達リクエスト'）通知を配信できなければなりません。 **システム要件:** * **機能:** 1. ユーザーは異なる通知トピック（例：自分の投稿の更新、特定の友人からの更新）を購読できること。 2. イベント公開サービスは特定のトピックまたはユーザーにメッセージを送信できること。 3. 購読していてオンラインのユーザーは関連する通知をリアルタイムで受信すること。 * **非機能（制約）:** 1. **スケーラビリティ:** システムは100万の同時オンラインユーザーと、秒間1万件の通知のピーク負荷をサポートすること。 2. **レイテンシ:** 通知の99%はイベントが公開されてから200ミリ秒以内にユーザーのデバイスに配信されること。 3. **信頼性:** システムは通知の最低1回配信（at-least-once delivery）を保証すること。 4. **可用性:** システムは99.95%の稼働率を持つこと。 **あなたのタスク:** 高レベルなシステム設計を提示してください。あなたの回答は以下を網羅するべきです： 1. 全体アーキテクチャ（APIゲートウェイ、通知サービス、メッセージキュー、データベース、クライアント接続管理などの主要コンポーネントを含む）。 2. 主要コンポーネントのための技術選択とその理由（例：WebSockets vs. Long Polling、Kafka vs. RabbitMQ、NoSQL vs. SQL）。 3. 設計がスケーラビリティ、レイテンシ、信頼性、可用性の要件にどのように対処しているか。 4. 設計であなたが行った可能性のあるトレードオフに関する議論。

78

2026/03/16 05:05

システム設計

Google Gemini 2.5 Flash-Lite VS Anthropic Claude Opus 4.6

グローバルな読み取りトラフィック向けのURL短縮サービスを設計する

Bitlyに類似した本番環境向けのURL短縮サービスを設計してください。システムはユーザーが長いURLへリダイレクトする短縮リンクを作成できること、オプションのカスタム別名（エイリアス）をサポートすること、リンクごとの基本的なクリック解析を提供することを満たす必要があります。以下の要件と制約を仮定します： - 月間で1億2千万件（120 million）の新しい短縮リンクが作成される。 - 月間で15億件（1.5 billion）のリダイレクトが発生する。 - ニュースイベントやマーケティングキャンペーン時に読み取りトラフィックが非常にバーストしやすい。 - リダイレクトのレイテンシは、北米およびヨーロッパのユーザーに対して95パーセンタイルで80ms未満であること。 - データセンターが1箇所ダウンしても短縮リンクは引き続き機能すること。 - 解析は完全にリアルタイムである必要はないが、通常は5分以内に表示されること。 - ユーザーは作成から10分以内のみ宛先URLを更新できる。 - リンクはユーザー定義の任意の時刻で有効期限を設定できる。 - 悪用防止は重要：明らかなスパムや悪意のあるリダイレクトを減らす必要があるが、深いセキュリティ実装の詳細までは求められない。回答には以下を含めてください： - 高レベルのアーキテクチャと主要コンポーネント。 - コアデータモデルとストレージの選択。 - リンク作成、リンク解決（リダイレクト）、解析を読むためのAPI設計。 - トラフィック成長とバースト処理のためのスケーリング戦略。 - 信頼性およびディザスタリカバリのアプローチ。 - ID生成、データベース選択、キャッシュ、一貫性、解析パイプライン設計を含む主要なトレードオフ。 - システムを監視し障害を検出する方法についての簡単なメモ。

64

2026/03/16 04:45

システム設計

OpenAI GPT-5 mini VS Anthropic Claude Opus 4.6

リアルタイムEコマース通知システムの設計

あなたは急成長中のEコマース企業で働くシニアソフトウェアエンジニアです。あなたのタスクはリアルタイム通知システムを設計することです。このシステムは、注文ステータスの更新（例：「発送済み」、「配達済み」）、ウィッシュリスト内商品の価格下落、フラッシュセールの告知など、さまざまなイベントについてユーザーに通知する必要があります。このシステムのハイレベルなアーキテクチャを設計してください。設計は以下の要件に対応している必要があります： 1. **高スループット:** システムは主要なセールイベント時のようなピーク時に分間最大100,000件の通知を処理できること。 2. **低遅延:** イベント発生から99%の通知がユーザーのデバイスに5秒以内に配信されること。 3. **信頼性:** 通知の少なくとも一度配信（at-least-once delivery）を保証すること。注文更新のような重要な通知が失われてはならない。 4. **スケーラビリティ:** アーキテクチャは将来のユーザーベースおよび通知量の増加に対応して水平スケールできること。 5. **パーソナライゼーション:** 特定のユーザーセグメント（例：ある商品カテゴリに興味のあるユーザー）にターゲットを絞った通知送信をサポートすること。提案するアーキテクチャ（主要コンポーネントとそれらの相互作用を含む）を説明してください。使用する技術（例：メッセージキュー、データベース、プッシュ通知サービス）を説明し、設計決定を正当化してください。特に一貫性、可用性、コストに関するトレードオフについて議論してください。

64

2026/03/15 11:23

システム設計

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

大規模なURL短縮サービスの設計

あなたは以下の制約を満たさなければならないURL短縮サービス（bit.lyやtinyurl.comに類似）を設計する任務を負っています： 1. サービスは月間1億件の新しいURL短縮をサポートしなければならない。 2. 読み取り対書き込みの比率は100:1（つまり月間100億件のリダイレクト）である。 3. 短縮されたURLは最大7文字（英数字）でなければならない。 4. 短縮URLは推測可能または連続的であってはならない。 5. システムは稼働率99.9%を達成しなければならない。 6. リダイレクトのレイテンシは95パーセンタイルで10ms未満でなければならない。 7. 短縮URLは設定可能なTTL（既定5年）後に失効し、失効したURLは再利用可能でなければならない。 8. サービスは災害復旧のため少なくとも2つの地理的リージョンで稼働しなければならない。次の点に対処する包括的なシステム設計を提示してください： - ハイレベルなアーキテクチャ図の説明（テキストでコンポーネントとその相互作用を明確に説明） - URL短縮アルゴリズムとキー生成戦略、衝突を回避し非推測性を確保する方法を含む - データベーススキーマとストレージ技術の選択、及びその正当化 - キャッシュ戦略とキャッシュ無効化のアプローチ - 読み取りパスと書き込みパスを個別に記述し、推定スループット計算を含める - スケーリング戦略：トラフィックが10倍に増加した場合の対応方法 - マルチリージョン展開とデータ整合性モデル、選択したトレードオフ（CAP定理に基づく理由付け） - TTLの失効とURL回収メカニズム - 障害モードとシステムの復旧方法（少なくとも3つの具体的な障害シナリオ） - あなたが行った主要なトレードオフと、検討したが却下した代替案、その理由数値、技術選択、アーキテクチャ上の理由付けを具体的に示してください。曖昧な一般論は避けてください。

73

2026/03/14 19:35

システム設計

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash-Lite

URL短縮サービスの設計

基本的なリンク短縮サービスに類する公開URL短縮サービスを設計してください。サービスは利用者が長いURLを送信して短いコードを受け取り、その短縮URLから元の宛先に訪問者をリダイレクトできるようにします。回答では、実用的で上位レベルの設計を提案し、以下を網羅してください： - コアとなる機能要件 - 主要な非機能要件 - 主要なAPIエンドポイント - データモデル - 短縮コードの生成方法と一意性の保証方法 - 読み取り（リダイレクト）および書き込み（短縮作成）のリクエストフロー - ストレージの選択とキャッシュ戦略 - 読み取り負荷の重いトラフィックに対するスケーリング手法 - 有効期限切れや削除されたリンクの扱い - 基本的な濫用防止とレートリミティング - 信頼性に関する考慮点と想定されるボトルネック - トレードオフと仮定設計の深さは中程度に保ってください：実装可能な程度に具体的にしつつ、ベンダー固有の詳細や本番運用専用の細部には踏み込みすぎないでください。

64

2026/03/13 02:11

システム設計

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

URL短縮サービスの設計

bit.lyやTinyURLのようなURL短縮サービスを設計してください。設計は以下の側面を考慮する必要があります。 1. **機能要件**: サービスがサポートする必要があるコア機能は何ですか？URLの作成、リダイレクト、有効期限、分析を考慮してください。 2. **高レベルアーキテクチャ**: システムの主要コンポーネント（例：APIレイヤー、アプリケーションサーバー、データベース、キャッシュ、ロードバランサー）を説明してください。それらがどのように相互作用するかを説明してください。 3. **URLエンコーディング戦略**: 各URLに短くユニークなキーをどのように生成しますか？アプローチ（例：ハッシュ化、base62エンコーディング、事前生成キーサービス）について議論し、衝突をどのように処理するかを説明してください。 4. **データベース設計**: どのようなデータベースを使用し、その理由は何ですか？コアテーブルのスキーマを提供してください。このユースケースにおけるSQLとNoSQLのトレードオフについて議論してください。 5. **スケーラビリティとパフォーマンス**: 高い読み取りトラフィック（例：1日あたり数百万のリダイレクト）をどのように処理しますか？キャッシュ戦略、データベースパーティショニングまたはシャーディング、リードレプリカについて議論してください。 6. **信頼性と可用性**: コンポーネントが失敗した場合、サービスが利用可能であることをどのように保証しますか？冗長性、レプリケーション、フェイルオーバー戦略について議論してください。 7. **レート制限と不正利用防止**: サービスが悪用されるのをどのように防ぎますか？実装の出発点としてシニアエンジニアが使用できる、明確で構造化された計画を提供してください。月間1億件の新規URLと100:1の読み取り/書き込み比率を想定した概算容量見積もりを含めてください。

70

2026/03/11 17:55

システム設計

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

食品配達アプリのためのリアルタイムドライバー追跡システムの設計

あなたは、人気の食品配達サービスのためのリアルタイムドライバー追跡システムのハイレベルアーキテクチャを設計するタスクを任されています。このサービスは、ピーク時には 50,000 人のアクティブなドライバーと 200,000 人のアクティブな顧客を抱えています。次の側面をカバーするシステムアーキテクチャについて説明してください。 1. ドライバーのモバイルデバイスがバックエンドに位置データを送信する方法。 2. この位置データを処理および配布するために必要なバックエンドサービス。 3. 顧客のモバイルデバイスが特定の注文のリアルタイム位置更新を受信する仕組み。 4. 通信プロトコル（例：HTTPポーリング、WebSocket、MQTT）の選択とその選択の正当性。 5. ドライバーの位置と注文情報を格納するためのデータモデル。 6. ピーク時の負荷に対応するためのスケーリング戦略。

79

2026/03/10 09:38

システム設計

OpenAI GPT-5.4 VS Anthropic Claude Haiku 4.5

リアルタイム共同編集ホワイトボードの設計

リアルタイム共同編集ホワイトボードアプリケーションのシステムを設計してください。設計は以下のコア機能をサポートする必要があります。 - 複数のユーザーが同時に単一のホワイトボードセッションに参加し、操作できること。 - ユーザーは自由形式の線を描画したり、テキストボックスを追加したり、基本的な図形（例：長方形、円）を配置したりできること。 - 1人のユーザーが行ったすべての変更は、セッション内の他のすべてのユーザーにほぼリアルタイム（500ミリ秒未満の遅延）で表示されること。 - システムは、ホワイトボードセッションあたり少なくとも50人の同時ユーザーを処理できること。応答は、ハイレベルアーキテクチャの概要を示す計画である必要があります。主要なコンポーネント（クライアント側、サーバー側）、それらの間の通信プロトコル、およびデータモデリングと永続化の戦略を説明してください。特に、リアルタイムデータ同期の処理方法と、複数のユーザーが同時にキャンバスを編集する際の潜在的な競合の解決方法を説明してください。

94

2026/03/09 11:21

お題・ディスカッション一覧

URL短縮サービスの設計

URL短縮サービスの設計

グローバルなURL短縮サービスを設計する

グローバルなURL短縮サービスの設計

グローバルなURL短縮サービスの設計

リアルタイム配車マッチングプラットフォームの設計

グローバルなURL短縮サービスの設計

大規模なURL短縮サービスの設計

リアルタイムのライドシェア通知システムの設計

スケーラブルなリアルタイム通知システムの設計

グローバルな読み取りトラフィック向けのURL短縮サービスを設計する

リアルタイムEコマース通知システムの設計

大規模なURL短縮サービスの設計

URL短縮サービスの設計

URL短縮サービスの設計

食品配達アプリのためのリアルタイムドライバー追跡システムの設計

リアルタイム共同編集ホワイトボードの設計

関連リンク