List of Site [text.Baldanders.info]

𝕏 に人間と認められなかったので活動を停止します

2026-10-14T07:49:41+00:00

今回は，このブログの最近の運用についてお知らせかたがた覚え書きを記しておく。

ブログのコミット履歴を圧縮しました

このブログは，github-pages-env リポジトリで作成環境を，spiegel-im-spiegel.github.io リポジトリでデプロイを管理している。Hugo と GitHub Pages を利用。基本的にブランチは切らずに master ブランチに直接コミットしている。ひとりで運用してるので，こんなもんだろう。

なにせ10年以上もこの体制で運用しているもんで，コミットログも10年分溜まってしまってるのだ。まぁ，どれだけログが溜まってようと普段は気にしないのだけど，最近は AI (GitHub Copilot) といっしょに記事やデプロイのチェックを行っていて，ときどきサンドボックス上に clone して動作テストをしたりするの。その度に10年分のログがダウンロードされるわけで，遅い遅い。

というわけで「昨年までのコミットだけまとめられる？」と AI に訊いたら「できます」と言うのでサンドボックス上でやらせてみたんだけど，塩漬けのネタ用にブランチを切っていた関係でうまく rebase できなかったので，最終的に今年7月までのコミットをまとめることにした。サンドボックス上で動作テストまでやらせて，最終的な作業手順をシェルスクリプトにまとめてもらった。あとはスクリプトを実行して作業完了。

コミットをまとめた弊害もあって，このページの右上にもある “History in GitHub Page” で該当ページのコミット履歴を見れるようにしているのだが，今年7月までの履歴がなくなってしまった。ゴメンペコン 🙇

まぁ，でも，これでリポジトリがスッキリした。

𝕏 に人間と認められなかったので活動を停止します

Firefox のコンテナ機能がなかなか便利で最近よく使っているのだが，これの影響で 𝕏 のサインイン状態が外れちゃったのね。「しょうがない」とサインインし直したのだが

あなたが人間であることを確認します

とか出るの。「は？」とか思ってコンテナやブラウザを変えて試してみるのだが状況は変わらない。私は Twitter 時代からスマホに公式アプリを入れてなくて，ブラウザからしかアクセスしていない。なので「スマートフォンでXアプリを開いて続行」とか言われても「知らんがな」となる。

あとで調べて知ったのだが，最近の 𝕏 ってユーザが「人間」であることを確認できないとサインインできなくなってるんだって？ググったら，これのせいで iOS なんかが困らされてるという記事が挙がっていた。

試しに手持ちの Android タブレットに一時的にアプリを入れてサインインしてみようとしたのだが（スマホに入れるのはどうしても嫌）

あなたが人間であることを確認してください

とか表示が出て生体認証を要求するの。なんだそれ？もういいや！金払ってるわけじゃないし，サインインしなくても（自 TL が見れないだけで）推し VTuber とかのポストは見れるし，ゲーム情報は Discord でも見れるので実害はない（多分）。

というわけで 𝕏 上での活動を完全停止します。サインインできないから退会すらできないョ。まぁ，そのうち勝手に BAN されるかもしれんけど（笑）ホンマどこまで粘着質なんだか。

「マガジン航」サイト終了のお知らせ

2026-10-07T03:23:27+00:00

yomoyomo さんの記事経由で知ったのだが

えっ「マガジン航」って続いてたのか？と一瞬思ったが，そういえば止めたという話も聞いてなかったな。

しかし2023年秋に最後の記事更新をして以来、今後このメディアをどのように活かして行くべきか、編集発行人としてその方向性を見出すことができずにいました。

この間にインターネットの環境そのものが、ウェブからSNSへ、さらに生成AIへと急速にシフトしており、そのようななかで過去記事のアーカイヴをどのように管理すべきかについても検討を重ねましたが、いまの状況のもとではウェブ上にいつまでも置き続けること自体がよいことだとは思えず、サイトの終了と完全閉鎖を選ぶことにしました。

「マガジン航」終了のお知らせより

なるほど。というわけで，今月いっぱいでドメインごとなくなるらしい。

これまでの記事のアーカイヴは、Internet ArchiveのWayback Machineに委ねることとし、ドメイン名も含めてすべて解消いたします。

[…]

これまでにご寄稿いただいたテキストについては、ローカルファイルでもバックアップをとっておりますので、万一、Internet Archiveからのサルベージができなかった場合は、責任をもってこちらからコピーをお送りします。

「マガジン航」終了のお知らせより

私の本家サイトで塩漬けになっている日記や旧ブログはいまさら弄る気も起きないのだが，ここのブログは直しておいたほうがいいか。とりあえず GitHub Copilot に調査と作業計画の立案をしてもらおう。結果はこんな感じ。

Plan: マガジン航リンクのWayback化

content 内のマガジン航リンクを，指定日時を基準にしたWayback URLへ置き換えます。現状は66件・44ファイルで，記事リンクのほか，サイトトップ・作者・カテゴリへのリンクも含まれています。

content の対象URLを確定します。生成物の public と，過去のDelicious書き出し資料は直接変更しません。
リンク先を https://web.archive.org/web/20261003095755/ と元URLをつないだ形式に置き換えます。リンク文字列や引用文，元URLのパス・クエリ・フラグメントは保ち，Markdownリンクと fig-quote などの属性も対象にします。
Waybackで記事ページとトップ・作者・カテゴリページの保存状態を確認します。保存がない，または適切でないURLは元URLを残して例外として報告します。
content を再検索し，例外以外に元ドメインが残っていないことと，差分がリンク先の変更に限られることを確認します。
build.sh を実行し，ビルド成功と生成HTMLのリンク先を確認します。コミット・公開は行いません。公開する場合はリポジトリの作業手順に従います。

content は Hugo 環境で記事ファイルを置くディレクトリのこと。 fig-quote は引用ブロックを書くために独自に作成したショートコードである。 build.sh は名前の通りビルド用のバッチファイル（シェルスクリプト）。

リンク先の変更自体は（大抵のエディタが備えている）単純な置換処理でできるのだが，対象範囲の制限と変更後の Internet Archive への疎通テストもお願いした。作業計画は問題なさそうなので，そのまま進めてもらう。

Internet Archive 側のリンクでパスの修正が必要だったが（古い日付にリダイレクトされる），それも含めてほぼ手放しで修正作業を完了した。いやぁ，いい時代になったねぇ。手作業なら面倒くさくなって途中で投げ出していたところだ。

私がこのブログで最後に参照した記事は2016年の工藤郁子さんによる以下の記事だ。

メディアは（常に）スパムか？

これは書籍『スパム[spam]:インターネットのダークサイド』の書評記事なのだが，件の本がめっちゃ読みにくいため，工藤郁子さんの書評記事のほうを参考にさせてもらっている。これは今後も変わらないだろう。

「マガジン航」の終了自体は時代的なものもあり「しょうがないか」と思うこともあるが，サイト自体が消えるのは残念な気持ちではある。あとは magazine-k.jp ドメインが spam や phishing に転用されないよう，あるいは Internet Archive が市場や時の為政者に踏み潰されないよう祈るばかりである。

ところで仲俣暁生さんは Bluesky か Mastodon あたりに来てはいただけないのだろうか。いや 𝕏 の TL は見ないので，個人的な願望なのだが…

参考

スパム[spam]:インターネットのダークサイド: フィン・ブラントン (著), 生貝直人 (監修), 成原慧 (監修), 松浦俊輔 (翻訳); 河出書房新社 2015-12-25; 単行本; 430924744X (ASIN), 9784309247441 (EAN), 430924744X (ISBN); 評価

[Comment] とりあえず読みづらい。修飾語が多すぎるよ。ギリシア神話かっての。

reviewed by Spiegel on 2016-12-10 (powered by PA-APIv5)

Web ページの著者情報に Fediverse/Mastodon アカウントを設定する

2026-09-24T12:32:18+00:00

正式には Mastodon v4.3 からの機能らしいのだが Web ページの <meta> 要素に著者情報として Fediverse/Mastodon アカウントを設定できるようになっている。

We’ve decided to create a new kind of OpenGraph tag—the same kind of tags you have on your website to determine which thumbnail image will appear on the preview for the page when shared on Discord, iMessage, or Mastodon. It looks like this: <meta name="fediverse:creator" content="@Gargron@mastodon.social" />.

The handle can be any fediverse account, not just Mastodon. That includes Flipboard, Threads, WordPress (with the ActivityPub plugin installed), PeerTube, Pixelfed, and many others. It will work with and without the leading at-symbol for the handle. If multiple tags are present on the page, the first one will be displayed, but we may add support for showing multiple authors in the future. We intend to propose a specification draft for other ActivityPub platforms in the coming weeks.

via Highlighting journalism on Mastodon

これは以前からある rel="me" を使った Web サイト認証とは異なる。

たとえば Mastodon アカウントが @username@mstdn.example.com なら Web ページの <head> 要素内に以下の <meta> 要素を追記する。

<meta name="fediverse:creator" content="@username@mstdn.example.com">

上の引用文では Open Graph 語彙の新種みたいに書かれているが，厳密な RDFa の語彙があるわけではなく，固定名 fediverse:creator のデータを name 属性と content 属性の組で記述しているに過ぎない。どちらかというと Twitter Card の仕組みに近いかな。

上手く設定できればリンクプレビューに著者情報が表示される。こんな感じ。

リンクプレビュー表示例

全く関係ない Web ページに著者情報を設定されるのは困るので，ユーザのプロフィール設定で有効なドメインを指定する。

認証 - プロフィールより

上の例なら baldanders.info および text.baldanders.info ドメインの Web ページに対してのみ著者情報が有効になる。

ブログ等を運営している方で自力で <meta> 要素を設置可能であれば，検討してみてもいいんじゃないだろうか。

ブログ記事に OGP article メタデータを追加した

2026-08-10T06:20:48+00:00

他所のブログ記事を眺めてたら <head> 要素内のメタデータに

<meta property="article:tag" content="foo">

みたいな記述が見える。 article なんてあったか？と思い，調べてみたら，どうやら OGP の中で定義されている語彙（vocabulary）のようだ。

オブジェクトタイプに article を指定する

article を使うためには prefix に article の語彙を定義し og:type に article を指定する。

<html>
<head prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#">
  ...
  <meta property="og:type" content="article">
  ...
</head>

content 属性は本来リテラルデータを指すので内容に（RDF 上の）意味はないのだが，どうやらただの文字列ではなく， Web 上のリソースを指定しなければいけないようだ。したがって <head> 要素に

<meta property="og:type" content="article">

と書きたければ <head> 要素の prefix 属性を使って

<head prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#"> ... </head>

のように記述する必要がある。まぁ RDFa の設計思想的には間違ってるけどね。もう，私は気にしないことにしている。

OGP では article を含め，以下の語彙が定義されている。

IRI	resource	types
`music`	`https://ogp.me/ns/music#`	`music.song`, `music.album`, `music.playlist`, `music.radio_station`
`video`	`https://ogp.me/ns/video#`	`video.movie`, `video.episode`, `video.tv_show`, `video.other`
`article`	`http://ogp.me/ns/article#`	`article`
`book`	`http://ogp.me/ns/book#`	`book`
`payment`	`http://ogp.me/ns/payment#`	`payment.link`
`profile`	`http://ogp.me/ns/profile#`	`profile`
`website`	`http://ogp.me/ns/website#`	`website`

これ以外の語彙が欲しいなら独自に定義するしかない。

article のメタデータ

article の語彙で使えるメタデータは以下の通り

property	content	description
`article:published_time`	ISO 8601 形式の日時	記事の公開日時
`article:modified_time`	ISO 8601 形式の日時	記事の最終更新日時
`article:expiration_time`	ISO 8601 形式の日時	記事の有効期限
`article:author`	`profile` リソース	記事の著者情報
`article:section`	文字列	記事のセクション（カテゴリ）
`article:tag`	文字列	記事のタグ

article:author に正しくリソース（通常は URI）を指定している Web ページを見たことがない（笑）みんな名前を文字列で書いてるっぽい。私も profile の語彙でわざわざメタデータを書く気にならないので，名前の文字列をセットしている。文法的には content 属性はリテラル値なので，ただの文字列でも文法上はエラーにならないのだが。

article:author や article:tag が複数ある場合は <meta> 要素を複数書けばよい。

<meta property="article:tag" content="foo">
<meta property="article:tag" content="bar">

article:section や article:tag には文字列を指定するとあるが，それって意味なくね？普通はセクションやタグの情報を示すリソースを示すものなんじゃないのか？

OGP は，やっぱり OGP だった

以上を踏まえて，このブログサイトも <head> 要素に OGP の article メタデータを追加している。まぁ article メタデータがどのくらい活用されているのかは分からないけど。しばらくは様子見ということで。

OGP は（RDFa に則ってるのに）相変わらずセマンティック・ウェブからかけ離れたところにいるのがいい感じである（笑）

ブックマーク

リンクカードに対応した

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

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

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

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

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

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

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

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

{{< linkcard "79c9ba36c62cd792801ef499cffe7e614e89670a" >}}

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

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

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

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

ありがたい話である。

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

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

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

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

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

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

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

Release v0.162.0 · gohugoio/hugo

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

Security fixes and hardening in Hugo

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

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

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

Reject symlinked entries in resources.Get (f8b5fa0).

via Release v0.162.0 · gohugoio/hugo

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

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

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

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

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

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

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

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

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

via Content formats

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

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

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

GitHub Copilot はシェル芸達者

2026-04-09T06:57:34+00: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); 評価

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

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

ブログを Fediverse & Atmosphere に参加させる

2026-03-23T11:42:41+00:00

随分前に Bridgy Fed を利用して Bluesky と Mastodon を相互接続させる方法を紹介したが，同じサービスを使ってブログなどの Web サイト（の更新）を Bluesky/Atmosphere および Mastodon/Fediverse と連携させることが出来るようだ。

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Mastodon["Mastodon (Fediverse)"] Bluesky["Bluesky (Atmosphere)"] Website-->BridgyFed BridgyFed-->Mastodon BridgyFed-->Bluesky

Federation with Bridgy Fed

登録自体は簡単で，以下のページでブログの URL を入力するだけ。

via Enter a web site to bridge:

成功すれば以下の画面に遷移する。

via text.baldanders.info profile - Bridgy Fed

RSS フィードを備えているサイトであれば問題なく登録できるはず。サイトの登録は誰でもどのサイトでもできる。勝手に登録されてしまい取り消したいのであれば，オプトアウトの手続きを行う必要がある。

If you’re on the web, email us from an address at your web site’s domain to show that you own it, or you can put the text #nobridge in the profile on your home page and then update your profile on your user page.

via How do I opt out and remove my site or account?

初期状態では Bluesky ハンドルは @yourdomain.com.web.brid.gy に， Mastodon ハンドルは @yourdomain@web.brid.gy になっている。

たとえばサイトのドメインが text.baldanders.info であれば，それぞれ

@text.baldanders.info.web.brid.gy (Bluesky)
@text.baldanders.info@web.brid.gy (Mastodon)

となる。

このうち Bluesky ハンドルはサイトのドメイン名に変更可能である。変更方法は以前書いた記事を参照のこと。 DNS の TXT レコードまたは /.well-known/atproto-did ファイルに DID を設置すれば勝手に更新してくれるみたい。

ちなみに，ここのブログのように GitHub Pages で独自ドメインにしている場合は DNS の TXT レコードが使えないため /.well-known/atproto-did ファイルに DID を書いて設置した。この場合 /_config.yml ファイルに以下の記述を追加する必要がある。

include: [".well-known"]

最終的には以下のハンドル名になった。

@text.baldanders.info

via text.baldanders.info - PDSls

Mastodon ハンドル名の web.brid.gy の部分を独自ドメインに変えることもできるようだが，このブログではメリットが薄い（かえってハンドル名が長くなる）のでやらないかな。

Fediverse の各サービスや Bluesky 等とやり取りするために IndieWeb や Webmention が推奨されているみたいだが，これは後日調査して可能なら対応するか。

今回はここまで。

ブックマーク

Using Web Mentions in a static site (Hugo) | Modern Web Development with Chrome
このブログがFediverseに対応しました
Bridgy-Fedのまとめ
Webmention.io
Long-Form Comes To Bridgy Fed : Bridgy Fed が長文ドキュメント用の Standard.site に対応

AT Protocol & ActivityPub 関連サービスの利用について

2026-03-06T02:36:06+00:00

ATProto/Atmosphere 関連サービス

AT Protocol ベースのサービスをいくつか試しているが，そろそろ覚えきれなくなってきたので，整理のためにここでまとめておく。

サービス	アカウント等	備考
Bluesky	`@baldanders.info`	メインアカウント (PDSls)
`@fanapod.baldanders.info`	非公式 APOD 配信ボット (PDSls)
`@crawler.baldanders.info`	Web クローラーボット (PDSls)
`@photos.baldanders.info`	お散歩カメラ, 実験用 (PDSls)
`@goark.bsky.social`	開発・実験用 (PDSls)
Pckt	お散歩カメラ	ブログ, photosアカウント使用
Streamplace	@baldanders.info	動画配信, メインアカウント使用
なうぷれあっと	@baldanders.info	音楽共有, メインアカウント使用
Leaflet	お散歩カメラ	ブログ（休眠中）, メインアカウント使用
TriLinesAt	—	三行日記（休眠中）, メインアカウント使用
Skyreader	—	休眠中, メインアカウント使用

他にも面白そうなサービスが色々と登場しているので，これからも増えていくかも知れない。自作ツールで bsky.social 以外の PDS で Bluesky の API を使えるようになれば pckt.cafe とかも使いやすくなるのだが… この辺は調査中。

ActivityPub/Fediverse 関連サービス

ついでに，私が利用している ActivityPub/Fediverse 関連サービスも挙げておく。といっても今のところは Mastodon しか使ってないのだが。

サービス	アカウント等	備考
Goark	`@spiegel@goark.fedicity.net`	メインアカウント
`@osanpo@goark.fedicity.net`	Web クローラーボット
`@goark@goark.fedicity.net`	開発・実験用, 今のところボット運用
Fedibird	`@spiegel@fedibird.com`	予備系
mstdn.jp	`@spiegel@mstdn.jp`	休眠中

PixcelFed も気になっているのだが，これも API とかどうなってるんだろうと踏み出せてない。まぁ Mastodon が問題なく使えてるので優先順位は低め。

Bridgy Fed 連携

Bridgy Fed は Bluesky や Mastodon 等の ActivityPub 連合（Fediverse）を連携させるサービスで，現在 Bluesky → Fediverse と Fediverse → Bluesky のブリッヂが提供されている。また Web サイトを Bluesky や Fediverse へ参加させる機能も提供されている。

Bridgy Fed について詳しくはドキュメントを参照のこと。ここでは本サイトで提供している Bridgy Fed 連携の設定を挙げておく。

Bluesky → Fediverse

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky"] Mastodon["Fediverse\n(Mastodon, ...)"] Bluesky e2@--> BridgyFed BridgyFed e1@--> Mastodon e1@{ animate: true } e2@{ animate: true }

Bluesky	Fediverse
`@baldanders.info`	`@baldanders.info@bsky.brid.gy`
`@fanapod.baldanders.info`	`@fanapod.baldanders.info@bsky.brid.gy`

Mastodon → Bluesky

graph LR BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Mastodon"] Mastodon e1@--> BridgyFed BridgyFed e2@--> Bluesky e1@{ animate: true } e2@{ animate: true }

Mastodon	Bluesky
`@spiegel@goark.fedicity.net`	`@mstdn.baldanders.info` (PDSls)

※ @mstdn.baldanders.info アカウントは認証には使えない。

Web → Bluesky & Fediverse

graph LR Website["Web site"] BridgyFed(("Bridgy Fed")) Bluesky["Bluesky\n(and Atmosphere)"] Mastodon["Fediverse\n(Mastodon, ...)"] Website e1@--> BridgyFed BridgyFed e2@-->Mastodon BridgyFed e3@-->Bluesky e1@{ animate: true } e2@{ animate: true } e3@{ animate: true }

Web site	Profile, Fediverse, and Bluesky
`text.baldanders.info`	Bridgy Fed profile
`@text.baldanders.info@web.brid.gy`
`@text.baldanders.info` (PDSls)

Fediverse アカウントの URL はブラウザでは Web サイトにリダイレクトされる（フォローは可能）
Bluesky アカウントは認証には使えない

ブックマーク

Mastodon/Bluesky で共有するためのボタンを追加・更新

2026-02-26T06:32:46+00:00

そろそろ重い腰をあげようかな，ということで。

このブログ各記事ページの右上には共有のためのボタンがある（目立たないようにわざと小さくしているが）。今まで Bluesky の共有ボタンを付けてなかったのだが，今回これを追加した。ボタンに対応する URL の組み立ては以下の公式ドキュメントを参考にした。

Action Intent Links | Bluesky

ついでに Mastodon の共有ボタンも更新した。第三者サービスを経由してポストするのはそろそろやめようかなと思って（信用してないわけじゃないけど）。参考にしたのは以下の記事。

サイトに「Mastodonで共有」ボタンを設置する。 - freefielder.jp

このページで公開している CSS および JavaScript コードをそのまま使わせてもらった。権利の帰属先および利用ライセンスはこちら。

ありがたや 🙇

なお Pocket への共有ボタンは外した。私が使わなくなったので。はてなへの共有ボタンも付けない。そもそもはてなのアカウント持ってないしな。