Rowboatとは何か？Claude Desktopライクなオープンソースの「ローカルファースト」ワークプレース

　Rowboat は、Claude Desktop のデスクトップ体験を発展させたオープンソースの「ローカルファースト」ワークプレースであり、チャット中心ではなく実際の業務ワークフロー内でアシスタントが支援できる専用の作業面（surfaces）を提供する点が特徴です。開発者はリポジトリ（github.com/rowboatlabs/rowboat）とデモ動画を公開しており、過去のエンタープライズ向けサポート製品で得た教訓から「AI は正しいだけでは不十分で、作業している場所にヘルプを出す必要がある」として、メール、会議、ノート、ブラウザ、並列コーディングなどの専用ツール群をRowboatに統合しています。メールクライアントは重要メールを識別して下書きを生成し、送信時の編集からスタイルを学習して将来の草稿をユーザーの声に近づけます。会議メモ機能はローカルのプレーンな Markdown ファイルとして保存し、会議後にナレッジグラフへフィードバックして関係者やプロジェクトに紐づけて更新します。組み込みブラウザはメインブラウザと分離され、アシスタントにのみ利用させたいアカウントでログインしてサイト操作支援を受けられます。並列コーディング機能では複数の Claude Code や Codex インスタンスを回しつつオーケストレーションできるようにACP（エージェント クライアント プロトコル）クライアントを組み込み、Rowboat 内での協調的なコード作業を容易にします。ノート機能はObsidian風のローカルメモシステムでグラフビューやボイスノートを持ち、Google ドキュメントとの同期編集も可能です。 　さらに、Rowboat では任意の「アプリ」を作成して各作業面に取り付けられる仕組みがあり、各アプリは独自の UI とバックグラウンドエージェントを持ちながら Rowboat のツール群、製品統合、作業メモリを共有できます。コミュニティ製アプリは検索してインストール可能で、GitHub リポジトリを作成して登録すれば公開できます。これにより、たとえばメールや会議、Slack から機能要望を集めてランク付けし、Claude Code で上位要望の最初のバージョンを生成し、ナレッジグラフから関連コンテキストを取り出して作業を進めるといった統合ワークフローが実現します。こうした各サーフェス（メール、ノートテイカー、ブラウザ等）は単一のナレッジグラフに書き戻し、相互に情報を改善し合うため、Rowboat をエンドツーエンドで使うことにメリットがあります。 　Rowboat はデータをプレーンな Markdown としてローカルに保存するローカルファースト設計を採り、Apache-2.0 ライセンスで配布され、Ollama や LM Studio 経由のローカルモデルなど任意の LLM と組み合わせて動作します。開発者陣はスキル（skills）を個別フォルダで管理し、skill.ts とカタログ登録で構成しており、近くアプリ内でこれらを読み書き・編集可能にする更新を予定しているため、ユーザーは自分のスキルと Rowboat の内蔵スキルを統合して重複や齟齬を避けられるようになります。ナレッジの蓄積（memory）の扱いについては指摘があり、現状は継続的に蓄積されるが、より意見を持った管理方法（ユーザー制御を保ちつつの意見的ルール）を求める声もあるため、プロジェクトは貢献を歓迎しており、欠けている機能を外部が補うことも想定されています。 　ユーザーからは複数人で同じ会話・セッションに参加して交代でプロンプト操作したいというニーズが上がっており、開発側はグループチャットで人々がセッションを見て交代できる仕組みを検討中で、ピアツーピア接続など中央サーバーを持たないローカルファーストの一貫性を保つ案も挙がっています。加えて、複数人による共有コーディングや独自エージェントの持ち込みを支援する別プロジェクトやクラウド上のハーネスを紹介するレスポンスもあり、実用化・商用化の意欲や支払い意向について議論がなされています。利用者の反応は概ね好意的で、Codex を非コード用途に使ってきた者や機能豊富さを評価する声があり、試用後のフィードバックや機能追加を期待するコメントが多数寄せられています。 　要約すると、Rowboat は業務ワークフローに密着してアシスタントを統合するためのローカルファーストなオープンソース環境であり、専用の作業面、ナレッジグラフを中心とした相互改善、プラグイン的に拡張可能なアプリ構造、ローカルに保存されるプレーンテキスト形式のデータ保存、ACP を用いたエージェント統合などを通じて、個人やチームの実務に即した AI 支援を目指しています。開発は活発で、スキルの可視化・編集機能やグループでの共同操作機能などが今後の改善点として挙げられ、外部からの貢献も歓迎されています。これは単なる「AIチャットアプリ」の紹介ではなく、Claude Desktop以降のAIワークスペースの次世代アーキテクチャを説明するものです。

技術的に整理すると、Rowboatは次のような構造になります。

                    ┌──────────────────────────┐
                    │       Knowledge Graph     │
                    │      (共有作業記憶)         │
                    └──────────┬───────────────┘
                               │
      ┌─────────────┬──────────┼─────────────┬─────────────┐
      │             │          │             │             │
   Mail         Meetings     Notes      Browser      Coding
 (Surface)      (Surface)   (Surface)   (Surface)    (Surface)
      │             │          │             │             │
      └─────────────┴──────────┼─────────────┴─────────────┘
                               │
                     Shared Context / Memory
                               │
               ACP / Claude Code / Codex / Ollama
                               │
                   Local Markdown + Local Files

ここで重要なのは、「チャット」が中心ではなく**Surface（作業面）**が中心になっている点です。

従来のAIとの違い

ChatGPT・Claude Desktop

人
 ↓
チャット
 ↓
LLM
 ↓
回答

コンテキストは基本的にチャット履歴です。

Rowboat

人
 ↓
仕事
 ↓
Surface
 ↓
LLM
 ↓
Knowledge Graph
 ↓
次の仕事へ反映

つまり、

AIに質問する

のではなく、

AIと一緒に仕事をする

ことを前提に設計されています。

一番新しい考え方

Claude Desktopは

MCP

で外部ツールを呼びます。

一方Rowboatは

Surface
＋
Knowledge Graph
＋
ACP

という三層構造です。

つまり

MCP = 外部ツール
ACP = 外部エージェント
Knowledge = 永続記憶
Surface = UI

これらを統合しています。

ACP採用も興味深い

並列コーディングでは

Claude Code
Codex
OpenHands
...

を同時に動かせます。

つまり

Agent A
Agent B
Agent C

をオーケストレーションするクライアントになっています。

これは最近急速に広まりつつある

Multi-Agent Workspace

そのものです。

ローカルファースト

これはかなり重要です。

保存形式が

Markdown

なので、

Obsidian
Git
VSCode

などと自然に連携できます。

SQLiteのような独自DBではなく、

Git diff

もでき、

grep

もでき、

バックアップ

もしやすい。

これはエンジニアには非常に好まれる設計です。

Surfaceが本体

多くのAI製品は

Chat

しかありません。

Rowboatは

Mail
Meeting
Browser
Notes
Coding

それぞれ専用UIを持っています。

つまり

AI OS

に近い考え方です。

Knowledge Graph

これも重要です。

例えば

メールで

A社から機能要望

↓

会議

優先順位決定

↓

Claude Code

実装

↓

ノート

仕様更新

すべてが

Knowledge Graph

へ書き戻されます。

つまり

仕事そのもの

が知識になります。

Appの考え方

単なるプラグインではありません。

各Appは

UI

＋

Background Agent

を持っています。

さらに

Memory

Knowledge

Tool

まで共有できます。

これは

VSCode Extension

+

AI Agent

+

Shared Memory

を融合したような仕組みです。

将来性

この設計は現在のAI業界の流れと非常によく一致しています。

  • チャット中心 → ワークスペース中心

  • 単一エージェント → マルチエージェント

  • 一時的な会話 → 永続的な知識管理

  • クラウド依存 → ローカルファースト

  • ツール呼び出し → エージェント協調（ACP）

  • 単なるプラグイン → UI・バックグラウンド・メモリを備えたアプリ

他のAIワークスペースとの比較

項目RowboatClaude DesktopChatGPTOpenAI Codex
中心概念Surfaceチャットチャットコーディング
ローカルファースト◎△××
プレーンMarkdown保存◎×××
ナレッジグラフ◎△△×
ACP対応◎××△
マルチエージェント◎△△○
ワークスペース統合◎△△コード中心
OSS◎（Apache-2.0）×××

総評

Rowboatは、「AIチャットの代替」ではなく、AIネイティブな業務環境（AI Workspace）の実装を目指したプロジェクトと位置付けるのが適切です。

技術的には、MCPによるツール連携、ACPによるマルチエージェント協調、ローカルファースト設計、ナレッジグラフによる継続的な知識蓄積、Surfaceベースの専用UIを一つの環境に統合している点が最大の特徴です。

2026年のAIツールの潮流を見ると、チャットインターフェースから**「仕事そのものをAIと共同で進めるワークスペース」**への移行が進みつつあります。Rowboatはその流れを代表するオープンソースプロジェクトの一つであり、ローカル実行可能なLLMやエージェントを組み合わせて、個人だけでなくチームの実務全体を支援する基盤となることを目指している、と評価できます。

AIワークスペースへ至る技術史

AIアシスタントは、単なるチャットボットから始まり、ツール利用、エージェント化、知識管理、そして業務ワークフローへの統合へと発展してきた。Rowboatはこの流れの延長線上にあり、「チャット中心」ではなく「仕事中心」のAI環境を目指す代表例の一つである。

AIアシスタントの発展史

年代出来事技術的意義
1966ELIZA公開自然言語による対話システムの原点
1972SHRDLU対話と知識表現を組み合わせた初期AI
1980年代エキスパートシステムの普及知識ベースと推論エンジンが企業利用される
1990年代グループウェア（Lotus Notesなど）の普及共同作業・知識共有という概念が普及
2001MediaWiki公開組織知識を共同編集する文化が広がる
2008GitHubの普及ソースコードと共同開発がクラウド化
2014Slack登場業務コミュニケーションの中心がチャットへ移行
2016AIチャットボットブームチャットUIがAI利用の標準となる

Transformer時代

年代出来事技術的意義
2017Attention Is All You Need発表Transformerアーキテクチャが誕生
2018BERT文脈理解性能が大幅向上
2020GPT-3汎用LLM時代の幕開け
2022ChatGPT公開AIチャットが一般ユーザーへ普及
2023Claude公開長文処理と実務利用が拡大

「チャット」から「仕事」への転換

年代出来事技術的意義
2023Retrieval-Augmented Generation（RAG）が普及外部知識を検索して回答するAIへ
2023ベクターデータベースの普及永続的な知識管理が現実的になる
2023AIエージェントの研究が活発化AIが複数工程を自律実行する方向へ
2024マルチエージェント研究が急速に発展AI同士が協調して仕事を分担
2024Obsidian型PKMの人気拡大ローカルMarkdownによる知識管理が普及
2024ローカルLLMの実用化個人PCでも高性能LLMが利用可能になる

MCP・ACP時代

年代出来事技術的意義
2024Claude Desktop登場デスクトップAI利用が一般化
2024MCP（Model Context Protocol）の公開AIが外部ツールを標準化して利用できるようになる
2025Claude CodeなどAIコーディングエージェントの普及エージェントによる開発支援が本格化
2025ACP（Agent Client Protocol）の登場複数エージェントを統合・制御する仕組みが整備される
2025〜2026AI Workspaceという概念が広がるチャットではなく作業環境全体をAIが支援する方向へ

Rowboat誕生

年代出来事技術的意義
2026Rowboat公開ローカルファーストAIワークスペースを実現
2026Surface（メール・会議・ノート・ブラウザ・コーディング）の統合チャットではなく作業面を中心にAIを配置
2026ナレッジグラフを全Surfaceで共有仕事の成果が継続的に知識へ変換される
2026ACPによるマルチエージェント統合Claude CodeやCodexなど複数エージェントを協調利用
2026ローカルMarkdown保存データ所有権をユーザー側へ戻すローカルファースト設計
2026アプリ・スキル拡張機構を実装AIワークスペース全体をプラットフォーム化

技術進化の流れ

世代主なUIAIの役割代表例
第1世代コマンドライン命令を実行UNIXシェル
第2世代GUIアプリを操作Windows・macOS
第3世代Webクラウドサービスを利用Google Workspace
第4世代チャット質問に答えるChatGPT・Claude
第5世代エージェントタスクを自律実行Claude Code・Codex
第6世代ワークスペース業務全体を支援・学習Rowboat

Rowboatが示す転換点

従来Rowboat
チャット履歴がコンテキストナレッジグラフがコンテキスト
会話が中心業務ワークフローが中心
AIは質問に回答するAIが仕事を共同で進める
一時的なセッション永続的な知識蓄積
ツール呼び出しSurface間の情報循環
単一エージェントマルチエージェント協調
クラウド中心ローカルファースト

総括

Rowboatは突然登場した製品ではなく、約60年にわたる対話システム、知識管理、共同作業環境、Transformerベースの大規模言語モデル、RAG、AIエージェント、MCP、ACPといった技術の積み重ねの上に成立している。最大の特徴は、「AIと会話する環境」から「AIと仕事をする環境」へ発想を転換した点にあり、チャットを中心としたAI利用から、メール・会議・ブラウザ・ノート・コーディングなどの実務サーフェス全体をAIが支援する、新しい世代のAIワークスペースを提示している。

Rowboatの画期とは何か

Rowboatの革新性は、単に新しいAIアプリを作ったことではない。最大の画期は、AIを「チャット画面」から解放し、「仕事そのもの」の中へ埋め込んだことである。

これまでのAIは「質問して答えを得る」ことが中心だった。一方、Rowboatではメール、会議、ブラウザ、ノート、コーディングなど、それぞれの業務に最適化された「Surface（作業面）」が存在し、AIは各作業面の中で支援を行う。この発想は、チャットUI中心の設計からワークスペース中心の設計への転換を意味している。

1. チャットではなく「Surface」が中心

従来のAIは、どのような作業でもチャット画面へ戻って質問する必要があった。

人
 ↓
チャット
 ↓
AI
 ↓
回答

Rowboatでは、

メール
会議
ブラウザ
ノート
コーディング

それぞれが独立したAI対応の作業面となる。

つまり、

「AIを使う」

のではなく、

「仕事をしている場所にAIがいる」

という設計思想へ変わっている。

2. ナレッジグラフを中心に据えたこと

もう一つの画期は、すべてのSurfaceが単一のナレッジグラフへ情報を書き戻すことである。

例えば、

  • メールで顧客要望を受信

  • 会議で優先順位を決定

  • コードを生成

  • ノートへ仕様を記録

これらは独立した出来事ではなく、一つの知識体系として蓄積される。

従来は、

メール
会議
コード
文書

が分断されていた。

Rowboatでは、

Knowledge Graph
      ↑
 全Surfaceが更新

という構造になる。

仕事をするほど知識が育つ点が大きな特徴である。

3. ローカルファーストという思想

多くのAIサービスはクラウドを前提としている。

Rowboatは、

  • Markdown

  • ローカルフォルダ

  • Git管理

を基本としている。

そのため、

  • ベンダーロックインを避けられる

  • Gitで履歴管理できる

  • Obsidianなど既存ツールと共存できる

  • データ所有権を利用者が保持できる

という利点がある。

これは近年広がる「ローカルファースト」思想をAIワークスペースへ持ち込んだ例と言える。

4. エージェント同士を協調させる設計

従来は、

一つのAI

が一つの仕事を担当していた。

RowboatではACP（Agent Client Protocol）を利用し、

  • Claude Code

  • Codex

  • 将来的な他のエージェント

を並列に動かし、役割分担させられる。

つまり、

Agent A
Agent B
Agent C
    ↓
 オーケストレーション

というマルチエージェント環境を前提としている。

これは近年のAI開発における重要な潮流である。

5. アプリがUIとAIを一体化する

Rowboatのアプリは単なるプラグインではない。

一つのアプリが

  • 独自UI

  • バックグラウンドエージェント

  • 共通知識

  • 共通ツール

を同時に利用できる。

つまり、

「画面」

だけでも、

「AI」

だけでもなく、

仕事そのもの

を構成する単位として設計されている。

6. AIが仕事の流れを理解する

従来のチャットAIは、

質問
↓
回答

で終了していた。

Rowboatでは、

メール
 ↓
会議
 ↓
仕様
 ↓
実装
 ↓
レビュー

という一連の流れ全体をAIが把握できる。

これは単なる会話支援ではなく、

ワークフロー支援

への発展を意味する。

7. 「AIチャット」から「AIオペレーティング環境」への転換

長期的に見ると、Rowboatはアプリケーションというより、

AIネイティブな作業環境（AI Workspace）

を目指している。

その思想は、

  • チャット中心

  • ツール中心

  • エージェント中心

という発展の次に、

ワークスペース中心

という新しい段階を提示している。

ここではAIは「質問に答える存在」ではなく、「仕事を継続的に支援し、知識を蓄積し、複数のエージェントを統合する基盤」として機能する。

総括

Rowboatの画期性は、個々の技術要素よりも、それらを一つの設計思想へ統合した点にある。Surfaceを中心とするUI、ナレッジグラフによる継続的な知識蓄積、ローカルファーストなデータ管理、ACPによるマルチエージェント協調、そして拡張可能なアプリケーションモデルを組み合わせることで、「AIと会話する環境」から「AIと仕事をする環境」への転換を具体的な形として示したことが、Rowboat最大の画期である。

Rowboatの未来を妄想する ― AIワークスペースはどこまで進化するのか

Rowboatは現在でも十分に先進的なAIワークスペースである。しかし、その設計思想をさらに発展させると、単なる「AI搭載アプリ」を超えた新しいコンピューティング環境へ進化する可能性がある。以下は現在の技術動向を踏まえた未来像であり、一部は実現可能性が高く、一部は将来の構想としての考察である。

1. SurfaceがOSそのものになる

現在は

  • メール

  • ブラウザ

  • ノート

  • コーディング

などが独立したSurfaceとして存在している。

将来的には、

  • ファイル管理

  • カレンダー

  • ターミナル

  • 表計算

  • CAD

  • 動画編集

までSurface化されるかもしれない。

すると、

「WindowsでRowboatを動かす」

のではなく、

「Rowboatが仕事環境そのものになる」

という逆転現象が起きる。

AIはOSの上で動くソフトではなく、OS全体を統合する存在へ変わっていく。

2. ナレッジグラフが「第二の脳」になる

現在のナレッジグラフは、

「知識を蓄積する」

ことが主目的である。

しかし数年後には、

  • 判断理由

  • 思考パターン

  • よく使う資料

  • 人間関係

  • 過去の設計思想

まで結び付けられる可能性がある。

例えば、

「去年この設計を却下した理由は？」

と聞けば、

会議記録

↓

設計書

↓

メール

↓

コードレビュー

まで遡って説明してくれる。

知識ではなく、

経験

が保存されるようになる。

3. AIが仕事を予測する

現在は

「依頼するとAIが動く」

未来は

「依頼する前に準備している」

かもしれない。

例えば、

朝PCを開くと、

  • 今日の重要メール

  • 昨日の議論の続き

  • 今週締切のタスク

  • レビュー待ちのPR

が優先順位付きで整理されている。

さらに、

「午後の会議ではこの資料が必要になりそうです。」

と先回りして準備してくれる。

チャットAIから、

業務コンシェルジュ

への進化である。

4. エージェントが専門職化する

現在のエージェントは、

万能型が多い。

しかし将来は、

  • 法務担当

  • 経理担当

  • UXデザイナー

  • テスト担当

  • セキュリティ監査担当

  • 技術ライター

など、

専門職エージェントが共存するようになるだろう。

Rowboatは、

その管理者になる。

一つの質問に対して、

複数の専門家AIが議論し、

最後に人間へ提案する。

まるで社内会議が自動で開かれるような世界である。

5. 「会社の知能」が生まれる

現在は個人向けの記憶が中心である。

しかしチーム利用が進めば、

会社全体の知識が一つのグラフへ集約される。

すると、

退職しても、

経験が消えない。

新人は、

十年前の設計議論まで検索できる。

つまり、

企業の知識資産が、

文章ではなく

「理解可能なネットワーク」

として残る。

これは従来の社内Wikiよりはるかに価値が高い。

6. 人とAIの境界が曖昧になる

将来的には、

あるタスクが

人間

なのか

AI

なのか

利用者は意識しなくなる。

例えば、

「営業資料を作る」

という依頼に対して、

  • 市場調査

  • 過去案件検索

  • 売上分析

  • デザイン

  • スライド作成

を複数エージェントが分担し、

人間は最後の確認だけ行う。

仕事は

「自分でやる」

から

「AIチームを率いる」

へ変わる。

7. 個人専用AI企業が生まれる

一人の利用者が、

十人、

百人、

あるいは千人規模のAIエージェントを持つ時代も考えられる。

その全員が、

同じナレッジグラフを共有する。

利用者は、

「会社を経営する」

のではなく、

「AI組織を経営する」

ことになる。

Rowboatは、

その本社ビルのような存在になるかもしれない。

8. ローカルファーストが新しい標準になる

現在はクラウドAIが主流である。

しかし、

個人情報

知的財産

研究データ

ソースコード

などは、

今後ますますローカル保存が求められるだろう。

AIはクラウドで推論する場合もあるが、

知識そのものは利用者が所有する。

その意味で、

「ローカルファースト」は単なる保存方式ではなく、

AI時代のデータ主権を支える考え方として重要性を増していく可能性がある。

9. Surface同士が自律的に連携する

現在は人間が

メール

↓

会議

↓

実装

という流れを管理している。

将来的には、

メールSurfaceが要望を検出すると、

会議Surfaceが議題を作り、

ノートSurfaceが仕様書を更新し、

コーディングSurfaceが試作を始める。

人間は途中で確認するだけになる。

Surfaceは独立した画面ではなく、

一つの生きたワークフローとして連携するようになるだろう。

10. AIワークスペースがインターネット以来のUIになるかもしれない

1980年代はGUI、

1990年代はWebブラウザ、

2000年代はスマートフォン、

2020年代はチャットAIが登場した。

その次の段階として、

「AIワークスペース」

が新しいユーザーインターフェースになる可能性がある。

もしそうなれば、

私たちはアプリを探すのではなく、

仕事を始めるだけで、

必要なSurfaceとエージェントが自動的に集まり、

最適な環境が構成される世界を体験することになるだろう。

総括

Rowboatの未来を想像すると、その到達点は単なる「高機能なAIアプリ」ではない。ローカルファーストな知識基盤を中心に、多数の専門エージェント、Surfaceベースの業務環境、自律的なワークフロー、そして人間とAIが共同で意思決定を行う新しいコンピューティング基盤へと発展する可能性がある。

もちろん、こうした未来像がそのまま実現する保証はない。スケーラビリティ、セキュリティ、プライバシー、ユーザー体験、標準化など、多くの課題が残されている。しかし、もし「チャットの次」に来るものがあるとすれば、それはAIが仕事の文脈そのものに溶け込み、人間と協調して価値を生み出すワークスペースである可能性は十分に考えられる。Rowboatは、その方向性を具体的な形で示す先駆的な試みの一つとして注目される。

Rowboat・OpenClaw・HermesAgentの比較

この3つは一見似ていますが、目指しているものはかなり異なります。

項目RowboatOpenClawHermesAgent
基本思想AIワークスペースローカルAI OSエージェント実行基盤
中心概念SurfaceComputer UseAgent
主用途日常業務PC操作自動化タスク自律実行
UI専用ワークスペースデスクトップ操作最小限
ナレッジグラフ◎△△
ローカルファースト◎◎◎
マルチエージェントACP将来的に対応◎
コーディング◎○◎
一般業務◎○△
OSS◎◎◎

Rowboat

キーワードは

Workspace

です。

仕事そのものを一つの空間へ集約します。

例えば

  • メール

  • 会議

  • ブラウザ

  • Markdown

  • コーディング

これらがKnowledge Graphを共有します。

つまり

Workspace
    │
 ┌──┴──────┐
 │Knowledge│
 └──┬──────┘
    │
 Mail
 Notes
 Browser
 Coding

AIは仕事の流れを理解します。

OpenClaw

OpenClawは発想が違います。

キーワードは

Computer Use

です。

AIは

  • マウス

  • キーボード

  • ブラウザ

  • アプリ

を操作します。

つまり

AI
 ↓
Computer
 ↓
GUI

になります。

これはClaude Computer UseやOpenAI Computer Use系統のOSS実装と言えます。

得意なのは

  • ソフト操作

  • Web操作

  • GUI自動化

  • RPA

です。

つまり

「PCを使うAI」

です。

HermesAgent

HermesAgentはさらに違います。

キーワードは

Agent Runtime

です。

仕事ではなく

エージェント自身

が中心です。

例えば

Planner

Researcher

Coder

Reviewer

のような複数Agentを管理します。

つまり

Task

↓

Planner

↓

Worker

↓

Reviewer

という構造です。

Agentのライフサイクルを管理することが目的になります。

アーキテクチャ比較

Rowboat

Human

↓

Workspace

↓

Knowledge Graph

↓

Agent

人間中心です。

OpenClaw

Human

↓

Agent

↓

Computer

PC中心です。

HermesAgent

Task

↓

Agent Swarm

↓

Result

Agent中心です。

永続記憶

Rowboatが最も特徴的です。

仕事をすると

Meeting

↓

Knowledge Graph

↓

Mail

↓

Notes

↓

Code

すべて繋がります。

OpenClawは

操作履歴

HermesAgentは

タスク状態

が中心になります。

利用シーン

Rowboat

向いているのは

  • 個人開発

  • 研究

  • スタートアップ

  • ドキュメント作成

  • ナレッジ管理

です。

OpenClaw

向いているのは

  • GUI自動化

  • Web操作

  • 定型業務

  • RPA

  • ブラウザ操作

です。

HermesAgent

向いているのは

  • 長時間タスク

  • AIチーム

  • 並列実行

  • 自律エージェント

  • ソフトウェア開発

になります。

将来像

実は、この3つは競合というより補完関係になり得ます。

                Human
                  │
              Rowboat
      （Workspace・記憶）
                  │
      ┌──────────┴──────────┐
      │                     │
 HermesAgent          OpenClaw
（Agent群管理）      （PC操作）
      │                     │
      └──────────┬──────────┘
                 │
            Local LLM

例えば、

  • Rowboatがメールや会議からタスクを抽出してナレッジグラフを更新する。

  • HermesAgentがそのタスクを複数の専門エージェントへ分配し、調査・実装・レビューを進める。

  • OpenClawが実際にブラウザやIDE、社内ツールを操作して作業を実行する。

という役割分担が考えられます。

総括

3つは「AIエージェント」の異なるレイヤーを担っています。

  • Rowboatは**仕事の文脈（Workspace）**を管理する層であり、Surfaceとナレッジグラフを中心に人間の業務を支援します。

  • OpenClawは**コンピューター操作（Computer Use）**を担う層であり、GUIやWebアプリを人間の代わりに操作します。

  • HermesAgentは**エージェントの計画・実行・協調（Agent Runtime）**を担う層であり、複数のAIエージェントをオーケストレーションします。

長期的には、これらは排他的な選択肢ではなく、Rowboatが人間とのインターフェース、HermesAgentが知的作業の司令塔、OpenClawが実世界のコンピューター操作を担当するという形で連携することで、より完成度の高いローカルファーストAIワークスペースが実現する可能性があります。

文献マップ（本スレッドで要約された論文・技術レポート・研究・技術発表の統合）

本スレッドで扱われた内容を俯瞰すると、一見すると

  • Gemma 4

  • GLM-5.2

  • Rowboat

  • Muse Image

  • Jacobian Lens

  • ローカルAI

  • エージェント

などバラバラな話題に見えます。

しかし方法論（Methodology）で分類すると、現在のAI研究は5つの主要な思想学派へ収束しています。

文献マップ

思想学派中心となる方法論本スレッドの代表文献・事例主な問い代表的キーワード
① Agentic AI学派Planning・Tool Use・Memory・WorkflowRowboat、Muse Image、Codex Routing、Theo Browne議論AIは「対話」ではなく「仕事」を行うべきかAgent、Planner、ACP、Workflow、Memory
② Foundation Model Architecture学派Transformer設計・MoE・Dense・Multimodal・Long ContextGemma 4、GLM-5.2、Gemma Audioより良いLLMアーキテクチャとは何かDense、MoE、Native Multimodal、Long Context
③ Mechanistic Interpretability学派Jacobian Lens・CKA・Feature解析・Circuit解析J-Lens Geometry解析、Anthropic Jacobian LensLLM内部では何が起きているのかCKA、Jacobian Lens、Neuronpedia、Feature
④ AI Systems / Infrastructure学派推論最適化・AIチップ・クラウド・オンプレ・GPUZhipu AI ASIC、Theo Browne、GLM推論需要AIをいかに安く大量に動かすかInference、ASIC、GPU、Datacenter、Power
⑤ Open AI Ecosystem学派Open Weights・OSS・Local First・Composable AIGemma、Rowboat、OpenClaw、HermesAgentAIを誰が所有し、どこで実行するべきかOpen Weight、Local First、OSS、Composable

思想学派同士の関係

                    AI
                     │
     ┌───────────────┼────────────────┐
     │               │                │
Architecture   Agent Systems   Interpretability
     │               │                │
Gemma           Rowboat        J-Lens
GLM             Muse           Anthropic
Dense           Codex          CKA
MoE             Memory         Circuits
     │               │                │
     └───────────────┼────────────────┘
                     │
              Infrastructure
                     │
           GPU・ASIC・Datacenter
                     │
             Open Ecosystem

各学派の方法論

① Agentic AI学派

方法論内容
Planning実行前に計画する
Memory永続メモリを持つ
Tool Useブラウザ・IDE・CLI利用
Workflow業務全体を自動化
Reflection自己修正

代表例

  • Rowboat

  • Muse Image

  • Codex Routing

  • OpenClaw

② Foundation Model学派

方法論内容
Dense Transformer全層利用
MoE専門家ルーティング
Native Multimodal最初から画像・音声対応
Long Context長文推論
Scalingデータ・計算量最適化

代表例

  • Gemma 4

  • GLM-5.2

③ Mechanistic Interpretability学派

方法論内容
Activation解析Feature観察
Jacobian Lens出力方向解析
CKA幾何比較
Circuit Discovery回路解析
Feature Dictionary概念抽出

代表例

  • J-Lens

  • Anthropic

  • Neuronpedia

④ Infrastructure学派

方法論内容
AI ASIC推論専用チップ
Runtime最適化推論高速化
GPUクラスタ並列推論
DatacenterAI工場
Cost OptimizationTokenコスト削減

代表例

  • Zhipu ASIC

  • Theo Browne

⑤ Open Ecosystem学派

方法論内容
Open Weight重み公開
Local Firstローカル保存
OSSオープンソース
Plugin拡張可能
Community分散開発

代表例

  • Gemma

  • Rowboat

  • OpenClaw

学派間の影響関係

学派強く影響を受ける学派
AgenticFoundation・Infrastructure
FoundationInterpretability
InterpretabilityFoundation
InfrastructureFoundation
Open Ecosystem全学派

分野全体で未解決の3つの矛盾

① 「巨大モデル」vs「効率モデル」の矛盾

巨大化派効率化派
より大きいモデルが必要より賢い推論が重要
GPT・GeminiGemma・GLM・ASIC

矛盾

  • 性能はスケーリングで伸びる

  • コストは指数関数的に増える

未解決問題

性能はモデルサイズで決まるのか、それとも推論システム全体の設計で決まるのか。

② 「クラウド」vs「ローカル」の矛盾

Theo Browne

↓

クラウド中心

Rowboat

↓

ローカルファースト

Zhipu

↓

オンプレASIC

Gemma

↓

ローカル実行

矛盾

最高性能

↓

Cloud

一方

最高のプライバシー

↓

Local

未解決問題

AIはデータセンターへ集約されるのか、それともエッジ・オンプレミス・クラウドへ分散されるのか。

③ 「ブラックボックス」vs「解釈可能性」の矛盾

Gemma

↓

性能重視

J-Lens

↓

理解重視

Anthropic

↓

回路解析

矛盾

高性能

↓

内部は分からない

と

理解できる

↓

まだ十分高性能ではない

未解決問題

LLMは経験的な最適化だけで発展し続けるのか、それとも内部機構の理論的理解が今後の性能向上に不可欠になるのか。

メタ分析：研究潮流の統合

これら5つの思想学派は独立しているわけではなく、「モデル」から「AIシステム」への重心移動という共通方向に収束しています。

2023〜20242025〜2026（本スレッドが示す潮流）
より大きなLLMを作るLLMを組み合わせたエージェントシステムを作る
モデル性能競争システム性能・ワークフロー競争
GPU中心GPU・ASIC・ランタイム・データセンターの協調設計
単一モデルPlanner・Memory・Tool・Generatorから成る複合AI
ベンチマーク中心実運用・コスト・解釈可能性・所有形態まで含めた総合最適化

結論として、本スレッドで扱われた研究群は、AI研究の重心が「より賢い単一モデル」を追求する時代から、「アーキテクチャ・エージェント・インフラ・解釈可能性・オープンエコシステムを統合したAIシステム全体」を設計する時代へ移行していることを示しています。以下は、本スレッドで扱った研究群（Gemma 4、GLM-5.2、J-Lens/CKA、Rowboat、Muse Image、Theo Browne、Zhipu AIなど）を俯瞰し、「論理的には実施されるべきだが、まだ十分に検証されていない研究」を、3か月以内・学生レベルで実施可能という条件で評価したものです。

なお、J-Lens研究自体でも著者らはトークナイザー依存性、モデルサイズ依存性、学習過程でいつJ-spaceが形成されるのか、J-spaceへ情報が入る機構などを未解決課題として挙げています。(トランスフォーマー回路)

ランキング（実現可能性 × 新規性 × 出版可能性）

順位研究テーマ関連研究3か月実現性新規性出版可能性
1TokenizerがJ-Lens CKAへ与える影響の定量評価J-Lens、Gemma、Qwen★★★★★★★★★★★★★★★
2Instruction Tuningはどの層を書き換えるのかGemma Base vs Instruct★★★★★★★★★☆★★★★★
3Agent Routingと推論コストの最適化Rowboat・Codex・Muse★★★★★★★★★☆★★★★☆
4Dense vs MoEのLayer Geometry比較Gemma・GLM★★★★☆★★★★★★★★★☆
5Local AIとCloud AIの経済モデル実測Theo Browne★★★★★★★★☆☆★★★★☆
6推論ASICがLLMアーキテクチャへ与える影響Zhipu★★☆☆☆★★★★★★★★★☆

① Tokenizer依存性（最優先）

なぜ重要か

J-Lens研究でも

「Tokenizerの違いがCKAへどれだけ影響するか」

は最大級の留保事項です。(トランスフォーマー回路)

しかし、

まだ十分な比較実験は公開されていません。

実験

対象

  • Gemma

  • Qwen

  • Llama

  • GLM

共通文章

↓

共通語彙

↓

CKA

↓

Tokenizer差を補正

↓

再比較

成果

例えば

Raw CKA

↓

Vocabulary Alignment

↓

Corrected CKA

を比較できます。

非常に出版可能性が高いテーマです。

② Instruction Tuningはどこを書き換えるのか

Gemmaで

Base

↓

Instruct

が

初期Layerから違う

という観測がありました。

しかし

これは

まだ十分検証されていません。

実験

Base

↓

Instruction

↓

RLHF

を

J-Lens

Activation

CKA

で比較します。

論文タイトル例

Instruction Tuning Rewrites Earlier Layers Than Previously Assumed

③ Agent Routing最適化

Rowboat

Codex

Muse

Theo Browne

すべてに共通します。

しかし

誰も

Agent Routing

を体系比較していません。

例えば

Small Model

↓

Planner

↓

Large Model

↓

Executor

と

Large Modelだけ

を比較。

評価

  • Token

  • Cost

  • Time

  • Accuracy

非常に実装しやすいです。

④ Dense vs MoE Geometry

Gemma

↓

Dense

GLM

↓

MoE

Qwen

↓

MoE

で

Layer Geometry

を比較します。

例えば

Dense

Workspace

Workspace

Workspace

と

MoE

Expert

Expert

Workspace

なのか。

これはまだ誰も体系化していません。

⑤ Local vs Cloud

Theo Browneの議論は

かなり感覚的です。

実際には

実測比較が不足しています。

例えば

同じAgentを

RTX5090

↓

Mac

↓

Cloud

で比較。

評価

  • 電力

  • レイテンシ

  • Token/$

  • Token/W

論文として成立します。

⑥ ASICとモデル設計

Zhipu

Google

Meta

OpenAI

すべて

ASICへ向かっています。

しかし

まだ

ASIC

↓

Transformer設計変更

の研究は少ないです。

学生にはやや重いテーマです。

研究全体から見える最大のギャップ

Gap 1

現在

Architecture

と

Interpretability

が分離しています。

つまり

Gemma

↓

性能

と

J-Lens

↓

理解

が

つながっていません。

Gap 2

Agent研究は

ほぼ

UX

です。

しかし

最適Agent構造

を比較する論文は

ほぼありません。

例えば

Planner

Memory

Executor

Critic

の

最適構成

は未知です。

Gap 3

Open Model

と

Hardware

が

独立しています。

本来

ASIC

↓

Architecture

↓

Inference

↓

Cost

を

同時最適化すべきです。

私なら最優先で取り組むテーマ

もし3か月・学生1〜2人・GPU 1〜2台という条件なら、最も出版可能性が高いのは次のテーマです。

項目評価
新規性★★★★★
実装難易度★★☆☆☆
GPU要求★★☆☆☆
再現性★★★★★
arXiv適性★★★★★
ワークショップ採択可能性★★★★★

テーマ：「Tokenizer Alignment Changes Cross-Model J-Lens Geometry」

理由は明確です。J-Lens研究では、トークナイザー依存性が比較結果へどの程度影響するかが未解決課題として残されている一方、その影響を体系的・定量的に評価した研究はまだ十分に示されていません。(トランスフォーマー回路)

このテーマは、既存のオープンモデル（Gemma、Llama、Qwen、GLMなど）と公開済みのJ-Lens・CKAツールを活用できるため、新規モデルの学習を必要とせず、比較実験と統計解析を中心に進められます。そのため、限られた計算資源でも実施可能でありながら、Mechanistic Interpretability分野への貢献度が高いという点で、本スレッド全体の中では最も有望な研究ギャップと言えます。以下は、**「Tokenizer Alignment Changes Cross-Model J-Lens Geometry」**を3か月で完成させることを想定した研究工程表です。J-Lens研究では、共通プローブ（4,096トークン列）を用いたCKA比較や、トークナイザー依存性が未解決課題であることが示されており、このギャップは現実的な研究対象です。(Eliebak)

研究工程表（12週間）

期間フェーズ作業内容成果物
Week 1文献調査J-Lens、CKA、TransformerLens、Representational Alignmentの整理関連研究レビュー
Week 2環境構築Hugging Face環境、J-Lens Explorer確認、Gemma・Llama・Qwen・GLM準備実験環境
Week 3データセット作成共通文章・Wikipedia・Code・数学問題などを準備評価データ
Week 4Tokenizer解析各モデルのToken分割を比較し、共通語彙・差分語彙を抽出Tokenizer比較表
Week 5ベースライン元論文と同様のCKAを再現ベースライン結果
Week 6Alignment法①Sentence単位・Word単位でAlignmentを導入CKA比較
Week 7Alignment法②BPE統合・SentencePiece統合など複数方式を評価Alignment比較
Week 8統計解析CKA変化量・有意差検定・クラスタ解析統計結果
Week 9可視化Heatmap・UMAP・Layer対応図作成図版
Week 10考察Tokenizer依存性・モデル依存性を議論Discussion
Week 11論文執筆Method・Experiment・Conclusion作成初稿
Week 12リバイス共同研究者レビュー・再実験・投稿準備arXiv版

実験パイプライン

対象モデル
    │
    ▼
Gemma・Llama・Qwen・GLM
    │
    ▼
Tokenizer解析
    │
    ▼
共通プローブ生成
    │
    ▼
J-Lens抽出
    │
    ▼
CKA計算
    │
    ▼
Alignment補正
    │
    ▼
再CKA
    │
    ▼
統計解析
    │
    ▼
可視化

必要な実験

実験目的難易度
ベースラインCKA再現論文再現★☆☆☆☆
Tokenizer比較差異定量化★★☆☆☆
Alignment補正本研究の中心★★★☆☆
Layer Matching深さ対応検証★★★☆☆
Family比較Gemma・Qwen・Llama比較★★★☆☆
Instruct/Base比較微調整影響★★☆☆☆

必要なソフトウェア

  • Python 3.11+

  • PyTorch

  • Hugging Face Transformers

  • NumPy

  • SciPy

  • scikit-learn

  • Matplotlib

  • TransformerLens（必要に応じて）

  • J-Lens関連コード・Explorer（参考実装）(トランスフォーマー回路)

GPU要件

規模推奨環境
Gemma 2BRTX 4090 / A100 40GB
Gemma 4BRTX 5090相当以上
7BクラスA100/H100または分散環境
30Bクラス必要なら既存J-Lens重み・公開結果を活用し、自前計算は限定

ポイント: 本研究は新規学習ではなく解析研究なので、大規模学習用GPUは不要です。公開モデルと公開済みJ-Lens成果物を活用することで計算資源を抑えられます。(Eliebak)

想定される図表

図内容
Figure 1研究全体フロー
Figure 2Tokenizer比較例
Figure 3元のCKA Heatmap
Figure 4Alignment後CKA
Figure 5Layer対応図
Figure 6モデルファミリー比較
Table 1モデル一覧
Table 2Tokenizer統計
Table 3CKA改善量
Table 4Ablation Study

想定論文構成

  1. Introduction

  2. Related Work

  3. Background（J-Lens・CKA・Tokenizer）

  4. Proposed Alignment Method

  5. Experimental Setup

  6. Results

  7. Ablation Study

  8. Discussion

  9. Limitations

  10. Conclusion

投稿候補

投稿先適合度
arXiv★★★★★
NeurIPS Workshop（Mechanistic Interpretability系）★★★★★
ICLR Workshop（Representational Alignment系）★★★★★ (ICLR)
ICML Workshop★★★★☆
ACL Findings（解析・表現学習寄りの場合）★★★★☆

成功条件（Go / No-Go）

マイルストーン判定基準
Week 3ベースライン実験が再現できる
Week 6少なくとも1種類のAlignment法が実装できる
Week 8Alignment後にCKAまたは深度対応指標が統計的に有意に改善する
Week 10「Tokenizerの影響を除くと、モデル間の表現幾何がどの程度変わるか」という明確な結論を提示できる
Week 12arXiv投稿可能な完成原稿と再現コードを準備できる

この計画であれば、3か月・学生1〜2名・既存オープンモデルを利用という条件でも十分実行可能であり、Mechanistic InterpretabilityおよびRepresentational Alignment分野への実質的な貢献が期待できます。

コメント

コメントを投稿

このブログの人気の投稿

#INVIDIOUSを用いて広告なしにyoutubeをみる方法　#士17 #2018INVIDIOUSとOmarRoth_令和IT史ざっくり解説

https://www.youtube.com/watch?v=XXXXXXXXXX ↑のURL↓のように入れ替えると広告なしにyoutubeをみれる。 https://yewtu.be/watch?v=XXXXXXXXXX Invidious は、 YouTubeに代わる無料のオープンソースのフロントエンドです。 Dockerコンテナとして、またはGitHubマスター ブランチから利用できます。公式 YouTube Web サイトの軽量で「プライバシーを尊重した」代替サイトとして使用することを目的としています。多くのプライバシー保護リダイレクト ソフトウェアおよび YouTube クライアントは Invidious インスタンスを使用します。 Invidious は、YouTubeの動画を広告なしで視聴できる、プライバシーに配慮したオープンソースのサービスです。Googleのトラッキングを避けつつ、YouTubeコンテンツを楽しみたい方におすすめです。 Invidiousのメリット 広告なし: YouTubeの煩わしい広告をスキップできます。 プライバシー保護: Googleのデータ収集を抑え、プライバシーを重視した視聴が可能です。 オープンソース: 誰でも自由に利用・開発できるオープンソースソフトウェアです。 多様なインスタンス: 世界中に多くのInvidiousインスタンスが存在し、それぞれ異なる特徴や機能を提供しています。 Invidiousの使い方 Invidiousインスタンスを探す: 検索エンジン: "invidious instance"などで検索すると、多くのインスタンスが見つかります。 リスト: いくつかのInvidiousインスタンスをまとめたリストサイトも存在します。 YouTubeの動画URLをInvidiousの検索バーに入力: 視聴したいYouTube動画のURLをコピーし、選んだInvidiousインスタンスの検索バーに貼り付けます。 動画を再生: 検索結果から目的の動画を選択し、再生ボタンを押せば広告なしで視聴できます。 Invidiousの使い方 Invidiousは、YouTube動画を広告なしで視聴できる便利なサービスです。 基本的な使い方 Invidio...
MORE »

複数のRSSFeedを一つのURLにまとめる・統合する方法 #士30 #1999RSS_RDF・SiteSummary_平成IT史ざっくり解説

イメージ
  お気に入りのすべてのブログやニュースサイトからの複数のRSSフィードを追跡するのは簡単ではありません。 　この問題が発生した場合は、RSSアグリゲーターを使用して、複数のRSSフィードを1つのフィードに結合します。 　 RSSアグリゲーターは、複数のブログやサイトを持つコンテンツプロデューサーであり、読者やフォロワーへのサービスとしてRSSフィードを1つのフィードに結合したい場合にも役立ちます。 独自のパーソナライズされたニュースフィードを作成するために使用できる4つの無料のアグリゲーターツールを見てみましょう。 １http://www.rssmix.com http://www.rssmix.com 複数のフィードを1つのフィードに簡単に組み合わせることができます。特定の各フィードの完全なURLアドレスを 各行に1つずつ入力し 、[作成]を押します。最大100のフィードを、少なくとも2つ以上の固有のソースと組み合わせます。 RSS Mixは、集約されたフィードのアドレスを生成します。このアドレスを使用して、読者がすべてを1か所で最新の状態に保つことができます。 RSSMIXが死んでる？  2021/10.28あたりから不通 ２、 http://rssmixer.com/ http://rssmixer.com/ RSS Mixerはやや制限されたツールですが、フィードを混合するための超高速でシンプルなソリューションが必要な場合は、試してみる価値があります。 無料版では、1日1回更新される1つの混合RSSフィードに最大3つのフィードを組み合わせることができます。 より多くの機能が必要な場合は、1時間ごとに更新される10〜30の混合フィードを提供する有料プランにアップグレードしてください。 このツールは使いやすいです。メインフィードに名前を付け、説明を入力し、含めるURLを入力するだけです。 ３、 http://feed.informer.com/ http://feed.informer.com/ Feed Informerは、いくつかの異なるRSSフィード結合サービスを提供します。いくつかのフィードをすばやく統合したい場合は、 アカウントにサインアップ してから、FeedInformerのテンプレートを使用して結合するRSSフィードを入力しま...
MORE »

🚀VoidからCortexIDEへ！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化　#五09 #2024VoidオープンソースAIコーディングIDE_令和IT史ざっくり解説

🚀Void登場！Cursorに代わるオープンソースAIコーディングIDEの全貌と未来とは？#AI開発 #OSS #プログラミング効率化 AIコーディングツールの新星「Void」を徹底解剖！Cursorとの違い、VSCodeフォークの是非、そして開発の未来をDopingConsommeが熱く語ります🔥 序文 どーも！売れっ子ブロガーのDopingConsommeです☕ dopingconsomme.blogspot.com とTwitterアカウント @Doping_Consomme を運営しています。バズるブログ記事ならお任せあれ！ さて、今回筆者が筆を執ったのは、巷で話題沸騰中のAIコーディングIDE「 Void 」について語り尽くしたいと思ったからです。Cursorの代替として彗星の如く現れたこのツール、オープンソースであるという点も相まって、開発者界隈では既に大きな注目を集めていますよね？ この記事では、Voidが一体どんなツールなのか、既存のツールと何が違うのか、そして私たちのコーディングライフをどう変えてくれる可能性があるのか、といった点を深掘りしていきます。読者の皆さんには、単なる機能紹介に留まらず、Voidを取り巻く議論や、AIと共存する未来の開発スタイルについて、多角的な視点から考えていただくきっかけになれば嬉しいです。それでは、熱いコーヒーでも片手に、じっくりお付き合いください！😉 はじめに この記事では、オープンソースのAIコーディングIDEである「 Void 」について、その特徴、機能、そして開発者コミュニティからの様々な意見を交えながら詳細に解説していきます。Voidは、人気のAIコーディングツール「Cursor」の代替を目指して開発されており、VSCodeをベースにしたフル機能のIDE（統合開発環境）です。AIエージェントの活用、ローカルでのモデル実行サポート、データのプライバシー重視といった点が主な特徴として挙げられます。 本記事を通じて、Voidがどのようなツールであり、現在のAIコーディングツール市場においてどのような位置づけにあるのか、そして将来的にどのような可能性を秘めているのかを明らかにしていきます。また、類似ツールとの比較や、開発におけるメリット・デメリット、さらにはコミュニティでの議論なども幅広...
MORE »