  |
はてなキーワード: Cookieとは
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
“ 「Save Image as Type」はもともと個人開発の無害なツールだった。扱いづらいWebp形式の画像を、JPGやPNGといった扱いやすい形式に簡単に変換して保存でき、世界で多くのユーザーが使っていた”
“ 悪意あるコードの注入が発覚したのは24年後半。所有者の変更が関連しているとみられている”
“ ユーザーがWebページを開くと、隠しiframeでAmazonやBest Buyなどの通販サイトを読み込み、アフィリエイト用のCookieをブラウザに植え付ける。ユーザーがその後に買い物すると、攻撃者側に紹介料が入る仕組みだ”
「プライバシー保護」というと、巨大IT企業によるデータ収集への対抗策として語られることが多いですが、私たち個人にとって、もっと切実で身近なリスクがあります。
ふとした瞬間に画面を見られたり、あるいは自分の死後にスマホのロックが解除されたりしたとき、そこには「誰にも見せたくない自分」が詰まっています。あなたの趣味嗜好、行動範囲、検索履歴……これらが家族に筒抜けになることは、時として人生に甚大なインパクトを与えかねません。
本記事では、生粋のAndroidユーザーである筆者が実践している、「ロック解除状態でスマホを渡しても致命傷を負わないための設定」を解説します。対象はGoogle Pixel（Android 14/15）およびBraveブラウザです。
まず大前提として、スマホのロック解除に使う6桁暗証番号は、iPadやPCなど他のデバイスと必ず別にしてください。「どうせ同じ番号だろう」と推測されるのを防ぐための最低限の対策です。
まずはOSレベルで「無意識に記録されるデータ」を徹底的に排除します。便利機能の多くは、プライバシーのリスクと表裏一体です。
「いつどこにいたか」は雄弁なプライバシー情報です。Googleマップのタイムライン機能は便利ですが、行動を詳細に記録する必要がないならオフにすべきです。
マップ利用時のみ位置情報をONにし、ログとしては残さない運用が最も安全です。
人に検索画面を見せて文字を入力しようとした瞬間、予測変換に「恥ずかしいワード」が表示される……これこそが最も恐れるべき事態です。Gboardの学習機能を無効化し、リスクを排除します。
特に「連絡先の候補」をOFFにすることで、連絡先に登録している特定の人名などが変換候補に出るのを防げます。
クラウドへの自動バックアップは便利ですが、「見られても良い写真」と「そうでない写真」が混在したままクラウドに上がるのは危険です。写真はローカルで選別し、必要なものだけを手動で上げる運用にします。
アップロードしたい写真を選択し、[今すぐバックアップ]（雲のアイコン）をタップするだけです。
また、絶対に見られたくない写真は、Googleフォトとは別のクラウドサービス（後述）に退避させ、ローカル端末からは即座に削除しましょう。
Googleの電話アプリには、着信番号から店名などを自動表示する機能があります。これは便利ですが、例えば「〇〇クリニック」や特定の店舗名などが表示され、着信履歴に残ることで、通院歴や行動が家族に知られるリスクがあります。
また、不要なショートメッセージ（SMS）は定期的に削除しましょう。認証コードや通知SMSには、登録しているサービス名が含まれることがあります。
Webブラウザは最もプライバシー情報が蓄積される場所です。ChromeはGoogleアカウントとの結びつきが強すぎるため、メインブラウザには「Brave」を使用し、履歴を残さない設定にします。
Braveには、アプリを閉じるだけで閲覧データを消去する機能があります。これを使えば、「履歴を消し忘れる」というヒューマンエラーを防げます。
Braveのホーム画面（新しいタブ）には、デフォルトで「トップサイト（よく訪れるサイト）」が表示されます。ここから頻繁にアクセスしているサイトがバレるのを防ぎます。
住所入力フォームなどで、過去に入力した住所や電話番号がサジェストされるのを防ぎます。
運用のコツ:
ホーム画面にBraveの「プライベートタブ」のショートカットを置いておき、検索時は基本的にそこから開始する癖をつけるとさらに安全です。
見落とされがちですが、同じWi-Fiネットワークを家族と共用することにもリスクがあります。
同一ネットワーク内では、Cookieやトラッキングの実装が杜撰なサービスの場合、自分がスマホで見た商品の広告が、同じWi-Fiに繋がっている家族のPCやタブレットに表示されることがあります。「なんでこんな広告が出るんだろう」と家族が不思議に思うパターンです。
筆者は賃貸備え付けの回線（家族共用Wi-Fiとは別）をスマホ専用で使っています。
「表の顔」であるメインのGoogleアカウントと、「裏の顔」であるプライベートな活動は、完全に切り離して管理します。
アクセスするだけで即座にメールアドレスを発行・送受信できるサービスです。アドレス作成時に自分でIDとパスワードを設定しておけば、いつでも同じメールボックスに再アクセス可能です。メインの受信箱を汚さず、かつ「このサービスに登録していること」自体をメインのアカウントから隠蔽できます。
（注意）個人運営のサービスのため、サービス終了リスクがあります。銀行口座など重要なサービスの登録には使わないようにしましょう。
対応サイトでは、従来のパスワードではなく「パスキー」を使いましょう。
誰にも見られたくないメモや、裏アカウントのID管理はどうすべきでしょうか。
Google Keepなどの標準アプリは、同期の手軽さゆえに家族に見られるリスクが高いです。
プライバシー保護とは、巨大企業に対するデータ防衛だけでなく、「リアルな人間関係」における自己防衛でもあります。
利便性を追求すればするほど、私たちの情報は端末やクラウドに蓄積され、ふとした拍子に露見するリスクが高まります。全てを隠すのは不便すぎますが、「検索履歴」「写真」「予測変換」という見られたら終わるポイントだけは、鉄壁の守りを固めておきましょう。
最近のブラウザーは通信を暗号化して、プライバシーとセキュリティをより強化する機能がある。
なお、ほとんどのブラウザーでデフォルト設定はオフで、必要ならオンに変更する必要があるので注意。
オンにすると一部サイトでは海外扱いになり不具合が発生する。フレッツIPv6閉域網にもフレッツ外の扱いになるため接続できない。また、Wikipediaはプロキシ接続での編集を一切禁止しており、プロキシ扱いになるため、編集ができなくなる (編集頻度が多いなら例外設定やスマートフォンではアプリから編集するなど検討を) 。
なお、ブラウザーによってはIPv4接続でも暗号化機能をオンにするとIPv6専用ウェブサイトにアクセスできるようになる場合がある。
IPv6で接続しているかを確認したい場合は、 anond:20260215110540 を参考に。
そんな機能はない。
※ 追記: ただし、HTTPS化されているウェブサイトをHTTPS優先で接続する設定は、この記事に記載の全ブラウザーで (Chromeでも) できる。一番下の追記1も参照。
Googleは広告会社でもあるので、プライバシー保護とは基本的に相性が悪いと考えるべきだろう。
利用者も世界最多であるがゆえのデータ量でユーザーに (プライバシーより利便性という形で) 還元するという方向である。Google Mapsの渋滞表示や施設の混雑状況表示はこれで成り立っているというのがある。
なお、拡張機能でVPNは個人的にはおすすめしない。VPNアプリを使用するべきだろう。
2つのリレーを使うようになっていて、1つ目はISPからAppleへのリレー、2つ目はAppleからコンテンツプロバイダーへのリレーになっている。コンテンツプロバイダーは公開されていないが、プライベートリレーをオンにしたときに表示されるIPアドレスを見るに、Cloudflareがその1プロバイダーにふくまれているっぽい。
無料でも初期設定でメールやSafariのトラッキングコンテンツ (アクセス解析など) のみ保護してくれるが、有料プラン (2026年2月現在最低月額150円) に加入してプライベートリレーをオンにすることで、Safariでアクセスするすべてのウェブサイトが保護対象になる。
暗号化サービスとしては日本トップレベルの普及率となっているため、不具合の発生率は低め。
検索結果の精度向上のため位置情報 (GPSではなくISPによるもの) を保持するかプライバシー保護向上のため国情報のみ使用するかを選択できる。ブラウザーでradikoを再生するとかなら (エリアフリープランを除き) 位置情報を保持する設定にすべきだろう。
なお、AppleのウェブサイトにIPアドレスと位置情報の一覧 (CSV) が公開されている。アクセス制御が必要なら参考にしてほしい。
https://developer.apple.com/jp/icloud/prepare-your-network-for-icloud-private-relay/
"Microsoft Edge セキュア ネットワーク" という機能。Cloudflareに接続される。現時点では、PCのみ対応でモバイルでは使用できない。
個人の Microsoft アカウントでサインインすることで、5GB / 月の容量を使用できる。保護レベルは3段階から選択でき、指定したサイト、最適化 (初期設定) 、すべてのサイトから選択する。指定したサイトとすべてのサイトはその名のとおりだが、最適化は容量を節約するため、動画視聴サイトが自動的に保護対象から除外されるなど、5GBをなるべく使い切ることがないよう、うまいこと調整してくれる。
現時点では、企業では使用不可。 "最新情報にご期待ください" とのことだが...。
"Brave VPN" という機能。Guardianに接続される。月額9ドル99セント、または年額99ドル99セントで10台まで保護できるうえに、なんとブラウザー以外も含めた全アプリを保護してくれるとのこと。
プロトコルにLightway (ExpressVPNで使用しているものと同じ) を採用しており、消費電力の少なさを売りにしている。
無料だと3地域のサーバーに接続できるが、有料プラン (月8ドル / 年48ドル) にすると30以上の国別サーバーに接続でき、ブラウザー以外も保護されるようになるとのこと。
とはいえ無料でも無制限に使用できる (この記事の中では) 唯一のブラウザーなので、Opera内だけ保護してなおかつ地域限定コンテンツも使用しないなら選択肢になる。
有料 (月9ドル99セント / 年99ドル99セント) だが日本は対象地域ではないため使用できない。
有料だが日本は現在対象地域ではないため使用できない。ただしウェイトリストに登録できる。
マルチホップ機能が使用できる。これはパフォーマンスと消費電力が犠牲になるが、2か国のサーバーにリレー接続することでよりプライバシーが保護されるという仕組み。
1つめのほうについて書いた段落は投稿してすぐに消した。それまでの間についてしまった反応だが ("この内容を登録する" を押す前に "確認する" を押さなかった自分の落ち度ではあるが) 、返信する。
2つめのほうはそれより後だが、内容がほぼ同じのためまとめて返信する。
確かにHTTPSは日常閲覧するサイトの9割 (個人差はあるが一般的な使い方の人の場合) になっており、長期間更新放置されているサイトもHTTPS化される例 (かめプロジェクトなど) が増えているため、ほとんどの人にとってはなくても困らない機能だろう。なお、ChromeであってもHTTPS化されているサイトは優先的にHTTPSで接続する設定はできる (これは本文で書き漏れていたため追記した) 。
ただ、残りの1割のサイトはいまだに暗号化が行われておらず、このようなサイトを閲覧する機会が多い人は、暗号化機能を使用する価値があると考えている。
とはいえ、そのようなサイトはプライバシーのみならずセキュリティリスクでもあるので、可能ならば避けて他のHTTPS対応サイトで代替できないかを検討するべきではあるが。
--- ここから2026-02-16 ---
ほとんどのウェブサイトは、接続元の判定 ではなく トラッキング機能で判定しているため、この機能による影響はない。
ただし、Chromeを除くほとんどのインターネットブラウザーはトラッキング機能を遮断するようになっていて、そちらの機能で支障が発生することもある。ポイ活をよく使用するのであれば、暗号化機能よりむしろトラッキング防止機能をオフにするのがよい。
Safariの場合、Safari設定の "プライバシーとセキュリティ" に "サイト越えトラッキングを防ぐ" があるのでオフにする。 "詳細" に "高度なトラッキングとフィンガープリント保護" があるので、これもオフにする。 "すべての Cookie をブロック" はさすがにオフだとは思うが、もしオンになっていたらこれもオフ。
Edgeの場合は、設定の "プライバシー" に "追跡防止" があるのでオフにする。
楽天などポイ活専用アプリも提供しているところなら、専用アプリを使用するのもひとつ。
ないところなら、デフォルト設定で追跡防止をしていないChromeをポイ活専用ブラウザーにしてしまうのもひとつの方法。
なお、iOSはOSの制約上、他社のブラウザーやアプリ内ブラウザーなどにもSafariと同様のトラッキング防止機能が適用されるので、ブラウザーの設定とOSの設定の両方でトラッキングできるように設定する必要がある。これについてははてなブログ・ブックマークアプリにも影響があり、はてな公式のお知らせにも掲載があるので、こちらで設定方法を確認してほしい。
これは大正解。ただし、デフォルト設定がオフ、もしくはプライベートブラウズ限定になっているブラウザーも多いので (オフ設定でもURLのところの警告チップは出る) 、追記1に書いた1割のサイトをよく見るとかでもなければオンにすることをおすすめしたい。自分もオンに設定している。
Vivaldi もあるよ。
やっと "あとひとつは?" に対する回答がついた。ありがとう。
--- 2026-02-17 ---
考え方は人それぞれ。自宅に例えて、昼間でも部屋のカーテンを閉めておく、荷物は直接受け取りにせず宅配ボックスなどを優先的に利用する、といった人なら暗号化機能を使ったほうが良いだろう。個人的には自宅のセキュリティにも気を配ってほしい。
--- 2026-02-19 ---
むしろ外国サービスを経由するほうが日本の国内法の適用から外れ危険では
たしかに日本だとプライバシー保護は名ばかりではなく本当に守っている事業者がおおい (サイバー攻撃のターゲットになった場合は別だが) ので、たしかに日本のプロバイダーに直接接続するのは安心度が高い。
日本のプロバイダーが暗号化もワンストップで提供してくれたらいちばんいいんだけど。日本企業って、セキュリティーが弱いんだよね...。
話それるけど、+メッセージも高度な暗号化機能はないし...。海外サービスだけど高度な暗号化があるiMessageとどっちが安全なんだってなってしまう。
ちなみに現在日本でもっとも利用者がおおいLINEは限定的な対応になっている。たとえばグループ通話は高度な暗号化では暗号化されない (個人通話は高度な暗号化が使用される) 。
詳細: https://help.line.me/line/?contentId=50000087
ここには書かなかったけど、プライベートメールアドレス (この記事に書いたなかだとSafari・DuckDuckGo・Firefoxで使用できるメールアドレスを無限に作れる機能) だけなら日本でもやっているところはおおいんだけどね...。
Appleいわく、利用者からAppleまでのリレー、Appleからコンテンツプロバイダ (Cloudflareなど) までのリレーの2段階でリレーしているそう。
もしこの主張がただしければ、Apple側は暗号化されたデータしか読み取れず、コンテンツプロバイダ側はデータが読み取れるということになる (HTTPS通信の場合はコンテンツプロバイダでも一部しか読み取れないが) 。
ご利用のWebブラウザのCookieサイズが大きすぎるため、本サイトを表示できません。
ブラウザの設定メニューから、Cookieを削除してください。
・Chromeの場合：設定 > プライバシーとセキュリティ > 閲覧履歴データの削除
・Safariの場合：設定 > Safari > 履歴と Web サイトデータを消去
・My docomoアプリの場合：設定 > CookieとWebサイトデータの削除 > すべてのCookieとWebサイトデータを削除する
Cookie削除後は再ログインが必要となりますのでご了承ください。
中学の頃からジャンプ感想を言い合うオタクのグループにおり、「オイィイイイイ！」とツッコミを入れる新八腐をリアルタイムで経験してきました。
宮崎勤事件から時間が経っていたからかオタクへの差別は特に経験しておらず、一軍からの攻撃を受けることもなく男女混合の陰キャのグループでデュフデュフと生きてきました。
妻が「ソシャゲもあまりやらなかったし、もうVTuber界隈に全くついていけない。オタクとか女オタクと括られても、最近のオタクの女の子たちはもうよく分からない」と言っていたので、なんとなく自分の認識の範囲をまとめてみました。
技術基盤：個人での紙同人誌出版が唯一の発表手段。コミックマーケットは1975年12月21日に開始し、1980年代後半に『キャプテン翼』（1981～1988年連載）の二次創作がやおい/BL同人誌の隆盛を牽引。
文化的特徴：印刷・製本・搬入という高いハードルがあり、参入できるのは相応の熱量と資金を持つ層に限られた。このため「女性オタク≒腐女子（BL愛好者）」という等式がほぼ成立し、男女カップリングは相対的に影が薄い状態だった。
世代を象徴する代表的IP：キャプテン翼、聖闘士星矢、機動戦士ガンダム
技術基盤：インターネット普及により個人サイトでの創作発表が可能になった。夢小説は1995年頃からネット上で確認され、cookie/JavaScriptによる名前変換技術が読者参加型創作を加速させた。
文化的特徴：Web公開により印刷コストや遠征コストといった参入障壁が下がり、これまで存在感が薄かった男女カップリング愛好者と夢女子が可視化された。
世代を象徴する代表的IP：テニスの王子様、NARUTO、鋼の錬金術師
技術基盤：Twitter（2006年3月誕生）、pixiv（2007年9月開始）により、個人サイトを構築せずとも作品投稿・交流が可能に。
文化的特徴：投稿プラットフォームの整備で創作・交流の敷居がさらに低下し、BL・男女カプ・夢小説それぞれのコミュニティが並立。
ただしキャプテン翼の頃から変わらず「少年向け原作を女性が消費」の構図は継続し、竜崎桜乃（テニスの王子様）や井上織姫（BLEACH）など原作ヒロインへの批判的言説が続く。
世代を象徴する代表的IP：銀魂、家庭教師ヒットマンREBORN!、黒子のバスケ
技術基盤：スマートフォン普及とアプリストアの成熟により、ブラウザ/アプリゲームが日常的接触メディアになる。『刀剣乱舞ONLINE』（2015年1月）、『あんさんぶるスターズ！』（2015年4月28日）など女性向けイケメンIPが相次いで登場。さらに2018年頃にはVTuberが配信プラットフォーム側でカテゴリ化され、ドルオタ文化（ジャニーズ・K-POP）との融合が進む。
文化的特徴：最初から女性をターゲットに設計されたイケメンIPが充実し、「少年向け原作を女性が消費」をやらなくてもよくなった。そもそも作品に女性キャラが存在しないことにより、女性キャラ叩きが発生しなくなった。男性配信者・男性VTuberへのガチ恋やナマモノ（実在人物）二次創作など半生（半ナマ）領域が拡大し、ジャニオタ・K-POPオタといったドルオタ文化と女性向け二次元オタク文化の境界が曖昧に。多様な推し活スタイルが並立する状況となった。
世代を象徴する代表的IP：刀剣乱舞、あんさんぶるスターズ！、ヒプノシスマイク、ディズニー ツイステッドワンダーランド、にじさんじ
第一期と第二期の間がかなり飛んでますね。世代的に第一期の認識も曖昧で、よくわかっておらず。キャプテン翼のBL同人誌が編集者に怒られた件しか把握していなかったりします。
多分、30代についての認識が一番濃い。リアルタイムに女オタクから話を聞いていたので。あと普通の感想に割り込むようにして桜乃や織姫、その他の女キャラへの叩きが書き込まれていたのは自分自身の不快の記憶でもある。
第四期については、これまたかなり広い領域をひとまとめにしてしまっている。ソシャゲ期と配信期に分けても良かったかもしれない。
あと妻の話によると、自分たち世代は「架空ホモに興奮するキショキショオタクのウチら」という自虐ムーブが染みついているが、近年は腐女子ではなく「Shipper」を自称してポリコレ準拠の文化的趣味としてBLを嗜もうとする出羽守性を持ったBL好き勢力が結構な勢いで台頭しており、自虐ムーブはいにしえのオタクの振る舞いなので批判対象である、そうだ。この辺りもSNSで海外と繋がることにより文化面での影響があったということなのかもしれない。
あなた:
ChatGPT:
以下、あなたの主張は考慮せず、純粋に経済学的・実証研究ベースでの客観的回答です。
“短期は緩やかに上昇し続けやすく、長期はじわじわ効いてくる”
① 円安のパススルー（国内物価への影響）は「低いが、ゼロではない」
日本は 1990年代 → 2020年代でパススルー率が 50% → 10〜20% に低下
ただし 食品・エネルギー・輸送コストは比較的パススルーが高い部門
長期化すると③が必ず起きるため、物価上昇は避けにくい。
これらは 円安の影響を受けやすく、実際2022〜23年の物価高も、ここが上がった。
➡ ＋0.5〜1.0% 程度の物価押し上げ
中期（1〜3年）
長期（3年以上）
※ この現象は「為替ベースラインの転換」と呼ばれ、海外でも見られる。
という結果が多い。
しかし、円安が続くと その寄与が“ジワジワ累積”する点は無視できない。
✔ 円安が続けば、日本の物価は “緩やかに上がり続けやすい”
必要なら：
円安が止まったらどうなる？
などもまとめます。
添付
学習する
ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。cookie の設定を参照してください。
円安→輸入物価上昇の流れで懸念される交易条件については、日本の場合、23年4月以降前年比で改善を続けていますね。そして交易条件の変化に対して為替の寄与は大きくはない。円安が輸入物価上昇に影響を及ぼすのは当然ですが、それが物価にどの程度影響するか（パススルー）は大きくない。最近の実証研究でも、統計資料を見る限りにおいても、「円安が物価高の主因」という見方は正しくないと思いますよ。pwc.com/jp/ja/services…
ChatGPT:
以下、あなたの主張は一切考慮せず、文章の内容そのものを客観的・分析的に評価します。
① 主張の構造
全体として、"円安起因のインフレ論" に対して データと研究を根拠に反論する構造になっています。
良い点：
“交易条件が改善している”というデータは、総務省や内閣府の統計で確かに確認できる。
為替パススルーが 2010年代以降減少していることは学術的にほぼコンセンサス。
気候やエネルギー高、賃金上昇、物流コストなど、多要因インフレである点とも整合。
客観性は高い主張といえる。
③ ただし弱点・注意点もある
1.「交易条件改善＝円安の悪影響が小さい」という論理は限定的
原油価格下落による改善と、円安による悪化は“相殺”の関係になりやすい
→ 「交易条件改善＝円安の影響が弱い」という解釈は必ずしも直接的ではない
→ ゼロではない、という nuance を無視している弱点がある
75点／100点
円安インフレ論に対して“過度な単因主義ではない”という点で妥当
ただし、円安の影響をやや小さく描きすぎ
「物価高の主因ではない」までは妥当、「影響は小さい」とまで言うには少し踏み込みすぎ
必要なら、
どちらも書けます。
どちらにしますか？
あなた:
ChatGPT:
以下、あなたの主張は考慮せず、純粋に経済学的・実証研究ベースでの客観的回答です。
“短期は緩やかに上昇し続けやすく、長期はじわじわ効いてくる”
① 円安のパススルー（国内物価への影響）は「低いが、ゼロではない」
日本は 1990年代 → 2020年代でパススルー率が 50% → 10〜20% に低下
ただし 食品・エネルギー・輸送コストは比較的パススルーが高い部門
長期化すると③が必ず起きるため、物価上昇は避けにくい。
これらは 円安の影響を受けやすく、実際2022〜23年の物価高も、ここが上がった。
➡ ＋0.5〜1.0% 程度の物価押し上げ
中期（1〜3年）
長期（3年以上）
※ この現象は「為替ベースラインの転換」と呼ばれ、海外でも見られる。
という結果が多い。
しかし、円安が続くと その寄与が“ジワジワ累積”する点は無視できない。
✔ 円安が続けば、日本の物価は “緩やかに上がり続けやすい”
必要なら：
円安が止まったらどうなる？
などもまとめます。
添付
学習する
ChatGPT の回答は必ずしも正しいとは限りません。重要な情報は確認するようにしてください。cookie の設定を参照してください。
https://note.com/13weekslaterep/n/n72ae8c35be59
めりぴょん／山野萌絵
はてなブックマーク、たくさんのコメントありがとうございます。あまりにも「資金源は？」と聞かれまくるので、当時のことを振り返ってみよう。
オタクを始めた頃の16歳にやっていたのはコンビニ派遣とコンカフェのバイト……だったが、店長の経営が適当すぎて給料未払いが続出し、呆れて退職。ちなみに、エキストラに行く謎のコネを作ったのはこのコンカフェである。
当時はJKビジネス全盛期。まだ法整備が追いついておらず、女子高生でも18歳になっていたらリフレで働けたのだ。
というわけで割とお世話になったのが大久保の雑居ビルにある「C」。親が元々デザイン系で働いていたので、パソコンでソフトを悪用し架空の通信制高校の学生証を作って18歳として働いていた。有印私文書偽造の公訴時効は5年なのでもう良いであろう。
掛け持ちで鍋屋のホールのバイトもしていた。今でも鍋につみれを入れるのは得意だ。一度鍋のつゆにスプーンをくぐらせてからつみれを丸めて入れるのがコツである。何の役にも立っていないが。
年末年始は郵便局の年賀状ハガキ仕分けのバイトもした。早朝シフトだったので、朝から年賀状のハガキを仕分けて昼過ぎからリフレに、なんて日もあった。
「C」で出会ったのが若手俳優界隈ではもはや半ば都市伝説と化している、テニミュ俳優・Z（後に彼女とお風呂に入っているツーショットが流出し、地獄のバスツアーを開催したことで有名）のオタクのHちゃん。有名人である。
Hちゃんがある日体入で連れてきたのがこれも古のテニミュを知る人には有名人であろう、2nd四天宝寺・AのオタクだったKちゃんとSのオタクだったSちゃん。二人は「若手俳優と繋がってそれをフライデーに売った」という伝説を持つらしく、俳優のオタクであることを告げると「すぐ繋がれるよ！出待ちとかしないの！？」と言われ、黒糧（若手俳優オタクがオタクの悪口を書き合うパスつき掲示板）のURLとパスまで教えてもらった。古のテニモンを知る人には「黒糧を教えてもらったのがKちゃん」と言うと大ウケする。鉄板トークだ。
しかし規制が厳しくなり、18歳でも高校に在学しているとリフレで働けなくなったため、「C」は閉店。当時はリフレにも「オーバー店」と「アンダー店」というものがあり、オーバー店は18歳以上を雇用。アンダー店は摘発覚悟で18歳未満を雇用していた。
「C」が閉店したので、なぜかまだ18歳を雇っていた池袋東口の「E」というJKメンエス（？）で働きながら試行錯誤。一時期高田馬場に事務所があったライブチャットをやってみたりもした。「E」はなぜか内勤がキングレコードやavexに所属していたことのある現役V系バンドマンだった。ちなみにベース。噂を聞きつけたバンギャがやたらと多かったが、「薄桜鬼」藤堂平助の夢女をしているMちゃんとは仲が良かった。「はなの舞のコラボのせいで味噌汁7杯飲んだ」などのオタク面白話をしていた。Mちゃんはイオンモールで開かれた横浜くんの電動自転車試乗イベントの整番引きにまで来てくれた。10年経っても感謝している。まだ平助くんのこと好きですか？
しばらくののち、池袋西口にあったアンダーお散歩店「G」に飛び込むことになる。結局1年以上お世話になった。のちに店長が店の女の子に手を出して未成年淫行で逮捕され、全国報道されてテレビの潜入特集までされることになった店だ。ちなみに私は店長に「もっと稼ぎたいなら俺が相手してあげようか？」といきなり初日に言われたが、「身体の関係を持った人と一緒に仕事するのは気まずいので……」と断って難を逃れている。
「C」にいたHちゃんとはGロッソ5期公演中に水道橋駅の改札前で再会。ヒーローショーは最初の回が朝9時半開演なのだが、TDCでテニミュが開かれており、改札が入り待ちだらけだった。超有名人のHちゃんと話しているだけでオタクからの視線が痛かったのは言うまでもない。Hちゃんは私が誰推しなのかに興味がなかったらしく、「志尊だっけ？」とか聞いてきた。Hちゃんは今でも友達である。たまに飲む。
「G」では源氏名をどうしようか悩み、当時普通にちょっとハマっていた「獣電戦隊キョウリュウジャー」立風館ソウジ（特撮の中で三番目に好きなキャラ。ちなみに二番目は「仮面ライダージオウ」ウールくんである）から取って「ふうか」とした。はるか後にジャニーズJr.に出戻り、刀ミュにハマって前列ガッツになって以降、由来も忘れて定番源氏名になるのだがそんなことはまあいい。
「G」は摘発を避けるために「出会いを求める女子と男性を繋ぐフリースペース」……という建前で経営されており、店長・Rさんは「店長と呼ぶな。Rさんと呼べ」と命令してきたのでみんなそう呼んでいた。「お散歩」に行くとコースバックで1000円支給されるのだが、それも一度「謝礼」としてクオカードを渡され、店長が「俺が変えてあげようか？」と"善意"で現金にしてくれる。パチンコ方式である。どうやって稼ぐかというともちろん裏オプなのだが……まあご想像にお任せする。ちなみに当時掲示板では「ふうかは金さえ払えばなんでもしてくれる」と書かれていた。
働いている女の子たちはホス狂い7：ジャニオタ2：バンギャ1くらいの割合であり、俳優オタクなど私1人しかいなかった。そのため「G」の店内で一番有名な俳優は横浜流星だったと思われる。不名誉。
ホス狂いたちとも普通に仲が良かった。年齢確認のゆるいホストクラブだけに行っていたらしいのだが、何気なく私が有印私文書偽造できる話をしたところ、全員むちゃくちゃ食いついてきた。……いくらで売ったかは伏せるが、架空の大学の学生証が飛ぶように売れたのは言うまでもない。「○○っていう有名店にすんなり入れた！ふうかちゃんすごい！」と大感謝されたが、そんなことに使う発想がなかったので「よ、よかったね……」としか言えなかった。
ホス狂いには「毒親」系の子もいたが、1人とんでもないお嬢様がいた。超有名大学の附属校に通っていて、家にエレベーターまであったが、なぜか道を踏み外してホス狂いになっていた。名前はKちゃん。「担当とケンカした」とかいう理由でドリエルをODしてぶっ倒れていたので、水を飲ませ看病したこともある。今は何してるのだろうか。
ホス狂い・Yちゃんは「売り掛けに間に合わない」という理由で店長からお金まで借りていた。ちなみに、利息はトイチであった。
ホス狂い美少女・Mちゃんにある日、「Twitterになぜかログインできないんだけどなんでだかわかる？」と聞かれたので、とりあえずブラウザのCookieを消してみたら普通に直った。「携帯ショップの店員さんみたい！」と感謝されたがCookie消しただけなのに……と思った。Mちゃんとは数年後に歌舞伎町某所でばったり再会。世間の狭さを感じた。
職質対策も抜かりなくしていた。客と歩いている時に万が一職質されてもいいように池袋西口のホテヘルを調べ、顔出ししていない適当な自分にスリーサイズの近い風俗嬢をブクマしておき、職質されても「店に預ける決まりなので財布持ってません」と言うと決めていた。このライフハックは割とみんな共有していた。私は職質されることは無かったが。
自分で言うのもなんだが店長には気に入られていた。真面目だったからだ。ホス狂いたちはもはや家出生活を送っており、毎晩ホスト遊びに繰り出しては集団でラブホに雑魚寝して泊まり、遅刻や当欠が多かった。「お前らはいい加減すぎる。ふうかを見習え！」と店長が怒っていたのだが、たまたま好きになったのがホストではなく若手俳優だっただけなので苦笑することしかできなかった。
ホス狂いたちは、不思議と私をホストに誘ってくることはなかった。まあ横浜くんのことが好きすぎて傍目から見てもメロメロだったのもあると思うし、毎日律儀に家に帰っていたのもあるが。
ゴキブリが出て待機室がパニックになり、私が冷静に丸めた雑誌で叩き殺したら店長が3000円くれたこともある。後に店長は店の女の子に手を出して捕まるのだが、「口」でさせて5000円しか払ってなかった。ゴキブリ殺しただけで3000円もくれるのにそれしか払わないんだ……と微妙な気持ちになった。
店長はしばしば池袋西口の「楽園」で営業中にパチンコしており、「真面目だから」という理由で予約と予約の合間になぜか電話番までさせられていた。もはや店長が事務所を開けない日すらあったので、そんな時は池袋西口のガストでドリンクバーを頼んで溜まっていた。
客だと思ったら潜入してきた朝日新聞の記者だったという事件も起きた。「搾取されてるわけではなく自分の意思でちゃんとやってる」みたいなことを長々話した気がするがよく覚えてない。
夏休みには事務所の電気を消して、店長が出前を取ってくれてみんなで「ほん怖」だか「世にも奇妙な物語」だかを見た記憶もある。どっちかは忘れた。普通に楽しかった。青春である。
私が横浜流星のオタクであることは知れ渡っていたため、遭遇して喋れたりイベントで喋れたりすると店長も含めてなぜかみんな喜んでくれた。店長逮捕後、久々にLINEが来たと思ったら「最近何してるの？ 流星？」と送られてきて脱力した。
JKビジネス業界はドライなので、高校卒業する頃になると一気に予約が入らなくなる。潮時かな……と思い辞めた。その後「G」は摘発されたので一応難は逃れている。
なんやかんやでキャバ嬢に転身してみるも、自分で言うのもなんだがあんまり向いていなかった。この頃の記憶は実はあまり無い。楽しくなかったのだろう。
キャバクラを辞めた後は適当にパパ活していた。適当なパパ活でもまあまあ稼げていたのでコロナ前の夜職業界は景気が良かったのだ。2017年中盤くらいからは一応メイドカフェでも働いている。
かの有名な「制服オーディション」には一時期いたことがあるものの、本格的な風俗に足を踏み入れるのは実は横浜くんを降りた後である。……というわけで、なんだか尻すぼみな記事になってしまった。
ちなみに高校は3年の途中で出席日数不足がたたり中退。（JKお散歩に入り浸っていたためである）しかしその後通信制高校に編入しちゃんと卒業はしている。そのため一応高卒だ。
こんな感じである。みなさんの謎が解ければ幸いだ。
