UnifyPort の接続を計画停止する：自動復旧による再起動を防ぐ

UnifyPort のメッセージングアカウントを削除せず、一時的に接続を停止するには、POST /v1/accounts/{account_id}/runtime/stop に {} を送信します。runtime_status: stopped で停止完了を確認してください。stopping は確認を続ける必要があります。実行前に、自動復旧ワーカーへ「意図した停止」であることを伝えなければ、接続が再起動される可能性があります。

要点

• runtime の停止はアカウントを保持します。削除とは別の操作です。
• 接続停止の前に、アプリ側で停止の意図を永続化します。
• 観測した runtime_status と、復旧を許可するかどうかは別の判断です。
• 再接続できても、停止中のメッセージが回収された証拠にはなりません。

正しい復旧処理が、停止の意図に反する場合

たとえば LINE 対応業務の保守で、担当者が接続を停止した直後、監視ワーカーが stopped を読み取り、オンライン維持のために start を呼び出すとします。これは説明用の仮定であり、実際の顧客障害の報告ではありません。個々の API 呼び出しは正しくても、全体として担当者の意図に反します。

必要なのは再ログインではなく、そのアカウントが今オンラインであるべきかという共通の判断です。runtime 復旧ガイド は、オンラインであるべき接続の障害復旧を扱います。計画停止では、その処理の前に許可判定を追加します。

これは新しい API 設定ではありません。アカウントのライフサイクル は、アカウントの status、認証状態、runtime_status を区別しています。ここで提案する停止記録はアプリ独自のデータです。UnifyPort の追加フィールドでも、アカウント status に約束された動作でもありません。

停止する対象を選ぶ

目的	適切な操作対象
メッセージ受信を続けながら CRM 更新や AI 処理を止める	アプリのコンシューマー
アカウントを保持し、ライブ接続を止める	Stop runtime
メッセージングアカウントのリソースを廃止する	別のアカウント削除フロー

下流処理だけの保守なら、webhook メンテナンスの比較 を参照してください。接続停止は永続的なメッセージバッファーではありません。

廃止が目的の場合だけ、アカウント削除ガイド を使います。runtime stop の仕様は、返金、契約の一時停止、プラットフォーム本来のアカウント削除、保存済みメッセージの消去を約束していません。

停止要求より先に、停止の意図を共有する

以下はアプリ設計上の推奨手順です。

1. ワークスペース、account_id、チャネル、担当者、理由を確認し、アカウントと認証状態を別々に取得します。
2. アカウント単位の停止判断を永続化します。復旧ワーカーと予約送信ワーカーが、新しい要求の送信前に必ず確認するようにします。
3. すでに動作中のワーカーと調整します。今保存したフラグでは、送信済みの API 要求を取り消せません。アプリ側のアカウント単位の調整と、進行中操作の確認が必要です。
4. webhook 受信側は稼働させ、到着するイベントを検証・保存します。runtime stop が webhook の処理完了待ちを保証するとは解釈しないでください。
5. 確認済みの停止要求を一度送信し、結果を調べます。

次はアプリの疑似コードであり、SDK の構文や追加エンドポイントではありません。

自動 start または reconnect の前:
    アカウントの現在の運用意図をローカル保存先から読む
    担当者が停止を指定している場合:
        復旧要求を送信しない
    それ以外:
        認証状態と runtime 状態を確認する
        文書化された復旧操作を選ぶ

遅延ジョブや手動復旧ボタンも同じ判定を通します。停止と再開の変更を調整し、古い起動ジョブが後の画面操作だけで再び実行可能にならないようにしてください。

一度停止し、実際の状態を確認する

Stop runtime リファレンス は空の JSON オブジェクトを指定しています。次は未実行の例です。変数には、バックエンドで確認したアカウントと、安全に保管した API キーを設定します。

curl -X POST \
  "https://api.unifyport.ai/v1/accounts/${UNIFYPORT_ACCOUNT_ID}/runtime/stop" \
  -H "X-Api-Key: ${UNIFYPORT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{}'

キーはサーバー側に保持します。HTTP ステータスと取得できた診断情報を記録し、秘密情報はログに残しません。

観測結果	解釈と次の操作
runtime_status: stopped	runtime 層の停止完了。ローカルの停止指定は維持する
runtime_status: stopping	状態遷移中。再確認する
タイムアウト、読み取れない応答	結果不明。追加の変更前に状態を読む
停止指定中なのに running へ変化	競合する start／reconnect 経路を調べ、保守準備完了と表示しない

アカウント取得 または runtime 状態の更新 で照合します。Refresh は状態の同期であり、再起動要求ではありません。確認回数やエスカレーションの方針はアプリで定め、固定の完了時間を仮定しないでください。

公開イベント一覧にない account.stopped を待ってはいけません。ライフサイクル文書では、account.status.updated がすべての要求による状態遷移で届くとは保証していません。受信箱が静かなだけでは停止の証明になりません。

再開は別の確認済み操作にする

送信ジョブを制限したまま、保持されたアカウントの認証状態を確認します。ユーザー操作が必要なら、対応する認証フローを続けます。認証成功時は通常 runtime が自動起動するため、停止中に意図せず再認証を始めないでください。

認証が有効で runtime が停止している場合は、Start runtime を使います。ローカルの停止制御と明示的な再開を調整し、実際に running となるまで確認します。starting は完了ではありません。

滞留ジョブを解放する前に、それぞれが現在も適切かを確認します。管理されたテストメッセージを送り、新しい受信イベントの署名検証と保存を追跡してから、必要なコンシューマーと自動復旧方針を再開します。

UnifyPort の非公式インターフェースは、取り逃したペイロードの再送を保証せず、汎用の REST メッセージ履歴取得 API も提供していません。停止区間は受信欠落の可能性がある期間として記録します。新規メッセージの成功は現在の経路の証明であり、欠落回収の証明ではありません。

FAQ

Stop でアカウントは削除されますか？

いいえ。文書化された操作は runtime を停止し、アカウントを保持します。再起動は別の操作です。

監視ワーカーは stopped のアカウントをすべて起動すべきですか？

いいえ。まず、そのアカウントをオンラインにする意図が現在あるかを確認します。runtime 状態だけでは担当者の意図は分かりません。

停止成功で、送信待ちの返信や webhook 配信は取り消されますか？

そうは仮定できません。アプリのジョブは別途管理します。公開仕様には、送信済み作業の取り消しや webhook の排出完了保証はありません。

停止すると課金も止まりますか？

runtime stop の仕様にはその約束はありません。接続状態を料金変更の証拠にしないでください。

次の作業と出典

Stop runtime と合わせて、アプリ側の復旧許可判定を実装してください。競合する復旧ワーカー、進行中の起動、停止応答の消失、stopping、明示的な再開、古い返信ジョブをテスト対象にします。これは推奨テストであり、実施済みの結果ではありません。

参照確認日：2026-11-04。

• UnifyPort：Stop runtime
• UnifyPort：アカウントのライフサイクル
• UnifyPort：Webhook 配信と復旧の制限