分断した情報・判断・ログを束ねる。
- メモ・チャット・タスク・議事録・AI ログが、ツールと形式の壁で分断されている。
- 会議が増える一方で、「誰が・どこで・なぜ決めたか」が後から追いにくい。
- 個人の工夫が、チームの標準として残らない。
Fragment Practice — Human–AI Work Protocols Studio— 高松・瀬戸内から、運用の背骨を設計します
人と AI のあいだに、静かなプロトコルを。
Fragment Practice は、AI・業務・セキュリティのあいだで起きる「判断の揺れ」「運用の曖昧さ」「記録の分断」を、ノート・会議・ログ・ルールの単位で整えるスタジオです。
目指すのは「AI を賢く使う」よりも、誰がどこで判断し、何を根拠に残すかが説明できる状態。実務として回るテンプレとレビュー手順まで落とし込みます。
要件定義や稟議資料が整っていなくても問題ありません。 「ここが重い」「この判断が毎回つらい」——そのレベルのメモからで十分です。 相談内容を踏まえて、最短の入口（Spot / Sprint / Ongoing）をご提案します。
プロンプトではなく、「運用として回る背骨」を設計します。
扱うのは AI そのものではなく、AI が入った後の仕事の構造です。会議・ノート・ログ・ルールをつなげることで、判断が安定し、説明と引き継ぎがしやすくなります。
ポリシー・BCP と現場の「日常」をつなぐ。
- AI 利用ルールが、現場の会議・ノート・チケット運用に接続されていない。
- セキュリティ／監査の視点と、事業運用の視点にギャップがある。
- 一度作ったルールが、変化に追従できる構造になっていない。
これらを「人 × AI × 運用」の設計課題として扱い、静かで再現可能なプロトコルとして整えることを目的にしています。
こんな立場の方から、よく相談されています。
規模や肩書きよりも、「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）と案件の型、成果物のイメージを整理しています。
Research & Writing
ケースノート・論考・ZINE として、仕事と AI の関係性を言語化するラインです。
Fragment（fragment.place）
1 ページ = 1 Fragment の発想でノートを扱うモデル。導入必須ではなく、概念だけ既存環境へ持ち込む形も歓迎です。
FAQ / Legal
進め方、料金の考え方、NDA や機密情報の扱い、前提条件を整理しています。
迷ったら FAQ、契約や機微情報は Legal、更新通知は Updates。