FAQ（よくある質問） — 相談前に、前提と言葉を共有しておくためのページです。

カテゴリ一覧

よくある質問を 6 つのカテゴリに分けています。現在のご自身の立場（経営／現場／研究／情報システムなど）やプロジェクトのフェーズに近いものからご覧ください。

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

Fragment Practice が担う役割や、どのようなビジネス／研究の文脈でフィットしやすいかを確認したい方向けの質問です。

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

一言でいうと、「人 × AI × メモ・会議・ログ」のレイヤーで発生している構造的な課題を、業務と研究の両方の視点から整理したいときにフィットしやすいスタジオです。 たとえば、次のような状況でご相談いただくことが多くあります。 ・生成 AI は試しているが、個々人の使い方に依存しており、チームとしての方針・運用ルール・レビュー手順に落とし込めていない ・会議メモやチャットログは蓄積しているものの、意思決定の履歴や前提が追いづらく、再利用可能な「基盤ドキュメント」が育っていない ・AI ツール／SaaS が増え、認知負荷やセキュリティ・ガバナンスの観点で「どこまで許容するか」「何を禁止するか」の判断が難しくなっている ・PoC やリサーチは進んでいるが、「どの前提・設定で実験したのか」が後から再現しづらく、ナレッジが個人や特定チームに閉じがちになっている プロダクト開発、カスタマーサクセス、社内 DX、情報システム・セキュリティ、R&D・ラボなど、文脈はさまざまですが、共通しているのは「判断と文章とツールの関係を、プロトコルとして設計し直したい」というニーズです。

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

事前に完全に整理されている必要はありません。「問題の構造は見えているが言語化しきれていない」「複数の論点が絡み合っていてうまく説明できない」という状態から入ることが多いです。 初回は、既存の資料・議事録・チャットログ・社内メモ・リサーチノートなど、現場で実際に使われている断片（Fragment）を共有いただき、それらを一緒に読み解きながら： ・今回のプロジェクトで扱う範囲（スコープ） ・今は扱わない／次フェーズに回す範囲 を整理していきます。 「説明しづらい段階なのでまだ早いのではないか」と迷っている場合でも、その状態のまま出していただいて問題ありません。問いの構造を一緒に組み立てることも、仕事の一部だと考えています。

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

現時点の Fragment Practice では、次のような案件とは相性がよくない可能性があります。 ・24/365 の監視センター運用など、常時対応が求められる現場オペレーションの人員増強や、シフト運用そのものを担うことを主目的とする案件 ・既にメインベンダー／SIer が存在し、「実装ラインの一部として工数を提供する開発リソース」のみを期待されている案件 ・短期間での数値指標の最大化のみを目的とし、ルール設計やナレッジ基盤構築よりも、ツール導入や一時的なアウトプット量の拡大を最優先する案件 このようなケースでも、「どのようなパートナーや進め方が現実的か」を整理する 1 回限りのアドバイザリーとしてであれば、お役に立てる場合があります。

2. プロジェクトの進め方・アウトプット

コンサルティングやリサーチのプロジェクトがどのように設計され、どのような成果物が残るのかを確認したい方向けの質問です。

初回相談からプロジェクト完了までの標準的な流れはどうなっていますか？

個人向け・組織向け・研究プロジェクトいずれの場合も、基本的なプロセスは次の 5 ステップで構成されます。 1. Premises（前提整理） 業務内容、組織構造、ステークホルダー、利用中のツール群、セキュリティ／コンプライアンス要件、時間的制約、優先順位などを共有いただき、「今回はどこまで扱うか／どこから先は対象外とするか」を明確化します。 2. Fragment Mapping（断片の棚卸し） 会議メモ、チャットログ、既存ドキュメント、研究ノート、インシデント記録などを Fragment として整理し、どこで認知負荷・情報の断絶・判断の遅延が生じているかをマッピングします。 3. Protocol Draft（プロトコル案の作成） YAML / Prism Config、プロンプトセット、テンプレート群、フローマップなど、テキストベースの artefact として「人 × AI × ドキュメント」のプロトコル案を設計します。必要に応じて、運用責任・レビュー責任の線引きも明記します。 4. Trial & Edit（試行と編集） 一定期間（数週間〜）実際の業務・研究の中で試用いただき、ログ・メモ・フィードバックをもとに構造をアップデートします。現場で使いづらい要素は遠慮なく指摘いただき、プロトコル側を調整します。 5. Wrap-up（背骨として残す） 最終版の設定・テンプレート・ガイドライン・補足メモを整理し、必要に応じて社内共有用のショートレポートやケースノートとしてまとめます。研究案件では、次の検証や再現実験に使える形で前提をテキスト化します。

プロジェクト終了時点で、具体的にどのような成果物が残りますか？

案件の目的に応じて変動しますが、共通して「再利用可能なテキストと構造」を残すことを重視しています。代表的な成果物の例は次のとおりです。 ・AI 利用ルール、役割分担、例外条件などを記述した YAML / Prism Config / Protocol ファイル ・職種別・シーン別のプロンプトセット（企画、レビュー、リサーチ、問い合わせ対応、一次ドラフト作成など） ・会議メモ、ふりかえり、インシデントレビュー、リサーチログ等のドキュメントテンプレート一式 ・「どの場面で／どのツール／どのモデルを利用し、誰がレビューするか」を示した業務フローマップ ・ChatGPT などに渡すことを前提に設計された「組織としての自己紹介・判断基準テンプレート」 ・Before / After、採用した設計方針、今後見直すべき論点などを整理したショートレポート プレゼン資料単体ではなく、内部で継続的に更新・再利用できる artefact として残す設計を行います。

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

業務負荷と生活リズムを踏まえ、オンライン中心・ミーティング少なめの設計を基本としています。標準的には次のようなイメージです。 ・個人向け：初回 60〜90 分（現状整理・方向性の確認）＋フォロー 1 回（オンラインまたはテキスト） ・小規模チーム：1〜2 週間に 1 回のオンラインミーティング（計 2〜4 回）＋ Slack / メールでのテキストベースのやりとり ・リサーチ／共創プロジェクト：隔週〜月 1 回のミーティング＋実験ログ・メモを共有しながらの非同期コミュニケーション 「ミーティングの回数を増やすこと」ではなく、「意思決定と前提がログとして残ること」を主な評価軸にしています。ツールは既存の環境（Slack / Teams /メール 等）に合わせて柔軟に対応します。

3. 料金・契約・NDA

社内の稟議や予算計画、契約・コンプライアンスの観点から、事前に把握しておきたい内容に関する質問です。

料金はどのような考え方で見積もられますか？ 目安のレンジを教えてください。

時間単価ベースではなく、「構造の複雑さ × 影響範囲 × 再利用可能性」を軸に見積もります。目安は次のとおりです（詳細なパターンは Services ページに整理しています）。 ・Individual（個人向け）：5〜20 万円 - 例：AI × 仕事の相性マップ、個人向けプロトコル設計、ノート／ログ構造の設計など ・Team / Organization（チーム・組織向け）：30〜150 万円 - 例：AI 利用ルール／フロー設計、テンプレートセット、オンボーディングガイド、運用ガイドライン等 ・Research / Joint Project（リサーチ・共創）：20〜80 万円 - 例：小規模リサーチ、PoC 設計・検証、ケースノート・ZINE 制作、共同執筆プロジェクト等 一度きりのアウトプットではなく、内部の「学習基盤」として残る artefact の比率を高めることで、時間あたりの費用対効果が上がるように設計します。

契約形態と支払い条件について教えてください。

法人・個人事業主いずれからのご依頼にも対応しています。一般的なケースでは、次のような形になります。 ・契約形態：業務委託契約（準委任）を基本とし、必要に応じて個別契約書式に合わせて調整 ・NDA：単独の秘密保持契約、または業務委託契約内の条項として締結 ・支払い条件：案件完了後、または事前に合意したマイルストン単位で請求書を発行し、銀行振込にてお支払い ・海外からの依頼：条件によっては英語ベースの契約・海外送金にも対応可能 社内稟議に必要な情報（目的、期待成果、リスク、コストレンジなど）を 1〜2 ページに整理したメモが必要な場合は、一緒に作成することもできます。

NDA や機密情報の取り扱いはどうなりますか？

NDA には標準的に対応しており、情報セキュリティ／IT-BCP プロジェクトの経験を前提に「AI に渡さないべき情報がある」ことを前提条件として設計します。 ・着手前に NDA を締結し、扱う情報の範囲・粒度・共有方法を調整 ・AI サービスへの送信有無を判断するための基準を、実務レベルのルールとして明文化 ・ログの保存期間、マスキング方針、削除トリガー等を事前に定義 公開可能な範囲の知見を ZINE やケーススタディとして社外共有する場合も、必ず事前にご相談し、匿名化の程度やレビュー方法を合意したうえで進めます。

4. AI・ツール・セキュリティに関する質問

利用するモデルやツールの範囲、既存システムとの整合、セキュリティ設計について事前に確認したい方向けの質問です。

サポートしている AI サービスやツールの例を教えてください。

Fragment Practice は、特定ベンダーや特定ツールに依存しない「構造単位での設計」を基本としています。代表的な対象は次のとおりです。 モデルの例： ・OpenAI（ChatGPT / GPT-4o / Assistants API など） ・Google（Gemini） ・Anthropic（Claude） ・Perplexity ほか ツール／プラットフォームの例： ・Notion, Obsidian, Slack, Teams, Linear, Jira, Confluence ・Google Workspace / Microsoft 365 ・各種ナレッジベース、インシデント管理ツール、チケットシステム 「どのサービスを採用するか」だけではなく、「既存のスタックの上にどのようなプロトコル／テンプレート／ガイドを重ねるか」を一緒に設計していきます。

組織として生成 AI の利用経験がほとんどない状態でも依頼できますか？

はい、利用経験が少ない段階からのご相談にも対応しています。その場合は、最初に「AI 導入の前提整理セッション（60〜90 分）」を設け、次のような点を一緒に整理します。 ・現状の業務プロセスと、AI を利用したくない／してはならない領域 ・セキュリティ・コンプライアンス上の制約や、懸念を持っているポイント ・記録としてどこまで残したいか・どこからは残さないほうが良いか そのうえで、「リスクを抑えつつ効果が見えやすい最初の一歩」と、AI に任せる範囲・人が最終判断する範囲の線引きを、シンプルなプロトコルとして設計します。

すでに複数の AI ツールを使いこなしているチームにとって、どのような価値がありますか？

ある程度活用が進んでいるチームでは、「ローカル最適の積み重ねによる構造的な負債」が見え始めるタイミングでご相談いただくことが多いです。例えば： ・メンバーごとにプロンプトやテンプレートが乱立し、再利用・共有の単位が曖昧 ・PoC や検証は進む一方で、本番運用時の責任分界・レビュー手順・例外処理が整理されていない ・セキュリティ・IT-BCP 観点での境界線が明確でなく、現場と管理部門で認識がずれている こうした場合に、Fragment / Prism / QFS のレイヤーを用いて「プロトコルとしてどの粒度で揃えるか」「どこを標準化し、どこをローカル裁量に残すか」を一緒に設計していきます。

セキュリティや機微情報保護の観点から、どのように設計を進めますか？

情報セキュリティ／IT-BCP プロジェクトの経験を前提に、「AI を利用しないほうがよい領域」が存在することを前提にプロジェクトを設計します。 ・個人情報、営業機密、機微な社内情報など、AI へ送信しないカテゴリを整理 ・ログの保存場所・保存期間・アクセス権限・マスキング方針を、現行ポリシーとすり合わせ ・既存の ISMS や委託先管理の枠組みと矛盾しない形で、AI 利用ルールを定義 「便利さ」と「リスク管理」のバランスを、Health & Rhythm（働き方のリズム）も含めた視点から一緒に検討します。

5. 個人向け・チーム向けの違い

経営層・現場責任者・個人として、「どの単位から始めるのが現実的か」を検討したい方向けの質問です。

個人向けとチーム向けの違いは何ですか？ どちらから始めるケースが多いですか？

おおまかには、次のような違いがあります。 ・Individual：個人の仕事の構造（時間の使い方、ノート／ログの設計、AI との分担）にフォーカス ・Team / Organization：複数メンバーでの流れ（会議、チャット、ドキュメント、承認プロセス）と責任分界にフォーカス 実務上は、組織としての依頼であっても、最初はキーパーソン 1〜2 名の個人プロトコルから始めることが多いです。少人数で検証しながら、業務や文化にフィットするかを見極め、その後チーム単位・部門単位に拡張していくイメージです。

想定しているチーム・組織の規模感はどの程度ですか？

現在想定している規模感は次の通りです。 ・1〜3 名：経営者、プロダクトオーナー、研究者、フリーランスなどの個人プロトコル設計 ・3〜15 名：プロダクトチーム、事業開発チーム、研究ユニットなどのフロー／ドキュメント設計 ・〜数百名：大規模組織の中の特定部門（DX、情報システム、セキュリティ、人事 等）を対象にしたガイドライン設計やパイロット導入 全社変革や大規模な体制変更そのものを直接担うというより、「一定の範囲に Quiet System を設計し、そこから周辺に波及させる」アプローチを得意としています。

海外拠点を含むチームや、英語ベースの研究プロジェクトにも対応可能ですか？

はい、日本語／英語が混在するプロジェクトにも対応しています。例えば： ・日本語で議論した内容や意思決定を、英語の Prism 設定・プロトコルとして整理する ・英語話者の研究者・エンジニアと共同で、Research & Writing（ケースノート・論考）を進める といった形です。 時差、法務・コンプライアンス要件、契約条件などによっては難しいケースもあるため、まずは概要ベースでお問い合わせいただければ、可能な範囲をすり合わせさせていただきます。

6. Research & Writing / Fragment との関係

研究・検証プロジェクト、共同執筆、ZINE、Fragment（自社ノートツール）との関わり方を確認したい方向けの質問です。

Research & Writing は、通常のコンサルティングや伴走とどう接続されていますか？

多くのプロジェクトでは、まず実務寄りの Services（コンサルティング・伴走）としてスタートし、そこで繰り返し現れるパターンを Research & Writing に昇華させていきます。 ・現場の判断軸や設計上のトレードオフを、フレームワークやケースノートとして文章化 ・Fragment / Prism / QFS などのレイヤーに、YAML・テキスト・図表として落とし込み、後から再現可能な形に整理 ・公開可能な部分のみ切り出し、ZINE やトーク資料、技術ノートとして再構成 研究者・ラボとの共同研究では、観察ログ・設定ファイル・会話の文脈を「そのまま再検証できる単位」で残すことを重視しています。

自社プロジェクトの内容が ZINE やケーススタディとして社外公開されることはありますか？

公開有無や範囲は、プロジェクトごとに個別に合意を取りながら決めます。原則として： ・公開を検討する場合は、必ずドラフトを共有し、修正・削除の希望を反映 ・組織名／個人名の扱い（匿名化の程度）は、事前に明確な合意を取ったうえで決定 ・公開が適切でない場合は、完全な非公開の内部メモや設計書としてのみ保持 といった方針です。 「社外には出さないが、社内の他部門・経営層には共有したい」というケースでは、社内限定のケースノートやトーク資料を一緒に設計することも可能です。

Fragment（自社ノートツール）の導入は必須ですか？ 既存ツールのままでも依頼できますか？

Fragment（fragment.place / 自社ツール）の導入は必須ではありません。多くのプロジェクトでは、既存のノート／ドキュメント環境の上に構造とプロトコルを設計します。 ・Notion / Obsidian / Confluence / Google Docs / Microsoft 365 など、現行のスタックを前提として設計 ・Fragment 的な考え方（1 ページ = 1 Fragment、Prism / Scene / Flow のメタデータ等）のみを持ち込み、ツール自体は変えない進め方も可能 Fragment ツール自体は、 ・研究ノートや設計メモを「1 ページ単位」で扱いたい ・Prism / Scene / Flow などの設定と一緒にノートを管理したい といった場合に特に相性が良いですが、「概念のみ利用し、実装は既存ツール上で」という選択も歓迎しています。