何故、ローカルにシステムを欲したのか
HPで作品を公開していますが、以前から、公開する以外の使い道がないか、と考えていました。
chatGPTにプレーンテキストの本文を添付し、感想や分析を求めることはあります。ただ、作品数が増えてくると、それだけでは難しくなってきます。
単体の作品について話すことはできます。どんな場面なのか、人物なのか、文章の雰囲気はどうか……。
自分がどんな文体で書いているのか、どんな言葉を繰り返しているのか、どんな人物を書きがちなのか、作品ごとに何が似ていて、何が違うのかという作品群全体の傾向は見えにくいです。
自分で考えることも可能ですが、作者でもありますので、中々主観的なものは抜けません。読み返しているつもりでも、自分はこういう作品を書いているはずだという認識に引っ張られる部分があります。
2026年5月現在、出藍文庫には短編小説を中心に約60作あります。
この作品群全体を生成AIに読ませることができれば、自分では気づいていない反復や癖が見えてくるのではないか。そう考えるようになりました。
出藍文庫のHPは、WordPress・PHP・SQLなどを使用して構築しています。作品本文も、タグも、カテゴリも、全てデータベース上に存在しています。
投稿データを抜き出し、ローカル環境で扱える形に整理すれば、自作を横断的に分析できるのではないか。
そんなことをchatGPTと相談しながら、ローカル環境の構築を始めました。
生成AIそのものに興味があったというより、公開されている作品群を、公開以外の形で作者が使える方法はないだろうか、と思っています。
このシステムを使えば、同じ登場人物で別の視点から書いたり、シリーズものとして書くというものだけではない、別の作品の書き方を探し出せるのではないか、編み出せるのではないか、と。
※開発面が気になる方は、「実装に使ったものやフロー」から読まれることをおすすめします。
作ったもの
そうして作ったものがこちらです。以下のスクショをご確認ください。
最初から大規模なシステムを作ろうとしていた訳ではありません。
まず必要だったのは、作品を横断して扱える状態にすることでした。
現在は、ローカル環境上で、作品検索、作品本文の取得、Markdown生成、タグ・カテゴリ表示などを行えるようにしています。
現状は、小説投稿サイトというより、自作分析用の実験環境に近い状態です。
実装に使ったものやフロー
ここからは、実際にどのような形でローカル環境を構築したのかを書いていきます。
文学や生成AIそのものの話というよりも、WordPress・PHP・SQLを使った実装寄りの内容になります。
出藍文庫はWordPressで構築しているため、作品本文、タイトル、タグ、カテゴリ、公開日時などは、全てMySQL上に保存されています。
そのため、PHPから投稿データを取得し、必要な情報をまとめ直す処理を作成しました。
最初は、単純に本文だけを出力していました。
ただ、それだけでは作品ごとの差異や構造が分かりづらく、生成AI側でも整理しにくい場面があります。
そのため、作品単位でMarkdownを生成するようにしました。
タイトル、タグ、カテゴリ、本文、分析用データなどを一つのファイルとしてまとめる形です。
つまり、本文をそのまま渡すのではなく、作品データとして整理した上で渡す状態に近いです。
Markdown形式を選んだのは、作品データを構造化しやすかったためです。
ローカル環境で動かしているため、出力形式を頻繁に変更できるのも大きかったです。
検索機能を追加してみたり、分析項目を増やしてみたり、Markdown構造を変更してみたり……。公開環境ではやりにくい試行錯誤をかなり自由に行えます。
公開環境に直接組み込みますと、セキュリティ、ログ管理、API利用制限、ユーザー対応など、考えることが一気に増えます。
今回はまず、自分自身の作品分析を目的にしていたため、Mac mini上で動作するローカル環境として構築しました。
生成AIに渡す部分ですが、APIによる自動化は行ってません。生成したmdをチャット欄に添付して、指示を出してます。APIを叩くまで行うと、かなりに金額が請求されてしまうだろうな、と考えたためです。
実装してどのように使っているのか
現在は、作品単位でMarkdownを生成し、それを生成AIへ渡して分析する形を中心に使っています。分析というより、作品群を検索可能にしている感覚に近いです。
あるタグに属する作品だけをまとめたり、特定の時期の作品だけを並べたり、人物単位で比較したりします。
複数作品をまとめて生成AIへ渡し、文体傾向の比較を行っていたりします。文章の長さ、改行位置、会話量、情景描写の密度……。自分では別々のつもりで書いていた作品同士に、似たリズムや構図が出てくることがあります。
五感表現や頻出語の分析も行っています。どの感覚表現を使いやすいのか、どういう場面で似た言葉を反復しているのか等です。単体では気づきませんが、数十作単位で並べると、似た温度感の場面を繰り返していることがあります。
作品比較もよく行っています。単純に似ている作品を探すというより、どんな感情の動きを描いているか、人物同士の距離感をどう扱っているかを比較する感覚に近いです。
この作品と近い温度感の作品を探してください。会話主体の作品と情景主体の作品を比較してくださいといった形で確認しています。
登場人物単位で扱えるのもかなり面白い部分でした。この人物と近い人物は誰か、この人物を主人公にした場合、どんな方向へ話が伸びそうかといった形で整理させると、生成AI側が既に作品内に存在していた傾向を拾い始めます。
新しい設定を作るというより、自分が既に何を書いていたかを整理する感覚に近いものでした。
生成AIにmdデータを渡すと何が変わったのか
一番大きかったのは、単体の作品ではなく、作品群として扱いやすくなったことでした。
プレーンテキストの本文をそのまま渡していた時は、どうしても一作品ごとのやり取りになりやすかったです。それでも感想や分析は可能ですが、作品同士の比較や、横断的な傾向分析になると難しくなります。
どの作品にどんなタグが付いているのか、どの時期に書かれたのか、どういう分類なのか……。そうした情報が欠けていると、生成AI側でも作品同士を整理しづらくなります。
プレーンテキストの場合、AI側から見ると、基本的には、今渡された文章を読む形になります。タイトルなのか、本文なのか、分析メモなのか、どこからどこまでが作品なのか、何を比較対象として扱うべきなのか……。人間なら無意識に補完できる部分も、生成AI側では曖昧になりやすいです。
長文としては読めます。感想はくれますが、分析や評論となると何とも言えないものになります。構造化された作品データとしては扱いにくいからです。
Markdown化し、作品単位で情報をまとめるようになってからは、作品データとして扱いやすくなりました。単なる長文ではなく、どの作品なのか、どういう属性を持っているのかを含めて渡せるようになります。
たとえば、
タイトル
本文
AI分析
五感分析
頻出語
類似作品
のように、役割ごとに整理できます。
すると生成AI側でも、
「これは本文」
「これは分析」
「これは比較材料」
として扱いやすくなります。この違いはかなり大きかったです。
単純に読みやすくなるという話ではありません。作品ではなく、作品＋周辺情報＋作者傾向をまとめて扱えるようになります。作品比較や傾向分析の精度もかなり変わりました。
頻出語分析を行いますと、自分では意識していなかった単語の反復が見えてきます。
作品比較を行いますと、文章リズムや視点移動の傾向が整理されます。
横断検索もしやすくなりました。プレーンテキストでは、読むしかできなかったものが、タグ検索、類似作品比較、時系列比較、モチーフ抽出のように、参照できる状態へ近づいているからでふ。
横断検索や比較を行うと、作品同士が繋がり始めます。別作品の登場人物に似た感情の動きがあったり、無意識に似た構図を反復していたり、文章リズムに共通点が出ていたりするのが見えてきます。
単体で読んでいる時には気づきにくかった部分です。書いた時には別々の作品だったものが、同じ作者が書いた作品群として見え始めます。
もちろん、生成AI側の分析が常に正しい訳ではありません。説明すると弱くなる表現を、整理しようとしてしまうこともあります。沈黙や余白を回収しようとする場面もあります。
ただ、作者一人では見えにくいものを外側から整理する補助としては、かなり有効でした。
生成AIが凄かったというより、生成AIに渡せる形に作品群を整理したことが、一番大きかったのかもしれません。
今後の予定
このシステムを、第三者向けのWebサービスやアプリとして公開する予定はありません。
理由は単純です。セキュリティ、サーバー負荷、ログ管理、データ保存、悪用される可能性……。公開するとなりますと、分析環境を作る以外のことに時間を使う必要が一気に増えます。技術的には可能だと思います。
僕がやりたいことは、小説を書くことです。エンジニアとして活動したい訳ではありません。
今回作った環境も、生成AIサービスを作りたいからではなく、自分の作品群を整理し、読み返せる状態にしたかったから作ったものでした。
現状は、自分自身の作品分析や実験環境として使っていく予定です。
ただ、作品を書き続けていく限り、この環境自体も少しずつ変わっていくのだと思います。