どういうものか

ある程度汎用的に作ってるので、利用はOpenAIのAPIに限らない。

踏み台サーバーにアクセストークンの登録しておけば、APIの向き先を踏み台サーバーにしておけば利用する側はAPIキーを知らなくてもAPIが利用できるようになる、というもの。

ただの踏み台で全く抽象化しないので、OpenAIの公式ライブラリはそのまま透過的に利用できる。

kurehajime

使い方

起動

踏み台サーバーはこんな感じで起動する。

-Hオプションで付与したいヘッダーを指定する。これは何個でも良い。
そして最後にAPIのURLを指定。

 $ ./fumidai \
  -H "Authorization: Bearer $OPEN_API_KEY" \
  https://api.openai.com

利用

pythonでOpenAIの公式ライブラリを使ってる場合は、openai.api_baseで接続先を変えるだけで良い。

import openai
openai.api_base = "http://localhost:8080/v1"
completion = openai.ChatCompletion.create(
    model="gpt-3.5-turbo",
    messages=[
        {"role": "user", "content": "Think of three names for cats that seem smart."}
    ]
)

for cho in completion.choices:
    print(cho.message.content)

openai.api_base = "http://localhost:8080/v1"
と指定していれば、
http://localhost:8080/v1/chat/completions
にアクセスした際に、fumidai経由で
https://api.openai.com/v1/chat/completions
にアクセスできる。

localhostだとあまり意味はないが、閉じたネットワーク上に踏み台を1つ立てればアクセスキーを一箇所で管理できる。

kurehajime

課題と問題点

認証の仕組みがない

いまの仕組みだと誰でもアクセストークンを利用できるようになるので、外部には公開できない。
あくまで内部ネットワーク上でアプリケーションサーバーから叩かれる用途に限られる。
これがもう少しセキュアになれば、フロントエンドから直接叩かれるエンドポイントになれる。

とはいえ認証の仕組みと「OpenAIのライブラリがそのまま利用できる」という要件とを両立するのは難しいかもなぁ。

踏み台サーバーがオレオレAPIキーを発行して、それをopenai.api_key = secretで渡すようにすれば、OpenAIのエコシステムを維持したまま利用できるかもしれない。なんか本末転倒な気がしないでもないけど。

CORSに対応してない

上の理由により「フロントエンドから叩けるようになって便利だよ！」と胸を張って言えるような状態ではないため、あえて対応してない。

鍵の使い分けができない

Open AIのAPIは1契約あたりの最大利用量が決まってるので、アクセストークンをまとめればまとめるほどこれに引っかかるリスクがある。

kurehajime

うーん、「薄すぎてメリットがあまりない」と「でも下手に抽象化はしたくない」のジレンマがもどかしい。