BookAIBookAI
Mivaの構築方法 | パート1:システムプロンプトからプロのAIストーリーテラーへ

Mivaの構築方法 | パート1:システムプロンプトからプロのAIストーリーテラーへ

BookAI Team

BookAI Team

June 17, 2025·5 分で読めます

Mivaの構築方法 | パート1:システムプロンプトからプロのAIストーリーテラーへ

  • Writer: 謝昆霖(Keanu)

    謝昆霖(Keanu)

How to Build Miva | Part 1

AIの分野において、プロンプトエンジニアリングは重要な技術です。BookAIでは、この役割を「Instruction Designer(指示設計者)」と呼んでいます。本連載では、BookAIチームがMivaを開発した実際の経験を共有し、慎重に設計されたシステムプロンプトと指示を通じて、信頼性の高いプロフェッショナルなAI読書システムをどのように構築したかを解説します。

▎ LLMの魂:BookAIシステムプロンプト

BookAIの製品、すなわちMiva Lite、Pro、およびAdvancedは、異なる利用シナリオに合わせて設計されたAI主導の読書サービスです。技術の中心にあるのは「検索(Retrieval)」です。当初の課題は、数十億の単語から効果的に検索を行い、読者の質問に的確に答えることでした。検索の概念実証(PoC)が成功裏に完了した後、技術的ロードマップが確立され、2024年の第2四半期には、語り部サービスのための「マルチエージェントシステム(MAS)」を構築することが重要な目標となりました。

当初、MASは非常に原始的なもので、ユーザーの意図を特定するエージェントと、本から学術的な回答を生成するエージェントの2つしかありませんでした。しかし2024年の第4四半期までに、MASは4つのエージェントに進化しました。当時、MASやエージェンティックワークフロー(Agentic Workflow)といった用語はほとんど聞かれず、私たちは手探りで進んでいました。

なぜすべてがそんなに複雑になってしまったのでしょうか?後で説明します!(笑)

検索された本の内容に基づいて生成されたエージェントのフレームワークは以下の通りです:

当初、私たちはMiva Lite、Pro、およびAdvancedを製品ラインとして計画し、Liteを無料版、他を有料版としました。そのため、普遍的で厳密なプラットフォームである「BookAIシステムプロンプト」を構築することが、全体的なアーキテクチャとサービスにとって不可欠となりました。

これを車のプラットフォームと考え、様々な車種のコア機能として機能するものと捉えてください。異なるエンジンが様々な種類の車を動かすように、多様なLLMモデルは各々に異なる強みを提供します——強力なものもあれば、繊細なものもあります。私たちのアーキテクチャはAIの回答の深さを誘導および制限し、各LLMの境界を明確に定義します。

以下は、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読書パートナー)、目標(本の中核となる概念を素早く理解させること)、そして回答スタイル(極めて簡潔で本に焦点を当てること)が明確に定義されます。この明確さにより、Miva Liteの対応範囲は本の基本的な紹介にとどまることが保証されます。

▎ サービスとしてのLLM(LLMaaS):Miva Liteのエージェントアーキテクチャ

Mivaファミリーの中でMiva Liteは最もシンプルな指示を持っています。それでもなお、「本の内容に基づいた回答」を行う単一のエージェントの指示には、20,000文字(6,130トークン)が含まれます。ProとAdvancedではさらに洗練されています。

MAS内では、オペレーション管理(Operation Management)の原則を採用し、各エージェントを独立したワークステーションとして扱い、役割、目的、入出力フォーマット、評価方法、およびエージェント間やデータとの相互作用を明確に定義しました。

BookAIでは、LLM-as-a-Service(LLMaaS)をごく初期の段階でキートレンドとして特定し、LLMの出力を制御することで差別化とマネタイズを図りました。

Miva Liteの「本の内容に基づく回答」の指示セットには、以下の重要なモジュールが含まれています:

  • ユーザーリクエスト処理モジュール:読者の質問を解析し、意図や言語を分析して、ユーザーが本当に知りたいことを見つけ出します。

  • 対話記憶管理モジュール:短期記憶・長期記憶の管理を通じて、無料版および有料版での本の検索機能を支援します。

  • 本の内容受信・引用機能モジュール:システムから取得した重み付けされたコンテンツの抜粋を管理し、ユーザーの意図に基づいてフィルタリングやマッチングを行います。

  • 応答生成モジュール:慎重に設計された指示を用いて、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>

これらの緻密に作成されたルールは情報過多を防ぎ、好奇心を刺激しさらなる探求を促すことで、ユーザーエクスペリエンスを向上させます。

こうしたアーキテクチャにより、応答コストの調整が可能になり、さまざまなLLMモデルを跨いで効率を最大化し、ビジネス面と技術面の両方において実現可能性をもたらしました。

▎ 本への忠実さか、AIの創造性か:サブスクリプションの境界を定義する

ビジネスの成功には、技術的な理想と商業的な現実のバランスが求められます。出版社からよく「もし本に答えがなかったら、Mivaは答えを作るのですか?」と聞かれます。私たちの答えはこうです。「技術的には、Mivaは常に答えを持っています。しかし、本の内容に厳密に従うかどうかは技術的な決定ではなく、商業的な決定です。」

私たちの設計上の課題は、本の内容の境界を越えることなく、LLMの創造性を引き出すことでした。そこで、当社のサブスクリプション戦略は次のようになります:

  • Miva Lite(無料版):厳密に本や基本概念の紹介にとどまり、創造的な拡張を制限して本の内容を忠実に伝えます。

  • 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>

このモジュールはユーザーの期待値を明確に管理し、ビジネスの実行可能性と認識の明確性のバランスを取っています。

▎ シンプルさ:LLM制御の第一原則

BookAIのシステムプロンプトの歴史を振り返ると、最初は非常に長く包括的な指示を書いており、後の管理に苦労しました。そこから学んだ最も重要な原則、それが「シンプルさとモジュール化」です。

LLMは、システムプロンプトやユーザープロンプトという呼称に関わらず、すべての入力されたコンテキストをサンプリングします。違いはサンプリングの重みだけです。実際のところ、指示が複雑になればなるほど、エラーの可能性が高まり、デバッグが難しくなります。プロンプトの衝突(prompt conflicts)のデバッグを容易にするには、各指示を独立した「機能ユニット」として扱うモジュール型での設計が重要です。

例えば、ロール定義機能モジュールを完全に分離しています:

  • ペルソナモジュール(Persona Module) (Miva Persona Core)

  • ミッションモジュール(Mission Module) (Core Mission)

  • 出力フォーマットモジュール(Output Formatting Module) (Output Formatting)

階層別論理処理モジュール(Tiered Logic Handling Module) (Tiered Logic Handling)

このモジュール化により、維持にかかる労力が劇的に減少し、柔軟性が向上しました。複雑すぎる指示のロジックはパフォーマンス上の問題を引き起こし、これはInstruction Designerにとって絶えず頭の痛い問題です。BookAIシステムプロンプト設計では、厳密なコントロールが求められます。

▎ 現実世界からの挑戦

学術界から現実の「戦場」に足を踏み入れると、収益性が鍵を握るようになります。簡潔で、モジュール化され、人間が管理しやすいアーキテクチャを使ってLLMの挙動を効果的に制御することは、もはや単なる技術課題ではなく、芸術的な挑戦でもあります。

商業製品としてのBookAIは、急速に進化する技術、UX、ビジネスモデルに常に適応し続けなければなりません。

次の記事では、「本に答えがない場合の対応」、マルチエージェントシステムのコラボレーション、および製品開発における商業戦略、UXデザイン、リーン原則の統合について議論します。

どうぞお楽しみに!

(続く)