2024-06-06
台湾地下鉄暴漢事件と勇者ヒンメルの魔法
台湾の地下鉄で刃物を持った男に立ち向かった青年の勇気ある行動と、そのインタビューが大きな話題となっている。青年は恐怖に直面しながらも、漫画・アニメ『葬送のフリーレン』の登場人物「勇者ヒンメル」を思い出し、「勇者ヒンメルならそうするだろう」と自分を奮い立たせたと語ったのだ。
中捷纏鬥1分鐘「度秒如年」 長髮哥的勇氣來自動畫「芙莉蓮」（聯合新聞網）
この「勇者ヒンメルなら〜」という台詞は、作中において、ヒンメルの仲間たちが行動の理由を問われたときに必ず口にする言葉である。人々の優しさや勇気、利他的な行動を説明する際に使われるものだ。
『葬送のフリーレン』は、勇者ヒンメルたちと共に魔王討伐の旅を終えたエルフのフリーレンが、仲間たちが老い、亡くなった後も長寿種がゆえに生き続け、彼らの想いが受け継がれていく様子を見守る物語である。
フリーレンは、かつてヒンメルと旅をしていたとき、彼が行く先々の村で小さな頼みごとを快く引き受けたり、困っている人を助けたりする姿に疑問を抱いていた。それは魔王討伐という目的に対して明らかな寄り道に見えたからだ。膨れっ面をするフリーレンに対して、ヒンメルは微笑みながらシンプルな哲学を語る。「ほんの少しでいい。誰かの人生を変えてあげればいい。きっとそれだけで十分なんだ。」ヒンメルはいつか自分の想いが理解され、世界を変えることを信じていた。
勇者ヒンメルは、魔王討伐という大義だけでなく、人々のために尽くすことを生き方とした。彼の死後もその想いは受け継がれ、様々な形で人々の心に息づいている。「継承」はこの作品における大きなテーマだが、ここで描かれるのは、組織の制度や社会の仕組みによって執り行われる継承ではない。むしろ、魔法を管理する協会が時代ごとに入れ替わったり、かつて魔法使いの証明であった「聖杖の証」がただの首飾りとして扱われるようになるなど、システムは「脆いもの」として示される。対照的に強調されるのはヒンメルのような「想いに基づいた行動」であり、それは時に人々の命を救い、社会を変える力を持つ。台湾で起きた事件も、ヒンメルの想いが次元を超え、現実の人々の心さえも動かしたことを象徴している。
『葬送のフリーレン』の中で、僕が最も好きな言葉は「イメージできないものは魔法では実現できない」というものだ。魔法とは技術であり、知識や鍛錬によって習得するものである。ただし、その魔法で起こそうとすることを具体的にイメージすることができなければ、魔法を行使することはできない。この仕組みについては「魔法とはイメージの世界」「術者がイメージできない魔法は使えない」などと繰り返し説明されており、例えば、花畑を出す魔法を使うときには、目の前の地表が花いっぱいで埋め尽くされる姿を想像することができなければできない。僕はこれを、想像力の重要性とその可能性を語った、現実世界にも通じる至言として受け止めている。
ヒンメルは魔法使いでこそなかったが、「よりよい世界をつくる」ということについては誰よりも具体的なイメージを持っていた。そして願いを込めながら、そのイメージを自ら体現し続けたのだ。それはまさに魔法となり、僕たちの日々に大きな勇気を与えてくれている。
2024-06-09
Hugo + Netlify + DecapCMS を使ったサイト構築
35歳の誕生日を機に、個人サイト（ブログ）をリニューアルすることにした。
以前より、Hugo + Netlify を使って個人サイトを配信していたのだが、この仕組みには「記事の更新作業に手間がかかる」という問題があった。
静的サイトジェネレーター兼コンテンツ管理として Hugo があり、Netlify がホスティングを担っているのだが、実際に記事を更新する際は、次のような手順となる。
- Github リポジトリを pull する（僕は複数台のマシンを使っているので、ローカルを最新状態に同期する必要がある。）
- mdファイルを追加し、そこにブログ記事を書く
- Github に push する
- Netlify が更新を検知し、build → deploy を実行する（＝サイトが更新される）
この手順から、Github に対する操作を省きたい。つまり、一般的なブログサービスのように（あるいは Wordpress サイトのように）「ブラウザで管理画面を開き、記事を更新する」という手続きにしたい。
そこで Decap CMS（旧・Netlify CMS）を使ってみることにした。ヘッドレスCMSの代表格で、特にGitベースであるという点が大きい（コンテンツの変更履歴を Git で管理できる）。
また、併せてサイトのデザインも一新することにした。以前は Hugo に不慣れなこともあり、無料配布されていた Hugo テーマを流用して改造しながら使っていたのだが、その運用を4〜5年ほどしたことで Hugo の仕組みにもだいぶ詳しくなった。そこで Hugo テーマをフルスクラッチで作ってみることにした。
各ツールの役割の確認
- Hugo : 静的サイトジェネレーター。Markdown ファイルを HTML に変換して静的なウェブサイトを生成してくれる。静的サイトにはロマンがある。Golangで書かれているため動作が高速で、Goテンプレートエンジンによる柔軟なテンプレートシステムが魅力的。
- Netlify : 静的サイトのホスティングサービス。Git リポジトリと連携して自動デプロイを行う。
- Decap CMS : オープンソースのヘッドレスCMS。GUIベースの管理画面を提供し、静的サイトジェネレーターと連携してコンテンツを管理する。実装後に重大な落とし穴が発覚する（後述）。
1. サイトの基本形を作成
まずはまっさらな状態から Hugo プロジェクトを作っていく。
1. Hugo プロジェクトを作成
hugo new site ezeroms.com
cd ezeroms.com
2. カスタムテーマの準備
Hugo プロジェクトで推奨されている形は、root ディレクトリの下に /site とかで区切って、テーマ等を置くディレクトリを一段下で管理する方法だ。これは、root ディレクトリでサイト設計やデプロイに関するメタ情報を管理し、具体的なサイト自身の設定や見た目と分離することで、複数テーマも管理やスケーラビリティを確保しようとするものだ。
しかし、今回のサイトの場合はテーマを切り替えることはない（自分でアップデートし続ける）し、プロジェクトの規模も小さいので、構造のシンプルさを優先して全て root ディレクトリ直下で管理する方法にした。
ezeroms.com
├── archetypes
│ └── index.html
├── content
│ ├── about
│ │ └── _index.md
│ ├── diary
│ │ └── _index.md
│ ├── shoulders-of-giants
│ │ └── _index.md
│ └── work
│ └── _index.md
├── layouts
│ ├── _default
│ │ ├── baseof.html
│ │ └── rss.xml
│ ├── about
│ │ └── index.html
│ ├── diary
│ │ ├── index.html
│ │ └── single.html
│ ├── month
│ │ └── list.html
│ ├── partials
│ │ ├── header.html
│ │ ├── footer.html
│ │ ├── global-nav.html
│ │ └── ...
│ ├── shoulders-of-giants
│ │ └── index.html
│ ├── subject
│ │ └── list.html
│ ├── topic
│ │ └── list.html
│ │── work
│ │ ├── index.html
│ │ └── single.html
│ └── index.html
├── public
├── static
│ ├── admin
│ │ ├── config.yml
│ │ └── index.html
│ ├── css
│ └── images
├── config.toml
└── netlify.toml
- public : hugo server で build されたファイルが格納される場所。キャッシュが邪魔しているのか？と思ったときは全削除したりする。
- content/*/_index.md : 一見不要そうだが、ここに index の md ファイルがないとディレクトリを正しく認識してくれない。
- static/admin : Decap CMS の管理画面用のファイル群。
2. 本番環境と自動デプロイの設定
1. GitHub リポジトリの作成
git init
git add .
git commit -m "Initial commit"
git remote add origin <GITHUB_REPO_URL>
git push -u origin main
2. Netlify アカウントの作成
3. Githubリポジトリの連携
Netlify の管理画面で「New site from Git」を選択し、GitHubリポジトリを連携。
4. ビルド設定
Build Command: hugo
Publish Directory: public
これで、Github の main ブランチが更新されると、Netlify側で自動デプロイが走るようになる。
5. ドメイン設定
Netlify の管理画面で ezeroms.com を割り当てる。
3. 詳細なサイト構築（テーマファイルの編集）
layouts 以下のテーマファイルと static/css をひらすら編集し、理想的なデザインを作り上げていく。自分一人のプロジェクトということもあり、あらかじめ全てのページを Figma で作ることはせず、主だったページのレイアウト構成だけ Figma 上で検証して、スタイリングについては実装しながら検討していった。褒められた方法ではないが、こういうところがソロ・プロジェクトの爽快なところだ。
コツ : テーマファイルへのマーキング
hugo server で localhost を確認しながら作っていくのだが、描画されているページに適切なテーマファイルが当たっているのかどうか分からなくなる。（「このページにこのテーマファイルが当たってほしいのに当たらん〜〜〜〜」的なことが続く）
そこで、すべてのテーマファイルに以下のようなマーキングした上で、config.toml の設定と、テーマファイルのディレクトリやファイル名を少しずつ弄りながら検証していった。
<!-- debug-info -->
<p class="debug-info">File : /layouts/subject/list.html</p>
最終的にこんなかんじで出来上がる。
課題 : URLスキーム
本当はもっとURLスキームに拘りたかったのだが、どうやってもできず（Decap CMS管理の範囲外を作ることになり）断念した。いい方法を知っている人がいたら教えてほしい。
# 理想的なURLスキーム
ezeroms.com/diary/
ezeroms.com/diary/subject/news/
ezeroms.com/diary/month/2024-06/
# 実際のURLスキーム
ezeroms.com/diary/
ezeroms.com/subject/news/
ezeroms.com/month/2024-06/
4. CMSを導入してブラウザから更新できるようにする
package.json を作成し、Decap CMSをインストール。
npm init -y
npm install netlify-cms-app
static/admin ディレクトリの config.yml 、index.html を編集してセットアップし、ezeroms.com/admin にアクセスすれば管理画面が使えるようになる。めっちゃ簡単だ。
管理画面の自由度がとても高く config.yml で設定すると一覧の表示項目も柔軟に変更することができる。
backend:
name: git-gateway
branch: main
media_folder: "/static/images/uploads"
public_folder: "/images/uploads"
collections:
- name: "about"
label: "About"
folder: "content/about"
create: true
slug: "{{fields.slug}}"
fields:
- { label: "Body", name: "body", widget: "markdown" }
summary: "{{body}}"
- name: "diary"
label: "Diary"
folder: "content/diary"
create: true
slug: "{{fields.slug}}"
media_folder: "/static/images/diary/{{fields.slug}}"
public_folder: "/images/diary/{{fields.slug}}"
fields:
- { label: "Title", name: "title", widget: "string" }
- { label: "Date", name: "date", widget: "datetime", date_format: "YYYY-MM-DD", time_format: false }
- { label: "Slug", name: "slug", widget: "string" }
- { label: "Month", name: "month", widget: "list" }
- { label: "Subject", name: "subject", widget: "select", multiple: true, options: ["news", "music", "manga-and-anime", "movies-and-dramas", "comedy", "gaming", "sports", "books-and-magazines", "languages-and-foreign-cultures", "design-and-creative", "internet-and-technology", "natural-science", "humanities-and-social-sciences"] }
- { label: "Body", name: "body", widget: "markdown" }
summary: "{{date | date('YYYY-MM-DD')}} | {{body | truncate(280, '...')}}"
sort:
field: "date"
direction: "desc"
- name: "work"
label: "Work"
folder: "content/work"
create: true
slug: "{{fields.slug}}"
media_folder: "/static/images/work/{{fields.slug}}"
public_folder: "/images/work/{{fields.slug}}"
fields:
- { label: "Title", name: "title", widget: "string" }
- { label: "Date", name: "date", widget: "datetime", date_format: "YYYY-MM-DD", time_format: false }
- { label: "Slug", name: "slug", widget: "string" }
- { label: "Image", name: "image", widget: "image" }
- { label: "Body", name: "body", widget: "markdown" }
summary: "{{date | date('YYYY-MM-DD')}} | {{title}}"
sort:
field: "date"
direction: "desc"
- name: "shoulders-of-giants"
label: "The shoulders of Giants"
folder: "content/shoulders-of-giants"
create: true
slug: "{{fields.slug}}"
fields:
- { label: "Topic", name: "topic", widget: "list"}
- { label: "Body", name: "body", widget: "markdown" }
summary: "{{body | truncate(280, '...')}} Topic {{topic}}"
sort:
field: "body"
direction: "asc"
Decap CMS の落とし穴
さて、これで理想的な個人ブログの運用体制が構築できた…と思っていたのだが、ここで Decap CMS の大きな落とし穴が発覚する。
記事のテキストフィールドが、日本語入力に対応できていないのだ。漢字変換をしようとしたときにキャレットの位置がズレてしまい、正常に入力作業をすることができない。
Updating Slate editor to support Korean
どうやら Slate のバージョンが古いのが原因らしく、改善のためのプルリクは出ているのだがスルーされているっぽい。
（写真）
Issueが立っていたのでむなしくコメントを残しておいた。
なので、このサイトの実際の運用は次のようになっている。
- UpNote でコンテンツ管理（UpNote はモバイル用のネイティブアプリが用意されている）
- UpNote から DecapCMS にコピペして記事を更新
記事の編集作業部分をテキストエディタに外出ししている状態だ。以前に比べれば格段に更新しやすくはなったものの、できればブラウザで完結する運用を目指したい。
もちろん、ヘッドレスCMSには Decap CMS 以外にも選択肢はあるのだが、Netlify との相性と「無料で使える」という条件で探すと少し絞られてしまう（APIでやりとりするものは使いたくない）。また、できればスマホから更新ができるように、モバイル用インターフェースが提供されているとなお嬉しい。もう少し調べてみようと思う。
2024-06-20
プロダクト開発とユーザーとの摩擦
5月から6月にかけて、Chooningのアップデートを重ね、新たな機能を続々とリリースした。アーティストのアカウント認証機能、プロフィール共有機能、Spotify視聴履歴に基づいたおすすめ投稿機能などを実装し、さらに中国語（繁体字）版インターフェースもリリースして、この夏は台湾市場への進出も見据えている。
しかし、どんな施策も万人に受け入れられるわけではない。アプリのアップデートは歓迎されるばかりではなく、ときに「改悪だ」という厳しい意見も寄せられる。開発者は、データベースに記録される値や計測ツールの結果、インタビューを通じたユーザーの声など、様々な情報のもとに開発内容を決めている。それでも、すべてのユーザーを満足させることはできない。長くサービスを続けていれば、開発者とユーザーの間には大なり小なり摩擦が生じる。
一般的によくあるのは、サービス側が収益性を高めようとする施策だろう。例えば、目立つ場所に広告を配置したり、広告の表示頻度を上げたりすればユーザーは不快に思う。動画や漫画の続きを見ようとして、下手くそなゲームのプレイ動画を数十秒見せられてイライラした経験をしたことのある人は多いだろう。Chooningにはそういった仕組みはないが、僕は会社員としてプロダクトを作っていたとき、この手の実装をする際には心苦しく思っていたし、実際にリリース後のSNSでユーザーの毒づく声を目にしてよく落ち込んでいた。
Chooningでは収益性を求める施策は行っていないものの、だからといってユーザーの不満を買わずにやれているわけではない。むしろ、より切実な衝突を感じることがある。例えば、ユーザーのプロフィールをシェアできるようにした件については「お互いにフォローせず、時々お邪魔するのが楽しみだったのに」といった声が上がった（恐らく相互フォローを促進する意図があると受け止められたのだろう）。また、おすすめフィードを実装した件については「ファーストビューがメジャーなアーティストで埋め尽くされてしまい、自分の好きなマイナーアーティストを紹介しても届きづらくなった」という声が上がった。
僕は常々、自分のプロダクトは技術や機能だけでなく、価値観の次元で勝負したいと思っている。Chooningでユーザーが体験できることは、「人と音楽との関わり方はこうあってほしい」という僕の価値観に基づいている。具体的には、Spotifyなどのサブスク（ストリーミング）サービスで音楽を手軽に聴きながらも、その音楽について向き合って考えたり、些細な思い出を語ったり、同好者と共感し合う時間を持って欲しい、というものだ。そのためにユーザーがスムーズに音楽を共有したり、見つけたり、交流したりできる機能を充実させている。僕のようなタイプの開発者には、そうやって価値観を形にしたものに触れてもらい、それを心地よいと感じてもらいたいと思う欲望がある。機能の追加や変更は、自分の価値観をより明確に伝えるためのメッセージでもある。
だからこそ、仕様を変更したときに、それまで支持してくれていたユーザーが「これは求めているものじゃない」と言って離れていくのを見ると、価値観に共感してもらえなかった…という極めて個人的な喪失感を感じてしまう。それは、収益性の都合でユーザーに不満を持たれるよりもはるかに悲しい。収益性の向上はサービスの存続に不可欠であり、僕も運営者としての責務の一部として割り切ることができる。しかし、価値観の相違による意見の衝突は自分の気持ちの解決が難しい。「ごめんな、でも僕はこう思うんだ。分かってくれることがあれば嬉しい」と目を閉じるしかない。
離れていってしまったユーザーのことは、いつも少し心に棘が刺さったような気持ちで残っている。自分のプロダクトを作るということは、自分の価値観を形にして社会に届けるということだ。そこでは多くの「Not for me」の声も受けることになる。ストアからダウンロードした僕のアプリを、翌月も使い続けてくれる人がどれくらいいるだろう？ その数字を見る度に、僕は他者との価値観の違いを認識する。あえて強がってみせるなら、それこそが、本気で物を作ることの面白さだと言えるかもしれない。
プロダクトには成長していく段階があり、それに伴って作り手と使い手の関係も変わっていく。ある時期を共に過ごしたユーザーの一部が次の時期に離れていくことは避けられない。頭では理解しているのだが、それでも、一度プロダクトを気に入ってくれたユーザーには、ずっと使い続けてもらいたいと願ってしまう。
ユーザーの声は大きい。少なくとも僕は、どんなに厳しい意見や的外れな批判でも、自分が生み出したものに対して感情を込めて意見をくれる人には感謝している。高校時代にゲームを作ったり、大学時代に友達とサービスを作っていた頃は、世の中の反応は全くなかった。それに比べれば、不満の声であったとしても「反応がある」というのは嬉しいことだ。作り手のモチベーションは、案外そんなものに支えられている。
2024-06-22
神話を解体する自販機と昆虫食文化について
JR関内駅北口の喧騒の中に、ひときわ異彩を放つ自動販売機が設置されている。その名も「次世代良質昆虫Food」―――昆虫食を取り扱った自販機だ。
「広島こおろぎ大トロ」「山形かいこ繭」「コオロギおつまみせんべい」「コオロギ・ラーメン」「ライノ・ビートルズ（カブトムシの成虫）」「ジャイアント・ウォーターバグズ（タガメの成虫）」「ゼブラ・タランチュラ（デカい蜘蛛の成虫）」…などなど、虫が苦手な人なら卒倒してしまうような商品が陳列されている。なかなかハードコアなシロモノだ。
自宅の最寄り駅でもあるので、毎日のようにこの自販機を目にしているのだが、実際に商品を買ったことはまだ一度もない。僕はいわゆる昆虫少年だったので、虫そのものに対しては普通の人より抵抗感はないのだけれど、それを食べ物として扱うことについては、多くの人と同じようにかなりの躊躇いがある。この自販機の商品パッケージに描かれたものを自分が噛み砕いて胃に収めることを想像すると、たちまち口腔内に気色い感触が広がり、目眩すら感じてしまう。中年に差し掛かった三十五歳男性の姿としては情けないものかもしれないが、これが僕の真実の姿なので仕方ない。
その一方で、イナゴの佃煮や炒めた蜂の子程度であれば子どもの頃に口にしたことがあり、いまでも「食べろと言われたらまあ食べられる」くらいの感覚もまた同時に持ち合わせている。当時住んでいたのは神奈川県の横須賀市で、決してそういった食文化のある地域ではなかったのだが、両親のおかげで有り難い機会に恵まれてしまったのだ。例えば、イナゴの佃煮は、母が自然食品を取り扱っているような店で買ってきていた。柔らかい部分と硬い部分が混在した小海老のような食感で、噛みしめていると甘塩っぱい味がしてくる。これが結構クセになる味で、僕は割と好きだった。何度かねだって買ってもらった記憶すらある。蜂の子は、庭のアシナガバチの巣を駆除したときに父が炒めて作ってくれた。「こういった食事もあるのだ」と教える目的だったのだろう。1951年生まれの父親が、新潟県の自分の田舎では珍しいものではなかった、という話をしながら、台所でフライパンを振るっていた姿を覚えている。僕はなんとなく勝手に、それが蜂蜜のような甘い味がすると期待していたのだが、実際にはまったりとした味のしないクリームのようで、お世辞にもおいしいと言えるものではなかった。僕も妹も一口つついて食べるのをやめてしまい、残された大量の蜂の子を一人でさみしそうに食べる父の背中が印象に残っている。（ただ、その父すらも「あれ？ こんな味だったか…？」と首を傾げながら食べていた。）
そんな経験もあるので、自分に昆虫食の素養がまったくないわけではないと思うのだが、イナゴや蜂の子以上のものには…特に甲虫類や蜘蛛などになると、かなりの抵抗感がある。この手の食に対する認識というのは、結局のところ、それが本人にとってどれほど身近にあったか、ということに尽きるのだろう。僕がカブトムシやタガメやセミを食べられないのは、この歳になるまで食べずに育ってきたから、というだけのことに過ぎない。『彼方のアストラ』でアリエス・スプリングが仲間を庇いながら言う「そういう風に育ったから、そうなった」という言葉は、つくづく真理を語ったものだと思う。
さて、件の自販機だが、多くの人々がその前を通り過ぎる中で、さまざまな反応を見せる。怪訝な表情を浮かべるおばさんや、無表情で固まったまま見つめ、やがて何事かを理解したかんじで立ち去っていくスーツ姿のおじさん。指を差してキャーキャーと騒ぐ恋人たちもいれば、酔っ払った大学生たちが罰ゲームとして購入している姿も見たことがある。今日も駅前を通ると、自転車に乗った小学生たちがこの自販機の前で輪を作っていた。高学年の男子の一人、少し太めで大柄の少年が自販機の前に立って何を購入するか選んでおり、他の子どもたちはそれを不安げに見守っている。会話を聞いていると、どうやら度胸試しのようだった。その光景を見ていて、もしいま僕が小学生だったら同級生の前でカッコつけてバリバリとセミやタガメを囓っていただろうし、もし大学生だったら率先して罰ゲームのネタにして大騒ぎしていたんだろうな…と想像し、少しゲンナリした（残念ながら僕はそういう愚かな子どもであり、愚かな若者であった）。
ただ同時に、罰ゲームだろうと度胸試しだろうと、僕たちの文化というものは案外こういうところから変わっていくのかもしれない、とも考えた。どんな形であれ「虫を口にしたことがある」という経験が広まることは、人々の認識や文化に影響を与えていくはずだ。きっと彼らがそういう風に育つことで、社会はそうなっていくのだろう。
僕が日本で具体的に昆虫食を広めようとする運動や愛好者たちの存在を知ったのは、2015年頃、シナプスという会社でオンラインサロン事業に携わっていた頃のことだ。そこで昆虫食を研究するサロンが開設され、バナーなどのデザインを手掛けることになって、サロン開設者の文章に触れたことがきっかけだった。それから十年近くが経つが、いち消費者として見る限りでは、昆虫食文化の普及はあまり進んでいないように感じる。どうやら日本で昆虫食を広めるのは容易ではないようだ。
しかし、この自販機はその難題に対するユニークなアプローチとして機能している。昆虫食は高たんぱくで栄養価が高く、環境負荷も少ない。フードセキュリティの観点からも積極的に取り入れていこう、とただ声高に説くだけでは限界がある。駅前に自販機を置き、遊び心で挑戦するような環境を作ることは、昆虫食が単なる食糧問題の解決策としてだけでなく、日常の一部として受け入れられるための重要な回路となり得るはずだ。
フランスの哲学者であり記号学者でもあるロラン・バルトは、著書『神話作用』で、日常生活の中に潜む「神話」を解体し、分析する試みを行った。バルトが言う「神話」とは、単に古代の神話や伝説を指すのではない。彼は、現代社会におけるさまざまな文化的事象や習慣、商品、メディアのメッセージなどを「神話」として捉えた。例えば、広告、映画、スポーツなどの中に潜む「神話」を分析し、これらがいかにして人々の意識や価値観を形作り、ある特定のイデオロギーを自然なものとして受け入れさせるかを示した。バルトの研究の目的は、こうした「神話」の解体と、その背後にあるメッセージや意味を明らかにすることだった。
僕は、この駅前の自販機を見るたびに思う。現代の日本社会における「食文化の神話」の解体は、まさにいま、この自販機の前で始まっている、と。日本では、昆虫を食べることは一部の地域を除いて一般的ではなく、むしろ奇異なものと見なされがちだ。しかし、この町の人々の目の前に突如として現れたこの自販機は、従来の固定観念を揺さぶり、新たな食文化の扉を開こうとしている。これは単なる奇抜なベンディング・マシンではなく、社会や文化の変化を促す実験装置なのだ。
そして、その触媒となっているのが、男子小学生たちの度胸試しや、酔っ払った大学生たちの罰ゲームといった愚行だ。文化の変化は、往々にしてこうした遊び心や無駄といった生活の余白から生まれる。僕は自販機前の光景にかつての自分の姿を重ねながら、そのような正当性を検討することで、自らの過去を慰めるのであった。
