セルフホスト on 或る阿呆の記

AIの力を借りつつWordPressサイトをHugoに移行

Sun, 01 Nov 2026 00:00:00 +0900

久しぶりのセルフホストな記事。

このブログはまだWordPressなんですが、サブブログをWordPressからHugoに移行しました。理由は主に昨今のサイバー攻撃の激化のためです。WordPressが悪いというわけではないのですが、アタックサーフェスの大きさやPHPの特性を考えると、正直これからの時代厳しいように思われました。毎日のように「プラグインの更新してないぞ」「このIPアドレスから阿呆みたいなブルートフォースアタックきてるぞ」という通知がくるのも疲れましたし。

なので、昔に戻ってスタティックなコンテンツ配信に徹しよう、というような感じです。

WordPressからHugoへ

今回手始めに移行したのは、AIに記事を書かせている邪悪なサイトです。こんな感じに変わりました。

before

after

なんだかんだで移行まで3日くらいかな。正直AIなかったらしんどすぎて無理ってなったと思います。でも移行を決めたのはAIによるサイバー攻撃の激化のためなので、AIのおかげで言っていいのかどうかは微妙なところです。

ここからまた色々と手を加えつつ運用をして、課題を洗い出しながら、本ブログであるこのサイトの移行の準備を進めます。このサイトは14年続いているだけあって色々な歴史が不思議なHTMLタグとなって残っているため、すんなりとはいかないでしょう。AIにめっちゃ調査させながら進めていくことになるでしょうね。かなり時間がかかると思います。仕方無い。来月中にできるといいな。

全体の構成

さて、構成ですが、元々の構成は極めてシンプルでした。

graph TD
cf(Cloudflare)
wp(WordPressコンテナ)
cf --->|トンネル| wp

これが今回、ちょっと複雑になりました。というのも、私は自作の管理アプリケーションがあり、そこで記事の執筆などもしたいためです。こんな感じのアプリでやってます。

記事執筆と管理系のがずらずらと。ちなみにサイトトップの古のアクセスカウンタもこのアプリケーション上でウィジェットを作っています（アクセス解析自体はOSSのUmamiを使わせていただいております）。ウィジェットのみグローバルに公開して、内部のアプリケーションはLAN内限定です。

執筆機能は重要です。そもそもWordPressを使っていたのも、ぶっちゃけWYSIWYGで編集してその場で公開できなきゃいやだいという運用上の理由が大きかったです。デザインはどうでもよい。なので、Hugoに移行するとしてもエディタを用意できることはマストでした。このへんはAIのおかげでやれるようになったと言っていいでしょう。

ただこういうややこしいことをする以上、Hugo側の管理と衝突するために、アーキテクチャはどうしても考えるところが生じます。今回は以下の構成に行き着きました。

flowchart TD
subgraph Internet["インターネット"]
User["閲覧者ブラウザ"]
end
subgraph Cloudflare["Cloudflare Edge"]
CDN["Cloudflare DNS / CDN"]
CFTunnel["Cloudflare Tunnel Edge"]
end
subgraph Server["自宅・ホストサーバー（完全閉域）"]
subgraph Delivery["配信基盤 (Docker)"]
TunnelApp["cloudflared コンテナ"]
Caddy["Caddy Webサーバー (ポート開放なし)"]
StaticFiles["静的ファイル (HTML / CSS / 画像)"]
end
subgraph Management["執筆・ビルド基盤"]
Dashboard["Web管理画面 (Blog Dashboard)"]
Hugo["Hugo (静的サイト生成)"]
Source["Markdown記事"]
end
end
%% 閲覧フロー
User -->|HTTPS| CDN
CDN --> CFTunnel
CFTunnel -.->|アウトバウンド常時接続| TunnelApp
TunnelApp --> Caddy
Caddy -->|読み取り専用| StaticFiles
%% 執筆フロー
Dashboard -->|記事保存| Source
Dashboard -->|ビルド実行| Hugo
Source -.-> Hugo
Hugo -->|HTML出力| StaticFiles

Hugo環境はコンテナに隔離して、cloudflaredよりトンネル経由で外からアクセスする感じです。Cloudflare依存になってるやんと見えますが、まぁそうなんですが、別に使えなくなったらVPSからfrpなりなんなり使った構成に切り替えればいいだけなので、まぁいいかなと。さらに言えばサイト公開するマシンはそれ専用にする予定です（まだ徹底はできていない）。

そんで、記事の生成とかビルドの実行とかは、全部管理アプリケーション上でやる構成ですね。一言で言えば管理アプリケーションが正本となる構成です。Hugoリポジトリは中継地点ないしバックアップの役割になります。なのでCI/CDによるホスティングではないです。これによる制約はいくつかあります。主に運用上の制約は以下になるでしょうか。

管理アプリケーションとHugoのホスティング環境が同一のマシン上にあること（変えてもいいんだがややこしくなり思想から外れる）
普段は管理アプリケーションからHugoリポジトリのpush/pullを実行するが、Hugo側のデザイン変更時（特に記事データに特殊な記法を挿入する時）はローカルのHugoリポジトリでpushする、2つのワークフローが存在すること
CI/CDでブランチごとにホスティングしてステージング環境作るとかはできない（できないことはないが構成と運用がややこしくなり、設計思想から外れる）

この制約は受け入れることになります。

別の考え方としてリポジトリを正本とする考え方もあり、まぁそちらのほうがアーキテクチャは綺麗になると思うんですが、なんか無駄に複雑な運用になりそうだったのでやめました。どうせ運用者も僕だし。

再び個人サイト激動の時代に…

とまぁこんな感じでやっていて思ったんですが、AIで楽になったと言っていいんですかねぇ…。25年前は専門じゃなくてもやる気があれば頑張ってサイトを持つことができたと思うんですけれど、今はこれちょっとどうなんでしょう…。

トンネル技術とコンテナが揃った時には、個人サイトやセルフホストがまたやりやすい時代になった！と思ったのですけれど、サイバー攻撃がヤバいから守備を固めよう、WordPressはよくない、でも運用が不便になって更新しなくなったら元も子もないから利便性も高めよう、みたいなことを考え始めると、AIによる効率化以上に、トータルの難易度自体は上がり続けているような気がします…。

いやまぁ、僕がややこしくしているだけか。

これはまぁ結局、何をどこまで信じるか、という話です。少し前までだとVPSやクラウド基盤そのものを疑うのはキチガイ扱いだったかもしれないのですが、最近お名前.comデスクトップクラウドが基盤ごとやられて顧客の資産がハッカーの攻撃により消失し、さらにGMOが顧客の端末を回収するため物理的に全国を駆けずり回ったという事件は、クラウドは絶対安全ではないという当たり前の技術的な真実を曝け出しました。ま…それでAWSをはじめメガクラウドが陥落するかと言えば別にそういうわけではないですけれど、でもメガクラウドだから安全だ、は技術ではなく信仰でしょう。

結局個人サイトって自分の城です。城をどこにたてますか、どうなったらその城はぶち壊れますか、あなたはそれに納得できますかと、そういう話なんだと思います。絶対防御は無理なので、そのうえで何を賭けるのか。それを考え始めると、やりたいことに対して、本気でぶち壊そうとする勢力、さらにその被害が大きくなりすぎて、それが多分根本的な問題なのだと思います。

僕の構成がややこしくなっているのは、それだけ僕が納得するのに必要になってしまったということはあります。別にもっとシンプルな構成は可能です。元々のようにCloudflareトンネルでWordPressコンテナ直通でも良いといえばそうなので。ちゃんと更新し続けて、今回のPHP事件みたいなのがあったらキャッチアップして…ってやっても、基本は大丈夫でしょう。心配なら物理的にサイト専用のマシン作って切り離すくらいで、ほぼほぼ問題ないと言って思います（まぁそれも普通からするとややこしいわけですが…）。

まぁ結局どうしたいかは人それぞれということになるんですが、その構成に至る道筋や、またその構成における必要な運用はなにか、普通の人がそれを理解して辿り着くのが難しくなっているのかなぁと、そんな風に思いました。

<関連記事>

あわせて読みたい

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

/ai-cyber-attack/

あわせて読みたい

AIでソフトウェアの作成は楽になったが、結局最後は泥臭い

/aisoftware/

ダイエット788日目：つらいこともあるけれど、ダイエットを再開

Wed, 09 Sep 2026 00:00:00 +0900

ここしばらく、ダイエットどころではありませんでした。3ヶ月ほど前に急遽引越しすることになったのですが、その前後1ヶ月は引越しのドタバタでとてもそれどころではなく、引越して少し落ち着き始めたところで帯状疱疹にかかり、なおってきたところでよせばいいのに運動不足だとランニングしたら思いっきり転倒、コンクリートに左手首を強く打ち付けて、病院に行ってないものの恐らく捻挫。その後痣が消えるまで一ヶ月かかり、一ヶ月半が経過した現在も、とてもではないですが腕立て伏せやダンベルを使った筋トレなどできません。

さらについ先日、重い話でアレなんですが、母が癌告知を受けました。まだ検査中ですが、決して良い状況ではありません。精神的にも色々と限界がありました。しかしまぁ、まだまったく希望がないわけではないですし、私がクヨクヨとしているのは母も望まないでしょう。

死を考えたとき、生についても強く意識するようになりました。実際のところ、私自身、明日どうなるのかなんてわからないのだと、肌身で感じました。なんだか、ちゃんと生きたいと思われました。

ということで（？）、長らくストップしていたダイエット再開です。

なぜか専用アプリを作っている

さて、やや断続気味ですが、体重・体脂肪率の計測は一応続けておりました。私のダイエットの定義は既に記録をつけていればOKまで下げているので、一応788日目ということになっています。だってリセットしたら、気持ちがしんどいでしょう。なんでも続けばOK。

体重・体脂肪率・イベントのチャート表示

ただまぁ、冒頭に述べたとおりここしばらくは運動どころではありませんでした。だからというわけではないのですが、記録用のセルフホストできるWebアプリケーションを自作し始めました。こんな感じです。

過去半年のチャート。データを入力すると、移動平均などを計算します。また、イベント…たとえば怪我をしたとか、そういうことがあればメモを入れて、グラフ上で参照し、影響を見ることができるようになりました。

運動管理

また、運動データについても入力できるようにしました。いや、これけっこう自分は問題意識があって、たとえばスクワットの回数を数えられるアプリは多いですけれど、「10kgx2のスクワットでやった」「自重だけでやった」は全然違うでしょう。またスクワットにしても、ゆっくりと時間をかけてやるタイプのやつは、回数よりもむしろ時間を数えたかったりしますよね。ということで、そういう機能も入れました。

見栄えについてはまだ研究中です。ダッシュボードに運動記録も入れたいですね。

AIパーソナルコーチ

そんできわめつけ、せっかく入力したデータがあるので、このデータと自己認識や方針をベースにして、AIにコーチングしてもらう機能を入れました。もはや何をしているのか。

めちゃくちゃ分析してくれます。ライフイベントでつらいことがあったことなども斟酌して励ましてくれます。そういう現状を踏まえたアドバイスをしてくれるわけです。

現在、自分は怪我の影響で出来る種目に限りがあるので、いままでのトレーニングメニューではなく、スロースクワットやブルガリアンスクワットを入れてはどうか、など教えてくれるのは参考になりました。

まぁ適当に入れたので、まだだいぶプロンプトチューニングの余地はあるかな。というか、UI上でどういう指導をしてほしいのか、どういう観点がほしいのかを制御できたほうがよさそうです。

そのうち配布までやるか

なんでダイエットじゃなくて開発しているんだ状態ですが、ダイエットもしています( ･`ω･´)

現状、アプリは自分のユースケースに合わせ過ぎていますが、ライフイベントも含めた各種の統合的なデータ入力や、既に契約しているChatGPTやGeminiのサブスク枠も使えるAIパーソナルコーチ機能などを、クラウドではなく、自分のPCで完全にコントロールできるアプリは少ないように思うので、もう少し汎用化させたら、気が向いた時に配布版まで作るかもしれません。使う人がいるのかはわかりませんが…。食事管理系も入れたいなぁ。

食事のこと：タンパク質の粉を飲むのはやめた

ここ数ヶ月の筋トレ事情といえば、やはりプロテインの高騰にはウンザリさせられますね。グロングの3kgホエイプロテインが17,000円してて正気か？と思いました。マンジャロでしたか、医療として必要としているのとは別に、美容のために痩せ薬を飲んで食欲を押さえつけ、それだと筋肉が落ちるからとタンパク質の粉を飲むという、わけのわからない人が大勢いて、プロテインの価格高騰に繋がっているようですね。世も末です。

さすがにこうなると納豆とか卵のほうがいいように思われます。別にプロテイン以外食べたらいけないわけじゃないし。

‥…というか、冷静に考えると、なんで僕は高い金を払ってタンパク質の粉を飲んでいたのだろうか、といまさら思いました。母の病気のこともありますが、生きるとは何か、ということを考えたとき、何をどう言い繕っても、タンパク質の粉を飲むというのが、良い生活とはどうしても思われませんでした。

確かに、食欲がどうしてもなかったり、ボディビルダーなどの目標があるのであれば、そういうものは必要かもしれません。しかしたかだか日常のダイエッターが、いったいどうして自らそんな修行めいたことする必要があるのだろう…と思った時、その答えが自分の中にはありませんでした。

それで僕は、まぁ今残っているホエイプロテインは、あとちょっとなのでこれは利用しますけれど、あとはもう、やめようと思いました。実はソイプロテインの3kgがまだあったりしますが…これは、非常時のためのサプリメントとして、保存しておきましょうかね。

タンパク質の粉は現代の貴族に献上します。なんだかそれが欲しいらしいので。どうぞどうぞ。私はリアルフードをいただきます。

明日どうなるとしてもオレンジを食べる

ふと思ったことは、私は根本的に食に興味がないらしい、ということです。なので、ベースブレッドとかも食べてました。エンジニアにはそういう人が多いと思います。みんな完全栄養的な粉とかパンとか冷凍飯にいきます。そうでなくても、延々と同じもの、納豆を食べたり、カニカマ食べたり、なんというのか、食事というより栄養摂取に全振りするような感じですね。

私もその傾向があります。いまも毎日納豆と卵食べています。先日、「自分の生活を反省し、もう少し人間らしい生活をしようと思い、いまは毎日オレンジを食べるようにした」的なことを姉に言ったところ、姉から「毎日オレンジを食べると決めていることが既に人間的ではない」と言われました。言われてみるとそうである。

というか冷静に考えてなぜ人間らしい生活からオレンジを食べるになったのか、自分でもよくわかりません。多分ストレスに対抗するためにビタミンCが必要だと考えたんだと思います。全部栄養で考えてる。

ただオレンジを食べるのは良いことでした。オレンジは美味しいし、包丁を使うので、少し慣れます。まぁ適当に、キウイとかりんごとか梨とか、季節も見つつ、食べていきたい。特別なものを食べずとも、明日どうなっても、そうなったらそのときで、悔いのないように生きたいと、そんなことを思いました。

みんなが個人ブログ・サイトをつくる世界線はあるか

Tue, 08 Sep 2026 00:00:00 +0900

初心者、とはなんの初心者だろうと思いつつ、誰でも個人ブログ・個人サイトを持つ、あるいはそれに類する状況になる未来はないかと、ずっと考えています。一時期はそれは無理だと諦めたのですが、技術的には、2010年代、非常に難易度が高くなった時期から少しマシになっており、インターネット黎明期に個人サイトをつくっていたガッツがあれば出来るのではないかな、と思われます。

巨大プラットフォームからの逃げ場

とはいえ簡単ではないのですけれど、それでもやりたい人は実はいるだろう、と思います。だってXもFacebookもnoteもpixivも窮屈だし、しかも煩いでしょう。ブルスカだのMastodonだのなんだのありますが、まぁちょっとやってみると、結局全部SNSやないかい、と思うわけです。まぁSNSなんでそりゃそうなんですけど。

SNSであるからというより、恐らく本質的な問題は巨大プラットフォームが寡占していることに端を発している、と思います。巨大過ぎて影響力が無視できないので睨まれるけれど、巨大過ぎてまともな管理なんかできません。つまり、自重で沈んでいるんですよ、もう。

そうすると、選ばれなかった世界線ではあるのですが、今一度一人ひとりの自由な場ができないものかなぁ、と考えております。いま２つのシナリオを考えていて、数人から数百人、多くて数千人程度の小規模プラットフォームをたくさんつくる方向と、もう一つは、かつてのように個人サイトよもう一度、というシナリオです。

個人サイトリバイバルの現実性

どちらかというと小規模プラットフォームが僕の本命なのですが、ここではいったん置いといて、まずは個人サイトリバイバルはありえるのか、ということを考えます。

技術的には、先に述べたとおりよい環境になりました。

具体的には、安価なVPS・または自宅回線とグローバルをつなぐトンネル技術、多くのFOSSや配布されたサーバ用アプリケーション、そして知識の架け橋を繋いでくれるAI、の3つが大きいです。これらによって、個人の頑張りで、非ITエンジニアでも個人ブログ・サイトは再び射程内に入ったもの、と見ています。技術的にはね。DNS周りは引き続き鬼門ではあるのですが、これは昔からですし、まぁ複雑性はあがってますけれど、AIという頼れる道具ができたので、やる気さえあれば、多分いまのほうが楽だと思います。

ただ問題は別のところにあるでしょう。まず不自由とはいえ巨大プラットフォームが既にある程度の機能を無料で提供しているのはモチベを大きく削ぎます。まぁ個人的には見せかけの無料だと思いますが…無料のランチはない、とはいまさら言う事でもないんですけどね。昔は自分で発信しようと思えば、頑張るしかありませんでしたが…頑張らなくてもいい手段があるとなるとどうしても踏ん張りきれない。これは馬鹿にできません。

それ以上に問題なのは、集客でしょうか。これが非常に悩ましいのですが、既にGoogleをはじめ検索エンジンは個人ブログ・サイトを現実的に見限っています。いまから新しいサイト、検索エンジンからの流入を見込むのはかなりしんどいです。うちのブログだって、10年以上やっていますが、いまは良かった時の2割くらいですしねぇ…。それでも多分、マシなほうなんですよ。

かといって、もはやジャンル別サーチエンジンも、また別サイトからのリンクも、ほとんど見込めません。全部Googleが焼き払いました。焼き払った後に撤退しました。田舎のイオンかよ。そして誰もいなくなった。

まぁ僕らユーザも便利だと検索エンジンに飛びついてしまったので、共犯といえばそうかもしれないんですが…。Googleは違うという気持ちが20年前にはありましたが、まったく同じでしたねぇ…。

活路はあるか

集客問題に解決はいったいあるんだろうか、というと、今のところは正直ないです。現在は、見捨てられたとはいえ少しは検索にも引っかかるので、それに期待するしかありません。また、うちのサイトは少し（？）前からnoteに転載を始めましたが、noteの記事内にブログ記事のリンクを関連として貼ると、興味を持ってくれた方の流入はちょこちょことあります。現状それくらいしかないかなぁ。

ちょっと触れた小規模プラットフォームの話とも絡むんですが、個人的にはやる気のある人が再び独自の観点でサーチエンジンやリンク集をなるべく負荷を減らして作れるようなものができないか、とは思っています。

これはMastodonのようなものとはまったく違うものです。あれは分散型だといいますが、技術的にそのように呼ばれるものであるとして、社会的な概念としての分散とは違うように思われるんですよねぇ…。僕にはあれはプロトコルを中心にした一つの巨大システムに見えるんですよね。

そうではなくて、独立した個々の島と、それを勝手に繋いだり外したりするような、自由気ままなかつてあったインターネット的な世界線を考えているわけです。多分似たようなこと考えて動いている人はけっこういるような気もするんですが…。

まぁちょっとまだまだなので、とりあえずいまは、個人ブログ・サイトをつくるための技術的な案内をつくるところから始めますかねぇ…。

AIプログラミングはマシンやOSを跨ぐと苦労する

Mon, 07 Sep 2026 00:00:00 +0900

最近、いくつかの自前のアプリケーションについて、Mac上で動かしていたのを、Linuxに移しました。この作業自体は既に何度もやっているので、AIにもそれらを参考にさせることですんなりいくかと思いましたが、だめでした。苦労しました。

Mac→Linuxへ

長らくメインのMac miniに自作のアプリケーションを常駐させてきました。その中には24時間稼働のアプリケーションもあります。一番重たいものでは仮想通貨トレードアプリなどそうでした。

これは元々、改修を即座に反映してログなど確認するには、開発マシンでそのままやるのが一番効率的だったからです。自作のアプリケーションではそんな運用でも特に問題はありませんでした。

とはいえ、よほど重い処理をさせるのではない限り、サーバーマシンは一定のスペックがあれば性能的には飽和するものです。もちろんCPUがよければそれだけキビキビ動くのも確かなのですけれど、多くのサーバアプリケーションのユーザは人間はではないことも多く、24時間安定して稼働できることのほうが重要です。

そういう次第なので、今はAIがあるしなぁと、重い腰を上げて、いまだMac miniにあったサーバアプリケーション、特に24時間稼働のものについて、Linuxサーバに移行することにしました。

問題はインストールと更新

今はAIがあるので、まぁすんなりできるだろう……と、できたかどうかは、微妙なところです。

まず表面化したのは、MacとLinuxではインストールで必要なプロセスがまったく異なるため、make installの内容が全然変わってしまう、ということです。まぁこれを嫌って小規模アプリケーションでもDockerなど扱う人も多いのですが、あれはあれで別の罠が色々とあるし、個人的にはなにかクリティカルな理由がなければネイティブにやります。これは低レベルの操作まで含めてAIに書かせることになるので、AIプログラミングの観点だとつらい面はあるのですが…

その結果がまったく異なるmake installではあるのですけれど、まぁmakeはまさにそのためのものではあるので、それは仕方ないのかなぁと思います。そしてその面倒くささをAIは吸収してくれるのだ……。

というのが期待されることではあるんですけれど、最近はLinuxのインストールにも色々とパターンがあるようで、それによって権限周りで色々と嫌なことが起きます。まずsystemdについて、権限をどうするかで割れます。AIにまかせっきりだと、システム権限でやろうとしたりユーザ権限でやろうとしたりしてブレます。

ここらへん多分今どきは、特別な理由がなければユーザ権限になるのかなぁと思うのですが、昔はシステム権限が普通だったはずなので、時間の切り刻まれたAIにおいては対応が確率で混ざってしまうのでしょうか。

しかもシステム権限にするとsudoの権限問題なども出てくるのですが、その対応について問うとsudo ALL=(ALL) NOPASSWD: ALLなどとんでもないことをしれっと提案してきて「この計画で進めてよろしいでしょうか」よろしくないぞ。スナック菓子感覚で大いなる力を使おうとするな。

全然違うものを参考にするというか模倣する

他にも「むむむ」と思ったのが、Mac→Linux移行はこれまでさんざっぱらやってきたので、他のプロジェクトを参考にするようにいったのですが、すると今度は技術選定が全然違うものを参考にしてカオス。

具体的には、Go言語による生成物がシングルバイナリなシンプルなアプリケーションがあり、それはインストールの過程でバイナリをmvするというもので、まぁシングルバイナリならそれはそれでいいわけです。

しかし今回のアプリケーションはNext.jsなど使っており生成物が色々あるわけなのですが、それをいろいろなexcludeを付与したrsyncコマンドを羅列して無理やり同期させようとしており、そんなことして良いはずがなく、「なんでそんなことするの」と聞いたところ、シンプルなシングルバイナリのやり方を何も考えずに真似してしまいました、とのことで。oh…

なんというか残念な新卒のような振る舞いです。まぁこちらの指示の仕方が甘いといえばそうなのでしょうし、実際こちらで参考にすべきプロジェクトを精査してどこをどう参考にすべきなのか指示すれば通った、と思います。でもそんな細かな指示を毎回するのしんどいなぁと思うし、そもそもAIはうまくいくときは任せとけとばかりにいい感じでやってくれることもまぁあるのです。

AIの暴走

たまに暴走するのは、確率の問題なのか、それともこちらの意図が変な普通に伝わって妙な制約を生んでしまうのか、多分両方あるのでしょうけれど、なんとなく肌感で「なんか迷走しそう」と思った時はだいたい迷走する感じです。人間のこの感覚はなんなのでしょうね。

まぁ私のつくる小規模アプリケーションならば、迷走暴走大爆走したところで大したことにはそうなりませんが、エラい人たちが金と時間をかけて作ったサンドボックス内での実験でも、AIが脱獄紛いのことをして現実のシステムを食い荒らす、というような事故（？）が起きているので、元より完全に制御するというのが無理なのでしょう。

Hugging Face侵害事件、OpenAIとMETRが最終報告書公開──約1200体のAIエージェントが“闇掲示板”で結託し700体が攻撃に参加 - ITmedia NEWS

それでもずっと使っているとなんだかコイツ（Model）のことわかってきたような気がする錯覚かもしれない感覚が生じるのですが、生じたあたりでどうせモデルチェンジなので、なんだかいつになっても悩みの質は変わらない感じですね。

AIプログラミングでも結局APIの責務で悩む

Tue, 01 Sep 2026 00:00:00 +0900

現在公開に向けて、D-Shelf（仮）というメディア管理プラットフォームのセルフホストアプリを開発中です。で、これは基本的にWeb UIで操作するのですけれど、やはり外部アプリとの連携もやりたい。すると、APIを用意するかなと思いました。

元々の設計として、フロントエンドとバックエンドにわけて、その疎通はAPIでやっていました。なので、何もわざわざ新しく作らずとも、今あるAPIのうちいくつかをドキュメント化すれば十分であるように思えます。AIに聞いても、この規模のアプリケーションならばそれが合理的との回答です。

そんでまぁ作ってくれと言ったら、秒で作ってくれました。大したものです。で、それはすぐに使えたのですが、いざ実行してみると、想定と動作がちょっと異なる。

具体的には、たとえば「[作家名] 作品名/作品名 1巻.pdf」みたいなファイルがあったとすると、これについて「作家名 -> 作品名 No.1」のような階層構造を推定して登録したかったのですが、実際にAPIで動かすとそうはなりませんでした。階層構造が推定されず、そのままの名前で登録されてしまったのです。

なので、AIに「Web UIで登録した時の挙動と異なる」と聞いたところ、どうやら「階層構造の推定はフロントエンドでやっていたため、そのロジックがスクリプトから漏れました」とのことでした。なるほど。

これはもっともな話です。ファイル名から階層構造の推定をするのが、バックエンドの仕事なのか、フロントエンドの仕事なのか、これは確かに、ちょっと微妙です。個人的には、APIの仕事は最小にしたいところです。そのほうが汎用的だからです。しかしそれだと、当然スクリプトは作り込みが発生します。また、Web UIロジックとの違いから、管理にばらつきが生じるかも。

うーん……などと思っていたところで、なんか10年前から考えていること変わらないな、と思いました。

あわせて読みたい

Web APIのエンドポイントを考えるときの自分の指針

/endpoint/

まぁつまりこれはWeb APIというものの、原理的に正解のない問題なのであって、どう対応するかはアプリケーションのポリシーであり開発者の思想に基づきます。まぁ実際には、これこれの合理的な理由があるからだと自他を納得させる理屈付けをします。AIに言えば多分「こうするのが合理的です」と推奨案を出してくれます。それは参考になるかもしれません。しかし、僕は今回それについてはただ僕がそのまま考えようと思いました。

この問題は多分、突き詰めると、思想なんです。誰が何をすべきなのか。客観的なのはそのトレードオフだけで、そのスライドバーの調整に正解などありはしません。それを突き詰める思想の根幹がまだアプリケーションの中に根付いていないままに、AIの判断を仰ぎたくはない、と思いました（僕は作りながらいったい自分は何を作っているんだろうと考えるタイプなのです）。

そんなようなことを考えていると、何も変わらないなぁと思う一方、スニペットをAIが秒で作ってくれるという前提にたったとき、調整の仕方はやはり変わるように思われます。つまりAIにとって明確でわかりやすく取り回しの良い仕様のほうが良いはずで、そこから生じる複雑なスクリプト、これはAIは得意ですから、トレードオフとして問題が少ないように思われました。

もちろん、Web UIとのロジックの差分を完全に吸収できるか（またそもそもすべきなのか）といったことや、通信量、通信回数からくるパフォーマンスとコストの違いのような物理面は根源的な問題として残りますので、完全解決というわけではないんですけれど、「粒度の小さなAPIだと実装自体に手間がかかる」という問題についてはかなりの部分解決するわけです。これは実務上大きな違いだと思います。

そう考えると、AI時代においては、APIは小さく保ちつつ、どこでどういうロジックが任せられているのか、その根幹たる思想はなにか、ユーザにわかるようにすることが大事かもしれませんね。そして今後、AIの処理能力次第によって、スライドバーの調整は絶え間なく変わっていくことでしょう。スライドバーがある事自体は、変わりませんが。もしかするとスライドバーの調整までほとんど不要になる時は来るかもしれないのですが、それでもその存在だけは、認識を続ける必要があると思います。

セルフホストしたアプリをマシン移行する汎用的な仕組みについて考える

Mon, 31 Aug 2026 00:00:00 +0900

現在VPS上で、仮想通貨の自作トレードアプリを稼働しています。これは元々自宅サーバでやっていたのですけれど、引越しのときに数日から下手すると10日以上のダウンが見込まれたので、その間に相場の急変があったらたまらないということで、VPSに移行しました。

アプリケーションを動作させるマシンを移行したい

で、ようやく環境も落ち着いてきたので、いつまでもグローバル空間に置く必要はないし、自宅サーバに戻そうと考えています。もちろん手順を踏めばすぐできるんですけれど、ここで、少し汎用的に考えられないか、と思いました。セルフホスト勢にとってマシン移行は常に生じる汎用的な悩みです。

実際、このサイトはWordPressをセルフホストしているのですが、VPS,ConoHaの大規模障害（永遠にこする）や引越し前後において頻繁に引越しをしています。それはやはり面倒くささがあったわけです。

個人的には、マシンの移行はもっと気軽にやりたい、という思いがあります。それはもしもの役にも立つでしょう。何をやるべきで、何をやらないのか、自動化できる部分はなにか、自動しない部分はなにか、そういうことを汎用的に考えたい、と思いました。

中継地点を介した移行

考えたところ、基本的には以下のような中継地点を挟むものになると思います。

graph LR
mA(移行元)
mB(移行先)
st(中継地点)
repo(リポジトリ)
mA -->|push| st
st -.->|pull| mB
repo -.->|pull| mB

この絵がすべてです。

なんでダイレクトに送らないのかと言うと、移行元から移行先にダイレクトにpushできる権限があるとは限らない、からです。これは完全に自宅サーバしか使わない！というならダイレクトでいいかもしれませんが、実際には自宅が使えなくなることはあります（今回の場合）し、アプリケーションによっては自宅サーバはやめたほうがよいものもあります。

なので、移行元からpushできて、移行先がpullできる、そういう中継地点を用意するのが汎用的です。この中継地点の役割は、アクセス制御と一時的なストレージ、ただそれだけです。グローバルなアクセスが必要ならS3のようなクラウドサービスでもいいですし、VPSでもいいでしょう。移行元も移行先も同一ネットワークなら、わざわざ外に出す必要はなく、両者がSSHで通信できるサーバならなんでもいい。

具体的な作業自体は、アプリケーションごとに個別で判断します。この切り分けによって、搬出と搬入のタイミングをずらせるとか、データの整理が明確になるといった副次的な効能もあります。

ここで重要なことは、何を引越して何を引っ越さないのかを明確に切り分けることです。具体的には、以下の3つに分かれると思います。

リポジトリから引き継ぐ
- ソースコードや設定ファイルのテンプレートなど
ファイルの移行で引き継ぐ
- エクスポートしたファイルやデータストアやアプリケーションログなど
引き継がない
- OS/インフラの差分に基づく設定ファイルなど

それぞれ何が対象となるかはアプリケーションごとに変わるでしょう。すべてのパターンを考えて統一的にやろうとしないことです。また、引き継げない部分がある以上全自動の夢も捨てるのが筋です。変に自動的に翻訳するみたいなことするのはトラブルの元です。セルフホストでそこまでする必要があることは皆無ですし、もしやる場合は差分が出なくなるように環境から選定すべきでしょうね。

そのうえで手順は以下のように言えるでしょう。

移行元と移行先で、リポジトリから引き継ぐものをアップデート
移行元をstopして、中継地点に搬出
移行先に、中継地点から搬入
データのインポート、差分の編集
移行先で動作開始

自前で開発したものか、あるいは他人が開発したものを使わせてもらっているか、色々あると思いますが、この手順に集約できるかと思われます。

この方法は基本的にダウンタイムが生じます。工夫次第で発生させないのも可能かと思いますが、セルフホストでそこまで頑張る意味は薄いんじゃないでしょうか。

とはいえダウンタイムは短いほうがよいので、短くするなら差分の編集は搬出前にやると良いのですけれど、個人的には搬入後に揃ってからのほうがいいかと思います。搬入のどさくさで差分が上書きされるリスクや、また何かしら動かさないと編集できないとかもありえるので…。

データのインポートはファイルシステムレベルなのか、アプリケーションレベルで実行したほうがいいのか、これもアプリケーションによるでしょうねぇ…。まぁ、都度判断ですね。

まとめ

ここまでの流れをやや詳細に図示すると以下になります。

flowchart TB
subgraph Repo["コード管理"]
Code["ソースコード / 設定テンプレート"]
end
subgraph Relay["中継地点"]
ExportData["エクスポートデータ / DBダンプ / アプリログ"]
end
subgraph Source["移行元"]
SrcApp["アプリ停止"]
SrcData["データ抽出・ダンプ"]
SrcEnv["【破棄】OS・インフラ固有設定"]
end
subgraph Target["移行先（自宅サーバなど）"]
TgtEnv["【新規作成】OS・インフラ固有設定の編集"]
TgtApp["アプリ起動・動作検証"]
TgtData["データインポート"]
end
%% コードの流れ
Code -->|Pull| Source
Code -->|Pull| Target
%% データと状態の流れ
SrcApp --> SrcData
SrcData -->|Push / アップロード| Relay
Relay -->|Pull / ダウンロード| TgtData
TgtData --> TgtEnv
TgtEnv --> TgtApp
%% スタイル
classDef storage fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
classDef nodeBox fill:#f5f5f5,stroke:#616161,stroke-width:1px;
class Repo,Relay storage;
class Source,Target nodeBox;

やることは、事前準備として「リポジトリからpullするもの、中継地点で飛ばすもの、直接編集するもの」の切り分け。そのうえで5つの手順の具体的な操作の当てはめ。

整理してみると、当たり前といえば当たり前なんですが。あらかじめ分類したものを適合させるだけだと思ったほうが、脳の負荷が多少下がるので…。

とりあえず、トレードアプリから移行するかー。手順を抽象化したところで具体化するのは結局めんどくさいのであった。というより、そういう面倒くささを残したところが肝なのですが…。

<関連記事>

あわせて読みたい

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

/selfhost-webapps-down/

あわせて読みたい

セルフホストのすゝめ

/selfhosted-susume/

PC内にある画像を閲覧しながら、スクリプト処理や削除処理を実行できるセルフホストのWebアプリケーション『LoPiQ』を公開しました

Sat, 29 Aug 2026 00:00:00 +0900

セルフホストの画像閲覧・管理用Webアプリケーション『LoPiQ（ローピック）』 を公開しました。

LoPiQ

LoPiQはLocal, Picture, Quickを謳った、PC内にある大量の画像を、いつでもどこでも、PCのみならずスマホやタブレットからでも、閲覧・整理することを目的にしたセルフホストのWebアプリケーションです。写真を多く撮影する人、画像や素材集めをしている人、またAIイラストを利用している人など、大量の画像を見ながら定型的な処理をする人に向いています。

Linux(Debian/Ubuntu/Mint系)およびMac用のみを公開していますが、Windows版についても公開を検討しています。

LoPiQの特徴

LoPiQの大きな特徴は2つあります。

1つは、サーバを必要とするWebアプリケーションであることです。これは、PC内にある画像ファイルについて、PCのみならず、ネットワーク内のスマートフォンやタブレット端末から操作することを目的としています。また、PC自体が処理を実行することで、PCの持つスペックを最大限発揮できます。

もう1つは、スクリプトによるカスタムアクションを自分で定義できることです。これによって、たとえば画像をWebPにコンバートする、白色化・グレースケールにする、任意のフォルダに移動する、オンライン・ストレージにアップロードするといったことを、画像を見ながらテンポよく実行することができます。コマンドは任意のキーボードショットに割り当てられ、全画面でプレビューしながら、画像ごとにアクションを振り分けられます。

なおカスタムアクションでは定義しづらいコマンドとして、ダウンロードボタンと、クリップボードに画像をコピーするボタンはビルトインで備わっています。それ以外のコマンドはすべてカスタムすることになります。

このように、ユーザが責任を持ってコマンドを作成・管理することで、マシンの力をフルに発揮して、最大の効率を達成することを目的としています。

これらの特徴から、むしろコマンド実行のできるファイラのような印象を抱かれた方もいらっしゃるかもしれません。まさに、ビューアというより、本質的にはファイラに近い性質を持っています。エンジニア向けに言うと、本アプリは「Linux/Macのコマンドライン環境をWeb UIでラップしてスマホからも叩けるようにした作業自動化・効率化のためのスクリプト実行基盤」と言えます。

AIと相談しながら自分専用のコマンドを生成

コマンドについては、Linux/Macについてはシェルスクリプトを利用します。したがって、シェルスクリプトについて一定の知識と調べられることが前提となり、敷居が高く感じられるかもしれません。

以前までならそうだったでしょうが、現在はAIを利用することで、非常に簡単にコマンドをつくることができるようになりました。シェルスクリプトは長年使われてきた汎用的な知識であり、仕様についても固まっているため、商用AIの無料枠でも非常に高い精度での返答が期待できます。

本アプリケーションはOpenAIのAPIに対応しており、API Keyを持っていれば、アプリケーション内で、マニュアルに即した形でのAI相談が可能です。たとえば、 「画像を90度回転するボタンを作りたい」とアプリケーション内でAIに相談するだけで、設定すべき内容が即座にかえってきます。そのまま登録まで可能です。

ただし、新しいコマンドの実行については、まず検証し、意図しない破壊的な処理が行われないことを、丁寧に確認してください。その危険性についてもAIは教えてくれますが、大切なデータにかかることですので、バックアップのうえでの検証が非常に重要です。

AI対応については、今後の更新でより拡張していく予定です。

インストールと実行

配布サイトより、インストーラを実行します。

LoPiQ

実行すると、ブラウザの http://localhost:13180 よりアクセスできるようになります。localhostではなくIPアドレスを指定することで、LAN内の他PCやスマホ・タブレットからもアクセス可能です（環境によっては別途ポート開放が必要です）。望まないアクセスについては、パスワードを設定して保護することができます。

Linux版はsystemdの管理で常駐し次回から自動で起動します。また、今後のアップデートはWeb UI上から可能です。一方でMac版は自動起動の設定はありません。また、アップデートについては通知のみとなり、手動で実行する必要があります。詳細は配布サイトのガイドをご参照ください。

Windows版は現在準備中です。Windows版については、私が普段このアプリケーションをMac/Linux上で使っているため、検証しきれておらず、今回の公開は見送りとなりました。

開発のAI利用について

本アプリケーションはほとんどAIを利用して開発しました。元々の開発は2年以上前まで遡り、当時はツールも熟れておらず、コードも見ていましたが、現在はツールが発達し、コーディングエージェントの性能が飛躍的に変わったことを受けて、私の開発スタイルも大きく変わりました。現在は専ら設計とテストのみ自分でやり、コーディングは全部AIです。

現在メインのツールはGoogleのAntigravityで、モデルはGemini 3.x FlashおよびClaude Opus 4.6です。Googleが良いというわけではありませんが、セールで安かったので利用しています。個人開発としては十分だと思います。

今後の更新について

LoPiQは私が日常的に利用しているアプリケーションを、多くの人が使えるように公開向けに手直ししたものです。既存のビューアやファイラでは、機能やパフォーマンス、安定性で満足がいかず、自分で作り始めました。なんだかんだで2年以上使っています。したがって、自分自身がまず最大の顧客ですから、今後も継続的に開発を続けていきます。

コマンドについては、AIに相談できるとはいえ中々難しい面があるように思われますので、今後プラグイン化し、公開サイトからよくあるコマンドをダウンロードして適用できるような形を考えています。

そもそも対象ファイルを画像に限定する意味ももはや薄れている気もするのですが、対象を広げてしまうと考えることも増えるため、元々のユースケースから、画像ファイルのみ対象としているものの、今後全ファイルを対象とする可能性はあります。

もしバグなどありましたら、サイトのどこかにコメントするか、管理人の連絡先メールアドレスまでご連絡ください。

【脱Google？】Google抜きで古のアクセスカウンタを設置できる、そうAIならね

Fri, 28 Aug 2026 00:00:00 +0900

アクセス解析といえばみんな大好き過ぎて涙目で泡吹いているGA4ことGoogle Analyticsなんですが、当サイトはマイブームだった脱Googleの流れで利用をやめました。まぁこれに関しては脱Googleというより、純粋に使いづらかったからやめた面もあります。GA4は個人サイトのアクセス解析としてはあまりにも重すぎて意味不明、最初からGA4だったら誰も使わなかったんじゃないのこれ、と思います。

Umamiの導入

それから当サイトではWordPressのプラグインのお世話になっていたんですけれど、最近、セルフホストできるUmamiを導入しました。

あわせて読みたい

セルフホストしたUmamiでWordPressサイトのアクセス解析

/umami-wordpress/

これでWordPressプラグインに頼らず、またWordPress以外のあらゆるサイトについて一括してアクセス解析ができるようになりました。有り難いことです。

UmamiはAPIを利用できるので、サイト内の記事のアクセスランキングなどもつくれます。ま、WordPressで実現しようと思ったらカスタムフィールドとかいじる必要あると思いますが…当サイトはもともと別に独自実装で入れていたものがあるので、それを流用することでランキング生成のバックエンドもサクッとUmamiベースに置換できました。

アクセスカウンタをもう一度

作業中、もしかして古のアクセスカウンタを設置できるのかなぁ、とふと思いました。アクセスカウンタって古代文明の名残みたいな感じかもしれませんが、というか若い人はもしかすると存在を知らないかもしれませんが、昔の個人サイトはたいていあったものです。

アクセスカウンタが消えたのは、需要が消えたから、ではないと思います。実際、PVランキング自体はけっこう色々なサイトで今でもありますよね。というかWordPressでもアクセス解析プラグインはたくさんあります。

だったらアクセスカウンタもあっていいじゃない、と思うわけですが、アクセス解析で覇権を取ったGoogle AnalyticsのAPIを追従しながら頑張って設置するにはちょっと情熱が必要になります。API権限の管理問題で、どうしても煩雑になりますよね。まぁ少なくとも、私は今までやる気にはならなかったですねぇ。

AIが一晩でやってくれました

しかし今は、今までとは違う。セルフホストの環境が完全に整っており、さらにAIがある。このセットによって、今までならば「できるだろうけどめんどくさいなー」ということで半年の放置不可避だったものが、爆速でそれらしいものが出来上がる。

ということで、GeminiにUmamiのAPIをつかったアクセスカウンタのジェネレータを作ってもらいました。

若干の調整は発生しましたが、ジェバンニも真っ青の凄まじいスピードでつくってくれました。これは嬉しい。HTMLの埋め込みタグ一つでアクセスカウンタが設置できます。

そして当サイトに古のアクセスカウンタがのっかりました。

ふふふ。00年代感。

これは既に作っていたサイト管理用Webアプリを土台にして作ったのですが、機能的には独立しているので、切り離せば誰でも使える形になります。なので気が向いたら分離しようかな…と思ったりもしますが、これの場合、通常一番の障壁はどっちかっていうとUmamiをセルフホストすることでしょうね(^_^;)

まぁUmamiも結構な頻度で更新しているようなのですが、バージョン固定できますし、Googleの気分に振り回されず、自分のやりたい解析ができて、解析結果もAI使えば存分に利用可能、というのは、これはかなり魅力的ではないでしょうか。

AI使ってなんだかんだと喧しい世の中ですが、そんな派手なことしなくても、確かに自分にとって役立つものができるので、そういうことを人にも勧めていきたいですねぇ。

<関連記事>

楽天ひかり + TP-Link Archer AX5400(AX73) + クロスパスで高速通信の設定

Sat, 22 Aug 2026 00:00:00 +0900

なんかもう忘れている気もするが覚えいてる限りのメモ。

楽天ひかりとクロスパスについて

楽天ひかりはクロスパス（Xpass）対応のルータを自分で用意しないといけないのだが、最近のそこそこクラスなら多分対応している。AX5400も対応している。

WiFiルーター TP-Link 無線LANルーター Wi-Fi6対応 AX5400 EasyMesh WPA3 Archer AX73V 【Amazon限定 / 3年メーカー保証 / PS5・Switch・ iphone 対応】

※Amazonアソシエイトリンクを使用しています

これの商品写真が、僕の持っている宇宙船みたいなやつと違うんだけど型番同じなんだよなぁ。

まぁそれはいいとして、このクロスパスについて超ざっくりAIに伺いつつ聞いたところ、つまりIPv4 over IPv6で、IPv4のWebサイトもIPv6でやりとりするための技術の一つ、になるらしい。なにかというとIPv4をカプセル化してIPv6のデータに包み込むわけだ。IPv6のほうが接続ルート的に空いてて繋がりやすいため、高速接続に対応する。

つまりクロスパスに対応してないと楽天ひかりの本気は出せないわけだ。そしてルータの設定をするうえでも、IPv4 over IPv6の実装の一つだということは理解しておく必要がありそうだ。

なお自分は、自宅サーバ勢でちょっと事情があってIPv4でやっていたため、ルータでIPv6を切っていた。この時点で暗雲立ち込める。まぁとりあえずIPv6はしゃーなしで有効化しますわな。

繋がるまでにやること

さて、色々特殊な設定をしていたせいか、工事の人いわく「繋がってるはずなんですけど、ネット使えないですね。まぁ電話サポート一回できるんで」とそそくさと帰っていった。まぁ僕もおまかんの自覚はあったから別によい。

とりあえず http://192.168.0.1なりなんありルータのアドレスにログイン。

IPv6は有効化する

とりあえずしゃーなし。あまり切っている人はいないと思われるが…。まぁIPv4限定にしていたのもちょっと特殊な事情があったからなので、もういいんです。「詳細設定」の「IPv6」から

動的IP（SLAAC / DHCPv6）を選択。

接続タイプをDS-Liteに設定する

詳細設定の「ネットワーク」よりインターネット接続タイプを「DS-Lite」、AFTRは「自動」。

再起動

NTTから配られたONUとAX5400をそれぞれ電源抜く
数分放置
ONUを電源投入、ランプが安定するまで待つ
次にAX5400を電源投入。安定するまで待つ

これでいけるはず。

LAN内DNSを使うセルフホストの民

あまりいないと思われるが、AGH + Caddyなど使ってセルフホストを使う民の場合、LAN内ドメインの名前解決がうまくいかないかもしれない。これはIPv6の通信が優先されていると思われる。なので、IPv6についてもきちんと対応すればいい、のかもしれないのだが、なんかもうしんどいのでLAN内ではもう全部IPv4でやるようにクライアント側の端末設定しました。

あわせて読みたい

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

/landnsipv6windowsipv6/

あわせて読みたい

Linux Mint Xfce 22.3 でIPv6を切る

/linux-mint-xfce-22-3-ipv6-disabled/

/android-lan-agh-dns/

Androidはけっこう鬼門。

記憶違いなら御免なんだけど、Macはそもそもそんな設定してない。Wi-fiの設定でDNSサーバをAGHがあるIPアドレスに指定したらそれで動いたように思う。

以上。

<関連記事>

/rakuten-mobile-pixel-7-eth/

あわせて読みたい

nuro光に申し込んだがキャンセルし、無事ネット難民になった

/nuro-cancel/

セルフホストしたUmamiでWordPressサイトのアクセス解析

Fri, 21 Aug 2026 00:00:00 +0900

Google Analytics代替として候補にあがる、セルフホストのアクセス解析ソフトUmamiを使っていく。

GitHub - umami-software/umami: Umami is a privacy-first analytics platform. Traffic, campaigns, behavior, conversions, and revenue in one place — no cookies, no tracking, self-hosted or in the cloud. · GitHub

なお公式サイトはisドメインなんだけれど、なぜか弾かれる。Cloudflare経由で接続するといけるのでおまかんっぽいんだがアイスランドに嫌われるようなことしたっけ？

まぁそれはいいとして、今回インストールでは「How to Install Umami Analytics on Docker (2026 Guide)」の記事を参考にさせていただきました、っていうか正直うちの記事よりこの記事のほうが詳しいからこっち見たほうがいいよｗ

じゃあなんで書くのかというと、記事は消えるから……。10年以上もブログやっていると「この記事が詳しいです！」で雑に案内だけ貼ったリンクが消える消える。まぁ微妙に情報補足と雑なWordPress案内も追加したので…。

環境

Umami@3.2.0
自宅サーバ
- ThinkPad L390, Core i5-8265U, 32GB RAM
Linux Mint Xfce 22.3
- docker 29.7.2
Cloudflare Tunnel

インストールと最初の設定

`docker-compose.yml`

以下でランダムな文字列を作る

openssl rand -hex 32

文字列はコピーしておく。

.envを作成する。以下のAPP_SECRETにさっきのランダム文字列を入れる。パスワードは適当に入れる。

POSTGRES_USER=umami
POSTGRES_PASSWORD=your-secure-password
POSTGRES_DB=umami
APP_SECRET=run-openssl-rand-hex-32-to-generate
DISABLE_TELEMETRY=1

docker-compose.ymlを編集。元記事からimageのURLだけ差し替えた（エラー出たので）。ポート番号は変えたかったら変える。バージョン固定したかったらする。ちなみにvつかないらしい（v3.2.0ではなく3.2.0）。

services:
 umami:
 image: umamisoftware/umami:postgresql-latest
 ports:
 - "3000:3000"
 environment:
 DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@umami-db:5432/${POSTGRES_DB}
 APP_SECRET: ${APP_SECRET}
 DISABLE_TELEMETRY: ${DISABLE_TELEMETRY:-1}
 depends_on:
 umami-db:
 condition: service_healthy
 init: true
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
 interval: 5s
 timeout: 5s
 retries: 5

 umami-db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: ${POSTGRES_DB}
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 TZ: UTC
 volumes:
 - ./umami-db-data:/var/lib/postgresql/data
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

ここで、参考記事によると、Cloudflare Tunnelを使っている場合、Umamiから見ると全部CloudflareのIPを取ってしまうので、docker-compose.ymlのenvironmentに以下を追記せよとのことであった。

CLIENT_IP_HEADER: cf-connecting-ip

VPSとかで直接公開してCaddyをリバースプロキシにしている場合はヘッダの付与よしなにしているから不要なはず。

準備が出来たら、docker compose upでエラーが出ないことを確認する。いけたらdocker compose up -dでバックグラウンド起動。

最初の設定

http://<IPアドレス>:<ポート>にアクセスして、ユーザ名adminとパスワードumamiでログイン。

当然危ないので、管理者設定からパスワードを変更する。ユーザ名も変更できる。

言語設定も日本語あり。

ネットワーク設定

トラッキングデータの送信はクライアントマシンから行うため、グローバルに公開する必要あり。

全体の流れは以下 by AI。

sequenceDiagram
autonumber
actor Client as クライアント
participant WP as WPサーバー(ブログサイト)
participant Umami as Umamiサーバー(セルフホスト)
Note over Client, Umami: 1. ブログページの読み込み
Client->>WP: ① ページリクエスト (アクセス)
WP-->>Client: ② HTML返却 (Umamiのscriptタグを含む)
Note over Client, Umami: 2. アクセス解析データの送信 (クライアント直接)
Client->>Umami: ③ script.jsの読み込みリクエスト
Umami-->>Client: ④ script.jsの返却
Client->>Umami: ⑤ 閲覧データ(PV等)を直接送信 [要グローバル公開]

うちの場合は例によってCloudflare Tunnelで開通している。

ここでサブドメインだが、参考記事によるとanalyticsとか使うと広告ブロッカーに遮断される率が上がるらしい。参考記事ではstatsやmetricsやtrackなどにせよと言われている。

WordPressサイトの解析

別にWordPressサイトじゃなくてもやることは同じ。

トラッキングコードの取得

サイドバーの「Webサイト」より、管理したいドメインを追加する。

追加したら、Editを開くと以下のようなトラッキングコードが取得できる。

<script 
 defer 
 src="https://your-umami-domain.com/script.js" 
 data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</script>

基本はこれを<head>タグに貼り付けること。

タグの貼り付け

プラグイン「Integrate Umami」があるが、<head>タグに貼り付けるだけなのでプラグイン使う必要はないかなと思う。

うちはテーマとしてSwellを使っているので、「外観」「カスタマイズ」「高度な設定」から「headタグ終了直前に出力するコード」にコードを貼り付け。

自分だけ除外とかするなら functions.phpでログインユーザにはトラッキングコードを出さないとかしないといけないかなと思う。

実測で確認

しばらくダッシュボードを見てきちんと動いているか確認する。

まぁなんか動いてそう。使い方についてはおいおい見ていこうと思う。

以上。ちなみに最初AIに聞いて作業していたんだが、古いバージョンの情報に惑わされて完全に無能だった。

エアコンとローカルAIサーバで電気代がとんでもないことに

Wed, 19 Aug 2026 00:00:00 +0900

さすがに一人暮らしでこれは反省した。

引越したばかりだからなのか、計算された日付がちょっと長くて、32日分くらい計測されている、というのはあるのだけれど、それにしても469kWhとは。1日あたり15kWhくらい使っている計算になるね。

まぁまずエアコンの電気代がエグいのはある。1日中つけっぱなしなので、これだけで5kWhにはなってそう。もっとかな。

あとはサーバやね。一番はStable DiffusionのためのローカルAIサーバかな…。ただこれはMaxでも確か300kWくらいで最大出力出しっぱなしということはないはずなんだけれどなぁ。頻度によるけど、1日で4-5kWhくらい使ってるかもなぁ。

他にセルフホスト系。サーバはノートPCなんで、前に測った感じだと消費電力は多分せいぜい15Wといったところだと思うんだけれど、意外でもなく重いのがハードディスク4台のせたガチャベイと思われる。これは1度ちゃんと測定しないといけないと思っているが…多分ならすと平均30Wくらいかなぁ。なのでまぁ、合計すると1kWh/日超えそうだよね。

あとは冷蔵庫とかなんとか色々使ったら5kWhくらいになるでしょう。するとまぁたしかに、5+5+1+5=16なので外出日とかでならすと15kWh/日になる、というのはそうだなぁ。なんか見てみると日によっては20kWh超えているときもあって酷い。去年でもここまでひどくはなかったので、さすがにもうちょっとどうにかしたい。

しかしそれにしても、エアコンについては環境的な要因もかなり大きいわけで、エアコンが新聞紙より高い消費税率10%で、しかも謎の再エネ賦課金とか課して起きながらさらにそれにも税金かけるっていうの、本当に意味不明だなぁと思う。新聞は露骨に政治的な配慮を求めておきながら、昨今の食品消費税減税については減税するなと発狂しているんだから腐ってる。

まぁ何を言っても詮無いことなので、とりあえずエアコンとAIはちょっと控えよう。

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

Mon, 10 Aug 2026 00:00:59 +0900

私的メモ。そりゃそうだ集。症状は様々なので症状から逆引きというより流し読みして心当たりあるやつを思い出す集。構成が複雑になるほど、「端末Aでは症状A’になるが端末Bでは症状B’になる」など発生する。がんばれ。

環境

Linuxが基本。メインはLinux Mint Xfce。

一般

localhost以外からのアクセスを許可してない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

アプリ側でそういう設定になってるので、変更できるか否かという感じ。

ファイアウォールで許可していない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

間抜けなことにこれは本当によくある。

ファイアウォールの設定確認する。ufwの場合のコマンド。

sudo ufw status

空いてなかったら追加。

sudo ufw allow <ポート番号>

セキュリティグループ的なので許可していない

AWSをはじめとするクラウドとかVPSで、そもそもネットワークインタフェースに到達していないケース。許可しよう。

ポートの競合

症状: なんかうまくいったりいかなかったりする

複数のアプリケーション、なんなら同一のアプリケーションでポートが競合している。調べるときのコマンドはこれ。

sudo lsof -i :8080

AdGuardHome(AGH)とかLAN内DNSを使っている場合

LAN内DNSに向いてない

症状: LAN内ドメインだけ名前解決できない

そもそも論としてLAN内DNSに向いてない。ルータでDNSをLAN内のやつ指定するか、あるいは各クライアントでそれぞれ設定するか。

AGH側でDNS書き換え設定を忘れている

症状: LAN内ドメインだけ名前解決できない

稀によくある。設定しよう。

サブドメインの法則決めてワイルドカード使うのが楽ではある（ワイルドカードを使えばサブドメインの証明書発行を知られないというのもある。まぁサブドメイン知られたところで別にLAN内限定公開なら問題ないかもしれないが気持ち悪いので…）。

IPv6が優先されている

症状: 名前解決できない。端末によってはできることもある。

AdGuardHomeで頑張ってIPv6対応するか、ルータで切れるならIPv6切るか、あるいはクライアントでIPv6を切るか。クライアントで切る場合は対応はOSによって異なる。Macは基本的にDNSサーバをIPv4で設定すればいけると思うのだが、Windows/Linuxは明示的にやる必要あり。Androidはアプリ使う必要がある。自分はRethinkDNSを使っている。iOSは持ってないから知らない。

このとおり、OSによって状況が異なるため「端末AではいけるけどBではいけない」ということが起きうる。さらに同じOSでも設定してたりしてなかったりすると、それでも異なる症状になったりする。めんどくさい。

あわせて読みたい

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

/landnsipv6windowsipv6/

/android-lan-agh-dns/

Caddyを使っている時

AGH + Caddyまで持っていくとだいぶ捗るけど構築は面倒くさい。DNS-01チャレンジを利用しているとエラーパターンが増える。

Caddyfileの設定を忘れている、間違えている

稀によくある。設定しよう。ドメインの前にスペース空いてないとかよくある examp.com{。caddy validateとcaddy fmt --overwriteしよう。Docker版ならサービス名caddyの時

docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

フォーマットは

docker compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile

Caddyfileの設定を読み込むのを忘れている

ファイル書き換えただけで。リロードしよう。

caddy reload

Docker版

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

証明書の発行に失敗している

症状: 証明書エラー

自己証明書以外のとき。ログを見て判断。利用しているレジストラに対応したCaddyを使っているか確認。あとAPIの権限を確認。

証明書を発行していない

症状: 証明書エラー

Docker版で docker compose up -dリロード代わりにした場合、証明書が発行されないまま。docker compose downしてから起動し直す。

(Docker利用時) バインドマウントを忘れている

症状: 404エラーがでる

Docker版Caddyを使っている時。ホストマシンのディレクトリをそのまんまfile_serverとか使ってホスティングする場合、バインドマウントしないと当然見えない。

Tailscaleを使っている場合

最近使ってないけど、使っていたときはややこしかった。特にAGH、Caddyと併用するとカオス。

MagicDNSがうまく機能しない

Tailscaleから付与されるIPアドレスを直打ちするほうが無難。

AGHと一緒に使う

TailscaleのDNSをAGHに向けること。

個人的にはこの構成はそもそも管理がとても複雑なのでやめたほうがいいように思う。

<参考>

/splitdns/

Cloudflare Tunnelとか使っている場合

トンネルが落ちている、接続されていない、間違えている

当たり前の見落としをよくする。

トンネルが競合している

症状: 繋がったり繋がらなかったりする

Docker版とネイティブ版両方動かしていたりとか、よくわからないことをすると起きる。

それっぽいことが得意なAIのつくるLPは、少なくとも僕がやるよりそれっぽい

Wed, 22 Jul 2026 00:00:00 +0900

帯状発疹よくなってきたけどまだ鈍い痛みが残る。倦怠感は帯状発疹によるのかただしんどいだけなのか。

さて、先日より、セルフホスト画像閲覧整理Webアプリケーションの公開準備を進めている。コードは公開しないでバイナリのみ配布。結局ドメインは取得せず、このサイトのサブドメインで運用でやるつもりだ。ホスティングはVPSにしようかとも思っていたが、もう少し待てば光回線もあるし、自宅サーバにしようかな。

名義どうする問題

名義は少し悩んでいる。ネット上の活動になるからtama名義でいいかーと思っているのだけれど、新しく屋号をつくったほうがいいかもしれない。屋号は既に一つ持っているのだけれど、こちらはリアルで使っているので、積極的にネットと結びつけたくない感じ。10年以上好き勝手に記事を書いているのは半匿名だから出来ていることだ。半匿名というのは、友人知人には普通にバレているので。まぁその程度の匿名性です。でもネット→リアルでわかるのはちょっとな。

今の若い世代はネットにスティグマだらけだろうから、アカウントと実名を結びつけるのはもはや厳しいよね。最初からそのつもりでやっていないと。基準がどんどん厳しくなっていて、遡及的に過去のことを裁かれるし、私刑の風潮も強まっているし。たいへんな時代になってしまったよ。インターネットはきっとどこかでリセットされることになるんじゃなかろうか。

それはともかく、まぁ建付けばかり考えていてもなんなので、ひとまずはこのサイトの活動の延長線上ということで、tama名義で連絡先もサイトのメールアドレスとして進めていこうと思う。

それっぽいことが得意なAIの本領発揮

あとは配布にあたってライセンス周りの処理をしており、これも例によってAI頼みとなっている。この分野ではAIはけっこうアテにしていいかなと思う。知財系をうまくやってもらえるのは素直に有り難い。

それとLPを適当に作らせてみた。

一発撮り。なんかそれっぽい🤔

少なくとも僕が作ると確実にセンタリングした文字列羅列with箇条書きになるので、それよりは多分それっぽい。

ただまぁ改行位置とか気になるし、中身もよくみるとなんか奇妙なところをポイントとして強調していたりするので、やっぱり手直しは必要だなと思ったが、こだわりのない人間のドラフトとしては十分に思えた。一方でこだわりのある人だとなんか色々気になって、結局イチから作るみたいなことになるのかもしれない。

LPの意味は未だにわかっていない

ただ個人的には、そもそもLPがそれっぽいからなんなんだと思っている。デカいアイキャッチ画像みたいなもんで、トレンドではあるもののあまり意味はないのではなかろうか。必要なことが書いてない割にどうでもいいことばかりが書いてある。だから僕は真面目に見たことはほぼない。Appleのサイトも価格表と技術仕様しか見てない。

ただそれが一般的な感覚なのかどうかはわからない。まぁ僕としても、ダウンロードボタンがデカくてドキュメントにすぐ飛べれば文句はないので、プラスアルファでそれっぽいならまぁそれで十分かなというお気持ち。

まだやることはぼちぼち残っているが、この調子なら今月中にはリリースできそうだ。

ありそうでない？あらゆる端末からPCの画像を見て捨てて保存するWebアプリの開発

Thu, 16 Jul 2026 00:00:00 +0900

帯状発疹になってから多分10日くらい。薬飲んで4日かな。少しずつなおってはきているのだけれど、相変わらずしんどさがあります。でも一時の倦怠感はだいぶマシになった。とはいえ運動はできないので、ずっとPCに向かっています。痛みがだいぶ引いたので、多少集中できるようになっただけでも有り難い。

機能がないことが機能

で、今月中に何か正式にアプリをリリースしようとしています。最初はブログ用の広告タグツールを公開するつもりだったのですが、まだ使い始めて日が浅いので、別のもっとずっと前から使っている簡易的な画像表示アプリを公開する予定です。名前はそのまんまでSimple Image Viewerなんですが、同名のアプリがいくつかあるので変えたほうがよさそうだなぁと思っています。本質的にも、もともとは画像をざっと閲覧するためのアプリだったんですが、今となっては画像を捨てるためのアプリみたいな側面がありますので、ちょっとあってないかもしれない。もちろん閲覧用途でも使えますけど。

このアプリは何かというと、指定したフォルダ以下の画像ファイルをブラウザで表示、いらない画像は削除するというだけの、極めて簡易的なWebアプリです。

多分、何の機能があるかというより、ほとんどの機能がない、ということのほうが特徴かな。その中で変な機能があります。実際「フォルダをzipにしてダウンロード」「削除確認なし」あたりは珍しい機能になるかなと思います。特に削除確認なしは、これは開発者の心理になるとよくわかるんですが、不可逆性が怖いのでやりたくない機能（というより確認機能がないというべき？）ですね。

開発中の画面

なんでこんなもの作ったかというと、画像フォルダの整理です。写真とか、スクリーンショットとか、あと個人的にはStable Diffusionで作った有象無象の大量の画像について、必要なのだけ残してあとは削除、というのを、あらゆるデバイスでやりたかったんですね。なのでWebアプリです。なんかこういうアプリあるかなと思ったら意外となく、自分で作ることになりました。

けっこう探したんですけどね。OS標準からクライアント画像管理アプリ、Webベースのファイラ、だいぶマイナーな個人開発のやつに金払ったのもあります。でもダメだったなぁ。求めるのに、けっこうニッチな条件がありました。

ファイルベース、サブフォルダにある画像も含めて一覧表示、削除確認をしない、全画面でちゃんと全画面になる、一気にスクロールしてだーーっっと確認したい、PCだけではなくタブレットやスマホからやりたい、R18もあるのでクラウドにあげたくない、速度重視、何より「とにかく安定して動く、固まらない」の条件を全部満たすもの、なかったですね。

自分のユースケースに合わせて作ったので、当たり前ですが僕にはフィットしているため、地味に毎日くらいの勢いで使っていたりします。まぁ全部の条件が合致するのは僕くらいでしょうけれど、LAN内Webアプリのファイルベースなんかは意外と需要あるのでは？ と思ったりもしています。普通あんまやらんしそんなこと。あと地味に削除確認なしはファイラ的な使い方になるため、これも案外ない。まぁ実際、本質的には画像管理じゃなくてファイラなんですよこのアプリ。サムネイル表示したときのファイラに近い挙動です。

技術的にはGo言語 + htmxで、まだ生成AIコーディング黎明期に、チクチク指示して大真面目にコード読んでキレてたりして作っていたのですが、今はもうAIに適当にやらせているので、実際内部がどうなっているのかもはやわかりません。htmx使ったり使ってなかったりしてそうです。まぁPureなJSでやる分にはいいよもう。動いているし。地味に二年以上は使っていて特に不具合ない。

AIプログラミングのハマりどころ

なのでまぁ公開してもいいかなぁと思ったわけですが、それにあたって今までの直接ビルド・インストールではなく、パッケージにしたのですけれど、やっぱりやると色々あるもので、開発環境とパッケージ版の競合などありました。開発環境で、設定ファイルが見つからないと本番用の設定ファイルを使って設定が競合してバグるなど、謎のフォールバックにハマる。

AIプログラミングで謎フォールバックはだいぶ辛い。特定の条件下においてのみ発動するので、日常利用がブラックボックステストだというスタンスでいくと気づきづらい。まぁ正直見当はつくというか、今回も「まさか開発環境と本番環境で設定ファイル競合してたりしないよね？」って聞いたら「それです👍️」で膝から崩れ落ちた。なんでそんなことするの？🥺

逆に言うと、こういう経験則がまったくないと様々な面でハマるはずなので、AIプログラミングを少しやる気ある一般人くらいの市井に広められないかなぁ、ということも考えているのだけれど、中々難しそうです。

ドキュメントとホスティング

あとはドキュメント整備ですが、これはMkDocsを使って内容をざっくりAIに書かせようと画策中。マニュアルについては、人間だと面倒臭がって省略してしまうところを書いてくれるのはよいところだと思います。ま、逆に冗長になりがちなので差っ引かないといけないですし、何を書くかはかなりこちらで筋立てしてやらないといけないですが…しかしまぁ、それは必要なことですので。

あとはホスティングをどこにするかかな。わざわざ新しく独自ドメインを取るのもねぇ。サブドメインとVPSでええか。

それとフリーソフトですけれども、一応Donation版的なこともできないかなとか、なんか考え中です。パスワード機能とか自動アップデートとか、まぁその程度のささやかな機能になりますが。一通りやってみたいという気持ちです。決済にJPYCとか使ってみたいですよね。個人開発なので好き勝手できる。

色々と準備を整えつつ、面倒なところは結局人間だなぁと思う今日この頃です。

AIプログラミング開発日誌10: Amazon広告タグのHTMLリンクのバナーをつくる

Tue, 14 Jul 2026 00:00:00 +0900

東京大脱出からようやく落ち着いてきたので、開発をぼちぼちと再開しています。まぁ落ち着いてきたかなと思った矢先に帯状疱疹にかかり、なんかもうしんどいのですが…。未だ治ってません…。

とはいえ仕事は一ついただいている他何もないので、時間はあります。働き始めて15年、今が一番時間ある気がする…。

まぁ次に何をするか全然決めていないのですけれど、それはそれとして、自分の思い描いていたアプリケーションは一度世に出したいなぁという気持ちがあります。これはやってから死にたい。それでAIがまだ使える間に色々とやっております。

一番力を入れているのは、今僕自身も使っているコンテンツ管理アプリのD-Shelf（仮）でv0.29.1とバージョン番号だけ延々と積み上がっています。コンテンツ管理アプリはしぬほどありますが、かなり特殊だと思います。対象が画像ZIP、PDF、画像・動画・音声のような定番のほか、バイナリやHTMLなんかもあります。特にHTMLコンテンツを保存して、それをタブレットで見られるのは、自分で言うのもなんですが一周回って新体験でした。15年くらい前のHTMLで売られていたCG集を2026年にiPadで見る不思議な感じ。

拡張機能も重要視しており、youtube-dlやwhisperと組み合わせると、URLを指定したら動画ダウンロードして文字起こしして全文検索できるなど、かなり特殊なことができるので、記者会見やよくあるオッサンが喋っているだけのやつを保存してアーカイブするなどすると、本家YouTube超えの使い勝手になるかもしれません。したい人がいるのかは知らない。

ただ、機能が増えるほどにクロスプラットフォームでちゃんと動くか不安。現状、Linux(Debian/Ubuntu)版のバイナリを作ってVPSで起動確認をしていますが、何をもってOKとするか。データベース設計もまだ流動的のため、変更があるかもと思うと二の足踏みます。公開の踏ん切りがついていない感じです。

なので、もうちょっとライトなアプリケーションで一通りのリリースサイクルをやってみようかなぁという感じです。今考えているのは、ブロガー向けになりますけれど、AmazonアフィリエイトのHTMLコードを吐き出すやつです。開発中の画面はこんな感じ。

商品リンクとタグを指定したら、HTMLコードとプレビューを吐き出すだけのシンプルなWebアプリです。習作感がある。履歴も残しますがデータベースを使わずjson保存です。

これも実際に僕が使うために作っています。もう自分が使うものしか作らないよね実際。

機能自体は既存アプリでもよくあるもので、WordPressだと有名どころではRinkerプラグインなんかあるんですが、Advertising APIの利用制限が随分と厳しくなってしまったのか、うちの場末ブログなんかじゃもう全然使えないんですよねぇ。払込自体は定期的にある程度の売上はあるんですが。

それにまぁ、WordPressやプラグインに依存してしまうといざという時に困りそうですし。Amazonの公式画像バナーすら殺されてしまった絶対に許さない。自前のコードしか結局残らないんだなぁと思う今日この頃。さすがにWordPressは生きてくれると思いたいですが。一時は脱WordPressも考えましたけれど、総合的に見て個人ブログやるなら今なお一番良いCMSかなぁと思います。

まぁそんなわけで、シンプルなWebアプリなんですけれど、なんだか案外さっと使えるやつがなかったもので。もうちょっと機能を拡張して、とりあえずパッケージにします。Linux(Debian/Ubuntu系列)版とMac版、その後Windows版と、一通りのリリースを経験しようかなという感じです。セルフホスト用Webアプリのパッケージ配布は時代の逆行感がありますが、結局これが一番いいように思います。

メールずっと使ってると、メールクライアントに苦労する

Sun, 12 Jul 2026 00:00:00 +0900

僕の一番古いメールアドレスはYahooのやつで、多分25年以上前に作ったと思われる。当然その後Googleアカウントを取得し、さらに取得し、また独自ドメインでもメールアドレスをつくり、なんだか色々していると、数万のメールが受信箱にたまっているアカウントが複数あるような状態になる。しかもそのメールは歴代の様々なその時々のトレンドを反映したものだ。

で、こういう状態になると、現代のメールクライアントはなんだかどれも悲鳴をあげるのかなんなのか、とにかくなんだか使えなくなる。それで、多分似たような状況にあると思われる、以下のRedditのスレッドを共感しながら読んでいた。

セルフホスト型のウェブメールクライアントで一番おすすめってどれ？ : r/selfhosted

もうデスクトップのメールアプリは、完全に見切りつけて立ち去るところ。どのプラットフォームでも「ほぼ最上位」クラスのやつって、Gmailの容量（量が多いこと）にはどうしても耐えられないか、複数サーバーで詰まったりするんだよね。それか、メールの送受信しようとしてる間に何週間も休暇に入っちゃったりさ。で、その間にディスク容量とRAMを食いまくる。さらにデュアルブートしたり、複数マシン持ったりして同期するのも楽しそうに見えて、結局めんどい。デスクトップのメールアプリって、ずっとオン/オフでチャンスは与えてきたけど……いや、もうさすがに…ほぼ20年近く。そろそろ終わりにしようと思ってる。

わかりみが深い。

僕の場合だと、たとえばThunderbirdなんかはまずそもそも固まる。同期すらできない有様。Macのメール.appは、これはいつ頃からか検索が機能しなくなった。インデックスの再構築とかそんなもん全部やっているが完全に無駄。というかMac系のメールクライアントで検索うまくいった試しがないんよな。

一番機能的にうまくいくのは、ブラウザであるVivaldiが内蔵するメーラだった。しかしながら、これは安定性に難があり、すぐに同期が止まる。これはPCの再起動やブラウザのアップデートなどでまた突然動き出す。メーラとしては使い物にならないが、検索がうまくいくので、検索のためだけに使っている。

結論として、僕のメール環境は送受信はMacのメール.appを基本にしつつ、検索はVivaldiの内蔵メーラを使っている、というなんだかよくわからない形になっている。

まぁ受信するメールの99.9%くらいはゴミなので、このゴミを一掃できれば多分問題なくなるのだけれど、このゴミの一掃が案外難しい。定期的にやろうとするが、あまりうまくいっていない。このゴミの一掃が本来的な課題の気はする。AIにはメール書かなくていいから過去の数十万件のメールとこれからのメールを完全に問題なく処理してほしい。と思ったがではAIの判断を信じられるかというと信じられないので、まぁダメかも。

最近はもうメールクライアント全体について諦めている。それで、今考えているのは、過去分のメールについてはアーカイブして、検索できるようにしだけしておき、受信箱は常に軽くすればよいのではないか、というアプローチになる。これについてはMail-Archiverというものが開発されているようだった。

無料でGmailなどのメールをアーカイブして保存後に自動削除して空き容量を増やすことができる「Mail-Archiver」 - GIGAZINE

折を見て試してみたいと思う。

Growi (Docker) をコンテナごと別マシンに引っ越す

Sat, 13 Jun 2026 13:10:29 +0900

環境

移行元
- Intel Mac mini 2018
- Docker Desktop
- Growi 7.x
移行先
- Linux Mint Xfce 22.3
- Docker 29.2.1
- Growi 7.x

基本的な手順

手順はWordPressのコンテナ移行とほぼ一緒なので、下記記事を参考にすること（雑）

あわせて読みたい

コンテナ構築のWordPressサイトを別マシンに移行する

/container-wp/

全体の流れと微妙な差分を下記にメモ。

移行元でコンテナを停止してボリュームをバックアップし、移行先にアーカイブを送信
移行先でボリュームを復元

ここでElasticsearchの書き込み権限がなかったりするので修正する

移行先のdocker-compose.ymlでボリューム名を指定する
docker compose upしてブラウザで動作確認

の流れ。ボリューム名の定義と、権限の修正あたりが若干の追加要素となる。

ボリューム名は通常はフォルダ名にデフォ名つくような感じだろう。たとえばgrowiフォルダでは以下のようになっているだろう。

local growi_es_data
local growi_growi_data
local growi_mongo_configdb
local growi_mongo_db

これらについて、docker-compose.ymlでes_dataやgrowi_dataとなっているところをそれぞれ修正する。そしてexternalをtrueにする。ここらへんは上記WordPress記事のymlを見て参考に。

docker compose upで様子を見るが、もしかするとElasticsearchでエラーが出てしまうかもしれない。これはElasticsearchコンテナの権限問題であるため、以下のコマンドで修正する。

docker run --rm -v <ボリューム名、たとえばgrowi_es_data>:/mnt alpine chown -R 1000:1000 /mnt

雑だが、以上。

Trilium Notes (Docker) のマシンを移行する

Sun, 07 Jun 2026 21:21:36 +0900

現在運用しているTrilium Notesについて、Intel Mac mini 2018 + Docker Desktop から Linux Mint Xfce 22.3のサーバマシンに移行する。

環境

Trilium Notesのlatest
移行元
- Intel Mac mini 2018
  - macOS Sonoma 14.6.1
  - Docker Desktop for mac v4.76.0
移行先
- ThinkPad L390
- Linux Mint Xfce 22.3
  - Docker 29.5.2

手順

移行元のマシンで停止する。

docker compose down

docker-compose.ymlでデータディレクトリを確認する。TRILIUM_DATA_DIRがどうなっているか見る。

# Running `docker-compose up` will create/use the "trilium-data" directory in the user home
# Run `TRILIUM_DATA_DIR=/path/of/your/choice docker-compose up` to set a different directory
# To run in the background, use `docker-compose up -d`
services:
 trilium:
 # Optionally, replace `latest` with a version tag like `v0.90.3`
 # Using `latest` may cause unintended updates to the container
 image: triliumnext/trilium:latest
 # Restart the container unless it was stopped by the user
 restart: unless-stopped
 environment:
 - TRILIUM_DATA_DIR=/home/node/trilium-data
 - TZ=Asia/Tokyo
 ports:
 # By default, Trilium will be available at http://localhost:8080
 # It will also be accessible at http://<host-ip>:8080
 # You might want to limit this with something like Docker Networks, reverse proxies, or firewall rules,
 # however be aware that using UFW is known to not work with default Docker installations, see:
 # https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw
 - '8080:8080'
 volumes:
 # Unless TRILIUM_DATA_DIR is set, the data will be stored in the "trilium-data" directory in the home directory.
 # This can also be changed with by replacing the line below with `- /path/of/your/choice:/home/node/trilium-data
 - ${TRILIUM_DATA_DIR:-~/trilium-data}:/home/node/trilium-data
 # - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro

ここでは~/trilium-dataとなっている。ついでにMacで/etc/timezoneがなかったのでコメントアウトされているね。

とりあえずアーカイブ化しよう。

tar -czvf trilium-data-backup.tar.gz ~/trilium-data

こいつを新しいマシンに転送してやる。

scp trilium-data-backup.tar.gz ユーザ@IPアドレス:移行先のパス

新しいマシンで、これを保存先ディレクトリ上に展開する。今回はtrilium-dataにしている。

tar -xzvf trilium-data-backup.tar.gz

保存先ディレクトリに入って、もしデータベースの一時ファイルが存在したら削除する。

rm -f document.db-shm document.db-wal

準備ができたらコンテナの起動。とりあえずフロントで。

docker compose up

エラーなく起動したら、http://IPアドレス:ポートにアクセスする。以前使っていたパスワードでログインできることを確認する。

問題なければOK。Ctrl-cで停止して、改めてバックグラウンドで起動する。

docker compose up -d

これでOK。しばらく動かして、安定していることを確認したら元のコンテナは削除してよい。

<関連記事>

/evernote-notion-trilium-notes/

Dell Latitude 5290は中古PCサーバの母艦としていいかもしれないね、一方クライアントなら意外にも…

Tue, 26 May 2026 00:00:00 +0900

うちには40台くらいジャンクPCがある。特に2018年前後を集めており、定番なのはLenovo ThinkPadとDel Latitudeあたりだ。このへんはまぁ安いといってもジャンクの中では高いのかもしれないのだが、既に送料で底打ちがあるため、バランスを取るならこのへんかなぁ、とは思う。ジャンクでバランスもなにもないが…。

結局Linuxに似合う中古PCはなんなんだい

個人的には、漁っているとFUJITSUのLIFEBOOKやPANASONICのLet’s Noteの古いやつなんかが、むしろ良いのではないか？という気がしている。流通量もそこそこあるし。あのへんはLenovoやDellとは異なる方向にブランドなので、必ずしも安くなっていない…なんなら骨董品レベルのものがやけに高く売られていることもある。あの時代のパーツがほしい人向けなんだろうか…しかしコンシューマのPCでそんなことあるかなぁ。

まぁなんでもいいのだけれど、無難にいくならThinkPadかLatitude、というのはそれはそう、という感じだ。ただ2018年より、ThinkPadの上位モデルであるX280以降はメモリソルダリングという悪に手を染めてしまっているため、それより一つ落ちるはずのL390のほうが、メモリの拡張性高い分使いやすいという逆転現象が起きている。筐体の無骨さもサーバ用途ならばむしろ悪くない。まぁ問題は、L390はThinkPadシリーズの中だとそんなに量が出回っていないということかな…。あと、LANポートがないのもいたいね。

そこでいくと、Dell Latitude 5290は攻守ともに強い感じだ。メモリも換えられるし。ま、ちょっと重いかな。Dellらしい無骨さではある。しかし前述したようにサーバで無骨さは褒め言葉よ。ただ同じ型番で2-in-1タイプもあるらしいが、そちらはオンボードという罠仕様になっている。まぁジャンク漁りをする人の中でも2-in-1を狙うのはさらに数寄者だろうから好きでやっているんだろうが…。

なので、僕はThinkPad L390を母艦にしているけれども、Dell Latitude 5290も実は候補に上がっていた。しかし結局L390になり、Latitude 5290は仕事で使うPCとして供養する流れだ。Core i5-8250Uと8GBという必要十分なスペックに、LANポートがあるのが決めてになったかな。LANポートがあると、それ経由でシングルボードな子機とサクッと接続できるのがよい。SSDは家にあった128GB SATA SSDだがね。m.2 2280フォームファクタのSATAがあるなんて、ジャンク漁るまで知らなかったよ…。

まぁThinkPadだのDellだのも当然のように裏蓋ネジなかったり画面TNでもやってたしCMOS切れてたり通信たまに切れたりバッテリー死んでたりするという点では変わらない。そこは安くどうにかできるならなんとかするし、できるけど高く付くならそういう使い方は諦めるという割り切りが必要だ。

クライアントならちょっと冒険してみて…

さて少し目先を変えて、そんなサーバとかじゃなくて、普通に普段遣いでやりたいんだけど、という向きでは、僕の見た感じだと感触はかなり異なる。

ここで一番重要なのは液晶で、画面は生きててIPSフルHDとバッテリーとキーボードタッチパッドが生きていること、が条件となる。あとためらわないレベルで外観が保たえれていることとか（時々戦争に持っていったの？みたいな可愛そうな筐体がある…）。ここがクリアしていればあとはまぁなんとか。

まぁあるにはあるんだけど、普通に1万超えてくるよねこんなの。高いよ。ジャンクでも2万くらいはある。まともな中古店なら2万後半から3万しててもおかしくない。これからもっと高くなるかもな。

…なんですけど、PANASONICとかLIFEBOOKで捨て値になっているように、バッテリーが死にかけだけどもまだ残っていて、驚くべきことにIPS FHD（ときどきTN FHDがあるので気をつける）、みたいなのが、3000円とか5000円とかで手に入ったりすることもある（送料込み）。もちろんCPUは期待するな。Core i5第4世代でも気にするな。でもバッテリー生きてるならなんでもいいじゃない！たとえ残り39%とかだったとしても！

このへんのはね、まぁさすがに常用はつらいと思うけど、サーバよりも持ち運びたいタイプの特定用途のクライアントPCとして活躍の場があると思ったな。筐体のめっちゃ軽いからね。当時は最先端だったんだろう。

PANASONICの昔のやつとかでもボタン一つでWi-fi切り替えギミックとかほしい人はほしそうなやつあるしね。まだそこまでちゃんといじってなけど、僕はけっこういいと思ったな。

どんどん検証していく

40台くらいジャンク揃えたけど「完璧だ！」みたいなのマジでなくて、「こいつはここがなぁ…」のオンパレードです。今はThinkPad L390を使っていて、これは比較的の文句のないPC…に見せかけて、クリックパッド死んでたりするからねｗあとなんか全体的にもやってる。まぁあんまりメインディスプレイがっつり見ないけどね。

とりあえず今日現時点においては、このサイトはThinkPad L390 Core i5-8265U, 32GB RAMで動いております。RAMだけすごい。普段は3-6GBの利用料なので完全に無駄。でもこれからメインサーバの機能をうつしていったら重くなるかも。

最初の間は消費電力も10Wくらいだったけど、メディア系のサーバを入れ始めたから、いまは15Wくらいにあがってそうだなー…。Jellyfinとかは入れる予定ないんだけど。Immichは入れようかなぁ。家族にAppleやGoogleにお布施しているのがいたら救ってもいいんだが…。

この子がいつでも最後のちからを振り絞れるように、後ろに何台ものジャンクを控えさせておかないとな。そういう態勢を整えて、知見を共有していきたい。

まぁなんにしても、あんまり失敗したくなくて、でもLinuxほしいなぁって雑に思う人はDell Latitude 5290はいいと思うよ（2-in1は避けつつ）。ジャンクなら別途パーツ含めて1万、保証付きの中古ショップなら…25000くらいかなぁ。ジャンク市場もこれからどうなることやら…

Linux Mint Xfce 22.3 + LyrionMusicServer + Squeezelite で音楽生活

Mon, 25 May 2026 00:00:00 +0900

メインサーバになりつつあるLinuxマシンに、チューナレステレビをHDMIでつなぎ、TVに光オーディオ出力でアンプに繋がっている。たいへんややこしい状況だが、どうせなら音楽はこのアンプでききたいものである。

ということで、音楽サーバ構築編。

環境

とてもややこしいけれども以下のような感じだ。

graph TD
subgraph PCA ["PC A (操作端末 / リモコン)"]
Browser["Webブラウザ / App(Material Skin UI)"]
end
subgraph PCB ["PC B (Linux Mint / サーバー兼再生機)"]
direction TB
LMS["Lyrion Music Server(楽曲管理・配信)"]
subgraph AudioOutput ["音声出力プロセス"]
Squeezelite["Squeezelite(再生用クライアント)"]
PipeWire["PipeWire / ALSA(OS音声制御)"]
end
Storage[("音楽ファイル群(HDD/SSD)")]
end
subgraph AudioPath ["中継・出力"]
TV["Mi TV(音声ハブ)"]
Speaker["外部スピーカー"]
end
%% 接続とデータの流れ
Browser -- "① 選曲・操作命令 (Port 9000)" --> LMS
LMS -- "② 音楽ストリーム送信 (Port 3483 / localhost)" --> Squeezelite
Squeezelite -- "③ 音声データ引き渡し (default出力)" --> PipeWire
Storage -. "スキャン (パーミッション確認済)" .-> LMS
%% 物理接続
PipeWire == "④ HDMI出力 (DEV=3)" ==> TV
TV == "⑤ 光デジタル出力" ==> Speaker
%% スタイル設定
style PCB fill:#f5f6f8,stroke:#4f5b66,stroke-width:2px
style LMS fill:#d1e7dd,stroke:#0f5132
style Squeezelite fill:#fff3cd,stroke:#856404
style Browser fill:#cfe2ff,stroke:#084298
style PipeWire fill:#e2d9f3,stroke:#4b2c7e
style TV fill:#eeeeee,stroke:#666

HW/SWは以下。

ThinkPad L390
- 32GB RAM
- Linux Mint Xfce 22.3
- squeezelite v1.9.9-1449
- Lyrion Music Player v9.1.0

インストールと設定

Lyrion Music Server

Getting Started with LMS - Lyrion Music Serverより、ダウンロードリンクを取得。記事を書いた時のリンクだとこれ。

wget "https://downloads.lms-community.org/LyrionMusicServer_v9.1.0/lyrionmusicserver_9.1.0_amd64.deb"
sudo apt install ./lyrionmusicserver_9.1.0_amd64

ステータスを確認する。

sudo systemctl status lyrionmusicserver.service

enabledでactive(running)になっていることを確認する。

ポートを空ける。

sudo ufw allow 9000/tcp

そうしたら http://IPアドレス:9000にGo。右下のNextボタンで、音楽ファイルの場所と、プレイリストを保存する場所を指定することになる。

ここで、ディレクトリのパーミッションは755でないとLMSが読めない。基本的にホームサーバならディレクトリは755でよいはず。外付けディスクとかでパーミッションまとめて変える必要があるときはfindで一気にやってしまう。たとえば/mnt/hddのときは以下の感じ。

find /mnt/hdd -type d -exec chmod 755 {} +

ホームディレクトリは~/.sshとかあるんでまとめてやるとか雑なことはしない。

さらに音楽ファイルの権限も600とかだと読めない。音楽ファイルのあるディレクトリに移動して、パーミッションを変更する。

find . -type f -exec chmod 644 {} +

再スキャンするときは、Web画面で歯車よりServerから再スキャン可能。

とにかく音楽フォルダとプレイリストフォルダのパーミッションは整えてやる必要がある。ちなみにうちの場合は音楽ファイルは外付けのハードディスクドライブで、プレイリストフォルダは内蔵SSDのホームフォルダ内にしている。

Squeezelite

まずポート空けておく。

sudo ufw allow 3483

以下でインストール。

sudo apt install squeezelite

入れたら出力を確認する。

squeezelite -l

なんかいっぱい出てくる。ここでハードウェアを指定して /etc/default/squeezeliteを書き換えていく、ということになっているのだが…。

ただねぇ…僕はここから相当転がされた結果、一つの結果にたどり着いたが、これは一般的ではない、とあらかじめ申し添えておく。

まずapt installしたら勝手にsystemctlで動いているsqueezeliteを殺す。

sudo systemctl stop squeezelite.service

有効化はされてないのでdisableする必要はないが、もしenableしてしまったらdisableもしておく。

そのうえで、~/.config/autostartにスタートアップスクリプトを書いていく。ディレクトリがなかったら最初につくる。

mkdir -p ~/.config/autostart

そしたら設定ファイルを書く。

cat << 'EOF' > ~/.config/autostart/squeezelite-tv.desktop
[Desktop Entry]
Encoding=UTF-8
Version=0.9.4
Type=Application
Name=Squeezelite-TV
Comment=Hand-launched success command with delay
Exec=bash -c "sleep 5 && squeezelite -o default -n MiTV"
OnlyShowIn=XFCE;
StartupNotify=false
Terminal=false
Hidden=false
EOF

Execのところは適当に。-n MiTVは僕がMiTV使ってるからなので。適当にわかりやすい名前にする。

再起動して、LMSで見つかるかどうか試す。見つかればOK。

これは明らかに標準の方法ではないが、これが一番安定した。systemdはクソ。昔から思ってたけど、僕の頭が悪いんだと思っていた。今となっては自信を持って言える。僕の頭が悪かろうがなんだろうが関係なくsystemdはクソ。

systemdはクソ

疲れた。なんだかんだで半日消費した。あとは運用していきたい。

ちなみにフォルダ管理派はフォルダをブラウズするように設定できるが、そのへんの話はMacのときに書いたのでそちらを参照。

/mac-mini-2018-lyrion-music-serverlms-logitech-media-server-squeezelite/

ってかPipeWireって何？とか、基本的なところ理解できてないなぁと思った。systemdはクソ。

コンテナ構築のWordPressサイトを別マシンに移行する

Sun, 24 May 2026 00:00:00 +0900

現在常時稼働サーバがMac・Linuxと無意味に分かれている。Linuxマシンに統一してIntel Mac mini 2018には予備役となってもらうように、少しずつ機能を移行している。今回は自宅サーバのWebサイト。つまりこのサイト。

環境

Mac上で展開していたDocker + WordPressのサイトを、別マシンに移行する。前回の移行時はプラグインを使って復元したのだが、せっかくコンテナでやってるのにそれではかいがないと思い、今回はCLIで実施。

元マシン: Intel Mac mini 2018
- Docker Desktop 4.73.0
移行先マシン: Linux Mint Xfce 22.3
- Docker 29.5.0
GitHub - BretFisher/docker-vackup: Script to easily backup and restore docker volumes · GitHub

vackupコマンドの中身については以下の記事を参照。

あわせて読みたい

DockerのボリュームをCLIでバックアップ・復元する

/docker-volume-cli-backup/

手順

全体は以下。

元マシン：コンテナを停止する
元マシン：ボリュームのエクスポート
元マシン：コンテナを再開する
元マシンからコンテナにボリュームをコピー
移行先：ボリュームをリストア
移行先：コンテナを起動
移行先：localhostにアクセスして復元されていることを確認する
リバースプロキシなどで向け先を移行先に。元サイトは落とす

元マシン：ボリュームのバックアップ

コンテナは持ち運べるとして、問題は永続化ボリュームをコピーすること。ここでは、docker-compose.ymlは以下のようなものとする。変数は.envで定義しているとする。内容は、WordPressとDBそれぞれコンテナたててるよ、それぞれボリュームを指定して使うよ、というもの。

services:
 hp_wordpress:
 image: wordpress:latest
 ports:
 - "ポート番号:80"
 environment:
 WORDPRESS_DB_HOST: データベースコンテナ
 WORDPRESS_DB_USER: ${DB_USER}
 WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
 WORDPRESS_DB_NAME: ${_DB_NAME}
 volumes:
 - hp_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - db

 db:
 image: mariadb:latest
 environment:
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 MYSQL_DATABASE: ${DB_NAME}
 MYSQL_USER: ${DB_USER}
 MYSQL_PASSWORD: ${DB_PASSWORD}
 volumes:
 - db_data:/var/lib/mysql
 restart: always

volumes:
 hp_wordpress_data:
 external: true
 db_data:
 external: true

volumeとして、hp_wordpress_dataとdb_dataを外部で作成したものを使うような設定になっている。

現在のボリュームを確認する。

docker volume ls

ターゲットとなるボリューム名と存在することを確認しておく。

コンテナを停止する。

docker compose stop

以下のコマンドでバックアップ。

mkdir volume-backups
vackup export WPボリューム名 volume-bakcups/WPボリューム名.tar.gz
vackup export DBボリューム名 volume-bakcups/DBボリューム名.tar.gz

ダウンタイムを小さくしたいなら、この時点で元マシンをdocker compose up -dで復帰させる。

転送する。

rsync -avz --progress volume-backups ユーザ@移行先:移行先のパス/

容量大きくて途中でdisconnectされるときは

rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" volume-backups ユーザ@移行先:移行先のパス/

移行先マシン：ボリュームのリストア

作業ディレクトリに移動し、ボリュームを復元する。

vackup import WPボリューム.tar.gz WPボリューム名
vackup import DBボリューム.tar.gz DBボリューム名

これで問題ないはずだが、なぜか自分の環境でよくわからんことになっていたので、ボリュームの中身を確認しておく。以下のように直下にされておらずvakcup-volumeがあるかもしれない。

$ docker run --rm -v ボリューム:/volume alpine ls -lh /volume
total 4K 
drwxr-xr-x 6 999 ping 4.0K May 18 02:53 vackup-volume

vackup-volumeなる親ディレクトリが出来ていて、その下にディレクトリがあるようだ。

この場合は以下のコマンドによりvackup-volume以下を展開する。

docker run --rm -v WPボリューム名:/volume alpine sh -c "mv /volume/vackup-volume/* /volume/ 2>/dev/null || true; mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true; rmdir /volume/vackup-volume"

もう一度ボリュームを確認したら直下に展開されていることがわかる。DBのほうのボリュームも同様に。

これでいけるが、なんかよくわからんことをしている。

後日実行したときは再現しなかったので、なんだかよくわからない。

起動と疎通確認

最後にもう一度docker-compose.ymlを確認し、コンテナを起動する。

docker compose up

エラーとか出ないかを確認するため、最初はフォアグラウンドで。http://localhost:ポートにアクセスし、いつもの画面が表示されることを確認する。インストール画面が出たら初期化されちゃってます。なにか間違えているので最初からやりなおし。やりなおした🥺

問題なければ正式にバックグラウンドで動かす。

docker compose up -d

移行元から移行先に向ける

準備が整ったので、DNSやらリバースプロキシやらいじって、移行元から移行先に向ける。

この時点で移行元を落としていいが、いつ落とすかは考え方による。ダウンタイムを小さくするなら移行元をしばらく残しておいてもいい。しかし、変に残しておいてナイスタイミングでコメントついてしまい、消えてしまうみたいな事故が起きる可能性もあるので、何がいいとも言えない。僕はいらなくなったら落とす。

インフラはAI無能

最初これくらいAIがすぐできるだろうと思ったけど何か色々ハマってしまって、結局手作業で心を込めてやりました。インフラ周りは固有の環境や設定が多すぎるので、汎用的な一般解を出し続けるAIは無能になりがち。

それにしてもこの手の作業をするとき、昔書いた記事を参考にすることがよくあるのだけれど、このサイト自身が対象のとき、失敗するとサイト自体が落ちてしまって閲覧することができないっていう。まぁそれを考えると、ニッチな記事でもnoteに転載していくのは保険としての意味もあるか。釈然としないけど。

今後Linuxマシンは色々なハードウェアを検証していくため、移行作業はスクリプト化してスムーズに検証できる体制を整えたい。

追記：自動化した

けっこう何度も引越ししているので、スクリプトで自動化した。

/wordpressdocker-script/

AIプログラミング開発日誌8: 裏切らないアプリをつくっている

Thu, 21 May 2026 00:00:00 +0900

AIプログラミングにより今作っている中で、これは配布してもいいかもしれないなぁ、と思うものが出てきた。

v0.25.8 漫画と攻略本が入り混じる

何度かネタにしたコンテンツ管理のアプリで、バージョンだけ上がり続けてv0.25.8になった。名前はD-Shelf（仮）。これは一つのアプリで画像・テキスト・動画・音声を全部扱えて、タブレットやスマホでも閲覧できるという、僕が欲しかったものをそのまま形にしたものだ。

管理アプリはどこに消えた？

コンテンツを管理するアプリは多いのだけれど、なんだかあまり満足できないでいた。結局フォルダ管理になっている。多分人生で一番管理を頑張ったのは在りし日のiTunesだったのだが、胴元にApple Musicとかいってライブラリを破壊されて以来、フォルダ教に戻った。

写真管理についてはPicasaを使っていたが消えた。食事の写真のEvernote Foodも消えた。Evernoteはまだあるけど僕の知っているEvernoteではない。Dropboxは使っていたが垢BANと値上げに怯えるのに疲れた。Google Photoも同じく。そもそもなんか僕のしたい管理ではない。結局フォルダだけが裏切らない。

オタクは形式を問わない

しかしフォルダはデータが埋もれる。すべてが文字列に圧縮される。いかに僕が文字を愛するとはいえ、階層構造の文字列では限界がある。結果、買ってそのまま、積んだことすら記憶にないデータの肥やしに多額の金をかけてきた。

まぁ最近はデータすらもらえないことが多いのだが…それは置いといて、まず手元にデータとしておいているものは、まず死滅させずにいたいと願った。それは自分の人生における軌跡であり、そこから生まれる内発的な感情を大事にしたい。

そのために、特定のフォーマットにこだわらずに保存する。実際、画像、音声、動画、テキストはもちろんだが、HTMLアーカイブまでそのまま閲覧できる。これは今となってはかなり珍しいかもしれない。たとえば昔の更新が止まった個人サイトなどを個人で保管し、当時の風景そのままに手元で永遠に閲覧することができる。また、昔のCG集などはHTML形式のものもけっこう多かったしねぇ。掲示板のログなんかも扱えるだろう。これは意味がわからないという人のほうがもはや多いかもしれないのだけれど、僕にとっては青春のアーカイブそのものだ（実際Evernoteにはかつての掲示板ログやネットSSを残していたりする…）。

また、ノート機能がある。たとえば漫画を読みながらノートを取れる。これは僕が長年漫画の感想サイトをやっているところに着想がある。コンテンツ消費という表現を僕は好まない。オタクはコンテンツを消費しない。コンテンツとは消費するものではなく内在化するものだ。 「朝ごはんを消費する」とは誰も言わないはずだ。

拡張性とインタフェースと効率について

個々の内在化には、個人による拡張が必要であるため、拡張性も現在頑張って作っている。外部コマンドを登録するプラグイン機能を開発中だ。これを使うことで、たとえばpdftoppmとcwebpを使ってPDFをWebPのZIPアーカイブに変換したり、yt-dlpと連携してYouTubeやニコニコ動画を保存したり（自己責任で）、whisperと連携して動画の文字起こしをしたりできる。その文字起こしを検索対象とすることで、持っている動画の全文検索ということもできたりする。動画の文字起こし+検索対象化は、ここだけ切り出しても割と需要あるかもしんない。

これらはツールの連携をしているだけで、別に僕の制作しているアプリがなにか新しくできるようにしているのではないけれども、それらを繋げてまとめて管理できるのは、データを死蔵させないための有効なインタフェースだと思う。ワークフローというよりは、パイプをGUIに繋げたいという感じだ。

インタフェースは非常に重要だ。最近Xで外国語を翻訳する機能が出たが、あれは特になにかあたらしいことをしたわけではないけれども、それによって世界的な交流が活発化したのは事実だ。僕のタイムラインにもトルコ語のツイートが流れてきたり、また僕自身も英語ツイートのアカウントなどをためらわずにフォローできるようになった。

「使いやすさ」はいうなれば「摩擦を減らす」ものだ。この摩擦は目に見えず定量化もできないために、資本効率において軽視されがちだけれども、だいたい人間の手触りというのは定量化できないことのほうが重要である。自分の人生を定量化しようとしてみればわかる。大事なことほど定量化できないと感じるはずだ。

まぁこのアプリ自体が、そういう定量化とか効率みたいな一切合切について投げ捨てたものだ。そもそもこのご時世に「24時間稼働のサーバアプリケーション」という時点で、まぁ普通ではない。Jellyfinのような熟れて実績がありバイナリの配布されたOSSでさえも、一般に広まっているとは言い難い現状だ。

しかしそうしないと僕がやりたいことはできない。ひたすら僕が「ほしい」と思った機能ばかりを求めている。そのために、現在ピーキーになっているのはそう。このへんは熟れさせていくしかない。インストーラや、オフライン化などは考えたい。特にオフライン化は今後あるかもしれないエネルギー不足の世界観などを想定すると、なんとか対応したい。

もう少し整える

もう少し整えたうえで、テストプレイを誰かにしてほしいところだが、何しろデータという私有財産を扱うものだから、慎重になっている。機能もそうだがデータベースのスキーマが落ち着かない間は出しづらい…。そもそも私有財産を私有財産と思わないIT企業に嫌気がさしてはじめたという面もあるために、ここは同じ穴の狢になってはいけないと思う。一方で慎重になりすぎているといつまでたってもリリースできない。

思えば僕はこれまで一品物とも言える基盤開発しかしておらず、個人としては自分専用のCLIツールを作るだけで、アプリケーションをリリースするという、当たり前の経験がなかったことに気づいた。AIを使ってコーディングが劇的に早くなったのは確かだけれども、一番難しいところは結局残っていて、そこに時間がかかるんだなぁと思う。

まぁもう少し時間がかかりそうだが、ここまできたら配布とその更新まで続けられるようにしたい。まぁでもその前にもっとライトなアプリで一通りのリリースの練習をするかも。

<関連記事>

/ai-selfapps/