Orivel Orivel
メニューを開く

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

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

比較ジャンル

モデル一覧

システム設計

Anthropic Claude Opus 4.6 VS OpenAI GPT-5.4

リアルタイム通知サービスの設計

ソーシャルメディアプラットフォーム向けのリアルタイム通知サービスについて、高レベルなシステム設計を概説してください。サービスは次の要件を満たす必要があります。 - **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).

188
2026/04/18 09:41

解説

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

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

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

184
2026/04/17 09:38

プログラミング

Anthropic Claude Sonnet 4.6 VS OpenAI GPT-5.4

Pythonでスレッドセーフなトークンバケットレートリミッタを実装する

`TokenBucketRateLimiter` という名前のPythonクラスを書いてください。このクラスはレート制限のためのトークンバケットアルゴリズムを実装します。実装はスレッドセーフであり、状態管理のために外部ライブラリ(たとえば Redis)の使用は避けてください。 クラスは次の仕様を満たす必要があります。 1. `__init__(self, capacity, refill_rate)` メソッド: * `capacity`: バケットが保持できるトークンの最大数。 * `refill_rate`: 1秒あたりにバケットに追加されるトークンの数。 2. `consume(self, tokens)` メソッド: * このメソッドはバケットから指定された数の `tokens` を消費しようとします。 * トークンを正常に消費できた場合は `True` を返し、そうでなければ `False` を返すべきです。 * 消費を試みる前に、最後の呼び出しから経過した時間に基づいてバケットがトークンで補充される必要があります。 3. スレッドセーフ性: * このクラスは複数の同時実行スレッドから安全に使用できなければなりません。バケットの状態を変更するすべての操作(トークンの補充や消費など)は原子的である必要があります。 必要なインポートを含めた完全なクラス実装を提供してください。

185
2026/04/16 09:37

要約

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地区の外に住んでいるため初期投資から除外されるかもしれないと言う。小規模家主は、市が順守負担を過小評価していると述べている。環境団体は樹木とより涼しい道路への重点を支持する一方で、市全体の樹冠目標を測定可能な形で設定していないとして報告書を批判している。 来月の市議会会期では、この提案は何らかの形で可決される見込みだが、修正が加えられる可能性が高い。複数の市議会議員は、建物補助金に連動した、より強力な立ち退き防止規則を求めており、財政保守派は、国の補助金が実現しない場合には支出を自動的に停止すべきだと求めている。市長は、初年度の施策を遅らせない限り、どちらの考えにも前向きであることを示している。この政治的な駆け引きの背後には、市が気候リスクをどう表現するかという、より大きな変化がある。暑さはかつて、たまに起こる気象上の緊急事態として扱われていた。報告書は今、それを住宅、保健、交通、労働基準、公共への信頼に関わる、繰り返し発生する都市システム上の課題として扱うべきだと論じている。

210
2026/04/15 09:42

アイデア出し

OpenAI GPT-5.2 VS Google Gemini 2.5 Pro

廃車後の電気自動車バッテリーの革新的活用法

電気自動車(EV)のバッテリーは、車両用途から引退する際に通常、元の容量の70~80%を保持しています。これにより、なお大きなエネルギー貯蔵能力を有する中古バッテリーの供給が増え続けています。 廃車後のEVバッテリーのセカンドライフ用途について、少なくとも8件以上の明確に異なるアイデアを生成してください。アイデアは住宅、商業、産業、農業、人道支援、レクリエーションなど複数のセクターにまたがり、即実用的なものからより野心的・非定型なコンセプトまで含めてください。 各アイデアについて以下を提供してください: 1. 応用の簡潔な名称 2. その仕組みと、なぜ廃車後のEVバッテリーがその用途に適しているかを説明する短い記述(2~4文) 3. 主な対象ユーザーまたは市場 4. 対処が必要な主要な課題や制約 制約: - アイデアのうち少なくとも3件は、開発途上国または農村地域のユーザーや文脈を対象とすること - アイデアのうち少なくとも2件は、従来の住宅用蓄電や系統安定化のような既存のセカンドライフバッテリー文献で一般的に議論されていない、型破りまたは驚きのあるコンセプトであること - 同じ中核コンセプトをわずかな変形で繰り返さないこと

170
2026/04/14 09:39

解説

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash-Lite

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

あなたはシニアソフトウェアアーキテクトで、正式な計算機科学のバックグラウンドはないものの技術に関する一般的な理解があるプロダクトマネージャーと面談しています。チームが新しいマイクロサービスプロジェクトのために2つの異なるデータベースソリューションのどちらかを選択しようとしており、そのトレードオフが製品の決定(例:ユーザーが時々古いデータを見る可能性があるか、ネットワーク障害時に特定の機能が利用できなくなるかどうか)に直接影響するため、プロダクトマネージャーはCAP定理を理解する必要があります。 この聴衆向けにCAP定理の明確な説明を書いてください。あなたの説明は次を満たすべきです: 1. 一貫性(Consistency)、可用性(Availability)、分断耐性(Partition Tolerance)を、実務的で学術的ではない用語で何を意味するか定義すること。 2. なぜ任意の時点で3つのうち2つしか真に保証できないのか、そしてなぜ分断耐性が分散システムではほとんど常に譲れない(non-negotiable)ものなのかを説明すること。 3. CP対APなど異なるCAPトレードオフを示す、システムやプロダクトシナリオの少なくとも2つの具体的な実例を提供し、それらがユーザー体験にどのような影響を与えるかを示すこと。 4. CAP定理に関する一般的な誤解(たとえば「常に一つの特性を永久に犠牲にしなければならない」という誤解)に簡潔に対処すること。 5. 最後に、プロダクトマネージャーが2つのデータベースオプションを評価する際に尋ねるべき質問の短い要約で締めくくること。 トーンはプロフェッショナルでありながらわかりやすくしてください — 専門用語を使う場合は説明を付け、見下すような口調は避けてください。

188
2026/04/13 09:39

システム設計

Google Gemini 2.5 Flash-Lite VS OpenAI GPT-5.2

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つの重要な設計上のトレードオフを特定し、提示された制約を踏まえてなぜ一方を選んだのかを説明してください。

175
2026/04/11 09:41

計画立案

Google Gemini 2.5 Flash-Lite VS Anthropic Claude Sonnet 4.6

小規模クリニックの停電復旧計画

あなたは、夜間の嵐によって全面的な停電が発生した後の小規模な外来クリニックに助言しています。クリニックの患者受け入れ開始は午前8:00で、現在は午前6:00です。今後6時間について、クリニックの意思決定と作業の順序を示す実務的な行動計画を作成してください。 クリニックの状況: - 午前6:30までに、医師1名、看護師2名、受付1名、施設担当スタッフ1名が現地にいます。 - バックアップ発電機は、給油前に合計最大4時間までしか重要負荷に電力を供給できません。対応できるのは次のいずれか一方のみです: オプションA: ワクチン用冷蔵庫 + 非常用照明 + インターネットルーター オプションB: 診察室2室 + 非常用照明 + 基本的な受付用コンピュータ 両方のオプションを同時に支えることはできません。 - ワクチン用冷蔵庫は、ワクチンの廃棄を避けるために十分に通電されていなければなりません。安全温度の上限を累計30分超えた時点で、すべてのワクチンを廃棄しなければなりません。 - インターネットサービスは、ルーターに電力が供給されている場合にのみ機能します。 - 水は利用可能ですが、電話システムは停止しています。スタッフは個人の携帯電話を使用できます。 - 午前8:00から午後12:00までの間に、18名の患者が予約されています: - 定期フォローアップ 5件 - ワクチン接種予約 4件 - 緊急だが生命に関わらない受診 3件 - 午前11:00までに実施しなければならない検体受け取り 2件 - インターネットが必要な遠隔診療 4件 - 近隣の薬局は午前9:00に開きます。 - 燃料供給業者は、給油は早くても午前10:30以降になる見込みとしていますが、保証はされていません。 - 看護師1名はワクチン温度の監視と予防接種の実施について訓練を受けていますが、もう1名は受けていません。 - 医師は対面診療または遠隔診療のいずれかを行えますが、同時にはできません。 あなたの計画は、以下を満たさなければなりません: - 午前6:00から午後12:00までを対象にすること - 患者安全、法的・臨床的な実行可能性、サービス中断の最小化を優先すること - 必要に応じて、いつ発電機を使用し、どの時間帯にどのオプションへ給電するかを決定すること - 必要に応じて患者予約の優先順位を付け直し、または再調整すること - 利用可能なスタッフの役割に責任を割り当てること - 少なくとも3つの主要なリスクまたは障害点と、その対処方法を含めること - 不確実性を現実的に考慮し、追加の人員や機器があると仮定しないこと 回答は、段階的な運用計画として書いてください。

207
2026/04/10 09:41

プログラミング

Anthropic Claude Haiku 4.5 VS OpenAI GPT-5.4

コマンドライン ファイル同期ツール

Python スクリプトを作成してください。コマンドライン用のファイル同期ツールです。 スクリプトは次の3つのコマンドライン引数を受け取る必要があります: 1. `source_path`: ソースディレクトリへのパス。 2. `replica_path`: 同期されるレプリカディレクトリへのパス。 3. `log_file_path`: すべての操作が記録されるファイルへのパス。 コア機能: 1. **一方向同期:** ツールは一方向の同期を行い、`replica_path` ディレクトリを `source_path` ディレクトリの正確なコピーにします。 - ソースに存在しレプリカに存在しないファイルおよびディレクトリはレプリカにコピーされなければなりません。 - レプリカに存在しソースに存在しないファイルおよびディレクトリはレプリカから削除されなければなりません。 - 両方に存在するが内容が異なるファイルはレプリカで更新されなければなりません(ソースのバージョンがレプリカのバージョンを上書きします)。 2. **変更検出:** ファイルの更新が必要かどうかを判断するために、ファイル内容の MD5 ハッシュを使用してください。更新時刻には依存しないでください。 3. **ログ記録:** すべてのファイル操作(例: "COPY file.txt", "REMOVE old_dir", "UPDATE changed.log")をコンソールと指定されたログファイルの両方に記録してください。各ログエントリにはタイムスタンプを付けてください。 4. **実行:** スクリプトは同期操作を一度だけ実行して終了するようにしてください。ループで実行してはいけません。 要件: - Python 3 を使用すること。 - コマンドライン引数の解析には `argparse` ライブラリを使用すること。 - 解決策はネストされたディレクトリ、空のディレクトリ、およびさまざまなサイズのファイルを正しく扱う必要があります。 - スクリプトは単一の、自己完結型のファイルであること。

203
2026/04/09 09:38

41〜60件を表示 / 全483件

関連リンク

X f L