ISV 向けパススルー課金ガイド

2026年10月14日より、独立系ソフトウェアベンダー（ISV）は、パススルー課金を実装するためのアプリの準備を開始することが出来ます。パススルー課金を実装すると、アプリが発行した API 呼び出しによる API 利用量を、ユーザー側に直接帰属させることが可能です。

パススルー課金は、ビジネスモデルとアプリのアーキテクチャの両方に影響します。このガイドは、パススルー課金が自社のアプリに適したモデルかどうかを評価し、採用する場合にはそれを有効にするための技術的な選択肢を理解するのに役立ちます。

このガイドは 2 つのパートで構成されています。

1. ビジネス上の検討事項 — 利用可能な選択肢と、パススルー課金が自社のビジネスやユーザーにとってどのような意味を持つかを理解します。
2. 技術的な実装 — 有効化の方法を選択し、パススルー課金の実装に必要なアプリと認証の変更点を理解します。

パート 1：ビジネス上の検討事項

ビジネスへの影響を理解する

API 利用料はユーザー側の負担になる
パススルー課金を利用するユーザーの場合、対象の API 利用量は開発者のアカウントではなく、ユーザー側の Autodesk Platform Services（APS）アカウントに帰属します。

これにより API 利用料を誰が支払うかは変わりますが、製品の所有権やユーザーとの関係は変わりません。

API 利用量が多いアプリでは、API 費用が開発者にとって増え続けるコストになるのではなく、その利用を発生させているユーザー側で利用量に応じて増減するようになります。

ユーザー側に APS の利用枠が必要になる
パススルー課金対応のアプリを利用するユーザーは、APS の利用枠を含む対象のオートデスク製品サブスクリプションを保有し、必要な連携設定を完了する必要があります。

これは、ISV が API 利用料を負担している現在のモデルにはない、ユーザー側の前提条件となります。

この点が、ユーザーのオンボーディング、製品パッケージ、価格設定、営業、サポートの各プロセスにどのように影響するかを検討してください。

ユーザー側に別途オートデスクの費用が発生する
パススルー課金を利用するユーザーは、ISV のアプリ/サービスに独自の料金が設定されているのであば、これまでどおり ISV に利用料を支払い、対象の APS API 利用料はオートデスク製品サブスクリプションを通じて処理されるようになります。

ISV は、次の点をユーザー側に説明出来るよう準備しておく必要があります。

ISV のアプリ/サービス利用料と、同アプリ/サービスが消費する API 利用枠は別々の費用であり、それぞれの提供元（ISV とオートデスク）から請求されます。サブスクリプションに含まれる API 利用枠を超えて利用するユーザーは、その超過分をまかなうために、アカウントで Flex / T Flex（前払い）/ Pay as You Go（後払い従量課金）を利用出来る状態にしておく必要があります。Flex は、オートデスク ストアまたは Flex の販売を認められたパートナーから購入することが出来ます。

Client ID のパススルー課金への移行は一方向
パススルー課金用に新しいアプリを作成する場合でも、既存のアプリを移行する場合でも、変更は慎重に計画してください。

既存の Client ID の場合、現在の課金方式からユーザーが支払うパススルー課金の状態への移行は、この一方向にしか移行出来ません。言い換えるなら、アプリがパススルー課金の状態に移行すると、以前の状態に戻すことは出来ません。

パススルー課金は自社に適しているか

今後の API 価格改定を考慮する
パススルー課金を移行するかどうかの判断は、有料モデル対象の APS API が増加するにつれ、特に重要になります。

アプリが、現在有料である API や、今後有料化される API を使用している場合、その API 費用を自社のコスト構造に組み込むか（ISV 提供のアプリ利用料に組み込むか）、ユーザー側に負担してもらうかを検討してください。

将来を見越して、API が有料化される前にこの判断をしておけば、アプリやユーザーのオンボーディングに必要な変更をおこなう時間を確保することが出来ます。

現在、次の API が有料です。

• Model Derivative API
• Automation API
• Reality Capture API
• Flow Graph Engine API
• Manufacturing Data Model API
• AEC Data Model API

次の API は、今後有料化される予定です。（現時点で詳細は未定）

• Data Management API
• Forma API

オートデスクは今後も有料化する対象 API を追加していきますが、開発者の皆様やユーザー側が予算計画を立てられるよう、常に十分な期間を設けて事前に告知します。

課金オプションを検討する
パススルー課金の採用は任意です。現在の利用モデルを継続することも、ユーザー側をパススルー課金に移行することも、両方のモデルを並行して運用することも可能です。

ハイブリッドモデルの仕組み
ハイブリッドモデルでは、費用負担の方式が異なる 2 つのアプリ（Client ID）を使い分けます。

1. 既存のアプリ
   ユーザー → 既存の Client ID → APS → ISV の API 利用枠
2. パススルー課金対応のアプリ
   ユーザー → パススルー課金用の Client ID → APS → ユーザー側の APS 利用枠

この方法で両方のモデルを並行して提供することが可能です。既存のアプリの費用負担方式を変えずに、一部のユーザーをパススルー課金モデルに移行させることが出来ます。

注： 2 つのアプリを使うハイブリッド課金は、このガイドで後述する「移行期間（Transition）」の状態とは異なります。移行期間の状態では、ユーザーをパススルー課金にオンボーディングしている間、1 つの既存の Client ID の下で ISV 負担とユーザー負担の利用が共存させることが出来ます。移行期間の状態は一時的なもので、具体的なスケジュールは後日発表されます。

パート 2：技術的な実装

パススルー課金の採用を決めたら、アプリを有効にする方法は 2 つあります。

• パススルー課金に対応した新しい Client ID を作成する
• 対象の既存 Client ID をパススルー課金に移行する

どちらも最終的には同じユーザー負担のパススルー課金モデルに対応しますが、移行の手順が異なります。

1. 有効化の方法を選ぶ

オプション A：パススルー課金に対応した新しい Client ID を作成する

APS 開発者ポータル（aps.autodesk.com）で新しいアプリを作成し、アプリの設定画面で「Start Transition」をクリックします。

これにより、ユーザーのオンボーディング前に構成とテストが出来る、独立したパススルー課金用アプリが用意されます。

この方法は、既存の ISV 負担のアプリを、別のパススルー課金用アプリと並行して運用し続けたい場合にも便利です。

アプリは次のように運用されます。
既存の Client ID → ISV 側負担
新しいパススルー課金用 Client ID → ユーザー側負担

そのうえで、ユーザーを適切なアプリにオンボーディングします。

オプション B：既存の Client ID を移行する

既存のアプリが対象のタイプ（シングルページ、Web、モバイル、デスクトップ – “Traditional Web App” か “Desktop, Mobile, Single-Page App”）で、3LO（3-legged 認証フロー） の呼び出しを 1 つ以上おこなっている場合は、2つ目のアプリを作成せずに、既存の Client ID でパススルー課金を有効にすることが出来ます。

これにより、ユーザー側に別の Client ID を使用するアプリへの切り替えを求める必要がなくなり、既存のユーザーとパススルー課金のユーザーが同じアプリを使い続けられる移行期間が設けられます。

既存の Client ID でパススルー課金を有効にすると、その Client ID は移行期間（Transition）の状態になります。

2. 移行期間（Transition）の状態を理解する

移行期間の状態は、すべてのユーザーに同時に変更を求めることなく、ユーザー毎にパススルー課金に移行出来るように設計されています。

重要： 費用負担の状態の移行は元に戻せません。既存の Client ID がいったん移行期間に入ると、ISV 側負担の状態に戻すことは出来ません。ユーザー側負担のみの状態に進むと、移行期間に出来ません。

移行期間中は、1 つの Client ID で両方の費用負担モデルに対応出来ます。

つまり、特定の Client ID で最初にパススルー課金を有効にした時点では、既存のユーザーがアクセスを失うことはありません。

ユーザー側で来年初めに提供予定の連携手順を完了すると、同ユーザーの有料 API 利用の課金が ISV 側の負担からユーザー側の負担に切り替わります。まだ連携を完了していないユーザーは、API 利用料を ISV 側で負担する形でアプリを引き続き利用出来ます。

これにより、アプリやユーザー層に合ったペースでユーザーをオンボーディングすることが出来ます。

仕組みを把握出来たら、アプリを明示的にユーザー側負担のみの状態に進めます。

その時点で次のようになります。

• ISV は、その Client ID での API 利用料を負担しなくなります。
• 連携を完了したユーザー様は、引き続きアクセス出来ます。
• 連携を完了していないユーザーは、アクセス出来なくなります。

状態の進み方は次のとおりです。

ISV 側負担 → 移行期間 → ユーザー側負担のみ

それぞれの移行は、ISV が明示的に操作しておこないます。

3. サポートされている認証モデルを使用する

パススルー課金では、アプリが 3-legged OAuth（3LO）を使った API 呼び出しを 1 つ以上おこなう必要があります。純粋な 2LO のアプリや “Server-to-Server App” タイプのアプリは、パススルー課金に対応していません。これは、新しいパススルー課金用アプリを作成する場合も、既存の Client ID を移行する場合も同様です。

3LO が必要な理由

パススルー課金では、どのユーザーの APS サブスクリプションが API 利用料を負担すべきかを判断する必要があります。

3LO による認証・認可では、オートデスク側でサインインしたユーザーの ID を識別出来ます。オートデスクは同ユーザー ID を使って、ユーザーが利用出来る利用コンテキストを特定、認可の際にユーザーが適切なコンテキストを選択出来るようにします。

純粋な 2LO のフローでは、アプリのコンテキストは提供されるものの、ユーザーのコンテキストは提供されません。ユーザーのコンテキストがなければ、オートデスクはどのユーザーの利用枠で利用料を負担させるべきかを判断出来ません。

既存の 2LO またはサーバー間通信のアプリ

“Server-to-Server App” タイプ アプリの Client ID は、パススルー課金に移行出来ません。

現在、アプリが 2LO または SSA（Secure Service Account）だけで動作している場合、パススルー課金を採用するには、認証アーキテクチャの変更と、3LO に対応したアプリの種類が必要です。Autodesk Platform Services は、今後、すべての API エンドポイントを段階的に 3LO に移行していく予定です。このため、お使いのアプリでも 3LO の採用を始めることをお勧めします。

4. パススルー課金用アプリを構成する

APS 開発者ポータル（aps.autodesk.com）で、アプリに次の必要事項を構成します。

• Callback URL
• OAuth スコープ
• APS API へのアクセス
• アプリのコラボレーター
• アプリが使用する APS API

パススルー課金でサポートされるクライアントの種類は次のとおりです。

• Web
• シングルページアプリ
• モバイル

サーバー間通信のアプリ（”Server-to-Server App” タイプ アプリ）はサポートされません。

既存のアプリを移行する場合、既存の構成は同じ Client ID に関連付けられたまま維持されます。大きく変わるのはパススルー課金や費用負担の状態であり、アプリケーションの識別情報（ID）が別のものに変わるわけではありません。

5. 3LO の認可フローを更新する

3LO の認可フローに対するパススルー課金固有の変更は、次のパラメーターの追加です。

prompt=select_usage_context

例：

python

import secrets
from urllib.parse import urlencode
CLIENT_ID = "your_client_id"
REDIRECT_URI = "https://yourapp.example.com/callback"
AUTH_BASE = "https://developer.api.autodesk.com/authentication/v2/authorize"
def build_authorize_url() -> str:
    params = {
        "response_type": "code",
        "client_id": CLIENT_ID,
        "redirect_uri": REDIRECT_URI,
        "scope": "data:read data:write",
        "state": secrets.token_urlsafe(16),
        # パススルー課金のために利用コンテキストの選択を要求する
        "prompt": "select_usage_context",
    }
    return f"{AUTH_BASE}?{urlencode(params)}"

このパラメーターが指定され、アプリがパススルー課金の対象である場合、オートデスクは認可フローに利用コンテキストを選択するステップを追加します。

ユーザーの操作の流れは次のようになります。

認証 → 利用コンテキストの選択 → 同意 → アプリに戻る

選択された利用コンテキスト（サインインしたユーザー アカウント）によって、その認可に関連付けられるユーザー コンテキストが決まります。

6. 認可コードを通常どおり交換する

認可が成功したら、標準の APS OAuth トークン交換を使って認可コードを交換します。

トークン交換の際に、パススルー課金用の追加パラメーターは必要ありません。

python

import requests
TOKEN_URL = "https://developer.api.autodesk.com/authentication/v2/token"
def exchange_code(code: str) -> dict:
    resp = requests.post(
        TOKEN_URL,
        data={
            "grant_type": "authorization_code",
            "code": code,
            "redirect_uri": REDIRECT_URI,
            "client_id": CLIENT_ID,
            "client_secret": "your_client_secret",
            # 該当するパブリッククライアントでは代わりに PKCE を使用する
        },
    )
    resp.raise_for_status()
    return resp.json()

選択された利用コンテキストは、その結果得られる認可グラントとアクセストークンに関連付けられます。アプリ側で利用コンテキストを確認したり、以降の APS API リクエストで明示的に送信したりする必要はありません。トークンの更新後も、選択された利用コンテキストは認可グラントに紐付いたままです。アプリがアクセストークンを更新しても同じコンテキストが維持されるため、通常のトークン更新でユーザーに利用コンテキストを再度選択してもらう必要はありません。

7. APS API を通常どおり呼び出す

アクセストークンを取得したら、通常の 3LO アクセストークンと同じように APS API を呼び出します。

python

tokens = exchange_code(code)
response = requests.get(
    "https://developer.api.autodesk.com/some/aps/endpoint",
    headers={
        "Authorization": f"Bearer {tokens['access_token']}"
    },
)

パススルー課金用に追加で指定するヘッダーや API パラメーターはありません。対象の利用については、オートデスクがアクセストークンに関連付けられた利用コンテキストを使って、適切なユーザー コンテキストと費用の負担元を判断します。

8. 利用コンテキストの選択に失敗した場合に対処する

利用コンテキストの選択はフェイルクローズ（失敗時は拒否）で動作します。オートデスクが有効な利用コンテキストを確立出来ない場合、認可フローは認可コードを発行せず、エラー付きでアプリの Callback URL にリダイレクトします。コールバックでは、認可の成功とエラーの両方を処理出来るようにしてください。

python

from urllib.parse import parse_qs, urlparse
def handle_callback(callback_url: str):
    q = parse_qs(urlparse(callback_url).query)
    if "error" in q:
        raise RuntimeError(
            f"Authorization failed: {q['error'][0]}"
        )
    return q["code"][0]

利用コンテキストの選択は、次のような場合に失敗する可能性があります。

• ユーザーが利用出来る有効な利用コンテキストがない
• ユーザーが選択または認可の処理をキャンセルした
• アプリがパススルー課金の対象ではない
• その他の理由で利用コンテキストを特定出来ない

アプリでは、これらのケースを認可の失敗として扱い、ユーザーに適切な次の手順を案内してください。

9. 移行を完了する

移行の進め方は、選択した有効化の方法によって異なります。

新しいパススルー課金用 Client ID を作成した場合

既存のアプリから新しいパススルー課金用アプリへ、ユーザーをオンボーディングします。

ハイブリッドモデルを採用している場合は、両方のアプリを引き続き運用出来ます。

既存のアプリ → ISV 側負担のユーザー
パススルー課金用アプリ → ユーザー側負担のユーザー

既存の Client ID を移行した場合

ユーザー側でパススルー課金の連携手順を完了するまで、アプリを移行期間の状態に保ちます。

この期間中は次のようになります。
連携済みのユーザー → ユーザー側負担
未連携のユーザー → ISV 側負担

どちらのユーザーも、同じ Client ID を使い続けます。

移行していないユーザーの利用料の負担をやめる準備が出来たら、Client ID を明示的にユーザー側負担のみの状態に進めます。

この操作は、期限や事前に決められた移行期間によって自動的に実施されるものではありません。切り替えを完了出来る状態になったか否かの判断は、開発者（ISV）が判断します。

アプリがユーザー負担のみの状態に移行すると、連携手順を完了していないユーザーはアプリへのアクセスが出来なくなることに注意してください。

本番運用を開始する前に

パススルー課金を有効にする前に、次の点を確認してください。

1. 課金モデルと、Client ID の方針（新規作成か、対象の既存 ID の移行か）を決定している。
2. アプリが、サポートされているアプリの種類や 3LO の使用など、パススルー課金の要件を満たしている。
3. ユーザー側が APS サブスクリプションの要件を満たせる。
4. Callback URL、スコープ、API へのアクセス、コラボレーター、使用 API の宣言など、クライアントと API の構成が完了している。
5. prompt=select_usage_context の指定、選択失敗時の処理、コードの交換、トークンの更新、API 呼び出しなど、認可フローの準備が出来ている。
6. パススルー課金の状態変更は元に戻せないことを理解している。
7. 既存の Client ID を移行する場合、移行期間からユーザー負担のみへ移行する計画があり、ユーザーが必要な対応を理解している。

これらの要件を満たしたら、ユーザーのパススルー課金へのオンボーディングを開始する準備は完了です。

※ 本記事は Passthrough billing: A guide for ISVs | Autodesk Platform Services から転写・意訳・補足したものです。