OpenAI APIのコストを削減する方法:コンプライアンスを守りながら
要約
- OpenAIの費用を下げる定番の手順(まとめ処理、指示の削り込み、モデルの振り分け)は効くが、頭打ちになる。確率的な呼び出しを一つずつ最適化するだけで、その呼び出しが要るのかを問わない。
- 何かを最適化する前に、支出を計測すること。OpenAIの費用の1ドルごとを、特定の業務、チーム、用途に割り当てて初めて、以下の手が正しい的に当たる。
- 6つの定番の手にはそれぞれ、規制下で固有の法令対応のリスクがある。気づかれない指示の雛形のずれから、データの所在の境目をぼかすまとめ処理まで。
- 構造の答えは構成にある。8対2の分け方(8割を決定論的なルールに基づく実行、2割をモデルの呼び出し)が、呼び出しを値引きするのではなくなくすことで、15〜60倍の費用の優位を生む。Jinba Flowはこの構成を軸に作られている。
正直な答えを言う。OpenAIの費用を下げる定番の手順(まとめ処理、指示の削り込み、モデルの振り分け)は効くが、頭打ちになる。規制下の企業が確率的な呼び出しごとに払う額は減る。だが根っこの問題は消えない。その呼び出しはどれも、決まった監査の跡を持たない決定論的でない判断のままであり、しかも検査官に答えねばならない環境の中で動いているのだ。
本番の規模でOpenAIを使う銀行、保険会社、医療の事業者にとって、本当の答えは構造にある。そもそも生きたモデルの呼び出しが要る作業の量を減らし、残ったものを統べて、支出が割り当てられ、承認され、見直せるようにすることだ。本稿は、いま効く戦術の手と、頭打ちそのものをなくす構成の転換の両方を扱う。
ありふれたOpenAIの費用対策が規制下で力尽きる理由
「OpenAIのAPIの費用を下げる」と検索すれば、どの結果も同じ6つの手に集まる。本稿は、より広く扱った規制下の企業のための大規模言語モデルの費用最適化と並ぶもので、そちらは戦略を深く扱っている。指示を一時保存する、安いモデルへ振り分ける、まとめ処理のAPIを使う、出力のトークンを削る、文脈を縮める、適した処理の層を選ぶ。どれも間違いではない。だが、規制下の企業が実際に抱えている問題には、どれも答えていない。
OpenAIはトークンで課金する(入力と出力を、要求ごとに計り、料金はモデルによって変わる)。企業の財務のチームが統べ慣れているサービスの利用契約とは、根本的に違う費用の形だ。席の利用料は固定の項目である。トークンの請求は、誰も中央で握っていない使い方とともに動く変動の項目だ。新しい指示の雛形、繰り返すエージェント、支援のチーム。
規制下の企業がこれを強く感じるのは、請求を膨らませるのと同じ読めなさが、監査も難しくするからだ。費用も出力も揺らぐ仕組みは、費用も出力も固定のものより、割り当てにくく、再現しにくく、検査官に説明しにくい。ある情報セキュリティの実務者はそっけなくこう述べた。「黒箱の自動化で本気の監査を通せている者は、まだ誰もいない」別の人はこうも言う。「説明できないという穴が、実務ではこうした導入の多くを殺している」
定番の手はどれも、呼び出しの値段を下げる。だが呼び出しそのものの性質は変えない。確率的で、再現できず、求められたときに説明しにくい、という性質だ。
削る前に測る:まずOpenAIの支出を計測する
計測なき最適化は当て推量であり、当て推量は、最高財務責任者や検査官があとで尋ねる費用の物語の土台としては貧しい。指示やモデルに手を付ける前に、規制下の企業は、どの業務、どのチーム、どの用途がOpenAIの支出の1ドルを生んでいるのかを見えるようにする必要がある。
これを覆う道具は3つあり、細かさの度合いが上がっていく。
OpenAIの利用の画面は、モデルごと日ごとの支出を見る、アカウントの水準の標準の眺めだ。最も速い出発点で、つなぎこみの作業は要らない。火災報知器のようなものだと思えばいい。火事があることは教えるが、どの部屋から始まったかは教えない。
独自のトークンの記録の中間層は、要求ごとにトークンの数、モデル、呼び出しの文脈(どの窓口、どの利用者、どの業務)を記録するよう、応用のコードに手を入れることだ。費用を事業の単位に割り当てるための最低線であり、その項目を誰が持つのかと財務が尋ねた瞬間に効いてくる。役に立つ記録の型は、呼び出しごとにfeature、customer_id、environment、model、prompt_tokens、completion_tokens、そしてcost_usdを残す。
専用の大規模言語モデルの観測の基盤は、たとえばHeliconeやLangSmithといった道具で、APIの手前や横に立ち、呼び出しごとの指示、応答、待ち時間、費用を捉え、応用や環境ごとに使い方を分解する。独自のデータの流れを作らずに、本番の規模で見える化の問題を解いてくれる。
この3つはどれも、それ自体では費用を下げない。まずひとつの問いに答えるために存在する。どの指示、どの窓口、どのチームがトークンを燃やしているのか。それが分かって初めて、以下の手が仕組み全体にやみくもにではなく、正しい的に当たる。
OpenAI自身の資料が教える6つの定番の手
OpenAIの資料と利用者の知見は、請求を下げる6つの仕掛けに集まる。どれも本物で、どれも使う価値があり、そしてどれも、定番の助言が触れない固有の法令対応のリスクを規制下では伴う。
指示の一時保存
手:指示のうち一時保存された部分(指示文、少数の例、繰り返す文脈)を使い回し、OpenAIが直近の要求ですでに処理したトークンの料金を安くしてもらう。
法令対応のリスク:一時保存された指示の断片も、検証され承認された版と一致していなければならない。気づかれずに指示の雛形が書き換えられ、見直されていない古い版とともに保存されると、誰も承認していない論理の上で業務が動き続けかねない。
統制の直し方:一時保存される指示の雛形そのものを版管理し、保存の無効化を、他の本番の論理の変更と同じ承認の手続きに結びつけること。
モデルの振り分け
手:単純で量の多い作業(分類、抽出、短い要約)は小さく安いモデルへ送り、最先端のモデルは、本当にその推論の深さが要る作業のために取っておく。
法令対応のリスク:非公式な当て推量でモデルを選ぶ振り分けの論理は、それ自体が記録されていない判断だ。小さいモデルがKYCの項目の抽出を担って誤ったなら、そこへ送った振り分けの規則も、モデルの呼び出しと同じくらい監査できねばならない。
統制の直し方:振り分けの判断をモデルの呼び出しと一緒に記録すること。どの規則がこの要求をどのモデルへ送ったのか、そしてその規則が最後に変わったのはいつか。
まとめ処理のAPI
手:時間に追われない作業(夜間の書類の処理、まとめての分類のやり直し)には、OpenAIのまとめ処理のAPIが要求を非同期で処理し、標準の同期の料金より50%安くなる。
法令対応のリスク:複数の事業の単位やデータの所在の区域から書類を寄せ集めるまとめ処理は、同期の呼び出しなら保たれていた割り当てと管轄の境目をぼかしうる。
統制の直し方:提出したあとではなく前に、データの分類と事業の単位でまとめ処理を分けること。割引が、データの扱いの例外と引き換えにならないように。
出力トークンの抑え
手:上限を設けるのはmax_tokensのほうで、あわせて簡潔な出力を明示して求める。多くのモデルで、出力のトークンは入力よりはっきり高い料率で課金されるからだ。
法令対応のリスク:きつすぎる上限は、法令に関わる答えを気づかれずに切り落としうる。リスクの評価や契約の条項が文の途中で切れているほうが、高くつくより悪い。
統制の直し方:ひとつの全体の既定ではなく、完全な答えの形が分かっている用途ごとに上限を決め、切り落としが起きたら知らせること。
文脈の縮小
手:書類の全体ではなく、作業に関係する節だけを送り、作業の質を落とさずに入力のトークンを減らす。
法令対応のリスク:きつすぎる文脈の削り込みは、その書類を法令上の例外にしていたまさにその条項や但し書きを取り除き、高くても正しい答えの代わりに、自信満々に間違った答えを生みかねない。
統制の直し方:削り込みの論理を、印のついた例外の書類の集まりに対して本番に入れる前に検証し、削り込みの規則が変わるたびに検証し直すこと。
FlexとPriorityの処理の層
手:OpenAIのFlexの層は、遅れを許せる作業について待ち時間と引き換えに安い料率を出す。Priorityの層は、待ち時間に敏感な作業について逆をやる。
法令対応のリスク:要求ごとにその場で層を選ぶと、標準化されているべき処理の折り返しの時間がばらつく。ある融資の書類がある日はFlexで、翌日はPriorityで処理されるのは、処理の統制の穴だ。
統制の直し方:個々の要求ではなく業務の種類ごとに層を割り当て、その割り当てを処理の定義の一部として記録すること。
この6つの手はどれも、呼び出しの値段を下げる。どれも呼び出しをなくさない。規制下の企業は、実行のたびに確率のモデルで確率的な判断を下し続けている。そして確率的な判断はどれも、検査官が再現して見せろと求めうるものであり、二度目に同じ答えが返るとはかぎらない。
定番の手 | 何を最適化するか | 何が変わらないか |
|---|---|---|
指示の一時保存 | 入力のトークンの費用 | 呼び出しは起きる。出力はやはり決定論的でない |
モデルの振り分け | 呼び出しあたりの費用(安いモデル) | 振り分けた作業も、やはり確率的なモデルの呼び出し |
まとめ処理のAPI | 非同期の作業が50%引き | 同じ確率的な出力が、安く遅くなるだけ |
出力トークンの抑え | 出力のトークンの支出 | 切り落としの危険。呼び出しはやはり再現できない |
文脈の縮小 | 入力のトークンの量 | 法令に要る文脈を落とす危険 |
FlexとPriorityの層 | 待ち時間と費用の釣り合い | 呼び出しの監査可能性と決定論性は変わらない |
OpenAIが教えてくれない手:最適化ではなく、呼び出しをなくす
その頭打ちこそが、ここでの本当の発見だ。この問題でいま上位に出るどの結果も、まっすぐには扱っていない。定番の助言はAPIの呼び出しを最適化する。そもそもその作業に生きたモデルの呼び出しが要ったのかは問わない。この違いについては別に指示の最適化と決定論的な業務で書いたので、両方を比べているチームは参照してほしい。そもそもその作業に生きたモデルの呼び出しが要ったのかは問わないのだ。
別の道は、戦術ではなく構成にある。判断の道筋の大半を決定論的でルールに基づく論理が担い、言語のモデルは端でだけ、つまり本当に開かれた言葉の理解が要る狭い部分でだけ呼ばれるように業務を作ることだ。書類の分類、項目の検証、振り分けの論理、計算、体裁づくりに、確率のモデルは要らない。
この8対2の分け方(およそ8割を決定論的なルールに基づく実行、2割を本当に判断が要る地点でのモデルの呼び出し)が、トークンの支出の大半を値引きするのではなくなくす、構造の形だ。いまの支出と突き合わせて考える最高財務責任者は、2部構成の企業AI費用削減の枠組みを読むとよい。手を順に追っている。この経済は小さな話ではない。決定論を先に置く構成は、規模を出しても月5〜20ドルの水準で動く。対して月300ドル超。すべての段階でモデルを呼ぶ確率的なエージェントとして同じ作業を動かせばそうなる。これが15〜60倍の構造的な費用の優位である。
この差が生まれるのは、決定論の道が同じ呼び出しの安い版だからではない。呼び出しが存在しないからだ。
これがJinba Flowの背後にある構成だ。決定論を先に置く8対2の分け方が、あとから当てる最適化ではなく既定になっている業務の作成基盤である。チームはJinbaのビジュアルの編集画面やチャットからのフロー生成で、段階の大半がルールに基づきトークンを使わない業務を作る。大規模言語モデルの呼び出しは、統べられた処理の中の統制された段階としてだけ入り、完全な版管理を伴う。
.png)
決定論的な業務が、最高財務責任者と監査人の両方を満たす理由
この組み直しは規制下の企業で二重に報いる。6つの戦術の手が触れられない法令対応の問題を解くからだ。同じ原理は、AIの統制の道具がKYCと法令対応の業務をどう扱うかという広い話にも現れる。
再現できる出力。ルールに基づく道は、同じ入力に対して毎回同じ出力を出す。検査官が本当に求める性質であり、温度の設定に関わらず確率のモデルには保証できないものだ。「同じデータで判断を再生できないなら、規制当局はそれを引き裂く」
目で見えるフロー図の水準の監査の跡。決定論的な業務はフロー図として描け、一歩ずつそのまま見直せる。モデルの内側の推論の記録から組み立て直す必要はない。監査人は指示の設計を理解せずに、すべての判断の節を辿れる。
説明できないという穴がない。「なぜこの仕組みはこうしたのか」に対して、解釈すべき確率の分布ではなく、指し示せる規則がある。「動的なエージェントの振る舞いは、追えないデータの流れの危険を高める」とある実務者は述べたが、決定論的な業務はまさにその危険をなくす。
影のAIの一掃。承認された業務が、ひとつの統べられた定義の下で、RBAC、SSO、Active Directoryの連携とともにチームで共有されれば、ある作業を実行する道は承認されたひとつだけになる。割り当てのないまま費用を積む、十数通りの個人の指示の癖ではなく。Jinbaは作ることと動かすことを分ける。技術のチームはJinba Flowで作り、業務の担当は入力フォームの自動生成される対話の画面からJinba Appで実行する。すべての実行が、法令に適い費用を抑えられ監査された同じ道をたどる。
実例:三菱UFJのKYCにおける8対2の構成
三菱UFJフィナンシャル・グループの本人確認の処理は、およそ30〜40の業務の構成要素から成る、決定論を核にした構成の上で動いている。(KYC自動化のソフトの地図という基盤の水準の眺めについては、主要な道具の比較を用意している。)背骨はルールに基づく。書類の受け付けの検証、既知の型に対する項目の抽出、基幹系への本人確認の振り分け、そして規制の基準に応じた条件つきの印づけ。どれも大規模言語モデルを要さない。明示された確認と明示された出力である。
生成AIは統制された端でだけ入る。人の確認のために形の定まらない書類を要約すること、ある程度の揺らぎが許される社外向けの文書を下書きすること、そして固定の規則では捉えきれない本当にあいまいな事例を扱うことだ。モデルが助けたどの段階の出力も、動く前に人が確認する。
費用への含みは直接だ。生成の力が本当に効く業務の段階のおよそ2割にモデルの呼び出しを取っておくことで、三菱UFJは、明示的な規則として表せる8割の論理にトークンを燃やさずに済む。法令対応への含みも同じく直接だ。監査の跡は、規制当局の問いに数分で答えられるほどきれいである。
これは確率を既定とする道への理屈だけの代案ではない。世界最大級の銀行のひとつの中で、すでに機関の規模で動いている。
.png)
自分の状況に当てはまるのはどの節か
6つの定番の手と、構造の組み直しは、別々の問題に答える。すべてを一度に当てようとせず、自分を正しい節へ振り分けてほしい。
支出がどこへ行っているのかまだ分からない場合。他に何を変えるよりも先に、上の計測の節(利用の画面、トークンの記録、観測の基盤)から始めること。
支出は分かっていて、いまの構成のまま少しずつ節約したい場合。6つの定番の手を、実装の手間の順に進めること。まず出力トークンの抑えと文脈の縮小、次にモデルの振り分けとまとめ処理のAPI、最後に一時保存と層の割り当て。
業務を本番へ広げていて、費用と法令対応の本物の頭打ちにぶつかっている場合。決定論的な構成の節がそれだ。戦術の削り込みでは、KYCの流れや保険金処理の業務を、従業員2万人の規模で守りきれる費用と監査の姿にはできない。構成そのものが変わらねばならない。
つまずきどころと落とし穴
規制下の企業がこれらの手を本番で当てはじめると、いくつかのつまずき方が繰り返し現れる。
数週間で節約が消える。たいていは、指示の雛形が元と同じ変更の手続きを経ずに更新され、振り分けや一時保存の規則が気づかれずに戻っていた場合だ。統制と費用の調整が別々ではなく一緒に版管理されているか、確かめ直すこと。
安いモデルが例外で出力の質を落とす。これはモデルの振り分けを始めて数か月後、試験の集まりに入っていなかった書類で表に出る。振り分け先のモデルを、易しい多数ではなく本当に意地悪な標本で検証すること。
まとめ処理の節約が、約束した応答の時間の問題を連れてくる。非同期の処理は、顧客や検査官が同日中の回答を期待するものには向かない。広く有効にする前に、どの業務がまとめ処理に向くかを切り分けること。
決定論の部品が、それが写した規制からずれていく。去年の要求に合わせて作られたルールに基づくKYCの確認には、周りのモデルの呼び出しと同じ変更管理の規律が要る。決定論が利点になるのは、規則が最新であり続けるかぎりだ。
よくある質問
ありふれたOpenAIの費用対策が、規制下の企業に足りないのはなぜですか。
呼び出しあたりの値段は下がりますが、呼び出しそのものは変わらないからです。出力が定まらない確率的な判断のままで、しかも求められれば判断を再現し説明せねばならない環境の中で動いています。まとめ処理や一時保存はやる価値がありますが、規制当局が本当に気にする監査可能性の穴は解けません。
規制下でAIのAPIの費用を下げる、最も効く手はひとつ挙げるなら何ですか。
そもそも生きたモデルの呼び出しが要る作業の数を減らすことです。業務の論理の大半を決定論的でルールに基づく実行へ移し、本当に開かれた判断が要る狭い段階にだけモデルを残します。この構造の転換は、残った呼び出しへのどんな戦術の調整より一桁大きな節約を生みます。
決定論的な業務は、費用だけでなく法令対応をどう良くするのですか。
決定論の道は同じ入力から毎回同じ出力を生むので、検査官には確率の分布ではなく再現できる結果が渡ります。フロー図として表して一歩ずつ見直すこともでき、黒箱のモデルの呼び出しでは閉じられない、説明できないという穴を閉じます。
影のAIとは何で、企業のAPIの費用をどう押し上げるのですか。
影のAIとは、中央で統べられた業務の外で起きる利用のことです。個々の従業員やチームが、自分の指示、モデル、癖でAPIを直に呼ぶような使い方を指します。承認された業務に当てている一時保存、振り分け、まとめ処理の規律がないことが多く、事業の単位に割り当てるのも難しくなります。
企業は、OpenAIのAPIではなく自社でモデルを動かすべきなのは、どんなときですか。
データの所在の要求、量、そして業務のうちどれだけが本当にモデルの呼び出しを要し、どれだけが決定論的な論理で済むのかによります。8対2で決定論を先に置く型を回している企業では、APIの呼び出しの面が十分に小さく、完全に確率的な流れに比べて自社運用の採算は大きく変わります。自社運用は、おおよそ月500万〜1000万トークンで釣り合うとされますが、業務の8割がすでに決定論的なら、残ったモデルの呼び出しでその量に届かないかもしれません。
決定論的な業務の構成を、企業は実際どう始めればよいですか。
計測の段階から始めてください。いまAPIを通っている中で最も量が多く費用も高い業務を見つけ、そのどの段階が本当に開かれた言葉の作業で、どの段階が固定の確認、抽出、振り分けの判断なのかを地図にします。固定の論理の段階から規則へ移し、モデルの呼び出しは、その作業が規則に落とせないところにだけ残します。
一つひとつの呼び出しを最適化するのはやめよう。要らない呼び出しをなくしはじめよう。
規制下の企業にとって、OpenAIのAPIの費用を本当に下げる道は、2つの段階を通る。
- 戦術は、支出を計測し、そのうえで6つの定番の手(一時保存、振り分け、まとめ処理、出力の抑え、文脈の縮小、層の選択)を、各段階で法令対応を意識した統制とともに当てることだ。
- 構造は、8対2で決定論を先に置く形へ構成を移し、大規模言語モデルの呼び出しの大半をまるごとなくすことだ。15〜60倍の費用の優位を生み、どの戦術の手も届かない監査可能性の穴を閉じる。
この2つの段階は対立しない。戦術の手が時間を稼ぎ、残った呼び出しの無駄を減らす。構成の転換が頭打ちをなくす。多くの企業には両方が要るが、順序が大事だ。まず測り、次に最適化し、頭打ちが制約になったときに作り直す。
自社が指示の水準の手直しの先へ進み、規制下で本当に持ちこたえるAIの構成を設計する準備ができているなら、Jinbaは企業の責任者に向けて無料のAI戦略アセスメントを提供している。同じ転換を銀行に即して見たいなら、決定論的な業務で銀行のAIの費用を下げる方法を参照してほしい。私たちのコンサルタントは、三菱UFJ銀行を含むおよそ70件の企業導入の知見をもとに、AIの支出と法令対応の姿勢の両方に答える、取締役会に出せる計画を届ける。