第5章：創発タスクと非創発タスクの境界線
― Devinでさえ破綻する領域と、最初からAIに任せるべきでない領域
AIエージェントの設計で、最も誤解が多い部分がある。
「AIに任せれば自律的に問題を解いてくれるはずだ」 という期待。
残念ながらこれは正しくない。 むしろ、多くの失敗はここから生まれている。
AIがうまく働く領域と、働きづらい領域には、 構造的に明確な境界線がある。
その境界の名前が 創発性 だ。
創発タスクとは何か？
創発タスクとは、 「答えが事前に決まっていない問題」のことだ。
- 新しいサービスアイデアを考える
- まだ整理されていない市場を評価する
- 曖昧な要件から構造を設計する
- 前例のない障害原因を推測する
- 新しい研究仮説を生成する
ここでは、 "やるべきこと" そのものが問題を解きながら変化していく。
つまり、判断の文脈が固定できない。
LLMはこれが得意だ。 巨大モデルに蓄積されたパターンから、 多様なアイデアや視点を引き出すことができる。
ただし—— 得意なのは「発想」や「観察」、つまり 生成的な部分だけ だ。
非創発タスクとは何か？
一方、非創発タスクとは、
「やるべきことが事前に決まっており、手順も安定している」 領域だ。
- データ集計
- 相関分析
- 異常検知
- API呼び出し
- スクリプト生成
- 書類の下書き
- チェックリスト評価
ここには「驚き」はいらない。 求められるのは正確さ、安定性、一貫性だ。
AI設計で重要なのは「創発に任せる部分を最小化する」こと
AIに任せてよい創発は "判断の補助" のみ。 実行は外に出し、安定させるべき。
ところがよくある失敗はこうだ：
❌ 創発 × 自律 × タスク実行
→ AIがタスクを自分で決め、自分で実行し、自分で評価する → ループ・暴走・無意味な探索・コスト爆発
これは現在の技術で最も破綻しやすい構造だ。
象徴的なのが Devin問題 である。
Devinが示した限界 ― 「創発 × 自律」はまだ難しい
Devinは「AIソフトウェアエンジニア」を自称した最初の大規模プロジェクトだった。 驚くべき能力を示す一方で、次のような問題も頻発した。
- 無限ループ
- 不必要な探索
- 自分で壊したコードを直し続ける
- "正しそうに見える"が実際は動かない修正
- パフォーマンスの悪い手順を延々と試す
これは設計パターンが悪いのではなく、 創発性を完全自律で回すこと自体が、構造的に難しい ことを示している。
理由は明確だ。
創発タスクには「ルール不定」「探索の無限性」が内在するから。 人間のソフトウェアエンジニアでさえ、 経験・規律・制約・メンタルモデルで探索空間を絞っている。 AIにはそれがない。
自律性はスペクトラムである
ここで重要なのは、「伴走か自律か」を二者択一として捨てることだ。
実際のエージェント設計では、自律性は スペクトラムとして捉える。
- ある処理は完全自律でいい（非創発の定型処理）
- ある処理はチェックポイントだけ人間が入ればいい
- ある処理は人間が主導しないと成立しない（戦略判断など）
このスペクトラムのどこに位置づけるかを決めるのが設計だ。
そして根本的な原則はこうだ。
創発性が高いほど、人間の介在（HITL）側に寄せないと安定しない。
これは「自律はだめだ」という話ではない。非創発タスクなら自律は極めて強い。創発タスクでも、人間の介在のポイントを絞れば自律的に回せる範囲はある。
問題は「伴走か自律か」ではなく、 「どこまで自律させて、どこで人間を入れるか」 の設計だ。
創発を制御するのは「人間の一声」である
創発は、AIの強みである。 新しい視点やバリエーションを生成できる。
ただし、それを 制御するのは人間の役割 だ。
- 「方向がズレている」
- 「これは意味が薄い」
- 「この方針は採用しない」
こうした調整点を、人間が1ミリでも挟むと、 創発の暴走は瞬間的に止まる。
これを 伴走型（Co-pilot） と呼ぶ。スペクトラムの中で、人間の介在を最も強く入れた構造だ。
スペクトラムの3つの代表的位置
- 創発 × 伴走 → 安定性が高い。人間が収束させる
- 非創発 × 自律 → 実務で最も強い。手順が固定ならAI単体で回る
- 創発 × 自律 → リスクが高い。HITLの設計が不十分だと破綻する
この3つは、スペクトラム上の代表的な位置であり、その間に無数の設計判断がある。
「創発が必要か？」は設計前に必ず判定するべき
タスクを見たら、最初にやるべきことはこれだ。
- 創発が必要？
- それは自律で回せる？
- 回せないなら伴走にする？
- 伴走ならタスク範囲を固定して文脈を守る？
多くの現場で起きている混乱は、 この判定をしていないことに起因している。
非創発タスクは「リスト化」と「事前計算」が最適解
非創発タスクのほとんどは、 実は「既知の分析・操作のパターン」に過ぎない。
それは次章で扱う レポート化アーキテクチャ につながっていく。
- データ分析は創発ではない
- パターンカタログを網羅的に適用すれば終わる
- だからリアルタイムAIは必要ない
- バッチで計算し、レポートとして永続化すればよい
創発タスクと非創発タスクを分けて考えると、 この構造が非常にクリアになる。
スペクトラムの具体像
抽象的になりすぎないように、具体的な例で示す。
伴走型（Co-pilot） ― HITLが最も強い位置
AIは「アイデアや視点」を出し、人間が方向性を決める構造。
- 創発との相性: ◎（人間が収束させる）
- 判断の主語: 人間
- 探索空間: 制限される
- 安定性: 高い
- 最適領域: 創発タスク（曖昧な問題・新規課題）
自律型（Autonomous） ― HITLが最も弱い位置
AIが自分で方針を決め、実行し、評価する構造。
- 創発との相性: リスクが高い（HITL設計が不十分だと暴走する）
- 判断の主語: AI
- 探索空間: 制約なしだと無限に広がる
- 安定性: 非創発なら高い。創発なら低い
- 最適領域: 非創発タスク（定型処理・手順明確）
その間 ― 実務の大半はここにある
AIが自律的に動くが、特定のチェックポイントで人間が介在する構造。
- 方針の決定時だけ人間が承認する
- リスクの高い実行前に確認を入れる
- 定期的に結果をレビューし、軸修正する
実務で最も多いのはこの「間」の設計だ。創発性とリスクに応じて、HITLの強度を調整する。
次章への橋渡し：非創発 × 自律の最適解が「レポート化」になる
非創発タスクの大半はすでにパターン化されている。 創発を必要としない。 つまり自律型で安定運用できる。
そして非創発 × 自律の最適解が、 次章で扱う 「レポート化アーキテクチャ」 である。
この章のまとめ
- 創発タスクと非創発タスクの境界線を先に引くことが設計の出発点
- 自律性は二項対立ではなくスペクトラムである
- 創発性が高いほど、HITL側に寄せないと安定しない
- Devin問題が示したのは、創発の無限性をAI単体では制御できないこと
- 非創発タスクは手順が固定しており、外部化・テンプレート化・事前計算が最適
- 実務の大半はスペクトラムの「間」にある。創発性とリスクに応じてHITLの強度を調整する
次章（第6章）は、 データ分析の本丸：レポート化アーキテクチャ に進む。
ここでシリーズ全体の"実務的インパクト"が最大化される。
Last Updated: 2026-04-06