文字数・章数・Save the Cat 15ビートをまとめて換算するまで
今回作ったのは、小説の三幕構成ツールです。
総文字数や章数を入れると、
第一幕・第二幕・第三幕の区切りや、
Save the Cat の15ビートが、だいたいどのあたりに来るのかをまとめて見られるツールです。
これは、ただの計算機ではありません。
自分で小説を書いていると、途中でこういうことが起こります。
今の話、まだ序盤なのか。
もうミッドポイントを過ぎているのか。
このままだと、終盤が駆け足にならないか。
章数で割ると、転換点は何章目くらいなのか。
こういう「全体の地図」が欲しくなるんです。
プロットを考える時もそうだし、
書き始めてから全体のバランスを見直したい時にも使いたい。
なので今回は、創作の全体設計を見るためのツールを作りました。
前回作った「文字数・読了時間・会話比率チェッカー」が、文章の局所を見るツールだとしたら、
今回の三幕構成ツールは、作品全体の骨格を見るツールです。
最初に決めたのは、「何を解決するツールなのか」
個人開発では、最初にここを決めないと、だいたいブレます。
今回のツールで解決したかったのは、
構成の正解を出すことではありません。
正解を出すのは無理です。
物語はそんなに単純ではないので。
今回やりたかったのは、
全体のペース感を、ざっくり可視化すること
です。
ここを決めたことで、かなり作りやすくなりました。
つまりこのツールは、
- あなたの作品を自動で面白くするものではない
- プロットを代わりに考えてくれるものでもない
- でも、全体のバランスを見る地図にはなる
という立ち位置です。
この「何をしないか」を最初に決めるのは大事です。
AI時代は特にそうです。
コードは速く書けるようになったので、
気を抜くと機能を盛りすぎて、逆に使いにくいものができます。
だから最初に、
このツールは地図であって、答えではない
と決めました。
なぜ三幕構成と Save the Cat を一緒にしたのか
ここも、最初に考えたポイントです。
三幕構成だけでも、それなりに使えます。
起承転結より、物語の転換点を意識しやすいですし、
序盤・中盤・終盤の配分を見るだけでもかなり役立ちます。
ただ、それだけだと少し粗い。
第一転換点。
ミッドポイント。
第二転換点。
このあたりは見えても、
中盤のどこで遊び、どこで落とし、どこで反転させるかまでは見えにくいです。
そこで Save the Cat を重ねました。
Save the Cat は15ビートに分かれているので、
三幕構成より細かい地図になります。
しかも、ざっくりした位置の目安もあるので、
ツールに落とし込みやすい。
私自身、前から Save the Cat は面白いと思っていました。
ゲームや小説の構成を考える時にも使えるし、
「とっ散らかる前に骨組みを作る」という意味でかなり実用的です。
なので今回は、
大きな地図としての三幕構成
細かい目安としての Save the Cat
この二段構えにしました。
仕様は、最初に言葉で決めた
今回はここが一番大事でした。
AIにいきなり「三幕構成ツールを作って」と言っても、
一応それっぽいものは出てきます。
けど、だいたい微妙です。
なぜかと言うと、
AIはコードは書けても、
何を見せると人間にとって使いやすいか
までは勝手に決めてくれないからです。
なので私は、まず仕様を言葉で決めました。
今回の仕様は、だいたいこうです。
まず、入力は広めに取る。
総文字数だけでなく、ページ数、語数、章数でも使えるようにする。
次に、結果は三層に分ける。
一層目は三幕構成。
二層目は主要転換点。
三層目は Save the Cat の15ビート。
さらに、
「標準」「導入速め」「導入じっくり」みたいなプリセットを入れる。
最後に、結果を見た後にメモしやすいよう、
コピー用の要約も出す。
この順に決めていくと、
作るものの輪郭がかなりはっきりします。
個人開発で大事なのは、コードを書く前のこの時間です。
ここが曖昧だと、
AIに何度修正させてもズレます。
逆にここが固まっていると、
AIはかなり強いです。
AIには、実装を速くしてもらった
今回も、AIにはかなり助けてもらいました。
今回の使い方は、だいたいこんな感じです。
まず私が、
「入力はこれ」
「出力はこれ」
「見た目はこう」
「このツールの役割はここまで」
を言語化する。
次に、その仕様をもとに、
AIに PHP と JavaScript と CSS のたたき台を書いてもらう。
そのあと、自分で触る。
ここが大事です。
触ってみると、必ず違和感が出ます。
章数換算は便利だけど、表示が細かすぎる。
ビートの一覧は正しいけど、ぱっと見で頭に入ってこない。
入力欄が多すぎて、最初にどこを触ればいいか分かりにくい。
そういう違和感を見つけて、
またAIに修正させる。
つまり、
仕様は人間が決める
初速はAIに出してもらう
違和感を取るのは人間がやる
この役割分担です。
前回の文章分析ツールでも思ったのですが、
AI時代の個人開発では、
コーディング力そのものより、
仕様を切る力の方が重要になってきている気がします。
実装でやったことは、実はかなり地味
ツールの中身は、派手なAI技術ではありません。
むしろ地味です。
やったことを分解すると、こんな感じです。
1. まず割合を決める
三幕構成は、ざっくり 25 / 50 / 25 を基本にする。
つまり、序盤25%、中盤50%、終盤25%です。
Save the Cat は、15ビートの位置をパーセントで持つ。
たとえば Midpoint は 50%、All Is Lost は 75%、Break Into Three は 80% あたり、といった具合です。
ここをまず、ツールの内部データとして持たせました。
2. それを文字数や章数に変換する
次に、その割合を実際の作品サイズに落とします。
総文字数が8万字なら、
25%地点は2万字。
50%地点は4万字。
75%地点は6万字。
章数が20章なら、
25%地点は5章前後。
50%地点は10章前後。
75%地点は15章前後。
こういう換算ですね。
実装としては単純です。
でも、実際に使う時に一番ありがたいのはここです。
頭では分かっていても、
実数に直して見ると急に現実味が出ます。
3. 表示を「理解しやすい順」に並べる
これも地味ですが大事です。
技術的には、最初から15ビート全部を表に出すだけでも作れます。
でもそれだと、人は少し疲れます。
なので、
最初に三幕構成。
次に主要転換点。
そのあとに15ビート。
という順にしました。
個人開発では、
全部見せることより、
どの順で見せると分かりやすいか
の方が重要だったりします。
AIは一覧を出すのは得意です。
でも、人間の理解の順番を設計するのは、まだこちらの仕事です。
「正確さ」と「実用」のどちらを取るか
今回、一番迷ったのはここでした。
たとえば Save the Cat のビート位置は、
本によって若干表現が違ったり、
映画・小説・漫画で感覚がずれたりします。
しかも作品ごとに崩し方もある。
つまり、厳密にやろうとすると、
「ケースバイケースです」が増えていきます。
でも、それを全部入れ始めると、ツールが重くなる。
逆に単純化しすぎると、
今度は使う人が「これが絶対の正解なのか」と誤解するかもしれない。
このバランスはかなり悩みました。
最終的には、
厳密な構成診断ツールではなく、設計の目安ツールにする
と割り切りました。
この割り切りは大事です。
個人開発では、
100点を目指して終わらないより、
85点で実用になるものを出した方が強い。
この感覚は、前回の文字数チェッカーでも同じでした。
完璧な会話比率判定より、まず使える線を見つけて出す。
今回も、その延長線上にあります。
どこまでAIに任せて、どこから自分で決めるか
この話は、これから個人開発する人にかなり大事だと思います。
今回のようなツールだと、AIに任せやすいのはこの辺です。
- フォームの土台を作る
- 計算ロジックを書く
- 表の表示を整える
- レスポンシブ対応を入れる
- コピーボタンなどの補助機能を付ける
逆に、自分で決めた方がいいのはこの辺です。
- このツールは誰の何の悩みを解くのか
- どの入力だけに絞るのか
- どの数値を最初に見せるのか
- これは目安なのか、診断なのか
- どこで止めるのか
この境目を間違えると、
AIを使っても速くなりません。
逆に、ここをちゃんと分けられると、かなり速くなります。
私は最近、AIは「実装者」というより、
優秀な試作係みたいなものだと思っています。
一発で完成品を出す存在ではなく、
こちらが方向を示した時に、
速くたたき台を出してくれる存在です。
このツールを作って見えたこと
今回のツールを作っていて改めて思ったのは、
書く人向けのツールは、個人開発とかなり相性が良い
ということです。
なぜか。
自分がそのままユーザーになれるからです。
私は小説も書くし、ブログも書く。
だから、「ここが見たい」「ここが足りない」が分かる。
この距離感は強いです。
個人開発では、
大きな市場を狙うのも一つの手ですが、
まずは自分が深く分かる問題から作るのがやはり強いと思います。
しかもAI時代は、小さいけれど実用的なツールを、
前よりずっと速く形にできます。
だからこそ、
「自分が本当に使うか」
は、かなり重要な軸になります。
同じようなツールを作りたい人へ
最後に、今回の経験をかなり単純化して言うと、
手順はこうです。
まず、
解く問題を一つに絞る。
次に、
その問題に効くフレームワークを一つ選ぶ。
そのあと、
フレームワークを数値に変換する。
そして、
入力欄と結果表示を最小構成で作る。
最後に、
自分で触って違和感を取る。
これだけです。
AIがあると、実装そのもののハードルはかなり下がります。
でも、何を作るか、どう切るか、どこで止めるかは、まだ人間の仕事です。
なので、これから個人開発を始める人は、
「AIに全部やってもらう」より、
自分は編集者になる
くらいの意識の方がうまくいくと思います。
まとめ
今回の三幕構成ツールは、
小説を書く時に欲しかった「全体の地図」を、
そのままブラウザで使える形にしたものです。
考えたことはシンプルで、
- 構成の正解を出すのではなく、目安を見せる
- 三幕構成と Save the Cat を重ねて、粗い地図と細かい地図を両方出す
- AIには実装を速くしてもらい、仕様と違和感は自分で決める
この3つです。
個人開発は、AIのおかげでかなり速くなりました。
けど、速くなったからこそ、
その人が何を問題だと思っているか、
何を入れて何を削るか、
そういう編集の力が前より重要になっています。
今回のツールは、まさにそれを実感する一本でした。
