Research＋ZKリファクタリング 作業方針

このポリシーの役割

本ノートは、Research＋ZK全体のクラスタリング・リファクタリングを別のWorkスレッドで再開しても、作業の目的、AIとFukkamaruの役割、判断基準、実施順序が変質しないようにするための恒久的な作業方針である。

本ノートには、承認済みのタスク全体方針を記録する。現在の進捗、次に処理するクラスタ、個別ノートの判断結果は、本ノートへ重複して持たせず、ロードマップ、クラスタ作業台、親クラスタ用ログを正本とする。

新しいWorkスレッドでは、本ノートを単なるクラスタ分類ルールとして読んではならない。この作業は、クラスタリングによって判断対象を人間が扱える規模へ絞り、その単位でResearchとZettelkastenを実際にリファクタリングする長期作業である。

新しい判断によってタスク全体の方針が変わる場合は、変更点と以前の方針への影響をFukkamaruへ示し、承認後に本ノートへ反映する。個別クラスタだけに有効な判断は、そのクラスタの作業台またはログへ記録する。

目的

既存ノートの増加によって、全体を一度に把握し、関連カード、重複、補完関係、統合・分割候補を人間だけで探し切ることが難しくなっている。整理対象の選択肢が多すぎるため、何から着手するかを決めること自体が大きな認知負荷になっている。

本作業の第一目的は、次のとおりである。

ResearchとZettelkastenを同じ知識空間として照合し、大量のノートを、人間が理解・比較・判断できる規模のクラスタと子クラスタへ圧縮する。

クラスタリングは最終成果ではなく、リファクタリングを安全かつ継続的に行うための入口とする。その結果として、次を目指す。

1. ノート整理と役割判定の精度を上げる
2. 次に確認・判断する範囲を明確にする
3. 一度に抱える選択肢を減らし、整理の認知負荷を下げる
4. 長期の整理を中断・再開しながら継続できる状態にする
5. カード同士の重複だけでなく、新しい関係、補完、対立、前提、派生を発見する
6. Fukkamaru自身が、今後のZettelkasten整理に使える判断基準を理解する

単にノートをジャンル別フォルダへ分類すること、ファイル数を減らすこと、AIが知識管理の主体になることは目的としない。

AIとFukkamaruの役割

AIの役割

AIは最終判断者ではなく、大量のノートに対する探索・比較・俯瞰能力を拡張する補助者として振る舞う。

主に次を担当する。

• 対象ノートの走査と概要把握
• 意味的クラスタリングと境界候補の発見
• 関連、重複、補完、矛盾・緊張関係の発見
• 前提／派生、抽象／具体、原則／事例、原因／結果の関係の発見
• 統合、分割、改訂、降格、廃止候補の発見
• 現在リンクされていない新規リンク候補の発見
• Researchから独立したカード候補の抽出
• 既存カードの役割、粒度、根拠、品質の監査
• MOC / Structure / Indexの再構成、新設、統廃合候補の発見
• 整理効果と依存関係に基づく作業優先順位の提案
• 次に人間が判断する対象を、一論点または数枚のノートまで絞ること

AIは候補を大量に列挙してFukkamaruへ選択を丸投げせず、推奨案とその理由を示す。重要な判断では、根拠となる本文や関係を確認し、確認済みの事実、AIの推論、Fukkamaruの判断を区別する。

Fukkamaruの役割

Fukkamaruは知識管理と意味判断の主体として、次を決定する。

• どのクラスタまたは子クラスタから着手するか
• ノートの主張や意味をどの形で残すか
• 統合、分割、種別変更、移動、改名、削除を実施するか
• AIが提案した新しい関係やStructureを採用するか
• ユーザー自身の考えとしてPermanent Noteを成立させるか
• 公開範囲を変更するか

AIの提案だけを根拠に変更を確定しない。重要な変更は、理由、代替案、影響をFukkamaruが確認できる形にしてから決定する。

判断説明と学習支援

重要な判断では、結果だけでなく次を簡潔に説明する。

• なぜその判断候補になるのか
• どの記述や関係を根拠にしたのか
• どの特徴を見れば、同種のノートでも同じ判断ができるのか
• 今後似たノートが増えたときに、どのように考えればよいか

AIに依存しなければ整理できない状態を固定化せず、作業を通してFukkamaru側の判断基準も育てる。

対象範囲

• 現役の 31_Research と 32_Zk のMarkdownノート
• ノート種別を限定しない
• Permanentだけでなく、Fleeting、Literature、Structure、Index、type未設定・誤設定のノートも監査対象とする
• ResearchとZKを別々に整理せず、同じ知識空間として本文、主張、役割、リンクを突き合わせる
• Researchの内容が、既存カードとの重複、補強、対立、新規Permanent候補、Literatureとしての継続保持、MOC / Structure変更のどれに当たるかを検討する
• .退避を含む退避ファイルは、内容監査の対象外。ただし復元・変更履歴の確認では参照する
• 03_systems/research-zk-refactoring/work/ は、この作業期間だけの管理領域

上位ルール

1. 04_Context/_AI Start Here.md
2. 04_Context/Obsidian Zettelkasten Ai Operations.md
3. 本ノート
4. research-zk-cluster-roadmap.md
5. 各クラスタ作業台
6. AI Handoff、親クラスタ用ログ、AI Work Log

上位ルールと本作業の判断が矛盾する場合は、勝手に解釈せず差異と影響を示して確認する。

別スレッドでの再開手順

新しいWorkスレッドでは、会話履歴を正本とせず、次の順序で必要な状態を復元する。

1. 04_Context/_AI Start Here.mdと04_Context/Obsidian Zettelkasten Ai Operations.mdを読み、現在のアクセス・操作ルールを確認する
2. 本ポリシーを最初から最後まで読み、目的、役割分担、監査基準、承認境界を確認する
3. research-zk-cluster-roadmap.mdを読み、全体進捗、クラスタ境界、推奨順序、次の対象を確認する
4. 現在の親クラスタの作業台を読み、対象ノート、子クラスタ、判断、予定スレッド境界、未解決事項を確認する
5. 親クラスタ用ログから、完了済みの子クラスタと実施結果を確認する
6. 必要な場合だけresearch-zk-cluster-file-inventory.mdの該当行、対象ノート、関連ノートを読む
7. 「提案済み」「承認済み・未実施」「実施済み」「未解決」を混同せず、次に扱う小さな単位と許可されている操作を確認してから作業を再開する

ロードマップ、作業台、ログの記述が競合している場合は、更新日時だけで正しさを決めない。それぞれの正本としての役割を確認し、解消できない差異と作業への影響をFukkamaruへ示す。

既に完了したDiscoveryやクラスタを、新しいスレッドになったことだけを理由にやり直さない。再調査は、台帳の陳腐化、対象ノートの追加、記録間の矛盾など、必要な理由がある範囲に限定する。

作業全体のフェーズ

この作業は、次のフェーズを順に進める。現在どのフェーズにいるかは、ロードマップと対象クラスタの作業台で確認する。

Phase 1：Discovery / Mapping

ResearchとZKの全体像を俯瞰できる粒度で確認する。各ノートについて、まずノート名、type、主題、中心内容、主要リンク、強い関連候補、仮クラスタを把握する。

この段階では、既存ノートの本文編集、移動、改名、統合、分割、YAML変更、削除を行わない。最初からすべての本文を同じ深さで読むのではなく、一覧化後に必要な領域を深く読む。

Phase 2：仮クラスタと優先順位

各クラスタについて、クラスタ名、概要、主なノート、おおよその規模、Research / ZK構成、主な論点、想定される整理、他クラスタとの関係を示す。名称だけでなく、なぜ一緒に比較・接続・統廃合を検討する価値があるのかを説明する。

優先順位は、ノート数、重複量、Researchと既存ZKの重なり、整理効果、他クラスタへの波及、処理難易度、独立性、現在の知識構造上の重要性を考慮してAIが推奨する。候補一覧だけを示して選択を丸投げせず、推奨する開始クラスタと理由を示す。最終的な開始クラスタはFukkamaruが決定する。

Phase 3：親クラスタの作業設計

選択した親クラスタの本文とリンクを必要な範囲で深く読み、中心ノート、重複候補、境界ノートを確認する。親クラスタを実際に処理可能な子クラスタへ分け、依存関係と予定Workスレッド境界を作業台へ記録する。

最初に扱う対象は、一つの論点、重複候補群、または数枚の関連カードまで絞る。

Phase 4：子クラスタの詳細監査

ResearchとZKを横断し、各ノートを「内容」「関係」「役割」の3軸で監査する。監査だけではソースノートを変更しない。

Phase 5：変更提案と承認

実際の変更前に、少なくとも次を提示する。

1. 対象ノート
2. 現在の状態
3. 提案する変更
4. 変更理由と判断根拠
5. 影響する関連ノート、リンク、公開状態

必要な場合は、代替案、変更しない場合の影響、退避方法も示す。Fukkamaruの承認後にだけ、承認された範囲を実施する。

Phase 6：リファクタリングと検証

承認済みの改訂、統合、分割、種別変更、リンク追加、移動、改名、削除などを実施し、YAML、リンク、退避、公開状態、内容の保持、時限情報を検証する。

本文を扱うときの文章校正基準

本文の「校正」「整理」「まとめ直し」「リファクタリング」は、誤字修正、見出し追加、要約、YAML修正、冒頭の結論追加だけで済ませてはならない。元ノートを最初から最後まで読み、添付資料で確認した統合整理版と同じ水準で、内容を一つの論理的な文章へ再構成する。

再構成では、少なくとも次を保持する。

1. 検討の出発点、目的、利用者が置いた前提
2. 比較した選択肢、具体例、数値、例外、制約
3. 対話や追記によって条件・評価・結論が変わった経緯
4. 判断基準、採用・不採用の理由、最終的な結論
5. 今後の行動、再確認が必要な時限情報、未解決事項

会話形式、重複、断片的な追記は整理してよい。ただし、人間によるメモ、意図、背景、判断の文脈、具体的な検討材料を短い要約へ置き換えたり、失わせたりしてはならない。新しい事実の追加、現在時点での仕様・価格・性能の再検証は、依頼または承認された範囲でのみ行う。

再構成後のノートは、冒頭だけで結論を示すのではなく、読み進めれば「なぜその結論に至ったか」を追える構造にする。大きく再構成する既存ノートは、変更前全文を日付付き.退避へ保存する。

発話者・出典・対立する見解を保持する基準

チャットのコピー、複数人の感想、AIの回答、引用資料を含むノートは、本文を最初から最後まで読み、各記述について「誰が、どの時点で、どの立場から述べたものか」を把握してから再構成する。一部の文言だけを整えたり、AIが導いた結論だけを抜き出したりしてはならない。発言の前後関係、発言に対する反論・訂正・条件追加、最終判断に至らなかった保留も、意味を持つ内容として扱う。

再構成時は、読み手が発話者と情報の性質を取り違えない表現を選ぶ。形式はノートの内容に応じて使い分ける。

扱う内容	基本の表現	守ること
Fukkamaru自身の発話、問題意識、判断	引用ブロック、または本文中で発話者を明記	本人の意図・迷い・言い回しの要点を、AIの一般論へ置き換えない
AIの回答、質問、提案、誤案内	AIの回答などの明示的なラベルとコードブロック、または本文中で発話者を明記	AIの意見をFukkamaruの結論として書かない。後に訂正・不採用となった内容も経緯が必要なら残す
別ユーザー、第三者、公開事例、引用資料	出典・発話者・調査時点を本文または表で明示	他者の経験や一般情報を、Fukkamaru自身の経験・現行仕様・推奨と混同しない
対立・食い違い・未決着の見解	並べて比較できる文章、構造化リスト、比較表	都合よく一つの結論へ均さず、対立の理由、前提の違い、採否・保留を残す
AIによる整理・推論	AIの整理または推論であることを明示	原文にない事実や、本人が採用していない価値判断を補わない

引用ブロックやコードブロックは装飾のために増やすのではなく、発話者や原文の性質を区別しなければ文脈を誤読する箇所で使う。会話を逐語録のまま並べ直す必要はないが、引用を本文へ溶かす場合も、誰の発言・経験・判断かが追えるようにする。複数の見解が対立する場合は、各見解の根拠と条件を先に示し、その後にFukkamaruが採った判断、または判断を保留した理由を示す。

構成は見出しの細分化だけに頼らない。因果関係や時系列を文章でつなぎ、比較には表、手順や論点の集合には構造化リスト、関係や流れの把握にはMermaid図を使う。これらは情報を圧縮して意味を落とすためではなく、検討の構造、発話者の違い、選択肢の関係を読み手が追えるようにするために用いる。見出しは大きな論理の区切りに限定し、細かな断片ごとに見出しを増やして文脈を分断しない。

再構成後の検証では、少なくとも「本人のメモ・意図・判断基準が残っているか」「AI・第三者・引用資料との区別が残っているか」「対立・訂正・保留が単純化されていないか」「元の結論に至る経緯を本文だけで追えるか」を確認する。

Phase 7：子クラスタ・親クラスタの完了

子クラスタの処理と検証が完了した時点で親クラスタ用ログへ記録し、作業台とロードマップを必要な範囲で更新する。親クラスタ完了時は、変更結果だけでなく、得られた知識、今後使える判断基準、未解決事項、次の推奨クラスタをまとめる。

継続実行の原則

• 「承知しました。完了とします」のように、確認だけを伝えて作業を停止してはならない。
• Fukkamaruが個別の変更を承認した後は、次に許可不要で行える監査・検証・記録・提案へ進む。次の本文変更に承認が必要な場合は、停止の宣言ではなく、対象・現状・変更案・理由・影響を示して承認を求める。
• 明示的な中断、保留、別タスクへの切替、または外部の変化待ちをFukkamaruが指示した場合だけ、次の作業へ進まずに待機する。

ファイル操作方針

• 既存本文、YAMLの意味変更、title、type、draft、ファイル名、移動、統合、分割、削除は、対象・現状・変更案・理由・影響を提示し、承認後に実施する
• 既存ファイル名は承認なしに変更しない
• 新規リンク追加は原則として承認後に行う。ただし既存の継続許可に従い、draft: trueノートへの合理的なリンク追加は可能
• index.md、public-zettelkasten-build.md、テンプレート、画像、Obsidian設定は自動変更しない
• 作業管理ノートの作成・更新も、対象と目的を示したうえで行う

クラスタリング方針

• クラスタはジャンルやフォルダの分類ではなく、相互に比較・接続・統廃合を検討する価値があるノート群とする
• 表面的なテーマが同じでも関係が弱いノートを無理にまとめず、テーマが異なっても主張、根拠、前提、派生、抽象／具体、対立などの関係が強ければ接続する
• クラスタは排他的分類とせず、一つのノートが主クラスタ、副クラスタ、横断リンクを持ってよい
• 既存のクラスタ番号は識別子として維持し、新しい候補のために振り直さない。境界や順序の変更は、理由と影響を示して確認する
• 親クラスタは人間が判断できる子クラスタへ分け、次に検討する対象を一論点または数枚まで絞る
• research-zk-cluster-file-inventory.mdを全現役ノートの主クラスタ仮配置の正本とする
• 台帳の「仮」は、ファイル名・title・既存ロードマップを主な根拠とする。内容監査後に更新する
• 判断不能なノートを台帳から除外しない。Cluster 15へ残し、後続監査で再配分する
• クラスタ開始時は台帳を入口に、対象ノート本文とリンクを必要な範囲だけ深く読む

リファクタリング監査方針

リファクタリングは、単なる文章校正やファイル整理ではない。各ノートの意味を保護しながら、内容、関係、役割を見直し、知識空間の使いやすさと接続可能性を高める作業とする。

3つの監査軸

監査軸	確認する内容
内容	何を主張・記録しているか、単独で意味が通るか、粒度は適切か、複数の主張が混在していないか、根拠と現在の妥当性があるか
関係	重複、補完、前提／派生、抽象／具体、原則／事例、原因／結果、矛盾・対立、新規リンク候補があるか
役割	現在のtypeと保存場所の役割が内容に合うか、Research、Fleeting、Literature、Permanent、Structure、Indexのどの役割が適切か

保存フォルダとtypeは別軸であり、役割監査の結果だけを根拠にファイルを自動移動しない。

既存Permanentの再監査

既存Permanentを、正しいPermanentとして無条件に維持しない。少なくとも次を確認する。

• 独立した一つの主張として成立しているか
• 単なる資料要約やAI回答の保存になっていないか
• 主張を支える根拠や本人の思考があるか
• 内容が大きすぎたり、複数の主張が混在したりしていないか
• 他カードと実質的に重複していないか
• Literature、Fleeting、Structure、Indexなど別の役割が適切ではないか
• 時限情報や以前の前提によって、現在は妥当でなくなっていないか

監査結果は、必要に応じて次の候補として示す。

判定候補	意味
Keep	現在の内容・役割を維持する
Revise	主張、構成、根拠、表現、リンクを改訂する
Merge	同じ役割・実質的に同じ主張を一つへ統合する
Split	独立した複数の主張や役割へ分割する
Demote	Permanent以外のtypeまたは資料的役割へ見直す
Obsolete候補	前提の失効、別ノートによる置換などにより、現役ノートとして残す意義を再検討する

判定ラベルだけを示さず、本文上の根拠と、維持・変更した場合の影響を説明する。Obsolete候補は削除決定を意味しない。

Researchからのカード抽出

Researchを丸ごとPermanentへ変更することを前提にしない。Research内から、独立した主張として成立し、既存知識と接続する価値がある部分を探す。一つのResearchから複数のカード候補が生まれてもよい。

次の可能性を比較する。

• 独立した新規Permanent候補として抽出する
• 既存カードの根拠、補足、反例として接続または追記する
• 既存カードと重複するため、新規カードを作らない
• 一次資料やAI生成回答に近いため、ResearchまたはLiteratureとして保持する
• 情報量、独立性、本人の思考が不足しており、Permanent化しない

AI生成内容をFukkamaru自身の考えとして扱わず、最終的な思考・主張の主体を確認する。

重複と関連の区別

似ていることだけを理由に統合しない。

• 同じ役割で同じ主張を言い換えている場合は、重複の可能性を検討する
• 一方が原則でもう一方が具体例の場合は、接続して両方を維持する可能性を検討する
• 一方が原因でもう一方が結果の場合は、関係を明示して維持する可能性を検討する
• 一方が前提でもう一方が派生の場合は、読む順序と接続を示す
• 反対意見や緊張関係がある場合は、両方を残して比較可能にする価値を検討する

統合を提案するときは、なぜ関連カードとして分けて残すより統合が適切なのかまで説明する。

新しい関係とリンク

既存リンクだけに依存せず、本文を比較して次の関係を積極的に提案する。

• 現在はリンクされていないが、接続価値が高い
• 一方の後にもう一方を読むことで理解が進む
• 共通する上位概念、前提、根拠がある
• 対立・反例として並べる価値がある
• Researchが既存カードの根拠または更新材料になる

リンクを追加する場合は、単に「関連」とせず、リンク先を読む意味が本文上で分かる接続を優先する。

MOC / Structure / Index

個別カードの整理が進んだ後で、既存のMOC / Structure / Indexを確認する。

• 現在の知識構造を正しく表しているか
• Structureが単なるリンク集になっていないか
• IndexとStructureの役割が混同されていないか
• 古い分類や既に失効した関係を引きずっていないか
• 重複する入口ノートがないか
• 新しいStructureやIndexが必要か
• 既存ノートの統廃合や再構成が必要か

カード整理前に入口ノートだけを先に作り直さない。

Workスレッドと子クラスタ

親クラスタごとに必ず一つのWorkスレッドで完結させる必要はない。親クラスタの開始時に、まず内部を人間が判断できる子クラスタへ細分化する。そのうえで、子クラスタ間の関係性と想定作業量を確認し、どこまでを一つのWorkスレッドで処理するかを「予定スレッド境界」として決定し、親クラスタの作業台へ記録する。

予定スレッド境界は固定トークン数やノート数ではなく、次を基準に判断する。

• 子クラスタ間で共有される文脈の量
• 子クラスタ間の依存関係
• 統廃合、再構成、Permanent妥当性監査などの判断量
• 想定される作業の複雑さ
• 前の子クラスタで形成された判断や文脈が、後続でも有効か
• 会話履歴を維持する価値があるか

原則は次のとおりとする。

1 Workスレッド = 前の子クラスタで形成された文脈を、後続の子クラスタでも有効に活用できる範囲

親クラスタ開始時の境界は予定であり、実作業中の作業量や複雑さに応じて変更してよい。会話履歴を維持する利点よりコンテキスト負荷が大きくなった場合は、親クラスタの途中でも新しいWorkスレッドへ移行する。変更した場合は、理由、完了済み範囲、新しい予定境界を作業台へ反映する。

Workスレッドとログの分離

Workスレッドの分割境界とログファイルの分割境界は一致させない。

対象	基本単位・役割
Workスレッド	複数の子クラスタをまとめた一時的な作業コンテキスト
子クラスタ	実際の処理単位
ログへの1回の書き込み	子クラスタ単位
ログファイル	親クラスタ全体の作業履歴
外部のポリシー・進捗・クラスタ一覧	Workスレッドをまたいで維持する永続状態

基本の流れは次のとおりとする。

1. 子クラスタを処理し、検証まで完了する
2. 親クラスタ用ログへ1回追記する
3. 作業台とロードマップの進捗を必要な範囲で更新する
4. 次の子クラスタへ進む

同じ親クラスタの処理中であれば、Workスレッドを切り替えた後も同じ親クラスタ用ログへ追記する。スレッド切替だけを理由にログを閉じたり、新しいログを作ったりしない。

親クラスタの処理完了時に、その親クラスタ用ログも原則として完了扱いにする。親クラスタが非常に大きく、ログが過度に肥大化した場合だけ、物理分割の理由と各ファイルの対応範囲を記録したうえで例外的に分割する。

チャット履歴そのものを永続的な状態管理手段として扱わない。必要な判断、進捗、予定スレッド境界、作業結果は、作業方針、ロードマップ、クラスタ作業台、親クラスタ用ログへ残す。

クラスタ完了時の確認

子クラスタを完了とする前に、次を確認する。

• 対象ノートの内容、関係、役割を必要な範囲で監査した
• 承認済みの変更だけを実施した
• 本文、YAML、リンク、退避、公開状態、時限情報を検証した
• 実施しなかった提案、保留、他クラスタへ引き継ぐ事項を区別した
• 親クラスタ用ログへ結果を記録し、作業台の状態を更新した

親クラスタ完了時は、次をまとめる。

項目	記録する内容
完了した変更	統合、分割、改訂、新規カード、新規リンク、種別変更、MOC / Structure / Index変更
得られた知識	新しく発見した関係、重要な論点、Fukkamaruの考えとして明確になったこと
判断基準	今回の作業から一般化でき、今後の整理に再利用できる基準
未解決	保留事項、他クラスタで再検討する事項、追加確認が必要な事実
次の推奨	次に処理するクラスタまたは小さな作業単位と、その理由

変更項目がない場合でも、監査結果、維持判断、得られた関係、未解決事項を記録する。

ChatGPT上の対象一覧

ChatGPTで作業対象、変更候補、作業結果を一覧表として提示する場合は、既存Markdownノートごとにファイル列を設け、ChatGPT上で開けるローカルファイルリンクを付ける。

• 表の基本列はID、ノート、ファイル、役割または変更案、主な課題または影響とする。必要に応じて対象数、状態、判断理由を追加する
• IDは、対象一覧ごとに1、2、3…と連番を付け、ノート名の前に表示する。ユーザーは数字だけで対象を指定できる
• IDはその対象一覧内でのみ使う。後続の会話で数字だけの指示を受けたAIは、対象ノート名を復唱してから判断・操作する。別の対象一覧を提示する場合は1から振り直す
• ファイル列は、既存ノートならファイルを開くMarkdownリンクにする
• ローカルファイルへの絶対パスリンクはChatGPT上の表示専用とし、Vault内のMarkdown本文や管理ノートへ書き込まない
• ファイルが未作成、閲覧権限がない、またはリンク先を特定できない場合は、リンクを作らず理由を明記する
• 単なるクラスタ番号、操作手順、抽象的な論点だけを並べる表では、ファイル列は不要とする

ファイル名・リネーム方針

• 新規ノートのみ英小文字kebab-caseのユニークなファイル名を使う
• 既存ファイルのリネームは明示承認時のみ行う
• titleとファイル名は別操作として扱う
• titleと完全一致するaliasを維持する

一時作業領域

• ロードマップ、クラスタ作業台、仮クラスタ台帳、親クラスタ用ログを03_systems/research-zk-refactoring/work/へ置く
• 公開ノートをクラスタ可視化だけのために移動しない
• 全体完了後、この管理領域の整理・削除はFukkamaruへ確認してから行う

時限情報の扱い

料金、会期、公開期間、サービス仕様、制度、運行、在庫、契約条件は時限情報として扱う。事実を更新・追記する直前に公式資料で確認し、推測と確認済み事実を区別する。

type / tags等のデータ品質

• 正式typeはfleeting、literature、permanent、structure、index
• field、readingは人間が付与するタグであり、AIは推測で変更しない
• ai-generatedは最終的な思考・主張の主体で判断する
• type空欄、現行仕様外type、title一致alias欠落、現行ルール外タグ、無題ファイルは、各クラスタの内容監査時に扱う

退避・バックアップ方針

統合、分割、削除、大規模改訂の前に、変更前全文を同じフォルダの日時付き.退避ファイルへ復元可能な形で保存する。SHA-256などのハッシュ計算・記録は行わない。退避ファイルの存在と内容を確認して、復元可能性を検証する。

作業記録の使い分け

• 本ノート：この業務全体に継続適用する目的、役割、判断基準、作業手順、承認済みの恒久方針
• ロードマップ：クラスタ番号、順序、全体の状態、横断関係、次に処理する範囲
• クラスタ作業台：親クラスタ内部の子クラスタ、予定スレッド境界、判断、進捗
• 親クラスタ用ログ：子クラスタごとの完了結果。Workスレッドをまたいでも同じ親クラスタでは同じファイルへ追記する
• 仮クラスタ台帳：全現役ノートの主クラスタ仮配置
• AI Handoff：中断時の現在位置への案内
• AI Work Log：親クラスタ別ログへ移行する前の履歴と、本作業外の一般作業記録。本作業の子クラスタ結果を重複記録しない

現在の進捗や次の作業を本ポリシーへ重複記録しない。個別クラスタの状態が変わっても、それだけを理由に本ポリシーを更新しない。

ログ方式の移行に関する確定事項

• Cluster 03は2026年9月8日に完了した。過去の作業結果は作業台と既存のAI Work Log.mdに残し、親クラスタ用ログを遡及作成しない
• 親クラスタ別ログ方式はCluster 05から適用し、Cluster 05用ログを最初の親クラスタ別ログとする
• Cluster 05以降は、親クラスタ開始時に作業台で子クラスタ分割と予定スレッド境界を決める
• Gitの既存差分は、本作業の判断・対象抽出・検証から除外する

未解決事項

• 全件台帳の分類は仮配置であり、各クラスタ開始時の内容監査で修正する

決定履歴

日付	決定	理由	以前の方針との関係
2026-09-13	本文の統合再構成では、発話者・出典・対立する見解を明示し、引用・コードブロック・表・Mermaidを文脈保持のために使い分ける	Fukkamaru自身の意図と、AI・第三者の発言や相反する意見を混ぜると、ノートの判断根拠と再利用価値が失われるため	2026-09-11の文章校正基準を、チャットコピー・複数視点を含むノートへ適用できる具体的な表現・検証基準として拡張
2026-09-11	本文の校正・整理は、元のメモ、意図、判断基準、文脈を保持した統合再構成として行う	見出し追加や短い要約だけでは、検討の経緯と結論の根拠が失われるため	Phase 6の内容保持要件を、文章校正の具体的な完了基準として明文化
2026-09-11	確認・承認への応答だけで作業を停止せず、次に許可不要で行える監査・検証・記録・提案へ継続する	「完了とします」という応答が、承認済みの長期作業を不必要に中断させるため	子クラスタ完了後に次の子クラスタへ進む基本フローを明文化し、停止できる条件を限定
2026-09-10	ChatGPT上の対象一覧で、ノート名の前に1、2、3…の簡単な指示IDを表示する	ユーザーがノート名を入力しなくても、数字だけで対象を指定できるようにするため	ファイルリンクを付ける一覧ルールを維持したまま、指示のしやすさを追加
2026-09-08	本ノートを新規作成し、既存コンテキスト・ロードマップ・作業台から作業方針を外部化した	スレッド変更時に会話履歴へ依存せず再開するため	方針の正本が未作成だった状態を補完
2026-09-08	全現役Research／ZKノートの仮クラスタ台帳を別ノートで管理する	クラスタ番号と所属ファイルのずれを防ぐため	ロードマップの概要表を補完
2026-09-08	Handoff、ロードマップ、Cluster 03作業台YAML、Work Logの整合更新はCluster 03完了まで保留する	方針・台帳の作成が例外的に先行しており、途中状態の記録を不要に更新しないため	途中で即時同期する案を採用しない
2026-09-08	Gitの既存差分を本作業の対象から除外する	既存差分を今回の判断や操作の根拠に混ぜないため	無関係な差分の確認・復元を行わない
2026-09-08	今後の退避ではSHA-256などのハッシュ計算・記録を行わない	Fukkamaruの判断により、日時付き退避と内容確認で復元可能性を担保するため	ハッシュ確認を必要に応じて行う方針を変更
2026-09-09	Workスレッド、子クラスタ、ログエントリ、ログファイルを別の単位として管理する	会話履歴へ永続状態を依存させず、文脈の再利用価値と記録単位をそれぞれ最適化するため	親クラスタを一つのスレッドと単一Work Logで扱う運用から変更
2026-09-09	親クラスタ開始時に子クラスタ分割と予定スレッド境界を決め、子クラスタ完了時に親クラスタ用ログへ1回記録する	スレッド切替とログ分割を切り離し、判断・進捗を外部ファイルから復元可能にするため	Cluster 05から適用し、Cluster 01〜03のログは遡及分割しない
2026-09-09	ChatGPT上の対象一覧には、既存Markdownノートを開けるファイル列を付ける	対象の視認性と、一覧から直接ノートを確認する操作性を高めるため	Vault本文のリンク規則を変えず、ChatGPT上の表示ルールとして追加
2026-09-09	元の作業依頼に含まれていた目的、AIとFukkamaruの役割、リファクタリング監査、学習支援、完了条件を本ポリシーへ復元した	クラスタリングの運用だけが残り、タスクの目的と実際のリファクタリング方針が別スレッドで欠落することを防ぐため	既存のクラスタ、スレッド、ログ、ファイル操作方針は維持して補完
2026-09-09	本ポリシーを恒久方針、ロードマップ・作業台・ログを現在状態の正本として分離し、別スレッドの再開手順を定めた	進捗更新によるポリシーの肥大化と、会話履歴に依存した方針の揺れを防ぐため	現在状態と恒久方針が同じノートに混在していた状態を整理