「あの件、ビジネス側に投げたあと、どうなったんだっけ？」
複数のプロダクトを同時に見ていると、こういう「ボールは自分にないけど、把握はしておきたい」案件が次々と頭の隅に溜まっていきます。Claude Codeに情報収集やドキュメント作業を任せられるようになったぶん、セッションは増え、並行作業も増え、今度は覚えておくこと自体が追いつかなくなりました。
そこで、「もう自分で覚えなくていい」をコンセプトに、自分の脳みそをClaude Codeの外に再現してみました。この記事では、その仕組みを紹介します。
仕組みの全体像
まず全体像を紹介します。
構成としては下記の4つのレイヤーに分けて、それぞれをファイルとClaude Codeのスキルで持たせています。
| レイヤー | 役割 |
|---|---|
| dashboard | 今、自分が何を気にしているかを書く主観の場。これが脳みその再現。 |
| context.md | プロダクトの客観的な状態を書く事実の場 |
| tasks/ | 細かなアクションの受け皿。これはタスクリスト |
| memory/ | セッションをまたぐ前提と学習 |
ドキュメントファイルとしてdashboardを作っておいてもよいのですが、一覧性のためにhtmlとして見やすい形にしています。
これらは独立して並んでいるのではなく、ソースから正データ、表示へと続く3段の階層で動いています。
[ソース層]
JIRA / Slack / GitHub / Gmail / 議事録 / Datadog
│
│ /organize-meeting・/slack-watch・/mail-watch などのスキル群が加工
▼
[正データ層]
context.md：プロダクトの事実
decisions/：判断の経緯
tasks/：具体アクション
│
│ /board-update が2時間おきに再構築
▼
[表示層]
dashboard：脳の可視化
▼
人間の判断
dashboardが主観で、context.mdとdecisions/が客観。これを分けて、ソースから表示までの流れを片方向に固定しています。表示層から正データ層への逆流は禁止。この階層を決めてから、メンテナンスが安定しました。
レイヤー1：dashboardで脳を可視化する
「今、自分が何を気にしているか」を1ファイルにしたものです。タスクリストにするのではなく、記憶していることをそのまま再現することを重要視しています。
# 脳内
## 📬 レビュー待ち（GitHub）
## 🔔 GitHub通知
## 📧 メール要返信
## 🔴 脳みその真ん中（3〜5件）
いま最も判断リソースを割いているもの。
## 🟠 脳みその周辺（5〜8件）
近日中に判断が飛んでくる可能性や手を動かさないといけない可能性があるもの。
## 🟡 端にひっかけているもの
直接の判断はないが、動向を把握しておくべきもの
## 🔘 忘れた
脳から落ちたもの。2週間で自動削除
設計上の工夫が2つあります。
ひとつめは、項目を置く基準を「自分にアクションがあるか」ではなく「判断が飛んでくる可能性があるか」にしたことです。アクション基準だとただのタスクリストになり、「セールス経由でもらっていた要望、検討中のまま放置してないか？」といった 自分にボールはないが、把握しておく必要があるもの や、以前開発から共有を受けて一応覚えておいた方がいいものが漏れます。
ふたつめは 🔘 忘れた セクション。脳から落ちた項目を即削除せず、忘れた日と一緒にここに移して2週間バッファとして残す。定例で突然話題に戻ったときに「あれの最後の状態はこうだった」を拾える。2週間経つと自動で削除されます。context.mdに事実は残っているので、情報自体が失われるわけではないのも安心です。
実データをもとに生成したイメージ
dashboardは2時間おきに再構築する
dashboardは手書きで維持しているわけではありません。/board-update スキルが2時間おきにソースを並列で読み、前回のdashboardと差分を取って項目を追加・移動・更新します。
JIRA → チケットのステータス変化、新規作成、ブロッカー
Slack → 未処理メンション、新トピック
GitHub → レビュー待ちPR、未対応コメント
Gmail → /mail-watch が拾った要返信メール
tasks/ → タスクファイルの進捗・議事録から抽出したタスク
context.md → 各プロダクトの客観的な状態
↓
dashboard
JIRAでチケットがDoneになっていたらdashboardから消える。Slackで返信のいる新しい依頼が来ていたら🟠に追加される。GitHubのレビュー待ちPRと要返信メールは、4色の優先度ゾーンの上にある固定セクションに並ぶ仕組みです。
自分が触らなくてもdashboardが古びない。この自走性がこの層の中心にあります。
レイヤー2：context.mdでプロダクトの客観状態を1ファイルにする
dashboardが主観なら、context.mdは客観。プロダクトごとに1ファイルあって、「現在のスプリントで何が進行中か」「直近のリリースは何だったか」「既知の問題は何か」を、誰が見ても同じ事実として書きます。
dashboardが「自分がこの施策のどこを気にしているか」を載せるのに対して、context.mdには主観を入れない制約を持たせています。正データはcontext.mdとdecisions/にあって、dashboardはその表示レイヤーにすぎない、という階層を強制しています。
施策がリリースされるとcontext.mdに事実として記録され、decisions/に「なぜこの仕様にしたか」が残る。するとdashboardからは自然に消えていく、というサイクルができます。
context.mdも定期的に更新処理を走らせるようにしています。自分は特に会議での更新が多いので、議事録の要約スキル /organize-meeting が担当します。会議後の議事録を該当プロダクトのフォルダに振り分け、意思決定を検出してdecisions/に記録し、必要ならcontext.mdを更新する。会議終わりのファイリングを自分でやらなくてよくなりました。
レイヤー3：tasks/で細かなアクションを受け止める
dashboardでタスクを管理していない分、タスクは別のレイヤーで扱っています。
例えば会議でさらっと言う「その件、会議設定しますね」「来週までにデータ出しておきます」「○○さんに連携しておきます」のような一言は、JIRAチケットを切るほどでもなく、dashboardに置くと粒度が合いません。
また、誰かに言われたわけではなく自発的に行っている作業（この記事の執筆とかそうですね）も、どこにも残らないため、tasks/ のフォルダで管理しています。
1タスク1ファイル、中身はタイトル・背景・目標期日・完了条件くらいのシンプルなMarkdownとしています。
とはいえ、dashboardとtasks/は連動しているため、二重で見ることはほぼありません。
レイヤー4：memory/でセッションをまたぐ前提を残す
ここまでの3レイヤーとは別に、Claude Codeの memory/ でセッションをまたぐ前提と学習を保持しています。同じ失敗を繰り返さないこと、セッションごとに前提を説明し直さなくていいこと、この2つに効いています。
memory/ 部分は@mura_massann さんが別記事「Claude Codeに「意識しなくてもできる」を実装した話──学習する記憶の3層構造」にまとめているものが大変わかりやすく、また学習にまで踏み込んだ記事となっております。ぜひ参考にしてみてください。
おわりに
仕組みを入れる前は、「あれ、まだ覚えてたかな」という小さな不安が、常にバックグラウンドで動いていました。会議中も移動中も、頭のどこかでタスクの棚卸しが走っている感覚です。覚えておくこと自体が、地味に脳のリソースを食っていました。
今は、気にすべきことはdashboardが、事実はcontext.mdが、宙に浮くアクションはtasks/が、セッションをまたぐ前提はmemory/が覚えていてくれます。しかもdashboardは2時間おきに勝手に再構築されるので、自分が更新を忘れても古びない。だから朝は、ファイルを開いた瞬間に「今はこれを考えればいい」とわかる状態から1日を始められます。
覚えることを手放したぶん、考えることに使える脳が戻ってきた。 これが、自分の脳みそを外に出してみていちばん効いた変化でした。覚えるのをやめて、ようやく考えられるようになった、とも言えます。
この先やろうとしていること
現状の4レイヤーは「気にする・事実を覚える・アクションを切り出す」までを外部化していますが、最後の判断やアクション自体は自分がやっています。ゆくゆくはそういった一次判断や日常の中での返信は自動で進めてもらい、自分は判断結果を受けて差し戻すかどうかだけ見るような形にしていきたい。脳の入出力を移植したあとは、考える部分そのものをどこまで譲れるかということに挑戦していきたいと思います。