多くの AI research tool の弱点は、研究の流れを chat box に押し込んでしまうことだ。model は論文を説明できるし、script も書けるし、Python の断片も出せる。ただ実際に実験を進めると、必要になるのは別のものだ。persistent な Python/R runtime、再利用できる data files、remote machines、追跡できる artifacts、database retrieval tools、そして失敗しても復旧できる workspace。

今日紹介する xuzhougeng/wisp-science が面白いのは、この点にある。単なる「科学版 ChatGPT」ではなく、AI agent、desktop workspace、Python/R REPL、MCP bioinformatics tools、remote compute contexts を一つの local-first workbench にまとめようとしている。

2026-07-18 時点で GitHub repository page、README、release/tag page、公開 git history、LICENSE、local git clone から確認できる公開情報では、xuzhougeng/wisp-science は 173 stars、24 forks。GitHub language breakdown は HTML 78.9%、Rust 10.0%、Python 6.0%、JavaScript 3.3%、TypeScript 1.0%、CSS 0.8%。README では core は Rust、Tauri v2、Leptos で構築されていると説明されている。license は Apache-2.0。GitHub embedded data の repository creation time は 2026-07-01 07:57:11 UTC。公開 git history の initial commit は 17c5369、commit time は 2026-07-01 22:08:09 +08:00。default branch main の最新 commit は 03bd27f、commit time は 2026-07-18 17:41:49 +08:00、message は Release v0.16.2。アクセスできる GitHub release/tag page では v0.16.2 が 2026-07-18 09:42 UTC に hoptop によって tag されている。

プロジェクト概要

項目内容
リポジトリxuzhougeng/wisp-science
位置づけlocal-first desktop AI research workbench
Stars173
Forks24
主言語GitHub 統計では HTML。core は Rust / Tauri v2 / Leptos / Python を含む
ライセンスApache-2.0
GitHub 作成時刻2026-07-01 07:57:11 UTC
公開 Git history 起点2026-07-01 22:08:09 +08:00、initial commit 17c5369
最新 main commit03bd27f、2026-07-18 17:41:49 +08:00
最新のアクセス可能な release/tagv0.16.2、2026-07-18 09:42 UTC
キーワードlocal-first、AI for science、Python/R runtime、MCP、bioinformatics、SSH/WSL compute

研究は一回の Q&A では終わらない

Wisp Science の README は、最初にこの project を “local-first desktop AI research assistant and scientific computing workbench” と定義している。この中でいちばん重要なのは AI ではなく workbench だと思う。

research や data analysis の実作業は、一度質問して終わりになることが少ない。まず Python を走らせ、column name が違うことに気づく。次に paper を調べ、filter 条件を変える。途中の chart を残し、翌日に続きをやる。普通の chat interface では、こうした state が context window に押し込まれ、時間が経つほど細部が失われる。

Wisp は work state を local project に残す方向を取っている。README には SQLite store、project/session/artifact、persistent Python/R runtime、file previews、saved conversations などが出てくる。temporary prompt panel というより、agent loop を持った research IDE に近い。

Python/R runtime が中核になる

scientific computing で重要なのは、model が code を書けるかだけではない。既存の runtime を安定して操作できるかが重要だ。Wisp Science の wisp-runtime は、project / execution context / language ごとに manager-owned process を持ち、Python と R の namespace を tool calls と sessions の間で保持する。

これはかなり現実的な問題を解いている。大きな data object、model result、plot の中間状態は、毎 turn 読み直すには重い。agent が毎回ゼロから script を走らせると時間もかかるし、「いま environment に何があるのか」が見えにくくなる。

README では runtime object inspector も説明されている。object name、type、shape、size、bounded metadata を read-only に確認できる。DataFrame 全体を chat に貼り付けるより、この方が安全で、notebook を調べる研究者の普段の動きにも近い。

remote compute は明示的に許可する

もう一つ注目したいのは、Wisp Science が SSH/WSL/GPU を雑な shell として扱っていないことだ。README では local compute は常に使える一方、remote server は current conversation で明示的に選択する必要がある。environment probing と capability record は Settings -> Environments が管理する。

AI research tool ではこの境界が大事になる。lab の remote machine には queue、GPU、data permission、shared environment がある。agent が command を実行できるなら、自分がどの machine にいて、どの interpreter を使い、どの directory にアクセスでき、失敗後にどう戻るかを知らなければならない。

Wisp は remote compute を conversation-scoped selection にしており、global に開きっぱなしにはしない。この設計はよい。成熟した HPC scheduler を置き換えるものではないとしても、「remote execution」を危険な汎用 terminal に単純化していない。

MCP は飾りではなく科研ツールの入口

repository には mcp-servers/ と bundled bio-tools がある。README では WISP_MCP_PKG=mcp_pubmed で対応する MCP server を起動し、agent が PubMed のような tool を呼べると説明されている。project description でも約 80 個の bioinformatics / computational biology database clients に触れている。

これは、model の training memory だけで「この gene にはどんな paper があるか」を答えさせるより実用的だ。research agent はできるだけ tool で evidence を取り、その evidence に基づいて説明を書くべきだ。ここでの MCP は流行語ではなく、database query、literature retrieval、local analysis を接続する interface layer になっている。

もちろん maintenance cost はある。MCP server の dependencies、外部 database の API、network、quota はすべて結果に影響する。Wisp はそれらを workbench に入れようとしているが、user は各 tool の source と limitation を理解しておく必要がある。

Gumi で観察する理由

Wisp Science はまだ若い。GitHub creation time は 2026-07-01 だが、commit と release の cadence は速い。短期間で 173 stars まで伸びており、AI for science に関心のある小さな層に見つかり始めている。ただし、まだ mainstream project ではない。

scope も具体的だ。ぼんやりした “AI desktop app” ではなく、scientific computing、Python/R runtime、bioinformatics MCP、remote compute、artifact preview、local-first projects を中心にしている。この組み合わせは、普通の agent wrapper より engineering density が高い。

developer として見るなら、UI screenshot よりも capability boundary の切り方が面白い。agent loop、context compaction、tools、runtime、MCP client、store、skills、ACP adapter が crate/module に分かれている。これは「agent が長く働くとき、state をどこに置くのか」という問題に正面から向き合っている証拠だ。

注意したいところ

第一に、project はまだ MVP vertical slice だ。README も agent loop、streaming providers、tools、Python/R REPL、SQLite store、MCP client、Leptos UI は build and run できると書く一方で、Roadmap には deferred items が残っている。正式な研究 workflow に入れる前に、non-critical project で試すべきだ。

第二に、install と build のハードルは低くない。Rust、Tauri、Trunk、uv、optional R、Windows WebView2、platform ごとの installer signing など、普通の SaaS の click-to-use とは違う。local toolchain を触る前提の人に向いている。

第三に、MCP と外部 scientific databases は魔法ではない。database coverage、query quality、API changes、network environment、credential management は agent output に影響する。research の場では、どんな conclusion も original evidence に戻って確認する必要がある。

第四に、GitHub の language statistics は HTML が大きく見える。docs や frontend build artifacts の影響がありそうで、language badge だけを見ると技術スタックを誤読しやすい。README と directory structure を見ると、core workbench は Rust/Tauri/Leptos、Python/R runtime、MCP components を中心にしている。

まとめ

Wisp Science が面白いのは、AI research tool を「chat で script を生成するもの」から「state を持つ local workbench」へ少し進めているところだ。runtime、remote compute、artifact、MCP data sources、skills catalog、session recovery という、実験の現場で実際に困る部分を扱っている。

model に paper を説明させるだけなら、少し重く見えるかもしれない。しかし AI agent が scientific computing workflow にどう入っていくかを観察したいなら、xuzhougeng/wisp-science は watch list に入れる価値がある。AI for science の鍵は、より強い model だけではなく、evidence、state、compute context を保てる作業環境に model を置くことだ。