List of Tools [text.Baldanders.info]

リンクカードに対応した

2026-07-08T11:36:01+00:00

取引量が少なくて Amazon PA-API にアクセスできなくなってしまったので，今までの商品レビューカードから Web サイトのリンクカードに切り替えないと。 …と思いながら半年以上経ってしまった（その間に骨折入院とかもあったけど）。

ようやくリンクカードを Hugo の処理で出せるようになった。こんな感じ。

text.Baldanders.info: 帰ってきた「しっぽのさきっちょ」

Web ページの情報収集のためのツールを作るのに時間がかかってしまったのだ。いや，厳密には，実作業時間では半日ほどなのだが，やる気スイッチがなかなか入らなくて（笑）

あらかじめツールを使って Web ページ情報をこんな感じに Hugo の環境下に保持っておいて

[
  {
    "hash_id": "79c9ba36c62cd792801ef499cffe7e614e89670a",
    "url": "https://text.baldanders.info/",
    "title": "text.Baldanders.info",
    "description": "帰ってきた「しっぽのさきっちょ」",
    "image_url": "https://text.baldanders.info/images/attention/site.jpg",
    "image_path": "/images/thumbs/79c9ba36c62cd792801ef499cffe7e614e89670a.jpg",
    "image_width": 100,
    "stars": [
      false,
      false,
      false,
      false,
      false
    ]
 }
]

実際に使うときは Hugo のショートコードで展開してる。上のリンクカードだとこんな感じ。

{{< linkcard "79c9ba36c62cd792801ef499cffe7e614e89670a" >}}

引数で hash_id を指定すれば，そのリンクカードを展開するようにしている。

最近は出版社さんもページの og:image 等で書影を指示してくれるので，こちらは og:image の中身をサムネイル表示すれば，本の紹介用リンクカードになる。たとえば最近読んだ『ケアレス・ピープル』ならこんな感じ。

ケアレス・ピープル - 株式会社　すばる舎学び・成長・成功をあなたに: ケアレス・ピープル詳細をご覧いただけます。; 評価

[Comment] 米国では某企業から圧力がかかってると聞いて紙の本を買ってみた

ありがたい話である。

YouTube とかも埋め込みにしないで，こんな感じにリンクカードにすれば煩くないかな。

【 3D LIVE 】Flat Out 輪堂千速生誕祭2026 Summer Fes!🔧【#輪堂千速生誕祭2026 】: 輪堂千速誕生日記念グッズ2026🛒販売ページURLhttps://shop.hololivepro.com/products/rindochihaya_birthday_2026⏰グッズ販売期間（受注販売）2026年07月08日(水) 21時00分～ 2026年08月10日(月) 18時00分🎧🔧輪堂千...; 評価

今回，ツールを組むのに意図的に AI エージェントを使わないようにした。いや，細かく指示するのが面倒になって「自分で書いたほうが速い」となってしまったのだ。たまには自力でコードを書かないと脳みそが鈍るからな（笑）

あっ，でも，レビューとかは AI エージェントにやってもらってる。ひとりでコードを書くときって AI が QA 役みたいに振る舞ってくれるので，めっちゃ助かっている。 AI がコードを書くときは私が QA 役かな。

「なうぷれあっと」を試す

2026-06-27T11:28:22+00:00

すいばりさんによる音楽共有サービス「なうぷれあっと」を試してみた。ご本人による紹介記事はこちら

日本の音楽シーンをATプロトコルで共有するSNSを作った｜すいばり

AT Protocol ベースの音楽共有サービスとしては Rocksky が有名らしいが，あちらのメインボリュームは（当然ながら）英語圏の人達なので，上がってくる楽曲もあちらの音楽が中心になる。そこで

日本のユーザーが、日本語の音楽でつながれる場所が欲しかった。

日本の音楽シーンをATプロトコルで共有するSNSを作ったより

というのがサービスを立ち上げた動機だそうな。

うんうん。よく分かる。私なんて今はアニソンか VTuber の楽曲しか聴かないため，JPOP ならまだしも，海の向こうの音楽はさっぱり分からない。なので，こういうサービスは大変ありがたかったり。

というわけで試してみた。サインアップは Bluesky (というか atproto) のアカウントで行う。設定画面はこんな感じ。

設定より

「自動投稿」を有効にして Last.fm のユーザ名をセットすれば Last.fm の scrobble 情報を使って Bluesky に自動投稿してくれる。 Last.fm と Spotify などの音楽配信サービスを連携すれば，それらの視聴データも反映される。

私はスマホに Onkyo HF Player を入れていて，楽曲の音源を入れてヘヴィローテーションしているのだが，これも Last.fm のアプリで認識できた。

なうぷれあっとのデータは各ユーザの PDS リポジトリに公開情報として格納される。なうぷれあっと自体はユーザの視聴データを保持しないが，各 PDS リポジトリのデータをかき集めてトップページに統計情報を表示しているらしい。

ATプロトコルは 分散型アーキテクチャ です。「再生回数が多い曲」「人気ユーザー」のような集計は、複数のサーバーをまたぐデータを扱う必要があります。

音楽SNSのような中央集権的なサービスが当たり前にやっていることを、分散型の制約の中でどこまで実現できるか試してみたかったです。

日本の音楽シーンをATプロトコルで共有するSNSを作ったより

なうぷれあっとより

Bluesky への自動投稿は設定で間引くことができる。さっき書いたように，私は聴き始めると割とヘヴィローテーションしてしまうので，全部を Bluesky にポストすると TL が #なうぷれ で埋め尽くされてしまう。ポストの頻度についてはチューニング中だが，私は 10% くらいで十分かなぁと思っている。

実は Last.fm のことをすっかり忘れていた。 Scrobble の履歴を見たら2016年が最後のアクセスだった。まだアカウントがあったことにびっくりだよ。当時の履歴もちゃんと残ってたし。

そういえばなうぷれあっとに上がってる楽曲で Spotify 等で視聴可能なものについては該当のページに飛べるようになっている。素晴らしい。 Spotify はアカウントだけ取って完全に放置してたんだよな¹。初めて役に立ったよ（笑）

今回のサービスを試してみて思ったが，ソーシャルなサービスだからといって何でもフラットにすればいいというわけじゃないよな。グローバルとの繋がりは保ちつつ，やんわりと囲える設計がいいのかもしれない。そう考えると Mastodon というか ActivityPub はよくできているかも。

Spotify に限らないけど（アルゴリズムで）機械的に作ったプレイリストやおすすめを聴くのってダルくない？まぁ，私はアナログレコードや CD の世代で，気に入った楽曲は手元に置いて聴き倒したい人だからしょうがない（←年寄り）。今は FLAC 形式の音源が普通に買えるようになって本当によかった。リッピングしなくて済む。 ↩︎

Ubuntu サーバで LLM 構築へ：（1）事前学習

2026-06-09T09:26:51+00:00

だいぶ生成 AI を使うことに慣れてきたので，そろそろ自前で LLM サービスを構築することを考えてみる。

いや，既にもうメジャーな AI サービスプロバイダってメタクソ化（enshittified）し始めてるぢゃん。企業サービスに完全にロックインされないうちに自前で構築できるようになっておかないと，と思ってさ。

今回は，以下の要求で Kagi Assistant にサービス構成を提案してもらった。

家庭内 LAN 上の Ubuntu サーバ機に LLM サービスを構築する
クライアントは Windows 機と Ubuntu 機を想定
主な用途はプログラミング支援とブログ作成補助
VS Code で使えるようにする

以降に Kagi Assistant からの提案を載せるけど，まだ内容の検証をしていない。なので嘘や間違いが紛れている可能性があるのでご注意を。私としては，この提案を学習の起点（trigger）とするつもりである。

アーキテクチャ

Kagi Assistant が最初に推奨してきた構成：

graph TB subgraph Server["Ubuntu Server"] Ollama["Ollama
:11434
(推論エンジン)"] LiteLLM["LiteLLM
:4000
(API Proxy)"] Nginx["Nginx
:443
(Reverse Proxy)"] Embed["nomic-embed-text
(Embedding / RAG用)"] PG["PostgreSQL
(LiteLLM 用)"] Ollama ---> LiteLLM LiteLLM --- PG LiteLLM ---> Nginx Ollama --- Embed end subgraph ClientUbuntu["Ubuntu PC"] VSCodeU["VS Code + Continue"] end subgraph ClientWin["Windows PC"] VSCodeW["VS Code + Continue"] end Nginx -- "LAN (HTTPS)" --> ClientUbuntu Nginx -- "LAN (HTTPS)" --> ClientWin

全体アーキテクチャ推奨構成（LiteLLM/Nginx あり）

推論エンジンとして Ollama を提案した理由は以下の通りらしい：

個人〜小規模LAN利用ではOllamaが最適。セットアップが最も簡単で、OpenAI互換APIを標準提供し、モデル管理が容易です。

vLLMは同時接続ユーザーが多い（5人以上）本番運用向けで、単一ユーザーには複雑さが増すだけ
- vLLM vs. Ollama: When to use each framework
- vLLM vs Ollama: Which Local AI Server to Run in 2026
llama.cppは低レベルすぎて管理が煩雑

LiteLLM は Ollama の前に置く OpenAPI 互換 API プロキシ。 Ollama だけでなく OpenAI や Anthropic などの外部 API も統一的に扱えるらしい。図では LiteLLM に PostgreSQL がぶら下がっているが，これは API キー管理・使用量トラッキング用とのこと。

What is stored in the DB | liteLLM

Nginx はリバースプロキシとして HTTPS 終端，セキュリティ（Ollama/LiteLLM への直結ポートをサーバの外に晒さない），ストリーミング対応を担っている。注意点は以下の通り：

LAN 内のみの利用でもHTTPS推奨（Continue.dev が API キーを送るため）
Let’s Encrypt 証明書か自己署名証明書を使用
ストリーミング（SSE）対応のため proxy_buffering off が必須

nomic-embed-text については後述する。

LiteLLM と Nginx は入れなきゃダメ？と訊いてみたら，もう少し簡単な構成もあるらしい。

graph TB subgraph Server["Ubuntu Server"] Ollama["Ollama
:11434
(推論エンジン)"] OpenWebUI["Open WebUI
:8080
(GUIチャット)"] Embed["nomic-embed-text
(Embedding / RAG用)"] Ollama --- Embed Ollama ---> OpenWebUI end subgraph ClientUbuntu["Ubuntu PC"] VSCodeU["VS Code + Continue
ollama run (CUI)
ブラウザGUIチャット"] end subgraph ClientWin["Windows PC"] VSCodeW["VS Code + Continue
ollama run (CUI)
ブラウザGUIチャット"] end Ollama -- "Ollama API
:11434" --> ClientUbuntu OpenWebUI -- "Web UI
:8080" --> ClientUbuntu OpenWebUI -- "Web UI
:8080" --> ClientWin Ollama -- "Ollama API
:11434" --> ClientWin

全体アーキテクチャ推奨構成（Ollama 単体, LiteLLM/Nginx なし）

クライアントの用途ごとの使い分けは以下の通り。

アクセス先	ポート	用途	クライアント
Ollama API	`:11434`	VS Code + Continue（コーディング支援）	Ubuntu / Windows
Ollama API	`:11434`	`ollama run`（CUIチャット）	Ubuntu / Windows
Open WebUI	`:8080`	ブラウザ GUI チャット（ブログ執筆・雑談）	Ubuntu / Windows

VS Code の拡張機能である Continue は Ollama API に対応しているそうなので（セキュリティの問題を除けば）直結で OK。ターミナルエミュレータ等で CUI チャットを行う場合はクライアント側にも Ollama をインストールして接続先をサーバ機に向ければいいらしい。

OLLAMA_HOST=http://192.168.x.x:11434 ollama run qwen3.5:9b

さらに簡単に Ollama API を直に叩く方法もある（自作ツール向け？）。こんな感じ。

# ワンショット質問
curl http://192.168.x.x:11434/api/chat -d '{
  "model": "qwen3.5:9b",
  "messages": [
    {"role": "user", "content": "ブログのタイトル案を5つ提案して"}
  ],
  "stream": false
}'

# ストリーミング（リアルタイム出力）
curl http://192.168.x.x:11434/api/chat -d '{
  "model": "qwen3.5:9b",
  "messages": [
    {"role": "user", "content": "PythonでFizzBuzzを書いて"}
  ]
}'

Ollama API って素の RESTful API でやり取りするのか。確かにこれは（セキュリティ的に）ヤバいな。 LiteLLM/Nginx を噛ませろって言う筈だわ。 LAN 内に他人（のデバイス）が入ってくる余地がないならギリ大丈夫かな。まぁ，どのみち malware に侵入されたらアウトだけど。

Open WebUI は Web ベースのチャットインターフェースで，以下の特徴があるらしい¹。

機能	説明
ChatGPT 風 UI	ブラウザでチャット、使い慣れたインターフェース
会話履歴	すべての会話を保存・検索可能
モデル切替	ドロップダウンでモデル切替
ドキュメント RAG	ファイルをアップロードして対話
ユーザー管理	複数ユーザー・アクセス制御
完全オフライン	外部へのデータ送信なし

OpenAI の API キーを持っていれば Open WebUI から OpenAI のモデルも使えるそうな（以下は Docker 上に Open WebUI をインストールした場合の起動例）。

# Open WebUI起動時にOpenAI APIも設定
docker run -d \
  --name open-webui \
  --network host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -e OPENAI_API_KEY=sk-your-openai-key \
  --restart always \
  ghcr.io/open-webui/open-webui:main

用途別の使い分けについてまとめてもらった。

用途	インターフェース	理由
ブログ執筆・雑談	Open WebUI（ブラウザ）	ChatGPT風で直感的、会話履歴管理
プログラミング支援	VS Code + Continue	コード補完・エディタ統合
サクッと質問	`ollama run`（CUI）	ターミナルから即座に
スクリプト・自動化	curl / Python API	バッチ処理やパイプライン

普段の調べ物は Kagi Assistant で必要十分なので Open WebUI はあまり使わないかもしれないけど。 Open WebUI が不要なら入れない構成もありだな。

モデル選択

Ollama で選択可能な LLM モデルで Kagi Assistant が勧めてきたのは以下のもの¹。

用途	推奨モデル	役割
チャット・コーディング対話	Qwen 3.6-27B または 35B-A3B	chat, edit, summarize
コード自動補完（FIM）	Qwen 2.5-Coder（7B/14B/32B）	autocomplete（タブ補完）
Embedding（RAG用）	nomic-embed-text	codebase検索
Reranker（RAG精度向上）	Qwen3-Reranker-8B	検索結果の再順位付け

GPU VRAM別のモデル構成

VRAM	チャット用モデル	自動補完用モデル	備考
8GB	Qwen 3.5-9B (~6.6GB)	Qwen 2.5-Coder 7B (~5GB)	1モデルずつ切り替え運用
16GB	Qwen 3.6-35B-A3B (~16-22GB)	Qwen 2.5-Coder 14B (~9GB)	同時稼働は量子化調整が必要
24GB	Qwen 3.6-27B (~17GB)	Qwen 2.5-Coder 32B (~20GB)	★最も推奨される構成
32GB+	Qwen 3.6-27B (Q6/Q8) + Qwen 2.5-Coder 32B	同時稼働余裕あり	RTX 5090等

💡 24GB VRAM（RTX 3090/4090）の構成が最もバランスが良い: Qwen 3.6-27Bでチャット・エージェント的コーディング、Qwen 2.5-Coder 32Bでタブ補完。ただし同時稼働はVRAM的に厳しいため、Ollamaはモデルを自動でアンロード/ロードするので、交互に使う運用になります。

あー。そういや，サーバ機のスペックを教えてなかった。手持ちの空いてるミニ PC をサーバ機にする予定なのでスペックは高くないのよ。

というわけで Ryzen 5 7430U, RAM 16GB, 外付け GPU なしの構成で再提案してもらった。

役割	推奨モデル	RAM使用量	予想速度	理由
チャット・ブログ・コーディング対話	Qwen 3.5-9B (Q4)	~6 GB	~5-8 tok/s	9Bで品質最優、ブログ執筆に十分な表現力
コード自動補完（FIM）	Qwen 2.5-Coder 3B (Q4)	~2.5 GB	~15-20 tok/s	補完は高速が命、3Bで品質も十分
Embedding（RAG用）	nomic-embed-text	~0.3 GB	高速	コードベース検索用

💡 合計RAM使用量: ~9 GB（OS等の予約分を含めても16GB内に余裕あり）

チャット用を軽くして速度を稼ぐ構成：

役割	モデル	RAM	予想速度
チャット	Qwen 3.5-4B (Q4)	~3 GB	~12-18 tok/s
自動補完	Qwen 2.5-Coder 1.5B (Q4)	~1.2 GB	~30+ tok/s
Embedding	nomic-embed-text	~0.3 GB	高速

合計 ~4.5 GB。速度は快適ですが、ブログ執筆の品質は9Bに劣ります。

🌟 注目の選択肢：Gemma 4 26B-A4B（MoE）

GoogleのGemma 4 26B-A4Bは 総パラメータ26B・推論時アクティブ3.8B のMoEモデルです。 Q4量子化で ~15 GB のRAM使用量。

✅ 品質: 3.8B活性化で26Bクラスの表現力（Qwen 3.5-9B以上の可能性）
⚠️ RAM: ~15 GBで16GBギリギリ。OSの予約分と競合する可能性
⚠️ 速度: MoEはアクティブパラメータが少なくても全パラメータのメモリアクセスが必要なため、DDR4帯域幅がボトルネックになり 予想3-6 tok/s

結論: 試す価値はありますが、16GBではスワップ発生のリスクが高く、安定性に欠ける可能性があります。まずはQwen 3.5-9Bで安定運用し、余裕があればGemma 4 26B-A4Bも試すのがおすすめ。

⚡ パフォーマンスを引き上げるTips

施策	効果	詳細
`num_ctx`を小さく	速度向上	4096→2048にするとコンテキスト処理が高速化。ブログ執筆なら2048で十分な場面も
モデルを1つずつロード	RAM節約	`OLLAMA_MAX_LOADED_MODELS=1`で未使用モデルを自動アンロード
Q3量子化を試す	RAM削減・速度UP	`ollama run qwen3.5:9b-q3_K_M`でRAM~4.5GB、品質は若干低下
スワップの無効化	安定性向上	RAM不足時のスワップは極端な低速化の原因。`/etc/fstab`でswapを0に
将来的にGPU追加	劇的改善	Thunderbolt/OCuLink外付けGPUエンクロージャーでRTX 3060(12GB)等を追加すれば、一気に実用的に

Ryzen 5 7430U には内蔵 GPU (Radeon Graphics) があるが LLM 推論には非力なので CPU-only 推論となる。そうなるとメモリ帯域幅が重要になるんだけど DDR4-3200 デュアルチャネルは DDR5 半分以下の帯域幅（〜51GB/s）しかない。 RAM のサイズも 32GB 以上は欲しいらしい。

サーバRAM	推奨構成	備考
8GB	Qwen 3.5-4B (チャット) + Qwen 2.5-Coder 1.5B (補完)	1モデルずつ切り替え
16GB	Qwen 2.5-Coder 7B (チャット) + Qwen 2.5-Coder 3B (補完) + nomic-embed	★最も現実的
32GB	Qwen 3.5-35B-A3B (チャット) + Qwen 2.5-Coder 7B (補完) + nomic-embed	★★最高の体験
64GB	Qwen 3.5-35B-A3B + Qwen 2.5-Coder 14B + nomic-embed	余裕あり

なかなかに貧弱な構成と言われてしまった（笑）

！だってメモリもプロセッサも高いんだよ，今！

しょうがないぢゃん orz

nomic-embed-text について

nomic-embed-textはOllama上で動く Embeddingモデル です。テキストを数値ベクトル（768次元）に変換するだけで、それ自体にデータベースは必要ありません。

テキスト入力 → nomic-embed-text → 768次元ベクトル出力

ベクトルデータはデータベース化して RAG (Retrieval-Augmented Generation; 検索拡張生成) に使用する¹。 Open WebUI および Continue は自前でベクトルデータベースを持っている。規模が大きくなれば PostgreSQL + pgvector などのベクトルデータベースが別途必要になる。

🏗️ RAGの規模別アーキテクチャ

規模	ベクトル保存先	構成
小規模（個人・Continue.dev）	ローカルファイル（Continue内蔵）	Ollama + nomic-embed-text のみ
中規模（チーム・Open WebUI）	Open WebUI内蔵のChromaDB	Ollama + Open WebUI
大規模（組織・自作パイプライン）	PostgreSQL + pgvector / Qdrant / Milvus	Ollama + 独自バックエンド

今回はここまで

とりあえず Ollama と RAG についてはちゃんと勉強せなあかんなぁ，というのは分かった。あとは実際に組んでみて評価していく感じかな。

薄々わかってはいたが，どうも手持ちの環境は貧弱すぎるみたいだけど，どの程度足らないのかの感覚がわからない。これは使ってみて確かめるしかないだろう。

仕事が絡むなら vLLM も気になるところだが，そういう仕事が貰えるなら考えるということで（笑）

RAG の機能は，簡単にいうと LLM に外部の情報を検索させてから回答させる仕組み。これによって組み込まれた知識にない情報についても（extrinsic hallucination を抑えつつ）対応することができるようになる。 Google 検索のようなキーワード検索ではなく，プロンプトによる指示に合わせて意味的検索ができるのが特徴。 Continue は nomic-embed-text が出力したベクトル化情報をファイルに保存するらしい。 Open WebUI は自前でベクトル化を行い，内蔵の ChromaDB に保存するようだ。 ↩︎ ↩︎ ↩︎

Secretary as a Service

2026-05-31T03:43:36+00:00

Agents Window

最近気がついたのだが VS Code 1.120 から Agents Window なるものが追加されたそうだ。

仕事でコードを書くときは分担して作業するものなのであまり意識することはないが，独りで作業する場合，特に Go で複数のパッケージを同時に弄る場合は頭の中がとっ散らかってしまうことがある。我ながら歳をとったなぁとは思うけど。

というわけで，少しでも作業が軽減できればと Agents Window を試そうとしたんだけど，これって既存の AI エージェントとのセッションを他セッションに引き継げないのな。「どうにかならん？」と，それこそ Copilot に訊いてみたんだが，セッション履歴のインポート・エクスポート機能はあるが（つまりバックアップ・リストアはできる？），他セッションに引き継いで fork することはできないと言われた。できることは AI に引き継ぎ資料を書かせて，それを別のセッションに読み込ませるくらいだそうな。

この辺の話を Mastodon/Bluesky で愚痴ったのだが

Post by @rino@mstdn.world

View on Mastodon

みたいなポストをいただいたり。でも，ここに書かれている Claude のやり方も裏技っぽいよねぇ。他に「ZedのMCPサーバでコンテキスト共有したい」みたいな運用もあるよ，と教えてもらった。

セッションの複製や fork は必須の機能だと思うんだけど，なんで Copilot の標準機能にないの？やっぱそろそろ VS Code や Copilot は卒業すべきかねぇ。だからといって，個人利用で Claude Code とか使う気はないが。

秘書としての AI エージェント

他の記事でも言ってるけど，コーディング支援として使う AI はどちらかというとペアプログラミングしている感じ。それも新人くんとのペアプロ（笑）最初の頃は「自分で書いたほうが速い」って感じだったんだけど，反応を見ながら指示を出すことで，なんとなく AI の性格のようなものが分かってきた。 GitHub Copilot の Pro 契約で使える主なモデルはこんな感じ（個人の意見です。あしからず）。

GPT-5-mini: コストゼロで使えるのが最大のメリット。生真面目なおバカ。コード補完やコメント補完では重宝するが，エージェント・モードだと最初から明後日の方向に全力疾走する。「けもフレ」のアライさんみたいなモデル
GPT-5.3-Codex: 個人で使うエージェントとしては一番バランスが取れている。こちらの意見に追従（ついしょう）せず，ちゃんと反論できる。人間のペースに合わせてくれる盲導犬モデル
Claude Sonnet 4.6: 計画立案は上手いが，一度走り出すと融通が利かず失敗するまで突っ走るチョロQモデル。コード分析等で無闇にトークンを消費してる印象。金に糸目をつけず地球資源を濫用する富裕層向き

エージェントの使い方がちょっと変わったきっかけになったが goark/pa-api パッケージに来た PR の評価に VS Code の Copilot を使ったこと。 PA-API から Creator API に移行するための大きな変更だったので，自分だけで評価・判断するのがちょっと不安だったのだ。

実をいうと PR ページでアサインする AI レビューが使いものにならなかったのであまり期待してなかったのだが，思った以上に使えた。私は，上述の性格診断から GPT-5.3-Codex を常用しているのだが， PR に対するお互いの評価を突き合わせて「議論」が成立したことに驚いた。結城浩さんの『AIと生きる』に出てくる「AI との対話」ってこういう感じなんだなぁ，と実感したのだった。

これで我が家では Copilot はペアプロ相手の新人くんから秘書に格上げになった。 AI で秘書的な役割を演じるものとして思いつくのはグレッグ・イーガンの『万物理論』に出てくるシジフォスだな。私としてはあーゆーのが理想なんだけどねぇ。

サービスとしての秘書

個人で Go 製ツールを書くときは複数の自作パッケージを同時に扱うことが多い。そういう意味で Agents Window は便利そうなのだが，前に述べたようにセッションの複製や fork ができないのはいただけない。あと，複数のセッションを統括する AI セッションが要るよね，たぶん（セッション間の通信？）。秘書はなんぼあってもいいですからね（by ミルクボーイ）。

で，思ったんだけど，これ VS Code から分離したほうがよくね？そもそもエディタや IDE にエージェント機能を組み込むのは筋が悪いと思うのだ。だからこそ CLI インタフェースの AI エージェントが人気なんだろうけど GUI デスクトップでいまさら CUI ターミナル上で動かす意味はないよね。ブラウザ上で動かすのはもっとないけど。

というわけで Agents Window には密かに期待を寄せている。どう発展するのか分からないけど。

あと，やっぱローカル LLM は真面目に勉強しないといけないなぁ。既に AI サービスはメタクソ化が始まってると思う。早めに逃げれるようにしておかないと。

ブックマーク

VS Code 1.121 で何が変わったのか？ Agents・Mermaid・HTMLプレビュー・ターミナル最適化を整理する - Qiita

参考

万物理論 (創元SF文庫): グレッグ・イーガン (著), 山岸真 (翻訳); 東京創元社 2004-10-28; 文庫; 4488711022 (ASIN), 9784488711023 (EAN), 4488711022 (ISBN); 評価

[Comment] グレッグ・イーガンの名作。これも singularity を巡る物語だな。

reviewed by Spiegel on 2017-09-18 (powered by PA-APIv5)

Hugo v0.162.0 がリリースされた【Security fix あり】

2026-05-27T07:01:18+00:00

Hugo v0.162.0 がリリースされた。

Release v0.162.0 · gohugoio/hugo

Go コンパイラおよび関連パッケージのセキュリティ・アップデートがあるのはいつものことなのだが，今回は注意すべき修正がある。

Security fixes and hardening in Hugo

The following changes either fix a concrete issue or reduce the default attack surface of hugo builds.

Disallow text/html content files by default (e41a064). A new security.allowContent policy gates which content media types may be used for pages under /content. text/html is denied by default; sites that rely on hand-authored or adapter-emitted HTML content can opt back in with security.allowContent = ['.*'].

Re-check security.http.urls on every redirect hop in resources.GetRemote (86fbb0f).

Reject symlinked entries in resources.Get (f8b5fa0).

via Release v0.162.0 · gohugoio/hugo

このうち，最初の項目にまんまと引っかかった。こんな感じ：

ERROR error building site: assemble: failed to create page from pageMetaSource 
/remark/2015/gnupg-2-1-8: "/path/to/content/remark/2015/gnupg-2-1-8.html:1:1": 
access denied: "text/html" is not whitelisted in policy "security.allowContent"; 
the current security configuration is:

[security]
  allowContent = ['! ^text/html$']
  enableInlineShortcodes = false
  ...

どうも既定では HTML ファイルを拒否する設定になったらしい。それならば HTML を許可すればいいだろうと， “!” を取って

[security]
  allowContent = ["^text/html$"]

と hugo.toml に書いたら markdown ファイルが全拒否になってしまった（笑）。HTML と markdown のみを許可するには

[security]
  allowContent = ["^text/markdown$", "^text/html$"]

などとする必要がある。ちなみに Hugo では

Create your content using Markdown, HTML, Emacs Org Mode, AsciiDoc, Pandoc, or reStructuredText.

via Content formats

と多様なフォーマットに対応している。この中で HTML 形式を受け入れるのは（malware を埋め込まれたりとか）リスクが高いと判断して安全側に倒したものと思われる。実運用では security.allowContent に，実際に使用するドキュメントフォーマットのみを列挙するのが正しいのだろう。

エラーの出た gnupg-2-1-8.html はこのブログにおける最初の記事で，元々は Movable Type 用に書いた記事で「そのまま読み込ませてコンパイルできるかなぁ」と試してみた記事だった。記事本文の HTML 記述はともかく front matter を整えるのが面倒くさそうなので旧ブログからの移行は諦めたが。今なら変換ツールを AI に書かせたんだろうなぁ（笑）

最近は GitHub Copilot に Hugo のアップデートと redeploy をさせているのだが，今回の障害の分析と対処はすべてお任せで作業を完遂できた。「Hugo のマイナーバージョンアップは問題が出やすいから気をつけて」と指示に添えたのが功を奏したようだ。自力でやったら悩みまくって，ドキュメントを調べまくって30分くらい時間を無駄にしてただろう。いい時代になったものである。

Ubuntu 26.04 LTS へのアップグレード

2026-05-19T03:40:42+00:00

先月の4月に Ubuntu 26.04 LTS がリリースされた。

急ぐ必要はないし，システムがなにか言ってくるまで様子見を決め込んでいたのだが，今朝ようやく通知が来た。

とりあえずパッケージを最新状態にしてから

アップグレード開始。

このウィンドウが出たときに脳内 BGM があの名曲になった（笑）

サードパーティのパッケージについてのアラート。

今はスクショ撮って AI に「何書いてあんの？」って聞けば教えてくれるので，ホンマ助かる。ここは大人しく「はい」を選択して続行する。サードパーティ・パッケージのリポジトリは一旦無効化されるが，アップグレード後に手動で回復させる。

アップグレード自体は特にトラブルなく完了した。

再起動も問題ないかな。

このウィンドウが出たときに脳内 BGM が（以下略）

このあと簡単な設定を行う。

んー。こんな感じかな。バージョン等を確認しておく。

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 26.04 LTS"
NAME="Ubuntu"
VERSION_ID="26.04"
VERSION="26.04 LTS (Resolute Raccoon)"
VERSION_CODENAME=resolute
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=resolute
LOGO=ubuntu-logo

セキュリティ関連ツールもチェックしておくか。

$ gpg --version
gpg (GnuPG) 2.4.8
libgcrypt 1.12.0
Copyright (C) 2025 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/username/.gnupg
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,
      TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

うーん。 GnuPG を 2.5 系に上げる気はなさそうだな。今ちょっと面倒くさいことになってるし，しょうがないか。

$ ssh -V
OpenSSH_10.2p1 Ubuntu-2ubuntu3.2, OpenSSL 3.5.5 27 Jan 2026

OpenSSH も OpenSSL も微妙にバージョンが古い気がするが… まぁいいか。

動作確認で Snap 版 Remmina を起動したら，こんなのが表示される。

あれ？これ設定がリセットされてる？念のためもう一度設定しておこう。

$ sudo snap connect remmina:audio-record :audio-record
$ sudo snap connect remmina:avahi-observe :avahi-observe
$ sudo snap connect remmina:cups-control :cups-control
$ sudo snap connect remmina:mount-observe :mount-observe
$ sudo snap connect remmina:password-manager-service :password-manager-service
$ sudo snap connect remmina:ssh-keys :ssh-keys
$ sudo snap connect remmina:ssh-public-keys :ssh-public-keys

サードパーティのパッケージを作業の覚え書きとして挙げておく。

PPA 版 Git
- Git stable releases : “Ubuntu Git Maintainers” team
GitHub CLI
- Installing gh on Linux and BSD
NodeSource 版 Node.js
- Node.js Distributions
  - v24 LTS 版を選択
pgAdmin 4
- Download
VS Code
- Running Visual Studio Code on Linux
xtradeb applications
- Ungoogled Chromium
- KeePassXC

おー。全部 resolute バージョンに対応してるな。待ってた甲斐があったな（笑）

「ソフトウェアとアップデート」をインストールする

Ubuntu 26.04 LTS から APT リポジトリを GUI で管理できる「ソフトウェアとアップデート」がなくなってしまった。ただ，リポジトリにはあるらしいのでインストール可能。

「ソフトウェアとアップデート」のパッケージ名って何だっけ？よく分からないのでアプリセンターで検索したらあったよ。

ここからインストールして事なきを得た。

多分 Ubuntu 側はアプリセンターに統一したいんだろうけど APT リポジトリ管理が隠蔽されてるのは困るのよ。サードパーティのリポジトリ設定が正しいか確認するのに GUI の「ソフトウェアとアップデート」を使ってるし OS アップグレード設定もこれで行っている。

もうちょっと考えてほしい。少なくとも LTS 版でやることじゃないよなぁ。

ブックマーク

参考

スーパーユーザーなら知っておくべきLinuxシステムの仕組み: Brian Ward (著), 柴田芳樹 (翻訳); インプレス 2022-03-08 (Release 2022-03-08); 単行本（ソフトカバー）; 4295013498 (ASIN), 9784295013495 (EAN), 4295013498 (ISBN); 評価

[Comment] 版元で PDF 版が買える。セキュリティ・エリアにも持ち込めるよう紙の本を買ったのだが，オンライン読書会が始まったので PDF 版も購入。Linux システムの扱い方に関するリファレンス本として優れている。最初に軽く流し読みして，必要に応じて該当項目を拾い読みしていけばいいだろう。

reviewed by Spiegel on 2023-02-11 (powered by PA-APIv5)

SP Silicon Power シリコンパワー USBメモリ 8GB USB3.1 / USB3.0 亜鉛合金ボディ防水防塵耐衝撃 Jewel J80 SP008GBUF3J80V1TJA: シリコンパワー (Release 2017-02-01); Personal Computers; B01MS6RPN2 (ASIN), 4712702655278 (EAN); 評価

[Comment] ブータブル USB 作成用に購入。ひたすらデザインで決めた（笑）以前に同じデザインの 32GB 版を買ったが，最小サイズで買い直した。現在は在庫切れ？状態。

reviewed by Spiegel on 2022-07-17 (powered by PA-APIv5)

AI エージェントとは「もくもく作業」できない

2026-05-10T04:40:39+00:00

（今回は技術的な話は一切ありません。あしからず）

昨年の骨折入院以来「やる気スイッチ」がオフになりっぱなしだったのだが（療養で休職中でよかったよ），先日 pull request を頂いたことで久しぶりにスイッチが入った。

仕事以外で GitHub Copilot のエージェント・モードはほとんど使わない。ここのブログ記事を書く際のタイトル決めやデプロイ作業を手伝ってもらうくらい。でも，折角なのでここは Copilot エージェントに貰った PR のレビューからマージまでやってもらうことにした。ついでに他の goark リポジトリについても少しずつレビュー，修正，PR，マージ，そしてリリース処理までの一連をやってもらっている。

ちなみに Copilot のモデルは GPT-5.3-Codex を主に使っている（これが一番コストと性能のバランスが取れてる）。コード補完やコメント生成くらいなら premium request のコストが発生しない GPT-mini でも十分なのだが，エージェント・モードだとおバカ過ぎて使いものにならない。まぁ，だからこそみんなお金を払って高コストモデルを使うんだろうけど。でも今月はまだ3分の1しか経ってないのに，もう半分以上使ってしまってるよ。散財の予感がする…

プログラマならみんな経験があると思うけど，コードを書いてるとフロー状態というか「ゾーンに入る」ことがある。職場だと周囲の「雑音」のせいでフロー状態を維持するのが難しいこともあるけど，雑音が少ない在宅作業だと一度フロー状態にハマるとなかなか抜け出せず，気がついたら飯も食わんとエラい時間が経ってたなんてことがある（逆に在宅のほうが雑音が多い人もいるかもしれないが）。

だから gogh みたいな作業支援ゲームでポモドーロ・タイマーみたいなのを仕掛けておくというのは意外と有用なのよ¹。コワーキング・スペースや図書館や喫茶店などで作業するってのは集中するための手段じゃなくて集中し過ぎないための手段だと思っている。「もくもく作業」はちゃんと時間を区切ってやらないと。

一方で AI エージェントとの作業は「もくもく作業」にならない。当たり前だ。「対話」してるんだもの。

プログラマ目線で見ると，あれって機械とのペアプログラミングだわ。機械がコードを書いて，横で人間が茶々を入れながら見てるの。

ペアプログラミングってマジでやるとお互いめっちゃ疲れるんだよな。コードを書く側は常に見られながら書いてるからフローどころじゃないし，横で見ている側もコーディング中の相手の思考や作業ペースを邪魔することなく適切に意見を言わないといけない。誰だよ，最初にペアプロはいいとか言い出したやつ！

まぁ，でも，少なくとも相手は機械だから緊張とか気分とかいった精神状態とは無縁だし，間とか空気とか読まなくていいし。対話の途中でマシンから離れて飯を食ってても昼寝してても全然問題ない（笑）むしろ人間側は集中力を酷使して疲弊しないようにしないと。こういうときこそポモドーロ・タイマーだな。

とはいえ，エージェントの自主性（笑）に任せると企業プレゼンみたいなことを言い出したりするので，人間側が目標と範囲と大まかな手順を与えてやらないといけない。まぁ，人間相手でも，そこはあまり変わらないか？

機械は人間の言うことを否定しない。「私は◯◯だと思う」とか「◯◯したほうがいい？」とかいった訊き方をしてノーと言われた試しがない。だから AI は人生相談にとことん向かない。人間の怒りも哀しみも寂しさも機械は全肯定してブーストする。

一方で「A と B のどちらがいい？」みたいな選択肢を与えると，根拠を示してそれなりの意見をくれる（意見が正しいかどうかは別として）。ただし「A と B のどちらがいい？」と訊いても「それより C という選択もありますよ」みたいな応答を返すことはない。機械に sense of wonder を求めてはいけない。

機械は「やれ」と言ったことに対しては規模や難易度や合法・非合法といったことに関わらずやる（またはやろうとする。強制的にガードがかかってできない場合もあるが）。でもその結果に対して「GO OR NO-GO」を判断するのは人間の仕事である。だから，その結果を最終的に実行する判断を機械に委ねるのは間違ってるし，人間が判断できない規模や複雑さを持つ結果を「生成」させてはいけない。 AI が生成した pull request が多くの開発コミュニティで嫌われるのは，量も複雑さも人間の判断の範囲を超えているから。人間社会なんだから，あくまでも主役は人間である。

機械による作業結果が人間の評価・判断を超えそうなら，超えないレベルまで分割すればいい。これも人間の仕事。作業分割とマイルストーンの設計が大事。

GPT-5.3-Codex が賢いと思ったのは，評価観点のひとつが「人間が見て分かりやすいかどうか」である点だ。コードの修正範囲，コミットや PR の単位，後方互換性といったことについて人間側の視点を考慮してくれる。考え方（？）が若干保守的ではあるが，よく躾けられてる印象である。同じようなことを GPT-mini にやらせると，ホンマ無茶苦茶するからなぁ。

GitHub Copilot のエージェント・モードに対する感想でした。オチはない。

参考

ピープルウエア第3版: トム・デマルコ (著), ティモシー・リスター (著), 松原友夫 (翻訳), 山浦恒央 (翻訳); 日経BP 2013-12-18; 単行本（ソフトカバー）; 4822285243 (ASIN), 9784822285241 (EAN), 4822285243 (ISBN); 評価

[Comment] とりあえず図書館で借りて試し読みしたら面白かったので買うことにした。原書の初版が1987年ということで，当時の雰囲気が漂う感じ。アジャイルやスクラムなど現代につながる開発スタイルの源流とも言える本。

reviewed by Spiegel on 2023-02-12 (powered by PA-APIv5)

とはいえオリジナルの Pomodoro Technique の言う「25分」は短すぎると思うけど。『ピープルウエア』によると，通常はフロー状態に入るのに15分程度かかるらしい。なので25分タイマーでフロー状態から覚めるのは全く効率が悪いということになる。 ↩︎

ぞーぺん（ZonePane）で bsky.social 以外の PDS にサインインする

2026-05-08T11:56:43+00:00

以前書いた「そろそろ PDS を個人で管理する時代か？」で「常用しているぞーぺん（ZonePane）も bsky.social 以外の PDS に対応してない」と愚痴ったのだが ZonePane for Desktop v2.9.18 で bsky.social 以外の PDS (Personal Data Server) にもサインインできるようになった¹。ありがたや。さっそく試してみよう。

bsky.social 以外の PDS でサインインを試す

アカウント追加画面に移動して

アカウント追加より

「Bluesky にサインイン」を選択する。

サインインより

折りたたまれた状態ではあるが「サーバー（PDS）」の項目が追加されている。 Bluesky の既定 PDS である bsky.social であればこの項目は空欄でもいいが，それ以外の PDS のアカウントの場合は PDS のドメインを入力する必要がある。

サインインより

これで「サインイン」ボタンを押せばブラウザの OAuth 認証・承認画面に飛ぶ。

Authorizeより

ここで承認すればサインイン完了である。

Bluesky じゃないほうの PDS を利用している方はプロバイダから PDS 名のアナウンスがあるはずなので必ずメモしておくこと。紛失しちゃった場合は PDSls で確認する手もある。

photos.baldanders.info - PDSlsより

デスクトップ版 ZonePane の Mastodon やら Bluesky やらをゴチャまぜにしてマルチカラムで表示するインタフェースはホンマに重宝していて，もう手放せなくなっている。これからもよろしくお願いします。

v2.9.18 は bsky.social 以外の PDS で OAuth 認証した場合に再認証で PDS ドメイン名を忘れてしまう不具合があったが 2026-05-08 にリリースされた v3.0.0 では修正されていた。

ありがたや 🙇

アプリケーションとデータストレージの抱き合わせはリスクか？

今までは，ユーザから見てアプリケーションとユーザデータ（のストレージ）が一体であることは当たり前だった。分散型と言われる Mastodon でさえストレージはアプリケーション・インスタンスの一部になっていて，別のインスタンスに移りたければインスタンス間でデータの「引っ越し」が必要である（引っ越しができるだけマシだが）。

ここで AT Protocol が登場し Eurosky や Periwinkle といったアカウントとデータを専ら扱う PDS サービスが出てきたことで（ユーザから見た）アプリケーションとユーザデータの関係が変わってきているんじゃないだろうか。たとえば Bluesky は利用したいが Bluesky が擁する PDS に自分のアカウントとデータは置きたくない，といったような。

（上の記事によると，コリイ・ドクトロウ氏は PDS を自前で用意したようだ）

私が pckt.blog サービスのアカウント（photos.baldanders.info）を取得するときには深く考えず「ひとつくらい別 PDS のアカウントがあってもいいだろう」くらいの軽い気持ちだったのだが，最近 atproto エコシステムにおいてアプリケーションとデータストレージの抱き合わせは（アプリケーションがなんであれ）リスクなんじゃないかと思い始めている。

というわけで PDS を引っ越そうか悩み中である。

【2026-05-10 追記】

Andorid 版および iOS 版の ZonePane も最新版で bsky.social 以外へのサインインに対応したようだ。

手元のスマホで試したが問題なくサインインできた。

デスクトップ版 ZonePane は現在「お試し版」の状態で Windows, macOS, Linux (Debian, Ubuntu) で利用可能。 ↩︎

VTuber ごっこ

2026-04-28T11:50:41+00:00

前回は Web カメラからの映像をゲーム画面と合成して Zoom に出力するところまでやった。こうなると次は VTuber だよね。

そういや，今って VTuber の定義ってあるんだっけ。まぁ，定義するのがバカバカしいほど意味が広がってるのは確かだけど。日本版 Wikipedia の記事を見ても「結局 VTuber ってなんやねん？」という感想しか出ないし。

日頃お世話になってる Kagi Assistant に「技術寄りに定義して」と頼んだら，こう返してくれた。

2D または 3D の CG アバターを用い、トラッキング技術によって演者の動きをリアルタイムに反映させながら、動画配信プラットフォームで活動する存在

まぁ，この辺が無難だろうな。そして「技術的な構成要素」として以下の3つを挙げてくれた。

モーションキャプチャ（身体の動き）
フェイシャルキャプチャ / トラッキング（表情）
リップシンク（音声同期）

つまり動く CG キャラを使って上の3つの要素を満たせば，一応は「VTuber ごっこ」ができるわけだ。「動画配信プラットフォームで活動」する気はないけど。

既存の Web カメラを使って Live2D¹ のアバターを動かすことはできそうだ。

調べてみたところ（調べたのは AI だが），どうやら Ubuntu で Live2D モデルを動かすには VTube Studio 一択のようだ。 VTube Studio は Steam で提供され Ubuntu では Proton 環境下で動作する（つまり中身は Windows アプリ）。使い方と OBS Studio との連携方法は以下のページが参考になった。

ただし Ubuntu で使う場合，そのままでは Web カメラの映像を認識しないので Facetracker を経由する必要がある²。

flowchart LR subgraph ubuntu [Ubuntu] direction LR Webcam[/"Webcam"/] Facetracker["Facetracker"] subgraph proton [Steam/Proton] VTS["VTube Studio"] end end Webcam e1@--> Facetracker Facetracker e2@-->|OpenSeeFace| VTS e1@{ animate: true } e2@{ animate: true }

Facetracker は Flatpak で提供されている³。

$ sudo flatpak install flathub de.z_ray.Facetracker
Looking for matches…
Required runtime for de.z_ray.Facetracker/x86_64/stable (runtime/org.gnome.Platform/x86_64/50) found in remote flathub
Do you want to install it? [Y/n]: y

de.z_ray.Facetracker permissions:
    ipc    network    fallback-x11    wayland    x11    devices



        ID                                        Branch         Op    Remote     Download
 1. [✓] de.z_ray.Facetracker.Locale               stable         i     flathub      2.0 kB / 4.1 kB
 2. [✓] org.freedesktop.Platform.GL.default       25.08          u     flathub      4.4 MB / 142.4 MB
 3. [✓] org.freedesktop.Platform.GL.default       25.08-extra    u     flathub      3.0 MB / 142.4 MB
 4. [✓] org.freedesktop.Platform.codecs-extra     25.08-extra    u     flathub    869.0 kB / 14.4 MB
 5. [✓] org.gnome.Platform.Locale                 50             i     flathub    147.7 kB / 385.9 MB
 6. [✓] org.gnome.Platform                        50             i     flathub    254.2 MB / 408.8 MB
 7. [✓] de.z_ray.Facetracker                      stable         i     flathub    167.9 MB / 171.4 MB

Changes complete.

VTube Studio と連携させるために，以下のディレクトリに設定ファイル ip.txt を置く。

~/.local/share/Steam/steamapps/common/VTube Studio/VTube Studio_Data/StreamingAssets/

ip.txt の内容は以下の通り。

# To listen for remote connections, change this to 0.0.0.0 or your actual IP on the desired interface.
ip=0.0.0.0

# This is the port the server will listen for tracking packets on.
port=11573

Facetracker を起動するとこんな画面が表示される。

Facetrackerより

Webcam でカメラを指定する以外は既定のままでも動くが Server Settings はそのままだと多分ヤバいので，常用するなら変えたほうがいいだろう。 Server Settings を変えた場合は先程の ip.txt も記述を合わせること。

左上のボタン（アイコンではない）を押さないとトラッキングが始まらないので注意。

VTube Studio にカメラを繋いでキャリブレーションなどの設定をし，背景をグリーンバックにした状態がこれ。

VTube Studioより

VTube Studio にはあらかじめいくつかの Live2D モデルが用意されていて，比較的自由に使っていいみたい（EULA があるので注意）。もちろん自前で用意したモデルも使える。

下の方で小さいのがちょろちょろ動いてるが，これが watermark になってるらしい。 DLC を購入（1,520円）すると消せるそうな。買い切り有り難い。

VTube Studio をソースとして OBS Studio に取り込んでフィルタを設定したところ。

OBS Studioより

クロマキーで背景が綺麗に抜けているのが分かる。 gogh 画面と合わせるとこんな感じ。

OBS Studioより

うんうん。いい感じやね。くたびれたオッサンの絵面がこうなるんだから，そりゃあ VTuber が流行るわけだよ（笑）

さて OBS はだいたい遊び尽くしたかな。 Streamplace を使った gogh 作業配信は気まぐれで続けている。 Bluesky でアナウンスするので，よろしかったらどうぞ。

ブックマーク

RogueRen/Linux-Guide-to-Vtubing: this is a guide to help Vtubers who use Linux or vtubers who want to start using linux - Codeberg.org

参考

VTuber学: 岡本健 (その他), 山野弘樹 (その他), 吉川慧 (その他); 岩波書店 2024-08-28 (Release 2024-08-28); Kindle版; B0DBZ3QP7J (ASIN); 評価

[Comment] VTuber を歴史的観点，理論的観点から記述していく試み。多様な論者が登場してなかなか面白い。Kindle 版も横書きで読みやすい。

reviewed by Spiegel on 2024-09-16 (powered by PA-APIv5)

VTuberの哲学: 山野弘樹 (著); 春秋社 2024-03-20 (Release 2024-04-20); Kindle版; B0D1V1WXRH (ASIN); 評価

[Comment] VTuber を哲学的視点から記述していく試み。固定レイアウトなのでブラウザの Kindle Cloud Reader で読めるの助かる。

reviewed by Spiegel on 2024-09-15 (powered by PA-APIv5)

あくまのかんづめ〜周防パトラのエッセイ集〜: 周防パトラ (著); エムディエヌコーポレーション（MdN） 2024-08-09 (Release 2024-08-09); Kindle版; B0D9LH6CW3 (ASIN); 評価

[Comment] 「個人Vtuber周防パトラは何者なのか？！」を見て衝動買い。泣いていいのか笑っていいのか分からん（褒め言葉）。これを読んで「推しちゃったっ！」を聴くと感慨深いかも。

reviewed by Spiegel on 2024-10-29 (powered by PA-APIv5)

「Live2D」の名称およびロゴは株式会社 Live2D の登録商標だそうな。また，開発用のソフトウェア（SDK および Live2D Cubism Editor）の利用には，利用者の規模や目的に応じた利用許諾契約（End-User License Agreement; EULA）が適用されるとのこと。ちなみに VTube Studio にも EULA が設定されているので利用の際はご注意を。 ↩︎
VTube Studio は OpenSeeFace に対応している。 OpenSeeFace 自体は Python スクリプトのようだが Facetracker が OpenSeeFace のインタフェースを持っているということらしい。ちなみにマイク入力はちゃんと認識するみたいなので，リップシンクは問題ない。 ↩︎
Flatpak は Ubuntu に既定で入っていない。 Flatpak の導入については前回の記事を参照のこと。 ↩︎

OBS 合成映像を Zoom に出す

2026-04-27T09:47:22+00:00

この前の読書会のときに Zoom カメラの背景を gogh のスクリーンショットにしてたんだけど，どうせなら背景が動いたらいいよね。でも Zoom 単体の機能では Web カメラの背景を削除することはできるけど，背景として別の動画を合成するのは難しそう，というかできない？じゃあ OBS Studio の仮想カメラの機能を使って OBS の合成映像を Zoom に出せばいいんじゃないか？というわけで，実際にやってみることにした。

なお，今回のスペックは以下の通り：

PC: ショップブランド PC
- プロセッサ: AMD Ryzen5 PRO 4650G (6 Cores / 12 Threads with Radeon Graphics)
- メモリ: 32GB
- ストレージ: 512GB SSD
Web カメラ: サンワダイレクト 400-CAM086
OS: Ubuntu Desktop 25.10
OBS Studio: 32.1.2 (64 bit)

ゲーム PC 未満のスペックだが，日常的な作業では困らない程度。

Flatpak 版 OBS Studio に換装する

以前 Streamplace でゲーム配信した際は Windows 版の OBS Studio を使ったのだが（その前の gogh 内にストリーム配信したときは Windows 環境だったので），その後 Ubuntu に OBS Studio をインストールして Streamplace に配信できることを確認している。 Windows を入れているミニ PC はスペックが貧弱でゲームと OBS Studio を同時に動かすのは厳しいので OBS Studio は Ubuntu 環境で動かしたい。

いわゆるグリーンバック背景とかの設備無しで Web カメラ映像の背景部分を分離・透過させるには Background Removal (obs-backgroundremoval) プラグインを導入することがほとんど唯一の選択のようだ。 obs-backgroundremoval はバイナリ提供だが Linux 版も用意されている。

ただ，私の環境では obs-backgroundremoval のインストールに失敗してしまった。私は APT 版の OBS Studio をインストールしていて obs-backgroundremoval もダウンロードした .deb ファイルを使ってインストールしたのだが，ライブラリの互換性とか色々と面倒みたいで， Kagi Assistant にも「Flatpak 版を入れるのが一番確実」などと言われてしまった。

Flatpak の特徴

Ubuntu のパッケージマネージャーには主に APT, Snap, Flatpak の3つがあるが，それぞれにメリット・デメリットがある。 Kagi Assistant に簡単にまとめてもらった。

特徴	APT (deb)	Snap	Flatpak
管理主体	各ディストリビューション	Canonical社 (Ubuntu)	コミュニティ (非営利)
依存関係	システム共有 (競合のリスクあり)	自己完結 (独立)	自己完結 (独立)
更新速度	OSのサイクルに依存 (遅め)	非常に速い	非常に速い
サンドボックス	なし (システムに直接アクセス)	あり (厳格)	あり (柔軟に調整可能)
起動速度	非常に速い	やや遅い (圧縮解凍のため)	速い
主な用途	システムツール、基本ソフト	サーバー、CLI、GUIアプリ	デスクトップアプリ (GUI)
透明性	オープンソース	サーバー側がクローズド	完全オープンソース

Snap や Flatpak 版のアプリはサンドボックス内に隔離されているため Ubuntu システムの内部状態との競合を避けることができる（セキュリティ上もより安全）。この特徴は GUI アプリのほうが効いてくるだろう。だから Flatpak 版を入れろと言ってくるわけか。

上の表に対して「オープンソースと完全オープンソースの違いは何？」と訊いたらリポジトリ管理の違いを意図しているらしい。つまり APT の公式リポジトリ管理はディストリビュータの制御下にあるが， Flatpak は flathub も含めて完全にコミュニティによる管理である，ということらしい。なのでオープンソースの定義（Open Source Definition; OSD）とは関係がない。

うーん。ホンマにそんな言い回しがあるのか？

Flatpak の導入

Flatpak は既定では Ubuntu にインストールされていない。ので，まずは Flatpak のインストールから。

$ sudo aptitude install flatpak

$ flatpak --version
Flatpak 1.16.1

よしよし。 OBS Studio を入れるには

$ sudo flatpak install flathub com.obsproject.Studio

とすればいいのだが， Flatpak インストール直後の状態でこれをやると

$ sudo flatpak install flathub com.obsproject.Studio
Looking for matches…
error: No remote refs found for ‘flathub’

と怒られる。そこで flathub リポジトリを参照する設定を加える。

$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

これで準備OK。

Flatpak 版 OBS Studio に換装する

まず APT 版をアンインストールしておく。

$ sudo aptitude remove obs-studio

あとで分かったのだが， APT 版と Flatpak 版はユーザデータの格納場所（構造も？）が異なるため，そのままではデータを引き継げない（手動でコピー&ペーストすればいいのかもしれないが）。

APT 版のユーザデータ: ~/.config/obs-studio
Flatpak 版のユーザデータ: ~/.var/app/com.obsproject.Studio/config/obs-studio

APT 版のユーザデータをすっぱり諦めるのなら remove じゃなくて purge でもいいかもしれない。

改めて OBS Studio のインストールから。

$ sudo flatpak install flathub com.obsproject.Studio
Looking for matches…
Required runtime for com.obsproject.Studio/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/25.08) found in remote flathub
Do you want to install it? [Y/n]:y


com.obsproject.Studio permissions:
    ipc                   network               fallback-x11       pulseaudio       wayland      x11      devices
    file access [1]       dbus access [2]

    [1] host, xdg-run/pipewire-0
    [2] org.a11y.Bus, org.freedesktop.Flatpak, org.freedesktop.Notifications, org.kde.StatusNotifierWatcher


        ID                                            Branch             Op        Remote         Download
 1. [✓] org.freedesktop.Platform.GL.default           25.08              i         flathub        141.4 MB / 142.4 MB
 2. [✓] org.freedesktop.Platform.GL.default           25.08-extra        i         flathub         25.6 MB / 142.4 MB
 3. [✓] org.freedesktop.Platform.Locale               25.08              i         flathub          1.7 MB / 379.0 MB
 4. [✓] org.freedesktop.Platform.codecs-extra         25.08-extra        i         flathub         14.1 MB / 14.3 MB
 5. [✓] org.gtk.Gtk3theme.Yaru                        3.22               i         flathub        139.3 kB / 191.5 kB
 6. [✓] org.freedesktop.Platform                      25.08              i         flathub        201.3 MB / 252.7 MB
 7. [✓] com.obsproject.Studio                         stable             i         flathub        192.3 MB / 202.8 MB

Installation complete.

再ログイン（または再起動）するとアプリの一覧（ダッシュボタンを押すとアイコンの一覧が表示されるやつ）に OBS Studio のアイコンが追加されているはず。アイコンをクリックして起動確認しておく。

Background Removal プラグインのインストール

obs-backgroundremoval のインストールも Flatpak で行う。

$ sudo flatpak install com.obsproject.Studio.Plugin.BackgroundRemoval
Looking for matches…


        ID                                                     Branch        Op        Remote         Download
 1. [✓] com.obsproject.Studio.Plugin.BackgroundRemoval         stable        i         flathub        111.8 MB / 112.0 MB

Installation complete.

インストール後 OBS Studio を起動し直し [ツール] → [プラグインマネージャー] を開いて obs-backgroundremoval がインストール済みで有効になっていることを確認する。

プラグインマネージャーより

Windows 版 obs-backgroundremoval にはインストーラはなく zip 圧縮ファイルで提供されている。

インストールするには zip ファイルを展開し obs-backgroundremoval\ フォルダ以下をフォルダごと c:\ProgramData\obs-studio\plugins\ フォルダにコピーする。

Web カメラ映像の加工

まずは「ソース」に Web カメラを追加する。

ソースの追加より

ソースに追加したカメラの「フィルタ」を開いて「エフェクトフィルタ」から「背景除去（Background Removal）」を追加する（「音声/映像フィルタ」は弄らなくてよい¹）。

エフェクトフィルタの追加より

あとはパラメータをいじっていい感じにすればよい。

背景除去より

（緩く顔出し NG ってことでご容赦。まぁくたびれたオッサンの顔なんか見たくないやろw）

背景の gogh のゲーム画面と合わせるとこんな感じになる。

合成結果より

おー。ちゃんと部屋に居るっぽい（笑）

Zoom へ出力する

OBS Studio 側で「仮想カメラ開始」した状態で Zoom 側のカメラを「OBS Virtual Camera」に設定する。こんな感じ。

Zoom 設定ビデオとエフェクトより

おそらく Discord や Microsoft Teams なども似たような感じで行ける筈。

よし！じゃあ来月のオンライン読書会はこれで行こう。

ブックマーク

APT vs Snap vs Flatpak: Ubuntu Package Managers Explained (and When to Use Each)

他に参考にしたツール

Webcamoid はオープンソース（GPLv3）の製品で Linux を含むクロスプラットフォームでバイナリが提供されている。 Ubuntu では APT でインストール可能だが，専用のインストーラ（有料）が用意されているらしい？

$ aptitude search webcamoid
p   webcamoid                 - full featured webcam capture application
p   webcamoid-data            - icons and locale files for webcamoid
p   webcamoid-plugins         - full featured webcam capture application - plugins

多くのエフェクトを持ち仮想カメラ機能も備える。複数のカメラを同時に管理・切り替えできる。ただ背景除去についてはグリーンバックなどの設備があることが前提のようで（ChromaKey エフェクトなら不完全ながら可能らしいが），今回の用途には合わなかった。

Webcamoid のダウンロードと使い方 - ｋ本的に無料ソフト・フリーソフト
Webcamoid 8.5、Webカメラ用のシンプルなクロスプラットフォームアプリケーション : 現在は v9
ウェブカメラを最大限に活用するための6つの最高のLinuxカメラアプリ : Webcamoid 以外にもいくつかのカメラアプリが紹介されている。

参考

サンワダイレクト WEBカメラマイクなし画角60度フルHD 1080P 200万画素三脚対応 Zoom/Teams対応ケーブル3m 400-CAM086: サンワダイレクト; エレクトロニクス; B08TC3NR9L (ASIN), 4969887781586 (EAN); 評価

[Comment] マイクなんて飾りですよ。エラい人には分からんのです（笑）リモート会議で使うのなら必要十分な性能。

reviewed by Spiegel on 2022-02-05 (powered by PA-APIv5)

色々とググってみると「背景除去」を「音声/映像フィルタ」から追加するみたいな記述ばっかりで「そんなのねーよ！」とひたすら悩んだ。どうも古いバージョンでは，本当に「音声/映像フィルタ」から Background Removal を追加して抜いた背景の色を（緑などに）指定し，その上で「エフェクトフィルタ」の「クロマキー」で指定した色を透過にする手順だったようだ。 ↩︎