>_Minimal
Contact

ソフトウェアの境界を4軸で捉える

2026-05-24 7 min read IT,アイデア,論考
  • Home
  • IT
  • ソフトウェアの境界を4軸で捉える
目次
7 min read

■ はじめに

新しい技術に触れるたびに、いつも同じ疑問があった。

それが「どのレイヤに属するか」という分類ではうまく整理できない、ということだ。

実際には技術は層として積み上がっているというより、異なる種類の境界をまたぐ仕組みの違いとして現れている。

そこで、ソフトウェアを理解するために、境界を4つの軸で整理するという考え方に至った。

目的はシンプルで、新しい技術を見たときに「これは何を跨いでいるのか」をすぐに判断できるようにすることだ。

■ 4つの軸

① Where（実行空間）

どこで実行されているかの違い。

  • Thread
  • Process
  • Machine
  • Network

例

  • 関数呼び出し：同一スレッド内
  • IPC：プロセス間
  • RPC / HTTP：ネットワーク越し

ポイント

距離が増えるほど、遅延・失敗・同期の難しさが増える。

② What changes meaning（意味の変換）

同じ操作でも、意味体系が変わるポイント。

  • FFI
  • VM
  • Syscall
  • Protocol / Driver

用語

  • FFI：異なる言語間で関数を呼び出す仕組み
  • VM：別の命令体系を解釈して実行する仕組み
  • Syscall：ユーザー空間からカーネルへの呼び出し
  • Protocol / Driver：外部システムとの通信・制御規約

例

  • Python → C関数呼び出し
  • JVMによるバイトコード実行
  • ファイル読み込み（syscall）
  • USBデバイス制御

ポイント

ここは「距離」ではなく「意味の翻訳」が支配的になる。

③ Who can act（権限）

何がどこまで実行できるかの制約。

  • User ↔ Kernel
  • Guest ↔ Host
  • Container boundary

用語

  • Kernel：OSの中核で全権限を持つ
  • User space：制限された実行環境
  • Guest / Host：仮想マシンとホスト
  • Container：OSを共有しながら隔離された環境

例

  • 一般アプリはハードウェアに直接触れない
  • Dockerはプロセスを隔離するがOSは共有する
  • VMは完全に別OSとして動作する

ポイント

ここは「できることの境界」を決めている。

④ When state changes（時間）

状態がいつ確定するかの違い。

  • Git
  • Write-Ahead Log（WAL）
  • Event Log

用語

  • Git：変更をコミット単位で確定する
  • WAL：DB変更を事前にログとして記録する
  • Event Log：発生した事象を逐次記録する

例

  • Git commit：人間が意味づけた確定点
  • DBトランザクション：原子的な確定
  • Event sourcing：履歴から状態を再構築

ポイント

「いつ確定したとみなすか」の設計問題。

■ FFIの位置づけ

FFI（Foreign Function Interface）は単なる関数呼び出しに見えるが、この軸で見ると構造が明確になる。

  • Where：同一プロセス
  • What：言語モデルの変換が発生する
  • Who：安全性モデルの境界を越える
  • When：同期的

つまりFFIは、物理的には近いが、意味変換のコストが非常に大きい接点になっている。

■ RPCの位置づけ

RPCは逆の性質を持つ。

  • Where：Machine間
  • What：Protocolによる意味変換
  • Who：基本的に制限なし
  • When：非同期・失敗前提

距離が主なコストになっている境界である。

■ このモデルの使い方

このモデルの目的は分類そのものではなく、

新しい技術が「どの種類の境界をどう扱っているのか」を素早く理解することにある。

例えば：

  • RPC → 距離の問題
  • FFI → 意味変換の問題
  • コンテナ → 権限の問題
  • Git → 時間の問題

■ このモデルを作った動機

このモデルを作った理由は単純で、

新しい技術が出てきたときに、それがどの種類の境界を扱っているのかを瞬時に把握したかったためである。

技術は個別の発明に見えるが、実際にはそれぞれ異なる境界の扱い方として整理できる。

■ まとめ

ソフトウェアとは、単なる層の積み重ねではなく、

空間・意味・権限・時間という異なる種類の境界をどう扱うかの設計の集合である。

この4軸モデルは、それを見分けるための思考の道具である。

■ 最近の技術を4軸でざっくり分類

■ LLM / GPT系（大規模言語モデル）

  • Where：Machine / Network（クラウド前提）
  • What：意味変換が支配的（自然言語 ↔ 数理表現）
  • Who：APIレベルで制御（強い権限制御あり）
  • When：推論は即時、学習はバッチ・非同期

→ 意味変換の極端な外部化

「意味を計算機に持ち込んだ技術」

■ RAG（Retrieval Augmented Generation）

  • Where：Machine / Network（検索先分離）
  • What：意味＋外部知識の合成
  • Who：データソース依存（権限というより信頼構造）
  • When：リアルタイム参照＋即時生成

→ 意味変換＋外部記憶の合成構造

「モデル単体の限界を外部記憶で補う設計」

■ Kubernetes

  • Where：Machineクラスタ
  • What：抽象化された実行単位（コンテナ）
  • Who：強い権限制御（namespace / RBAC）
  • When：宣言的状態管理（desired state）

→ 実行空間と権限の統合制御システム

「実行環境そのものを抽象化したOS」

■ Docker / Container技術

  • Where：Process内部の仮想分離
  • What：ほぼ変化なし（OS呼び出しそのまま）
  • Who：制限された権限境界
  • When：通常のプロセスモデル

→ 権限と実行空間の軽量分離

「OSを壊さずに境界を作る技術」

■ WebAssembly（Wasm）

  • Where：Machine / Runtime
  • What：命令セットの再定義
  • Who：サンドボックス制御
  • When：即時実行モデル

→ 意味変換の標準化＋安全な実行空間

「ポータブルVMの再発明」

■ FFI（Rust / Python / Goなど）

  • Where：Process内部
  • What：言語モデル変換が発生
  • Who：unsafe / boundary制御
  • When：同期呼び出し

→ 意味変換の境界そのもの

「近いのに一番壊れやすい接続」

■ gRPC / REST API

  • Where：Network
  • What：構造化データへの意味変換
  • Who：基本制約なし
  • When：非同期通信

まとめ

→ 距離コストを前提にした意味変換

「分散システムの標準的境界」

■ Web3 / Blockchain

  • Where：Network（分散台帳）
  • What：状態の意味を分散定義
  • Who：合意アルゴリズムで制御
  • When：ブロック単位で確定

→ 時間と権限の再定義

「誰がいつ状態を確定できるかの再設計」

■ Git

  • Where：Local / Distributed
  • What：状態そのものではなく履歴
  • Who：ユーザー主体
  • When：明示的コミット

→ 時間の構造化

「状態ではなく履歴を扱う設計」

■ Edge AI（ローカル推論）

  • Where：Machineローカル
  • What：クラウド依存からの意味変換内製化
  • Who：ユーザー権限強化
  • When：即時

→ 意味変換のローカル回帰

「クラウドから端末へ意味処理を戻す動き」

■ 全体を俯瞰すると見えること

この4軸で見ると、最近の技術トレンドはかなりはっきり分かれます：

① Meaning（What）をいじる流れ

  • LLM
  • RAG
  • FFI
  • Wasm

👉 「意味変換の高度化」

② Where（実行空間）を変える流れ

  • Kubernetes
  • Edge AI
  • Cloud-native

👉 「実行場所の抽象化・再配置」

③ Who（権限）を変える流れ

  • Containers
  • Web3
  • Zero Trust系

👉 「信頼モデルの再設計」

④ When（時間）を変える流れ

  • Git
  • Blockchain
  • Event sourcing

👉 「状態の定義そのものの変化」