鏡の中

資本主義の極限が「民主社会主義」に行き着く：国家を株式会社として再定義する統治モデル

2026-09-07T11:53:11.705+09:00

結果的に、士郎正宗世界における、企業国家に関する考察となるのだろうか

国家を「完全合理的な株式会社（JP Holdings Inc.）」として再定義し、AIガバナンスと資本主義のメカニズムを極限まで適用することで、倒産や失業のない超効率的な統治モデルを構築する可能性について書き記す

1. 国家の株式会社化

国家を単一のコングロマリット（JP Holdings Inc.）として再設計し、国民を「社員（株主）」と定義する。

国債の全額買収: 発行されている膨大な国債（例えば日本における1,700兆円規模の債務）は株式市場における株となる

2. 「倒産ゼロ・失業ゼロ」を実現するAI経営判断

企業や組織の持続可能性を担保するため、経済活動の動的コントロールをAIに一任する。

赤字部署の事前再編: 個別の事業セグメントが赤字に転落する前に、AIがリアルタイムのデータに基づいて自動的に事業ポートフォリオを組み替え、破綻や倒産という概念そのものを消滅させる。

労働者の完全保護: 部署の統合や再編において、そこで働いていた構成員には一切のお咎め（解雇や不利益）が発生しない。すべてのリソースは成長セグメントへシームレスに再アサインされる。

税務署も年金機構も必要ない、全てソフトウェアに置き換わる

年金は退職金の分割払いとなる

3. 戦争なき時代の国家買収スキーム

国家の株式会社化が世界に浸透した場合、敵対的買収による戦争のない抗争で決着をつけることになる

資本のレバレッジ: 直接的な巨大国家の買収が困難である場合、まずは小国の買収や経済圏の統合によって基盤となる資本とエネルギー拠点を確保する。

経済合理性による統合: 非効率なレガシー官僚機構や政治的妥協を排除し、純粋な株主価値と資本効率の最大化を基準として、国家の経営権を合法的に書き換える。

このような形こそが真の意味での民主社会主義と言えるのではなかろうか

ただし、どのように日本を企業に変貌させるのかはわからない

とは言え、トランプの出現は、アメリカ合衆国全体を株式会社トランプにする前段階とも取れる

なんの成果も出せない見せかけの政治に民衆が気がついてしまった

だから、政治家ではないトランプが求められた

トランプもイーロン・マスクのやっていることも、政治というより会社経営だ

膨らみ続ける政府債務の行方：戦争なき現代、この巨大な借金はどう決着するのか

2026-09-06T19:26:48.848+09:00

「インフレによって数字が大きくなっていくだけだから平気だ」

政府債務の膨張に対して、こうした楽観論が語られることがある。しかし、はたして本当にそれだけで済む話なのだろうか。

日本の国債は政府が借りている借金であり、その保有者は日銀、金融機関、海外、家計などに分かれている。

一応現時点での内訳も書いておく

日本銀行

44.2%

銀行等

16.0%

生損保等

14.5%

海外

12.3%

公的年金＋年金基金

8.4%

家計

1.5%

その他

3.1%

国債は殆ど日本国内で買われているから大丈夫と言う論理も、この割合から海外が意外に多いなと感じるのではなかろうか？

またこの割合にしろ、今後海外の割合は増えると予想する

なぜなら日銀はが金利を上げたからだ

日銀が大きな割合を保有しているとはいえ、日銀と政府は別の法人・会計であり、財布も別だ。

日銀が利益を出した場合、その一部は国庫納付金として政府に戻り、一般会計に入った金は結果として新規国債の発行額を減らすことはできる。しかし、それによって既存の国債そのものが消えるわけではない。つまり、日銀というバッファが存在していても、政府債務そのものが消えてなくなるわけではないのだ。

そして国債は満期になるたびに返済する必要があるが、実際には新しい国債を発行して借り換えることで財政を維持している。

この仕組みを長期間続ければ、金利が上昇したときに、より高い金利で借り換えることになり、利払いも増えていく。債務が膨らみ続ける仕組みを、永遠に維持できるとは考えにくい。

「インフレで額面が大きくなる」の本当の意味

もちろん、100年も経てば物価も賃金も上昇する。

一円玉が消えて、一万円玉が使われるようになり、日本の平均年収が一億円になるような世界になれば、国債の額面も現在とは比較にならないほど大きくなるだろう。

しかし、それで「国債がいくら増えても問題ない」ということにはならない。

日本は、すでに国家債務と通貨の大きなリセットを経験している。

明治以来、日本では長く「銭」という単位が使われていたが、戦争前にはインフレが進み、敗戦時には政府が発行した国債の価値も大きく失われた。通貨の単位も、実質的にはそれまでとは異なる「円」の時代へと移っていった。

これは、単に物価が上がって国債の数字が大きくなったという話ではない。戦争と敗戦をきっかけに、通貨の価値、国債の価値、そして国家財政の前提そのものが大きく変わったのである。

それからまだ百年も経っていない。

戦争なき世界で、債務はどう調整されるのか

日本では再び国債が膨れ上がり、アメリカや欧州を含む世界各国でも、政府債務が積み上がり続けている。

今度は、同じような大規模な戦争が起きるとは限らない。では、戦争が起きないまま、さらに百年が経過したとき、膨らみ続けた政府債務はどうなっているのだろうか。

問題は、国債の額面が何兆円、何京円になるかだけではない。

その膨張を、インフレ、増税、歳出削減、金利抑制、債務整理などのどのような形で、最終的に誰が負担するのかという問題である。

「インフレで通貨の単位が大きくなるから、国債の額が増えても問題ない」というだけでは、この問題を説明したことにはならない。

誰も答えを出していない大きな問い

各国は現時点で日本よりも高い年収、高い物価、高い税金へシフトしている

日本も追従する事になるだろう

だがそれもいつか限界に達する

権力集中をしない政治体制

2026-09-05T17:52:00.088+09:00

権力集中をしない政治体制

欧州各国の政治制度には、第二次世界大戦前後の独裁政権の経験から、「権力が一つの機関や政党に集中しないようにする」ための強い思想が反映されています。ここでは、戦後欧州がどのように「権力の集中そのものを防ぐ仕組み」を作ったのかを整理します。

1. なぜ欧州は「権力集中」を恐れるのか？

ドイツのナチス政権やイタリアのファシスト政権など、歴史上、「民主的な選挙」を経て成立した政権がそのまま権力を掌握し、独裁化していったという痛烈な反省があります。

そのため、戦後の欧州各国では「素晴らしいリーダーを選ぶこと」以上に、「誰が権力者になっても国家権力を丸ごと掌握できない（権力を分散させる）仕組み」が憲法や政治制度の土台に組み込まれました。

2. 権力を縛る「縦と横」の分断メカニズム

権力の暴走を防ぐため、欧州各国は主に「横の牽制（機関同士）」と「縦の分散（中央と地方）」という2つのアプローチをとっています。

(1) 横の分散：機関同士のチェック＆バランス

・ドイツ：首相に対する不信任決議を、同時に後任を選出する「建設的不信任決議」とし、政局の不安定化を防ぎつつ、連邦憲法裁判所が政府の行為を厳しく審査する。また、人間の尊厳や民主制など「絶対に変えてはならない永久条項」が憲法（基本法）にある。

・イタリア・オーストリア：国家元首である大統領と内閣（首相）を明確に分離し、対等な権限を持つ二院制や、法律の合憲性をチェックする憲法裁判所を設置している。

・フランス：大統領に比較的強い権限を与える一方で、首相・政府を別系統の行政主体とし、国会や憲法院、さらには上位概念であるEUの司法機関による外部的な制約を受けている。

(2) 縦の分散：中央から地方への権限委譲

・ドイツ・オーストリア：連邦制を採用し、州に大きな権限を与えている。連邦政府だけで立法や行政を完結できない構造になっている。

・スペイン：フランコ独裁による強烈な中央集権体制への反省から、1978年憲法で「自治州制度」を導入し、広範な自治権を与えている。

3. 「数」の力で暴走させない選挙と政権の仕組み

制度だけでなく、選挙制度も権力集中を防ぐ大きな防壁となっています。

・比例代表制の重視：ドイツなど多くの国で採用されており、一つの政党が議会の過半数を簡単に独占しにくい。

・連立政権の常態化：結果として複数政党による連立政権になりやすく、政権政党が単独で思い通りの政策を突っ走らせることが難しい構造になっている。野党も議会内に一定の勢力を保ちやすい。

4. まとめ：人格や善意に頼らない「仕組みの民主主義」

欧州の戦後民主主義の肝は、政治家個人の人格や善意に依存せず、以下のマルチな要素で権限を細かく切り分けている点にあります。

・中央政府と地方政府

・行政府と議会

・行政府と司法

・与党と野党

・大統領と首相

・議会と憲法裁判所

・国家とEU

これらはすべて、「民主的な選挙で選ばれた政権であっても、国家権力を無制限に行使させてはならない」という共通の理念に基づいています。戦後欧州の政治は、独裁者を排除する制度というよりも、「権力の集中そのものを起こさせない防壁のネットワーク」として理解する必要があります。

なぜ日本は自民党中心の政治が続くのか？

欧州が「権力分散の仕組み」を徹底したのに対し、日本が自民党による長期政権（一党優位体制）を維持しやすい背景には、以下のような歴史的・制度的な理由があります。

1. 「外部からの破壊」ではなく「内部での継承」による近代化

欧州各国は、自国の政治体制がファシズムやナチズムによって崩壊し、他国に占領されるなど「国家体制の完全なリセット・再構築」を経験しました。その痛烈な反省から、憲法レベルで権力分立を厳格にデザインし直しました。

一方、日本は戦後に憲法改正や民主化が行われたものの、官僚機構や国家の骨組み自体は戦前から大きく断絶することなく引き継がれました。

2. 中選挙区制から小選挙区制への移行と「政党の性格」

日本の選挙制度は、かつての中選挙区制（1つの選挙区から複数当選する）の時代、自民党候補同士が同じ党内でパイを奪い合う構造（保守分裂）でした。これが実質的な野党の役割を果たし、自民党が単独で過半数を取らなくても政権を維持できる「自民党一強」の土壌を作りました。

1994年の政治改革で導入された「小選挙区制」は、本来は「政権交代が起きやすい制度」として設計されましたが、実際には野党側が割れやすく、自民党の組織力・資金力が圧倒的に有利に働くため、結果として野党が万年野党化しやすい構造を生みました。

3. 「強いリーダーや強力な中央集権」を好む行政文化

欧州の多くの国（ドイツやスペインなど）は、過去の強権的な中央集権のトラウマから「地方分権」や「連邦制」へ舵を切りました。

対して日本は、明治維新以降、中央政府（官僚機構）が主導して近代化を成し遂げた歴史的経緯があり、危機管理や効率性の面でも「中央集権」や「強力な行政・与党」が機能しやすい（あるいは国民がそれを許容しやすい）文化的土壌があります。

4. 野党側の受け皿の弱さと「現状維持」の心理

欧州では比例代表制が主流であるため、少数政党でも議席を確保しやすく、連立のパートナーとして発言力を持ちます。

しかし日本の小選挙区制の環境下では、野党が政権を獲るためには「巨大な政党にまとまる」必要がありますが、政策や理念の異なる野党同士がうまく結集できず、「自民党以外の選択肢が信用できない」という有権者の心理を生んでいます。結果として、「消極的な現状維持」として自民党政権が選ばれ続けることになります。

まとめ

欧州が「誰が権力を握っても暴走しないように、あらかじめギチギチにハードルを設けたシステム」であるのに対し、日本は「特定の政党（自民党）と官僚機構が長期政権を担うことで、政策の継続性や行政の安定を重視してきたシステム」と言えます。

どちらが優れているかというよりも、「歴史的トラウマをどう制度に昇華させたか」の違いが、現在の両者の政治体制の差に表れています。

Macで作ったZIPの文字化け

2026-08-11T16:14:52.997+09:00

MacでZIPを作ってWindowsに持っていき、Windowsで解凍すると文字化けする。

MacのZIPはちょっと古いもので、ヘッダにUTF-8フラグやUTF-8ファイル名を記録してくれず、そのままUTF-8ファイル名のみを保持するため、Windowsで解凍するときにそのまま文字化けしてSJISになってしまうのが原因だ。

Mac定番のKekaを使うときちんとヘッダにUTF-8ファイル名も書き込んでくれるようで、Windowsで解凍しても文字化けが起きない。

ちなみにKekaはAppStoreから落とすとサブスク？料金がかかるんだけど、本家サイトからダウンロードするとそのまま使える。

Macでも新しいZIPをbrew install zipしてやって、

/opt/homebrew/bin/zip -UN=UTF8 -r "${BASE_NAME}.zip" "$TARGET" -x "*.DS_Store" -x "__MACOSX" -x "._*"

とかやってやれば文字化けせず、.DS_Storeや._ファイル名も含めずZIPできるんだけど

そこまでやる人普通はいないので素直にKeka使ったほうがいいかもしれない。

というか、Appleちゃんとしろよ

世界中が困ってんだよ

RaspberryPiにWaveshareのe-inkディスプレイをつけた

2026-07-10T00:04:05.171+09:00

Pythonで書いて、サービスにしておいたので、

ラズパイが起動したら表示されます

全有権者比率での投票率

2026-07-09T11:27:08.698+09:00

政党	2026	2024	2021	2017
自民党	20.66%	約17.8%	約19.7%	約17.9%
立憲＋公明（→中道改革連合）	約10.25%	約18.3%	約18.4%	約16.7%
国民民主	5.47%	約6.8%	約2.6%	約1.4%
維新	4.85%	約8.7%	約8.0%	約3.4%
共産	2.48%	約3.5%	約4.1%	約4.0%
れいわ	1.64%	約2.9%	約2.2%	―

dot_cleanしてくれる常駐アプリを作りました

2026-06-27T17:41:48.833+09:00

最近MacbookNeoをつかいまくってて、

SDカードとか書き込んでて気がついた

そうだった。.ds_storeとか_ファイル名とか、Macを使ってると隠しファイルができてしまうのだ。

しかし！

それらを消すコマンドがある！

ターミナルを開いて、以下のコマンドを入れる

dot_clean -m /Volumes/NO\ NAME

マウントされている名前はNO NAMEなんだけど、スペースが入ってるからバックスラッシュ・スペースでつながっている

これを毎回やるのは嫌なので、

取り出しをするときにフックして、dot_cleanを実行するアプリを作ってみた。

名前はdcleanにした

xcodeを立ち上げて、アカウント入れたりなんだりしてから、contentViewやItemを消して、dcleanAppだけ残して以下のように書き換え

import SwiftUI

import AppKit

import Combine // 🌟 これを追加！

// MARK: - 1. ログのデータ構造と管理クラス

// 重複したログでも区別できるように Identifiable にする

struct LogItem: Identifiable {

let id = UUID()

let text: String

}

// ログを管理し、UI（メニューバー）を更新する専用のクラス

class LogStore: ObservableObject {

static let shared = LogStore()

@Published var logs: [LogItem] = []

// UIの更新は必ずメインスレッドで行う

func addLog(_ message: String) {

DispatchQueue.main.async {

let formatter = DateFormatter()

formatter.dateFormat = "HH:mm:ss" // 実行時間も表示

let timeString = formatter.string(from: Date())

let newLog = LogItem(text: "[\(timeString)] \(message)")

// 最新のログが一番上に来るように追加

self.logs.insert(newLog, at: 0)

// メニューが長くなりすぎないよう最新10件に制限

if self.logs.count > 10 {

self.logs.removeLast()

}

func clear() {

DispatchQueue.main.async {

self.logs.removeAll()

}

// MARK: - 2. メインのApp定義

@main

struct dcleanApp: App {

// LogStoreの変更を監視する

@StateObject private var logStore = LogStore.shared

init() {

// アプリ起動時にディスク監視を開始

DiskObserver.shared.start()

}

var body: some Scene {

MenuBarExtra("dclean", systemImage: "wand.and.stars") {

Text("外付けドライブの取り外しを監視中...")

.font(.caption)

.disabled(true)

// ログが存在する場合のみ履歴メニューを表示

if !logStore.logs.isEmpty {

Divider()

Text("最近の動作履歴")

.font(.caption)

.disabled(true)

ForEach(logStore.logs) { log in

Text(log.text)

.font(.system(size: 11)) // ログは少し小さめの文字で表示

}

Divider()

Button("履歴をクリア") {

logStore.clear()

}

Divider()

Button("アプリを終了") {

NSApplication.shared.terminate(nil)

}

.menuBarExtraStyle(.menu)

}

// MARK: - 3. ディスク監視クラス

class DiskObserver: NSObject {

static let shared = DiskObserver()

private override init() {

super.init()

}

func start() {

NSWorkspace.shared.notificationCenter.addObserver(

self,

selector: #selector(handleVolumeWillUnmount(_:)),

name: NSWorkspace.willUnmountNotification,

object: nil

)

}

@objc func handleVolumeWillUnmount(_ notification: Notification) {

guard let volumeURL = notification.userInfo?[NSWorkspace.volumeURLUserInfoKey] as? URL else { return }

let path = volumeURL.path

guard path.hasPrefix("/Volumes/") else { return }

// "/Volumes/USB_Drive" から "USB_Drive" の部分だけを抽出して見やすくする

let driveName = volumeURL.lastPathComponent

print("取り外しを検知: \(path) - dot_cleanを開始します。")

LogStore.shared.addLog("⏳ \(driveName) をクリーン中...")

runDotClean(for: path, driveName: driveName)

}

func runDotClean(for path: String, driveName: String) {

let task = Process()

task.launchPath = "/usr/sbin/dot_clean"

task.arguments = ["-m", path]

do {

try task.run()

task.waitUntilExit()

print("dot_clean完了: \(path) - 安全に取り外します。")

LogStore.shared.addLog("✅ \(driveName) のクリーン完了")

} catch {

print("dot_clean実行エラー: \(error.localizedDescription)")

LogStore.shared.addLog("❌ \(driveName) でエラー発生。\(error.localizedDescription)")

}

三角を押して動作確認したら、ビルド対象をAny Mac(arm64, x86_64)にして、メニューのプロダクトからアーカイブを選んでディストリビュートし、CopyAppを選んで適当なところに配置、XCODEでを終わらせて、できたAppをダブルクリックしたら動くはず

これで、いちいち、dot_cleanする必要はなくなった。

欲しい方はこちらからどうぞ

2026年06月30日バージョンから、上記説明の他にあれこれ追加して、右クリックメニューのクイックアクションにフォルダをクリーンアップするCleanupと、.DS_Storeや._ファイル名を除外しながらZIPを作るmakeCleanZipを登録する事ができるように修正しました。

2026年07月04日ネットワークドライブなども対象になっていたので、それらを除外する処理を追加しました。

2026年07月07日アプリ用アイコン作成、上部常駐部アイコン作成、下部のバーにアイコンが出てしまったのを修正

起動すると上部にアプリが常駐します。

クイックアクション設定から「Finder右クリックに追加する」で、クイックアクションが登録されます。

「Finder右クリックから削除する」でクイックアクションは消せます。

終了させるときは「アプリを終了」です。

実はこれを作る前にはKekaというアプリを使っていたのですが、

ZIPしか使わないし、拙作アプリだけで良くなりました。

自動開閉ゴミ箱の回路を差し替えた

2026-06-21T22:46:23.003+09:00

以前買ったそこそこ高い自動開閉ゴミ箱

なぜ最近、閉まらなくなってしまって

開く時と閉まる時でトルクが全然違う

ドライバーがいかれたのだろうか？

直すのも面倒なので回路ごと差し替えることにしました。

使ったのはPIC16F1825とDRV8835、GP2Y0E03、他に部品は、LEDとプルアップ抵抗4.7k2本、あとはユニバーサル基盤

開発環境はMacbookNeoで、MPLab X IDE 6.3 と snap、あとは、リボンケーブルやデュポンコネクタ、ジュンフロン線、半田、コテくらいですかね

開く時と閉まる時の時間設定をすると、動き始めと動き終わりがゆっくりになるように調整しています。

開いている時間は、家族から45秒くらい欲しいと言われたので、その設定にしました。

一応スイッチを付ければ、距離センサーで反応する高さを設定することもできるようにしてあるのですが、今のところ25cm固定で問題なさそうなので、スイッチは付けてません。そのうちやるかも知れませんが、今のところ必要性がないです。

他に考えてるのは、snap用のコネクタが剥き出しなので、TPUで部品作って、覆うようにしようかなとかですかね

snap用のコネクタも付けました。

今回結構多くのデュポンコネクタを作りました。

2.54mmピッチで、AWG28あたりの線を使うと、

デュポン一択ですね

VSC+PlatformIO+ESP WROOM 32

2026-06-11T13:47:13.068+09:00

マウスキーボードジグラーを作った

BLEで繋ぐとチョビチョビ動く

ノウハウの蓄積と継承問題

2026-06-10T11:40:05.708+09:00

農業や漁業も若者に魅力のない職業らしいが、高齢化という点では、建設業もやばい、そして実はソフトウェアもやばい

というか本気でソフトウェアはマヂやばい

建設業に似てると思う

どちらの業種もノウハウが山のようにある

それなのに大工の研修数年やった程度の人に家を建ててもらうことになるのはマヂ勘弁してほしい

プログラマもそうだろ？

半年プログラミング講義して、現場に投入よ？

今はAI使ってそれらしい答えが得られるんだけど、、、

それ、正しいわけがないので、ちゃんと読んで治せる人がいないと全然ダメ

そのうちAIが変わるかもしれないけど、今時点ではどれもこれもまだダメ

いやー本当に、プログラムなんて組まないでいい時代になってほしいよ

そうしたらスッキリやめるのになー

まぁ、多分仕事は無くならない気がする

建てた家が十年後大丈夫か見極められる人、書いたプログラムがなんでそういう設計なのかメンテコストなど見越して設計できる人、そういう立場の連中は残るだろう

そこが居なくなったら大変よ

自動開閉ゴミ箱の調子が悪い

2026-06-09T21:25:22.909+09:00

開くときにはトルクがあるのだけど、閉まるときに全然トルクがない

多分Hブリッジイカれた

仕方ないので自前回路で置き換える

まずは部品選定（単一電池２本で動くようにしないといけない）

PIC16F1825

モータードライバはDRV8835

赤外線距離センサーはGP2Y0E03

んで次がプログラム

あとは書き込んで配線して試すだけ・・・

ちょっと今日はできないのでまた時間のあるときにやる

ミジンコ

2026-06-05T00:44:32.587+09:00

元気に泳いでいます

フィラメントケースを再考する

2026-06-04T23:43:17.294+09:00

https://www.onlyspoolz.com/portfolio/

こちらを見ると1kgサイズのスプールは厚みが65mm程度

だからわたしが以前採用したこちらのケースでは４つのスプールが収まります。

https://amzn.to/3ROjlrF

3100円なんですけど、業務用というものもあって、

https://amzn.to/4odPO6W

サイズもほぼ一緒でこちらは2209円

わたしは底面から15cmの中心に、

Φ20のパイプを33cm長に切って、

3Dプリンタで作った部品で固定しています。

それを作ったのが2018年の年末で、

そこからずっと使ってますが、

一度もジャムったことがありません

よくある底面で支えるタイプも試したことはあるんですが、どうもゴロゴロして安定しません

フィラメントスプールは中心に穴が空いてるんだから、そこにΦ20のパイプを通して保持する方が断然安定しますし、この容器の中にシリカゲルを仕込んだ方が扱いも簡単です。

ですが、残念なのが一点

パイプ一本なので、真ん中のスプールだけ変えたい時に全スプールをら持ち上げなくてはなりません。

まぁ、4キロくらいどうってことはないんですけど、フィラメントがPTFEパイプに通っているとちょっとやりづらさはあります。

できれば、パイプを4本に切って、スプールホルダを四つ中に仕込みたい。

2ミリ幅くらいで仕込めたらいいんだけど、パイプ保持には両側から2cmくらいは欲しい

まぁそんな感じでホルダーのデザインをしてますがなかなかうまくいかないですね

薄さと強度の両立ってなかなか大変です。

多分これなら行けるかも？

幅70mm以下のスプールに対応

ホルダーの幅自体は74mmになり、4つ分を横に並べると、74 x 4 = 296mm

先程の容器の下部は小さくすぼんでいるため、

容器の最小サイズは下部となり、30 x 20 x 23くらい

30cm なら296mmでぎり入ります。

百均の園芸支柱11mmを70mm長に切って４箇所取り付け、最上部はφ20mmのパイプを同じく70mmに切って上からはめる

はめるときは真ん中を少し広げないといけないので、

都度ホルダーごと上に抜き取る必要はありますが、

フィラメント４つを引き抜くよりは楽です。

ケースもこれ以上幅広のものを用意したくは無いので、これで決まりですかね・・・

あ、いやだめだ

スプールの真ん中がφ２０くらいのパイプならOKなんだけど、

それの支え部分がφ４０

全然だめだ・・・

もうちょい単純に考えてこれでいい気がしてきました

スプール中心にφ２０のパイプを使うのもやめます。

支柱部品も３Dプリントで作ってしまいます。

強度とか使い勝手に関しては使ってみないとわかりません

追記(2026/06/06)

やはり使ってみて改善点が出てきました

最終的にこの形になりそうです

Duet6HC+SBCでの3.6.3

2026-06-03T11:44:23.848+09:00

３日悩んだのですが、事の発端は、ファームのアップデートでした。

アップデート後SPIコネクションがresetされる現象が以下の様に発生

2026/6/1 16:42:29	Warning: SPI connection has been reset
2026/6/1 16:42:29	Connection to Duet established
2026/6/1 16:42:29	Warning: Lost connection to Duet (Transfer timeout while waiting for TfrRdy pin)
2026/6/1 16:25:59	File 0:/gcodes/Dish - PoleMiddle_PETG_6h0m.gcode selected for printing
2026/6/1 16:13:54	Finished printing file 0:/gcodes/Dish - PoleBottom_PETG_1h41m.gcode, print time was 2h 7m
2026/6/1 15:41:46	接続確立

まずいことに、わたしはリボンケーブルにちょっと自身がなかったのです。

自前で４０ピン、２８ピンのケーブルを作ったので、もしや、失敗したのかと思い、FC４０ピンソケットを購入し、つけ直しました。

しかし、また再現、仕方なく、もう一度つけ直しました。

それでも再現・・・

そこで、公式を見てみたのですが、

２２ピンであるところ、TfrRdy pinは正常に動いていることを確認しました。

次に、疑ったのはファームです。

SBC（RaspberryPi4)には、source.listにunstableの設定が書かれていました。

stableにして、ダウングレード手順に従ってダウングレードしました。

そしたら、嘘のように安定しました。

いやぁ・・・新しいからいいわけではないですね

GoogleFitがなくなるというので

2026-05-27T18:44:14.063+09:00

仕方なく作っているレシピアプリ（というか、献立記録アプリ）を作り直している

材料を選んで献立を作り、

食事の記録画面では献立から朝昼晩間食を記録できる

記録先はログインしたGoogleアカウントのドライブ上にJSONで記録する

GoogleFitへ食べたものを登録できるアプリを作っている

2026-05-09T20:47:00.001+09:00

今のところこんな感じ

食成分データベース八訂版を使って食べたものを登録（レシピ作成）

卵かけご飯のような普通の飯も登録しておいてカレンダーに登録する

GoogleFitと同期できる

言語はGo

フレームワークはFiber

iPhoneのGoogleFitアプリでの表示はこんな感じ

MacBookNeoが来ました

2026-04-03T21:34:00.007+09:00

ようやくMacbookNeoが届きました。

色はシトラスです。

iPhoneのCPUの方がインテルMacよりはやいなんて・・・

わかりやすい例としてちょっと重い処理をやってみました。

こちらのJSで実装したLispで描いたマンデルブロ集合は、

インテル入ってる初代MacBookProより断然速く描画が完了します。

https://www.yachiyo.tech/tool/JSLisp/

インテルCPUが、スマホのCPUに、速度でも電力効率でも負けるなんて、

アップルは本当にとんでも無いことをやっていると思います。

数時間使いっぱなしなんですけど、全然バッテリーが減りません。

一体どうなってるんでしょうか

さようならEvernote

2026-03-10T20:21:00.003+09:00

EvernoteからUpNoteへの引っ越し完了

Evernoteは2009年から使っていました

しかし、わたしの場合このまま使うと4月に$249.99/yearを、請求されるらしいです

あり得んでしょ？

実は自前で作っているシステムに引っ越しさせようかとも思いましたが

今回は間に合わず、仕方なくUpNoteに引っ越ししました

Evernoteからのエクスポートには、evernote/backup.exeを使って、コマンドラインからバックアップしましたが、バックアップ前に、Evernoteのメモを作成日ごとに切り分けておきました

一つのenexが1Gを超えるとUpNoteでインポートできません

ちなみにこちらのツールです

https://github.com/vzhd1701/evernote-backup

UpNoteに引っ越してわかりましたが、使い勝手はこちらの方が上です

買い切りで六千円なら買いますよ

さようならEvernote

2026年の増税をAIにまとめさせた結果

2026-03-05T07:34:00.003+09:00

現時点で判明している、2026年以降に実施される「増税」および「実質的な負担増（社会保険料引き上げ等）」をすべて網羅してプレインなテキストでまとめます。
たばこ・酒（嗜好品）
• 加熱式たばこ増税（2026年4月・10月）：紙巻きたばことの税率格差解消のため2段階で実施。
• 紙巻きたばこ・加熱式共通増税（2027年〜2029年各4月）：1本0.5円（1箱10円）ずつ、3年連続で段階的に引き上げ。
• 第3のビール・発泡酒増税（2026年10月）：ビールとの税率一本化に伴い、安価なビール系飲料が値上がり。
• チューハイ・サワー・果実酒増税（2026年10月）：これらもビール系とのバランス調整により税率が引き上げ。
防衛財源（防衛増税）
• 法人税付加税（2026年4月以降）：法人税額に4%を上乗せ。
• 所得税付加税（2027年1月〜）：所得税額に1%を上乗せ。
• 復興特別所得税の期間延長（2027年1月〜）：税率は下がるが、支払い期間が最長13年程度延長され、生涯の負担総額が増加。
子育て・社会保障（保険料上乗せ等）
• 子ども・子育て支援金（2026年4月〜）：医療保険料に上乗せして全員から徴収。実質的な「子育て税」とも呼ばれる。
• 高校生の扶養控除縮小（2026年度〜）：16〜18歳の扶養控除が38万円から25万円に削減。児童手当支給との引き換えですが、高所得層を中心に実質増税。
• 介護保険料の引き上げ（2026年度〜）：高齢化に伴い、40歳以上が支払う介護保険料の基準額が全国的に改定・上昇。
その他・検討中の項目
• 森林環境税（継続中）：2024年から開始された年1,000円の国税（住民税に加算）が引き続き継続。
• 国際観光旅客税（出国税）の増税（検討中）：出国時の1,000円を3,000円に引き上げる案が議論されています。
• 国民年金保険料の納付期間延長（検討中）：納付期間を40年から45年に延長する案があり、実現すれば5年分（約100万円）の負担増。
• インボイス制度の経過措置終了（2026年10月〜）：免税事業者からの仕入れ税額控除80%特例が終了。納税負担がさらに増加。
2026年は特に「子ども・子育て支援金」の徴収開始と「酒・たばこ」のダブル増税が家計に直結する大きな変化となります。

政治と経済の無相関性：歴史的視点からの考察

2026-02-18T21:48:00.003+09:00

これまでの主要な経済事象を振り返ると、政治が経済に与える影響は極めて限定的、あるいは皆無であることがわかります。

• 高度経済成長（イザナギ景気）

戦後ゼロからの再出発において、成長は必然的な流れでした。これは社会構造の復興によるものであり、政治の功績ではありません。

• バブル崩壊

市場の過熱とその終焉は経済サイクルの一環であり、政治的コントロールの枠外で発生しました。

• 震災と民主党政権

福島第一原発事故や東日本大震災という未曾有の国難、そして「悪夢」と評された政権下においても、株価は停滞しつつも極端な反応を示さず平行線を辿りました。この事実は、政権交代や重大な政治事象が市場の本質を動かさない証左です。

• アベノミクスによる30年の停滞

多種多様な政策が打たれましたが、結果として待っていたのは「失われた30年」の継続でした。金利操作の限界から外国人投資家の反応も限定的であり、株価の上下動はあったものの、実体経済と政治施策に直接的な因果関係は見出せません。

• サナエノミクスと現状

金利上昇による住宅ローンへの打撃や、1300兆円を超える国債赤字が露呈しています。かつて技術的コアコンピタンスを誇った企業の低迷を見れば、政治主導の技術投資も無意味であることは明白です。

結論

以上の歴史的事実から導き出される結論は一つです。政治は経済に対して実質的な影響力を持っていません。

「経済対策」と銘打たれた数々の政策が、実際の経済動向に寄与した例は皆無であり、経済は政治とは切り離された独自の原理で動いています。

【考察】異世界転生ブームの構造：ドラクエを共通言語とした救済

2026-02-11T10:42:00.001+09:00

1. 宗教的機能の代替

現代の異世界転生作品は、かつての宗教が担っていた「現世の苦難からの解放」という役割を引き継いでいる。

• 救済の構図: 現実での挫折や閉塞感を、死（転生）を境界線としてリセットする。

• 報酬: 努力の積み重ねではなく、転生時に付与される「能力（チート）」によって即座に成功と承認を得る。

2. 信仰対象の不在と派閥

この現象には、特定の神や教祖が存在しない。

• 信仰ではなく共有: 読者は特定の対象を拝んでいるのではなく、提示された「都合の良い設定」を各自で利用している。

• 派閥の性質: 「悪役令嬢」「追放」などのジャンル（派閥）は、個人の好みの違いであり、教義の対立ではない。

3. 土台としての「ドラゴンクエスト」

作品群の根底には、ドラゴンクエスト（JRPG）が定着させたルールが共通基盤として存在する。

• 共通ルールの利用: ステータス、レベル、魔法、魔王、ギルドといった要素は、説明不要の「周知の事実」として扱われる。

• 効率化: 世界観の説明を省略し、読者が最も求める「成功体験」の部分に物語を集中させることを可能にしている。

結論

異世界転生ブームとは、宗教に代わり、ドラクエ的な共通ルールを道具として用いることで、誰もが手軽に「自分が報われる物語」を消費できる救済の仕組みである。

2026-01-17T15:25:00.002+09:00

JSで作ったLISPライク言語

実は少しバージョンアップして、Switch-CaseやFillRectのみですが描画命令を持たせました

これにより、マンデルブロを描画できるようにしてみました。

是非ご観覧ください

https://www.yachiyo.tech/tool/JSLisp/

https://github.com/ChaosReadman/JSLisp

独自WEBフレームワークAlbion

2026-01-04T14:34:00.006+09:00

https://github.com/ChaosReadman/Albion

XQueryの完全実装をやめ、必要な機能のみ実装

どこがどう違うのか、開発哲学もREADMEに記述

XQueryに存在しない更新系クエリも実装

もはやwiki、レシピサイト、ブログなども作ることができますが、まだ脆弱性に関する設計を置き去りにしていますので、現状のまま使わないでくださいね

まだまだ変わります

独自WEBフレームワーク（FUSEやめました）

2026-01-04T02:16:00.002+09:00

FUSEを使うのをやめたらめちゃくちゃ早くなりました。

2秒ちょいかかっていたのが、0.5秒かからなくなりました。

これなら実用速度です。

double, int, stringへのキャストにも対応しましたので

以下のような書き方もできます。

where xs:double($book/@price) >= 10.5 order by xs:int($book/@price)

order by xs:string($book/@price)

独自WEBフレームワーク

2026-01-03T23:16:00.005+09:00

再び独自フレームワークを作り始めています。

あるアイデアのもと、Fuseを使い、XML Dataをファイルとフォルダ構造で置き換えています。

そしてSwiftによってResftfulAPIを作り、

リクエスト先にquery.xqyを配置

リクエストが来た時にquery.swiftを作成し、コンパイルし、実行します。

二回目からのリクエストでは、実行ファイルができている状態なので、コンパイル等の時間はかかりません。

デモでは食品データベース（２４７７種類）を使用しています。