AtCoderで黄色になりました

Last updated at 2026-02-28Posted at 2026-02-19

こんにちは。tau1235です。
ABC444で入黄しました。
入黄するまでのことや感想などをいろいろ書いてみます。

はじめに

高一の夏ごろ(2024/6/30)に競プロを始めてから、高二の冬(2026/2/7)についに黄色になることができました。高校生のうちになれてよかった。

AtCoderに初めて参加したABC360の2024/6/30から2026/2/7まで、1年半とちょっとくらいでしょうか。
入青したのが2025/7/19なので、青から黄色まで半年くらいかかったみたいです。
この中では、水青反復の時期が一番伸び悩んでいて辛かった記憶があります。

ABC444ではA~Eが簡単、Fからとんでもない崖があるという回でした。
私はA~Eを20分くらいで解いたことで2400perfが取れたのですが、F以降が解けなく、100%早解きでレートを稼いだことと、(どうせなら難しい問題を通して入黄したかった...)
444とかいう縁起が悪そうな数字も重なって、なんともいえない気持ちで黄色になりました。
暖色になれた実感がなさすぎる！！！

ちなみに、これまで入水のときも入青のときも、その翌日のARCで落ちています。
しかも、それぞれちょうどrated対象になるdiv2,div1です。呪われてる？

今回も即落ちすると思ってたのですが、早解きに成功して耐えました。やったね。

ところで、AtCoderでは黄色(rating2000)からABCがunratedになります。なんかすごくないですか。
他にも、ABCとかでユーザ解説が書けるようになったりします。
こんな感じで黄色になると色々あるので、AtCoderの中で一つの区切りのようなものだと個人的に感じています。その黄色に自分がなれたというのはやっぱり嬉しいです。

↑謎のボタンがある

これまでにやったこと

黒色時代からもちょっとだけ書きます。
入水くらいまでの記憶が曖昧なので嘘があるかもしれません。

AtCoder初提出~入灰 (2024/6/13~2024/6/30)

高一の初め頃ですね。
なんとなくプログラミングに興味が沸いてきたので、APG4bをやっていました。
AtCoderをどうやって見つけたかは、全く覚えていません。
プログラミング経験もアルゴリズム関連の知識もほぼ0でした。
強いて言えば、学校の授業でちょっと触れたくらいだと思います。少なくともC++は完全に0から学びました。
アルゴリズム関連の知識も、BFS,DFSとかの存在をうっすら知ってた程度だと思います。

入灰~入茶 (2024/6/30~2024/9/7)

ここから入水くらいまでは、Frestさんの

を見ればすべてが分かります。この記事の5億倍くらい価値があるので、見てください。
(Frestさんには許可を取っていません、ごめんなさい！！！何かあれば消します)

ほとんど内容が同じになりますが、覚えてる限りでやったことを書きます。

A~Cの縦埋めをひたすらしてたはずです。
あとはEDPCのA~Eもやったらしいです。

入茶~入緑 (2024/9/7~2024/11/22)

AtCoderProblemsを見た感じ、D埋めもちょっとしていそうでした。
それからは

の「分野別　初中級者が解くべき過去問精選 100 問」のAtCoderにジャッジがあるところをやっていました。AOJの問題はやってないはずです。

入緑~入水 (2024/11/22~2025/2/8)

Eの縦埋め、典型90の★5までをやったと思います。
典型90の問題や解けなかったABCの問題とかの解法とかをNotionにまとめていた時期もありましたが、面倒になって途中でやめました。
今はObsidianを使っていて、難しかったアルゴリズムとか作問メモとかをまとめることもあります。面倒なのでまとめないときもあります。

今もそうなのですが、競プロ関連の本は1冊も持ってません。深い理由はなく、買うのが面倒だからです。本がなくて困ったことは今のところないので、本が必要かどうかは人によりそうです。蟻本だけは１回読んでみたいかも。

入水~入青 (2025/2/8~2025/7/19)

Fの縦埋め、典型90の★7までをやりました。
縦埋めは基本青diffまでしかやってません。

入青~入黄 (2025/7/19~2026/2/7)

JOIに向けて、JOIの難易度5~9を埋めました。逆にそれ以外ほとんどしてなかったらしいです。びっくり。
意外とJOIの過去問は効果があるのかもしれません。
JOI関連の話はここに書いてあるので、気になる人は見てください。

upsolveについては、コンテスト中に解けそうだった問題、解けるべきだと思った問題などは基本upsolveするようにしています。コードは書かなくても、解説を読むことだけはほぼ毎回していたと思います。

ライブラリとか習得アルゴリズムとかの話は、長くなりそうなので別でまとめます。

ライブラリ

現時点で持っているライブラリたちです。
これに書かれていないものは毎回手書きしていると考えてください。

順番は、ファイルに置いてある順番をそのままで書いたので、ある程度時系列順になっている気がしたのですが、そんなことないかもしれません。
ジャンル別に分けている訳ではないので見にくいと思います。すみません。

使用頻度を3段階に分けてみましたが、こういう分類が苦手なので、この数字はあまり参考にならないです。じゃあいらなくない？

1 : ほとんど使わない(1度でも使ったことがあるかないかくらい)
2 : たまに使う
3 : よく使う

名前	使用頻度
ダイクストラ法	1
UnionFind (ACL含む)	3
WeightedUnionFind	2
SegTree (ACL含む)	3
LazySegTree (ACL含む)	3
SegTreeBeats	1
SCC (ACL含む)	2
Trie	2
エラトステネスの篩	2
階乗mod	3
ワーシャルフロイド法	1
拡張ユークリッドの互除法	1
中国剰余定理	1
行列 (繰り返し二乗法含む)	2
ローリングハッシュ	2
全方位木dp	2
LCA	2
重心分解	1
Aho-Corasick	1
FPS	2
FunctionalGraphの閉路列挙	1
分数型	2
１次式の交差判定とか	2

他の人と比べて、ライブラリとして持ってるのは少なめかもしれません。
ライブラリを整備しても、その問題特有の操作とかに対応させるために結局ライブラリを改造することが必要になることがあると思います。自分はその改造が下手(ライブラリの作り方が下手というのもある)なので、結局全部1から書いた方が速かったな...になることがまあまああるのも原因としてあるかもしれません。
ライブラリの整備がめんどくさいというのもあります。
ACLが強すぎるので、ACLを使うだけでもなんとかなる気もします。

ライブラリ関連で、マクロの話も少しします。
マクロは基本使いません。

#include<bits/stdc++.h>
using namespace std;

int main(){

}

全コード共通なのはこれくらいです。多分APG4bに載ってるやつです。あとはusing ll=long longくらいかな？
コードが短く見えて気分が良くなります。マクロを整備した方が早解きにも便利なんでしょうが、これで慣れてしまったのでもう変えたくありません。

知ってるアルゴリズムとか

詳しく書くつもりだったのですが、思い出すのが面倒になったので適当に書きます。

これの中級編・上級編に書かれているアルゴリズム

典型90問で扱われているアルゴリズム
ABCで出題されて解けなかったもの(Aho-Corasickとかはこれ)
自分が参加したABCのFまでに出てくるようなアルゴリズムはほとんど知っているはずです。逆に、ABCに出ないようなやつはほぼ知りません。
その他気になったもの(FPS関連とか)

コンテストの時の話

エディタは基本VSCodeを使っています。環境構築はevimaさんの動画を見てやったので、環境構築とかの話は未だによくわかっていません。難しい。

考察するときは、D,E問題までくらいなら頭の中で済ませることも多いです。場合分けが面倒な問題や、F問題とかになってくるとさすがにメモを使いたくなります。
考察用のメモとして、MediBang Paintというソフトを使っています。これも、Frestさんの動画を見て真似したやつをずっと使い続けているだけです。紙を使う人もいますが、自分の場合は紙とかペンとかを毎回用意するのが面倒なので使ってません。

海外コン

有名なものはだいたい参加するようにしていると思います。
周りを見ていると、AtCoderが青とか黄色くらいの人、Codeforcesは紫とか橙とかに行っている印象なんですが、自分は未だに青です。弱すぎ～
典型早解きばかりに頼りすぎているとこうなる、という悪い例です。

↑ clistです。
yukicoderはclistからアカウントが見つけられなかったので載ってません。

upsolveもしたいんですが、解説が英語なので読む気が起きず放置してしまいがちです。

考察について

考察のときの話をします。

よくやってることを思い出してみました。

とりあえずサンプルケースを手で解く
単純なケースを考える
部分問題に分割する

どれもよくあるやつだと思います。
1 : 実際に手で解こうとすると、なんとなくイメージも掴めるのと、解法が自然と浮かんできたりすることもあるので良いです。例えば、この問題を解こうとするとこういう操作をする必要がありそう、みたいなのを必然的に考えることになるので、困ったらサンプルを解いてる気がします。サンプルだけで特に何も思いつかなかった場合、適当にランダムなケースを自分で作って解いたりします。

2 : イメージとしてはJOIの部分点みたいなのに近いかもしれません。数列に関する問題であれば、数列$A$がすべて同じ要素であるときを考えたり、$A$に重複がないとして考えてみる、とかです。そもそもこういう特殊ケースが解けなければ元の問題も解けるはずがないので、これを考えることで損になることはないと思います。考えやすいケースを考えてから元の問題を考えると、少し変えるだけで元の問題も解けるようになることもよくあるやつです。

3 : あんまり2と変わらない気がしてきました。１つの問題といっても、複数の簡単な問題として分けることで解けることが多いです。というかほとんどの問題がそうかもしれません。例えば、何かを最大化する問題を二分探索と何かしらの判定問題の２つに分ける、みたいなやつとか？(あんまりいい例が思いつかなかった)
考えることが減って脳にも優しいです。