第10章: タスクを最後まで閉じる

CC Company（シーシーカンパニー）の全タスクを点検した日のことです。34件のタスクを1件ずつ開いていったら、7件が「品質チェックは合格しているのに、タスクが完了していない」状態でした。

成果物はある。品質チェックも通っている。なのに、誰がそれを受け取ったのか記録がない。5件にいたっては、AI社員が「終わりました」と報告したまま、誰にも受理されずに放置されていたのです。

引っ越しに例えるなら、こんな状態です。荷物は全部段ボールに詰めた。トラックにも積んだ。でも新居に運んでいない。鍵も返していない。「引っ越しは終わりましたか？」と聞かれたら、「荷造りは終わりました」としか答えられない。

心理学者ツァイガルニク（Zeigarnik）が1927年に発見した現象があります。未完了のタスクは、完了したタスクの約2倍、記憶に残り続ける（出典: Zeigarnik, 1927, Psychologische Forschung）。「あの仕事どうなったっけ？」というモヤモヤは気のせいではなく、脳のワーキングメモリを実際に消費しています。タスクが宙に浮いている限り、あなたの頭の中のリソースも占有され続けるのです。

この章は、そのモヤモヤを仕組みで消す話です。

あなたの現在地を確認する

• AI社員のタスクに「開始・進行中・完了」などの状態がある
• タスクの完了を自己申告ではなく基準で判定している
• 完了したタスクの記録（何をやったか・合格したか）が残っている
• タスクが途中で止まった場合の対処法が決まっている

全部チェックが付いた方: タスク管理の仕組みが整っています。第11章で自動化に進みましょう。

1〜3個の方: タスクは動いているが「閉じ方」が甘い状態です。この章で「最後まで閉じる」仕組みを学ぶと、未完了タスクの放置がなくなります。

チェックがゼロの方: タスクの状態管理がない状態です。AI社員に仕事を振っても、完了したのかしていないのかわからない。この章がその問題を解決します。

川島さんの「終わったはず」事件

川島さんがAI社員に月曜の部内会議の議事録を頼みました。「会議の録音データを文字起こしして、要点をまとめておいて」。AI社員は「承知しました」と返事をし、作業を始めました。

木曜日。上司から「月曜の議事録、共有フォルダに入ってる？」と聞かれました。川島さんはAI社員に確認します。「あの議事録、できた？」。AI社員は答えます。「完了しました。品質チェックも合格しています」。

しかし、共有フォルダには入っていませんでした。AI社員の作業フォルダにはファイルがある。品質チェックのログも残っている。でも、川島さんが「見た」とも「OKを出した」とも、どこにも記録がない。AI社員は「完了した」と言うけれど、川島さんは受け取った覚えがない。

成果物は合格している。なのに仕事が「閉じて」いない。

皆さんの職場でも似た経験はないでしょうか。部下に「あの資料できた？」と聞いたら「はい、できてます」。でも誰にも共有されていない。メールの下書きフォルダに入ったまま。報告書は完成しているのにハンコが押されていない。

品質サイクル（第5章、第6章）は「良いものを作る」仕組みです。しかし、作ったものが「確実に届き、記録され、完了として処理される」ところまではカバーしていません。ここに穴があったのです。

タスクの「閉じ方」を4回作り直した

この問題を解決するために、CC Companyではタスクの全行程を管理する仕組み（タスクライフサイクル）を設計しました。

正直に言うと、最初からうまくいったわけではありません。4回のダメ出しを受けて、ようやく安定しました。この章では、その4回の失敗と修正の過程を追いながら、タスクを最後まで閉じる仕組みの作り方をお伝えします。

なお、この仕組みはCC Companyの全部署で共通の基盤として使っています。記事執筆、講演資料作成、クライアント提案書など、業務の種類は違っても「タスクを生成し、実行し、検証し、完了させる」サイクルの回し方は同じです。ここまでの章で学んだ目的設定（第1章）、業務分解（第2章）、マニュアル（第4章）、合格基準（第5章）、品質サイクル（第6章）、手順書（第8章）、検証（第9章）が揃っていれば、業種や規模を問わず適用できます。

最初のダメ出し: 「状態が定義されていない」

最初に作ったワークフロー（v1）は素朴な5ステップでした。「ゴール設定→チェックリスト→実行→検証→完了」。理屈としては正しい。しかし、別のAIシステム（ゲートキーパー）に検証させたところ、3つの指摘が返ってきました。

「状態遷移が定義されていない」「実行者と検証者の責任境界が曖昧」「例外処理がない」。

最初の指摘が一番痛かった。「いま、この仕事はどの段階にあるのか」が誰にも分からない状態になっていたのです。

人間同士の仕事であれば、暗黙の了解で進みます。「資料作ってるんだろうな」「レビュー待ちだろうな」「もう終わったはずだ」。こうした推測で日常業務は回ります。しかしAI社員は推測しません。推測してもらうこともできません。

そこでv2では、タスクの状態を明示的に定義しました。最小限の状態セットとして、以下の6つを設けています。

この6つの状態だけで、タスクの現在地が一目瞭然になります。PMI（Project Management Institute：プロジェクトマネジメント協会）の調査によれば、明確な管理構造を持つ組織はプロジェクト成功率が38%高い（出典: PMI, Pulse of the Profession）。タスクの状態管理は「あったら便利」ではなく、仕事を完了させるための基盤です。

ポイントは、「報告済み」と「完了」を分けていることです。AI社員が「終わりました」と言っただけでは完了ではありません。あなた（またはあなたの代理）が「確認した、受理する」と明示的に判断して初めて完了です。冒頭の引っ越しの例で言えば、「荷造り完了」と「引っ越し完了」は別のことなのです。

2回目のダメ出し: 「作った人が判定している」

v2で状態管理を入れたものの、次の問題が出ました。AI社員が成果物を作り、自分で品質チェックし、自分で「合格」と判定し、自分で「完了」にしている。全工程を1人でやっているので、ミスがあっても気づけないのです。

レストランで料理を作ったシェフが「美味しいです、OKです」と自己申告するだけでは、品質管理として不十分です。別の人が味見をする。お客さんが「美味しかった」と言って初めて、その料理は成功です。

IBM（アイビーエム）のフェイガン（Fagan）が1976年に確立した正式インスペクション手法では、第三者によるレビューでテスト前段階にエラーの82%を検出できました（出典: Fagan, 1976, IBM Systems Journal）。作った人が自分でチェックするだけでは見落とす欠陥を、別の視点が拾い上げる。この知見は50年前からある原則です。

v3では、タスクに関わる役割を3つに分離しました。

実行者: 実際に作業する人。記事を書く、スライドを作る、調査をする。

検証者: 成果物の品質をチェックする人。実行者とは別の視点で確認する。

受理者: タスクの開始を指示し、完了を受理する人。仕事の「始まり」と「終わり」を管理する。

「作った人が、完了を判定しない。」 これが原則です。

CC Companyでは、検証を「ゲートキーパー」と呼ぶ別のAIシステムが行っています。実行するAIとは物理的に別のシステムです。ある日、レビューログに「6つの表を確認し全て正常」と書かれていましたが、ゲートキーパーが検証したところ表は5つしかありませんでした。実行者の自己レビューでも、私自身の確認でも見落としていたミスを、別の視点が拾ったのです。

チェックリストを「正本」にする

v3で役割を分けたところ、今度は「どこに記録するか」で混乱しました。

川島さんも同じ壁にぶつかりました。最初はTrello（トレロ）のカンバンボードでタスクを管理していました。カードを「作業中」から「完了」に移動させて終わり。しかし、AI社員が複数の業務を並行して進めるようになると、カードの中に情報が収まりきらなくなりました。「合格基準は何だったか」「どのステップまで完了したか」「レビューログはどこにあるか」。これらの詳細がカードの外にバラバラに散らばっている。

CC Companyでも同じことが起きました。タスク管理ツール（Google Tasks（グーグルタスクス））のステータスは「完了」なのに、チェックリストファイルには受理の記録がない。逆に、チェックリストは全ステップ完了なのに、タスク管理ツールが「作業中」のまま。どちらが正しいのか分からない。

そこで決めたルールが、チェックリストファイルを「正本」にすることです。

タスクごとに1つのチェックリストファイルを作り、そこにすべてを記録します。ゴール、ステップ、合格基準、各ステップの完了状態、レビューログへのリンク、タイムスタンプ。このファイルが唯一の正本です。

タスク管理ツールは、正本の状態を外部に映し出す「ダッシュボード」に過ぎません。便利な一覧表ですが、正本ではない。もしチェックリストとタスク管理ツールの状態がずれたら、チェックリストの方が正しいとします。

外科医アトゥール・ガワンデ（Atul Gawande）は著書『チェックリスト・マニフェスト』で、WHO（World Health Organization：世界保健機関）の手術安全チェックリスト（たった19項目のリスト）が死亡率を47%削減した事例を紹介しています（出典: Haynes et al., 2009, New England Journal of Medicine）。チェックリストの力は「記憶の補助」ではなく、「プロセスの省略を検知する仕組み」にあるとガワンデは述べています。AI社員のチェックリストもまったく同じ目的で機能します。

川島さんの場合、タスク管理ツールをやめる必要はありません。ツールは「目次」として使い、詳細は1タスク1ファイルのチェックリストに書く。この二層構造にしたことで、川島さんは「タスクの全体像はツールで、詳細はファイルで」と把握できるようになりました。

3回目のダメ出し: 「報告したのに届いていない」

v3で役割分離とチェックリストを導入しましたが、運用を始めてすぐに問題が見えました。冒頭で紹介した「34件中7件が未完了」の事件です。

AI社員が「すべてのステップを完了し、品質チェックに合格しました」と報告する。これが完了報告です。しかし、この報告を受け取って「確認した、このタスクは完了とする」と判断する受理のプロセスが、v3には存在しませんでした。

5件のタスクが「報告済み」のまま誰にも受理されずに浮いていた原因は、受理する仕組み自体がなかったからです。報告はしている。でも「受け取りました」と記録する手順がない。だから報告が宙に消える。

v4では、完了報告と受理を明確に分離しました。受理のタイミングで行うことは3つです。

1. チェックリストを確認する: 全ステップにチェックが入っているか。レビューログが存在するか。
2. 受理を記録する: 「いつ、誰が受理したか」をチェックリストファイルに記録する。
3. ダッシュボードを更新する: タスク管理ツールの状態を「完了」に更新する。

マシカンポ（Masicampo）とバウマイスター（Baumeister）（2011）の研究が興味深い知見を示しています。未完了タスクが脳のリソースを占有し続ける問題に対して、「具体的な計画を立てる」だけで認知的干渉が消えるというのです（出典: Masicampo & Baumeister, 2011, Journal of Personality and Social Psychology）。受理プロセスは、タスクの完了を明示的に記録することで、あなたの頭の中からそのタスクを安全に消す仕組みでもあるのです。

出口のない仕組みは必ず壊れる

v4で受理プロセスを入れた直後、別の問題にぶつかりました。あるタスクが5回修正しても合格しない。AI社員は律儀に修正を繰り返すが、合格基準自体に問題があるのでいつまでも終わらない。期限が過ぎたタスクも放置される。「どうすればいいか分からない」状態のタスクが溜まり始めたのです。

CC Companyではこれを「オーナー判断待ち」と名づけました。AI社員やシステムの自動処理では解決できない問題に遭遇したとき、無限にリトライするのではなく、明示的に「ここから先は人間が判断してください」と旗を立てるのです。

「オーナー判断待ち」になるケースは4つです。

1. 修正5回超過: 何度やっても合格しない。合格基準自体に問題がある可能性がある。
2. 期限超過: タスクの期限が過ぎた。延期するか、中止するか、分割するか。
3. 停滞: 48時間以上進捗がない。何かが詰まっている。
4. 担当者不在: このタスクを実行できるスキルや担当が存在しない。

これとは別に、レビューログ欠損（チェック済みなのにログファイルがない）の場合は、オーナー判断を待たずにAI社員が自動的に該当ステップをやり直します。人間を巻き込む必要がない問題は、仕組みの中で自動修復するのが原則です。

人間に判断が戻ったら、取れる選択肢は3つです。

• 再実行: 合格基準を見直して、もう一度やり直させる
• 中止: このタスクは諦める
• 分割: タスクを小さく分けて、改めて取り組む

ポイントは、これらの「出口」を事前に設計しておくことです。問題が起きてから「どうしよう」と考えるのではなく、あらかじめ「この条件になったら人間に戻す」と決めておく。皆さんの会社でも、「申請が3回差し戻されたら上長に相談する」「納期に間に合わない場合は前日までに報告する」というルールがあるはずです。AI社員にも同じ出口が必要なのです。

それでもずれる。だから監督者を置く

v4まで設計して、「これで完璧だ」と思いました。しかし運用を始めると、やはりずれが生じます。

CC Companyで実際に起きた不整合の例です。AI社員がタスクを完了報告したが、タスク管理ツールの更新を忘れた。タスク管理ツールは「完了」なのに、チェックリストには受理の記録がない。期限が過ぎたタスクが放置されている。チェック済みなのにレビューログが存在しない。

ある日、タスク管理ツールの画面に「105時間超過」と表示されたタスクがありました。慌てて確認したところ、実際にはタスクは完了していて、チェックリストも全ステップ完了済み。ただし、タスク管理ツールへの反映が漏れていただけでした。仕組みは動いている。でも表示がずれている。これが人間なら「あ、更新忘れてた」で済みますが、AI社員は自分では気づきません。

こうした不整合を検出し、修復する役割が監督者です。

監督者の仕事は、定期的にチェックリストとタスク管理ツールの状態を突き合わせ、ずれを見つけて修復することです。CC Companyでは、1日1回の起動ルーティンで監督チェックを実行しています。

2025年のマルチエージェント研究のサーベイ論文によれば、システムに「検査役」を組み込むと、エラーの96.4%を回復できるという報告があります（出典: Talebirad & Nadiri, 2025, arXiv: 2501.06322）。監督者は「疑い深い見張り番」です。仕組みが正しく動いているかを、仕組みの外側から定期的にチェックする。この存在があることで、多少のずれは自動的に修復され、仕組み全体の信頼性が保たれます。

v5ではこの監督機能を標準装備し、どの状態からでもキャンセルや中断ができる「完全閉包」を実現しました。その後も運用する中で改善を重ね、本書執筆時点ではv6になっています。完成ではなく、使いながら育てている段階です。

規模に応じた設計: 個人・チーム・組織

個人で始めるなら

川島さんがこの仕組みを自分の業務に取り入れたとき、最初に聞かれたのは「全部やらないとダメですか？」でした。答えはノーです。個人なら最小限で十分です。

• 状態管理: 「未着手→作業中→完了」の3状態で十分。紙のTODOリストでも構いません。
• 受理: AI社員が出した成果物を、自分で確認してから「使う」。確認せずにそのまま使わない。
• 例外処理: 3回修正してダメなら、指示（プロンプト）の出し方を見直す。

個人にとってのタスクライフサイクルの価値は、「なんとなく終わった気がする」を防ぐことです。明示的に「完了」と判断する習慣があるだけで、仕事の抜け漏れは激減します。川島さんも、まずは「AI社員の成果物を確認したらファイルに日付を書く」というルールから始めました。

チームに広げるなら

• 状態管理: 6状態の標準版を導入。チーム共有のタスクボードで可視化する。
• 役割分離: 実行者と検証者を別の人にする。作った人がレビューしない。
• 受理: チームリーダーまたは指名された人が受理する。
• 監督: 週次のチーム定例で、停滞タスクや未受理タスクを棚卸しする。

組織で展開するなら

• 状態管理: 完全版を導入。未着手から完了、中止までの全状態を網羅する（詳細は付録Dを参照）。
• 役割分離: 実行者、検証者、受理者を組織的に分離。検証専門の品質管理部門を設ける。
• 審査レベル: タスクのリスクに応じて検証の深さを変える。社内完結の軽微なタスクは簡易チェック。外部公開や金銭に関わるタスクはフルゲート。
• 監督: 毎日の起動ルーティンで自動チェック。不整合は自動修復。修復できないものは「オーナー判断待ち」に自動遷移。

コラム: 「47件」と書いたのはAIの創作だった

この章の原稿を通読していたとき、冒頭に「47件のタスクを点検した」と書かれていました。覚えのない数字です。活動ログを調べたところ、実際に監督チェックで走査したタスクは34件でした。47件はAI社員が書籍を執筆する過程で作り出した数字、つまりHallucination（ハルシネーション：もっともらしい嘘）だったのです。

第3章で学んだ通り、AI社員は存在しない情報をもっともらしく語ります。しかも「成功を誇張しがち」という傾向もあります。「47件を走査して7件の問題を発見した」は「34件を走査して7件の問題を発見した」よりも物語として見栄えがする。AIには悪気がない。しかし、結果として嘘になる。

この経験から学んだのは、タスク管理の記録を残す目的がもう1つあるということです。成果物の品質を管理するためだけでなく、AI社員自身の報告を後から検証できるようにするため。活動ログという記録があったから、47件が34件だと気づけた。記録がなければ、嘘の数字がそのまま書籍に残っていたところです。

LLM（Large Language Model：大規模言語モデル）知識: なぜAIに「役割」を与えると品質が上がるのか

本章で紹介した「実行者・検証者・受理者」の役割分離は、AIの研究分野では「マルチエージェントパターン」と呼ばれる設計手法に対応しています。

デュ（Du）ら（ICML（International Conference on Machine Learning：機械学習の国際会議） 2024）の研究では、複数のAIに同じ問題を解かせて互いの回答を議論させると、単独のAIよりも事実性と推論力が向上し、ハルシネーション（もっともらしい嘘）が減少しました（出典: Du et al., 2024, Improving Factuality and Reasoning in Language Models through Multiagent Debate, ICML）。

さらに興味深いのは、ChatEval（チャットエヴァル。ICLR（International Conference on Learning Representations：学習表現の国際会議） 2024）の実験結果です。複数のAIに異なる役割を与えて文章品質を評価させると、人間の評価との一致度が向上しました。しかし、全員に同じ役割を与えると性能が劣化したのです（出典: Chan et al., 2024, ChatEval: Towards Better LLM-based Evaluators through Multi-Agent Debate, ICLR）。「異なる視点」が本質的に重要ということです。

CC Companyの「実行者」「検証者（ゲートキーパー）」「受理者」という設計は、この研究知見と同じ原理に基づいています。1つのAIに「書いて、チェックして、報告して」と詰め込むと、注意が散ってミスが増える。第7章で学んだ「小さな専門家をたくさん育てる」の思想を、タスク管理にまで拡張した形です。CC Companyがこの役割分離をどう組織全体に広げているかは、第14章で詳しく紹介します。

まとめ

• 成果物の合格と業務の完了は別。タスクは「受理」されて初めて閉じる
• タスクの状態を明示的に管理する。最小6状態で始められる
• 実行者・検証者・受理者を分ける。作った人が完了判定しない
• チェックリストファイルを正本にする。タスク管理ツールはダッシュボード
• 行き詰まったときの出口を事前に設計する。無限リトライは禁止
• 監督者が不整合を検出し修復する。定期的なチェックで仕組みの信頼性を保つ
• この仕組みは個人の簡易版から組織のフル装備まで、段階的に導入できる

タスクが最後まで閉じるようになりました。次に考えるべきは、「毎日やる作業を人間が毎回トリガーしなければならない」という問題です。