AI が要らないとき
AI は、繰り返しの量があり、データが明確で、測れる効果が期待できるときに役立ちます。しかし「みんながやっているから」と入れてしまい - 結果ではなくコスト・リスク・ノイズだけが増えることがよくあります。以下は AI が要らないとき の実務ケースと、モデルの代わりに何をするかです。
- 量がない - タスクはまれで、手作業の方が安くて速い
- データがない - 文書とプロセスの混乱はモデルで増幅されるだけ
- 保証が必要 - 金銭、法的事実、セキュリティ、生命と健康
- ルールが硬い - if/else、バリデータ、スクリプトの方が LLM より信頼できる
- 原則 - 先にプロセスと指標、あとからモデル
AI は道具であり、必須レイヤーではない
モデルは下書き、分類、意味検索、オペレーターへのヒントに強いです。明確なブリーフ、きれいなデータ、意思決定の人の責任の代わりにはなりません。
2026 年の典型的な失敗は、「製品に AI」を買う前に三つの問いに答えないこと - どのくらいの量か、成功指標は何か、誰が誤りに責任を持つか。答えがなければ、AI は高いアーキテクチャの飾りになります。
AI が確実に要らないとき
1. タスクがまれで手作業が安い
週に一度、10-15 分の作業なら、LLM 自動化は導入と運用の方が高いことが多いです。比較してください：連携コスト + トークン + 品質管理 vs 年間の人時。
2. プロセスがまだ書かれていない
規程がなく、唯一の正がなく、チャット回答が FAQ と矛盾する。AI は「秩序を作らない」- 混乱を拡大します。先にプロセス地図、その後に自動化。
3. 決定的な結果が必要
税番チェック、税計算、支払いステータス、アクセス権、API スキーマ準拠 - これはルールとテストの領域です。LLM は確率的で、同じ入力でも出力が変わり得ます。保証にはコード、バリデータ、ワークフローを使い、プロンプトではありません。
4. 誤りの代償が高すぎる
顧客への法的約束、医療的結論、確認なしの金融取引、インフラセキュリティ。人付きのコパイロットはあり得ます。エスカレーションなしのオートパイロットは不可です。
5. データが少ない、または汚い
古い PDF 三枚と散らばった Notion ページの RAG は、自信満々の誤答を生みます。先にナレッジベースを整理：文書バージョンとコンテンツ所有者。
6. すでに簡単な解がある
カタログ検索、フィルタ、メールテンプレ、サポートマクロ、SQL レポート、LLM なしの n8n。古典的ツールが 80% をカバーするなら - デモのためにスタックを複雑にしない。
7. 指標のオーナーがいない
ベースライン（応答時間、誤り率、チケット単価）がなければ、AI が助かったか分かりません。「賢くなった気がする」は KPI ではありません。前後の数値が必要です。
AI の代わりに何をするか
| 状況 | まず始めること |
|---|---|
| プロセスの混乱 | 規程、チェックリスト、役割 |
| 繰り返し回答 | FAQ、テンプレ、マクロ |
| 連携とステータス | API、キュー、ワークフロー（n8n など） |
| カタログ検索 | ちゃんとした検索とフィルタ |
| 分析 | SQL / BI。「チャットに聞け」ではない |
| たまに下書きが要る | 狭いコパイロット、自動送信なし |
多くの場合、最善の道は：プロセスを単純化 → ルールを自動化 → テキストや分類が本当に時間を節約する狭い一点にだけ AI。
一日で AI が要るか判断する
- 先月の実タスクを 20 個書き出す。
- 繰り返しで、合計週 30 分超のものを印付けする。
- きれいなデータと「正しい / 誤り」の基準があるか確認する。
- 誤りのリスクを評価：ロールバック可能か、人が必要か。
- 量が少ない・データが汚い・リスクが高いなら - モデルは後回し。
指標なしのパイロットは実験のための実験です。ベースラインと停止条件があるパイロットが、仮説検証のまっとうなやり方です。
まとめ
AI が要らないのは、量がない、データがない、硬い保証が要る、または単純なルールで既に足りるときです。先にプロセス・データ・指標 - その後、狭いシナリオでモデルと品質管理。そうでなければトークンと運用費を払い、成果はスライドのままです。
製品やサポートのどこで AI が効き、どこで規程と LLM なしの自動化で足りるか、正直に見たい場合はご連絡ください。
よくある質問
「AI が要らない」は AI が無用という意味ですか？
いいえ。 AI は量がある場面で役立ちます：下書き、FAQ、分類、きれいなベース上の RAG、オペレーターのコパイロット。ポイントは、ルール・希少性・誤りのコストで冗長になる場所にモデルを置かないことです。
AI から始めて、あとでプロセスを整えられますか？
通常はいいえ。 モデルは現状を増幅します。プロセスが混沌なら、自動化は混沌を加速します。まず最小の秩序と正のソース、その後に狭いパイロット。
立ち上げ期のサポートで AI の代わりは？
FAQ、返信テンプレ、マクロ、API でのステータス、明確なエスカレーション。 これで一次対応をカバーできることが多いです。典型チケットが多く、ナレッジが安定してから AI を足します。
高リスクでも AI が妥当なのはいつ？
最終自動返信ではなく、人の助手として。 下書き、リスクの強調、規程の検索 - はい。レビューなしの顧客への自動送信 - 厳しい制御と監査があるまで不可。
クライアントに「まだ AI は早い」とどう説明しますか？
数字で： タスク量、導入コスト、誤りリスク、LLM なしの単純ワークフローが既に出せるもの。段階を提案：秩序 → ルール → 指標付きの単一シナリオ AI パイロット。それは成熟に見え、「進歩反対」には見えません。