PMのエージェントを作ってラクしよう！

認知負荷に限界が来たPM／エンジニアへーーー

PCを開いたらこんなことになっていませんか？

モニターにはGitHubのPR一覧。その裏で、BE／FE／SP／Infraのリポジトリがそれぞれ別ターミナルで開いていて、Slackではクライアントとのやり取りが行われている。

さらに、AIチャットとのセッションがいくつも並列している。

「このタスク、どのリポジトリだっけ？」、「さっきのチャットどのAIセッションでやってたっけ？」

もはやコードを書いている時間よりも、

「どこで・何を・どこまでやったか」を思い出すことに時間を取られてしまいがちです。

こんなPM/エンジニアを兼務する人にとって、この状態は正直しんどいのではないでしょうか。

実際、ここで詰まっているのは、スキルなどではなく**「人間の認知容量」**そのものです。

上記で並べたものはどれも「難しい判断」というより、状態管理の話です。

だからこそ必要なのは、

人間の認知にこれ以上無理をさせないための「設計」を組み込むことです。

この記事では、そのための一つの答えとして、

Notion×マルチリポ×ClaudeCodeで構成した「PMエージェント」の事例を紹介します。

ポイントは以下の3つです。

• 人間は、重い判断だけに集中する
• タスク取得や衝突チェック、CIの監視のような機械的な処理は、エージェントに任せる
• タスクごとに文脈を分離し、「どのタスクがどこまで進んでいるか」を頭で覚えなくていいようにする

この役割分担と仕組みを入れることで、少しでも認知メモリをセーブできるようにします。

実践できるように、考え方とプロセス、具体的な工夫までをできるだけ噛み砕いてお伝えしていきます。

解決の方向性：PMエージェントという設計思想

ここまで見てきたように、問題は「人間が抱えすぎている」ことです。

では、その負荷をどこに逃がせばいいのか。

答えは、「PMのエージェントを作って、仕事の流れそのものを組み替える」というアプローチです。

その中心にあるのが、次の3つの原則です。

原則1：判断は人間 ― 重いものだけ手元に残す

まず決めたのは、「判断のすべてをAIに任せない」ことです。

プロジェクトの優先順位を変える、仕様のトレードオフを決める、レビューで「この設計で本当にいくか」を最終決定する

こういった“重い判断”は、人間がやるべき領域です。

一方で、重くない判断もたくさんあります。

• このタスクはどのリポジトリ（BE/FE/SP/Infra）に紐づきそうか
• どのブランチ／worktreeを使うべきか
• どのPRがどのタスクと対応しているか

こうした「当たりをつける」「候補を並べる」部分は、AIエージェントに任せています。

実際の作業ではAIエージェントがタスクデータベースに溜まったタスクを読み取り、どのリポジトリ・どのコンポーネントに紐づくのかをまずエージェントが推論します。

人間はそれに対して「それで進めよう」「ここだけ修正しよう」と判断しているだけです。

つまり、「ゼロから全部考える」のではなく、AIが出してくれた判断材料の中から重要な意思決定だけを人間がする状態にしていきます。

原則2：作業はAI ― 機械的な処理は委譲する

次に、「作業」は徹底的にAIに投げる前提で設計します。

ここでいう作業とは、たとえばこんなものです。

• データベースからタスクをまとめて取得し、整理する
• タスクごとにブランチ／worktreeを切り、必要なファイルを開く
• 衝突しそうな変更がないかざっと確認する
• draft PRを作り、最低限の説明を書く
• CIが通るまで結果を監視し、落ちたらログを拾ってくる

どれも“頭を使う”というより、決まりきった手順をなぞるタイプの処理で、人間がやると地味に時間を食う一方で、やり忘れ・見落としも起きやすいタスクです。

このような機械的な処理は、できる限りエージェント側に寄せています。

人間は、「このタスクを今やる／やらない」や、「この実装方針で本当にいくか」、社内外とのコミュニケーションに集中し、

そこに至るまでの細かい操作や監視は、なるべく触らなくていいようにしています。

原則3：文脈は混ぜない ― 隔離して精度を守る

そして3つ目が、「文脈を混ぜない」という原則です。

長い文脈を1つのセッションに詰め込み続けると、

AIの精度は落ちてしまいます。

人間と同じで、「このチャットって、どのタスクの話だっけ？」となってしまいます。

そこで、実際の作業では「1タスク = 1 worktree」 を基本単位とし、対応するAIセッションもタスクごとに分けています。

つまり、

• 各タスクは専用のworktreeで物理的に分離
• そのworktreeに関する会話・実装・レビューは、専用のサブエージェントに紐づける
• 親エージェントには、生ログではなく「要約された結果」だけを返す

こうすることで、

• AI側は、関係ないタスクの履歴に引きずられにくくなる
• 人間側も、「このタスクはこのworktree／このセッション」と頭を切り替えやすくなる

結果として、「どのタスクがどこまで進んでいるか」を把握しやすくなります。

全体アーキテクチャ：プロセスと全体像

ここからは、「PMエージェントが実際に何をしているのか」を、ひとつの流れとして見ていきます。

ポイントは、処理をステップごとに追えるプロセスとして設計することです。

人間の頭の中では、「タスクを拾う」「どのリポジトリか判断する」「ブランチを切る」「実装する」「PRを出す」「CIを見る」…といった作業が、並列で走っており、メモリを圧迫する要因となっています。

その結果、「いま自分は何のどのフェーズにいるのか」が曖昧になり、抜け漏れや戻りが増えていく。

これを機械的なステップに分解し、PMエージェントが 上から下まで順番に処理するパイプラインとして設計します。

全体の流れは、次のとおりです。

タスク取得→ 関連コンポーネント推論→ 衝突分析→ プラン追記→ 並列実装
→ PR前レビュー→ draft PR→ CI→ 完了処理

人間が頭の中で「なんとなく」やっていた作業が、このプロセスのどこに相当するのかを整理し直し、可能な限りエージェント側の処理として固定化していきます。

まず、タスク取得〜関連コンポーネント推定〜衝突分析 のブロック。

• タスク管理ツール（弊社ではNotion）からタスクを一括で拾い上げる
• それぞれのタスクが「どのサービス／どのモジュール／どのリポジトリ」と関係しそうかを、エージェント側で推定する
• すでに進行中の変更とぶつからないかリスクをざっと見ておき、衝突度合いを判定する

何をAIに任せているかというと、人間が毎回やっていた「これってどのコード触ればいいのか」「他の変更と衝突しないか」という確認作業をプロセスの一部として肩代わりさせています。

次に、プラン追記〜並列実装〜PR前レビューのブロック。

• 衝突面で問題なさそうなタスクについては、必要に応じて「どういう手順で直すか」の実装プランをタスクに追記する
• 1タスク = 1 作業スペース（worktree など）を原則に、サブエージェントがそれぞれのタスクを並列で実装していく
• ある程度コードが固まったところで、「この変更は何をしているのか」「どこに注意すべきか」といった PR 前レビューのたたき台をエージェントが用意する

ここでは、「タスクを粒度よく分ける」「最終判断をする」のは人間が担当しつつ、

そこに至るまでの分解や手順の整理、実装の手を動かす部分を、できるだけエージェントに寄せています。

最後が、draft PR〜CI〜完了処理 のブロックです。

• エージェントが draft PR を作成し、必要最低限の説明やラベル付けを行う
• CI を実行し、その結果を監視し続ける
• CI がパスしたタスクだけを「完了候補」として扱い、「どの作業スペースをクリーンアップするか」「どの変更はまだ要修正か」を整理する

ここまでを一連のフローとして PMエージェントに握らせることで、

• どのタスクが、いまプロセスのどのステージに詰まっているのか
• 人間が見るべきはどのポイント（設計判断／レビュー／マージ判断）なのか

が、エージェントにも人間にも分かるようになっていきます。

言い換えると、PMエージェントは、

このプロセスのレールの上で管理する司令塔のような存在で、タスク管理ツールに載ってからPRがマージされるまでの間に起きることを管理します。

人間は、重い判断ポイントだけに集中し、その前後の細かいステップは、なるべく意識しなくてよい。

そのための全体アーキテクチャが、

この「タスク取得 → 関連コンポーネント推定 → 衝突分析 → プラン追記 → 並列実装 → PR前レビュー → draft PR → CI → 完了処理」という動線になっています。

安全装置：暴走させないための工夫

インフラや本番に近い環境を触る現場では、「AIがコマンドを打って、取り返しのつかないことにならないか？」という懸念があると思います。

この懸念をできるだけ先回りして潰すために、いくつかの「安全装置」を仕込みます。

重要なのは、「プロンプトで気をつけるように指示する」のではなく、物理的に・構造的に危ないことができないようにすることです。

その仕組みは以下の方法で取り組みます。

bash 経由での破壊的なコマンドや、Terraform・AWS・Git の取り返しのつかない操作などは、hook で検知し、一定条件を満たしたものは問答無用で denyする

どれだけモデルの性能が上がっても、「予期せぬエラー」がゼロにはならない前提のもとで、最後の一手はツール側で守る設計です。

同じ発想で、タスク管理ツールに対しても保護をかけます。

仮にNotionだとすると、

AIエージェント専用の Database View を用意し、エージェントはそのビューだけを触るように制限します。

人間が日々使っているボードには直接手を出させず、view-lock の hook で「人間用ビューへの誤ったクエリ」を弾きます。

これにより、「気づいたらボード全体のフィルタやグループが壊れていた」といった事故を防ぎます。

worktree をタスクごとに生やしていくと、放っておけばどんどん増えてカオスになりますが、状態別に自動クリーンアップの方針を決めています。

• すでにマージ済みの残骸は、自動的に削除する
• 進行中（OPEN）のものは、まだ触らない
• PR がない／クローズ済みのものは、ユーザーに確認を促してから片付ける

こうした地味なルールをエージェント側に埋め込んでおくことで、「どの作業スペースを消していいか」を人間が毎回判断しなくて済みます。

また、「検証はどこでやるか」も安全性と認知負荷に直結するポイントです。

重い検証は可能な限り CI に寄せ、ローカル環境では lint と型チェック程度に絞っています。これにより、ローカルは軽く保ちつつ、「本当に壊れないかどうか」のチェックは標準化されたパイプラインに任せることができます。

これらの安全装置があることで、「AIエージェントを実運用に乗せたときに、現場が本当に安心して任せられるか」を左右する土台になっています。

まとめ：ボトルネックは人間の認知！

この記事で伝えたいのは、「ボトルネックになっているのが人間の認知そのものだ」という認識です。

• 判断は人間に残しつつ、機械的な作業はエージェントに任せる
• タスクごとに文脈を分け、「覚えなくていい状態」を作る
• プロセスという一本の流れに落とし込み、抜け漏れを構造的に減らす
• その上で、安全装置を多層的に仕込んで「壊さない」前提をつくる

という形で仕事の設計そのものを行っています。

「人間が本当に考えるべきところだけに、ちゃんと集中できるようにするための、認知の外付け装置」です。

まずは「自分の認知を一番食っているのはどこか」を見つけて、そこから少しずつ、「判断」と「作業」、「文脈」と「安全装置」を分離するところから始めてみてください。