AIの利用量とコスト

従量制AIは、ドキュメント製品において、誤った数字が所有者に実際のお金の損失をもたらす部分です。このページでは、その仕組みを説明します。何が計測され、呼び出しにどのような料金が設定され、どの残高から差し引かれ、後から何を確認できるのか、そして2つの異なる画面に表示される数値が正当に異なる場合について説明します。

得られるもの#

プロジェクトが行うすべての AI 呼び出し — 読者の質問、パネル内での自分の質問、翻訳、埋め込みの実行、エージェントのステップ — では、それを消費したサーフェス、実行したモデル、入出力のトークン数、プロバイダーが請求した金額、残高から差し引かれた金額を記録した行が書き込まれます。メーター制の MCP ツール呼び出しでは、ツールとその課金クラスを記録した行がそれぞれ書き込まれます。

これらの行から、支出をモデル別、サーフェス別、予算カテゴリ別、会話別、翻訳言語とページ別、MCP ツール別に確認でき、それぞれについて日ごとの推移も確認できます。分析概要にある見出しの支出タイルは、2 つの台帳を合計したものです。

これらを確認するのは無料です。読者に回答するには料金がかかります。

残高を消費するもの、消費しないもの#

使用量はリクエスト数ではなく金額で計測されます。各呼び出しでは、その呼び出しに設定された 料金分が消費されるため、より安価なモデルを選ぶと同じ残高をより長く利用できます。これがモデル ピッカーの目的であり、すべてのプランで利用できます。

読者イベントは料金が設定されていますが、請求されることはありません。 Usageビューでは各イベント種別の横に数値が 表示されるため、トラフィックが示す内容を確認できますが、どの項目からも差し引かれません。 請求対象の金額と計測のみの金額は別々の合計として管理されるため、1つの画面で後者が請求書として 表示されることは決してありません。

独自のプロバイダーキーを使用した呼び出しは計測されますが、請求はされません。行は引き続き 記録されます。プロバイダーの実際のコスト、使用モデル、トークン数が記録され、削除する代わりに ゼロとして料金が設定されます。これは、キー上にあるという理由だけで内訳からモデルが欠落すると、 「そのモデルは一度も呼び出していない」と受け取られるためです。これらの呼び出しも別途カウントされるため、 実際の使用量の横にある $0 も、壊れているように見えるのではなく、その意味が説明されます。 独自のキーを使用しても、プランに含まれる内容は変わりません。

構築方法#

意図的に1つのテーブルにしていない2つの課金台帳#

MCP呼び出しにはトークン請求がなく、名前、クラス、固定された定価があるだけだからです。また、MCP呼び出しの大部分（プロジェクトの検出や一覧表示）は、どのプロジェクトにも属していません。これらを任意のプロジェクトに対して記録すると、使用量チャートが事実として表示する、作為的な帰属になってしまいます。

呼び出しの料金の決まり方#

1. プロバイダー自身が報告したコストを優先します。 プロバイダーが呼び出しにかかったコストを返す場合は、 その数値をそのまま使用し、行に推定の印は付けません。これはローカルでの計算よりも信頼できます。 プロンプトキャッシュの割引や、処理中に行われた料金変更もすでに反映されているためです。
2. それ以外の場合は、モデルのカタログ料金を使用します。 レスポンスから取得した実際のプロンプトトークン数と完了トークン数に、 そのモデルの100万トークンあたりの入力料金と出力料金を掛け合わせます。カタログにはそれぞれ固有の料金を持つチャットモデルが12種類あり、 別途、埋め込みモデルのカタログもあります。
3. 認識されないモデルには、意図的に悲観的なフォールバック料金が適用されます。 その行には estimated のフラグが付けられるため、すべての画面で事実としてではなく推測として表示できます。モデルの検索は完全一致のみで、曖昧検索は行いません。 部分文字列による照合では、かつて -mini モデルに、そのフルサイズ版の同名モデルの料金が適用されてしまったためです。

その後、マークアップが適用され、行に固定されます。そのため、料金が変更されても過去の行が正確なまま保たれます。

トークン数は、モデルAPI自身の使用量レポートから取得します。Docsbookはテキストの長さから推測しません。

ミリセントと重要な丸め処理#

プロバイダーのコストは、ミリセント（セントの千分の一）単位で保存されます — 1 回の安価な回答のコストは 1 セントのごく一部であり、整数セント単位では ほぼすべての行がゼロに丸められ、内訳グラフが実態と異なってしまうためです。

ウォレットから出ていく金額は整数セント単位です。差し引き額は整数セント単位に切り捨てられ、 余りはプロジェクトに繰り越されるため、100 回の 1 セント未満の回答で最終的に 1 セントが消費され、 免除されたり過剰請求されたりすることはありません。 金額は、まずトライアルクレジット、次に月間 allowance、最後に一回限りの残高の順で消費されます。

画面上で確認できる結果。ウォレットからその呼び出しで実際に出ていった金額を記録する列は、 ほぼすべての行で 0 です。これは、1 セント未満の呼び出しでは繰り越し分しか移動しないためです。 そのため、新しい画面である Spend タイルと Usage ビューでは、その列を合計するのではなく、 プロバイダーのコストと固定されたマークアップから各行の定価を再構築します。一方、2 つの古い画面では引き続きその列を合計します。 この 2 つの表示が一致しない場合は、再構築された値のほうが実態をより正確に表しています。

残高がなくなるとどうなるか#

Docsbookは従量課金制です。残高は自動的に補充されず、残高がなくなってもサイトに 変更はありません。停止するのはAIによる処理だけであり、しかも自己説明できる 場所で停止します。

これらは予約ではなくチェックであるため、ウォレットの残高が空になった後も最大で 1回分だけ超過する可能性があります。次の呼び出しは安全側に倒して失敗します。

超過利用は強制停止に代わる選択肢であり、利用者が明示的に選択した場合のみ有効で、有料プラン 限定です。上限が設定され、固定間隔で課金され、上限の75%、85%、90%、95%、100%に 達する過程で使用量Webhookを通じて通知されます。翻訳とセマンティック インデックスがこれを利用することは意図的にありません。インデックスの実行は大規模で意図的な キャンセル可能な処理であり、それをひそかに超過料金の請求へと変えるのは 利用者にとって不親切だからです。

チャットページ#

チャットページでは、アシスタントに何を尋ね、回答にいくらかかったかを、期間を指定せずに一連の会話について表示します。そのため、タイルとその下のリストが異なる対象を示すことはありません。

「回答済み」は推測ではなく、読み取りに基づいて判定されます。 以前のシグナルである引用のクリック、いいね、外部リンクのクリックは、両方向に誤りが生じる代理指標です。完璧な回答を得て何もクリックしなかった読者は未評価として扱われ、引用されたページを読まずにクリックした読者は回答済みとして扱われます。代わりに、別のモデル処理で各トランスクリプトを読み取ります。判定結果は一度だけ書き込まれて再利用され、新しい会話のうち判定されるのはページの読み込みごとにごく少数だけです。そのため、初回の読み込みをタイムアウトさせるのではなく、数回の訪問を経て数値が埋まっていきます。判定済みの会話が5件未満の場合、タイルは以前の読み取り方式にフォールバックし、そのことを表示します。判定待ちの会話は未判定として表示され、未回答として表示されることはありません。

タイルにカーソルを合わせると、過去24時間の数値がある場合はその数値が表示されます。「回答済み」は割合ではなく件数（「3件中2件」）を表示します。1日だけでは、会話1件ごとに割合が大きく変動するためです。収益とコストには個別の日次数値はありません。どちらも、画面上ですでに表示されている期間を対象に読み取られます。

これが正しい方法である理由#

制限事項と未解決の疑問#

• プロバイダー別に支出を分けて表示することはできません。 台帳に記録されるのはモデルであり、 その背後にあるベンダーではないため、「Anthropicにいくら支払ったか」という質問には、 現在のプロダクトでは答えられません。
• トークン台帳でエージェントの実行ごとの支出を確認することは、まだできません。 MCPの行には それを実行した実行情報が含まれますが、トークンの行に含まれるのは自由形式の 会話IDだけです。そのため、エージェントのモデル料金は実行ごとではなく、 会話ごとにまとめられます。
• estimatedと表示された行は推測値であり、フォールバック料金は意図的に高く設定されています。 カタログにないモデルには、 意図的に悲観的な料金が設定されます。料金設定のないモデルについて顧客への請求が 不足するほうが、より悪い誤りだからです。そのため、推定行は測定値ではなく、 上限値です。
• 以前からある2つの画面では、控除セント列を合計したままになっています。 そのため、 呼び出しの大半が1セント未満であるプロジェクトでは、過少報告になります。Spendタイルと Usageビューでは、代わりに定価を再計算します。2つの支出額が一致しない場合は、 それが理由です。
• 節約額は推定値であり、そのように表示されています。 回答済みの会話数に、業界標準の サポートチケット費用を掛けて算出します。これはお客様のサポート費用ではなく、 Docsbookが実際に測定したものでもありません。
• 自分のキーを使用した支出は、金額としては表示されません。 これらの呼び出しでは利用量、モデルの内訳、 トークン数、$0が表示されます。実際にかかった費用は、プロバイダーの 請求書で確認できます。
• レポートと保持期間は同じ長さではありません。 パネルに表示される利用状況は30日分を超えず、 リーダー分析の終了期間と一致します。一方、AI台帳自体は90日間保持されます。これは、 異議のある請求を再構築できるようにするための余裕であり、毎日削除処理が行われます。MCPの呼び出し行は 現在のところまったく削除されないため、ツールごとのビューは全期間のデータになっています。
• 未解決の問い：「Savings」と「Revenue」はモデルであり、「Cost」は測定値です。 検証できるのは台帳です。 どのモデルが実行され、プロバイダーがいくら請求し、残高からいくら差し引かれたかを確認できます。 このデータから検証できないのは、回答された質問がなければサポートチケットになっていたかどうか、 またはチャットを利用した読者が、利用しなければ購入していなかったかどうかです。 2つの収入額は読者間の順位として捉え、決して現金額として捉えないでください。

どのプラン#

読者向けアシスタント、エージェントの実行、自動翻訳は、Docsbook のプロバイダーキーで料金が発生する機能であり、有料です。その他のすべて — 台帳、内訳、モデルの選択、自分のキーの使用、MCP — は、このページのすべてのプランで利用できます。特に MCP にはプランによる制限がまったくなく、唯一の制限は費用です。現在のプランと料金については料金ページをご覧ください。

確認場所#

1. トラフィックの横に表示される、時間経過に伴う支出 — 分析概要の Spendタイル。
2. 何に支出したか — Usageビュー：AIはサーフェス、カテゴリ、モデル別、MCPはツールとクラス別、 料金設定はされているものの請求されていないイベント。期間は 24時間、7日間、30日間です。
3. チャットで何を依頼し、いくらかかったか — 管理者サイドバーのChat行。 会話を開くと、その文字起こしと個別の コスト内訳を確認できます。
4. エージェントから — get_ai_usage 経由の MCP。

関連#

• 分析の概要 — Spendタイルとフィルター適用時の動作
• 測定の仕組み — データの保持と保存場所
• 追跡イベント — これらの会話の背後にあるチャットイベント
• AIチャット — モデルとプロバイダーの選択
• AI翻訳の仕組み — この残高を消費するもう1つの機能
• Webhooks — 上限に近づいたことを、事後に知るのではなく通知してもらう