野村政行の「堪忍袋の緒を締めろ！」

ActivityPubへの投稿を静的HTMLにも保存しておく

野村政行 — Wed, 31 Dec 2025 17:51:00 +0900

巨大な企業SNSからActivityPubに移住して早3年が過ぎた。完全に移住したわけではなく、世間一般の情報を得るためには巨大な企業SNSの検索機能を使わせてもらっているし、ググればそちらのSNSの投稿はヒットするので、そういう活用の仕方はさせてもらっている。自分の投稿をそちらにアップしなくなっただけだ。で、ActivityPubのほうにはそれなりに投稿しているのだが、この投稿はGoogleなどの検索エンジンからはクロールできない。ActivityPubのフロントエンドにSoapboxというものを使っているのだが、これはsingle-page application (SPA)、つまりjavaScriptがその都度ActivityPub APIから情報を取得して画面に表示しているため、検索エンジンのBotがクロールしようと思ってもこの機能が動作しないため投稿の中身がクロールできない。どうしようもないゴミ発言を拾われないのはいいことではあるが、流石に寂しい。どうしようもないゴミ発言も自分で責任をもって管理したい。そのために自分のドメインで公開しているのだから、検索エンジンくんが欲しいというなら、まあ、提供してもいい。

というかですね。

検索エンジン様に拾っていただかないと、世間からみて生きているかどうかわからない、ということに気づきました。ごめんなさい。生きています。ゴミ発言ですが拾ってください。

そこで、ActivityPubのRSS feedや、outbox を読み取って静的HTMLとして出力するプログラムを開発した。 https://github.com/king-nomura/feedToHtml Node.jsで動くのでローカルでも、サーバでもわりとどこでも動かせるんじゃないかと思う。このプログラムの開発にはがっつりとClaude Codeを使った。自分ひとりで作ったものではないのでREADMEにもちゃんと記載した。いや、記載させた。自分で自分のことを書くの恥ずかしかったろ、Claude Code君よ。

とりあえず出力結果はこちら。 → @king_nomuraの投稿

今年はここまで。

AIでiOSアプリを作ってリリースする

野村政行 — Fri, 25 Apr 2025 08:55:40 +0900

(2025.4.26追記)

「Vibe Coding」では、コードを人間が読んではいけないそうです。あくまでAIが作った成果を楽しむもので、どう実装したか確認したらそれはただの「コーディングアシスト」だから、だそうで。ということは自分はVibe Coding界隈とは相入れないんだな、というのを確信しました。ごめんなさい。

きっかけ

今年の2月にGitHub Copilotにエージェントモードが追加された。コードを直接書くのではなくAIに望んでいるもの（機能、画面レイアウトなど）を伝えてプログラムを書いてもらうことを「Vibe Coding」というらしい。そして、このバイブコーディングを嗜んでいる人々の中には「1行たりともコードを書かない」という縛りプレイを楽しんでいる人もいるらしい。なにそれ楽しい。

知らないエディタで知らない言語を使う

バイブコーディング環境の流行とはだいぶ違うが、すでに課金済みという理由からGitHub Copilot エージェントをバイブコーディングのお供に選んだ。このGitHub Copilot エージェントを導入するには、開発環境（IDE）として Visual Studio Code を選択するしかない。自分は普段はJetBrains社製のIDEを使っているため、VS Codeの使い方で若干手間取ってしまう。いまどきのプログラム初学者はVS Code一択だろうから、これは老兵ならではの悩みといえる。とはいえ、設定は拡張機能としてGitHub Copilotを追加するくらいだ。アカウントを紐づけて、VS Codeの設定画面からエージェント機能をONにすればもうバイブコーディングの準備は完了だ。そもそもバイブコーディングではコードを書く行為はメインではない。なのでエディタとしての使い勝手を上げるチューニングは、あまり頑張らなくて良い。自分の場合は普段使っているIDEとは別の環境になっているので、むしろもっと「バイブコーディング専用IDE」にチューニングしても良さそうだ。

コードエディタとして考えると邪魔なくらいチャット画面を広げている。実際の作業が始まるとソースコードもちゃんと追いかける必要はある（後述）のだが、バイブコーディングではチャット画面を起点にして作業をすることになるので、まずはチャット画面の使い勝手を追求したほうが良い。なんならば、ど真ん中にチャット、右にエディタという構成にしたいくらいだ。チャットの入力フィールドももっと大きく打ちやすくできると嬉しいのだが、そういうチューニングはまだ追求できていない。

今回は、 Flutter というマルチプラットフォーム対応のフレームワークを使ってユーティリティーアプリを開発することにした。プログラム言語はDart。FlutterもDartもほぼ未経験だが、GitHub Copilotに「Flutter知ってる？」と質問したら「知ってる」と返してきたので採用した。まるで炎上案件の火種なのだが、ここからでもなんとかなっちゃうんだな、AIなら。とりあえず、空っぽのディレクトリを開いて、エージェントに「Flutterでアプリを作りたいからセットアップして」とお願いしてみた。なお、ここから先も含めて、実際にどういうリクエストをエージェントに送ったのかは残念ながら忘れてしまったのでニュアンスで読んでほしい。Flutterフレームワークをマシンに設定するところは（アクセス権限の兼ね合いもあるので）流石にエージェントが自動で……とはいかなかったが、手順はエージェントが教えてくれたのでそれに従いFlutterのプロジェクトをセットアップした。きちんとFlutterプロジェクトのセットアップが完了してしまえば、その後のパッケージの追加やビルドなどはエージェントがコマンドをターミナルに入力・実行してくれるようになる。

気を取り直して、エージェントに「タイマーアプリを作って」とお願いしてみた。すると、なんということでしょう、タイマーとスタートボタン、停止ボタンが出来上がって、実際に動くではありませんか。ソースコードを確認してみる。うーん、よく分からないがそれっぽい。シンプルなアプリをお願いしたのでうまくできるだろうとは思っていたが、ぱっと見では強引そうなところも読みづらいところもない。関数名、変数名もしっかりしている。これからのプログラムの勉強は、AIがまずお手本の「Hello World」を生成してくれて、それを学習していくスタイルになるかもしれない。

結局コードは読むし、書くことがある

さて、ここから作りたい機能をひとつづつ、エージェントに指示を出して増やしてもらうことになるのだが、この「ひとつづつ増やしていく」というところはバイブコーディングのポイントかな、と感じた。人間が行う作業でもそうなのだが、エージェントに曖昧で大味な指示を出すと齟齬が生まれやすく、余計なことまで実装してしまう傾向があるようだ。上記の「画面にタイマーを表示するアプリを作って」の指示からは、タイマーアプリを作るというからにはスタートボタンと停止ボタンは必要だろう、というところまでエージェントは推測してくれた。これは良い方向にお節介が働いた例だが、こういう事例で「AIは賢い」といってしまうのはあまり良くないことだと感じた。曖昧な指示から勘違いな機能が実装されてしまうと、削除したり修正しなくてはならなくなる。指示と違う部分を指摘して、こういうふうに直してくれとエージェントにお願いすることになるが、これは単純に時間とコストのロスだ。また、エージェントは自分が提案したコードを覚えているので、エージェントではなく人間がそれを修正してしまうと、次にエージェントがコードを修正するときに「齟齬」が生まれてしまうようだ。いずれ技術が進むともう少し協業できるようになるかもしれないが、原則としてバイブコーディングでは人間はコードを「書いてはいけない」のだろう。

そんな経験から、新機能を一部分でも実装できたらいったんGitにpushするなどしてコードを保全するようにするようにした。そして、エージェントが更新したコードとのdiffを毎回確認し、違和感があればコードをロールバックして、エージェントとのセッションは新しく立て直す。そして改めてエージェントには齟齬の余地を減らすような工夫を加えた新しい指示を送ってみる、トライアンドエラーの手順を確立していった。

品質という点でみると、エージェントが提案してくるコードの中には配布元が「近い将来、非推奨になるよ」としている関数を使ったものが含まれることがある。AIが学習したコードの中では古い書き方の評価が高いのだろう、そういうときは配布元URLを引用して指摘してもなかなかうまく修正をしてくれない。これはたまたま気づけたから指摘できた事例だったが、「エージェントが提案してきたコードを自分でも調べてみる」というのはなかなかにコスト高だし難しい作業だ。エージェントが書いたコードが必ず一発で動くとも限らない。そういうときはエージェントにエラーメッセージを伝えて修正を依頼するのだが、修正を依頼しても直せずにループに陥ってしまい最後はコード修正を諦めてしまう、という場面もあった。その場面では、そもそもエージェントが考えた修正のアプローチがまずかったらしく、最後は諦めて自分でコードを直してしまった。

エージェントにもできないことはあり、そのときは当然だが自分でコードを書くしかない。つまり現状のバイブコーディングというのは、AIの力量を把握して、いざとなれば自分でコードを読み書きする前提で、その上であえてなるべくエージェントに書いてもらう、という塩梅のコーディング手法なんだろうな、と思った。

AIのことを「時給500円の疲れ知らずのバイト君」と表現したブログを拝見したことがあるが、まさしくそんな感じだ。指示を的確に出し続ければ、その分だけずっと同じクオリティで仕事をし続けてくれる。だが、その疲れ知らずなバイト君にずっと付き合って指示を的確に出し続けなければならないのは店長である人間なのだ。そして出来上がったものを確認するのも人間。そりゃそうだよね。

iOS / macOSアプリを出したんだ

そんなこんなで作られたのが「Chain Timer」というアプリ。Flutterなのでマルチプラットフォームで動作するのが非常に便利。4月24日にiOS版とmacOS版を無事公開することができた。

アイコンはChatGPTに作ってもらった。UIデザインについては、そもそもFlutter自身がMaterial Designに忠実なので適当にパーツを並べただけでも破綻しづらく、カラーテーマもFigmaの Material Theme Builder を使ってダークテーマも含めてすぐに導入できた。こんな単機能なアプリで日本語専用にするのは勿体無いので、このアプリは日本語と英語に対応している。翻訳の一部は、i18nパッケージ（slang）を導入していることをエージェントが認識していて、都度いい感じに翻訳ファイルを更新してくれた。

タイマーを連続で起動させるというアイディアは、数年前にMakerFaireTokyoに出展したハードウェアが元ネタで、アナログ写真の現像のときに濡れた手でいくつもタイマーを切り替えないといけないのが不便だったので思いついたものだ。個人的には、シンプルながらそれなりに便利なアプリになったと思う。タイマーリストをQRコード化する機能は、デバッグ時に非常に重宝した。このQRコードの中にはタイマーリストの構造をJSON→gzip圧縮→BASE64エンコードした文字列を格納しているが、QRコードに含められる文字長に限界があるのであまり大きなデータ構造にすることができなかった。

本当はAndroid版とWindows版もあるのだが、Android版をGoogle Playに登録するには12人のテスターが必要なので保留中。Windows版は、そもそも開発者アカウントの登録に手間取って謎の足踏み中だが、出せるもんなら出してみたい。減るもんじゃないし。

Obsidianで日記サイトを構築して、ついでにAIと戯れる

野村政行 — Tue, 11 Mar 2025 08:08:03 +0900

この日記はHugoで生成している。Hugoの書式はMarkdownなので、テキストエディタでも書くことはできるがリッチエディタっぽいツールを使うとさらに便利になる。そこでObsidianだ。Obsidianはオープンソースのメモアプリで、拡張性が魅力だが、まずは基本機能の「デイリーノート」をそのまんまHugoのフォーマットに合わせて使うこととする。 Obsidianは「保管庫」と呼ばれるフォルダを指定してその中にある .md ファイルのひとつひとつをメモとして扱う。フォルダやファイルの構成をHugoのcontentディレクトリのままにできるので、そのまま読み書きできる。例えば以下のようなテンプレートをデイリーノートのテンプレートとして指定すると、いきなりHugoのドラフトページを書き始められる。

---
title: titleを入れる
date: {{date:YYYY-MM-DD}}T{{time:HH:mm:ss}}+09:00
url: {{date:YYYY/MM/DD/}}
tags:
 - PC
draft: true
---
本文を入れる

書き終わったらGitにあげる

拡張機能「git」を導入する。これで、書いた日記をGitHubにpushできるはずだ。 Obsidianは保管庫に指定したフォルダに隠しフォルダを作って諸々の設定を保存している。なので、.gitignore　でそのディレクトリを除外しておくことにする。

.obsidian

Git Source Panelを表示すると、この日記ファイルがまだstageされていないことがわかる。ここから諸々の操作が可能なようだ。デフォルトのコミットメッセージは vault backup: {{date}} となっている。ここにも変数使えるのね。

さらにAIを導入してみる

いまナウで最先端なAIというやつを入れてみる。近頃はコードを書くときにはGitHub Copilotをメインで使っているが、日記はコードじゃないので使わない。ちょっとしたコードを書いたり雑多な質問にはChat GPTを使っているがこれはWebベースで使っているし自分は課金していないのでAPIとして組み込むには向かない。ここでは拡張機能「copilot」を使ってGoogle Gemini APIの無料枠を導入してみることにする。 AIには日記の誤字・脱字を直してもらったり、読みやすいように校正してもらいたい。だが、日記のような砕けた文章を校正してくれるだろうか。「自分っぽい書き方」をしているところとの相性が気になる。

よーし、校正をお願いしてみるか。chatウインドウから

この記事の校正をお願いします。誤字や脱字、読みづらいところなどがあれば指摘してください

……、お願いします。

校正をご希望の記事が提供されていません。

……、はい。開いているページを「{activeNote}」と書いて指定しないといかんのね。

{activeNote}の校正をお願いします。誤字や脱字、読みづらいところなどがあれば指摘してください

……、おお。割と平たい文章になるように言い回しを提案してくれるじゃないか。ただ、なんというか、いわゆる「いかがでしたかブログ」っぽい文章にどんどん直されていく印象もあり。この校正そのまんまは受け入れ難いなぁ。

- 「いまナウで最先端なAIというやつを入れてみる。」→ 「最新のAIを導入してみます。」

これとか受け入れ難い。ナウで最先端なほうが良くないですか？ダメですか？そうですか。

というわけで、今日の日記はここまで書いたObsidianの使い方を実験するための日記でした。最後に今日の日記を要約してください、AIさん。

この日記は、Hugoで生成している日記サイトの作成に、Obsidianというメモアプリを活用する試みについて書かれています。Obsidianのデイリーノート機能をHugoのフォーマットに合わせて使用し、日記を書き終わった後はObsidianの拡張機能「git」を使ってGitHubにpushする方法を試しています。さらに、Google Gemini APIを導入してAIによる校正を試していますが、AIによる校正は文章を平坦にし、「いかがでしたかブログ」のような印象を与えるため、全面的には受け入れられないと感じています。全体として、Obsidianの様々な機能を活用して日記サイトを構築する実験的な内容となっています。

あ、あなたの文体を否定的に書いた部分をそのまま要約に採用しましたね……。最後にちくりと人間側を腐しておきたいと……。

「文章のどこかに『生成AI』を入れてください」

野村政行 — Fri, 03 May 2024 17:12:45 +0900

すごいなぁ、とは思うんですよ。生成AI。文章にしても、絵にしても、音楽にしても。

自分だってAIをまったく使っていないわけではない。いろんなプログラミング支援AIを試してみて、今はGitHub Copilotに落ち着きそうだ。

プログラミング支援AIは、そのサジェストの出し方、手の差し伸べ方が非常に上手い。冗長な内容の入力途中で残りを補完してくれる、というものならこれまでもあった。最近は、変数名の付け方がちゃんとしているとその単語の意味まで理解して補完してくれる。

この間ですね、emailでvalidationという名前の関数を使ったif文を書いていたら、変数messageを作ろうとしたらそこに"メールアドレスが違います"を代入してきたんですよ。へえ、AI君やるじゃない、と思うでしょ。それで、そのmessageを仮想配列に変えて"ja"というキーをつけたら、今度はAIがその次の行に"en"をキーにして"email address is incorrect."って書いてきたんですよ、これにはまぁ驚いたねぇ、頼もしいわぁAI先輩かっこいいっす。

こういうの、本当に自分たちが望んでいた未来のコンピューターな感じがして嬉しい。執事ってこういうものだよね。言わなくても察する、先回りして準備しておく、押し付けがましくない。我々はこういうものを求めていたんだ。

でもね。

「対話型の生成AIに、こういう文章で質問を投げるとこんな答えが返ってくるんですよ、すごいでしょ」

と言われたら、それは本当に「未来」なのか、納得できかねる。

「こういう文章で質問を投げる」ノウハウ自体で一喜一憂している様が「未来」じゃない。コミュニケーションが苦手な性格の人間にはAIとの対話にもハードルがある。人間の側が自分の考えていることをうまくアウトプットできないとなれば、今はまだAIのほうでもそれをうまく汲み取れない。そこは人間と変わらない。むしろAIはカメラや音声でこちらをのぞいているわけではないので文章という限られたインプットから察するしかない。「こういう文章で質問を投げる」ノウハウとは対AIコミュニケーション能力とも言い換えることができて、現段階でそれをうまくできる人はそもそも自分の考えをうまく文章化してアウトプットできる人で、おそらく実生活においても他者と円滑にコミュニケーションできるんじゃないだろうか。

前述のプログラミング支援AIが自分にとって心地よいのは、プログラムの世界ではコンピューターに対して正しいプログラムを書いてあげる能力がそもそも必要で、それはコンピューターに対してのコミュニケーション能力と言い換えることもできる。AIも同じプログラムを読むことから、プログラムを介して間接的にAIに対してのコミュニケーションが成り立つ。AIに対して直接話しているわけじゃないが同じ方向を向いて同じ言葉（プログラム）で対話が成立するから心地よいのだ。

AIを使うノウハウなんてものは一過性のブームだ。本当にAIが賢くなる未来においては、必要なのは人として極めて一般的なコミュニケーション能力であって特殊なノウハウではないはずだ。その未来はすぐ来るだろうから一喜一憂することじゃない。AIを使う、というのはすなわちコンピューターと共に生きていくライフスタイルそのもののことだと思う。それは、人間の生活を助けるように寄り添ってくれるものであって、人間がご機嫌をとりにいくようなものではない。

AIが寄り添ってくれる未来とはコンピューターの活躍する未来として、20世紀の頃からずっと我々が想像してきた未来のまんまであるはずだ。

おひとりさまインスタンスでなんとかしたい

野村政行 — Tue, 18 Jul 2023 08:23:38 +0900

おい、2022年は一日も日記書いていないぞ。

Twitterで時折ツイートしているから生存確認できているだろうと油断していた。インターネット、とりわけSNSは不思議なもので、自宅に引きこもっているだけの零細フリーランスなのに社会に繋がっているような錯覚を与える。他人の書き込みを眺めていいねボタンを押すだけで、なにか社会の裾のところにしがみついているような感覚。ところが、昨年後半からそのTwitterの運営が迷走しだした。

考えてみれば、落書きのようなメモ書きとはいえ、一応は自分の著作物である。SNSというプラットフォームは商品を並べたり配送を依頼する場所であって、工場を貸してもらっているわけではない。ちゃんと自分のドメインで製造して管理して、並べたり配送したりするところから他者にお願いするのが「筋」なのではないか。

そこでMastodonなどでお馴染みの、ActivityPubに対応したインスタンス（サーバー）を立ち上げることにした。自分の発言を自分のドメインに置くための、いわゆる「おひとりさまインスタンス」である。

Google Cloud Platform (GCP) の無料枠でe2-microというスペックのVMインスタンス（簡単にいうとレンタルサーバー）を一つもらえる。これでPleromaという実装（ActivityPubに対応したソフトウェア）を使ってインスタンスを立ち上げた（https://social.a3size.com/@king_nomura）。これからはこちらを「自分が発言するときの」メインのSNSに出来ないかな、と考えている。PleromaはMastodonよりも軽量らしく、またビューワーとしてこのインスタンスを利用しているのは自分ひとりしかいないので、それほどの負荷にはならなそうだ。また、将来もしも別の実装に取り替えたくなっても、まあデータのインポートエクスポートでなんとかなるんじゃないかなぁ、と楽観的に考えている。

将来的にThreadsもActivityPubに対応することが発表されているので、そうなればThreads上のユーザーをフォローしやすくなるし、自分のアドレス（ @king_nomura@social.a3size.com ）も伝えやすくなるだろう。相手がどこのサービスのインスタンスに所属しているかをいちいち気にしないで良い、というのがスマートで美しい。自分のアドレスが自分のドメインなのも、「ちゃんとしている」感じが嬉しい。

なので、SNSならなんでもいいという人はとりあえずThreadsにしたらいいんじゃないかな、などと考えている2023年なのでありました。

2006年に買ったマウスを静音マウスにする

野村政行 — Wed, 21 Jul 2021 01:20:14 +0900

普段、Macではトラックパッド（Magic Trackpad 2）を、主にゲーム（とかブラウザ確認とか）に使っているWindowsマシンではマウスを使っている。このWindowsのマウスは、LogitechのMX Revolutionで、2006年に買ったものだ¹。しばらくWindows機を立ち上げていなかったのでブランクはありつつも、もう15年も使ってきたマウスだ。

Magic Trackpad 2のクリック音は「コツッ」という少しくぐもった音色で（わざとそういう音を鳴らしているところが凄い）、MX Revolutionのクリック音は「カチッ」といういかにもなマイクロスイッチの音色だ。この、「カチッ」という音は、いろんな音がなっている中でなら気にならないが、比較的高い音でキンキン鳴るように聞こえて、ちょっと「カチカチカチカチ」と連打するとあまり気分が良い音とは思えなくなってきた。そこで、思い切ってスイッチを換装することにした。こちらがスイッチ換装作業の様子。元々ついていたスイッチを外して、新しいスイッチをつけたところだ。

静音マウス改造は実に様々な方がチャレンジされていて、その多くの方が静音スイッチの部品として「Kailh ミュートマイクロスイッチ」などの名前で検索すると出てくる6mm × 6mm × 7.3mmのマイクロスイッチを使用している。なるほど、これをMX Revolutionに乗せてしまえばいいのだな？とやや乱暴に思いついて、それを実行した。写真を見て貰えばわかるが、左下側に転がっているのがもともとついていた3本足の長方形スイッチで、付け替えた静音タイプのスイッチは正方形。うっかりするとクリックする部分がうまく噛み合わなくて押せなくなってしまうのだが、あまり深く考えずに実行してしまった。

ちなみに、このKailhのマイクロスイッチ、Amazonなどでも買えるのだがmercariで出品されているものを購入すると1個あたり100円未満で買えるというので、初めてmercariを使った。次に使うのは何年後になるだろうか。

実際の換装作業だが、知識のある方なら写真から想像つくと思うが、元々あったスイッチを取るためにハンダを吸い取るのに大変手間取ってしまった。吸い取り器じゃなくて吸い取り線で頑張ったんだぜ、これ。その結果、基盤パターンがもげてしまったので仕方なくリード線で配線を繋ぎ直した（マウス左ボタンの付近の黄色いリード線がそれ）。この場所以外にも、写真には写っていないが「マウスを持ったとき手前にくる側」にも基盤と部品がハンダ付けされている部分があり、そもそも先にそこを外さないとこのスイッチ換装の作業自体ができない構造になっているが、これもなかなか取れなかった。体感では、全体の作業の合わせておよそ2/3くらいをハンダを取るのに費やした気がする。

スイッチ換装のついでに、バッテリーも交換した。写真からわかるだろうか、すでにこのバッテリー、真ん中が大きく膨らんでしまっていたのだ。15年前のマウスなので純正パーツはもう手に入らないだろう、ということで互換バッテリー台湾から送ってもらい、つい先ほど載せ替えた。

作業終了後、まだ長時間使ってみてはいないが、今のところ順調に動いている模様。クリック音は「トン」というか「ト」というくらいの本当に静かな音に変わってくれたので、このまましばらく使ってみて動作に支障が出ないようならば、この換装は成功だったといえるだろう。

https://diary.a3size.com/2006/09/28/ ↩︎

Bluetoothヘッドセットとの戦い

野村政行 — Sat, 26 Dec 2020 04:08:08 +0900

ふと、PCでオンライン会議をするのにちょうどいいマイクとヘッドホンが欲しくなって、こういう投資は惜しんではならないとおばあちゃんの知恵袋に書いてあるので、買った。

マイクはマランツのMPM2000UというUSB接続のコンデンサマイクにすることにした。これをできればアームスタンドに取り付けたかったが、生憎デスク周りの構造上アームを付けられる場所がなかったので、卓上スタンドで使っている。会議の度に手前に持ってきたり奥にしまったりするのが若干煩わしいが、この煩わしさがオンライン会議をやるぞ！という気持ちのスイッチにもなっている部分も若干ある。

( Amazonアフィリエイト： https://www.amazon.co.jp/gp/product/B01GJ9IUNY/)

最初は有線のマイクではなく、無線のヘッドセットを導入して完全ハンズフリーな会議環境にしたいと思った。だが、それは諦めて有線のマイクを買うことにした。その経緯についてここにメモしておきたい。

無線のヘッドセットを使えば、会議中にふらふらとPCの前を離れてもちゃんと会議の音声は聞こえるしこちらの声も届く。なんと夢のような。そう思ってBluetoothのヘッドセットを探した。

最近のイヤホンはカナル型のものが全盛だ。オープンイヤー型は音が漏れるので非常に嫌がられる。だが、野村にとってはカナル型イヤホンは、装着した時の遺物感と「周りの音が聞こえづらくなる」ところがとても辛い。なので、SONYのSBH82Dを買った。特殊な形状のイヤホンなので、これを選んだということは相当に悩んで選んだなと察していただきたく。

( Amazonアフィリエイト： https://www.amazon.co.jp/gp/product/B07R7B3GRC/)

で、早速使ってみたところ、確かに無線のヘッドセットとして機能した。音はちゃんと聞こえるし、マイクの一は肩甲骨あたりに来ることになって話しやすい。だが、嬉々としてオンライン会議の本番に投入しようとすると、そのタイミングに限ってイヤホンのBluetoothが切断されるという現象が発生した。何度か試すうち、このBluetooth接続が切れてしまう現象はイヤホンとマイクを同時に使用すると発生することがわかった。PCの音楽を聴いたりYouTubeを見たりしているときには全然切断されないが、オンライン会議のようにマイク機能を併用するときに非常に切れやすくなるのだ。

出力にSBH82D、入力にUSB MICROPHONE(MPM2000U)を指定

で、まず上記の有線マイクを買ってみた。そして、イヤホンにSBH82D、マイクにMPM2000Uを指定してみると、予想通りイヤホンが切断される現象は起きなくなった。なんだよ、SBH82Dはヘッドセットとしては使えないのか？……もう少し実験してみよう。

MacBookProのBluetoothのハードウェアまたはドライバに問題があるのかも、と思い試しにAppleのAirPodsを買ってみた。試しに買うっていう金額じゃねーが。

( Amazonアフィリエイト： https://www.amazon.co.jp/gp/product/B07PRWYVN4/)

さすがはApple、接続トラブルもなくすんなりと音が出た。ではマイクはどうか。……繋がる！ちゃんと繋がる！……だが、どういうわけか、圧倒的に音質が悪くなる。なぜだろう、と思いネットで調べてみると、「コーデックが切り替わる」という記述を発見する。

これ、AirPodsだけではなくSBH82Dのほうでも再現できるのだが、Bluetoothデバイス1つでイヤホンとマイクを同時に使うと、SCOコーデックになることが原因であった。

イヤホンとマイクを使用するときはSCOコーデックになっている

調べてみると、これはBluetoothのHFP(Hands-Free Profile)という仕様に基づいていることがわかった（参考： https://news.mynavi.jp/article/osxhack-264/ ）。その名前から、携帯電話のハンズフリー用ヘッドセットで使う想定の規格なのだと推測される。つまりMacはヘッドセットを使う時にBluetooth機器との接続するときにプロトコルはHFPを要求する。

一方、SBH82Dをイヤホンとして使っている時、Bluetoothオーディオ機器の標準的な接続プロトコルであるA2DP(Advanced Audio Distribution Profile)でMacと接続している。それが、マイクを有効化するとA2DPからHFPに切り替わる。このことから、SBH82DはA2DPからHFPプロトコルを上手に切り替えれずに接続が切れる、またはそもそもHFPが苦手なのではないかと想像した。

Bluetoothの仕様は https://www.bluetooth.com/specifications/profiles-overview/ にある。英語を読み解く元気がないので斜め読みだが、このHFPにおける音声コーデック、SCOコーデック(内部的にはmodified version of the SBC codec)はモノラル/サンプルレート16kHzだと書いてある。モノラル！しかも16kHz！確かに携帯電話ハンズフリー級の音質で、そりゃいくらなんでも音が悪い。どれだけ便利だろうともHFPは使いたくない、無線ヘッドセットは諦めざるを得ない。

従って、イヤホンは無線、マイクは有線。これならイヤホンはSCOと比べて高音質なA2DPのままで、まあそこそこちゃんとしたマイクもあるので、そこそこ良いオンライン会議環境なのではないかと思う。

ところで、SBH82Dは音声コーデックAACが使えるのだが、これはiOSのみ対応とのこと。試してみるとやはりMacOSからはAACでは繋がらない。この間発表されたM1チップのMacならどうにかすると繋がるのだろうか、テストできる環境がないのでそれはわからない。

なので、せめて、A2DPの中でも最強セッティングで動作するようにチューニングはしておきたい。

具体的には、Apple Developerという公式の開発者サイトからBluetooth Explorerをダウンロードして設定をごにょるわけだが、上記のBluetooth仕様を読んで理解して……というのがとても大変なので、ググってみる。すると結論としてみんな「bitpool=53」にしていた、という事実だけはここに残しておく。bitpoolが53だとサンプルレート44.1KHzでビットレート328kb/s、51だとサンプルレート48kHzでビットレート345kb/sなので、48kHzで環境を揃えられるなら51の方が良いように思うんだが。

bitpoolを53にした場合

bitpoolを51にした場合

レンタルサーバを使うのをやめた

野村政行 — Wed, 02 Dec 2020 10:04:35 +0900

2018年の日記では、この日記サイトは BitBucket → Wercher → GitHub Pages という流れで公開されていると書いた。

素敵な自動化をしたはずなのに、そのあとは6本しか日記を更新しておらず全然その恩恵を生かすことはできなかった。まあ、自動化という「手段を整えることが目的」だからね。買い物でも、お金を払う瞬間がもっともアガった、なんてことは良くあることで。で、月末と年末で支払い関係やデスクトップ周りの見直しをしていた勢いで、2006年からずっと惰性で使い続けていたさくらのレンタルサーバーを次回は契約更新しないことにした。不満があるわけでもないが、レンタルサーバを借りてWebとメールを管理する、というスタイルに時代遅れ感もあったので。

この日記サイトとは別に用意していたWebサイト(www.a3size.com)はNetlifyに置くことにした。無料で静的Webサイトをホスティングしてくれる。しかもGitHubと連携できるし、CIも回せるらしい。とりあえずはGitHubと連携させて、FTPアップロードなる古の儀式を廃止した。これでhttpdサーバが不要になったので、レンタルサーバはいつでも解約できる。

ドメインはGoogle Domainsに移管した。すでに独自ドメインでGmailを利用しているので、集約先としてちょうどよかった。今後何かサーバリソースが必要になったら、まずはGCP(Google Cloud Platform)を候補にしようかと思っている。

ついでなのでこの日記サイトも、上記で書いたような3社のサービスを連携させるではなく、GitHub → GitHub Actions → GitHub Pagesという風に、GitHubだけで完結するように変更した。ワークフローはこちらのサイトを参考にさせてもらった（ https://knsh14.github.io/posts/how-to-automate-deploying-hugo/ )。

今回はとりあえず環境の変化だけのメモ書きだが、慣れない状況で全力でグーパンチ振り回していたら一年が終わろうとしていて、色々書き留めておかないとなぁ、と思っている。しわすー。

2019年の映画の話

野村政行 — Mon, 13 Jan 2020 09:21:44 +0900

去年の秋あたりから「期間が読めない」類の案件をいくつか参加させていただいた（今も）。面白い案件だし参加させていただける嬉しさがある一方で、スケジュールが組みづらく、他の案件をお断りすることになってしまうのは若干辛い。

そして、ゲームが積まれていく。……違う、ゲームの話じゃない。映画だ映画。1月になって第1話ラッシュで。……違う、TVアニメの話でもない。

というわけで、2019年分の映画はこちら：もう一度観たい映画2019

いつも鑑賞直後に星をつけているのだが、年の途中で自分の中での評価基準を変えた。それまで低め低めに星をつけていたが、このままだとどんな作品でも星5つにならないことに気づいたので、もっと気軽に星4つ以上をつけることにした。なので、年間通してみると「鑑賞直後の評価」にはばらつきが出てしまったのはご勘弁を。

いくつかの作品についてコメントすると。

「アベンジャーズ／エンドゲーム」はもう一度観たいが、一体どこから遡って観るんだろうか。「アイアンマン」からなのかな。シリーズを畳むといえば「スターウォーズ」もあるのだが(「スター・ウォーズ　スカイウォーカーの夜明け」は年明けに観たので、2020年分にカウント)、先に畳み方を観てしまったからか「アベンジャーズ(MCU)」のほうが好きな終わり方かな。

「ジョーカー」は映画全体がある種の胡散臭さをまとっていて、雰囲気だけでご飯が何杯か食べられそうで素敵。ジョーカーは「かわいそう」であると同時に「状況を変える元気がない」人で、一昔前ならばこの人は努力が足りないから状況を打破できないんだ、と云われたことだろう。この負のスパイラルが社会の問題として認知されている今だからこそ、心に響くのではないか。もともとのジョーカーというキャラクターにそういう背景はなかっただろうから、ある意味でこれは壮大な二次創作なんだろうなぁ。ちなみにハーレイ・クィーン関連作品は未見。劇場でスーパーマン鑑賞中に壮大に寝てしまって、そのせいでDC関連作品(DCEU)になんとなく負い目を感じてしまっているのだ。どうしようかなぁ……。

「ワンス・アポン・ア・タイム・イン・ハリウッド」は人にオススメできるタランティーノ作品という点で良かった。映画のスタイル(作風)と話そのものの相性が良くて、もしもこの企画が先にあって監督誰にするよ？という会議があったとしても真っ先にタランティーノの名前が挙がっただろう、と思う。あと、レオナルド・ディカプリオとブラッド・ピットがてぇてぇ。ディカプリオがダメな人間演じると名作。

「ホイットニー～オールウェイズ・ラヴ・ユー～」をもう一度観たくなるのは何故なのだろうか。ホイットニーが活躍していた頃をギリギリ知っている世代として、どうしても思い入れてしまう。

「運び屋」というコミカルな作品をみんな観てくれ。予告編からは想像できないだろうが、これは笑えて、泣けるダメ人間物語なんだ。想像なんだが、クリント・イーストウッドはじいさんが若者にいいこと言うふりして説教するのが本質的には嫌いなんじゃなかろうか。出会った若者たちに対して割とフラットな感情でぶつかっているように思う。もちろん経験から来る言葉の重みみたいなものはあるのだが、説教とはちょっと違って、単に「オレはこう思うぜ」という世間話をしているだけなんじゃないかな。同じテーマを日本で映画化したら、じいさんが仙人か宗教関係者みたいな感じになっちゃうかも。

観ていない作品について軽く触れると、「ジョン・ウィック：パラベラム」「ゾンビランド：ダブルタップ」はタイミングが合わなかった。

「アイリッシュマン」もタイミングが合わなかった上に、これ3時間超えなんだよね。Netflixはまだ契約していない。今の生活状態で契約すると、もう睡眠時間を0にしても足りなそうなので無理。気になるが、おそらく観ないままになりそう。人生損した気分。

「天気の子」はTV放映待機。新海誠作品なのにどうしても、どうしても心が動かなかったんだ……。作品を観る前の環境ノイズが多すぎて、疲れちゃったんだ。では、今年も頑張りましょう。

ストレージを空けたいんだ

野村政行 — Wed, 31 Jul 2019 00:17:50 +0900

その昔はさぁ、ハードディスクってものがあるらしいよ、とかさぁ。遂にハードディスクが1GBの領域に到達したらしいよ、とかさぁ。

などというインターネット老人会、そもそもインターネットがまだ研究者のものだった頃の話はさておいて。

メインマシンのストレージをどこまで大きくするのか問題である。

減っていく一方の空き容量に対して、青天井に増やしていけば解決なのかというと、これがそうでもない。ストレージがクラッシュしたとき、またはマシンがクラッシュしたときにどうリカバリするのか。バックアップを使って代替機を立ち上げようと思っても、その代替機のストレージが小さいと欲しいデータの容量には足りていたとしてもバックアップ自体が復元できない。だからマシンを買い替える際にストレージを大きくするのには抵抗がある。

というわけでこの1〜2ヶ月くらいずっとストレージを空ける作戦を練っている。断捨離やらこんまり的なものにあまり興味はないが、ストレージを空けるには基本ひとつの手段しかない。すなわち「不要なものを捨てる」。

しかし、不要なものを決められないからこそどんどんストレージが圧迫されていくのだ。まずは不要なものを不要であると認めるところから始めなければならない。

試しに入れてみた程度のアプリは潔く捨てる。ドライバの類ならともかく、大した動機もなくインストールしたアプリは、どうせ次に立ち上げる時にはバージョンアップしていて最新版をダウンロードしなおす羽目になる。ならば使う時にまたダウンロードすればいい。例えば半年使わなかったらもうそのバージョンのアプリは要らないんじゃなかろうか。1年ならまず間違く。確定申告の電子申告作業でさえ、毎年必ず最新版のインストール作業から始まっているではないか。いや、確定申告関連のアプリこそ設定がめんどくさいのでアンインストールしたくないのだが。ともかく確定申告よりも起動頻度が低いアプリは不要である。

「入手できなくなったときのために取っておいたアプリ」というのも、数年経って冷静に見回すともっと便利なアプリが出ていたり、そもそもそのアプリで行なっていた作業自体が要らないということも多い。ファイラとかアーカイバとか、なんであんなにたくさん出回っていたのだろう。……いかん、そんなことを考えるとインターネット老人会からお誘いがきてしまう。

Xcodeが溜め込んでいる古いiOS関連のファイルやバックアップなども捨てた。必要になる場面がもしも出てきたら……、と思って残してみたが一向に出番はなかった。また最近の傾向として「サポートされていないバージョンのOSについては対応しない」という原則がクライアントと合意できることが非常に増えたように思う。野村がそもそもアプリ開発をメインの仕事にしていないのと、クライアントの特性によるところも大きいとは思うが、それが時代の潮流であるようにも感じられる。同様にAndroidも、古いOSに関連するファイルを常に持っている必要はないので削除した。

ドキュメントや作業ファイルなどのデータの要・不要はどう判断するか。

まず「終わった仕事」のデータはセキュリティの観点からストレージにホットスタンバイさせておくべきではない（もちろん破棄すべきデータは破棄した上での話）。事故が起こっては困るので、なるべく早くストレージから引き上げる。「終わったけれどもまだ参照したい仕事」や長期にわたっている仕事は、まず契約単位など時系列で分類して、契約が終わったものは一旦データを引き上げてしまった方が掃除がしやすい。契約終了後にも残しておく必要があるデータ、すなわち現在の契約で使うデータをまた現在の作業フォルダに入れ直す。このように、過去のデータは必要な時に簡単にストレージに入れ直せるようにしておければ良いのではないかと考えている。問題はデータを引き上げる先だ。

データのバックアップはまずDVD-Rメディアに焼いている。どうやらこの手のメディアの耐用年数は10年程度だと思っていた方がよいらしい。10年は短いようにも感じるがこれでもハードディスクやSSD、USBメモリよりは長期保存に適しているのだから仕方ない。で、終わったけれどもまだ参照したいようなデータがDVD-Rメディアだけに入っていると、外出先などですぐに参照できなくて困ることがある。この不安から、ついついストレージに不要なデータをたくさん残しっぱなしにしてしまう。

アプリと同じように、データは必要なときになったらダウンロードすればいいのではないか。つまり、オンラインストレージを使えば良いのではないか。

データをオンラインストレージにおくにはセキュリティの不安がある。そもそも契約上オンラインストレージが利用できない案件もある。とはいえ、例えば「念のため取っておいているデータ」を外付けストレージに入れて持ち歩いたら、今度はそのストレージの故障や紛失が怖い。そう考えると下手なモバイルストレージよりも適正に運用できているオンラインストレージのほうが安全じゃないだろうか。

そんあわけで、今更ながらG Suiteの契約をすることにした。これまで無料のGoogleドライブは使っていたが、無料サービスは有料サービスに比べて、サービス運営側の匙加減でデータを消されてしまう（アカウントを凍結されてしまう）可能性があるし、そもそも15GBの容量ではデータのバックアップ先として足りない。そこで、G Suiteだ。

証明書やパスワード、ログのようなファイルは例外として、移動できそうなファイルはオンラインストレージに退避させることができるのではないか、と考えてぼちぼちファイルを移動させている。手始めにプライベートな実験ファイルなどから。それでも結構な量のデータがストレージに入ったままになっていてびっくりした。2000年のファイルって、何に使うんだよ。このインターネット老人会め。

そんなこんなで何もしないのに比べて40〜50GB程度は空き容量が増えた。ほかにもシステム関連のごみファイルが、何回もOSをアップデートしたりマシンを引っ越したりしているせいで大量にたまっているような気がするが、これを消すにはOSのクリーンインストールがひつようということで、流石にそれはめんどくさい。ひとまずジリ貧な状態乗り切ったからヨシ。