2. エンジニア向けの説明

計算理論とチューリングマシン: コンピュータサイエンスの計算理論の文脈では、チューリング完全性は「万能チューリングマシンと同等の計算能力を持つこと」と定義されます。チューリングマシンとは無限長のテープ（記憶）と読み書きヘッドを備え、あらかじめ定めた遷移規則に従って計算を行う抽象機械モデルです。非常にシンプルなモデルですが、このテープ上の読み書きと状態遷移だけで任意の計算が可能であることが示されています。要するに、チューリングマシンは現在考えうる最も強力な計算モデルの一つであり、現実のコンピュータで実行できるアルゴリズムはすべてチューリングマシン上でも実行できます。チューリング完全なシステムは、このチューリングマシンが解ける問題をすべて解けるだけの計算力を備えているということになります。実用上は「有限メモリしか持たない現実のコンピュータにおいて、そのメモリ制限を無視すれば実質的に同じ計算ができる」という意味合いです。

https://zenn.dev/cybozu_ept/articles/github-actions-is-turing-complete#チューリング完全性とは

チューリング完全となる条件

プログラミング言語や計算モデルがチューリング完全となるためには、いくつかの基本的な構造要素が必要です。一般に命令型（Imperative）言語であれば少なくとも次の2点が求められます:

• 条件分岐と繰り返し（条件によって処理をループさせたりジャンプさせたりする仕組み） – 例えばifやwhile、再帰呼び出しなど。これにより計算の長さ（ステップ数）を動的に伸ばすことができます。
• 可変なメモリ領域（読み書き可能なデータ記憶） – 変数、配列、テープなど形態は問いませんが、計算途中の値を保存し、更新できる領域が必要です。特に重要なのはそのメモリが原理上無制限（必要に応じていくらでも増やせる）であることです。

これらが揃うと、プログラムは任意の長さの計算や任意サイズのデータ処理を記述できるようになり、結果としてチューリングマシンで実行できるあらゆる計算をシミュレートできるようになります。ちなみに関数型言語の場合はループの代わりに再帰的な関数適用やラムダ計算によって同等の表現力を持たせることができます。いずれにせよ、「計算を途中でいくらでも繰り返し展開できる仕組み」と「理論上無限に使えるメモリ」の二つがチューリング完全性の鍵となります。

具体的な例（チューリング完全なシステム）

抽象計算モデルの例では、前述のチューリングマシンそのものはもちろん、アルフォンス・チャーチのラムダ計算やポストの計算機械（Post体系）、またμ-Recursive関数などがすべてチューリング完全であると知られています。これらは計算論の研究用に考案されたモデルですが、実際には現代のほとんどすべての汎用プログラミング言語もチューリング完全です。例えば、命令数わずか8つしかない極簡単な言語Brainfuckや、関数定義すら持たない初期のBASICであっても、ループとメモリさえあればチューリング完全性を持ちます。実際にBrainfuckやLazy Kといった極限まで機能を絞った言語がチューリング完全であることが示されています。一方でPythonやJavaScriptなど現代的な高級言語は言うまでもなくチューリング完全であり、それらの言語が動作するコンピュータ自体も（メモリが許す限り）チューリングマシンと同等の計算能力を持っています。要素の少ない言語でも高級な言語でも、条件分岐・繰り返し・可変メモリといった基本要件を満たしていれば計算能力の上限は同じ（チューリング機械相当）なのです。

図: さまざまな計算モデルの階層。内側から「Combinational logic（組み合わせ回路）」→「Finite-state machine（有限状態機械）」→「Pushdown automaton（プッシュダウン・オートマトン）」→「Turing Machine（チューリングマシン）」の順に包含関係が描かれており、チューリングマシンが最も強力なモデルであることを示している。例えば正規表現が扱う正則言語は有限状態機械で受理され、**文法（コンテキストフリー言語）**はプッシュダウン・オートマトンで受理されますが、これらの計算モデルはチューリングマシンより表現力が低いため、それぞれチューリング完全ではありません。一般的に計算モデルの表現力はこの図のような階層構造になっており、チューリングマシンが頂点に位置します。チューリング完全な言語は、この頂点であるチューリングマシンと同じ領域（最外郭の緑色部分）に属することになります。

チューリング完全ではない例

世の中のすべてのシステムがチューリング完全というわけではありません。計算能力を限定した言語も存在し、そのような言語では実行できる処理に上限があります。典型的な例が正規表現（regex）や限定的なSQLクエリです。正規表現は文字列パターン照合のための言語ですが、理論的には有限オートマトン（有限状態機械）というモデルで表現されるため、無限にネストしたり再帰的な計算を行うことができず、チューリング完全ではありません。また標準的なSQLも、基本的には有限個のテーブルデータに対する問合せを記述するための宣言的言語であり、再帰的なクエリや無限ループを持たない限りチューリング完全の条件を満たしません。事実、SQL-99で再帰的な共通テーブル式（CTE）が導入されるまでは、SQLのクエリ部分はチューリング不完全でしたが、再帰SQLやストアドプロシージャなどの拡張によって現在ではチューリング完全と言えるレベルまで表現力が強化されています。このように一部の言語は意図的に計算能力を制限することで、無限ループが発生しないようにしたり（例：全ての計算が停止することを保証する全域関数型言語）、特定分野に特化して扱いやすくすることがあります。ただしその分、解ける問題の範囲が狭まるため、用途が限定的になります。「チューリング完全でないがゆえに実用上の制約が生じ、最終的には機能拡張されてチューリング完全になる」というケースも少なくありません（前述のSQLの例などが典型です）。

3. プログラミングとAIの関連性

AIのコード生成とチューリング完全性: 近年の高度なAI（特に大規模言語モデル）は、プログラミング言語のコードを生成することができます。例えばChatGPTにPythonやJavaScriptのコードを書かせるといったことが可能ですが、これらの一般的なプログラミング言語はすべてチューリング完全であり、したがってAIが生成したコードは原理的にどんな計算タスクでも実行し得る力を持っています。言い換えると、AIはコードを書くことで自らチューリング完全な計算を間接的に行えるのです。これは非常にパワフルで、複雑な問題に対しても適切なプログラムさえ組めれば解を計算できることを意味します。例えばAIが与えられたデータを分析して答えを出す際に、内部でPythonコードを組み立てて実行するようなケースでは、そのPythonの持つ表現力（チューリング完全性）のおかげで制約のない柔軟な処理が可能になります。

プロンプトエンジニアリングとチューリング完全性の関係: プロンプトエンジニアリングとは、AIに望む出力を得るために入力文（プロンプト）の工夫を凝らすことですが、これは見方を変えれば自然言語を用いたAIのプログラミングとも言えます。高度な使い方では、AIに段階的な推論をさせたり、一度の回答で完了しない処理を対話を通じて継続させることで、まるでループや関数呼び出しを行っているかのように振る舞わせることもできます。例えば大きな問題を何度もAIに解かせ、その都度部分結果をプロンプトに含めて次の処理をさせる、という対話型のループを作ることも可能です。実際の研究でも、プロンプトによって言語モデルにチューリングマシンの動作をシミュレートさせられることが示されています。これはモデルの出力を再度入力としてフィードバックする仕組みを使い、AIに仮想的な「メモリ」を与えることで無限に近い長さの計算を実現する手法です。このようにプロンプト設計次第で、AIは内部にループや条件分岐を持たなくとも段階的に任意の計算（アルゴリズム）を実行できる可能性があり、言語モデルとプロンプトの組み合わせ自体を一種のチューリング完全なシステムのように扱うことができます。

チューリング完全性がAI開発やプログラミングで重要な理由: プログラミングにおいてチューリング完全性が重要なのと同様に、AIの開発・活用においても汎用的な計算能力の保証が重要です。 AI分野のタスク（機械学習アルゴリズムの訓練、データ処理、シミュレーションなど）は非常に多様で複雑な計算を含みますが、それらを実装するためには底層でチューリング完全なシステムの支えが必要です。例えば大規模データの解析では繰り返し処理や条件分岐が不可欠ですし、機械学習のモデルも最終的にはチューリング完全なプログラミング言語で記述されています。AIアプリケーションを開発する際、もし使用する言語やプラットフォームがチューリング完全でなければ、途中で実現できない処理が出てきてしまい、十分な機能を持つAIを構築できなくなるでしょう。逆にチューリング完全であれば、新しい要求にも柔軟に対応できます。さらに、近年の生成AIは自らコードを書いたり、他のツールと連携したりすることで足りない機能を補うことができますが、これも根底にあるプログラミング言語や計算モデルがチューリング完全だからこそ可能なアプローチです。要するに、チューリング完全性は汎用性と将来性の土台なのです。プログラミング言語でもAIシステムでも、それがチューリング完全であることによって「理論上どんな計算でもこなせる」という安心感が得られます。そしてそのことが、私たちがソフトウェアやAIに問題解決を託す上で非常に重要だと言えるでしょう。

3. 依存関係の管理とTypeScriptでの実装

● TypeScriptのインターフェースを活用した依存関係の管理:

上記DIPを実現するために、TypeScriptでは インターフェース（interface） を活用します。ユースケース側では外部依存（データ永続化や外部サービス呼び出しなど）に直接触れないように、ポート（Port） と呼ばれるインターフェースを定義します。例えば、タスク管理のユースケースがデータベースに依存しないように、TaskRepositoryやTaskPortといったインターフェースを用意し、ユースケースはそれに対してプログラミング します。これによりユースケースは「データ保存のできる何か」には依存しますが、その具体実装（SQLなのかファイルなのか）は知らなくて済みます。依存関係は抽象に向かうため、具体的な実装側（インフラ層）がこのインターフェースを実装し、後述のDIコンテナ等で注入します。

● ユースケースとリポジトリの関係:

ユースケースからデータベース操作を行う際の悪い例として、ユースケース内で直接DB接続やORMリポジトリを生成・呼び出ししてしまうケースがあります。例えば以下のように、ユースケース内で直接newしてDBのリポジトリを使うと、ユースケース層がインフラ詳細（DB）に依存してしまいます:

// 悪い例: ユースケースが直接DBリポジトリに依存している
execute(title: string, description: string, pool: any) {
  const task = new Task(title, description)
  const taskRepository = new TaskRepository(pool)  // インフラに依存
  return taskRepository.persist(task)
}

このようにデータベースのコネクションやORMに直接依存する設計は、クリーンアーキテクチャのルール違反 となります。解決策として、ユースケースはリポジトリのインターフェース（抽象）に依存 し、実体はインフラ層で用意するようにします。具体的には、例えばITaskRepositoryというインターフェースを定義し、ユースケースはコンストラクタでそれを受け取る形に変更します。TypeScriptであれば次のような実装になります:

// リポジトリのインターフェース定義（ユースケース側で定義）
interface ITaskRepository {
  persist(task: Task): Promise<void>;
  find(id: number): Promise<Task | null>;
  // ...必要なメソッド定義...
}

// ユースケースでインターフェースを受け取る
class CreateTaskUseCase {
  constructor(private taskRepo: ITaskRepository) {}  // 抽象に依存

  async execute(title: string, description: string) {
    const task = new Task(title, description)
    await this.taskRepo.persist(task)  // 抽象メソッド呼び出し
  }
}

ユースケースはITaskRepositoryという**抽象（インターフェース）**のみに依存し、具体的な保存処理は知りません。このITaskRepositoryを実装したクラス（例えばMySQLTaskRepositoryなど）をインフラ層に作成し、アプリ起動時にユースケースに注入することで、依存関係の逆転を実現します。上述の例でも、TypeScriptのインターフェースによりコンパイル時に契約が保証されるため、安全に依存関係を管理できます。

● 実装例（クラスとインターフェースの使用）:

上記の設計をコードで表すと、インターフェース継承と依存性注入 の形になります。例えば、TaskUseCaseクラスのコンストラクタでTaskPortインターフェース（リポジトリの抽象）を受け取り、それを用いてタスク取得などの処理を行う実装が考えられます。このようにすることで、ユースケース（TaskUseCase）は具体的なデータアクセス手段を意識せず、与えられた抽象（TaskPort）経由で操作を行います。実装クラス側（例えばTaskRepositoryImpl）はTaskPortインターフェースを実装し、インフラ層でデータベース操作の詳細を持ちます。TypeScriptのクラスとインターフェース機能により、「内側のレイヤーは外側の詳細を知らず、抽象だけ知っている」 状態を作り出せるわけです。

4. DIコンテナの活用

● NestJSを活用した依存性の注入:

TypeScript/Node.jsのフレームワークであるNestJSは、標準で強力なDI（Dependency Injection）コンテナを備えており、クリーンアーキテクチャ実践に役立ちます。NestJSでは、クラスにデコレータを付与してプロバイダ（サービスやリポジトリ）として登録し、必要な箇所で自動的にインスタンスが注入されます。モジュールごとに依存関係を整理するため、構造が明確になり大規模プロジェクトでも管理しやすい利点があります。例えば、ユースケースサービスに対してリポジトリ実装をNestJSのprovidersでバインドしておけば、コントローラからユースケースサービスを呼ぶ際に適切な実装が注入されます。

● DIを用いたテスト容易性:

依存性注入を活用すると、テストが格段にしやすくなります。NestJSではテスト時にDIコンテナにモック（テスト用のダミー実装）を登録することで、ユースケースやサービスの挙動を外部要因に左右されず検証できます。実際、DIによりオブジェクトは自前で依存物を生成しないため、代わりにテスト用のフェイクやモックを注入できます。その結果、ユニットテストでは対象クラスだけに注力でき、副作用のない堅牢なテストが可能です。例えばNestJSのテストモジュール機能を使えば、あるサービスが依存するリポジトリをモック実装に差し替えて注入し、ビジネスロジック部分のみを検証できます。DIコンテナを活用することで、疎結合な設計とテスト容易性 の双方を実現できるのです。

5. クリーンアーキテクチャのメリット

クリーンアーキテクチャを導入することで、システム設計に以下のようなメリットが生まれます。

フレームワーク非依存

システムの動作が特定のフレームワークに縛られません。フレームワークはあくまで詳細の実装に過ぎず、いつでも交換可能な「ツール」として扱われます。例えば、ExpressからNestJSへの移行や、ReactからVueへのフロントエンド変更も、ビジネスロジック部分を変更せずに対応しやすくなります。

テスト容易性

ビジネスルールのロジックはUIやDBと無関係に分離されているため、ユニットテストが書きやすくなります。UIやデータベースの代わりにモックを用意して、ユースケースの振る舞いを単独で検証可能です。これにより、変更時に回帰バグがないか素早く確認でき、リファクタリングも安心して行えます。

変更に強い構造

レイヤー間の依存が内側に限定されているおかげで、技術要素の変化や要件変更に柔軟に対応できる保守性・拡張性の高い設計となります。例えばデータベースをSQLiteからPostgreSQLに差し替えたり、UIフレームワークを変更する場合でも、影響はインフラ層など限られた範囲に留まり、中心のビジネスロジックへの修正は不要で済む可能性が高いです。結果としてシステム全体が変更に強くなり、将来的な機能追加も容易になります。

UI/データベース非依存

ビジネスルールは外部のUIやデータベースの細部に影響されません。UIはシステムの他の部分を変更せずとも改修・交換でき、データベースについてもビジネスロジック層はその存在を意識しないため、極端に言えばDBなしでもビジネスロジックのテストが可能です。

外部システムからの独立

ビジネスロジックは外界のシステム（例えば認証基盤や他サービスのAPI）について何も知らない状態を保てます。外部サービスの変更やサードパーティライブラリのアップデートがあっても、影響はインターフェース層・インフラ層で吸収でき、ドメインやユースケースには波及しません。この独立性により、安心して外部サービスやライブラリの変更を取り込めます。

以上のように、クリーンアーキテクチャはフレームワークやデータソースに左右されない柔軟でテストしやすい構造をもたらします。その結果、システムが長期間にわたって拡張・変更しやすい状態を維持できる点が大きな利点です。

6. 実践のポイント

クリーンアーキテクチャを現場で適用する際には、以下のポイントに留意すると効果的です。

ドメインモデルの優先

システムで表現すべき業務上の概念やルールをドメインモデルとして最優先で設計しましょう。例えばエンティティ（ドメインオブジェクト）はデータベースのテーブル設計に引きずられず、業務の言葉で属性や振る舞いを定義します。ドメイン知識がコード上に散逸しないよう、この層に閉じ込めます。こうすることで、ビジネスロジックが常にシステムの中心に据えられ、技術的な変更にも影響されにくくなります（※ドメイン駆動設計(DDD)の考え方も参考になります）。

外部依存の抽象化

データベースや外部API、フレームワークといった外部要素への依存は必ず抽象化して受け渡すようにします。具体的にはインターフェースや抽象クラスで境界面（インターフェース層）を定義し、それを経由して外部システムとやり取りします。これにより「外側の変更が直接内側に影響しない」状態を作ります。例えば、ファイルストレージからクラウドストレージに変更する場合でも、ストレージ操作用のインターフェースを実装し直すだけで、ユースケースから見ると同じメソッド呼び出しで済みます。常に依存の方向が抽象に向くよう意識しましょう。

データフローの意識

各レイヤー間をデータがどのように流れるかを明確に設計します。特に、データの入力と出力の変換はインターフェースアダプター層で完結させることがポイントです。ユースケース層では外部のデータ形式を意識せずに済むように、リクエストDTOからドメインモデルへの変換、ドメインモデルからレスポンスDTOへの変換などを適切に橋渡しします。こうしたデータフローの境界を明確にすることで、レイヤー間の役割がはっきりし、将来の拡張時にも「どこを修正すべきか」が分かりやすくなります。

以上の点を踏まえ、実装時には**「今書いているコードはどの層の責務か」を常に自問すると良いでしょう。例えば、ビジネスルールに直接関係ないログ出力や認証チェックのコードがユースケース層に紛れ込んでいないか、UIフレームワーク特有のオブジェクトがドメイン層に漏れていないか、といった観点でコードを見直す習慣をつけます。クリーンアーキテクチャでは各層の責務が明確に分かれているため、逆に言えば責務外の処理が混入すると設計が崩れる**恐れがあるからです。

7. よくある間違いとその解決策

クリーンアーキテクチャを適用しようとする際に陥りがちなミスや、依存関係が破綻しやすいポイントを押さえておきましょう。

手段が目的化してしまう:

クリーンアーキテクチャという名前や同心円の図解だけが独り歩きし、「とにかくレイヤーを分ければ良い」「形だけ真似しよう」としてしまうことがあります。この場合、本来の目的である関心の分離や保守性向上がおろそかになり、かえって開発効率が下がってしまうこともあります。対策: クリーンアーキテクチャは銀の弾丸ではないことを認識し、プロジェクトの規模や要求に応じて適用範囲を見極めましょう。「何のためにこの構造にするのか（目的は何か）」をチームで共有し、単にレイヤーを作ること自体が目的化しないように注意します。

過度な抽象化・インターフェースの乱立:

DIPを意識するあまり、必要性の低い部分までインターフェースを作りすぎたり、レイヤーを細分化しすぎてしまうケースがあります。抽象化しすぎるとコードが複雑化し、開発効率や可読性が落ちて本末転倒になりかねません。対策: 抽象化はあくまで「変更に備えるための手段」であることを意識します。頻繁に変更が起こり得る箇所や外部依存が大きい箇所を重点的に抽象化し、その他は過度に分離しすぎないようにバランスを取ります。インターフェース導入の目的は依存方向の制御であり、数を増やすこと自体ではない点にも留意しましょう。

依存関係のルール違反:

レイヤー間の依存関係の制約を破ってしまう典型例も挙げられます。例えば、ドメイン層のエンティティが直接DBのエンティティ（ORMモデル）に依存してしまったり、ユースケース層でWebフレームワークのリクエストオブジェクトを参照してしまうなどです。特にユースケース層とインフラ層の境界は破綻しやすく、前述したようにユースケース内でDBコネクションを扱ってしまうミスがありがちです。対策: 依存ルールに反する箇所を定期的にレビューで洗い出し、インターフェース経由の呼び出しにリファクタします。ユースケースが何か外部要素に触れている場合はすぐにポートを定義しなおし、インフラ層に処理を移すべきサインだと考えましょう。チーム内で依存関係のチェックリスト（「ユースケースから〇〇を直接呼んでいないか？」等）を用意するのも有効です。

ドメイン貧血症（Anemic Domain Model）:

クリーンアーキテクチャとDDDを混同して誤解した結果、ドメインモデルに何もロジックがなくデータの入れ物になってしまうケースがあります。全てのビジネスロジックをユースケースに寄せすぎると、エンティティはただのDTOと化しドメイン層の意義が薄れます。この状態だと変更箇所がユースケースに集中してしまい、場合によってはユースケースが肥大化します。対策: エンティティが担うべきドメインルール（不変条件や関連オブジェクトとの整合性維持など）はエンティティ内部に持たせます。ユースケースはフローの調整役に留め、個々のビジネスルールは適切にドメイン層でカプセル化しましょう。例えば、「タスクのステータス更新はTaskエンティティ自身のメソッドで行い、ユースケースはそのメソッドを呼ぶだけ」にするといった設計です。こうすることで各層の責務が明確になり、テストもしやすくなります。

8. 学習リソース

最後に、クリーンアーキテクチャをさらに深く学ぶための参考リソースを紹介します。

書籍『Clean Architecture 達人に学ぶソフトウェアの構造と設計』（Robert C. Martin 著, 日本語訳）
クリーンアーキテクチャの提唱者である「アンクルボブ」ことRobert C. Martin氏の著書です。アーキテクチャの歴史的背景からSOLID原則、具体的な設計指針まで体系的に解説されており、様々な種類のシステムに応用できる普遍的な知見が得られます。クリーンアーキテクチャの思想を包括的に理解するのに最適な一冊です。

原著記事「The Clean Architecture」およびその日本語翻訳ブログ
Robert C. Martin氏が自身のブログで発表したクリーンアーキテクチャ解説記事（英語）と、その有志による日本語翻訳記事があります。書籍ほど長くありませんが、同心円のレイヤー図とともに設計の要点がまとまっているため、まずはこちらを読むと全体像を掴みやすいでしょう。日本語翻訳は「クリーンアーキテクチャ The Clean Architecture 翻訳」というタイトルで公開されています。

サンプル実装リポジトリ

実際のコードでクリーンアーキテクチャを体験するには、GitHub上のサンプルリポジトリを読むのが近道です。例えば、quick-xp/taskhelp-api はNode.js (Express) + TypeScriptでToDoアプリAPIをクリーンアーキテクチャで実装した練習用プロジェクトで、ディレクトリ構成やコードが参考になります（SpaceMarket社ブログで紹介）。また、海外の例ですが FilipeMata/clean_architecture_typescript_example ではクリーンアーキテクチャの各層がフォルダで分けられており、TypeScriptでの実装方法を学べます。これらのリポジトリをクローンして手元でテストを動かしたり、リファクタリングしてみると理解が深まるでしょう。

その他の関連書籍

クリーンアーキテクチャ以外にもオニオンアーキテクチャやヘキサゴナルアーキテクチャといった類似の設計手法があります。それらを比較しつつ理解したい場合は『実践ドメイン駆動設計』(DDD)や『レガシーコード改善ガイド』なども併せて読むと、クリーンアーキテクチャの位置づけがより明確になります。特にDDDはクリーンアーキテクチャと組み合わせて使われることも多い概念なので、ドメインモデルの設計に興味があればチェックしてみてください。