ストーリー
田
田中VPoE
「データの評価ができたら、次は技術の選択だ。『AI』と一口に言っても、生成AI、従来型ML、RPA、ルールベースとさまざまな選択肢がある。」
あなた
「それぞれの得意分野が違うんですね。」
あ
田
田中VPoE
「その通り。業務の特性に合った技術を選ばないと、コストばかりかかって効果が出ない。適材適所の技術選択を学ぼう。」
あなた
「NetShop社の各業務に最適な技術を選べるようになりたいです。」
あ
田
田中VPoE
「技術の特徴を理解すれば、正しい判断ができる。一つずつ見ていこう。」
4つの技術カテゴリ
比較一覧
| 項目 | 生成AI（LLM） | 従来型ML | RPA | ルールベース |
|---|---|---|---|---|
| 得意なこと | テキスト生成・理解、柔軟な対応 | パターン認識・予測・分類 | 定型的なUI操作の自動化 | 明確なルールに基づく処理 |
| 苦手なこと | 数値計算、100%の正確性 | 自然言語の柔軟な理解 | 非定型な操作 | 曖昧なケースの判断 |
| 必要データ | 少量（プロンプト設計）〜中量（RAG） | 大量の教師データ | 不要 | 不要 |
| 導入コスト | 中（API利用料） | 高（モデル開発） | 低〜中 | 低 |
| 運用コスト | API利用量に比例 | モデル再学習コスト | ライセンス費用 | 保守コスト |
| 導入スピード | 速い（数週間） | 遅い（数ヶ月） | 中程度 | 速い |
生成AI（LLM）の適用領域
適している業務
| 業務タイプ | 具体例 | 理由 |
|---|---|---|
| テキスト生成 | 商品説明文、メール文面、レポート | 自然な文章を高速に生成 |
| テキスト理解・分類 | 問い合わせ分類、感情分析、要約 | 文脈を理解した判断が可能 |
| 対話 | チャットボット、FAQ応答 | 自然な会話が可能 |
| 情報検索（RAG） | ナレッジベース検索、社内FAQ | 文書を理解した上で回答 |
| コード生成 | プログラム作成、SQL生成 | 指示からコードを生成 |
注意点
| リスク | 説明 | 対策 |
|---|---|---|
| ハルシネーション | 事実と異なる情報を生成する | RAGで根拠データを提供、人間のレビュー |
| API依存 | 外部APIに依存するため停止リスク | フォールバック設計、複数プロバイダ |
| コスト増加 | 利用量に応じてコストが増加 | キャッシュ、モデル選択の最適化 |
| 個人情報漏洩 | 外部APIにデータを送信 | DLP対策、プライベートデプロイ |
従来型ML（機械学習）の適用領域
適している業務
| 業務タイプ | 具体例 | 理由 |
|---|---|---|
| 予測 | 需要予測、売上予測、解約予測 | 過去データからパターンを学習 |
| 分類 | 不正検知、画像分類、スパム判定 | 大量データからの分類精度が高い |
| 異常検知 | 不正注文検知、設備異常検知 | 正常パターンからの逸脱を検出 |
| レコメンド | 商品推薦、コンテンツ推薦 | 行動履歴からの嗜好学習 |
| 最適化 | 価格最適化、配送ルート最適化 | 複数変数の最適組み合わせ |
注意点
| リスク | 説明 | 対策 |
|---|---|---|
| データ依存 | 学習データの偏りが結果に影響 | データの多様性確保、バイアス評価 |
| モデル劣化 | 時間経過で精度が低下 | 定期的な再学習、モニタリング |
| 開発期間 | モデル開発に数ヶ月かかる | MVP（最小モデル）から段階的に |
| 説明可能性 | ブラックボックスになりがち | 説明可能なモデルの選択 |
RPA（Robotic Process Automation）の適用領域
適している業務
| 業務タイプ | 具体例 | 理由 |
|---|---|---|
| データ転記 | システム間のコピー＆ペースト | UI操作の忠実な再現 |
| 帳票処理 | 請求書データの入力 | 定型フォーマットの処理 |
| レポート配信 | 定期レポートのダウンロードと配信 | スケジュール実行が容易 |
| ファイル操作 | ファイルの移動、リネーム、変換 | 単純な操作の自動化 |
注意点
| リスク | 説明 | 対策 |
|---|---|---|
| UI変更への脆弱性 | 画面変更でロボットが停止 | API連携への移行検討 |
| スケールの難しさ | 業務変更のたびに修正が必要 | 変更管理プロセスの整備 |
| 限定的な判断力 | 例外的なケースに対応できない | AI連携（Intelligent Automation） |
ルールベースの適用領域
適している業務
| 業務タイプ | 具体例 | 理由 |
|---|---|---|
| 条件分岐 | 注文金額による承認ルート振り分け | IF-THENで表現可能 |
| バリデーション | 入力データの整合性チェック | 明確な基準で判定可能 |
| 通知 | ステータス変更時の自動通知 | トリガー条件が明確 |
| 計算 | 割引率の自動計算 | 計算式が定義済み |
NetShop社への技術フィット評価
| 業務 | 最適技術 | 理由 | 代替技術 |
|---|---|---|---|
| FAQ自動回答 | 生成AI（RAG） | 多様な質問に柔軟に対応 | ルールベース（初期版） |
| 商品説明文作成 | 生成AI | 自然な文章の生成が得意 | - |
| 需要予測 | 従来型ML | 過去データからのパターン学習 | 統計的手法（初期版） |
| 不正注文検知 | 従来型ML | 異常パターンの学習 | ルールベース（初期版） |
| 商品情報更新 | RPA | システム間のデータ転記 | API連携 |
| 注文ステータス通知 | ルールベース | トリガー条件が明確 | - |
| レビュー検出 | 生成AI + ML | テキスト理解＋分類 | キーワードフィルタ |
| 出荷検品 | 画像認識AI | 画像による判定 | バーコード検品（既存） |
ハイブリッドアプローチ
実際のプロジェクトでは、単一技術ではなく複数技術を組み合わせるケースが多い。
ハイブリッド例: CS問い合わせ対応
├── ルールベース: 問い合わせの初期分類
├── 生成AI（RAG）: FAQ回答の自動生成
├── 従来型ML: 問い合わせの感情分析
└── RPA: 対応結果のシステム登録まとめ
| 項目 | ポイント |
|---|---|
| 4つの技術 | 生成AI、従来型ML、RPA、ルールベースの使い分け |
| 選択基準 | 業務の特性（テキスト/数値/UI操作/条件分岐）で判断 |
| 段階的導入 | 簡単な技術から始めて段階的に高度化 |
| ハイブリッド | 複数技術の組み合わせが現実的な解 |
| 技術ロックイン回避 | 特定技術に依存しない設計が重要 |
チェックリスト
- 4つの技術カテゴリの特徴を説明できる
- 業務特性に応じた技術選択ができる
- 各技術のリスクと対策を理解した
- ハイブリッドアプローチの考え方を把握した
次のステップへ
次は「リスクアセスメント」として、AI導入に伴う技術リスク、業務リスク、倫理リスク、法規制リスクを評価する方法を学ぼう。
推定読了時間: 30分