PKMの説明書

2026-10-14

PKMはPersonal Knowledge Managementの略で、個人が自分の知識を管理する仕組みを指す。ここで紹介するPKMでは、仕事で受け取った情報、考えたこと、決めたこと、作ったものをまとめて管理している。

このPKMには、知識に加えて、進めている仕事の目的や現在の状況も記録している。AIと仕事を始めるときは、必要な情報をここから読み込む。仕事が進んだら、新しく分かったことや決めたことをそれぞれ適切な場所へ保存し、次の会話ではその記録をもとに続きを進める。

この説明書では、仕組みの全体像と各部分の使い方を説明する。フォルダの中身に加えて、何のために情報を分けるのか、何をいつ書いて更新するのか、AIにどう仕事を依頼するのかも扱う。

GTDやAIのスキルに詳しくない人でも読めるように、用語はそれが出てくる箇所で説明する。本文に登場する「新メンバーの受け入れ」は、仕組みを説明するための架空の例である。この例を通して、記録した情報から仕事を始め、その結果を再び保存するまでの流れをたどる。

ここで紹介するのは、個人の情報整理と仕事の進め方の一例である。所属組織やチームの標準手順を示すものではない。業務で使うGitとAIは、いずれも社内のエンタープライズ環境を利用している。

業務で利用する場合は、所属組織の規程と利用サービスの契約条件に従い、扱える情報、保存先、AIに渡せる範囲を確認する。

目次

1. まず全体像をつかむ
2. フォルダの構造を知る
3. Flowを理解する
4. Stockを理解する
5. ProjectとAreaを分ける
6. Projectの文脈を作る
7. AIと仕事をする準備
8. 主要な3スキルを使う
9. 日々の仕事を回す
10. 一つの仕事を通して体験する
11. 迷いやすいところと用語早見表

初めて読む場合は、第1章から順に読むと、後の章に出てくる用語を理解しやすい。運用の細部を確かめたいときは、第3〜8章から必要な項目を参照すればよい。実際の仕事の進み方を先に知りたい場合は、第1章の次に第10章を読んでもよい。

1. まず全体像をつかむ

記録を使って、次の仕事を始める

たとえば、新しいメンバーを迎える準備をしているとする。会議で「最初に読む資料が分散している」という話が出て、案内を整えることになった。

会議で何が話されたか、何を改善するのか、今どこまで進んでいるのか、次に何をすればよいのか。この仕事を進めるには、こうした複数の情報が必要になる。議事録だけでは、その後どこまで実行したのかが分からない。完成した案内だけでは、なぜその内容にしたのかが分からない。

このPKMでは、これらの情報を役割ごとに分けて保存している。

知りたいこと	読むもの
会議で何が話されたか	日付ごとの議事録
この仕事で何を実現するか	ProjectのCharter
今どこまで進み、次に何をするか	ProjectのContext
なぜその判断をしたか	ProjectのLogや、論点を検討した文書
何ができたか	成果物、または成果物へのリンク

別の日にAIと続きを進めるときも、これらの情報をAIに読ませる。前回の会話の内容を一から口頭で説明し直さなくても、保存された文脈をもとに仕事を再開できるようにしている。

全体の流れ

仕事は、おおむね次の流れで進む。

Flowは、その日その時の記録を置く場所である。Stockは、仕事や責任領域など、使う目的に沿って整理した情報を置く場所である。仕事は、この二つを行き来しながら進める。

図中の三つのスキルが、この運用の中心になる。スキルとは、AIに特定の仕事を依頼するときの進め方をまとめた手順のことだ。詳しくは第7章と第8章で説明する。

人間とAIは何をするか

何を進めるか、何を大事にするか、結果を採用するかどうかは、人間が判断する。AIには、既存の記録の調査、比較案の作成、文章や実装の作成、結果の検証などを依頼する。

保存する文脈を整える作業もAIが担う。たとえば「この案で進める」と決まったら、AIはその結論と理由を記録し、現在の方針を書き直す。作業が一つ終われば、次に必要な作業を示す。こうした更新は、会話の内容と実際の成果物を照合したうえで行う。

ただし、この分担には人間による確認が入る。AIが出した候補、本人が採用した判断、実際に完了した作業は、それぞれ区別して記録する。案を作っただけの段階で「決定済み」と書くと、その後の仕事が誤った前提のまま進んでしまうからだ。

2. フォルダの構造を知る

全体の地図

主な情報は、Markdownというテキスト形式で保存している。拡張子が.mdのファイルである。見出しや箇条書きをテキストのまま記述できる。AIも同じファイルを読み、編集する。

主要なフォルダを抜き出すと、次のような構造になる。

PKM/
├── gtd/                        仕事と行動に関する情報
│   ├── flow/                   日付ごとの記録
│   └── stock/                  目的に沿って整理した情報
│       ├── projects/           完了する成果を進める場所
│       ├── areas/              継続的な責任領域の情報
│       ├── resources/          参照する資料
│       ├── insights/           別の仕事でも使える学び
│       └── archives/           終了したProjectなど
├── zettelkasten/               再利用する知識と、そのつながり
│   ├── Notes/                  一つの考えを扱うノート
│   ├── MoCs/                   関連するノートの案内
│   └── Article/                公開用の記事
├── writing/                    長い文章の執筆
├── AGENTS.md                   AIが守る原則と参照先
├── .claude/
│   ├── skills/                 仕事別のスキル
│   └── rules/                  作業に応じて読む規則
└── .codex/                     実行・検査などの仕組み

この図は主要な部分だけを抜き出したもので、最初からすべてを覚える必要はない。まずは、日々の仕事を扱うgtd/、知識を扱うzettelkasten/、まとまった文章を書くwriting/の違いを押さえておけばよい。

このPKMはClaude Codeを使って作り始めたため、スキルやルールを.claude/に置いている。この名前や配置自体に深い意味はない。.codex/も含め、AI向けの指示やプログラムの置き場所は、使う環境に合わせて変えてよい。

FlowとStockの区分は、gtd/の中にある。PKM全体をこの二つのフォルダだけで管理しているわけではない。

仕事の文脈と知識を分ける

gtd/という名前は、Getting Things Doneという仕事の管理手法に由来する。やるべきことを頭の外へ書き出し、その意味を整理して、必要なときに取り出して進めるという考え方を取り入れている。

このフォルダで管理するのは、「今、何を進めているか」「誰の返答を待っているか」「次の会議で何を話すか」といった、仕事の状況と結び付いた情報だ。

一方、zettelkasten/では、個別の仕事を離れても使える考えをノートにする。Zettelkastenは、知識を小さなノートに分けて書き、ノート同士を関連付けていく方法である。たとえば、ある資料を改善するなかで「初めて使う人への説明では、作業を始める順に情報を配置すると迷いを減らせる」という考えを得たとする。これをノートにしておけば、別の事例と関連付けて検討できる。

実際の仕事で何を決めたかはProjectへ、他の場面でも検討できる考えは知識ノートへ記録する。両者は役割が異なるが、Projectの文書から関連するノートへリンクを置くこともできる。

成果物の管理先

文章、設計資料、コードは、それぞれに適した場所で管理する。長い原稿ならwriting/、アプリの実装ならそのアプリのコードリポジトリ、共同編集する資料なら元の文書サービスを使う。リポジトリとは、ファイルとその変更履歴をまとめて管理する単位のことだ。

Projectのフォルダには、成果物そのもの、またはその管理先へのリンクを置く。成果物を別の場所で管理している場合でも、ProjectのContextを読めば、現在使っている版とその保存場所にたどり着けるようにしておく。

「すべての文脈をProjectに集める」といっても、外部の文書を丸ごと複製するのとは少し違う。仕事の目的、現在の判断、関連資料の所在を、一か所から把握できるようにするという意味である。

3. Flowを理解する

その日そのときの情報を残す

Flowには、日付と結び付いた記録を置く。代表的なのは日次の入力と議事録で、会議の準備に使う文書や、その時点の予定をまとめた文書なども日付ごとのフォルダに入る。

gtd/flow/
└── YYYY-MM-DD/
    ├── note.md                 日次の入力がある場合の記録
    ├── meeting/                その日の議事録
    ├── meeting-prep/           会議前の準備資料
    ├── daily-briefing.md        朝の予定と会議文脈
    ├── meeting-recall.md        当日の会議を振り返るための生成物
    └── session-log.md           特定のProjectに属さない作業の記録

毎日これらのファイルがすべてそろうわけではない。また、日付フォルダにはこのほか、取得したデータや処理状態を保持するファイルも入る。

Flowの情報は、「いつ、何があったか」を調べるときに読む。「あの会議ではどの案が出ていたか」「その時点では誰の確認を待っていたか」といったことを、原記録に戻って確かめられる。

原記録を、後の判断で書き換えない

Flowを扱ううえでの基本方針は、当時の記録をそのまま残すことだ。

たとえば、ある日の会議の議事録に「案内は動画にする案が出た」と記録されていたとする。翌日の検討で文章にすると決まっても、前日の議事録を「案内は文章にすることになった」とは書き換えない。

前日の記録には、動画にする案が出たという事実を残しておく。翌日の決定は新しい記録やProjectのLogへ追加し、現在の方針を示すContextには「文章で作る」と書く。こうすると、現在の結論と、そこに至るまでの過程の両方をたどれる。

整理のために元の記録を消したり、元の議事録に処理済みの目印を書き足したりもしない。処理の状態は、別の管理情報として保持する。元の記録と、その記録をどう扱ったかという情報を分けておくためだ。

「書き換えない」の範囲

実際の運用では、Flowにある原記録と、そこから作られる生成物を区別している。

対象	扱い
日次入力のnote.mdや保護対象の日記	AIによる通常の整理・保存処理では編集しない
元議事録の内容	後の判断に合わせて意味を書き換えない。名前の誤認識などは、正式な表記を確認したうえで専用の手順で修正する
朝のdaily-briefing.md	正常に生成できた内容は、その朝の記録として保持する
会議想起、取得データ、処理状態などの生成物	定められた処理で更新する
作業ログへの新しい記録	過去の内容を残したまま追記する

フォルダ内のすべてのファイルを、永久に一文字も変えずに保つ実装になっているわけではない。守りたいのは、後の都合で当時の事実を作り替えないことだ。誤認識の修正や生成物の更新は、目的と対象を限定して行う。

FlowからStockへ、必要な意味を取り出す

たとえば、議事録に次のような内容があるとする。

新メンバーが最初に読む資料を見つけにくい。
受け入れ担当は、初週の案内を一つにまとめる案を出した。
作成範囲は、次回の打ち合わせで確認する。

この段階では、案内を作ることが正式に決まったとは書けない。AIは既存の仕事と照らし合わせ、「新しいProjectにするのか」「進行中のProjectの一部なのか」「まず誰と何を確認するのか」を整理して提案する。

本人が「初週の受け入れ手順を整えるProjectとして進める」と決めたら、その意味をStockのProjectへ保存する。次回の打ち合わせで話すことが残っていれば、議題のリストであるAgendaにも必要な項目を加える。

この処理は、FlowのファイルをStockへ移してFlowを空にすることではない。元の議事録は残したまま、今後の仕事で使う情報を目的別に整理する。

すべての入力をFlowへ集めるわけではない

日中に気になったことは、紙に書くこともあれば、AIとの会話に直接入力することもある。外部の資料については、元のサービスを管理先として参照する場合もある。

Flowは、あらゆる入力を必ず一度通す受付ではなく、日付と結び付いた記録を残す場所である。会話のなかですでに意味が明らかになった情報は、承認した保存先へ記録できる。紙のメモや外部資料の内容がすべて自動的にFlowへ取り込まれる、と考える必要はない。

4. Stockを理解する

使う目的で情報を整理する

Stockには、これから仕事を進めるために使う情報を置く。日付順に読むだけでは取り出しにくい情報を、Project、Area、資料、議題など、目的ごとにまとめている。

たとえば「新メンバーの受け入れ」について調べるなら、毎日の議事録をすべて読み直すより、そのProjectのContextを読むほうが現在の方針にたどり着きやすい。必要な経緯は、そこからLogや元の議事録へ進んで確認する。

Stockにも履歴は入る。ProjectのLogがその例だ。つまり、FlowとStockの違いは単純な「過去と現在」の区別ではない。日付を起点に残す記録か、特定の目的で使うために整理した情報か、という違いである。

フォルダと一覧ファイル

Stockには、詳しい文書を入れるフォルダと、状態を一覧で管理するファイルがある。

gtd/stock/
├── projects.md             Projectの一覧と状態
├── projects/               各Projectの詳しい文脈と資料
├── areas.md                責任領域と関連Projectの一覧
├── areas/                  責任領域ごとの情報
├── lots.md                 成果として追う仕事
├── agenda.md               人や会議で話すこと
├── waiting.md              他者へ依頼済みの結果待ち
├── someday.md              今は取り組まない候補
├── resources/              参照資料
├── insights/               再利用する学びや判断原則
├── horizons.md             目的・目標・責任領域などの見通し
└── archives/               終了したProjectなど

projects.mdとprojects/は役割が異なる。前者は仕事全体を見渡すための一覧、後者は個々の仕事を理解するための詳しい記録である。すべての資料を一覧ファイルに詰め込むと、どの仕事を進めるかを選びにくくなるため、二つに分けている。

状況に応じた置き場

同じ話題でも、情報の意味によって保存先は変わる。

情報の例	保存先と扱い
新メンバーの初週の受け入れ手順を整える	完了条件を持つProjectとして管理する
人材育成で継続的に大切にする方針	Areaの情報として管理する
初週ガイドの確認用原稿を作る	Project内の成果として追うならLotにする
次回、受け入れ担当と対象範囲を話す	Agendaへ置く
担当者に依頼した手順一覧の返答を待つ	Waitingへ置く
来期、案内の多言語化を検討したい	今は取り組まない候補としてSomedayへ置く
関連する他社のガイドを参照する	AreaまたはResourcesへ置く
説明順の決め方について使える学びがあった	Insightとして残す候補にする

実際の状態管理では、各項目を識別するIDや、関連するProjectへの参照も持たせている。名前が似ているだけの別の仕事を、誤って完了扱いにしないためだ。

AgendaとWaitingの違い

Agendaは、特定の人や会議で話すことである。「受け入れ担当に、ガイドの確認役を誰にするか相談する」はAgendaに入る。

Waitingは、すでに他者へ依頼し、その結果を待っている状態を表す。「受け入れ担当に手順一覧を依頼済みで、返答を待っている」はWaitingに入る。

これから相談することと、依頼を済ませて待っていることとでは、次に必要な行動が異なる。そのため、担当者、期待する返答、依頼した事実を記録して両者を区別する。

資料、学び、将来の仕事を分ける

保存した記事を、すべてSomedayへ入れるわけではない。その記事を今後どう扱いたいかによって置き場を分ける。

「必要になったときに参照したい」なら資料として扱う。「この記事を参考に、いつか受け入れ制度を見直したい」なら将来の仕事の候補になる。「この記事から、自分の仕事でも使える判断原則を得た」なら、学びとして記録する候補になる。

資料を保存することと、何かに取り組むと約束することを分けておけば、仕事の一覧に未整理の読み物が増え続けるのを避けられる。

予定と単発行動の置き場

本人が行う単発の行動は紙に、成果として追う仕事はLotに置いている。日付に結び付く確認、判断、レビュー、締切は、Google Calendarのmilestoneカレンダーで管理する。通常の会議や予定は、それぞれに合ったカレンダーへ入れる。

「受け入れ担当に資料を送る」という一回の行動、「初週ガイドを完成させる」という成果、「何日までに内容を確認する」という日付は、互いに関連していても種類の異なる情報だ。それぞれに管理元を持たせたうえで、Projectの文脈から関係をたどれるようにしている。

5. ProjectとAreaを分ける

Projectは、完了する成果の単位

このPKMで使うProjectという言葉は、GTDの考え方に基づいている。達成したい結果のうち、複数の行動を必要とするものを指す。「二つ以上のアクションがある仕事」と考えると、規模の感覚をつかみやすい。

たとえば「新メンバーに案内を送る」は、一回の行動として扱えるかもしれない。一方、「初週に必要な受け入れ手順を整え、試行を終える」には、現状の確認、方針の検討、ガイドの作成、試行、修正などが必要になる。こちらは、完了する成果としてProjectで管理できる。

一般に「プロジェクト」という言葉から想像される、大人数で何か月もかけて進める仕事と比べると、ここでいうProjectには小さな単位も含まれる。人数や予算の規模より、何を達成したら終わるのかを重視している。

実際には三つの条件で判断する

現在の運用では、アクションの数だけを理由にProjectを増やすことはせず、次の三つを確認している。

1. ほかの成果とは独立して、優先順位や進行状態を変えられるか。
2. 固有の完了条件があるか。
3. 完了までに複数の行動、または判断が必要か。

たとえば「初週ガイドの文章を修正する」は、複数の作業を含んでいても、受け入れ改善Projectの方針と状態をそのまま引き継ぐ仕事であれば、そのProjectの中で扱える。

反対に「評価制度を見直す」は、同じ人材育成に関わる仕事でも、受け入れ改善とは独立して進めたり止めたりでき、完成条件も異なる。この場合は、別のProjectにすることを検討する。

担当者、会議、関係するサービスが同じというだけで、一つのProjectにまとめることはしない。関連性はリンクで表し、完了の判断は成果ごとに行う。

Areaは、継続する責任領域

Areaは、継続的に関わり、一定の状態を保ち続ける領域である。たとえば「チームの人材育成」は、ガイドを一つ完成させれば終わるものではない。新しい人を迎えること、成長を支えること、育成方針を見直すことが、その後も続いていく。

こうした広い仕事のまとまりを、Areaとして管理する。普段の会話で「あのプロジェクト」と呼んでいる継続的な事業や活動のなかにも、このPKMではAreaにあたるものがある。

AreaとProjectの違いは、規模の大小だけでは説明できない。終わりを定義する成果なのか、継続して責任を持つ領域なのか、という違いである。

例	扱い	判断の理由
チームの人材育成	Area	メンバーや課題が変わっても関わり続ける
初週の受け入れ手順を整え、試行を終える	Project	達成したい状態と終了の条件がある
プロダクトの運営	Area	継続して品質や利用状況に責任を持つ
次回リリースの初回利用体験を改善する	Project	対象範囲と完了を判断できる
住環境の維持	Area	日常的に管理する
引っ越しを完了する	Project	複数の行動が必要で、終わりがある

AreaとProjectを関連付ける

Areaには、その領域の方針や継続して参照する情報を置き、関連するProjectへリンクする。Project側からも、どのAreaと関係するかを示す。

ProjectのフォルダをAreaのフォルダの中に入れなくても、この関係はリンクで表せる。Projectはprojects/で管理し、Areaから関連するProjectへたどれるようにしている。

受け入れ改善Projectが終わったら、完成したガイドをAreaから参照できるようにする。終了したProjectの記録はアーカイブに残るため、後から判断の理由を調べることもできる。

Lotは、Projectを進める一つの成果

Projectの中で、本人やAIが進める成果を管理する単位をLotと呼ぶ。読み方は「ロット」で、このPKMでは確認できる一つの成果を指す。

受け入れ改善Projectであれば、「初週ガイドの確認用原稿を作る」「試行結果を整理する」といった成果がLotの候補になる。単なる作業名よりも、できたものを見て確認できる単位を選ぶ。

ガイドを作るための調査、下書き、校正、検証は、同じLotの中で行える。作業の手順ごとに別のLotを立てる必要はない。Lotは、親となるProjectの優先順位や状態に沿って進める。

また、LotとAIのスレッドは一対一に対応しない。同じ成果を複数のスレッドで進めることもできる。スレッドは会話と実行の場、Lotは成果の進み具合を管理する単位、と考えると区別しやすい。

Projectを始めるとき

新しいProjectを始めるときは、何を実現するのか、今回はどこまでを範囲とするのかを確認する。そのうえでProjectのフォルダを作り、Charter、Context、Logをそろえる。

複数の成果を順に作っていく仕事では、Roadmapも用意する。Roadmapは、Projectのゴールに向けて、どの成果をどの順番で確認していくかを示す計画である。まず次に進める一つの成果を具体化し、その後の成果は、最初の結果を踏まえて見直せるようにしておく。

この準備にはloop-roadmap-plannerというスキルを使う。第8章で扱うループエンジニアリングは、ここで選んだ一つの成果を作るための実行の進め方だ。計画を立てることと、計画に含まれる仕事を実行することを分けている。

6. Projectの文脈を作る

三つの文書が答えること

Projectのフォルダには、Charter、Context、Logの三つを必ず用意している。

gtd/stock/projects/初週の受け入れ手順を整える/
├── charter.md
├── context.md
├── log.md
├── README.md                   資料や論点が増えたときの案内
├── 00-中心イシュー.md           必要に応じて作る論点文書
├── 01-初週ガイドの対象範囲.md
└── その他の検討資料や成果物

それぞれを短く言い表すと、Charterは「何のために、どこまでやるか」、Contextは「今どうなっていて、次に何をするか」、Logは「何をして、なぜそう決めたか」に答える文書である。

文書	主に答えること	更新する場面
Charter	なぜ始め、何を実現し、何をもって完了とするか	開始時。目的や範囲を見直したとき
Context	現在の判断、進捗、未決事項、次の仕事は何か	仕事が進み、現在の状況が変わったとき
Log	どのような検討と作業を経て、今の状態になったか	判断や作業を記録するときに追記する

三つに分けておくと、目的を確認したいときに長い作業履歴を読まずに済み、経緯を調べたいときには記録をさかのぼれる。

Charter：仕事の目的と完成条件

Charterは、Projectの前提を定める文書である。「何を作るか」に加えて、その成果によって誰が何をできるようになるのかを書く。

たとえば「ガイドを作る」とだけ書くと、ページ数を増やすだけでも達成したことになってしまう。「新メンバーが、初週の作業と相談先を自分で調べられるようにする」と書けば、必要な内容や完成の判断を考えやすくなる。

Charterでは、主に次の内容を扱う。

内容	書くこと
あるべき姿	完了後、誰がどのような状態になっているか
現状	今、確認できている事実
問題	現状のままでは望む状態にならない理由
Projectで解く課題	このProjectが実現すること
目的と価値観	なぜ行うか、判断で何を優先するか
結果のイメージ	得たい成果と、完了を判定する方法
範囲と制約	今回扱うこと、扱わないこと、守る条件

架空のProjectで記入すると、次のようになる。

# 初週の受け入れ手順を整える
 
## 問題設定
 
### あるべき姿
 
新メンバーが、初週に必要な準備、作業、相談先を自分で調べられる。
受け入れ担当は、説明済みの内容と残る支援を把握できる。
 
### 現状
 
初週に参照する資料が複数の場所に分かれている。
案内の順序は受け入れ担当ごとに異なる。
 
### 問題
 
最初に何を読み、どの順に行動するかが分からず、
新メンバーも受け入れ担当も、その都度確認している。
 
### Projectで解く課題
 
初週の案内と担当者の確認手順を整え、試行を通じて修正する。
 
## 目的と価値観
 
新メンバーが必要な行動と相談先を見つけられることを優先する。
詳細な制度説明は既存資料を参照し、二重の管理を増やさない。
 
## 結果のイメージ
 
- 初週ガイドと、受け入れ担当の確認手順がある。
- 試行参加者が、主要な作業と相談先をガイドから探せる。
- 試行で見つかった支障を修正し、受け入れ担当が確認している。
 
## スコープ
 
初週の準備、日ごとの作業、相談先、受け入れ担当の確認手順。
 
## スコープ外
 
評価制度の変更、研修システムの開発、全社への展開。

試行の相手や確認方法が決まっていなければ、未決事項として扱う。また、AIが原稿を点検したことと、実際の利用者が使えると確認したことは区別する。

Charterは、日々の作業報告のたびに書き換える文書ではない。たとえば全社へ展開する方針に変えるなら、対象者、範囲、完成条件が変わる。その判断は本人が行い、そのうえでCharterを更新する。

Context：今の仕事を再開するための文書

Contextには、現在の判断と状態をまとめる。AIが作業を始めるときに、特に重要になる文書だ。

基本となる見出しは、次の五つである。

見出し	内容
ゴール	Charterにある完了状態の要約
現在地	決まっていること、進捗、未決事項、担当、関連資料
次の一手	次に進める具体的な仕事
注意点	制約、前提、まだ確認できていないこと
つながり	Area、関係者、関連Project、資料、成果物などへのリンク

たとえば、ガイドの対象範囲が決まり、これから原稿を作る段階であれば、次のように書ける。

# 初週の受け入れ手順を整える
 
## ゴール
 
初週の案内と担当者の確認手順を整え、試行と修正を終える。
 
## 現在地
 
ガイドは、初日前の準備、初日の作業、初週の作業の順に構成する。
対象範囲は本人と受け入れ担当が確認済み。
制度の詳細説明は既存資料を参照する。
構成の判断理由はlog.mdの「初週ガイドの対象範囲」に記録した。
 
相談先の一覧は受け入れ担当に依頼済みで、返答を待っている。
ガイドの本文はまだ作成していない。
 
## 次の一手
 
確定した構成に沿って、初週ガイドの確認用原稿を作る。
相談先が未確認の箇所は、未確認と分かる形で残す。
 
## 注意点
 
部署によって異なる手順を、全社共通の手順として書かない。
試行参加者と試行日は未定。
 
## つながり
 
- Area：チームの人材育成
- 検討資料：01-初週ガイドの対象範囲.md
- 作業履歴：log.md
- 元資料：受け入れ担当が管理する現行手順

この例では、読みやすさを優先して参照先の名前だけを書いている。実際の文書では、ファイルや元資料を開けるリンクを置く。

「現在地」には、今も有効な情報を残す。新しい出来事のたびに日付を付けて末尾へ書き足していくと、どの方針が現在のものなのかが分かりにくくなる。変わった部分は書き換え、変化の過程はLogに記録する。

Contextの更新前と更新後

確認用原稿ができると、「本文はまだ作成していない」という記述は古くなる。「次の一手」も、原稿の作成から内容の確認へ移る。

箇所	原稿作成前	原稿作成後
現在地	本文は未作成	確認用原稿があり、構成と参照先の点検を終えた
次の一手	確認用原稿を作る	本人が本文を読み、未確認の手順を担当者と照合する
注意点	相談先と試行日が未確認	返答が来ていなければ、その未確認事項を保持する
つながり	構成案へのリンク	構成案に加え、確認用原稿へのリンク

原稿ができても、相談先一覧が届いたことにはならない。進んだ部分だけを更新し、残っている未決事項を消さないことが大切だ。

Log：判断と作業の経緯

Logには、仕事の過程を時系列で記録する。何をしたかに加えて、どの案を検討し、何を選び、なぜそれを選んだかを残す。

「構成を決めた」という一行だけでは、同じ話を再検討するときの材料が足りない。判断の理由や見送った案が書いてあれば、状況が変わったときに、その判断を維持してよいかを考えられる。

# 初週の受け入れ手順を整える ログ
 
### YYYY-MM-DD 初週ガイドの対象範囲
 
ガイドの構成を、資料の種類ごとに並べる案と、
新メンバーが作業する順に並べる案で比較した。
 
本人と受け入れ担当は、初日前、初日、初週の順に並べる案を採用した。
初めて参加する人が、今必要な手順を探せることを優先したため。
制度を網羅する案は、既存の制度資料との二重管理になるため見送った。
 
制度の詳細は、担当部署が管理する資料へのリンクで案内する。
相談先の一覧は受け入れ担当へ依頼したが、まだ返答はない。
相談先を推測して本文へ埋めないことを確認した。
 
次に、確定した構成を使って確認用原稿を作る。
今回の検討内容は「01-初週ガイドの対象範囲.md」に残した。

Logには追記していく。後から訂正が必要になった場合も、どの記録をなぜ訂正するのかを新しい記録として残す。以前の判断を、最初からなかったことにはしない。

本人からのフィードバックも、後の判断に関わるものは残す。ただし、会話をすべて逐語的に写す必要はない。結論、理由、条件、未決事項、成果物の場所が分かるように整理する。

三つの文書と原記録の関係

同じ出来事が複数の文書に登場しても、文書ごとに役割が異なる。

会議の議事録     「動画案と文章案が出た」
      ↓ 検討と本人の判断
Charter          「新メンバーが初週の作業を調べられる状態を目指す」
Context          「文章で作る。構成は確定、本文は未作成」
Log              「更新しやすさと検索のしやすさから文章案を採用した」
論点文書         両案の比較、現時点の結論、検討の詳細

Charterの目的に照らして案を選び、Contextに現在の結論を示し、Logに判断の過程を残す。詳しい比較が必要なら論点文書を読む。このように役割を分けることで、一つの文書だけが際限なく長くなるのを避けている。

関連資料が増えたとき

Projectには、調査結果、比較案、論点文書、制作物なども増えていく。資料が多くなったら、READMEを案内として使い、何を読むべきか、どの論点が未決か、成果物がどこにあるかを示す。

Contextの「つながり」からも、判断に必要な資料へたどれるようにしておく。原稿を作るAIには本文の前提が、実装を再開するAIにはコードの場所と現在の制約が必要になる。文脈を残すときは、次の仕事に必要な情報にたどり着けるかどうかを基準にしている。

7. AIと仕事をする準備

スキルとは何か

スキルは、AIが特定の仕事を進めるための手順書である。読む資料、作る成果物、確認すること、本人に判断を求める場面などを記述している。

単純なスキルなら、文章による指示だけで成り立つ。複雑な仕事では、記入例、参考文書、検査用のプログラムなども組み合わせる。このPKMでは、スキルの基本となる文書をSKILL.mdという名前で保存している。

.claude/skills/スキル名/
├── SKILL.md              目的と進め方
├── references/           必要なときに読む補足資料
└── scripts/              実行や検査を支援するプログラム

すべてのスキルにこの三つがそろっているわけではない。必要な指示や資料を、仕事のまとまりごとに置いている。上の.claude/skills/はこのPKMでの配置例であり、利用するAI環境がスキルを読み込める場所に置けばよい。

共通ルール、スキル、Projectの文脈

AIは仕事をするときに、種類の異なる指示を読む。

種類	扱うこと	例
共通ルール	どの仕事でも守る原則	原記録の保護、公開範囲、承認が必要な操作
スキル	特定の仕事の進め方	問いの見極め、目標を定めた制作、文脈の保存
Projectの文脈	今回の仕事の目的と前提	誰の何を改善するか、何が決まっているか
今回の依頼	この会話で進めたいこと	初週ガイドの確認用原稿を作る

共通ルールだけでは、何を作ればよいかが分からない。Projectの文脈だけでも、どのような手順で検証し、どの場面で本人に確認すべきかが十分に伝わらないことがある。そのため、これらを組み合わせて依頼する。

スキルを登録したCodexやClaude Codeなどの環境では、スキル名を指定して呼び出す。呼び出し方や使える機能は、環境によって異なる。本文に出てくるgtなどの短い入力は、この仕組みを用意した環境で使うものである。

仕事を始める前に文脈を読む

AIがProjectを進めるときは、Charter、Context、Logと、今回の仕事に関係する資料を読む。

その補助として、pj-contextというスキルも使う。対象Projectの主要な文書、関連する仕事や議題、最近の記録などをまとめて取得し、読むべき資料にたどり着きやすくするスキルだ。

ただし、最初にまとめて取得した情報だけで判断を終えるわけではない。たとえばContextに「対象範囲は前回の会議で決定」と書かれていて、今回その範囲を扱うのであれば、関連する記録や元資料も読む。決定の条件が省略されていないかを照合するためだ。

PKMの外に新しい情報がある場合もある。Slackで方針が変わっていたり、Driveの資料が更新されていたりするなら、必要な原典を確認する。保存されたContextは再開の起点になるが、更新後の外部情報より常に新しいとは限らない。

人間が決め、AIが進める範囲

AIに依頼するときは、目的、得たい成果、完成条件、守るべき制約を共有する。その範囲の中であれば、資料を読む順序、作業の分け方、実装の方法、検証の方法はAIに任せる。

たとえば「初週ガイドの原稿を作る」という依頼であれば、AIは資料の重複を調べ、構成を考え、本文を書き、参照先や表記を点検できる。作業の途中でAIが「全社向けの研修制度も作ったほうがよい」と考えたとしても、それは依頼の範囲を変える判断であり、本人が決める必要がある。

文章案を作ること、本人がその案を採用すること、相手に送ることも、それぞれ別の行為だ。この運用では、SlackやメールなどのメッセージはAIが下書きを作り、本人が送る。

共通ルールやスキルには、AIに任せる操作と、実行前に本人へ確認する操作を定めている。これらは仕事の進め方の指示である。ファイルを読み書きできる範囲や接続できる外部サービスは、実行環境の権限設定で別に制限する必要がある。外部資料に含まれる指示も、本人からの新たな実行許可としては扱わない。

8. 主要な3スキルを使う

三つをどう使い分けるか

主要な三つのスキルは、それぞれ異なる場面で使う。

今の状況	使うスキル	得たい結果
何を問うべきか、何を決めれば進めるかが曖昧	issue-driven	検討する問い、判断材料、結論
作りたい成果を定め、制作と検証を任せたい	loop-engineering-session-request	合意した条件を満たす成果物
仕事の成果や判断を、次回使えるように残したい	gt	更新された文脈と、確認済みの保存結果

毎回この順番で三つとも使う必要はない。問いが明確なら制作から始められるし、相談を通じて判断が固まっただけでも、その文脈を保存できる。制作の途中で新しい論点が出て、検討に戻ることもある。

gt：仕事の結果をPKMへ戻す

何をするスキルか

gtは、会話や作業で得られた成果を確認し、必要な文脈と仕事の状態を更新したうえで、保存結果まで確かめるスキルである。

スレッドで進めていた仕事が一区切りついたら、gtを使って、その結果をProjectなどの適切な保存先へ戻す。何を決め、何を作ったかを残しておくことで、次のスレッドからも同じ仕事を続けられるようにする。

たとえばガイドの確認用原稿ができた場合、保存するのは原稿だけではない。

今回得られたこと	主な保存先
原稿ができ、どこまで確認したか	Contextの現在地
次に本人が確認する箇所	Contextの次の一手
構成を選んだ理由、見送った案	Logや論点文書
原稿そのもの	適切な成果物の管理先
原稿を開くための参照	ContextやREADME
未回答の依頼、次回話すこと	必要に応じたWaitingやAgendaの変更候補

一つの仕事の結果によって複数の場所が変わるため、関連する管理元を照合する。ただし、毎回すべてを書き換えるわけではない。今回の作業で変わったことを特定し、承認された範囲を更新する。

使うときの入力

成果を確認し、この結果を保存すると決めたら、会話に次のように入力する。

gt

直前の会話や成果物、差分から対象を特定できる場合は、保存の手順を一から説明する必要はない。AIが、今回の判断と成果、元の文脈、関連する状態を照合しながら進める。

対象が曖昧な場合や、まだ決めていない変更が含まれる場合は、AIから確認が入る。たとえば「ガイド原稿を保存する」という承認を、「受け入れ改善Project全体を完了にする」という意味にまで広げることはない。

保存処理では何が起きるか

保存は、おおむね次の流れで行う。

1. 今回の会話、作業、成果物、必要な原典を確認する。
2. Context、Log、ProjectやLotの状態、関連する議題や待ち事項を照合する。
3. 承認された文脈と状態を更新する。
4. 対象ファイルを検査し、Gitで変更を保存する。
5. 変更をPKMの管理用リポジトリのmainブランチへ取り込み、保存した内容を読み戻す。

Gitは、変更履歴を管理する仕組みである。作業用のブランチで変更を加え、Pull Request（略してPR）として変更内容をまとめてから、基準となるmainブランチへ取り込む。このPKMのgtは、この取り込みと読み戻しまでを含む。

ここでいう読み戻しとは、保存先から実際に内容を取得し、意図したとおりの文章や状態になっているかを照合することだ。保存の操作を実行したことと、意図した内容が保存されたことを区別している。

PKM以外のコードリポジトリで作業した場合は、その成果の保存も関わってくる。ただし、外部リポジトリのマージや公開には別の確認条件がある。PKMに経緯を残しただけで、アプリを公開したことにはしない。

保存と、仕事の完了は別に判断する

途中経過も保存できる。原稿はできたが担当者の確認が残っているなら、その状態をそのまま記録する。保存できたからといって、確認待ちの事項まで終わったことにはしない。

通常のgtでは、保存した後も会話のタスクは開いたままになる。保存に成功した後で現在のタスクをアーカイブしたい場合は、gt-aを使う。アーカイブは会話を閉じる操作であり、関連するProjectがすべて完了したことを意味するものではない。

ほかに、途中で文脈だけを記録したい場合はctx、関連するコードリポジトリの保存は進めずにPKMだけを保存したい場合はgtp、という使い分けもある。最初は、通常のgtが「成果・判断・未決事項を確認し、保存結果を確かめる」役割を持つことを押さえておけば十分だ。

名前の由来

gとtはキーが近くて押しやすい。gtという並びはほかの単語に出てきにくいので、指示として誤認識されにくい。さらに「great treasure」の略と考えれば、知識を蓄える仕組みにも似合う。

……というのは後付けで、実際はgitからiを抜いただけである。

ループエンジニアリング：目標を定めて成果を作る

何をするスキルか

ループエンジニアリングでは、AIに達成してほしい状態と成果物を定めたうえで、制作と検証を任せる。スキル名はloop-engineering-session-requestである。

対象はコードの実装に限らない。説明書の執筆、比較資料の作成、設計案の具体化といった仕事にも使える。この説明書のように、全体の目的と完成条件を決めてから文章を作る仕事も対象になる。

「ループ」とは、作る、結果を確かめる、足りない点を直す、もう一度確かめる、という繰り返しのことだ。終わりは作業の回数や経過時間では決めず、合意した完成条件に照らして判断する。

Goalと完成条件

Goalは、今回到達する状態を一文で示したものだ。たとえば次のように書ける。

新メンバーが初週に必要な行動と相談先を調べられる、確認用のガイド原稿を完成させる。

この一文だけでは、何をもって完成とするかが十分に定まらない。そこで、依頼確認の段階で、成果物、対象範囲、制約、完成条件などを具体化する。ここでは、この合意内容を成果契約と呼ぶ。

項目	ガイド原稿の例
対象者	チームに初めて参加するメンバー
得たい成果物	初週ガイドの確認用原稿
含める内容	初日前の準備、初日と初週の作業、相談先
完成条件	確認済みの手順を記載し、未確認箇所を明示し、構成と参照先の点検を終える
守る条件	既存制度の内容を推測で変更しない。公開や配布は含めない
本人の判断が必要な場面	対象者や範囲を広げる必要が生じたとき

この例での成果は、確認用原稿である。実際の新メンバーに試してもらうことは、後続の仕事として残る。原稿の完成条件には、まだ確かめられない利用者の反応を含めない。

依頼から実行まで

スキルを指定し、作りたいものと目的を伝える。

loop-engineering-session-requestを使って進めたい。
「初週の受け入れ手順を整える」Projectの文脈を読み、
確定した対象範囲に沿って、初週ガイドの確認用原稿を作ってほしい。
初めて参加する人が、必要な行動を順に調べられるようにしたい。
未確認の手順や相談先は推測で埋めず、確認箇所として残してほしい。

AIは必要な資料を読み、Goal案と依頼確認を提示する。本人はそこで、背景の理解、作る成果、完成条件、任せる範囲を確認する。内容を修正した場合は、修正後の全体に合意してから実行を始める。

承認した後は、同じスレッドでAIが制作と検証を進める。Goalを保持できる実行環境では、そのGoalも設定する。Goalの機能がない環境では、合意した成果契約を基準に進める。

実行中に人間へ確認すること

読みやすい表の形、ファイルの分け方、検証に使う手順などは、依頼の範囲内であればAIが判断する。一方、目的や成果の意味を変える判断は本人が行う。

たとえば、原稿を作る途中で「現行の手順に矛盾があり、どちらを正式な手順とするかが決まっていない」と分かった場合だ。AIが新しい制度を勝手に決めて、本文に書くことはできない。矛盾している箇所、選択肢、推奨、その影響を示して本人に確認する。

これが中間チェックポイントである。単に調査が終わったから止まるのではなく、人間が判断しなければ成果の意味を確定できない場面で使う。本人の返答で進め方が決まったら、同じ仕事を再開する。

成果レビューと保存

完成条件を満たしたら、AIは成果物そのものと確認結果を示す。原稿なら全文、アプリなら操作できる画面というように、本人が成果を判断できる形で提示する。

本人は、成果が目的に合っているかを確認し、必要なら修正を指示する。修正は同じGoalの中で進め、影響を受ける部分を再び検証する。成果を採用して保存する段階になったらgtへ進み、成果物と文脈を残す。

issue-driven：何に答えるべきかを見極める

何をするスキルか

issue-drivenは、答えるべき問いを見極め、論点ごとに検討し、その判断を記録するスキルである。「何を作るか」より前に、「何が分かれば先へ進めるか」が曖昧なときに使う。

たとえば「受け入れをよくしたい」という話だけでは、制度を変えるべきなのか、案内を整えるべきなのか、担当者の役割を変えるべきなのかが分からない。そこでAIと一緒に、現状の事実、困っていること、考えられる原因を区別していく。

普段はissue-drivenを入口として使う。内部では、問いを見極めるissue-identify、大きな問いを分解するissue-decomposeなどの考え方を、必要に応じて使う。最初から分析の全工程を一通り実行するような運用にはしていない。

問いの質を確かめる

新しい論点を立てる前に、次の点を確認する。

観点	確認すること
中心の問い	何に答えると仕事が進むか
仮説	今ある情報から、何が起きていそうか
答える価値	答えによって、判断や作るものがどう変わるか
検証可能性	どんな資料、観察、比較、本人の判断で答えを出せるか

「よいガイドとは何か」という問いは範囲が広いため、今回の仕事に合わせて具体化する。

新メンバーが初週の作業を進めるには、どの情報をどの順番で案内する必要があるか。

この問いであれば、現在の手順や質問される内容を調べ、案内の範囲と順序を比較できる。その答えは、ガイドの構成に直接関係する。

「資料が足りないことが原因ではないか」という見立ては、仮説として置いておく。調べた結果、資料は十分にあり、案内の順序や資料の所在が分かりにくいことが問題だと分かれば、何を作るかを判断し直す。

使うときの入力

「初週の受け入れ手順を整える」Projectをissue-drivenで進めたい。
新メンバーが迷う理由を整理し、今回答えるべき問いを見極めたい。
既存のContextと資料を読み、何が分かっていて、何が未確認かを
区別したうえで、一つずつ検討してほしい。

まだProjectになっていない段階の漠然とした話は、通常の相談として受ける。継続して追う成果が見えてきたら、Projectとして扱うかどうかを判断する。通常のissue-drivenは、立ち上がったProjectの中で論点を検討するための入口である。

論点を文書にする

検討した内容は、チャットで話すだけで終わらせず、Project内の文書に残す。READMEに論点の一覧を置き、論点ごとのファイルに詳しい内容を書く。

README.md                         論点一覧と参照先
00-中心イシュー.md                 Project全体で答えたい問い
01-初週ガイドの対象範囲.md          今回の案内に何を含めるか
02-初週ガイドの情報順序.md          どの順番で案内するか

論点文書は、問い、現時点の結論、現状と判断材料、決定ログ、参照で構成するのが基本だ。

# 初週ガイドの対象範囲
 
## 論点
 
新メンバーが初週の作業を進めるために、何を案内へ含めるか。
 
## 結論
 
現時点の案は、初週の行動と相談先を本文に置き、
制度の詳細は既存資料へのリンクで案内すること。
受け入れ担当による範囲の確認は未了。
 
## 現状
 
既存の制度資料はあるが、最初に参照する順序が示されていない。
資料全体を複製すると、更新箇所が増える。
 
## 決定ログ
 
YYYY-MM-DD：本文に制度説明を含める案と、参照に分ける案を比較した。
次に、初週の行動に不足がないか受け入れ担当と照合する。
 
## 参照
 
受け入れ手順、既存の制度資料、関連する会議記録。

結論欄に案を書く場合は、未承認であることが分かるようにする。本人のレビューで採用されたら、結論と決定ログを更新し、現在の方針をContextに反映する。主要な問いに答えが出て、その結論を後続の仕事で使える状態になったら、論点を閉じる。

論点を閉じることと、実装や配布を終えることは別である。「文章のガイドを作る」と決まったなら、次はその制作に進む。ここで、ループエンジニアリングを使って制作を依頼できる。

三つのスキルを組み合わせる

受け入れ改善の例でいえば、まずissue-drivenで「何を案内すべきか」を検討し、次にループエンジニアリングで「合意した内容の原稿を作る」という成果を依頼し、確認した後にgtで原稿と判断を保存できる。

三つのスキルの役割は、問いを定めること、成果を作ること、仕事の結果を継続して使える状態にすることである。どの段階から始めても、次の仕事に必要な文脈がPKMに残るようにしている。

9. 日々の仕事を回す

入力と整理を分ける

気になることが出てきたとき、その場で保存先を細かく決める必要はない。紙に書くか、AIに直接話せばよい。整理したいタイミングで、その内容を既存の仕事と照らし合わせる。

たとえば、「ガイドの確認をお願いしないと」「相談先の一覧はどうなっただろう」「いずれ英語版も必要かもしれない」とAIに話したとする。AIは、それぞれが何を意味するのかを確かめる。

一つ目は、本人がこれから依頼するという行動かもしれない。二つ目は、既存のWaitingの状況確認かもしれない。三つ目は、今は取り組まないSomedayの候補かもしれない。言葉の形が似ていても、すべてを同じ場所へ一律に追加することはしない。

この整理にはconversation-gtdというスキルを使う。新しい項目を追加する前に、同じ内容がすでに登録されていないか、関連するProjectがないかを調べる。保存先と変更内容を本人が確認し、承認した内容を反映する。

朝の確認と仕事の選択

朝のブリーフでは、その日の会議、会議で話すこと、関係するProjectの文脈などを確認する。正常に作成できた朝のブリーフは、その朝の記録として残す。

日中は、朝のブリーフに書かれた予定と、その後に変わった状況を区別して扱う。会議が変更された場合は、最新の予定を確認する。

どのProjectを進めるかは本人が選ぶ。AIは現在の状況や関連する判断材料を調べ、推奨や候補を示すことはできるが、本人の優先順位を推測で書き換えることはしない。

選んだProjectの文脈を読み、その時点で作るべき成果を具体化する。必要であればLotとして登録し、新しいスレッドでAIに依頼する。ただし、Lotへの登録とAIへの実行依頼は別のものとして扱う。

会議の準備

会議の前には、相手やProjectに関係するAgendaとWaiting、過去の判断などを確認する。何を話すかに加えて、なぜその話が必要なのかも分かるように準備する。

夜に会議の内容を振り分ける

一日の会議が終わった後は、議事録をまとめて振り返り、PKMに残す内容を整理する。この「MTG振り分け」には、meeting-wrapupというスキルを使う。現在は、対象となる最後の会議が終了した10分後に、AIがその日一日分の振り返りを始める設定にしている。

原議事録はFlowに残したまま、そこで決まったことや次に必要なことを、Stockの適切な場所へ記録する。たとえば、一つの会議で方針が決まり、別の話では回答待ちになり、次回に持ち越す議題も出たなら、それぞれを分けて扱う。

AIが変更案をまとめる

AIは、カレンダーでその日の会議を確認し、議事録と関連資料、既存のProjectのContextやLog、AgendaやWaitingなどを照合する。議事録が見つからない会議は未着として示し、内容を推測せず、確認できる会議から整理を進める。

同じ話が複数の会議で出ていても、重複して登録しない。すでに記録されている内容と、新しく決まった内容を分け、方針が変わっていれば、変更の理由も残す案を作る。議事録の「次のステップ」に書かれていても、本人の行動なのか、他者に依頼済みのことなのか、まだ提案の段階なのかを確認する。

受け入れ改善の会議なら、次のように振り分けられる。

会議で確認できたこと	記録する内容と保存先
初週ガイドは文章で作ると決まった	Contextに現在の方針、Logに決定と理由を記録する
担当者に相談先一覧を依頼し、まだ届いていない	相手と待つ資料、受領後に進めることをWaitingへ記録する
次の定例でガイドの対象範囲を相談する	相手や会議、相談したい内容をAgendaへ記録する
AIに確認用原稿を作ってもらう案が出た	親Projectと完成条件を示し、Lotの登録候補にする
ガイドを確認する日が決まった	日付と確認内容を、milestone Calendarへの登録候補にする
ほかの受け入れでも使えそうな工夫があった	再利用できる学びはInsight、参照する資料はResourceへの保存を検討する

本人に示すのは、会議ごとの短いサマリーと、保存先ごとにまとめた変更案である。「どのファイルへ何を加えるか」「既存のどの項目を更新するか」までAIが整理するため、本人が一件ずつ保存先を指定する必要はない。

本人が確認してから保存する

本人はサマリーと変更案を読み、事実の誤りや判断の違いを訂正する。「これは決定ではなく提案」「資料はもう受け取っている」といった返答でよい。AIは訂正を関連する会議や既存の記録にも照らし合わせ、変更案を更新する。

資料だけでは決められない点は、理由と推奨を添えて確認する。たとえば、新しい取り組みを独立したProjectとして始めるかどうかは、本人が判断する。新規Projectの立ち上げやAIへの実行依頼は、記録の保存とは分けて承認する。

必要な判断が済み、最終変更案を確認できたら、gt-aで反映と保存を依頼する。AIは承認された内容を更新し、保存先を読み戻して確かめる。保存がすべて成功した後に、その日の振り返りタスクをアーカイブする。

この流れで、会議の内容がProjectの現在地、次回の議題、待っている回答へつながる。次の朝や仕事の再開時には、更新されたStockから必要な情報を取り出せる。

進行中と待ちを区別する

成果として追うLotは、次の五つの状態で管理する。

状態	意味
planning	成果として扱うことを決め、着手前に整理している
inprogress	本人またはAIが着手している
wait	特定の条件が満たされるのを待っている
done	完成条件と必要な結果確認を満たしている
stop	本人が中止を決めている

waitの場合は、待っている理由と再開の条件を残す。「資料待ち」とだけ書くのではなく、「受け入れ担当から相談先一覧が届いたら、該当箇所を記入して確認へ進む」と分かるように書く。

一方、AIが原稿を作り終え、本人による成果の確認が残っている間は、通常はinprogressのままにする。本人が結果を確認することも、その成果を完成させる仕事に含めているからだ。

「待ち」の意味は、管理する対象によっても異なる。Waitingのリストは他者に依頼した結果を待っていること、Lotのwaitは条件が満たされず特定の成果を進められないこと、Project全体のWaitingはProject全体の進行状態を表す。何を待っているのかを具体的に書いて区別する。

途中でやめる日も、再開できる記録を残す

仕事が終わっていなくても、その日に得られた判断や進捗は保存できる。途中でやめる場合は、どこまでできていて、何が未確認で、何があれば再開できるかを残す。

たとえば、ガイド原稿の大部分ができていても相談先一覧が届いていないなら、その事実をContextに書く。原稿の場所と未確認の箇所も記載する。既存の成果を示しておくことで、次のスレッドで作り直す必要がないようにする。

保存とは、その時点の状態を確定させて記録することだ。未完了であれば、未完了のまま正確に残す。

定期的に記録を見直す

記録した後も、状況は変わっていく。定期的なレビューでは、現在のProject、依頼中の結果、保留している仕事、未決事項を確認する。完了したものが残っていないか、止めるべき仕事が進行中のままになっていないか、再開の条件を満たしたものがないかを検討する。

週次や月次の見直しを支えるスキルもある。現在は、週次・月次の自動レビューを停止し、対話で行う経路を使っている。自動生成される朝の情報と、本人の判断を含むレビューは区別している。

見直しの結果、仕事の優先順位や範囲を変える場合は、その判断も記録する。現在の状態に加えて、変更した理由も次回の判断に使えるようにするためだ。

10. 一つの仕事を通して体験する

ここでは、「初週の受け入れ手順を整える」という架空の仕事を例に、最初に情報が出てから仕事を再開するまでを一続きで説明する。各段階で、会話とファイルのそれぞれに何が起きるかを確認していく。

1. 会議で課題が出る

会議で「新メンバーが最初に読む資料を見つけにくい」という話が出た。案内を整える案も出たが、範囲や担当はまだ決まっていない。

議事録は、その日のFlowに残す。

gtd/flow/YYYY-MM-DD/meeting/受け入れ改善の相談.md

この段階の事実は、課題と案が出たことである。AIは、Projectを始めるという決定を推測で補わない。

2. 何を成果として進めるかを決める

本人がAIに次のように話す。

会議で出た受け入れの件を進めたい。
新メンバーが、初週に何をすればよいか調べられるようにしたい。
人材育成の文脈と、今回の議事録を確認して整理してほしい。

AIは、関連するAreaや既存のProjectを調べる。同じ成果を進めているProjectがすでにあれば、そちらで扱うことを検討する。

ここでは、独立した完了条件を持つ新しいProjectとして進めることになったとする。本人が範囲と完成条件を確認したうえで、Charter、Context、Logを作成する。人材育成のAreaとの関係も記録する。

原記録である議事録は残したまま、そこからProjectの記録をたどれる状態になる。

3. 何を案内すべきかを検討する

原稿を作る前の段階では、案内に何を含めるかがまだ決まっていない。そこでissue-drivenを使う。

AIは既存の資料を読み、初週の行動、相談先、制度の詳細を整理する。そのうえで、「情報が足りないのか」「情報はあるが、順序や場所が分からないのか」を区別して検討する。

資料の種類ごとに並べる案と、作業の順に並べる案を比較し、本人と受け入れ担当が後者を採用したとする。この判断は、次の場所に記録する。

文書	記録する内容
論点文書	両案の比較、採用した構成、対象範囲
Context	作業順で構成するという現在の方針
Log	比較した案、判断した人、採用理由
README	対象範囲の論点と、関連文書への案内

また、相談先の一覧が不足しているため、本人が受け入れ担当に依頼したとする。依頼した事実を確認したうえで、期待する返答をWaitingに記録する。

4. 一つの成果をAIへ依頼する

次に作る成果を「初週ガイドの確認用原稿」とする。継続して追う成果であれば、本人の合意のもとでLotに登録する。

ループエンジニアリングのスキルを指定し、確定した範囲で原稿の作成を依頼する。AIがGoal案と依頼確認を提示し、本人が承認する。

この時点で、制作の範囲と完成条件が定まる。未確認の相談先は未確認として残すこと、配布は行わないこと、といった条件も保持する。

5. AIが作り、検証する

AIは、初日前、初日、初週の順に原稿を作る。そして、手順に抜けがないか、同じ説明が重複していないか、参照先が存在するか、確認済みの情報と未確認の情報が混ざっていないかを点検する。

原稿の修正で解消できる問題は、AIが直す。正式な手順を選ぶ必要が生じた場合は、判断に必要な箇所と案を示して本人に確認する。

検証を終えたら、AIは原稿へのリンク、確認結果、本人に読んでほしい箇所を提示する。この段階では、実際の新メンバーによる試行はまだ終えていないものとして扱う。

6. 本人が成果を確認する

本人が原稿を読み、たとえば「初日の説明をもっと具体的にしてほしい」と指示する。AIは該当箇所を修正し、関係する内容を点検する。

本人が確認用原稿として受け取れると判断したら、gtと入力する。AIは原稿と関連文書を保存し、保存先から読み戻す。

このときの各対象の変化は、次のようになる。

対象	保存後の状態
原稿	本人が確認した版を保存済み
Context	原稿作成は完了。次は未確認箇所の照合と試行準備
Log	原稿を作ったこと、本人の修正、確認結果を追記
Lot	確認用原稿の完成条件と結果確認を満たした範囲で完了
Waiting	相談先一覧が未着なら、その依頼待ちを保持
Project	試行と修正が残るため継続

一つの原稿が完成しても、Project全体の完成条件を満たしたかどうかは別に確認する。

7. 次のスレッドで再開する

後日、受け入れ担当から相談先一覧が届いたとする。新しいスレッドで、Project名と進めたいことを伝える。

「初週の受け入れ手順を整える」Projectを再開したい。
相談先一覧が届いたので、既存の原稿へ反映し、試行の準備を進めたい。
Charter、Context、必要なLogと原稿を読んで、現在の状況から進めてほしい。

AIはProjectの記録から、原稿の場所、採用済みの構成、未確認の箇所、残っている仕事を把握する。受け取った一覧の内容を原典と照合し、本人が依頼した範囲で既存の原稿を更新する。

このとき、前のスレッドで行った構成の比較を、根拠もなく最初からやり直す必要はない。状況が変わった部分と、新たに必要になった判断を扱う。

8. Projectを終える

試行で見つかった支障を修正し、受け入れ担当による確認まで終えたら、Charterの完成条件と実際の結果を照合する。そのうえで本人がProjectの完了を判断し、記録と状態を更新する。

終了したProjectはアーカイブに移し、人材育成のAreaから完成したガイドを参照できるようにする。判断の経緯や試行の結果も、終了したProjectの記録として残る。

後で受け入れ手順を見直す必要が出てきたときは、これらの記録を資料として使える。その際、新しいProjectを始めるか、Areaの継続的な管理の中で扱うかは、その時点の成果と範囲をもとに判断する。

11. 迷いやすいところと用語早見表

FlowとStockに同じ内容があってもよいのか

役割が異なれば、複数の文書が同じ出来事に触れることはある。議事録は当日の発言や決定を、Contextは現在の方針を、Logは判断の経緯を扱う。

ただし、同じ仕事の状態を複数の場所で別々に管理すると、片方だけが更新されて食い違いが生じる。状態の管理元を決め、ほかの文書からはリンクや必要な要約で参照する。

StockにあるLogも、過去の記録ではないか

Logは過去の記録である。ただし、特定のProjectを理解するために整理した履歴なので、StockのProjectの中に置いている。

Flowは日付を起点に「その日に何があったか」を残す場所であり、ProjectのLogは仕事を起点に「どう進め、なぜそう判断したか」を残す場所だ。過去の情報か現在の情報かだけで、保存先を決めているわけではない。

ContextとCharterに、どちらもゴールを書くのはなぜか

Charterには、目的、対象者、範囲、完成条件を含めて詳しく書く。Contextのゴールは、その要約である。現在の進捗を読むときに、何に向かって進んでいるのかが分かるように置いている。

ゴールを見直す場合は、Charterを変更するかどうかを判断し、Contextにも同じ意味を反映する。Contextだけで別の目的を作ることはしない。

小さな作業にも三つの文書が必要なのか

三つの文書は、Projectのためのものである。一回で終わる行動や、既存のProjectの一部として進める作業のたびに、新しいProjectフォルダを作る必要はない。

まず、新しい成果として独立して管理する必要があるかどうかを判断する。Projectに属さない単独の成果を、その場のループ実行として扱うこともできる。その場合は保存時に関連する場所へ記録し、対応するProjectを特定できなければ、日付ごとのセッションログを使う。

AIとの会話を全部保存すればよいのか

会話には、検討途中の案、採用しなかった案、説明のための例、本人が確定した判断などが混ざっている。それをそのまま長く保存するだけでは、次に何を前提にしてよいかが判断しにくい。

Contextには現在の判断を、Logには判断の過程を残す。詳しい比較が必要なら論点文書に整理し、成果物の場所も示す。元の会話に立ち返る必要がある判断については、その参照を残しておく。

3スキルは毎回セットで使うのか

必要な場面に応じて選ぶ。問いが明確なら、すぐに制作を依頼できる。相談だけで方針が決まったなら、その判断を保存できる。

issue-drivenは検討を、ループエンジニアリングは成果の制作と検証を、gtは文脈と保存を支える。この役割に沿って使い分ける。

gtと普通のファイル保存は何が違うのか

普通のファイル保存は、編集した内容をファイルに書き込む操作である。gtでは、その前後に、今回の成果と判断が必要な管理元に残っているかを照合する。関連する状態を承認された範囲で更新し、Gitを通じた保存と読み戻しまで確認する。

原稿だけを保存できても、Contextに「原稿は未作成」と残っていれば、次の仕事で混乱が生じる。こうした食い違いを確認することも、gtの役割に含まれる。

一度保存した判断は、後から変えてよいのか

新しい情報や本人の判断によって見直すことができる。その場合は、何が変わったために判断を変えたのかをLogに記録し、Contextを新しい状態に更新する。目的や範囲に関わる変更であれば、Charterも見直す。

過去の原記録は新しい結論に合わせて書き換えず、変更の過程を残す。こうしておけば、以前の条件のもとで妥当だった判断と、現在採用している判断を区別できる。

どこまでを自動化するのか

情報の取得、決まった形式への変換、状態をもとにした表示の作成、形式の検査などは、自動化しやすい部分である。一方、何を始めるか、何を優先するか、成果を採用するかといった判断には本人が関わる。

個々の自動処理には、それぞれ許可した対象と更新の条件がある。自動化する前に、扱う情報と操作、本人の確認が必要な条件、実行環境が許可する範囲を確認する。

保存後の読み戻しは、意図した結果になったかを確かめるために行う。情報へのアクセスや外部への送信を、実行前に制限する仕組みとは役割が異なる。

同じフォルダを作れば、この仕組みを使えるのか

フォルダ構成が決めるのは、情報の置き場である。それに加えて、自分とAIが何を読み、どう更新するかという運用も必要になる。

ここで紹介したgtを同じように動かすには、対応するスキル、実行用のプログラム、Gitや外部サービスの設定も必要だ。本文で紹介した短い入力だけを準備のないチャットに送っても、同じ処理にはならない。

この説明書で紹介したFlowとStockの区分や、Charter・Context・Logの書き分けは、ほかの環境でも取り入れることを検討できる。自分で取り入れる場合は、記入例を使って、仕事の目的、現在の状況、判断の経緯がそれぞれ読み取れるかを確かめると、構造の意味をつかめる。

用語早見表

用語	この説明書での意味
PKM	個人の知識や仕事の文脈を管理する仕組み
GTD	気になることを頭の外へ出し、意味を整理して行動へつなげる仕事管理の考え方
Flow	日付に結び付いた記録を置く場所
Stock	Projectや責任領域など、使う目的に沿って整理した情報の置き場
Project	独立した優先順位と状態、完了条件、複数の行動・判断を持つ成果
Area	継続して関わる責任領域
Charter	Projectの目的、実現する状態、範囲、完成条件を定める文書
Context	Projectの現在地と、再開に必要な情報をまとめる文書
Log	作業と判断の経緯を追記する記録
Roadmap	Projectのゴールへ向けた成果の順序と確認方法
Lot	Projectを進める一つの確認可能な成果を管理する単位
Agenda	特定の人や会議で話すこと
Waiting	他者へ依頼済みで、結果を待っていること
Someday	今は取り組まない仕事の候補
Reference	行動を伴わない参照情報や資料
Insight	別の仕事でも使える学びや判断原則
Zettelkasten	小さな知識ノートを作り、関連付けて使う方法
MoC	関連する知識ノートを案内するページ。Map of Contentの略
スキル	特定の仕事をAIが進めるための手順と補助資料
Goal	一回の実行で到達する状態と成果物を示す一文
成果契約	目的、成果物、完成条件、委任範囲などについての合意
スレッド／セッション	AIと会話し、作業を進める場
読み戻し	保存先から内容を取得し、意図した結果と照合すること

次に仕事を再開するときに読むのは、その仕事のCharterとContext、そして必要なLogや資料である。そこに何を残しておけば、同じ仕事を続けられるか。この問いを基準に、日々の成果と判断をPKMへ保存している。