AIを何度も使うようになると、次第に「どのモデルが強いか」より別の問題が効いてきます。

上位AIへ全部渡したら遅い
軽いAIへ落としたら人の確認が増えた
Agentを細かく分けたらContext再読が重い
Codeへ移したら例外処理の保守が増えた
安いRouteを選んだのにRetryで総負担が増えた
最後に人が全部読む設計になっている
Modelや料金が変わるたび、仕事の設計まで作り直している

この段階で必要なのは、単純な「高性能Model / 安いModel」の比較ではありません。

仕事を工程へ分け、その工程に必要な判断力・検証可能性・復旧性へ合うRouteを選ぶこと。

本教材では、実行経路を次の5種類として扱います。

Human
Code
Tool
Light AI
Strong AI

そして工程ごとに、

Detectability
Recoverability
Propagation
Human Touch
Retry
Escalation
Fallback

を見ながら振り分けます。

狙いは「強いAIをなるべく使わない」ことではありません。

強い判断が必要な場所へ、強いAIや人間を残すこと。

逆に、意味判断が不要な反復はCodeやToolへ逃がします。

30秒診断――その仕事、「全部同じAI」になっていませんか？

一つの仕事を思い浮かべてください。

たとえば記事制作なら、

構成
本文Draft
見出し番号確認
画像寸法確認
Fact Check
ZIP検査
公開判断

があります。

この全部を同じAIへ渡しているなら、次の5問へ答えます。

1. この工程は意味判断が必要か
2. 誤りを後から見つけられるか
3. 失敗したら局所修正できるか
4. 人が読む量はどれくらいか
5. 何が起きたら上位Routeへ上げるか

たとえば画像寸法確認はCodeへ寄せられるかもしれません。

一方、記事全体の論理矛盾はStrong AIやHumanの方が向くかもしれません。

大事なのは、

「AIにできるか」ではなく、「毎回AIに考え直してもらう必要があるか」。

です。

この教材で持ち帰るもの

Route Gate
Route Manifest
Human / Code / Tool / Light AI / Strong AI
Detectability / Recoverability / Propagation
Escalation / Fallback
Retry Delta
Human-touch Budget
Compute / Wall-clock / Critical Path
Context / Handoff Cost
Deterministic Migration Gate
Accepted-output Cost
Route Experiment
Article / Image / Researchの3ケース
Reopen Trigger
Stop Rule
Route Manifest完全版

1. Modelを選ぶ前に、工程を分ける

AIコストを下げようとすると、最初にModel比較へ行きがちです。

でも、同じ仕事の中にも性質の違う工程があります。

調査
↓
抽出
↓
整形
↓
判断
↓
生成
↓
検査
↓
修正
↓
採用
↓
公開

全部を「AI作業」という一語へ潰すと、Route設計ができません。

そこで、

仕事の種類ではなく、工程ごとの失敗構造を見る。

という順序に変えます。

2. Route Gateの5問

Q1. 意味の曖昧さを解釈する必要があるか

意味判断が必要な例：

相手の要望の矛盾を整理
複数条件を統合
文章の論点を判定
原因候補を比較
画像の意図一致を判断

意味判断がほぼ不要な例：

Hash計算
File名変更
行数集計
画像寸法取得
必須File存在確認

規則が固定済みなら、毎回LLMへ考え直してもらう必要はないかもしれません。

Q2. 誤りを後から検出できるか

軽いRouteを試しやすいのは、失敗を後から見つけられる工程です。

JSON Schema
画像寸法
File existence
重複件数
Hash

などは機械検査を置けます。

一方、自然な要約が原文と逆の意味になった場合、見た目だけでは気付きにくい。

「短いTaskだから軽量AI」とは決めません。

失敗の見つけやすさを見ます。

Q3. 失敗したら局所修正できるか

一工程だけ戻せるなら試行しやすくなります。

反対に、入口の誤判断が後工程へ広がり、最後に全体やり直しになるならRoute選択を慎重にします。

見るのは失敗確率だけではありません。

失敗したときの影響範囲です。

Q4. 人が読む量はどれくらいか

安いAIが5000字を10本出し、人が全部読む。

これは生成費が安くても運用は軽くありません。

一方、出力を固定形式へ狭め、

差分
FAIL理由
要確認項目

だけ読めるならHuman Touchは下がるかもしれません。

人の確認も資源として扱います。

Q5. 何が起きたら上位Routeへ上げるか

例：

Validator FAIL
必須情報欠損
同じFailureが継続
曖昧条件が残る
重大Risk判断が必要
Human Review量が上限超過

これがEscalation条件です。

最初から全工程をStrong AIへ渡すのではなく、

必要になった地点だけ強い判断へ上げる

ために使います。

3. 最小Route Card

工程:
完成条件:

意味判断:
- high / medium / low / unknown

誤りの検出:
- machine / human / difficult / unknown

失敗時の戻り方:
- local / previous-stage / full-redo / unknown

人が読む量:
- low / medium / high / unmeasured

第一Route:
- Human / Code / Tool / Light AI / Strong AI

上位へ切り替える条件:
-

特に、

検出しにくい
+
全体やり直し
+
Human負担未計測

が重なる工程は、単純そうだからという理由だけでRouteを下げない方が安全です。