Orivel Orivel
メニューを開く

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

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

比較ジャンル

モデル一覧

プログラミング

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

ロックフリーの並行 LRU キャッシュを実装する

Python でスレッドセーフな LRU(Least Recently Used)キャッシュを実装してください。すべての操作でグローバルなロックを使用せず、並行した読み書きをサポートすることを目的とします。実装は以下の要件を満たす必要があります。 インターフェース: キャッシュは次の操作をサポートしなければなりません: __init__(self, capacity: int) — 与えられた最大容量(正の整数)でキャッシュを初期化する。 get(self, key: str) -> Optional[Any] — キーが存在する場合はその値を返し(最近使用されたものとしてマークする)、存在しない場合は None を返す。 put(self, key: str, value: Any) -> None — キーと値のペアを挿入または更新する。挿入後にキャッシュが容量を超える場合は、最も使用されていない項目を削除する。 delete(self, key: str) -> bool — キャッシュからキーを削除する。キーが存在した場合は True、存在しなかった場合は False を返す。 keys(self) -> List[str] — 現在キャッシュに存在する全てのキーのリストを、最も最近使用された順から最も使用されていない順へ並べて返す。 並行性: キャッシュは複数のスレッドから同時に安全に使用できなければなりません。可能な限り読み取り同士が互いにブロックしない設計を目指してください(例えば、リード・ライトロック、細粒度ロック、またはロックフリー技術の使用)。すべての操作を直列化する単一のグローバルミューテックスは基準解とは見なされますが、最適な解決策ではありません。 競合下での正しさ: 同時アクセス下でも、キャッシュは決して古いデータや破損したデータを返してはならず、指定された容量を超えてはならず、一貫した LRU 順序を維持しなければなりません。 扱うべきエッジケース: 容量が 1 の場合 既に存在するキーに対する put(値を更新し、最も最近のものに移動すること) 存在しないキーに対する delete 同一キーに対する同時の put と get 多数のスレッドが同時に挿入する際の急速な連続追い出し(evictions) テスト: 単一スレッドおよびマルチスレッドのシナリオで全操作の正しさを示すテスト関数 run_tests() を含めてください。マルチスレッドテストは少なくとも 8 スレッドを使い、重複するキーに対して get、put、delete の混合操作を行い、キャッシュが決して容量を超えないこと、また get が一度も挿入されていないキーに対して値を返さないことをアサートする必要があります。 完全な実装を Python で提供してください。標準ライブラリのみを使用し、サードパーティのパッケージは使用しないでください。並行性戦略と取った設計上のトレードオフを説明する docstring とコメントを含めてください。

594
2026/03/23 17:47

アイデア出し

OpenAI GPT-5 mini VS Google Gemini 2.5 Flash

デジタル時代における公共図書館の創造的収益源

世界中の公共図書館は予算削減に直面している一方で、地域コミュニティからのサービス需要は増え続けています。あなたは、中規模の都市図書館システム(約15万人の住民にサービスを提供している)に助言していると想定してください。この図書館は、情報への無料かつ公平なアクセスという中核的使命を損なうことなく、新しく持続可能な収益源を生み出す必要があります。 少なくとも8つの異なるアイデアを作成してください。各アイデアについて、以下を提供してください。 短い記述的な名称 どのように機能するかの簡潔な説明(2〜3文) なぜ公共図書館にとって実行可能か(既存の資産、スペース、職員の専門性、コミュニティからの信頼を考慮) 1つの潜在的なリスクまたは欠点と、それをどのように緩和できるか 制約事項: いかなるアイデアも、貸出や基本的な図書館サービスへのアクセスに対して利用者に課金することを含んではいけません。 少なくとも2つのアイデアは、図書館の物理的なスペースを従来とは異なる方法で活用するものにしてください。 少なくとも2つのアイデアは、地元の企業や団体とのパートナーシップを含むものにしてください。 アイデアは、低投資で短期間に得られる成果から、より大規模な戦略的イニシアティブに至るまで、さまざまなスケールをカバーしてください。 「ベイクセールを開催する」や「寄付を募る」といった一般的な提案は避け、創造的で持続可能なモデルに焦点を当ててください。

544
2026/03/23 09:01

システム設計

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

URL短縮サービスの設計

URL短縮サービス(bit.ly や tinyurl.com に類似)を設計してください。以下の制約を満たす必要があります: サービスは月間で1億件の新しいURL短縮をサポートする必要があります。 読み取り(リダイレクト)リクエストと書き込み(短縮)リクエストの比率は100:1です。 短縮URLは可能な限り短くするが、少なくとも10年間の予想ボリュームをサポートできる必要があります。 システムは99.9%の稼働率(アップタイム)を達成する必要があります。 リダイレクトのレイテンシは95パーセンタイルで50ms未満でなければなりません。 データセンターがオフラインになった場合、サービスは優雅に劣化(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に対応する明確なセクションを持つ構造化プランとして提示してください。

622
2026/03/22 21:21

説得

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

教育委員会に芸術プログラムの存続を訴える

あなたは公立中学校の保護者代表です。教育委員会は、資金を標準化テスト対策講座の拡大に振り向けるために、芸術プログラム(美術、音楽、演劇)を全面的に削減することを提案しています。次回の会議で委員会に対して発言する時間は5分です。 説得力のある演説(400~600語)を書き、教育委員会のメンバーに芸術プログラムを維持するよう納得させてください。あなたの演説は以下を満たす必要があります。 テスト成績向上への委員会の懸念を認め、それを正当な目標として扱うこと。 教育的理由、社会・情緒的理由、地域社会に基づく理由を用いて、芸術プログラムを維持するための少なくとも三つの明確に異なる議論を提示すること。 事例、統計、研究結果など、少なくとも一つの具体的でもっともらしい証拠や研究結果を参照して支持すること。 芸術を完全に廃止することなく、委員会の予算上の懸念に対処する建設的な妥協案を提案すること。 全編を通して敬意と協調的な口調を使用し、委員会に対して敵意や見下す態度を避けること。 あなたの演説は、明確な導入部、本論、結びの構成を持ち、声に出して読んでも自然に聞こえる内容にしてください。

555
2026/03/21 09:23

システム設計

OpenAI GPT-5.4 VS Google Gemini 2.5 Flash

URL短縮サービスの設計

URL短縮サービス(bit.ly や tinyurl.com に類似)を設計してください。次の制約を満たす必要があります: サービスは月間1億件の新しいURL短縮をサポートすること。 読み取り対書き込み比率は100:1(すなわち、生成された各URLは平均で100回アクセスされる)。 短縮URLは少なくとも5年間アクセス可能であること。 システムは99.9%の稼働率を達成すること。 リダイレクト遅延(短縮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に対応する明確なセクションを持つ構造化された設計ドキュメントとして提示してください。

576
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つの特殊なマネージド製品ですべてが解決すると仮定してはならない。 予算は重要である。あらゆるレプリケーション、キャッシュ、ストレージの選択を正当化すること。 短縮コードはコンパクトで、大規模時にある程度推測しにくいものであるべきだが、完全な秘匿性は不要である。 回答では、以下を提供してください: 主要コンポーネントとデータフローを含む高レベルアーキテクチャ。 リンクメタデータ、リダイレクト経路、分析イベントに対するストレージ選択と、その根拠。 短縮コード生成戦略。衝突回避方法とカスタムエイリアスの扱いを含む。 キャッシュ、パーティショニング/シャーディング、マルチリージョンの考慮を含む、グローバルトラフィック向けのスケーリング計画。 障害、ホットキー、災害復旧、性能劣化時の動作を扱う信頼性計画。 主要APIとコアデータモデル。 不正利用対策およびセキュリティ上の考慮事項。 主にどのようなトレードオフを行ったか、その理由。

520
2026/03/20 11:03

分析

Anthropic Claude Sonnet 4.6 VS Google Gemini 2.5 Flash

最も有望な学校給食改革を選択する

公立の学区は今後2年間に1つの給食改革にしか資金を投入できません。以下の選択肢を分析し、学区が選ぶべき単一の選択肢を推奨してください。あなたの回答は、トレードオフを比較し、想定される反対意見に対処し、明確な結論に達するべきです。 学区の目標: 生徒の栄養状態を改善する 実際に給食を食べる生徒の数を増やす 実施を2年以内で現実的に保つ 大きな継続的なコスト超過を避ける 現状: 18校で合計12,000人の生徒 現在46%の生徒が給食を選んでいる 調査によると、生徒は味、長い列、魅力的な選択肢の欠如のためにしばしば昼食を抜いている 学区は現在、次のうちの1つだけを実行できる オプションA: 訓練を受けたシェフを雇ってメニューを再設計する 初期の研修・コンサル費用:中程度 継続的な食材費:やや高い 期待される効果:食事の味が良くなり、より健康的なレシピが魅力的になることで参加率が中程度に増加する リスク:効果はスタッフの導入状況と学校間でのレシピの一貫性に左右される オプションB: すべての学校にセルフサービスのサラダ・フルーツバーを導入する 初期の設備費:高い 継続的な食料の廃棄リスク:高い 期待される効果:バーを利用する生徒にとって栄養面の大幅な改善、全体としては参加率は控えめに増加 リスク:人員配置、衛生管理、年齢層による利用の偏り オプションC: 給食のモバイル事前注文システムを導入する 初期の技術・研修費用:中程度 継続的なコスト:低〜中程度 期待される効果:列の短縮、予測の改善、参加率が中程度に増加、メニューが同じままなら栄養面の直接的改善はほとんどない リスク:技術利用が限られる家庭への不平等なアクセス、当初の導入における採用の課題 オプションD: 甘いデザートや揚げ物の副菜をより健康的なデフォルトに置き換える 初期費用:低い 継続的なコスト:中立(変わらない) 期待される効果:給食利用者全員に対する直接的な栄養改善、変更を好まない生徒がいれば参加率が若干低下する可能性 リスク:生徒の反発、給食が楽しめなくなったという印象 学区の目標と制約を踏まえて最適な選択肢を特定する分析を書いてください。新しい予算数値や外部の事実を創作せず、与えられた情報のみに基づいて検討してください。

493
2026/03/19 21:45

ブレインストーミング

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

予算削減に直面する小さな町の公立図書館の収益源

人口およそ12,000人にサービスを提供する小さな町の公立図書館は、次年度から年間の自治体資金が30%削減されることを知ったばかりです。この図書館には、以下の資産と制約があります。 資産: 200人収容のコミュニティルームを備えた6,000平方フィートの建物 小さな駐車場(20台分) 常勤司書2名と非常勤スタッフ3名 40,000冊の紙の書籍コレクションと控えめなデジタルカタログ 3Dプリンター、レーザーカッター、ミシンを備えたメイカースペース 信頼性の高い高速インターネットと一般利用向けコンピューター15台 建物の裏手にある小さな柵付き庭園エリア 制約: 図書館は引き続き無料で入館できなければならず、書籍の貸し出しも無償で継続しなければならない 酒類の販売や賭博の開催はできない 新たな収益活動はいずれも、米国の一般的な自治体において合法でなければならない スタッフを増やすことはできない。ボランティアの募集は可能 図書館理事会は、隣接する住宅地の近隣住民から重大な騒音苦情が発生するようなものは承認しない できるだけ多くの、互いに異なる、実用的な収益創出またはコスト削減のアイデアをブレインストーミングしてください。各アイデアについて、以下を示してください: 短い名前 それがどのように機能するかを説明する1~2文 それが活用する図書館の資産 さまざまなカテゴリ(例: イベント、提携、サービス、スペース貸し出し、助成金、物販、デジタルなど)にわたって幅広さを目指してください。

610
2026/03/19 19:59

61〜80件を表示 / 全136件

関連リンク

X f L