2025年まで (含む) の意識低いカメラライフまとめ

2025-12-21T05:21:24+09:00

2025年は写真を撮った (←情報量ほぼゼロの総括)。</p>

</a>カメラ</h2>
カメラというやつが手元にある。それもスマホとかコンデジとかではなくフルサイズセンサのミラーレス一眼が。</p>
元来何か新しいことをしようというときはまず道具を揃えて、やろうと思えばひととおりのことはできるという状態を整えるタイプである。使われていない液タブがモニタアームに生っているのはつまりそういうことなのだが、さておき、カメラもそのノリで買ってしまったものだ。とはいえ液タブと違って素養が皆無の状態から何か始めるわけではなく、義務教育の頃から時折カメラを弄らせてもらって「この光景いいな」と思ったときにシャッターを切るようなことをしていたので、単にそれを再開してみようかと思っただけである。</p>
スマートフォンでは駄目なのかと言われるとべつに駄目ではないのだろうが、それはおそらく「コンピュータのスペックがモリモリでないとプログラミングはできないのか」と問うのと同じことで、何かしようと思ったときに道具が強力であればあるほど雑にいろいろ実現しやすいというだけの話だ。強い制約を掻い潜る不自由さの楽しみに目を向けるのは、ひととおりの範囲を動き回って堪能してからでも遅くない。 (などといいつつ、真面目にプログラミングをやりたいなら初学者は論理回路かC言語から初めるべきだと半ば本気で思っているので説得力はないが……。)</small></p>
</a>撮る……何を？</h2>
で、何を撮るのかという話だが、デカいカメラを抱えるようになって気付いたことがある。それは私が何か撮りたいと思ったとき、その行為は光景や現象の単なる記録か画作りパズルかの二つに大別できるということだ。</p>
</a>記録</h3>
記録というのは、たとえば私の笑いのツボにハマった光景、中二心をくすぐった景色、興味深く感じた対象などを切り取るということである。</p>

</a></div></div>
黒い壁に赤く光り浮かびあがる火災報知器とボタン。中二心をくすぐる </figcaption> </figure>

</a></div></div>
白い空、黒い海、デカい橋。中二心をくすぐる </figcaption> </figure>

</a></div></div>
くっきり引かれた夏、秋、冬の境界線 </figcaption> </figure>

</a></div></div>

下にも置かない丁重な待遇を受ける、警視庁のマスコットキャラクターである ピーポくん</a>。きみ偉かったんだね…… (2023年)</p> </figcaption> </figure>

</a></div></div>
「アドホックシープラ」。一部の C++ プログラマを煽るのに使えそうだ </figcaption> </figure>
私がこういう写真を撮るとき、基本的にこれは人の心を動かすための表現ではない。なぜなら共感を期待していないからである。火災報知器で中二心が疼く人がそこまで多いことは期待していないし、モノクロの世界でデカい橋を目前にして「イカしてるじゃん」と思ったところでそれがどうしたという話だし、そもそも感情ドリヴンですらない単なる観察記録だったり半ばネタ画像だったりもする。ただ後で昔の写真を見て「イカしてるじゃん」と自分で思えればそれで十分だから (そして実際そう思える感性だから)、作品として工夫する必要や欲求を感じていなかった。</p>
</a>画作りパズル</h3>
対して画作りパズルとは、「なんかいい感じの画になる画像をその場で錬成する」という遊びである。記録ではないから、文脈 (すなわち周囲の状況) を残す必要がない。</p>

</a></div></div>
木で重なりなく視野を充填するパズル (へたくそ) </figcaption> </figure>

</a></div></div>
ボケチャンス！ (お笑いのことではない) と思って絞りを開いたらいい感じに奥行を感じられる仕上がりになったので満足した一枚 </figcaption> </figure>
こちらもパズルとしての遊びであって、人に何らかの感情を与えようといういわゆる “表現” ではないから、場合によっては主題すらなくても良い。面白そうな機能や機構があれば意味もなく活用すればいいし、ありきたりであっても構わない。</p>
たとえば「テトロミノを敷き詰めるパズルは結局長方形になるからありきたりで単調だ」などと考えるのはパズルの本質を履き違えているといえる。長方形になりそうな感じがしてきたところで詰めを考えて解を成立させるところがパズルたる所以なのであって、パズルとしての画作りも同じである。何か収まりが良くなりそうだったり特定の構図や構成を成立させられそうなところで、どうにかして決め手を見付けるというのがこのパズルの楽しみ方 (のひとつ) だ。リザルト画面、もとい成果物である写真が “素晴らしい” ものであるかは大した問題ではない……もちろん面白いものが出来上がるに越したことはないが。</p>
</a>ミラーレス一眼を抱えて変わったこと</h2>
2025年は私のカメラ遊びにおいて転機の年だったのだが、それを説明するには2025年より前のことから始めなければならない。</p>
</a>遊びのなかった時代</h3>
一眼ミラーレスを手に入れる前 (あるいは手に入れた後もしばらく) のカメラライフ (#ゴママヨ</a>) がどうだったか思い返してみると、専ら「記録」のための写真しか撮っていなかったようである。一時期のデータが物理的に行方不明になっているため確かではないが、手元に残っている限りの記録では、構図や構成で遊ぼうとした写真の最初の1枚は “躍動</a>” 写真だった。</p>

</a></div></div>
初めての躍動写真。ブレまくっていて下手 (自己評価) (2018年) </figcaption> </figure>

</a></div></div>
2ヶ月後の躍動写真。腕の動かし方のコツを掴んだらしい (2018年) </figcaption> </figure>

</a></div></div>
3ヶ月後の躍動写真。彩度と明度の高い卵を活かして躍動の中心にすると映えるということに気が向くようになってきた (2018年) </figcaption> </figure>

</a></div></div>
1.5年後の躍動写真。画像の中央にない主役を躍動中心にする余裕がみられる (2019年) </figcaption> </figure>
ここに至るまでに画作りで遊んだことがなかったというのも、そう不思議な話ではない。一眼レフもコンデジもスマホも、基本的にモニタ (あるいはファインダー) は撮像面と平行で、概ねセンサーと近い位置にある。この制約のもと、何も調べず何も教わらない状態で異常な姿勢をとってローアングルを撮ってみようとは自然には思わないだろう。ローアングルという概念を知っていたところで、そこから想像されるのはいわゆる “ローアングラー” のような尋常ならざる姿であり、余程のことでもなければ真似してみようとはならないわけである。 (ガラケーは折り畳んでモニタの角度を変えられはしたものの、基本的には中途半端な角度で止めることを想定する構造ではなかったため利便性の面では大きな問題があった。)</p>
そしてローアングルに限らず、自分の頭部からと異なる視野で撮るのは主に姿勢面で大変だ。非凡な写真を撮りたいという欲や構図のビジョンがない以上、頭の高さ以外からの写真など撮ってみようかと考える機会などあるわけがなかった。</p>
</a>遊ばなかった時代</h3>
そこにきて一眼ミラーレスである。こいつは背面の液晶ディスプレイの角度を変更可能で、なんと頭と全然違う位置にカメラがあってもセンサに投影されている映像を確認できる。革命的ではないか！かような玩具を手に入れてしまえば、当然意味もなく濫用して遊んでみたくなるもの……と言えれば話は簡単だったのだが、そうは問屋が卸さない。</p>
いくら姿勢の面で楽になったとはいえ、視点を低くしての撮影は社会的なリスクも伴う。人の往来のある道端でローアングル撮影などできたものではない。そもそも出不精なうえ、道具があっても知識は皆無。構図で遊べることに気付くのはまだ先の話だ。</p>
この頃の私はというと、ボケのことも視点のことも何も考えておらず、一眼ミラーレスを単に「暗いところでもそれなりに撮れて解像度が結構あるすごいデジカメ」くらいのものだと思っていた。そんな状態でも空と電線を撮ることはできるので、実はあまり物足りなさは感じていなかったのである。</p>
</a>遊べる時代</h3>
いつまで昔話をと思うかもしれないが、安心してほしい。ここからは2025年の話である。</p>
転機になったのは、中央線快速への二階建車両の導入だった。</p>

サービス開始に先立ち、グリーン車を連結した12両編成の電車を、10月13日以降順次導入する。2025年春のサービス開始までの間は、グリーン料金不要(普通車扱い)の「グリーン車お試し期間」を設ける。</p> </blockquote>

中央線快速に2階建てグリーン車　25年春まで無料 - Impress Watch</a></p> </figcaption> </figure>
この車両の1階はプラットフォームより低い位置にあり、窓からは地面すれすれの景色が見える。</p>

</a></div></div>
中央線に新規導入された二階建車両 </figcaption> </figure>

</a></div></div>
意図せずローアングルになった写真。2025-02-01</time> </figcaption> </figure>
この1階の座席に座って写真を撮ったことで、やっと気付いたのである。「あれ、もしかして画面内の地面の割合を変えると遊べる？」と。ついでにボケがあると矢鱈に奥行感が出てくるらしいことにも同時に気付いてしまった。</p>
それから様々な参考文献や動画を眺め、3ヶ月後の旅行では概ね今と同じスタイル——つまり、記録で撮るか、あるいは画作りパズルで撮るかという状態になっていた。</p>
</a>2025年の写真</h2>
さて本題の2025年の写真コーナーである。先述のとおり “気付き” を得たのが2月初頭で、その後の最初のカメラ持ち歩き練り歩きイベントが約3ヶ月後の沖縄旅行だった。ここから紹介を始めよう。</p>
ちなみにこの記事の写真は全て JPEG 撮って出しである。現像する気力がないのと、そもそも基本的にはパズルであり演出に凝る必要もそこまでないからね……。</p>
</a>沖縄の自然</h3>

</a></div></div>
茂みから垣間見えた猫 </figcaption> </figure>
猫が見えたので、フレームで囲いつつ前ボケで具体性を喪失させる。なるほどね。スタンダード構図再現ポイントが高い (?)。</p>

</a></div></div>
ソロで生えていたキノコをローアングルで </figcaption> </figure>
ローアングルの練習。背景はもちろんぼかす。そのへんに生えている人間よりも1本しか生えていないキノコの方が大事だからね。</p>
なお後日キノコほど大事ではない人間 (ぼけ) から「俺を背景のダシにしやがって」的な御言葉をいただいた。</p>

</a></div></div>
ハイビスカスの花 </figcaption> </figure>
接写に定番の主題であるところの、花。もちろん望遠端で背景はぼかす。空と葉と花で RGB 、ついでに塔の白で色のラインナップが揃っていい感じに……と思っていたら別のオタクのカメラがﾇｯと入ってきた図。そりゃまあ狙いが被ることもあるわな。背景に白があるおかげで、黒が入っても色のバランスは案外悪くない。</p>
レンズフードにもまあまあピントが合っているせいで、花とともに外来異物の実在性が強調されてちょっと面白いことになっている (個人の感想)。</p>
一応 乱入カメラのないバージョン</a>も撮れている。こちらが当初意図していたものだが、逆に物足りなく見えてしまうようになった。</p>
</a>空、鉄塔、電線</h3>

</a></div></div>
消えゆく夕焼けを背景に聳える送電塔と、空を渡る送電線 </figcaption> </figure>
無骨な巨大構造物のひとつの極致であるところの鉄塔、色を変えつつある空、そして我が物顔で空を渡る電線。オタク (一人称) の大好物である。</p>
視線誘導がそこそこいい感じにきまっている気がする。</p>
電線が集中線のようにもなっており、戦隊ヒーローが集結してポーズをとっている構図のような頼もしい印象を若干受けてしまうのは私だけなのだろうか。</p>

</a></div></div>

</a></div></div>
夕焼けを背景に聳える送電塔と送電線 </figcaption> </figure>
赤と黒の対比はそれだけで映えるので “いい感じポイント” (何？) を積みやすい。</p>
骨組だけの鉄塔は逆光で真っ黒になっても黒の面積比が少ないため潰れた印象を受けづらく、かなり使いやすい。</p>

</a></div></div>

</a></div></div>

</a></div></div>
鉄塔と電線が多い → うれしい！ </figcaption> </figure>
高圧線だと秩序立って複数の線が長距離を走るため、配置を制御しながらお手軽に空を汚せて奥行もパースから自動的に感じやすい。初心者向きの題材なのかもしれない。</p>
</a>リリス</h3>

</a></div></div>
リリス </figcaption> </figure>
同じような姿勢のリスが2匹、フォーメーションでも組んでいるのかという並びで姿を見せた一枚。鉄道車両を複数並べるときこういう見せ方をしがちな気がする。</p>
</a>玉ボケ</h3>

</a></div></div>
花から溢れたような、あるいは花へと跳ねているような光の玉 </figcaption> </figure>
なるほど玉ボケというのは情報を失いつつも存在感はあるので、装飾として扱いやすいということに納得がいった一枚。</p>
光にリズム感があるのが良い。</p>
もう少し絞りを開放すれば玉ボケも大きくなったが (実際に変えながら撮って確認した)、この写真ではこのくらいがちょうど良いと感じた。</p>

</a></div></div>
光の玉を運ぶ橋 </figcaption> </figure>
「デカい橋、大変結構」と思いながら記録のつもりで撮りまくっていたところ手前にピントが合ってしまい、橋がボケた。偶然の産物だが、ぼかすことで自動車の実在感というか生活密着感みたいなものを一気に追放できるのが強すぎることを実感した一枚。</p>
ちなみに 橋にピントを合わせた写真もある</a>が、こうなるとあまり面白みのある画像ではないな。</p>
</a>鳥と彫像</h3>

</a></div></div>
勝利の女神、鍛冶屋、そして鳥 </figcaption> </figure>
鳥や花を頭に乗せていると基本的に滑稽なニュアンスを伴うが、これが高さをヒエラルキーとする文脈に組み込むと尚更面白く見える。顔を見せずこちらに尻を向けているせいで鳥が尚更記号的な様相を呈しているのもそれを加速している。</p>
</a>分割</h3>
画面を分割する。それだけである。</p>
何らかの対比にするといい感じになるとかならないとか。</p>

</a></div></div>
放射線状の分割 </figcaption> </figure>

</a></div></div>
左右の分割 </figcaption> </figure>

</a></div></div>
左右のち上下の3分割 </figcaption> </figure>

</a></div></div>
斜め分割 </figcaption> </figure>
</a>来年は</h2>
写真撮影というのが存外に遊べることに気付いた年だった。</p>
とはいえ結局まだまだ「記録」の写真が大半である。 2026年はもう少しガジェットとしての使い方とか遊び方面を模索してみてもいいかなと思っている。</p>
</a>ボケ</h3>
まずボケというやつが玉にしてもよし、背景を弱めてもよしで雑に強すぎるので、もっと使っていきたい。特に午前に起きられない生活習慣からすると外出後半は日没後になっていることがしょっちゅうなので、デカいセンサーの暗所性能を活用しつつ、そこら中にある光源をうまく活用できると面白くなるはずだ。</p>
</a>絞り開放</h3>

</a></div></div>
両側10車線道路……なのだが、本題はそこではない。 </figcaption> </figure>
これは望遠端で圧縮効果というやつを使ってみたくて10車線道路 (freeway, いわゆる高速道路) を撮影したものだが、ここで紹介したいのは道路や圧縮効果ではない。</p>
実はこれ、フェンスがレンズにモロ被りする形で撮影しているのである。フェンスの隙間が小さすぎてレンズをくぐらせることができなかったが、絞りを開放してほぼ消滅させることができた。</p>
今回は超便利という程度に留まったが、なにか極端なボケで面白いことができると面白いんだけどなぁ (トートロジー) という気持ちがある。</p>
</a>構図</h3>
最近たまに映像作品の表現技法などの動画を観ていて、当然といえば当然だろうが写真に大いに通ずるところがあると感じている。真面目に創作をしたいわけではないが、知っていて初めて見えてくる合理性というのもあるので、たまに映画など眺めつつ目を養いたいものだ。 (などといいつつ結局映像作品を観ている間は内容の把握で手一杯で、構図など気にしている余裕はないことがほとんどだが。)</p>
とりあえずは画角の選択で少しは迷いが減るように修練するところからか。</p>
</a>筋肉</h3>
レンズを抱えるにせよ出歩くにせよ、最低限の筋肉がないと消耗が大きすぎることが知られている。三脚などを使いたくない私は、尚更筋肉の必要性が高い。</p>
欲しがるだけで手に入るなら苦労はないが、苦労はしたくないなぁ。技術の力で手ぶれ補正とかノイズ除去とかどんどん最強になってくれ。たのむ。</p>
</a>積極的な外出</h3>
嫌です。</p>
</a>やっていき</h2>
2026年はもっとカメラで遊んでいきたい (言うだけならタダ)。</p>
(ところで風景パズルで思い出したが、7年前に買って少しだけプレイしてからずっと放置している The Witness</a> どうしよう……。)</small></p>

絶叫し先走る全知の魔

2025-09-22T20:06:37+09:00

かわいそうなおじさんを、これ以上生み出してはいけない。</p>

</a>先走り汁と化したおじさん</h2>
カウパー氏をご存知だろうか。外科医のおじさんである。 (特定の年齢を持たない故人をおじさんと呼ぶべきかは諸説あろうが、とりあえず親しみを込めた敬称として使うことにする。)</p>

尿道球腺について初めて詳細な解剖図を描いた功績により、カウパー腺とカウパーの名前が付けられていることで知られる。</p> </blockquote>

ウィリアム・カウパー - Wikipedia</a> (2025-09-22)</p> </figcaption> </figure>
カウパー腺とは何なのかというと、先走り汁を分泌する器官である。先走り汁はカウパー腺から分泌されることからカウパー腺液</strong>とも呼ばれる。</p>
さて、日本にはそんなカウパーおじさんを先走り汁そのものにしようとする不届きな輩が多くいる。すなわち、先走り汁 (あるいは我慢汁) を「カウパー」と呼ぶ勢力</strong>である。だが、外科医のおじさんが一体何をしたというのか。何の罪があって男性器から滲み出る (滲み出る？) 存在と同一化されなければいけないのか。</p>
……といった現象はそれなりに存在し、目撃するたびに私は「“カウパーおじさん” だ……</strong>」と思ってしまうのである。</p>
この記事は、これ以上カウパーおじさんを増やしてはいけないという話だ。</p>
</a>叫ぶおじさん</h2>
とはいえ日常のふとした瞬間に先走り汁について考えるのは何か嫌だという人もいるだろう。その場合、類似の有名な事例として、ムンクの『叫び』を思い出すこともできる。</p>

つまり「叫び」はこの絵で描かれている人物が発しているのではなく、「自然を貫く果てしない叫び」に怖れおののいて耳を塞いでいる姿を描いたものである^{[3]</sup>。</p>
</blockquote>}

叫び (エドヴァルド・ムンク) - Wikipedia</a> (2025-09-22)</p> </figcaption> </figure>
豆知識としては、ある意味定番といえるほど有名である。『叫び』で描かれている人物はムンクではなく、なんなら人物も叫んでいないのだが、「ムンクの『叫び』」と呼ばれるせいでムンクが叫んでいる絵だと思われてしまっているというものだ。</p>
健全なイメージを保ちたい人は、このような現象を目撃したとき「“ムンクおじさん” だ……」と思えば良い。</p>
</a>余談</h3>
どうでもいいが、こういった何もかもが間違っている呼称や命名のことを個人的に「神聖ローマ帝国」と呼んでいる。</p>

神聖ローマ帝国、と自らを呼んだ、そしていまだに呼んでいるこの政体はいかなる点においても神聖ではなく、ローマ的でもなく、帝国でもなかった。</p> </blockquote>

神聖ローマ帝国 - Wikiquote</a> (2025-09-22)</p> </figcaption> </figure>
</a>魔</h2>
実は “カウパーおじさん” は SF や中二病文脈にも結構いる。特に有名なのは「ラプラスの魔</a>」と「マクスウェルの魔</a>」だろう。</p>
これらはいずれも、思考実験や仮説のために提唱された架空の存在の呼び名である。ラプラスおじさん</a>が決定論を説明するために提唱した、世界の全ての物質の力学的状態を知っている超越的な存在がラプラスの魔であり、マクスウェルおじさん</a>が熱力学の法則について考える思考実験で提唱した仮想的な存在がマクスウェルの魔だ。</p>
しかしこれがフィクション的な文脈になると、これらの魔をモチーフにしたキャラクターに「ラプラス」や「マクスウェル」といった名前 (あるいはそれをもじった名前) を与える事例が出てくる。 (具体例を出せと言われてすぐに良いものを出せるわけではないが……心当たりのある人は少なくないはずだと思っている。)</p>
ほんとにええんか？おじさんやぞ？？というのが正直な感想である。いやべつにおじさんの名前にあやかること自体には何の問題もないのだが、ペットやそれと同種の別個体を飼い主の名前で呼ぶかのような所業</strong>をどんな表情で見たものか若干悩ましい。</p>
で、そういったキャラクターを見ると思ってしまうのである。「“カウパーおじさん” だ……</strong>」と。</p>
猫や女の子を見て、先走り汁に塗り替えられてしまった哀しきおじさんのことを思い出す哀れなオタクが、少なくともひとり、ここにいる。哀れなオタクを代表して、皆さまには是非とも “カウパーおじさん” を減らすよう意識していただけるようお願いしたい。 (たとえば存否の不確定な存在や猫の名前を「シュレディンガー」やその変形にしないでください！)</p>

くだらない小ボケにツッコミされることを鬱陶しく思うことに不思議はない

2025-07-26T04:32:15+09:00

ボケなら何でもツッコミを入れておけば良いというものではない。</p>

</a>文脈</h2>
『名取さなの毒にも薬にもならないラジオ』の第107回で以下のような投書があったと聞いた。</p>

名取さなさん、スタッフの皆さん、こんばんは！</p>
私はくだらない小ボケをよくしてしまうのですが、それにツッコミされることに対してムッとしてしまいます。</p>
例えば「今日が楽しみすぎて、夜しか眠れなかったわ」と言うと「ちゃんと寝てるのかよ（笑）」とか、「まだ月曜日か、疲れすぎて金曜日かと思ったわ」と言うと「勘違いしすぎだろ（笑）」とか……。</p>
私がしょうもないのは間違いないですし、それを丁寧に拾ってくれる友達や会社の同僚に感謝こそすれムッとなるのは理不尽なのですが、それでも「拾ってほしい発言じゃないんだよな」「それはボケそのものだろ！」と反発してしまう所があります。</p> </blockquote>
反応まとめ (どくラジ＃１０７ - posfie</a> (pp.36–43)) を読む感じだと、理解できないという意見がかなり多いようだが、実はそのようなツッコミを (「ムッとする」かはさておき) 愉快に思えないことは妥当であり、むしろツッコミを入れる方が会話が下手なのではないかという話をこれからする。</p>
Disclaimer: 私はネットラジオを聞く習慣がなく、当該放送あるいは当該部分も自分で聞いたわけではない。</p>
</a>小ボケへのストレートなツッコミには問題がある</h2>
まず小ボケへの応答としての「安直でストレートなツッコミ」そのものについて、客観的に、以下のような性質がある。</p>

「夜しか眠れなかったわ」に対して「ちゃんと寝てるのかよ(笑)」という返答は会話中で一切情報が増えていない。なぜなら「夜は寝てるんじゃん」というのはボケ発言の焼き直し、言い換え</strong>でしかないからで、これが『それは (私が今言った) ボケそのものだろ！』という感想になる原因であろう。つまり会話に何ら新しい情報や話題のアンカーを追加せず、そのツッコミにはオウム返しか相槌程度の機能しかない</strong>。</li>
にもかかわらず、その “相槌” は話のフォーカスをずらしていってしまう。「今日が楽しみだった」という本題を繋げづらくなり、会話の潤滑剤としてはあまり有効でなくむしろ邪魔</strong>ですらある。これが『拾ってほしい発言じゃないんだよな』という感想になる原因であろう。</li>
つまり返答がネガティブな効果を持つ相槌</strong>となっている。</li> </ul>
こうしてみると、例として挙げられているようなツッコミは、ボケた人が何を期待していたかに関係なく、シンプルに会話の邪魔になっていることがわかる。</p>
</a>別の例で考えてみる</h2>
元の投稿が理解されていないのは、例が良くないという面もありそうだ。</p>
例として出されている「夜しか眠れなかったわ」は定番すぎて定型のツッコミを待つ枕詞のように見えてしまうので、そのようなツッコミを嫌う人に対して「お前がツッコミを誘ってきたんだろ」という批判的感想を持ってしまうのは理解できる。ここで違う例を出して、たとえば「八百屋で『はい300万円ね！</strong>』と言われて『計算間違ってますよ』とか『300万円ではないと思います』と退屈なツッコミを入れるのは無粋だし、明らかな本題 (300円払ってください) から逸れている</strong>」のような表現をしていれば、もう少し受け入れられやすかったのではなかろうか。</p>
「300万円ではないと思います」に対する素朴な感想は「当たり前だ」だろうし、「勘違いしすぎだろ（笑）」に対する感想は「本気で勘違いしてたわけないのはお前もわかってるだろ」だし、「ちゃんと寝てるのかよ（笑）」に対する感想は「だからそう言ってるだろ」だろう。そういったツッコミは、それ自体が何の面白さも非自明さも持っていないし、会話のフックも追加しない</strong>。つまりそれが退屈で無粋であるということだ。</p>
</a>ツッコミが無粋になるとき</h2>
そもそもボケに対して「解説としてボケの別表現や自明な指摘を加える」というのが、ボケの存在を第三者に向けてわかりやすく強調すること自体が目的の一部となっている漫才のフォーマットであって、一般の日常会話においてこの形式が適しているとはいえない。</p>
「渾身のボケ」で皆を笑わせることが目標なのであれば丁寧に下準備をして爆発させるのも良いが、くだらない小ボケがそれに該当しないのは明らかだ。「疲れすぎて金曜日かと思ったわ」で＼ドッ／となることは発言者も期待していないし、期待していると感じる聞き手もあまりいないだろう。そう考えると、小ボケを拾って丁寧にツッコミを入れてしまうのは雑談をしたい人を漫才の舞台に引き上げているようなもの</strong>で、全然噛み合っていないということになる。</p>
明らかなボケに対して解説や明示的な追認のようなくどい言葉を追加するのは、とても軽妙な会話とはいえない。その無粋を残念に感じる心の動きは、必要もなく小ボケを挟んでしまうような遊び心のある話者にとってこそ自然で妥当なものといえよう。</p>
</a>ではどうすればいいのか</h2>
くだらない小ボケにツッコミを入れるのが無粋なら、どうするか。これは個人的な美学からの意見にすぎないが、本題から逸れないように (あるいは本題にすぐに戻れるように) ボケを重ねる</strong>のが良いのではなかろうか。</p>
たとえば以下のようなことだ。</p>

「今日が楽しみすぎて夜しか眠れなかったわ」に対して
「そりゃ困ったな、今日の楽しみに備えてもう少し寝とくか？」とか。</li>
「まだ月曜日か、疲れすぎて金曜日かと思ったわ」に対して
「そのうち週末で疲れがとりきれなくなって土日すら金曜日になりそうだな」とか。</li>
「はい300万円ね！」に対して
「最近の野菜は高いですね、銀行に寄っといてよかった〜」と言いながら300円払うとか。</li> </ul>
話したい本題があったなら、ボケ返しをスルーするなり乗っかるなりして続ければよく、それで誰も困らない。本題はどうでもよくボケる方が楽しそうなら、どんどん上にボケを重ねていけばよく、ボケを返せなくなったところで投了としてツッコミで締めればいい。この場合むしろボケの連鎖自体が本題となるから「小ボケにツッコまれて『拾ってほしい発言じゃないんだよな』という感想になる」ということは起きないだろう。</p>
この流儀だとそもそも発端がくだらない小ボケなので、返答が爆笑するほど面白くなくとも (同程度に「くだらない」小ボケでも) 許されるという気楽さもある。ぷよぷよやテトリスで連鎖させると1回1回が小粒な消去であっても勝手にポイントに倍率がかかっていくようなものだ。</p>
そんなに頻繁にボケに便乗できるものか、いつもボケることを考えるのは大変だ、と思っただろうか？もちろんその通りで、リアルタイムに進行する会話において予測不可能なタイミングで投入された小ボケに乗っかって更にボケるというのは簡単なことではないし、頭を使う。良いコミュニケーションとは必ずしも楽なものではない。</p>
</a>結局何を勘違いしているのか</h2>
端的にまとめるなら、「丁寧な会話」と「軽妙な会話」は違う、それどころか対極にある</strong>ということだ。</p>
「いかなる発言でも (くだらない小ボケであっても) 丁寧に拾うことで喜ばれるだろう」という丁寧な会話の様式はリアクションそのものをよろこぶ発想によるもので、人間の感情や関係をケアすることを主眼に置いたコミュニケーション</strong>であるといえる。一方で、「小ボケなり皮肉なり率直でない言葉をとにかく増やそう、積み重ねよう」という軽妙な会話の様式は、非自明な言葉や展開によって会話の情報量や予測困難さを増すことをよろこぶ発想で、これは言葉遊びという知的な遊戯を活発化することを主眼に置いたコミュニケーション</strong>であるといえる。</p>
この違いをプロトコルミスマッチと言ってしまえばそれまでだが、少なくとも小ボケに安直にツッコまれることを残念に思う (あるいは鬱陶しく思う) こと自体は軽妙な会話を好む人からすればまったくもって妥当な落胆であり、決して「理解できない思考をしているコミュニケーション困難なバケモン」であるがゆえの感想ではない。また、小ボケへの愚直なツッコミが持つ「丁寧に拾っても得るものがないが失うもの (本題からの逸脱) は発生する」という欠点は、どちらの様式を良しとするかに関係なく無視できない負の効果を持っており、むしろそのような無粋で安直なツッコミで返答をしてしまう人こそ、ある種のコミュニケーション能力 (具体的には、本題のスムーズな継続を妨げない能力) が高くない</strong>とさえいえる。</p>
コミュニケーションというとどうにも感情対感情といったウェットな面が強調されがちなようだが、コミュニケーションは感情や共感のみによって成り立っているわけではないという側面は無視されるべきでないし、もっといえば、良いコミュニケーションというものを「対話相手の感情が盛り上がるよう “介護” すること」であるかのように矮小化するような風潮に簡単に呑み込まれるべきではないと思う。感情介護コミュニケーションは要素を丁寧に拾っておけば成立させられるので楽かもしれないが、それが面白いものになるかは全く別の話である。</p>
言語コミュニケーションの形は「丁寧な会話」だけではない。楽しい会話とは、相槌を打ちさえすれば満点というような雑なものではないのだ。</p>

反語を使わない理由があろうか。いや、ない。

2025-05-29T00:34:27-07:00

若かりし頃の日常をどうして忘れられようか。いや、忘れられない。</p>

</a>反語、あるいは修辞疑問文</h2>
もはやいつどこでのことだったか思い出せないが、学校での思い出を話そう。小学校か中学校か高校かもわからない、その授業が国語か現代文か古文か漢文かもわからない、しかし少なくとも学校の何らかの授業で反語表現、特にその一種である修辞疑問文を教わったことがある。</p>
修辞疑問文とは、疑問などでなく主張や確信であるようなことを、表面的には疑問の形で表現するという技法が適用された文のことである。これは表面的な表現と文脈が食い違うことから解釈の変更が自然となるというメカニズムなので単体でわかりやすく例を出すのは難しいが、たとえば「自転車の鍵どこにある？」「私が知ってると思う？」の後者がそうだ。「私が知ってると思う？」というのが本当にそう思うかを聞いていると解釈するのは不自然で、ゆえに「知っているわけないよね (そしてそのことをわかっているはずだよね)」という含意を読み取るべきということである。「知っているわけない」という疑問でもなんでもない主張を形式上は疑問文として表現しているのが修辞疑問文だ。</p>
さて、これが教科書でどう解説されているかというと、もちろん文脈がどうとか解釈がどうとか小難しいことは書いておらず、疑問文の後ろに「いや、ない」や「いや、(反対の内容)」などと付け足すと自然になるものがそうだといった具合でふんわりと説明されており、具体例でイメージを補完するという構成になっていた。その具体例、というか適用例というのが子供の頃の私 (たち) には面白かったのである。</p>
</a>反語表現を解除できないはずがあろうか。いや、ない。</h2>
実際の文は紹介できないが (おそらく解説対象のテキストに含まれていた修辞疑問文だっただろう)、イメージとしては次のような感じである。</p>

「これだけの布陣で戦に負けることがあろうか？ (いや、ない。)」</li>
「ケーキが嫌いな子供などいようか？ (いや、いない。)」</li> </ul>
普通の読解力があれば、このような形の疑問文がそれらしい場所に出てくれば込められた意図が疑問ではなく、むしろその否定であることは子供でもわかる。もちろん当時授業を受けていた私たちだってそれくらいはわかっていた。そのうえで解説のためにわざとらしく「(いや、ない。)」などと付け足された修辞疑問文が滑稽で仕方なかったのである。</p>
野暮ではあるが、これが面白かった理由を考えてみると次のようになるだろう。</p>

前半の (初歩的ではあるものの) 技巧的表現と、後半の婉曲性の欠片もない露骨な直接さのギャップ</li>
丁寧に組み立てられた前半の疑問文と、それを即堕ち2コマばりの勢いで素早くスポイルする後半のハイテンポなリズム</li>
見ればわかることにわざわざ丁寧な蛇足がつくことのアンバランスさと無意味さ</li>
本来他者に対して発されたコミュニケーションの言葉なのに、自分の疑問に自分で答え自分の発言を自分で否定するという一人芝居のように改変するという、ある種の小馬鹿にするようなコラージュをよりによってお堅い教科書がしていることの不謹慎さ</li> </ul>
こうして振り返ってみると、いわゆるインターネットのキモ・オタクが好きそうな性質がてんこ盛りである。しかもそればかりか、「いや、ない。」は端的で汎用性が高く、しかもクラスや学年の全員が知っている教養なのである。</p>
これが流行らないはずがあろうか。いや、ない。</p>
</a>流行</h2>
かくして反語 (と呼ばれていた修辞疑問文) は流行した。目につく範囲の男子たちは意味もなく修辞疑問文を乱用し、「一緒に飯を食わない理由があろうか？」「いや、ない。」とか「教科書を持ってきたはずがあろうか？いや、ない。」とか、とにかく「いや、ない。」を付けては笑いあったのである。少年の日の思い出だ。</p>
少年の日の思い出といえば「そうか、そうか、つまり君はそんなやつなんだな。」も当時人気のあるフレーズだった。こちらは日常における応用が些か難しく下火になるのも早かったが、ここぞという場面で掘り返されたりして静かに生き延び続けた。</p>
</a>オタクの大喜利</h2>
当時を振り返って思うが、これはまさしく現代の (一部の) オタクたちがやっている、ミームや語録や「構文」による大喜利的会話そのものだ。文脈に紐づいた構造や機構を、文脈から切り離し、表面的な意味や汎用性を利用して無関係な別文脈で転用する。アニメや UGC で無限に元ネタが供給される現代のミームとは質も量も違う貧弱なライブラリだが、たしかに修辞疑問文の解除 (そしてエーミールの発言) はあの時代の私たちにとって大喜利の道具であり、「素材」だった。</p>
未だ SNS を知らぬ少年たちはそうしてインターネットのキモ・オタクとしての会話スキルを無自覚に鍛えていたのである。マジかよ。</p>
</a>結論などあろうものか。いや、ない。</h2>
思い出話は以上だ。</p>
だから何という話ではないが、インターネットのキモ・オタクたちが息をするようにしている “会話 as a 大喜利” はどうもインターネットや SNS の存在を前提としないところにも面白さの源を持っているらしいと気付いたので、こうして記事でメモすることにした。</p>
なんでもインターネットや SNS のせいにするのはやめましょう。</p>

冥福と、浅ましい祈り

2025-04-22T06:56:53+09:00

訃報を聞くとすぐに「ご冥福をお祈りします」と SNS に投稿する “冥福祈りマン” は、自分が何を言っているのかわかっているのだろうか？</p>

</a>湧き出る冥福祈りマン</h2>
SNS を観測していると、有名人 (特に徳が高いとされがちな人) が亡くなった際に「ご冥福をお祈り」する投稿が流れてきがちであるが、この短い一言を見るだけで私はいつもけしからんことだと思う。もちろん中には全面的に筋の通った冥福祈りマン (ここでいうマンは性別等を問わず人間全般を指す用法で使っている) もいることだろうが、その割合は決して多くないと思っている。</p>
発言者は冥福が何なのか、冥福を祈ることが具体的にどのような世界観のもとで何を望んでいることを意味するのか、わかっているのか？訃報を出しにして “徳アクセ” で着飾ろうとすることを恥ずかしいと思わないのか？そういった疑いとともに失望あるいは軽蔑の念を感じずにはいられない。</p>
</a>そもそも冥福とは何なのか (しりません)</h3>
そもそも冥福とは何なのか……というのは実は本題とあまり関係ないといえばないのだが、一応紹介しておこう。大多数の冥福祈りマンは知らないだろうし。</p>
軽く調べた限りでは、これは浄土真宗 (仏教において国内でシェア最大の宗派) あるいは神道などで使われる概念ではないらしい。「使われる概念でない」というのは控え目な表現で、むしろ場合によっては死後に関する教えと真っ向から反発するような概念でさえあるようだ。こういった言及をするとき本当は信頼できて検証された出典つきでやるべきなのだが (信頼できない情報源が多そうなので)、今回これは本題にあまり関係しないのでこれくらいにしておく。ぜひとも有識者にまとめてほしい (他力本願 (誤用) (仏教用語))。</p>

浄土真宗では「冥福を祈る」ということはしません。これは亡くなった人を「仏さま（既に成仏した方）」と見るためで、冥土の世界で過ごすことがそもそも無いと言うことです。</p> </blockquote>

真宗は冥福を祈らない？ | 真宗大谷派三宝寺／浄土真宗寺院【埼玉県春日部市】／本山：真宗本廟（東本願寺）</a></p> </figcaption> </figure>

「冥福」「成仏」「供養」「往生」などは仏教用語のため、使わないように気を付けましょう。かわりに御霊の「平安」「拝礼」などと言った言葉が神式のお葬式ではお悔やみの言葉になります。</p> </blockquote>

「冥福」や「成仏」は使わない？神式のお悔やみの言葉 : お葬式なるほどチャンネル</a></p> </figcaption> </figure>

仏教では、「死」はこの世の生の終わりを指し、閻魔大王の裁きを受けた後に成仏できるかどうかが決まります。そのため、故人の成仏を願って行う儀式がお葬式や法要にあたります。この思想があるため、お悔やみの言葉にも「冥福」「成仏」「供養」などといった言葉が使われるのです。</p>
「故人の死を悼んで“お悔やみ”を述べる」という考え方自体が、仏教固有のものと言えます。但し、人は亡くなると同時に阿弥陀様に救われて成仏するとし、「冥途」という概念がない浄土真宗のような宗派もあります。</p> </blockquote>

キリスト教式のお悔やみの言葉 : お葬式なるほどチャンネル</a></p> </figcaption> </figure>
</a>誰のための祈り</h3>
さて、「冥福を祈る」ことが適切である場面がそれほど多くないことがわかったが、では SNS で冥福を祈っている人々が皆国内におけるマイナーな宗教を信仰しているのか？俄かには信じがたい話である。では逆に故人の宗教がどうかというと、国外であればまだしも、日本人だとそもそもこれが明らかでないケースも多いだろう。</p>
つまり多くの場合、客観的に考えて「冥福を祈れる宗教の流儀」を選択すべき理由は特に思い当たらないということになる。</p>
</a>無邪気な冥福祈りに潜む醜さ</h2>
明確な意図と自覚もなく「冥福」を祈ることが真っ当には思えない。表面的には礼儀を伴っているかのようなその行いはむしろ、多くの人にとってはとても胸を張って主張できたものではないであろう内実の醜さを備えている。</p>
</a>礼儀</h3>
礼儀の面では、まず相手の宗教も知らず特定の宗教様式を押し付けること自体が無礼と考えるべきである。「冥福」ではピンと来ないかもしれないから架空の新興宗教を想像してみよう。</p>
とある新興宗教では、すべての人々の魂は死後世界を彷徨いつづけ、神であり教祖でもある X の導きによって救われるとしよう。信者はきっと誰かが亡くなったとき「X さまのお導きで魂が救われますように」などの文句で祈るのかもしれない。では、これをその宗教の外側で発言することは社会性があり礼儀を伴っていると思えるだろうか？</p>
あなたの大切な人が亡くなったとき、見ずしらずの人や通りすがりの人、あるいはちょっとした知り合いから「{{あなたも故人も全く信仰も信用もしていない神や指導者</strong>}} のお導きで魂が救われますように」などと祈られて心が安らぐだろうか？あるいは「{{あなたも故人も全く信仰も信用もしていない神や指導者</strong>}} の宗教を信じていない人がいるなんて想像もしていませんでした！」と言い訳されて「そっか、じゃあ仕方ないね、無礼だったなんて言わないよ☺️」という気持ちになれるだろうか？</p>
無思慮に「冥福を祈る」というのは本質的にそういうことである。それでいいと思う人はそれで良いかもしれないが、まず冥福を祈る人々は自分の行いを客観的に捉えるべきであろう。実際にやられてトゲトゲした気持ちにならない人はきっとそんなに多くないと思う。そして多くの人の気持ちを悪い方向に刺激するようなら、そもそもそれは礼儀やマナーとして機能していない。</p>
</a>米に箸を立てろ</h3>
「冥福を祈る」は元ネタの宗教の文脈を離れた慣用表現であるから許される、と主張する人もいることだろう。だが、故事成語のような迂遠な表現ならともかく、「冥」「福」を祈るという直接的なフレーズから元ネタの死生観や宗教観が綺麗に抜き去られたとするのは少々無理がある。少し調べればより中立な代替表現がみつかるのに敢えて「冥福」を祈るのなら、そのワードの選択に何らかの意図があると読み取られても仕方のないことである。</p>
こうしたことを考えるときいつも、茶碗に盛った米に箸を立ててはいけないという行儀のことを思い出す。米に箸を立てるのは、これまた仏教か何かに関連して死者に対しての作法であるから生きている人の飯で行うのは良くないとされているという話である。 (もっとも、行儀の良い箸の扱いというのはただでさえ禁止事項が多いので、こういった理由も後からこじつけられただけの可能性はあるが……。)</p>
「べつにあなたも私も仏教徒ではないが、仏教における死者への作法だから仏教以外の文脈でもマナー違反とする」を堂々と主張できるなら、同様に「べつにあなたも私も冥福を祈ることが失礼にあたる宗教の信徒ではないが、それが失礼になる宗教もあるからその文脈以外でもマナー違反とする」も構造的に同じであり同様に受け入れられて然るべきである。どちらかのみ妥当であるとするのは一貫性を欠くではないか。</p>
もし前者 (米に箸を立てるのは死者への飯を想起させて良くない) は当然だと思っているのに後者 (冥福を祈るのは良くない) を同様に当然だと思えないのであれば、そこには「冥福の特別扱い」あるいは冥福を祈ってきた自分への特別扱いがあるということであり、自らの行いと考えを省みるべきではないだろうか。</p>
</a>死者で着飾る現代ファッション</h3>
故人の信仰に寄り添っているわけでもない、遺族に寄り添っているわけでもない、自分の信念と宗教観から発した言葉でもない。そんな「ご冥福をお祈りします」投稿の意義とは一体何なのか。答えは「自身のアカウントに装着して『私は礼儀正しく社会性があり、他人の訃報で悲しめるほど情緒も豊かで、そして人のために祈れる徳までも備えた人間です』とアピールできるアクセサリ</strong>」である。</p>
口頭でのリアルタイムの対話で出てくるならまだしも、 SNS に流す文はお手元の板なり箱なりで入力しているはずである。その板なり箱なりで一度でも「冥福」が何なのか調べて意味を探れば、特定の宗教の文脈を多分に含んでいるようだということは簡単に察せられる。ということは、無思慮に冥福をお祈りしている人たちは自分が何を言っているのか理解せず、かつ、その意味を調べようともせず投稿しているということだ。自分でも何を言っているのかわからないまま何か言っている様子を、本心からの哀悼であるとどうして信じられようか？</p>
しかし冥福祈りマンにとっては、意味などどうでもいいし本心であるかどうかも関係ない。なぜならこれは無料のアクセサリーであり、お手軽に社会性と徳をアピールするという機能こそが重要だからである。自分を良く見せようというアクセサリーとして最大限の機能を発揮するには、「惜しい人を亡くした」とか「悲しい」とかの比較的平易で素朴な表現よりも、もうちょっと日常の語彙から遠く堅苦しそうな表現の方がかしこく見えるので望ましい。道理で皆よくわからない冥福を祈るわけだ。 ……とまで言うと穿ちすぎと言われるかもしれないが、少なくとも私は、冥福祈りは社会性アピールのためのファッションあるいは徳の高い自分に酔える玩具としての側面が非常に強いしその側面は簡単には否定できないと思っている。</p>
冥福祈りマンは自分を良く見せるファッションとして祈っているわけだが、残念ながらその意図とは裏腹に、物言わぬ死者 (多くの場合面識もない) を利己的にファッション化する行為は実に浅ましく映る</strong>。見る人の信仰によっては冒涜的とすら感じるかもしれない。死者には人権も尊厳もないから恥じることなどないし、好きにアクセサリにさせてもらうぜ！という思想を持っていようがそれはそれで人の勝手だが、内心はさておき、それを強く感じさせるアクセサリは大衆に見せるには少々尖りすぎているように思う。</p>

まあでも、死後の世界を信じているでもなくそもそも相手の宗教も知らない、そもそも「冥福」が何の宗教の概念なのかもよく知らないのに堂々と「ご冥福をお祈り」とかできる人、本当にすごいと思う。死者に尊厳なんてないから宗教ミスマッチなんてあっても関係ないもんな。
ロックな生き方を貫いてほしい</p> </blockquote>

https://mastodon.cardina1.red/@lo48576/107059124383055839</a></p> </figcaption> </figure>
</a>そもそも自分で何を言っているのかわからないまま喋るな</h3>
これに尽きる。</p>
口頭での会話などリアルタイム要素のある場では聞きなじみのあるフレーズが確認する前に口から飛び出してしまうことはあるだろうが、 web に容易にアクセス可能な状態で、自分の手で文字として打って発した言葉の意味が自分でわからないというのはさすがに擁護が難しい。マルコフ連鎖 bot じゃあるまいし。社会性や徳などの前に最低限の思慮を備えた方が良い。</p>
</a>結局何なのか</h2>
べつに私は、いつ何人たりとも冥福を祈ってはいけないなどと言いたいわけではない。本心から冥福を祈るような宗教の人々もいるだろうし、あるいは皮肉として意味をわかったうえで宗教を跨いで “冥福” を祈りたくなるような相手だって世の中にはいるだろう。あるいは死者に尊厳がないことをアピールしていきたいという思想的な活動の一環として、あるいは他所の宗教を理由に行動を制限されるべきではないという思想の表明のために、あるいはこのようなブログ記事を書いてしまう厄介なオタクとは違って社会と慣習に無抵抗で従順であるというアピールのために……。</p>
誰がどのような思想を持っていようが個人の勝手だし、他人の内心などどうでもいい。それで利害がぶつかるなら棲み分けなり言論バトルなり政治活動バトルなり暴力革命バトルなりが状況に応じて発生するだけである。 (私は善良な市民なので暴力革命を推奨していません！)</p>
私はただ、無邪気に「冥福を祈る」ことの浅ましさと無礼さを、考えたことのなかった人に気付いてほしいだけである。有名人や偉人が亡くなるたびにそこかしこで冥福を祈る醜い姿 (主観) を浴びせられるのでは辟易もしようというものである。礼儀正しくあろうとするすべての人々が、誠実であろうとするすべての人々が、そして特に私の観測範囲にいる人々や親しい人々が、これといった理由もなしの無思慮な「冥福」を祈らなくなることを、願ってやまない。</p>

自宅サーバの使いみち (2025-Q1)

2025-04-03T10:15:39+09:00

自宅サーバや VPS の用途を紹介する。</p>

</a>自分用サーバ</h2>
私の家にはサーバがある。</p>

</a></div></div>
設置しているものだけでも19インチラックが2つ、NAS が4台 (うち1台は運用停止中)、ネットワーク機器は4台、汎用のノードが3台である。実は画面外にデスクトップ PC が3台あり、ラックマウントでも設置していないネットワーク機器が2台と汎用ノードの芽 (CPU と M/B 抜き) が1台あるが、今回は関係ないのでさておこう。</p>
薄々気付いてはいたが、一般のご家庭にしては些か数が多いようだ。計算機リソースが多いというのは言ってみれば家が広いようなもので、「そんなに家が広くて何になるの」などと言う人はそういない。リソースというのはあればあるだけ自由度が高まる便利なもので、その嬉しさを問うなど愚問である。</p>
とはいえ、では具体的にその自由度を何に使っているかとなると、これは環境の差や個性の出るところであろう。私のサーバ環境もゆったりと変化を続けている。定点観測というわけでもないが、折角なので現状の記録と紹介を兼ねつつ「サーバなんて何に使っているの？」というよくある問いへの今のところの答えを置いておくことにした。</p>
</a>概略</h2>
</a>物理ノード</h3>
まずサーバや自分用サービスといってもすべてを自宅に置いているわけではなく、要件次第で適宜使い分けることになる。分類するうえで一番上に来るのが、「物理ノードを誰がどこで管理しているか」だろう。概ね以下の通りである。</p>

自宅 (汎用×4, NAS×4 (うち2休眠))

自宅に計算機の実機があり、その上でサービスを動かしている。</li>
基本的に OS は Proxmox VE (Debian ベースの distro) を使い、その上で仮想マシンや LXC コンテナを立ててサービスを動かして使っている。</li> </ul> </li>
実家 (NAS×1)

実家に計算機の実機があり、その上でサービスを動かしている。</li>
今のところ箱型の NAS 製品が部屋にそのまま置いてあり、それをストレージとして使ったり、上に仮想マシンやコンテナを立てて更に別のサービスを動かしたりして使っている。</li> </ul> </li>
VPS (×2)

VPS 業者が計算機を持っており、その基盤上で仮想化された汎用コンピュータを動かし、その上にサービスを乗せている。</li>
基本的に OS は GNU/Linux (というか Debian) を使い、その上で Docker Compose を使ってサービスを立てて使っている。</li> </ul> </li>
SaaS

業者が特定の目的にのみ使えるサービスを提供しており、それをそのまま使っている。物理的な計算機の実態は重要ではない。</li>
主にメール関係、ドメイン関係、オブジェクトストレージ、リバースプロキシの一部機能などを使っている。</li> </ul> </li> </ul>
</a>自宅サーバクラスタ</h3>
</a>汎用ノード</h4>
Proxmox VE</a> でクラスタを組んでいる。今のところ3台構成だが、ノードもストレージもそのうち増やす予定がある。</p>

</div></div>
vCPU (仮想コア) は 16+24+32=72 コア、メモリは (32 GB ×4枚)×3台=384 GB (=375.63 GiB)、ストレージは NVMe で各 1 TiB以上、 NAS で 42 TB (冗長化後) のうち一部をクラスタから利用可能にしている。 CPU は幸運にも全てPコアだ。 AMD 万歳！</p>
利用率がスクショ時点で CPU 1%, メモリ 15% とスカスカのように見えるが、メモリは余れば ZFS というファイルシステムのキャッシュとして使われるので I/O の高速化に貢献し、 CPU も後述のビルドサーバを動かしているときには使えるだけ使うことになるので、無駄にはなっていない。それでもビルドサーバ用途だと vCPU がメモリに対して少なすぎてバランスは悪いかもしれないが、現状で一般のご家庭向け CPU には 33 vCPU 以上の製品がない</strong> (ないといったらない！) ので仕方ない。今はとりあえずメモリを 48 GB ×4 ×3 にする嬉しさが少ないことに感謝するのみだ。あれ高いんだよな……。</p>
ちなみに、とある VPS の 64 vCPUs, 192 GB memory, 960 GB storage のプランが 1920 USD/mo. (≒ 月額¥288,000) なので、自宅インフラに350万円かけたとしてもこの性能なら1年で元がとれる。電気代を高めに計算しても13〜15ヶ月あれば十分なくらいだ。つまり VPS を2年以上借りている人は今すぐ自宅にサーバを持つべきである</strong> (錯乱)。</p>
</a>NAS</h4>
</a>冗長化</h5>
HDD は壊れるものである。そして遅い。冗長化は (場合によっては) これら2つを解決できる。ならばやるしかなかろう。</p>
というわけで、すべての NAS でストレージデバイスの冗長化をしている。メインの NAS では負荷と性能を考えて mirror VDEVs (ZFS 版の RAID10 みたいなもの) を、サブとオフサイトの NAS では1ドライブや2ドライブの故障に耐性のある冗長化 (Synology の NAS なので SHR-1 や SHR-2) を使っている。</p>
とはいえ「RAID is not a backup</strong>」と古事記にも書いてあるように、 NAS のシステムが壊れたり誤操作で「正常に」破壊したりなどすればドライブを並べた程度の冗長化では対処できないこともある。当然バックアップも必要だ。</p>
</a>バックアップ</h5>
バックアップによるデータの保全には 3-2-1 ルール</a> (バックアップには3つのコピー、2つの媒体、1つのオフサイトを用意すること) という ユーゴスラビア</a>のようなならわしがある。</p>
これを弊宅で実践しようとすると、こうなる。</p>

3つのコピー

自宅メイン</li>
自宅サブ</li>
実家</li> </ul> </li>
2つの媒体

メインとサブで HDD を共有しない</li> </ul> </li>
1つのオフサイト

実家</li> </ul> </li> </ul>
2つの媒体というのは本来であれば記録媒体を変えたいところで、たとえば HDD のホットストレージに対して磁気テープ (LTO とか) でバックアップを用意するようなことがしたい。したいが、 LTO というのはどうやら一般のご家庭で動かすにはあまりにうるさいようなのと、 LTO 規格が LTO 8 以降で「ドライブは1世代前のテープまで書き込めて、2世代前のテープまで読み出せる」という気の利いた互換性保証をやめてしまった (読み出しも1世代前までになってしまった) というのが残念で、自宅への導入は却下した。</p>
オフサイトバックアップについても怪しいところがあり、南海トラフとまで言わずとも関東で大地震でも起きたら自宅も実家も間違いなく同時にやられるような位置関係にあるので、かなりアテにならない。とはいえ北海道に引っ越す気もないし、クラウドストレージは結構高いし (特に長期間となるとなおさら)、仕方ないので合格点ではあるだろうということで妥協している。自宅が燃えても助かるならひとまず良しとしようではないか。</p>
ちなみに何故 NAS がそんなに沢山あるかというと、こういうことだ:</p>

4ベイの NAS (1) を自宅メインとして調達</li>
ベイが足りなくなった</li>
8ベイの NAS (2) を自宅メインとして調達

4ベイのものを自宅サブに</li> </ul> </li>
実家用に8ベイの NAS (3) を調達</li>
8ベイで普段使いには事足りるが、構成変更や他所からの HDD の持ち込みなどでベイがもっと欲しくなった</li>
36ベイの NAS (4) を自宅メインとして調達

8ベイのもの (2) を自宅サブに</li> </ul> </li>
4ベイの NAS (1) の使い道がなくなったので休眠させる</li>
36ベイの NAS (4) と同じ OS で効率的にレプリケーションするために、12ベイの NAS (5) を自宅サブとして調達</li>
36ベイのやつ (4) がクソうるせえ！！！！！！！</strong> 運用停止

12ベイのもの (5) を自宅メインへ、8ベイのもの (2) を自宅サブへ</li> </ul> </li> </ol>
ここから得られる教訓は簡単だ。 NAS は段階的に乗り替えてベイを増やしていくよりも最初の一発からベイが多いものにしておくべきである。ただし騒音レベルは事前に確認しておくこと。</strong></p>
</a>NAS 上のサービス</h5>
NAS といってもこれは計算機の役割の名前にすぎず、実際に何が動いて何をしているかというと割とバリエーションがある。素朴にリモートストレージとして使うなら SMB (CIFS)、NFS、iSCSI のサーバあたりを動かすのが鉄板だ。私は主に SMB、たまに NFS を使っている。</p>
NFS では認証まわりをセットアップするのが面倒で、かといって NAS 側に任せるとストレージとしての実装と認証の実装が分離できなくなるのが嫌だったので、雑に user / password で認証できる SMB を使うことが多い (なお盗聴耐性があるのかは知らない)。 iSCSI は Proxmox VE 側の問題</a>のせいで使いづらくて仕方がないので今のところスルーしている。本当は使いたいのだが。 rsync は PC との同期や NAS 間での同期で使ったりするが、こちらも通信路の暗号化はしたいので rsync サーバを立てるのではなく SSH でやっている。</p>
近年の NAS はコンテナや仮想マシンを動かせる製品も多く、察するに NAS とは Network Almighty Server とかそんな感じの言葉の略なのだろう (いいえ)。 General Purpose Unit (いいえ) であるところの GPU を彷彿とさせる命名だ。さておきコンテナや仮想マシンの機能は使えるには使えるが、たまにパフォーマンスやネットワークまわりで問題が発生して解決が手間だったりするので、あまりヘビーに使おうと思わない方がいい</strong>というのが個人的な経験からの考えである。ゆえに今のところ NAS 上でリモートストレージとして必要な機能以外は動かしていない。</p>
</a>自宅サーバと VPS で動かしているもの</h3>
更に VPS から自宅へと移動する願望や新規追加を検討しているアプリもあるが、とりあえず現状を書く。</p>
以下で挙げているものは単一項目でも実際には複数インスタンスを動かしていることがあるが、今回それは重要ではないので記載はしない。</p>

多目的</a>

Redmine</a></li> </ul> </li>
基幹インフラ</a>

CoreDNS</a></li>
AdGuard Home</a></li>
Step CA</a></li>
NetBird</a></li>
NAS</a></li> </ul> </li>
インフラ管理</a>

Redmine</a> (再掲)</li>
NetBox</a></li>
Grafana</a></li>
Prometheus</a></li>
Thanos</a></li>
SNMP exporter</a></li>
house-exporter (自作)</a></li> </ul> </li>
行動管理補助</a>

Redmine</a> (再掲)</li>
Radicale</a></li>
Tracks</a></li> </ul> </li>
情報蓄積、メモ</a>

NAS</a> (再掲)</li>
Redmine</a> (再掲)</li>
linkding</a></li>
Shaarli</a></li>
BookStack</a></li>
PdfDing</a></li>
Paperless-ngx</a></li>
ByteStash</a></li>
NocoDB</a></li>
Monica</a></li> </ul> </li>
ファイル同期・共有</a>

NAS</a> (再掲)</li>
Nextcloud</a></li>
Syncthing</a></li> </ul> </li>
通信、通知</a>

Mailu</a></li>
Ntfy</a></li>
Mattermost</a></li> </ul> </li>
コンテンツ鑑賞記録</a>

BookWyrm</a></li>
Ryot</a></li> </ul> </li>
コンテンツ管理</a>

Navidrome</a></li> </ul> </li>
開発</a>

Forgejo</a></li>
Woodpecker CI</a></li> </ul> </li>
SNS</a>

BookWyrm</a> (再掲)</li>
Mastodon</a></li> </ul> </li>
外部公開用</a>

Shlink</a></li>
web サイト</a></li> </ul> </li>
サーバクラスタ内部向け機能</a>

MinIO</a></li>
Apt-Cacher NG</a></li>
CNCF Distribution</a></li>
Proxmox Backup Server</a></li> </ul> </li> </ul>
</a>SaaS を使っているもの</h3>

VPS

固定 IPv4/v6 アドレスが安く、可用性が自宅サーバよりも高いため。</li>
自宅に固定アドレスを持ってくることも不可能ではないが、リスクやコストが釣り合わない。複数回線を引いてこられるならアリだが、賃貸だとそれも面倒。</li> </ul> </li>
レジストラ、 DNS

ドメイン名の取得ついでに DNS もインターネット向けにはそのまま使っている。</li>
複数サービスを利用し、止められても全てのドメインが同時に死なないように、そして猶予があれば別レジストラへすぐに移管できるようにしている。とはいえ止められると結構つらいが。</li> </ul> </li>
SimpleLogin

メールのエイリアスサービス。</li>
自分で立てたり手作業でどうにかすることも不可能ではなさそうだが、単なる中継サービスなので楽をするために SaaS を使っている。</li>
これを止められても DNS 設定を変えることで中継を解除して自前メールサーバ等で受け取れるようにしてある。</li> </ul> </li>
メールサーバ

自分で立てたものもあるが、そちらが止まったときに備えて SaaS も使っている。</li>
複数サービスを利用し、どちらかを止められても諸々のサービスへのログインが阻害されないよう冗長化している。</li> </ul> </li>
Cloudflare Tunnel

リバースプロキシのようなもの。ロードバランサでもあるが、そちらは今のところ必要としていない。</li>
固定 IP アドレスがなくとも IPv4/v6 両方で外部から名前解決してアクセスできるようになる超便利サービスだが、 HTTPS 通信であっても一旦 Cloudflare 側で終端する都合、通信内容は (認証情報含め) すべて Cloudflare に筒抜けになる。 Cloudflare をどこまで信用するかはさておき、意識しておくべきではある。</li>
私の場合、最重要の情報は Cloudflare を通したくないので、 VPN を経由したり IPv6 の非固定アドレスで直接接続しないとアクセスできないようにしてある。</li>
一応 self-hosting できる競合実装</a>があるらしいので、そのうち試してみたい。</li> </ul> </li> </ul>
</a>アプリケーション紹介</h2>
自宅と VPS で動かしている具体的なサービスを紹介する。これが「自宅サーバを何に使っているのか」への直接的な回答になる。</p>
</a>多目的</h3>
</a>Redmine</h4>

Overview - Redmine</a></li> </ul>

</div></div>
Redmine のマイページ</figcaption> </figure>
かなり最強の存在。人生のかなりの部分を管理している。私が自分用に動かしているサーバアプリケーションで最も有用に感じるものがこれである。</p>
Redmine のコア部分はチケット管理システムだと思っているが、他にも Wiki やら工数管理やらカレンダーやらソフトウェア開発に必要そうな機能がいろいろあり、総合的にはプロジェクト管理のためのソフトウェアということになるだろう。</p>
ところで人生というやつは、目標があり、問題があり、複数の文脈があり、こなすべき作業があり、経緯と状態があり、時として締切がある。つまりチケットによるプロジェクト管理というやつは、適切に運用すれば割と素朴に人生に適用できるはずなのだ。脳内に巣喰う無数のタスクを全て計算機に追い出して記憶と記録と管理を任せられるのなら、もちろんそうするのが楽ということになる。</p>
</a>管理されているものの例</h5>
未だ正解構成には到達していないが、例として以下のような「プロジェクト」を用意している。例として挙げるだけなので詳細を確認せずともよいが、タスクに限らず、とにかく状態があり行動や変化のログを記録したくなるようなものは何でも追加しているということが伝われば良い。</p>

braindump</a>: 脳から一旦吐き出して外界に存在させるべき何か。

ブログのネタ、勉強メモなどをトピックごとに起票し、所望の形に吐き出すか諦めたらクローズ。</li> </ul> </li>
シリーズ購入管理</a>: 書籍のシリーズなど、購入済のものや新刊の状況を継続的に追跡する必要のあるものを管理する。

シリーズごとに起票し、完結した全巻を入手するか追うのをやめたらクローズ。</li> </ul> </li>
人のおすすめ: 人がおすすめしているのを見たもの、またはおすすめされたもの。

おすすめされたものを実際に堪能するか、あるいはスルーすることに決めたらクローズ。</li> </ul> </li>
旅行: 日を跨ぐような、あるいはそれに相当する入念な準備や計画が必要になるような長期の外出の管理。

個々の旅行ごとにサブプロジェクトを作成する。</li>
荷物や手続の準備、行きたい場所やしたい行動などを適宜起票し、準備が完了したり所望の場所に到達したり行動を行ったり諦めたらクローズ。</li> </ul> </li>
生活</a>: 趣味や娯楽でない方の諸々のタスクを管理する。契約などの管理もする。

サブプロジェクト「人生の裏」: 非公開の個人情報やプライバシーが主題になるような生活案件。</li>
サブプロジェクト「住居」: 住居に関連する事項。</li>
サブプロジェクト「引越202x」</a>: 202x年に行う予定の引越に関連する事項。</li>
契約は後述の設備・備品チケットと同じようなステータスで管理できる。</li> </ul> </li>
設備・備品管理</a>: 言わずもがな。

保証期間、保証書、外箱などの管理が必要だったり、手入れや特別な破棄手順が必要ななものについて、入手・利用・破棄の全体を追跡する。</li>
設備・備品チケットは他のチケットと少々異なり、以下のようなステータスを持つ。

新規: 入手する目処が立った。</li>
運用準備: 運用を開始するための作業をしている。</li>
運用中: 運用中・稼動中。</li>
運用休止中: 一時的に運用をやめている。</li>
運用終了準備: 運用終了のための処置や廃棄作業中。</li>
運用不可/障害: 故障状態、修理中、紛失などで運用が一時的に不可能な状態。</li>
運用終了: 運用終了・廃棄完了。</li> </ul> </li>
これの運用についてはちょっと悩んでいるところもある: バグ #529: [Redmine] 設備・備品管理の方法を再検討 (2024-10) - 人生管理運用 - Nopmine</a></li> </ul> </li>
趣味・娯楽</a>: 言わずもがな。

サブプロジェクト「コンテンツ鑑賞」</a>: 積んでいるアニメ、本、ノベルゲームなど。

実はこの用途が一番最初に Redmine を使い始めたときの目的だった。</li> </ul> </li>
サブプロジェクト「人生管理運用」</a>: この Redmine そのものの運用方法に関する思考。</li> </ul> </li> </ul>
</a>タスク管理はつらいのか？</h5>
タスク管理システムで労役を思い出してつらくなる人もいるかもしれない。ひとつここで明確にしておきたいのは、私はこのシステムを「自分の行動を指示させるための行動管理機構」として使っておらず、「なんらかの形で人生に発生する行動や情報を適切な形式で記録できるメモ」として使っているということである。この文脈で私が「管理」というとき、それは「必要な情報にアクセスしたり更新しやすい状態が維持されている」という意味で言っており、「行動を外部から規定する」という意味で言っていない。私がリマインダーを見て何らかの行動をするのは、「この時期に確認すべきだと過去の私が思っていたのだからそうなのだろう」と思って今の自分が改めてそうすると決めたからであって、「システムに行動を指示されたからそうしよう」と考えるからではないのである。</p>
私の運用する人生用 Redmine はあくまで「私が何をすべきか今自分で考えるための参考情報が記録された、過去の行動と思考を蓄積したデータベース</strong>」であって、決して「将来の自分を規定する計画書」ではなく、ゆえに不備があっても (たとえば期日の入力を忘れても) それ自体が即座に重大な問題になったりなどはしない。すべての義務的行動は、その行動自体が義務として課せられたゆえに義務なのであって、 Redmine 上にチケットが起票されたゆえに義務になるのではない。</strong> ゆえに Redmine をこの用途で使うこと自体に特段のつらさは感じていないし、感じてしまうならそれはある種の責任転嫁である。</p>
</a>基幹インフラ</h3>
</a>CoreDNS</h4>

CoreDNS: DNS and Service Discovery</a></li> </ul>
DNS サーバ。宅内のローカルなドメイン名を解決するために使っている。</p>
自分向けのサービスやサーバは必ずしも全世界に向けて公開すべきとも限らないため、自宅のネットワーク内でのみ名前を解決できるならその方が良い。そのため一旦宅内の CoreDNS サーバで名前解決を試み、駄目だったときに ISP の DNS などにフォールバックするようにしている。サーバ群以外のデスクトップ PC や無線端末などは、後述の AdGuard Home</a> を経由して CoreDNS を使うようにしてある。</p>
解決すべき名前と IP アドレス等は、後述の NetBox</a> に登録した情報から自動生成している。</p>
</a>AdGuard Home</h4>

AdGuard Home｜あらゆるOS（Windows, macOS, Linux）向けシステムワイドソフトウェア</a></li> </ul>
ブロックリスト機能などがあり広告ブロックに使える DNS サーバ。スマートフォン、タブレット、PC、ゲーム機や IoT ガジェット等の、システムの中枢にいないエンドユーザ的な端末から使っている。</p>

</div></div>
AdGuard Home のダッシュボード</figcaption> </figure>
広告ブロックの是非についてここでは語らないが、無視できない割合のクエリがブロックされており、かつそれらが少なくとも私が直接認めたり望んだものではなかったという事実は確かに可視化されている。</p>
</a>Step CA</h4>

step-ca | Easily Manage Certificates For Production Workloads</a></li> </ul>
自宅ネットワーク用の HTTPS 証明書発行サーバ。</p>
HTTP 通信が暗号化されておらず盗聴可能であることは周知の事実である。とはいえ基本的に「信頼できる」ネットワーク内であればこれは問題にならない。</p>
問題になるのはそのようなネットワークが「信頼」できなくなった場合で、たとえばこれは信頼しきれないメーカーの IoT 機器が自宅のネットワークに参加したりとか、強めの権限を持っている仮想マシンがクラックされたりとかである。このようなリスクは避けられず事故はいつか起きる (しかもしばらくそれに気付けない) ものとして備えるべきで、つまり宅内であっても可能なところは (特にユーザ名とパスワードが行き来するところは) 暗号化しておいて、「信頼」をそもそも最小限しか必要としない仕組みを構築しておくべきということだ。</p>
</a>NetBird</h4>

NetBird - Open-Source Zero Trust Networking</a></li> </ul>
VPN ソリューション。外出先で携帯端末などから自宅内ネットワークに参加するために、自宅サーバに出口ノードを用意している。</p>
わかる人向けに言うと、 Tailscale の競合で self-hosting をサポートしているのが NetBird である。私はまだ self-hosting はしていないが。</p>
どうせ裏は WireGuard のようなので、シングルユーザ向けでいいからもうちょっとシンプルなものはないかなと思っている。</p>
</a>NAS</h4>

TrueNAS - Open Enterprise Storage</a></li>
DiskStation Manager | Synology Inc.</a></li> </ul>
ネットワークストレージ。日頃利用するデータ、サーバが利用するデータ、過去に作成したものや購入したもの、バックアップなどなど、あらゆるものを溜め込む場所。</p>

</div></div>
TrueNAS のダッシュボード</figcaption> </figure>

</div></div>

</div></div>
TrueNAS の記憶域一覧とエンクロージャ確認画面</figcaption> </figure>
自宅のメインで TrueNAS を、自宅のサブと実家で Synology の NAS を使っている。</p>
</a>インフラ管理</h3>
</a>NetBox</h4>

NetBox Community - NetBox Labs</a></li> </ul>
データセンター管理ソフト。拠点、ラック、デバイスといった物理的な器具や空間、仮想マシンや IP アドレスや VLAN などといったリソース、また電源や通信線などの配線に至るまで、データセンターで管理する必要のある様々なリソースを一括管理できる。</p>

</div></div>

</div></div>
NetBox のラック確認画面の一部と、 IP アドレス一覧画面</figcaption> </figure>
自宅サーバクラスタを管理していると、設定や意思決定が各所に散っていき、矛盾が生じやすくなる。たとえば管理が粗雑だと、どこかにあったメモの設定と、管理用のスクリプトが適用しようとする設定と、実際に動いているマシンの設定が、ぜんぶ食い違っているなどということがありうる。これを防ぐために有用なのが Single Source of Truth という概念で、簡単に言えば、すべての情報を一箇所に綺麗に整理して集約してしまえば、他の場所に置いたものなど全部無視してそもそも矛盾など起きえない状態にできるはずという発想である。実際にやろうとすると注意深い設計と徹底した自動化が必要なので言うほど簡単なことではないが、目指すだけなら損はない。</p>
NetBox は API アクセスができるので、必要な情報を抜き出して使うようなスクリプトが書きやすい。たとえば私の場合、 CoreDNS</a> に食わせるドメイン名と IP アドレスのリストなどを NetBox から取得してスクリプトで生成している。</p>
本当はもっといろいろできそうなのだが、インフラ管理の自動化も道半ばなのでとりあえず「何か矛盾があっても最優先の記録場所を確認すれば理想状態は書いてある」という状態になっているだけでも、メモを書き散らかすよりだいぶマシだということでありがたがっている。</p>
</a>Grafana</h4>

Grafana: オープンなオブザーバビリティ・プラットフォーム | Grafana Labs</a></li> </ul>
時系列データなどの可視化ツール。後述の Prometheus</a> で収集し Thanos</a> に蓄積したメトリクスをグラフ等として可視化できる。</p>

</div></div>

</div></div>
Grafana による、消費電力グラフと WAN 通信量グラフ</figcaption> </figure>
メトリクス (監視対象の状態) 自体はいろいろ収集しているが、ダッシュボードに表示しているのは今のところ自宅全体の消費電力とサーバラックの消費電力、ルータ関係のメトリクス (通信量など) のみである。昔はコンセントタップ単位の消費電力や温湿度なども監視していたが、機材故障</a>や Bluetooth まわりでの接続品質の悪さなど諸事情あって監視を中断した。</p>
後述するが自宅全体の消費電力の監視には自作の house-exporter</a> を、サーバラックの消費電力やルータの監視は SNMP exporter</a> を使っている。</p>
</a>Prometheus</h4>

Prometheus - Monitoring system & time series database</a></li> </ul>
メトリクスを収集するサーバ。これ単体では収集したデータの確認程度の基礎的な可視化しかできず、人間向けに見せるには先述の Grafana</a> 等で可視化する。</p>
Grafana のダッシュボードには追加していないが、諸々のサービスのメトリクスも収集だけはしている。</p>
データストアとして後述の Thanos</a> と協調させている。</p>
</a>Thanos</h4>

Thanos - Highly available Prometheus setup with long term storage capabilities</a></li> </ul>
Prometheus</a> で収集したメトリクスを蓄積したり Grafana</a> 等のクライアントへ配信する、 Prometheus 互換な API を提供できるサーバ。</p>
本来は大規模なメトリクス収集のためのものだが、私は単に「長期間データを蓄積できる」という性質だけを求めて使っている。 (一方 Prometheus では一定期間でデータが消えていくような用法が基本になっているらしい。)</p>
データは後述の MinIO</a> サーバに蓄積している。</p>
</a>SNMP exporter</h4>

GitHub - prometheus/snmp_exporter: SNMP Exporter for Prometheus</a></li> </ul>
SNMP (Simple Network Management Protocol) というプロトコルでデバイスやサーバからメトリクスを引き出して Prometheus</a> 向けに提供する中継サーバ。</p>
設定の管理や生成が手間なので正直あまり好きではないが、その手間の責任は SNMP exporter のみならず各種デバイス側にある割合も (全てではないが) 多いため、 SNMP exporter 自体については何ともいえない。面倒ではあるが、なんだかんだで便利なので結局使っている。</p>
</a>house-exporter (自作)</h4>

NOP Thread / house-exporter · GitLab</a></li> </ul>
諸々のメトリクスを自力で取得して Prometheus</a> 向けに提供する、自作の中継サーバソフトウェア。</p>
スマートメーター</a> (電力計) から Bルートサービス</a> を使って家庭の電力情報を取得する機能と、 Bluetooth で SwitchBot の温湿度計プラス</a> から温度と湿度を取得する機能がある。 SwitchBot の Plug Mini というスマートプラグから Bluetooth 経由で消費電力情報を取得する機能もあるが、この製品は リコール</a>されており、もちろん (?) 手元の4台も全て早々に壊れたので、今はその機能は使っていない。もう使うこともないだろう。</p>
スマートメーターとは Wi-SUN という無線規格で通信する必要があり、その上のレイヤーのプロトコルも ECHONET Lite という独自のものになるため、規格と仕様を読みながら最低限の部分を自前で実装した (参考: doc/specs.md · 257cefdbcd2e644d1b06086059411bd5673859ab · NOP Thread / house-exporter · GitLab</a>)。</p>
SwitchBot の温湿度計プラスのメトリクスは BLE (Bluetooth Low Energy) で広報されているためそこまで実装量は必要なかったが、相対湿度から体積湿度を算出するためにちょっとした計算が必要なのでサーバ側でやっている。ただ、この BLE での通信がかなり頻繁に失敗して原因も解明しきれないため、保守が面倒で今はこの機能を使っていない。 (これを動かしている Raspberry Pi がオープンフレームとはいえ金属製のサーバラックに設置してあるのは間違いなく通信状況を悪化させている一要因ではあるが、それだけではないはず……。)</p>
</a>行動管理補助</h3>
</a>Radicale</h4>

Radicale v3 Documentation</a></li> </ul>
スケジュールや連絡先 (アドレス帳) などの同期サーバ。</p>
一般的にスマホや PC のスケジュール同期は CalDAV プロトコルや iCalendar 形式のファイルによって、また連絡先の同期は CardDAV プロトコルによって行われる。 Radicale は CalDAV と CardDAV のサーバであり、これらのプロトコルを使うクライアントに情報を提供したり、データの追加・削除・編集を受け付けたりする。</p>
神経質でない人は Google や Apple (あるいは Microsoft？) のアプリとサーバを使ってこういった情報を同期するものと思うが、私はそういった企業のサービスにできるだけ依存しない生活をこころがけているため自前で用意している。可用性だけ考えれば圧倒的にそういったデカ・テックのサーバの方が安定しているため、このスタイルを他人におすすめすることはないが……これは利便性ではなく思想と実践の問題である。</p>
</a>Tracks</h4>

Tracks</a></li> </ul>
文脈ごとにタスクを分類できる TODO 管理アプリ。</p>
重いタスクや長期間に及ぶタスク、また単純なタスクでないような何かについては先述のとおり Redmine</a> で管理しているが、 Tracks では逆に「未着手」と「完了」しか状態を持たないようなシンプルなタスクを蓄積・消化するのに使う。つまり「進行中」を気にする必要がなく、遂行に際しての履歴やメモを残す必要もなく、後から思い返すこともないような雑事を管理している。たとえば「石鹸を買う」とかのチケットを Redmine で定期的に立てては閉じるなどしても (特に一人暮らしでは) 得るものが小さいが、そういったものに Tracks が使いやすい。</p>
「Redmine で hogehoge に関するチケットを立てる」などのようなタスクを立てられるので、その点でも Redmine を補完する存在である。</p>
単なるタスクリストであれば同期されたメモにリストを作って追加や削除をしていくだけでも運用できるにはできるのでクリティカルではないが、やはり当然ながら専用のアプリケーションの方が使い勝手は良い。</p>
検索可能性 (ググラビリティ) の低さが尋常でない名前なのでたまに困る。</p>
</a>情報蓄積、メモ</h3>
</a>linkding</h4>

linkding | linkding</a></li> </ul>

</div></div>
Linkding での 公開ブックマークリスト</a></figcaption> </figure>
シンプルな UI の web ブックマーク管理ソフト。</p>
必要十分な機能の揃った、無難で良いもの。</p>
</a>Shaarli</h4>

Shaarli documentation</a></li> </ul>

</div></div>
Shaarli での公開ブックマークリスト</figcaption> </figure>
シンプルな UI の web ブックマーク管理ソフト。</p>
機能や使い勝手に大きな不満はなかったが、データ保存方式が結構ロックでスケーラビリティとか長期間利用となると若干不安要素があったので、 linkding</a> に乗り替えることにした。</p>
</a>BookStack</h4>

BookStack</a></li> </ul>
リッチテキストエディタと markdown エディタどちらも使える Wiki システム。長期間残す前提の記録などのために立てた。</p>
permalink 機能が使えるのが良いと思って使ってみたが、ページの permalink 取得が一手間必要で面倒だったり、セクションの ID が markdown 編集で維持されなかったりなど、肝心のところで私の望むレベルに達していないところがあるのが悩ましい。そのうち別実装を試すことになるだろう (これより良いものが見付かるかは不明だが)。</p>
</a>PdfDing</h4>

GitHub - mrmn2/PdfDing: Selfhosted PDF manager, viewer and editor offering a seamless user experience on multiple devices.</a></li> </ul>

</div></div>
PdfDing のドキュメント一覧</figcaption> </figure>
linkding</a> にインスパイアされた、 PDF ドキュメントの蓄積・管理アプリ。 PdfDing 側に PDF ビューア機能と既読管理機能があり、 PC で途中まで読んでスマホで簡単に (記憶を頼りにスクロールなどすることなく) 続きから読むなどの複数デバイスでの利用が便利。</p>
ｲﾝﾀﾈｯﾂで手に入れた文書や電子書籍、取扱説明書などを突っ込んで管理している。まだスキャナを持っていないためできないが、自炊などした場合にも役立つことだろう。</p>
後述の Paperless-ngx</a> とは用途を分けており、基本的に通して読むもの、あるいは読む必要はないが何かの際に参照したくなるかもしれない文書の管理に使っている。</p>
</a>Paperless-ngx</h4>

Paperless-ngx</a></li> </ul>
紙の文書を電子化したものを管理することを主眼に置いたアプリ。最初から電子データしかないものももちろん管理できる。</p>
こちらは PdfDing</a> と用途を分けており、 PDF データと同時に元となった紙媒体も保管しておく必要のある文書や、領収書、納品書、契約書といった、いざというとき探し出すためにしっかり整理されている必要のある文書に使っている。</p>
</a>ByteStash</h4>

GitHub - jordan-dalby/ByteStash: A code snippet storage solution written in React & node.js</a></li> </ul>
スニペット (コード等の断片で、小さく使い回しのききやすいもの) を管理するためのアプリ。単なるメモよりもソースコード的なものの管理に特化している。</p>
SNS で流れてきた面白いコード片を記録したり、別の端末に設定を流し込むためのデータなどを置いたりするのに使っている。</p>
</a>NocoDB</h4>

NocoDB Cloud</a></li> </ul>

</div></div>

</div></div>

</div></div>
NocoDB でポスターやタペストリーを管理してみようとしているところ</figcaption> </figure>
どう表現したものか難しいが、表のようなものであればそれっぽく管理できるというデータベースのアプリ。</p>
巷では Airtable</a> と競合する自由ソフトウェアなどと言われている。機能的に釣り合っているかは知らないが、大して使い込んでいない今の時点での感想としては、リッチな RDB (Relational Database) といったところ。</p>
タペストリーの管理をしたくて</a>立ててみたが、手持ちのものの入力が手間なのでどうしたものか……。応用はききそうなので、諸々の管理における最後の砦として活躍してくれそうだと思っている。</p>
NocoDB がなくとも Wiki などに表を作って管理することは不可能ではないが、その場合スキーマに柔軟性がなく変更に弱く入力も面倒でビューの追加も難しいなど圧倒的に不便なものになるので、使い勝手はネイティブなデータベースに及ぶべくもない。</p>
</a>Monica</h4>

Personal CRM done right - Monica</a></li> </ul>
人間関係について整理して記録しておけるアプリ。 "Open source personal CRM" (CRM: Customer Relationship Management, 顧客関係管理) を謳っている。</p>
たとえば知り合ったが頻繁に顔を合わせるほどではないような関係の人とか、あるいは友人であってもいつが誕生日であるとか前回会ったとき何をしたとか、そういった人間関係についての記録を整理しておくことができる。特にハンドルネームから実名を思い出せないときに有用だ。</p>
が、新しく人と知り合うことがない陰キャひきこもり生活を送っているため正直あまり使っていない。どうせ記憶から溢れるほどの人と関われないので。 ……などといいつつ、同僚の名前を思い出すにも一呼吸必要なくらいには人の情報を覚えるのが苦手なので、やはり念の為ということで立ててある。</p>
</a>ファイル同期</h3>
</a>Nextcloud</h4>

Nextcloud - Open source content collaboration platform</a></li>
すべてのアプリ - App Store - Nextcloud</a></li> </ul>
ファイルの同期と共有をはじめとした様々な機能を「アプリ」として追加できるプラットフォーム。とはいえ最もベーシックな使い方は Dropbox や OneDrive のようなファイル共有である。</p>
もともとは Dropbox のようなものだったが、「アプリ」を追加できる機能が充実しており、結構なんでもある。ただし私は過去に Nextcloud のバージョンアップを雑にやって失敗しデータを吹き飛ばしかけた (というか、吹き飛ばしてバックアップからどうにかした) 過去があり、リスクを分散したいので、できるだけ Nextcloud サーバに依存しないインフラ整備をこころがけている。私が Nextcloud 上で動かしている (ファイル管理と Nextcloud システム自体の関連以外の) アプリは以下の2つだけである。</p>

PhoneTrack</a>

端末等の位置情報を追跡したり、その記録を閲覧できる。</li>
遠めの外出や旅行において利用している。</li> </ul> </li>
Notes</a>

markdown ファイルをメモとして編集・管理できる。</li>
Notes 上でのメモはそのまま Nextcloud 内に markdown ファイルとして保存される。</li>
逆に PC 等から markdown ファイルを編集して同期すると、 Notes 上でも編集がメモに反映されている。</li> </ul> </li> </ul>
また、 Android のクライアントには写真や動画などを自動で Nextcloud サーバにアップロードしてくれる機能があり、これも活用している。</p>
どうでも良いが、 Google で検索すると公式サイトよりも上位に日本の代理店 (たぶん) が「Nextcloud公式サイト」というタイトルで出てくる (2025-03-30</time>) のはどうかと思う。 †公式† サイトでは無償の Community 版への導線もなく、あたかも契約しないとサーバアプリを使えない製品であるかのように案内されているが、そんなことは全くないので諸氏には安心して本物の公式サイトにアクセスしてほしい。</p>
</a>Syncthing</h4>

Syncthing</a></li> </ul>

</div></div>
Syncthing のダッシュボードでのフォルダ一覧</figcaption> </figure>
プライベートなファイル同期のためのアプリ。スマホや PC でファイルを同期できる。実はサーバを立てずとも使える。</p>
Nextcloud</a> と違うのは、 Nextcloud ではサーバが必須で web UI 上からひととおりのファイル操作 (ファイルやフォルダの作成、削除、閲覧、編集など) や選択的な同期とダウンロードができるのに対して、 Syncthing はまとまった単位での同期に特化しておりビューアやファイル操作機能などがなく、サーバも立てる必要がない点。敢えてサーバを立てているのは、 Android の Syncthing クライアントに問題があっても同期する端末の追加・削除・設定変更といった基本的な操作が外出先でできるようにしておきたいというのが主な理由。</p>
</a>通信、通知</h3>
</a>Mailu</h4>

Mailu — Mailu, Docker based mail server</a></li> </ul>
メールサーバを実用的に運用するのに必要なひととおりの機能を備えたソフトウェアパッケージ。ひとくちにメールサーバといっても実は数多くのコンポーネントがあり、その設定は複雑怪奇、しかも迂闊な設定で動かすとセキュリティに問題を抱えて大惨事になりかねない。そういった問題に陥らないよう真っ当な設定を web UI 等から管理できるようにしようというもの。</p>
これは VPS 上に立てている (立てざるを得ない) ため自宅サーバではないのだが、一応自前管理ということで紹介する。</p>
メールサーバを自前で持つというのは、商業的な理由での機能制限や追加の課金を受けないということを意味する。</p>

無制限の個数のドメインを使える</li>
無制限の個数のアカウント (メールアドレス) を使える</li>
無制限の個数のエイリアスを使える</li>
無制限にメールを送受信できる</li>
迷惑メールフィルタのカスタマイズをいくらでもできる</li>
etc.</li> </ul>
ついでに、アプリパスワード (メーラ (MUA) 用に管理画面のログインパスワードとは別のパスワードを発行するセキュリティ機能) に対応しているのも嬉しい。</p>
無論、可用性を非常に高く維持したいとか、迷惑メールとして弾かれては絶対に困るとか、とんでもない大量送信を考えているとか、そういった事情があるなら既存の有償サービスを用いる方が良い。だが事業で使っているわけでもない個人のメールアドレスにそこまでシビアな要求はないし、どうしてもそこまでシビアな条件が必要になったらそのときは別のメールサービスを併用したって良い。有償のメールサービスを使っていたとて、待ち望んでいたメールが迷惑判定されて気付かなかったり受信もできず弾かれたりなどといったことはしょっちゅう起きている。サーバが安定稼動していれば安心というものではないのだ。</p>
つまり自前でメールサーバを持たない理由は保守管理とセキュリティ維持のコストくらいしかない。保守管理については Docker ベースなこともありアップデートがかなり簡単なので、リリースノートの確認さえしっかりしておけばそうそうハマることはないはずである。セキュリティについては、 Mailu は既存のメジャーなソフトウェアと独自の管理画面・設定生成ソフトの組み合わせという形で提供されており、後者が安全な設定の生成を担っている。メール関係のプロトコルに関するコアの部分で独自実装はそこまでしていないはずなので、既に社会的信用のあるソフトウェアの占める割合が多く、それ以外の部分に問題があったとしてもそのソースコードの確認や修正に手を出しやすい。結果として、すべて自前で設定を詰めて複数のコンポーネントの連携をセットアップするよりも相対的にずっと楽で安全であることが期待できる。 (もちろんメールサーバに限らず、ソフトウェアをどこまで信頼してどこまで疑うかは利用者次第だが。)</p>
</a>Ntfy</h4>

ntfy.sh | Send push notifications to your phone via PUT/POST</a></li> </ul>
汎用の通知サービスのサーバ。 Android クライアントを入れれば Android スマホに「通知」を発することもできるし、同時に PC で通知を受け取ることもできる。メールとメーラほど重い仕組みは必要ないがいろいろなデバイスで通知は受け取りたいし簡単に通知を送信したいという場合に便利。</p>
スケジュール関係のイベントやサーバ等で発生した障害などの通知で使うつもりで立てたが、いろいろあって今のところメールで済ませがち。最近またこちらを積極的に使っていくことを検討しているが、どうなるだろうか。</p>
</a>Mattermost</h4>

Mattermost | Collaboration Platform for Mission Critical Work</a></li> </ul>
Slack の競合のようなもの。</p>
チャンネルを分けたり通知を受け取ったり bot を動かしたりなどできるため、何らかの自動化と通知、あるいは日記や雑な記録スペースなどに使えないかと思ってとりあえず立てているが、現状では全然使っていない。</p>
bot による自動化については Mattermost に乗せるよりも ActivityPub 経由とかでできる方が面白かったりしないだろうか等の雑念があるため、まだ 方針を決めかねている</a>が、 Mattermost はちょっと過剰かなという感覚がある。単に通知を受け取るだけなら先述の Ntfy</a> で良いしそちらの方が軽量なのだが、たとえば通知に対して特定の絵文字でリアクションを付けると返信扱いにできるなどといった簡単な双方向の交信を視野に入れると、 SNS やチャット系の実装の方が Ntfy では届かないところにまで手が届くのでどうしたものか、といったところ。</p>
日記や生活関係のログについては……そもそも1日1文ですら書かなくなる性質なのでもちろん滞った。</p>
</a>コンテンツ鑑賞記録</h3>
</a>BookWyrm</h4>

BookWyrm: Social Reading and Reviewing</a></li> </ul>
読書管理のシステムに ActivityPub プロトコルでの SNS 機能がついたサービス。概ね 𝕏 (formerly Twitter) 連携のついた 読書メーター</a>からリコメンド系の機能を除外したようなもの。</p>
書誌情報をデータベース系サイトから取得してくる機能もあるのだが、例のごとく日本語圏では使い物にならなかったりするので、読んだ本の情報をいちいち入力していくことになるのは正直それなりに面倒。そんなに時間はかからないので慣れたが。</p>
あとはノベルゲームも広義ノベルということで、それらも管理している。オーディオブックがありならノベルゲームもありだろう。</p>
</a>Ryot</h4>

Ryot</a></li> </ul>
アニメや映画の鑑賞やゲームプレイをはじめとした、任意の行動の記録のためのサービス。</p>
私は専らアニメと映画とゲームの記録に使っている。</p>
</a>コンテンツ管理</h3>
</a>Navidrome</h4>

Navidrome</a></li> </ul>

</div></div>
Navidrome でのアルバム一覧 (ランダム順序) 画面</figcaption> </figure>
音楽サーバ。プレイリスト管理もできるので、どちらかというとそれを目当てに使っている。</p>
昔は PC にローカルに音楽ライブラリを持って MPD (Music Player Daemon)</a> を立てて使っていたが、これだと同期に一手間必要なのと、音楽ライブラリのコピーを PC ごとに持っておく必要があり無駄があった。特にスマホだと音楽を全て端末に持っておきたくはないが、それでもプレイリストは編集したいことがあった。 (これは外出時にスマホではなく WALKMAN で音楽を聴いていたせいでもある。)</p>
そこで音楽サーバを立てて NAS 上の音楽ライブラリを利用させ、プレイリストもサーバ側で持つことで、同期の手間を解消しつつスマホ等からもプレイリストを編集できるようにした。</p>
そのうちプレイリストをダウンロードしてきて WALKMAN 向けに変換するスクリプトを書こうと思っているが、まだ手をつけていない。</p>
</a>開発</h3>
</a>Forgejo</h4>

Forgejo – Beyond coding. We forge.</a></li> </ul>

</div></div>

</div></div>
Forgejo でのダッシュボード画面とコミット一覧</figcaption> </figure>
Git サーバに、プロジェクト管理に便利な諸々の機能と web UI を付けたサーバアプリ。 GitHub や GitLab のようなもの。 Gitea の fork であると言えばわかる人にはわかるかもしれない。</p>
私はソフトウェアを書くときは基本的に公開して問題ないように作るのでリポジトリも GitLab や GitHub に投げがちだが、個人的な情報や機微情報を含むようなもの、あるいは自分で作ったわけではないものは公開せず自前インフラ内に抱え込みたい。そういったものを管理しつつ web UI 等から閲覧できるようにするために Forgejo を使っている。</p>
また、単に秘密にするだけでなく自前インフラの CI (Continuous Integration) (後述の Woodpecker CI</a>) を利用したいリポジトリも置いている。</p>
</a>Woodpecker CI</h4>

Woodpecker CI | Woodpecker CI</a></li> </ul>

</div></div>
Woodpecker CI 上でのテスト結果履歴画面</figcaption> </figure>
CI (Continuous Integration) サーバ。 git サーバに push されたコミット等に対して自動でビルドやテスト等を実行して、問題がないか確認するソフトウェア。</p>
GitHub などを見るとコミットにチェックマークが付いていたり×マークが付いていたりするが、あれを判定するためのものである。ビルドやテストといってもいろいろな環境や設定や確認事項がありうるため、それら複数の構成のビルドやタスクをクリーンな環境ですべて実行してくれるのが便利。これを開発機でやろうとすると、限られた CPU とメモリ資源で同じ環境を使い回して実行することになりがちなので、効率が悪かったり手間がかかったりする。</p>
実は自宅にサーバを持とうと決めた一番の理由がこの CI サーバである。確認する設定の組み合わせを十分に増やすと 無料で使える枠をすぐに食い尽くしてしまう</a>ため、心行くまでテストするには自前で CI インフラを 持つしかなかった</a>。そして CPU もメモリもあればあるだけテストの並列実行数を増やせるので、サーバは多ければ多いほど良い。 CI を走らせていない間は別のことにリソースも使えるし。</p>
</a>SNS</h3>
</a>Mastodon</h4>

Mastodon - 分散型ソーシャルネットワーク</a></li> </ul>
各々が自前でサーバを立てて通信しあうことで成立する SNS プロトコルである ActivityPub の、マイクロブログ系実装のひとつ。 Misskey なども同じ ActivityPub プロトコルに対応しているので、 Misskey のアカウントをフォローすることもできる。</p>
BookWyrm</a> も ActivityPub に対応しているので、たとえば Mastodon 上のアカウントから BookWyrm 上のアカウントをフォローすると、BookWyrm 側で投稿した読んだ本や感想などが Mastodon 側アカウントのタイムライン上に流れてくるようになる。</p>
𝕏 (formerly Twitter) をはじめとするプロプライエタリなサービス (Threads や mixi2 なども含む) に依存したくないので、手元でサーバを動かせる自由ソフトウェア実装ということで使っている。 Bluesky は……主張している特性に実装が追い付いていない印象があるので、規格や思想はさておきメジャーな開発陣への信頼が微妙 (存在しないものを喧伝しないで、実装できてから言ってくれ)。</p>
</a>外部公開用</h3>
</a>web サイト</h4>

Caddy - The Ultimate Server with Automatic HTTPS</a></li> </ul>
このサイト (waf.nopth.ink) を含むいくつかの静的なウェブサイトも自宅サーバにホストしている。 web ページスペースというやつは基本的に面倒な管理方法を要求されたり機能に制限があったりして面倒だし、かといってわざわざ VPS 上のお高い計算リソースを使うほど可用性が重要でもないので、自宅に立てるのが丁度良い。</p>
</a>Shlink</h4>

Shlink — The URL shortener</a></li> </ul>
短縮リンクサービス。</p>
基本的に使っていないが、何か URL を人に口頭や映像で共有したいとき短い方が良いという場合に備えて用意している。</p>
</a>サーバクラスタ内部向け機能</h3>
</a>MinIO</h4>

MinIO Object Storage for Linux — MinIO Object Storage for Linux</a></li> </ul>
Amazon S3 互換のオブジェクトストレージ。データ (特に多いのは動画や画像等のメディアだがそれに限らない) を保存する先のオンラインストレージとして、いろいろなアプリケーションが対応している。</p>
自宅のありあまる (そんなに余っていないが) ストレージを使えば、転送量課金などを恐れる必要はないし少なからぬ割合の通信が宅内で済むことが多いので、 SaaS を使うよりも経済的である。</p>
</a>Apt-Cacher NG</h4>

Apt-Cacher NG - Software Package Download Proxy</a></li> </ul>
Debian のパッケージ配布サーバなどのキャッシュプロキシとして使えるサーバ。</p>
宅内に仮想マシンやコンテナを含めて数十もの Debian 環境があり、それらが各々インターネット上のミラーサーバに接続するのはあまり行儀が良くないので、一度キャッシュプロキシを通ったものはそれ以降宅内からリクエストされてもミラーサーバの帯域を使わずに済むようにしている。</p>
</a>CNCF Distribution</h4>

Distribution | CNCF</a></li>
CNCF Distribution</a></li> </ul>
Docker レジストリのキャッシュプロキシサーバ。</p>
docker.io のレジストリはレート制限が厳しく、またインターネット側のサービスやインターネット接続自体に問題がある場合でも諸々の Docker を利用したサービスは起動できるようにしておきたいので、宅内でキャッシュしている。</p>
</a>Proxmox Backup Server</h4>

Proxmox Backup Server - Open-Source Enterprise Backup Solution</a></li> </ul>
Proxmox VE との連携が強力な、バックアップ管理サービス。</p>
優れた差分バックアップや自動的なクリーンアップなどが使えて便利。 Proxmox VE 上で動かしているサーバのバックアップは基本的にこれで十分。</p>
</a>おしまい</h2>
紹介パートは良いとして、最後に教訓を再掲しよう。</p>

VPS を2年以上借りている人は今すぐ自宅にサーバを持つべきである。</li>
NAS は最初からベイが多いものにしておくべきである。ただし騒音レベルは事前に確認しておくこと。</li> </ul>
「サーバをそんなに積んで何に使っているの？」の次は「ストレージをそんなに積んで何を置いてるの？」に答える必要があるかもしれない…… なんでや計算機リソースはあればあるほどいいだろ！ (錯乱)</p>

ActivityPub サーバとクライアントの特殊化のミスマッチ

2025-01-05T07:21:25+09:00

現状の ActivityPub エコシステムでは、サーバがコンテンツの種類を強く縛りすぎていると思う。</p>

</a>名誉を集約し、楽しみ方をカスタマイズする</h2>
ActivityPub では多様なアプリケーション (サーバもクライアントも) が共通のプロトコルを利用して相互に投稿をやりとりできるのがネットワークとしての大きな魅力のひとつだが、その運用を便利にしようと考えるとき、私の考える便利な方向性とは「ひとつのアカウントから多様な情報を発信しつつ、フォロー先の投稿を見るのは情報の種類に特化したクライアントで行う</strong>」といったものである。</p>
ここでいう多様とは、たとえばブログ記事、たとえば写真、たとえば中編動画、たとえば短文投稿、たとえば音楽、たとえばソーシャルブックマーク、といったように性質レベルで大きく異なる投稿の種類のことで、旧来であればこういったものは投稿の種類ごとに別々のサーバ、別々の web サービスで扱われていたものであった。これらの発信源を単一アカウントにすることで、「特定の人が作成した/発信したもの」という発信者 (あるいはクリエイター) のアイデンティティの統合ができるという点で個別の web サービスを使うよりも便利になる。対してユーザは、見たい投稿の種類ごとに UI 体験が特化したクライアントを用いてタイムラインを眺めることで、全てが雑然と汎用的な形でのみ流れてくる状況を回避できることを望むだろう。受信に関しては自由度があり、アカウントとサーバを別にしても良いし、サーバサイドで投稿種別ごとにフィルタリングできても良いし、クライアント側でフィルタリングできても良い。受信さえできていればやりようはある。</p>
端的に表現するなら、「発信者は創造や情報発信の名誉をひとつの名義に集約できる</strong>べきで、受信者は受け取った多様なコンテンツの楽しみ方をカスタマイズしやすい</strong>べきである」ということになる。</p>
</a>ActivityPub エコシステムの現状</h2>
しかし現実の ActivityPub fediverse をいちユーザとして見てみると、私の考える理想とは全く逆方向に機能している。つまり「多数のアカウントから情報を発信しつつ、フォロー先の投稿を見るのは汎用の (あるいは単一種類の投稿を主に想定する) クライアントで行う</strong>」という状況が一般的なようである。</p>
人々は投稿の種類ごとに別々のサーバ実装 (そして当然別々のアカウント) から発信し、フォローと受信は単一のアカウントから行っている。たとえば短文は Mastodon から、写真は Pixelfed から、長編動画は PeerTube から、ブログは Write.as から、といった具合である。そして各種投稿のビューの形も、フォロー元アカウントのサーバ実装に特化した形になりがちである。たとえば Mastodon からフォローしている場合は写真であれ動画であれ音楽であれ長文記事であれ、すべての投稿を「短文投稿 SNS 上での投稿」の形で閲覧することになる。</p>
</a>サーバは投稿種別に中立であることが望ましい</h2>
思うに、このような逆転が発生している原因は「サーバ実装が (発信、受信ともに) web UI と強く紐付いている」ことにある。発信側サーバが特定の投稿種別に特化した web UI を (あるいはそれに加えて内部的な実装を) 持っていると、他の形式の情報を同じアカウントから発信しづらくなる (あるいはそもそも発信できなくなる)。そして受信側サーバが特定の投稿種別に特化した web UI を (あるいはそのようなクライアント API のみを) 持っていると、「アカウントは同一だが異なるクライアントを目当ての投稿種別ごとに使い分ける」という利用法が成り立たない作りになりやすい。</p>
このような問題を解決するためには、サーバが送受信いずれにおいても特定の投稿種別を前提としたりそれに特化したりせず、内容に中立なまま投稿の送受信とクライアントへの伝達に注力することが望ましいだろう。そして可能ならもうひとつ、投稿・閲覧のための web UI を用意しないこと、あるいは用意するとしても特定の利用方法を前提にした味付けをしないことが望ましい。サーバは用途不定のネットワークの一部としてコンテンツに対して中立であれということである。投稿やそのインターフェースを味付けするのはクライアントが専任であるべき仕事だ。</p>
とはいえこれは ActivityPub の client to server API のように中立なプロトコルがサーバ–クライアント間でも一般的にならないと難しいような気もするが。そんな日が来るのだろうか？</p>

ポリデント

2025-01-04T22:32:27+09:00

ソフトウェアに潜むポリデントの話。</p>

</a>インデント</h2>

インデントとは、木構造のある行の列をテキストで表現するとき行頭に詰める空白文字、あるいはその行為のことである。</p>

int </span>main</span>(</span>void</span>) {
</span>    </span>return </span>0</span>;
</span>//↑この空白がインデント
</span>}
</span></code></pre>
* 項目
</span>    + リストアイテム1
</span>    + リストアイテム2</span><!--
</span>↑この空白がインデント-->
</span></code></pre>
</a>インデントの流儀</h3>
インデントには、「何をいくつ詰めるか」で複数の流儀がある。
(これらはしばしば俗に言う「宗教戦争」のテーマとなっているが、今回それには触れない。)</p>
いくつか例を挙げよう。</p>

1レベルごとに空白 (0x20, ' '</code>) を2文字</li>
1レベルごとに空白を3文字</li>
1レベルごとに空白を4文字</li>
1レベルごとに水平タブ (0x09, '\t'</code>) を1文字</li>
1レベルごとに空白を2文字、ただし4レベル分 (空白8文字分) ずつまとめて水平タブに置き換える</li>
1レベルごとに空白を4文字、ただし2レベル分 (空白8文字分) ずつまとめて水平タブに置き換える</li>
</ul>
</a>水平タブと空白の混合</h3>
空白が増えてきたらまとめて水平タブに置き換える流儀では、エディタのタブ幅によって表示が壊れやすい。
標準的なターミナル等では水平タブは8文字幅だが、テキストエディタの設定によっては4文字幅で表示する場合などがあるからだ。
プロジェクト側でタブ幅の設定ファイルを持ちテキストエディタにそれを優先させるという手段で回避できるが、とにかく一手間必要になる。</p>
void </span>foo</span>()
</span>  {
</span>// ↑空白2つ
</span>    </span>if</span>(bar)
</span>// ↑空白4つ
</span>      {
</span>// ↑空白6つ
</span>        </span>baz</span>(
</span>// ↑タブ文字1つ
</span>          qux0,
</span>// ↑タブ文字1つ + 空白2つ
</span>          qux1,
</span>          qux2,
</span>          qux3,
</span>        );
</span>      }
</span>  }
</span></code></pre>
こうしたブロックレベルを表現する場合では、水平タブと空白の混合は (たしかに実在はするものの) 特定プロジェクト等が採用していたりするのみで、頻繁にそこら中でみられるような流儀ではない。
しかし、これが局所的に発生しやすい文脈もある。</p>
    </span>if </span>(!dry_run) {
</span>//↑タブ1つ
</span>        </span>prepare</span>();
</span>//↑タブ2つ
</span>        </span>letsgo</span>(param0,
</span>               param1,
</span>//↑タブ2つ + 空白7つ (!?)
</span>               param2,
</span>               param3);
</span>    }
</span></code></pre>
関数定義や関数呼出において引数が多かったり長かったりするとき複数行に跨がることがあるが、このとき最初の引数を別の行にしない流儀では関数名と開き括弧の分 (あるいは、加えて括弧の前の空白分) の空白で引数の先頭が揃うようインデントを追加する派閥がある。
この場合、引数用のインデント幅は関数名の長さに依存し固定幅の水平タブでは表現できないため、どうしても空白文字を使うことになる。
ブロックインデントを水平タブで行っていた場合、めでたくタブ+空白の混合インデントの完成だ。</p>
</a>ポリデント</h2>
水平タブ+空白の混合インデントのように多数 (poly) の種類の空白を用いるインデント (indent) のことを、個人的にポリデント</strong>と呼ぶことにしている。</p>
この記事はこれを紹介するためだけに書かれた。</p>
</a>おまけ</h2>

ポリデントが “宗教戦争” のオチ要員として使われている例: [Home] Tabs Spaces Both</a></li>
</ul>

write-and-forget

2024-12-25T19:01:22+09:00

markdown で妥協して新しくブログを作ることにした。</p>

</a>HTML では足りない！</h2>
メタデータや意味を十全に与えたいと考えたとき、 markdown は言うに及ばず、ある種の拡張なしの HTML であっても表現力に不満がある。</p>
</a>blockquote が貧弱すぎる</h3>
たとえば HTML で何らかのまとまった引用をしたいとき用いる `blockquote</code> タグを考えてみよう。 blockquote</code> に特有の意味を与えられる機構は cite</code> 属性と cite</code> タグのみである。</p>`
Content inside a blockquote</code> must be quoted from another source, whose address, if it has one, may be cited in the cite</code> attribute.</p> </blockquote> HTML LS の cite 属性の解説 (2024-12-16</time>)</a></p> </figcaption> </figure> The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.). This can be a work that is being quoted or referenced in detail (i.e., a citation), or it can just be a work that is mentioned in passing.</p> </blockquote> HTML LS の cite タグの解説 (2024-12-15</time>)</a></p> </figcaption> </figure> それ以外の情報は、著者や発言者も、参照日時も、出版日や版も、「強調は引用者による」も、区別して表現するためのタグや属性はない。</p> MDN</a> に載っている例では以下のようになっている:</p> <</span>figure</span>> </span> <</span>blockquote</span>> </span> <</span>p</span>>It was a bright cold day in April, and the clocks were striking thirteen.</</span>p</span>> </span> </</span>blockquote</span>> </span> <</span>figcaption</span>> </span> First sentence in <</span>cite</span>><</span>a </span>href</span>="</span>http://www.george-orwell.org/1984/0.html</span>">Nineteen Eighty-Four</</span>a</span>></</span>cite</span>> by George </span> Orwell (Part 1, Chapter 1). </span> </</span>figcaption</span>> </span></</span>figure</span>> </span></code></pre> そう珍しいものではない形式の引用だが汎用のマークアップ (figure</code> と figcaption</code> 要素) で記述せねば紐付けられず、また "George Orwell" が著者である (しかし発言者ではない) ことは figure</code> 要素でマークアップしてなお機械可読に表現されていないことがわかる。もちろん「(中略)」を本文と区別して表現する能力もない。</p> もちろん「(中略)」を本文と区別して表現する能力もない。</p> </blockquote> 万が一このような引用をする羽目になったら、「(中略)」が本当に何かを略しているのか、それとも単に記号列として「(」「中」「略」「)」が元からあったものなのか、引用の外側から補足が必要になる。もっとも、機械可読に表現可能だったとしても補足するに越したことはないであろうが。</p> 似たような問題で、訳註が存在する文書をさらに翻訳して訳註を加えた場合にどれが翻訳前文書内の訳註でどれが最終翻訳者による訳註なのかマークアップで区別する標準的な方法がないというのも、 HTML の引用まわりの表現力の弱さの一例である。</p> さらには markdown では figure</code> 要素どころか cite</code> 属性でさえ生の HTML の挿入なしに記述できない。技術文書ばかりでなく日常的な文書であっても markdown や素朴な HTML では圧倒的に表現力が不足しており、 HTML タグに microdata なり RDFa Lite なりの追加仕様を組み合わせてはじめてまともなレベルになるわけで、喩えるなら高級言語を許されずアセンブリ言語を使わされているばかりか CFI directive まで常用せねばならないようなものである。 (一応 microdata は WHATWG HTML 標準内で定義されているようだが……。) このような迂遠なものを頻繁に作成し長期間メンテナンスするような文書群で使いたくはなかった。</p> </a>参照能力と参照外し能力の欠如</h3> HTML で markdown よりマシになるならタグが足りずともひとまず HTML で書けば良いではないかという話になるわけで、部分的には実際その通りなのだが、話はそれで終わらない。上に挙げた例は microdata のような追加のメタデータで意味を与えれば解決できる問題だったが、根本的に重複なしでの記述が難しい課題がある。それはクロスリファレンスや目次 (ToC) だ。</p> たとえば同じページ内の特定のセクションへリンクしたいとき、そのリンクのテキストをセクション名から持ってきたり、あるいはセクション番号を利用したいということはあるだろう。 ToC (目次, Table of Contents) はその最たる例である。 HTML ではこれが自動化できず、自分でテキストを複製してきたりカウントして数字を直接使わねばならない。一応 CSS でカウンタを使うことはできるが、その数字はあくまでスタイリングに使うことしかできず、マウスでドラッグして選択可能な本文として配置することはできない。本文の一部としてそういった参照をしたくばソース中で複製・決め打ちする他なく、つまり文書を編集する際にミスして一貫性がなくなる (数字や文字列が実態と一致しなくなる) 可能性がそれなりに高い。</p> footnote (脚注) も同じような問題を抱えており、 footnote をまとめる footer なり aside</code> 要素なりにおける記載と、マウスホバーしたとき表示されるツールチップ (素朴には title</code> 属性で実装できる) で同じ文章を表示しようとすると、ソース中でのテキストの複製が必要になる。 JavaScript を使えばどうにかできるにはできるが、それはむしろ HTML ではどうにもならないと言っているようなものである。静的な文書に後付けの動的な機構を必須としたくはない。</p> このような問題を抱える HTML という形式は、人間が保守する前提のしっかりしたドキュメントのソースファイルに適しているとはいえない。</p> </a>他にもいろいろ不足あり</h3> DocBook 5 の要素一覧</a>と比較すれば、 HTML の語彙がいかに貧弱で原始的であるかわかるだろう。 HTML では用語集も Q&A も全て dl</code> タグで表現することになるし、ファイルパスも変数名も短いコード片もすべて code</code> タグで表現することになる。</p> HTML ではそのように情報を潰して潰して、それでもどうにかスタイルを変えるとよさそうなものだけを区別した結果が今定義されているタグなのであって、根本的に機械可読な意味を残すための形式ではない。あくまで出力 (特に表示と印刷) のための形式か、あるいは編集がギリギリできるくらいの中間形式と捉えるくらいが妥当で、セマンティックな入力として最適に作られた形式と考えるべきではない。</p> </a>markdown で諦める (ただし限定的に)</h2> これだけ不満がありながら markdown を使うことにした理由は、単にこの調子でやっていくと記事にできたはずの考えまでどんどん揮発していきそうで、それはそれで非常に良くないと思ったからである。最近 (というほど最近でもないが) XML 処理系を字句解析器レベルから自分で実装しようとしており (libxml2 と libxslt は偉大だがどうにも満足できない事情があった)、進捗は確かにあるもののこの調子ではあと何年かかるかわかったものではない。 markdown のように意味を込めるのが難しい形式であっても、そもそも意味を込める意義の薄い用途に限っては使い物になる。</p> 旧ブログではどんなに長く技術的な情報であっても、あるいはどんなに私的でどうでもいい情報であっても、無関係に豊かな語彙を活用して同じ場所にブログ記事としてしたためていた。しかし冷静に考えて、誤った実装方法を警告する記事と技術的思想の解説記事と私的な日記が区別されず同居しているのは明らかに体験が悪い。体験が悪かろうと区別が難しければ同居させるしかないことを私はここ十数年の SNS アカウント運用で身をもって学んだわけだが、そうはいってもやはり明らかに性質の異なる記事というのは存在するのである。</p> その「性質」が最も極端なのが、日記である。日記は後から書き直したり改善することが滅多になく (稀に追記やリンク URL 修正はあるかもしれない)、紐付けられたプライマリな日時が文脈として本質的に重要で、かつ正しさを価値判断の基準に持たない。 (一応補足すると、これは正しいことが価値を生まないという意味ではなく、誤った記述があるという事実そのものにも価値が認められることがあるということ。)</p> 何より個人的に、他人の私信とかいうやつは、ごく一部自分に刺さるトピックのものを除いてかなりどうでもいい。日記の価値の8割くらい (数字は適当) は、他人に読まれることではなく自分に読み返されることによってその存在意義を回収するのではないだろうかと思えるほどである。かような日記という空虚でどうでもいい記事群は、他人が読んで役立てられる前提の “どうでもよくない” 記事と同列で扱うようなものではなく、相応に人目につきづらい日陰に埋もれさせたい。となれば、日記を正しく weblog として分離して、日記でなく正しさが重要でメンテナンスに値するような記事を別の場所でリッチにやるというのが妥当に思われる。</p> そういったわけで、このたび日記や雑感の集積場所としてのブログをこうして分離して、こちらは既存実装で雑に用意することにした。この文脈であれば、むしろ表現力が弱いという制約は「表現力が欲しくなるような用途に使うべからず」という誓約としてポジティブに機能させられよう。そして本文形式を高度に拡張可能な static site generator を使わないことで、「埋もれるべき日陰の場所を必要以上に “良く” しない」という自分への枷とする。このブログは (現時点では) Zola</a> を使っており、これは shortcode の定義機能</a>などがあるという点では高度だが、本文が基本的に markdown 前提であるという点では拡張性に乏しい。</p> </a>旧ブログを使わない理由</h2> 実はオレオレ XML スキーマを利用して書けるブログを nanoc</a> で用意して既に持っている。 nanoc は極めて拡張性が高く、本文が markdown である必要がないばかりか、オレオレ XML 文書を HTML にすることもできる。そちらを使わず自力で XML 処理系を実装する理由はいくつかあるが、端的には Rust で書きたいから (あるいは Rust 以外で書きたくないから) ということになる。</p> nanoc はキャッシュの仕組みがあってなおまあまあ遅かったり、フレームワークから少々外れたところでがっつりコードを書くことになったり、既存のフィルタも処理を改変したいため自分でパッチをあてる羽目になったり、 XSLT 1.0 範囲での記述だと面倒で汎用言語のロジック表現力を使いたかったりなどで、現状の旧ブログではあまり素直に nanoc に乗りきれていない。また nanoc では、 XSLT によるレイアウトは XSLT 側での import や include による依存追跡がうまくできずキャッシュが不適切に利用されてしまったり、 XSLT でのレイアウトはページあたり1回しかできないため複数段の XSLT スタイルシート適用が素直にはできないという問題もあり、 XSLT の利用は手厚いサポートを受けているとはいえない状況である。これは XSLT 前提でオレオレ XML を書きまくっている私にとっては懸念材料で、それならいっそ最初から Rust で書いた方がコントロールも効くし便利で楽しいだろうということで自前実装を試みることになった。</p> そしてその自前実装が完成するまで待つほどのことでもないような記事を書き出す先として、また先述のように「どうでもいい」記事を隔離する場所として、新たにこのブログを用意した。</p> </a>write-and-forget</h2> このブログに置く記事の基準はただひとつ、「書いたきりノーメンテナンスで、あるいは最小限の追記に留めて放置することに躊躇いがないこと」である。</p> たとえば次のように判断する。</p> 「この日こういったことがあった、こう感じた」は当時の事実認識のスナップショットとして価値があるので良い。認識が変わってどうしても補足したくなったら、後日に紐付けて別の記事を作ってリンクだけ追加する。旧記事そのものを訂正してはいけない。</li> </ul> </li> 「このバージョンの処理系ではこう書くのが正しい」は「後のバージョンでは別のこのような書き方が正しい」と大きめの情報を補足したくなるので望ましくない。「このバージョンの処理系にこういったバグがあった」までなら「後のバージョンでは直った」という僅かな追記で済むので良い。</li> </ul> </li> 「こういったトラブルがあったのでこう対処した (できなかった)」は、成果がなかろうと誤っていようと作業記録としての価値があるので良い。誤ったリスクある手順があとで発見されたら「この手順は適当でないので真似してはいけない」程度の追記で済ますこと。正しい手順を長々と解説しようとするのは望ましくない。誤っている理由の追加くらいはあっても良い。</li> </ul> </li> </ul> </li> 製品の評価 (レビュー) などは、各種観点あるいは総合的にみての評価という特定構造のメタデータを共通して持つような記事なので望ましくない。多少なりとも機械可読な情報を提供したい気持ちがあるなら、最初からそのように設計したり後から既存データの構造を弄れるような柔軟なシステムに乗せるべき。</li> あくまで感想や経験を主観的に述べるものであって結論として点数をつけたりしないようなものであれば、まあ良いか……</li> </ul> </li> </ul> このような性質を、 fire-and-forget という概念をもじって write-and-forget</strong> と呼ぶことにした。 fire-and-forget</a> とはミサイル兵器だけでなくしばしばプログラミングの文脈でも用いられる概念で、ミサイルやリクエストやタスクをひとたび fire (発射) すればその後の動作を監視したりコントロールする必要がないという性質のことである。</p> そしてこのブログを write-and-forget メディアにするという戒めとして、 waf_thread</code> と命名することにした。今後このサイトには忘れられるべき記事が打ち捨てられていくことになるだろう。</p>

</a>やっていき</h2>
2026年はもっとカメラで遊んでいきたい (言うだけならタダ)。</p>
(ところで風景パズルで思い出したが、7年前に買って少しだけプレイしてからずっと放置している The Witness</a> どうしよう……。)</small></p>

`</a>おわりに</h2> “本物” になろう。</p>`

</a>おまけ</h2>

ポリデントが “宗教戦争” のオチ要員として使われている例: [Home] Tabs Spaces Both</a></li> </ul>

waf_thread

便所は人を呪う

2025年まで (含む) の意識低いカメラライフまとめ

絶叫し先走る全知の魔

くだらない小ボケにツッコミされることを鬱陶しく思うことに不思議はない

反語を使わない理由があろうか。いや、ない。

冥福と、浅ましい祈り

自宅サーバの使いみち (2025-Q1)

『メイクアガール』感想 (ネタバレあり)

美しき機能停止

ザ・俺

ActivityPub サーバとクライアントの特殊化のミスマッチ

ポリデント

write-and-forget

waf_thread

便所は人を呪う

2025年まで (含む) の意識低いカメラライフまとめ

</a>沖縄の自然</h3> </a></div></div> 茂みから垣間見えた猫 </figcaption> </figure> 猫が見えたので、フレームで囲いつつ前ボケで具体性を喪失させる。 なるほどね。 スタンダード構図再現ポイントが高い (?)。</p>

</a>リリス</h3> </a></div></div> リリス </figcaption> </figure> 同じような姿勢のリスが2匹、フォーメーションでも組んでいるのかという並びで姿を見せた一枚。 鉄道車両を複数並べるときこういう見せ方をしがちな気がする。</p>

絶叫し先走る全知の魔

くだらない小ボケにツッコミされることを鬱陶しく思うことに不思議はない

反語を使わない理由があろうか。いや、ない。

冥福と、浅ましい祈り

自宅サーバの使いみち (2025-Q1)

</a>Shaarli</h4> Shaarli documentation</a></li> </ul> </div></div> Shaarli での公開ブックマークリスト</figcaption> </figure> シンプルな UI の web ブックマーク管理ソフト。</p>

</a>Navidrome</h4> Navidrome</a></li> </ul> </div></div> Navidrome でのアルバム一覧 (ランダム順序) 画面</figcaption> </figure> 音楽サーバ。 プレイリスト管理もできるので、どちらかというとそれを目当てに使っている。</p>

『メイクアガール』感想 (ネタバレあり)

</a>性癖</h2> 大変刺さった。</p> </a>セルフ首絞め</h3> そもそも完全にノーマークだったのに観ることにした決め手が、 PV の首締めシーンだった。</p> </div></div> 不本意な自傷を強いられる女の子、とても良い。</p>

</a>セルフ首絞め</h3> そもそも完全にノーマークだったのに観ることにした決め手が、 PV の首締めシーンだった。</p> </div></div> 不本意な自傷を強いられる女の子、とても良い。</p>

美しき機能停止

ザ・俺