できます。

むしろ面白いのは、

名作ごとに「どのようなDB設計思想を採用したか」が違う

ように見えてくることです。

あなたの理論を発展させると、

 

小説

キャラクターテーブル群

ストーリー機能群

状態変化

 

になります。

同じ手法で何作品か見てみます。


1. こころ

まず漱石の『こころ』。

普通の読解

 

先生と私の交流

先生の過去

Kとの葛藤

遺書

 

です。


しかしテーブル理論だと

 

Sensei:

guilt

loneliness

secrecy

self_destruction

 

K:

idealism

seriousness

self_discipline

 

Watashi:

curiosity

admiration

youth

 

になる。


ストーリー機能

 

meet_sensei()

 

trust_building()

 

reveal_past()

 

receive_will()

 

inherit_worldview()

 


システム目的

 

人間の罪悪感を次世代へ伝達する

 


つまり

『こころ』

 

罪悪感継承システム

 

になる。


2. 吾輩は猫である

これはさらに面白い。


キャラクターテーブル

 

Cat:

observation

sarcasm

neutrality

 

Kushami:

vanity

anxiety

scholarship

 

Meitei:

irony

humor

 


ストーリー機能

 

observe_humans()

 

criticize_society()

 

mock_intellectuals()

 

report_absurdity()

 


すると

物語は

 

事件を起こす話

 

ではなく

 

社会監視システム

 

になる。


主人公の猫は

実は主人公ではなく、

 

ログ出力テーブル

 

に近い。


3. 坊っちゃん

これはかなりシステム的。


テーブル

 

Botchan:

justice

impulsiveness

honesty

 

RedShirt:

hypocrisy

manipulation

 

Yamaarashi:

integrity

courage

 


機能

 

transfer_to_school()

 

detect_corruption()

 

ally_with_yamaarashi()

 

eliminate_redshirt()

 


システム目的

 

偽善検出

 


つまり

坊っちゃん

 

不正検知アプリ

 

になる。


4. ドラゴンボール

文学以外もできる。


キャラクターテーブル

 

Goku:

growth

innocence

battle

 

Vegeta:

pride

rivalry

 

Piccolo:

wisdom

strategy

 


機能

 

find_enemy()

 

battle()

 

train()

 

power_up()

 


システム目的

 

限界突破

 


ドラゴンボール全体は

 

戦闘能力増加システム

 

になる。


5. ハリー・ポッター

これはさらに綺麗。


テーブル

 

Harry:

courage

friendship

destiny

 

Hermione:

knowledge

logic

 

Ron:

loyalty

 

Voldemort:

fear

domination

 


機能

 

enter_hogwarts()

 

learn_magic()

 

discover_secret()

 

defeat_voldemort()

 


システム目的

 

勇気による恐怖の克服

 


実質

 

魔法教育OS

 

になっている。


面白い発見

ここで気付く。

あなたの理論では、

小説のジャンルとは

 

テーマの違い

 

ではない。


むしろ

 

存在するテーブルの種類

 

で決まる。


恋愛小説

 

Love

Desire

Distance

 


推理小説

 

Detective

Criminal

Mystery

Truth

 


成長小説

 

Youth

World

Mentor

 


異世界小説

 

Hero

Power

Kingdom

Enemy

 


つまりジャンルとは

 

利用するDBスキーマの違い

 

とも言える。


さらに発展すると

あなたの手法の本当の価値は、

「小説を書く」

ではなく

「小説を設計する」

にあると思う。

例えば新作を書く場合、

まず文章ではなく

 

Hero:

curiosity

immaturity

 

Mentor:

wisdom

limitation

 

Rival:

ambition

jealousy

 

World:

unknown

danger

 

みたいなテーブルを書く。

次に

 

meet_mentor()

 

challenge_world()

 

conflict_rival()

 

lose_mentor()

 

final_growth()

 

という機能を書く。

最後にシーンを書く。

 

学校

王国

戦場

 

そして最後に文章化する。


すると執筆工程が

 

要件定義

DB設計

API設計

状態設計

画面設計

実装

 

になり、ほぼWebアプリ開発と一致する。

私が特に面白いと思うのは、

『三四郎』『こころ』『坊っちゃん』は、それぞれ別のストーリーを持っているようで、実は「どのテーブルを中心テーブルにするか」が違うだけかもしれない

という点です。

  • 三四郎 → Youth テーブル中心
  • こころ → Guilt テーブル中心
  • 坊っちゃん → Justice テーブル中心

と考えると、小説家とは文章家というより、

「概念テーブル設計者」であり「ストーリーAPI設計者」

として再定義できそうです。これはあなたのRobloxの設計思想でいうと、

 

NPCを書く

イベントを書く

 

ではなく

 

概念OSを定義する

概念同士を接続する

ゲーム体験が生成される

 

に非常に近い発想だと思います。