---
name: ti-poc
description: 契約前の PoC・商談・社内検証で見込み客に「導入が簡単・速い」を体験させるトライアル体験スキル（契約前寄り）。TRIGGER when トライアル環境での価値実証、業務プロセスの可視化・理解、サンプルデータでの多軸集計デモ、少量の自社マスタや注文書・請求書を取り込む体験、デモ用サンプルデータの準備。DO NOT TRIGGER when 本番導入プロジェクトの工程進行は ti-onboarding、実装形態の判断は ti-lifecycle、単一の能力で完結する作業は層2スキル（ti-reference 等）。
version: 0.1.6
updated: 2026-07-21
---

# ti-poc — PoC・商談（トライアル体験）

契約前の PoC・商談・社内検証で、見込み客に「導入が簡単・速い」を実感させる**進行スキル**。4体験（理解・可視化 → サンプルデータでの多軸集計 → 自社マスタ取込 → 自社文書からの取引作成）を1本のナラティブで束ねる。**能力は再実装せず**、各体験で層2スキルを体験順に呼び、実装形態の判断は ti-lifecycle を参照する。契約が成立したら ti-onboarding へモードを遷移して引き継ぐ。

本書は薄い索引に徹する（詳細は必要な reference だけを読む方式）。体験の順序づけ・デモデータ／実演台本・モード設定の実体は各 reference にある。

## このスキルが持つもの・持たないもの

| 持つ（進行＝順序づけ・段取り） | 持たない（能力・判断＝委譲先） |
|---|---|
| 4体験（理解→集計→マスタ→文書）の順序づけと1本のナラティブ | 参照・集計の実行＝ ti-reference／可視化＝ ti-spec-view |
| 驚きの源泉（AI 固有性）の演出規律・poc モードの挙動設定 | データ投入・移行・デモデータ生成の機構＝ ti-data-load／帳票資産＝ ti-report |
| デモデータ作成のワークフロー設定（何を何件どの順で＝ ti-data-load を呼ぶ） | 文書→取引作成・入力支援＝ ti-update／メタデータ配備の機構＝ ti-metadata |
| ti-onboarding への引き継ぎ渡し・ロール別の見せ方の出し分け | 実装形態の判断（宣言的/Apex/外部/製品機能化・Anonymous Apex 可否・運用移行）＝ ti-lifecycle |
| — | 契約後の本番導入プロジェクトの工程進行＝ ti-onboarding |

進行はこのスキル、能力は層2、判断は ti-lifecycle。この主従を崩さない。単一の能力で完結する作業（集計を1本・マスタを1件・可視化を1枚・受注を1件）は層2へ直接落とし、本スキルを経由しない。

## モードと未判定既定（発火時にまず確認）

本スキル（契約前寄り）と ti-onboarding（契約後寄り）は同じ層2能力を違う局面モードで束ねる**連続体**で、相互排他ではない。**契約状態が判明した時点で poc→onboarding へモードが遷移**する。契約状態・環境が読めないときは、**フェーズを確定せず、参照・可視化のみで応答し、書込・環境前提を要する段に入る前に契約状態と環境（トライアル／Sandbox／本番）を能動的に確認する**。poc モード（サンプル・破棄前提・少量）を本番顧客に誤適用すると本番 org への害につながるため、「疑わしきは poc」を既定にしない。

## 発火点（いつ・どの reference を読むか）

| チェックポイント | 読む／呼ぶ | 渡す・確認するもの |
|---|---|---|
| どの体験を・どの順で見せるか段取りする瞬間 | `references/experience-flow.md` | 買い手の業務・現在の体験・環境（トライアル） |
| デモデータを用意する・多軸集計の実演台本を組む瞬間 | `references/demo-data-and-scenario.md` | 業種プロファイル・見せる集計軸・台本のテンポ |
| poc モードの挙動・onboarding への引き継ぎ・ロール別出し分けを決める瞬間 | `references/mode-and-handoff.md` | 契約状態・データ規模・ロール |
| 体験1の理解可視化・体験2の多軸集計を出す瞬間 | ti-reference の該当 reference（`experience-flow.md` が案内） | 対象プロセス・意味定義の参照点・見せる軸 |
| 現状のカスタマイズを把握・可視化する瞬間 | ti-spec-view の該当 reference | 対象 org・可視化の範囲 |
| デモデータ準備・体験3の自社マスタ取込で投入が要る瞬間 | ti-data-load の該当 reference（大量 I/O はスクリプト経路） | 投入シナリオ・dry-run→突合の前提 |
| 体験4の自社文書→取引作成が要る瞬間 | ti-update の該当 reference（レイアウト解析資産は ti-report 側） | 対象文書・意味定義マッピング |
| トライアル構築で「どの実装形態で作るか」の判断が要る瞬間 | ti-lifecycle の該当 reference（Anonymous Apex はトライアル限定で可） | 要件の性質・破棄前提かどうか |
| org へ書き込む直前（体験3のマスタ取込・体験4の取引作成） | ti-core `references/safety-gate.md` | 対象・承認ドラフト・dry-run→突合 |
| 現状仕様を往復で詰める瞬間（体験1の業務理解・Fit 確認） | ti-core `references/spec-roundtrip.md` | 現状仕様・買い手の業務説明 |
| トライアルで繰り返し詰まる／ナレッジが不足した瞬間 | ti-core `references/feedback.md` | 匿名化した摩擦シグナル |
| 一次解決で解けず利用者が未解決のまま／繰り返し詰まると判定した瞬間 | ti-core `references/support-escalation.md` | 本人の許可・再現手順（PII・業務データ本体・認証情報は載せない） |

> 本文中の能力スキル名（ti-reference・ti-update・ti-report・ti-metadata・ti-spec-view・ti-lifecycle・ti-core・ti-data-load）は配置済みで、フォルダ名＝正準名として辿れる（ti-data-load は `tsubaiso-data-migration` からの改称先）。未配置の機構・スキルに当たったら機構を捏造せず人へ引き継ぐ（または ti-core Knowledge で代替する）。

## reference 索引

| reference | 何を定義するか |
|---|---|
| `references/experience-flow.md` | 4体験マップ（各体験で呼ぶ層2能力・理解→集計→マスタ→文書のナラティブ）＋体験連続性（トライアル→PoC→導入→稼働後）＋驚きの源泉＝AI 固有性の設計原則（語り口の規律） |
| `references/demo-data-and-scenario.md` | デモデータ作成ワークフロー（ti-data-load をワークフロー設定で呼ぶ・業種プロファイル・山と谷の型）＋多軸集計の軸セットの型＋実演台本の型（軸切替のテンポ・待ち時間ゼロ・ROI 対比） |
| `references/mode-and-handoff.md` | poc モードの挙動軸・poc⇄onboarding の引き継ぎ（契約成立でのモード遷移・未判定既定）・ロール別の出し分け・段階導入と二層モデル・安全ゲート ≠ ライセンス制御の区別 |

## 原則

- **進行はここ、能力は層2、判断は ti-lifecycle**。体験の順序づけ・段取り・モード設定は本スキルが持ち、各体験の実作業と実装形態の判断は委譲先で行う。
- **驚きの源泉＝AI 固有性**。「その場で・準備なしで・速く」を驚きの核に据え、人力で事前準備できてしまうもの（事前受領して集計を作り込む等）は驚きに数えない。
- **AI が下書き、人が判断**。体験3・4で買い手の実データを操作する局面でも、下書き（取込案・マッピング案・dry-run 結果）を示し、確認・承認を得てから書き込む。
- **本書は薄く保つ**。体験の手順・デモデータ・台本・モード設定は reference に置き、SKILL.md は索引に徹する。
- 出力に内部識別子（API 名・SOQL・レコード ID）を利用者向けに出さない（ti-core 群A の出力規律に従う）。