JavaScript 開発者はよく、シンプルでありながら驚くほど奥深い疑問を抱きます。なぜ Promise は一度開始すると止めることができないのか？ 一見すると、これは不足している機能のように感じられます。ネットワークリクエストをキャンセルしたり、タイマーを停止したり、ユーザー操作を中断できるのに、なぜ Promise だけはできないのでしょうか？

その答えは、Promise がどのように設計され、どんな問題を解決するために作られたのかにあります。

Promise の本質を理解する

JavaScript における Promise は、実際の処理そのものではありません。むしろ、将来得られる値の表現です。これは最終的に次のいずれかの状態に落ち着く「コンテナ」のようなものです。

• Fulfilled（成功）
• Rejected（失敗）

一度作成されると、Promise は契約のように振る舞います。次のことを保証します。

1. いずれ必ず状態が確定する。
2. 状態は一度しか確定しない。
3. 登録されたすべてのハンドラに通知される。

この設計は意図的なものです。Promise はタスクを制御しません。結果を観測し、報告するだけです。

核となる理由：Promise は観測者であり、制御者ではない

最大の誤解は、Promise が非同期処理を「実行している」と思われていることです。しかし実際にはそうではありません。

次のコードを見てください。

const promise = new Promise((resolve, reject) => {
  setTimeout(() => resolve("Done!"), 3000);
});

実際の非同期処理（setTimeout）は、ブラウザやランタイム環境によって制御されています。Promise はその結果をラップしているだけです。

もし Promise が停止可能だった場合、内部で動いているすべての処理を制御できなければなりません。しかし、それは現実的ではありません。なぜなら：

• 一部の処理はブラウザによって管理されている。
• 一部は OS によって管理されている。
• 一部は外部（サーバーなど）で実行されている。
• すでに実行が始まっているものもある。

これでは Promise がすべての非同期 API に強く結びつき、柔軟性が失われてしまいます。

不変性と予測可能性

Promise は、一度状態が確定すると不変であるよう設計されています。これにより、次のような強力な保証が得られます。

• キャンセルによる競合状態が発生しない。
• 予期しないサイレントエラーを防ぐ。
• チェーン処理が信頼できる。
• 非同期フローが一貫する。

もし Promise にキャンセル機能が組み込まれていた場合、開発者は中間状態を扱う必要があり、複雑さやバグの原因になります。

例えば：

promise.then(handleResult);
promise.cancel();

この場合、handleResult は実行されるべきでしょうか？ エラーは伝播すべきでしょうか？ 後続の処理は壊れるのでしょうか？

こうした問題は設計を大きく複雑にします。

Promise がキャンセルできないことで、JavaScript は予測可能な振る舞いを保っています。

関心の分離（Separation of Concerns）

JavaScript はキャンセルを Promise に組み込む代わりに、責任を分離することを推奨しています。

• Promise は結果の受け渡しを担当する。
• 非同期処理 は実行とキャンセルを担当する。

これにより、よりクリーンなアーキテクチャになります。

例えば、ネットワークリクエストは専用の API でキャンセルできます。

const controller = new AbortController();

fetch(url, { signal: controller.signal });
controller.abort();

ここでは：

• リクエスト自体はキャンセルされる。
• Promise は単に reject される。

このパターンにより、Promise はシンプルで汎用的なまま保たれます。

なぜこれは実際には良いことなのか

最初は Promise を止められないことが不便に感じられるかもしれません。しかし実際には大きな利点があります。

• 一貫した非同期フロー Promise は必ず resolve または reject されると信頼できます。

• デバッグが容易 実行途中で「消された」かどうかを追跡する必要がありません。

• 再利用可能で合成しやすいコード 外部の影響を気にせず、チェーンや組み合わせが可能です。

• プラットフォームの柔軟性 非同期 API ごとに独自のキャンセル手段を実装できます。

キャンセル可能な Promise はどうなったのか？

過去には Promise 自体にキャンセル機能を追加する提案もありましたが、次の理由で却下されました。

• 状態管理が複雑になる。
• 既存コードとの互換性が壊れる。
• デバッグが困難になる。

代わりに、現代の JavaScript では シグナルやコントローラ が推奨されています。

• AbortController
• カスタムキャンセルトークン
• Observable ベースのパターン

これらにより、Promise のシンプルさを保ちながらキャンセルが可能になります。

本当の結論

Promise が停止できないのは、そもそも非同期処理を制御する目的で作られていないからです。Promise は実行を管理するのではなく、結果を表現するために存在します。

この設計により、JavaScript の非同期プログラミングは：

• 予測可能
• 再利用・合成しやすい
• スケーラブル
• 理解しやすい

つまり、Promise を止める必要はありません。本当に止めるべきなのは、その背後で動いている処理です。

なぜ Promise がキャンセルできないのかを理解することで、より良い非同期コードを書けるようになります。設計に逆らうのではなく、それを受け入れましょう。適切なレイヤーに適切なツールを使うことが重要です。

• Promise は結果を扱う。
• 非同期 API は制御を扱う。
• キャンセルを考慮したアーキテクチャを設計する。

この視点に切り替えると、JavaScript の非同期モデルは制限ではなく、意図的に洗練されたものだと分かるはずです。