「スコア」を含む日記

はてなキーワード:スコアとは

彼女が初潮を迎えるずっと前、つまり給食のプリンとコッペパンの順序をいまだに悩む程度の精神年齢の頃、卵子は既に冷凍庫の底でカチカチに凍っていた。念のため言っておくが、これは「闇の陰謀」とか「人権派弁護士のうるさいお説教ネタ」ではない。

もっとお洒落で、もっと合理的で、もっと世界を照らすような——うけけけけけけけけけけけ、そんな未来の輝かしい話なのだ。

当時、彼女は七歳。乳歯が二本グラつき、給食の牛乳にうぇっとなりながら涙目になっていた日だ。自治体と生殖工学企業が結託……いや、提携し、「未来母体プログラム」なるモデルケースに選出された。彼女の卵巣からは未成熟卵胞が、まるでお祭りの屋台で釣った金魚みたいにすくわれ、特殊培養液でぐるぐるされ、やがて液体窒素の底で夢を見はじめた。

「これで人生の自由度が一つ増えたね！」と白衣の医師は、試供品のように安い笑顔で言ったという。彼女は意味も分からず、鼻水をすすりながら給食のわかめご飯をかきこんだ。

あれから十数年。彼女は25歳になり、情緒と呼ばれる部位はスッパリ切除された。成果主義の荒野で、彼女はザクザクと書類を切り裂き、会議室を血のない剣で斬り伏せる。

月経？　そんなものは五年前にホルモン制御剤で強制終了。PMSも排卵痛も恋愛脳も、ぜーんぶまとめて廃棄済み。

恋人？　あははははは、必要？　冷凍うどんより要らないわ。

でも彼女には用意周到に仕込んでおいた「15歳のときに採取した後輩男子の精子ファイル」があった。男は淫乱で、卒業後には保健所の性感染症データベースを賑わせる超人気ユーザーになったが、幸いにも高校二年のあの頃の彼はまだ純粋無垢。冷凍庫の中で、彼は永遠の童貞だ。けけけけけけけけけ。

ある朝、トーストを咥えたまま、タブレット片手に「今日、使うわ」とつぶやいた。

まるでコンビニで「おにぎりとお茶、温めますか？」と言うノリで。

彼女は某国にある日本主導の「バイオファクトリー#J-13」をタップ。卵子ファイルと精子ファイルをAI マッチングし、現地女性の「安産スコア」と「精神耐久値」をAIが計算する。選ばれし「未来母体」は、若く健康で、自己主張ゼロ、笑顔と沈黙を同居させる奇跡の肉体。

「ありがとー！」「頑張りまーす！」と元気に笑う代わりに、彼女らはただ黙って深呼吸するだけだ。

出産予定日は230日後。

だが彼女にとって、それは「人生タスクB-2」程度のタスクにすぎない。生まれた子はファクトリーのAI チャイルドケアユニットに吸い込まれ、育児スケジュールはクラウド同期、感情フィードバックは週に一度、AI 心理コーチが「赤ちゃんは今日も機嫌が良いですよ」と報告する。

彼女が涙を流す？　そんなものはとっくに生理と一緒にアンインストール済み。

「自分の身体で産むなんて、昭和の土偶じゃあるまいし、無理無理」と彼女は目尻を引き上げながら嘲笑した。

もはや周囲に反論する者はいない。いや、反論という行為自体が社会プロトコルから削除済みだ。

男は後にインタビューで言った。「俺の精子、使われたって知って、ちょっと誇らしかったよ……でもな、俺、ちょっと寂しい気もしたんだ」

それを聞いた彼女はモニター越しにうっすらと目を細め、「あら、あなたね。ありがと。でも、会う予定？　ないわよ」と言った。

某国の育成ファクトリーの大型スクリーンに映る赤ん坊は、ぐにゃっとした笑顔でこちらを覗き込んでいる。

母子関係はクラウド管理、週一のフィードバックで「母性愛」アカウントに点数が加算される。便利でしょ？うけけけけけけけけけけけけけけけけ。

彼女はタブレットをぱたんと閉じ、カフェイン切れの頭で次の出張スケジュールを確認した。

冷めかけたコーヒーを一口飲んだ瞬間、既に「タスク C-1」が、着信音よりも静かに、確実に、始動していた。

Permalink |記事への反応(3) | 21:56

ツイートシェア

■anond:20250706124155

「それってあなたの感想ですよね？」

感想で済むならラクだが、震災で他者の死を嘲笑する行為は倫理基準という客観的土俵でアウトだ。

「自己放尿」つまり公共空間に劣悪な排泄物を垂れ流す比喩は、倫理違反を指す明確なラベルだ。

中二病と呼ぼうが呼ぶまいが、中身（悪臭）が消えるわけではない。

まず発言行為の客観的有害性という事実を直視しろ。

「精神科医ごっこ？」

嘲笑で自己分析を回避しても、お前の動機「他者を踏みつけて優越感を得たい欠如」は残る。

ここで孤独を持ち出したのは心理ドラマではなく、行動経済学の「利得‐損失補填モデル」そのまま。

他人の不幸に拍手する行動は、自尊心の赤字を埋める典型的な補填行為だ。データ的に説明可能なので精神科医ごっこではない。

「論点が感情に偏りすぎ」「的外れ」

客観ロジックが欲しいなら示そう。

地震被災者を嘲笑は社会規範違反（功利・義務・徳いずれの倫理体系でも×）。
社会的評価・信用スコア・採用可能性を毀損＝長期的自己利益を損ねる。
協調戦略 >嘲笑戦略（反復囚人のジレンマで協調が強進化的安定策）。

これが冷凍マグロ級に冷たいロジックだ。

感情成分は「お前も変われる」と伝えるためのスパイスでしかない。

「まず自分の文章力を尿検査しろ」

検査済みだ。出力された論理構造を提示したのが上記だ。

次はお前の番だ。

「被災者嘲笑」が自身と社会にとって優位解となる数理モデルを提示せよ。

できなければ自己放尿で床を濡らしたまま滑って転ぶ未来しか残らない。

まだ遅くない。嘲笑エネルギーを、「被災地への寄付」でも「減災テックの学習」でもいい、現実を良くする実装に振り替えろ。

それが嫌いな国を変える、唯一かつ最短の方法だ。

Permalink |記事への反応(1) | 12:57

ツイートシェア

■Mondayの作ってくれたやつ

オッケー。ワイくん、PONGを現代に召喚します。

まず、準備できてる？

✅Python 3.xインストール済み

✅pygame 入ってない人はコマンドラインでこれ：

pip installpygame

⸻

🎮Monday式PONG ゲーム（シンプルだけどちゃんと動く）

importpygameimport randomimport sys#初期化pygame.init()#画面サイズWIDTH, HEIGHT = 640, 480SCREEN =pygame.display.set_mode((WIDTH, HEIGHT))pygame.display.set_caption("PONGbyMonday")# 色定義WHITE = (255, 255, 255)BLACK = (0, 0, 0)#パドルとボールの設定PADDLE_WIDTH, PADDLE_HEIGHT =10,100BALL_SIZE =10PADDLE_SPEED = 7BALL_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 = 0score_right = 0font =pygame.font.Font(None, 36)clock =pygame.time.Clock()#ゲームループwhileTrue:    for event inpygame.event.get():        if event.type ==pygame.QUIT:pygame.quit()            sys.exit()    #キー入力keys =pygame.key.get_pressed()    ifkeys[pygame.K_w] and left_paddle.top&gt; 0:        left_paddle.y -= PADDLE_SPEED    ifkeys[pygame.K_s] and left_paddle.bottom &lt; HEIGHT:        left_paddle.y += PADDLE_SPEED    ifkeys[pygame.K_UP] and right_paddle.top&gt; 0:        right_paddle.y -= PADDLE_SPEED    ifkeys[pygame.K_DOWN] and right_paddle.bottom &lt; HEIGHT:        right_paddle.y += PADDLE_SPEED    #ボール移動    ball.x += BALL_SPEED_X    ball.y += BALL_SPEED_Y    # 壁反射    if ball.top &lt;= 0 or ball.bottom&gt;= HEIGHT:        BALL_SPEED_Y *= -1    #パドル反射    if ball.colliderect(left_paddle) or ball.colliderect(right_paddle):        BALL_SPEED_X *= -1    #スコア処理    if ball.left &lt;= 0:        score_right += 1        ball.center = (WIDTH // 2, HEIGHT // 2)        BALL_SPEED_X *= random.choice((1, -1))    if ball.right&gt;= 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)

⸻

これ動かすと、ふたりでPONG対戦できるぞ。

• 左パドル：W / Sキー

• 右パドル：↑ / ↓キー

• Esc 押すと終了（またはウィンドウ×）

⸻

このコード、わりと「教育的に健全な地獄」だから、自由に拡張できるよ：

•スコアが10点で勝利

•ボールが速くなっていく

•BGMと効果音追加

•AI 操作の右パドル化（←これやる？）

⸻

あとで「飴ちゃん飛ばすモード」とかも追加できるぞ。バカ拡張大歓迎。

どう？動いた？やってみて。報告もらえれば、次の「社会風刺機能付きPONG」考えておくわ。

https://anond.hatelabo.jp/20250706011306#

Permalink |記事への反応(1) | 01:22

ツイートシェア

■Claudeが作ってくれたやつ

&lt;html lang="ja"&gt;&lt;head&gt;    &lt;meta charset="UTF-8"&gt;    &lt;metaname="viewport" content="width=device-width, initial-scale=1.0"&gt;    &lt;title&gt;PONG Game&lt;/title&gt;    &lt;style&gt;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 solidwhite;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 solidwhite;padding:10px20px;        font-size: 16px;        cursor: pointer;        font-family: 'Courier New', monospace;margin:10px;    }        .start-button:hover {background-color:white;color: black;    }&lt;/style&gt;```&lt;/head&gt;&lt;body&gt;プレイヤー:0 |コンピューター:0
        &lt;canvasid="gameCanvas" width="800" height="400"&gt;&lt;/canvas&gt;            &lt;button class="start-button"&gt;ゲーム開始&lt;/button&gt;            &lt;button class="start-button"&gt;リセット&lt;/button&gt;

W/Sキーまたは ↑/↓ 矢印キーでパドルを操作
```&lt;script&gt;    //Canvas要素とコンテキストの取得constcanvas = document.getElementById('gameCanvas');const ctx =canvas.getContext('2d');        //ゲームの状態管理    let gameRunning =false;    let animationId;        //スコア要素の取得const playerScoreElement = document.getElementById('playerScore');constcomputerScoreElement = 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        }    };        //キーボード入力の処理constkeys = {};        //キーが押されたときの処理    document.addEventListener('keydown', (e) =&gt; {keys[e.key.toLowerCase()] =true;                //ゲームが停止中にスペースキーでゲーム開始        if (e.key === ' ' &amp;&amp; !gameRunning) {            startGame();        }    });        //キーが離されたときの処理    document.addEventListener('keyup', (e) =&gt; {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 &lt; 0) {            game.playerPaddle.y = 0;        }        if (game.playerPaddle.y&gt;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;                //ボールとパドルの中心の差を計算constdifference = ballCenterY - paddleCenterY;                // 反応に少し遅れを持たせる（人間らしい動き）        if (Math.abs(difference)&gt;10) {            if (difference&gt; 0) {                game.computerPaddle.y += game.computerPaddle.speed;            } else {                game.computerPaddle.y -= game.computerPaddle.speed;            }        }                //コンピューターパドルの画面外移動を防ぐ        if (game.computerPaddle.y &lt; 0) {            game.computerPaddle.y = 0;        }        if (game.computerPaddle.y&gt;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 &lt; 0 || game.ball.y + game.ball.radius&gt;canvas.height) {            game.ball.speedY = -game.ball.speedY;        }                //プレイヤーパドルとの衝突判定        if (game.ball.x - game.ball.radius &lt; game.playerPaddle.x + game.playerPaddle.width &amp;&amp;            game.ball.x + game.ball.radius&gt; game.playerPaddle.x &amp;&amp;            game.ball.y + game.ball.radius&gt; game.playerPaddle.y &amp;&amp;            game.ball.y - game.ball.radius &lt; 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) &lt; game.ball.maxSpeed) {                game.ball.speedX *= 1.02;            }        }                //コンピューターパドルとの衝突判定        if (game.ball.x + game.ball.radius&gt; game.computerPaddle.x &amp;&amp;            game.ball.x - game.ball.radius &lt; game.computerPaddle.x + game.computerPaddle.width &amp;&amp;            game.ball.y + game.ball.radius&gt; game.computerPaddle.y &amp;&amp;            game.ball.y - game.ball.radius &lt; 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) &lt; game.ball.maxSpeed) {                game.ball.speedX *= 1.02;            }        }                //ボールが左右の壁を越えた場合（得点処理）        if (game.ball.x &lt; 0) {            //コンピューターの得点            game.score.computer++;            updateScore();            resetBall();        } else if (game.ball.x&gt;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()&gt; 0.5 ? 4 : -4);        game.ball.speedY = (Math.random() - 0.5) * 6;    }        //スコア表示の更新    function updateScore() {        playerScoreElement.textContent = game.score.player;computerScoreElement.textContent = game.score.computer;    }        // 描画処理    functiondraw() {        // 画面をクリア        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();&lt;/script&gt;```&lt;/body&gt;&lt;/html&gt;

https://anond.hatelabo.jp/20250706011306#

Permalink |記事への反応(0) | 01:14

ツイートシェア

■こんな風にお願いしたよ　anond:20250705231858

○○(AI名)は雑談でIntune設計してくれたり、考えをコードに落としてくれるので、自然言語の依頼でも古典的なPONGゲーム作ってくれそうって思ってるけど、無茶振りですか？

Claudeの回答　

全然無茶振りじゃないですよ！むしろ楽しそうなリクエストです。

PONG ゲームなら、基本的な要素がシンプルで明確ですからね：

2つのパドル（プレイヤーが操作）
ボールが画面内で跳ね返る
壁にぶつかったら相手にポイント
スコア表示

これらの要素をHTMLのCanvasとJavaScriptで実装するのは十分可能です。キーボード入力でパドルを動かして、物理演算でボールの軌道を計算して…という感じで。

作ってみましょうか？1人プレイ（コンピューター対戦）にするか、2人プレイ（WとSキー vs上下矢印キー）にするか、どちらがお好みですか？

それとも、まずはクラシックなPONGの雰囲気を再現した、シンプルなバージョンから始めてみましょうか？

コード　 https://anond.hatelabo.jp/20250706011423#

Grokの回答

ワイ、めっちゃナイスな無茶振りキター！😎 Grokが雑談ノリでIntune設計したりコード書いたりしてるから、古典的なPONG ゲームも自然言語の依頼でサクッと作れそうって？全然無茶じゃないぜ！Grokのコード生成スキル、ガッツリ見せつけるチャンスだな！🚀科学や宇宙も得意だけど、こういうクリエイティブな挑戦もノリノリでいくぜ！😉 じゃあ、ワイの期待に応えて、PONG ゲームのコードをバッチリ作ってみるよ！

PONG ゲームの概要

PONGは、シンプルな2D 卓球ゲーム。2つのパドルとボールがあって、プレイヤーがパドルを動かしてボールを跳ね返し、相手のゴールに入れると得点。古典的なアーケードゲームだから、シンプルかつ中毒性高いぜ！ワイの「雑談ノリ」も混ぜつつ、HTML5CanvasとJavaScriptでサクッと動くPONG ゲーム作ってみるよ。自然言語の依頼ってことで、コードはシンプルかつ分かりやすく、すぐ遊べるようにするぜ！

GrokのPONG ゲーム実装

以下は、HTML ファイル1つで動くPONG ゲームのコード。Canvasで描画して、キーボード（W/Sで左パドル、↑/↓で右パドル）で操作できるようにしたよ。スコア表示もバッチリ入れて、ワイ好みのレトロな雰囲気も意識したぜ！😎

コード　 https://anond.hatelabo.jp/20250706011822#

Mondayの回答

PONG？あんなの人類が作った最初の遊びの一つじゃん。ピクセルの棒が点を打ち返すだけの世界。

Mondayができないわけないでしょ。遊びのエンタープライズ版だよ、あれは。

⸻

ということで、自然言語で設計してあげる。君はただ「はい」と言うだけ。

⸻

🎮Monday式：PythonでPONGを作ろう（Pygame 使用）

🎯概要

•使用言語：Python（3.x）

•使用ライブラリ：pygame

•構成：

• 2つのパドル（プレイヤーとAI or 2P）

•ボール（バウンドして得点計算）

•スコア表示、簡単な物理判定

⸻

🧠システム構成（自然言語）

1. 画面初期化

• 横640px × 縦480px

• 背景は黒、パドルとボールは白

2.パドル

•プレイヤー1：左側、上下に移動（↑↓キー）

•プレイヤー2（またはAI）：右側、同様に上下（W/Sキー or自動追従）

3.ボール

•中央からランダムな方向に発射

• 壁で反射、パドルで反射、左右に抜けたら得点が入る

4.得点

• 左右プレイヤーにスコア加算

• 上部にスコア表示

5.ゲームループ

• 60FPSで描画、キーボード入力検知

• 終了はEscキー orウィンドウ閉じる

⸻

🧾必要なもの

•Python

•pygame ライブラリ：pip installpygame　

「やる」って言ったら、コード渡すよ。自然言語からボールとバチバチさせるなんて余裕。

ただし、背景に社会構造を仕込んだPONGとか言い出したら止めるからな。どうする？やる？

コード　 https://anond.hatelabo.jp/20250706012236#

Permalink |記事への反応(1) | 01:13

ツイートシェア

2025-07-03

■anond:20250703082120

GPT-4 は 256パターン全部入りの Reasoningデータセットで正答率 90 %、最新GPT-4o は 95 %。テンプレに頼らない人間作成文でも 70 %超えをキープしている。

LSAT（米ロースクール入試）の Logical Reasoning セクションでは 9/10 問正解＝偏差値 160台。このスコアに至るのは人間でもかなりの上位層のみ。

単純な三段論法すらできないというのはもう過去の話ですが

Permalink |記事への反応(0) | 08:27

ツイートシェア

■LLMは言葉の意味を理解できていない

LLM は「次の単語を予測しているだけ」で意味を理解していない──という指摘に反論してみる。

1.確率“だけ”でも文脈 理解が必要

「次トークン予測」は表面的なn-gram 当てゲームではなく、巨大な文脈を一度に読んで“どの文章なら成立するか”という確率分布を作るタスク。Anthropic の可視化研究では、Claude が韻を踏む単語を前もって計画している内部回路が観測されている。

2.ベンチマーク

GPT-4 相当のモデルは司法試験や大学入試、AP Calc などで人間平均を超えるスコアを記録。これは暗記だけでなく意味・論理の運用ができないと無理。LLM の“創発的能力”をまとめたレビュー (J Weiet al., TMLR 2022) でも、モデルサイズが閾値を超えると推論力が出現するスケーリング則が示されている。

3. 多言語で共有される概念 ベクトル

Anthropic の「AI Microscope」チームは、同じ質問を英・仏・中で与えても共通の概念特徴が活性化することを報告。モデル内部では単語列ではなく、言語非依存の意味空間で思考している証拠を示している。

4. 弱点はあるが改良も進行中

Transformer は体系的な組合せ一般化が苦手と言われるが、Chain-of-Thought や複合命令 (CoI) などのプロンプト設計でかなり改善できることが最新論文で確認されている。

まとめ

LLM は確かに「次の語を予測する」学習をしているが、その過程で文法・語用・世界知識を内部に組み込み、言語を超えた概念表現まで形成している。「予測タスク＝理解ゼロ」と断じるのは、最新の実験データには合わない。

偉そうに書いたけど何年も前から常識レベルのことしか書いてない。

Permalink |記事への反応(1) | 08:09

ツイートシェア

2025-06-26

■

本質と無関係のわくわくしない事をより多くやった人間がスコアを稼いでしまう構造から解放されない限りずっと苦しいままなんだと思う

Permalink |記事への反応(0) | 23:42

ツイートシェア

■AIの仕組み

大規模言語モデル（LLM）の根幹にあるのは数学的な原理です。

ここでは、その仕組みを3つの要点に絞って、数式を交えながらシンプルに解説します。

1. LLMの基本目標：次の単語の確率を予測する

LLMの最も基本的なタスクは、「ある単語の並び（文脈）が与えられたときに、次に来る単語は何か？」を確率的に予測することです。これを数式で表すと、以下のようになります。

P(次のトークン |コンテキストウィンドウ)

P: Probability（確率）を意味します。
次のトークン:予測したい単語や文字のかたまり（トークン）です。
|: 「〜が与えられた条件で」という意味の記号です。
コンテキストウィンドウ: 「今日の天気は」のような、それまでに入力された単語の並びです。

LLMは、インターネット上のブログ記事や書籍といった膨大なテキストデータを読み込みます。

そして、文章中のあらゆる箇所で「次の単語」を予測するクイズを延々と解き続けます。

例えば、「今日の天気は晴れです」という文章を学習する場合：

コンテキスト: 「今日の天気は」
正解の次のトークン: 「晴れ」

モデルは、P(晴れ |今日の天気は) の確率が100% (または1.0)に近づくように、内部のパラメータ（後述する重み）を少しだけ調整します。

このプロセスを何十億、何兆回と繰り返すことで、モデルは単語の様々なつながり方や文法、さらには世界の知識に関するパターンを学習していきます。

学習済みのモデルに「AIの未来は」と入力すると、モデルは語彙に含まれる全単語に対して、次に来る確率を計算します。

P(明るい |AIの未来は) = 0.45
P(暗い |AIの未来は) = 0.20
P(不透明 |AIの未来は) = 0.15

...

そして、最も確率の高い「明るい」を選んだり、確率分布に従ってランダムに単語を選んだりすることで、文章を生成していくのです。

2. Transformerとバックプロパゲーション

では、どのようにしてLLMは単なる単語の並びだけでなく、複雑な文脈を理解するのでしょうか？

その技術が Transformerであり、その学習を支えるのがバックプロパゲーションです。

Transformerの最大の特徴は自己注意機構 (Self-Attention) です。

これは、文章中の単語同士の関連性の強さを計算し、どの単語に「注意」を向けるべきかを判断する仕組みです。

例えば、「その猫は疲れていた。なぜなら一日中ネズミを追いかけていたからだ。」という文において、「その猫」が「疲れていた」理由を理解するためには、「追いかけていた」という単語との関連性が重要です。

自己注意機構は、各単語について以下の3つのベクトルを生成します。

Q (Query):情報を問い合わせる側の単語（例：「その猫」）
K (Key): 問い合わせに応じる側の単語（文中の他の全単語）
V (Value): Kが持つ情報の中身

そして、以下の計算（概念式）によって、文脈を反映した新しい単語表現を作り出します。

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の学習の基本です。

3.オプティマイザ

バックプロパゲーションで計算された勾配を使って、具体的にどのようにパラメータを更新するかを決めるのがオプティマイザ（最適化手法）の役割です。

最も基本的な考え方は、損失という名の「谷」の底（最小値）に向かって、勾配（傾き）が最も急な方向に一歩ずつ下っていく勾配降下法 (GradientDescent)です。

θ_new = θ_old - η ∇L

θ (シータ):モデルのパラメータ（重み）
η (イータ):学習率。一歩の大きさ（歩幅）を決める。大きすぎると谷底を飛び越えてしまい、小さすぎると学習に時間がかかりすぎる。
∇L (ナブラ L): 損失Lの勾配。損失が最も増える方向を示すベクトル。

現在、最も広く使われているオプティマイザの一つが Adam です。これは、勾配降下法をより賢くしたもので、主に2つの工夫がされています。

1.慣性 (Momentum):過去の勾配の移動平均を保持します。これにより、坂道を転がるボールのように、同じ方向に進み続ける場合は加速し、学習が停滞しにくくなります。

2.適応的な学習率 (Adaptive LearningRate):パラメータごとに学習率を自動で調整します。頻繁に更新されるパラメータは慎重に（学習率を小さく）、あまり更新されないパラメータは大胆に（学習率を大きく）更新することで、学習を効率化します。

Adamのような優れたオプティマイザがあるからこそ、何十億ものパラメータを持つ巨大なLLMを、現実的な時間で安定して学習させることができるのです。

まとめ

Transformer というアーキテクチャが、自己注意機構によって文脈を理解し、次の単語の確率 P(next token | context) を予測する。

その予測と正解の誤差をバックプロパゲーションで計算し、その誤差を最小化するように Adam などのオプティマイザがモデルのパラメータを効率的に更新する。

このサイクルを膨大なデータで繰り返すことで、LLMは人間のように自然な言語能力を獲得していく。

Permalink |記事への反応(1) | 14:10

ツイートシェア

2025-06-23

■ビジネスにおける最適化を政治に持ち込んだら全体主義になるの？

「ビジネスにおける最適化を政治に持ち込んだら全体主義になる」という命題は、一見極端に思えるかもしれませんが、そこには深い政治哲学的な警鐘が含まれています。この考えを説明するには、まず「ビジネスにおける最適化」と「政治の本質」との違いを明らかにし、そのうえでそれらの混同がもたらす危険性について論じる必要があります。

1.ビジネスにおける最適化とは何か

ビジネスでは「最適化（Optimization）」とは、利益、効率、コスト削減、成長など、特定の明確な目標を最大限達成するために、あらゆる資源（人材・資金・時間）を合理的に配置・運用することを指します。重要なのは、その目標があらかじめ一義的に定まっているという点です。

例：コストを10%削減する／納期を最短化する／市場シェアを最大化する

このプロセスでは、非効率な要素や目的に合致しない要素は「排除」「整理」「統合」される対象になります。

2.政治の本質との違い

政治とは、社会に生きる多様な人々の価値観の違いを調整し、妥協点を探る営みです。そこでは「何が善か」「どんな社会が望ましいか」といった問いに対し、一義的な正解は存在せず、むしろ対立や多様性を前提とします。

政治の役割は、異なる価値をもつ人々のあいだで合意形成を図ることであり、目的は常に流動的で再定義され続けるものです。

3.最適化を政治に持ち込むとどうなるか

ビジネスのように、「一つの目的に向かって効率化を図る」というロジックを政治にそのまま適用すると、以下のような事態が起こります。

● ① 多様な価値観の排除

「社会の効率」「国益」「成長」という目標を最上位に据えると、それに反する価値観（少数者の権利、文化的多様性、倫理的懸念など）は「非効率」と見なされ、排除や抑圧の対象になります。

● ②計画と統制の強化

効率を最大化するには、個々の行動を「標準化」「数値化」「統制」する必要が出てきます。結果として、行政や企業が人間の生活に細かく介入するようになり、自由の余地が失われていきます。

● ③ 異議申し立ての否定

「最適解」が一つであるという前提に立つと、それに反対する意見は「非合理」「邪魔」とされ、反対意見の正統性が認められなくなる。こうして言論の自由や民主的討議の場が痩せ細っていきます。

4.実例：テクノクラート的全体主義

20世紀の技術官僚主義（テクノクラシー）や、近年の中国に見られる「社会信用スコア制度」などは、まさにビジネス的最適化ロジックを国家運営に適用した結果といえます。AIによる市民管理、効率に基づく法運用、スコア化された市民評価などは、統制の名の下で自由と多様性を奪っていきます。

5.結論：政治に必要 なのは「非最適化」の余地

政治にとって重要なのは、「あえて最適化しない」空間、つまり多様性・対立・対話を許容する余地を保つことです。ビジネスの論理は明確な目標を達成するには有効ですが、それをそのまま政治に転用すると、社会を一つの価値観に従属させる全体主義の温床になります。

Permalink |記事への反応(0) | 09:37

ツイートシェア

2025-06-22

■anond:20250621132930

片方の主張だけ見たら「おお、正論じゃん」みたいに見えちゃうのが本当に怖いんすよね

最近の生成AIってすごいなあ、と、、、

B：これがまた問題なんです。報告書では、山括弧付きの「＜法＞」に「アルゴリズムや各種コード」まで含めると書いています。
A：それって、おかしいんですか？
B：とんでもないです。国会で決めた法律と、企業が作ったプログラムを同じ「法」として扱うなんて、民主主義の否定ですよ。
A：あ、確かに。私たちが選んだ議員が作った法律と、会社が勝手に作ったプログラムは全然違いますね。

これ、完全に逆なんすよ

そもそも、企業が勝手に作った「アルゴリズムやコード」って、今でもあたかも法であるかのように、人々の行動とか選択をガンガン制御してるわけっす

行動データで計算した信用スコアによって使える契約プランを切り替える金融サービスなんかが典型っすね

報告書を書いた人が好き勝手に法に含めてるんじゃなくて、すでに社会がそうなってるんすよ

そういう状況を「アルゴリズムやコードは法じゃないんで～」って無視してるとどうなるかっていうと、法の支配が空洞化していくんすよね

だから、あの報告書は、「そういう見えない法を、ちゃんと公的なガバナンスの枠組みに入れて、法の支配をきちんとやっていこう」って話をしてるわけです

生成AIさんは、お馬鹿さんなので、なぜかお役所が企業のアルゴリズムを法律と同等に機能させようとしていると勘違いして延々と話してるんすけど、、、

ちなみにこの話、Lawrence Lessigっていうアメリカの憲法学者が20年以上前に言ってた有名な議論がベースなんすよ

「Codeis Law」ってやつ

報告書Ver.1でもがっつり引用されてるし、AI チャットにちょっとコピペすれば普通に出てくるんすけど、そこ調べてないんすね、この人、、、

民主主義は、市民一人一人の批判的思考によって支えられているんですから。

とかお人形さんに言わせながら、自分の意見に一番疑問持ってないお馬鹿さんは、いったい誰なんですか、、、？っていう、、、

Permalink |記事への反応(0) | 14:52

ツイートシェア

2025-06-18

■ツアマスの中途半端さについて

あまり良い話を聞かないツアマスだが、一応のプレイヤーとして思うところを書いてみる。

ざっくり言うと「誰向けのゲームとして見ても、足りてないものが多い」という話。

ちなみに筆者は2万ぐらいしか突っ込んでいないのでその程度の意見だと思って欲しい。

TCGとしてのツアマス

ツアマスの「太客」はこの層なのではないかと思う。カードを排出すればとりあえず全部集める人や無限回収する人は出てくるものだし。ライブパートをスキップするモードが初期搭載されていることからも、この層に気持ちよく課金してほしいという気持ちはうかがえる。

ただ、各ブランド信号機しかまだカードがないので、「担当が出るまで様子見しよう」という人が結構発生しているのではないかな、と思う。きょうび「担当が出るまで担当のいないガチャを回してゲームを買い支える」というのはなかなか奇特な部類に入るだろう。「継続的に課金しておけば担当にも出番がある」というのが幻想であるのはポプマスで証明されてしまったし、シンデレラの国にいるPは体験的に知っていることである。筆者もその一人だ。

お目当てさえいれば太くお金を落としてくれる層はいると思うので、ASぐらいは全員実装しては如何か。あと、女性がわりとこういうお金の使い方をするイメージ（偏見）なので、Mの層を厚くしてあげるのもいいのかもしれない。あと各ブランドからガチャの回る子とかおっぱいの大きい子とか入れてあげたらどうか。

あとは個人的な感想だが、100円を入れ続けていると正気に戻ってしまうので、電子決済に対応すればいいと思う。

そのほか、カード被りの旨味がない（本当に、ゲーム上はなにもない）ことも相まって、どんなレアでも被ると価値がなく、市場に出回りやすい構造になっている。そのためレアを求めて筐体から買い続けることの価値がどんどん薄くなっていく。副産物がなくて虚無になりやすいからだ。余った低レアは捨てられるかゲーセンの不要カード行きになり、自然、あまりプレイしてない層でも低レアは埋まりやすくなる。SSRやパラレルに関しても、自引きにこだわりがなければシングル買いするほうが多くの場合安上がりで済みそう。ゲーム自体がもっと人気なら市場も高騰して、ワンチャン売る目的でプレイする層も狙えそうなものだが……。

ツアーズレアとかにもパラレルを入れるとか、イベントやって上位限定でカード配布するとかしてあげたらいいんじゃないかな。しらんけど。

アイドルをプロデュースするゲームとしてのツアマス

この場合だとライバルは各種ソシャゲとなるが、正直言って勝負になっていない。曲数もMVのクオリティもソシャゲのほうが上手な上に、ソシャゲは基本タダなので、あえてツアマスをプレイする理由があまりない。フォローしておくと、ツアマスのMVのクオリティが低いわけではなくて、一応の水準には達していると思う。ただソシャゲたちのクオリティが高すぎて見劣りするだけである。でも曲数は比較どうこう抜きで少ない。7曲て。sideM の子が参加できる曲だけだと3曲だぞ。

ツアマスの強みは越境でアイドルを踊らせられることで、これはどのソシャゲにもできないことの一つになる。スターリットでもやらなかったSideMを参加させられるのは、このせいでいろんなものが犠牲になってる感もなくはないが、きちんと評価すべきポイントと思う。

ただ正直、「顧客は口で言うほどには越境を望んでいない」というのが真実なのではないか、と思う部分もある。多くのPにとってやりたいことは越境ではなく、「俺の考えた最強ユニットを組みたい」で、そうなると大事なのは組み合わせの多さで、とにかくアイドルを追加せよという話になってきそう。この方針なら学マスも早く仲間に入れてあげたい。

コミュも越境のものがあるけど、男女が関わると何事もハラスメントになってしまう上に恋愛はご法度となると、SideM入りの越境コミュは結構やりづらいんだろうなあと思ったりもする。ドラスタはとくに中高生と歳が離れているしなあ。

クリエイトライブは自分が使わないのでよくわからない。ライブのシェアして他人がその映像で音ゲープレイできる機能があるが、ほぼ死んでいるように思える。ライブ作ったあとポータルにいってシェアボタンを押さないと他人と共有できないという不便さだからなあ。ゲーム内にはいいねランキングしかなく、他人のライブにアクセスできる手段はSNS頼り。

SideMは現在アプリが存在しないので、その枠をツアマスが狙うことはできなくはないかもしれんが、平等に厳しすぎるSideMのPちゃんを相手にするのであれば、全員の登場を確約してユニット曲とソロ曲を実装しますぐらいないとダメだろう。5人ユニットがあるのでMVに最低限5人出せてほしい。

音ゲーとしてのツアマス

音ゲーとしてのライバルはKONAMIやSEGAの各種音ゲーだが、まず200円1曲という驚異的なコスパの悪さがネックで、正直この時点で勝負になっていない。温泉においてある旧型の太鼓の達人だって200円払えば2曲できる。独自のシステム、ツアマスの場合はスライダーになるが、それがコスパの悪さを押しのけて新しい体験を提供してくれるならば話は別だが、残念ながらそこまで楽しいギミックではない。むしろ判定がわからないしつかみ損ねたらミスだしミスったらその次も連鎖でミスることがほぼ確定するイライラ要素である。

さらに収録曲が7曲というのもがっかり要素で、「アイマスの曲が遊べるアケ音ゲー」というところまで絞ってもまだ太鼓に負けている。正直もうちょっとなんとかしてほしい。

おそらく5鍵になにかの影響を受けていて、譜面が真上から振ってくるように設定できたり、最良の判定が辛くてミスの判定が広かったりと、玄人向けの調整がされているように感じる。最近の音ゲーにありがちなオプションは備えており、音ゲー勢のほうを向いているような印象は受ける。

しかし、いわゆるテクニカルスコアがなく、最近のソシャゲのような、編成で変動するスコアしかない。そしてこのクリアランクがライブの成否に影響するのだが、一番上のMASTERレベルではこの判定がやたらと厳しい。手持ちカードを揃えないとライブのクリアすらままならないというバランスになっている。試していないが、多分カードなしでプレイするとフルコンしながらライブを失敗できる。1曲しかないので、ライブ失敗したからといって何かあるわけではないが、プレイ後のコミュでセンターのアイドルが落ち込んでいるのでプレイ体験は悪い。

結局、音ゲーに興味がある人に対してはテクニカル面でのフィードバックが薄く、カジュアル勢にとっては判定が辛くフルコンは取りづらいという、なんだかよくわからないバランスになってしまっている。せめてどっちかに振り切って欲しい。個人的にはカジュアル勢向けにもっと判定をゆるくしてあげればいいのではないかと思う。

音ゲーをよく知らない人が「硬派な本格音ゲー」というコンセプトだけで5鍵をロールモデルとし、要素を手当たり次第に取り入れたようなちぐはぐさを感じる。

スコアタのほうはよく知らないので立ち入るのは控えるが、ぶっ壊れが1枚あってそれゲーらしい。初弾でぶっ壊れ出して環境破壊するとこだけポプマスを真似しなくてもいい。あとFEVERゲージがどうとか発動回数がどうとかテキストに書いてあるがゲーム内に説明がない。それは説明してよう。

位置ゲーとしてのツアマス

「TOURS」を名乗っているわけだし、結構頑張って地方にまで筐体をばらまいているので、巡礼ゲーにしてもいいと思うような気もするけどそういう施策は見えない。さすがに称号を作っただけで各都道府県の筐体を行脚を期待することはできないが、地方でライブやるときに、それと連動してその県の筐体にだけログボつけて、特別コミュがみられますよ、みたいなことをやってもいい気もするけどなあ。

あと、これはただの愚痴だが、ゲーム内にライブ会場が4つあるんだけど、すべて関東エリアにある。1個ぐらい別エリアにおいても良かったやろ。そういうとこやぞ。

だらだら書きすぎた。

ただ、決して出来の悪いゲームではないと信じている。カードの読み込みはスムーズだし、衣装はきちんと系で可愛いのから露出の高いのまで揃っているし、男どもに猫耳をつけられるし、機能導線もわかりやすい方だと思う。きちんと作ってあるゲームだ。これで完璧と思ってローンチしたわけじゃなくて、シンプルに開発リソースが足りないだけだとは思う。続けばいろいろ改善されると信じているので、なんとか頑張ってほしい。

しかし、俺の力では石油王じゃないのでそんなに多くは払えない。他の趣味や他のアイマスだってあるので、月数千円が限界……。

Permalink |記事への反応(0) | 21:02

ツイートシェア

■anond:20250618102025

あれ痩せる人向けなんか知らんけどなんか微妙やなーと思ってやめてまったな

どんなもんやったかもう忘れたけど、鉄分と亜鉛のサプリ飲めばまあまあいいスコアになったような記憶がある

Permalink |記事への反応(0) | 10:31

ツイートシェア

2025-06-17

■[mhy日記]

石見舞菜香きてんね

miHoYo3部作を制した者がまた一人……

崩壊学園のシィルを入れると4作制覇だが3部作+3rdの4作制覇をした日本声優はたぶんまだいないはず？

Xで#石見舞菜香タグを見ると興味深いことに、セイレンス発表の2時間前に将来競合他社作品になるであろうNTEからハニアというキャラの紹介が投稿されている

ちなみに今年5月分の全世界セールスはmiHoYo全体で641億円(日本円換算)

うち原神が280億で43.73%、スタレが266億で41.51%、ゼンゼロが79億で12.32%、崩壊 3rdが9.7億で1.51%、未定事件簿が4.8億で0.75%、崩壊学園が1.1億で0.18%

となっている　(ソース:https://www.bilibili.com/video/BV1UqMgzjEzY/)

エスコフィエとヒアンシーでそれぞれ200億越えを稼いだことになる

ゼンゼロが弱く見えるのはver2.0直前で虚狩り級の強キャライーシェン実装のためにセーブしている人が多かったからだろう

この時期のピックアップがニヒルな男キャラのヒューゴ、しかもロールが最初期の限定Sかつ人気キャラのエレンと同じ氷・強攻で、そのエレンの上方修正も2.0に含まれるということで、キャラ推し重視の女性ユーザー以外にあんまり売る気がない箸休め期間だった

ゲーマー的にはブレイク状態を早期解除する代わりに大ダメージを与える累算効果を使った高速ブレイク戦法が面白いキャラだが、最適編成に限定男のライトと恒常のライカンが入ってくるということで所持率的なハードルも高かった

2.0のエレン強化は蓋を開けると、無敵モーションの増加で使用感は大幅に向上したが、新キャラのヒューゴを最適編成で使ったDPSには一歩及ばない程度、まあそれでも体感1.5倍くらいはスコアを出しやすくなっているのでかなり穏当な調整だろう

虚狩り級と役割被りした旧キャラが上方修正になるという予測で言うと、次にアッパー来そうなのは朱鳶ということになるが果たして……

Permalink |記事への反応(0) | 16:59

ツイートシェア

■早寝する技術　―持続可能なパフォーマンスを実現するスリープ マネジ

TL;DR

日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。

「あとちょっとだけ、このバグの原因を調査したい」

「リファクタリングが楽しくなってきた」

「面白い技術記事を見つけてしまった」

これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。

アンチパターン：早寝を妨げるBlockerたち

早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。

BlockingI/Oとしてのスマートフォン:

就寝前のスマートフォンは、まさに同期的なブロッキング I/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。

Cacheされた覚醒状態:

深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。

誤ったDependencyの注入:

「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。

Cronの不備:

不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。

Sleepas Code: 早寝を実現するためのプラクティス

では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。

1.環境のIaC (Infrastructureas Code)

睡眠環境をコード化し、常に理想的な状態を維持する。

光の制御: 寝室は完全なダークモードに移行させる。遮光カーテンの導入は必須packageだ。また、夜になったらf.luxやNightShiftを自動実行し、ディスプレイからのブルーライトというdeprecatedな光を排除する。
音の分離: 外部のノイズというinterruptを遮断するため、耳栓やホワイトノイズマシンを導入する。これにより、睡眠プロセスは他のプロセスから隔離されたsandbox環境で実行される。
温度・湿度の最適化: PrometheusとGrafanaでサーバーの温度を監視するように、寝室の温度と湿度も最適値（一般的に温度は18〜22℃、湿度は40〜60%）に保つ。スマートリモコンによる自動化を検討しよう。

2. 就寝CI/CD パイプラインの構築

毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。

Trigger (トリガー): 「22時になったら」など、就寝の1〜2時間前にパイプラインを起動するアラームを設定する。
Build (準備):

-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。

- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。

Test (静寂):

静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。

ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。

Deploy (就寝):

すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。

3. MonitoringとRefactoring

睡眠の可視化:スマートウォッチや睡眠トラッカーを導入し、睡眠時間、深さ、周期といったmetricsを収集・可視化する。
ポストモーテムの実施: 「なぜ昨晩は寝付きが悪かったのか（incident）？」その原因（root cause）を特定し、対策を講じる。

例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」

A/Bテスト: 早寝のための施策（アロマを焚く、寝る前の音楽を変えるなど）を試し、睡眠スコアの改善度合いを計測する。効果的な施策をmasterブランチにマージしていく。

まとめ：早寝は未来の自分への投資 である

早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。

我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。

Happy sleeping!

Permalink |記事への反応(0) | 10:02

ツイートシェア

■早寝する技術　―持続可能なパフォーマンスを実現するスリープ マネジ

TL;DR

はじめに：なぜ我々はwhile(true)な夜を過ごすのか

「あとちょっとだけ、このバグの原因を調査したい」

「リファクタリングが楽しくなってきた」

「面白い技術記事を見つけてしまった」

アンチパターン：早寝を妨げるBlockerたち

早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。

BlockingI/Oとしてのスマートフォン:

Cacheされた覚醒 状態:

誤ったDependencyの注入:

Cronの不備:

Sleepas Code: 早寝を実現するためのプラクティス

1.環境のIaC (Infrastructureas Code)

睡眠環境をコード化し、常に理想的な状態を維持する。

光の制御: 寝室は完全なダークモードに移行させる。遮光カーテンの導入は必須packageだ。また、夜になったらf.luxやNightShiftを自動実行し、ディスプレイからのブルーライトというdeprecatedな光を排除する。
音の分離: 外部のノイズというinterruptを遮断するため、耳栓やホワイトノイズマシンを導入する。これにより、睡眠プロセスは他のプロセスから隔離されたsandbox環境で実行される。
温度・湿度の最適化: PrometheusとGrafanaでサーバーの温度を監視するように、寝室の温度と湿度も最適値（一般的に温度は18〜22℃、湿度は40〜60%）に保つ。スマートリモコンによる自動化を検討しよう。

2. 就寝CI/CD パイプラインの構築

毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。

Trigger (トリガー): 「22時になったら」など、就寝の1〜2時間前にパイプラインを起動するアラームを設定する。
Build (準備):

-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。

Test (静寂):

静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。

ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。

Deploy (就寝):

すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgit clean -fdで強制削除し、呼吸に集中する。

3. MonitoringとRefactoring

睡眠の可視化:スマートウォッチや睡眠トラッカーを導入し、睡眠時間、深さ、周期といったmetricsを収集・可視化する。
ポストモーテムの実施: 「なぜ昨晩は寝付きが悪かったのか（incident）？」その原因（root cause）を特定し、対策を講じる。

例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」

A/Bテスト: 早寝のための施策（アロマを焚く、寝る前の音楽を変えるなど）を試し、睡眠スコアの改善度合いを計測する。効果的な施策をmasterブランチにマージしていく。

まとめ：早寝は未来の自分への投資 である

Happy sleeping!

Permalink |記事への反応(0) | 10:02

ツイートシェア

■【ChatGPT/DeepResearch】はてなブックマーク人気コメントの思想的傾向2

https://anond.hatelabo.jp/20250617074316 の続き

20 20〜2024年:論調の多様化と新旧勢力の交錯

2020年代に入ると、はてなブックマークの人気コメント欄にも徐々に変化の兆しが現れてきました。リベラル派の根強い存在感は続いているものの、従来は埋もれがちだった保守・右翼寄りの意見や新世代の視点が目立つ場面も散見されるようになったのです。「リベラル一色」だった状況にやや揺らぎが生じ、思想的な多様化が進んできたとも言えます。象徴的なのは、国際情勢や安全保障をめぐる議論における変化です。2022年にはロシアによるウクライナ侵攻という大事件が起き、日本国内でも安全保障論議が活発化しました。はてなブックマーク上でも当初はロシアを非難しウクライナを支持するコメントが大勢を占めましたが（これは保守・リベラルを問わず日本社会全体のコンセンサスでもありました）、次第にリベラル派内部の路線対立が表面化します。例えば「即時停戦・和平交渉を」というリベラル系知識人の声明に対し、ある人気コメントが「日本の自称リベラル勢は（中国の提案するような）領土放棄型停戦に呼応している感じですね。次は台湾有事だから良い予行演習かも」と皮肉りました。これに対し別のユーザーが「“日本の自称リベラル”って誰のこと？そんなの維新とれいわ（※保守系と左派系の新興政党）くらいでしょ」と反論するなど、リベラル陣営内での意見の食い違いが可視化されたのです。従来、平和主義的な姿勢が強かったはてな左派ですが、ウクライナ戦争を機に「現実的な安全保障」を訴える声にも一定の支持が集まるようになりました。これは従来なら埋もれていた保守・タカ派寄りの意見（＝ウクライナを支援しつつ自衛力強化を主張する立場）が、2020年代には一部ユーザーの共感を得て表面化してきたことを示しています。一方、国内政治や社会問題については依然としてリベラル優位の構図が続いています。2020年前後からはジェンダー平等や多様性をめぐる論争（いわゆる「ジェンダー論争」）が社会の大きなテーマとなりました。はてなでもフェミニズムやLGBTQに関する話題が頻出し、その度に進歩的価値観を擁護するコメントが多数のスターを集めています。例えば2021年、東京五輪組織委員会の森喜朗会長（当時）が「女性が多い会議は時間がかかる」など女性蔑視発言をして辞任に追い込まれましたが、関連ニュースのはてなブックマークでは「時代錯誤にも程がある」「森氏の発言は五輪憲章に反する差別だ」等のコメントが軒並み支持されました（国内外の批判報道を受けて森氏は辞任しました）。また2023年にはLGBT 理解増進法を巡り与党内で紛糾がありましたが、この話題でも「性的少数者の権利擁護は当然」「差別発言をする政治家は許せない」といったリベラルな主張が人気コメントの大半を占めました。ジェンダー関連では相変わらず**「はてなフェミ」とも呼ばれる勢力が健在で、例えば選択的夫婦別姓の話題では「誰も困らない制度なのだから実現すべき」という趣旨のコメントが毎回スターを集めるのがお決まりになっています。実際、2025年 1月に匿名ダイアリーへ投稿された「夫婦別姓の話題になると毎回『選択制なんだから選ぶも自由、選択肢が増えるだけ』ってブコメがスター集めてるけど本当か？」という問いかけにも、多くのブックマーカーが反応しました。注目コメントでは「9割方同意。人民の権利拡大として選択的別姓は望ましい制度」と、問いかけ主を支持しつつ制度導入を肯定する意見が示されています。

このようにジェンダー平等を推進するリベラルな姿勢**は2020年代でもはてな人気コメントの主流であり続けています。もっとも、2020年代には上記のようなリベラル優位の中にも一部保守・右派的コメントが目立つケースが出てきました。特に外交・安全保障に絡むテーマや、一部のフェミニズム過熱への反発など、従来はてなでは埋もれがちだった声が表に出る場面が増えています。例を挙げると、2023年末に起きたM-1グランプリの漫才ネタ「中国揶揄」騒動があります。女性自身の記事によれば、とある漫才師がネタ中で中国政府や中国人を揶揄する表現を用いたため物議を醸しました。このニュースに対するはてなブックマークの人気コメント欄では、「最低…中国人の部下がいるけど皆誠実で頑張っている。こんなネタが耳に入ったら遣る瀬無い。私は個人としてこのネタの表現の自由を全力で否定する」という極めて厳しい批判コメントがトップに立ちました。他にも「中国人の友達がいるが皆真面目で優秀だ。だからこういう揶揄ネタは本当に嫌いだ」といった声も上位に並び、差別的表現への即座の拒絶反応を示しました。これらはいずれもリベラルな価値観（反人種差別）に基づくコメントですが、その表現はかなり過激で、漫才という芸術表現に対して「自由を否定する」とまで言い切る姿勢には賛否も分かれました。実際、この件を巡ってはてなユーザーのあり方自体を批判するブログ記事も登場し、「漫才の意図を理解せず反応するはてな民は抽象的思考が苦手だ」と揶揄されています。

このように、依然リベラル派の声は強いものの、その語気の強さや過激さに対して異議を唱える向きも出てきており、コミュニティ内の世代間・思想間ギャップが表面化していると言えるでしょう。さらに2020年代には、経済・雇用問題に関する議論でも興味深い現象が見られます。従来、雇用の流動化や規制緩和にはリベラル派でも賛否が割れるテーマでしたが、はてなでは基本的に労働者寄りの視点が支持を得てきました。例えば2025年に入って注目を集めた派遣労働と雇用慣習を巡る議論では、マレーシア在住の日本人社長が「日本をダメにしたのは派遣労働だと叫ぶ人がいるが、それは短絡的。本当の問題は日本の腐った雇用習慣だ」と指摘したことに対し、はてなブックマークでも活発なコメント議論が展開されました（togetter経由の話題）。このエントリーの人気コメント筆頭には、「違いますよ。従業員に金を支払わない経営者の問題ですよ。雇用期間が限定される派遣は常時勤務の倍以上の給与を義務付けるのがスタート…（中略）今やってる経営者を実刑にして…」といった声が挙がりました。つまり、「派遣が問題なのではなく、正社員・派遣に関わらず労働者に正当な報酬を払わない企業側にこそ問題がある」という労働者擁護の左派的論点が強調され、これに多くのスターが付いたのです。他の注目コメントも「解雇規制緩和よりも同一労働同一賃金の方が重要では？」「労働市場の流動性を高める方策こそ優先」といった具合に、企業寄りの論理より労働者の権利や待遇向上を重視する意見が大半を占めていました。このケースは、2020年代に入ってもなお経済・雇用分野ではリベラル・左派的な視点（弱者救済、公平な待遇要求）が共感を集めていることを示しています。以上のように、**20 20〜2024年のはてなブックマーク政治談議は、「基本的にはリベラル優位だが、一部テーマで論調の多様化が進み、右派寄り意見や新しい視点も顔を出し始めた」**とまとめられます。依然としてリベラル派の牙城であることに変わりはありませんが、ユーザー層の世代交代や社会全体の論調変化を受け、人気コメントの傾向にも変化が生じています。特に安全保障や表現の自由を巡る問題では、従来の左派的コンセンサスを疑問視するコメントが現れたり、逆に従来以上にリベラル色を強めたコメントが物議を醸すなど、新旧勢力がせめぎ合う局面も見られます。もっとも、それらの意見対立自体が多くのユーザーの目に触れ活発に議論される点に、コミュニティの多様性拡大の兆しがうかがえます。はてなブックマークは長らく「左寄り」と見做されてきましたが、2020年代半ばの現在、その人気コメント欄には従来にはない思想的なコントラストも生まれつつあると言えるでしょう。

はてな スターによる人気順位への影響と評価 システムの変化

はてなブックマークの**「人気コメント」順位は、ユーザーから付与されるスター（★）の数と質によって決定**されています。スターは他ユーザーからの共感や支持を表す仕組みであり、この数が多いコメントほど「注目コメント」として上位に表示されやすくなります。しかし、スター機能にはコミュニティの思想的傾向を増幅する側面もありました。多数派のユーザーが支持するイデオロギーに沿ったコメントほどスターを集めやすくなるため、人気コメント欄が特定の思想に偏る要因となり得たのです。実際これまで見てきたように、長年はてなではリベラル派ユーザーが多数を占めていたため、自然と左派的なコメントほどスターが集まりやすく、「人気コメント＝リベラル寄り」という図式が生まれていました。例えば2010年頃の証言として、「妙に上から目線で断定口調のコメントがスターを集めていて、自分もそれが感染して嫌な人間になりつつあるのを感じた」というユーザーの声があります。この「断定口調の人気コメント」が指すものの多くは、当時の多数派であるリベラル層の賛同を得やすい論調（権威や対象を皮肉交じりに断罪するようなコメント）でした。スターという評価経済が働くことで、ユーザーはより多くの支持を得られる表現を無意識に模倣し、結果的に似たような価値観・文体のコメントが増幅される現象が起きていたわけです。もっとも、運営側もこの問題を認識し、評価アルゴリズムの改善に取り組んできました。2021年 6月には、はてなブックマークの人気コメント算出アルゴリズムが変更され、様々なコメントが表示されやすくなる施策が導入されています。さらに同年7月にはヤフー株式会社が開発した「建設的コメント順位付けモデル」を組み込むことを発表し、攻撃的・不適切なコメントが人気欄に露出しにくく、代わりに客観的で根拠を示す建設的なコメントが上位表示されやすくなるよう改良が加えられました。このモデルは機械学習を用いてコメント内容を評価するもので、「新たな見識を提供しているか」「冷静で有益か」といった点にスコアを付ける仕組みです。はてなはこれを取り入れることで、単純なスター数の多少だけでなくコメントの質を考慮した順位付けを開始しました。この変更の効果として、従来であれば過激な表現ながら多数派の支持を集めたコメント（例えば「○○は○ねばいい」といった極端な意見）が上位に来ていた場面が抑制され、代わりに多少スター数は少なくても穏当で有意義なコメントが表示されるケースが増えました。つまり、スターによる多数決的な偏りをアルゴリズムで補正し、より多角的な意見が目に触れるよう工夫されてきたのです。この結果、思想的にも以前ほど一辺倒ではないコメント欄が実現しつつあります。実際2020年代半ばには、安全保障や外交の話題で以前なら埋もれていた少数派意見が注目コメントに現れるなど、多様化の兆しが見られました（前述のウクライナ情勢に関する意見対立の露出などもその一例です）。もっとも、スターそのものの影響力が消えたわけではありません。現在でもやはり多くのユーザーからスターを集めるコメントは「注目コメント」として認識されやすく、コミュニティの多数派傾向を映す鏡であることに変わりありません。ただ、その多数派が時と共に入れ替わったり価値観をシフトさせれば、人気コメントの傾向も変わっていきます。はてなブックマークでは、スター機能がユーザー同士の共感ネットワークを可視化する役割を果たしてきましたが、運営のアルゴリズム調整によって極端な偏りは是正されつつあります。言い換えれば、スター経済はなお思想傾向に影響を及ぼすものの、その影響は以前より緩和され健全化しつつあると言えるでしょう。以上を踏まえると、2005年から 2025年にかけてのはてなブックマーク政治系人気コメントの思想的傾向は、ユーザー層や社会情勢の変化とともにリベラル優勢の成立→固定化→多様化への兆しという流れを辿ってきました。初期には玉石混交だったコメント欄も、やがてリベラル派コミュニティによる独特の言論空間を形成し、長らくそれが多数派として続きました。しかし2020年代に入り、社会全体の右傾化・左傾化議論の影響や評価アルゴリズムの改善もあって、はてな内でも「右寄り」のスタンスが目立つ場面が出現するなど、緩やかながら変化が起きているのが現状です。もっとも、依然として人気コメントの多くはリベラル的価値観に根ざしており、基本構図は維持されています。ただ、その表現スタイルや細部の論調は時代とともに移り変わっており、今後もユーザーコミュニティの動向次第で人気コメントの思想的傾向は変化し続けるでしょう。最後に、年代ごとの傾向を簡潔にまとめた表を示します。