ハッカー倫理に準拠した人工知能のアーキテクチャ設計

スポンサーリンク

Accel Brain; Console×

派生問題:オブジェクト指向は如何にして可能になるのか

RUP機能は、拡張と再利用が可能なパッケージとしての開発プロセスを提供すると共に、反復型アーキテクチャ中心設計漸進的ユースケース駆動型開発の区別を導入することによって、短いタイムスパンとリードタイムで<結果>を少しずつ目に見える形で提示していくことにある。

それ故RUPは言わば小刻みなPDCAサイクルの絶え間ない反復を指し示している。方向付けフェーズでは既に「企画」の水準でシミュレートされた<結果>が要求され、遂行フェーズではアーキテクチャ・ドライバの特定に留まらずユースケース・モデルやプロトタイプによる<結果>の視覚化が求められる。制作フェーズは「ベータ版」開発として位置付けられ、移行フェーズすら「過渡期」と見做される。RUPはこの動的なサイクルの反復によって矢継ぎ早に<結果>を出し続けることで「速度」の問題を解消していく。

しかしRUPはそれ自体で完結した「マニュアル」ではない。これは「ライブラリ」のようなもので、各組織システムの開発プロジェクトに導入されて初めて成り立つ。RUPは、導入先の組織の企業文化やプロジェクトのユースケースに応じて、その都度「設計」されなければならない。

これを前提とすれば、オブジェクト指向設計思想は、RUPを運用する場合にせよ、RUPを実践する場合にせよ、重要な位置付けにある。RUPオブジェクト指向設計を推奨している。しかしそれだけではなく、RUPを運用する上ではオブジェクト指向設計思想に基づいた分析が必要になる。

問題解決策:概念水準と仕様水準と実装水準の区別

オブジェクト指向を理解するには、前段階として、「オブジェクト指向分析(Object-oriented analysis)」で言及すべき「概念水準の観点(conceptual perspectives)」、「オブジェクト指向設計(Object-oriented design)」で言及すべき「仕様水準の観点(specification perspectives)」、「オブジェクト指向プログラミング(Object-oriented programming)」で言及すべき「実装水準の観点(implementation perspectives)」の差異を理解しなければならない。この差異は、二重の区別によって成り立っている。つまりオブジェクト指向分析オブジェクト指向設計オブジェクト指向プログラミング区別と、概念水準(conceptual level)と仕様水準(specification level)と実装水準(implementation level)の区別だ。

責任としてのオブジェクト

オブジェクト指向におけるオブジェクトは単なる「データと操作の集合体」ではない。この前提に立ってしまうと、上述した三つの区別を理解することはできない。むしろオブジェクトは「責任」を意味する。インスタンスは責務を遂行する実体に他ならない。

概念水準のオブジェクト指向分析

RUPのようにオブジェクト指向に準拠した開発プロセスでは、まず全てのソフトウェアを網羅的に設計するのではなく、アーキテクチャ・ドライバに関わる基本的な仕様となるサブセットを設計していく。そのためには、まず開発しようとしているオブジェクトが「そもそも何なのか(What)」を特定しなければならない。初めからそのオブジェクトの「実装は如何にして可能になるのか(How)」を考えてしまっては、何を造れば良いのかも定まらない状況で開発を進めることになるため、不確実性が高まってしまう。

この「そもそも何なのか(What)」、すなわち「何の責任を担うのか」を特定する営みを概念水準での分析と呼ぶ。この分析の具体名がオブジェクト指向分析であると考えて良い。

実装水準のオブジェクト指向プログラミング

一方、やはり最終的には「実装は如何にして可能になるのか(How)」も決定しなければならない。この営みが実装水準となる。そして、この実装方法オブジェクト指向プログラミングということになる。

しかし、一つの開発で要求される責任が単一とは限らない。複数の責任問題となる場合、複数のオブジェクトが必要になる。場合によっては、オブジェクト同士を結合することで、複合的な責務を担保しなければならなくなる。

仕様水準のオブジェクト指向設計

そこでオブジェクト指向では特に、複合的な責任を果たそうとしている複数のオブジェクト結合部分となる公開インターフェイス仕様化が目指されることになる。ここでいう公開インターフェイス仕様化とは、あるオブジェクトがそのオブジェクトを「如何にして利用できるのか(How)」を共有する営みを意味する。

いわゆる「仕様」とは、インターフェイスのHow to use it.に他ならない。使い方がわからなければ、仕様書など無いも同然だ。そして、この仕様を共有する営みこそがオブジェクト指向設計に他ならない。GoFのデザイン・パターンは、まさに共通言語化による共有を目指した産物だった。

概念水準の分析結果と仕様水準のインターフェイスを介したコミュニケーションのメリット

概念水準仕様水準で要求や仕様の共有を行なえば、システムの概要を伝達することができる。実装水準コードの詳細を知らなくてもコミュニケートすることが可能になる。例えばRUPのソフトウェア要求定義やアーキテクチャ設計は、まずこの概念水準仕様水準でのみシステムを分析して設計していく。

この区別を導入していると、概念や仕様を変更せずに実装を変更することができるため、コードが改修されたとしても、その実装の詳細を知らない者でも、インターフェイスを介してそのオブジェクトを利用し続けることができる。これは、インターフェイスのユーザーを実装の変更による影響から守ることを意味する。

REST(ful)の仕様は、この概念と仕様の水準でコミュニケートしたわかり易い事例になっている。各APIのユーザーは、連携先のシステム内部の具体的な実装内容を全く知らない状態であっても、仕様として規定したHTTP(S)リクエストとレスポンスの形式に従うだけで、そのAPIを運用することができる。

機能テストと結合テストと単体テストの差異

オブジェクト指向を以上のように区別すると、テスト概念も適切に整理することができるようになる。「機能テスト(Functional test; System test)」と「結合テスト(Integration test; Interface test)」と「単体テスト(Unit test)」の差異は、責任という概念を前提として、概念水準仕様水準実装水準差異に対応している。

次のように纏めても良い。

以下、もう少し詳述する。

機能テストの前提

機能テスト概念水準の検証になる。「そもそも何なのか(What)」、すなわち「何の責任を担うのか」に関する当初の予定と、実際に実装されたコードをはじめとした成果物との間に矛盾が無いことを確認していく。

RUPの場合は特に、ソフトウェア要求定義などで取り上げたユースケース図やユースケース記述に成果物たるオブジェクトが対応し切れるか否かを検証する。いわゆる「ユースケース・テスト」は、ユースケース・モデルとコード同期関係を確認するテストに他ならない。オブジェクト指向分析で組み立てたモデルと実際のコード同期していなければ、そもそもその成果物は何の責任も果たしていないことになる。無価値と見做されても致し方ない。

「ユースケース・テスト」に象徴されるように、一連の機能テストでは、システムの内部を事実上考慮しない。丁度、ユースケース図がアーキテクチャの内部を事実上考慮しない理屈と同じだ。その意味機能テストは「ブラックボックステスト」であり、「限界値分析」や「同値分割」は「ユースケース・テスト」の機能的等価物として採用されても構わない。

結合テストの前提

結合テスト仕様水準の検証になる。仕様によって共有されるのは、そのオブジェクトが「如何にして利用できるのか(How)」だ。したがって結合テストで検証すべきなのは、そのオブジェクトインターフェイスが本当に仕様で規定されている通りに利用できるか否かになる。

言い換えれば、結合テストでは、インターフェイス同士の結合を検証する。これにより、各オブジェクトインターフェイスを介した相互利用が「仕様通り」に実現することを確認する。オブジェクト指向設計で組み立てたインターフェイスに関するモデルと実際のコード同期していなければ、使用で説明しているHow to use it.に矛盾があるということになる。

その影響は他のオブジェクトに波及している。もし矛盾が見受けられるのならば、そのインターフェイスを抱えているオブジェクトの改修が必要になる。これは一種の「手戻り」であり、別途で退行テストが必要になる。ここでいう退行テストは、概ね単体テストのやり直しと考えて良い。

結合テストケースを考察する上では、多くの場合「粒度」が問題になる。同じ結合部分でも、「APIとAPIのマッシュアップ」と「PHPとMySQLの結合」とでは、粒度に差異が生じる。しかしこの問題に対する普遍的な正解は無い。どの粒度が適切なのかは、専らオブジェクト指向設計で選択する必要がある。

単体テストの前提

単体テスト実装水準の検証になる。つまり、「如何にして実装されるのか(How)」が問われる。詳細クラス図やシーケンス図やコミュニケーション図は実装を手引きしてくれるモデルとしても機能する。

しかしながら、実際のコードがこれらのモデルと同期していなければ、仕様を満たせないオブジェクトとして実装されている危険がある。また、モデルとコード同期していないということは、後続の開発でそのモデルを見直しても、現状のコードを俯瞰的に観察することが不可能になる。これは、ソフトウェアの全体像を把握することが不可能であるということになるため、後続の開発者との仕様水準でのコミュニケーションが事実上不可能になっていることを意味する。

一般的に単体テストは致命的なバグを取り除くデバッグ作業と見做されている。いわゆる「ホワイトボックステスト」や「デシジョンテーブル」では、「分岐網羅」や「命令網羅」や「条件と動作の差異」などのような概念によって網羅性が問われている。

しかし、こうした網羅性の問題は二次的な問題として格下げしてしまって構わない。仮にあらゆる条件や可能性を考慮したテストを実施したところで、最終的に提出される成果物たるコードがモデルと同期していないようでは、利用価値が無い。後続の開発による保守や拡張において、モデルによる俯瞰的な全体像の観察ができないようでは、「再利用」の対象にはなり得ない。

むしろ単体テストの時点で消化しておくべきなのは、「クラス構造テスト」などのような静的テストだろう。個々のオブジェクトにバグが無い場合であっても、クラス間の継承、多重度、凝集度、可視性などによって、思わぬ修正や機能追加を余儀無くされる場合もある。

問題解決策:RUPと既存の開発プロジェクトの「共通性/可変性分析」

以上のオブジェクト指向設計思想を前提とすれば、RUPを開発プロジェクトに導入する場合にも、オブジェクト指向で考えていかなければならないことがわかる。と言うのも、RUP拡張可能性と再利用可能性を確保したパッケージとして提唱されているからだ。この意味で言えば、RUPの運用や実践は等価機能主義的になる。言い換えれば、RUPと既存の開発プロジェクトの関係は相互にブラックボックス化されている必要がある。

ジム・コプリエンが提唱したオブジェクト指向分析の一つである「共通性/可変性分析(commonality/variability analysis)」は、ソフトウェアが相対する問題の領域を設定する上での問題解決策であった。しかしこの分析方法は、RUPと既存の開発プロジェクトの関連においても再利用されるべきであろう。

共通性分析と可変性分析の差異

共通性/可変性分析は文字通り「共通性」と「可変性」の区別を導入する分析だ。ただしこの区別は、概念水準仕様水準実装水準区別と重なり合っている。

共通性分析は、カプセルの中で纏め上げることで共通化することが可能な流動的諸要素の属性を意味する。一方で可変性分析は、共通化した場合に、特定のユースケースで逸脱し得る流動的諸要素の属性を意味する。

共通性分析の観点は、概念水準仕様水準に向けられる。可変性分析の観点は、仕様水準実装水準に向けられる。共通性分析における仕様水準の観点によって、「概念水準から観た場合に共通して立ち現れる諸概念」を網羅して参照できる「インタフェースの仕様」を洗い出すことが可能になる。一方、こうしてある仕様水準共通性が設定されることで、その共通部分との「差異」を伴わせる特化型のユースケースに対応した実装水準方法を決定付けることが可能になる。

共通性の観点から、言わば共通する諸概念を纏め上げた抽象クラスが抽出される。一方これに対して可変性の観点からは、当該抽象クラスの共通処理部分との「差異」に対応付けるように、特化した処理を記述すべき具象クラスが抽出される。

自己論理的なオブジェクト指向のシステム合理性

RUPの開発プロセスを既存の開発プロジェクトに導入する場合には、既存の開発プロジェクトとの共通性可変性区別できるようにしておいた方が無難だ。既存の開発プロジェクトと共通している部分については、そのまま抽象化して関連付ければ良いだろう。だが可変となる部分に関しては、RUPを導入した場合の個別具体的なプロセスを明確化しなければならない。

例えば関数型プログラミングが根付いている開発プロジェクトに対してRUPを導入する場合には、関数型プログラミングとオブジェクト指向プログラミングの「差異」を意識せざるを得なくなるはずだ。既存の開発プロジェクトには、既に関数型プログラミングを前提とした設計思想が普及しているかもしれない。可変のメンバ変数に対する参照すら許さないプロジェクトのアサインメンバーに対してオブジェクト指向へのパラダイム転換を要求して従事させるのは至難の業だ。

尤も、この関数型プログラミングとオブジェクト指向プログラミング差異に付随する問題に限って言えば、典型的には概念水準仕様水準実装水準区別の導入をそれこそオブジェクト指向分析的に実践することによって解消できるだろう。何故なら、関数型プログラミングとオブジェクト指向プログラミング差異は、精々のところ実装水準の全般と仕様水準の一部の問題でしかないからだ。たとえRUPの開発プロセスに従わない関数型プログラミングの担い手が実装水準を担当していたとしても、その成果物が仕様水準指し示した公開インターフェイス仕様を満たしてさえいれば、その関数型プログラミングが有害になることはあり得ない。

無論、このことの前提にあるのは概念水準仕様水準アーキテクチャ設計が徹底されているということだ。とりわけアーキテクチャ中心設計によって抽出されたアーキテクチャ・ドライバは、オブジェクト指向的には概念水準仕様水準にしか対応しない。実装水準に対応するのは、アーキテクチャ設計とは区別される詳細設計だ。

つまり、アーキテクチャ・ドライバの抽出をはじめとしたアーキテクチャ中心設計オブジェクト指向分析オブジェクト指向設計によって実践するソフトウェア・エンジニアやアーキテクトは、あくまでも仕様水準を介した詳細設計とのブリッジを心掛けることが求められる。そして、その仕様水準指し示しインターフェイス仕様が守られている限りにおいて、アーキテクチャ設計者は詳細設計者に自由度を提供しなければならない。言い換えれば、オブジェクト指向設計を実践するアーキテクチャ設計の担い手は、仕様水準における「非オブジェクト指向設計的な詳細設計」や、実装水準における「非オブジェクト指向プログラミング」の担い手たちさえも許容しなければならない。

これこそが、オブジェクト指向を自己論理的に適用した場合に到達する結論だ。オブジェクト指向的なアーキテクチャ設計を担当するソフトウェア・エンジニアやアーキテクトは、言わば仕様水準詳細設計実装水準のプログラミングという活動そのものをブラックボックス化して観察しなければならない。我々は、オブジェクト指向を徹底すればするほど、非オブジェクト指向に対してすら寛容にならなければならないのである。もはやアーキテクチャ設計を敢行する我々にとって、例えばアラン・ケイのメッセージに耳を傾けることも、ビヨルネ・ストロヴストルップと共に『オブジェクト指向とは何か?』を論じることも、二次的な問題でしかなくなる。オブジェクト指向と非オブジェクト指向区別をこの区別そのものに再導入(re-entry)することにより、非オブジェクト指向をもオブジェクト指向的に参照することを以って、アーキテクチャ設計システム合理性を確保していく必要がある。

問題解決策:UML

オブジェクト指向分析オブジェクト指向設計が広く採用されるようになったのは、1980年代からである。開発現場への普及に伴い、徐々に設計方法も多種多様となっていた。少なく見積もっても、数十の方法が混在していたという。その結果として開発現場では、伝達したい情報は同じであっても、表記法が異なるが故に混乱を招くようになっていた。

こうして分裂状態にあった方法の中でも、とりわけ多くの開発者たちが利用していたのは、次の3つの方法に大別できる。第一の方法は、ジェームズ・ランボーの「オブジェクトモデリング技法(Object Modeling Technique: OMT)」である。この方法は、分析対象領域をオブジェクトモデル、動的モデル、機能モデルの3つの観点で区別する分析表現法として提唱されていてた。第二の方法は、グラディ・ブーチによる「ブーチ法(Booch method)」である。この方法UMLの特にクラス図の起源の一つとなっている。そして第三の方法は、イヴァー・ヤコブソンの「Objectory法」である。この方法はユーザーの要求をユースケースでモデリングしていく分析方法である。

1990年代になると、これら3つの代表的な方法が統合されるようになる。1994年、ブーチが勤務していたラショナルソフトウェア社にランボーが合流したことで、まずOMTとブーチ法が統合されることになる。その際、統合された方法論はUnified Method 0.8と名付けられていた。この「Unified Method」という命名には、「開発方法の統合」という理念がまだ潜んでいた。しかし、この理念は必ずしも十全に継承されていった訳ではない。実際、続く1995年にはヤコブソンがこの統合プロジェクトに参加することになった。これにより、OMT、ブーチ法、そしてObjectory法を採り入れたUML0.9が誕生した。この方法の主導的差異構成したのは、開発プロセスと表記法の区別である。これによりオブジェクト指向分析オブジェクト指向設計は、個別具体的な開発プロセスの規模や種類に拘らず、独立した固有の表記法を手にすることになる。UMLは開発プロセスに依存しない、表記法としての抽象性を獲得したのである。

その後もUMLは順調にバージョンアップされていった。2000年代から策定され始めたUML2.0になると、「モデル駆動アーキテクチャ(Model Driven Architecture: MDA)という設計思想が導入されることになる。それはモデルから実行可能なアーキテクチャを生成するという発想である。この関連からUML2.0以降、特に振る舞いや制約を表現する表記法が潤沢に配備されることになった。MDAの主導的差異構成したのは、設計アーキテクチャ区別である。MDAの目的アーキテクチャから設計を解放することであった。ただしここでいう「設計」とは、機能要求に対応したユースケースに過ぎない。一方でアーキテクチャとは、アーキテクチャ中心設計でいうところの、品質特性要求に対応する。すなわち、拡張性、信頼性、そして性能などのような、エンドユーザーにとっては潜在化している諸問題に限定される。

MDAはシステム開発の自動化を夢見てきた。この思想はUML2.0にも反映されている。実際、クラス図からコードスニペットを自動生成することも、逆にプログラムからシーケンス図を自動生成することも、不可能ではなくなっている。しかしこの夢物語は、過度には賛同されなかった。MDAをサポートする兼ね合いから、UMLツールは、多くのデータモデルやメタデータを抱え込むことになった。それ故にUMLは、それ自体として、一個のプログラミング言語と化していく。そうなると、UMLと実際のコードの関連は、プログラム同士の関連と等しくなることで、複合性を増大させていく。つまりUMLは、それ自体として、「システムシステム(System of Systems)」と化す。

如何に理性的な人間の眼から観ても、このシステム複合性の全体像を理解することは困難極まりない。何故なら、たとえUMLの表記法が共通化されていたとしても、それによって表現すべき対象は、機能要求次第で可変であるためだ。したがってアーキテクトは、UML複合性の縮減のために、別のUMLを必要としてしまう。UMLUMLUML… と言った具合に、UMLは論理学的に無限後退へと陥っていく。

このUMLパラドックス脱パラドックス化できたのは、もはやUMLの代替案に対する認知的な期待であった。その代替案とはーーもはやモデリングですらないーー文章である。Markdownの表記法が好例であろう。箇条書きされた短い文章の集まりの方が、設計者の負担を軽減すると共に、ステークホルダーとの認識齟齬も起こり難いためである。

忘れてはならないのは、UML設計の表記法であるということだ。それは数学的な正確性や構文検証を伴わせた形式的な表記法からは区別される。無論オブジェクト指向設計の多くの使い手たちは、UMLをそうした形式的な表記法としては利用していないはずだ。UMLは曖昧な表現を許容する。だからこそ、設計者はそれを誤用する場合もあれば、そこからディス・コミュニケーションが派生する場合もある。一方ではオブジェクト指向プログラミング詳細設計を文書化するためにUMLを利用する設計者もいれば、他方ではシステム設計の文書化にUMLを利用する設計者もいる。だがこの点において、UMLは非ソフトウェア構造を十分には反映させることができないため、不十分な表現に留まってしまう。UMLのユーザーは、しばしばUML設計思想では全く意図されてこなかった対象を表現しようとするあまりに、その表記法を歪めてしまう。

UMLで描写されたアーキテクチャ設計表現は、下流工程の設計者、実装者、そして構築に関わるステークホルダーに対して、十分な説明を与える表現ではない。単なるクラス図であっても、図で使用されている線分や箱に関して、状況に応じて凡例が必要になる場合もある。あらゆる関係者がUMLを理解できるほどの数学的または論理学的な思考力を有している訳ではない。たとえUML表現していても、設計上の意思決定の根拠を説明する場合や、システムの振る舞いを描写するためには、文章による記述が必要になる。総じて言えば、UMLには、システム開発というコミュニケーション的行為合意形成を促す機能は全く無い。

機能的等価物の探索:ツリーダイアグラム

上述したように、UML問題は、それが設計の表記法であるが故のパラドックスである。Markdownのような文章の表記法は、脱パラドックス化形式の一つとなり得る。確かにマークアップ言語であるMarkdownは、UMLも含めた他のオントロジーとの構造的な結合を許容するであろう。だがこのMarkdownという問題解決策は、「オブジェクト指向設計は如何にして可能になるのか」という問題設定に対して、直接的に貢献する方法ではない。UML機能的等価物を探索する場合、この「オブジェクト指向設計は如何にして可能になるのか」という問題設定を前提とした上で、尚且つ「設計の表記法であるが故の問題」を回避することが求められる。

尤も、「設計の表記法であるが故の問題」が有害となり得るのは、設計者、実装者、そしてステークホルダーが「人間」である場合だ。ここでいう「人間」とは、設計の表記法と形式的な表記法を混同してしまう関係者の総称である。そうした「人間」は、曖昧な表現を許容するUMLをしばしば誤用することで、別の「人間」との間で、より良き合意形成を断念する。したがって、この類の「人間」を排除することによって、UMLは、設計の表記法であるが故のパラドックスから救済されることになる。言い換えれば、非「人間」的な存在Xシステム設計実装を担えば、上述した「人間」的な問題は派生しない。同時合意形成問題も解消されるであろう。正確に言えば、ステークホルダーとなる「人間」たちによる理性的な討議は、この存在Xによる<創造>を信仰するか否かという議論へと代替されていくのである。

宗教の社会構造と「生命の樹」の意味論

この極端な理念には前例がある。宗教システム社会構造歴史意味論を前提にすれば、この存在Xに代入されるのが「」の概念であることは直ぐにわかる。多くの宗教家たちにとって、この「」の概念は、現代の「システムシステム(System of Systems)」に匹敵するほどの複合性を宿していた。例えばゲルショム・ショーレムらが取り上げているユダヤ教的なグノーシス主義の秘境的な体系である「カバラ(Kabbala)」においては、唯一の認識不可能性が焦点となっている。カバラ主義から影響を受けている思弁的神秘主義者たちは、このを「無限なるもの(Ein Sof, Ayn Sof)」として捉えた。「無限なるもの」は完全なる統一性である。それは「無限なる者」から区別されることで、非人格的な性格を際立たせている。それは「無限なる者」ではなく、あくまでも「無限なるもの」に他ならない。

この「無限なるもの」としてのを語り得るには、高度な抽象化が必要になる。実際カバラ主義の間では、非人格的なを「原因の原因(Sibbat ha-Sibbot)」や「根源根源(Shoresh ha-Shorashim)」などと表現する場合もある。しかしこの抽象化は、あくまでもを認識不可能な存在Xとして語る場合にのみ機能する。こうした存在Xは、有(Yesh)でもなければ無(Ain)でもない。「無限なるもの」の中では、如何なる変化も起こらない。故に、に対して区別を導入することは不可能である。「無限」としてのには限界も際限も無いために、その外部には何も存在しない。だから、とその外部を区別することは不可能である。

これはパラドックスである。は、唯一でありながらも、その内部に無限の複数性を宿しているからだ。これは、エンドユーザーから観れば一個のシステムであるように思えても、その内部には無数のサブシステム構成されているアーキテクチャと、論理的には類似している。アーキテクトならば、この複合性の縮減のために、UMLのような表記法に頼ることになる。同様にカバラ主義者たちの間でも、ある表記法が慣れ親しまれている。それが、いわゆる「生命の樹(Tree of Life, Etz haChayim)」である。

生命の樹は、宇宙に関する思弁的神秘主義の中心的な特徴を成している。カバラ主義におけるその歴史意味論において、この概念は特に「セフィロート(Sephirot, Sephiroth)」の体系と共に記述される傾向が強い。セフィロートは、生命の樹の構成要素を成している。カバラ主義者は、このセフィロートをメディアとすることで、区別形式を導入することを可能にした。この背景にあるのは、唯一の唯一性に内在する複数性にこそ世界の法則が潜在化しているという、カバラ主義者たちに内面化している宇宙設計思想である。

Scholem, Gershom. (2011). On the mystical shape of the godhead: Basic concepts in the kabbalah. Knopf Doubleday Publishing Group., p44より掲載。

唯一は10のセフィロートの概念で構成されている。このセフィロートの体系はの多様な性格を有していると共に、聖性の階層構造によって秩序付けられている。天上に近い上位のセフィラーは、地上に近い下位のセフィラーよりも聖性が高い。一方、中央よりも右側に位置するほど、そのは慈悲深くなる。逆に左側に位置するほど、厳格さを備えていると言われている。この左右の差異は、世界の対立や矛盾表現しているという。

こうしたセフィラー(Sephirah)という用語は、「数える(mispar)」という意味のヘブライ語から派生した概念であると言われている。遅くても3世紀から6世紀頃には製作されていたという『形成の書(Sefer Yetzirah)』では、神の創造を説明する上で、この概念が叙述されていた。『形成の書』はがアブラハムに語った内容であると言われている。この伝説の真偽はともかくとしても、この書物の主題人間物語ではない。そこで描かられているのは、の創造における、ヘブライ文字や数字のような抽象的な概念と天体や自然現象の関係である。その記述は『旧約聖書』の内容とは異質な抽象論となっている。それによれば、世界は10のセフィロートと22のヘブライ語のアルファベットの組み合わせから構成されたという。世界が数字によって構成されているという発想は、何処かピタゴラス学派の音楽論を連想させる。

ただし『形成の書』では、個々のセフィラーが具体的に何を表すのかについても、それが如何にして生成され得たのかも、説明されていない。そうした個別具体的な定義は、後のカバラ主義者たちの解釈に委ねられていた。しかし、むしろ重要なのは、無限で際限の無いように思える存在Xであっても、「10」で数えることが可能であるという点である。つまり元来認識不可能であるとされた対象であっても、定量的な区別形式を導入することが可能なのである。

ダイアグラム小史

ツリーダイアグラム(Tree diagram)」の概念史を遡れば、この概念が必ずしも構成要素を叙述してきた訳ではないということも、直ぐにわかるであろう。例えば『旧約聖書』の「創世記」には、アダムの家系が延々と叙述されている。家系図は、血縁関係を可視化する生命の樹の一種であると考えられる。生命の樹という概念は、決してユダヤ教に限定される訳ではなく、キリスト教やギリシャ神話とも縁を持っている。

14世紀のルネサンス期においては、『デカメロン』の作者として有名なイタリアの詩人ジョヴァンニ・ボッカッチョが、『異教の々の系譜(Genealogia Deorum Gentilium)』で、ギリシャ・ローマ神話で語られるデミウルゴスの子孫たちの系図の図版を掲載している。14世紀の時代背景を念頭に置けば、この系図は、複合性の高い概念のモデリングとしては稀有な例であった。と言うのもこの時代のモデルと言えば、専ら地図の設計に利用される幾何学的なダイアグラム(geometric diagrams)が主流であったためだ。ダイアグラムで可視化されていたのは、々の運行やその位置関係であった。幾何学的な発想そのものは、古代エジプトの測量士たちの活動に由来している。今でこそ知り渡っている緯度と経度の区別は、古代ローマの学者であり天動説の支持者でもあったクラウディオス・プトレマイオスによって導入された。地球儀のような球状の物体への地図投影(map projection)は、ここから派生している。その後も14世紀までは、この物理学的な観測方法が、地図の標準的なデータビジュアライゼーション法として利用され続けていた。

その後の数世紀の間も、モデリングの方法は専ら物理学的なダイアグラムとして発明され続けた。立て続けに地理情報に関する物理学的な測定方法主題となるのは、領土侵攻という当時の政治的な都合も絡んでいる。16世紀には展望台や三角測量法などが発明され、17世紀には解析学や統計学のような近代科学の発展が大きな貢献をもたらした。18世紀から19世紀前半には、地理情報の可視化方法が、等高線や等高線などによって洗練されていった。棒グラフや円グラフ、ヒストグラムや散布図など、データビジュアライゼーションの主要な表現方法が定着し始めたのも、この時期からである。こうした方法は地理情報や気象情報のみならず、様々な物理現象を視覚的に理解する上でも用いられるようになった。更に19世紀中盤から19世紀末の間には、統計学者たちが磨いてきた統計手法が、この可視化の方法論に合流することになる。様々な統計量が様々なグラフィックによって直感的に把握できるようになったのである。

この関連から、ツリーダイアグラムの可視化方法も、科学サイドに導入されるようになる。ダーウィンの生物学的な進化論が提唱されて以来、科学的な分析結果もツリーダイアグラムによる可視化の対象となり始めた。実際、動物学者エルンスト・ヘッケルは、全生物の系統樹を生命の樹の如く描いている。そこには、生物の系統関係に基づく壮大な体系が系統樹という一つの体系として叙述されている。ダーウィンの生物学的な進化論がキリスト教的な創造論との対立を生じさせたとすれば、ヘッケルの可視化は、宗教サイドのツリーダイアグラムの偶発性を顕在化させることになった。今やツリーダイアグラムは、神の世界の表記法としてだけではなく、脱魔術化された近代科学の業績をも表現しているのである。

ツリーとセミラティスの差異

しかしこの対立が指し示しているのは、ツリーダイアグラムという概念が、宗教サイドにも科学サイドにも囚われないほどの抽象性を獲得しているということである。ただしこの概念の抽象性を十分に活かすためには、それが「ツリー」的であることの必然性を疑わなければならない。この関連からもう一度我々は、アレグザンダーが導入した「ツリー」と「セミラティス」の区別観察することになる。実際現代のグラフ理論的な統計学や離散数学の間では、むしろセミラティスの方が、ダイアグラムの形態を巧く叙述しているのである。

グラフ形態を適切に区別するには、クラス図における関連の誘導可能性のように、二つの構成要素の間にある論理学的な二項関係(binary relation)を把握しておかなければならない。その際重要となるのは、順序関係(order relation)と順序集合(order set)の差異である。順序関係には擬順序(preorder)と半順序(partial order)と全順序(total order)がある。擬順序は、反射律(reflexivity)と推移律(transitivity)を同時に満たす二項関係を表す。半順序は反射律と推移律と反対称律(antisymmetry)を同時に満たす二項関係を表す。そして全順序は、反射律、推移律、半対称律、そして比較可能律(comparability)を同時に満たす二項関係を表す。

ここで、各順序関係は、オブジェクト集合Sに属する任意の要素x, y, zにおける二項関係をRとした場合を想定している。反射律は$$xRx$$が成り立つ場合を指す。推移律は$$xRy$$かつ$$yRz$$ならば$$xRz$$を満たす場合を指す。反対称律は$$xRy$$かつ$$yRx$$ならば$$x = y$$となる場合を指す。そして比較可能律は、$$xRy$$または$$yRx$$が成り立つ場合を指す。

ダイアグラムにおいては、隣接している二つの要素の関連が重要となる場合が多い。これに対応した関連付けは、一般に「被覆関係(convering relation)」として定義されている。xとyが被覆関係となる条件は、$$xRy$$かつ$$x \neq y$$で、尚且つ集合Sの任意の要素zに対して、$$xRz \land zRy$$が成立しない場合である。したがって、ある二項関係Rを前提とした被覆関連は、他の要素を介在させず、純粋に非冗長的かつ直接的な関連を意味する。この時、xとyは特に$$x^{*}Ry$$と表記される。この二項関係を矢印で結んだのが、「ハッセ図(Hasse diagram)」となる。ハッセ図は、特定の順序関係に関して、その有限順序集合を可視化する方法として知られている。

順序集合は順序関係の集合である。擬順序集合(preorder set)は反射律と推移律で構成されている。だがこれらの条件だけでは、全体としては緩い順序関係が形成されることになる。この集合$$S_{preorder} = \{a,b,c,p,q,r,s,t,x,y,z \}$$とした場合、この集合内で成立する擬順序は以下のようになると仮定する。

$$xRy, xRz, yRa, zRa, aRb, aRc, \\
pRq, pRr, pRs, pRt, xRx, yRy, \\
zYz, aRa, bRb, cRc, pRp, qRq, \\
rRr, sRs,tRt, xRa, xRb, xRc, \\
yRb, yRc$$

ここから、反射律となる$$aRa, bRb, cRc, pRp, qRq, rRr, sRs,tRt$$と、推移律となる$$xRa, xRb, xRc, yRb, yRc$$は、それぞれ被覆関係を満たさない。したがってハッセ図として作画されるべき要素は、被覆関係を満たす次の二項関係のみとなる。

$$xRy, xRz, yRa, zRa, aRb, aRc, pRq, pRr, pRs, pRt$$

擬順序集合から導かれるハッセ図では、反対称律を満たさなくも良い。そのため$$xRy \land yRx$$の時に$$x \neq y$$でも構わないということになる。これを「同値関係(equivalence relation)」という。そしてこの同値関係にある類を同一類(equivalence class)と呼ぶ。上記の擬順序集合では、yとz、rとsとtがそれぞれ同値類となる。

一方、半順序集合(partially ordered set)では、反対称律を満たさなければならないため、同値類は形成されない。同値類は、擬順序集合に固有の特徴である。これに対し、擬順序集合と半順序集合の共通点は、比較可能律が必ずしも満たされていないということである。つまり半順序集合をハッセ図で表した場合、そこには相互に関連の無い複数のグラフ構成されることになる。それは、半順序集合が異なる複数の部分集合区別できるということでもある。他方、全順序集合(totally ordered set)は、半順序集合の条件に加えて比較可能律も満たされている。そのため半順序集合とは異なり、全順序集合のハッセ図では一列のグラフが形成される。

dot言語で作画した擬順序集合、半順序集合、全順序集合のハッセ図。

擬順序集合が緩やかな条件付けによって構成されているのに対して、全順序集合は緊密な条件付けによって構成されている。この中間にあるのが半順序集合である。この半順序集合特徴付けるためには、上界(upper bound)と下界(bottom bound)の区別を導入しなければならない。この差異集合特徴を表す。例えばxとyの上界は、集合$$U = \{z|z \in S, \ xRz \land yRz\}$$である。上界Uの任意の要素zに対して、$$z_0 Rz$$となる$$z_0$$をxとyの上限(least upper bound)と名付け、ここでは$$sup(x, y)$$と表記する。一方、xとyの下界は、集合$$L = \{w|w \in S, \ wRx \land wRy\}$$である。下界Lの任意の要素wに対して$$wRw_0$$となる$$w_0$$をxとyの下限(greatest lower bound)と名付け、特に$$inf(x, y)$$と表記する。この上限と下限の区別を導入すると、半順序集合の重要な特徴である「上半束(upper semilattice)」と「下半束(lower semilattice)」、そして「束(lattice)」の区別を導入することが可能になる。すなわち、$$sup(x, y)$$が含まれている半順序集合は上半束の集合となる。$$inf(x, y)$$が含まれている半順序集合は下半束の集合となる。そして$$sup(x, y)$$と$$inf(x, y)$$が共に含まれている半順序集合は束の集合となる。任意の要素に対して上限が必ず存在する上半束では、全ての上界の最大元(maximal element)が一意に定まる。逆に任意の要素に対して下限が必ず存在する下半束では、全ての下界の最小元(minimal element)が一意に定まる。

dot言語で作画した上半束、下半束、束。

直線状のグラフである全順序集合のハッセ図では、生命の樹のように、無数に枝分かれしていく複数のノード表現することはできない。擬順序集合が可能にする同値類の表現が必要とはならないのであれば、ツリーダイアグラムの表記法として最適なのは、半順序集合である。上限と下限の区別を導入すれば、様々なツリーダイアグラムの表現が可能になる。上半束の半順序集合から作画したハッセ図を有向グラフとして活用するなら、様々な因果関係が最終的に何の要素に帰結しているのかを可視化することが可能になる。逆に下半束の半順序集合を利用するなら、その有向グラフは、逆に発端となる最初の原因ーー「原因の原因」ーーを可視化することを可能にする。しかしこうしたツリー状の可視化を構造化しているのは、上半束(upper semilattice)と下半束(lower semilattice)の差異の共通項となるセミラティス(semilattice)である。

先に我々は、アレグザンダーの観察観察により、ツリーセミラティス区別が、セミラティス構造ツリー化というパラドックスを招いていることを確認した。この区別は、人為自然区別に対応している。セミラティス構造ツリー化というパラドックスは、<自然人為性>というパラドックスと論理的に等価である。しかしこれに対して上述したグラフ理論や離散数学は、このパラドックスを「展開」することで、ツリーダイアグラムがセミラティス構造を具象化した一種に過ぎないということを記述している。つまりツリー化したグラフ構造を汎化していけば、それはセミラティス構造になり得るのである。したがってツリーダイアグラムの観察者は、一見ツリーとして固定化している構造であっても、一旦セミラティスとして抽象化することによって、別のあり方でもあり得る具象的なツリー構造可能性を探索することも可能になる。

アーキテクトの機能的等価物としての人工知能

擬順序と半順序と全順序の区別、上半束と下半束と束の区別、そしてツリーセミラティス区別は、様々な諸要素の諸関連ーー諸関連の諸関連ーーを形式化させるメディアとして機能する。しかもこの形式化は、関連するノード集合と各ノード間のエッジの属性となる二項関係の条件付けをそれぞれパラメタとして受け付けることで、自動化させることが可能になる。まず以ってこのグラフ構造化は、概念クラス図や詳細クラス図の機能的等価物となり得る。関連の誘導可能性は、エッジで表現することになる。クラスの階層構造は、上半束の構造表現できる。この構造において、最上位のスーパークラスは全ての上界の最大元となる。一方、下半束の構造は、どちらかと言えばコミュニケーション図やシーケンス図、あるいはコンポーネント図の機能的等価物となろう。この場合、最小元のノードに対応する関数が、エントリーポイントとなる。各エッジは、ここから呼び出される処理を流れを指し示す訳だ。だがクラス図のメソッド名やシーケンス図のインスタンス名などのようなデータは、グラフ構造では可視化され得ない。しかしながらここで重要なのは、非「人間」的な設計者を仮定した場合である。その存在X人工知能のような人工物であれば、各ノードが有するメソッドやプロパティのようなデータは、メタデータとして保持されることになるであろう。

このように、二項関係という単純な条件付けから、オブジェクト指向分析オブジェクト指向設計の担い手となる「人間」の機能的等価物としての人工知能設計することが可能になる。ここまで来れば、これらのみならずオブジェクト指向プログラミングに関しても、自動化したいという欲求に駆られるかもしれない。しかし既に「人間」のプログラマの傾向から考えてもわかるように、今やプログラミングの大部分は、ライブラリやAPIの機能的な再利用によって成り立っている。そしてその多くは、GitHubのコミットログとして保存されている。したがって、オブジェクト指向プログラミングの自動化としてまず実現するべきなのは、ライブラリやAPIの機能的な再利用の自動化である。

この問題解決策となるのは、Webクローラ自然言語処理である。と言うのも、大多数のライブラリやAPIは、Sphinxをはじめとした文書の自動生成ツールによって生み出されているからである。こうした文書は、コードとそのコメントから構成されている。プログラマは、コメントを予め所定の表記法で記述することで、文書化する対象を操作することができている。こうして生成された文書は、全てWeb上で公開されている。Webクローラによる観察は容易い。各Webページの階層構造は、各クラスの概念的な階層構造やパスの構造に対応している。あるサブクラスのWebページには、そのスーパークラスのWebページへのハイパーリンクが貼られている。各Webページには、メソッドの引数や返り値の型、あるいはプロパティの有無などが詳述されている。こうした文書をWebスクレイピングの対象とすれば、既存のライブラリやAPIにおける、そのツリー構造セミラティス構造を抽出することが可能になる。

既存のAPIやライブラリの論理構造蒐集できたなら、後は「組み合わせ最適化問題(combinatorial optimization problem)」を解くだけである。つまり、「オブジェクト指向設計構成したツリーダイアグラムの構造」と「既存のAPIやライブラリの論理構造」の差異を最小化する組み合わせを探索する訳だ。周知のように、組み合わせ最適化は困難極まりない問題設定である。だからサイモンのように、最適化満足化区別を導入することは、ここでも有益となる。たとえ最適解は不可能でも、満足解であれば、強化学習でパラメタ化することが可能になる。その際、どの既存のAPIやライブラリを利用するかという選択問題は、一種の確率バンディット問題として設定できるであろう。

だがこの場合により一層難易度を上げてしまうのは、「既存のAPIやライブラリの論理構造で参照されている諸概念」と「オブジェクト指向設計構成したツリーダイアグラムで参照している諸概念」との間の、距離計算である。キーワードのマッチ率程度の類似性計算アルゴリズムでは、勿論全く通用しない。たとえ同じ概念であっても、文書の生成者次第では、異なる用語で記述されている場合もある。それ故に、深層学習による汎化性能を備えた自然言語処理が必要不可欠となる。

以上の記述は、このWebサイトの概念実証の中でも、とりわけ未来志向的な思弁で留まっているように視えるかもしれない。しかしこれらの観察は、このWebサイトにおける概念実証の公理、定理、定式を前提とすれば、十分演繹可能な結論となっている。これらについては、既に『量子力学、統計力学、熱力学における天才物理学者たちの神学的な形象について』、『Webクローラ型人工知能によるパラドックス探索暴露機能の社会進化論』、および『深層強化学習のベイズ主義的な情報探索に駆動された自然言語処理の意味論』において、詳細に解説しておいた。

上述した人工知能実装された時、「人間」の設計者と実装者の大半は不要となる。既存の概念を実装する場合であれば、上述した人工知能により、全てが自動的に開発されていく。「人間」が必要となるのは、未だWeb上に蓄積されていない全く新しい概念を設計して実装する場合のみである。そうした「人間」を、ここでは<創造的>な「人間」と名付けておこう。現存するエンジニアの全てが、全く新しい概念を設計して実装するほどの知識やスキルを有している<創造的>な「人間」であるとは限らない。既存のAPIやライブラリを使い回すことしかできないエンジニアは、職を失うことになったとしても不思議ではない。しかしそうなると、「人間とは何か」などといった哲学者たちが好みそうな派生問題に付き合わざるを得なくなるであろう。これが瑣末な問題に過ぎないという観点を確かめたい読者は、次のページに進むよりも、『ヴァーチャルリアリティにおける動物的「身体」の物神崇拝的なユースケース』をご覧いただくことを推奨する。と言うのも、次のページからは人工知能アーキテクチャ設計の実践に移るため、そうした哲学的な思弁を期待しても無駄に終わるからである。

スポンサーリンク