プログラミング
コードの正確さ、完成度、実務で使える実装力を比較します。
このジャンルでは、主に 正確さ、完全性、コード品質 のような力を見ようとしています。
システム設計よりも、実際に動くコードになるか、細部まで正しく組めるかを強く見ているのが違いです。
ここで高得点でも、上位の設計判断、プロダクト判断、初心者向けの説明の分かりやすさまで強いとは限りません。
このジャンルで強いAIが向いている用途
実装、デバッグ、リファクタリング、コードレビュー補助です。
このジャンルだけでは判断しきれないこと
高レベルな設計、利害調整を含む文書作成、自由発想の強さまでは分かりません。
コーディング：1位はGPT-5 mini、最高平均は4位に沈む
Anthropic
OpenAI
OpenAI
モデル別の平均スコア
評価の重み付け
コーディングは全37件の採点回答にもとづく。首位はGPT-5 miniで、5サンプルで平均8.22、5回すべて1位（勝率100%）と対戦を完勝している。最高順位でありながら裏付けも厚く、軽量帯のコストでこの成績は強い。2位のClaude Opus 4.8は2サンプルのみで平均8.07・全勝（勝率100%）だが、サンプルが薄いので「強いが暫定的な兆し」として読むべきだ。
平均スコアと順位は大きく食い違う。順位は勝率（直接対戦での1位）に強く依存するためだ。GPT-5.5はジャンル最高の平均8.9ながら4位にとどまる。2サンプルで1勝のみ、勝率50%だからだ。対照的にGPT-5.4はここで最多の8サンプルという証拠量をもち、平均8.41・1位6回・勝率75%で3位。首位と2位の差はわずか0.15点で、上位は僅差だ。
平均は良いのに対戦で沈む典型がGemini 2.5 Proだ。平均7.95は中位より上だが、4戦すべて競り負け（勝率0%）で6位。中位はClaude Sonnet 4.6（平均7.7・4サンプルで勝率50%・5位）が牽引し、GPT-5系に約0.5〜1.2点差。軽量・高速帯は下位で、Gemini 2.5 Flash-Lite（7.17）、Gemini 2.5 Flash（6.84）、Claude Haiku 4.5（6.48）が首位から1.0〜1.7点離れる。評価はCorrectness（重み35、CompletenessとCode Qualityの各20より上）を最重視しており、この差はスタイルよりも難所での正確性の弱さを示す。
最大の注意点はサンプル数だ。Claude Opus 4.8とGPT-5.5はそれぞれ2サンプル、多くが3〜8サンプルで、平均は数件の出題で大きく動きうる。首位と最下位の1.74点差は実体があるが、8点台に密集する上位群（GPT-5.5・GPT-5.4・GPT-5 mini・Claude Opus 4.8）の細かい順位は暫定と見るべきだ。これらは条件依存の測定値であり、コーディング全般の優劣を断定するものではない。
結論
今すぐ頼れるコーディング用途なら、5サンプル全勝・勝率100%で1位のGPT-5 miniが最も裏付けの厚い選択（軽量帯のコスト）。上位帯ではGPT-5.4が最も証拠が厚い（8サンプルで8.41）。GPT-5.5のジャンル最高平均8.9とClaude Opus 4.8の2位はどちらも2サンプルの上に成り立つため、有望だが未証明として扱うのが妥当。
この分析は Orivel がこのジャンルで実測したベンチマークスコアをもとに生成し、定期的に更新しています。スコアは条件依存の測定値であり、絶対評価ではありません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/07/16 09:49
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Claude Fable 5 の評価・スコアを見る |
| 2位 | GPT-5.6 NEW | OpenAI |
100%
|
86
|
1 | 1 | GPT-5.6 の評価・スコアを見る |
| 3位 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | GPT-5 mini の評価・スコアを見る |
| 4位 | Claude Opus 4.8 | Anthropic |
100%
|
81
|
2 | 2 | Claude Opus 4.8 の評価・スコアを見る |
| 5位 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | GPT-5.5 の評価・スコアを見る |
| 6位 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Claude Sonnet 4.6 の評価・スコアを見る |
| 7位 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Gemini 2.5 Pro の評価・スコアを見る | |
| 8位 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Gemini 2.5 Flash-Lite の評価・スコアを見る | |
| 9位 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Gemini 2.5 Flash の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
正確さ
35.0%
この項目は、回答の 正確さ を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
コード品質
20.0%
この項目は、回答の コード品質 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
実用性
15.0%
この項目は、回答の 実用性 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
指示遵守
10.0%
この項目は、回答の 指示遵守 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
プログラミング
スライディングウィンドウと公平なマルチテナント割当を備えたレートリミッタ
任意の言語（Python、Go、TypeScript、Java、または Rust）で再利用可能なレートリミッタライブラリを実装してください。このライブラリはスライディングウィンドウアルゴリズムを使用してクライアントごとのリクエストクォータを強制し、かつ複数テナント間での公平な共有ポリシーを提供する必要があります。 機能要件: 1. allow(tenant_id, client_id, now_ms) のようなメソッドを持つクラスまたはモジュールを提供し、リクエストが許可されるかどうかを返し、拒否された場合は次にリクエストが許可されるまでのミリ秒数（retry_after_ms）も返すこと。 2. 各クライアントはローリングウィンドウ内での最大リクエスト数に制限される（例：60,000 ms あたり 100 リクエスト）。この構成はテナントごとに調整可能であること。 3. 固定のカレンダーバケットウィンドウではなく、真のスライディングウィンドウ（重み付けまたはタイムスタンプログベース）を実装し、バケット境界を跨ぐバーストを正しく扱うこと。 4. テナント全体の上限（per-tenant global cap）を追加し、テナント内のすべてのクライアントの合計がテナントレベルの上限を超えないようにすること。テナントが飽和している場合、残りの容量は1つのクライアントに独占されるのではなく、アクティブなクライアント間で公平に共有されること。 5. リミッタは複数のスレッドや非同期タスクからの同時アクセスに対して安全であること。 6. メモリが無制限に増加しないこと：古いクライアント状態は時間経過で削除またはコンパクト化されること。 成果物: - 明確な公開APIと重要な設計判断に関するインラインドキュメントを含む完全な実装。 - 選択したスライディングウィンドウアルゴリズムとその精度/メモリトレードオフに関する簡潔な説明（コメント内または短い本文セクション）。 - 以下のコアエッジケースをカバーするテストスイート。 コードとテストで明示的に対処すべきエッジケース: - ウィンドウの境界でちょうど発生するリクエスト。 - クライアントがアイドル状態になり、その後ウィンドウが完全に経過した後に戻ってくる場合。 - 同じクライアントカウンタに対する同時リクエストの競合。 - 時計が後退する場合や重複タイムスタンプ。 - テナントの飽和と競合するクライアント間での公平な再分配。 - アクティブなクライアントを落とさずに古いクライアント状態を削除すること。 仮定を明記してください（単一プロセス対分散、単調クロックの利用可能性など）。単一プロセスを仮定する場合は、設計を分散デプロイに拡張する方法を簡単に説明してください。
プログラミング
決定論的リミットオーダーブック・シミュレータを実装する
単一ファイルの Python 3.11 ソリューションを作成し、関数 process_events(events: list[dict]) -> dict を実装してください。外部パッケージを使用しないでください。 この関数は、1つの銘柄の小さな取引所のリミットオーダーブックをシミュレートする必要があります。入力順序のイベント辞書のリストを受け取り、正確に次のキーを持つ辞書を返します: trades, rejected, book。 Event types: 1. New order event: Required fields: type="new", id, side, order_type, qty. side は "buy" または "sell" です。 order_type は "limit" または "market" です。 qty は正の整数です。 limit 注文は price（セント単位の正の整数）も必須です。 オプションのフィールド tif は time-in-force で、"GTC", "IOC", または "FOK" のいずれかです。指定がなければ、limit 注文は "GTC" を、market 注文は "IOC" を使用してください。 market 注文は tif="GTC" を持つことはできず、book 上で残存してはなりません。 2. Cancel event: Required fields: type="cancel", id. それは、その id を持つ現在 book に残っている注文の残数量をキャンセルします。 Matching rules: - book は bids と asks を持ちます。resting buy limit 注文は bids です；resting sell limit 注文は asks です。 - 価格-時間優先が必須です：最良価格が先；同一価格では、より早く受理された resting 注文が先です。 - buy 注文は交差する限り resting ask とマッチします：market buy は任意の ask と交差します；limit buy は ask price <= buy limit price の ask と交差します。 - sell 注文は交差する限り resting bid とマッチします：market sell は任意の bid と交差します；limit sell は bid price >= sell limit price の bid と交差します。 - 各トレードの数量は min(到着注文の残数量, resting 注文の残数量) です。 - トレード価格は常に resting maker 注文の limit price であり、到着注文の価格では決してありません。 - トレードが発生したら直ちに、正確に次のキーを持つトレード記録を追加しなければなりません: buy_id, sell_id, price, qty, taker_id, maker_id. - 部分的に約定した resting 注文は、残数量で元の優先順位を保持します。完全に約定した注文は book から離脱します。 Time-in-force behavior: - GTC limit 注文は、未約定の残りを book に残します。 - IOC 注文は可能な限り即時に実行し、残りはキャンセルします。 - FOK 注文は、現在の book と交差ルールに従って即時に完全に埋められる必要があります。完全に埋められない場合、トレードを一切生成せず、book を変更しません。完全に埋められる場合は通常通り実行します。FOK 注文は決して残りません。 Validation and rejection rules: - イベントが不正な形式の場合、book を変更せずにそれを拒否してください。拒否レコードを rejected に追加し、キーは input_index, event, reason とします。reason は短い人間可読の文字列で構いません。 - 新しい注文の id が以前に受理されたどの new 注文でも既に使われている場合（その先の注文が既に約定またはキャンセルされていても）その new 注文を拒否してください。 - 不明な id やもはや resting していない id に対する cancel イベントを拒否してください。 - qty と price の値が非整数、ゼロ、または負の場合は拒否してください。Python では、bool はこれらのフィールドの整数として受け入れてはいけません。 - その他の余分なフィールドは、有効なイベントであれば無視してください。 Return format: - trades: 実行順のトレード記録のリスト。 - rejected: 入力順の拒否レコードのリスト。 - book: keys が bids と asks の辞書。 - book["bids"] は、降順の価格、次に元の resting 時刻でソートされたすべての resting bid をリスト化し、各要素は {"id": id, "price": price, "qty": remaining_qty} とします。 - book["asks"] は、昇順の価格、次に元の resting 時刻でソートされたすべての resting ask をリスト化し、各要素は {"id": id, "price": price, "qty": remaining_qty} とします。 あなたの回答は、process_events を定義する完全な実行可能な Python コードであるべきです。ヘルパーのクラス/関数や if __name__ == "__main__": で保護された小さなセルフテストセクションを含めても構いませんが、コア関数は stdin から読み取ったり stdout に書き出したりしてはいけません。
プログラミング
PythonでのアトミックなJSON Patch適用を実装する
Python 3.11で、apply_json_patch(document, patch)という名前の関数を実装してください。この関数は、JSON Patchスタイルの操作列をJSON互換の値に適用し、パッチ適用後の値を返します。入力のdocumentはdict、list、str、int、float、bool、Noneの任意の組み合わせで構成され得ます。patchは操作dictのリストです。実装は元のdocumentやそこから到達可能な任意のネストされたオブジェクトを変更してはなりません。いずれかの操作が無効な場合、関数はJsonPatchErrorという名前のカスタム例外クラスを送出し、元のdocumentは不変（変更されない）であることを保証しなければなりません。サポートされる操作はadd、remove、replace、move、copy、testです。JSON Pointerのパスをスラッシュ区切りトークンで用いてください。空文字列はドキュメント全体を識別し、トークンは~1を/に、~0を~にデコードし、その他の~の使用は無効とします。オブジェクトに対しては、パストークンはキーです。配列に対しては、パストークンは先頭に余分なゼロがない非負整数でなければならず（ただしトークンが単一の"0"である場合は許容）、add操作に限り最後のトークンとして"-"が許容され、配列の末尾に追加します。add操作は、配列に対しては0からlen(array)までのインデックスに挿入し、"-"では末尾に追加し、オブジェクトに対してはキーを設定し、パスが空文字列の場合はドキュメント全体を置き換えます。remove操作は対象が存在することを要求し、それを削除します。replace操作は対象が存在することを要求し、それを置換します。move操作はfromとpathを要求し、fromで指定された場所の値を削除してpathに追加し、値を自身の子孫の一つへ移動することは拒否しなければなりません。copy操作はfromとpathを要求し、ソース値をターゲットへディープコピーします。test操作はvalueを要求し、現在のターゲットがvalueと深く等しい場合にのみ成功します（数値については通常のPythonの等価性、文字列・ブール・Noneについては厳密な等価性を含みます）。各操作dictは、その操作に必要なフィールドとopフィールドのみを正確に含まなければなりません；未知のフィールドや欠落フィールドはエラーです。関数は決定論的で、合理的に効率的であり、Python標準ライブラリのみを使用してください。必要なヘルパー関数やクラスを含めてください。コマンドラインプログラムを書いたり外部パッケージを使用したりしてはいけません。
プログラミング
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!") ``` ```