介在型と非介在型の可視化ツール｜違いと選び方
生成AIの可視化・コスト管理ツールを、通信経路に入る「介在型」と入らない「非介在型」に分けて、目的別の選び方を解説します。機能・導入・運用・リスクの比較、目的から方式を選ぶ判断表、両方を組み合わせる構成のパターン、介在型から非介在型へ（またはその逆へ）移る場合の注意点をまとめました。
生成AIの可視化・コスト管理ツールは、通信経路に入る「介在型」（ゲートウェイ・プロキシ）と、入らない「非介在型」（プロバイダの管理APIを読む方式）に分けられます。選び方の軸は、目的が「見る・気づく」なのか、「止める・変える・検査する」なのかです。前者なら非介在型、後者なら介在型が必要で、両方が必要なら組み合わせます。
この記事では、2つの方式の比較、目的から方式を選ぶ判断表、組み合わせの構成を説明します。全体像は「生成AI・LLMのコスト管理ツール比較 完全ガイド」を参照してください。
2つの方式の比較
| 観点 | 介在型（ゲートウェイ・プロキシ） | 非介在型（管理APIの読み取り） |
|---|---|---|
| データの取り方 | 通過するリクエストを記録する | プロバイダが記録した利用量を読む |
| 見える範囲 | ゲートウェイを通る利用だけ | 登録した組織・アカウントのすべての利用 |
| 見える粒度 | リクエスト単位（利用者・アプリを識別できる） | プロバイダの粒度（キー・デプロイメント・モデル） |
| 実費 | 別途、請求データで確認が必要 | 管理APIから実費も取得できる |
| 止める・変える | できる（流量制限・遮断・振り分け） | できない |
| 内容の検査 | できる | できない（原文を扱わない） |
| 反映の速さ | リアルタイム | 取得の間隔ぶん遅れる |
| 導入 | 各アプリケーションの接続先を変える | 読み取り専用の認証情報を登録する |
| 停止時の影響 | 生成AIの利用が止まる | 可視化と通知が止まるだけ |
| プロンプトの扱い | 通過する（記録するかは設定次第） | 扱わない |
目的から方式を選ぶ
| 目的 | 介在型 | 非介在型 |
|---|---|---|
| 部署別・プロジェクト別の費用の把握 | △（通る利用だけ） | ◎ |
| 請求と一致する実費での報告 | △（別途確認が必要） | ◎ |
| 予算の消化率・急増の通知 | ○ | ◎ |
| 複数プロバイダの横断での把握 | △（通る利用だけ） | ◎ |
| APIキーの棚卸し | △ | ◎ |
| 利用者ごとの上限の強制 | ◎ | × |
| 入力内容の検査 | ◎ | × |
| モデル・プロバイダの切り替え | ◎ | × |
| 利用者個人単位の把握（全経路） | ○（通る利用は識別できる） | △（キー単位で記録する経路のみ） |
費用の管理が主な目的なら非介在型が向いています。すべての経路の利用を、請求と一致する実費とあわせて把握できるためです。介在型は、止める・変える・検査するといった制御が主な目的の場合に選びます。
組み合わせの構成パターン
パターン1: 非介在型だけ
| 構成 | 向いている企業 |
|---|---|
| 全社の利用を管理APIから可視化し、予算・急増で通知。被害額の上限はプロバイダ側の上限機能で設定 | 目的が費用の管理とガバナンス。制御の強い要件がない |
最も導入と運用が軽い構成です。多くの中堅企業はここから始められます。制御の要件が後から出てきた場合も、その用途だけにゲートウェイを足す形で、パターン3へ無理なく移れます。
パターン2: 介在型だけ
| 構成 | 向いている企業 |
|---|---|
| すべての利用をゲートウェイに集め、記録・制御・検査を一元化 | 利用を一つの基盤に集約でき、ゲートウェイの冗長化と運用の体制がある |
ゲートウェイを通らない利用が出ないように統制できることが前提です。実費の突合は別に行います。
パターン3: 組み合わせ
| 構成 | 向いている企業 |
|---|---|
| 制御や検査が必要なアプリケーションだけゲートウェイを通し、全社の費用と利用状況は非介在型で可視化 | 一部に制御の要件があるが、全社をゲートウェイに集めるのは避けたい |
組み合わせると、ゲートウェイの停止の影響を一部の用途に限定しつつ、全体の費用はゲートウェイの外から把握できます。ゲートウェイを通らない利用や、ゲートウェイの停止中の利用も、非介在型の可視化で抜け漏れなく見られます。
選ぶときの判断の流れ
- 目的を書き出す: 見る・気づく／止める・変える・検査する
- 「止める・検査する」の要件が本当にあるかを確認する: 規程で求められているか、プロバイダ側の上限機能で代替できないか
- 要件がなければ非介在型を選ぶ
- 要件があれば、対象の用途を限定して介在型を検討する
- 介在型を入れる場合も、全体の把握と実費の突合に非介在型を併用するかを検討する
方式を移るときの注意点
| 移り方 | 注意点 |
|---|---|
| 介在型 → 非介在型 | 利用者・アプリ単位の識別がキー単位になる。キーを利用者・アプリごとに分ける設計に見直す |
| 非介在型 → 介在型（追加） | 各アプリケーションの接続先の変更、ゲートウェイの冗長化、原文の扱いの審査が必要 |
| どちらの場合も | 部署への対応付け（組織マッピング）と過去のデータの扱いを決めておく |
構成パターンごとの運用の違い
| 運用の作業 | 非介在型だけ | 介在型だけ | 組み合わせ |
|---|---|---|---|
| 新しいアプリの追加 | 作業なし（キーの対応付けのみ） | 接続先の変更が必要 | 制御が要るアプリだけ接続 |
| 利用の増加への対応 | 作業なし | ゲートウェイの拡張 | ゲートウェイは対象のアプリ分だけ |
| 停止時の対応 | 通知が止まるだけ | 迂回の手順を実行 | 対象のアプリだけ迂回 |
| 実費の突合 | ツールで実施 | 請求データで別途実施 | 非介在型のツールで実施 |
| 原文の管理 | 不要 | 記録するなら必要 | 対象のアプリ分だけ |
組み合わせの構成は、ゲートウェイの運用の範囲を、本当に制御が必要なアプリに限定できるのが利点です。
よくある質問
Q. 介在型のほうが細かく見えるなら、介在型を選ぶべきでは？ 介在型はゲートウェイを通る利用をリクエスト単位で見られますが、通らない利用は見えません。また、停止時の影響とプロンプトの集中というリスクを伴います。費用の管理が目的なら、非介在型でキーを利用者・用途ごとに分ける設計のほうが、リスクを増やさずに必要な粒度を得られることが多いです。
Q. 非介在型で、利用者ごとの上限を設けることはできますか？ 上限を強制する（超えたら止める）ことはできません。利用者やキーごとに消化の状況を見て、超えそうなときに通知し、是正を促す運用になります。
Q. どちらの方式でも、部署への対応付けは必要ですか？ 必要です。介在型ならアプリケーションや利用者を、非介在型ならキー・デプロイメント・アカウントを、部署に対応付けて初めて部署別の集計ができます。対応付けの設計は「組織マッピングとは」を参照してください。
Q. 介在型を入れた後で、非介在型を追加する意味はありますか？ あります。ゲートウェイを通らない利用、ゲートウェイの停止中の利用、請求と一致する実費を把握できるため、全体の費用の抜け漏れを防げます。
まとめ
- 可視化ツールは、通信経路に入る介在型と、入らない非介在型に分かれる
- 費用の把握・実費での報告・横断での把握・キーの棚卸しは非介在型、上限の強制・内容の検査・切り替えは介在型が向く
- 構成は、非介在型だけ・介在型だけ・組み合わせの3パターン。組み合わせでゲートウェイの影響を一部に限定できる
- まず「止める・検査する」の要件が本当にあるかを確認し、なければ非介在型を選ぶ
ManageAIは、非介在型の可視化サービスです。5プロバイダの管理APIから利用量と実費を取得し、部署・利用者・プロジェクト・APIキー別に可視化して、予算と急増で通知します。ゲートウェイと組み合わせる場合も、ゲートウェイの外から全体の費用を把握できます。モニター企業を募集中です。
関連記事
- 生成AI・LLMのコスト管理ツール比較 完全ガイド｜ゲートウェイ・可視化・FinOps
- AIゲートウェイのメリット・デメリット｜統制と可用性のトレード
- 管理API連携型の可視化ツールとは｜導入が軽い理由
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ