CONTENT
ここから
0. この授業でやること
生成AIというと、
- 文章を書く
- 質問に答える
- 要約する
- アイデアを考える
といった用途を思い浮かべることが多いと思います。
しかし、実際のビジネスでは、
「文章を書いてほしい」のではなく
「これはAなのかBなのか判断してほしい」
という仕事が大量にあります。
例えば、
問い合わせ
↓
営業？
サポート？
クレーム？
請求？
その他？
これもAIの仕事です。
さらに、
問い合わせ
↓
緊急度は高い？
↓
重要顧客？
↓
技術トラブル？
↓
人間による確認が必要？
↓
担当部署へ振り分け
という使い方もできます。
この授業では、このようなAIを
Decision AI（判断AI）
として扱います。
1. 今日のゴール
最終的に次の流れを自分で説明・実行できることを目指します。
問題を見つける
↓
AIで解決できる形に分解
↓
モデルを選ぶ
↓
小さくテストする
↓
正解データと比較する
↓
精度を測定する
↓
コストを計算する
↓
失敗パターンを調べる
↓
人間による確認方法を決める
↓
小規模導入
↓
本番投入
重要なのは、
「AIが動きました」
で終わらないことです。
ビジネスでは、
「本当に使って大丈夫ですか？」
まで答えられる必要があります。
2. 今回使うモデルの考え方
AIモデルには、それぞれ得意な仕事があります。
大きく分けて考えてみましょう。
| 種類 | 得意な仕事 | 例 |
|---|---|---|
| 生成AI | 文章を作る | GPT / Qwen / Gemma |
| Reasoning Model | 複雑な問題を考える | 推論モデル |
| Decision Model | 判断する | Laya / Von / Kev など |
Decision Modelでは、
文章を入力
↓
営業 0.82
請求 0.08
サポート 0.06
その他 0.04
のような結果を利用します。
3. 今回の実験
今回は架空の会社に届いた
100件の問い合わせメール
をAIに分類させます。
分類は5種類です。
営業
サポート
請求
クレーム
その他
人間が作成した
正解データ
も用意します。
そのため、
AIの回答
×
正解データ
を比較できます。
4. 最終的に作るもの
最終的な画面イメージです。
AIメール分類
Processed: 100 / 100
分類結果
営業 22 ███████████
サポート 31 ███████████████
請求 18 █████████
クレーム 12 ██████
その他 17 ████████
Accuracy
92.0%
Correct
92
Incorrect
8
さらに、
ID Subject Prediction Correct
001 製品について 営業 ✓
002 ログインできない サポート ✓
003 請求書について 請求 ✓
004 対応が遅い サポート ✗
のように確認できるようにします。
PART 1
環境を準備する
5. 必要なもの
今回使用するものです。
PC
├─ Windows
└─ macOS
Terminal
├─ Windows Terminal / PowerShell
└─ macOS Terminal
Python
Git
Ollama
今回はできるだけ
Windows / Mac共通
で進めます。
6. Gitをインストール
Windows
Git公式サイトからインストールします。
https://git-scm.com/download/win
インストール後、
git --version
を実行します。
Mac
Terminalで確認します。
git --version
入っていない場合は、
xcode-select --install
を実行します。
7. Pythonを確認する
Windows
PowerShellで、
python --version
または
py --version
Mac
python3 --version
を実行します。
8. 作業フォルダを作る
Windows
mkdir decision-ai-tutorial
cd decision-ai-tutorial
Mac
mkdir decision-ai-tutorial
cd decision-ai-tutorial
9. Python仮想環境を作る
プロジェクトごとにPython環境を分離します。
Windows
py -m venv .venv
有効化します。
.\.venv\Scripts\Activate.ps1
Mac
python3 -m venv .venv
有効化します。
source .venv/bin/activate
10. 必要なライブラリ
pip install pandas rich scikit-learn
主な役割です。
| ライブラリ | 用途 |
|---|---|
| pandas | データ処理 |
| rich | TUI表示 |
| scikit-learn | 精度評価 |
11. Ollamaを準備する
OllamaはローカルPCでAIモデルを動かすためのソフトウェアです。
インストール後、
ollama --version
を確認します。
12. モデルを確認する
ollama list
モデルが表示されれば準備完了です。
今回利用するモデルについては、授業実施時点で利用可能なモデル名・配布方法を確認してから指定します。
モデル名を推測してインストールしないでください。
PART 2
いきなりAIを導入しない
13. 最初に「問題」を決める
ここが最も重要です。
AIを導入することを目的にしてはいけません。
例えば、
毎日500件のメールが届く
↓
社員が内容を読む
↓
担当部署を判断
↓
転送する
という業務があるとします。
問題は、
メール分類に
毎日2時間かかっている
ことです。
14. 現在のコストを計算する
例えば、
2時間 / 日
×
20営業日
=
40時間 / 月
人件費を1時間3,000円とすると、
40時間
×
3,000円
=
120,000円 / 月
年間では、
1,440,000円
です。
ここで初めて、
AIを導入すると安くなるのでは？
という仮説を立てます。
15. AIが必要か考える
すべての問題にAIが必要なわけではありません。
例えば、
件名に「請求書」が入っていたら経理
だけなら、
if "請求書" in subject:
category = "請求"
で十分かもしれません。
比較します。
| 方法 | 特徴 |
|---|---|
| ルール | 最も安い |
| Decision Model | 曖昧な分類に強い |
| LLM | 複雑な文章理解に強い |
| 人間 | 柔軟だがコストが高い |
AIを使わない選択肢も必ず検討します。
PART 3
問題を分解する
16. 大きな仕事を小さな判断にする
「問い合わせ対応」という仕事をそのままAIに渡さないようにします。
分解します。
問い合わせ
│
├─ 何について？
│
├─ 緊急？
│
├─ クレーム？
│
├─ 重要顧客？
│
├─ 技術問題？
│
└─ 人間確認が必要？
AIには
小さな判断
を担当させます。
17. 掛け算として考える
例えば、
優先度
=
緊急度
×
顧客重要度
×
障害影響度
という考え方ができます。
AIに、
「全部考えて」
とお願いするのではなく、
緊急度
→ AI
顧客重要度
→ DB
障害影響度
→ AI
契約内容
→ DB
と分解します。
PART 4
テストデータを作る
18. まず100件で試す
いきなり会社の全メールをAIに渡しません。
まず、
100件
で実験します。
CSV形式にします。
id,subject,body,correct_label
1,料金について,料金プランを教えてください,営業
2,ログインできません,昨日からログインできません,サポート
3,請求書について,今月分の請求書を送ってください,請求
19. 正解データを作る
非常に重要です。
AIを評価するには、
正解
が必要です。
これを
Ground Truth
と呼びます。
メール
↓
人間が分類
↓
正解データ
を先に作ります。
20. AIに分類させる
AIには、
営業
サポート
請求
クレーム
その他
のどれかを返してもらいます。
結果を保存します。
id,prediction
1,営業
2,サポート
3,請求
PART 5
AIをテストする
21. 正解率を測る
例えば、
100件
正解
92件
不正解
8件
なら、
Accuracy = 92%
です。
しかし、
Accuracyだけでは不十分です。
22. Precisionを見る
例えばAIが
クレーム
と判断したメールが20件。
そのうち本当にクレームだったのが15件。
Precision
15 / 20
=
75%
です。
23. Recallを見る
本当はクレームが30件あったとします。
AIが見つけたのは15件。
Recall
15 / 30
=
50%
です。
これは問題です。
クレームを半分見逃しています。
24. Confusion Matrixを見る
例えば、
AI予測
営業 サポート 請求
正解 営業 20 2 0
正解 サポート 3 25 1
正解 請求 0 1 18
これを見ると、
どの分類を間違えやすいのか
が分かります。
25. 「何を間違えたか」を見る
数字だけ見てはいけません。
間違えた8件を実際に読みます。
例えば、
「料金を二重で請求されています。
至急確認してください。」
AI：
クレーム
正解：
請求
これは完全な誤りでしょうか？
実は、
請求
+
クレーム
の両方とも考えられます。
ここで、
分類ルールそのもの
を見直します。
PART 6
失敗する条件を探す
26. わざと難しいデータを入れる
本番では綺麗な文章だけ来ません。
テストします。
短文
無理です
誤字
せいきゅうしょおねがいします
長文
数千文字の問い合わせ。
曖昧
以前相談した件です。
複数要件
請求書を確認したいです。
それとログインもできません。
27. 多言語も確認する
例えば、
English
Chinese
Korean
Japanese
など。
多言語モデルを利用する場合でも、
「多言語対応だから大丈夫」
ではなく、
実際のデータで確認
します。
PART 7
モデルを比較する
28. 同じ問題を複数モデルに解かせる
同じ100件を使います。
Dataset
│
├─ Model A
├─ Model B
└─ Model C
比較します。
| Model | Accuracy | 処理時間 | メモリ |
|---|---|---|---|
| A | 92% | 8秒 | 2GB |
| B | 95% | 30秒 | 8GB |
| C | 90% | 4秒 | 1GB |
ここで重要なのは、
精度だけで決めない
ことです。
29. コストも比較する
例えば、
Model A
月額
5,000円相当
Accuracy
92%
対して、
Model B
月額
50,000円相当
Accuracy
93%
なら、
1%のために45,000円払う価値があるか？
を考えます。
PART 8
ローカルAIのメリット
30. APIとローカルを比較する
クラウドAPI
会社
↓
Internet
↓
AI API
↓
結果
Local AI
会社PC
↓
Local Model
↓
結果
31. コスト構造
クラウドAPIでは一般的に、
利用量
×
単価
で費用が増えます。
ローカルモデルでは、
PC
+
電気代
+
運用コスト
が中心になります。
ただし、
ローカル = 無料
ではありません。
32. ローカルAIにもコストがある
例えば、
PC購入
保守
アップデート
電気代
監視
障害対応
エンジニア工数
があります。
そのため、
TCO
Total Cost of Ownership
で比較します。
PART 9
セキュリティを確認する
33. AIに何を渡しているか
確認します。
個人情報
顧客情報
契約情報
医療情報
社内機密
パスワード
APIキー
などが含まれていないか確認します。
34. データの流れを書く
本番投入前に必ず、
入力
↓
どこへ送る？
↓
どこで処理？
↓
保存される？
↓
誰が見られる？
↓
いつ削除？
を確認します。
PART 10
AIを100%信用しない
35. Confidenceを利用する
例えば、
営業
Confidence
97%
なら自動処理。
しかし、
営業 38%
サポート 35%
その他 27%
なら、
人間確認
に回します。
36. Human in the Loop
例えば、
Confidence >= 90%
↓
自動処理
60%〜90%
↓
人間確認
< 60%
↓
処理しない
という設計ができます。
※ 90%や60%は例です。
実際の閾値はテスト結果から決めます。
PART 11
本番投入前チェック
37. 上司に聞かれたら答えられるようにする
本番投入の前に、次の質問へ答えられる状態にします。
| 上司からの質問 | 確認すること |
|---|---|
| 何の問題を解決するの？ | 現在の業務課題 |
| 本当にAIが必要？ | ルール処理・人間との比較 |
| どのくらい正確？ | Accuracy / Precision / Recall |
| 間違えたらどうする？ | 人間確認・例外処理 |
| いくら安くなる？ | 導入前後のコスト |
| 情報漏えいは大丈夫？ | データの送信先・保存先 |
| PCでちゃんと動く？ | CPU / GPU / RAM / 処理時間 |
| WindowsでもMacでも使える？ | 両環境での動作確認 |
| 大量処理できる？ | 100件 → 1,000件 → 10,000件の負荷試験 |
| モデルが止まったら？ | フォールバック |
| 誰が責任を持つ？ | 最終判断者・運用担当者 |
| 精度が落ちたら？ | 定期評価・再テスト |
| 元に戻せる？ | AIを使わない従来フローを残す |
この表をすべて確認できれば、
「とりあえずAIを入れてみました」
ではなく、
「必要性、精度、コスト、セキュリティ、障害時対応まで検証済みです」
という説明ができます。
PART 12
本当にコスト削減になるか確認する
38. Before / Afterを作る
AI導入前の業務を測定します。
例：
問い合わせ件数
500件 / 日
分類作業
2時間 / 日
人件費
3,000円 / 時間
月20営業日なら、
2時間
×
20日
×
3,000円
=
120,000円 / 月
年間では、
1,440,000円 / 年
です。
39. AI導入後を計算する
例えばAI導入後、
AI自動分類
90%
人間確認
10%
になったとします。
人間の作業が、
2時間
↓
20分
になれば、
20分
×
20日
なので、
約6.7時間 / 月です。
人件費3,000円なら、
約20,000円 / 月
になります。
40. AI自体のコストも入れる
ここを忘れてはいけません。
AI導入による削減額
=
削減できた人件費
-
AI利用料
-
サーバー費
-
保守費
-
確認作業
-
開発費
例えば、
以前
120,000円 / 月
AI導入後、
人間確認 20,000円
サーバー 5,000円
保守 10,000円
-------------------
合計 35,000円
なら、
120,000
-
35,000
=
85,000円 / 月
の削減です。
年間では、
1,020,000円
になります。
※ 数値は授業用の仮定です。
41. ROIを見る
例えば開発に、
300,000円
かかったとします。
毎月、
85,000円
削減できるなら、
300,000
÷
85,000
≒
3.5か月
です。
約4か月で初期投資を回収できる計算になります。
これを、
投資回収期間
として説明できます。
PART 13
小さく本番環境へ入れる
42. いきなり100%自動化しない
危険なのは、
テスト成功
↓
全社導入
です。
段階的に進めます。
STEP 1
100件で実験
↓
STEP 2
過去データ1,000件
↓
STEP 3
実際の業務でAIを動かす
ただし結果は使わない
↓
STEP 4
人間の判断と比較
↓
STEP 5
一部業務だけ自動化
↓
STEP 6
対象範囲を拡大
43. Shadow Mode
非常に重要なテスト方法です。
AIを本番データで動かします。
ただし、
AIの判断では実際の処理を行いません。
本番メール
│
├────────→ 人間
│ ↓
│ 実際の処理
│
└────────→ AI
↓
判断だけ
あとから、
人間の判断
×
AIの判断
を比較します。
これなら業務へ影響を与えずにテストできます。
44. Canary Release
Shadow Modeで問題がなければ、
一部だけAIに任せます。
例えば、
100件
↓
5件
AI自動処理
95件
従来処理
問題がなければ、
5%
↓
10%
↓
25%
↓
50%
↓
100%
と増やします。
PART 14
フォールバックを作る
45. AIが止まったらどうする？
必ず考えます。
AI正常
↓
AI分類
AIが利用できなければ、
AI停止
↓
従来のルール処理
または
人間による処理
へ戻します。
これを、
Fallback
と呼びます。
46. AIを業務の単一障害点にしない
例えば、
メール
↓
AI
↓
担当者
だけでは、
AIが止まると業務全体が止まります。
そこで、
┌→ AI
メール ───────┤
└→ 従来処理
のように逃げ道を作ります。
PART 15
ログを残す
47. AIの判断を記録する
最低限、
日時
入力ID
使用モデル
モデルバージョン
AIの回答
Confidence
最終判断
人間による修正
処理時間
エラー
を記録します。
例：
id,model,prediction,confidence,final_label
001,laya,営業,0.94,営業
002,laya,サポート,0.72,請求
003,laya,請求,0.98,請求
48. なぜログが必要？
例えば3か月後、
最近AIの間違いが増えた
とします。
ログがなければ、
いつから？
どの分類？
どんな文章？
どのモデル？
どのバージョン？
が分かりません。
ログがあれば原因を調査できます。
PART 16
継続的に評価する
49. AIは導入して終わりではない
例えば会社の商品が変わったとします。
以前：
商品A
商品B
商品C
半年後：
商品A
商品B
商品C
商品D
新サービスE
入力データが変化します。
そのため、
Accuracy
92%
↓
87%
↓
79%
と落ちる可能性があります。
50. 定期テストをする
例えば、
毎月
100件をランダム抽出
↓
人間が正解を確認
↓
AIと比較
します。
記録します。
4月 94%
5月 93%
6月 92%
7月 87%
急に低下したら調査します。
51. 判断基準を決める
例えば、
Accuracy >= 95%
正常
90〜95%
注意
< 90%
要調査
と決めます。
ただし、この数値は例です。
業務によって必要な精度は異なります。
PART 17
「正解率」だけで判断しない
52. 間違えた時の損失を見る
次の2つは同じ「1件の間違い」でしょうか？
ケースA
営業メール
↓
その他
ケースB
重大なクレーム
↓
その他
同じ1件の誤分類でも、
ビジネス上の損失が違います。
53. Risk × Probability
そこで、
発生確率
×
発生した場合の影響
で考えます。
例えば、
| エラー | 発生確率 | 影響 | 対応 |
|---|---|---|---|
| 営業誤分類 | 中 | 小 | 自動処理可 |
| 請求誤分類 | 中 | 中 | 一部確認 |
| クレーム見逃し | 低 | 大 | 人間確認 |
| 重要顧客見逃し | 低 | 大 | 人間確認 |
こうすると、
どこまで自動化してよいか
判断しやすくなります。
PART 18
AIに任せる範囲を決める
54. 自動化レベルを分ける
すべて同じ扱いにしません。
LEVEL 0
人間だけ
↓
LEVEL 1
AIが候補を表示
↓
LEVEL 2
AIが判断
人間が承認
↓
LEVEL 3
高Confidenceのみ自動
↓
LEVEL 4
原則自動
例外だけ人間
最初からLEVEL 4を目指す必要はありません。
55. 実際の業務フロー
例えば、
メール受信
↓
AI分類
↓
Confidence確認
├─ 95%以上
│ ↓
│ 自動振り分け
│
├─ 70〜95%
│ ↓
│ 人間確認
│
└─ 70%未満
↓
未分類BOX
という運用ができます。
※ 閾値はテスト結果から決定します。
PART 19
Decision AIを組み合わせる
56. 1つの巨大なAIに全部任せない
例えば、
この問い合わせを分析して、
顧客重要度を考えて、
緊急度を判断して、
部署を決めて、
返信も作って、
送信してください。
では処理が大きすぎます。
分解します。
57. 小さな判断の組み合わせ
問い合わせ
↓
┌─────────────┐
│ 内容分類 │
└─────────────┘
↓
┌─────────────┐
│ 緊急度判定 │
└─────────────┘
↓
┌─────────────┐
│ 顧客重要度 │
└─────────────┘
↓
┌─────────────┐
│ リスク判定 │
└─────────────┘
↓
Action
それぞれを独立してテストできます。
58. これが「判断の掛け算」
例えば、
優先度
=
緊急度
×
顧客重要度
×
影響範囲
という考え方です。
さらに、
自動処理可能？
=
分類Confidence
×
リスク
×
業務ルール
という設計もできます。
AIだけで答えを決めるのではありません。
AI
+
DB
+
ルール
+
人間
を組み合わせます。
PART 20
最終課題
59. 自分の業務から1つ問題を選ぶ
例えば、
メール分類
問い合わせ分類
レビュー分類
商品分類
営業リード判定
SNSコメント分類
FAQ分類
社内問い合わせ分類
などです。
60. 問題を1文で書く
悪い例：
AIを導入したい
良い例：
毎日500件届く問い合わせの
担当部署振り分けに
2時間かかっている。
61. 現状を数字にする
最低限、
件数
作業時間
人件費
ミス件数
対応時間
を調べます。
62. 問題を分解する
例えば、
問い合わせ対応
を、
問い合わせ内容分類
緊急度
顧客重要度
対応部署
人間確認必要性
に分解します。
63. AIを使わない方法も考える
必ず、
ルール
検索
データベース
従来プログラム
人間
Decision Model
LLM
を比較します。
64. テスト計画を作る
最低でも、
100件のテストデータ
正解データ
通常データ
曖昧データ
誤字
長文
短文
複数要件
を用意します。
65. 評価する
最低限、
Accuracy
Precision
Recall
処理時間
メモリ使用量
1件あたりコスト
失敗パターン
を確認します。
66. Before / Afterを作る
導入前
作業時間：
コスト：
ミス：
処理件数：
導入後
作業時間：
コスト：
ミス：
処理件数：
を比較します。
67. 本番投入方法を決める
PoC
↓
過去データテスト
↓
Shadow Mode
↓
5%導入
↓
25%
↓
50%
↓
本番
という流れを考えます。
68. 最終発表
次の内容を簡潔にまとめます。
① Problem
何が問題なのか。
② Current Cost
現在どれくらい時間・費用がかかっているか。
③ Decomposition
仕事をどのような判断に分解したか。
④ Solution
どの方法で解決するのか。
⑤ Why AI?
なぜルール処理ではなくAIなのか。
⑥ Test
どのようにテストしたか。
⑦ Accuracy
どの程度正確だったか。
⑧ Failure
どんな時に失敗したか。
⑨ Cost
導入するといくらになるか。
⑩ Risk
誤判定・セキュリティなどのリスクは何か。
⑪ Human Check
どこを人間が確認するか。
⑫ Deployment
どのように本番投入するか。
69. 上司への説明を想定する
最終的には、
このAIを使いたいです。
ではなく、
次のように説明できることを目標にします。
現在、この業務に月40時間かかっています。
ここまで説明できれば、
「AIだから導入する」
ではなく、
「業務改善の手段としてAIを選択した」
と説明できます。
70. 最後に
この授業で一番重要なのは、
AIモデルの名前を覚えることではありません。
重要なのは、
「問題に対して、どの技術を、どこまで使うべきか判断できること」
です。
AIを使うこと自体を目的にしてはいけません。
問題
↓
現状を数字で把握
↓
問題を小さく分解
↓
AI以外の方法も検討
↓
適切なモデルを選択
↓
小さくテスト
↓
正解データと比較
↓
失敗する条件を確認
↓
コストを比較
↓
リスクを確認
↓
人間が確認する範囲を決定
↓
段階的に本番投入
↓
継続的に評価
この流れを守ることで、
「AIが動いた」から「AIを業務で使える」へ進むことができます。
71. AIは全部を担当しなくてよい
例えば、問い合わせ対応という仕事があったとしても、
すべてを1つのAIに任せる必要はありません。
問い合わせ
↓
文章の分類
↓
緊急度の判定
↓
顧客情報をDBから取得
↓
業務ルールで優先順位を計算
↓
必要なものだけ人間が確認
↓
LLMが返信文を作成
このように、
Decision Model
+
従来プログラム
+
データベース
+
LLM
+
人間
を組み合わせることができます。
それぞれが得意な部分だけを担当します。
72. 小さいモデルにも役割がある
大きなLLMは非常に便利です。
しかし、すべての処理に大きなモデルが必要とは限りません。
例えば、
これは営業メール？
YES / NO
という判断だけなら、大きな生成AIを毎回利用する必要がない場合があります。
小型のDecision Modelで十分な精度が出れば、
高速化
+
コスト削減
+
ローカル処理
+
処理の単純化
につながる可能性があります。
ただし、
「小型モデルだから安い」
と決めつけてはいけません。
実際の処理時間、ハードウェア、運用費、精度を測定して比較します。
73. モデル選択ではなく「役割選択」から考える
最初から、
Layaを使おう
Qwenを使おう
GPTを使おう
と考えないようにします。
先に、
何を判断したい？
を決めます。
例えば、
分類したい
↓
分類モデルを検討
YES / NOを判断したい
↓
Decision Modelを検討
複雑な理由を考えたい
↓
Reasoning Modelを検討
文章を書きたい
↓
生成LLMを検討
正確な顧客情報が必要
↓
データベースを利用
完全にルール化できる
↓
通常のプログラムで処理
という順番です。
74. AI導入の基本公式
今回の授業を簡単にまとめると、
良いAI導入
=
明確な問題
×
適切な問題分解
×
適切なモデル
×
正しいテスト
×
安全な運用
です。
どれか1つだけ優れていても十分ではありません。
75. 「精度99%」だけでは判断しない
例えば、
Accuracy
99%
という結果が出ても、それだけでは本番投入できません。
確認する必要があります。
何件でテストした？
どんなデータだった？
正解データは誰が作った？
重要な1%を間違えていない？
新しいデータでも動く？
処理速度は？
コストは？
個人情報は？
AIが停止したら？
モデルを変更したら？
人間はどこで確認する？
数字の高さではなく、
その数字を信用できる理由
まで確認します。
76. 実験結果を残す
実験するときは、最低限次の情報を残します。
| 項目 | 記録内容 |
|---|---|
| 実験日 | いつ実施したか |
| モデル | 使用モデル |
| バージョン | モデル・ライブラリのバージョン |
| PC環境 | Windows / Mac |
| CPU / GPU | 使用ハードウェア |
| RAM | 使用メモリ |
| データ数 | 100 / 1,000 / 10,000件など |
| Accuracy | 正解率 |
| Precision | 適合率 |
| Recall | 再現率 |
| 処理時間 | 全体・1件あたり |
| メモリ使用量 | 最大使用量など |
| コスト | API・サーバー・運用費 |
| 誤分類 | 具体的な失敗例 |
| 備考 | 問題点・改善点 |
これによって、
Model A
vs
Model B
vs
Model C
を感覚ではなく数字で比較できます。
77. 最終チェックリスト
本番投入前に確認します。
問題
解決方法
データ
精度
異常系
性能
コスト
セキュリティ
運用
本番投入
78. 最終的に目指す状態
AIを導入するとき、
このモデルがすごいので使います。
ではなく、
この業務には、
この問題があります。
現在は月○時間、
○円のコストが発生しています。
問題を分解した結果、
この判断部分について
AIを利用する価値があると考えました。
AIを使わない方法とも比較しています。
○件のデータでテストし、
精度・速度・コストを測定しました。
失敗する条件も確認しました。
重要な判断については
人間が確認します。
AIが停止した場合は
従来フローへ戻せます。
まずShadow Modeで検証し、
問題がなければ段階的に導入します。
導入後も継続して精度を測定します。
と説明できる状態を目指します。
79. 今日覚えてほしいこと
AIを使う
ではなく、
問題を見つける
↓
分解する
↓
測る
↓
比較する
↓
小さく試す
↓
失敗を調べる
↓
安全に導入する
↓
継続して測る
ここまでが、
AIをビジネスで使う
ということです。
最終メッセージ
大きなAIに全部考えさせることだけが、AI活用ではありません。
仕事をよく観察すると、
分類する
判断する
点数を付ける
優先順位を決める
異常を見つける
文章を作る
人間に確認してもらう
という小さな仕事に分けることができます。
その一つひとつに、
最も適した手段を配置する。
それが、実際のビジネスでAIを活用するための基本的な考え方です。