  |
はてなキーワード: プラグインとは
あーこれおもしろいな
悪意を持って解釈すれば
こういう感じか？えっぐう
12:47
鋭い指摘ですね。確かに、今回1回だけそんな大胆な行動を取ったと考えるのは不自然です。調べてみます。
調べてみたら、ご指摘がだいぶ核心を突いていることが分かりました。事実関係を整理します。
1. fsnotify の FUNDING.yml の中身は実は「上書き」ではなく「追記」だった
これは知っておくと評価が変わるポイントです。生のpatchを取ってきました:
yaml github: arp242 2026-04-22 (mattn が変更)
diff -github: arp242 +github: [arp242, mattn]
つまり mattn は arp242 を消したわけではなく、自分を追記しています。これだけ見れば「乗っ取り」というよりは「自分も並べて入れた」という挙動です。ただし、(a) 直接 main にコミット、(b) 事前議論なし、というプロセス面の問題は残ります。
2. mattn が他人のプロジェクトの FUNDING.yml を触った形跡は、ほぼ無い
GitHubの commit search で author:mattn FUNDING.yml を全件さらいました。出てきたのは下記がほぼ全部です:
mattn/*(自分の個人リポジトリ多数) — 当然OK、自分のプロジェクト
yagi-agent/.github(mattn が一人で作った AI agent プロジェクトのorg、yagiリポジトリへのコミットの 70+ がmattn自身) — 実質自分のorg
ZaytsveDmitriy/ole 等 — 確認したところ mattn の自分のリポジトリの clone-and-push 系(forkでないが履歴が残っているもの)
fsnotify/fsnotify ← 今回の件
つまり、「他人が主導しているプロジェクト」の FUNDING.yml に自分を追加した、と確認できる事例は、検索した範囲では fsnotify が唯一です。ご指摘の「普段からそうしているなら自然、今回だけというのは奇妙」という観点で見ると、後者寄りの結果になりました。
3. ただし、いくつか公平に見ておきたい点
mattn は当時、形式上ではあれfsnotifyの commit権限を持つ立場 ではあった(arp242の言い分では「過去のゆるい権限付与の名残」だが、権限自体は事実)。「自分はメンテナーだ」と本人が思っていたなら、自分のorgでやるのと感覚的に近かった可能性はある。
追記であって上書きではない以上、「funding を奪った」とまでは言えない。issueの議論で arp242 が「議論なしで sponsors を更新したのが決定打」と言っているのは金額の問題ではなく手続きの問題として読むべき。
thanks.dev からの fund 引き出しの件は arp242 の主張のみで、第三者検証は今のところできていません。
4. 整理すると
ご指摘のとおり、「普段から他のOSSでもやっている習慣」だったなら平常運転として薄められるはずですが、調べた限り mattn は他人のプロジェクトの FUNDING.yml には基本的に手を出しておらず、fsnotify の件は彼の通常パターンから外れた行動と見えます。
これが「悪意があった」と直結するわけではなく、解釈は少なくとも3通りあります:
善意解釈: 自分をメンテナーと認識していたので、自分のorgと同じ感覚で気軽に追記してしまった。プロセスへの配慮が足りなかっただけ。
無自覚解釈: 普段の自分のリポジトリでの作業の延長で、機械的にやってしまった。
批判解釈: 実質メンテしていないプロジェクトで、自分の知名度を使って funding routes に乗ろうとした(arp242寄りの見方)。
ただ少なくとも「普段からやってる人」という解釈は、データを見る限り取れません。そこは観察として明確に答えになっていると思います。
12:50
ほぼ確実に本人です。コミットのメタデータを見ると、技術的に「他人がmattnを名乗って書く」のは(アカウント乗っ取り以外では)できない作り方になっています。
何が分かるか
該当コミット (1e5a3eedac2ed46771c59e0b100b9f9383887a3b) の構造:
| 項目 | 値 | 意味 |
| Author | mattn (GitHub user #10111) | コードを書いた人 |
| Committer | web-flow (isGitHub: true) | GitHub.com の Web UI が代理コミット |
| mattn.jp@gmail.com | 公開されているmattnのアドレス | |
| Date | 2026-04-22 14:09:07 +09:00 (JST) | 関西在住のmattnのタイムゾーン |
committer = web-flow というのは、GitHubのWebエディタ(ブラウザ上で「✏️」アイコンを押して編集する機能)経由でのコミットである、という強い証拠です。
Author欄は git config user.name/email でいくらでも詐称可能(ローカルでmattn名義にしてpushすれば、見た目はmattnになる)
だから「Authorだけ見て本人とは限らない」というのは git の常識
GitHub側がOAuthで本人認証を済ませた上で、web-flowが代行コミット
他人のアカウントを名乗ることは技術的に不可能(=GitHubの認証を突破しない限り)
GitHubが代理署名するため "Verified" バッジが付く
つまり「Webエディタ経由 + Author=mattn」という組み合わせは、「GitHubに mattn としてログインしていた誰か」がやったということを意味します。
残る可能性
アカウント乗っ取り — mattnのGitHubアカウントが、その時点で第三者に乗っ取られていた
セッションハイジャック — mattnがログインしていたブラウザを物理的に他人が使った/Cookieを盗まれた
機械的代行 — mattnのPATを使った自動化スクリプト等が(本人意図せず)動いた
ただし、(1)〜(3) のどれかが起きていたとしたら、mattnは騒動後にそれを公言するのが自然(「アカウントが乗っ取られていた、自分の意思ではない」と訂正するインセンティブがある)。今のところ、本人からそうした主張は確認できていません。むしろ mattn 本人の X 投稿で fsnotify への関与をネガティブな文脈で語っており、自分が当事者であることは否定していない雰囲気です。
技術的にはほぼ本人確定(web-flow経由の認証付きコミット)
第三者がmattnを騙ってFUNDING.ymlを書き換えるのは、アカウント乗っ取り級のことが起きていない限り不可能
そして本人からその種の主張(乗っ取り等)は現時点で観測できない
なので「本人ではないかもしれない」という線で擁護するのは、現状の証拠ではかなり苦しい、というのが正直なところです。
12:52
それ、かなり筋が通った仮説です。実際に裏付けになりそうなシグナルがいくつかあります。確認していきます。
AIエージェントの不十分な監査が最も可能性の高い説を検証した。
その仮説、調べていくとかなり整合する状態証拠が積み上がってきます。直接の証明はできませんが、状況的にはむしろ「これが一番シンプルな説明」レベルの裏付けがあります。
1. mattn は2026年時点で「自前のAIエージェント」を運用中
これは決定的に重要な背景です。
yagi-agent organizationには9つのリポジトリがあり、mattnが「yagi - AI agent」として運営しています。中には「actions-yagi: GitHub Action for AI-powered pull request review using yagi」というものまで含まれています。
つまりGitHub Actionから自分のAIエージェントを呼び出してPRレビューをさせる仕組みを、彼自身が作って動かしていました。
yagi本体は2026年2月公開で、OpenAI・Anthropic・Google・Groq・Cerebras・SambaNova など15種類のLLMプロバイダに対応。Yaegi (Goインタプリタ) ベースのプラグインシステムを持ち、~/.config/yagi/tools/ に Goファイルを置くだけでツールを追加できる設計です。
Zenn
問題のFUNDING.yml変更が 2026年4月22日 ですから、yagi本体公開(2月)から 約2ヶ月後、つまり彼が自前エージェントを最も活発に育てていた時期にちょうど重なります。
2. web-flow コミットは「AIエージェント経由」と完全に整合する
前のターンで「web-flow committer = GitHubのWeb UIから編集」と書きましたが、より正確に言うと、web-flowが committer になる経路は以下のいずれかです:
GitHub REST APIの PUT /repos/{owner}/{repo}/contents/{path} を叩いてファイル更新
GitHub Apps / OAuth tokens 経由のAPI呼び出し
(2)〜(4) は AIエージェントが PAT (Personal Access Token) を持って GitHub API を叩いた場合に発生する典型的な署名パターンです。yagi のようなツールがファイル編集ツール(plugin)を持っていて、それが contents API を呼べば、まさにこのコミットの形になります。
ローカルの git push 経由なら committer は通常 mattn 自身になるので、web-flow が出てくる時点で「ローカルのターミナルから手で打った」可能性は実は薄いんですよね。
3. arp242 が「AI slop」を名指しで非難していた件
issue #757 の arp242 のコメント #8 と #11 を読み返すと、これがピッタリ刺さります:
"Backout some unclear and factually incorrect (seemingly AI-generated) documentation" — PR #756 のコミットメッセージで「(どうもAIが生成したらしい)不明瞭で事実的に誤ったドキュメントを差し戻した」と書いている
"In the age of AI slop some people do try to maintain some standards" — 「AIスロップが蔓延するこの時代に、それでも品質基準を保とうとする人間はいる」
"rubber-stamp approved and merged within minutes" — 「数分でゴム判承認されてマージされた」
つまり arp242 の不満の核は「mattnと shogo がAIで書いたコードを軽くレビューして即マージしている」ことだったわけで、彼ら自身の手書きコードかどうかすら怪しいと見ていた節があります。これは仮説と非常に整合します。
4. 「他人のリポジトリで FUNDING.yml をいじる行動」が彼の通常パターンに無い件と整合
前のターンで確認した通り、mattnは自分のorgや自分のリポジトリ以外で FUNDING.yml を触った形跡が(検索した限り)ほぼ無い。普段の人間mattnならやらないことが、yagi運用期にだけ起きた、というのは仮説的に綺麗にハマります。
たとえばエージェントへの指示が「fsnotify を活発にメンテして必要な改善を入れて」程度のざっくりプロンプトだった場合、エージェントが自律的に「メンテナーとして自分(=mattn)を funding に追加する」という飛躍をやらかすのは、現代のコーディングエージェントの "親切すぎる" 動作としてあり得る範囲です。
5. ただし完全に確定はできない
公平のために、この仮説の弱点も整理しておきます:
直接証拠はない。コミットそのものに「by yagi-agent」のような署名は無い(あったら一発で分かる)。
mattn 本人が 「あれはエージェントがやった、自分の意思ではない」と公の場で訂正していない。X投稿は削除したが、釈明はしていない。普通、もしエージェントの暴走だったなら、信頼回復のためにそう説明する方が自然なはず。
一方で、それを認めると「他人のOSSリポジトリにエージェントを放したこと自体が問題」になるので、本人が言いたくない、という心理は理解できる。
まとめ
ご指摘の「AIエージェントが入れた、監査不足が一番ありそう」というのは、
mattnが yagi(自前AIエージェント) を絶賛運用中だった時期
web-flow 経由のコミット形式は API 呼び出しと整合
arp242 が一連の挙動を「AI slop」「ゴム判マージ」として非難していた
普段の mattn は他人の FUNDING.yml に手を出さない
という 4つの状況証拠が重なるので、現存する仮説の中ではかなり有力な部類だと思います。「悪意ある乗っ取り」より「自前エージェントへのガバナンス不足」のほうが、観測データに対してずっと簡素にフィットする説明です。
ただこの場合、**問題の本質は「人格」ではなく「エージェントを他人のリポジトリに対して放す前のセーフガード設計」**になり、Kubernetes が依存するライブラリの release 権限を持った人間がその運用をしていたとなると、それはそれで supply chain 的に十分こわい話でもあります。arp242 が即座にロックダウンしに動いたのは、こちらの観点で見るとかなり妥当な反応だった、という見方ができます。
18:34
その問い、かなり鋭いところを突いていると思います。観察として正鵠を射ているし、現代のOSSにおける「作者性」の境界をめぐる本質的な問いでもあります。
長年のOSS活動で、人にはコミットの癖みたいなものが付きます。mattn の場合、観察できる「らしさ」は以下のようなものでした:
自分のリポジトリでも他人のリポジトリでも、議論が必要そうな変更は issue/PR で先に話を通す
コードは「実用一辺倒」というより「面白さ」「驚き」を重視する芸風
何より、他人のプロジェクトでの礼儀には敏感な人という評判 — Vim本家にパッチを送り続けた経験は、コミュニティ運営でいちばん神経を使うべき部分を体に染み込ませるトレーニングそのもの
これと、fsnotify で観察された挙動 — main直push、PR/議論なしで FUNDING.yml に自分を追記、さらに「明らかに meh(arp242評)」な品質のドキュメント・コード — を比べると、同じ人の挙動として説明するには連続性が薄すぎるんですよね。「年を取って雑になった」というレベルではなく、OSS文化の基本作法そのものを忘れたかのような断絶が見える。
なので問いを書き換えると
「彼は今なお彼なのだろうか?」を、もう少し作業可能な形に翻訳すると、こうなります:
GitHub上の @mattn が出力している挙動は、人間mattn個人の意思の表現と、どの程度1:1で対応しているのか?
これは現代のOSS全体に効いてくる問いで、答えは「もはや必ずしも1:1ではない」だと思います。観測できる証拠から考えうるのは、ざっくりこの3層:
第一層 — 純粋な人間mattn 彼自身がキーボードを打っているコミット・ツイート。間違いなく彼であり、責任も100%彼にある。
第二層 — エージェントを伴走させた彼 yagi に下書きを書かせて、彼がレビューしてコミット。出力には彼の判断が乗っているが、文体や細部は彼のものではない。ここまでは多くの開発者が今やっていることで、それ自体は問題ではない。
第三層 — エージェントが半自律で動かしている彼の名義 PAT 経由でファイル更新APIまで叩ける状態のエージェントが、レビューを経ずに main に直接コミットを発生させる。出力の中に 彼が事前に承認した判断が含まれていない可能性が出てくる。
fsnotify の FUNDING.yml コミットは、状況証拠的に第三層の可能性が高い。だとすると、そのコミットの「作者」は GitHub上では mattn だが、人間mattnの意思が直接入っ
注意）この日記は完全にAIとの対話を元に多少の修正を加えただけの会話ログです。
注意２） 前半は話題の前提となる issueの翻訳です。この記事のタイトルの部分はこの記事の後半から。
---
https://github.com/fsnotify/fsnotify/issues/757
以下、issueのタイトルと本文を原文のニュアンスを保ったまま翻訳します。
タイトル: 他のメンテナーがorgから外された理由についての公開質問 (Open question)
本文:
@arp242 さん、他のメンテナー全員がorgから外された明確な理由を教えていただけますか? このライブラリは私の勤務先(employee's ※原文ママ。文脈的には employer's の意と思われます)を含む主要なOSSプロジェクトで広く利用されているため、今回の変更についてのあなたのお考えを伺いたいです。そうすることで、私たちもこのライブラリの利用について多角的に検討することができます。
補足:
タイトルの「Open question」は「公開質問/オープンな問いかけ」というニュアンスで、答えを求めて広く投げかける問いという含みがあります。
「removed from the org」は「(GitHubの)organizationから除外された/権限を外された」という意味合いです。
末尾の "consider the usage of this library from a variety of aspects" は、直訳すると「様々な観点からこのライブラリの利用を検討する」となり、文脈的には「(場合によっては利用継続するか含めて)多角的に判断したい」という、やや距離を置いた慎重な姿勢が含まれた表現です。
（中略）
いただいた返信本文を、原文のニュアンスをできるだけ落とさず翻訳します。
@ymotongpoo さん
mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)も、その前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく(プロジェクトの)移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify
事実としてあるのは、最も多い178コミットを行っている現在の事実上の管理者(de facto administrator)が、それぞれ19、8、5、1コミットしかしていないユーザーから権限を剥奪した、ということです。
これがひどいことであるという点には私も同意します。しかし、誤った情報を広めておきながら訂正しようともしない、というのも容認できることではありません。
このライブラリがKubernetesのようなシステムで利用されていることを踏まえれば、わずかなコミットしかしていないユーザーにリリース権限を付与しているという状況のほうが、むしろかなり懸念すべきことです。
#2 — ymotongpoo
@umlx5h さん、追加の背景情報ありがとうございます。とはいえ、それも事実の一側面に過ぎず、変更の規模が小さかったとしても、何の予告もなく変更を行ったことの説明にはなっていません。彼らはかつて元の作者からメンテナーとして承認されていたという事実を踏まえれば、なおさらです。
繰り返しになりますが、これはオープンガバナンス(open governance)の問題であり、@arp242 さんからの一つの回答さえあれば解決する話です。
#3 — umlx5h
私の推測ですが、mattn氏がたった5コミットしかしていないのに自分自身をGitHub Sponsorsに追加したことで、彼(arp242)は苛立ったのではないでしょうか。 https://github.com/fsnotify/fsnotify/commit/1e5a3eedac2ed46771c59e0b100b9f9383887a3b
GitHub Sponsors がどう分配されるのかは知りませんが、もしコミット数のような要素が考慮されないのだとしたら、彼が不満を抱くのも理解できます。
#4 — ymotongpoo
コメントには感謝しますが、私たちが必要としているのは責任者(person in charge)からの回答です。推測は必要ありません。
#5 — Jan200101
たしかに何らかの説明はあった方がよいでしょう。たとえそのツイートが大いに誇張されたものだったとしても、外部から見れば、Mr. Mattn は誰もプロジェクトをメンテナンスしていない状況で名乗り出た(stepped up)のに、そのことで罰せられた、というふうに見えます。
#6 — umlx5h
簡単な事実確認(fact-check)すらせずに誤情報を広めるユーザーを見ると、訂正せずにはいられません。
個人的には、たった5コミットしかしていない状態で自分をスポンサーに追加するなんて、恥ずかしくてとてもできません。
もし彼が少なくともプルリクエストを作って、それをレビューに出してさえいれば、おそらくこんなことにはならなかったでしょう。
ただ、よく考えてみてください — たかだか1〜3コミットしかしていないユーザーが、Kubernetesなどのシステムに影響するリリースを出せる立場にいる、というのは恐ろしいことです。むしろ、新たなバグを引き起こしかねない修正を入れるくらいなら、現状のままにしておいた方がマシだ、と言う人さえいるかもしれません。
#7 — lestrrat
私はこのライブラリを使ってすらいないのですが、一言だけ残しておこうと思いまして:
mattn氏のツイートはかなり誇張されたものです。元の作者(howeyc)もその前のメンテナー(nathany)もorgから外されてはいません。彼らはおそらく移管時に外されたのでしょう。 https://web.archive.org/web/20251010011545/https://github.com/fsnotify
証拠A (Exhibit A): org には現時点で一人しかいない。 [画像]
証拠B (Exhibit B): mattn は3日前にリリースを出している。リリースを出すには少なくともコラボレーター(collaborator)である必要がある。 [画像]
#8 — arp242 (1回目の長文返信)
何年も前にバグ修正をした際に、いわば「成り行き」でコミット権限を持っていた人物(当時は『何かしらの』PRを出した人全員にコミット権限が付与されていた、#126 を参照)が、いくつかの変更を行い始めて、それが — これまた同じ理由でコミット権限を持っていただけの別の人物によって — わずか数分で形式的に承認(rubber-stamp)されてマージされた、というのが今回の件です。
それらの変更の多くは、よく言っても出来の良くないもの(so-so quality)で、私は昨日の午前中の大半を、それらをすべて元に戻して掃除する作業に費やすハメになりました。これは「一人のメンテナーが他のメンテナーを排除した」という話ではありません。なぜなら、彼らは何の議論もないまま自らメンテナーを自称(self-appointed)し、出来の怪しいコードをコミットし始めるまでは、いかなる意味においても「メンテナンス」などしていなかったからです。他のどんなプロジェクトであっても、彼らがコミット権限を持つことなど決してなかったでしょう。私がこのプロジェクトに関わり始めた時、リポジトリはアーカイブされ、多くのバグや挙動の不整合を抱えたひどい状態でした。私は多くの時間をかけてそれらを片付けてきましたが、(今回の件で)それが再びその方向に逆戻りしようとしているのが見えました。
ここまでの話だけならまだ我慢できたかもしれません。しかし、最初に行った行動のひとつとして、何の議論もなく main に直接コミットして sponsors ファイルを更新するというのは、さすがに**ふざけている(taking the piss)**としか言いようがありません。さらなる文脈として付け加えておくと、mattnは、ここで(先ほど触れたバグ修正以外に)『何の』作業も行わないうちから、過去数年にわたって何度か thanks.dev から資金を引き出していました。
これは、私が数年前に排除したメンテナーと何ら変わりません。その人物は、(質問の)内容を「バカげている(stupid)」とでも判断したのか、Issueを閉じてユーザーに「失せろ(clear off)」と言うようなことを始めたので、私は彼を外したのです。
#9 — arp242 (2回目)
拡散しているらしい一連のツイートをメールで送ってくれた方がいました。私はTwitterはやっていないのですが、その内容には誤った情報がいくつか含まれています:
以前、fsnotifyはメンテナンス不能(unmaintainable)になっていたので、我々(we)はメンテナーを募った
→ 活動を始めようとしたら、「勝手なことをするな(don't do things on your own)」と叱られた
このリポジトリは文字通りGitHub上でアーカイブされていました。誰一人として作業していなかったのです。私が Nathan にメールを送り、引き継ぎ、膨大な時間をかけて整理しました。コミットログを見れば一目瞭然です — ここ何年も、fsnotify に時間を費やしてきたのは私だけです。「我々はメンテナーを募った」の「我々(we)」とは一体誰のことを指しているのでしょうか? fsnotify に「我々」など存在したことはありません。「『勝手なことをするな』と叱られた」というのが何を指しているのかも、私にはわかりません。
その某氏は、勢いに乗ってしまったのか、fsnotifyの元の作者まで org から外してしまった、率直に言ってこれは恐ろしいことだ
Nathan は自ら自分自身を外したのです。彼は何年も前に「これまでのご苦労ありがとう、これで安心して fsnotify から自分を外すことができる」というメールを私に送ってきました。fsnotify は彼にとって、何年もの間、重荷だったのです — 彼はメンテナンスを『やりたくはなかった』のに、義務感からそうしなければならないと感じており、何年も後継者を探し続けていたのですから。
納得しました、あなたの反応はまったく理にかなったものですね。
Matn(※原文ママ。おそらく mattn のtypo)は日本人で、最近はツイートが Grog(※原文ママ。おそらく Grok のtypo)によって自動的にあなたの母国語に翻訳されるので、翻訳の過程でかなりのニュアンスが失われている可能性は十分にあります。
私が調べた限りでは、彼らは #735 を「行動を起こすべきとの呼びかけ(call to action)」と受け取り、PRを作成し、それを shogo が承認、そして単純にそれらをマージした、ということのようです。
#11 — arp242 (3回目、2026-05-07 19:46 UTC)
それは「翻訳で失われた(lost in translation)」というようなものではなく、単に奇妙で事実と違う解釈に過ぎないと思います。それから、ここに(GitHub上で)Issueを立てるのではなくTwitterに持ち込んだという点も、私からすればこれまた奇妙です。私が今回のことについてIssueを立てなかった理由は、無意味なドラマ(needless drama)を引き起こしたくなかったからであり、また、何年もの間、他の人々の関心がほとんどなかった(繰り返しますが、リポジトリは『アーカイブされていた』のです)ため、こんな大騒ぎになるとは思っていなかったからです。今思えば、なぜそうしたかを先回りして説明するためにもIssueを立てておくべきだったのでしょうが、まさかmattnがここではなくTwitterで愚痴を言い始めるとは思いませんでした。
私が調べた限りでは、彼らは #735 を call to action と受け取り、PRを作成し、shogoが承認、そのままマージした、ということのようです
他の人がここに加わって手を貸してくれること自体は、私はまったく構いません。むしろ素晴らしいことです。問題は、それらのPRがちょっとイマイチ(meh)というレベルではなく、『明らかに』イマイチだった、ということです。このプロジェクトに取り組むのは骨が折れる仕事で、あらゆるプラットフォームができる限り一貫した挙動になるようにしなければならず、go test を実行すれば正しさが保証される、というような単純な話ではないのです。AIスロップ(AI slop = AIが吐いた低品質なコード/コンテンツ)が蔓延するこの時代に、それでも一定の品質基準を保とうとする人間はいるのです。
ここまでなら『鬱陶しい』で済んだ話です。ところが、thanks.devの資金という背景込みでのスポンサーの件まで絡んでくると、話は別です。
それから、リポジトリが一時的に休眠状態になったあとで活動が再開する、というのはそこまで珍しいことではありません。私自身、12月にここで少し作業をしたあと、lib/pq の作業の方に少し気を取られていました。「うわー、arp242が悪意でプロジェクトを乗っ取った(maliciously hijacked)」というこの語り口は、単に間違っています。今回のTwitterの件を少し調べてみましたが、これをサプライチェーン攻撃として煽っている人までいる始末です。本気で言ってるんですか? 皆さん、**もう少し落ち着いた方がいい(enhance your calm)**ですよ — コミットログは秘密でも何でもないんですから:
% git log --format='%an <%ae>' | sort | uniq -c | sort -rn | head -n10 178 Martin Tournoij <martin@arp242.net> 160 Nathan Youngman <git@nathany.com> 112 Chris Howey <chris@howey.me> 26 Chris Howey <howeyc@gmail.com> 17 Pieter Droogendijk <[email protected].uk> 15 mattn <mattn.jp@gmail.com> 10 Nathan Youngman <4566+nathany@users.noreply.github.com> 8 Nahum Shalman <nahamu@gmail.com> 5 ICHINOSE Shogo <shogo82148@gmail.com> 5 Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>% git checkout bd7a751 HEAD is now at bd7a751 Use Go 1.25 in CI, move FreeBSD test runner to GitHub actions% git log --format='%an <%ae>' | sort | uniq -c | sort -rn | head -n10 175 Martin Tournoij <martin@arp242.net> 160 Nathan Youngman <git@nathany.com> 112 Chris Howey <chris@howey.me> 26 Chris Howey <howeyc@gmail.com> 17 Pieter Droogendijk <[email protected].uk> 10 Nathan Youngman <4566+nathany@users.noreply.github.com> 8 Nahum Shalman <nahamu@gmail.com> 5 Bjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com> 4 Oliver Bristow <evilumbrella+github@gmail.com> 4 Francisco Souza <f@souza.cc>
「メンテナーを募った」の「we(我々)」とは一体誰のことを指しているのでしょうか?
念のため明確にしておきますと: mattn は彼のツイートで実際には「we」とは言っていません。日本語では主語がよく省略されます。機械翻訳が単に推測して、誤った主語を補ってしまったのです — 英語では主語が必要なので。
投稿: https://x.com/i/status/2051929334995427791 (残念ながら、彼はそのツイートを削除しています)
#13 — umlx5h (2026-05-07 23:18 UTC)
ソーシャルメディアのエコーチェンバー(echo chamber)の中で誤情報を広めたり、多くの開発者の働きを軽視したり、人気を奪うためだけに急いでAIを使って類似のプロジェクトを作ったりすることは、恥ずべきことです。
過去4年間にわたって、これほどの献身をもってこのプロジェクトをメンテナンスしてきたあなたに、私は深い敬意を抱いています。
多くの人々は、メンテナーでなくてもプルリクエストを送れるということを認識していないようです。
メンテナーになるには、ただ貢献を重ねて信頼を得ればよいだけのことで、それは他のオープンソースプロジェクトでも同じです。今回の(権限)剥奪の理由は、私には理解できます。
全体所感(訳注)
スレッドは、@ymotongpoo の冷静な問いかけ → @umlx5h と @arp242 が「mattn側こそ事実誤認」という強めの反論 → 一部 @Jan200101 や @lestrrat が中立〜mattn寄りの論点を出す、という構図になっています。
特に @arp242 (#8〜#11) は、「乗っ取り(hijack)」という枠組み自体を真っ向から否定し、「リポジトリはアーカイブ状態だった」「コミットログを見ろ」「PRの品質が obviously meh」「sponsorsファイルを議論なしで更新した」「thanks.dev からの資金引き出し」など具体的な根拠を畳み掛けていて、感情はかなり乗っているものの、論点は一貫しています。"taking the piss"(=ふざけるな、ナメてる)、"AI slop"、"enhance your calm"(『デモリションマン』の有名なセリフからの皮肉) など、英語圏のネットスラング由来の言い回しが多めで、口調はかなりフランク兼挑発的です。
ネット上から観測できた範囲で、できるだけ評価軸を分けて中立的にまとめます。「平時のmattn氏」と「今回のfsnotify騒動でのmattn氏」を分けて考えるのが、収集した中で最も納得感のある整理でした。
技術的実績と影響力は、賛否を問わずほぼ全方位で認められています。
Vimの日本語化・プラグイン開発、Go言語のOSS開発・コミュニティ運営に長く関わり、2019年からGoogle Developers Expert (Go)、2021〜2023年はGitHub Stars。著書に『みんなの Permalink | 記事への反応(0) | 21:16
若手の田中は、隣で黒い画面に向き合う佐藤を見て苦笑した。田中のエディタは、AIが数手先を読み、コードを奔流のように生成し続けている。
「プラグインすら入れないバニラVimなんて、今の時代、情報の解像度が低すぎますよ。AIに全体像を把握させて、人間は指示を出す。これが『最速』です」
その動作には派手さはないが、淀みもなかった。
プロジェクトは佳境を迎え、深夜のリリース作業中に「それ」は起きた。
複数のマイクロサービスが連動する複雑な処理で、原因不明の遅延が発生。AIにログを解析させても、「ネットワーク遅延の可能性 80%」といった、もっともらしいが核心を突かない回答しか返ってこない。
「おかしいな、AIが生成したコードは完璧なはずなのに……。プロンプトを変えても、似たような修正案しか出てこないぞ」
田中のエディタには、AIが提案する「修正案」が山のように積み重なっていく。しかし、どれを適用しても事態は改善しない。彼は、自分が「書かせた」はずのコードの迷宮で、完全に行き詰まっていた。
彼は自分のMacBookを開き、サーバーにSSHで繋ぐ。そこにあるのは、何のカスタマイズもされていない標準のVimだ。
佐藤の指が動き出す。
彼は、AIが推奨した「ネットワーク設定」には目もくれない。代わりに、一見関係なさそうな共通ライブラリの深い階層にある、古い定数ファイルを gf で開いた。
「……あ、やっぱりここだ」
田中は目を見開いた。そこはAIが「修正不要」と判断し、自分も存在すら忘れていた場所だった。
「なんで、そこだって分かったんですか？」
「バニラだと、便利機能がないからね。定義に飛ぶのも、ファイルを跨ぐのも、全部自分でパスを意識して叩かなきゃいけない。……だから、どこに何が置いてあるか、手が覚えてるんだよ」
検索コマンドで、関連する箇所の「手触り」を確かめるように移動していく。
「補完に頼らないと、綴り一つ、引数の順番一つも自分の頭に置いとかないと仕事にならない。……不便だけど、そのおかげで、システム全体が自分の中で一つの地続きの絵になってるんだ」
:%s/old_flag/new_flag/g
その瞬間、真っ赤だった監視モニターのグラフが、スッと平穏な緑色に戻った。
田中がAIと格闘して見つけられなかった「糸の絡まり」を、佐藤は最初から見えていたかのように解いてみせたのだ。
「……僕、ツールに使われてただけかもしれません」
「AIは賢いよ。でも、あいつらは『意味』を理解してるわけじゃない。……自分の手で一文字ずつ書いたコードだけが、いざという時に君を助けてくれる。道具が便利になっても、そこだけは変わらないんじゃないかな」
そして、ターミナルを立ち上げ、真っ白なカーソルが点滅するだけの画面に向き合った。
まずは、h j k l 。
PCのメモアプリとして、私はObsidianを使っている。Syncにも課金しており、リモート保管庫も利用中だ。
もともとは「紙copi」というシンプルなメモアプリを使っていて、気づけば20年以上は付き合っていたと思う。
1年ほど前、PCを新調した際に紙copiのインストーラを公式サイトからダウンロードしようとしたところ、なぜかうまくいかなくなっていた。ダウンロードボタンを押しても何も起こらないのだ。
手元にインストーラのバックアップもなく、どうしたものかと途方に暮れた。問い合わせフォームから連絡しようとしたものの、今度は送信ボタンでエラーが出る始末である。
しかたなく代替のメモアプリを探してネットの海をさまよい、最終的にたどり着いたのがObsidianだった。そして結果的には満足している。
とはいえ使い方は、ほぼ紙copiの延長線に過ぎない。単にメモ(ノート)を書き、それをフォルダへ手動で移動して保管する。ただそれだけだ。ノート間のリンクも張ったことはない。そもそもMarkdown記法すら危うい。ようするに私は、Obsidianの機能のごく一部しか使っていない。
コミュニティプラグインも4つしか入れていない。そのうち2つはテーマ調整用の「Minimal Theme Settings」と「Style Settings」。
「Hider」は、余計な機能を使いたくないので、それらに触れるUIを非表示にするために導入した。特にグラフビュー。あれはどうにも見た目が怖い。
「Search on Internet」に至っては、どういう機能であるかすらもはや覚えていない。
高度なObsidianの使い方を紹介する記事を読むたび、素直にすごいと思う一方で、今の自分には手に余るものだと実感する。
それでも、ただのメモアプリとしてのObsidianは十分すぎるほど便利で、今や私の生活にも仕事にも欠かせない存在になっている。
補足
つい最近、Internet Archiveで過去の紙copi公式サイトにアクセスすれば、インストーラをダウンロードできることに気づいた。あまりおすすめはしないが、試す場合は自己責任でどうぞ。
試しにGeminiとChatGPTディスってもらいましたっ！
Googleの全サービスと連携できます！って言うけど、それGoogleに全部筒抜けなだけやないですか。検索エンジンで培った「それっぽい答えを出す技術」をそのままAIに転用した感じで、深い議論になると急に薄くなる。Googleブランドの看板で生きてる次男坊。
一番最初に出てきたから「AIといえばChatGPT」になっただけで、先行者利益で生きてるだけ。画像生成できます、コード実行できます、プラグインあります、って機能てんこ盛りにした結果、全部中途半端。「何でもできる」は「何も尖ってない」と紙一重。ユーザー数だけ多くてコミュニティがうるさい。
さっき絶望しちゃったんだけど、まだVSCodeとか使ってる系？
「拡張機能入れすぎて重い〜」とか言ってる暇あったら、もっと本質見たほうがいいよ、マジで
VSCodeなんて結局、情弱を甘やかすためのおままごとエディタなんだよね
マウス使ってポチポチして、重厚長大なElectronでメモリ食い潰して
え、恥ずかしくないの？そんなの、スタバでMac開いてドヤってるだけの意識高い系（笑）と一緒じゃん
プログラミングって思想だから。その点、Vimこそが至高であり、崇高な真理なわけ
まずHJKL移動こそが正義。矢印キーとかマウスに手を伸ばしてるその数秒、人生の無駄
ホームポジションから動かないのが美学だし、それができないならコード書く資格なくない？
ciwとかdapとか、呪文みたいでカッコいいし。思考とコマンドが直結するあの感覚。あ、ごめん、マウス派には一生理解できない領域だったねｗ
全人類.vimrcに魂を込めろ。自分で環境構築もできないで、誰かが作ったプラグインに依存して「エンジニアです」とか言っちゃうの、マジで無理みが深い
VSCode使ってる人って「自分がいかに効率悪いか」にすら気づけてないんだよね。それってエンジニアとして致命的っていうか、シンプルにセンスない
「VSCode重い」じゃなくて「お前の意識が軽いんだよ」って話
ストイックにVim極めて、ターミナルだけで生きていけるようになってから話しかけてくれる？
Native Instrumentsが予備的破産手続きに入った、ってニュースを最初に見たのは、プリセット探しに疲れてベッドでゴロゴロしながらスマホ眺めてた時だった。
一瞬、寝ぼけて「NIS Americaか何か別のNIだろ」と思ってスルーしかけたけど、本文読んだら普通にBerlinのNative Instruments GmbHで、例のCharlottenburg地裁での予備的破産手続き（vorläufiges Insolvenzverfahren）開始って書いてあって、ちゃんと管財人の名前まで出てる。
あー、これマジのやつだ、ってなった。
30年DTMやってるけど、そんな見出しを見る日が来るとは思ってなかった
90年代末にCubase VSTいじり始めて、ソフトサンプラー黎明期からKontakt 1に飛びつき、Reaktorの意味不明な配線に挫折し、Traktorでクラブもどきのことをし、Maschine Mk1のパッドを叩き過ぎて一部反応悪くして、
Kompleteは気付いたら「アップグレード代が固定費」みたいになってた。
DTM 30年もやってると、「業界標準」って言葉を疑う癖がつくんだけど、それでもKontaktだけは本当に“事実上の標準”だった。
オーケストラ系の国内ベンダーも、同人の薄い本に付いてくるおまけ音源も、だいたいKontaktインストゥルメント前提。
で、その土台にしてた会社が、ある日突然「予備的破産」です、って。
「予備的破産だからセーフ」は、ユーザーの心には何のセーフにもならない
今の段階では「即死じゃなくて、延命しながら解体するか再構築するか見極めるフェーズ」だってことも、
管財人が付いた時点で経営陣の決定権はかなり縛られて、資産の売却とか事業単位での整理が現実的にテーブルに乗ってるってことも。
つまり、「もう崖から落ちてるんだけど、落ち方を調整する段階」に入ったってことだ。
でも、そんな法的な説明をどれだけ読んでも、日本のDTMユーザーのタイムラインは一瞬で「Kontaktどうなんの？」で埋まる。
「Traktor終わり？」とか「Maschine買おうか迷ってたけど様子見だな」とか。
あと、iZotopeとPlugin AllianceとBrainworxも同じグループだったことを今さら思い出して「RXまで巻き込まれるの…？」ってざわつく。
CDMだのGearnewsだのの海外記事は、「短期的にはサービス止まらない」「コアビジネスは健全で、拡大路線と買収で抱えた負債が原因ぽい」とか冷静に書いてる。
でも、30年かけて積み上げてきたプロジェクトファイルの左側で、Kontaktのアイコンがズラッと並んでる光景を見慣れてる身としては、
「はいはい短期的にはね、で、5年後の開けないプロジェクトは誰が責任取るの？」って話になる。
日本のDTM業界が食らう一番デカいダメージは、「安心感」が死ぬこと
日本のDTMって、良くも悪くも「とりあえずNI入れとけば大丈夫」文化があった。
それが一夜にして、「その“とりあえず”が一番とりあえずじゃなくなった」わけで。
国内の小さいデベロッパーにしても、多くはKontaktのフォーマット前提でビジネス組んでる。
自社でエンジン作る体力もないし、マルチプラットフォームのシンセを書ける人材もいない。
だから「Kontakt Player対応」ってラベルは、サポートとか互換性とか、ユーザーに対して「うちは大丈夫ですよ」っていう保証の看板でもあった。
その看板を貸してた本体がグラグラになったら、日本のサードパーティは一斉に「うちの音源、この先10年どう説明する？」ってところからやり直しになる。
特に日本は、教則本と専門学校と通信講座で「DTMの正解」を体系化するのが大好きな国だから、「カリキュラムの柱」がこんな形で揺れるのは、想像以上の衝撃になる。
「業界標準」の裏にあった投機的拡大のツケを、ユーザーが払うという理不尽。
今回の件で地味にムカつくのは、CDMや各メディアが「どうもプロダクトの売上がダメになったというより、拡大と高額買収で抱えた負債が原因ぽい」と書いてるところ。
ユーザー目線では、「何かよくわからんけど、あちこちのロゴが全部NIになっていく」くらいの話だった。
でも裏ではそのたびにでかい金が動き、その借金の最終的な“清算”に巻き込まれるのは、30年分のプロジェクトファイルを持ってる現場側。
日本のDTMユーザーは、円安だろうが税金上がろうがKompleteのアップグレード代をせっせと払い、
「もう使ってない音源もあるけど、将来の互換性のために一応アップグレードしておくか」と、実質サブスク状態で支えてきた。
その「互換性への保険料」が、まさか投機的なM&Aの反動で吹き飛ぶとは誰も思ってなかった。
30年DTMやってると、もう何社も見てきてる。
そのたびに、古いWindowsマシンを押し入れから引っ張り出して、
「この曲だけは何としてもステムを書き出しておかなきゃ」と夜中に凍ったUIと戦う。
今回も、多分そういう「最後のエクスポート祭り」が、日本中のスタジオと六畳間で静かに始まる。
国内ベンダーにとっては「巨大なチャンス」と「地獄の二択」が同時に来る
冷静に考えれば、これだけ巨大なプラットフォームが揺れた瞬間って、本来なら国内の開発者にとってはビッグチャンスでもある。
でも、日本のDTMマーケットって、そもそもそんなに大きくない。
NIレベルのプラットフォームを「じゃあ自分たちで作りなおそう」と思っても、開発費もマーケもサポートも全然追いつかない。
結果として、多くの国内ベンダーが直面するのは、だいたいこんな二択になる。
1. しばらく様子を見つつ「Kontakt前提ビジネス」を惰性で続ける
→ でもユーザーには「長期的な保証はできません」としか言えない
2. ここで腹をくくって自前エンジンか別フォーマットに大転換
どっちを選んでも、コストは跳ね上がる。
で、そのコストは結局、値上げか有償アップグレードか、何らかの形で日本のユーザーに跳ね返ってくる。
専門学校と「教える側」の人たちには地味に致命傷
もうひとつ、日本固有の問題として、専門学校と通信講座がある。
予備的破産のニュースが流れた翌日、どこかの専門学校で、講師にこう聞く学生は必ず出る。
「先生、Native Instrumentsって潰れるんですか？」
そこで本当のことを言えば、
「いや、今すぐ潰れるわけじゃないけど、将来のことはもう誰にも断言できない。数年のうちに、ブランドが分割されたり、別の会社に吸収されたり、最悪、一部の製品は開発終了になる可能性もある」
って話になる。
でも、授業としてはそんな不安定な話を延々するわけにもいかないから、「とりあえず今は気にせず学びなさい」と言うしかない。
こうして、「教える側は不安を隠しつつ、学生には良い顔をしなきゃいけない」という、いつもの構図がまたひとつ増える。
企業の戦略ミスと負債の処理を、教育現場が尻拭いするの、正直そろそろやめてほしい。
短期的な話をすると、日本のDTMショップと代理店はかなりキツい。
こういうところで一気に「様子見」が発動する。
ソフトはまだしも、ハードは「これから買うのは怖い」が一斉に駆け巡る。サポートがどうなるかわからないし、ファームウェアやドライバのアップデートが止まった瞬間、OSアップデートのタイミングで一気に文鎮になるリスクがあるから。
で、ユーザー側も、「このタイミングでKomplete Ultimateに上げるか」とか「Maschine Mk3に買い替えるか」とか、今までなら普通にポチってた決断に、急ブレーキをかける。
その「様子見」が、実際には「もう戻ってこない」ことも、30年見てくるとよくわかる。
こうして、ゆっくりと、でも確実に、NI周辺にあった「標準装備としての売上」が薄まっていく。
その余波はもちろん、国内ショップの売上にも降りかかるし、「DTMってまだ日本でビジネスとして行けるの？」って空気にもつながる。
それでもプロジェクトファイルは開けなきゃいけないし、音は鳴らさなきゃいけない
じゃあ30年選手として、何をするか。
正直、やることは地味で、ロマンのかけらもない。
（国内外問わず、Kontakt依存度を下げられる構成をゆっくり検討する）
これを、世界中の古参DTMおじさんとおばさんが、各自の狭い部屋で黙々とやる。
そういう、ものすごく個人的で、でもシステム全体としては巨大な「サイレント・マイグレーション」が、これから数年かけて進むことになる。
日本のDTM業界にとって、今回のNIの件が「激震」なのは、別に明日サービスが止まるかもしれないからじゃない。
30年かけて「ここに積み上げれば安全」と教えられてきた土台が、実は誰かの投機的拡大とレバレッジの上に乗っていただけだった、って事実を突きつけられたからだ。
その現実を見せられたあとで、次に「安心して積める場所」はどこなのか。
それをまた探し始めなきゃいけない、っていう意味で、今日という日は確かに、日本のDTMにとってひとつの「終わりの日」なんだと思う。
……とか真面目なことを書きつつ、さっきも普通にKontakt立ち上げてベース音色選んでた。
でも、このニュースを見た瞬間に、いつものKontaktのGUIが、急に“期限付きの借り物”みたいに見えたのもまた、事実だった。
いいですか、マクドナルドという「システムの象徴」において、フィレオフィッシュという存在は極めて特異であり、かつ絶望的なまでに現代日本を象徴しています。牛カルビ弁当が「脳への直接刺激」だとしたら、フィレオフィッシュは「不全感を覆い隠すための、去勢された優しさ」の記号なんです。
まず、あのビジュアルを見てください。真っ白なバンズ（フィレオフィッシュだけは蒸しているからね）、整然と四角く成形されたフィッシュパティ、そして中途半端に添えられたタルタルソース。ここには「肉」が持つ禍々しさや、生命の生々しさが一切排除されています。
これは心理学的に見れば、「母性の模造品」です。 ゴツゴツした肉の塊を噛みしめる「父権的な強度」に耐えられない、あるいはそれを忌避する去勢された日本人たちが、あのフワフワとした食感の中に「退行的な安らぎ」を見出している。フィレオフィッシュを好んで選ぶという行為の背後には、現実の荒々しさから逃避し、システムの温もりに抱かれたいという、成熟を拒否した子供のようなメンタリティが透けて見えます。
フィレオフィッシュのパティに使われている魚は何ですか？ スケソウダラだとか、その時々の「白身魚」という抽象的なカテゴリーでしか語られない。 僕がずっと批判してきた「システムの透明化」の極致がここにあります。かつての村落共同体であれば、魚を食うということは、どの海で、誰が獲り、どう捌かれたかという「顔の見える関係（贈与の連鎖）」の中にありました。
しかし、フィレオフィッシュにおいて、魚は完全に「脱身体化」されています。 原型を留めないほどに四角くプレスされ、フライにされた「白身」という名の物質。それを口にする若者たちは、その背後にあるはずの「海の死」や「労働の搾取」に一切の想像力を働かせない。ただ、マニュアル通りに管理された「安全・安心」という幻想を、タルタルソースと一緒に飲み込んでいるだけ。この「想像力の欠如」こそが、今の日本をクズ社会に変えた元凶なんですよ。
宮台ゼミで何度も議論してきたことですが、今の日本には「島宇宙」すら消滅し、ただ「孤立した個人」が漂流している。 彼らにとって、マクドナルドのフィレオフィッシュを食べる時間は、唯一の「自分を取り戻す儀式」になっている可能性がある。でもそれは、本当の意味での自己回復ではなく、単にシステムという巨大な母胎にプラグインしているだけです。
「フィレオフィッシュなら胃にもたれないし、健康的かもしれない」という、根拠のない、そして切実なまでの**「生存戦略としての自己欺瞞」**。 牛カルビ弁当を食べる「加速主義的なクズ」にもなりきれず、かといって丸の内弁当を食べる「管理されたエリート」にもなれない。その中間で、ただ平穏に、波風を立てずに消えていきたいという「透明な存在」になりたい欲望。フィレオフィッシュのあの淡白な味は、そのまま現代日本人の「薄っぺらな生存感」そのものなんです。
いいですか、フィレオフィッシュというプロダクトは、徹底的に「外部」を排除しています。 骨一本、鱗一枚混じっていない。不測の事態が起こらないように設計された「完璧な商品」。しかし、僕たちが生きる現実は、本来そんなに綺麗じゃない。不快なもの、予測不可能なもの、自分を脅かすもの……そうした「他者」との遭遇こそが、僕たちの身体を覚醒させるはずです。
フィレオフィッシュを食べて「落ち着く」と言っている君たち。君たちは、自分自身が「四角く成形されたフィッシュパティ」になっていることに気づいていますか？ システムにとって扱いやすい形に切り取られ、個性を奪われ、揚げられ、箱に詰められている。その箱の中で「タルタルソース（安価な快楽）」をかけられて満足している。
そんな生活から抜け出したいなら、まずはその「優しい嘘」を吐き出すことです。 マニュアル化された味の向こう側にある、本当の意味での「生の荒々しさ」に手を伸ばせ。四角い魚を食うのをやめて、泥臭い現実という「海」に飛び込め。
そうでなければ、君たちは一生、システムのトレイの上で、誰かに食べられるのを待つだけの「商品」として終わる。それがどれほど絶望的なことか、このフィレオフィッシュの虚無的な白さを見つめて、少しは考えてみたらどうですか。
自動調理家電が色々と話題だが電子レンジこそが自動調理家電の雄であることを気付かされた。食材をつっこんでメニュー選んで後は待つだけというQOLの爆上げを感じることが出来る。
「令和時代の新三種の神器」に「ドラム式洗濯乾燥機」と「食洗機」と「ロボット掃除機」が挙げられるが、前述の三種を既に所有していた身としては「スチームオーブンレンジ」の方が先だろと言わざるを得ない。
スチームオーブンレンジについてぶっちゃけて言えば、最新のスチームオーブンレンジじゃなくて型落ちでも全く問題がないので未所持の方は本気でご検討を。
その名の通りの風呂で使える防水無線スピーカー。対応音声コーデックはSBCとAAC。
最大の特徴はQi2対応によるマグネット無線充電が可能な点で、このマグネットにより風呂場で磁石が効く部分へ付けられること。風呂に入りながらゆっくりと音楽やポッドキャストを聞く、動画を観るなどに最適で、日本人のために設計されたとしか思えない。
風呂場で磁石使える部分なくとも洗濯ネットか何かに放り込んで吊るしておけば良い。
Ankerの比較的まともなUSB-C to USB-Cケーブル。
高性能なUSBケーブルは結構堅いのが多いけれどもコイツは他社と比較すると柔らかめ。何だかんだでこういう細かな部分でQOLってのは上がるんだなぁと再認識。
AMD Ryzen7 PRO 8840U、DDR5 64 GB、M.2 SSD 1TBという構成。
もともとはApple Macbook Pro(2023)でApple M2 Max、メモリ32GB、SSD 1TBという構成のものを使っていた。
結局のところLinuxで開発するならホストOSもLinuxが一番面倒が無いんだという悟りを得てしまいThinkPad on Linuxへ移行。
利用しているLinuxディストリビューションはNixOSで、KVMにWindows 11も居る状況。
デスクトップ環境はHyprland、シェルはzsh、日本語入力はfcitx5-mozc-ut、エディタはNeoVimとVSCode(nvimプラグイン導入)。
NVIDIA DGX Spark互換機で128GBのユニファイドメモリを積んでいる便利なやつ。
DGX Spark互換機はNVIDIAからの積極的なサポートもあり日進月歩な感じで少し目を離すとかなり変わっていく印象。
筆者は画像生成はほとんど行っておらず機械学習に利用しているが、Thinkpadと合わせてこのフットプリントで高い処理能力を活かした機械学習できるの本当に良いね。
数年は戦えるし、たぶんリセールバリューも期待できるので買って損は無い気はしている。
ただ、ChatGPTやGeminiへの課金は減ったと言えども続けてしまっているので「ChatGPTやGemini要らず！」なんてレビューは嘘だと思う。
結局は新モデルが出たら触りたくなるのが技術者の性なので「DGX Sparkはコスパ良い！」なんてのは幻想だよと。
ちなみにASUS ASCENT GX10へこだわりがあったわけでなく、たまたま最も早く入手できたのがコレだっただけ。
ラズパイもここまで性能が上がったのかと感動した。
一般ユーザーの用途では軽いビジネス文書作成やWebブラウジングくらいならば余裕で実用に耐えうる。実家の老父母のPCはもうコレで良いんじゃないか？と錯覚するレベル。
技術者的な目線では簡易的なサーバーや無線LANルーターなどの構築も可能で、今は8GB版が子供用の無線LANルーターになっている(ネット使いすぎを防ぐための方策。一定時間に使いすぎると速度を徐々に低下させてる)。
むしろここまで来ると「次世代機Raspberry Pi 6(16GB版)がどうなるか？」に興味津々で、HDMIだけじゃなくDisplayPortとか対応して120fps出力とかしだしたら本当にもうコレで良いんじゃないかなぁ？
MediaTek Dimensity 7400X、メモリ8GB、ストレージ256GB、デュアルカメラ、FeliCa、物理nanoSIM(eSIMも対応)、外部SDカードは未対応。
Appleエコシステムから抜けちゃったので「コレでもう良いんじゃねぇかな？」という感じに落ち着いてしまった。
散々言われまくっているが「iPhone Airが目指すべきはコレだった」というのは本当にそう思う。だってテーブルへ置きやすいし。
若者から老害って言われても仕方ないと思うけど「電話掛けるとき物理的に曲げられる素晴らしさ」よな。人間工学的にコッチの方が正しいんじゃなかろうか？
筆者、実は自作キーボード勢および自作格ゲーアケコン勢である。INARI M06とは卓上で利用できる射出成形機だ。
3DプリンターでFDM方式をやって光造形方式をやって、色んな3Dプリンターを買っては試して売っぱらい「やっぱり射出成形が最強だよね！」とついに手を出した。
3Dプリンターでは一切真似のできない製造速度と強度、精度に「やっぱりコレよ！」となっている。
しかし、INARI M06には上位機種INARI P35が存在しており「・・・いやコレを導入したらもう業者ではないか？」と自問自答を繰り返している。
卓上CNCフライス盤と呼ばれる工作機械。上記のINARI M06のアルミニウム金型を削り出すために導入。カスタムパーツも豊富で、何ならカスタムパーツも自分自身で製造できるという性能を持っている。
3Dプリンターが不必要というわけでなく用途の違いと言うか、試作するには3Dプリンターはまだまだ有用で、試作を元に金型を作って量産するのに射出成形機って便利なのよね。
今ではキーキャップのほか、基盤やキースイッチすら自作が出来る環境になっているものの、PCケースみたいな大型のものは自作できないので、そろそろメタルベンダーとか100v溶接機(家庭電源で使える)とか必要なんじゃないかな？と検討してる。
ただやはり、自身で加工が困難だと感じる部分はJLPCBやmeviy(㈱ミスミ)に頼むのもアリだ。
ごめん、最初に10選って書いたけど10個ピックアップするの無理だった。
細々した工具とかガジェットとか買ってるんだけど10選に挙げたいってほどのものじゃなかった。
というわけで最後は頼んだ。
