かなり久々のピアノ演奏会への出演 ~ YouTubeとChatGPTフル活用

www.instagram.com

2009年頃にショパンの幻想曲と舟歌を弾いたのが最後で、そこから実に17年ぶりのピアノ演奏会への出演。

かるく振り返り記事をかいておく。

選曲

今回のみやまっくす音楽祭は、入退場含めて10分以内というルールがあるので、だいたい8分前後くらいで弾ける曲を選ぶ必要がある。

自分はショパン以外は練習で飽きてしまうので、必然的にショパンの曲で、まぁまぁ見栄えして弾きごたえもある曲。

あとは、2025のショパンコンクールで4位だった桑原志織さんの演奏は全部聴いてたわけだが、なかでも印象深かったのは2次予選と3次予選の選曲。

www.youtube.com

www.youtube.com

ただ、8分前後の曲というのは意外と少なくて、舟歌、英雄ポロネーズ、スケルツォ第3番の3つくらいだ。

舟歌と英雄ポロネーズはどちらも過去にステージで弾いたことがあるので、となると...スケルツォかなと。

この曲は一般市民への知名度はほとんど高くないが、意外と過去にもショパンコンクールの演奏者による音源がYouTubeにたくさん上がっている。

桑原志織さんの演奏はこれ以上の素晴らしい呼吸の取り方があるかと思うくらいに自然で美しい演奏なわけだが、他の演奏者でもKate Liuさんの何かが憑依したように思える特徴的な演奏もおもしろい。

というわけでこれに決定。応募した。

練習はできるが、うまく聞かせるにはどうするか...

ショパンの曲あるあるだが、弾くのはべつに音大生のような超絶技巧ができなくても弾けるが、聴かせるのが難しい。(それが楽しい)

過去の話だが、大学生のときにも誰に習っていたわけでもないので練習で一番苦労したのはそこだ。内面的な心の癒しをショパン自身が求めている要素が強い後期の作品はまだいいのだが、自分にとって難しいのはむしろ中期くらいの、一番ショパンがノリノリでかつ浮き沈みがあった時代の作品たち。今回のスケルツォ3番もそのうちの一つだ。

ただ、昔にはできなくて今にはできることが2つある。

1つめ。「わからないことはChatGPTにきいてみよう!」

聞いてみるとこんな感じのものが出てきた。

あってるかどうかはともかく、解釈の仕方として参考にはなる。

2つめ。「公開レッスンの動画をYouTubeでみてみよう」

ショパンの曲で音大生が弾くような曲であれば、だいたいその公開レッスンの動画がある。

www.youtube.com

ほかにもこういうの もあったりする。

マレイ・ペライアの動画はフレーズの取り方とか全体構成を考えるうえで、かなり参考になった。

家には電子ピアノしかないので...

さすがにグランドピアノをぶっつけ本番で弾くのはこわすぎる。本番の3週間前くらいから、福岡市内やその周辺のストリートピアノでタッチの違うピアノを何種類か触って、ピアノによって変えないといけない点はどこかを探ってみたり、

studio.ems-fukuoka.com

天神のほうにあるグランドピアノ弾けるレンタルスペースを借りて、YAMAHAの(ストリートピアノよりも格段に良く調律された)グランドピアノでソフトペダルを使うべき場所を片っ端から調整&楽譜にメモして、

なるべく家に実際のピアノがないことで起きそうな問題を事前に解消しておいた。

KAWAIとYAMAHAではタッチが結構違うので、完全な事前調整まではできないなりにも、これらはやっておいて本当によかった。

リハーサルの10分の使い方

カワイのグランドピアノというのはShigeru Kawaiシリーズふくめて、少々くせがある。ショパンのスケルツォ3番では、ソフトペダルを踏むべきかどうかが、ピアノによって判断が割れる箇所が3箇所くらいあった。8分ほどの曲なのだけど、リハーサルとして割り当てられた時間は10分。通しで弾いていてはあまり十分なチューニングができなさそうだ。

ということで、ここでもChatGPTに聞いてみたw

何度かためしたが、概ね想定通りの返しが来た。

この辺のアドバイスについては、ああなるほどなって感じ。ただ、それでもしっくり来なくて、結局のところ、3年くらい練習してて弾き慣れているショパンのスケルツォ4番を前半に少し盛り込んで、後半でスケルツォ3番の抜粋で調整をかけるという方針でいくことにした。

リハーサルのリハーサルでだいたい9:55くらいに収まるところまで家で調整をして、リハーサルもほぼほぼ10分ぴったりくらいでそこそこフィードバックを感じつつ終えた。

本番前はひたすら脱力

この舞台袖というのは学生で特にコンクールの場とかであればそんなに自由はないというか、ここも含めて見られているんじゃないかというプレッシャーが感じられる場所なのだが、17年ぶりに演奏会に出てみたらそこは結構違った。

そもそもで日頃からストリートピアノで何度か練習していたこともあり、人前で弾くことの緊張感はゼロ。「ああ、たくさんの観客だ、どうもー」くらい気楽にいけた。あとは、演奏会だと結構自由で、あまりに冷房が寒いので少しだけ外に出させてもら立ったり、立って歩くくらいなら許される感じだった。なので、今回はひたすら手の体操, 特に脱力をやって過ごした。

本番どうだったか

結論から言うと、実は結構失敗した。特に焦って弾いたわけでもないのだけど、速く弾きすぎてリズム感がコントロールできてなくて焦っているように聴こえる、という印象が強めの演奏になってしまった。ほとんどの人には別に気にならなかったらしい(むしろ速く弾いてる部分が技巧的に見えたらしい)が、こういうのは自分が思い通りに弾けたかどうかが一番大事なのである。

あとからリハーサル時の動画も見返してみると、どうもリハーサル時からそのような傾向があり、おそらくピアノが想像よりも遥かに軽々弾けることで突っ走ってしまう部分が出てしまったんだろう。

ただ、中間部の比較的ゆったりめな部分は、練習のときに結構テンポが不自然になりやすくて苦労してたんだけど、本番ではちょうどいい具合に弾けた。メゾピアノ以下の音量域の広さは流石にカワイの最高峰ピアノだけあって綺麗だった。逆にフォルテ以上が、しっかり表現をねちっこくやらないと、全部同じに聴こえてしまう(これはどちらかというとカワイのピアノではなく、みやまっくすのホールの設計によるところが大きそう)というのが攻略できず、やや単調な表現になってしまったかもしれない。

総じて、ド素人が17年ぶりに弾いてみたという前提ではいい演奏だったんだろうけど、演奏会でショパンを聴かせるという観点ではまだまだ改善の余地がたくさんある、そんな演奏であった。

まとめ

電子ピアノしかなくても、音大卒/ピアニストが本業じゃなくても、工夫しつつ1日1~2時間練習を重ねてピアノ慣れしておけば、演奏会でそこそこに弾くことはできるというのは今回でわかったので、またチャレンジしてみようと思う。

OpenAI Codexのおかげで、数時間でPyTestのFixturesをRubyに持ち込めた

2年くらい前に、「PyTestのFixturesみたいなのがRubyにあったらいいんだけどなー」と思ってsmartestというテストランナーを試作してたのだけど、時間もなくまともなAIもなく、結局リポジトリを作って数ファイルコミットして中途半端に何も出来上がっていない状態になっていた。

そもそも当時なんで独自のテストランナーが欲しくなったかと言うと、きっかけはPlaywright Test Runnerの紹介動画だ。

自動文字起こしのトランスクリプトだとこのように説明されている。

the big question is why did we create another yet another testing framework and honestly we did not want to um we tried them all. We tried Mocha, we tried the jest and the but it turned out that none of them really worked for us. And I think that the reason is that historically JavaScript test frameworks were built for unit testing but end to end testing has this unique set of challenges and we actually built playright test to address these challenges. So what are these challenges? Things like for example out of the box cross browser support. You don't need to set up any plugins or do any mess with the configuration. It just works. Parallelization for example, well, [clears throat] we know how to run things and how to reuse things in browser efficiently. So, we can run things really fast and so do isolation. Like in unit tests, you usually do isolation on the NodeJS side. And we can and we have to isolate test inside the browser. And there are way better ways to isolate things in browser. And uh last but not least, we actually want to have a crazy level of flexibility for our end to end tests and we were really impressed by pytest fixtures and we didn't see anything like that in JavaScript world. So we implemented these ideas of uh fixtures in JavaScript and in form of playright test.

雑に要約すると、

  • Playwrightテストは、べつに作りたくて作ったわけではなく、既存の単体テスト用のテストランナーではまったくフィットしなかったのでE2Eテストに特化したものを作ることにした。
  • PyTestのフィクスチャに感銘を受けて、既存のJavaScriptテストランナーでそれを実装したものがなかったので取り入れた

と説明されている。ちなみに2026年現在においてはVitestのcontextがあるが、これはPlaywrightが由来っぽいことが明記されている。

Test Context | Guide | Vitest

Test Context Inspired by Playwright Fixtures, Vitest's test context allows you to define utils, states, and fixtures that can be used in your tests.

Railsを本業にテストを書いている人は、RSpecもしくはMinitest+Capybaraで不安定なテストを書いている。これはおそらく10年くらい変わっていない。そうなると、このPlaywrightの取り組みはかなりゲームチェンジになるのでは?とおもってテストランナーを作ってみたいと思ったわけだ。

ChatGPTに雑に聞いてみた

2年くらい停滞していたテストランナー開発について、GPT-5.5が登場してさらに賢くなったなーという実感があったので、なんとなくChatGPTに聞いてみた。

  • Vitestのtest-contextやpytestのfixturesのようにブロック引数でフィクスチャを与えるような書き方ができる
  • describeやcontextを必須とせずトップレベルでテストを書ける

あたりの機能性のあるテストライブラリがほしいよーという内容を、具体的なサンプルコードや機能性を25行くらいインプットしたプロンプト

...

...

...

という感じで、5,6ターンしているうちに概要設計ができあがってきちゃったわけだ。↑の画像には書いていないが、1000行規模のコードで具体的な説明をかなり詳細に書いてくれていて、「あー、たしかにこれならできそうだなー」という実感が強烈に持てた。

ChatGPTに設計書を書かせてOpenAI Codexで実装する

これならできそうだーという実感を持てたところで、ChatGPTにその設計書をアウトプットさせてOpenAI Codex (gpt-5.5 xhigh)で一気に実装させた。

テストランナーが正しく動いていることを確認するテストもそのテストランナーベースで書かせて、ドキュメンテーションサイトもDocusaurusで作らせた。

smartest-rb.vercel.app

さらに、この内容が実現可能な説明になっていることもテストさせるようにした。(AIコーディングの品質担保もだんだん慣れてきたw)

そして、既存テストに影響をあたえずブラウザテストを簡単に書く方法もできあがってしまった

テストフォルダが testやspecだとMinitestやRSpecと衝突して、既存テストのconfigを変えないと導入できないので不都合だ。そうならないように、自動ロードされるテストフォルダは ライブラリ名と同じ smartest/ 配下に限定し、テストの実行コマンドも bundle exec smartest path/to/test.rb のようなコマンドを用意して、Playwright testくらいお手軽にブラウザテストを書けるテストランナーができてしまった!!

smartest-rb.vercel.app

おそらくここまでの制作時間は通算4時間くらい。

image

我ながら、これは結構最高な使い勝手と言えそう。

Google検索で出るようにするのもChatGPTに頼るとよさそう

PyTestのRuby版として認知させようとしても "pytest fixtures ruby" などのGoogle検索で出るようにするにはコツがいる。

...

AI自身にも検索させて「出ませんねぇ」とわからせたうえで、今回のライブラリの存在をわからせて

最後に「これどうやったら検索結果に出るようになるん?」と聞けば、いろいろ対策を教えてくれた。

改善項目が12個出されてきたので、それをfeedback.mdっていうファイルに書き出させて、それをOpenAI Codexとともに解消していくと、1日後には検索結果にAI要約でsmartestが出るようになった!!

今は、 "smartest rubygems" で↓のサイトが出ないのに対応をしていたりもする。

rubygems.org

smarter_csvという別のGemが検索結果に出てきているし、もしかして "smarter_csv rubygems" と言われている。これが数日後にはどうなるかな...

キーワードの取り合い的な攻めたSEOだと専門家に頼む必要はあるのかもわからんけど、検索結果に出ないのを出るようにしたいだけならChatGPTに聞けば十分ということが改めてわかってしまったのであった...。

AIエージェントで言語の壁は崩せる

以前にデブサミ2025でこんな話をしたのだけど、

現在においてはAIエージェントのコーディングのおかげで、他言語のフレームワークのエッセンスを自分が使っている言語のフレームワークに取り入れることは非常に容易になった。

Ruby on Railsの代替フレームワークが出てきたとて既存のRailsで作っちゃった製品はそう簡単に移行できないので、他の言語のいいところをRubyに取り込むのは結構アリだなと改めて思ったのであった。

画面操作仕様をAIエージェントと一緒に考えるなら、FigmaよりもAstro+HTML+CSSが最高なのでは説

まえおき

最近、思い立ったスマホアプリのUI設計とか機能設計とかをClaude Codeでいろいろ試している。

ちょっと前までは、FigmaとかSketchとかで画面イメージを作ってからそれをAIエージェントになんとか読ませて実装する、という流れでやっていたわけだけど、なんかそろそろpencil.devみたいなイケイケツールも出てきたくらいだからAIエージェントと壁打ちしながらUI/UX設計をやりたいものだ。

FigmaのMCPを使うとできるのか?とかも考えていたが、なんかどうもしっくり来なかった。

AIに図を書かせるならHTMLが意外といいらしい

少し前に仕事でドキュメントをClaudeとChatGPTに書かせていたときの話。

Markdownベースで提案書を書いていく中で、

  • 業務フローの概要説明
  • メリットデメリットをいらすとやの絵も効果的に使って挿絵
  • GitHubフローの概念説明

みたいな図をラクして描けないかなぁと考えていたことがある。

GeminiのNano Bananaもだいぶ良くなってきたとはいえまだ「いかにもGeminiで作ったな」って感じの図なので微妙。SVGを生成させるか、Mermaidか、MCPで何かできるのか、 などいろいろ調べていたときに、たまたまこの記事を見つけた↓

tech-lab.sios.jp

そうか、iframeでHTML+CSSで図を描かせたらいいのか!と。確かにこの方法は速くて割と的確な図を描いてくれる。

言うなれば、 AIエージェントの思考回路をアウトプットするのに、HTML+CSSはとても素直な表現手段たりえる ということだ。

デザインシステムを食わせると、いい感じのドキュメント、いい感じの図になる

横道をさらにそれるが、Markdown形式でドキュメントを書かせていること自体にも疑問を持つようになった。AIエージェントが素直に表現できるのがHTMLなのであれば、それよりも表現能力の低いMarkdownをアウトプットしてPDFにする意味なくね?と。

そして、企画の提案書をAstro+HTMLで作らせてみると、意外とこれがいい感じだった。ただ、図のトーンや文書のトーンは、何も指示しないとBootstrapぽくなってみたり、謎の立体的な図がいっぱいになったりするので、流石にここはどうにかしたい。

◯◯のサイトみたいに、って指示を最初は使ってたけど、それはすなわちデザインシステムを指示してるわけなので、

note.com

こういうサイトから取ってきて、デザインシステムのコンポーネントのサイトURLをペタっとプロンプトに貼って、AIエージェントに指示すれば、だいぶ見た目がいい感じになる。

スマホアプリの画面操作仕様だって同じ

今回あらためて、

  • HTML+CSSでUIを書かせて, iframeでそれをそのまま埋め込む
  • 画面イメージの図はMaterial 3 webのコンポーネントで、ドキュメンテーション自体はAtlassianデザインシステムで、Astro製のドキュメンテーションサイトを作るように指示

ということを画面操作仕様でやってみると、これが思っていたよりだいぶ良かった。

何がよかったって、

画面操作を検討するときに、実際にUIがそのまま動くのだ。フロントエンド開発のStorybookみたいなもんではあるのだけど、コンポーネント単位ではなく画面操作単位でそういうことができる。

今までのやり方だと

  • Sketchで画面を作る
  • AIエージェント向けにドキュメントや長大なプロンプトを書く
  • AIエージェントに実装してもらう

だったので、画面を動かして試せるのは実装が終わった後になるので、実装指示が悪かったりすると全然UI議論に行き着かないというのが大きな問題としてあった。画面操作仕様をHTMLで書かせる今回のやり方なら、いわゆる前工程で画面のUIの壁打ちができるので、とても効率が良い。雰囲気だけで言うと、ProttってサービスがAIネイティブになった感じ。

UIの壁打ちのみならず、チューニングもできる

ちらっと書いた通り、このHTML+CSSで画面仕様を出すというのは、単なる利便性と言うよりは、 AIが考えていることを正確に効率よくアウトプット している側面が大きい。なので人間が考えることをより支援して、より正確にフィードバックが行える可能性を示唆している。

今回作ろうとしているアプリは、ドキュメントスキャナーのアプリなので、台形補正だったり画像の補正アルゴリズムあたりが大事だ。

いろんなパターンの画像でうまくできているかを、1こ1こ開くのはとても大変なので、こんな感じでサイトでそれぞれのstepの成果物を展示するようにしておくと、アプリの複雑な実装を入れる前に、macOSのOpenCVベースでどういう処理をするとどうなる、というのをいろんな画像パターンで見て、計画をかなり綿密にレビューすることができる。

ようするに、画面操作仕様をHTMLにしたことで起きた変化とは..

もともとなんでFigma MCPが微妙だなーと思ってたかというと、このあたりのAIが考えていることがより明確になるなどの実感が皆無だったことだろう。

MarkdownやConfluenceでドキュメントを書いているとき、 Claude Codeにいろいろ考えさせているはずなのに、 その思考の一部しかドキュメントにアウトプットされていない というのが意外と気づくのに時間がかかっていたわけだ。

もちろんMarkdownにも良いところはあって、「人間が読みやすい」というのは最大の利点だ。ただ、やはり百聞は一見にしかずで、テキストで全部を伝えるのはAIでも難しい。壁打ちをするにおいては、AIエージェントが自身の考えを正確に早くアウトプットできる&人間が視覚的に簡単に理解できる方向に寄せたほうが、設計品質は上げることができるだろう。

繰り返しになるが、 AIが考えていることをほぼそのままdumpできる 手段こそ、HTML+CSSなわけだ。

このHTML+CSS / Astroという構成は、Markdownと同様にコンテンツはテキストベースなので、GitHubで同一のリポジトリで管理することは容易だ。仕様とUIが分離しないよう、ドキュメントと実装を行き来することも簡単にできるし、ドキュメンテーションサイトはVercelで簡単にデプロイできるので、他の人にこんなものを作ろうとしていると説明する材料としてもとても有用だ。

ところでこの文章はAIが書いてるの?

ChatGPTにXの投稿を要約させて書いてみました。でも全然だめだったので、結局 YusukeIwaki が手で書いていますw

AIに個人エンジニアブログを代行で書かせるのはまだ少し時代が追いついてないかなという感じする。