― VERTEXを生み出した発想の源泉
AI、LLM、Agent、Database、Runtime、通信、UI。
最近は、いろいろな技術について考え、実際に作りながら試しています。
その中で、よく聞かれることがあります。
「どうしてそんな発想が出てくるんですか？」
自分でも考えてみました。
VXN。
Impact DB。
LLM Memory Architecture。
ARD。
Vertex Works。
VRA。
Evidence。
VXS。
vCELL。
VXN-DB。
AI Consultant。
そして、まだ形になっていないいくつもの構想。
一つひとつを見ると、かなりバラバラに見えます。
しかし、実際には全部つながっています。
私の場合、最初から「新しい技術を発明しよう」と考えているわけではありません。
むしろ逆です。
最初にあるのは、
「何か、おかしくないか？」
という小さな違和感です。
そこから、
「なぜ、こういう設計になっているんだろう？」
と考える。
さらに、
「そもそも、その前提は本当に必要なのか？」
と一段戻って考える。
そして、
「別の考え方を持ち込んだら、どうなるだろう？」
となる。
最後は、
「じゃあ、実際に作ってみよう」
です。
この繰り返しから、VERTEXは少しずつ形になってきました。
この記事では、これまで考えてきたことを振り返りながら、私自身のアイデアの源泉と、そこからどのようにVERTEXという思想が生まれてきたのかを書いてみます。
1. 私の出発点は「AI」ではなかった
最初からAIを作りたかったわけではありません。
出発点にあったのは、もっと現実的な問題です。
現場で仕事をしていると、コンピュータの都合と、人間の仕事のやり方が合っていないことがあります。
人間は、
- 手書きする
- 見ながら判断する
- 口頭で伝える
- 途中で考えを変える
- 一旦保留する
- 後から確認する
といったことを普通にやります。
ところがコンピュータは、
入力
↓
決定
↓
保存
を求めることが多い。
「今は分からない」
「あとで確認する」
「たぶんこれ」
「状況を見てから決める」
といった状態が、システム側では扱いにくい。
ここに最初の違和感がありました。
人間の仕事は、そんなにきれいに確定していない。
それなのに、コンピュータ側へ持っていく瞬間に、無理やり確定させている。
この違和感は、後になってImpact DBという発想につながります。
2. 現場を見ると、コンピュータの常識が揺らぐ
現場には、教科書どおりに進まないことがたくさんあります。
例えば、
見た
↓
ちょっと違う気がする
↓
様子を見る
↓
別の情報が入る
↓
最初の判断を修正する
という流れがあります。
人間はこれを自然にやっています。
ところがシステムを設計すると、
状態 = A
と決めたくなります。
すると、後になってBだったと分かったとき、
A → B
という変更しか残らない。
しかし本当に欲しいのは、
Observation
↓
Candidate A
↓
Additional Evidence
↓
Candidate B
↓
Confirmation
という流れなのではないか。
「AからBに変わった」という結果だけでなく、
なぜAだったのか
まで残したい。
この発想が、後のAI設計にも強く影響しています。
3. 私は「既存技術」を見るとき、少し疑う
技術を調べるとき、私はすぐに、
「じゃあ、これを使おう」
とは考えません。
むしろ、
「これって、そもそも本当に必要？」
と考えます。
既存技術が悪いとは思っていません。
むしろ、素晴らしい技術がたくさんあります。
でも、
「今までそうしてきた」
ことと、
「これからもそうするべき」
ことは同じではありません。
この区別は、VERTEXの設計で何度も出てきました。
4. 「JSONが普通」だからといって、AI内部までJSONでいいのか
この疑問から出てきたのがVXNです。
JSONは非常に優秀です。
人間が読める。
Webと相性がいい。
デバッグしやすい。
互換性も高い。
だから外部インターフェースで使うことに、何の問題もありません。
でも、AI同士が大量のメッセージをやり取りする内部通信まで、同じ表現を使い続ける必要があるのでしょうか。
そこで、
AI間通信をJSONから解放できないか？
と考えました。
これは、
「JSONはダメ」
ではありません。
そうではなく、
「誰のための表現なのか？」
という問いです。
人間のための表現。
外部APIのための表現。
AIのための内部表現。
Runtimeのための内部表現。
全部同じである必要はない。
ここから、
Vertex Native（VXN）
という構想が生まれました。
5. VXNは「新しいJSON」を作りたいわけではない
VXNについて最初に誤解されたくないのは、
「JSONより小さいデータ形式を作ろうとしているだけ」
ではない、ということです。
本当に考えたいのは、
AIシステム内部の通信そのものを、AI・Agent・Runtimeに合わせて設計し直す
ことです。
例えば、
Human
↓
External Interface
↓
JSON
↓
VXN Boundary
↓
VXN
↓
Agent / Runtime / Brain / Tool
という世界です。
外側は人間と既存システムの世界。
内側はAIの世界。
境界を分ける。
この考え方をさらに進めると、VXNは単なる通信フォーマットではなく、
VERTEXの神経系
という位置づけになっていきました。
6. なぜ「神経系」という発想になるのか
私は、コンピュータの世界だけを見て発想することが、必ずしも正しいとは思っていません。
別の世界にある仕組みを観察して、
「これを情報システムに持ってきたらどうなる？」
と考えることがあります。
例えば神経系です。
神経は、単純な「ファイル転送」とは違います。
重要なのは、
- 刺激
- 状態
- 強度
- 方向
- タイミング
- 反応
です。
AIシステムでも、
Observation
↓
Decision
↓
Execution
↓
Verification
↓
Evidence
という情報の流れがあります。
これを、
単なるAPI呼び出しの連続
として見るのではなく、
情報がシステム内を伝播している
と考えてみる。
そうすると、通信の設計思想が変わります。
7. 別の世界の原理を持ってくる
この「別の世界から考え方を持ってくる」というのは、私の発想のかなり大きな部分です。
例えば、
- 神経系
- 流体
- 3D空間
- 組織構造
- 工場
- 建築
- 物流
- 生物の情報伝達
などです。
「コンピュータの中でどう実装するか」を考える前に、
現実世界では似た問題をどう解いているのか？
を見る。
その考え方をコンピュータへ翻訳する。
もちろん、そのまま持ってきても使えません。
だから、
異分野の原理
↓
抽象化
↓
コンピュータへの翻訳
↓
実装
↓
検証
と進めます。
8. Tesla Valveから情報伝播を考える
この発想の一つが、Tesla Valveでした。
本来は流体の世界の仕組みです。
でも、
「一方向へ流れやすく、逆方向へ流れにくい構造」
として見れば、情報伝播にも応用できるかもしれない。
そこで、
情報
→
→
→
という単純な一本道ではなく、
不要な逆流を抑えながら情報を流す
という考え方を持ち込めないかと考えました。
VXNでも、
- 一方向性
- 合流
- 分岐
- 伝播
- 停止
などの概念を考えるようになりました。
これは、単に「速い通信」を作る話ではありません。
情報そのものの流れを設計する
という話です。
9. 「止まる」を設計する
これもVERTEXの設計で何度も出てきた考えです。
普通は、
どう動かすか
を考えます。
でもAIシステムでは、
いつ止めるか
も同じくらい重要です。
AIが自律的に動いて、
Agent
↓
Tool
↓
Another Tool
↓
Another Agent
↓
Mutation
と進んでしまったら、
どこかで止めなければならない。
そこで、
停止先行
という発想が出てきます。
実行することよりも先に、
- どこで止まるか
- 誰が止められるか
- どこで人間に戻すか
- 失敗したらどう戻すか
を決める。
この思想は、その後のVRA、Evidence、Human Gate、ARDなどにも強くつながっています。
10. 「AIに自由にさせる」と「AIに権限を与える」は違う
AIの自律化を考えるとき、私は、
「全部AIに任せる」
という方向だけを考えているわけではありません。
むしろ、
AIは自由に考えてよい。しかし、重要な権限は別の場所に置く
という設計を考えています。
例えば、
AI
↓
Proposal
↓
Validation
↓
Human Gate
↓
Apply
という構造です。
AIには、
- 調べる
- 提案する
- 推論する
- 比較する
- 設計する
自由があります。
しかし、
確定
本番変更
重要な権限変更
などは、別の境界に置きます。
この考え方は、あとでVertex WorksやVRAの設計に発展していきます。
11. AIに直接PCを触らせるのではなく、「工場」を作る
ここから生まれたのがVertex Worksです。
普通に考えれば、
AI
↓
PowerShell
↓
PC
でいいように見えます。
でも、それでは怖い。
AIが直接、
ファイル変更
↓
実行
↓
失敗
↓
さらに変更
を繰り返す可能性があります。
そこで、
AIの仕事を受け付けて、検証可能な形で実行する「工場」を作ろう
と考えました。
それがVertex Worksです。
12. VRAという「発注書」
WorksへAIが仕事を渡すときには、単なる自然言語ではなく、
VRA（Vertex Request Artifact）
という形で仕事を発注します。
概念的には、
AI
↓
VRA
↓
Workstation
↓
Execution
↓
Verification
↓
Evidence
です。
重要なのは、
何をしたいか
だけではありません。
- 誰が発行したのか
- どの仕事なのか
- どのプロジェクトなのか
- どの権限で実行するのか
- どのレーンで処理するのか
- 人間の承認があるか
- 結果をどう確認するか
といった情報も必要になります。
こうして、AIの「意図」と「実機操作」の間に、はっきりした境界を作ります。
13. そして「Evidence」が必要になった
AIが仕事を発注した。
Worksが実行した。
でも、
「本当に成功したの？」
という問題が残ります。
そこでEvidenceが重要になります。
例えば、
result
verified
final_state
command_count
exit_code
rollback
evidence_state
evidence_id
evidence_return_state
などです。
つまり、
「やった」
ではなく、
「やった。検証した。そして、その証拠がある」
まで必要です。
ここから、
AIシステムではEvidenceそのものを第一級の情報として扱う必要がある
という考え方が強くなりました。
14. Evidenceは「ログ」と違う
ログは、
何が起きたか
を記録します。
Evidenceは、
その結果をどう確認したか
まで含められます。
例えば、
Execution
↓
Verification
↓
Rollback
↓
Evidence
という流れを一つの構造として扱う。
これにより、
「成功したように見える」
と
「検証可能な成功」
を分けられます。
ここはVERTEXを作る中で、かなり重要な考え方になりました。
15. そこで「曖昧な情報を無理に確定しない」という話に戻る
ここで、最初の問題へ戻ります。
AIが、
「Aである可能性が高い」
と推論した。
それを、
A = TRUE
にしてしまうと、
「可能性が高い」
という重要な情報が消えます。
だったら、
Candidate A
Confidence High
Confirmed False
として持っておけばいい。
この発想が、
Impact DB
につながりました。
16. Impact DBは「曖昧なデータのゴミ箱」ではない
Impact DBについて最初に考えたのは、
「確定していないから、とりあえずここに入れておく」
ではありません。
むしろ、
確定していないことそのものを、意味のある状態として扱う
という考え方です。
例えば、
Observation
↓
Hypothesis
↓
Candidate
↓
Impact
↓
Evidence
↓
Confirmation
という流れを保存する。
重要なのは、
最初の状態を失わない
ことです。
17. 「分からない」はデータである
私はこの考え方をかなり重要だと思っています。
AIシステムでは、
A
B
だけでなく、
Aかもしれない
Bの可能性もある
情報不足
矛盾している
判断できない
追加確認が必要
も情報です。
それなのに、
「DBに入れるには一つに決めないといけない」
と考えると、
データを保存するために情報を壊してしまいます。
だから、
「分からない」を保存する
という設計が必要になる。
これはAI時代のデータ設計として、かなり重要な問いだと思っています。
18. 早すぎる確定は、情報損失になる
例えば、
A = 51%
B = 49%
という状態があったとします。
これを、
A = TRUE
に変換すれば、システムとしては扱いやすくなります。
しかし、
B = 49%
という情報は消えます。
なぜAが選ばれたのか。
Bがどれだけ近かったのか。
後から判断を覆す必要があるのか。
これも分からなくなる。
つまり、
確定とは、情報を増やすこととは限らない。
場合によっては、
情報を圧縮してしまうこと
でもあります。
Impact DBは、そこに抵抗します。
19. RDBとImpact DBを分ける
ここでRDBの価値を否定するわけではありません。
むしろ逆です。
RDBは、
確定した事実を厳密に管理する
ための非常に強い道具です。
だから、
Impact DB
= 未確定・候補・仮説・影響
RDB
= 確定した事実
と役割を分ける。
すると、
Observation
↓
Impact DB
↓
Evidence
↓
Confirmation
↓
RDB
という流れが作れます。
この構造にすると、
「いつ確定したのか」
という概念までデータとして扱えます。
20. そして「記憶」の問題が出てくる
Impact DBを考えていると、別の問題が見えてきました。
AIに記憶を持たせる場合、
何を記憶するのか？
という問題です。
会話履歴でしょうか。
Knowledgeでしょうか。
Vector DBでしょうか。
全部でしょうか。
でも考えてみると、
今の会話
仕事の途中状態
未確定の仮説
確定した事実
長期的な知識
共有されたルール
は全部違います。
なのに「Memory」という一つの箱に入れようとすると、混乱します。
ここから、
LLM Memory Architecture
という考え方につながりました。
21. 記憶は一つではない
現在考えている概念では、例えば、
Working Memory
Session / State Memory
Impact Memory
Confirmed Facts
Knowledge Memory
Shared Brain
などの層があります。
概念的には、
LLM Memory Architecture
┌─────────────────────────┐
│ Working Memory │
└────────────┬────────────┘
↓
┌─────────────────────────┐
│ Session / State │
└────────────┬────────────┘
↓
┌─────────────────────────┐
│ Impact DB │
└────────────┬────────────┘
↓
┌─────────────────────────┐
│ RDB │
└────────────┬────────────┘
↓
┌─────────────────────────┐
│ Knowledge / Brain │
└─────────────────────────┘
という構造です。
ここでは、
何を覚えるか
だけでなく、
どんな状態で覚えるか
も重要になります。
22. 会話履歴と「仕事の記憶」は違う
これは実際にAIを使っているとよく分かります。
チャットの内容が残っていても、
どこまでやった？
何を変更した？
何が検証済み？
何が未完了？
次は何をする？
が分からなければ、仕事は再開できません。
つまり、
Conversation History
と、
Work State
は違います。
ここからSession StateやCheckpointという概念が出てきました。
23. 「セッションが切れても、仕事は切れない」
この考え方は、VERTEX Session Portalの設計にもつながっています。
AIとの接続が切れること自体は、完全になくせないかもしれません。
だから、
切断を前提に設計する
という方向へ進みました。
必要なのは、
Session Watcher
Heartbeat
Reconnect
Message Journal
State Checkpoint
Recovery
Job Reconciliation
Evidence Rebinding
などです。
重要なのは、
チャットを復旧すること
ではありません。
仕事の状態を復旧すること
です。
これが、Session Resilienceの中心思想になっています。
24. AIの記憶には「寿命」がある
さらに考えると、
記憶には寿命があります。
例えば、
Working Memory
→ 数分～数時間
Session State
→ 作業中
Impact Memory
→ 問題が解決するまで
Knowledge
→ 長期間
Confirmed Facts
→ 長期保存
というように違います。
全部を同じ場所へ保存すると、
- 一時情報
- 古い情報
- 確定情報
- 未確定情報
- 共有情報
が混ざってしまう。
だから、
記憶にはLifecycleがある
という考え方になります。
25. 「何でも覚えるAI」が優秀とは限らない
AI Memoryを考えるとき、
「コンテキストをもっと大きくしよう」
という方向に目が行きます。
でも、
全部覚えていることと、必要なことを適切に思い出せることは違う
と思っています。
古い情報。
誤った情報。
未確認情報。
一時的な情報。
重複情報。
これらを全部同じ重みでAIへ渡せば、むしろ判断の邪魔になるかもしれません。
だから、
AI Memoryでは、容量より記憶品質が重要なのではないか
と考えています。
26. そこからMemory Routerへ
記憶を層に分けるなら、
「どの記憶を取りに行くか」
を判断する仕組みも必要です。
例えば、
今の作業
→ Working Memory
前回の作業状態
→ Session State
過去の未解決問題
→ Impact DB
確定した仕様
→ RDB
長期的な知識
→ Knowledge
というようにする。
そこで、
Memory Router
という考え方が出てきます。
LLMに全部のMemoryを渡すのではなく、
今の問いに必要な記憶だけを取り出す
わけです。
27. 記憶とEvidenceをつなぐ
ここでもEvidenceが出てきます。
例えば、
Memory:
「Aかもしれない」
がある。
その後、
Evidence:
「Bを支持」
が来る。
すると、
A
↓
weakened
となる。
さらに別のEvidenceが来れば、
A
↓
confirmed
になるかもしれない。
つまり、
記憶は固定値ではなく、Evidenceによって更新される状態
として扱えます。
28. 「忘れる」ことも記憶の一部
記憶について考えると、
「どう覚えるか」
ばかり考えてしまいます。
でも、
どう忘れるか
も重要です。
一時的なメモを永久保存する必要はない。
逆に、重要な設計知識を短時間で消してはいけない。
つまり、
Retention
TTL
Importance
Authority
Resolution
Archive
などもMemory Architectureの一部になります。
「記憶」と「忘却」はセットです。
29. Agentが増えると、「誰の記憶か」が重要になる
AIが1つなら比較的単純です。
でもAgentが増えると、
Architect
Developer
Reviewer
Researcher
Consultant
など、それぞれ違う役割を持ちます。
すると、
「この情報は誰が知っているのか？」
が重要になります。
そこで、
Private Memory
+
Shared Brain
という考え方が出てきました。
例えば、
Developer Agent
→ 今編集しているファイル
Shared Brain
→ プロジェクト全体のルール
です。
全部の情報を全Agentに共有する必要はありません。
30. MemoryにもPermissionが必要になる
さらに、
Read
Write
Append
Resolve
Share
Promote
Delete
などの権限が必要になります。
特に重要なのは、
誰が確定させる権限を持っているのか
です。
AIが候補を作ることと、
AIが正式な事実へ昇格させることは、
同じ権限でなくていい。
この考え方は、Human GateやARDにもつながっていきます。
31. AIを一人の万能エージェントにしない
ここでARDの話が出てきます。
AIに、
考える
調べる
コードを書く
テストする
レビューする
本番変更する
を全部やらせる必要があるのか。
ここでも、
そもそも一人のAIに全部やらせる必要があるのか？
と考えました。
そこで、
Architect
↓
Developer
↓
Reviewer
のように役割を分ける。
Agentを増やすだけではなく、
責任と権限を分ける
という発想です。
32. ARDは「AIを増やす」話ではない
ARDの本質は、
「三つのAIを並べる」
ことではありません。
重要なのは、
- Role
- Permission
- Handoff
- State
- Retry
- Human Gate
- Review
を含めて、
AIによる仕事そのものを工程として設計する
ことです。
例えば、
Architect
↓
Typed Handoff
↓
Developer
↓
Verification
↓
Reviewer
↓
Human Gate
という流れ。
AI開発を、一種の生産工程として見る。
これがVertex Worksの「工場」という発想ともつながっています。
33. AIを「人間の代わり」にするのではなく、「組織」にする
AIを一人の超人的な存在として考えるより、
専門家の集合体として考えた方が自然なのではないか
と思うことがあります。
Architectは設計する。
Developerは作る。
Reviewerは検証する。
Consultantは相談を受ける。
Workstationは実行する。
Brainは知識を保持する。
こうしていくと、
AIは一人の人格ではなく、一つの組織になる
という見方もできます。
34. VCS ― AI Consultantという発想
この延長で考えたのがAI Consultantです。
単純なChatbotではなく、
現状把握
↓
課題特定
↓
原因整理
↓
選択肢
↓
比較
↓
優先順位
↓
実行計画
まで考える。
しかも、必要なら、
ARD
Brain
Workstation
専門System
へ仕事を渡す。
つまり、
AIが答えるだけではなく、問題解決の工程そのものを設計する
わけです。
35. でも、AIにコンサルタントを全部任せていいのか？
ここでも私は、一つの答えだけを決めたくありません。
世の中には、
AIに任せたい人
もいれば、
AIには任せたくない人
もいます。
なら、
AI Proposal
↓
Reason / Evidence
↓
Comparison
↓
Simulation
↓
Human Gate
↓
Approval
のように、
委譲の段階を設計する
方がいい。
AIを信用するか、しないか。
その二択ではありません。
36. Human GateはAIの敵ではない
Human Gateというと、
AIを邪魔する仕組み
のように見えるかもしれません。
私はそうではなく、
AIの能力と人間の責任を接続する境界
だと考えています。
AIには、
- 発見する
- 推測する
- 比較する
- 設計する
自由を与える。
でも、
- 確定する
- 重要な変更を適用する
- 最終責任を引き受ける
ことは、人間の領域として残す。
こうした境界設計は、AIが強くなるほど重要になると思っています。
37. vCELLという、さらに大きな疑問
ここから、さらに大きな発想へ進みました。
LLMそのものの構造です。
通常、LLMは巨大なモデルとして考えられています。
もちろん、その進化は素晴らしい。
でも、
本当に「大きな一つの塊」にすることが最適なのか？
という疑問がありました。
そこで考えたのが、
vCELL
です。
38. AIを「セル」として考える
vCELLでは、AIを一つの巨大なモデルだけで見るのではなく、
複数のセルが構造を作る
という発想を持っています。
しかも平面だけではなく、
3D、さらに4D的な積層や関係
を考える。
例えば、
1
↓
2
↓
8
↓
32
↓
...
のようなセル階層。
それぞれのセルが情報を持ち、局所的な関係を持つ。
そして全体として、
巨大な単一モデルとは違う情報処理構造
を作れないか。
39. なぜ3Dなのか
ここでも、出発点は違和感です。
平面上に全部を並べると、
遠くの情報まで移動しなければならない
という問題が出てきます。
だったら、
平面
ではなく、
空間
を使えばいいのではないか。
近いところは近いまま。
階層を持たせる。
入れ子にする。
回転させる。
経路を設計する。
ここから、
通信距離そのものを設計対象にする
という発想が生まれました。
40. 「複雑さ」を「構造」で解決する
AIシステムでは、ただ計算量を増やすだけでなく、
どう配置するか
も重要だと考えています。
これはvCELLだけではありません。
VXNもそうです。
Memory Architectureもそうです。
ARDもそうです。
Vertex Worksもそうです。
全部、
複雑になったものを、構造で整理する
という方向を持っています。
41. 小さいモデルを組み合わせる発想
vCELLの考え方では、
120B
30B
8B
4B
のような異なる能力のモデルを、
役割の異なるセル群
として考えることもできます。
一つの巨大なモデルに全部を詰め込むのではなく、
- 推論
- 要約
- 日本語
- 検証
- ルーティング
などを役割として分ける。
ここから、
複数LLMをどう使うか
という問題も、
「モデルを切り替える」
だけではなく、
モデル群そのものを構造化する
という発想に変わっていきました。
42. vCELL-Jという日本語特化の考え方
さらに日本語に特化したvCELLも考えています。
日本語は、
- 省略
- 文脈依存
- 敬語
- 口語
- 技術語
- 略語
- 混在表現
など、単純な単語変換では難しい部分があります。
そこで一つの教師だけではなく、
複数LLMをTeacher Poolとして比較する
という考え方を採りました。
それぞれのモデルの強みを調べ、
Teacher A
Teacher B
Teacher C
...
から能力を抽出して統合する。
ここでも、
一つの巨大なものに全部を任せない
という思想が繰り返し出てきます。
43. VXN-DB ― データも一つにしない
そして、データベースにも同じ考え方が入ってきました。
私たちが考えているのは、
Impact DB
RDB
VXN-DB
という役割分担です。
例えば、
Impact DB
→ 曖昧・候補・影響
RDB
→ 確定した事実
VXN-DB
→ 空間・時間・関係
という考え方。
ここでも、
一つの保存方式ですべてを解決しようとしない
という発想が出ています。
44. VXN-DBでは「空間」が重要になる
一般的なDBは、表形式のデータ整理が非常に得意です。
しかしAIシステムでは、
いつ
どこで
どの状態で
何と関係して
どの順番で
という情報が重要になります。
そこで、
空間だけでなく時間も含めた関係
をデータモデルとして考える。
これも、
「表に入らないから困る」
ではなく、
「そもそも表を中心に世界を考え続ける必要があるのか？」
という問いから始まっています。
45. 私は「UI」も固定したくない
もう一つ大きかったのがUIです。
AI開発環境というと、
左：ファイル
中央：コード
右：チャット
のような従来型IDEを思い浮かべます。
もちろん、それは便利です。
でも、
AIが実際に何をしているのかを見るには、それだけで十分なのか？
と考えました。
そこで、
- Project Explorer
- Agent Chat
- Code
- Live View
- Preview
- Observer
などを一体として考えるようになりました。
46. VVAS ― AIと画面を同時に見る
そこから出てきたのが、
Vertex Visual Authoring Surface（VVAS）
です。
考え方としては、
CURRENT UI
+
PAST UI
を並べて、
何がどう変わったのかを視覚的に確認する
。
さらに、
Screenshot
+
Annotation
+
AI Proposal
+
Live Demonstration
をつなげる。
つまり、
UIを説明するのではなく、UIそのものを会話の対象にする
という発想です。
47. スクリーンショットを「命令」にする
例えば、
この赤枠の部分を変えて
という指示。
人間にとっては簡単です。
しかし従来のAIとのやり取りでは、
どのファイルの、どのCSSの、どのコンポーネントなのか
へ変換する必要がありました。
VVASでは、
Visual Point
↓
Semantic Target
↓
Code / Component
↓
AI Proposal
↓
Preview
という流れを考えています。
ここでも、
人間の自然な表現を、システム側の構造へ翻訳する
というVERTEXの基本思想が出ています。
48. Ray ― 「AIの目」を作る
さらにVertexにはRayという観測の仕組みがあります。
ここでも考え方は単純です。
AIが開発するなら、
まず見えなければならない。
フォルダを見る。
ファイルを見る。
階層を見る。
依存関係を見る。
必要なら内容を見る。
つまり、
AIに「目」を与える
という発想です。
最初は単純なフォルダ一覧でも、
X-Ray
Deep Ray
Explorer
と進化させ、
観測そのものを強くする
という方向へ進めています。
49. 「AIが見えない」ということが問題になる
AIがコードを書けても、
何を見てそう判断したのか
が分からなければ危険です。
だから、
Observe
↓
Understand
↓
Plan
↓
Modify
↓
Verify
という順序が重要になります。
これは人間の開発者にも当てはまります。
いきなり修正するより、
まず見る
。
この「まず見る」という原則は、Ray、ARD、Works、Evidenceすべてに流れています。
50. AIは「賢い」だけでは足りない
ここまで考えてくると、AIシステムに必要なのは単純なIQのようなものではないと感じます。
必要なのは、
- 見る
- 覚える
- 忘れる
- 推測する
- 保留する
- 実行する
- 止まる
- 検証する
- 引き継ぐ
- 復旧する
といった能力です。
つまり、
AIそのものを賢くするだけではなく、AIが仕事を続けられる環境を作る必要がある
ということです。
51. そのためにVERTEXは「OS」に近づいていく
こうして考えていると、VERTEXの各コンポーネントがバラバラの製品ではなくなってきました。
Brain
ARD
Memory
VXN
Works
VRA
Evidence
Session
Ray
Consultant
UI
Runtime
それぞれが、
AIが考え、記憶し、通信し、行動し、検証し、復旧するための機能
になっていきます。
つまり、
AIアプリケーション
というより、
AIが仕事をするためのOperating Environment
に近づいていく。
これが、VERTEXという名前に込めているものでもあります。
52. Vertex Nativeという思想
ここまで作ってくると、「Vertex Native」という言葉の意味も少し変わってきます。
単に、
Vertex独自の技術
という意味ではありません。
むしろ、
AIを中心に置いたとき、システムそのものをどう再設計するか
という思想です。
通信ならVXN。
記憶ならMemory Architecture。
曖昧性ならImpact DB。
実行ならWorks。
仕事の発注ならVRA。
結果の証明ならEvidence。
開発工程ならARD。
観測ならRay。
継続ならSession。
相談ならVCS。
こうして一つにつながってきます。
53. 「既存技術の延長線」だけを歩かない
もちろん、既存技術を使います。
Rustも使う。
SQLiteも使う。
RDBも使う。
JSONも使う。
LLMも使う。
Webも使う。
Electronも使う。
しかし、
既存技術を使うこと
と、
既存技術の考え方に縛られること
は違います。
ここは自分の設計でかなり意識しているところです。
54. 「斜め上」を考える
私は、新しいものを考えるとき、
「今あるものを10%良くしよう」
だけでは物足りないと感じることがあります。
例えば、
「Agentをもっと増やそう」
ではなく、
そもそもAgentをどういう構造にするのか？
「Memoryをもっと大きくしよう」
ではなく、
そもそも記憶を一つにする必要があるのか？
「JSONを速くしよう」
ではなく、
そもそもAI内部でJSONを使い続ける必要があるのか？
「AIにPCを操作させよう」
ではなく、
AIとPCの間に工場を作ったらどうなるのか？
「LLMを巨大化しよう」
ではなく、
巨大化以外に、空間化・分散化という方向はないのか？
この一段外側へ出る感じが、自分の発想の特徴なのだと思います。
55. 「斜め上」は、無謀と同じではない
もちろん、何でも突拍子もないことを考えればいいわけではありません。
アイデアを思いついたら、
仮説
↓
実装
↓
測定
↓
観察
↓
修正
します。
このサイクルを回す。
面白いだけでは残しません。
使えなければ捨てる。
実測できなければ、
「まだ仮説」
とする。
この姿勢はかなり大事です。
56. 「おもしろい」は研究の正当な出発点
技術開発では、
ROI
とか、
市場性
とか、
既存製品との比較
が重要です。
それは当然です。
でも、そこだけから出発すると、
誰もやっていないこと
が非常にやりにくくなります。
だから私は、
「おもしろそう」
を大事にしています。
ただし、
「おもしろいから正しい」
とは考えません。
おもしろいから作ってみる。
作ったら測る。
測ったら考え直す。
その繰り返しです。
57. 「作ってみる」が思想を現実にする
私はアイデアを頭の中だけで完成させようとはしません。
ある程度考えたら、
作ってみる。
実際に動かす。
壊す。
また作る。
この繰り返しです。
例えばVXNも、
最初は考え方でした。
それが実装になり、
VERTEXの通信系へ入り、
そこでまた別の問題が見える。
すると設計を変える。
これはvCELLでも同じです。
Memoryでも同じです。
Worksでも同じです。
58. 実装すると、「思っていたのと違う」が出てくる
ここは重要です。
頭の中ではきれいでも、
実際に作ると、
遅い
重い
複雑
扱いにくい
境界が曖昧
想定外
ということが普通に起こります。
でも、
それは失敗ではなく、観測結果
です。
むしろ、
「思っていたのと違った」
という情報が得られたことに価値があります。
だから、
仮説
↓
実装
↓
現実
↓
差分
↓
新しい仮説
という循環を回します。
59. この「差分」を大切にする
自分がアイデアを出すとき、かなり重要なのが、
理論と現実の差分
です。
理論どおりなら、そのまま進めばいい。
違ったなら、
なぜ違った？
と見る。
その差分が、
新しいアイデアの種
になります。
つまり、
バグも、想定外も、違和感も、全部アイデアの材料
になります。
60. AIと会話することが発想装置になっている
最近は、AIとの対話そのものがアイデア生成の装置になっています。
自分一人で考えると、
思いつく
↓
検討する
↓
終わる
となりがちです。
でもAIとの会話では、
思いつく
↓
言語化する
↓
反論される
↓
別案が出る
↓
さらに考える
↓
構造化する
というサイクルが高速で回ります。
もちろん、AIの言うことをそのまま採用するわけではありません。
むしろ、
AIを壁打ち相手として使う
感覚に近いです。
61. AIに「考えてもらう」のではなく、「考えを広げる」
AIとの対話で大事なのは、
「答えをもらう」
だけではありません。
むしろ、
自分の考えを外へ広げる
ことがあります。
例えば、
「AI間通信をもっと効率化できないか？」
という一言から、
JSON
↓
VXN
↓
Domain Profile
↓
Semantic Communication
↓
Runtime
↓
Neural Network
と考えが広がっていく。
その途中で、
「じゃあ記憶も同じように分けられるのでは？」
となり、
Memory Architectureへ飛ぶ。
さらに、
「曖昧な記憶はどうする？」
となって、
Impact DBへ戻る。
この循環がおもしろい。
62. アイデア同士が「後からつながる」
最初は別々に見えていたものが、後からつながります。
例えば、
VXN
と
Memory
は別の話に見えました。
でも、
MemoryをAgentからどう呼ぶ？
と考えた瞬間、
Agent
↓
VXN
↓
Memory
という関係になる。
Impact DBも、
Memory
↓
Uncertainty
↓
Evidence
としてつながる。
ARDは、
Agent
↓
Memory
↓
VXN
↓
Works
↓
Evidence
へつながる。
こうして、
点だったアイデアが、後から線になる
のです。
63. VERTEXは、最初から完成した設計図ではなかった
これも重要です。
VERTEXを最初から、
VXN
Memory
Impact DB
ARD
Works
VCS
vCELL
まで全部考えていたわけではありません。
一つ考える。
作る。
問題が出る。
その問題を解こうとする。
すると別の技術が必要になる。
それを作る。
また問題が出る。
この連鎖です。
つまりVERTEXは、
最初から存在していた完成品ではなく、問題解決の連続から生まれた構造
です。
64. だからVERTEXは少し変な形をしている
普通なら、
「DB製品です」
とか、
「AI開発ツールです」
とか、
「Agentフレームワークです」
と一言で言えるかもしれません。
でもVERTEXは、
なかなか一言で言えません。
それは、
一つの製品を作ろうとしているというより、AIが活動する世界そのものを設計しようとしている
からです。
65. それでも一つの共通思想がある
バラバラに見えるVERTEXの技術には、共通する考えがあります。
それは、
一つのものにすべてを背負わせない
ということです。
通信を一つの形式に押し込まない。
記憶を一つの箱に押し込まない。
データを一つのDBに押し込まない。
AIの役割を一つにしない。
実行権限をAI一つに渡さない。
UIを一つの表示に固定しない。
セッションを一つの接続に依存しない。
この「分離」が、VERTEX全体をかなり強くしています。
66. 「分ける」だけではなく「つなぐ」
ただし、分離するだけでは意味がありません。
重要なのは、
分けたものを、適切な境界で再接続すること
です。
例えば、
Memory
↕
VXN
↕
Agent
Impact DB
↕
Evidence
↕
RDB
AI
↕
VRA
↕
Works
Architect
↕
Handoff
↕
Developer
です。
だからVERTEXは、
分離と接続の設計
でもあります。
67. 境界を作ると、責任が明確になる
これはシステム設計だけでなく、AIの安全性や監査にも関係します。
例えば、
AIの提案
と、
Humanの承認
を分ける。
Execution
と、
Verification
を分ける。
Inference
と、
Confirmed Fact
を分ける。
Conversation
と、
Work State
を分ける。
この「境界」を明確にすると、
どこで何が起きたのか
を追いやすくなります。
68. その境界が、AI時代には特に重要になる
AIが弱い時代なら、
AIは補助ツール
で済んでいました。
でもAIが強くなるほど、
AIが何をしたのか
が重要になります。
AIが考える。
AIが判断する。
AIが実行する。
AIが記憶する。
AIが別のAIへ渡す。
こうなるほど、
Authority
Provenance
Evidence
State
Permission
が重要になります。
69. 「AIの自由」と「システムの統制」を両立する
私がVERTEXで目指しているのは、
AIを縛りすぎること
でも、
AIに何でもさせること
でもありません。
その間に、
自由な推論
↓
明確な境界
↓
検証可能な実行
↓
Human Gate
を置く。
これによって、
AIの自由度を確保しながら、システムとしての統制も維持する
という構造を目指しています。
70. 「経験」を残すという考え方
もう一つ、最近特に強く感じることがあります。
仕事をしていると、
長年の経験からしか出てこない判断
があります。
それは教科書に書かれていない。
マニュアルにもない。
でも現場では重要です。
AI ConsultantやKnowledge Architectureを考えるとき、
この経験知をどうやって後世に残すのか？
という問題が出てきます。
71. AIは「回答装置」だけではなく、「経験の保存装置」になれるか
例えば、
この状況なら、まずここを見る
とか、
このパターンは見逃しやすい
とか、
この条件なら先に止めた方がいい
という判断。
こうした経験知を、
Observation
↓
Decision
↓
Reason
↓
Outcome
として残せれば、
AIは単に答えるだけでなく、
経験を組織の記憶として残す
役割を持てます。
これはAI ConsultantやShared Brainと深くつながります。
72. だから「記憶」は過去だけを保存するものではない
Memoryは単なる履歴ではありません。
そこには、
- 事実
- 経験
- 判断
- 仮説
- 失敗
- 成功
- 根拠
- ルール
があります。
つまり、
未来の判断に使える形で過去を保存すること
がMemoryの価値です。
73. 私が大事にしているのは「答え」より「構造」
個別の答えは、時間が経てば変わります。
でも、
なぜその答えに至ったのか
という構造は、別の問題にも使えます。
例えば、
問題
↓
観測
↓
仮説
↓
比較
↓
検証
↓
確定
というパターン。
これは、いろいろな分野に適用できます。
だから私は、
単発の正解より、再利用できる構造
を作ることに興味があります。
74. VERTEXは「構造」を作るための実験場
ここまで来ると、VERTEXをどう説明するかも少し見えてきます。
VERTEXは単なる、
AIアプリ
ではない。
単なる、
Database
でもない。
単なる、
Agent Framework
でもない。
むしろ、
AIが考え、記憶し、通信し、実行し、検証し、復旧し、人間と協働するための構造を実験する場
です。
75. まだ答えは出ていない
これは重要です。
VXNも完成した標準規格ではありません。
Impact DBも研究中です。
Memory Architectureも設計中です。
vCELLも仮説を含んでいます。
VXN-DBも今後変化します。
AI Consultantも発展途上です。
つまり、
この記事は完成品の宣伝ではありません。
むしろ、
現在進行中の設計思想を公開している
ものです。
76. 実験して、間違っていたら変える
技術の世界では、
「最初から正しい設計」
を目指しすぎると、何も作れないことがあります。
だから、
仮説
↓
Prototype
↓
Test
↓
Observation
↓
Revision
でいい。
重要なのは、
間違いを早く見つけること
です。
そして、間違いを見つけたら、
それを設計の材料にする
。
77. だから「忘れる」ことも必要になる
これまでの設計を見ていると、記憶だけでなく、
忘れること
も重要だと思うようになりました。
古いアイデア。
使わなくなった設計。
失敗した仮説。
間違った前提。
これらも全部残しておく価値はあります。
ただし、
現行設計と同じ扱いをしてはいけない
。
ここでも、
Active
Superseded
Rejected
Archived
のような状態が必要になります。
これはMemoryにもReference Registryにも共通する考え方です。
78. Reference Registryという発想
そしてもう一つ、最近かなり重要だと感じているのが、
Reference Registry
です。
AIが複数動き、ドキュメントが大量に増えると、
「どれが正式な仕様なのか？」
という問題が起きます。
例えば、
仕様書A
↓
古い
仕様書B
↓
最新版
チャットのメモ
↓
途中案
Git上の文書
↓
別ブランチ
となったとき、
AIは何を参照すればいいのでしょうか。
79. 「存在する文書」と「正規の文書」は違う
ファイルが存在していることと、
それが現在のCanonical Referenceであること
は違います。
だから、
Reference Registry
に、
- Canonical Reference
- Version
- Status
- Authority
- Scope
- Provenance
- Supersedes
- Effective From
などを持たせる。
すると、
「この時点で、この用途では、この文書を正規の基準とする」
ということをシステムとして管理できます。
80. Reference Registryは「文書管理」ではない
ここも重要です。
単なるファイル一覧ではありません。
重要なのは、
正規性の管理
です。
つまり、
どの文書があるか
より、
どの文書を信頼すべきか
を扱います。
これはAIシステムにとって重要です。
なぜならAIは、複数の情報を見つけたとき、
どれを基準にするか
を決めなければならないからです。
81. Reference RegistryとHuman Gate
当然、Reference RegistryをAIが自由に書き換えるのも危険です。
そこで、
AI Proposal
↓
Validator
↓
Human Gate
↓
Registry Update
という構造が考えられます。
つまり、
AIは「この文書をCanonicalにした方がよい」と提案できる。
でも、
「Canonicalとして確定する」
のは別の権限。
ここでも、
Inference
↓
Proposal
↓
Authority
を分けています。
82. VERTEXの設計には、実は共通の文法がある
ここまでを並べると、VERTEX全体に一つの共通パターンがあることに気づきます。
Observe
↓
Interpret
↓
Preserve Uncertainty
↓
Propose
↓
Validate
↓
Execute
↓
Verify
↓
Record Evidence
↓
Promote / Resolve
これが、
- Ray
- Impact DB
- Memory
- ARD
- VRA
- Works
- Evidence
- Reference Registry
のいろいろな場所に姿を変えて現れます。
83. 「確定」を最後に置く
この共通パターンでもっとも特徴的なのは、
確定を早くしない
ことです。
まず観測する。
考える。
候補を出す。
必要なら保留する。
Evidenceを待つ。
検証する。
その後で確定する。
この順序を守る。
これはImpact DBだけでなく、
AI Memory、
Human Gate、
Reference Registry、
Evidence、
全部に共通しています。
84. 「確定していないこと」を恥ずかしがらない
AIシステムでは、
「分かりません」
を言わせたくない、という空気があります。
でも私は、
分からないなら、分からない方がいい
と思っています。
大切なのは、
「分からない」で終わらないこと
です。
例えば、
原因 = 不明
影響 = 高
追加確認 = 必要
なら、それだけで次の行動が決まります。
つまり、
不確実性があっても、前へ進める
ことが重要です。
85. 「不確実性を扱えるAI」は強い
AIにとって、
A
と言うのは簡単です。
でも、
Aの可能性が高いが未確定
と状態を保ったまま扱うのは、システム側の支援が必要です。
だから、
LLMの知能だけを上げるのではなく、不確実性を保存できるインフラを作る
という発想が重要になります。
Impact DBは、その一部です。
Memory Architectureも、その一部です。
86. 私のアイデアの源泉を言葉にすると
ここまで振り返って、ようやく、
「自分はどこからアイデアを持ってきているのか」
が少し分かってきました。
たぶん、次のような流れです。
現場の違和感
↓
既存の前提を疑う
↓
一段戻って問題を再定義する
↓
異分野の原理を持ち込む
↓
大胆な仮説を立てる
↓
小さく作る
↓
現実を見る
↓
差分を発見する
↓
また考える
↓
構造にする
これが繰り返されています。
87. 「なぜ？」を何回も繰り返す
自分の発想では、
Why?
を一回で終わらせないことが多いです。
例えば、
なぜAI間通信にJSONを使う？
↓
汎用的だから。
↓
なぜ汎用である必要がある？
↓
人間やシステム間で交換するから。
↓
じゃあAI内部も同じである必要がある？
↓
本当に？
ここまで戻ると、
VXNの発想が出てきます。
Impact DBも、
なぜDBには確定値を入れたがる？
↓
検索しやすいから。
↓
じゃあ未確定情報はどうする？
↓
なぜ確定させる必要がある？
↓
確定しないまま保存すればいいのでは？
となります。
88. 発想は「一段外側」に出ることで生まれる
これが、自分の発想の大きな特徴なのかもしれません。
問題があるとき、
問題の中で解決方法を探す
だけではなく、
その問題が成立している前提そのものを見る
。
そして、
その前提から外へ出る
。
すると、
今まで候補になかった選択肢が見えてくる。
89. その結果、VERTEXは「斜め上」になる
VXNもそうです。
Impact DBもそうです。
vCELLもそうです。
Memory Architectureもそうです。
Worksもそうです。
Reference Registryもそうです。
普通なら、
「もっと既存の仕組みを良くしよう」
となるところで、
「そもそも、その仕組みを前提にする必要がある？」
と考える。
そこから別の構造を試す。
だから、結果として少し斜め上のものになります。
90. でも、斜め上に行ったら必ず現実に戻る
これはかなり重要です。
どれだけ面白いアイデアでも、
作れない
↓
測れない
↓
使えない
なら意味がありません。
だから最後には必ず、
実装
へ戻ります。
そして、
実測
へ戻ります。
そして、
現場
へ戻ります。
91. 私にとって「現場」は最終テスト
机の上で美しい設計でも、
現場で使えなければ意味がありません。
だから、
現場で本当に使えるか
が最終的なテストになります。
これは、AIでもDBでもUIでも変わりません。
92. 理論と現場の間を往復する
自分の開発スタイルを言葉にすると、
現場
↓
違和感
↓
抽象化
↓
理論
↓
設計
↓
実装
↓
実験
↓
現場
という往復運動です。
一方通行ではありません。
現場から理論へ行き、
また現場へ戻る。
ここがかなり重要です。
93. 「未来のための設計」も忘れない
VERTEXでは、今使えることだけではなく、
数年後にも残る構造
も考えるようになっています。
例えば、
- Provenance
- Reference Registry
- Evidence
- Memory
- Knowledge
- Shared Brain
などです。
なぜなら、
人間がいなくなっても、AIが増えても、システムが変わっても、
過去の判断や経験を追跡できることが重要だからです。
94. AIにノウハウを継承させる
人間の経験には寿命があります。
組織から人がいなくなれば、その経験も失われることがあります。
そこで、
Experience
↓
Knowledge
↓
Memory
↓
Evidence
↓
AI
という形で、
経験知をシステムとして残す
ことができれば、
AIは単なる自動化装置ではなく、
知識の継承装置
にもなります。
これはVCSやShared Brainの大きなテーマです。
95. VERTEXは「次の人」のためにも作る
自分だけが分かる仕組みを作っても、長くは続きません。
だから、
後から別の人が理解できる構造
を目指したい。
Reference。
Evidence。
Provenance。
Registry。
Architecture。
これらは全部、
未来の人間と未来のAIのための説明可能性
にもつながっています。
96. そして、まだまだ終わっていない
VERTEXには、まだたくさんの問いがあります。
例えば、
AI Memoryはどこまで構造化できるのか？
Impact DBはどこまで有効なのか？
VXNは本当に既存方式より効率が良くなるのか？
vCELLは3D構造によって本当に通信や計算を改善できるのか？
AIはどこまでConsultantとして働けるのか？
Agent組織はどこまで自律できるのか？
Human Gateをどこに置くべきなのか？
まだ答えはありません。
97. でも、答えがないことは悪くない
むしろ、
まだ分からないから作る
というのが研究の面白さだと思っています。
最初から答えが分かっているものを作るだけなら、
新しい設計思想は生まれにくい。
だから、
仮説
↓
実験
↓
結果
を繰り返します。
結果が予想通りなら前進。
予想外なら、それも前進。
98. VERTEXは「完成品」ではなく「思考の履歴」
だから、VERTEXそのものを、
完成した製品
として見るより、
考えたこと、作ったこと、失敗したこと、修正したことが積み重なった思考の履歴
として見る方が近いかもしれません。
VXNがある。
Impact DBがある。
Memoryがある。
ARDがある。
Worksがある。
Evidenceがある。
それぞれは、
「その時点で必要だった問題を解こうとして生まれたもの」
です。
99. 私がアイデアを作るときのルール
改めて整理すると、今のところ自分の中には、いくつかのルールがあります。
1. まず違和感を見る
「なんとなく変だ」を無視しない。
2. 前提を疑う
「なぜそうなっているのか」を考える。
3. 一段外側から見る
問題そのものではなく、問題を作っている構造を見る。
4. 異分野から持ってくる
コンピュータだけで考えない。
5. 大胆な仮説を立てる
最初から小さく正解を狙わない。
6. すぐ作る
頭の中で完成させようとしない。
7. 実測する
「たぶん」は、実測で確認する。
8. 間違いを捨てない
失敗も次の設計材料にする。
9. 確定を急がない
不確実性そのものを残す。
10. 最後は現場へ戻す
現実に使えるかを確認する。
100. おわりに
私にとって、アイデアは「突然ひらめくもの」ではありません。
もちろん、突然思いつくことはあります。
でも本質的には、
違和感
↓
疑問
↓
前提への疑い
↓
異分野との接続
↓
仮説
↓
実装
↓
失敗
↓
観測
↓
再設計
という繰り返しの中から生まれます。
VXNもそうでした。
Impact DBもそうでした。
LLM Memoryもそうでした。
ARDもそうでした。
Vertex Worksもそうでした。
vCELLもそうでした。
Reference Registryもそうです。
最初から完成された設計図があったわけではありません。
一つの疑問から始まり、
「そもそも、こうである必要があるのか？」
と問い続けた結果、少しずつ構造ができてきました。
そして、最近になって分かってきたことがあります。
VERTEXの本当の中心は、特定の技術ではないのかもしれません。
VXNでもない。
Impact DBでもない。
vCELLでもない。
Brainでもない。
Worksでもない。
その奥にあるのは、
「既存の前提を疑い、新しい構造を考え、それを実際に作って確かめる」
という姿勢そのものです。
だからVERTEXは、まだ完成していません。
これからも、
なぜ？
↓
本当に？
↓
そもそも？
↓
別の方法は？
↓
作ってみよう
を繰り返していくことになると思います。
そして、もし何か面白いものが生まれたら、
それをまた実装し、
測定し、
壊し、
作り直していく。
私にとって、それが技術を作るということです。
VERTEXという実験
最後に、一言でこの活動を表すなら、
VERTEXは、AIの未来を予測するためのプロジェクトではなく、AIの未来に必要になるかもしれない構造を、自分たちで先に作ってみるための実験です。
正しいかどうかは、まだ分かりません。
だから作る。
作ったら測る。
測ったら考える。
そして、また次を作る。
その繰り返しの先に、
まだ名前のない何かが生まれることを楽しみにしています。