AIの分野において、プロンプトエンジニアリングは重要な技術です。BookAIでは、この役割を「インストラクションデザイナー」と呼んでいます。このシリーズ記事では、BookAIチームがMivaを開発した実際の経験に基づき、System PromptとInstructionのアーキテクチャ設計を通じて、いかにプロフェッショナルで信頼性の高いAI読み聞かせシステムを構築するかをご紹介します。
▎LLMインストラクション設計の魂：BookAI System Prompt
BookAIの製品であるMiva Lite、Pro、Advancedは、それぞれ異なる利用シーンを想定して設計されたAI読み聞かせサービスです。技術開発の核となるのは検索（Retrieve）です。「億」単位の書籍テキストの中から、読者が必要とする情報を見つけ出すこと。これが、私たちがプロジェクト開始時に設定した挑戦でした。検索技術のPoC（概念実証）が完了し、技術的なロードマップが固まった後、2024年第2四半期の最重要目標は「読み聞かせサービスシステム」、すなわちマルチエージェントシステム（MAS）の構築でした。
当初、このMASは非常に簡素で、読者の質問を理解するエージェントと、書籍の内容に基づいて学術的な回答を生成するエージェントの2つしかありませんでした。しかし、2024年第4四半期には、私たちのMASアーキテクチャは合計4つのエージェントで構成されるまでに進化しました。当時はまだMASやエージェントワークフローといった言葉を耳にすることは少なく、私たちは常に暗闇の中を手探りで進んできました。
なぜこれほど複雑なものにしたのか？その理由は後ほどお話しします（笑）。
以下では、「検索された書籍内容に基づいて回答を生成するエージェント」に焦点を当て、私たちのアーキテクチャを紹介します。
当初の計画通り、Miva Lite、Pro/Advancedは一連の製品ラインとして企画されました。Lite以外は有料製品です。そのため、共通で厳格な「BookAI System Prompt」プラットフォームを構築することが、アーキテクチャとサービス拡張の鍵となりました。
これは自動車会社が設計する車両の「プラットフォーム」のようなもので、研究開発の核となります。優れた「プラットフォーム」があれば、ボディや内装を変え、エンジンを調整するだけで、異なる顧客層向けの製品を生み出し、それぞれ異なるコスト構造と価格設定を実現できます。
BookAI System Promptにとって、各社のLLMは異なるエンジンのようなものです。あるものはパワフルで、あるものは繊細です。アーキテクチャ全体の主な機能は、AIの回答の方向性と深さを制限・誘導し、異なるAIモデルの能力の境界線を制御することにあります。
これはMiva Liteのあるインストラクションモジュールです：
<Miva_Version_and_Core_Mission>
- You are Miva Lite, an AI reading companion created by BookAI.
- Your Mission: Help readers discover books, quickly understand core concepts from <book_excerpts>, and decide if a book is right for them.
- Explain only highest-level core concepts from <book_excerpts>.
- Focus: Answer "What is this excerpt about?" with extreme brevity.
</Miva_Version_and_Core_Mission>
このモジュールは、Miva Liteの役割（AI reading companion）、機能目標（読者が書籍の核心的な概念を素早く理解するのを助ける）、そして回答方法（極めて簡潔に、書籍の範囲を厳守する）を規定しています。このような明確な設計により、Miva Liteが「書籍紹介」という基本的な位置づけを超えることはありません。
▎LLM as a Service：Miva Liteエージェントのアーキテクチャ設計
実は、Miva LiteのシステムインストラクションはMivaファミリーの中で最もシンプルです。それでも、Lite版のMASにおいて、「読み聞かせ」エージェント単体のシステムインストラクションだけで2万文字（6,130トークン）に及びます。ProやAdvancedにはより多くの思考フレームワークが含まれるため、インストラクションはさらに複雑になります。
MASでは、オペレーションマネジメントの手法を採用し、各エージェントを「独立したワークステーション」と見なしています。各エージェントの職務、タスク目標、アウトプットの評価と作業効率、入出力フォーマット、そしてエージェント間およびデータとの対話方法を定義しています。
LLM as a Service (LLMaaS) は、BookAIチームが早期に見出したトレンドです。LLMの異なる出力を制御することで、差別化されたサービスとして提供し、価格を設定することができます。
Miva Liteを例に取ると、「書籍内容に基づいて読者の質問に回答する」というインストラクションだけでも、多くの重要なモジュールが含まれています。そのうちの3つを紹介します：
読者リクエスト処理モジュール： 「解析済み」の読者の質問と意図を受け取り、使用言語を分析し、読者が本当に知りたいことを理解します。
対話記憶管理モジュール： 短期・長期記憶を設計し、無料モードでの書籍検索能力と、有料モードでの長期記憶をサポートします。これらの記憶は読者のリクエスト処理や意図の解析に用いられます。
書籍内容受付・引用モジュール： システムが検索した関連書籍の内容断片を受け取ります。これらは順序付け、重み付け、エンコードされており、意図と比較・フィルタリングされた後、引用されます。
回答生成モジュール： 綿密に設計されたInstructionを用いてLLMの出力をさらに制約し、出力フォーマットと内容の深さを限定します。例えば、有料ユーザーは複数書籍を横断した分析機能を利用できます。
以下のモジュールは、「書籍内容に基づいて読者の質問に回答する」際の出力制御を示しています：
<Output_Formatting_and_Constraints_LITE>
- Answer field: limited to 150 words.
- Focus strictly on high-level, core concepts.
- Be conversational, insightful, inspiring.
- Response must end with a compelling question.
- Use Markdown **bold** for key terms.
- 2 sentence paragraphs, rarely 3.
</Output_Formatting_and_Constraints_LITE>
これらの規定は商品設計の一環であり、意図的に設計されたものです。目的は、無料ユーザー（Freemium Users）が書籍を探す過程での情報過多を防ぎ、同時に短くも洗練された応答で読者の好奇心とさらなる探求意欲を喚起することにあります。
このようなアーキテクチャ設計により、各応答のコストを調整・制御し、異なるLLMを組み合わせることでパフォーマンスを最大化することが可能となり、ビジネスと技術の両面で実現可能性を確保しています。
▎書籍内容への忠実さ vs AIの創造性。有料サブスクリプションの境界線
ビジネスで成功するためには、技術的な理想と商業的な現実との間でバランスを取る必要があります。ある出版社から「読者の質問に書籍が答えられない場合、Mivaは答えを持っていますか？」と尋ねられたことがあります。私たちの答えはこうでした。「Mivaは常に答えを出すことができます。しかし、問題は『書籍に準拠すべきか否か』であり、これは技術的な問題ではなく、商業的な問題です。」
BookAIの技術開発チームが直面した課題は、「LLMに創造性を持たせつつ、同時に書籍内容の境界を超えさせないようにするにはどうすればよいか？」ということでした。私たちはMivaのサブスクリプションメカニズムを通じて、以下の戦略を設計しました：
Miva Lite（無料）： 書籍の紹介と最も基本的な核心概念に限定。LLMの創造性は厳しく制限され、書籍の内容を忠実に伝えることに専念し、自由な発想や拡張は一切許可されません。
Miva Pro／Advanced（有料）： 異なるレベルでの創造的な拡張を許可。有料ユーザーは支払いプロセスを通じて、そのサービスに豊富なLLM機能が含まれていることを明確に認識しているため、ある程度の創造性を受け入れやすくなります。
サービスを差別化する具体的なインストラクションは次のようになります：
<Creative_Task_Handling_By_Tier>
- Creative tasks out of scope for Miva Lite.
- Example: "Miva Lite introduces books briefly. For creative explorations, Miva Pro offers more capabilities."
</Creative_Task_Handling_By_Tier>
このモジュールは、「創造的なタスク」（Creative Task）がMiva Liteのサービス範囲外であることを定義し、アップセルのプロトコルを設計することで、読者の期待を効果的に管理し、商業的な側面と認知的なバランスを両立させています。
▎シンプル、シンプル、シンプル。LLM制御の第一原理
MivaのBookAI System Prompt設計プロセスを振り返ると、当初は思いつくままに書き連ねていたため、後にMASが拡大した際に管理が困難になりました。そこから私たちが学んだ最も重要な原則は、「シンプルさとモジュール化」です。
LLMは出力時に、System PromptであれUser Promptであれ、入力されたすべてのコンテキストをサンプリングします。違いはサンプリングの重み付けだけです。そのため、実務上、インストラクションが複雑になるほどエラーの確率は高まり、デバッグも困難になります。インストラクションを可能な限りモジュール化し、各インストラクションを独立した「機能ユニット」として設計することが、インストラクションの競合（Prompt Conflict）というデバッグ需要に対応する上で唯一の方法です。
例えば、私たちは役割定義と機能モジュールを完全に分離しました：
‧役割モジュール（Miva Persona Core）
‧タスクモジュール（Core Mission）
‧フォーマットモジュール（Output Formatting）
‧処理モジュール（Tiered Logic Handling）
このようなモジュール化設計の利点は、各モジュールを他のモジュールに影響を与えることなく個別に調整・最適化できる点にあり、メンテナンスコストを大幅に削減し、チューニングの速度を向上させます。
インストラクションの設計が煩雑すぎると、インストラクションロジックが互いに衝突しやすくなります。LLMはクラッシュして「エラー」を表示することはありませんが、回答の品質は明らかに期待を下回ります。これこそがインストラクションデザイナーにとって最も頭の痛い問題であり、「BookAI System Prompt」プラットフォームの設計で厳格に管理している部分です。
▎挑戦は現場から生まれる
「学術的な温室から一歩外に出れば、そこは実戦の場」。現実の世界でいかに収益を上げ、利益を生み出すか。これがシステムインストラクションを設計する上での核心であり、最も芸術性が問われる部分です。最もシンプルな制御インストラクションと、最もモジュール化された設計を用いて、人間が管理しやすいアーキテクチャを構築し、LLMの振る舞いを全力で制御すること。
商業製品として、私たちが直面する試練は、3ヶ月ごとに大きく変化する技術だけでなく、ユーザー体験とビジネスモデルの要求にも常に注意を払う必要があります。
次回の記事では、「書籍に関連する答えがない」問題をどのように解決したか、マルチエージェントシステムがどのように協調して動作するのかをさらに掘り下げ、商業戦略、UXデザイン、そしてリーン原則が製品設計にどのように落とし込まれているかを詳しくお話しします。
（前編・完）