AIに《丸投げ》しなかった理由。VPSでnote連載小説システムを作ってみた

AIに《丸投げ》しなかった理由。VPSでnote連載小説システムを作ってみた、と書かれたテキストと構成アイコン
Tomoya

前回、AI量産系の「稼げるnote」がなぜ売れてしまうのかを分析した。

今回は、それを批判するだけで終わらせず、実際に自分の手で検証してみることにした。

前回の記事はこちらから

AIを使ってnoteで本当に稼ぐことは可能なのか。

ただし、中身のない情報商材としてではなく、AIの力を借りて読む人の心を動かす小説を「製品」として実際に運用してみる、という形で試したい。

結果はありのままを記事にしていくつもりだ。

DiscordでNote_Novelistアプリから連載小説第0004話のレビュー依頼通知が届き、あらすじや承認・差し戻しの操作案内が表示されている画面
Discord上で小説生成Botから連載第4話のレビュー依頼通知が届き、承認や修正指示の受付状態を示しています。

目次

設計思想:AIに全部任せなかった理由

今回のシステムの本質は、「AIに小説を書いてもらうこと」そのものではない。

その前提となる枠組み・ルールを、僕自身が決めることにした。

具体的には、人間がいわば「プロデューサー」の立場で物語の基本設定や進め方を決め、その枠の中でAIが実際の文章を執筆する、という構成にした。方向性さえ決めてしまえば、あとはほぼ全自動で回るようにしたかったので、これまでも使っているVPS上にシステムを常駐させ、生成されたドラフトはDiscordに通知して、そこで内容を確認する形にした。

前提の制約
Tomoya

最初から分かっていた制約が1つあった。

noteには記事を自動投稿する仕組みが公式には存在しない。

なので、レビューでOKを出した後、自分の手でnoteに投稿するひと手間だけは残る。これは最初から織り込み済みで進めることにした。

システム自体の仕組みはそれほど複雑ではなく、AIに相談しながら組み上げていった。

ただし、このシステムの本当のポイントは「プロンプト設計」にある。

ここの設計を誤ると、話の内容が変わってしまったり、時系列や設定にズレが生じてしまう。長く連載を続けるほど、AIの生成にはこの手の「」が生まれやすくなるので、そこは慎重に考えて設計した。

まだ有料プランを契約しておらず迷っている方に朗報です!

以下のリンクから月額プランを契約すると、初月は半額で利用できます。コストが心配な方でも、最初の1か月は最低10ドルから試せるので、気軽に始めやすいと思います(解約も簡単にできます)。



構築記:ローカル検証からVPSへ

システム全体フロー図
システム全体フロー 生成は自動化し、公開の判断だけは人間が握る 自動化する領域 人が判断する領域 1 ローカル検証 手元で挙動を確かめる 2 VPS常駐 定時起動で下書き生成 3 チャット通知 原稿が手元に届く 4 人間の承認 読んで公開可否を決める 5 note投稿 連載として公開 差し戻し ・ 再生成 自動化するのは「生成」まで。公開ボタンを押す権限だけは自動化せず、必ず人の手元に残す。 承認されなかった原稿は破棄せず、条件を変えて再生成のループに戻す。

図:note連載小説システムの全体フロー

進め方は、これまでのシリーズと同じく「ローカルで開発→動作確認→VPSへ」という段階を踏んだ。

まず要件をPRDとしてまとめ、それをCursorのAIエージェントに渡して実装してもらう形を取った。

ローカルでは、コマンドを1つずつ手動で実行しながら、想定通りに動いているかを段階的に確認していった。この時点ではDiscordはまだ組み込まず、VPSに載せてから使える状態の土台だけを作っておいた。

一気に全部を作り込まず、動く部分から確認していく、という普段の進め方を今回も踏襲した形になる。

AIエディタでPRDに基づくプロジェクト計画作成を依頼し、確定方針と処理フローチャートが生成された構成図
AIアシスタントへのプロンプト指示(①依頼)から、確定した開発方針と処理フロー(②計画)が生成されるプロセスを示しています。

以前のシリーズに関して以下から


つまずきポイント3連発

つまずきポイント整理図
つまずきポイント 3連発 通知が届かない・二重に動く。原因はすべて「設定の使い回し」にあった 1 BotのID競合 問題点 音声チャットAI用のBotを そのまま使い回そうとした 既存Botの処理が優先され 小説システムの通知が 機能しなかった 音声チャット 小説通知 Bot 1つ 音声が 優先される 対応 小説専用のBotを新規作成。 サーバーとチャンネルは共用のまま 2 起動モードの設定ミス 問題点 常駐化の設定ファイルに 起動数の指定を書き忘れた 意図せず複数プロセスが 起動しうる状態になっていた cluster mode 接続が重複する fork mode 1本だけ保つ 対応 常に1本の接続を保つ処理なので fork modeを明示して修正 3 IDの取り違え 問題点 通知が全く届かなかった 送信先に指定すべきIDを 別の用途のIDと取り違えていた 誤:BotのアプリID 開発者ポータル側 正:チャンネルID サーバー側 似た役割のIDが複数あるため 用途ごとの切り分けが必要 対応 AIに一緒に確認してもらい 見るべき数値をすぐ特定できた 3つに共通するのは「既存のものを流用したことによるズレ」。Botも設定も、用途が違うなら分けたほうが早い。

図:VPS常駐で踏んだ3つのつまずきと、その対応

VPSに実装を移してから、3つのトラブルに立て続けにぶつかった。

1つ目
BotのID競合

問題点

Discordの通知には、以前作った音声チャットAI用のBotをそのまま使い回そうとした。

しかし既存の音声チャットBot(前回構築したシステム)の処理が優先的に動いてしまい、新しい小説システムの通知がうまく機能しなかった。

対応

結局、小説専用の新しいBotを別に作り、同じDiscordサーバー・同じチャンネルを共用しつつ、Botの中身だけは完全に分ける形に変更した。

2つ目
起動モードの設定ミス

問題点

常駐化の設定ファイルに、「1つのプロセスだけを起動する」という指定を書き忘れていたため、意図せず複数プロセスが起動しうる状態(cluster mode)になっていた。

対応

Discord Botのような「常に1本の接続を保つ」タイプの処理は、1つの窓口だけを起動する(fork mode)のが正解で、ここも合わせて修正した。

pm2 listコマンドの実行結果一覧と、vps-noteプロセスがonline状態で動作している様子
プロセス管理ツールPM2の実行結果画面において、vps-noteプロセスが正常に起動している状態を示しています。
3つ目
IDの取り違え

問題点

Discordから通知が全く届かない問題も発生した。

原因は、サーバーの「チャンネルID」ではなく、開発者ポータル上の「BotのアプリID」を設定してしまっていたことだった。

Botのプロフィール設定画面で、「Note_Novelist」のアプリIDが表示されたエリアと注意点
Discordの開発者ポータルにて、ボット「Note_Novelist」のアプリID設定箇所と確認ポイントを示しています。

Discordには似たような役割のIDがいくつも存在するので、どれがどの用途のIDなのか、きちんと切り分けて理解しておく必要があると感じた。

対応

AIに一緒に確認してもらったことで、どの数値を見るべきかすぐに特定できたのは助かった。

DiscordのWebブラウザURLバーにおいて、チャンネルIDにあたる末尾の数値部分が強調された画面
DiscordのWeb画面URLから、チャンネルIDとして取得すべき末尾の数字列を示しています。
Tomoya

同じようにDiscordでのシステム構築につまずいている人がいれば、参考になるかもしれない!!

サーバーやチャンネル自体は共用してもいいが、それらを繋ぐBotだけは、サービスごとに別々に管理した方がいい

というのが今回一番の学びだった。


次回予告

次回は、このVPS上に常駐させたシステムを使って実際に小説を執筆・レビューし、noteで販売してみた結果を報告する。

前回の記事はこちらから

以下のリンクから月額プランを契約すると、初月は半額で利用できます。コストが心配な方でも、最初の1か月は最低10ドルから試せるので、気軽に始めやすいと思います(解約も簡単にできます)。

他のVPSは「さくらインターネットから!」

前回のおすすめ記事はこちらから

VPSを使った24時間稼働システムを作成した記事はこちら

AIに《丸投げ》しなかった理由。VPSでnote連載小説システムを作ってみた、と書かれたテキストと構成アイコン

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

始めまして。このブログを運営するTomoyaです。
未経験個人開発者。AI×個人開発(Vibe Cording)で学習して参入してくれる人が増えて広がっていくと良いなと思って始めました。

実際に作成→デプロイ(公開)→運営を行ってそれについての問題や疑問を記録していきます。
また行っていく上で内容(セキュリティ・制限など)にもこだわっていきたいなと思っています。

コメント

コメントする


目次