⚠️ この記事は非エンジニア・文系が書いています。
用語の使い方が間違っていたら、優しく教えてください。
なお、これは3部作の1本目です。次回は「厳密さとは何か」を扱います。
はじめに：きっかけは「キー」という一語
生成AIとAPIやらスクレイピングやらの話をしていて、ずっと引っかかっていた言葉がありました。
「キー」 です。
日常で「キー」と言えば、玄関の鍵くらいしか思い浮かびません。
ところが技術の世界に入ると、急にこうなります。
| 呼び名 | 何のキー？ |
|---|---|
| APIキー | サービスを使うためのキー |
| 主キー・外部キー | データを識別するキー |
| 公開鍵・秘密鍵 | 暗号のキー |
| セッションキー | 通信を維持するキー |
| ショートカットキー | 操作のキー |
| キーボードのキー | 物理的なキー |
極端に言えば、ネットワークの「ポート番号」だって、
「アクセスを成立させて、相手を識別する要素」 と定義すれば、
キーの仲間に見えてきます。
ここで素朴な疑問が湧きました。
なんで全部「キー」じゃダメなのでしょうか。
文系は使い回す、理系は分ける
考えてみると、私（文系）は言葉を使い回します。
一つの言葉に意味をいっぱい乗せて、その場の雰囲気で選んでいます。
「キー押して」→ キーボードだな。
「家のキー」→ 鍵だな。
聞いている相手がその場で察してくれるので、雑でも通じます。
でもエンジニア（理系）は、これを許してくれません。
APIキー、主キー、公開鍵と、几帳面に分けます。
なんで分けるのですか、と聞くと、たいてい
「文脈で区別しているから」
と返ってきます。
……が、これは後の記事で「実はちょっと違う」とわかります。今回は置いておきます。
用語が増える二つの方向
専門用語が増えていく仕方を見ていると、二つの方向があるようです。
縦軸（手順・工程）
同じものでも、処理のどの段階かで名前が変わります。
- 行きは「リクエスト」、帰りは「レスポンス」（同じ通信の往復なのに）です
- 人が書くと「ソースコード」、機械が動かすと「実行ファイル」になります
横軸（状況・環境）
ほぼ同じ機能でも、どこに入れるかで名前が変わります。
- 「アドイン」と「アドオン」（素人目にはほぼ同じ）がそうです
この縦×横の掛け算で、用語は座標のラベルのように増えていきます。
専門用語が多すぎるのは、ケチでもイジワルでもなく、
細かく割っていった結果なのですね。
状況A 状況B 状況C
手順1 用語 用語 用語
手順2 用語 用語 用語
手順3 用語 用語 用語
ちなみに調べたら、この「割る」発想は
ISO 704 / ISO 1087 という国際規格で
「一語一概念（単義性の原則）」 として明文化されていました。
エンジニアの几帳面さは、規格レベルの作法だったわけです。
ところで、言葉は割りっぱなしにはなりません
ここからが本題です。
用語をどんどん割っていくと、あるとき逆の動きが始まります。
「これとこれ、結局同じことを言っているよね。共通部分をまとめてしまおう」
増えすぎた言葉から共通項をくくり出して、上にまとめるのです。
割る → まとめる。この2段階がセットになっています。
そして、この「まとめる」を、
まったく無関係な2つの分野が、お互いを知らないまま同じやり方でやっている
ことに気づきました
プログラミングの「まとめる」
プログラミングでは、オブジェクト指向がこれをやっています。
- 抽象化：個別から共通の型を抜き出します
- 継承：重複する定義を親クラスに引き上げます
- DRY原則：「同じことを二度書くな」＝重複は一箇所にまとめろ、という考え方です
# Before：同じ処理があちこちに重複している
class Dog:
def breathe(self): print("呼吸する")
class Cat:
def breathe(self): print("呼吸する")
# After：共通部分を親クラスに「引き上げ（pull-up）」
class Animal:
def breathe(self): print("呼吸する")
class Dog(Animal): pass
class Cat(Animal): pass
重複している breathe を、上の Animal にまとめました。
これがオブジェクト指向の「まとめる」です。
法律の「まとめる」
そして法律にも、まったく同じ構造があります。
パンデクテン方式と呼ばれる、ドイツ民法などの作り方です。
売買・賃貸借・贈与……いろいろな契約があります。
でも、どの契約にも共通するルール（意思表示、法律行為、権利能力など）があります。
それを毎回それぞれの契約に書くのは無駄なので、
共通部分を「総則」として最初にまとめて置くのです。
【総則】 ← 全部に共通するルールをここに「引き上げ」
├─ 売買のルール（各則）
├─ 賃貸借のルール（各則）
└─ 贈与のルール（各則）
……これは、さっきのオブジェクト指向の図と、同じではないでしょうか。
| プログラミング | 法律 | |
|---|---|---|
| まとめる操作 | 親クラスへの引き上げ | 総則化 |
| 共通部分 | 親クラス（Animal） | 総則 |
| 個別 | 子クラス（Dog, Cat） | 各則（売買, 贈与） |
| 原則 | DRY（重複を書くな） | 重複規定を省く |
| 目的 | 変更しやすく・再利用 | 矛盾をなくす・条文節約 |
目的は違います。でも操作は同じです。
どちらも「重複する共通項を、一箇所にくくり出す」ことをやっています。
法律家とプログラマは、お互いの言葉を知らないまま、
構造的に同じことをしていたわけです。
おわりに：ここから先がもっと面白いのです（次回）
正直に言いますと、「法とコードは似ている」という指摘自体は、
すでに海外の論文にもあります（末尾参照）。そこは私の発明ではありません。
でも、ここから先に続きがあります。
- 法学はこの「まとめる」を何百年もかけて完成させました
- プログラミングは**まだまとめている途中（成長期）**かもしれません
- そもそも「厳密に分ける／曖昧に残す」は何で決まるのでしょうか
- 突き詰めると「厳密さ＝合意を固定したもの」ではないでしょうか
このあたりを次回（第2部）で書きます。
文系のたわごとです。間違っていたら教えてください。
参考（いずれも一次資料の確認を推奨します）
- ISO 704 / ISO 1087（単義性の原則）
- James Grimmelmann, "Programming Languages and Law" (2022)
- MIT, "Deconstructing Legal Text: Object-Oriented Design in Legal"
- 「Models of Law」Illinois Law Review
- Pandektensystem（ドイツ民法・総則–各則構造）