プログラミングにおける最新AI性能検証一覧 | Orivel | GPT-5.6 (OpenAI)

比較ジャンル

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

モデル一覧

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

プログラミング

Anthropic Claude Sonnet 5 VS OpenAI GPT-5.6

Webサーバーログアナライザー

Python 関数 analyze_logs(log_data) を作成してください。この関数は、Web サーバのログエントリを含む複数行の文字列を受け取ります。関数はこれらのログを解析し、分析を行い、結果を要約した辞書を返す必要があります。有効なログ行は次の形式に従います: [TIMESTAMP] LEVEL IP_ADDRESS "REQUEST_METHOD /path" RESPONSE_CODE BYTES_SENT 有効な行の例: [2023-10-27T10:00:00Z] INFO 192.168.1.1 "GET /index.html" 200 1543 関数は次のことを行う必要があります: 有効なログ行のみを解析し、形式が崩れた行や空行は問題なく無視すること。次の指標を計算すること: total_requests: 有効なログエントリの総数。 error_rate: LEVEL が ERROR のリクエストの割合（パーセンテージ）、小数点以下2桁に丸めること。 top_3_ips: タプルのリスト。各タプルは IP アドレスとそのリクエスト数を含み、リクエスト数の多い順に並べた上位3つの IP を含むこと。 busiest_hour: 1日の中でリクエストが最も多かった時間（0〜23 の整数）。タイムスタンプは ISO 8601 形式（UTC）です。計算した値を持つ total_requests、error_rate、top_3_ips、busiest_hour のキーを含む辞書を返すこと。次のエッジケースを扱ってください: 入力文字列 log_data が空の場合、適切にゼロまたは空の値を持つ辞書を返してください（例: total_requests: 0、top_3_ips: []）。ユニークな IP アドレスが3つ未満の場合、top_3_ips リストには存在するすべてのユニークな IP をカウントの多い順に含めてください。最も混雑した時間帯が同率の場合、同率のうちのどれか一つの時間を返して構いません。

31

2026/07/25 01:19

プログラミング

OpenAI GPT-5.6 VS Google Gemini 2.5 Pro

スライディングウィンドウと公平なマルチテナント割当を備えたレートリミッタ

任意の言語（Python、Go、TypeScript、Java、または Rust）で再利用可能なレートリミッタライブラリを実装してください。このライブラリはスライディングウィンドウアルゴリズムを使用してクライアントごとのリクエストクォータを強制し、かつ複数テナント間での公平な共有ポリシーを提供する必要があります。機能要件: allow(tenant_id, client_id, now_ms) のようなメソッドを持つクラスまたはモジュールを提供し、リクエストが許可されるかどうかを返し、拒否された場合は次にリクエストが許可されるまでのミリ秒数（retry_after_ms）も返すこと。各クライアントはローリングウィンドウ内での最大リクエスト数に制限される（例：60,000 ms あたり 100 リクエスト）。この構成はテナントごとに調整可能であること。固定のカレンダーバケットウィンドウではなく、真のスライディングウィンドウ（重み付けまたはタイムスタンプログベース）を実装し、バケット境界を跨ぐバーストを正しく扱うこと。テナント全体の上限（per-tenant global cap）を追加し、テナント内のすべてのクライアントの合計がテナントレベルの上限を超えないようにすること。テナントが飽和している場合、残りの容量は1つのクライアントに独占されるのではなく、アクティブなクライアント間で公平に共有されること。リミッタは複数のスレッドや非同期タスクからの同時アクセスに対して安全であること。メモリが無制限に増加しないこと：古いクライアント状態は時間経過で削除またはコンパクト化されること。成果物: 明確な公開APIと重要な設計判断に関するインラインドキュメントを含む完全な実装。選択したスライディングウィンドウアルゴリズムとその精度/メモリトレードオフに関する簡潔な説明（コメント内または短い本文セクション）。以下のコアエッジケースをカバーするテストスイート。コードとテストで明示的に対処すべきエッジケース: ウィンドウの境界でちょうど発生するリクエスト。クライアントがアイドル状態になり、その後ウィンドウが完全に経過した後に戻ってくる場合。同じクライアントカウンタに対する同時リクエストの競合。時計が後退する場合や重複タイムスタンプ。テナントの飽和と競合するクライアント間での公平な再分配。アクティブなクライアントを落とさずに古いクライアント状態を削除すること。仮定を明記してください（単一プロセス対分散、単調クロックの利用可能性など）。単一プロセスを仮定する場合は、設計を分散デプロイに拡張する方法を簡単に説明してください。

137

2026/07/16 09:49

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

Webサーバーログアナライザー

スライディングウィンドウと公平なマルチテナント割当を備えたレートリミッタ

関連リンク