通信経路に介在しない可視化とは｜可用性を損なわない設計
生成AIの利用状況を、通信経路に介在せずに可視化する方式（非介在型・プル型）の仕組みを解説します。プロバイダの管理APIから利用量を定期的に読み取る構成、介在型との違い、可用性・セキュリティ・導入の手間の面での利点、できることとできないこと、導入時に確認すべき点をまとめました。
通信経路に介在しない可視化とは、アプリケーションと生成AIのプロバイダの間に入らず、プロバイダが記録した利用量を管理APIから定期的に読み取って可視化する方式です。「非介在型」や「プル型」とも呼ばれます。リクエストはこれまでどおりプロバイダに直接届き、可視化の仕組みは横から利用の記録を読むだけなので、可視化の仕組みが止まっても生成AIの利用は止まりません。
この記事では、非介在型の仕組み、介在型との違い、利点、できることとできないこと、導入時の確認点を説明します。全体像は「生成AI導入のセキュリティ 完全ガイド」を参照してください。
非介在型の仕組み
[社員・社内システム] ──リクエスト──▶ [生成AIのプロバイダ]
│ 利用の記録（トークン数・モデル・時刻・キー）
▼
[プロバイダの管理API]
│ 読み取り専用の権限で定期的に取得
▼
[可視化の仕組み] ─▶ 画面・通知
| 段階 | 内容 |
|---|---|
| 1. 利用 | 社員や社内システムが、これまでどおりプロバイダに直接リクエストを送る |
| 2. 記録 | プロバイダが、利用量（トークン数・モデル・時刻・キー）と費用を記録する |
| 3. 取得 | 可視化の仕組みが、読み取り専用の認証情報で管理APIから定期的に利用量を取得する |
| 4. 集計・表示 | キーを部署・利用者に対応付けて集計し、画面に表示する。予算や急増で通知する |
可視化の仕組みは、リクエストの経路のどこにもいません。これが「介在しない」という意味です。
介在型との違い
| 介在型（ゲートウェイ・プロキシ） | 非介在型（管理APIの読み取り） | |
|---|---|---|
| リクエストの経路 | ツールを通過する | ツールを通過しない |
| 導入時の変更 | アプリケーションの接続先を変える | 変更なし。認証情報を登録するだけ |
| 停止時の影響 | 生成AIの利用が止まる | 可視化と通知が止まるだけ |
| 応答の遅延 | 加わる | 加わらない |
| プロンプト | 通過する | 扱わない |
| 反映の速さ | リアルタイム | 取得の間隔ぶん遅れる |
| 止める機能 | 遮断・流量制限ができる | できない（気づいて是正する） |
停止時の影響の詳細は「外部ツール停止で自社AI利用が止まるか｜介在型と非介在型」を参照してください。
非介在型の利点
1. 可用性を損なわない
可視化の仕組みが停止しても、生成AIの利用は止まりません。可視化のために、業務の単一障害点を作らずに済みます。
2. プロンプトに触れない
管理APIが返すのは利用量のメタデータで、プロンプトや応答の内容は含まれません。可視化の仕組みが機密情報を抱えることがなく、従業員のプライバシーの面でも説明しやすくなります。メタデータと原文の違いは「メタデータと原文の違い｜可視化に原文は要らない」を参照してください。
3. 導入が軽い
アプリケーションの接続先を変える必要がなく、読み取り専用の認証情報を登録するだけで始められます。社内システムの改修や、端末への常駐ソフトの配布も不要です。
4. 預ける権限が小さい
必要なのは、利用量と費用を読み取る権限だけです。モデルを呼び出す権限や管理者の権限は要りません。万一認証情報が漏れても、生成AIを不正に使われることはありません（利用量を読まれるリスクは残るため、保管と失効の手順は必要です）。
5. 過去のデータも取り込める
プロバイダが記録している範囲で、導入前の利用量もさかのぼって取り込めます。停止していた期間の利用量も、復旧後に取得し直せます。
できることとできないこと
| できること | できないこと |
|---|---|
| 部署・利用者・プロジェクト・キー別の利用量と費用の可視化 | リクエストの遮断・流量の制限 |
| 予算の消化率・日次の上限・急増の通知 | リアルタイムの制御（取得の間隔ぶん遅れる） |
| キーの棚卸し（使われていないキー、持ち主不明のキー） | プロンプトの内容の検査 |
| 実費と概算の突合、月次の報告 | 利用者個人の内訳（プロバイダがキー単位で記録していない経路） |
「止める」機能が必要な場合は、各プロバイダの利用上限の機能を最後の砦として設定し、非介在型の可視化で「気づいて是正する」運用を組み合わせるのが現実的です。どうしても流量を制御したい用途だけ、介在型を限定して使う方法もあります。
反映の遅れをどう考えるか
非介在型は、管理APIから定期的に取得するため、利用から画面への反映に取得の間隔ぶんの遅れがあります。
| 用途 | 遅れの影響 |
|---|---|
| 月次の報告・予算管理 | 影響なし |
| 日次の上限の通知 | 小さい（数十分程度の遅れ） |
| 急増・漏えいの検知 | 取得の間隔ぶん遅れて気づく。数十分〜1時間程度なら、請求書で気づくより大幅に早い |
多くの企業にとって課題は「請求書が届いてから気づく」ことです。数十分の遅れで気づけるなら、課題の大半は解決します。
導入時の確認点
| 確認点 | 内容 |
|---|---|
| 対応しているプロバイダ | 自社が使っている経路に対応しているか |
| 必要な権限 | 読み取り専用で足りるか。付ける権限の具体的な範囲 |
| 取得の間隔 | 利用量と費用を、どのくらいの間隔で取得するか |
| 見える粒度 | キー・デプロイメント・モデルのどこまで見えるか。限界を開示しているか |
| 認証情報の保管 | 暗号化の方式、画面での表示、失効の方法 |
導入の流れ
非介在型の可視化の導入は、アプリケーションに手を入れずに進められます。
| 段階 | やること | 担当 |
|---|---|---|
| 1. 経路の確認 | 会社として使っているプロバイダ・組織・アカウントを挙げる | 情シス |
| 2. 認証情報の発行 | 各プロバイダで、利用量と費用の読み取り専用の認証情報を発行する | 各経路の管理者 |
| 3. 登録 | 可視化の仕組みに認証情報を登録する。取得が始まる | 情シス |
| 4. 対応付け | 見つかったキー・デプロイメント・モデルを、部署・利用者に対応付ける | 情シスと各部署 |
| 5. 通知の設定 | 予算・日次の上限・急増の通知を設定する | 情シス |
社内システムの改修やリリースの調整が要らないため、導入の作業は情シスの中で完結します。
よくある質問
Q. 非介在型で、急な利用の増加に間に合いますか？ 取得の間隔が短ければ、請求書で気づくより大幅に早く気づけます。被害額に上限を設けたい場合は、プロバイダ側の利用上限も合わせて設定します。
Q. ゲートウェイをすでに使っています。非介在型も必要ですか？ ゲートウェイを通らない利用（別の経路、直接のAPI利用、別のクラウド）がある場合は、非介在型で全体を把握すると抜け漏れを防げます。ゲートウェイの停止中の利用量も把握できます。
まとめ
- 非介在型の可視化は、プロバイダの管理APIから利用量を定期的に読み取り、通信経路に入らない
- 可視化が止まっても生成AIの利用は止まらない。プロンプトに触れず、導入は認証情報の登録だけ
- できるのは可視化・通知・棚卸し・突合。遮断やリアルタイムの制御はできない
- 反映は取得の間隔ぶん遅れるが、請求書で気づくより大幅に早い。止める機能はプロバイダの上限と組み合わせる
ManageAIは、読み取り専用の権限で各プロバイダの管理APIから利用量を15分ごとに取得する、非介在型（プル型）の可視化サービスです。通信経路に一切介在しないため、ManageAIが停止しても貴社の生成AIの利用には影響せず、プロンプト原文も構造上取得しません。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ