---
name: ti-update
description: PSA/IMA顧客の稼働後のデータ更新全般＝トランザクション（販売・購買・在庫・経費・会計仕訳 等）の作成・更新とマスタの日常メンテを、整合を保って行い（入力支援）、承認前に矛盾を点検して承認者・申請者を助け（承認支援）、承認者本人の明示的な許可を得て承認・却下の操作を代行する（承認操作の代行）能力スキル。TRIGGER when 外部文書（見積・注文書・請求書等）から取引レコードを作る/更新する、在庫・経費・仕訳等を登録する、締め等のトリガ項目を更新する、マスタを日常メンテで追加・修正する、登録結果を入力元と突合検証する、ERPの外にあるデータとERPのあいだでデータを受け渡す、レコードを申請前・承認前にチェックする、承認待ちレコードを点検助言する、承認者本人の許可を得て承認・却下の操作を行う。DO NOT TRIGGER when 初期一括ロード・期首残高・org間の移行投入は ti-data-load、実装形態（Flow/Apex/Anonymous Apex可否・運用移行可否）の判断は ti-lifecycle、帳票レイアウトへの出力は ti-report、導入プロジェクトの工程進行は ti-onboarding、契約前の価値実証・トライアル体験の演出は ti-poc。承認するかどうかの判断はAIが行わない（人間の判断）。承認申請・差戻し・リコール・承認者の再割当の操作も行わない。
version: 0.6.0
updated: 2026-08-05
---

# ti-update — 更新系（入力支援＋承認支援＋承認操作の代行）

PSA/IMA を使う顧客の**稼働後のデータ更新全般**を支援する**能力スキル**。射程は (i) トランザクションデータ全般（販売＝見積・受注・売上→請求→入金／購買＝調達・発注・検収／在庫＝入出庫・在庫移動／経費精算／会計仕訳・支払 等）の作成・更新と、(ii) マスタの稼働後日常メンテ（取引先・商品・税区分・部門・銀行口座 等の1件〜数件の追加・修正）。柱は3本＝**(A)入力支援（＝業務レコードへの唯一の書込）**、**(B)承認支援（人間の承認を助ける読み取りチェック）**、**(C)承認操作の代行（承認者本人の明示的な許可を得て、承認・却下の操作だけを行う）**。

本書は薄い索引に徹する（詳細は必要な reference だけを読む方式）。手順の実体は各 reference にある。

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

| 持つ（更新系の中身） | 持たない（機構・判断＝委譲先） |
|---|---|
| 稼働後のトランザクション作成・更新の入力支援（正規経路・突合検証） | 初期一括ロード・期首残高・org間移行の投入機構＝ ti-data-load |
| マスタの稼働後日常メンテの入力支援（1件〜数件・突合検証） | 書込前の構造ゲート（作れない工程の検出・参照先の有効条件）＝ ti-reference |
| ERP の外にあるものとのあいだの受け渡しに共通する作法 | ERP → 外の向きの参照・集計の実行そのもの＝ ti-reference |
| 申請前/承認前チェックの内包（標準フレーム×会社ポリシー層） | 承認前チェックが引く集計・類似取引のレシピ＝ ti-reference |
| マスタ突合・VR充足の書込前検証・write_action の読み取り | 実装形態の可否判断（Flow/Apex・Anonymous Apex可否・運用移行）＝ ti-lifecycle |
| 承認待ちの捕捉・点検助言・出力規律 | 帳票レイアウトへの出力（データ→PDF）＝ ti-report／工程進行＝ ti-onboarding／契約前の価値実証・体験演出＝ ti-poc |
| 承認者本人の許可を得たうえでの承認・却下の操作代行 | **承認するかどうかの判断＝人間**／承認申請・差戻し・リコール・承認者の再割当＝いずれも行わない |

**主従を崩さない**: 入力支援(A)はトランザクション＋マスタの両方に効く。承認支援(B)は承認プロセスを持つ対象＝主にトランザクションに効き、マスタは承認プロセスがある場合のみ。**業務レコードを書くのは入力支援だけ**（承認支援は読み取り、承認操作の代行(C)が書くのは承認指示の1件で、業務レコードには触れない）。

## 境界（誤発火の決め手）

| 言い回し | 発火先 | 決め手 |
|---|---|---|
| 注文書から受注を作る／在庫・経費・仕訳を登録する（稼働後） | **ti-update** | 稼働後の日常の書込 |
| 取引先を1社追加・商品マスタを1件直す（稼働後の日常メンテ） | **ti-update** | 少量・稼働後メンテ |
| 表計算や既存システムに残っている業務と ERP のあいだでデータをやり取りする | **ti-update**（`external-handover.md`） | 受け渡しに共通する作法。各向きの手順は入力支援と ti-reference |
| このレコードを申請前／承認前にチェックする・これで出してよいか | **ti-update** | レコードの業務妥当性の可否 |
| この受注を承認しておいて／却下しておいて（本人が承認者） | **ti-update**（承認操作の代行） | 承認待ちに対する操作。**実行の前に対象1件ごとの明示的な許可を取る** |
| 承認していいかどうか決めて | **判断はしない** | 判断は承認者本人。AI は点検結果を示すところまで |
| 承認申請を出しておいて／差し戻して／取り消して／別の人に回して | **行わない** | 申請・差戻し・リコール・再割当は射程外。人が画面で行う |
| 外部システムと恒常的に連携させたい | ti-lifecycle | 都度の受け渡しではなく定常運用の機構＝実装形態の判断 |
| マスタを全量移行・期首残高を入れる・org間コピー（初期/大量） | ti-data-load | 初期・大量・移行の投入 |
| この要件をFlow/Apexで作るか・運用に持っていってよいか | ti-lifecycle | 可否の対象＝実装形態 |
| 帳票のレイアウトを直す | ti-report | 出力方向（データ→PDF） |
| 契約前トライアルで多軸集計・体験を見せる（PoC演出） | ti-poc | 契約前の価値実証・体験演出 |

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

| チェックポイント | 読む／呼ぶ | 渡す・確認するもの |
|---|---|---|
| 外部文書から取引レコードを作る・締め等のトリガ項目を更新する・マスタを日常メンテする・登録結果を突合検証する | `references/input-support.md` | 入力元・対象オブジェクト・マスタ突合結果・型別切替 |
| ERP の外にあるデータと ERP のあいだでデータを受け渡す（据え置いた業務・表計算・外部システムとの往復） | `references/external-handover.md` | 向き（外→ERP／ERP→外）・出所・時点・持ち出しの範囲 |
| 対象プロセス・マスタが未実証（購買/在庫/経費/仕訳/マスタ）か確認して段階拡張する・計画を逆算生成する | `references/process-coverage.md` | 対象・着手時確認軸・依存グラフ |
| レコードを申請前／承認前／締め前／無効前にチェックする・承認待ちを捕捉して点検助言する | `references/approval-support.md` | 対象レコード・標準フレーム(a〜f)・会社ポリシー・承認者観点・ロック前フェーズ |
| **承認者本人の許可を得て承認・却下の操作を代行する** | `references/approval-execution.md` | 対象・決定（承認/却下）・理由・**本人の明示的な許可** |
| 転記由来項目が空でマスタ不備が疑われる／その場でマスタを直して取引へ戻す | `references/approval-support.md §転記由来項目の遡及2段判定` ＋ `references/input-support.md §マスタ不備のその場修正ループ` | 対象項目・転記元マスタ・不足値の人間確認 |
| 隣接スキルとの境界を判定する・書込前ゲート/参照レシピの委譲先を確認する | `references/boundaries-and-gates.md` | 局面（初期/稼働後）・量・委譲先 |
| 書込前の構造ゲート（作れない工程の検出・参照先の有効条件） | ti-reference の書込前ゲート（write-index 機能） | 対象オブジェクト・参照先の有効性 |
| 承認前チェックの集計・類似取引を引く | ti-reference のレシピ（Atlas MCP 配信） | 利益率・過去取引の引き当て軸 |
| 現状仕様を往復で詰める瞬間（突合結果の提示・点検助言の往復・承認の許可の往復） | ti-core `references/spec-roundtrip.md` | 差分・選択肢・前提 |
| 依頼された操作の実行経路が使えるか確かめる瞬間（権限・接続で止まった／組織で初めて行う） | ti-core `references/capability-preflight.md` | 依頼の内容・不足している器 |
| org へ書き込む直前（作成・トリガ項目更新・マスタ書込） | ti-core `references/safety-gate.md` | 対象・承認ドラフト・PIIマスキング |
| 段階拡張の穴・サーバーAPI未開放・意味定義の不足に気づいた瞬間 | ti-core `references/feedback.md` | 不足の内容 |
| 一次解決で解けず利用者が未解決のまま／繰り返し詰まると判定した瞬間 | ti-core `references/support-escalation.md` | 本人の許可・再現手順（PII・業務データ本体・認証情報は載せない） |

> 本文中の能力スキル名（ti-reference・ti-metadata・ti-data-load 等）は配置済みで、フォルダ名＝正準名として辿れる（ti-data-load は `tsubaiso-data-migration` からの改称先）。書込前ゲート・参照レシピの提供元は ti-reference。書込前ゲートは ti-reference の参照ファイル `references/write-index.md`（実体＝Atlas MCP `atlas_write_seam`）を発火点で参照する（`boundaries-and-gates.md` から案内）。

## reference 索引

| reference | 何を定義するか |
|---|---|
| `references/input-support.md` | 正規経路（項目更新→自動起動フロー委譲・承認の判断は人間）／書込基盤のUI同等化（本命＝サーバーAPI開放・暫定＝直接書込＋突合）／マスタ突合・VR充足の書込前検証（トランザクション＋マスタ）／マスタ不備のその場修正ループ（承認支援との接続）／型別切替／親子一括作成I/F／添付／write_action の読み取りと書込計画への利用 |
| `references/external-handover.md` | ERP の外にあるものとのあいだの受け渡しに共通する作法（外→ERP は入力支援、ERP→外は ti-reference へ委譲し、ここは共通の作法だけを持つ）／出所を残す・時点を付ける・持ち出しは本人権限内・外を正としない・「つないだ」と言わない／詰まりどころ／記録の限界 |
| `references/approval-support.md` | 承認真実源の捕捉／承認前・申請前チェックの2層構造（標準フレーム(a〜f)×会社ポリシー層）／転記由来項目の遡及2段判定（マスタ不備の根本原因検出）／標準Flow非依存／ロック前4フェーズ（申請前/承認前/締め前/無効前）／集約スイート（ロック前チェックスイート＝意味定義から引く）／標準フレームの自己完結チェックリスト（スイートが引けないときのフォールバック）／出力規律／不変条件／レポートと監査証跡 |
| `references/approval-execution.md` | 承認操作の代行。技術で守られる資格の境界と守られない「人の判断」の別／対象1件ごとの明示的な許可／点検結果の提示を先に置く順序／却下の理由の必須／行わないこと（申請・差戻し・リコール・再割当・承認状態の直接書換）／詰まりどころ／記録 |
| `references/process-coverage.md` | プロセス網羅（受注ドメインの実体）／段階拡張の対象（購買・在庫・経費・仕訳・マスタ日常メンテ＝着手時の確認軸）／依存グラフと作成計画の逆算生成 |
| `references/boundaries-and-gates.md` | 隣接スキルとの境界（特に ti-data-load＝初期/移行 vs ti-update＝稼働後）／書込前構造ゲートの ti-reference 委譲／承認前チェックの参照レシピの ti-reference 取得／書込本命経路の依存 |

> 会社ポリシーの雛形は `templates/承認前チェック_会社ポリシー_雛形.md` に同梱する（承認前チェックの会社ポリシー層で使う雛形。`references/approval-support.md` から参照する）。

## 原則

- **業務レコードへの書込は入力支援だけ**。AI が業務レコードに書くのは対象レコードの作成と締め等のトリガ項目更新・マスタ日常メンテだけ。後続レコードの生成・承認連鎖はパッケージの自動起動フローへ委譲する。**承認状態の項目を直接書いて承認を偽装しない**（承認・却下は `references/approval-execution.md` の正規経路で行う）。
- **承認するかどうかは人が決め、AI は操作だけを行う**。AI は点検結果を示し、承認者本人の明示的な許可を受けてから操作する。許可は対象1件ごとに取り、包括的な許可は受け付けない。**「人が判断したこと」を担保する仕組みは技術側に無く、この作法だけが歯止め**であることを忘れない。
- **ERP の外から来たものを ERP の正としない**。外の資料と ERP の値が食い違ったとき、どちらが正かは人が決める（`references/external-handover.md`）。
- **中身はここ、機構・判断は他スキル**。書込前の構造ゲート・集計レシピは ti-reference、初期一括/移行は ti-data-load、実装形態の可否は ti-lifecycle。本スキルは発火点でそれらを参照する。
- **本書は薄く保つ**。手順・チェックリストは reference に置き、SKILL.md は索引に徹する。
- **標準は薄く・会社固有は逃がす**。標準フレームは常に異常な普遍ルールだけを持ち、業種・会社で変わるしきい値・必須項目・例外は会社ポリシー層（無ければ標準のみで動く）。
- 利用者向け出力に内部識別子（API名・SOQL・レコードID）を出さない。業務語へ翻訳し、レコードはリンク化する。