タスクアロケーションとは。AIを担当者欄に置いても、責任までは移らない

コラム一覧へ戻る

担当者欄が指してきたのは誰か

担当者欄には、これまで2つの役割が同居していました。手を動かす人と、進まなくなったときに拾う人です。人の名前が入っている限り、この兼務は成立します。

山田さんが佐藤さんに見積書のレビューを頼んだとします。佐藤さんが今週動けなければ、「今週は手が空かないので来週になります」と返します。この一言で、依頼は止まったまま放置されず、期限だけが動きます。

拾う動作は、担当者欄の外には書かれていません。人が入っていれば黙っていても起きるので、欄を分ける必要がありませんでした。

AIを割り当てると、兼務のどこが外れるか

AIエージェントは、割り当てられた作業を進めます。一方で、自分の作業が止まったことを業務上の遅れとして誰かに知らせるかどうかは、あらかじめ人が決めた通知の条件しだいです。条件を決めていなければ、止まったことは誰の画面にも出ません。

ここで起きるのは、ボード上の見え方の違いです。人が担当している依頼は、遅れると催促や相談が飛んでくるので、依頼者が気づきます。AIが担当している依頼だけ、催促が来ません。止まった依頼が静かに残るという点で、担当者欄の意味が変わります。

だから運用としてやることは、AIの精度を上げる前に、止まりに気づく人を欄として決めておくことです。

割り当てと委任は、どこが違うか

割り当てと委任を分けて考えると、欄の設計が決めやすくなります。Google DeepMind の研究者らが2026年2月に公開した論文は、委任（intelligent delegation）を、タスクアロケーションを含む一連の決定と定義しています。そこには権限と責任の移転、役割と境界の明示、意図の明確化、信頼を築く仕組みが伴うと書かれています¹。

裏返すと、タスクアロケーションは委任の一部分でしかありません。担当者欄に名前を入れる操作が担っているのは、この割り当ての部分だけです。

同じ論文は「delegation necessitates the assignment of responsibility and authority and thus implicates accountability for outcomes」と述べ、委任には責任と権限の割り当てが伴い、結果に対して答える立場が生じると説明しています²。欄に名前を入れた時点で責任も動いたと読むのは、この定義からすると早すぎます。

移すつもりがあるなら、誰が結果に答えるのかを別に書くことになります。書く場所が無いなら、責任は動いていません。

GitHubとMulticaは、人をどこに置いているか

この分け方は、AIに作業を渡すツールの実装にすでに現れています。GitHub では、issue の Assignees から Copilot を選べます。ドキュメントには、Copilot が作業を始めてプルリクエストを出し、終わったらレビューを依頼する、と書かれています³。

そのうえで、承認を必要とするリポジトリでは、Copilot が出したプルリクエストに自分で承認を付けても、必要な承認数には数えられません。GitHub のドキュメントは「your approval of a Copilot pull request won't count toward the required number」と書き、別のレビュアーの承認がマージ前に要ると説明しています⁴。作業を頼んだ人と、通す人を分けているわけです。

AIコーディングエージェントを共有ボードのメンバーとして扱う OSS の Multica も、同じ形を取っています。README は、同僚を選ぶのと同じようにエージェントをアサイニーに選べると書いたうえで、「Work lands in review, not in main. You decide what ships.」と続けます⁵。成果はレビューに入るのであって、そのまま本流には入りません。何を出すかは人が決める、という設計です。

どちらも、担当に相当する欄をAIに開放しつつ、通す判断を人の名前に固定しています。開発以外の依頼をボードで回す場合も、同じ形にできます。

実行者欄と責任者欄に割る

やることは単純で、1つだった担当者欄を2つにします。実行者欄にはAIの名前を入れてよく、責任者欄には人の名前を必ず入れます。既定値は、その依頼を出した人にしておくと迷いません。

期限も責任者欄の人が持ちます。実行者がAIのとき、期限に間に合うかどうかを交渉できるのは人だけだからです。

担当が2人になると責任が薄まるのではないか、という反論はあります。実際は逆で、今の1欄のままだと、AIの名前を入れた瞬間に人の名前が消えます。2欄にすれば、実行者が誰であっても人の名前が1つ残ります。

ただし、管理者1人が全依頼に目を通している規模なら、欄を増やす必要はありません。その人が事実上すべての依頼の責任者なので、欄に書いても情報が増えないからです。期限のない単発の調査をAIに投げる場合も同じです。

差し戻しの戻り先を人に固定する

欄を分けたあと、止まった依頼を実際に動かすのは通知です。PATHWORK では、依頼を「パス」という単位で扱い、届いた、見られた、受領、返信、放置を1つの流れとして持ちます。相手が反応しないと、その依頼は送信者の通知に自動で戻ります。

戻り先が送信者に固定されているので、実行しているのがAIでも、放置された依頼は人の手元に現れます。責任者欄を別に作らなくても、戻り先が人であることで同じ役割を果たす場面があります。

決めておきたいのは、AIの作業を人が代理で受けているときの扱いです。その人が受領を押した時点で、依頼の責任は実行しているAIではなくその人に移ります。押す前に中身を見るのか、見ずに受けて後から確かめるのかを先に決めておくと、差し戻しの宛先で揉めません。委任が何段か重なる場合の追い方は、エージェント間委任の記事で扱っています。

割り当てる前に決めておくこと

• 実行者欄にAIの名前を入れてよい依頼の種類を書き出す
• 責任者欄の既定値を、依頼を出した人にするか担当の管理者にするかを決める
• 何日動かなければ責任者の通知に戻すかを日数で決める
• AIが途中で止まったとき、誰の画面に出るかを確かめる
• 責任者欄が空の依頼を着手不可にするかを決める
• 人が代理で受領するとき、中身を見てから押すかを決める

まとめ

タスクアロケーションは、誰がやるかを決めるところまでを担います。担当者欄にAIを置くと、手を動かす役割は埋まりますが、止まったときに拾う役割が空きます。欄を実行者と責任者に割り、責任者には人の名前を必ず入れます。これが、AIをボードに載せるときの最小の変更です。

管理者1人で全依頼を見ている規模には要りません。管理者が全部を追いきれなくなり、誰が次に動くか一目で分からない依頼が出てきたあたりが、欄を分ける目安になります。

次の一手としては、今あるボードを開いて、担当者欄が空のまま3日以上動いていない依頼を数えてみてください。その数が、AIを載せたときに静かに滞留する依頼の予備軍です。

参考

本文中の番号をクリックすると、その数字の根拠にした原文にジャンプします。原文は改変せず、そのまま載せています。

1. Nenad Tomašev, Matija Franklin, Simon Osindero「Intelligent AI Delegation」arXiv:2602.11865

   Here we propose an adaptive framework for intelligent AI delegation - a sequence of decisions involving task allocation, that also incorporates transfer of authority, responsibility, accountability, clear specifications regarding roles and boundaries, clarity of intent, and mechanisms for establishing trust between the two (or more) parties.

   論文アブストラクト（本文の「タスクアロケーションを含む一連の決定」「権限と責任の移転、役割と境界の明示、意図の明確化、信頼を築く仕組み」の根拠） 本文の該当箇所へ戻る
2. 同論文の全文（HTML版）

   Delegation (Castelfranchi and Falcone, 1998) is more than just task decomposition into manageable sub-units of action. Beyond the creation of sub-tasks, delegation necessitates the assignment of responsibility and authority (Mueller and Vogelsmeier, 2013; Nagia, 2024) and thus implicates accountability for outcomes.

   本文（記事が引用した一文の前後。本文の「責任と権限の割り当てが伴い、結果に対して答える立場が生じる」の根拠） 本文の該当箇所へ戻る
3. Using Copilot cloud agent on GitHub（GitHub Docs）

   You can ask Copilot to start working on an issue by assigning the issue to Copilot. Copilot will start working on the task, raise a pull request, then request a review from you when it's finished. ... In the right side menu, click Assignees. Click Copilot from assignees list.

   Assigning an issue to Copilot の節（本文の「Assignees から Copilot を選べる」「作業を始めてプルリクエストを出し、終わったらレビューを依頼する」の根拠） 本文の該当箇所へ戻る
4. Review output from Copilot（GitHub Docs）

   If your repository requires pull request approvals, your approval of a Copilot pull request won't count toward the required number. Another reviewer must approve the pull request before it can be merged.

   Review Copilot's changes の節（本文が引用した一文と、その直後の「別のレビュアーの承認がマージ前に要る」の根拠） 本文の該当箇所へ戻る
5. multica-ai/multica（GitHub、README）

   Review gates → Work lands in review, not in main. You decide what ships.

   README の Review gates 項（本文の「成果はレビューに入るのであって、そのまま本流には入らない」の根拠） 本文の該当箇所へ戻る