プログラミング知識ゼロ。バイブコーディングでローカルLLMマスコットを作ったよ

完成したデスクトップマスコットアプリ。Foundry Local経由により、NPU推論でLLMとチャットできる

　突然だが告白しよう。筆者の中学生のころの夢は「ソフトウェア会社を立ち上げる」ことだった。ちょうどWindows 95が発売された1996年の前後、TVで連日Microsoft……もといビル・ゲイツ氏に関するニュースや特番を観て、ソフトウェア会社は面白そうだし、その社長は金持ちでいいな(直球)と思ったからだ。

　しかし、「ソフトウェア会社を立ち上げるなら、ソフトウェアについて勉強して、まずは何かソフト作らなければ」と思い、書店でプログラミングに関する本をいろいろ購入して読んでみたものの、「自分でソフトが作れる」というイメージがまったく湧かなかったのだ。

　それは、頭の中で作りたいソフトの像がないから作れないというわけではない。初心者向けのプログラミング本の中で、関数とかポインタとかスタックとか、いろいろ丁寧に説明されているのだが、「んで、それは俺が夢に描いたソフトとなんか関係あるん？」となってしまうのだ。

　今から思えば、買った本が目的に合わなかったのかもしれないし、そもそも勉強しようとした言語(C言語)が間違いだったのだろう。しかし、本当に右も左も分からない人間にとって、どれを学べばいいのかすら分からないのがプログラミングの世界なのだと思う。まあ、どの業界も同じなのかもしれないが……。

今ならAIがソフトウェアを作ってくれる

　だが近年、ユーザーが作りたいソフトの形を言葉でAIに伝え、AIが実際にプログラミングをする「バイブコーディング」(Vibe Coding: 雰囲気でコーディング)が実用的になってきた。もともとAIがコンピュータやプログラミングの知識と親和性が高いというのは、ある意味当たり前のような気がするのだが、これを使ってソフトを作ってみようと思い立った。

　AIでソフト作れたらソフトウェア会社立ち上げるとか、さすがにその気はまったくないのだが、「誰も作ってくれないけど欲しいソフトがある」のだ。それが気軽にローカルLLMと会話できるデスクトップマスコットである。

　ローカルLLMソフトの代表格と言えば「LM Studio」が挙げられよう。しかし筆者がやりたいのはちょっとした質問、雑談レベルの会話で、そのためにLM Studioのような大層なUIを使うのはちょっと気が引ける。そのためにウィンドウの切り替えをしなければならないのが明白だからだ。デスクトップマスコットなら、作業中のウィンドウを開いたまま会話できるのではないかと思った。

　また先日の記事でも紹介したが、NPUを駆使して推論すれば低消費電力で済む。あの記事は「AnythingLLM」と「Foundry Local」の組み合わせを紹介したが、読者からのアドバイスで、Intel純正ソフト「AI Playground」でもNPUを使ったLLM推論が可能だと知った。まあ、どちらにしろUIがデカすぎるので、LM Studioと同じ理由で使いたくないのだが。

　というわけで、「ローカルLLMと会話できるシンプルなデスクトップマスコット」をバイブコーディングしてみようと思うに至ったのだった。

　先日の記事の通り、Foundry LocalがLLMを実行する部分を担い、モデルの選択によってCPU、GPU、NPUを使い分けてくれる。またFoundry Localが起動すると、サーバーとして振る舞い、特定のポートを叩けばOpenAI互換のAPIが使える。

　よって筆者……じゃなかった、AIが作るアプリは、

• キャラクターを表示する
• チャット入力欄を用意する
• LLMからの出力を吹き出しに表示
• OpenAI APIを叩いて送受信する

という4つの機能さえ実装すれば、理論上動作するはずである。

俺は素人だから必要最低限のプロンプトだけ投げるぜ

　必要な機能の目処が付いたので、とりあえずChatGPTに以下のプロンプトを投げてみた。ちなみにChatGPTは無料プランで、何も契約していない。

　するとChatGPTから以下の答えが返ってきた。

　返ってきたソースコードは、「UI(MainWindow.xaml)」と「ロジック(MainWindow.xaml.cs)」の2つだ。それからキャラクターの画像をどのフォルダに配置すべきなのか教えてくれたほか、改良ポイントとして「タイピング風表示」、「ウィンドウドラッグ対応」、「感情の実装が雑すぎる(文中のキーワードで判断)のでスコア評価もしくは感情ラベルをLLMに吐かせる」といった提案をしてくれた。

　だが、ChatGPTは何かを忘れている。そう、筆者は事実上プログラミング未経験者で、ソースコードだけ渡されてもコンパイルの仕方すら分からないのだ。MainWindow.xamlとMainWindow.xaml.csって何それ美味しいの？というレベルである。ここはバカ丸出しでChatGPTに注文をつけるしかない。

ソースコード吐いた後、俺のことを置いてきぼりにいきなり別次元の話に行こうとするChatGPT

　以降、Visual Studioの無料の入手方法(Community Editionは無料)や、分からないことが発生した場合でも、ググったりしないで、あえてChatGPTの中で質問し続けた。それから、ChatGPTはせっかく画像生成機能もあるので、Visual Studioインストール中にキャラクターも生成してもらった。

Visual Studioインストール中にキャラクターを生成して待機

あとはChatGPTの指示通りにソースコードをVisual Studioに貼り付けていく

当然、エラーになったりするがAIにまるっと修正させる

　XAMLもC#も画像も準備OKになったところで改めてVisual Studioのステータス画面を見ると、数個のエラーが残っていた。ChatGPTとのやり取りは省くが、基本的にエラーとなっている文を丸々ChatGPTに貼り付けて、解決してもらう。筆者がエラーでつまずいたポイントを挙げていくと、

1. XAMLの先頭が壊れていた
2. JSONがパースされない(Foundry LocalのエンドポイントをChatGPTが理解していなかったため)
3. マスコットの吹き出し上部が切れてしまう

のである。特に2番目について、まさかFoundry LocalのエンドポイントがOpenAI API互換だっていうことをChatGPTが知らなかったとは思わなかったので、30分近く格闘してしまった。それ以外は比較的トントン拍子で修正することができた。

　もっとも、ChatGPTは「ソースコードの差分」を出力してくれるが、どこに挿入するものなのか提示してくれなかったり(関数を読んでいけば分かるが)、分かりにくかったりするので、そういうときは「修正後のソースコードを全部ちょうだい」と頼むことが多かった。

無料のChatGPTはソースコードの修正を頼むと、ソースコードを断片的に渡される。挿入箇所の説明もGeminiなどに比べるとあっさりめで、どこに挿入するのか分かりにくい

　ひとまず全部バグを潰したら、動作するアプリのプロトタイプが完成した。ここまで来るのに1時間半ぐらい費やしたが、おそらくOpenAI API互換だと最初から伝えていれば1時間程度で済んだことだろう。ちなみにOpenAPI互換のため、ポートをLM StudioなどのOpenAI API互換エンドポイントに仕向ければそちらでも実行可能ではある。

ひとまず超初期プロトタイプ完成。吹き出しもテキストボックスも出しっぱなしだし、Qwenの思考モードもオンのまま

　これらを修正していたら、ちょうどオープンソースの「Kimi 2.6」が公開された。こちらのほうもコーディング能力が高いとのことなので、まるっとソースコードをKimiのほうに移して、以降はKimiにいろいろ頼ってみることにした。

実装してから気づくバグ……いやそれは仕様と呼ぶ

　これでひとまず晴れて自作のマスコットを介して、Foundry Localの仕組みを使いつつLLMと会話できることが確認できたが、アプリとしてまったくOKだと手放して喜べない理由がある。

1. Foundry Localが起動していないと会話に失敗する(当然)
2. Foundry Local起動後のポート番号はランダムだが、アプリは決め打ちでAPI取得失敗する
3. Foundry Localで使うモデルが選べない(別途コマンド操作でロードしたものだけ)
4. キャラクターが瞬きしない
5. LLMの反応待っている間、待受中といった表示がない
6. メッセージを全部受け取ってから表示し始める
7. 吹き出しがスクロールできないので長文表示できない
8. テキストボックスも吹き出し表示しっぱなし
9. 終了の手段がAlt+F4のみ
10. アプリを閉じてもLLMがメモリにロードされっぱなし

　ユーザーからしたら単なるバグだが、考えてみれば筆者が当初ChatGPTにお願いしたアプリは、あくまでも動作しているFoundry Localを介したLLMと対話するだけの「ガワ」であって、これらの仕様を事細かに定義した上でChatGPTが実装させたわけではない。「あなたのお望み通り(仕様通り)のソフトを実装しました」という挙動は当たり前であって、頼んでもいないことを実装したらそれはそれでどうなのよ、的な話だ。

　そのため、Kimiとやり取りしながらゆっくり実装を進めていった。ここでKimiが「なかなかやるな」と思ったのは、Foundry LocalのURLやポートを指定したり、モデルを取得したり選択したりする設定画面を、自動で別途生成してくれたこと。確かに1画面でゴチャついたら元も子もないので、デスクトップマスコットの存在意義をしっかり理解しているな、と思った。

モデル決め打ちではなく設定画面で変更できるようにした図。これでGPUとかCPU推論も思いのまま

GPU推論している図。ただ、画像のようにGPU負荷終了後=テキストを全部受け取ってからに喋り始めるので遅い。ここもストリーミングできるように修正した

　どうしても直らなかったのがFoundry Local起動した後にランダムになるポート番号取得。KimiでもChatGPTでも、やり方を変えても取得できないのだ。ここでコーディングに比較的強いとされるClaudeに投げたら、デッドロックしていることが判明してあっさり問題が解決した。まあそういう日もあるかもしれない。

Claudeにソースをまるっと投げて問題点を聞いたらあっさり直した。直したが、無料分の使用制限にあたって終了

　Foundry Localは今年(2026年)4月に正式リリースされたばかりなので、おそらくそれを扱うためのノウハウが不足しているのだろう。逆にそうでないところは、ChatGPTでもKimiでも一発で成功することが多い。たとえばキャラクターの瞬きアニメーションは、自動で4秒から10秒でランダムで設定されたし、「お前を消す方法」で終了させる実装も一発で終えた。

　上でも説明しているが、無料のChatGPTはわりかしコンテキストウィンドウを節約する志向のようで、ソースの差分しか提供してくれないことが多い。するとソースコードを自力で検索して貼り付ける必要があるが、作業をミスってしまいエラーになりがちだった。一方、Kimiは細かい指示説明は抜きにして、全ソースコードをパパっと出してくれることが多く楽だった。

ChatGPTにいろいろ修正を頼み続けるとますます説明が省略されがちになる。トークン節約なのは分かるが、関数を検索して自分で貼るとか、人間がやる作業じゃないぞ……

その点Kimiは完全版って頼まなくても完全版で来ることが多い。太っ腹でいい判断だ

　記事執筆時点で、作成したアプリに、終了時に特にほかのアプリでLLMが使われているかどうか判定してメモリに残すかどうかといった機能はなく、問答無用でアンロードする仕様だったり、複雑なアニメーションとか感情判定とかはない。まあ公開するつもりがない自分用アプリだし、ひとまずこれで問題はないだろうと思った。気が向いたら機能拡張したいと思う。

　なお、作り終えてから知ったのだが、「CocoroAI」というデスクトップマスコットがあり、こちらもローカルLLMのエンドポイントを叩くことができるようだ。しかも機能もふんだんに実装されている。ただ、3Dがゴリゴリ動くのでCPU/GPUともに負荷が高く、GPUで推論する場合はリソースを食い合うし、ノートPCで常駐するような使い方はちょっと向かないなと思った。自作してよかったと思う。

AIに仕様まで考えさせたら爆死した

　ここまで来て筆者は思った。「じゃあ最初からデスクトップマスコットとして必要な仕様を全部策定して一気に実装させればいいじゃん！」ということだ。とはいえ先述の通り筆者はソフトウェア開発についてまったくノウハウがない。そこでKimi自身に仕様を策定させて実装してみようと思った。

　すると、何やらFoundry Localについて自動的に調べ始め、仕様を策定していった。……のは良かったのだが、基本機能(Phase 1)でいきなり感情/状態変化、音声による対話、天気取得、OSログイン時の自動起動、コンテキスト保持などを策定したのだった。

もう音声で喋ったりとか天気取得とか俺以上のことを考えている。Phase 2ではマルチモーダル対応とか言ってる。モダンといえばモダンだが、そこまで求めてない……

　「これは俺以上の賢さだ(当然)！」と思いつつ、じゃあ実装を始めてくださいと頼んだところ、14ファイルにもおよぶ大量のソースコードを生成してくれた。後はAIの指示通りに、Visual Studioでプロジェクトを作成して1つずつファイルを作って中身をコピペしていく。

　……そう、ここで筆者はタダのAIのしもべに成り下がってしまったのだ。AIに指示したのは1行で1分足らずで済んだのに、AIに逆に指示されてファイル作成+コピペ作業は5分ぐらいかかるのである。だから自動でソースをファイルに記述してくれるCodexもClaude CodeもKimi Codeもあるのね……などと妙に納得してしまった。

【8時15分修正】Codexは無料枠でも利用できるため記述を変更しました。

　「まあそれでもAIが考えた最強のマスコットが使えればいいや」と思ってなんとか全部コピペしてみたが、エラーだらけになってしまった。その後Kimiでどうあがいてもエラーが消えなかったので、仕方なく会社のGoogle Workspaceで契約しているGemini 3.1 Proに投げてしらみ潰しに修正していった(Claudeはこの日上限に達してしまった)。

　なんとか起動できるレベルまで持っていったが、キャラクターが吹き出しで答えてくるのではなく、チャットウィンドウで交流する方式。しかも無駄にWindows標準の訛った日本語のナレーターの音声で語りかけてくる。さすがに萎えてしまって、そのままで使う気にも修正する気にもならなかった。まあ、こちらは完全AI版ということで、記念として残しておこう。

コンパイルできないエラーだらけだったが1つ1つ潰していった結果なんとか起動だけはできるようになった。でも400番エラーで肝心な会話はできない

“欲しいソフトを作る”楽しさの再確認

　バイブコーディングに触れてみて思ったのは、コンピュータと親和性の高いAIをもってしても、まだ完璧にプログラミングはできないんだな、ということ。エラーメッセージを貼ると、意外にも「それは関数のタイポ」とか「メソッドを誤って消し飛ばしてしまった」とか凡ミスをしでかすようだ。ただ、人間と同じように指摘すると直してくれるので、それはそれで、あたかも同僚と一緒に仕事しているような感じで楽しい体験だ。

　人間一人ひとりには、無限の可能性や多くの夢が秘められているが、技術や技量が壁となって、その可能性や夢を実現できないことがこれまであった。しかし今ならAIがあって、その壁を乗り越えられる。バイブコーディングは、実現したい、欲しいソフトがあるのに、プログラミング知識の前に立ち止まってしまう筆者のような人間にとって、一筋の光だ。

　もし「誰にも見向きされないけど、自分だけがめちゃくちゃ欲しいソフト」のアイデアが眠っているのなら、AIに話しかけてみてほしい。トライ&エラーを繰り返しながら、自分が欲しいと思ったソフトが動き出す瞬間は、かつてMS-DOSやWindows 95で多くのソフトを知り触れたあの時の興奮と変わらないはずだ。