FAQ（よくある質問） — 相談範囲・成果物・料金・機密情報の扱いを、先にクリアにするページです。

カテゴリ一覧

迷う場合は「1. はじめての方・全体像」か「3. AI・ツール・機密情報の扱い」から見るのがおすすめです。

「何を相談できるか」「自分たちの状況に合うか」を短時間で確認したい方向けです。

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

会議・ドキュメント・チャット・チケットが増える中で、 「判断が遅い／引き継げない／理由（Why）が消える」といった“運用の詰まり”が起きているときに向いています。 よくある状況： ・生成AIは使われ始めたが、チームとしての判断基準（どこまで任せ／どこから人が必ず読む・決めるか）が曖昧 ・会議が増え、メモ・チャット・ドキュメント・チケットが分断して「なぜそう決めたか」が追いにくい ・ポリシー/ガバナンスはあるのに、現場の会議・記録運用に接続されず形骸化している ・PoCや試行錯誤が積み上がる一方で、前提（設定・条件）と結果（観察ログ）が残らず再現できない Fragment Practice は、単発の“AI活用テク”よりも、 ・判断基準と責任分界（運用ルールの核） ・記録の構造（会議・意思決定・検証ログ） ・無理なく続く見直しのリズム を一体で整え、運用として回り続ける状態を目指します（内部ではこれを Quiet System と呼ぶことがあります）。

この項目へのリンク

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

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

この項目へのリンク

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

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

この項目へのリンク

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

初回〜序盤では、いきなり“分厚い資料”よりも、判断と運用の核になるテキストが先に残ります。 例： ・前提条件（制約・関係者・扱う情報）と、扱う/扱わない範囲のメモ ・判断基準（AIに任せる範囲／人が必ずレビューする範囲）のたたき台 ・会議・記録・タスクの「どこが詰まっているか」の簡易マップ この“薄い合意”があるだけで、チーム内の会話や設計の速度が変わるケースが多いです。

この項目へのリンク

相談後、どこから始めるのが現実的ですか？

多くの場合、最初の入口は次のいずれかです。 ・会議 → 議事録 → 決定 → タスクの“つなぎ目”を整える ・AIに渡す/渡さないの境界と、必須レビュー点を先に決める ・検証ログ（試行の前提と結果）が残るテンプレを先に作る 「大きく変える」より、まず小さな運用単位で“核”を差し込み、ログで育てるのが基本です。

この項目へのリンク

問い合わせ後、どのような返答が返ってきますか？

いただいた内容を拝見し、メールで次のような形でお返しします。 ・状況の要約（論点と前提条件を、1枚に整理） ・次の一手の候補（どこから入ると負担が減るか：Spot/Sprint/Ongoing の提案） ・確認したい点（追加で3〜5点ほど） ・機密情報の扱い（必要ならNDAや共有チャネルの提案） 完全に整理された要件は不要です。共有できる範囲の“材料”だけで構いません。

この項目へのリンク

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

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

個人・チーム・研究のいずれでも、基本は次の 5 ステップです。 1) 前提条件と境界の確認 業務/組織/ツール/セキュリティ要件/運用リズム等を共有し、今回の範囲と除外範囲を決めます。 2) 現状整理（材料の棚卸し） メモ・チャット・ドキュメント・ログを並べ、認知負荷/断絶/判断遅延が起きる地点を見立てます。 3) 初期案（運用ルール／テンプレのたたき台） テンプレート、チェックリスト、簡易フロー、必要に応じて設定（YAML 等）として起こします。 4) 試行 → 微調整（現場で回る形へ） 実務で回してもらい、ログ/フィードバックから「続く形」に寄せて調整します。 5) 納品整理（更新できる形で引き渡し） 最終版のルール/テンプレ/補足メモを整理し、必要なら社内共有用の短いレポートにします。

この項目へのリンク

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

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

この項目へのリンク

成果物は、どの形式で提供されますか？（社内共有用）

基本は「社内で更新しやすい形式」を優先します。 例： ・ドキュメント：Google Docs / Notion / Confluence / Microsoft 365 など（貴社環境に合わせます） ・テンプレ：チェックリスト、運用手順、FAQ、意思決定メモ、検証ログ ・共有用：必要に応じて PDF / 短いスライド（説明用） 目的が「運用に埋め込む」ことなので、編集権限や共有範囲も含めて最初にすり合わせます。

この項目へのリンク

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

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

この項目へのリンク

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

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

この項目へのリンク

こちらが準備しておくと良いものはありますか？

あれば助かりますが、必須ではありません。 ・いま使っている会議体（定例/1on1/レビュー）の一覧 ・議事録や決定メモのサンプル（機密は伏せた形でOK） ・AI利用の現状（ルール有無、気になっている事故/不安） “共有できる範囲”だけで構いません。最初は「どこが重いか」さえ分かれば十分です。

この項目へのリンク

どのモデル/ツールを前提にできるか、既存環境との整合、機密情報の扱い（NDA/境界線の設計）を確認したい方向けです。

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

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

この項目へのリンク

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

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

この項目へのリンク

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

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

この項目へのリンク

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

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

この項目へのリンク

「AIに渡せる情報／渡せない情報」はどう決めますか？

方針だけでなく、現場で迷わないチェック質問に落とします。 例： ・この情報は、外部SaaSに載せても良いか？（共有範囲） ・個人情報/顧客情報/契約情報を含むか？（情報カテゴリ） ・この出力は誰がレビューし、どこに記録するか？（責任とログ） 組織の既存ポリシーがある場合はそれを優先しつつ、実務テンプレとチェックポイントに埋め込みます。

この項目へのリンク

既存の社内ルール（規程/監査/ISMS 等）がある場合はどう進めますか？

既存の社内ルールを前提に進めます。 ・規程/ガイドラインに合わせて、現場の会議・記録・レビュー手順に接続 ・例外が出るポイント（現場判断が必要な箇所）を明確にし、エスカレーション/記録の型を用意 ・委託先/外部SaaS/国外拠点など、境界が揺れやすい部分を優先的に整理 「ルールを増やす」より、いまあるルールが運用として機能する形に落とすことを重視します。

この項目へのリンク

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

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

時間単価ベースではなく、役割とスコープを合意したうえで、原則「固定精算」で設計します。 料金が上下する主な要因： ・構造の複雑さ（判断基準／ログ設計／例外運用／更新ルールのどこまで扱うか） ・関係者の幅（現場／情シス／セキュリティ／法務 等、誰を巻き込むか） ・成果物の再利用性（テンプレ／FAQ／説明用ひな形として横展開できる度合い） 目安（税抜・固定精算のガイド）： ・Spot（論点整理と判断基準のたたき台）：数万円台〜 ・Sprint（テンプレ/ルールの初期版＋試行）：数十万円〜（小規模）／数百万円〜（組織） ・Ongoing（運用レビュー＆改善）：月額 数十万円〜 ※基本は「設計・判断・レビュー中心」で、常駐・作業代行を前提としていません。

この項目へのリンク

どのプランから始めるのが一般的ですか？

多くは次の順で進めます。 1) Spot：論点と判断基準を揃える（何を決めるべきか／どこが詰まりか） 2) Sprint：必要箇所だけを文書化・運用化（テンプレ、FAQ、例外運用、更新ルール） 3) Ongoing：ケースで育てる（例外対応、品質ブレ、運用更新を月次で回す） 「大きな資料を先に作る」よりも、小さな運用単位で始めてログで育てるほうが、定着しやすいです。

この項目へのリンク

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

法人・個人事業主いずれも対応しています。 ・契約：業務委託（準委任）を基本に、必要に応じて貴社書式に合わせます ・精算：パッケージ（Spot/Sprint/Ongoing）または合意した役割・スコープで固定精算 ・支払い：月次請求（銀行振込）を基本に、短期 Spot/Sprint は完了後請求等も調整可能です 社内稟議用に、目的/想定成果物/前提（扱う情報の境界）/目安の整理（1〜2ページ）が必要なら、初期に一緒に作成できます。

この項目へのリンク

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

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

この項目へのリンク

稟議・購買のために、何を用意すればいいですか？

一般的には次があると進みやすいです（必要ならこちらで整理メモを作れます）。 ・目的：何の詰まりを解消するか（会議/ログ/AI境界/運用負債など） ・範囲：対象部門/人数/期間 ・扱う情報の境界：機密の扱い、共有チャネル、NDA要否 ・成果物の形：テンプレ/ルール/FAQ/短いレポート/説明用ひな形 “高い資料力”より、合意形成できる粒度の前提があるかが重要です。

この項目へのリンク

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

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

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

この項目へのリンク

想定している規模感は？

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

この項目へのリンク

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

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

この項目へのリンク

オンサイト（対面）対応は可能ですか？

内容と地域により調整可能です。 基本はオンライン＋非同期ログ往復ですが、ワークショップや重要局面（合意形成/研修/設計キックオフ等）では対面が有効なこともあります。移動や日程条件を含め、まずはご相談ください。

この項目へのリンク

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

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

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

この項目へのリンク

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

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

この項目へのリンク

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

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

この項目へのリンク

最終的に目指す状態（アウトカム）は何ですか？

目指すのは「AIで速くなる」だけでなく、次が同時に成立する状態です。 ・判断がログとして残り、後から追える（理由が消えない） ・例外が扱える（禁止/推奨だけでなく、現場で迷わない） ・更新できる（運用ルールが“育つ”） ・無理なく続く（リズムを壊さない） つまり、運用が静かに回り続ける土台があることです。

この項目へのリンク