「もうプログラミングスキルは不要」勢へ

恐らくそれは「プログラミングスキル」ではないです。
いや単に「プログラミングスキル」という言葉の定義の問題かもしれない。

実際多くの人はPythonの文法、JavaScriptのフレームワーク、SQLのクエリ構文——つまり特定言語に関する文法知識をイメージするんじゃないかと思います。
それ故、コーディングエージェント全盛時代に、文法知識の重要性が相対的に下がる・・・これはその通りかと思います。

じゃあ「プログラミングスキルはもう要らない」のか？
それは完全に誤りです。

自然言語でAIに指示する場合であっても、プログラミング的な思考能力がなければ正しい指示はできません。つまり、自然言語であってもプログラム であり、書き手には「プログラミングスキル」が要ると考えています。

ここでいう「プログラミングスキル」は文法知識ではありません。計算論的思考（Computational Thinking）を始めとした各種スキルです。
「AI時代に必要な開発スキル」と言い換えてもいいかもしれませんね。

本記事では、私自身のメモとして「AI時代のプログラミング教育」また「AI時代に必要なスキル」として調査した内容を
(なるべく)お気持ち記事にはならないことを心がけ、学術研究や各種記事を元に記載していきます。

3行で

「プログラミングスキル不要」論で言われているのは文法知識の話であり、計算論的思考（Computational Thinking）は依然として必要
自然言語でAIに指示する行為もプログラミングであり、問題の分解・抽象化・パターン認識・手順設計といった思考力が求められる
AIに丸投げするとスキルが育たない。AIを「思考のパートナー」として使い、能動的に関与することが重要

「自然言語は最もホットなプログラミング言語」

2023年、OpenAI創設メンバーの一人であるAndrej Karpathyがこんな発言をしました。

The hottest new programming language is English
（最もホットな新しいプログラミング言語は英語だ）

この発言は「もうプログラミングを学ぶ必要はない」という文脈で引用されることがあります。
しかし本来の意味は逆です。自然言語がプログラミング言語として機能するようになったということであり、自然言語を使う側にもプログラミング的な思考が求められるということです。

Schmidt & Runfola (2025) は論文 "Liberating Logic in the Age of AI" の中で、この変化を学術的に裏付けています。

What matters is no longer just fluency in traditional programming languages but the ability to think computationally by translating problems into forms that can be solved with computing tools.

（重要なのは従来のプログラミング言語の流暢さだけではなく、問題をコンピューティングツールで解ける形に変換する計算論的思考の能力である）¹

さらに同論文では、プロンプトエンジニアリングの本質をこう表現しています。

Prompt engineering came to be understood as programming through the AI, rather than programming the AI.

（プロンプトエンジニアリングは、AIをプログラミングするのではなく、AIを通してプログラミングすることだと理解されるようになった）

「プロンプトエンジニアリング」という言葉についての捉え方も個人的にはちょっと思うことがあるのですが、これは別記事で述べたいと思います。

要は自然言語で指示しているように見えても、やっていることの本質はプログラミングなんですよ、といった内容です。

Computational Thinking（計算論的思考）とは

では、文法知識ではない「プログラミングスキル」って具体的に何なのか。
その答えの一端が計算論的思考（Computational Thinking, 以下CT） です。

BBC Bitesizeの定義によると、CTには4つの柱があります²。

出典²

柱	内容
Decomposition（分解）	複雑な問題をより小さく扱いやすい部分に分解する
Pattern Recognition（パターン認識）	問題の中や問題間の類似性を見つける
Abstraction（抽象化）	重要な情報にのみ注目し、無関係な詳細を無視する
Algorithms（アルゴリズム設計）	問題を解くためのステップバイステップの手順を設計する

CTは「問題をコンピュータで解ける形に変換する思考法」であり、特定のプログラミング言語とは独立した能力です。そしてこれは、AIに指示を出す際にもそのまま適用されます。

AIコーディングにおけるCTの必要性

CTの4つの柱が、AIコーディングでどう必要になるか具体例で見てみましょう。

Decomposition（分解）

AIに「ECサイトを作って」と一括で指示するのと、以下のように分解するのとでは、結果の品質が全然違います。

1. 商品データのスキーマを設計する
2. 商品一覧APIのエンドポイントを作成する
3. カート機能のステート管理を実装する
4. 決済フローのバリデーションを実装する

大きな問題を適切な粒度に分解する能力は、AIに対しても人間のチームメンバーに対しても同じように必要です。分解が適切でなければ、AIは曖昧な指示を「なんとなく」解釈して、意図しないものを返してきます。

また、Decompositionにあたっては要件仕様(ユーザー側の仕様)から機能仕様(実装側の仕様)に落とし込むにあたって実現方法は様々あり、その選定をAIに丸投げするのではなく人間がチェック・フィードバックするには外側の知識も問われます。
分解するためにはどのような分解要素があるのか、という設計知識と理解も必要になります。

トークン限界 / コンテキスト圧縮への対応

上記の観点以外にも個人的にはDecompositionスキルは現時点のコーディングエージェントの能力では一番問われる能力だと考えます。

というのは現時点のコーディングエージェント及び生成AIのリソース能力では、トークンの限界により
ちょっと大きめのプログラミングにおいてはコンテキスト圧縮が必ずと言っていいほど発生するかと思います。
その際当然、プログラミングにおいては発生してはいけない「細かいニュアンスが抜ける」ことになるのでバグの温床や、デグレの原因となります。

Decompositionによるモジュール化能力により、会話の際にスレッド分割したいあるいはそうでなくても保守性を高めた設計により
文脈が各モジュール毎に完結するのでコンテキスト圧縮時のバグ/デグレを防止できていると感じます。
(これはエビデンスなしのお気持ち)

Abstraction（抽象化）

プロンプトの抽象度は、低すぎても高すぎても問題が起きます。

抽象度が低すぎる：実装の細部を逐一指定 → AIの強みを活かせない
抽象度が高すぎる：「いい感じに作って」→ 意図と全然違うものが出てくる

「認証が必要で、JWTトークンを使い、リフレッシュトークンの有効期限は7日間」のように、本質的な要件だけを適切な粒度で伝える能力が求められます。これは抽象化そのものです。

こちらはAbstractionスキルだけでなくバックグランドとなる知識も問われるかもしれませんね。

Pattern Recognition（パターン認識）

あるAPIエンドポイントの実装で発生した問題と、別のエンドポイントで発生した問題の共通構造を見抜く。CRUD操作に共通するパターンを認識して、過去の類似問題がどう解決されたかを踏まえて効率的な解法を導く。。。。とか

問題間の類似性を見抜く能力は、効率的なAI活用の土台になります。

類似性を見抜く能力といっても自分の中で「引き出し」がないと、自分の中のインデックス不足であまり効果を発揮しないと思います。

やはりシニアエンジニアは暗黙的に「あ、これ進●ゼミでやったところだ！」が発動しまくってるものだと考えます。
となるためにも、「引き出し」を増やしたうえで同時に引き出し内の類似検索能力を身に着けることが必要と思います。

Algorithms（アルゴリズム設計）

「まずデータベースのマイグレーションを実行して、次にシードデータを投入して、その後APIのエンドポイントをテストする」——この依存関係や順序の設計が間違っていれば、各ステップが正しくてもシステム全体は動きません。

AIが個々のパーツを生成できたとしても、それらを正しい順序で組み合わせる設計はCTの領域です。
また、そもそも各パーツにおける概念を理解していないと指示をすることもできません。

もちろんプロトコル、必ず行う流れや一般的な流れであればこの辺の指示が抜けても補完はやってくれます。
ただしUI動作や仕様動作等のプロダクトにおける制御について、ここを完全にAIに任せると
人間の価値観を基づき差別化を果たしたプロダクトを作成することはできず、「AIの最尤な価値観（≒よくある価値観）」に基づいたプロダクトになります。

Sarah Chasins教授の見解：構造化する能力

UCバークレーでコンピュータサイエンスの教授を務めるSarah ChasinsはYouTube講演³で、AIツールを使う場合でも構造化（structuring）する能力が不可欠であることが強調されています。

Chasinsの研究室（PLAIT Lab）が開発しているツール群は、この思想を体現しています。例えば実験生物学者向けのプログラム生成ツールHoneybeeでは、ユーザーは（i）実験で何をしたか、（ii）どんなデータが生成されたか、（iii）どんな分析・可視化が欲しいかを構造化して記述する必要があります。AIがコードを生成するとはいえ、問題を構造化する能力はユーザー側に求められるわけです⁴。

また、Jayagopal, Lubin, & Chasins (2022) は、AI/プログラム合成ツールの初心者にとっての学習可能性を研究しました。この研究は、AIツールが存在してもユーザーが基本的なプログラミング思考を必要とすることを示しています⁵。

Chasinsの研究ミッションは

To make programming a path to a more informed and evidence-driven society — not just a way to get wrong answers faster.

（プログラミングを、より情報に基づいた証拠駆動の社会への道にする——誤った答えをより速く得るための手段にするのではなく）⁴

AIを使って「誤った答えをより速く得る」人と、AIを活用して正しい解に到達できる人。

この差を生むのが、CTの有無だと個人的にも感じています。

エビデンス①：AI利用がスキル形成を阻害する（Anthropic研究）

ここからはエビデンスを4つ紹介していきます。

Shen & Tamkin (2026) はAnthropicの研究として、52名の（主にジュニアの）ソフトウェアエンジニアを対象にランダム化比較試験（RCT）を実施しています⁶。

参加者はPythonの非同期処理ライブラリ「Trio」を用いたコーディングタスクを与えられ、AI支援あり群となし群に分けられました。タスク完了後にマスタリークイズが実施されています。

結果

指標	AI支援あり群	AI支援なし群
クイズ平均スコア	50%	67%
タスク完了時間	約2分速い（有意差なし）	—

AI群はマスタリークイズで17%低いスコア（Cohen's d=0.738, p=0.01）。これは約2段階分の成績差に相当します。特にデバッグに関する問題での差が最大で、AIが生成したコードの間違いを発見・修正する能力——まさにAI時代に最も重要なスキル——が最も損なわれていました。

AI利用の6つのパターン

この研究で特に面白いのが、AI利用パターンの質的分析です。

低スコアのパターン（認知的オフローディング）：

パターン	行動	平均クイズスコア
AI Delegation	AIにすべてを丸投げ。最速で完了	40%未満
Progressive AI Reliance	最初は自分で書くが、徐々にAIに依存	40%未満
Iterative AI Debugging	自分でコードを書くが、デバッグはAIに任せる	40%未満

高スコアのパターン（能動的関与）：

パターン	行動	平均クイズスコア
Generation-then-comprehension	AIにコードを生成させた後、「なぜこうなるか」をAIに質問	65%以上
Hybrid code-explanation	コード生成と説明を同時に要求し、説明を読んで理解	65%以上
Conceptual inquiry	概念的な質問のみをAIに聞き、コードは自分で書く	65%以上

論文の結論はかなり明確です。

Productivity benefits may come at the cost of skills necessary to validate AI-written code if junior engineers' skill development has been stunted by using AI in the first place.

（生産性の恩恵は、ジュニアエンジニアがAI使用によりスキル発達を阻害された場合、AIが書いたコードを検証するために必要なスキルの犠牲の上に成り立つ可能性がある）

要するに「速くはなるけど、身につかない」ということですね。
こちらの研究は文法理解能力にフォーカスが当たっていますが、前述のCT等の抽象化スキルの観点の研究も気になるところです。

エビデンス②：認知的アウトソーシングの危険性

ミシガン大学のMark Guzdial教授はコンピューティング教育研究の第一人者です。2026年2月のブログ記事で、GenAIと認知の関係を自動車の比喩で説明しています⁷。

GenAI is not cognitive offloading. It's outsourcing. We don't think about how to do the tasks that we ask GenAI to do.

（GenAIは認知的オフローディングではない。アウトソーシングだ。我々はGenAIに頼む作業のやり方について考えない）

この比喩がすごくわかりやすいんですが、GuzdialはかつてのAppleの広告を引き合いに出します。

Some of you may remember the Apple ads that emphasized the computer as a "bicycle for the mind."

（コンピュータを「知性の自転車」と表現したAppleの広告を覚えている方もいるだろう）

自転車は人間の身体能力を拡張する——脚を使って漕ぐことで、より遠くに行ける。しかしGenAIは自転車ではなく自動車だと。自動車は確かに行動範囲を広げますが、人間の身体を使わない。

結果として、自動車社会では身体が退化しますよね。GenAIも同様に、思考を使わないまま成果を得られてしまうので、能力が萎縮するリスクがあるわけです。

Guzdialの処方箋は「運動」です。

We will have to figure out that we need to exercise our minds, even if GenAI could do it easier, faster, and in some cases, better.

（GenAIの方が簡単で速く、場合によってはより良くできるとしても、我々は自分の知性を鍛える必要があることを理解しなければならない）

エビデンス③：文法知識と計算論的思考は別物

ライデン大学のFelienne Hermansは、著書 "The Programmer's Brain" (2021) の中でプログラマーの認知プロセスを詳細に分析しています⁸。

この研究の重要な知見は、文法の暗記（syntax knowledge）と、認知的プロセス（チャンキング、メンタルモデル構築、パターン認識）は全く別の能力だという点です。

ここが個人的に非常に重要なポイントだと思っていて、Hermansはさらに教育用プログラミング言語 Hedy の研究を通じて、文法の障壁とCTの障壁は分離可能であることを実証しました⁹。Hedyは文法を段階的に導入することで文法の障壁を下げるのですが、CTの課題は別途残り続けます。

この知見をAI時代に当てはめると、こういうことが言えます。

AIは文法の障壁を事実上ゼロにした。しかしCTの障壁はそのまま残っている。

Pythonのfor文の書き方を知らなくても、AIが書いてくれます。しかし「何をループすべきか」「なぜループが必要なのか」を判断する能力はAIでは代替できません。

エビデンス④：プロンプトエンジニアリングはCTである

Hsu (2025) は論文 "From Programming to Prompting" の中で、プロンプトエンジニアリングとCTの対応関係を明確に示しました¹⁰。

CTの要素	プロンプトエンジニアリングでの対応
Decomposition	複雑なタスクを複数のプロンプトに分解する
Abstraction	本質的な要件を抽出し、適切な抽象度で記述する
Pattern Recognition	効果的なプロンプトパターンを認識し再利用する
Algorithms	プロンプトの実行順序や条件分岐を設計する

Schmidt & Runfola (2025) も同様に、プロンプトエンジニアリングには論理、抽象化、分解、パターン認識——つまりCTの4つの柱すべてが必要であることを論じています¹。

こうやって並べてみると、プログラミング言語がPythonから自然言語に変わっても、必要な思考能力は変わっていないことがよくわかります。

実践：AIと協働する際のベストプラクティス

ここまでエビデンスを並べてきましたが、「じゃあ具体的にどうすればいいの？」という話をします。前述のAnthropic研究が示した6つのパターンが、そのまま実践ガイドとして使えます。

やってはいけないパターン

1. AI Delegation（丸投げ）

「この機能を実装して」→ 生成されたコードをそのまま採用

タスク完了は最速ですが、スキルの獲得はゼロ。問題が起きたときに自力で対処できなくなります。

2. Progressive AI Reliance（徐々に依存）

最初は自分で考えるんですが、行き詰まるとAIに任せるようになり、徐々に依存度が上がっていくパターンです。特に長時間のコーディングセッションで陥りやすいので注意してください。

3. Iterative AI Debugging（デバッグの委託）

自分でコードを書くけど、エラーが出るたびにAIにデバッグを依頼するパターンです。一見効率的に見えますが、デバッグ思考——AI時代に最も重要なスキルの一つ——が育ちません。

効果的なパターン

1. Generation-then-comprehension（生成→理解）

「この関数を実装して」→ 生成後に「このコードがなぜこのアプローチを取っているか説明して」

コードを生成させた後に、理解を確認するフォローアップ質問をするやり方です。

2. Hybrid code-explanation（コード＋説明の同時要求）

「この関数を実装して。各ステップの判断理由もコメントで説明して」

コード生成と説明を同時に要求して、生成物を理解しながら進めます。

3. Conceptual inquiry（概念的質問）

「Trio の Nursery パターンはどういう場面で使うべき？」→ 理解した上で自分でコードを書く

AIには概念の理解を助けてもらい、コードは自分で書くパターンです。エラーに直面して自力で解決する過程が最も学びにつながります。Anthropic研究でも、このパターンが高スコア群の中で最速でした。

AI時代に必要なスキルセット

ここまでのエビデンスを総合すると、AI時代に必要な「プログラミングスキル」は以下の6つに集約されると考えています。

CTの4つの柱

スキル	AI時代における意味
Decomposition（分解）	問題を適切な粒度のタスクに分解し、AIへの指示単位を設計する
Abstraction（抽象化）	本質的な要件を抽出し、適切な抽象度で仕様を記述する
Pattern Recognition（パターン認識）	効果的な解法パターンを認識し、新しい問題に応用する
Algorithms（アルゴリズム設計）	処理の順序、依存関係、条件分岐を設計する

＋2つの追加スキル

スキル	内容
検証能力	AI出力が仕様・期待と合致するかを確認する能力。テスト設計、動作確認、仕様との照合など。コードを逐一読む能力ではなく、正しさを何らかの方法で検証できる能力
デバッグ思考	期待と実際の差分を特定し、原因を切り分ける思考。コードレベルに限らず、仕様レベル・設計レベルでも機能する汎用的な問題解決能力

ここで「コードリーディング」を意図的に含めていません。かつてアセンブリを書ける人がほぼいなくなったのと同じように、AIが生成したコードを逐一読むことは、抽象化の歴史の中で下位レイヤの概念になっていくと考えているからです。重要なのはコードを読めることではなく、結果を検証できることです。

教育はどう変わるか

Becker et al. (2023) のSIGCSE論文は、AIコード生成ツールの登場によってプログラミングの「難しさ」が消えるのではなく形が変わることを論じています¹¹。文法エラーとの格闘は減りますが、問題の分解、設計の妥当性判断、出力の検証といったCT的な難しさが前面に出てきます。

Porter & Zingaro (2024) はAI前提のPython教科書 "Learn AI-Assisted Python Programming" も、問題分解とプロンプト設計を必要スキルとして位置づけています¹²。

日本の文脈

日本では2020年から小学校でプログラミング教育が必修化されて、文部科学省は「プログラミング的思考」という用語を使っています。この「プログラミング的思考」は、実はCTにかなり近い概念です。

しかし現場の実態としては、Scratchなどのツール操作の習得に偏っていて、思考力そのものの育成には必ずしも至っていないという課題があります。「ブロックを並べてキャラクターを動かす」ことと、「問題を分解し、抽象化し、手順を設計する」ことは別物ですよね。

AI時代こそ、文科省が本来意図した「プログラミング的思考」——つまりCT——の育成が重要になると考えています。なぜならAIが文法の障壁を取り除いた今、残るのは思考の障壁だけだからです。

はっきり言って「授業に(一律)生成AIを使わないべきだ」という議論自体がこの「思考能力習得」と「知識習得」を区別できていないで議論していることがほとんどで、上記のように文部省の言うところの「プログラミング的思考」が現場で「プログラムの手順」になってしまっているのがこの議論をややこしくしていると感じます。
「プログラムの手順」をクライテリアにしたらそりゃ生成AI使ったら意味ないですよね。

結論としては「教育がAI社会に追い付いていない」という形ですが、
とはいえ、ここら辺を身に着けた「"知識"を教えるだけではない」「PBL等を通じて思考能力を指導できる」教育者が果たして何割いるでしょうか？1割切るのでは？
これは全国の教師が悪いわけではなく、国が悪いわけでもなく、ただただ環境変化のスピードに追い付いていないものだと考えます。

結論：プログラミングの本質は変わらない

プログラミング言語の歴史は、抽象化の歴史です。

低水準言語　マシン語 → アセンブリ → C → Java, C++ → C#, Python → 自然言語　高水準言語

各段階で下位レイヤは不可視になりました。アセンブリプログラマーがレジスタ操作を意識していたように、C言語プログラマーはメモリ管理を意識していた。しかし今、多くのエンジニアはそれらを意識しません。同様に、AI時代には個々のコード行を意識する必要性も薄れていくでしょう。
(もちろん現時点でも組込エンジニア等がそれらを必要としているのと同様、引き続きプログラム言語を意識する必要のあるエンジニアもいるでしょう。)

しかし、どの段階でも変わらなかったものがあります。それは「構造化された指示を組み立てる能力」——すなわちComputational Thinkingです。

問題を分解し、パターンを認識し、本質を抽象化し、手順を設計する。この能力なくして、どんなに高性能なAIツールがあっても正しい結果は得られません。

AIコーディング時代の「プログラミングスキル」とは、特定言語の文法知識ではありません。計算論的思考という、時代を超えて変わらない本質的な能力のことです。

参考文献

Schmidt, D.C. & Runfola, D. (2025). Liberating Logic in the Age of AI: Going Beyond Programming with Computational Thinking. arXiv:2511.17696. https://arxiv.org/abs/2511.17696 ↩ ↩²
BBC Bitesize. Introduction to computational thinking. https://www.bbc.co.uk/bitesize/guides/zp92mp3/revision/1 ↩ ↩²
Chasins, S.E. YouTube講演. https://www.youtube.com/watch?v=AFu7jzI0ExY ↩
Chasins, S.E. Research Mission. https://schasins.com/ ↩ ↩²
Jayagopal, D., Lubin, J., & Chasins, S.E. (2022). Exploring the Learnability of Program Synthesizers by Novice Programmers. ACM UIST 2022. https://dl.acm.org/doi/abs/10.1145/3526113.3545659 ↩
Shen, J.H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245. https://www.anthropic.com/research/AI-assistance-coding-skills ↩
Guzdial, M. (2026). GenAI as automobile for the mind, and exercise as the antidote. Computing Ed Research Blog. https://computinged.wordpress.com/2026/02/16/genai-as-automobile-for-the-mind-and-exercise-as-the-antidote-a-metaphor-for-predicting-genais-impact/ ↩
Hermans, F. (2021). The Programmer's Brain. Manning Publications. ↩
Hermans, F. (2020). Hedy: A Gradual Language for Programming Education. ACM ICER 2020. https://dl.acm.org/doi/abs/10.1145/3372782.3406262 ↩
Hsu, H.P. (2025). From Programming to Prompting: Developing Computational Thinking through Large Language Model-Based Generative Artificial Intelligence. TechTrends. https://link.springer.com/article/10.1007/s11528-025-01052-6 ↩
Becker, B.A. et al. (2023). Programming is Hard — Or At Least It Used to Be. SIGCSE 2023. https://dl.acm.org/doi/abs/10.1145/3545945.3569759 ↩
Porter, L. & Zingaro, D. (2024). Learn AI-Assisted Python Programming: With GitHub Copilot and ChatGPT. Manning Publications. ↩