← 練習ガイド · アプリの仕組み

速さを比較する前に、初期化・互換性・エラーを確認する。 以下は2022年当時の条件です。ポータルやAWSの構築手順が現在の練習環境でも使えることは保証していません。

順番	処理	時間・失敗条件
1	POST /initialize	30秒でタイムアウト。失敗すれば即fail
2	アプリケーション互換性チェック	数秒〜数十秒。失敗すれば即fail
3	負荷走行	60秒。終了時に未完了リクエストを切断

/initialize は期待される初期状態を復元し、実装言語を {"lang":"go"} のように返します。lang が空なら初期化失敗です。データ構造を変えても初期化の整合性を保つ必要があります。

項目	扱い
参加者の3つの閲覧API	成功1回につき1点
採点対象の管理者API	成功1回につき10点
通常エラー	1件につき負荷走行スコアの1%減点
Criticalエラー	1件につき負荷走行スコアの10%減点

減点率は 通常エラー数 × 1% + Criticalエラー数 × 10%。0点が確定すると走行を打ち切り、failになります。例：成功点3,000点、通常5件、Critical 2件なら25%減点で2,250点です。

Criticalになるのは、下記の処理でエラーになった場合。 正常な失格者への403応答そのものがエラーという意味ではありません。

• テナントの追加
• 大会の追加・スコア入稿・終了
• 参加者の失格処理
• 失格済み参加者による GET /api/player/* の検証

採点対象APIの一覧を開く

点数	メソッド	パス	エラー時
1	GET	/api/player/player/:player_id	通常。ただし失格済み参加者の検証はCritical
1	GET	/api/player/competition/:competition_id/ranking	同上
1	GET	/api/player/competitions	同上
10	POST	/api/admin/tenants/add	Critical
10	GET	/api/admin/tenants/billing	通常
10	GET	/api/organizer/players	通常
10	POST	/api/organizer/players/add	通常
10	POST	/api/organizer/player/:player_id/disqualified	Critical
10	POST	/api/organizer/competitions/add	Critical
10	POST	/api/organizer/competition/:competition_id/finish	Critical
10	POST	/api/organizer/competition/:competition_id/score	Critical
10	GET	/api/organizer/billing	通常
10	GET	/api/organizer/competitions	通常

予期しないステータスコードや正常でないレスポンスはエラーです。

更新操作	反映先	許容される猶予
大会終了 POST /api/organizer/competition/:competition_id/finish	GET /api/organizer/billing、GET /api/admin/tenants/billing	更新レスポンスを返してから3秒
参加者失格 POST /api/organizer/player/:player_id/disqualified	GET /api/player/player/:player_id、GET /api/player/competition/:competition_id/ranking、GET /api/player/competitions	更新レスポンスを返してから3秒

全APIに一律3秒の遅延が認められるわけではありません。

429 Too Many Requests を返せるのは次の2つです。Retry-After が必要で、ベンチは指定秒数待って再試行します。その429応答には得点が付きません。

• POST /api/admin/tenants/add
• POST /api/organizer/competitions/add

対象	原文での扱い
DB初期化	POST /initialize または ~isucon/webapp/sql/init.sh。実行するとDBの内容が変更される
MySQLの初期dump	/home/isucon/webapp/sql/admin/。原文では /initialize・init.sh からは使わない
SQLite3の初期DB	/home/isucon/initial_data。原文では初期化に使う
実装言語	初期はGo。ほかにNode.js・Perl・PHP・Python・Ruby・Rust・Java
接続	ホスト名とHTTPSを維持。ベンチの接続先は isuports-1.t.isucon.dev 〜 isuports-3.t.isucon.dev
認証	ベンチはJWTを自前発行。ブラウザ用のblackauthは維持

この練習リポジトリとの差分： 原文はDocker Composeをsystemdから起動する構成ですが、現在のREADMEではGoバイナリを起動する構成として記録されています。言語切り替えや復旧は、現環境のサービス定義を確認してから行ってください。

当時の追試条件を、練習用の確認項目に並べ替えています。

• 再起動後にベンチが通る。
• 再現スコアが最終計測の 85%を超える。原文では85%以下がfail。
• ベンチで書き込まれたデータを再起動後も取得できる。
• ブラウザの挙動を維持している。blackauthも動く。

当時の最終スコアは最高値ではなく競技中の最後の計測値です。後半2項目は、当時は上位チームへの追試項目でした。

2022年当時の環境・運営規則（必要なときだけ読む）

環境

• チーム固有のCloudFormationテンプレートを東京リージョンで使用。主な資源は c5.large 3台、gp3 20GB 3個。
• GitHub登録のSSH鍵で isucon ユーザーとして接続。SSM接続時は ssm-user から切り替える。
• /usr/local/bin/isucon-env-checker で環境確認とポータルへの情報送信を行う。
• テンプレートに沿わない資源変更や外部資源への処理委譲は禁止。監視・テスト・開発への外部資源利用は許可されるが、スコアを向上させる効果を持ってはいけない。
• 終了時に環境チェックに失敗したり、ポータルのサーバー情報が複数スタックで混在していたりすると失格。

変更禁止・終了後の扱い

• isucon-env-checker.service 本体と有効化リンク、/opt/isucon-env-checker 配下、/usr/local/bin/isucon-env-checker は変更禁止。
• /etc/systemd/system/blackauth.service は変更禁止。運営の追試用ユーザー・公開鍵などを削除して追試を妨げない。
• 終了後は3台を起動したまま維持し、運営の案内まで操作・停止・削除しない。
• 競技中の問題内容の公開、チーム外との情報交換、結託、不正アクセスや妨害は禁止。

当日の流れ

時刻・窓口	内容
10:00	競技開始
17:00	他チームのリーダーボード更新停止。自チームは更新継続
18:00	競技終了
翌14:00	結果発表予定
ポータル	ベンチの投入・結果確認、質問・サポート。PENDING／RUNNING中は追加投入不可
Discord	運営の告知と呼びかけを確認。競技中の質問はポータルへ

CloudFormationの画面操作や詳細な禁止事項は、下記の原文を参照してください。

出典：ISUCON12 予選当日マニュアル。現環境との差分のみリポジトリREADMEを参照。