プログラミング知識ゼロでも、
ずっと胸の奥に残っていた願いは、
AIとなら形に近づけることがあります。
遠かった世界が、言葉から近づき始めた
「自分には無理だ」
そうやって、やりたいことを胸の奥に押し込めた経験はありませんか。
作ってみたい。
形にしてみたい。
でも、知らない言葉ばかりで息が詰まる。
何から始めればいいのかも見えない。
そんな人の心を深く揺らすのが、
プログラミング知識ゼロに近いところから、
AIと一緒にローカルLLMと会話できるデスクトップマスコットを作っていった話です。
これは、何でも分かる人の武勇伝ではありません。
分からないまま立ち止まり、
それでも背を向けず、
一つずつ前へ運んでいった人の記録です。
もともとの夢は、
「ソフトウェア会社を立ち上げる」ことでした。
ちょうどWindows 95が発売された1996年前後、
テレビで連日流れるMicrosoft……もといビル・ゲイツ氏のニュースや特番を見て、
ソフトウェア会社は面白そうだし、社長は金持ちでいいな、と思った。
その率直さに、かえって胸をつかまれます。
けれど、そこで現実の壁にぶつかります。
ソフトウェア会社を立ち上げるなら、
まず勉強して、自分で何か作らなければいけない。
そう思って、書店でプログラミングの本を買って読んでみた。
それでも、「自分でソフトが作れる」という像がまったく浮かばなかった。
関数。
ポインタ。
スタック。
丁寧に説明されていても、心の中ではこうなる。
「んで、それは俺が夢に描いたソフトとなんか関係あるん？」
ここで苦しくなるのは、才能がないからではありません。
学んでいることと、自分が本当に作りたいものが、まだつながっていないからです。
どの本を読めばいいのか。
どの言語を選べばいいのか。
右も左も分からない人間にとっては、そこからもう霧の中です。
そんな距離を、一気に縮めたのがAIでした。
そばで話せる存在を、自分の手で作りたかった
近年は、作りたいものの形を言葉で伝え、
AIが実際にプログラミングする「バイブコーディング」が実用的になってきました。
そこで生まれたのが、
ローカルLLMと会話できるデスクトップマスコットを作ってみよう、という挑戦です。
代表的なローカルLLMのソフトとしてはLM Studioがある。
けれど、やりたかったのは、ちょっとした質問や雑談でした。
そのたびに大きな画面を開いて、ウィンドウを切り替えるのは少し違う。
作業中の画面を開いたまま、気軽に話しかけられる存在がほしかったのです。
しかも、Foundry Localは起動するとサーバーとして振る舞い、
特定のポートを叩けばOpenAI互換のAPIが使える。
つまり理屈の上では、必要な機能を絞れば動かせるはずでした。
必要なのは4つです。
キャラクターを表示する。
チャット入力欄を用意する。
LLMからの出力を吹き出しに表示する。
OpenAI APIを叩いて送受信する。
まずはここだけ。
ここに絞ったことが、この話の大きな分かれ道になっています。
ChatGPTに投げた最初の依頼も、実に率直でした。
Windowsで既にFoundry Localが動いている。
NPUで推論する仕組みができている。
これを使って、デスクトップマスコットと雑談できるアプリを作ってほしい。
さらに、
入力ボックスは小さく。
吹き出しで受け答えする。
通常の顔、悲しい顔、嬉しい顔の3つを用意し、回答内容に合わせて自動で切り替える。
答えの長さに応じて吹き出しサイズも自動調整する。
そうした細かな願いまで丁寧に渡していきます。
返ってきたのは、Windows前提ならWPF（C#）で軽く作るのが一番ラク、という提案でした。
UIはWPF。
推論はFoundry LocalのローカルAPI。
感情判定はキーワードか簡易スコア。
吹き出しはTextBlockとBorderで自動サイズ。
ここまで示されると、遠かった世界が急に具体物になってきます。
返ってきたソースコードは、
「MainWindow.xaml」と「MainWindow.xaml.cs」の2つ。
画像の配置場所まで教えてくれた。
改良案として、タイピング風表示、ウィンドウドラッグ対応、感情ラベルを出させる話まで出てきた。
分からないまま聞いたから、前へ進めた
でも、ここで終わりではありません。
そもそも、どこに貼ればいいのか分からない。
コンパイルって何なのかも分からない。
MainWindow.xamlって何それ、という段階です。
ここで見栄を張らず、
「今もらったソースコードをどこにはっつけて？どうすればいい？コンパイル？？」
とそのまま聞いたことが、この話を前へ動かしました。
すると返ってきたのは、貼る場所は2つだけ、という答えでした。
XAMLを貼る。
C#を貼る。
ビルドして実行する。
Visual StudioでMainWindow.xamlを開いて、今ある中身を全部消して、コードを丸ごと貼る。
そこまで細かく案内されたことで、ようやく足元の道が見えてきます。
しかもVisual Studioの無料版の入手方法まで教えてもらい、
分からないことが起きても、あえて検索せず、そのままChatGPTに聞き続けた。
インストール中には、画像生成でキャラクターまで用意してもらった。
ひとつずつ、必要なものが揃っていきます。
分からないまま言葉にできたから、
ここまで来られたんです。
前に進める人は、最初から何でも知っている人ではありません。
見えないままでも、次の一歩を聞ける人です。
もちろん、現実はそんなにきれいではありません。
XAMLもC#も画像も準備OKになったところで、
Visual Studioの画面には数個のエラーが残っていた。
そこで、エラー文を丸ごと貼って、AIにまるっと修正させていく流れが始まります。
つまずいたポイントは、かなり具体的でした。
XAMLの先頭が壊れていた。
JSONがパースされない。
マスコットの吹き出し上部が切れてしまう。
特に大きかったのは、Foundry Localのエンドポイントでした。
OpenAI互換のAPIとして扱えるのに、その前提がAIに伝わっておらず、30分近く格闘することになった。
ここに、AIは万能ではなく、前提がずれれば普通にこじれるという現実が出ています。
それでも、差分が分かりづらければ
「修正後のソースコードを全部ちょうだい」と頼み直しながら進めていく。
そうして、ひとまず全部バグを潰した先に、動作するアプリのプロトタイプが完成しました。
ここまで、およそ1時間半。
OpenAI互換だと最初から伝えていれば、1時間程度で済んだかもしれない。
この距離感が、むしろ現実味を強くしています。
動いたあとに見えてきた、本当の課題
ただ、ここからが本当の意味での始まりでした。
いざ使ってみると、次々に不便さが見えてきます。
Foundry Localが起動していないと会話に失敗する。
起動後のポート番号はランダムなのに、アプリは決め打ちでAPI取得失敗する。
使うモデルが選べない。
キャラクターが瞬きしない。
反応待ちの表示がない。
メッセージを全部受け取ってから表示し始める。
長文をスクロールできない。
終了の手段がAlt+F4のみ。
閉じてもLLMがメモリにロードされっぱなし。
ここで大切なのは、
それを単なる失敗として終わらせていないことです。
最初にお願いしたのは、あくまで「動作しているFoundry Localを介したLLMと対話するガワ」でした。
だから、そこまで細かい仕様を頼んでいない以上、抜けが出るのは当然でもある。
つまり、止まる原因は能力不足だけではない。
最初に見えていなかった輪郭が、使って初めて現れてきたということです。
うまくいかなかった理由を、
すべて自分の非力さにしなくていい。
実際に触れたからこそ、足りなかったものが見えたのです。
その後はKimiともやり取りしながら、細かい部分を整えていきます。
Foundry LocalのURLやポートを指定したり、モデルを取得したり選択したりする設定画面まで、別途生成してくれた。
1画面でごちゃつかないように切り分けてくれたあたりに、デスクトップマスコットの存在意義を理解した気配もありました。
どうしても直らなかったのは、Foundry Local起動後にランダムになるポート番号の取得です。
KimiでもChatGPTでも解決できなかった。
ところがClaudeに投げたら、デッドロックしていることが判明し、あっさり問題が解決した。
そういう日もある。
その一言に、現場の空気がにじみます。
Foundry Localは2026年4月に正式リリースされたばかり。
だから、まだ扱い方の蓄積が少ないのだろう。
一方で、キャラクターの瞬きアニメーションや、「お前を消す方法」で終了させる実装は一発で終わった。
得意なところと、まだ荒いところが混ざっているのも、今のAIらしさです。
それは前へ進んだ証拠です。
何もしていない人には、違和感すら現れません。
実際に動かした人にだけ、次に整えるべき場所が見えてきます。
便利そうな近道が、かえって遠回りになることもある
そして、ここで誰もが一度は考えそうなことを試しています。
だったら最初から必要な仕様を全部決めて、一気に実装させればいいじゃないか、と。
そこでKimiに、Foundry LocalでLLMと対話できるデスクトップマスコットアプリの仕様を策定してほしいと頼んだ。
すると、感情や状態変化、音声による対話、天気取得、OSログイン時の自動起動、コンテキスト保持まで入った仕様が出てきた。
賢い。
たしかに賢い。
けれど、その瞬間に人の手のサイズから少し離れ始めます。
生成されたのは、14ファイルにも及ぶ大量のソースコード。
Visual Studioでプロジェクトを作成し、1つずつファイルを作って中身をコピペする。
AIに指示したのは1行で1分足らず。
なのに、AIに逆に指示されて、ファイル作成とコピペには5分ぐらいかかる。
そこで、CodexもClaude CodeもKimi Codeもあるのね、と妙に納得したそうです。
しかも、苦労して貼り終えてもエラーだらけ。
Kimiでは消えず、会社のGoogle Workspaceで契約しているGemini 3.1 Proに投げて、しらみ潰しに修正していく。
なんとか起動しても、今度は吹き出しで答えるのではなくチャットウィンドウ方式。
しかもWindows標準の訛った日本語のナレーターが語りかけてくる。
さすがに萎えてしまい、そのままで使う気にも、直す気にもならなかった。
この場面が教えてくれることは、とても重いです。
大きく作れば楽になるわけではない。
機能を増やせば満たされるわけでもない。
自分が本当にほしかったものの芯を見失うと、立派に見えるものほど、自分の手から離れていきます。
何度か止まった人ほど、次の一歩は深くなる
それでも最後に残ったのは、失望ではありませんでした。
AIを使ってみて分かったのは、まだ完璧ではないということ。
関数のタイポや、メソッドを誤って消してしまうような凡ミスもある。
でも、人間と同じように指摘すれば直してくれる。
まるで同僚と一緒に仕事をしているような感覚があり、それはそれで楽しかった。
そして何より、
「誰にも見向きされないけど、自分だけがめちゃくちゃ欲しいソフト」
が、トライ&エラーの末に動き出す瞬間のよろこびは大きかった。
あとからCocoroAIというデスクトップマスコットの存在も知った。
こちらもローカルLLMのエンドポイントを叩ける。
しかも機能は豊富。
けれど3Dがゴリゴリ動くぶん、CPU/GPUともに負荷が高く、ノートPCで常駐する使い方には少し向かない。
だからこそ、自作してよかったと思えた。
この話が残していくのは、
「AIは便利だった」という感想だけではありません。
無理だと思っていた場所にも、言葉から手を伸ばせる時代になったという事実です。
だからもし今、
何度か挑戦して、途中で止まって、もう一度踏み出すのが怖くなっているなら、
思い出してほしいんです。
止まった経験は、失格の印ではありません。
どこでつまずくのかを、身をもって知ったということです。
その経験は、次の一歩の精度を上げます。
次の一歩は深くなります。
なぜなら、うまくいかなかった痛みを知っているからです。
遠回りした人には、遠回りしやすい場所が見えます。
それは弱さではなく、次の前進を支える材料です。
コメント