2025年ふりかえり

今年も色々ありました。振り返り。

IT技術者として

数値で振り返ると次のようになります。

  • ブログ記事: 11本
  • YouTube動画: 26本
    • 低レイヤ技術の説明動画が通算100個突破。めでたい。
  • スライド(一部YouTube動画と重複): 30個
    • SpeakerDeckにアップロードした動画の数が200個突破。めでたい。

この記事を書き始める前は「今年は大人しかったなあ」と思ってましたが、まとめてみればそうでもなく、相変わらず落ち着きなく何かをしていたようです。

会社員として

公になっているのはKubeConのメンテナセッションをやったくらいですね。これはなかなか盛り上がってよかったのではないでしょうか。

speakerdeck.com

開催直前に咳喘息を発症して「そもそもセッションが成立するのか」というくらい危なかったですが、なんとかなりました終わりよければすべてよし。

それ以外はひっそりと、あれとかこれとか諸々やってました。反省点が大変多かったですね。来年改善します。

個人事業主として

Linuxカーネルの本を共訳したのが一番大きな仕事です。いいかんじに訳せたのではないでしょうか。これまでLinuxカーネル開発について同人誌や小さな記事を色々書いてきましたが、しばらくそういうのは書かなくてもいいかな、と思うくらいよくまとまった本だと思います。

satoru-takeuchi.hatenablog.com

今年の後半あたりからは、何年も前から書く書くといって全然書き終わらないソースコードリーディング本について、ついに筆が進むようになってきました。年末年始も進捗を出したいと思います。これについては一部スライドやYouTube動画として先出しました。大きな反響をいただいたので執筆意欲がわきました。

speakerdeck.com

youtu.be

youtu.be

来年こそ原稿を書き終えるぞという心意気でやっていきます。

その他には、過去に書いた本が「Linuxのしくみ」をはじめ、じりじりと売れ続けていて、不労所得嬉しい…もとい、書いてきてよかったなあという思いをあらたにしました。長く読み続けられる本になってほしいです。

YouTuberとしての活動は前述の通り26本の動画を公開しました。チャンネル登録者数はさっき見たところ12000人を超えたようです。なかなかいいですね。課金してくれるかたもわずかながら増えました。今年の動画の中で一番ウケたのはLinuxのブートプロセスについてのものです。これについてはいずれもうちょっとちゃんとしたものを同人誌としてまとめてもいいかなと思っています。

youtu.be

YouTuberとしては利益は全く出ていなくて悲しいなあというスライドも作りました。

speakerdeck.com

来年はUdemyでYouTubeよりだいぶクオリティを高くした動画を販売しようかなと思っています。年末年始に仕込みます。

今年は終盤まで真面目なことばかりしていて鬱憤がたまっていたのですが、12月上旬のKernel/VM探検隊@北陸 part8 でふざけた発表をしてすっきりしました。

speakerdeck.com

趣味

今年はライブにたくさん行きましたね。大変よかったです。

satoru-takeuchi.hatenablog.com

あとはキャンプもたくさん行きました。楽しかったです。

終わり。

書籍を書く時のGitHubを使った原稿管理のしかた

私はこれまでIT技術についての書籍を十冊以上書いてきました。一般書店に並ぶものから同人誌まで、何百ページのものから数十ページくらいのものまで、さまさまです。

techbookfest.org

これらの本の原稿はすべてGitHubで管理してきました。本記事は私が長年蓄積してきたGitHubでの書籍の原稿管理方法を共有します。何事も直感に従ってその場のノリで動くという私の性格を強く反映したやり方なので、人によって合う合わないはあると思います。

私は文書の変更はかなり細かくコミットしていきます。筆が進むうちに書いたところまでコミット、ある程度時間が経てばコミット、です。コードとは違ってコミットを論理的な単位で分割しません。ごちゃごちゃ考えていると執筆の神様は逃げてしまうので、書いたらとりあえず永続化します。また、頻繁にコミットしてると進んだ感が出てきて滅入りにくくなるというメリットもあります。

コミットメッセージはほとんど書きません。主な理由は、コードと違って「過去にどのような契機でこの部分を変更したのかを正確に知りたい」ということがあまり無いからです。それなのにコードと同じ感覚で原稿を書こうとしても、いつまでたっても進みませんし、そのうち嫌になってきてやめてしまいそうなのでいいことが無いと考えています。

まとまった変更のためにbranchを切るようなことはしません。とくに、関係者に共有する前はPRなんて作らずに、どんどんmainにマージしていきます。例えば章ごとにbranchを分ける…というようなことをしても特にメリットは無いです。作っても後で忘れますし、思い出したときにはconflictだらけになっていたり、すでに不要な文書になっていることが多くてつらいです。そうではなく、思いついたら本文にすぐ反映させ、常に文書全体の構造を頭に入れて、できるところからどんどん書いていきます。

編集者やレビューアといった関係者と原稿を共有するの際は、 彼らにGitHubのアカウントを教えてもらって、リポジトリのコラボレータになってもらいます。上述の通りIT技術の本なのでGitHubを使える関係者が多いからできることです。他の分野の本だとこうはいかないでしょう。たぶん。

関係者からのコメントはissueないしPRの形で受け入れます。このとき、「こんな観点でレビューしてほしい。こんなコメントはissueで、こんなコメントはPRで欲しい」といったレギュレーションを最初に決めてREADMEに書いておきます。

ほとんどのコメントはissueの形で受け取ります。たとえば「ここの段落は意味がわからない」と指摘してもらって、対応するPRを私が作って、コメントをした人に受け入れてもらったらマージ、というやりかたです。

レビューアになんでもかんでもPRを作ってもらうというやり方は非効率だと考えています。理由は、文書は人によってかなり個性が出ること、最終的な成果物は一人の個性で統一されていると読みやすいと考えていること、他の人の個性が反映された文書を自分の言葉に置き換えるコストが大きいことです。ただし、誤字脱字、技術的誤りといった変更点が自明なコメントはPRを出してもらって修正案をそのまま受け入れるというやりかたがうまく機能します。

原稿のファイル形式はmarkdownが多いです。テキスト形式で表示してもある程度読める、覚えることが少ないため書くのが楽、GitHubがhtmlにレンダリングする機能を持っているのでプレビューもしやすい、といった理由で選択しています。関係者も読み書きできることが多いのも利点です。ただし最近は、markdownと同様の利点を持ちつつ、ややマイナーですが、より表現力が高いasciidocに乗り換えつつあります。なお、asciidocもGitHubがhtmlにレンダリングして表示してくれます。

サンプルコードを挿入するときはベタ書きだと管理しにくいのでコードを単体でファイルにしておき、文書ファイルからはコードに対応するファイルを参照します。こうすると後からコードを変更しやすい、コードのテストが容易、出版後にソースコードだけ公開することになったときに自動で公開用のリポジトリを作成、更新するのが楽といったメリットがあります。

画像はGoogle Drawingsで書き、画像形式にexportしたバイナリをGitリポジトリに突っ込んでいます。Gitリポジトリへのバイナリの保存は忌み嫌われがちですが、どのみち大したサイズではないし、頻繁に書き換えるものではないので気にしてません。

本記事は私が書籍を書くときにGitHubで原稿を管理する方法を紹介しました。書籍を出したいと思っている人、すでに出して次もやりたいと思っている人のうちの誰かに刺さることを願っています。

生成AIを使ったサービスとの付き合い方

世の中に大量に溢れている生成AIを使ったサービスとの私の付き合い方、考え方について書きます。仕事の話ではなく私的な話のみをします。

どういうサービスを使っているのか

主にChatGPTを使っています。日々わからないことを調べるときに過去にはググっていた場面で、8割くらいはChatGPTでやるようになりました。残り2割は何かというと、質問と答えの対応がはっきりしているものですね。自分が全く、あるいはあやふやにしか理解していないことについての質問は全てChatGPTにしています。めちゃくちゃ便利です。

コーディングにはCopilotを使っています。課金はしていません。VS Code上でコード補完、対話形式でコードを生成させたりする機能を使っています。私はコーディングが苦手なこともあって、生産性は大きく上がっていると感じます。自律的にまとまったタスクを全部やらせる機能は使ってません。

課金をしないのは、大がかりに使っていないので、今の使い方では課金しなくても困らないからです。タスクを丸ごと任せない理由は、何されるかわからないという恐れがあるからです。これは感覚的なものであって、そんなに深く考えてはいないです。3日後には気が変わって使っているかもしれません。

その他のツールはまだ積極的に使っていません。もっといいのがあるのはわかりますが、面倒なので評価していません。いずれ導入するかもしれませんが、いつになるかはわかりません。

他のサービスとの比較検討はしたのか

ChatGPT以外にGeminiなどを評価したかというと、していません。Copilot以外のプログラミング用ツールも、他のツールとの比較検討はしてないです。VS Codeですぐ試せそうなので使って、便利なのでそのまま使っているだけです。

他のツールをあれこれ探さない主な理由は、他のことにもっと時間を使いたいからです。私の人生全体の中で、生成AIを使ったサービスの良し悪しで幸福度が上がる割合は、まださほど高くはないです。どのサービスも目まぐるしく改善されてトップランナーが激しく入れ替わるり続けている現在、私にとって今何が一番のサービスかを追い求めるよりも、家族と過ごす時間や友達と遊ぶ時間のほうが大事です。

例えば10年後に生成AIが今よりはるかにすごいことになってて食っていけなくなる、ということは十分ありえますが、そこまで行き着くのであれば今現在の最新状況を追ってようとそうでなかろうと変わらなさそうなどと考えています。一つ言えることは、「将来ひどい目に遭うかも」と焦燥感に駆られてサービスの評価に明け暮れて現在のQoLを下げたくないということです。

生成AIサービスを使うにあたって気にしていること

一にも二にも確認、裏取りです。「ChatGPTがこう言っていた。ならこうなんだな、終わり」ということは絶対しません。サービスが返してくる回答は参考情報に過ぎません。回答を見て、別の調べ方をして、自分なりにその回答に筋が通っているのかを納得する、実際に確認する、といったことをします。

とくに人からの依頼に応えるときはこれが大事だと考えています。何かを聞かれてサービスの回答を鵜呑みにして「これが自分の回答です」ということをやってしまうと、それは自分が不要であることの宣言だと思っています。これは昔から言われているググった結果のコピペ、wikipediaのコピペはだめよという話と同じです。AIの回答はヒントとして扱い、それを最終的に自分の意見に昇華させなければいけないと考えます。

おわりに

便利な世の中になりましたね。テクノロジーすごい。

寝ても覚めてもコーディング…ではないソフトウェア技術者にとっての生成AI

本記事はコーディングが得意ではないし、ものすごく好きなわけでもない人にとっての生成AIを使ったコーディングについての意見を書いたものです。書くのはあくまで個人的な活動についてのもので、所属する組織の一員としての活動とは関係ないものと考えてください。

ここしばらく、生成AIを使ったコーディングが流行っていますね。私の観測範囲では、情報発信している方は、もともとコーディングがめちゃくちゃ得意であったり、好きであったりする人が多かったです。そんな中で、そうではない人の意見は何らかの役に立つのではないかと思って書きました。「開発の楽しさ」「開発速度」「品質」がどのように変わったかに注目しています。

まずは開発の楽しさについて。これは私は上がりました。コーディングがものすごく好きな人が「楽しくなくなった」と言っているのを少なからず見ましたが、私はそれはありませんでした。これはコードを書くことそのものをどれだけ楽しめているかによって感想が大きく変わるのではないかと思います。私はプログラミングは好きですが、寝ても覚めてもやっているほどではありません。目的を達成できれば自分でコーディングできなくても多くの場合は気にしません。そういうこともあって楽しさという観点ではプラスに働きました。

続いて開発速度について。私はこれも向上しました。現状の生成AIは仕様が明確に決まっている小規模のコードであれば、そこそこの精度で作ってくれます。その後のレビューは必須ですが、他人の書いたソースを見るのは得意ですし苦にならないので、そんなに大変ではありません。いままではコードを書くところで、とくに新規に何かを作る場合は、私の実装速度が遅いことがネックになることが多かったので、そこが生成AIによった、ある程度は改善しました。「自分で書くほうが速い」という人と、そこが違うと考えます。

最後に品質について。これは一概には言えませんが、そんなに変わらないかなと思います。一発目に殴り書きしたコードは生成AIよりも自分のほうがマシなものを書けますが、どのみち「できた」とみなすまでは自己レビューをするので、最初に書いたのか自分だろうとAIだろうと、最終的にはそんなに変わらないとは思います。

まとめです。上述の通り、私の場合は現状の生成AIは、ネックだった実装能力を強化してくれる素晴らしいツールです。どんどんいいかんじになって人間の仕事が減ることを願っています。また、願おうと願うまいといずれそうなると推測しています。

「Linuxカーネルプログラミング」という本を翻訳しました

Linuxカーネルプログラミング」という本を翻訳しました。明日(2025年7月28日)発売です。

原著はこちら。

Linuxカーネルを扱った日本語の書籍といえば、「詳解Linuxカーネル」や「Linuxカーネル2.6解読室」が有名です。

どちらもLinuxのコードレベルまで踏み込んだ解説書でした。それに対して本書はコードの説明もしますが、カーネルモジュールの開発によってLinuxの主要なサブシステムを理解するというアプローチをしています。これは「なにかを学習するには手を動かすとよく身につく(意訳)」という著者の考え方を反映しています。

さらにいうと、前述の2冊は発売から既に20年近くが経過していますが、本書は2024年時点での最新Linuxカーネルについて扱っています。目まぐるしくソースコードが変化するLinuxにおいて、新しいカーネルを扱っているというのは大きなメリットです。

Linuxカーネルのコードは膨大ですが、本書はその根幹を成す重要のサブシステムを一通り説明しています。以下、本書の目次をO'Reilly Japnの公式サイトから引用します。

目次にはあらわれていませんが、随所にセキュリティ機能についても触れられていますし、仮想マシンやコンテナの実現に欠かせないcgroupsについても言及されています。仮にカーネルプログラミングをしないにしても、最新カーネルの機能を大まかに知る助けとなるでしょう。

余談ですが、本書の表紙にはタスマニアデビルが描かれています。「LinuxといえばマスコットはペンギンのTuxでは?なぜタスマニアデビル?」と思う方もたくさんいるでしょう。しかし、実は一時期LinuxのマスコットはタスマニアデビルTuzだったのです。というマニアックな過去の経緯から本書の表紙はタスマニアデビルにしました。なお、原著はPackt Publishingという出版社から出ていて表紙も全然違っていたのですが、日本語版は動物の表紙で名が通っているO'Reillyから出版されることになったため、このようになりました。

さらに余談ですが「Linuxカーネル2.6解読室」は当時著者陣が所属していた(今も全員いらっしゃるかもですが)VA Linux社の技術者たちが「新Linuxカーネル解読室」というアツい連載をしているので、興味のある方は御覧ください。

以上

日傘はよい

生まれて初めて日傘を買いました。日課になっている朝の散歩で夏場にさして暑さをしのぐのが目的です。もともと夏場は帽子(キャップ)で頭への直射日光を避けていましたが、ここ数年はそれでは太刀打ちできなくて散歩を断念する日が多くなっていました。日中は家にこもってパソコンカタカタばかりしてる私にとって運動機会が減るのはよろしくないことなので、ならば日傘を…と購入に踏み切りました。

さっそく使ってみたところ、帽子とは比較にならないくらい、とても良かったです。帽子は頭への直射日光は防げるもののジリジリ熱を持つし首や肩には日光があたるといった弱みがありました。それに対して日傘は手首辺りまである日陰を常に作ってくれるので、とても良かったです。散歩時のまとわりつくような疲労はかなり緩和されました。

そんなこんなで今年は夏に入ってもほぼ毎日散歩できています。よかったですね。なぜ今まで使わなかったんだ、というくらいです。これからも活用していきます。

ちなみに買ったのはモンベルのやつです。

https://webshop.montbell.jp/sp/goods/disp.php?product_id=1128751

外出先でも散歩するので折りたたみのものにしました。ほかの日傘を買ったことがないので、これが他のものと比べて相対的にいいやつなのかどうかは知らないです。また、ハットも使ったことがほぼないので日傘との比較はできません。

終わり。

THE YELLOW MONKEYのライブに行ってきた: 2024-2025

THE YELLOW MONKEYというロックバンドのライブに2024年から2025年にかけて3回行ってきました。あとライブ・ビューイングも1つ行きました。これらの感想を書いておきます。ライブというものにこれまで一度も行ったことがなかったので、そういう感想も書きます。

このバンドは1990年代後半から2000年代前半あたりには一般的知名度がけっこう高かったと思います。メジャーではありましたが独特のギラギラドロドロした雰囲気があり、他のバンドとは何か違っていたと記憶しています。2004年に一度解散して2016年に再結成したので、その後知ったという人もいるでしょう。

私は解散前は「シングルは知ってる。好き」「ずっとひっかかっていてたまに思い出す何個かある」くらいでしたが、コロナ禍で暇だったときにYouTubeを漁ってたらライブ映像を見つけて、それがよくてアルバム聴いてみたら全部良くて、ハマりました。それでライブのパフォーマンスが凄かったので「これは機会があれば生で観てみたい」と思うようになりました。その後ボーカルの吉井さんが喉頭がんを患って復活、東京ドーム公演で復帰、ということになり「そんなことが可能なのか?」「どのようなパフォーマンスになるのか」「もしかするとこれが最後の機会かもしれない」と思い、一念発起して行くことにしました。

THE YELLOW MONKEY SUPER BIG EGG 2024"SHINE ON"

このライブはとにかく人が多くて5万人くらいいたらしいです。人が米粒サイズで蟻のようで、1つのバンドを観るためにこのれだけの数が集まるなんてすごいと思いました。このライブは吉井さんが病み上がりだったということ、途中で彼が自ら述べた通り明らかに喉の調子が悪そうでした。聴衆がずっと祈るように観ていたと記憶しています。一般的なライブとは違った意味での一体感があったように思います。最初に参加したライブなのに一般的もなにもないんですが、とにかくそう思いました。

喉の調子が悪かったとは書きましたが、それはそれとしてこのライブがたいへん良かったです。最初から最後まで代表曲のオンパレードで、復活後リリースされてい曲もやりつつ、硬軟自在でよろしかったです(セトリ)。 以下、とくによかったものをいくつか挙げておきます。

www.youtube.com

復活後にリリースされた、ライブのタイトルにもなっている曲です。サビのところにクラップがあるんですが、これでうまく一体感が出ていました。最初のライブなのにちゃんとみんな拍手のタイミングが合ってて「ファン凄い」って思いました。

www.youtube.com

暴力的なイントロから始まる彼らの代表曲のひとつです。歌詞がダサいとカッコイイの間のすごくいいとこどりなのです。とにかくかっこよかった。

www.youtube.com

中盤で流れました。もともとは吉井さんがおばあ様に宛てた曲だったらしいのですが、人生の終わりにいったん近づいた吉井さんがここで歌うことに大きな意味があったのだと思います。改めて凄い曲だと思いました。

www.youtube.com

ファーストシングルです。アルバムに入っているものはそれほど好きではないんですが、ライブだと別物に化けて非常に格好いいです。とくに、復活後のやや掠れが入った今の声でこそ出るかっこよさがあります。全然売れなかったと自他ともに認める曲がライブの定番になっているというのはすごいですね。

www.youtube.com

これまた全然売れなかったけど代表曲で、ライブの締めでよく演奏するやつです。私も全ての中でトップクラスに好きな曲です。ライブ後半なのにめちゃくちゃ走り回りながら歌っていて、「病み上がりの人がこんなことができるのか」と思いました。

最後に人生初ライブの感想を。私はうるさいのが大嫌いなのですが、好きな音だとうるさくても心地いいとわかりました。今後も行きたいなあ…ということで、この後始まった全国ツアー「Sparkleの惑星X」にも何個か参加することになりました。よかったですね。

THE YELLOW MONKEY TOUR 2024/25~Sparkleの惑星X~ 1228 Budokan Live Viewing

ここからはSparkleの惑星Xについての感想です。このツアーはBlock1~3までの3ブロックに分かれていて、それぞれセトリが違うという構成でした。このツアーは最新アルバムSparkle Xを軸にしつつ、1つのblockにつき1つの過去アルバムをとりあげて、それぞれの曲を織り交ぜて演奏するというものでした。

Block1のチケットは当たらなかったのですが、ライブビューイングやるということで近くの映画館に行ってきました。このブロックのテーマは3rdアルバム jaguar hard painでした(セトリ)。このアルバムは全アルバムの中でも1,2を争うほど好きな曲なので非常にうれしかったです。前述の「悲しきASIAN BOY」もこのアルバムに入っています。声は前半は危うかったんですが後半はかなり安定していました。明らかに東京ドームのときより良かったです。

このライブでとくに印象に残った曲は次のものです。

www.youtube.com

2ndアルバムの中の非常に毒々しい曲です。好きな曲だったのでこれがライブで聴けるとは…という感想でした。なにかが憑依しているのかと思うくらい迫力がありました。

www.youtube.com

これも2ndアルバムの曲。箸休めのような位置付けで、この日のライブでもそのような位置づけでした。非常に気を抜いて聴けてよかったです。

www.youtube.com

これも2ndアルバムの曲。ライブでは異様な一体感を生み出す曲です。とにかくよい。

www.youtube.com

Sparkle Xの曲…なんですが、このアルバムのリリース後に出たComplete Boxにだけ入っている曲です。本来アルバムに入るべきだったけれども諸事情によりこういう形のリリースになった…とのこと。まあそれはいいとして非常にやさしい曲で、毒々しいjaguar hard painの曲の中にこれが演奏されると何とも言えないさわやかさがあってよかったです。

なおライブの最後に、Block 3の後にFinal Blockという追加公演をやるということがわかりました。後で書くように、それにも行きました。

THE YELLOW MONKEY TOUR 2024/25 ~Sparkleの惑星X~【Block.2】なし

Block 2はチケット取れませんでした、無念。このblockのテーマは4thアルバムSmileでした(セトリ)。

何らかの形で音源がリリースされるといいですね…と思っていたらファンクラブ限定のシングルにBlock 2のライブ音源が入っていることがわかりました(買った)。よかったですね。

THE YELLOW MONKEY TOUR 2024/25 ~Sparkleの惑星X~【Block.3】富山オーバード・ホール

Block 3です。テーマは5thアルバムFour Seasonsです(セトリ)。Block 1のときよりもさらに声が安定していました。印象に残った曲を挙げておきます。

www.youtube.com

Four Seasonsの曲です。ライブはこの曲から始まりました。もともとアルバムの中でそれほど好きというわけではなかったですが、滅茶苦茶かっこよかったです。ライブ映えしますね。

www.youtube.com

Sparkle Xより。このアルバムの中でも好きなほうの曲です。怪しくて渋くて格好よかったです。

www.youtube.com

とにかく格好いい。そう思いながら聴いていました。こういうギラギラした曲いいですね。

www.youtube.com

Sparkle Xより。これもいい曲です。歌詞も素晴らしいです。楽器隊のソロが続いてその後にこの曲のイントロになって…という流れが非常によかったです。

www.youtube.com

終わりのほうで演奏された曲です。このツアーでは前述のように2つのアルバムをとりあげているのですが、だいたい1曲は他のアルバムの曲が演奏されます。このblockの場合はそれが7thアルバムPUNCH DRUNKARDのタイトル曲でした。

この曲はドラムソロ、続いてベース、ギター、最後にボーカルという順番で入ってきて全員揃うという構成になっています。アルバムで聞くぶんにも格好いいですが、ライブだと迫力がさらに増していて、大変よかったです。あと演出として、あの頃を彷彿とさせるサングラスをかけてくれたものもよかったですね。

THE YELLOW MONKEY TOUR 2024/25 〜Sparkleの惑星X〜」<FINAL BLOCK>GLION ARENA KOBE

Final Blockはアルバムではなく1996年のツアーの曲とSparkle Xの曲を演奏するというものでした。わたしはそのライブには行っていないし映像も観たことないのですが、非常に楽しめました(セトリ)。ご本人たちは「このblockが一番のお気に入り」と言ってましたが、わたしもこれが一番良かったと思います。以下印象に残った曲です。

www.youtube.com

6thアルバムSICKSの曲です。アルバムにしか入っていない曲ですが、彼らの代表曲の一つで、かつ、壮大な曲です。「いつかはこれをライブで聴きたい」と思っていまして、「final blockでは演るんじゃなかろうか」と根拠のないことを思っていましたが、当たっていました。そして想像をはるかに上回るものが聴けました。冒頭のギターソロから最後まで観客が微動だにできず、最後も拍手すらできないという特異な状況が発生しました。Sihine Onから数えて全ての演奏の中で最高のものだったと思います。

本筋とは関係ないですが、2016年の再結成後はライブ動画などを観るに大人の落ち着きを感じていましたが、Shine Onでの復活以降は何というか狂気を帯びた憑依系のパフォーマンスが増えたように思います。これはうれしい。

www.youtube.com

Sparkle Xに収録されている快作兼怪作です。とにかく色々な意味が込められていて、ダブルミーニングどころか5つくらい意味があるんじゃないかと思います。歌えなかったことと、喉の病気、下ネタ、喉の病気を克服して歌えるようになったことの喜び、喉以外の病気、あと下ネタ、などなど。この曲は吉井さんの怪しい踊りが売りの一つです。見るごとにどんどん怪しさが増してきて、final blockで観たものは完成形ともいえる非常に怪しいものでした。なおこれは、けなしているのではなく誉めています。

ところでこの曲をアルバムで最初に聴いて思い出した曲があります。奇しくも先日B’z presents UNITE #02で共演したB'zの愛のバクダンです。2作に共通するのは非常に明るくポップで爽やかなことです。「ラプソディ」のイントロを聴いた瞬間に「これはTHE YELLOW MONKEYの愛のバクダンだ」と思いました。そして聞けば聞くほど下ネタ要素が全開になってきて頭を抱えて「これは下品な愛のバクダンだ」と思うようになりました。これはけなしているのではなく誉めています。

www.youtube.com

ライブの最後のほうでいきなり「新曲演ります」と言って歌いだしたのがこの「CAT CITY」(上記リンク先の後半あたりで流れる曲)です。アニメの主題歌らしいです。あまりにもこのバンドのイメージからかけ離れた曲で、天国旅行とは別の意味で棒立ちになってしまいました。いいとか悪いとかの評価は単独でシングルを聴いた後にしたいと思います。なお、この曲の後にMCを挟むでもなくSUCK OF LIFEに入ったので、「もしかしてさっきのは幻覚だったのだろうか」と思うほどライブの中でも浮いていました。

終わりに

セルフアンコールということであと4本ライブやるようです。お元気そうで、かつ、意欲があるようでなによりです。応募しているので当たるといいですね。

theyellowmonkeysuper.jp

最後に見返してみると「かっこいい」ばっかり書いていますが、実際かっこよかったです。おわり。