読むと得られるもの
判断軸（Decision Lines）
「どこで人が読む/決めるか」「どこからAIに委ねるか」の線引きと、その根拠。
テンプレと構造（Notes / Logs）
会議→議事録→決定→タスクが崩れない最小テンプレ／ログ設計の考え方。
境界線（Security / Governance）
禁止リストで止めず、例外運用・レビュー・証跡として回すための設計視点。
Research & Writing
Research & Writing — 実務を支える、背骨としてのノート。
Fragment Practice は、「人 × AI × 会議・ノート・ログ」の間で起きる 判断のブレ／説明責任／記録の分断を、Quiet System として整えるスタジオです。
ここでは、その設計と観察をフレームワーク・ケースノート・文章として残します。
Services が「現場で回る運用」を作る場だとすると、Research & Writing は その裏側にある 判断軸・境界線・テンプレの原型 を整理して共有するアーカイブです。 （機密は取り除き、再利用できる粒度に整えます）
迷う場合は、まず「主なライン」→「背骨となるレイヤー」だけ読めば全体像が掴めます。
What you’ll find — このページにあるもの
想定している読者
- 事業会社の企画・DX・情シス・セキュリティで、AIの利用と説明責任に悩んでいる方。
- 研究者／実務家として、人とAIの協働を「運用の背骨」で捉えたい方。
- 個人・小チームで、ノート/ログ/リズムまで含めて仕事の型を作りたい方。
Services と Research & Writing — 実務と設計メモの往復
現場で起きた論点を「その場の解決」で終わらせず、抽象化して背骨として残し、 次の案件・次の判断に再利用できる形にします。これが Fragment Practice の基本ループです。
Services（現場）で起きること
- 断片（メモ/チャット/議事録/AIログ）を並べ、詰まり地点と判断遅延を特定する。
- 判断ライン・テンプレ・レビュー観点を、運用として“回る形”に落とす。
- セキュリティ/監査/委託先制約と、現場の速度を同じテーブルで整合させる。
Research & Writing（背骨）で残すこと
- 繰り返し現れるパターンを、フレーム/チェックリスト/ケースノートにする。
- Prism / QFS / Health & Rhythm / Streams を、文章と設定（YAML等）で更新する。
- ZINE・トーク・Applied write-up として共有し、共通言語として育てる。
主なライン — どんな種類のノートがあるか
深く読みたい方向けに、方向性を 4 つに絞って整理しています。 「自分の関心はどれか」を決めるための地図として使ってください。
Individual — 個人の仕事とAI
経営者・フリーランス・リード職など、個人単位で「分担」と「判断」を設計するためのノート。
- 判断ライン（任せる/読む/決める）を、日々のログとセットで定義する。
- Health & Rhythm（負荷の波）と、AIの使い方を接続する。
Team / Org — チームと説明責任
会議→決定→タスクの導線、ガイドラインの運用化、オンボーディングなど “背骨” を作るケースノート。
- 会議メモ/AI要約/決定ログ/チケットが分断しない最小構造。
- 例外運用・レビュー・証跡が「現場で回る」形になる設計。
Frameworks — Prism / QFS など
概念レイヤーと設定（YAML等）を、実務で使える粒度に落とした設計メモ。
- 役割/トーン/禁止事項/境界条件を「設定」として扱う。
- 言語・認知のレイヤー（QFS）を、タグやレビュー観点に還元する。
Outputs — ZINE / Talk / Applied write-up
実験や実務の知見を、共有可能なアウトプットに変換するライン（温度と前提を残す）。
- 公開範囲・匿名性・レビュー前提で、知見を安全に共有する。
- 「論文と実務レポートの中間」の粒度で、再利用可能性を上げる。
Thematic spine — 背骨となるレイヤー
ここでいう “理論” は、難しい説明のためではなく、「どの情報をどの層で扱うか」「どこで線を引くか」を決めるための設計ラベルです。
Fragment System & Prism Protocol
メモ・会議・チャット・AIログを Fragment（断片）として扱い、 Prism で「誰に／どの役割で／どのトーンで／どこまで見せるか」を定義します。 倫理や価値観も Ethics Configuration として “設定” に落とし、 セキュリティ／ガバナンスと自然に接続させます。
Quantum Fragment Syntax（QFS）
まだ言語化されていない判断や感覚が、どのように Fragment になり、 “いつもの言い回し” や “チームの前提” に育つかを扱う層です。 実務では タグ設計／テンプレ／レビュー観点に影響します。
Health & Rhythm Layer
コンディションや生活事情など、扱いに配慮が必要な Fragment をどう守るか。 どこまで残すか／AIログに残さないか／レビュー頻度をどう設計するか。 ここは 情報設計と働き方が繋がる層です。
Streams（外側のレイヤー）
ノートの外に出ていく Fragment（ストリーム／公開範囲／来歴）を扱う層です。 AT Protocol のような基盤は、外側のレイヤーとして位置づけ、アクセス制御・文脈・証跡の観点をそのまま持ち込みます。
進め方 — 小さく試して、静かに書き残す
大規模調査より先に、運用に差し込める小さな背骨を作り、観察し、文章として更新します。
Frame（前提と境界）
テーマと範囲（扱う/扱わない）を定義し、NDA・公開範囲・ログの扱いを先に決めます。
Sketch（試作と観察）
テキスト中心のアーティファクト（テンプレ/チェックリスト/設定）を埋め込み、 現場の負荷を増やさずに回るかを観察します。
Write（共有可能な形へ）
ZINE・ノート・トーク・Applied write-up にまとめ、フレームに還元して更新します。
Outputs — どのような形で残るか
共通して重視するのは、後から読み直せて、更新できるテキストであることです。
Framework / Case notes
- 判断ライン、例外運用、レビュー観点を “運用に刺さる” 粒度で残す。
- テンプレ・チェックリスト・設定（YAML等）として再利用できる形にする。
ZINE / Talks / Applied write-ups
- 温度感と前提（制約）を含め、共有できる文章に再構成する。
- 公開範囲・匿名性・レビューを前提に、安全に知見を外へ出す。
次に何を見ればよいか
実務の入口は Services に、前提条件は FAQ / Legal に整理しています。 Research & Writing は、その背後にある判断軸と設計のログです。