生成AIの性能は上がり続けている。 同じモデルを使える人同士でも、仕事の進み方には大きな差が出る。 プロンプトの巧さに加えて、AIが参照できる情報がその差を作る。 これまで何を決め、いま何が動いていて、次に何を確かめたいのかをAIが読める状態にしているかどうかである。
この固有の情報を、ここではコンテキストと呼ぶ。 プロジェクトの目的、過去の判断、相手との約束、保留の理由、仕事の完成条件、そこから得た学びまでを含む。 頭の中や会話履歴だけにある情報は、別の日に始まったAIとの作業へ引き継げない。 継続して使える形で残し、必要な場面で読み直せるようにすることで、AIはその人の仕事に沿った判断材料を出せる。
自分はGTDとZettelkastenを組み合わせた個人ナレッジマネジメントを、AIとの会話から動かしている。 2026年2月にこの仕組みについて最初に書いた時点では、日次ノートを朝と夜に処理し、次のアクション一覧をAIが更新する運用だった。 半年ほど改修を続けた現在は、紙、会話、PKM、Calendar、作業用のAIタスクが、それぞれ異なる役割を持つ。 中心にあるのは、情報の意味に合う場所へ保存し、次の判断へつなぐことである。
蓄積、意味づけ、活用
仕事中に生まれる気がかりは、まず紙へ書く。 紙を使えない場面では、AIとの会話へ直接入力する。 この段階では文を整えず、忘れたくないことを頭の外へ出せればよい。
整理したくなったら、紙を見ながらAIと話す。 朝や夜と時刻を決めず、必要なときに何度でも行う。 AIは発話から、望む結果、実行する人、関係するプロジェクト、日付、待っている相手、再開する条件を読み取り、構造化した変更案を作る。
変更案は、仕事の意味に応じて置き場所が変わる。 自分が一度で終えられる行動は紙に残す。 複数の作業を通じて確認可能な成果を作る仕事はLotとして追う。 人や会議で話すことはAgenda、依頼した結果を待つことはWaiting、日付に紐づく確認や判断はCalendar、いまは着手しない案はSomedayへ置く。 行動を伴わない資料はReference、別の場面でも使える学びはInsightとして保存する。
保存した状態は、日々の判断に使う。 AIはプロジェクトの経緯と現在の状態を読んで、次に作る成果の候補を出す。 会議前には相手とのAgenda、Waiting、過去の判断をまとめる。 仕事を終えたときは、成果と判断をプロジェクトの記録へ戻す。 蓄積したコンテキストが、次の整理、実行、振り返りの入力になる。
GTDはコミットメントを保存する
GTDは、行動と約束の状態を管理するために使う。 何を知っているかより、何を完了させたいか、誰の返事を待っているか、いつ判断するかを扱う。
プロジェクトは、達成したい状態とそこへ至る仕事の全体を持つ。 各プロジェクトのフォルダには、目的、現在までの判断、進捗ログ、関連資料を置く。 AIが新しい作業を始めるときは、まずこの記録を読む。 この記録があれば、別の日や別のAIタスクでも同じ前提から再開できる。
実行はLotという単位で区切る。 Lotは、ひとつの確認可能な成果を作る仕事である。 目的、成果物、完成条件を定め、計画中、進行中、条件待ち、完了、中止の状態を持つ。 プロジェクトが長く続いても、AIへ渡す仕事はLotごとに小さく保てる。
この分け方により、プロジェクトの長い経緯と、一回のAIタスクで扱う成果を同時に管理できる。 PKMが継続する記憶を持ち、Codexの各タスクは成果を作る一時的な作業場所になる。 成果が完成すると、AIは変更したもの、判断したこと、残ったリスクを提示する。 自分が確認した後、記録、Gitの変更、Pull Request、マージ、読み戻しまでを一つの終了処理として行う。
Zettelkastenは判断材料を育てる
GTDで扱うのは、現在の仕事に対するコミットメントである。 Zettelkastenには、仕事を越えて使える考えを保存する。
会議や制作で得た気づきのうち、別の場面でも使えるものはInsightとしていったん蓄積する。 考えが独立した命題として読めるようになったら、一つの概念を一つのノートへ書く。 関連するノートをリンクで結び、複数のノートをMoCからたどれるようにする。 まとまった論考はArticleとして公開する。
この区別があることで、進行中の仕事に固有の情報と、将来も使える知識をそれぞれ更新できる。 あるプロジェクトで得た判断原則は、アトミックノートとして残る。 数か月後に別の仕事を始めたAIは、そのノートを新しいプロジェクトの判断材料として参照できる。
一日の中でコンテキストが動く
一日の始まりには、Calendarの予定とPKMのAgenda、Waiting、会議準備メモから、その日のブリーフが作られる。 予定の羅列にせず、会議ごとに話すことと、その話題を理解するための文脈をまとめる。 朝の時点で、誰と何を確認する日なのかが分かる。
日中はダッシュボードで、プロジェクト、Lot、依存関係、Waitingを見る。 全プロジェクトから直感的に気になるものを選び、次に確認できる成果をAIと決める。 その日のLotは、自分で進めるものとAIへ任せるものに分け、Calendarの予定と同じ時間軸で配置できる。 画面上の配置は一日の計画、PKM上のLotは継続する仕事の状態として扱う。
AIへ任せるLotでは、ダッシュボードから依頼文をコピーし、Codexで新しいタスクを始める。 AIはプロジェクトの記録と成果契約を読み、最初に理解した内容を提示する。 自分が依頼全体を確認した後は、資料を読む順序、下書き、比較、検証をAIが進める。 目的や完成条件が変わる判断だけを人間へ戻す。
最後の会議が終わると、その日の会議をまとめて振り返るタスクが開く。 議事録は、プロジェクトの記録、Agenda、Waiting、Lot、本人の行動、Insight、Referenceへつなぐ証拠として使う。 複数の会議と既存のPKMを照合してから変更案を出すため、同じ約束や仕事を重複して登録しにくい。
AIと人間の判断を分ける
AIは、検索、照合、分類、候補作成、ファイル更新、検証を担当する。 人間は、何を実現したいかを決め、仕事を選び、意味が変わる更新を承認し、成果を検収する。
この分担により、AIの判断を人間が確かめてからコミットメントを変更できる。 AIが作った変更案には、元の発言、保存先、既存項目との関係を含める。 AgendaやWaitingの完了、Lotの登録、新しいプロジェクトの開始など、コミットメントを変える操作は事前に確認する。 更新後は安定したIDを使って対象を読み戻し、意図した状態になったことを確かめる。
自動処理にも同じ考え方を適用している。 CalendarやAIタスクの取得に失敗したときは、保存済み情報の取得時点または取得エラーを表示する。 決められた入力から再生成できる処理はスクリプトへ任せ、意味の判断を含む変更は会話と承認を通す。 Gitの履歴とPull Requestは、変更内容を後から追うための記録になる。
コンテキストは使うたびに更新される
同じモデルでも、参照するコンテキストが育つにつれて応答は変わる。 短い発話から関係するプロジェクトを見つけられる。 会議前に、数か月前の判断と最近のWaitingを同じ画面へ出せる。 新しいAIタスクが、前のタスクの会話を知らなくても、成果と判断の続きから始められる。
運用ルールもコンテキストの一部である。 分類を間違えた理由、承認が必要だった操作、うまく機能した手順を、AIが読むルールやスキルへ戻す。 次の実行から新しい判断基準が使われる。 自分の記録と、自分とAIがどう協働するかの両方が更新されていく。
この仕組みを使い続けて分かったのは、コンテキストの価値は量と整理の質で決まるということだ。 現在有効な判断と古い案を区別できる形で保存する必要がある。 決定、状態、成果、学びをそれぞれ適切な場所へ置き、古くなった状態を更新する必要がある。
AI時代の個人ナレッジマネジメントは、記録を増やす活動から、次の判断に使える状態を保つ活動へ変わってきた。 紙に書いた一行、会議で決まった約束、AIが作った成果、そこから得た学びが、別々の場所で管理されながら次の仕事へつながる。 この循環が続くほど、AIは毎回説明を受ける相手から、過去の判断を踏まえて仕事を進める協働者へ近づいていく。