生成AIの利用料は、多くの場合、利用者の人数ではなく使った量で決まります。量の単位はトークンと呼ばれ、送った文章と返ってきた文章の長さ、添付した資料、エージェントが繰り返した処理の分だけ積み上がります。この量は請求書の話として扱われがちですが、2026年10月にカナダ サイバーセキュリティセンターが公表した文書は、同じ量を「業務を止めないための資源」として扱っていました。上限に達したAIは、その時点で使えなくなるからです。
この記事の要点
- カナダ サイバーセキュリティセンターの文書「Managing AI token consumption for operational resilience」（ITSM.00.125、2026年10月22日更新）は、AIの利用量の上限を、費用だけでなく業務の継続に関わるリスクとして整理している
- 文書は、利用量の枠を業務への影響で3段に分けて割り当てることや、上限の70%・80%・90%で段階的に警告を出す例を示している
- あわせて、外部の提供元が使えないときに備えた複数の提供元への振り分けや、小さなモデル・ローカルで動くモデル・手作業への切り替えを、平時に用意しておく項目として挙げている
利用量が「止まる理由」になる
文書には「Five Eyes」の表示があり、本文は複数の機関の連名（authoring agencies）として書かれています。文書はまず、外部のAIサービスが従来のソフトウェアと違う課金の仕組みで動いていることを確かめています。利用者数やライセンスではなく、入力と出力の量と種類、処理の内容に応じて支払う仕組みです。量はプロンプトや応答の長さ、モデルに渡す文脈、使う機能で変わるため、予測と管理が難しくなります。
簡単な質問なら数百トークンで済む一方、大きな文書の分析や複数段の自動処理では数万トークンに及ぶことがある、と文書は書いています。エージェントの処理は、各段階で前の内容とツールの出力を処理し直すため、費用が積み重なります。
そのうえで文書は、利用量に関わるリスクを6つ並べています。費用の上昇と予測の難しさ、重要な業務が使える量の不足、利用状況の見えにくさ、性能の低下、利用量の枯渇、そして利用量を狙う攻撃です。このうち、費用の話にとどまらないのが枯渇と攻撃です。
上限に達すると、AIを使う業務がそのまま止まる
文書の言う枯渇は、組織が割り当てられた量の上限、利用の割り当て、処理の速度の上限、予算の上限のいずれかに達した状態です。正当な利用の集中でも、効率の悪いアプリケーションでも、需要の急増でも起こります。
枯渇すると、遅延、性能の低下、要求の失敗、AIの機能が使えなくなるといったことが起きます。業務の重要な部分をAIに頼っている組織ほど、代わりの手段を用意していなければ影響が大きい、と文書は指摘しています。
対策の例として挙げられているのが、段階的な警告です。上限の70%に達したら情報としての通知、80%で警告、90%で重大な警告とする、という例が示されています。
さらに文書は、利用量そのものを狙う攻撃にも触れています。自動化したプロンプトや、外から使えるAIの窓口の悪用によって大量の利用を発生させ、割り当てや予算を使い切らせる攻撃です。費用を膨らませて金銭的な損害を与えることを狙う形もあり、例として、長い出力を求める複雑な入力や、AIの出力を再び入力に戻させるループが挙がっています。当社の見方では、社外に公開したチャットボットや、メールや問い合わせを自動で処理するエージェントは、この入り口になりえます。
業務の重要度で3段に分けて割り当てる
文書が中心に置いているのは、利用量を業務への影響で優先付けする考え方です。日常的で量の多い利用が、最も重要な業務に必要な量を食わないよう、割り当てを3段に分ける案が示されています。
- 第1段 最重要: サイバー防御、インシデント対応、脅威情報など。利用できる量と継続性を最優先にする
- 第2段 業務: 給付の処理、コンプライアンス対応、方針の分析など、欠かせない業務の処理。利用量を監視し、安定した運用と費用の管理を両立させる
- 第3段 生産性: メールの下書き、会議の要約、一般的な調べものなど日常の利用。需要が高い時期には、利用の制限や縮小の対象になりうる
専用の枠を確保すれば費用は増えうるが、回復力と業務の継続を支えられる、とも書かれています。一方で、最重要の業務だけを優遇すると優先度の低い業務が滞るため、配分の釣り合いを取るよう求めています。
この3段は、社内に当てはめると問いの形になります。障害対応の最中に、社員全員が会議の要約に同じ契約の枠を使っていたら、対応に使うAIは残っているか。分けていなければ、答えは利用状況しだいです。
外部の提供元が使えないときの用意
文書は、回復力と運用管理の項目として、次のようなことを挙げています。
- 複数の提供元を使える構成にし、1社への依存を減らす
- 障害やサービスの中断時には、使える提供元へ処理を振り分ける
- 業務の要件を満たす中で、最も費用の低いモデルを選ぶ
- 従来のツール、信頼できる提供元の小さなモデルやローカルで動くモデル、手作業のほうが効率的な場面を見分ける
重要インフラの事業者に向けた節では、AIが使えないか信頼できなくなった場合に備えて、AIに頼らない手段（手作業での運用の訓練など）を維持することも挙げています。全ての処理に同じ高価なモデルを使う必要はなく、作業に合わせてモデルの大きさを選べば費用を抑えられる、という記述もあります。
外部のモデルを使うか、ローカルで動くモデルを使うかは、業務の必要に応じて組織が決めることだ、と文書は書いています。ローカルのモデルは、費用の話だけでなく、外部の上限や障害の影響を受けない代わりの経路としても位置づけられています。
利用量の急増を、異常の兆候として見る
監視の項目には、セキュリティの側から見ても目を引く記述があります。利用量の異常な増加を、帯域の急増が不正なデータ転送を示すことがあるのと同じように、データ持ち出しの兆候になりうるものとして監視する、というものです。利用量の記録をセキュリティ監視の基盤（SIEM）に入れ、ID、クラウド、API、システムのログと突き合わせることも挙げられています。
そのための手段として、AIゲートウェイやプロキシ、集中監視の仕組みで、AIの利用状況、利用量、費用、方針の順守を見えるようにすることが挙がっています。AIプロキシは、利用量の計測、割り当ての強制、ガードレールの適用、部門ごとの費用配分を支える現実的な方法になりつつある、とも書かれています。社員それぞれが個別の契約や個人の鍵でAIを使っている状態では、この監視の前提になる「全体でどれだけ使っているか」がそもそも分かりません。
社内でAIを業務に組み込む前に決めること
ここからは当社による置き換えです。文書の項目を、社内でAIを業務に組み込む場合の準備に並べ直すと、次の4つになります。
- どの業務が、どの契約の枠を使っているか: 全社で1つの枠を共有しているのか、部門や用途で分かれているのか。社員が個人で契約しているものも含めて把握できているか
- 上限に近づいたとき、何を後回しにするか: 障害対応や顧客対応に使うAIと、日常の下書きや要約を、同じ順番で扱ってよいか。後回しにする判断を誰がするか
- 止まったときの代わりの経路: 別の提供元、社内で動かすモデル、手作業のどれに切り替えるか。切り替えの手順を、止まる前に試しているか
- 利用量の記録を誰が見るか: 費用として経理が月に一度見るだけか、異常の兆候として日々見る人がいるか
1がないまま2から4を決めることはできません。利用の経路が社員ごとに分かれていれば、上限も記録も経路ごとに分かれ、会社として一つの答えを返せないためです。
AIの経路と代わりの経路を設計する
当社のセキュリティFDEでは、FDE（伴走エンジニア）が、AIを業務で使うときの守りをお客様の環境に合わせて組み上げます。社内のAI利用の経路を洗い出す段階から、外部サービスが使えないときに切り替える社内のモデルの置き場所の検討まで、ご相談いただけます。ネットワークの側でAIへの通信を見える形にする手段としては、AIの出口制御と通信制御を行う透過型UTM「ForceUTM」も扱っています。
参考資料
AIの利用経路と代わりの経路を決める
社内のAI利用の洗い出しや、外部のAIサービスが使えないときの切り替えの手順づくりについてご相談ください。
AIセキュリティの取り組みはAIセキュリティのサイトでご覧いただけます。
まずは相談する相談無料・