TypeScriptのyieldを使わないでジェネレーターと同等のループ処理を実装する代替案

TypeScriptにおけるジェネレーター（function* と yield）は、非同期処理や逐次的な値生成をシンプルに表現できる強力な機能です。
しかし、実務では「yield を使わずに同等のループ制御や状態遷移を実現したい」という場面も少なくありません。
例えば、トランスパイル制約のある環境や、ランタイム依存を極力減らしたいケースでは、ジェネレーター構文そのものが選択肢から外れることがあります。

本記事では、ジェネレーターに依存しないループ制御の代替設計について、コンピューターサイエンスの観点から整理し、実装パターンとして再現可能な方法を解説します。

主に扱うアプローチは以下の通りです。

クロージャを用いた手続き的ステートマシン
明示的な状態オブジェクトによるイテレーション制御
コールバックベースの逐次処理モデル
イミュータブルな配列変換による擬似ジェネレーション

例えば、状態オブジェクトを用いる場合は次のように設計できます。

type State<T> = {
  value: T;
  next: () => State<T> | null;
};

このような設計により、yield を使わずとも「次の値へ進む」というジェネレーター的振る舞いを明示的に制御できます。

また、従来の for...of やジェネレーターに依存した設計と比較すると、制御フローが明確になり、デバッグ性やテスト容易性が向上する場合もあります。
逆に、抽象度が下がることでコード量が増えるというトレードオフも存在します。

本記事ではこれらのメリット・デメリットを整理しながら、実務で使える代替パターンを体系的に解説していきます。

なぜTypeScriptでyieldを使わない実装が必要なのか
JavaScript/TypeScriptにおけるジェネレーターの基礎
yield構文の制約と実務上の課題
クロージャを使ったステートマシン実装
コールバックとPromiseによる逐次処理設計
配列とイミュータブル設計による疑似ジェネレーター
ジェネレーター代替パターンの比較と設計指針
まとめ：yieldなしでループ制御を設計するポイント

なぜTypeScriptでyieldを使わない実装が必要なのか

TypeScriptにおけるジェネレーター構文（function* と yield）は、逐次的な値生成や中断可能なフロー制御を直感的に記述できる強力な仕組みです。
しかし実務の現場では、この構文をあえて避けた設計が求められるケースが一定数存在します。
その背景には、単なる好みではなく、実行環境・保守性・アーキテクチャ制約といった現実的な要因があります。

まず最も大きい理由の一つは、トランスパイル後の互換性問題です。
TypeScriptでジェネレーターを使用すると、コンパイル結果は複雑なヘルパー関数や状態機械へ変換されます。
この変換はランタイム依存を増やし、特に古いJavaScript環境や軽量ランタイムでは予期しない制約となることがあります。

例えば、以下のようなコードは一見シンプルですが：

function* generator() {
  yield 1;
  yield 2;
  yield 3;
}

コンパイル後は内部的に状態管理関数へ展開され、実行環境によってはサイズ増加やデバッグの複雑化を引き起こします。
特に組み込み環境やエッジコンピューティングでは、このオーバーヘッドが無視できない場合があります。

次に重要なのは、制御フローの可視性です。
yield は処理の中断ポイントを暗黙的に作るため、コードの流れが非局所的になります。
小規模な処理では問題になりませんが、複雑な業務ロジックになると以下のような課題が生じます。

状態の遷移点が関数全体に散らばる
デバッグ時に現在の実行位置が追いにくい
テスト時に中間状態の再現が難しい

これにより、コードの保守性が低下する可能性があります。

さらに、アーキテクチャの観点からも制約があります。
例えばマイクロサービスやイベント駆動アーキテクチャでは、処理の中断・再開を言語機能に依存するよりも、明示的な状態管理として設計した方が適切な場合があります。

ここで重要なのは、「ジェネレーターの否定」ではなく、「責務の明確化」です。
つまり、処理の状態遷移を言語機能に隠蔽するのではなく、明示的なデータ構造として扱う設計思想への移行です。

また、チーム開発においては知識レベルのばらつきも無視できません。
yield は直感的に見えて、実は実行モデルの理解が必要なため、以下のような認知負荷が発生します。

実行の再開ポイントの理解
イテレーター状態の保持メカニズム
呼び出し側との契約の暗黙性

このため、特に大規模チームでは「明示的なループ制御」の方がコードレビューやオンボーディングの効率が高くなる傾向があります。

最後に、近年のフロントエンド・バックエンド開発では、非同期処理の主流がasync/awaitへ完全に移行しています。
この結果として、ジェネレーターの役割は限定的になりつつあり、代替設計の価値が相対的に高まっています。

要するに、yield を使わない実装は単なる代替手段ではなく、次のような目的を持った設計選択です。

実行環境依存を減らす
制御フローを明示化する
保守性とテスト容易性を高める

この前提を理解すると、次章以降で扱うクロージャや状態オブジェクトによる代替パターンの意義がより明確になります。

JavaScript/TypeScriptにおけるジェネレーターの基礎

JavaScriptおよびTypeScriptにおけるジェネレーターは、関数の実行を途中で停止し、必要に応じて再開できる特殊な仕組みです。
この機能はfunction*構文によって定義され、yieldを用いることで値を逐次的に返すことができます。
通常の関数が「開始から終了まで一気に実行される」のに対し、ジェネレーターは「実行の途中状態を保持できる」という点が本質的な違いです。

まず基本的な構造として、ジェネレーター関数は以下のように記述されます。

function* simpleGenerator() {
  yield 1;
  yield 2;
  yield 3;
}

この関数は呼び出しただけでは処理を実行せず、イテレーターオブジェクトを返します。
実際の値の取得はnext()メソッドを通じて行われ、呼び出すたびに次のyieldまで実行が進みます。

この仕組みは内部的には状態機械として動作しており、以下のようなステップで理解すると本質が掴みやすくなります。

関数が呼び出されるが即時実行はされない
イテレーターが生成される
next()呼び出しごとに実行が再開される
yieldに到達すると処理が一時停止する
doneがtrueになると終了する

このようなモデルは、逐次的なデータ生成や遅延評価に非常に適しています。
例えば、大量データの生成やストリーム処理において、メモリ効率を高く保ちながらデータを扱うことができます。

TypeScriptにおいてもジェネレーターの挙動はJavaScriptと同一ですが、型付けによって安全性を高めることが可能です。
例えば以下のように、返却される値の型を明示できます。

function* numberGenerator(): Generator<number, void, unknown> {
  yield 10;
  yield 20;
}

この型定義により、ジェネレーターが返す値の整合性がコンパイル時に検証されるため、実行時エラーのリスクを減らすことができます。

ジェネレーターの代表的な用途としては以下が挙げられます。

無限シーケンスの生成
遅延評価によるパフォーマンス最適化
イテレーション処理の抽象化
非同期フロー制御（古典的なcoスタイルなど）

特に無限シーケンスの生成はジェネレーターの強みを最も象徴する用途です。
例えば連番生成やフィボナッチ数列などは、配列として事前に構築する必要がなく、必要な分だけ逐次生成できます。

また、ジェネレーターはfor...of構文と組み合わせることで、非常に自然なループ表現を実現できます。

for (const value of simpleGenerator()) {
  console.log(value);
}

この構文糖衣により、内部的なnext()呼び出しを意識することなくイテレーションが可能になります。

ただし重要な点として、ジェネレーターは「便利な抽象化」である一方で、「実行状態を隠蔽する仕組み」でもあります。
この特性が後の章で扱う「yieldを使わない設計」の動機とも密接に関係してきます。

つまりジェネレーターの本質は、単なるループ構文ではなく、実行状態を持つ関数という抽象モデルであるという点にあります。

yield構文の制約と実務上の課題

yieldはジェネレーターにおける中心的な構文であり、逐次的な値の生成や実行の中断・再開を実現するための強力な仕組みです。
しかし、理論的な美しさとは裏腹に、実務の現場ではいくつかの構造的な制約が存在し、それが設計上の判断に影響を与えることがあります。

まず第一に挙げられるのは、制御フローの非局所性です。
yieldは関数の途中に散在できるため、処理の「どこで状態が止まるか」がコード上から直感的に追いにくくなります。
例えば以下のようなケースでは、その影響が顕著です。

function* process(items: number[]) {
  for (const item of items) {
    const doubled = item * 2;
    yield doubled;
    const validated = doubled > 10;
    if (validated) {
      yield doubled + 1;
    }
  }
}

このように、1つのループ内に複数のyieldが存在すると、実行順序は見た目以上に複雑になります。
特に分岐やループと組み合わさることで、実行パスの全体像を把握するためには「頭の中で状態遷移をシミュレーションする」必要が生じます。

次に重要な課題は、状態管理の暗黙性です。
ジェネレーターは内部状態をランタイムが保持するため、開発者が明示的に状態を記述する必要がありません。
一見するとこれは抽象化として優れていますが、実務では逆に問題になる場合があります。

現在の実行位置がコード上に明示されない
テスト時に特定の中間状態を再現しづらい
デバッグ時にスタックトレースだけでは文脈が不足する

特にマイクロサービスや分散処理と組み合わせた場合、この「暗黙の状態」は設計上の不透明性につながることがあります。
状態が関数内部に閉じ込められているため、外部システムとの同期やリトライ制御が複雑化する傾向があります。

さらに、TypeScriptの型システムとの相性も無視できません。
ジェネレーターは型定義が可能である一方で、Generator<T, R, N>のようなジェネリック型は直感的とは言い難く、チーム開発では理解コストが上がる要因になります。
特に第三引数（nextの入力型）は使用頻度が低いにもかかわらず、型定義の複雑さだけを増すことがあります。

また、実行性能の観点でも注意点があります。
現代のJavaScriptエンジンではジェネレーターは最適化されているものの、通常のループや配列操作と比較するとオーバーヘッドが発生する場合があります。
特に大量データ処理では以下のような差異が問題になることがあります。

イテレーター生成コスト
状態保存によるメモリ負荷
JIT最適化の制約

これらは小規模な処理では無視できるレベルですが、データパイプラインやリアルタイム処理では積み重なることで影響が顕在化します。

もう一つ見逃せないのは、非同期処理との設計のズレです。
現在の主流はasync/awaitであり、Promiseベースのフロー制御が標準となっています。
そのため、ジェネレーターを用いた制御は古典的手法として扱われることが多く、コードベースの一貫性を損なう可能性があります。

総合すると、yieldの課題は単一の問題ではなく、以下の複合的な要因として整理できます。

制御フローの可視性低下
状態管理の暗黙化
型定義の複雑化
パフォーマンス上の潜在コスト
非同期設計との不整合

このような背景から、実務では「ジェネレーターを使わない設計」や「明示的な状態機械への置き換え」が検討されることになります。
次章では、その具体的な代替手法についてより踏み込んで解説します。

クロージャを使ったステートマシン実装

クロージャを用いたステートマシンは、yieldに依存せずにジェネレーター的な振る舞いを再現する代表的な設計手法です。
このアプローチの本質は、「関数が自身のスコープ外に状態を保持できる」というJavaScriptの特性を利用し、明示的な状態遷移をコードとして表現する点にあります。

ジェネレーターが内部的に状態機械へ変換されるのに対し、クロージャベースの実装ではその状態機械を開発者が直接設計します。
この違いにより、実行フローの透明性が高まり、デバッグやテストの容易性が向上するという利点があります。

まず基本構造として、状態を保持するクロージャは次のように定義できます。

type State<T> = {
  value: T;
  next: () => State<T> | null;
};
function createCounter(max: number): State<number> {
  let current = 0;
  return {
    value: current,
    next: () => {
      current++;
      if (current >= max) return null;
      return createCounter(maxFromCurrent(current, max));
    }
  };
}
function maxFromCurrent(current: number, max: number) {
  return max;
}

このように、next()が次の状態を返す構造にすることで、yieldと同様に逐次的な値生成を実現できます。
重要なのは、状態遷移がすべて明示的に記述されている点です。

クロージャベースのステートマシンは、以下のような特徴を持ちます。

状態遷移が関数呼び出しとして明示化される
実行フローがコード上で追跡可能
外部から状態を注入・変更しやすい
テスト時に任意の状態から再開できる

特にテスト容易性の観点では、ジェネレーターよりも優れている場合があります。
例えば、特定の中間状態から処理を再開したい場合、クロージャではその状態を直接構築することが可能です。
一方ジェネレーターでは、next()を複数回呼び出して状態を再現する必要があり、冗長になりがちです。

また、この設計は状態機械（State Machine）としての性質を強く持ちます。
状態と遷移を明示的に設計することで、以下のようなメリットが得られます。

複雑な分岐ロジックの可視化
状態遷移の単純化
バグの局所化
並列処理との相性向上

特に並列処理との親和性は重要です。
ジェネレーターは内部状態を隠蔽するため、並列実行時の状態共有が難しい場合がありますが、クロージャベースの設計では状態が明示的であるため、スレッドセーフな設計に近づけることができます。

ただし、この手法にもトレードオフは存在します。
最大の課題は「記述量の増加」です。
ジェネレーターでは数行で表現できる処理が、クロージャでは状態管理や遷移ロジックを明示的に書く必要があるため、コード量が増える傾向があります。

さらに、設計を誤ると状態遷移が複雑化し、かえって可読性が低下する可能性もあります。
そのため、クロージャベースのステートマシンは「複雑な制御フローを明示的に管理したい場合」に限定して採用するのが合理的です。

まとめると、このアプローチの本質は以下に集約されます。

暗黙的な実行状態を排除する
状態遷移を関数として明示する
制御フローの透明性を最大化する

この設計思想は、次に扱うコールバックベースやPromiseベースの逐次処理とも密接に関係しており、より高レベルな制御構造設計へとつながっていきます。

コールバックとPromiseによる逐次処理設計

ジェネレーターの代替として逐次処理を実現する手法の中で、コールバックとPromiseを用いた設計は最も実務的かつ広く利用されているアプローチです。
この設計は、yieldのような言語レベルの中断機構に依存せず、関数呼び出しの連鎖によって「次の処理へ進む」という制御を明示的に表現します。

まずコールバックベースの逐次処理は、最も原始的でありながら本質的な制御フローの表現方法です。
各処理が完了したタイミングで次の関数を呼び出すことで、擬似的なイテレーションを構築します。

function step1(next: () => void) {
  console.log("step1");
  next();
}
function step2(next: () => void) {
  console.log("step2");
  next();
}
function step3() {
  console.log("step3");
}
step1(() => step2(() => step3()));

この構造は単純ですが、処理の順序が関数呼び出しのネストとして表現されるため、規模が大きくなるにつれて「コールバック地獄」と呼ばれる可読性の問題が顕在化します。
特に条件分岐やエラーハンドリングが加わると、制御フローの追跡が困難になります。

この問題を解決するために登場したのがPromiseベースの逐次処理です。
Promiseは非同期処理の状態（pending、fulfilled、rejected）をオブジェクトとして扱うことで、コールバックのネストをフラットにすることができます。

function step1() {
  return new Promise<void>((resolve) => {
    console.log("step1");
    resolve();
  });
}
function step2() {
  return new Promise<void>((resolve) => {
    console.log("step2");
    resolve();
  });
}
function step3() {
  return new Promise<void>((resolve) => {
    console.log("step3");
    resolve();
  });
}
step1()
  .then(step2)
  .then(step3);

このようにPromiseチェーンを用いることで、逐次処理の構造が視覚的に直線化され、制御フローの可読性が大幅に改善されます。

さらにPromiseベースの設計には、以下のような特徴があります。

非同期処理と自然に統合できる
エラーハンドリングをcatchで一元化できる
中間状態を明示的に扱える
async/awaitへの移行が容易

特に重要なのは、Promiseが「状態を持つオブジェクト」であるという点です。
これはジェネレーターと同様に実行状態を抽象化していますが、その状態は外部から観測可能であり、制御フローがブラックボックス化しにくいという利点があります。

また、async/awaitはPromiseの上位抽象であり、内部的にはPromiseチェーンとして動作します。
そのため、コールバックからPromise、そしてasync/awaitへと進化する流れは、逐次処理の抽象度を段階的に高めた結果と捉えることができます。

一方で、Promiseによる逐次処理にも注意点があります。
例えば、単純なループ処理をPromiseで表現すると、以下のように冗長になる場合があります。

小規模な同期処理には過剰設計になりやすい
ループ表現が直感的でなくなる
状態の共有には別途スコープ管理が必要になる

このため、Promiseは「非同期逐次処理」において特に有効であり、同期的なイテレーションの代替としては設計判断が必要です。

総合すると、コールバックとPromiseによる逐次処理設計は以下のように整理できます。

コールバック：最も低レベルで直接的な制御フロー
Promise：構造化された非同期制御フロー
async/await：Promiseの可読性を高めた上位抽象

この階層構造を理解することで、ジェネレーターを使わずとも多くの逐次処理パターンを再現することが可能になります。
次に扱う配列ベースのアプローチは、さらに宣言的な方向へと設計思想が移行していきます。

配列とイミュータブル設計による疑似ジェネレーター

ジェネレーターの代替設計として、配列とイミュータブルなデータ操作を組み合わせたアプローチは、最も宣言的で理解しやすい手法の一つです。
この方法は「逐次的な値生成」を状態遷移としてではなく、「変換可能なデータ列」として扱う点に特徴があります。

従来のyieldベースの設計では、値の生成は実行フローの途中に埋め込まれていました。
一方で配列ベースの設計では、すべての値を構造として定義し、それを関数的に変換することで逐次処理を表現します。
この違いは単なる実装差ではなく、設計思想の転換といえます。

まず基本的な例として、単純な数列を生成する場合を考えます。

const base = [1, 2, 3, 4, 5];
const doubled = base.map((value) => value * 2);
const filtered = doubled.filter((value) => value > 5);

このように、配列操作を組み合わせることで「生成→変換→フィルタリング」という逐次処理を明示的に表現できます。
このアプローチの本質は、状態を持たずにデータを変換し続ける点にあります。

イミュータブル設計の利点は、以下のように整理できます。

元データが変更されないため副作用が発生しない
処理の流れが関数合成として表現できる
デバッグ時に各段階のデータを追跡しやすい
並列処理との相性が良い

特に重要なのは「状態を持たない」という性質です。
ジェネレーターやクロージャベースの設計では内部状態が存在しましたが、配列ベースでは各ステップが独立した変換として扱われるため、状態管理の複雑性が排除されます。

さらに、このアプローチは関数型プログラミングの思想と強く結びついています。
map、filter、reduceといった高階関数を組み合わせることで、処理のパイプラインを構築できます。

const result = [1, 2, 3, 4, 5]
  .map(x => x * 2)
  .filter(x => x % 2 === 0)
  .reduce((acc, value) => acc + value, 0);

このような構造は、逐次的な処理を「データ変換の連鎖」として再定義している点で重要です。
ジェネレーターが「時間的な流れ」を扱うのに対し、配列ベースの設計は「空間的なデータ構造」を扱うと整理できます。

ただし、この手法にも明確な制約があります。
特に以下の点は設計上の注意点となります。

大規模データではメモリ効率が悪化する可能性がある
無限シーケンスの表現が困難
遅延評価が標準ではないため事前計算が発生する

これらの問題に対処するためには、必要に応じてイテレーターやストリーム処理と組み合わせる設計が求められます。
つまり、配列ベースの設計は万能ではなく、「有限で明確なデータ集合」に適した手法です。

また、TypeScriptとの相性という観点でも重要な利点があります。
配列操作は型推論と非常に親和性が高く、以下のような恩恵を受けることができます。

各変換ステップで型が自動的に更新される
インターフェース設計が単純化される
ジェネリクスの複雑化を回避できる

結果として、コードの可読性と静的解析の精度が向上します。

総合すると、このアプローチは「ジェネレーターの代替」というよりも、「逐次処理の再定義」と捉えるべきです。
状態を持つ実行モデルではなく、データ変換の連鎖として設計することで、より宣言的で予測可能なコード構造を実現できます。

次章では、これらの手法を比較し、それぞれの適用領域について体系的に整理します。

ジェネレーター代替パターンの比較と設計指針

これまで解説してきたように、TypeScriptにおけるyieldを使わない実装には複数のアプローチが存在します。
それぞれの手法は単なる実装差ではなく、制御フローの捉え方そのものに違いがあり、適用領域や設計思想も大きく異なります。
本章ではそれらを体系的に比較し、実務での設計指針として整理します。

まず、主要な代替パターンを俯瞰すると以下のように分類できます。

クロージャベースのステートマシン
コールバック／Promiseによる逐次処理
配列とイミュータブルなデータ変換
明示的な状態オブジェクトによる制御

それぞれの特徴を整理すると、次のような構造的な違いが見えてきます。

パターン	状態管理	可読性	適用領域	拡張性
クロージャ	明示的	中	中規模ロジック	高
Promise	半明示的	高	非同期処理	高
配列処理	なし	非常に高	データ変換	中
状態オブジェクト	明示的	低〜中	複雑フロー	非常に高

この比較から明らかなように、各手法は「優劣」ではなく「適材適所」の関係にあります。
重要なのは、ジェネレーターを置き換えること自体ではなく、「どの抽象レベルで制御フローを表現するか」という設計判断です。

例えば、クロージャベースのステートマシンは内部状態を明示的に管理するため、複雑な遷移ロジックを持つ業務処理に適しています。
一方で、単純な逐次処理には過剰設計となる可能性があります。

Promiseベースの設計は、非同期処理との統合に優れており、特にAPI通信やI/O処理において標準的な選択肢となります。
しかし同期的なループ表現には適していないため、用途が限定されます。

配列ベースのイミュータブル設計は、最も宣言的で理解しやすい一方で、遅延評価や無限シーケンスの表現には弱いという制約があります。
したがって、データ量が有限である場合に最適です。

ここで重要になるのは、「どのパターンを選ぶか」ではなく「どの性質を優先するか」という設計軸です。
一般的には以下の観点で判断します。

可読性を最優先するなら配列ベース
制御の柔軟性を重視するならクロージャ
非同期統合が必要ならPromise
状態遷移の完全制御が必要なら状態オブジェクト

さらに実務的な観点では、これらを単独で使うのではなく、組み合わせて設計するケースが多くなります。
例えば、Promiseチェーンの中でクロージャを使って状態を保持したり、配列処理の結果を非同期フローに渡すといった構成です。

重要なのは、これらのパターンがすべて「ジェネレーターの代替」ではなく、「制御フロー設計の異なる表現形式」であるという点です。
yieldが提供する抽象化は強力ですが、それを必ずしも採用する必要はなく、むしろ制約のある環境では明示的な設計の方が合理的になる場合があります。

最終的な設計指針としては、次の3点に集約されます。

状態の隠蔽ではなく可視化を優先する
制御フローの抽象度を必要最小限に保つ
実行環境とチームスキルに合わせて選択する

この視点を持つことで、ジェネレーターの有無に依存しない、より本質的な制御フロー設計が可能になります。

まとめ：yieldなしでループ制御を設計するポイント

本記事では、TypeScriptにおけるyieldを用いずにジェネレーター相当のループ制御を実現するための複数の設計パターンについて検討してきました。
それぞれの手法は単なる実装の違いではなく、制御フローそのものの捉え方を変えるものであり、設計思想の選択に直結します。

結論として重要なのは、「ジェネレーターを置き換えること」自体ではなく、「制御フローをどのように可視化し、管理するか」という視点です。
yieldは強力な抽象化ですが、その内部状態の隠蔽性が実務上の課題になる場面も少なくありません。
そのため、明示的な設計へと移行することには十分な合理性があります。

これまで扱った代替パターンを整理すると、次のような構造になります。