次世代のプログラミング言語とは？

AIによって、プログラマーが淘汰されようかという今になって「次世代のプログラミング言語とは何を言っているのか？」と返されそうですが、今とあるプロジェクトをやっておりまして（具体的なことは控えます）、AI時代に必要なプログラミング言語についてより意識するようになってきました。

■ 現在のAIプログラミングの構造

今までのプログラミングとは「人間からコンピューターへの指示」ということでした。ではAI時代になると何が変わるのでしょうか。

現状、AIを使ったプログラミングは次のような形になります。

人間 → [自然言語（プロンプト）] → AI → [プログラム] → コンピュータ

---

■ 次世代言語という発想

これについてまず考えられるのは、次のような形です。

人間 → [次世代言語] → AI → [プログラム] → コンピュータ

つまり、人間とAIの間に共通言語を持てないか、という発想です。

さらにいうと、

人間 → [次世代言語] → AI → [次世代言語] → コンピュータ

ここまで踏み込めれば、AIが生成した内容も（原理的に）人間が確認可能になります。
つまり、問題が発生したときに「何が意図されていたのか」を追跡できるようになります。

---

■ 想定される批判

ここで当然、次のような批判が出てきます。

人間 → [次世代言語] → AI
AI → [次世代言語] → コンピュータ

同じ言語を使うのであれば、AIは人間が入力した内容をそのまま返すだけではないか、というものです。

実際に、そういうことは起こり得るでしょう。

---

■ それでも何が便利なのか？

ポイントは、人間・AI・コンピュータの間で共通言語を持つこと自体にあります。

自然言語ではなく、このような言語を想定する理由は以下のとおりです。

• 表現にムラがなく、曖昧性を排除できる
• 最終的に機械で実現可能な形に落とし込める

一方で、従来のプログラミング言語との違いは、

• 人間が理解可能な抽象度を保つこと

にあると考えています。

---

■ 実は新しくない発想

このアイデアは一見すると突飛に見えるかもしれませんが、実は全く新しいものではありません。

第5世代コンピュータで目指されていた、論理型言語の思想に近いものです。

論理型言語の代表格であるPrologは、当時日本でも注目されました。
また、このブログでたびたび触れているADPも、Prologをベースとしています。

また、Grokに言わせるとLLMとPrologをつなぐアイデアは既に研究対象となっているようです。AIに聞けば多数出てくるようです。下記面白そうなもの2点をピックアップします。

・Arithmetic Reasoning with LLM: Prolog Generation & Execution
LLMが自然言語の算術問題からPrologの述語・ルールを生成し、Prologインタプリタで実行。CoT（Chain-of-Thought）より精度が大幅に向上した実験。

・LLM and Prolog: the logical alternative to chain-of-thought reasoning (Medium, 2025)
金融領域での実践例。LLMが自然言語からPrologルールを抽出し、シンボリック推論エンジンで処理。非常に読みやすい解説。

そりゃPrologを知っている人なら絶対に考えるよなという話ですね。

---

■ 宣言的という考え方

Prologのような言語は「宣言的」と呼ばれます。

つまり、

• 「何を作るのか？」にフォーカスする
• 「どう作るのか？」は実行系に委ねる

という考え方です。

現在のAIによるコーディングもこれに近く、人間が「何を作るのか」をプロンプトで与え、「どう作るか」はAIが担っています。

---

■ 批判への一つの答え

この役割分担を前提とすると、

「AIは入力をそのまま返すだけではないか」

という批判にも、ある程度対応できます。

もう少し踏み込んだイメージとしては、

• 人間は「満たすべき条件」（述語）を定義する
• AIはその実装（述語の本体）を生成する

という形です。

ここでいう「述語」は論理型言語の用語で、「関数」に近い概念です。

処理手順ではなく「満たすべき条件」を中心に表現することで、結果の妥当性を人間が確認しやすくなります。

---

■ 現実的な課題

とはいえ、このような構想は「言うは簡単で実現は難しい」ものです。第5世代コンピュータプロジェクト自体が頓挫した経緯もあり、AIを使えば当時の問題は解決できるのか？という問いは依然として残ります。

具体的には、

・人間に読みやすいと言ってもPrologはコンピュータよりの言語である。
・宣言的といっても、それだけですべてが上手くいくわけではない。Prolog自体が流行っていない。
・現実案としては、コメントがAIに対する補足（プロンプト）になるが、そうすると自然言語が残ることになる。

というジレンマがあります。特に「宣言的プログラミング」とは当時一瞬流行ったパラダイムになりますが、純粋さを追求すると却ってコードを分かりにくくする側面があります。またAIの出力は手続き的にもなりえます。このあたりの折り合いをどうつけるのかというのが課題かと思います。

このような「純粋な理論」と「現実の泥臭さ」の板挟みを解決するために、私は一つのアプローチをとっています。例えば、ADPは、Prologをベースにマルチパラダイムを追求しています。つまり純粋な宣言的なパラダイムを捨てて、手続き的にも書けるようにしています。このあたりの落としどころが現実的ではあるかと思います。

---

■ 最後に

もっとも、私自身も30年ほど前にこうしたアイデアの断片を考えたことがあります。

さらにいうと、ADPの機能として次世代言語に必要な要件を備えることができれば、ADPそのものが次世代言語になり得るのではないか、とも思っています。

夢は広がりますが、まずは時間を見つけて少しずつ形にしていきたいところです。

What Is a Next-Generation Programming Language?

■ The Structure of AI-Assisted Programming Today

Traditionally, programming languages have been a way for humans to instruct computers. So what changes in the AI era?

Today, AI-assisted programming typically looks like this:

Human → [Natural Language (Prompt)] → AI → [Program] → Computer

---

■ The Idea of a Next-Generation Language

From here, one natural idea is:

Human → [Next-Generation Language] → AI → [Program] → Computer

In other words, can we introduce a shared language between humans and AI?

Taking this a step further:

Human → [Next-Generation Language] → AI → [Next-Generation Language] → Computer

If this were possible, then—even in principle—humans could verify what the AI produces.
When problems occur, we could trace and understand the original intent behind the system.

---

■ Expected Criticism

At this point, a natural criticism arises:

Human → [Next-Generation Language] → AI  
AI → [Next-Generation Language] → Computer

If the same language is used on both sides, wouldn’t AI simply return what the human provided?

In fact, this can certainly happen.

---

■ So What’s the Benefit?

The key point is the value of having a shared language across humans, AI, and computers.

Why not just use natural language?

• It introduces inconsistency and ambiguity
• It is not directly executable by machines

A next-generation language would instead aim to:

• Eliminate ambiguity
• Be directly translatable into executable form

And compared to traditional programming languages, the key difference would be:

• It maintains a level of abstraction that humans can understand

---

■ Not Actually a New Idea

This idea may sound radical, but it is not entirely new.

It is closely related to the concepts explored in logic programming languages during the Fifth Generation Computer era.

For example, Prolog—one of the most well-known logic programming languages—was once widely discussed in Japan.
The language I’ve mentioned occasionally in this blog, ADP, is also based on Prolog.

---

■ The Declarative Approach

Languages like Prolog are often described as declarative.

That means:

• Focus on what should be done
• Leave how to do it to the execution system

Interestingly, modern AI-assisted coding follows a similar pattern:
humans specify what they want, and AI handles how to implement it.

---

■ A Possible Answer to the Criticism

If we properly recognize this division of roles, we can respond to the earlier criticism that “AI would just return the input as-is.”

A more concrete idea would be:

• Humans define conditions—what must be satisfied (predicates)
• AI generates the implementation (the body of those predicates)

Here, a “predicate” is a concept from logic programming, somewhat similar to a function.

Instead of describing step-by-step procedures, we describe conditions to be satisfied.
This makes it easier for humans to verify whether the result is correct.

---

■ Practical Challenges

Of course, this kind of idea is much easier said than done.
The Fifth Generation Computer project itself failed, which raises the question:

Can AI solve the challenges that existed back then?

More concretely, several dilemmas remain:

• Even if we aim for human readability, Prolog is still closer to a machine-oriented language
• Declarative approaches alone do not solve everything—Prolog itself never became mainstream
• In practice, comments may act as prompts for AI, which means natural language still remains in the system

This creates a fundamental tension.

Declarative programming was once a briefly popular paradigm, but pushing it too far can make systems impractical.
At the same time, AI-generated output can also be procedural.

How to balance these aspects remains an open challenge.

---

■ Final Thoughts

That said, I personally had fragments of this idea over 30 years ago.

And if the language I’m developing—ADP—can incorporate the necessary characteristics of such a next-generation language, it might itself become one.

It’s an ambitious thought, but for now, I’ll continue working on it little by little, whenever time allows.

llama.cppの開発＆最適化、環境構築

老兵は死なず、AIと踊る

　私のAI体験、2026年2月の活動、ということで、我がAIマシン（Core i9-10980XE,メモリ256GB＋GeForce GTX1080Ti、GeForce RTX3070）にllama.cppの環境構築を行ったので、そのメモになります。

（事前セットアップ）

• OSのセットアップ、各種ドライバーをインストール
• Cuda toolkitをインストール
  インストールされているグラフィックボードのバージョンに合ったバージョンをインストールする。
  例）GeForce GTX1080Ti用のCuda toolkitは、12.8.0になる。
• Visual Studioをインストール
  Visual Studio 2022 community Editionをインストール
• Gitもインストールしておく

llama.cppをダウンロード＆ビルド

• https://github.com/ggml-org/llama.cppのページにあるQuick startのBuild from source by cloning this repository - check out our build guideを参照
• ダウンロードは
  git clone https://github.com/ggml-org/llama.cpp cd llama.cpp
  で行う。
• ビルドのコンフィグレーションを行う
  cmake -B build -DGGML_CUDA=ON -DCMAKE_CXX_FLAGS="/utf-8 /EHsc" -DCMAKE_C_FLAGS="/utf-8" -DLLAMA_BUILD_BORINGSSL=ON -DLLAMA_BUILD_LIBRESSL=ON -DCMAKE_CUDA_ARCHITECTURES="61;86"
  最後の、DCMAKE_CUDA＿ARCHITECTURESの61が1080Ti、86が3070用の設定になる。
• ビルドを行う
  cmake --build build --config Release
• コードページに関するワーニングがでるが無視しても動作した。一部のツールは文字化けするかもしれません。

動作確認

• llama-serverの実行
  llama-server -hf unsloth/Qwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_M -ngl 0 -b 512 --flash-attn on --host 0.0.0.0 --port 8080
  
  ファイアーオールが警告が出たらポートを解放する
• クライアントからアクセス
  http://（llamaのマシンのIP）:8080/でアクセス

モデルがQwen3-VL-235B-A22B-Thinking-GGUF:Q5_K_Mで、だいたい、１～２Token/sec、つまり1秒に1文字出力される。何かすると20分ぐらいかかるので、これを高速化できればうれしいという話。

Visual Studioからの起動＆コンパイル

• 　llama.cppをダウンロードした場所にbuildフォルダが作成される。このフォルダをカレントディレクトリとしてVisual Studio（devenv.exe）を起動する。
  下記の要領でショートカットを作っておくと良い
  
  リンク先："C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe" llama.cpp.sln （デフォルトインストール）
  作業フォルダ：C:\llama.cpp\build （llama.cppをc:\llama.cppにダウンロードしたと仮定）
  
  「詳細設定ボタン」→「管理者として実行」にチェックを入れる（プロファイル時に必要）。

• デバックモードとリーリースモードで、リコンパイルを行ってみる。

VTuneのインストール＆動作確認

• VTuneをインストール
  使っているCPUに対応したバージョンのVTuneをインストールする。
• VTuneは、最新バージョンしかダウンロードできない。2026年2月現在の最新バージョン2025.8.1.7では、Ice Lake以降のCPUしか対応していない。Core i9-10980XEは、Cascade lake（1世代前）なので対応していない。ので、事前にダウンロードしているもの（2023）を利用する。
• 2022では、Windows11 25H2の環境ではインストールに失敗した（厳密にいうと2024のインストール＆アンインストール後に行ったのでそのせいでインストールに失敗した可能性もある）。
• 2024では、正常にプロファイルが取れなかった。
• インストール時のオプションで、Visual Studioのツールにチェックが入っていることを確認すること。
• 先に2024をインストールするとアンインストールしても一部ファイルが残っており、2023をインストールしてもショートカットが2024側を指すので起動しない。
  C:\Program Files (x86)\Intel\oneAPI\vtune
  以下のフォルダをチェックすること。
• 出来れば、古いバージョンから試して不用意にバージョンをあげない方がよい。
• VTuneの起動
  インストールが終了すると、Visual Studioのメニューにアイコンがでるのでプロファイルを行える。
• ソースコードを見るには、プロジェクトの設定でデバッグ情報を出力するようにすれば良いが、デバッグモードで行った方が面倒が少ない。この場合、コードが最適かされないのでパフォーマンスが下がるが、概ね、半分ぐらいの速度になる。あまり遅くなっていない。そもそも手動で最適化を行うのでコンパイラの最適化は止めても大丈夫かと思う。手動の最適化が終わった後に最終的にＯＮにすればよい。

目的の箇所にたどり着けたのでよいが、途中、Bottom-upタブの見方が良く分からないので学習する必要がある。

最も時間がかかっている個所が判明したが、

sumi = _mm256_add_epi32(sumi, _mm256_add_epi32(p16_0, p16_1));

どうも、AVX2のコードのようである。まずは、AVX512で動かすにようにして、最適化をかけるようにする。

ボトルネックについて

　パット見た感じなので確定的ではないですが、ボトルネックになっているコードは、モデルの重みデータを戻す処理のようである。このモデルデータは、重みが5ビットのものを使っているので内部で8ビットにしているようです。
llama.cppはAVX512を使うといっているがこのデータを戻すところはAVX2のままのようです。
考えてみれば当たり前といえば当たり前なのですが、なんとなく5ビットに圧縮したら展開するのに時間がかかるのではないかと思っていたら、その通りのようでした。この部分の処理時間は全体の約70%ぐらいを占めており、この部分を最適化することは期待がもてる。
もっとも、RAMを大量に積んで利用するモデルを8ビットとかにすればこの部分の処理をカットすることが出来るのでかなり早くなるかと思うが、メモリはこれ以上は積めないので最適化を頑張ろうかと思う。

老兵は死なず、AIと踊る

なぜ日本のITが弱いのか？（もう一つの理由 Part1）

－ ITに関わる日本人は英語が残念なことが多い －

老兵は死なず、AIと踊る

ITの権威も英語は弱いか？

　変数名は「AIにレビューさせろ」Part1で、「日本人の英語力は、ばらつきがあり変数名の命名に英語を使うときは危険度が増します。」と婉曲的に書きましたが、残念ながら少なくともITに関わる日本人の英語力はやはり残念なことが多いです。
これは、私自身の英語力も以前は残念だったといえますし、今は「残念でない」だけで、上手いか？と言われたら「人よりは」と謙遜してしまいます（一応プロなので）。
実は、プログラマになりたい人向けに、「基本情報技術者試験の科目B」をお勧めしたのですが、その問題文に「残念な英語」が混ざっており発見してしまいました。
令和5年度、基本情報技術者試験 科目Bの問１の

論理型: divideFlag

になります。この変数は回答に関わっており、あまりいい加減にしてほしくないのですが、何が問題かというと命名はこの際置いておいて、値（true/false)の持たせ方にあります。

if (divideFlag が true と等しい)
  pnListの末尾 に iの値 を追加する
endif

とありますが、divideFlagを素直に読むと「割算フラグ」ということで、値がtrueの時はどういう意味かが曖昧になります。
コード上では「true = 割り切れていない」という意味ですが、多くの人は「true = 割り切れた」と受け取ってしまうでしょう。つまり誤解を与える使い方になっています。
　ということでAIに掛けてみました。各AIの実行結果は以下のとおりですが、全AIが『意味があいまいになる。「割り切れた＝trueと解釈しがち」』としています。

ChatGPTの結果
Geminiの結果
Copilotの結果
Grokの結果
ちなみに、ChatGPT,Gemini,Copilotは、「命名が良くない」とも指摘しています。
ChatGPTは下記のとおり１回鍛えたのでより突っ込んだ内容となっていますが、いずれにしても、divideFlagはダメということになります。

　私自身は、『i ÷ j の余り が 0 と等しい』の条件の部分を無意識に『i ÷ j の余り が 0 と等しくない』が正解と考えてしまい、「答えが無いやん！」と一瞬混乱しました。
もっとも、恐らくほとんどの方が、「私がおかしい」と指摘するでしょう。この部分ですが、「割り切れたら後の追加は不要（false）」という意味（candidateFlagやisPrimeなど）であればまったく問題なく、アルゴリズムを適切に判断すると、 『i ÷ j の余り が 0 と等しくない』という認識がおかしいということになります。ということで『私がいちゃもんをつけている』と感じる人もいるでしょう。要は各人が持っている英語力ということになるのですが、今は、AIで試すことにより、一部のエンジニアのいちゃもんなのか、正しい指摘なのかを確認できる時代になりました。

日本のITエンジニアの英語力

　普通のブログ記事なら「IPAさんやってしまいましたね！」と言って終わりでしょうが、いくら何でも「試験問題」ということでそれなりに注意して作成はしているでしょう。実際に多くのITエンジニアは私のような混乱は起こさないかと思います。つまりこのあたりが我々ITエンジニアの英語力の限界と考えた方がよいです。つまり、「AIにレビューさせろ」Part1の正しさをIPAさんが身をもって証明していたとも言えます。
　ということで私は、日本語でプログラムを組めるようにしたいと改めて思いましたので、ADPは日本語で名称を記述できるようにしたいです。
　「変数名を日本語で・・・」を読んだ硬派なITエンジニアは「変数名は英語だ！」と主張するかもしれません。そんなあなたにはTOEICや英検の受験をお勧めします。おそらく適切な英語名の命名に必要な英語力は、TOEICで730点、英検準１級以上かと思います。100歩譲って、TOEICの平均点560（英検2級程度）であれば、なんとか命名が出来るかもしれません（私の主観では足りないかと思いますが）。もし受験していない人は受験することをお勧めします。おそらくショックな点数（例えば300点）とかになるかもしれませんが、普通のITエンジニアの英語力はそんなものです。

やはりAIレビューが必要

　この問題は令和5年（３年前）になりますが、今ならコード全体をChatGPTに掛けられます。下記のとおり、divideFlagについてダメ出ししてもらえるので、今後は試験問題をAIに掛けたいです。ただしローカルAIでレビューしないと思わぬところで問題が漏洩する可能性があります。
ちなみに、コードにある i,jのような１文字変数は『ダメ』という記事も見かけますが、「AIにレビューさせろ」Part0（初心者の方へ）で指摘しているとおり現実としてよく使います。また、ChatGPTはダメ出ししていません。つまり、1文字変数は普通に使うと考えた方がよいでしょう。
さらに、divideFlagのように混乱を助長するような命名を行うのであれば、むしろ f のような１文字の名称の方がましだと思いますが、それはまた別の話ということで

老兵は死なず、AIと踊る

「未経験者がIT業界に入るには？」2026年版 Part1

老兵は死なず、AIと踊る

面白いnoteの記事を見つけました。
未経験でSES会社に入社したらスキルシートで経歴詐称されて会社都合退職した話
先ず、私としてはこの記事にいちゃもんをつけようという意図はなく、書いてあることはその通りなので、むしろ「もっと世間に広めないと」ということでリンクを張ります。

私が驚いたのは、一見するとITとは関係ない職種である夜職を10年やっていたIT未経験の方が、曲がりなりにも会社に採用されたことです。
ここ5年くらいでしょうか？「未経験者でも出来る！」みたいな感じで、転職サイトやらスクールやらが雨後の筍のように出てきます。こういう記事で警鐘を鳴らしたりしていましたが、昔はある程度自分で勉強した人がこの業界にチャレンジしていたような気がします。
長年この業界にいる人間からしたら「未経験者で出来るわけないだろ」と思いますし、ＩＴ業界は昔からブラックと言われていましたが、SNS時代に入りさらに悪い方向にいっているんだろうなと実感されるところにあります。

なぜ経歴詐称する未経験者がSESで就業できるのか？

　記事をよく読んでいくと当の会社ですが（異論はあるでしょうが）そこまで悪徳ではないかと思います。一応、事前にテストをしてさらに2か月研修をした上での、SES（経歴詐称）ということですが、これはよくある会社となります。
経歴詐称は良くないことではありますが、そもそもなぜこういう商習慣が成立するのでしょうか？
一番の理由は、「こういう条件でもプログラマーとして何とかやっている人がいる」ということにつきます。

ポイントは、2か月みっちりやれば、出来る人は最低限のプログラミングが出来るようになるということです。私の他の記事を見た方は「5,000時間勉強が必要なのではないのか？」と思われるでしょう。その記事にも書いていますが、私がBASICを出来るようになったのは3か月（概ね100時間）です。その後、プロになるのに「5,000時間以上」勉強したということになります。
会社に入って2か月ということは約300時間程度勉強したということですので、（プロになれるかどうかは別として）最低限のプログラミングは、（人によっては）出来るようになっているということです。

どのくらいの割合の人間が300時間で最低限のプログラミングができるかどうかは客観的なデータは持っていませんが、今までの経験上、体感では2割ぐらいは出来るようになった記憶があります。ちなみに、過去に私が勤めたわりときっちりとした会社は、大学卒業（新卒）で、おおよそ3か月ぐらい研修します。そして大体5割ぐらいはプログラミングが出来るようになっていました。

　明確な根拠があるわけではないですが、要するに、概ね2,3カ月研修をすれば、2割くらいの人間は、最低限SESとして送り込めるようになるということになります。また、ちゃんとした企業でも正社員で入った新卒の半分はプログラミングが出来なかったケースがありました。ちなみにこの半分のプログラミングができない人達がプログラミングが出来るようになったかというと残念ですがあまりいなかったかと記憶しています。このように正社員で雇ってもプログラミングが出来ない場合、ほぼその会社のお荷物になるという実態があります。

プログラミングの適性を知る

　2，3か月で最低限のプログラミングが出来ない場合、この人達がプログラミングが出来るようになるかというと難しいものがあります。「向いていなくても5,000時間やればプログラミングが出来るようになると言っていたのではないか？」とご批判がきそうです。一番大きな要因ですが、「本人のやる気」があります。言葉を変えると「馬を水飲み場に連れて行くことはできても、馬に水を飲ませることはできない」というイギリスのことわざに尽きます。そして大体、会社に入って最初の2,3カ月で「最低限の適性と本人のやる気」を確かめているということが言えます。

　もちろんですが、やる気があっても3か月では無理という人もいます。そういう人は「規格外」ということなのでしょうが、SES会社ではそういう判断を「受け入れ先の企業」に委ねるでしょう。つまり出来ない場合でもSESとして就業させられることになります。

なぜ経歴詐称をするのか？

　これは、SESの受け入れ企業が「経験者」しか受け入れないことが大きいかとおもいます。もちろん探せば「未経験OK」というのもあるかと思いますが、そもそも未経験者OKの会社がSESを頼むはずもないでしょう。　
　SESというのはいわゆる準委任契約ということで、請負契約と異なり「完成保証がない」契約となります。つまり出来なくても契約違反とならないということもあります。で、実態としてですが、結構な割合で、完成しなかったりします。実は「末端のプログラマに完成保証を行わせる」のは現実的でない。完成保証させるには仕様を確定させなければならない等それはそれで厄介だったり、あまり大きな声では言えないがそもそも完成させる必要がないもの（例えばデモの開発とか）もあります。そうすると「未経験者でも良いのか？」という風になりますが、「完成保証」はしなくても「作業した人間自体はプロフェッショナルが行った」というのが発注者側の論理となるでしょう。
　一方で、誰でも最初は未経験者で、かつ最低限のプログラミングが出来る、つまりSESでの就業も実質可能ということであれば、ということで「嘘も方便」ということで経歴作業が行われます。また、実際にここからきちんと成果を上げるプログラマもいらっしゃるかと思います。そういう人は「嘘から出た真」と言えるかもしれません。また、完成しなくても「未経験者」ということがばれにくいということもあります。
　話がややこしくなったかと思いますが、要するに例えば夜職の場合、お客に夢を語ったこともあったかと思います。たとえ夢が実現しなくても、それに対していちいち「嘘つき」という方がおかしい、というのが還暦を控えたおじさんの意見になりますが、一方で「いただき女子」のようなことをするとダメですよということかと思います。

　政府は、DXと言ってデジタル化を推進しますと言いながら、このような業界のタブーについて触れないだけでなく、逆に推進するようなことをしています。本気でデジタル化を考えるのなら、このように人材を粗製乱造するのではなく、しっかりと地に足がついたキャリアパスを業界全体で考え、政府が後押しするようにしなければならないかと思います。

なぜ未経験者が採用されるのか？

　そもそも「経験者はSES会社に入らない」ということが言えます。私ですが、SES会社に行こうとも思いません。強いて言えばユーザ企業に直接売り込みを掛けるでしょうが、実は日本の大きな企業は「経験年数」以上に「見知らぬフリーランスと直接契約はしない」というのもあります。直接契約が難しいのはどちらかというと「利権」ということになりますが、このあたりがもう少し風通しが良くなると「人材不足」ということも減るかと思います。
　また既にみてきたようにIT業界のSESとは「ライオンが子供を谷底へ落とすような場所」と言えるかもしれません。そうして這い上がった子供は当然ですが、親から独立します。そうすると親は別の子供を探すということになります。
　それ以外の未経験が採用される理由ですが、「ルッキズム」ということもあるかもしれません。あまりこれ以上踏み込むと炎上するかもしれませんが、ご自身がルッキズムで採用されたかもといういうのは知っておいても損ではないかもしれません。私が担当したプロジェクトのメンバーにそういう人がいましたが、あまりプレッシャーを与えるようなタスクは割り振らなかった（サポート業務を任せた）経験があります。
　プログラマではなく、「メンバーの雑用」、「補助」、「テスト要員」ということで採用されることもあります。これは最初から補助やテスト要員ということではなく、「こいつはプログラムが組めなさそう」と現場のリーダーが思ったらそういう割り振りをされるかと思います。私もそういう割り振りをした経験があります。

働く人も学習が必要では？

　一方で、この方の記事を読むと「働く側の矛盾」を感じます。
記事を引用しますと、
『スキルが足りなくて辞めさせられるとかそういうことなら私も悪かったと思う』と書いてありますが、少なくともご本人としては、一定のスキルは身についているという認識だったように読めます。さらに『できない仕事を「できる人」として振られるのは相当なストレスだと思う』とおっしゃっています。つまり「額面通り2，3か月のスキル」で就業したいと思っていたかもしれません。
しかしながら、一方では、この方は、『社長は面接で「経験を2〜3年に見せなければいけない」と言っていたが、それはスキル面の話だと思っていたので面食らった。』と書いていますが、この方は「経歴2,3年のスキル」をどうやったら手に入ると思ったのでしょうか？
　例えば「1週間で英語が話せる」とかでしたらほとんどの人が「眉唾」だと思うかと思います。同時に、2か月の勉強では、どうやっても２年の実務スキルは獲得できません。
（ちなみに、この人は「その会社に入って2か月間の給料をもらったかと思うし加えて、解雇予告手当ももらっているということでなかなかのやり手ではあると思う）。
　「IT未経験」でネットを検索すると「未経験歓迎の会社や転職サイト」と色々出てきますが、実態としては経歴詐称を行うSESが多いということで、「まったくの未経験者がIT業界に就業できるほど甘くはない」ということは働く人も覚えておいた方が良いかと思います。

では、どうすれば？

　別の記事では、「AIを使って学習すればよい」と書いていましたが、「未経験者が就業目的で勉強をする」ということを少し真面目に考えてみます。
私の中では「5,000時間勉強しろ」ということなのですが、それではあまりにも漠然としていますので、就業までのステップごとに見ていきます。
もちろん、各ステップで、躓いたらAIを用いて補習をすればよいということになります。

Step1　基本情報技術者試験の合格
　経験がないとなると資格を取得するのが策の1つになるかと思います。
さらに、プログラマーとして就業を目指すなら、最初に
　基本情報処理技術者試験の科目Bの攻略
が優先されるかと思います。
たとえば300時間勉強すれば、基本情報の午後の試験は解けるようになるかと思いますし、300時間勉強しても解けなければ「向いていない」と判断しても良いかもしれません。
試しに一回問題を読んでみることをお勧めします。
例えばですが、令和5年の基本情報技術者試験の科目Bのリンクを掲載します（時間が経つとリンク切れになるかもしれません）。
正解はこちらです。

Step2 通信大学に通う

　放送大学やサイバー大学などがあります。これらは安価で学習内容も最低限のクオリティは保証されているかと思います。
私は放送大学を卒業しましたので、放送大学について説明します。
　放送大学の情報コース
　 ちなみに私は、目的が違いますが、放送大学に3年次で編入し卒業しました。例えば大卒や中途退学等の方は単位が認定されるので、卒業を目指すなら3年次編入を行い情報系の単位を取得して卒業を目指すということもできます。卒業までの費用はHPによると77万円とあります。3年次編入をすれば費用は大雑把にいうと半額近くになるでしょう。多くのプライベートのプログラミングスクールがほぼ同程度の数十万円になっていますので、どうせやるなら学位の資格をとった方が励みになるでしょう。

　「大学を卒業したからどうやねん」という話もあるのですが、資格をとったり大学を卒業したりするということは「計画的に物事を進めることができる」ということでその点をアピールすれば、経歴詐称を行うSES企業ではなく、いわゆるクライアント企業への就業も目指せるかと思います。
また、アメリカの企業は本来、プログラマーで採用するにしても「コンピュータサイエンスの学位」を求めています。これはいわゆる基礎学力を求めていることになります。私のこの記事では大学教育について批判していますが、そうはいっても改めてシラバスをみると現在受講する方にとっての理想を追求しているかと思います。
（強いて、僭越ながらダメ出しを行うとすれば「OS」と「プログラミング言語処理（コンパイラの作成）」とかはあった方が面白いかとは思います）

　また、就業に際してですが、中途採用ということになりますとどうしてもハードルが上がるかと思いますが、「門前払いを食らう＝SES企業」と考えて大丈夫かと思いますし、自社開発を行っている人材不足の企業にとっては「未経験者でも実力のある人」は歓迎するでしょう。

Step3 アルバイトを目指す

　既に書きましたが、企業がなぜ「プログラマ」を正社員として入れたがらないか？「SESが跋扈するのか？」というと「プログラマとして雇い、プログラミングが出来ないと分かっても、安易に首が切れない」というのがあります。試用期間があるのでちゃんとしている会社はそこで判断をするでしょうが、「この人はプログラミングが出来ない」という判断をするのも日本の雇用慣行に馴染まないということが言えます。
一方で、アルバイトなら比較的楽に就業が出来るかと思います。私も大学生の頃、ゲーム会社や計測ソフトを作成している会社にアルバイトでプログラミングを行っていました。雇用者、被雇用者、両方にとって気が楽な面があります。

まとめ

　「未経験がIT企業に就職できる」広告として氾濫していますが、例えば転職サイトなどは「転職者のその後」をどこまでケアしているか怪しいですし、未経験＝スキルなしでもOKということではないです。
この話も嘘ではなく、むしろ「給料が出ているのかどうか不明ですが2か月間研修する」というのはむしろちゃんとしている方の会社になります。
経歴詐称はダメでしょうが、逆に「うちは経歴詐称はしません」と言われても、どこまで信じてよいかわからない面があります。
また、今の多くの企業が実態として「法的にグレーな行為」を行っている面を鑑みると、個別の企業の問題ではなく、日本での働くことの問題としてとらえた方がよいかと思います。
　ITエンジニアと名乗る人でも、プログラミングが出来る人と出来ない人がいます。これは「適性（向いている向いていない）」もありますが同時に「本人がどれだけプログラマーになりたいかという意欲（熱望）」もあります。「適性がない＝プログラミングが出来ない」というよりも実際は「あきらめる」ということが多いです。
　また、現場でのプログラミングは思った以上にプレッシャーが掛かります。リンクの方もそれが分かったので辞めたということもあるでしょう。
　中長期的な就業を考えるとSESというのはお勧めは出来ないので、きちんと勉強して資格や学位を習得すれば必要以上の寄り道をしなくてもよいかと思います。
基礎がしっかりとしていれば時代が変わっても、AIが台頭しても、その変化についていくことも出来るようになるでしょう。

老兵は死なず、AIと踊る