トップ > 開発言語 > エンジニアの視点から見る「言語」の意味

エンジニアの視点から見る「言語」の意味

開発言語 コミュニケーション その他技術系

※この記事は「エムティーアイ Blog Summer 2025」の 8/13 分の記事です。

はじめに

こんにちは！スマートコンテンツ事業部の藤木です。
エムティーアイに新卒でエンジニアとして入社して、配属直後にこの記事を書いています。
大学院では自然言語処理系の研究室にいたため、言語やAIなどに関心があります。

弊社では3か月間の新卒エンジニアの研修があり、そこではC#・Reactなどを学びながらWebアプリを作成しました。私はその過程で疑問を覚えました。

  • 書きたい処理はなぜ毎回プログラミング言語で表現可能なのか？
  • 「言語」を扱うものであるなら、理系より文系の分野なのでは？
  • 「言語」と呼ぶからには日本語、英語などと共通点もあるのではないか？
  • 綺麗な日本語を使う方法と、綺麗なコードやアーキテクチャを作る方法はもしかして近いのではないか？

これらについて私も最近勉強中ですが、学んでいることをこちらで共有したいと思います。
本記事の知見を活用することでプログラミング言語への理解が深まり、綺麗なコードを書けるようになる(かもしれない)ことを期待しています。

目次

言語とはどんなものか？

そもそも言語とは何でしょうか。我々が思いつくものは日本語、英語、各種プログラミング言語とかでしょうか。しかし、日本語とPythonは似ているようで何か違うなと違和感を感じると思います。
違和感の通り、言語はざっくり二種類に分類できます。それは自然言語と形式言語と呼ばれます。
両者の共通点を以下にまとめます。

  1. 記号(symbol)の集合である。これら記号によって構成される。
    自然言語：「猫」「run」「😂」など
    形式言語：「while」「print」「=>」など

  2. 構文(syntax)がある。正しい記号の順番が決まっている。
    自然言語：私 は 本 を 読む 。
    形式言語：if x > 0:

  3. 意味(semantics)がある。
    自然言語：「犬」は現実世界のあのかわいい四足歩行の哺乳類を指す
    形式言語：int x = 5; は状態や値がどうなるかを定める

これらの性質を持つものを言語と呼ぶことが多いです。

自然言語と形式言語の違い

なぜ自然言語と形式言語でこのような違いがあるのでしょうか。 最大の違いは、「曖昧性を許容するかどうか」です。自然言語は文脈や状況によって構文や意味の変化を許容しますが、形式言語は解釈が機械的に一義に決まるように設計されています。
例えば自然言語では、「ごはん」という文がsyntax errorもsemantic errorも吐きません。構文や意味が一見適当でも問題ないことがあります。 お昼時であれば食事をしたいことがわかりますし、焼き肉中であれば白米を指していることがわかります。
対して形式言語では "ごはん" と書かれてもなにがなんだか分かりません。多くの場合何も起きず、もしくはエラーになります。
曖昧性を許容することにはメリットもデメリットもあります。メリットとしては記号の数を減らすことで楽ができる点や、文学作品などで曖昧性を楽しむことができます。デメリットとしては厳密性がないので、定まった意味を記すことが難しいです。
なので厳密性のある言語として、プログラミング言語などが用いられています。

形式言語には数式や論理式なども含まれることからも、自然言語と形式言語のメリットデメリットが感覚としてわかるのではないでしょうか。

言語があらわしているもの

ここまで言語の性質を見てきました。ではここで、言語があらわしているものとは何なのでしょうか？
これは一言で言うと、「世界(対象ドメイン)」です。文章によって目の前に光景が想像できるような小説が記述可能ですし、数式によって多くの物理法則が記述可能です。またプログラミングによって、無限の処理とソフトウェアを形作ることができます。
これが言語の持つ最大の力なのです。
日本語とプログラミング言語、これらが何か似ているようで違うような、という違和感はこの説明でしっくりくる面もあるのではないでしょうか。見た目の構造こそ違えど、世界を記述しているという意味で共通しているのです。

余談：syntax errorやsemantic error、bugについて

先ほども軽く触れましたが、コーディングをしていると良く遭遇するエラーやバグ。プログラミング言語であればエラーを吐きますが、自然言語ではエラーを吐かないという説明をしました。
ただし、場合によっては自然言語でもバグが起きることがあります。厳密性がないのですから、解釈によっては意味のわからない世界が構築されることがあるのです。プログラミングの論理バグと同じで、バグというのは世界の記述の失敗と言えます。
よくあるのは、コミュニケーションのすれ違いです。構文や意味が曖昧なことにより、人間インスタンスによって解釈が異なることがあるのです。
これは日常生活では問題にならなくても、仕事では大きな問題になることがあります。これらのバグを避けるために、研修ではロジカルシンキングや報連相、コミュニケーションについて研修するのですね。

さらに余談ですが、意図的にバグを起こすことをエンタメに消化しているコンテンツもあります。アンジャッシュのコントや、ルイス・キャロルの不思議の国のアリスなどが代表的でしょうか。ここでは詳しくは触れませんが、面白いのでぜひ見てみてください。

なぜ世界の表象/モデル化が可能か？

前章ではプログラミング言語は言語である以上、無限の処理とソフトウェアを作ることができると述べました。しかしそれは本当なのでしょうか？
これには、チューリング完全性と存在論(オントロジー)が関係あります。それぞれ説明致します。

チューリング完全性とは

非常に乱暴な言い方ですが、(理論上)「ある言語／計算系があらゆる計算を実現できる」ということです。多くのプログラミング言語はこの性質を持っています。

存在論(オントロジー)とは

もともとは哲学の一分野で、情報科学領域にも応用して用いられる概念です。「何が存在しているのか」を形式言語を用いて厳密に記される方法は以前からありました。
その際に用いられる言語はDL (Description Logic)などがあり、以下のような概念で構成されています。

  1. 概念(Concept)
    例：Person (人間), Animal (動物)
  2. 役割(Role)
    例：hasChild (子を持つ), worksFor (勤務先)
  3. 個体(Individual)
    例：alice : Person, bob : Person
  4. TBox(Terminological Box)
    概念や役割の定義・階層化(クラス階層や制約)
    例：Employee ⊑ Person, Manager ≡ Employee ⊓ ∃ manages.Department
  5. ABox(Assertional Box)
    個体に関する事実の記述
    例：alice : Manager, worksFor(bob, dept1)

気づいた方も多いのではないでしょうか。これはオブジェクト指向の言語と概念がとても似ています。
情報科学のオントロジーとオブジェクト指向は系譜としては異なるっぽいのですが、それはむしろこのような「存在の捉え方」がなかなか核心を捉えているという解釈も可能なのではないでしょうか。

二つが合わさると

オントロジーにより物の存在を定義して式で表せる範囲のものは、(計算可能な範囲で)チューリング完全性を持つ言語によって計算可能なのです。(現実には停止問題・資源制約・記号のグラウンディングなどの課題が残ります。)
言い換えると、世界を構成する「存在」を上手にとらえることによって、それはプログラミングによって再現可能なのです。
私たちは世界がどのように言語で記述されるかを考えながらコーディングを行っている、ということになります。コーディングに論理的思考力が必要と言われる所以に感じます。

エンジニアリングへの応用

ここまで見ると、綺麗にコードを書くとはどういうことか、アーキテクチャとは何か、というものが見えてきた気がします。
まずアーキテクチャとは、プロダクトの構造をどういう存在のつながりと捉えるか、ということだと感じます。ごちゃごちゃと記述していては世界のどこに何があるのかがわかりにくくなってしまいます。世界の捉え方のフレームワークを一定にすることで、わかりやすさを上げる。また、チーム開発において共通の世界観を共有できることで、バグや可読性の低下を阻止する。言語を扱う営みですから、わかりやすさや認識の共有により円滑にことが進むというわけですね。
綺麗にコードを書くというのも同じです。世界の捉え方に沿ったコードを書くということです。その言語が大事にしている概念やコーディング規則は、世界の捉え方を推奨していると捉えることができます。

コーディングの勉強方法も自然言語のそれと共通の部分があるように感じます。使われる記号の意味を理解することやその繋げ方を理解するには、単純なインプットと、たくさんコードに触れることによって世界の構成のされ方を知る必要があることに繋がります。

コーディング以外のエンジニア業務にも応用ができます。コミュニケーションやドキュメンテーションで、「この言語の作る世界は相手に正確に伝わるのか？」「もっとよい世界の表現方法はないのか？」と考えることで、よりよく言語を扱って情報のやりとりを行うことができると思います。

まとめ

今回は「言語」の特徴と、プログラミング言語の概念について簡単に説明いたしました。
自然言語と形式言語の違いはその厳密性で、共通点は世界を象徴する、ということです。

少しでも皆さんの言語への理解が深まって、エンジニアリングの考え方の一助となれば幸いです。
拙い文章ではございましたが、ここまで読んでいただいた方には感謝の気持ちでいっぱいです。ありがとうございました。

補足（GPT-5 メモ）

わかりやすさのために曖昧に書いた場所もあるので、AIによる補足を以下に書いておきます。

  • 自然言語／形式言語の二分：入門の見取り図として読むと理解しやすい。実務には制御自然言語や DSL（SQL・正規表現など）、マークアップ（HTML）といった“中間”もある。

  • 「犬」の説明のニュアンス：定義の例は中立的な言い回し（例：四足歩行の哺乳類）として解釈すると、概念と評価の混在を避けられる。

  • int x = 5; の前提：C/Java 系の意味を想定した例。Python では x = 5 は「名前に 5 を束縛する」挙動で、同じ見た目でも意味論が異なる。

  • 「ごはん」は発話の例：自然言語は語用論（文脈）が意味を補完する。短い発話でも状況次第で意図が伝わるという趣旨。

  • 形式言語での "ごはん"：多くの処理系で“裸の文字列”は副作用のない式として評価されることがある（REPL では値が表示）。規則で許された文脈に置かれない限り、有意味な操作にはならないかエラーになる。

  • エラーの層：不具合は「構文エラー（パース不可）／静的意味エラー（型不一致・未宣言参照など）／実行時エラー」の三層で捉えると整理しやすい。

  • 「無限の処理」：理論上の表現力を指す。実際の計算は時間・メモリなどの資源制約を受ける。

  • チューリング完全性（超要約）：「計算可能な手続きなら理論上は表現できる」性質。停止問題などの限界があり、正規表現や一部 DSL のように意図的に非 TC な言語もある。

  • オントロジーの形式化：20 世紀の述語論理の発展を背景に、記述論理（DL）や OWL で「何が存在しどう関係するか」を機械可読に表せる。DL は代表枠組みで、FOL や Common Logic でも表現可能。

  • DL の用語：TBox＝概念や関係の定義（階層・制約）、ABox＝個体に関する事実。例の worksFor(bob, dept1) は「bob が dept1 で働く」の意味。

  • 開放世界と閉世界：オントロジー（OWL 等）は「未記載＝未知」（開放世界仮定）、多くのアプリや DB は「未記載＝不存在」（閉世界仮定）。前提の違いで推論・クエリの振る舞いが変わる。

  • グラウンディング：モデル上の記号を実データやセンサー入力に結びつける工程。ここが弱いと記号操作にとどまりやすい。

  • アーキテクチャの読み方：「存在のつながり」という比喩に加え、責務・依存・インターフェース・データフロー・品質特性（可用性・変更容易性・性能など）を含む“世界観”として捉えると全体像が掴みやすい。

  • 認識ずれを減らす実務ツール：Ubiquitous Language（用語統一）、OpenAPI／JSON Schema／GraphQL のスキーマ、C4 モデルの図、ADR（アーキテクチャ決定記録）は、チームの“言語”を固定して解釈の揺れを減らす助けになる。

  • 「象徴」という語：ここでは「表象（モデル化）」の意味合いで読むと技術文脈に馴染む。