複数案件を同時に進行するためのコンテキスト整理術 2026/04/09　西田 将幸 ／ クラスメソッド株式会社 

西田 将幸（にしだ まさゆき） クラスメソッド株式会社 PM兼エンジニアとして複数案件を並行で担当 自己紹介 2 

複数案件を並行する中で起きる 3つの課題 と、AIを活用した解決策 1. MTGの準備が追いつかない 2. タスクが散らばって、抜け漏れる 3. プロジェクトのコンテキストが頭から消える 共通するスタンス: AIに判断を委ねるのではなく、判断しやすい状態をAIに作らせる 今日のテーマ 3 

課題 1 MTGの準備が追いつかない 

痛み 定例があることを直前まで思い出せない 週次MTGだと、前回話した内容を思い出すのに時間がかかる 結果として抜け漏れが発生する 案件が増えるほど、MTGの存在自体が頭から抜ける 課題1: MTGの準備が追いつかない 5 

カレンダーと過去の議事録をAIに渡し、MTG準備を自動化 1. カレンダーから今日〜3営業日先のMTGを自動取得 2. 各MTGに対して AI が準備アクションを提案 3. 前回の議事録から未消化TODOを抽出し、議題案に反映 毎朝のルーティンに組み込むことで、準備忘れが構造的に起きにくくなる 解決策: カレンダー + 議事録で準備を仕組み化 6 

MTGの議事録はmd形式でローカル保存 → AIがいつでも参照可能 議事録の内容を起点に: タスクの作成 → 決定事項・宿題を即 Notion に登録 次回MTGの準備 → 前回TODOの消化状況を自動で議題に含める MTG 終了 → 議事録を md で保存 → AI がタスクを抽出・登録 → 次回MTG 準備時に前回TODO を自動参照 議事録の活用サイクル 7 

Claude Code のカスタムスキル（ /calendar ）で実現 内部では gcalcli コマンドを実行: gcalcli --calendar "[email protected]" --nocolor agenda --details=all --nodeclined 取得した予定を Claude が分析: MTGごとの準備タスクを提案 予定の間の空き時間を算出し活用提案 場所・会議リンク（Meet / Zoom）を表示 Google Calendar MCP もあるが、フィルタリングが安定しなかったので CLI を採用。 CLI なら必要な情報だけ取得できるため、トークン消費も抑えられる カレンダー連携の仕組み 8 

課題 2 タスクが散らばって、抜け漏れる 

痛み 案件ごとに管理ツールも粒度もバラバラ A案件: GitHub Projects / B案件: Slack Canvas / C案件: Backlog 案件タスクだけでなく、個人的なタスクも発生する 発生源が多すぎて、一箇所にまとまっていない → 抜け漏れが起きる 全てを一箇所にまとめないと、優先度もつけられないし、今日何をすべきかの判断がつかない 課題2: タスクが散らばって、抜け漏れる 10 

案件タスクも個人タスクも1つのDBに入る → 全体を一覧できる スマホからも追加・確認できる → 思いついた瞬間に入れられる 簡易DBとして使える → ステータス・予定日・種別でフィルタリング可能 API がある → Claude Code から直接読み書きできる プロジェクト管理ツールだと案件ごとに分かれてしまう。 Notion なら全タスクを横断で管理できる 解決策: Notion に全タスクを集約する 11 

一箇所に集めるだけでは不十分。整理の仕組みが必要 1. タスクをすべて出し切る 頭の中に「やらなきゃ」を残さない 思いついたらすぐ Inbox に入れる → 頭を空にする 2. 棚卸しして整理する Inbox を定期的にレビューし、種別・予定日を振り分ける 「いつやるか」 「本当にやるか」をここで判断する 3. 実行に集中する 整理済みのタスクだけを見て作業する 実行中に「次なにやろう」と考えなくてよく、脳の疲労が抑えられ集中力が上がる 集めたタスクを GTD で整理する 12 

頭の中にタスクを残すと、作業中にも無意識にそれを覚えようとする 「あれもやらなきゃ」が脳のバックグラウンドで走り続ける 集中力が削がれ、目の前の作業の質が落ちる さらに、覚えきれなくなったものから抜け漏れる 出し切ることで: 頭を今やるべき1つに集中させられる 「忘れてないかな」という不安がなくなる 抜け漏れの原因が仕組みの問題に変わり、改善できるようになる なぜ「出し切る」が大事なのか 13 

Inbox に入れる手段が多いほど、抜け漏れが減る 手動: スマホ / PC から Notion に直接追加 振り返りから: /retro weekly で週次振り返り → 「やり残し」 「来週必要」をそのまま Inbox に Epic から分解: 要件だけ書けば、AIがタスクに分解して登録 振り返り → 「これやり残してた」 「来週これ必要」→ Inbox に追加 Epic に要件を書く → AI がタスクに分解して Notion に登録 タスクの入口を増やす 14 

Inbox に溜まったタスクを毎朝整理 → 今日やることだけに集中 トリアージ: /gtd-triage で Inbox のタスクに種別・予定日を対話的に設定 今日のリスト: /today で予定日が今日のタスクだけを表示 朝の数分で全体像を把握してから作業開始 朝のルーティンでタスクを回す 15 

課題 3 プロジェクトのコンテキストが頭から消える 

痛み 1週間触れていないプロジェクトの状況・決定事項・経緯を思い出せない Blocked が放置されて時間をロスする 案件を切り替えるたびに、ドキュメントやチャットを遡ってコンテキストを復元する作業が発生 AI に聞いても、プロジェクト固有の文脈がないから的外れな回答になる 複数案件を並行していると、人間も AI もコンテキストを維持できない 課題3: プロジェクトのコンテキストが消える 17 

/daily コマンド一発で、朝のブリーフィングを自動生成 6つの Subagent が並列で情報収集 → 結果を統合 毎朝、全プロジェクトの状態・Blocked・Nextが自動整理される 解決策: Daily Briefing 18 

/daily は 6つの Subagent を同時起動して情報を並列取得する Agent 取得内容 手段 GTD タスク 今日のタスク一覧 Notion API (自作 CLI) ニュースダイジェスト 技術ニュースの要約生成 RSS / スクレイピング → AI 要約 カレンダー 今日 + 7日分の予定 gcalcli プロジェクト状況 全案件の phase / WIP / Blocked 自作 CLI INBOX 未処理タスク件数 Notion API Epic 締切 締切間近の Epic とリスク判定 Notion API → 結果を統合して daily note と ターミナル報告 を生成 ニュースは 一次情報ソースのみ に絞っている（多すぎると読まなくなる）: AWS News Blog / What's New / Anthropic News / LINE Developers / Chrome / WebKit / MDN Daily Briefing: 並列取得の仕組み 19 

Subagent の結果を分析し、AI が事前準備できるタスクを自動検出。 タスクの性質に応じて 2つのトラック に振り分ける AIだけで完結できる → サブエージェントを自動起動 ゴールが明確で、プロジェクト内の情報だけで成果物を作れるタスク バックグラウンドで勝手に進む → 人間が着手する頃には下書きが完成済み AIだけでは完結しない → プロンプトだけ生成 ユーザーの判断・方針決定が必要なタスク（設計方針、スコープ等） 自己完結したプロンプトファイルを出力 → 新しいセッションでそのまま作業開始できる 種別 例 自動完結 プロンプト生成 meeting-prep 議題の下書き 定例（過去議事録あり） 初回MTG（方針未決） backlog-draft 要件/設計ドラフト タスク分解 設計方針の選定 reply-draft 連絡ドラフト 進捗報告 方針相談 research 事前調査 技術比較 スコープ未定の調査 Daily Briefing: できる限りAIに先回りさせる 20 

プロジェクトごとに CLAUDE.md を配置 状態・決定事項・Blocked を構造化して記録 Claude Code が会話のたびに参照 → コンテキストを即座に復元 ドキュメント追加時は、AIに関連ファイルも連動更新させる 例: 議事録追加 → Feature Hub のステータス更新、ADR の追記 など 人間も AI も同じファイルを見る CLAUDE.md によるコンテキスト永続化 21 

docs/ ├── features/ # 機能ハブ（状態・決定・見積もりの集約点） │ ├── reservation.md │ ├── pre-checkin.md │ └── payment.md ├── requirements/ # 要件（クライアント向け / 社内向けで分離） │ ├── client/qa/ # Q&A 履歴 │ └── internal/ # 社内コンテキスト ├── design/ # DB 設計・データフロー図 ├── decisions/ # ADR （意思決定の記録と却下理由） ├── integrations/ # 外部API 仕様（ローカルに全文保存） ├── research/ # 技術調査・PoC ・スパイク ├── meetings/ # 議事録 └── notes/backlog-drafts/ # 下書き → 正式ドキュメントへ昇格 CLAUDE.md がこの構造のナビゲーションルールを定義 → AI が迷わない 実例: プロジェクトの docs 構造 22 

利用するサービスのAPIドキュメントをmd形式でローカル保存 → AIがネット検索せずに仕様を参照できる APIだけでなく、サービスから送られてくるメールの内容なども md 化 → サービスに関する情報をすべて手元に集める AIに「このAPIの仕様は？」と聞けば、ローカルファイルだけで完結して回答できる integrations/: 外部サービスの情報をローカルに集約 23 

なぜその設計にしたのかを記録するドキュメント # ADR-001: キャンセルポリシーは24 時間前まで ## ステータス: accepted ## コンテキスト - 当日キャンセルが多発し、リソースが無駄になっていた - クライアントから「24 時間前」の要件あり ## 決定 キャンセルは予約日の24 時間前まで可能とする ## 却下した案 - 48 時間前 → クライアントが「厳しすぎる」と判断 - キャンセル不可 → ユーザー体験が悪化 却下理由も残す → 同じ議論を繰り返さない。AIも経緯を踏まえて回答できる ADR（Architecture Decision Records） 24 

Feature Hub = 1機能につき1ファイル。状態・決定・見積もり・関連ファイルを集約 --- feature: reservation status: 実装中 updated: 2026-03-15 --- # 予約機能 ## ステータス - [x] DB 設計完了 - [ ] API 実装中 ← 今ここ - [ ] フロント実装 ## 決定事項 | # | 決定 | 理由 | 日付 | |---|------|------|------| | 1 | キャンセルは24 時間前まで | クライアント要件 | 03/01 | ## 未決事項 - **Blocked**: 決済API の本番キー未発行 ## 関連ファイル - 要件: requirements/client/reservation.md - DB 設計: design/database.md - ADR: decisions/001-cancel-policy.md Feature Hub: 機能の「単一の入り口」 25 

AI が「予約機能について」と聞かれたら、まず features/reservation.md を見る → 状態・Blocked・決定事項が1ファイルで把握できる lifecycle フラグ で陳腐化を防止 active / superseded / archived 人間が読んでも AI が読んでも同じ構造 Feature Hub の効果 26 

Feature Hub に限らず、すべてのドキュメントに YAML frontmatter を付与 ドキュメント種別 主なフィールド Feature Hub feature , status , updated ADR（意思決定記録） decision , status: accepted / rejected 議事録 type: meeting , date , attendees 外部API仕様 source , scraped_at 技術調査 type: research , status , summary AI が grep -r "status: 実装中" で実装中の機能を横断検索できる frontmatter があることで、AI がファイルの役割・鮮度・状態を即座に判別 人間にとってもメタデータが一目でわかる docs 全体の工夫: YAML frontmatter の統一 27 

1. MTGの準備は、前日の仕組みに任せています 2. タスクは一箇所に集めて、毎朝そこだけ見ています 3. プロジェクトの状況は、構造化して永続化しています AIに判断を任せるのではなく、判断しやすい状態をAIに作らせている まとめ: 3つの原則 28 

ありがとうございました 29