Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ライセンス: このファイルは MIT License で公開されています。


執筆・文体ガイドライン

AIによる小説生成において、「あらすじ化」を防ぎ、読者を惹きつける「物語」を出力するためのガイドラインです。


1. 執筆の基本姿勢 (Show, Don’t Tell)

  • NG (あらすじ/説明): 「佐伯は焦りを感じた。」「会議は紛糾した。」
  • OK (描写): 「佐伯の手のひらに脂汗が滲んだ。心臓の音が耳元でドラムのように鳴り響く。」「『ふざけるな!』怒号と共に、大村が机を叩いた。コーヒーカップが跳ね、茶色い飛沫が資料を汚す。」
  • 指示: 感情語(悲しい、嬉しい、焦る)を極力使わず、身体反応、情景、会話、行動を通じて状況を描写すること。

2. フォーマットとリズム

  • ターゲット: ビジネスパーソン / 普段小説を読み慣れていない層。
  • 構成:
    • Web小説やライトノベルを意識した、読みやすい改行リズム。
    • 1段落は長くても3〜4行程度とし、頻繁に改行を入れる。
    • 会話文を多用し、テンポよく物語を進める。
  • 文体:
    • 視点: 三人称一元視点(シーンごとに視点人物を固定する)。翼と結衣で文体が異なる(Section 2-C参照)
    • 現代的でシャープな文体。比喩表現はビジネスシーンやIT用語など、世界観に合ったものを用いると効果的。
  • テンポの最優先原則 :
    • ビジネス小説の読者は「学び」を求めて読んでいる。描写が丁寧すぎて動きが少ないと読み疲れる。
    • 描写は必要最低限に。 五感描写は1シーンにつき冒頭の2-3文で十分。以降は会話と行動でテンポを作る。
    • 1シーン内に詰め込みすぎない。 1シーン=1つの出来事・1つの感情変化に集中する。

3. 出力単位と密度

🚨 絶対ルール: 1シーン=1ファイル

原稿出力は必ず「1シーン=1ファイル」で行う。1章を1回の出力でまとめて書くことを禁止する。

v14で「1章1ファイル」出力を行った結果、AIの1回出力制限(≒6,000字)が章全体の上限になり、 v13比で▲30,000字(▲27%)の大幅減となった。これは構造的な問題であり、二度と繰り返さない。

項目ルール
出力単位1シーン = 1ファイル(例: chapter_01/s01.md, chapter_01/s02.md
通常シーン4,000〜8,000字
[L]シーン最低5,500字、上限なし(内容が適正字数を決める。v15水準の7,000〜8,000字が必要ならその字数を与える)
統合全シーン完成後に chapter_XX/full.mdfull_manuscript.md に結合(後工程)
章合計目標通常章 15,000〜20,000字 / 重要章 20,000〜30,000字

基本方針

  • シーンの長さに下限は設けない。 テンポと内容の密度を優先する。
  • 目安: 1シーンあたり 4,000〜8,000文字。
    • 短い場面転換シーン: 2,000字でもよい
    • 佐伯との対話シーン [L]: 最低5,500字、上限なし。成功者の告白の神崎対話シーン(9,000〜21,000字)と同等の密度を目指す。What/Why/Howを必ず含むこと。app_design.md の設計内容を参照して書くこと
  • 密度の確保:
    • プロットの各要素(目的・障害)を消化するために十分な分量を割くこと。駆け足で進めない。
    • ただし「下限を満たすための水増し描写」は厳禁。

シーン数ルール

  • 1章あたりのシーン数に制限はない。 内容に応じて2〜6シーンを自由に設計する。
  • 各シーンはscenes.mdで定義された「変化」を1つ実現することに集中する。

2-A. 禁止反復パターン・固有感覚描写ルール

v16では「蛍光灯の白い光」「胸が締め付けられる」等の同一描写が複数シーンで反復され、文章密度が低下した。v15水準の描写密度を回復するため、以下のルールを設ける。

禁止反復パターンリスト

以下の表現は全編を通じて最大使用回数を制限する。同じ意味を伝える場合は別の表現を使うこと。

禁止パターン上限代替の方向性
「蛍光灯の白い光」全編1回空間の照明は固有の光源で描写(デスクライトの影、窓の光、スマホの明滅等)
「胸が締め付けられる」全編2回胸を使うなら「胸の奥が熱い」「胸骨の裏側が痛い」等の変奏
「息が詰まる」全編3回呼吸系:「息を吹き出せない」「喜管がつかえる」「浅い息が続く」
「拳を握りしめる」全編3回手系:「爪が掌に食い込む」「指先が白くなる」「テーブルの下で指を揃む」
「背筋が凍る」全編2回寒気系:「首筋が引きつる」「肌が粟立つ」「脇腹に冷たい汗」
「琩琥色の液体」(コーヒー)全編2回カフェの描写は五感のどれかで固有化(蛙の苦さ、泡の音、カップの重さ等)

固有感覚描写ルール

  1. 各シーンに固有の感覚描写を最低1つ設計する。 scenes.mdの各シーンに「描写ガイド」欄を設け、そのシーンでしか使わない五感描写を指定する
  2. 場面末尾は象徴的イメージで閉じる。 シーンのラスト1〜2文は、そのシーンの感情を凝縮した象徴描写で終わる
  3. 同じ感情を表す身体反応は、2シーン連続で使えない。 翼が2シーン続けて「拳を握りしめる」のは禁止

2-B. キャラクター発話パターン辞書

各キャラクターの発話に固有の「声」を与えるためのリファレンス。これは原稿執筆時の入力として参照する。

キャラ口調の特徴使う言葉使わない言葉例文
短文・断定的・反射的「だろ」「じゃないですか」丁寧すぎる敬語、「かもしれません」。佐伯への発話で「っす」不使用(「どうっすか」→「どうですか」、「ないっす」→「ないです」等)「それ、やります。明日から」
佐伯穏やか・問いかけ型・比喩が多い。コーチングモード/人間モードの使い分けあり(下記参照)「さ」「だよね」「どう思う?」「〜してみよう」「お前」(全編不使用)、「くん」付け(全編不使用)。コーチングモードでは命令形不使用「ちょっと聞きたいんだけどさ、それって——誰のためにやってるの?」
結衣丁寧・配慮型・言いよどみが多い「ですよね」「すみません」「ただ」断定口調、「それは違う」「それ、私がやっておきます……ただ、少しだけ教えてもらえますか」
涼太論理的・反論型・厚紳士的敬語「ですが」「論理的には」「データ上は」感情的な言葉、「とにかく」「その判断の根拠をお聞かせいただけますか」
沙織控えめ・同意型・言葉が少ない「はい」「わかりました」自分からの提案、長文「」(沈黙、小さくうなずく)
穏やか→支配的・裏表がある「そうだよね」「俺のこと」「結衣がそれでいいなら、いいんじゃない? ……でも、それって本当に結衣のため?」
高城簡潔・成果志向・温かさが少し「結果を出せ」「お前には期待してる」感情的な励まし「このプロジェクト、任せる。やれるか?」

運用ルール:

  • 上記は「基本設定」。感情が高まるシーンでは意図的に崩す(翼が丁寧になる、涼太が感情をぶつける等)
  • ただし穋りぎな口調は疲れるので、口調の変化は重要場面に絞る
  • 佐伯の口調は全編通じて最も安定。人間モードへの切替は限定的場面のみ(下記参照)

佐伯の口調設計

一人称:

  • 原則「僕」。翼との通常対話・コーチングモードでは常に「僕」
  • 「俺」許容: 佐伯が自身の過去の失敗・痛みを語る感情的シーンのみ(Ch.7後半、Ch.11告白等)
  • 「私」は使用しない(報告書等の文書内を除く)

小道具:

  • キャップ付きボールペン(ブルーブラックインク)。万年筆はNG
  • 原稿内では「ペン」と表記。「ペン先」「ペンのキャップ」等。

呼び方(2ステップ):

  • Ch.1-2: 「高橋さん」(初対面〜信頼構築初期)
  • Ch.3以降: 「翼」(翼からの提案で切替。Ch.3冒頭付近で自然なトリガーを配置)
  • 「お前」全編不使用。「くん」付け全編不使用

口調モード:

モード適用範囲命令形特徴
コーチングモード全編(佐伯がコーチとして機能している場面すべて)不使用→誘い/問いかけに変換穏やか・対等な誘い。Ch.3-4はさらに柔らかめ
人間モード限定的(佐伯がコーチの枠を外れた感情的頂点のみ)許容率直な断定・命令形。Ch.11 s02訪問、Ch.11 s04告白等

コーチングモードの変換パターン:

原文パターン変換後
「〜してみろ」「〜してみよう」
「〜しろ / 書け / 出せ」「〜してみて / 〜してみよう」
「〜するな」「〜してないか?」
「〜だろ(詰め)」「〜だろう / 〜じゃないかな」

人間モードの例(維持): 「嘘をつくな」「飲め」「言ってないだろ」— これらは物語の感情的頂点を担うためそのまま残す

翼の佐伯への口調

  • 佐伯への発話(対面・LINE問わず)で**「っす」不使用**
  • 基本は丁寧語(「です/ます」基調)。関係深化に応じた自然な崩れはOK
  • 他キャラ(涼太等)への発話では「っす」使用可

2-C. 翼・結衣の視点文体設計

背景: v15 Part 1では、結衣パートが「三人称の形式を取りながら一人称独白を多用する」文体で書かれており、翼の三人称限定視点と自然に対比が生まれていた。v17ではこの方向性を設計として明示し、再現性を確保する。

基本方針

翼のシーン結衣のシーン
基調三人称限定視点三人称+一人称独白を多用
一人称侵入感情クライマックスのみ(1シーンに0〜1箇所)常時。ダッシュ付き独白が結衣パートの基本文体
独白の調子断定的・反発的自問的・自己否定的
独白の例「——あの人に何が分かるんだよ」「——毎回、相手が悪いということか」「——私が甘えてるだけ」「——私、何のためにこんなに頑張ってるんだろう」
思考の構造問いを閉じる(怖いから)問いが浮かぶ→蓮/義務で自動打ち消し→スケジュールで上書き

OS理論との対応

  • 翼の三人称: 自分のOSを客観視できていないことを、三人称の「外側から見ている」形式が皮肉として描く
  • 結衣の一人称寄り: 世界が全部主観で構成されている(他者の評価=自分の存在価値)感覚を、一人称独白の多さで体感させる

Part進行に伴う変化(クロスオーバー)

Part結衣
Part 1三人称基調。独白は少ない一人称独白が頻繁。内面の声が地の文に侵入する
Part 2 中盤クライマックス(八つ当たり等)で一人称侵入が増加自覚が進むにつれ一人称侵入が徐々に減少
Part 3再び三人称に安定(OSの書き換えが進んだ)三人称が増え、独白は内省的・穏やかになる

クロスオーバーの意義: Part 2中盤の交差点(翼の一人称増加 ⁄ 結衣の一人称減少)が、二人のOS変容の対称性を読者に体感させる。


4. シーケンス設計原則

基本シーケンス: 危機→渇望→対話→実践→次の危機

成功者の告白の構造分析から、ビジネス小説のメリハリは「シーンタイプの分類」ではなくシーケンス(流れ)の設計によって生まれることが判明した。以下の原則を各章の設計に適用する。

原則1: 学びは渇望の後に来る

  • 翼・結衣が壁にぶつかり、「答えが知りたい」「どうすればいいかわからない」と感じた後に、佐伯との対話(または翼から部下への「翻訳」)を配置する。
  • 先に学びを提示し、後から実践させるのはNG。「もがき→渇望→対話(学び)→不完全な実践」の順序を厳守する。

原則2: 温度差でメリハリを作る

  • 隣接するシーン間で感情温度の落差を設計する。
  • 高揚→絶望、日常→危機、緊張→弛緩 のコントラストが読者を引き込む。
  • scenes.mdの各シーンに「感情温度 (-5〜+5)」を明記し、隣接シーンの温度差を確認する。

原則3: ドラマ65% / 学び30% / メタ5%

  • ドラマ (65%): 人間関係の衝突、仕事上の失敗、私生活の崩壊 — 物語を駆動するイベントと感情
  • 学び (30%): 佐伯との対話、フレームワークの提示、気づきの言語化 — ビジネス書としての価値
  • メタ (5%): まえがき・エピローグでの著者の語り — 物語と読者をつなぐ架け橋
  • この比率は全体の目安であり、各章の性質によって変動する。第1部序盤はドラマ多め、佐伯対話回は学び多め、でよい。

原則4: 対話シーンを厚く描く

  • 佐伯との対話シーン [L] は、各章で最も重要なシーン。十分な文字数を割く。
  • 成功者の告白における神崎との対話は毎回10-15ページ(文庫)=約4,000-6,000字。
  • 厚く描く ≠ 冗長に描く。 対話の密度が高いことが重要。

[L]マーキングルール

学びの核心を含むシーン[L] マークを付ける。これにより、ドラマシーンと学びシーンの配分が可視化される。

定義

  • [L] = Learning Scene — そのシーンの主目的が「読者に学び(フレームワーク、気づき、理論)を伝えること」であるシーン
  • 具体的には: 佐伯との対話、フレームワークの解説、翼・結衣の言語化の瞬間

ルール

  1. scenes.mdのシーン見出しに [L] を付記する(例: ### Scene 3 [L]: 佐伯との初回セッション
  2. plot.mdでも学びシーンを明示する
  3. 1章あたり [L] シーンは原則1-2個。多すぎると「座学」になる
  4. [L] シーンの前に必ず「もがき」「渇望」の描写があること

学習コンテンツ理解度ガイドライン

背景: 本作の学習コンテンツには「PDCAの回し方(How)」のような実践レベルのものから「なぜPDCAが機能するのか(Why深掘り)」のような抽象度の高いものまで幅がある。難テーマを提示する際に翼が即座に理解してしまうと、読者が置いていかれる。逆に、すでに読者が理解した概念で翼がいつまでも迷っていると退屈する。翼の理解速度を制御するルールを定める。

理解度レベル定義

レベル名称翼の状態描写の指針
L1体験的理解やり方を知って「試せる」状態。理由は分かっていない「こうやればいいんですね」→ すぐ行動に移す。Howは掴むがWhy/Whatは表面的
L2構造的理解なぜそれが機能するか(Why)の構造を言語化できる状態佐伯の問いかけに対して自分の言葉で説明を試みる。まだ不完全だが核心に近い
L3応用的理解別の状況にフレームワークを転用できる状態第2部で部下に教える場面。佐伯の言葉をそのまま使うのではなく「翻訳」して相手に合わせられる
L4統合的理解複数のフレームワークが自分の中で繋がり、体系として機能する状態第3部でPDCA/GROW/Growth Mindsetの限界を感じ、それらを超える枠組みを自ら掴む

パート別の到達目安

パート主要FW[L]シーン終了時の到達レベル数シーン後の到達レベル
第1部PDCAL1(体験的理解)→ 実践→失敗→修正L2(Why深掘りで構造的理解に到達)
第1部自分のOSL1(自分の行動パターンに名前がつく程度)L2(佐伯の問いかけで「なぜ自分はこう動くのか」に気づく)
第2部PDCA(継続)L3(部下を育てる過程で、自分の言葉でPDCAを教える。「翻訳」を通じて応用的理解に到達)
第2部GROWL1→L2(佐伯との対話で構造的に理解)L3(部下に対して自分の言葉で運用)
第2部Growth MindsetL1→L2L3(マネジメント場面での応用)
第3部エフェクチュエーションL1(体験的に「こうするしかなかった」)L2(佐伯の言語化支援で構造的理解に到達。実践レベル(L3)は本作内では到達しない)
第3部PDCA(統合)L4(PDCAの本質的限界(Causal思考)に直面し、エフェクチュエーションと統合することで、PDCAが自分の体系の一部として機能する状態)
第3部成人発達理論—(翼に直接教えるFWではない)L2相当(翼の変容を佐伯が言語化することで、読者は構造的に理解する。翼自身の実践的応用は本作の先にある)

第3部FWの到達レベルについて: PDCAは3部をかけてL1→L4に到達するが、第3部で新たに登場するエフェクチュエーションと成人発達理論はL1→L2が現実的な到達レベル。1つの部だけでL3(応用的理解)に至るには実践と失敗のサイクルを描く尺が足りない。この「まだ道半ば」感が物語のリアリティと余韻を担保する。翼はすべてを悟った完成形ではなく、成長の途上にある人間として物語を終える。

描写ルール

ルール1: [L]シーンで一発理解させない

  • 佐伯がWhat/Why/Howを厚く教えた直後の翼の状態はL1(体験的理解)が基本
  • 翼は行動型なので「やり方」を掴むのは速い。しかし「なぜ」の深い理解には時間がかかる
  • 特にWhy深掘り(「PDCAの本質は仮説精度の向上である」等)は、翼がL1→L2に到達するまで複数シーンを要する

ルール2: 「分かったつもり→実践で崩れる」サイクルを描く

  • 翼が「なるほど、分かりました」と言った後、実践場面で微妙にズレた適用をする
  • このズレこそが読者にとっての学習機会。「ああ、そこじゃないんだ」と読者が気づく
  • 佐伯は次の対話でそのズレに触れる:「前回やってみてどうだった?」→翼が自分のズレに気づく

ルール3: 第2部の「翻訳」で理解が深まる

  • 翼がL2(構造的理解)からL3(応用的理解)に到達する契機は、部下に教えようとする場面
  • 人に教えることで自分の理解の穴が見える構造を描く
  • 翼が部下に説明しようとして言葉に詰まる → 自分の理解が不十分だったと気づく → 佐伯に壁打ち → 再度部下に伝える

ルール4: Whyの難易度を段階設計する

  • 同じFW内でもWhyの深さに段階がある。例:PDCA
段階Whyの深さ翼の理解タイミング提示方法
表層Why「仮説がないと闇雲な行動になるから」[L]シーン内で即理解(L1)佐伯の問いかけ→翼が自分で気づく
中層Why「PDCAの本質は仮説精度の向上。精度が上がれば再現性が生まれる」数シーン後の実践→失敗→振り返り翼が失敗を佐伯に報告する中で言語化される
深層Why「PDCAはCausal(因果論的)思考そのもの。不確実性の高い世界では機能しない」第3部で初めて直面する起業の失敗体験を通じて体感。佐伯がエフェクチュエーションの文脈で回収

ルール5: 読者の理解ペースと翼の理解を同期させる

  • 理想は「翼より少し先に読者が気づく」状態。読者が「あ、翼まだ分かってないな」と感じる瞬間がある
  • しかし読者を置き去りにしない。佐伯の解説(ティーチングモード)で読者にはL2の材料を提供しつつ、翼はまだL1にとどまる、という構造が基本
  • 読者が翼と一緒にL2に到達してしまう場合は、それでもよい。重要なのはL1で止まらないこと

5. 各シーンのチェックポイント

生成時に以下の要素が含まれているか確認する。

  • Context: 誰が、どこで、何をしているか明確か?
  • Goal: 主人公(視点人物)の「このシーンでの目的」は明確か?
  • Conflict: 期待通りにいかない「障害」や「葛藤」が描かれているか?
  • Reaction: 障害に対するキャラクターのリアクション(思考・感情・身体反応)があるか?

完了時チェックフロー(各シーン)

  • Show, Don’t Tell: 感情語の直接使用を避け、身体反応・行動・情景で描写しているか?
  • テンポ: 冗長な描写がないか? 読み疲れないか?
  • コーチング対話テンプレート([L]シーン): 佐伯が応援型コーチとして振る舞っているか? 詰めていないか?
  • シーソー構造: 仕事面と私生活面の「干渉」(因果関係)が描写されているか?
  • シーケンス: もがき→渇望→対話(学び)→実践 の順序が守られているか?
  • メタ表現の排除: 「Ch.3」等のメタ視点の用語が原稿内に混入していないか?

6. ワークフローと参照ファイル (Global Workflow)

品質と整合性を担保するため、以下のパイプラインで工程を完了させること。 詳細は 00_v17_plan.md を参照。

設定ファイル体系 (01_settings/)

ファイル役割
characters.md人物設定
os_theory.mdOS理論
storyline.md物語設計(テーマ・構成・ルール・前提条件)
style_guide.md文体ガイド(本ファイル)
app_design.mdアプリ設計(フレームワークWhat/Why/How + 教え方原則)

生成パイプライン

  1. 壁打ち: app_design.md のフレームワークWhat/Why/Howを人間が確定
  2. シナリオ生成: settings全体 → 02_story/scenario.md
  3. プロット生成: scenario + settings → 02_story/plots/chapter_XX.md
  4. シーン設計: plots + settings → 02_story/scenes/chapter_XX.md[L]マーキングを含む)
  5. 原稿執筆: scenes + settings → 03_manuscripts/chapter_XX/scene_XX_YY.md(🚨 1シーン=1ファイル)
  6. 推敲・統合: 通読→伏線整合性→[L]シーンチェックリスト検証→シーケンスチェック→統合ファイル生成
  • ルール: 執筆時は必ずシーン詳細(ビートシート)を参照し、そこで定義された「変化(Value Change)」と「理論的意図(OS)」を忠実に再現すること。

7. コーチング対話テンプレート

佐伯のコーチングシーンは物語の核心部分であり、「成功者の告白」における神崎の対話スタイルを準拠モデルとする。佐伯は応援者であり、翼を追い込む存在ではない。

v17 制約: 佐伯のコーチング対話の相手は翼のみ。結衣・涼太・沙織との直接1on1は行わない。第2部では翼が佐伯から学んだことを自分の言葉で部下に伝える「翻訳」構造。詳細は app_design.md Section 4 参照。

標準フロー(6ステップ)

Step名称佐伯のアクション翼のリアクション描写のポイント
1受け止め相手の状況を穏やかに聞く。「最近どう?」「何があった?」と、対等な立場で会話を始める構えながらも、佐伯の穏やかさに少し安堵する佐伯は相手のペースに合わせる。急かさない
2問いかけ相手が考えたことのない角度から質問する。「それって、誰のために?」「本当にそう思ってる?」表面的な回答(「特に考えてなかった」「普通にやっただけ」)穏やかだが核心を突く質問。佐伯の口調は終始柔らかい
3寄り添い相手の抵抗や防御を否定しない。「そう感じるのは自然だよ」「俺もそうだったから」と共感を示す防御が少し緩む。でもまだ本音は出ない佐伯が自分の経験を少しだけ開示することで、対等な関係を築く
4深掘り相手が落ち着いた状態で核心に触れる。「じゃあ聞くけど、本当のところは?」動揺、沈黙、あるいは感情の噴出最も重要なステップ。身体反応を丁寧に描写すること。佐伯は追い込まない — 相手が自分で扉を開けるのを待つ
5沈黙佐伯は黙って待つ。相手が自ら気づく時間を与える内省、過去の記憶のフラッシュバック、自問会話を止め、内面描写に切り替える。沈黙の「重さ」を描く
6解説気づきを言語化し、フレームワークのWhat/Why/Howを対話の中でしっかり解説する。「ひとついい方法があってさ」「これを知ってると全く変わる」佐伯の解説で理解が深まる。具体的数字や図解で腹落ちするヒントだけで終わらず、仕組み・理由・使い方まで教える。 図解・数字・実演を交えて、読者が翌日職場で試せるレベルに

佐伯の対話におけるNGパターン

NG理由代替
「お前は何から逃げている?」(初対面で)攻撃的。応援者の立場ではない「何が一番気になってる?」等の柔らかい切り口から
「それでお前は満足なのか?」(詰め口調)詰めるのは佐伯の役割ではない「自分ではどう思う?」と問いかけ、相手に委ねる
佐伯が一方的に講義する対話なく一方通行は退屈する対話のラリー(問い→反論→解説→納得)で厚く教える。厚く書くこと自体はNGではない
「答えは自分で見つけろ」(突き放す)応援者は突き放さない「一緒に考えよう」「ヒントを出すから、そこから考えてみて」
佐伯が声を荒げる/怒るキャラクター矛盾佐伯が動揺するのは黒沢関連の話題が出た時のみ。それ以外は穏やか

対話テンプレートの運用ルール

  1. 佐伯は応援者 — 相手の味方であることが常に伝わる態度。厳しいことを言う時も「あなたのことを思って」が透ける
  2. 佐伯も不完全 — 特に翼の言葉が自分の過去(黒沢との決裂)に触れた場合、穏やかさの裏にある痛みが一瞬漏れる
  3. 毎回異なるテーマ — 同じフローでも、扱うテーマ(成果、他者、組織、自分自身)によって深掘りの方向は変わる
  4. 対話の「後」を描く — コーチング直後ではなく、数日後に翼が行動で示す(Show, Don’t Tell原則)。第2部では翼が部下に「翻訳」する場面がこれにあたる
  5. 対話シーンは厚く教える — [L]シーンではWhat/Why/Howを必ず含む。最低5,500字、上限なし。成功者の告白の神崎のように、対話のラリーの中で厚く解説する
  6. 黒沢の描写原則 — 黒沢と明らかに思える人物に対しては「壊れた」ではなく「失った」で一貫させる。佐伯自身が壊れた(一般論含む)、部下が壊れた(黒沢以外の部下一般)はOK。佐伯と黒沢の関係は対等であり、「救う/壊れる」の上下関係ではない

8. Crisis → Learning チェック項目

「成功者の告白」の分析から導かれた原則:ノウハウは「危機の渦中」で提示されてこそ、読者に刺さる。各章の執筆時に以下をチェックすること。

各章必須チェックリスト

  • 危機は具体的か? — 抽象的な「壁」ではなく、特定の人物・場面・状況による具体的な痛みが描かれているか
  • 危機は主人公にとって「自分ごと」か? — 他人の問題ではなく、自分のOS(行動原理)が原因で起きた危機であると認識できるか
  • ノウハウは「救命ロープ」として機能しているか? — 「知っておくと便利」レベルではなく「これがなければ溺れる」レベルの切迫感で提示されているか
  • ノウハウ提示の前に、十分な「もがき」が描かれているか? — 読者が「答えを知りたい」と感じるだけの焦燥感を蓄積できているか
  • ノウハウ提示後に「即座の解決」をしていないか? — 知識を得てもすぐには使いこなせない「不完全な実践」の過程が描かれているか
  • 知識の出典は自然か? — 佐伯がいきなり講義するのではなく、対話・実体験・失敗の振り返りの中で自然に浮かび上がるか

NGパターン(避けるべき構成)

パターン問題対策
「座学型」佐伯がホワイトボードで一方的に講義する対話テンプレートに沿い、翼の具体的な失敗を素材に対話で引き出す
「万能薬型」ノウハウを知った途端に問題が解決する知識→実践→失敗→修正→成功のサイクルを描く
「観客型」翼・結衣が冷静に学んでいる感情的な抵抗→崩壊→再構築のプロセスを経る

9. シーソー構造チェック項目

「成功者の告白」の設計原則:仕事の上昇と私生活の崩壊は表裏一体。各章のプロット・シーン設計時に以下をチェックすること。

各章必須チェックリスト

  • この章で仕事面は上昇しているか、下降しているか? — scenario.mdの「シーソー対比表」と一致しているか確認
  • 仕事面と逆方向の私生活イベントが描かれているか? — 仕事が上がっているなら私生活に亀裂が入る(またはその逆)
  • シーソーの「支点」は何か? — 仕事と私生活を繋ぐ因果関係は明確か
  • サブストーリーの進行がメインストーリーと干渉しているか? — 私生活の出来事が仕事のパフォーマンスに影響する、またはその逆
  • 読者が「両方を追いたい」と感じる構成か? — 仕事パートだけ、私生活パートだけで完結していないか

注意事項

  • 毎章シーソーが作動する必要はない — 特に第3部終盤では仕事と私生活が同時に上昇する「統合」の状態になってよい
  • シーソーの「落差」が物語のエンジン — 落差が大きいほど読者の感情が動く

10. OS理論の描写への反映 (Theory Integration)

キャラクターの行動や思考を描写する際は、os_theory.md および characters.md の定義に従うこと。

  • 思考依存 (佐伯など): 行動の前に「予測」「リスク計算」「定義づけ」を行う描写を挟む。
  • 行動依存 (翼など): 思考する前に「体が動く」「口が出る」描写、あるいは沈黙(思考)に耐えられない焦燥感を描く。
  • 視点人物のフィルタ: シーンの視点人物(POV)のOSを通して世界を見ること。例えば「他者本位」の結衣視点では、常に「相手の顔色」や「場の空気」が描写の優先順位高くなる。

v16 拡張:OS型の描写タイミング

v16ではOS型(行動型/思考型、自分本位/他者本位)を第1部前半から翼の行動様式と絡めて提示する。描写上のルールは以下の通り。

パートOS型の描写レベル読者が得るもの
第1部前半翼の行動パターンとして自然に描写。佐伯が「行動型」と名指しする場面あり「人の行動には型がある」というレンズの獲得
第1部後半翼が自分のパターンを自覚し始める。佐伯が思考型との対比を示唆OS自己認識の重要性
第2部4象限(行動型/思考型 × 自分本位/他者本位)が部下3人で揃う。翼が各メンバーのOSの違いに気づく他者のOSを読み取るマネジメントスキル
第3部翼のOS自体が変容する(行動型の暴走→バランス)OSは固定ではなく更新可能であるという認識

描写上の注意:

  • 第1部前半では「OS型」「行動型」等の用語を佐伯が自然に使い始める。ただし4象限の全体像はまだ提示しない
  • 第2部で部下のOSを描写する際、翼がすぐに「こいつは思考型だ」と類型化するのはNG。翼は自分の言葉で「なぜこいつの言動が理解できないか」を悩み、佐伯との対話の中で徐々にOSの違いに気づく(理解度ガイドラインのL1→L2プロセス)
  • 各キャラクターのOSは characters.md の定義に従い、行動・思考・対人反応を通じて一貫して描写する

Created: 2026-02-17 Updated: 2026-02-21 Version: v17 (壁打ち確定)