作者が知っている世界を、読者に全部説明しなくていい

設定を考えるのが面白い。すると、考えたことを全部説明したくなる。

2026年9月20日、書きながら気になったのは、その塩梅だった。世界の仕組みを細かく決めるほど、読者にも正確に理解してほしくなる。でも、僕が設定を発見する楽しさと、読者が物語を発見する楽しさは、同じ順番では生まれないのかもしれない。

そこで執筆メモに残したのが、Author layerとReader layerを分ける考え方だ。完成した作品から導いた法則ではなく、これから自分の文章で試すための方針になる。

世界の仕組みと、その世界で起きること

作者の側には、制度、地理、技術、歴史、計算モデルがある。読者の側には、登場人物が見て、選んで、困る場面がある。

この二つを分けると、「設定を説明する場面をどこに入れるか」という問いが少し変わる。「この設定のせいで、いま誰の選択が変わるのか」と考えられる。

たとえば、次はこの考え方を試すための架空の短い場面だ。

「往復で頼める？」
「片道しか売っていません」
「帰りは？」
係員は、もう一度同じ欄を指した。

ここでは、帰れない理由をまだ決めていない。制度なのか、技術なのか、一時的な故障なのか。でも、帰り方が問題になっていることは分かる。

設定の全貌は不明でも、その場の困りごとは見える。この二つを分けて制御できるのではないか。

メモでは「作者は100知っていても、その場面では3だけ渡す」という言い方が残った。これは測定した比率でも、文章の97％を削るという指示でもない。作者が持つ情報量と、一度に読者へ渡す量を同一にしないための比喩だ。

説明を削るときには、次の三つを問いにしてみたい。

どれにも当たらなければ、設定資料に戻してよい可能性がある。一方、知らないせいで人物の決断が唐突に見えるなら、説明を後ろへ送るだけでは解決しない。

「なぜ帰れないのか分からない」は謎になり得る。「この人物は何をしようとしているのか分からない」は、場面を追えない理由にもなる。曖昧さを全部同じものとして扱わないでおきたい。

ソフトウェアの実装とインターフェースに置き換えると、考えやすいところがある。

作者側の実装は、世界の内部で何が可能かを決める。読者へ渡すインターフェースは、人物の行動と、その結果として見えるものになる。内部の仕組みをすべて読まなくても、何が起きたかは追える。

ただし、ここでアナロジーは一度止める必要がある。ソフトウェアのAPIなら、呼び出す前に仕様が明らかなほうがよいことが多い。物語では、仕様を途中で推測したり、見立てを変えたりすること自体が楽しみになる。

だから、読者に渡すのは単純に薄い説明ではない。手掛かりの順序だ。最初の違和感が、後の場面で別の意味に見えてくるように配置したい。

ただし、作者が内部設定を作り込んでいるだけで、その効果が保証されるわけでもない。本文に手掛かりがなければ、読者には伝わらない。

自分のメモには、数理モデルやシミュレーションも並行して作る「Executable SF」という方向がある。これはまだ制作方針で、完成した仕組みではない。

作者用の資料には、細かな条件と検証を残す。小説には、その条件の中で暮らす人物を書く。興味を持った人が補足を開ける形にできれば、本文だけで全部を説明する必要はなくなる。

とはいえ、補足を読まないと登場人物の決断が理解できないなら、境界の引き方を見直したい。補足は世界をもっと知る入口であって、物語を理解するための不足分を全部預ける場所にはしたくない。

試したいのは、設定説明を先に置く版と、人物の行動から入る版を作ることだ。

初めて読む人には、その場面で人物が何を望み、何が妨げになり、世界について何を推測したかを聞く。説明を減らしても前二つが伝わるなら、世界の仕組みを後に回せる余地がある。逆に人物の行動が意味不明になるなら、必要な情報まで削っている。

この読み比べはまだしていない。現時点で残しておきたいのは、設定を減らすという決意ではなく、設定と本文を分けて持てるという見通しだ。

作者が知っていることは、全部を説明しなくても、人物の選べることと選べないことの中に残せる。

筆者の執筆メモ「2026.09.20」「Author layer -> Reader layer」「執筆テクニックとして見つけたこと01」（2026-09-20、非公開）。起点の疑問、当日の記録、AIとの壁打ちから得た執筆案を参照。確認日：2026-09-20 JST。
作者層／読者層、三つの確認質問、APIとの比較は、本ノートで試す創作上の枠組み。効果を実証した理論や、特定作家の技法の歴史的説明ではない。
片道切符の会話は本ノートの説明用に作った架空の例。読者による比較評価は未実施。