UNIX思想における「表現性の原則」：ロジックではなく、データに寄せるとは？

UNIXの哲学にはいくつかの重要な原則がありますが、その中でも「表現性の原則（Rule of Representation）」は、特にソフトウェアの設計において強力な指針となります。この原則はしばしば「ロジックではなく、データに寄せる（Represent knowledge as data, not as code）」と表現されます。

本記事では、この考え方が意味するところを解説し、「データ」という言葉が具体的に何を指すのか、またこの原則を活かした具体例を交えて紹介します。

表現性の原則とは何か？

「表現性の原則」とは、処理ロジックに組み込むのではなく、設定や構造をデータとして表現することで、プログラムの柔軟性・拡張性・再利用性を高めるという考え方です。

「ロジックではなく、データに寄せる」とは？

プログラムの挙動を決定づける情報（例：設定、処理の順序、変換規則など）を、コードの中にハードコーディング（固定的な記述）するのではなく、外部ファイルや構造化されたデータ形式（JSON、XML、YAML、CSVなど）に切り出して保持することを意味します。

このようにすることで、以下のような利点が得られます：

コードを変更せずに挙動を変えられる
ユーザーや管理者が設定を柔軟にカスタマイズできる
汎用性の高いロジックを再利用可能にできる

「データ」とは何か？

ここで言う「データ」とは、構造化された形式で外部または内部に保持される情報のことです。代表的なものには以下のようなものがあります：

設定ファイル（例：.ini, .conf, .yaml）
入力パラメータ
状態遷移表やルール表
外部データベースやリソースファイル
JSONやXMLで記述された構成情報

つまり、「コードそのもの」ではなく、「コードの動作を決定づける情報」を意味します。

具体例

1. フィルター処理：`sed` や `awk`

awk -F, '{ print $1, $3 }' data.csv

この例では、CSVファイルという“データ”に対して汎用的なロジックで操作しています。特定のデータ構造（カンマ区切り）に寄せることで、awkという一般ツールでさまざまな処理が可能になります。

2. 設定ファイルによるアプリ制御（データ寄せ）

# config.ini
mode = debug
log_level = info

アプリケーションがこの設定ファイルを読み込むことで、コードを変更せずに動作モードやログ出力レベルを切り替えられます。

3. 状態遷移の記述（データ寄せ）

{
  "states": [
    { "from": "init", "to": "processing", "on": "start" },
    { "from": "processing", "to": "done", "on": "finish" }
  ]
}

状態遷移をデータとして記述すれば、状態管理ロジックを汎用的に設計でき、別の状態遷移表に差し替えることで異なる挙動を実現可能です。

4. テンプレートエンジン（例：Jinja2）

<h1>Hello {{ name }}!</h1>

ここではテンプレート（＝データ）に埋め込まれた変数nameに動的に値を挿入することで、ロジックを汎用化できます。

「ロジックに寄せる」場合の例

例1：条件分岐をコードに埋め込む

def process(mode):
    if mode == "debug":
        print("Debugging...")
    elif mode == "release":
        print("Running normally")
    else:
        print("Unknown mode")

この場合、動作モードの条件分岐はすべてロジック（コード）に書かれているため、モードを増やすにはコードの修正が必要です。

例2：状態遷移をコードに埋め込む

if current_state == "init" and event == "start":
    current_state = "processing"
elif current_state == "processing" and event == "finish":
    current_state = "done"

状態遷移がすべてコード内で記述されており、新しい状態を追加するたびに条件分岐を増やす必要があります。

まとめ

UNIX思想における「表現性の原則」は、コードの柔軟性や再利用性、保守性を高めるための重要な視点です。「ロジックではなく、データに寄せる」ことで、ソフトウェアはより構造化され、他のツールとの連携や自動化も進めやすくなります。

現代のソフトウェア開発においても、この考え方は設定管理、CI/CDパイプライン、マイクロサービスの設計など、さまざまな場面で活用されています。