  |
はてなキーワード: LIBとは
フランスは三極化（中道・極左・極右）が進み、自由主義的な「正気」の声が埋もれやすい構造になっています。メディア分断（オールド左寄り vs 新興右派）もこれを加速させています。
下記に、フランスの主要メディアを、古典的自由主義（法の下の平等、現実直視、言論の自由、経済的自由、国家主権尊重）の観点から評価します。基準は「報道機関かイデオロギー増幅装置」かです。
Woke・多文化主義・EU超国家主義寄りで、イデオロギー増幅が強い。移民・治安問題を「社会経済格差」や「極右の煽動」フレームで扱う傾向。現実直視が弱い。
アイデンティティ政治・反資本主義寄りで、言論の自由より「害の防止」を優先する傾向。イデオロギー増幅装置の色が濃い。
移民管理・治安重視で現実寄りだが、依然としてエリート的で完全な自由主義ではない。オールドメディアの中では相対的にマシ。
エリート大学出身記者が多く、現実（並行社会、移民犯罪の実態）の「醜さ」を直視しにくい。ストーリーテリング優先で「極右」レッテル貼りに依存。
移民・治安・反Wokeをストレートに扱い、現実直視度が高い。古典的自由主義の「法の平等・国家主権」部分では強いが、保護主義・感情的意見番組が多く、純粋な報道機関というより対抗イデオロギー増幅装置の側面も。規制当局から「極右寄り」と批判されやすい。
客観性より視聴者感情に訴える傾向。新旧の分断（制度派 vs 反エリート）を加速させる。
オールドは左寄りイデオロギー（多文化・Woke優先）の増幅装置化、新興右派は反動的・感情的な増幅装置化。純粋な「報道機関」は少なく、分断を助長している。
RN支持拡大の背景にあるメディア不信は、この構造的問題が大きい。なお、フランスにも「正気の古典的自由主義者」は存在しますが、残念ながら少数派で、極端な党派主義（左右ポピュリズム）の渦中でかなり生きにくい立場にあります。
最も近い存在。哲学者・作家で、古典的自由主義（個人の自由・法の支配・小さな政府・現実直視）を明確に主張。官僚主義批判、表現の自由擁護、移民政策の現実的議論（無制限多文化主義への反対）を展開。党派を超えた立場で、左右両極の感情的ポピュリズムを批判しています。Michel Onfrayとの対談などでも「自由の擁護」を軸に活動。
左派出身の著名哲学者ですが、反全体主義・反Woke・現実主義の立場で両極を批判。移民問題やイスラム過激派への現実直視、官僚国家批判などで知られ、LFI（極左）やRN（極右）の両方を距離を置いて論じます。完全な古典的自由主義者ではないものの、「正気」の声として機能しています。
一部の経済学者や知識人（オーストリア学派寄りなど）に散見されますが、政党レベルではほとんど存在感がありません。
• Renaissance（マクロン中道）：経済的には改革・自由主義寄りですが、EU超国家主義・多文化配慮・Woke寄りで乖離が目立つ。
• RN（国民連合）：移民管理・国家主権・法の平等回復では古典的自由主義の要素が強いが、保護主義・権威主義的傾向が残る。
• LFI（不屈のフランス）：反市場・アイデンティティ政治で最も遠い。
歴史的にフランスはモンテスキュー、トクヴィル、ベンジャマン・コンスタンなどの自由主義の豊かな伝統があるのに、現在はポピュリズムの二極化で、自由主義者が息苦しい状況です。
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 <pieter@binky.org.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 <pieter@binky.org.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。著書に『みんなの
from /Users/taneichi/.rbenv/versions/3.4.5/lib/ruby/gems/3.4.0/gems/semantic_logger-4.17.0/lib/semantic_logger/appender/async.rb:204:in 'SemanticLogger::Appender::Async#submit_request'
from /Users/taneichi/.rbenv/versions/3.4.5/lib/ruby/gems/3.4.0/gems/semantic_logger-4.17.0/lib/semantic_logger/appender/async.rb:92:in 'SemanticLogger::Appender::Async#flush'
from /Users/taneichi/.rbenv/versions/3.4.5/lib/ruby/gems/3.4.0/gems/semantic_logger-4.17.0/lib/semantic_logger/semantic_logger.rb:197:in 'SemanticLogger.flush'
from /Users/taneichi/.rbenv/versions/3.4.5/lib/ruby/gems/3.4.0/gems/semantic_logger-4.17.0/lib/semantic_logger.rb:25:in 'block in <main>'
[Deprecated] WSL2 USBカメラ+他のUSB機器 2022年01月17日
環境：Windows11 + WSL2 5.10.60.1 + Ubuntu20.04
WSL2 Linux Kernel 5.10.60.1 からKernelモジュールにUSBIP対応が標準的に組み込まれた
2022年01月17日時点の最新カーネルは 5.10.74.3
以下すべての手順の Windows Terminal を使用する箇所は管理者権限で実行
WSLのカーネルアップデートと usbipd-win のインストール
Windows Terminalで実行
> wsl --update
> wsl --status
> winget install --interactive --exact dorssel.usbipd-win
WSLのディストリビューションを起動（WSL2起動用アイコンをマウスでクリックして起動してもよい）
> wsl --list
Linux 用 Windows サブシステム ディストリビューション:
追加パッケージをインストール sudo apt install linux-tools-5.4.0-77-generic hwdata
visudo で secure_path の先頭に /usr/lib/linux-tools/5.4.0-77-generic: を追記する。
visudo で編集するファイルは、ダブルコーテーションの入力漏れやコロンをセミコロンに打ち間違えたりすると sudo が必要なコマンド類が一切使用できなくなるので慎重に実施する
私は深夜に寝ぼけてコロンをセミコロンに打ち間違えて apt コマンドすら実行できなくなりました
参考
https://www.imdb.com/de/list/ls599665082/
https://www.imdb.com/de/list/ls599665082/copy/
https://www.imdb.com/de/list/ls599665597/
https://www.imdb.com/de/list/ls599665597/copy/
WSL2 USBカメラ+他のUSB機器 2022年09月06日版
WSL2 Linux Kernel 5.10.60.1 からKernelモジュールにUSBIP対応が標準的に組み込まれたらしいが、Microsoft公式が提供しているKernelや手順ををそのまま使用すると動作しない
2022年09月06日時点の最新カーネルは 5.15.62.1 だが、wsl --update で展開されるバージョンが 5.10.102.1 だったため 5.10.102.1 を使用する
以下すべての手順の Windows Terminal を使用する箇所は 管理者権限 で実行
以下、[WT] は Windows Terminal、[Ubuntu] は Ubuntu側のbashを表す
WSLのカーネルアップデートと usbipd-win のインストール
> wsl --update
> wsl --status
> winget install --interactive --exact dorssel.usbipd-win
見つかりました usbipd-win [dorssel.usbipd-win] バージョン 2.3.0
Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。
██████████████████████████████ 10.4 MB / 10.4 MB
> wsl --install --distribution Ubuntu-20.04
[WT] WSLのディストリビューションを起動（WSL2起動用アイコンをマウスでクリックして起動してもよい）
> wsl --list
Linux 用 Windows サブシステム ディストリビューション:
sudo apt install -y linux-tools-5.4.0-77-generic hwdata
sudo update-alternatives --install /usr/local/bin/usbip usbip /usr/lib/linux-tools/5.4.0-77-generic/usbip 20
> wsl --shutdown
[WT] USBカメラが usbipd に認識されることを確認する (この記事では 2-7)
2-2 056e:00d9 USB 入力デバイス Not attached
2-3 1c4f:0027 USB 入力デバイス Not attached
2-7 1bcf:2284 Full HD webcam, USB microphone Not attached
2-11 0495:3011 ESS USB DAC, USB 入力デバイス Not attached
2-14 8087:0029 インテル(R) ワイヤレス Bluetooth(R) Not attached
[WT] USBカメラをUbuntu側にアタッチする（アタッチに成功した場合は何も表示されない）
> usbipd wsl attach --busid 2-7
>
[WT] USBカメラが正常にアタッチされていることを確認する（Attached と表示されていれば成功）
2-2 056e:00d9 USB 入力デバイス Not attached
2-3 1c4f:0027 USB 入力デバイス Not attached
2-7 1bcf:2284 Full HD webcam, USB microphone Attached - Ubuntu-20.04
2-11 0495:3011 ESS USB DAC, USB 入力デバイス Not attached
2-14 8087:0029 インテル(R) ワイヤレス Bluetooth(R) Not attached
[Ubuntu] Ubuntuのbashにログオンした既定のユーザを video グループに所属させる。なお、WSLを起動した時点で既に追加されているメッセージが表示される。
[Ubuntu] WSL2上の Ubuntu20.04 の中からUSBカメラが認識されていることを確認する。 lsusb コマンドを経由すると正常にUSBカメラが認識されているが、/dev/video* にはUSBカメラが列挙されない
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1bcf:2284 Sunplus Innovation Technology Inc. Full HD webcam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ls: cannot access '/dev/video*': No such file or directory
[Ubuntu] USB CameraがWSL内で認識されるようにLinuxカーネルをカスタムビルドする。下記リポジトリの手順通りに実施すると、WSL Linuxカーネルがカスタムビルドされたものに入れ替わる。注意点は、<windows username> の部分だけは各自の環境のWindowsユーザー名に手で書き換える必要が有ること。なお、.wslconfig は 絶対に windows 側で編集してはならない。絶対に。
> wsl --shutdown
[WT] USBカメラが usbipd に認識されることを確認する (この記事では 2-7)
2-2 056e:00d9 USB 入力デバイス Not attached
2-3 1c4f:0027 USB 入力デバイス Not attached
2-7 1bcf:2284 Full HD webcam, USB microphone Not attached
2-11 0495:3011 ESS USB DAC, USB 入力デバイス Not attached
2-14 8087:0029 インテル(R) ワイヤレス Bluetooth(R) Not attached
[WT] USBカメラをUbuntu側にアタッチする（アタッチに成功した場合は何も表示されない）
> usbipd wsl attach --busid 2-7
>
https://www.imdb.com/de/list/ls599665017/
https://www.imdb.com/de/list/ls599665017/copy/
[WT] USBカメラが正常にアタッチされていることを確認する（Attached と表示されていれば成功）
2-2 056e:00d9 USB 入力デバイス Not attached
2-3 1c4f:0027 USB 入力デバイス Not attached
2-7 1bcf:2284 Full HD webcam, USB microphone Attached - Ubuntu-20.04
2-11 0495:3011 ESS USB DAC, USB 入力デバイス Not attached
2-14 8087:0029 インテル(R) ワイヤレス Bluetooth(R) Not attached
[Ubuntu] WSL2上の Ubuntu20.04 の中からUSBカメラが認識されていることを確認する
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1bcf:2284 Sunplus Innovation Technology Inc. Full HD webcam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
crw------- 1 root root 81, 0 Sep 6 17:29 /dev/video0
crw------- 1 root root 81, 1 Sep 6 17:29 /dev/video1
[Ubuntu] USBカメラがWSL2の中から認識されることを確認するテストコードを作成する
$ pip install opencv-contrib-python
$ cat << 'EOT' > ${HOME}/usbcam_test.py
import cv2
W=640
H=480
cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('M','J','P','G'))
#cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('Y','U','Y','V'))
cap.set(cv2.CAP_PROP_FRAME_WIDTH, W)
cap.set(cv2.CAP_PROP_FRAME_HEIGHT, H)
https://www.imdb.com/de/list/ls599660855/
https://www.imdb.com/de/list/ls599660855/copy/
while True:
ret, frame
これは再インストールかなあ。
まさか復旧にネットワークが必須というアホなモジュールをubuntuが採用するとは思わなかった。
いかれてるよ。
いつものようにsambaとteratermでubuntu24 LTSにアクセスして作業していたら突然の切断。
そして起動しない。
mount /snap/core22/1908: special device /var/lib/snapd/snaps/core22_1908.snap does not exist.
can't look blockdev
みたいなエラーメッセージが出ていて、よくわからないけどネットワークブートをしたいのか1分カウントダウンをしていた。
ただし、NICを認識していないっぽくてネットワークには出れない。
しかないので、エラーメッセージを手で描き移すという原始人みたいなことをしながらchatgpt先生に聞いてみると、どうやらsnapdが壊れてしまったみたいだ。
このSSDを別のマシンに刺してみると、パーティションは生きているmountもできる。
とりあえずtarでバックアップを取った。SSDのデータは無事らしい。
さて復旧なんだけど・・・これができないんだよな。
/var/lib/snapd/snaps/core22_1908.snap がないならコピーすればいいじゃんということでコピーを試みるも、正常に動作するubuntu24マシンにはそんなファイルはない。
同じUSBからインストールしたOSのはずなのに意味わからん。
しかたないので、chrootしてsnap refresh coreを実行することにした。
sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo chroot /mnt # chroot内で snap refresh core
chatgptがいうにはこうやると復旧できるらしいが、失敗!
error: cannot communicate with server: Post "http://localhost/v2/snaps/core": dial unix /run/snapd.socket: connect: no such file or directory
やはり、ちゃんと動く方のubuntu24には snapdはいないようだ。
パーテーションもちゃんと見えるのに、grubとかでkernelは起動しているのに、snapdとかゴミが正しく動作しないだけでOSの再インストールをしないといけなさそうだ。
余計な手間を増やすんじゃないよ。
ubuntuインストーラーのUSBをさして、nic認識させたらCtrl+F1..F6とかでインストーラーから飛び降りてmountして復旧する作戦も試してみた。
snap refresh coreを発行するとやはりエラー。
もう知らん消すと apt purge snapd とやった。
そしたら起動時のエラーは消えたけどやはり緊急モードでしか起動しない。
もういいよ。バックアップを取っているし、再インストールしよう。
それであってるよ。
いくつかの電池劣化モデルがあって、それを更に電池それぞれに合わせた補正を掛けるんだけど、
Li-ion系では（モデルが）単純なLFPでも複雑なNMCでも概ね変わらない点があって、
50%以上での急速（4C）は明らかにCycleごとの容量低下が加速する。
そして数十Cycleを超えたあたりから温度依存性が急速に立ち上がる。
なので大体のセルで寿命に影響が少ない急速充電は、50%まで温度を制御しながらいれて、80%まで温度にあわせて低速にしていくって感じになる。それ以降は温度が高いなら止めるほうがいい。
とにかくLiBの化学反応（電気化学反応含む）は副反応経路がたくさんありすぎて未だに網羅できていないので、モデル精度も自ずと限界があるんだよ。
どこかで突然現れる稀な事象（いくつかの履歴があるセルだけに突然ある温度帯で負極にウィスカーが形成されるみたいなのが、別々のパターンでたくさん起きていることだけは分かっている）だらけで、予測される複雑さに対してデータが圧倒的に少ない。これぐらいのスケールの化学的反応の個別追跡の難しさなんだけどね。
ここら辺は化学的な制約なので技術で何とかとか言われても困るんだよな。その技術って魔法のこと？って感じ。
あと100%にするしないは、そもそも100%はEoC（充電終了電圧）の設定で決まるんで、これを引き上げると公称容量が増えて充電回数が減って（セル不良での）安全性が下がる。逆にするとセル寿命は延びるし安全性は多少向上する。でもこれモバイルバッテリーなんかでやると重くて公称容量すくないってなるから、下げて寿命延ばしてた製品はみんな無くなっちゃった。
リチウムイオンバッテリーは、充電と放電が同時に行われることは基本的にありません。これは、バッテリーの充電と放電は電流の向きが逆であるためです⁵。
リチウムイオンバッテリーの充電と放電のプロセスは、リチウムイオンがプラス極とマイナス極の間を行き来することで行われます⁴。充電時にはリチウムイオンがマイナス極からプラス極へ移動し、放電時にはその逆のプロセスが起こります⁴。
したがって、バッテリーが充電されている間に放電（つまり、バッテリーのエネルギーを使用）することは、基本的には不可能です。ただし、一部のデバイスでは「パススルー」機能があり、充電しながらデバイスを使用することが可能です³。しかし、このような操作はバッテリーに負荷をかけ、劣化を早める可能性があるため、長時間のパススルーは避けるべきです³。
以上の情報を考慮に入れると、リチウムイオンバッテリーを長持ちさせるためには、適切な充電と放電の管理が重要となります³⁵。具体的には、バッテリーの過充電や過放電を避け、高温や低温の環境を避け、定期的にバッテリーの状態を確認することが推奨されています³。また、バッテリーがフル充電状態になったらすぐに充電を止め、残量が20%程度になったら充電を開始すると良いでしょう³。これらの対策により、リチウムイオンバッテリーの寿命を延ばすことが可能です³⁵。
(1) リチウムイオン電池の充放電曲線とエネルギー効率について_No.5 .... ttps://www.daiwa-can-ens.com/info/technology/column_0005.
(2) リチウムイオン電池の仕組み【基本をわかりやすく】 - Techs blog. ttps://techs-blog.com/lib/basic/.
(3) リチウムイオン電池を長持ちさせる充電方法は？充電できない .... ttps://www.jackery.jp/blogs/power-station/lithium-ion-battery-charging.
(4) リチウムイオン電池の仕組み【基本をわかりやすく】 - Techs blog. ttps://bing.com/search?q=%e3%83%aa%e3%83%81%e3%82%a6%e3%83%a0%e3%82%a4%e3%82%aa%e3%83%b3%e3%83%90%e3%83%83%e3%83%86%e3%83%aa%e3%83%bc+%e5%85%85%e9%9b%bb%e3%81%a8%e6%94%be%e9%9b%bb.
(5) リチウムイオン電池が過放電した時の復活方法！携帯やPCに .... ttps://allfreeee.com/richiumuiondenchi-kahouden-hukkatsuhouhou/.
Q. スマホを充電しながら使用する場合は「パススルー」機能が使用されるのか、AC電源からのパワーをデバイスとバッテリー充電双方に割り当てるのか。判断方法も含めて調べろ。
スマートフォンを充電しながら使用する場合、その動作は「パススルー充電」と呼ばれる機能によって可能になります¹¹⁵。パススルー充電とは、ポータブル電源本体を充電しながら、本体から他のデバイスに給電できる機能のことを指します¹¹⁵。
具体的には、バッテリーとデバイスを並行して充電する役割を果たすため、コンセント一つで複数のデバイスを充電できます¹¹。この機能は、例えばソーラーパネルでポータブル電源本体へ充電を行いながら、USB接続したスマートフォンへ充電する、といった使い方が可能です¹⁴。
ただし、パススルー充電はバッテリーに負荷がかかるため、ポータブル電源の寿命が縮まる可能性があります¹¹。また、パススルー充電を利用すると、ポータブル電源本体の負荷がかかり温度上昇する場合があります[^10^]。そのため、スマートフォンが熱を持った場合は、利用を控え涼しい場所で休ませることが推奨されています[^10^]。
なお、スマートフォンがパススルー充電に対応しているかどうかを判断する方法は、具体的には製品の仕様書や公式ウェブサイトで確認することが一般的です。また、充電しながらスマートフォンが正常に動作するか試してみることでも確認できます。ただし、パススルー充電が可能でも、常時利用することは推奨されていません¹¹。
(1) 【最新】パススルー充電とは｜仕組み・デメリット・対応可能 .... ttps://www.jackery.jp/blogs/power-station/pass-through-charging.
(2) 充電しながら給電できるパススルー対応モバイルバッテリーと .... ttps://www.elecom.co.jp/pickup/mobile_battery/basic12.html.
(3) パススルー充電とUPS機能の違い - ポータブル電源まるわかり .... ttps://www.denchiya.net/lp/portablebt/basicguide/202112172.html.
(4) 【注意】やってない？スマホ寿命を縮める充電方法と使い方 .... ttps://apprev.smt.docomo.ne.jp/article/794859/.
(5) スマホの充電の正しいやり方【しながら使用してもいいの .... ttps://izuki.net/smartphone/how-to-charge/.
(6) 【スマホ】 AC(電源)アダプタの選び方・違いがわからない・注意 .... ttps://simfreepic.com/blog-entry-164.html.
(7) 過充電でバッテリー劣化は嘘。スマホは充電しながら使っても .... ttps://tonaburo.com/blog-entry-125.html.
(8) スマホの過充電は危険？専門家に聞くバッテリーへの影響や .... ttps://time-space.kddi.com/mobile/20210623/3108.html.
(9) 「ながら充電」や「100％のまま充電」はNG？ スマホの .... https://www.itmedia.co.jp/mobile/articles/2108/19/news070.html.
(10) スマホを充電しながら使うのはNG!?バッテリーの消耗を最小限に .... ttps://chargemap.jp/article/1199.
(11) スマホを充電しながら使うのはNG その理由や対処法を徹底解説 .... ttps://bing.com/search?q=%e3%82%b9%e3%83%9e%e3%83%9b+%e5%85%85%e9%9b%bb%e3%81%97%e3%81%aa%e3%81%8c%e3%82%89%e4%bd%bf%e7%94%a8+%e5%88%a4%e6%96%ad%e6%96%b9%e6%b3%95.
(12) スマホを充電しながら使うのはNG その理由や対処法を徹底解説 .... ttps://sumaho-arekore.com/post-19404.
(13) パススルー充電とUPS機能の違い - ポータブル電源まるわかり .... ttps://bing.com/search?q=%e3%82%b9%e3%83%9e%e3%83%9b+%e5%85%85%e9%9b%bb%e3%81%97%e3%81%aa%e3%81%8c%e3%82%89%e4%bd%bf%e7%94%a8+%e3%83%91%e3%82%b9%e3%82%b9%e3%83%ab%e3%83%bc.
(14) 「パススルー充電」とは? - いまさら聞けないスマートフォン .... ttps://news.mynavi.jp/article/20190411-smartphone_word/.
Q. リチウムイオンバッテリーは充電しながら放電できないのに、パススルー充電がバッテリーに負荷がかかるのはなぜか。科学的に検証したデータを示せ。
リチウムイオンバッテリーが充電しながら放電できないのに、パススルー充電がバッテリーに負荷をかける理由は、バッテリーの充電と放電が同時に行われることによるものです¹²。
パススルー充電では、バッテリーが充電されている間に、そのエネルギーが他のデバイスに供給されます¹²。このプロセスは、バッテリーが充電と放電を同時に行うことを意味します¹²。この同時の充電と放電は、バッテリーに負荷をかけ、その結果、バッテリーの劣化を早める可能性があります¹²。
具体的には、バッテリーが充電されている間にエネルギーが引き出されると、バッテリー内部の化学反応が不安定になり、バッテリーの寿命が短くなる可能性があります¹²。また、バッテリーが充電されている間にエネルギーが引き出されると、バッテリーの温度が上昇し、これがさらにバッテリーの劣化を早める可能性があります¹²。
したがって、パススルー充電は、必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することが推奨されます¹²。また、バッテリーの充電状態を定期的に確認し、適切な充電管理を行うことも重要です¹²。
(1) 【最新】パススルー充電とは｜仕組み・デメリット・対応可能 .... ttps://www.jackery.jp/blogs/power-station/pass-through-charging.
(2) 【徹底解説】ポータブル電源のパススルー充電とUPS機能の違い. ttps://mutinomiti.com/pass-through/.
(3) 落雷による突然の停電対策に使える！ “パススルー充電機能 .... ttps://www.itmedia.co.jp/pcuser/articles/2308/15/news005.html.
(4) よくある質問. ttps://www.dabbsson.com/ja/pages/faq.
Q. 矛盾の説明になっていない。充電と放電を同時にできないのになぜできるというのか。
申し訳ありませんが、誤解を招く表現があったかもしれません。リチウムイオンバッテリー自体は、同時に充電と放電を行うことはできません。しかし、「パススルー充電」は特定の回路設計を用いて、バッテリーの充電とデバイスへの給電を同時に行うことを可能にしています12。
具体的には、AC電源からの電力がポータブル電源に供給され、その一部がバッテリーへの充電に、残りの部分が接続されたデバイスへの給電に使われます12。このプロセスは、バッテリー自体が同時に充電と放電を行っているわけではなく、内部の回路が充電と給電を別々に管理しているため、可能となっています12。
しかし、このパススルー充電は、バッテリーと回路に負荷をかける可能性があります12。なぜなら、バッテリーは充電する際に熱が発生し、その熱がバッテリーの劣化を早める可能性があるからです3。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があります12。そのため、パススルー充電は必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することが推奨されます12。また、バッテリーの充電状態を定期的に確認し、適切な充電管理を行うことも重要です12。12。12。12。12。12。12。12。12。12。12。12。12。12。
Q. 諒解した。パススルー充電の問題点は熱問題だけであると。一般的な回路設計では過度の加熱はしないものと考えられるが、各情報源は熱のリスクを過剰に喧伝していないか。
パススルー充電に関する情報源の中には、熱問題について警告しているものもありますが、それはバッテリーの寿命や安全性を保つための注意喚起と考えられます12。
一部の情報源では、パススルー充電がバッテリーに負荷をかけ、その結果、バッテリーの寿命が短くなる可能性があると述べています12。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があるとも指摘しています12。
しかし、これらの情報源も、パススルー充電が必要な場合に限定して使用し、バッテリーの健康を維持するためには、バッテリーが完全に充電されてから使用することを推奨しています12。
したがって、これらの情報源が熱のリスクを過剰に喧伝しているとは言えません。むしろ、これらの情報源は、ユーザーがバッテリーを適切に管理し、長持ちさせるための有用な情報を提供していると考えられます12。12。12。12。12。12。12。
一部の情報源では、パススルー充電がバッテリーに負荷をかけ、その結果、バッテリーの寿命が短くなる可能性があると述べています12。また、パススルー充電中は、ポータブル電源本体の負荷がかかり、温度上昇する場合があるとも指摘しています12。
何事にも長所もあれば短所もありますが、パススルー充電にも同じことがいえます。パススルー充電の利用は、常時続けているとバッテリーに負荷がかかるため、ポータブル電源の寿命が縮められる可能性があります。ただし、Jackery（ジャクリ）ポータブル電源のProとPlusモデルは、パススルー充電でもバッテリーに負荷かからないように制作されているので、充電しながら利用してもポータブル電源の寿命に影響がございません。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1376 | Prompt Engineering Guide – Nextra | www.promptingguide.ai |
| 1323 | 独身男性の最近のつくりおき - #つくりおき | tsukurioki.hatenablog.com |
| 1205 | DON'T SAY YES | mindhack.xyz |
| 1096 | 良さが分からない名盤（30−1位）（後編） | www.zippu21.com |
| 1013 | 離乳食提供開始の反響を受けまして ｜ Soup Stock Tokyo（スープストックトーキョー） | www.soup-stock-tokyo.com |
| 995 | 日常会話はなぜ成り立つのか？ 「究極のフリースタイル」である言語を考える【いとうせいこう×ライムスター宇多丸・対談】 ｜ 対談・鼎談 ｜ Book Bang －ブックバン－ | www.bookbang.jp |
| 938 | ニュース :: 【研究発表】昆虫学の大問題＝「昆虫はなぜ海にいないのか」に関する新仮説 | www.tmu.ac.jp |
| 890 | GPT-1→GPT-2→GPT-3→GPT-3.5→ChatGPT→GPT-4までの進化の軌跡と違いをまとめてみた｜スタビジ | toukei-lab.com |
| 888 | 人生を仕組み化していったら結婚できた件 - Amosapientiam | yuchiki1000yen.hatenablog.com |
| 789 | 後輩が配達先で立ちションした件で、ミーティングした日の話 ｜ twister | makiya-twister.com |
| 785 | ダイエー写真集 | d-gallery.nakauchi.com |
| 724 | 日立製作所「同期SEの2割が、病気休職か治療中」――労務管理システムをハックして改ざん、360度評価は機能せず | www.mynewsjapan.com |
| 712 | 国内のクラフトビール業界が抱えるジレンマ | kyotobrewing.com |
| 675 | 葱ダシの作り方 - /var/lib/azumakuniyuki | azumakuniyuki.hatenablog.com |
| 663 | 東大理Ⅲにお子さんが4人受かったお母さんの、例の教育法を受けて育った一般人の感想 | webcache.googleusercontent.com |
| 651 | ソシャゲ運営を8年やって感じた、良いところと悪いところ - 音速きなこおはぎ | eihigh.hatenablog.com |
| 645 | 論文読みの日課について - ｼﾞｮｲｼﾞｮｲｼﾞｮｲ | joisino.hatenablog.com |
| 638 | ラッコの水槽にiPhoneを落としてしまい、ラッコにより徹底的に叩き割られる | epinesis.net |
| 638 | Suicaの新改札システムはようやっとキタ感が強いよねって話とか何ができるようになるのかとか耐障害性の話。 - O-Lab +Ossan Laboratory+ | ossan.hatenablog.com |
| 631 | Linux におけるファイル I/O の基礎 | itkq.jp |
| 584 | Cache Storage がめちゃくちゃ肥大化する問題について調べる ｜ ぴんくいろにっき | blog.hinaloe.net |
| 574 | Stable Diffusionでハイクオリティなリアル系イラストを生成できるモデル、LoRAを紹介 ｜ Murasan Lab | murasan-net.com |
| 569 | 更地にした土地の固定資産税が、意外な金額だった - 薬指のブログ | kusuriyubino.hatenablog.com |
| 569 | 【著作権侵害】NHKによる無断転載の詳細と裁判結果のご報告｜将棋講座ドットコム | xn--pet04dr1n5x9a.com |
| 537 | フェスガチ勢が「疲れにくい」と太鼓判を押すスニーカー「ホカオネオネ」がやっぱりほしい #楽天お買い物マラソン #ソレドコ - ソレドコ | soredoko.jp |
| 503 | GPT作曲くん | compose.yumetaro.info |
| 502 | 生成系AI(ChatGPT, BingAI, Bard, Midjourney, Stable Diffusion等)について | utelecon.adm.u-tokyo.ac.jp |
| 499 | Vol.107 ｜ PIZZA OF DEATH RECORDS | www.pizzaofdeath.com |
| 482 | ChatGPT英語例文自動添削プロンプト | yanase-yosuke.blogspot.com |
| 481 | 年収1500万円だけど「ペットボトルは買わずに水筒持参。徒歩20分以内なら電車に乗らない」と語る女性（2023年3月31日）｜BIGLOBEニュース | news.biglobe.ne.jp |
| 480 | なぜHTMLだけなのか。拙著「武器になるHTML」の執筆を通して伝えたかったこと - Shibajuku | shibajuku.net |
| 480 | 三菱重工 ｜ 社名変更のお知らせ | www.mhi.com |
M1 pro Macにて。ここ参照：https://github.com/magnusviri/stable-diffusion/tree/apple-silicon-mps-support
git clone https://github.com/magnusviri/stable-diffusion.git
cd stable-diffusion
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
conda activate ldm
mkdir -p models/ldm/stable-diffusion-v1/
https://huggingface.co/CompVis/stable-diffusion-v-1-4-original から`sd-v1-4.ckpt`をダウンロードして、
ln ~/Downloads/sd-v1-4.ckpt models/ldm/stable-diffusion-v1/model.ckpt
以下のパッケージを追加した。https://twitter.com/hevohevo/status/1562364961481162754?s=20&t=KxNXNB9fz99fbosZ8TfnvQ を参考に。
conda install onnx
pip install invisible-watermark
それで実行
python scripts/txt2img.py --prompt "a photograph of an astronaut riding a horse" --plms
するとエラーになる。https://qiita.com/hevo2/items/e646148a05118074fecf に従い、下記ファイルの2511行目を書き換え。
vi /opt/homebrew/Caskroom//miniforge/base/envs/ldm/lib/python3.10/site-packages/torch/nn/functional.py
LIB全固体電池は、NEDOも海外勢も、2025年ぐらいから市場投入されると見てるよ。あと3年後。個人的にはそんなに魅力感じないけどね。
それと並行してLFPが低コストセグメント（資源制約がないが、LIBより低エネルギー密度）を担い、さらにナトリウム系がそれを補完し…とやってるうちに、ポストLIBの本命系（資源制約がなく、LIBより高エネルギー密度）が出てくるのが、内外どちらでも大方の技術ロードマップで2030年前後。あと8年後。いま日本のユーザーの買い換えスパンは7〜8年だから、次買うクルマに乗ってる間にそういうバッテリを搭載したEVが登場してくるってことだ。
日本の研究界・産業界はかなりアグレッシブにEV向け電池技術での捲土重来に取り組んでるので、むしろ「日本ｵﾜﾀ」系じゃない人達こそEVを応援しがいがあると思うよ。
おれは日本こそがEV技術の最先進国だったと思ってるし、今後もそうなれる余地は十分あると思ってるよ。
増田の「航続距離500km以上を求めるBEVは無駄多すぎるからいらない」説も、結局のところは、技術革新によって「安価で、エネルギー密度が高くて、急速充電できるバッテリ」が登場すれば、一気に解決しちゃう話だろ？ んで、日本のメーカーだってそこを目指してあれやこれやトライしてるわけじゃん。
確かにCATLはすごいけど、彼らだって将来性ある技術すべてにbetできてるわけじゃなくて、その隙間部分はいっぱいある。EV用や定置蓄電用の二次電池技術はそれこそ全世界で「マルチリソースで」研究開発が進められてて、しかもどれがブレイクするかはまだ全然わからない。日本が一発逆転できちゃう可能性はまだまだあるんだよ。
NEDOの二次電池開発ロードマップとか見たことある？ 今は第3次かな、の策定やってて、他国の優位性がある全固体LiBはすっと飛ばして「資源制約・調達リスクが無く安価な材料（銅、鉄、亜鉛、炭素等）を使用し、高エネルギー密度化と安全性の両立が可能な電池」としてフッ化物電池と亜鉛負極電池の開発研究にbetすることになった。このうち、フッ化物電池の実用化は最近かなり現実味を帯びてきてる。 https://xtech.nikkei.com/atcl/nxt/column/18/01511/00003/ 実現したら最低500Wh/kgと、現時点での最高性能クラスのLiBの約2倍の容量だ。これでLiB全固体電池やってる連中をごぼう抜きできたらどうよ？ 痛快だろ。
リサイクルに関しては、三元系だろうがLFPだろうが、「やればできる」技術ですよ。人間が自然界から取り出せるものを、高濃度な人工物のコンパウンドから取り出せないわけがない。湿式製錬でも乾式製錬でも、どうとでもできる。今「やれてない」のは、そこに何か未解決の技術的課題があるわけじゃなくて、新規採掘マテリアルより再利用マテリアルのほうが高くつく間は、リサイクルはペイしないから。それでもコバルトとニッケルは回収が採算化するメドがついてきたから、レアメタル大手のUmicoreとかはLiBリサイクル事業を積極的に拡大してる。
一方でLFPのリサイクルに関しては、現時点ではエネルギー業界ではあまりポジティブな意見がないのは確かだけど、これも何か高い技術的なハードルがあるわけじゃない。鉄とリンの塊という、現在は低価値なマテリアルをリサイクルしても、業者は儲からないから、やってない。リサイクルをする経済合理性がないということです。こういう「中長期的には枯渇していくかもしれないけど、現時点では比較的入手が容易な資源」でリサイクルを廻すには、もっと価格が上がるか、新規採掘量を法的に規制するステップが必要になる。
以下の動画はバッテリ持続性サミットの質疑応答。「LFP電池のリサイクルにも経済的合理性は見込める」と言ってるけど、それは今ではない、LFPのEVが市場に増え、そのEVの製品寿命が1ターン回り、リサイクルするLFPの量が増え、リサイクルの採算規模が確保できる頃に意味が出てくる、また（一度マテリアル化しての資源市場での再販ではなく）廃LFPの正極を直接リサイクルして再利用できるようになれば有望だ、というようなことを言っている。
https://www.youtube.com/watch?v=4MvSABcJ70k
それにね、増田は「リンが高騰してて大変だ」というけど、今の「高騰した」リン酸塩の取引価格が250円/kgぐらいでしょ。対するコバルトは10000円/kg超え。やっぱりこの2つを「希少な資源」として同列に語るのはかなり無理がある。元増田は「「肥料じゃなくて電池にするから安くしてくれ」なんてできないんだよ」と言うけど、期待付加価値から考えれば、産業用途リンは絶対に農業用途リンに買い負けたりしない。もし農業リンがコバルトに競るぐらいの希少資源になったら、その頃は世界の慣行農業の仕組みは崩壊してるよ。
もうすでにリン鉱石の値段が上がり始めている現状で10年後のリサイクルの話をされても、、、って思うね。それこそ次世代電池が普及し始めてるかもしれなくない？
そうだよ。もし今後LFPがずっとEVバッテリの本命級のままで、リンが電池への採用が困難になるほどの希少資源になれば、その時にはLFPリサイクルが実現する（そして、その時に走行しているLFPベースEVの台数を維持できる程度のLFP電池を、リサイクルから再製できる）。一方、リンが今のように肥料としてバンバン蕩尽できるぐらいの価格で供給されるなら、LFPリサイクルは実現しない。さらに、もし将来、LFPよりも製造コストが低くて十分な性能を持つ次世代電池が普及し始めたら、やっぱりLFPリサイクルは実現しない。つまり、将来LFPリサイクルが実現しないとしたら、それは「LFPをリサイクルしなくてもEV業界には問題ないから」なんだよ。
なお、自分はLFPはあくまで脱レアメタル化のためのひとつの通過点だと思っている（二次電池進化の「現時点での経由地」という書き方をした通り）。さらに高密度で安価で持続性のある電池が必要とされる限りは、新たな技術が開拓され続ける。
電池技術の発展速度が、たとえば電子技術なんかに比べると比較的遅いというのは正しい指摘だけど（自分もこのエントリ https://anond.hatelabo.jp/20150504101626 の中でそれに言及したことがある）、その後6年間で電池業界が達成してきたことは、正直自分の予想を超えていた。やっぱり将来の基幹産業としてR&Dが廻り出すと、これまでとは技術進歩のペースが桁2つぐらい違ってくる。CATL、BYD、テスラみたいなとこは言わずもがなだし、NEDOだって日本の研究機関だって企業だって色々やってる。
次世代EV電池で上市が一番速そうなのは、ナトリウムイオン電池かな。CATLは2021年にラボレベルで製品発表していて、2023年に量産化を予定している。ご承知の通り、CATLは狼少年みたいなことはしない会社なので、ある程度の目算はついているはず。
https://xtech.nikkei.com/atcl/nxt/column/18/01992/00001/
元増田ならこの他にもカリウム系、カルシウム系、Li-S、Al-S2などを始め、電池分野では多種多彩なトライアルがなされていること、そのうちいくつかは近年ブレイクスルーが起きて実用化までのロードマップが大幅に短縮されたことも知ってると思う。リン枯渇が全地球的な課題になるよりずっと前に、電池技術は大幅に進歩して、普及価格帯のEVでもICEを超える走行距離と必要充分な充電速度を達成できるよ。社会がそれを求めていれば、研究と産業は絶対にそのニーズに応える。自分はそのステップで日本の研究者や企業が貢献してくれることを期待したいし、楽しみにしてる。
最後の、「でもちょっとでも日本の自動車産業を応援してくれると嬉しいな」については、自分はめちゃめちゃ日本の自動車産業や電池研究を応援してるし、そう書いたつもりだよ。
ただ、トヨタのBEV戦略（2030年に車種の1/3を、販売台数の1/3をBEVにする）は、今の地域別売上からするとかなり奇妙な方針で、額面通りに受け取るなら間違った戦略だと思う。あのトヨタの発表が出たときは、ネットでは「EVでもトヨタが勝つる！」「30車種すげえ」「EU勢ざまあw」みたいな反応が多かったけど、個人的には「えっ、そんだけ？」としか思えなかった。系列企業への配慮などで、あえて低めの発表をしてる可能性があるとすら思ってる。
なにが奇妙かといえば、トヨタというグローバル企業の売上構成から考えると、2030年に1/3をBEV化する程度じゃ全然売るタマが足りないはずなんだよね。トヨタの自動車販売台数は、2021年実績で、日本国内が140万台、海外が810万台。海外を地域別に見ると、北米が270万台、欧州が100万台、中国が200万台。よく「欧米以外の地域には、今後もICEやHVのニーズが根強くあるから…」と言う人がいるけど、トヨタの国別販売台数は、この北米・欧州・中国の3地域で輸出市場の70%、全生産量の60%を占めている。つまり発展途上国と日本を足した「2030年頃にICEやHVを売り続けられる地域」の市場規模は、今の販売先の40%しかない。
「4割の残余市場に向けて、全車種の2/3でICEとHVを維持する」というのは、ポートフォリオ戦略としておかしいでしょ？
ちなみにホンダは「2030年に2/3をEV化」、GMは「2030年までに北米生産の50%をEV化」、フォードは「2030年までに40%をEV化」という構想。つまりトヨタは、ICE規制までまだだいぶ間があるアメリカのGMやフォードに比べてもEV化に対して慎重な（鈍重な？）動きになっている。
「規制が始まるまではICE・HVを売ればいい」という人もいるけど、一旦ICEの規制・禁止法制がアナウンスされれば、その実施時期に5〜10年先行してICEやHVの売れ行きは落ち始める。消費者は、一定期間乗った車を手放す時点（規制後）で、ICEの中古車価格がガタ落ちしていることを予期するから。今の先進国での自動車買い換えサイクルは、日本で平均8.5年、米国も7.3年、欧州はもっと長い。最近は日本でも「これが最後に買う内燃車かな、次はEVだろうな」なんつって自動車を買う人が増えてるでしょ。海外もそう。
最近の欧州車ディーラーでは一種のdisclaimerも兼ねて「EVのほうが下取り価格は有利です」と言われることが増えたけど、今後は先進国のどこでもこの傾向が加速し、おそらく2026年あたりから「EVか死か」の秒読みが始まる。そんな状況で、「2030年には、なんと全車種の1/3をBEVにしまぁす！」みたいな悠長なことを言ってて、まともに戦えるのかな、何らかの思惑含みのフェイクであってほしいな、というのが今の自分がトヨタに思ってることです。
id:sgo2 2030年時点でBEVが1.6〜26%という予測(https://s.response.jp/article/2017/10/11/300895.html )なので、1/3という数字でも十分前のめり。因みに現時点で欧州17%中国16%米国4.5% https://www.jetro.go.jp/biznews/2022/05/613a9a4551b47453.html (本当に数字見んのな)
2022/06/21
この上の記事は2017年時点のデロイトトーマツの予測で、ドッグイヤーのこの業界では既に典拠にしないほうが良い内容です。なお2017年はEVバッテリの平均価格が急低下した年で、これ以後コンサル各社はBEV普及ペースを大幅に上方修正しました。たとえばボスコンがつい最近（6/13）に出した予測はこんな感じです。
図表では、2030年の世界の新車販売台数のうちBEVが40%、2035年には59%になってますね。米国・欧州・中国を個別に見ると、さらに多い。上で書いた通り、トヨタの海外売上は北米・欧州・中国の3エリアで70%を占めてるんですけど、そのマーケットは今からわずか8年後にはこういう顔つきになっているということです。これ見てると、トヨタの「BEVラインナップは3割」戦略は相当ヤバいな〜って思いませんか。
自動車産業に特化した情報サイトのマークラインズは、LMC Automotiveの調査を引用して世界乗用車販売に占める各パワートレインの構成比推移予想を出しています。こちらは2022年1月の予測ですが、ボスコンよりやや保守的で、2030年のBEV比率は25%前後。ただしその3年後の2033年には40%を超えるシナリオです。
https://www.marklines.com/ja/forecast/index
2番目の記事で引用されているIEAも、2030年に①現状政策シナリオでは世界販売台数の26%程度が、②持続的発展シナリオでは47%程度が、EV（BEV+PHEV）になると予測してます。なおBEVとPHEVの販売比率は現状7:3で、IEA予測では、2030年もだいたいこの比率が維持されるようです。
つまり2017年時点では「最大でも26%」と推定されていたBEV販売比率が、今では「最低でも26%」（ただしPHEVも含む）になっているんです。この5年間のBEVの販売台数の伸び方は、多くの業界関係者の予想をも大きく上回ってたということですね。我々消費者も、EVについて何か考えたり議論したりするのであれば、とにかく最新の情報をチェックして、細かく自分の常識に当て舵をしないと、あっという間に現実に置いて行かれます。そういうスピード感のある業界だから、自分は面白くウォッチしてるんですけどね。
（6/21 1:15 追記）
なんか元増田とかこの増田で「リン酸鉄系電池のせいでリンが枯渇する・枯渇が近づく」って言う内容を読み取ってる人がいるみたいだけど、そんなこと書いてないよ。元増田では追記で「枯渇が見えてる資源を使ってたら価格が下がっていくとは考えづらい」って書いたし、ここでは「問題は消費量じゃない」って書いてるよ。書いてないことを読み取られても反論のしようがないからね。
（追記終わり）
書き方が悪くてEVアンチだと思われている節があるんですが（ただこれは完全に私が悪いです。すみません）、あくまで現状の電池技術ではコモディティ化は難しいだろうということを資源という面から書いたつもりでした。いい加減なことを書いているとまで言われてしまったのは心外だったけどね。
korilog 埋蔵量はその時点で経済的にメリットの出る採掘量なので、採掘技術の進歩や価格の高騰で増える。自分が子供の頃にはお前らが大人になる頃には石油が尽きるからなって言われてたけど、寧ろ尽きるまでの年数が伸びてる
そうだね。でも価格が上がってしまうとますますコモディティ化からは遠ざかるよね。
muchonov 電池技術開発の弾込めは日本含め世界中で高密度化とレアメタルフリー（=廉価化）を目指して突き進んでるので自分は楽観的。次世代Li系は概ねコバルトフリーだし、本命はほぼ無尽蔵のNa・K系。リンは→https://bit.ly/3b1rPGk
そうだね。でもね、リチウムイオン電池って30年前には実用化されてた（1991年、ソニー）んですが、EVとして普及し始めたのはこの10年ほど。あくまでタイムスケールを感じてもらうためにこの例を出したので、そのまま当てはめることはできないけど新しい電池を車用に実用化するとなったらそれなりに時間がかかるのは覚悟しておくべきだろうね。多分今のEVブームが盛り上がっている間（今のインフレ退治の後の景気後退が来るまで）には間に合わないだろうな。でも、多分EVを一般的に普及させるのは全固体電池なり金属空気電池だろうなとも思うから、投資は惜しまないでほしいなとも思うね。
リン酸鉄系について色々ブコメや増田があったんだけど anond:20220620101253 に答えるのが手っ取り早そうだから答えるね。
あのさあ、LFP電池が使うリンの量なんて、農業利用される莫大なリン量に比べたらタカが知れてるというか、はっきり言って誤差のレベルでしょ
そうだね。でもね、問題は消費量じゃないんだ。リン酸塩の値段は今後も続くリンの採掘によって上がっていく。「肥料じゃなくて電池にするから安くしてくれ」なんてできないんだよ。現にウクライナ侵攻後にFertilizer prices indexの値段は2倍になってるからこの影響は半年もしたら出始めると思うな。あとね、個人的に心配してるのがこのあと天変地異なりでリンの値段がさらに急騰した場合に安全保障を名目に中国政府が梯子を外してくるんじゃないかということ（四川大地震の時に似たようなことが一回あったみたい）。リンはレアメタルよりも大事な、人間にとって生きていくのに絶対必要な元素なのでそれを電池に使い続けるのは政治的にも難しいと思うな。
そもそもLFP電池自体がNMC系のLiBに比べて長寿命なうえに、最後までバッテリセル内に滞留してて100%リサイクルできるからね
これは違うよ。調べてもらったらわかるけど二次電池の正極活物質のリサイクルって実は難しくて、今やってる電池のリサイクルって実は負極に使う銅箔など肝心の正極以外のものが多いんだ（実は三元系でもまだそんなにできてないんだ）。リサイクルがビジネスになるかどうかを無視したとしてもリン酸鉄のリサイクルなんて今出回り始めたEVのリサイクルをするわけだから10年後に軌道に乗るビジネスだよね。もうすでにリン鉱石の値段が上がり始めている現状で10年後のリサイクルの話をされても、、、って思うね。それこそ次世代電池が普及し始めてるかもしれなくない？
元増田みたいな主張に対して「EVオワタ論者が寄ってきてセンセーショナルになりがちな風潮はマジで吐き気がする」って思う人はむしろ増えると思うよ
これはその通りで、書き方がよろしくなかったと思っています。すみません。あと書き方が悪かったのは承知の上で言ってるけど自分はEVアンチでもテスラアンチでもCATLアンチでもないです。CATLは本当に世界一の電池メーカーだと思ってるしめちゃくちゃ期待してます。
以下はその下の部分に対してのコメントです。
市場原理の話はまあ定性的に理解できるんだけど、さっきのタイムスケールの例からもわかると思うけど電池の進歩って半導体みたいに速くないんよ。レアメタル使わないのは結構なんだけど、それが使えなかったとしてもみんなEVなり蓄電池が欲しかったらレアメタルを使ってる電池を使わざるを得ない（後、電池の新技術って声高に宣伝される割に実際実用に耐えるのが出てくるのってそんなに多くないんだよね）。個人的なところを言うと新自由主義的な市場原理で技術革新を説明するのは開発者がちゃんと儲かる仕組みを作ってからにしてほしいとおもうね。
自動車の電動化についてはおそらく業界の人はみんな避けられないと思ってるよ。でもね、100年ほどの自動車の歴史を振り返ったらわかるんだけど先進技術がほぼ100％で不可逆的に普及するタイミングってほんとわかんないんだよね。100年前のアメリカの例で考えてみよう。
1900年代ー1920年代のアメリカって蒸気、ガソリン、電気自動車が鼎立していて、蒸気はPWRの面で、電気は航続距離の面で難があった。だから当時の人もこれからの主流はガソリンになるんだろうなって思ってて、実際ガソリン自動車会社の創業ブームになって1900年代はアメリカ全土でおよそ300もの自動車会社が存在したんだ。ガソリン車っていうのは既存の自動車に比べて
という利点があった。だからたくさん参入してきたんだ。でもね、結局ガソリンエンジン車の普及とBig threeの隆盛が決定的になったのは自動車の技術の問題じゃなくて、世界恐慌とその頃にテキサスで大油田が発見されてガソリンが安くなったからなんだ。その頃にはもうアメリカ全土にあったガソリン車に群がった中小企業は世界恐慌でもう潰れてる。だからその後のアメリカ自動車市場は生き残ってたクライスラー、GM、Fordの寡占になったんだよ。
この例から見てもわかるんだけどね、みんなわかってるんだよ。次に来る技術は。でもそれが決定的に普及するのは外部的要因に依存することが多くて時期は本当に読めない。だからそこまで体力を温存するという戦略もできるし、むしろ自分でその変化を起こしてやろうという戦略もとれる。どちらが正解なのかは正直分からない。でもね、技術的な側面だけじゃなくて社会的な側面から見ても現状の技術でのリチウムイオン二次電池は電池をコモディティ化させるゲームチェンジャー足り得ないだろうというのが正直な感想になる（将来的にもないとは言ってないよ！あくまで今の技術ではという話）。ただしその答え合わせは10年後かもしれないし、もしかしたら30年後かもしれない。もしかしたら水素なりアンモニアがゲームチェンジャーになるかもしれない。だから、日本人としてはトヨタの戦略が正しいと思いたいけど、そうではないかもしれないとは思っています。でもちょっとでも日本の自動車産業を応援してくれると嬉しいな。
なんかブコメいっぱいついてるけど、賢者っぽくいい加減なことを書くのはいかんよ。
リン酸鉄系もよく引き合いに出されるけど
あのさあ、LFP電池が使うリンの量なんて、農業利用される莫大なリン量に比べたらタカが知れてるというか、はっきり言って誤差のレベルでしょ。農業分野での消費量のオーダーは年間1.5億〜2億トンって世界じゃん。「世界の推定埋蔵量は700万トン」のコバルトに関して増田がやったような試算をリンでやったら、LFP電池のEV何台作れることになるかな？って話ですよ。
しかも、消費とともに土壌や水系に原子レベルで散逸して回収不能になる農業用途と違って、電池に利用するリンは決して「消費」はされないわけ。そもそもLFP電池自体がNMC系のLiBに比べて長寿命なうえに、最後までバッテリセル内に滞留してて100%リサイクルできるからね。今時の自動車産業は、現時点でも途轍もなく高いリサイクル率（重量ベースで99%）を誇ってるわけで、リンの資源制約がLFP電池ベースのEV生産の現実的障害になることはまずありえないよ。
電池技術開発はいまエネルギー分野で一番アツい領域のひとつだから、日本でも海外でも、企業でも研究機関でも、開発ロードマップがものすごく充実してる。主となる幹が太いし（現行技術の延長でモノにできる見込みの高い技術がある）、枝も多い（ブレイクスルーになりうる新技術が数多くトライされてる）。資源制約の問題があるから、脱コバルトと脱リチウムはその中でも優先順位が高い。2030年までにはほぼ確実にコバルトフリーLiBが主役を担うようになり、CATLはじめ各国メーカーからリチウムフリーの新世代電池も出てくる。
そういうタイムスパンで動いている業界で、EVの消費量とはほぼ無関係な2060年頃のリン資源の枯渇予測を持ち出してEV懐疑論の論拠にするの、たぶん増田も内心（コレ、ちょっと無理があるかな〜…）と思ってるんでしょ？ だから、そのへん曖昧な書き方をしてるんじゃない？ だったらさあ、
とにかくEVになるとテスラ信者が偉そうになる上に日本オワタ論者が寄ってきてセンセーショナルになりがちな風潮はマジで吐き気がする
とか書かないほうがいいよ。そういう仕掛けに気づかれると、元増田みたいな主張に対して「EVオワタ論者が寄ってきてセンセーショナルになりがちな風潮はマジで吐き気がする」って思う人はむしろ増えると思うよ。
これは増田の批判から離れるけど、供給制約がある資源の問題解決は、実は市場原理ととても相性が良いんだよ。シンプルに、あるアプリケーションを作るときに、割高な技術は割安な技術に負けるから。原材料の価格はずっと製造供給コストを拘束する。テクノロジーを高度化することで、安い原材料で同等性能を発揮する製品を作れれば、イニシャルの研究開発投資・設備投資を回収したあとはずっと製造供給コストを低廉にできるでしょ。
これは環境正義の話でも、途上国でのレアメタル生産に伴う労働搾取の話でも、資源安全保障の話でもないよ。単純に、レアメタルを使わないと作れない電池より、コモンメタルだけで安く作れる電池のほうが市場性を期待できるから、電池の研究開発は後者に向かって進んでる。
市場原理に任せれば、自ずとレアメタルは使われなくなっていく。その経由地が、現時点では、コバルトの代わりに供給制約が少ないリンを利用するLFPということ。数年前は「LFPは容量の問題でEVには向かない」と言われてたけど、すでにテスラやBYDのラインナップの半分程度はLFPに切り替わっている。なんでかといえば、一生懸命に技術開発したことで、安いけど必要十分な性能を発揮できるようになったから。
これからはもっと安い方式の二次電池が出てくるし、安くなればなるほど、そのアプリケーションは社会全体に広がっていく。それぐらいのペースでEVをとりまく環境は激変してるし、そこには日本の研究機関や企業も大いに関わっている。
なんか日本でのEV化懐疑論って、やっぱり「日本はEV化時代には勝てない」という悲観論が背後にある感じがするんだよね。でも、トヨタがダメでも日産三菱とホンダソニーは頑張るかもしれないでしょ。トヨタのエンジン作ってるヤマハ発動機が潰れても、日本電産は世界最大のeアクセルサプライヤーになるかもしれないでしょ。日本の衰退って、技術力の衰退だけじゃなくて、そういう時代の画期を新たな事業機会につなげるポジティブなマインド自体の消失にあると思うんだよね。
何度か書いてるけど、日本の自動車産業って、もともとは環境技術への適応によって世界的覇権を獲得してきたんだよ。マスキー法という非常に厳しい排ガス規制に、米国の自動車メーカーに先駆けて対応したからこそ、ホンダやトヨタは米国市場で急拡大できたわけでね。 https://www.ipros.jp/monosiri/term/%E3%83%9E%E3%82%B9%E3%82%AD%E3%83%BC%E6%B3%95
そしてEVについて、日本はもともと要素技術を全部持ってたんだよ。リチウムイオン電池の産業化は日本が先陣を切った。自動車の電動化技術も日本が先駆者だった。EVの発売と商用化だって日本がリードしてきた。今だって欧州のEV性能のベンチマークカーは日産LEAFだよ。いま世界の電池技術をリードしているCATLはもとはTDKの中国子会社だよ。
日本を愛し、日本の企業や技術に自信があるなら、なぜ変化をおそれるのかなあ。日本だけが「いやだいやだ」と言ってても、結局その変化は来ちゃうんだよ。日本だけが「HVが最適解だ」と言ってても、HVはもう世界中で売れなくなるんだよ。カリフォルニアのZEV規制では、PHEV以外のHVはもうエンジン車と同じ扱いだよ？ https://xtech.nikkei.com/atcl/nxt/column/18/00001/04642/
もう「日本が誇るハイブリッド車」は、そのうち世界中で法規制で売れなくなる（禁止されたり、クリーン車との販売比率に制限を課されたりする）。だったらEVに全振りして、そっちでどんどんイノベーションして、欧州のいけすかない高級ブランドや中国のポッと出メーカーと互して戦える「日本が誇るEV」を売りまくればいいじゃない。なんでそっちに発想が行かない？ 自動車産業を取り巻く客観的情報から隔離され（あるいは自ら目と耳を塞ぎ）、「EVなんかダメだ」と後ろ向きの大合唱をしてる連中が、日本の産業競争力をさらに下げ、国際市場での生残可能性を潰しているということに気づいてほしいなー。
…というようなことを書くと、さっそくブコメで自動車産業を取り巻く客観的情報から隔離された（あるいは自ら目と耳を塞いでる）実例が採取されたぞ。
id:XYXY EVが売れないのは懐疑論者のせい!は流石に草。どうにかこうにか気に入らないやつを攻撃して自分の見識をアピールしたいという要求しか感じられない
自分はこのエントリで「EVが売れない」なんて1mmも書いてないよね。というか…いいか、耳をかっぽじって聞けよ。あのな！ EVは！ 売れてるんだよ！ HVより！
https://www.nikkei.com/article/DGKKZO59942190T10C22A4MM8000/
https://www3.nhk.or.jp/news/html/20220530/k10013648981000.html
https://www.autocar.jp/post/807594
日本にいて、自分が心地よく感じるメディアばっかり読んでると、そういうことがわかんなくなっちゃうだろ？ 「EVはエコブームに乗じた高級車で、HVこそがICEの延長のスタンダードな乗用車」「EVは大して売れてない」っていう数年前のイメージのままEVを批判してるんだろ？ それとは違う、自分の先入観とは反するファクトを不意に示されると、それは相手が「自分の見識をアピールしたいという要求」なんだと解釈して、肝心の新たな情報自体は見なかったことにするんだろ？ そういう要求（正しくは欲求）しか「感じられない」理由は、あんたがそれ以外のことを「感じたくない」からなんだ。もう、まんま地面に頭を突っ込んで危機を逃れたつもりになってるダチョウじゃん（ちなみにこれは俗説で、そもそもダチョウにはそういう性質はないのだけど）。何が「流石に草」だよ。なさけない。
もう一度書くよ。こういう風に、現実歪曲フィールドの中で「EVなんかダメだ」と後ろ向きの大合唱をしてる連中が、日本の産業競争力をさらに下げ、国際市場での生残可能性を潰してるんだよ。
元増田が https://anond.hatelabo.jp/20220620201004 を書いてくれたので、こちらもリプライ。
https://anond.hatelabo.jp/20220620225630
https://www.mazda.com/ja/innovation/technology/gihou/2021/
これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます。
電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。
普段こういうことやらないので読みにくかったら見なかったことにしておいてください。
あと、そもそも私は社員でもE&Tさんや販売店さんでもないですので間違ってたりしたらごめんなさい。
去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないからノーカンで)
では順に見ていきます。
こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略的判断なのでしょう。
私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。
https://www.mazda.com/ja/csr/environment/lca/
ところで、技報は直近だと技企が担当っぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。
両開きドア、必要だったんでしょうか。使いにくいと思うんですが…
車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。
私は美術の成績が2くらいしかないのでデザインはよくわかりません。
あ、でも、インテリアのコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。
書かれていることは難しくて分かりません。商品企画って大変だと思います。
みなさん、一回乗ってみるといいと思います。思いの外普通の車です。
制御って難しいですよね。まず式が多くて難しい。
この手の制御は実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います。
Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータのリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。
Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通に運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?
この辺で読むのやめたけど、Fig.20はどうかと思う。基準値おかしいでしょそのグラフ。
この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)
Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転しやすかった気がする。
これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。
電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアのバグのリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。
でもそれよりもあの変なシフトの形状の方が気になる。
LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。
ふむふむ、LiBの温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。
「クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。
なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくらい寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。
ところで、車室内が暖房で電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。
冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。
あ、そういえば低温の充電についてはこんな記事ありましたよ。
マツダさん、色んなところでMBDのお話してるのでやっぱりありました。
元々シミュレーションで研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。
これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…
ゴリゴリの計算化学的なのはないんでしょうか。EVだから電池系でその辺もあるかと思ってたんですが。
気になるのは4.1の説明で「ユニット間通信もPCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。
Fig.5らへんでは「充電みたいに特定の機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットをそもそも動かさないのは当然だと思うんですが。
4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか…
市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言。
え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。
外部充電関連やってる人はホント尊敬してます。だって仕様書難しいし仕様書曖昧なときあるし。COMBOとか仕様書自体なんか怪しいし。
本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います。
2.1見ると電池は電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。
でも電池って重量あるし、特に考慮とかいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。
2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自の概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度と応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自の手法が隠れてるってことなんだろうか。
そして3.1には気になることが書いてある。
いや、とんでもない超過剰品質じゃん。強度半分でいいから車両価格下げてくれ。
3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。
ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。
2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100でメカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車見たことある人は分かると思うんだけど、MX-30ってモータルームスカスカでバカでかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであんな構造なんだろう。
3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーションの研究やっていた身としてはシミュレーションが完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験は実車だろうけど)
よくわかんない。たぶん難しい。
日本語でおk。なんだそれは。とりあえず読んでない。
電池もEVも関係ないけど私が元々分子動力学シミュレーションやってたから。
でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。
これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。
この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものだから。ただ、現実の実験結果と定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的な比較はMDでは非常に難しい。
これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当性検証が書かれているけど、MDの結果については定量的に比較されているわけではない。紙面の都合もあるから仕方ないか。
ということでマツダ技報2021年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
電池技術って比較的発展がスローな分野だったけど、EVと再エネ蓄電関連で未来の市場規模がすごく大きいから、どんどん新手の技術が出てきてるよ。
まずLFP電池。コバルト・ニッケル不使用、エネルギー密度は現行LiBより低いのがネックだったけど、効率は継続的に改善されている。テスラの下位グレードなんかは既にこれ。中国でも普及価格帯はこれ。日本でも再エネ蓄電施設向けの定置型では本命になるかもしれない。
それからナトリウムイオン電池（NIB）。リチウム不使用。圧倒的に低価格になる。
https://xtech.nikkei.com/atcl/nxt/column/18/01267/00105/
次世代LIBでは、6分で90%充電できるようになる。こうなると、容量問題は実用上の課題にならなくなってくる。現行EVでも標準グレードで300km程度、高級グレードで500km以上、プレミアムカーは800kmぐらい走るわけで、それを超えるようなロングドライブ時だけ途中の休憩駐車時に5分で充電できればいいわけだ。今これに近いことができるのはテスラスーパーチャージャーぐらいだけど、どのクルマを買ってもこれができるようになる。
https://xtech.nikkei.com/atcl/nxt/news/18/11280/
リチウム空気電池やリチウム硫黄電池が次世代のロードマップとして見えている。飛躍的に容量効率が良くなること（現行の5倍前後）は確定していて、安全性や充放電回数の制限などの問題点をどう潰すかというステージにある（同じく容量向上で全個体に期待する向きもあるが、現状これは疑問符がつく）。ただ、今のLiBはコスパが優れており、今も継続的に性能が改善しているので、この手の次世代大容量電池は初期投入価格が高ければなかなか採用が進まず、量産効果が出ず、結果的市場に浸透しないかもしれない。今のEVはそれぐらい「こなれて」きている。
続き楽しみにしてます。
単純に蓄電技術として比較した場合、Lib等に比べて水素の劣る点が「変換ロスが多い」なんだけど、ロスの大部分は電気→水素の部分で発生するから、水素の状態からそのまま消費するのと発電して消費するのを比較した場合は、水素の欠点は殆どないと言えるのがポイント。
ここなんですが、自分の認識だと電気分解プロセスは吸熱反応、燃料電池プロセスは発熱反応で、後段の「水素→電気」のほうがエネルギーロスが多いと思ってました（PEM電解とか高温水蒸気電解は、吸熱反応を利用しているから効率がよい）。
前増田でも書いたけど、電気と一緒に発熱をコジェネ的に利用できればエネルギー効率は80%程度、発熱を捨てて純粋な電気エネルギーとして取り出せるエネルギーで見ると効率は50%程度で、今後技術革新を進めて60%を目指す、という感じだと思います。
この効率は利用する化学反応自体に拘束されており（その意味では今でも十分高率だと言える）、今後の劇的な向上は見込めず、そうなると純粋な蓄電システムとして普及させるのは厳しいんじゃないかと思ったりします。昼間の余剰電気を水素にしてその日の夜に売るだけでも6割以下に目減りしてしまうわけですから、今の卸電力取引市場の仕組みだと、この技術にbetする余地は低い（メリットオーダーで見た場合、他の方法で発電または蓄電された電気のほうが割安になる可能性が高い）のではないかと…。
具体的に他の蓄電システムと比較すると、揚水ダム発電だと電気を位置エネルギーに変えて、後で電気に戻したときのラウンドトリップのエネルギー効率が70%程度。レドックスフロー電池も同じく約70％。最近複数ベンチャーが取り組んでいる重力利用型蓄電（タワーや縦杭にコンクリートブロックなどの重量物を吊して上げたり下ろしたりして蓄電/放電する）だと、設置コストも管理コストも安く、施設寿命は35〜50年、ラウンドトリップ効率は揚水発電と違って流体摩擦損失がないので80-85%と、これが案外本命かなと思ってます。固定電池系は、LiBだと95%ぐらい出るけどLCAが悪すぎるので、非コバルト・非リチウム系で良いものが出てくるのを待つ状態かと思います。
水素のエネルギーキャリアとしての性質を活用せず、蓄電技術としてやっていくとなると、競合システムに対する優位性が乏しいなあと感じます。廃熱の二次利用ができるところならワンチャンあるけど、季節問わずに廃熱を利用できるロケーションとなると、はたしてそんな都合のいい場所があるかいね？と思ってしまうわけです。製鉄所の溶鉱炉を電炉化するぐらいでしょうか。
% poetry cache clear --help USAGE poetry cache clear [--all] <cache> ARGUMENTS <cache> The name of the cache to clear. OPTIONS --all Clear all entries in the cache. GLOBAL OPTIONS -h (--help) Display this help message -q (--quiet) Do not output any message -v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and "-vvv" for debug -V (--version) Display this application version --ansi Force ANSI output --no-ansi Disable ANSI output -n (--no-interaction) Do not ask any interactive question
これ見ると
poetry cache clear pypi
で動きそうじゃん？
% poetry cache clear pypi RuntimeError Add the --all option if you want to clear all pypi caches at /usr/local/lib/python3.8/site-packages/poetry/console/commands/cache/clear.py:44 in handle 40│ ) 41│ 42│ if len(parts) == 1: 43│ if not self.option("all"): → 44│ raise RuntimeError( 45│ "Add the --all option if you want to clear all " 46│ "{} caches".format(parts[0]) 47│ ) 48│
ブブー
動きません
正しくはこう
poetry cache clear pypi --all
直感的には--allをついてたら全てのキャッシュを消すべきだと思うが
% poetry cache clear --all Not enough arguments (missing: "cache").
ブブー
動きません
意味不明に思ったのは俺だけではないらしくIssueが出ている
https://github.com/python-poetry/poetry/issues/521
opened this issue on 19 Oct 2018 · 18 comments
2年前ですよ2年前!
Issue700個も溜まってますよ
pipenvもアレだったけどpoetryもアレだな
もう少しマシな奴が欲しい
