公式のWeKnora説明では、RAG、Agent、MCP、サンドボックス、自動Wikiという5つの機能領域が示されています。公式の中国語README から分かるのは、WeKoraナレッジベースのコストを文書数だけで決められないということです。最短の解決策は、データ処理、検索・保存、モデル、Agent、実行環境、運用の6項目に分解し、最初はローカルまたは低同時実行数で検証することです。
企業のナレッジベース担当者は、RAGとAgentの予算根拠を説明したい場合に読んでください。プロダクトエンジニアは、文書投入、検索、ツール呼び出し、自動Wikiのどこで資源を使うかを切り分けたい場合に役立ちます。個人開発者は、クラウド上の作業環境を常時稼働させる前に、利用量に応じた上限を作れます。
最初にWeKoraナレッジベースのコストを6つに分ける
WeKnoraの導入予算は、次のように分けると説明しやすくなります。
- データ処理：PDFやオフィス文書の読み取り、分割、メタデータ抽出、埋め込み生成。
- 索引と保存：ベクトル索引、キーワード索引、原文、履歴、バックアップ。
- RAG回答：検索、再ランキング、コンテキスト作成、回答生成。
- AgentとMCP：複数回の推論、ツール呼び出し、外部検索、処理結果の再投入。
- サンドボックスと自動Wiki：コード実行、ファイル操作、長時間タスク、Wiki生成。
- 運用：監視、ログ、権限管理、障害対応、更新、バックアップ、アクセス制御。
この分類では、初回だけ発生する費用と、利用量に応じて増える費用を混ぜません。さらに、予算を「一度きりの導入」「継続運転」「利用量の増加後」の3層に分けると、試験環境の費用を本番運用の金額と誤認しにくくなります。
注意：料金や必要なリソースは、採用するモデル、文書形式、更新頻度、同時実行数、保存方針で変わります。根拠を確認できない単価や月額を、固定の相場として予算書へ転記しないでください。
第一歩：文書の取り込みを3つの処理に分ける
文書処理では、初回取り込み、増分同期、大規模な再構築を別のシナリオとして記録します。初回取り込みは対象文書を一括解析し、分割と埋め込みを行うため、保存データが少なくても処理時間と一時領域が膨らむ可能性があります。
増分同期では、変更された文書だけを再処理できるかが重要です。ファイル全体を毎回取り込む設計なら、文書数が変わらなくても処理量が増えます。大規模な再構築では、古い索引を保持したまま新しい索引を作るため、保存領域と一時的な計算資源を別に確保する必要があります。
WeKnoraの文書読み取りに関する環境変数は、公式DocReaderの設定説明 と 公式の環境変数テンプレート で確認できます。予算表には、次の変数をそのまま記録してください。
- 新規文書の容量とファイル形式
- 1日または1週間あたりの追加・変更文書数
- OCRや表抽出が必要な割合
- 分割後のチャンク数
- 埋め込みを再生成する条件
- 旧版保持、削除、ロールバックの期間
- 取り込み失敗時の再試行方法
文書の「件数」だけでは、画像中心のPDFとテキスト中心のMarkdownを同じ負荷として扱ってしまいます。容量、抽出難度、更新頻度を別々に測定してください。
第二歩：RAG回答の費用を検索経路ごとに記録する
RAGの1回答は、単純なモデル呼び出し1回ではありません。質問の前処理、ベクトル検索、キーワード検索、再ランキング、コンテキストの結合、生成モデルによる回答という複数の処理に分けて記録します。
検索側では、ベクトル検索だけを使うのか、キーワード検索を組み合わせるのか、再ランキングを行うのかで処理回数が変わります。ハイブリッド検索の考え方は、公式のテキスト検索・ハイブリッド検索資料 で確認できます。再ランキングを使う場合は、公式の再ランキング例 のように、候補を絞り込む段階そのものを別の計算項目として扱います。
見積もりには、次の式を使うと説明しやすくなります。
月間RAG処理量 ＝ 月間質問数 × 1質問あたりの検索回数
月間モデル入力量 ＝ 月間質問数 ×（質問トークン＋検索結果トークン＋指示文トークン）
重要なのは、質問数だけでなく、1質問あたりの検索回数とコンテキスト長を記録することです。回答の根拠を増やすために検索結果を大量に渡すと、生成モデルの入力と応答時間が増えます。一方で、コンテキストを削りすぎると、回答の正確性や引用可能性が落ちます。
場面別の判断：平均質問と重い質問を分ける
平均的なFAQは、短い検索と1回の回答生成で終わるかもしれません。しかし、複数文書の比較、権限確認、計算、外部情報の参照を含む質問は、同じ1件でも処理段階が増えます。
予算では、次の3種類を別に集計します。
- 通常質問：固定された社内文書から回答する処理。
- 複雑質問：複数回検索し、長いコンテキストを生成する処理。
- 失敗・再試行：タイムアウト、形式不正、根拠不足による再実行。
「質問件数×平均単価」だけで計算すると、少数の重い質問が全体の資源を押し上げる状況を見落とします。週ごとに処理時間、入力・出力トークン、検索回数、失敗率を記録し、通常質問と複雑質問の比率を修正してください。
第三歩：Agent、MCP、自動Wikiはタスク単位で見積もる
Agent導入では、質問ではなく「完了したタスク」を数えます。1タスクの中で、計画、検索、MCPツール呼び出し、結果確認、追加推論、最終回答が繰り返されるためです。
WeKnoraの機能境界に含まれるAgent、MCP、サンドボックス、自動Wikiについては、公式READMEの機能説明 と 公式サンドボックス文書 を基準に、実際に有効化する機能だけを予算へ入れます。
計算の基本形は次のとおりです。
月間Agent負荷 ＝ 月間タスク数 × 1タスクあたりの推論回数
月間ツール負荷 ＝ 月間タスク数 × 平均ツール呼び出し回数
月間実行負荷 ＝ サンドボックス実行時間の合計 ＋ 失敗時の再実行時間
ブラウザー操作、外部検索、コード実行、ファイル変換を含むタスクは、通常のRAG回答と同じ予算枠に入れないでください。特に失敗時の再試行が自動化されている場合、表面上のタスク数より実行回数が多くなります。
自動Wikiも、生成したページ数だけでは不十分です。情報源の検索回数、ページ間のリンク生成、更新時の差分確認、誤生成の修正を記録します。最初は「1タスクあたりの最大ツール呼び出し数」と「サンドボックスの最大実行時間」を決め、上限を超えた処理を人間の確認へ戻す設計が安全です。
第四歩：条件分岐でローカル、クラウド、混合構成を選ぶ
WeKnoraをローカルで検証するか、クラウドへ常駐させるかは、単純な安さではなく、データ境界、同時実行数、運用担当者の有無で決めます。公式の構成を確認する際は、公式Docker Compose構成 と各機能の環境変数を照合してください。
導入前の決定チェックリスト
次の条件に当てはまる項目を確認し、上から順に構成を決めてください。
-
[ ] 機密文書を外部のモデルや保存領域へ送れない
→ ローカル構成を第一候補にします。外部サービスへ接続する機能は分離し、認証情報とログの保存場所を個別に確認します。 -
[ ] 利用者が限定され、機能確認が目的である
→ ローカルまたは低同時実行数の検証環境へ戻します。常時稼働するクラウド環境を先に契約しないでください。 -
[ ] 常時アクセス、遠隔操作、Agentの長時間処理のいずれかが必要である
→ クラウド構成を候補にします。計算資源だけでなく、保存、監視、通信経路、権限管理を継続費用として記録します。 -
[ ] 文書保管は内側に置き、推論や一部の実行環境だけを外部へ出したい
→ 混合構成を検討します。データ転送、認証、接続障害、処理結果の一時保存を追加項目にします。 -
[ ] 長期にわたり高負荷処理が安定して続き、物理機器を管理できる
→ 自前運用も比較します。購入費だけでなく、保守、電力、更新、障害復旧を含めて判断します。 -
[ ] 短期検証、季節的な負荷、期間限定のチーム利用である
→ 固定設備を購入する前に、必要な期間だけレンタルする構成へ戻します。
このチェックリストで複数の条件が衝突する場合は、データ保管場所を最優先にし、その次に同時実行数と運用体制を比較します。単純な月額だけでクラウドかローカルかを決めると、バックアップや障害対応の見えない作業が後から増えます。
導入先のアカウントや注文条件を整理する場合は、Macstripeの注文設定ガイド も確認できます。これはWeKnoraの料金表ではなく、実行環境を用意する際の確認項目を整理するための案内です。
第五歩：週次レビューで予算モデルを修正する
予算は公開前に一度作って終わりではありません。毎週、次の項目を同じ定義で記録し、見積もりと実績の差を確認してください。
- 追加・更新された文書量
- チャンク数と再埋め込み件数
- RAG質問数と検索回数
- 通常質問、複雑質問、失敗再試行の割合
- Agentタスク数とツール呼び出し数
- サンドボックスの実行時間
- 保存容量、索引更新時間、バックアップ量
- エラー率、タイムアウト、手動対応件数
- 同時実行数と処理待ち時間
本番化する前に、最大コンテキスト長、1タスクあたりのツール呼び出し上限、サンドボックスのタイムアウト、異常時の再試行回数を設定します。運用時の確認項目は、本番環境向けの公式チェック項目 と照合し、検索基盤だけでなく、権限、バックアップ、監視、障害復旧まで含めてください。
予算が想定を超えた場合は、いきなりモデルを小さくするのではなく、どの場面が増えたかを特定します。文書更新が原因なら増分処理、検索負荷が原因なら候補数と再ランキング、Agent負荷が原因ならツール上限と失敗再試行を見直します。
よくある質問
WeKora（WeKnora）の導入前に、どの費用を洗い出せばよいですか？
初期導入だけでなく、文書の解析と埋め込み、検索インデックス、生成モデル、Agentのツール呼び出し、サンドボックス、監視と障害対応を分けて確認します。文書数だけで見積もると、更新頻度や質問量が増えた時のモデル費用と実行基盤の負荷を見落とします。
WeKnoraのRAGナレッジベースは、どう予算化すればよいですか？
まず月間の新規文書量、更新量、質問数、1質問あたりの検索回数、入力コンテキスト量を記録します。そのうえで、取り込み処理、ベクトル検索、キーワード検索、再ランキング、回答生成を別の変数として計算し、実測値を週単位で更新します。
企業ナレッジベースのモデル呼び出しとベクトル保存費用はどう分けますか？
モデル呼び出しは、文書取り込み時の埋め込み、検索時の再ランキング、回答生成、Agentの追加推論に分けます。ベクトル保存はデータ容量だけでなく、インデックスの更新、複製、バックアップ、検索負荷に左右されるため、モデル費用とは別の保存・運用項目として管理します。
WeKnoraはローカル環境とクラウド環境のどちらが向いていますか？
少量の社内文書で機能確認をする段階なら、ローカルまたは低い同時実行数の環境が管理しやすいです。外部利用者が増え、常時アクセス、Agentの長時間処理、遠隔からの運用が必要になった場合は、クラウドまたは混合構成を検討します。機密データを外部へ出せない場合は、保管場所とモデル接続先を分離して判断します。
