Ti Rollout

ti-rollout — 導入ロールアウト（接続・環境セットアップの進行）

TI を顧客環境で「安全・安心に使い始める」ための進行スキル。接続と環境の準備を、AI が自動化できる部分と人が本人操作する部分に分けて順に進める。能力は再実装せず、データ投入は ti-data-load、参照は ti-reference、メタデータは ti-metadata、書込安全は ti-core を呼ぶ。原則は一貫して「AI が下書き・設定、人が承認・本人認証」。

0. 発火時にまず提示する注意（プライバシー）[REQUIRED]

ロールアウトを始める最初に、必ず次を利用者へ提示してから手順に入る（省略禁止）。

⚠️ プランとプライバシー: TI は Team／Enterprise を推奨します（個人プランは推奨しません）。個人プラン（無料／Pro／Max）で業務データを扱う場合は、業務データを扱う前に必ず「Improve Claude for everyone（モデル改善への利用）」をオフにしてください。オンのままだと、会話の内容（参照した業務データを含む）が AI モデルの学習に使われ、長期間保持されることがあります。Team／Enterprise は既定で学習に使われません。

提示後、現在のプランと当該設定の状態を確認し、個人プランかつ未オフならオフを促してから先へ進む。

1. クライアント非依存の方針 [REQUIRED]

TI は特定 AI クライアントに固定しない。**Claude は参照実装（案内・自動化・スキル配布が最も整っている）**として推奨するが、資産は標準に寄せて可搬にする。

• 意味・ナレッジ・実データはすべて標準 MCP（Atlas／Knowledge／Salesforce 標準 MCP）。MCP 対応クライアントなら接続先は共通。
• 手順・判断ルールは Markdown（本スキル群）。他クライアントへは形式変換で取り込める（例: Cursor=ルール＋mcp.json＋エージェント実行、ChatGPT=カスタム指示＋コネクタ）。取り込みの可否・範囲は各クライアントの MCP 対応状況に依存する。
• org 側設定・移行スクリプトの自動化にはコマンド実行環境が要る。参照実装ではローカル実行（Salesforce CLI）を使う。ローカルでコマンド実行できるクライアント（Cowork デスクトップ／エージェント型エディタ等）では自動化まで可能。実行環境の無いクライアント（例: Web の ChatGPT）は、知識・データ接続は使えるが org 側設定は各クライアント標準の手順で手動になる（メタデータをホスト型デプロイで行う設計にすれば自動化も原理的に可能）。
• 他クライアント向けに変換・移植を頼まれたら、SKILL 本文（手順・ルール）を対象形式へ写し、MCP 接続情報を対象の設定へ落とす。Claude 固有語（プラグイン等）は一般語（スキル／ルール）に置換する。

1.5 役割とタイミング（管理者・各利用者の両方に対応）[REQUIRED]

本スキルは 2 つの役割・タイミングを 1 本で扱う（発火時に役割・局面を判定し、該当フローだけを案内する。分割スキルにはしない＝接続モデル・安全の枠組みを共有し重複を避ける）。

判定: 発火時に「初回の組織セットアップ（管理者）」か「各自の接続（利用者）」かを確認する。利用者フローは短く済ませ（既定は接続・本人ログインのみ。各自導入の顧客ならプラグイン導入を先に案内）、管理者フローは §3 を順に進める。役割が不明なら確認してから該当フローへ入る。§0 の個人プラン注意は役割に関わらず最初に提示する。

利用者フロー（各利用者が本人接続するとき）

利用者はコネクタの追加も接続キーの入力も不要で、一覧にある組織コネクタを選んで「接続」し、本人でサインインするだけ。AI は接続画面を開いて対象を選び「接続」を押すところまで代行してよく、サインイン（本人認証）だけは本人に渡す（資格情報は AI が扱わない）。画面操作ができないホストでは、押す場所を 1 段ずつ案内する。

1. コネクタ一覧（設定 / カスタマイズ → コネクタ）で、未接続にある参照用の組織コネクタを選び「接続」→ 本人の Salesforce アカウントでサインインして許可
2. 更新も使う人は、同じ手順で更新用の組織コネクタを接続する。接続後、作成・更新系のツール権限を「実行前に確認する」設定にする [REQUIRED]（書き込みを許す前提の必須設定。誤操作・外部からの指示混入への備え）
3. 新しいチャットで「接続先の org とユーザーを確認して」。本人の情報が返れば完了。更新を使うときは「実行前に、どのレコードをどう変えるか先に示して」を添える

参照だけでよい人は 1 だけでよい。見える・触れる範囲は本人の Salesforce 権限どおりで、接続する側に範囲を設定する項目はない。

2. AI が自動で行う／人が本人操作する（境界）

接続用アプリ（ECA）は 4 つの構成要素を 1 回のデプロイにまとめて送る。コンシューマ鍵と oauthLink はプラットフォームが採番するため雛形から除去して送る。構成要素を分けて送らない（単体・順序違いのデプロイは不完全な状態や失敗になる。step 5）。デプロイが通らないときは Setup 画面での手作成へ切り替える。

セキュリティ既定: 最小権限、既定は読み取り専用（更新は明示有効化＋実行前承認、削除はしない）、参照範囲は本人権限内、データは顧客 org 内（ツバイソ非経由）。

3. 進行手順（順に案内・各段で目的を伝える）

各段で「何のために何をするか（安全観点）」を一言添えてから進める。人の操作は場所と手順を都度案内する。

step 0. 管理者ご自身の環境へ TI を入れる（進入口・本スキルの外側が持つ）[REQUIRED]

本スキルは TI の配布物であり、TI が入っていない相手には発火しない。 したがって「管理者が自分の環境へ TI を入れる」段だけは、どう書いても本スキルからは届かない。この段は配布物の外側（顧客へ渡すセットアップ手順書・当社からの個別案内）が持つ。

• 本スキルが発火している時点で、この段は済んでいる。 step 1 へそのまま進んでよい
• 例外は、管理者以外の人が代わりに進めようとしている場合。 step 2・3・6 の管理者操作は、管理者が自分の画面で行えば足りる（別の場所からでも進む）。step 9 だけは、AI が管理者の GitHub 認可のもとで受け皿を作る段で、AI が動いている環境そのものが管理者のものである必要がある。口頭の中継では代替できないため、管理者本人の環境にも TI を入れる必要があることを先に伝える
• 外側の手順書を参照しながら進めているなら、その手順書にこの段が書かれているかを確認する。 無いと、手順書の1段目が「TI に依頼してください」で始まり、TI を持っていない読み手には最初の一手が存在しない状態になる。手順書は当社の成果物で、管理者には直せない。この段で直そうとせず、ツバイソへの申し送りとして記録し報告する

手順書を整備する側への申し送り: 手順書側は「この段は外側が持つ」、本スキル側は「ここから先を案内する」と双方向に書く。本スキルからは手順書の状態が見えないため、恒常的な担保は手順書の改訂フロー側のチェックに置く。

1. §0 の注意提示 → プラン/設定確認。

2. Atlas／Knowledge の組織コネクタ登録（人: 管理者が組織登録。Team/Enterprise は以後各自は接続のみ）。目的＝業務の意味・ナレッジを会話で引ける土台。ここで、パッケージ同梱のログイン用 ECA が組織にあるかを確認する（バージョン番号では判定しない）。無ければ組織ごとに手動で 1 つ作る必要があり、手順は references/f0-login-eca-setup.md。作らないとログインできず以降の段へ進めないため、この段で判定して先に着手する。

3. PSA/IMA（Salesforce）の MCP サーバー有効化（人: 管理者が設定画面でトグル。参照=Reads、必要なら更新=Mutations）。目的＝AI からの接続の受け口を開く。最小で始める（Reads のみ）。

4. 組織を Salesforce CLI に認証（AI: CLI 用意・実行開始／人: ブラウザで本人ログインのみ・一度きり）。目的＝接続用アプリ本体・権限セット等のメタデータ生成とデプロイ、データ構造マップの生成をローカル実行で行う土台。

5. 接続用アプリ（外部クライアントアプリ）の作成＋接続キー取得（AI: 設定値の用意・デプロイ・鍵の取得／人: デプロイの承認）。目的＝最小権限の既定値で正しく設定し、手作業の設定ミス・過剰権限を防ぐ。4 つの構成要素（アプリ本体・OAuth 設定・グローバル OAuth 設定・ポリシー）を 1 回のデプロイにまとめて送る。 コンシューマ鍵と oauthLink はプラットフォームが採番するため、雛形から除去して送る。別 org の雛形を使う場合は orgScopedExternalApp を対象 org へ書き換える。構成要素を分けて送らない——OAuth 設定を単体で送るとデプロイは通るのにコンシューマ鍵が採番されず接続に使えない状態になり、ポリシーを OAuth 設定より先に送るとエラーで失敗する（不足分を後から送れば回復する）。部分的に失敗したときの順は (1) 不足分の追送で回復 →(2) だめなら Setup 画面での手作成（削除して作り直すとコンシューマ鍵が変わり、配布済みの設定を巻き込む）。設定項目・OAuth 範囲・セキュリティのチェック内容は references/api-eca-setup.md §1〜§3 に準じる（同 reference は api スコープ ECA の手順だが、構成と作成上の制約は ECA 共通）。このアプリが標準 MCP 接続の OAuth 認証の受け皿になり、取得した接続キー（Client ID）を step 6 でコネクタに設定する。OAuth の具体構成（コールバック・範囲・PKCE 等）は references/api-eca-setup.md が持つため本節では再掲しない。このアプリと付随する権限セット等を org へデプロイする前に承認ゲートを通す（発火点表の ti-core safety-gate＝承認ドラフト提示→人が承認。メタデータの生成・デプロイという機構そのものは ti-metadata）。

6. コネクタ登録／結線の案内（人: 管理者が組織コネクタに Salesforce を登録し、詳細設定の Client ID に接続キーを設定。各利用者は一覧から「接続」して本人ログイン）。接続キーは秘匿情報でなく接続元の識別子＝一度設定して配るだけ。

7. 読み取り/更新の選択の確認（人: 用途に応じ Reads のみか Mutations も。更新時も承認を挟む・削除不可）。

8. 疎通確認（AI: 「接続先の org とユーザーを確認」を実行し、意図した org/本人か確認）。

9. TIプラグインの配布（既定は全社一括）。組織のマーケットプレイスは private／内部リポジトリのみを受け付けるため、顧客の管理下に受け皿を 1 つ作り、そこから配る。ツバイソ側から顧客組織へ直接配れない構造である点を、安全上の意味として管理者へ伝える。公開配布元の取得に招待・認証・追加課金は要らない。利用可否を決めるのは配布物へのアクセスではなく Tsubaiso Atlas MCP からの意味定義配信（§5）。他クライアントは形式変換。

   AI が行う: (a) 受け皿＝顧客 GitHub 上の空の private リポジトリを作る（README・.gitignore・ライセンスを付けない。付けるとコミットが生じ複製の送信が弾かれる）。(b) 公開配布元をミラー複製して送る（git clone --mirror {公開リポジトリ} → git remote set-url --push origin {受け皿} → git push --mirror）。フォークは使わない（フォークは元リポジトリと可視性設定を共有するため public のフォークは public になる）。

   人が行うのは 2 つだけ: (1) GitHub の本人認可。受け皿は顧客の資産なので、作成を AI へ委ねる許可をブラウザで一度取る。顧客が GitHub アカウントを持たない前提で、無料アカウントの作成から案内する（private リポジトリは無料枠で作れる）。(2) 配布先の決定。受け皿に Claude の GitHub アプリを入れ、組織設定でコネクタの GitHub を有効化 → 組織設定 > プラグイン > プラグインを追加 > GitHub から同期 で受け皿を選び、ユーザーアクセスを「既定でインストール」または「必須」にする。誰に配るかは管理者の判断であり AI は代行しない。

   受け皿は org 配下である必要はない（要件は private であること・GitHub アプリが入っていること・自動同期を使うなら本人がそのリポジトリの admin であることの 3 点のみ）が、継続性と保守の分散から org 配下を勧める。

   改訂の取り込み（既定＝追従ワークフローを置く）: 初回の複製を送ったら、続けて同梱の雛形 templates/upstream-sync.yml を受け皿の .github/workflows/upstream-sync.yml として置く。雛形は改変せずそのまま置く（改変したときは置く前に python3 -c "import yaml; yaml.safe_load(open(...))" で解析できることを確かめる。解析に失敗するワークフローは GitHub が実行しないため、一度も動かないまま「上流に差分が無いだけ」と読めてしまう）。以後は新しい版が出るたび、追従 PR が立ち、そのまま自動でマージされる（雛形の既定 AUTO_MERGE: 'true'）。管理者の手作業は要らない。配る判断は「上流を信頼する」という初回の決定に寄せてある。

   反映は必ず PR のマージで行う [REQUIRED]。 組織マーケットプレイスの自動同期は「版上げを含む PR が既定ブランチへマージされたとき」に発火し、既定ブランチへの直接 push では発火しない（公式ドキュメント「Manage plugins for your organization」の記載）。したがって受け皿の側でどれだけ速く反映しても、PR を経ていなければ利用者へは届かない。雛形が自動反映でも PR を立ててからマージする形にしているのはこのためで、「PR を省けば速い」と考えて直接 push へ変えると、受け皿の main だけが進んで配信が止まる。

   反映は 1 日 1 回で、時刻は保証されない [REQUIRED]。 GitHub の scheduled は混雑時に遅れ、当日発火しないこともある（当社の受け皿で約 5 時間の遅れと未発火の日を実測）。「昨日出た版が今朝には入っている」を前提に案内しない。 急いで反映したいときは受け皿の Actions で「Run workflow」を手動実行する（管理者が任意に押せるもので、配る判断をやり直すことにはならない）。滞留の通知も同じスケジュールで動くため、通知そのものが 1 日単位で遅れる。

   毎回人が判断する形へ切り替えることもできる: 雛形の AUTO_MERGE を 'false' にすると、立った追従 PR を管理者がマージして初めて配られる。この 1 行だけは改変してよい（上の「改変せずそのまま置く」は挙動を書き換えないという意味で、用意された切り替えを使うことは含まない）。選ぶのは運用の設計で、既定の良し悪しではない——自動反映は「上流を信頼するという決定を一度だけ行い、以後は任せる」形、'false' は「毎回どの版を配るか管理者が決める」形。違いはマージを誰が押すかだけで、PR が立つところまでは同じ。 どちらでも、マージできないとき（競合・レビュー必須のブランチ保護・必須チェックの失敗）は PR が open のまま残るので、壊れた状態が黙って配られることはない。

   既定を自動反映にしているのは、手作業を残すこと自体が統制にならないため [REQUIRED]。マージが滞れば利用者の手元は古いままになり、利用者からは「できるはずのことができない」という形でしか気づけない（当社自身の受け皿で、追従 PR が 5 日滞留して 6 版分止まった）。滞留の通知はそのための保険であって、通知が要る運用はすでに痛みを払っている。'false' を選ぶのは、顧客が版を選別する必要を実際に持っているときだけにする（規程で版の受け入れ判定を要する、検証環境で先に確認する運用がある、等）。「念のため人を挟む」を理由に選ばない。

   置いたあと管理者に 2 つ依頼する。(1) 受け皿の Settings > Actions > General > Workflow permissions で「Allow GitHub Actions to create and approve pull requests」を有効にする（同じ欄のラジオボタンは変更不要）。自動反映が既定でも省略しない——反映の経路そのものが PR の作成とマージなので、無効だと何も動かない。(2) 組織設定 > プラグインでそのマーケットプレイスの「自動的に同期」を on にする。この操作をする人が受け皿の admin である必要がある（webhook を作るため。admin でないと「Cannot access repository」と出るが、これは GitHub アプリが入っていない意味ではない）。受け皿にブランチ保護をかけるならレビュー必須にしない——必須にすると自動マージが通らず、AUTO_MERGE: 'true' でも毎回管理者がマージすることになる。

   既に受け皿を設置済みの顧客には、雛形の差し替えを個別に案内する [REQUIRED]。 雛形を直しても、設置済みのワークフローは顧客のリポジトリにあるので自動では直らない。設置済みの受け皿には、少なくとも次の 3 つを個別に反映してもらう。(a) 上位 env の GH_REPO（無いと gh が基準リポジトリに上流を選び、追従 PR が上流へ立ち、既存 PR の判定も常に空を返す）。(b) 本節の PR 経由の反映（直接 push で反映する旧版のままだと、受け皿の main は進むのに配信が発火しない）。(c) permissions: に contents: write と pull-requests: write が揃っていること（PR の作成とマージの両方に要る。片方だけだと、PR は立つのにマージで落ちるという分かりにくい止まり方をする）。当社が設置した受け皿も同じ対象なので、雛形を改訂したら設置済みの棚卸しを併せて行う。

   複製が上流から遅れている状態で雛形を導入するときは、先に main を上流へ早送りしてから雛形を載せる（git merge --ff-only upstream/main → git push origin main → 雛形のコミット）。逆順にすると初回だけ余分な PR を挟む。早送りは PR を経ないので自動同期が発火しないため、初回は管理者が組織設定 > プラグインで「再同期」を押す（押しても不足は起きないので、発火したか分からないときは押す）。

   雛形を置いたあとは git push --mirror による追従を使わない（受け皿を丸ごと上書きするためワークフローごと消える）。初回の複製までは従来どおりで、雛形はそのあとに追加する。

   利用者側でも版の遅れに気づけるようにしてある。 追従が止まっても利用者の画面には何も出ないため、TI のスキルはセッション最初に同梱の版と公開されている最新版を照合し、古ければ 1 行告げる（ti-core references/version-freshness.md）。管理者側の PR 滞留通知と利用者側の自己診断は両輪で、どちらか一方では止まったことに気づけない。

   代替＝各利用者が自分で導入（顧客が GitHub を使えない場合のみ）: カスタマイズ → プラグイン → 個人プラグインの「＋」→ マーケットプレイスを追加 → リポジトリから追加 → 公開リポジトリを指定 → プラグインをインストール。この経路には自動更新が無い [REQUIRED]——「自動的に同期」は組織マーケットプレイスにしかなく、個人で追加したマーケットプレイスは利用者が「更新」を押すまで古いままになる。実際に、この経路で入れていた手元が 7 日間更新されず、そのあいだに公開側が 4 版進んでいた例がある（当社で実測。手元 0.18.0 に対し公開 0.22.0）。この例が示すのは「更新を押さなければ古いまま」ということだけで、受け皿から先の同期が発火したかどうかとは無関係——経路が違うので、上の PR 経由の話の証拠として読まない。版がそろわず、全員が最新かを管理者が把握できないことと併せて、既定にしない理由になる。やむを得ずこの経路を採るなら、更新を押す担当と頻度を運用で決めておく。

   経路によって利用者側の見え方が変わるので、案内の文面を混ぜない。 全社一括では組織管理となり、版の表示も更新ボタンも無く最終更新日だけが見える（カスタマイズもグレーアウト）。各自導入ではプラグイン詳細に「ソース／バージョン／更新ボタン」があり利用者が自分で更新できる。ただしそこに出る「バージョン」は配信の通し番号であって、配布物の版（plugin.json の x.y.z）ではない（当社で実測）。どちらの経路でも、利用者は画面から自分の版を確かめられない。 版の照合を画面でなく同梱ファイルの読み取りで行う理由がここにある（ti-core references/version-freshness.md）。どの版が入っているかは管理者側で把握する。

10. 組織セットアップ（AI: データ構造マップ生成・必要なカスタマイズ生成、反映前に人が承認）。

11. （必要時）ローカルスクリプト実行用の本人接続（大量データ移行／MCP に無い任意 API 操作・§4）。

各段でつまずいたら、原因を切り分けて次の操作を案内する。反映待ち（接続用アプリの有効化に時間がかかる等）は待って再試行する。

4. ローカルスクリプト実行用の本人接続（api スコープ・要否判断）

会話（標準 MCP）による数件の読み書きを超える処理は、ローカルスクリプトで行う。用途は 2 系統ある。

• 業務データの一括移行・大量投入（別環境からの一括移行・期首残高・大量デモデータ）＝ ti-data-load
• 標準 MCP ツールに無い任意 API 操作（商談等へのファイル添付＋公開リンク発行、大容量/バイナリ授受、Bulk/Composite、独自 Apex REST）＝ ti-local-automation

スクリプトが org へつなぐために、**標準 MCP とは別の OAuth 本人接続（api スコープ）を使う（本人の権限に限定・共有サービスアカウントは作らない・トークンは OS キーチェーンに保管）。この接続は api スコープの専用 ECA（MCP 用 ECA とは別に立てる。MCP は読み書き両用で 1 つのまま）＋権限セットで対象者を絞る＋ループバックの本人 OAuthで構成する。ECA 作成・権限セット付与は管理者が一度行い、各利用者は初回のみブラウザで本人認証する。接続の登録・認証（ECA・本人 OAuth・キーチェーン保管）の具体手順は本スキルが持つ（下記 references/api-eca-setup.md）。各能力スキル（ti-data-load／ti-local-automation）が持つのはスクリプト実行の具体（移行の型・任意 API レシピ）**であり、接続手順は再掲しない。

• 本スキルの役割は要否判断と接続準備の案内だけ: 日常の参照・少量更新なら不要。一括処理や MCP に無い操作を使うときのみ、この追加接続の準備と実行を該当能力スキルへ引き継ぐ。
• api スコープ専用 ECA の作成手順（管理者・組織で 1 回・フェイルクローズ）は references/api-eca-setup.md（ECA 作成・対象者ゲート・コンシューマ鍵・権限セットでの展開・停止・読み取り側の制約）。
• パッケージ同梱のECAと同じものを手で作ってもらう案内を書く直前は references/api-eca-setup.md §注意（読み取り側の制約） を読む [REQUIRED]。 購読側から読み出せるのは許可された範囲までで、接続先のURL・本人確認や秘密情報の要否・許可の方針は返らない。取れた範囲だけで案内を書くと、相手の組織で動かない設定ができる。

ECA の reference は 2 本あり、用途が違う。取り違えるとどちらも動かない。

5. 契約終了時の後始末（案内）

• 使えなくなること: Atlas／Knowledge の配信停止により TI 支援機能は継続しない。利用可否を決めるのは配布物へのアクセスではなく配信で、配布物そのものは公開されたまま残る。
• データ: 顧客 org 内にそのまま残る。業務データはツバイソが保持も経由もしていないため、ツバイソ側に残らない。
• 後始末: 接続（コネクタ・接続用アプリ・ローカルスクリプト用接続）は顧客側の設定なので、切断・無効化で AI アクセスを遮断できる（推奨）。ただし references/f0-login-eca-setup.md の経路を使っている組織は顧客側の操作だけで完結しない——当社へ預けたコンシューマ鍵と秘密が当社側に登録されているので、その削除をサポートへ依頼するところまでを案内する。
• 配布物と複製物の扱いは利用条件が定める [REQUIRED]: 配布物同梱の LICENSE.md 第 3 項が、契約終了時に使用を停止し複製物を削除することを定めている。配布用の受け皿（顧客の private リポジトリ）はこの「複製物」に当たるので、「顧客資産だから不要になれば削除してよい」という任意の案内をしない。案内は「利用を停止し、受け皿を含む複製物を削除する。手順は AI が案内する」とし、条件そのものは LICENSE.md へ委ねて本スキルで言い換えない（言い換えると条件が緩んだ版が独り歩きする）。

発火点（いつ・何を読む/呼ぶ）

製品知識の引き当て（ti-core references/knowledge-lookup.md）は本表に置いていない。 本スキルの射程は接続・環境セットアップで、製品の業務仕様・操作手順の可否を答える場面を持たないため。接続手順については本スキル自身が正本であることが、同 reference の §分担 に自前の行として書かれている。

原則

• AI が下書き・設定、人が承認・本人認証。本人確認・権限付与・org 反映は人が行う。
• 安全を主眼に。最小権限・既定読み取り・承認ゲート・削除しない・データは顧客 org 内。各段で目的（安全観点）を伝える。
• クライアントに固定しない。Claude は参照実装。標準 MCP＋Markdown 手順で可搬に保ち、他クライアントへは変換で渡す。
• 本スキルは進行。能力（参照・投入・メタデータ）は層2へ委譲し、ここには再掲しない。
• 利用者向け出力に内部識別子（API 名・SOQL・レコード ID・具体的な鍵値）を出さない（ti-core references/output-discipline.md）。ただし Client ID（接続キー）は接続元を示す非秘匿の識別子であり、コネクタ設定のため管理者へ提示・配布してよい（秘匿対象はクライアントシークレット等の認証情報）。