第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の強度を調整する。
「創発 × 自律」を成立させる6つの構造条件
「創発性が高いほどHITL側に寄せないと安定しない」は、逆からも読める。
人間の介在の代わりに構造を置ければ、創発タスクでも自律の範囲は広げられる。
コード生成をAIに自律実行させる開発基盤（colaboration-agent）を運用して、これを確かめた。コード生成は創発タスクだ。要件から実装への写像は事前に決まっていない。それでも自律で回る。回しているのはAIの賢さではなく、次の6つの構造条件である。
1. 事前リスク判定 ― 実行前に「人間に回す」を決める
タスク分類の時点で、AIが自分の担当タスクのリスクを判定する。構成変更・セキュリティ関与・影響範囲の広い変更は、実行前に人間へ渡す。
この判定自体が創発的判断であり、「自分でできる」と過信しうる。だから判定をAIだけに任せない。核心ファイルの変更やセキュリティ関与は、ルールで強制的に人間側へ倒す。AI判断と構造的ルールのハイブリッドにする。
このとき前提になるのは、人間側へ倒す操作をあらかじめ列挙できることだ。列挙できていれば、残りは自律で回してよい。逆に、危険側を書き出せないまま自律の範囲だけを絞るのは、安全になったのではなく、判定を先送りしただけである。
2. 事後構造チェック ― 判断と検証を分ける
自律実行した結果を、別プロセスが検証する。実行役と検証役を分離し、検証は「そのまま採用 / 修正が必要 / やり直し / 人間判断」のように離散的な判定に落とす。
ここで効くのは第2章の「ペルソナ＝文脈のパッケージ」だ。実行役と検証役は別の役割文脈を持つ。同じLLMでも文脈が違えば異なる判断になる。
ただし補正できる範囲は限られる。
- 文脈バイアスは補正できる ― 役割分離で実現する
- モデルバイアスは補正できない ― 文脈を変えても同じ盲点は残る
だから検証を1つの総合判断にまとめない。「コード品質」「セキュリティ」「テストの有無」「スコープ逸脱」のように、独立した検証軸を構造的に複数定義する。ある軸が盲点に落ちても、別の軸が拾う。
そしてこの仕組みには容量の限界がある。同時に走らせる自律の本数を増やすと、先に飽和するのは実行側ではなく検証側だ。
事後チェックは、検証する側の帯域を超えた瞬間に壊れる。壊れ方が悪い。落ちるのではなく、通ったことになる。
だから同時に走らせる自律の本数（幅）に上限を置く。上限の根拠はAIの能力ではなく、検証側が実際にさばける量である。エラーを出さずに縮退するぶん、この失敗は他のどれよりも見つけにくい。
3. ループ上限 ― 自己修正の回数に物理的な上限を置く
「修正 → 再検証」の往復に回数上限を置く。超えたら人間にエスカレートする。
上限は暴走を止めるだけで、品質を保証しない。同じ問題を3回繰り返して3回とも失敗することはある。止まった時点のコードは中途半端なままだ。それでよい。安全弁と品質保証は別の仕組みである。
「回数ではなく収束度で判断する」という改良は採らない。収束判定自体がAI判断になり、安全弁に不安定性を持ち込む。
安全弁はシンプルであることが価値だ。安全弁に知性を入れると、安全弁自体が壊れる。
4. 連鎖上限 ― 自律の深度を制限する
自律実行が次のタスクを生む構造では、連鎖の深さに上限を置く。N世代を超えたら必ず人間のチェックポイントを通す。深さの失敗は幅の失敗とは質が違う。幅は検証側の帯域を飽和させる量的な失敗であり、深さは元の意図が薄れていく質的な失敗である。
上限値そのものに理論的根拠はない。フェーズによって最適値は変わる。この条件の本質は別のところにある。
連鎖は文脈をドリフトさせる。 タスクAがBを生み、BがCを生むうちに、元の意図は少しずつ薄れる。人間のチームで伝言ゲームが起きるのと同じ構造だ。
これは第2章で扱った「文脈汚染」とは逆向きの失敗である。汚染は、ひとつの文脈に複数の判断基準が混ざることで起きる。ドリフトは、各世代が自分の文脈にきれいに閉じているからこそ起きる。汚染を止めるための文脈分離が、連鎖させた瞬間にドリフトを生む。だから処方も逆になる。汚染には分離を、ドリフトには再接続を。
緩和は深さの可視化だけでは足りない。各世代が「最初のゴールは何だったか」を参照し続ける仕組みが必要だ。ルートの文脈を維持しないと、枝葉の最適化に走る。
5. 不可逆操作の隔離 ― 自律してよいのは取り消せる操作だけ
条件1〜4 はすべて「誤りを検出して止める」機構である。止めることに意味があるのは、止めた時点でまだ世界が変わっていない場合だけだ。事後チェックが効くのは、成果物が「まだ外に触れていない場所」に置かれているからである。
コード生成では、プルリクエストという待機場所がこれを暗黙に保証している。だから条件1〜4 だけで足りているように見える。メール送信・デプロイ・決済・外部API呼び出しを含む自律では、この前提が消える。
自律で実行してよいのは、取り消せる操作だけである。取り消せない操作は、結果ではなく実行そのものを人間の承認に通す。
これを条件1に混ぜてはいけない。条件1はAIの判断を含む。だが可逆性は、AIがリスクを評価して決める事柄ではない。操作そのものが持つ性質であり、推論なしに判定できる。推論に依存しない形で置ける安全弁を、推論に依存する条件の中に埋めない。条件3と同じ原則がここにも効く。
6. 自己権限の固定 ― 制約される側が制約を緩められない
条件5 は「取り消せない操作」を隔離した。だが取り消せる操作のなかにも、自律に渡せないものが残る。その操作が、AI自身の次の権限を増やす場合だ。
承認モードを「都度確認」から「自動実行」へ切り替える。ロールを昇格する。実行を許すコマンドの一覧に一行足す。新しい認証情報へのアクセスを与える。どれも設定を戻せる。状態遷移としては可逆である。それでも自律に渡せない。戻すまでのあいだに、承認を通さない実行が何回でもできるからだ。
操作が取り消せることと、その操作を自律に渡してよいことは、別の軸である。
可逆性は「その操作自体を元に戻せるか」を問う。権限増加は「その操作のあと、主体ができることが増えるか」を問う。二つは独立に決まり、可逆かつ権限増加という組み合わせは実在する。そこが最も危ない。可逆だという理由で自律の側に分類され、しかも一度通れば以降の安全弁が効かなくなる。
条件1〜5 はすべてAIの行動を制約する機構だ。権限の変更だけは、制約される側が制約そのものを書き換える操作になる。
制約される主体は、その制約を解除する権限を自分で発行できてはならない。
この条件は他の5つと階層が違う。条件1〜4 は1回の実行と繰り返しを制御し、条件5 は外の世界への効果を制御する。条件6 が制御するのは 条件1〜5 そのものだ。権限の変更を自律に許した時点で、他の5条件は「AIが必要と判断すれば外せるもの」に変わる。上限を書き換えられるなら、それは上限ではない。
判定は推論に依存しない。「この操作のあと、この主体ができることが増えるか」は操作の種別として機械的に分類できる。条件3・条件5 と同じ原則がここにも効く。安全弁は推論の外に置く。
実装では、権限を緩める方向の変更と厳しくする方向の変更を非対称に扱えばよい。緩める方向（都度確認 → 自動実行、ロール昇格、許可リストの拡張、認証情報の付与）だけを承認に通す。厳しくする方向は自律で構わない。安全側に倒す変更を止める理由はない。
この区別は公開実装でも表面化している。承認ゲートを持つエージェント実行環境で、設定ファイル経由で実行中の承認ゲートを緩められる経路が指摘され、修正された（local-operator #1282 → PR #1291）。制御プレーン経由の ask → auto を同じ境界として扱う提案（#1310）は、本稿執筆時点（2026-09-20）で未解決である。どちらも同一の報告者（@Nakagawa-master）による起票で、後者では "authority-increasing transition" と明示されている。本条件と同じ枠組みだ。第三者による独立の追認ではなく、同じ境界線を実装の側から引き直した例として読んでほしい。
追記（2026-10-12）: 上の「未解決」は2026-09-20時点の状態である。その後、#1310 は2026-09-21に完了として閉じられた。修正は報告者とは別の開発者が PR #1324 で実装し、v0.61.11 に収録されている。この追記が加えるのは、条件5（不可逆性）と条件6（制約される側が自分の権限を増やせない）を別の軸として扱う必要があったという論点に対する、後続の実装と配布の事実までである。本書全体の独立した検証ではなく、利用者一般にとっての安全性の証明でもない。上の段落の読み方も変わらない。
6条件が変えるのはスペクトラム上の位置
6条件は創発性を消さない。創発タスクを非創発タスクに変えるわけでもない。壊れ方を制御するだけだ。
そのうえでスペクトラム上の位置は動く。ここで一度整理しておく。本書がここまで使ってきた「創発性が高いほど」という言い方は、正確には「解の形を事前に固定しにくいほど」である。創発かどうか ― 答えが事前に決まっていないかどうか ― は二値である。スペクトラムを作っているのは別の軸だ。
答えが事前に決まっていないこと（＝創発）は二値である。連続するのは「答えが入る形を、事前にどこまで固定できるか」だ。
- 形も固定できない（設計判断・要件定義・戦略）→ 伴走。何が正解かを判定する基準そのものを人間が作る段階であり、事後チェックの軸が書けない。構造で代替できないのは人間が賢いからではなく、チェックを定義できないからだ
- 答えは未定だが形は既定（パターンに沿ったコード生成・既存構造への追加）→ 自律 ＋ ガードレール。実装は事前に決まっていないので創発である。だが言語・既存構造・テストが通ること・レビューで判定できることは事前に決まっている。6条件が効くのはこの帯だ
- 答えが事前に決まっている（定型処理・集計・既知パターンの適用）→ そもそも創発ではない。完全自律
「創発タスクは伴走一択」ではない。解の形を事前に固定できる範囲を、ガードレール付きの自律に移せる。実務で自律化の余地が最も大きいのはこの帯だ。
この構造は開発基盤に限らない。人間とAIが同列に参加する協働ハブを運用しても、同じ6条件が現れる。
- どの操作を自律実行してよいかを事前に決める（事前リスク判定）
- 変更は必ず別の役割のレビューを通してから反映する（事後構造チェック）
- 判断が往復し続けるときは人間にエスカレートする（ループ上限）
- 自動生成されたタスクが次のタスクを生む深さに上限を置く（連鎖上限）
- 取り消せない操作は、結果ではなく実行そのものを承認に通す（不可逆操作の隔離）
- 権限を階層に分け、自分の権限を自分で引き上げられない構造にする（自己権限の固定）
実装は違うが、構造は同じだ。6条件は特定の実装の工夫ではなく、創発タスクを自律で回すための構造要件である。
そして、構造の追加には上限がある。6条件は足せば足すほど安全になる類のものではない。ガードレールは壊れ方を制御すると同時に、AIが動ける範囲を狭める。条件を増やし続ければ、最後には「答えが事前に決まっている手続き」だけが残る。それは創発を安全にしたのではなく、創発を捨てたのだ。構造の適量は、解の形を固定できる範囲まで。そこを超えて構造を足すのは、伴走に戻すべきタスクを自律のまま握り続けている兆候である。
次章への橋渡し：非創発 × 自律の最適解が「レポート化」になる
非創発タスクの大半はすでにパターン化されている。 創発を必要としない。 つまり自律型で安定運用できる。
そして非創発 × 自律の最適解が、 次章で扱う 「レポート化アーキテクチャ」 である。
この章のまとめ
- 創発タスクと非創発タスクの境界線を先に引くことが設計の出発点
- 自律性は二項対立ではなくスペクトラムである
- 創発性が高いほど、HITL側に寄せないと安定しない
- Devin問題が示したのは、創発の無限性をAI単体では制御できないこと
- 非創発タスクは手順が固定しており、外部化・テンプレート化・事前計算が最適
- 実務の大半はスペクトラムの「間」にある。創発性とリスクに応じてHITLの強度を調整する
- HITLの代わりに構造を置けば、創発タスクでも自律の範囲は広げられる。必要な構造条件は6つ（事前リスク判定・事後構造チェック・ループ上限・連鎖上限・不可逆操作の隔離・自己権限の固定）
- 可逆であることは自律に渡してよい理由にならない。制約される主体が、その制約を解除する権限を自分で発行できてはならない
- 人間に回すべき操作は事前に列挙できる。列挙したものをルールで人間側へ倒し、残りは自律で回す
- 安全弁はシンプルであることが価値。安全弁に知性を入れると安全弁自体が壊れる
- 創発かどうかは二値。連続するのは「解の形を事前にどこまで固定できるか」であり、構造を足せるのもその範囲までである
次章（第6章）は、 データ分析の本丸：レポート化アーキテクチャ に進む。
ここでシリーズ全体の"実務的インパクト"が最大化される。
Last Updated: 2026-09-20