docs(i18n): translate build/automation/ and build/interface/ into ja (#388, PR 2 of 7)

content/docs/build/automation/index.ja.mdx

@@ -0,0 +1,43 @@
+---
+title: 自動化
+seoTitle: "自動化：フロー、ワークフロー、承認"
+description: 用途に合ったツールを選びます。手順にはフロー、状態にはワークフロー、人による承認には承認を使います。
+editions: [community, cloud, enterprise]
+translation:
+  source_sha: e39ead174c229520946d302d63cc2c7e6903c12d87048df02a15aed0b5ab0a84
+  guide_rev: 1
+  mode: auto
+---
+
+**自動化は、ビジネスロジックをアプリケーションコードに散らばらせるのではなく、ランタイムが実行するメタデータとして、データモデルに宣言的に結び付けます。** 3 つのツールがその範囲をカバーしており、最初に正しいものを選べば、後で作り直す手間が省けます。
+
+## どれが必要か [#which-one-do-i-need]
+
+| 必要なもの | 使うもの | 読むもの |
+|---|---|---|
+| 「X が起きたら Y をする」：レコードの変更、スケジュール、ボタンのクリックで実行される手順 | **フロー** | [フロー](/docs/build/automation/flows) |
+| 「このレコードはこれらの状態だけを通って進める」：管理されたライフサイクル | **ワークフロー**（ステートマシン） | [ワークフロー](/docs/build/automation/workflows) |
+| 「先に進む前に人が承認しなければならない」：ルーティングされる人の判断 | **承認** | [承認](/docs/build/automation/approvals) |
+
+目安：**状態**はワークフローで、**手順**はフローでモデル化します。承認は別のエンジンではありません。承認とは、人が判断するまで承認ノードで一時停止するフローです。
+
+## どう組み合わせるか [#how-they-combine]
+
+3 つは競合せず、組み合わせて使います。
+
+- **ワークフロー**は、そもそもどのライフサイクル遷移が有効かを制約します。状態とその間の移動だけで、それ以外は扱いません。
+- **フロー**は、それらの遷移の前後で副作用を実行します。メールを送る、レコードを更新する、外部サービスを呼び出す、待機する、分岐する、などです。
+- フロー内の**承認ノード**は、承認者が操作するまで実行を止め、その後、承認または却下の分岐に沿って再開します。
+
+つまり「ケースが new → assigned → resolved と進む」はワークフローであり、「エスカレーションされたらマネージャーに通知する」はフローであり、「5 万ドルを超える値引きには財務マネージャーの承認が必要」は承認ノードを持つフローです。
+
+> **ヒント：** 要求が「X が起きたら Y をする」と読めるならフローです。「このレコードは決して状態を飛ばしてはならない」と読めるならワークフローです。ここから始めれば、選択を誤ることはほとんどありません。
+
+## 次に進む [#where-to-go-next]
+
+| ページ | 理由 |
+|---|---|
+| [フロー](/docs/build/automation/flows) | フローの完全なリファレンス：トリガー、ステップの種類、エラー処理、CEL |
+| [ワークフロー](/docs/build/automation/workflows) | 厳密なライフサイクルのための、状態とその許可された遷移 |
+| [承認](/docs/build/automation/approvals) | 承認ノード、実行アイデンティティ、承認者の体験 |
+| [CEL 式](/docs/reference/cel) | 条件と検証ルールで使われる式言語 |

content/docs/build/automation/workflows.ja.mdx

@@ -0,0 +1,181 @@
+---
+title: ワークフロー
+seoTitle: "ワークフロー：ステートマシンとしてのレコードのライフサイクル"
+description: レコードのライフサイクルをステートマシンとしてモデル化します。レコードが取りうる状態、その間で許される移動、そしてフローの方がうまくできることは何も含めません。
+editions: [community, cloud, enterprise]
+translation:
+  source_sha: 7ec55c7f19bcf4f40b34dc0d852ea4cf3534169ad263dbdff0f1ed34fbb0c600
+  guide_rev: 1
+  mode: auto
+---
+
+**ワークフローは、レコードのライフサイクルを有限ステートマシンとしてモデル化します。レコードが取りうる状態と、その間で許される移動です。** オブジェクト上の `state_machine` 検証ルールとして宣言し、状態フィールドへのすべての書き込みがそれに照らしてチェックされます。中心となる要件が「このオブジェクトはこれらの状態だけを通って進める」であるときに使います。
+
+Salesforce 風の独立した Workflow Rule という作成タイプはありません。かつての「ワークフロー」の概念は、きれいに 2 つに分かれます。
+
+- **`state_machine` 検証ルール**：厳密なライフサイクル遷移のため。このページです。
+- **[フロー](/docs/build/automation/flows)**：イベントで起動する、またはスケジュールされた自動化のため。[承認](/docs/build/automation/approvals)による一時停止も含みます。
+
+## ワークフローとフロー [#workflows-vs-flows]
+
+| | ワークフロー（ステートマシン） | フロー |
+|---|---|---|
+| モデル化するもの | *状態*：レコードがライフサイクルのどこにあるか | *手順*：何かが起きたときに何が起こるか |
+| 答える問い | 「この遷移は今許されるか？」 | 「それについて何をするか？」 |
+| 形 | 状態フィールドと、許される移動の表 | ノードとエッジ：トリガー、アクション、分岐 |
+| 副作用 | なし。制約するだけです | すべて：メール、更新、HTTP、待機 |
+
+両者は組み合わせて使います。ステートマシンが遷移を制約し、通知、レコード更新、外部呼び出しが必要なときには、フローがその前後で副作用を実行します。
+
+## ステートマシンを定義する [#define-a-state-machine]
+
+`new → assigned → resolved` と進まなければならず、エスカレーションの経路を持つサポートケースです。ステートマシンはオブジェクトの `validations` のひとつです。
+
+```ts
+import { P } from '@objectstack/spec';
+import { ObjectSchema, Field } from '@objectstack/spec/data';
+
+export const SupportCase = ObjectSchema.create({
+  name: 'support_case',
+  label: 'Support Case',
+  fields: {
+    status: Field.select({
+      label: 'Status',
+      required: true,
+      options: [
+        { label: 'New', value: 'new', default: true },
+        { label: 'Assigned', value: 'assigned' },
+        { label: 'Escalated', value: 'escalated' },
+        { label: 'Resolved', value: 'resolved' },
+      ],
+    }),
+    resolution: Field.textarea({
+      label: 'Resolution',
+      requiredWhen: P`record.status == 'resolved'`,  // no resolved case without one
+    }),
+  },
+  validations: [
+    {
+      type: 'state_machine',
+      name: 'case_lifecycle',
+      field: 'status',
+      message: 'This status change is not allowed.',
+      initialStates: ['new'],
+      transitions: {
+        new: ['assigned'],
+        assigned: ['resolved', 'escalated'],
+        escalated: ['resolved'],
+        resolved: [],
+      },
+    },
+  ],
+});
+```
+
+これを契約として読みます。ケースは `new` として作成され、`new` のケースは担当割り当てしかできません。`assigned` のケースは解決またはエスカレーションでき、エスカレーションされたケースは解決できます。`resolved` には何も列挙されていないので、それ以上は何も移動させられません。ステータスが `resolved` のときは `resolution` が必須なので、それなしでケースを解決する書き込みは拒否されます。
+
+## 構成 [#anatomy]
+
+| キー | 宣言するもの |
+|---|---|
+| `type: 'state_machine'` | この検証ルールがステートマシンであること |
+| `name` | ルールの識別子（snake_case） |
+| `field` | ルールが管理する状態フィールド |
+| `transitions` | 各状態 → 移動できる状態のマップ。レコードの更新時にチェックされます |
+| `initialStates` | レコードを作成できる状態。挿入時にチェックされます |
+| `message` | 拒否された書き込みが返すエラー |
+
+このルールは、すべての検証ルールに共通するキー `severity`、`events`、`active`、`priority` も受け付けます。
+
+### 最終状態 [#final-states]
+
+リストが空の状態は最終状態で、そこから出るすべての移動が拒否されます。キーがまったくない状態は最終状態ではありません。そこではチェックに判断材料がなく、書き込みを通してしまうので、「最終」を意味するときは `[]` を宣言してください。
+
+### 遷移の条件 [#conditions-on-a-transition]
+
+`state_machine` ルールには遷移ごとのガードがありません。移動を条件付きにするには、プラットフォームが強制する場所に条件を置きます。
+
+- **ある状態に必要な値**：上の `resolution` のように、そのフィールドに `requiredWhen` を付けます。値なしでその状態に入る書き込みを拒否し、ルールより前から存在する行には手を付けません。
+- **それ以外すべて**：同じ `validations` 配列に、兄弟の `script` または `conditional` 検証ルール（CEL の述語）を置きます。
+
+### イベントではなく書き込み [#writes-not-events]
+
+マシンは状態フィールドへの書き込み時にチェックされます。`status` を現在の値の下に列挙されていない値に変える更新は拒否され、`initialStates` 以外での挿入も同様です。宣言すべき名前付きイベントはありません。正当な移動の表がマシンのすべてです。
+
+> **ヒント：** マシンは最小限に保ちます。状態とその間の移動だけです。「そしてメールを送る」と言いたくなった瞬間、ワークフローの領域を離れています。その副作用は、遷移に反応する[フロー](/docs/build/automation/flows)に置いてください。
+
+## 副作用はフローに置く [#side-effects-belong-in-flows]
+
+ステートマシンは有効な遷移を記述するだけで、それ以外は何もしません。遷移で何かを*する*必要があるとき（営業に通知する、クローズ日を記録する、外部システムを呼び出す）は、マシンとレコード変更で起動するフローを組み合わせます。
+
+```ts
+export const dealClosedWon = defineFlow({
+  name: 'deal_closed_won',
+  label: 'Deal closed won',
+  type: 'record_change',
+  status: 'active',
+  nodes: [
+    {
+      id: 'start',
+      type: 'start',
+      label: 'Stage moved to closed won',
+      config: {
+        triggerType: 'record-after-update',
+        objectName: 'opportunity',
+        condition: "record.stage == 'closed_won' && previous.stage != 'closed_won'",
+      },
+    },
+    {
+      id: 'set_closed_date',
+      type: 'update_record',
+      label: 'Set Closed Date',
+      config: {
+        objectName: 'opportunity',
+        filter: { id: '{record.id}' },
+        fields: { closed_date: '{TODAY()}' },
+      },
+    },
+    {
+      id: 'notify_sales',
+      type: 'notify',
+      label: 'Notify Sales',
+      config: { recipients: '{record.owner}', title: 'Deal won: {record.name}' },
+    },
+    { id: 'end', type: 'end', label: 'End' },
+  ],
+  edges: [
+    { id: 'e1', source: 'start', target: 'set_closed_date' },
+    { id: 'e2', source: 'set_closed_date', target: 'notify_sales' },
+    { id: 'e3', source: 'notify_sales', target: 'end' },
+  ],
+});
+```
+
+マシンは商談が正当に `closed_won` へ*到達した*ことを保証し、フローはその後に起こることを処理します。上のような条件は CEL 式です。[CEL](/docs/reference/cel) を参照してください。
+
+## ワークフロールールからの移行 [#migrating-from-workflow-rules]
+
+Workflow Rules を持つプラットフォームから来た場合の対応は次のとおりです。
+
+| 旧来の概念 | 現在の対応するもの |
+|---|---|
+| Workflow Rule | フロー |
+| 時間トリガー（「日付の N 日前/後」） | 相対時間トリガー：フローの開始ノードの `config.timeRelative`（16.0、[フロー](/docs/build/automation/flows)を参照） |
+| 時間トリガー（固定時刻） | スケジュールフロー |
+| 項目自動更新アクション | `update_record` ノード |
+| メールアラート | `notify` ノード |
+| HTTP 呼び出し | `http` ノード |
+| 承認プロセス | 1 つ以上の `approval` ノードを持つフロー |
+
+判断の基準：旧ルールが「X が起きたら Y をする」なら、小さなフローとしてモデル化します。「日付フィールドの N 日前/後に Y をする」なら、相対時間トリガーを宣言します。レコード変更フローに日付が等しいという条件を付けてはいけません。それはレコードがたまたま変更されたときにしか評価されないからです。「このレコードは管理された状態を通って進まなければならない」なら、`state_machine` 検証ルールを宣言し、副作用にはフローを使います。
+
+## 次に進む [#where-to-go-next]
+
+| ページ | 理由 |
+|---|---|
+| [フロー](/docs/build/automation/flows) | 遷移の前後の副作用：トリガー、ステップ、エラー処理 |
+| [承認](/docs/build/automation/approvals) | フロー内の一時停止としての、人による承認 |
+| [検証ルール](/docs/build/data/validation-rules) | ステートマシンが属するルールの系統 |
+| [CEL 式](/docs/reference/cel) | `requiredWhen`、検証ルール、フロー条件の背後にある言語 |
+| [データモデリング](/docs/build/data) | ライフサイクルを制約するオブジェクト |
+| [自動化の概要](/docs/build/automation) | 選び方：フロー、ワークフロー、承認 |