ローカルAIの開発環境として買ったサーバーですが、今のところ、日常で便利さを感じているのはAI開発以外の用途にもあります。
例えば、複数の機器のスピーカー出力をネットワーク経由でサーバーに集約し、サーバーに接続したスピーカーから再生すること。以前はメインPCの電源に左右されていたスピーカー出力が、かなり扱いやすくなりました。
サーバーの構成は資料にまとめ、追加機能や更新の作業もAIと相談しながら進めています。今回は、買ったあとの使い道と、ほぼAIに任せている管理で、自分が何を判断しているのかを書いてみます。
音声入力を自前で動かせるのは、助かっている
AIを使った開発について調べていると、音声入力をおすすめするYouTuberの方をよく見かけます。キーボードで打つ代わりに話して指示することで、作業を効率化できるという話です。
私もそれに感化された口で、導入しようかなと考えたんですが、検討していたサービスはサブスクリプションだったことと、クラウドに音声を送ることが少し気になっていました。
そこでたまたま、音声入力をするアプリケーションをAIで自作してみよう、というYouTubeの企画を見ました。これなら自分でもできるんじゃないかと思ったのが、導入のきっかけの一つです。最初は古いゲーミングPCにWhisperを導入し、音声入力を動かしていました。
現在のサーバーでは、Qwen3-ASR-1.7B-JAを常駐させています。音声認識のモデルを自分の環境で動かせるうえ、私が使う日本語特有の単語などもよく認識してくれて、かなり満足しています。音声入力サービスのサブスクリプションへ加入しなくても済む点も、助かっています。
ただ、自前の音声入力は旧PCでも実現していたので、この用途だけのために新しいサーバーが必要だったわけではありません。それでも、今も便利に使っているものの一つとして紹介しておきたいと思いました。
メインPCを止めると、スピーカーが使いにくかった
スピーカー出力の方では、具体的に解消できた不便がありました。
以前はSound Blaster X5をメインPCに接続し、各機器のスピーカー出力をX5へ集約して、そこにつないだスピーカーから再生していました。サブPCやNintendo Switch 2のスピーカー出力もまとめていたのですが、メインPCを停止するとスピーカーから音が出なくなるのが困りごとでした。
苦肉の策として、メインPCに接続した給電可能なUSBハブを経由してX5をつなぎ、メインPCの停止中もX5へ電源を供給する形にしました。これで、メインPCが動いていなくてもX5のミキサー機能を使えました。
ただ、この方法にも欠点がありました。私の環境では、メインPCを止めるとX5が一時的に休止状態に入ったようになって音が出なくなり、X5を再起動すると再び音が出る、という動きになっていたんです。どうにか使えるようにした構成ではありましたが、毎回この操作が必要なのは不便で、何とかしたいとは常日頃感じていました。
そんな中、ひょんなことからホームスピーカーの導入を考え、各機器のスピーカー出力をサーバーへ集約する仕組みがないか、ChatGPTへ相談しました。そこで教えてもらったのが、「Voicemeeter」を使ってPCのスピーカー出力をネットワーク経由で送る方法でした。
スピーカー出力をサーバーに集めると、PCを追加しやすくなった
今は、Windows PC側のVoicemeeterから、VBANという仕組みを使ってスピーカー出力をネットワーク経由でサーバーへ送っています。サーバー側では受信用ソフトとPipeWireで各PCのスピーカー出力をミキシングし、サーバーへUSB接続したSound Blaster X5を通して、接続先のスピーカーから再生しています。
構成としては「各Windows PCのスピーカー出力（Voicemeeter） → ネットワーク → サーバーで受信・ミキシング → X5 → スピーカー」という流れです。現在は2台のWindows PCのスピーカー出力を、この経路でサーバーに集約しています。
この形にしたことで、メインPCを止めているときにスピーカー出力が不安定になる問題が解消しました。メインPCを使っているかどうかに左右されにくくなったのは、大きな変化です。
さらに、新しいPCを追加しても、同じ仕組みに組み込めます。PCを増やした時にも、スピーカー出力の集約先が決まっているので、コントロールしやすくなったと感じています。そもそも家で一人で使うPCを何台も持っているのがおかしいというツッコミがきそうで怖いですが……（笑）
AIに何かを作ってもらう用途はまだ試行錯誤していますが、このスピーカー出力の集約は、常時稼働するサーバーが実際に役立っている例です。
作った構成は、Markdownの資料に残す
こうした機能を追加していくと、構成をどう記録しておくかも大事になってきます。サーバーの構築や変更作業をChatGPTに任せたあとは、そのままサーバーの状態や導入したものをまとめてもらい、Markdownの資料として残しています。追加機能の相談や状態の確認、新しいモデルの検証でも、その資料を提示すると次の作業へスムーズに移れるので、資料化しておいてよかったと感じています。
会話だけに構成を残していると、別のチャットへ移ったときに説明をやり直すことになります。資料があれば、今ある環境を参照しながら次の相談を進められます。
ただし、構成を変えたら、その場で資料も更新してもらう必要があります。それを怠ると、AIと会話していて「なんか話がずれるな」と感じることがあるので、そこは押さえておこうと思っています。
管理はほぼAIに任せているが、対応方針は自分で決める
更新やセキュリティパッチに関するサーバーの管理作業は、今はほとんどAIに任せています。資料をもとに調べてもらい、必要な作業を進めてもらう使い方です。
ここでいうAIによる管理は、ローカルLLMへ日常作業を安定して任せられるようになった、という話とは別です。サーバーの構築や管理では、ChatGPT側のパソコン操作の機能を利用しています。
一方で、自分が確認している点もあります。先ほど紹介した音声認識の環境には、待機中にもCPUの1コア相当を使い続ける既知の問題があり、公式の修正を待っています。
この件は、現状の影響は許容して一旦パッチを待とう、と判断していました。ところが、定期的なパッチ確認を頼むと、AIがこの問題を再び取り上げ、調査や構成変更で迂回できる可能性があると提案してきます。
私が確認しているのは、主にそこです。今は進めてほしくない調査や構成変更へ話が向かっていないかを見ています。
作業を任せる一方、今困っていることなのか、手を入れる価値があるのか、待つ方がよいのかは、自分が判断しています。
「注意事項」と「どう対応してほしいか」は、両方残したい
この問題については、運用資料に注意事項として書いてもらっていたのですが、「パッチが出るまで待ちたい」「迂回策の調査は今は進めてほしくない」という方針までは、十分に明示していなかったと思います。
そのため、構成変更に合わせて資料も組み替えてもらっています。構成や既知の問題が正しく書かれているかに加えて、「どう対応してほしいか」まで伝わる内容になっているかは、自分自身でも目を通す必要があると考えています。
よく巷で言われている人間に残された仕事はAIの成果物を正しくチェックするということにもつながっているように思いました。
サーバー管理を任せるけど、自分でもちゃんとコントロールしていく。そんな単純なことに気づかされたという話でした。
インフラエンジニアとして、試せる環境がある面白さ
私はインフラエンジニアなので、常時稼働するサーバーが一台あると、できることの幅が広がると感じています。必要なソフトウェアを自分で導入し、構成を変えながら試せること自体にも面白さがあります。
今後は、サブスクリプションで使っているものの一部をOSSで代替できないか、とも考えています。ただ、具体的にどれだけ契約や費用を減らせるかは、これからです。
AIサーバーとしての購入効果は、まだ評価の途中です。それでも、スピーカー出力を集約するような日常の使い勝手の改善や、自分で試して学ぶ場所としては、持っていてよかったと感じる部分があります。
ローカルAIでやりたいことを試しながら、家の中で役立つ用途も少しずつ増やしていく。今は、そのような付き合い方をしています。
購入時に何を比較したかは「RyzenのローカルAIサーバーを買った理由と、使って分かった難しさ」、チャットや資料を分ける考え方は「AIとの開発で一番変えたことは、一つのチャットで作り続けないことだった」で紹介しています。
コメント