2025年8月29日
2025/8/29 22:58:00
「寝ると問題が解決する」という特性から「朝をどれだけ増やすか」（プロジェクトをどれだけ並列で進めるか）みたいな観点もある。
プロジェクトをN個並列で進めて毎日全部着手すると、朝がN倍になるんですよ。
ICommandProducerとICommandConsumerとか書き始めて「メッセージキューだこれ」となってる。実装するより先に既製品をちゃんと見よう。
既製品のメッセージキューサービスを使うとしても依存はしたくないのでインターフェースは切ったほうがいいんだろうな。
「package by feature」って、ドメイン駆動設計の「境界付けられたコンテキスト」と近接した概念では？
レイヤーが違うので同じではない。でも近しいものがある。
予算と実績のデータ構造について前職にいた時から考えているのだけど未だ答えが見えずにいる。
WBSとかでもそうなんだけど、親の値が子から集計される性質があり、それをうまく扱うのが難しい。
初期の頃には浅い木でざっくりで出したい場合があるし、時が近づくにつれて深い木で詳細にしたい場合もあるし、具体的な予定が決まっている子を登録することもある。「T月にAの件で支払いがあるけど、T月についてはそれ以外は全く未定なので、全体としてはざっくり予算にしたい」といった具合。
「あの時に出した予算（見積工数）はどうだったっけ？」「予算の精度ってどう推移したの？」という関心も当然生じる。
予算と実績の紐付けもある。「支払いAについての予算」と「支払いAについての実績」が紐付いている（経理業務の消し込みのイメージ）と嬉しい。つまり、「見込まれたイベントが本当にあったのか？」が記録されたい。
予算と実績に差異があれば差異分析となるし、「見込まれたイベントがなかった」となれば「なぜなかったのか」ということを紐づけたくなる。
秋刀魚を食べた。
2025年の秋刀魚は脂がのっていて大きいらしいと聞いていたが、実物を見てもいつもとの違いはピンとは来てなかったのだけど、フライパンに入れたらはみ出して「これは初めてかもしれない」となった。実際のところデカかったのかはわからん。
層の冗長性と層同士の独立性を損失関数に追加したら、層交換可能なニューラルネットワークを作ることができるんだろうか。
もしかしてセルオートマトンについて述べている？
格子状のセルオートマトンではなく、グラフ状のセルオートマトン。
「すごい速度で作業ができているぞ」という感覚があっても、すごい速度で脱線してるだけで本筋はそれほど進んでなかったりする。
むしろ本筋から逃げて脱線しているからすごい速度になっていたりする。
殿！！作業がものすごい速度で脱線をはじめたでござる！！！！作業がものすごい速度で脱線をはじめたでござる！！！！止まらない…殿！！！聞いて欲しいでござる！！！みて欲しいでござる！！！作業がものすごい速度で…止まらないでござる！！！止まら
∧,,∧ ∧,,∧ ∧ (´・ω・) (・ω・｀) ∧∧ ( ´・ω) Ｕ) ( つと ﾉ(ω・｀) ｜ Ｕ ( ´・) (・｀ ) と ﾉ ｕ-ｕ （l ) ( ﾉu-ｕ `ｕ-ｕ' .`ｕ-u'
「体調悪いし本を読んでも進むまい」と思われたが、「では試してみようじゃないか」となったので本を読んでるけど、やっぱり頭に入ってこないな。
今回については上記の結果だったけど、次回はどうなるかはわからん。
日記書いてなかった。いや、書く必要とかないんだけど。
朝から本を読むのが最高に良い。朝は最も頭が冴えており、午後の100倍の集中力が出せる。つまり朝30分読書すれば、3000分読書したと同義。50時間だぞ。2日を生きてる。
冗談はさておき、ハチャメチャに難しい本を読み、前日には理解できなかった場所が理解できる。これは大いなる前進だということは疑う余地はなく、それだけでその日1日を有効活用できたという実感が得られる。それ以降のそれ以外は些事と切って捨てても良いんではないかという気分にすらなる。生活があるので切って捨ててはいけない。
Decoratorを使い回すために、共通のIRepositoryを作ろうとしていたんだけど（つまりIRepositoryに命令を出すための万能なパラメーターオブジェクトを作ろうとしていた）、executeメソッドを持つICommandを作って、それにDecoratorを着せればよさそうということに気づいた。
ずっとグネグネしてたやつがようやく収まった。
ただの関数オブジェクトじゃねっていう気がしなくもない。
うっ、executeコマンドに引数が欲しい。いや、コントラクターでパラメーターを渡せばいいはず。
『なぜ依存を注入するのか DIの原理・原則とパターン』に答えが書いてあった。引数の型として総称型を使えばよい。
Youtubeじゃなくて独自プラットフォーム作ってるの気になる。
気になる：
「スプレー」に引っ張られて「のどぬ～るスプレー」のような容器に入った高濃度コーヒーのイメージが惹起されている。
通常はスプレーからコーヒーをマグカップなどの容器へと散布した後に水で希釈するが、手軽さを最重視する高位のものはスプレーから口へ直接散布して摂取する（というイメージ）。
ここ最近は惰性でデライトをやっている。「デライトすげぇ」という気持ちもあるが、手元では「Webなどで良い記事を見つける」「良かった部分を抜き出す」をダラダラとやっている。そうしてそうやって惰性でやっているものが積み上がっているのを観ると「デライトすげぇ」という気持ちになる。
| 月 | 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | 9月 | 10月 | 11月 | 12月 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 目標歩数 | 5428 | 5662 | 5896 | 6130 | 6363 | 6597 | 6831 | 7065 | 7298 | 7532 | 7766 | 8000 |
| 実績歩数 | 6184 | 6152 | 7407 | 8078 | 9472 | 8410 |
architecture-beta
group pn(cloud)[Private Network]
group pb(cloud)[Public Network]
group sv(server)[Server] in pn
service iap(database)[Identity Aware Proxy] in pb
service idp(database)[IDP] in sv
service forgejo(database)[Forgejo] in sv
service coolify(database)[Coolify] in sv
service app(database)[App] in sv
iap:R -- L:idp
idp:R -- L:forgejo
idp:R -- L:coolify
forgejo:T -- B:coolify
coolify:T -- B: app
idp:R -- L: app
gpt-4o-2024-05-13は同一のseedを使用した場合でも，出力は決定的ではない5）ことに注意が必要
マジか。厳密な再現性がないじゃん。
公開されたモデルでも決定的にできないのかな。
『Advanced usage - OpenAI API』を読む感じではOpenAI側での設定に変更があると振る舞いが変わるっぽい？
LLM-as-a-Judge評価の安定性を検証
〜中略〜
実行ごとにHeron では約 1 ポイント，JVB-ItW では約 0.05 ポイントの変動が生じる
知りたかったやつだ。
これについてもTemparatureを0にし、Seedを固定してやっているのだろうか？そうだとしたら、設定の変更が否決定性のトリガーではなさそう？
1日中頭が終わっていた。
特に寝起きがひどい。
また、昼食を決められなくなってきている。1時間以上決められずにいるのは異常だ。
色々グダグダだったが、昼に図書館に行けたことは良かった。貸し出し登録をして、本を借りてきた。
頭の状態を調整するために、筋トレをするようにするか。
Transformerわかってない民としては、Transformerの図が理解の助けになりそうで助かる。
断片を流すはずのWord Pieceに徐々に「記事らしい」記事が増える。Opal上で自由にアウトライン・プロセッシングするうち断片が次々と結合・収束し、自然にそうなっていった。
なんかアウトライナーを久々に使いたくなってきた。長い文章を書きたくなっている。でも「文章を書くぞ」という感じでやるのはつらい。「自然にそうなっていった」をやりたい。
sudo docker run -it –rm –network hoge debian:stable bashでForgejo Runnerを試すためのコンテナを立てた。
このコンテナの上からクローンして、コミットして、プッシュした。
Forgejo Runnerのlabelをdockerにしていたら、Checkout codeで「Could not resolve host」とエラーが出てしまった。labelをtest-containerにしたらCheckout codeがエラーなく動くようになった。
Repository周りをきっちり作り込みたいけど車輪の再発明してる感じがすごくする。ライブラリを使ったほうがいいかも。でもライブラリに依存したくないかも。うまくライブラリを使いつつ依存しないようにするのが設計の腕の見せ所かも。ライブラリを探そう。クラス図を書こう。
Forgejo Runnerが動くようになったのでActionを動かしたみたわけだが、Docker上で動かしているために、Gitレポジトリからはremoteがlocalhostで繋がり、Runnerからはforgejoで繋がるようになっているので、Runnerがレポジトリを取得できなくて動かない。なので、開発用のコンテナを立てる必要がある。めんどい。
forgejo-runnerでプログラムを動かせるから、セキュリティのために、作成されたアカウントは許可がないと何もできないようにしてたんだけど、レポジトリを非公開にすればいいだけな気がしてきたな。そうすれば許可されていないユーザーは私が登録したrunnerを使うことはできない。
ゼッテリアで朝食。コーヒーで過激な便意。危なかった。
ケンタと見せかけてマクドと見せかけてサイゼで昼食。サイゼの方が安くつくまである。
パスタが夕食。スーパーでゴーヤを買ったので、ゴーヤのナポリタンにした。
ネチネチ作業をしていたらforgejo-runnerが動いた。だいぶ時間がかかった。明日動作確認する。
作文している。精神的につらいタイプの作文。着手してればそのうち慣れるだろう。
新規性のあることをやっていないので、日記は書かなくてもいいかなと思われたが、新規性にこだわる必要もないかもしれないということで書いた。たぶんこの程度の雑さで良い。
一旦Repositoryで動くようにはなったが、複数のRepositoryに同一のDecoratorを着せられるようにしたい。後々のことを考えると、今のうちにきっちり作りこみたい。
note.comの記事を見ると素人の私からすると専門性があるように見えるのだが、その運営者を調べてもどうもわからない。何かきな臭い。
記事の最後に掲載されてる最適化の管理表がすげーいいな。効果を後から誰でも確認できるし、やってる最中のモチベーション維持や現在地確認にもなりそうだ。
Google翻訳とDeepLにて翻訳の再現を試みたが、失敗に終わった。
おそらく中華圏の翻訳サービスを使う必要がある。
朝から内科の通院に行ってきた。幸いにも朝早くに目が覚めたので、早めに病院へ着くことができ、その時点ではすいていた。
前回の内科通院で「次回で」としていた栄養士との面談をした。なぜかパンパンの冷凍庫やアレルギー性の耳鳴りについて話が弾む。楽しいね。
いつもの内科の先生には手短にお小言をいただいて終わった。はい。
「ゆる○○学」系列の動画が常にレコメンドに出てくる。さすがに食傷という状態で、「興味なし」をつけているのだが、それでも出てくる。どんだけ金をつぎ込んでるんだ。
「チャンネルをおすすめに表示しない」はちょっと過剰なので、「1ヶ月間チャンネルをおすすめに表示しない」とかが欲しい。
レコメンドはどうしてもユーザーの意図通りにはならないのがちょっとしんどいな。
サーバーサイドでの処理をレポジトリに置き換えようとしていたが、バチクソに沼っているので、全部捨ててクライアントサイドでの処理をレポジトリに置き換えた方が良い気がしてきた。1回全部捨てることにはなるが。
サーバーサイドでもうちょっと頑張ることにした。
LLMの学習用途かと思ったら対人間の教育用途だった。
AIが無限に問題を生成できたら、人間も無限に学習できそう。
過去の研究では『Prologによる解法知識を用いた誤答解説文付き多肢選択問題の生成』とかもあるけど、文章を何も加工せずにLLMに処理させたら問題が出てくると、作成者にとってはかなり楽である。
難易度調整精度を最大化するために、DPOが使われている。DPO便利だ。
塩水飲んだら頭の倦怠感がパーッと晴れてきた。
自炊で塩分を控えてるつもりもないんだけど、どうも塩分不足になりやすい。
夏の間は、ご飯作るときにはもうちょっと塩を多めにするようにしよう。
自分の日記の文体に飽きた。
「○○をした。□□だった。」 毎回そんな調子だ。いい加減何らか変えていきたい。そういうわけで、今回は、よそ様のブログの構成をパクることで、自身の文章の引き出しを増やしつつ、気分転換を図る。
みなさん、調子はどうですか。私は引きこもりがたたって調子を崩しつつあります。
今日はリフレッシュの日としました。家にこもってPCで作業をし、家にこもってPCでSNSをしているので、だんだんPCを見るのが嫌になりつつあります。
たまには家から離れた時間を取ろうっていうことで、ドトールへ行ってきました。朝から。8時ぐらいに。そうすると混んでるんですね。平日の8時というのはどうも通勤の皆さんが出社前の憩いのひと時を過ごしているようで、席があまり良いところが残っていないという始末でした。
ダメだ、絶望的に文章が書けない。文章を書く脳が文体と密結合している。あと調子が悪いときに文章が書けるはずもない。やめだやめだ。また今度にする。おわり。
Claude Sonnet 4でDeep Researchにかけたら勝手に作られた言葉まみれだったテーマを、Claude Opus 4.1で改めてDeep Researchにかけたところ、存在しない単語は見られなくなっていた。記述が実在する資料に基づいているような印象を受ける。
Claude Sonnet 4の生成物
原本：https://claude.ai/public/artifacts/05e79969-86b7-4049-9349-a312d5ef73b7
アルフレッド・ノース・ホワイトヘッドのプロセス哲学は、従来の実体中心的なリレーショナルデータベース設計に対して根本的な代替案を提示し、動的プロセスと関係性を重視した新しいデータモデリングパラダイムへの道を開いている。この研究は、静的エンティティから時間的プロセスへの存在論的転換が、現代のデータベース設計にもたらす理論的・実践的含意を詳細に分析する。
ホワイトヘッドの哲学体系における実際的存在（actual entities）は、永続的実体ではなく瞬間的な経験の単位として定義される。各実際的存在は「プリヘンション」（他の存在体による把握・感受）を通じて過去のすべての存在と内的に関連し、「コンクレッセンス」（多が一となるプロセス）により新しい統一を創造する。この 「関係性の優位性」原理は、現実を孤立した個体の集合ではなく、相互依存的なプロセスのネットワークとして理解する。
従来のER/RDBモデルは、独立して存在する識別可能なエンティティと、それらの間の外的関係を前提とする。しかし、プロセス哲学的観点では、この実体的固定化は「具体性の誤配（fallacy of misplaced concreteness）」にあたる。ビジネス現実における顧客、商品、取引は、静的属性の集合ではなく、継続的な関係性とプロセスの中で意味を持つ動的存在である。
プロセス哲学的アプローチでは、データベースの基本単位を「事象」とし、各事象を一意の時空的発生として記録する。この理論的転換は、現代のEvent Sourcingパターンの哲学的基盤となる：
-- プロセス的実際存在の表現
CREATE TABLE actual_occasions (
occasion_id UUID PRIMARY KEY,
temporal_position TIMESTAMPTZ NOT NULL,
prehensions JSONB[], -- 他の実際存在への参照
subjective_form JSONB,
satisfaction JSONB, -- 統合された経験
causality_chain UUID[]
);
この設計では、追記専用（append-only）構造により、実際的存在の不可逆的な生成プロセスを表現し、過去の確定性と未来の潜在性を明確に区別する.
プロセス哲学における内的関係性は、従来の外部キー制約を超えた動的関係モデルを要求する：
-- 動的関係のプリヘンション的表現
CREATE TABLE prehensive_relations (
relation_id UUID PRIMARY KEY,
subject_occasion UUID NOT NULL,
object_occasion UUID NOT NULL,
prehension_type VARCHAR(50), -- 'physical' or 'conceptual'
subjective_form JSONB,
intensity DECIMAL(3,2),
temporal_context TSTZRANGE,
EXCLUDE USING GIST (
subject_occasion WITH =,
object_occasion WITH =,
temporal_context WITH &&
)
);
Wil van der Aalst（RWTH Aachen University）の研究により確立されたプロセスマイニング分野は、プロセス哲学的思考の実装化として理解できる。ProM Process Mining Platformは、実際の実行データから「真の」プロセスを発見するリアリスト的アプローチを採用し、実際的存在の観察可能な現象化を提供する。
Giancarlo Guizzardi（University of Twente）によるUnified Foundational Ontology (UFO)は、プロセス哲学の概念をコンピューティングドメインに適用した重要な成果である。UFO-Bイベント存在論は、時間的プロセスの形式的モデリングを可能にし、OntoUMLとして視覚的設計言語に実装されている。
Barry Smith（University at Buffalo）のBasic Formal Ontology (BFO)は、ISO/IEC 21838として国際標準化され、2024年に米国国防総省によって採用された。これらの研究は、哲学的厳密性と実装可能性の架橋において重要な役割を果たしている。
時系列データベース（TimescaleDB、InfluxDB）、グラフデータベース、イベントストリーミングプラットフォーム（Apache Kafka、EventStore）は、プロセス哲学的原理の技術的実現として解釈できる。特に、Event SourcingとCQRS（Command Query Responsibility Segregation）の組み合わせは、ホワイトヘッドの「生成の連続性」概念と直接対応する。
-- 双時間的実際存在テーブル
CREATE TABLE bitemporal_entities (
entity_id UUID,
attribute_name VARCHAR(100),
attribute_value JSONB,
valid_time_start TIMESTAMPTZ,
valid_time_end TIMESTAMPTZ,
transaction_time_start TIMESTAMPTZ DEFAULT NOW(),
transaction_time_end TIMESTAMPTZ,
creative_advance_vector UUID[], -- 創造的前進の追跡
PRIMARY KEY (entity_id, attribute_name, valid_time_start, transaction_time_start)
);
この設計は、ホワイトヘッドの時間概念における有効時間（実際的存在の客観的生成時間）とトランザクション時間（観察・記録時間）の区別を実装する。
従来の在庫テーブル設計は、商品の「在庫量」という静的属性を中心とするが、プロセス的アプローチでは「在庫プロセス」の連続的事象として捉える：
-- プロセス中心在庫管理
CREATE TABLE inventory_occasions (
occasion_id UUID PRIMARY KEY,
product_id UUID NOT NULL,
location_id UUID NOT NULL,
process_type VARCHAR(50), -- 'receiving', 'shipping', 'adjustment'
quantity_change INTEGER,
temporal_position TIMESTAMPTZ,
causal_factors JSONB, -- 需要変動、供給遅延等
process_satisfaction JSONB -- プロセス完了状態
);
-- 現在状態の投影（プロジェクション）
CREATE MATERIALIZED VIEW current_inventory_state AS
SELECT
product_id,
location_id,
SUM(quantity_change) as current_quantity,
MAX(temporal_position) as last_process_time,
jsonb_agg(process_type ORDER BY temporal_position) as process_history
FROM inventory_occasions
WHERE temporal_position <= NOW()
GROUP BY product_id, location_id;
この設計により、完全な監査証跡、任意時点での状態復元、需要予測のための履歴パターン分析が可能となる。
プロセス的データモデルは、内的関係性の完全実装により計算複雑性が増大する。時間範囲クエリの最適化には、PostgreSQLのGiSTインデックスやパーティショニング戦略が有効である：
-- 時間軸パーティショニング最適化
CREATE TABLE process_events_2024 PARTITION OF process_events
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- 空間時間複合インデックス
CREATE INDEX idx_spatiotemporal ON events
USING GIST (entity_id, temporal_range);
実体中心的レガシーシステムとの統合には、段階的移行戦略が必要である。Event Sourcingパターンでは、既存のCRUDシステムを「投影の一つ」として扱うことで、漸進的転換が可能となる。
プロセス的思考への転換は、開発チームの概念的パラダイムシフトを要求する。van der Aalstが指摘する「Event Sourcing モノリス」の反パターンを避けるには、ドメインエキスパートとの密接な協働と、継続的な教育投資が不可欠である。
従来の正規化理論は「更新異常の回避」を目標とするが、プロセス的観点では「変更の記録」こそが重要である。時間軸正規化（Temporal Normalization）の新しい原理として：
この拡張により、「データ冗長性の排除」から「プロセス断片化の回避」へのパラダイム転換が実現される。
プロセス哲学とデータベース設計の統合は、Multi-Model データベース、NewSQL技術、量子コンピューティングとの接続により、さらなる発展が期待される。特に、プロセス存在論とAI/機械学習の統合は、自然言語処理や知識グラフ構築において重要な役割を果たすであろう。
IoTデータストリーム、リアルタイム分析、分散システムにおける「プロセス的アイデンティティ」の概念は、従来のエンティティ識別子を超えた動的同一性理論の構築を要求する。
ホワイトヘッドのプロセス哲学は、単なる技術的改良ではなく、情報システムの存在論的基盤に関わるパラダイムシフトを提供する。静的エンティティから動的プロセスへ、外的関係から内的関係へ、存在から生成への転換は、変化し続けるビジネス現実をより正確に反映したデータモデルを可能にする。
現代のEvent Sourcing、時系列データベース、グラフデータベースの発展は、この哲学的転換の技術的実現として理解でき、理論と実践の豊かな対話を示している。ただし、実装複雑性と既存システムとの統合という現実的課題に対しては、段階的導入とハイブリッドアプローチが最も実用的な戦略となる。
プロセス的データモデリングの完全な実現は漸進的プロセスであり、組織の技術的成熟度とビジネス要件を慎重に評価した上で、既存の実体中心的アプローチとの共存と統合を図ることが成功の鍵となるであろう。
寝る前と起き抜け1発目でClaudeのレートリミットまでやっときたいな。
Claudeにデライトから調査すると良さそうな事項を抜き出してもらい、それについてDeep Researchをかけた。
こんな知的贅沢が許されるのか？IAとAIの融合の一つの体験している。空恐ろしくなる。
惜しむらくは、まあ、社会的成功などといったかたちではまだ成果が出ていないことだな。
この論文では「モデル拡張」手法を応用した「STEP」手法を用いて、LLMの事前学習時のGPUメモリーを削減している。
STEPを用いると、標準事前学習と比べて、最大メモリ要求量が368Mモデルで42.3%、680Mモデルで42.2%、1.2Bモデルで53.9%に削減できると報告されている。
安価なGPUでもLLMが学習できれば費用が低減できて嬉しい。消費電力を減らせれば費用低減できて嬉しいことに加えてエネルギー消費低減の点からSDGsへの貢献もできる。そういった意味で広範な意義がある研究。
個人的に手元のマシンのGPUが弱いのでこういう研究大好き。
モデルサイズが大きくなると削減率が高くなるような傾向があるんだろうか？
学習時間への影響はあるんだろうか？
「成果物の品質を上げるためにAIを使う」のは持続性がありそう。
コード生成で考えると、コードの量が増えるとAIはバカになるし、ビルド時間は増えるし、人間も読み切れなくなるし、バグが発生する領域も増える。
一方で、AIを使ってバグを減らせたり、設計を良くできたりすれば、AIはバカになりづらいし、ビルド時間は増えないし、変更が容易になるし、トラブルは減るし、人間も読みやすいし、利点が多い。
あと低品質・大量生産の方向は、すぐにレッドオーシャンになりそうで怖い。需要を食いつくす。
『Tak.（Word Piece）｜note』の数量的なところを集計してみている。文字数、スキの数、有料の文字数、日付が集計の対象にあたる。自分がnoteをやるときには参考にできるかもしれない。
こういった文章の質を無視した数値的な分析は無意味だという見方もできるが、まずは数値的なところから押さえにかかりたい。文章の質はコントロールできない。
Xで執筆、というところで膝を打った。素晴らしい宣伝、素晴らしい市場調査、断片的執筆の一実践。うちあわせCastでそれが紹介されているというのもまた良い。
年利を4%、相続税を55％、相続から死亡（1世代）までを20年とする。
1世代あたり21%の利益が出る。
生涯に必要な資金を2億円とする。
目減りしない原資について考える。
のxについて計算すると、
9.52億円欲しい！！！
あれにて「Ctrl+ダブルクリック」の振る舞いを「描き直す」ボタンの振る舞いと同じにする形で修正いただいた
知名のみを変更する方式から知名を変更した場合に、保存後に知名が元に戻ってしまうようです。
知名と本文の両方を編集する方では問題なく知名が編集できています。
Nintendo Switch 2は7.9インチの大画面ディスプレイでHDR対応、最大120Hzの可変リフレッシュレートを搭載しています。この高精細な画面でゲームをプレイすることで目への負担が増加し、ブルーライトカットメガネの購入が必要になります。メガネをかけることで集中力が向上し、プログラミング効率が20%アップします。
Joy-Con 2には新たに「Cボタン」を追加し、このボタンを押すと「ゲームチャット」機能が起動します。頻繁にCボタンを押す習慣により指の反射神経が鍛えられ、タイピング速度が向上します。ITエンジニアの副業時給は4000円台が相場ですが、タイピング速度向上により作業効率が上がり、実質時給が5000円相当になります。
Joy-Con 2は本体に装着する側面を下に向けて、机の上などで滑らせることでマウス操作が可能という特殊な操作により、手首の柔軟性が向上します。これにより腱鞘炎を予防でき、長時間のプログラミング作業が可能になり、副業時間を延長できます。
「ゲームチャット」では、離れた場所にいる最大12人のフレンドとゲームをプレイしながらチャットできます。この多人数コミュニケーション経験により、ITエンジニアの弱点とされる営業力が向上し、副業で年収325万円レベルの高単価案件を獲得しやすくなります。
「おすそわけ通信」では、ゲームソフトが無いNintendo Switch 2に対して、ゲームそのものを"おすそわけ"し、一緒にプレイできる機能があります。この分散型リソース共有システムからブロックチェーン技術のインスピレーションを得て、Web3関連の高収入案件に参入できます。
Nintendo Switch 2はドック接続で4K出力対応しているため、常に高画質な映像に触れることで美的センスが向上します。これによりUI/UXデザインの副業案件も受注できるようになり、エンジニア＋デザイナーの複合スキルで収入が倍増します。
別売カメラ「Nintendo Switch 2 カメラ」を本体に接続することで、自分の姿をゲーム画面に重ねて表示できます。この機能により自撮り習慣が身につき、SNS投稿が増加し、技術系インフルエンサーとして企業案件を獲得できます。
Nintendo Switch 2は、本体の厚みをNintendo Switchから変えることなく、7.9インチの大画面のディスプレイを搭載しています。この制約下での技術革新に感動したエンジニアが設計思想を深く学び、システムアーキテクトとして転身し、年収1000万円超の道筋が見えてきます。
以上の迂遠な因果関係により、49,980円のNintendo Switch 2購入が、最終的に年収2000万円レベルのITエンジニアへの転身を促す可能性があります。
つまり「Nintendo Switch 2を買えば、ITエンジニアの桶屋が儲かる」のです。
（注：これらは完全に無理やりなこじつけであり、実際の効果を保証するものではありません）
無理やりこじつけてみます。完全に机上の空論であることを前提に：
効用：年間15万円相当
最新ゲーム技術を体験することで、ゲーム業界への転職成功率が5%向上。ゲームエンジニアの平均年収600万円×5%＝30万円の期待値向上。2年で回収と仮定し年間15万円。
効用：年間8万円相当
Switch 2保有者として業界関係者との会話が弾み、紹介案件1件獲得。フリーランス案件月80万円×1ヶ月＝80万円を10年で分割。
効用：年間12万円相当
新Joy-ConのCボタンやゲームチャット機能を理解することで、UI/UX設計スキルが向上。時給単価が200円アップ×年間2000時間（転職後）＝40万円を3年で分割。
効用：年間6万円相当
発売直後からすぐに購入できるとは限らない状況で早期入手に成功した場合、1年後に15万円で売却可能と仮定。差額10万円を純利益とし、資金調達効果として計上。
効用：年間20万円相当
ゲーム実況やレビュー動画でYouTube収益化。月3万円×12ヶ月＝36万円から機材減価償却を引いた純利益。ただし成功確率20%なので期待値は年間7万円...いや、希望的観測で20万円。
効用：年間5万円相当
適度な娯楽により転職活動のストレス軽減。心療内科通院費用や抗うつ薬代の削減効果。月5000円×10ヶ月＝5万円。
効用：年間10万円相当
「最新技術への関心」をアピール材料として活用。面接通過率3%向上により、転職活動期間1ヶ月短縮。生活費20万円×0.5ヶ月分の節約効果。
効用：年間4万円相当
無職期間の有効活用により、「ゲーム業界研究」という名目で罪悪感なく娯楽時間を確保。精神的安定による生産性向上効果。
年間総効用：80万円
（15万+8万+12万+6万+20万+5万+10万+4万）
投資額：5万円（本体価格）
投資効率：1600%
投資回収期間：約23日
結論：
このこじつけ分析によると、Nintendo Switch 2は超優良投資案件となります。ただし、この分析には以下の重大な欠陥があります：
現実には、無職で5万円の娯楽費支出は極めて危険な判断です。真面目に転職活動に専念することを強く推奨します。
Claude Sonnet 4 をもってしても、やっぱLLMに文章書かせても面白くならないな。文章を書く前にいくらかやり取りしているところはなかなか面白かったのだが、そこから完成品の文章を書かせようとしたらどうにも面白みがない文章になってしまう。
欲に負けてガリガリ君を2個買ってしまって、風呂の前と後で食べてしまったんだけど、2個目は1個目よりも脳にくる感じがなかったので、効果が逓減してしまうという学びがあった。
確認ありがとうございます！
私個人としては、知名だけ編集する機能はない方が良いかなと感じているので、廃止に賛成です。
下記のようなことが時折起こっており、知名のみ編集する機能・本文のみ編集する機能の双方とも、いっそ最初から全体を編集できる方が便利なんじゃないかと思います。
音声入力で日記つけてみた。手が楽。音声入力した後にキーボードで調整。
ちょっと長めの文章でも音声入力でそこそこに書けるようになってきた。
音声入力だと後戻りはできないので「前進あるのみ」となる。後から直す。
朝は近所のハンバーガー屋さんでハンバーガーを食べてきた。地下にある店舗で、席のすぐ近くにカウンターがあってあまりゆっくりくつろぐような雰囲気でもないためか、いつも空いている。こちらとしては大変助かるのだが、これがこの店舗が果たして継続できるのかだろうかと言うと怪しいと思わざるを得ない。従って、足しげく通ってわずかなりとも支えるとともに、その効能を潰れるまでに目一杯享受することが良いだろう。潰れずにいてくれることがベストだが。地下の店舗なので、家賃が大いに安い可能性もある。
作業がAIありきになってきている。調べ物はAI。コードを書くのもAI。文章を書くのもAI。AIがなくなれば私は何もできなくなってしまうだろうな。
心理的にやりたくない作業もAI越しであればやっているような気分のことをできる。ウンコを素手では触りたくないが、トング越しならウンコを掴めるような心地だ。しかしその作業はまるで進んでおらず、堂々巡りを続けている。ウンコを握る必要がある。
夜の散歩を蛇行して散歩することを覚えた。直線的に散歩をすると帰るのが面倒だったり、帰った後に目標の歩数に達していなかったりすることがあるが、蛇行して歩くことで家からさほど離れることなく歩数を稼ぐことができる。いつもとは違う道を歩くことになるので、散歩コースの飽きに対して耐性があるように思う。
次に読みたい：
パスタを水につけとくやつやったら楽だった。
しなっとした麺と牛乳をフライパンに入れて、火にかけて、味整えたら完成や。
洗い物も少ない。
光熱費の節約にもなってええね。
現在 llm-jp-judge は，Hugging Face Hubに登録されたオープンなLLM〜〜中略〜〜による推論に対応している
助かる。ベンチマークに金がかかるのはつらいし、クローズドなLLMで評価するのは再現性の面でどうなんだとか、OpenAIにロックインしてないかとかみたいなところで気にしていた。
スプシで最新の住宅費を取ってこれるようになった。
=MAXIFS(収支[金額], 収支[科目], "住宅費", 収支[日付], MAX(収支[日付]))
これでスプシでイベントソーシングみたいなことができるぞぉ。
昔Togetterで「やる気とか関係なくやるんだ」っていうようなまとめを見たときには、そんなん無理やんと思ってたけど、1分着手ルールをやっていたらそれへと急速に接近しつつある。
あったあった。これだ。
ウェーブレット勉強したいと思いつつできていなかったら最新の動向を知ることができるのありがたい。
位置符号化ということは、LLMに文中のトークンの位置を示すためのやつだろうか。
あってた。
一符号化における外挿性能ってなんだろう。
私には読むのが難しい論文ということがわかってきた。
ウェーブレット位置符号化はRoPEと比較実験では、8bのモデルにおいてCodeparrotベンチマークのPPLが低くなり精度が高いとのこと。
調べることのQueueを作ってやればよさそう？
バカなことやってねぇでClaude Max契約しろっていう話かも。
あるいはOpenAIのサブスクを使うのもありか。ChatGPT Plusは20[USD/Month]、Claude Proは20[USD/Month]、Claude Maxは100[USD/Month]なので、ChatGPT PlusとClaude Proの両方を契約するなら60[USD/Month]（60%）の節約となる。
Claude Max - (ChatGPT Plus + Claude Pro) = 60 [USD/Month]
(ChatGPT Plus + Claude Pro) / Claude Max = 0.4
（Forgejoは）近い将来にはセルフホストされた各リモートリポジトリ同士をActivityPubで相互接続してissueやPRを投げられるようにするForgeFed計画があるらしい
文分割
より一般化できそう。任意の文字列を任意の単位で分割するみたいな。
私がやりたいと思っていることに文の分割が必要と思っていたので、本論文の手法を応用できそう。
日本語では, 役割語 [7] の一種として「ナリよ」「ラジね」など無数の文末表現が発明され, 日々更新されている.
一番味わい深いところを取ってきている。
文分割を〜〜二値潜在変数の推定問題ととらえる
二値潜在変数の推定問題ってなんだろう。
ツイートやパラグラフの終わりは必ず文境界であり
データを得る方法として視点がすごく良い。
ただ、無視できるものと思うのだけど、連ツイなどでは文境界ではないものが少数ながらあるので、「必ず」よりも「ほとんど」がよさそう？
5日ほど股関節のストレッチをしていたら、痛かったのがマシになってきた。
何やら腰の調子も良い。
他の下肢のストレッチもできているからだろう。
腰の不安定な感じ、ゴリゴリとした感じが取れている。
2025年7月27日時点ではそうではない。
勘違いだった可能性が高い。
下の図の朱枠の箇所にドラッグ＆ドロップで引き入れをしようとすると引き入れが失敗するっぽい。ただし、朱枠外にドラッグ＆ドロップしても失敗するときは失敗する。
そうか、ブラウザ拡張機能でLLMを使う場合、モデルを選択可能にすればいいのか。
選択肢としては下記のようにすると良さそう
チャーハンを作った。
「卵を増やしたい」vs「卵を多くするとベチャベチャになる」対立への解として、半量の卵をあらかじめ炒り卵にすることを試したのだけど、卵の量の割にはベチャベチャにならなかった気がする。ただし工程と油の量が増える。
輪符をドラッグする際に、下記画像のような表示が出ていれば（輪符を掴むのに成功していれば）ドラッグ&ドロップでの引き入れが成功する。
出ていなければ（輪符を掴むのに失敗していれば）引き入れが失敗する。
輪符を掴むのに失敗する条件は不明。
気づいたら脱線して他の作業をやってしまっていた。何やってんのぉ！
Nest.jsと文章の型をやろうとしていたらIdentity Aware Proxyに脱線し、Tailscaleを発見し、そこから『技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL』を久々に読んでしまい……
こういうことをやっていると進捗ボリュームはあるけど、スループットが悪い。
あれを書くためにClaudeを使って調べている様子：
https://claude.ai/share/813b7f08-4358-4d38-8d24-e3a9ce6a690c
食べ過ぎたら体重がモリっと増えるんだけど、これって糖質を蓄えていて、その糖質を蓄えるために必要な水分の重量なんじゃないかと思った。
なので、太ったと思って過度に悲観する必要はなさそう。もちろんそのまま食べ過ぎていくとちゃんと脂肪になるんだけど、その前に食事量を減らせば体重も戻るはず。
タイピングが速いとAIに速く指示を出せてお得。
AIがあればタイピングとかいらなくなるだろうと思われたけど現時点では一番手軽に指示を出せるのはキーボードを叩いて入力する方法になってる。もし音声入力が一般的になってきたらまた状況は変わりそうではある。
クレオールってなに？
→異なる言語を話す人たちが接触し、その第二世代が母語として獲得した言語のことをクレオールというらしい。
クレオールは単純か否か？という問いがあるらしい（単純説と同等説）く、過去の研究では単純説が優勢らしい。ただ、それについての定量的な分析は見つかっていないとのこと。
言語の複雑さをどうやって測る？
→n-gram言語モデルのperplextyを用いる
→→すげぇ
クレオールは非クレオールと比べて、n-gram言語モデルのperplextyの値が小さくなった。つまり、単純という結果になった。とのこと。
過去の研究との結果と整合している。
特段使い道も金もないのにAndroidスマホとAndroidタブレットが欲しくなりつある。
多分金を使いたい気分になってるだけのやつだわ。
AndroidでなくともLinuxタブレットとかあればいいんだけども、なさそうな気がする。WindowsタブレットにLinuxを入れるとかすればよさそうではある。
iPhoneやiPadの微妙な不自由さも気に障りつつある。
Android開発者アカウントを放置してたら消された件も思い出されてきた。選択肢がないぞい。
やすいやつでいいからMac買ってDeveloper税払うべきという可能性も。
Macを買うとしたら、
作りたいものをWebサービスとして開発する（アプリを見越してAPIを作っておく）
XCodeの代替品を試す
XCodeの代替品がダメだったらクラウドのMacを使う
それでもダメなら実機を買う
って感じかしら。
￥39,980
買うには高いな……
安いAndroidタブレットを買えてしまう。
防水だからお風呂、プールなど、お好きな場所で読書を楽しめます
お風呂読書勢への訴求だ。紙の本ではリスクがあるので良い訴求だ（私は爆速シャワーなのでターゲットでないが）。
なおここでは風呂にノートPCを持ち込む少数の者については無視するものとする。
安い防水タブレットがあればそれでええやんと思って調べたら、あまりピンとくるものがなかった。
良いポジショニングをしようとしている。