cellotakです。
先週末実施された大学入学共通テストですが、去年から新たに「情報Ⅰ」が科目として加わりました。
去年もプライベートで解いていたのですが、新しい科目なだけに問題傾向も変化が大きくなりそうだなと気になっていたので、今年も解いてみました。
解いてみた結果を交えつつ、3年目のWeb受託開発エンジニアとしての感想、去年との比較などを書いていきたいと思います。
問題と解答
問題と解答は各所で公開されています↓
参考: 【日経】共通テスト2026 問題と正解 （旧センター試験）
問題形式
問題形式は2025年と同様です。
- 時間は60分
- 大問が4つ。
- 択一問題と英数字の穴埋め問題をマークシートで答える形式
大問ごとの出題分野
こちらには変化があったので2025年と2026年を比較します。
2025年
| 大問 | 出題分野 | 配点 | |
|---|---|---|---|
| 第1問 | 小問集合 | 20 | |
| 第2問 | A | 情報システム | 15 |
| B | シミュレーション | 15 | |
| 第3問 | プログラミング（アルゴリズム） | 25 | |
| 第4問 | データの活用（統計） | 25 | |
2026年
| 大問 | 出題分野 | 配点 | |
|---|---|---|---|
| 第1問 | 小問×2、16進法、情報デザイン、ネットワーク | 25 | |
| 第2問 | A | 情報システム | 15 |
| B | 論理演算 | 15 | |
| 第3問 | プログラミング（アルゴリズム） | 25 | |
| 第4問 | データの活用（統計） | 25 | |
今年は主に第1問と第2問に大きく傾向の変化がありました。
後述しますが、第1問は一応小問集合っぽい扱いではあるものの、序盤の2つを除いては各問が小問とは呼べない重さになっていて、数はそのまま（なんなら増えてる？）という感じでした。
第2問のBは2025年はシミュレーションというテーマで、日本語理解力を試されるような内容でしたが、今年はしっかり論理演算が必要になるような問題となっていました。
結果
実際自分が解いてみた結果も比較します。
2025年
| 大問 | 配点 | 得点 |
|---|---|---|
| 第1問 | 20 | 20 |
| 第2問 | 15 | 12 |
| 15 | 15 | |
| 第3問 | 25 | 19 |
| 第4問 | 25 | 21 |
| 合計 | 100 | 87 |
2026年
| 大問 | 配点 | 得点 |
|---|---|---|
| 第1問 | 20 | 18 |
| 第2問 | 15 | 15 |
| 15 | 15 | |
| 第3問 | 25 | 22 |
| 第4問 | 25 | 18 |
| 合計 | 100 | 88 |
全体としての感想
大幅に難化ということになりそうです。
2025年の平均点は69.26点だったようですが（この時が簡単すぎたというのがありますが）、今年の平均点は1/21発表の中間集計では60点を割り、59.76点となっています。
参考: 令和８年度大学入学共通テスト（本試験）平均点等一覧（中間集計）
特に時間面がシビアになっています。昨年も少し時間が足りなかったため、今回は意識してかなり急いで解いたのですが、第1問、第2問がかなりボリューミーになっていたことでさらに厳しくなり、最後まで解ききれませんでした。（第4問での失点は時間切れ）
ただ、あくまで個人的な感想としては問題の質は上がった気がします。
2025年の問題は全体的に「素早く正確な読解力が求められるパズル」といった感じで、専門的な要素に乏しかった印象ですが、今年はネットワークやセキュリティの知識が問われたり、進数変換や論理演算の訓練がある程度必要になる問題があったりなど、より「情報」っぽくなった気がします。
個人的には基本情報技術者試験の問題に雰囲気が似てきたような印象でした。
そのため受験生にとっては、問題量が増え、専門性が上がったというダブルパンチで難化ということになりそうですが、読解力パズル要素が減って、知識や経験で解ける要素が増えてくれたおかげで自分としては点数がほぼ変わらなかったという形になります。
問題ごとの感想
第1問
問1
知識を問う小問。
2問しかないですが、逆にこういうのはもう少し増やしてもいいのかなと思ったりします。
問2
クロスステッチをビットに見立てて、進数変換などを行う問題。
法則に気づいてしまえば進数変換以外の計算はいらないものだったので、ちょっとパズルゲーム感強めでした。
シフト演算とかも織り交ぜるとより専門っぽくなりそうな気がしました。
問3
生年月日の入力UIをテーマにした問題。
中身は数学の統計の問題という感じです。
問4
メールに関する問題。
ドメイン名やユーザー名を間違えたときにどこでエラーが発生するかという問題でした。
ドメインやメールに関して、丸暗記ではなく仕組みを把握しているかが問える良い問題だなと思いました。
第2問
A
住民情報の証明書システムを題材とした問題。
これは完全にマイナンバーシステムを意識していて、マイナンバーカードを使ってコンビニで住民票を印刷したり、自宅のデバイスでマイナンバーカードを読み取って個人情報の証明をしたり、という流れを模した問題となっていました。
社会人としては実体験として想像しやすい話題だったかと思いますし、問題としては良かったと思いますが、受験生にとっては何のことかイメージが湧きづらい題材だった気はします。
学生であっても役所手続きだったり時事だったりに幅広くアンテナを張っていることが求められているのかなと感じました。
B
グレースケールの画像の重ね合わせを題材とした問題。
白い余白を持ったキャラクター画像を背景画像に重ね合わせる時に余白を透過させるためにどういう論理演算をしたらいいかが問われていました。
実際の画像処理でこういうことをしているのかはちょっと分かりませんが、論理演算を単に数式だけでやらせるのではなく、普段目にするような技術と絡めて出題しているのは上手いなと思いました。
第3問
去年と同様文化祭を題材としたプログラミング問題でした。
（最近の高校生は文化祭でプログラミングするんだろうか）
こちらは去年と傾向があまり変わっていない印象です。
内容としては、文化祭の体験展示の待ち時間を計算したり、待ち時間に応じて適切な体験時間を計算するプログラムを作っているというものでした。
この問題に関しては気になった点がいくつかあったので後述します。
第4問
サクラの開花予想日を題材とした統計系の問題でした。
こちらも去年と傾向は似ている印象です。
データサイエンスとかにはこういうのが必要そうと思いつつ、疎い分野なので問題の良し悪しはよくわかりませんでした。
題材としている内容が結構面白くて、400度の法則、600度の法則というワードは聞いたことがありましたが、「緯度が高いと実際の開花日と乖離しやすい」とか「氷点下日の日数で補正できそう」というのはかなり知識として興味深いものでした。
あまり良くないと感じた部分
全体的に良い問題が増えたという感想ですが、プログラミングの問題はまだ改善の余地がありそうだと感じました。
問題で使われていたプログラムの一つが以下です。
(01) Touchaku = [0, 3, 4, 10, 11, 12]
(xx) taiken = 1
(xx) saichou = 0
(02) kyakusu = 要素数(Touchaku)
(03) (taiken <= 15) and (saichou < 10)の間繰り返す:
(04) | Kaishi = [0, 0, 0, 0, 0, 0]
(05) | Shuryou = [0, 0, 0, 0, 0, 0]
(06) | Shuryou[1] = taiken
(07) | iを2からkyakusu まで1ずつ増やしながら繰り返す:
(08) | | Kaishi[i] = 最大値(Shuryou[i-1], Touchaku[i])
(09) | |_ Shuryou[i] = Kaishi[i] + taiken
(10) | saichou = 0
(11) | iを1からkyakusu まで1ずつ増やしながら繰り返す:
(12) | |_ saichou = 最大値(saichou, Kaishi[i] - Touchaku[i])
(13) | もし saichou < 10 ならば:
(14) | |_ 表示する("体験時間", taiken, "分間:", "最長待ち時間", saichou, "分間")
(xx) |_ taiken = taiken + 1
なお、実際は穴埋めになっていた部分(xxの行など)は正解を埋めた状態にしています。
気になるポイント① : 変数名の付け方
変数名が日本語のローマ字表記になっていますが、素直に英語にするか、逆に振り切って漢字仮名を使った日本語変数にしてしまった方がいいのではと思っています。日本語のローマ字表記は、同音異義語の問題もあるので英語や漢字仮名に比べて情報が欠落してしまっているので反対派です。何より読みづらい。
また、ローマ字化している日本語自体もだいぶ言葉足らず感があって気になります。例えば Touchaku = [0, 3, 4, 10, 11, 12] という定義をみても、背景を知らなかったら一体これが何の配列なのかさっぱりわかりません。
情報の授業をきっかけにプログラミングを始めようと思った人たちにこういう書き方でいいんだとは思ってほしくないなあという気持ちでした。
ただし、この擬似言語の書き方に関しては「共通テスト手順記述標準言語（DNCL）の説明」というガイドライン的な内容に準拠しているようで、ここに kosu_gokei の様な日本語のローマ字表記が使われている以上、試験問題を変えるならこのガイドライン自体から見直す必要がありそうで、なかなかすぐには直しづらい部分なのかもしれません。
それにしても kosu_gokeiは本当に分かりづらい…（「個数の合計」を指していると思われます）。
気になるポイント② : while文の使い方
個人的な意見になってしまうかもしれませんが、(taiken <= 15) and (saichou < 10)の間繰り返す: というwhile文相当の繰り返し処理が気になります。
このプログラムの目的は「taikenを1から15まで順にインクリメントしながらsaichouを調べ、それが10以上になれば処理を止めたい」というものです。
繰り返しの上限も決まっていますし、意味合い的にも taikenを1から15まで1ずつ増やしながら繰り返す: というfor文相当の書き方の方がしっくりきます。
また、現状は変数taikenを繰り返しのループ外でグローバルに定義していますが、for文にすれば変数スコープをループ内に収められます。
具体的には
taikenを1から15まで1ずつ増やしながら繰り返す:
| Kaishi = [0, 0, 0, 0, 0, 0]
| Shuryou = [0, 0, 0, 0, 0, 0]
| ...（略）...
| もし saichou >= 10 ならば:
|_ |_ 繰り返しを抜ける
のようにfor文で定義しつつ saichou >= 10ならbreakするという書き方にすることが考えられます。
あるいはC言語のfor文のように初期化・継続条件・更新を一箇所で宣言するような形で
taiken = 1 として (taiken <= 15) and (saichou < 10) の間 taiken を 1 ずつ増やしながら繰り返す:
| ...（略）...
|_
といった書き方も考えられそうです。
ただし、こちらも「共通テスト手順記述標準言語（DNCL）の説明」にはbreak文もC言語的なfor文も定義されていないため、ガイドラインに準拠するならこういった書き方はできません。
ということでこのガイドラインの範疇でやるならwhile文を使わざるを得ないということなのだと思われます。
気になるポイント③ : 実用性・必要性に乏しい。
来訪者がやってくる時刻などはあらかじめ配列としてプログラムにベタ書きしてあるため、問題にあるコードのままだと待ち時間を計算するために都度コードの配列を書き換えた上で実行までする必要があり、なんとも人力な運用になります。
また、時刻は開始時刻が0となっているので、書き換え時に現在時刻から開始時刻の引き算も人力でやる必要があります。
そもそも問題の例だと配列の要素数が少なすぎて手計算の方が早いという問題もあります。
これらを考えると、この作業を本当にプログラミングでやる意味があるのかが疑問です。スプレッドシートの方がいくらか使いやすそうです。
実際に文化祭において体験時間を表示させたいのであれば、訪問時にボタンを押すなりして訪問時刻をプログラムの入力として渡して自動的に実行する、みたいな作りになるかと思います。
せっかく文化祭というシチュエーションを設定しているのであれば、そういった運用面まで見越した作りにした方が意義のある問題な気がします。
さいごに
昨年解いた時にはあまり印象が良くなかった共通テストの情報Ⅰですが、かなり改善が見られた気がします。
まだ数年は問題傾向の変化が大きそうなので来年もまた解いてみたいと思います。