Claude App Attestの仕組み — iOS/macOSアプリの真正性証明
Claude App AttestはAPIキーを配布せずにiOS/macOSアプリからClaude APIを呼び出す仕組みです。Appleの端末証明でアプリの正当性を確認し、1時間だけ有効なトークンを発行します。
Claude App Attestとは何か — APIキーを配らずにアプリを認証する仕組み
Claude App Attestは、iOS/macOSアプリが端末上から直接Claude APIを呼び出すための認証方式です。AppleのApp Attestサービスを使ってアプリの改ざんがない正規ビルドであることを証明し、Anthropicがその端末に短命のアクセストークンを発行します。利用料はデベロッパーのワークスペースに課金されます。
一番の違いは「アプリに秘密を持たせない」点です。sk-ant-...形式のAPIキーをアプリにバンドルすれば、リバースエンジニアリングで抜き出され不正利用される恐れがあります。App Attestはキーそのものを配布せず、プロキシサーバーを運用する必要もありません。利用できるのはApp AttestからClaude APIを直接呼び出す場合のみで、Amazon Bedrock・Google Cloud・Microsoft Foundry経由の利用では使えません。
App Attestが解決する課題 — プロキシ運用からの解放
App Attest登場以前、モバイルアプリからClaude APIを呼ぶ選択肢は実質2つでした。1つはAPIキーをアプリにバンドルする方法、もう1つは自前のバックエンドプロキシを経由させる方法です。
| 構成 | メリット | デメリット |
|---|---|---|
| APIキーをアプリに埋め込む | メリット実装がシンプル | デメリットリバースエンジニアリングでキーが抜かれるリスク |
| 自前プロキシ経由 | メリットキーを端末に持たせない | デメリットプロキシサーバーの構築・運用・スケーリングが必要 |
| App Attest | メリットキー不要・プロキシ不要 | デメリットClaude API直接呼び出し限定、物理デバイス必須 |
App Attestはこの二択を崩し、秘密を配布物に含めず、かつプロキシも不要にする第3の選択肢です。バックエンドを持たない小規模チームや、サーバーレスでアプリを配布したいケースに向きます。
App Attestは内部でどう動くか — チャレンジからトークン発行まで
アプリが端末で初めてClaudeを呼び出すとき、内部では次の順で処理が進みます。
- アプリがAnthropicへチャレンジを要求する
- 端末のSecure Enclaveが
DCAppAttestServiceを使ってその端末を証明する - 証明結果をAnthropicへ送り、検証済みの短命アクセストークンと交換する
この一連の流れはClaude for Foundation Modelsパッケージが自動で実行し、トークンの有効期限が近づけば裏側で再取得します。開発者側でチャレンジ応答のコードを書く必要はありません。
発行されるトークンには3つの制約があります。ワークスペースにスコープが固定され、発行から1時間で失効し、Messages APIの呼び出ししか認可しません。もう一つ重要なのは、トークンがエンドユーザーの身元を一切運ばない点です。App Attestが証明するのは「このアプリの正規インストールである」ことだけで、「誰が使っているか」は含まれません。フリーミアムの利用回数制限や課金上限、パーソナライズをやりたい場合、その判定ロジックはトークンに混ぜ込めず、アプリ側でユーザー識別の仕組みを別途持つ必要があります。
他の認証方式と何が違うか
Claude APIの認証方式は現在3つあり、公式ドキュメントの比較表では想定用途がそれぞれ明確に分かれています。
| 認証方式 | クレデンシャル | 想定用途 |
|---|---|---|
| APIキー | クレデンシャルsk-ant-api...形式の静的シークレット | 想定用途ローカル開発・プロトタイピング・スクリプトなど、シークレット管理を自分で担保できる環境 |
| Workload Identity Federation | クレデンシャルIdPのIDトークンから交換する短命トークン | 想定用途AWS・Google Cloud・Azure上の本番ワークロード、CI/CD、Kubernetesなど静的シークレットを排除したい構成 |
| App Attest | クレデンシャル検証済みインストールに発行される短命トークン | 想定用途エンドユーザーに配布するiOS/macOSアプリで、バックエンドもプロキシも持たずに直接Claude APIを呼ぶ場合 |
APIキーとWorkload Identity Federationは同じAPIアクセス権限を持ち、どちらを選ぶかは「シークレット管理を誰がどこで担うか」の違いにすぎません。対してApp Attestは対象そのものが「エンドユーザーへ配布するアプリ」に限定される点で、他の2方式と性質が異なります。サーバー側のワークロードを持つチームがWorkload Identity Federationを使い、同じチームがモバイルアプリも配布するなら、サーバー側はWIF・モバイル側はApp Attestという組み合わせが公式の想定に沿う形です。逆に、社内ツールのように配布先が限られていてシークレット管理を自チームだけで完結できる場合は、App Attestをあえて導入せずAPIキーのままにしておく方がシンプルという判断も十分に成立します。
導入に必要な条件と設定手順
App Attestには物理デバイスが必須です。Simulatorや、Secure Enclaveを持たない機種では証明そのものが実行できません。開発中はSimulatorでAPIキー認証に切り替える運用になります。この切り替えはApp Attestが未対応というだけでなく、開発サイクルの速度を保つ狙いもあります。実機でのApp Attestフローはビルド・署名・端末への配布を毎回挟むため、Simulatorでのイテレーションに比べて確認のたびの手数が増えます。
設定には次の2つの権限が要ります。
- Apple Developer Team ID
- 組織のadmin、owner、またはprimary ownerロール
手順は4ステップです。
- Xcodeプロジェクトの「Signing & Capabilities」でApp Attestケーパビリティを追加する
- Claude Consoleのワークスペース設定で「App integrations」を開く
- 「Create app integration」から名前・Apple Developer Team ID・バンドルID(最大32個)を登録する
- integrationの「Overview」タブでクライアントID(
clid_...)を取得し、アプリの設定に渡す
バンドルIDを最大32個まで登録できるのは、無料版・有料版・社内配布版のような同一アプリの複数バリアントを1つのintegrationでまとめて管理できるようにするためです。
侵害・退役したアプリはどう止めるか
登録したアプリが侵害された、あるいはサポートを終了したときは、integrationごと失効させます。ワークスペース設定の「App integrations」から対象を選び「Revoke」を押して確定する、という手順です。誤操作での取り消しはサービス停止に直結するため、Revokeボタンへのアクセス権限は組織内で絞っておく価値があります。
失効させると、そのintegrationが発行済みの全トークンが無効になり、登録済みの端末も新しいトークンを要求できなくなります。この操作は元に戻せません。同じアプリを復旧させたい場合は、新しいintegrationを作り直す必要があります。緊急停止の手段としては強力ですが、ロールバック不可という前提で運用に組み込む必要があります。
App Attestで作れないもの — 対応面の限界
App Attestを検討するときは、対応していない面も押さえておく必要があります。まず対象OSがiOSとmacOSに限られ、Android・Windows・Linux向けアプリでは使えません。クロスプラットフォームで配布するアプリは、いずれにせよAndroid側にはAPIキーかWIFの仕組みを別途用意することになります。
次にクラウド経由のアクセスが対象外です。Amazon Bedrock・Google Cloud・Microsoft Foundry経由でClaudeを呼ぶ構成では、App Attestではなくそれぞれのプラットフォームが提供する認証を使います。すでにBedrock等でClaudeを組み込んでいる既存アプリをApp Attestへ切り替えるには、呼び出し経路自体をClaude API直叩きに変える設計変更が要ります。サーバー側のワークロードでこうしたクラウド発行のIDをすでに使っているなら、モバイル以外の面ではWorkload Identity Federationが受け皿になります。
最後に、Webアプリやサーバーサイドの処理には使えません。App Attestが証明するのは「Apple製の物理デバイス上で動く、登録済みビルドである」ことなので、そもそも端末という概念がないサーバー処理には適用しようがありません。サーバー側の認証を静的シークレットなしで運用したい場合は、App AttestではなくWorkload Identity Federationの対象領域になります。両者を混同すると設計段階で手戻りが生じるため、対象がエンドユーザーの端末かサーバーかをまず切り分けておく必要があります。
まとめ
Claude App Attestは、iOS/macOSアプリからClaude APIを直接呼ぶときにAPIキーの配布を不要にする認証方式です。Appleの端末証明を経由して1時間有効のトークンを発行し、ユーザー識別は運びません。対応OSはiOSとmacOSに限られ、物理デバイス必須・失効は不可逆・クラウド経由では利用不可という制約もあります。配布経路をClaude APIへの直接呼び出しに固定できるかどうかが導入可否の分かれ目であり、それを満たせるモバイル配布アプリなら認証設計の有力な選択肢になります。ほかの認証方式との比較はClaude APIの認証方式まとめで扱っています。