オートマトンの歴史

 

時期	系統・代表例	概要（約200字）
1940–60年代	ノイマン型自己複製オートマトン	ジョン・フォン・ノイマンとウラムが提案。生命の自己増殖を形式的に再現する試みで、後の人工生命研究の源流。複雑なルールで自己複製構造を生成し、情報と形の自己維持を数理的に示した。後にコッドが簡略モデルを開発。
1960年代	L-system（リンダンメイヤー）	植物の成長過程を記号列として再帰的に記述する文法モデル。枝分かれや葉の配置などを規則で生成でき、フラクタル幾何やCG植物モデルの基礎となる。ライフゲーム以前に形態生成オートマトンとして影響大。
1970年代	コンウェイのライフゲーム	グリッド上のセルが誕生・生存・死の簡単なルールで進化。自己組織的に複雑なパターンが生まれ、計算能力も持つ。メディアで広まり、一般に「オートマトン＝ライフ」という認識を定着させた。
1980年代	ウォルフラムの一次元CA／ラングトンのループ	ウォルフラムはRule 30やRule 110で秩序と混沌の境界を分類。ラングトンは自己複製ループを開発し、単純ルールから生命的構造が生まれることを実証。可逆CAや格子ガスも物理モデリングに発展。
1990年代	発火型・可逆・物理系CA	Brian’s Brain、Cyclic CA、Greenberg–Hastingsなど発火と拡散のリズムを再現。トッフォリ＝マルゴラスの可逆CAや格子ボルツマン法は流体・熱伝導を近似し、物理シミュレーションや材料科学に応用。
2010年代以降	SmoothLife／Lenia／Neural CA	SmoothLifeやLeniaは連続空間で擬生命パターンを生成。Neural CAはニューラルネットでルールを学び、形態形成や自己修復を実現。近年は学習とオートマトンの融合で「進化するルール系」へ展開。

The History of Automata

 

Era	System / Example	Summary (≈200 characters each)
1940s–1960s	Von Neumann Self-Replicating Automaton	Proposed by John von Neumann and Ulam, it modeled self-reproduction in formal logic. This became the foundation of artificial life, showing how information and structure can replicate through rule-based construction. Later simplified by Codd.
1960s	L-system (Lindenmayer System)	A grammatical model expressing plant growth as recursive symbol rewriting. It generates branching and leaf structures via simple rules, forming the basis of fractal geometry and procedural modeling—an early form of morphological automaton.
1970s	Conway’s Game of Life	A grid-based system where simple birth/survival/death rules yield complex emergent patterns. Demonstrated how simple local rules create global order and even universal computation. It popularized “cellular automata” worldwide.
1980s	Wolfram’s 1D CA / Langton’s Loop	Wolfram classified CA behaviors (Rules 30 & 110) and explored order-chaos boundaries. Langton’s self-replicating loop showed lifelike growth from minimal rules. Reversible CA and lattice-gas models extended automata to physical simulation.
1990s	Excitable, Reversible & Physical CA	Systems like Brian’s Brain, Cyclic CA, and Greenberg–Hastings reproduced excitation and wave propagation. Toffoli–Margolus reversible CA and lattice-Boltzmann methods modeled fluids and heat, influencing physics and materials science.
2010s–present	SmoothLife / Lenia / Neural CA	SmoothLife and Lenia introduced continuous-space life-like forms. Neural CA learned their own rules via neural networks, enabling self-repair and morphogenesis. These merge learning and automata, creating evolving rule-based systems.

テリー・ライリー《In C》の演奏指針要約

 テリー・ライリー《In C》の演奏指針要約。全員が同一譜面の53のパターンを順番に演奏し、編成や楽器数は自由（理想は約35名）。声部は任意の母音・子音で参加可。各奏者は各パターンを好きな回数だけ反復して次へ進む。公演は45〜90分程度が目安で、1パターンの滞在はおおむね45〜90秒以上。互いをよく聴き、ときに休んで聴くこと。強弱の幅を大きく取り、合奏でクレシェンド／ディミヌエンドを合わせる。ユニゾンやカノン的重なりを任意に行い、ポリリズムの相互作用を楽しむが、常に2〜3パターン以内で歩調を保ち、先走りや遅れを避ける。高音Cの8分音符パルス（ピアノやマレット、慎重な打楽器）で合図可。全員が厳密なリズムで正確に弾くこと。テンポは任意だが無理のない範囲で。休止中も周期的アクセントを意識し、再入時の効果を配慮する。必要に応じて1オクターブ移調（特に上方）、長音には下方移調も有効。リズムの拡大も可。弾けないパターンは省略可。増幅や電子鍵盤の使用も可。終結は全員が第53番に到達してから大きなクレッシェンドとディミヌエンドを数回行い、各自の判断で順次抜けて終わる。

https://thirdcoastpercussion.com/downloads/2015/04/Terry-Riley-In-C-concert2.pdf

Shenは、Lisp系の関数型言語で、パターンマッチ、マクロ、遅延評価、型系（シーケント計算に基づく）、組込みProlog、コンパイラコンパイラなどを単一環境で提供する“多段”言語です。

 Shenは、Lisp系の関数型言語で、パターンマッチ、マクロ、遅延評価、型系（シーケント計算に基づく）、組込みProlog、コンパイラコンパイラなどを単一環境で提供する“多段”言語です。2021年以降はSシリーズの軽量カーネルに集約され、部分適用ベースの実装、型付きYACC、GC付きProlog、パッケージ/入出力/ハッシュ表など基盤が刷新。学習は「Shen in 15 minutes」と『The Book of Shen』が入口。配布は最新S系カーネル、標準ライブラリ2系、Shen/tk（Tcl/Tk連携GUI）、Yggdrasil（スタンドアロン生成）。2025年はOpen Shenとして大規模な無料資料を公開予定。Shenは多くのホスト言語上で動作し、同一ソースで移植性を確保。REPLと型推論、パターン指向の関数定義、例外/ストリーム/マップ等の抽象を備え、小さな核＋豊富な標準で、DSL設計や定理証明的型検査、ロジック/関数/命令の横断が容易。Yggdrasilで単一バイナリ化、Shen/tkで簡易GUI、サンプルとチュートリアルも整備。研究から実務まで、短いコードで強い表現力を狙う人に適した言語です。

ジャズでいう「ヴォイシング」とは、同じコード名でも、どの音を選び、どの高さに並べ、どの順番で重ねるかという配置設計のことです

 ジャズでいう「ヴォイシング」とは、同じコード名でも、どの音を選び、どの高さに並べ、どの順番で重ねるかという配置設計のことです。たとえばC7と書いてあっても、ルートCと5度Gを低く置く場合と、3度E・7度Bb・9th D・13th Aだけを中域にまとめる場合ではまったく別の響きになります。ジャズでは一つの“正解フォーム”より、場面ごとの色合いとバンド内バランスが優先されるので、ヴォイシングは演奏者の個性そのものになります。特に大事なのはガイドトーンと呼ばれる3度と7度で、これらはコードの性格と進行感（どこへ解決しそうか）を一番はっきり伝えます。逆にルート音はベース担当に任せて鍵盤やギターは抜いてしまい、3度・7度とテンション（9th,11th,13thなどの色づけ音）だけを鳴らす「ルートレス・ヴォイシング」がよく使われます。これは低域を濁らせず都会的なサウンドを作ります。また、各音を狭く固めるクローズ・ヴォイシング、オクターブ以上に広げるオープン・ヴォイシング、上から2番目の音を1オクターブ下げてクリアにするドロップ2など、配置の流儀そのものもヴォイシングと呼びます。良いヴォイシングとは、(1) コード機能が聞き手に明確であること、つまり「今はG7でこれからCmaj7へ落ち着く」という行き先が耳で感じ取れること、(2) アンサンブルを濁らせないこと。特にジャズコンボではベースが低域を担当するので、ピアノやギターはむやみにルートや5度を重ねず、中低域をスッキリ保つ必要があります。(3) その曲のスタイルや空気感にふさわしい色（テンション）を持つこと。ビバップならタイトで機能的、モードやR&B寄りなら浮遊感やしなりを出す、といった具合です。(4) そしてボイスリーディング、すなわち各音が次のコードへ半音〜全音以内で自然に動くこと。滑らかな動きはプロらしい“伴奏の説得力”として聞こえます。まとめると、ヴォイシングとは単なる押さえ方ではなく、和音の中で何を喋らせ、どんな質感でバンドに置くかという、リアルタイムのハーモニーデザインそのものだと言えます。この感覚が身につくと、同じコード進行でもあなた独自の伴奏と世界観を提示できるようになります。つまりヴォイシングは、ジャズにおける声の表情そのものです。

「須磨の浦」は同じ神戸付近の海辺ですが、『源氏物語』と『平家物語』でまったく異なる意味を持ちます。

 「須磨の浦」は同じ神戸付近の海辺ですが、『源氏物語』と『平家物語』でまったく異なる意味を持ちます。『源氏物語』では平安中期（10世紀ごろ）の設定で、光源氏が政争に敗れて都を離れ、一時的に身を寄せる「流謫の場」として描かれます。荒い波音や嵐の夜などの描写を通じ、栄華からの転落、不安、望郷、そして後の復帰への転機が表現されます。これが須磨の浦の「孤独と再起」のイメージを決定づけました。これより時代が下る『平家物語』では、寿永3年（1184年）の一ノ谷の戦いの舞台として須磨の浦が登場します。ここでは平家一門が源義経らに破られ、西へ退き、若武者が討たれ、栄華が崩れる場面が語られ、盛者必衰と無常の象徴になります。物語内時間でも、成立年代でも、『源氏物語』の須磨が先、『平家物語』の須磨が後に位置します。

Apache Sparkは、分散処理エンジンです

 

1. Apache Sparkとは何か（前提）

Apache Sparkは、分散処理エンジンです。メモリ上でデータを扱うことで従来のHadoop系バッチ処理より高速に、大量データをバッチ処理・ストリーミング処理・機械学習・グラフ解析などに使えます。Python / SQL / Scala / Java / Rから利用できます。Amazon Web Services, Inc.
Sparkは1つのフレームワークでバッチとリアルタイム両方の処理、SQL分析（Spark SQL）、機械学習（MLlib）、グラフ解析（GraphX）までカバーする「統一エンジン」です。spark.apache.org+1

---

2. Sparkの主な実用パターン（ユースケース）

2.1 大規模ETL / データレイク整備

• 例：S3やデータベース、ログ、IoTイベントなど大量の生データを一気に読み込み、クレンジング・結合・正規化して分析用形式（Parquetなど）に変換する「ETL（Extract / Transform / Load）」バッチ。

• 特徴：Sparkは大容量バッチを一括処理するのが得意で、日次・時間毎の集計レポート生成やデータウェアハウス／レイクハウスへのロードに使われています。CData Software+1

• 組織的には「データレイクの心臓」として、部門横断で使われることが多いです。CData Software

2.2 ストリーミング／リアルタイム分析

• 例：クリックログ、センサー値、取引イベントなどが秒単位で流れてくるストリームをほぼリアルタイムで集計し、ダッシュボードや検知ロジックに反映。

• Spark Structured Streamingは継続的にデータを取り込み、ウィンドウ集計や異常検知を行えます。これは不正検知、レコメンドの即時更新、パーソナライズ広告などに使われています。AWS Documentation+1

• 典型的にはKinesisやKafkaなどのストリームからSparkで処理→結果をS3やRedshiftに格納、という流れがよくあります。AWS Documentation+1

2.3 機械学習・レコメンド

• Spark MLlib（機械学習ライブラリ）や分散データフレームを使って、大量データで学習するクリック率予測モデルやレコメンドモデルを学習する用途があります。

• 具体例として、Yelpは広告クリック率予測モデルの学習をSpark on Amazon EMRで行い、広告収益とCTR（クリック率）を改善したと報告されています。また、Washington Postは読者の行動データをSparkで解析し、レコメンドを最適化しています。Amazon Web Services, Inc.

• 特徴：大量データを反復学習するワークロード（勾配降下・特徴量生成など）では、Sparkの「メモリに保持したまま繰り返し計算できる」性質が効きます。Amazon Web Services, Inc.

2.4 対話型データ探索・BI支援

• Spark SQLを使って、巨大なログテーブルやイベントテーブルに対してインタラクティブにクエリを打って可視化・調査する使い方があります。バッチではなく“調査・仮説検証”フェーズでデータアナリストがよく使います。Amazon Web Services, Inc.+1

2.5 グラフ解析・つながり分析

• SparkのGraphXなどでソーシャルグラフ、ネットワークの中心性解析、レコメンド用の関係性グラフなどを分散計算するケースがあります。これは広告のターゲティング・ユーザー類似度推定・不正取引ネットワーク検出などに応用されます。Instaclustr

---

3. AWSでのApache Spark関連ソリューション

Spark自体はオープンソースですが、AWSは “クラスタのセットアップやスケーリングを代わりにやる” サービスを複数用意しています。以下が主な選択肢です。

3.1 Amazon EMR（Elastic MapReduce）

用途イメージ：フル機能のビッグデータ基盤 / 自由度高いSpark実行環境

• Amazon EMRはHadoop/Spark/Hiveなどのビッグデータ系OSSをマネージドで動かすサービスです。Sparkクラスタを数クリックで用意し、S3のデータを分散処理できます。Amazon Web Services, Inc.

• Spark on EMRは機械学習（MLlibによるスケールアウト学習）、ストリーム処理、インタラクティブSQL、ETLまで幅広くカバーします。Amazon Web Services, Inc.

• Amazon SageMakerと連携して、EMR上のSparkから学習・推論ジョブをSageMakerに渡すことも可能です。これは大規模特徴量生成をSparkで行い、その後のMLライフサイクル管理をSageMaker側でやる、という分業に向いています。Amazon Web Services, Inc.

• EMR Serverless：近年は“サーバレス版EMR”が提供されており、Sparkジョブを投げるだけで自動的に必要な計算リソースが立ち上がり・スケールし・終了します。クラスタ常駐管理が不要になり、アイドルコストを抑えられる、というのが狙いです。Amazon Web Services, Inc.+2AWS Documentation+2

  • ストリーミング（Spark Structured Streaming）もEMR Serverless上でスケールさせられるようになっていて、リアルタイム処理基盤としても使えます。Amazon Web Services, Inc.

  • Step Functionsなどとつなげて、バッチETLパイプラインや定期集計をワークフロー化することも一般的です。Amazon Web Services, Inc.

まとめると、EMRは「Sparkを含むビッグデータOSSスタックをほぼ素のまま使いたい」「チューニング自由度も欲しい」「でもインフラ管理は極力AWS側に任せたい」という場合の主力です。Amazon Web Services, Inc.+2AWS Documentation+2

---

3.2 AWS Glue

用途イメージ：サーバレスETL特化（データ整備・カタログ化）

• AWS Glueはサーバレスのデータ統合／ETLサービスで、裏側の実行エンジンとして最適化済みのApache Sparkランタイムを採用しています。GlueのSparkランタイムはオープンソース版Sparkより高速化・コスト削減のためにAWS側でチューニングされています。AWS Documentation+2Amazon Web Services, Inc.+2

• “ジョブ”単位でPySpark（またはSpark SQL変換スクリプト）を投げるだけで、Glueがインフラを自動で用意・スケール・終了します。管理するのはスクリプトとスケジュールだけです。AWS Documentation+1

• Glueにはクローラとデータカタログがあり、S3等のデータソースを自動的にスキーマ推定してメタデータ管理できます。これは組織横断の“データレイクの目録（データカタログ）”として使われます。CloudThat+1

• ストリーミングETLもサポートしており、Spark Structured StreamingベースでKinesis等のリアルタイムデータを取り込みつつクレンジング→S3/Redshiftに流し込むことができます。AWS Documentation+1

Glueは「分析用データをきれいに整備してRedshiftやデータレイクに流し込みたい」「とにかくサーバレスで、ETLパイプラインの管理コストを最小化したい」という場合に選ばれます。AWS Documentation+1

---

3.3 ストリーミング連携：Amazon Kinesis × Spark

用途イメージ：リアルタイムのイベント処理／監視／不正検知

• Amazon Kinesis（Data Streamsなど）は、クリックログ・IoTセンサー・アプリイベントなどを高スループットで取り込み、ほぼリアルタイムで下流に流します。AWS Documentation+1

• Spark Structured StreamingはKinesis Data Streamsのコネクタを通じて、専用スループット（Enhanced Fan-Out）で各シャードから2MB/秒レベルの読み取りが可能です。これにより、低レイテンシーでの集計・アラート・ダッシュボード更新・特徴量生成などができます。AWS Documentation+1

• この構成は「リアルタイム売上監視」「決済不正検知」「パーソナライズ広告の即時更新」のような、秒〜分単位の応答が必要なケースでよく採用されます。AWS Documentation+1

---

3.4 SageMaker連携（学習・推論のMLOps化）

用途イメージ：Sparkで特徴量生成 → SageMakerでモデル運用

• Spark（特にEMR上のSpark）は、巨大データから特徴量を生成・集計・前処理する部分に強い。Amazon Web Services, Inc.

• その後、Amazon SageMakerに渡して分散学習・ハイパーパラメータ最適化・モデルデプロイ（エンドポイント化）まで持っていく、という分業パターンが一般的になっています。Amazon Web Services, Inc.

---

4. ざっくり使い分けイメージ

シナリオ	向いているAWSサービス (Spark関連)	ねらい
データレイクのバッチETL／日次集計	AWS Glue（サーバレスSparkランタイム）	最小運用コストでETLを回したい
ストリーミングETL／リアルタイム分析	Spark Structured Streaming + Kinesis／EMR Serverless	数秒〜数十秒で検知・集計したい
ビッグデータの自由度高い分析・ML基盤	Amazon EMR / EMR Serverless（Sparkクラスター/ジョブ）	OSSスタックをほぼそのまま使いたい
特徴量生成から学習・推論まで一気通貫なMLパイプライン	EMR上のSpark + SageMaker	大規模データで学習し、そのまま本番提供したい

（上記はそれぞれのサービス公式ドキュメント・活用事例に基づき要約しました。InfoQ+4Amazon Web Services, Inc.+4AWS Documentation+4）

---

まとめ

• Apache Sparkは「大量データをまとめて変換・学習・分析」「リアルタイムで流れてくるデータを即座に処理」の両方を1つのエンジンでこなせるのが強みです。Amazon Web Services, Inc.+2spark.apache.org+2

• AWS側ではSparkをいちから自分でEC2に構築しなくても、

  • Amazon EMR / EMR Serverless（ビッグデータ/ML向けの高自由度クラスタ・サーバレス実行）Amazon Web Services, Inc.+2AWS Documentation+2

  • AWS Glue（サーバレスETL基盤。Glue 5.0は最適化Spark 3.5系でさらに高速化・低コスト化）Amazon Web Services, Inc.+1

  • Kinesis + Spark Structured Streaming（リアルタイム処理）AWS Documentation+2AWS Documentation+2

  • EMR ↔ SageMaker連携（特徴量生成から学習・デプロイまで）Amazon Web Services, Inc.
    という形で目的別のマネージド選択肢が揃っています。