共通テストの「プログラミング問題」は、何を測っているのか——論理の重要性から位置づけを考える

2026年2月6日 19:45

はじめに——入試に「プログラミング」が入った、その先を問う

大学入学共通テストに「情報」が導入されて2年目となる2026年度も、プログラミングを題材にした問題が第3問として出題されました。高校の「情報I」で学んだ内容が入試で問われる——教育関係者や受験生の関心も高く、擬似言語（共通テスト用のプログラム表記）にどう慣れるか、という話題もよく聞きます。

一方で、世界の先端では少し違う動きがあります。スタンフォード大学のコンピューターサイエンス学科では、「コードを書く試験」をやめ、AIと自然言語で対話しながら開発する「Vibe Coding」や、チームでプロダクトを作るブートキャンプ形式へと教育の重点が移っている、という報道があります（スタンフォード大学で起きている「教育の激変」｜日経クロステック）。「プログラミング言語より英語（自然言語）が製品の質を決める」という指摘も、その文脈で語られています。

この二つを並べると、一見すると矛盾しているように見えるかもしれません。日本では「プログラミング的な思考」を入試で問い、海外のトップ校では「コードを書かせない」方向へ進む。けれども、「論理の重要性」という観点で整理し直すと、共通テストのプログラミング問題の「あり方」を、単なる受験対策の話ではなく、これからの教育で何を大切にするかという問いとして捉え直すことができます。本記事では、共通テストのプログラミング出題の実際を振り返りつつ、論理が「どこで」「どう」問われるべきかを、教育現場で考えやすい形でまとめます。

共通テスト「情報I」のプログラミング問題、いま何を測っているか

共通テストの「情報」では、高校で使うプログラミング言語が多様なことから、共通テスト専用のプログラム表記（擬似言語）が使われています（令和7年度大学入学共通テスト『情報I』の実施に向けて｜情報入試研究会、共通テスト【情報】出題範囲・対策アドバイス｜Z会）。特定の言語の文法を覚えているかではなく、「プログラムの流れや論理を読み解く力」を、言語に依存しない形で問うという設計です。

2026年度の第3問（プログラミング、25点・15マーク）では、文化祭で来訪者が体験できるゲームを題材に、待ち時間のシミュレーションと、その結果を踏まえたプログラムの改良までが一連の流れで問われました（【速報】大学入学共通テスト2026 情報Ⅰの分析｜高校生新聞、情報Ⅰ 2026年度大学入学共通テスト速報｜河合塾）。

問1では、図表から来訪者の到着時刻・開始時刻・終了時刻・待ち時間の関係を手作業で追う内容でした。ここで問われているのは「開始時刻は、直前の人の終了時刻と、自分の到着時刻のどちらか遅い方（最大値）になる」というアルゴリズムの理解です。問2では、そのアルゴリズムを擬似言語のプログラムに落とし込み、開始時刻・終了時刻・待ち時間を計算する部分の空欄を埋める形式でした。つまり「論理を読む」だけでなく、正しい処理（前任の終了と自分の到着の最大値→開始、開始＋体験時間→終了、開始－到着→待ち時間）をコード上のどこにどう書くかを選ばせる、論理の「読解」と「表現の選択」がセットになった出題でした。問3では、待ち時間が10分未満になる体験時間を調べるために、プログラムを改良する内容が問われ、「手作業で考え→プログラミングに落とし込み→コードを活用して課題を解決する」という三段階の流れがはっきりしていました（共通テスト2026年「情報」はどんな問題が出題されたのか？｜IT中小企業診断士・村上知也）。

プログラムの行数は10行と14行で、配列の添字は1から始まるなど、複雑さは中程度とされています。一方で、昨年よりマーク数が増え（51→60）、全体としてやや難化したとの分析もあり、状況やアルゴリズム、変数の役割の説明に沿って丁寧に考える力が求められたと言えます（情報Ⅰ 2026年度大学入学共通テスト速報｜河合塾）。

つまり、2026年度の共通テストのプログラミング問題が測っているのは、「特定のプログラミング言語の文法」ではなく、与えられた仕様や図表からアルゴリズムを理解し、それをプログラムの空欄にどう反映するか、さらに改良の方向性を考える力——言い換えれば、「論理を読む」「論理を正しい形でコードに置き換える」「そのコードを課題解決にどう使うか」という、読解から表現・活用までを含んだ論理力にかなり近いです。

「コードを読む」と「論理を組み立てる」——二種類の力

ここで、論理に関わる力を少し整理しておきましょう。

これまでのプログラミング教育では、次の二つがしばしばセットで語られてきました。

文法（構文）：変数の書き方、括弧の閉じ方、セミコロンの有無など、機械が解釈するための「正しい書き方」。
論理：順次・分岐・反復といった処理の流れ、条件の設定、データの扱い方など、「何をいつどうするか」の設計。

共通テストのプログラミング問題は、擬似言語という形で文法の差をならし、「読解」と「論理の追跡」に焦点を当てています。2026年度のように、問1で図表からアルゴリズムを理解し、問2でその論理をプログラムの空欄に「どの式・どの変数」で表現するかを選ばせる形は、「コードで表現された論理を読み解く力」加え、「理解した論理を、正しいコードの形で選ぶ力」まで少しだけ踏み込んだ出題と言えます。

一方で、世の中で言われる「論理的思考」には、もう一つのレベルがあります。それは、これから何を作るかを決め、そのための処理の流れや例外を自分で一から組み立てる力——要件を分解し、条件や境界（エッジケース）を考え、それを誰か（やAI）に伝えられる形で書く力です。前者を「論理を読む力（と、正しい表現を選ぶ力）」、後者を「論理を組み立てる力」と呼ぶと、共通テストのプログラミング問題は、現状では「読む力」と「与えられた論理をコードでどう表すかの選択」を中心に問い、「目的から自分でアルゴリズムを設計する」ところまでは時間・形式の制約で問いにくい、と整理できます。どちらも大事ですが、「組み立てる力」を入試でどこまで問うかは、今後の検討課題になっていくでしょう。

スタンフォードの向こう側：論理は「どこ」で問われるようになるか

スタンフォードの事例で言われているのは、「コードを書くこと」の価値が相対的に下がり、「AIと自然言語で対話してモノを作る能力」が前面に出てきているという変化です。ただし、そこで不要になるのは主に「機械向けの構文を正確に書くこと」であり、「何を作るか（目的）」「どう動くべきか（処理の流れ・例外）」を決め、AIに伝え、出てきた結果を検証する力は、むしろ重要性が増している、という指摘があります。

つまり、論理そのものが不要になるのではなく、論理が「発揮される場所」が変わるという見方ができます。

これまで：人間が細かい手順までコードに落とし、構文エラーと格闘しながら論理を形にする。
これから：人間は「何をさせたいか」「どんな条件で分岐させるか」「どんな例外を考慮するか」を言葉や設計図（擬似コード・仕様）で示し、AIがコードを生成する。人間はその結果が論理的に正しいかを検証する。

このとき、「コードは書けなくても、コードがやっている処理の流れ（ロジック）は読める」という能力は、AIが書いたコードや提案を評価するうえで、最低限のリテラシーとして残ります。共通テストのプログラミング問題が「プログラムの流れを読み解く」ことに重きを置いているのは、この「読む力」を育てる・測るという意味で、AI時代の論理リテラシーと方向性が重なる部分があると言えます。

共通テストのあり方を、論理という観点から振り返る

では、共通テストのプログラミング問題の「あり方」を、論理の重要性という観点から振り返ると、どう整理できるでしょうか。

現状の良い点として、次のようなことが挙げられます。

言語に依存しない擬似言語により、「特定言語の文法」ではなく論理の読解が問われている。
穴埋めや読解中心であり、「一から正しいコードを書く」ことより、既にある論理を追い、正しい選択や結果を選ぶ力が評価されている。
2026年度のように、問1でアルゴリズムを理解し、問2でプログラムに落とし込み、問3でプログラムを改良して課題を解決するという「読解→表現→活用」の流れが一つの大問で問われる構成も出てきている。
試作問題や分析でも、文脈の読み取りと論理的な思考が繰り返し強調されている。

今後、議論の対象にし得る点としては、例えば次のようなものがあります。

「論理を組み立てる」力——仕様や目的から自分で処理の流れや条件を考え、擬似コードや日本語の設計図にまとめる——を、時間や形式の制約のなかでどこまで問うか。
例外・エッジケースをどれだけ意識させるか。AIは「通常ルート」は得意でも異常系を見落としがちなので、「想定外にどう備えるか」を考える力は、実務でも教育でも重要度が増している。
「読んだ結果が正しいか」を検証する——トレースやテストケースの選択——といった、検証の論理を問う設問の余地。

いずれにせよ、「プログラミングの位置づけ」を「構文を覚えること」から「論理を読み、必要なら組み立て、検証すること」へとシフトして考えると、共通テストのプログラミング問題は、「論理を扱う一つの窓口」として意義を持ち続け、かつ今後の出題の改良を議論するときの軸にもなり得ます。

教室でできること——設計図と検証を授業に

共通テストの出題形式そのものは、現場で変えることはできません。けれども、日々の授業のなかで「論理を読む」だけでなく「論理を組み立てる」「検証する」経験を増やすことは、多くの学校で可能です。

例えば、次のような工夫が考えられます。

擬似コードや日本語の設計図を書かせる
「文化祭のチケットで、在庫が0のとき・残高が足りないときはどうするか」といった条件や処理の流れを、まず日本語や簡易な擬似コードで書かせ、そのあとで実際のコードやAIに渡す。共通テストの「読解」とセットで、「組み立て」の練習になります。
AIにコードを生成させ、その正しさを検証させる
「この仕様で動くプログラムを書いて」とAIに依頼し、出てきたコードが仕様通りか、境界値でおかしくなっていないかを、生徒自身に確認させる。「論理を読む力」と「検証する態度」の両方を育てます。
例外処理・エッジケースを話し合わせる
「通信が切れたらどうする？」「二重に押されたら？」といった問いを授業で扱う。共通テストで直接問われていなくても「想定外を考える論理」は、AI時代の設計者として大切な力です（「AIに使われる側」から「設計する側」へ——生徒を導くとき、教師が考えるべきことでも、設計者に必要な力の一つとして触れています）。

こうした授業は、共通テストのプログラミング問題の「読解」対策とも両立しつつ、「入試の先」にある、論理を組み立て・検証する力につなげる役割を果たします。

まとめ——プログラミングの位置づけは「論理を扱う窓口」に

共通テストにプログラミングを題材にした問題が入ったことで、「何を覚えるか」だけでなく、「何を読解し、何を問うているか」を意識する機会が増えています。現状の出題は、擬似言語による「論理の読解」に重心があり、それはAI時代に必要な「AIの出力を論理的に検証する力」とも接続しています。

一方で、論理には「読む」だけでなく「組み立てる」「検証する」という側面があり、スタンフォードのような「自然言語でAIと対話して作る」世界では、むしろそちらの比重が高まっています。共通テストのプログラミング問題のあり方を振り返るとは、「文法の暗記」を減らし、「論理を読み、組み立て、検証する」教育と入試をどうデザインするかを、いま一度問い直すことでもあります。

プログラミングの位置づけを、「特別な言語を覚えること」から「論理を扱う窓口」に移していく。共通テストはその一里塚として機能しつつ、今後も「何を測るか」「どう問うか」が議論されていくテーマとして、教育関係者や受験生と一緒に考え続けていく価値があると思います。