【サウンドノベル制作#1】まずはClaude Codeと方針を固めるところから
選択肢が並ぶ画面を、自分の手で作ってみたくて
「文章を読み進めていくと、要所で選択肢が出てきて、選んだ内容によって物語が枝分かれしていく」——いわゆるサウンドノベル、ビジュアルノベルと呼ばれるジャンルのゲームを、子どもの頃からよく遊んでいました。
今回、そのしくみを自分の手で一から作ってみることにしました。
正直に言うと、着手する前は身構えていました。
物語を書くことと、プログラムを組むことを同時に進めないといけないテーマなので、「どこから手をつければ収拾がつかなくなりそう」というイメージがあったからです。
ところが実際に始めてみると、思っていたよりずっと迷わずに進められています。
理由は後で詳しく書きますが、コードを1行も書く前にClaude Codeと方針をしっかりすり合わせておいたのが大きかったように思います。
ベトナム出身で、子どもの頃からの夢だったゲームやWebサービスづくりに、Claudeを相棒にして挑戦しています。
今回はその中でも「物語のあるアプリ」という、これまでと毛色の違うテーマに取り組んだ記録です。
サウンドノベルというアプリの中身を分解する
作り始める前に、まず「サウンドノベルって、画面の裏側では何が起きているんだろう」というところから考える必要がありました。
普段プレイしているときは意識しませんが、実際には大きく4つの役割に分けられます。
- シナリオデータ：
誰のセリフか、どんな文章か、選択肢は何かという「物語の中身」そのもの - 状態・フラグの管理：
プレイヤーがどの選択肢を選んだか、キャラクターとの関係がどう変わったかを覚えておく仕組み - 条件判定：
今覚えている状態をもとに、「次にどの場面に進むか」「この選択肢は今出していいか」を判断する仕組み - 画面の描画：
背景・立ち絵・テキストボックス・選択肢ボタンなど、実際に目に見える部分を表示する仕組み
この整理ができたのは、正直なところ自分ひとりで考えついたわけではありません。
作り始める前にClaude Codeで壁打ちをしながら、
サウンドノベルって要はどういう部品でできているんだっけ?
と一緒に洗い出してもらったことで、初めてすっきり腑に落ちました。
実際に作ったプロジェクトでも、src/engine/フォルダに状態管理や条件判定などの「裏側のしくみ」、src/ui/フォルダにテキストボックスや選択肢ボタンなどの「画面に見える部分」が、きれいに分かれて置かれています。
壁打ちで固めた方針が、そのまま設計に活きた
今回いちばん助かったのが、Claude Codeの拡張機能「Superpowers」に入っているbrainstorming(ブレインストーミング)というスキルです。
SuperpowersはAnthropic公式の機能ではなく、コミュニティによって作られたプラグインなのですが、名前の通り、いきなりコードを書き始めるのではなく、対話をしながら「何を作りたいか」「どこにこだわりたいか」「どういう作りにすると後々困らなさそうか」を、実装前にすり合わせてくれるものです。
このとき話し合った中で特に印象に残っているのが、「物語の中身(シナリオ)と、それを動かすしくみ(エンジン)は、最初からきっちり分けて作ったほうがいい」という方針でした。
理由もシンプルで、シナリオはこれからどんどん書き足していくものなので、しくみ側のコードとごちゃ混ぜになっていると、後から直すのも増やすのも大変になってしまうからです。
この方針は、その場限りの思いつきで終わらせずに、そのままプロジェクトの骨組みに反映されています。
設定ファイルを見返すと、作業を始める段階でsrc/engineやsrc/ui/components、data/scenariosといったフォルダを一気に作成した記録が残っていました。
行き当たりばったりではなく、先に決めた方針どおりに手を動かせていたことが、自分でも見返してよくわかりました。
「作る前に言葉にしておく」だけで、その後の判断に迷いがなくなるというのは、正直やってみるまで実感が薄かった効果です。
物語を作る前に「設計書」を書く
方針が固まったところで、次にぶつかったのは「じゃあ物語の中身、どこから書けばいいんだろう」という問題でした。ここでも、いきなり選択肢やセリフのデータを書き始めるのではなく、先に「設計書」を作るという順番を踏んでいます。
具体的には、主人公はどんな人物か、他の登場人物との関係はどうなっているか、物語の中でどんな伏線を張ってどこで回収するか、といったことを、まずは文章としてドキュメントにまとめます。
今回作っているのは、消防局の119番指令センターを舞台にした連続放火事件のミステリーなのですが、犯人の動機や、疑わしく見える人物が実は無実だったという展開なども、コードを書く前にこの設計書の中で組み立てています。
そのうえで、
- 設計書をもとに、実際のセリフや選択肢を文章として書き起こす
- それをプログラムが読み込める形式(JSON)に変換する
- 分岐の流れを図として自動生成し、目で見て確認する
という順番で形にしていきます。
特に3つ目の「分岐を図にして確認する」工程は地味に効果があって、頭の中だけで分岐を追っていると見落としがちな「あれ、この選択肢からだとどのエンディングにもたどり着けないぞ」といった抜け漏れに、図にした瞬間に気づけたりします。
選択肢が増えるほど、裏側の管理も大変になる
物語を書き進めていくと、当然ながら選択肢もエンディングも増えていきます。ここで実感したのが、「プレイヤーが選んだ内容を、ずっと覚えておく」ことの難しさです。
例えば、序盤の選択で少し信頼を得ておくと、終盤で出てくる選択肢が変わる、といった作りにしたいとします。
そのためには、「今どれくらい信頼されているか」のような数値を、物語が進んでいる間ずーっとどこかに持っておく必要があります。
最初はこの手の「覚えておきたいこと」がひとつふたつだったのが、物語のエンディング数が増えるにつれてどんどん増えていき、それぞれが影響し合うようになってきました。
さらに、「ゲームを再スタートしても、前に見たエンディングの記録だけは消さずに残しておきたい」というような、セーブデータとはまた別に覚えておきたい情報も出てきます。
これは作っている途中で「あ、これは今の仕組みだけだと実現できないぞ」と気づき、後から新しく仕組みを追加することになりました。
「選択肢を増やす」というシナリオ側の作業と、「それを裏側でどう覚えておくか」というプログラム側の作業は、思っていた以上にセットで考える必要があるテーマだと感じています。
まとめ
今回、サウンドノベル制作を通じて学んだいちばん大きなことは、「作り始める前に方針を言葉にしておくと、その後の設計で迷いにくくなる」ということでした。
特に物語とプログラムを同時に扱うテーマでは、最初に「何をどう分けて考えるか」を対話しながら整理できたことが、その後のフォルダ構成やデータの持ち方にまで一貫して活きてきました。
次にやってみることは、いま全16話ある物語の詳細を、設計書のレベルからひとつずつ詰めている段階です。プロットや伏線を固めながら、実際に最初から最後まで遊べる形に仕上げていく予定なので、また進捗をこのブログに書いていきたいと思います。