FAQ（よくある質問） — 相談前に、前提と言葉を静かにそろえるためのページです。

カテゴリ一覧

よくある質問を 6 カテゴリに分けています。立場（経営／現場／研究／情シス等）やフェーズに近いものからご覧ください。

1. はじめての方・全体像

「何をしてくれるスタジオなのか」「自分たちの状況にフィットするか」を素早く確認したい方向けです。

Fragment Practice は、どんな課題のときに依頼しやすいですか？

一言でいうと、 「人 × AI × ノート・会議・ログ」の間で起きている “運用の詰まり” を、プロトコル（背骨）として設計し直したいときにフィットします。 よくある状況： ・生成AIは使われ始めたが、チームとしての判断ライン（どこまで任せ／どこから人が読む・決めるか）が曖昧 ・会議が増え、メモ・チャット・ドキュメント・チケットが分断して「なぜそう決めたか」が追いにくい ・ポリシー/ガバナンスはあるのに、現場の会議・ノート運用に接続されておらず形骸化している ・PoCや試行錯誤が積み上がる一方で、設定や前提（config）と観察ログが残らず再現できない Fragment Practice は、単発の“AI活用テク”よりも、 ・ルール（Protocol） ・記録の構造（Notes / Logs） ・続けやすいリズム（Health & Rhythm） を一体で扱い、静かに回り続ける Quiet System として整えることを目的にしています。

相談内容はどの程度まで整理されている必要がありますか？

きれいに整理されている必要はありません。 むしろ「複数の論点が絡み合って説明しづらい」「何が問題かは感じるが名前がついていない」段階から始まることが多いです。 初回では、いま手元にある断片（Fragment）を一緒に並べます： ・会議メモ / 1on1 メモ ・チャットのやり取り（Slack / Teams 等） ・社内ドキュメント / ガイドライン ・検証ログ / 実験ノート その上で、 ・今回扱う範囲（Scope） ・今回は扱わない範囲（次フェーズに回す） ・判断ライン（AIに任せる／人が必ず読む） を静かに言語化していきます。RFPのような完成された要件は不要です。

どのような依頼とは相性がよくありませんか？

次のような主目的だと、相性がよくない可能性があります。 ・常時対応（24/365）の運用要員としてのリソース提供が主目的 ・すでに主幹ベンダーが決まり、実装工数だけを外部から追加することが主目的 ・短期KPI最大化のみを優先し、記録/判断/運用の背骨を残す設計に価値を置かない ただし、「現実的な分担の整理」や「やる/やらないの線引き」を1回で整えるアドバイザリーとしては、お役に立てることもあります。

相談すると、最初に何が手元に残りますか？

初回〜序盤では、いきなり“分厚い資料”を作るよりも、判断と運用の核になるテキストが先に残ります。 例： ・今回の前提（Premises）と、扱う/扱わない範囲のメモ ・判断ライン（AIに任せる範囲／人が読む・決める範囲）のたたき台 ・会議/ノート/ログの「どこが詰まっているか」の簡易マップ この“薄い背骨”があるだけで、チーム内の会話や設計の速度が変わるケースが多いです。

2. 進め方・成果物

どう進み、何が残り、どう継続運用につながるのかを確認したい方向けです。

初回相談から完了までの標準的な流れは？

個人・チーム・研究のいずれでも、基本は 5 ステップです。 1. Premises（前提と境界） 業務/組織/ツール/セキュリティ要件/リズム等を共有し、今回の範囲と除外範囲を決めます。 2. Fragment Mapping（断片の棚卸し） メモ・チャット・ドキュメント・ログを並べ、認知負荷/断絶/判断遅延が起きる地点をマッピング。 3. Protocol Draft（プロトコル案） テンプレート、チェックリスト、簡易フロー、必要に応じて設定（YAML等）として “背骨” を起こします。 4. Trial & Edit（試行と編集） 実務で回してもらい、ログ/フィードバックから「続く形」に寄せて調整します。 5. Wrap-up（更新可能な背骨として残す） 最終版のプロトコル/テンプレ/補足メモを整理し、必要なら社内共有用の短いレポートにします。

終了時点で、どんな成果物が残りますか？

案件の目的に応じて組み合わせますが、共通して「読み返せる/更新できる」テキストと構造を残します。 代表例： ・判断ラインとルール（Protocol）：OK/NG、例外、レビュー責任、ログの残し方 ・ノート/ログ/会議テンプレ：会議、1on1、意思決定メモ、検証ログ、ふりかえり等 ・フローの最小図：会議→議事録→決定→チケット化などの“つなぎ目” ・プロンプト（必要な場合）：場面別に、プロトコルとして再利用できる形で ・ショートレポート（必要な場合）：Before/After、採用した方針、残課題、次の一手 PowerPoint“だけ”を納品するというより、日々の運用に刺さる artefact を残す設計です。

期間の目安はどのくらいですか？

テーマと関係者の幅によりますが、目安は次のとおりです。 ・単発相談（整理/方向決め）：1回（60〜90分） ・個人/小チームの設計＋試行：2〜6週間 ・部門横断のパイロット：1〜3ヶ月 ・伴走/アドバイザリー：3ヶ月〜（月次で更新） ポイントは「大きく変える」よりも、まず小さな背骨を入れて、運用ログで育てることです。

ミーティング頻度やコミュニケーションはどう設計しますか？

オンライン中心・ミーティング少なめを基本に、非同期のログ往復を軸にします。 目安： ・個人：初回60〜90分＋フォロー（テキスト/短時間） ・小規模チーム：隔週 or 週1で2〜4回＋非同期 ・研究/共創：隔週〜月1＋検証ログの共有 評価軸は「会議回数」より、 ・前提と意思決定がログとして残るか ・チームのリズムを乱さずにプロトコルを差し込めるか です。

3. 料金・契約・NDA

稟議や予算、法務・コンプライアンスの観点から、事前に把握しておきたい方向けです。

料金はどう見積もりますか？ 目安レンジは？

時間単価ベースではなく、主に次で設計します。 ・構造の複雑さ（どのレイヤーまで扱うか） ・関係者の幅（誰を巻き込むか） ・再利用可能性（背骨として残る度合い） 目安レンジ（プロジェクト内容で調整）： ・ライト相談（1回完結）：4〜9万円前後 ・個人/デュオの構造設計（数回＋テキスト整備）：5〜15万円前後 ・小〜中規模チーム（プロトコル＋テンプレ整備）：25〜70万円前後 ・部門/横断（パイロット/設計＋運用接続）：60〜220万円前後 ・継続アドバイザリー：月額35〜70万円前後 ※最適な形は、初回ヒアリングで「背骨として残す範囲」を一緒に決めたうえで提案します。

契約形態と支払い条件は？

法人・個人事業主いずれも対応しています。 ・契約：業務委託（準委任）を基本に、必要に応じて貴社書式に合わせます ・支払い：合意したマイルストン単位、または完了後に請求書（銀行振込） 社内稟議用に、目的/想定成果物/リスク/レンジを 1〜2ページで整理するメモが必要なら一緒に作成できます。

NDA や機密情報の取り扱いは？

NDA には標準的に対応します。 また、AIを使う前提の設計ではなく「AIに渡さない情報がある」前提で進めます。 ・着手前に、扱う情報の範囲/共有チャネル/アクセス権を定義 ・AIに送って良い/送らないカテゴリを、現場運用のルールに落とし込み ・ログの保存/削除/マスキング/保管場所をすり合わせ 公開可能な知見をケースノート等にする場合も、必ず事前合意とレビューを前提にします。

4. AI・ツール・セキュリティ

どのモデル/ツールを前提にできるか、既存環境との整合、境界線の設計について確認したい方向けです。

対応しているAIサービスやツールの例は？

特定ベンダー固定ではなく、既存環境の上に“プロトコルとテンプレ”を重ねる設計が基本です。 例： ・モデル/サービス：ChatGPT / OpenAI、Gemini、Claude など ・基盤/ツール：Notion、Obsidian、Google Workspace、Microsoft 365、Slack/Teams、Linear/Jira 等 「どれを採用するか」だけでなく、 ・どの場面で使うか ・どの情報は扱わないか ・どこで人が必ずレビューするか を運用の文章として定義します。

組織として生成AIの利用経験が少なくても依頼できますか？

はい。むしろ初期は「線引き」と「最初の運用単位」を決めるほど効果が出やすいです。 初期は、 ・使う/使わない領域（機微/個人情報/営業機密など） ・最初に試すユースケース（効果が見えやすい/リスクが低い） ・ログの残し方（残す/残さないの境界） をシンプルなプロトコルとして整えます。

すでにAI活用が進んでいるチームにとっての価値は？

活用が進むほど、ローカル最適の積み重ねによる“運用負債”が見えやすくなります。 例： ・プロンプト/テンプレが乱立し、共有/再利用の単位が崩れる ・本番運用の責任分界、レビュー手順、例外処理が整理されていない ・管理部門（セキュリティ/監査）と現場の認識がズレる この状態を、 ・どこを標準化し ・どこを裁量として残すか を含めて “背骨” に束ね直すのが価値になります。

セキュリティ/BCP観点で、どう設計しますか？

セキュリティ/IT-BCP の文脈では、便利さより先に「境界線」を設計します。 ・AIに送らない情報カテゴリ（個人情報/機微/営業機密等）の整理 ・ログの保存場所/保存期間/アクセス権/削除トリガー ・既存のISMS、委託先管理、BCP、監査の枠組みとの整合 “禁止リスト”だけで終わらず、現場の会議・ノート・チケット運用に接続した形に落とします。

5. 個人・チーム・国際チーム

どの単位から始めるのが現実的か、規模感や言語対応について確認したい方向けです。

個人向けとチーム向けの違いは？ どちらから始めることが多い？

大枠では、 ・個人：仕事と生活の境界、判断の型、ノート/ログ、AIとの役割分担、週間リズム ・チーム：会議体、合意形成、ドキュメント/チケット連携、責任分界、オンボーディング という違いです。 組織案件でも、まずキーパーソン1〜2名の“個人の背骨”から始め、検証してからチームに静かに拡張するケースが多いです。

想定している規模感は？

現在よく扱うレンジは次のとおりです。 ・1〜3名：経営者/フリーランス/研究者の個人プロトコル設計 ・3〜15名：プロダクト/事業/研究ユニットなどのフロー設計 ・〜数百名：大規模組織の特定部門（DX、情シス、セキュリティ等）のパイロット “全社変革”を一気にやるより、範囲を切って背骨を作り、波及させる設計が得意です。

英語ベース/海外拠点を含むチームにも対応できますか？

はい、日本語/英語が混在するプロジェクトにも対応可能です。 ・日本語での意思決定を、英語のプロトコル/ノートに整理 ・英語話者と共同で、検証ログやケースノートを残す 時差や契約条件により難しいケースもあるため、まずは概要ベースでご相談ください。

6. Research & Writing / Fragment との関係

研究・共同執筆・ZINE、そして Fragment（ツール/概念）との関わり方を確認したい方向けです。

Research & Writing は、通常の支援とどう接続されていますか？

多くのプロジェクトでは、まず実務のQuiet System設計として始まり、そこで繰り返し現れるパターンを Research & Writing に昇華させます。 ・現場の判断軸/トレードオフを、ケースノートとして文章化 ・前提/設定/観察ログを、再検証できる形で残す ・公開可能な部分のみを切り出し、ZINEや発表資料に再構成 実務と研究の往復で、プロトコルが“育つ”ことを大事にしています。

事例が社外公開されることはありますか？

公開の有無/範囲はプロジェクトごとに合意して決めます。 ・公開を検討する場合は、必ずドラフト共有とレビューを実施 ・組織名/個人名の扱い（完全匿名〜一部開示）も事前合意 ・公開しない場合は、完全非公開の内部ドキュメントとしてのみ保持 「社外には出さないが社内共有したい」という場合も、社内限定のケースノートとして設計できます。

Fragment（fragment.place）の導入は必須ですか？

必須ではありません。 多くは、既存の Notion / Google Docs / Microsoft 365 / Confluence / Obsidian 等の上に、 「Fragment的な構造（1ページ=1断片）」「メタデータ」「ログの粒度」などの考え方だけを持ち込みます。 ツール導入よりも、いまの器の上で“運用として回る背骨”を作ることを優先します。