情報開発と利活用

令和維新

2004年4月から企業を離れ、コンサルタントや情報起業を試行しながら、失われた２０年を取り戻し、日本再生をめざす私の歩みをみて一人でも多くの後継者が出てくれることを祈りつつ友達から紹介されたこのホームページの更新を続け、これまでの活動の記録と今やビッグデータ、AI,、IOT,ブロックチェーン、仮想通貨の時代になってしまいましたが、私の現状認識と関連技術を紹介していきたい。

フォローする

UX

(0)

オンライン

(0)

ソーシャルメデイア

(0)

開発

(0)

スマートマネー

(0)

流動性

(0)

教育訓練開発手法の紹介

Headline News

Shopping List

お買いものレビューがまだ書かれていません。

新着記事一覧(全8011件)

過去の記事 >

2026.05.20

(2)フラクタル設計エンジン(Fractal Design Engines)

テーマ：英語のお勉強日記(8374)

カテゴリ：メタバース

Building the tree
ツリーの構築

So the next part is the tree itself that is the overall model that we have and then the individual challenges that we break off from the model, for instance the overall model could be an F1 car and the model includes all of the parts and how they work together, we then set up a new challenge which is specifically to improve the engine, this sparks multiple challenges, reducing weight, increasing compression ratio within the regulations, increasing the rate in which power is created, etc, then within each of those elements there could be specific challenges, for instance piston changes, head changes, metal composition changes, etc.
次に、ツリー自体、つまり私たちが持っている全体モデルと、そのモデルから切り出す個々の課題について説明する。たとえば、全体モデルがF1カーで、モデルにはすべての部品とそれらの連携方法が含まれているとする。次に、エンジンの改良という新しい課題を設定する。これにより、重量の削減、レギュレーション内での圧縮比の向上、出力生成速度の向上など、複数の課題が発生する。そして、それぞれの要素の中に、ピストンの変更、ヘッドの変更、金属組成の変更など、具体的な課題が存在する可能性がある。

So, the model itself isn’t the tree, we aren’t just decomposing down the parts, the tree are the challenges which have specific sections of the model on which they are allowed to operate, this means different challenges might be acting on the same parts. This is where the tree becomes more of a graph in terms of its interaction with the UKP and the model for the product that we are working on.
つまり、モデル自体がツリー構造になっているわけではなく、単に構成要素を分解しているわけでもありません。ツリー構造とは、モデルの特定のセクションに対して操作を行う課題のことだ。これは、異なる課題が同じ部分に対して作用する可能性があることを意味する。このように、ツリー構造は、UKP（英国製品パッケージ）や私たちが取り組んでいる製品モデルとの相互作用という点で、よりグラフ的な性質を帯びてくる。

So, in the tree each ‘node’ has a Branch Manager, the job of the branch manager is to initiate the challenges within its area, and to maintain the ‘golden checkpoint’ which is basically the baseline that it started at, and then each clear improvement on that baseline.
つまり、ツリー構造では各「ノード」にブランチマネージャーがおり、ブランチマネージャーの役割は、その領域内で課題を開始し、基本的に開始時のベースラインである「ゴールデンチェックポイント」を維持し、そのベースラインに対する明確な改善を一つずつ進めていくことだ。

このレベルでは、ブランチマネージャーには2つのパートナーがある。1つ目は経済エージェントで、これはブランチが課題の結果に対して時間を「入札」し、基本的にブランチ内で費やすことができる労力の量を設定する。2つ目はスパイラル検出器で、これは予算が無駄にならないようにするためのものだ。ブランチが予算があっても制御不能に陥り結論に至らない場合、スパイラル検出器はブランチマネージャーに通知する。ブランチマネージャーは、新しいチームを再開するか、他のチームを待つか、すべてのチームが失敗したか、または十分な数のチームが失敗したため肯定的な結果が得られる可能性が低いと判断した場合は、その特定のノードが肯定的な結果に繋がらなかったことを「上司」であるブランチマネージャーに警告することができる。

The teams
チーム

So now let's get onto those teams, and they really are two different teams. The first team is the Generative Team, they’re the ones who get given the challenge and get to be creative, they’re a team of generative agents, domain aligned to the specific problems and aligned to the specific output formats that are allowed. These agents are then assigned, with a budget , given the challenge that they need to address, and then they propose a new solution.
さて、それではチームについて見ていこう。実際には2つの異なるチームがある。1つ目は生成チームだ。このチームは課題を与えられ、創造性を発揮する。生成エージェントのチームで、特定の問題と許可されている特定の出力形式にドメインが適合している。これらのエージェントには予算が割り当てられ、対処する必要のある課題が与えられ、新しいソリューションが提案される。

This is where the second team comes in, the evolutionary team, this consists of agents whose job it is to first fit the generative proposal into something that is valid for the Unified Physics Kernel (UPK) and then uses a headless metaverse to create modifications to the solution and validate whether they are improving the solution against the golden checkpoint for that branch. The evolutionary team might kickback to the Branch Manager if the solution is too far from realistic and can’t be made into something viable, or if the delta from the solution or golden checkpoint is too high.
ここで2つ目のチーム、進化チームが登場する。このチームは、まず生成提案を統合物理カーネル（UPK）に有効なものに適合させ、次にヘッドレスメタバースを使用してソリューションに変更を加え、そのブランチのゴールデンチェックポイントに対してソリューションが改善されているかどうかを検証するエージェントで構成されている。ソリューションが現実的からかけ離れていて実行可能なものにできない場合、またはソリューションやゴールデンチェックポイントからの差分が大きすぎる場合は、進化チームがブランチマネージャーにキックバックする可能性がある。

The translator
翻訳者

So, a core challenge is how does the Branch Manager speak to the teams? Either the Branch Manager knows all of the languages required for the teams, or we have a translator which understands the agents and is able to translate it into the specific context, boundaries and challenge required for each of the agents and the overall team. The is the Semantic Translator which performs two key challenges:
では、中核的な課題は、ブランチマネージャーがチームとどのようにコミュニケーションを取るかということだ。ブランチマネージャーがチームに必要なすべての言語を知っているか、エージェントを理解し、各エージェントとチーム全体に必要な特定のコンテキスト、境界、および課題に翻訳できる翻訳者が必要だ。これがセマンティック翻訳者であり、2つの重要な課題を実行します。

 Ensuring everything is valid from a syntax/semantics perspective
構文/意味論の観点からすべてが有効であることを保証する

 Translates between managers and agents into their own specific contexts
マネージャーとエージェントの間で、それぞれの特定のコンテキストに翻訳する

1 つ目は、ソリューションのリンターまたはコンパイラのようなもので、すべての出力が使用できるシステム要件を満たしていることを確認する。2 つ目ははるかに複雑で、これは同期エンジンだ。これは、ブランチマネージャーを含むさまざまなエージェントがそれぞれのコンテキストで互いに通信できるようにするという課題がある。つまり、「ピストンエージェント」が「エンジン」エージェントと通信する必要がある場合、コンテキスト間で翻訳する。そのためには、すべてのエージェントが非常に明確な境界と言語記述を持ち、標準操作手順、通信に必要な意味論と構文、およびイベント駆動型システムで複数のエージェントが連携して動作するために必要なその他のすべての要素を明確にする必要がある。

Where the Evolutionary Teams live
進化チームが存在する場所

While the generative teams can create flights of fancy, our evolutionary teams need to work within an environment, and this is where the headless metaverse becomes ‘containerized reality as a service’ that is that each branch has its own instance which applies the parts of the UPK that applies to that specific branch, so if we’re dealing just with a piston its tuned down to just that space, if it’s just the aerodynamics of the overall car then its tuned down just to that. Feasibility Assessors work as active cullers of branches as we spin up hundreds, thousands or even millions of evolutionary threads from a single generative route and use our assessor to dynamically tune the budget and thus ‘naturally select’ the branches that are delivering the most benefits.
生成チームが自由奔放なアイデアを生み出せる一方で、進化チームは、ある環境の中で作業する必要がある。そしてここで、ヘッドレス・メタバースが「サービスとしてのコンテナ化された現実」となる。つまり、各ブランチはそれぞれ専用のインスタンスを持ち、そのブランチに関係する UPK（統合物理カーネル）の部分だけが適用される。例えばピストンだけを扱うなら、その領域だけに調整されるし、車全体の空力だけを扱うなら、その領域だけに調整される。実現可能性アセッサーは、積極的に枝を間引く存在として機能する。1つの生成ルートから数百、数千、あるいは数百万もの進化スレッドを立ち上げる中で、アセッサーが動的にブランチを削っていく。そしてアセッサーは予算を動的に調整し、最も利益をもたらすブランチを「自然選択」する。

The Headless Metaverse isn’t just a single static environment, it’s the way that we drive massive scale adaptation and pruning of solutions from each creative generative routes.
ヘッドレス・メタバースは単一の静的な環境ではない。それは、各生成ルートから生まれる膨大な解を適応・剪定するための仕組みなのだ。

The economy of the FDE
FDEの経済性

私たちが用いる調整アプローチは、計算資源の利用可能性と、ゴールデン・チェックポイントに対する改善度を経済モデルとして使うというものだ。より大きな改善を示したブランチは、より大きな予算にアクセスできる。さらに、プログラムに対する私たちの“姿勢”も、作業の進め方を決定する。つまり、漸進的な改善を進めたい場合は、創造性の予算を減らし、進化チームに集中させる。ただし、非常に積極的な剪定を行う。

Using compute availability as our ‘natural selection’ approach helps to align the outcome of the FDE （Fractal Design Engine）to our overall goals, not driving ‘intelligent’ design, but instead enabling us to ‘bias’ the FDE towards the goals that we want.
計算資源の利用可能性を“自然選択”のアプローチとして使うことで、FDE の成果を私たちの全体目標に整合させることができる。“知的設計”を推進するのではなく、FDE を私たちが望む目標へと“バイアス”させることができるのだ。

Summary
まとめ

So, this is the foundation of my idea, a design engine that is built to build products that people probably couldn’t create. Does this remove design genius? Absolutely not, but it means that once the design genius has happened you can work on the engineering details to make that design into reality, making a smaller phone, or ensuring its waterproofing is better, trying different ways to reduce weight or increase lifetime. This is, IMO, a much more challenging problem than building software systems, but if people are now actively deploying the Enterprise Torment Nexus then I thought I’d throw this out into the universe as something I’d actually like to see built.
つまり、これが私のアイデアの基盤であり、人間にはおそらく作れない製品を作るために構築された設計エンジンである。これはデザインの天才を排除するのか。全くそんなことはない。しかし、これはデザインの天才的ひらめきが起きた後、そのデザインを現実にするための工学的詳細に取り組めるということを意味する。より小さなスマートフォンを作るとか、防水性能を高めるとか、重量を減らす方法や寿命を延ばす方法を試すといったことだ。これは、私の意見では、ソフトウェアシステムを構築するよりもはるかに難しい問題だ。しかし、人々が今やエンタープライズ・トーメント・ネクサスを積極的に展開しているのなら、私はこれを実際に作られてほしいものとして世界に投げてみようと思った。

They’ve funded the Enterprise Torment Nexus
彼らは “ エンタープライズ・トーメント・ネクサス ” に資金を投じた。

Enterprise Insecurity as a Feature
“ 企業の不安定性 ” を機能として扱う

blog.metamirror.io

Agentic Ai
エージェント AI

Additive Manufacturing
付加製造

Evolutionary Ai
進化型 AI

Manufacturing
製造

AI
人工知能

Written by Steve Jones
執筆：ステイーブ・ジョンズ

My job is to make exciting technology dull, because dull means it works. All opinions my own.
私の仕事は、ワクワクする技術をつまらなくすることだ。なぜなら、つまらないということは、それが実際に動くということだから。意見はすべて私個人のものだ。

インターネット・コンピュータランキング
==============================
ネットサービスランキング
==============================

お気に入りの記事を「いいね！」で応援しよう