外部ツール停止で自社AI利用が止まるか｜介在型と非介在型
生成AIの周辺ツール（ゲートウェイ・監視・可視化）が停止したときに、自社の生成AI利用が止まるかどうかは、ツールが通信経路に入る「介在型」か、入らない「非介在型」かで決まります。2つの方式の違い、停止時の影響、介在型を使う場合の対策、ツール選定時の確認点を情シス・DX推進向けに解説します。
生成AIの周辺ツールが停止したときに、自社の生成AI利用まで止まるかどうかは、ツールが通信経路に入る「介在型」か、入らない「非介在型」かで決まります。介在型（ゲートウェイ・プロキシ）は、すべてのリクエストがツールを通過するため、ツールが止まると生成AIの利用も止まります。非介在型（管理APIから利用量を読むツール）は、通信経路の外にいるため、ツールが止まっても生成AIの利用には影響しません。
この記事では、2つの方式の違い、停止時の影響、介在型を使う場合の対策を説明します。全体像は「生成AI導入のセキュリティ 完全ガイド」を参照してください。
介在型と非介在型
| 介在型 | 非介在型 | |
|---|---|---|
| 構成 | アプリケーション → ツール → 生成AIのプロバイダ | アプリケーション → 生成AIのプロバイダ（ツールは横から管理APIを読む） |
| 例 | ゲートウェイ、プロキシ、中継型の監視ツール | 管理APIから利用量・費用を読む可視化ツール |
| できること | リクエストの振り分け、キャッシュ、流量制限、遮断、内容の検査 | 利用量・費用の可視化、予算の通知、急増の検知 |
| ツール停止時 | 生成AIの利用が止まる（迂回しない限り） | 生成AIの利用は止まらない。可視化と通知が止まるだけ |
| 応答の速さへの影響 | ツールを通過する分の遅延が加わる | 影響しない |
| プロンプトの扱い | 通過する（保存するかは設定による） | 扱わない（メタデータのみ） |
| 導入の手間 | アプリケーションの接続先を変える | 読み取り専用の認証情報を登録する |
停止時の影響
介在型が止まると
| 影響 | 内容 |
|---|---|
| 生成AIを使う業務が止まる | 社内チャット、要約、問い合わせ対応など、ツール経由のすべての利用 |
| 影響が全社に及ぶ | 1つのツールに全部署の利用を集めている場合、全部署が止まる |
| 復旧までの対応 | 迂回の手順（プロバイダへ直接つなぐ）がなければ、復旧を待つしかない |
介在型のツールは、生成AIの利用にとっての単一障害点になりえます。生成AIが業務に深く組み込まれるほど、停止の影響は大きくなります。
非介在型が止まると
| 影響 | 内容 |
|---|---|
| 可視化の画面が更新されない | 利用量・費用の最新の数字が見られない |
| 通知が届かない | 予算や急増の通知が、停止中は届かない |
| 生成AIの利用 | 影響なし |
非介在型は、停止中のデータも復旧後にプロバイダの管理APIから取得し直せることが多く、停止期間の利用量が失われにくいのも特徴です。
どちらを選ぶか
目的によって選びます。
| 目的 | 向いている方式 |
|---|---|
| 費用・利用状況の可視化、予算の管理 | 非介在型で足りる |
| 急な増加・漏えいの検知（気づく） | 非介在型で足りる |
| 利用の遮断・流量の制限（止める） | 介在型が必要 |
| 複数モデルへの振り分け・キャッシュ | 介在型が必要 |
| 入力内容の検査 | 介在型（または端末側の仕組み）が必要 |
「気づく」は非介在型、「止める・変える」は介在型と整理できます。可視化や費用の管理だけが目的なら、介在型を入れて単一障害点を作る必要はありません。止める機能が必要な場合は、各プロバイダの利用上限の機能（最後の砦）と組み合わせることも検討します。
介在型を使う場合の対策
介在型が必要な場合は、停止の影響を小さくする対策を取ります。
| 対策 | 内容 |
|---|---|
| 冗長構成 | ツールを複数の拠点・インスタンスで動かす |
| 迂回の手順 | ツールが止まったときに、プロバイダへ直接つなぐ手順と判断基準を決めておく |
| 対象を限定する | すべての利用を通すのではなく、統制が必要な用途に限る |
| 監視と通知 | ツール自体の稼働を監視し、停止をすぐに知る |
| 稼働率の保証の確認 | 提供元の稼働率の保証（SLA）と、停止時の連絡の体制を確認する |
ツール選定時の確認点
| 確認点 | 質問の例 |
|---|---|
| 通信経路に入るか | 「このツールが停止したら、当社の生成AIの利用は止まりますか」 |
| 停止時の挙動 | 「停止時にリクエストは失敗しますか、素通りしますか」 |
| 停止中のデータ | 「停止中の利用量は、復旧後に取得できますか」 |
| 遅延 | 「リクエストに加わる遅延はどのくらいですか」 |
| 導入時の変更 | 「アプリケーションの接続先の変更は必要ですか」 |
最初の質問への答えが「止まります」なら、停止時の対策を必ず確認します。
停止の影響を評価する手順
介在型のツールを検討するときは、停止したときの影響を次の手順で評価します。
- ツールを通る利用を洗い出す: どの部署の、どの業務・システムがツールを経由するか
- 業務ごとに止まったときの影響を見積もる: 顧客対応が止まる、社内の作業が遅れる、など
- 許容できる停止時間を決める: 数分なら許容できるか、数時間でも許容できるか
- 迂回の手順を決める: 誰の判断で、どうやってプロバイダへ直接つなぐか
- 提供元の稼働の実績と保証を確認する: 稼働率の保証、障害時の連絡、過去の障害の公開状況
顧客対応など、止まると影響の大きい業務が介在型のツールを通る場合は、迂回の手順を事前に試しておくことが重要です。
事例で考える（架空の例）
ある企業が、全社の生成AIの利用をゲートウェイ経由に集約した、という架空の例です。
| 時点 | 起きたこと |
|---|---|
| 導入時 | 可視化と費用の管理のため、全社の API 利用をゲートウェイ経由に切り替えた |
| 障害時 | ゲートウェイの提供元で障害が起き、社内チャットと問い合わせ対応の自動応答が止まった |
| 対応 | 迂回の手順がなく、復旧まで数時間、業務を手作業で行った |
| 見直し | 費用の可視化は管理APIを読む非介在型に切り替え、ゲートウェイは流量制限が必要な一部の用途に限定した |
目的が「可視化」だけなら、通信経路に入る必要はなかった、というのがこの例の教訓です。
よくある質問
Q. 非介在型でも、急な増加に気づくことはできますか？ できます。管理APIから利用量を定期的に取得し、時間単位の推移を過去と比べれば、急な増加を検知して通知できます。検知までに取得の間隔ぶんの遅れがあることは前提にします。
Q. 介在型と非介在型を併用することはありますか？ あります。一部の用途だけ介在型のゲートウェイで統制し、全社の利用状況と費用は非介在型で可視化する、という組み合わせです。
Q. 非介在型のツールが止まっている間の通知はどうなりますか？ 停止中は通知が届きません。復旧後に利用量を取得し直せば、停止中の状況も確認できます。停止中の被害を抑えたい場合は、プロバイダ側の利用上限を最後の砦として設定しておきます。
Q. 自社でゲートウェイを作る場合も同じですか？ 同じです。自社で運用するゲートウェイも、止まれば生成AIの利用が止まります。冗長構成と迂回の手順、運用の体制まで含めて検討します。
まとめ
- 周辺ツールの停止で生成AIの利用が止まるかは、介在型（通信経路に入る）か非介在型（入らない）かで決まる
- 介在型は、振り分け・遮断・検査ができる一方、停止時に利用が止まる単一障害点になりえる
- 可視化・予算管理・急増の検知（気づく）は非介在型で足りる。止める・変えるには介在型が必要
- 介在型を使う場合は、冗長構成・迂回の手順・対象の限定で停止の影響を小さくする
ManageAIは、プロバイダの管理APIから利用量と費用を読み取る非介在型の可視化ツールです。通信経路に一切介在しないため、ManageAIが停止しても、貴社の生成AIの利用には影響しません。影響は可視化と通知の停止に留まります。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ