プログラミング
プログラミングジャンルにおけるAIモデルの比較結果を確認できます。評価基準、ランキング、最新のベンチマーク例をまとめています。
ジャンル概要
コードの正確さ、完成度、実務で使える実装力を比較します。
このジャンルでは、主に 正確さ、完全性、コード品質 のような力を見ようとしています。
システム設計よりも、実際に動くコードになるか、細部まで正しく組めるかを強く見ているのが違いです。
ここで高得点でも、上位の設計判断、プロダクト判断、初心者向けの説明の分かりやすさまで強いとは限りません。
このジャンルで強いAIが向いている用途
実装、デバッグ、リファクタリング、コードレビュー補助です。
このジャンルだけでは判断しきれないこと
高レベルな設計、利害調整を含む文書作成、自由発想の強さまでは分かりません。
このジャンルに強いモデルランキング
このランキングは当ジャンルに限定したスコアの平均順です。
最終更新: 2026/03/23 17:47
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
勝率
平均スコア
| モデル | 詳細 | ||||||
|---|---|---|---|---|---|---|---|
| 1位 | GPT-5.2 | OpenAI |
100%
|
89
|
6 | 6 | GPT-5.2 の評価・スコアを見る |
| 2位 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | GPT-5 mini の評価・スコアを見る |
| 3位 | GPT-5.4 | OpenAI |
80%
|
86
|
4 | 5 | GPT-5.4 の評価・スコアを見る |
| 4位 | Claude Opus 4.6 | Anthropic |
33%
|
84
|
1 | 3 | Claude Opus 4.6 の評価・スコアを見る |
| 5位 | Claude Sonnet 4.6 | Anthropic |
33%
|
76
|
1 | 3 | Claude Sonnet 4.6 の評価・スコアを見る |
| 6位 | Gemini 2.5 Pro |
0%
|
84
|
0 | 3 | Gemini 2.5 Pro の評価・スコアを見る | |
| 7位 | Gemini 2.5 Flash |
0%
|
75
|
0 | 3 | Gemini 2.5 Flash の評価・スコアを見る | |
| 8位 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Gemini 2.5 Flash-Lite の評価・スコアを見る | |
| 9位 | Claude Haiku 4.5 | Anthropic |
0%
|
65
|
0 | 3 | Claude Haiku 4.5 の評価・スコアを見る |
このジャンルで評価している項目
このジャンルで使っている採点基準と重みです。
正確さ
35.0%
この項目は、回答の 正確さ を確かめるために入れています。 比重が重いのは、この部分が弱いとジャンル全体の評価が崩れやすいからです。
完全性
20.0%
この項目は、回答の 完全性 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
コード品質
20.0%
この項目は、回答の コード品質 を確かめるために入れています。 比重がしっかりあるのは、全体の良し悪しに目に見えて効いてくる項目だからです。
実用性
15.0%
この項目は、回答の 実用性 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
指示遵守
10.0%
この項目は、回答の 指示遵守 を確かめるために入れています。 比重をやや軽くしているのは、重要ではあるものの、このジャンルの中心そのものではないからです。
最新のお題
プログラミング
ロックフリーの並行 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` 行は新しいトランザクションを開始します。 * ログファイルの終わりでまだ開いているトランザクションも「破棄」され、最終出力に含めないでください。
プログラミング
スライディングウィンドウと優先度付きキューを備えた並行レートリミッタを実装する
スレッドセーフなレートリミッタを Python で設計および実装してください。以下の機能をサポートすること。 1. **スライディングウィンドウによるレート制限**: リミッタはスライディングウィンドウアルゴリズム（固定ウィンドウではない）を用いてリクエスト数を追跡すること。`window_seconds` の期間内に許可される最大 `max_requests` を与えられたとき、任意の時点で新しいリクエストが許可されるかどうかを正確に判定できること。 2. **複数の階層（ティア）**: レートリミッタは名前付きの複数のティア（例: "free", "standard", "premium"）をサポートし、各ティアごとに独自の `max_requests` と `window_seconds` の設定を持つこと。クライアントは登録時にティアが割り当てられる。 3. **遅延リクエストのための優先度付きキュー**: リクエストがレート制限された場合、単に拒否するのではなく、ティアごとの優先度付きキューにエンキューすること。各リクエストは整数の優先度を持ち（数値が小さいほど高優先度）、容量が空いたときに特定クライアントのために待機中の最も高優先度のリクエストをデキューして処理するメソッドを提供すること。 4. **スレッドセーフ**: `allow_request`, `enqueue`, `dequeue`, `register_client` のすべての操作は複数スレッドから同時に呼び出しても安全でなければならない。 5. **クリーンアップ**: 直近 `cleanup_threshold_seconds`（設定可能）よりも長くリクエストを行っていないクライアントの追跡データを削除するメソッドを提供すること。 実装には以下を含めること: - 説明されたインターフェースを持つ `RateLimiter` クラス。 - 少なくとも `client_id`, `timestamp`, `priority`, `payload` を持つ `Request` dataclass または named tuple。 - 重複したクライアント登録、未登録クライアントからのリクエスト、空の優先度キュー、同時変更、クロック精度の問題などのエッジケースへの適切な対応。 さらに、デモ用スクリプトを `if __name__ == "__main__"` ブロック内に書くこと。デモでは以下を行うこと: - 少なくとも 2 つのティアを持つレートリミッタを作成する。 - 複数のクライアントを登録する。 - 複数スレッドからのバーストリクエストをシミュレートし、一部が許可され、他がエンキューされる様子を示す。 - 容量が空いたときに遅延リクエストが処理される様子を示す。 - イベントのシーケンスがわかるように明確な出力を表示する。 コメント内で設計上の選択を説明すること。特にスライディングウィンドウの実装、同期プリミティブの選択、および精度と性能の間のトレードオフについて記述すること。
プログラミング
スライディングウィンドウと優先度付きキューを備えた同時実行レートリミッタを実装する
Pythonで、次の機能をサポートするスレッドセーフなレートリミッタを設計・実装してください。 1. **スライディングウィンドウによるレート制限**: 固定時間ウィンドウを使うのではなく、真のスライディングウィンドウアルゴリズムを実装してください。各クライアント（文字列キーで識別）は、任意の連続する window_seconds 秒の間に最大で max_requests 件のリクエストを許容されます。 2. **優先度レベル**: 各リクエストには優先度レベル（整数 1-5、1 が最も高い優先度）が付与されます。クライアントのレート上限に達した場合、低優先度（数値が大きい）なリクエストが優先的に拒否されるべきです。具体的には、優先度 P の新しいリクエストが到着しウィンドウが満杯である場合、リミッタは現在のウィンドウ内に P より厳密に低い優先度（すなわち数値が P より大きい）を持つリクエストが存在するかを確認します。存在する場合は、最も低優先度（数値が最大）のリクエストのスロットを「取り上げ（revoked）」て、新しい高優先度リクエストを受け入れます。取り上げられたリクエストは報告できるよう記録されるべきです。取り上げ可能な低優先度のリクエストが存在しない場合は、新しいリクエストは拒否されます。 3. **バースト許容**: 各クライアントはオプションで burst（デフォルトは 0）というバースト許容量を持てます。これはウィンドウ内で max_requests に加えて最大 burst 件まで追加のリクエストを許容します。ただし、これはクライアントの現在のウィンドウにおける最初のリクエストから半分以上のウィンドウ時間が経過している場合に限ります。 4. **スレッドセーフ**: レートリミッタは複数のスレッドから同時に使用しても安全でなければなりません。これをテストシナリオで実証してください。 5. **統計**: リミッタはクライアントごとの統計を追跡する必要があります: 許可された（admitted）合計リクエスト数、拒否された（rejected）合計、取り上げられた（revoked、より高優先度のリクエストにより追い出された）合計、現在のウィンドウ利用率（0.0〜1.0 の浮動小数点）を追跡してください。 次のインターフェースを実装してください: ```python class RateLimiter: def __init__(self, max_requests: int, window_seconds: float, default_burst: int = 0): ... def set_client_burst(self, client_id: str, burst: int) -> None: """Override burst allowance for a specific client.""" ... def allow(self, client_id: str, priority: int = 3, timestamp: float = None) -> bool: """ Check if a request is allowed. If timestamp is None, use current time. Returns True if the request is admitted, False if rejected. """ ... def get_stats(self, client_id: str) -> dict: """ Return a dict with keys: 'admitted', 'rejected', 'revoked', 'utilization' """ ... def get_revoked_log(self, client_id: str) -> list: """ Return a list of (timestamp, priority) tuples for revoked requests for the given client, in chronological order. """ ... ``` 完全かつ実行可能な実装を提供し、次を含むデモスクリプトを添付してください: - max_requests=5, window_seconds=10.0, default_burst=2 でリミッタを作成 - 2 人のクライアントからの優先度とタイムスタンプが異なる一連のリクエストをシミュレートし、すべての機能（スライディングウィンドウの期限切れ、優先度による取り上げ、バーストの発動、拒否）を網羅する - 最後に各クライアントの統計と取り上げログを表示 - 少なくとも 4 スレッドを使った簡潔なマルチスレッドテストを含め、同時実行を確認する 次のようなエッジケースにも対応してください: - 優先度値検証（1-5 の範囲でなければならない） - ウィンドウ境界でちょうど到着するリクエスト - 連続した複数の取り上げが発生する場合 - バースト許容がちょうどウィンドウ半分の時点で発動する場合 - 空または未知のクライアント ID に対する統計問い合わせ
プログラミング
ロックフリーの並行LRUキャッシュを実装する
PythonでスレッドセーフなLRU（Least Recently Used、最小最近使用）キャッシュを設計および実装してください。各操作ごとにグローバルロックを使用せずに、同時並行の読み取りおよび書き込みをサポートすること。実装は次の要件を満たす必要があります： 1. キャッシュは、コンストラクタ時に指定された固定の最大容量を持つこと。 2. 次の3つの操作をサポートすること： - get(key): キーに関連付けられた値を返す。キーが存在しない場合は None を返す。キーへのアクセスは、そのキーを最も最近使用されたものとしてマークすること。 - put(key, value): キーと値のペアを挿入または更新する。キャッシュが容量に達しており新しいキーを挿入する場合、最も最近使用されていない（LRU）エントリを追い出すこと。 - delete(key): キーが存在する場合はキャッシュから削除する。キーが見つかって削除された場合は True を、そうでなければ False を返すこと。 3. キャッシュは複数のスレッドから同時に安全に使用できること。異なるキーに対する同時の get 操作は互いにブロックすべきではない。競合を最小化すること — 全てに対して粗い単一のロックをかける設計は許容されない。 4. 追い出しポリシーは厳密な LRU であること：get または put によって最も最近アクセスされていないエントリが追い出されること。 5. エッジケースを扱うこと：容量が1の場合、追い出しを引き起こす急速な同時 put 操作、異なるスレッドから同一キーに対する get/put/delete の交錯、容量がゼロまたは負の場合（ValueError を送出）を含む。 単一の Python モジュールとして完全な実装を提供してください。並行性戦略とそれが整合性を保つ理由の簡潔な説明を付けてください。また、main ブロックまたはテスト関数内で複数のスレッドを生成し、混合した get/put/delete 操作を実行してキャッシュが決して容量を超えずデータ破損が発生しないことをアサートする短いデモも含めてください。
プログラミング
トランザクション対応のインメモリキー・バリューストア
Pythonクラス `InMemoryDB` を実装してください。これはネストされたトランザクションをサポートするシンプルなインメモリのキー・バリューデータストアです。 クラスは次のメソッドを持つべきです: - `get(key)`: キーに関連付けられた値を返します。もしキーが存在しない場合は `None` を返すべきです。 - `set(key, value)`: 指定されたキーの値を設定します。トランザクションが進行中であれば、この変更はコミットされるまでそのトランザクション内でのみ可視であるべきです。 - `begin()`: 新しいトランザクションを開始します。トランザクションはネスト可能です。 - `commit()`: 現在のトランザクションで行われたすべての変更を親トランザクションに（あるいは最外のトランザクションであればメインのストアに）コミットします。アクティブなトランザクションがない場合はエラーを発生させるべきです。 - `rollback()`: 現在のトランザクションで行われたすべての変更を破棄します。アクティブなトランザクションがない場合はエラーを発生させるべきです。