2025-12-03 15:14
ポッドキャストを始めるにあたり、まず配信サイトをどうするかという話があり、その辺りについての個人的見解や調査結果をまとめてみる。ポッドキャスト配信に興味がある人の参考になれば幸いです。
ポッドキャストの捉えられ方も多様になってきていますが、ここでは、特定のアプリやサイト内で独占的にしか音声を聴けないものではなく、配信者が様々なメディアに登録できて利用者が無料で利用できるオープンな形式のものを指すこととします。そちらの方が広くリーチしたい場合には効果的でしょう。
メイン配信プラットフォーム選定
大本の配信元をどこにするか。これは、以下の分類になる。ただ、何れのパターンを選ぶにせよ、Spotifyへの登録はお勧めする。(後述)
Spotify が無難。特に企業でやるなら
シェアが大きい
担当者も前提知識少なく始められる
分析機能も見やすい
個人でやるならLISTEN もオススメ
コミュニティ要素が上手く機能している
文字起こしが最初から全てのポッドキャストで有効にできる
エンジニアだったら自前構築もオススメしたい
私の場合、趣味でOSSをやっている者だ 、はPodbardによる自前構築でCloudflare上でホストしている。ヘンリー理想駆動ラジオ はSpotifyだ。
個人的には自前構築を推している。何れのパターンにせよ、最終的には複数媒体に登録することになるので、どこが「ホームページ」なのかが分かりづらくなって分散してしまう問題があるが、自前構築であれば大本のサイトがホームページであることが明確になる。Spotifyをメインにしている場合も、別途ホームページを設けているパターンも見る。
また、プラットフォームの番組画面をホームページにする場合には表現の自由度が低いのも難点。Spotifyだと、概要欄や説明欄のテキストエリアが使いづらい。一応、Spotifyの説明欄にはHTMLを直接記述できるので、私は、Markdownで書いてローカルでHTMLに変換した物をテキストエリアに貼り付けている。
余談だが、自前構築をやりやすくするために作ったOSSがPodbardであり、個人的には満足できる出来になっているが、全然使われていないのが残念。この領域ではYattecastが古くからが人気で数多くのポッドキャストが利用している。Podbardにも後発の強みがあると思っているが、やはり、Yattecastの凄さを改めて感じる。Podbard使いたい方はお知らせ下さい。今なら篤くサポートします。
アートワーク画像の準備
ポッドキャスト番組には、各媒体でアートワーク画像が求められる。媒体ごとに若干指定が異なるが、基本的には正方形のJPG画像であるため、1400x1400 pxの画像を一個用意しておけば使い回ししやすいだろう。画像の作成は、趣味活動であれば生成AIに作らせるのも今ならお手軽だ。
各プラットフォームへの登録
ポッドキャストを始めるまで知らなかったが、リスナーが利用するポッドキャスト媒体は今やSpotifyがトップで、リスナーの1/3程度が利用している。最低限Apple Podcastに登録しておくかと思っていたが、最低限登録するなら今やSpotifyが最優先だ。また、Amazon Music + Audibleも侮れないシェアがある。YouTubeもやった方がよいだろう。
この辺のリサーチについては、オトナル・朝日新聞社が出している、ポッドキャスト国内利用実態調査が参考になる。2024年と2025年でガラッと傾向が変わっているところがあるのも面白い。2025年の調査ではYouTubeが視聴メディアでトップになった。このあたりは「ポッドキャスト」に対する認知や解釈が広がってきたことが影響しているのだと思う。
登録推奨プラットフォーム
上記を踏まえ、以下のプラットフォームへの登録をお勧めする。全て無料で出来て登録も簡単だ。プラットフォーマー的にはコンテンツが増える分には歓迎というのがあるのでしょう。
Spotify
Apple Podcast
Amazon Music
YouTube
LISTEN
何れも、RSSフィードのURLとアートワーク画像を用意しておいて、それぞれにアカウント登録してフォームを適宜埋めて申請すれば、しばらくすればそれぞれの媒体上にラインナップされる。ちなみにYouTubeは「趣味で〜」の場合何故か3ヶ月くらいかかった。
各種プラットフォームに登録すると、それらの管理機能を使えるのも嬉しいポイントだ。例えば、Spotifyのアクセス解析やLISTENの文字起こしなどは個人的に有用だった。Spotifyのアクセス解析はSpotifyをメインにしていないとSpotify経由のものしか取れないが、それでも傾向を見るには十分だ。
ちなみに、複数プラットフォーム登録による難点として「コメント分散問題」というのがあるようだが、残念ながら私はそれには困っていない。
RSSフィードの確認
各種プラットフォームに登録する為にはRSSフィードというやつが必要になる。Spotifyの場合RSSフィードが有効になっているか確認して、そのURLを控えておこう。
あなたのRSSフィード - Spotify
このRSSフィードがあれば特定の媒体に限らず、他のプラットフォームやポッドキャストクライアントで聴いてもらえるので、大事です。
ホームページ / 公式サイト
付随要素ではあるが、ポッドキャストのホームページがあると嬉しい。お知らせや各種リンクをまとめて置く場所は欲しくなる。自前構築であればそこをホームページにできるが、プラットフォーム上で配信している場合には、追加で別に用意することになる。独自ドメインがあると嬉しいが、どこまで凝るかとの兼ね合いではある。
シンプルなリンク集で大体事足りるので、プロフィール作成サイトの利用をよく見かける。具体的には Bento が身の回りでは多い印象です。
また、メルマガサブスクなどで使われるSubstack をほっとテック ではホームページとして使っていて、これはおしゃれだと思う。無料で使えて、独自ドメインも割り当てられる。こういうサービスは一般的には独自ドメインを利用する為には有料プランの継続利用が必要になることが殆どだが、Substackはワンショットの$50で独自ドメイン設定ができる ようなので良心的。ちなみに、ほっとテックの場合はまた別の方法で実現しているようです。
独自ドメインを使った番組サイト・ニュースレター配信の設定 - ほっとテック Newsletter 準備号
ちなみにSubstack自体にもポッドキャスト機能がある ことに今気付きました。
ホームページに何を載せるか
各プラットフォームへの番組リンクの他、以下のような要素が多く見られます。お好みで用意して載せると良いでしょう。
お便りフォーム
公式SNSアカウント
コミュニティ
まとめ
ちゃんとやろうとすると何気に色々用意する物が出てきてしまいますが、興味があれば、まずは最低限パッと始めてみてはどうでしょうか。気が向いた時に後から整えれば良いのです。
例えば、LISTENであれば、アカウント登録と番組登録をして、ブラウザから録音するだけ。何も用意せず、無料ですぐに始められます。LISTENでは声日記 という気軽な音声配信ムーブメントが生まれているのも面白いところです。
「趣味でOSSをやっている者だ」は自前構築でやっていて、Cloudflare でホストしていますが激安なのでほぼお金はかかっていません。独自ドメイン代はかかっていますが、それもオプショナルなものです。なので何れにせよポッドキャストを運営する際には、配信面ではほとんどお金はかかりません。
機材や収録環境、編集などは、お金をかければキリがない世界でもありますが、逆に安く抑える方法もあります。手持ちのスマホだけで追加コスト無しで始めることだってできます。私がどうしているかは、以下を参考にしてみてください。
2025-12-01 00:18
趣味でOSSをやっている者だ というポッドキャストを始めて1年が経った。そのノウハウを横展開して、ヘンリー社でもヘンリー理想駆動ラジオ というポッドキャストを始め、運営に関わっている。
怠惰な自分でも続けられるように省力運営志向で、特に編集には時間をかけたくない。ただ、それなりの音声クオリティは保ちたい。それを自分なりにOKなラインになるように各種ツールを組み合わせて運用している。
ポッドキャストを始めてから大きくツール構成を変えたわけではなく、Ossan.fm の @nagayama さんに相談して教えてもらった内容をベースにしている。大感謝。その辺りの話は、1: 秋はポッドキャストの季節 (nagayama) 、 2: 令和最新版ポッドキャストの始め方 (nagayama) でも話しているので興味があれば聞いてみて欲しい。
今は、収録を終えてからスムースにいけば15分程度で、公開用の音声ファイルを作成できている。その辺りの話を書いてみたい。マイクなどのハード周りの話は前回の、「リーズナブルに整えるオンラインミーティング向けマイク環境 」で書いたので、今回は収録から音声ファイル作成までのソフトウェア関連の話が中心です。
大事なポイント
話者毎のマルチトラック収録
AI自動編集ツールへの丸投げ
Auphonicは、nagayamaさんに聞くまで知らなかったが、Rebuildでも使われている 、ポッドキャスト編集ではメジャーなツールのようだ。これがなかったら私もポッドキャストを続けられなかったと思う。
話者毎のマルチトラック収録 (Riverside)
使い慣れたGoogle MeetやZoomなどで収録する方法はお手軽だが、そのままだと単独音声ファイル取得のみで、話者毎に分離された音声ファイルが得られない。これは、その後の編集が不便になり、特に、話者毎に声の大きさの差が大きい場合に声の大きさを揃えるレベル調整がやりづらかったり、ノイズ除去を個別にかけづらいのが難点だ。なので、ここは最低限、話者毎に分離された音声ファイルを入手したい。
やる方法はいくつかあるが、私はそれができる収録ツールに丸投げしていて、それがRiverside 。Ossanfmでも使われている。
良くあるオンラインミーティングツールのようにブラウザから利用でき、ゲストはユーザー登録せずとも招待リンクから参加できるので負担が少ない。収録ボタンを押して開始すれば、話者毎に音声が録音されてリアルタイムに非同期でアップロードされる。収録が終わったら、話者それぞれの音声ファイルをダウンロードできる。
話者毎にロスレス音源(wavファイル)が取得できるが、頭出し音源 (aligned audio) としても取得でき、途中参加者がいても編集しやすいのも嬉しいポイントだ。
注意事項
Riverside側の遅延や利用者側の環境の問題などによって動作不安定になったり、無料プランではマルチトラックのロスレス音源は取得できないなどの制約はあるが、特に気にはしていない。
動作が不安定になり利用者が途中で落ちた場合でも、復帰すればRiverside側が音声アップロードのレジューム含めて適切にハンドリングしてくれるので、今のところ大きな事故になったことはない。心配ならバックアップとして参加者それぞれが手元でQuicTimeなどでローカル録音するのが万全だとは思う。
あと、デフォルトではビデオも録画されて転送量が凄いことになるので、画面が必要ないなら音声のみ録音して転送する設定にすると良い。
プランについては素直に年間$180のStandardプランを契約している。ただ、現在はStandardプランは新規契約できず、年間$288(もしくは月間$29)のProプランがミニマムの有料プランになるので、個人では少し悩む金額感だ。ただ、ProプランだとAI編集機能などが使えるようなので、その機能次第ではAuphonicを使わずに済む可能性もあり検討の余地はあるかもしれない。
また、Spotifyでポッドキャストを配信している番組も多いが、RiversideはSpotifyと提携し、統合された収録ツールとして利用できる点でも有力な選択肢になる。
代替サービスやツール
同様のサービスではzencastr が古くからの定番で、RebuildはCleanfeed を使っているようだ。また、StreamYard を勉強会やイベント配信用に契約していて、それをポッドキャスト収録でも流用している企業もあるようです。
また、有力な変わり種として、Craig というDiscordボットを使う手もある。Discordの音声チャットにボットを招待して音声を録音してもらうものだ。これは無料でマルチトラック録音ができるので使っているポッドキャストも多い。例えば、Yokohama North AM や readline.fm など。
ちなみに、Zoomも参加者毎の音声を個別録音できるオプションがあることを、@tsueeemura さんに教えてもらいました 。ロスレス音源ではないAACであることや、無料の場合には40分制限がかかるが、それを許容できるなら悪くない選択肢かも知れない。
また、CraigやZoomの場合はローカル録音された物がアップロードされるわけではなく、圧縮・伝送された音声をサーバーやボット側で録音する形式になるので、多少は音質が落ちていることは留意が必要だ。
何にせよ参加者毎にマルチトラック録音できてロスレスに近い音源が取得できれば、あとは使いやすいツールを使えば良い。それぞれが同時にローカル録音する方法もお手軽ではあるが、頭出しの手間が少しかかるし、録音ボタン押し忘れ等による録音失敗トラブルも聞くので注意。ローカル録音含めて冗長録音している番組もあるようで、ちゃんとやりたいならそうした方が良いのだとは思う。
AI自動編集ツールへの丸投げ (Auphonic)
とにかくAuphonic が素晴らしい。Auphoicは正確にはポストプロダクションツールで、音声ファイルを作る最後の工程を自動化してくれるツール。本来は収録した音声を手で編集した後に最後にかけるものだが、レベル調整、無音部分やノイズ、咳払い除去などを自動処理してくれるAI編集機能があり、私は自分で編集は基本行わず、横着してそれに丸投げするスタイルを取っている。
乱暴なスタイルだが、それで自分的には全然許容できる音質もののになっている。同様のスタイルを取るポッドキャストも増えてきている印象。
具体的には、Multitrack Productionの画面のフォームからRiversideで収録した音声ファイルを人数分アップロードし、設定のプリセットを選んでサブミットするだけで、しばらく待てば音声ファイルが書き出される。1時間分の収録音声の処理が順調に行けば10分程度で終わってしまう。
具体的なプリセット設定は以下のような具合。書き出しは96kpbsのモノラルのMP3にしている。モノラルなので各トラックの設定は同じにしている。
ちなみに、ファイル書き出し品質は年々向上傾向で、Podcast standardの統計 を見ると、今は128kbpsのステレオが多数派になっているようだ。
wavをflacに変換してサイズを圧縮するtips
音声ファイルをAuphonicにアップロードする際に、wavファイルを直接アップロードすると、結構時間がかかることがあるので、ロスレス圧縮音源のflacに変換してからアップロードすることをお勧めする。声だけの音源だと5倍程度サイズが小さくなるので、比例してアップロード時間が短くなる。つまり1分が10秒そこそこになる。私は以下のような雑なシェルスクリプトでディレクトリ内のwavをflacに一括変換している。
#!/bin/sh
set -ex
for i in *.wav; do
ffmpeg -i "$i" "${i%.*}.flac"
rm "$i"
done
料金プラン
https://auphonic.com/pricing
月々のプランよりも無期限の"One-Time Credits" をまとめて買っておく方が、趣味ポッドキャスターの場合はお得だと @nagayama さんに教えてもらって、100時間分を$150で購入した。月々のプランだと、一番安いSプランで月額$11。それで9時間分の処理ができるが、一ヶ月に9時間も収録しないのでワンタイムの方がお得になる。
まだ出来ていない活用
AuphonicにはAPI や、Google DriveやDropboxなどのクラウドストレージとの連携機能もあるため、その辺りを組み合わせたら、収録終了をトリガにしてプロダクション音源を自動的に書き出して配置してくれるなどもできそう。ただ、今の手動フローでも十分に短時間で済んでいるし、収録語に音源の微調整が必要になることもあるため、やっていない。
また、Intro/Outroを自動的に繋げてくれる機能は試したいとは思っている。特に、番組購読のお願いやお便りフォームの案内などは固定音声を作ってしまってoutroで繋げてしまえば良いよなーと思いつつ幾星霜。
その他のツール
手動での音声編集が必要になった場合 (ffmpeg, Audacity)
収録トラブルなどで、複数の音声ファイルを繋げたり重ね合わせたり、一部カットしたりする必要が出てきた場合には、機械的な処理であれば ffmpeg を使い、確認しながらのカット等が必要になれば、Audacity を使っている。無料で使える定番。
ffmpegはオプションが複雑で難解だが、今なら使い方をChatGPTに聞けば大体いい感じに教えてくれるので便利。Audacityは無料なのでありがたいが、Mac上で使う分にはちょっとUIに癖があるので、もう少し手ごろな良いツールがあれば乗り換えたいが、プロユースの物は高額だし複雑すぎて逆に使いこなせなさそうなので手を出していない。
ローカルでのノイズ除去 (krisp)
ポッドキャスト収録に限らず、オンラインミーティングなどでも活用できるので一応ローカルノイズ除去の krisp を契約している。年間$96。
据置のコンデンサマイクに切り替え て、打鍵ノイズなども少し気になったので、導入し始めたが、最近は各種オンラインミーティングツールにノイズ除去が搭載されることも多くなってきたので、必要なくなってきているかも。ノイズ除去が複数レイヤーで重複して施されて、薄っぺらい音声になったりしてそうだが、今のところ気にしていない。
AI文字おこし (Notta)
公開用の音声ファイルが出来た後、一応音声ファイルをひと通り聞いて内容確認しながらチャプター付けや公開用Show Notes作りをしている。それを楽にするために、AI文字起こしサービス Notta のプレミアムプランを契約している。年間14,220円。
公開音声をNotta上にアップロードして文字おこししてもらい、文字起こしを見ながら倍速再生で内容を確認している。文字起こしの精度はヒントなどをちゃんと与えているわけでもないのでそれほど高くはないが、文字起こしをクリックして再生位置ジャンプができたり、キーワードを拾ったりできて便利。
MP3へのチャプター付け自体は、拙作のポッドキャスト配信ツールである、podbard にその機能を持たせている。またその機能を切り出した別のOSSとしとして chape というものがあり、これはvim等のエディタでポッドキャストの音声ファイルにチャプターやその他メタデータを付与できるので便利です。
ちなみに、連携しているLISTEN の文字起こし精度がNottaとも遜色がなく、UI的にも文字起こしを確認しながらチャプター付けをするのにも向いていそうだが、公開前に内容確認をしたい関係でNottaを使っている。実はLISTENでも非公開音源の文字起こしができそうで、それをやりくりする方法もありそうだが、それは流石にabuseだと思うのでやらない。LISTENはLISTEN内でホストされている以外の連携ポッドキャストも無料で文字起こしできるのは大分太っ腹だと思う。
また、チャプター付けについては Forecast というMac用のツールもあり、これを使っている人もまま見ます。Overcast と開発元が同じなので信頼感はある。
まとめ
ということで、ポッドキャストの収録から編集済み音声ファイル作成までの流れをまとめてみた。ちょっとくらいの金額だったらお金を使って楽をする方針だけど、なんだかんだで積み重なって、この部分だけでも年間7万円くらいお金がかかっていることが判明してしまった。
気が向いたら、以下のようなことについてもまとめたい。
ゲストアサインや収録の様子
配信プラットフォーム選定やポッドキャスト開始時にやった方が良いこと
2025-11-21 17:30
今年のYAPCは、前日入りして全日程堪能し、会期翌日の日曜日もホテルに留まり、月曜日に帰る満喫プランで楽しんだ。
2日開催の充実の内容となりましたが、今回も素晴らしいカンファレンスでした。関係の皆様は本当にお疲れさまでした。ありがとうございました。2日開催なので、トーク本数も充実していながら、質疑応答の時間やトーク間の休憩時間もゆったりと取られていて良かった。
話してきた
トークを採択していただいたので、k1LoW/deck への貢献に関する話をしてきた。今年後半はdeckの開発に熱狂していたので、その総括的な内容。
OSS開発への貢献をどのように始めたか、どのように機能追加やパフォーマンスチューニングをしたか、一般的なパフォーマンスチューニングの心得という構成で、いつもの私のYAPCトークらしく盛りだくさんとなった。面白い発表になったと思う。「面白かったです」という感想もいただけて嬉しかった。パフォーマンスチューニングの話は別途切り出してどこかで話したいとも思ったりもしている。
個人的に、仕事もOSS活動もソフトウェアエンジニアリングもここ数年色々中途半端だったと感じる部分もあったのだけど、deckの開発を通してソフトウェアエンジニアとしての自信を取り戻せたと感じているので、その点でもk1LoWさんには感謝している。
LTしてきた
実はYAPCでLTするのは12年ぶり2回目。LTの方が慣れてないので少し緊張した。内容は x-moteme/ghq について。YAPC::Fukuoka 2025のテーマが"Q"だったので、ghqの話はしたいと思ったので応募して、採択されて良かった。時間通りに話せて良かった。
考えてみたら、deckとghqの話をしてきたので、両方とも他人の褌でしたね。
ポッドキャスト出た
ポッドキャストほっとテック のYAPC::Fukuoka 現地ゲスト特別会 Day2 に少し出演させてもらいました。LTで話す直前の短い合間の時間を縫っての出演でしたが、ちょうどLTの緊張を紛らわすこともできて良かった。パーソナリティの一人の @youhei さんとも初めて対面でお会いできて嬉しかった。
#342 YAPC::Fukuoka 現地ゲスト特別回 Day2 by ほっとテック
YAPC::Fukuoka の感想、ほっとテック3周年について話しました
Read on Substack 「踊り場」で話した
YAPC::Fukuoka 2025のタイムテーブルにある「踊り場」とは何なのか #yapcjapan踊り場 #yapcjapan - YAPC::Japan 運営ブログ
今回「踊り場」という、ランダムな企画セッションを行うスペースがあり、そこでも結構話した。スペースの前にいる人だけではなく、参加者も含めてわいわいディスカッションする雰囲気で良かった。全体的に見切り発車かつ、ホストに丸投げの企画ばかりだったのが、逆に"セッション"的なグルーヴ感やインタラクティブ感を生み出していて面白かった。ホストアサインの妙もあったと思う。
"OSS開発者なら学生たくさん連れてこれる説" という謎セッションでは @moznion 司会の元、 @yusukebe, @fujiwara, @pyama, @gosukenator という豪華メンバーと一緒に前でお話できて良かった。学生が不思議と20人前後集まってくれ、色々疑問や質問を挙げてくれて、交流できたのは良かった。
トークを聞いた
トークも色々聞いて、どれも面白かった。
山澤教授のゲストトークは、大学教育におけるAI活用や学生のAI利用の実態などを聞けてかなり面白かった。普段なかなか聞けないこういった話をYAPCで聞ける機会を提供してもらえるのは貴重。非公開トークではあるが、懇親会で教授にお話しさせてもらった感じ、何らかの形で公開される可能性も少しはありそうだったので期待。
大学における人工知能関連の教育について
あとは、@sugyan のトークも良かった。AI時代でも、プログラミング自体の楽しさは忘れないように、失われずあって欲しいと改めて思う。
やり方は一つだけじゃない、正解だけを目指さず寄り道やその先まで自分流に楽しむ趣味プログラミングの探求 2025-11-15 YAPC::Fukuoka
交流した
YAPCと言えば、同窓会的な感じで旧交を温められるのも楽しいし、最近は新しい人も参加して新陳代謝が進んでいるのも良いことだと思う。学生支援があるのとても良い。
あと、スポンサーにサンリオ社が名を連ねていることに何となく嬉しさを感じていて、ツイートなどもしていた。
サンリオ社がスポンサーしている理由も知りたいと思っていたが、exはてな仲間の @kurain さんがエンジニアリングマネージャーとして働いていることが理由だったようで、思わぬ縁があって面白かった。@kurain さんとはLT登壇で隣で、そこで交流もできて良かった。
あとは、DELTA社の @hirata_4 さんが最終日の後に少人数の飲み会を企画してくれて、そこで新しい出会いがあって嬉しかった。LTされていた @nukumaro22 さんや、YAMAP CTOの @higuhey さんなど。ここはちょっとイツメンとは違う交流の場に行けて良かった。
趣味でOSSをやっている者だ を聞いて下さっている方からのお声掛けもそこそこあって嬉しかった。
YAPCは一年間で一番楽しみなイベント
YAPCは一年で一番楽しみにしているイベントだなぁと改めて思った。来年は東京でビッグサイト開催ということでとても楽しみにしています。発表したい！
キーノートスピーカーとのポッドキャスト収録
前回のYAPC::Hakodateの後にもキーノートスピーカーの @moznion さんにポッドキャストのゲストに来てもらったのだけど、今回も同様にキーノートスピーカーの @pyama86 さんに来てもらって収録したので、是非聞いて下さい。
63: Stay Hacker (pyama86)
2025-09-21 23:59
ポッドキャスト「趣味でOSSをやっている者だ 」 を1年くらい続けてきたので、今のマイク環境について書いてみようと思う。あまり大げさな機材を使わず、リーズナブルでコンパクトな構成を志向している。なので、普通の人のリモート会議用にも使える構成だと思うので、参考にしてもらえると嬉しい。
現在のマイク周りは以下のようになっている。これはデスクの左側の壁の様子で、この右側にPCやモニターがある。
マイク - JBL QUQNTUM STREAM
マイクは JBL QUANTUM STREAM。USB接続できるコンデンサマイクで、本体は缶コーヒーを一回り大きくしたくらいにコンパクト。ゲーム配信者なども使っているモデルで信頼度も高く、実際音質も悪くない。あとは、サイドトーン機能という、マイクにモニターヘッドフォンを挿して自分の音声を聞きながら収録できる機能も備えている。これが1万円程度で買えるのは破格。
ただ、コンデンサマイクなので、指向性の調整はできるものの、ノイズはやや入りがちになる。声の収録であればダイナミックマイクを使った方がクリアにはなる。ただ、ダイナミックマイクはその構造上、しっかりマイクに向かって発話する必要があり、顔が別の方向を向いているときなどは音が極端に小さくなってしまう。これは画面を色々見ながら話すには不都合があった。
実際、以前は定番のSHURE MV7というダイナミックマイクを使っていたが、自分の話し方では完全に宝の持ち腐れとなり、今のマイクに落ち着いた。ちなみに、SHURE MV7+ という後継機種は、USB直接接続で音が小さくなりがちだった前モデルの問題を改善しているようだ。実際それを使っている方と一緒に収録したときも問題はなかった。ダイナミックマイクで収録した音声は、レベル調整をかけてもクリアさがキープされやすいのは良い点だと思う。
このJBL QUANTUM STREAMも、普通の人が使う分にはこれを買うだけで十分だと思う。コンパクトで場所を取らないし、USB接続で手軽に使えるのは大きい。
ノイズ対策
ポッドキャストをやる中で少しづつノイズ対策を整えていった。効果はそれぞれ少しかもしれないが、簡単にできることはやっていく、という感じだ。
まずは、ソフトウェア的に Krisp を使っている。これは定番だと思うが、最近のリモート会議システムはノイズキャンセリング機能も備えていることも増えてきたのでそれで十分かも知れない。
ハードウェア的には、ポップガードとショックマウントを導入した。
このショックマウントは、そのままだとマイクのUSB穴に干渉してしまったので、少しヤスリで削って以下のように取り付けた。サイズ的にはそれ以外はぴったりでコンパクトさをキープできて良かった。
ショックマウントはモニタリングヘッドフォンを初めて付けたときに、デスクの振動や手を置いた音などがマイクに地味に入っていることに気付いて導入したのだが、効果はかなりあった。
設置
マイクアームはデスク周りがごつくなるのを嫌って導入していない。冒頭の写真の通り、メッシュパネルのカゴに取り付けている。マイク位置の調整があまりできないが、これもコンデンサマイクなのでアバウトで良いメリットがある。
モニターヘッドフォン
自分の声を聞きながら収録できるようにモニターヘッドフォンも導入した。オーディオテクニカのモニターヘッドフォンラインナップの中で一番廉価なシンプルな以下の製品を選んだ。
著者 :
Audio Technica(オーディオテクニカ)
発売日 :
モニターしながらの収録は趣味の世界になってくるし、好き嫌いや慣れもあると思うが、個人的にはやって良かったと思っている。モニターしないと、人によっては自分の声のゲインが分からない不安から、声を張りすぎて咽に負担をかけてしまうという話もあるようだ。確かにモニターした方が落ち着いて話せる感じはある。ただ、話が盛り上がってくると、モニターしてても自分の声を聞き取ることが疎かになり、自分の声がちゃんと収録できていないことに気付かないこともありました…。
ちなみに、ポッドキャスト収録時はモニターヘッドフォンですが、普段のリモート会議ではShokzの骨伝導イヤフォンにしています。
Shokzの骨伝導イヤホンは会議でも運動でも入浴でもマルチに使えて快適 | おそらくはそれさえも平凡な日々
(余談) リンゴジュース
これも気休め程度だと思うが、収録時の飲み物をリンゴジュースにしています。リンゴのペクチンが唾液の粘り気を減らし、リップノイズを抑える効果があるらしい。僕は一応、プロテインを割って飲む用のリンゴジュースを自宅に常備しているので、それを飲んでいます。
まとめ
今回は、マイク周りについて書きましたが、ポッドキャスト自体どうやってるかなどは別でまとめるかもしれません。
2025-09-05 15:58
GitHubのImmutable Releasesがパブリックプレビューとなりました。ソフトウェアを公開している方は積極的にオンにすると良いでしょう。suzuki-shunsukeさんが早速zennを書かれているので、詳しい解説はそちらに譲ります。
ここでは、Go製のソフトウェアで実行ファイルもリリースされている方の中には、tagpr と goreleaser を組み合わせて使っている方がそれなりにいると思うので、その場合の設定についてお知らせします。
Draftリリースを作り、それを再利用する
これだけです。具体的には以下です。
.tagpr に release = draft 設定を追加する.goreleaser.yml に release.use_existing_draft: true 設定を追加する
例を以下に示します。
# .tagpr
[tagpr]
release = draft
# .goreleaser.yml
release:
use_existing_draft: true
これは、具体的にはtagprが作成するGitHub ReleaseをDraftとして作成し、goreleaserにそのDraft Releaseを再利用させています。
release = draft の設定がないと、tagprが作ったリリースをその後変更できずファイルをアップロードできなくなりますし、 use_existing_draft: true 設定がないと、goreleaserは別でリリースを作ってしまいます。
ということで、tagprとgoreleaserの組み合わせは、すでに、immutable releasers readyになっているので、是非設定を有効にしてみて下さい。
余談
tagpr 地味ながら社会的責任を伴うツールになってきているのを感じているので、これを機にGitHub Actions周りの設定を見直しました。もう少し調整予定です。また、観念してcommit hashでpinするようにもしました。pinact 便利。ちゃんとメンテナンスしていきます。
実行ファイルのリリースについては、個人的には自分がメンテナンスしている ghr を使うことが多く、これは設定なしでドラフトリリースを見つけて再利用してくれる機能を入れており、もともとドラフトリリースを作ってから、ファイルアップロード後に公開するワークフローにしていたので設定変更も必要なかった。
ただ、 ghr 自体のメンテナンスはそこまで活発にしているわけではないので、そこまで薦められる状態にはなっていないと思います。
haya14busaさんが、最近 trusted-go-releaser を含めた、サプライチェーン周りのツールチェインを整えている雰囲気を感じるので期待しています！
2025-08-23 01:11
9/8(月) 追記: ツール名を Chapel から Chape に変更しました
https://github.com/Songmu/chape
ターミナル上でMP3のチャプターやメタデータを編集したくなり、コマンドラインツールを作った。名前の chapeは"chapter editor"を適当にもじった。動作は以下を見て欲しい。
使い方は簡単で以下のように chape コマンドの引数にMP3ファイルを指定するだけ。
# install
% brew install Songmu/tap/chape
# edit metadata in your.mp3
% chape your.mp3
エディタが開き、YAML化されたメタデータが表示される。それを適宜編集して保存・終了すれば、その内容がMP3に書き込まれる。
アートワーク(artwork:)にローカルファイルパスやURLでも指定でき、その内容をMP3に埋め込んでくれる。その他標準的なメタデータにも対応している。詳しくはリポジトリのREADME.md を見て欲しい。
出力されるYAMLにはJSON Schemaコメントを入れてあるので、YAML Language Serverを使っている場合にはプロパティの説明や補完の恩恵が得られる。
参考: 独自YAMLファイルをJSON SchemaでLSP補完する
エディタと反映の仕組み
chape は EDITOR 環境変数で指定されたエディタを起動して、一時ファイルに書き込まれたメタデータのYAMLを開く。その編集プロセスの終了後、YAMLの内容をMP3に反映している。
なので、EDITOR がサーバーモードなどを使っている場合には上手く動かない可能性があります。その場合は CHAPE_EDITOR 環境変数にスタンドアロンなエディタを指定するか、 chape dump サブコマンドでYAMLを出力後編集し、それを chape apply でMP3に反映する等の方法が取れます。
エンジニアのポッドキャスターにはかなり便利だと思うので是非ご利用下さい。
2025-08-16 23:05
7月頭に技術支援先でプレゼンをする機会があり、いつもの僕の雑なHTMLプレゼンではなくて、ちゃんとしたプレゼンフォーマットにしたいと考えて、 k1LoW/deck を使い始めた。MarkdownをソースとしてGoogleスライドを生成できるツールだ。
GitHub - k1LoW/deck: deck is a tool for creating deck using Markdown and Google Slides.
良かった点
これまで15年以上主にMarkdownからプレゼンテーションを作るスタイルでやってきたので、乗り換えやすかった。
使い始めた6月時点で、上記の紹介エントリーからさらに進化を遂げており。感動的に体験が良かった。特に以下の機能が良かった。
--watch オプションでのファイル更新検知と自動適用画像やコードブロック画像の自動配置
一部のインライン要素のスタイル適用
おかげで、7月頭のプレゼンを乗り切ることができた。
改善の余地を感じた点
同時に、以下の点に改善の余地を感じた。まあ、私自身がMarkdown, HTMLに対して一家言ある往年のWeb標準厨的であることや、いきなり130ページ・画像20枚のスライドを作ったことが問題だったのだが。
Markdown内にFrontmatterを書きたかった
私の既存のプレゼンソースのMarkdownにはFrontmatterにメタ情報を記述していた
ここにプレゼン用のメタ情報を入れられるようにしたかった
パフォーマンス
130ページ・画像20枚のスライドだと生成に12,3分かかった
不十分なMarkdown対応
パラグラフ分割・改行の扱いが不正確で、段落分けができなかった
作者のk1LoWさんのユースケース的には箇条書きがちゃんと表示されるだけで十分だったのだろう
生のインラインタグ (<cite>, <s> 要素など) へのスタイリング非対応
テーブル記法非対応
コントリビュートしてたらコミッターにしてもらった
ということで、この辺りの課題を k1LoW さんと相談しながら順次解決していって一通り片づけた。パフォーマンス問題は、上記の12,3分かかっていたスライド生成は25秒程度に短縮された。実に30倍である。画像が少ないスライドだと100倍以上のパフォーマンス改善になるケースもあった。
7月頭から1ヶ月半程で、1万行以上のコード追加、70以上のpull requestをマージし、コラボレーター権も付与してもらって、コミッターになった。
今後は、k1LoWさんと一緒に頑張ってメンテナンスに協力していければと思っています。
deck の解説ここ1ヶ月半で色々アップデートがあったので、改めて deck の使い方をまとめておいた方が良いと思い、以下の解説スライドを作った。これも当然 deck で作った物だ。
色々アップデートがあったと書いたが、当初のシンプルな使い勝手は維持されていて、複雑になってはいないはずだ。徒に機能を増やした訳ではなく、多くの人にあって欲しい機能を追加して「思った通りに動く」ことを重要視した。その為の改善を積み重ねたつもりである。
是非ご利用下さい。
宣伝
スポンサー
上記のスライド内でも書いていますが、deckはOSSなので様々な形で貢献して下されば嬉しく思いますが、k1LoWさんとSongmuはGitHub Sponsorsを開けてあるので、是非少額のワンショットでも良いのでスポンサーして下さると嬉しいです。
ちなみに、deck のインテグレーションテストをGitHub Actionsで実行するためのGoogle WorkspaceやGoogle CloudのリソースにSongmu個人の有料契約を使っているため、ほんのちょっとだけお金がかかっています。
Buildersconに発表プロポーザルを提出しています
この deck へのコントリビュートについて発表プロポーザルを Builderscon 2025 に提出しています。採択されるようにスターなどで後押しして下さると嬉しいですし、採択されたら是非聞きに来て下さい。
k1LoW/deck開発におけるTidy Fitstの実践 - 機能追加とパフォーマンス向上の両立
k1LoWさんとのポッドキャスト
私のポッドキャスト、趣味でOSSをやっている者だ でk1LoWさんと色々おしゃべりしています。deck の開発についてもお話しているので、興味があれば是非聞いてみて下さい。
2025-08-12 00:43
https://github.com/Songmu/laminate
文字列から画像を生成するコマンドラインツールがいくつか存在する。例えば以下のようなものだ。
laminate はそれらを一元管理する。laminate コマンドを実行すれば、設定ファイル上の適切なコマンドに処理が渡され、画像が出力される。例えば以下のように使う。
% cat main.go | laminate -lang go > main.go.png
k1LoW/deck との連携
最近、k1LoW/deck というMarkdownからGoogleスライドを作成するツールを愛用し、開発にも携わっているのだが、laminate はこの deck のために作ったツールだ。
deck にはMarkdown内のコードブロックを画像化してスライドに貼り付ける素晴らしい機能がある。画像化のための外部コマンドを指定することで実現するのだが、そこで以下のように laminate を使うことを想定している。
% deck apply -c 'laminate' deck.md
これで、Markdown内のコードブロックが laminate によって画像化され、Googleスライドに貼り付けられる。
利用方法
laminate 自体は画像生成機能を備えておらず、設定ファイル記述内の適切なコマンドを実行する。設定ファイルは以下のような具合だ。
cache: 1h
commands:
- lang: qr
run: 'qrencode -o "{{output}}" -t png "{{input}}"'
- lang: mermaid
run: 'mmdc --scale 8 -i - -o "{{output}}" --quiet'
ext: png
- lang: '{go,perl,rust,python,java,javascript,typescript}'
run: 'silicon -l "{{lang}}" -o "{{output}}"'
- lang: '*'
run: ['convert', '-background', 'white', '-fill', 'black', 'label:{{input}}', '{{output}}']
laminate 自体は標準入力から文字列を受取り、標準出力に画像データを出力するが、各画像生成コマンドの様々な入出力インターフェースに対応するために、{{input}} と {{output}}というテンプレート変数を利用できるようにしている。
lang指定には、globパターンを利用でき、最初に一致したコマンドが実行される。このように、langに応じた適切なコマンド実行が laminate の役割だ。langと言いつつ、上記でもqrがそうであるように言語名に限らない様々な文字列に応じた画像生成コマンドを設定できる。
画像フォーマットはデフォルトでPNGを期待しているが、コマンドが別フォーマットを出力する場合は、extキーを指定することで、別の画像フォーマットに対応できる。(ただ、deck というかGoogleスライドは、PNG, JPEG, GIFしかサポートしていないので注意)
deck の --code-block-to-image-command (-c) オプションで同様のことを実現しようとすると、少し複雑なシェルスクリプトを書く必要があるため、それを分かりよく書けるようにしたという次第である。
キャッシュ機構
上記の設定ファイル例から気付いたかもしれないが、laminate にはキャッシュ機構がある。cache: 1h だと、同じ入力に対しては1時間はコマンドは再度実行されず、キャッシュ画像が出力される。これにより、deck のスライド生成の高速化が図れる。このキーを指定しない場合、キャッシュは無効になる。
その他細かい利用方法については、リポジトリのREADME.md を参照して下さい。
ご利用下さい
ということで、 deck を使う上では必須ツールではないかと思うので、是非ご利用下さい。
余談1: Siliconの設定
コード文字列のシンタックスハイライト画像生成には、Silicon を利用しているが、私は以下のような設定にしている。
% cat ~/.config/silicon/config
--font 'HackGen'
--theme 'Monokai Extended Origin'
--no-line-number
--pad-horiz 0
--pad-vert 0
--no-window-controls
HackGen (白源) フォントはSIL Open Font Licenseなので、画像化したものを頒布しやすいのも嬉しいポイント。
余談2: 命名
deck との親和性も意識しつつ名付けた。結果として同様に検索性の低いツール名となった。ラミネート加工のように、このツール自体は図版の生成を行わなず、あくまで最後の処理を実施するツールであることも表現できており気に入っている。物理のカードやスライドにラミネート加工を施すこともあることも deck との親和性を感じられて良い。
しかし、実は、我々日本人がイメージする「ラミネート加工」は英語では "pouch lamination" という "laminate" の限定的な意味であり、英語の "laminate" は薄いレイヤーを貼り合わせるようなことを指すようだ。例えば「積層板」は "laminated plate" となるらしい。
"laminator" だと我々が認識しているラミネート加工のイメージに近くなるようなので、もしかしたらそっちの方が名前としては良かったのかも知れないとも考えたが、コマンド名は動詞の方が良いという話もあるし、原義の"laminate" の意味合いであっても、このツールが果たす役割とそんなにずれていないとも思い、laminate で良しとした。
参考: Lamination - Wikipedia
余談3: ファイル名サニタイズ github.com/spf13/pathologize
laminate のキャッシュファイルは cache/{lang}/{hash(input)}.{ext} に格納される。このとき {lang} や {ext} は一応ユーザー入力になるため、トラバースや不正な文字列 ("CON"等) などを避けるために無害化処理を施している。
そのためのGoの定番ライブラリが案外定まってなさそうだったが、github.com/spf13/pathologize を見つけ、これを使うことにした。
これは、100行程度と小粒ながら良いライブラリで、一般的なトラバース処理だけではなく、クロスプラットフォームで問題になりそうなファイル名のサニタイズもやってくれる。例えば、Windows上の不正なファイル名などもケアしてくれる。Windowsは未だにに "CON" 等のファイルを作れないし、将来的にも変わらない可能性が高い。マルチプラットフォームなツールを作る上では意識をしておきたい所だ。
作者のspf13 さんも cobra や viper , Hugo 等を作られた方なので信頼性も高い。pathologize はスター数も多くなく、まだバージョンタグも打たれていな状況ではあるが、既に使える品質にはなっていると思うので、ローカルにユーザー入力に基づいた名前のファイルを保存する際には利用を検討すると良いと思う。もちろん、そもそもそんなことをやるべきではない、という話でもありますが。
2025-06-26 14:07
この話は、goccy/go-yaml 作者のgoccyさんと、YAMLの話を…止めない! という私のポッドキャストエピソードでも話した内容だが、口頭では説明が難しかったり、上手くまとまってなかった部分もあったので、補足的にエントリーを書いた。ポッドキャストでは裏話的な話やgoccyさんの生の意見も聞けるので、そちらも是非聞いてみて欲しい。
GoのYAMLライブラリとそのアーカイブ事件
GoのメジャーなYAMLライブラリには大きく以下の2つがある。
他にもYAMLライブラリはいくつかあるが、実態は、gopkg.in/yaml のラッパーであることがほとんどだ。例えば、github.com/ghodss/yaml や sigs.k8s.io/yaml 等。
gopkg.in/yaml は k8sやdocker compose内部でも使われている世界的に標準的なライブラリで、我々ソフトウェアエンジニアを支えている重要なライブラリと言える。そして、その開発リポジトリが正式にメンテナンスを停止し、アーカイブされる という事件があり、乗り換え先選定やメンテナンス継承等に関わる色々な動きが起きている。
アーカイブの影響
直ちに問題はなく、大事になっていない。ライブラリとしては利用可能なままだし、そもそも、gopkg.in/yaml のメンテナンスは実質的に大分前から止まっていたようなものなので、状況が大きく変わったわけではない、という見方もある。
ラッパーライブラリが多く存在するのもそのためだ。足りない機能やGoらしくないインターフェースをラップするために、ラッパーライブラリ経由で gopkg.in/yaml を操作する使い方がされている。YAMLの仕様は余りにも膨大であるため、イチからライブラリを実装するのは多くにとって現実的ではないという話もある。
とは言え、アーカイブされたライブラリに依存するのは長期的には不安定なので、乗り換え先を選定するか、既存のソースのメンテナンス継承を検討する必要がある。
そこで、有力な乗り換え先として注目されているのが goccy/go-yaml である。
2つのYAMLライブラリの比較
私は元々、goccy/go-yaml を好んで使っていた。そっちの方が使いやすく、品質も高いと考えていたからだ。作者のgoccy(五嶋)さんに対する信頼度が高いことも後押ししている。
2つのライブラリの簡単な比較は以下。
gopkg.in/yaml
古く(2011年)からあるGoのYAMLライブラリ
Cで書かれたlibyaml をGoに移植したような作りになっている
移植なので、libyaml実装に引っ張られた作りになっている
変数名や内部のインターフェースなど
libyaml自体が歴史があるプロジェクトなのでソースコードの統一感に欠ける部分も
goccy/go-yaml
後発(2019年)のYAMLライブラリ
YAMLの仕様を元に、Go向けにスクラッチで実装されたライブラリ
Goらしいコード・インターフェースで書かれている
ライブラリ利用者からしたインターフェースも自然で使いやすい
若いプロジェクトであることもあり、メンテナンスの統制が取れており、ソースコードの統一感が高い
YAML Test Suite のスコアも、gopkg.in/yaml よりも高い
実装をもとに作られたgopkg.in/yamlと、仕様をもとに作られたgoccy/go-yamlとアプローチが異なるのが面白い。開発の世界では良くある話でもある。
個人的には、goccy/go-yaml への乗り換えが進んでいくのだろうと思っていた。gopkg.in/yaml はそもそもメンテナンスに困っており、引継先なども模索した上で、それが難しいと判断してアーカイブされたのだろうから、今後引き取り手が現れる可能性も低いと思っていた。
ただ、goccy/go-yaml も個人プロジェクトではあるし、gopkg.in/yaml とのインターフェースの差異もあるため、乗り換えコストを払うことが見合うかどうかは様子見されている雰囲気も感じる。
そして、ここで、(あまり注目されていないが)大きな動きがある。YAML本家による、gopkg.in/yaml のメンテナンス継承である。
YAML本家によるメンテナンス継承
YAMLオーガニゼーション はYAMLの総本山であり、YAMLの仕様に加えて、LibYAMLやPyYAMLの実装、YAMLテストスイートなども公開・開発・管理している。YAML自体がPerl出自の技術であることもあってか、Perl6の実装も公開している のも面白い。そこが、gopkg.in/yaml のメンテナンスを引継を計画して進めている。そのリポジトリが以下だ。
(ちなみに、元々の gopkg.in/yaml のリポジトリはgithub.com/go-yaml/yaml なので、仕方がないのだが、紛らわしく、説明に苦労する。)
これは、客観的に見たら悪くない話ではあるだろう。メンテナンスに困ったOSSの受け皿として、このようなオープンな団体が手を挙げるのは良いことだ。ただ、リーダーシップ不在のまま引き取られたOSSが、結局放置される事例は多い。「墓場」の様な揶揄がされることもある。
gopkg.in/yaml の保守性の悪さからメンテナンスに苦労していた現実もある。そういう「死にかけている」ライブラリに対して無理に延命措置を講じることが本当に良いことなのか、という話もある。gopkg.in/yamlがその性質上、Goらしくないコードになっていることや、YAML本家のチームにGoのエキスパートがいなさそうなのも不安要素である。
この継承に関する議論は、CNCFのSlack の #go-yaml チャンネルで行われており、誰でも閲覧可能だ。CNCF内で議論されているというのが面白い。
ただ、最近のCNCF Slackのプラン変更 により、90日以上前のメッセージが閲覧できなくなるので見たい方はお早めに。該当チャンネルは、4/25作成のチャンネルなので、今ならまだ全部のログが読める。
goccyさんとYAML本家との対話
goccyさんも上のSlack上に投稿し、議論がなされている。YAMLの大本の作者である、Ingy döt Net さんが精力的に議論に参加していてアツい。
ここで、出てきた面白い観点としては、gopkg.in/yaml はLibYAMLの移植であり、Goらしいコードになっていないことが彼らにとって寧ろ好ましいという点だ。
これは言われてみれば無理もない話だろう。彼らは、LibYAML, PyYAMLも同時にメンテナンスしているわけで、go-yamlも含めて、それらが似通った実装になっている方がメンテしやすいというのは道理だろう。Goに詳しい人がいないから尚更だ。
そして、もう一つの観点として、「仕様が正か。実装が正か」というソフトウェア開発で頻出の話がある。彼らは、YAMLの仕様も、汎用的で網羅的なテストスイートも公開しているので、元々は仕様を正にすることも考えていたのだと思う。ただ、実際はLibYAMLやPyYAMLの振るまいが事実上の標準仕様となっていることを受け入れ、その方針で進めているようだ。だから、尚更、gopkg.in/yaml の実装がLibYAMLに近いことが好ましいという話になる。
実際、YAML仕様の記述には曖昧な点があり、テストスイート自体が正しいか、という話もある。
ちなみに、gopkg.in/yaml のテストスイート網羅率は73%であり、goccy/go-yamlは88%である (2024年12月時点 )。そもそも100%を目指す様な者でもなく、その必要性も疑わしいという話もある。
私は、YAMLのテストスイートが網羅されている実装は存在しないと認識していたが、実は2020年に、本家が全てのテストケースが通る参照実装を公開していた事を今回の議論の中で知った。そして、それを参考にテストスイートを網羅するライブラリも少ないながら出てきているとのことだ。
https://github.com/yaml/yaml-reference-parser
それと同時に、この参照実装は実用性に欠け、彼らがメンテナンスしているPyYAMLやLibYAMLも意図的に仕様から逸脱していて、テストスイートを網羅していないことも議論の中で明かしている。
現実問題としては仕方ないとも思うが、仕様から実装を進めていたgoccyさん的にはびっくりする話だっただろうが、その辺りの公式のスタンスが今回知れたのは良かったとは思う。
KubernetesのYAMLライブラリの移行
ちょうど本日、6月26日、Kubernetes本体から、gopkg.in/yaml の依存がドロップされ、新しい go.yaml.in/yaml (yaml/go-yamlのライブラリ名) へ移行するpull requestがmasterに取り込まれた。
Drop usage of forked copies of goyaml.v2 and goyaml.v3 by dims · Pull Request #132357 · kubernetes/kubernetes
現実問題としては、インターフェースやコードベースが同一の後続ライブラリに移行するのは丸い選択肢だとは思う。この新しいyaml/go-yaml はKubernetesが正式に採用することになり、CNCFも巻き込んで議論されているので、メンテナンス体制の不安もある程度払拭されたと言えるかも知れない。
私Songmu個人的には、引き続き、goccy/go-yamlを使い、推していきます。
おまけ: yamlscript
今回の議論の中で、YAML作者のIngy氏は現在yamlscript という恐ろしい名前のプロジェクトに積極的に取り組んでいることも分かった。YAML愛が凄い。Ingy氏についての話や、yamlscriptについては、冒頭にも書いた、YAMLの話を…止めない! というポッドキャストエピソードで話しているので是非聞いて欲しい。
また、今回のSlack上での議論については、その半公開の性質上引用は控えた(多分やっても問題ないとは思うが)。議論を見たい方は、Slackに参加 して #go-yaml チャンネルを覗いてみて欲しい。6/4~6/6辺りの議論なので、8月一杯くらいでアーカイブが消えてしまうのでお早めに。
2025-06-26 00:02
Songmu/action-create-branch
READMEにも書いてあるが以下のように使う。これは、指定ブランチがあれば作るし、無かったら何もしない簡単なGitHub Actionだ。分岐元指定のrefにはブランチ名、タグ、コミットハッシュを指定できる。refは省略可能でデフォルトではgithub.refを使う。
- uses: Songmu/action-create-branch@v0
with:
branch: feature/new-feature
ref: main
何故作ったか
先のエントリーの、action-push-to-another-repository のフォーク元には、元々、create-target-branch-if-needed という、指定ブランチがなかったら作るオプションがあった。しかし、私がフォークしたものからはそれを削除した。コードの複雑性が増してしまっていたし、その機能を内包する必要性も感じなかったからだ。
ただ、一時ブランチを作って、そこにpushするユースケースは確かにあるだろう。であれば、前段に、ブランチがなかったら作るというステップを定義すれば良い。
そういう、単純にブランチを作るだけのGitHub Actionはきっとあるだろうと思ったが、案外良い物が見当たらなかった。具体的には、分岐元のrefにブランチ名、タグ、コミットハッシュを柔軟に指定したいが、それができるアクションを見つけられなかったので、作った。
APIで操作するので、事前にcheckoutする必要がないのも嬉しいポイント。
action-push-to-another-repositotyとの組み合わせ
リポジトリのREADMEにも追記 したが、以下のように使えば良い。
- uses: actions/checkout@v4
persist-credentials: false
- name: Create branch if needed
uses: Songmu/action-create-branch@v0
with:
repository: 'owner/dest-repo'
branch: 'new-feature'
ref: develop
- name: Push to another repository
uses: Songmu/action-push-to-another-repository@v2
with:
destination-repository: 'owner/dest-repo'
destination-branch: 'new-feature'
こちらの方が、１つのアクションに変にオプションを増やすよりも明確で分かりやすい。この様に、シンプルな部品を作りシンプルに留めること、それらを上手く組み合わせて使うのがソフトウェア設計全般で大事なことの１つだ。
実際、action-push-to-another-repositoryのスクリプトは50行程度だが、action-create-branchは133行と実はこっちの方が分量が多くなっている。なので、ブランチを作る処理はやはり内包したくない。
ちなみに、aciton-push-to-another-repositoryのコード行数が比較的少ないのは、コミット処理をsuzuki-shunsuke/commit-action に委譲しているからだ。
また、action-create-branchのコード行数が比較的多いのは、指定されたrefからコミットハッシュを解決する処理がそこそこ複雑だからだ。それを今回はGraphQL APIを使って、一撃でcommitハッシュを取得するようにしてあるのが面白ポイントなので、興味ある方はコード を見て欲しい。
このアクションの開発ではClaude Codeに大半のコードを書いてもらった。便利ですね。
