2026-10-13時点の公開料金を確認し、問い合わせAIの月次費用を架空条件で計算した設計検討です。確認したのはローカルの計算ロジックで、実LLMの品質・応答時間・実業務の削減効果は未検証です。

結論：API単価より先に、レビューを含む処理経路を決める

AIが回答の下書きを作っても、人が根拠を読み直し、修正してから送るなら、その時間は残ります。費用を比較する単位は「1回のAPI呼び出し」より、「問い合わせ1件を同じ完了条件まで処理する費用」です。

開発担当・テックリードが判断したいのは、AI下書きを試すか、FAQ改善や有人対応を続けるかです。この記事では、API料金・レビュー・有人対応・保守を分けて再計算します。

判断	条件
限定したPoCへ進む	回答品質の基準を先に決め、確認・修正を含む工数を測れる。費用に余裕があり、保守担当がいる
いったん見送る	レビュー費だけで比較基準を超える、あるいは知識の更新・誤回答の対応担当を置けない
追加検証する	APIのusageは取れるが、レビュー時間・有人への戻り・再生成回数が未測定

安価なモデルへの変更だけで導入を決めると、修正時間の増加を見落とします。品質条件を満たさない方式は、費用比較の候補から外します。

前提：AI下書きと、最初から人が対応する経路を分ける

以下はすべて架空の計画値です。問い合わせ本文や業務データは使っていません。

項目	仮定
月間問い合わせ	1,000件
比較基準	全件を人が対応し、1件6分で確認・修正・送信まで完了
工数の評価単価	3,000円/時間
AI下書きの対象	70%＝700件。全件を人がレビューして送信
最初から有人へ回す対象	30%＝300件、各6分。LLMを呼ぶ前に既存の受付ルールで振り分ける仮定
AI下書きのレビュー	基本ケースは1件2分。根拠確認・修正・送信までを含む
維持・評価・障害対応	月12時間×3,000円＝36,000円
追加基盤費	月5,000円
初期構築費の比較上の配賦	120,000円÷12か月＝月10,000円
為替の計算条件	1 USD＝150円。市場の為替レートではない仮定

既存の受付基盤など両方式に共通する費用は比較から除き、AI方式の追加費用を計上します。税、検索・埋め込み・外部ツールの課金、学習費、誤回答による損失、移行・撤退費は別途見積もる項目です。

この工数価値の差は、そのまま支出削減や現金利益にはなりません。 固定給の担当者の時間が空く場合、実支出より対応可能な仕事量が変わることがあります。初期構築費も、12か月への配賦とは別に、支払い時点の資金負担を確認します。

700件へのレビュー費と300件への有人対応費は、別の集団に対する費用です。AI下書きを読んだ後で全面的に人へ戻るケースがあるなら、その件にはレビュー費と追加の有人対応費の両方が発生します。今回の簡易モデルにはその戻りを入れていないため、実測時に追加が必要です。

選択肢：現状維持・FAQ改善・既製品も同じ完了条件で比較する

方式	主に測る費用	採用を検討する条件	採用しない条件
有人対応を維持	処理件数×完了までの時間	件数が少なく、問い合わせの変化が大きい	応対の滞留が増え、担当を増やせない
FAQと検索を改善	知識整備・検索運用・残る有人対応	既存の定型回答で解決できる	検索だけでは必要な条件を説明できない
既製品のAI下書き	契約・従量・設定・レビュー・移行	権限・ログ・引き継ぎが要件を満たす	必須の運用条件を満たさない、追加費用が不明
自作のAI下書き	推論・レビュー・基盤・品質評価・保守	独自の品質ゲートが必要で、維持担当がいる	API料金だけを根拠に安いと判断している

表は選択肢を整理する設計案です。今回、FAQや既製品の価格・品質は比較実験していません。それらを数値上の勝者・敗者にはせず、同じ問い集合と完了条件で次に比較します。

料金の根拠と、再試行を含む計算式

料金式の例にはClaude Sonnet 5.5の通常の入力・出力料金を使います。2026-10-13に確認した公式表では、100万トークンあたり入力2 USD、出力10 USDです。今回はキャッシュなし・追加ツール課金なしの条件です。品質・遅延・この用途への適性は未評価です。Claude公式料金表

実運用では請求対象となった各試行のusageを合計します。キャッシュなど別の料金区分を使う場合は、その区分を分けて単価を適用します。文字数をトークン数に置き換えたり、最終的に成功した1回だけを数えたりしません。

LLM費用（USD）＝ Σ（各試行の入力tokens×入力単価
                       ＋各試行の出力tokens×出力単価）÷1,000,000

月次総費用（円）＝ LLM費用×為替の計算条件
                  ＋AI対象件数×レビュー分÷60×工数単価
                  ＋有人対象件数×有人対応分÷60×工数単価
                  ＋維持工数費＋追加基盤費＋初期費の月次配賦

試算では各試行のトークン量が同じと仮定し、合計を「AI対象件数×平均課金対象試行数×1試行の料金」で近似します。基本ケースは入力2,000・出力300トークン、平均試行数1.1です。1.1は初回を含む試行数で、初回に1.1回の再試行を加える意味ではありません。 700件なら770回相当です。これらは実usageや再試行の実測値ではありません。

キャッシュの読み書きやツール利用には別の料金区分があるため、同じ式の入力単価だけを機械的に差し替えないでください。契約経路と利用機能に合わせて確認します。Claude公式料金表

ローカル検証：API料金とレビュー時間を別々に動かす

Pythonの標準ライブラリdecimalを使い、APIに接続せず計算しました。入力値の単位を固定し、負値・非有限値、対象率や平均試行数などの不正値を拒否します。計算例の対象は掲載した条件の桁数です。極端に巨大・微小な値は対象外で、decimal.Overflow等が発生する場合があります。計算精度は28桁とし、金額表示を小数点以下2桁へ整えるのは表示時だけです。

実行手順は、以下のコードをcost_example.pyへ保存してpython3 cost_example.pyです。送信や課金は発生しません。

from decimal import Decimal as D, InvalidOperation, localcontext

FIXTURE = {
    "n": 1000, "ai_share": "0.7", "review_minutes": "2",
    "handling_minutes": "6", "manual_minutes": "6",
    "billed_attempts": "1.1", "input_tokens": "2000", "output_tokens": "300",
    "input_usd_mtok": "2", "output_usd_mtok": "10",
    "usd_jpy": "150", "labor_jpy_hour": "3000",
    "ops_hours": "12", "infra_jpy": "5000", "build_jpy": "120000",
    "amort_months": "12",
}

DECIMAL_FIELDS = tuple(key for key in FIXTURE if key != "n")

def nonnegative_decimal(name, value):
    if isinstance(value, bool):
        raise ValueError(f"{name}: bool is not a number")
    try:
        number = D(str(value))
    except (InvalidOperation, ValueError):
        raise ValueError(f"{name}: decimal required") from None
    if not number.is_finite() or number < 0:
        raise ValueError(f"{name}: finite nonnegative value required")
    return number

def calculate_cost(params):
    """初回を含む課金回数。事前分岐した人間対応とAIレビューは重複しない。"""
    n = params["n"]
    if type(n) is not int or n < 0:
        raise ValueError("n: nonnegative integer required (excluding bool)")
    p = {key: nonnegative_decimal(key, params[key]) for key in DECIMAL_FIELDS}
    if p["ai_share"] > 1 or p["billed_attempts"] < 1:
        raise ValueError("ai_share must be <= 1; billed_attempts must be >= 1")
    if any(p[key] == 0 for key in ("labor_jpy_hour", "usd_jpy", "amort_months")):
        raise ValueError("labor_jpy_hour, usd_jpy, amort_months must be positive")
    with localcontext() as context:
        context.prec = 28
        ai = n * p["ai_share"]
        handoffs = D(n) - ai
        billed = ai * p["billed_attempts"]
        api_usd = billed * (p["input_tokens"] * p["input_usd_mtok"]
                           + p["output_tokens"] * p["output_usd_mtok"]) / D(1_000_000)
        api_jpy = api_usd * p["usd_jpy"]
        labor_per_minute = p["labor_jpy_hour"] / D(60)
        review = ai * p["review_minutes"] * labor_per_minute
        handling = handoffs * p["handling_minutes"] * labor_per_minute
        ops = p["ops_hours"] * p["labor_jpy_hour"]
        amortized = p["build_jpy"] / p["amort_months"]
        fixed = ops + p["infra_jpy"] + amortized
        manual = n * p["manual_minutes"] * labor_per_minute
        budget = manual - handling - fixed - api_jpy
        total = api_jpy + review + handling + fixed
        # 閾値の表示値は丸めを含む。判定はレビュー費用と予算の直接比較。
        threshold = budget / (ai * labor_per_minute) if ai else None
        return {
            "ai_drafts": ai, "handoffs": handoffs, "billed_attempts_total": billed,
            "api_usd": api_usd, "api_jpy": api_jpy,
            "review_jpy": review, "handoff_jpy": handling,
            "ops_jpy": ops, "infra_jpy": p["infra_jpy"],
            "build_amortized_jpy": amortized, "fixed_jpy": fixed,
            "total_jpy": total, "manual_jpy": manual, "savings_jpy": manual - total,
            "review_budget_jpy": budget, "break_even_review_minutes": threshold,
            "saving_positive": review < budget,
        }

long_context = {"input_tokens": "12000", "output_tokens": "800", "billed_attempts": "1.4"}
cases = {
    "base": {},
    "long-2min": long_context,
    "long-4min": {**long_context, "review_minutes": "4"},
    "long-4.5min": {**long_context, "review_minutes": "4.5"},
}
for name, changes in cases.items():
    result = calculate_cost({**FIXTURE, **changes})
    print(f'{name}: API={result["api_jpy"]:.2f}, '
          f'total={result["total_jpy"]:.2f}, '
          f'difference={result["savings_jpy"]:.2f}, '
          f'below_baseline={result["saving_positive"]}')

実行結果：

base: API=808.50, total=211808.50, difference=88191.50, below_baseline=True
long-2min: API=4704.00, total=215704.00, difference=84296.00, below_baseline=True
long-4min: API=4704.00, total=285704.00, difference=14296.00, below_baseline=True
long-4.5min: API=4704.00, total=303204.00, difference=-3204.00, below_baseline=False

検証環境はPython 3.14.3、標準ライブラリのみです。上の掲載コードの出力と比較表を照合しました。別途、正常系、対象0件、AI対象率0・1、不正値、再試行、費用同額・超過、入力の非破壊など167項目の回帰チェックを実行しました。これらは計算式と入力境界の確認であり、実LLMや問い合わせ品質の評価ではありません。

架空条件の計算結果

4ケースともAI対象率70%、有人対応30%、固定費51,000円です。「長文」は入力12,000・出力800トークン、平均課金対象試行数1.4へ変えた条件です。モデルの品質が同等という実験結果を示すものではありません。

ケース	LLM費（円）	レビュー費（円）	有人対応費（円）	固定費（円）	総費用（円）	有人基準300,000円との差
基本：レビュー2分	808.50	70,000	90,000	51,000	211,808.50	88,191.50円下回る
長文：レビュー2分	4,704	70,000	90,000	51,000	215,704	84,296円下回る
長文：レビュー4分	4,704	140,000	90,000	51,000	285,704	14,296円下回る
長文：レビュー4.5分	4,704	157,500	90,000	51,000	303,204	3,204円上回る

長文化と試行数の増加による差は3,895.50円。一方、長文ケースでレビューが2分から4分へ増える差は70,000円です。この仮定では、APIの入力を削る施策だけより、根拠確認・修正にかかる時間の測定が判断を変えます。

レビュー時間の境界は、予算から逆算できる

長文ケースでレビューに使える比較上の予算は次の値です。

300,000 − 4,704 − 90,000 − 51,000 ＝ 154,296円
レビュー1分増の月次費用 ＝ 700÷60×3,000 ＝ 35,000円
比較基準と等しくなるレビュー分 ＝ 154,296÷35,000
                                  ＝ 約4.408457分/件

「4.41分まで大丈夫」と丸めて運用上限にすると、わずかに比較基準を超えます。判定にはレビュー費＜残りの比較予算を使い、時間表示の丸め値は使いません。費用が等しい場合にも、新たな運用リスクに見合う余裕がありません。

この境界は、ここに置いた単価・対象率・保守費などが成立する場合の計算値です。未計上費用や測定誤差を含む余裕を別に設定します。品質ゲートを緩めてレビューを短くする判断には使いません。

本番で費用を増やす失敗と、確認する担当

失敗	必要な測定・制約	判断する担当
FAQ全文や会話履歴を毎回送る	1試行の入力量、必要な根拠の欠落、回答品質を一緒に評価する	検索・アプリ担当
レビューを「承認ボタンの時間」だけで計る	根拠確認、修正、送信、後日の訂正を含む時間を記録する	応対担当・業務責任者
失敗のたびに無制限に再生成する	試行数・出力量・総予算・時間の上限を決める	アプリ・運用担当
タイムアウトを無課金と見なす	usage未取得を「0円」へ確定せず、結果不明として請求と照合する	運用・費用管理担当
安いモデルへ替えて確認が長くなる	同じ評価セットで品質とレビュー時間を比較する	評価担当・開発責任者
月平均だけ見てピークを隠す	問い合わせ種別ごとの分布、上位の費用・工数、滞留を確認する	業務・運用担当

OWASPは、制御されない推論が資源消費や費用増につながるリスクを示し、入力制限・利用量制限・タイムアウト・監視などを挙げています。これは公式資料で確認できる一般的なリスクです。OWASP LLM10:2025 Unbounded Consumption

その対策として、生成前に予算を予約し、呼び出し後に実usageと照合する設計を検討します。並行実行がある場合は予算予約も排他的に更新し、結果不明分の予約を即座に解放しません。予約だけで実請求の上限を保証できるわけではなく、最大出力やツール呼び出しも制限し、超過を検知したら新規生成を止める必要があります。これは設計案であり、掲載コードは予算制御・並行処理・請求照合を実装していません。

ログには、公開可能な相関ID、モデル・料金確認日、試行番号、課金区分ごとのusage、処理経路、レビュー・追加有人対応の時間、結果不明の状態を分けて残します。問い合わせ本文・秘密情報を費用ログへ一括保存する設計は避けます。

条件付きの推奨と、次に確認すること

この架空条件なら、AI下書き方式を限定PoCで測る余地があります。長文・レビュー4分では差が14,296円まで縮むため、未計上費用を含めて再評価します。4.5分なら、同じ条件のまま費用面から進める理由はありません。FAQ改善や有人対応の改善も比較候補に戻します。

次の検証では、同じ問い合わせ集合を方式ごとに評価し、以下をそろえます。

正しい根拠・回答禁止条件・担当への引き継ぎ条件を、費用計測前に固定する。
試行ごとの実usage、確認・修正・送信までの時間、下書き後の全面有人対応を測る。
検索・埋め込み・契約・監査・移行・撤退など、今回未計上の費用を追加する。
対象率・工数・件数の悪化ケースでも比較基準に余裕があるか確認する。
保守担当、誤回答時の停止判断者、有人対応への切り戻し手順を決める。

費用表は、品質と運用条件を満たした候補を比較するためのものです。実際の問い合わせ品質、レビュー時間、業務効果を確認するまでは、本番導入の根拠として確定させません。

参考資料と検証範囲

Claude公式料金表：2026-10-13確認。通常の入出力単価と別料金区分の根拠。
OWASP LLM10:2025 Unbounded Consumption：2026-10-13確認。利用量・資源消費を制限する一般的なリスクと対策。

公式資料から確認した料金とリスク、架空条件の計算結果、運用の設計案を区別しています。LLM実行、品質比較、実送信、課金、並行する予算予約、実請求照合、本番負荷、継続運用は未検証です。

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表。AI × Web × 業務自動化の開発・検証に取り組んでいます。
技術選定・品質・運用の判断材料を、検証範囲と制約を示して発信しています。
AI導入や業務自動化の技術選定・設計整理については、対応できる範囲を確認のうえご相談を承ります。