第10章　自分で仕事を見つけるAI

10.1　導入：サーモスタットは自律か

エアコンのサーモスタットを考える。

設定温度を25℃にしておくと、サーモスタットは次の動作を繰り返す。

  1. 室温を測定する
  2. 設定温度との差を計算する
  3. 室温が高ければ冷房を動かす、設定温度に近ければ止める
  4. 手順1に戻る

人間は最初に「25℃にしてくれ」と設定するだけで、あとはサーモスタットが自分で判断して動く。毎分「今は27℃だから冷房をつけろ」「25℃になったから止めろ」と指示する必要はない。

このサーモスタットを「自律している」と言えるだろうか。

一見すると、ルールに従っているだけに見える。しかし、「目標値と現状を比較し、差に応じて自分で次の行動を決める」という構造は、まさに自分で判断して動いていると言える。しかも、設定温度という共有されたルールの範囲内で動いている。暖房に切り替えたり、窓を開けたりはしない。

ここに、本章で扱う「自律」の本質がある。

自律（autonomous）とは、自由放任ではない。共有されたルールの中で、自分の次の行動を自分で見つけることである。

第7章で導入したサブエージェント、第8章で設計した依存関係、第9章で整えた通信プロトコル——これらの仕組みがあっても、毎回リードが指示を出すのでは規模が拡大しない。タスクが10個、20個と増えれば、リードが1つずつ割り振るのはボトルネックになる。

では、担当が自分で掲示板を見て、次にやるべき仕事を取りに行く仕組みにできないか。本章ではその設計を学ぶ。

10.2　自律とは何か

「自律」と聞くと、「何でも自由にやる」という意味に受け取りがちである。しかし、AI の設計における自律は、それとはまったく違う。

2つの対比で考える。

flowchart LR
  subgraph X["❌ 自由放任"]
    direction TB
    X1["ルールなし<br>何をやるかは自分次第"]
    X2["衝突・重複・暴走の危険"]
    X1 --> X2
  end
  subgraph O["✅ ルール内の自律"]
    direction TB
    O1["共有ルールあり<br>その範囲で自分が判断する"]
    O2["整然とした自発性"]
    O1 --> O2
  end
  style X fill:#f8d7da,stroke:#dc3545
  style O fill:#d4edda,stroke:#28a745

自由放任とルール内自律の対比

「ルール内の自律」が成り立つために必要な条件を整理する。

表 1: 自律に必要な5つの条件
条件 意味 なければどうなるか
共有タスク表 何の仕事があるか見える 何をすべきか分からない
状態表示 各タスクの進捗が分かる 終わった仕事を重複して取る
依存関係 どのタスクが着手可能か分かる 前提が揃っていないタスクに着手して失敗する
役割 自分が取ってよいタスクの範囲が分かる 専門外の仕事を取って品質が下がる
停止条件 いつ止まるべきか分かる 永遠に動き続ける、または無駄な作業を続ける

サーモスタットの言葉で言い換えると、次のようになる。

  • 共有タスク表 → 室温の表示（現状が見える）
  • 状態表示 → 冷房の稼働ランプ（いま動いているか分かる）
  • 依存関係 → 設定温度との差の計算（判断の根拠がある）
  • 役割 → 冷房のみ。暖房には切り替えない（範囲が限定されている）
  • 停止条件 → 設定温度に達したら止まる

自律は AI の「知能の高さ」によって実現するのではない。環境が適切に整備されているから実現する。掲示板がなく、状態が見えず、依存関係も不明な状況では、どんなに賢い AI でも自律的に動けない。

ノート自律は便利だが、ルールの質が自律の質を決める

自律エージェントの性能は、AI の能力だけでは決まらない。共有タスク表、状態表示、依存関係、役割定義、停止条件——これらの環境設計の質が自律の質を決める。よい掲示板のないところに自律はない。

10.3　WORK と IDLE の2相ループ

自律エージェントは「常に全力で働く」わけではない。仕事があるときとないときがある。これを2つの相（phase）で表現する。

stateDiagram-v2
    IDLE : IDLE（待機中）
    WORK : WORK（作業中）
    SHUTDOWN : SHUTDOWN（終了）

    [*] --> IDLE
    IDLE --> WORK : 仕事を見つけた
    WORK --> IDLE : 仕事が終わった
    IDLE --> SHUTDOWN : 一定時間何もなし
    WORK --> SHUTDOWN : すべて完了

自律エージェントのWORK/IDLEループ

図: WORK/IDLE 2相ループの状態遷移図

各相の役割を整理する。

IDLE（待機中）：作業は行わず、定期的に次の2つを確認する。

  1. 受信箱（第9章）にメッセージが届いていないか
  2. タスクボードに自分が取れる仕事がないか

どちらかが見つかれば、WORK 相に移る。

WORK（作業中）：タスクを実行する。完了したら、結果を報告し、IDLE 相に戻る。

SHUTDOWN（終了）：IDLE 相で一定時間（たとえば60秒）何も見つからなければ、自ら終了する。

この「止まる設計」が重要である。停止条件がなければ、エージェントはいつまでも IDLE 相でタスクボードを見続け、無駄に動き続ける。サーモスタットにたとえれば、「夏が終わって冷房が不要になったら電源を切る」に対応する。

物理実験で言えば、データ収集装置の動作と同じ構造である。

表 2: 2相ループとデータ収集装置の対応
2相ループ データ収集装置
IDLE（待機） トリガー待ち（信号が来るまで待つ）
WORK（作業） 信号を検出→データを記録する
SHUTDOWN（終了） 測定完了→電源を切る

常にフル稼働するのではなく、仕事がなければ待ち、仕事があれば動き、すべて終われば止まる——この設計が、自律エージェントの基本構造である。

10.4　タスクボードと自動取得

自律エージェントが仕事を見つけるための中心的な仕組みがタスクボードである。第4章の ToDo 板と似ているが、複数の担当が共有する点が異なる。

タスクボードには、各タスクについて次の情報が書かれている。

表 3: タスクボードの項目
項目 意味 例
タスクID タスクの識別番号 T-005
内容 何をするか グラフを作成する
状態 pending / in_progress / completed pending
担当者 誰が取ったか（未取得なら空欄） （空欄）
依存 どのタスクの完了が前提か T-003

エージェントが IDLE 相でタスクボードを確認したとき、自分で取ってよい仕事の条件は次の通りである。

  1. 状態が pending（未着手）であること
  2. 担当者が 未設定であること（誰もまだ取っていない）
  3. 依存するタスクが すべて完了していること
  4. 自分の役割で扱ってよい範囲であること

この4条件をすべて満たすタスクだけを取りに行く。これを自動取得（auto-claim）と呼ぶ。

graph TD
  T1["T-001 データ整理<br>✅ completed（調査担当）"]
  T2["T-002 グラフ作成<br>⏳ pending"]
  T3["T-003 考察メモ<br>⏳ pending"]
  T4["T-004 表紙作成<br>⏳ pending"]
  T5["T-005 参考文献整理<br>🔄 in_progress（構成担当）"]
  T1 -->|"依存 ✓"| T2
  T2 -->|"依存 ✗"| T3
  CLAIM["構成担当が取れるタスク：<br><b>T-004</b>（依存なし・未着手）"]
  T4 -.->|"取得可能"| CLAIM
  style T1 fill:#d4edda,stroke:#28a745
  style T2 fill:#fff3cd,stroke:#ffc107
  style T3 fill:#f8d7da,stroke:#dc3545
  style T4 fill:#fff3cd,stroke:#ffc107
  style T5 fill:#d1ecf1,stroke:#17a2b8
  style CLAIM fill:#e2e3f1,stroke:#6c757d,stroke-dasharray:5

タスクボードと取得可能なタスクの判定

注意すべき点がある。自動取得は万能ではない。

  • タスクの数が少なく、リードが直接割り振れるなら、わざわざ自動取得にする必要はない
  • 高リスクな操作（提出、削除、大幅な方針変更）は自動取得ではなく、第9章の承認プロトコルを通すべきである
  • 全員が同じタスクを同時に取ろうとする競合が起きうる。先に取った方が担当になるルールを決めておく必要がある

自律は「命令不要」を意味するのではなく、命令の粒度を下げることを意味する。大枠の目標と全体計画はリード（または人間）が設定し、具体的な1つ1つのタスクの割り振りを、各担当が自分で判断する。

10.5　同一性の維持問題

自律エージェントが長時間動き続けると、予想外の問題が起きる。自分が誰で、何の役割かを忘れるのである。

第6章で学んだ文脈圧縮を思い出してほしい。会話や作業の履歴が長くなると、AI は古い情報を要約して圧縮する。このとき、作業の詳細だけでなく、自分の役割情報まで圧縮されてしまうことがある。

たとえば、調査担当として30分間動き続けた後、文脈圧縮が起きたとする。圧縮後の要約に「調査担当として動いている」という情報が欠落すると、エージェントは次の IDLE 相で何を基準にタスクを選べばよいか分からなくなる。

人間でも同じことが起きる。長いシフト勤務で交代した後や、数日ぶりに中断した仕事を再開するとき、最初にやることは何か。

  • 自分の担当は何か
  • どこまで進んでいたか
  • 次に何を見るべきか

これを確認してから作業を再開する。AI でも同じ仕組みが要る。

この仕組みを同一性の再注入（identity re-injection）と呼ぶ。具体的には、文脈圧縮が起きた後に、次のような情報をエージェントの文脈の先頭に書き戻す。

表 4: 同一性の再注入に含める情報
項目 内容
名前 調査担当
役割 テーマに関する情報を集め、方針案をリードに提出する
チーム レポート作成チーム
参照すべき場所 タスクボード、受信箱

平たく言えば、「名札を付け直す」ことである。

名札の付け直しが不要なのは、作業が短時間で終わる場合だけである。長時間にわたる自律的な作業では、文脈圧縮のたびに「自分は誰で、何をしていて、次に何を見るべきか」を再設定する仕組みが不可欠になる。

10.6　フィードバック制御との対応

ここまでの概念を、10.1節のサーモスタットに立ち戻って整理する。

サーモスタットはフィードバック制御の最も単純な例である。目標値と現在値の差（偏差）に応じて出力を調整し、差をゼロに近づける。この構造は、自律エージェントの設計とそのまま対応する。

表 5: フィードバック制御と自律エージェントの対応
フィードバック制御の要素 サーモスタットでの実現 自律エージェントでの実現
目標値 設定温度（25℃） チーム全体の目標（レポートを完成させる）
測定 室温を測る タスクボードと受信箱を確認する
偏差の計算 室温と設定温度の差 「取れる仕事があるか」の判定
制御出力 冷房を動かす/止める タスクを取って作業する/待機する
動作範囲 冷房のみ（暖房には切り替えない） 自分の役割の範囲内で動く
停止条件 設定温度に達したら止まる すべてのタスクが完了したら終了する 

flowchart TD
  subgraph S["🌡️ サーモスタット"]
    direction TB
    S1["設定温度"] --> S2["偏差を計算<br>(室温 − 設定)"]
    S2 --> S3{"差はあるか？"}
    S3 -- "差あり" --> S4["冷房ON"]
    S3 -- "差なし" --> S5["冷房OFF"]
    S4 --> S6["室温を再測定"]
    S5 --> S6
    S6 --> S2
  end
  subgraph A["🤖 自律エージェント"]
    direction TB
    A1["全体目標"] --> A2["タスクボード<br>を確認する"]
    A2 --> A3{"仕事はあるか？"}
    A3 -- "仕事あり" --> A4["WORK"]
    A3 -- "仕事なし" --> A5["IDLE"]
    A4 --> A6["結果を報告、再確認"]
    A5 --> A6
    A6 --> A2
  end
  style S fill:#fff3cd,stroke:#ffc107
  style A fill:#d1ecf1,stroke:#17a2b8

サーモスタットと自律エージェントの構造対応図

この対応から見えてくるのは、自律エージェントが高度な知能を必要としないという事実である。サーモスタットに「知能」があるとは言わない。しかし、目標・測定・判断・制御の4要素が揃えば、自分で次の行動を決めることができる。

AI の自律も同じ構造である。「AI が自分で仕事を見つける」と聞くと高度な知的能力を想像しがちだが、実際に行われているのは定期的にタスクボードを見て、条件に合うタスクを取るという、サーモスタットと同じ水準の判断ループである。

最小形式の自律では、高度な知能を仮定しない。難しさは判断の高度さよりも、環境の設計——タスクボードの整備、状態表示の正確さ、依存関係の設計、停止条件の設定——にある。

10.7　手順で見る：2相ループとタスクボード

10.3〜10.4節の概念を、手順モデルとタスクボードの状態変化で確認する。

手順モデル：自律エージェントの2相ループ

  1. タスクボードを確認する
  2. 取得可能なタスク（pending・担当なし・依存完了）があるか判定する
  3. ある場合（WORK相）：タスクを取得し、作業を行い、完了にする。IDLEカウンタをリセットし、1に戻る
  4. ない場合（IDLE相）：IDLEカウンタを1つ増やす。1に戻る
  5. IDLEカウンタが上限に達したらSHUTDOWN（終了）
  6. 仕事をした後にカウンタをリセットする点が重要。サーモスタットが冷房を動かした後、再び室温の監視に戻るのと同じ構造である

この手順で、8.6節のタスクボード（T-001〜T-005）を構成担当が処理する流れを追うと、次のようになる。

表 6: 自律ループの実行例
ステップ 相 行動 タスクボードの変化
1 WORK T-002（グラフ作成）を取得・完了 T-001完了済み → T-002の依存を満たす
2 WORK T-003（考察メモ）を取得・完了 T-002完了 → T-003の依存を満たす
3 WORK T-004（表紙作成）を取得・完了 依存なし → 取得可能
4 WORK T-005（参考文献整理）を取得・完了 依存なし → 取得可能
5〜7 IDLE 取れるタスクなし（3回連続） 全タスク完了済み
8 SHUTDOWN 終了 —

手順の要点を整理する。

  1. 取得可能かどうかの判定は10.4節の4条件のうち3つ（pending・担当なし・依存完了）で行う
  2. T-001（データ整理）が completed のため、T-002（グラフ作成）は最初から取得可能。T-003（考察メモ）は T-002 の完了を待ってから取得可能になる
  3. すべてのタスクが完了した後、IDLE が3回続くと SHUTDOWN に至る。これが10.3節の停止条件に対応する

10.8　第11章への橋渡し

本章では、自律エージェントの設計を学んだ。自律とは自由放任ではなく、共有ルールの中で自分の次の行動を見つける仕組みである。WORK/IDLE の2相ループでタスクボードを監視し、条件に合うタスクを自動取得し、仕事がなくなれば停止する。

ここまでで、後半の構造が一通り揃った。

  • 第7章：役割分担（サブエージェント）
  • 第8章：依存関係の設計と並列化
  • 第9章：通信プロトコル
  • 第10章：自律（自分で仕事を見つける）

しかし、自律エージェントが複数同時に動く状況を考えると、新たな問題が浮かぶ。

たとえば、2つの担当が別々のタスクとして同じファイルを編集したらどうなるか。一方の変更がもう一方を上書きしてしまう。2人が同じ実験ノートの同じページに同時に書き込めば、どちらかの記録が消える。

これは作業空間の衝突の問題である。タスクの分担が正しく、通信も整い、自律的に動ける——それでも、同じ場所で同時に作業すれば干渉が起きる。

次の第11章では、互いの作業を邪魔しない作業空間の分離を扱う。物理実験で「別々の実験台で作業する」ことが干渉を防ぐように、AI にも別々の作業空間を与える設計を学ぶ。

演習：掲示板を見て、自分で仕事を取るAI班を演じる

形式：4〜6人1組、30分

役割：次の役を割り振る（人数に応じて兼任してよい）。

表 7: 演習の役割一覧
役割 仕事内容
リード 最初に全体目標だけを示す。個別の割り振りはしない
調査担当 テーマに関する情報を集める
構成担当 調査結果をもとに構成を設計する
点検担当 成果物を確認し、問題があれば差し戻す
記録係 タスクボードの変化を時系列で記録する
監査係 ルール違反（条件を満たさないタスクの取得等）を指摘する

テーマ：以下から1つ選ぶ。

  • 「高校生向けに”運動量保存”の説明ミニ教材を完成させる」
  • 「大学祭の出し物の企画書を仕上げる」
  • 「研究室の安全マニュアルを改訂する」

準備物：

  • 黒板や模造紙にタスクボードを作る。各タスクに以下の欄を設ける
欄 記入内容
タスクID T-001, T-002, …
内容 何をするか
状態 pending / in_progress / completed
担当者 取った人の名前（初期は空欄）
依存 どのタスクの完了が前提か
  • 各自に役割カードを配る（名前・役割・担当範囲を記載）

ルール：

  1. リードは全体目標だけを示す。「○○さんはこれをやって」という個別指示はしない
  2. 各担当はタスクボードを見て、未担当・依存解決済み・自分の役割の範囲内のタスクだけを取れる
  3. タスクを取ったら、タスクボードの担当者欄に自分の名前を書く
  4. 完了したら、状態を completed に変え、依存していた後続タスクが着手可能になる
  5. 10分経過時点で「中断カード」を配る。受け取った担当は、自分の役割カードを見直し、「自分は誰で、何をしていたか」を確認してから再開する（同一性の再注入の体験）
  6. 一定時間タスクボードに動きがなければ、その担当は IDLE とみなす

振り返りの問い：

  • リードが個別に指示しなくても、掲示板があれば動けたか
  • 依存関係があるタスクを、焦って取りそうになった場面はあったか
  • 中断カードで役割を見直したとき、何が思い出しにくかったか
  • もし掲示板がなかったら、同じ作業は成り立ったか
  • 自律で得をしたのはどこか。逆に、リードの指示があった方がよかった場面はどこか

発展（アプリで試す）：Codex App で、3つのタスクをタスクボードとして整理し、2つのスレッドにそれぞれ「取得可能なタスクがあれば着手し、完了したら報告せよ」と指示せよ。どのタスクがどの順で処理されたかを記録し、依存関係が守られたかを確認せよ。

章末課題

課題：自分の課題を「自律的に動けるAIチーム」用に再設計する

今学期の課題や研究活動から、数日以上かかる作業を1つ選び、自律エージェントチームの設計書を作成せよ。

想定する作業の例：

  • 実験レポートの完成
  • 発表資料の作成
  • 卒研の文献整理
  • 就活準備書類の作成

必須項目：

  1. 全体目標：何を完成させるか（1〜2文）
  2. チーム構成と役割：3〜5名の担当と、各担当の役割範囲
  3. 共有タスク表：6〜10個のタスクを、以下の項目で記述する
    • タスクID、内容、初期状態、依存関係
  4. 自動取得の条件：どの条件を満たせば担当が自分でタスクを取ってよいか（10.4節の4条件を参考に）
  5. 人間の承認が必要な場面：自動取得ではなく、承認プロトコル（第9章）を通すべき操作を特定する
  6. 2相ループの設計：
    • IDLE 相で確認する対象（タスクボード、受信箱）
    • IDLE から WORK への遷移条件
    • SHUTDOWN の条件（何回の IDLE で終了するか）
  7. 同一性の再注入：長時間動作した後に「名札を付け直す」ために、どんな情報を書き戻すか

提出形式：設計書（A4で2枚程度）。タスクボードの図と2相ループの図を含めること。

評価観点：

  • 自律の条件（タスクボード・状態・依存・役割・停止条件）が具体的に設計されているか
  • 自動取得の条件が妥当か（取ってはいけないタスクを取らない設計になっているか）
  • 承認が必要な操作が正しく特定されているか（高リスク操作の判断基準）
  • 停止条件が明示されているか（永遠に動き続けない設計か）
  • 同一性の再注入が具体的に設計されているか
  • 第8章（依存関係）、第9章（通信プロトコル）の考え方と整合しているか

第10章のまとめ

本章では、自律（autonomous）——共有ルールの中で自分の次の行動を見つける仕組み——を学んだ。

要点を整理する。

  1. 自律は自由放任ではない。サーモスタットが設定温度の範囲内で自動的に動作するように、共有されたルールの中で自分の次の行動を自分で判断する設計である
  2. 自律に必要な5条件は、共有タスク表・状態表示・依存関係・役割・停止条件。これらの環境設計の質が自律の質を決める
  3. 自律エージェントは WORK/IDLE の2相ループで動く。仕事があれば WORK、なければ IDLE で待機し、一定時間何もなければ SHUTDOWN する
  4. タスクボードから仕事を自動取得（auto-claim）するには、pending・担当なし・依存完了・自分の役割の範囲内、の4条件を満たす必要がある
  5. 長時間動作すると文脈圧縮で役割を忘れうるため、同一性の再注入（名札の付け直し）が必要になる
  6. 自律の構造はフィードバック制御と同じである。目標値と現状の差を測定し、差に応じて行動する。AI の高度な知能ではなく、環境の適切な設計によって自律は実現する

次の第11章では、自律エージェントが複数同時に動くときに起きる作業空間の衝突を防ぐ方法を扱う。