Enshittification――プラットフォームはなぜ必ず腐るのか

Enshittification――プラットフォームはなぜ必ず腐るのか

「最近、なんかこのサービス使いにくくなったな」 そう感じたことがない人のほうが少ないだろう。Google検索は広告とSEOゴミで埋まり、Amazonで商品を探せば怪しい中華ブランドのスポンサー商品が最上位を占める。Twitterの返信にはインプレゾンビのリプライが氾濫し、Facebookは友人の近況よりもアルゴリズムが推す動画を見せたがる。Uberの配車アプリは広告まみれになった。 これらは偶然の劣化ではない。構造的な必然だ。 SF作家にしてテクノロジー批評家のコリイ・ドクトロウ(Cory Doctorow)は、この現象に「Enshittification」という名前をつけた。直訳すれば「クソ化」。2022年にブログで提唱され、2023年にはアメリカ方言学会の「今年の言葉」に、2024年にはオーストラリアのマッコーリー辞典でも年間最優秀語に選出された。日本語では「メタクソ化」「エンシット化」「改悪化」など訳語が乱立しているが、いずれもこの品のない原語の破壊力には及ばない。2025年10月には同名の著書も出版され、FT/シュローダー ビジネスブック・オブ・ザ・イヤーのロングリストにも選ばれた。 三段階の腐敗モデル ドクトロウの理論の核心はシンプルだ。プラットフォームの劣化は気まぐれではなく、予測可能な三段階で進行する。 第一段階:ユーザーへの奉仕。 プラットフォームは赤字を垂れ流してでも、ユーザーに最高の体験を提供する。初期のFacebookは友人の投稿を時系列で正確に届けてくれた。Amazonは原価割れの価格と無料配送で顧客を集めた。Google検索は関連性の高い結果を返し、広告は最小限だった。この段階のプラットフォームは、まるで理想的な公共財のように振る舞う。 第二段階:ビジネス顧客への転換。 ユーザーが十分に集まると、プラットフォームは広告主や出品者といったビジネス顧客を優遇し始める。Facebookのフィードに知らないアカウントの投稿が混ざり始め、Amazonの検索結果に広告枠が増え、Google検索ではスポンサーリンクが上位を占めるようになる。ユーザー体験は犠牲になるが、まだ「我慢できる」程度に留められる。 第三段階:全方位からの搾取。 ビジネス顧客もロックインされると、プラットフォームはユーザーとビジネス顧客の両方から価値を搾り取り、株主に還元する。Amazonではマーケットプレイス出品者が売上の45%以上を手数料として取られるようになり、検索上位は最も高い広告費を払った商品で埋め尽くされた。Facebookは出版社に全文掲載を強いておきながら、リーチを絞って「ブースト」の課金を要求した。サービスは崩壊寸前まで劣化するが、ユーザーもビジネス顧客も「ロックイン」されているために離脱できない。 Twiddling――見えないダイヤル ドクトロウはこのプロセスの実行手段を「twiddling(ツイドリング)」と呼ぶ。プラットフォームがパラメータを絶え間なく微調整し、利用者が「もう限界だ」と感じる寸前で踏みとどまらせるテクニックだ。 デジタルプラットフォームの本質は、価値の配分を自在に操れるところにある。物理的な商品と違い、アルゴリズムの調整は一瞬でできる。ユーザーごと、セッションごとに異なる価格を提示することも、特定のコンテンツの可視性を上げ下げすることも技術的には容易い。商業的監視データを使えば、そのユーザーが受け入れる最高価格や最低賃金を予測することすらできる。 この非対称性が、enshittificationを可能にしている。ユーザー側からは、いつ、どのように価値が奪われたのかが見えない。気づいたときには、もう代替手段がない。 二面市場の呪い なぜプラットフォームは例外なくこの道を辿るのか。ドクトロウの答えは「二面市場(two-sided market)」の構造にある。 プラットフォームは買い手と売り手の間に立つ仲介者だ。両者がプラットフォームに依存すればするほど、プラットフォームの交渉力は増す。ネットワーク効果がロックインを強化し、スイッチングコストが離脱を阻む。友人が全員Facebookにいるなら、自分だけMastodonに移っても意味がない。出品者がAmazonを離れれば、顧客の大半を失う。 この構造は、プラットフォームに「善意でいる」インセンティブを与えない。競争圧力がなければ、残るのは株主への還元圧力だけだ。サービスの質を落としても、ユーザーが離脱できないなら、それは「合理的な」経営判断になる。 情報技術者が知るべき構造的教訓 Enshittificationの議論は、しばしば「巨大テック企業への批判」として消費される。だが、エンジニアやセキュリティ技術者にとって、ここにはもっと実践的な教訓がある。 APIの約束は永続しない。 プラットフォームが提供するAPIは、enshittificationの各段階で変容する。Twitter APIの段階的な制限強化と有料化、Reddit APIの突然の価格改定、Googleの各種API廃止——いずれもサードパーティ開発者をロックインしてから価値を回収するパターンだ。外部APIに依存するシステムを設計するとき、この構造的リスクを織り込まないのは脆弱性と言ってよい。 アルゴリズムの不透明性はセキュリティ問題である。 twidddlingの本質は、ユーザーに見えない形でシステムの挙動を変えることだ。これは情報セキュリティの文脈では、ユーザーの同意なきシステム変更にほかならない。プラットフォームのアルゴリズムがブラックボックスである限り、ユーザーは自分がどのように操作されているかを知ることができない。 データポータビリティは技術的防御策である。 ドクトロウが提唱する「離脱する権利(right of exit)」は、技術的にはデータポータビリティと相互運用性(interoperability)の問題だ。GDPRのデータポータビリティ権やEUのデジタル市場法(DMA)は、この方向での法的枠組みを提供しているが、技術的な実装はまだ発展途上にある。ActivityPubのような分散型プロトコルや、ATProtocol(Bluesky)のようなアプローチは、ロックインそのものを構造的に困難にしようとする試みだ。 AIはenshittificationを加速するか ドクトロウ自身が2026年3月のブログ記事で指摘しているように、AIはenshittificationの新たな道具になりつつある。 カスタマーサポートのAI化はその典型だ。何時間も待たされるコールセンターは、もともとユーザーから企業株主への価値移転の手段だった——人を雇わないことでコストを削減し、ユーザーの時間を犠牲にする。AIチャットボットへの置き換えは、この構造をさらに推し進める。問題は解決されず、しかも怒りをぶつける相手すらいなくなる。 LLMを使った検索結果の要約(AI Overview)も、コンテンツクリエイターからプラットフォームへの価値移転として分析できる。ユーザーが元記事を訪問しなくなれば、クリエイターの収益は減り、最終的にはコンテンツの質が低下する。プラットフォームは一時的にユーザー体験を向上させるが、長期的にはエコシステム全体を痩せ細らせる。 抵抗の技術 ドクトロウの処方箋は二つの原則に集約される。 一つはエンドツーエンド原則。プラットフォームは、アルゴリズムが決めたものではなく、ユーザーが求めたものを届けるべきだという考え方だ。フォローしたアカウントの投稿はすべて時系列で表示される。検索クエリに対する正確な結果がスポンサー商品よりも先に表示される。当たり前のことだが、現在のプラットフォームはこの「当たり前」を放棄している。 もう一つは離脱する権利。ユーザーがプラットフォームを離れるとき、データや人間関係を持ち出せるようにすること。これには相互運用性の確保が不可欠だ。電話番号をキャリア間でポータビリティできるように、ソーシャルグラフやコンテンツもプラットフォーム間で移行できるべきだとドクトロウは主張する。 個人レベルでできることもある。オープンソースの代替サービスを使う、自前のドメインとブログを持つ、データのエクスポートを定期的に行う、DRMフリーのコンテンツを選ぶ——これらは小さな行動だが、ロックインへの抵抗としては確実に機能する。 おわりに Enshittificationは、テクノロジー業界に固有の病理ではない。ドクトロウ自身が認めるように、突き詰めれば資本主義の力学そのものだ。利益最大化の圧力と、それを制御する規制や競争の不在が、サービスの劣化を「合理的」にしてしまう。 だが、構造を理解することは無力ではない。名前をつけることには力がある。「最近このサービス使いにくくなったな」という漠然とした不満が、「ああ、これはenshittificationの第二段階だ」という分析に変わったとき、我々は初めて意識的に行動を選べるようになる。 プラットフォームが腐るのは自然法則ではない。特定の政策選択と、それを許す構造の結果だ。であれば、構造は変えられる。少なくとも、自分自身のデジタルライフをどこに置くかは、自分で選べる。 参考文献:Cory Doctorow, “Enshittification: Why Everything Suddenly Got Worse and What to Do About It” (Verso Books / Farrar, Straus and Giroux, 2025)

2026年4月20日 · 1 分
ゼロ・グラビティを観た ── 無重力に放り出されることの怖さ

ゼロ・グラビティを観た ── 無重力に放り出されることの怖さ

「ゼロ・グラビティ」を観た。観ているだけで息苦しくなる映画だった。あんなところでは自分はとても生きていけない、と思った。重力がありがたいわ。 死に方の生々しさ 船員は窒息して、乾いて死ぬ。船外活動中だった男性は、デブリに頭を貫かれて死ぬ。後者の遺品のなかに、妻や子供の写真が写っていた。こういう、死んだ人物が誰かの大切な人だったという描写に、自分は本当に弱い。 ロシア人だったか、マットという男性も合理的な判断をしていた。二人で死ぬより一人が生き残るほうがいい、という選択。情ではなく合理で決めた選択は、観ていて辛い。 宇宙はきれいで、生きていけない 宇宙から見た太陽や地球は美しい。それは映画の中で何度も見せられる。しかしその美しさのすぐ隣で、空気がないというだけで人間は呼吸できずに死ぬ。あの落差が、この映画のいちばんしんどいところだと思う。 ふと脱線して考えたのだが、ガンダム世界はあれだけコロニーまで作る技術を持ちながら、なぜあんなに文化的・政治的には未熟なままなのだろう。技術と文化の発展速度は本来そんなに揃わないものなのかもしれない。あるいは、揃わないからこそ戦争が起きるのか。 細かいところで気になったこと 主人公の名前は思い出せないが、スーツ内の酸素が0%になってからも、彼女は結構な時間持ちこたえていた。あの状況で呼吸をコントロールするのは、実際どうやればできるのだろう。パニックの中で呼吸を意識的に抑えるというのは、訓練でどこまで身につくものなのか。 宇宙飛行士というのは、人類の中でも上澄みの中の上澄みのはずだ。それが事故で何人も死んでいく。映画の中の話とはいえ、もったいないと感じてしまう。現実でも宇宙開発の歴史で何人もの宇宙飛行士が亡くなっている。あれだけ訓練と選抜を経た人たちが、と思うと、やはりもったいない。 邦題と原題の話 邦題は「ゼロ・グラビティ」だが、原題は「Gravity」だった。無重力を強調した邦題と、重力そのものを題にした原題。逆である。 原題のほうは、観終わってから効いてくる。ラストで主人公が地表に降り立ち、地面の感触に手をつく場面。あれは「重力に戻ってきた」場面であって、映画全体は「重力を失い、重力に戻る」物語だった。そう考えると Gravity というタイトルのほうが、映画の構造を正しく射抜いている気がする。 邦題が「ゼロ・グラビティ」になったのは、おそらく日本の観客にとって「無重力空間で漂う絶望」のほうが宣伝文句として伝わりやすかったからだろう。商業的判断としては理解できる。ただ、作品の意図とはずれている。 雑談のリアリティ 劇中、宇宙飛行士たちは無線で結構くだけた雑談をする。実際の宇宙飛行士もあんなふうに雑談するのだろうか。任務中の通信記録を聞いたことがないので分からないが、極限環境にいる人ほど普段は冗談を言うものだ、という話は聞く。緊張を保ち続けると保たないから、意図的に弛緩を挟む。あれはリアルなのかもしれない。

2026年4月17日 · 1 分
2001年宇宙の旅は本当に「つまらない」のか ── 序盤は面白かった、という個人的な感想

2001年宇宙の旅は本当に「つまらない」のか ── 序盤は面白かった、という個人的な感想

「2001年宇宙の旅」を観た。結論から言えば、序盤の道具の発見からHAL 9000のあたりまでは面白く観ていたが、ラストの光が溢れる場面と老いていく場面、赤子のシーンに来ると意味が取れなくなった。同じように「分からなかった」「つまらなかった」と感じている人がいるはずなので、どこまで乗れて、どこから分からなくなったかを書いておく。 鑑賞環境について ── VR、モニタ、スマホ VRで途中まで見たが、書きたいことが多すぎて、結局モニタに切り替えた。VRのまま快適にメモが取れれば最高なのだが、Apple Vision Proでもなければ難しい。一方、モニタで見ているとスマホに手が伸びる。マウスでシークバーをなぞればその後の画面まで見えてしまうから、注意が散る。鑑賞環境というのは案外むずかしい問題だ。 序盤のサバンナの場面 ── ここはまだ面白い 最初はサバンナである。地球なのかすら分からない、人間がまだいない地表だ。アニメと違って、映画には必ず「撮影場所」が必要になる。これはどこで撮ったのだろうか、とまず気になる。 骨が転がっている。それで、かつて何かが死んだ場所だと分かる。 肉付きのいい、豚と馬の中間のような動物が出てくる。イノシシの類だろうか。それから、ゴリラのような黒い体毛の猿。これは遠い昔の地球なのか、それとも別の惑星なのか。スタンリー・キューブリックは、なぜ冒頭をイノシシと猿のシーンに割いたのか。ピューマのような肉食獣が猿を襲う。 水の少ない荒涼とした土地で、猿の群れが濁ったオアシスの水を飲んでいる。人間ならまず腹を壊すはずだ。猿の消化機能はどうなっているのだろう。 そこへ別の群れが現れて、縄張り争いになる。 人間とやっていることが変わらない、と思った。オスとメスの区別はつかないが、大きな声を出して縄張りを主張する。孤立した個体は肉食獣にも、同族の別の群れにも襲われる。だから群れる。鳴き声が言語に多様化したあとも、鳴き声そのものが担っていた役割が消えたわけではない。人間も同じことをしている。たとえば毛づくろい的なコミュニケーションがそうだ。 モノリスと骨 ── 道具の発見というアイデア そこへモノリスが現れる。例の伝記によると、あのマットな黒の質感を塗装で再現し、撮影中それを保つのに、スタッフはずいぶん苦労したらしい。 やがて一匹の猿が、転がっている動物の骨を眺める。手で握って、骨で骨を叩いてみる。道具の発見である。こういう小さな発想の積み重ねで文化は前に進む。 二度目の縄張り争いの場面では、攻め手が骨を握っている。前と同じ群れの、同じ攻守なのかは分からない。とにかく、骨で殴り殺してしまう。 そしてあの有名なシーン。一匹の猿が骨を空高く投げ上げ、骨が頂点に達して落ちはじめる。地面に着く前に、画面は宇宙空間に切り替わる。人工衛星か、それとも船か。 道具の延長線上に宇宙開発がある、と言いたいのだろう。気が遠くなるほど時間を飛ばす編集である。 宇宙のシーンで気になったこと 文明はずいぶん進んでいる。とはいえ、現実の2026年に至っても、民間人の宇宙体験がやっと始まった程度で、映画の描く宇宙時代には程遠い。 それにしても、と思う。なぜこの宇宙空間の建造物はこういう形をしているのだろう。続いて出てくる宇宙船には翼がある。宇宙空間で揚力は要らないはずだが、それでも飛行機に似た形をしている。 機内のペンの先端が赤いのも気になった。血液なのか、赤インクなのか。重力のある機内で、宇宙ではペンはどう挙動するのか。 白い制服にターバンのような帽子をかぶった女性。キャビンアテンダント的な役回りだろう。グリップシューズで床を歩いている。 コックピットでは、モニタが二人のパイロットの間にあり、席は左右に並んでいる。ガンダムのコックピットのように縦に並べないのか、と一瞬思ったが、現実の旅客機もパイロット席は左右に並んでいる。360度のモニタを覆うのでないなら、これで合理的なのかもしれない。 一週間経って思い返す ── 面白かった部分とそうでない部分 ここまで書いてから、見終えて一週間ほど経った。あらためて思う。これは何が面白いのか? 最後のほうの、AIが生成したような色彩がめぐるだけの映像はよく分からなかった。一方で序盤、道具の発明と狩猟の萌芽の場面、宇宙ステーションでの会話の場面、それからHAL 9000に読唇術的に会話を読まれて、自衛のために船員が殺されていくくだりまでは、まだ面白く見ていた。自分が乗っていける範囲はそのあたりまでだったと思う。 腑に落ちなかったシーン ── 船員を反対方向に投げる場面 初代ガンダムでいうボールのような形の小型機が、宇宙空間に投げ出された船員を前足のアームでキャッチする。ここまではいい。だがその直後、HALに船への帰還を拒まれたあと、なぜその回収した船員を、母船とは反対方向に放り出したのか。爆発から守るためかもしれないが、結局、HALを停止させて権限を取り戻し、船の操作方法を学び直しても、その船員はもう回収できない。あの判断が分からない。 1968年の特撮としての驚き、いま観るとどうか 撮影されたのは1968年。CGなど影も形もない時代に、この宇宙を再現してみせた撮影技術は賞賛に値する。ただ、いま観て、当時の観客が抱いたであろう「これはいったいどう撮ったんだ」という驚きを、同じ強度で味わえるかと言われると、やはり厳しい。 モノリスは、この映画が初出なのだろうか。もし発明だとしたら、相当にイカしている。あの形と質感だけで、十分に得体の知れない何かを背負っている。 ラストが分からない ── 光、老い、赤子、モノリス再登場 最後のほうの光が溢れる場面、なぜか登場人物が老いていく場面、モノリスがふたたび現れる場面、赤子が映される場面。ここに来ると、もう意味が取れない。 この分からなさそのものを楽しめ、ということなのだろうか。それが正解なのかもしれないが、自分にはまだ、そう構えて観るだけの度量がない。

2026年4月15日 · 1 分
Pythonの「クラス(class)」とは?JavaScriptとの違いを徹底解説

Pythonの「クラス(class)」とは?JavaScriptとの違いを徹底解説

Pythonの「クラス(class)」は、データ(属性)とそれに対する処理(メソッド)をひとまとめにした「オブジェクトの設計図」です。この設計図をもとにして、実際にデータを持たせた「インスタンス(実体)」が生成されます。 Pythonのクラスの概要と具体例 Pythonでクラスを定義する際は、classキーワードを使用します。コンストラクタには特殊なメソッド名である__init__を用い、クラス内のメソッドは最初の引数として必ず自分自身を指すselfを受け取るのが最大の特徴です。 Pythonの具体例: class User: # コンストラクタ(初期化メソッド) def __init__(self, name, age): self.name = name # インスタンス変数(属性)の定義 self.age = age # メソッド def greet(self): # selfを使って自身のデータにアクセスする print(f"こんにちは、{self.name}です。{self.age}歳です。") # 設計図(クラス)から実体(インスタンス)を作成 user1 = User("太郎", 25) user1.greet() # 出力: こんにちは、太郎です。25歳です。 このように、関連するデータと振る舞いを1つのカプセルにまとめることで、コードの再利用性や保守性を高めることができます。 PythonとJavaScriptのクラスの「同じ点」 JavaScript(ES6以降)にもclass構文が存在します。どちらもオブジェクト指向プログラミング(OOP)を簡単に実現するための機能として、以下のような共通点を持っています。 設計図から実体を作る概念: どちらもnewキーワード(Pythonではクラス名そのものを関数のように呼ぶだけですが、概念は同じです)を使ってインスタンスを生成します。 初期化とメソッドの定義: インスタンス生成時に呼ばれるコンストラクタと、固有の処理を行うメソッドを定義できます。 継承(Inheritance): 既存のクラスをベースにして、新しいクラスを作ることができます(class Child(Parent): や class Child extends Parent)。 JavaScriptで同じ機能を書いた例: class User { // コンストラクタ constructor(name, age) { this.name = name; this.age = age; } // メソッド greet() { console.log(`こんにちは、${this.name}です。${this.age}歳です。`); } } const user1 = new User("太郎", 25); user1.greet(); // 出力: こんにちは、太郎です。25歳です。 PythonとJavaScriptのクラスの「異なる点」 見た目はよく似ているものの、裏側の仕組みや構文のルールには明確な違いがあります。 ...

2026年3月8日 · 1 分
xxHash(ダブルエックスハッシュ)とは?:超高速なハッシュアルゴリズム

xxHash(ダブルエックスハッシュ)とは?:超高速なハッシュアルゴリズム

xxHash:めちゃくちゃ速い、非暗号学的なハッシュ関数 データ圧縮アルゴリズムの「LZ4」や「Zstandard」を作ったことで知られるYann Collet氏によって開発されました。セキュリティ(暗号化)を目的としない代わりに、コンピュータのメモリ(RAM)の読み込み速度の限界に迫るほどの圧倒的な処理スピードを誇るのが最大の特徴です。 主な特徴 圧倒的なスピード: 数あるハッシュ関数の中でもトップクラスの速度を誇ります。GB(ギガバイト)単位の巨大なデータであっても、一瞬でハッシュ値(データを要約した短い文字列)を計算してくれます。 非暗号学的(セキュリティ用途ではない): 計算が速すぎるため、悪意のある攻撃者がハッシュ値から元のデータを逆算したり、同じハッシュ値になる別のデータを見つけたりすることが比較的容易です。そのため、パスワードの保存や暗号通信には絶対に使用してはいけません。 高い品質(衝突率の低さ): 「速いから適当に計算している」わけではありません。「SMHasher」と呼ばれるハッシュ関数の厳密な品質テストをクリアしており、異なるデータから偶然同じハッシュ値が生まれてしまう「衝突(コリジョン)」が非常に起こりにくい、高品質なアルゴリズムです。 どのような場面で使われるか? その圧倒的なスピードと品質から、セキュリティが求められない「データの整合性チェック」や「高速な検索」の裏側で大活躍しています。 チェックサム(ファイル破損の確認): 大容量のファイルがネットワークの転送中に壊れていないかを確認する際、一瞬でチェックできます。 データベースやキャッシュシステム: データを高速に検索・保存するための「ハッシュテーブル」の内部処理で使われます。 ゲーム開発: 大量のデータをリアルタイムで処理し、1フレームの遅れも許されないゲームエンジンの内部で、アセット(画像や音声データ)の同一性チェックなどに利用されます。 他のハッシュ関数との比較 ハッシュ関数 種類 スピード 主な用途 セキュリティへの利用 xxHash 非暗号学的 爆速 チェックサム、データベース、ゲーム開発 ❌ 不可 MD5 / SHA-1 暗号学的(※現在は非推奨) 遅い 過去のファイル整合性チェックなど ❌ 危険(現在は非推奨) SHA-256 暗号学的 かなり遅い パスワードのハッシュ化、ブロックチェーン、SSL証明書 ⭕️ 必須 用途に合わせて「スピード重視ならxxHash」「セキュリティ重視ならSHA-256など」と使い分けるのが現在のスタンダード!

2026年3月8日 · 1 分
Node.jsのパッケージマネージャ比較:npmとYarnの特徴と違いを徹底解説

Node.jsのパッケージマネージャ比較:npmとYarnの特徴と違いを徹底解説

Node.jsで開発を進める際、外部のライブラリ(パッケージ)を管理するためのツールとして必ず触れることになるのが「パッケージマネージャ」です。今までnpmってなんやろなぁ…と思っていたそこのあなた!パッケージマネージャの代表格であるnpmとYarnは、どちらも同じ目的を持つツールですが、誕生の背景や機能に違いがあるんですよ! npm(Node Package Manager)の特徴 npmは、Node.jsをインストールすると標準で付属してくるデフォルトのパッケージマネージャです。 Node.jsのデファクトスタンダード: 標準ツールであるため、特別なインストール作業なしですぐに使い始めることができます。Web上のチュートリアルやドキュメントもnpmを前提に書かれているものが最も多いです。 巨大なエコシステム: 世界最大級のソフトウェアレジストリ(パッケージの保管庫)を持っています(※Yarnもこのnpmレジストリを利用します)。 近年の劇的な進化: 過去には「インストールが遅い」といった課題がありましたが、バージョン7以降でワークスペース(Monorepo対応)機能が強化され、バージョン8や9と進むにつれてパフォーマンスやセキュリティが大幅に改善されています。 Yarn(Yet Another Resource Negotiator)の特徴 Yarnは、npmが過去に抱えていた「パフォーマンス」や「セキュリティ」、「一貫性」の課題を解決するために、Facebook(現Meta)などのエンジニアによって開発されました。 高速なインストール: パッケージのダウンロードを並行処理で行うため、大規模なプロジェクトであるほどインストールの速さを実感しやすいです。 強力なキャッシュ機能: 一度ダウンロードしたパッケージをローカルにキャッシュし、オフライン環境でもインストールが可能な仕組みを持っています。 先進的な機能(Yarn Berry): バージョン2以降(通称 Yarn Berry)では、重たい node_modules フォルダを生成せずにパッケージを管理する「Plug’n’Play (PnP)」機能や、リポジトリにパッケージ自体を含める「Zero-Installs」といった革新的なアプローチを採用しています。 主な相違点と比較 操作の目的 npm のコマンド Yarn のコマンド パッケージのインストール(初回) npm install yarn install パッケージの追加 npm install <package> yarn add <package> 開発環境専用パッケージの追加 npm install -D <package> yarn add -D <package> パッケージの削除 npm uninstall <package> yarn remove <package> スクリプトの実行 npm run <script> yarn <script> 依存関係のロックファイル package-lock.json ...

2026年3月8日 · 1 分
JavaScriptにおける「===」と「==」の違い:型変換の落とし穴

JavaScriptにおける「===」と「==」の違い:型変換の落とし穴

JavaScriptでプログラミングをしていると、値を比較する際に「===」と「==」の2種類の演算子に遭遇します。これらは見た目は似ていますが、両者がどのような基準で比較を行うのかについては明確な違いが存在します。この記事では、それぞれの挙動と違いについて、具体的なコード例を交えて解説します。 「==」(等価演算子:Loose Equality)とは何か 「==」は、比較する2つの値のデータ型が異なる場合、JavaScriptエンジンが自動的に同じ型になるように変換(暗黙の型変換)してから比較を行います。型が違っていても、実質的な値が同じになるように変換できれば「true」を返します。 具体例: console.log(1 == '1'); // true を返します。文字列の'1'が数値の1に変換されるためです。 console.log(true == 1); // true を返します。真偽値のtrueは数値の1に変換されます。 console.log(null == undefined); // true を返します。JavaScriptの仕様上、これらは等価として扱われます。 console.log([] == false); // true を返します。空の配列は数値の0に、falseも0に変換されるためです。 このように、「==」を使用すると意図しない型変換が背後で行われます。これにより、開発者が直感的に予測しづらい結果を生む可能性があります。 「===」(厳密等価演算子:Strict Equality)とは何か 一方、「===」は、値だけでなくデータ型も完全に一致しているかどうかを判定します。暗黙の型変換は一切行われません。型が異なれば、その時点で即座に「false」を返します。 具体例: console.log(1 === '1'); // false を返します。数値と文字列で型が異なるためです。 console.log(true === 1); // false を返します。真偽値と数値で型が異なります。 console.log(null === undefined); // false を返します。型が異なります。 console.log([] === false); // false を返します。オブジェクト(配列)と真偽値で型が異なります。 型変換を伴わないため、挙動が非常にシンプルになります。結果が予測しやすくなり、予期せぬバグを防ぎやすくなります。 比較結果のまとめ 両者の違いをわかりやすく比較するために、表にまとめます。 比較する値 A 比較する値 B A == B の結果 A === B の結果 ...

2026年3月5日 · 1 分
無限にスクロールできる労苦からuAutoPagerizeで解放された

無限にスクロールできる労苦からuAutoPagerizeで解放された

こんにちは、のなめです。 突然ですが、現代社会を生きる皆さんに質問があります。 インターネット、してますか? 僕は毎日12時間はインターネットをしています。もはやネットの海に浮いているプランクトンと言っても過言ではありません。 そんな僕ですが、ネットサーフィン中に「ある深刻な問題」に直面し、精神が崩壊寸前まで追い込まれました。 それがこれです。 「次へ」ボタン、押すのダルすぎ問題。 検索をして、記事を読んで、一番下まで行って、小さな「次へ」をクリックする……。 この工程、人生で一番無駄なカロリー消費だと思いませんか? 独自の計算したところ、一生で「次へ」を押す回数は約8億回。このままでは僕の人差し指は摩擦熱で発火し、家が燃えます。 「スクロールだけで……ただ指を下に滑らすだけで、次のページが勝手に出てきてほしい……!!」 そんな人類の悲願を叶えるため、今回はある**「禁断の果実(Chrome拡張機能)」**に手を出すことにしました。 救世主の登場 それがこちら。 『uAutoPagerize』~~~~!! (ドラえもんが道具を出す時のイントネーションで再生してください) こいつは一言で言うと、**「ページの下まで行くと、勝手に次のページを継ぎ足してくれる」**という、怠惰の極みのような拡張機能です。 インストールは一瞬。Chromeに追加するだけ。 さっそく、このツールがいかに「神」なのか、実際に使ってみましょう。 実践①:Google検索編 まずは基本の**「Google検索」**です。 通常であれば、1ページ目の10件を見終わったら「次へ」を押さなければなりません。 しかし、uAutoPagerizeを入れた僕のブラウザは一味違います。 ご覧ください。 終わらねぇ~~~~~~!!!! 見てくださいこの継ぎ目のなさ。まるで**「最初から1枚の長い紙でしたけど?」**みたいな顔をして次のページが出てきます。 本来ならクリックが必要だった断絶された世界が、これひとつで**「永遠(エターナル)」**になりました。 情報が滝のように流れてきます。これならマウスホイールで世界の真理に到達できる気がします。 実践②:画像サイト・素材サイト編 続いては、フリー素材サイトや、Pinterestのような画像一覧サイトです。 こういうサイトこそ、「いい画像ないかな~」とザッピングするスピードが命。 速い……! 速すぎる!! もはや自分の動体視力がスクロールに追いついていません。 「次へ」を押して画面が切り替わるあの**「0.5秒のロード時間」**すらも抹殺されています。 「クリック」という概念が消滅しました。 今の僕の辞書には「スクロール」しか載っていません。 革命の代償(注意点) あまりにも便利すぎて、気付いたら3時間くらい無心でスクロールしていました。 恐ろしい子……! ただ、一つだけ注意点があります。 サイトの一番下(フッター)が見たくても、永遠に逃げられます。 「フッターが見たいのに、新しいページが無限に湧いてきて辿り着けない!」という地獄のアキレスと亀状態になります。 そういう時は、アイコンをクリックして一時停止しましょう。これテストに出ます。 まとめ いかがでしたでしょうか。 『uAutoPagerize』。 それは、我々を「クリック」という労働から解放し、無限のスクロール地獄へと誘う悪魔的ツールでした。 皆さんも是非導入して、腱鞘炎のリスクを回避しつつ、情報の濁流に飲み込まれてみてはいかがでしょうか。 僕はこれから、スクロールのしすぎで筋肉痛になった人差し指を冷やすので、今日はこの辺で失礼します。 それでは。

2026年1月7日 · 1 分
書評:読者は必ず欺かれる。殊能将之『ハサミ男』が仕掛けた二重三重の罠(ネタバレ有り)

書評:読者は必ず欺かれる。殊能将之『ハサミ男』が仕掛けた二重三重の罠(ネタバレ有り)

導入:殺人鬼 vs 模倣犯という奇妙な幕開け もし、自分が狙っていた獲物を、自分の殺害方法をそっくり真似た「模倣犯」に先に殺されてしまったとしたら? 殊能将之の『ハサミ男』は、既に二人殺害しているシリアルキラーである主人公が、自身の第三の犠牲者となるはずだった人物の無残な死体を「第一発見者」として見つける、という極めてユニークな導入から幕を開ける。 この「殺人鬼が模倣犯を追う」という倒錯したプロットだけでも一級品だが、本作の真価は、大胆な「叙述トリック」にある。 第一の罠:「ハサミ男」は本当に「男」なのか? 本作最大のトリックは、タイトルにもなっている「ハサミ男」という呼称そのものにある。 作中でマスコミによって名付けられたこの呼び名は、読者に対して「犯人は男性である」という強力な先入観を植え付ける。さらに、物語では男性の容疑者も登場し、我々の疑いをそちらへ誘導する。 だが、これこそが罠だ。 真犯人は、実は女性、安永知夏である。彼女は賢く、美貌にも恵まれている。そんな彼女が、猟奇的な殺人衝動を抱えている。この「美人は疑われにくい」という社会的なバイアスを作者はトリックの装置として利用している。 第二の罠:二人の「わたし」と、二人の「遺体発見者」 本作の巧妙さは、真犯人の性別を隠したことだけにとどまらない。 物語は「わたし」という一人称で語られるが、読者がメインの語り手として追っていく「わたし」は、日高という男性である。彼は自殺願望を抱え、デブで、そして「ハサミ男」の模倣犯として描かれる。読者は当然のように「わたし=日高=ハサミ男(真犯人)」だと誤解するように仕向けられる。 しかし、物語にはもう一人の「わたし」が存在する。それこそが、真犯人である知夏だ。 知夏もまた、日高と同じ現場の「遺体発見者」なのである。 つまり、二人は同じ場所で、別々に遺体を発見している。だが、読者は巧妙な視点の切り替えによって、遺体発見者が「わたし」という一人称で語る同一人物(日高)であるかのように錯覚させられる。どちらも同じような話し方をする為、読者は遺体発見者の「わたし」が一人だと誤認する。 例えば、二人には「太っている」という共通点があるが、日高が「かなりのデブ」であるのに対し、知夏は「美人と評されるレベルのふくよかさ」である。同じ言葉でも指し示す状態が微妙にズレている点や、読み返してこそ気づく仕掛けが満載だ。 結末:知性か、あるいは悪運か 最終的に、真犯人である知夏は捕まらない。 彼女は利発そうで殺したくなりそうな次のターゲットを見つけ、物語は幕を閉じる。この結末は、読者に強烈な印象を残す。 『ハサミ男』は、叙述トリックというミステリの技法を極限まで磨き上げ、読者の常識と先入観を徹底的に弄ぶ。読み終えた時、あなたは「してやられた」という悔しさと興奮を同時に味わうことになるだろう。 おまけ よければこちらの記事もご覧ください。 自由意志は幻か? テッド・チャン『What’s Expected of Us』と科学が突きつける問い ゼロ・グラビティを観た ── 無重力に放り出されることの怖さ 自由意志は幻か? テッド・チャン『What’s Expected of Us』と科学が突きつける問い 2001年宇宙の旅は本当に「つまらない」のか ── 序盤は面白かった、という個人的な感想 あなたの体はあなただけのものじゃないのか?意識は孰れ要らなくなるのか?<harmony/>伊藤計劃 感想と解説 万年筆、青酸カリ、遺体リレー。トリック解説「ブルータスの心臓」東野圭吾作 法曹の卵×女子大生が描く事件簿.日常法律系ミステリ, 無料法律相談が導く結末 「六法推理」五十嵐 律人作

2025年11月16日 · 1 分
Pythonのif文for文while文の使い方と違い

Pythonのif文for文while文の使い方と違い

Pythonにおける「if」「for」「while」は其々何をするものなのか if :条件によって実行するコードを実行しないコードを分ける for:リストや文字列などの要素を順番にひとつずつ処理する。 while:条件が真である間ずっと同じ処理を繰り返す if文 条件分岐を行う構文。条件が真か偽かをチェックし真なら真のときのコードを、偽なら偽のときのコードを実行してくれる。 if condition: # 条件が真のとき elif other_condition: # それ以外でこちらが真 else: # 上のどれでもないとき いつif文を使うのか 入力値や状態に応じて処理パターンを切り替えたいとき 例:点数によって評価を変える、メニュー番号で処理を分岐。 エラー条件や例外的ケースを先に弾きたいとき。 複数条件を組み合わせて「どれを優先するか」を決めたいとき。 For文 w3schoolsの定義によると… A for loop is used for iterating over a sequence (that is either a list, a tuple, a dictionary, a set, or a string). This is less like the for keyword in other programming languages, and works more like an iterator method as found in other object-orientated programming languages. ...

2025年11月8日 · 2 分