第8章　仕事を分解し、依存を設計する

8.1　導入：実験の工程を並べてみる

物理実験のレポートを仕上げるまでの工程を考える。

  1. 測定データを整理する
  2. グラフを作成する
  3. 考察を書く
  4. 参考文献を整理する
  5. 表紙を作る
  6. 全体を結合して提出する

この6つを、上から順に1つずつ片づけていく——これが最も単純なやり方である。しかし、よく見ると全部を直列に並べる必要はない。

グラフの作成（2）はデータ整理（1）が終わらないと始められない。考察（3）はグラフ（2）がないと書けない。しかし、参考文献の整理（4）や表紙の作成（5）は、データ整理を待たなくても今すぐ始められる。

flowchart LR
    T1["①データ整理"] --> T2["②グラフ作成"]
    T2 --> T3["③考察"]
    T3 --> T6["⑥結合・提出"]
    T4["④参考文献整理"] --> T6
    T5["⑤表紙作成"] --> T6

実験レポートのタスクと依存関係

この図を見ると、④と⑤は①〜③と同時に進められることがわかる。全部を直列に並べた場合に比べて、総時間が短くなる可能性がある。

ここから2つの問いが生まれる。

  • どの仕事が、どの仕事の完了を待っているか（依存関係）
  • 待っている間に、別の仕事を進められないか（並列化）

第4章では ToDo 板でタスクの「状態」を管理した。本章では、タスクの「関係」——依存関係——を設計する方法を学ぶ。

8.2　タスクの依存関係とは

仕事を小さな単位に分けたものをタスク（task）と呼ぶ。第4章の ToDo 項目と似ているが、本章ではタスク同士の前後関係——依存関係——に注目する。

依存関係とは、「タスク A が完了しないと、タスク B に着手できない」という制約である。これを矢印で表す。

\[ t_A \to t_B \tag{1}\]

この矢印は「\(t_A\) が \(t_B\) の前提条件である」と読む。8.1節の例では、次の依存関係がある。

\[ t_1 \to t_2 \to t_3 \to t_6 \]

\[ t_4 \to t_6, \quad t_5 \to t_6 \]

一方、\(t_1\) と \(t_4\) の間には矢印がない。つまり、この2つは互いに依存しておらず、どちらを先にやってもよいし、同時に進めてもよい。

タスクの集合と依存関係をまとめたものを依存グラフと呼ぶ。

flowchart LR
    T1["①データ整理"] --> T2["②グラフ作成"]
    T2 --> T3["③考察"]
    T3 --> T6["⑥結合・提出"]
    T4["④参考文献整理"] --> T6
    T5["⑤表紙作成"] --> T6
図 1: 実験レポートの依存グラフ

この図が「仕事の地図」である。単なる一覧表（ToDo 板）とは違い、矢印がついている。矢印は「この順序を守れ」という制約であり、同時に「矢印がない組は並列化できる」という自由を示している。

8.3　半順序の直感的理解

依存グラフには、数学的に「半順序」（partial order）と呼ばれる構造がある。名前は難しく聞こえるが、考え方は単純である。

2つの並べ方を比較する。

全順序（total order）：すべてのタスクに1列の順番がつく。

flowchart LR
  T1["①"] --> T2["②"] --> T3["③"] --> T4["④"] --> T5["⑤"] --> T6["⑥"]

全順序：すべてのタスクが一列に並ぶ

この場合、どの2つを取っても「どちらが先か」が決まっている。

半順序（partial order）：一部のタスクの間にだけ順番がある。順番がつかない組もある。

flowchart LR
  T1["①"] --> T2["②"] --> T3["③"] --> T6["⑥"]
  T4["④"] --> T6
  T5["⑤"] --> T6

半順序：一部のタスクは並列に進められる

この場合、①と②の間には「①が先」という順番がある。しかし、①と④の間には順番がない。順番がつかない組は、同時に進めてよい。

物理の言葉を借りれば、全順序は「一本道」、半順序は「分岐と合流のある道」である。

表 1: 全順序と半順序の比較
比較 全順序 半順序
イメージ 一本道 分岐と合流のある道
任意の2タスクに順序がある はい いいえ（順序なしの組がある）
並列化の余地 なし 順序なしの組を同時に進められる
安全性 高い（順序違反が起きない） 順序を守る設計が必要

全順序（全部直列）は安全だが遅い。半順序を活かせば、依存を守りつつ並列化できる。ただし、順序のない組を無秩序に進めると混乱するため、設計が必要になる。

ノート依存関係の設計が並列化の鍵

「全部直列にすれば安全」は正しいが遅い。「全部同時にすれば速い」は依存を無視すると破綻する。並列化とは、依存関係を正しく設計したうえで、順序のない組を見つけ出し、そこだけを同時に進める技術である。

8.4　依存から実行順序を導く

依存グラフがあれば、「いま何ができるか」を機械的に判断できる。手順は次の通りである。

手順：依存を満たしたものから順に実行する

  1. すべてのタスクを「未着手」にする
  2. 前提条件がすべて完了しているタスクを探す（= いま着手可能なタスク）
  3. 着手可能なタスクを実行する（複数あれば同時に進めてよい）
  4. 完了したタスクを「完了」に移す
  5. 手順2に戻る。着手可能なタスクがなくなれば終了

8.1節の例で手順を追う。

段階1：前提なしで始められるタスクを探す。

  • ①データ整理：前提なし → 着手可能
  • ④参考文献整理：前提なし → 着手可能
  • ⑤表紙作成：前提なし → 着手可能

3つを同時に着手できる。

段階2：①が完了したとする。

  • ②グラフ作成：前提は①のみ → ①完了 → 着手可能

④や⑤がまだ進行中でも、②を始められる。

段階3：②が完了。

  • ③考察：前提は②のみ → ②完了 → 着手可能

段階4：③④⑤がすべて完了。

  • ⑥結合・提出：前提は③④⑤ → すべて完了 → 着手可能

タイムラインで比較すると、違いが明らかになる。

gantt
    dateFormat YYYY-MM-DD
    axisFormat %d日目
    todayMarker off
    section 全部直列
    ①データ整理    :a1, 2024-01-01, 1d
    ②グラフ作成    :a2, after a1, 1d
    ③考察          :a3, after a2, 1d
    ④参考文献      :a4, after a3, 1d
    ⑤表紙作成      :a5, after a4, 1d
    ⑥結合・提出    :a6, after a5, 1d
    section 並列化
    ①データ整理    :b1, 2024-01-01, 1d
    ②グラフ作成    :b2, after b1, 1d
    ③考察          :b3, after b2, 1d
    ④参考文献      :b4, 2024-01-01, 3d
    ⑤表紙作成      :b5, 2024-01-01, 3d
    ⑥結合・提出    :b6, after b3, 1d

直列と並列のタイムライン比較

並列化により、④と⑤の時間が①〜③の裏に隠れ、全体の時間が短くなる。

8.5　待ち時間を別処理にする

8.4節の並列化に加え、もう1つ重要な考え方がある。長い処理を裏で走らせ、その間に別の仕事を進める——バックグラウンドタスク（background task）である。

実験で例える。データ変換プログラムを走らせると5分かかるとする。その5分間、画面の前で座って待つのは無駄である。待っている間に、参考文献を調べたり、表紙を整えたりできる。

AI の仕事でも同じことが起きる。テストの実行、ファイルの検索、大量のデータの処理——こうした「時間はかかるが、途中で人間の判断は要らない」作業は、裏で走らせておき、結果が出たら回収すればよい。

ただし、裏で走らせたら放置してよいわけではない。結果を追跡し、回収する仕組みが必要である。具体的には、次の3つを管理する。

  1. 識別子（ID）：どの裏作業か区別するための番号
  2. 状態：実行中か、完了か、失敗か
  3. 結果の回収：完了したら、結果を取り出して本流に戻す
flowchart TD
    A["データ変換を裏で開始<br>ID=bg-001 を記録"] --> B["待っている間に<br>参考文献を整理する"]
    B --> C["bg-001 が完了<br>結果を回収"]
    C --> D["変換結果を使って<br>グラフを作成する"]
図 2: 裏タスクの実行フロー

どんな作業を裏で回し、どんな作業は前面でやるべきかの判断基準を整理する。

表 2: 裏で回す作業と前面でやる作業の判断基準
観点 裏で回しやすい作業 前面でやるべき作業
所要時間 長い（数分以上） 短い
途中の判断 不要 途中で方針変更が必要
結果の扱い 完了後に回収すればよい 結果を見ながら次を決める
他タスクとの関係 独立している 他タスクと強く結びつく
失敗時の影響 小さい（やり直せる） 大きい（後続が全部止まる）

8.6　手順で見る：依存グラフから実行順序を導く

8.2〜8.4節の概念を、段階表で確認する。判定の原則は1つだけである。前提条件がすべて完了していれば、そのタスクは着手可能。この判定を繰り返すだけで、依存グラフから実行順序が導かれる。

8.3節の依存グラフに基づき、段階ごとに着手可能なタスクを列挙すると次のようになる。

表 3: 依存グラフに基づく実行順序
段階 着手可能なタスク 判定の理由
1 データ整理、参考文献整理、表紙作成 いずれも前提なし → 最初に着手可能
2 グラフ作成 前提の「データ整理」が段階1で完了
3 考察 前提の「グラフ作成」が段階2で完了
4 結合・提出 前提の「考察」「参考文献整理」「表紙作成」がすべて完了

段階1で3つが同時に着手可能と判定され、段階4で全タスクが完了する。8.4節の手順をそのまま表にしたものである。

この段階表の核心は「前提がすべて完了しているか」の判定1つだけにある。この判定を繰り返すだけで、どんな依存グラフでも実行順序を導ける。

8.7　第9章への橋渡し

本章では、タスクの依存関係を設計し、並列化とバックグラウンド処理で効率を上げる方法を学んだ。

ここまでの道具を振り返る。第7章でサブエージェント（別担当）を導入し、本章でタスク間の依存関係と並列化を設計した。複数の担当が、それぞれのタスクを、依存関係に基づいた順序で進める——この仕組みが整ったことになる。

しかし、ここで新たな問題が浮かぶ。担当同士はどうやって連絡を取るのか。

第7章のサブエージェントは、司令塔に要約を返すだけの一方通行であった。しかし、複数の担当が協調して仕事を進めるとき、「調査結果をもとに構成を変えたい」「点検で見つかった問題を調査担当に差し戻したい」といった相互のやり取りが必要になる。

口頭で「よろしく」と言うだけでは、誰が何を頼んだか、返事はどれへの応答か、承認されたのか保留なのかが曖昧になる。物理実験で危険な操作を口頭だけで伝達したら事故の元である。

次の第9章では、AI 同士の連絡に必要なプロトコル——構造化された通信の型——を扱う。

演習：付箋でタスクグラフを作り、待ち時間を埋める

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

テーマ：以下から1つ選ぶ（または自分で設定してよい）。

  • 「5分の科学紹介プレゼンを完成させる」
  • 「学園祭の出し物の企画書を仕上げる」
  • 「グループレポートを完成させて提出する」

手順：

  1. タスク分解（10分）

    選んだテーマの仕事を6〜10個のタスクに分解し、付箋に書く。各付箋に次の3項目を記入する。

    表 4: 付箋の記入項目
    項目 記入内容
    タスク名 動詞＋対象（第4章の書き方）
    完了条件 何をもって「終わり」とするか
    状態 未着手・進行中・完了・待機中のいずれか

  2. 依存関係の設計（10分）

    付箋を机に並べ、依存関係がある組を矢印（テープや線）でつなぐ。その後、次の3つに分類する。

    表 5: タスクの分類
    分類 意味
    今すぐ着手可能 前提条件がない、または前提がすべて完了
    結果待ち 他のタスクの完了を待っている
    裏で回せる 時間はかかるが判断不要で、他と独立

  3. イベントカードへの対応（10分）

    教員が途中で次のようなカードを配る。グループはタスクグラフを更新する。

    • 「バックグラウンドタスク A が完了した」→ 後続タスクが着手可能になる
    • 「バックグラウンドタスク B が失敗した」→ やり直しタスクを追加し、後続を「待機中」に戻す
    • 「新しい要件が追加された」→ タスクを追加し、依存関係を引き直す

振り返りの問い：

  • 依存関係を矢印で書いたことで、「同時に進められる仕事」が見えたか
  • 完了条件がないタスクがあった場合、何が困ったか
  • バックグラウンドタスクが「失敗」したとき、どこまで影響が波及したか
  • 全部を直列に並べた場合と比べて、どれくらい時間が短縮できそうか

発展（アプリで試す）：Claude Desktop で、同じプロジェクト内に2つのチャットを開き、片方に「文献調査」、もう片方に「表紙作成」を依頼せよ（この2つは依存関係がなく同時に進められる）。両方の結果が揃ってから、3つ目のチャットで統合させよ。

章末課題

課題：自分の現実の課題を、タスクグラフ＋バックグラウンド実行計画に変換する

今学期の課題から、数日以上かかるものを1つ選び、依存関係つきのタスクグラフを設計せよ。

想定する作業の例：

  • 実験レポートの完成
  • プレゼン準備
  • 卒研の文献調査
  • インターン応募書類の作成

必須項目：

  1. 全体目標：何を完成させるか（1〜2文）
  2. タスク分解（6〜10個）：各タスクについて以下を記述する
    • タスク名（動詞＋対象＋完了条件）
    • 依存関係（どのタスクの完了が前提か。前提なしの場合は「なし」）
    • 初期状態（未着手・着手可能・待機中のいずれか）
  3. 依存グラフ図：タスクを箱、依存関係を矢印で描く
  4. 並列化可能な箇所の特定：どのタスクの組が同時に進められるかを明示する
  5. バックグラウンド実行の候補：裏で回せるタスクがあれば挙げ、結果の回収方法を説明する
  6. 実行順序：8.4節の手順に従い、段階ごとに着手可能なタスクを列挙する

提出形式：タスクグラフ図＋説明文500〜800字

評価観点：

  • タスク分解が適切な粒度か（大きすぎず、小さすぎず）
  • 依存関係が明確で、矛盾がないか（循環依存がないか）
  • 並列化可能な箇所が正しく特定されているか
  • バックグラウンド実行の候補が妥当か（判断基準に基づいているか）
  • 結果の回収と最終統合まで設計できているか
  • 第4章（計画）、第7章（役割分担）の考え方と整合しているか

第8章のまとめ

本章では、大きな仕事をタスクに分解し、依存関係を設計する方法を学んだ。

要点を整理する。

  1. 仕事の難しさは量よりも関係の複雑さにある。タスク間の依存関係を矢印で書き出すと、「仕事の地図」が見える
  2. 依存関係 \(t_A \to t_B\) は「\(t_A\) が完了しないと \(t_B\) に着手できない」制約である。矢印がないタスクの組は並列化できる
  3. 全順序（全部直列）は安全だが遅い。半順序を活かし、依存を守りつつ順序のない組を並列化するのが効率的な設計である
  4. 「前提がすべて完了したタスクから順に着手する」という手順で、依存グラフから実行順序を機械的に導ける
  5. 長くて判断不要な作業はバックグラウンドで裏に回し、待ち時間に別の仕事を進める。ただし、ID で追跡し、結果を回収する仕組みが必要
  6. 依存関係を書くのは自由を減らすためではなく、何が今できるかをはっきりさせるためである

次の第9章では、複数の担当が協調するときに必要な通信の型（プロトコル）を扱う。口頭の「よろしく」ではなく、構造化された連絡の仕組みを設計する。