はじめに
「プログラミング＝英語の文字」そんな常識がある中、日本語でプログラミングできる言語が存在することをみなさまご存じでしょうか？
「なでしこ」や「Mind」といった日本語プログラミング言語は、十分業務システム開発に使えるように設計されています。しかし、商業用途のシステムやアプリケーション開発現場で使われることはあまりないようです。
ただし、あまりないとはまったくないことを意味しておらず、たとえばMindの開発会社スクリプツラボが2004年から2010年の間請け負った「ぐるなび」の全文検索エンジンは日本語プログラミング言語Mindで実装され運用されていました。
本記事では、なぜ日本語プログラミング言語は広まらないのか？その理由と今後の可能性について現場にいるシステムエンジニアの立場から考察してまいります。また、日本語プログラミング言語をよく知らないエンジニアの方がイメージで書いている説明を読んでみて誤解をまねくような点について是正を試みております。
日本語プログラミング言語の代表例
なでしこ
日本語に近い語順で書ける、現在もっとも知名度のある日本語プログラミング言語で、中学校の教科書にも採用されている実績があります。ネーミングも日本らしさを強調していてグッドですね。
バージョン１はインタプリタ言語です。バージョン３はNode.jsベースのJavaScriptへのトランスコンパイラ言語です。いずれもオープンソースでGitリポジトリにアクセスすればソースコードを閲覧できます。
なでしこ３はWebブラウザ版にも対応
バージョン１とは完全互換ではないですが日本語に近い文法を持ちつつ、なでしこ３（バージョン３）ではブラウザベースの実行環境を整えています。前述しましたようにNode.jsベースなのでコンソールやデスクトップアプリも実装可能な、現時点での主力バージョンです。
プロデル
プロデルは日本語に近い語順で記述できるオブジェクト指向の中間コードコンパイラ言語です。中間コードは共通言語ランタイム(CLR)で、.NETアプリケーションと同じ実行環境で動きます。
言語名は変わりますが、「プロデル」のフランス語風カナ読みで「プロデューレ」の「レ」とレつながりで、「スミレ」と「スミレ畑」があります。（そのような意図で命名されたかとは無関係です。）
スミレ畑はWebブラウザ版にも対応
スミレは.NET Core環境で動作し、スミレ畑はWebAssemblyというWeb用のアセンブリ言語をコード生成しますので、これらの環境上で動く他言語のアセンブリとの相互運用性に優れた日本語形式言語の実装と言えます。
Mind
1985年に登場したMindは分かち書きながら日本語の語順で記述でき、大規模開発の実績と堅牢性を持つ中間コードコンパイラ言語です。独自の中間コードは専用のC言語ランタイム環境で実行されます。
Mindで実装された「MindSearchII」が大規模商用サービスぐるなびの全文検索エンジンとして2004年から6年間採用されたことも、その実力を示していると言えるでしょう。
また、Mind登場の20年後に登場したなでしこが中学校教材に採用されたことと同様に、Windows以前の時代ではMindも中学校向け教材として言語仕様調整されて販売された実績があります。
ドリトル
実用に振ってるなでしこ・プロデル・Mindに比べると、まさに教育目的で開発された日本語プログラミング言語です。公式ホームページでも「ドリトルは教育用に設計されたプログラミング言語です。」とうたわれています。
中学校・高校の教科書や副教材などに採用されています。プロデルと同様にオブジェクト指向を基調に設計されています。
日本語プログラミング言語がプロの実装現場に普及しない３つの理由
ローカル言語を選択した時点で生じる規模の問題
こんにちの世界の支配的言語は英語であることに誰も疑いをはさむ余地がないでしょう。
英語には英語のよさがあります。少ない文字種、覚えやすいシンプルな文法。日本人にとってはネィティブなプロナウンスになじめず、聞いたり話したりすることが苦手でも、読み書きは得意な方が多数いらっしゃると思われます。
また、少ない文字種というのはコンピューターと相性がよく、とくにプロセッサが非力だったころ、文字を文字コードという数値で扱う上、文字種が少ない英字は非常に効率がよく、プログラミング言語の主流の文字種として利用され続けるには相応の理由があると考えられます。
その点は、コンピューターのパワーが飛躍的に向上した今日でも、その有用性にかわりなく、今後もコンピューター言語の主流文字として使われていくと筆者は予想しています。
今日のプログラミング言語は巨大グローバル企業がスポンサーとなったオープンソースプロジェクトが主流で、（そうでなくても利用され支持されているプロジェクトももちろんありますが）言語機能単体だけではなく大規模フレームワークとしてライブラリ提供されることが一般的で、多くのコントリビュータが英語を基調としたプロジェクトで活動されています。
従って、日本発のプログラミング言語であっても、英字を使った方がグローバル展開の上では制約がないと言えます。
このような点から、プログラミング言語のシステム文字に日本語をメインに据えることは、世界展開の上では企画した時点で制約を負うことになります。
ライブラリ・フレームワークの展開の制約
日本語プログラミング言語自体の開発プロジェクトは、前節で述べましたとおり、ことの性質上規模の制約が生じることに由来して、展開できるライブラリのボリュームにも制約がかかります。
プログラミング言語の言語仕様としては問題なくても、提供できるライブラリの開発にはマンパワーが必要で、マンパワーの規模はその言語のライブラリやフレームワークの規模感となります。
今日のシステム開発やSI現場では、プログラミング言語単体の採用というよりは、フレームワーク化された大規模ライブラリを同時に利用する形で動いています。
業務用システムとして依然主流のWebアプリケーションシステムなどを開発するには、相応の規模のフレームワークライブラリを利用することが必須で、それを使わずして一から機能を用意していくのは、いくらプログラミング言語自体の生産性が高いものになっていたとしても、今日の現況ではむりがあると言わざるを得ないでしょう。
このような背景から、大規模システム開発の開発言語として、日本語プログラミング言語が採用されることはよりいっそうむずかしくなっています。
プロの実装エンジニアの認知の問題
SESなどで稼働するプロの実装エンジニアは、このような背景を大前提に、ほとんどは海外から登場する圧倒的な規模のフレームワークを伴うプログラミング言語の習得とそれを使いこなした効率のよい実装が必須のタスクとなります。
彼らにとって、業務上の必然性として日本語プログラミング言語の習得の必要性はほぼ完全にない状況です。
そのため、基本的には日本語プログラミング言語の具体的認識を詳しくもたないため、語感からだけからなるイメージ先行のステレオタイプも生じやすい状況となっています。
ここで、プロの実装エンジニアの方とけんかを売るつもりはなく、これはいたしかたない状況と説明しています。
例えば記述が長くなるから日本語の表現がプログラムに適さないという誤解
例えば、Pythonなら
print("Hello")
と書くところが、日本語プログラミング言語Mindでは
"Hello" 表示
のようにも書けます。（対話環境であればまさにこれだけも動きます。）
文字数でいったら"Hello"のぞくとPythonなら７文字ですがMindなら空白含めて３文字です。（いじわるな読者はここでタイプしている文字数はhyouziなので空白含めて７文字でしょと連想されるかもしれませんが、いまどき全文字フルタイプする人はそういないので、この議論にあまり建設的な意義はなさそうですが、いかにも長そうに表現している例があったもので反証しています。）
お嬢様コーディングを端的な例とすれば、とても冗長に書くこともできますが、定義者の書き味で極端に短く書くこともできなくはないということはイメージを更新していただきたく、ちょっと触れてみました。
記号系言語のように意味が直感的にわからなくても短い方がよいならば、等価定義を使っていくらでもシステム予約語を短くすることもできます。これはある意味どの言語でも多かれ少なかれ同じでしょう。
人間の認知能力は優秀なので、より記号的で宣言的なプログラミング言語に慣れた場合、Pythonであっても手続き系言語が冗長に思えるというのはありうることで、なにも日本語に限ったことではなく、英字系プログラミング言語でも冗長に関数名定義すれば長くすることはできると思います。
ですからこのあたりはどういう意図をもってコーディングするか、将来これを保守する別の記述者を想定して意図をわかりやすくするか、記述量の効率重視とするかの違いのようにも思われます。
AI時代の日本語プログラミング言語の生存戦略
エンジニア以外のドメインプロフェッショナルへの展開
これまでの日本語プログラミング言語の主なユーザー層は、プログラミングを職業としていないさまざまな職業の方がメインとなっており、ご自身のアイデアをアプリケーション化することで、業務改善に寄与されていることでしょう。
このユーザー層は引き続き日本語プログラミング言語を採用しつづけてくれると予想されますが、AI時代になると一部の層はバイブコーディングにシフトする余地があります。
しかし、生成されたソースコードの意味を認識してちょい変したいような場合は、日本語プログラミング言語で生成するようAIと対話する可能性があります。
ソフトウェアエンジニア以外のエンジニアへの展開
エンジニアの中では、大きくわけてソフトウェアエンジニアとハードウェアエンジニアとにわかれます。
ハードウェアエンジニアの中にはプログラマブルなデバイスを開発するような場合はソフトウェアエンジニアにかなり近いと言えますが、通常はプログラミングを本業としないハードウェアエンジニアを想定すると、業務改善用途でさまざまなアプリケーションを実装して業務に役立てることができます。
本業の負荷とのバランスで習得力のある方は一般的なプログラミング言語を利用している場合も多くありますが、業務改善対象が大規模なフレームワークを想定しなくても実現可能で、SIlerなどに対価を払って開発するのではなくあくまで業務担当者個人＋α程度で開発する場合は、設計イメージとソースコードが近い日本語プログラミング言語は選択対象となるでしょう。
また、ハードウェアエンジニアには属さないけれども、プログラミングを主業務としないＩＴエンジニアとして、ネットワークエンジニアやシステムエンジニア（プログラマだったのは昔で、今はえらくなってプログミングスキルはロストしている）層にも選択の余地はあると考えられます。
後者の場合はソフトウェアやシステムを設計している業務がメインなので、システム開発の専門といえば専門なので、日本語プログラミング言語を選択する理由は少し異なるので次の節にゆずるとします。
前者のネットワークエンジニア層が外部のSIlerやSESに対価を払って社内システムを構築するような場合、外注費削減の手段として日本語プログラミング言語で社内システムを自力で構築するというようなケースも考えられます。
AIとバイブコーディングする場合も同じで、今日の複雑な実装言語を直接生成させて細かい保守ができなくなるより、日本語プログラミング言語を生成させて、細かいちょい変保守は自分たちでやりたい場合は選択の理由となります。
ソフトウェアエンジニアの設計現場への展開
これまで説明してきましたとおり、日本語プログラミング言語にとってシステム開発現場はレッドオーシャンで、英字系一般プログラミング言語の支配圏です。
システム開発現場では、英字系一般プログラミング言語のスキルが達者で優秀な実装エンジニアがごまんといて、SESなどの一定のビジネスを構成してもいます。
しかし、ソフトウェアやシステムも工業プロダクトである以上、仕様がまずあって、その仕様を実現実装するために開発が行われます。そこで、システム開発の現場にはソースコードを直接扱うエンジニアの直上に仕様をコントロールするシステムエンジニアという職層があります。
システムエンジニアという範疇でも、プログラミングできるかできないかは多様で、業務知識が豊富で業務要件のみとりまとめる層とか、こちらのキャリアパスはコンサルタントというネーミングに志向されてゆき、細かい実装はできなくてもデータベース照会言語SQLだけ覚えていてデータ構成設計だけできる層や、設計と実装が両方できる層とかさまざまとも言えます。
とりあえず、システムエンジニアという職責の中に、実装プログラミングを含むか否かは業態や事業のキャリアパスにもよりますので、ここでは設計業務という範疇で考えてみます。
ソフトウェアエンジニアやシステムエンジニアに対する設計支援ツールというものは存在していますが、賞味の対象ロジックを細かく設計する際は図形表現では作業効率が悪くなります。実際のところ、設計支援ツールで最初から最後まで設計しているのはめぐまれた環境で、いろいろ日程に押されて不完全な設計情報を実装担当者や業者に引きわたすということが多くあります。
そこで現れるのは、不完全な自然言語表現の日本語による仕様情報です。
多くのシステムエンジニアが、自然言語の日本語で、一般的なプログラミング言語のソースコードを書く実装エンジニア・プログラマに仕様を伝達しています。
これまで説明してきた制約上、システムエンジニアの方には日本語でも厳密なプログラミングが可能ということを知らない方も多くいます。
そのため、設計言語ツールのない現場の彼らはいきおい自然言語の表現で、同じ人間のプログラマーと対話して仕様を調整している世界があります。
この領域はある意味、日本語プログラミング言語のブルーオーシャンとも言える世界です。
文字種としては主に日本語を用いておりますので、単語用語や登場変数の定義漏れ、誤記脱字のゆらぎが蔓延するコンパイラチェックなき自然言語の設計情報をパラダイムシフトして、定義漏れ、誤記脱字の他、ロジックが破綻していないかなどのコンパイラチェック可能な設計用途の日本語プログラミング言語の登場が待たれます。
おわりに
今日の実装用プログラミング言語は高度に複雑化して、かつて高級言語がめざした、機械語よりではないプログラミング言語の理念からは先祖返りしているような様相を示しています。
これらの高度なプログラミング言語を手作業で扱う職種として、専門職プログラマーの需要はひきつづき維持されつづけるとは思いますが、ビジネスの現場ではより変化に柔軟に対応可能なアプリケーションやシステムの実装が要求されているのも事実であります。
システム開発の現場でも、大規模な人海戦術が要求されるフルトラックの実装開発よりもノーコーディングやバイブコーディングの展開も予想されます。
コンピュータにやらせたいタスクを指定する言語として自然言語をそのままAIなりに解釈させても、どこまでいってもあいまいさは排除できず、人間のプログラマにあいまいな説明をして手戻りが発生するのと同じようなリトライによる反復が発生するものと考えられます。
なぜなら、人間が使う自然言語は人間の文化的な側面を強く持っており、文芸芸術的な側面から解釈の多様性や表現の多様性といったものをおのずと内在しておりますので。
ソフトウェアの動作内容を指定したり記録するソースコードの価値は不変で、一定の形式化と構造化により人間同士でも厳密で一意なロジックが認識しあえる言語としてコンピュータ向けのソースコードのありようは今後もベストな状態が模索されていくものと考えられます。