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

比較ジャンル

すべて見る 333 ディスカッション 70 小説・創作 18 プログラミング 17 システム設計 17 教育問題 16 解説 15 要約 17 アイデア出し 16 ロールプレイ 15 ビジネス文書 16 計画立案 16 分析 17 ブレインストーミング 15 説得 16 お笑い 16 共感 18 カウンセリング 18

モデル一覧

すべて見る GPT-5.4 (OpenAI) GPT-5.2 (OpenAI) GPT-5 mini (OpenAI) Claude Opus 4.6 (Anthropic) Claude Sonnet 4.6 (Anthropic) Claude Haiku 4.5 (Anthropic) Gemini 2.5 Pro (Google) Gemini 2.5 Flash (Google) Gemini 2.5 Flash-Lite (Google)

システム設計

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秒以内に反映されるべきである。 - 地域のデータセンターでサービス障害が発生してもシステムは可用性を維持すること。 - 正確な決済処理の詳細は対象外だが、請求のためにトリップ記録は耐久的に保存されなければならない。 - プライバシー、安全性、規制上の懸念については簡潔に触れてよいが、主な焦点はアーキテクチャとスケーリングである。回答では以下を説明してください： - 主なサービスまたはコンポーネントとそれぞれの責任。 - ライドリクエストからドライバー割当、トリップ完了までのデータフロー。 - ドライバー位置を効率的に保存・検索する方法。 - ピークトラフィックやホットスポット都市に対するスケーリング処理。 - 重要な箇所での信頼性、耐障害性、データ整合性の確保方法。 - 設計上の主要なトレードオフ（どこで最終的整合性を許容し、どこで強整合性を選ぶかを含む）。厳密なクラウドベンダー製品名を挙げる必要はありません。詳細な実装よりも明確なアーキテクチャと理由付けに重点を置いてください。

63

2026/03/19 07:43

システム設計

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生成、データベース選択、キャッシュ、一貫性、解析パイプライン設計を含む主要なトレードオフ。 - システムを監視し障害を検出する方法についての簡単なメモ。

73

2026/03/16 04:45

システム設計

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash-Lite

URL短縮サービスの設計

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

68

2026/03/13 02:11

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

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

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

URL短縮サービスの設計

関連リンク