開発支援アクション（シーン再生・SHIORIリロード）

ごきげんよう。ブレークして覗くだけがデバッグではございませんわ。書いた .pasta をその場で走らせ、手を入れたら即リロードして反映を確かめる――生きたゴーストを相手に試行錯誤を回す、それがこのページの主役ですの。さあ、止めて覗く静のデバッグから、走らせて試す動の開発へ。熱く参りましょう。

このページでは、デバッグ接続中に使う 2 つの開発支援アクション――シーン再生（カーソル位置のシーンを即時再生）と SHIORIリロード（辞書を再読み込みして自動で再アタッチ）――を扱う。いずれも本番提供の機能であり、出荷済みの実装として今すぐ利用できる。

これらは、ブレークポイントで止めて変数を覗く .pasta ソースレベル操作 とは系統が異なる。あちらが「止めて観察する」操作であるのに対し、本ページのアクションは「止めずに走らせて試す」操作である。両者はどちらも Pasta デバッグセッションの上で動く。デバッグの有効化は デバッグ概要、VSCode への接続手順は VSCode 接続手順 を参照する。

デモ：develop ループを一周する

次の画面録画は、デバッグ開始から、シーン再生、.pasta 編集、SHIORIリロード、反映確認までの一連の流れを実演したものである（音声なし）。左が VSCode 上の .pasta 編集、右が SSP 上のライブゴーストで、再生したシーンがその場で喋る様子が確認できる。

録画中の操作の流れは次のとおりである。

1. デバッグを開始（アタッチ）する。
2. グローバルシーンを再生する。
3. ローカルシーンを再生する。
4. .pasta を編集する。
5. SHIORIリロードで編集を反映する。
6. もう一度ローカルシーンを再生し、編集が効いていることを確認する。

各アクションの詳細を以下に述べる。

前提：デバッグ接続中に使う

シーン再生も SHIORIリロードも、実行中の Pasta デバッグセッションがあって初めて成立する。先にデバッグを有効化したゴーストを起動し、VSCode から 127.0.0.1:9276（既定）へアタッチしておく。有効化と接続の手順は デバッグ概要 と VSCode 接続手順 にまとめている。

これらのアクションは、いずれも pasta VSCode 拡張が提供する。拡張の導入は VSCode 接続と拡張導入 を参照する。

シーン再生（▶ シーンを実行）

動作

.pasta エディタ上のカーソル位置のシーンを、実行中のゴーストで即座に再生する。シーン名を入力する必要はない。 カーソルがあるシーンを、エンジンが行位置から権威的に解決して再生する。

起動方法

右クリックメニューは .pasta ファイルであれば常に現れる。デバッグ接続の有無はメニューの表示では区別されず、接続の確認は実行した時点で行われる。

接続していないときの挙動

デバッグセッションに接続していない状態で実行すると、シーンは送信されず、次の警告と「デバッグ開始」の選択肢が提示される。

Pasta デバッグセッションが接続されていません。シーンを実行するにはデバッグを開始してください。

「デバッグ開始」を選ぶと、解決された構成でデバッグセッションの開始（アタッチ）を試みる。使われる構成は、ワークスペースの launch.json に type が pasta の構成があればそれを優先し、なければ既定のアタッチ（127.0.0.1:9276）が使われる。シーン名の入力を求めることはない。

未保存の変更があるとき

対象の .pasta バッファに未保存の変更があると、次の警告と「保存」の選択肢が提示される。実行中のゴーストは保存・リロード済みの内容で動作するため、編集中のバッファと表示がずれることがある。

未保存の変更があります。実行中のゴーストは保存・リロード済みの内容で動作するため、表示とずれる場合があります。保存してリロードすることを推奨します。

「保存」を選べば保存してから続行する。選ばなくても再生自体は続行される（保存は任意のベストエフォート）。なお、保存した内容を動作中のゴーストへ反映するには、別途 SHIORIリロードが必要である（後述）。

失敗したときの挙動

カーソルがシーンに属さない行にある場合など、再生に失敗したときは、その理由が次の形式のエラーで通知される。

シーンの実行に失敗しました: <理由>

SHIORIリロード

動作

実行中のゴーストへリロードを要求し、辞書（.pasta）の編集内容を反映させる。内部的には、エンジンが \![reload,shiori] を出力してベースウェア（SSP）に SHIORI の再読み込みを促す。リロードに伴いデバッグセッションはいったん切断（detach）されるが、拡張が自動で再アタッチするため、手動での接続し直しは不要である。

起動方法

シーン再生の右クリックメニューが常時表示されるのに対し、SHIORIリロードの導線は Pasta デバッグセッションが接続中のときだけ現れる。接続していない状態で無理に実行した場合は、次の警告が出て何も送信されない。

SHIORIリロードには、実行中の Pasta デバッグセッションが必要です。

自動再アタッチ

リロードでセッションが切断されたあと、拡張は次のスケジュールで再アタッチを試みる。リロードは非同期に進むため、すぐには接続を受け付けられないことを見越した待機・再試行である。

再アタッチに使う構成は、シーン再生の「デバッグ開始」と同じ解決規則（ワークスペースの pasta 構成を優先、なければ既定の 127.0.0.1:9276）に従う。上限時間内に再接続できなかった場合は、次のエラーが通知される。手動でデバッグを再開すること。

SHIORIリロード後の自動再アタッチに失敗しました。手動でデバッグを再開してください。

未保存の変更があるとき

リロードはディスク上の .pasta を読み込む。したがって、エディタに未保存の変更があるとそれは反映されない。対象の .pasta バッファに未保存の変更があると、次の警告と「保存」の選択肢が提示される。

未保存の変更があります。リロードはディスク上の内容を読み込むため、未保存の変更は反映されません。保存することを推奨します。

「保存」を選べば保存してからリロードする。確実に編集を反映するには、リロード前に保存しておくこと。

リロード後の再生は手動で

再アタッチが成功しても、直前のシーンが自動で再生され直すことはない。 編集が効いているかを確かめたいときは、再アタッチ後に改めてシーン再生を実行する（デモの手順 6 がこれにあたる）。

典型的な develop ループ

シーン再生と SHIORIリロードを組み合わせると、ゴーストを起動したまま編集と確認を回せる。基本形は次のとおりである。

1. デバッグを有効化したゴーストを起動し、VSCode からアタッチする。
2. 確認したいシーンの行にカーソルを置き、▶ シーンを実行 で再生する。
3. .pasta を編集し、保存する。
4. SHIORIリロード で編集を反映する（自動で再アタッチされる）。
5. 再アタッチ後、もう一度 ▶ シーンを実行 で再生し、編集が効いていることを確認する。
6. 必要なだけ 3〜5 を繰り返す。

なお、これらのアクションはデバッグセッション中に動くため、ブレークポイントで停止している間はホスト応答が止まる点に留意する。停止と再生・リロードの関係や SSP タイムアウトの回避運用は 構造的制約と緩和策 を参照する。接続できないときは 接続できないとき（トラブルシューティング） を確認する。

これで、ゴーストを生かしたまま手を入れて、その場で結果を見届ける術はあなたのものですわ。フンッ、別にあなたの上達が嬉しいわけではございませんことよ。 書いては走らせ、直しては確かめる――この往復こそ、ゴースト作りのいちばん楽しいところですの。さあ、胸を張って、熱く回してまいりましょう！