これを比較的直感に反する方法で機能させることができました。(少なくとも、Runbook をワーカーにコピーするために依存関係の実行のために非グラフ ワークフロー Runbook を解析する方法とは直感に反します)。
Runbook をキャンバスに追加するのではなく、MyCodeActivity のコード エディター構成で別の Runbook への呼び出しを追加するだけです。
Orchestrator.GraphRunbook.Model.dll (Azure Automation Graphical Authoring SDK) にバンドルされている ReadMe.docx に基づいて、ここでの学習経験、具体的には WRT InlineScript アクティビティ (基本的にコード アクティビティが変換されるもの) と組み合わせて、 InlineScript のコンテキスト内から別の Runbook を実行できるとは思わないでしょう (ReadMe から)。
実行エンジンは提供されたブロックをブラック ボックスとして扱い、非常に基本的な構文チェックを除いて、その内容を分析しようとしません。
.. これは、ネイティブ PS ランブックの場合、ワーカーにコピーされないことを意味します。残念ながら、ピア ワークフロー Runbook の実行をテストしたことはありません (他の場所で参照されていないため、ワーカーにコピーされます)。その理由の 1 つは、InlineScripts 内のコードが依存する Runbook に対して解析されないという前提があったためですが、おそらくそれはネイティブ参照のみの場合です (私にとって疑わしい区別)?
とにかく、上記は回避策のようです。
ただし、Runbook がスクリプト アクティビティ内に閉じ込められるのではなく、デザイン キャンバス (および結果として得られるシリアル化されたモデル) で一級市民として扱われることを望んでいました。依存関係の順序で自動化された CI/CD デプロイの定義。(とは言っても、通常のスクリプトの依存関係チェックについては、すでに大まかなパスを取得しているため、それで十分です。つまり、より多くの解析を行うことを意味します。)