はじめに：タスク管理がエンジニアを殺す
エンジニアの生産性のボトルネックは、もはや「コードを書くスピード」ではありません。
ChatGPTがどれだけ優秀になっても、私たちは相変わらず「タスク管理」という沼に時間を吸われています。
やりたいことを整理し、タスク化し、見積もり、優先順位を決め、カレンダーに入れ、進捗を見直し、修正する……。
この 「タスクのためのタスク」 が、私たちのフロー状態（没頭）を容赦なく破壊します。
- 割り込みひとつで集中が切れる
- Notionを見返して「あれ、何やるんだっけ？」となる
- 期限切れタスクが目に入り、焦って計画を引き直す
- 気づけば30分が溶けている
私はついに腹を決めました。
「人間はゴールだけ言う。あとはAIが全部やれ」 と。
その思想で実装を進めているのが、Cognitive Flow Agent です。
Cognitive Flow Agent とは何か
一言でいうと、 「専属の敏腕PM（プロジェクトマネージャー）をローカル環境で飼う」 システムです。
目指しているUX
- チャットでゴールを呟く: 「技術ブログを立ち上げて、月1万円稼ぐところまで持っていきたい」
- 壁打ち: AIが「ターゲットは？ 技術スタックは？」と逆質問して前提を掘り下げる。
- WBS生成: 依存関係まで考慮したタスクリストを自動生成。
- 自律実行: AIができるタスク（調査、下書き）は勝手に実行。
- スケジュール: 残りのタスクをGoogleカレンダーの空き枠に自動でねじ込む。
ユーザーである私は、「AIが敷いてくれたレールの上を、ただ走るだけ」。
意思決定のコストを極限までゼロにする世界を目指しています。
技術構成とアーキテクチャ
「で、どうやって実現してるの？」というエンジニアの疑問に答えるべく、現在のアーキテクチャを公開します。
LangGraph を中心に、状態管理・推論・実タスク連携を有機的に結合させています。
システム全体構成図
エージェント内部ロジック詳細図
技術選定
ただ流行りの技術を並べたわけではありません。それぞれの採用には明確な理由があります。
| 技術 | 採用理由 |
|---|---|
| FastAPI | PythonネイティブなAIライブラリ群との親和性が最強。ここをNode.jsにすると型定義が重複して死にます。 |
| LangGraph | PMの業務は「一直線」ではありません。「計画→実行→評価→修正」というループを書くために必須でした。 |
| gpt-5-mini | エージェントは思考を何周も回します。推論コストを気にせずガンガン回せるこのモデル一択です。 |
| WebSocket | AIが裏で動いている様子（思考ログ）がリアルタイムでフロントに飛んでくる体験は、UX上不可欠です。 |
| APScheduler | ユーザーが寝ている間もタスクを実行し続けるための心臓部です。 |
| FAISS (RAG) | 「前に話したあれ」を忘れないために、過去の文脈をベクトル化して保持します。 |
実装の深掘り
1. LangGraph
エージェントは単なるスクリプトではなく、「状態（State）」を持ちます。
class AgentState(TypedDict, total=False):
messages: List[Any]
current_phase: Literal["goal_definition", "wbs_generation", "idle"]
project_definition: Optional[dict]
generated_tasks: Optional[List[Any]]
user_id: str
iteration_count: int
従来の LangChain の Chain と決定的に違うのは、 「情報が不足していたらユーザーに質問する」 という分岐がグラフとして定義されている点です。
# 状態に応じた条件分岐の定義
workflow.add_conditional_edges(
"extract_definition",
route_after_extraction,
{
"validate": "validate_definition", # 定義完了なら検証へ
"ask_more": "ask_questions" # 不足があれば質問へ（ループ）
}
)
この「人間の試行錯誤」をコードで表現できるのが LangGraph の強みです。
2. WBS生成
JSON生成において、以前は崩れたフォーマットが返ってくることに悩みましたが、Pydantic × Structured Output で世界が変わりました。
# Pydanticで「こう返せ」と型を定義
structured_llm = llm.with_structured_output(WBSOutput)
# 推論実行（依存関係まで含めて破綻しないWBSが生成される）
result = await structured_llm.ainvoke(prompt)
JSONパースエラーの対策コードを書かなくていい。これだけで開発スピードが倍になりました。
3. フロントエンドとのリアルタイム連携
「AIが今何をしているか」が見えないと、ユーザーは不安になります。
FastAPI の WebSocket を使い、エージェントの思考プロセスを逐次フロントに流しています。
await websocket.send_json({
"type": "thought",
"content": "ターゲット層が曖昧なため、追加質問を生成中..."
})
画面上でプロジェクトが勝手に進んでいく様子を眺めるのは、エンジニアとして最高の快感です。
4. RAG と Notion連携（現在進行中）
ここが現在、最も苦戦している「泥臭い」部分です。
-
RAG (FAISS):
会話が長くなるとコンテキストが溢れます。「先週言ってたあの件」をロストしないよう、会話履歴をベクトル化して FAISS に突っ込み、必要な文脈だけを都度検索する仕組みを組み込んでいます。
-
Notion API:
OAuth接続やページ生成の非同期化を進めていますが、Rate Limit との戦いです。
「WBSができた瞬間にNotionの全ページが埋まっていく」という未来を目指して、キューイング処理などを調整中です。
課題と今後の展望
実装してみて、まだ解決できていない課題もあります。
- 記憶の爆発: 長期プロジェクトではCheckpointerを使って記憶を「要約・圧縮」する仕組みが必要。
-
モチベーション変数: 人間は機械ではありません。「今日はやる気が出ない」という私の感情を、どう
AgentStateに組み込み、スケジュールを緩和させるか。
最後に：これは生産性ではなく「自由」の話
Cognitive Flow Agent は、単なる業務効率化ツールではありません。
私たちが本当にやりたいこと（創造的な開発や学習）に集中し続けるための「自由」を手に入れる技術です。
「タスク管理は大嫌いだが、作りたいものは山ほどある」
そんなエンジニアが、もっとモノづくりに没頭できる世界を目指して開発を続けます。
もし興味がある方や、LangGraphの知見を共有したい方がいれば、ぜひコメントをください。