バイブ・ライティングによる小説構造設計
この開発の出発点は、最初から業務システムの設計にあったわけではない。
むしろ逆で、最初はAIを使って小説を書くところから始まっている。
自分は、AIと一緒に物語を組み立てていくこのやり方を、勝手に「バイブ・ライティング」と呼んでいる。
「雰囲気で書く」という意味ではなく、最初はイメージや断片的なアイデアから入り、そこから設定を構造化し、AIが扱いやすい形へ整えていく書き方、という意味で使っている。
流れとしては、まずAIとブレストして、世界観やキャラクターやシーンのイメージを膨らませる。
ある程度固まってきたら、重要な設定を個別ファイルとして切り出す。
登場人物、組織、場所、出来事、能力、関係性のような要素ごとにファイルを分け、属性を持たせ、重複や矛盾が起きにくいように整理する。
その上で、それらの設定を組み合わせて、あらすじやシーン、言わせたいセリフを組み立てていく。
自分の中では、この単位を「シーン」や「幕」と呼んでいる。
さらに、設定ファイルをAIに読ませやすくするために、Pythonで圧縮・結合し、必要な文脈だけを取り出せるようにしている。
最後にAIで本文を書き、人間が微調整する。
こうすると何がいいか。
一番大きいのは、設定の破綻が起きにくいことだ。
AIに長編を書かせると、キャラクターの口調や背景、関係性がぶれやすい。
でも、設定を構造化して持っておくと、そのブレがかなり抑えられる。
ただ思いつきで書かせるのではなく、「前提条件を整理してから書かせる」形になるからだ。
このやり方を続けていて、あるとき面白いことがあった。
圧縮した設定情報をNotebookLMに読み込ませ、音声解説を作らせてみたところ、そのストーリー全体が「システムのように整理されている」といった趣旨で説明されたのだ。
そのとき、かなり腑に落ちた。
確かに自分がやっていたのは、感覚だけで物語を書いていたのではなく、要素を分解し、属性を与え、関係を整理し、あとで再利用できる形にしていく作業だった。
それはかなり「設計」に近い。
そしてそこで、逆に業務システムの設計書のことを思い出した。
業務の設計書は、再利用しにくい形のまま残りがちだ
SIerの現場では、今でも多くの設計書がExcelで作られている。
もちろんExcel自体が悪いわけではない。
表も書けるし、見た目も整えやすいし、誰でも触れる。
実務で広く使われてきたのにはちゃんと理由がある。
ただ、その自由度の高さが、そのまま再利用性の低さにもつながりやすい。
たとえば、テスト結果のOK/NGだけを機械的に拾いたい、という単純そうな処理でも、実際にはかなり苦労することがある。
セル結合やセル挿入でフォーマットが崩れていたり、シートごとに微妙に列の意味が違っていたり、担当者ごとの独自ルールが入り込んでいたりする。
そうなると、ただ抽出したいだけなのに、自動化の前処理にものすごく時間がかかる。
これはテスト結果だけの話ではない。
設計書全般でも同じことが起きる。
自由に書けること自体は便利だが、最初から「データとして扱う」発想で作られていないので、後から再利用しにくい。
AIに処理させようとしても、文書の量が膨大なうえ、記述揺れや表現揺れが大きく、必要な情報だけを安定して抜き出すのが難しい。
結果として、コンテキスト不足や解釈揺れにぶつかりやすい。
つまり、人間向けに見た目を整えることはできても、機械にも人間にも扱いやすい資産にはなりにくい。
この違和感は、AIと小説を書いているときに感じていたこととかなり似ていた。
設定が整理されていないと、AIはぶれる。
設計資産が整理されていないと、業務でも再利用や検証がしにくい。
根っこは同じ問題なのではないかと思うようになった。
既存のモデリングツールにも、別の難しさがある
では、最初からモデリングツールを使えばいいのではないか。
実際、世の中には良いモデリングツールがたくさんある。
ER図、クラス図、業務フロー、各種UML。
表現力も高く、操作性も洗練されているものが多い。
ただ、ここにも別の難しさがある。
ひとつは、独自バイナリ形式で保存されることが多いこと。
もうひとつは、XMLなどテキスト形式で保存されていても、人間が直接読んで扱うには可読性が低いこと。
つまり、ツールに依存しやすい。
さらに、良いツールほど最終的には有料化しやすい。
しかもライセンスはサブスク型で、人数単位になることが多い。
すると、導入時は便利でも、人数が増えるとコストが膨らみやすい。
その結果、「読むためだけにライセンスを払うのは厳しい」となって、だんだん使われなくなり、最終的には誰も更新しない資産になる。
これはかなりもったいない。
設計資産は、本来は長く残って再利用されるべきものだ。
なのに、読むための道具がないと中身に触れない、という状態はあまり健全ではないと思う。
ここでもやはり、自分が欲しいのは「専用ツールの中に閉じた資産」ではなく、人間にも機械にも比較的扱いやすい形で残せる設計資産なのだと感じた。
AI時代の設計は、もっと役割分担が変わっていくと思う
これから先、AIを活用する流れはますます強くなるはずだ。
そのとき、人間の仕事とAIの仕事の境界も少しずつ変わっていくと思っている。
自分は、今後のAIの責務は大きく二つに寄っていくと見ている。
ひとつは、設計の補助。
もうひとつは、正確なコーディングだ。
もちろん、要件の妥当性を決めるのはまだ人間の役割が大きい。
でも、要件定義のあとに発生する詳細設計や、個別要素の整合性確認、関連する項目の洗い出しのような作業は、かなりAIに任せやすくなっていくはずだ。
この段階の設計行為は、小説制作で言えばバイブ・ライティングに近い。
まず方向性があり、要件や意図があり、それをもとにAIが補助しながら構造を広げ、整合性を詰めていく。
これを自分の中では「バイブ・デザイン」と呼んでもいいと思っている。
ただし、ここで大事なのは、AIが出した設計をそのまま機械同士で回せば済むわけではないことだ。
最終的には、人間がそれを読み取り、妥当性を評価し、品質を保証しなければいけない。
だから必要なのは、AIが扱いやすいだけのデータではない。
人間が直感的に読めることも必要だ。
一覧、関連、図、チャート。
こうした補助表現があることで、初めて人間は全体を理解しやすくなる。
つまり、AI時代の設計資産には、
- 機械が解釈しやすいこと
- 人間が読んで判断しやすいこと
- 将来も残しやすいこと
の三つが必要になると思っている。
その基盤は、テキストで持つのがいいと思った
ここまで考えて、ようやく「では何を基盤にするべきか」という話になる。
自分の答えは、少なくとも土台はテキストがいい、というものだった。
しかも、表現力と可読性のバランスを考えると、Markdownがかなりちょうどいい。
単なるプレーンテキストより構造を書きやすい。
表も書ける。
見出しも持てる。
リンクも扱える。
差分も見やすい。
人間も読めるし、機械にも比較的処理させやすい。
もちろん、Markdownだけで図のすべてを表現するのは難しい。
だからこそ、図やチャートはあくまで補助として使い、その元になる構造をテキストで持つのが良いと思った。
実際、今考えているフォーマットでも、ERでは entity 側に Columns や Indexes、Relations を持たせ、diagram 側では対象 object を束ねる形にしている。class 側も同様に、個別定義と diagram 定義を分けている。
まだ試行錯誤中ではあるが、考え方としては一貫している。
まずは構造をテキストで持つ。
その上で、人間が理解しやすい図や詳細ビューを重ねる。
この順番の方が、資産としても強い。
だから、テキストベースのモデリングツールを作りたくなった
小説をAIと書いていて気づいたのは、設定が構造化されているほど、AIも人間も扱いやすくなるということだった。
そして業務の設計資産を見たとき、その逆の問題もはっきり見えた。
情報はたくさんあるのに、再利用しにくい。
読むにも処理するにも重い。
ツールにも形式にも縛られやすい。
だったら、最初から「人間にも機械にも扱いやすい形」で持てる設計資産を作れないか。
それが、この開発の出発点だった。
そして、調べたところ
- モデルの設計が中核
- モデルから整合性のある図を表現できる
- 保管はツールがなくなってもつぶしの利くテキストベース
- 無料または低価格で利用可能
というものは、一部を満たすツールはあったが全てを満たすツールは存在していなかった。
最初はファイル管理まで含めた独立ツールとして考えていた。
ただ、その後、Obsidianプラグインへ寄せた方が良いと判断した。
次回は、最初に考えていた独立ツール構想から、なぜObsidianプラグインへ切り替えたのかを整理してみたい。
コメント