社内AIの使用量を見積もる5工程｜上限に当たる前に決める

「全社に配る前に使用量の見積もりを出せと言われたのですが、人数を掛ける以外に何を数えればいいのか分かりません」「月の予算には収まっているのに、特定の時間帯だけ返ってこないという声が上がってきます」——社内に生成AIを配った後の担当者から出てくる言葉です。この二つが同時に起きるのは、偶然ではありません。使用量の上限は月ではなく分の単位で効くので、月の合計が予算内でも、同じ分に重なった呼び出しは弾かれます。この記事では、配った後に量がどこまで増えるかを先に見積もる手順を、公開されている技術文書の仕様に沿って5つの工程に分けます。

「人数を掛ければ出る」が、いちばん多い誤解

見積もりの依頼を受けたとき、最初に作られるのはたいてい1枚の表です。配る人数、1人あたりの想定回数、1回あたりの単価。この3つを掛けて月額を出す。費用の概算としてはこれで合っていますが、この表からは、いつ止まるかが一切読み取れません。止まる条件は、月の合計とは別の場所に置かれているからです。

前提の人数も、実態とずれます。帝国データバンクが2026年3月17日から31日にかけて全国2万3,349社に行い、1万312社から回答を得た調査（回答率44.2%）では、生成AIを活用していると答えた企業は34.5%でした。規模別では大企業46.5%、中小企業32.4%、小規模企業28.0%です。会社として導入していても、社内の全員が使っている状態とは限りません。

使う頻度の分布はもっと偏ります。パーソル総合研究所が2025年10月に正規雇用者3,000名を対象に行った調査では、業務での生成AIの利用率は32.4%でした。内訳は週4日以上が11.7%、週1日から3日が12.4%、月に数日以下が8.4%です。使う人の中でも、量を作っているのは上の1割強だけという形になります。人数を一律に掛ける見積もりは、この偏りを平らにしてしまいます。

上限は月ではなく、分の単位で効く

生成AIを社内の仕組みに組み込むとき、ほとんどの提供元は2つの上限を対で設定します。1分あたりに処理できるトークン数の上限と、1分あたりに受け付ける呼び出し回数の上限です。マイクロソフトが公開している運用の技術文書では、この2つが比例して割り当てられると明示されています。

具体的な比率も書かれています。古い世代の対話モデルでは、割り当ての1単位が毎分6回の呼び出しと毎分1,000トークンに対応します。推論を重ねる世代では毎分1回に対して毎分1,000トークンから1万トークンというように、モデルごとに比率が変わります。同じ予算でも、モデルを替えると受け付けられる回数がまるごと変わるということです。

さらに厄介なのが、回数の上限が1分単位では判定されないことです。同じ技術文書には、呼び出し回数は1秒から10秒程度の短い窓で評価されると書かれています。毎分600回の設定なら、1秒あたり10回を超えた時点で弾かれます。1分の合計が300回でも、最初の10秒に200回が集まれば止まります。平均ではなく、山の高さが上限を決めているのはこのためです。

見積もりに要るのは、3つの数字だけ

必要な入力は3つに絞れます。山の時刻における毎分の呼び出し回数、1回あたりの入力の長さ、1回あたりの出力の長さ。マイクロソフトが公開している処理能力の見積もり手順でも、事前に用意すべき情報としてこの3つが挙げられています。

この3つで足りるのは、1回の重さが入力と出力の長さだけで決まるからです。どんな用途に使っているか、どの部署が使っているかは、量の計算には入りません。用途は長さを通じてしか効きません。だから見積もりの作業は、用途を分類することではなく、用途ごとの長さを測ることになります。

3つのうち、社内で最も測られていないのが出力の長さです。入力は自分たちで書いた文なので見当がつきますが、返ってくる文の長さは用途で大きく変わります。数行の要約と、数千字の草稿では10倍以上の差が出ます。出力の長さを測っていない見積もりは、桁が合いません。

使用量を見積もる5つの工程

作業の順番にします。人数から始めて、回数、長さ、山、余裕の順です。どの工程も、推測ではなく実際の記録に当てるところまでを1工程として扱ってください。

この5工程で最も飛ばされるのが4番目です。1日の平均で見積もった上限は、朝の始業直後に必ず割れます。平均の値は費用の見積もりには使えますが、止まるかどうかの見積もりには使えません。

工程1：席数と、実際に使う人の差を先に確定する

契約の席数と、実際に使う人の数は一致しません。全社に配った直後は触ってみる人が多いので数字が上がり、数週間で落ち着きます。見積もりに使うべきなのは、配って2か月ほど経ってからの数字です。配った初月の数字を土台にすると、過大な設備を抱えることになります。

落ち着いた後の水準は、先に挙げた調査の分布が目安になります。業務で使っている人が3割ほど、そのうち週4日以上の層が全体の1割強。1,000人の会社なら、日常的に使うのは100人台、その上位に量を作る数十人がいるという形です。ここから先は自社の記録で置き換えていきますが、記録が無い段階ではこの分布から始めて構いません。

同時に使う人数は、さらに別の数字です。100人が1日に10回使っても、それが8時間に散れば毎分あたりは2回程度にしかなりません。逆に朝の30分に半分が集まれば毎分の値は跳ね上がります。見積もるのは延べ人数ではなく、同じ分に重なる人数です。この差を最初に言葉で分けておかないと、会議の途中で数字がすり替わります。

工程2：1人あたりの回数は、用途の分布から置く

回数を置くときは、用途の分布から入ります。帝国データバンクの同じ調査では、活用している業務として文章の作成・要約・校正が45.1%、情報収集が21.8%、企画立案時のアイデア出しが11.0%と並んでいました。文章まわりが半分近くを占めるという形は、多くの会社で共通します。

この分布が効くのは、用途によって1回の重さが違うからです。文章の校正は入力も出力も短く、1回が軽い。情報収集は往復の回数が増えます。企画のアイデア出しは1回の出力が長くなります。回数だけを数えると、軽い用途が多い会社と重い用途が多い会社が同じ数字になります。

実務では、用途を3つか4つに丸めて、それぞれの1日あたりの回数を置きます。細かく分けても精度は上がりません。分ける目的は、この後の工程で長さを測る単位を作ることです。パーソル総合研究所の調査では、時間の削減幅が大きい業務として企画・相談・思考整理が週36.9分、文書や資料の作成・編集が週35.1分、データの分析や報告が週33.6分と並んでいました。削減幅が大きい業務は、それだけ長く使われている業務でもあります。

工程3：1回の長さは、入力と出力を分けて測る

ここが見積もりの中心です。1回の呼び出しの重さは、入れた文の長さと返させた文の長さの2つで決まります。この2つを1つの平均にまとめてしまうと、後の計算がまるごと狂います。分けて測るというのは、手間の話ではなく仕様の話です。

測り方は単純で、実際のやり取りを用途ごとに10件ほど取り出して、入力と出力それぞれの長さを数えます。ここで注意が要るのが、入力に含まれるのが利用者が書いた文だけではないことです。社内資料を参照させる仕組みなら、探してきた資料の本文も入力に乗ります。過去のやり取りを引き継ぐ仕組みなら、それも毎回の入力に積み上がります。

この積み上がりが、見積もりを最も大きく外す原因です。利用者から見れば1行の質問でも、実際に送られている入力が数千トークンということが普通に起きます。利用者の体感ではなく、送られている内容そのもので測ってください。手元の記録で測れないなら、仕組みを作った側に1度だけ実測を依頼します。

出す側の1回は、入れる側の何回分として数えられるか

ここに、見積もりで最も見落とされる仕様があります。出力のトークンは、入力のトークンより重く数えられます。生成の処理に余分な計算が要るためで、マイクロソフトの見積もり手順には、出力と入力の換算の倍率がモデルごとに表で示されています。

倍率は世代によって違います。ある世代では出力1トークンが入力8トークン分として利用率に数えられ、別の世代では4トークン分として数えられます。つまり同じ長さのやり取りでも、モデルを替えるだけで必要な処理能力が2倍変わります。モデルの選定を量の見積もりと切り離して進めると、ここで計画が崩れます。

計算の形も公開されています。入力側の毎分トークンは山の毎分回数に平均の入力長を掛けたもの、出力側も同じ。この2つを、出力側に倍率を掛けたうえで足すと、正規化された毎分トークンが出ます。あとはそれをモデルごとの1単位あたりの処理量で割れば、必要な枠の数になります。

条件	入力側の毎分	出力側の毎分	換算後の毎分	必要な枠
毎分1,000回・入力200・出力20・倍率8	20万	2万	36万	110
同じ条件で、入力の50%が使い回せる場合	10万	2万	26万	80

これはマイクロソフトの技術文書に載っている計算例そのものです。1単位あたりの処理量が3,400という設定で、換算後の36万を割ると105.88となり、刻みに合わせて切り上げると110になります。出力がわずか20トークンでも、倍率8が掛かると入力の8分の1の長さで入力側の8割の重さになります。出力を短く抑える指示が量に効くのは、この倍率があるためです。

工程4：山は1日・1週間・1か月の3つの周期で探す

呼び出しが集まる時刻には、はっきりした周期があります。1日の中では始業直後と昼休み明け。1週間の中では週明けと、週末に向けた提出前。1か月の中では月末の締めと、その直後です。この3つの周期は重なります。月末の週明けの朝が、多くの会社で最も高い山になります。

山を探すときに見るのは、月の合計ではなく毎分の値です。記録が1時間単位でしか取れない場合は、1時間の値をそのまま60で割ってはいけません。1時間の中でも偏っているからです。実務では、1時間の値を60で割った数字の2倍から3倍を、その時間帯の毎分の山として置くという扱いをします。この倍率は、記録が細かく取れるようになった段階で実測に置き換えます。

業務の仕組みに組み込んだ自動処理がある場合は、別に数えます。夜間にまとめて走らせる処理は、人の利用と時刻が重ならないので合算すると実態から離れます。人が使う量と、仕組みが使う量は別の表に分けてください。分けておけば、上限に近づいたときに片方だけを遅らせるという手が打てます。

工程5：余裕を乗せる割合は、推定の粗さから決める

最後に余裕を乗せますが、何割乗せるかには根拠が要ります。根拠になるのは、上限の判定そのものが粗いという仕様です。マイクロソフトの技術文書は、上限の判定に使われるトークン数は受け取った時点の推定値であり、課金に使う正確なトークン数とは別物だと明記しています。

推定に何が含まれるかも書かれています。本文の推定量に加えて、出力の上限として指定した値と、候補をいくつ作るかの指定値です。つまり実際には200トークンしか返らない用途でも、出力の上限に4,000と書いてあれば、4,000トークン分として枠を消費します。同じ文書には、期待する出力が200トークン程度なら上限を4,000にしないことという助言が添えられています。

この仕様は、見積もりの前に直せる項目でもあります。用途ごとに出力の上限を実態に合わせるだけで、同じ処理能力で受けられる回数が増えます。余裕の割合を決める前に、まずこの設定を見直してください。そのうえで、短い窓でのばらつきを考えると、山の値に対して3割から5割の余裕を見ておくのが現実的です。

ここまでの5工程で、やってはいけない形も決まります。下の5つは、いずれも見積もりの表としては成立するのに、止まる時刻を当てられない作り方です。

• 月の合計だけを見て上限を決める（止まるかどうかは分の単位で決まる）
• 1日の合計を営業時間で割って、それを毎分の値として使う（山が平らになる）
• 入力と出力の長さを1つの平均にまとめる（出力には倍率が掛かる）
• 用途と関係なく、出力の上限を大きい値のまま全社に配る（枠を無駄に消費する）
• 上限に当たったとき、待ち時間を置かずにそのまま再試行する（失敗した要求も上限に数えられる）

同じ文を繰り返し送ると、量が減る仕組みがある

社内で使う指示文は、前半がほとんど同じになります。役割の説明、守ってほしい書式、参照する社内規程。この共通部分は毎回送られるので、そのままなら毎回まるごと量に数えられます。

ここに効くのが、同じ入力を使い回す仕組みです。マイクロソフトの技術文書では、使い回された入力トークンは利用率の計算から100%差し引かれると書かれています。先の計算例でも、入力の50%が使い回せる場合は換算後の毎分が36万から26万に下がり、必要な枠が110から80に減っています。3割近い削減が、文章を書き換えずに得られるということです。

効かせるには条件があります。共通部分を毎回先頭に、同じ並びで置くこと。途中に日付や利用者名を混ぜると、そこから後ろが使い回せなくなります。社内で配る指示文の雛形を作るときは、変わる部分を後ろにまとめてください。これは運用の決めごと1つで効く、数少ない項目です。

長い入力を許すと、見積もりが一段変わる

長い資料をまるごと読ませる使い方を許すかどうかは、量の見積もりを一段変えます。1回の入力が数千トークンの世界から、数万トークンの世界に移るからです。1人が1回使うだけで、通常の用途の数十回分を消費します。

長い入力には、別の重みが付く場合もあります。マイクロソフトの技術文書に載っている最新世代の重み表では、長い文脈の入力は短い文脈の入力の2倍、長い文脈の出力は7.5倍として数えられています。長い資料を読ませて長い文章を返させる使い方は、最も重い組み合わせです。

受け付けない場合もあります。同じ文書には、12万8,000トークンを超える入力に対応していないモデルがあり、その場合は別の受け皿に回されるか、受け皿が無ければ失敗として返ると書かれています。長い入力を許すなら、許す用途と、許す人の範囲を先に決めておく。全員に開放したうえで後から絞ると、使い始めた業務を止めることになります。

画像を扱う用途を許す場合は、もう一段の換算が入ります。同じ技術文書に載っている画像向けの見積もりでは、画像の入力トークン1つが文字の入力トークン1.6個分に相当し、画像として出力されるトークンはさらに画像の入力の3.75倍として重み付けされます。つまり画像を1枚返す1回は、文字だけのやり取りとは桁の違う重さになります。資料の図版づくりをAIに任せる運用を始めるなら、文字の用途とは別の表で見積もってください。

量のほかに当たる上限を、先に一覧で確認しておく

止まる原因は、1分あたりの量だけではありません。1回の呼び出しの形そのものに上限が置かれていて、そこに当たると量に余裕があっても失敗します。見積もりの表を作る前に、使う予定の仕組みについて次の項目を確認しておいてください。

• 1回の対話に含められるやり取りの件数の上限（公開されている例では2,048件）
• 1回の呼び出しで渡せる外部の道具の数の上限（公開されている例では128個）
• 文章を数値の並びに変換する処理で、1回に渡せる件数と合計のトークン数の上限
• まとめて処理する仕組みで、1つのファイルに入れられる件数の上限（公開されている例では10万件）
• 割り当てを変更してから、実際に反映されるまでの待ち時間（公開されている例では最大15分）

実務で効くのは、最後の待ち時間です。上限に当たったので割り当てを増やしたのに、現場ではまだ弾かれ続ける。この15分のあいだに「増やしても直らない」という判断が下されて、別の対処に走ってしまうことがあります。割り当てを変えたら、反映までの時間を待ってから効果を見ると手順に書いておくだけで、この混乱は消えます。

割り当ての分け方にも自由度があります。同じ技術文書によれば、ある地域に24万トークンの割り当てがあるとき、1つの配置に24万をまとめて割り当てても、12万ずつ2つに分けても構いません。人が使う用途と、仕組みが自動で走らせる用途を別の配置に分けておけば、片方が枠を食い尽くしても、もう片方は止まりません。量を見積もる段階で、この分け方まで決めておくのが安全です。

上限に当たったとき、現場ではどう見えるか

上限に当たった状態は、担当者のところに「エラーが出ました」という形で届きません。現場で起きるのは、返ってこない、途中で止まる、いつもより遅い、のいずれかです。利用者は不具合と区別できないので、上限の話としては報告されません。ここが、上限に当たっているのに気づかれない理由です。

仕組みの側には手がかりが残ります。上限を超えた呼び出しには、要求が多すぎることを示す応答コード429が返ります。応答の見出しには、残りの呼び出し回数、残りのトークン数、上限が戻るまでの秒数、そして再試行までの推奨の待ち時間が入っています。この見出しを記録していない仕組みでは、後から原因を切り分けられません。

もう一つ、止まらずに遅くなる形もあります。同じ技術文書には、月あたりの使用量の段階を超えると応答までの時間が段階内のときの2倍以上になることがあると書かれています。止まらないので誰も報告しませんが、待ち時間が2倍になれば現場では使われなくなります。速度の低下も、量が上限に近いことの合図として扱ってください。

使用量の数字は上限より低いのに、止まることがある

見積もりの答え合わせでいちばん混乱するのがここです。管理画面の使用量は上限の半分しか使っていないのに、現場では弾かれている。マイクロソフトの技術文書は、この2つが別の数字であることをはっきり書いています。使用量の指標は課金された成功分、上限の判定は受け取った時点の推定です。

• 出力の上限を大きく指定していると、実際の出力が短くても大きい方の値で枠を消費する
• 入力が長すぎて弾かれた要求も、回数の上限には数えられるが、使用量の指標には出てこない
• 短い窓のばらつき。1分の合計が上限内でも、1秒から10秒の窓に集まれば弾かれる
• 共用の資源では、全体の需要が高いときに実効の上限が一時的に下げられることがある。数時間で戻る
• 失敗した要求も上限に数えられる。間を置かずに再試行を繰り返すと、状態はさらに悪くなる

最後の項目は、仕組みを作る側に直接効きます。再試行は、待ち時間を倍にしながら、ばらつきを混ぜて行います。全員が同じ秒数で再試行すると、次の秒にまた山ができます。応答の見出しに入っている推奨の待ち時間があれば、それに従うのが最も確実です。再試行の回数にも上限を置き、5回から10回程度で諦めるようにしておきます。

増える前に決めておく、止める順番と人が確認する範囲

量は必ず増えます。増えてから慌てて止めると、業務のどれを止めるかを現場の声の大きさで決めることになります。増える前に、止める順番を紙に書いておいてください。判断に迷う余地を残さないことが、この作業の目的です。

• 止める順番：まとめて走らせる自動処理 → 長い資料を読ませる用途 → 対話での利用、の順で止める
• 止める判断の線：山の時刻の毎分の値が、設定した上限の何割に達したら止めるかを数字で決める
• 止めたことを誰に、どの経路で知らせるか。知らせないまま止めると不具合として報告が上がる
• 例外：止めない用途を1つだけ決めておく。全部止める運用は現場で守られない
• 見直しの周期：毎月、山の値と上限の距離を測り直す。3か月同じ数字なら見積もりを作り直す

そして、見積もりの数字そのものをAIに出させないでください。使う人数も、1回の長さも、山の高さも、自社の記録にしかありません。生成AIに聞けばもっともらしい数字が返りますが、それは他社の事例の平均を言葉にしたものです。AIに任せてよいのは、記録から数を拾い出す下ごしらえと、計算の式を組む作業までです。

AIを使う場合も、根拠を必ず書かせます。どの記録の、どの期間の、何件から出した数字なのか。根拠の欄が埋まらない数字は、見積もりの表に載せない。そのうえで、上限の設定を変える判断と、止める判断は人が持つと決めておきます。帝国データバンクの調査でも、課題の筆頭は情報の正確性で50.4%、次いで専門人材やノウハウの不足が41.3%、活用すべき業務の範囲が40.0%でした。範囲を先に決めることが、そのまま正確性の問題への手当てになります。

まとめ

社内の生成AIがどこまで増えるかは、人数を掛けても出ません。止まるかどうかを決めているのは月の合計ではなく、同じ分に重なる呼び出しの数と、1回あたりの入力と出力の長さです。しかも回数の上限は1分ではなく、1秒から10秒の短い窓で見られています。平均ではなく山の高さで見積もる理由は、ここにあります。

5つの工程は、使う人を数える、1人あたりの回数を置く、入力と出力の長さを分けて測る、1日と1週間と1か月の山を探す、推定の粗さに合わせて余裕を乗せる、の順です。出力は入力の4倍から8倍として数えられる仕様があるので、出力の上限を実態に合わせるだけで受けられる回数が増えます。共通する指示文を先頭に固定すれば、使い回しで3割近く減ることもあります。

上限に当たった状態は、現場からは不具合としてしか見えません。応答に残る手がかりを記録していなければ、原因の切り分けもできません。だから量が増える前に、止める順番と、止める判断の線と、知らせる経路を決めておきます。そして見積もりの数字自体は自社の記録から取り、AIには根拠を書かせて下ごしらえまでを任せる。この線を先に引いておけば、上限に当たっても業務の止め方を自分たちで選べます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。