【AI時代のプロジェクト管理】記録が残らないのは罪だと思ったので、案件の全記録をAIが引ける形に作り替えた

このAI時代に、全ての記録が残らないままにしておくのは罪なのではないか。

そう考えて、担当している受託開発案件の1つ(以下「この案件」)の全ての情報を、Google Driveに入れることにした。

会話はSlackで流れていく。会議の文字起こしは生成された瞬間から、誰にも読み返されない。チケットは閉じたら忘れられる。人間には読み返す時間がないからで、それは仕方がない。だが、いまはAIがいる。時間が無限にある読み手が現れたのに、記録のほうが読める形で残っていない。もったいない、では済まない気がした。

ただ、フォルダに放り込むだけでは、AIも人間も読まない。読まれるためには設計が要る。作ったのは、5つの部品からなる仕組みである。

1. 集める:3つの情報源を、Driveの一箇所へ
2. 揃える:バラバラの記録を、共通フォーマットの「仕訳帳」に転記する
3. 育てる:仕訳帳とは別に、論点ごとの「元帳」とAI用の「目録」を持つ
4. 届ける:週報、日報、「あれどうなった?」への回答として、人の行動に返す
5. 疑う:AIの裁量を絞り、機械の検品で守り、人の指摘で直す

作ってみると、あちこちで想定外が出た。

この記事は、5つの設計と、途中で出た課題をどう潰したかの記録である。PMの目線で書くので、プログラムの実装詳細には踏み込まない。「AIと自動化で、プロジェクト運営のどこがどう変わるのか」を持ち帰ってもらうのがゴールである。

動かしているのはClaudeのエージェント環境だが、設計自体は特定のAIに依存しない。データの扱いは、社内の生成AI利用規程と各ツールの非学習設定(入力を学習に使わせない設定)の範囲で行っている。

この仕組みの語彙は、経理の帳簿から借りている。

この記事の言葉	意味
仕訳帳	週ごとの記録ファイル。3つの情報源を共通フォーマットに転記したもの
元帳	論点ごとのページ。いまの状態と決定の履歴を持つ。数値や決定の横断一覧ページも含む
目録(INDEX)	「何を聞かれたら、どの元帳を開くか」のAI用ルーティング表
検品	機械が生成物に対して行う16項目の検証
AI	大規模言語モデル。裁量があり、同じ入力でも出力が揺れる
プログラム	決定論の処理。同じ入力なら必ず同じ出力
機械	AIとプログラムの総称(人間でない側)
W33、W34	ISO週番号。年の第33週、第34週のこと

設計1:集める(3つの情報源を、Driveの一箇所へ)

幸い、この案件の情報源を数えたら3つしかなかった。

• Slack:日々の会話。9チャンネル、週に300件前後
• Meet:会議。Google Meetの標準機能としてGeminiが文字起こしを自動生成する。内部MTGが週2〜3本、外部定例が週1〜2本
• Backlog:チケットとコメント。担当、期限、状態の変更履歴

この3つは、MCP(Model Context Protocol。AIが外部ツールに直接アクセスするための仕組み)とGoogle Apps Script(GAS)を使えば、全て一箇所に集められる。SlackとBacklogはAIが直接取りに行く。Meetの文字起こしは、Geminiが生成したドキュメントをGASが拾ってDriveの収集フォルダに放り込む。

そして毎週月曜の朝、集めたものを1週間分のフォルダに構造化して蓄積し、そこから週報と日報が生まれる。全体はこういう形をしている。

課題:AIに整理をやらせたら、権限エラーで全滅した
Geminiが生成した文字起こしファイルの整理(社内/社外/資料へのフォルダ振り分け)をAIに任せたところ、全件が権限エラーで止まった。AIが使うDrive連携は、他人(この場合Gemini)が作成したファイルを動かす権限を持っていない。

そこで分担を引き直した。振り分けは、本人の権限で動くGASが収集した直後にやる。AIは週次で「振り分け漏れがないか」を点検して報告する(閲覧権限があれば足りる)。実行役と監査役が分かれて、結果的に二重の安全網になった。

**自動化の分担は、理想ではなく権限で決まる。**いまの分担はこうなっている。

担当	やること
GAS(自作スクリプト)	文字起こしの収集と、ラベルによるフォルダ振り分け
AI + プログラム(自動)	取得 → 構造化 → 検品 → 週報生成 → 元帳と目録の更新、の週次処理と毎営業日の日報
人間	会議名へのラベル付けと、週報の送信ボタン

この収集フローで人間に残る仕事は2つで、それぞれ理由がある。会議名の先頭に【社内】か【社外】を付けておくと、文字起こしの振り分けはラベルだけで機械判定できる。どちらも付いていない会議は「分類不明」として検出されるので、付け忘れが黙って誤分類される代わりに、異常として目に見える。送信ボタンのほうは、週報の投稿先が他社と共有しているチャンネル(Slack Connect)で、この案件のチャンネルではアプリからの自動投稿が許可されていないからだ。下書きまでは自動、最後のクリックだけ人間。自動化の設計は、こういうプラットフォームの制約が最後の形を決める。

課題:取れない日が必ず来る
たとえばBacklogのデータは、取得処理が業務PC上で動くため、PCが起動していないと取れない。自動実行は「毎週必ず全部取れる」を前提にすると、最初の連休で壊れる。

だから週次の実行は「PCが確実に開いている月曜の朝」に寄せ、それでも取れなければ「未取得」と記録して終了し、翌営業日に自動でリトライする。

地味な図だが、ここには運用思想が2つ入っている。1つ、「0件だった」と「取得できなかった」を明確に区別して記録する。2つ、検品に落ちたら黙って進めず、必ず人に通知して止まる。

自動化が信頼を失うのは、間違ったときではなく、間違ったまま黙って走り続けたときである。

設計2:揃える(バラバラの記録を、共通の仕訳帳へ)

集めた直後のデータは、3つが3つとも別の顔をしている。

Slackは口語の断片で、1つの話題が10本のスレッドに散る。Meetの文字起こしは逆に長大で、1本が2〜3万字ある。Geminiは要約も付けてくれるが、それは全体の1割ほどで、残りの9割は発言をそのまま書き起こした生の記録である。Backlogは構造化されているが、「担当が変わった」「期限が延びた」という一番大事な動きが、変更履歴として各チケットの奥に散らばっている。

経理の仕事に例えると分かりやすい。手元にあるのは、走り書きの領収書(Slack)と、長い契約書(文字起こし)と、形式の違う請求書(Backlog)の山である。経理はこれをそのまま保管しない。仕訳帳という共通の形式に転記してから保管する。どの伝票から来たかの番号を添えて。

やっていることは、これと同じである。3つの情報源を、毎週、共通フォーマットのファイルに転記する。1メッセージ1セクション、発言者と時刻つき、そして全ての行に「元の発言に1クリックで飛べるリンク」を添える。仕訳帳における伝票番号にあたるものだ。

転記のルールのうち、効いているものが4つある。

0件も書く。 投稿がゼロだった週のチャンネルにも「投稿なし」というファイルを作る。空白を放置すると、AIは気を利かせて他の情報で埋めにくる。「無かった」という事実も、記録である。

黙って捨てない。 表示の都合で件数を絞ったときは、必ず「他N件」と書かせる。100件を10件に絞ること自体は構わない。絞ったことを隠した瞬間に、読み手は「全部で10件だ」と誤解する。

翻訳は置換ではなく追記。 勤務先にはオフショア開発を使う案件があり、そうした案件のSlackには日本語と海外メンバーの言語が日常的に混在する。この案件もそうで、外国語の発言は原文を残したまま、末尾に日本語の要旨を併記する。訳文で上書きした瞬間、原文は永遠に失われるからだ。日本語以外の発言に要旨が付いていなければ、検品で止まる。

原文を捨てない。 文字起こしの生の記録は、Geminiの要約だけ残せば量が9分の1になる。それでも捨てない。原文とリンクさえ残っていれば、要約も索引も後から何度でも作り直せる。逆はできない。

設計3:育てる(仕訳帳を、元帳と目録に)

ここが、この仕組みの心臓部である。

課題:情報は膨らみ続ける
週300件の会話と3〜5本の文字起こしが、1年で50週分。「集めたフォルダを全部AIに読ませる」という方式は、数ヶ月で破綻する。読む量に比例してコストが増え、精度は逆に下がっていくからだ。

答えは2段構えになった。

元帳:仕訳帳だけでは、残高に即答できない

ここでも経理の帳簿が、そのまま答えになった。

週ごとの記録は、時系列に全部書いてある仕訳帳である。だが経理は、仕訳帳だけでは仕事にならない。「いま売掛金の残高はいくらか」と聞かれて、1年分の仕訳を先頭から読み直す経理はいない。仕訳帳とは別に科目ごとの元帳を持っていて、そこに転記した残高で即答する。

プロジェクトの質問も、まったく同じ構造をしている。実際に飛んでくる質問を数えてみると、ほとんどが日付ではなく論点について聞いている。「あの障害の原因は?」は障害という論点の話で、「誰がボールを持ってる?」は論点のいまの状態の話だ。個々の発言は数百件あるが、論点はどの時点でもせいぜい数十個しかない。だから、週ごとの記録(仕訳帳)とは別に、**論点ごとのページ(元帳)**を持つ。売掛金の残高にあたるのが、「この論点はいま誰の球で、何日止まっているか」である。

目録:AIは全部を読まない。引く

元帳が数十ページできると、今度は「どの元帳を開くか」が問題になる。

蔵書が増え続ける図書館を考えてほしい。有能な司書は、全ての本を暗記しているわけではない。目録を持っている。「この質問なら、あの棚のあの本」という対応表である。

同じものを作った。この目録(INDEX)は人間向けの目次(どこに何があるか)ではなく、「何を聞かれたら、どの元帳を開くか」というAI専用のルーティング表である。AIがまず読む索引を1枚だけ置く発想は、llms.txtという提案でも知られている。

聞かれること	目録が指す先
あの障害の経緯と原因	元帳「障害対応」
いま誰がボールを持っているか	各元帳の状態欄(持ち主と停滞日数)
見積もりの金額と工数	元帳の数値一覧ページ
ある決定の経緯と、その後の上書き	元帳の決定一覧ページ

目録が指すのは、常に元帳である。原文が要るときは、元帳の各行に付いている出典リンクを辿る。つまり読み筋は「目録 → 元帳 → (必要なら)原文」の一方通行になる。

目録も元帳も、毎週の取り込みと同時にプログラムが生成し直す。手で更新する索引は必ず腐るので、索引は常に「生成物」にする。ただし再生成が及ぶのは既存の論点の範囲で、論点を新設できるのは人間だけにしてある(理由は設計5で書く)。

2段を重ねた全体像

この構造の妙は、増え方の違いにある。仕訳帳(週ごとの記録)は無限に増える。だが元帳(論点)は増えない。そして目録は元帳だけを指す。こうすると、記録が何年分溜まっても、AIが最初に読む量は一定のままになる。

層を分けているのには、もう1つ理由がある。性質が違うのだ。仕訳帳に載るのは事実である。誰が、いつ、何を言ったか。一度起きたら変わらないし、取りこぼしたら二度と復元できない。元帳に載るのは解釈である。この論点はいま止まっているのか、誰の球なのか。状態は毎週変わるし、原文さえ残っていれば後から何度でも作り直せる。だから優先順位も違う。事実は今週拾う。解釈は後からでも間に合う。取り返しがつかない方から先に押さえる、というだけの話である。

「文体も情報量も違う3つの情報源を、どう育てるのか」の答えがこれである。バラバラの伝票は、週次で共通の仕訳帳に転記され、仕訳の各行は論点の元帳に紐づき、元帳が「いまどうなっているか」を更新し続ける。

情報は溜まるのではなく、元帳の形に育っていく。

決定は上書きしない:訂正仕訳の作法

元帳には、もう1つルールがある。決定を上書きしない。

これも経理の作法そのままである。経理は帳簿の誤りを消しゴムで消さない。訂正仕訳を新しく切って、間違いも訂正も両方残す。

「手数料は自社負担」と3月に決まり、8月に「先方負担」へ覆ったとする。古い決定を消して書き換えると、「なぜ変わったか」「いつまで前提が違ったか」が消える。だから古い決定は残したまま「8月の決定によって上書きされた」という印を付け、新しい決定を追記する。

これで「いまの仕様は?」にも「4月時点ではどうだったか?」にも答えられる。顧客と過去の認識をすり合わせる場面で、この差は大きい。そして、後から入った人が古い記録を開いてしまっても、「これは訂正済み。最新はこちら」がファイル自身に書いてあるので迷子にならない。

前提の監視:決定は建物、前提は地盤

決定を元帳に記録するとき、もう1つフィールドを足している。「この決定が依存している前提」である。

決定は、下した瞬間は正しい。腐るのは前提のほうである。「障害対応は保守範囲、機能改修は別見積」という決定は、「改修要望は月5件以下」という前提の上に立っている。要望が月6件来はじめたとき、決定の文面はどこも間違っていない。地盤だけが沈んでいる。

人間はこれを検知できない。決定を覚えている人はいても、全決定の前提を毎週読み返す人はいないからだ。

そこで、毎週の取り込みのたびに、機械が新しい出来事(チケットの動き、会話での言及)を全決定の前提と突き合わせ、触れていたら「この決定、前提が揺らいでいます」と週報に候補を上げる。見直すかどうかを判断するのは人間である。機械がやるのは、地盤の定点観測だけでいい。

設計4:届ける(週報、日報、「あれどうなった?」)

ここまでで、集まって、揃って、膨らんでも壊れない。だが、それだけでは誰の行動も変わらない。

情報基盤は、引かれなければただのフォルダである。

そこで、人の行動につながる出口を3つ用意した。

週報:月曜の朝、定例の前に届いている

月曜に内部定例があるので、それに間に合う形で週報が届く。イメージはこういうものだ(内容は架空)。

【週報 2026-W34】

■ 今日やらないとまずいこと(期限順)

内容	担当	期限	状態
負荷対策の具体回答	佐藤	8/17(必着)	クライアント宛未回答
見積シートの工数入力	田中	8/18 13:00	進行中

⚠ 注意:主担当の佐藤さんは8/17不在。1件目のボトルネックになりうる

■ 止まっているもの(滞留日数順)

• 外部連携の設定確認。12日停滞、先方の返答待ち
• 見積もりの承認。8日停滞、5名の確認待ちで停止中

見てほしいのは中身の並べ方である。「今週あったこと」の時系列ではなく、「今日やらないとまずい順」に並んでいる。期限順、滞留日数順、そして「クライアントに未回答のまま放置されているもの」が最上位に来る。

ここで守っている原則が1つある。**要約しない。組み替える。**AIに要約させると、何を残すかの判断をAIがすることになり、大事な1件が「その他」に溶ける。やっているのは要約ではなく、机の上の書類を締切順に並べ直す作業である。情報は全部残る。並び順だけが変わる。読み手は上から読んで、自分に関係のあるところで止まればいい。

もう1つ、サンプルの注意書きにさらっと重要なことが書いてある。「主担当が17日不在。1件目のボトルネックになりうる」の行だ。これは「回答の期限が17日」という事実と、「担当者が17日不在」という事実の掛け合わせでできている。どちらも単体では問題ではない。重なると、1週間の遅延リスクになる。

実際の1週間分のデータを調べると、この種の「関係の情報」がいくつも埋まっていた。

関係	実例
重なり	期限の日と、担当者の不在日が同じ
差し戻し	担当がAからBに変わったが、前日はBからAに変わっていた。つまり「振った」のではなく「戻ってきた」
多対一の待ち	1つの見積もりが、5人の確認待ちで止まっている
期限の連動	チケットの期限延長の理由が、定例で決まったリリース日の変更

人間はこれを、頭の中の「なんとなく嫌な予感」として処理している。優秀なPMの予感の正体は、たいていこの掛け合わせの検出である。機械にやらせれば、予感が定例前のリストになる。

日報:進捗のウォッチとリマインド

週報が「今週の地図」だとすると、日報は日々の現在地である。日報が見る差分は毎営業日取得している(平日は業務PCが動いているので、週次のような「取れない日」対策は薄くて済む)。

【日報 8/20(木)】

• 昨日動いたチケット:3件(それぞれ原文リンク)
• 期限が明日のタスク:1件(担当:田中)。昨日から動きなし、リマインド推奨
• 返答待ちが24時間を超えたもの:1件(先方PO宛)

振った球が返ってきているか。期限が近いのに止まっていないか。人間がやると「毎朝全チケットと全スレッドを見回る」という重労働になるウォッチが、毎営業日、決まった時刻に3行で届く。週報だけだと月曜に把握して金曜には忘れるので、その間を日報が埋める。

ささいだが効いている仕様がもう1つある。動きがない日も「今日は0件」と届くことだ。登山の定時連絡と同じで、「連絡が来ない」だけでは、順調なのか遭難したのか区別がつかない。0件の日に0件と言ってくれるから、届かなかった日に仕組みの故障を疑える。

質問:「あれどうなった?」に出典つきで答えさせる

週報と日報は自動で届く出力だが、もう1つ、こちらから聞きに行く使い方がある。「8月の障害の原因って結局何だった?」「あの見積もりの前提は?」と、そのままAIに聞く。AIは目録から元帳を引き、原文リンクつきで答える。

出典リンクが付いていることが、運用上は決定的に効く。「言った言わない」が、議論ではなくリンク1クリックで終わるからだ。

設計5:疑う(4層の機械と、最後の1層の人間)

ここまで読んで、PMなら必ず思うはずだ。「そのAI、間違えないのか?」

間違える。実際にやられた。一番肝が冷えたのは、Slackにはローマ字表記しか存在しないメンバーの氏名を、AIが漢字で「復元」してきたことだ。しかも同音別字で間違えていた。顧客も読む文書で、である。

AIは、優秀だが空欄を放っておけない新人だと思ったほうがいい。分からないところを「たぶんこうだろう」で埋めてくる。悪意はない。だから怖い。

対策は5つの層でやっている。4層は機械の守りで、最後の1層だけが人間である。どれも、経理が金額を守るときの発想と同じだ。

層1:裁量を渡す範囲を、紙に書いて絞る

まず、工程ごとに「誰の裁量か」を固定した。

工程	担当
取得、転記、件数、期限、リンク化、並び順	プログラム(決定論)。元データから機械的に転記する
停滞と期限超過の検知	プログラム(日数と期限の決定論判定)
週報のタイトルと背景の2文、外国語の要旨、新しい論点の候補出し	AI。ただし直後に検品を通す
前提に触れた出来事の検知(意味の照合)	機械が候補を挙げるまで。対応の判断は人間
論点の登録、前提を見直すかの判断、週報の送信	人間

AIが自分の言葉で自由に書けるのは、週報の本文でいえばタイトルと背景説明の2文だけである。数字と固有名詞に関わる部分は全てプログラムが転記する。機械の転記は、同じ入力なら必ず同じ出力になる。ここが人間の新人との違いで、仕組みにすれば二度と揺れない。

層2:納品前に棚卸しをする

棚卸しは、帳簿の在庫と実際の在庫を突き合わせて、紛失(帳簿にあるのに無い)と架空在庫(帳簿に無いのにある)を見つける作業である。同じことを情報でやる。取得した瞬間に全メッセージのID一覧(帳簿)を控えておき、出来上がった文書に書かれたID一覧(実物)と突き合わせる。

ただし、このID突合が保証するのは存在と件数までである。差分がゼロなら、記録の取りこぼしゼロ、存在しない記録の捏造ゼロ。目視のレビューでは原理的に不可能な保証が、計算で出る。一方で、実在する記録の中身が書き換わる誤り(冒頭の氏名の復元がまさにそれだ)はID突合では捕まらない。そこは別の検品が受け持つ。AIが触った後のファイルをプログラムの出力と1行ずつ突き合わせ、転記部分に差分があれば行番号つきで止める。それでも残る「意味の誤り」は、層3の名寄せと層5の人の指摘で守る。

検品は全部で16項目あり、「返信を118件と書いているが実物は90件」といった誤りを実際に捕まえている。1つでも引っかかれば、その週の処理は止まって通知が飛ぶ。

検品16項目の代表例

• 件数の自己申告:ファイル冒頭の「親メッセージ12件」と、実際のセクション数を突合する
• 取りこぼし / 捏造:取得時のID一覧と、文書内のID一覧の集合差を取る
• リンクの正当性:原文リンクをIDから再計算して文字列比較する。計算で導出できないURLは捏造と判定
• 外国語の要旨:日本語以外の発言に日本語要旨が付いていなければ停止
• 改変検知:AIが触った後のファイルを、プログラムの出力と1行ずつ比較。人名の復元や数字の書き換えを検出
• 検品係の自己診断:既知の12ケースを毎回流し、1つでも外れたら「検査不能」として停止。壊れた検品係が全件合格を出す「合格に見える空回り」を防ぐ

層3:呼び名を名寄せする

「サーバ増強の件」「負荷対策」「インフラの例のやつ」が同じ論点を指していると、人間は文脈で分かるが、目録は3つの別の論点として腐っていく。経理が取引先マスタで「(株)ABC」と「ABC株式会社」を同一先に名寄せするのと同じで、用語辞書を1枚持ち、表記ゆれを正規の呼び名に寄せる。

新しい論点を元帳に登録できるのは人間だけにして、AIは「新しい論点らしきものを見つけた」という候補出しまでとする。呼び名はプロジェクトの語彙そのものなので、ここだけは人が握る。

層4:決算チェックと同じ定型テストを流す

仕組みは、直したつもりの変更で壊れる。そこで「答えが決まっている質問20問」をあらかじめ用意しておき、プロンプトやフォーマットを変更するたびに流して、正答率が落ちていないかを見る。

コツは質問を時点指定にすること。決算書の「期末時点の残高」と同じで、時点を固定すれば正解は未来永劫変わらず、テストが腐らない。

20問の代表例

• いま未決のまま止まっている論点は何か。何日止まっているか
• この仕様が決まった経緯と、その出典はどこか
• 顧客が過去に否定した案は何か。理由は何か
• 一度決めてから覆った決定はあるか。なぜ覆ったか
• 8/14時点で、保守契約の範囲はどう決まっているか(時点指定の例)

層5:人の指摘で直す(それでも、実態とはずれていく)

機械の検品をどれだけ重ねても、週報は実態とずれていく。

載っている情報が古い。口頭で交わした会話はどこにもログが無いので、反映されようがない。本来書かれるべきことが、書かれていない。

ずれの原因は仕組みの外側、つまり「そもそも記録されなかった現実」にあるので、仕組みの内側の検品では原理的に捕まえられない。帳簿をどれだけ照合しても、伝票が起こされなかった取引は見つからないのと同じである。だから最後の層だけは、人間になる。

対策は、拍子抜けするほど原始的にした。**人間が指摘する。**月曜の定例で、週報への指摘の時間を数分取る。「これは先週の情報」「それは金曜の立ち話で解決済み」「あの件が載っていないのはおかしい」。日報への指摘は、もっと軽くていい。Slackでそのままリプライする。

原始的だが、この仕組みの上では指摘が使い捨てにならない。定例での指摘は会議の文字起こしに残り、Slackでのリプライは会話ログに残る。つまり指摘そのものが、翌週の取り込みで基盤に流れ込む。

週報を直すための発言が、記録として還流して、次の週報を直す材料になる。修正の指示を仕組みの外で受け取って人力で直すのではなく、修正の指示ごと仕組みに食わせる。

この基盤は作って終わりの道具ではなく、指摘を餌にして育てていくものだと思っている。

同じ形に辿り着いた人がいた

この設計を固めてから知ったのだが、Andrej Karpathy が2026年4月に「LLM Wiki」というパターンを公開している。AIに毎回生ドキュメントを読み直させるのではなく、構造化されたページの集合を育てて維持する、という発想で、原本の層と生成物の層を分け、定期的に矛盾や古い記述を点検する。Gist本文はユースケースの例として「Slackのスレッドや会議の文字起こしを食わせ、LLMが維持する社内wiki」を挙げていて、この記事の形そのものだった。

先人がいると、失敗報告が読めるのがありがたい。公開後のコメント欄には、実践者の検証報告が集まっている。その中の「生成物が生成物を引用しはじめて、原典に辿れない主張が増殖し崩壊した」という報告を読んで、出典として使ってよいのは原文だけ、週報や目録のような生成物は出典にできないというルールを輸入した。この1行のルールが、基盤が自分の書いた嘘を自分で信じ始める事故を構造的に止める。

この仕組みは、PMの仕事をどう変えるか

運用はまだ数週間だが、変化はすでに出ている。

月曜の朝の「かき集め」が消える。　期限超過、停滞、返事待ちを人力で棚卸しして定例に臨む、あの30分から1時間が、届いている週報を読む5分になる。

リマインドが仕組みになる。「あれ、どうなりました?」と聞いて回る仕事は、PMの仕事の中で最も消耗する割に、最も価値を生まない。日報が毎朝それを代行する。

「言った言わない」が消える。　全ての報告に原文リンクが付いているので、記憶の突き合わせが検索1回になる。

「嫌な予感」がリストになる。 期限と不在の重なり、差し戻し、多対一の待ち。優秀なPMが経験で嗅ぎ取っていたものが、機械の定点観測として毎週届く。

新規参画者のキャッチアップが変わる。「この案件に今日から入る人が最初に読むべき5件」をAIに出させる。過去の経緯の説明に先輩の半日を使う必要がなくなる。

そして何より、PMの時間の使い途が変わる。情報を運び、思い出し、かき集める仕事が機械に移ると、残るのは判断だけになる。どの決定を見直すか。どの停滞に介入するか。どのリスクを顧客に伝えるか。本来それだけをやるのがPMだったはずで、ようやくそこに戻れる。

全ての記録が残らないままにしておくのは罪ではないか、と冒頭に書いた。

記録を読める形で残しさえすれば、それを読み尽くして仕事に変えてくれる読み手が、もういる。

参考

• Andrej Karpathy, LLM Wiki(Gist): https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• llms.txt(AI向けにMarkdownの厳選インデックスを置くという提案。本文「目録」の節で触れたもの): https://llmstxt.org