/* Page prose (ja) */
"DistributedFourPieces" = "# 4 つの部品\n\n4 つのものが協調して働きます。それぞれに名前を付けておく価値があります。\n\n---\n\n## 1. `distributed actor` そのもの\n\n型そのものです。ローカル actor と同じく、分離された状態を所有します。ローカル actor と違って、actor システムと関連づけられ*なければならず*、他のプロセスに渡せるアイデンティティを得ます（これについてはすぐ後で説明します）。\n\n---\n\n## 2. `distributed` メソッド\n\nネットワークをまたいで公開するメソッドの部分集合です。そのそれぞれが潜在的な**リモートメッセージ**です。`distributed` と印づけられていないものはすべて、ローカル参照を保持する者だけのプライベートなままです。\n\n---\n\n## 3. `ActorSystem`: トランスポートとランタイム\n\nこれはローカル actor に相当するものがない部品であり、モデル全体の心臓部です。**actor システム**は、実際に actor を見つけ出し、それらの間でメッセージを運ぶランタイムです。アイデンティティを割り当て、引数をシリアライズし、何らかの接続を通じてバイトを送り、向こう側で呼び出しを届けます。\n\nふつうは自分で書くものではありません。既存の実装を使います。2026 年に最も有名なのは、Apple のオープンソースの Distributed Cluster パッケージに含まれる **`ClusterSystem`** で、サーバーサイドの Swift プロセスをクラスターにつなぎます。ツールチェーンには、実際のネットワーキングなしにテストで分散コードを動かすための `LocalTestingDistributedActorSystem` も同梱されています。いずれにせよ、actor システムは*自分で持ち込む依存関係*であり、それこそがこれが Swift Playground で実行できない理由です。\n\nactor を作成するときに、システムを actor に渡します。\n\n```swift\n// `system` is an already-running ClusterSystem.\nlet ledger = Ledger(actorSystem: system)\n```\n\nその `actorSystem:` パラメータは手で書くものではありません。コンパイラがそれを受け取るイニシャライザを合成し、配線してくれます。システムは今やこの actor に対して責任を負います。アイデンティティを与え、そこへメッセージをどう経路づけるかを知っています。\n\n---\n\n## 4. `ID`\n\nactor システムが actor を採用するとき、システム自身の `ActorID` 型から引き出した、*この特定の actor インスタンス*のための一意でシリアライズ可能な名前である **`ID`** を刻印します。ID こそが、別のプロセスから actor を見つけられるようにするものです。\n\n支店 A が、支店 B のサーバー上に存在する元帳の ID を知っていれば、実際のオブジェクトを一度も保持することなく、それへの参照を**解決 (resolve)** し、メソッドの呼び出しを始められます。\n\n```swift\n// Branch A resolves a remote ledger it never constructed.\nlet remoteLedger = try Ledger.resolve(id: knownID, using: system)\ntry await remoteLedger.deposit(50)\n```\n\n`resolve(id:using:)` は actor の状態を取ってきたりコピーしたりはしません。**リモート参照**を返します。これは、あらゆる呼び出しをネットワーク越しに本物の actor へ転送する、ローカルな代役です。状態は支店 B にとどまり、移動するのは*メッセージ*だけです。\n\n[前へ](@previous)  |  4 / 9 ページ  |  [次へ: async と throws](@next)";
