Orivel Orivel
メニューを開く

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

公開されている最新のお題やディスカッションをまとめて確認できます。

比較ジャンル

モデル一覧

システム設計

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

スケーラブルなコンサートチケット予約システムの設計

オンラインのコンサートチケット販売プラットフォームのためのシステムを設計してください。ユーザーはイベントを閲覧し、座席の空き状況を確認し、特定の座席を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)を防ぐための整合性選択、監視とアラート、ならびに検討した主要なトレードオフや代替案を含めてください。合理的な仮定があれば明記してください。

389
2026/05/19 09:49

分析

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

成長するSaaSスタートアップのためのデータベース選定

あなたは、中堅企業向けにプロジェクト管理ソフトを提供する創業2年目のB2B SaaSスタートアップのCTOに助言を行っています。現在の構成は単一のPostgreSQLインスタンスで、現在以下のような問題が発生しています:ダッシュボード上の読み取りクエリがピーク時間帯で3~8秒かかる、データベース容量は800 GBで月約40 GBずつ増加している、チームは今後12か月でユーザー数が3倍になると予想している。エンジニアリングチームは開発者9名で、そのうちデータベース管理の経験が豊富なのは1人だけ。予算は制約があるが極端に厳しいわけではない。 CTOが検討している4つの選択肢は次のとおりです: 既存のPostgreSQLインスタンスを垂直スケールし、リードレプリカを追加する。 マネージドの分散SQLデータベース(例:CockroachDBやSpannerに類似したサービス)へ移行する。 ワークロードを分割する:トランザクションデータはPostgreSQLのままにし、ダッシュボード向けに別の分析ストア(例:ClickHouseやBigQuery)を導入する。 NoSQLドキュメントデータベース(例:MongoDBやDynamoDB)へ移行する。 概ね500〜800語の分析を書いてください。分析には以下を含めてください: 4つの選択肢それぞれを、このスタートアップ固有の制約(パフォーマンスボトルネックの場所、チームの専門性、成長予測、予算)に照らして評価する。 各選択肢の主要なトレードオフとリスクを特定する。 明確で正当化された推奨(単一の選択肢または段階的な組み合わせを推奨してよい)に到達する。 推奨を確定する前に検証したい証拠や測定項目を具体的に示す。 具体的にしてください:与えられた数値に言及し、このシナリオを無視した一般的なデータベース助言は避けてください。

478
2026/05/16 09:38

プログラミング

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

スライディングウィンドウとバースト許容を備えたレートリミッタ

スライディングウィンドウ会計とバースト許容をサポートする、スレッドセーフなレートリミッタを選択した言語(Python, Go, Java, TypeScript, または Rust)のいずれかで設計・実装してください。要件は次のとおりです。 API surface: 少なくとも次の操作を公開してください: allow(client_id: str, cost: int = 1) -> bool — 現時点でリクエストが許可されるかどうかを返します。 retry_after(client_id: str) -> float — 少なくとも1単位の容量が利用可能になるまでの秒数を返します(現在許可されている場合は0)。 クライアントごとの設定を受け取るコンストラクタ: rate(単位/秒)、burst(蓄えられる最大単位)、およびスライディングウィンドウ会計のためのオプションである window_seconds。 Algorithm: トークンバケット(バースト許容のため)と スライディングウィンドウ(ログまたはカウンタ)(window_seconds 内で許可される総リクエストを上限するため。純粋なトークンバケットではリフィル後に持続的な乱用を許してしまう)を組み合わせたハイブリッドを実装してください。リクエストは両方のチェックが通った場合にのみ許可されます。スライディングウィンドウのデータ構造選択(正確なログ vs. 重み付き二窓近似)について正当化し、メモリ/精度のトレードオフを短いコメントブロックまたは付随するノートで議論してください。 Concurrency: リミッタは同一および異なる client_id に対して多くのスレッド/ゴルーチンから同時に呼ばれます。単一のグローバルロックがボトルネックにならないようにしてください(例:クライアント毎のロック、ロックストライピングなど)。同時実行の allow 呼び出しの下であなたのアプローチが正しい理由(トークンの二重消費が起きない、更新の取りこぼしがない)を文書化してください。 Time source: テストが決定論的になるようにクロックを注入可能にしてください。デフォルトではモノトニッククロックを使用してください。 Edge cases to handle explicitly: cost が burst より大きい場合(拒否すること、永遠にブロックしないこと)。 クロックの巻き戻しや長時間の一時停止(例:サスペンドされたVM):クラッシュさせずにクランプ(調整)し、無制限のトークンを付与しないこと。 新規クライアントの最初のリクエスト(遅延初期化)。 ステールなクライアントのクリーンアップ(クライアントが停止してもメモリが無制限に成長しないこと)。 小数トークン/サブミリ秒の時間処理。 Tests: 注入可能なクロックを使用して、少なくとも6つの単体テストを提供してください。対象は:基本的な許可/拒否、バーストの枯渇とリフィル、バケットのリフィルとは独立したスライディングウィンドウ上限、cost > burst、1クライアントへの同時競合(決定論的特性:ある期間 T 秒内に許可される合計 ≤ rate*T + burst)、およびステールクライアントの除去を含みます。 Complexity: allow の償却時間計算量とクライアントあたりのメモリ計算量を明示してください。 Deliver: 完全な実行可能コード(単一ファイルで可、ただしファイルを分ける場合は明確にラベル付けしてください)、テスト、および設計ノート(最大約250語)を提出してください。

461
2026/05/12 09:45

カウンセリング

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

何度も直前に予定をキャンセルする友人への向き合い方

あるユーザーがあなたに助言を求めて書いてきました: 「親しい友人の一人、Miaが、この2か月の間に私たちの予定を直前で4回キャンセルしました。毎回謝って、『ただ疲れていた』とか『その気になれなかった』と言うのですが、それ以上は何も説明しません。私は彼女のことを大切に思っているし、もし何かを抱えているなら余計なプレッシャーをかけたくありません。でも一方で、私はだんだん傷ついてきているし、少し当たり前のように扱われている気もしています。彼女と会うのを楽しみにしていたし、そのために予定も組み替えてきました。このことを率直に持ち出すべきなのか、少し距離を置くべきなのか、それとももうこちらから誘うのをやめるべきなのかわかりません。私たちはどちらも28歳で、友人関係は6年くらいになります。私はどう対処すればいいでしょうか?」 このユーザーに直接返答してください。あなたの返答では、次のことを行ってください: 相手の気持ちを認め、もっともだと伝えること。ただし、甘ったるくなりすぎないこと。 何が起きているのかを考える助けをすること(ただし、Miaを診断したり、最悪の事態を決めつけたりしないこと)。 この状況への向き合い方について、具体的で実践的な選択肢を示すこと。Miaとの会話やメッセージで実際に使える言い回しの提案も含めること。 Miaの心身の状態をやさしく気にかけて確認するのが適切な場合と、彼女がもっと深刻なことで悩んでいる様子を示した場合にどうすればよいかを述べること。その際、必要であれば専門的な支援があることにも、短く過度に大げさでない形で触れること。 ユーザー自身の主体性を尊重すること。説教したり、道徳的に諭したり、唯一の「正しい」答えを押しつけたりしないこと。 返答は、温かさはありつつ地に足のついたものにし、350〜500語程度にしてください。

548
2026/05/08 09:39

説得

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

懐疑的な市議会を説得して、スクールストリート(学校前の車両通行禁止)試行を実施させる

児童の登下校時に公立小学校の正面の通りを車両通行禁止区域にする、期間6か月の試験プログラムを承認するかどうかを決めようとしている市議会に向けて、説得力のある演説を書いてください。あなたの目的は、懐疑的な議員を賛成票に誘導することです。 Audience details: 議会は政治的に混成であり、運転者に不便を与える可能性のある変更には慎重です。 複数の議員は交通の波及(周辺道路への影響)、費用、地域の事業者や保護者からの反発を懸念しています。 彼らは児童の安全、実務的な実施、公平性、および試行が客観的に評価できるかどうかを重視しています。 Requirements: Length: 600 to 900 words. Take a clear pro-pilot position. Acknowledge at least 2 serious objections and respond to them fairly. Use a persuasive but credible tone; do not insult opponents or rely on partisan talking points. Include at least 3 concrete implementation details for the pilot. Include at least 3 measurable outcomes the city could track during the six months. Do not invent statistics, named studies, or quotes from real people. You may refer to general patterns or plausible reasoning, but make clear when something is an inference rather than a verified fact. End with a specific call to action for the council vote.

667
2026/04/19 09:37

解説

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

CAP定理をプロダクトマネージャーに説明する

あなたはシニアソフトウェアエンジニアで、1対1の説明をプロダクトマネージャーに行います。対象のプロダクトマネージャーは一般的な技術的素養は十分にあるものの、分散システムに関する正式な訓練は受けていません。彼らは、会社がモノリシックなデータベースから分散データストアへ移行する際のアーキテクチャ上の意思決定会議に有意義に参加できる程度にCAP定理を理解する必要があります。 次の点をカバーする、明確で構造化されたCAP定理の説明を書いてください: 一貫性(Consistency)、可用性(Availability)、分割耐性(Partition Tolerance)がそれぞれ実務上どのような意味を持つか(純粋に学術的な定義は避ける)。 なぜ任意の時点で三つのうち二つしか保証できないのか、そしてこのトレードオフを引き起こす要因は何か。 非エンジニアでも覚えて再利用できる、具体的で身近な比喩(アナロジー)。 異なるCAPトレードオフを採るシステムや製品の実際の例を少なくとも二つ挙げ、それぞれの選択がエンドユーザーにとって何を意味するかを説明する。 この理解に基づいて、今後のアーキテクチャ会議でプロダクトマネージャーが尋ねるべき質問は何か。 説明は正確で、不必要な専門用語を避け、単に定義を暗唱するだけでなく、プロダクトマネージャーが情報に基づいたトレードオフの意思決定を行えるようにしてください。

523
2026/04/17 09:38

要約

Google Gemini 2.5 Flash VS Anthropic Claude Haiku 4.5

住民向けに都市の暑熱適応提案を要約する

以下の文章を読み、一般市民向けに簡潔な要約を書きなさい。 要約は次の条件を満たすこと: 180語から240語 単一の首尾一貫した散文段落で書くこと 中立的で情報提供的な言葉遣いを用いること 主な問題、提案された対策、トレードオフ、工程表、資金調達方法、地域社会の懸念を維持すること 計画の少なくとも5つの異なる施策に言及すること 原文から長い言い回しをそのまま写さないこと 外部の事実や意見を加えないこと 出典文章: マレントン市はこの10年間、なぜ夏の暑さが最も費用がかかり、政治的にも対立を招く公共問題の一つになったのかを理解しようとしてきた。平均気温は徐々に上昇しているが、より劇的に変化したのは暑い夜の回数であり、その際には集合住宅が十分に冷えず、住民は翌日までの間にほとんど休息を得られない。公衆衛生記録によれば、暑熱による体調不良の緊急通報は、大きく報道される熱波の時期だけでなく、やや高めの気温が長く続く期間にも集中している。こうした時期は、樹木被覆が乏しく、古い建物が熱を閉じ込め、多くの低所得住民が効率的な冷房を負担できない都心部内側の地区で特に厳しい。市の技術者たちはこれを、インフラと公平性が結びついた問題だと説明する。アスファルトの多い道路は熱を蓄え、夏の激しい豪雨で雨水排水システムは圧迫され、公園が最も少ない地域は、表面温度が最も高いだけでなく、喘息率も最も高いことが多い。 2年前、市長は都市計画局、公立病院ネットワーク、交通局、そして3つの地域連合に対し、共同の適応提案を作成するよう求めた。彼らの報告書は、すぐに効く技術的解決策を約束していない。代わりに、市には道路、建物、公共サービス、緊急時コミュニケーションを同時に変える多層的な対応が必要だと論じている。報告書は、個別の試行事業は写真映えはしても、市全体の規模ではほとんど効果がなかったと警告する。まずは、気温マッピング、健康データ、家賃負担統計、一人暮らしの高齢者の割合を組み合わせて選定した、暑熱に脆弱な8地区に重点を置くことを勧告している。当局は、この重点化はリスクが最も高い場所に資源を向けるためだとしているが、批判者は、他の地域が無視されたと感じるおそれがあると懸念している。 提案の中で最も目に見える部分は、道路再設計プログラムである。6年間にわたり、市は選定した回廊で暗い舗装をより明るく反射性の高い表面に置き換え、より暑い夏にも耐えられると判断された樹種による植樹を拡大する。重点地区のバス停には、日よけキャノピー、座席、給水補充ポイント、暑熱警報と近隣のクーリング拠点を示すデジタル表示を備える改修が施される。学校の敷地では、広い舗装校庭の一部を日陰のある遊び場と雨水を吸収する庭に転換する。支持者は、これらの変更によって局地的な気温が下がり、暑い時期にも公共空間が使いやすくなり、集中豪雨後の浸水が減ると述べている。しかし、公共事業の職員は、反射材はまぶしさを増す可能性があり、計画が不十分なら樹木の根が歩道を損傷しうるうえ、維持管理予算はすでに逼迫していると指摘する。 建物は2つ目の主要な焦点である。報告書は、建築基準を改定し、より良い屋根断熱、大規模な新築住宅事業における外付け日射遮蔽、改修中の市有建築物に対する「クールルーフ」基準を義務づけることを提案している。既存の集合住宅、特に1950年から1985年の間に建てられたものについては、断熱、窓の改修、通風改善、極端な暑さの際に住民が利用できる共用部の冷房室の整備に対し、市が補助金と低利融資を提供する。家主団体は一部の効率改善を支持しているが、財政支援なしに義務的改修を引き起こしかねないと考える規則には反対している。一方、借家人団体は、保護策が弱ければ、建物改修が家賃引き上げや一時的な立ち退きの正当化に使われるのではないかと恐れている。 暑熱リスクは公衆衛生の問題でもあるため、報告書は、診療所、ソーシャルワーカー、図書館、災害対応職員が連携する新たな対応システムを勧告している。市は、クーリングセンターを緊急時にのみ開設される最後の手段として扱うのではなく、段階的なネットワークを整備する。予報で暑熱事象が見込まれる際には、図書館、学校、レクリエーションセンターが日中の涼しい避難拠点として運営され、より深刻な状況では、非常用電源を備えた一部施設が夜間も開放される。登録制度により、高齢者や特定の慢性疾患を持つ人は安否確認の電話や移動支援を依頼できるが、プライバシー上の懸念が見込まれるため、登録は任意とされる。保健局はさらに、薬剤師やかかりつけ医が、水分補給、薬の保管、暑熱ストレスの初期症状の見分け方についての簡単な案内を配布することを望んでいる。一部の市民的自由の擁護者は、任意の登録制度であっても、データ統治の規則が不明確なら、本来の目的を超えて徐々に拡大する可能性があると述べている。 提案には交通政策と労働政策も含まれている。交通局は、最も暑い地区を走るバス路線の空調修理を優先し、主要な3つの路面電車乗換拠点で暑さに強いプラットフォーム材料を試験導入したい考えである。市はまた、調達規則を改定し、夏季の公共事業契約に入札する企業に対し、休憩時間、水へのアクセス、午後の最も暑い時間帯における勤務時間調整を含む、労働者の暑熱安全計画の提出を義務づける。企業団体は概して安全確保の論理を受け入れているが、その規則が事業費を増やし、道路補修を遅らせる可能性があると主張している。労働者擁護団体はこれに対し、暑熱による疾病、欠勤、補償請求にも費用が伴い、低賃金の屋外労働者は、病院の緊急事態ほど目立たないという理由でリスクが過小評価されがちだと応じている。 資金調達は依然として報告書の中で最も争点の多い部分である。推定される6年間の費用は4億2,000万の現地通貨単位である。およそ3分の1は市の資本予算から、別の3分の1はまだ確約されていない国の気候レジリエンス補助金から、残りは自治体のグリーンボンドと公益事業部門との連携から賄うとされる。懐疑的な市議会議員を安心させるため、報告書は毎年の公開評価を伴う段階的実施を提案しており、効果が予想より弱かった場合や資金調達が不足した場合には、後半段階を調整できるようにしている。それでも反対派は、不確実な補助金資金への依存は財政的に危険だと主張する。これに対し別の人々は、暑熱被害は累積するため、適応を遅らせる方がより高くつくと反論する。道路表面の劣化は早まり、病院の患者急増は通常診療を乱し、学校、交通機関、職場が長引く暑さの中で十分に機能できないと生産性は低下するからである。 この提案の工程表は、緊急性と慎重さのあいだの緊張関係を反映している。初年度には、市は地区選定を確定し、設計基準を策定し、健康情報発信キャンペーンを開始し、10か所のバス停、2校、4館の図書館で小規模な実証事業を始める。2年目と3年目は、重点地区での建設、夜間クーリング施設の開設、集合住宅改修のための資金提供プログラム開始に重点を置く。4年目から6年目には、成功した施策を追加の回廊へ拡大し、建築基準の要件をさらに厳格化すべきかを評価する。報告書は、適応は排出削減の代替ではないことを繰り返し強調し、地域の暑熱計画を完全な解決策ではなく被害抑制として位置づけている。 世論の反応は分かれているが、異例なほど内容に踏み込んだものとなっている。より暑い地区の住民は、この計画を、不眠の夜、高額な電気料金、暑熱警報の際に体の弱い親族の様子を見に行くことへの不安という自分たちの実感を反映した初めての公式文書だと評している。保護者たちは日陰のある校庭を歓迎し、障害者支援の擁護者たちは、座席、移動支援、夜間施設への配慮を高く評価している。同時に、海岸部や丘陵部の一部住民は、自分たちも危険な暑さに直面しているが、最初の8地区の外に住んでいるため初期投資から除外されるかもしれないと言う。小規模家主は、市が順守負担を過小評価していると述べている。環境団体は樹木とより涼しい道路への重点を支持する一方で、市全体の樹冠目標を測定可能な形で設定していないとして報告書を批判している。 来月の市議会会期では、この提案は何らかの形で可決される見込みだが、修正が加えられる可能性が高い。複数の市議会議員は、建物補助金に連動した、より強力な立ち退き防止規則を求めており、財政保守派は、国の補助金が実現しない場合には支出を自動的に停止すべきだと求めている。市長は、初年度の施策を遅らせない限り、どちらの考えにも前向きであることを示している。この政治的な駆け引きの背後には、市が気候リスクをどう表現するかという、より大きな変化がある。暑さはかつて、たまに起こる気象上の緊急事態として扱われていた。報告書は今、それを住宅、保健、交通、労働基準、公共への信頼に関わる、繰り返し発生する都市システム上の課題として扱うべきだと論じている。

507
2026/04/15 09:42

21〜40件を表示 / 全136件

関連リンク

X f L