LINE アプリ開発に携わっている Hiraki と申します。普段は、LINE アプリにおけるアーキテクチャの統一を推進するプロジェクトのリードや、AI ネイティブな 開発スタイルを業務に組み込むための研究開発に取り組んでいます。
この記事では、AI エージェントの普及とともに増え続ける「作業状態の管理負荷」に着目し、その負荷を軽減するために GTD という手法を AI エージェントで自動化してみた、という検証の話を紹介します。
増え続ける作業状態の管理負荷
ここ最近、AI エージェントの利用機会が増え、開発のあり方そのものが変わりつつあります。
- 開発速度が上がって PR（Pull Request）の数が増え、レビューすべき対象も増える
- 複数の作業を同時に進める並行作業が当たり前になり、作業の中断と再開の回数も増える
この変化は、扱うタスクの数を増やすだけでなく、「進行中」「対応待ち」といった把握しておくべき仕事の状態を増やします。一言でいうと、作業状態を管理する負荷が増えているということです。
私自身、それをまさに実感しています。複数の PR について「どれが自分の番で、どれが相手の対応待ちなのか」を頭の中で覚えておいたり、レビューした内容が反映されたかを何度も確認しにいったり、中断のたびに「何をどこまでやっていたか」を思い出したりするのは、ひとつひとつは小さくても、積み重なると地味に大きな負担です。
では、この負荷が増えると何が問題なのでしょうか。
管理負荷が増えることの問題
作業状態を管理する負荷が増えると、認知的な負担も大きくなります。その結果、必要なことを思い出すのに時間がかかったり、本来やるべきことを忘れてしまったりします。先ほど挙げた私の負担も、根性や注意力で乗り切る話ではなく、この認知的な負担の表れだと捉えると、対策の方向性が見えてきます。
この「思い出すのに時間がかかる」「やるべきことを忘れる」という2種類の症状は、認知科学でいう別々の認知機能への負荷として捉えられます。ここで負荷がかかっているのは、主に次の2つの認知機能だと考えられます。
- ワーキングメモリー（短期記憶）：頭の中で情報を一時的に保持しながら、それを使って考えたり作業したりする能力
- 負荷がかかると、やるべき作業を思い出すのに時間がかかったり、作業の精度が落ちたりしやすくなる
- 展望記憶：将来やるべきことを覚えておき、適切なタイミングで思い出して実行する能力
- 負荷がかかると、待ち状態のタスクの対応漏れが起きやすくなる
※用語の定義は、脳科学辞典「ワーキングメモリー」と『高次脳機能研究』39巻3号の総説「展望記憶のリハビリテーションとトピック」（PDF）を参考にしています。
したがって、この2つの負荷を軽減する仕組みがあればよさそうです。
認知負荷をどう軽減するか
この認知負荷を軽減する仕組みのひとつとして、私は GTD（Getting Things Done）に着目しました。
GTD とは
GTD は、ひとことで言うと個人単位でのタスク管理手法です。David Allen 氏の著書『Getting Things Done: The Art of Stress-Free Productivity』（2001年）で提唱されました。
やり方はシンプルで、タスクを時系列上の状態ごとのリストに分けます。本記事では、作業状態の管理という観点から特に関係の深い次の4つのリストを取り上げます。
- Inbox：これから振り分けるタスクを、ひとまず書き留めておく場所
- NextAction：いま着手すべきタスク（例：レビュー依頼が来た PR、MTG のアジェンダ準備）
- Waiting：自分の手を離れ、相手の対応を待っているタスク（例：レビュー済みの PR の修正反映待ち）
- Someday：いますぐ着手はしないが、いつかやりたいタスク
なお、GTD のリストには、ほかにも複数のタスクから構成される Projects や、日時指定の予定を置く Calendar など、さまざまなバリエーションがあります。
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 の振り分けルールの主なものを抜粋すると、次のようになります。
| 自分の役割 | PR の状態 | 振り分け先 |
|---|---|---|
| レビュアー | レビュー依頼が来て、まだレビューしていない | NextAction |
| レビュアー | レビュー済みで、相手の修正を待っている | Waiting |
| レビュアー | 指摘のあと相手が新たに push した（再レビュー） | NextAction |
| 作成者 | レビューで修正を求められた、または CI が失敗した | NextAction |
| 作成者 | 承認されてマージ待ち | NextAction |
| 作成者 | レビューや CI の結果を待っている | Waiting |
| どちらでも | マージまたはクローズされた | （自動で完了） |
どの行も 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 リストの画面です（タスクはデモ用の架空のものです）。
- レビュー依頼が来た PR や、メールで届いた依頼は NextAction に入る
- レビューを行って相手待ちになった PR は Waiting に移る
- レビュー完了済みの PR は Completed に並ぶ
エージェントを実行するだけで、いま着手すべきタスクと、相手の対応を待っているタスクが、それぞれのリストに自動で振り分けられます。
MVP で検証できたこと
この MVP により、先ほど立てた2つの検証項目は、どちらもクリアできたといえます。
- 検証1（実現可能性）：ローカルの AI エージェントから Google ToDo リストを実際に操作できた
- 検証2（有用性）：リストの登録や状態変更を自動化でき、管理コストが減ったことを体感できた
検証2について、私の運用がどう変わったかを Before / After で整理すると次のとおりです。
| Before | After |
|---|---|
| 1日に何度も GitHub やメールを見にいき、結果を頭の中や手元のリストに反映していた | エージェントの実行1回で NextAction と Waiting が揃う |
| 複数リポジトリの PR の状態をひとつずつ確認していた | 5つのリポジトリを横断して、自分に関係する PR が自動で振り分けられる |
| 「どれが自分の番で、どれが相手の対応待ちか」を頭の中で覚えておく必要があった | リストが代わりに覚えてくれるので、頭の中で把握し続ける必要がなくなった |
なお、これは私自身の運用（N=1）での実感であり、定量的に効果を測ったものではありません。それでも、冒頭で感じていた「作業状態を覚えておくことの負担」が確かに軽くなった、という手ごたえは得られました。
タスクの遂行支援まで踏み込んでみる
ここまでで、MVP により GTD の管理を自動化する価値がありそうだということがわかりました。この MVP を発展させると、リストの管理だけでなく、積まれたタスクの遂行そのものを AI エージェントが先回りで支援するところまで踏み込めます。
一例として、レビュー待ちの PR の要約を試してみました。NextAction には「自分がレビューすべき PR」が並びます。ここに積まれた各 PR について、あらかじめ AI エージェントに要約を出力させておけば、いざレビューするときに PR を一つずつ開いて把握し直したり、その都度「要約して」と指示したりする手間が省けます。
作りとしては、これまでの構成がそのまま活きました。PR の内容を読み取って要約を生成する部分は AI エージェントが担い、その要約を保存して表示する操作は「副作用」なので GAS 側に任せます。 要約は PR ごとに1枚の HTML ページとして GAS から配信し、対応するタスクからそのページへリンクを張るようにしました。つまり、リストの各タスクから要約に一足飛びでたどれる形です。
要約には、単なる内容のまとめだけでなく、AI エージェントによる簡易的なレビューの所見や、その PR にすでに付いている指摘とやりとりの整理も含めるようにしました。また、要約は日本語で出力させているので、英語で書かれた PR でも、要点をつかんでからレビューに入れます。次の画像は、この仕組みで生成した要約ページの一例です。ページのレイアウトや見出しは実際に出力されたものですが、題材の PR はこの記事のために用意した架空のものに差し替えています。
「見るべき点」でレビューの勘所を先に押さえ、「既存の指摘とやりとり」でどの指摘がすでに出ていて対応済みか・未対応かを把握しておけば、同じ指摘を繰り返さずにレビューを始められます。
さらに、この要約は放っておいても散らかりません。PR がマージ・クローズされてタスクが自動で完了すると、それに歩調を合わせて要約のページも自動で片付きます。もともとタスクの自動完了に使っていた仕組みを、要約の後始末にもそのまま流用した形です。おかげで、手元には「いままさにレビューすべき PR」の要約だけが残り続けます。
これも私自身の運用（N=1）での試みですが、リストの管理を自動化した土台の上に、こうしたタスクの遂行支援を一枚重ねられることは実感できました。ここからさらに支援の幅を広げていけば、仕事の効率をより高められる可能性があると考えています。
まとめ
この記事では、AI エージェントの普及とともに増え続ける「作業状態の管理負荷」に着目し、その軽減策として GTD を紹介しました。GTD はそれ自体の運用に管理負荷がかかるという限界がありますが、AI エージェントから Google ToDo リストを操作することで、その管理をある程度まで自動化できることを MVP で示しました。
さらに、リスト管理の自動化を土台として、その上に PR 要約のようなタスクの遂行支援を重ねられることも確認できました。ここからさらに支援の幅を広げていけば、仕事の効率をより高められる可能性があると考えています。
最後までお読みいただき、ありがとうございました。
