社内の業務システムに「AI機能を入れたい」という要望が来たとき、まず迷うのが「どのAIを使うか」という手前の設計判断です。
スパム検知のような分類タスクに使う従来型AIと、文章やコードを新規に作り出す生成AI（Generative AI、学習したパターンから新しいコンテンツを生成する技術）は、見た目は似ていても仕組みも運用コストも別物です。この記事では、開発タスクを前にしたときにどちらを選ぶべきか、判断軸ごとに整理します。
AIと生成AIは何が違うのか
AI（人工知能）は、本来人間の知能が必要とされるタスクをコンピュータに行わせる技術分野全体を指す、かなり広い言葉です。
具体的には、メールのスパム判定、YouTubeやNetflixのレコメンド、不正送金の検知、画像内の物体認識などが含まれます。これらはすべて「入力を分類する」「次に起きることを予測する」タスクで、出力はラベルやスコア、アクションです。
生成AIはこのAIという大きな分野の中の一部分（サブセット）です。ChatGPTやGeminiのようなモデルが該当し、テキスト・画像・音声・動画・コードといった「新しいコンテンツ」を出力する点が最大の違いです。
つまり「すべての生成AIはAIだが、すべてのAIが生成AIというわけではない」という関係になります。これはAPI選定やライブラリ選定の際にまず押さえておきたい前提です。
判断軸1: 出力の種類が分類かコンテンツ生成か
最初に確認すべきは、解決したいタスクの出力が「既存の選択肢から1つを選ぶ」ものか、「ゼロから何かを作る」ものかです。
たとえば問い合わせメールを「緊急/通常/スパム」に振り分けるタスクなら、出力は固定されたラベルです。これは分類問題であり、軽量な機械学習モデルで十分対応できます。
一方、問い合わせ内容から返信文のドラフトを作る、エラーログを要約する、コードのdocstringを自動生成する、といったタスクは出力が毎回変わる自由形式のコンテンツです。これは生成AIの領域になります。
判断軸2: レイテンシとコストの許容度
分類系の軽量モデルは推論が速く、1リクエストあたりのコストも小さく抑えられます。リアルタイム性が求められる不正検知やレコメンドには向いています。
対して生成AIのAPI呼び出しは、プロンプト（モデルへの指示文）の長さやモデルサイズによってレイテンシもコストも変動します。たとえばコードレビューの自動コメント生成を全PRに対してリアルタイムで走らせる場合、トークン課金の積み上がりを事前に試算しておく必要があります。
判断軸3: 出力の検証コストを誰がどう負うか
生成AIが作るコードや文章は、常に正しいとは限りません。生成されたPythonの関数も、実行して結果を確認する検証ステップが前提になります。
分類モデルの出力は「正解率」という単一の指標で精度を評価しやすいのに対し、生成AIの出力は「妥当かどうか」を人間かテストコードがレビューする工程が追加で必要です。CI/CDパイプラインにAIコード生成を組み込むなら、生成結果に対する自動テストの通過を必須条件にする設計が現実的です。
判断軸4: チームの運用体制とMCP連携の可否
生成AIをエディタやCIに組み込む場合、MCP（Model Context Protocol、AIモデルと外部ツール・データソースを接続する標準プロトコル）対応のツールかどうかも選定材料になります。
MCP対応のAIコーディングツールであれば、社内のIssueトラッカーやドキュメントリポジトリに直接アクセスさせ、コンテキストを踏まえたコード生成や説明文の自動作成が可能です。分類タスク用の軽量モデルにはこうした連携の概念自体が存在しないため、ワークフロー自動化をどこまで広げたいかが分かれ目になります。
| 観点 | 従来型AI（分類・予測） | 生成AI |
|---|---|---|
| 出力 | ラベル・スコア・アクション | テキスト・画像・コードなど新規コンテンツ |
| 代表例 | スパム検知、不正検知、レコメンド | ChatGPT、コーディングアシスタント、画像生成 |
| 検証の負荷 | 正解率などの指標で評価しやすい | 人間またはテストによるレビューが前提 |
| 連携の広がり | 固定的なパイプラインに組み込みやすい | MCP等で外部ツールと連携し自動化しやすい |
ケース別の推奨
- 問い合わせの緊急度振り分け、異常検知、画像のラベリングなど出力が固定の選択肢なら、分類系の軽量モデルを選びます
- PRの説明文生成、ドキュメントのドラフト作成、コードの叩き台生成など出力が自由形式ならAIコーディングアシスタントの導入を検討します
- 社内ドキュメントやチケット管理ツールと連携させたいなら、MCP対応のツールを優先して比較します
- リアルタイム性が最優先で、トークン課金の変動リスクを避けたいなら、まず分類モデルで代替できないか検討します
あえて見送るべき条件
出力の正しさが即座に業務影響を与える領域（会計処理の自動確定、医療判断の最終決定など）に、検証プロセスなしで生成AIの出力をそのまま流し込むのは避けたい選択です。
また、チームにコードレビューやテスト整備の余力がない状態で生成AIによるコード生成を大量導入すると、検証されないコードが積み上がるリスクがあります。導入前にCIでのテストカバレッジがどの程度あるか確認しておくと安全です。
社内ツールがMCPのような連携プロトコルに対応していない場合、無理に生成AIの自動化範囲を広げるより、まずAPI連携の設計からやり直す方が遠回りになりません。
導入前に確認したいこと
分類AIと生成AIはどちらが優れているかという話ではなく、タスクの性質に応じて使い分けるものです。
- 出力が固定ラベルか自由形式のコンテンツかをまず切り分ける
- 生成AIを使うなら検証ステップ（テスト・レビュー）をワークフローに組み込む
- MCP対応ツールの導入余地があるかを社内の既存ツール群と照らして確認する
- コストとレイテンシの試算を小規模なPoCで先に取っておく
まずは対象タスクの出力形式を紙に書き出し、分類か生成かを仕分けるところから始めてみてください。