マイクロエージェント：進化と知的創造の計算機科学

生命はどのような仕組みで機能しており、無生物の環境からどのように誕生したのでしょうか。完全に解き明かされていませんが、そこには生物を構成する化学物質による化学反応や、化学物質や生物の進化の積み重ねがあり、それを解き明かしていくことが、生命を理解する鍵になるはずです。

私はシステムエンジニアとして、この基礎となる化学反応と進化の仕組みを適切に模倣するシミュレーションシステムを実現するための基本設計について考えています。化学反応を直接的にシミュレーションすると膨大な知識とプログラム作成が必要になるため、できるだけ本質的に重要な抽象モデルを使って、生命の仕組みや起源の全体像を把握していくアプローチを取りたいと考えています。

こうしたシミュレーションシステムの基本設計を適切に行うために、生物の体内における化学反応の仕組みについて考えているうちに、一つの気づきがありました。

化学物質が液体中で様々な化学反応をして、それが生命維持や進化に意味のある処理を行っているという視点から見ると、そこにはコンピュータが行っている処理と同じように、インプットとアウトプットの連鎖によって処理が進行していることになります。しかし、処理の進行という全体像は同じように見えるものの、その基本的な処理方法が、根本的な異なるアプローチによって成立しているという点です。

それは、処理の連鎖の順序が、予め処理の順序が決まっているコンピュータプログラムの処理方法と、前の化学反応で出力された化学物質が次の化学反応を開始させるという化学回路の処理方法の違いです。

この記事では、この気づきに基づいて、化学回路の処理方法を計算機科学的な視点から分析し、それをデータと処理の関係として捉えなおすことで、マイクロエージェントアーキテクチャという考え方のシステム基本設計を提案します。マイクロエージェントアーキテクチャについて掘り下げて考えていくと、着想の元になった化学進化のシミュレーション以外にも、柔軟な適応性を持つ新しいシステム開発パラダイムへの応用や、知識の進化をさせるための仕組みとして、新しいタイプの人工知能技術やブレーンストーミングの自動実行システムなどにも応用が出来る可能性が見えてきます。

書いているうちに思いついた内容が広がってしまったため、長文になってしまいましたが、以下の本文で、詳しく見ていきましょう。

■処理順序の自由性

一般的なプログラムは処理順序を決めて実行することになります。この処理順序が入れ替わってしまうと、多くの場合、全く異なる処理結果に至る事になります。

一般的なニューラルネットワークは、層構造を持ち、入力層から出力層までの順序が決まっています。この処理順序が入れ替わると、学習した内容が崩れてしまうはずです。

このように、外部から与えられた構造として、処理順序が決まっている物が多くあります。

一方で、液体の溶媒の中に異なる複数の触媒となる化学物質が溶け込んでおり、最初の触媒により発生した化学反応により生成された化学物質が、別の触媒が発生させる化学反応の材料として使われる、という水中での化学反応の連鎖を考えてみましょう。

ここでは、化学反応、つまり化学的な処理の順序は構造的には決められていません。液体の溶媒の中で、それぞれの触媒はいわばフラットに溶け込んでいます。

そこに化学反応の材料となる化学物質が加えられたり、熱や光などのエネルギーが外部から与えられると、いずれかの化学反応が開始され、そこから処理の連鎖が起きていくことになります。

生物の細胞の中では、このような化学回路と呼ばれる化学反応の連鎖が多数行われています。その中には細胞内小器官や細胞骨格の構造によって処理順序が決まっているものもありますが、液体である細胞質の中で、フラットに処理が行われている場合もあります。

■液体中の化学回路の処理モデル

液体中の化学回路の処理モデルは、マイクロエージェントアーキテクチャと呼ぶことができると思います。

システムアーキテクチャの中で、エージェントはサービスと対となる概念です。

サーバが提供するサービスは、呼び出し元からサービスが呼ばれて処理を行い、呼び出し元に結果を返すという流れが基本です。

エージェントは、サービスを呼び出す主体となります。

サービス側ではマイクロサービスアーキテクチャという考え方があり、ある程度の小さな機能単位にサービスを分割する事があります。

マイクロエージェントは、この対となるアプローチです。つまり呼び出し側のプログラムを小さく分解するアプローチです。

ただし通常の手続き型のプログラムでは、マイクロエージェントの実現は難しいでしょう。手続き型のプログラムでは、処理の前後関係が重要です。

このため、小さく分解されサービスを単一のエージェントが順番に呼び出すマイクロサービスは実現しやすいものの、呼び出し側のエージェントを分解するマイクロエージェントの実現は、やりにくいはずです。

一方で、個々の細かいエージェントが他のエージェントとの順序関係を気にすることなく処理を実行できるような設計ができれば、マイクロエージェントが実現できます。これは、液体中の化学回路の処理モデルのようなものです。

■マイクロエージェントアーキテクチャ

液体中の化学回路の処理モデルを参考にすると、２つのレイヤをイメージすると、マイクロエージェントアーキテクチャを把握しやすくなることがわかります。

１つはエージェントのレイヤです。もう１つはデータのレイヤです。

エージェントはデータを監視しておき、入力になるデータがあれば、それを処理して出力データを生成します。

このように各エージェントが、他のエージェントから処理を引き継ぐのではなく、データを監視しておき、それをトリガーとすることで、お互いの処理順序を気にすることなく、個々のエージェントの処理を設計することができます。

こうすることで、個々のエージェント毎に処理の精度や速度を改善や不具合の修正を行ったり、別の入力や出力を加える機能拡張を行ったりする事が容易になります。

この際に、１つの種類のエージェントの処理を、複数の処理実体が並行して実行できるような設計をしておけば、処理時間を短くすることができます。

これは化学回路における触媒の数が増えれば、並行して化学反応が進行できることと同じです。このためには、入力データと出力データの入れ物にボトルネックが生じないように設計することが重要です。

複数の処理実体が同時並行でアクセスすることができない単一のファイルやテーブルにデータを詰め込んでしまうと、そこがボトルネックとなります。

■データレイク

液体中の化学回路の処理モデルにおけるデータの入れ物は、いわゆるデータレイクです。

通常のプログラミングやシステム設計では、扱うデータの種類毎に、特定の型の変数やファイルやテーブルにデータを入れておきます。通常、同じ入れ物には同質のデータを入れておき、その入れ物を多数用意しておきます。

そしてプログラムやシステムは、必要なタイミングで必要な入れ物からデータを取り出して処理し、別の入れ物に結果を保存します。

これに対して、データレイクは多様なタイプのデータを入れられる１つの入れ物です。異なる質のデータであっても、データレイクの中に全てフラットに入れておくことができます。

■対流型データ処理

フラットに多種のデータが入っているデータレイクに対して、多数のマイクロエージェントがアクセスする事を考えてみます。

液体中の化学回路の処理モデルでは、エージェントとデータは対流を通して出会います。

あるタイミングで、それぞれのデータは１つのエージェントからしかアクセスされません。反対に１つのエージェントは、あるタイミングでは１つのデータのみにアクセスします。

そして、エージェントは処理対象のデータであるかどうかに関わらず、順番にデータにアクセスします。多数のエージェントが、お互いに異なるデータにアクセスし、それが終わったらまたお互いに重ならないように次のデータにアクセスします。

このためには、並んでいるデータに対して、エージェントがランダムにアクセスしたり、別々の順番でアクセスすると上手くいきません。

全てのエージェントが別々のデータにアクセスしつつ、同じ順番で次のデータにアクセスするという共通のルールでデータアクセスをすればよいのです。

これは液体中で対流によって化学物質動作が順番に出会う様子に似ています。

このようにデータレイク内のデータに多数のマイクロエージェントが同時並行で順番にアクセスする処理を実現するプラットフォームを、対流型データ処理と呼ぶことにします。

■並列処理

同じ型のデータや全く同じデータもデータレイクに入ることが可能です。また、全く同じ処理をするマイクロエージェントを稼働させることもできます。

対流型データ処理の仕組みでも、これを利用して、同じ処理を複数の同じ処理をするマイクロエージェントで並列実行させて処理スピードを早くしたり、エージェントの数を減らして遅くしたりすることができます。

■リング状のリンクリスト

マイクロエージェントが処理した結果もデータレイクに入れることで、そのデータを処理する事ができるマイクロエージェントが、やがてそのデータにアクセスして、処理が行われます。

対流型データ処理を行う場合、データレイクのデータには、データのアクセス処理順序を一元的に管理する仕組みを設けると、そこがボトルネックになります。このため、各データは前のデータと後のデータへのリンクを持たせるようなリング状のリンクリストにしておく事が適切です。

これにより、処理結果をデータレイクに追加した際に今のアクセスしていたデータの場所に挿入したり、処理し終えたデータを削除したりする処理も、分散実行が可能になります。

■排他制御

エージェント毎に１つのデータの処理の時間は異なります。その結果、複数のマイクロエージェントがデータを同じ順番に処理するとしても、同じデータにアクセスするケースがあります。

このため、マイクロエージェントはデータアクセスの際にデータにロックをかけておき、処理を終えたらロックを解除する必要があります。

そしてロックがかけられているデータにアクセスしようとした場合は、処理が終わるのを待たずに、スキップします。そうしないと全てのエージェントが、最も遅いエージェントの処理時間に合わせてしか処理できなくなるためです。

■オペレーターとしてのマイクロエージェント

プログラミングの用語でオペレーターとは、足し算や引き算のように、比較的シンプルな演算を意味します。

これは、プロセッサの処理で言えば機械語の命令に相当します。

マイクロエージェントは、究極的にはオペレーター単位まで分解が可能です。

オペレーターが処理するデータ数は単一のものから複数のものまであります。

例えば、数値の符号を反転させるオペレーターは単一の数値データのみを処理します。足し算や引き算などは２つの数値データを処理します。

■処理データと結果の扱い

マイクロエージェントがデータを処理した際に、元のデータをどう扱うか、処理結果のデータをどう扱うかについての検討が必要になります。

元のデータは、消去してしまうのが一般的だと思われます。そして結果データは、新たにデータレイクに保管することになります。

■構造化

１つのデータレイクだけでなく、複数のデータレイクを使ったマイクロエージェントアーキテクチャのシステムも考えられます。

この場合、一部のマイクロエージェントが、処理した結果データを別のデータレイクに入れるという役割を担います。

これは一部のデータを別のデータレイクに移動させるという使い方もできます。そこからさらに別のデータレイクに移動させるということを行えば、ワークフロー処理のようなものを実現できます。

また、データをコピーする事でデータレイクをバックアップすることもできます。これにより、本来のデータレイクのように長期保管用のデータレイクにはデータが消えないように残しつつ、作業用のデータレイクで処理を行うといったことを実現できます。

また、地理的に離れたところにデータ収集用のデータレイクを分散しておき、そこから共通のデータレイクへとコピーすることでデータ収集の効率化とデータの一元化もできるでしょう。

■処理効率化

また、大きなデータレイクではマイクロエージェントの対流処理の効率が悪いため、効率的な処理にするために小さなデータレイクにデータを移すというアプローチにも使えます。

この場合、大きなデータレイクの周りに小さなデータレイクを用意することになります。移動あるいはコピー用のマイクロエージェント毎に１つの小さなデータレイクを割り当てる構造です。

小さなデータレイクに入れるデータとそこで巡回しているマイクロエージェントが同一なものが多数あれば、同種のデータを同時並列で処理する場合に活用できます。

異なるデータを異なる小さなデータレイクに分けることで、データを分類して処理を効率化することもできます。

■ライブデータブランチ

データを別のデータレイクにコピーすることで、元のデータやシステムへの悪影響を与えずに、新しいシステムの開発や実験が可能になります。

これはソフトウェア開発時にソースコードのリポジトリから作業用のブランチを作る作業に似ています。

マイクロエージェントによるデータレイクのコピーの場合、元のデータレイクへのデータ追加時にも、自動的にブランチ側のデータレイクにもデータが反映されます。いわばライブデータのブランチです。

■ライブシステムブランチ

すでに開発したライブデータブランチ上のシステムがある場合、そのシステム全体をブランチのようにコピーすることもできます。

元のデータレイクからデータをコピーするマイクロエージェントを含んだ、そのブランチに関わっている全てのマイクロエージェントを丸ごとコピーして、元のデータレイクに接続すれば実現できます。

これにより、元のデータだけでなくシステムにも悪影響を与えることなく、システムへの機能追加や改良や不具合修正が可能になります。

これはライブシステムブランチと呼べるでしょう。

■化学回路から生物システムへ

化学回路から発想を得て整理したマイクロエージェントアーキテクチャが、ライブシステムブランチを実現できることは、化学の分野の方への視点を提供します。

それは、ライブシステムブランチが、生物の成長や進化の仕組みに現れているということです。

多細胞生物は、１つの胚細胞や卵細胞から細胞分裂を行って発生し、成長していきます。

この際に、各細胞内部では化学回路の処理が止まることはありません。また、全く同じ細胞に分裂することもあれば、性質や役割が異なる細胞になる場合もあります。

この様子は、まさにライブシステムブランチの仕組みに現れています。

■オペレータコードの集合としてのDNA

また、新しい個体は親の個体からDNAで遺伝情報を引き継いでいます。

この際に、変異や交配により親とは一部の遺伝情報が異なる場合があります。この交配や変異が、進化を生み出すことになります。

この様子は、元になるシステムから全てのマイクロエージェントをコピーして作られたライブシステムブランチへ改変を加える作業に相当します。

この時、DNAが全てのマイクロエージェントのソースコードの集合となります。そのDNAから、実際に様々な化学反応を発生させるタンパク質が生成されます。

このタンパク質はいわばオペレータです。

■生物におけるマイクロエージェントアーキテクチャ

人間がシステムを改変する場合は、元の仕組みで必要な部分を壊さず、改良されることを知的に判断して改変します。

このため、僅かな順序変更やエラーでも、システム全体の動作不良を引き起こすような従来の手続き型のプログラムでも良かったのです。

しかし、生物における交配や変異はランダムです。このため、手続き型のプログラムのように僅かな変更で全体が機能しなくなるような仕組みでは、繁殖と進化を両立する事が困難です。

そこでは、マイクロエージェントアーキテクチャが適しているのです。

マイクロエージェントアーキテクチャであれば、処理の順序はプログラムには埋め込まれておらず、データレイク内のデータの状態で決定されます。このため、プログラムの改変でデータ状態と処理手順が不整合を引き起こすことがありません。

また、ランダムな変更により一部のマイクロエージェントがエラーを起こして機能しなくなっても、他のマイクロエージェントは動作し続けます。

さらに、複数の種類のマイクロエージェントが同居して処理を行うため、ほとんど似たような処理を行う複数種のマイクロエージェントが共存することができます。

これは、ランダムな変更で機能しなくなったマイクロエージェントがあっても、似た処理を行うマイクロエージェントが処理を継続することで、システム全体の機能不全は回避できることを意味します。

加えて、新種のマイクロエージェントが、重要な処理を阻害するケースも考えられます。同時並行で他のエージェントが分散して処理していることで、新種のマイクロエージェントが全てを阻害する前に、正規の処理を行うマイクロエージェントが部分的には通常の処理を進行させます。

これらの観点から、マイクロエージェントアーキテクチャはランダムな変化に対して堅牢な仕組みと言えます。これが、生物の繁殖と進化にとって、マイクロエージェントアーキテクチャが適している理由です。

■化学進化におけるマイクロエージェントアーキテクチャ

マイクロエージェントアーキテクチャが、化学回路をモデル化しており、これが生物のシステムの性質を説明できる点は、さらに興味深い視点を提供します。

それは、化学進化です。

進化とは一般的にはDNAによる遺伝構造の自己複製と変化、そしてその遺伝情報の自然淘汰により発生する現象と捉えられています。これは、生物の進化です。

一方で、化学物質も増殖と変化と自然淘汰により、進化する場合があります。それが化学進化です。

先ほど説明したように、生物の進化はマイクロエージェントアーキテクチャの視点から見れば、オペレータコードの集合であるDNAと、そこから生成されるオペレータであるタンパク質の集合の処理によって成り立っています。

つまり、マイクロエージェントアーキテクチャの観点からは、進化はコードとオペレーターの処理によって成立していることになります。

この事は、生物ではないものであっても、コードの役割とオペレータの役割があり、マイクロエージェントアーキテクチャの処理環境があれば、進化は進行することができるということです。

化学物質は、この条件を満たします。マイクロエージェントアーキテクチャはもともと液体中の化学物質の反応の連鎖をモデル化しています。

そして、コードとしてのDNAやRNA、オペレータとしてのタンパク質やRNAは化学物質です。また、これらに限らず、他の化学物質も、部分的にコードやオペレータとして機能する場合も考えられます。

■マイクロエージェントアーキテクチャの応用

この事は、マイクロエージェントアーキテクチャが化学進化のシミュレーションに適している可能性が高いことを示しています。

化学進化のシミュレーションの設計が難しいところは、新たに生成された化学物質が、次々に新しい化学反応を起こす事を模擬する部分です。

新しい化学反応を起こす化学物質は、シミュレーション上では一種のオペレータとして表現する必要があるため、単に化学物質をデータをとして加工するだけでなく、加工されたデータがオペレータにもなるということが必要です。

これを通常の手続き型のプログラムの発想でシミュレーションモデルにすることが難しいのです。

マイクロエージェントアーキテクチャであれば、データレイクに新たに加わったデータを、データとして解釈しながらもオペレータとしても扱うことが容易です。また、処理を大規模にして分散並列化してシミュレーションを進行させる場合にも適しています。

さらに、化学進化の過程では、化学物質を一時的に専有したり、他の化学物質から接触されないように隔離したりする場合があります。脂質の膜に閉じ込めてその中で化学反応をするといった構造です。これも複数のデータレイクの構造化によりシミュレーションできます。

このように、マイクロエージェントアーキテクチャを活用して上手く化学進化をシミュレーションできると、疑似的な生物のようなシステムの発生までも観察できる可能性が出てきます。

■論理進化

化学進化や生物の進化は、自己進化するシステムの具体例です。

これをマイクロエージェントアーキテクチャで再現できるなら、より抽象的な進化の仕組みが理解できるようになるかもしれません。それは論理進化と呼べるでしょう。

抽象的な論理進化の原理が明らかになれば、化学進化や生物の進化と同様な性質を持ちつつ、現実の物理法則や化学物質の特性とは無関係の法則の中で、論理的に進化現象を観察できます。

■論理進化の先にある人工知能

これを応用すれば、進化に必要な法則面での条件が明らかになります。そして、生物が地球の科学環境で繁栄したように、様々なデータセットや知識分野の上で自己進化して繁栄するシステムを生み出すことができるかもしれません。

これは、一種の人工知能のようなものです。

ただし、現在の人工知能が脳の学習の仕組みから影響を受けたニューラルネットワークをベースにしているのに対して、こちらは生物や化学物質の進化の仕組みに基づいているという点で、異なるアプローチです。

ニューラルネットワークが既存のデータや知識のパターンを学習するのに比べて、マイクロエージェントアーキテクチャは学習でなく、それらのデータや知識の上で進化をするという点が、特に大きなアプローチの違いです。

学習の本質は真似をすることにあり、現在の人工知能は人間の真似を高度に行っていると考えることができます。一方で進化は
本質的に創造です。地球と全く同じ環境を与えられても、おそらくそこでは地球で起きた進化とは異なる道を辿り、異なる生態系と生物が想像されるでしょう。

この事は、人工知能が学習により既存の考え方や知識を再現するのか、根本的に全く異なる知識体系や考え方を進化させていくのか、という差異をもたらすでしょう。

■ブレーンストーミングへの応用

この仕組みは、例えば小説のような創作や、新しい学問的なアプローチの発案、新規ビジネスや商品のための検討などのように、既存の考えよりも新しいアイデアが求められる分野で有用でしょう。

この場合、前提となる知識やアイデアと、異なるバックグラウンドから得られた知識やアイデアを一か所に集めて、それらを使って検討することが望ましいとされています。また、検討の中で新規に生み出された知識やアイデアも、既存のものと併せて次の検討に利用できるようにすることも重要です。

これは良く知られたブレーンストーミングというアイデア検討方法です。この場合、知識やアイデアは文章であったり図表であったり、イラストや写真のようなものも含むでしょう。

このため、ブレーンストーミングはマイクロエージェントアーキテクチャに上手く適合します。知識やアイデアはデータレイクに保持しておくことで、異なるデータ元からデータレイクに集めたり、検討で得られたものを同じデータレイクに保存することも容易です。

そして、集められた多数の知識やアイデアの全体を眺めたり、一部だけを抽出してそれらにフォーカスを当てたりして、アイデアの深堀りを進めていくことになります。こうした作業は順不同で、並列に別々の主体が実施すれば良いため、マイクロエージェント的に分散処理が可能です。

既存の知識やアイデアから新しい発案を行う作業は、通常は複数の人で行う事になりますが、アイデア検討のルールを様々なプロンプトで表現すれば、大規模言語モデルを使った会話型AIを活用することができます。１つのプロンプトを使って会話型AIにデータレイクのデータを与える仕組みをマイクロエージェントとして実装すれば、同時並行で多数のマイクロエージェントを使ってブレーンストーミングを行う仕組みができるわけです。

ここで、プロンプト自体も１つの知識としてデータレイクに入れて、多数のエージェントに異なるプロンプトや知識をシステムプロンプトとして与えるようにし、時々システムプロンプトを入れ替えたり、検討の中で新しいプロンプトを発案するような仕組みにすれば、自動的にブレーンストーミングをし続けるシステムが構築できます。

このままでは有用なものもあまり意味のない知識やアイデアやプロンプトがデータレイクに溢れていきます。また、マイクロエージェントの数が多くなると処理コストもかかりますので、エージェントの多様性を保ちながらも数を調整する仕組みも必要になるはずです。このため、時々、データやエージェントの集約や整理をすることが必要になるでしょう。

また、知識やアイデアが活発に出てくる時期と、マンネリ化して同じような物しか出てこなくなる時期もあるでしょう。この場合は、ランダムな変化を持ち込んで刺激したり、外部から新しい知識やアイデアを取り入れることも必要です。

このように状況を評価して、集約や整理、ランダムな変化や新しい知識を持ち込むことも、マイクロエージェントとして実現できます。

■さいごに

生命の起源、および、人工知能を含む知性の本質について考える事を、私は個人研究のテーマとしています。

マイクロエージェントアーキテクチャは、生命や知性の持つ特定の側面を上手く反映したコンピュータシステムの基本アーキテクチャとなる可能性があります。

複雑なシステムは多面的な性質を持つため、システムのアーキテクチャはどれか一つを選ぶというよりも、その多面性に合わせて、複数のアーキテクチャを統合していくことが重要です。その意味で、既存のアーキテクチャだけでは上手く扱えない側面がある場合、新しいアーキテクチャを考え出すことが重要です。そして、その新しいアーキテクチャに全てを載せ変えるのではなく、新しいアーキテクチャに基づいたサブシステムを追加することになります。

マイクロエージェントアーキテクチャも、それ単独でシステムの全てを扱おうとすれば、効率が悪くなるでしょう。分散型の複雑系のシミュレーションであったり、進化や創造を伴う仕組みが必要な部分に焦点を当てて適用することで、既存のシステムに新たな側面を加えることが可能になるというのが、マイクロエージェントアーキテクチャの真価となると私は想像しています。