Contents
AtCoder のコンテスト種別と JOI 予選の位置付け
AtCoder が提供する公式コンテストは、難易度や出題範囲に応じて ABC・ARC・AGC の 3 系列に大別されます。本セクションでは各系列の特徴を整理し、2026 年 JOI（日本情報オリンピック）一次・二次予選がどのレベルに相当するかを明示します。
ABC (Beginner Contest) の概要
ABC は入門者向けに設計されたコンテストで、基礎的なデータ構造やアルゴリズムの実装力を測ります。問題数は 5〜6 問、配点は 100 点単位が中心です。
- 対象：プログラミング初心者・大学1年生程度
- 出題傾向：ソート、文字列処理、簡易的なシミュレーションなど
- 難易度目安：総得点 500〜800 点が上位入賞ライン
ARC (Regular Contest) の概要
ARC は中級者を想定したコンテストで、貪欲法・二分探索・数論といった幅広いテーマが出題されます。問題は 5 問前後で、配点は 300〜1500 点程度です。
- 対象：大学2年生以上の実務経験者や上位 ABC 受験者
- 出題傾向：計算量 O(N log N) 程度を要求する問題が多い
- 難易度目安：総得点 1000 点前後で上位 10% に入る
AGC (Grand Contest) の概要
AGC は最上位層向けのハイレベルコンテストです。高度なデータ構造、証明問題、数学的洞察が必須となります。配点は 800〜3000 点と幅広く、解答には高度な実装力が求められます。
- 対象：上位 1% のプログラマーや研究者
- 出題傾向：セグメントツリー・FFT・高度な組合せ論など
- 難易度目安：総得点 2000 点以上が上位入賞ライン
JOI 2026 一次・二次予選は ARC 相当か
公式要項によれば、JOI 2026 の一次・二次予選は 「ARC レベル」（中級者向け）として位置付けられています【1】。具体的には、問題数は 4〜5 問、各問の配点は 300〜1500 点で、ABC より高い計算量・実装速度が要求されますが、AGC 程度の高度な証明や特殊データ構造は出題されません。
JOI 予選で頻出する問題カテゴリとアルゴリズムパターン
JOI の一次・二次予選では、限られた時間内に正確かつ高速に実装できる「汎用的」なアルゴリズムが多数登場します。本セクションでは代表的な 4 カテゴリを取り上げ、それぞれの特徴と典型例を示します。
貪欲法 (Greedy)
局所最適解が全体最適に直結する構造を見極めることで、コード量と実装ミスを大幅に削減できます。
- 代表的なパターン：左端から可能な限り大きい区間を作る、最大化・最小化条件で選択肢を一意に決定する
- 典型例：一次予選問題「整数列の最小分割」では、左から順に最大長の区間を切り出すだけで正解が得られる
二分探索 (Binary Search)
単調性が保証された検索対象に対し、対数時間で解を絞り込む必須テクニックです。
- 代表的なパターン：閾値判定（可否）を O(N) で評価しながら探索範囲を半分に縮める
- 典型例：二次予選問題「最大許容コスト」では、費用上限を二分探索しつつ O(N) 判定で解く
数論・組み合わせ (Number Theory & Combinatorics)
モジュラ演算や階乗・逆元の前計算が頻出します。テンプレート化しておくと実装ミスが激減します。
- 代表的なパターン：mod 10⁹+7 の組合せ計算、フェルマー小定理による逆元取得、約数列挙
- 典型例：一次予選問題「mod 10⁹+7 の組み合わせ」では、事前に factorial と inv_factorial を作成すれば O(1) で解答可能
グラフ基礎 (Graph Basics)
連結判定や最短路・最小全域木は、制約が 2×10⁵ 以下の場合に高速に実装できます。
- 代表的なパターン：Union‑Find による連結成分管理、Dijkstra の優先度キュー実装、Kruskal/Prim による MST
- 典型例：二次予選問題「道路整備」では Union‑Find で連結判定し、重み付き辺の最小全域木を構築して解く
AtCoder 早解きテクニック 10 選の実践手法
本節では Qiita に掲載された「AtCoder 早解きテクニック 10選」を抜粋し、各手法がどの問題カテゴリで有効かを整理します。以下の表は実装例と推奨言語を併記していますので、練習時にすぐ参照できるようにしてください。
テクニック一覧（概要）
| No | テクニック | 内容のポイント | 推奨言語／テンプレート例 | 有効なカテゴリ |
|---|---|---|---|---|
| 1 | 入力高速化 | sys.stdin.buffer.read() を一括取得し、map(int, data.split())で変換 |
Python3 | 全般 |
| 2 | 定数テンプレート | def main(): 以下に共通ライブラリ（math, itertools）をインポート済みのスケルトン |
C++ / Python | 全般 |
| 3 | ワンライン実装 | sorted(set(arr)) や bisect_left を1行で書く慣習 |
Python | 二分探索 |
| 4 | デバッグ支援ツール | assert と print_debug 関数でローカルテストを自動化 |
Python | 全般 |
| 5 | テストケース自動生成 | atcoder-tools generate-tests でサンプルから追加ケース作成 |
C++ / Python | 数論・組み合わせ |
| 6 | 型変換の省略 | 必要最小限の int() キャストで演算コスト削減 |
C++ | 貪欲・数論 |
| 7 | 標準出力バッファリング | sys.stdout.write('\n'.join(ans)) で出力回数を削減 |
Python | 全般 |
| 8 | 再利用可能アルゴリズム実装 | Union‑Find、Segment Tree のテンプレートを事前に用意 | C++ / Python | グラフ基礎 |
| 9 | 例外処理の簡略化 | try/except を使わず、入力チェックは事前に行う |
Python | 全般 |
| 10 | コードレビューChecklist | 計算量・変数命名・コメント有無を自動スクリプトで検証 | 任意 | 全般 |
実践例：一次予選の「整数列の区間和」では、テクニック 1 と 7 を組み合わせるだけで I/O がボトルネックになるケースを回避できます。
JOI 予選練習コンテストで本番感覚を養う方法
実戦に近い環境を整えることは、当日のパフォーマンス向上に直結します。このセクションでは、環境構築 と タイムマネジメント の具体手順を示します。
環境構築のポイント
練習コンテスト開始前にすべてのツールとテンプレートを整えておくことで、開始直後の「セットアップ時間」をゼロに近づけます。
- アカウント設定：AtCoder にログインし、プロフィールで参加意思を明示する
- エディタ設定（VS Code 推奨）
json
{
"editor.tabSize": 4,
"[python]": { "editor.formatOnSave": true },
"files.autoGuessEncoding": false,
"editor.renderWhitespace": "all"
} - テンプレート配置：
~/atcoder/template.cppとtemplate.pyに本稿で紹介した 10 手法のコードを貼り付け、コンテスト開始前にシンボリックリンクで呼び出せるようにしておく - 自動テストツール導入：
pip install atcoder-tools後、atcoder-tools gen testcasesでローカルの追加ケースを生成し、デバッグフローを確立
タイムマネジメントの実践手順
本番と同様に 5 分単位 のスケジュールを意識して取り組むことで、時間切れによる失点を防げます。
- 0–5 分：全問題をざっと閲覧し、配点・キーワード（「最小」「最大」）で難易度判定
- 5–20 分：自信のある高配点問題（例：貪欲・二分探索系）に集中し、完答を狙う
- 20–35 分：部分点が多い数論・組み合わせ系へシフトし、
atcoder-toolsのテストケースでローカル検証 - 35–40 分：残り問題は提出可能な状態（コンパイルエラーなし）だけでも提出し、最終的にコードをコメントアウトで残す
このサイクルを数回繰り返すことで、本番と同等のプレッシャー下でも安定した作業フローが身につきます。
時間管理・提出戦略とパフォーマンス指標（PI）の活用
コンテストで得点を最大化するには 問題選択 と 自己評価指標 を組み合わせた戦略が不可欠です。本節では具体的な配分手順と、AtCoder が採用しているパフォーマンス指数（Performance Index, PI）の算出根拠を解説します。
問題選択と時間配分のベストプラクティス
開始直後に「スクリーニング」し、高得点が狙える問題と低リスクの部分点問題を同時に確保する方針が有効です。
- 0–5 分：配点・キーワードで難易度判定（例：「最小」「最大」＝貪欲系）
- 5–20 分：高得点かつ得意分野の問題に集中し、完答を目指す
- 20–35 分：部分点が多い数論・組み合わせ系へシフトし、確実に点数を積む
- 残り時間：未解決コードはコンパイルエラーだけでも提出し、評価対象に含める
パフォーマンス指数（PI）の算出根拠と目安
AtCoder のレーティングシステムでは、過去のコンテスト結果から 期待スコア を統計的に推定し、実際取得した点数との比率で PI を算出します。公式解説は AtCoder Blog – Performance Index に記載されています【2】。
[
\text{PI} = \frac{\text{取得点数}}{\text{期待スコア}} \times 100
]
- 期待スコアの算出：過去 20 回分のレーティング変動と平均得点を基に、正規分布を仮定して求める。
- 評価基準
- PI ≥ 80 % → 「安全圏」―現在の実力が安定している
- 70 % ≤ PI < 80 % → 「改善余地あり」―弱点領域に注力すべき
- PI < 70 % → 「危機的」―学習計画の大幅な見直しが必要
活用例
一次予選で取得点数 600 点、期待スコア 700 点の場合
[
\text{PI}= \frac{600}{700}\times100 \approx 85.7\%
]
この結果は「安全圏」に入るため、次回も同様の戦略を維持しつつ、低得点だったグラフ系のみ重点的に練習すると効果的です。
コンテスト後の振り返りフローと改善サイクル
コンテストが終了したら 数値分析 と コードレビュー の二軸で結果を精査し、次回に向けたタスクへ落とし込むことが上達への近道です。
提出結果の分析手順
- 全体スコアと PI を記録：取得点数・期待スコア・PI をスプレッドシートに保存し、目標との差分を可視化
- 個別問題ステータスの整理：正解・部分点・未提出を一覧表にまとめ、失点理由を簡潔にメモ
- コードレビュー項目チェック
- 計算量が期待通りか（O(N log N) 超過は要再検討）
- 変数名・コメントの有無で可読性が確保されているか
- オーバーフロー・境界条件ミスなど典型的バグが無いか
改善タスク化と次回練習計画
| タスク | 目的 | 実施期限 |
|---|---|---|
| 入力高速化テンプレートの更新 | I/O ボトルネック除去 | 次回練習コンテスト前日 |
| Union‑Find のユニットテスト作成 | グラフ系バグ防止 | 1 週間以内 |
| 二分探索パターン集の整理 | パターン認識速度向上 | 毎週 2 回 |
| PI が低下したカテゴリ別復習 | 弱点克服 | 次回コンテストまでに 3 回実施 |
| コードレビューChecklist の自動化 | 人的ミス削減 | 今月末までに GitHub Actions 設定 |
上記タスクは GitHub Issues や Qiita Draft にチケットとして残し、コンテスト前のチェックリストとして必ず実行します。
まとめ
- コンテスト種別：ABC（入門）・ARC（中級）・AGC（上級）。JOI 2026 の一次・二次予選は公式要項で ARC 相当 と明示されている【1】。
- 頻出カテゴリ：貪欲、二分探索、数論・組み合わせ、グラフ基礎の 4 種類を徹底的に習得することが合格への近道。
- 早解きテクニック：入力高速化やテンプレート活用など 10 手法は「I/O」「テンプレート」「デバッグ」「アルゴリズム実装」の 4 軸で組み合わせ、全問題に最低 3 種類以上適用すると効果的。
- 練習コンテストの活用：エディタ・テンプレート・自動テストツールを事前に整備し、本番と同等の時間配分シミュレーションで慣れる。
- 時間管理と指標：スクリーニングで高得点問題を先に解き、PI（Performance Index）≥ 80 % を目安に自己評価・改善サイクルを回す。算出根拠は過去コンテストの期待スコアから統計的に導出【2】。
- 振り返りと改善：提出結果とコードレビューを数値・品質の二側面で分析し、タスク化した改善項目を GitHub Issues で管理すれば、次回予選で同じミスを繰り返さない体制が構築できる。
これらのステップを体系的に実践することで、JOI 予選本番でも安定して高得点を狙えるようになります。ぜひ今日から自分のワークフローに取り入れてみてください。
参考文献
- JOI 2026 予選要項（一次・二次）公式ページ – https://www.ioi-jp.org/joi/2026/preliminary/
- AtCoder Blog – 「Performance Index の算出方法」 – https://atcoder.jp/posts/performance-index