組織マッピングとは｜APIキーと部署を紐づける設計の基本

組織マッピングとは、生成AIプロバイダ側にあるAPIキー・デプロイメント・プロジェクト・モデルといった技術的な単位を、自社の部署・利用者・プロジェクトに対応付けることです。プロバイダには「部署」という概念がないため、この対応付けを作らない限り、部署別の費用は出せません。

この記事では、組織マッピングがなぜ必要か、プロバイダごとに何を起点にするか、どう作ってどう維持するかを整理します。配賦全体の設計は「生成AIコストの部署別配賦（チャージバック）完全ガイド」で扱っています。

なぜ組織マッピングが要るのか

プロバイダの管理API（利用統計API）から取れるのは、次のような単位の利用量と費用です。

• OpenAI: APIキー × モデル × 時間、プロジェクト別の実費
• Azure OpenAI: デプロイメント × モデル × 時間、リソース別の実費
• Claude: APIキー × モデル × 時間、ワークスペース別の実費
• AWS Bedrock: モデル × 時間、リージョン別の実費
• Google Vertex AI: モデル × 時間、プロジェクト別の実費

どこにも「営業部」「開発1課」は出てきません。「営業部の今月の費用」を出すには、営業部が使っているキーやデプロイメントがどれかを、自社側で定義する必要があります。これが組織マッピングです。

組織マッピングがないと、部署別の集計は毎月の手作業になります。各コンソールから数字を取り、Excelでキーを部署に振り分けて按分する。プロバイダが増えるたびに転記元が増え、担当者が異動すると振り分けのロジックが失われます。

対応付けの起点はプロバイダごとに違う

組織マッピングで最初に理解すべきなのは、経路によって「何を部署に紐づけるか」が違うことです。

OpenAIとClaudeは実際のAPIキーを利用者や部署に紐づけられます。キーの名前と所有者のメールアドレスがプロバイダ側に登録されているため、対応付けの手がかりが最初からあります。

Azure・Bedrock・Vertex AIは、キーが利用者に紐づきません。この場合、リソース名やリージョン／モデルの組み合わせを「疑似キー」として扱い、同じ仕組みで部署に対応付けます。利用者個人までは追えないので、部署単位で見たいときはAWSアカウントやGCPプロジェクトを部署ごとに分けておくのが実務上の解です。

この粒度の違いは、組織マッピングを作る前に関係者へ共有しておきます。「全プロバイダで個人別に見える」と期待されたまま進めると、後で必ず食い違います。

組織マッピングの構成要素

対応付けは、次の3つの要素で構成します。

部署階層に循環（AをBの下に、BをAの下に）があると集計が壊れるため、階層は木構造に保ちます。プロジェクトは部署とは別の軸として持ち、部門横断の案件に使います。

作り方の手順

初回の組織マッピングは、次の4ステップで作ります。所要は組織の規模によりますが、「どのキーがどのチームのものか分かる人」が同席すれば、初回のヒアリングで大半が埋まります。

1. プロバイダ側の単位を全部出す

各プロバイダの管理APIから、キー・デプロイメント・モデルの一覧を機械的に取得します。手作業で各コンソールを開いて書き写すのではなく、自動で収集される状態にしておくと、後から増えたキーも自動で台帳に載ります。

2. 所有者を埋める

キー名や所有者のメールアドレス、リソース名を手がかりに、誰が発行したキーかを埋めます。名前から分からないキーは、発行時期と利用量の推移から当たりをつけ、関係者に確認します。

3. 部署・プロジェクトに対応付ける

1つのキーは1つの部署に対応付けるのが原則です。複数部署で使っている共用キーは、無理に1つの部署に付けず「共用」として按分の対象にします。開発部門はプロジェクト（プロダクト）単位も併用します。

4. 未知のキーの扱いを決める

収集で新しく見つかったキーは、自動で台帳に載せて「未割当」として扱います。未割当の費用は月次の棚卸しで所属を決めます。CSVで一括登録できる仕組みがあると、初回の投入と組織変更時の更新が楽になります。

キーの命名規則とCSV一括登録

初回の対応付けと、その後の更新を楽にする2つの実務上の工夫です。

命名規則

キーやデプロイメントの名前に、対応付けに必要な情報を最初から含めておきます。

「dev1-minutes-prod-sato」のような名前にしておけば、名前を見るだけで大半の対応付けが決まります。既存のキーは改名できないことが多いので、新規発行分から適用し、既存分は台帳で補います。

CSVで一括登録する項目

初回投入と組織変更時の更新は、CSVでまとめて行えると作業が短くなります。最低限の項目は次のとおりです。

キー識別子は末尾数桁だけを扱い、キーの全文を台帳に持たないようにします。台帳は対応付けのためのもので、認証情報の保管場所ではありません。

未割当をどう扱うか

組織マッピングを始めると、必ず「どの部署のものか分からないキー」が出てきます。典型的なものは次の3つです。

• 検証用に発行したまま忘れられたキー
• 退職者・異動者のキー
• SIerが構築時に作ったキー

未割当は隠さず、指標として追うのが運用のコツです。未割当の費用と全体に対する割合を月次で見て、増えていれば組織マッピングの更新が追いついていないサインと捉えます。用途が終わったキーはプロバイダ側で失効し、台帳からも外します。

未割当を放置すると、部署別の合計が全社の実費に届かず、「差額は誰の費用か」を毎月説明することになります。

更新の運用——組織変更に耐える設計

組織マッピングは作って終わりではありません。崩れる要因は主に3つです。

運用を回すコツは、更新のタイミングを月次レビューに固定することです。「未割当の棚卸し」を毎月の議題に入れておけば、組織変更の反映漏れも同じ場で拾えます。

キーの発行時に台帳へ登録する運用（命名規則「部署略称-用途-環境」など）を決めておくと、未割当の発生自体が減ります。

権限の設計——誰がどの部署の費用を見られるか

組織マッピングができると、部署別・利用者別の費用が見えるようになります。ここで「誰が何を見られるか」を決めておかないと、現場の反発を招きます。

• 管理者（情シス・経営企画）は全社を見られる
• 部門長は自部署を見られる（閲覧のみ）
• 利用者個人の費用を本人以外に見せるかは、評価ではなく判断材料として使うと合意した上で決める

個人別の費用は「誰かに見せる」より「異常を検知する」ための単位と考えると、権限で悩む場面が減ります。

よくある質問

Q. BedrockやVertex AIで、誰が使ったかまで知りたいのですが。 モデル単位の集計からは分かりません。AWSアカウントやGCPプロジェクトを部署（またはチーム）ごとに分けると、その単位で内訳が出せます。利用者個人まで追う必要があるなら、OpenAIやClaudeの直接利用のようにキーが個人に紐づく経路を選ぶ判断もあります。

Q. 退職者のキーはどう扱えばよいですか？ プロバイダ側で失効し、台帳では「失効」として履歴を残します。失効前の利用は元の部署に付けたまま、以後は発生しません。失効を忘れると未割当の費用として出続けるので、棚卸しの確認項目に入れておきます。

Q. 組織マッピングは誰が作るべきですか？ キーと用途を知っている情シス・開発と、組織図と予算を持つ経営企画の両方が要ります。初回は両者が同席する1時間のヒアリングで作り、以後の更新は情シスが月次の棚卸しで行う分担が現実的です。

まとめ

• 組織マッピングは、プロバイダ側の技術的な単位（キー・デプロイメント・モデル）を自社の部署・利用者・プロジェクトに対応付けること。部署別の費用を出す起点
• 対応付けの起点はプロバイダで違う。OpenAI・ClaudeはAPIキー、Azureはデプロイメント、Bedrock・Vertex AIはリージョン／プロジェクト × モデルを疑似キーとして扱う
• 作り方は「単位を全部出す → 所有者を埋める → 部署に対応付ける → 未知のキーの扱いを決める」の4ステップ
• 未割当は指標として追い、月次の棚卸しで所属を決める。更新は月次レビューに固定する

ManageAIは、5プロバイダの管理APIからキー・デプロイメント・モデルを自動で収集し、部署階層・メンバー・キー割当による組織マッピングをUIとCSV一括取込で管理します。収集で見つかった新しいキーは自動で台帳に載り、未割当の費用も隠さず表示します。導入時の組織マッピングは一緒に行い、読み取り専用キーの登録だけで当日から始められます。現在、モニター企業を募集中です。

関連記事

• 生成AIコストの部署別配賦（チャージバック）完全ガイド｜FinOpsの考え方で設計する
• 生成AIコストの配賦方法3パターン｜キー・タグ・按分
• FinOps for AI｜生成AI費用に固有の難しさと対処