AI 時代に増え続ける「作業状態の管理負荷」を、GTD × AI エージェントで軽くする

LINE アプリ開発に携わっている、Hiraki と申します。普段は、LINE アプリのアーキテクチャ統一を推進するプロジェクトのリードを務めるとともに、AI ネイティブな開発スタイルを実務に取り込むための研究開発に取り組んでいます。

この記事では、AI エージェントの普及に伴って増え続ける「作業状態の管理負荷」に焦点を当てます。その負担を軽減するため、GTD（Getting Things Done）という手法を AI エージェントで自動化する検証を行った話をご紹介します。

増え続ける作業状態の管理負荷

ここ最近、AI エージェントの利用機会が増え、開発のあり方そのものが変わりつつあります。

• 開発速度が向上し、PR（Pull Request）の数が増えることで、レビューすべき対象も膨らんでいる
• 複数の作業を並行して進めることが当たり前になり、作業の中断と再開の回数も増えている

この変化は、単に扱うタスクの数が増えるだけでなく、「進行中」「対応待ち」といった把握しておくべき仕事の状態そのものを増やします。一言で言えば、作業状態を管理する負荷が増大しているということです。

私自身、それを痛感しています。複数の PR について「自分の番がいつか、どれが相手の対応待ちなのか」を頭の中で覚えておくこと、レビューした内容が反映されたかを何度も確認しに行くこと、中断のたびに「何をどこまでやっていたか」を思い出そうとすること。ひとつひとつは小さな負担かもしれませんが、積み重なると地味に大きな重荷になります。

では、この負荷が増えると具体的に何が問題になるのでしょうか。

管理負荷が増えることの問題

作業状態を管理する負荷が増えると、認知的な負担も大きくなります。その結果、必要なことを思い出すのに時間がかかったり、本来やるべきことを忘れてしまったりします。先ほど挙げた私の負担も、根性や注意力で乗り切る話ではなく、この「認知的な負担」の表れだと捉え直せば、対策の方向性が見えてきます。

この「思い出すのに時間がかかる」「やるべきことを忘れる」という 2 つの症状は、認知科学では別々の認知機能への負荷として捉えられます。ここで負荷がかかっているのは、主に次の 2 つの認知機能です。

• ワーキングメモリー（短期記憶）：頭の中で情報を一時的に保持しながら、それを使って考えたり作業したりする能力

負荷がかかると、やるべき作業を思い出すのに時間がかかったり、作業の精度が落ちたりしやすくなります

• 展望記憶：将来やるべきことを覚えておき、適切なタイミングで思い出して実行する能力

負荷がかかると、待ち状態のタスクの対応漏れが起きやすくなります

※用語の定義は、脳科学辞典「ワーキングメモリー」と『高次脳機能研究』39 巻 3 号の総説「展望記憶のリハビリテーションとトピック」（PDF）を参考にしています。

したがって、この 2 つの負荷を軽減する仕組みがあればよさそうです。

認知負荷をどう軽減するか

この認知負荷を軽減する仕組みのひとつとして、私は GTD（Getting Things Done）に着目しました。

GTD とは一言で言えば、個人単位でのタスク管理手法です。デヴィッド・アレン氏が 2001 年に著した『Getting Things Done: The Art of Stress-Free Productivity』で提唱されました。

やり方はシンプルです。タスクを時系列上の状態ごとに分けてリスト化します。本記事では、作業状態の管理という観点から特に重要な次の 4 つのリストを取り上げます。

• Inbox：これから振り分けるタスクを、ひとまず書き留めておく場所
• NextAction：いま着手すべきタスク（例：レビュー依頼が来た PR、MTG のアジェンダ準備）
• Waiting：自分の手を離れ、相手の対応を待っているタスク（例：レビュー済みの PR の修正反映待ち）
• Someday：いますぐ着手はしないが、いつかやりたいタスク

なお、GTD のリストにはこのほかにも、複数のタスクから構成される Projects や、日時指定の予定を置く Calendar など、さまざまなバリエーションがあります。

GTD の 4 つのリストとタスクの流れ

GTD を活用すれば、タスク一覧やその状態を脳内の記憶から外部のリストへ移すことができます。これにより、先ほど挙げた 2 つの認知負荷を軽減できます。

• ワーキングメモリーの負荷を軽減：いま何をやるべきかを、外部に記憶できる
• 展望記憶の負荷を軽減：相手待ちのタスクが可視化され、対応漏れを防ぎやすくなる

GTD の限界 ― 運用コストとのトレードオフ

ただし、GTD は万能ではありません。リストの運用には、それ自体に手間がかかります。

• リストは人間が手で管理しなければならない（例：PR レビューや研修受講といったタスクを自分で追加する）
• 待ち状態が解除されたかどうかを定期的に自分で確認しなければならない（例：PR レビューの指摘が反映されたか、メールやチャットの返信が来たか）

このリストの管理作業自体もまた、認知負荷になりえます。つまり、GTD が軽減してくれる負荷と、GTD を運用するための管理負荷との間にはトレードオフがあるのです。

GTD が軽減する負荷と、運用にかかる管理負荷のトレードオフ

運用のための管理負荷が、GTD が軽減してくれる負荷に見合わない場合、GTD を運用する価値はありません。「GTD を試したけど続かなかった」という方がいるかもしれませんが、このトレードオフが原因のひとつではないでしょうか。

では、その GTD の管理負荷をどう減らすかを考えてみましょう。基本的な方針は、GTD のリスト管理をなるべく自動化することです。

私が GTD で管理しているタスクは、次の 3 つに大別できます。

• 繰り返しタスク: 定例 MTG のアジェンダ作成など、定期的に繰り返す必要があるタスク
• 依頼タスク: PR レビューや研修受講など、誰かからの依頼をトリガーとして発生するタスク
• 計画済みタスク: 事前に登録されている機能開発やバグ対応など

これら 3 つの分類では、自動化によってどれほど管理負荷を減らせるかが異なります。次章では、まず検証すべきポイントを整理し、どの分類に着手すべきかを明確にしていきます。

MVP による検証

ここでは主に 2 つの点を検証します。

• 検証 1: ローカルの AI エージェントから Google ToDo リストを操作できるか（技術的な実現性）
• 検証 2: 自動で GTD リストを管理することに、本当に価値があるのか

これらを手早く確認するため、MVP（Minimum Viable Product：検証に必要な最小限の実装）を作成します。3 つの分類を「自動化でどれだけ管理負荷を減らせそうか」という観点から比較検討すれば、今回どこに注力すべきかが見えてきます。

なお、GTD のリスト管理には Google ToDo リスト（英語版名称は Google Tasks）を利用する前提とします。タスク管理に特化したこのサービスは、GTD と親和性の高い「リスト」という概念を持ち、後述するように API を経由して操作できるためです。

分類ごとの自動化の余地

• 繰り返しタスク: 小さい（Google ToDo リストの標準機能で十分対応可能）
• 依頼タスク: 大きい（外部の動きを監視し、自動的に振り分けが可能）
• 計画済みタスク: 小さい（着手の判断が人間に依存するため）

繰り返しタスクは Google ToDo リストの「繰り返し機能」でそのまま代替できるため、わざわざ仕組みを作る必要はありません。また、計画済みタスクは「今すぐやるか」の判断が人間に委ねられるため、自動化しても効果は限定的です。

一方、依頼タスクは PR やメールといった外部の動きをトリガーとして自動的に振り分けられ、3 つの分類の中では最も自動化による効果が大きいと考えました。

そこで今回は、依頼タスクにスコープを絞り、その情報源として PR とメールを取り扱います。具体的には、PR のレビュー状態に応じて NextAction に追加したり Waiting へ移したりすること、そしてメールから対応すべき依頼を拾って NextAction に積むことを、最小構成で検証します。

なお、「依頼タスク」の中でも PR とメールではタスクの作り方が異なります。PR は、レビュー状態や CI の結果に基づき決定的なルールで NextAction か Waiting かに振り分けられます。一方、メールは「どれが対応すべき依頼なのか」を機械的なルールだけで一律に判定するのは難しく、AI エージェントの判断に頼る必要があります。この違いは、後述するシステム構成にも大きく関わってきます。

参考までに、PR の振り分けルールの主なものを抜粋すると、以下のようになります。

どの行も GitHub の状態から機械的に判定でき、同じ状態なら必ず同じ結果になります。

システム構成

全体のシステム構成は次のとおりです。

システム構成図

ローカルの AI エージェントが GitHub の PR とメールを集めて分類し、その結果を GAS（Google Apps Script）の Web アプリ経由で Google ToDo リストに反映します。AI エージェントには、ターミナル上で対話しながら開発を進める CLI 型のコーディングエージェントを使い、この仕組みはそのスキル（エージェントに手順や知識を追加する拡張機能）として実装しています。

役割分担としては、

• AI エージェント = 判断：PR とメールから情報を集め、どのタスクをどのリスト（NextAction か Waiting か）に入れるかを確定する
• GAS = 副作用：確定した指示を受けて、実際に Google ToDo リスト内のタスクを操作する（誤操作を防ぐガードもここに置きます）

という形です。

ここで、先ほど触れた PR とメールの違いが効いてきます。PR は決定的なルールで振り分けられるので、その分類はプログラムで処理できます。一方メールは、どれが対応すべき依頼かの候補の洗い出しを AI エージェントに委ねます。ただし、AI エージェントが挙げた候補がそのままリストに入るわけではありません。その中から実際に登録するものは、私が明示的に指定します。メールの判断には PR のような機械的な正解がないからこそ、最後の確定は人が行う形にしています。いずれの場合も、最終的に「どのリストに何を入れるか」が確定した指示として GAS に渡る、という点は変わりません。つまり、ここでいう AI エージェントは、すべての判断を AI で行う仕組みではなく、ルール・AI・人の判断を束ねて確定した指示を作る、進行役という位置づけです。

この「判断」と「副作用」を分けたのには理由があります。AI エージェントの出力は確率的で、同じ入力でも結果が揺れたり、ときには誤った判断をすることがあります。タスクの追加・移動・完了といった実際にデータを書き換える操作まで AI エージェントに直接やらせると、その揺らぎがそのまま Google ToDo リスト上の事故（重複登録や誤削除）につながりかねません。

そこで、書き換え操作は GAS 側に閉じ込め、「どのリストに何を入れてよいか」のルールやガードを GAS 側で固定しました。AI エージェントには「分類を判断する」役割だけを任せ、確定した指示だけを GAS に渡す形にすることで、判断の揺らぎが副作用に波及しにくい構成にしています。

なぜ GAS を経由するのか

前節で述べた「副作用を閉じ込める」という方針を、実装としてどう実現するか。ここで選んだのが、GAS の Web アプリを一種のプロキシとして使う構成です。

AI エージェントから Google ToDo リストの REST API を直接呼び出す構成にすると、タスクの追加・移動・完了といった書き換え操作（副作用）が、AI エージェント側に散らばってしまいます。副作用が分散すると、「どのリストに何を入れてよいか」というルールやガードもエージェント側に持たざるをえず、判断と副作用を分けたかった意図が崩れてしまいます。

そこで、書き換え操作はすべて GAS の Web アプリの向こう側に閉じ込めました。AI エージェントは GAS に確定した指示を HTTP で渡すだけで、実際の API 呼び出しは GAS 側が行います。こうすることで、副作用とそのガードを GAS という 1 か所に集約でき、エージェント側は「分類を判断する」役割に専念できます。

なお、GAS には Google Workspace の各種サービスを呼び出す仕組みが標準で備わっているため、今回の MVP では、個別に GCP プロジェクトを作成して OAuth クライアントを設定するような準備をせずに Google ToDo リストを操作できた、という副次的な利点もありました。

誤操作を防ぐための工夫

判断と副作用を分けただけでは、「AI エージェントが誤った指示を出したらどうなるのか」「何度も実行したら重複しないのか」という不安が残ります。そこで、副作用の集約先である GAS 側に、次のようなガードを置いています。

• 入口を閉じる：GAS の Web アプリは「アクセスできるユーザー = 自分のみ」の設定でデプロイし、呼び出しには自分の Google アカウントでの認証を必須にしています
• 重複させない：各タスクには対応する PR の ID を埋め込み、同じ PR への指示は新規作成ではなく既存タスクの更新として扱います。同じ分類を何度実行しても、途中で失敗して再実行しても、リストは同じ状態に収束します
• 勝手に消させない：タスクを削除する指示は受け付けていません。タスクが完了になるのは、PR のマージ・クローズという事実から自動で判定された場合だけです。逆に、私が手動で完了にしたタスクは、PR がオープンなままでも復活させません。手動での完了を「このタスクは自分の管理対象から外す」という明示的な意思表示として尊重するためです
• 人が確定する：前述のとおり、機械的な正解のないメール由来のタスクは、AI エージェントの候補から実際に登録するものを私が明示的に指定します

このうち「重複させない」と、「勝手に消させない」で触れたタスクの自動完了は、どちらも「各タスクに、対応する PR の ID をマーカーとして埋め込んでおく」という一つの仕組みで実現しています。

タスクを登録するとき、GAS はまずその ID のタスクがすでにあるかを解決してから、新規作成か更新かを決めます。ID とタスクの対応表は GAS 側にも索引として持っていますが、これは高速化のためのキャッシュにすぎず、Single Source of Truth（信頼できる唯一の情報源）はあくまで Google ToDo リスト側です。索引が消えたり古くなったりしても、リスト側のマーカーを走査して同じタスクにたどり着けるため、二重登録には進みません。

タスクを完了処理する際は、同じ ID を差分検出に利用します。マージやクローズといった個別のイベントを追跡するのではなく、「今回の同期で表示されなくなった ID のタスクを完了にする」という状態の突き合わせを行います。イベントを見逃しても次回の同期で自動的に整合性が取れるよう設計されており、何度実行しても同じ状態に収束する（冪等な）仕組みです。

こうしたガード機能を GAS 側に集約しておくことで、AI エージェントの判断が揺らいでも、Google ToDo リストの中身が壊れてしまう影響を最小限に抑える構成になっています。

デモ：実際の Google ToDo リスト

これまで私は、レビュー依頼の有無や PR の反映状況、メールで届いた依頼などを確認するために、1 日に何度も GitHub やメールをチェックし、その結果を手元のリストや頭の中で整理していました。しかし、エージェントを 1 回実行して分類するだけで、この手作業は不要になります。各タスクが状態ごとに自動的に振り分けられるのです。

私の場合、監視対象のリポジトリは 5 つありますが、エージェントの実行 1 回で自分に関係する数件の PR がまとめて整理されます。下の画像は、その振り分け後の Google ToDo リストの画面です（なお、タスク内容はデモ用の架空のもの）。

エージェント実行後の Google ToDo リストの画面（タスクはデモ用の架空のもの）

• レビュー依頼が来た PR や、メールで届いた依頼は「NextAction」に入る
• レビューを行って相手待ちになった PR は「Waiting」に移る
• レビュー完了済みの PR は「Completed」に並ぶ

エージェントを実行するだけで、今すぐ着手すべきタスクと、相手の対応を待っているタスクがそれぞれのリストに自動で振り分けられます。

MVP で検証できたこと

この MVP により、冒頭で掲げた 2 つの検証項目はどちらもクリアできました。

• 検証 1（実現可能性）：ローカルの AI エージェントから Google ToDo リストを実際に操作できた
• 検証 2（有用性）：リストへの登録や状態変更を自動化でき、管理コストが下がったことを体感できた

検証 2 について、私の運用がどう変わったかを Before/After で整理すると以下の通りです。

Before / After

1. 1 日に何度も GitHub やメールを見にいき、結果を頭の中や手元のリストに反映していた → エージェントの実行 1 回で NextAction と Waiting が揃う
2. 複数リポジトリの PR の状態をひとつずつ確認していた → 5 つのリポジトリを横断して、自分に関係する PR が自動で振り分けられる
3. 「どれが自分の番で、どれが相手の対応待ちか」を頭の中で覚えておく必要があった → リストが代わりに覚えてくれるので、頭の中で把握し続ける必要がなくなった

なお、これは私自身の運用（N=1）での実感であり、定量的に効果を測ったものではありません。それでも、冒頭で感じていた「作業状態を覚えておくことの負担」が確かに軽くなったという手ごたえは得られました。

タスクの遂行支援まで踏み込んでみる

ここまでで、MVP（最小実行可能製品）によって GTD の管理を自動化する価値があることが示されました。この MVP を発展させれば、単なるリストの管理を超えて、積まれたタスクの実行そのものを AI エージェントが先回りして支援する段階まで踏み込めます。

具体例として、レビュー待ちの PR（プルリクエスト）の要約を試みました。NextAction には「自分がレビューすべき PR」が並んでいます。ここに溜まった各 PR について、あらかじめ AI エージェントに要約を出力させておけば、実際にレビューする際に一つずつ開いて内容を把握し直したり、その都度「要約して」と指示したりする手間を省けます。

仕組みとしては、これまでの構成がそのまま活かされています。PR の内容を読み取って要約を生成する部分は AI エージェントが担い、その要約を保存して表示する操作は「副作用」なので GAS 側に任せます。 要約は PR ごとに 1 枚の HTML ページとして GAS から配信し、対応するタスクからそのページへリンクを張るようにしました。つまり、リスト上の各タスクから要約ページに一足飛びでアクセスできる形です。

要約には、単なる内容のまとめだけでなく、AI エージェントによる簡易的なレビューの所見や、すでに付いている指摘とそのやりとりの整理も含めるようにしました。また、要約は日本語で出力させるため、英語で書かれた PR でも要点を把握してからレビューに入れます。次の画像は、この仕組みで生成した要約ページの一例です。ページのレイアウトや見出しは実際に出力されたものですが、題材の PR はこの記事のために用意した架空のものに差し替えています。

PR 要約ページのレイアウト例（題材の PR は記事用に用意した架空のもの）

「見るべき点」でレビューの勘所を先に押さえ、「既存の指摘とやりとり」でどの指摘がすでに出ていて対応済みか・未対応かを把握しておけば、同じ指摘を繰り返さずにスムーズにレビューを始められます。

さらに、この要約は放っておいても散らかりません。PR がマージまたはクローズされてタスクが自動で完了すると、それに合わせて要約のページも自動的に片付けられます。もともとタスクの自動完了に使っていた仕組みを、要約の後始末にもそのまま流用した形です。おかげで、手元には「いままさにレビューすべき PR」の要約だけが残り続けます。

これも私自身の運用（N=1）での試みですが、リストの管理を自動化した土台の上に、こうしたタスクの実行支援を一枚重ねられることを実感しました。ここからさらに支援の幅を広げていけば、仕事の効率をより高められる可能性があると考えています。

まとめ

この記事では、AI エージェントの普及とともに増え続ける「作業状態の管理負荷」に着目し、その軽減策として GTD を紹介しました。GTD はそれ自体の運用に管理負荷がかかるという限界がありますが、AI エージェントから Google ToDo リストを操作することで、その管理をある程度まで自動化できることを MVP で示しました。

さらに、リスト管理の自動化を土台に、PR の要約といったタスクの実行支援を重ねていくことも確認できました。ここから支援の範囲を広げていけば、仕事の効率をさらに高められる可能性があると考えています。

最後までお読みいただき、ありがとうございました。