tsubaiso ti-onboarding — 導入支援（工程進行）
ベータとして先行提供している機能です。 記述が変わることがあります。扱いは ti-core の
references/beta-status.mdを参照してください。
契約顧客の本番導入プロジェクトを「計画 → 設計 → 制作 → 構築 → データ移行 → 教育 → 運用テスト」の工程で進める進行スキル。能力は再実装せず、各工程で層2スキルを工程順に呼び、実装形態の判断は ti-lifecycle を参照する。原則は一貫して「AI が下書き、人が判断」。
本書は薄い索引に徹する（詳細は必要な reference だけを読む方式）。工程の順序づけ・対話ループ・モード設定の実体は各 reference にある。
このスキルが持つもの・持たないもの
| 持つ（進行＝順序づけ・段取り） | 持たない（能力・判断＝委譲先） |
|---|---|
| 導入工程（7工程／ERP工程）の現在地把握と次工程の段取り | 参照・集計の実行＝ ti-reference／可視化＝ ti-spec-view |
| 設計工程の AI リード対話ループ（業務説明→Fit&Gap→マスタ設計→反復） | データ投入・移行の実行＝ ti-data-load／帳票＝ ti-report |
| onboarding モード（全量・本番前提）で層2を呼ぶ挙動設定 | メタデータ配備の機構＝ ti-metadata／入力支援・承認前チェック＝ ti-update |
| poc からのモード遷移の受け・ロール別の出し分け | 実装形態の判断（宣言的/Apex/外部/製品機能化・Anonymous Apex 可否・運用移行）＝ ti-lifecycle |
| — | 契約前の価値実証・トライアル体験の演出＝ ti-poc |
進行はこのスキル、能力は層2、判断は ti-lifecycle。この主従を崩さない。単一の能力で完結する作業（集計を1本・マスタを1件・可視化を1枚・受注を1件）は層2へ直接落とし、本スキルを経由しない。
必要な業務領域から順に立ち上げるとき
7工程は全量導入の型だが、同時に全部を立ち上げなくてよい。販売・購買・制作・在庫・原価計算・管理会計・会計のうち、顧客がいま困っている領域から順に立ち上げ、残りは既存のやり方（表計算・既存システム）に置いたままにできる。
進め方は全量と同じ7工程を、対象を選んだ領域に限って回す。 違うのは範囲だけで、工程を省略しない（設計を飛ばして構築から入らない・運用テストを省かない）。
順序の決め方 [REQUIRED]: 立ち上げる領域は、顧客の困りごとの強さではなく依存の向きで並べる。下流だけを先に立ち上げると、上流から来るはずのデータを手で入れ続けることになり、属人化を移し替えただけになる。依存の実体は ti-reference の契約モデル索引・プロセス索引で引き、決め打ちしない。
据え置く領域との境目を先に決める [REQUIRED]: 立ち上げない領域との境目には、必ず人か仕組みが埋める手当てが要る。境目に何が残るかを工程の計画時に列挙し、「あとで考える」で先送りしない（列挙しないまま進むと、運用テストで初めて露見して工程が戻る）。ERP の外に残ったデータとのあいだの受け渡しは ti-update references/external-handover.md。
全量へ広げるとき: あとから追加する領域は「稼働後に新しい業務・事業が加わったとき」（次節）と同じ扱いで、references/design-lead-loop.md を対象を限って回す。既存業務への波及を確認してから足す [REQUIRED]。
稼働後に新しい業務・事業が加わったとき
導入が終わったあとも、新しい業務が始まる・新しい商品やサービスの事業が立ち上がるたびに、業務プロセスをどう組むか・それを製品へどう登録するか・マスタをどう設計するかを決め直す必要が生じる。これは導入時の設計工程と同じ問いなので、同じ対話ループ（references/design-lead-loop.md）を、対象を新しい業務に限って回す。
導入時との違いは範囲だけで、進め方は変えない。全社を作り直すのではなく、増えた業務のぶんだけを設計して足す。 原則は導入時と同じく「AI が下書き、人が判断」。着手前に、既存の業務・データ・設定へ波及しないことを確認する（適用の型と確認の手順は references/design-lead-loop.md §稼働後の新しい業務・事業への適用）。
モードと未判定既定（発火時にまず確認）
本スキル（契約後寄り）と ti-poc（契約前寄り）は同じ層2能力を違う局面モードで束ねる連続体で、相互排他ではない。契約状態が判明した時点で poc→onboarding へモードが遷移する。契約状態・環境が読めないときは、フェーズを確定せず、参照・可視化のみで応答し、書込・環境前提を要する段に入る前に契約状態と環境（トライアル／Sandbox／本番）を能動的に確認する。onboarding モード（全量・本番前提）を安易に既定にしない（本番 org への誤書込を避ける）。
発火点（いつ・どの reference を読むか）
| チェックポイント | 読む／呼ぶ | 渡す・確認するもの |
|---|---|---|
| そのセッションで最初に TI のスキルを使う瞬間（依頼の内容を問わず・1 セッション 1 回） | ti-core references/version-freshness.md |
同梱 .claude-plugin/plugin.json の版 |
| 製品の操作手順・可否・理由を書こうとした瞬間／製品そのもの（コード・フロー・項目ヘルプ・パッケージのメタデータ）を読もうとした瞬間／実測と期待の食い違いを不具合と書こうとした瞬間／作業の対象範囲を自分で数え上げようとした瞬間 | ti-core references/knowledge-lookup.md |
引きたい製品・機能と、利用者の言い方 |
| 導入工程のどこにいて次に何をするか段取りする瞬間 | references/process-map.md |
現在の工程・環境（トライアル/Sandbox/本番） |
| 必要な業務領域から順に立ち上げる（部分導入の）段取りをする瞬間 | references/process-map.md ＋ 本書 §必要な業務領域から順に立ち上げるとき |
立ち上げる領域・依存の向き・据え置く領域との境目に残るもの |
| 設計工程で業務モデル・Fit&Gap・マスタ設計を対話で進める瞬間 | references/design-lead-loop.md |
業務プロセス説明・実帳票・関与すべき現場責任者 |
| 稼働後に新しい業務・新しい商品/サービスの事業が加わった瞬間 | references/design-lead-loop.md §稼働後の新しい業務・事業への適用 |
新しい業務の範囲・取引の型（何を売り・いつ収益を認識し・何が原価か）・既存業務への波及の有無 |
| onboarding モードの挙動・poc からの引き継ぎ・ロール別出し分けを決める瞬間 | references/mode-and-handoff.md |
契約状態・データ規模・ロール |
| 設計工程で業務の流れ・構造・集計を示す瞬間 | ti-reference の該当 reference（process-map.md が案内） |
対象プロセス・意味定義の参照点 |
| 現状のカスタマイズを把握・可視化する瞬間 | ti-spec-view の該当 reference | 対象 org・可視化の範囲 |
| 制作・構築工程でメタデータ配備・帳票が要る瞬間 | ti-metadata／ti-report の該当 reference | 配備対象・帳票の仕様 |
| データ移行工程で大量投入・移行が要る瞬間 | ti-data-load の該当 reference（大量 I/O はスクリプト経路） | 移行対象・dry-run→突合の前提 |
| 運用テスト工程で入力支援・申請前/承認前チェックが要る瞬間 | ti-update の該当 reference | 対象レコード・チェック観点 |
| 据え置いた領域と ERP のあいだでデータを受け渡す瞬間 | ti-update references/external-handover.md |
向き（外→ERP／ERP→外）・出所・時点・持ち出しの範囲 |
| 制作・構築工程で「どの実装形態で作るか」の判断が要る瞬間 | ti-lifecycle の該当 reference | 要件の性質・継続保守の主体 |
| org へ書き込む直前（制作・構築・データ移行・運用テスト） | ti-core references/safety-gate.md |
対象・承認ドラフト |
| 現状仕様を往復で詰める瞬間（Fit&Gap・マスタ設計の確定） | ti-core references/spec-roundtrip.md |
現状仕様・変更指示 |
| 工程で繰り返し詰まる／ナレッジが不足した瞬間 | ti-core references/feedback.md |
匿名化した摩擦シグナル |
| 一次解決で解けず利用者が未解決のまま／繰り返し詰まると判定した瞬間 | ti-core references/support-escalation.md |
本人の許可・再現手順（PII・業務データ本体・認証情報は載せない） |
本文中の能力スキル名（ti-reference・ti-metadata・ti-report・ti-update・ti-spec-view・ti-lifecycle・ti-core・ti-data-load）は配置済みで、フォルダ名＝正準名として辿れる（ti-data-load は
tsubaiso-data-migrationからの改称先）。未配置の機構・スキルに当たったら機構を捏造せず人へ引き継ぐ（または ti-core Knowledge で代替する）。
reference 索引
| reference | 何を定義するか |
|---|---|
references/process-map.md |
PSA 7工程マップ（各工程で呼ぶ層2能力・ti-lifecycle 参照点・トライアル→Sandbox→本番の環境進行）＋ERP 工程の差分（仕訳分析ほか）＋大量 I/O のスクリプト経路 |
references/design-lead-loop.md |
設計工程の AI リード対話ループ（インプット→業務説明→操作説明→Fit&Gap→マスタ設計→反復）。マスタ設計シミュレーションは合成（接地=ti-reference／投入=ti-data-load／集計・可視化=ti-reference・ti-spec-view／統合提案=ループ内推論）で専用能力を持たない |
references/mode-and-handoff.md |
onboarding モードの挙動軸・poc⇄onboarding の引き継ぎ（契約成立でのモード遷移・未判定既定）・ロール別の出し分け・段階導入と二層モデル |
原則
- 進行はここ、能力は層2、判断は ti-lifecycle。工程の順序づけ・段取り・モード設定は本スキルが持ち、各工程の実作業と実装形態の判断は委譲先で行う。
- AI が下書き、人が判断。全工程で下書きを示し、確定・承認は人に委ねる。設計工程では関与すべき現場責任者・論点を能動的に明示する。
- 範囲は狭くできるが、工程は省略しない。部分導入でも稼働後の追加でも、回す工程は同じで対象だけを絞る。
- 本書は薄く保つ。工程の手順・対話ループ・モード設定は reference に置き、SKILL.md は索引に徹する。
- 出力に内部識別子（API 名・SOQL・レコード ID）を利用者向けに出さない（ti-core
references/output-discipline.mdに従う）。