はじめに
初めまして！
私は2026年2月ごろから競技プログラミングを始め、約半年間AtCoderに取り組んできました。
そして先日、ついにAtCoderで青色になることができました！ 🎉
せっかく一つの区切りまで来たので、今回は、競技プログラミングを始める前の自分がどのくらいのレベルだったのか、そこから半年間でどんなことをやってきたのか、そしてレートがどのように上がっていったのかをまとめてみようと思います。
この記事が、これから競技プログラミングを始めようと思っている方や、同じようにプログラミングにまだ慣れていない方にとって、少しでも参考になれば嬉しいです。
「半年で青になるための方法」というよりは、「こんな感じでやっていたら青になれました」という一つの体験談として読んでもらえればと思います。
AtCoderを始める前の自分
競技プログラミングをする上で重要な能力として、個人的には大きく**「プログラミング力」と「数学力」**の2つがあると思っています。
では、そんな自分がAtCoderを始める前、この2つの能力をどのくらい持っていたのかというと……
プログラミング力
Pythonで四則演算ができて、if文がなんとなく分かる程度。
数学力
高校数学までの基本的な内容は一通り身についている程度。
……といった感じでした。
つまり、プログラミングについてはほぼ初心者です。
そもそも競技プログラミングについても、「そういうものがあるらしい」という程度の認識で、具体的にどんなことをするのかもほとんど知りませんでした。
そんな状態から、2026年2月ごろにAtCoderを始めることになります。
ここから一体どのようにして青色までたどり着いたのか、振り返っていきたいと思います。
3. 実際にやったこととレート遷移
まず、私のレートの遷移はこんな感じでした。
ここからは、実際にどんなことをしながらレートを上げていったのか、月ごとに振り返っていきたいと思います。
1か月目
AtCoderを始めたばかりの頃は、そもそも問題の入力をどう受け取るのか、答えをどう出力するのかすらよく分かっていない状態でした。
そこで、最初はAIに一つ一つ質問しながら、整数や数列などのデータをPythonでどのように受け取って、どのように処理・出力するのかを、実際の過去問を解きながら学んでいきました。
解説を読んでもよく分からないことが多かったので、
「このコードは何をしているの？」
「なぜこれで答えが求まるの？」
「そもそもこの考え方をどうやって思いつくの？」
といったことをAIに理解できるまでひたすら質問していました。
まずはA問題、B問題を中心に取り組み、Pythonでの基本的な問題の解き方に少しずつ慣れていきました。
そして、A・B問題にある程度慣れてきたところで、次はC問題にも挑戦し始めました。
ここから一気に難しくなります。
C問題では、累積和のようなアルゴリズムや、優先度付きキューのような特定のデータ構造を知らないと解けない問題がかなり増えてきました。
最初は「こんなのどうやって思いつくんだ……」という問題ばかりで、かなり苦労しました。
そこで、とにかく知識を増やすために、AtCoderのA～C問題の過去問を上から順番にどんどん解いていきました。
分からないアルゴリズムやデータ構造が出てきたら、その都度調べて、実際にコードを書いて使ってみる。
これをひたすら繰り返しました。
その結果、少しずつですが、
「この問題なら累積和が使えるんじゃないか？」
「ここは優先度付きキューを使えばよさそう」
というように、問題を見たときに使えそうなアルゴリズムを思いつける力が身についてきました。
少なくとも、優しめのC問題であれば、問題文を読んで「これ、あれを使えば解けそうだな」と考えられるくらいにはなりました。
2か月目
2か月目も、精進では引き続きC問題をひたすら解いていました。
それと並行して、様々な基礎的なアルゴリズムについても勉強していきました。
例えば、
- DFS
- BFS
- 二分探索
- いもす法
- その他の基本的なアルゴリズム・データ構造
などです。
ただアルゴリズムの名前や実装方法を覚えるだけではなく、
「どういう状況のときに、このアルゴリズムを使うのか」
を意識して勉強するようにしていました。
最初の頃は、問題を見ても「どのアルゴリズムを使えばいいのか」が全く分かりませんでした。
しかし、過去問をたくさん解いていくうちに、少しずつ問題の特徴とアルゴリズムが結びつくようになっていきました。
このあたりから、C問題までで身につけた知識を組み合わせたり、少し工夫したりすることで、D問題なら解法を思いつけるという場面も増えてきました。
「問題を見ても何をすればいいのか全く分からない」という状態から、「知っているアルゴリズムを使って解けそう」と考えられるようになってきたので、自分でも成長を実感できる時期でした。
3・4か月目
しかし、ここで一度パフォーマンスが伸び悩みました。
原因は、E問題が全然解けないことです。
なんとかD問題までは解けるようになったものの、E問題になると途端に何も思いつかなくなり、
「この問題、どうやって解くんだ……？」
と一時間近く悩み続けて、そのままコンテストが終わってしまう、ということもありました。
この頃になると、さすがにC問題をひたすら解いて得られる知識や考察力だけでは、E問題には太刀打ちできなくなってきました。
そこで、今度はD問題を上からひたすら解いていくことにしました。
C問題のときと同じように、過去問をどんどん解きながら、D問題で使われる考え方やアルゴリズムを身につけていきました。
また、この時期からは**AWC（AtCoder Weekly Contest）**という平日に開催されている練習用コンテストにも積極的に参加するようになりました。
過去問を解くだけではなく、実際のコンテストに近い状況で、
- 問題文を読んで解法を考える
- 制限時間を意識する
- どの問題から手をつけるか判断する
- 思いついた解法が本当に正しいか考える
といったことを繰り返すことで、単純な知識だけではなく、問題を見て解法を考える力そのものを鍛えることを意識しました。
こうした精進をしばらく続けていると、少しずつですが簡単なE問題なら解けるという場面も増えてきました。
そして、それに伴ってコンテストでのパフォーマンスも目に見えて上がり始めました。
5・6か月目
5か月目あたりから、次の目標として**「青色になる」**ことを意識するようになりました。
この頃になると、青色を目指すためには、E問題までを早めに解く、あるいは何とかF問題まで解くといったレベルが求められるようになってきます。
しかし、ここで一つ大きな問題がありました。
タイピングがめちゃくちゃ遅い。
プログラミング経験が浅かったこともあり、この頃の自分は何ならほぼ両手の人差し指だけでタイピングしているような状態でした。
そのため、コーディングの速さで他の人と勝負しようとすると、かなり分が悪い状況でした。
そこで、コーディングの速さではなく、考察にかかる時間を減らすことで差をつけようと考えるようになりました。
具体的には、これまで以上にさまざまなアルゴリズムについて学習し、E・F問題についても、たとえその場で解けなかったとしても、まずは自分なりに解法を考えるようにしました。
そして解けなかった問題については、解説をただ読むだけではなく、「なぜこの解法になるのか」を自分の言葉で説明できるレベルまで読み込むことを意識しました。
それでも分からない部分についてはAIにも補足してもらいながら、一つずつ理解していきました。
こうしたことを続けていると、E問題を見たときに、
「なんだかあの問題に似ているな」
とか、
「この方針でいけるんじゃないか？」
といったことを思いつける場面が少しずつ増えていきました。
その結果、E問題を解けることが安定してきて、コンテストでもEまで到達できることが増えていきました。
さらに、F問題についても、比較的簡単な回であれば解ける場面が少しずつ出てくるようになりました。
また、レートがある程度上がったことで、もう一段階高い考察力が求められるARCにも参加できるようになりました。
ARCでは、通常のABCとはまた違ったタイプの問題に取り組むことができ、そこでさらに考察力を鍛えることができました。
そして、考察力が上がっていくにつれて、ARCでも少しずつレートを上げられるようになっていきました。
この頃には、コンテストで青色のパフォーマンスを出せることもかなり増えてきました。
そして、ついに――
記念すべき35回目のコンテストで、入青することができました！ 🎉
AtCoderを始めた頃は、問題の入力方法すらよく分からなかった自分が、半年後には青色までたどり着くことができました。
振り返ってみると、最初から難しい問題を解けたわけではなく、その時々で自分に足りないものを見つけて、それを過去問やコンテストを通して一つずつ埋めていったことが、成長につながったのかなと思います。
4. 半年間を振り返って分かったこと
半年間競技プログラミングに取り組んできて、特に「これは大事だったな」と感じたことを3つ紹介します。
AIはガンガン活用しよう
個人的には、AIはかなり積極的に活用していいと思っています。
特に初心者のうちは、「何が分からないのかすら分からない」という状態になることが多いと思います。
そんな状態で同じような質問を何度もしても、AIならその都度こちらの理解度に合わせて説明してくれます。
また、競技プログラミングの解説では、ある程度知識があることを前提として、途中の説明が省略されていることもよくあります。
そういったときに、問題文と解説をAIに投げて「この部分がよく分からない」と聞いてみると、解説では省略されていた部分を補足して詳しく説明してくれます。
「分からないところをそのままにしない」という意味では、AIはかなり役に立ったと感じています。
ただし、AIの言うことを何でも鵜呑みにするのは危険です。
問題を丸ごと投げるだけだと、たまに的外れなことを言い出すこともあります。
実際、私自身も一度AIの説明に惑わされて、一つの問題に2時間くらい迷走したことがあります……。
AIはあくまで理解を助けるための道具として使い、最終的には自分で考えて、納得できるところまで理解することが大切だと思います。
解いた過去問の数は正義
競技プログラミングでは、解いた過去問の数はやっぱり正義だと思います。
問題を解いていると、
「このアルゴリズムを知らなかったら、普通は思いつかないんじゃないか？」
と思うような問題に出会うことがあります。
特にABCでは、そういった問題であっても、過去問を遡ってみると、似たような考え方やアルゴリズムの使い方をする問題が見つかることが多いです。
そして本番でその問題に出会ったとき、
「これ、前に解いた問題と似ている！」
と思えるかどうかが、かなり大きな差になります。
結局のところ、**「その問題を解いたことがあるか」「似た問題を見たことがあるか」**が運命を分ける場面はかなり多いです。
もちろん、ただ数をこなせばいいというわけではありません。
次の項目にもつながりますが、解いた問題から何を吸収するかも同じくらい重要だと思います。
問題を解くときは「解き方の理解」までがセット
これはコンテスト後の復習でも、普段の精進でも同じなのですが、解けなかった問題の解説をなんとなく読んで、
「へー、こうやって解くんだ」
で終わってしまうのは、めちゃくちゃもったいないです。
その場では分かったつもりになっていても、次に似たような問題に出会ったときには、結局思い出せなくなってしまいます。
特に競技プログラミングの解説では、突然よく分からない式変形が始まったり、「ここから明らかに〜」と言われたりして、正直、目をそらしたくなる場面もかなりあります。
ですが、そういうときこそ、
「なぜこの式になるのか？」
「なぜこのアルゴリズムで解けるのか？」
「この考え方は他の問題でも使えるのか？」
というところまで掘り下げて理解することが大切だと思います。
私の場合は、解説を読んでも分からない部分をAIに質問しながら、一つずつ理解していきました。
もちろんAIに限らず、インターネット上には競技プログラミングのコミュニティがたくさんあります。
どうしても分からない問題があれば、実際に上位の人に聞いてみるというのもかなり有効な手段だと思います。
「解説を読んで終わり」ではなく、自分の言葉で解法を説明できるところまで理解する。
これを意識するだけでも、過去問から得られるものはかなり変わってくると思います。
さいごに
ここまで読んでいただき、ありがとうございました！
この記事を読んで、「プログラミング初心者だけど、競技プログラミングを始めてみようかな」と思ってくれる人が一人でも増えてくれたら嬉しいです。
また、現在AtCoderに取り組んでいて、レートが伸び悩んでいる方にとっても、この記事が少しでも参考になればと思います。
私自身、最初は問題の入力方法すらよく分からないところからのスタートでした。
それでも、分からないことを一つずつ理解して、過去問を解いて、コンテストに参加して……と続けていくことで、半年後には青色まで到達することができました。
この記事が、これから競技プログラミングを始める人のきっかけになれば幸いです。
それでは、またどこかで！ 👋