断片化した情報・判断・ログを束ねる。
- メモ・チャット・タスク・議事録・AI ログが、ツールと形式の壁で分断されている。
- 会議が増える一方で、「誰がどこで決めたか」が後から追いにくい。
- 個人の工夫が、チームの標準として残らない。
Fragment Practice — Human–AI Work Protocols Studio— 高松・瀬戸内から、人と AI のあいだの仕事を静かに設計します
人と AI のあいだに、静かなプロトコルを。
Fragment Practice は、AI・業務・セキュリティのあいだに生じる「判断のにじみ」「運用の曖昧さ」「記録の分断」を、ノート・会議・ログ・ルールの単位で整えるスタジオです。
「AI をどう賢く使うか」ではなく、「どこまでを AI に任せ、どこからを人が判断するか」。その境界を、実務として回る形で設計します。
要件定義や社内稟議用の資料が整っていなくても問題ありません。 「ここが重い」「この判断が毎回つらい」——そのレベルのメモからで十分です。 状況を聞いた上で、話すべきか／進めるべきかも含めて一緒に整理します。
プロンプトではなく、「仕事が回るプロトコル」を設計します。
Fragment Practice が扱うのは、AI そのものではなく「AI が入った後の仕事の構造」です。会議・ノート・ログ・ルールがつながることで、判断が安定し、引き継ぎと説明がしやすくなります。
ポリシー・BCP と、現場の「日常」をつなぐ。
- AI 利用ルールが、現場の会議・ノート・チケットと接続されていない。
- セキュリティ／監査の視点と、事業運用の視点にギャップがある。
- 一度作ったルールが、変化に追従できる構造になっていない。
これらを「人 × AI × プロセス」の設計課題として扱い、静かで再現可能な運用（Quiet System）として整えることを目的にしています。
こんな立場の方から、よく相談されています。
規模や役割よりも、「人と AI が一緒に仕事をしている具体的な場面があるか」を重視しています。まずは当てはまるかどうか、ざっと見てください。
経営者・フリーランス・プロジェクト責任者
- AI を使っているが、判断の線引きが毎回揺れる。
- ノート／タスク／チャットが散らばり、全体が見えない。
PM / EM / 事業部門マネージャー（チーム運用）
- 会議体が増え、決定や論点が追いづらい。
- AI 利用が属人化し、標準フロー・テンプレを作りたい。
情報システム・セキュリティ・BCP / 監査
- 現場の実態と、ルール・監査視点のギャップが気になる。
- 「渡して良い情報／渡さない情報」を現場と一緒に具体化したい。
研究者・ラボ・DX 室・R&D
- 実務に接続したログ設計を、研究テーマとして扱いたい。
- PoC の知見を、再利用可能な形式（YAML/ノート/レポート）に残したい。
迷う場合は、まずは 「困っている場面（会議／ノート／判断／リスク）」を箇条書きで送ってください。こちらから最短の進め方をご提案します。
具体的には、こんなテーマを一緒に扱います。
「AI をどう使うか」だけでなく、仕事の記録・会話・判断が 継続できる形になっているかを重視します。単発の整理から、数週間〜数ヶ月の設計・伴走まで対応します。
個人（仕事と生活）
- 案件管理・見積・レポートなど、業務フローの役割分担を整理したい。
- 散らばる情報を「仕事ログ」として見える化したい。
- 無理をしないが積み上がる、週間・月間のリズムを作りたい。
チーム・部門・プロジェクト
- AI 利用ルールを、会議・ノート・チケットと接続して運用したい。
- 会議→議事録→決定→チケットの流れをテンプレ化したい。
- PoC の知見を、再現可能なログと手順として残したい。
どの案件でも、一緒に設計する 3 つのレイヤー。
最終的に目指すのは「分担・ルール・情報の流れが明示されている状態」です。そのために、次の 3 レイヤーを同時に扱います。
Protocol（判断ライン）
どの場面で、どこまで AI に任せるか。どの情報は扱わないか。短い文章・チェック・図・YAMLで、更新可能な背骨を作ります。
Notes / Logs（流れ）
会議・1on1・レビュー・インシデント等の「場」と、メモ・AI ログ・チケットをつなぐ設計。 既存環境を前提に、どこに何を書くかを定義します。
Rhythm（続く形）
日々の記録・レビュー・休息のタイミングを設計し、最小限の問いで運用が続く形にします。
具体的な案件の型（Spot / Sprint / Ongoing など）は Services に整理しています。
- 1境界の確認
何を扱い、何を扱わないか。情報の境界と判断者を先に決めます。
- 2設計して試す
テンプレ・ルール・ログの流れを作り、実務の中で小さく試します。
- 3背骨として残す
更新しやすい形（文章・図・YAML）で残し、引き継ぎや説明に耐える状態にします。
業務改善の対象となる領域とツール
「新しいツールを入れること」よりも、いまある業務の流れに、判断ラインとログの背骨を通すことを優先します。ここでは、よく扱う領域と、その周辺で登場するツール群をまとめています。
AI / LLM
モデル選定より、役割分担・境界線・ログを運用に接続します。
OpenAIClaudeGemini
API 利用GuardrailsReview / QAAI LogPrompt / Spec役割分担入力データ境界失敗パターン収集RAG / Knowledge接続モデル比較検証 / PoC運用手順
Knowledge / Notes
ノート・テンプレ・メタデータで「残る背骨」を作ります。
NotionObsidianGoogle Docs
Microsoft 365Drive / SharePointMarkdownYAMLGoogle SheetsAirtable命名規約 / タグID / リンク設計週次 / 月次レビューテンプレ設計更新ルールアーカイブ方針ナレッジ導線
Collaboration
会議→議事録→決定→チケットの“つなぎ目”を整えます。
SlackTeamsZoom
Meet議事録フロー決定ログ会議体系合意形成フォローアップアジェンダチケット連携1on1論点整理共有設計会話ログ
Ops / Governance
ポリシーを現場運用に落とし、監査・説明可能性まで含めて設計します。
SecurityPolicyBCP
Audit機密区分AI 利用規程説明可能性ログ保全委託先管理権限 / アクセスSaaS リスク証跡 / 台帳例外運用インシデントBCP 手順
上記以外の社内システムや専用ツールでも、画面イメージやワークフローを共有いただければ、「現状の器を前提としたプロトコル設計」として提案します。ツール導入そのものより、運用の背骨づくりを優先します。
周辺ページとリソース
詳細は目的に合わせて分けています。トップでは「入口」まで。深掘りしたいレイヤーから覗いてください。
Services
入口（Spot / Sprint / Ongoing）と案件の型、成果物のイメージを整理しています。
Services ページへResearch & Writing
ケースノート・論考・ZINE として、仕事と AI の関係性を言語化するラインです。
Research & Writing へFragment（fragment.place）
1 ページ = 1 Fragment の発想でノートを扱うツール。導入必須ではなく、概念だけ既存環境へ持ち込む形も歓迎です。
FAQ / Legal
進め方、料金の考え方、NDA や機密情報の扱い、前提条件を整理しています。
まずは、「どの負担を軽くしたいか」から。
まだ言葉になっていなくても大丈夫です。 仕事と生活の現在地を一緒に整理し、無理なく試せる次の一手を提案します（必要なら「今回は見送り」も含めて判断します）。
※ 原則オンライン（ビデオ / 音声のみ）です。機密情報やログの取り扱いは Legal に整理しています。必要に応じて NDA 前提でも対応します。