しっぽのさきっちょ [text.Baldanders.info]

Mastodon 10年史を AI に語らせてみた

2026-04-16T10:32:24+09:00

Mastodon の TL を眺めてたら mstdn.jp が10年目に突入したというポストを見かける。 mstdn.jp が10年目に突入したということは，Mastodon 自体は丸10年経ったということになるか？

ここで Mastodon の10年を振り返る記事を書いてみたら面白いと思ったのだが，実は Mastodon って（特に歴史的な部分は）よく知らないんだよね。なので，AI に Mastodon の10年史を語らせてみることにした。

利用サービスは GitHub Copilot with VS Code，選択モデルは GPT-5.3-Codex で行っている。ではどうぞ。

Mastodon が最初に公開されたのは 2016 年です。2026 年は公開から丸10年の節目で，分散型 SNS の歴史を振り返るには良いタイミングだと思います。

Mastodon 略歴（ざっくり）

2016年: Eugen Rochko 氏が Mastodon を公開。Twitter に似た操作感を持ちながら，サーバーを分散運用できる設計が注目される。
2017年: 各地で個人・コミュニティ運営のインスタンスが増加。日本語圏でも利用者が急増し，「連合（Fediverse）」という言葉が広まりはじめる。
2018年ごろ: ActivityPub を中心に，Mastodon 以外の実装ともつながる流れが強くなる。単体サービスではなく「相互接続できるSNS群」としての性格が明確になる。
2019年〜2021年: 大規模な爆発的成長というよりは，コミュニティ運営やモデレーションの知見が蓄積される時期。ローカルルール重視の文化が定着。
2022年: 主要SNSの環境変化をきっかけに，Mastodon への関心が世界的に再上昇。新規インスタンス立ち上げや移住が加速。
2023年〜2025年: 一時的なブームを越えて，日常的に使う人とコミュニティが残るフェーズへ。Mastodon は「代替先」ではなく，独自の選択肢として位置づけられていく。

ここまでを一言で言えば，Mastodon の10年は「中央集権型の巨大SNSに対するカウンター」から始まり，「分散型コミュニティ運営の実践知」を積み重ねた10年でした。

この記事では，この略歴をもう少し丁寧に追いながら，技術・文化・運用の3つの観点で整理してみます。

技術面: Mastodonの10年

技術面で最初に押さえるべき点は，Mastodon が単なる「Twitter風アプリ」ではなく，最初から連合を前提にした実装だったことです。単一サービスの拡張ではなく，サーバー同士の接続を前提にした設計を採ったことで，後の Fediverse 全体の成長に直接つながりました。

1. プロトコル中心への転換

初期の利用者体験は Web UI の分かりやすさに注目が集まりましたが，長期的に効いたのは ActivityPub を軸にした相互接続性でした。これにより，実装が異なるソフトウェア同士でもフォローや投稿配送ができるようになり，「アプリを選ぶ自由」と「コミュニティをまたぐ接続性」が両立しました。

2. 実装の成熟とクライアント多様化

10年のあいだに，Mastodon 本体は機能追加だけでなく，安定性や管理機能の面でも成熟しました。同時に，公式クライアント以外の選択肢も増え，ユーザーは自分に合う UI やワークフローを選べるようになりました。分散型サービスでは，この「クライアント多様性」が継続利用のしやすさを支える重要な土台になります。

3. 分散設計が生む技術的トレードオフ

一方で，分散設計は常にメリットだけではありません。サーバー間配送の遅延，モデレーション方針の差，メタデータや検索範囲のばらつきなど，中央集権型では見えにくい課題が日常的に現れます。ただし，これは欠点というより，「一つの正解に全員を合わせない」設計思想の裏返しでもあります。

4. 2026年時点で見える技術的意義

2026年の時点で見ると，Mastodon の技術的意義は，巨大プラットフォームに代わる機能を再実装したことではなく，「SNSの相互運用を現実にした」点にあります。実装の競争軸を囲い込みから接続性へ移したこと自体が，この10年で最も大きな技術的成果だと言えます。

文化面: Mastodonの10年

文化面で特徴的なのは，Mastodon が「プロダクトの利用規約に従う場」よりも，「コミュニティの合意で育つ場」として発展してきたことです。同じソフトウェアを使っていても，インスタンスごとに雰囲気や価値観が異なり，その違い自体が Fediverse の多様性を作ってきました。

1. ローカル文化の重視

中央集権型 SNS では，全員がほぼ同じルールとランキングに従います。一方 Mastodon では，インスタンスごとにルールやモデレーション方針を設計できるため，小規模でも目的に合った場を作りやすくなります。技術系，創作系，地域コミュニティなど，話題ごとに文化圏が生まれたのはこの仕組みの効果です。

2. タイムライン体験と会話の速度

Mastodon の体験は，アルゴリズム推薦の強い可視化よりも，時系列で流れる会話の連続性に重心があります。結果として，短期的な拡散効率より，継続的なやり取りや顔なじみ同士の関係が育ちやすい傾向があります。これは「バズ中心の文化」から距離を取りたい利用者に支持された要因の一つでした。

3. ブームと定着の反復

この10年で何度か大きな流入が起きましたが，そのたびに全部が定着したわけではありません。ただ，波が引いた後にも一定数の利用者と運営者が残り，文化が薄く積み上がっていきました。急成長よりも，継続的な共同運営を重視する土壌が形になってきたと言えます。

4. 2026年時点で見える文化的意義

2026年の時点での文化的意義は，「巨大サービスの代替」を超えて，「小さな共同体が自分たちの会話空間を持てる」ことを実証した点にあります。Mastodon の10年は，SNSを一枚岩で捉えるのではなく，複数の文化圏の集合として扱う視点を広げた10年でもありました。

運用面: Mastodonの10年

運用面で重要なのは，Mastodon が「使うサービス」でもある一方で，「運営するサービス」でもあることです。大規模プラットフォームでは運営が利用者から見えにくいのに対し，Mastodon では管理者，モデレーター，利用者の距離が近く，運用そのものがコミュニティの性格を決めます。

1. インスタンス運営の実務

インスタンス運営では，サーバー保守だけでなく，利用規約の整備，問い合わせ対応，荒らし対策，バックアップ運用など，多面的な作業が発生します。特に利用者が増える局面では，技術対応より先に運営体制がボトルネックになることも多く，持続可能な分担設計が不可欠でした。

2. モデレーションと連合ポリシー

Fediverse では，どのサーバーと連合するかを各インスタンスが判断できます。この自由度は大きな強みですが，同時に運営の責任も増やします。迷惑行為の封じ込め，外部インスタンスとの関係調整，方針説明の透明性など，モデレーション実務の成熟が長期運用の鍵になりました。

3. 財政と継続性の課題

多くのインスタンスは有志運営であり，コストと労力の持続可能性が常に課題です。寄付，スポンサー，コミュニティ課金など，運営モデルは多様ですが，どれも万能ではありません。10年の蓄積で見えてきたのは，「拡大速度」より「無理なく続けられる規模」を選ぶ判断の重要性です。

4. 2026年時点で見える運用的意義

2026年時点での運用的意義は，SNSの運営をブラックボックスにせず，コミュニティが意思決定に参加できる形を実例として示したことです。Mastodon の10年は，技術と文化を支える土台として，運用設計そのものがプロダクトの一部であることを可視化した10年だったと言えます。

近年台頭してきた Bluesky との比較

近年は Bluesky も急速に存在感を高めており，分散型 SNS の文脈で Mastodon と並べて語られることが増えました。両者は「中央集権型 SNS に依存しない選択肢」という点では近い一方で，重視する設計とコミュニティの作り方には違いがあります。

プロトコルと構造: Mastodon は ActivityPub を前提に，複数サーバーの連合運用を早期から実践してきました。Bluesky は AT Protocol を軸に，IDやデータ可搬性をより前面に出した設計を進めています。
体験と文化: Mastodon はインスタンスごとのローカル文化が濃く，コミュニティ単位で空気を作る傾向があります。Bluesky は比較的単一空間に近い体験から入りやすく，公開空間での拡散と会話の見通しやすさが強みです。
運用モデル: Mastodon は各インスタンス管理者の裁量が大きく，運営方針の多様性がそのままネットワークの多様性になります。Bluesky はプラットフォーム提供側の整備と利用者体験の統一感を活かしつつ，段階的に分散化を広げるアプローチを取っています。

要するに，Mastodon は「先に分散運用を社会実装した10年」，Bluesky は「分散化を再設計しながらスケールを狙う現在進行形」と整理できます。どちらが優れているかではなく，設計思想の違いを理解して使い分けることが重要です。

まとめ

Mastodon の10年を振り返ると，重要だったのは単なる機能競争ではなく，「つながり方の設計」を社会に実装したことでした。技術面では相互運用性を現実のものにし，文化面では小さな共同体の多様性を支え，運用面ではコミュニティが意思決定に関与するモデルを積み上げてきました。

その意味で，2026年は「分散型SNSは成立するのか」という問いに対して，Mastodon がすでに10年分の実例を示した年だと言えます。これから先は，Mastodon と Bluesky を含む複数の流れがどう交差し，利用者にどんな選択肢を広げていくかを見ていく段階に入った，と私は考えています。

Mastodon どうでしょう

アウトラインは AI と一緒に考えたが（AI だけに考えさせると論文みたいな構成になるw），中身は 100% AI による記述で，私は1文字も触っていない。

どうだろうか¹。私なんか文章を読んで「ほほう」と感心してしまったよ（笑）

しかし10年か。 Mastodon の登場は一昔前の話になってしまったねぇ。日本で Mastodon が話題になった頃に「GW 過ぎたらみんな忘れてるに100カノッサ」と言ってた頃が懐かしいよ。当時は Twitter がここまでメタクソ化するとは思わなかったし「どうせ山ほどある Twitter クローンのひとつでしょ」という認識しかなかったからなぁ。

IT 業界は2〜3年でシーンが変わるからな。 10年も経てば，そりゃあ変わるか。

ブックマーク

Kagi Assistant にも同じように聞いてみたが，こちらは Mastodon が「強力なアンチハラスメントツール」として機能していることを強調していた。ユーザ側の高度なフィルタリング機能や投稿時に公開範囲を制御できることを評価しているみたい。 ↩︎

Streamplace と Livepeer

2026-04-12T22:23:13+09:00

前回の続き。

というか，前回の記事が思ったより長くなったのと，話の中心が Streamplace のほうに横滑りしそうになったので記事を分けたのだった。

Livepeer について

Streamplace の話をする前にバックエンド（基盤技術）のひとつである Livepeer について説明しておこう。

Livepeer は Ethereum blockchain 上に構築された分散型のビデオインフラストラクチャ・プラットフォーム，だそうだ。 Blockchain 関連は Ethereum が登場するあたりからどんどん興味が薄れていったのだが，こんなまともそうなものもあるんだ。

Livepeer は以下の疑問が出発点となり，2017年に設立されたらしい。

What if video - the most captivating, expressive medium online - ran on open, permissionless infrastructure instead of expensive, proprietary systems?

via Livepeer Story - Livepeer Docs

Since its launch in 2017, Livepeer’s mission has been to deliver affordable, performant open video & AI infrastructure rooted in decentralised video technology enabled by cryptoeconomic primitives.

via Livepeer Story - Livepeer Docs

Doug and Eric set out to revolutionise video streaming infrastructure from the hardware infrastructure up by:

Turning idle GPUs around the world into a competitive marketplace,

Using crypto-economic incentives to guarantee reliability and quality,

Delivering measurable cost reductions via decentralised economies of scale.

via Livepeer Story - Livepeer Docs

Livepeer の特徴について Kagi Assistant にまとめてもらった。

分散型トランスコーディング
- 動画配信で最もコストがかかる「トランスコーディング（動画を視聴者の環境に合わせた形式に変換する処理）」を、世界中のコンピューター（ノード）に分散して実行させます
- これにより YouTube や AWS などの巨大な中央集権的サーバーを利用するよりも大幅に低コストで配信インフラを構築できます。
ネットワークの参加者
- オーケストレーター（Orchestrators）: 自分のコンピューターのリソース（CPU/GPU）を提供して動画処理を行い報酬を得る参加者です。
- デリゲーター（Delegators）: 自分が持つ LPT トークンを信頼できるオーケストレーターに預け（ステーキング）、ネットワークのセキュリティに貢献しながら報酬の一部を受け取る参加者です。
LPT (Livepeer Token)
- Livepeer の独自トークン「LPT」は、ネットワークの調整、ガバナンス、およびセキュリティ維持のために使用されます。
AI との統合
- 最近ではビデオ配信だけでなく、分散型 GPU リソースを活用した AI 推論（リアルタイムのビデオ生成や加工など） のインフラとしても機能を拡張しています。
開発者向けツール
- 開発者が自分のアプリに簡単にビデオ機能を組み込めるよう、SDK や「Livepeer Studio」といったホスト型プラットフォームも提供されています。

だいたい合ってる？ Streamplace や Livepeer 周辺で Web3 が云々とか聞こえてきたのはそういう訳だったんだねぇ。

Streamplace について

ここで Streamplace が登場する。 Streamplace は2024年後半にパイロット版が公開され，2025年の ATmosphereConf のライブ配信に採用されて注目を集めた。 2026年の ATmosphereConf でも Streamplace によるライブ配信が行われていた（まぁ，私はそれで知ったのだが）。

Streamplace は，この Livepeer が提供する強力な分散型ビデオ処理能力をバックエンド（基盤）として利用することで特定の企業に依存しない自由な配信プラットフォームを実現する，ということのようだ。前回の記事でも挙げたが「特定の企業」のひとつである YouTube と Streamplace との比較を再び挙げておく（AI による要約なので鵜呑みにしないように）。

比較項目	Streamplace	YouTube
運営形態	分散型（特定の企業に依存しない）	中央集権型（Google が運営）
基盤技術	AT Protocol / Livepeer ネットワーク	Google 独自のクローズドなインフラ
ソースコード	オープンソース（誰でも利用・改善可能）	非公開（プロプライエタリ）
データの所有権	ユーザー自身（自己主権型アイデンティティ）	運営企業（Google）
主な目的	分散型 SNS 向けのビデオインフラ提供	広告収益を主とした動画共有サービス
検閲・制限	プロトコルレベルでの検閲は困難	運営企業のポリシーにより削除・停止あり
主な利用者層	Web3 開発者，分散型 SNS ユーザー	一般消費者，クリエイター，広告主

もちろん，基盤技術として AT Protocol (Authenticated Transfer Protocol) が使われているのもポイントで，つまり Streamplace は「万能アカウント（The Everything Account）」上のアプリケーション（のひとつ）である，とも言えるわけだ（分散サービスではあるが，匿名サービスではない）。

The Atmosphere, as you can see above, already has countless apps you can use. There are Twitter-like apps such as Bluesky and Blacksky; blogging services like Leaflet, Offprint, and pckt; collection and annotation tools like Semble, Margin, and Seams; and I can go on and on because the ecosystem is expanding by the day. And this is just a small portion of the existing Atmosphere - I couldn’t fit all of the different apps because there are just. so. many.

via The Everything Account

なお VOD (Video on Demand) については，この記事を書いてる時点でまだ開発・テスト中の段階らしい。特にフロントエンド側が未整備のようで，私達一般ユーザが利用できるのはまだ先のようだ。

Livepeer が分散ネットワークであるということは Streamplace はセルフホストしないといけないのか？と一瞬思ったが，一般ユーザ向けには Streamplace 公式の環境（stream.place）が用意されている（使い方は前回記事参照）。組織向けや自前で動画配信プラットフォームを構築したいユーザはセルフホストもできますよ，というスタンスみたい¹。 Streamplace がもっと注目されれば（今 PDS サーバがボコボコ立ち始めているように）一般ユーザが選択可能なインスタンスがもっと増えるのかも知れない。

Streamplace のマネタイズってどうなってるの？

でも，そうなると stream.place のマネタイズってどうなってるのか気になる。ベンチャーキャピタルから資金調達しまくって，挙げ句の果てにメタクソ化か？とか意地悪なことも考えたが，ちょっと違うらしい。

Streamplace は Livepeer Treasury から助成金を受けて開発を行っているらしい（LPT 払い？）。 Livepeer にとって Streamplace はエコシステム上の「公共財（public good）」と見なされていて， Streamplace を育成することが Livepeer エコシステムの拡大に繋がると考えているようだ。

一方 Streamplace 側は Gateway ビジネスモデルによるマネタイズを将来的に考えているらしい。アーキテクチャと支払いフローはこんな感じ。

flowchart LR subgraph ApplicationLayer [Application Layer] direction TD A1["User Apps\nWeb, Mobile,\nTouchDesigner"] end subgraph GatewayLayer [Gateway Layer] direction TD A1 --> J[Job Intake] J --> A1 G1["Capability Discovery"] G2["Pricing & Selection"] G3["Routing / Session Mgmt"] end subgraph OrchestratorLayer [Orchestrator Layer] direction TD J --> GW[GPU Worker] GW --> J AI["AI Models / BYOC\nContainers"] T[Transcoder] end style ApplicationLayer stroke:#3cb540,stroke-width:2px style GatewayLayer stroke:#3cb540,stroke-width:2px style OrchestratorLayer stroke:#3cb540,stroke-width:2px

via Gateway Architecture - Livepeer Docs

flowchart LR A["End users / \nApplications"] G["Gateway"] O["Orchestrator"] W["Transcoder / \nAI Runner"] C["Arbitrum \n(on-chain)"] R["Gateway revenue"] A -- "Pay gateway's rate \n(business layer)" --> G G -- "Pay network rate \n(ETH payment tickets)" --> O O -- "Pay workers" --> W O -- "Redeem tickets" --> C G -- "Keep margin" --> R

via Gateway Business Model - Livepeer Docs

この “End users” は配信者を指すのか？視聴者も含むのか？

上の図は Streamplace を含む Livepeer エコシステムに対する支払いモデルだ。でも，これだと最終的にかかるコストを配信者と視聴者の間でどう配分するかについて不透明な感じがする（見落としがあったらゴメン）。一応

アプリ開発者や配信者が使用したリソース分を支払う従量課金モデル（クラウド資源利用とかでよく見る方式）
高度な機能や安定した帯域を保証する代わりに視聴者が一定額を支払うサブスクリプションモデル（Amazon Prime Video や Netflix みたいな感じ）

とかいった方法で収益化を行うことを考えてるみたいだけど…

YouTube などは基本的にオーディエンスの規模が大きいほど（視聴者への接触機会が多いほど）配信者が稼げる構造になっているが，広告モデルであるが故に配信者も視聴者もコストを払っている感覚が薄い（スパチャのような投げ銭に近いものもあるが）。そういう意味でも YouTube は現代版「テレビ」なんだよなぁ。

動画配信に限らないけど，こういうのって流れ (トレンド) を激変させるほどのキラーコンテンツが現れるかどうかなんだよな。そう考えると Streamplace はまだ「整ってない」感じがするし，整ったとしてもバズるかどうかは運次第といったところもある。

P2P や Web3 などに興味のある人にとっては注目すべき点もあろうが，一般のユーザにとっては「もうしばらく様子見かな」といったところか。やっぱ VOD 機能が正式にサービスインされないと是とも非とも言えないなぁ。

でも，私みたいに今まで「配信」とは無縁だった周回遅れの人が「ちょっとやってみようかな」と思える程度にはなっているかな。

暗号通貨/資産はゼロサムゲームか？

私個人の感覚で申し訳ないが， Livepeer が Ethereum blockchain 上に構築されていると聞いて身構えてしまうのは「暗号通貨/資産って，結局のところゼロサムゲームなんじゃないの？」と思ってしまうからだ。特に NFT (Non-Fungible Token) とか極まってるよね。生成 AI が登場して，そちらに興味が移ったら，あっという間に廃れたけど（笑）

…ていう雑談を Kagi Assistant としてたのだが AI 曰く

投資家同士のマネーゲーム（富の移転）で終わるのではなく、そのプロジェクトが 「世の中をどう便利にするか」「どんな問題を解決するか」 という実需が伴うことで、市場全体が成長するポジティブサムな関係が成立します。

なんだそうな。確かに NFT には「実需」はなかったな。 LPT はどうなんだろう。 Livepeer エコシステムを通じて何かしらの「実需」を創造できるのだろうか。

ブックマーク

なお，セルフホスト用に Docker 環境が用意されているそうな。 WebRTC を利用するので（UDP ポートをいっぱい開ける），その辺の知識がないと難しいかも。 ↩︎

Streamplace で Gogh 作業配信を行う

2026-04-12T15:23:32+09:00

前回の最後の方で「Streamplace を使うことを考えてみようかな」と書いたが，実際に試してみることにした。なお gogh のゲーム画面を動画配信サイトに乗せるのは基本的に OK のようだが，制作会社からガイドラインが示されているので，それに従う必要がある。

gogh二次利用ガイドライン

Streamplace とは

Streamplace は分散型 SNS 向けのビデオレイヤおよびオープンソースのライブビデオ配信プラットフォームで AT Protocol (Authenticated Transfer Protocol) エコシステム下で構築されているのが特徴らしい。

Kagi Assistant に Streamplace と YouTube の比較表を作ってもらった（YouTube 以外の動画配信サービスでも似たようなものだろう）。

比較項目	Streamplace	YouTube
運営形態	分散型（特定の企業に依存しない）	中央集権型（Google が運営）
基盤技術	AT Protocol / Livepeer ネットワーク	Google 独自のクローズドなインフラ
ソースコード	オープンソース（誰でも利用・改善可能）	非公開（プロプライエタリ）
データの所有権	ユーザー自身（自己主権型アイデンティティ）	運営企業（Google）
主な目的	分散型 SNS 向けのビデオインフラ提供	広告収益を主とした動画共有サービス
検閲・制限	プロトコルレベルでの検閲は困難	運営企業のポリシーにより削除・停止あり
主な利用者層	Web3 開発者，分散型 SNS ユーザー	一般消費者，クリエイター，広告主

だいたい合ってるかな。

Streamplace および基盤技術である Livepeer については別記事でもう少し掘り下げて紹介する。まずは（細かいことは考えず）アカウントを取得するところから始めよう。

Streamplace 側の準備

公式サイトのトップページの右上にある Sign Up をクリックする。

via Streamplace Signup

サインアップには Bluesky などのアカウントが必要らしい。アカウントを入力して（上の図では隠れているが）下の方にある Continue をクリックすると OAuth の認証画面になるので確認して承認すればサインアップは完了。

via OAuth Authentication

ドメイン等をきちんと確認すること。

サインアップ（あるいはサインイン）したら Live Dashboard に移動する。

via Live Dashboard

ここで Stream from OBS をクリックする。

via Stream from OBS

プロトコルは RTMPS を選択。この状態で Generate Stream Key をクリックする。

via Stream from OBS

Stream Key が伏せ字で表示されるので右側のボタンをクリックしてクリップボードにコピーする。

OBS 側の設定に必要なので以下の情報はどこかにメモっておこう。

Service： Custom…
Server： rtmps://rtmps.stream.place:1935/live
Stream Key： 上で取得した値
Output Settings
- Output Mode： Advanced
- Keyframe Interval： 1s
- x264 Options： bframes=0

OBS Studio 側の準備と配信の開始

当然ながら gogh はあらかじめ起動しておいてね。

OBS Studio のインストールおよびシーンやソースの設定については割愛する（前回記事の後半でもちょこっと説明している）。各自でいい感じに設定して欲しい。

配信設定については，設定（Settings）画面を表示し配信（Stream）タブで，上の情報を参考に，以下のように設定する。

via OBS Studio ➢ Settings ➢ Stream

さらに出力（Output）タブでも，以下のように設定する。

via OBS Studio ➢ Settings ➢ Output

これであとは Start Streaming ボタンを押せば Streamplace 側に配信が流れる。 Streamplace の Live Dashboard が以下のような状態になっていれば OK（まだプレビュー状態）。

via Live Dashboard

タイトル等を入力して Start Livestream! をクリックすれば配信が開始される。

via Live Dashboard

ちなみに，最近の Bluesky はライブ中フラグを立てることができる。

via Edit live status

ライブ中状態にすると以下のようにアバターアイコンに赤枠が付く。

via Profile

スマホ用アプリ

Streamplace の配信は Web ブラウザで見れるが，スマホ用のアプリも提供されている。

Android だとこんな感じ（横持ちの場合）。

via Streamplace App

見るだけならサインインしなくても OK なようだ。これならスマホ版の gogh は要らんな（笑）配信¹ 仕掛けてポモドーロ・タイマーを起動しておけば出先でも使えるぢゃん。

…後半へ続く。

~~Streamplace 配信は特定のユーザにだけ見えるようにすることもできる。~~ 勘違い。 gogh の限定公開機能と混同していた。 ↩︎

GitHub Copilot はシェル芸達者

2026-04-09T15:57:34+09:00

最初に予防線を張っておくと，この記事は技術系の内容ではありませんし，私は生成 AI の扱いにも慣れてません。その辺を割り引いて読んでいただけるとありがたいです。

生成 AI にどこまで任せていいのか

最近は GitHub Copilot に開発支援だけじゃなくて，このブログのメンテナンスもさせている。なにせ，どこまで任せていいのか匙加減がさっぱり分からないので，できそうなところから徐々に任せていく感じ。気分は新卒社会人の OJT だぜ（笑）

今のところ GitHub Copilot に任せているのは以下の作業：

タイトル & slug の提案と記事ファイルの作成
書いた記事の校正とタグの提案
記事ファイルの commit & push
ブログのビルドと GitHub Pages への commit & push
Hugo の更新

記事そのものは書かせてない。

いや，生成 AI に書かせるとホンマに好き勝手な（私の意図とは程遠い）ことを書くのよ。一度，タイトルだけ決めたまっさらな状態で書かせようとしたら「何の論文を書く気？」って感じのアウトラインを組み始めて，さすがに止めた。ブログ記事に10個も章立てしてどうする（笑）

よくアフィリエイト記事を AI に書かせて云々みたいな話を聞くけど，ホンマに AI に書かせてるの？かなり無茶苦茶するぞ。ある意味，文才があるのかも知れないが。

というわけで「記事を書く」以外の作業をやらせている。

ちなみにモデルは GPT-5.3-Codex を使っている。あまり Premium Request を消費したくないので最初は GPT-5 mini を使ってたのだが，どうもこの手の「作業」には向かない感じ。最終的にはローカル LLM を構築したいのだが，お試しレベルならともかく，まともに動くモデルを個人環境で構築するのは難しいか？

タイトル & slug の提案と記事ファイルの作成

私は最初にタイトルを決めないとブログ記事が書けない。マイクロブログ程度の短文ならともかく，ブログ記事でタイトルも決めずに書き始めると大抵記事が迷走する（タイトルを決めて書いても迷走しがちなのだが，それはそれ）。

手順としては

日本語のタイトルを決める（ここだけ私の作業）
Copilot に英語の翻訳と対応する slug を提案させる（たいてい複数個の候補を提案してくれる）
slug が決まったら記事ファイルを作成させる
ファイル内の front matter を埋めさせる

という感じ。日本語タイトルを英訳させるための対話で，色々と気付きがあって面白い。

たとえば日本語タイトルが曖昧で英訳が頓珍漢な文になることがある。これは生成 AI 以前の機械翻訳サービスを使ってたときもそうだったが，機械と対話することで「文のこの部分が誤解を招いてるのか」と気づいたりできるわけだ。こういったやり取りが意外と面白かったりする。

記事ファイルの作成用にシェルスクリプトを組んでいるのだが，まずその挙動を理解させるところから始めた。したら「このスクリプトをリファクタリングするか？」と訊いてきたのでやらせてみたら，なかなかいい感じに仕上げてくれた。これなら AI にスクリプトを改善させることもできそうだ。

他の既存のスクリプトについても同様にリファクタリングさせ，それらの使い方を copilot-instructions.md および README.md にまとめさせた。

書いた記事の校正とタグの提案

私のブログは意図的に文体を崩して書いているので（設計書やビジネス文書じゃあるまいし），下手に賢い lint では却って使いづらかったりする。ためしに Copilot に「誤字だけ指摘して」と指示してみたら，いい感じに結果を返してくれた。以来，校正は Copilot に任せている。

誤字だけでなく慣用句の漢字間違いの指摘とかは結構ありがたかったり。それでいて崩した文体については一切スルーしてくれる（笑）偉い偉い。

もうひとつ悩んでいるのが記事に付与するタグの選択だ。これを普通に AI に任せるとメチャクチャにしてくれるので，まずは過去の記事を全て浚ってタグの一覧を作らせるところから始めた。

したらすごい勢いでシェルスクリプトを書き始めた。私はそれを「へぇ。なるほど」とか言いながら眺めるだけ。アレだ。ペアプログラミングってやつ（笑）機械相手にペアプロすることになるとは思わなかった。

せっかくいい感じのスクリプトを書いてくれたので，それをファイルにまとめていつでも呼び出せるようにさせた。タグの一覧を出現数の多いものからソートして CSV ファイルに出力させる。ここまでできれば，作成した記事に対してタグ一覧の中から妥当なタグを提案するよう指示すればよい。

タグ一覧を作ったメリットはもうひとつあって typo がいくつか見つかったのと似たような意味のタグの重複が見つかった。見つけたのも Copilot だけど（なにせ10年以上の間にタグが450個以上できてるのだ）。これらも修正方針を提案させた上で修正させた。ファイル作業に関してはちゃんと手順を踏めば間違えることなくやってくれる。

記事ファイルの commit & push

記事ファイルの commit に関しては，念のため，最初に commit message を提案させて，私が確認してから実際の作業を行わせている。ここで GPT-5 mini と GPT-5.3-Codex の違いが大きく出た。

いや，ブログ記事の追加なんだから AI (君) のしたことを書くんじゃなくて，どんな記事を追加したのかを書けよ！

というわけで，GPT-5 mini は向いてないという結論になった。 commit & push するためのコマンドラインの組み立て自体はどちらも大差ないんだけどねぇ。

ブログのビルドと GitHub Pages への commit & push

ブログのビルドと GitHub Pages への commit & push についても以前からスクリプトファイルを作っていたので，それをそのまま Copilot に使わせている。まぁ，自分でやったほうが早いのだが，作業の一連を任せることに意味があると思ってるので，敢えて任せている。この辺も OJT っぽいよな（笑）

指示も最初はできるだけ具体的にしていたが，最近は「デプロイして」だけでも（過去の作業履歴や copilot-instructions.md の記述から）適切に処理してくれるようになった。

Hugo の更新

このブログは静的サイトジェネレータである Hugo を使って構築しているのだが，未だ v1 に到達せずベータ版のままである。古いテンプレート変数や関数のいくつかは deprecated になっているし，稀に破壊的変更が起きることもある。 Hugo のバージョンアップのたびにビルドし直して互換性等の確認をしているのだが，だんだん面倒くさくなってきたので，これも Copilot に任せてみることにした。

今回もゴリゴリとスクリプトを書き始める AI。私も前と同じく様子を眺めていたが，出来がよさそうなのでスクリプトファイルとして書き出してもらった。こんな感じ（長いぞ！）。

#!/usr/bin/env bash
set -euo pipefail

# Install latest Hugo Extended .deb from GitHub Releases using apt.
# Usage: ./hugo_inst.sh

REPO="gohugoio/hugo"
API_URL="https://api.github.com/repos/${REPO}/releases/latest"
WORK_DIR="${TMPDIR:-/tmp}/hugo-inst.$$"

cleanup() {
  rm -rf "$WORK_DIR"
}
trap cleanup EXIT

mkdir -p "$WORK_DIR"
cd "$WORK_DIR"

arch="$(dpkg --print-architecture)"
case "$arch" in
  amd64|arm64)
    ;;
  *)
    echo "Unsupported architecture: $arch" >&2
    echo "This script supports: amd64, arm64" >&2
    exit 1
    ;;
esac

echo "Current Hugo:"
if command -v hugo >/dev/null 2>&1; then
  hugo version || true
else
  echo "hugo command not found"
fi

echo "Fetching latest release metadata from ${REPO} ..."
release_json="$(curl -fsSL "$API_URL")"

version="$(awk -F '"' '/"tag_name"/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$version" ]]; then
  echo "Failed to read latest release version." >&2
  exit 1
fi

asset_url="$(awk -F '"' '/"browser_download_url"/ && /hugo_extended_.*_linux-'"$arch"'\.deb/ {print $4; exit}' <<<"$release_json")"
if [[ -z "$asset_url" ]]; then
  echo "Failed to find hugo_extended .deb for architecture: $arch" >&2
  exit 1
fi

deb_file="${asset_url##*/}"

echo "Latest release: ${version}"
echo "Downloading: ${deb_file}"
curl -fL --retry 3 --retry-delay 2 -o "$deb_file" "$asset_url"

# Optional checksum verification when checksums.txt exists in latest release.
checksums_url="$(awk -F '"' '/"browser_download_url"/ && /checksums\.txt/ {print $4; exit}' <<<"$release_json")"
if [[ -n "$checksums_url" ]]; then
  echo "Downloading checksums.txt for verification ..."
  curl -fL --retry 3 --retry-delay 2 -o checksums.txt "$checksums_url"

  if awk '{print $2}' checksums.txt | grep -qx "$deb_file"; then
    echo "Verifying checksum ..."
    grep "  $deb_file$" checksums.txt | sha256sum -c -
  else
    echo "checksums.txt does not include ${deb_file}; skipping verification."
  fi
else
  echo "checksums.txt not found in latest release; skipping verification."
fi

echo "Installing ${deb_file} with apt ..."
sudo apt install -y "./$deb_file"

echo "Installed Hugo:"
hugo version

echo "Done."

これについては，私は1行も触っていない。

手順としては

インストールするマシンのアーキテクチャを確認して対応する .deb ファイルをダウンロードする
可能ならチェックサムの検証も行う
ダウンロードした .deb ファイルを apt install コマンドでインストールする

という感じ。

これを実行して Hugo を更新した後，ブログのビルドを行い，ビルド前後の差分を調べて問題がないことを確認する。問題がなければビルドしたものを commit & push させる。

「問題がないことを確認する」の部分は私が判断しているので完全な自動化ではないが，今のところ問題は起きていない。

GitHub Copilot はシェル芸達者

という感じで緩々と GitHub Copilot を使っている。

今回の一連で意外とシェル芸達者なのが分かったので，自宅機に CLI 版を入れようかなぁ。でも，結城浩さんほど使い倒す勇気はないんだよなぁ。それよりもローカル LLM 構築に向けて環境を整えるほうが先か？

参考

フルスクラッチから1日でCMSを作る_シェルスクリプト高速開発手法入門改訂2版 (アスキードワンゴ): 上田隆一 (著), 後藤大地 (著), ＵＳＰ研究所 (監修); ドワンゴ 2019-07-05 (Release 2019-07-05); Kindle版; B07TSZZPWN (ASIN); 評価

既存の常識に凝り固まったソフトウェア・エンジニアに「痛恨の一撃」を加える快書もしくは怪書。

reviewed by Spiegel on 2014-09-21 (powered by PA-APIv5)

ネトフリに再契約しなくてもよかったのに

2026-04-07T16:19:17+09:00

ネトフリに再契約しなくてもよかったのに

NASA Artemis II ミッションにおける Orion 有人宇宙船が月の裏側を回り込むのが日本時間で 2026-04-07 朝とのことで，どこで配信するのかなと思ってたらネトフリで配信するとか聞こえてきて。

テレビアニメを（ネットでも）あまり見なくなって，だいぶ前に Netflix のサブスクリプションを解除していた。今年の WBC のときは（競技スポーツに関心が薄いこともあり）完全にスルーしていたが，今回は「またネトフリか」と思いつつ，結局は再契約してしまった。

メンバーシップは解除したけどアカウント自体は残ってたと思ったのだが，どうやらアカウントも消えてたみたいで，あらためて登録からやり直した。前に使ってたメールアドレスは使えたが，以前利用してたときの情報は綺麗になくなってるようだ。まぁ，これはこれでいいか。どうせすぐ解約するし。

あとで NASA の公式 YouTube チャンネルで枠が立ってると Bluesky で教えていただいた。実際にネトフリの配信を見てみたが NASA の公式配信の映像を使ってるだけみたいで，これなら宇推くりあさんの YouTube 配信で十分じゃん orz

ネトフリのサブスクリプションはソッコーで解除しましたよ。契約の関係で5月5日までは有効みたいなので，せっかくだから『超かぐや姫！』でも見るか。 1ヶ月で解約なら映画チケット代より安いし，これで元は取れるやろ（笑）

Artemis Program & Artemis II Mission

今回の Artemis II ミッションは Artemis 計画のひとつ。

Artemis 計画は

20世紀のアポロ計画以来の有人月面着陸を実現し，月面での持続的な有人活動の拠点を築くことを目指す
- 大型ロケット SLS（Space Launch System）の開発
- 有人宇宙船 Orion および着陸機 HLS (Human Landing System) の開発
- 月軌道を周回する有人拠点 Gateway の建設
アルテミス合意（Artemis Accords）に基づく国際協力体制の構築
- アルテミス計画と日本の宇宙探査活動 | JAXA 国際宇宙探査センター
将来の有人火星探査に向けた基盤構築

といった内容で，有人月面着陸に関しては今のところ Artemis V まで計画されている。なお Gateway については現在，凍結しているらしい。

Artemis II は，有人宇宙船 Orion に4人の宇宙飛行士を乗せて月の裏側を回り込んで帰ってくるミッションだ。

via Artemis II Map - NASA

本当は2月に打ち上げ予定だったのが，延びに延びて4月になった。打ち上がってからは（トイレが故障するとかあったそうだが）概ね順調で今日のイベントと相成ったわけである。

Artemis II 配信を YouTube で見る

NASA 公式チャネルでは，以下の配信枠が立てられている。

最初の2つは打ち上げからずうっと配信されているようだ。最後のが今回の月周回イベント用の枠で，昨夜から配信が始まった。コメントが有効になってるので，ずうっと配信しっぱなしということはないだろう？

日本語での解説では，この手のイベントではおなじみ宇推くりあさんの同時視聴ライブ配信がとても参考になった。彼女は Artemis I から引き続き，打ち上げから何度か枠を立てて配信されている。

ありがたや 🙇

私は深夜は起きていられないので（年寄りは寝るのが早い）深夜の配信はほとんど見逃したが，月の裏側を回るイベントは見ることができた。

via NASA’s Artemis II Crew Flies Around the Moon (Official Broadcast) - YouTube

慌ててキャプチャしたので要らないものも写っているが，これは Orion が月の裏側から出てきて通信が回復した直後の船外カメラの映像（月の裏側に入っている間は DSN (Deep Space Network) の通信が切れる）。三日月っぽく見えるのは実は地球である。

その後（Orion から見て）太陽が月に隠される「日食」イベントもあった。

via NASA’s Artemis II Crew Flies Around the Moon (Official Broadcast) - YouTube

これは太陽が月の後ろに隠れた直後と月の後ろから出てくる直前の映像。太陽の周囲にあるコロナがこのように見えるのは，なかなか面白かった。

Orion はこれから地球に戻り，順調に行けば4月11日に再突入する予定である。その時は，もしかしたらこの記事に追記するかも知れない。どことは言わないが，ググったら既に再突入成功の記事とかあるみたいなので（笑）きっと大丈夫だろう（ちょっと，いやだいぶウケた）

【2026-04-08 追記】 Artemis II からの画像を Flickr で見る

Flickr には2008年から NASA の公式アカウントがあるのだが， Artemis II ミッションの画像もここにアップされている。いくつか挙げておこう。

via Earthset | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

via Solar Eclipse Emergence from Orion | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

via Artemis II in Eclipse | NASA Johnson | Flickr (licensed under CC BY-NC-ND 4.0)

最後の「日食」の写真は素晴らしい。

月周囲の暈（halo）がコロナによるものか黄道光によるものか（あるいはその両方によるものか）については議論があるらしい。また月（の影部分）地球照で僅かに照らされているのも分かる。あとは月と背景の星星との位置関係か。学術的にも色々と興味深い写真のようだ。

こういった画像を CC license 下で公開してくれるのはありがたい。どこぞの国の月探査とは大違いやね（笑）

テレビはホンマに要らなくなったな

WBC のときは（最初に言ったように）私は競技スポーツに関心が薄いので Netflix が独占配信をやるとか聞いても「ふーん」程度の感想だったのだが，今回もし Netflix が独占配信するとかやりだしたらちょっと嫌だったかも知れない。だが，まぁ，ありそうな話ではある。昔 NHK と組んで月探査機「かぐや」からの映像を独占させた JAXA とか，いかにもやらかしそうだ。

今回は私の先走りの思い込みで本当によかった。新聞・テレビを見ないので，今回の Artemis II ミッションが日本でどのように報道されているのか知らないし，知らなくても全く問題なく欲しい情報を摂取できる今の状況は幸せなのかも知れない。

参考

天体物理学: Arnab Rai Choudhuri (著), 森正樹 (翻訳); 森北出版 2019-05-28; 単行本; 4627275110 (ASIN), 9784627275119 (EAN), 4627275110 (ISBN); 評価

興味本位で買うにはちょっとビビる値段なので図書館で借りて読んでいたが，やっぱり手元に置いておきたいのでエイヤで買った。まえがきによると，この手のタイプの教科書はあまりないらしい。内容は非常に堅実で分かりやすい。理系の学部生レベルなら問題なく読めるかな。

reviewed by Spiegel on 2019-11-13 (powered by PA-APIv5)

Gogh でてきぱきワーキング【2026-04-06 追記】

2026-04-04T19:08:09+09:00

gogh で作業支援

いわゆる作業支援ゲームあるいはもっと簡単に「作業ゲー」と呼ばれるものは色々と登場しているが gogh (ゴッホ) で自身の作業ルームを公開されている方を Bluesky で見かけたので私も試してみた。

gogh - Focus with Your Avatar
ambr｜note : gogh の制作会社によるブログ
gogh ゴッホ - YouTube : gogh の公式 YouTube チャンネル
@goghjpn.bsky.social on Bluesky : gogh の公式 Bluesky アカウント

Steam 版の gogh は作業ルームをかなり細かくカスタマイズできて，しかもそれを他のユーザと共有できるというので，クリエイター寄りの方々にも人気らしい。

実際、マルチプレイヤー機能が入ってからは本当に爆発的に広まりました。これはgogh配信の大きな特徴なのですが、想像もしていなかったような有名なイラストレーターさんや漫画家さんが次々に作業配信をしてくれました。開発チームには漫画好きやイラストレーターファンが多いので「え…？あの先生も…！？」とチームのSlackに毎日驚きと喜びが溢れていました。

世界30万本を超えたSteam版goghを振り返る - 開発編｜ambrより

モバイル版（Android/iOS）が無料で提供されているにもかかわらず有料の Steam 版がこれだけ売れてるというのは，この辺に理由があるのかも知れない。

Steam 版の gogh の特徴としてはマルチルーム（マルチプレイ）機能の他に

ポモドーロ・タイマー¹
ToDO リスト，日課，日記の記入・管理
複数のアバターを作成可能（最大9アバター）
- DLC でコラボレーションアバターも提供されている
複数の部屋を作成可能（最大15部屋）
- 大人数が入れるLサイズ部屋も作成可能
ルームアイテムへのWebカメラストリーミング
- OBS の仮想カメラにも対応（後述）
お絵描きチャット（通常のチャット機能，音声チャット機能はない）
ローカル音楽プレイリスト

などといったものがある。

via File:Pomodoro Technique.jpg - Wikimedia Commons

試しに（マルチプレイヤーでも使えるように）Lサイズ部屋をひとつ作ってみたのだが，うっかり興が乗ってしまい夜ふかし（というかほとんど徹夜）してしまった。我ながら何やってんだか。

goghより

任意の画像データ（GIF も可）を絵や写真オブジェクトとして室内に設置できる。上の部屋では Flickr で公開している写真を展示してみた。まぁ，飾るような写真じゃないんだけどね。雰囲気だよ雰囲気（笑）

gogh と OBS

gogh は OBS と組み合わせてゲーム内でストリーム配信することもできる²。たとえばパソコンモニタやプロジェクタ・スクリーンといったオブジェクトに OBS の仮想カメラの映像を映し出すことができる。

今まで配信とか無縁の生活だったが，面白そうなので OBS Studio をインストールして試してみた³。のだが，どうしても上手くいかない。最初は OBS 側のシーンやソースの設定の問題かと思って色々弄ってみたが全然ダメで，ふと思いついて Web カメラを gogh のアイテムに直結してみたが，これもダメだった。これって多分 gogh 側にカメラ映像が渡ってないな。

ちなみに私のメインマシンは Ubuntu なのだが，よく考えたら Steam 版 gogh は Windows 版のみの提供で Linux/Ubuntu 環境では Proton でエミュレーションして動かしているのだった。だから OBS との連携ができなくても仕方ないのかな？

しょうがない。ミニ PC (Windows 機) に OBS Studio を入れるか。あまりパワーがないのでまともに動くか不安だけど。

goghより

おっ。あっさり動いた。自分で自分を映してるので合わせ鏡みたいになってるが，まぁよかろう。一応 gogh とは別のゲームを起動して仮想カメラで映してみたが，これも問題なかった。パワーがないのでちょっとカクカクしてたけど（笑）

.｡oO（マルチプレイ用に部屋を公開したらストリーミングが切れてしまった。これってこういうもの？）

OBS を使えば YouTube などのサービスにも配信できる。

【作業雑談】ポモドーロで作業を頑張る月曜日（時々おしゃべり）【古代日本史VTuber きら子】 - YouTubeより

まぁ，でも，これで稼ぐ気はないし，何となく Google のサービスは嫌なので atproto エコシステム下のサービスである Streamplace を使うことを考えてみようかな。

Start streaming with OBS | Streamplace Docs

上手くいったらまた報告する。

ブックマーク

参考

てきぱきワーキン〓ラブ (5) (ビームコミックス): 竹本泉 (著); エンターブレイン 2000-05-01; コミック; 4757700423 (ASIN), 9784757700420 (EAN), 4757700423 (ISBN); 評価

ついに（「さよパラ」にも出てきた）アレックスの謎が解ける？

reviewed by Spiegel on 2017-10-13 (powered by PA-APIv5)

ポモドーロ・タイマーはいわゆるポモドーロ法（Pomodoro Technique）に基づいたタイマーで，メインの作業時間（通常25分）と休憩時間（通常5分）を交互に繰り返すことで集中力を維持するためのもの。gogh では作業時間と休憩時間の長さはユーザが自由に設定できる。「ポモドーロ」とはイタリア語で「トマト」を意味し，この名前はこの方法を考案した Francesco Cirillo がトマト型のキッチンタイマーを使っていたことに由来するらしい。 ↩︎
OBS (Open Broadcaster Software) はオープンソースの高機能ライブ配信・録画用ソフトウェア。 “OBS Studio” という製品名で無料提供され Windows, macOS, Linux 用のバイナリが提供されている。映像・音声のミキシング，ライブ配信，高画質録画，シーンの切り替えといった機能を備えている。 YouTube や Twitch といったサービスへの配信にも対応している。また仮想カメラ機能を使い Zoom や Microsoft Teams といったビデオ会議ツールのカメラ入力としても利用できる。 ↩︎
ちなみに OBS Studio のインストールには通常の方法の他に Steam からインストールする方法もある。 Steam 版は自動更新してくれるメリットがある。ただし Windows バイナリのみの提供で Ubuntu 機ではインストールできないこともないが起動時に「ネイティブ版を使え」と怒られる。それでも無視して起動しようとしたらクラッシュした。 Linux ネイティブの OBS Studio は Flatpak で提供されている。また Ubuntu 環境では PPA に公式リポジトリがあるので，そちらから APT でインストールすることもできる。 ↩︎

MPA for Linux でログイン検証（Linux で個人番号カードを読む 2）

2026-04-01T15:25:15+09:00

前回の続き。

myna のリポジトリによると，サブプロジェクトの MPA for Linux を使って Linux の Web ブラウザでマイナポータルや e-Tax のサイトに個人番号カードを使ってログインできるらしい。素晴らしい！

Rust ツールチェーンのインストール

事前準備として Rust ツールチェーンのインストールを行う。

Rust の基礎勉強をしてたのはもう6年も前で，仕事に結びつくこともなかったので完全に放置していた。しかも，あれから自宅パソコンを買い替えたりして開発環境もなくなったので，インストールからやり直すことに。

インストールページに従って，以下のスクリプトをダウンロード&実行する。

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
info: downloading installer

Welcome to Rust!

This will download and install the official compiler for the Rust
programming language, and its package manager, Cargo.

...

   default host triple: x86_64-unknown-linux-gnu
     default toolchain: stable (default)
               profile: default
  modify PATH variable: yes

1) Proceed with standard installation (default - just press enter)
2) Customize installation
3) Cancel installation
>

今回はこのまま Enter キーを押して続行。

info: profile set to default
info: default host triple is x86_64-unknown-linux-gnu
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-03-26 for version 1.94.1 (e408947bf 2026-03-25)

...

Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, you need to source
the corresponding env file under $HOME/.cargo.

This is usually done by running one of the following (note the leading DOT):
. "$HOME/.cargo/env"            # For sh/bash/zsh/ash/dash/pdksh
source "$HOME/.cargo/env.fish"  # For fish
source "~/.cargo/env.nu"  # For nushell
source "$HOME/.cargo/env.tcsh"  # For tcsh
. "$HOME/.cargo/env.ps1"        # For pwsh
source "$HOME/.cargo/env.xsh"   # For xonsh

これで ~/.rustup/ および ~/.cargo/ ディレクトリ以下にツールチェーンがインストールされた。 PATH 設定が ~/.cargo/env ファイルに記述されていて ~/.profile と ~/.bashrc が ~/.cargo/env を読み込むよう書き換えられている。必要に応じて内容を調整する。

とりあえず，今すぐ PATH を通したいなら

$ . ~/.cargo/env

とすればよい¹。

起動確認しておこう。

$ rustc --version
rustc 1.94.1 (e408947bf 2026-03-25)

うんうん。問題なさそうやね。 Rust の勉強もやり直すかなぁ。

MPA for Linux のインストール

いよいよ MPA for Linux をインストールする。

適当なディレクトリに github.com/jpki/myna リポジトリを clone する。

$ git clone https://github.com/jpki/myna.git

リポジトリ内の mpa ディレクトリに移動して cargo install を実行する。

$ cd myna/mpa
$ cargo install --path .
  Installing mpa v23.0.0 (/home/username/path/to/myna/mpa)
    Updating crates.io index
     Locking 107 packages to latest Rust 1.94.1 compatible versions
      Adding der v0.7.10 (available: v0.8.0)
      Adding generic-array v0.14.7 (available: v0.14.9)
      Adding sha1 v0.10.6 (available: v0.11.0)
      Adding sha2 v0.10.9 (available: v0.11.0)

         ...

   Compiling myna v0.6.4 (/home/username/path/to/myna)
   Compiling mpa v23.0.0 (/home/username/path/to/myna/mpa)
    Finished `release` profile [optimized] target(s) in 16.86s
  Installing /home/username/.cargo/bin/mpa
   Installed package `mpa v23.0.0 (/home/username/path/to/myna/mpa)` (executable `mpa`)

これで ~/.cargo/bin/ ディレクトリにホストアプリケーション mpa がインストールされた。

次に同ディレクトリにある install.sh を実行してホストアプリケーションをブラウザに登録する。ブラウザのプロファイルが既定の場所にあるのであれば，引数なしで起動すればよい。

$ ./install.sh
=== Installing Native Messaging Host manifests ===
Host path: /home/username/.cargo/bin/mpa

Installed: /home/username/.config/google-chrome/NativeMessagingHosts/com.github.jpki.mpa.json
Installed: /home/username/.config/chromium/NativeMessagingHosts/com.github.jpki.mpa.json
Installed: /home/username/.mozilla/native-messaging-hosts/com.github.jpki.mpa.json

ブラウザのプロファイルが既定のの場所にない場合は

./install.sh --user-data-dir /path/to/datadir

のように指定できるらしい。今回は既定のままでOK。

次にブラウザのほうほうにも拡張機能をインストールする必要があるのだが，正規ルートからはインストールできないようなので Developer mode で強制的に行う。手順は以下の通り。

Chrome

chrome://extensions/を開く

右上のディベロッパーモードをON

パッケージ化されていない拡張機能を読み込むで./mpa/extensionを読み込む

拡張機能のメニューからMPA for Linuxを開く

動作確認ボタンを押してエラーが出なければOK

Firefox(一時的)

about:debuggingのこのFirefoxを開く

一時的なアドオンを読み込むで./mpa/extension/manifest.jsonを読み込む

拡張機能のメニューからMPA for Linuxを開く

動作確認ボタンを押してエラーが出なければOK

ブラウザ拡張のインストールより

メインで使ってる Firefox に入れるのは怖いので，サブとして使ってる ungoogled-chromium で試した。やり方はたぶん Chrome と同じでいいよね。こんな感じ？

ちなみに Developer mode を OFF にするとこの拡張機能も無効になる。これがあるからオススメしにくいんだよなぁ。

これで MPA for Linux の導入は完了。上手くログインできるかなぁ。

マイナポータルサイトにログインする

マイナポータルより

左サイドにあるログインボタンを押してログイン画面に移動する。

ログイン | マイナポータルより

ここで暗証番号の入力を求められる。

暗証番号入力より

利用者証明用パスワード（4文字の数字）を入力して OK ボタンをクリックする。ボタンをクリックせず Enter キーを押すとなにも起こらず処理が止まってしまうので注意（困るなぁ）。

ホーム | マイナポータルより

よし。上手くいった！

e-Tax サイトにログインする

e-Tax サイトのログインは個人用と法人用がある。私は個人用からログインする。

個人ログイン | e-Taxより

下の方にスクロールすると

個人ログイン | e-Taxより

「ICカードリーダーで読み取り」ボタンがあるので，これをクリックする。あとは前節と同じように暗証番号の入力を求められるので，利用者証明用パスワード（4文字の数字）を入力して OK ボタンをクリックする。

TOP | e-Taxより

こちらも問題なく入れた！

これで Linux 機で確定申告できる！

マイナポータルおよび e-Tax の両サイトへのログインを確認できたので，ブラウザ拡張機能の Developer mode を OFF に戻しておく。

これで来年は自宅 Linux 機で確定申告できるな。もうスマホで確定申告するのは嫌なのよ。スマホは入力端末としては向かないっスよ。

ミニ PC の Windows 機はますますゲーム専用機になっていくな（笑）まぁ，それはそれで重宝しているからいいか。

参考

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

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

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

コマンドの . は source と同じ意味で，指定したファイルを現在の shell で実行する。 ↩︎

Linux で個人番号カードを読む

2026-03-31T20:23:14+09:00

自宅の Ubuntu 機に IC カードリーダーを接続し，個人番号カードの内容を読み取る。

事前準備

今回は IO DATA の非接触式 IC カードリーダー USB-NFC4 を使用する。

USB-NFC4 | ICカードリーダーライター | アイ・オー・データ機器 I-O DATA

昨年の夏頃に Amazon で安売りしてたのを買ったのだが，そのまま放置していた。いざ確定申告で使おうとしたら Windows 機で認識できなくて使えなかった。そのまま捨て置くのはもったいないので Linux で使えるか試そうという話である。

Ubuntu 側で必要なのは以下のソフトウェア

OpenSC/OpenSC: Open source smart card tools and middleware. PKCS#11/MiniDriver
デバイスドライバ : CIR315A 用のドライバで代用
jpki/myna: マイナンバーカード・ユーティリティ・JPKI署名ツール · GitHub

では早速はじめよう。

インストール

Wiki によると Linux 版の OpenSC は自前でビルドしろとあるが， Ubuntu であればバイナリが提供されているっぽいのでそちらを使う。

$ sudo aptitude install opensc opensc-pkcs11 pcscd pcsc-tools libpcsclite1 libusb-1.0-0 libpcsclite-dev libusb-1.0-0-dev
libpcsclite1 は、要求されたバージョン (2.3.3-1) で既にインストールされています
libusb-1.0-0 は、要求されたバージョン (2:1.0.29-2) で既にインストールされています
libpcsclite1 は、要求されたバージョン (2.3.3-1) で既にインストールされています
libusb-1.0-0 は、要求されたバージョン (2:1.0.29-2) で既にインストールされています
以下の新規パッケージがインストールされます:
  libccid{a} libeac3{a} libintl-perl{a} libintl-xs-perl{a} libpcsc-perl{a} libpcsclite-dev libusb-1.0-0-dev libusb-1.0-doc{a} opensc 
  opensc-pkcs11 pcsc-tools pcscd 
更新: 0 個、新規インストール: 12 個、削除: 0 個、保留: 0 個。
アーカイブの 2,824 kB を取得する必要があります。展開後に 12.8 MB のディスク領域が新たに消費されます。
先に進みますか? [Y/n/?]

起動確認だけしておく。

$ opensc-tool -i
OpenSC 0.26.1 [gcc  15.2.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)

問題はなさそうかな¹。

CIR315A の製品ページから「USB Linux インストーラ」をダウンロードする。

CIR315A関連ファイルのダウンロードより

ダウンロードしたファイルの内容は以下の通り：

Circle_USB_Linux_Installer_v2.2.2_(driver_v.2.2.2).zip (2025-07-25 時点)
- Generic-Debian
  - libabcccid_2.2.2-1_amd64.deb

この libabcccid_2.2.2-1_amd64.deb をインストールする。

$ sudo dpkg -i libabcccid_2.2.2-1_amd64.deb

myna は GitHub のリリースページからバイナリをダウンロードしてインストールする。

myna-v0.6.4-x86_64-unknown-linux-gnu.zip (2026-03-12 時点)
- myna

ファイル myna を PATH の通ってるディレクトリに置く。こちらも起動確認だけしておこう。

$ myna help
Usage: myna [OPTIONS] <COMMAND>

Commands:
  text     券面入力補助AP
  visual   券面確認AP
  test     Test card reader
  jpki     公的個人認証
  pin      Pin operation
  unknown  謎のAP
  help     Print this message or the help of the given subcommand(s)

Options:
  -v...          
  -d, --debug    
  -h, --help     Print help
  -V, --version  Print version

個人番号カードを読み込む

まずは USB-NFC4 を繋いだだけの状態で IC カードリーダーが認識されているか確認する。

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    No              Circle CIR315 CL [CIR315 CL] (137K231232M2) 00 00

USB-NFC4 から「ピッ！」って音がする。やっと認識してくれたよ。

ではカードリーダーに個人番号カードを乗っけてみる。

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Circle CIR315 CL [CIR315 CL] (137K231232M2) 00 00

Card 項目が Yes になっている。よしよし。

次に PIN 情報を取得する。

$ pkcs15-tool --list-pins
Using reader with a card: Circle CIR315 CL [CIR315 CL] (137K231232M2) 00 00
PIN [User Authentication PIN]
	Object Flags   : [0x12], modifiable
	ID             : 01
	Flags          : [0x12], local, initialized
	Length         : min_len:4, max_len:4, stored_len:0
	Pad char       : 0x00
	Reference      : 1 (0x01)
	Type           : ascii-numeric
	Tries left     : 3

PIN [Digital Signature PIN]
	Object Flags   : [0x12], modifiable
	ID             : 02
	Flags          : [0x12], local, initialized
	Length         : min_len:6, max_len:16, stored_len:0
	Pad char       : 0x00
	Reference      : 2 (0x02)
	Type           : ascii-numeric
	Tries left     : 5

鍵は取り出せるかな。

$ pkcs15-tool --read-certificate 1
Using reader with a card: Circle CIR315 CL [CIR315 CL] (137K231232M2) 00 00
-----BEGIN CERTIFICATE-----

...

-----END CERTIFICATE-----

ありゃ。暗証番号がなくてもいいのか。でもちゃんと取り出せてるみたい。

もういっちょ。

$ pkcs15-tool --read-certificate 2 --verify-pin --auth-id 02
Using reader with a card: Circle CIR315 CL [CIR315 CL] (137K231232M2) 00 00
Please enter PIN [Digital Signature PIN]: 
-----BEGIN CERTIFICATE-----

...

-----END CERTIFICATE-----

こちらもちゃんと取り出せてるようだな。

“Please enter PIN” には署名用パスワードを入力する²。正しく入力すると以下のポップアップが出る。

myna のほうも動かしてみよう。

$ myna pin status
券面入力補助AP 暗証番号: 3
券面入力補助AP 暗証番号A: 10
券面入力補助AP 暗証番号B: 10
券面確認AP 暗証番号A: 10
券面確認AP 暗証番号B: 10
JPKIユーザー認証用 暗証番号: 3
JPKIデジタル署名用 パスワード: 5

これでパスワード入力を失敗できる（ロックアウトされまでの）残り回数が分かる。

券面情報を取得してみよう。

$ myna text attrs
暗証番号(4桁): ****
氏名    : **********
住所    : **********
生年月日: ********
性別    : *

実際にはちゃんと内容が表示されるが，ここでは伏せ字にしている。あしからず。暗証番号には券面事項入力補助用パスワードを入力する。

myna を使えば PDF ドキュメントなどに電子署名を付与できる。こんな感じらしい。

$ myna jpki pdf sign input.pdf -o signed.pdf

署名の検証は以下の通り。

$ myna jpki pdf verify signed.pdf

「JPKI署名用証明書は4属性(氏名・住所・生年月日・性別)を含みますので注意してください」とあるので，実際に運用する場合はホンマにご注意を。

さらに「MPA for Linux」を使えば Linux のブラウザでマイナポータルや e-Tax などのサイトに個人番号カードを使ってログインできるようだ。ただし（今のところ） Rust のビルド環境が必要なのとブラウザ拡張を無理やり入れるみたいな操作が必要らしいので，今回は割愛する。またどこかで試そうか。

今回はここまで。次回へ続く。

ブックマーク

Linux & IO DATA USB-NFC4 & マイナンバーカード

参考

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

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

OpenSC v0.27 より前のバージョンには脆弱性が報告されている。 2026-03-31 時点では Ubuntu の APT リポジトリには反映されてない模様。頑張って反映させてね。 ↩︎
個人番号カードの暗証番号・パスワードには署名用パスワード（最大16文字の英数字），利用者証明用パスワード（4文字の数字），券面事項入力補助用パスワード（4文字の数字），個人番号カード用（住民基本台帳用）パスワード（4文字の数字）の4つがある。 ↩︎

Aptitude コマンドの導入

2026-03-31T11:56:48+09:00

aptitude というコマンドがある¹。依存関係解決能力に優れていて apt コマンドの代わりとして使えるようだ（同じパッケージデータベースを使う）。

【Linux】aptitudeコマンドで依存関係を賢く解決してパッケージを管理する - 森の株

さっそく導入してみよう。

$ sudo apt install aptitude

$ aptitude help
aptitude 0.8.13
使用方法: aptitude [-S ファイル名] [-u|-i]
          aptitude [オプション] <アクション> ...

アクション (指定がない場合、aptitude はインタラクティブモードで起動します):

 install         パッケージをインストール/更新します。
 remove          パッケージを削除します。
 purge           パッケージと設定ファイルを削除します。
 hold            パッケージを固定します。
 unhold          パッケージの固定を解除します。
 markauto        自動的にインストールされたという印をパッケージにつけます。
 unmarkauto      手動でインストールされたという印をパッケージにつけます。
 forbid-version  aptitude に特定のパッケージバージョンの更新を禁止させます。
 update          新規/更新可能なパッケージの一覧をダウンロードします。
 safe-upgrade    安全な更新を行います。
 full-upgrade    パッケージのインストールや削除を伴う可能性のある更新を行います。
 build-dep       パッケージの構築依存関係をインストールします。
 forget-new      どのパッケージが "新規" かの情報を消去します。
 search          名前や正規表現でパッケージを検索します。
 show            Display detailed info about a package.
 showsrc         Display detailed info about a source package (apt wrapper).
 versions        指定したパッケージのバージョンを表示します。
 clean           ダウンロード済みのパッケージファイルを消去します。
 autoclean       古いダウンロード済みのパッケージファイルを消去します。
 changelog       パッケージの変更履歴を表示します。
 download        Download the .deb file for a package (apt wrapper).
 source          Download source package (apt wrapper).
 reinstall       現在インストールされているパッケージを再インストールします。
 why             特定のパッケージをインストールする必要がある理由を表示します。
 why-not         特定のパッケージをインストールすることができない理由を表示します。

 add-user-tag    パッケージ/パターンにユーザタグを追加します。
 remove-user-tag パッケージ/パターンからユーザタグを削除します。

オプション:
 -h              このヘルプの文章です。
 --no-gui        利用可能でも GTK GUI を使いません。
 -s              アクションのシミュレートのみ行い、実際には実行しません。
 -d              パッケージのダウンロードのみ行い、インストールや削除は
                 行いません。
 -P              アクションの確認のため、常にプロンプトを出します。
 -y              すべての yes/no の質問に対して 'yes' と答えたと見なします。
 -F フォーマット 検索結果の表示フォーマットを指定します。マニュアルを参照し
                 てください。
 -O 順序         検索結果の並び替えを指定します。マニュアルを参照してくださ
                 い。
 -w 幅           検索結果の表示フォーマットの幅を指定します。
 -f              依存関係が壊れたパッケージを積極的に修復しようとします。
 -V              パッケージのどのバージョンがインストールされるか表示します。
 -D              自動的に変更されたパッケージの依存関係を表示します。
 -Z              各パッケージのインストールサイズの変更を表示します。
 -v              付加的な情報を表示します (何倍もの情報が提供されます)。
 -t [リリース]   パッケージをインストールするリリースを指定します。
 -q              コマンドラインモードで、進行状況の逐次表示を抑制します。
 -o キー=値      'キー' の名前の設定オプションを直接設定します。
 --with(out)-recommends     推奨パッケージを強い依存関係として扱うかどうかを
                            指定します。
 -S ファイル名   ファイルから aptitude の拡張状態情報を読み込みます。
 -u              起動時に新しいパッケージ一覧をダウンロードします。
                  (端末インタフェースのみ)
 -i              起動時にインストールを行います。
                  (端末インタフェースのみ)

すべてのオプションの完全なリストと説明については、マニュアルページを参照してください。

この aptitude にはスーパー牛さんパワーなどはありません。

ゴメン。最後の1文は分からない。試しに aptitude パッケージ自身を search してみよう。

$ aptitude search aptitude
i   aptitude                      - 端末ベースのパッケージマネージャ
v   aptitude:i386                 -
i A aptitude-common               - architecture independent files for the aptitude package manager
v   aptitude-doc                  -
p   aptitude-doc-cs               - 端末ベースのパッケージマネージャ aptitude 用チェコ語マニュアル
p   aptitude-doc-en               - English manual for aptitude, a terminal-based package manager
p   aptitude-doc-es               - 端末ベースのパッケージマネージャ aptitude 用スペイン語マニュアル
p   aptitude-doc-fi               - 端末ベースのパッケージマネージャ aptitude 用フィンランド語マニュアル
p   aptitude-doc-fr               - 端末ベースのパッケージマネージャ aptitude 用フランス語マニュアル
p   aptitude-doc-it               - Italian manual for aptitude, a terminal-based package manager
p   aptitude-doc-ja               - 端末ベースのパッケージマネージャ aptitude 用日本語マニュアル
p   aptitude-doc-nl               - Dutch manual for aptitude, a terminal-based package manager
p   aptitude-doc-ru               - Russian manual for aptitude, a terminal-based package manager
p   aptitude-robot                - Automate package choice management

先頭の3文字が各パッケージの状態を表している。先頭文字の

i はインストールされていることを表す
p はインストールされていないことを表す（purge 状態）
c はインストールされてないが設定が残ってる状態（remove 状態）
v は仮想パッケージ（インストール対象外）
B は依存関係が壊れている状態

2文字目は予約されているアクションで，空白は予約なしの状態を指す。 3文字目に A が付いてるものは依存関係によって自動的にインストールされていることを示す。

update および install アクションの使い方は apt コマンドと同じかな。 remove や purge アクションも同じ。カーネルアップグレード後によく使う apt autoremove は aptitude では ~~autoclean アクションを使えばいいのかな~~ カーネル更新 → リブート → aptitude safe-upgrade で古いバージョンのカーネルイメージを削除してくれる。これは有り難い。いわゆる dry run は -s オプションでできるみたい。

apt upgrade については aptitude safe-upgrade で行う。

$ sudo aptitude safe-upgrade

ディストリビューションのバージョンを上げるときに使う full-upgrade アクションは同じようだ。

aptitude コマンドでは，インストール時などに依存関係の競合が発生すると複数の解決策を提示する場合があるらしい（まだ遭遇してない）。安直に y キーを押さずに，提示された解決策を確認してから選択するのがよさそうだ。

引数なしで aptitude コマンドを起動すると TUI モードで起動する。

おー。これはよさげ。パッケージ毎に（依存関係の解決を含めた）細かい操作をする場合には便利かも。なぜか TUI モードではマインスイーパーで遊べる。

参考

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

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

“aptitude” (apt + tude) は才能や適性を指す言葉で，ラテン語の “aptus” (適切な，適合した) に由来するそうな。同じ由来の類義語に adapt/adaptation などがある。 apt コマンドは “Advanced Package Tool” の略称だけど “apt” からのこじつけかなとか思ったり。（参考: 語根「apt」＝「fit (適当な) 」を覚えろ！） ↩︎

雨粒御伝を巡る（お散歩カメラ 2026-03-29）

2026-03-29T20:46:14+09:00

このブログでは久しぶりのお散歩カメラ。最近は pckt や Leaflet で主に書いているから。

先日 pckt のほうに書いたが「雨粒御伝」なんてのが設置されているらしい。全部で8体。というわけで今回は8体の雨粒御伝を巡るお散歩に出かけることにした。

雨粒御伝 (あまつぶおんでん) を巡る

雨粒の形をした石像「雨粒御伝 (あまつぶおんでん)」は、年中雨の多い松江市の観光を盛り上げるために作られました。

雨粒御伝は、利伝さん・笑伝さん・和伝さん・美伝さん・愛伝さん・友伝さん・澄伝さん・信伝さんの 8 体あり、平成 25 年 11 月から松江城を巡る堀川沿いに設置されています。

「御伝」とは、松江の魅力を伝える “伝道師” として意味を込めた造語で、松江市在住のミュージシャン浜田真理子さんによって名付けられました。

松江観光協会 - 松江めぐり|えにしずく|まち歩きマップ|雨粒御伝より

今回は松江駅からスタートし，松江大橋を渡り，松江城のお堀沿いをぐるっと周って，最後は地ビール館に至るルートで歩くことにした。では，出発しよう。

雨粒澄伝 (あまつぶとおでん)

雨粒澄伝（雨粒御伝） | Flickr

松江大橋北詰，旅館「大橋館」前に設置されている。地元の旅館とか用がないからなぁ。最初「大橋館って何だっけ？」ってググっちまったよ（笑）

雨粒愛伝 (あまつぶめでん)

雨粒愛伝（雨粒御伝） | Flickr

カラコロ工房前に設置されている。最近は徒歩で通りかかることが多いのに全く気が付かなかったよ。注意力散漫だなぁ。

雨粒美伝 (あまつぶびゅーでん)

雨粒美伝（雨粒御伝） | Flickr

島根県市町村振興センター近くに設置されている。雨粒御伝シリーズで最初に見つけたのがこれ。

雨粒和伝 (あまつぶわでん)

雨粒和伝（雨粒御伝） | Flickr

堀川遊覧船の大手前堀川遊覧船乗場近くに設置されている。ここも用がない。でもなんで松ぼっくり？

雨粒利伝 (あまつぶりでん)

雨粒利伝（雨粒御伝） | Flickr

松江歴史館前に設置されている。ここには一度入ったが，やはり全く気づかず。どこを見て歩いているのやら（笑）

雨粒友伝 (あまつぶゆうでん)

雨粒友伝（雨粒御伝） | Flickr

武家屋敷の近く（といってもだいぶ離れてるけど）に設置されている。自転車で通過したことしかない。気が付かなくても無理ないよね（言い訳）

雨粒信伝 (あまつぶしんでん)

雨粒信伝（雨粒御伝） | Flickr

ありゃ Google Maps には載ってないな。八雲記念館前の交差点付近の土産物屋の前に設置されている。自力で探しなはれ（笑）もちろん観光客向けの土産物屋などスルーなので気がつかなかった。

雨粒笑伝 (あまつぶしょうでん)

雨粒笑伝（雨粒御伝） | Flickr

地ビール館奥隣り，遊覧船乗場近くに設置されている。足元に倒れてる鳥が微妙にリアルでこえーよ。触れねーよ。

これでコンプリート。帰りは遊覧船に乗ろうと思ったのだが大盛況らしく，1時間待ちと言われたので，諦めて徒歩で松江城まで戻った。

松江城でお花見

松江市内は今年，3月27日に桜の開花宣言が出された。松江城城山はどんな感じだろうと寄ってみた。

おー。花見客が結構いるな。

お花見（松江城二の丸） | Flickr

二の丸はだいたい五分咲きくらい。本丸は七分から木によっては満開に近い感じ。

桜と天守閣（松江城本丸） | Flickr

こりゃあ，次の週末には満開過ぎちゃうんじゃないのかなぁ。

流石に疲れたので帰りは路線バスに乗った。途中で気がついたが，スマートバンドの心拍数センサーが死んでた。リブートしたら直ったけど，今日一日運動してないことにされてしまった。

ここまで13K歩も歩いたんだよ，どってんばってん orz

参考

GARMIN(ガーミン) vívosmart 5 Black S/M バンド型スマートウォッチ心拍計【日本正規品】: ガーミン(GARMIN) (Release 2022-04-21); エレクトロニクス; B09XGYX7JF (ASIN), 0753759301590 (EAN), 753759301590 (UPC); 評価

サイクルコンピュータと Bluetooth または ANT+ で連携可能なスマートバンド（活動量計）として購入。 Garmin 製なのに自前では GPS 機能がない（スマホの GPS 機能と組み合わせて使う）。活動量計としての機能は十分というかありすぎる（笑）

reviewed by Spiegel on 2023-08-01 (powered by PA-APIv5)

サクラミラージュ: ReGLOSS (メインアーティスト); cover corp. 2036-01-01 (Release 2025-03-10); MP3 ダウンロード; B0DZNX5YTH (ASIN); 評価

リリース日に mora の高解像度版を購入。この歳になってこんな買い方するとは（笑） ReGLOSS は5人の音色（おんしょく）が皆個性的で，これがカッチリ嵌ると本当に格好いい！ヘヴィローテーション中。（2025-04-27 追記： OHTORA さんによる男声セルフカバーもよき）

しっぽのさきっちょ [text.Baldanders.info]

Mastodon 10年史を AI に語らせてみた

Mastodon 略歴（ざっくり）

技術面: Mastodonの10年

1. プロトコル中心への転換

2. 実装の成熟とクライアント多様化

3. 分散設計が生む技術的トレードオフ

4. 2026年時点で見える技術的意義

文化面: Mastodonの10年

1. ローカル文化の重視

2. タイムライン体験と会話の速度

3. ブームと定着の反復

4. 2026年時点で見える文化的意義

運用面: Mastodonの10年

1. インスタンス運営の実務

2. モデレーションと連合ポリシー

3. 財政と継続性の課題

4. 2026年時点で見える運用的意義

近年台頭してきた Bluesky との比較

まとめ

Mastodon どうでしょう

ブックマーク

Streamplace と Livepeer

Livepeer について

Streamplace について

Streamplace のマネタイズってどうなってるの？

暗号通貨/資産はゼロサムゲームか？

ブックマーク

Streamplace で Gogh 作業配信を行う

Streamplace とは

Streamplace 側の準備

OBS Studio 側の準備と配信の開始

スマホ用アプリ

GitHub Copilot はシェル芸達者

生成 AI にどこまで任せていいのか

タイトル & slug の提案と記事ファイルの作成

書いた記事の校正とタグの提案

記事ファイルの commit & push

ブログのビルドと GitHub Pages への commit & push

Hugo の更新

GitHub Copilot はシェル芸達者

参考

ネトフリに再契約しなくてもよかったのに

ネトフリに再契約しなくてもよかったのに

Artemis Program & Artemis II Mission

Artemis II 配信を YouTube で見る

【2026-04-08 追記】 Artemis II からの画像を Flickr で見る

テレビはホンマに要らなくなったな

参考

Gogh で てきぱきワーキング【2026-04-06 追記】

gogh で作業支援

gogh と OBS

ブックマーク

参考

MPA for Linux でログイン検証（Linux で個人番号カードを読む 2）

Rust ツールチェーンのインストール

MPA for Linux のインストール

Chrome

Firefox(一時的)

マイナポータルサイトにログインする

e-Tax サイトにログインする

これで Linux 機で確定申告できる！

参考

Linux で個人番号カードを読む

事前準備

インストール

個人番号カードを読み込む

ブックマーク

参考

Aptitude コマンドの導入

参考

雨粒御伝を巡る（お散歩カメラ 2026-03-29）

雨粒御伝 (あまつぶおんでん) を巡る

雨粒澄伝 (あまつぶとおでん)

雨粒愛伝 (あまつぶめでん)

雨粒美伝 (あまつぶびゅーでん)

雨粒和伝 (あまつぶわでん)

雨粒利伝 (あまつぶりでん)

雨粒友伝 (あまつぶゆうでん)

雨粒信伝 (あまつぶしんでん)

Gogh でてきぱきワーキング【2026-04-06 追記】