  |
はてなキーワード: KEYとは
絶望先生見てたしまほろまてぃっくも見たし、歌物語のOPED良かったし～で、行くことに
QRコード注文とかもだけど、やたらアプリをインストールさせる風潮好きじゃないんだよね。こっちにコスト押し付けてる感じで…
しかも、Googleアプリストアがクレカ情報入力しろと。こういうとこから流出するのよな…と思いつつ入力。アプリの出来はいいけど、こういうのってスマホの電池切れたら…とか心配しちゃう。
で、最初は土曜に行く予定だったが昼の予約が全滅。なぜか日曜の昼はガラガラだったのでそっちで予約。
調べたら40周年の時も日時指定だったからしいが、その時は名古屋大阪でもやってたのにィ～
で、土曜日。中古屋行ったらまほろまてぃっく二期DVDBOX八百円。幸先良いじゃんと喜んでたら仕事の連絡。
なんか業務上の大事故が起きたみたい(他人事)本来なら明日客先に出向いて対応すべき重大インシデントだよね～。神様がシャフト展に行くなと言ってるのでは？仕事優先することで事故を回避みたいな…まぁ、起きたことはしょうがないし連休明けに対応することになる。
で、今日。無事に5時半起床で新幹線にも間に合う。場所調べてたら、会場のビルはシャフト展が終わったら取り壊すと知る。場所やら日程はそういうことかと納得。
押井気取って駅の立ち食いそばに行くが、味はともかく、丼を渡すスペースと食券置くスペースせますぎ(店員一人分)セルフ給水や七味も近くに置いてあるから、注文して待機中のオッサンや丼を受け取ったオッサンが入り乱れて動線メチャクチャ、店の仕事しやすさだけで配置してる感…2人で回してるみたいだし仕方ないかもしれんが、もっとこうシステマチックにさぁ…と、憤慨しながらサンシャイン通りへ。
池袋全体が大混雑で歩くだけでも時間を食う。スマホを見せると4階に行くように言われるが、階段に人が並んでいるので最後尾で待機。単にオタクがたむろしてるだけじゃないよな？と不安になっていると、スタッフさんから、整理番号の段へ行くように、と声をかけられる。
階段を登ってると知らないイケメンオタクに「何番ですか？」と尋ねられる。番号を見せると、「その番号ならもっと先ですよ。」と言われる。「はぁ、そうですか」と返すブサイクオタク(俺)礼を言え礼を。
番号の階段に付くが、列も動いてるのでどうすればいいかわからず、流れで入場。
撮影場所とかパネルとか。混雑してる。オオ、まほろまてぃっくの原画とコンテだ！角のとこにあるからメチャクチャ見辛いけど…
ぱにぽにとか、まあ年代順に展示してる感じ。絶望先生のコーナーを主に見るが人が多くて大変。次のスペースはカーテンで区切られてて逆流できないっぽい？まどかの部屋で次が物語だったと思う。撮影可のとこがあったり、ウエダハジメのパネルとかあったけど、飛ばし見してたからちゃんと覚えてない。まどかはリアルタイムでハマってたけどwiki見ててこれってマーケティング…って思ったら冷めちゃったんだよな。エレベーターで別の階に行って階段を登る。階段に作品ポスターが飾ってあり、その後もなんか色々展示がある。ヴァージンパンク！そーいやシャフトだったな…しかし展示がまどかの上映スペースの隅にあって少し見にくい。
で、公式MADみたいなの流してる部屋兼通路があり、とりあえず最後まで見るか…と一人見てると人が通って気まずい。通行の邪魔だから前方で見るよう言われちゃったりして。
で、梅津とか久米田の50周年サインとかメッセージが飾ってあっておわり。20分くらいで見終わるが、これはほとんどスルーしたから。ちゃんと見てたら数時間かかると思う。
地下二階がグッズとのこと。チケットのチェックあり、カタログと購入用紙を渡され、実物コーナーを通り、MVとか流れてる劇場兼物販スペースみたいなとこに行く。図録がないか聞いてる人がいたが、過去の展覧会の図録がネットで買えるのでそちらで、ということらしい。注文ペンがあったみたいだが渡されてないんだか取り忘れたのか。自前のペンで書いて待機。列を崩しちゃならんのだかわからず、書いた後も待機。してたら書けた人から前にいくみたい。ペンも回収しますと言われ、なかったので自分のを…と伝える(ないならスタッフに言わないと後で面倒になる)
絶望先生の顔面原画ポストカード(少女達の集合シーンとか、もっといいのあっただろ、と思いながら)まほろまてぃっくの原画ポストカード(まほろの表情集。こっちはよい)を買う。10分くらい。全部で半時間。
１時間半ほど見込んでたので時間が余る。が、まさかの池袋駅までの道で迷う。うろついてたら、なんか無料でおジャ魔女とデジモンの展覧会やってて、撮影も可らしい。原画とかもあって結構ちゃんとしていた。
秋葉原でkeyの25周年のTCGパックを買う。今度買おうと思ってスルーしたらどこも売り切れになっちゃってて、でもあるとこにはあるんだな～。ボックスしかないけど。まあ仕方ない。
シュウマイ弁当買って新幹線で食う。中にお菓子が入ってます、と言われ、干しアンズの他にお菓子が？と思ったが、今思えばお箸か。色々と、弁当の完成形って感じでよい。タケノコが一番美味い気がする。
で
シャフト展行ってわかったんだけど、自分は信者というよりアンチなんだよな。あと、富野展とか庵野展とはやっぱ違った。まあこっちは周年イベントだからそらそうだけど。前者は老若男女ファミリーいたけどこっちは若い男女ばっかで、作画資料とかじゃなくコンテンツ紹介みたいな(そういえば、デジタル作画だからセル画とかはないんだよな～)
悪くはなかったけど、シャフト君そういうとこあるよね！って悪いとこも滲み出てた感じ
そういうアカンとこが噴出したのが打ち上げ花火じゃねえかと思うんよな
上手いこと噛み合ってたのが絶望先生
This might be the most hilarious project ever .
Well, this is said to be Kidzania , but it's just a large scale play house.
At first I was a bit skeptical about whether it would be fun, but since there are a lot of fun roleplaying games out there, it's become a really addictive project .
Girls love to act out daytime dramas while playing house .
Key Person
・Polka writes about what's happening in real time , and he's mysteriously good at writing.
・Fubuki, the gambling -loving rip-off doctor
・Miko, the organizer who works behind the scenes to mass-produce
・Marin, the cabaret club manager who is in her perfect job
・The Mio family begins a daytime drama
Even though I haven't seen the gang side, the characters are strong enough to be made into a manga .
To begin with, I 've done a lot of roleplaying in Minecraft .
I think it would be most interesting to throw these guys into a world like a TRPG . GTA has more of that kind of RP feel than Minecraft or ARK , so it feels like the flavor is exploding.
There are dozens of frames, so it will probably take until winter just to look at the clippings.
[] https://tensor.art/articles/913271679902311502
[] https://tensor.art/articles/913271892503191947
[] https://tensor.art/articles/913273855303258429
[] https://tensor.art/articles/913274016364543556
Actually, Yu-Gi- Oh! was originally intended to be a puzzle , or rather, a toy , like the Millennium Puzzle ...
But I think it's clear that what made Yu-Gi-Oh successful was the trading cards ... 😟
I think the key to its success is that it didn't set out to be a manga about puzzles right from the start .
In other words , without deciding on a specific direction for the story from the beginning , there are only characters and a vague ,
Also, incorporating the latest topics at the time, and a loose, tightrope- walking kind of manga might be better suited to serialization.
Also, inflationary battle manga , where ever stronger enemies appear , can go on forever .
Just when you think the universe will be destroyed and the end will come , a new Big Bang occurs and another world is created .
New characters will be available, and it should be possible to revamp Motorhead beyond just Gothic Maid ...
[] https://tensor.art/articles/913233772520973617
[] https://tensor.art/articles/913234002301712769
[] https://tensor.art/articles/913235196302629702
[] https://tensor.art/articles/913235376691257452
というわけでお漏らし文学をChatGPTに調べてもらった
Last time I paid 1€ to take a piss,
I walked into the Sanifair, looked around,
and just… left.
It was so disgusting I decided to go outside and search for a bush instead.
— Reddit / r/AskAGerman
「1ユーロ払ってトイレに入ったんだけど、あまりに汚すぎてそのまま出てきた。結局、外の藪を探すことにした。」
ドイツ人ですら「お金払って藪で用を足す方がマシ」と言ってしまう悲哀。
URL：れでぃっと r/AskAGerman
I used to squat when using public toilets.
Then one day, I slipped.
That day, something inside me died… and something outside me was never clean again.
— れでぃっと / r/AskEurope
でもある日、足が滑った。
その日、僕の中の何かが死んだ… そして僕の外側も、二度と綺麗にはならなかった。」
もう「しゃがむ」という選択肢すら許されない。
In Belgium, there’s an unwritten rule.
You hand the bar owner a euro,
he silently hands you the bathroom key.
you find a dark corner of the street instead.
— Blog post “The art of le pee in Belgium”
バーの店主に1ユーロ渡すと、無言でトイレの鍵を渡してくれる。
観光都市ブリュッセルでも、路上で立ち尽くす影が絶えない理由。
URL：saintfacetious.com
All cafés were closed, all public toilets locked.
I stumbled along the riverbank,
In the end, the Seine saw everything.
— れでぃっと / r/Paris
「深夜1時、セーヌ川沿い。
ワインと後悔で酔った体を引きずりながら歩き、
パリの夜は美しく、そして容赦ない。
観光客だけでなく、現地の人すらこうなることがある。
I was in Bilbao, desperate to pee before the match.
I ran into one of those self-cleaning toilets…
and then the cleaning cycle started
僕は全身びしょ濡れになって出てきた。」
水と泡まみれで出てきたマンチェスター・ユナイテッドファン。
In Amsterdam, we had these half-open urinals called ‘pee curls.’
They were meant to stop men from peeing in the canals.
Now they’re disappearing…
and the canals smell like history again.
「アムステルダムには、半分だけ壁のある露天トイレ『pee curl』があった。
でも今はそのpee curlも減り、
I have MS.
Since the public toilets closed,
Last month, I didn’t make it home in time.
I cried, then laughed, then stayed inside for a week.
— The Guardian 読者投稿
「私は多発性硬化症です。
先月、家に帰る前に間に合わなくて…
URL：The Guardian
まあまあだな、また探す
＿＿＿＿
確かに使ってた。使ってはいるけど解凍を使ってるのは自己解凍のところだけで、e,xオプションのところでは「ファイルを取り出す」表記。凍結表記もaオプションのところだけ。
(LHAになる前のバージョンだけど)LHarcソースコード内の日本語版の使い方
char use[] =
"LHarc version 1.13c Copyright(c) H.Yoshizaki（吉崎栄泰）, 1988-89.\n"
"============================================================= 1989 - 5 - 21 ===\n"
" <<< 高圧縮書庫管理プログラム >>>\n"
"===============================================================================\n"
" 使用法：LHarc [<命令>] [{/|-}{<スイッチ>[-|+|2|<オプション>]}...] <書庫名>\n"
" [<ドライブ名>:|<基準ディレクトリ名>\\] [<パス名> ...]\n"
"-------------------------------------------------------------------------------\n"
" 《命令》\n"
" a: 書庫にファイルを追加 u: 書庫にファイルを追加（日時照合付）\n"
" f: 書庫のファイルを更新 m: 書庫にファイルを移動（日時照合付）\n"
" d: 書庫内のファイルの削除 e,x: 書庫からファイルを取り出す\n"
" p: 書庫内のファイルの閲覧 l,v: 書庫の一覧表示\n"
" s: 自己解凍書庫の作成 t: 書庫内のファイルの CRC チェック\n"
" 《スイッチ》\n"
" r: 再帰的収集を行う w: ワークディレクトリの指定\n"
" x: ディレクトリ名を有効にする m: 問い合わせを行わない\n"
" p: 名前の比較を厳密に行う c: 日時照合を行わない\n"
" a: 全属性を凍結の対象とする v: 他のユーティリティでファイルを閲覧\n"
" n: 経過表示をしない k: 自動実行のキーワードの設定\n"
"===============================================================================\n"
" 転載・再配布などは自由です。 Nifty-Serve PFF00253\n"
英語版の使い方
char use[] =
"LHarc version 1.13c Copyright (c) Haruyasu Yoshizaki, 1988-89.\n"
"================================================================ 05/21/89 ===\n"
" <<< High-Performance File-Compression Program >>>\n"
"===============================================================================\n"
"usage: LHarc [<command>] [{{/|-}{<switch>[-|+|2|<option>]}}...] <archive_name>\n"
" [{<drive_name>:}|{<home_directory_name>\\}] [<path_name> ...]\n"
"-------------------------------------------------------------------------------\n"
" a: Add files to archive u: Update files to archive\n"
" f: Freshen files in archive m: Move new files into archive\n"
" d: Delete files from archive e,x: EXtract files from archive\n"
" p: disPlay files in archive l,v: View List of files in archive\n"
" s: make a Self-extracting archive t: Test integrity of archive\n"
" r: Recursively collect files w: assign Work directory\n"
" x: allow eXtended file names m: no Message for query\n"
" p: distinguish full Path names c: skip time-stamp Check\n"
" a: allow any Attributes of files v: View files by another utility\n"
" n: display No indicator k: Key word for AUTOLARC.BAT\n"
" t: archive's Time-stamp option\n"
"===============================================================================\n"
" You may copy or distribute without any donation to me. Nifty-Serve PFF00253\n"
" (See the User's Manual for detailed descriptions.) ASCII-pcs pcs02846";
それは間違い。
FeliCa Lite-Sでは、色んな場面（主に3種類？）で3DES演算をしているが、ICカードを使う度に128ビットのカード鍵と128ビットのチャレンジから2-key 3DES演算して56ビットのセッション鍵2つを生成しているし、その後は生成した2つのセッション鍵を使って2-key 3DES演算してMACを生成している。
なので、ICカードに書かれている128ビットのカード鍵が漏れると、不正なカードリーダー・ライターでデータを改ざんされる可能性がある。
1. マスター鍵から個別化カード鍵を生成する時 → Qiita記事のセクション「カード鍵の書き込み」の関数generate_CK ※標準生成アルゴリズムは推奨で必須ではない
2. カード鍵からセッション鍵を生成する時 → Qiita記事のセクション「セッション鍵の生成」の「triple_des(CK[7::-1] + CK[:7:-1], ……」の所
3. 送受信するデータのMACを計算する時等 → Qiita記事のセクション「MAC_Aの生成とカード判定」の関数_generate_mac
マスター鍵は、（Qiitaの記事では）192ビット（24バイト）、カード鍵は128ビット（16バイト）、セッション鍵は56ビット（7バイト）×2つ。
まだ信じてるジジイ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250901181912# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaLVlEgAKCRBwMdsubs4+ SFMrAQC5k3cd6iXF8e/eXKxDk6y1pzy5cKwQcfEdGoZaDC+G3wEA86haEbFDY+4h KEY/XzV2QK3By7jgVRA60VitCt20Pw0= =ewr2 -----END PGP SIGNATURE-----
The Power of Small Steps: How Tiny Changes Can Lead to Massive Growth
In a world that glorifies overnight success and dramatic transformations, it's easy to feel like you’re falling behind if you’re not making big leaps. But what if the secret to real, lasting personal growth wasn’t in doing more, faster—but in doing less, consistently?
Welcome to the power of small steps.
Big goals often feel overwhelming. You want to get fit, write a book, start a business, or learn a new skill—but you don’t know where to start. So you procrastinate. Or worse, you dive in too fast, burn out, and give up.
Small steps bypass all of that.
When you break down a huge goal into manageable actions, everything changes. Writing 500 words a day is less intimidating than finishing a whole novel. Ten minutes of walking is more doable than committing to a 5K. And spending 15 minutes a day learning a language adds up to over 90 hours a year.
Consistency beats intensity every time.
The Compound Effect
Imagine improving just 1% every day. That might sound insignificant—but over a year, it compounds into something extraordinary. This idea is the foundation of Darren Hardy’s The Compound Effect and James Clear’s Atomic Habits. Both books emphasize that small, smart choices, repeated over time, lead to radical results.
Think of your habits like planting seeds. At first, nothing seems to happen. But give it time, and you’ll see growth you never thought possible.
Real-Life Example: The 10-Minute Rule
Let’s say you want to start meditating but can’t sit still for 30 minutes. Instead of forcing it, try meditating for just 10 minutes a day. Or even 5. Build the habit before scaling the effort. Once it becomes part of your routine, extending the time feels natural.
This applies to nearly everything:
Want to read more? Read one page a day.
Want to save money? Start with $1 a day.
Want to eat healthier? Swap one snack a day for a better option.
How to Start Taking Small Steps
Pick one goal
Don’t try to overhaul your entire life at once. Choose one area to focus on—health, creativity, relationships, mindset, etc.
Break it down
What’s the smallest possible action you could take toward that goal? Make it so easy you can’t say no.
Link your new habit to an existing one. For example: “After I brush my teeth, I’ll journal for 5 minutes.”
Track it
Use a habit tracker, app, or notebook to keep yourself accountable. Seeing your streak grow is highly motivating.
Every time you follow through, give yourself credit. Progress is progress, no matter how small.
Final Thoughts
Don’t wait for motivation. Don’t wait for the perfect time. Just start—with whatever you have, wherever you are, and however small.
Because small steps, taken consistently, turn into big change.
①「国または知識はこれでよろしいですか？」の画面から「Moicrosoftアカウントを追加しましょう」の画面の間に「Shift」キーと「F3」キーと「Alt」キーを押す。するとコマンドプロンプトが表示されるので、そのウィンドウを「Alt」キーを押しながらマウスでクリックしてアクティブにする。
②「start ms-cxh-for-key-b:localonly」と入力して「Enter」キーを押す。Moicrofoftアカウントを作るためのウィンドウが表示されるので、任意のユーザー名とパスワードを入力して「次へ」を押す。
セットアップ終了後、
③スタートメニューなどから検索して「グループ ポリシーの編集」を起動(事前にBitRockerはオフにしておく)
④左のツリーから「コンピューターの構成」→「管理用テンプレート」→「Wandows コンポーネント」→「BitRocker ドライブ暗号化」→「オペレーティング システムのドライブ」を選び、右側のリストで「ネイティブのUEFIファームウェア構成……」の項目をダブルクリック
今まで、たくさんの設定ファイルが考案されてきた。
.ini レジストリ xml lua json yaml ..etc...
どれも一長一短だった。
例えば.iniはコメントもかけるし、シンプルなkey=value形式だった。だがしかしarrayを表現できなかった。
レジストリはarrayを表現できたがすべての設定を集約したため巨大な密林になった。
xmlは冗長なフォーマットになり、書き手とパーサーの負担が増えた。
スクリプト言語のluaやjsを設定ファイルに使おうぜという動きもあったが、セキュリティリスクもあり普及しなかった。
yamlはコメントはかけるが、これはこれで面倒な形式であり欠点ある。
いろいろ考えた末に俺様がたどり着いたのは、設定ファイルという概念の消滅だ。
設定のスキーマーを定義する共通言語で記述するか、またはYAMLでもなんでもいいから強力なディファクトスタンダートができる。
利用者はやりたいことを"自然言語"でAIに要求し、AIはそれを実現するために設定ファイルを解析し書き換える。
もうちょっと明るくできないかなあ。タスクバーをもうちょい右とか、そういう要求を自然言語で出す。
AIはプレビューを出して、こんなんどうすかと提示したり、やっぱり前の方がよかったなあというわがままなユーザーのリクエストに応じて、バックアップから復元したりと柔軟に対処する。
これにより、設定ファイルは機械が書き換えるものになり、人間が書き換えることがなくなるというのが、未来のあるべき姿だと思う。
転生もの。事故にあったら天使に会って転生先でスローライフを望む。
全12話。えぇ、ここで終わりなの。この（遅い）スピード感なら連続2クールくらいあるものだと思ってた。
ルンルが話すようになってさらに可愛くなった。
姿形が変わったらそれはもう別物？新しく新調されたら前のはどうなるの？
だって、自分の中に生まれたコタロー像を現実のコタローに入れて、
そうやって頭の中で作り上げた理想の世界でコタローと遊んでたってことですよね！？』
この辺のセリフ好き。今までへらへら見てたけど、いつの間にか結構真顔で見てた。
ハーレム系。女の子に酷く振り回される感じなので、理解のある男友達の徳井が癒し
藤岡先輩やべぇ奴だな。
周りが可愛い子だらけとはいえ、性格や立場が特殊すぎてしんどいなー。全然うらやましくない。
石原さんと付き合うことができた。今度は幼馴染である紗月の実家が明らかになる。
人気動画配信者が昏睡状態、発狂状態になっていると噂の中、主人公ミコたち動画配信者（ライバー）はVRゲームイベントに参加する。
しかしそれは邪神が人類滅亡を目論むによる恐ろしいゲームだった。邪神による悪魔のデスゲームが始まる。
よく分からないんだけど一部の人が消え、消えた人が魔獣化してたり。
やっぱりよく分からないんだけど世界が崩壊に近づいてそうなんだけど、歌の力で救っていく感じ？
神椿を追ってないと理解が難しそう。0~2話まで見たけどもういいかな。
戻ってきたのはきたのだが・・・何か表現できないような違和感が・・「お前、ヒカルちゃうやろ？」
なんだこれは。なんなんだこれは
世界の不気味さ、人と人との距離感、気持ち悪さがよく表現できていると思う。
ブロマンスなところがあるのでBLが嫌いな人とか、人を選ぶかもしれないが閉鎖的かつ、この言葉では表現しづらい異様な世界だから妙にマッチしている感じもある。
面白いかは別として（私は面白いと思うが、そうでない人に対しても）見ていて欲しい作品ではある。
見た目が真逆な二人。どちらもクラスメートから距離があり学校では孤独な感じなんだけどー
そんな二人がフードコートでひたすら日常会話をする感じ。なのでちょっと退屈かも。
舞台はイオンモール名取か。実際のKFCやサーティワン、ヴィレバンが登場する。
自分は2話でなんとなく見方が分かった気がする。スルメ系ですね。見ていくうちに面白さが分かっていくやつ。
次からはアンコール放送。振り返り放送1回目だけはオーディオコメンタリーがある。
あとEDのイントロ部分のセリフが違う。これまで6話全て同じセリフ（だからさぁ、今時音楽にイントロなんている？〜）
だったのが、アンコール放送では毎回違う。その回の話にちなんだセリフになってる。
前のシーズンから引き続き。私が苦手とするKeyのゲームが原作。
今のところは蒼の話が一番好きかな。
15話でOPの映像が少し変わった？と思ったら以前からちょいちょい変わってたのね。
25話で一応話がすっきりした。子が親の幸せを願っての行動。
全26話。最終話CMなしで27分だった。あと30秒〜1分くらい余韻が欲しかったかも。
"大学生の真木と八重子はある夜、上空から落ちてきた広辞苑に頭をぶつけて大怪我をした男・モグラと出会う"（wikipedia引用）
この真木と八重子がいい人すぎる。
よけいなおしゃべりが多いが、そこがまたいいね。
バケモノの話もありながら人間の心理思想の話もあったりして、結局は人次第だよねと感じるところもある。
全12話。最後にモグラが何者なのか語られる。面白かった。2期やって欲しい。
百合アニメ。キャラ原案がささ恋の作者なので既視感があるよね。
いいですね！ささ恋とはうってかわって綺麗な作画で百合ハーレム。
百合とか関係なくこの年頃の恋愛事情は暴走するものですからね、気持ちがあふれる表現とかそういうの好き
言いたいこと言えなかったり、逆に言ったり、変な行動したり暴走したり。まぁアニメではよくあることなんだけど表現が好きだった。
全12話。え
まさかの続編13話〜17話の全5話制作・放送が決定。放送に先駆け劇場上映も。
今まで実は主人公ロイドが縁の下の力持ちで助けていたのを気づかず勇者くん
「俺は強いからお前いらない」 とロイドを追放しちゃう典型的なやつ。
こういうのって追放する方も悪いけど、主人公側のコミュニケーション不足も原因よね。
その主人公は無自覚に無双できそうなくらい実力はあるのに自己肯定感の低い人。
と、テンプレすぎて不満がありそうに書いたけれど、そこまで鼻につくようには感じられなかったから継続してみると思う。
ハーレムパーティじゃないのもいいね。と思ったのも最初の数話かな。ちょっと退屈かも。これなら強くてニューサーガの方が少しはいいかな。
全12話。最後「終」って出るのは意外と珍しい気がする。続きはないんだろうな。
2025年冬アニメからの続き、4期2クール目にあたる。今回は主要キャラが悲しいことになる、結構なお話。
22話、23話は涙なしには見れない。あーもうこの23話で気持ちが全部持ってかれた。元々好きだったけどさらに好きになったよ
EDのイントロ部分のモールス信号、歌詞、超絶100億%あってる。音羽-otoha- 「no man's world」これ聴くだけで泣いちゃう
｢応答して、no man's world｣ 「応答して」 の音は 「Oh, どうして:Why」とも聞こえるよう歌詞をチョイスした？わざと？
ボウリング部の部内ではエンジョイ勢とガチ勢の対立でギスギス状態に。
部長の麻衣と本気でボウリングをやりたい利奈のボウリング一騎打ち対決。
そのときふしぎな事が起こった。
目覚めたらそこは戦国時代。は？
その後ボウリングしたりボーリングもしたりして、戦乱の世で自分たちや世話になってる戸倉家を守ろうと奮闘する物語。
6話はなかなか、命の話でも性の話でも血を感じるお話だったし、8月を感じさせるお話だった。
9話のOP/EDは特殊。OPはメンバーが現代組（長野県一刻館高校ボウリング部）から戸倉家の姫たちへと入れ替わり、EDもやなぎなぎの曲に。
全12話。まさかの侍タイムスリッパーならぬ、姫様タイムスリッパーだった。帰り方あれでええんか。
それぞれの家庭の話をもう少しやって欲しかった。少し話には出てたけど興味深かったので。けど時間ないよね。
一つ屋根の下で女の子と同居してハーレム状態の中、お世話をしたりされたりするよくあるやつ
母親が天才大女優ということで周りが勝手に期待するが、顔がいいだけの中身は凡人。
母が亡くなり、引き取られた家「帝乃家」は学園の三帝と呼ばれる才女三姉妹が住む家だった。ということで三姉妹と同居し、周りの世話をすることに。
三姉妹は皆自由勝手に見えるが、各々自分の武芸にあわせた必要ルーティーンをこなしている。
そんな3姉妹のことを理解しながら、憧れの "食卓を家族で囲む" ことはできるのだろうか。
可愛いげのない3姉妹が何気ないことで可愛くなる変化は楽しい。
ネットの情報を基に午前2時、不思議な儀式をすることで異世界転生。
初期値にルックスを低く設定、女性と疎遠になりそうな設定にすると、なんとボーナス割り振りポイントが爆上がりに。
この転生の仕方とボーナスパラメーターの割り振りは珍しいかも。
転生先では同じ方法で転生してきた（元）日本人とパーティーを組んで冒険をする。
メタボな少年貴族が主人公。前世では料理や裁縫を得意としたオトメンだったのだが、夏コミの帰りに熱中症で死んだらしい。みんなも気をつけようね。
両親には見放されてしまったが、前世で知っている歌を歌って女神と仲良くなったり、料理・裁縫スキルを活用して腹違いの弟と育てながら領家を運営していくって話かな。
文明の発程している前世の記憶があるので、周りとの交流や弟の育成の寄与することになるのだが、
その記憶を思い出しながら脳をフル回転して、こちらの世界の人に対し熱弁すると知恵熱が出てしばらく寝込んでしまうというデメリットもある。
全12話。よかった、起業することになった。最後にいつもの「野中のばら」を歌って終了。続きやってくれないかな。
3年ぶりの2期。許嫁が取り違え子だった！？
そんな複雑な関係の許嫁、片思いしている女の子、実は血が繋がっていないと分かった妹との恋の4角関係。
そこに今期ではもう1人幼馴染が加わり、5角関係へと進展するのであった。
EDは22/7、ナナニジメンバーは4羽目で祭りの観客役としても参加している。
全12話。いつもの調子で終わった。さて、この続きはいつあるのやら。
病床でゲームして寝落ちした感じで死んだと思ったら異世界に転生？転移？してた。
そこで出迎えてくれた大好きなゲームのキャラクターと共に、邪悪な国家マイノグーラの邪神として活動する。
自分とゲームのキャラクターが全く別の異世界へ一緒に飛ばされた？
OPは佐々木李子でこの曲調なので、もはやAve Mujicaみたいな感じ。
5話の容赦なさがいい。やる時もやられる時も出来るだけ残酷なシーンに描くのが好き。
シミュレーション世界とRPG世界、異なるジャンルのキャラクターが闘うというのが面白いね。
9話で英雄イスラが登場し双子ダークエルフが懐くのだが・・・なるほど、EDはこういうことだったのか。
全13話。予想外に面白かった。
1年半ぶりくらい？3期も見たと思うんだけれど全然覚えてない・・・・
クテンロウ編。ラフタリアの命を守るためクテンロウと話をつけてくる。
と、そこへ行く船を調達するため、亜人たちがたくさんいるシルトヴェルトで一悶着。
フォウルくんも成長した。船をゲットしてクテンロウへ。
悪政の元凶も倒してラフタリアさん天命へ。全12話。Season 5 決定。とことんやるだろうな
生まれ変わって太ももむっちり可愛い男の子が魔術を極めんとするやつ。1年ぶりの2期。
1期の敵が仲間になった後、2期ではモブっぽく扱われず、割と前線で活躍してくれる流れ好き。あとジェイドの存在が相変わらず大きいの好き。
女同士敵同士なんだけど勇者気絶中に何だかんだで仲良くなる感じ？結構好きかも。
アカペラ部の活動の話。そういえばもうすぐハモネプの時期でもありますね。
嬉歌のネガティブ精神と情緒不安定ぶりはヤバいな。結の言葉はキツイけど嬉歌の性格がコレなのでスッキリするわ。
アニメ化は今回からだけどプロジェクトは3年前からあったらしい。
全10話。結構良かった。最終話を見ると主題歌の「思い出話」の歌詞が身に染みる。
キャラクターではクマちゃんが好き。これまで声の所為で人とのコミュニケーションを取ってなかったけど、人一倍人の気持ちを理解できるいい子だった。
893の狂児は、組長に刺青を彫られるのが嫌で中学生で合唱部部長をやっている聡実に歌を教えてほしいとお願いをする。
全5話。4話で一旦終わって、次からこの時間は同作者の短編漫画「夢中さ、きみに。」をアニメ化したものが放送される。
5話は「夢中さ、きみに。」が終わってからの放送。4話の中で空白だった時間を埋める話。
かわいいとは程遠い中高一貫男子校、どこかミステリアスな林美良を中心に繰り広げられる青春ストーリー。
3年前に公開されたミルキー☆ハイウェイの続編で、スピード違反＆公務執行妨害＆警察車両爆破で捕まった後の話。
社会奉仕活動としてミルキーサブウェイと呼ばれてる鉄道車両を清掃することになったのだが・・・・。1話あたり3分半と短い。
面白いんだけど、面白さを説明するより3分だからとりあえず見て！となるやつ。
未来的な世界だけどどこかレトロな感じもある。主題歌はキャンディーズの銀河系まで飛んで行け！この曲って吉田拓郎節満載だよね。
高校生みたいにノリだけで行動してる感じ、あとプレスコなのか？と思うくらいセリフの抑揚やテンポが生っぽい感じが自然体でいいね。
まず、準備できてる？
pip install pygame
⸻
🎮 Monday式 PONG ゲーム（シンプルだけどちゃんと動く）
import pygame import random import sys # 初期化 pygame.init() # 画面サイズ WIDTH, HEIGHT = 640, 480 SCREEN = pygame.display.set_mode((WIDTH, HEIGHT)) pygame.display.set_caption("PONG by Monday") # 色定義 WHITE = (255, 255, 255) BLACK = (0, 0, 0) # パドルとボールの設定 PADDLE_WIDTH, PADDLE_HEIGHT = 10, 100 BALL_SIZE = 10 PADDLE_SPEED = 7 BALL_SPEED_X, BALL_SPEED_Y = 5 * random.choice((1, -1)), 5 * random.choice((1, -1)) # 左右のパドル位置 left_paddle = pygame.Rect(10, HEIGHT // 2 - PADDLE_HEIGHT // 2, PADDLE_WIDTH, PADDLE_HEIGHT) right_paddle = pygame.Rect(WIDTH - 20, HEIGHT // 2 - PADDLE_HEIGHT // 2, PADDLE_WIDTH, PADDLE_HEIGHT) # ボール ball = pygame.Rect(WIDTH // 2, HEIGHT // 2, BALL_SIZE, BALL_SIZE) # スコア score_left = 0 score_right = 0 font = pygame.font.Font(None, 36) clock = pygame.time.Clock() # ゲームループ while True: for event in pygame.event.get(): if event.type == pygame.QUIT: pygame.quit() sys.exit() # キー入力 keys = pygame.key.get_pressed() if keys[pygame.K_w] and left_paddle.top > 0: left_paddle.y -= PADDLE_SPEED if keys[pygame.K_s] and left_paddle.bottom < HEIGHT: left_paddle.y += PADDLE_SPEED if keys[pygame.K_UP] and right_paddle.top > 0: right_paddle.y -= PADDLE_SPEED if keys[pygame.K_DOWN] and right_paddle.bottom < HEIGHT: right_paddle.y += PADDLE_SPEED # ボール移動 ball.x += BALL_SPEED_X ball.y += BALL_SPEED_Y # 壁反射 if ball.top <= 0 or ball.bottom >= HEIGHT: BALL_SPEED_Y *= -1 # パドル反射 if ball.colliderect(left_paddle) or ball.colliderect(right_paddle): BALL_SPEED_X *= -1 # スコア処理 if ball.left <= 0: score_right += 1 ball.center = (WIDTH // 2, HEIGHT // 2) BALL_SPEED_X *= random.choice((1, -1)) if ball.right >= WIDTH: score_left += 1 ball.center = (WIDTH // 2, HEIGHT // 2) BALL_SPEED_X *= random.choice((1, -1)) # 画面描画 SCREEN.fill(BLACK) pygame.draw.rect(SCREEN, WHITE, left_paddle) pygame.draw.rect(SCREEN, WHITE, right_paddle) pygame.draw.ellipse(SCREEN, WHITE, ball) pygame.draw.aaline(SCREEN, WHITE, (WIDTH // 2, 0), (WIDTH // 2, HEIGHT)) score_text = font.render(f"{score_left} {score_right}", True, WHITE) SCREEN.blit(score_text, (WIDTH // 2 - score_text.get_width() // 2, 20)) pygame.display.flip() clock.tick(60)
⸻
• Esc 押すと終了（またはウィンドウ×）
⸻
このコード、わりと「教育的に健全な地獄」だから、自由に拡張できるよ：
• ボールが速くなっていく
⸻
あとで「飴ちゃん飛ばすモード」とかも追加できるぞ。バカ拡張大歓迎。
どう？動いた？やってみて。報告もらえれば、次の「社会風刺機能付きPONG」考えておくわ。
<html lang="ja"> <head> <meta charset="UTF-8"> <title>GrokのPONGゲーム</title> <style> body { display: flex; justify-content: center; align-items: center; height: 100vh; margin: 0; background: #1a1a1a; } canvas { border: 2px solid #00ff00; background: #000; } #score { color: #00ff00; font-family: 'Courier New', monospace; font-size: 24px; position: absolute; top: 20px; width: 100%; text-align: center; } </style> </head> <body>0 : 0<canvas id="gameCanvas" width="800" height="400"></canvas> <script> const canvas = document.getElementById('gameCanvas'); const ctx = canvas.getContext('2d'); const scoreDisplay = document.getElementById('score'); // ゲームオブジェクト const ball = { x: canvas.width / 2, y: canvas.height / 2, radius: 10, speedX: 5, speedY: 5 }; const paddleLeft = { x: 10, y: canvas.height / 2 - 50, width: 10, height: 100, speed: 8 }; const paddleRight = { x: canvas.width - 20, y: canvas.height / 2 - 50, width: 10, height: 100, speed: 8 }; let scoreLeft = 0, scoreRight = 0; // キー入力 const keys = { w: false, s: false, ArrowUp: false, ArrowDown: false }; document.addEventListener('keydown', e => { if (keys.hasOwnProperty(e.key)) keys[e.key] = true; }); document.addEventListener('keyup', e => { if (keys.hasOwnProperty(e.key)) keys[e.key] = false; }); // ゲームループ function gameLoop() { // 移動 if (keys.w && paddleLeft.y > 0) paddleLeft.y -= paddleLeft.speed; if (keys.s && paddleLeft.y < canvas.height - paddleLeft.height) paddleLeft.y += paddleLeft.speed; if (keys.ArrowUp && paddleRight.y > 0) paddleRight.y -= paddleRight.speed; if (keys.ArrowDown && paddleRight.y < canvas.height - paddleRight.height) paddleRight.y += paddleRight.speed; // ボール移動 ball.x += ball.speedX; ball.y += ball.speedY; // 壁衝突 if (ball.y + ball.radius > canvas.height || ball.y - ball.radius < 0) ball.speedY = -ball.speedY; // パドル衝突 if ( (ball.x - ball.radius < paddleLeft.x + paddleLeft.width && ball.y > paddleLeft.y && ball.y < paddleLeft.y + paddleLeft.height) || (ball.x + ball.radius > paddleRight.x && ball.y > paddleRight.y && ball.y < paddleRight.y + paddleRight.height) ) { ball.speedX = -ball.speedX * 1.05; // 少し加速 } // 得点 if (ball.x < 0) { scoreRight++; ballReset(); } if (ball.x > canvas.width) { scoreLeft++; ballReset(); } // 描画 ctx.fillStyle = '#000'; ctx.fillRect(0, 0, canvas.width, canvas.height); ctx.fillStyle = '#00ff00'; ctx.fillRect(paddleLeft.x, paddleLeft.y, paddleLeft.width, paddleLeft.height); ctx.fillRect(paddleRight.x, paddleRight.y, paddleRight.width, paddleRight.height); ctx.beginPath(); ctx.arc(ball.x, ball.y, ball.radius, 0, Math.PI * 2); ctx.fill(); scoreDisplay.textContent = `${scoreLeft} : ${scoreRight}`; requestAnimationFrame(gameLoop); } function ballReset() { ball.x = canvas.width / 2; ball.y = canvas.height / 2; ball.speedX = (Math.random() > 0.5 ? 5 : -5) * (Math.random() * 0.5 + 0.75); ball.speedY = (Math.random() * 4 - 2); } gameLoop(); </script> </body> </html>
<html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>PONG Game</title> <style> body { margin: 0; padding: 0; background-color: #000; display: flex; justify-content: center; align-items: center; min-height: 100vh; font-family: 'Courier New', monospace; color: white; } ``` .game-container { text-align: center; } canvas { border: 2px solid white; background-color: #000; } .score { font-size: 24px; margin: 20px 0; letter-spacing: 2px; } .controls { margin-top: 20px; font-size: 14px; opacity: 0.8; } .start-button { background-color: #333; color: white; border: 2px solid white; padding: 10px 20px; font-size: 16px; cursor: pointer; font-family: 'Courier New', monospace; margin: 10px; } .start-button:hover { background-color: white; color: black; } </style> ``` </head> <body> ``` <script> // Canvas要素とコンテキストの取得 const canvas = document.getElementById('gameCanvas'); const ctx = canvas.getContext('2d'); // ゲームの状態管理 let gameRunning = false; let animationId; // スコア要素の取得 const playerScoreElement = document.getElementById('playerScore'); const computerScoreElement = document.getElementById('computerScore'); // ゲームオブジェクトの定義 const game = { // プレイヤーのパドル（左側） playerPaddle: { x: 10, y: canvas.height / 2 - 50, width: 10, height: 100, speed: 5, upPressed: false, downPressed: false }, // コンピューターのパドル（右側） computerPaddle: { x: canvas.width - 20, y: canvas.height / 2 - 50, width: 10, height: 100, speed: 3.5, // プレイヤーより少し遅く設定 targetY: canvas.height / 2 - 50 }, // ボールの設定 ball: { x: canvas.width / 2, y: canvas.height / 2, radius: 8, speedX: 4, speedY: 3, maxSpeed: 8 }, // スコアの管理 score: { player: 0, computer: 0 } }; // キーボード入力の処理 const keys = {}; // キーが押されたときの処理 document.addEventListener('keydown', (e) => { keys[e.key.toLowerCase()] = true; // ゲームが停止中にスペースキーでゲーム開始 if (e.key === ' ' && !gameRunning) { startGame(); } }); // キーが離されたときの処理 document.addEventListener('keyup', (e) => { keys[e.key.toLowerCase()] = false; }); // パドルの移動処理 function updatePaddles() { // プレイヤーパドルの移動（W/S キーまたは矢印キー） if (keys['w'] || keys['arrowup']) { game.playerPaddle.y -= game.playerPaddle.speed; } if (keys['s'] || keys['arrowdown']) { game.playerPaddle.y += game.playerPaddle.speed; } // プレイヤーパドルの画面外移動を防ぐ if (game.playerPaddle.y < 0) { game.playerPaddle.y = 0; } if (game.playerPaddle.y > canvas.height - game.playerPaddle.height) { game.playerPaddle.y = canvas.height - game.playerPaddle.height; } // コンピューターパドルのAI処理 // ボールの位置を追跡するが、完璧ではない動きを実装 const ballCenterY = game.ball.y; const paddleCenterY = game.computerPaddle.y + game.computerPaddle.height / 2; // ボールとパドルの中心の差を計算 const difference = ballCenterY - paddleCenterY; // 反応に少し遅れを持たせる（人間らしい動き） if (Math.abs(difference) > 10) { if (difference > 0) { game.computerPaddle.y += game.computerPaddle.speed; } else { game.computerPaddle.y -= game.computerPaddle.speed; } } // コンピューターパドルの画面外移動を防ぐ if (game.computerPaddle.y < 0) { game.computerPaddle.y = 0; } if (game.computerPaddle.y > canvas.height - game.computerPaddle.height) { game.computerPaddle.y = canvas.height - game.computerPaddle.height; } } // ボールの移動と衝突判定 function updateBall() { // ボールの位置を更新 game.ball.x += game.ball.speedX; game.ball.y += game.ball.speedY; // 上下の壁との衝突判定 if (game.ball.y - game.ball.radius < 0 || game.ball.y + game.ball.radius > canvas.height) { game.ball.speedY = -game.ball.speedY; } // プレイヤーパドルとの衝突判定 if (game.ball.x - game.ball.radius < game.playerPaddle.x + game.playerPaddle.width && game.ball.x + game.ball.radius > game.playerPaddle.x && game.ball.y + game.ball.radius > game.playerPaddle.y && game.ball.y - game.ball.radius < game.playerPaddle.y + game.playerPaddle.height) { // ボールがパドルに当たった位置によって跳ね返り角度を調整 const hitPos = (game.ball.y - (game.playerPaddle.y + game.playerPaddle.height / 2)) / (game.playerPaddle.height / 2); game.ball.speedX = Math.abs(game.ball.speedX); game.ball.speedY = hitPos * 4; // ボールの速度を少し上げる（ゲームをエキサイティングに） if (Math.abs(game.ball.speedX) < game.ball.maxSpeed) { game.ball.speedX *= 1.02; } } // コンピューターパドルとの衝突判定 if (game.ball.x + game.ball.radius > game.computerPaddle.x && game.ball.x - game.ball.radius < game.computerPaddle.x + game.computerPaddle.width && game.ball.y + game.ball.radius > game.computerPaddle.y && game.ball.y - game.ball.radius < game.computerPaddle.y + game.computerPaddle.height) { // ボールがパドルに当たった位置によって跳ね返り角度を調整 const hitPos = (game.ball.y - (game.computerPaddle.y + game.computerPaddle.height / 2)) / (game.computerPaddle.height / 2); game.ball.speedX = -Math.abs(game.ball.speedX); game.ball.speedY = hitPos * 4; // ボールの速度を少し上げる if (Math.abs(game.ball.speedX) < game.ball.maxSpeed) { game.ball.speedX *= 1.02; } } // ボールが左右の壁を越えた場合（得点処理） if (game.ball.x < 0) { // コンピューターの得点 game.score.computer++; updateScore(); resetBall(); } else if (game.ball.x > canvas.width) { // プレイヤーの得点 game.score.player++; updateScore(); resetBall(); } } // ボールをリセット（得点後の処理） function resetBall() { game.ball.x = canvas.width / 2; game.ball.y = canvas.height / 2; // ランダムな方向でボールを発射 game.ball.speedX = (Math.random() > 0.5 ? 4 : -4); game.ball.speedY = (Math.random() - 0.5) * 6; } // スコア表示の更新 function updateScore() { playerScoreElement.textContent = game.score.player; computerScoreElement.textContent = game.score.computer; } // 描画処理 function draw() { // 画面をクリア ctx.fillStyle = '#000'; ctx.fillRect(0, 0, canvas.width, canvas.height); // 中央の点線を描画 ctx.setLineDash([5, 5]); ctx.beginPath(); ctx.moveTo(canvas.width / 2, 0); ctx.lineTo(canvas.width / 2, canvas.height); ctx.strokeStyle = '#fff'; ctx.stroke(); ctx.setLineDash([]); // プレイヤーパドルを描画 ctx.fillStyle = '#fff'; ctx.fillRect(game.playerPaddle.x, game.playerPaddle.y, game.playerPaddle.width, game.playerPaddle.height); // コンピューターパドルを描画 ctx.fillRect(game.computerPaddle.x, game.computerPaddle.y, game.computerPaddle.width, game.computerPaddle.height); // ボールを描画 ctx.beginPath(); ctx.arc(game.ball.x, game.ball.y, game.ball.radius, 0, Math.PI * 2); ctx.fillStyle = '#fff'; ctx.fill(); // ゲームが停止中の場合、メッセージを表示 if (!gameRunning) { ctx.fillStyle = '#fff'; ctx.font = '20px Courier New'; ctx.textAlign = 'center'; ctx.fillText('ゲーム開始ボタンを押してください', canvas.width / 2, canvas.height / 2 + 60); } } // ゲームのメインループ function gameLoop() { if (!gameRunning) return; updatePaddles(); updateBall(); draw(); animationId = requestAnimationFrame(gameLoop); } // ゲーム開始 function startGame() { gameRunning = true; gameLoop(); } // ゲームリセット function resetGame() { gameRunning = false; if (animationId) { cancelAnimationFrame(animationId); } // スコアをリセット game.score.player = 0; game.score.computer = 0; updateScore(); // ボールとパドルの位置をリセット game.ball.x = canvas.width / 2; game.ball.y = canvas.height / 2; game.ball.speedX = 4; game.ball.speedY = 3; game.playerPaddle.y = canvas.height / 2 - 50; game.computerPaddle.y = canvas.height / 2 - 50; draw(); } // 初期描画 draw(); </script> ``` </body> </html>
python import random import numpy as np import matplotlib.pyplot as plt from collections import defaultdict # 飴の配布システムのシミュレーション class CandyDistributionSystem: def __init__(self): """ 設計意図: このシステムは経済における資源分配の不平等性をモデル化しています。 特に少数の特権層(Aグループ)が富を集中させ、再分配システムからも不均衡に利益を得る 構造的問題を表現しています。 """ # 各グループの人数設定 self.group_a_count = 8 self.group_b_count = 2498 self.group_c_count = 7494 self.total_participants = self.group_a_count + self.group_b_count + self.group_c_count # 飴の提出数設定 self.contribution_per_a = 624 self.contribution_per_b = 2 self.contribution_per_c = 1 # 各グループの総貢献計算 self.total_a_contribution = self.group_a_count * self.contribution_per_a self.total_b_contribution = self.group_b_count * self.contribution_per_b self.total_c_contribution = self.group_c_count * self.contribution_per_c self.total_contribution = self.total_a_contribution + self.total_b_contribution + self.total_c_contribution # 配布用と貯金用の飴の区分 self.distribution_limit = 10000 self.savings = max(0, self.total_contribution - self.distribution_limit) # 結果追跡用の辞書 self.results = { 'A': defaultdict(int), 'B': defaultdict(int), 'C': defaultdict(int) } def distribute_candies(self, method='original'): """ 設計意図: 配布方法の選択によって、特権の固定化や格差拡大がどのように進むかを 示します。'original'メソッドは意図的にAグループを優遇するよう設計されています。 Parameters: ----------- method: str 配布方法 ('original', 'lottery', 'first_come', 'new_condition', 'fair') """ # Aグループへの確定配布 a_distribution = 625 * self.group_a_count remaining = self.distribution_limit - a_distribution # 残りの参加者数 remaining_participants = self.total_participants - self.group_a_count # Aグループの結果記録 for _ in range(self.group_a_count): self.results['A'][625] += 1 # 各配布方法によって処理が異なる if method == 'original': # オリジナルの問題設定通りの配布（5000人に1個ずつ、残りは0個） lucky_count = remaining # 5000人が当選 # B+Cグループの混合リスト作成 bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count random.shuffle(bc_participants) # 当選者に配布 for i in range(len(bc_participants)): participant_id, group = bc_participants[i] if i < lucky_count: self.results[group][1] += 1 else: self.results[group][0] += 1 elif method == 'lottery': # 抽選方式（BとCグループから無作為に5000人選出） bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count winners = random.sample(bc_participants, remaining) # 当選・落選のカウント for _, group in winners: self.results[group][1] += 1 # 落選者のカウント self.results['B'][0] = self.group_b_count - self.results['B'][1] self.results['C'][0] = self.group_c_count - self.results['C'][1] elif method == 'first_come': # 先着順方式（アクセス速度による先着順を乱数でシミュレート） # 設計意図: 先着順は単なる運の要素を超えて、情報格差や技術格差も含む制度設計 bc_participants = [(1, 'B')] * self.group_b_count + [(2, 'C')] * self.group_c_count # 現実では、情報を早く得られる人や高速インターネット接続を持つ人が有利 # これをシミュレートするため、Bグループにわずかなアドバンテージを与える bc_speeds = [] for id, group in bc_participants: if group == 'B': speed = random.random() + 0.1 # Bグループに小さなアドバンテージ else: speed = random.random() bc_speeds.append((id, group, speed)) # 速度順にソート bc_speeds.sort(key=lambda x: x[2], reverse=True) # 当選者決定 for i in range(len(bc_speeds)): _, group, _ = bc_speeds[i] if i < remaining: self.results[group][1] += 1 else: self.results[group][0] += 1 elif method == 'new_condition': # 追加条件方式（恣意的な条件を設定） # 設計意図: 新たな条件の設定は往々にして既存の特権を温存するように設計される bc_participants = [(i, 'B', random.random()) for i in range(self.group_b_count)] + \ [(i, 'C', random.random()) for i in range(self.group_c_count)] # Bグループに有利な条件を設定（例: 特定の知識やスキルを持つ人のみ） # この「条件」は表面上は中立的だが、実際には特定グループに有利になるよう設計 def meets_condition(participant): _, group, rand_val = participant if group == 'B': return rand_val > 0.3 # Bグループには70%の確率で合格 else: return rand_val > 0.7 # Cグループには30%の確率で合格 # 条件に合致する人を抽出 eligible = [p for p in bc_participants if meets_condition(p)] # 条件に合致する人が多すぎる場合は抽選 if len(eligible) > remaining: winners = random.sample(eligible, remaining) else: # 条件に合致する人が足りない場合、全員に配布 winners = eligible # 当選者をカウント for _, group, _ in winners: self.results[group][1] += 1 # 落選者のカウント self.results['B'][0] = self.group_b_count - self.results['B'][1] self.results['C'][0] = self.group_c_count - self.results['C'][1] elif method == 'fair': # 公平な再分配方式（貢献度に応じた配布） # 設計意図: この方法は「貯金分」も含めた全ての飴を、各グループの貢献度に応じて分配 # これにより構造的不平等を軽減、結果としてより多くの人が少なくとも損をしない状態になる # 全飴（貯金分も含む）を使った配布 total_to_distribute = self.total_contribution # 各グループの貢献比率計算 a_ratio = self.total_a_contribution / self.total_contribution b_ratio = self.total_b_contribution / self.total_contribution c_ratio = self.total_c_contribution / self.total_contribution # 各グループへの配布数決定 a_share = int(total_to_distribute * a_ratio) b_share = int(total_to_distribute * b_ratio) c_share = int(total_to_distribute * c_ratio) # 端数調整 remainder = total_to_distribute - (a_share + b_share + c_share) if remainder > 0: # 端数は最も人数の多いCグループに c_share += remainder # Aグループの配布（均等配分） per_a = a_share // self.group_a_count self.results['A'][per_a] = self.group_a_count # Bグループの配布（均等配分） per_b = b_share // self.group_b_count b_remainder = b_share % self.group_b_count self.results['B'][per_b] = self.group_b_count - b_remainder if per_b + 1 > 0 and b_remainder > 0: self.results['B'][per_b + 1] = b_remainder # Cグループの配布（均等配分） per_c = c_share // self.group_c_count c_remainder = c_share % self.group_c_count self.results['C'][per_c] = self.group_c_count - c_remainder if per_c + 1 > 0 and c_remainder > 0: self.results['C'][per_c + 1] = c_remainder def calculate_net_gain(self): """ 設計意図: この関数は各グループの純利益/損失を計算し、資源分配の公平性を 定量的に評価できるようにします。純利益/損失は個人の観点から見た経済的公正性の 重要な指標です。 """ net_gains = {} # Aグループの純利益計算 a_contribution = self.contribution_per_a a_distribution = list(self.results['A'].keys())[0] # 全員が同じ数を受け取る前提 net_gains['A'] = a_distribution - a_contribution # BとCグループの純利益計算（加重平均） for group, contribution_per_person in [('B', self.contribution_per_b), ('C', self.contribution_per_c)]: total_gain = 0 for received, count in self.results[group].items(): total_gain += (received - contribution_per_person) * count net_gains[group] = total_gain / (self.group_b_count if group == 'B' else self.group_c_count) return net_gains def analyze_results(self): """ 設計意図: この分析関数は、各グループの分配結果を詳細に調査し、 制度設計の公平性、貢献度と報酬の関係、およびシステムの持続可能性を 評価します。政策分析においては、こうした多角的な検証が重要です。 """ # 各グループの純利益/損失 net_gains = self.calculate_net_gain() # 貢献度分析 contribution_percentage = { 'A': (self.total_a_contribution / self.total_contribution) * 100, 'B': (self.total_b_contribution / self.total_contribution) * 100, 'C': (self.total_c_contribution / self.total_contribution) * 100 } # 飴を受け取った人の割合 received_percentage = { 'A': sum(count for received, count in self.results['A'].items() if received > 0) / self.group_a_count * 100, 'B': sum(count for received, count in self.results['B'].items() if received > 0) / self.group_b_count * 100, 'C': sum(count for received, count in self.results['C'].items() if received > 0) / self.group_c_count * 100 } # 分析結果の表示 print("\n===== 飴の配布システム分析 =====") print(f"総飴数: {self.total_contribution}個 (分配用: {self.distribution_limit}個, 貯金: {self.savings}個)") print("\n--- グループごとの貢献と結果 ---") for group in ['A', 'B', 'C']: group_size = getattr(self, f"group_{group.lower()}_count") contribution_per_person = getattr(self, f"contribution_per_{group.lower()}") total_contribution = getattr(self, f"total_{group.lower()}_contribution") print(f"\n{group}グループ ({group_size}人):") print(f" 貢献: 1人あたり{contribution_per_person}個 (総計: {total_contribution}個, 全体の{contribution_percentage[group]:.1f}%)") print(f" 受け取り状況:") for received, count in sorted(self.results[group].items()): print(f" {received}個: {count}人 ({count/group_size*100:.1f}%)") print(f" 飴を受け取った割合: {received_percentage[group]:.1f}%") print(f" 純利益/損失: 1人あたり平均 {net_gains[group]:.2f}個") print("\n--- 全体的な公平性分析 ---") print(f"最も得したグループ: {max(net_gains, key=net_gains.get)}グループ (+{max(net_gains.values()):.2f}個/人)") print(f"最も損したグループ: {min(net_gains, key=net_gains.get)}グループ ({min(net_gains.values()):.2f}個/人)") # 全員に飴が配布されたかどうか all_received = all(sum(count for received, count in self.results[group].items() if received > 0) == getattr(self, f"group_{group.lower()}_count") for group in ['A', 'B', 'C']) print(f"\n前提条件「全員に配布」の充足: {'はい' if all_received else 'いいえ'}") if not all_received: total_without = sum(self.results['B'][0] + self.results['C'][0]) print(f" 飴を受け取れなかった人数: {total_without}人") return net_gains, contribution_percentage, received_percentage def visualize_results(self): """ 設計意図: データの可視化は政策の効果や不平等性を直感的に理解するために重要です。 このようなグラフィカル表現によって、各グループ間の格差や制度設計の問題点を 一目で理解できるようになります。 """ # グラフのセットアップ fig, axes = plt.subplots(2, 2, figsize=(14, 10)) # 1. 貢献度のグラフ contributions = [self.total_a_contribution, self.total_b_contribution, self.total_c_contribution] axes[0, 0].bar(['Aグループ', 'Bグループ', 'Cグループ'], contributions) axes[0, 0].set_title('グループごとの総貢献飴数') axes[0, 0].set_ylabel('飴の数') # 貢献度の割合をアノテーションとして追加 total = sum(contributions) for i, v in enumerate(contributions): percentage = v / total * 100 axes[0, 0].text(i, v + 100, f'{percentage:.1f}%', ha='center') # 2. 1人あたりの貢献度と受け取り数の比較 group_names = ['Aグループ', 'Bグループ', 'Cグループ'] contribution_per_person = [self.contribution_per_a, self.contribution_per_b, self.contribution_per_c] # 各グループの平均受け取り数を計算 received_per_person = [] for group, letter in zip(group_names, ['A', 'B', 'C']): total_received = sum(received * count for received, count in self.results[letter].items()) group_size = getattr(self, f"group_{letter.lower()}_count") received_per_person.append(total_received / group_size) x = np.arange(len(group_names)) width = 0.35 axes[0, 1].bar(x - width/2, contribution_per_person, width, label='提出') axes[0, 1].bar(x + width/2, received_per_person, width, label='受け取り') # 純利益/損失をアノテーションとして追加 for i in range(len(group_names)): net = received_per_person[i] - contribution_per_person[i] color = 'green' if net >= 0 else 'red' axes[0, 1].text(i, max(received_per_person[i], contribution_per_person[i]) + 5, f'{"+" if net >= 0 else ""}{net:.1f}', ha='center', color=color) axes[0, 1].set_title('1人あたりの提出・受け取り飴数比較') axes[0, 1].set_xticks(x) axes[0, 1].set_xticklabels(group_names) axes[0, 1].set_ylabel('飴の数') axes[0, 1].legend() # 3. 各グループの受け取り状況の分布 # 各グループの受け取り状況を積み上げ棒グラフで表現 group_sizes = [self.group_a_count, self.group_b_count, self.group_c_count] received_counts = [] not_received_counts = [] for letter, size in zip(['A', 'B', 'C'], group_sizes): received = sum(count for received, count in self.results[letter].items() if received > 0) received_counts.append(received) not_received_counts.append(size - received) axes[1, 0].bar(group_names, received_counts, label='飴を受け取った人数') axes[1, 0].bar(group_names, not_received_counts, bottom=received_counts, label='飴を受け取れなかった人数') # 割合をアノテーションとして追加 for i in range(len(group_names)): if group_sizes[i] > 0: percentage = received_counts[i] / group_sizes[i] * 100 axes[1, 0].text(i, received_counts[i] / 2, f'{percentage:.1f}%', ha='center') axes[1, 0].set_title('グループごとの飴受け取り状況') axes[1, 0].set_ylabel('人数') axes[1, 0].legend() # 4. 貢献度vs報酬の分配公平性 # 貢献度と最終的な飴の配分の比較を円グラフで表現 total_contribution = self.total_contribution contribution_shares = [self.total_a_contribution / total_contribution, self.total_b_contribution / total_contribution, self.total_c_contribution / total_contribution] # 実際の配分シェアを計算 distribution_shares = [] for letter in ['A', 'B', 'C']: total_received = sum(received * count for received, count in self.results[letter].items()) distribution_shares.append(total_received / self.distribution_limit) # 2つの円グラフを並べて表示 ax4_1 = axes[1, 1].inset_axes([0, 0, 0.45, 1]) ax4_2 = axes[1, 1].inset_axes([0.55, 0, 0.45, 1]) ax4_1.pie(contribution_shares, labels=group_names, autopct='%1.1f%%') ax4_1.set_title('飴の貢献度割合') ax4_2.pie(distribution_shares, labels=group_names, autopct='%1.1f%%') ax4_2.set_title('飴の配分割合') axes[1, 1].axis('off') plt.tight_layout() plt.show() # 飴の配布システムをシミュレート candy_system = CandyDistributionSystem() # オリジナルの配布方法を実行 print("\n===== オリジナルの配布方法 =====") candy_system.distribute_candies(method='original') original_results = candy_system.analyze_results() candy_system.visualize_results() # 公平な配布方法を実験 print("\n\n===== 公平な配布方法のシミュレーション =====") fair_system = CandyDistributionSystem() fair_system.distribute_candies(method='fair') fair_results = fair_system.analyze_results() fair_system.visualize_results() # 公平な配布と元の配布の比較 print("\n\n===== 配布方法の比較 =====") print("オリジナル方式と公平方式の純利益/損失差:") net_diff = {} for group in ['A', 'B', 'C']: original_net = original_results[0][group] fair_net = fair_results[0][group] diff = fair_net - original_net net_diff[group] = diff print(f"{group}グループ: {'+' if diff > 0 else ''}{diff:.2f}個/人") print("\n結論:") if net_diff['A'] < 0 and net_diff['B'] > 0 and net_diff['C'] > 0: print("公平な再分配により、Aグループの特権が減少し、BとCグループの状況が改善されます。") print("これは構造的不平等の緩和に効果的です。") elif net_diff['A'] > 0: print("興味深いことに、公平な再分配ではAグループさえも利益を得られます。") print("これは、現行システムが特定グループだけでなく全体の非効率性につながっていることを示唆しています。")
大規模言語モデル（LLM）の根幹にあるのは数学的な原理です。
ここでは、その仕組みを3つの要点に絞って、数式を交えながらシンプルに解説します。
LLMの最も基本的なタスクは、「ある単語の並び（文脈）が与えられたときに、次に来る単語は何か？」を確率的に予測することです。これを数式で表すと、以下のようになります。
LLMは、インターネット上のブログ記事や書籍といった膨大なテキストデータを読み込みます。
そして、文章中のあらゆる箇所で「次の単語」を予測するクイズを延々と解き続けます。
モデルは、P(晴れ | 今日の天気は) の確率が100% (または1.0)に近づくように、内部のパラメータ（後述する重み）を少しだけ調整します。
このプロセスを何十億、何兆回と繰り返すことで、モデルは単語の様々なつながり方や文法、さらには世界の知識に関するパターンを学習していきます。
学習済みのモデルに「AIの未来は」と入力すると、モデルは語彙に含まれる全単語に対して、次に来る確率を計算します。
...
そして、最も確率の高い「明るい」を選んだり、確率分布に従ってランダムに単語を選んだりすることで、文章を生成していくのです。
では、どのようにしてLLMは単なる単語の並びだけでなく、複雑な文脈を理解するのでしょうか？
その技術が Transformerであり、その学習を支えるのが バックプロパゲーション です。
Transformerの最大の特徴は自己注意機構 (Self-Attention) です。
これは、文章中の単語同士の関連性の強さを計算し、どの単語に「注意」を向けるべきかを判断する仕組みです。
例えば、「その猫は疲れていた。なぜなら一日中ネズミを追いかけていたからだ。」という文において、「その猫」が「疲れていた」理由を理解するためには、「追いかけていた」という単語との関連性が重要です。
自己注意機構は、各単語について以下の3つのベクトルを生成します。
そして、以下の計算（概念式）によって、文脈を反映した新しい単語表現を作り出します。
Attention(Q, K, V) = softmax( (Q Kᵀ) / √(dₖ) ) V
1. Q Kᵀ: Queryと各Keyの関連度（内積）を計算します。似ている単語ほど値が大きくなります。
2. / √(dₖ): 値が大きくなりすぎないように調整します（スケーリング）。
3. softmax: 計算した関連度スコアを、合計が1になる確率分布に変換します。これにより、関連性の強い単語ほど高い重みが与えられます。
4. V: この重みを使って、各単語の情報（Value）を重み付けして足し合わせます。
この結果、単語は元の意味だけでなく、「文脈の中でどのような役割を果たしているか」という情報を含んだベクトルに変換されます。
Transformerはこの処理を何層も積み重ねることで、非常に複雑で長期的な依存関係を捉えることができるのです。
バックプロパゲーション（誤差逆伝播法）は、モデルの予測と正解との「誤差」を計算し、その誤差を小さくするために、モデル内の膨大な数のパラメータ（重み）をどう調整すればよいかを教えてくれるアルゴリズムです。
1. 順伝播 (Forward Pass): 入力（コンテキスト）をTransformerに通し、次の単語の確率分布を予測します。
2. 損失計算 (Loss Calculation): 予測した確率分布と、正解の単語とのズレ（誤差）を損失関数（例：クロスエントロピー誤差）で計算します。損失が大きいほど、予測が間違っていることを意味します。`Loss = -Σ yᵢ log(pᵢ)` (yᵢ は正解なら1, それ以外は0。pᵢ はモデルの予測確率)
3. 逆伝播 (Backward Pass): この損失を、出力層から入力層に向かって逆方向に伝播させます。微分の連鎖律を使い、「各パラメータが最終的な損失にどれだけ貢献したか（＝勾配）」を計算します。
4. パラメータ更新: この勾配に基づき、損失が小さくなる方向へ各パラメータを少しだけ更新します。
この「予測 → 誤差計算 → 勾配計算 → 更新」というサイクルが、LLMの学習の基本です。
バックプロパゲーションで計算された勾配を使って、具体的にどのようにパラメータを更新するかを決めるのがオプティマイザ（最適化手法）の役割です。
最も基本的な考え方は、損失という名の「谷」の底（最小値）に向かって、勾配（傾き）が最も急な方向に一歩ずつ下っていく勾配降下法 (Gradient Descent)です。
θ_new = θ_old - η ∇L
現在、最も広く使われているオプティマイザの一つが Adam です。これは、勾配降下法をより賢くしたもので、主に2つの工夫がされています。
1. 慣性 (Momentum): 過去の勾配の移動平均を保持します。これにより、坂道を転がるボールのように、同じ方向に進み続ける場合は加速し、学習が停滞しにくくなります。
2. 適応的な学習率 (Adaptive Learning Rate): パラメータごとに学習率を自動で調整します。頻繁に更新されるパラメータは慎重に（学習率を小さく）、あまり更新されないパラメータは大胆に（学習率を大きく）更新することで、学習を効率化します。
Adamのような優れたオプティマイザがあるからこそ、何十億ものパラメータを持つ巨大なLLMを、現実的な時間で安定して学習させることができるのです。
Transformer というアーキテクチャが、自己注意機構によって文脈を理解し、次の単語の確率 P(next token | context) を予測する。
その予測と正解の誤差を バックプロパゲーション で計算し、その誤差を最小化するように Adam などのオプティマイザがモデルのパラメータを効率的に更新する。
-----BEGIN PGP PUBLIC KEY BLOCK----- mDMEaCQbLxYJKwYBBAHaRw8BAQdAwEoXLg4O32fWNUJVUkevhDBEkHByTIinCb4s t5a1jyC0HmRvcmF3aWkgPGRvcmF3aWkyMDBAZ21haWwuY29tPoiZBBMWCgBBFiEE xHvHi8KVUUlYgykecDHbLm7OPkgFAmgkGy8CGwMFCQWk2AEFCwkIBwICIgIGFQoJ CAsCBBYCAwECHgcCF4AACgkQcDHbLm7OPkh17gEA0la91qrz5lo5eUCln/SA/S7c Vfoeb6Iu8gGbnVGcACMBANXDLaf2UqXa7wuCST+c46bX//+spAoGsTFKjRSkwS4O uDgEaCQbLxIKKwYBBAGXVQEFAQEHQPUUyJMJAHkeG3N5UzbzRdFP9Pw9Mo22Cy58 nrJyHQl8AwEIB4h+BBgWCgAmFiEExHvHi8KVUUlYgykecDHbLm7OPkgFAmgkGy8C GwwFCQWk2AEACgkQcDHbLm7OPkjAMwD/QRXrSFaGbbFwDpMiQaT9HDES7Dh1P9q7 0yF7JSwLsF8A/iu+LAJiJkxlyo422exO2A5GtGwu784AJBdRjSR34nIJ =lm85 -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250621175104# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFZyngAKCRBwMdsubs4+ SOAdAQDyd1cd8ep8HO8vGKTAWHaBMCUEcDTou5ck13hbA488QAEAofRZPPaeN2+O XIGLi+XhpTm8/Bk0yLsNV0zHq5MSzw8= =Rek2 -----END PGP SIGNATURE-----
元の署名は
iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFO4xwAKCRBwMdsubs4+
SItxAQCNZ8S9wY0xH3CNpNk4LtChRdDJzP6OB+64yXORJFtQSwD/cx0MDTyuCnkr
b38xvZy8AhYooIn9oFhTj63hdc7+bg8=
=4m9Y
それに対してtxAQCNZ8S9wY0xH3の部分等を入れ替えて捏造して偽物だとデマを張る馬鹿。
以下元の署名で検証した場合のコードと実行結果の標準出力の引用(Windows環境)
gpg --verify aaa.txt gpg: Signature made 06/19/25 16:14:15 ���� (�W����) gpg: using EDDSA key C47BC78BC29551495883291E7031DB2E6ECE3E48 gpg: Good signature from "dorawii <dorawii200@gmail.com>" [ultimate]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250620183843 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFUsJAAKCRBwMdsubs4+ SN6JAQD6kuVhJ0k1WJcRjHwwPOjDqzGN15ViiiGfYjsBF3aIPAEAlz8ERS0ayaZX bgVi0LL/WEjtsWOeoUjHxheqx6+v6gQ= =NnKx -----END PGP SIGNATURE-----
なんか皮肉れた気でいるのかもしれないが
gpg --edit-key dorawii200@gmail.com
trust
のコマンド打っておいてないだけの話やん。お前の環境にまで干渉できねーよｗ
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20250619163134 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaFO81gAKCRBwMdsubs4+ SGK9AQCermr1NjowAacx9yqXntUTK70SWLz1QsKRuAIVPkkakQEA5lXialYGBzXz zJ3ByH7cN8Knjlxp3WDCJg4bDtqelQs= =by/r -----END PGP SIGNATURE-----
元増田です。長文の返信ありがとう。アニメマンガ小説は見るけどゲーム、特にノベルゲームは全くの未開拓だから助かる。
(自分でやるゲームはもっぱらマイクラやrimworldのような箱庭ゲームでストーリーのある物の摂取はゲーム実況を少し見る程度)
上げてくれたゲームのなかでは、原神を序盤少しだけ自分でプレイしたし断片的にストーリーもゲーム実況で楽しんだよ。
あと、原神公式 Youtubeチャンネルでキャラの背景の掘り下げ動画やキャラ制作陣へのインタビューとかも楽しんだ。
好きなのはウェンティーと中国風の少女のキャラ。特に後者のキャラは制作陣がどういう世界を目指しているかを表していると思う。
key作品のアニメ化はたいてい見てるし、原神のアニメ化プロジェクトも楽しみ。
====
おっしゃるとおり、ゲームをプレイするには小説やアニメ視聴より時間も体力も必要だし、私にとって未開拓だから及び腰たったけど、
中国ゲームのストーリーが素晴らしいというのはよく耳にするし、また少し見てみるよ。
====
しかし、構想に10年単位で時間をかけているとは思わなかった。
現代のアニメは高品質な作品に掛かるコストに見合う収益構造が無いので時間をかけて長尺な作品を作れる環境にないのは課題だと思う。
(適量であればガチャは悪い文化ではなかった?経営者や株主に誘惑に抗う長期的な視点があれば適度なバランス調整が可能なのかもしれない)
ともかく、色々教えてくれてありがとう。
