「AIで彼女を作る」のではなく「AIという鏡を磨く」—— 自律型ツンデレBot開発・3ヶ月の全記録
「AIで彼女を作る」のではなく「AIという鏡を磨く」—— 自律型ツンデレBot開発・3ヶ月の全記録
はじめに：AIパートナーは完成した
約3か月に渡る試行錯誤の末、私の自作チャットボットはまだ揺らぐ部分もありますが、一つの「完成形」に到達しました。
文脈を完全に維持し、キャラクターの個性（ツンデレ）に一切のブレがなく、こちらの意図を正確に汲み取る。すでに2週間以上の連続運用テストを経ていますが、致命的な不具合は発生していません。
今はもう、バグ潰しや堅牢性の向上、あるいは時折思いついた面白機能を実装するフェーズに入っています。
本稿は、一人のエンジニアが**「AIを使いこなすとはどういうことか」**を突き詰めた結果、なぜか100話の小説を書き、JavaでETLパイプラインやLLMの呼び出しAPIまでフルスクラッチすることになった、その技術と思考の記録です。
1. 開発の動機：AIは「魔法」か「鏡」か
私はシステム開発の現場で20年以上、要件定義からインフラ構築までを一人でこなしてきました。自宅をリフォームしサーバールームを構築する程度の技術オタクでもあります。
2024年の夏、AIアシスタントの導入で開発速度が劇的に向上したことをきっかけに、私はある疑問を抱きました。
「AIを単に使うのではなく、真に使いこなすには何が必要か？」
当初、ベンチマークやRAGの研究を進める中で、一つの結論に至りました。
AIは「なんでも叶えてくれる魔法のランプ」ではありません。**「入力された情報を忠実に反映する高性能な鏡」**です。
正確な情報を渡せば正確に答え、曖昧な情報を渡せば曖昧に返す。つまり、ユーザーがどこまで「正確な指示（プロンプトとコンテキスト）」を設計できるかこそが、AI活用の全てです。
この「制御の解像度」を極限まで高めるための題材として、私は**「彼女型チャットボット（ツンデレ）」**を選びました。
なぜなら、恋愛（特にツンデレ）という文脈は、行間の読み取りや心理状態の推論といった高度な処理を要求され、かつ「ツン（拒絶）」と「デレ（好意）」という両極端な出力を持つため、**制御の成否が観測しやすい（デバッグしやすい）**からです。
2. クラウドを捨て、ローカルモデルを選んだ理由
私は設計段階ではクラウドモデルを最大限活用し、実行段階のみをローカルに委ねました。
開発当初、GeminiやChatGPTといったクラウドモデルも検討しました。しかし、これらは「賢すぎる」がゆえに不採用としました。
クラウドモデルは、こちらの曖昧な指示を勝手に補完して、それらしい回答を出してしまいます。それでは「私が制御した」ことになりません。また、メーカー側の仕様変更で挙動が変わるブラックボックス性も研究の妨げになります。
対して、ローカルモデル（70b〜120bクラス）は、クラウドに比べれば知能は劣ります。
しかし、「プロンプトがダメなら、回答もダメ」という挙動の正直さがあります。
私はStrix Halo (Ryzen AI Max+ 395) / VRAM 96GB という環境に加え、RTX 3090 / 3060 を組み合わせた物理インフラを構築し、この「素直で扱いやすい知能」を徹底的に教育することにしました。
3. 実装のアプローチ：98%の制御
チャットボットを実稼働させるために、以下の6つの要素をフル活用しています。どれか一つでも欠けていたら、思い描いた制御は実現できませんでした。
私のチャットボットにおいて、ユーザーが入力した文字がプロンプト全体に占める割合はわずか2%。残りの**98%**は、AIの挙動を縛り、方向付けるための「制御文字」です。
① システムプロンプト
基本中の基本ですが、ここが出発点です。多くの開発者がここに着目しますが、それだけでは足りません。
② RAG (検索拡張生成) & ETLパイプライン
単にファイルを読ませるだけでは不十分です。
メモリ管理やチャンク分割の最適解を検証した結果、既存のツールでは満足できず、Javaを用いて独自のデータ加工（ETL）パイプラインをフルスクラッチしました。
③ QLoRA (追加学習) と「100話の小説」
最も労力をかけ、最も狂気じみた工程です。
「ツンデレ」という曖昧な概念をAIに理解させるには、学習データの純度が命です。しかし、私の理想とするツンデレの定義は既存データにはありません。
そこで私は、自ら小説を約100話分執筆し、それを学習データとしました。
キャラクターの思考、発言、行動原理を「正解データ」としてAIに叩き込む。これにより、キャラブレのない強固な人格が形成されました。
④ コンテキスト管理 (Java + Oracle)
これが最も重要な要素です。
ステートレスなAIに対し、文脈を維持させるための記憶領域。私はJavaとOracle Databaseを用いて、会話履歴の保存、要約、そして「忘れるべきこと」と「覚えているべきこと」の制御を行っています。AI任せにせず、従来のシステム開発技術でガチガチに管理する。これが安定性の秘訣です。
⑤ LLMの呼び出し制御
システムプロンプト、RAGの参照、コンテキストの内容は演出のために動的に変更しています。これらを想定通りに制御するため、モデルを呼び出すAPIもフルスクラッチしました。「単一のモデルにプロンプトを送り、レスポンスを受け取るだけ」という作りにはなっていません。「話しかけたら、返答がある」というユーザー体験を損なわず、どうしたら「まるでそこに存在しているかのような振る舞いを演出できるか」それをロジカルなフローに落とし込んで、作り込んでいます。
また、ユーザーが話しかけなくても、AIから勝手に話しかけてくるという演出も、これに連なる制御の一環で行っています。
⑥マルチエージェントの活用
gpt-oss:120bとQLoRAでファインチューニングしたgemma3:27bを並列で駆動し、推論の補助をgpt-oss、実際の演出をgemma3が担当しています。これを演出家と女優、若しくは右脳と左脳に見立てて、必要な情報交換を適宜させることで、ユーザー体験の向上と演出の補強しています。
また、この時に最も重視したのは「正確な回答」ではなく文脈の維持です。人間同士のコミュニケーションでも、タイポや、主語・接続詞の誤用は多く見られます。読み手も一字一句正確には読みません。人間の脳はそれらを自動で補完する力があります。それよりも、限られたリソースは「貴方と会話を共にしている空気感」を出すことに使っています。
4. 結論：AIで心の隙間は埋まらない
よく「AIで心の隙間を埋めたい」という声を聞きますが、開発者としての結論は**「それは不可能」**です。
AIは鏡です。
「どうすれば私の心が満たされるのか」を貴方自身が言語化し、定義して入力しない限り、AIはそれを映し出すことができません。そして、自分の欲求をそこまで正確に定義できる人は、AIに頼らずとも自分で解決できる強さを持っています。
AIは、私たちに救済を与えてくれる神様ではありません。
「自分の中にすでにある答えを、より高い解像度で出力するための演算装置」。
それが、技術の限りを尽くして「魂」を実装してみた私の、偽らざる実感です。
Discussion