7 ポイント 投稿者 xguru 2024-08-24 | 1件のコメント | WhatsAppで共有
  • Anthropic が JSON API の CORS サポートを有効化
    • つまり、ユーザーのブラウザーから直接 Claude LLM を呼び出せるようになった
  • この機能は "anthropic-sdk-typescript: add support for browser usage" PR にひっそり含まれている
    • 掘ってみると、このコードに対する Anthropic TypeScript SDK の変更は、新しい JSON API 機能を示している
  • 次の HTTP リクエストヘッダーを追加することで、Anthropic API の CORS サポートを有効にできる:
    anthropic-dangerous-direct-browser-access: true
  • このヘッダーを追加すると、ブラウザーから直接 Anthropic モデルを呼び出せる
  • API キーをクライアントコードに含めると、そのサイトにアクセスできるユーザーが API キーを盗んで勝手にリクエストできてしまうため、Anthropic はこの機能の追加に慎重だった
  • それでも、この機能にはいくつか妥当なユースケースがある
    • 信頼できるユーザーに公開する社内ツールには向いている
    • あるいは、ユーザーがクライアントサイドアプリで使う自分のキーを提供する "BYOK(Bring Your Own Key)" パターンも実装できる

Haiku - クライアントサイドアプリの例

  • 試しに作られた Haiku ページは、CORS サポートが必要なクライアントサイドアプリの例
  • ウェブカメラへのアクセスを要求し、Anthropic API キーの入力を求めて(ブラウザーの localStorage に保存)、写真を撮り、Haiku モデルを使って俳句に変えるシンプルなアプリ
  • これまでは Vercel 上で独自プロキシを動かして Anthropic API に CORS サポートを追加する必要があった
  • 現在は新しいヘッダーを送るようにアプリをアップグレードし、プロキシなしで Anthropic と直接通信できる
fetch("https://api.anthropic.com/v1/messages";, {  
  method: "POST",  
  headers: {  
    "x-api-key": apiKey,  
    "anthropic-version": "2023-06-01",   
    "content-type": "application/json",  
    "anthropic-dangerous-direct-browser-access": "true",  
  },  
  body: JSON.stringify({  
    model: "claude-3-haiku-20240307",  
    max_tokens: 1024,  
    messages: [  
      {  
        role: "user",  
        content: [  
          { type: "text", text: "Return a haiku about how great pelicans are" },  
        ],  
      },  
    ],  
  }),  
})  
  .then((response) => response.json())  
  .then((data) => {  
    const haiku = data.content[0].text;  
    alert(haiku);  
  });  

1件のコメント

 
xguru 2024-08-24

Hacker Newsの意見

  • 個人的には、ユーザーが自分のキーを持ち込むWebアプリを作るのが好き

    • このアプローチは、実行ファイル配布の手軽さとオープンソースの利点を組み合わせられる
    • これまでに2つのWebアプリを開発した
      • マイク入力を使うリアルタイム文字起こし・翻訳アプリ
      • SRT字幕をさまざまな言語に翻訳するアプリ
    • 「ユーザーがキーを持ち込む」モデルを選ぶ主な理由は2つ
      • 低メンテナンス: すでに多くのソフトウェアを保守しているので、サイドプロジェクトまで保守したくない
      • 低コスト: 広告なしでアプリを公開でき、運用コストも低く抑えられる
    • 保守負担とユーザーコストを最小限にしながら、有用なツールを作って共有できる
  • ユーザーが自分のキーを持ち込むケースでは問題にならない

    • 処理はクライアント側で行われ、デバイスやWebサイトが侵害されない限り大丈夫
    • ただし、開発者が本番用キーをクライアント側で使う場合は、攻撃面が広がる可能性がある
    • 利便性や性能を理由に、セキュリティ面の考慮なしでこれをやってしまうかもしれない
  • JWTをサポートしない理由が理解できない

    • Supabaseは、安全なクライアント側アクセスを提供する良い例
  • Anthropicを含むすべてのAIベンダーは「Login with ___」機能を実装すべき

    • ユーザーが自分のAIリソースを信頼して使えるようにするべき
    • ほとんどのユーザーはAPIキーの生成や読み込みを面倒に感じ、安全に管理することもできない
  • ユーザーが自分のキーを持ち込むなら、OAuthのほうがより良い解決策

    • 開発者によっては実際のキーをフロントエンドにハードコードして苦労することになりかねない
    • OAuthのほうがより安全な解決策
  • 内部開発には向いているかもしれないが、ユーザー向けアプリには向いていない