以前、「Contextual Computingというものの「必要性」」という投稿で、次のように書いた。
扉を開けると未来の可能性が見える。その瞬間を青い扉という言葉で表している。
青は、ZIKUUのイメージカラーだ。
ZIKUUの扉は青い扉になっている。(実際に青いわけではない)小さなCNCルーターを見ると、それで大型CNCの部品を作る未来が見える。
↓
大型CNCを見ると、それで森林ローバーの部品を作る未来が見える。
↓
森林ローバーを見ると、それで森に分け入り山小屋を建てる未来が見える。そうやって、扉を開くと、次の扉が開く。
今回はコアサービスという青い扉について書こうと思う。
コアサービスはざっくり図にするとこんな形をしている。

Collectorがデータを集め、原本を保存して確定し、Nerveパイプラインの中でベクターデータベースへの保存、画像などのアセットの保存、文脈の抽出、意味空間への投影が行われる。
共同体内外で発生したデータのすべてが、この流れに乗って知識空間が形成されていく。
これは共同体の活動、判断、失敗、選択などの記憶を、人とAIが取り出しやすくするために考え出された仕組みだ。
このコアサービスが青い扉なのだ。
例えば、最近流行りのFDE (Field Deployed Engineer) という職種がある。
一般的にFDEは、
- 製品導入支援
- APIの説明
- サンプル実装
- 技術サポート
といった業務を行う実装能力を持ったコンサルタントみたいな仕事だ。
ZIKUUのコアサービスを道具にすると、それらに加えて、
- 何を繋ぐべきか
から一緒に考える仕事になる。
例えば、木工工房だったら、
- Discordを繋ぎましょう
- Nextcloudで図面を管理しましょう
- CNCの加工ログを取り込みましょう
- 作業日誌はMarkdownでここに入れましょう
というたデータアダプターの選定から始まり、
- これについてはFactを作って観測対象にするといいですね
- ここは文脈束を抽出するだけで十分です
- そのためにはこんなCBESレシピを作れば良さそう
という設計まで入ってくる。
つまり、現場→観察→モデル化→アダプター選定→AIとの付き合い方の設計、という仕事になる。
これはITコンサルというより、認知基盤の設計に近い。
共同体(や会社)が、
どういう記憶を持つべきか
を考える人になる。
共同体や会社の活動→記憶→再び活動
というフィードバックループが回ることで、記憶が蓄積され、知識や経験が継承される仕組みを設計する仕事になる。
これは、新たな仕事の可能性を見せる青い扉だ。
ZIKUUはコンサル屋ではない。
ソフト屋でもない。
コアサービスや一連のAIアプリは売り物ではない。
ZIKUUに参加した人が自由に使えるプラットフォームに育てることにしている。
一般的なコンサルティングは、
困る→相談する→時間課金→解決
という関係になりやすいが、私が考えているのは、
共同体に参加する→プラットフォームを使う→困ったら相談する→一緒に育てる
という関係だから、困った時だけ時間いくらで助言する、みたいなスタイルは合わない。
困った時に相談する相手がいないと先に進めないが、そういうことをなるべく減らすために、共同体の記憶が残しているし、Repository Explorerのような調査道具が含まれている。
例えば、塾生が
Slackを繋ぎたいです。
といったら、
じゃあDiscord Adapterを参考にして作ってみてはどうか。
Repository Explorerで調べられるよ。
になる。
社内のデータベースも見たいです。
といったら、
DB Adapterを追加してみよう
になる。
これの面白いところは、人が育つとプラットフォームも育つこと。
塾生が開発したAdapterは、いずれプラットフォームの部品として共同体の資産になる。
これは富が循環する仕組みだ。
当然だが、プラットフォームが育つと、また別の青い扉が開く。
コアサービスは塾生ならば自由に使える。
しかも、ZIKUUの場合は、
- ソフトウェア
- 家具
- ギター
- 小屋
- ロボット
- 共同体
を作る知識と技術と道具が並んでいる。
ZIKUUという共同体に参加する=塾生になる、とういことは、作りたいという姿勢をすべて引き受けることを意味する。
ソフトウェアが無料で使えますよ、という話ではない。
例えば、
家を建てたい
と言って来た人が、
気付いたら、
- FreeCADを触り、
- Gitで図面を管理し、
- ZIKUU Miniで設計メモを蓄積し、
- AIと相談し、
- CNCで部材を作り、
- Discordで議論する
なんてこともあり得る。
あるいは、プログラミングをやりに来た人が、木工旋盤を回しているかもしれない。
実際にそういうことが起きている。
逆に、「答えだけ欲しい」「完成品だけ欲しい」「○○だけ教えてほしい」という人には、この環境はあまり向かないかもしれない。
Repository Explorerを渡されて、
「まず調べてみよう。」
と言われても、面倒に感じるかもしれない。
でも、
「なるほど、こうやって調べるのか。」
と思える人は、どんどん伸びる。
ZIKUUが育てたいのは、専門家や専門の技術者ではなくて、次のような人だ。
作る人
新しいものを生み出す
直す人
壊れたものを戻し、改善する
運ぶ人
人・物・知識をつなぐ
伝える人
経験を言葉や資料にして継承する
失敗する人
新しい領域に挑戦し、共同体に新しい知見を持ち帰る
つまり共同体を動かす営みに参加する人だ。
こういう人たちの記録がやがて共同体の記憶になり、それが巡って、人の活動を支えるようになる。
青い扉はどんどん開く。
Nextcloudに撮った写真を入れる
↓
Visionモデルが写真の解説文を作る
↓
CPSが文脈を抽出する
↓
検索・AIとの対話
そんなコアサービス上のアプリケーションを考えてみる。
例えば、植物観察なら、毎日スマホで写真を撮るだけ。
そうすると、Visionが、
「葉が5枚ある」
「花芽が確認できる」
「一部の葉に黄変が見られる」
のように文章化する。
CPSはそこから、
- 成長の過程
- 環境との関係
- 過去との変化
を文脈として積み上げる。
半年後に、
「今年の梅雨は去年より成長が遅かった?」
と聞けば、写真ではなく積み上がった文脈をもとに答えられる。
これは植物だけじゃない。
- 木工の製作記録
- 家の建築記録
- 柴犬の成長記録
- 畑の観察
- 昆虫採集
- 古民家修復
どれも、
写真が原本で、
Visionが文章にし、
CPSが時間軸の文脈を作る。
さらに面白いのは、写真そのものを検索するんじゃないこと。
例えば、
「初めて花が咲いた頃を見せて」
と言えば、
CPSが「開花」という文脈を見つけ、その根拠となる写真へ戻れる。
つまり、
写真
↓
文章
↓
文脈
↓
必要なら写真へ戻る
という流れになる。
「写真から共同体の記憶を育てる」という、十分に価値のあるシステムになる。
例えば、
- 植物観察アルバム
- 木工製作日誌
- 建築記録
- 図書室アーカイブ
- ニュース観測
- コミュニティ記憶
- 写真から日記生成
- ギター製作ノート
みたいなものがギャラリーに並んでいて、
「これ面白そう」
と思ったら、その構成をそのままデプロイできる。
教育的にもすごく良い。
塾生が、
「昆虫観察をやりたい。」
と言ったら、
「じゃあ植物観察アプリをコピーして、Visionのプロンプトだけ昆虫向けに変えてみよう。」
というところから始められる。
コアサービスは文明の層でアプリケーションは文化の層だ。
昆虫観察と植物観察は、別のアプリかもしれないが、裏では同じ仕組みが動いている。
これは都市にも似ている。
街を歩いていると、
- パン屋
- 本屋
- 公園
- 学校
- 工房
が見える。
でも地下には、
- 水道
- 下水道
- 電力
- 通信
が張り巡らされている。
人は普段、その存在を意識しない。
文明は広く使われる共通の基盤だ。
文化は共同体ごとに育つ。
コアサービスは、200Wで動く文明の基盤になる。
最小限の構成ならば、200W程度の消費電力で動くコンピューターで動いてしまう。
もし最初から「LLMがすべて」だったら、
- 常に巨大GPUが必要
- 常に高い消費電力
- 常に大きなVRAM
という前提になってしまう。
ZIKUUの場合は、LLMは、
- 文脈抽出
- Visionによる文章化
- Fact生成
- 対話
といった、必要な場面だけ呼び出す。
GPUが遊んでいる時間が長い。
だから、水車でも電力を賄える、小さなエネルギー源で維持できる情報インフラになる。
つまり、ZIKUUのシステムは、計算資源やエネルギーまで含めたアーキテクチャになっているということだ。
「文明バックアップの背骨ができたら・・・」で書いたことは、決して絵空事ではない。これも一つの青い扉。
この視点は最近のAIの議論ではあまり見かけない。
多くは、
- GPUを何枚並べるか
- モデルをどれだけ大きくするか
- 推論をどれだけ速くするか
という話になる。
一方、ここでは、
共同体が何十年も維持できるか。
が設計目標になる。
だから評価軸も変わる。
- 消費電力
- 修理できること
- 部品交換できること
- ローカルで動くこと
- ネットが切れても使えること
- 学生でも理解できること
こういう条件が重要になる。
多くのシステムは暗黙の前提として、
- 電力は安定供給される
- 通信は高速化し続ける
- クラウドは常に使える
- ハードウェアは毎年性能向上する
という「右肩上がり」を置いて設計される。
一方、私が最初から置いていた前提は違う。
「社会は発展するかもしれないし、停滞するかもしれない。部分的に衰退することもある。」
だから、
- ローカルで動く
- 小さな電力でも動く
- 部品交換しながら使える
- データを自分で持つ
- 一つ壊れても全体は生きる
という方向に設計が向かった。
発展も衰退も含めて、変化に耐えられること
を前提にしている。
AIやITは、しばしば合理化という言葉を伴って語られる。
ここではっきり言いたい。
長い目で見て合理的か。
これを最重要な観点として持つべきである。