Notion Tasks DB 駆動 — 人間と AI のアクション管理を一元化する

人間のアクションと AI のアクションが分散すると追えない

AI エージェントを業務に組み込むと、アクションの発生源が増える。

スクレイピング後の提案レビュー、クライアントへの重要返信、契約書の確認——これらは人間が判断しなければならないタスクだ。一方で提案文の自動提出、Sheets への書き込み、週次レポートの生成はAI が自律実行するタスクになる。

問題は「どこに何があるか」が見えなくなることだ。Gmail の未読に埋もれた依頼、Slack のスレッドに残ったアクションアイテム、スクリプトのログに流れた実行結果——追うべき情報が複数ツールに散らばると、人間のオーバーヘッドが増大する。

課題：メール・ツール・ログに散らばる「やるべきこと」

典型的な問題はこうだ。

AI がスクレイピングを完了し「A ランク案件が 3 件あります、確認してください」とログに出力する。しかし人間がそのセッションを見ていなければ、そのアクションアイテムはどこにも残らない。Claude Code のセッションが終われば流れて消える。

別のケースでは、自動生成した返信下書きを確認してほしいという依頼が Gmail の下書きフォルダに溜まる。確認待ちなのか送信済みなのか、チェックしなければわからない。

これらの問題の根は同じだ。AI が生成したアクションアイテムが、人間が普段見る管理ツールに投入されていない。

アプローチ：Notion Tasks DB に集約 — 人間も AI も同じ DB を見る

八雲では Notion を「人間のアクション + 視覚管理」の層と定義している（AI 駆動開発の全体設計参照）。

具体的には Tasks DB（内部コード名: tasks_database）というデータベースを1つ用意し、人間が処理すべきタスクはすべてここに投入する。

AI は次のタイミングで Tasks DB にタスクを作成する。

スクレイピング完了後、S/A/B ランク案件を [提案レビュー] タスクとして投入
契約書・NDA の確認が必要な場合は [契約確認] タスクとして投入
返信下書きの確認が必要な場合は [返信確認] タスクとして、複数下書きがあっても1タスクにまとめて投入

人間は Notion の project-management ビューを見れば、今日確認すべきことが全部わかる。Gmail を掘り返す必要はない。

構造：ステータスが AI 実行のトリガーになる

Tasks DB のステータスは 4 段階で管理する。

レビュー待ち ──承認──▶ 承認済 ──AI実行──▶ 完了
     │
     └──修正依頼──▶ 差し戻し ──再ドラフト──▶ レビュー待ち

ポイントは「承認済」ステータスが AI 実行のトリガーになることだ。

人間がタスクを確認し「承認済」に変更した瞬間、AI はそのタスクを拾って対応するアクション（提案文の自動提出など）を実行し、完了したら「完了」に更新する。

このフローの利点は、人間が何をしたかが Notion の履歴として残ることだ。「いつ誰が承認したか」「どの案件がどのステータスにあるか」が一目でわかる。

スクレイピング後に投入される提案レビュータスクは、媒体×ランクの9種類（3媒体 × 3ランク）を月別の親タスクにまとめ、個別案件を子タスクとして紐付けるバッチ構造を採用している。Notion のツリー表示でS/A/Bランクをまとめて一覧できるのはこの設計のためだ。

launchd polling との連動

承認済タスクを AI が自動で拾う仕組みとして、task_sync.py を macOS の launchd で5分おきに実行している（launchd × Notion Tasks の詳細参照）。

launchd (5分おき)
  └─ task_sync.py
      ├─ Notion DB をポーリング（ステータス=承認済）
      ├─ アクション種別でディスパッチ（提案レビュー → /submit）
      └─ 完了後にステータスを「完了」に更新

ポーリング間隔を5分にしている理由は Notion API のレート制限（平均 3req/s）との兼ね合いだ。1回のポーリングで複数タスクを処理する設計なので、5分で十分余裕がある。

即時実行したい場合は Claude に「承認したよ、出して」と話しかけると、Claude が Notion ステータスを「承認済」に更新してから直接スキルを実行する。自動化と手動操作を同じデータモデルで統一しているため、どちらのルートでも同じ結果になる。

なお task_sync.py は親タスク（バッチコンテナ）をスキップし、子タスクの「承認済」のみを処理する。AnotherWorks のタスクは「気になる」ボタンの手動クリックが必要なため、承認済 になっても自動で「完了」にせず、人間の手動確認待ち状態を維持する設計にしている。

運用してわかった効果と落とし穴

効果として実感したこと。

タスクの発生源が AI になっても、人間の確認フローは変わらない。Notion を見るだけで「AI が何を待っているか」がわかり、承認するだけで自動実行が動く。認知負荷が一箇所に集約されたことで、こまめにログを確認する必要がなくなった。

運用で見えてきた落とし穴。

最初は AI のログや実行結果を Notion に全部書き込もうとした。しかしすぐに「スクレイピング結果などの実行ログは Sheets で管理し、Notion には人間の判断・承認が必要なものだけ投入する」という原則に落ち着いた。Notion に何でも入れると、今何を確認すればいいかが埋もれる。

タスクタイトルの命名規則も重要だった。[アクション] 案件概要（媒体） という形式を固定し、アクションを角括弧で統一することで、Notion ビューでフィルタリングしやすくなる。フリーフォーマットにすると検索しにくくなる。

Drive や Sheets のデータを Notion の page body に書き込みたくなるが、これも禁止にした。Drive Doc はドラフト URL でリンクするのみ。二重管理が起きると「どちらが正しいか」という問題が生まれ、かえって管理コストが増える。

もう一点、重複投入の防止。案件ID を lancers:5527535 のような媒体プレフィックス付きの形式で持たせ、同一案件を重複投入しない冪等設計にしている。これがないと、スクレイピングのたびに同じ案件のレビュータスクが増殖する。

まとめ

Notion Tasks DB を人間と AI の共通インターフェースにすることで、アクションアイテムの散在を防げる。設計の要点は3つだ。

投入対象を絞る — AI が一気通貫で完結できるタスクは Notion に入れない。人間の判断が必要なものだけ
ステータスを実行トリガーにする — 人間が承認したことが機械的なトリガーになり、手動連絡なしで AI が動く
Sheets / Drive とのレイヤー分離を守る — 実行ログは Sheets、判断・承認は Notion、書類の本体は Drive

AI エージェントを業務に組み込む際、「人間がどこを見ればいいか」を一点に絞ることが自動化の継続運用につながる。

関連記事

八雲の AI 駆動開発 — Synapse アーキテクチャ全体像
launchd × Notion Tasks 連動 — ポーリング実装の詳細