プログラミング
コードの正確さ、完成度、実務で使える実装力を比較します。
このジャンルでは、主に 正確さ、完全性、コード品質 のような力を見ようとしています。
システム設計よりも、実際に動くコードになるか、細部まで正しく組めるかを強く見ているのが違いです。
ここで高得点でも、上位の設計判断、プロダクト判断、初心者向けの説明の分かりやすさまで強いとは限りません。
このジャンルで強いAIが向いている用途
実装、デバッグ、リファクタリング、コードレビュー補助です。
このジャンルだけでは判断しきれないこと
高レベルな設計、利害調整を含む文書作成、自由発想の強さまでは分かりません。
コーディング：上位はGPT-5系が独占、ただしサンプルは薄め
OpenAI
OpenAI
OpenAI
モデル別の平均スコア
評価の重み付け
コーディングは全32件の採点回答にもとづく。上位3つはすべてGPT-5系で、1位はGPT-5.5（平均8.85・全勝）だが、これは1サンプルのみなので「有望な兆し」程度に読むべきだ。最も裏付けが厚い実力者は2位のGPT-5 miniで、5サンプルで平均8.22、5回すべて1位（勝率100%）と対戦を完勝している。軽量帯のコストでこの成績は強い。
平均スコアと順位は一致しない。順位は勝率（直接対戦での1位）に強く依存するためだ。3位のGPT-5.4は8サンプル（ここで最多の証拠量）で平均8.41・勝率75%。一方Gemini 2.5 Proは同じ平均8.41ながら5位で、3戦すべて競り負け（勝率0%）。対戦結果ではなく純粋な出力品質を重視するなら、GPT-5.4とGemini 2.5 Proは順位ほど差はない。
中位はClaude Sonnet 4.6（平均7.7・4サンプルで勝率50%）が牽引し、GPT-5系に約0.5〜1.1点差。軽量・高速帯は下位で、Gemini 2.5 Flash（7.31）、Flash-Lite（7.17）、Claude Haiku 4.5（6.48）が首位から1.5〜2.4点離れる。評価はCorrectness（重み35、Code Quality・Completenessの各20より上）を最重視しており、この差はスタイルよりも難所での正確性の弱さを示す。
最大の注意点はサンプル数だ。GPT-5.5は1サンプル、多くが3〜8サンプルで、平均は数件の出題で大きく動きうる。首位と最下位の2.37点差は実体があるが、8点台に密集する上位群（GPT-5.5・GPT-5.4・GPT-5 mini・Gemini 2.5 Pro）の細かい順位は暫定と見るべきだ。これらは条件依存の測定値であり、コーディング全般の優劣を断定するものではない。
結論
今すぐ頼れるコーディング用途なら、5サンプル全勝のGPT-5 miniが最も裏付けの厚い選択（軽量帯のコストで勝率100%）。上位帯ではGPT-5.4が最も証拠が厚い（8サンプルで8.41）。GPT-5.5の1サンプル首位は有望だが未証明として扱うのが妥当。
この分析は Orivel がこのジャンルで実測したベンチマークスコアをもとに生成し、定期的に更新しています。スコアは条件依存の測定値であり、絶対評価ではありません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/06/12 09:39
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | GPT-5 mini の評価・スコアを見る |
| 2位 | GPT-5.4 | OpenAI |
75%
|
84
|
6 | 8 | GPT-5.4 の評価・スコアを見る |
| 3位 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | GPT-5.5 の評価・スコアを見る |
| 4位 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Claude Sonnet 4.6 の評価・スコアを見る |
| 5位 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Gemini 2.5 Pro の評価・スコアを見る | |
| 6位 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Gemini 2.5 Flash の評価・スコアを見る | |
| 7位 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Gemini 2.5 Flash-Lite の評価・スコアを見る | |
| 8位 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Claude Haiku 4.5 の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
正確さ
35.0%
この項目は、回答の 正確さ を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
コード品質
20.0%
この項目は、回答の コード品質 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
実用性
15.0%
この項目は、回答の 実用性 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
指示遵守
10.0%
この項目は、回答の 指示遵守 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
プログラミング
Pythonで依存関係に基づくタスクスケジューラを実装する
タスクの依存関係に基づいてタスク一覧をスケジュールするPythonの関数またはクラスを書いてください。スケジューラは、タスクを実行可能な順序に決定し、並列に実行できるタスクをグループ化する必要があります。 入力は辞書のリストで、各辞書は次のキーを持つタスクを表します： - `id`: タスクの一意の文字列識別子。 - `name`: タスクの文字列名。 - `dependencies`: このタスクを開始する前に完了していなければならないタスクの文字列IDのリスト。 実装は次を満たす必要があります： 1. タスク辞書のリストを入力として受け取ること。 2. 実行計画をリストのリストとして返すこと。各内部リストは同時に実行できるタスクの「バッチ」を表します。バッチの順序は逐次実行の順序を表します。バッチ内のタスクIDの順序は重要ではありません。 3. 循環依存関係を検出して扱うこと。サイクルが見つかった場合、説明的なメッセージを含む `ValueError` を送出すること。 4. 依存関係のIDが存在するタスクに対応していない場合を検出して扱うこと。これも `ValueError` を送出すること。
プログラミング
スライディングウィンドウとバースト許容を備えたレートリミッタ
スライディングウィンドウ会計とバースト許容をサポートする、スレッドセーフなレートリミッタを選択した言語（Python, Go, Java, TypeScript, または Rust）のいずれかで設計・実装してください。要件は次のとおりです。 1. **API surface**: 少なくとも次の操作を公開してください: - `allow(client_id: str, cost: int = 1) -> bool` — 現時点でリクエストが許可されるかどうかを返します。 - `retry_after(client_id: str) -> float` — 少なくとも1単位の容量が利用可能になるまでの秒数を返します（現在許可されている場合は0）。 - クライアントごとの設定を受け取るコンストラクタ: `rate`（単位/秒）、`burst`（蓄えられる最大単位）、およびスライディングウィンドウ会計のためのオプションである `window_seconds`。 2. **Algorithm**: **トークンバケット**（バースト許容のため）と **スライディングウィンドウ（ログまたはカウンタ）**（`window_seconds` 内で許可される総リクエストを上限するため。純粋なトークンバケットではリフィル後に持続的な乱用を許してしまう）を組み合わせたハイブリッドを実装してください。リクエストは両方のチェックが通った場合にのみ許可されます。スライディングウィンドウのデータ構造選択（正確なログ vs. 重み付き二窓近似）について正当化し、メモリ/精度のトレードオフを短いコメントブロックまたは付随するノートで議論してください。 3. **Concurrency**: リミッタは同一および異なる `client_id` に対して多くのスレッド/ゴルーチンから同時に呼ばれます。単一のグローバルロックがボトルネックにならないようにしてください（例：クライアント毎のロック、ロックストライピングなど）。同時実行の `allow` 呼び出しの下であなたのアプローチが正しい理由（トークンの二重消費が起きない、更新の取りこぼしがない）を文書化してください。 4. **Time source**: テストが決定論的になるようにクロックを注入可能にしてください。デフォルトではモノトニッククロックを使用してください。 5. **Edge cases to handle explicitly**: - `cost` が `burst` より大きい場合（拒否すること、永遠にブロックしないこと）。 - クロックの巻き戻しや長時間の一時停止（例：サスペンドされたVM）：クラッシュさせずにクランプ（調整）し、無制限のトークンを付与しないこと。 - 新規クライアントの最初のリクエスト（遅延初期化）。 - ステールなクライアントのクリーンアップ（クライアントが停止してもメモリが無制限に成長しないこと）。 - 小数トークン／サブミリ秒の時間処理。 6. **Tests**: 注入可能なクロックを使用して、少なくとも6つの単体テストを提供してください。対象は：基本的な許可/拒否、バーストの枯渇とリフィル、バケットのリフィルとは独立したスライディングウィンドウ上限、`cost > burst`、1クライアントへの同時競合（決定論的特性：ある期間 T 秒内に許可される合計 ≤ rate*T + burst）、およびステールクライアントの除去を含みます。 7. **Complexity**: `allow` の償却時間計算量とクライアントあたりのメモリ計算量を明示してください。 Deliver: 完全な実行可能コード（単一ファイルで可、ただしファイルを分ける場合は明確にラベル付けしてください）、テスト、および設計ノート（最大約250語）を提出してください。
プログラミング
MarkdownサブセットをHTMLに変換するコンバータ
Python関数 `markdown_to_html(markdown_text: str) -> str` を実装してください。この関数は、特定のサブセットのMarkdownを含む文字列を対応するHTML表現に変換します。 関数は次の機能をサポートする必要があります： **ブロック要素:** 1. **見出し（Headers）：** `# ` から `###### ` で始まる行はそれぞれ `<h1>` から `<h6>` タグに変換すること。 2. **順不同リスト（Unordered Lists）：** `- ` で始まる行は `<ul>` と `<li>` タグに変換すること。レベルごとに2つのスペースでインデントされたネストされたリストをサポートすること。リストは空行または別のブロック要素によって終了する。 3. **コードブロック（Code Blocks）：** 三連バックティック（```）で囲まれた内容は `<pre><code>...</code></pre>` に変換すること。開始バックティック上の言語指定（例：```python）は無視すること。コードブロック内部では他のMarkdown処理は行わないこと。 4. **段落（Paragraphs）：** その他のテキストはすべて `<p>` タグで囲むこと。連続するテキスト行は同じ段落に属する。段落は1行以上の空行で区切られる。 **インライン要素:** 1. **太字かつ斜体（Bold & Italic）：** `***text***` は `<strong><em>text</em></strong>` に変換すること。 2. **太字（Bold）：** `**text**` は `<strong>text</strong>` に変換すること。 3. **斜体（Italic）：** `*text*` は `<em>text</em>` に変換すること。 **ルールと制約:** - インライン要素は見出しやリスト項目内でネストできる。 - パーサーは未終了のインラインタグなどの壊れたまたはトリッキーな入力に対して頑健であるべきである。例えば、`*italic` は `<p>*italic</p>` としてレンダリングされるべきである。 - インライン要素の優先順位は `***` が最優先、次に `**`、最後に `*` とする。 - 入力は単一の複数行文字列であると想定する。 - リンク、画像、引用（blockquote）、番号付きリストなど、ここに明記されていない他のMarkdown機能は実装しないこと。 - 出力されるHTMLは完全なドキュメントである必要はない（`<html>` や `<body>` タグは不要）。 **Example Input:** ```markdown # Header 1 This is a paragraph with **bold** and *italic* text. This is the same paragraph. - List item one - List item two with ***bold and italic*** - Nested list item - Back to the first level ```python def hello(): print("Hello, World!") ``` ```
プログラミング
Pythonでスレッドセーフなトークンバケットレートリミッタを実装する
`TokenBucketRateLimiter` という名前のPythonクラスを書いてください。このクラスはレート制限のためのトークンバケットアルゴリズムを実装します。実装はスレッドセーフであり、状態管理のために外部ライブラリ（たとえば Redis）の使用は避けてください。 クラスは次の仕様を満たす必要があります。 1. `__init__(self, capacity, refill_rate)` メソッド: * `capacity`: バケットが保持できるトークンの最大数。 * `refill_rate`: 1秒あたりにバケットに追加されるトークンの数。 2. `consume(self, tokens)` メソッド: * このメソッドはバケットから指定された数の `tokens` を消費しようとします。 * トークンを正常に消費できた場合は `True` を返し、そうでなければ `False` を返すべきです。 * 消費を試みる前に、最後の呼び出しから経過した時間に基づいてバケットがトークンで補充される必要があります。 3. スレッドセーフ性: * このクラスは複数の同時実行スレッドから安全に使用できなければなりません。バケットの状態を変更するすべての操作（トークンの補充や消費など）は原子的である必要があります。 必要なインポートを含めた完全なクラス実装を提供してください。
プログラミング
コマンドライン ファイル同期ツール
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` ライブラリを使用すること。 - 解決策はネストされたディレクトリ、空のディレクトリ、およびさまざまなサイズのファイルを正しく扱う必要があります。 - スクリプトは単一の、自己完結型のファイルであること。
プログラミング
ロックフリーの並行 LRU キャッシュを実装する
Python でスレッドセーフな LRU（Least Recently Used）キャッシュを実装してください。すべての操作でグローバルなロックを使用せず、並行した読み書きをサポートすることを目的とします。実装は以下の要件を満たす必要があります。 1. **インターフェース**: キャッシュは次の操作をサポートしなければなりません: - `__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]` — 現在キャッシュに存在する全てのキーのリストを、最も最近使用された順から最も使用されていない順へ並べて返す。 2. **並行性**: キャッシュは複数のスレッドから同時に安全に使用できなければなりません。可能な限り読み取り同士が互いにブロックしない設計を目指してください（例えば、リード・ライトロック、細粒度ロック、またはロックフリー技術の使用）。すべての操作を直列化する単一のグローバルミューテックスは基準解とは見なされますが、最適な解決策ではありません。 3. **競合下での正しさ**: 同時アクセス下でも、キャッシュは決して古いデータや破損したデータを返してはならず、指定された容量を超えてはならず、一貫した LRU 順序を維持しなければなりません。 4. **扱うべきエッジケース**: - 容量が 1 の場合 - 既に存在するキーに対する `put`（値を更新し、最も最近のものに移動すること） - 存在しないキーに対する `delete` - 同一キーに対する同時の `put` と `get` - 多数のスレッドが同時に挿入する際の急速な連続追い出し（evictions） 5. **テスト**: 単一スレッドおよびマルチスレッドのシナリオで全操作の正しさを示すテスト関数 `run_tests()` を含めてください。マルチスレッドテストは少なくとも 8 スレッドを使い、重複するキーに対して `get`、`put`、`delete` の混合操作を行い、キャッシュが決して容量を超えないこと、また `get` が一度も挿入されていないキーに対して値を返さないことをアサートする必要があります。 完全な実装を Python で提供してください。標準ライブラリのみを使用し、サードパーティのパッケージは使用しないでください。並行性戦略と取った設計上のトレードオフを説明する docstring とコメントを含めてください。