メタデータと原文の違い｜可視化に原文は要らない
生成AIの利用データにおける「メタデータ」と「原文」の違いを解説します。メタデータに含まれる項目（トークン数・モデル・時刻・キー）と原文（プロンプトと応答）の違い、メタデータで分かること・分からないこと、費用管理や利用状況の把握に原文が要らない理由、原文を扱う場合の注意点を整理しました。
生成AIの利用データには、メタデータ（トークン数・モデル・時刻・APIキーなど、利用の「量と属性」）と、原文（プロンプトと応答の「中身」）の2種類があります。費用の管理、予算の統制、部署別の利用状況の把握、APIキーの管理は、すべてメタデータで行えます。原文が必要になるのは、入力内容のルール違反の検知や、回答の品質の評価など、中身そのものを見る目的に限られます。
この記事では、メタデータと原文の違い、メタデータで分かること・分からないこと、可視化に原文が要らない理由を説明します。全体像は「生成AI導入のセキュリティ 完全ガイド」を参照してください。
メタデータと原文の違い
| メタデータ | 原文 | |
|---|---|---|
| 中身 | 利用の量と属性 | 入力した文章と、返ってきた文章 |
| 項目の例 | 入力・出力・キャッシュのトークン数、リクエスト数、モデル名、APIキーの識別子、時刻、費用 | プロンプト、応答、添付ファイル、会話の履歴 |
| 取得元 | プロバイダの管理API（利用統計の API）、クラウドのメトリクス | 通信経路（ゲートウェイ・プロキシ）、アプリケーションのログ、呼び出しログ |
| 機密情報を含むか | 原則として含まない | 社員が入力した内容によっては含む |
| 漏えい時の影響 | 利用量が知られる | 入力した機密情報が漏れる |
メタデータは「いつ・誰が（どのキーで）・どのモデルを・どれだけ使ったか」を表し、原文は「何を入力し、何が返ってきたか」を表します。
メタデータにも注意が必要な項目
メタデータにも、扱いに注意が必要な項目があります。
| 項目 | 注意点 |
|---|---|
| APIキーの名前 | 利用者の氏名やシステム名が入っていることがある |
| キーの持ち主のメールアドレス | プロバイダに登録されている場合、個人を特定できる |
| プロジェクト名・ワークスペース名 | 未発表の案件名が入っていることがある |
これらは原文に比べれば影響は小さいものの、閲覧できる人の範囲を決めて扱う必要があります。
メタデータで分かること
| 分かること | 使うメタデータ |
|---|---|
| 部署別・利用者別の利用量と費用 | キーごとのトークン数 × 単価、キーと部署の対応 |
| 予算の消化状況 | 日次・時間ごとの費用の累計 |
| 利用の急な増加 | キーごとの時間単位のトークン数の推移 |
| 使われていないキー | キーごとの利用の有無 |
| モデルの使い分け | モデルごとのトークン数の構成比 |
| 利用の時間帯の傾向 | 時間ごとのリクエスト数・トークン数 |
| 会社の経路が使われていない部署 | 部署別の利用量 |
費用の管理とガバナンスに必要な情報の大半は、メタデータだけで揃います。
メタデータでは分からないこと
| 分からないこと | 補う方法 |
|---|---|
| 何の業務に使ったか（用途） | 利用者への聞き取り、キーを用途ごとに分ける設計 |
| 入力ルールが守られているか | 教育と報告。必要なら対象を限定して原文を確認する |
| 回答の品質 | 利用者の評価、対象を限定したレビュー |
「何に使ったか」は、キーを用途（システム・業務）ごとに分けておくと、メタデータからでもある程度分かります。キーの設計を工夫すると、原文を見ずに分かる範囲が広がります。
可視化に原文が要らない理由
1. 目的に対して十分
費用の管理・予算の統制・キーの管理・利用状況の把握は、どれもメタデータで達成できます。目的に必要のないデータを集めないことは、データ保護の基本的な考え方です。
2. リスクを増やさない
原文を集めると、社員が入力した機密情報が、可視化の仕組みの中にも保存されます。可視化のために入れた仕組みが、新しい漏えいの経路になることを避けられます。
3. 導入と審査が軽くなる
原文を扱わないツールは、セキュリティ審査で確認すべき範囲が小さく、従業員への説明もしやすくなります。
4. 通信経路に入らずに取得できる
メタデータは、プロバイダの管理APIから定期的に読み取れます。通信経路に入る必要がないため、可視化の仕組みが止まっても、生成AIの利用は止まりません。
原文を扱う場合の注意点
目的によって原文が必要な場合は、次の点に注意します。
| 注意点 | 内容 |
|---|---|
| 対象を限定する | 全社・全期間ではなく、必要な業務・期間に限る |
| 保存の範囲と期間 | 保存する場所・期間・削除の手順を決める |
| 閲覧できる人 | 必要最小限の人に限り、閲覧を記録する |
| 従業員への説明 | 何を、何のために、誰が見るかを事前に説明する |
| 規程との整合 | 顧客との契約や個人情報の取り扱いの規程に反しないかを確認する |
メタデータの具体例
プロバイダの管理APIから取得できるメタデータは、たとえば次のような形です（値は説明のための例）。
| 時刻（UTC） | キー | モデル | 入力トークン | キャッシュ入力 | 出力トークン | リクエスト数 |
|---|---|---|---|---|---|---|
| 2026-09-28 01:00 | 営業部・議事録ツール | モデルA | 182,400 | 40,100 | 36,900 | 212 |
| 2026-09-28 01:00 | 開発部・コードレビュー | モデルB | 520,300 | 0 | 88,700 | 95 |
| 2026-09-28 02:00 | 営業部・議事録ツール | モデルA | 175,800 | 38,600 | 35,200 | 204 |
この表から、どの部署のどのツールが、どの時間帯に、どれだけ使ったかが分かります。単価を掛ければ費用の概算になり、部署ごとに集計すれば部署別の費用になります。一方で、議事録にどんな会話が書かれていたか、コードに何が含まれていたかは、この表のどこにも出てきません。
メタデータの保護
メタデータは原文に比べて影響は小さいものの、次のように保護します。
| 対策 | 内容 |
|---|---|
| 閲覧権限 | 全社の数字は情シスと経営、部署の数字は部門長など、役割で分ける |
| 個人を特定できる項目 | キー名や持ち主のメールアドレスは、必要な人だけが見られるようにする |
| 保存の場所 | 国内のリージョンで管理するなど、規程に合わせる |
| 通信と保存の暗号化 | 他の業務データと同じ水準で暗号化する |
よくある質問
Q. プロバイダの管理APIは、本当に原文を返さないのですか？ 利用量や費用を返す管理API（利用統計の API）は、集計値を返すもので、プロンプトや応答の内容は含みません。原文は、通信経路を通るリクエストや、アプリケーション・クラウドの呼び出しログに含まれます。
Q. 用途（何に使ったか）を知りたい場合は？ まず、キーを用途ごとに分ける設計で対応します。より細かく知りたい場合は、原文を外部に出さずに用途を把握する方法を検討します。原文を外部のツールに送って分析する方法は、リスクが大きくなります。
Q. メタデータから、入力した内容を推測されることはありませんか？ トークン数や時刻から、入力の中身を復元することはできません。推測できるのは、どのツールを、いつ、どれだけ使ったかまでです。ただし、キー名やプロジェクト名に案件名などが含まれていると情報が伝わるため、名前の付け方に注意します。
まとめ
- 生成AIの利用データは、量と属性を表すメタデータと、中身を表す原文に分かれる
- 費用管理・予算統制・部署別の利用状況・キー管理は、メタデータだけで達成できる
- メタデータで分からない「用途」は、キーを用途ごとに分ける設計で補える
- 可視化に原文を使わないことは、リスクを増やさず、審査と説明を軽くし、通信経路にも入らずに済む
ManageAIが取得するのは、トークン数・リクエスト数・モデル名・APIキーの識別子・時刻・費用などの利用量のメタデータです。プロンプトと生成結果の原文は、取得も保存も送信も行いません。原文を扱う仕組みがサービス内に存在しない、構造上の制約です。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円（税別）
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ