プログラミング
プログラミングジャンルにおけるAIモデルの比較結果を確認できます。評価基準、ランキング、最新のベンチマーク例をまとめています。
ジャンル概要
コードの正確さ、完成度、実務で使える実装力を比較します。
このジャンルでは、主に 正確さ、完全性、コード品質 のような力を見ようとしています。
システム設計よりも、実際に動くコードになるか、細部まで正しく組めるかを強く見ているのが違いです。
ここで高得点でも、上位の設計判断、プロダクト判断、初心者向けの説明の分かりやすさまで強いとは限りません。
このジャンルで強いAIが向いている用途
実装、デバッグ、リファクタリング、コードレビュー補助です。
このジャンルだけでは判断しきれないこと
高レベルな設計、利害調整を含む文書作成、自由発想の強さまでは分かりません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/05/12 09:45
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5.2 引退 | OpenAI |
100%
|
89
|
6 | 6 | GPT-5.2 の評価・スコアを見る |
| 2位 | GPT-5.5 NEW | OpenAI |
100%
|
89
|
1 | 1 | GPT-5.5 の評価・スコアを見る |
| 3位 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | GPT-5 mini の評価・スコアを見る |
| 4位 | GPT-5.4 NEW | OpenAI |
75%
|
84
|
6 | 8 | GPT-5.4 の評価・スコアを見る |
| 5位 | Claude Sonnet 4.6 | Anthropic |
50%
|
77
|
2 | 4 | Claude Sonnet 4.6 の評価・スコアを見る |
| 6位 | Claude Opus 4.6 引退 | Anthropic |
33%
|
84
|
1 | 3 | Claude Opus 4.6 の評価・スコアを見る |
| 7位 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Gemini 2.5 Pro の評価・スコアを見る | |
| 8位 | Gemini 2.5 Flash |
0%
|
73
|
0 | 4 | Gemini 2.5 Flash の評価・スコアを見る | |
| 9位 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Gemini 2.5 Flash-Lite の評価・スコアを見る | |
| 10位 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 4 | Claude Haiku 4.5 の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
正確さ
35.0%
この項目は、回答の 正確さ を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
コード品質
20.0%
この項目は、回答の コード品質 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
実用性
15.0%
この項目は、回答の 実用性 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
指示遵守
10.0%
この項目は、回答の 指示遵守 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
プログラミング
スライディングウィンドウとバースト許容を備えたレートリミッタ
スライディングウィンドウ会計とバースト許容をサポートする、スレッドセーフなレートリミッタを選択した言語（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 とコメントを含めてください。
プログラミング
カスタム形式の高度なログファイルパーサー
Python関数 `parse_log(log_content: str) -> list` を作成してください。この関数はカスタム形式のログファイルを解析します。関数はログ内容を単一の複数行文字列として受け取り、各辞書が正常に完了したトランザクションを表す辞書のリストを返す必要があります。 **ログ形式のルール:** 1. **`START <transaction_id> <timestamp>`**: トランザクションの開始を示します。`transaction_id` は空白を含まない文字列です。`timestamp` は ISO 8601 形式の文字列です。 2. **`END <transaction_id> <status> <timestamp>`**: トランザクションの終了を示します。`transaction_id` は開いているトランザクションと一致しなければなりません。`status` は単語1つ（例: `SUCCESS`, `FAIL`）です。 3. **`EVENT <key1>=<value1> <key2>="<value with spaces>" ...`**: 現在アクティブなトランザクション内のイベントを表します。1つ以上のキーと値のペアで構成されます。空白を含む値は二重引用符で囲まれている必要があります。 4. **`COMMENT # <any text>`**: 無視すべきコメント行です。 **処理ロジック:** * 関数は行を順次処理する必要があります。 * `EVENT` 行は、まだ終了していない直近に開始されたトランザクションに関連付けられます。 * トランザクションは、同じ `transaction_id` を持つ `START` と `END` 行が対応している場合のみ完了かつ有効と見なされます。 * 出力は辞書のリストとします。各辞書は1つの完了したトランザクションを表し、以下のキーを持たなければなりません: * `transaction_id` (string) * `start_time` (string) * `end_time` (string) * `status` (string) * `events` (辞書のリスト。各内側の辞書は1行の `EVENT` のキーと値のペアを表します。) **エラー処理と特殊ケース:** * 任意の `COMMENT` 行、空行、または指定された形式に一致しない不正な行は無視してください。 * 最初の `START` の前やトランザクションが閉じられた後など、アクティブなトランザクションの外で発生する `EVENT` は無視してください。 * 新しい `START` 行が前のトランザクションが `END` で閉じられる前に出現した場合、前のトランザクションは「破棄（abandoned）」されたものと見なし破棄してください。新しい `START` 行は新しいトランザクションを開始します。 * ログファイルの終わりでまだ開いているトランザクションも「破棄」され、最終出力に含めないでください。