ローカルLLM時代を見据えて、MelunaiというAIワークスペースを作った話
この記事は、ローカルLLMで動くAIワークスペース「Melunai」を作った経緯と、その途中で考えたことの記録です。
Melunaiは、ローカルLLMで動くAIワークスペースです。
ローカルAIチャット、Markdown編集、資料参照などを、クラウドではなくローカルPC上で扱うことを目指しています。
先に正直に書いておくと、Melunaiは完成品ではありません。バージョンで言えば v0.1.0-alpha、気持ちとしては v0.000 くらいの初期実験です。
それでも公開したのは、完成したからではなく、「ローカルAI時代に、どんなアプリが必要になるのか」という問いそのものに価値があると思ったからです。
将来、そこそこ強いAIが普通の個人PCで動くようになるんじゃないのか？
Melunaiは、この問いに対する実験です。
GitHub:
https://github.com/darudaruma/Melunai
なぜMelunaiを作ろうと思ったのか
Melunaiを作ろうと思った理由は、大きく分けて2つあります。
1. 技術は最終的に小さくなっていくと考えている
昔のパソコンは机を占有するほど大きかったのに、今ではノートPCとして片手で持ち運べるようになりました。携帯電話も、分厚く大きなものからスマートフォンへ進化しています。
カメラ・音楽プレイヤー・GPS・ストレージといった専用機器も、今ではスマートフォン1台にまとまっています。
もちろん、すべての技術が同じ進化をするわけではありません。ただ僕は、AIも最終的には同じように「小さく・効率的に・個人の手元で動く方向」へ進むのではないかと考えています。
今の最先端AIは巨大なデータセンターや大量のGPUを必要とします。しかし、量子化・蒸留・推論最適化などはどんどん進んでおり、以前より弱いPCでもローカルLLMを動かせるようになってきました。
将来的には、今よりずっと高性能なAIが、普通の個人PC上で動くようになる可能性があると思っています。
2. open-weightモデルやOSSの流れが強くなっている
現在、OpenAIやAnthropicのような企業はAPI中心のビジネスをしています。一方で、中国系モデルを中心に、DeepSeek・Qwen・Kimiなど、比較的オープンな形でモデルを公開する流れも強くなっています。
もちろん、すべてが完全なオープンソースというわけではありません。ただ少なくとも、「個人でも動かせるモデルが広く配布される流れ」は確実に強くなっているように見えます。
もし将来、強力なAIモデルがローカルPCで普通に動き、それが広く公開されるようになったら——AIアプリの前提そのものが変わるかもしれません。
今はAPI経由でクラウドAIを使うアプリが主流です。しかし将来的には、「ローカルで完結するAIアプリ」がもっと増える可能性がある。
僕はそこに興味を持ちました。
だからMelunaiは、「今すぐ完成されたものを作る」というより、ローカルAI時代を先取りして試してみるための実験として始まっています。
最初に作ろうとしていたもの
実は、最初から今のようなAIワークスペースを作ろうとしていたわけではありません。
最初に考えていたのは、ローカルLLMで動くClaude CodeのようなAI coding agentでした。
ローカル環境のファイルを読み取り、コードを編集し、作業を進めていくようなものです。
ただ、実際に現在のローカルLLMを触ってみると、かなり厳しい現実がありました。
僕の開発環境は16GBメモリ・Intel Core i5クラスの一般的なPCです。その環境で主に使っていたのが qwen2.5:7b でした。
しかし、7B級モデルではClaude Codeのような高度なcoding agent体験を再現するのはかなり難しかったです。
推論速度も遅く、長い文脈に弱く、複雑な指示を安定して処理するのも難しい。クラウドの最先端モデルと比べると、できることにはかなり差がありました。
そこで、「強いAIに全部任せる」のではなく、「弱いローカルLLMでも成立しやすい体験」を作る方向へ切り替えました。
その結果、現在のような、チャット・Markdown編集・資料参照などを中心にしたAIワークスペースへ変化していきました。
とはいえ、将来的にはローカルLLMもさらに進化していくと考えています。今後どこまで機能を増やしていけるのかは、自分自身かなり楽しみにしています。
現在のMelunaiでできること
現時点のMelunaiで主にできることは以下のとおりです。
- Ollama経由でローカルLLMと会話する
- チャット履歴をローカルに保存する
- Markdown CanvasでMarkdownファイルを編集し、AIに追記・編集を依頼する
- ローカル文書インデックスを作り、資料参照を試す
- MCPサーバー接続を実験的に扱う
重要なのは、「できる」と「実用的に安定してできる」は違うということです。
特に資料参照機能などはまだ実験段階で、ローカルLLMが弱いと回答品質が安定しないことがあります。現時点で一番安定しているのは、ローカルLLMチャットとMarkdown Canvasです。
やはり、アプリ側でどれだけLLMをサポートしようとも、LLM自体が弱ければ限界はすぐに来る、という感触があります。
AIを使って開発した
Melunaiは、Claude CodeとCodexを使って開発しました。
自分自身がアプリのコードを直接書いた部分は、ほとんどありません。というより、自分はデスクトップアプリを作った経験もなければ、TypeScriptも触ったことがありませんでした。
自分がやったのは、思想を出すこと・仕様を決めること・レビューすること・方向転換を指示することです。実装の多くはAIに任せました。
つまりMelunaiは、AIがAIアプリをどこまで作れるのかという実験でもあります。
作業スタイルとしては、CodexとClaude Codeそれぞれに共有ファイルを持たせ、なるべく作業が競合しないようにしながら並列で進めていました。
進捗管理や、次に何をやるべきかの整理は自分側で行い、コードを書く作業をAIに任せる、という形です。
特別なことをしているわけではありません。
AIコーディングについて思ったこと
個人的には、いわゆる「バイブコーディング（笑）」という言葉だけで片付けられる段階では、もうないと感じています。
AIにコードを書かせるのは危険だとか、脆弱なコードを書くとか、ハルシネーションが問題だとか、そういう話は確かにあります。
ただ実際に使ってみると、問題は「AIだから危険」というより、人間側の指示の出し方・マネジメント・ツールの使い方にあることもかなり多いと感じました。
人間同士の開発でも、仕様が曖昧ならプロジェクトは崩れます。逆に、制約条件や優先順位が整理されていれば、実装側はかなり動きやすくなります。
これはAI相手でもかなり近い感覚でした。
もちろん、AIはまだ万能ではありません。しかし、少なくとも「AIだからダメ」という単純な話ではないと思っています。
AIでコーディングする上で重要だと思ったこと
1. まず作らせてみる
正直、自分自身も「どう指示すればAIが一番うまく動くのか」は、まだ完全には分かっていません。
だからこそ、まずは作らせてみて、どんな指示ならうまくいくのかを観察しながら進めるのが大事だと思っています。
最近感じるのは、人間同士にも相性があるように、AIにも相性があるということです。
個人的にはClaudeやGPTはかなり使いやすく感じます。一方で、Geminiは使いにくいです。
2. AI同士でレビューさせる
今回はCodexとClaude Codeを同時に使っていました。
並列で作業させるだけではなく、互いにレビューさせるという使い方もしていました。
CodexにClaude Codeの成果物をレビューさせたり、逆にClaude CodeにCodexの成果物を確認させたり、といった形です。
また、一度作業が終わったあとに、「本当にそれでいいのか確認して」と再チェックをさせることもかなり多かったです。
今後やりたいこと
Melunaiはまだ始まったばかりです。
ローカルLLMでも速く感じるチャット体験
・資料参照の精度改善
・Markdown CanvasとAIの連携強化
・非エンジニアでも使える導線
・MCP連携の安全性向上
・UIの洗練
・インストール手順の簡略化
など、やりたいことはたくさんあります。
その中で一番大事なのは、弱いLLMでも破綻しにくい設計です。
小さいLLMを無理に天才扱いするのではなく、アプリ側が仕事を整理し、必要な情報だけ渡し、失敗しにくい流れを作る。
ここがMelunaiの核心だと思っています。
まとめ
Melunaiは、まだ完成品ではありません。
でも、自分にとってはかなり面白い試みだったと思います。
AIが将来もっと小さく・もっと強くなり、個人PCの中で普通に動くようになるのか。
もしそうなった時、ローカルAIアプリはどうあるべきなのか。そして、AI coding agentはAIアプリそのものをどこまで作れるのか。
Melunaiは、この2つの問いを同時に試すプロジェクトです。
今はまだ荒く、ローカルLLMも弱く、できないことも多いです。それでも、ローカルAIの未来に少しでも興味があれば、ぜひ覗いてみてください。