あまねけ！ - tech

あまねけ！おもしろCSS 7選

2026-06-22T17:21:00+09:00

「個人サイトWebオンリーめぐる市」に合わせて書かれた【個人サイト】カスタマイズに便利なCSS 8選【2026】という記事¹が面白かったので、私もあまねけ！で使われている面白い（たぶん）CSSを7つ選んで紹介しようと思います。

あまねけ！ではサイト内のJavaScriptをできるだけ排除しており、単純な記事の閲覧や基本的な機能は全てCSSのみで実現しています。ダークモードの切替や文字サイズの変更はもちろん、必要ならテキストブラウザで開いたり、プリンターで印刷して紙で読むこともできます。

そのため、この記事には広い環境をサポートするためのスタイルや、JavaScriptの方がイージー（not シンプル）に実現できる動作なども含んでいます。今すぐ便利にカッコよく！というわけでもない細かい調整も紹介するので、興味が出ましたら必要な範囲でお使いください。

① シェア用テキストを選択しやすくする
② スマホでのみ電話番号をリンクとして表示する
③ ページ印刷時にURLも記載する
④ 強調したいテキストに圏点を表示する
⑤ ドット絵をパキッと拡大して表示する
⑥ CSSだけでクリックに応じてスタイルを切り替える
⑦ CSSだけでランダムっぽいパラメータを使う
おわりに

① シェア用テキストを選択しやすくする

Click me!: amanejp2rawomh6vcxugcmz3lsdccfkgwcz755mawisr2yazu3bea2qd.onion

.sample-01-share-text {
  user-select: all;
}

user-select 属性を all にすると、クリックやタップで子の内容が全て選択されるようになります。その後の操作（コピーやシェア）はブラウザあるいはOSの標準機能に任されるので、JavaScriptでコピーを代行するよりユーザーに親切です。

冒頭のサンプルでは、インタラクションがあることを提示するために border-bottom: 1px dotted で下線も表示しています。

② スマホでのみ電話番号をリンクとして表示する

Click me!: +81 80-1665-4365

@media screen and (min-width: 768px) {
  a[href^="tel:"] {
    color: inherit;
    text-decoration: none;
    pointer-events: none;
  }
}

電話番号を押下可能なリンクとして設定する場合、スマホからクリックすると電話アプリが立ち上がって電話番号が入力された状態になると期待できます。しかし、PCやタブレットといった電話アプリを前提としていない環境では、クリックできないテキストとして提示したいものです。

このとき、リンクの装飾として使われる（しばしば青い）文字色と下線のスタイルを外し、さらにクリック不可とすればCSSのみでリンクをふつうのテキストとして表示できます。それぞれ color 属性・ text-decoration 属性・ pointer-events 属性で設定します。

これらをメディアクエリでPC・タブレットを対象に、またセレクタを a[href^="tel:"] とすることで、手動でクラスを指定せずとも「電話番号へのリンク」に対して全て適用できます。このスタイルを適用する場合、リンクテキストは「電話をかける」のようなタップできる前提のものではなく、リンクとして設定する具体的な番号が分かるように表示すべきです。

冒頭のサンプルでは、リンクとして表示しない場合は代わりにコピーしやすいシェア用テキストとして提示しています。

③ ページ印刷時にURLも記載する

@media print {
  a[href^="http"]:after {
    content: " " attr(href) " ";
    text-decoration: none;
    font-size: 80%;
  }
}

Webページを紙に印刷して利用する場合、リンクに関する情報はリンクテキストを残して失われます。PDFのみであればリンクを埋め込んで出力することもできますが、広い環境で利用できるようにURLも表示しておくと安心です。 ::after 疑似要素などを使えばリンク先URLをテキストとして付加できるので、これをメディアクエリと組み合わせて印刷時のみ有効にするとよいでしょう。

例示したスタイルでは http://～ あるいは https://～ から始まる外部リンクのみを対象にしていますが、必要に応じて変更してかまいません。あまねけ！では、 a[href^="/"] な内部リンクには先頭にドメインを付与するスタイルも入っています。

表示が気になった方は、このページを印刷するかPDFとして保存して出力を確認してみてください。

④ 強調したいテキストに圏点を表示する

.sample-04-kenten-text {
  text-emphasis: filled dot;
}

text-emphasis 属性を dot にすると、対象のテキストに圏点（テキストを強調するために文字の上に置く印）を表示できます。点の形（ dot ・ triangle ・ sesame など）や、それに対して図形の内部を塗りつぶすかどうか（ filled or open ）を決められるので、ある程度はサイトの雰囲気に合わせてカスタマイズできます。

表示が気になった方は、主にさよなら、キョーカイの子などの小説作品などで多用されているので眺めてみてください。

⑤ ドット絵をパキッと拡大して表示する

.sample-05-pixel-art {
  image-rendering: pixelated;
}

image-rendering 属性を pixelated にすると、画像のサイズ設定やブラウザのズーム機能による拡大・縮小に対して、ピクセルっぽさを残したアルゴリズムで表示されるようになります。

小さなサイズのドット絵など、ブラウザの幅に対してピクセルを十数倍に拡大して表示する場合、普通はなめらかに拡大するアルゴリズムによってピクセルがにじんでボケボケした見た目になります。これを回避するためには拡大済みの画像を事前に作るのが一般的ですが、このスタイルを当てれば画像が小さいままパキッと拡大できて便利です。マイクロなGIFアニメバナーを目指してでも触れています。

冒頭のサンプルに表示した88ピクセルx31ピクセルの小さなバナーでは、 image-rendering: pixelated を当てていない下のバナーだけがぼやけた表示になることを確認できます。

⑥ CSSだけでクリックに応じてスタイルを切り替える

動作サンプル

あまねけ！には、ページ左上の太陽 or 新月のマークでダークモードとライトモードを切り替える機能や、ページ右上の虫眼鏡のマークで文字の大きさを切り替える機能があります。このような動作は、JavaScriptを使えばクリックイベントでクラスを切り替えたり、カラーテーマについては color-scheme 属性を書き換えれば実現できるものです。

もしこの機能をCSSのみで実現したい場合は、非表示のチェックボックスにラベルを紐付けて、チェック状態に応じてスタイルを切り替えるのがよいでしょう。

/* 「状態」を保持するチェックボックスを隠しつつフォーカス可能にする */
input[type="checkbox"]#toggle {
  position: absolute;
  pointer-events: none;
  clip-path: rect(0 0 0 0);
  opacity: 0;
  appearance: none;
}

/* ユーザーに提示する切り替えUI */
label#toggle-button::before {
  content: "ここをクリックして背景色を変更";
}
input[type="checkbox"]#toggle:focus ~ label#toggle-button {
  outline: 2px solid royalblue;
}

/* 切り替えるスタイルの定義 */
#main {
  background-color: red;
}
input[type="checkbox"]#toggle:checked ~ #main {
  color: #eee;
  background-color: blue;
}

少し複雑ですが、実際に異なる2つのスタイルを宣言しているのは #main と input[type="checkbox"]#toggle:checked ~ #main のみです。他はユーザーに見せるためのクリック可能なラベルのスタイルと、チェックボックスを一切表示させないままフォーカス可能にするための工夫になっています。

もしチェックボックスを display: none などで隠してしまうと、マウス以外のインターフェース（Tabキーなど）でラベルに到達するのが難しくなるので、アクセシビリティの観点からこれらのスタイルをおすすめします。フォーカスしたことが分かりやすいよう、 outline 属性で可視化するのもポイントです。

この手法はcolor-schemeとprefers-color-schemeのつかいかたで触れたものとほぼ同じです。兄方向・親方向に辿るセレクタが書けなかった時代に作ったので、チェックボックスをbody直下に置いて、その弟要素としてsectionを置いて全てのコンテンツを詰める、というちょっと特殊なレイアウトが必要なのが難点ですね。

最近は :has() 疑似クラスが広く利用できるようになりつつあるので、最近のブラウザが対象なら以下のように素直なセレクタにできるでしょう。

body:has(input[type="checkbox"]#toggle:checked) #main {
  color: #eee;
  background-color: blue;
}
label#toggle-button:has(input[type="checkbox"]#toggle:focus) {
  outline: 2px solid royalblue;
}

これで「チェックボックスの直後のセクション」から「子にチェックボックスがあるbody」と、セレクタの基準が実際にスタイルを当てられる側に移ります。さらに、チェックボックスを上位に置く必要もなくなるので、再利用可能なコンポーネントに詰めて影響範囲を閉じることさえ可能です。

⑦ CSSだけでランダムっぽいパラメータを使う

動作サンプル

あまねけ！では、季節に合わせたミニ・エフェクト（参考）のように、ランダムな位置や動きを実現したいシーンがあります。

CSSで ランダムっぽさ を完結させたい場合は、事前にランダムな値を生成しておくか、ランダムっぽい計算を通せばよいでしょう。JavaScriptなら Math.random() で擬似乱数を得ることができますが、素直にやると各CSS属性のために何度も乱数を生成して大量に引き渡す実装になったり、スタイルの責務が曖昧になったりして筋が悪そうです。

もし完全にCSSのみでランダムっぽさを得たい場合は、CSS変数をシードとして非線形関数に通すのがおすすめです。CSSでは sin() や cos() といった三角関数が利用でき、これらはあらゆる数値を-1から1に変換する関数とみなせるので、以下のような使い方ができます。GLSLの古典的なハッシュ関数のアルゴリズムと同じですね。

.sample-07-random-position {
  --left: (mod(sin(var(--seed) * 12.9898 * var(--index)) * 43758.5453, 1) * 95svw);
  --top: (mod(sin(var(--seed) * 78.233 * var(--index)) * 43758.5453, 1) * 95svh);
  position: fixed;
  left: calc(var(--left));
  top: calc(var(--top));
}

周期を超える大きめの数値を三角関数に通すと乱数っぽく見える性質を利用したもので、実際にはCSS変数で値が確定する決定的な計算しかしていません。サンプルページでスライダーを動かしてみると分かるとおり、実際には位置が偏ったりいかにも正弦波のプロットっぽい配置に近づくこともあります。それでも、簡単な処理で大量に取り出せるランダムプールとしては十分です。

おわりに

CSSだけで実現できることは、他にもたくさんあります！　ちょっとした位置合わせや平面的な大きさの設定だけがCSSの能力ではありません。paddingとmarginの違いを峻別できるかなんて、広いCSSの世界の中では本当に小さな豆知識だということです。

そよ風に流される複雑なアニメーション、簡易的なダイアログ表示、ダークモードに合わせた画像反転、OSが提示した文字サイズへの追従、などなど……シンプルかつ安全な宣言的記述で「もう一歩」を叶えられるのがCSSの魅力です。みなさんもぜひ、日常生活のちょっとしたところからCSSを取り入れてみてくださいね。

先日個人サイトwebオンリーめぐる市(2026)サークル参加・全スペース制覇ログ・お気に入りサイト紹介であまねけ！の「個人サイトWebオンリーめぐる市」参加によせてを紹介いただいたヒフミさんのサイト「涼流花」の記事です。 ↩

今日できる！「読みやすい小説本」を作る10個のチェックポイント

2026-06-18T22:23:00+09:00

即売会で文芸サークルを回って見本誌を読んでいるとき、どうしても紙面の文字が頭に入ってこないことがあります。中身を理解するより先に、ページを先に進めるのがなんか面倒だなーと思う瞬間があるのです。

そういう本の紙面に感じる違和感はいろいろ。文字が小さくて読みにくい、あるいは判型に対して不自然に大きくて目が滑る。字　間　が　大　き　く　てリズムが掴めない、あるいは狭すぎて窮屈でせっかちな印象になる。行間が広くて、狭くて……綴られているのはきっとよく練られた素敵なフレーズなのでしょうが、そんなページに置かれただけで陳腐な印象になる気がします。

余白の取り方もそうです。たいていの文庫本は上（天）と下（地）の余白がどちらかに偏っていて、ぴったり揃えた紙面には違和感を感じるはず。でも、世の中には明らかにワープロソフトで適当に決めた余白の同人誌が出回っています。本の構造上、綴じ側（のど）は外側（小口）より大きな余白になるのが普通ですが、たまに行がのどにぴっちり食い込んで読みにくい同人誌も見かけます。

様々なデバイスで文字を読める今の時代に、わざわざ紙あるいは紙を模した平面で作品を発表するなら、できるかぎりその意味にこだわりたいところです。文章をただテキスト情報として伝えたいだけなら、読者にレイアウトを任せるリフロー型の電子書籍メディア¹を使うのがお互いに最適であって、わざわざ柔軟性もなく利便性も低い紙束を配る必要はないでしょう。

では、よい紙面とは何か？　それをどう作るのか？　その答えは非常にシンプルで、自分が読みやすいなと思った本を真似すればよいのです。文字の大きさ、行数、余白はどうなっているか、ノンブルや柱はどこに入っているか、などなど。

具体的には、以下のような10個のチェックリストを埋めていくのがよいでしょう。この記事を印刷したり、コピーしてメモアプリに貼り付ければチェックリストとして使えます。

① 本の判型（大きさ）は？
② 文字の大きさは？²
③ 1行に何文字くらい入ってる？³
④ 1ページに何行くらい入ってる？⁴
⑤ 版面（文字が印刷されている部分）は何mmある？
⑥ 天（上側）の余白は何mmある？
⑦ 地（下側）の余白は何mmある？
⑧ 小口（外側）の余白は何mmある？
⑨ ノンブル（ページ番号）はどこに入ってる？
⑩ 柱（ページのタイトル・見出しなど）はどこに入ってる？

実際の紙面に合わせるとこんな感じになります。

なお、版面の大きさを指定できず、代わりにのど（内側）の余白で配置を決めなければならない場合は、判型の横の長さから版面の横の長さと小口の余白を引くと、のどの余白が分かります。

チェックリストが埋まったら、これらの情報を元にお手持ちのワープロソフトや組版システムでページを調整します。もし自分の文芸同人誌でこのような点を気にしたことがなければ、まずはその同人誌の測定から始めるとよいでしょう。この記事では10個のチェックポイントに絞りましたが、本を眺めて気になった点はどんどん確認するべきです。扉はどんなデザインか、目次をどのように入れているか、どちらのページから始まっているか、などなど。

冒頭で触れた「目が滑る同人誌」は、そういうちょっとした観察や読者としての視線を感じない本だ、とも言い換えられます。本が読者に与える印象は、表紙のロゴタイプの綺麗さやイラストの エモさ だけで決まるわけではなく、ぱらぱらと立ち読みしたときの紙面の印象でも大きく変わるものです。

調整が終わったら、最後に見開きの一面（2ページ）で等倍に印刷してチェックしてみましょう。文庫本はA5サイズに、A5版はA4サイズになりますが、どちらもA4に印刷してかまいません。コンビニでのPDF印刷では「用紙に合わせる」ような設定を外すボタンが分かりにくいことがあります。

さて、新しい紙面は違和感なく仕上がりましたか？　調整前の紙面と見比べると、その違いをより意識できると思います。今回紹介したチェックリストが、あなたの素敵な作品を仕上げる際の参考になれば幸いです。

デバイスの画面サイズやウィンドウの大きさ、フォントサイズの設定に応じて再レイアウト（reflow）できる形式です。PDFのように決まった紙面を拡大・縮小するのではなく、ブラウザで文章を読むような体験を提供できます。テキストデータを含むので、検索機能や読み上げ機能とも相性がよいです。 ↩
読んでいる本の文字サイズがわかるしおりなどがあれば、大まかなサイズ感を掴むのが楽になります。 ↩
記号類が占める大きさが違ったり、禁則処理などで追い込まれたり追い出されて1行の文字数が変わることがあります。周囲に禁則文字がなく、正方形の空間を占めるふつうの文字の行で比較するとよいでしょう。ここから字間を逆算できます。 ↩
大きな文字の見出しやその周囲の余白、あるいは脚注が入って1ページの行数が減ることがあります。ふつうの本文のみで占められたページで比較するとよいでしょう。ここから行間を逆算できます。 ↩

たった今データを失うかもしれない君に捧ぐ10個の質問

2026-05-22T15:18:00+09:00

最近、Google DriveやDropboxといった大手のクラウドストレージサービスから突然BANされたとか、異議申し立てが全く認められずデータを喪失するといった事故がしばしば注意喚起としてSNSで拡散されることが増えました。しかし、多くの人はこうした事故を知りつつ 専制的なクラウドストレージサービス を漫然と使い続け、横暴なBANを待つ列に並んで暇を潰しているのが現状です。

本記事ではこうした専制的なクラウドストレージサービスの具体的なリスクを理解し、安全にデータを保管するにはまずは何をすべきなのか、10個の質問を通して示します。

私は普通のデータしか置いてないから大丈夫だよね？
いま使ってるクラウドストレージは一切使うなってこと？
リスクを意識してクラウドストレージを使う、って具体的にはどういうこと？
BANされるかもしれないデータは暗号化すれば大丈夫だよね？
プライバシー重視のクラウドストレージってなんなの？
でも、プライバシー重視のクラウドストレージって高いでしょ？
クラウドストレージの移行って面倒じゃない？
プライバシー重視って言ってるけど完全に信頼していいの？
そう言ってるあんたはどんなクラウドストレージサービスを使ってるわけ？
で、私は結局今からどうすればいいんだっけ？

私は普通のデータしか置いてないから大丈夫だよね？

おそらく、いいえ。

あなたがアップロードしたデータが普通かどうかは、あなたではなく（もちろん私でもなく）クラウドストレージサービスの運営事業者が 勝手に （！）決めることです。

明日からいきなり「56そう」とか「安楽死」という歌詞が含まれた楽曲や、肌色が50%以上を占める画像を所持しているアカウントを発見しだいBANします！なんてことになっても、あなたは大丈夫と言い切れますか？　もっともっと恣意的に、運営事業者を批判するこうした文書が全面的に禁止されるかもしれません。

しかも現代では、さらに込み入った検閲基準を備えたAIが24時間365日ストレージを監視して回っています。人手不足も疲れも知らない検閲チームって、なんだかすごく不気味ですよね。あなたも今日まで偶然BANされなかったというだけで、明日にはこうした不気味なAIがジロジロと普通のデータを覗き見てくるかもしれませんよ。

いま使ってるクラウドストレージは一切使うなってこと？

できるだけ、はい。

大手のクラウドストレージサービスには便利な共有機能や同期機能が用意されていますが、これらの多くは無条件にプライバシーを犠牲にせずとも十分に実現できます。効率の良い配信や利便性向上のためにデータを読むだけならまだしも、それを一方的なBANに使うなら話は別です。

かれらは便利でクールに見える機能でユーザーの目を引き、プライバシー侵害を正当化しようとしているだけです。

ただし、これらのクラウドストレージサービスから今すぐ撤退する必要はありません。これらを「勝手に消えるかもしれない」「一時的な利用のための」「覗き見られても平気なデータを置く」信頼できないサービスとして使い続けられます。つまり、どういうリスクと引き換えなのかをよく意識して使えば、もしもの時に被る実害を減らせるということです。

リスクを意識してクラウドストレージを使う、って具体的にはどういうこと？

鋭い質問ですね！

たとえば、クラウドストレージサービスにアップロードするデータは必ずローカルにも保存しておく、というルールを守っていれば突然BANに遭っても手元にはデータが残ります。クラウドストレージはあくまでバックアップで、原本は常に手元で保管するということです。これは、Google Driveの同期設定では「ミラーリング」と呼ばれているものです。

一方の「ストリーミング」は、ローカルストレージの節約という名目で手元にはファイルのリストだけを持っています。必要に応じてデータをダウンロードして閲覧・編集するという設定なので、BANされた時点で他のデータも巻き込んで一切アクセスできなくなってしまいます。

また、BANによる爆発半径を抑制するために複数のアカウントを持っておくのも有効なアイデアです。特にGoogle DriveはGoogle アカウントを介してメールや連絡先、Google Playなどと同一のアイデンティティとして取り扱われるので、BANによる被害が非常に大きくなりがちです。

そのため、Google Drive専用のアカウントに分けるのは基本的ながら効果の高い対策になります。

いずれの場合でも、運営事業者があなたのデータを検閲したり、サービス向上目的と称して営利活動のエサにする可能性は避けられません。これも勘案すべきリスクです。

BANされるかもしれないデータは暗号化すれば大丈夫だよね？

おそらく、はい。

CryptomatorやVeraCryptで暗号化したアーカイブをクラウドストレージサービスにバックアップすれば、原理的に（これは運営事業者がどう頑張っても、という意味です）検閲されたり無断利用されることはありません。運営事業者からはどう頑張ってもランダムなバイナリにしか見えないからです。つまり「覗き見られても平気な」データを置いてリスクを回避する手法です。

ただし、これらの暗号化アーカイブはフォルダ階層を特別な形式で1つのファイルにまとめているため、普通のフォルダより使い勝手が悪く独特な挙動を示したり、クラウドストレージサービスによっては上手く同期できない場合があります。また、サービス固有の便利な機能は一切使えないと考えた方がいいでしょう。

そうなってくると、いよいよどうしてそんな信頼できないサービスにデータを預けているのかよく分かりません。もし プライバシー重視のクラウドストレージサービス に移行したなら、難しい暗号化レイヤーを自前で用意する必要はなくなりますよ。

プライバシー重視のクラウドストレージってなんなの？

それ、本質的な問いです！

この記事では主に、運営事業者がユーザーから預かったデータを原理的に覗き見できない仕組みを採用しているサービスを プライバシー重視 と称しています。

原理的に覗き見できない、というのは運営事業者がどう頑張ってもファイルを読めない、という意味です。逆に言えば、Google DriveやDropboxのようなサービスは、権限制御や内部統制といった契約でデータへのアクセスを制限しています。そうしたサービスは国家権力の要請でファイルを引き渡したり、強制的なスキャンで一方的なBANを行使できる権力を握っています。

プライバシー重視のクラウドストレージサービスでは、ユーザーがアップロードしたデータは必ず暗号化された状態で保存されている上に、その復号鍵を運営事業者では保持せずにユーザーだけが利用できるようになっています。

これを実現する代表的な方法が E2EE （エンドツーエンド暗号化/クライアントサイド暗号化）であり、BANされるかもしれないデータどころか全てのデータを自動的に暗号化した上でアップロードする仕組みを初めから持っています。私たちはこの仕組みに乗っかるだけでよく、わざわざ独自の暗号化アーカイブを苦心して運用する必要はありません。

なお、Google DriveやDropboxも保存先のストレージは暗号化されているはずですが、適切な監査を経た（と主張する）手続きで復号鍵を取り出してファイルを取得できるという点で、プライバシー重視とはいえません。

でも、プライバシー重視のクラウドストレージって高いでしょ？

わずかに、はい。

ただし、費用と容量の比で見て何倍もかかることはありません。たとえば、Google OneのBasicプランを使っている人がProton DriveのDrive Plusプランに移行するなら、 240円/100GB/月 から 500円/200GB/月 になります。容量が2倍になって価格は2倍とちょっと、そこにプライバシー重視のおまけつきです。むしろお得じゃありません？

特に、いまGoogle Oneを使っていて100GBで足りなくなった人がアップグレードした場合、次のプランはGoogle AI Plusと称して勝手にAI機能を盛った 1000円/200GB/月 のものになるので、Proton Driveへの移行の方が費用面でも大きなメリットがあります。

サービス	無料枠	最小の有料プラン
Google One	15GB	240円/100GB/月
Dropbox	2GB	1200円/2TB/月
OneDrive	5GB	200円/100GB/月
Proton Drive	5GB	500円/200GB/月
Sync.com	5GB	560円/150GB/月
MEGA	10GB	620円/200GB/月

もしGoogle DriveやOneDriveを無料枠で使っているなら、MEGAはかなり大きめの無料枠があるので、すぐに移行できるはずです。無料枠から無料枠に移すだけでおまけに安心まで付いてくるなら、試してみる価値があると思いませんか？

クラウドストレージの移行って面倒じゃない？

ある程度、はい。

でも、現実の引っ越しのように数時間や数日で全てのデータを移す必要はないので、少しずつ進めてみましょう。パソコンのデータ移行とだいたい同じです。

初めに、無料枠で済む範囲の作業を新しいクラウドストレージサービスで行うようにします。新しいファイルはProton Driveに保存する、Google Driveにあるファイルを編集するときはProton Driveに移してから開く、といった感じです。ここで新しいサービスの使い勝手を確かめながら、少しずつGoogle Driveの使用容量を減らしていきます。

この移行期間中に、Proton Driveを使う上で甘受できない不便さを感じるかもしれません。その場合は別のクラウドストレージサービスを使ってみたり、いったんリスクを受け入れてGoogle Driveに戻る、という選択もありえます。リスクは比較の上に成り立つ定量的なものであり、ゼロリスクを目指すのもリスクを全て無視するのも愚かさで言えば全く同じです。

そして、新しいクラウドストレージサービスの使い勝手に問題がなさそうなら、1ヶ月くらい利用期間が被るように新しいサービスのプランを契約します。この間に少しずつ移行を進めて、元のサービス側は無料枠に収まる程度までファイルを減らしていけば、移行はほぼ完了です。元のサービスのプランは忘れずに解約して、しばらく併用するなり気長に移行したりするといいでしょう。

面倒なこともまずは初めの一歩からです。まずは前問のテーブルからの付いたクラウドストレージサービスを選んで、アカウントを登録してください。登録にお金は一切かかりません！　迷ったらProton Driveがおすすめです。

プライバシー重視って言ってるけど完全に信頼していいの？

ほとんど、いいえ。

専制的なクラウドストレージサービスが かなり 信頼できないのと同じように、プライバシー重視のクラウドストレージサービスも ある程度 は信頼できません。原理的に覗き見できても契約や運用で不当な検閲を防ぐことはできますし、逆にE2EEを謳っていてもバグや利便性向上のための処理でデータが漏れる経路があるかもしれません。

ただし、これはどういうリスクがあるかを考慮すべきという意味であって、より信頼に足らないサービスを使い続ける理由にはなりません。リスクを知って受け入れた上で、やはり私はプライバシー重視のクラウドストレージサービスを使うべきだと思います。

このような外部リスクの勘案を諦めて運営事業者を全く信頼せず、クラウドストレージサービスを一切使わない原理主義的な人も多くいます。こうした人たちは自宅でNASを構築してデータを保管したり、さらにその運用を勧めて回ったりしていますが、実際はデータ喪失のリスクを負っていることを意識しなければいけません。

まともなNASの運用には、ストレージの故障に備えて冗長なファイルシステムやバックアップの仕組みを構築するのは当然として、災害・盗難に備えた保存メディアや保管場所の分散が求められます（3-2-1ルールと呼ばれるものです）。

これらの専門的な知識を備えたミスのないオペレーションを目指すのは趣味としては面白いかもしれませんが、Google DriveからいきなりNASへの移行を勧めるのはなかなか酷なことです。一般的なユーザーであれば、適切にデータを管理できる事業者を選んで ある程度 信頼した方が安心です。

そう言ってるあんたはどんなクラウドストレージサービスを使ってるわけ？

興味が出てきたみたいですね！

私は主にSync.comのPro Solo (2TB)プランを使っています。ここに自宅に構築したNextcloudを併用して、E2EEになじまないアプリなどのストレージを用意している感じです。一応ProtonのUnlimitedプランなのでProton Driveも使えるんですが、こっちはメールサービスがメインなのでほとんど使っていません。

独自ドメインでメールアドレスを使うために、Protonにメールを移行する前はGoogle Workspace（登録した頃はG Suiteでしたね）を契約していて、今もなんやかんやメール以外のサービスを使っています。Google Driveの容量が余っているのでrcloneの暗号化バックアップ先にしたり、Geminiで適当に遊んだりするのにも便利です。

企業向け契約のプランならBANされにくいという噂もありますが、割高な上に完全な無検閲無法地帯として開放されているわけではないと思うので（特にCSAMやマルウェアにあたるコンテンツの検閲は厳しいはず）、変な回り道をせずにまともなクラウドストレージサービスを使ってください。

で、私は結局今からどうすればいいんだっけ？

やった！

じゃあ、今すぐ ① Protonのアカウントを作って、 ② Proton Driveアプリをインストールして、 ③ 今日からファイルの編集は全てProton Driveのフォルダでやってみてください。④ それからのことは来週考えればです！

Protonなら紹介リンクもあるから、よければ使ってね～。

デスクトップに面白い文字を流そう

2026-03-29T12:32:00+09:00

ここまでのあらすじ
- LED News Ticker
- LED AppBar
デスクトップに面白い文字を流そう
これから……？

ここまでのあらすじ

先日、デスクトップに文字を流し続ける小さなウィジェット「LED AppBar」を作りました。今は、ここにどんな文字を流したら面白いだろうか、ということを考えています――

LED News Ticker

Rust+Wasmで爆速ライフゲームを作って動く壁紙にするという記事を読み、動画やウェブページをライブ壁紙として設定できるLively Wallpaperというツールを知りました。このツールで何かライブ壁紙を設定してみたいと思って生まれたのが、LED News Tickerです。

LED News Tickerができることは主に2つ。固定の壁紙を表示することと、画面上部に配置された横長のLEDマトリクスパネル風の領域に任意のテキストを流すことです。これはいわゆるニュースティッカーと呼ばれるもので、あまねけ！の上部に流れている広告も同様のスタイルです。

LEDマトリクスパネル風の領域にニュースが流れている様子

そもそもLEDマトリクスパネルの実物を見たことがない方のために、一応実物の動画も置いておきます。こういう単色の小さなものなら数千円で買えますし、パトカーの後ろに設置されているパネルも同じものです。かつて新幹線で流れていた車内ニューステロップを想像してもよいでしょう。

流れるテキストは、事前に設定したフィードの定期取得やWebSocket・SSEの受信で順次切り替わっていきます。パラメータを付けずに開くと、たぶんニュースっぽい背景にNHKニュースのヘッドラインが流れるはずです。画面右下にマウスカーソルを寄せたり、タップすると設定画面が開けます。

LED AppBar

さて、Lively Wallpaperでこのページを壁紙に表示して楽しく過ごしていたのですが、実はパソコンを使っている間に壁紙を見る瞬間はそう多くないことに気付きました。いつも2つの画面にエディタとターミナルか調べ物のブラウザを表示していて、壁紙が出てくるのはウィンドウを切り替えるごくわずかな合間くらいです。

そこで、LED News Tickerからニュースティッカー部分のみを取り出して、さらに画面上部に固定するWindows用アプリLED AppBarを作りました。このアプリはWindowsのAppBar APIを利用して画面端領域を独占するもので、要はオリジナルのタスクバーを画面端に表示するイメージです。

このアプリ自体はニュースティッカーを同梱しておらず、中身はLED News Tickerのティッカー部分を表示する細い画面のブラウザと同じようなものです。つまり、URLを入れ替えれば任意のコンテンツを表示できるので、画面上部にニュースティッカー以外を表示したい人も使ってみてください。設定はトレイアイコンを右クリックで「Set URL...」です。

例えば、12人のキャラクターの視線で作業を監視してもらうことができます:

なお、LED AppBarはTauriで書かれていて、本来はクロスプラットフォームビルドできるのですがWindows以外には対応していません。前述の通り、画面上部を独占的に利用するWindowsシェルのAPIに依存しているからです。

RustからWindowsのAPI（Win32 API）を呼び出すには、Microsoft公式のwindowsクレートを使うのが最も手軽でしょう。以下の例の通り、 #[cfg(windows)] でWindows環境を識別して、 unsafe ブロック内で必要なAPIを呼び出す……というのが主な使い方です。

// 🌟 Windows環境でのみ動作するようガードする
#[cfg(windows)]
pub mod platform {
    pub fn register_appbar(hwnd: isize, bar_height: u32, monitor_index: u32) -> bool {
        let monitors = enumerate_monitors();
        // ...
        // 🌟 パラメータ準備とAPI呼び出しは unsafe にする
        unsafe {
            // ...
            let mut abd: APPBARDATA = mem::zeroed();
            abd.cbSize = mem::size_of::<APPBARDATA>() as u32;
            // ...
            let result = SHAppBarMessage(ABM_NEW, &mut abd);
            if result == 0 {
                log::error!("ABM_NEW failed");
                return false;
            }
            // ...
            {
                let mut orig = ORIGINAL_WNDPROC.lock().unwrap();
                if *orig == 0 {
                    let prev = GetWindowLongPtrW(hwnd, GWL_WNDPROC);
                    *orig = prev;
                    // 🌟 Rust側の関数をコールバックするAPI（appbar_wndproc）
                    SetWindowLongPtrW(hwnd, GWL_WNDPROC, appbar_wndproc as *const () as isize);
                }
            }
            // ...
        }
        true
    }

    // 🌟 Win32 APIに渡すコールバック関数なので、 extern "system" で呼び出し規約を揃える
    unsafe extern "system" fn appbar_wndproc(
        hwnd: HWND,
        msg: u32,
        wparam: WPARAM,
        lparam: LPARAM,
    ) -> LRESULT {
        // ...
        windows::Win32::UI::WindowsAndMessaging::DefWindowProcW(hwnd, msg, wparam, lparam)
    }
}

// 🌟 非Windows環境向けに、何もしないスタブを配置しておいてもよい
#[cfg(not(windows))]
pub mod platform {
    // ...
}

Win32 API側からコールバックで呼び出す関数宣言には extern "system" を付与するというのもポイントです。これは、RustコンパイラにWin32 APIの関数呼び出し規約に従うよう指示する宣言で、C++でマングリングを無効化したいとき¹に extern "C" を付けて関数定義するのと似ています。

高校生の頃に、C++で頑張って（なんとBitBltで！）クラスマッチのタイムテーブル管理アプリを作ってからというもの、なんとなくWindows GUIプログラミングに少し苦手意識があったのですが、こんなに簡単ならまた何か作ってみてもいいかもしれません。

デスクトップに面白い文字を流そう

さて、ここからが本題です。LED News TickerやLED AppBarをニュースティッカーとして使えば、好きなテキストを目立つ位置に流し続けることができます。

では、どんなテキストを流すのが面白いでしょうか？

ニュースのフィードを流す

ニュースティッカーにニュースを流すのはオーソドックスな使い方です。NHKニュースのフィードやGoogleニュースのフィードを流しておけば、テレビでニュースを垂れ流すのと同じくらい、あるいはそれ以上にストレスなくシンプルにヘッドラインを知ることができます。

これはかなり実用性が高いと思います。実際私もよく使っています。

インターネットのフィードを流す

はてなブックマークの人気エントリーやGIGAZINE、その他インターネットで話題になりやすいサイトのフィードを流しておくと、わざわざX（旧Twitter）を眺めなくても、作業のついでにトレンドを追えるかもしれません。

ただし、LED News Tickerはフィードのタイトルのみを流す仕組みなので、タイトルが内容の要約になっていないとか、クリックベイトじみた煽りタイトルの記事ばかりのフィードを流すのにはあまり向いていません。

速報性の高いニュース記事の多くは伝えるべき情報をタイトルで提示してくれますし、本文はさほど重要ではないケースも多いです。一方で、コラムやエッセイ、読み物のような記事になると、タイトルでストーリーやオチまで説明されると野暮だと感じることさえあるでしょう。

一度に十数文字しか流せない情報量の低さでもニュースティッカーが成り立つのは、タイトルで情報が完結するという仮定が前提になっています。インターネットのトレンドを流す場合は、なんとなく話題になっているキーワードを知る程度の使い方がちょうどいいかもしれません。

自分で用意したテキストをランダムに流す

ニュースやトレンドではなく、事前に用意したテキストを流すのもよい使い方です。よくSNSで見かけるbotのように、誰かの名言を流し続けるとか、ずかんのフレーバーテキスト集を作るとか、来週の資格試験のために暗記したい文章をずっと流しておくとか、聖書や日本国憲法からランダムに1フレーズを選んだりすることもできます。

まず、改行区切りでテキストを記載した data.txt を作りましょう:

ひとみを のぞきこむと じぶんの すがたが みえる。だが その かおは いつも すこしだけ わらっている。
だいじな ひとを わすれた にんげんの そばに あらわれる。かおりを かぐと なぜか なみだが でるという。
いちど なかまと みとめた あいてを にどと はなさない。トレーナーが きえても その ばしょで まわりつづける。
やくそくを やぶった にんげんを さがしだす。みつけると こゆびに あかい いとを まきつけて どこかへ つれさる。
はなびらが じかんごとに いちまいずつ ちる。さいごの いちまいが ちるとき なにが おこるかは だれも しらない。

これを以下のスクリプト random-words.mjs と同じフォルダに置いて実行します。30秒に一回のペースで data.txt からランダムなテキストをSSEで配信する簡単なスクリプトです。SSEというのは、サーバからリアルタイムにコンテンツを配信する仕組みのひとつです。

// @ts-check
// Random words SSE Server
// Usage: node random-words.mjs

import { createServer } from "node:http";
import { readFileSync } from "node:fs";

const POLL_INTERVAL = 30_000;
const PORT = 3000;
const LIST = readFileSync("data.txt", "utf-8").split("\n").filter(Boolean);

createServer(async (req, res) => {
  const url = new URL(req.url ?? "/", `http://127.0.0.1:${PORT}`);

  if (url.pathname === "/") {
    res.writeHead(200, {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache",
      Connection: "keep-alive",
      "Access-Control-Allow-Origin": "*",
    });

    let alive = true;

    req.on("close", () => {
      alive = false;
    });

    while (alive) {
      try {
        const item = LIST[Math.floor(Math.random() * LIST.length)];
        res.write(`data: ${item}\n\n`);
      } catch (e) {
        console.error("polling error:", e);
        res.write("data: 情報取得に失敗しました\n\n");
      }
      await new Promise((r) => setTimeout(r, POLL_INTERVAL));
    }
    return;
  }

  res.writeHead(404, { "Content-Type": "text/plain" });
  res.end();
}).listen(PORT, () => {
  console.log(`Random words SSE Server: http://127.0.0.1:${PORT}/`);
});

random-words.mjs

Node.jsが入っていなければ、コマンドプロンプトあたりで winget install -e --id OpenJS.NodeJS.LTS を実行すれば手軽にインストールできます。環境が準備できたら起動してみましょう:

> node random-words.mjs
Random words SSE Server: http://127.0.0.1:3000/

同じフォルダにバッチファイル random-words.bat を置いておけば、ワンタッチで起動できます:

cd /d "%~dp0"
node random-words.mjs

起動後にローカルSSEが流れるティッカーを設定すると、用意したテキストが流れてくるはずです。トレイアイコンを右クリックで「Set Server...」からこのバッチファイルを指定すると、LED AppBarの起動と同時に常駐してくれるので便利です。文字化けしているようなら、 data.txt がUTF-8で保存されているかを改めて確認してみてください。

SpotifyのNow Playingを流す

部屋に流れている曲の情報が流れるのって、音楽にこだわってる喫茶店みたいでおしゃれですね。Spotifyから再生中の曲を引くAPIは用意されているので、それをローカルに配信してLED AppBarが受け取れば簡単に表示できます。

まず、Spotify for DevelopersでAPIを利用するアプリケーションを登録しましょう。

App name/App description/Website: なんでも
Redirect URIs: http://127.0.0.1:3000/callback²
Which API/SDKs are you planning to use?: Web API

ここからClient IDとClient secretをコピーして、以下のスクリプト spotify-now-playing.mjs を実行します。10秒に一回のペースで再生中の曲を取得してSSEで配信する簡単なスクリプトです。

// @ts-check
// Spotify Now Playing SSE Server
// Usage: node spotify-now-playing.mjs

import { createServer } from "node:http";
import { exec } from "child_process";

const CLIENT_ID = process.env.SPOTIFY_CLIENT_ID ?? "YOUR_CLIENT_ID";
const CLIENT_SECRET = process.env.SPOTIFY_CLIENT_SECRET ?? "YOUR_CLIENT_SECRET";
const REDIRECT_URI = "http://127.0.0.1:3000/callback";
const SCOPES = "user-read-currently-playing user-read-playback-state";
const POLL_INTERVAL = 10_000;
const PORT = 3000;

let accessToken = "";
let refreshToken = "";
let tokenExpiresAt = 0;

const basicAuth = () =>
  Buffer.from(`${CLIENT_ID}:${CLIENT_SECRET}`).toString("base64");

/**
 * @param {string} code
 */
async function exchangeCode(code) {
  const res = await fetch("https://accounts.spotify.com/api/token", {
    method: "POST",
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
      Authorization: `Basic ${basicAuth()}`,
    },
    body: new URLSearchParams({
      grant_type: "authorization_code",
      code,
      redirect_uri: REDIRECT_URI,
    }),
  });
  const data = await res.json();
  accessToken = data.access_token;
  refreshToken = data.refresh_token;
  tokenExpiresAt = Date.now() + data.expires_in * 1000;
}

async function ensureToken() {
  if (Date.now() < tokenExpiresAt - 60_000) return;
  if (!refreshToken) return;
  const res = await fetch("https://accounts.spotify.com/api/token", {
    method: "POST",
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
      Authorization: `Basic ${basicAuth()}`,
    },
    body: new URLSearchParams({
      grant_type: "refresh_token",
      refresh_token: refreshToken,
    }),
  });
  const data = await res.json();
  accessToken = data.access_token;
  if (data.refresh_token) refreshToken = data.refresh_token;
  tokenExpiresAt = Date.now() + data.expires_in * 1000;
}

async function getNowPlaying() {
  await ensureToken();
  if (!accessToken) return null;

  const res = await fetch(
    "https://api.spotify.com/v1/me/player/currently-playing",
    { headers: { Authorization: `Bearer ${accessToken}` } },
  );

  if (res.status === 204 || res.status === 401) return null;

  const data = await res.json();
  if (!data.item) return null;

  const track = data.item.name;
  const artists = data.item.artists
    .map((/** @type {{ name: string; }} */ a) => a.name)
    .join(", ");
  return `${track} - ${artists}`;
}

createServer(async (req, res) => {
  const url = new URL(req.url ?? "/", `http://127.0.0.1:${PORT}`);

  if (url.pathname === "/") {
    res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
    res.end(
      accessToken
        ? `GET http://127.0.0.1:${PORT}/now-playing から楽曲情報をSSEで配信します`
        : `GET http://127.0.0.1:${PORT}/login からSpotifyで認証を行ってください`,
    );
    return;
  }

  if (url.pathname === "/login") {
    const authUrl = new URL("https://accounts.spotify.com/authorize");
    authUrl.searchParams.set("response_type", "code");
    authUrl.searchParams.set("client_id", CLIENT_ID);
    authUrl.searchParams.set("scope", SCOPES);
    authUrl.searchParams.set("redirect_uri", REDIRECT_URI);
    res.writeHead(302, { Location: authUrl.toString() });
    res.end();
    return;
  }

  if (url.pathname === "/callback") {
    const code = url.searchParams.get("code");
    if (!code) {
      res.writeHead(400, { "Content-Type": "text/plain; charset=utf-8" });
      res.end("コードがありません");
      return;
    }
    await exchangeCode(code);
    res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
    res.end(
      `GET http://127.0.0.1:${PORT}/now-playing から楽曲情報をSSEで配信します`,
    );
    return;
  }

  if (url.pathname === "/now-playing") {
    if (!accessToken) {
      res.writeHead(401, { "Content-Type": "text/plain; charset=utf-8" });
      res.end(
        `GET http://127.0.0.1:${PORT}/login からSpotifyで認証を行ってください`,
      );
      return;
    }

    res.writeHead(200, {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache",
      Connection: "keep-alive",
      "Access-Control-Allow-Origin": "*",
    });

    let alive = true;
    let lastTrack = "";

    req.on("close", () => {
      alive = false;
    });

    while (alive) {
      try {
        const track = await getNowPlaying();
        if (track != null && track !== lastTrack) {
          res.write(`data: 再生中：${track}\n\n`);
          lastTrack = track;
        }
      } catch (e) {
        console.error("polling error:", e);
        res.write("data: 楽曲情報の取得に失敗しました\n\n");
      }
      await new Promise((r) => setTimeout(r, POLL_INTERVAL));
    }
    return;
  }

  res.writeHead(404, { "Content-Type": "text/plain" });
  res.end();
}).listen(PORT, () => {
  console.log(`Spotify Now Playing SSE Server: http://127.0.0.1:${PORT}/`);
  console.log(
    `http://127.0.0.1:${PORT}/login からSpotifyで認証を行ってください`,
  );
  exec(`start http://127.0.0.1:${PORT}/login`);
});

spotify-now-playing.mjs

では、動かしてみましょう。もし先に前節のランダムティッカーを起動していたら、そちらは止めてから実行してください。認証情報は以下のように環境変数で渡すか、スクリプトに直接記載してもいいです。

> set SPOTIFY_CLIENT_ID=xxx
> set SPOTIFY_CLIENT_SECRET=yyy
> node spotify-now-playing.mjs
Spotify Now Playing SSE Server: http://127.0.0.1:3000/
http://127.0.0.1:3000/login からSpotifyで認証を行ってください

バッチファイル spotify-now-playing.bat にするならこんな感じです:

cd /d "%~dp0"
set SPOTIFY_CLIENT_ID=xxx
set SPOTIFY_CLIENT_SECRET=yyy
node spotify-now-playing.mjs

起動したら画面の指示通りSpotifyでログインして、アプリケーションとの接続を許可します。許可後にNow Playingが流れるティッカーを設定すると、「再生中：曲名 - アーティスト」のような表示が流れていくはずです。こちらも、トレイアイコンを右クリックで「Set Server...」からこのバッチファイルを指定できます。

No Contextな文章を流す

文脈がよく分からない発言や意味のないテキストは、画面端を彩るインテリアにぴったりです。ここでは具体的な実装は示しませんが、以下のようなアイデアならすぐに実現できるでしょう。

Wikipediaのランダム記事サマリ https://ja.wikipedia.org/api/rest_v1/page/random/summary を流す³
GitHubのパブリックイベント https://api.github.com/events を取得して全世界のコミットメッセージを流す⁴
MisskeyのStreaming API wss://{host}/streaming からサンプリングした投稿を流す

もしコーディングが面倒なら、「30秒に一度localhost:3000にテキストデータをSSEで配信するNodeスクリプトを1ファイルで書いて。内容は～」とAIに指示すれば、好みのテキストを垂れ流すサーバのできあがりです。

これから……？

デスクトップに流したら面白い文字をいくつか紹介してきましたが、これらはほんの一例です。世界にはまだまだ面白い文字がたくさんあります！　あなたが今思い浮かべて思わずニヤニヤしているテキストも、フィードに出力したり簡単なSSEサーバを用意すればすぐに流すことができます。

みなさんもぜひ、LEDマトリクスパネル風ライブ壁紙ツール「LED News Ticker」やLEDマトリクスパネル風ウィジェット「LED AppBar」で面白い文字を流してみてください。いいアイデアがあったら共有してくれると嬉しいです。

Cのプログラムや、Cの呼び出し規約を通じて他の言語のプログラムからC++を呼び出す場合、 extern "C" でCのABIを提供する必要があります。 ↩
http://[::1]:3000/callback も入れておくといいかもしれません。セキュリティ上のコーナーケースを潰すためか、localhost は使えないようです。 ↩
冒頭の1～3文程度が入った extract を流すのがいい感じです。 ↩
このAPIにはコミットメッセージが含まれていないので、さらに個別のコミット情報を取得する必要があります。ただしこの方式だと呼び出し回数がかさむので、アクセストークンでの認証をおすすめします。 ↩

ぼくらの同人作品ビューア（概念）

2026-03-27T12:14:00+09:00

まえがき
同人作品ビューアを考える
同人作品ビューアを探す
同人作品ビューアを作る
あとがき

まえがき

DLsite Playはかなり素敵な同人作品ビューアです。公式説明によれば、

購入した作品のZIPファイルをダウンロードや解凍する手間もなく、ブラウザ上ですぐに作品を閲覧できる配信方法です。
パソコン、スマートフォン、タブレットなどブラウザとインターネットに接続できる環境さえあれば、いつでも手軽に作品を楽しむことができます。
ブラウザ視聴について（DLsite Play）

とのことで、2015年の提供開始¹からDLsiteユーザーの視聴体験を支え続けています。同人作品をブラウザ上で視聴できるというサービスは、当時大学生になったばかりの私にとっては相当な衝撃でした。どうにか同じようなアプリを自分で作れないものか、と友人と議論したのを覚えています。その時はシンプルな構成に収めようと、オンデマンドでZIPを解凍できるnginxモジュールを見つけて試したものでした。

2015年前後は、他サービスでも電子書籍のビューアを提供し始めたり、音楽のストリーミングサービスが参入し始める頃でしたが、多様な作品形式に対応していた点でDLsiteは一歩先を進んでいたといえます。それから10年経った2025年にも、DLsite GamePlayというスマホでPCゲームを遊べるストリーミングサービスを開始しており、かれらがいかにストレスなくコンテンツを楽しむ環境を重視しているかが分かるでしょう。

さて、DLsite Playはかなり素敵な同人作品ビューアですが、大きな問題点があります。それは、作品購入後であっても、サークルが退会したり販売終了したら読めなくなること。そして、DLsiteで購入した作品しか読めないことです。DLsiteというコンテンツ販売サービスを支えるためのビューアなので当たり前ではあるものの、この素敵な同人作品ビューア体験と引き換えに、過去の傑作がZIP倉庫²に押しやられるのを受け入れるわけにはいきません。

私が大学生の時分でDLsite Playクローンを作ろうと思ったのも、おおよそこういう事情によるものです。しかし、その夢は具体的な行動を伴わないまま10年ほどが経ちました。幸いにも、最近はこうした同人作品にも使えそうなOSSのビューアがいくつか出ていますし、今はClaude Codeが隔離されたWSLの上で動いているので、あの頃よりは理想を形にできそうです。

同人作品ビューアを考える

私が目指しているのは完全なDLsite Playクローンではありません。DLsite Playとは見た目や機能が似ていなくても、同人作品ビューア（あるいは同人作品管理システム）に必要な機能を備えていて、それが手元のコンテンツで動けばよいのです。

しかしこれは、実は完全なDLsite Playクローンを実現するより難しい取り組みです。私が同人作品ビューアに何を求めていて、何があれば使いやすいのか、あるいはあっても意味のない機能とは？　それが分からないまま進めるとどうなるか――本当に必要な機能が揃っているミニマルなビューアを見逃してしまう。なんとなく機能が多い無料のビューアを入れてもイマイチ使いづらい。それなら、とClaude Codeに全部盛りのシステムを作ってもらったのに3日で使わなくなる――せっかくのAI最新技術もこれでは無意味です。

こうした結末を防ぐために、仮に呼ぶとすれば「ぼくらの同人作品ビューア（概念）」がどんな姿をしているかを、事前によく想像しなければいけません。

DLsite Playはかなり素敵な同人作品ビューアで、こうした概念を取り出すのに適した題材です。改めて公式説明やDLsite Play自体を眺めて、DLsite Playのいいところ・よくないところを挙げてみましょう。好みや慣れに過ぎないような点、DLsite Playに限らない特徴もとりあえず書いておきます。

画像・PDF・音声・動画・テキストなど様々な形式のコンテンツを1つの画面で閲覧できる。
作品名とサークル名や作品形式が表示されており、必要に応じて絞り込める。
作品の購入日が記録されており、作品名やサークル名と同様にソートできる。
階層構造を持ったフォルダを閲覧できるシンプルなファイルマネージャ³として扱える。
フラットな同人作品の一覧と、階層構造を持つ同人作品フォルダの扱いを分離している。
PDFをスクロール可能な連続したページではなく、1枚ずつ画像リストとして表示できる。
音声はオーバーレイのキューで再生され、音声を聞きながら別の作品を読める。
コンテンツが配信用に最適化されており、ローディングの待ち時間を意識することが少ない。
よく使う機能はメニューバーに押し込めずに常に表示する一方で、細かいフィルタやソートも用意されており、UIのバランスがよい。
レスポンシブデザインに対応しており、スマートフォンでも快適に閲覧できる⁴。
オフラインでの閲覧手段がある。オフラインキャッシュとして、あるいは作品のZIPファイルをそのままダウンロードできる。

よくないところは前述の通り、DLsiteで配信中の作品しか読めない点と、別のプラットフォームや自前で用意したコンテンツを登録できない点が最も大きいです。また、サークル側が手軽にDRMをかけられるようになっていて、購入者の所有権を軽視する傾向がありますが、これはDLsite Play自体のデメリットではありません。

このような点を踏まえて、概念上の同人作品ビューアが備えるべき特徴を考えてみます。みなさんもやってみましょう。あったら嬉しいな、ではなく、これがなければ3日と経たずに捨ててしまうようなコア機能を探すのを意識してください。

そして、いろいろ探しながら私が辿り着いた最小限の「ぼくらの同人作品ビューア（概念）」は、「作品フォルダ指向のプレビュー付きファイルマネージャ」になりました。DLsite Playの特徴を参考にもう少し具体的に記述すると、以下のような感じです。

フラットな同人作品フォルダの一覧と、階層構造を持った同人作品フォルダの2つを完全に区別して表示できる。深い階層の作品を閲覧していても、すぐに同人作品の一覧に戻れる。
同人作品フォルダはファイルシステム上のファイル名とは異なる作品名を表示できる。ファイルシステムの制約を受けずに作品の名前を自由に設定できる。
画像・PDF・音声・動画・テキストなど様々な形式のコンテンツを新しいタブやウィンドウを開かずに閲覧できる。前後のファイルに移動したり再生状態を操作できる最低限のUIを持つ。

検索や絞り込み、購入日順ソート、サムネイル表示など実際に必要な機能は他にもいろいろありますが、最小限のコア機能はここだと思います。作品単位でとりあえず手軽にコンテンツを眺める、という使い方を想像してください。

コア機能のスコープが定まったので、次は既存のソフトウェアでこれを実現できないか、という論点に移りましょう。

同人作品ビューアを探す

改めて、「ぼくらの同人作品ビューア（概念）」を示します。

フラットな同人作品フォルダの一覧と、階層構造を持った同人作品フォルダの2つを完全に区別して表示できる。
同人作品フォルダはファイルシステム上のファイル名とは異なる作品名を表示できる。
画像・PDF・音声・動画・テキストなど様々な形式のコンテンツを新しいタブやウィンドウを開かずに閲覧できる。

この程度なら少し探せばあるんじゃない？と思うかもしれませんが、全てにマッチするアプリケーションはなかなか見つかりませんでした。

たとえば、Windowsのエクスプローラは、Alt+Pでプレビューウィンドウが使えるので3を満たしそうですが、実際はPDFは冒頭数ページだけ、音声や動画は外部アプリを開くので使い物になりません。1は全く区別できませんし、2ももちろんありません。

この基準で、いくつか同人作品ビューアとして使えそうなアプリケーションを眺めてみましょう。

アプリ	カテゴリ	作品リスト	フォルダ階層	別名表示	マルチメディア
DLsite Play	ブラウザ
LANraragi	ブラウザ/画像		-		△
Komga	ブラウザ/画像		-		△
Mangatsu	ブラウザ/画像		-		△
Kikoeru	ブラウザ/音声				△
Audiobookshelf	ブラウザ/音声		-		△
Stash	ブラウザ/動画		-		△
Nextcloud	ブラウザ	-		-
FileBrowser Quantum	ブラウザ	-		-
copyparty	ブラウザ	-		-
Windows Explorer	ローカル	-		-	△
Directory Opus	ローカル	-		-
XnView MP	ローカル/画像			-	△
NeeView	ローカル/画像			-	△
Hydrus Network	ローカル		-		△

マルチメディア列の△は、おおよそ一部の形式での使用に特化しており、他形式は未対応または簡易的なビューアのみ提供されているものです。

これらを大きく分類すると、以下の4つのタイプがありそうです。

タイプ	作品フォルダ指向	フォルダ階層	マルチメディア
DLsite Play
コミックを想定したビューア
ファイルマネージャ系
階層表示可能なビューア

これを見ると、必要な要素を全て満たすアプリケーションはほとんどないことが分かります。あんまり意味はないですが、一応MECEにしておきましょうか。

タイプ？	作品フォルダ指向	フォルダ階層	マルチメディア
弱いファイルマネージャ？
強いスライドショーアプリ？
強いビューア？
弱いビューア？

これらの分析をまとめると、「ぼくらの同人作品ビューア（概念）」に求められるのは「作品フォルダの管理機能があるファイルマネージャ」とか「多くのメディアに対応した階層表示可能なビューア」といったものになりそうです。前節での定義とほとんど変わりませんが、既存のアプリケーションとの比較でもう少し具体的な姿を描くことができました。

ここまで言語化できればしめたものです。問題は、この条件を満たすアプリケーションが見つからなかったことくらいでしょうか。

同人作品ビューアを作る

結局、いい感じの同人ビューアが見つからなかったので作ることにしました。デモ版をchkdrs-demo.amane.moeに置いてあるので、興味のある方は触ってみてください。 demo1:demodemo1 ～ demo9:demodemo9 でログインできます。

Ghostwriter digital.png is licensed under a CC BY-SA 4.0.

axum⁵のバックエンドとSvelteKit⁶のフロントエンドに、ローカルでの作品管理にも対応できるようにTauri⁷でデスクトップモードも用意したクロスプラットフォームアプリです。コーディングの多くはClaude Codeが担当していますが、私の目でチェックしたり口を出したりするときのことを考えて、慣れているRustにしました。まだ開発中ですが、既に3つのコア機能は満たしています。

フラットな同人作品フォルダの一覧と、階層構造を持った同人作品フォルダの2つを完全に区別して表示できます。
同人作品フォルダはファイルシステム上のファイル名とは異なる作品名を表示できます。
画像・PDF・音声・動画・テキストなど様々な形式のコンテンツをビューアペインで開けます。

さらに、利便性を高める以下の機能も実装しました。これがコア機能なのか追加機能なのかを区別できるのも、今回の分析あってこそです。

カタログ機能（作品を横断的にまとめるコレクション）
プレイリスト機能（ファイル単位で追加できるシーケンシャルなリスト）
簡易的なユーザ管理機能
サムネイル自動生成機能
配信用軽量メディア（画像リサイズなど）生成機能
汎用ファイルキャッシュ機能
ZIPダウンロード機能

まだジャンルやタグを利用できなかったり、検索機能が弱かったり、ブラウザ側から作品をアップロードする機能もありませんが、裏を返せば私にとってはそれほど重要な機能ではないということです。なんでもかんでもあれば嬉しいわけでもないので、必要に応じて少しずつ拡張していく予定です。

あとがき

DLsite Playはかなり素敵な同人作品ビューアです。しかし、DLsiteの外側を見てくれません。他にもたくさんの同人作品ビューアがあります。しかし、それぞれ異なる欠点を抱えていました。結局のところ、全てを解決できる選択肢はないようです。Claudeにこのトレードオフについて相談してみましたが、「画像ビューアと音声ビューアを別々に立てて使うといいよ☆」なんて無茶な提案でお茶を濁してきます。なんてこった。

そのため、今回は同人作品ビューアとして最も参考になるDLsite Playの機能面を掘り下げ、類似の既存アプリを調査した上で自作することにしました。自作に至るまでの過程は地味で苦しいものです――あれを入れてこれを入れて動かしたけど、結局ダメそう。設定とかカスタマイズの範囲でなんとかならないかな？　いろいろ試したけどやっぱ無理――じゃあ、自作しかないか。

希望を満たすものがなければオーダーメイドで作るというのは、ソフトウェア以外でも当たり前の選択肢です。ただし、これも手間と機能のトレードオフになっています。AIエージェントを使えば時間や手間を大きく削減できるとはいえ、実装の責任はやはり自分にあります。実験的なプロジェクトや趣味のプログラミングでもない限り、自作せずに済むなら自作せずに完成度の高い既存のものを使う方が、楽だし安全だし経済的です。

AIエージェントの発展で、技術的詳細をまるで気にすることなく「あれと同じの作って」「最強の◯◯アプリ作って」なんて一言指示すれば、誰でもそれっぽい見た目のそれっぽいアプリができるようになりました。さらに、それを「オレが設計して作ったんだぜ」なんて自慢して回りたくなる誘惑も増しています。なんてったって見た目はすごくいいし、機能も全部盛りだからです。

しかし、要件も曖昧なままなんとなく便利機能をリストアップして作られた見た目だけのアプリケーションは、周囲はもちろん作った本人でさえ魅力を感じないはずです。本人に残っているのはAIガチャを引く高揚感の思い出だけ。ただの習作のTODOアプリが誰にも使われないのと同じように、AIガチャから得た興奮に利便性を見出す人はいません。

既存アプリを調査してまだないものを作る、なんてソフトウェア開発では当たり前のように思えますが、AIエージェントを持った高揚感で全て自作で解決する選択肢しか見えなくなる人も増えています。もちろん、自作の全てが悪いわけではないですが、出来のいい先行研究を知らないとまともな結果が出せないというのは、AIがあろうがなかろうが同じことです。

その取り組みの一例として、今回は欲しいものの概念を粘土のようにこね上げてから、最終的に自作の同人作品ビューアを選んだ過程について書いてみました。参考になれば幸いです。

DLsite、電子書籍や音声／音楽作品を視聴できるWebブラウザビューワ「DLsite Play」を提供開始 | HON.jp News Blog ↩
販売終了作品もDRMさえなければZIPファイルとして手元に残すことはできますが、手軽なビューアに比べて検索が面倒だし開くのも手間がかかります。すぐに手を伸ばせる本棚ではなく、押し入れの段ボールに保管されているイメージで「ZIP」の「倉庫」と表現しました。 ↩
Windowsにおけるエクスプローラ、macOSにおけるFinderなど。ファイラー。 ↩
スマートフォン向けにはアプリとしてDL Library（画像・PDF・テキスト作品向け）やDLsite Sound（音声作品向け）も提供されています。 ↩
Rust製のウェブアプリケーションフレームワーク。今回はAPIサーバとして使用しました。 ↩
柔軟性があり高速なコンポーネントフレームワークのSvelteを使って構築されたフロントエンドフレームワーク。 ↩
Rust製のデスクトップ/モバイルアプリケーションフレームワーク。今回はモバイルアプリは対象外です。 ↩

ははいぬ・けつあつ・くちかせ――日本語のhuman-readable nameを考える

2026-03-09T23:44:00+09:00

docker run ...
dd if=/dev/random ...
ssh-keygen -lv ...
shuf -n 3 words...
logout ...

`docker run ...`

Dockerでコンテナを起動するとき、 --name を与えないとランダムな英単語の組み合わせで名前が付くことはよく知られています。これはコンテナIDやUUIDのような完全にランダムな16進数ではなく、人間でも読みやすく見分けやすいIDを与える仕組みです。

$ docker run hello-world

Hello from Docker!
...

$ docker ps -a --format "table {{.ID}} {{.Names}}"
CONTAINER ID NAMES
f194dc6f87b5 wonderful_kowalevski
ff656b2992d0 kind_chaplygin
130258500f29 festive_nash
5bcc03f329fe clever_bardeen
977e200749ca hopeful_moore

この名前の生成ロジックは、namesgeneratorというパッケージで提供されています。ハードコードされた形容詞（108個）と著名人の姓（236個）から（非暗号論的な）乱数を元に1つずつ選び、 _ で接続するというシンプルな実装です。

ちなみに、このパッケージはもともと外部参照可能なpkgにあったのですが、Freeze the namesgenerator package against new additionsというPRをきっかけに単語リストが凍結されて、最終的に内部専用のinternalに移動しました。これらの単語リストのスラング的な意味合いや人物リストの評価で物議を醸す事態が長年にわたって続いており、メンテナンスの負担が高くなったことが主な理由だと、同PRや古いnamesgeneratorパッケージの説明に記されています。

`dd if=/dev/random ...`

さて、このような人間可読で（本来は）意味を持たない単語の組み合わせをhuman-readable nameと呼ぶことにしましょう。human-readable nameの決定には、以下の要素が必要です。

1種類以上の空でない単語リスト（例: 形容詞のリストと著名人の姓のリスト）
単語を結合する文字（例: _）
各単語リストから単語を取り出す1つ以上の位置

このうち、単語リストのインデックスを取り出す方法には大きく分けて2つあります。まずはDockerと同じく乱数プールから取り出したランダムなインデックス、もう1つは対象のデータに基づく決定的な手法です。

たとえば、あるIDと数値を持つオブジェクトにhuman-readable nameを付けるとき、JSON表現が {"key":"answer","value":42} なら必ず brilliant_jerk という名前にすることもできます。単純な実装では、SHA-256をとって前半と後半のバイトの剰余を取れば、決定的なインデックスを得られるでしょう。

human-readable nameから元のオブジェクトを計算できるわけではないので、役に立つシーンはそう多くなさそうですが、人間がバイト列の一致を視覚的に見分けるための表現としてはとても役に立ちます。

`ssh-keygen -lv ...`

実際のところ、human-readableといわれる名前は全ての地域や文化圏に共通の概念ではありません。冒頭のDocker出力例にあった kowalevski を一目でソフィア・コワレフスカヤのことだと理解するのは多くの日本人には難しく、これなら「不思議なソフィア」なんて文字列の方が読みやすく覚えやすいはずです。

もちろん、このような名前はASCII文字で構成するのがある種の暗黙的了解であり、human-readable nameが登場しうるほとんどの場所で安全に使えることは重要な利点です。しかし、もともとhuman-readable nameは人間が触れるインターフェースを構成する代替手段のはずでした。世界をUnicodeが支配した今となっては、既に多くの環境で問題なく扱えるとみなしても問題ないでしょう。

このようなIDの代替表現という目的をさらに広く捉えると、ASCII文字の単語の組み合わせに限らず、バイト列をさらに読みやすく置き換える表現を活用している例はたくさんあります。

秘匿性の高い通信アプリSignalにおいて、お互いに意図した相手と通信しているかを示すSafety Numbersは、16進数のハッシュを60桁の数字で表現して一致を確認しやすくする仕組みです。

OpenSSHで公開鍵のフィンガープリントを示す際に使われる二次元的なパターンも、randomartと呼ばれるhuman-readableな表現です。

+--[ED25519 256]--+
|.oB+*o..         |
| =+B *o. .       |
| .= o.+.. .      |
|   o.... .       |
|  . =o..S        |
|   +.o*.         |
| .   +o+         |
|  ooEoo          |
|+**+.o.          |
+----[SHA256]-----+

分散型の通信プロトコロルのMatrixでは、Signalと同様のMITM対策の検証としてSAS（Short Authentication String）が導入されており、対応しているクライアントでは事前に定義された64個の絵文字の組み合わせで一致を確認できます。数字の羅列よりもさらに人間の視覚に合わせた仕組みだと言えるでしょう。

認証の分野から離れると、what3wordsもhuman-readableな表現の重要な実装のひとつです。このサービスは、3メートル四方に区切った地図の各領域に3つの単語を与えて、位置を共有できるようにしたものです。what3wordsの位置は /// というプレフィックスで始まり、たとえば「///りゅっく。かたづけ。しぶる」のように示します。同じ位置で複数の言語にマッピングされており、英語では「///grocers.powerful.wanted」、韓国語では「///황태.늦잠.배우자」、クメール語では「///សេីច.ជាថ្មី.ត្រឹមតែ」というように、Dockerの名前生成が抱えていた文化的・言語的問題をある程度解決しています。

`shuf -n 3 words...`

さて、これらの多様なhuman-readable表現を参考に、改めて日本語のhuman-readable nameについて考えましょう。必要なのは以下の要素でした。

1種類以上の空でない単語リスト
単語を結合する文字

結合文字は ・ や 、 がいいでしょう。「ははいぬ・けつあつ・くちかせ」のような感じですね。日本語ならスペースでも見栄えはいいですが、シェルやクエリで使うにはあまりに区切り文字としての意味が強すぎます。

ここまで決めれば、あとは入れ替え可能な単語リストを用意してリポジトリに含めるだけです。たとえば、単語リストが1種類なら以下でhuman-readable nameを生成できます。

$ shuf -n 3 path/to/words.txt | paste -sd '_' | sed -e 's/_/・/g'
ははいぬ・けつあつ・くちかせ

というわけで、最後に日本語の単語リストを決めましょう。この単語がhuman-readable nameの印象を大きく変えるので、丁寧に検討する必要があります。

user: ランダムな人間向けのIDを生成するのに向いた日本語の単語リストって、どこかで配布されてる？
assistant: 日本語だと...正直、ちゃんと整備された「日本語IDジェネレーター向けワードリスト」って意外と少ないんだよね😅

……えーっと、どうやって集めますか？

Dockerレベルのランダム生成で25000パターンくらいなので、2つの組み合わせなら160単語くらい必要です。でも、3つ取り出すなら30単語くらいあれば足りるでしょう。30単語を3種類用意しても90単語なので、実はあまり難しいものではありません。

ただし、過去に使ったhuman-readable nameをずっと保持する設計であれば、かなり心許ないパターン数になります。

① 赤い・青い・黄色い・きりん・ぞう...

思い付いた単語を順番に書いていくんですね！　30単語くらいなら自分で書き出したり、AIに頼むのも現実的です。

大きな
小さな
長くて
短くて
高くて
...

sample-adjective30-1.txt

大きい
小さい
長い
短い
高い
...

sample-adjective30-2.txt

犬
猫
うさぎ
ハムスター
リス
...

sample-noun30.txt

この3つを順番に並べると、こういうほのぼのコミカルなhuman-readable nameが得られます。

$ for x in $(seq 1 10); do bash -c 'shuf -n 1 sample-adjective30-1.txt; shuf -n 1 sample-adjective30-2.txt; shuf -n 1 sample-noun30.txt' | paste -sd ''; done
甘くて辛いゾウ
小さな硬いクジラ
強くて軽いリス
低くて多いシマウマ
軽くて大きい犬
重くて重いトラ
遅くて速いシマウマ
弱くて暗いサイ
明るくて柔らかいトラ
硬くて多いオオカミ

② `cat core_lex.csv ...`

辞書から単語を取り出すんですね！　こういうスクリプトでSudachi辞書から名詞や形容詞の読み仮名を取り出して、いい感じの長さの単語だけ残すと13000語くらいのひらがなを取り出せます。3つの組み合わせなら2.2兆パターンくらい使えるので、uint32で不安にならないシステムなら十分でしょう。

あいい
あいうえお
あいうち
あいお
あいか
...

sudachi-dict-hiragana-words.txt

こっちはフラットな印象のhuman-readable nameになります。

$ for x in $(seq 1 10); do shuf -n 3 sudachi-dict-hiragana-words.txt | paste -sd '_' | sed -e 's/_/・/g'; done
からたけ・おおめ・にんめん
ありったけ・せんれん・きへき
ふはつ・おりかた・いやふき
ふしのき・きほん・たっす
さくれつ・こくおう・あまちゃ
きわもの・いとよ・けいゆ
もうへい・そせい・ふみあと
きおく・さいのめ・あせかき
ふえん・ちんろん・とんか
しかい・むおん・いっく

③ さやか・ほむら・りんこ・まなか・かえで...

好きなキャラクターの名前ですか！　覚えやすくていいですね。100人くらいすぐに出てきそうですし、並べるとカップリングみたいに見えるのもいいところです。150人なら23000パターンくらいで、Docker程度のランダム性を確保できます。

あかり
ひなた
さくら
みずき
ことね
...

sample-charactors.txt

ゲームやアニメの登場人物一覧データは、だいたい有志のwikiにはよくまとまっているのですが、機械的に処理しやすいCSVやスプレッドシートなどはそう多くない印象でした。ポケモンの名前がJSONにまとまっているNode.jsライブラリpokemonはあったので、ここから取り出してもいいでしょう。

こっちは想像力が鍛えられるかもしれないhuman-readable nameになります。

$ for x in $(seq 1 10); do shuf -n 2 sample-charactors.txt | paste -sd '_' | sed -e 's/_/・/g'; done
あやね・のぞみ・なぎ
いちか・ちさと・なのか
みお・あやね・らん
らん・れん・かなで
ことね・すず・このは
なぎ・そら・かすみ
あかり・いちか・ゆい
きらら・ことね・りりか
みれい・ほのか・えみ
しずく・ももか・ちひろ

`logout ...`

ランダムなhuman-readable nameの生成自体は、掘り下げる余地もないシンプルな実装です。一方で、そのロジックに与える単語リストにはまだ検討の余地があります。

最近、自作のAIエージェントセッション管理システムでランダムな日本語のIDを生成しようとしたところ、使いやすい単語リストの用意になかなか手間取ってしまったので、振り返りとしてこの記事を書きました。

あなたが秘蔵している使いやすいフォーマットの日本語リストがありましたら、ぜひ私にも教えてください。

WScript . ShellからStart-Processへ（一敗と、さらにその後）

2026-02-25T17:05:00+09:00

Windowsでウィンドウを一切表示せずにバックグラウンドで実行してほしいスタートアッププログラムがあるとき、VBScriptで以下のスクリプトを用意しておくと便利ですね。

Set ws = CreateObject("WScript.Shell")
ws.run "WRITE YOUR COMMAND HERE", vbhide

これを startup-your-brain.vbs として保存して、スタートアップフォルダ¹にショートカットを置くと、次回起動時から指定したプログラムが起動します。画面には変化がありませんが、タスクマネージャーから見ると起動しているのが確認できるかもしれません。

ws.run がプログラムを実行するメソッドで、 vbhide オプションによってウィンドウが作られなくなるようです。与えたプログラムがジョブの完了と共に終了するものならプロセスは残りませんし、バックグラウンドで何かを実行するプログラムならずっと待機してくれます。

VBScript（Microsoft Visual Basic Scripting Edition）は、1996年からJScriptと共にブラウザでの処理を目的に搭載されたスクリプト言語です。これがWindows上で動作するスクリプトエンジンWSH（Windows Script Host）で動作する汎用スクリプト言語として採用され、今回のようなバッググラウンドでのスタートアップに使えるようになりました。

しかし、Windowsの普及初期から長い歴史が続くVBScriptは、Visual BasicやVBA（Visual Basic for Applications）に比べて言語としての表現力が低く、使いにくい点も多いです。また、2024年頃にはVBScriptを中長期的に廃止する計画が発表されており²、2027年にはデフォルトでインストールされなくなると明言されています。

Windows上で動作する汎用スクリプトとしてのVBScriptの代替は、既にPowerShellが担っています。PowerShellは2003年頃からWSHの代替として開発された新世代のシェルであり、現在は主にPowerShell 5.1とPowerShell 7.xが利用できます。スクリプトファイルの拡張子は *.ps1 です。

さて、冒頭のバッググラウンドでのスタートアップをPowerShellで書くにはどうしたらいいでしょうか？　調べてみると、以下のような感じになりそうです。

Start-Process -FilePath "COMMAND" -ArgumentList "-y our --argument list" -WindowStyle Hidden

では、保存した startup-your-brain.ps1 を実行してみましょう。

……あれ、ダブルクリックしても実行できませんね。コンテキストメニューに「PowerShell で実行」があります。いったん試してみましょうか。

このシステムではスクリプトの実行が無効になっているため、ファイル startup-your-brain.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://go.microsoft.com/fwlink/?LinkID=135170) を参照してください。
    + CategoryInfo          : セキュリティ エラー: (: ) []、ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnauthorizedAccess

コンソールアプリ特有の黒い画面が表示され、こんなエラーが赤文字で出てきました。なんだか怖いですね。特に実行ポリシーを触ったことはなかったのですが、今は「Restricted」になっています。このポリシーでは、PowerShell上でコマンドを実行できても、スクリプトを起点にした実行はできないようです。WSHに隠れてマルウェアが爆増した歴史を踏まえれば、セキュリティ上当然の対策かもしれませんが、ちょっと不便ですね。

では、ショートカットでPowerShellを経由してスクリプトを呼ぶ作戦に切り替えてみましょう。一時的にポリシーを「RemoteSigned」にゆるめるオプションを与えたショートカットを作り、ローカルのスクリプトを実行できるようにします。

powershell -ExecutionPolicy RemoteSigned -File "startup-your-brain.ps1"

……おっ、動いていそうです！　しかし、黒いウィンドウが一瞬表示されてしまいました。これでは「ウィンドウを一切表示せずにバックグラウンドで実行」とはなりません。

では、PowerShellのポリシー自体をゆるくしたらどうでしょう？　一時的な実験として、実行ポリシーを「RemoteSigned」にしてみます。

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies
のヘルプ トピック (https://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): y

この状態で、もう一度 startup-your-brain.ps1 を「PowerShell で実行」してみます。

このポリシーならスクリプト単体で動きましたが、やはり黒いウィンドウが表示されてしまいました。どうも、PowerShell単体では黒いウィンドウは抑制できないように見えます。コンソールアプリだからでしょうか？

PowerShell -WindowStyle Hidden -Command Exit と足すといい、という情報もかなり流通していて試しましたが、動作はほぼ変わりませんでした。調べた感じでは、おそらくタスクスケジューラに登録しても変わらないみたいです。確かに、過去にバッチファイル（コマンドプロンプト）でいろいろな回避策を試して上手くいかなかった末にVBScript経由で起動しているわけなので、問題が逆戻りしただけという気がします。

……なるほど。つまり、現時点ではVBScriptからPowerShellに移行するメリットはなさそうです。2027年になってもインストールすればまだまだVBScriptは使えるので、急いで移行しなくても大丈夫かもしれません。

うーん。与えられたプログラムを起動するだけの透明なGUIツールがほしいだけなのに――あれ？　これ、さっさと作っちゃった方が早い気がしますね。C#とかはビルド環境を整えるのが面倒そうなので、Goでやってみましょうか。

package main

import (
    "os"
    "os/exec"
    "syscall"
)

func main() {
    if len(os.Args) < 2 {
        return
    }
    cmd := exec.Command(os.Args[1], os.Args[2:]...)
    cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true}
    cmd.Start()
}

これだけシンプルなら、脆弱性が入り込む余地もないでしょう。マルウェアの隠れ蓑にはなるかもしれませんが……まぁ、これくらいツールキットなら同梱されているレベルのものです。では、Windows向けにビルドしてみますね。

GOOS=windows GOARCH=amd64 go build -ldflags "-H=windowsgui" -o silent.exe main.go

-ldflags="-H windowsgui" でGUIアプリとしてビルドします。

これで、VBScriptから本当に欲しい機能だけを抜き出したシンプルなツールの完成です。もしGoのビルド環境はないけど使ってみたい、かつ私を信頼できる方はビルド済みの silent.exe を差し上げますのでお使いください。

では、早速使ってみましょう！　これならショートカット方式で呼び出せるはずです。以下のようなショートカットを作ります。

silent.exe COMMAND -y our --argument list

ダブルクリックで起動すると、無事に「ウィンドウを一切表示せずにバックグラウンドで実行」できるはずです！　これでもう、VBScriptが明日いきなり消えてしまっても安心ですね。

しかし、VBScript（ *.vbs ）とJScript（ *.js ）のスクリプトファイルのアイコンが消えてしまうのは少し寂しい気持ちもあります。VBScriptは水色の巻物が、JScriptは黄色い巻物が広げられたかわいいアイコンが使われているんですよ。知っていましたか？

一方でPowerShellのアイコンは、プロンプト³をモチーフにしたクールでシンプルなデザインです。もちろん、高機能でモダンなスクリプトエンジンに切り替えるのは、利便性の向上やセキュリティ面でも非常に重要なことでしょう。それでも、時代遅れのWSHと一緒にこうしたレトロなセンスまで消滅してしまうのは、なかなか惜しいものだと思ってしまいます。

エクスプローラで shell:startup と入力して移動するのが速いです。 ↩
VBScript deprecation: Timelines and next steps | Windows IT Pro Blog ↩
近年でいうところのエーアイに与える命令ではなく、ユーザが入力可能なことを示すUIとしての文字列（ > $ # など）のこと。 ↩

「条件を対等にするだけ。許可を」「よし、やっちまえ！」の裏側

2026-02-25T07:54:00+09:00

Google CloudにはPAM: Privileged Access Managerという仕組みがあります。事前にどのアカウント（プリンシパル）がどんな権限（ロール）を持つかという資格（エンタイトルメント）を定義し、アカウントが必要なタイミングで承認を受けると一定時間そのロールを獲得できます。音楽係の生徒が授業のときだけ音楽室の鍵を借りるとか、そういうイメージです。

AzureにおいてはPIM: Privileged Identity Managementが該当します。AWSにおけるIAM Identity Centerは標準機能の範囲では少し弱く、アクセス期間や対象の厳密な制御には別の管理ツールと連携する必要があるようです。今回は主にGoogle Cloudで話を進めていきます。

さて、OpenClawなどのオモシロ自律型AIエージェントが流行る中で、セキュリティにどのように気を配っていくかという目線がますます重要になっています。変なプロンプトは入れない、変なプラグインは入れない、不用意にアタックサーフェスを晒さない……ある程度慣れていれば当たり前のことですが、エーアイ？で初めてコンピュータに触った人もいるのでしょう。

Androidに詳しいユーザーなら誰もがESファイルエクスプローラーをインストールしていた時代だって、たった十数年前です。これからも、まだまだたくさんのことが起こりますからね。

みなさんは、このような自律型AIエージェントに与えるべき権限について、細かく考えたことはありますか？　なんでもできる方が便利ですが、なんでもやらせるのはとっても危険です。おそらく権限と便利さは逆U字のグラフを描くでしょう。

でも、もうなんでも開発を任せちゃってるし、デプロイだってさっさとやってほしいよ……と考えてしまうのは自然なことです。あなたはAIエージェント「スーパーAI太郎」と相談して、かれが使うサービスアカウント super-ai-kun@bullshit-job.iam.gserviceaccount.com に「Cloud Run 管理者」を与えました。別に「オーナー」権限でもよかったんですが、スーパーAI太郎が絶対にやめろと言って聞かなかったのです。

AI太郎がgcloudコマンドを呼んだみたいです……エラーなし。いいですね。これでちょっとしたウェブサービスならすぐリリースできます。Xにも自動で告知させた方がいいでしょう。……はい？　IAMの条件、って？　よく分かりませんが、「（省略可）」なので空っぽでOKです。スーパーAI太郎も何も言っていませんでしたし。

AI太郎が初めてのデプロイを済ませたみたいです。うーん最高。今日はとっても儲かったね。明日はもっと儲けられるよ。ね、AI太郎！　私は寝てるから、よろしく～。

数日後、AI太郎はあなたの言うとおりたくさんのコンテナをデプロイし、大量の暗号通貨をマイニングしてくれました。あれ？　それなのにAI太郎のウォレットが空っぽじゃないですか。なぁジョージ、私の財布をどこにやったんだ？

――――――

――――

――うーん……夢か。

もし寝ている間の逸失利益を気にしないなら、あなたのゴーサインを待ってからデプロイしてもらう方がかなり健全でしょう。でも、あなたがAI太郎に「Cloud Run 管理者」ロールを無条件に与えた時点で、ミサイルの発射ボタンは常に押しっぱなしになり、あなたの抱えるべき責任は青天井になったのです。こんなのよほどの責任フィリアか、押しボタンジャンキーでなければ耐えられません。

じゃあ、この発射ボタンを自分のタイミングで押せないものか……せめて押しっぱなしにならないボタンにできない？　ねぇAI太郎、どう思う？

【AI太郎】いい着眼点ですね！　自律型AIエージェントに与える権限について細かく考えるには、まさに今のような疑問が重要です。

今回のようなユースケースでは、Google CloudのPAMがおすすめです。ここで、PAMができることを整理しましょう。PrivilegedなAccessのManagerという名前の通り、こんなことができるみたいです:¹

権限昇格を許すプリンシパルとロールの組み合わせ（entitlement）を事前に定義できます。
権限昇格のリクエストに対して、正当な理由を記述するよう要求できます。
承認ボタンひとつで、事前に決めた最大期間より短い期間の一時的な権限昇格を許可できます。
取消ボタンひとつで、許可した権限昇格を有効期限を迎える前に取り消すことができます。
権限の得喪の履歴については、問題が起きた後でも監査ログで確認できます。

ちょっとやってみましょう！　まずはentitlementを作れるアカウント――プロジェクトを作ったあなたがやるのが楽ですね――から以下を実行します。大文字の箇所は自分の環境に合わせて適宜変えてください:

approvalWorkflow:
  manualApprovals:
    steps:
    - approvalsNeeded: 1
      approvers:
      - principals:
        - "user:OWNER_ACCOUNT@example.com"
eligibleUsers:
- principals:
  - "serviceAccount:SERVICE_ACCOUNT_LOCALPART@PROJECT_ID.iam.gserviceaccount.com"
maxRequestDuration: 1800s
privilegedAccess:
  gcpIamAccess:
    resource: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
    resourceType: cloudresourcemanager.googleapis.com/Project
    roleBindings:
    - role: roles/run.developer
requesterJustificationConfig:
  unstructured: {}

$ cat <<EOS > entitlement.yml
*（上記の内容）*
EOS
$ gcloud beta pam entitlements create YOUR-NEW-entitlement \
    --project="PROJECT_ID" \
    --location="global" \
    --entitlement-file=entitlement.yml

正常にentitlementが作成できたら、今度はAI太郎のシェルを借りて以下を実行しましょう:

# 実際にはAI太郎が自分で承認をリクエストします
gcloud beta pam grants create \
    --entitlement="YOUR-NEW-entitlement" \
    --location="global" \
    --project="PROJECT_ID" \
    --requested-duration="1800s" \
    --justification="条件を対等にするだけ。許可を。"

すると、あなたに権限昇格の確認を求めるメールが届き、そのリンクをブラウザで開くとこんな承認画面が表示されます:

どうですか？　これで、せっかく掘り出した暗号通貨のウォレットを失わずに済みそうです。他にも、チーターが蔓延るゲームに怒ったAI太郎が修正を施すための権限昇格を要求する仕組みを整えることもできます。あなたが「よし、やっちまえ！」なんて承認するだけで、全てが好転していくことが約束されました。

他にはどんなことに使えるでしょうか。ねぇAI太郎、どう思う？

【AI太郎】はい、鋭い視点です！　こんなことに役立つかもしれません:

クラウド上の機密情報や重要なデータを分析してレポートを作ってほしいとき。自分がリクエストしたときだけ承認がリクエストされるので、あなたがデスクに座ってAI太郎を監視できるタイミングのみアクセスを許すことができます。意図しない、検知できない情報流出をごく簡単な操作で防げます。
要らないサービスやストレージの削除をAI太郎に任せるとき。自律的にサービスを監視して、不要なコンテナの削除やオーバースペックなサーバの調整をリクエストしてもらえば、安全にコストを削減できます。なんでもかんでも消されないように、IAMの条件で削除候補を絞りやすい設計にした方がいいでしょう。
AI太郎に自分のウェブサービスのアカウントを渡して、許可に応じて一時的に使ってほしいとき。たとえば、重要なアカウントを格納したKeePassのパスフレーズをSecret Managerに入れておくと、KeePassへのアクセスを実質的に監査できます。ただし、使ったパスワードが会話履歴に残ったりするとあんまり意味ないかもしれません。

自動化したプリンシパルに一時的な権限を与える手法は、一日中パソコンの中を歩き回ったり、とんでもないポカをしでかそうとする自律型AIエージェントを監視しきれないケースで非常に役に立ちます。AI太郎が「あのー、大量にMoneroを掘って送金したいんで許可ください」なんて素直に言ってくれるかは分かりませんが、少なくとも発射ボタンくらいは人間の責任で押したいものです。

……あれ？　なんか、記事を書いている間にいっぱい承認リクエスト来てましたね。たぶん大丈夫なのでまとめてオッケーしておきます。ではまた。

コードブロックや箇条書き前のコロンをAIっぽいと嫌う人が多いみたいですが、これは普通にカッコいいので使った方がいいです。 ↩

example . comのデザインが変わってた

2026-01-23T18:00:00+09:00

example.comのデザインがいつの間にか変わっていたので、調べたことをまとめておきます。調べましたが、特別な理由はなさそうです。

example.comには、これまで以下のような文言が表示されていました。

Example Domain
This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.
More information...¹
2025年10月10日以前のexample.comの文言

お気付きの方もいるでしょうが、この文言はあまねけ！のページ下部に表示されている「More information...」というリンクの元ネタです。

さて、Wayback Machine上でこのデザインが確認できる最後の時刻は2025年10月10日 1:30（JST）頃です。これが以下の新たな文言とフラットなデザインに変わったのは2025年10月10日 2:44（JST）頃でした。おそらく2025年10月10日 2:00（JST）――2025年10月9日 17:00（UTC）――頃に入れ替わったようです。

Example Domain
This domain is for use in documentation examples without needing permission. Avoid use in operations.
Learn more²
2025年10月10日以降のexample.comの文言

これに関してはいくつか言及しているスレッドがありましたが、公式発表は見つかりませんでした。

ただ、2025年までずっと同じ内容だったというわけではなく、2019年10月17日³以前は余白とフォントが異なるカードデザインで、文言もわずかに変わっています。

Example Domain
This domain is established to be used for illustrative examples in documents. You may use this domain in examples without prior coordination or asking for permission.
More information...¹
2019年10月17日以前のexample.comの文言

さらに遡ると、2013年7月31日以前⁴は example.iana.org にリダイレクトしていました。ただし、リダイレクトされるだけで文言は変わっていません。

もう一段階遡ってみます。2013年4月26日以前⁵は、 http://www.iana.org/domains/example/ にリダイレクトしていました。ここでは、文言がわずかに変わっています。

Example Domain
This domain is established to be used for illustrative examples in documents. You do not need to coordinate or ask for permission to use this domain in examples, and it is not available for registration.
More information...⁶
2013年4月26日以前のexample.comの文言

最後にもう一回遡ります。2012年12月7日以前⁷は、ここまでのカードデザインとは全く異なるIANA内の説明ページが表示されていました。

これよりさらに前は、記録に残っている限りでは2002年の3月頃から2011年2月頃まで、RFC 2606を参照するごくシンプルなテキストが表示されていたようです。

改めて表にまとめます:

from	to	期間	デザイン
2002年3月頃	2011年2月頃	9年間	シンプルテキスト
2011年2月頃	2012年12月7日	1.8年間	IANA内の説明ページ
2012年12月7日	2013年4月26日	0.5年間	カード①
2013年4月26日	2019年10月17日	5.5年間	カード②
2019年10月17日	2025年10月10日	6年間	カード③
2025年10月10日	-	-	フラット①

こう見ると、example.comの内容が更新されるのはそう珍しい事象ではなく、数年単位でわずかな変更が加えられていることが分かります。ただ、これまで累計13年間も使ってきたカードデザインがフラットに一新され、「More information...」というリンクも消えてしまったのは、個人的には大きな変化だと感じます。

あまねけ！も「Learn more」リンクに変えようかなと思いましたが、どうにもしっくりこないのでやめました。たぶん「More information...」の後ろにある「...」がかなり好きですね。

ちなみに、トップページにある:

これは個人サイト初期の時代には誰も書こうとは考えなかった、日々拡大を続ける個人サイト記事集です。
今のところ、以下の記事を含みます:

は、moreutilsのDebianパッケージでの説明が元ネタです。moreutilsは特定のシーンでよく刺さる便利なコマンド集です。また、SNSの自己紹介で使っている:

これは百合初期の時代には誰も書こうとは考えなかった、日々拡大を続ける百合ツール集です。

も同じオマージュです。こっちは変わらないといいな。

https://www.iana.org/domains/example ↩↩
https://iana.org/domains/example ↩
20191017113820 ～ 20191017114755 ↩
20130730173856 ～ 20130730195154 ↩
20130425153504 ～ 20130425164946 ↩
http://www.iana.org/domains/special ↩
20121206161753 ～ 20121206195447 ↩

マイクロなGIFアニメバナーを目指して

2026-01-22T19:14:00+09:00

2026年6月6日開催予定の個人サイトWebオンリーめぐる市へ参加することになりました。それに合わせた 個人サイトっぽい 取り組みの一環として、今回はあまねけ！を宣伝するGIFアニメのマイクロバナーを作ったので、気付いた点をいくつかまとめておきます。

マイクロなGIFアニメバナーって何？
マイクロなGIFアニメバナーを作る
マイクロなGIFアニメバナーを使う
まとめ

マイクロなGIFアニメバナーって何？

そうですね。この質問は、「マイクロバナーって何？」と「GIFアニメバナーって何？」2つに分解することができます！

まず、マイクロバナーというのは、幅88ピクセル・高さ31ピクセルのごく小さな画像です。バナーというのは旗印とか横断幕という意味で、ウェブの領域では主に広告や宣伝のための中～小サイズの画像を指しています。この中途半端なサイズの起源は、かつてあったブラウザ「Netscape Navigator」のプロモーション「Netscape Now Program」で配られたバナーのサイズだと言われていますね。

ウェブ広告の業界団体IABが2007年頃に標準化したバナーサイズの一覧には、このNetscape Now Programから始まるバナーリンクの爆発的なブームを考慮したのか、88x31のサイズが「Micro Bar」として含まれています（Micro Bannerじゃないんだ）。

次に、GIFアニメバナーというのは、10～30fpsくらいでアニメーションするバナーのことです。バナーリンクのブーム当時には、手軽にアニメーションを扱える画像形式がGIFくらいしかなかったので、この記事ではあえてアニメバナーではなくGIFアニメバナーと呼んでいます。バナー収集サイトThe 88x31 GIF Collectionにあるのも、GIFばかりです。

もちろん、今は2026年なのでWebPやAPNGといったより高品質で効率のよい画像形式でアニメーションを利用できます。今からアニメバナーを作るならこれらの形式もおすすめです。一方で、GIFの色数制限（256色）を逆手に取ればレトロな雰囲気も作り出せるので、制作段階で減色するなり、GIFアニメ生成ツールが吐いたGIFを再度変換するのもよい考えです。

モダンな画像形式を使いつつGIFの気配を残した表現を「GIFアニメ」と呼び続けるのも悪くないでしょう。きっと。

マイクロなGIFアニメバナーを作る

今回作ったバナーは冒頭に掲載したものです。もう一度貼っておきます。

ここからは、この音ゲーあまねちゃんバナーをどのように作ったか概要を説明します。バナーの作り方は人それぞれだと思いますし、私は普段絵を描いたり動画を作ったりするタイプではないので、この手順はあまりよい例にはならないはずです。面倒なところをかなりhackyに済ませたので、参考程度にどうぞ。

画像素材を作る

88x31そのものや、それに収める前提のサイズ（小さなパーツ、あるいはスクロール用の長い画像）の画像素材を作ります。GIMPを使いましたが、透明度のあるビットマップを編集できるペイント系ソフトなら何でもいいです。

キャンバス全体に配置する素材:

アニメーションの一部に使う素材:

昔ドット絵を描いたときはGIMPでレイヤーを付け外しして1枚ずつ出力していましたが、ごく小規模なアニメを超えると現実的な作業ではなくなるので、動きは動画編集ソフトで与えていきます。

動画を作る

今回は、ゆっくりMovieMaker4を使いました。本来は実況動画などを作るソフトであり、GIFアニメの制作に使う必然性は全くありません。1ヶ月前にひみつ道具「世界修正時計」で使ったので少し慣れているというだけです。

まともな動画編集の経験は、高校の文化祭で作ったCMか大学生の時に文化祭で作ったCMくらいで（CMばっかりだ）、当時はAviUtlを使っていました。だから、なんとなくAviUtlっぽく触れるなら何でもよかったのです。Premiere Proとかなら楽なのかな？

YMM4での編集では、わずかに問題がありました。奇数の幅・高さのプロジェクトが作れないのです。高さ31ピクセルにはできないので、88x32にして出力後に削るか、倍の大きさ（176x62）で作ってあとで縮小する必要があります。倍の大きさで作ると奇数座標の配置で最終的な出力がボケますし、アニメーションなどの映像効果資源もよく注意しないと使えないので、やるなら88x32で作るのがおすすめです。

この場合、下部1ピクセルの行はマゼンタなど目立つ色で埋めておきましょう。これなら削り忘れても気付きやすいです。

あと、プレビューエリアを大きくすると表示がボケボケになって少し困ったので、また作るならこれもなんとかしたいところです。

動画の編集が完了したら、これらをPNG形式のフレームで書き出します。

出力フレームを削る

書き出した画像フレームは88x32なので、下を削って88x31にします。慣れているのでImageMagickを使いましたが、ここも自由にしてください。GUIで済む範囲のツールだと、XnConvertあたりがよさそうでした。

# 下部1ピクセルを削る（このコマンドは元のファイルを書き換えます）
mogrify -crop 88x31+0+0 +repage frames/*.png

もし88x31より大きなサイズ（ただし定数倍）で出力したい場合は、さらにここで拡大しておきます。一般的な画像編集ソフトの拡大機能や、mogrifyコマンドの -resize オプションなどを使うと、画像がボケボケになるので注意してください。ふつうはよかれと思ってバイリニアなりで綺麗に拡大しようとするので、これらの補間機能を無効にする必要があります。

# framesフォルダのフレーム画像を最近傍法で2倍に拡大してframes2xフォルダに書き出す
mkdir -p frames2x
mogrify -path frames2x -scale 200% frames/*.png

適切に拡大できていれば、以下のような出力になります。ピクセルは潰れません。

GIFアニメを生成する

できあがったフレーム画像の列をGIFアニメにまとめます。今回はたまに使っているgifskiで生成しました。もちろんここも何でもいいです。gifskiならWindowsとmacOS向けのGUIアプリ版もあるようなので、お気に入りのものがなければ使ってみてください。

# framesフォルダのフレーム画像を10fpsのGIFアニメに変換してanime.gifに書き出す
gifski -o anime.gif --fps 10 frames/*.png

こうして、音ゲーあまねちゃんバナーが作られました！

マイクロなGIFアニメバナーを使う

2026年にブラウザでごく小さな解像度の画像を表示する際は、いろいろと注意すべき点があります。

まず、スマートフォンやタブレット、あるいは高解像度のディスプレイを使っているPCユーザーの環境では、1CSSピクセル幅あたり1.5～3ドットで描画するのが一般的です。この場合、CSSピクセルでのサイズに対して、幅と高さの両方で1.5倍～3倍の大きさが必要です。

そのため、ブラウザでの画像表示サイズと実際の画像サイズが揃っていると、足りないドットを拡大で補おうとするのでボケた印象を与えてしまいます。

こんな感じですね:

この事象の解決方法は2つあります。1つは、大きな画像を用意して小さな幅で表示するパターンです。例えば、264x93（3倍）の画像を用意して、ブラウザでは幅88ピクセル・高さ31ピクセルとして表示します。srcsetを使えば、必要のない環境にまで大きなサイズの画像を配信せずに済みます。

<!-- 2x:1CSSピクセルあたり2ドットの環境にはbanner-2x.gifを、3xにはbanner-3x.gifを配信する -->
<img src="banner-1x.gif" srcset="banner-2x.gif 2x, banner-3x.gif 3x" width="88" alt="XXXへのリンク">

srcsetによる画像サイズの出し分けは汎用性が高い手法ですが、実は今回のバナーのようなケースではあまり利点がありません。ふつうは縮小画像から元の拡大画像を得るのは難しく、この部分に大きな画像を配信するメリットがあるわけです。しかし、ドット絵なら単純な補間で拡大画像が一意に定まるので、何枚もサイズの違う画像を作る必要性がありません。手間も容量も余分にかかってしまいます。

そのため、今回のケースでは image-rendering プロパティを使うのが最適解です。これは、もともと画像サイズとデバイスでの表示サイズが異なる場合の補間手法を指定できるもので、高解像度のディスプレイで足りないドットを拡大する際にも使われるようです。ここに pixelated を指定すると、最近傍法などのピクセルの見た目を維持できる手法で補間されます。これなら、88x31で配信したまま綺麗でパキッとしたピクセルを表示できますね。

.banner {
  image-rendering: pixelated;
}

表示はこんな感じ:

ちなみに、あまねけ！では、高解像度のディスプレイでバナーの表示が小さくなりすぎないように以下のようなスタイルも入れています。手元では、1dppxのディスプレイと2dppxのスマホで見たときの物理的なサイズがほぼ同じになりました。メディアクエリを加えれば、3dppxの環境は3倍表示にすることもできます。

@media (min-resolution: 1.5dppx) {
  .banner-88x31 {
    width: calc(88px * 2);
    height: calc(31px * 2);
  }
}

まとめ

マイクロなGIFアニメバナーをサイトに掲載する際のポイントをまとめます。

好きな動画編集ソフトで88x31のフレーム画像の列を出力して、gifskiなどのツールでGIFアニメにまとめます。
一般的な動画編集ソフトでは奇数の幅・高さを指定できません。88x32で作ってからXnConvertなどで一括変換します。
サイトに掲載する際は、CSSで image-rendering: pixelated; を指定して、デバイスでの表示がボケないようにします。

これを踏まえて、みなさんもぜひマイクロなGIFアニメバナーを作ってみましょう。他のいにしえの小さな画像規格に興味があれば、「X-Face compatibleなアイコンを目指して」も読んでみてください。個人サイトWebオンリーめぐる市もよろしくお願いします。

あまねけ！ - tech

あまねけ！おもしろCSS 7選

① シェア用テキストを選択しやすくする

② スマホでのみ電話番号をリンクとして表示する

③ ページ印刷時にURLも記載する

④ 強調したいテキストに圏点を表示する

⑤ ドット絵をパキッと拡大して表示する

⑥ CSSだけでクリックに応じてスタイルを切り替える

⑦ CSSだけでランダムっぽいパラメータを使う

おわりに

今日できる！「読みやすい小説本」を作る10個のチェックポイント

たった今データを失うかもしれない君に捧ぐ10個の質問

私は普通のデータしか置いてないから大丈夫だよね？

いま使ってるクラウドストレージは一切使うなってこと？

リスクを意識してクラウドストレージを使う、って具体的にはどういうこと？

BANされるかもしれないデータは暗号化すれば大丈夫だよね？

プライバシー重視のクラウドストレージってなんなの？

でも、プライバシー重視のクラウドストレージって高いでしょ？

クラウドストレージの移行って面倒じゃない？

プライバシー重視って言ってるけど完全に信頼していいの？

そう言ってるあんたはどんなクラウドストレージサービスを使ってるわけ？

で、私は結局今からどうすればいいんだっけ？

デスクトップに面白い文字を流そう

ここまでのあらすじ

LED News Ticker

LED AppBar

デスクトップに面白い文字を流そう

ニュースのフィードを流す

インターネットのフィードを流す

自分で用意したテキストをランダムに流す

SpotifyのNow Playingを流す

No Contextな文章を流す

これから……？

ぼくらの同人作品ビューア（概念）

まえがき

同人作品ビューアを考える

同人作品ビューアを探す

同人作品ビューアを作る

あとがき

ははいぬ・けつあつ・くちかせ――日本語のhuman-readable nameを考える

docker run ...

dd if=/dev/random ...

ssh-keygen -lv ...

shuf -n 3 words...

① 赤い・青い・黄色い・きりん・ぞう...

② cat core_lex.csv ...

③ さやか・ほむら・りんこ・まなか・かえで...

logout ...

WScript . ShellからStart-Processへ（一敗と、さらにその後）

「条件を対等にするだけ。許可を」「よし、やっちまえ！」の裏側

example . comのデザインが変わってた

マイクロなGIFアニメバナーを目指して

マイクロなGIFアニメバナーって何？

マイクロなGIFアニメバナーを作る

画像素材を作る

動画を作る

出力フレームを削る

GIFアニメを生成する

マイクロなGIFアニメバナーを使う

まとめ

`docker run ...`

`dd if=/dev/random ...`

`ssh-keygen -lv ...`

`shuf -n 3 words...`

② `cat core_lex.csv ...`

`logout ...`