生成AIの用途分類の作り方|業務カテゴリの設計
生成AIの利用を「何のために使ったか」で整理するための用途分類(業務カテゴリ)の作り方を解説します。分類の目的の決め方、2階層で作る設計、カテゴリの例、分類の粒度の決め方、よくある失敗、分類を運用して見直す方法、用途分類を費用や効果の分析に使う方法までをまとめました。

生成AIの用途分類は、目的を決めてから、大分類(作業の種類)と中分類(業務)の2階層で作ると、集計にも改善にも使える形になります。大分類は「文章の作成」「要約」「調べもの」など、どの部署にも共通する作業の種類で揃え、中分類は「議事録」「提案書」「社内の問い合わせ回答」など、自社の業務に合わせて定義します。
分類は、一度作って終わりではありません。「その他」が増えたら分類を見直し、目的に使える形を保ちます。この記事では、分類の目的の決め方、2階層の設計、カテゴリの例、粒度の決め方、運用の方法を説明します。用途を把握する方法は「社員は生成AIを何に使っているのか|用途を把握する3つの方法」、全体像は「生成AIの利用実態と用途を把握する 完全ガイド」を参照してください。
分類の目的を先に決める
| 目的 | 必要な分類 |
|---|---|
| 経営への報告 | 大まかな作業の種類(5〜8個程度) |
| 効果の測定 | 効果を測る業務単位(議事録・提案書など) |
| 横展開 | 部署をまたいで比べられる業務単位 |
| モデルの選び方の見直し | 求められる性能で分かれる単位(要約・分類/推論・分析) |
| ガイドラインの整備 | リスクの違いで分かれる単位(社内向け/社外向け) |
目的が決まらないまま分類を作ると、細かすぎて使われないか、粗すぎて判断に使えない分類になります。最初は経営への報告と効果の測定を目的にし、必要に応じて広げるのが現実的です。
2階層で設計する
| 階層 | 内容 | 決め方 |
|---|---|---|
| 大分類 | 作業の種類 | 全社共通。5〜8個程度 |
| 中分類 | 業務 | 部署・業務に合わせて定義。大分類ごとに数個 |
大分類の例
| 大分類 | 内容 |
|---|---|
| 文章の作成 | メール・資料・報告書などの下書き |
| 要約 | 会議・文書・問い合わせ内容の要約 |
| 翻訳 | 他言語との翻訳 |
| 調べもの・質問 | 情報の調査、知識の確認 |
| 企画・アイデア出し | 案の作成、壁打ち |
| データの整理・分析 | 表の整形、集計、分析 |
| プログラム | コードの作成・レビュー・修正 |
| その他 | どれにも当てはまらないもの |
中分類の例
| 大分類 | 中分類の例 |
|---|---|
| 文章の作成 | 社外メール、提案書、社内報告、求人票 |
| 要約 | 議事録、契約書の要点、問い合わせの要約 |
| 調べもの・質問 | 社内規程の確認、技術的な調査、市場の調査 |
| プログラム | 新規の作成、レビュー、テストの作成 |
大分類を全社で揃えておくと、部署をまたいだ比較と、経営への報告がしやすくなります。中分類は部署ごとに違ってかまいません。ただし、同じ業務を部署ごとに別の名前で呼んでいると比較できなくなるため、よく使われる中分類(議事録・提案書など)は名前を揃えておきます。
粒度の決め方
| 粒度 | 長所 | 短所 |
|---|---|---|
| 粗い(大分類のみ) | 分類しやすい。報告に使いやすい | 改善や横展開の判断には使いにくい |
| 細かい(業務の単位) | 効果の測定・横展開に使える | 分類の手間が増える。分類が揺れる |
目安は、「その分類ごとに、何かを判断するか」です。判断に使わない細かい分類は、作っても手間が増えるだけです。たとえば、効果を測る業務だけを中分類にし、それ以外は大分類に留める、という作り方もできます。
分類を運用する
| 運用 | 内容 |
|---|---|
| 分類の定義を文書にする | 各カテゴリの説明と、迷いやすい例の振り分けを書く |
| 分類の単位を決める | キー・業務ツールの機能・アンケートの回答など、何に分類を付けるか |
| 「その他」を監視する | 「その他」が一定の割合を超えたら、新しいカテゴリを検討する |
| 定期的に見直す | 半年〜1年ごとに、目的に使えているかを見直す |
分類を付ける単位
| 単位 | 付け方 |
|---|---|
| APIキー・業務ツール | キーの台帳に、用途の大分類・中分類を記録する |
| 業務システムの機能 | 「要約」「翻訳」などのボタンに分類を対応付ける |
| アンケートの回答 | 選択肢を大分類に揃える |
分類を付ける単位を決めておくと、利用量のデータと用途を結び付けられます。キーの台帳に用途の分類を持たせておけば、キー別の費用を用途別に集計できます。
分類の定義書の例
分類を運用するときは、次のような定義書を作り、迷ったときに参照できるようにします。
| 大分類 | 定義 | 含むもの | 含まないもの(振り分け先) |
|---|---|---|---|
| 要約 | 既存の文章・会話を短くまとめる | 議事録、長い文書の要点、問い合わせ内容のまとめ | 要約をもとに新しい文章を作る(→文章の作成) |
| 文章の作成 | 新しい文章の下書きを作る | メール、提案書、報告書 | 他言語への変換(→翻訳) |
| 調べもの・質問 | 情報や知識を得る | 社内規程の確認、技術の調査 | 得た情報をまとめて資料にする(→文章の作成) |
「含まないもの」と振り分け先を書いておくと、担当者によって分類が揺れにくくなります。
部署ごとの中分類の作り方
- 部署の窓口に、生成AIを使っている業務を挙げてもらう
- 挙がった業務を大分類に振り分ける
- 効果を測りたい業務・費用の大きい業務だけを中分類にする
- 残りは大分類のみで扱う
- 半年後に、中分類の追加・統合を見直す
用途分類を費用と効果の分析に使う
| 分析 | 見ること |
|---|---|
| 用途別の費用 | どの用途に費用が集まっているか |
| 用途別の効果 | どの用途で時間の削減や品質の向上が出ているか |
| 用途とモデル | 簡単な用途(要約・分類)で高性能なモデルを使っていないか |
| 部署と用途 | 同じ用途で部署ごとに費用や効果に差がないか |
用途別の費用と効果を並べると、「費用が大きいのに効果が小さい用途」「費用は小さいのに効果が大きい用途」が分かり、投資と見直しの判断に使えます。
よくある失敗
| 失敗 | 回避策 |
|---|---|
| 分類を細かく作りすぎる | 判断に使う単位だけを細かくする |
| 分類の定義があいまい | 迷いやすい例の振り分けを文書にする |
| 「その他」が大半になる | 「その他」の中身を見て、カテゴリを足す |
| 部署ごとに大分類が違う | 大分類は全社で揃え、中分類だけ部署に任せる |
| 作ったまま見直さない | 半年〜1年ごとに見直す |
よくある質問
Q. 分類の数はいくつが適切ですか? 大分類は5〜8個程度、中分類は判断に使う業務だけに絞るのが目安です。数が多すぎると分類が揺れ、集計の意味が薄れます。
Q. 汎用のチャットの利用は、どう分類しますか? 汎用のチャットは、キーや機能で用途を分けられないため、アンケートで大分類ごとの割合を聞いて補うのが一般的です。用途が決まってきた使い方は、専用の業務ツールに切り出してキーを分けると、継続的に測れるようになります。
まとめ
- 用途分類は、目的を決めてから、大分類(作業の種類)と中分類(業務)の2階層で作る
- 大分類は全社で揃え、中分類は判断に使う業務だけを部署に合わせて定義する
- 分類を付ける単位(キー・業務システムの機能・アンケート)を決め、利用量のデータと結び付ける
- 「その他」を監視し、定義の文書と定期的な見直しで、使える分類を保つ
ManageAIは、APIキー・部署・利用者別の費用を可視化し、キーの台帳に用途を対応付ければ用途別の費用も確認できます。また、プロンプト原文を貴社環境の外に一切出さずに、用途別の利用状況を統計として可視化する機能を提供予定です(特許出願中)。モニター企業を募集中です。
関連記事
次に読む
この記事を書いた人
モニター企業募集
初期費用0円・月額5万円(税別)
先着5社・2026年11月末まで
5プロバイダの利用量と費用を部署・利用者・APIキー別に可視化。読み取り専用キーの登録だけで当日から始められます。
募集要項を見る資料請求・お問い合わせ