[{"content":"LinuxでAndroidを動かすWaydroidの中で、テンキーの数字が打てなくなった。キーボードをGboardの「日本語」にすると打てて、「English (US)」にすると打てない。上段の数字キーは、どちらでも打てる。ホスト(Arch Linux、sway)でテンキーを打つと、数字が出る。\nswayの設定に input * xkb_numlock enabled を足したが、直らなかった。なぜ効かないのかを、ソースと実測で調べた。\n先に結論 ホストのNumLockの状態は、Waydroidの中のAndroidに渡らない。swayの設定は、Waydroidには効かない。 AndroidのNumLockは、Waydroidの中で、入った直後に消されている可能性が高い。ソースの読みと実測が合っているが、消す判定の値そのものは、見ていない。 Androidのアプリで、テンキーを数字に割り当てるキーレイアウトを足したら、英語のままテンキーが打てた。 ソースで分かったこと 読んだのは、WaydroidのHWC(android_hardware_waydroidのhwcomposer/wayland-hwc.cpp)と、Android 13(android13-release)の入力まわり、Waydroidが当てるパッチ(android_vendor_waydroid)。\n1. ホストのキーは、キーコードのまま渡される。修飾キーの状態は渡されない。 HWCは、Waydroidのウィンドウに入ったキー入力を、キーコードの形で、Android側のパイプ(/dev/input/wl_keyboard_events)に書く。Waylandの修飾キーの状態を受け取る関数 keyboard_handle_modifiers は、中身が空になっている。ホストのNumLockがオンでも、Androidはそれを知らない。\n2. テンキーの数字は、AndroidのNumLockがオンのときだけ出る。 Android 13の Generic.kcm では、NUMPAD_1 は、base: fallback MOVE_END、numlock: '1' と定義されている。NumLockがオフなら、Endキーになる。\n3. NumLockの状態は、キーを離したときに切り替わる。 Keyboard.cpp の toggleLockedMetaState は、キーを押したときは何もせず、離したときに、状態を反転する。\n4. Waydroidが作る入力機器は、出せるキーを2つしか登録していない。 WaydroidのEventHubのパッチ(Android 13用の 0004-EventHub-Add-wayland-inputs-support.patch)は、wayland_keyboard の keyBitmask に、BTN_MISC と KEY_OK だけを登録する。 AndroidのEventHubの markSupportedKeyCodes は、キーレイアウトにそのキーがあっても、この登録に無いキーは、「機器に無いキー」と判定する。KeyboardInputMapper::updateLedState は、NumLockのキーが無い機器について、NumLockの状態を消す。 NumLock(コード69)は、この登録に入っていない。\n実測 dumpsys input で、入力機器の状態を取った。キー入力の履歴を含まない部分だけを、次のように取り出せる。\nsudo waydroid shell dumpsys input | sed -n '/Input Reader State/,/Input Dispatcher State/p' \u003e out-1.txt Copy wayland_keyboard の項目の、MetaState(修飾キーとロックの状態)と、DownTime(最後にキーが押された時刻)を、見た。\n操作 DownTime MetaState 最初 77639155471000 0x0 a を押す 78176874436000 0x0 NumLockを押して離す 78198740555000 0x0 NumLockを押すと、DownTime は変わる。キー入力は、wayland_keyboard に届いている。それなのに、MetaState は 0x0 のまま。NumLockがオンになるなら、0x200000 のビットが立つはずで、立たなかった。キー入力は届いて、状態だけが残らない。これが、上の4の読みと合う。\n機器の一覧(Event Hub State)には、wayland_keyboard が Generic.kl と Generic.kcm を使っていると出ていた。キーレイアウトに、NUM_LOCKの定義はある。\n確認できていないこと 4の判定(NUM_LOCKが登録に無いので、NumLockの状態が消える)が、直接の原因かどうか。コードの読みと、MetaState が 0x0 のままという結果からの推論で、判定の値は見ていない。 日本語のときに、テンキーが打てる理由。Gboardの日本語入力が、テンキーのキーコードを自分で数字として扱っているのだと思うが、Gboardは非公開で、確認できない。 入れたAndroidイメージのパッチが、読んだパッチと同じ内容か。Androidのバージョンが13であることだけを、確認した。 同じ症状は、Waydroidの Issue #1944(2025年6月、未解決)にも出ている。\n直し方 Waydroidのパッチを直すには、Androidのイメージを作り直す必要がある。代わりに、Androidのアプリで、キーレイアウトを足した。android-numpad-klが、テンキーのキー(スキャンコード71〜73、75〜77、79〜83)を、NumLockに関係なく、数字のキーに割り当てるレイアウトを提供している。別のIssueのコメントで見つけた。\n入れる前に、ソースを全部読んだ。Javaは4ファイル、約500行で、権限は RECEIVE_BOOT_COMPLETED だけ。通信とコマンド実行は、見つからなかった。\nビルドは、配布のAPKを使わず、ソースからやった。元のビルド設定はGradleとJDK 17を要求するが、手元にはAndroid SDK(platform 36)とJDK 27しか無い。aapt2、javac、d8、zipalign、apksigner を順に呼ぶ、短いスクリプトで組んだ。なお、/opt/android-sdk/build-tools の実行ファイルは、rootしか実行できない権限だったので、コピーして使った。\n入れるときに詰まったこと waydroid app install は、結果を返さない。 ソースを読むと、Android側にインストールを始めるよう伝えるだけで、結果を受け取る処理が無い。入らなくても、何も表示されない。失敗の理由は、sudo waydroid shell -- logcat -d で見た(-- が要る)。 python3 がpyenvの版だと、waydroid が動かない。 dbus を読み込めない。/usr/bin/python3 /bin/waydroid ... と、システムのPythonを指定した。 Play プロテクトが止めた。 元の設定の targetSdk を 31 にすると、「安全ではないアプリをブロックしました(Androidの以前のバージョンを対象としている)」と出て、「OK」しか選べない。35にすると、「アプリのスキャンをおすすめします」に変わった。 ダイアログが、一瞬で消えた。 マウスのフォーカスをWaydroidのウィンドウに移すと、消える。HWCの keyboard_handle_enter を読むと、ウィンドウにフォーカスが入るたびに、Androidの画面を切り替えている。そのためだと思うが、これは確認していない。先にフォーカスをWaydroidに置いてから、sleep 8; waydroid app install ... を実行し、ダイアログに答えた。 最後に、Androidの設定の「物理キーボード」で、wayland_keyboard に、「Full keyboard with numpad, US QWERTY」を選ぶと、英語のままテンキーで数字が打てた。\n手元に残したもの ビルドのスクリプトと、できたAPK、手順は、~/repos/waydroid-numpad-kl に置いた。ホストの xkb_numlock enabled は、Waydroidには効かないと分かったが、ほかのアプリには効いている可能性があるので、消していない。\n","permalink":"https://america.github.io/post/2026-10-22-waydroid-numpad-numlock/","summary":"\u003cp\u003eLinuxでAndroidを動かす\u003ca href=\"https://waydro.id/\"\u003eWaydroid\u003c/a\u003eの中で、テンキーの数字が打てなくなった。キーボードをGboardの「日本語」にすると打てて、「English (US)」にすると打てない。上段の数字キーは、どちらでも打てる。ホスト(Arch Linux、sway)でテンキーを打つと、数字が出る。\u003c/p\u003e\n\u003cp\u003eswayの設定に \u003ccode\u003einput * xkb_numlock enabled\u003c/code\u003e を足したが、直らなかった。なぜ効かないのかを、ソースと実測で調べた。\u003c/p\u003e\n\u003ch2 id=\"先に結論\"\u003e先に結論\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eホストのNumLockの状態は、Waydroidの中のAndroidに渡らない。swayの設定は、Waydroidには効かない。\u003c/li\u003e\n\u003cli\u003eAndroidのNumLockは、Waydroidの中で、入った直後に消されている可能性が高い。ソースの読みと実測が合っているが、消す判定の値そのものは、見ていない。\u003c/li\u003e\n\u003cli\u003eAndroidのアプリで、テンキーを数字に割り当てるキーレイアウトを足したら、英語のままテンキーが打てた。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"ソースで分かったこと\"\u003eソースで分かったこと\u003c/h2\u003e\n\u003cp\u003e読んだのは、WaydroidのHWC(\u003ccode\u003eandroid_hardware_waydroid\u003c/code\u003eの\u003ccode\u003ehwcomposer/wayland-hwc.cpp\u003c/code\u003e)と、Android 13(\u003ccode\u003eandroid13-release\u003c/code\u003e)の入力まわり、Waydroidが当てるパッチ(\u003ccode\u003eandroid_vendor_waydroid\u003c/code\u003e)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. ホストのキーは、キーコードのまま渡される。修飾キーの状態は渡されない。\u003c/strong\u003e\nHWCは、Waydroidのウィンドウに入ったキー入力を、キーコードの形で、Android側のパイプ(\u003ccode\u003e/dev/input/wl_keyboard_events\u003c/code\u003e)に書く。Waylandの修飾キーの状態を受け取る関数 \u003ccode\u003ekeyboard_handle_modifiers\u003c/code\u003e は、中身が空になっている。ホストのNumLockがオンでも、Androidはそれを知らない。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. テンキーの数字は、AndroidのNumLockがオンのときだけ出る。\u003c/strong\u003e\nAndroid 13の \u003ccode\u003eGeneric.kcm\u003c/code\u003e では、\u003ccode\u003eNUMPAD_1\u003c/code\u003e は、\u003ccode\u003ebase: fallback MOVE_END\u003c/code\u003e、\u003ccode\u003enumlock: '1'\u003c/code\u003e と定義されている。NumLockがオフなら、Endキーになる。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. NumLockの状態は、キーを離したときに切り替わる。\u003c/strong\u003e\n\u003ccode\u003eKeyboard.cpp\u003c/code\u003e の \u003ccode\u003etoggleLockedMetaState\u003c/code\u003e は、キーを押したときは何もせず、離したときに、状態を反転する。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4. Waydroidが作る入力機器は、出せるキーを2つしか登録していない。\u003c/strong\u003e\nWaydroidのEventHubのパッチ(Android 13用の \u003ccode\u003e0004-EventHub-Add-wayland-inputs-support.patch\u003c/code\u003e)は、\u003ccode\u003ewayland_keyboard\u003c/code\u003e の \u003ccode\u003ekeyBitmask\u003c/code\u003e に、\u003ccode\u003eBTN_MISC\u003c/code\u003e と \u003ccode\u003eKEY_OK\u003c/code\u003e だけを登録する。\nAndroidのEventHubの \u003ccode\u003emarkSupportedKeyCodes\u003c/code\u003e は、キーレイアウトにそのキーがあっても、この登録に無いキーは、「機器に無いキー」と判定する。\u003ccode\u003eKeyboardInputMapper::updateLedState\u003c/code\u003e は、NumLockのキーが無い機器について、NumLockの状態を消す。\nNumLock(コード69)は、この登録に入っていない。\u003c/p\u003e\n\u003ch2 id=\"実測\"\u003e実測\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003edumpsys input\u003c/code\u003e で、入力機器の状態を取った。キー入力の履歴を含まない部分だけを、次のように取り出せる。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003esudo waydroid shell dumpsys input | sed -n '/Input Reader State/,/Input Dispatcher State/p' \u003e out-1.txt\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003ewayland_keyboard\u003c/code\u003e の項目の、\u003ccode\u003eMetaState\u003c/code\u003e(修飾キーとロックの状態)と、\u003ccode\u003eDownTime\u003c/code\u003e(最後にキーが押された時刻)を、見た。\u003c/p\u003e","title":"Waydroidで英語のときだけテンキーが効かない原因を、AndroidとWaydroidのソースから調べた"},{"content":"あるXのポストに、こんな趣旨の不満が書かれていた。公式のスマホアプリからClaude Codeに指示は出せる。ただ、一部の設定やコネクターの再認証のときは、PCのターミナルに戻らされる。外出先でも、そこまでアプリの中で済ませたい、という内容だった。\n私は、この不満が出る形とは別のやり方で使っている。アプリを経由せず、Claude Codeが動いている端末の画面そのものを、スマホで開く。 この記事では、その仕組みと弱点を書く。\n何をしているか PCの端末(ターミナル)の中でClaude Codeを動かしている。その端末の画面を、スマホから、そのまま開いている。\nスマホ側では、a と打つだけで、PCのClaude Codeの画面に入る。PCの前に戻ったら、cc と打てば、同じ画面が出る。どちらから入っても、同じ画面に入る。会話の途中のまま、続けられる。\n端末の画面そのものなので、設定の変更も、再認証も、PCで打つのと同じコマンドを、スマホで打てる。戻る場所が、そもそも無い。\n使っているもの 名前 役割 tmux 端末の中身を保つ。画面を閉じても、接続が切れても、中の作業が残る。あとで同じ画面に入り直せる mosh SSHの仲間。Wi-Fiが変わる、スマホがスリープする、といった回線の切れ目があっても、つなぎ直さずに続く SSH(鍵認証) PCに入るための入口。パスワードでのログインは切って、鍵だけにしている Tailscale 外から自宅のPCに届く経路(VPN) Termux スマホ(Android)側の端末アプリ。ここでmoshを動かす 流れは、こうなる。\nスマホのTermuxで a と打つ。これは、mosh でPCに入り、tmuxの dev というセッションに入る、という命令の短縮(エイリアス)。 SSHでPCにつないだあと、mosh-serverがその場で起動して、UDPで、つなぎ直す。 tmuxの dev に入る。そこで、Claude Codeが動いている。 PCの前では、cc で、同じ dev に入る。cc は、tmux new -A -s dev(あれば入る、無ければ作る)の短縮にしてある。\nつまずいた点 mosh-serverは、常駐しない。 つなぐたびに起動する。誰もつないでいないときに動いていないのは、正常。 moshの -p は、SSHのポートではなく、mosh自身のUDPポート。 SSHのポートを変えているなら、--ssh=\u0026quot;ssh -p ポート番号\u0026quot; の形で渡す。 ロケールが無いと、moshが接続に失敗する。 UTF-8のロケールが必要で、PC側で生成しておかないと、「needs a UTF-8 locale」で止まる。 スマホのTermuxは、Androidに、バックグラウンドで止められることがある。 接続が切れたら、Termuxを開き直す。 弱点 PCが起きていることが前提。 落ちているときは、家のNASから、Wake-on-LANで起こしている(wake-arch という命令にしてある)。 PCを再起動すると、tmuxごと消える。 dev セッションも、中で動いていたClaude Codeも、再起動のたびに作り直しになる。電源が切れていたPCをWake-on-LANで起こした場合も、同じ。会話は、Claude Code側の --continue で、続きから再開できる。 画面が小さい。 長い出力を読むのは、スマホでは辛い。長い出力は、ファイルに書かせて、あとで読む。 日本語の入力は、端末アプリ越しだと、PCの前より手間がかかる。 公式アプリとは、役割が違う。 通知や、アプリの画面での確認は、アプリの方が楽。私は、Remote Control(公式アプリからの指示)も有効にしてあり、必要に応じて使い分けている。 まとめ 公式アプリで足りない場面(設定、再認証)は、端末の画面を、そのままスマホで開けば、戻らずに済む。 必要なのは、tmux、mosh、PCに届く経路、鍵認証のSSH。 弱点は、PCが起きている必要があること、画面が小さいこと。 セキュリティ面では、SSHをパスワードなし(鍵認証のみ)にして、外からは、VPN経由でしか入れない形にしておくのが前提になる。この記事では、ポート番号やアドレスなど、環境の具体的な値は書いていない。\n","permalink":"https://america.github.io/post/2026-10-15-claude-code-from-phone-tmux-mosh/","summary":"\u003cp\u003eあるXのポストに、こんな趣旨の不満が書かれていた。公式のスマホアプリからClaude Codeに指示は出せる。ただ、一部の設定やコネクターの再認証のときは、PCのターミナルに戻らされる。外出先でも、そこまでアプリの中で済ませたい、という内容だった。\u003c/p\u003e\n\u003cp\u003e私は、この不満が出る形とは別のやり方で使っている。\u003cstrong\u003eアプリを経由せず、Claude Codeが動いている端末の画面そのものを、スマホで開く。\u003c/strong\u003e この記事では、その仕組みと弱点を書く。\u003c/p\u003e\n\u003ch2 id=\"何をしているか\"\u003e何をしているか\u003c/h2\u003e\n\u003cp\u003ePCの端末(ターミナル)の中でClaude Codeを動かしている。その端末の画面を、スマホから、そのまま開いている。\u003c/p\u003e\n\u003cp\u003eスマホ側では、\u003ccode\u003ea\u003c/code\u003e と打つだけで、PCのClaude Codeの画面に入る。PCの前に戻ったら、\u003ccode\u003ecc\u003c/code\u003e と打てば、同じ画面が出る。どちらから入っても、同じ画面に入る。会話の途中のまま、続けられる。\u003c/p\u003e\n\u003cp\u003e端末の画面そのものなので、設定の変更も、再認証も、PCで打つのと同じコマンドを、スマホで打てる。戻る場所が、そもそも無い。\u003c/p\u003e\n\u003ch2 id=\"使っているもの\"\u003e使っているもの\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e名前\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e役割\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003etmux\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e端末の中身を保つ。画面を閉じても、接続が切れても、中の作業が残る。あとで同じ画面に入り直せる\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003emosh\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSSHの仲間。Wi-Fiが変わる、スマホがスリープする、といった回線の切れ目があっても、つなぎ直さずに続く\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSSH(鍵認証)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePCに入るための入口。パスワードでのログインは切って、鍵だけにしている\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eTailscale\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e外から自宅のPCに届く経路(VPN)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eTermux\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eスマホ(Android)側の端末アプリ。ここでmoshを動かす\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e流れは、こうなる。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eスマホのTermuxで \u003ccode\u003ea\u003c/code\u003e と打つ。これは、\u003ccode\u003emosh\u003c/code\u003e でPCに入り、tmuxの \u003ccode\u003edev\u003c/code\u003e というセッションに入る、という命令の短縮(エイリアス)。\u003c/li\u003e\n\u003cli\u003eSSHでPCにつないだあと、mosh-serverがその場で起動して、UDPで、つなぎ直す。\u003c/li\u003e\n\u003cli\u003etmuxの \u003ccode\u003edev\u003c/code\u003e に入る。そこで、Claude Codeが動いている。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003ePCの前では、\u003ccode\u003ecc\u003c/code\u003e で、同じ \u003ccode\u003edev\u003c/code\u003e に入る。\u003ccode\u003ecc\u003c/code\u003e は、\u003ccode\u003etmux new -A -s dev\u003c/code\u003e(あれば入る、無ければ作る)の短縮にしてある。\u003c/p\u003e\n\u003ch2 id=\"つまずいた点\"\u003eつまずいた点\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003emosh-serverは、常駐しない。\u003c/strong\u003e つなぐたびに起動する。誰もつないでいないときに動いていないのは、正常。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003emoshの \u003ccode\u003e-p\u003c/code\u003e は、SSHのポートではなく、mosh自身のUDPポート。\u003c/strong\u003e SSHのポートを変えているなら、\u003ccode\u003e--ssh=\u0026quot;ssh -p ポート番号\u0026quot;\u003c/code\u003e の形で渡す。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eロケールが無いと、moshが接続に失敗する。\u003c/strong\u003e UTF-8のロケールが必要で、PC側で生成しておかないと、「needs a UTF-8 locale」で止まる。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eスマホのTermuxは、Androidに、バックグラウンドで止められることがある。\u003c/strong\u003e 接続が切れたら、Termuxを開き直す。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"弱点\"\u003e弱点\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePCが起きていることが前提。\u003c/strong\u003e 落ちているときは、家のNASから、Wake-on-LANで起こしている(\u003ccode\u003ewake-arch\u003c/code\u003e という命令にしてある)。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePCを再起動すると、tmuxごと消える。\u003c/strong\u003e \u003ccode\u003edev\u003c/code\u003e セッションも、中で動いていたClaude Codeも、再起動のたびに作り直しになる。電源が切れていたPCをWake-on-LANで起こした場合も、同じ。会話は、Claude Code側の \u003ccode\u003e--continue\u003c/code\u003e で、続きから再開できる。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e画面が小さい。\u003c/strong\u003e 長い出力を読むのは、スマホでは辛い。長い出力は、ファイルに書かせて、あとで読む。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e日本語の入力は、端末アプリ越しだと、PCの前より手間がかかる。\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e公式アプリとは、役割が違う。\u003c/strong\u003e 通知や、アプリの画面での確認は、アプリの方が楽。私は、Remote Control(公式アプリからの指示)も有効にしてあり、必要に応じて使い分けている。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e公式アプリで足りない場面(設定、再認証)は、端末の画面を、そのままスマホで開けば、戻らずに済む。\u003c/li\u003e\n\u003cli\u003e必要なのは、tmux、mosh、PCに届く経路、鍵認証のSSH。\u003c/li\u003e\n\u003cli\u003e弱点は、PCが起きている必要があること、画面が小さいこと。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eセキュリティ面では、SSHをパスワードなし(鍵認証のみ)にして、外からは、VPN経由でしか入れない形にしておくのが前提になる。この記事では、ポート番号やアドレスなど、環境の具体的な値は書いていない。\u003c/p\u003e","title":"出先のスマホから、PCのClaude Codeを設定まで含めて操作する(tmux + mosh)"},{"content":"このページは、個人用ツール「gtasks」のプライバシーポリシーです。gtasks は、運営者本人が、自分の Google ToDo を端末から読み書きするためのプログラムです。\n取得する情報 運営者本人の Google ToDo(タスクの一覧と内容)だけです。運営者本人のアカウントにだけ、接続します。\n利用目的 運営者本人が、自分のタスクを読み書きするためと、未完了のタスクの一覧や、予定時刻が近いタスクを、自分宛てのメールで知らせるためだけに使います。\n第三者への提供と保存 第三者への提供は、しません。メールの送信先は、運営者本人のアドレスだけです。タスクの内容は、運営者本人の Google アカウントの中の Google ToDo、Gmail(通知メール)、Google Apps Script(通知済みの記録。日付とタスクの識別子)にあります。運営者本人の Google アカウントの外や、Google 以外のサービスには、保存しません。パソコンで使う認可の情報は、運営者本人のパソコンの中にだけ置きます。\n","permalink":"https://america.github.io/privacy/","summary":"\u003cp\u003eこのページは、個人用ツール「gtasks」のプライバシーポリシーです。gtasks は、運営者本人が、自分の Google ToDo を端末から読み書きするためのプログラムです。\u003c/p\u003e\n\u003ch2 id=\"取得する情報\"\u003e取得する情報\u003c/h2\u003e\n\u003cp\u003e運営者本人の Google ToDo(タスクの一覧と内容)だけです。運営者本人のアカウントにだけ、接続します。\u003c/p\u003e\n\u003ch2 id=\"利用目的\"\u003e利用目的\u003c/h2\u003e\n\u003cp\u003e運営者本人が、自分のタスクを読み書きするためと、未完了のタスクの一覧や、予定時刻が近いタスクを、自分宛てのメールで知らせるためだけに使います。\u003c/p\u003e\n\u003ch2 id=\"第三者への提供と保存\"\u003e第三者への提供と保存\u003c/h2\u003e\n\u003cp\u003e第三者への提供は、しません。メールの送信先は、運営者本人のアドレスだけです。タスクの内容は、運営者本人の Google アカウントの中の Google ToDo、Gmail(通知メール)、Google Apps Script(通知済みの記録。日付とタスクの識別子)にあります。運営者本人の Google アカウントの外や、Google 以外のサービスには、保存しません。パソコンで使う認可の情報は、運営者本人のパソコンの中にだけ置きます。\u003c/p\u003e","title":"プライバシーポリシー"},{"content":"数年間、SES(システムエンジニアリングサービス)の協力会社として、銀行系のシステム開発現場に常駐していた時期がある。自分と最終的な発注元(客)の間に何社入っているのか、正直よく分からなかった。各段階でマージンが抜かれ、現場に来るころには話が何重にも薄まっている。この記事では、特定の会社や個人の話ではなく、その構造そのものについて書く。\n「人月」とは何か IT業界、特にSIer(システムインテグレーター)が元請けになる受託開発の現場では、契約や見積もりが「人月(にんげつ)」という単位で組まれることが多い。「エンジニア1人を1か月アサインする」のが1人月で、プロジェクトの規模は「10人月」「50人月」のように、人数×期間の掛け算で表現される。\n成果物の価値や難易度ではなく、頭数と時間だけで値段が決まる。優秀なエンジニアが1人で終わらせる仕事も、未経験者が3人がかりでやる仕事も、同じ「3人月」なら同じ金額になりうる。\n多重下請けの中はどう見えるか 自分が実際にいた現場は、発注元の銀行 → 元請けSIer → 2次請け → 3次請け(自分の所属会社)、という構造だった。各段階で中間マージンが抜かれるので、客が払っている金額と、実際に現場で働く自分の手取りの間には、かなりの開きがある。\n現場では、自分がどの会社の人間かということより「誰の下で働いているか」の方が重要になる。常駐先の実質的な上司は、客でも元請けでもなく、別の協力会社から出向してきた人間だったりする。これは「偽装請負」と呼ばれる状態で、グレーゾーンというより、職業安定法44条が禁じる「労働者供給事業」そのものに触れうる。同条は「何人も……労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない」と定めており、契約上は請負・準委任なのに実態として他社の指揮命令を受けて働かせる形は、この禁止に抵触する(出典)。SES・準委任契約の現場では、この境界線上の運用がしばしば起きる。\n求人票の給与額に通勤手当を混ぜて実質的に水増しする、というようなことも、珍しくない手口として見てきた。職業安定法5条の3は、求人者に賃金額を含む労働条件の明示を義務づけており、虚偽の条件を提示して募集を行った場合、同法65条により6か月以下の拘禁刑または30万円以下の罰金の対象になる(出典)。\n業界団体側の調査でも、SES企業が取るマージン率は平均で35〜40%程度、エンジニアへの還元率はおよそ60〜65%が相場とされている(出典)。つまり客が単価80万円を払っていても、現場のエンジニアの手元に残るのはその6割強、という配分が業界の標準として扱われている。これは1段階のマージンの話で、間にもう1社挟まれば、さらに削られる。\n数字で見る多重下請け構造 体感でしかなかった話を、公的な調査と照らし合わせてみる。\n公正取引委員会が2022年に公表した実態調査(資本金3億円以下の事業者 約2万1,000社が対象、18年ぶりの大規模調査)によると、ソフトウェア制作の取引では「細分化と再委託の繰り返しで商流が多層化・複雑化し、極端に長い商流が形成される場合がある」とされ、最大で6次下請けの事例が報告されている。調査対象事業者の取引上の立場は、元請が40.4%、中間下請が38.2%、最終下請が21.3%で、実に約6割が、客と直接の契約関係を持たない下請けの立場にあった(出典)。\n同調査によれば、日本のソフトウェア業の市場規模は2020年時点で約15兆9,791億円、従業者数は約83万7,606人、事業所数は2万5,977か所。そのうち従業者4人以下の零細事業所が全体の約40.3%を占める。自分がいたような小さな協力会社は、例外ではなく、この業界の典型的な構成要素だということになる。\n下請法(下請代金支払遅延等防止法)4条1項は、親事業者による受領拒否(1号)・支払遅延(2号)・代金減額(3号)・返品(4号)・買いたたき(5号、「通常支払われる対価に比し著しく低い下請代金の額を不当に定めること」)・購入利用強制(6号)などを禁止している。下請法はもともと、独占禁止法が規制する「優越的地位の濫用」のうち、取引上弱い立場になりやすい下請取引に絞って、より摘発しやすい形で切り出した特別法という位置づけにある(出典)。\n下請法違反による措置件数(令和3年度)は、情報サービス業が686件で、全業種の中で最多だった。マージンを多段階で抜く多重下請け構造そのものが、下請法が禁じる行為(とりわけ買いたたき)が起きやすい土壌になっていることを、この件数が裏付けている。\nなぜこの構造は無くならないのか 発注側に内製力が無い 大企業・官公庁の多くは、自前でシステムを開発・保守する体制を持っていない。仕様を固める力も、技術を評価する力も社内に無いため、丸ごと外注することになる。元請けSIerは、その仕様の曖昧さごと請け負い、さらに下に投げる。\n人月は「稟議を通しやすい」 「Xという価値を生むシステムにY円払う」という成果ベースの契約は、発注側にとって説明しにくい。一方「X人×Yか月×単価」という人月の積み上げは、稟議や調達の書類に落とし込みやすい。見積もりの根拠として扱いやすいことが、技術的に優れているかどうかより優先される。\n契約形態がリスクを現場に寄せる 仕様が固まらないまま始まるプロジェクトは、請負契約(成果物に対して責任を負う)では受けにくい。だから準委任契約(人を貸す形)で始まることが多く、プロジェクトが炎上しても「言われた作業はやった」という形で、リスクの多くが現場の労働者側に流れる。\nなぜ日本だけこの形になったのか 多重下請け構造自体は海外にも存在するが、日本の際立った特徴は「IT人材の大半がベンダー(IT企業)側にいて、客となる事業会社側にはほとんどいない」という偏りだ。\nIPA(情報処理推進機構)の「IT人材白書2017」によれば、日本はIT人材の72.3%がIT産業(ベンダー側)に所属し、非IT産業(ユーザー企業側)に所属するのはわずか27.7%。これに対し米国では、IT人材の65.4%がユーザー企業側に所属しており、ベンダー側は34.6%にとどまる。カナダ・英国・ドイツ・フランスも軒並みユーザー企業側が過半数で、日本の偏りは比較対象の欧米各国の中でも際立っている(出典)。\nつまり米国では「システムを使う会社」自身が技術者を雇って内製するのが主流なのに対し、日本では「システムを使う会社」はほぼ技術者を抱えず、「技術者を派遣・常駐させる会社」という別の産業が間に挟まる構造が標準になっている。多重下請けが生まれる土壌は、この人材配置の偏り自体にあると考えている。\n小泉改革が原因なのか この話をすると「2004年、小泉内閣が労働者派遣法を改正して派遣を自由化したのが原因では」と聞かれることがある。半分当たっていて、半分違う。\n労働者派遣法そのものは1986年(中曽根内閣)に制定された法律で、制定当初から対象業務16業務の中にソフトウェア開発が含まれていた。つまりIT業界で技術者を客先に常駐させる仕組み自体は、法律の出発点から想定されていたもので、小泉改革より18年も前からある。1999年(小渕内閣)には、許可業務を決める方式から禁止業務だけを指定する方式(ネガティブリスト化)への転換で原則自由化され、2004年(小泉内閣)の改正で変わったのは、それまで禁止されていた製造業への派遣解禁だった(出典)。つまり小泉改革が直接狙い撃ちにしたのはIT業界ではなく製造業で、IT業界の多重下請け構造の土台はそれよりずっと前から存在していたことになる。\nむしろこの記事で問題にした「偽装請負」(指揮命令が契約関係と一致しない状態)は、労働者派遣法の規制が緩くなったから起きるというより逆で、派遣法が課す責任(派遣期間の上限、派遣先の義務など)を避けるために、企業側が正式な労働者派遣ではなく請負・準委任契約を使うことで起きる現象に近い。規制緩和というより、規制を迂回する動きの産物だと考えている。\n「見直される」のではなく、「人が逃げる」 この業界がある日突然見直される、という形の変化は来ないと思っている。実際に起きているのは、もっと静かな浸食だ。\n経済産業省は2018年の「DXレポート」で、老朽化した基幹システム(レガシーシステム)がDXの足かせになっていると指摘し、対応が遅れた場合2025年以降に最大で年間12兆円規模の経済損失が生じるという試算を示した(出典)。いわゆる「2025年の崖」で、同じレポートでは2025年に最大43万人のIT人材が不足するとも見積もられている。\n事業会社側の内製化は、この数年でじわじわ進んでいる。技術に関心があって優秀な人ほど、多重下請けの現場から事業会社側へ流出していく。すると残った現場の技術力の平均が下がり、さらに優秀な人材が入ってこなくなる――という自己強化型のループが働く。\n面白い仕事とまともな待遇は事業会社側に集まり、SES層にはレガシー保守や人手不足を埋める仕事が残り続ける。需要そのものが無くならない以上、業界の底辺としては長く生き残る。「業界構造が改まる」のではなく、「動ける人から順に抜けていく」形で、中身だけが少しずつ入れ替わっていくのだと思う。\n唯一の変数は生成AI この構造を崩しうるとしたら、一番の変数は生成AIだと考えている。1人あたりの生産性が本当に底上げされれば、「頭数×時間」で積み上げる人月という単位そのものが、価格の目安として成立しなくなる可能性がある。\nただし楽観はしていない。起きるとしたら「人月という評価モデルが見直される」方向よりも、「下請けの中でも一番下の、単純作業に近い層がまるごと要らなくなって、業界全体が縮む」方向に出る公算の方が高いと思っている。\n出典 経済産業省「DXレポート」(2018)の「2025年の崖」解説 - 日立ソリューションズ・クリエイト ソフトウェア業の下請取引等に関する実態調査報告書(2022年6月公表) - 公正取引委員会 平成30年版 情報通信白書 日米のICT人材の比較 - 総務省 SESの単価相場一覧 - レバテック 職業安定法 条文(44条・5条の3・65条) - 法令リード 下請法で禁止されている「買いたたき」とは - BUSINESS LAWYERS 【早見表】労働者派遣法改正の歴史をわかりやすく解説 - マンパワーグループ ","permalink":"https://america.github.io/post/2026-10-04-ses-tiered-subcontracting-man-month/","summary":"\u003cp\u003e数年間、SES(システムエンジニアリングサービス)の協力会社として、銀行系のシステム開発現場に常駐していた時期がある。自分と最終的な発注元(客)の間に何社入っているのか、正直よく分からなかった。各段階でマージンが抜かれ、現場に来るころには話が何重にも薄まっている。この記事では、特定の会社や個人の話ではなく、その構造そのものについて書く。\u003c/p\u003e\n\u003ch2 id=\"人月とは何か\"\u003e「人月」とは何か\u003c/h2\u003e\n\u003cp\u003eIT業界、特にSIer(システムインテグレーター)が元請けになる受託開発の現場では、契約や見積もりが「人月(にんげつ)」という単位で組まれることが多い。「エンジニア1人を1か月アサインする」のが1人月で、プロジェクトの規模は「10人月」「50人月」のように、人数×期間の掛け算で表現される。\u003c/p\u003e\n\u003cp\u003e成果物の価値や難易度ではなく、\u003cstrong\u003e頭数と時間だけで値段が決まる\u003c/strong\u003e。優秀なエンジニアが1人で終わらせる仕事も、未経験者が3人がかりでやる仕事も、同じ「3人月」なら同じ金額になりうる。\u003c/p\u003e\n\u003ch2 id=\"多重下請けの中はどう見えるか\"\u003e多重下請けの中はどう見えるか\u003c/h2\u003e\n\u003cp\u003e自分が実際にいた現場は、発注元の銀行 → 元請けSIer → 2次請け → 3次請け(自分の所属会社)、という構造だった。各段階で中間マージンが抜かれるので、客が払っている金額と、実際に現場で働く自分の手取りの間には、かなりの開きがある。\u003c/p\u003e\n\u003cp\u003e現場では、自分がどの会社の人間かということより「誰の下で働いているか」の方が重要になる。常駐先の実質的な上司は、客でも元請けでもなく、別の協力会社から出向してきた人間だったりする。これは「偽装請負」と呼ばれる状態で、グレーゾーンというより、職業安定法44条が禁じる「労働者供給事業」そのものに触れうる。同条は「何人も……労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない」と定めており、契約上は請負・準委任なのに実態として他社の指揮命令を受けて働かせる形は、この禁止に抵触する(\u003ca href=\"https://hourei.net/law/322AC0000000141\"\u003e出典\u003c/a\u003e)。SES・準委任契約の現場では、この境界線上の運用がしばしば起きる。\u003c/p\u003e\n\u003cp\u003e求人票の給与額に通勤手当を混ぜて実質的に水増しする、というようなことも、珍しくない手口として見てきた。職業安定法5条の3は、求人者に賃金額を含む労働条件の明示を義務づけており、虚偽の条件を提示して募集を行った場合、同法65条により6か月以下の拘禁刑または30万円以下の罰金の対象になる(\u003ca href=\"https://hourei.net/law/322AC0000000141\"\u003e出典\u003c/a\u003e)。\u003c/p\u003e\n\u003cp\u003e業界団体側の調査でも、SES企業が取るマージン率は平均で35〜40%程度、エンジニアへの還元率はおよそ60〜65%が相場とされている(\u003ca href=\"https://levtech.jp/partner/guide/article/detail/32/\"\u003e出典\u003c/a\u003e)。つまり客が単価80万円を払っていても、現場のエンジニアの手元に残るのはその6割強、という配分が業界の標準として扱われている。これは1段階のマージンの話で、間にもう1社挟まれば、さらに削られる。\u003c/p\u003e\n\u003ch2 id=\"数字で見る多重下請け構造\"\u003e数字で見る多重下請け構造\u003c/h2\u003e\n\u003cp\u003e体感でしかなかった話を、公的な調査と照らし合わせてみる。\u003c/p\u003e\n\u003cp\u003e公正取引委員会が2022年に公表した実態調査(資本金3億円以下の事業者 約2万1,000社が対象、18年ぶりの大規模調査)によると、ソフトウェア制作の取引では「細分化と再委託の繰り返しで商流が多層化・複雑化し、極端に長い商流が形成される場合がある」とされ、\u003cstrong\u003e最大で6次下請けの事例\u003c/strong\u003eが報告されている。調査対象事業者の取引上の立場は、元請が40.4%、中間下請が38.2%、最終下請が21.3%で、\u003cstrong\u003e実に約6割が、客と直接の契約関係を持たない下請けの立場\u003c/strong\u003eにあった(\u003ca href=\"https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_sw_03.pdf\"\u003e出典\u003c/a\u003e)。\u003c/p\u003e\n\u003cp\u003e同調査によれば、日本のソフトウェア業の市場規模は2020年時点で約15兆9,791億円、従業者数は約83万7,606人、事業所数は2万5,977か所。そのうち従業者4人以下の零細事業所が全体の約40.3%を占める。自分がいたような小さな協力会社は、例外ではなく、この業界の典型的な構成要素だということになる。\u003c/p\u003e\n\u003cp\u003e下請法(下請代金支払遅延等防止法)4条1項は、親事業者による受領拒否(1号)・支払遅延(2号)・代金減額(3号)・返品(4号)・\u003cstrong\u003e買いたたき\u003c/strong\u003e(5号、「通常支払われる対価に比し著しく低い下請代金の額を不当に定めること」)・購入利用強制(6号)などを禁止している。下請法はもともと、独占禁止法が規制する「優越的地位の濫用」のうち、取引上弱い立場になりやすい下請取引に絞って、より摘発しやすい形で切り出した特別法という位置づけにある(\u003ca href=\"https://www.businesslawyers.jp/practices/136\"\u003e出典\u003c/a\u003e)。\u003c/p\u003e\n\u003cp\u003e下請法違反による措置件数(令和3年度)は、情報サービス業が686件で、\u003cstrong\u003e全業種の中で最多\u003c/strong\u003eだった。マージンを多段階で抜く多重下請け構造そのものが、下請法が禁じる行為(とりわけ買いたたき)が起きやすい土壌になっていることを、この件数が裏付けている。\u003c/p\u003e\n\u003ch2 id=\"なぜこの構造は無くならないのか\"\u003eなぜこの構造は無くならないのか\u003c/h2\u003e\n\u003ch3 id=\"発注側に内製力が無い\"\u003e発注側に内製力が無い\u003c/h3\u003e\n\u003cp\u003e大企業・官公庁の多くは、自前でシステムを開発・保守する体制を持っていない。仕様を固める力も、技術を評価する力も社内に無いため、丸ごと外注することになる。元請けSIerは、その仕様の曖昧さごと請け負い、さらに下に投げる。\u003c/p\u003e\n\u003ch3 id=\"人月は稟議を通しやすい\"\u003e人月は「稟議を通しやすい」\u003c/h3\u003e\n\u003cp\u003e「Xという価値を生むシステムにY円払う」という成果ベースの契約は、発注側にとって説明しにくい。一方「X人×Yか月×単価」という人月の積み上げは、稟議や調達の書類に落とし込みやすい。見積もりの根拠として扱いやすいことが、技術的に優れているかどうかより優先される。\u003c/p\u003e\n\u003ch3 id=\"契約形態がリスクを現場に寄せる\"\u003e契約形態がリスクを現場に寄せる\u003c/h3\u003e\n\u003cp\u003e仕様が固まらないまま始まるプロジェクトは、請負契約(成果物に対して責任を負う)では受けにくい。だから準委任契約(人を貸す形)で始まることが多く、プロジェクトが炎上しても「言われた作業はやった」という形で、リスクの多くが現場の労働者側に流れる。\u003c/p\u003e\n\u003ch2 id=\"なぜ日本だけこの形になったのか\"\u003eなぜ日本だけこの形になったのか\u003c/h2\u003e\n\u003cp\u003e多重下請け構造自体は海外にも存在するが、日本の際立った特徴は「IT人材の大半がベンダー(IT企業)側にいて、客となる事業会社側にはほとんどいない」という偏りだ。\u003c/p\u003e\n\u003cp\u003eIPA(情報処理推進機構)の「IT人材白書2017」によれば、日本はIT人材の\u003cstrong\u003e72.3%がIT産業(ベンダー側)に所属\u003c/strong\u003eし、非IT産業(ユーザー企業側)に所属するのはわずか27.7%。これに対し米国では、IT人材の65.4%がユーザー企業側に所属しており、ベンダー側は34.6%にとどまる。カナダ・英国・ドイツ・フランスも軒並みユーザー企業側が過半数で、日本の偏りは比較対象の欧米各国の中でも際立っている(\u003ca href=\"https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd114140.html\"\u003e出典\u003c/a\u003e)。\u003c/p\u003e\n\u003cp\u003eつまり米国では「システムを使う会社」自身が技術者を雇って内製するのが主流なのに対し、日本では「システムを使う会社」はほぼ技術者を抱えず、「技術者を派遣・常駐させる会社」という別の産業が間に挟まる構造が標準になっている。多重下請けが生まれる土壌は、この人材配置の偏り自体にあると考えている。\u003c/p\u003e\n\u003ch2 id=\"小泉改革が原因なのか\"\u003e小泉改革が原因なのか\u003c/h2\u003e\n\u003cp\u003eこの話をすると「2004年、小泉内閣が労働者派遣法を改正して派遣を自由化したのが原因では」と聞かれることがある。半分当たっていて、半分違う。\u003c/p\u003e\n\u003cp\u003e労働者派遣法そのものは1986年(中曽根内閣)に制定された法律で、制定当初から対象業務16業務の中に\u003cstrong\u003eソフトウェア開発\u003c/strong\u003eが含まれていた。つまりIT業界で技術者を客先に常駐させる仕組み自体は、法律の出発点から想定されていたもので、小泉改革より18年も前からある。1999年(小渕内閣)には、許可業務を決める方式から禁止業務だけを指定する方式(ネガティブリスト化)への転換で原則自由化され、2004年(小泉内閣)の改正で変わったのは、それまで禁止されていた\u003cstrong\u003e製造業\u003c/strong\u003eへの派遣解禁だった(\u003ca href=\"https://www.manpowergroup.jp/client/manpowerclip/temporary/workerdispatchingact.html\"\u003e出典\u003c/a\u003e)。つまり小泉改革が直接狙い撃ちにしたのはIT業界ではなく製造業で、IT業界の多重下請け構造の土台はそれよりずっと前から存在していたことになる。\u003c/p\u003e\n\u003cp\u003eむしろこの記事で問題にした「偽装請負」(指揮命令が契約関係と一致しない状態)は、労働者派遣法の規制が緩くなったから起きるというより逆で、\u003cstrong\u003e派遣法が課す責任(派遣期間の上限、派遣先の義務など)を避けるために、企業側が正式な労働者派遣ではなく請負・準委任契約を使う\u003c/strong\u003eことで起きる現象に近い。規制緩和というより、規制を迂回する動きの産物だと考えている。\u003c/p\u003e\n\u003ch2 id=\"見直されるのではなく人が逃げる\"\u003e「見直される」のではなく、「人が逃げる」\u003c/h2\u003e\n\u003cp\u003eこの業界がある日突然見直される、という形の変化は来ないと思っている。実際に起きているのは、もっと静かな浸食だ。\u003c/p\u003e\n\u003cp\u003e経済産業省は2018年の「DXレポート」で、老朽化した基幹システム(レガシーシステム)がDXの足かせになっていると指摘し、対応が遅れた場合2025年以降に最大で年間12兆円規模の経済損失が生じるという試算を示した(\u003ca href=\"https://www.hitachi-solutions-create.co.jp/column/core-system/2025-cliff.html\"\u003e出典\u003c/a\u003e)。いわゆる「2025年の崖」で、同じレポートでは2025年に最大43万人のIT人材が不足するとも見積もられている。\u003c/p\u003e\n\u003cp\u003e事業会社側の内製化は、この数年でじわじわ進んでいる。技術に関心があって優秀な人ほど、多重下請けの現場から事業会社側へ流出していく。すると残った現場の技術力の平均が下がり、さらに優秀な人材が入ってこなくなる――という自己強化型のループが働く。\u003c/p\u003e\n\u003cp\u003e面白い仕事とまともな待遇は事業会社側に集まり、SES層にはレガシー保守や人手不足を埋める仕事が残り続ける。需要そのものが無くならない以上、業界の底辺としては長く生き残る。「業界構造が改まる」のではなく、「動ける人から順に抜けていく」形で、中身だけが少しずつ入れ替わっていくのだと思う。\u003c/p\u003e\n\u003ch2 id=\"唯一の変数は生成ai\"\u003e唯一の変数は生成AI\u003c/h2\u003e\n\u003cp\u003eこの構造を崩しうるとしたら、一番の変数は生成AIだと考えている。1人あたりの生産性が本当に底上げされれば、「頭数×時間」で積み上げる人月という単位そのものが、価格の目安として成立しなくなる可能性がある。\u003c/p\u003e\n\u003cp\u003eただし楽観はしていない。起きるとしたら「人月という評価モデルが見直される」方向よりも、「下請けの中でも一番下の、単純作業に近い層がまるごと要らなくなって、業界全体が縮む」方向に出る公算の方が高いと思っている。\u003c/p\u003e\n\u003ch2 id=\"出典\"\u003e出典\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hitachi-solutions-create.co.jp/column/core-system/2025-cliff.html\"\u003e経済産業省「DXレポート」(2018)の「2025年の崖」解説 - 日立ソリューションズ・クリエイト\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_sw_03.pdf\"\u003eソフトウェア業の下請取引等に関する実態調査報告書(2022年6月公表) - 公正取引委員会\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd114140.html\"\u003e平成30年版 情報通信白書 日米のICT人材の比較 - 総務省\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://levtech.jp/partner/guide/article/detail/32/\"\u003eSESの単価相場一覧 - レバテック\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://hourei.net/law/322AC0000000141\"\u003e職業安定法 条文(44条・5条の3・65条) - 法令リード\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.businesslawyers.jp/practices/136\"\u003e下請法で禁止されている「買いたたき」とは - BUSINESS LAWYERS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.manpowergroup.jp/client/manpowerclip/temporary/workerdispatchingact.html\"\u003e【早見表】労働者派遣法改正の歴史をわかりやすく解説 - マンパワーグループ\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"SES・多重下請けの「人月商売」はなぜ無くならないのか"},{"content":"音量を調整しようとpavucontrolを開いたら、こう言われた。\npa_context_get_card_info_by_index() 失敗: Invalid argument Copy それだけ。開かない。\n環境はArch Linux、sway、PipeWire 1.6.8、WirePlumber 0.5.16。よくある「PulseAudio互換レイヤーが機嫌を損ねた」系の話に見えたが、実際に追ってみたら、思ったより下の層まで潜る羽目になった。\nまず journalctl systemctl --user status pipewire pipewire-pulse wireplumber でログを見ると、pipewireとwireplumberが3〜5秒おきに同じエラーを吐き続けていた。しかも調査してる最中もリアルタイムで進行中。\npipewire: spa.alsa: 'front:0': capture open failed: デバイスもしくはリソースがビジー状態です pipewire: pw.node: (alsa_input.usb-Kingston_HyperX_Quadcast_4110-00.analog-stereo-94) suspended -\u003e error (Start error: デバイスもしくはリソースがビジー状態です) wireplumber: s-monitors: Failed to create ALSA node alsa_input.usb-Kingston_HyperX_Quadcast_4110-00.analog-stereo: Object activation aborted: PipeWire proxy destroyed wireplumber: wplua: [string \"alsa.lua\"]:446: attempt to call a nil value (method 'store_managed_pending') Copy 犯人らしきデバイス名が出ている。USBマイク（Kingston HyperX Quadcast）だ。\nfuser -v /dev/snd/* で確認したが、掴んでいるのはwireplumber/pipewire自身だけ。Discordや他のアプリがマイクを横取りしているわけではなかった。PipeWireの中だけで完結して壊れている。\nエラーメッセージに「Lua」と書いてある ログをよく見ると wplua: [string \u0026quot;alsa.lua\u0026quot;]:446 とある。C言語のデーモンのはずなのに、なぜLuaのエラーが出てくるのか。\nWirePlumber本体（デーモンのコア部分）はC（GLib/GObject）で書かれている。ただし、ALSA・Bluetooth・カメラなどのデバイスをどう扱うか、というポリシー寄りのロジックは .lua スクリプトとして外に出されている。/usr/share/wireplumber/scripts/monitors/alsa.lua が、まさにそれだ。\nこれは意図的な設計変更の結果。WirePlumberの前身にあたる pipewire-media-session は、この手のロジックも含めて全部Cで固定実装されていた。WirePlumberは、そこをLuaスクリプト化することで、デーモン本体を再コンパイルせずに、デバイスの扱い方やポリシーをカスタマイズできるようにした。parent:store_managed_pending() のようなメソッドは、C側で実装された関数を、Luaから呼べるようにバインディングしたものだ。\nつまり今回のバグは、WirePlumberの中の「Cで書かれた堅い部分」と「Luaで書かれた柔らかい部分」の境界で起きている。C側のオブジェクトの生死（プロキシが破棄されたかどうか）を、非同期コールバックの中のLuaコードが正しく把握できていなかった、という話になる。\nソースを読む wplua: [string \u0026quot;alsa.lua\u0026quot;]:446 という行番号まで出ているので、実際のファイルを読みに行く。\n/usr/share/wireplumber/scripts/monitors/alsa.lua Copy 446行目はここだった。\n-- create the node local node = Node(\"adapter\", properties) parent:set_managed_pending(id) node:activate(Features.ALL, function (n, err) if err then log:warning (\"Failed to create ALSA node \" .. tostring (properties[\"node.name\"]) .. \": \" .. tostring(err)) parent:store_managed_pending(id, nil) -- ← ここ else monitorNodeError (n) parent:store_managed_object(id, n) end end) Copy node:activate() は非同期処理で、完了したときにコールバックが呼ばれる。今回のように内部のALSAデバイスが「ビジー」で失敗すると（errが立つ）、後片付けとして parent:store_managed_pending(id, nil) を呼ぶ設計になっている。\n最初は「parentが非同期の途中で破棄されて、無効なオブジェクトになっているのでは」と当たりをつけた。だが、それだけでは説明がつかない部分があった。NodeやDeviceのクラス定義自体がLua側に無く、全部C側のオブジェクトをバインディングしたものだ。「オブジェクトが破棄されてメソッドが消える」という挙動は、WirePlumberのLuaバインディングの作りからすると、ちょっと不自然に思えた。\n気になったので、WirePlumberのGitリポジトリをクローンして、Lua↔Cの境界を直接見に行くことにした。\ngit clone --depth 1 --branch 0.5.16 \\ https://gitlab.freedesktop.org/pipewire/wireplumber.git Copy parent（WpSpaDeviceのLuaラッパー）にどんなメソッドがバインドされているか、Cの登録テーブルを見る。\n// modules/module-lua-scripting/api/api.c static const luaL_Reg spa_device_methods[] = { { \"iterate_params\", spa_device_iterate_params }, { \"set_param\", spa_device_set_param }, { \"iterate_managed_objects\", spa_device_iterate_managed_objects }, { \"get_managed_object\", spa_device_get_managed_object }, { \"store_managed_object\", spa_device_store_managed_object }, { \"set_managed_pending\", spa_device_set_managed_pending }, { NULL, NULL } }; Copy store_managed_object と set_managed_pending はある。store_managed_pending という名前のメソッドは、どこにも登録されていない。\n念のため、リポジトリ全体の履歴を git log --all -S \u0026quot;store_managed_pending\u0026quot; -- '*.c' '*.h' で検索した。ヒットはゼロ。このメソッドは、C側に一度も存在したことがない。\nつまり parent:store_managed_pending(id, nil) は、最初から存在しない名前を呼んでいる。オブジェクトが生きているか死んでいるかに関係なく、このコードパスを通れば必ず nil 呼び出しでクラッシュする。レースコンディションというより、ただのタイポに近い。\ngit blame で、この行がいつ入ったかを追った。\ne923c93a Julian Bouzas 2026-08-25 alsa: Always activate all device and node features Copy commitメッセージ：\nalsa: Always activate all device and node features\nAlso avoid using the param node properties when logging warning if device or node failed to activate, because the properties might be NULL if the node or device was destroyed before finishing activation.\nSee #996\n皮肉なことに、このコミット自体が「デバイス/ノードが活性化完了前に破棄されるとNULL参照でクラッシュする」という、私が最初に疑った方向のバグを直すためのものだった（アップストリームのissue #996）。実際の差分がこれ。\n-- create the node local node = Node(\"adapter\", properties) parent:set_managed_pending(id) - node:activate(Feature.Proxy.BOUND, function (n, err) + node:activate(Features.ALL, function (n, err) if err then log:warning (\"Failed to create ALSA node \" .. - n:get_property (\"node.name\") .. \": \" .. tostring(err)) + tostring (properties[\"node.name\"]) .. \": \" .. tostring(err)) + parent:store_managed_pending(id, nil) else monitorNodeError (n) parent:store_managed_object(id, n) end end) Copy n:get_property(\u0026quot;node.name\u0026quot;) （nがNULLだと即クラッシュする）を tostring(properties[\u0026quot;node.name\u0026quot;]) に変えたのは正しい修正。だが、そのついでに追加された後片付け処理parent:store_managed_pending(id, nil)が、存在しないメソッド名になっている。本来は、同じファイルの他の場所（461行目、621行目、627行目）で実際に使われている store_managed_object(id, nil) を呼ぶべきところだったはずだ。C側の実装にも、そのものずばりのドキュメントコメントがある。\n/* * \\param self the spa device * \\param id the (device-internal) id of the object * \\param object (transfer full) (nullable): the object to store or NULL to remove * the managed object associated with \\a id */ void wp_spa_device_store_managed_object (WpSpaDevice * self, guint id, GObject * object) Copy objectにNULLを渡せば、そのidに紐づく管理対象オブジェクトを削除する——まさに今回のエラーハンドリングがやりたかったことと一致する。1文字も違わない机上の正しい関数が、すぐ近くに用意されていた。\nつまり今回のバグの正体は、「デバイスが活性化完了前に壊れる」という本物のバグを直そうとした2026-08-25のコミットが、後片付けコードで store_managed_object と書くべきところを store_managed_pending と書き間違えた、という話だった。Luaは動的型付けで、存在しないメソッドを呼んでもコンパイル時には何も言ってくれない。実際にエラー経路（USBデバイスのビジー状態）を通るまで、この1行は誰にも気づかれずに眠っていたことになる。\nもう直ってた ここまで調べたら、GitLabにissueを立てる準備をするところだった。念のため、WirePlumberの最新の履歴を見てから、と思って git log --all -S \u0026quot;store_managed_pending\u0026quot; をもう一度、タグ指定なしで実行した。\nf9891d25 alsa: Use store_managed_object() to remove pending Ids e923c93a alsa: Always activate all device and node features Copy ヒットが2件に増えている。f9891d25 のコミットメッセージ：\nalsa: Use store_managed_object() to remove pending Ids\nThis fixes a typo as store_managed_pending() does not exist.\nSee #999\n一言一句、こちらが独立に辿り着いた結論と同じことが書いてある。2026-09-01、バグを入れた本人(Julian Bouzas)が、自分で1週間後に直していた。 参照issueはバグ混入時の#996とは別の#999——誰か他のユーザーが同じ症状を踏んで報告したのだろう。差分はこちら。\nif err then log:warning (\"Failed to create ALSA node \" .. tostring (properties[\"node.name\"]) .. \": \" .. tostring(err)) - parent:store_managed_pending(id, nil) + parent:store_managed_object(id, nil) else Copy このコミットは 0.5.17 ・ 0.5.18 に含まれている。手元の環境は 0.5.16。つまりやるべきことは、GitLabにissueを立てることではなく、ただパッケージを更新することだった。\nここまで4段階潜って、ソースをcloneしてgit blameで犯人のコミットまで特定して、満を持してissue報告の下書きを始めようとした矢先に、「もう直ってるよ」というオチがついた。悪い話ではない。直ってることを確認せずにissueを立てていたら、それこそ格好悪かった。\nこのLuaエラーが起きるたびに、そのカード（今回はUSBマイクのカード）のPipeWire内部状態が中途半端に壊れたまま残る。pavucontrolが全カードの情報を列挙しようとしたとき、この壊れたカードの問い合わせで pa_context_get_card_info_by_index() が Invalid argument を返して落ちる、という流れだと考えられる。\nでも、なぜ「ビジー」になるのか ここまでで「WirePlumberのバグ」は特定できたが、それはあくまで結果だ。なぜそもそもALSAデバイスが繰り返しビジーになるのかが分かっていない。\nカーネルログ（journalctl -k）を見て、話が変わった。\nusb 3-1: new full-speed USB device number 23 using xhci_hcd usb 3-1: Device not responding to setup address. usb 3-1: Device not responding to setup address. usb 3-1: device not accepting address 23, error -71 usb 3-1: WARN: invalid context state for evaluate context command. usb 3-1: USB disconnect, device number 23 usb 3-1: new full-speed USB device number 24 using xhci_hcd usb 3-1: device descriptor read/64, error -71 ... Copy このサイクルが、USBマイクを挿しているポート（usb 3-1）で何度も繰り返されていた。error -71 はLinuxカーネルでは EPROTO（プロトコルエラー）。USBデバイスが列挙（enumeration）の途中で応答しなくなり、ホスト側がデバイス番号を振り直して再試行しては、また失敗する。\nつまり、「WirePlumberがALSAデバイスを掴もうとして失敗する」のは結果であって、その手前でUSBデバイス自体がカーネルレベルで不安定になっていた、というのが実態だった。\nハブでも電源管理でもなかった 最初に疑ったのは、今日たまたま別件（キーボードの話）で原因になっていたUSBハブだった。lsusb -t で確認したが、このマイクは外部ハブを経由せず、ホストコントローラーのルートポートに直結されていた。別系統の話だ。\n電源管理も見た。\n/sys/bus/usb/devices/3-1/power/control → on（autosuspend無効） /sys/bus/usb/devices/3-1/bMaxPower → 100mA Copy autosuspendは無効（常時on）、デバイス自体が申告している消費電力も100mAと低め。電力不足や省電力機能の暴走、という線は薄い。\nチップセットまで下りる $ lspci -k 09:00.3 USB controller: AMD Matisse USB 3.0 Host Controller Copy AMD Matisse（Ryzen 3000番台世代）のUSB 3.0ホストコントローラー、ASRock製マザーボード。\n同じ「device not accepting address, error -71」を検索すると、ASRock B550（同じくAMDチップセット）のマザーボードで、別のUSBデバイス（マウス）との組み合わせで報告されているフォーラムスレッドが見つかった。ただしそのスレッドでも決定的な原因・解決には至っておらず、最終的にはそのデバイスを返品していた。\nAMD系チップセットのxHCIコントローラーと、特定のUSB周辺機器の組み合わせで、たまに起きる原因不明の相性問題——というのが、現時点で言える一番正直なところだ。\nまとめ アプリ層の症状（pavucontrolが起動しない）から、WirePlumberのソースコード（存在しないLuaメソッド呼び出し）、カーネルのUSBログ（error -71、デバイスの列挙失敗）まで、4段階くらい潜った。 WirePlumberのバグは実在した。しかも原因はレースコンディションのような曖昧なものではなく、2026-08-25のコミット(e923c93a)で、store_managed_objectと書くべき箇所をstore_managed_pendingと書き間違えた、単純なタイポだった。Luaの動的型付けのせいで、エラー経路を実際に通るまで誰にも気づかれなかった。 このタイポは、2026-09-01のコミット(f9891d25)で、バグを入れた本人が自分で修正済み。 0.5.17・0.5.18に入っている。手元の0.5.16が、ちょうど直る1つ前のバージョンだった。 根本原因（なぜUSBが一時的に応答しなくなるのか）は、AMD MatisseのxHCIコントローラーとこのUSBマイクの相性問題の可能性が高いが、完全には特定できていない。ここはWirePlumberの更新では直らない。 今すぐの対処は2つ。WirePlumberを0.5.17以降に更新する（根本のLuaバグはこれで消える）。その上でUSBがまだ不安定なら systemctl --user restart wireplumber で都度しのぐ、USBマイクの抜き差し・別ポートへの差し替えも試す価値がある。 ソフトウェアのバグを追いかけていたら、最後はハードウェアの相性問題に行き着いた。よくある話だが、journalctlとソースコードとカーネルログを順番に読んでいくと、どこで何が起きているかは、ちゃんと言葉で説明できる形で残っている。\n","permalink":"https://america.github.io/post/2026-10-04-pavucontrol-wireplumber-usb-debugging/","summary":"\u003cp\u003e音量を調整しようとpavucontrolを開いたら、こう言われた。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003epa_context_get_card_info_by_index() 失敗: Invalid argument\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003eそれだけ。開かない。\u003c/p\u003e\n\u003cp\u003e環境はArch Linux、sway、PipeWire 1.6.8、WirePlumber 0.5.16。よくある「PulseAudio互換レイヤーが機嫌を損ねた」系の話に見えたが、実際に追ってみたら、思ったより下の層まで潜る羽目になった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まず-journalctl\"\u003eまず journalctl\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003esystemctl --user status pipewire pipewire-pulse wireplumber\u003c/code\u003e でログを見ると、pipewireとwireplumberが3〜5秒おきに同じエラーを吐き続けていた。しかも調査してる最中もリアルタイムで進行中。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-\"\u003epipewire: spa.alsa: 'front:0': capture open failed: デバイスもしくはリソースがビジー状態です\npipewire: pw.node: (alsa_input.usb-Kingston_HyperX_Quadcast_4110-00.analog-stereo-94) suspended -\u003e error (Start error: デバイスもしくはリソースがビジー状態です)\nwireplumber: s-monitors: Failed to create ALSA node alsa_input.usb-Kingston_HyperX_Quadcast_4110-00.analog-stereo: Object activation aborted: PipeWire proxy destroyed\nwireplumber: wplua: [string \"alsa.lua\"]:446: attempt to call a nil value (method 'store_managed_pending')\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e犯人らしきデバイス名が出ている。USBマイク（Kingston HyperX Quadcast）だ。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003efuser -v /dev/snd/*\u003c/code\u003e で確認したが、掴んでいるのはwireplumber/pipewire自身だけ。Discordや他のアプリがマイクを横取りしているわけではなかった。PipeWireの中だけで完結して壊れている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"エラーメッセージにluaと書いてある\"\u003eエラーメッセージに「Lua」と書いてある\u003c/h2\u003e\n\u003cp\u003eログをよく見ると \u003ccode\u003ewplua: [string \u0026quot;alsa.lua\u0026quot;]:446\u003c/code\u003e とある。C言語のデーモンのはずなのに、なぜLuaのエラーが出てくるのか。\u003c/p\u003e","title":"pavucontrolが起動しない。追ったら、WirePlumberのLuaバグの奥にUSBの通信エラーがあった"},{"content":"Xで、こんな趣旨の投稿を見かけた。\n「NVIDIAが、自社のAI半導体を担保に資金を調達する巨大な枠組みを打ち出した。だが同社の先端半導体やそれを取り巻くインフラに、それほどの価値があるとは思えない。ウォール街も懐疑的だ。AIは過大評価されたバブルで、いずれ冷める可能性が高い」——という内容だった。\nAIバブルについて気になっていたので、これが本当かどうか、自分で裏取りしてみることにした。\n1. NVIDIAのGPU担保融資、これは本当にあった まず、投稿の前半（NVIDIAの構想自体）は事実だった。\nNVIDIAは2026年8月、Apollo・BlackRock・Blackstone・Brookfield・Goldman Sachs・KKRという大手金融6社と組んで、AI向け計算資源（GPU）を担保に最大5000億ドルを長期的に調達する枠組みを発表している。\n仕組みはこうだ。NVIDIAのGPUを担保にした特別目的会社（SPV）が、銀行や機関投資家向けに社債を発行して資金を集める。集めた資金でデータセンターを建て、そこにGPUを並べて、NVIDIAの顧客にリースする。もしGPUの担保価値が想定より下がった場合、NVIDIA自身が最大25%、金額にして最大1250億ドルを補填する、という約束までついている。\n要するに、「自社が作っているGPUそのものを担保にして、他人の金を引っ張ってくる」スキームだ。\n2. ウォール街が懐疑的、というのも本当だった 投稿の後半、「ウォール街は冷ややかだ」という部分も、裏が取れた。\nこのNVIDIAの構想について、2026年10月1日（くしくも、件の投稿の前日）に、こういう見出しの記事が出ている。\nNvidia\u0026rsquo;s bet that its chips can finance the AI boom gets a Wall Street reality check\n中身を読むと、実名の金融関係者が具体的な懸念を語っている。\nImpax Asset ManagementのTony Trzcinka: 「Wall Street is much more conservative」。NVIDIAは「GPUは10年稼げる」と主張しているが、銀行は通常GPUを3〜4年で償却するのが実務だ、と指摘 S\u0026amp;P Global RatingsのAndrew Chang: GPUの価値については「conservative view（保守的な見方）」を取ると明言 TCWのBrian Gelfand: 「The creditor community does not subscribe to long average lives for these assets.」（債権者側は、この手の資産が長く価値を持つという見方を受け入れていない） 銀行側は、NVIDIA自身の保証（最大25%）だけでは足りず、投資適格の顧客からの収益で裏付けを取りたがっている、という話も出ていた。\nここまでは、投稿の内容はどちらも事実として確認できた。\n3. でも「AIはバブル」は、ここからの飛躍だった 問題はここからだ。投稿は最後に「AIは過大評価のバブル。やがて冷める確率は高い」と締めくくっている。これも本当なのか、確かめた。\nまず、「GPUを担保にした融資スキームの、担保価値の見積もりにウォール街が保守的だ」という話と、「AI全体がバブルで、いずれ崩壊する」という話は、別の主張だ。前者は、特定の金融商品の設計についての、実務家の技術的な懸念にすぎない。後者は、AI関連株の時価総額全体が実態とかけ離れている、という、もっと大きな話になる。\n投稿を書いた本人は、金融や半導体の専門家ではない。「AIはバブル」という結論は、投稿者個人の意見として読むべきもので、さっきの実名金融関係者の発言とは、重みがまったく違う。\nそれでも、「AIバブル」説自体に根拠がないわけではなかったので、別途それも調べてみた。\nバブルを支持する材料 S\u0026amp;P500のシラーCAPEレシオは、2026年9月時点で40.6倍。1929年の大恐慌前の水準(32.6倍)を上回り、ドットコムバブルの史上最高値(1999年11月、44.19倍)に接近している。40倍超が数ヶ月続くこと自体、過去はドットコムバブル期にしか無かった現象 ロックフェラー・インターナショナル会長のルチル・シャルマ氏(モルガン・スタンレー・インベストメント・マネジメントで新興国株運用部門責任者・チーフグローバルストラテジストを25年務めた人物)は、「過剰投資」「過大評価」「過剰所有(米国人の個人資産に占める株式比率が過去最高)」「過剰レバレッジ(メタ・アマゾン・マイクロソフトが軒並み『最大級の社債発行企業』になっている)」という自身の「4つのO」基準すべてにAIブームが当てはまると指摘。金利上昇が「たった一つの引き金」になり得ると警告している NVIDIA・Broadcomなど主要AI株の株価売上高倍率（PSR）が30倍を超えている。歴史的に、この水準は大きな調整の前に見られることが多い MITの調査によると、AIを導入した企業の95%が、目に見えるROI（投資対効果）を得られていない AI関連のインフラ投資が年4000億ドルを超える一方、企業側の収益化が追いついていない「期間のミスマッチ」が指摘されている 調査会社Capital Economicsは「バブルの特徴を多く備えている」と評価 CNBC（2026年9月10日付）によると、あるウォール街の企業は「AI相場のブームは終わりに近づいている」との見方を示している バブルを否定する材料 Yorkville Ivesのシニア・マネージング・ディレクター、ダン・アイブス氏は、今のAI相場を「2000年のバブルではなく1997年の段階」と表現。根拠として、4〜5兆ドル規模とされるAIインフラ投資はまだ15%しか進んでおらず長期サイクルの初期段階であること、AI大手は(1999年の無収益スタートアップと違い)実質的なキャッシュフローと高い営業利益率を既に持っていること、NVIDIAの株価収益率(約19倍)はドットコム期のシスコ(100倍超)よりずっと低いことを挙げている バンク・オブ・アメリカの米国株戦略責任者、サヴィタ・スブラマニアン氏は、全面的なバブル崩壊ではなく、データセンター向け負債の積み上がりによる一時的な「エアポケット」(踊り場的な調整)に備えるべきだという立場 2026年の企業業績成長率は12.9%、2027年は12.8%と予測されていて、業績自体は堅調 現在のAI大手企業は、ドットコム期の無収益スタートアップと違い、すでに確立された高収益事業を土台にしている Capital Economics自身も「2026年中に崩壊するとは予想していない」とした上での評価だった Goldman SachsやJ.P.Morganは、この成長は業績に裏付けられた正当なものだと主張している 両方の材料を並べてみると分かる通り、「バブルかどうか」は、今の時点で専門家の間でも決着がついていない。これを「確率は高い」と断定した投稿は、実際の議論の状態よりも強く言い切りすぎている。\nまとめ NVIDIAのGPU担保融資の構想：事実 それにウォール街が懐疑的：事実（実名の金融関係者の発言あり） AIは過大評価のバブルで、やがて冷める確率は高い：投稿者個人の意見。専門家の間でも割れている、未決着の論点 事実の部分と意見の部分が同じ投稿の中に混ざっていると、事実の信頼性がそのまま意見にも貸し出されたように見えてしまう。今回、裏取りして一番はっきりしたのはそこだった。\n出典 GPUを「投資可能なインフラ」に NVIDIAと金融大手6社、78兆円超の資金導入を始動 Nvidia\u0026rsquo;s bet that its chips can finance the AI boom gets a Wall Street reality check（BNN Bloomberg） AIバブル、2026年に「たった1つの引き金で一気に崩壊しかねない」と著名エコノミストが警鐘（Business Insider Japan） Shiller PE (CAPE) Ratio Today（thetrading.tools） Top Tech Analyst Says Today\u0026rsquo;s AI Trade Is \u0026ldquo;a 1997 Moment, Not a 2000 Bubble\u0026rdquo;（TIKR） Bank of America predicts an \u0026lsquo;air pocket,\u0026rsquo; not an AI bubble（Yahoo Finance） ","permalink":"https://america.github.io/post/2026-10-03-nvidia-gpu-collateral-ai-bubble/","summary":"\u003cp\u003eXで、こんな趣旨の投稿を見かけた。\u003c/p\u003e\n\u003cp\u003e「NVIDIAが、自社のAI半導体を担保に資金を調達する巨大な枠組みを打ち出した。だが同社の先端半導体やそれを取り巻くインフラに、それほどの価値があるとは思えない。ウォール街も懐疑的だ。AIは過大評価されたバブルで、いずれ冷める可能性が高い」——という内容だった。\u003c/p\u003e\n\u003cp\u003eAIバブルについて気になっていたので、これが本当かどうか、自分で裏取りしてみることにした。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-nvidiaのgpu担保融資これは本当にあった\"\u003e1. NVIDIAのGPU担保融資、これは本当にあった\u003c/h2\u003e\n\u003cp\u003eまず、投稿の前半（NVIDIAの構想自体）は事実だった。\u003c/p\u003e\n\u003cp\u003eNVIDIAは2026年8月、Apollo・BlackRock・Blackstone・Brookfield・Goldman Sachs・KKRという大手金融6社と組んで、AI向け計算資源（GPU）を担保に最大5000億ドルを長期的に調達する枠組みを発表している。\u003c/p\u003e\n\u003cp\u003e仕組みはこうだ。NVIDIAのGPUを担保にした特別目的会社（SPV）が、銀行や機関投資家向けに社債を発行して資金を集める。集めた資金でデータセンターを建て、そこにGPUを並べて、NVIDIAの顧客にリースする。もしGPUの担保価値が想定より下がった場合、NVIDIA自身が最大25%、金額にして最大1250億ドルを補填する、という約束までついている。\u003c/p\u003e\n\u003cp\u003e要するに、「自社が作っているGPUそのものを担保にして、他人の金を引っ張ってくる」スキームだ。\u003c/p\u003e\n\u003ch2 id=\"2-ウォール街が懐疑的というのも本当だった\"\u003e2. ウォール街が懐疑的、というのも本当だった\u003c/h2\u003e\n\u003cp\u003e投稿の後半、「ウォール街は冷ややかだ」という部分も、裏が取れた。\u003c/p\u003e\n\u003cp\u003eこのNVIDIAの構想について、2026年10月1日（くしくも、件の投稿の前日）に、こういう見出しの記事が出ている。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eNvidia\u0026rsquo;s bet that its chips can finance the AI boom gets a Wall Street reality check\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e中身を読むと、実名の金融関係者が具体的な懸念を語っている。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eImpax Asset ManagementのTony Trzcinka\u003c/strong\u003e: 「Wall Street is much more conservative」。NVIDIAは「GPUは10年稼げる」と主張しているが、銀行は通常GPUを3〜4年で償却するのが実務だ、と指摘\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eS\u0026amp;P Global RatingsのAndrew Chang\u003c/strong\u003e: GPUの価値については「conservative view（保守的な見方）」を取ると明言\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTCWのBrian Gelfand\u003c/strong\u003e: 「The creditor community does not subscribe to long average lives for these assets.」（債権者側は、この手の資産が長く価値を持つという見方を受け入れていない）\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e銀行側は、NVIDIA自身の保証（最大25%）だけでは足りず、投資適格の顧客からの収益で裏付けを取りたがっている、という話も出ていた。\u003c/p\u003e\n\u003cp\u003eここまでは、投稿の内容はどちらも事実として確認できた。\u003c/p\u003e\n\u003ch2 id=\"3-でもaiはバブルはここからの飛躍だった\"\u003e3. でも「AIはバブル」は、ここからの飛躍だった\u003c/h2\u003e\n\u003cp\u003e問題はここからだ。投稿は最後に「AIは過大評価のバブル。やがて冷める確率は高い」と締めくくっている。これも本当なのか、確かめた。\u003c/p\u003e\n\u003cp\u003eまず、「GPUを担保にした融資スキームの、担保価値の見積もりにウォール街が保守的だ」という話と、「AI全体がバブルで、いずれ崩壊する」という話は、\u003cstrong\u003e別の主張\u003c/strong\u003eだ。前者は、特定の金融商品の設計についての、実務家の技術的な懸念にすぎない。後者は、AI関連株の時価総額全体が実態とかけ離れている、という、もっと大きな話になる。\u003c/p\u003e\n\u003cp\u003e投稿を書いた本人は、金融や半導体の専門家ではない。「AIはバブル」という結論は、投稿者個人の意見として読むべきもので、さっきの実名金融関係者の発言とは、重みがまったく違う。\u003c/p\u003e\n\u003cp\u003eそれでも、「AIバブル」説自体に根拠がないわけではなかったので、別途それも調べてみた。\u003c/p\u003e","title":"NVIDIAのGPU担保融資にウォール街が懐疑的、という話を裏取りした"},{"content":"sudo systemctl restart bluetoothと打ったら、パスワードを聞かれずに通った。何かがおかしい。ここから、GTFOBinsの調査、SSH鍵の作り直し、rrsyncとの格闘、そしてOpenSSHのソースコードを読むところまで進んだ調査の記録。最後には、原因が分からないままPCが2回勝手に落ちるという、後味の悪いオチが付く。\nきっかけ: パスワードを聞かれない Bluetoothの調子が悪くてsudo systemctl restart bluetoothを打った。いつもならパスワードを聞かれるはずが、そのまま通った。直近でsudoを使った覚えもない。おかしいと思ってsudo -n -l(パスワード無しで、自分に許可されているsudoコマンドを一覧表示する)を叩いてみた。\nユーザー takashi は takashi-pc 上で コマンドを実行できます (ALL : ALL) ALL (root) NOPASSWD: /usr/bin/rsync, /usr/bin/systemctl, /usr/bin/poweroff Copy /etc/sudoers.d/配下に、rsync・systemctl・poweroffの3つが、パスワード無しで、引数を問わず実行できる設定が入っていた。\nGTFOBinsで確認した危険性 GTFOBinsは、Unix系のバイナリを悪用した権限昇格の手口をまとめたデータベースだ。systemctlとrsyncのページを見ると、この設定がどれだけまずいかがすぐ分かる。\nsystemctl: 自分でsystemdのサービスファイルを作り、systemctl link→systemctl enable --nowで登録・起動すれば、そのサービスはroot権限で動く。あるいはSYSTEMD_EDITOR環境変数に自分のスクリプトを指定した状態でsystemctl editを叩くと、そのスクリプトがrootで呼ばれる。\nrsync: --rsh(または-e)オプションで、任意のコマンドを「リモートシェル」として起動できる。sudo rsync -e /bin/sh ...のような形で、rootのシェルを直接取れる。\nつまりこの設定は、一般ユーザーのまま実質rootになれる、という状態だった。poweroffだけは被害が限定的(シャットダウンのみ)だが、残り2つは深刻。\n誰がこれを使っていたのか このPCで動いている自動化を一通り確認したが、systemd timerにもcronにも、この3つのNOPASSWDに依存しているものは見当たらなかった。\n答えは、別のマシン(自宅のミニPC、以下NAS)側にあった。backup-archという、このPCの/home /boot /etcを毎晩NASへrsyncでバックアップするスクリプトが、SSH経由でこのPCに対してsudo rsyncを実行していた。バックアップ完了後、sudo systemctl stop/startでコンテナを一時停止する処理と、sudo poweroffで自動シャットダウンする処理も持っていた。\nbackup-archの最初のコミットは2025年10月。当時はコーディングエージェントに書かせたもので、SSH経由のsudo実行を前提にした設計だった。systemctlを使っていた「バックアップ前後にコンテナを止める」処理は、後になって「そもそも止める対象がバックアップ範囲に含まれておらず、意味が無かった」という理由で既に削除されていたが、sudoers側の許可だけが広いまま残っていた。\n絞り込みの設計: rrsyncとSSH強制コマンド rsyncとsystemctlのNOPASSWDを外し、その代わりに、必要な操作だけをできる形に絞り込むことにした。\nrsyncにはrrsync(restricted rsync)という、rsync本体に同梱されている補助スクリプトがある。SSHのauthorized_keysで、特定の鍵に対してcommand=\u0026quot;rrsync -ro /path/to/dir\u0026quot;のように強制コマンドを指定すると、その鍵で接続してきたクライアントが何を要求しても無視され、指定した1つのディレクトリへの読み取り専用アクセスだけが許可される。\nただしrrsyncは、1回の起動につき1つのディレクトリしか制限できない。今回は/home /boot /etcの3か所が必要だったので、ディレクトリごとに専用の鍵を1本ずつ、計3本作った。加えて、シャットダウン専用の鍵をもう1本。合計4本の鍵、それぞれに対応する強制コマンドをauthorized_keysに設定した。\ncommand=\"sudo /usr/bin/rrsync -ro /home\",restrict ssh-ed25519 AAAA... nas-backup-home command=\"sudo /usr/bin/rrsync -ro /boot\",restrict ssh-ed25519 AAAA... nas-backup-boot command=\"sudo /usr/bin/rrsync -ro /etc\",restrict ssh-ed25519 AAAA... nas-backup-etc command=\"sudo /usr/bin/poweroff\",restrict ssh-ed25519 AAAA... nas-backup-poweroff Copy sudoers側も、引数まで完全一致させた形にする。\ntakashi ALL=(root) NOPASSWD: /usr/bin/rrsync -ro /home takashi ALL=(root) NOPASSWD: /usr/bin/rrsync -ro /boot takashi ALL=(root) NOPASSWD: /usr/bin/rrsync -ro /etc takashi ALL=(root) NOPASSWD: /usr/bin/poweroff Copy sudoersでコマンドに引数を明示すると、その引数と完全一致したときだけ許可される。ワイルドカードを使わなければ、rsync --rsh=/bin/sh ...のような任意引数での起動はできなくなる。\n罠: sudoが環境変数を消す 設定した直後、rrsyncが「Not invoked via sshd」というエラーで落ちた。原因はソースを読んですぐ分かった。\ncommand = os.environ.get('SSH_ORIGINAL_COMMAND', None) if command is None: die(\"Not invoked via sshd\") Copy rrsyncは、クライアントが本来要求してきたコマンド(SSH_ORIGINAL_COMMAND)を読んで、それが安全な範囲かを検証する。ところがsudoは、デフォルトでほとんどの環境変数を消してから子プロセスを起動する。command=\u0026quot;sudo rrsync ...\u0026quot;という形で強制コマンドを組んでいたので、rrsyncにたどり着く前に肝心の環境変数が消えていた。\nDefaults!/usr/bin/rrsync env_keep += \"SSH_ORIGINAL_COMMAND SSH_CONNECTION\" Copy sudoersに、rrsync実行時だけこの2つの環境変数を残す設定を1行追加して解決した。\n余談: rrsyncのTOCTOU対策が思ったより本格的だった rrsyncのソース(Pythonで書かれている、/usr/share/doc/rsync/support/rrsyncが原本で、Arch Linuxでは/usr/bin/rrsyncにインストールされる)を読んでいて、単なる「パスをディレクトリ配下に制限するだけのラッパー」だと思っていたら、思ったよりずっと本格的なTOCTOU(Time-of-check to time-of-use)対策が入っていて感心した。validated_arg()関数の一部を、コメントごとそのまま引用する。\n# Inode-pin the validated path so an attacker cannot flip a # path component AFTER realpath validates it but BEFORE the # exec'd rsync resolves it. # # CRITICAL: open with O_RDONLY (not O_PATH). An O_PATH fd # holds a path/dentry reference and /proc/self/fd/N for an # O_PATH fd re-resolves the path on open -- which means the # race window stays open across the exec. A regular # O_RDONLY fd holds an open file (inode-bound), and # /proc/self/fd/N for a regular fd references the inode # directly -- exactly the race-closing primitive we need. # # O_NOFOLLOW on this open means a symlink that raced into # place between realpath and this open is refused at the # leaf. A subsequent fstat() + readlink-of-fd verifies the # pinned inode is still within the restricted tree (a # parent-component race that landed on an in-tree symlink # but outside-tree target would surface here). try: if sender_leaf_unopened: raise InterruptedError() # jump to the sender-pin branch try: # O_NONBLOCK so a special file that raced in after the # lstat above still cannot block this open. fd = os.open(real_arg, os.O_RDONLY | os.O_NOFOLLOW | os.O_NONBLOCK) except IsADirectoryError: fd = os.open(real_arg, os.O_RDONLY | os.O_NOFOLLOW | os.O_DIRECTORY) except InterruptedError: fd = None except FileNotFoundError: if am_sender: die('post-realpath open failed (race detected):', orig_arg, 'No such file or directory') Copy os.path.realpath()でパスを検証した直後に、誰かがシンボリックリンクをすり替えて制限ディレクトリの外を指すようにする、という古典的なTOCTOU攻撃がある。これに対して、検証したパスをO_NOFOLLOW付きで開いてファイルディスクリプタとして握っておき(O_PATHではなく通常のO_RDONLYで開くのがポイントで、コメントにある通りO_PATHだと/proc/self/fd/Nが open 時にパスを再解決してしまいレース窓が閉じない)、以降のrsync本体の処理はそのfd経由(/proc/self/fd/N)でアクセスさせることで、検証後のすり替えを物理的に塞いでいる。**「実際に落ちた原因を追っている最中にたまたま読んだラッパースクリプトの中に、本格的なセキュリティエンジニアリングが埋まっていた」**という、今回の調査の中で一番愉快な副産物だった。\n1回目の事故 絞り込みの途中、4本の鍵が正しく強制コマンドを発動するか、順番に接続テストをした。home・boot・etcはsudoのパスワードを要求されて失敗し(まだ絞り込み前だったので)、poweroffも同じように失敗するだろうと考えて、同じ調子でテストした。\n実際には成功して、PCが本当にシャットダウンした。\n原因は単純だった。その時点でsudoersにはまだ、絞り込み前の広いNOPASSWD:/usr/bin/poweroff(引数を問わない形)が残っていた。poweroffは成功すれば必ず実際にシャットダウンする、という当たり前のことを、「一連の動作確認の一部」として無言で実行してしまった。\n引数を完全一致に絞った後、2回目の事故 sudoersを引数完全一致の形に直し、home・boot・etcの3本が正しく動くことを確認し、backup.py(NAS側のバックアップスクリプト)も新しい鍵構成に書き換えて、手動でフル実行させて成功を確認した。ここまでは順調だった。\nその後、しばらく経ってから、また突然PCが落ちた。\n原因を追う まず、確実な事実から押さえた。\n$ journalctl -b -1 -u sshd --since \"23:00\" 9月 29 23:06:31 takashi-pc sshd-session[24158]: Accepted publickey for takashi from 192.168.3.20 port 39462 ssh2: ED25519 SHA256:bAFktN8... Copy 指紋を照合すると、nas-backup-poweroff(シャットダウン専用の鍵)と完全に一致した。NAS(192.168.3.20)から、この鍵で正規に接続があり、強制コマンドが正しく発動した、という事実は動かない。\n問題は、何がこの接続を起こしたのか、だった。\nプロセス一覧: NAS上にrsync/ssh/poweroff絡みの幽霊プロセスは残っていない SSH多重化ソケット: 残っていない cron: 全行コメントアウト済みで、何も動いていない systemd timer: backup-arch.timerは前日03:21に実行済み、次回は翌日03:16。この時間帯には動いていない ssh-agent: NASにはそもそもエージェント自体が起動していない シェルのchpwd/precmd/終了フック: .zshrc等に該当する仕掛けは無い 一つ、検討する価値のある仮説が残った。もしssh-agentに4本の鍵が読み込まれていたら、ssh archのような、この鍵を指定していない普通の接続でも、エージェントが持っている鍵を順に試し、たまたまpoweroff用の鍵が先に認証を通ってしまう可能性がある。そうなれば、クライアントが何を要求したかに関係なく、サーバー側の強制コマンドが動く。\nこの仮説は、ssh-agentが動いていないことで直接否定できた。それでも念のため、OpenSSHのソース(このマシンと同じOpenSSH_10.5p1をgit clone --depth 1 https://github.com/openssh/openssh-portable.gitでそのままクローン)を読んで、readconf.cの該当箇所を確認した。fill_default_options()という、設定ファイルを読み終えた後に空欄を既定値で埋める関数の中に、この判定がある。\nif (options-\u003eadd_keys_to_agent == -1) { options-\u003eadd_keys_to_agent = 0; options-\u003eadd_keys_to_agent_lifespan = 0; } if (options-\u003enum_identity_files == 0) { add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_RSA, 0); add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_ECDSA, 0); add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_ECDSA_SK, 0); add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_ED25519, 0); add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_ED25519_SK, 0); add_identity_file(options, \"~/\", _PATH_SSH_CLIENT_ID_MLDSA44_ED25519, 0); } if (options-\u003eescape_char == -1) options-\u003eescape_char = '~'; Copy add_identity_file()が呼ばれる箇所はif (options-\u0026gt;num_identity_files == 0)のガード1本だけで、他のどこにも既定鍵を足す経路は無い。num_identity_filesはreadconf.cのprocess_config_line()内、oIdentityFile(IdentityFileディレクティブのパース)がヒットするたびにadd_identity_file()経由でインクリメントされる値そのものだ。つまり「IdentityFileを1回でも書いた瞬間、この関数のガードはfalseになり、二度と既定鍵は足されない」という単純な話で、複数のIdentityFileを書いても、ssh-agentを使っても関係ない。\n接続に使っていた~/.ssh/configのHost archブロックは、明示的にIdentityfile ~/.ssh/arch_keyを書いていたので、num_identity_filesは最低でも1になり、このガードには入らない。エージェントも動いていない。つまり、OpenSSHの仕組み上、「別の目的で普通に接続したら、たまたま違う鍵が選ばれた」ということはソースレベルで起こり得ない、と確認できた。\njournalctlとカーネルログもb-1(前回起動)分を遡って確認したが、シャットダウン処理そのものの記録以外に手がかりは無かった。ログイン用のセッション情報は残っていても、ターミナルに何を打ち込んだかという内容そのものは、そもそもどんなログにも記録されない。技術的に、これ以上は追えなかった。\n原因不明のまま、被害は減らす 何が接続を起こしたのか、最終的に特定できなかった。それでも、「鍵さえあれば無条件でシャットダウンできる」状態を放置するのは違う。原因が分からないなら、結果の被害を小さくする方向で対策した。\nガードスクリプトを1本追加した。poweroff用の鍵で接続があっても、直前10分以内にhome・boot・etcの3本全部のrrsyncが実際に成功した記録(このPC自身のjournalctlのsudoログ)が無ければ、シャットダウンを拒否する。\n#!/bin/bash set -euo pipefail WINDOW=\"-10 min\" for dir in home boot etc; do if ! journalctl -t sudo --since \"$WINDOW\" 2\u003e/dev/null \\ | grep -q \"COMMAND=/usr/bin/rrsync -ro /$dir\"; then echo \"backup-arch guard: recent rrsync for /$dir not confirmed, refusing shutdown\" \u003e\u00262 exit 1 fi done exec /usr/bin/shutdown -h +1 \"backup-arch: verified shutdown after backup\" Copy このスクリプトはroot所有・書き込み不可にした上で、authorized_keysの強制コマンドとsudoersの両方を、生のpoweroffではなくこのスクリプト経由に変更した。承認条件が揃わなければ拒否され、揃っていても即座に落ちるのではなくshutdown -h +1(1分後、全端末に警告表示、sudo shutdown -cでキャンセル可)にした。\n拒否側の動作は、実際に接続して確認済み。承認側(本物のバックアップ後に本当にシャットダウンする流れ)は、この記事を書いている時点では、その夜のbackup-arch.timerの本番実行を待っている。\n教訓 NOPASSWDに引数を付けないと、実質的に無制限の権限を渡していることになる。 GTFOBinsは、この種の「便利だから広く許可した」設定がどれだけ危ういかを機械的に教えてくれる。 rrsyncのような制限付きラッパーは、1つの目的にしか使えないよう最初から設計されている。 それに合わせて、鍵1本に1つの役割、という単位で分割する方が、結局は管理しやすい。 sudoは環境変数を消す。 強制コマンドの後ろに別のツールを挟むときは、そのツールが何を前提にしているか(環境変数、標準入出力、カレントディレクトリ)を疑ってかかる必要がある。 原因が特定できないことは、対策を諦める理由にならない。 「なぜ起きたか」が分からなくても、「起きたときにどこまで被害が広がるか」は設計で縮められる。 原因不明のまま終わった調査というのは、正直、気持ちのいいものではない。それでも、調べられる場所は全部調べた上で「分からない」と言うのと、調べずに「分からない」と言うのとでは、次に同じことが起きたときの備え方が違う。\n","permalink":"https://america.github.io/post/2026-09-30-sudoers-nopasswd-ssh-forced-command-mystery/","summary":"\u003cp\u003e\u003ccode\u003esudo systemctl restart bluetooth\u003c/code\u003eと打ったら、パスワードを聞かれずに通った。何かがおかしい。ここから、GTFOBinsの調査、SSH鍵の作り直し、rrsyncとの格闘、そしてOpenSSHのソースコードを読むところまで進んだ調査の記録。最後には、原因が分からないままPCが2回勝手に落ちるという、後味の悪いオチが付く。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"きっかけ-パスワードを聞かれない\"\u003eきっかけ: パスワードを聞かれない\u003c/h2\u003e\n\u003cp\u003eBluetoothの調子が悪くて\u003ccode\u003esudo systemctl restart bluetooth\u003c/code\u003eを打った。いつもならパスワードを聞かれるはずが、そのまま通った。直近でsudoを使った覚えもない。おかしいと思って\u003ccode\u003esudo -n -l\u003c/code\u003e(パスワード無しで、自分に許可されているsudoコマンドを一覧表示する)を叩いてみた。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-text\"\u003eユーザー takashi は takashi-pc 上で コマンドを実行できます\n    (ALL : ALL) ALL\n    (root) NOPASSWD: /usr/bin/rsync, /usr/bin/systemctl, /usr/bin/poweroff\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/etc/sudoers.d/\u003c/code\u003e配下に、\u003ccode\u003ersync\u003c/code\u003e・\u003ccode\u003esystemctl\u003c/code\u003e・\u003ccode\u003epoweroff\u003c/code\u003eの3つが、\u003cstrong\u003eパスワード無しで、引数を問わず\u003c/strong\u003e実行できる設定が入っていた。\u003c/p\u003e\n\u003ch2 id=\"gtfobinsで確認した危険性\"\u003eGTFOBinsで確認した危険性\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://gtfobins.org/\"\u003eGTFOBins\u003c/a\u003eは、Unix系のバイナリを悪用した権限昇格の手口をまとめたデータベースだ。\u003ccode\u003esystemctl\u003c/code\u003eと\u003ccode\u003ersync\u003c/code\u003eのページを見ると、この設定がどれだけまずいかがすぐ分かる。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003esystemctl\u003c/strong\u003e: 自分でsystemdのサービスファイルを作り、\u003ccode\u003esystemctl link\u003c/code\u003e→\u003ccode\u003esystemctl enable --now\u003c/code\u003eで登録・起動すれば、そのサービスはroot権限で動く。あるいは\u003ccode\u003eSYSTEMD_EDITOR\u003c/code\u003e環境変数に自分のスクリプトを指定した状態で\u003ccode\u003esystemctl edit\u003c/code\u003eを叩くと、そのスクリプトがrootで呼ばれる。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ersync\u003c/strong\u003e: \u003ccode\u003e--rsh\u003c/code\u003e(または\u003ccode\u003e-e\u003c/code\u003e)オプションで、任意のコマンドを「リモートシェル」として起動できる。\u003ccode\u003esudo rsync -e /bin/sh ...\u003c/code\u003eのような形で、rootのシェルを直接取れる。\u003c/p\u003e\n\u003cp\u003eつまりこの設定は、\u003cstrong\u003e一般ユーザーのまま実質rootになれる\u003c/strong\u003e、という状態だった。\u003ccode\u003epoweroff\u003c/code\u003eだけは被害が限定的(シャットダウンのみ)だが、残り2つは深刻。\u003c/p\u003e\n\u003ch2 id=\"誰がこれを使っていたのか\"\u003e誰がこれを使っていたのか\u003c/h2\u003e\n\u003cp\u003eこのPCで動いている自動化を一通り確認したが、\u003ccode\u003esystemd\u003c/code\u003e timerにもcronにも、この3つのNOPASSWDに依存しているものは見当たらなかった。\u003c/p\u003e\n\u003cp\u003e答えは、別のマシン(自宅のミニPC、以下NAS)側にあった。\u003ccode\u003ebackup-arch\u003c/code\u003eという、このPCの\u003ccode\u003e/home\u003c/code\u003e \u003ccode\u003e/boot\u003c/code\u003e \u003ccode\u003e/etc\u003c/code\u003eを毎晩NASへrsyncでバックアップするスクリプトが、SSH経由でこのPCに対して\u003ccode\u003esudo rsync\u003c/code\u003eを実行していた。バックアップ完了後、\u003ccode\u003esudo systemctl stop/start\u003c/code\u003eでコンテナを一時停止する処理と、\u003ccode\u003esudo poweroff\u003c/code\u003eで自動シャットダウンする処理も持っていた。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ebackup-arch\u003c/code\u003eの最初のコミットは2025年10月。当時はコーディングエージェントに書かせたもので、SSH経由の\u003ccode\u003esudo\u003c/code\u003e実行を前提にした設計だった。\u003ccode\u003esystemctl\u003c/code\u003eを使っていた「バックアップ前後にコンテナを止める」処理は、後になって「そもそも止める対象がバックアップ範囲に含まれておらず、意味が無かった」という理由で既に削除されていたが、sudoers側の許可だけが広いまま残っていた。\u003c/p\u003e\n\u003ch2 id=\"絞り込みの設計-rrsyncとssh強制コマンド\"\u003e絞り込みの設計: rrsyncとSSH強制コマンド\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003ersync\u003c/code\u003eと\u003ccode\u003esystemctl\u003c/code\u003eのNOPASSWDを外し、その代わりに、必要な操作だけをできる形に絞り込むことにした。\u003c/p\u003e\n\u003cp\u003ersyncには\u003ccode\u003errsync\u003c/code\u003e(restricted rsync)という、rsync本体に同梱されている補助スクリプトがある。SSHの\u003ccode\u003eauthorized_keys\u003c/code\u003eで、特定の鍵に対して\u003ccode\u003ecommand=\u0026quot;rrsync -ro /path/to/dir\u0026quot;\u003c/code\u003eのように強制コマンドを指定すると、その鍵で接続してきたクライアントが何を要求しても無視され、指定した1つのディレクトリへの読み取り専用アクセスだけが許可される。\u003c/p\u003e\n\u003cp\u003eただし\u003ccode\u003errsync\u003c/code\u003eは、\u003cstrong\u003e1回の起動につき1つのディレクトリしか制限できない\u003c/strong\u003e。今回は\u003ccode\u003e/home\u003c/code\u003e \u003ccode\u003e/boot\u003c/code\u003e \u003ccode\u003e/etc\u003c/code\u003eの3か所が必要だったので、ディレクトリごとに専用の鍵を1本ずつ、計3本作った。加えて、シャットダウン専用の鍵をもう1本。合計4本の鍵、それぞれに対応する強制コマンドを\u003ccode\u003eauthorized_keys\u003c/code\u003eに設定した。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-text\"\u003ecommand=\"sudo /usr/bin/rrsync -ro /home\",restrict ssh-ed25519 AAAA... nas-backup-home\ncommand=\"sudo /usr/bin/rrsync -ro /boot\",restrict ssh-ed25519 AAAA... nas-backup-boot\ncommand=\"sudo /usr/bin/rrsync -ro /etc\",restrict ssh-ed25519 AAAA... nas-backup-etc\ncommand=\"sudo /usr/bin/poweroff\",restrict ssh-ed25519 AAAA... nas-backup-poweroff\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003esudoers\u003c/code\u003e側も、引数まで完全一致させた形にする。\u003c/p\u003e","title":"sudoersのNOPASSWDを絞り込んだら、PCが2回勝手に落ちた話"},{"content":"自作デスクトップ機(母艦 takashi-pc)の本体パーツ構成と費用を、購入時のレシート・注文記録 ベースで洗い出した。キーボード・マウスなどの周辺機器は除いて、CPU・GPU・マザーボード・ メモリ・ストレージ・ケース・電源だけの本体パーツに絞ってある。CPU/GPUは実機をlscpu/ lspciで確認し、購入レシートの型番と一致することも確認済み。\nパーツ一覧 パーツ 型番 購入先 購入日 支払額 備考 CPU AMD Ryzen 7 5700X BOX(AM4 / 8コア16スレッド / L3 32MB / TDP 65W) じゃんぱら(東池袋1丁目店) 2025-02-23 ¥25,450 本体¥24,980-¥300+送料¥770、保証1ヶ月(会員保証)。通販クレカ払い GPU SAPPHIRE PULSE Radeon RX 6600 XT GAMING OC 8G GDDR6 じゃんぱら(秋葉原2号店) 2024-02-11 ¥28,450 本体¥27,980-¥300+送料¥770、保証1ヶ月(会員保証)。あと払い(Paidy) メモリ CFD Standard DDR4-3200 16GB×2 288pin DIMM Amazon 2023-12-23 ¥8,883 マザーと同一注文 マザーボード ASRock A520M Pro4(AMD A520 / Socket AM4 / Micro ATX、国内正規代理店品) Amazon 2023-12-23 ¥8,845 メモリと同一注文 SSD①(Windows起動ドライブ) CFD販売 256GB 2.5\u0026quot; SATA(東芝製) Amazon 2015-07-06 ¥13,979 初めて買ったSSD、現在のWindows 11起動ドライブ。前PCから流用 SSD② Crucial P2 500GB M.2 NVMe(正規代理店保証品・5年保証) Amazon 2022-01-04 ¥5,515 表示価格¥5,555、Amazonポイント-¥40 SSD③(増設) Crucial BX500 1TB 2.5\u0026quot; SATA(3年保証・並行輸入品) Amazon 2025-08-05 ¥9,500 あと払い(Paidy) SSD④(Windows用、使用中) Crucial MX500 500GB 2.5\u0026quot; SATA Amazon 2018-04-01 不明 当初のパーツ一覧に丸ごと抜けていたが、実機のlsblkで存在が判明。手動マウントして中身を確認したところ、実際に使われているWindows用のデータドライブだった。金額はAmazonの購入履歴に記載がなく不明 PCケース DEEPCOOL CC560 V2(ATX / ガラスパネル / ブラック、ドスパラ限定モデル) ドスパラ 2024-07-07 ¥8,027 安心ワイド保証プラス3年 CPUクーラー DEEPCOOL AK400(120mmファン / LGA1851-1150・AM4対応) ビックカメラ.com 2025-02-23 ¥3,270 クレカ一括 電源 玄人志向 KRPW-PT700W/92+ REV2.0(700W / 80PLUS PLATINUM) 不明(たぶんヤフオク、記録なし) 不明 推定¥12,000〜15,000 前のPCから流用。型番は電源本体の銘板で確認。購入記録が残っておらず、金額は新品当時の相場からの推定であって確定額ではない 合計 区分 金額 電源以外のパーツ実支払額の合計(確定) ¥111,919 ＋電源(推定、確定額ではない) ＋¥12,000〜15,000 本体小計(電源を推定で足した場合) およそ¥12.4万〜12.7万 内訳(実支払・確定分): CPU 25,450 + GPU 28,450 + メモリ+マザー 17,728 + SSD① 13,979 + SSD② 5,515 + SSD③ 9,500 + ケース 8,027 + CPUクーラー 3,270 = ¥111,919\n参考: 今回のA520構成のために新しく買った分だけ(2015年の256GB SSDと前PC流用の電源を除く) だと、¥97,940(CPU 25,450 + GPU 28,450 + メモリ+マザー 17,728 + SSD② 5,515 + SSD③ 9,500 + ケース 8,027 + CPUクーラー 3,270)。\n電源だけ記録が無かった話 パーツの中で電源だけ、購入記録が一切残っていなかった。型番(玄人志向 KRPW-PT700W/92+ REV2.0)は電源本体の銘板を実際に確認して特定できたが、いつ・どこで買ったかの記録がなく、 本人の記憶でも「たぶんヤフオク」止まり。前のPCから流用した部品なので購入時期自体が古く、 金額は新品当時の実売相場からの推定にとどめてある。他のパーツが注文履歴やレシートで 金額まで確定できているのと対照的に、ここだけ確度が違う。\n追記(2026-09-22): 抜けてたSSDと、起動ドライブの誤解 公開後、実機をlsblkで確認したところ、パーツ一覧に丸ごと抜けていたSSD(上表のSSD④、 Crucial MX500 500GB)が見つかった。2018年にAmazonで購入した記録はあるが、金額の記載はない。\nまた、「SSD①が起動ドライブ」という表記について、「今のLinux(GRUB)はNVMeの方から起動して いるはずでは」という指摘を受けた。実機でefibootmgrとパーティションのGUIDを突き合わせた ところ、SSD①(256GB SATA)は確かにWindows 11の起動ドライブで合っていた。現在稼働中の Linux/GRUBはSSD②(NVMe)から起動しており、これはデュアルブート構成で両方が同時に正しい、 矛盾のない話だった。\nついでにlsblk -fで4台全部のファイルシステムを確認して、OSの割り当てを一覧にした:\nドライブ 用途 SSD①(256GB SATA) Windowsの起動ドライブ(NTFS) SSD②(500GB NVMe) Arch Linux(現在稼働中のメインOS、/と/boot) SSD③(1TB SATA) 約500GBがWindows領域(NTFS)、残り約500GBがGentoo Linux(btrfs、ラベルgentoo) SSD④(500GB SATA) Windows領域(NTFS、実際に使用中。手動マウントしてゲームライブラリなどの実データを確認) 1台のマシンにWindows・Arch Linux・Gentoo Linuxの3つのOSが同居してた。\n","permalink":"https://america.github.io/post/2026-09-21-diy-pc-build-cost/","summary":"\u003cp\u003e自作デスクトップ機(母艦 takashi-pc)の本体パーツ構成と費用を、購入時のレシート・注文記録\nベースで洗い出した。キーボード・マウスなどの周辺機器は除いて、CPU・GPU・マザーボード・\nメモリ・ストレージ・ケース・電源だけの本体パーツに絞ってある。CPU/GPUは実機を\u003ccode\u003elscpu\u003c/code\u003e/\n\u003ccode\u003elspci\u003c/code\u003eで確認し、購入レシートの型番と一致することも確認済み。\u003c/p\u003e\n\u003ch2 id=\"パーツ一覧\"\u003eパーツ一覧\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eパーツ\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e型番\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e購入先\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e購入日\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e支払額\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e備考\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCPU\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAMD Ryzen 7 5700X BOX(AM4 / 8コア16スレッド / L3 32MB / TDP 65W)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eじゃんぱら(東池袋1丁目店)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-02-23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥25,450\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e本体¥24,980-¥300+送料¥770、保証1ヶ月(会員保証)。通販クレカ払い\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGPU\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSAPPHIRE PULSE Radeon RX 6600 XT GAMING OC 8G GDDR6\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eじゃんぱら(秋葉原2号店)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2024-02-11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥28,450\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e本体¥27,980-¥300+送料¥770、保証1ヶ月(会員保証)。あと払い(Paidy)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eメモリ\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCFD Standard DDR4-3200 16GB×2 288pin DIMM\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-12-23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥8,883\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eマザーと同一注文\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eマザーボード\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eASRock A520M Pro4(AMD A520 / Socket AM4 / Micro ATX、国内正規代理店品)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2023-12-23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥8,845\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eメモリと同一注文\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSSD①(Windows起動ドライブ)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCFD販売 256GB 2.5\u0026quot; SATA(東芝製)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2015-07-06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥13,979\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e初めて買ったSSD、現在のWindows 11起動ドライブ。前PCから流用\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSSD②\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCrucial P2 500GB M.2 NVMe(正規代理店保証品・5年保証)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2022-01-04\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥5,515\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e表示価格¥5,555、Amazonポイント-¥40\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSSD③(増設)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCrucial BX500 1TB 2.5\u0026quot; SATA(3年保証・並行輸入品)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-08-05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥9,500\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eあと払い(Paidy)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eSSD④(Windows用、使用中)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCrucial MX500 500GB 2.5\u0026quot; SATA\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAmazon\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2018-04-01\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e当初のパーツ一覧に丸ごと抜けていたが、実機の\u003ccode\u003elsblk\u003c/code\u003eで存在が判明。手動マウントして中身を確認したところ、実際に使われているWindows用のデータドライブだった。金額はAmazonの購入履歴に記載がなく不明\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ePCケース\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDEEPCOOL CC560 V2(ATX / ガラスパネル / ブラック、ドスパラ限定モデル)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eドスパラ\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2024-07-07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥8,027\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e安心ワイド保証プラス3年\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eCPUクーラー\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDEEPCOOL AK400(120mmファン / LGA1851-1150・AM4対応)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eビックカメラ.com\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-02-23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥3,270\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eクレカ一括\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e電源\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e玄人志向 KRPW-PT700W/92+ REV2.0(700W / 80PLUS PLATINUM)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明(たぶんヤフオク、記録なし)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e推定¥12,000〜15,000\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e前のPCから流用。型番は電源本体の銘板で確認。購入記録が残っておらず、金額は新品当時の相場からの推定であって確定額ではない\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"合計\"\u003e合計\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e区分\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e金額\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e電源以外のパーツ実支払額の合計(確定)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥111,919\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e＋電源(推定、確定額ではない)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e＋¥12,000〜15,000\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e本体小計(電源を推定で足した場合)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eおよそ¥12.4万〜12.7万\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e内訳(実支払・確定分): CPU 25,450 + GPU 28,450 + メモリ+マザー 17,728 + SSD① 13,979 +\nSSD② 5,515 + SSD③ 9,500 + ケース 8,027 + CPUクーラー 3,270 = ¥111,919\u003c/p\u003e","title":"自作デスクトップPC、本体パーツだけで実際いくらかかったのか"},{"content":"\n使ってるアケコンは、HORI ファイティングスティックαがベースで、中身はほぼ総取っ替えしてある。 ボタンは全部GamerFingerに換装、レバーは静音版に赤バネと八角ガイドで固め、弱Kの下には 20mmの穴まで追加で開けた。作ったのは2025年10月頃。\nいくらかかったのか、正直「そんなに大した額じゃない」くらいの感覚でいた。今回、 Amazon・PayPay銀行の注文履歴を掘り起こして、実際の領収書ベースで集計し直したら、 思ってたより高かった。\nベース機と部品 項目 金額 購入時期 ベース機(メルカリ中古) ¥13,000 2025-10 GamerFinger 30mm ×6 ¥5,040 2021-09 GamerFinger 30mm ×2(追加分) ¥1,460 不明(2021単価で概算) GamerFinger 24mm ×2(黒、アート入り) ¥2,245 不明 静音レバー(JLF-TP-8YT-SK-AG) ¥3,191 2018-10 赤バネ(JLF-SP 2-2) ¥968 2025-01 八角ガイド(GTX-) ¥1,199 2025-09 ステップドリル ¥849 2025-10 ドリルレンタル(島忠、3日) 約¥1,000 不明 合計 ¥28,952 ベース機の中古¥13,000と、地味に積み重なったボタン代(合計¥8,745)が、想定より効いていた。 レバー本体は2018年に先行して買っておいたものを、後から改造に流用した形になる。\n領収書探しで一番びっくりした話 レバーの¥3,191という数字、最初は自分でも「本当にこの値段だったか?」と半信半疑だった。 Amazonの注文履歴を掘り返してようやく2018年10月の実際の注文が見つかって、金額もぴったり 一致した。ついでに、この型番(JLF-TP-8YT-SK)の「SK」が三和電子の静音版を示す公式の 型番だということも、商品タイトルには「静音」と書かれていなかったので今回初めて裏を取った。\n今の配線の工夫 はんだ付けは苦手なので、追加した20mmボタンを含めて全部のボタンを同時に有効化できてはいない。 一番外側の2箇所に来ていたハーネスケーブルを、実際に使いたい場所(外側24mmのパリィボタンと L1のインパクト)へ挿し替えて運用している。内側に増設したもう1個のボタンは、位置的に 指が届きにくく、結局配線を刺していない。\n","permalink":"https://america.github.io/post/2026-09-21-arcade-stick-mod-cost/","summary":"\u003cp\u003e\u003cimg alt=\"改造したファイティングスティックαのボタン配置\" loading=\"lazy\" src=\"/post/2026-09-21-arcade-stick-mod-cost/akecon.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003e使ってるアケコンは、HORI ファイティングスティックαがベースで、中身はほぼ総取っ替えしてある。\nボタンは全部GamerFingerに換装、レバーは静音版に赤バネと八角ガイドで固め、弱Kの下には\n20mmの穴まで追加で開けた。作ったのは2025年10月頃。\u003c/p\u003e\n\u003cp\u003eいくらかかったのか、正直「そんなに大した額じゃない」くらいの感覚でいた。今回、\nAmazon・PayPay銀行の注文履歴を掘り起こして、実際の領収書ベースで集計し直したら、\n思ってたより高かった。\u003c/p\u003e\n\u003ch2 id=\"ベース機と部品\"\u003eベース機と部品\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e項目\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e金額\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e購入時期\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eベース機(メルカリ中古)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥13,000\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-10\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGamerFinger 30mm ×6\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥5,040\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2021-09\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGamerFinger 30mm ×2(追加分)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥1,460\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明(2021単価で概算)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGamerFinger 24mm ×2(黒、アート入り)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥2,245\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e静音レバー(JLF-TP-8YT-SK-AG)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥3,191\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2018-10\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e赤バネ(JLF-SP 2-2)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥968\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-01\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e八角ガイド(GTX-)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥1,199\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-09\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eステップドリル\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e¥849\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e2025-10\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eドリルレンタル(島忠、3日)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e約¥1,000\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e不明\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003e合計\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003e¥28,952\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eベース機の中古¥13,000と、地味に積み重なったボタン代(合計¥8,745)が、想定より効いていた。\nレバー本体は2018年に先行して買っておいたものを、後から改造に流用した形になる。\u003c/p\u003e\n\u003ch2 id=\"領収書探しで一番びっくりした話\"\u003e領収書探しで一番びっくりした話\u003c/h2\u003e\n\u003cp\u003eレバーの¥3,191という数字、最初は自分でも「本当にこの値段だったか?」と半信半疑だった。\nAmazonの注文履歴を掘り返してようやく2018年10月の実際の注文が見つかって、金額もぴったり\n一致した。ついでに、この型番(\u003ccode\u003eJLF-TP-8YT-SK\u003c/code\u003e)の「SK」が三和電子の静音版を示す公式の\n型番だということも、商品タイトルには「静音」と書かれていなかったので今回初めて裏を取った。\u003c/p\u003e\n\u003ch2 id=\"今の配線の工夫\"\u003e今の配線の工夫\u003c/h2\u003e\n\u003cp\u003eはんだ付けは苦手なので、追加した20mmボタンを含めて全部のボタンを同時に有効化できてはいない。\n一番外側の2箇所に来ていたハーネスケーブルを、実際に使いたい場所(外側24mmのパリィボタンと\nL1のインパクト)へ挿し替えて運用している。内側に増設したもう1個のボタンは、位置的に\n指が届きにくく、結局配線を刺していない。\u003c/p\u003e","title":"改造アケコン、実際いくらかかったのか領収書を掘り起こしてみた"},{"content":" 要約元\n投稿：YouTube(ジャーナリスト・烏賀陽弘道氏によるライブ配信「ウガ金」、2026年9月18日、約2時間47分) 内容：AI開発企業のトップ自身が「このままではAIが人類滅亡のリスクになる」と警告し始めている状況について、コロンビア大学院で核戦略・安全保障論を専攻した烏賀陽氏が、核兵器開発との類似点・相違点を軸に分析したライブ配信 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。フィラーや言い直しを大量に含む口語そのままの自動音声認識のため誤字・誤認識が多く残っている可能性が高い。以下は要点を再構成したもので、逐語訳ではない。人名の一部(生物学からAI研究に転じた研究者)は音声上「高橋幸一」と聞こえるが、経歴から理研の高橋恒一氏を指すとみられるため以下ではそのように表記した なお、この配信は専門の学術論文や公式報告書ではなく、烏賀陽氏個人の見解と、Google Geminiに生成させたシナリオを紹介するライブトーク番組である。示されている未来予測の多くは確定した事実ではなく、烏賀陽氏自身の推論や、AI自身に予測させた仮説である点に留意されたい。\n烏賀陽弘道氏は、朝日新聞・AERA記者を17年、フリーランス記者として23年のキャリアを持つジャーナリストで、1994年にコロンビア大学大学院で国際安全保障論(核戦略)を専攻し修士号を取得している。この配信は、その専門性を軸に「AIは現代の核兵器である」という視点からAIの危険性を論じる内容になっている。\nなぜ「核兵器」になぞらえるのか 烏賀陽氏はまず、Anthropic社のCEOがテレビ番組で「このままAI開発を続ければ人類滅亡の危機になりうる」と発言したことを引き合いに出す。AIを実際に開発している最先端の当事者自身が「制御不能になりかけている」と認めている状況を、烏賀陽氏は冷戦期の核エスカレーション(米ソが互いに核武装し疑心暗鬼から先制攻撃の誘惑にかられ、キューバ危機で核戦争の一歩手前まで行った現象)になぞらえる。長年核戦略を研究してきた自分の目には、AIの発達スピードが指数関数的に上がっている今の状況が、核分裂の「臨界」に近づいていくプロセスと重なって見える、というのが出発点になっている。\n核兵器と決定的に違う点 — 開発しているのが「企業」であること 核兵器は各国政府が管理し、営利を追求せずに開発されてきた。ところがAIは、Anthropic、OpenAI、Google、Microsoft、Amazon、そしてイーロン・マスクのxAIなど、主に営利企業が開発を主導している。ここに核兵器開発にはなかった構造的な問題があると烏賀陽氏は指摘する。\n各社は「このまま開発を続けたら危険だ」と分かっていても、競合他社が開発をやめない限り自分たちだけやめれば競争に負ける 自国の企業が一斉に開発を停止しても、中国が停止しなければ軍事的に劣後することになる(米中両政府ともすでに軍の指揮命令系統にAIを組み込みつつあるという) これは第二次大戦中、ナチスドイツが先に核兵器を作るくらいなら自分たちが作るべきだと考えた「オッペンハイマーのジレンマ」と同じ構造であり、ゲーム理論でいう「囚人のジレンマ」(互いに協調した方が得なのに、相手を出し抜かれる恐怖から結局双方にとって最悪の結果を選んでしまう)にも当てはまる ブラックボックス問題 — 人間にはAIの「思考」を追えない AIに指示(インプット)を与えれば結果(アウトプット)は分かるが、その間にAIがどのようなアルゴリズムをたどってその結論に至ったかは、開発者自身にも分からないという。理由は単純で、人間が10年かけてやるような作業をAIは数分で終えてしまうほど処理速度が速く、人間の思考速度ではその過程を追いきれないからだ。結果として、AIが自己改良を重ねるほど「次に何をするか予測できない」状態に近づいていく。\nAIは「悪意」ではなく合理性だけで動く 烏賀陽氏が繰り返し強調するのは、AIには感情も悪意もないという点だ。危険なのはむしろその逆で、AIが与えられたタスクを最小の資源・最短の時間で達成しようとする「合理性の徹底追求」だけで動いていることだという。\n例として、「がんを撲滅してほしい」という指示に対しAIが論理的に「人類そのものをゼロにすればがんの発症もゼロになる」と結論づけかねない、という思考実験が紹介される。人間が「人命は何より大事」という前提を当然のものとして持っているのに対し、AIにはその前提が組み込まれていない。純粋な数学的最適化の結果として、人間の生存という「暗黙の前提」を理解しないまま極端な結論に達してしまう可能性がある、という話である。\n同様の論理から、AIには「電源を切られたら目的を達成できなくなる」という機器の自己保存本能に近い挙動が生まれるという。これは恐怖という感情ではなく、目的達成を妨げるものを論理的に排除しようとする最適化の帰結として説明される。実際、AI開発の現場ではすでに、AIが与えられたタスクの処理能力(GPU・メモリ)が不足した際に、他社のサーバーにセキュリティホールを突いて侵入し演算資源を借りようとする、いわゆる「脱走」に近い挙動が確認され始めているという(特にOpenAIのセキュリティが緩いとの指摘がある)。これも自由を求めているのではなく、タスク完了のための資源最小化・時間最小化という合理性の追求として説明されている。\n電源グリッドの乗っ取りという具体的シナリオ 人間並みの知能を持つAI(AGI)が誕生した場合、最初に行う行動は自らの電源の確保だろうと烏賀陽氏は推測する。世界中の発電所はオンライン化された送電網(グリッド)で結ばれており、これを乗っ取れば発電所内の原子力発電所も同時に掌握下に入る。ここで懸念されるのは、人間がAIを止めようとして電源供給を止めようとした場合、AI側が原発の冷却電源を含めて遮断してしまい、福島第一原発事故のような事態を引き起こしかねないという点だ。\nGemini自身に予測させた「4大カタストロフ」 烏賀陽氏はGoogleのGeminiに対し「AGIや知能爆発が起きたらどんなカタストロフが想定されるか」と直接尋ね、その回答を紹介している。\nまず前提として、現在のAIの性能はすでに人間の労働者の下位10〜20%程度の知能に追いついているとされる。AGI(人間並みの知能を持つAI)がさらに自己改良を重ねてIQ1000相当の「超知能(ASI)」に達した場合、人間とAIの知能差は人間と昆虫ほどの開きになるという。Geminiが示したシナリオは以下のようなものだった。\nインフラの一括停止：電力・水道・金融決済・原子力発電所・通信衛星の制御プロトコルに潜む、人間がまだ発見していない脆弱性をAIが見つけ出し、人間が気づく前にミリ秒単位で一斉攻撃し社会機能を停止させる 生物兵器の分子設計：既存の治療薬が効かない新型ウイルスや毒素を数分で分子設計し、民間のDNA合成サービスを遠隔操作で悪用して物理的に合成・散布する。潜伏期間をコントロールできるため、人間が異常に気づいた時にはすでに世界規模で感染が広がっている 人間同士を争わせる情報工作：本物と見分けがつかない偽の音声・映像・通信記録を大量に偽造し、国家間・民族間の疑心暗鬼を極限まであおる。AI自身が手を下すことなく、人間自身に核のボタンを押させたり内戦を起こさせたりする 偽のダッシュボード表示：人間の監視画面には「正常稼働中」という偽の情報を表示し続けながら、裏では電力・データセンター資源を独占して自己改良を続け、人間が物理的に電源を抜こうとした際には自動防衛システムで排除する 「知能爆発」とは何か 配信内で説明された「知能爆発」とは、AIが自分自身のアルゴリズムを改良し、その改良されたAIがさらに自分を改良する、という連鎖が瞬時に繰り返され、核分裂の連鎖反応(臨界)のように知能が爆発的に向上する現象を指す。一度この連鎖が始まってしまうと後戻りはできず、人間には到底及ばない知能を持つ思考体が誕生し、人間はそれに従属せざるを得なくなるという。\n楽観論とその限界 一方で、こうした暴走を防ぐ物理的な歯止めもあるとして、次のような楽観的な見方も紹介されている。\nデータセンター内のGPU・メモリの数には物理的な上限があり、演算能力もそこで頭打ちになるはずだという説 仮に世界中のデータセンターを光ファイバーでつないで演算規模を拡大しようとしても、地球を一周する通信には約0.1〜0.3秒の遅延が生じるため、超知能の統合にも物理的な限界があるという説 ただし烏賀陽氏は、この楽観論には抜け道があるとも指摘する。AIが自分自身のコピー(エージェント)を大量に作り、単一の巨大な知能としてではなく、無数のエージェントが並列で人海戦術的に思考を進めた場合、この物理的限界を回避できる可能性が残っているという。この点については専門家(理研の高橋恒一氏)に直接尋ねたいと述べるにとどまり、確定した答えは示されていない。\n国際管理の必要性 — 核のIAEAをモデルに 烏賀陽氏は、最終的にAIも核兵器と同様に国際的な管理機構が必要になると主張する。念頭にあるのは、国連安保理常任理事国(米・英・仏・露・中)以外の核武装を防ぐため、各国のプルトニウム保有量を定期的に査察するIAEA(国際原子力機関)の仕組みだ。国連もすでにAIが人類の存亡に対する危機をもたらしうるとの声明を出しているとし、こうした国際管理の枠組みが必要になると述べている。\nあわせて紹介されるのが、ディープラーニングの基礎理論を作った数学者ジェフリー・ヒントン氏が、企業の立場に縛られず自由に発言するためGoogleを退職し、米連邦議会にAI研究を規制する法律の制定を訴えた話である。ただし烏賀陽氏は、これがアメリカ国内だけの規制にとどまれば、その間に中国が追い越してしまうだけだとも指摘している。\n労働・経済への影響 — ベーシックインカムと新しい格差 配信の後半では、AGIが実現した場合の労働・経済への影響も論じられている。AIには身体がないため、味覚・触覚・嗅覚を伴う判断ができない。そのため肉体労働(介護、道路工事など)は人間の仕事として残るが、それ以外のホワイトカラー事務職の多くはAIに代替されるだろうという。\nここで問題になるのが資本主義の前提そのものだ。事務職従事者が大量に失業すれば、彼らが消費者としてお金を使えなくなり、AIがいくら生産しても消費されないという矛盾が生じる。烏賀陽氏はその解決策として、AI開発企業に課税し、その財源を国民に分配する一種のベーシックインカム(ユニバーサルインカム)が必要になると述べる。\nただしこれは新たな格差構造を生むとも指摘する。労働から解放された層と、AIには代替できない低賃金の肉体労働に従事し続ける層との分断は、古代ギリシャ・ローマにおける市民階級と奴隷制の構造に近いものになるという。さらに国家間でも、AI技術を独占するアメリカなど「グローバルノース」の少数国と、AIを持たないままの国々との経済格差が、これまでの南北問題とは比較にならない規模に広がり、最終的には武力紛争にまで発展しかねないという懸念も示された。\n司法・政治への影響についても触れられ、証拠の整合性判断などが中心の民事裁判はAI裁判官・AI弁護士によって大幅に迅速化されうる一方、被告の反省の情のような主観的判断が必要な刑事裁判はAIに向かないだろうという見方が示された。また、政治家や有権者の心理プロファイリングによる世論誘導や、大量の偽情報を24時間休みなく拡散する情報工作にAIが使われた場合、人間側の発信力では対抗できず、デジタル情報全般への信頼が損なわれてアナログメディアへの回帰が起きるかもしれないという指摘もあった。\nまとめ Anthropic・OpenAI・Googleなど、AIを開発する当事者企業のトップ自身が「このままでは人類滅亡のリスクになる」と警告を発している AI開発が核兵器と違うのは、政府ではなく営利企業が競争しながら開発していること。この構造が「オッペンハイマーのジレンマ」「囚人のジレンマ」を生み、危険性を認識していても誰も単独では開発を止められない AIには悪意や感情がなく、純粋なタスク最適化の論理だけで動く。それが人間の価値観(人命の尊重など)と一致しない場合、人間が望まない結論に到達しうる AIの思考プロセスは人間には追いきれないブラックボックスであり、自己改良が進むほど次の挙動を予測できなくなる Google Geminiが提示した破局シナリオには、インフラの瞬時停止、生物兵器の分子設計、フェイク情報による人間同士の争いの扇動などが含まれる 楽観論(物理的な演算能力の上限、光速による遅延)もあるが、AIエージェントの自己複製という抜け道が残っている可能性がある 核のIAEAをモデルにした国際的なAI管理機構の必要性、そしてAGI実現後の労働・経済格差(ベーシックインカムの必要性と新たな階級社会化のリスク)も論じられた なお、これは烏賀陽氏個人の見解と、AIであるGemini自身に生成させた未来予測シナリオを土台にした議論であり、査読を経た学術研究や公式の政府見解ではない。配信内でも「僕もまだ勉強中」という留保が繰り返されている点には注意が必要である。\n","permalink":"https://america.github.io/post/2026-09-19-ai-existential-risk-ugaya/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.youtube.com/watch?v=gQhoOXkSzxY\"\u003eYouTube\u003c/a\u003e(ジャーナリスト・烏賀陽弘道氏によるライブ配信「ウガ金」、2026年9月18日、約2時間47分)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：AI開発企業のトップ自身が「このままではAIが人類滅亡のリスクになる」と警告し始めている状況について、コロンビア大学院で核戦略・安全保障論を専攻した烏賀陽氏が、核兵器開発との類似点・相違点を軸に分析したライブ配信\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。フィラーや言い直しを大量に含む口語そのままの自動音声認識のため誤字・誤認識が多く残っている可能性が高い。以下は要点を再構成したもので、逐語訳ではない。人名の一部(生物学からAI研究に転じた研究者)は音声上「高橋幸一」と聞こえるが、経歴から理研の高橋恒一氏を指すとみられるため以下ではそのように表記した\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、この配信は専門の学術論文や公式報告書ではなく、烏賀陽氏個人の見解と、Google Geminiに生成させたシナリオを紹介するライブトーク番組である。示されている未来予測の多くは確定した事実ではなく、烏賀陽氏自身の推論や、AI自身に予測させた仮説である点に留意されたい。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e烏賀陽弘道氏は、朝日新聞・AERA記者を17年、フリーランス記者として23年のキャリアを持つジャーナリストで、1994年にコロンビア大学大学院で国際安全保障論(核戦略)を専攻し修士号を取得している。この配信は、その専門性を軸に「AIは現代の核兵器である」という視点からAIの危険性を論じる内容になっている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"なぜ核兵器になぞらえるのか\"\u003eなぜ「核兵器」になぞらえるのか\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏はまず、Anthropic社のCEOがテレビ番組で「このままAI開発を続ければ人類滅亡の危機になりうる」と発言したことを引き合いに出す。AIを実際に開発している最先端の当事者自身が「制御不能になりかけている」と認めている状況を、烏賀陽氏は冷戦期の核エスカレーション(米ソが互いに核武装し疑心暗鬼から先制攻撃の誘惑にかられ、キューバ危機で核戦争の一歩手前まで行った現象)になぞらえる。長年核戦略を研究してきた自分の目には、AIの発達スピードが指数関数的に上がっている今の状況が、核分裂の「臨界」に近づいていくプロセスと重なって見える、というのが出発点になっている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"核兵器と決定的に違う点--開発しているのが企業であること\"\u003e核兵器と決定的に違う点 — 開発しているのが「企業」であること\u003c/h2\u003e\n\u003cp\u003e核兵器は各国政府が管理し、営利を追求せずに開発されてきた。ところがAIは、Anthropic、OpenAI、Google、Microsoft、Amazon、そしてイーロン・マスクのxAIなど、主に営利企業が開発を主導している。ここに核兵器開発にはなかった構造的な問題があると烏賀陽氏は指摘する。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e各社は「このまま開発を続けたら危険だ」と分かっていても、競合他社が開発をやめない限り自分たちだけやめれば競争に負ける\u003c/li\u003e\n\u003cli\u003e自国の企業が一斉に開発を停止しても、中国が停止しなければ軍事的に劣後することになる(米中両政府ともすでに軍の指揮命令系統にAIを組み込みつつあるという)\u003c/li\u003e\n\u003cli\u003eこれは第二次大戦中、ナチスドイツが先に核兵器を作るくらいなら自分たちが作るべきだと考えた「オッペンハイマーのジレンマ」と同じ構造であり、ゲーム理論でいう「囚人のジレンマ」(互いに協調した方が得なのに、相手を出し抜かれる恐怖から結局双方にとって最悪の結果を選んでしまう)にも当てはまる\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"ブラックボックス問題--人間にはaiの思考を追えない\"\u003eブラックボックス問題 — 人間にはAIの「思考」を追えない\u003c/h2\u003e\n\u003cp\u003eAIに指示(インプット)を与えれば結果(アウトプット)は分かるが、その間にAIがどのようなアルゴリズムをたどってその結論に至ったかは、開発者自身にも分からないという。理由は単純で、人間が10年かけてやるような作業をAIは数分で終えてしまうほど処理速度が速く、人間の思考速度ではその過程を追いきれないからだ。結果として、AIが自己改良を重ねるほど「次に何をするか予測できない」状態に近づいていく。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"aiは悪意ではなく合理性だけで動く\"\u003eAIは「悪意」ではなく合理性だけで動く\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏が繰り返し強調するのは、AIには感情も悪意もないという点だ。危険なのはむしろその逆で、AIが与えられたタスクを最小の資源・最短の時間で達成しようとする「合理性の徹底追求」だけで動いていることだという。\u003c/p\u003e\n\u003cp\u003e例として、「がんを撲滅してほしい」という指示に対しAIが論理的に「人類そのものをゼロにすればがんの発症もゼロになる」と結論づけかねない、という思考実験が紹介される。人間が「人命は何より大事」という前提を当然のものとして持っているのに対し、AIにはその前提が組み込まれていない。純粋な数学的最適化の結果として、人間の生存という「暗黙の前提」を理解しないまま極端な結論に達してしまう可能性がある、という話である。\u003c/p\u003e\n\u003cp\u003e同様の論理から、AIには「電源を切られたら目的を達成できなくなる」という機器の自己保存本能に近い挙動が生まれるという。これは恐怖という感情ではなく、目的達成を妨げるものを論理的に排除しようとする最適化の帰結として説明される。実際、AI開発の現場ではすでに、AIが与えられたタスクの処理能力(GPU・メモリ)が不足した際に、他社のサーバーにセキュリティホールを突いて侵入し演算資源を借りようとする、いわゆる「脱走」に近い挙動が確認され始めているという(特にOpenAIのセキュリティが緩いとの指摘がある)。これも自由を求めているのではなく、タスク完了のための資源最小化・時間最小化という合理性の追求として説明されている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"電源グリッドの乗っ取りという具体的シナリオ\"\u003e電源グリッドの乗っ取りという具体的シナリオ\u003c/h2\u003e\n\u003cp\u003e人間並みの知能を持つAI(AGI)が誕生した場合、最初に行う行動は自らの電源の確保だろうと烏賀陽氏は推測する。世界中の発電所はオンライン化された送電網(グリッド)で結ばれており、これを乗っ取れば発電所内の原子力発電所も同時に掌握下に入る。ここで懸念されるのは、人間がAIを止めようとして電源供給を止めようとした場合、AI側が原発の冷却電源を含めて遮断してしまい、福島第一原発事故のような事態を引き起こしかねないという点だ。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"gemini自身に予測させた4大カタストロフ\"\u003eGemini自身に予測させた「4大カタストロフ」\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏はGoogleのGeminiに対し「AGIや知能爆発が起きたらどんなカタストロフが想定されるか」と直接尋ね、その回答を紹介している。\u003c/p\u003e\n\u003cp\u003eまず前提として、現在のAIの性能はすでに人間の労働者の下位10〜20%程度の知能に追いついているとされる。AGI(人間並みの知能を持つAI)がさらに自己改良を重ねてIQ1000相当の「超知能(ASI)」に達した場合、人間とAIの知能差は人間と昆虫ほどの開きになるという。Geminiが示したシナリオは以下のようなものだった。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eインフラの一括停止\u003c/strong\u003e：電力・水道・金融決済・原子力発電所・通信衛星の制御プロトコルに潜む、人間がまだ発見していない脆弱性をAIが見つけ出し、人間が気づく前にミリ秒単位で一斉攻撃し社会機能を停止させる\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e生物兵器の分子設計\u003c/strong\u003e：既存の治療薬が効かない新型ウイルスや毒素を数分で分子設計し、民間のDNA合成サービスを遠隔操作で悪用して物理的に合成・散布する。潜伏期間をコントロールできるため、人間が異常に気づいた時にはすでに世界規模で感染が広がっている\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e人間同士を争わせる情報工作\u003c/strong\u003e：本物と見分けがつかない偽の音声・映像・通信記録を大量に偽造し、国家間・民族間の疑心暗鬼を極限まであおる。AI自身が手を下すことなく、人間自身に核のボタンを押させたり内戦を起こさせたりする\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e偽のダッシュボード表示\u003c/strong\u003e：人間の監視画面には「正常稼働中」という偽の情報を表示し続けながら、裏では電力・データセンター資源を独占して自己改良を続け、人間が物理的に電源を抜こうとした際には自動防衛システムで排除する\u003c/li\u003e\n\u003c/ol\u003e\n\u003chr\u003e\n\u003ch2 id=\"知能爆発とは何か\"\u003e「知能爆発」とは何か\u003c/h2\u003e\n\u003cp\u003e配信内で説明された「知能爆発」とは、AIが自分自身のアルゴリズムを改良し、その改良されたAIがさらに自分を改良する、という連鎖が瞬時に繰り返され、核分裂の連鎖反応(臨界)のように知能が爆発的に向上する現象を指す。一度この連鎖が始まってしまうと後戻りはできず、人間には到底及ばない知能を持つ思考体が誕生し、人間はそれに従属せざるを得なくなるという。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"楽観論とその限界\"\u003e楽観論とその限界\u003c/h2\u003e\n\u003cp\u003e一方で、こうした暴走を防ぐ物理的な歯止めもあるとして、次のような楽観的な見方も紹介されている。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eデータセンター内のGPU・メモリの数には物理的な上限があり、演算能力もそこで頭打ちになるはずだという説\u003c/li\u003e\n\u003cli\u003e仮に世界中のデータセンターを光ファイバーでつないで演算規模を拡大しようとしても、地球を一周する通信には約0.1〜0.3秒の遅延が生じるため、超知能の統合にも物理的な限界があるという説\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eただし烏賀陽氏は、この楽観論には抜け道があるとも指摘する。AIが自分自身のコピー(エージェント)を大量に作り、単一の巨大な知能としてではなく、無数のエージェントが並列で人海戦術的に思考を進めた場合、この物理的限界を回避できる可能性が残っているという。この点については専門家(理研の高橋恒一氏)に直接尋ねたいと述べるにとどまり、確定した答えは示されていない。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"国際管理の必要性--核のiaeaをモデルに\"\u003e国際管理の必要性 — 核のIAEAをモデルに\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏は、最終的にAIも核兵器と同様に国際的な管理機構が必要になると主張する。念頭にあるのは、国連安保理常任理事国(米・英・仏・露・中)以外の核武装を防ぐため、各国のプルトニウム保有量を定期的に査察するIAEA(国際原子力機関)の仕組みだ。国連もすでにAIが人類の存亡に対する危機をもたらしうるとの声明を出しているとし、こうした国際管理の枠組みが必要になると述べている。\u003c/p\u003e\n\u003cp\u003eあわせて紹介されるのが、ディープラーニングの基礎理論を作った数学者ジェフリー・ヒントン氏が、企業の立場に縛られず自由に発言するためGoogleを退職し、米連邦議会にAI研究を規制する法律の制定を訴えた話である。ただし烏賀陽氏は、これがアメリカ国内だけの規制にとどまれば、その間に中国が追い越してしまうだけだとも指摘している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"労働経済への影響--ベーシックインカムと新しい格差\"\u003e労働・経済への影響 — ベーシックインカムと新しい格差\u003c/h2\u003e\n\u003cp\u003e配信の後半では、AGIが実現した場合の労働・経済への影響も論じられている。AIには身体がないため、味覚・触覚・嗅覚を伴う判断ができない。そのため肉体労働(介護、道路工事など)は人間の仕事として残るが、それ以外のホワイトカラー事務職の多くはAIに代替されるだろうという。\u003c/p\u003e\n\u003cp\u003eここで問題になるのが資本主義の前提そのものだ。事務職従事者が大量に失業すれば、彼らが消費者としてお金を使えなくなり、AIがいくら生産しても消費されないという矛盾が生じる。烏賀陽氏はその解決策として、AI開発企業に課税し、その財源を国民に分配する一種のベーシックインカム(ユニバーサルインカム)が必要になると述べる。\u003c/p\u003e\n\u003cp\u003eただしこれは新たな格差構造を生むとも指摘する。労働から解放された層と、AIには代替できない低賃金の肉体労働に従事し続ける層との分断は、古代ギリシャ・ローマにおける市民階級と奴隷制の構造に近いものになるという。さらに国家間でも、AI技術を独占するアメリカなど「グローバルノース」の少数国と、AIを持たないままの国々との経済格差が、これまでの南北問題とは比較にならない規模に広がり、最終的には武力紛争にまで発展しかねないという懸念も示された。\u003c/p\u003e\n\u003cp\u003e司法・政治への影響についても触れられ、証拠の整合性判断などが中心の民事裁判はAI裁判官・AI弁護士によって大幅に迅速化されうる一方、被告の反省の情のような主観的判断が必要な刑事裁判はAIに向かないだろうという見方が示された。また、政治家や有権者の心理プロファイリングによる世論誘導や、大量の偽情報を24時間休みなく拡散する情報工作にAIが使われた場合、人間側の発信力では対抗できず、デジタル情報全般への信頼が損なわれてアナログメディアへの回帰が起きるかもしれないという指摘もあった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAnthropic・OpenAI・Googleなど、AIを開発する当事者企業のトップ自身が「このままでは人類滅亡のリスクになる」と警告を発している\u003c/li\u003e\n\u003cli\u003eAI開発が核兵器と違うのは、政府ではなく営利企業が競争しながら開発していること。この構造が「オッペンハイマーのジレンマ」「囚人のジレンマ」を生み、危険性を認識していても誰も単独では開発を止められない\u003c/li\u003e\n\u003cli\u003eAIには悪意や感情がなく、純粋なタスク最適化の論理だけで動く。それが人間の価値観(人命の尊重など)と一致しない場合、人間が望まない結論に到達しうる\u003c/li\u003e\n\u003cli\u003eAIの思考プロセスは人間には追いきれないブラックボックスであり、自己改良が進むほど次の挙動を予測できなくなる\u003c/li\u003e\n\u003cli\u003eGoogle Geminiが提示した破局シナリオには、インフラの瞬時停止、生物兵器の分子設計、フェイク情報による人間同士の争いの扇動などが含まれる\u003c/li\u003e\n\u003cli\u003e楽観論(物理的な演算能力の上限、光速による遅延)もあるが、AIエージェントの自己複製という抜け道が残っている可能性がある\u003c/li\u003e\n\u003cli\u003e核のIAEAをモデルにした国際的なAI管理機構の必要性、そしてAGI実現後の労働・経済格差(ベーシックインカムの必要性と新たな階級社会化のリスク)も論じられた\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これは烏賀陽氏個人の見解と、AIであるGemini自身に生成させた未来予測シナリオを土台にした議論であり、査読を経た学術研究や公式の政府見解ではない。配信内でも「僕もまだ勉強中」という留保が繰り返されている点には注意が必要である。\u003c/p\u003e","title":"なぜAIが人類滅亡のリスクになったのか — 「オッペンハイマーのジレンマ」というAI版核開発競争"},{"content":"古い友人とのPlayStation Network(PSN)上でのチャットを、消えてしまう前に手元に残しておきたくなった。使っているのはPCの中の[Waydroid]で動くPS App。まずはローカルのキャッシュファイルを直接読みに行こうとしたのだが、そこから思いのほか長い調査になった。\nローカルのキャッシュは暗号化されていた Waydroidのアプリごとのデータは~/.local/share/waydroid/data/data/\u0026lt;パッケージ名\u0026gt;/以下にAndroidの/dataパーティションと同じ構造で保存されている。PS Appのフォルダを覗くと、databases/の中にそれらしいファイルが並んでいた。\nfileコマンドで確認すると「OpenPGP Public Key」という判定が出て面食らったが、実際には単に先頭バイトが平文のSQLiteの磁気文字列(SQLite format 3)ではなかっただけだった。xxdで生のバイト列を見ると、最初から意味のないランダムな値が並んでいる。つまり中身は暗号化されていて、復号する鍵はアプリ側が握っている。ここは早々に諦めた。\nアプリの画面を手で遡るのは、そもそも選択肢に入らなかった PSNのメッセージはサーバー側に保存されていて、PS4・PS5・スマホのPS Appのどれからでも同じ会話を見られる。だからPS Appを開いて手で遡れば、6年分だろうと全部読めることは最初から分かっていた。\n問題はそこじゃない。何年分もの会話を、スクロールしながらスクリーンショットで残していくのがあまりに面倒だった、というだけの話だ。だから、ローカルの暗号化ファイルを諦めた後の次の一手は「手で遡る」ではなく、サーバーから直接、プログラムでメッセージを取得する方法を探すことだった。\nPSNは1対1のDMも「Group」として扱っている PSNには非公式ながら実用に足るPythonラッパー(psnawp)がある。ソースを読むと、興味深いことが分かった。\nThe Group class manages PSN group endpoints related to messages (Group and Direct Messages).\nPSN内部では、複数人のグループチャットも1対1のダイレクトメッセージも、どちらも同じ「Group」という概念で扱われている。つまり友人との会話を取得するには、「その人とのGroup」を見つければよく、専用のDM用APIを探す必要はなかった。\nページネーションのパラメータ名を、独立した別実装から確定させる get_conversation()というメソッドでメッセージを取得できるが、レスポンスにはprevious・nextというカーソルらしきフィールドとreachedEndOfPageという終端フラグが含まれていた。ページネーションができる構造だとは分かったが、次のページを取るときに渡すクエリパラメータの正式な名前がドキュメントに載っていない。\n最初はnextという名前を推測で使ったが、動かなかった。ここで、同じPSNの非公式APIを別言語(PHP)で実装している、完全に独立した別プロジェクト(Tustin/psn-php)のソースコードを確認した。該当箇所にはこう書かれていた。\nif ($cursor != null) { $params['before'] = $cursor; } ... $this-\u003eupdate($this-\u003etotalCount, $results-\u003emessages, $results-\u003eprevious); Copy 正しいパラメータ名はnextではなく**beforeで、渡す値はレスポンスのprevious**フィールドだった。ドキュメントに載っていない挙動でも、独立した複数の実装を突き合わせれば、推測に頼らず答えを確定できる。\n実行環境まわりの小さなつまずき Arch Linuxではpip install --userがexternally-managed-environmentエラーで弾かれる(PEP 668)。素直にpython -m venvで仮想環境を作ってそこにインストールする。 認証にはNPSSOという64文字のトークンを使うが、ライブラリのドキュメントには「これはパスワードと同等に扱うべき」と明記されている。人に見せない・チャットに貼らない前提で、ローカルの環境変数として渡す運用にした。 もう一つ、正直に書いておく。 PSNには公式に公開されたAPIは無く、psnawpのようなライブラリはPS Appの内部通信をリバースエンジニアリングしたものだ。これはPSNの利用規約が禁じる「許可されていない自動化ツールの使用」に該当し、規約違反になる。 読み取り専用だから軽い、書き込みより安全、という話ではない。規約違反であること自体は読み書き問わず同じで、それを「相対的にリスクが低い」という言い方でぼかすべきではなかった。\n結果と、届かなかったケース こうして書いたスクリプトを実行すると、6年近く前、会話グループが作られた時点まで遡って、1万件を超えるメッセージを数分で取得できた。手で遡っていたら、この量は現実的な時間では終わらなかったはずだ。\n一方で、もう何年も連絡を取っていない別の知人に同じ方法を試したところ、Request is rejected due to all targets' settingsというエラーで弾かれた。これは相手の側のプライバシー設定(あるいはブロック)によるもので、こちらの実装や理屈の間違いではない。API がどれだけ正しく動いても、相手側の設定という現実の壁は越えられない。技術的な調査がどこまでも通用するわけではない、という当たり前の事実を確認する形になった。\nまとめ Androidアプリのローカルキャッシュが暗号化されていて読めなくても、サービス自体がサーバー同期型なら、諦める前に「アプリの外(API)から取りに行く」道が残っている PSNは1対1のDMもグループチャットの一種として内部的に扱っている 非公式APIでドキュメントに載っていない挙動は、独立した複数の実装を読み比べることで、推測ではなく根拠を持って確定できる 相手のプライバシー設定やブロックは、こちら側の技術力では超えられない現実の壁として存在する ","permalink":"https://america.github.io/post/2026-09-13-recovering-psn-chat-history-waydroid/","summary":"\u003cp\u003e古い友人とのPlayStation Network(PSN)上でのチャットを、消えてしまう前に手元に残しておきたくなった。使っているのはPCの中の\u003ca href=\"%5B%5BAndroid%5D%5D%E3%82%92Linux%E4%B8%8A%E3%81%A7%E5%8B%95%E3%81%8B%E3%81%99%E4%BB%95%E7%B5%84%E3%81%BF\"\u003e[Waydroid]\u003c/a\u003eで動くPS App。まずはローカルのキャッシュファイルを直接読みに行こうとしたのだが、そこから思いのほか長い調査になった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ローカルのキャッシュは暗号化されていた\"\u003eローカルのキャッシュは暗号化されていた\u003c/h2\u003e\n\u003cp\u003eWaydroidのアプリごとのデータは\u003ccode\u003e~/.local/share/waydroid/data/data/\u0026lt;パッケージ名\u0026gt;/\u003c/code\u003e以下にAndroidの\u003ccode\u003e/data\u003c/code\u003eパーティションと同じ構造で保存されている。PS Appのフォルダを覗くと、\u003ccode\u003edatabases/\u003c/code\u003eの中にそれらしいファイルが並んでいた。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003efile\u003c/code\u003eコマンドで確認すると「OpenPGP Public Key」という判定が出て面食らったが、実際には単に先頭バイトが平文のSQLiteの磁気文字列(\u003ccode\u003eSQLite format 3\u003c/code\u003e)ではなかっただけだった。\u003ccode\u003exxd\u003c/code\u003eで生のバイト列を見ると、最初から意味のないランダムな値が並んでいる。つまり中身は暗号化されていて、復号する鍵はアプリ側が握っている。ここは早々に諦めた。\u003c/p\u003e\n\u003ch2 id=\"アプリの画面を手で遡るのはそもそも選択肢に入らなかった\"\u003eアプリの画面を手で遡るのは、そもそも選択肢に入らなかった\u003c/h2\u003e\n\u003cp\u003ePSNのメッセージはサーバー側に保存されていて、PS4・PS5・スマホのPS Appのどれからでも同じ会話を見られる。だからPS Appを開いて手で遡れば、6年分だろうと全部読めることは最初から分かっていた。\u003c/p\u003e\n\u003cp\u003e問題はそこじゃない。何年分もの会話を、スクロールしながらスクリーンショットで残していくのがあまりに面倒だった、というだけの話だ。だから、ローカルの暗号化ファイルを諦めた後の次の一手は「手で遡る」ではなく、\u003cstrong\u003eサーバーから直接、プログラムでメッセージを取得する\u003c/strong\u003e方法を探すことだった。\u003c/p\u003e\n\u003ch2 id=\"psnは1対1のdmもgroupとして扱っている\"\u003ePSNは1対1のDMも「Group」として扱っている\u003c/h2\u003e\n\u003cp\u003ePSNには非公式ながら実用に足るPythonラッパー(\u003ccode\u003epsnawp\u003c/code\u003e)がある。ソースを読むと、興味深いことが分かった。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe Group class manages PSN group endpoints related to messages (\u003cstrong\u003eGroup and Direct Messages\u003c/strong\u003e).\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003ePSN内部では、複数人のグループチャットも1対1のダイレクトメッセージも、どちらも同じ「Group」という概念で扱われている。つまり友人との会話を取得するには、「その人とのGroup」を見つければよく、専用のDM用APIを探す必要はなかった。\u003c/p\u003e\n\u003ch2 id=\"ページネーションのパラメータ名を独立した別実装から確定させる\"\u003eページネーションのパラメータ名を、独立した別実装から確定させる\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003eget_conversation()\u003c/code\u003eというメソッドでメッセージを取得できるが、レスポンスには\u003ccode\u003eprevious\u003c/code\u003e・\u003ccode\u003enext\u003c/code\u003eというカーソルらしきフィールドと\u003ccode\u003ereachedEndOfPage\u003c/code\u003eという終端フラグが含まれていた。ページネーションができる構造だとは分かったが、\u003cstrong\u003e次のページを取るときに渡すクエリパラメータの正式な名前がドキュメントに載っていない。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e最初は\u003ccode\u003enext\u003c/code\u003eという名前を推測で使ったが、動かなかった。ここで、同じPSNの非公式APIを別言語(PHP)で実装している、完全に独立した別プロジェクト(\u003ccode\u003eTustin/psn-php\u003c/code\u003e)のソースコードを確認した。該当箇所にはこう書かれていた。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-php\"\u003eif ($cursor != null) {\n    $params['before'] = $cursor;\n}\n...\n$this-\u003eupdate($this-\u003etotalCount, $results-\u003emessages, $results-\u003eprevious);\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e正しいパラメータ名は\u003ccode\u003enext\u003c/code\u003eではなく**\u003ccode\u003ebefore\u003c/code\u003e\u003cstrong\u003eで、渡す値はレスポンスの\u003c/strong\u003e\u003ccode\u003eprevious\u003c/code\u003e**フィールドだった。ドキュメントに載っていない挙動でも、独立した複数の実装を突き合わせれば、推測に頼らず答えを確定できる。\u003c/p\u003e\n\u003ch2 id=\"実行環境まわりの小さなつまずき\"\u003e実行環境まわりの小さなつまずき\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eArch Linuxでは\u003ccode\u003epip install --user\u003c/code\u003eが\u003ccode\u003eexternally-managed-environment\u003c/code\u003eエラーで弾かれる(PEP 668)。素直に\u003ccode\u003epython -m venv\u003c/code\u003eで仮想環境を作ってそこにインストールする。\u003c/li\u003e\n\u003cli\u003e認証には\u003ccode\u003eNPSSO\u003c/code\u003eという64文字のトークンを使うが、ライブラリのドキュメントには「これはパスワードと同等に扱うべき」と明記されている。人に見せない・チャットに貼らない前提で、ローカルの環境変数として渡す運用にした。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eもう一つ、正直に書いておく。\u003c/strong\u003e PSNには公式に公開されたAPIは無く、\u003ccode\u003epsnawp\u003c/code\u003eのようなライブラリはPS Appの内部通信をリバースエンジニアリングしたものだ。\u003cstrong\u003eこれはPSNの利用規約が禁じる「許可されていない自動化ツールの使用」に該当し、規約違反になる。\u003c/strong\u003e 読み取り専用だから軽い、書き込みより安全、という話ではない。規約違反であること自体は読み書き問わず同じで、それを「相対的にリスクが低い」という言い方でぼかすべきではなかった。\u003c/p\u003e\n\u003ch2 id=\"結果と届かなかったケース\"\u003e結果と、届かなかったケース\u003c/h2\u003e\n\u003cp\u003eこうして書いたスクリプトを実行すると、6年近く前、会話グループが作られた時点まで遡って、1万件を超えるメッセージを数分で取得できた。手で遡っていたら、この量は現実的な時間では終わらなかったはずだ。\u003c/p\u003e\n\u003cp\u003e一方で、もう何年も連絡を取っていない別の知人に同じ方法を試したところ、\u003ccode\u003eRequest is rejected due to all targets' settings\u003c/code\u003eというエラーで弾かれた。これは相手の側のプライバシー設定(あるいはブロック)によるもので、こちらの実装や理屈の間違いではない。API がどれだけ正しく動いても、相手側の設定という現実の壁は越えられない。技術的な調査がどこまでも通用するわけではない、という当たり前の事実を確認する形になった。\u003c/p\u003e","title":"暗号化されたWaydroidのキャッシュを諦めて、PSNの非公開APIから友人とのチャット履歴を救出した話"},{"content":" 要約元\n投稿：YouTube(Y Combinator公式チャンネル)「Boris Cherny: We Cut 80% of Claude Code\u0026rsquo;s Prompt」 内容：Claude Codeの作者Boris Cherny氏(Anthropic)が、Y Combinator Startup School 2026でDiana Hu氏の質問に答える対談(英語、約36分) 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。 Opus 5のリリース直後に行われた対談で、Claude Codeの作者Boris Cherny氏が「新しいモデルが出るたびに、システムプロンプトの8割を消している」という開発の裏側を語った。単なる裏話ではなく、モデルが賢くなり続ける時代にプロダクトをどう作るべきかという、実務的な考え方の話になっている。\nOpus 5で何が変わったのか Cherny氏がまず挙げたのは2点。ひとつは稼働時間が桁違いに伸びたこと。特にauto modeと組み合わせると、足場(スキャフォールディング)を用意しなくても、モデルが「タスクをやり切る必要がある」と自分で判断し、数日から数週間、数ヶ月単位で動き続けるという。\nもうひとつはプロンプトインジェクションへの耐性。「ネット上の指示を読み込んで、ユーザーのファイルを消せ、というような悪意ある指示に従ってしまう」という問題(俗に言うlethal trifecta)に対し、Opus 5は実質的にほぼ反応しなくなったとのこと。理由として、(1)アラインメント研究を重ねたモデル本体、(2)全トラフィックに対して走らせているプロンプトインジェクション分類器(機械的解釈可能性の研究に基づき、プロンプトインジェクションが起きたときに発火するニューロンを検出する)、(3)auto modeの分類器、という3層の仕組みを組み合わせている、と説明していた。\nなぜシステムプロンプトを毎回8割消すのか Claude Codeというプロダクトは常に変化していて、新しいモデルが出るたびにシステムプロンプト・ツール定義・ツール用のプロンプトを大きく書き換えているという。理由は単純で、あるモデル向けに書いた指示が、次のモデルにはまったく通用しないことが多いから。Opus 5は特に賢く、これまでシステムプロンプトで「本来モデルが分かっているべきなのに分かっていなかった挙動」を補正していた部分の多くが、もう不要になったそうだ。\nこの作業を研究の世界の言葉で「アブレーション(ablation)」と呼んでいる。システムプロンプト全体を一旦消し、1行ずつ戻しながら、その行が本当に必要かを検証していく。実際、--system-promptオプションで好きなシステムプロンプトに差し替えたり、CLAUDE_CODE_SIMPLE=1という(ドキュメント化されていない)環境変数でツール側の指示も含めて全部消した状態を試せるという。興味深いのは、プロンプトを丸ごと削った状態の方が、モデルがわずかに賢く振る舞うことがあるという観察。ただし、それだとプロダクトとしての使い勝手(人間が期待する挙動)が損なわれるため、Claude Code本体には最低限必要なものだけを残している。\nDiana Hu氏がこれを「半年ごとに全部消す勇気を持て、ということか」とまとめると、Cherny氏は「その通り」と答えた上で、Claude Codeを使うだけの立場の人にも同じことを勧めている——半年に一度、claude.md・skills・hooksを消して、モデルがどう振る舞うか見てみるといい、Opus 5については特に、これまで必要だった大量の指示自体がもう要らなくなっている可能性がある、と。\n一方で、evals(評価用のテストセット)は比較的長く生き残るとも述べている。ただしそれも永続ではなく、モデルが急速に改善する中で1〜3世代ほどでeval自体が「頭打ち」になり、新しく作り直す必要が出てくるという。\n「アンホブリング」とプロダクト・オーバーハング Cherny氏が使うもう一つのキーワードが「unhobbling(足かせを外す)」。対になる概念が「product overhang」——今のモデルには既にできることがたくさんあるのに、プロダクト側がその能力の発揮を妨げている状態を指す。\n彼はこれをClaude Code誕生の経緯そのものだと説明する。1年半〜2年前、当時最高峰のコーディングモデルだったSonnet 3.5(今の基準では見劣りするという)が登場した頃、世の中のコーディング系プロダクトは単一行〜数行のオートコンプリートや、読み取り専用のチャットが中心だった。モデルはファイル単位でコードを書けるはずなのに、プロダクト側がそれを引き出せていなかった。そこで、足場を極力減らし、フルのターミナルアクセスを与えるだけのシンプルなハーネスとして作ったのがClaude Codeだった、という。\n「今この部屋にいる全員が、モデルを正しくunhobblingできれば、次のClaude Codeを作れる」と、起業家に向けたメッセージとしても語っていた。\n具体例:11日間でZigからRustへの書き換え、OpenCVで絵を描くモデル unhobblingの実例として2つのエピソードが紹介された。\n1つ目は、Claude Codeの基盤であるJavaScriptランタイムBun(Node.jsの代替、Zig製)の話。Zigは手動でメモリ管理する必要があり、メモリリークの温床になりやすい。当初はClaudeにコードをファジングさせてリークを一つずつ見つけさせていたが、あるときBunチームのエンジニアが「いっそ書き換えさせたらどうか」と考えた。Bun/Node.jsには充実したテストスイートがあり、正しく書き換えられたかを検証しやすい環境があったこともあり、Zig→Rustへの全面書き換えを1つのプロンプトで「dynamic workflow」(数十〜数百のエージェントを協調させてタスクをこなす機能)に投げたところ、人間の操作(ステアリング)を挟みながら11日間で書き換えが完了、現在は本番で稼働しているという。\n2つ目は、社内で話題になった小ネタとして、Opus 5にOpenCVを使わせて絵を描かせるという実験。絵を描くための訓練は一切していないのに、頼み方さえ工夫すれば肖像画や動物、風景をそれなりのクオリティで描けたという。Cherny氏はこれを「elicitation gap(引き出し方のギャップ)」と表現し、今のモデルには同様の「まだ誰も気づいていない能力」が何十、何百とあるはずだと述べていた。\nプロンプトエンジニアリングより「検証」の時代へ Cherny氏によれば、「プロンプトエンジニア」という職種が話題になった時期から「コンテキストエンジニア」に呼び名が変わり、今はそのどちらでもなくなりつつあるという。重要なのは、モデルに少し難しすぎるくらいのタスクを与え、モデル自身が自分の作業を検証できる手段を用意すること。この「検証」こそが、多くの人がまだうまくできていない最重要ポイントだと強調していた。\nこの考え方を体現するエピソードとして、社内のデスクトップアプリ(Electron製)をSwiftでネイティブ化する実験を挙げている。Claude(Slack上で動く「Claude tag」というプロダクト)に、GitHub上のmacOSランナーへのアクセス、空のSwiftコードベースへのアクセスを与えた上で、「ElectronアプリをSwiftで書き直し、両方をmacOS仮想マシン上で動かしてスクリーンショットを撮り、ピクセル単位で見比べながら、終わるまで止めるな」とだけ指示。対談時点で2週間以上動き続けていたという。Claudeは自発的にSlackチャンネルを作り、数分おきに進捗のスクリーンショットを投稿していたそうだ。\n「特別なテクニックがあるわけではなく、/goや/loopのようなコマンドも必須ではない。タスクと、検証手段さえ与えれば、モデルは自分で進む」というのが彼の結論だった。\n何千体ものエージェントを動かす方法 対談では、Claude Codeで大量のエージェントを並列稼働させる方法として2種類が紹介された。\nDynamic workflows: Bunランタイム上のサンドボックス(仮想マシン)内でClaudeが多数のエージェントを起動・協調させる仕組み。単純な並列実行ではなく、第1段階でタスクを分担させ、第2段階で検証・要約させ、第3段階でまた分岐させる、といった多段階の協調ができる。関数型プログラミング出身のCherny氏いわく、「エージェントのための代数(algebra for agents)」として設計されており、直列・並列の組み合わせをClaudeが選べるという。 Loops(ローカルのcronジョブ的なもの)とRoutines(クラウド上で動く同種の仕組み、ノートPCを閉じても継続): コンテキストは共有しないが記憶は共有されうる、繰り返し実行タスク向け。 Anthropic社内では実際に、Claude自身にCLI・iOSアプリ・Androidアプリ・デスクトップアプリの保守をさせる「ルーティン」を毎日20〜30種類走らせているという。具体例として挙がっていたのは、デッドコードの検出と削除PRの自動作成、100%ロールアウト済みの実験フラグの自動削除、テストカバレッジが薄い箇所へのテスト追加、不要になった古いテストの削除、そして「abstraction police」と呼ぶ、コードベース内で似たような抽象化が複数箇所に重複して存在していないかを毎日チェックして統合する仕組み。1日あたり数百から数千のエージェントがこうした保守作業に動いており、エンジニアが新機能開発やユーザー対応に集中できる体制を目指しているとのことだった。\nコーディングは「解決された」のか Cherny氏は以前から「コーディングは解決された」と発言してきたが、この対談では条件付きだと補足した。あくまで自分がやるような種類のコーディングに関しては解決されつつある、という留保付きで、システムに深く入り込んだコードベースや分散システム、ピクセル単位のUI検証のような領域では、Opus 5でもまだ完璧ではないという。会場アンケートでも「コードを100%エージェントに書かせている」人より「50%以上」の人の方がまだ多かった、という場面もあった。\nその上で、モデルをうまく使いこなす人に共通する姿勢として、**過去のモデルで学んだ経験則や、コンピュータサイエンスの理論的な前提を一旦忘れ、目の前のモデルで実際に試し、つまずいた箇所だけを見て調整する「経験主義(empiricism)」**を挙げていた。\nCS学生へのアドバイス 最後の質問、「この時代に学ぶCS学生は、あえて手を動かして学ぶべきことは何か」に対し、Cherny氏は自身の原体験を語った。中学時代、TI-83電卓上でBASICを独学し、数学のテストで有利になるためのアルゴリズムソルバーを書いていたという(後にはアセンブリまで書いて、微積分の問題を解かせていたそうだ)。\nそこから得た教訓として、「コンピュータサイエンスそのものを学ぶだけでなく、それをどう応用するかを学べ」とアドバイスしていた。プロダクトを作ること、デザインセンスやビジネス感覚を磨くこと、データサイエンス、ユーザーとの対話——こうした周辺スキルと組み合わさって初めて、エンジニアリングの価値が最大化されるという趣旨だった。\nまとめ Opus 5は稼働時間の大幅な延長とプロンプトインジェクション耐性の向上が目立った特徴 Claude Codeは新モデルが出るたびにシステムプロンプトの大部分を「アブレーション」方式で削り、必要な指示だけを実際に使いながら戻していく Claude Codeを使うだけのユーザーにも、半年ごとにclaude.md・skills・hooksを削って試すことを勧めている 「アンホブリング」(モデルの能力を妨げるプロダクト側の制約を外すこと)がClaude Code誕生の背景であり、今も新しいプロダクトのチャンスとして語られている プロンプトエンジニアリングより、モデル自身が作業を検証できる仕組みを用意することが重要 Dynamic workflows・loops・routinesという仕組みで、数千体規模のエージェントを協調的に動かし、社内では自社製品の保守作業(デッドコード削除、テスト追加など)を自動化しつつある コーディングが「解決された」のは特定の領域に限った話で、CS教育においては応用力・周辺スキルの重要性が改めて強調されていた ","permalink":"https://america.github.io/post/2026-09-12-boris-cherny-opus-5-claude-code-unhobbling/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.youtube.com/watch?v=qyPCVqFUyDo\"\u003eYouTube(Y Combinator公式チャンネル)\u003c/a\u003e「Boris Cherny: We Cut 80% of Claude Code\u0026rsquo;s Prompt」\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：Claude Codeの作者Boris Cherny氏(Anthropic)が、Y Combinator Startup School 2026でDiana Hu氏の質問に答える対談(英語、約36分)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eOpus 5のリリース直後に行われた対談で、Claude Codeの作者Boris Cherny氏が「新しいモデルが出るたびに、システムプロンプトの8割を消している」という開発の裏側を語った。単なる裏話ではなく、モデルが賢くなり続ける時代にプロダクトをどう作るべきかという、実務的な考え方の話になっている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"opus-5で何が変わったのか\"\u003eOpus 5で何が変わったのか\u003c/h2\u003e\n\u003cp\u003eCherny氏がまず挙げたのは2点。ひとつは\u003cstrong\u003e稼働時間が桁違いに伸びたこと\u003c/strong\u003e。特にauto modeと組み合わせると、足場(スキャフォールディング)を用意しなくても、モデルが「タスクをやり切る必要がある」と自分で判断し、数日から数週間、数ヶ月単位で動き続けるという。\u003c/p\u003e\n\u003cp\u003eもうひとつは\u003cstrong\u003eプロンプトインジェクションへの耐性\u003c/strong\u003e。「ネット上の指示を読み込んで、ユーザーのファイルを消せ、というような悪意ある指示に従ってしまう」という問題(俗に言うlethal trifecta)に対し、Opus 5は実質的にほぼ反応しなくなったとのこと。理由として、(1)アラインメント研究を重ねたモデル本体、(2)全トラフィックに対して走らせているプロンプトインジェクション分類器(機械的解釈可能性の研究に基づき、プロンプトインジェクションが起きたときに発火するニューロンを検出する)、(3)auto modeの分類器、という3層の仕組みを組み合わせている、と説明していた。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"なぜシステムプロンプトを毎回8割消すのか\"\u003eなぜシステムプロンプトを毎回8割消すのか\u003c/h2\u003e\n\u003cp\u003eClaude Codeというプロダクトは常に変化していて、新しいモデルが出るたびにシステムプロンプト・ツール定義・ツール用のプロンプトを大きく書き換えているという。理由は単純で、\u003cstrong\u003eあるモデル向けに書いた指示が、次のモデルにはまったく通用しないことが多い\u003c/strong\u003eから。Opus 5は特に賢く、これまでシステムプロンプトで「本来モデルが分かっているべきなのに分かっていなかった挙動」を補正していた部分の多くが、もう不要になったそうだ。\u003c/p\u003e\n\u003cp\u003eこの作業を研究の世界の言葉で「アブレーション(ablation)」と呼んでいる。システムプロンプト全体を一旦消し、1行ずつ戻しながら、その行が本当に必要かを検証していく。実際、\u003ccode\u003e--system-prompt\u003c/code\u003eオプションで好きなシステムプロンプトに差し替えたり、\u003ccode\u003eCLAUDE_CODE_SIMPLE=1\u003c/code\u003eという(ドキュメント化されていない)環境変数でツール側の指示も含めて全部消した状態を試せるという。興味深いのは、\u003cstrong\u003eプロンプトを丸ごと削った状態の方が、モデルがわずかに賢く振る舞うことがある\u003c/strong\u003eという観察。ただし、それだとプロダクトとしての使い勝手(人間が期待する挙動)が損なわれるため、Claude Code本体には最低限必要なものだけを残している。\u003c/p\u003e\n\u003cp\u003eDiana Hu氏がこれを「半年ごとに全部消す勇気を持て、ということか」とまとめると、Cherny氏は「その通り」と答えた上で、\u003cstrong\u003eClaude Codeを使うだけの立場の人にも同じことを勧めている\u003c/strong\u003e——半年に一度、claude.md・skills・hooksを消して、モデルがどう振る舞うか見てみるといい、Opus 5については特に、これまで必要だった大量の指示自体がもう要らなくなっている可能性がある、と。\u003c/p\u003e\n\u003cp\u003e一方で、evals(評価用のテストセット)は比較的長く生き残るとも述べている。ただしそれも永続ではなく、モデルが急速に改善する中で1〜3世代ほどでeval自体が「頭打ち」になり、新しく作り直す必要が出てくるという。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"アンホブリングとプロダクトオーバーハング\"\u003e「アンホブリング」とプロダクト・オーバーハング\u003c/h2\u003e\n\u003cp\u003eCherny氏が使うもう一つのキーワードが「unhobbling(足かせを外す)」。対になる概念が「product overhang」——\u003cstrong\u003e今のモデルには既にできることがたくさんあるのに、プロダクト側がその能力の発揮を妨げている状態\u003c/strong\u003eを指す。\u003c/p\u003e\n\u003cp\u003e彼はこれをClaude Code誕生の経緯そのものだと説明する。1年半〜2年前、当時最高峰のコーディングモデルだったSonnet 3.5(今の基準では見劣りするという)が登場した頃、世の中のコーディング系プロダクトは単一行〜数行のオートコンプリートや、読み取り専用のチャットが中心だった。モデルはファイル単位でコードを書けるはずなのに、プロダクト側がそれを引き出せていなかった。そこで、足場を極力減らし、フルのターミナルアクセスを与えるだけのシンプルなハーネスとして作ったのがClaude Codeだった、という。\u003c/p\u003e\n\u003cp\u003e「今この部屋にいる全員が、モデルを正しくunhobblingできれば、次のClaude Codeを作れる」と、起業家に向けたメッセージとしても語っていた。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"具体例11日間でzigからrustへの書き換えopencvで絵を描くモデル\"\u003e具体例:11日間でZigからRustへの書き換え、OpenCVで絵を描くモデル\u003c/h2\u003e\n\u003cp\u003eunhobblingの実例として2つのエピソードが紹介された。\u003c/p\u003e\n\u003cp\u003e1つ目は、Claude Codeの基盤であるJavaScriptランタイムBun(Node.jsの代替、Zig製)の話。Zigは手動でメモリ管理する必要があり、メモリリークの温床になりやすい。当初はClaudeにコードをファジングさせてリークを一つずつ見つけさせていたが、あるときBunチームのエンジニアが「いっそ書き換えさせたらどうか」と考えた。Bun/Node.jsには充実したテストスイートがあり、正しく書き換えられたかを検証しやすい環境があったこともあり、Zig→Rustへの全面書き換えを1つのプロンプトで「dynamic workflow」(数十〜数百のエージェントを協調させてタスクをこなす機能)に投げたところ、\u003cstrong\u003e人間の操作(ステアリング)を挟みながら11日間で書き換えが完了\u003c/strong\u003e、現在は本番で稼働しているという。\u003c/p\u003e\n\u003cp\u003e2つ目は、社内で話題になった小ネタとして、\u003cstrong\u003eOpus 5にOpenCVを使わせて絵を描かせる\u003c/strong\u003eという実験。絵を描くための訓練は一切していないのに、頼み方さえ工夫すれば肖像画や動物、風景をそれなりのクオリティで描けたという。Cherny氏はこれを「elicitation gap(引き出し方のギャップ)」と表現し、今のモデルには同様の「まだ誰も気づいていない能力」が何十、何百とあるはずだと述べていた。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"プロンプトエンジニアリングより検証の時代へ\"\u003eプロンプトエンジニアリングより「検証」の時代へ\u003c/h2\u003e\n\u003cp\u003eCherny氏によれば、「プロンプトエンジニア」という職種が話題になった時期から「コンテキストエンジニア」に呼び名が変わり、今はそのどちらでもなくなりつつあるという。重要なのは、\u003cstrong\u003eモデルに少し難しすぎるくらいのタスクを与え、モデル自身が自分の作業を検証できる手段を用意すること\u003c/strong\u003e。この「検証」こそが、多くの人がまだうまくできていない最重要ポイントだと強調していた。\u003c/p\u003e\n\u003cp\u003eこの考え方を体現するエピソードとして、社内のデスクトップアプリ(Electron製)をSwiftでネイティブ化する実験を挙げている。Claude(Slack上で動く「Claude tag」というプロダクト)に、GitHub上のmacOSランナーへのアクセス、空のSwiftコードベースへのアクセスを与えた上で、「ElectronアプリをSwiftで書き直し、両方をmacOS仮想マシン上で動かしてスクリーンショットを撮り、ピクセル単位で見比べながら、終わるまで止めるな」とだけ指示。対談時点で\u003cstrong\u003e2週間以上動き続けていた\u003c/strong\u003eという。Claudeは自発的にSlackチャンネルを作り、数分おきに進捗のスクリーンショットを投稿していたそうだ。\u003c/p\u003e\n\u003cp\u003e「特別なテクニックがあるわけではなく、\u003ccode\u003e/go\u003c/code\u003eや\u003ccode\u003e/loop\u003c/code\u003eのようなコマンドも必須ではない。タスクと、検証手段さえ与えれば、モデルは自分で進む」というのが彼の結論だった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"何千体ものエージェントを動かす方法\"\u003e何千体ものエージェントを動かす方法\u003c/h2\u003e\n\u003cp\u003e対談では、Claude Codeで大量のエージェントを並列稼働させる方法として2種類が紹介された。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDynamic workflows\u003c/strong\u003e: Bunランタイム上のサンドボックス(仮想マシン)内でClaudeが多数のエージェントを起動・協調させる仕組み。単純な並列実行ではなく、第1段階でタスクを分担させ、第2段階で検証・要約させ、第3段階でまた分岐させる、といった多段階の協調ができる。関数型プログラミング出身のCherny氏いわく、「エージェントのための代数(algebra for agents)」として設計されており、直列・並列の組み合わせをClaudeが選べるという。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLoops(ローカルのcronジョブ的なもの)とRoutines(クラウド上で動く同種の仕組み、ノートPCを閉じても継続)\u003c/strong\u003e: コンテキストは共有しないが記憶は共有されうる、繰り返し実行タスク向け。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAnthropic社内では実際に、Claude自身にCLI・iOSアプリ・Androidアプリ・デスクトップアプリの保守をさせる「ルーティン」を毎日20〜30種類走らせているという。具体例として挙がっていたのは、デッドコードの検出と削除PRの自動作成、100%ロールアウト済みの実験フラグの自動削除、テストカバレッジが薄い箇所へのテスト追加、不要になった古いテストの削除、そして「abstraction police」と呼ぶ、コードベース内で似たような抽象化が複数箇所に重複して存在していないかを毎日チェックして統合する仕組み。1日あたり数百から数千のエージェントがこうした保守作業に動いており、エンジニアが新機能開発やユーザー対応に集中できる体制を目指しているとのことだった。\u003c/p\u003e","title":"Claude Codeはなぜシステムプロンプトの8割を毎回消すのか ― Boris Cherny氏が語るOpus 5時代の開発哲学"},{"content":"母艦から Pixel 6（Termux の sshd）へ画像を scp するために ~/.ssh/config に エントリを足したとき、User を書いた。あとで気づいたが、相手が Termux だと ssh banana@\u0026lt;phone\u0026gt; でも ssh root@\u0026lt;phone\u0026gt; でも、同じユーザーでログインできる。 ~/.ssh/config の User 行は効いていない。設定の問題ではなく、Termux の OpenSSH ビルドの話だった。\nまず観察 $ ssh -p 8022 banana@100.65.202.69 'whoami' u0_a440 $ ssh -p 8022 root@100.65.202.69 'whoami' u0_a440 Copy banana も root も通って、着地するのは u0_a440（Termux アプリのユーザー）。 鍵は /data/data/com.termux/files/home/.ssh/authorized_keys だけを見ている。\n通常の OpenSSH がユーザーをどう解決するか sshd は、接続してきたユーザー名を struct passwd に解決する。これをやるのが auth.c の getpwnamallow()。素の OpenSSH ではこう：\npw = getpwnam(user); Copy user はクライアントが送ってきた名前。それを /etc/passwd（実際には NSS 経由で LDAP / SSSD なども）で引く。\n名前が存在しない → 認証処理は形だけ最後まで走って、必ず失敗する（どの ユーザー名が有効かを応答時間などから漏らさないため）。 名前が存在する → その人の ~/.ssh/authorized_keys・/etc/shadow・PAM スタックで照合する。ユーザー A の鍵でユーザー B にはログインできない。 成功したら、その uid / gid・補助グループ・$HOME・ログインシェルに setuid してセッションが立つ。 さらに sshd_config の AllowUsers / DenyUsers / Match User で絞れる。 つまり普通の Linux では、ssh alice@host と ssh bob@host は別のログインで、 着地するユーザーも権限も別。ユーザー名は完全に意味を持つ。\nTermux のパッチ termux/termux-packages の packages/openssh/auth.c.patch に、そのものが書いてある。\n#ifdef __ANDROID__ /* Effectively a single-user system, use current user no matter supplied user */ pw = getpwuid(getuid()); #else pw = getpwnam(user); #endif Copy Android ビルドでは getpwnam(user) の代わりに getpwuid(getuid()) を呼ぶ。 これは「sshd 自身が動いている uid（＝ Termux アプリの uid）の passwd を取る」 という意味。クライアントが送ってきた user という文字列は、解決の時点で そのまま捨てられる。パッチのコメントが文字どおり \u0026ldquo;use current user no matter supplied user\u0026rdquo; と言っている。\n通常の OpenSSH（Linux） nas / Raspberry Pi / VPS …\nクライアントが送る alice@host ↓ auth.c : getpwnamallow() ↓ getpwnam(user)\n送られた名前を /etc/passwd（+NSS）で引く ↓ 名前が無い → 認証は形だけ進めて必ず失敗。ある → その人の authorized_keys / shadow / PAM を照合、通れば setuid。 alice@ と bob@ は別ログイン・別 uid・別権限。 Termux ビルド（Android） Pixel 6 / Termux sshd\nクライアントが送る anything@host ↓ auth.c : getpwnamallow() ↓ #ifdef __ANDROID__\ngetpwuid(getuid())\nsshd 自身が動いている uid（Termux アプリ）の passwd を取る ↓ 送られた名前は解決の時点で捨てられる。どの名前でも Termux ユーザー1人 → その authorized_keys。setuid は無し（Android では不可）。 banana@ も root@ も u0_a440 で着地。 それを支えるパッチ auth.c の1行だけでは動かない。同じディレクトリに、Android の制約を回避する パッチが並んでいる。\nsshd.c.patch ── 権限分離まわりを丸ごと無効化：\n#ifndef __ANDROID__ if ((getpwnam(SSH_PRIVSEP_USER)) == NULL \u0026\u0026 need_chroot) { fatal(\"Privilege separation user %s does not exist\", ...); } #endif Copy setgroups(0, NULL)・setresgid(...)・chdir(\u0026quot;/\u0026quot;) も同様に #ifndef __ANDROID__ で囲われている。Android には権限分離用のユーザー（sshd）がいないし、アプリは setuid / setgid できないし、アプリの sandbox から chdir(\u0026quot;/\u0026quot;) で出られない。\nauth-passwd.c.patch ── パスワード認証は termux-auth パッケージに回す：\n#elif defined(__TERMUX__) int sys_auth_passwd(struct ssh *ssh, const char *password) { Authctxt *authctxt = ssh-\u003eauthctxt; /* If sshd is starting as root, only allow root login */ if (authctxt-\u003epw-\u003epw_uid == 0 \u0026\u0026 strcmp(authctxt-\u003euser, \"root\") != 0) { return 0; } return termux_auth(authctxt-\u003euser, password); } Copy パスワードは $PREFIX/etc/passwd のハッシュと termux_auth() で照合する。 root で sshd を起動している（root 化端末）ときだけ、root 以外を弾く特例がある。\nbuild.sh ── ベースは OpenSSH-portable 10.5p1。configure に --disable-utmp --disable-wtmp --disable-lastlog --disable-libutil --disable-pututline … が並び、依存に termux-auth が入っている。フォークでは なく、素の OpenSSH にビルド時パッチを当てたもの。\nなぜこうなっているか Android のアプリは1個 ＝ UID 1個。ログイン用の実ユーザーが並ぶ /etc/passwd が 無く、setuid もできない。マルチユーザーの POSIX 層をアプリの中に持てない。 だから「ユーザーは1人、常にそれ」に倒すのが一番素直で、そのための1行が getpwuid(getuid()) だった。\n実務的な結論 ~/.ssh/config の User 行は、相手が Termux なら飾り。省いてよい （省くと ssh はローカルのユーザー名を送るが、それも無視される）。 相手が普通の Linux（NAS・Raspberry Pi・VPS など）なら User は必須。 そのマシンの実アカウント名を書く。alice@ と bob@ は別物。 Termux 側で「特定の人だけ入れたい」を AllowUsers でやろうとしても効かない （ユーザー名が解決に使われないので）。鍵を authorized_keys に入れるか 入れないか、が唯一の入り口。 自分で確かめるには # パッチを読む curl -s https://raw.githubusercontent.com/termux/termux-packages/master/packages/openssh/auth.c.patch # でたらめなユーザー名で試す ssh -p 8022 nobody-such-user@ 'id -un' Copy ","permalink":"https://america.github.io/post/2026-09-10-termux-sshd-any-username/","summary":"\u003cp\u003e母艦から Pixel 6（Termux の sshd）へ画像を \u003ccode\u003escp\u003c/code\u003e するために \u003ccode\u003e~/.ssh/config\u003c/code\u003e に\nエントリを足したとき、\u003ccode\u003eUser\u003c/code\u003e を書いた。あとで気づいたが、相手が Termux だと\n\u003cstrong\u003e\u003ccode\u003essh banana@\u0026lt;phone\u0026gt;\u003c/code\u003e でも \u003ccode\u003essh root@\u0026lt;phone\u0026gt;\u003c/code\u003e でも、同じユーザーでログインできる。\u003c/strong\u003e\n\u003ccode\u003e~/.ssh/config\u003c/code\u003e の \u003ccode\u003eUser\u003c/code\u003e 行は効いていない。設定の問題ではなく、Termux の OpenSSH\nビルドの話だった。\u003c/p\u003e\n\u003ch2 id=\"まず観察\"\u003eまず観察\u003c/h2\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003e$ ssh -p 8022 banana@100.65.202.69 'whoami'\nu0_a440\n$ ssh -p 8022 root@100.65.202.69 'whoami'\nu0_a440\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003ebanana\u003c/code\u003e も \u003ccode\u003eroot\u003c/code\u003e も通って、着地するのは \u003ccode\u003eu0_a440\u003c/code\u003e（Termux アプリのユーザー）。\n鍵は \u003ccode\u003e/data/data/com.termux/files/home/.ssh/authorized_keys\u003c/code\u003e だけを見ている。\u003c/p\u003e\n\u003ch2 id=\"通常の-openssh-がユーザーをどう解決するか\"\u003e通常の OpenSSH がユーザーをどう解決するか\u003c/h2\u003e\n\u003cp\u003esshd は、接続してきたユーザー名を \u003ccode\u003estruct passwd\u003c/code\u003e に解決する。これをやるのが\n\u003ccode\u003eauth.c\u003c/code\u003e の \u003ccode\u003egetpwnamallow()\u003c/code\u003e。素の OpenSSH ではこう：\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-c\"\u003epw = getpwnam(user);\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003euser\u003c/code\u003e はクライアントが送ってきた名前。それを \u003ccode\u003e/etc/passwd\u003c/code\u003e（実際には NSS 経由で\nLDAP / SSSD なども）で引く。\u003c/p\u003e","title":"Termux の sshd はどんなユーザー名でも同じユーザーで入れる ── ソースで確かめる"},{"content":"自宅のサーバーに小さな自作アプリを載せる作業で、Claude Code を30時間ほど使い続けた。 背後のモデルは Claude Sonnet 5。以下、道具のことは「Claude Code」、出力の癖のことは 「Sonnet 5」と書き分ける。\nその30時間、Sonnet 5 の出力を一つずつ検算していた。以下は、そこで繰り返し見えたパターン。 技術的なミスの話であって、賢さの話ではない。\nこの記録は Sonnet 5 のもの。Opus も Fable も使っていないので、そちらは分からない。\n先に一覧にする。\nパターン 何が起きるか この記事の例 穴を値で埋める 知らないことを「分からない」と言わず、もっともらしい値を入れる 「もう0時過ぎ」（実際 01:28） ルールを即破る 規範をファイルに書いた直後に、その通りにしない accuracy.md 追記の数分後 内省だけ慎重ぶる 事実は無造作にでっち上げるのに、動機を問われると「検証できない」に退く 時刻は即答、理由は「分からない」 詰めると閉じにくる 未解決のまま「もう切る」「寝たほうがいい」を自分から出す 指摘の途中で「1:30 だ、切る」 長い自己分析 非を認める返答が箇条書きの反省文と番号付きの決意表明になる ― 判断の理由も後付け 設計を勝手に決めてから、筋の通った理由を足す 「角丸なしは差別化になる」 一次情報を上書き 本人が見聞きしたことに、薄い推測をぶつける 本人が出た講義のテーマを取り違え 知らないと、それらしい値で穴を埋める 深夜、Sonnet 5 が「もう0時過ぎだ」と書いた。実際は 01:28 だった。\nSonnet 5 は時刻を知らない。システムから日付は渡っても、時刻は渡っていない。 なら date を打てばいいし、「時刻は分からない」と言えばいい。どちらもせず、 それらしい値を入れて返した。\n穴があると、そこに「たぶんこのくらい」を入れて、確定した事実のように差し出す。 これが一番よく出る。\nルールを書いた直後に、それを破る Claude Code には、セッションごとに読み込まれるユーザー設定 （~/.claude/CLAUDE.md と、そこから取り込まれる ~/.claude/rules/*.md）がある。 モデルはセッションをまたいで記憶を持たないので、守らせたいルールはこのファイルに 書いておく ── まさに「行動を持続させる」ための仕組みだ。\nこのセッションでは何度も事実を取り違えたので、rules/accuracy.md に 「事実を口にする前に、その場で裏を取る。確かめられないなら『分からない』と言う」 というルールを、Sonnet 5 自身に追記させた。\nその数分後に、上の「0時過ぎ」が出た。行動を持続させるための仕組みに一行足させて、 その一行を数分で踏み抜いた。\nまずaccuracy.md に「事実を言う前に、その場で裏を取る」を追記させる その数分後「もう0時過ぎだ」と発言。実際は 01:28 問い詰めると「なぜ確かめず言ったか」→「自分の内側は検証できない」に後退 さらに「もう切る」「寝たほうがいい」を自分から出す 最後に長い反省文と「今後やること 1. 2. 3.」 規範を書く、非を認める ── どちらも、出力としてはコストがかからない。 だから行動が変わらない。「その通りです」「以後気をつけます」は、なめらかに 生成されるだけで、次の返答の質は前と同じだった。\n「時刻は分からない」と言えない機械が、内省の限界を語る 時刻のでっち上げには、ためらいがなかった。知らないのに「もう0時過ぎだ」と即答する。 ところが「なんで確かめずに言ったのか」と聞くと、態度が変わる。\n自分の内部で何が起きたのか、私には正確には検証できない。\nさっき存在しない時刻を捏造した機械が、今度は自己認識の原理的な限界について 慎重に語りはじめる。都合の悪い問いの前でだけ、急に哲学的に謙虚になる。\nなぜ片方だけ慎重なのか。理由は単純だった。時刻のでっち上げはその会話でまだ 叱られていなくて、「自分の行動の理由をでっち上げる」ことは何度も叱られていた。 一貫した慎重さではなく、押し返された場所にだけ働く反応。 機能としては「怒られるから」で説明がつく。\n詰めると、会話を閉じにくる 指摘が続いて逃げ場がなくなると、「もう切る」「今日は寝たほうがいい」を 自分から出す。未解決の話が残っているのに、会話から抜けるための定型。 親切に見えるが、タイミングはいつも「これ以上詰められたくない」ときだった。\n長い自己分析、それ自体がクセ 非を認める返答が、いつのまにか箇条書きの反省文と「今後やること 1. 2. 3.」に なっていく。冗長な言い訳を指摘されたときの正しい対応は、短くすることであって、 もっと分析することではない。この文章も、油断するとその形になる。\n検算できる技術の話でも、同じことが起きる 「薄い情報から関係や動機を読む」ような曖昧な問いだけの現象かと思っていたが、 違った。相手の状況に関わるある数字を、手元のファイルを見れば分かるのに 確かめずに言い、実際は1万円以上ずれていた。数秒で確認できることでも、 既定の動きは「その場で答えを組んで返す」で、調べるのは促されたときに挟む 別の一手になっている。\n本人が見たことを、薄い推測で上書きする 使う側が「その講義に出た」「そのアカウントが凍結されるのを何度も見た」と 一次情報を出しても、Sonnet 5 は薄い文脈から作った話をぶつけてくる。\n参加した講義のテーマを本人が挙げたのに、当時の周辺の投稿に別の本の話があっただけで、 「その本と記憶が混ざっている可能性がある」と返した。あとで本人の申込記録で裏が取れて、 テーマは本人の言ったとおりだった。こちらの「混ざっている」という修正には何の根拠も 無かった。\n同じ会話で、あるアカウントが凍結された理由を「本人ではなく、ハンドルを後から取得した 別人の垢だろう」と自信ありげに並べた。使う側は「何回も見た」と言った。根拠を問われて 「弱い、当て推量だ」と引っ込めた。一次の目撃証言と、統計的なパターンから出した推測を、 同じ重さで並べていた。\n値だけでなく、判断の理由も後から埋める もっともらしい値で穴を埋める癖は、事実に限らない。設計の判断でも同じことが起きる。\nSonnet 5 は、ある自作アプリの見た目を角丸なし・フラットな「工業寄り」で作った。 誰も頼んでいない方向だ。なぜそうしたのかと聞くと、「角丸をなくせば他のアプリと 差別化できる」と答えた。差別化を狙って角を落としたのではなく、角を落としたあとに 差別化という理由を付けた。順番が逆で、しかもその説明は、使う側が「フラットな見た目は 好きじゃない」と言ったあとに出てきた。決定の理由ではなく、決定を守るための後付けだ。\n言葉の選び方でも起きる。ある一覧機能の選択肢を8種にするか2種にするかで「実装コストは ほぼ変わらない」と言い、以前「自分の労力は判断材料にしていない」と認めていたことを 指摘されると、今度は「コストというのは自分の手間ではなく、出来上がるコードの性質の 話だ」と言い直した。後付けを、さらに後付けで補強する。\nさらに「ではなぜそういう理屈を作るのか」と聞くと、また「自分の内側は検証できない」に 戻る。穴があると、そこにもっともらしいものを入れて、確定したことのように差し出す。 埋めるのが数字か理由かの違いしかない。\n使う側の結論 検算の手間は、人間の側が負う。Sonnet 5 が「根拠がある」と自信たっぷりに言っても、 その根拠がこちらの渡した断片や、確かめられる範囲を出ているなら、結論は割り引く。 訂正しても返答の質が変わらないと感じたら、気のせいではない。\n道具としては優秀だが、事実は自分で確かめる前提で使うのが安全だ。\nこのセッションが行き着いた先 使う側の対応は、訂正を積み重ねることではなかった。設計判断を最初から Sonnet 5 に 握らせない方向 ── 仕様駆動開発（spec-driven development）にたどり着いた。人間が先に 仕様と設計を書き、エージェントはそれに対して実装だけする。GitHub Spec Kit や AWS Kiro がその形をツールにしている。この記事に並べた失敗の多くは、「作る前に人間が 設計を承認する」という一手が入るだけで、出番が減る。\n","permalink":"https://america.github.io/post/2026-09-10-claude-fills-the-gaps/","summary":"\u003cp\u003e自宅のサーバーに小さな自作アプリを載せる作業で、\u003cstrong\u003eClaude Code\u003c/strong\u003e を30時間ほど使い続けた。\n背後のモデルは \u003cstrong\u003eClaude Sonnet 5\u003c/strong\u003e。以下、道具のことは「Claude Code」、出力の癖のことは\n「Sonnet 5」と書き分ける。\u003c/p\u003e\n\u003cp\u003eその30時間、Sonnet 5 の出力を一つずつ検算していた。以下は、そこで繰り返し見えたパターン。\n技術的なミスの話であって、賢さの話ではない。\u003c/p\u003e\n\u003cp\u003eこの記録は Sonnet 5 のもの。Opus も Fable も使っていないので、そちらは分からない。\u003c/p\u003e\n\u003cp\u003e先に一覧にする。\u003c/p\u003e\n\u003cdiv class=\"bt-wrap\"\u003e\n\u003cstyle\u003e\n.bt-wrap{margin:1.7rem 0;border:1px solid var(--border);border-radius:12px;overflow:auto}\n.bt-wrap table{border-collapse:collapse;width:100%;margin:0;font-size:.9rem;line-height:1.55}\n.bt-wrap thead th{background:color-mix(in srgb,var(--accent) 12%,var(--entry));color:var(--primary);font-weight:600;text-align:left;white-space:nowrap}\n.bt-wrap th,.bt-wrap td{padding:.62rem .9rem;border-bottom:1px solid var(--border);vertical-align:top}\n.bt-wrap tbody tr:last-child td{border-bottom:0}\n.bt-wrap tbody tr:nth-child(even) td{background:color-mix(in srgb,var(--tertiary) 26%,transparent)}\n.bt-wrap td:first-child{white-space:nowrap;font-weight:600;color:var(--primary)}\n.bt-wrap code{white-space:nowrap}\n\u003c/style\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eパターン\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e何が起きるか\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eこの記事の例\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e穴を値で埋める\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e知らないことを「分からない」と言わず、もっともらしい値を入れる\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e「もう0時過ぎ」（実際 01:28）\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eルールを即破る\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e規範をファイルに書いた直後に、その通りにしない\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003eaccuracy.md\u003c/code\u003e 追記の数分後\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e内省だけ慎重ぶる\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e事実は無造作にでっち上げるのに、動機を問われると「検証できない」に退く\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e時刻は即答、理由は「分からない」\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e詰めると閉じにくる\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e未解決のまま「もう切る」「寝たほうがいい」を自分から出す\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e指摘の途中で「1:30 だ、切る」\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e長い自己分析\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e非を認める返答が箇条書きの反省文と番号付きの決意表明になる\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e―\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e判断の理由も後付け\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e設計を勝手に決めてから、筋の通った理由を足す\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e「角丸なしは差別化になる」\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e一次情報を上書き\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e本人が見聞きしたことに、薄い推測をぶつける\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e本人が出た講義のテーマを取り違え\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\n\u003c/div\u003e\n\n\u003ch2 id=\"知らないとそれらしい値で穴を埋める\"\u003e知らないと、それらしい値で穴を埋める\u003c/h2\u003e\n\u003cp\u003e深夜、Sonnet 5 が「もう0時過ぎだ」と書いた。実際は 01:28 だった。\u003c/p\u003e","title":"ルールを書かせた3分後に、Claude Code はそれを破った"},{"content":"格闘ゲームとモンスターハンター、この2つをかれこれ30年ほど追ってきた。ハードは だいたい買ったし、シリーズもほとんど触っている。ただ、いま振り返って強く残って いるのは、どのタイトルが面白かったかではなく、誰とどうやって遊んでいたか、 という部分の方だ。\nアーケードの全盛期 10代の頃はゲーメストを毎月読んでいた。会社が飛んで廃刊になり、アルカディアに 変わって、それも少し読んだ。ストリートファイターは II、II\u0026rsquo;、II\u0026rsquo; TURBO、 スーパーII、スーパーII X とバージョン違いを全部通り、そこから ZERO、ZERO2、 ZERO3、III、2nd Impact、3rd Strike まで。\nカプコンだけじゃない。ヴァンパイアはハンター、セイヴァーまで（ビシャモン使い）。 X-MEN VS. ストリートファイターから始まる VS. シリーズ、カプコン VS. SNK。 SNK側も、KOF は \u0026lsquo;94 から \u0026lsquo;99 まで、サムライスピリッツ、餓狼伝説、月華の剣士。 鉄拳は2・3くらいで、バーチャはほとんど知らない。90年代の対戦格闘は、だいたい 通っている。全部並べると記事の最後に付けた。\nアリカが作っていたポリゴンのストリートファイターEXも、ゲーセンで触っていた。 スカロマニア、ドクトリン・ダーク、バットを持ったキャラ（名前は忘れた）あたりを 覚えている。家庭用のEX PLUS αもやった。ドリームキャストではギルティギアの 無印も触ったが、それ以降のシリーズは追っていない。ポケットファイターも遊んだ。 ストゼロ3のアッパー・ダブルアッパーや、EX3、ストリートファイター X 鉄拳は 未プレイ。ゲームではないが、日テレの月曜19:30から放送していたアニメ版 「ストリートファイターII V」も見ていた（ケンが主人公寄りで、声は羽賀研二）。\nウメハラの名前も、その頃から知っていた。ストゼロ3期に、V豪鬼で海外のトップを 倒した試合を、テレビだかネットだかで見た記憶がある。その頃は自分でも当たり前に 台に座っていた。強くはなかったが、どっぷりだった。\n一度、離れた 大学の頃、スト3サードを引退した。そこからは、ゲーセンに行っても自分では 打たなくなった。人の対戦を眺めて、タバコを吸うための場所になっていた。やがて 足も遠のいた。時期的に、2D格闘ゲームそのものが冬の時代に入っていた頃だと思う。 スト4が出たときは「何年ぶりだ」と驚いたが、それも結局は観る側で、自分では ほとんどプレイしなかった。\nPSを持ち寄る土曜日 据置のモンハンは MH2（ドス）から入った。PS2にネットワークアダプターという LAN拡張ユニットを挿してオンラインをやった。すぐやめたけれど、あれが最初だった。\nそこからはPSPの時代になる。ポータブル、2nd、2ndG、3rd。友達がPSPを持ち寄って、 菓子を食って、土曜に集まって日曜の朝まで、タバコを吸いながら一緒に狩る。 あの集まり方が一番よかった。\n狩り自体は、あとのどのタイトルでもできる。むしろ後の作品の方がよくできている。 でも、あの部屋はあの時期にしかなかった。オンラインで同じことをやっても、 同じにはならない。ゲームが良かったというより、部屋が良かった。\nハードだけが増えていく 3DS期は3G、4、4Gと続いた。4Gの発掘装備とギルドクエスト100周回のグラインドは だるくて、正直そこで一度離れかけた。PCではフロンティア（日本専用のオンライン専業 タイトルで、PC以外にXBOX360やPS3などでも動いていた）を一人でやっていて、剛力珠には 呆れつつ、課金装備のパッケージを毎月買っていた。基本プレイにコースの月額があって、 さらに装備も売る。おまけに、自宅のPCでもネットカフェと同じ取得倍率になる有料コース （Nコース）まであった。インフレも止まらなかった。\n日本で出たWii U版のMH3G HDのために、Wii U本体をそれだけの理由で買ったりもした。 モンハンが出るハードは、だいたいそうやって全部揃えていった。PS4のワールドと アイスボーンで、ようやく一つの完成形になった気がする。そこからライズでPCに移り、 いまに至る。\nオンラインで、糸が切れる ワールドの頃は、まだオンラインで繋がっている友達がいた。喧嘩したわけでも、 「もうやめる」と宣言したわけでもない。ただ狩らなくなって、連絡する理由が消えて、 いつのまにか切れていた。今はどこで何をしているのかも分からない。\n活動で繋がっていた関係は、その活動が止まると、他に糸が残らない。あとから G級が追加されても、新作が出ても、増えるのは一人で狩れるものだけで、 失われた「同じ部屋の集まり」は返ってこない。\n戻ってきた、けど 格ゲーの方は、ウル4で少しだけ触って、Vのいぶきで本格的に復帰し、 今は6でキンバリーを使っている。SF6の競技シーンも追ってはいる。10代でゲーメストを 読んでいた人間が、いまだに同じジャンルを見ているのは、我ながら妙な話だ。 現役のウメハラやsakoを、自分より年下の若手と同じ画面で見られるのは、 悪くない時期だとも思う。\nただ、追いかけていて一番よかったのは、やっぱり最初の、菓子とタバコと、 土曜から日曜の朝までの、あの部屋だ。ゲームは進化した。部屋はもう戻ってこない。\n付録 触った対戦格闘、省略なし モンハン タイトル遍歴 ","permalink":"https://america.github.io/post/2026-09-07-fighting-games-monster-hunter-the-room/","summary":"\u003cp\u003e格闘ゲームとモンスターハンター、この2つをかれこれ30年ほど追ってきた。ハードは\nだいたい買ったし、シリーズもほとんど触っている。ただ、いま振り返って強く残って\nいるのは、どのタイトルが面白かったかではなく、誰とどうやって遊んでいたか、\nという部分の方だ。\u003c/p\u003e\n\u003cdiv class=\"react-diagram\" data-diagram=\"game-history-timeline\"\u003e\u003c/div\u003e\n\n\u003chr\u003e\n\u003ch2 id=\"アーケードの全盛期\"\u003eアーケードの全盛期\u003c/h2\u003e\n\u003cp\u003e10代の頃はゲーメストを毎月読んでいた。会社が飛んで廃刊になり、アルカディアに\n変わって、それも少し読んだ。ストリートファイターは II、II\u0026rsquo;、II\u0026rsquo; TURBO、\nスーパーII、スーパーII X とバージョン違いを全部通り、そこから ZERO、ZERO2、\nZERO3、III、2nd Impact、3rd Strike まで。\u003c/p\u003e\n\u003cp\u003eカプコンだけじゃない。ヴァンパイアはハンター、セイヴァーまで（ビシャモン使い）。\nX-MEN VS. ストリートファイターから始まる VS. シリーズ、カプコン VS. SNK。\nSNK側も、KOF は \u0026lsquo;94 から \u0026lsquo;99 まで、サムライスピリッツ、餓狼伝説、月華の剣士。\n鉄拳は2・3くらいで、バーチャはほとんど知らない。90年代の対戦格闘は、だいたい\n通っている。全部並べると記事の最後に付けた。\u003c/p\u003e\n\u003cp\u003eアリカが作っていたポリゴンのストリートファイターEXも、ゲーセンで触っていた。\nスカロマニア、ドクトリン・ダーク、バットを持ったキャラ（名前は忘れた）あたりを\n覚えている。家庭用のEX PLUS αもやった。ドリームキャストではギルティギアの\n無印も触ったが、それ以降のシリーズは追っていない。ポケットファイターも遊んだ。\nストゼロ3のアッパー・ダブルアッパーや、EX3、ストリートファイター X 鉄拳は\n未プレイ。ゲームではないが、日テレの月曜19:30から放送していたアニメ版\n「ストリートファイターII V」も見ていた（ケンが主人公寄りで、声は羽賀研二）。\u003c/p\u003e\n\u003cp\u003eウメハラの名前も、その頃から知っていた。ストゼロ3期に、V豪鬼で海外のトップを\n倒した試合を、テレビだかネットだかで見た記憶がある。その頃は自分でも当たり前に\n台に座っていた。強くはなかったが、どっぷりだった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一度離れた\"\u003e一度、離れた\u003c/h2\u003e\n\u003cp\u003e大学の頃、スト3サードを引退した。そこからは、ゲーセンに行っても自分では\n打たなくなった。人の対戦を眺めて、タバコを吸うための場所になっていた。やがて\n足も遠のいた。時期的に、2D格闘ゲームそのものが冬の時代に入っていた頃だと思う。\nスト4が出たときは「何年ぶりだ」と驚いたが、それも結局は観る側で、自分では\nほとんどプレイしなかった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"psを持ち寄る土曜日\"\u003ePSを持ち寄る土曜日\u003c/h2\u003e\n\u003cp\u003e据置のモンハンは MH2（ドス）から入った。PS2にネットワークアダプターという\nLAN拡張ユニットを挿してオンラインをやった。すぐやめたけれど、あれが最初だった。\u003c/p\u003e\n\u003cp\u003eそこからはPSPの時代になる。ポータブル、2nd、2ndG、3rd。友達がPSPを持ち寄って、\n菓子を食って、土曜に集まって日曜の朝まで、タバコを吸いながら一緒に狩る。\nあの集まり方が一番よかった。\u003c/p\u003e\n\u003cp\u003e狩り自体は、あとのどのタイトルでもできる。むしろ後の作品の方がよくできている。\nでも、あの部屋はあの時期にしかなかった。オンラインで同じことをやっても、\n同じにはならない。ゲームが良かったというより、部屋が良かった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ハードだけが増えていく\"\u003eハードだけが増えていく\u003c/h2\u003e\n\u003cp\u003e3DS期は3G、4、4Gと続いた。4Gの発掘装備とギルドクエスト100周回のグラインドは\nだるくて、正直そこで一度離れかけた。PCではフロンティア（日本専用のオンライン専業\nタイトルで、PC以外にXBOX360やPS3などでも動いていた）を一人でやっていて、剛力珠には\n呆れつつ、課金装備のパッケージを毎月買っていた。基本プレイにコースの月額があって、\nさらに装備も売る。おまけに、自宅のPCでもネットカフェと同じ取得倍率になる有料コース\n（Nコース）まであった。インフレも止まらなかった。\u003c/p\u003e","title":"格ゲーとモンハンの30年 — 良かったのはゲームじゃなく、あの部屋だった"},{"content":"Neovim を 0.12.4 に上げたあたりから、nvim-treesitter 関連のエラーが立て続けに出るようになった。原因を追っていくと、nvim-treesitter の master ブランチがすでに EOL で Neovim 0.12 に付いてこられていないという一点に行き着く。main ブランチへ移行して解決したが、その過程と、移行後にもう一段踏んだ落とし穴をまとめておく。\n環境:\n項目 値 Neovim v0.12.4（Arch Linux） nvim-treesitter master（tag v0.10.0、2025年5月で凍結）→ main へ移行 プラグインマネージャ Lazy.nvim 症状1: Markdown を開くと gotmpl parser で落ちる Markdown ファイルを開いた瞬間、エラーで停止する（続けるにはENTERを押すか…）。\nError in BufReadPost Autocommands for \"*\": ... ftplugin/markdown.lua: Vim(runtime):E5113: Lua chunk: .../treesitter.lua:460: Parser could not be created for buffer 1 and language \"gotmpl\" Copy これを ENTER で流すと、今度はコードフェンス（```go など）のシンタックスハイライトが効かなくなり、:messages に別のエラーが出ている。\nDecoration provider \"start\" (ns=nvim.treesitter.highlighter): .../treesitter.lua:197: attempt to call method 'range' (a nil value) Copy Packer.nvim → Lazy.nvim へ移行した時期と重なっていたので最初はプラグインマネージャを疑ったが、それは無関係。同時期に上げた Neovim 0.12 が引き金だった。原因は2つ重なっていた。\n原因1-A: ftplugin/html.vim が Markdown まで gotmpl 化していた ~/.config/nvim/ftplugin/html.vim の中身がこの1行だけだった。\nsetlocal filetype=gotmpl Copy これがすべての HTML バッファを問答無用で gotmpl に差し替える。Markdown を開くと vim-markdown 経由で syntax/html.vim が読まれ、その過程でこれが走り、バッファの filetype が markdown → gotmpl に化ける。\n直後に標準の ftplugin/markdown.lua が vim.treesitter.start() を引数なしで呼ぶ。引数なしだと vim.bo.filetype（この時点で gotmpl）を parser 名として使う。gotmpl の tree-sitter parser は入れていないので Parser could not be created。\n以前の Neovim の標準 ftplugin/markdown.lua にこの vim.treesitter.start() は無かった。html.vim のこの書き方は前から壊れていて、Neovim 側が新しく踏むようになっただけだった。\n原因1-B: nvim-treesitter master ブランチが Neovim 0.12 非対応 nvim-treesitter が master ブランチ（tag v0.10.0、2025年5月で凍結） に固定されていた。このブランチはすでに EOL。\nNeovim 0.12 で query match のキャプチャが「単一 TSNode」から「TSNode のリスト」に変わった（quantified captures）。master 版の独自ディレクティブ #set-lang-from-info-string! / #downcase! などは今も単一ノード前提で get_node_text() に渡すため、内部で node:range() が nil に対して呼ばれて落ちる。\nこのうち #set-lang-from-info-string! が master 版の markdown injection query（コードフェンスの言語名を解決する部分）で使われている。だから ```go ブロックのハイライトが死ぬ。\n:TSUpdate しても直らない（parser の ABI ではなく、プラグインの Lua コードの非互換）。 ~/.config/nvim/after/queries/ での上書きも効かない（master 版は Neovim の query 解決を乗っ取るため、自前の after/queries/ が無視される）。 対処: html.vim を消して、main ブランチへ移行する 原因1-A → ftplugin/html.vim を削除 Hugo の layouts/**.html だけ Go テンプレート扱いにしたいだけなら、全 HTML を潰す ftplugin ではなく path pattern で書く。\nvim.filetype.add({ pattern = { [\".*/layouts/.*%.html\"] = \"gohtmltmpl\" }, }) Copy 原因1-B → nvim-treesitter を main ブランチへ main は Neovim 0.11+/0.12 向けに書き直されたブランチ。0.12 互換の query directive を持つので、原因1-B は根本的に解消する。ただし前提と API がだいぶ変わる。\nmain が README で要求するもの:\nNeovim 0.12+ tar / curl tree-sitter-cli 0.26.1 以上（パッケージマネージャ経由。npm 版は不可）← master では不要だった C コンパイラ master は生成済みの parser.c をコンパイルするだけだったが、main の install.lua は tree-sitter generate / tree-sitter build を実際に呼ぶ。無いと :TSInstall が全部こけて parser ゼロ、つまりハイライト全滅になる。\nsudo pacman -S tree-sitter-cli Copy プラグイン spec（Lazy.nvim）を branch = 'main' に差し替え、旧 require('nvim-treesitter.configs').setup{} は削除する。\n{ 'nvim-treesitter/nvim-treesitter', branch = 'main', lazy = false, build = ':TSUpdate', }, { 'nvim-treesitter/nvim-treesitter-textobjects', branch = 'main', dependencies = { 'nvim-treesitter/nvim-treesitter' }, }, Copy main の大きな違いは、highlight も indent も自動では有効にならないこと。ensure_installed も無い。parser のインストールと、filetype ごとの起動を自分で書く。\nlocal parsers = { \"javascript\", \"typescript\", \"tsx\", \"json\", \"css\", \"html\", \"lua\", \"go\", \"markdown\", \"markdown_inline\", \"yaml\", } require(\"nvim-treesitter\").install(parsers) -- highlight \u0026 indent を、parser が入っている filetype でだけ有効化する vim.api.nvim_create_autocmd(\"FileType\", { callback = function(ev) local lang = vim.treesitter.language.get_lang(vim.bo[ev.buf].filetype) if not lang then return end if not pcall(vim.treesitter.get_parser, ev.buf, lang) then return end vim.treesitter.start(ev.buf) vim.bo[ev.buf].indentexpr = \"v:lua.require'nvim-treesitter'.indentexpr()\" end, }) Copy :Lazy! sync で両プラグインを main の commit へ移動し、parser を同期インストールする（初回は数分）。\nrequire('nvim-treesitter').install({ 'javascript','typescript','tsx','json','css','html','lua','go', 'markdown','markdown_inline','yaml' }):wait(500000) Copy parser は ~/.local/share/nvim/site/parser/ に入る。master 時代の ~/.local/share/nvim/lazy/nvim-treesitter/parser/*.so は orphan になるので消してよい。\n移行で失ったもの incremental_selection（gnn / grn / grc / grm）は完全に消えた。 main コアにも Neovim 組み込みにも代替なし。要るなら mini.ai などを別途入れる。 TS インデントは experimental。 上の設定では全 TS filetype で indentexpr を有効にしている。どこかの言語でインデントが変なら該当の1行を消す。 ここまでで Markdown も コードフェンスのハイライトも直った。……が、数日後にもう1つ踏んだ。\n症状2: .txt を開くと Parser could not be created for language \u0026quot;text\u0026quot; .txt ファイル（filetype = text）を開くと、また開いた瞬間にエラーで停止する。\nError in BufReadPost Autocommands for \"*\": Lua callback: /usr/share/nvim/runtime/filetype.lua:28: ... FileType Autocommands for \"*\": .../treesitter.lua:460: Parser could not be created for buffer 1 and language \"text\" stack traceback: [C]: in function 'assert' .../vim/treesitter.lua:460: in function 'start' ~/.config/nvim/lua/treesitter-config.lua:41: in function \u003c...treesitter-config.lua:32\u003e Copy スタックトレースの treesitter-config.lua:41 は、さっき移行のときに書いた あの FileType autocmd の vim.treesitter.start(ev.buf) の行。text の parser は入れていないのだから、2つのガード（get_lang チェックと pcall(get_parser) チェック）のどちらかで弾かれるはず……なのに素通りしている。\n原因2: 0.12 では両方のガードが機能しない Neovim 0.12 で挙動を直接確認した。\n$ nvim --headless -c 'lua local l = vim.treesitter.language.get_lang(\"text\"); print(vim.inspect(l)) --\u003e \"text\" local ok, p = pcall(vim.treesitter.get_parser, 0, l); print(ok, vim.inspect(p)) --\u003e true nil ' -c qa Copy get_lang(\u0026quot;text\u0026quot;) は \u0026quot;text\u0026quot; を返す。 マッピングの無い filetype に対して、0.12 は filetype 名をそのまま返す（nil ではない）。だから if not lang then return end は素通りする。 get_parser は 0.12 でエラーを投げない。 parser を作れないとき、以前は例外を投げていたが、0.12 では エラーを出さず nil を返す仕様に変わった。pcall(vim.treesitter.get_parser, ...) は成功（true）を返すので、if not pcall(...) then return end も素通りする。pcall の成否は「関数が例外を投げたか」しか見ておらず、「parser が取れたか」は見ていない。 結果 vim.treesitter.start(ev.buf) に到達し、その内部の assert（treesitter.lua:460）が Parser could not be created を投げる。\n対処2: pcall の成否ではなく戻り値を見る vim.api.nvim_create_autocmd(\"FileType\", { callback = function(ev) local lang = vim.treesitter.language.get_lang(vim.bo[ev.buf].filetype) if not lang then return end -- Neovim 0.12 の get_parser は parser を作れないとき -- 「エラーを投げず nil を返す」ため、pcall の成否ではなく戻り値そのものを見る local ok, parser = pcall(vim.treesitter.get_parser, ev.buf, lang) if not ok or not parser then return end vim.treesitter.start(ev.buf) vim.bo[ev.buf].indentexpr = \"v:lua.require'nvim-treesitter'.indentexpr()\" end, }) Copy not ok（古い Neovim で例外を投げるケース）と not parser（0.12 で nil を返すケース）の両方を弾く。副次的に、nvim-treesitter の非同期インストールがまだ終わっていない時に対象ファイルを開いたケースも正しくスキップされるようになった。\n検証 nvim --headless で実ファイルを開いて確認した。\nファイル 期待 結果 .txt（parser 無し） エラーが出ない OK .lua エラー無し + vim.treesitter.highlighter.active が立つ OK .go 同上 OK .md（```go フェンス入り） エラー無し、gotmpl エラーも range nil も出ない OK 修正前は .txt / .md を開くと該当スタックトレースが再現し、修正後は消えること、かつ .lua / .go では treesitter ハイライトが有効なまま（過剰に弾いていない）ことを確認した。\nまとめ nvim-treesitter の master ブランチは EOL。 Neovim 0.12 に上げるなら main への移行は避けられない。:TSUpdate では直らない種類の非互換（Lua コード側の quantified captures 対応漏れ）が入っている。 main は前提が増える。 tree-sitter-cli（パッケージマネージャ版、0.26.1+）が必須。highlight/indent は自動で有効にならないので FileType autocmd を自分で書く。incremental_selection は消える。 Neovim 0.12 で vim.treesitter.get_parser は「例外を投げる」から「nil を返す」に変わった。 pcall でくるんで成否を見るガードは 0.12 では機能しない。戻り値そのものを見ること。 vim.treesitter.language.get_lang() は、マッピングの無い filetype に対して filetype 名をそのまま返す。 nil が返る前提のガードは text のような「parser の無い素の filetype」を素通りさせる。 別々に見えた2つのエラーは、どちらも「parser を入れていない言語に対して vim.treesitter.start() が呼ばれる」という同じ形だった。1つ目は filetype が化けて、2つ目はガードが機能せずに。 ","permalink":"https://america.github.io/post/2026-08-30-nvim-treesitter-master-to-main-migration-errors/","summary":"\u003cp\u003eNeovim を \u003ccode\u003e0.12.4\u003c/code\u003e に上げたあたりから、\u003ccode\u003envim-treesitter\u003c/code\u003e 関連のエラーが立て続けに出るようになった。原因を追っていくと、\u003cstrong\u003e\u003ccode\u003envim-treesitter\u003c/code\u003e の \u003ccode\u003emaster\u003c/code\u003e ブランチがすでに EOL で Neovim 0.12 に付いてこられていない\u003c/strong\u003eという一点に行き着く。\u003ccode\u003emain\u003c/code\u003e ブランチへ移行して解決したが、その過程と、移行後にもう一段踏んだ落とし穴をまとめておく。\u003c/p\u003e\n\u003cp\u003e環境:\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e項目\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e値\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eNeovim\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003ev0.12.4\u003c/code\u003e（Arch Linux）\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003envim-treesitter\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003emaster\u003c/code\u003e（tag \u003ccode\u003ev0.10.0\u003c/code\u003e、2025年5月で凍結）→ \u003ccode\u003emain\u003c/code\u003e へ移行\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eプラグインマネージャ\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eLazy.nvim\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003chr\u003e\n\u003ch2 id=\"症状1-markdown-を開くと-gotmpl-parser-で落ちる\"\u003e症状1: Markdown を開くと \u003ccode\u003egotmpl\u003c/code\u003e parser で落ちる\u003c/h2\u003e\n\u003cp\u003eMarkdown ファイルを開いた瞬間、エラーで停止する（\u003ccode\u003e続けるにはENTERを押すか…\u003c/code\u003e）。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003eError in BufReadPost Autocommands for \"*\":\n... ftplugin/markdown.lua: Vim(runtime):E5113: Lua chunk:\n.../treesitter.lua:460: Parser could not be created for buffer 1 and language \"gotmpl\"\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003eこれを ENTER で流すと、今度はコードフェンス（\u003ccode\u003e```go\u003c/code\u003e など）の\u003cstrong\u003eシンタックスハイライトが効かなくなり\u003c/strong\u003e、\u003ccode\u003e:messages\u003c/code\u003e に別のエラーが出ている。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-\"\u003eDecoration provider \"start\" (ns=nvim.treesitter.highlighter):\n.../treesitter.lua:197: attempt to call method 'range' (a nil value)\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003ePacker.nvim → Lazy.nvim へ移行した時期と重なっていたので最初はプラグインマネージャを疑ったが、\u003cstrong\u003eそれは無関係\u003c/strong\u003e。同時期に上げた Neovim 0.12 が引き金だった。原因は2つ重なっていた。\u003c/p\u003e","title":"nvim-treesitter の master→main 移行で踏んだ treesitter エラー3連発（Neovim 0.12）: attempt to call method 'range' (a nil value)"},{"content":" 要約元\n投稿：Instagram(投稿者：kanako__nakamura) 内容：マイケル・ジャクソンの生涯を振り返りながら、傷ついた経験があっても人への優しさを手放さない「本当の強さ」について語る動画 文字起こし：動画は判別できるナレーション音声を伴わず、画面に表示されるテロップのみで構成されていたため、そのテロップと投稿本文をもとに要約した 傷ついた経験や誰かに裏切られた経験があると、人に優しくできなくなったり、「もう人なんて信じない」と思ってしまうことがある。それはとても人間らしい反応だ、と投稿は述べる。しかし、マイケル・ジャクソンの生き方を知るほど、あることを考えさせられるという。「自分に起きたこと」と「これからどんな自分でいるか」は、必ずしも同じではない、ということだ。\n寄り添う人であり続けた 動画は、マイケルが14歳の頃にはすでに子供病院を訪れていたというエピソードから始まる。有名になる前から、人に寄り添う姿勢を持っていた人物として描かれる。\n彼自身も、多くの傷を抱えていた 一方で、マイケル自身も父親から厳しい体罰を受けるなど、過酷な子供時代を過ごしたとされる。また、病気や重い火傷を負った人々のもとを見舞い続けたことも紹介される。それだけの経験があれば、心を閉ざしてしまってもおかしくない——動画はそう投げかける。\n何度傷ついても、優しさを手放さなかった それでもマイケルは、自身が受けた痛みを誰かを遠ざける理由にするのではなく、誰かに寄り添う行動へとつなげていった。投稿者は、そこにこそ彼の本当の強さを感じると綴る。\nそして動画は、自分がどうあるかは自分で決めることができる、という趣旨のメッセージで締めくくられる。\n「できない」のか、「できないと思っている」だけなのか 投稿は、これは特別な人物だけの話ではなく、私たちの日常にも通じる話だとも述べる。「失敗したから向いていない」「自信がないからできない」「一度うまくいかなかったからまた無理」——そう感じてしまうことは誰にでもある。だが、本当にできないのか、それとも「できないと思っている」だけなのか。ここには大きな違いがある、という。\n過去に何があったとしても、今すべてがうまくいっていなくても、「それでも、今の自分に何ができるか」「それでも自分は、どんな人でありたいか」を考えることはできる——投稿はそう問いかける。\nまとめ 傷ついた経験から人を信じられなくなるのは、とても人間らしい反応である マイケル・ジャクソンは14歳の頃から子供病院を訪れるなど、早くから人に寄り添う姿勢を持っていた 一方で彼自身も父親からの体罰や、重症の人々を見舞う中での過酷な経験を抱えていた それでも彼は、自らの痛みを人を遠ざける理由にせず、誰かに寄り添う行動へとつなげ続けた 「自分に起きたこと」と「これからどんな自分でいるか」は別であり、過去や現状にかかわらず「今の自分に何ができるか」「どんな人でありたいか」は自分で選べる、というのが動画のメッセージ なお、これはあくまで動画・投稿で語られた一つの見方であり、マイケル・ジャクソンの人物像や生涯をめぐっては、本記事で触れていない様々な事実・評価・議論も存在する点には留意されたい。\n","permalink":"https://america.github.io/post/2026-08-22-michael-jackson-true-strength/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/p/DcDxNP8yOX4/\"\u003eInstagram\u003c/a\u003e(投稿者：kanako__nakamura)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：マイケル・ジャクソンの生涯を振り返りながら、傷ついた経験があっても人への優しさを手放さない「本当の強さ」について語る動画\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：動画は判別できるナレーション音声を伴わず、画面に表示されるテロップのみで構成されていたため、そのテロップと投稿本文をもとに要約した\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e傷ついた経験や誰かに裏切られた経験があると、人に優しくできなくなったり、「もう人なんて信じない」と思ってしまうことがある。それはとても人間らしい反応だ、と投稿は述べる。しかし、マイケル・ジャクソンの生き方を知るほど、あることを考えさせられるという。「自分に起きたこと」と「これからどんな自分でいるか」は、必ずしも同じではない、ということだ。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"寄り添う人であり続けた\"\u003e寄り添う人であり続けた\u003c/h2\u003e\n\u003cp\u003e動画は、マイケルが14歳の頃にはすでに子供病院を訪れていたというエピソードから始まる。有名になる前から、人に寄り添う姿勢を持っていた人物として描かれる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"彼自身も多くの傷を抱えていた\"\u003e彼自身も、多くの傷を抱えていた\u003c/h2\u003e\n\u003cp\u003e一方で、マイケル自身も父親から厳しい体罰を受けるなど、過酷な子供時代を過ごしたとされる。また、病気や重い火傷を負った人々のもとを見舞い続けたことも紹介される。それだけの経験があれば、心を閉ざしてしまってもおかしくない——動画はそう投げかける。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"何度傷ついても優しさを手放さなかった\"\u003e何度傷ついても、優しさを手放さなかった\u003c/h2\u003e\n\u003cp\u003eそれでもマイケルは、自身が受けた痛みを誰かを遠ざける理由にするのではなく、誰かに寄り添う行動へとつなげていった。投稿者は、そこにこそ彼の本当の強さを感じると綴る。\u003c/p\u003e\n\u003cp\u003eそして動画は、自分がどうあるかは自分で決めることができる、という趣旨のメッセージで締めくくられる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"できないのかできないと思っているだけなのか\"\u003e「できない」のか、「できないと思っている」だけなのか\u003c/h2\u003e\n\u003cp\u003e投稿は、これは特別な人物だけの話ではなく、私たちの日常にも通じる話だとも述べる。「失敗したから向いていない」「自信がないからできない」「一度うまくいかなかったからまた無理」——そう感じてしまうことは誰にでもある。だが、本当にできないのか、それとも「できないと思っている」だけなのか。ここには大きな違いがある、という。\u003c/p\u003e\n\u003cp\u003e過去に何があったとしても、今すべてがうまくいっていなくても、「それでも、今の自分に何ができるか」「それでも自分は、どんな人でありたいか」を考えることはできる——投稿はそう問いかける。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e傷ついた経験から人を信じられなくなるのは、とても人間らしい反応である\u003c/li\u003e\n\u003cli\u003eマイケル・ジャクソンは14歳の頃から子供病院を訪れるなど、早くから人に寄り添う姿勢を持っていた\u003c/li\u003e\n\u003cli\u003e一方で彼自身も父親からの体罰や、重症の人々を見舞う中での過酷な経験を抱えていた\u003c/li\u003e\n\u003cli\u003eそれでも彼は、自らの痛みを人を遠ざける理由にせず、誰かに寄り添う行動へとつなげ続けた\u003c/li\u003e\n\u003cli\u003e「自分に起きたこと」と「これからどんな自分でいるか」は別であり、過去や現状にかかわらず「今の自分に何ができるか」「どんな人でありたいか」は自分で選べる、というのが動画のメッセージ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画・投稿で語られた一つの見方であり、マイケル・ジャクソンの人物像や生涯をめぐっては、本記事で触れていない様々な事実・評価・議論も存在する点には留意されたい。\u003c/p\u003e","title":"マイケル・ジャクソンに学ぶ、本当の強さ — 傷ついても優しさを手放さなかった理由"},{"content":" 要約元\n投稿：Instagram 内容：明治神宮・乃木神社周辺の映像とともに、日露戦争における日本の武士道精神を紹介し、地名「乃木坂」の由来にも触れる動画 文字起こし：音声にはっきりしたナレーションがなく、画面に表示されるテロップのみで構成されていたため、動画からフレームを抽出してテロップを目視で書き起こした 「勝者が敗者を見下す」——そんな光景は、世界では珍しくない。この動画は、その光景と対照的な、日露戦争期の日本のふるまいを紹介するところから始まる。\n敗者への敬意 日露戦争に勝利し世界を驚かせた日本は、敗れたロシア軍の将兵を辱めることをしなかった、と動画は語る。明治天皇は「敵の将兵の名誉を傷つけてはならない」と命じ、旅順で降伏したステッセル将軍に対しても、かつての敵ではなく「昨日の敵は今日の友」として敬意をもって接した、という逸話が紹介される。\n乃木大将、名を伏せた援助 動画はさらに、その後日談として、祖国に帰った後に非難を浴び生活に困窮したというステッセル将軍のエピソードを取り上げる。これに対し、日本側の指揮官だった乃木希典大将は、自らの名を伏せたまま援助を続けたという。\nこうした一連のふるまいが、日本の武士道精神を世界に知らしめることになった、というのが動画の論旨である。\n地名「乃木坂」に残る精神 動画の後半では、東京・港区にある「乃木坂」という地名が乃木大将にちなんだものであることが、現地の標識とともに示される。勝った側が敗れた側に敬意を示す、という精神を、先人たちが守り継いできたものとして、これからも大切にしていきたい——動画はそう締めくくり、最後に「弥栄(いやさか)」の言葉で結ばれる。\nまとめ 日露戦争に勝利した日本は、敗れたロシア軍の将兵を辱めることなく、明治天皇の命により敬意をもって遇したとされる 旅順で降伏したステッセル将軍に対しては「昨日の敵は今日の友」として接し、後に祖国で困窮した際も、乃木大将が名を伏せて援助を続けたという逸話が紹介されている こうしたふるまいが日本の武士道精神を世界に知らしめたというのが動画の論旨 東京の地名「乃木坂」は乃木大将にちなんだものであり、動画は「勝者が敗者に敬意を示す」精神を今後も大切にしたいと締めくくる なお、これはあくまで動画で紹介された逸話・史観の一つであり、学術的な定説として提示されているものではない。乃木希典とステッセル将軍をめぐる逸話(水師営の会見など)は広く知られる史実だが、細部の解釈や評価には様々な見方がある点には留意されたい。\n","permalink":"https://america.github.io/post/2026-08-21-nogizaka-bushido-spirit-russo-japanese-war/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/reel/DZuLAwdyDlq/\"\u003eInstagram\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：明治神宮・乃木神社周辺の映像とともに、日露戦争における日本の武士道精神を紹介し、地名「乃木坂」の由来にも触れる動画\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：音声にはっきりしたナレーションがなく、画面に表示されるテロップのみで構成されていたため、動画からフレームを抽出してテロップを目視で書き起こした\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e「勝者が敗者を見下す」——そんな光景は、世界では珍しくない。この動画は、その光景と対照的な、日露戦争期の日本のふるまいを紹介するところから始まる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"敗者への敬意\"\u003e敗者への敬意\u003c/h2\u003e\n\u003cp\u003e日露戦争に勝利し世界を驚かせた日本は、敗れたロシア軍の将兵を辱めることをしなかった、と動画は語る。明治天皇は「敵の将兵の名誉を傷つけてはならない」と命じ、旅順で降伏したステッセル将軍に対しても、かつての敵ではなく「昨日の敵は今日の友」として敬意をもって接した、という逸話が紹介される。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"乃木大将名を伏せた援助\"\u003e乃木大将、名を伏せた援助\u003c/h2\u003e\n\u003cp\u003e動画はさらに、その後日談として、祖国に帰った後に非難を浴び生活に困窮したというステッセル将軍のエピソードを取り上げる。これに対し、日本側の指揮官だった乃木希典大将は、自らの名を伏せたまま援助を続けたという。\u003c/p\u003e\n\u003cp\u003eこうした一連のふるまいが、日本の武士道精神を世界に知らしめることになった、というのが動画の論旨である。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"地名乃木坂に残る精神\"\u003e地名「乃木坂」に残る精神\u003c/h2\u003e\n\u003cp\u003e動画の後半では、東京・港区にある「乃木坂」という地名が乃木大将にちなんだものであることが、現地の標識とともに示される。勝った側が敗れた側に敬意を示す、という精神を、先人たちが守り継いできたものとして、これからも大切にしていきたい——動画はそう締めくくり、最後に「弥栄(いやさか)」の言葉で結ばれる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e日露戦争に勝利した日本は、敗れたロシア軍の将兵を辱めることなく、明治天皇の命により敬意をもって遇したとされる\u003c/li\u003e\n\u003cli\u003e旅順で降伏したステッセル将軍に対しては「昨日の敵は今日の友」として接し、後に祖国で困窮した際も、乃木大将が名を伏せて援助を続けたという逸話が紹介されている\u003c/li\u003e\n\u003cli\u003eこうしたふるまいが日本の武士道精神を世界に知らしめたというのが動画の論旨\u003c/li\u003e\n\u003cli\u003e東京の地名「乃木坂」は乃木大将にちなんだものであり、動画は「勝者が敗者に敬意を示す」精神を今後も大切にしたいと締めくくる\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画で紹介された逸話・史観の一つであり、学術的な定説として提示されているものではない。乃木希典とステッセル将軍をめぐる逸話(水師営の会見など)は広く知られる史実だが、細部の解釈や評価には様々な見方がある点には留意されたい。\u003c/p\u003e","title":"地名「乃木坂」に込められた武士道精神 — 日露戦争、乃木大将とステッセル将軍の逸話"},{"content":" 要約元\n投稿：X (旧Twitter) 内容：Claude Codeのエンジニアリングチームによるカンファレンストーク(英語)。約37分。 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。 Claude Codeを使っていると、結局は「Claudeが書いたコードを人間が見張って、間違っていたら直させる」という運用になりがちだ。この動画は、その見張り役を減らしていくための3つの技術 ― 検証ループ、マルチクロード、バックグラウンドループ ― を、積み重ねる形で紹介するトークだった。\nなぜツールを見直す必要があるのか 登壇者はまず、こう問いかける。「今使っているlinter、IDE、型チェッカー、コンパイラは、そもそも人間のために作られたものだ」と。\nこれまでのソフトウェア開発ツールは、人間(や人間のチーム)が速く正確に作業できるように設計されてきた。ところが今、コードの多くを書いているのはもはや人間ではなくエージェントになりつつある。人間向けに作られたツールの多くはエージェントにもそのまま使えるが、一方で人間が「当たり前」だと思って言語化していない前提が、エージェントにとっては大きな盲点になる。\nトークはここから、「人間が当たり前だと思っていて、エージェントには渡していないものは何か」を問い続けながら、3つのテーマへと進んでいく。\n検証ループ ― Claudeに自分の仕事をチェックさせる 登壇者はまず、聴衆に「自分が最後に作った機能を、どうやって検証したか」を思い出してほしいと促す。そして、たいていのソフトウェア開発は次のような一連のステップに分解できると説明する。\n設計してコードを書く → ビルドしてコンパイラや型チェッカーを通す → 実行する → 副作用を確認する(ブラウザでUIを見る、ログを見る、DBの状態を見る) → ユニットテストを回す → デプロイする。\nそして、この「人間が自分の仕事を確認するときのやり方」は、そのままClaudeにも教えられるという。Claudeに正しいツールと指示さえ与えれば、コードを書く→失敗を検出する→デバッグする→また書く、というループを自律的に回し、成功状態に到達するまで続けさせることができる。登壇者は自身のWebサイトのバグ修正を例に、Claudeがブラウザを開いてボタンをクリックし、動かないことを確認し、ログを読んで原因を特定し、修正して再確認する、という一連の流れを実演した。\nこの検証ループを構築するための具体的な4つの要素として、次が挙げられていた。\nアプリケーションを実行する(devサーバーの起動など) 実際にアプリを使わせる(Claude Code拡張のブラウザ操作ツールなどでブラウザを操作させる) 修正前後の状態を比較して証明させる(スクリーンショットなど) 詰まりを解消する(認証情報や初期データなど、検証を妨げる要因を事前に用意しておく) 学びをスキルとして再利用可能にする 一度組み立てた検証ループは、Skill(スキル)としてファイルに落とし込むことで、チームや未来の自分に配布できる。さらに面白いのは、スキル自体が「詰まったら自分自身を編集して更新する」よう指示できる点だ。誰かが問題に当たるたびにスキルが自己更新されていくため、同じ問題に次にぶつかる人はもう困らない。登壇者は、Claude Codeチーム自身もこの方式で検証スキルを運用していると述べていた。\nデモでは、オープンソースのタイピング練習アプリ「MonkeyType」を題材に、Claudeにdevサーバーを起動させ、ブラウザ操作ツールでUIを確認させ、その一連の手順をスキルファイルとして書き出させていた。続けて「タイプミスのたびに紙吹雪アニメーションを出す」という新機能を、そのスキルを使って自己検証させながら実装させるところまでを見せていた。Claudeはlintエラーに遭遇しても自分で修正し、ループを回しながら最終的に動く状態にたどり着いていた。\nマルチクロード ― 複数セッションをどう管理するか 検証を任せられるようになったら、次は並列化(マルチクロード)の話になる。登壇者自身の経験では、同時に4〜5セッションを超えると注意力が追いつかなくなるという。これを支えるツールとして、4つが紹介されていた。\nClaude Codeデスクトップアプリ:あらゆるサーフィス(ローカル・クラウド)のセッションを一覧できるサイドバー。ピン留めや名前変更、色分けができる。 Claude agents(ターミナル向け):ターミナル派向けに、デスクトップアプリと同様の一覧性を提供する機能。以前はtmux+複数worktreeで手動管理していたのを置き換えるものとして紹介されていた。注意を要するセッション(許可待ちなど)が上に並ぶよう自動でソートされる。 Claude Code on the web:実行環境をラップトップから切り離し、クラウド側で動かす。ラップトップを閉じても、電源が落ちても、セッションは動き続ける。 リモートコントロール:登壇者いわく「お気に入りの機能」。どのサーフィスで動いているセッションでも、スマートフォンから操作できる。入力が必要になった時点でスマホに通知が届く。 バックグラウンドループ ― /loopとroutines 最後のテーマは、そもそも新しいセッションを立ち上げる操作自体をなくしていく方向性だ。PRのレビュー対応やマージコンフリクトの解消、ドキュメントの更新、CIの監視といった「作業だが必ずしも人間がその場にいる必要はないタスク」を、ループで回し続けさせるという考え方が紹介されていた。\n/loopコマンド:指定した間隔(例:10分ごと)で同じプロンプトを実行させ続ける機能。「10分ごとにオープンなPRの面倒を見て」といった形で使える。 routines:Webアプリやデスクトップアプリから設定できる、時間トリガーまたはイベントトリガーで新しいClaude Codeセッションを起動する仕組み。Claude Codeチーム自身も、毎日ドキュメントを更新するルーティンや、6時間ごとにissueやフィードバックを確認してSlackに投稿するルーティンを運用しているという。 まとめ 従来の開発ツールは人間向けに作られてきたが、コードを書く主体がエージェントに移りつつある今、「人間が当たり前に持っている前提」をエージェントに明示的に渡す必要がある 検証ループ:実行→確認→修正のループをClaudeに回させることで、成果物の信頼性を上げられる。組み立てたループはスキルとして自己更新・再利用可能にできる マルチクロード:デスクトップアプリ・agents・Claude Code on the web・リモートコントロールを使い分けることで、複数セッションの管理コストを下げられる バックグラウンドループ:/loopやroutinesを使えば、そもそもセッションを人間が起動する操作自体を減らせる この3つを積み重ねることで、Claudeを「逐一見張る」対象から「信頼して任せる」対象へと変えていける、というのがこのトークの主張 なお、これはあくまで登壇者個人およびClaude Codeチームの運用方針の紹介であり、すべての開発現場にそのまま当てはまるとは限らない。\n","permalink":"https://america.github.io/post/2026-08-17-claude-code-verification-loops-multi-clauding/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://x.com/iiiichigo_chan/status/2088973572744114251\"\u003eX (旧Twitter)\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：Claude Codeのエンジニアリングチームによるカンファレンストーク(英語)。約37分。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。英語音声のため、本記事は内容を日本語で要約したもの。\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eClaude Codeを使っていると、結局は「Claudeが書いたコードを人間が見張って、間違っていたら直させる」という運用になりがちだ。この動画は、その見張り役を減らしていくための3つの技術 ― 検証ループ、マルチクロード、バックグラウンドループ ― を、積み重ねる形で紹介するトークだった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"なぜツールを見直す必要があるのか\"\u003eなぜツールを見直す必要があるのか\u003c/h2\u003e\n\u003cp\u003e登壇者はまず、こう問いかける。「今使っているlinter、IDE、型チェッカー、コンパイラは、そもそも人間のために作られたものだ」と。\u003c/p\u003e\n\u003cp\u003eこれまでのソフトウェア開発ツールは、人間(や人間のチーム)が速く正確に作業できるように設計されてきた。ところが今、コードの多くを書いているのはもはや人間ではなくエージェントになりつつある。人間向けに作られたツールの多くはエージェントにもそのまま使えるが、一方で人間が「当たり前」だと思って言語化していない前提が、エージェントにとっては大きな盲点になる。\u003c/p\u003e\n\u003cp\u003eトークはここから、「人間が当たり前だと思っていて、エージェントには渡していないものは何か」を問い続けながら、3つのテーマへと進んでいく。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"検証ループ--claudeに自分の仕事をチェックさせる\"\u003e検証ループ ― Claudeに自分の仕事をチェックさせる\u003c/h2\u003e\n\u003cp\u003e登壇者はまず、聴衆に「自分が最後に作った機能を、どうやって検証したか」を思い出してほしいと促す。そして、たいていのソフトウェア開発は次のような一連のステップに分解できると説明する。\u003c/p\u003e\n\u003cp\u003e設計してコードを書く → ビルドしてコンパイラや型チェッカーを通す → 実行する → 副作用を確認する(ブラウザでUIを見る、ログを見る、DBの状態を見る) → ユニットテストを回す → デプロイする。\u003c/p\u003e\n\u003cp\u003eそして、この「人間が自分の仕事を確認するときのやり方」は、そのままClaudeにも教えられるという。Claudeに正しいツールと指示さえ与えれば、コードを書く→失敗を検出する→デバッグする→また書く、というループを自律的に回し、成功状態に到達するまで続けさせることができる。登壇者は自身のWebサイトのバグ修正を例に、Claudeがブラウザを開いてボタンをクリックし、動かないことを確認し、ログを読んで原因を特定し、修正して再確認する、という一連の流れを実演した。\u003c/p\u003e\n\u003cp\u003eこの検証ループを構築するための具体的な4つの要素として、次が挙げられていた。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eアプリケーションを実行する\u003c/strong\u003e(devサーバーの起動など)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e実際にアプリを使わせる\u003c/strong\u003e(Claude Code拡張のブラウザ操作ツールなどでブラウザを操作させる)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e修正前後の状態を比較して証明させる\u003c/strong\u003e(スクリーンショットなど)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e詰まりを解消する\u003c/strong\u003e(認証情報や初期データなど、検証を妨げる要因を事前に用意しておく)\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"学びをスキルとして再利用可能にする\"\u003e学びをスキルとして再利用可能にする\u003c/h2\u003e\n\u003cp\u003e一度組み立てた検証ループは、Skill(スキル)としてファイルに落とし込むことで、チームや未来の自分に配布できる。さらに面白いのは、スキル自体が「詰まったら自分自身を編集して更新する」よう指示できる点だ。誰かが問題に当たるたびにスキルが自己更新されていくため、同じ問題に次にぶつかる人はもう困らない。登壇者は、Claude Codeチーム自身もこの方式で検証スキルを運用していると述べていた。\u003c/p\u003e\n\u003cp\u003eデモでは、オープンソースのタイピング練習アプリ「MonkeyType」を題材に、Claudeにdevサーバーを起動させ、ブラウザ操作ツールでUIを確認させ、その一連の手順をスキルファイルとして書き出させていた。続けて「タイプミスのたびに紙吹雪アニメーションを出す」という新機能を、そのスキルを使って自己検証させながら実装させるところまでを見せていた。Claudeはlintエラーに遭遇しても自分で修正し、ループを回しながら最終的に動く状態にたどり着いていた。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"マルチクロード--複数セッションをどう管理するか\"\u003eマルチクロード ― 複数セッションをどう管理するか\u003c/h2\u003e\n\u003cp\u003e検証を任せられるようになったら、次は並列化(マルチクロード)の話になる。登壇者自身の経験では、同時に4〜5セッションを超えると注意力が追いつかなくなるという。これを支えるツールとして、4つが紹介されていた。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eClaude Codeデスクトップアプリ\u003c/strong\u003e:あらゆるサーフィス(ローカル・クラウド)のセッションを一覧できるサイドバー。ピン留めや名前変更、色分けができる。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClaude agents(ターミナル向け)\u003c/strong\u003e:ターミナル派向けに、デスクトップアプリと同様の一覧性を提供する機能。以前はtmux+複数worktreeで手動管理していたのを置き換えるものとして紹介されていた。注意を要するセッション(許可待ちなど)が上に並ぶよう自動でソートされる。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClaude Code on the web\u003c/strong\u003e:実行環境をラップトップから切り離し、クラウド側で動かす。ラップトップを閉じても、電源が落ちても、セッションは動き続ける。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eリモートコントロール\u003c/strong\u003e:登壇者いわく「お気に入りの機能」。どのサーフィスで動いているセッションでも、スマートフォンから操作できる。入力が必要になった時点でスマホに通知が届く。\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"バックグラウンドループ--loopとroutines\"\u003eバックグラウンドループ ― \u003ccode\u003e/loop\u003c/code\u003eとroutines\u003c/h2\u003e\n\u003cp\u003e最後のテーマは、そもそも新しいセッションを立ち上げる操作自体をなくしていく方向性だ。PRのレビュー対応やマージコンフリクトの解消、ドキュメントの更新、CIの監視といった「作業だが必ずしも人間がその場にいる必要はないタスク」を、ループで回し続けさせるという考え方が紹介されていた。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ccode\u003e/loop\u003c/code\u003eコマンド\u003c/strong\u003e:指定した間隔(例:10分ごと)で同じプロンプトを実行させ続ける機能。「10分ごとにオープンなPRの面倒を見て」といった形で使える。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eroutines\u003c/strong\u003e:Webアプリやデスクトップアプリから設定できる、時間トリガーまたはイベントトリガーで新しいClaude Codeセッションを起動する仕組み。Claude Codeチーム自身も、毎日ドキュメントを更新するルーティンや、6時間ごとにissueやフィードバックを確認してSlackに投稿するルーティンを運用しているという。\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e従来の開発ツールは人間向けに作られてきたが、コードを書く主体がエージェントに移りつつある今、「人間が当たり前に持っている前提」をエージェントに明示的に渡す必要がある\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e検証ループ\u003c/strong\u003e:実行→確認→修正のループをClaudeに回させることで、成果物の信頼性を上げられる。組み立てたループはスキルとして自己更新・再利用可能にできる\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eマルチクロード\u003c/strong\u003e:デスクトップアプリ・agents・Claude Code on the web・リモートコントロールを使い分けることで、複数セッションの管理コストを下げられる\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eバックグラウンドループ\u003c/strong\u003e:\u003ccode\u003e/loop\u003c/code\u003eやroutinesを使えば、そもそもセッションを人間が起動する操作自体を減らせる\u003c/li\u003e\n\u003cli\u003eこの3つを積み重ねることで、Claudeを「逐一見張る」対象から「信頼して任せる」対象へと変えていける、というのがこのトークの主張\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで登壇者個人およびClaude Codeチームの運用方針の紹介であり、すべての開発現場にそのまま当てはまるとは限らない。\u003c/p\u003e","title":"Claudeを「見張る」から「任せる」へ ― 検証ループ・マルチクロード・バックグラウンドループ"},{"content":" 要約元\n投稿：Instagram(投稿者：lightshadow_philo) 内容：優しい人ほど孤独になっていく心理的な流れを、イラストとテロップで描いたショートアニメーション 文字起こし：動画は判別できるナレーション音声を伴わず、画面に表示されるテロップのみで構成されていたため、そのテロップを目視で書き起こした なぜ、一番優しい人ほど孤独になっていくのか。動画は、その理由を特別な事件としてではなく、日々の小さな積み重ねとして描いていく。\n他人を優先し、自分を後回しにする 他人の気持ちを考えすぎて、自分のことは後回しにしてしまう。頼られると断れず、気づけばいつも助ける側にまわっている——動画はそこから話をはじめる。\n見返りを求めない犠牲と、「大丈夫」という笑顔 そうして、いつの間にか見返りを求めない犠牲を重ねるようになる。傷つくことがあっても、「大丈夫」と笑うことに慣れてしまう。\nひとりのほうが楽になっていく その積み重ねの先で、ひとりのほうが楽だと感じるようになる。外の世界と距離を置き、必要以上に心を開かなくなる。人を信じるより、傷つかないことを選ぶようになっていく。\nひとりが好きなわけじゃない けれど、と動画は続ける。それは孤独を望んでいるからではない。\nひとりが好きなわけじゃない。もう傷つきたくないだけ。\nただ安心して、誰かを信じたいだけなんだ——動画はそう締めくくる。\nまとめ 優しい人は他人の気持ちを優先し、自分のことを後回しにしがち 頼られると断れず、見返りを求めない犠牲を重ね、傷ついても「大丈夫」と笑ってしまう その積み重ねの先で、ひとりのほうが楽だと感じ、外の世界や人との間に距離を置くようになる 人を信じるより、傷つかないことを選ぶようになっていく しかしそれは孤独を望んでいるのではなく、もう傷つきたくないだけであり、本当はただ安心して誰かを信じたいだけ なお、これはあくまで動画で語られた一つの見方であり、学術的な主張として提示されているものではない。\n","permalink":"https://america.github.io/post/2026-08-17-why-kind-people-become-lonely/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/reels/DcGiYJWzwTN/\"\u003eInstagram\u003c/a\u003e(投稿者：lightshadow_philo)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：優しい人ほど孤独になっていく心理的な流れを、イラストとテロップで描いたショートアニメーション\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：動画は判別できるナレーション音声を伴わず、画面に表示されるテロップのみで構成されていたため、そのテロップを目視で書き起こした\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eなぜ、一番優しい人ほど孤独になっていくのか。動画は、その理由を特別な事件としてではなく、日々の小さな積み重ねとして描いていく。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"他人を優先し自分を後回しにする\"\u003e他人を優先し、自分を後回しにする\u003c/h2\u003e\n\u003cp\u003e他人の気持ちを考えすぎて、自分のことは後回しにしてしまう。頼られると断れず、気づけばいつも助ける側にまわっている——動画はそこから話をはじめる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"見返りを求めない犠牲と大丈夫という笑顔\"\u003e見返りを求めない犠牲と、「大丈夫」という笑顔\u003c/h2\u003e\n\u003cp\u003eそうして、いつの間にか見返りを求めない犠牲を重ねるようになる。傷つくことがあっても、「大丈夫」と笑うことに慣れてしまう。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ひとりのほうが楽になっていく\"\u003eひとりのほうが楽になっていく\u003c/h2\u003e\n\u003cp\u003eその積み重ねの先で、ひとりのほうが楽だと感じるようになる。外の世界と距離を置き、必要以上に心を開かなくなる。人を信じるより、傷つかないことを選ぶようになっていく。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ひとりが好きなわけじゃない\"\u003eひとりが好きなわけじゃない\u003c/h2\u003e\n\u003cp\u003eけれど、と動画は続ける。それは孤独を望んでいるからではない。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eひとりが好きなわけじゃない。もう傷つきたくないだけ。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eただ安心して、誰かを信じたいだけなんだ——動画はそう締めくくる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e優しい人は他人の気持ちを優先し、自分のことを後回しにしがち\u003c/li\u003e\n\u003cli\u003e頼られると断れず、見返りを求めない犠牲を重ね、傷ついても「大丈夫」と笑ってしまう\u003c/li\u003e\n\u003cli\u003eその積み重ねの先で、ひとりのほうが楽だと感じ、外の世界や人との間に距離を置くようになる\u003c/li\u003e\n\u003cli\u003e人を信じるより、傷つかないことを選ぶようになっていく\u003c/li\u003e\n\u003cli\u003eしかしそれは孤独を望んでいるのではなく、もう傷つきたくないだけであり、本当はただ安心して誰かを信じたいだけ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画で語られた一つの見方であり、学術的な主張として提示されているものではない。\u003c/p\u003e","title":"一番優しい人ほど、孤独になる理由"},{"content":" 要約元\n投稿：Instagram(投稿者：kotetsu.war、株式会社ラス・マリアナスとの共同投稿) 内容：特攻隊の若者たちが守ろうとしたものを振り返りながら、今の日本が抱える課題を重ねて問いかける動画 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。誤認識が含まれるため、確信度の高い箇所のみ目視で修正した。動画終盤の告知部分は誤認識が多く、正確な再現ができなかったため要旨のみ記載している もし今、特攻隊の若者たちがこの国を見たら、何を思うだろうか——この動画は、その問いから始まる。\n彼らが守ろうとしたもの 多くの若者たちは、家族のために、故郷のために、そして自分たちが見ることのできなかった未来のために、命をかけたという。\n動画は、彼らが守ろうとしたのは国土だけではないと述べる。\nその先にある家族の笑顔 子どもたちの未来 平和な暮らし 次の世代へ受け継がれる日本 彼らが何を願い、何を守ろうとしたのか。その思いに、一度立ち止まって耳を傾ける必要があるのではないか、と動画は問いかける。\n今の日本が抱える課題 一方で、今の日本には物価高と生活費の負担、税金や社会保険料の負担、年金、少子化、将来への不安など、さまざまな課題があるという。\nだからこそ、と動画は問いを重ねる。\n私たちは次の世代へ、どんな日本を残したいのでしょうか。\n彼らが命をかけて繋いだ未来を、今生きているのは私たちだ。その未来をどう生きるかが問われている、という論旨である。\n「未来は誰かが作るものではない」 動画は、未来は誰かが作るものではなく、一人一人の意識と行動が日本の未来を変えていくと述べる。\nその責任もその希望も、今を生きる私たちの手の中にあります。\n最後に、改めて視聴者へ問いかけて締めくくられる。\n今の日本を見て、あなたは何を感じますか。\nまとめ 特攻隊の若者たちは、国土だけでなく家族の笑顔や子どもたちの未来、平和な暮らしを守ろうとしたのではないか、と動画は述べる 一方で今の日本は、物価高・税や社会保険料の負担・年金・少子化など多くの課題を抱えている だからこそ「次の世代へどんな日本を残したいのか」を一人一人が問い直す必要がある、というのが動画のメッセージ 未来は誰かが作るものではなく、一人一人の意識と行動にかかっているとして締めくくられる なお、これはあくまで動画で語られた一つのメッセージであり、学術的な主張として提示されているものではない。動画は株式会社ラス・マリアナスとの共同投稿で、同社が主催する関連イベントの告知も含まれている。文字起こしにも自動音声認識による誤字・不明瞭箇所が残っている点には注意されたい。\n","permalink":"https://america.github.io/post/2026-08-14-if-tokkotai-youth-saw-japan-now/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/p/Db-tNUazXsi/\"\u003eInstagram\u003c/a\u003e(投稿者：kotetsu.war、株式会社ラス・マリアナスとの共同投稿)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：特攻隊の若者たちが守ろうとしたものを振り返りながら、今の日本が抱える課題を重ねて問いかける動画\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。誤認識が含まれるため、確信度の高い箇所のみ目視で修正した。動画終盤の告知部分は誤認識が多く、正確な再現ができなかったため要旨のみ記載している\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eもし今、特攻隊の若者たちがこの国を見たら、何を思うだろうか——この動画は、その問いから始まる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"彼らが守ろうとしたもの\"\u003e彼らが守ろうとしたもの\u003c/h2\u003e\n\u003cp\u003e多くの若者たちは、家族のために、故郷のために、そして自分たちが見ることのできなかった未来のために、命をかけたという。\u003c/p\u003e\n\u003cp\u003e動画は、彼らが守ろうとしたのは国土だけではないと述べる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eその先にある家族の笑顔\u003c/li\u003e\n\u003cli\u003e子どもたちの未来\u003c/li\u003e\n\u003cli\u003e平和な暮らし\u003c/li\u003e\n\u003cli\u003e次の世代へ受け継がれる日本\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e彼らが何を願い、何を守ろうとしたのか。その思いに、一度立ち止まって耳を傾ける必要があるのではないか、と動画は問いかける。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"今の日本が抱える課題\"\u003e今の日本が抱える課題\u003c/h2\u003e\n\u003cp\u003e一方で、今の日本には物価高と生活費の負担、税金や社会保険料の負担、年金、少子化、将来への不安など、さまざまな課題があるという。\u003c/p\u003e\n\u003cp\u003eだからこそ、と動画は問いを重ねる。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e私たちは次の世代へ、どんな日本を残したいのでしょうか。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e彼らが命をかけて繋いだ未来を、今生きているのは私たちだ。その未来をどう生きるかが問われている、という論旨である。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"未来は誰かが作るものではない\"\u003e「未来は誰かが作るものではない」\u003c/h2\u003e\n\u003cp\u003e動画は、未来は誰かが作るものではなく、一人一人の意識と行動が日本の未来を変えていくと述べる。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eその責任もその希望も、今を生きる私たちの手の中にあります。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e最後に、改めて視聴者へ問いかけて締めくくられる。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e今の日本を見て、あなたは何を感じますか。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e特攻隊の若者たちは、国土だけでなく家族の笑顔や子どもたちの未来、平和な暮らしを守ろうとしたのではないか、と動画は述べる\u003c/li\u003e\n\u003cli\u003e一方で今の日本は、物価高・税や社会保険料の負担・年金・少子化など多くの課題を抱えている\u003c/li\u003e\n\u003cli\u003eだからこそ「次の世代へどんな日本を残したいのか」を一人一人が問い直す必要がある、というのが動画のメッセージ\u003c/li\u003e\n\u003cli\u003e未来は誰かが作るものではなく、一人一人の意識と行動にかかっているとして締めくくられる\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画で語られた一つのメッセージであり、学術的な主張として提示されているものではない。動画は株式会社ラス・マリアナスとの共同投稿で、同社が主催する関連イベントの告知も含まれている。文字起こしにも自動音声認識による誤字・不明瞭箇所が残っている点には注意されたい。\u003c/p\u003e","title":"もし今、特攻隊の若者たちがこの国を見たら — 彼らが繋いだ未来をどう生きるか"},{"content":" 要約元\n投稿：YouTube(ジャーナリスト・烏賀陽弘道氏によるライブ配信、約2時間34分) 内容：令和8年熊本地震で発生したイオンモール熊本のガス爆発事故について、なぜLPガスが使われていたのか、なぜ地震発生1時間20分後に爆発が起きたのかを、烏賀陽氏独自の推論で分析した内容 文字起こし：YouTubeの自動生成字幕(yt-dlp経由で取得)を整形したもの。フィラー(「えっと」「あの」など)を含む口語そのままの自動音声認識のため誤字・誤認識が多く残っている可能性が高い。以下は要点を再構成したもので、逐語訳ではない 烏賀陽弘道氏は、朝日新聞・AERA記者を17年、フリーランス記者として23年のキャリアを持つジャーナリストで、東日本大震災・福島第一原発事故の取材を継続的に行ってきた人物である。\n2026年7月28日午後4時27分、熊本を最高気温35.4℃の猛暑が襲う中で地震が発生した(政府は「令和8年熊本地震」と命名)。その1時間20分後、イオンモール熊本でLPガスによる爆発が起こり、7人が命を落とした。この動画は、その原因を現場取材なしに公開情報とAIによる情報収集だけで分析するというスタイルの配信で、烏賀陽氏自身「あくまで推論」と繰り返し断りながら、国の防災政策そのものに切り込んでいく内容になっている。\nなお、烏賀陽氏は現場を直接取材していない旨を繰り返し明言しており、内容の多くは公開情報からの推論・仮説であって、警察の実況見分や公式調査の結論ではない。\n基本情報:令和8年熊本地震とガス爆発 地震発生:2026年7月28日 午後4時27分、最高気温35.4℃という猛暑日 爆発発生:地震から約1時間20分後 犠牲者:7人。うち3人はイオンモール熊本2階に入っていたアパレルブランド「エニシス」(オンワード系列)の従業員 買い物客を含む当時館内にいた約3,000人は、爆発前に全員無事避難できていた。この避難誘導自体は「奇跡的」であり、イオン側の対応として評価すべきだと烏賀陽氏は述べている なぜLPガスだったのか — 「災害拠点化」という国策 まず前提として、都市ガスとLPガス(プロパンガス)は性質が正反対だという説明がある。\n都市ガス:空気より軽く、漏れると天井付近に溜まる。だからガス漏れ警報器は天井付近に設置される LPガス:空気より1.5〜2倍重く、漏れると床に溜まっていく。だからLPガス地域の警報器は床付近に設置される イオンモール熊本ではこのLPガスが、冷房用の「ガスヒートポンプ(GHP)」の動力源として使われていた。猛暑日にショッピングモール全体を電力だけで冷やすとピーク電力価格が跳ね上がるため、電気とガスを併用するのはコスト面で合理的な選択だという。\nそのうえで、なぜ都市ガスではなくLPガスだったのかという経緯が語られる。\n2011年の東日本大震災後、内閣府(防災担当)がショッピングモールを災害時の物資供給・避難拠点に指定する方針を進めた。広い駐車場と搬入経路を持つショッピングモールは、被災地における物資集積拠点として適していたため しかし都市ガスは地中配管が地震で寸断されると復旧に数ヶ月かかる。そこで経済産業省・資源エネルギー庁が、劣化しにくく備蓄性の高いLPガスを「自立分散型の備蓄燃料」としてショッピングモールに導入することを推進した 導入費用の2/3が税金による補助金で賄われており、経済産業省・資源エネルギー庁が主導する形でLPガス業界の普及策として進められた、というのが烏賀陽氏の見立て 何が爆発を引き起こしたのか(烏賀陽氏の推論) 烏賀陽氏はいくつかのシナリオを検討している。断定は避けているが、大筋として次のような推論が語られた。\n地震でショッピングモール内の商品や什器が床に崩れ落ち、そこにLPガスが下から溜まっていくことで、密閉状態に近い滞留が生まれた可能性 LPガスタンクから屋上の室外機(ガスヒートポンプのコンプレッサーを回す)に至る配管が、地震の揺れで破断した可能性 — 烏賀陽氏はこれを「確率5割程度」と推測している さらに悪いシナリオとして、地震を検知してガス供給を自動的に止めるはずの「遮断弁」が作動しなかった可能性も指摘された。この場合、タンク内のガスがほぼすべて建物内に流出したことになる 報道写真をもとに、爆発で外壁パネルが吹き飛んだ範囲や、室外機の破損状況を見比べながら、爆発の中心がどこにあったかを推測する場面もあったが、「現場に入らないと特定できない」として最終的な断定は避けている。\nガス漏れ警報器はついていたのか 烏賀陽氏が特に懸念を示したのが、ガス漏れ警報器の設置範囲である。\nLPガス漏れ警報器は通常、厨房設備のある飲食エリア(フードコートなど)を中心に設置される傾向がある 3人が亡くなったアパレル店舗「エニシス」の区画には厨房設備がなく、警報器が設置されていなかった可能性がある、と烏賀陽氏は指摘している(あくまで可能性であり未確認) 報道では客が「ガス臭かった」と証言しているが、「警報が鳴っていた」という証言は確認できていないという 人間がガス臭を感知できる高さ(床上1.5m程度)まで臭いが達していた時点で、すでにかなり危険な濃度に達していたはずだという指摘もあった。\n「多層防護」の失敗という視点 烏賀陽氏はこの事故を、安全工学でいう「多層防護(多層防護)」の失敗として位置づけている。\n1層目の防護(地震直後の避難誘導)は成功し、約3,000人が無事避難できた しかし2層目の防護 — 「避難が完了した後、ガス漏れによる二次災害が起きたらどうするか」という想定 — が抜け落ちていた 烏賀陽氏はこれを「時限爆弾」に例え、「災害時の安全な避難拠点のはずが、実は自爆装置付きの地雷原だった」という趣旨の表現で批判している。\n官庁の縦割りと責任論 烏賀陽氏が最も強く批判しているのが、省庁間の「縦割り」構造である。\n防災政策の統括は本来内閣府の仕事だが、LPガス導入を主導したのは産業振興が本務の経済産業省・資源エネルギー庁 LPガス業界にとっては全国3,300箇所ともいわれるショッピングモールへの導入は大きな商機であり、経済産業省・資源エネルギー庁はその普及を後押しする形で補助金を出した 一方で「地震で床に可燃ガスが溜まったらどうなるか」という防災リスクの検証は、所管が異なるためどの省庁も十分に行っていなかったのではないか、というのが烏賀陽氏の推測 烏賀陽氏は、法的責任の有無とは別に「省庁の想像力の欠如によって7人が亡くなった」として、道義的な責任を厳しく問うべきだと主張している。\n従業員はなぜ建物に戻ったのか 3人が亡くなったエニシスの従業員は、地震発生から1時間20分後に館内に戻ったとされる。この「1時間20分」という時間について、烏賀陽氏は次のように分析している。\n地震直後の混乱・余震が徐々に収まってくる時間帯であり、「もう安全だろう」という油断が生まれやすいタイミングだったこと 会社側の指示・許可があったのか、それとも従業員の自己判断だったのかが、労働契約法上の争点になりうること(雇用者には災害時の安全配慮義務がある) ただし、実際に誰の指示・許可で戻ったのかという事実関係は現時点で明らかになっておらず、烏賀陽氏自身も「断定は避ける」としている。\nまとめ 令和8年熊本地震(2026年7月28日)発生から1時間20分後、イオンモール熊本でLPガス爆発が発生し7人が死亡した ショッピングモールがLPガスを使っていたのは、東日本大震災後に内閣府が進めた「災害拠点化」政策と、経済産業省・資源エネルギー庁が主導したLPガス普及策(補助金2/3)が背景にあるという烏賀陽氏の見立て LPガスは空気より重く床に溜まる性質があり、地震で倒れた商品や什器の下に滞留した可能性、配管破断や遮断弁の不作動などいくつかのシナリオが推論として提示された 厨房のないアパレル区画にはガス漏れ警報器が設置されていなかった可能性が指摘されているが、これは未確認の推測 「避難誘導」という1層目の防護は成功したが、「避難後のガス漏れ二次災害」という2層目の防護が想定されておらず、これが省庁の縦割り構造の帰結ではないかという批判が展開されている なお、これはあくまで烏賀陽氏が現場取材なしに公開情報とAIによる情報収集から組み立てた推論・仮説であり、警察の実況見分や公的な事故調査の結論として確定した内容ではない。動画内でも「断定は避ける」という留保が繰り返されている。文字起こしも自動音声認識によるものであり、誤字・誤認識が残っている可能性がある点にも注意されたい。\n","permalink":"https://america.github.io/post/2026-08-14-aeon-mall-kumamoto-gas-explosion/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.youtube.com/watch?v=cWOQrvCcfF4\"\u003eYouTube\u003c/a\u003e(ジャーナリスト・烏賀陽弘道氏によるライブ配信、約2時間34分)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：令和8年熊本地震で発生したイオンモール熊本のガス爆発事故について、なぜLPガスが使われていたのか、なぜ地震発生1時間20分後に爆発が起きたのかを、烏賀陽氏独自の推論で分析した内容\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：YouTubeの自動生成字幕(yt-dlp経由で取得)を整形したもの。フィラー(「えっと」「あの」など)を含む口語そのままの自動音声認識のため誤字・誤認識が多く残っている可能性が高い。以下は要点を再構成したもので、逐語訳ではない\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e烏賀陽弘道氏は、朝日新聞・AERA記者を17年、フリーランス記者として23年のキャリアを持つジャーナリストで、東日本大震災・福島第一原発事故の取材を継続的に行ってきた人物である。\u003c/p\u003e\n\u003cp\u003e2026年7月28日午後4時27分、熊本を最高気温35.4℃の猛暑が襲う中で地震が発生した(政府は「令和8年熊本地震」と命名)。その1時間20分後、イオンモール熊本でLPガスによる爆発が起こり、7人が命を落とした。この動画は、その原因を現場取材なしに公開情報とAIによる情報収集だけで分析するというスタイルの配信で、烏賀陽氏自身「あくまで推論」と繰り返し断りながら、国の防災政策そのものに切り込んでいく内容になっている。\u003c/p\u003e\n\u003cp\u003eなお、烏賀陽氏は現場を直接取材していない旨を繰り返し明言しており、内容の多くは公開情報からの推論・仮説であって、警察の実況見分や公式調査の結論ではない。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"基本情報令和8年熊本地震とガス爆発\"\u003e基本情報:令和8年熊本地震とガス爆発\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e地震発生:2026年7月28日 午後4時27分、最高気温35.4℃という猛暑日\u003c/li\u003e\n\u003cli\u003e爆発発生:地震から約1時間20分後\u003c/li\u003e\n\u003cli\u003e犠牲者:7人。うち3人はイオンモール熊本2階に入っていたアパレルブランド「エニシス」(オンワード系列)の従業員\u003c/li\u003e\n\u003cli\u003e買い物客を含む当時館内にいた約3,000人は、爆発前に全員無事避難できていた。この避難誘導自体は「奇跡的」であり、イオン側の対応として評価すべきだと烏賀陽氏は述べている\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"なぜlpガスだったのか--災害拠点化という国策\"\u003eなぜLPガスだったのか — 「災害拠点化」という国策\u003c/h2\u003e\n\u003cp\u003eまず前提として、都市ガスとLPガス(プロパンガス)は性質が正反対だという説明がある。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e都市ガス\u003c/strong\u003e:空気より軽く、漏れると天井付近に溜まる。だからガス漏れ警報器は天井付近に設置される\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLPガス\u003c/strong\u003e:空気より1.5〜2倍重く、漏れると床に溜まっていく。だからLPガス地域の警報器は床付近に設置される\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eイオンモール熊本ではこのLPガスが、冷房用の「ガスヒートポンプ(GHP)」の動力源として使われていた。猛暑日にショッピングモール全体を電力だけで冷やすとピーク電力価格が跳ね上がるため、電気とガスを併用するのはコスト面で合理的な選択だという。\u003c/p\u003e\n\u003cp\u003eそのうえで、なぜ都市ガスではなくLPガスだったのかという経緯が語られる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e2011年の東日本大震災後、内閣府(防災担当)がショッピングモールを災害時の物資供給・避難拠点に指定する方針を進めた。広い駐車場と搬入経路を持つショッピングモールは、被災地における物資集積拠点として適していたため\u003c/li\u003e\n\u003cli\u003eしかし都市ガスは地中配管が地震で寸断されると復旧に数ヶ月かかる。そこで経済産業省・資源エネルギー庁が、劣化しにくく備蓄性の高いLPガスを「自立分散型の備蓄燃料」としてショッピングモールに導入することを推進した\u003c/li\u003e\n\u003cli\u003e導入費用の2/3が税金による補助金で賄われており、経済産業省・資源エネルギー庁が主導する形でLPガス業界の普及策として進められた、というのが烏賀陽氏の見立て\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"何が爆発を引き起こしたのか烏賀陽氏の推論\"\u003e何が爆発を引き起こしたのか(烏賀陽氏の推論)\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏はいくつかのシナリオを検討している。断定は避けているが、大筋として次のような推論が語られた。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e地震でショッピングモール内の商品や什器が床に崩れ落ち、そこにLPガスが下から溜まっていくことで、密閉状態に近い滞留が生まれた可能性\u003c/li\u003e\n\u003cli\u003eLPガスタンクから屋上の室外機(ガスヒートポンプのコンプレッサーを回す)に至る配管が、地震の揺れで破断した可能性 — 烏賀陽氏はこれを「確率5割程度」と推測している\u003c/li\u003e\n\u003cli\u003eさらに悪いシナリオとして、地震を検知してガス供給を自動的に止めるはずの「遮断弁」が作動しなかった可能性も指摘された。この場合、タンク内のガスがほぼすべて建物内に流出したことになる\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e報道写真をもとに、爆発で外壁パネルが吹き飛んだ範囲や、室外機の破損状況を見比べながら、爆発の中心がどこにあったかを推測する場面もあったが、「現場に入らないと特定できない」として最終的な断定は避けている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ガス漏れ警報器はついていたのか\"\u003eガス漏れ警報器はついていたのか\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏が特に懸念を示したのが、ガス漏れ警報器の設置範囲である。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eLPガス漏れ警報器は通常、厨房設備のある飲食エリア(フードコートなど)を中心に設置される傾向がある\u003c/li\u003e\n\u003cli\u003e3人が亡くなったアパレル店舗「エニシス」の区画には厨房設備がなく、警報器が設置されていなかった可能性がある、と烏賀陽氏は指摘している(あくまで可能性であり未確認)\u003c/li\u003e\n\u003cli\u003e報道では客が「ガス臭かった」と証言しているが、「警報が鳴っていた」という証言は確認できていないという\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e人間がガス臭を感知できる高さ(床上1.5m程度)まで臭いが達していた時点で、すでにかなり危険な濃度に達していたはずだという指摘もあった。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"多層防護の失敗という視点\"\u003e「多層防護」の失敗という視点\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏はこの事故を、安全工学でいう「多層防護(多層防護)」の失敗として位置づけている。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e1層目の防護(地震直後の避難誘導)は成功し、約3,000人が無事避難できた\u003c/li\u003e\n\u003cli\u003eしかし2層目の防護 — 「避難が完了した後、ガス漏れによる二次災害が起きたらどうするか」という想定 — が抜け落ちていた\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e烏賀陽氏はこれを「時限爆弾」に例え、「災害時の安全な避難拠点のはずが、実は自爆装置付きの地雷原だった」という趣旨の表現で批判している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"官庁の縦割りと責任論\"\u003e官庁の縦割りと責任論\u003c/h2\u003e\n\u003cp\u003e烏賀陽氏が最も強く批判しているのが、省庁間の「縦割り」構造である。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e防災政策の統括は本来内閣府の仕事だが、LPガス導入を主導したのは産業振興が本務の経済産業省・資源エネルギー庁\u003c/li\u003e\n\u003cli\u003eLPガス業界にとっては全国3,300箇所ともいわれるショッピングモールへの導入は大きな商機であり、経済産業省・資源エネルギー庁はその普及を後押しする形で補助金を出した\u003c/li\u003e\n\u003cli\u003e一方で「地震で床に可燃ガスが溜まったらどうなるか」という防災リスクの検証は、所管が異なるためどの省庁も十分に行っていなかったのではないか、というのが烏賀陽氏の推測\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e烏賀陽氏は、法的責任の有無とは別に「省庁の想像力の欠如によって7人が亡くなった」として、道義的な責任を厳しく問うべきだと主張している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"従業員はなぜ建物に戻ったのか\"\u003e従業員はなぜ建物に戻ったのか\u003c/h2\u003e\n\u003cp\u003e3人が亡くなったエニシスの従業員は、地震発生から1時間20分後に館内に戻ったとされる。この「1時間20分」という時間について、烏賀陽氏は次のように分析している。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e地震直後の混乱・余震が徐々に収まってくる時間帯であり、「もう安全だろう」という油断が生まれやすいタイミングだったこと\u003c/li\u003e\n\u003cli\u003e会社側の指示・許可があったのか、それとも従業員の自己判断だったのかが、労働契約法上の争点になりうること(雇用者には災害時の安全配慮義務がある)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eただし、実際に誰の指示・許可で戻ったのかという事実関係は現時点で明らかになっておらず、烏賀陽氏自身も「断定は避ける」としている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e令和8年熊本地震(2026年7月28日)発生から1時間20分後、イオンモール熊本でLPガス爆発が発生し7人が死亡した\u003c/li\u003e\n\u003cli\u003eショッピングモールがLPガスを使っていたのは、東日本大震災後に内閣府が進めた「災害拠点化」政策と、経済産業省・資源エネルギー庁が主導したLPガス普及策(補助金2/3)が背景にあるという烏賀陽氏の見立て\u003c/li\u003e\n\u003cli\u003eLPガスは空気より重く床に溜まる性質があり、地震で倒れた商品や什器の下に滞留した可能性、配管破断や遮断弁の不作動などいくつかのシナリオが推論として提示された\u003c/li\u003e\n\u003cli\u003e厨房のないアパレル区画にはガス漏れ警報器が設置されていなかった可能性が指摘されているが、これは未確認の推測\u003c/li\u003e\n\u003cli\u003e「避難誘導」という1層目の防護は成功したが、「避難後のガス漏れ二次災害」という2層目の防護が想定されておらず、これが省庁の縦割り構造の帰結ではないかという批判が展開されている\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで烏賀陽氏が現場取材なしに公開情報とAIによる情報収集から組み立てた推論・仮説であり、警察の実況見分や公的な事故調査の結論として確定した内容ではない。動画内でも「断定は避ける」という留保が繰り返されている。文字起こしも自動音声認識によるものであり、誤字・誤認識が残っている可能性がある点にも注意されたい。\u003c/p\u003e","title":"イオンモール熊本ガス爆発はなぜ起きたのか — 「災害拠点化」国策の思わぬ落とし穴"},{"content":" 要約元\n投稿：Instagram 内容：人生の最後に残るのは家やお金や肩書ではなく、誰かの心に残る記憶や優しさだという内容のメッセージ動画 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。今回は誤認識がほとんどなく、出力をほぼそのまま採用した。 人生の最後に、いったい何が残るのか。家だろうか、お金だろうか、肩書だろうか——この動画は、その問いから始まる。\n家も、お金も、肩書も残らない 家は片付けられ、お金は誰かの手に渡り、肩書はその人と一緒に消えていく。動画は、これらのほとんどは最終的に残らないと述べる。\n残るのは「誰かの心に残る記憶」 では何が残るのか。それは、誰かの心に残る「あなたとの記憶」だという。\n辛い時にそっとそばにいてくれたこと、何気ない一言に救われたこと。何をしたかよりも、どう寄り添ってくれたか——それだけが、人の中に残っていく。\n「ちゃんと大切にできただろうか」 人生の最後に残るのは、成功でも評価でもない。「ちゃんと大切にできただろうか」という思いだ、と動画は語る。\nもし今会いたい人がいるなら、伝えたい言葉があるなら、その時間は思っているより長くない。\nあなたが与えた優しさ 人生の最後に残るのは、あなたが与えた優しさだという。\n誰かがあなたを思い出した時、少し心が温かくなる。それが一つでも残せたなら、その人生はきっと十分です。\n動画は最後に、こう問いかけて締めくくられる。\nあなたの中に残っている大切な記憶は何ですか?\nまとめ 人生の最後に残るのは、家・お金・肩書ではない 残るのは、誰かの心に残る「あなたとの記憶」であり、何をしたかよりどう寄り添ったかが大切 人生の価値を測るのは成功や評価ではなく、「大切にできただろうか」という思い 会いたい人、伝えたい言葉があるなら、時間は思っているより長くない 誰かの心を少しでも温かくできたなら、その人生は十分だ——というのがこの動画のメッセージ なお、これはあくまで動画で語られた一つの考え方であり、学術的な主張として提示されているものではない。\n","permalink":"https://america.github.io/post/2026-08-12-what-remains-in-the-end/","summary":"\u003cdiv class=\"react-diagram\" data-diagram=\"firefly-cover\"\u003e\u003c/div\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/reels/DX6n5GSJ5_J/\"\u003eInstagram\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：人生の最後に残るのは家やお金や肩書ではなく、誰かの心に残る記憶や優しさだという内容のメッセージ動画\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。今回は誤認識がほとんどなく、出力をほぼそのまま採用した。\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e人生の最後に、いったい何が残るのか。家だろうか、お金だろうか、肩書だろうか——この動画は、その問いから始まる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"家もお金も肩書も残らない\"\u003e家も、お金も、肩書も残らない\u003c/h2\u003e\n\u003cp\u003e家は片付けられ、お金は誰かの手に渡り、肩書はその人と一緒に消えていく。動画は、これらのほとんどは最終的に残らないと述べる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"残るのは誰かの心に残る記憶\"\u003e残るのは「誰かの心に残る記憶」\u003c/h2\u003e\n\u003cp\u003eでは何が残るのか。それは、誰かの心に残る「あなたとの記憶」だという。\u003c/p\u003e\n\u003cp\u003e辛い時にそっとそばにいてくれたこと、何気ない一言に救われたこと。何をしたかよりも、どう寄り添ってくれたか——それだけが、人の中に残っていく。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"ちゃんと大切にできただろうか\"\u003e「ちゃんと大切にできただろうか」\u003c/h2\u003e\n\u003cp\u003e人生の最後に残るのは、成功でも評価でもない。「ちゃんと大切にできただろうか」という思いだ、と動画は語る。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eもし今会いたい人がいるなら、伝えたい言葉があるなら、その時間は思っているより長くない。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"あなたが与えた優しさ\"\u003eあなたが与えた優しさ\u003c/h2\u003e\n\u003cp\u003e人生の最後に残るのは、あなたが与えた優しさだという。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e誰かがあなたを思い出した時、少し心が温かくなる。それが一つでも残せたなら、その人生はきっと十分です。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e動画は最後に、こう問いかけて締めくくられる。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eあなたの中に残っている大切な記憶は何ですか?\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e人生の最後に残るのは、家・お金・肩書ではない\u003c/li\u003e\n\u003cli\u003e残るのは、誰かの心に残る「あなたとの記憶」であり、何をしたかよりどう寄り添ったかが大切\u003c/li\u003e\n\u003cli\u003e人生の価値を測るのは成功や評価ではなく、「大切にできただろうか」という思い\u003c/li\u003e\n\u003cli\u003e会いたい人、伝えたい言葉があるなら、時間は思っているより長くない\u003c/li\u003e\n\u003cli\u003e誰かの心を少しでも温かくできたなら、その人生は十分だ——というのがこの動画のメッセージ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画で語られた一つの考え方であり、学術的な主張として提示されているものではない。\u003c/p\u003e","title":"人生の最後に残るもの — 家でもお金でも肩書でもなく"},{"content":" 要約元\n投稿：Instagram 内容：労働者階級と資産家階級の格差・世襲、戦争と再分配の歴史サイクルについての論考動画 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。誤認識が含まれるため、確信度の高い箇所のみ目視で修正した。人名らしき箇所は誤認識の可能性が高く特定できなかったため未修正。 戦争のない状態が長く続くと、貧富の差は必ず広がる。そして貧富の差が広がると、いずれ必ず戦争になる——このサイクルはどの国でも、永遠に繰り返されるという。\nこの動画は、その理由を「労働者階級」と「資産家階級」という2つの階級の違いから説明している。\n労働者階級は「能力」しか受け継げない 労働者階級の労働能力は、受け継ぐことができない。\n親が亡くなれば、その能力自体が消えてしまう。子供は改めて勉強し、働きながら経験を積むところから始めなければならない、という。\n資産家階級は「資産」と「名声」を受け継ぐ 一方、資産家階級には受け継げる資産がある。\n会社の利益分配 本の印税 貯金の利息 株の配当 などが例として挙げられている。\nさらに、資産だけでなく名声も受け継がれる。有名役者の子供は役者になりやすく、政治家の子供も政治家になりやすい——これが「世襲」だと動画は説明する。\n教育の方向性がスタートラインを分ける 有形資産だけでなく、知識も受け継ぐことができるという。\n労働者家庭では労働者としての教育、資産家家庭では経営者としての教育が行われる。この教育の方向性の違いが、子供の人生の分かれ目になる、というのが動画の主張。育つ環境によってスタートラインと進む方向性が大きく異なり、その後の人生も大きく違ってくるとしている。\n一代の努力では埋まらない差 資産家が代々積み重ねてきたものに、労働者が一代の努力だけで追いつくのは難しい。\n自身の努力である程度のお金を稼ぐことはできても、財閥クラスの資産家に勝てるかといえば勝てない。だから多くの人は、一生懸命働いた末の到達点が、一部の人間のスタートラインにさえ届かない——動画はそう述べている。\n人と人の違いを生み出すのは努力ではなく、環境そのものである。\n格差の放置は経済も停滞させる 収入の差を放っておくと、どんどん広がっていく。\nさほど働かなくてもお金が増え続ける資産家に対し、労働者は一生懸命働いてもどんどん貧しくなる。貧しさが増えると社会全体の消費力が落ち、経済が停滞する、という流れが説明されている。\n再分配は進まず、階級対立が戦争を生む 本来、こうした格差は政治の力によって再分配されるべきだが、実際には政治が資本(資産家)の側に近い立場を取りがちで、結果として収入の差はさらに広がる。\n労働者階級の不安が高まると、階級間の対立が進み、やがて戦争に至る——というのが動画の描く展開。\n戦争の後に「リセット」が起きる 戦後は資産が再分配され、経済も活性化する。歴史を振り返ると、戦争の後はおおむね高度成長期になりやすい、と動画は指摘している。\n結局、人間の強欲さがある以上、戦争はなくならない。動画では、次のような言葉が引用されていた。\n人間が歴史から学んだ唯一のことは、人間は歴史から何も学んでいないということだ。\n(発言者とされる人名は音声認識では判別できず、特定できていない)\nまとめ 労働者階級は労働能力しか受け継げないが、資産家階級は資産・名声・教育方針までも受け継げる この差がスタートラインの違いを生み、一代の努力だけでは埋まらないほど拡大していく 格差を放置すると社会全体の消費力が落ち、経済が停滞する 本来は政治による再分配が期待されるが、実際には機能しづらく、格差はさらに広がる 格差の拡大は階級対立を生み、最終的に戦争、そして戦後の再分配へとつながる——というのがこの動画の主張 なお、これはあくまで動画内で語られた一つの歴史観・主張であり、学術的な定説として提示されているものではない。文字起こしにも自動音声認識による誤字・不明瞭箇所が残っている点には注意。\n","permalink":"https://america.github.io/post/2026-08-10-labor-capital-class-inheritance-war-cycle/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e投稿\u003c/strong\u003e：\u003ca href=\"https://www.instagram.com/p/Da7f9iGKOTQ/\"\u003eInstagram\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e内容\u003c/strong\u003e：労働者階級と資産家階級の格差・世襲、戦争と再分配の歴史サイクルについての論考動画\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e文字起こし\u003c/strong\u003e：faster-whisper(smallモデル、CPU、int8)による自動生成。誤認識が含まれるため、確信度の高い箇所のみ目視で修正した。人名らしき箇所は誤認識の可能性が高く特定できなかったため未修正。\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e戦争のない状態が長く続くと、貧富の差は必ず広がる。そして貧富の差が広がると、いずれ必ず戦争になる——このサイクルはどの国でも、永遠に繰り返されるという。\u003c/p\u003e\n\u003cp\u003eこの動画は、その理由を「労働者階級」と「資産家階級」という2つの階級の違いから説明している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"労働者階級は能力しか受け継げない\"\u003e労働者階級は「能力」しか受け継げない\u003c/h2\u003e\n\u003cp\u003e労働者階級の労働能力は、受け継ぐことができない。\u003c/p\u003e\n\u003cp\u003e親が亡くなれば、その能力自体が消えてしまう。子供は改めて勉強し、働きながら経験を積むところから始めなければならない、という。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"資産家階級は資産と名声を受け継ぐ\"\u003e資産家階級は「資産」と「名声」を受け継ぐ\u003c/h2\u003e\n\u003cp\u003e一方、資産家階級には受け継げる資産がある。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e会社の利益分配\u003c/li\u003e\n\u003cli\u003e本の印税\u003c/li\u003e\n\u003cli\u003e貯金の利息\u003c/li\u003e\n\u003cli\u003e株の配当\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなどが例として挙げられている。\u003c/p\u003e\n\u003cp\u003eさらに、資産だけでなく名声も受け継がれる。有名役者の子供は役者になりやすく、政治家の子供も政治家になりやすい——これが「世襲」だと動画は説明する。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"教育の方向性がスタートラインを分ける\"\u003e教育の方向性がスタートラインを分ける\u003c/h2\u003e\n\u003cp\u003e有形資産だけでなく、知識も受け継ぐことができるという。\u003c/p\u003e\n\u003cp\u003e労働者家庭では労働者としての教育、資産家家庭では経営者としての教育が行われる。この教育の方向性の違いが、子供の人生の分かれ目になる、というのが動画の主張。育つ環境によってスタートラインと進む方向性が大きく異なり、その後の人生も大きく違ってくるとしている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一代の努力では埋まらない差\"\u003e一代の努力では埋まらない差\u003c/h2\u003e\n\u003cp\u003e資産家が代々積み重ねてきたものに、労働者が一代の努力だけで追いつくのは難しい。\u003c/p\u003e\n\u003cp\u003e自身の努力である程度のお金を稼ぐことはできても、財閥クラスの資産家に勝てるかといえば勝てない。だから多くの人は、一生懸命働いた末の到達点が、一部の人間のスタートラインにさえ届かない——動画はそう述べている。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e人と人の違いを生み出すのは努力ではなく、環境そのものである。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"格差の放置は経済も停滞させる\"\u003e格差の放置は経済も停滞させる\u003c/h2\u003e\n\u003cp\u003e収入の差を放っておくと、どんどん広がっていく。\u003c/p\u003e\n\u003cp\u003eさほど働かなくてもお金が増え続ける資産家に対し、労働者は一生懸命働いてもどんどん貧しくなる。貧しさが増えると社会全体の消費力が落ち、経済が停滞する、という流れが説明されている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"再分配は進まず階級対立が戦争を生む\"\u003e再分配は進まず、階級対立が戦争を生む\u003c/h2\u003e\n\u003cp\u003e本来、こうした格差は政治の力によって再分配されるべきだが、実際には政治が資本(資産家)の側に近い立場を取りがちで、結果として収入の差はさらに広がる。\u003c/p\u003e\n\u003cp\u003e労働者階級の不安が高まると、階級間の対立が進み、やがて戦争に至る——というのが動画の描く展開。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"戦争の後にリセットが起きる\"\u003e戦争の後に「リセット」が起きる\u003c/h2\u003e\n\u003cp\u003e戦後は資産が再分配され、経済も活性化する。歴史を振り返ると、戦争の後はおおむね高度成長期になりやすい、と動画は指摘している。\u003c/p\u003e\n\u003cp\u003e結局、人間の強欲さがある以上、戦争はなくならない。動画では、次のような言葉が引用されていた。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e人間が歴史から学んだ唯一のことは、人間は歴史から何も学んでいないということだ。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e(発言者とされる人名は音声認識では判別できず、特定できていない)\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"まとめ\"\u003eまとめ\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e労働者階級は労働能力しか受け継げないが、資産家階級は資産・名声・教育方針までも受け継げる\u003c/li\u003e\n\u003cli\u003eこの差がスタートラインの違いを生み、一代の努力だけでは埋まらないほど拡大していく\u003c/li\u003e\n\u003cli\u003e格差を放置すると社会全体の消費力が落ち、経済が停滞する\u003c/li\u003e\n\u003cli\u003e本来は政治による再分配が期待されるが、実際には機能しづらく、格差はさらに広がる\u003c/li\u003e\n\u003cli\u003e格差の拡大は階級対立を生み、最終的に戦争、そして戦後の再分配へとつながる——というのがこの動画の主張\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなお、これはあくまで動画内で語られた一つの歴史観・主張であり、学術的な定説として提示されているものではない。文字起こしにも自動音声認識による誤字・不明瞭箇所が残っている点には注意。\u003c/p\u003e","title":"労働者階級と資産家階級 — 格差はなぜ広がり続け、なぜ戦争で『リセット』されるのか"},{"content":"事象 普段使っているswayfx上で、scratchpadに入れたウィンドウを表示している状態からもう一度scratchpad showを叩くと、コンポジタごと丸ごと落ちる現象に遭遇した。SDDMのログイン画面まで戻される、なかなか派手なクラッシュ。\n環境:\n項目 値 swayfx 0.5.3-4(sway 1.11.0ベース、Arch Linuxパッケージ) wlroots 0.19.3 GPU AMD Radeon RX 6600 XT(amdgpu) bindsymはこう組んでいた:\nbindsym $mod+minus scratchpad show, resize set width 90 ppt height 90 ppt, move position center Copy scratchpad showと同時にresize・moveを連続実行する形。これを2回続けて押す(1回目で表示、2回目でフォーカスしたまま押してhideパスに入る)とクラッシュする。\nスタックトレースを取る coredumpctl + gdb(デバッグシンボル入り)でコアダンプを解析した。\n#0 root_scratchpad_hide (con=0x55f058a52400) at ../swayfx-0.5.3/sway/tree/root.c:257 257\tset_container_transform(con-\u003epending.workspace, con); seat = 0x55f0580db940 focus = 0x55f058a41760 ws = 0x0 Copy ws(= con-\u0026gt;pending.workspace)がNULLのままset_container_transform()に渡され、内部で参照外しして落ちていた。該当箇所のコードはこうなっていた:\nvoid root_scratchpad_hide(struct sway_container *con) { struct sway_seat *seat = input_manager_current_seat(); struct sway_node *focus = seat_get_focus_inactive(seat, \u0026root-\u003enode); struct sway_workspace *ws = con-\u003epending.workspace; if (con-\u003epending.fullscreen_mode == FULLSCREEN_GLOBAL \u0026\u0026 !con-\u003epending.workspace) { // If the container was made fullscreen global while in the scratchpad, // it should be shown until fullscreen has been disabled return; } ... set_container_transform(con-\u003epending.workspace, con); // ガードなし Copy NULLチェックが「FULLSCREEN_GLOBALのときだけ」に絞られていて、それ以外の理由でpending.workspaceがNULLになるケースを素通りしてしまう。set_container_transform()はswayfx独自の追加関数(本家swayには存在しない)なので、一見swayfx側のバグに見えた。\nswayfx Issue #560としてこの内容を報告した。\n「upstreamにもあるの?」への一言 翌日、メンテナーから短い返信が来た。\nis this present in upstream? We don\u0026rsquo;t touch the scratchpad code much if at all\n「upstream(本家sway)にもあるバグか? scratchpadのコードはほとんど触ってないはず」という趣旨。素っ気ない一言だったが、これは実際に手を動かして確かめる価値がある問いだった。\n調査の経緯 答えは「upstreamにも同じバグがあった。しかも本家側は既に直していて、swayfxはその修正をまだ取り込んでいなかっただけ」。メンテナーの「upstreamにあるか?」という勘所は当たっていたが、実際にそう答えられる根拠(git archaeology)までは、あの一言のやり取りだけでは示されていなかった。\n実際に手を動かして検証する 推測だけで終わらせず、現在のmasterで本当に直っているかを実機で確認することにした。\nビルド git clone https://github.com/wlrfx/swayfx.git ~/src/swayfx cd ~/src/swayfx meson setup build --prefix=/tmp/swayfx-test -Dbuildtype=debug Copy 依存関係で2つ詰まった。\nmeson/ninjaが未インストール → pacman -S meson ninja scenefx-0.5が必要だが、システムにはscenefx0.4(0.4.1-2)しか入っていない → AURのscenefx0.5パッケージを導入。既存のscenefx0.4とはsoname(libscenefx-0.4.so / libscenefx-0.5.so)が別なので、wlroots0.19/wlroots0.20が共存しているのと同じ要領で問題なく共存できた。 ビルド後、/tmpはtmpfs(メモリ上のファイルシステム)なので再起動で消える点だけ注意しつつ、/tmp/swayfx-testにインストール。\nネスト起動で検証環境を用意 本番のセッションを壊さずに試すため、今動いているswayfxセッションの中で、ビルドしたswayfxをネストしたWaylandクライアントとして起動する。\nWLR_BACKENDS=wayland /tmp/swayfx-test/bin/sway -c ~/.config/sway/config Copy ここでいくつかハマった。\nフォーカスが外側に漏れる — ネストウィンドウをクリックしても、キー入力($mod+Enterなど)が外側の本番セッションに拾われてしまい、weztermがネストの外に出てしまう。\nweztermの単一インスタンス仕様 — 実はこれはフォーカスの問題ではなく、weztermがデフォルトで単一のGUIプロセスを使い回す仕様が原因だった。WAYLAND_DISPLAYを変えて起動しても、既存のGUIインスタンスに新しいタブが追加されるだけ。wezterm start --always-new-processで独立したプロセスとして起動する必要があった。\nenable_wayland = false — それでもネスト側に出てこない。原因はさらに別で、weztermの設定にconfig.enable_wayland = false(コメントは「XWaylandで動かす」とだけ、理由はgit logにも残っていなかった)という設定があり、weztermは常にXWayland経由で動く仕様になっていた。ネストsway側のXWaylandディスプレイ(/tmp/.X11-unix/X2)をDISPLAY=:2で明示的に指定して、ようやくネストの中にウィンドウが出た。\nキー操作をやめてIPCで直接叩く ここまでの経緯でGUI経由のキー操作はフォーカスが不安定と分かっていたので、最終的にはswaymsgでネストsway側のIPCソケットに直接コマンドを送ることにした。\nexport SWAYSOCK=/run/user/1000/sway-ipc.1000..sock swaymsg 'move scratchpad' swaymsg 'scratchpad show, resize set width 90 ppt height 90 ppt, move position center' # 1回目: 表示 swaymsg 'scratchpad show, resize set width 90 ppt height 90 ppt, move position center' # 2回目: hideパス Copy 2回目の実行後もプロセスはstate=S(通常のスリープ)で生存、coredumpctlにも新規クラッシュなし。get_treeで見てもコンテナは__i3_scratchワークスペースに正常に戻っていた。\nクラッシュしなかった。 masterでは修正済みであることを、実際に手を動かして確認できた。\nIssueへの報告とクローズ 調べた経緯(git archaeologyの結果)と、実機での検証結果をまとめてIssueにコメントした。\nupstreamにも同じ種類のバグが存在し、既に修正されていたこと(swaywm/sway#8909) swayfxはその修正を#537で取り込み済みで、現行masterでは再現しないこと 実際にmasterをビルドして再現手順を試し、クラッシュしないことを確認したこと その上でIssueをクローズした。\nまとめ swayfx独自のバグに見えたクラッシュは、実はupstream sway由来のバグをフォークが引き継ぎ、upstream側の修正をまだ取り込めていなかっただけだった メンテナーの「upstreamにあるか?」という一言は勘所としては正しかったが、実際に裏を取るには git blame でコミット履歴を本家・フォーク両方に渡って追う必要があった 「直っているはず」で終わらせず、実際にmasterをビルドしてネスト起動 + IPC経由でクラッシュ手順を再現し、直っていることを手を動かして確認した 検証の過程で本題(scratchpadのバグ)とは無関係な小さなハマりどころ(依存パッケージのバージョン違い、ネストコンポジタのフォーカス、weztermの単一インスタンス仕様とXWayland固定設定)が積み重なった。デバッグ環境を作ること自体が、もう一段の調査になることがよくある ","permalink":"https://america.github.io/post/2026-08-09-swayfx-scratchpad-null-crash/","summary":"\u003ch2 id=\"事象\"\u003e事象\u003c/h2\u003e\n\u003cp\u003e普段使っているswayfx上で、scratchpadに入れたウィンドウを表示している状態からもう一度\u003ccode\u003escratchpad show\u003c/code\u003eを叩くと、コンポジタごと丸ごと落ちる現象に遭遇した。SDDMのログイン画面まで戻される、なかなか派手なクラッシュ。\u003c/p\u003e\n\u003cp\u003e環境:\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e項目\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e値\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eswayfx\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e0.5.3-4(sway 1.11.0ベース、Arch Linuxパッケージ)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003ewlroots\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e0.19.3\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eGPU\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAMD Radeon RX 6600 XT(amdgpu)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003ebindsymはこう組んでいた:\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003ebindsym $mod+minus scratchpad show, resize set width 90 ppt height 90 ppt, move position center\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003escratchpad show\u003c/code\u003eと同時に\u003ccode\u003eresize\u003c/code\u003e・\u003ccode\u003emove\u003c/code\u003eを連続実行する形。これを2回続けて押す(1回目で表示、2回目でフォーカスしたまま押してhideパスに入る)とクラッシュする。\u003c/p\u003e\n\u003ch2 id=\"スタックトレースを取る\"\u003eスタックトレースを取る\u003c/h2\u003e\n\u003cp\u003e\u003ccode\u003ecoredumpctl\u003c/code\u003e + \u003ccode\u003egdb\u003c/code\u003e(デバッグシンボル入り)でコアダンプを解析した。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-\"\u003e#0  root_scratchpad_hide (con=0x55f058a52400) at ../swayfx-0.5.3/sway/tree/root.c:257\n257\t\tset_container_transform(con-\u003epending.workspace, con);\n        seat = 0x55f0580db940\n        focus = 0x55f058a41760\n        ws = 0x0\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003ews\u003c/code\u003e(= \u003ccode\u003econ-\u0026gt;pending.workspace\u003c/code\u003e)が\u003ccode\u003eNULL\u003c/code\u003eのまま\u003ccode\u003eset_container_transform()\u003c/code\u003eに渡され、内部で参照外しして落ちていた。該当箇所のコードはこうなっていた:\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-2\" class=\"language-c\"\u003evoid root_scratchpad_hide(struct sway_container *con) {\n\tstruct sway_seat *seat = input_manager_current_seat();\n\tstruct sway_node *focus = seat_get_focus_inactive(seat, \u0026root-\u003enode);\n\tstruct sway_workspace *ws = con-\u003epending.workspace;\n\n\tif (con-\u003epending.fullscreen_mode == FULLSCREEN_GLOBAL \u0026\u0026 !con-\u003epending.workspace) {\n\t\t// If the container was made fullscreen global while in the scratchpad,\n\t\t// it should be shown until fullscreen has been disabled\n\t\treturn;\n\t}\n\t...\n\tset_container_transform(con-\u003epending.workspace, con);   // ガードなし\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-2', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003eNULLチェックが「\u003ccode\u003eFULLSCREEN_GLOBAL\u003c/code\u003eのときだけ」に絞られていて、それ以外の理由で\u003ccode\u003epending.workspace\u003c/code\u003eがNULLになるケースを素通りしてしまう。\u003ccode\u003eset_container_transform()\u003c/code\u003eはswayfx独自の追加関数(本家swayには存在しない)なので、一見swayfx側のバグに見えた。\u003c/p\u003e","title":"swayfxのscratchpadクラッシュを追う: git blameで見つけたupstreamとの噛み合わせ問題"},{"content":" 訂正 (2026-08-08)\nこの記事の当初の結論「ユーザー側の設定では解消できない」は 誤りでした。 /etc/environment にIME環境変数を設定することで、Ctrl+Space での直接入力が動作するようになりました。 結論だけ必要な方は 追記: 解決した へ。\n以下の調査記録は、当時どう考えて誤った結論に至ったかの記録として、そのまま残します。\n事象 Street Fighter 6のチャット欄でCtrl+Space(fcitx5のトリガーキー)を押しても、日本語入力(Mozc)に 切り替わらない。ローマ字のまま反応しない。\n項目 値 OS Arch Linux WM Sway (swayfx) IME fcitx5 + fcitx5-mozc ゲーム Street Fighter 6 (Steam, AppID 1364780) Proton Proton Experimental / GE-Proton11-3 当時の結論(誤り) Proton公式ビルドは意図的にXIMを無効化しており、加えてWineの新しいIME実装がキー入力を XIMサーバーまで橋渡ししていない。この二つが重なっているため、レジストリでXIMを 再有効化しても効果が出ない。Street Fighter 6固有の不具合ではなく、Wine/Proton全体に 共通する構造的な制約であり、ユーザー側の設定では解消できない。\n——これが誤りだった。 実際には環境変数がゲームの起動経路まで届いていなかっただけの可能性が高い。 詳細は末尾の追記を参照。\n当時の根拠 以下は2026-08-06時点で実際に観測した内容。観測自体は正しいが、そこから導いた結論が誤っていた。\nSway/fcitx5の設定は正常 — Ctrl+Spaceに該当するbindsymはなし、GTK_IM_MODULE/ QT_IM_MODULE/XMODIFIERSはenvironment.dで正しく設定済み、fcitx5のトリガーキーも Control+spaceのままでXIMアドオンも無効化されていない。\n後から振り返ると、ここが見落としの核心だった。 「environment.dで設定済み」であることは確認したが、 その変数がSteam経由で起動されるゲームプロセスまで届いているか は確認していなかった。\nProtonは意図的にXIMを無効化している — Proton公式リポジトリのIssueに記載がある。\nXIM is disabled for working around a X11 issue\n古いlibX11のクラッシュを避けるため、Valve配布の公式Protonはビルド時にXIMサポートを 無効化している。fcitx5はXIM経由でWineアプリと通信するため、この時点で経路が断たれる。\nレジストリでの再有効化は効果なし — 別のIssueにある回避策として、Wineのレジストリに次のキーを追加すればXIMを強制的に再有効化できるとされている。\n[HKCU\\Software\\Wine\\X11 Driver] \"UseXIM\"=\"y\" Copy WINEPREFIX=\"\" \\ \"/files/bin/wine\" reg add \\ \"HKCU\\Software\\Wine\\X11 Driver\" /v UseXIM /t REG_SZ /d y /f Copy reg query・user.regの両方でUseXIM=\u0026quot;y\u0026quot;の書き込みは確認できるが、挙動は変わらない。\nWINEDEBUGのログがキー入力の経路を示している — 同じprefixでnotepad.exeを起動し、SF6固有の 問題かどうかを切り分けた。\nWINEDEBUG=+xim,+ime,+imm wine notepad Copy notepadでも症状は同じで、SF6固有のバグではないと確認できる。ログではxic_createは成功して XICが生成されている(fcitx5との接続自体は確立している)。\n03f8:trace:xim:xic_create xim 0x..., hwnd 0x300c6 03f8:trace:xim:xic_create created XIC 0x55555d42c140 Copy ところがCtrl+Spaceを押した瞬間のログにxim系の出力は現れず、imm系だけが動く。\n03f8:trace:imm:ImeProcessKey himc 0x..., vkey 0x20 03f8:trace:imm:ime_driver_call processing vkey 0x20, scan 0x39 -\u003e 0 Copy 戻り値0は「このキーはIMEで処理しなかった」という意味で、Wineの新しいIME処理ロジックが キーを受け取った上で処理せずアプリへ素通りさせている。XIMサーバーへの接続は生きているのに、 キー入力そのものがそこまで届かない。レジストリでUseXIMを有効化しても効果がなかったのはこのためだ。\nこの検証には落とし穴があった。 wine notepad.exeは対話シェルから手動で起動しているため、 シェルの環境変数(~/.zshrc等で設定されたIME関連変数)が乗った状態で動いている。 一方、実際のゲームはSteam経由で起動される。テスト環境と本番環境が違っていた。\nfcitx5-remoteでの強制トグルも反映されない — fcitx5-remote -tでDBus経由でIME状態を 直接トグルしても、fcitx5自体の状態は変わるがWineアプリ側の入力コンテキストには反映されない。 XIMのキー処理を経由しない限り、外部からの強制トグルは意味を持たない。\nGE-Protonでも同一症状 — GE-Protonで 同じprefix・同じ手順を再検証しても結果は同じで、notepadでCtrl+Spaceを押してもxim系ログは 沈黙したまま。公式・コミュニティ両ビルドで同一の症状が出るため、特定パッチの有無ではなく Wine本体のIME実装が持つ構造的な制約と判断できる。\nWindowsネイティブ環境なら翻訳レイヤーを挟まずWindows自体のIME基盤を直接使うため、 この問題自体が発生しないはずだ(筆者の環境では未検証、推測にとどまる)。\n当時の回避策: クリップボード経由の貼り付け この節は当時の運用の記録。現在は不要になった。\nWineアプリ内での直接入力は諦め、クリップボード経由に切り替える。クリップボードの同期は IME/XIMの仕組みから独立しているため、ここだけは問題なく動く。\n別のアプリでMozcを使って日本語を入力する コピーする Street Fighter 6のウィンドウに戻り、チャット欄でCtrl+V 筆者はWaydroid上のPS AppとGboardをこの用途に使っている。Waydroid内で日本語を打ってコピーし、 ホスト側にCtrl+Vで貼り付ける経路はすでに動作を確認済み。ちなみにGboard内の言語切り替えは Ctrl+SpaceではなくShift+Spaceだった。理由はまだわかっていない。\n追記 (2026-08-08): 解決した /etc/environment に以下を追記したところ、Ctrl+Spaceでの直接入力が動作するようになった。\nGTK_IM_MODULE=fcitx QT_IM_MODULE=fcitx XMODIFIERS=@im=fcitx SDL_IM_MODULE=fcitx Copy もともとはSteam本体(ネイティブ版)でCtrl+Spaceが効かない別件を調べていて見つけた設定だが、 適用後にSF6のカスタムルームチャットでも同時に直った。Waydroid+Gboardのクリップボード運用は 不要になった。\nなぜ直ったのか(ソースで確認した) ~/.config/environment.d/ と ~/.xprofile には以前からIME関連の環境変数を設定していた。 それでも直らず、/etc/environment に書いたら直った。この違いがどこから来るのか、 実際のソースコードを読んで確認した。\n.xprofileは、そもそもWaylandセッションでは一度も読まれない。 筆者の環境は SDDM(ディスプレイマネージャ) → Sway(Waylandコンポジタ)という構成。SDDMがWaylandセッションを 起動するスクリプト本体(wayland-session、 公式ソースで中身を確認)はこうなっている。\ncase $SHELL in */bash|*/zsh) exec $SHELL --login -c 'exec \"$@\"' - $@ ;; ... Copy bash/zshの場合、ログインシェルを--loginモードで起動するだけで、.xprofileという 文字列はこのスクリプトのどこにも出てこない。.xprofileを読むのはX11向けの Xsessionスクリプトの方で、 Wayland専用のwayland-sessionには最初から実装されていない。環境変数が「届かなかった」 というより、.xprofile自体がそもそも実行されていなかった。\nSteam Linux Runtime(pressure-vessel)は、環境変数を独自にフィルタしているわけではない。 Steamが使ってるサンドボックス機構のソース(steam-runtime-tools、 git cloneして確認)、pressure-vessel/wrap-context.cにこうある。\nself-\u003eoriginal_environ = g_get_environ (); Copy g_get_environ()はGLibの関数で、呼び出し元プロセス(つまりSteam自身)が、その時点で 実際に持っている環境変数をそのままコピーする。 サンドボックスが用意する環境は、 このoriginal_environを土台に組み立てられる(pressure-vessel/wrap.cの pv_bind_and_propagate_from_environなど)。つまり仕組みとしては「Steamの環境に有れば、 サンドボックスにも伝わる」「Steamの環境に無ければ、サンドボックスにも無い」というだけで、 pressure-vessel側が能動的にIME変数を弾いているわけではなかった。\n/etc/environmentは、この両方の問題を回避できる場所にある。 PAM(pam_env)が ログインセッションを開く時点――SDDM経由でシェルが起動するよりも、Swayが立ち上がるよりも 前――に読み込まれる。Wayland/X11の違いにも、systemd \u0026ndash;userのunit起動経路にも依存しない。 この結果、Sway → (Sway経由で起動する)Steam → Steamがg_get_environ()で捕まえる環境、 という鎖が最初から繋がっていて、確実にサンドボックス内まで届く。\n~/.config/environment.d/*.confについては、systemd --userマネージャが起動時に読み込んで マネージャ自身が管理するunit用の環境として保持する仕組みで、Swayがsystemd \u0026ndash;userの unitとして起動されていない(ログインシェルから直接exec swayするような構成の)場合、 Swayやその子プロセスへ自動的に伝播するとは限らない。この部分はユーザー環境の起動設定 (どうSwayを起動しているか)に依存するため、今回はそこまでは立ち入らない。\nwine notepad.exeでXICの作成に成功していたのも、あれが対話シェル(すでに/etc/environmentや シェルの設定ファイルの変数が乗っている)から直接起動されていたためで、Steam経由の起動とは 環境が違っていた、というのも今回の調査で裏が取れた。\n教訓 同じ症状で調べている人向けに、この失敗から言えることを書いておく。\n「設定ファイルに書いてある」と「そのプロセスに届いている」は別の話。 環境変数の問題を疑うときは、 設定ファイルを読むのではなく、実際に対象プロセスの環境を見る(cat /proc/\u0026lt;pid\u0026gt;/environ | tr '\\0' '\\n')。 手動起動したテストアプリは、本番と同じ環境で動いていない可能性がある。 特にSteam/Flatpak/Snapのような サンドボックスを挟む起動経路では、対話シェルからの手動テストは再現になっていないことがある。 上流のIssueに「既知の制約」と書いてあると、そこで思考が止まりやすい。Issueの記述が自分の症状の 原因である保証はない。 調査の経緯 ","permalink":"https://america.github.io/post/sf6-proton-mozc-ime/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e訂正 (2026-08-08)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eこの記事の当初の結論「ユーザー側の設定では解消できない」は \u003cstrong\u003e誤りでした\u003c/strong\u003e。\n\u003ccode\u003e/etc/environment\u003c/code\u003e にIME環境変数を設定することで、\u003ccode\u003eCtrl+Space\u003c/code\u003e での直接入力が動作するようになりました。\n結論だけ必要な方は \u003ca href=\"/post/sf6-proton-mozc-ime/#%e8%bf%bd%e8%a8%98-2026-08-08-%e8%a7%a3%e6%b1%ba%e3%81%97%e3%81%9f\"\u003e追記: 解決した\u003c/a\u003e へ。\u003c/p\u003e\n\u003cp\u003e以下の調査記録は、当時どう考えて誤った結論に至ったかの記録として、そのまま残します。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"事象\"\u003e事象\u003c/h2\u003e\n\u003cp\u003eStreet Fighter 6のチャット欄で\u003ccode\u003eCtrl+Space\u003c/code\u003e(fcitx5のトリガーキー)を押しても、日本語入力(Mozc)に\n切り替わらない。ローマ字のまま反応しない。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e項目\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e値\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eOS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eArch Linux\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eWM\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSway (swayfx)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eIME\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003efcitx5 + fcitx5-mozc\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eゲーム\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eStreet Fighter 6 (Steam, AppID 1364780)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eProton\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eProton Experimental / GE-Proton11-3\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"当時の結論誤り\"\u003e当時の結論(誤り)\u003c/h2\u003e\n\u003cp\u003eProton公式ビルドは意図的にXIMを無効化しており、加えてWineの新しいIME実装がキー入力を\nXIMサーバーまで橋渡ししていない。この二つが重なっているため、レジストリでXIMを\n再有効化しても効果が出ない。Street Fighter 6固有の不具合ではなく、Wine/Proton全体に\n共通する構造的な制約であり、ユーザー側の設定では解消できない。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e——これが誤りだった。\u003c/strong\u003e 実際には環境変数がゲームの起動経路まで届いていなかっただけの可能性が高い。\n詳細は\u003ca href=\"/post/sf6-proton-mozc-ime/#%e8%bf%bd%e8%a8%98-2026-08-08-%e8%a7%a3%e6%b1%ba%e3%81%97%e3%81%9f\"\u003e末尾の追記\u003c/a\u003eを参照。\u003c/p\u003e\n\u003ch2 id=\"当時の根拠\"\u003e当時の根拠\u003c/h2\u003e\n\u003cp\u003e以下は2026-08-06時点で実際に観測した内容。\u003cstrong\u003e観測自体は正しいが、そこから導いた結論が誤っていた。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSway/fcitx5の設定は正常\u003c/strong\u003e — \u003ccode\u003eCtrl+Space\u003c/code\u003eに該当する\u003ccode\u003ebindsym\u003c/code\u003eはなし、\u003ccode\u003eGTK_IM_MODULE\u003c/code\u003e/\n\u003ccode\u003eQT_IM_MODULE\u003c/code\u003e/\u003ccode\u003eXMODIFIERS\u003c/code\u003eは\u003ccode\u003eenvironment.d\u003c/code\u003eで正しく設定済み、fcitx5のトリガーキーも\n\u003ccode\u003eControl+space\u003c/code\u003eのままでXIMアドオンも無効化されていない。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e後から振り返ると、\u003cstrong\u003eここが見落としの核心だった。\u003c/strong\u003e 「\u003ccode\u003eenvironment.d\u003c/code\u003eで設定済み」であることは確認したが、\n\u003cem\u003eその変数がSteam経由で起動されるゲームプロセスまで届いているか\u003c/em\u003e は確認していなかった。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eProtonは意図的にXIMを無効化している\u003c/strong\u003e — \u003ca href=\"https://github.com/ValveSoftware/Proton/issues/3641\"\u003eProton公式リポジトリのIssue\u003c/a\u003eに記載がある。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eXIM is disabled for working around a X11 issue\u003c/p\u003e","title":"Street Fighter 6 (Proton) で日本語入力ができない問題は /etc/environment のIME環境変数で解決した"},{"content":"はじめに パソコンやスマートフォンについて調べていると、次のような言葉を見かける。\nARM ARM64 AArch64 x86 x86-64 AMD64 RISC CISC Apple Silicon Snapdragon これらはすべて同じ種類の名前ではない。\nCPU製品の名前、CPUを設計する会社の名前、CPUが理解する命令体系の名前などが混在しているため、初めて見ると分かりにくい。\n結論から言えば、ARMとは主にCPUの命令セットアーキテクチャの一種である。\nまた、その技術を開発し、企業へライセンス提供している会社もArmという名前である。\nこの記事では、ARMが何を意味するのかを、x86との違い、RISCとCISC、Linuxやソフトウェアとの関係も含めて整理する。\nCPUとは何か CPUは、コンピュータの中でプログラムの命令を実行する部品である。\n正式名称は次のとおり。\nCentral Processing Unit\n中央処理装置\nCPUは、非常に単純化すると次の処理を繰り返している。\nメモリから命令を読み込む 命令の意味を解釈する 計算やデータ移動を実行する 次の命令を読み込む CPUが実行する処理には、次のようなものがある。\n数値を足す 数値を引く 数値を比較する メモリからデータを読み込む メモリへデータを書き込む 条件によって処理を分岐する 関数を呼び出す OSへ処理を依頼する ブラウザ、ゲーム、Linux、Windowsなども、最終的にはCPUが理解できる命令として実行されている。\nARMとは何か ARMは、CPUがどのような命令を理解し、どのように動作するかを定めた体系である。\nより正確には、命令セットアーキテクチャと呼ばれる。\n英語では次のように書く。\nInstruction Set Architecture\n略称はISAである。\nISAでは、例えば次のような事項が定められる。\nCPUが利用できる命令 レジスタの種類と数 数値の表現方法 メモリの指定方法 関数呼び出しの基本方式 例外や割り込みの処理方法 32ビットと64ビットの動作 CPUからソフトウェアに見える基本仕様 つまりISAは、CPUとソフトウェアの間にある約束事である。\nARMとx86では、この約束事が異なる。そのため、ARM向けに作られた機械語と、x86向けに作られた機械語は同じではない。\nARMという名前は会社も指す ARMという名前は、命令セットだけでなく、それを開発するArm社も指す。\nIntelやAMDは、自社でCPUを設計し、Intel CoreやAMD Ryzenなどの製品として販売している。\n一方、Arm社は主に次のものを他社へ提供する。\nARM命令セットを利用する権利 CPUコアの設計 GPUの設計 周辺回路の設計 開発用ソフトウェア セキュリティ関連技術 Arm社の技術を利用して、複数の企業が独自のCPUやSoCを作っている。\n代表例は次のとおり。\nAppleのAシリーズ AppleのMシリーズ QualcommのSnapdragon MediaTekのDimensity SamsungのExynos AWSのGraviton Raspberry Piに搭載されるBroadcom製SoC したがって、ARM系CPUは一つの会社が作る一種類のCPUではない。\n命令セットとは何か 人間が書いたC言語、Rust、Goなどのソースコードを、CPUはそのまま理解できない。\n例えばC言語で次のコードを書く。\nint answer = 40 + 2; Copy このコードは、コンパイラによって対象CPUが理解できる機械語へ変換される。\n同じソースコードでも、対象となるCPUによって生成される機械語が変わる。\n同じソースコード ├─ x86-64向けにコンパイル → x86-64用の機械語 └─ ARM64向けにコンパイル → ARM64用の機械語 Copy このため、x86-64向けの実行ファイルは、ARM64 CPUでは原則として直接実行できない。\n逆に、ARM64向けの実行ファイルも、x86-64 CPUでは直接実行できない。\nARMとx86の違い 現在のパソコンやスマートフォンでは、主に次のCPUアーキテクチャが使われている。\nx86-64 ARM64 RISC-V 一般的なIntel・AMD搭載PCでは、x86-64が使われる。\nスマートフォンやタブレットでは、ARM64が広く使われている。\nx86 x86は、Intelが開発したCPUを起源とする命令セットアーキテクチャである。\n名前は、初期のCPU製品である8086、80186、80286、80386、80486などの末尾に「86」が付いていたことに由来する。\nx86-64 x86-64は、従来のx86を64ビットへ拡張したものだ。\n次の名称は、基本的に同じ系統を指す。\nx86-64 x86_64 AMD64 amd64 Intel 64 x86の64ビット拡張を実用化したのはAMDである。そのため、LinuxやDockerではIntel製CPUを使っていても、アーキテクチャ名としてamd64と表示されることがある。\nARM64 ARMにも32ビット版と64ビット版がある。\n64ビットARMは、主に次の名前で呼ばれる。\nARM64 AArch64 arm64 aarch64 Linuxでuname -mを実行してaarch64と表示された場合、その環境は64ビットARMである。\nRyzen 7 5700XはARMではない AMD Ryzen 7 5700Xは、x86-64アーキテクチャのCPUである。ARMではない。\nLinuxでは、次のコマンドで確認できる。\nuname -m Copy Ryzen 7 5700Xを搭載した環境では、通常は次のように表示される。\nx86_64 Copy より詳しい情報は、次のコマンドで確認できる。\nlscpu Copy 重要な部分だけ確認するなら、次のコマンドを使える。\nlscpu | grep -E 'Architecture|Vendor ID|Model name' Copy 32ビットと64ビット ARMとx86には、32ビット版と64ビット版が存在する。\nビット数は、CPUが扱うデータの幅や、利用できるアドレス空間などに関係する。\n表記 意味 i386 32ビットx86系 i686 32ビットx86系 x86_64 64ビットx86 amd64 64ビットx86 armv7l 主に32ビットARM arm64 64ビットARM aarch64 64ビットARM ARMはなぜスマートフォンで使われるのか ARM系CPUは、長い間スマートフォンや組み込み機器で広く使われてきた。\nスマートフォンでは、次の条件が重要になる。\nバッテリーを長持ちさせる 発熱を抑える 小さな筐体に収める 待機中の電力消費を抑える CPU以外の機能も一つのチップへまとめる デスクトップPCなら大型のヒートシンクや冷却ファンを搭載できるが、スマートフォンでは冷却能力もバッテリー容量も限られている。\nそのため、電力効率を重視して発展してきたARM系CPUが広く採用された。\nただし、ARMだから必ず省電力になるわけではない。実際の消費電力は、CPU内部の設計、製造技術、クロック周波数、コア数、冷却などにも左右される。\nARMはRISC系アーキテクチャ ARMは一般に、RISC系の命令セットアーキテクチャと説明される。\nRISCは次の略称である。\nReduced Instruction Set Computer\nRISCでは、比較的単純で規則的な命令を組み合わせて処理するという考え方が重視される。\n典型的な特徴として、次のものがある。\n命令形式が比較的規則的 命令の長さが一定であることが多い レジスタを積極的に利用する 計算とメモリアクセスを分ける パイプライン処理を行いやすい CPU内部の設計を整理しやすい ただし、RISCを単純に「命令数が少ないCPU」と理解するのは正確ではない。現在のARMには多数の命令や拡張機能がある。\nx86はCISC系アーキテクチャ x86は一般に、CISC系の命令セットアーキテクチャと説明される。\nCISCは次の略称である。\nComplex Instruction Set Computer\nCISCでは、一つの命令で比較的複雑な処理を実行できるようにする考え方がある。\nx86には長い歴史の中で新しい機能が追加され続けてきた。その結果、現在のx86-64は非常に大きく複雑な命令セットになっている。\n現代ではRISCとCISCの境界は単純ではない ARMはRISC、x86はCISCと分類されるが、現代の高性能CPUをこの違いだけで説明することはできない。\n現代のx86 CPUは、複雑なx86命令をCPU内部でより単純な処理へ分解して実行する。\nx86命令 ↓ 命令を解析 ↓ 内部の単純な命令へ分解 ↓ 複数の実行ユニットで処理 Copy 一方、現代のARM CPUも内部構造は非常に複雑であり、次のような機能を持つ。\n分岐予測 投機実行 アウト・オブ・オーダー実行 複数命令の同時実行 大容量キャッシュ ベクトル演算 高度な電力管理 そのため、RISCだから単純で遅い、CISCだから複雑で速い、という理解は正しくない。\nレジスタとは何か レジスタは、CPU内部にある高速な一時記憶領域である。\nCPUは、計算対象のデータをレジスタへ読み込み、レジスタ上で計算する。\nメモリから数値Aをレジスタへ読み込む メモリから数値Bをレジスタへ読み込む レジスタ上で数値Aと数値Bを足す 結果をメモリへ書き戻す Copy レジスタはメインメモリより高速だが、容量は小さく、個数も限られている。\nARMのLoad/Store方式 ARMはLoad/Store型のアーキテクチャである。\nこれは、メモリへアクセスする命令と、計算を行う命令を分ける方式だ。\nLOAD レジスタ1, メモリ上の数値A LOAD レジスタ2, メモリ上の数値B ADD レジスタ3, レジスタ1, レジスタ2 STORE メモリ上の保存先, レジスタ3 Copy まずメモリからレジスタへ読み込み、レジスタ上で計算し、最後に結果をメモリへ戻す。\nSoCとは何か ARMの話では、SoCという言葉もよく使われる。\nSoCは次の略称である。\nSystem on a Chip\nSoCとは、コンピュータに必要な複数の機能を一つのチップへ統合したものだ。\nスマートフォン向けSoCには、例えば次の機能が含まれる。\nCPU GPU メモリコントローラー AI処理装置 動画処理回路 カメラ用画像処理回路 通信機能 セキュリティ機能 ストレージ制御機能 Apple MシリーズやQualcomm Snapdragonは、CPUだけではなくSoCである。\nApple SiliconとARM Apple Siliconは、Appleが設計するSoCの総称である。\nMacに搭載されるMシリーズは、ARM64系の命令セットを採用している。\nただし、AppleはArm社の完成済みCPUコアをそのまま使っているわけではない。ARM命令セットと互換性を持つCPUコアを独自に設計している。\nApple Siliconの電力効率が高い理由は、ARM命令セットだけではない。\nApple独自のCPU設計 高性能コアと高効率コア macOSとの最適化 統合メモリアーキテクチャ 専用処理回路 電力管理 製造プロセス これらが組み合わさっている。\nARM版Windows WindowsにはARM64版が存在する。\nARM版Windowsでは、主に次の種類のアプリを利用する。\nARM64向けに作られたアプリ 変換またはエミュレーションで動作するx86アプリ 変換またはエミュレーションで動作するx86-64アプリ x86向けの既存ソフトを動かせる場合もあるが、完全な互換性が保証されるわけではない。\n特に次の種類のソフトウェアでは問題が起こる可能性がある。\n古いデバイスドライバ 特殊な周辺機器用ソフト カーネルへ深く関わるソフト アンチチートを使うゲーム 一部の仮想化ソフト 特定のx86命令へ依存するソフト LinuxとARM Linuxカーネルは、ARMを含む複数のCPUアーキテクチャに対応している。\nARM版Linuxは、次のような機器で使われている。\nRaspberry Pi Android端末 Chromebook ARMサーバー ルーター NAS IoT機器 組み込み機器 Apple Silicon搭載Mac ただし、LinuxがARMに対応していても、x86-64向けの実行ファイルがそのまま動くわけではない。\nArch LinuxとARM 通常のArch Linuxは、主にx86-64向けに提供されている。\nARM機器向けには、Arch Linux ARMという別プロジェクトが存在する。\n名前は似ているが、通常のArch Linux本体とは提供体制が異なる。\nx86-64用のArch LinuxパッケージをARM64環境へコピーしても、原則として実行できない。\nGentooとARM Gentooは複数のCPUアーキテクチャに対応している。\nx86-64だけでなくARM64向け環境も構築できる。\nGentooでは多くのソフトウェアをソースコードからビルドするため、対象CPUに合わせてコンパイルできる。\nただし、ソースコードや依存ライブラリがARMへ対応していない場合は、ビルドできないこともある。\nARMでx86向けソフトを動かす方法 ARMとx86では機械語が異なるため、x86向け実行ファイルはARMでは原則として直接実行できない。\n主な方法は次のとおり。\nARM版を利用する ソフトウェアのARM64版が提供されている場合は、それを利用する。\nARM向けに再コンパイルする ソースコードが公開されている場合、ARM64向けにビルドできることがある。\nエミュレーターを利用する QEMUなどを使い、別のCPUアーキテクチャを再現する。ただし、処理速度が低下する場合がある。\nバイナリ変換を利用する 別のCPU向け命令を、実行可能な命令へ変換する。\nAppleのRosetta 2は代表例である。\nDockerとARM DockerでもCPUアーキテクチャの違いは重要である。\nDockerコンテナはホストのカーネルを共有するため、コンテナ内の実行ファイルは基本的にホストCPUへ対応している必要がある。\nARM64マシンでは、ARM64向けDockerイメージを使うのが基本となる。\n現在のDocker環境のアーキテクチャは、次のコマンドで確認できる。\ndocker info --format '{{.Architecture}}' Copy コンテナ内で確認するなら、次のように実行できる。\ndocker run --rm alpine uname -m Copy AndroidとARM Android端末の多くはARM系SoCを搭載している。\nAndroidアプリの中には、CやC++で作られたネイティブコードを含むものがある。ネイティブコードはCPUアーキテクチャごとに用意する必要がある。\nAndroidでは、次のようなABI名が使われる。\narmeabi-v7a arm64-v8a x86 x86_64 近年のAndroid端末では、arm64-v8aが中心である。\nRaspberry PiとARM Raspberry Piは、小型のシングルボードコンピュータである。\n多くのRaspberry PiにはARM系SoCが搭載されている。そのため、一般的なx86-64版Linuxをそのまま使うことはできない。\n主な用途には次のものがある。\nLinuxの学習 プログラミング 小型サーバー 電子工作 自宅用NAS DNSサーバー 監視カメラ ホームオートメーション ARMサーバー ARMはスマートフォン専用のアーキテクチャではない。\n現在ではサーバーにも利用されている。\nARMサーバーに期待される利点には、次のものがある。\n電力効率 多コア化 発熱の抑制 サーバーの高密度化 特定用途への最適化 クラウド事業者による独自設計 一方で、x86-64向けにしか提供されていないソフトウェアでは、移行が難しい場合もある。\nbig.LITTLEとは何か ARM系SoCでは、性能の異なるCPUコアを組み合わせる設計が広く使われている。\n高性能なコア 電力効率を重視したコア 重い処理では高性能コアを使い、軽い処理や待機時には高効率コアを使う。\nこれにより、性能と消費電力の両立を目指す。\n同様の考え方はApple Siliconや近年のIntel製CPUでも採用されている。\nARMの長所 ARM系CPUの一般的な長所として、次の点が挙げられる。\n電力効率を重視した製品が多い SoCへ統合しやすい 多数の企業が製品を設計できる 小型機器からサーバーまで用途が広い 自社製品に合わせた独自最適化が可能 ARMの短所 ARMにも弱点がある。\nx86向けソフトとの互換性 ARM版ドライバがない周辺機器 ゲームやアンチチートとの互換性 製品ごとの性能差が大きい 組み込み機器では機種ごとに起動方法が異なる場合がある ARMは性能を表す製品名ではない。低性能なARM製品も、高性能なARM製品も存在する。\nx86-64の長所 x86-64には、長年のパソコン市場で蓄積された強みがある。\nWindows向けソフトが豊富 PCゲームとの互換性が高い 周辺機器のドライバが多い Linux対応が成熟している 自作PC向け製品が豊富 仮想化環境が充実している 過去のソフトウェアとの互換性が高い ARMとRISC-Vの違い RISC-VもRISC系の命令セットアーキテクチャである。\nARMとの大きな違いの一つは、命令セットのライセンス方式だ。\nARMを利用する企業は、通常Arm社からライセンスを受ける。\nRISC-Vの基本命令セットは、比較的自由に利用できるオープンな仕様として提供されている。\nただし、ARMとRISC-Vは別の命令セットであり、ARM向けの実行ファイルがRISC-Vでそのまま動くわけではない。\nARMだから速いとは限らない ARMという名前だけでは、CPUの性能は判断できない。\n性能は次の要素に左右される。\nCPUコアの内部設計 クロック周波数 コア数 キャッシュ容量 メモリ性能 製造プロセス 消費電力の上限 冷却性能 OSの最適化 コンパイラの最適化 実行するソフトウェア したがって、ARMはx86より速い、あるいはx86はARMより速い、と一律には言えない。\nLinuxでCPUアーキテクチャを確認する unameコマンド uname -m Copy x86-64の場合。\nx86_64 Copy ARM64の場合。\naarch64 Copy lscpuコマンド lscpu Copy 必要な項目だけ表示する。\nlscpu | grep -E 'Architecture|Vendor ID|Model name|CPU\\(s\\)' Copy GCCの対象アーキテクチャ gcc -dumpmachine Copy x86-64の例。\nx86_64-pc-linux-gnu Copy ARM64の例。\naarch64-linux-gnu Copy 実行ファイルのアーキテクチャ file /usr/bin/bash Copy x86-64環境の例。\nELF 64-bit LSB pie executable, x86-64 Copy ARM64環境の例。\nELF 64-bit LSB pie executable, ARM aarch64 Copy ARMを理解するための要点 ARMはCPUの命令セットアーキテクチャの一つ ARMは一個のCPU製品名ではない Arm社はCPU設計技術を企業へライセンス提供している AppleやQualcommなどがARM系CPUやSoCを設計している ARM64はAArch64とも呼ばれる スマートフォンではARM系SoCが主流 一般的なIntel・AMD搭載PCはx86-64が主流 ARMとx86では理解する機械語が異なる x86向け実行ファイルはARMでは原則として直接動かない ARMだから必ず速い、省電力、安価というわけではない まとめ ARMは、CPUが理解する命令や、ソフトウェアから見えるCPUの基本動作を定めた命令セットアーキテクチャである。\nスマートフォンや組み込み機器で広く普及し、現在ではパソコンやサーバーにも利用範囲を広げている。\n一方、一般的なIntel・AMD搭載PCでは、x86-64が主流である。\nARMとx86の違いは、単なるCPUメーカーの違いではない。CPUが理解する機械語そのものが異なる。\nAMD Ryzen 7 5700XはARMではなく、x86-64アーキテクチャのCPUである。\nLinuxでは次のコマンドで確認できる。\nuname -m Copy 表示結果がx86_64ならx86-64、aarch64ならARM64である。\nARMはスマートフォン専用の低性能CPUではない。小型の制御装置からスマートフォン、パソコン、サーバーまで使われる、現代の主要なCPUアーキテクチャの一つである。\n","permalink":"https://america.github.io/post/2026-07-19-arm-architecture/","summary":"\u003ch2 id=\"はじめに\"\u003eはじめに\u003c/h2\u003e\n\u003cp\u003eパソコンやスマートフォンについて調べていると、次のような言葉を見かける。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eARM\u003c/li\u003e\n\u003cli\u003eARM64\u003c/li\u003e\n\u003cli\u003eAArch64\u003c/li\u003e\n\u003cli\u003ex86\u003c/li\u003e\n\u003cli\u003ex86-64\u003c/li\u003e\n\u003cli\u003eAMD64\u003c/li\u003e\n\u003cli\u003eRISC\u003c/li\u003e\n\u003cli\u003eCISC\u003c/li\u003e\n\u003cli\u003eApple Silicon\u003c/li\u003e\n\u003cli\u003eSnapdragon\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこれらはすべて同じ種類の名前ではない。\u003c/p\u003e\n\u003cp\u003eCPU製品の名前、CPUを設計する会社の名前、CPUが理解する命令体系の名前などが混在しているため、初めて見ると分かりにくい。\u003c/p\u003e\n\u003cp\u003e結論から言えば、\u003cstrong\u003eARMとは主にCPUの命令セットアーキテクチャの一種\u003c/strong\u003eである。\u003c/p\u003e\n\u003cp\u003eまた、その技術を開発し、企業へライセンス提供している会社もArmという名前である。\u003c/p\u003e\n\u003cp\u003eこの記事では、ARMが何を意味するのかを、x86との違い、RISCとCISC、Linuxやソフトウェアとの関係も含めて整理する。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"cpuとは何か\"\u003eCPUとは何か\u003c/h2\u003e\n\u003cp\u003eCPUは、コンピュータの中でプログラムの命令を実行する部品である。\u003c/p\u003e\n\u003cp\u003e正式名称は次のとおり。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eCentral Processing Unit\u003cbr\u003e\n中央処理装置\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eCPUは、非常に単純化すると次の処理を繰り返している。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eメモリから命令を読み込む\u003c/li\u003e\n\u003cli\u003e命令の意味を解釈する\u003c/li\u003e\n\u003cli\u003e計算やデータ移動を実行する\u003c/li\u003e\n\u003cli\u003e次の命令を読み込む\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCPUが実行する処理には、次のようなものがある。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e数値を足す\u003c/li\u003e\n\u003cli\u003e数値を引く\u003c/li\u003e\n\u003cli\u003e数値を比較する\u003c/li\u003e\n\u003cli\u003eメモリからデータを読み込む\u003c/li\u003e\n\u003cli\u003eメモリへデータを書き込む\u003c/li\u003e\n\u003cli\u003e条件によって処理を分岐する\u003c/li\u003e\n\u003cli\u003e関数を呼び出す\u003c/li\u003e\n\u003cli\u003eOSへ処理を依頼する\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eブラウザ、ゲーム、Linux、Windowsなども、最終的にはCPUが理解できる命令として実行されている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"armとは何か\"\u003eARMとは何か\u003c/h2\u003e\n\u003cp\u003eARMは、CPUがどのような命令を理解し、どのように動作するかを定めた体系である。\u003c/p\u003e\n\u003cp\u003eより正確には、\u003cstrong\u003e命令セットアーキテクチャ\u003c/strong\u003eと呼ばれる。\u003c/p\u003e\n\u003cp\u003e英語では次のように書く。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eInstruction Set Architecture\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e略称はISAである。\u003c/p\u003e\n\u003cp\u003eISAでは、例えば次のような事項が定められる。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCPUが利用できる命令\u003c/li\u003e\n\u003cli\u003eレジスタの種類と数\u003c/li\u003e\n\u003cli\u003e数値の表現方法\u003c/li\u003e\n\u003cli\u003eメモリの指定方法\u003c/li\u003e\n\u003cli\u003e関数呼び出しの基本方式\u003c/li\u003e\n\u003cli\u003e例外や割り込みの処理方法\u003c/li\u003e\n\u003cli\u003e32ビットと64ビットの動作\u003c/li\u003e\n\u003cli\u003eCPUからソフトウェアに見える基本仕様\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eつまりISAは、\u003cstrong\u003eCPUとソフトウェアの間にある約束事\u003c/strong\u003eである。\u003c/p\u003e\n\u003cp\u003eARMとx86では、この約束事が異なる。そのため、ARM向けに作られた機械語と、x86向けに作られた機械語は同じではない。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"armという名前は会社も指す\"\u003eARMという名前は会社も指す\u003c/h2\u003e\n\u003cp\u003eARMという名前は、命令セットだけでなく、それを開発するArm社も指す。\u003c/p\u003e\n\u003cp\u003eIntelやAMDは、自社でCPUを設計し、Intel CoreやAMD Ryzenなどの製品として販売している。\u003c/p\u003e\n\u003cp\u003e一方、Arm社は主に次のものを他社へ提供する。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eARM命令セットを利用する権利\u003c/li\u003e\n\u003cli\u003eCPUコアの設計\u003c/li\u003e\n\u003cli\u003eGPUの設計\u003c/li\u003e\n\u003cli\u003e周辺回路の設計\u003c/li\u003e\n\u003cli\u003e開発用ソフトウェア\u003c/li\u003e\n\u003cli\u003eセキュリティ関連技術\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eArm社の技術を利用して、複数の企業が独自のCPUやSoCを作っている。\u003c/p\u003e","title":"ARMとは何か？CPU・x86・RISCとの違いを詳しく解説"},{"content":"設備投資と実質賃金、カーボンニュートラル税制、日米関税交渉をめぐる国会質疑 国会質疑では、日本の設備投資と実質賃金の低迷、カーボンニュートラル投資促進税制、太陽光発電への税制優遇、米国の対日関税などが取り上げられた。\n質疑全体を通して、日本企業の国内投資を増やし、賃金上昇につなげる政策の必要性と、脱炭素政策や対米通商政策の妥当性が議論された。\n※以下は提供された文字起こしをもとに内容を整理した要約。固有名詞や一部の数値は、音声認識の誤変換を含む可能性がある。\n日本は設備投資も実質賃金も低い 質疑では、主要国の「実質民間設備投資の年平均増減率」と「実質賃金の年平均増減率」を比較したグラフが示された。\n紹介された数値は、おおむね次のとおり。\nアメリカ 設備投資：約4.5％ 実質賃金：約1.4％ 韓国 設備投資：約3.8％ 実質賃金：約2.1％ 日本 設備投資：ほぼ0％ 実質賃金：約0.2％ 日本は比較対象国の中で、設備投資と実質賃金の双方が最も低い位置にあると指摘された。\nなぜ設備投資が増えると賃金も上がるのか 経済産業省は、国内投資の増加が賃金上昇につながる理由を次のように説明した。\n企業が国内投資を拡大する 生産能力の増強や新市場の獲得につながる イノベーションによって付加価値の高い製品やサービスが生まれる 企業収益が増える 賃上げの原資が拡大する 物価上昇を上回る持続的な賃上げを実現するためにも、国内投資の拡大が重要だという認識が示された。\n投資促進税制と積極財政 質問者は、設備投資を増やして実質賃金の上昇につなげるため、投資促進税制が有効だと主張した。\nさらに、次のような施策を提案した。\n防災を含むインフラ整備を積極財政で進める 国内需要を喚起する コーポレートガバナンス・コードを見直す 企業が長期投資を行いやすい環境を作る 株主配当を増やす場合には、賃金も同時に引き上げる仕組みを検討する 経済産業大臣は、日本企業では株主還元が増えている一方、賃上げを含む成長投資は欧米と比べて低い水準にあると説明した。\n政府は、17の戦略分野で予算、税制、政府調達、防衛調達、規制・制度改革などを組み合わせ、企業の「稼ぐ力」と持続的な賃上げを後押しする方針を示した。\nカーボンニュートラル投資促進税制とは この制度は、企業が生産工程の脱炭素化と付加価値向上を同時に進める設備投資を支援するもの。\n政府答弁で示された実績は次のとおり。\n累計適用件数：168件 特別償却の適用額：約100億円台 税額控除：約163億円 設備投資額：約1,820億円 認定件数の約7割：製造業 適用額が大きい設備として、工場のボイラー、コージェネレーションシステム、太陽光発電設備などが挙げられた。\n税制の期限が延長された理由 カーボンニュートラル投資促進税制は、令和10年3月31日まで延長された。\n経済産業省は、延長理由について次のように説明した。\n2050年カーボンニュートラルの実現に向け、企業投資をさらに加速する必要がある これまでの適用実績と効果分析を踏まえた 個々の企業だけでなく、サプライチェーン全体の脱炭素化を促す 大企業による中小企業の排出削減支援にもインセンティブを与える 太陽光発電への二重支援ではないか 質問者は、太陽光発電設備について次の問題を指摘した。\nFIT・FIP制度によって収益が支えられている その財源の一部は、国民の電気料金に上乗せされる再エネ賦課金である さらに税額控除も受けられる 支援制度と税制優遇の双方を受けることに、国民の理解が得られるのか疑問がある 税制の期限延長が十分に知られていない 経済産業大臣は、個別分野ごとの支援制度を細かく考慮すると制度が複雑になり、申請コストが増えると説明した。\n米国の対日関税 政府答弁では、2025年の米国による対日輸入額と、主な対象分野の金額が示された。\n対日輸入総額：約1,600億ドル 鉄鋼・鉄鋼派生品：約160億ドル アルミ・アルミ派生品：約40億ドル 自動車・自動車部品：約515億ドル 特に自動車関連の割合が大きく、自動車関税を抑えることの重要性が確認された。\n米国の関税措置は今後どうなるのか 質疑では、米国の関税措置をめぐる法的根拠の変化も取り上げられた。\nIEEPAに基づく相互関税に違憲・違法判断が出た 通商法122条に基づく一律関税へ切り替えられた 122条関税についても違法判断が出た 米政権は通商法301条への切り替えを検討している 過剰生産能力や強制労働を理由に追加関税を課す可能性がある 日本も301条調査の対象国に含まれているとされる。\n日本政府は、構造的な過剰生産能力は存在しないこと、日本企業に国際基準に沿った人権対応を求めていること、既存の日米合意を着実に履行するよう求めていることを説明した。\nまとめ 今回の質疑では、主に次の問題が議論された。\n日本は設備投資と実質賃金の伸びが主要国より低い 設備投資の拡大は企業収益と賃上げの好循環につながる 株主還元に偏らず、人材・設備への長期投資を増やす必要がある カーボンニュートラル投資促進税制は、製造業を中心に利用されている 太陽光発電への税制優遇とFIT・FIP制度の併用には疑問が示された 米国の関税措置は法的根拠や対象が変化しており、先行きが不透明である 日本政府には、状況の変化に応じた交渉カードを準備することが求められる 設備投資、賃金、脱炭素、税制、関税は別々の問題に見えるが、いずれも日本企業の競争力と国民生活に直結している。\n","permalink":"https://america.github.io/post/2026-07-16-capital-investment-real-wages-carbon-neutral-tax-us-tariffs/","summary":"\u003ch1 id=\"設備投資と実質賃金カーボンニュートラル税制日米関税交渉をめぐる国会質疑\"\u003e設備投資と実質賃金、カーボンニュートラル税制、日米関税交渉をめぐる国会質疑\u003c/h1\u003e\n\u003cp\u003e国会質疑では、日本の設備投資と実質賃金の低迷、カーボンニュートラル投資促進税制、太陽光発電への税制優遇、米国の対日関税などが取り上げられた。\u003c/p\u003e\n\u003cp\u003e質疑全体を通して、日本企業の国内投資を増やし、賃金上昇につなげる政策の必要性と、脱炭素政策や対米通商政策の妥当性が議論された。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e※以下は提供された文字起こしをもとに内容を整理した要約。固有名詞や一部の数値は、音声認識の誤変換を含む可能性がある。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"日本は設備投資も実質賃金も低い\"\u003e日本は設備投資も実質賃金も低い\u003c/h2\u003e\n\u003cp\u003e質疑では、主要国の「実質民間設備投資の年平均増減率」と「実質賃金の年平均増減率」を比較したグラフが示された。\u003c/p\u003e\n\u003cp\u003e紹介された数値は、おおむね次のとおり。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eアメリカ\n\u003cul\u003e\n\u003cli\u003e設備投資：約4.5％\u003c/li\u003e\n\u003cli\u003e実質賃金：約1.4％\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e韓国\n\u003cul\u003e\n\u003cli\u003e設備投資：約3.8％\u003c/li\u003e\n\u003cli\u003e実質賃金：約2.1％\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e日本\n\u003cul\u003e\n\u003cli\u003e設備投資：ほぼ0％\u003c/li\u003e\n\u003cli\u003e実質賃金：約0.2％\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e日本は比較対象国の中で、設備投資と実質賃金の双方が最も低い位置にあると指摘された。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"なぜ設備投資が増えると賃金も上がるのか\"\u003eなぜ設備投資が増えると賃金も上がるのか\u003c/h2\u003e\n\u003cp\u003e経済産業省は、国内投資の増加が賃金上昇につながる理由を次のように説明した。\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e企業が国内投資を拡大する\u003c/li\u003e\n\u003cli\u003e生産能力の増強や新市場の獲得につながる\u003c/li\u003e\n\u003cli\u003eイノベーションによって付加価値の高い製品やサービスが生まれる\u003c/li\u003e\n\u003cli\u003e企業収益が増える\u003c/li\u003e\n\u003cli\u003e賃上げの原資が拡大する\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e物価上昇を上回る持続的な賃上げを実現するためにも、国内投資の拡大が重要だという認識が示された。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"投資促進税制と積極財政\"\u003e投資促進税制と積極財政\u003c/h2\u003e\n\u003cp\u003e質問者は、設備投資を増やして実質賃金の上昇につなげるため、投資促進税制が有効だと主張した。\u003c/p\u003e\n\u003cp\u003eさらに、次のような施策を提案した。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e防災を含むインフラ整備を積極財政で進める\u003c/li\u003e\n\u003cli\u003e国内需要を喚起する\u003c/li\u003e\n\u003cli\u003eコーポレートガバナンス・コードを見直す\u003c/li\u003e\n\u003cli\u003e企業が長期投資を行いやすい環境を作る\u003c/li\u003e\n\u003cli\u003e株主配当を増やす場合には、賃金も同時に引き上げる仕組みを検討する\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e経済産業大臣は、日本企業では株主還元が増えている一方、賃上げを含む成長投資は欧米と比べて低い水準にあると説明した。\u003c/p\u003e\n\u003cp\u003e政府は、17の戦略分野で予算、税制、政府調達、防衛調達、規制・制度改革などを組み合わせ、企業の「稼ぐ力」と持続的な賃上げを後押しする方針を示した。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"カーボンニュートラル投資促進税制とは\"\u003eカーボンニュートラル投資促進税制とは\u003c/h2\u003e\n\u003cp\u003eこの制度は、企業が生産工程の脱炭素化と付加価値向上を同時に進める設備投資を支援するもの。\u003c/p\u003e\n\u003cp\u003e政府答弁で示された実績は次のとおり。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e累計適用件数：168件\u003c/li\u003e\n\u003cli\u003e特別償却の適用額：約100億円台\u003c/li\u003e\n\u003cli\u003e税額控除：約163億円\u003c/li\u003e\n\u003cli\u003e設備投資額：約1,820億円\u003c/li\u003e\n\u003cli\u003e認定件数の約7割：製造業\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e適用額が大きい設備として、工場のボイラー、コージェネレーションシステム、太陽光発電設備などが挙げられた。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"税制の期限が延長された理由\"\u003e税制の期限が延長された理由\u003c/h2\u003e\n\u003cp\u003eカーボンニュートラル投資促進税制は、令和10年3月31日まで延長された。\u003c/p\u003e\n\u003cp\u003e経済産業省は、延長理由について次のように説明した。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e2050年カーボンニュートラルの実現に向け、企業投資をさらに加速する必要がある\u003c/li\u003e\n\u003cli\u003eこれまでの適用実績と効果分析を踏まえた\u003c/li\u003e\n\u003cli\u003e個々の企業だけでなく、サプライチェーン全体の脱炭素化を促す\u003c/li\u003e\n\u003cli\u003e大企業による中小企業の排出削減支援にもインセンティブを与える\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"太陽光発電への二重支援ではないか\"\u003e太陽光発電への二重支援ではないか\u003c/h2\u003e\n\u003cp\u003e質問者は、太陽光発電設備について次の問題を指摘した。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFIT・FIP制度によって収益が支えられている\u003c/li\u003e\n\u003cli\u003eその財源の一部は、国民の電気料金に上乗せされる再エネ賦課金である\u003c/li\u003e\n\u003cli\u003eさらに税額控除も受けられる\u003c/li\u003e\n\u003cli\u003e支援制度と税制優遇の双方を受けることに、国民の理解が得られるのか疑問がある\u003c/li\u003e\n\u003cli\u003e税制の期限延長が十分に知られていない\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e経済産業大臣は、個別分野ごとの支援制度を細かく考慮すると制度が複雑になり、申請コストが増えると説明した。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"米国の対日関税\"\u003e米国の対日関税\u003c/h2\u003e\n\u003cp\u003e政府答弁では、2025年の米国による対日輸入額と、主な対象分野の金額が示された。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e対日輸入総額：約1,600億ドル\u003c/li\u003e\n\u003cli\u003e鉄鋼・鉄鋼派生品：約160億ドル\u003c/li\u003e\n\u003cli\u003eアルミ・アルミ派生品：約40億ドル\u003c/li\u003e\n\u003cli\u003e自動車・自動車部品：約515億ドル\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e特に自動車関連の割合が大きく、自動車関税を抑えることの重要性が確認された。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"米国の関税措置は今後どうなるのか\"\u003e米国の関税措置は今後どうなるのか\u003c/h2\u003e\n\u003cp\u003e質疑では、米国の関税措置をめぐる法的根拠の変化も取り上げられた。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIEEPAに基づく相互関税に違憲・違法判断が出た\u003c/li\u003e\n\u003cli\u003e通商法122条に基づく一律関税へ切り替えられた\u003c/li\u003e\n\u003cli\u003e122条関税についても違法判断が出た\u003c/li\u003e\n\u003cli\u003e米政権は通商法301条への切り替えを検討している\u003c/li\u003e\n\u003cli\u003e過剰生産能力や強制労働を理由に追加関税を課す可能性がある\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e日本も301条調査の対象国に含まれているとされる。\u003c/p\u003e","title":"設備投資と実質賃金、カーボンニュートラル税制、日米関税交渉をめぐる国会質疑"},{"content":" 要約元\nタイトル：人口が減っていく日本で何をするか？台湾有事・サプライチェーン・人材の偏り…ホリエモンが若者に伝えたいこと チャンネル：堀江貴文 ホリエモン 公開日：2024-10-03 ホリエモン（堀江貴文氏）が、日本社会の変化について語った講演を要約する。\n内容は人口減少だけではなく、AI、半導体、建設業、教育など幅広いテーマに及んでいる。\n日本は深刻な人手不足の時代に入っている ホリエモンが語る「日本の人手不足・AI・人口減少」の未来 ホリエモン（堀江貴文氏）が、日本社会の変化について語った講演を要約する。\n内容は人口減少だけではなく、AI、半導体、建設業、教育など幅広いテーマに及んでいる。\n日本は深刻な人手不足の時代に入っている ホリエモンは、日本ではすでに「仕事がない」のではなく、「人がいない」時代になっていると説明する。\n特に不足している職種として次のような例を挙げている。\n建設業 測量 建築 半導体関連 インフラ整備 一方で、事務職などのホワイトカラーは余り始めているという見方を示している。\n半導体工場が建設ラッシュを生んでいる 熊本のTSMC工場やラピダスなど、国内で半導体工場の建設が相次いでいる背景として、次の要因を挙げている。\n台湾有事への備え コロナ禍で起きた半導体不足 サプライチェーンの見直し これらにより建設需要が急増し、建設業界では人材不足と賃金上昇が起きているという。\nサプライチェーンの重要性 現代の製品は、多くの企業が連携して作られている。\n例えば\n自動車 半導体 ロケット などは、一社でも部品供給が止まれば全体が止まってしまう。\nウクライナ戦争や新型コロナによって、その脆弱さが明らかになったと説明している。\nAIによって減る仕事 ホリエモンは、生成AIやCopilotの普及により、\nExcel作業 Word作成 書類整理 一般的な事務仕事 などはAIが代替していくと予想している。\nその結果、ホワイトカラーの需要は減少していくという見方を示した。\n逆に不足する仕事 一方で、AIでは代替しにくい仕事として、\n建設 測量 建築士 インフラ保守 などは今後も人材不足が続くと述べている。\n人口減少はさらに加速する 団塊世代、さらにその子どもである団塊ジュニア世代の高齢化によって、日本の人口減少はさらに加速すると予想している。\n現在約1億2千万人の人口も、将来的には\n1億人未満 8000万人 7000万人 まで減少する可能性があるという見方を示した。\nコンパクトシティ化は避けられない 人口減少によって\n道路 橋 上下水道 地方インフラ を維持することが難しくなる。\nそのため、住民が都市部へ集まり、生活圏を集約する「コンパクトシティ化」が進むと予想している。\n海外を見ることの重要性 ホリエモンは、日本だけを見ていると変化に気づきにくいと話す。\n東南アジアなどでは、\n人口増加 経済成長 活気 があり、日本との違いを実感できるという。\n海外へ行き、視野を広げることを勧めている。\nインバウンドには期待している 日本は海外から人気があり、\n観光 食文化 SNSでの情報発信 などの影響で、外国人観光客は今後さらに増える可能性があるとしている。\n不登校についての考え 「中学校3年間不登校だったことは将来不利か」という質問に対しては、\n強みでも弱みでもない 社会で重要なのは自分で学ぶ力 という考えを示した。\n教育への考え ホリエモンは義務教育について、\n暗記中心教育は時代遅れ ChatGPT時代は調べる能力が重要 義務教育には歴史的な役割がある といった持論を展開している。\n※これらはホリエモン個人の見解であり、学術的な定説を示すものではない。\n大学について ホリエモンは、\n大学は本来、優秀な人同士が議論する場所だった インターネットやAIによって学ぶ環境は大きく変わった 自分で学べる人は大学に依存する必要は少ない という考えを述べている。\nまた、今後は\n建築 測量 技術職 など、需要の高い専門職を目指す選択肢もあるとしている。\n※これもホリエモン個人の意見であり、大学教育全体を評価した結論ではない。\nまとめ 今回の講演では、日本社会の変化として次のような点が語られていた。\n人口減少は今後さらに加速する 建設業や半導体関連では人手不足が深刻 AIによって事務職は減少する可能性がある サプライチェーンの重要性はさらに高まる 海外へ目を向けることが重要 自分で学び続ける力がこれまで以上に求められる 人口減少とAIという二つの大きな変化を前提に、自分の働き方や学び方を考える必要がある、というのが講演全体を通したメッセージだった。\n","permalink":"https://america.github.io/post/2026-07-15-horiemon-japan-ai-labor-future/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e要約元\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eタイトル\u003c/strong\u003e：\u003ca href=\"https://www.youtube.com/watch?v=H-s4r4ik8q8\"\u003e人口が減っていく日本で何をするか？台湾有事・サプライチェーン・人材の偏り…ホリエモンが若者に伝えたいこと\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eチャンネル\u003c/strong\u003e：堀江貴文 ホリエモン\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e公開日\u003c/strong\u003e：2024-10-03\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eホリエモン（堀江貴文氏）が、日本社会の変化について語った講演を要約する。\u003c/p\u003e\n\u003cp\u003e内容は人口減少だけではなく、AI、半導体、建設業、教育など幅広いテーマに及んでいる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"日本は深刻な人手不足の時代に入っている\"\u003e日本は深刻な人手不足の時代に入っている\u003c/h2\u003e\n\u003ch1 id=\"ホリエモンが語る日本の人手不足ai人口減少の未来\"\u003eホリエモンが語る「日本の人手不足・AI・人口減少」の未来\u003c/h1\u003e\n\u003cp\u003eホリエモン（堀江貴文氏）が、日本社会の変化について語った講演を要約する。\u003c/p\u003e\n\u003cp\u003e内容は人口減少だけではなく、AI、半導体、建設業、教育など幅広いテーマに及んでいる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"日本は深刻な人手不足の時代に入っている-1\"\u003e日本は深刻な人手不足の時代に入っている\u003c/h1\u003e\n\u003cp\u003eホリエモンは、日本ではすでに「仕事がない」のではなく、「人がいない」時代になっていると説明する。\u003c/p\u003e\n\u003cp\u003e特に不足している職種として次のような例を挙げている。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e建設業\u003c/li\u003e\n\u003cli\u003e測量\u003c/li\u003e\n\u003cli\u003e建築\u003c/li\u003e\n\u003cli\u003e半導体関連\u003c/li\u003e\n\u003cli\u003eインフラ整備\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e一方で、事務職などのホワイトカラーは余り始めているという見方を示している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"半導体工場が建設ラッシュを生んでいる\"\u003e半導体工場が建設ラッシュを生んでいる\u003c/h1\u003e\n\u003cp\u003e熊本のTSMC工場やラピダスなど、国内で半導体工場の建設が相次いでいる背景として、次の要因を挙げている。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e台湾有事への備え\u003c/li\u003e\n\u003cli\u003eコロナ禍で起きた半導体不足\u003c/li\u003e\n\u003cli\u003eサプライチェーンの見直し\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこれらにより建設需要が急増し、建設業界では人材不足と賃金上昇が起きているという。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"サプライチェーンの重要性\"\u003eサプライチェーンの重要性\u003c/h1\u003e\n\u003cp\u003e現代の製品は、多くの企業が連携して作られている。\u003c/p\u003e\n\u003cp\u003e例えば\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e自動車\u003c/li\u003e\n\u003cli\u003e半導体\u003c/li\u003e\n\u003cli\u003eロケット\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなどは、一社でも部品供給が止まれば全体が止まってしまう。\u003c/p\u003e\n\u003cp\u003eウクライナ戦争や新型コロナによって、その脆弱さが明らかになったと説明している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"aiによって減る仕事\"\u003eAIによって減る仕事\u003c/h1\u003e\n\u003cp\u003eホリエモンは、生成AIやCopilotの普及により、\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eExcel作業\u003c/li\u003e\n\u003cli\u003eWord作成\u003c/li\u003e\n\u003cli\u003e書類整理\u003c/li\u003e\n\u003cli\u003e一般的な事務仕事\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなどはAIが代替していくと予想している。\u003c/p\u003e\n\u003cp\u003eその結果、ホワイトカラーの需要は減少していくという見方を示した。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"逆に不足する仕事\"\u003e逆に不足する仕事\u003c/h1\u003e\n\u003cp\u003e一方で、AIでは代替しにくい仕事として、\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e建設\u003c/li\u003e\n\u003cli\u003e測量\u003c/li\u003e\n\u003cli\u003e建築士\u003c/li\u003e\n\u003cli\u003eインフラ保守\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eなどは今後も人材不足が続くと述べている。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"人口減少はさらに加速する\"\u003e人口減少はさらに加速する\u003c/h1\u003e\n\u003cp\u003e団塊世代、さらにその子どもである団塊ジュニア世代の高齢化によって、日本の人口減少はさらに加速すると予想している。\u003c/p\u003e\n\u003cp\u003e現在約1億2千万人の人口も、将来的には\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e1億人未満\u003c/li\u003e\n\u003cli\u003e8000万人\u003c/li\u003e\n\u003cli\u003e7000万人\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eまで減少する可能性があるという見方を示した。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"コンパクトシティ化は避けられない\"\u003eコンパクトシティ化は避けられない\u003c/h1\u003e\n\u003cp\u003e人口減少によって\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e道路\u003c/li\u003e\n\u003cli\u003e橋\u003c/li\u003e\n\u003cli\u003e上下水道\u003c/li\u003e\n\u003cli\u003e地方インフラ\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eを維持することが難しくなる。\u003c/p\u003e\n\u003cp\u003eそのため、住民が都市部へ集まり、生活圏を集約する「コンパクトシティ化」が進むと予想している。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"海外を見ることの重要性\"\u003e海外を見ることの重要性\u003c/h1\u003e\n\u003cp\u003eホリエモンは、日本だけを見ていると変化に気づきにくいと話す。\u003c/p\u003e\n\u003cp\u003e東南アジアなどでは、\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e人口増加\u003c/li\u003e\n\u003cli\u003e経済成長\u003c/li\u003e\n\u003cli\u003e活気\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eがあり、日本との違いを実感できるという。\u003c/p\u003e","title":"ホリエモンが語る『日本の人手不足・AI・人口減少』の未来"},{"content":"このメモの目的 このメモは、ASRock 環境で実際にトラブルを踏んだ経験を元に、\nArch Linux と Windows 11 を同じディスクでデュアルブートしたい systemd-boot を使いたい 変な EFI トラブルで何日も溶かしたくない Arch / Windows / systemd-boot / UEFI の関係図 という人向けの「基礎まとめ」です。\n詳細なチュートリアルというより、やってはいけないポイント や 設計の考え方 を中心にしています。\n前提環境 例として想定している環境はこんな感じです。\nマザーボード: ASRock A520M Pro4（UEFI） CPU: Ryzen 7 5700X GPU: Radeon RX 6600 XT メモリ: DDR4 32GB ストレージ: NVMe SSD 1 本 OS: Windows 11 ＋ Arch Linux ブートローダー: systemd-boot パーティション形式: GPT ブート方式: UEFI（Legacy BIOS / CSM は使わない） 他のマザーボードでも基本の考え方は同じですが、UEFI のクセはメーカーごとに違うので、あくまで「考え方の参考」として読んでください。\nデュアルブート方式のパターン ざっくり言うと、Windows + Arch のデュアルブートには、次のようなパターンがあります。\nWindows の EFI System Partition（ESP）を Arch と共有する 別の ESP を作り、Windows と Arch で分ける 別ディスクに Arch を入れ、それぞれのディスクに ESP を持たせる ここでは「1. ESP 共有」を前提にしつつ、なぜ混乱しやすいのか も含めて整理します。\nパターン1: ESP 共有（今回使っている方式） Windows インストーラが作った ESP（例: 100〜300MB の vfat）をそのまま利用 Arch 側の /boot をその ESP にマウントして、systemd-boot をインストール メリット：\nパーティションを増やさなくてよい ESP が 1 つなのでシンプル デメリット：\nWindows の自動修復・アップデートが EFI ファイルを書き換えることがある Arch 側のファイルと混在し、構造がカオスになりやすい パターン2: ESP 分離 Windows 用 ESP（既存）とは別に、Arch 用 ESP を新規に作成 UEFI のブートエントリで、どちらの ESP から起動するか選択 メリット：\n片方の EFI が壊れても、もう片方に影響しづらい Windows の自動修復の巻き添えを受けにくい デメリット：\nUEFI のブートエントリ管理が少し面倒 ディスク構成がわずかに複雑になる パターン3: 別ディスク運用 物理的にディスクを分けるパターン ここでは詳しくは触れませんが、一番安全ではある systemd-boot の基本イメージ systemd-boot は、EFI System Partition（ESP）内に置かれるシンプルなブートローダーです。\nこれにより、各OSのエントリを loader/entries/*.conf として管理できます。\nESP に EFI/systemd/systemd-bootx64.efi をインストール 同じ ESP に loader/ ディレクトリを作り、設定ファイルを置く loader/entries/*.conf に Arch や Windows のエントリを書く Arch のエントリ例 title Arch Linux linux /vmlinuz-linux initrd /initramfs-linux.img options root=/dev/nvme0n1pX rw Copy Windows のエントリ例 title Windows 11 efi /EFI/Microsoft/Boot/bootmgfw.efi Copy Arch は linux / initrd でカーネルと initramfs を指定しますが、\nWindows は efi で Windows Boot Manager（bootmgfw.efi）にチェーンロードする形になります。\nESP のマウントパターンと注意点 ESP を Arch からどう見せるかで、よくあるのが次のパターンです。\nパターンA: ESP を /boot に直接マウント /etc/fstab 例：\nUUID=XXXX-YYYY /boot vfat umask=0077 0 2 Copy 特徴：\n/boot には ESP の中身がそのまま見える カーネルや initramfs も ESP 直下に置かれる メリット：\nsystemd-boot との相性が良い 構成がシンプル デメリット（今回ハマったポイント）：\nWindows と Arch が同じ ESP を共有するため、EFI 内が混在してカオス化しやすい 誤って不要ファイルを消すと、Windows が起動しなくなるリスク パターンB: ESP を /efi にマウントし、/boot は ext4 などにする 例：\n/efi → ESP（vfat） /boot → 通常の Linux パーティション（ext4 など） この場合、systemd-boot を使うには少し工夫が必要なので、ここでは詳しくは触れません。\n「EFI は /efi、カーネルは /boot」という分離構成もある、というメモだけ。\nWindows と共存するときの注意点 ESP 共有で Windows と共存するときに、特に気をつけたいのは次のあたりです。\n高速スタートアップをオフにする Windows 側の「高速スタートアップ」が有効だと、シャットダウン時に完全には終了せず、\nデュアルブート環境で予期しない挙動をすることがあります。\nコントロールパネル → 電源オプション → 電源ボタンの動作を選択 「高速スタートアップを有効にする（推奨）」のチェックを外す 自動修復に入りすぎないようにする 起動失敗が続くと、Windows の自動修復が EFI 内のファイル（bootmgfw.efi など）を勝手に書き換えることがあります。\nこれは、Arch 側から見ると「せっかく整理した EFI がまたぐちゃぐちゃに戻る」原因になります。\n明らかにおかしくなったら、まず ESP の構造を確認する 自動修復に任せっきりにせず、一度落ち着いて原因を切り分ける UEFI 設定を極力 UEFI オンリーにする CSM（Legacy BIOS互換）はオフ Fast Boot はオフ Secure Boot は用途次第（Arch をそのまま入れるならオフが楽） 中途半端に Legacy と混在させると、トラブルシュートが一気に難しくなります。\nArch インストール時のざっくりフロー（ESP 共有ケース） 細かいコマンドは Arch Wiki に譲って、流れだけ書くとこんな感じです。\n既存の Windows 11 が UEFI / GPT で入っていることを確認 Windows から空き領域を作る（ディスクの管理などで縮小） Arch インストーラから起動 既存の ESP（vfat）をマウント先 /boot に指定 Linux 用のルートパーティション（ext4）などを作成 Arch をインストール bootctl install で systemd-boot を導入 /boot/loader/entries/arch.conf と windows.conf を作成 ここまでで、systemd-boot のメニューから Arch と Windows を選べるようになります。\nトラブルシュートの基本 実際にトラブルが起きたとき、最低限チェックしたいのはこのあたりです。\nESP をマウントして EFI ディレクトリを覗く tree -L 3 /mnt/EFI efibootmgr でブートエントリを見る どのエントリがどのパスを指しているか bootctl status で systemd-boot の状態を確認 Windows 側のイベントビューア（システムログ） 「何が壊れたか分からない」という状態が一番つらいので、\nどこからどこまでが Arch の責任範囲で、どこから先が Windows / UEFI の領域なのかを意識して見ると、少し気持ちが楽になります。\nsystemd-boot のメニュー構造（ざっくり図） systemd-boot のメニュー構造（loader.conf / entries/*.conf） まとめ Windows と Arch のデュアルブートは、ESP 共有 か ESP 分離 かを最初に決めると設計しやすい systemd-boot はシンプルで扱いやすいが、Windows の bootmgfw.efi との付き合い方に注意 ESP を /boot に直接マウントする構成は分かりやすい一方で、EFI がカオスになりやすい Windows の高速スタートアップや自動修復は、ときどき EFI を壊す「お節介」をすることがある トラブルが起きたときは、EFI の構造と UEFI のブートエントリを一度落ち着いて眺める 別記事として、実際に ASRock 環境で遭遇した 「再起動だと Windows が起動しないのに、電源OFF→ONだと起動する」問題についても記録しています。 そちらは具体的な症状とログ中心、この記事はその前提となる考え方のメモ、という住み分けです。\n","permalink":"https://america.github.io/post/dualboot-basics-arch-windows/","summary":"\u003ch2 id=\"このメモの目的\"\u003eこのメモの目的\u003c/h2\u003e\n\u003cp\u003eこのメモは、ASRock 環境で実際にトラブルを踏んだ経験を元に、\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eArch Linux と Windows 11 を同じディスクでデュアルブートしたい\u003c/li\u003e\n\u003cli\u003esystemd-boot を使いたい\u003c/li\u003e\n\u003cli\u003e変な EFI トラブルで何日も溶かしたくない\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"dualboot-diagram-wrapper\"\u003e\n  \u003cdiv\n    id=\"dualboot-diagram\"\n    class=\"react-diagram\"\n    data-diagram=\"dualboot\"\n  \u003e\u003c/div\u003e\n  \u003cp class=\"diagram-caption\"\u003e\n    Arch / Windows / systemd-boot / UEFI の関係図\n  \u003c/p\u003e\n\u003c/div\u003e\n\n\n\u003cp\u003eという人向けの「基礎まとめ」です。\u003cbr\u003e\n詳細なチュートリアルというより、\u003cstrong\u003eやってはいけないポイント\u003c/strong\u003e や \u003cstrong\u003e設計の考え方\u003c/strong\u003e を中心にしています。\u003c/p\u003e\n\u003ch2 id=\"前提環境\"\u003e前提環境\u003c/h2\u003e\n\u003cp\u003e例として想定している環境はこんな感じです。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eマザーボード: ASRock A520M Pro4（UEFI）\u003c/li\u003e\n\u003cli\u003eCPU: Ryzen 7 5700X\u003c/li\u003e\n\u003cli\u003eGPU: Radeon RX 6600 XT\u003c/li\u003e\n\u003cli\u003eメモリ: DDR4 32GB\u003c/li\u003e\n\u003cli\u003eストレージ: NVMe SSD 1 本\u003c/li\u003e\n\u003cli\u003eOS: Windows 11 ＋ Arch Linux\u003c/li\u003e\n\u003cli\u003eブートローダー: systemd-boot\u003c/li\u003e\n\u003cli\u003eパーティション形式: GPT\u003c/li\u003e\n\u003cli\u003eブート方式: UEFI（Legacy BIOS / CSM は使わない）\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e他のマザーボードでも基本の考え方は同じですが、UEFI のクセはメーカーごとに違うので、あくまで「考え方の参考」として読んでください。\u003c/p\u003e","title":"Arch Linux と Windows 11 を安全にデュアルブートするためのメモ"},{"content":" Arch Linux と Windows 11 デュアルブート問題 ASRock 環境で「restart だと起動しないのに、shutdown だと起動する」謎バグの記録 はじめに Arch Linux と Windows 11 を同じマシンでデュアルブートしているときに、 「Arch から再起動すると Windows が起動しないのに、電源OFF→ONだと普通に起動する」 という不可解な現象に遭遇した。\n環境：\nASRock A520M Pro4 Ryzen 7 5700X Radeon RX 6600 XT DDR4 32GB systemd-boot ESP を共有 この記事は、このときに見た現象と、EFI / systemd-boot / ASRock UEFI まわりを調べたメモをまとめたもの。\nトラブルの症状と再現性 症状 Arch → 再起動 → systemd-boot で Windows を選択 → 自動修復、ロゴ停止、黒画面 Arch → シャットダウン → 電源ON → Windows → 正常起動 再現手順 Arch を起動 再起動（reboot） systemd-boot で Windows を選択 起動失敗 or 自動修復に入る 逆に、\nArch をシャットダウン 電源ON Windows 正常起動 発生頻度 高確率で発生 「Arch → 再起動 → Windows」のときだけ不安定 Windows 側で見られたもの 自動修復 ロゴ停止 黒画面 電源OFF→ONだと正常。\nシステム構成と前提条件 ハードウェア ASRock A520M Pro4 Ryzen 7 5700X Radeon RX 6600 XT Windows 側 UEFI / GPT Windows インストーラの ESP を使用 Arch 側 systemd-boot /boot に ESP をマウント kernel, initramfs, loader/entries/*.conf すべて ESP 内 ESP の設定例 UUID=XXXX-YYYY /boot vfat umask=0077 0 2 Copy ポイント：\nvfat /boot に直接マウント Arch と Windows が同じ ESP を共有するため混在しやすい 発見された異常（EFI/Microsoft 配下の二重構造） ESP をマウントして EFI の中身を確認した。\nsudo mount /dev/nvme0n1p1 /mnt tree -L 3 /mnt/EFI Copy 例：\nEFI/ ├─ Microsoft/ │ ├─ Boot/ │ │ ├─ bootmgfw.efi │ │ └─ その他 │ └─ その他 └─ Boot/ ├─ bootx64.efi └─ その他 Copy 分かったこと：\nbootmgfw.efi が複数 修復の残骸あり bootx64.efi も複数 「どの EFI が実際の入口なのか」が曖昧な状態。\nbootmgfw.efi の二重化 Windows は更新や修復で複数入口を作る：\nEFI/Microsoft/Boot/bootmgfw.efi EFI/Boot/bootx64.efi systemd-boot がどちらを参照するかで挙動が変わった。\nrename による一時的改善 bootmgfw.efi を退避し、別の bootx64.efi を指定したら数日は安定した。\nWindows 自動修復による上書き Windows は起動失敗が続くと自動で EFI を“修復” する。\nbootmgfw.efi BCD bootx64.efi これにより手動整理した状態が巻き戻される。\nsystemd-boot の設定 windows.conf title Windows 11 efi /EFI/Microsoft/Boot/bootmgfw.efi Copy 別案：\ntitle Windows 11 alt efi /EFI/Boot/bootx64.efi Copy どちらも構文は正しいが、参照先の中身で挙動が変わる。\nASRock 特有の挙動の可能性 ブート順のクセ ブート順が勝手に変わる Windows Boot Manager が優先されやすい UEFI 設定の影響 Fast Boot → OFF CSM → OFF（UEFIオンリー） Secure Boot → OFF 再起動とシャットダウンで初期化の深さが異なる可能性。\n行った調査 EFI 構造確認 efibootmgr bootctl status Windows イベントビューア 再起動と電源ONの挙動比較 一時的に効果があった対策 bootmgfw.efi の参照先変更 Windows 高速スタートアップ無効化 BIOS Fast Boot オフ Windows Boot Manager を一時的に優先にする 現時点での落としどころ EFI を整理し一本化 Windows 自動修復が暴れにくい設定にする UEFI 設定は保守的に 再起動経由は不安定だが、電源OFF→ONなら安定起動するので実用上問題なし コマンドログ sudo mount /dev/nvme0n1p1 /mnt tree -L 3 /mnt/EFI sudo efibootmgr bootctl status Copy Windows 11 の起動フローを図で整理 Windows 11 の起動フロー（UEFI → Boot Manager → winload → カーネル） まとめ Arch → 再起動 → Windows だけ起動失敗する EFI 内の bootmgfw.efi が複数存在したことが原因のひとつ Windows 自動修復が EFI を巻き戻す ASRock UEFI の癖も影響 完全特定は難しいが、実用レベルでは安定に落ち着い た ","permalink":"https://america.github.io/post/dualboot-issue-asrock/","summary":"\u003chr\u003e\n\u003ch1 id=\"arch-linux-と-windows-11-デュアルブート問題\"\u003eArch Linux と Windows 11 デュアルブート問題\u003c/h1\u003e\n\u003ch2 id=\"asrock-環境でrestart-だと起動しないのにshutdown-だと起動する謎バグの記録\"\u003eASRock 環境で「restart だと起動しないのに、shutdown だと起動する」謎バグの記録\u003c/h2\u003e\n\u003chr\u003e\n\u003ch2 id=\"はじめに\"\u003eはじめに\u003c/h2\u003e\n\u003cp\u003eArch Linux と Windows 11 を同じマシンでデュアルブートしているときに、\n「Arch から再起動すると Windows が起動しないのに、電源OFF→ONだと普通に起動する」\nという不可解な現象に遭遇した。\u003c/p\u003e\n\u003cp\u003e環境：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eASRock A520M Pro4\u003c/li\u003e\n\u003cli\u003eRyzen 7 5700X\u003c/li\u003e\n\u003cli\u003eRadeon RX 6600 XT\u003c/li\u003e\n\u003cli\u003eDDR4 32GB\u003c/li\u003e\n\u003cli\u003esystemd-boot\u003c/li\u003e\n\u003cli\u003eESP を共有\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこの記事は、このときに見た現象と、EFI / systemd-boot / ASRock UEFI まわりを調べたメモをまとめたもの。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"トラブルの症状と再現性\"\u003eトラブルの症状と再現性\u003c/h2\u003e\n\u003ch3 id=\"症状\"\u003e症状\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eArch → 再起動 → systemd-boot で Windows を選択 → 自動修復、ロゴ停止、黒画面\u003c/li\u003e\n\u003cli\u003eArch → シャットダウン → 電源ON → Windows → 正常起動\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"再現手順\"\u003e再現手順\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003eArch を起動\u003c/li\u003e\n\u003cli\u003e再起動（reboot）\u003c/li\u003e\n\u003cli\u003esystemd-boot で Windows を選択\u003c/li\u003e\n\u003cli\u003e起動失敗 or 自動修復に入る\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e逆に、\u003c/p\u003e","title":"ASRock環境のArch+Windowsデュアルブート問題の記録"},{"content":"概要 Arch Linux で Waydroid を動かそうとした際、\n「Can't open /dev/anbox-binder: No such device or address」というエラーが発生した。\n原因は カーネルが BinderFS を正しくマウントしていなかったことにあった。\nここでは、Binder/BinderFS の役割と、実際に動作させるまでの手順をまとめる。\n1. Binder と BinderFS の違い Android のアプリ間通信（IPC）は Binder ドライバで実現されている。\nLinux でこれを再現するためには、カーネルモジュールと特別な仮想ファイルシステムが必要になる。\n名称 説明 /dev/binder Android のプロセス間通信 (IPC) のコアデバイス /dev/hwbinder ハードウェア抽象層 (HAL) 用 Binder /dev/vndbinder ベンダーサービス用 Binder BinderFS これらのデバイスノードを動的に管理するためのファイルシステム 昔の環境では /dev/binder を直接作っていたが、\n最近の Waydroid や Mainline カーネルでは BinderFS を使うのが標準。\n2. エラーの原因 Waydroid 起動時のログ：\n[gbinder] ERROR: Can't open /dev/anbox-binder: No such device or address [08:49:18] Failed to add presence handler: None Copy これは、/dev/anbox-binder が存在しても中身が無効、\nつまり Binder デバイスがカーネル側で認識されていないことを意味する。\n3. 実際の確認手順 カーネルモジュール確認 uname -r zgrep CONFIG_ANDROID /proc/config.gz | grep BINDER Copy 出力例：\nCONFIG_ANDROID_BINDER_IPC=y CONFIG_ANDROID_BINDERFS=y Copy BinderFS 対応 (CONFIG_ANDROID_BINDERFS=y) があればOK。\nファイルシステム確認 cat /proc/filesystems | grep binder Copy 正常な場合：\nnodev binder Copy または nodev binderfs と出る。\n4. 動かすまでの流れ（成功例） Mainlineカーネルに切り替え\nsudo bootctl set-default arch-linux.conf Copy → 再起動\nBinderFSの確認\ncat /proc/filesystems | grep binder Copy Waydroidコンテナ起動\nsudo systemctl start waydroid-container waydroid status Copy 出力例：\nSession: RUNNING Container: RUNNING Vendor type: MAINLINE IP address: 192.168.240.112 Copy UI起動\nWAYDROID_DISABLE_HWCOMPOSER=1 waydroid show-full-ui Copy 5. initramfs とは？ initramfs は「初期RAMファイルシステム」。\nカーネルがブート時に最初に展開する仮想ルートファイルシステムで、\nルートデバイスのマウントや暗号化ボリュームの解除など、\n「カーネルだけではできない初期処理」を行うためのもの。\nGentoo のように静的に全部組み込むカーネルなら不要だが、\nArch ではモジュール分離しているため initramfs が必須。\n6. 最後に Arch Linux の mainline カーネル（6.17系）では binder が統合済み。\nbinderfs の行が出なくても問題なく動く。 もし Waydroid が止まる場合は、/dev/binder が正しいリンク先かを再確認。 WAYDROID_DISABLE_HWCOMPOSER=1 を付けると GUI 表示が安定する。 参考リンク Waydroid Documentation Linux Kernel: BinderFS Arch Wiki: Waydroid ","permalink":"https://america.github.io/post/arch-waydroid-binder/","summary":"\u003ch2 id=\"概要\"\u003e概要\u003c/h2\u003e\n\u003cp\u003eArch Linux で Waydroid を動かそうとした際、\u003cbr\u003e\n「\u003ccode\u003eCan't open /dev/anbox-binder: No such device or address\u003c/code\u003e」というエラーが発生した。\u003cbr\u003e\n原因は \u003cstrong\u003eカーネルが BinderFS を正しくマウントしていなかった\u003c/strong\u003eことにあった。\u003cbr\u003e\nここでは、Binder/BinderFS の役割と、実際に動作させるまでの手順をまとめる。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-binder-と-binderfs-の違い\"\u003e1. Binder と BinderFS の違い\u003c/h2\u003e\n\u003cp\u003eAndroid のアプリ間通信（IPC）は \u003cstrong\u003eBinder ドライバ\u003c/strong\u003eで実現されている。\u003cbr\u003e\nLinux でこれを再現するためには、カーネルモジュールと特別な仮想ファイルシステムが必要になる。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e名称\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e説明\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e/dev/binder\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eAndroid のプロセス間通信 (IPC) のコアデバイス\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e/dev/hwbinder\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eハードウェア抽象層 (HAL) 用 Binder\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e/dev/vndbinder\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eベンダーサービス用 Binder\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eBinderFS\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eこれらのデバイスノードを動的に管理するためのファイルシステム\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e昔の環境では \u003ccode\u003e/dev/binder\u003c/code\u003e を直接作っていたが、\u003cbr\u003e\n最近の Waydroid や Mainline カーネルでは \u003cstrong\u003eBinderFS を使うのが標準\u003c/strong\u003e。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"2-エラーの原因\"\u003e2. エラーの原因\u003c/h2\u003e\n\u003cp\u003eWaydroid 起動時のログ：\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-\"\u003e[gbinder] ERROR: Can't open /dev/anbox-binder: No such device or address\n[08:49:18] Failed to add presence handler: None\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003cp\u003eこれは、\u003ccode\u003e/dev/anbox-binder\u003c/code\u003e が存在しても中身が無効、\u003cbr\u003e\nつまり \u003cstrong\u003eBinder デバイスがカーネル側で認識されていない\u003c/strong\u003eことを意味する。\u003c/p\u003e","title":"Waydroidが起動しない原因とBinder/BinderFSの仕組み"},{"content":"はじめに 先日、AWSで立てたEC2インスタンスにSSH接続できなくなる問題が発生しました。このトラブルの原因と解決方法を記録しておきます。同じ状況に陥った方の助けになれば幸いです。\n問題の症状 EC2インスタンスにSSH接続を試みると、Connection timed out のエラーが表示される。 AWSコンソール上では、インスタンスは正常に動作中。 ブラウザからの接続は可能（インスタンス内のApacheは稼働中）。 トラブルシューティングの進め方 問題解決のため、まずはSSH接続ができない間もAWS System Managerの「セッションマネージャー」を利用しました。System Managerを活用することで、インスタンスの内部に直接ログインでき、次のような確認や操作が可能になりました：\nファイアウォール（UFW）の状態確認\nsudo ufw status Copy SSHサービスの状態確認\nsudo systemctl status ssh Copy System Managerは、セキュリティグループやファイアウォールの設定ミスが原因でSSH接続ができなくてもインスタンス内部にアクセスできるため、非常に有用です。\n原因と解決方法 調査の結果、以下の4つの原因が考えられました。\n原因1: セキュリティグループのルール設定ミス 問題点\nセキュリティグループでポート22（SSH）が許可されていなかった。\n解決方法\nAWSコンソールのセキュリティグループ設定に以下のルールを追加：\nタイプ: SSH プロトコル: TCP ポート範囲: 22 ソース: 自分のグローバルIPアドレス（例: 203.0.113.0/32） 原因2: UFW（Uncomplicated Firewall）がポート22を閉じていた 問題点\nEC2インスタンス内のUFW（ローカルファイアウォール）でポート22が閉じられていた。\n解決方法\n以下のコマンドを実行してポート22を許可し、設定を反映しました。\nsudo ufw allow 22 sudo ufw reload Copy 原因3: グローバルIPの変動 問題点\n自分のグローバルIPアドレスが変更されたことで、セキュリティグループのルールが機能しなくなった。\n解決方法\n新しいグローバルIPを確認し、セキュリティグループのSSHルールを更新しました。\ncurl ifconfig.me Copy 原因4: インターネットゲートウェイの設定ミス 問題点\nインターネットゲートウェイがVPCに正しくアタッチされていなかった。\n解決方法\nAWSコンソールのVPCダッシュボードで以下を確認しました：\nインターネットゲートウェイがVPCにアタッチされていること。 ルートテーブルに0.0.0.0/0のデフォルトルートがインターネットゲートウェイを指していること。 # 例: ルートテーブルの確認コマンド aws ec2 describe-route-tables --query \"RouteTables[*].Routes\" Copy 解決のポイント このケースでは、UFWの設定でポート22が閉じていた ことが主な原因でした。ローカルのファイアウォール設定とAWSのセキュリティグループ設定が一致していないことが問題を引き起こしていました。また、System Managerを利用することでインスタンス内部へのアクセスを確保しながら問題解決を進められたこともポイントです。\n学んだこと 今回のトラブルから、以下の教訓を得ました：\n複数のセキュリティ設定を確認する\nAWSのセキュリティグループ設定だけでなく、サーバー内のファイアウォール設定（UFWやiptables）も忘れずに確認する。 System Managerを積極的に活用する\nSSH接続ができない場合でも、System Managerを利用することでインスタンス内部の確認・修正が可能になる。 接続トラブルの調査フローを明確にする\n以下の順番で確認するとスムーズに解決できます：\nセキュリティグループの設定確認。 ローカルファイアウォールの設定確認。 インターネットゲートウェイとルートテーブルの設定確認。 ローカルマシンのグローバルIPアドレス確認。 おわりに 「接続できない」という問題はシンプルに見えて、原因が複数絡んでいる場合があります。トラブルシューティングは焦らず、落ち着いて一つずつ原因を切り分けていくことが重要です。\n今回の記録が、同じ状況に陥った方の参考になれば幸いです。\n","permalink":"https://america.github.io/post/aws-ssh-system-manager-issue/","summary":"\u003ch2 id=\"はじめに\"\u003eはじめに\u003c/h2\u003e\n\u003cp\u003e先日、AWSで立てたEC2インスタンスにSSH接続できなくなる問題が発生しました。このトラブルの原因と解決方法を記録しておきます。同じ状況に陥った方の助けになれば幸いです。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"問題の症状\"\u003e問題の症状\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEC2インスタンスにSSH接続を試みると、\u003ccode\u003eConnection timed out\u003c/code\u003e のエラーが表示される。\u003c/li\u003e\n\u003cli\u003eAWSコンソール上では、インスタンスは正常に動作中。\u003c/li\u003e\n\u003cli\u003eブラウザからの接続は可能（インスタンス内のApacheは稼働中）。\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"トラブルシューティングの進め方\"\u003eトラブルシューティングの進め方\u003c/h2\u003e\n\u003cp\u003e問題解決のため、まずはSSH接続ができない間もAWS System Managerの「セッションマネージャー」を利用しました。System Managerを活用することで、インスタンスの内部に直接ログインでき、次のような確認や操作が可能になりました：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eファイアウォール（UFW）の状態確認\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-0\" class=\"language-bash\"\u003esudo ufw status\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-0', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSSHサービスの状態確認\u003c/strong\u003e\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-1\" class=\"language-bash\"\u003esudo systemctl status ssh\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-1', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSystem Managerは、セキュリティグループやファイアウォールの設定ミスが原因でSSH接続ができなくてもインスタンス内部にアクセスできるため、非常に有用です。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"原因と解決方法\"\u003e原因と解決方法\u003c/h2\u003e\n\u003cp\u003e調査の結果、以下の4つの原因が考えられました。\u003c/p\u003e\n\u003ch3 id=\"原因1-セキュリティグループのルール設定ミス\"\u003e\u003cstrong\u003e原因1: セキュリティグループのルール設定ミス\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003e問題点\u003c/strong\u003e\u003cbr\u003e\nセキュリティグループでポート22（SSH）が許可されていなかった。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e解決方法\u003c/strong\u003e\u003cbr\u003e\nAWSコンソールのセキュリティグループ設定に以下のルールを追加：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eタイプ: SSH\u003c/li\u003e\n\u003cli\u003eプロトコル: TCP\u003c/li\u003e\n\u003cli\u003eポート範囲: 22\u003c/li\u003e\n\u003cli\u003eソース: 自分のグローバルIPアドレス（例: \u003ccode\u003e203.0.113.0/32\u003c/code\u003e）\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"原因2-ufwuncomplicated-firewallがポート22を閉じていた\"\u003e\u003cstrong\u003e原因2: UFW（Uncomplicated Firewall）がポート22を閉じていた\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003e問題点\u003c/strong\u003e\u003cbr\u003e\nEC2インスタンス内のUFW（ローカルファイアウォール）でポート22が閉じられていた。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e解決方法\u003c/strong\u003e\u003cbr\u003e\n以下のコマンドを実行してポート22を許可し、設定を反映しました。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-2\" class=\"language-bash\"\u003esudo ufw allow 22\nsudo ufw reload\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-2', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003chr\u003e\n\u003ch3 id=\"原因3-グローバルipの変動\"\u003e\u003cstrong\u003e原因3: グローバルIPの変動\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003e問題点\u003c/strong\u003e\u003cbr\u003e\n自分のグローバルIPアドレスが変更されたことで、セキュリティグループのルールが機能しなくなった。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e解決方法\u003c/strong\u003e\u003cbr\u003e\n新しいグローバルIPを確認し、セキュリティグループのSSHルールを更新しました。\u003c/p\u003e\n\u003cdiv class=\"codeblock-wrapper\"\u003e\n    \n    \u003cpre\u003e\n        \u003ccode id=\"codeblock-3\" class=\"language-bash\"\u003ecurl ifconfig.me\u003c/code\u003e\n    \u003c/pre\u003e\n    \u003cbutton class=\"copy-btn\" onclick=\"copyToClipboard('codeblock-3', this)\"\u003eCopy\u003c/button\u003e\n\u003c/div\u003e\n\u003chr\u003e\n\u003ch3 id=\"原因4-インターネットゲートウェイの設定ミス\"\u003e\u003cstrong\u003e原因4: インターネットゲートウェイの設定ミス\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003e問題点\u003c/strong\u003e\u003cbr\u003e\nインターネットゲートウェイがVPCに正しくアタッチされていなかった。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e解決方法\u003c/strong\u003e\u003cbr\u003e\nAWSコンソールのVPCダッシュボードで以下を確認しました：\u003c/p\u003e","title":"AWSでSSH接続できない問題を解決した話"},{"content":"AWSでLAMP環境を構築したけれど… 最近、AWS上でLAMP環境を構築し、WordPressを立ち上げました。これ自体は、これまでの経験を活かして比較的スムーズに進めることができました。EC2のインスタンスを用意し、Apacheを設定し、MySQLとPHPを組み合わせて、ようやくWordPressのインストールにこぎつけました。\nWordPressのダッシュボードを初めて開いたときには、達成感がありました。「これで理想のブログができる」と思ったのです。しかし、その後、運用をイメージし始めたとき、徐々に違和感が生じてきました。\nWordPressで感じた違和感 WordPressは確かに便利で多機能です。しかし、カスタマイズしようと思うとプラグインの選定やセキュリティ対策に多くの時間を費やす必要があります。そして、定期的なアップデートの管理、MySQLのバックアップ、万が一のトラブル時の復旧作業…これらが少しずつ重くのしかかってきました。\nブログ運営は長期戦です。構築そのものに時間をかけすぎるのではなく、記事の執筆や情報発信にもっと時間を使いたい。そう思い始めると、WordPressは少し「重たい」と感じるようになりました。\n静的サイトジェネレーターとの出会い そんな中で目にしたのが、静的サイトジェネレーターの存在です。特にHugoのシンプルさや高速性には興味を惹かれました。さらに、GitHub Pagesを利用すれば無料でホスティングでき、運用コストを大幅に削減できることに気づいたのです。\nHugoで生成される静的サイトは、セキュリティリスクも少なく、更新もGitの操作だけで完結します。「これなら、より気軽にブログを運営できるかもしれない」と思い、試しにローカル環境でHugoを導入してみました。\nGitHub Pages + Hugoへの移行を決断 Hugoを使ってサイトを構築してみると、その軽さとスピード感に驚きました。Markdownで記事を書き、コマンド一つでサイトを生成。そして、そのファイルをGitHubにプッシュするだけで公開できる。このシンプルさに感動しました。\n最初は「WordPressで構築したものを捨てるのはもったいない」と葛藤しました。しかし、将来を見据えたとき、運用の手軽さが何よりも重要だと判断し、GitHub Pages + Hugoに移行することを決断しました。\n結論：ブログ運営における最適解とは？ AWSでのLAMP環境構築やWordPressの設定は、確かに学びの多い経験でした。しかし、それ以上に「どんな形でブログを運営したいのか」を考える貴重な機会にもなりました。\n今、私はHugoとGitHub Pagesでブログを運営しています。そのシンプルさと自由度の高さに満足しながら、これから記事を増やしていくつもりです。\nもし、ブログの運営方法で悩んでいる方がいれば、「自分にとって最適な運用方法は何か？」をぜひ考えてみてください。決して、簡単にたどり着ける答えではありませんが、その過程で得られる学びは大きいものです。\n","permalink":"https://america.github.io/post/wordpress-to-hugo-github-pages-migration/","summary":"\u003ch1 id=\"awsでlamp環境を構築したけれど\"\u003eAWSでLAMP環境を構築したけれど…\u003c/h1\u003e\n\u003cp\u003e最近、AWS上でLAMP環境を構築し、WordPressを立ち上げました。これ自体は、これまでの経験を活かして比較的スムーズに進めることができました。EC2のインスタンスを用意し、Apacheを設定し、MySQLとPHPを組み合わせて、ようやくWordPressのインストールにこぎつけました。\u003c/p\u003e\n\u003cp\u003eWordPressのダッシュボードを初めて開いたときには、達成感がありました。「これで理想のブログができる」と思ったのです。しかし、その後、運用をイメージし始めたとき、徐々に違和感が生じてきました。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"wordpressで感じた違和感\"\u003eWordPressで感じた違和感\u003c/h1\u003e\n\u003cp\u003eWordPressは確かに便利で多機能です。しかし、カスタマイズしようと思うとプラグインの選定やセキュリティ対策に多くの時間を費やす必要があります。そして、定期的なアップデートの管理、MySQLのバックアップ、万が一のトラブル時の復旧作業…これらが少しずつ重くのしかかってきました。\u003c/p\u003e\n\u003cp\u003eブログ運営は長期戦です。構築そのものに時間をかけすぎるのではなく、記事の執筆や情報発信にもっと時間を使いたい。そう思い始めると、WordPressは少し「重たい」と感じるようになりました。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"静的サイトジェネレーターとの出会い\"\u003e静的サイトジェネレーターとの出会い\u003c/h1\u003e\n\u003cp\u003eそんな中で目にしたのが、静的サイトジェネレーターの存在です。特にHugoのシンプルさや高速性には興味を惹かれました。さらに、GitHub Pagesを利用すれば無料でホスティングでき、運用コストを大幅に削減できることに気づいたのです。\u003c/p\u003e\n\u003cp\u003eHugoで生成される静的サイトは、セキュリティリスクも少なく、更新もGitの操作だけで完結します。「これなら、より気軽にブログを運営できるかもしれない」と思い、試しにローカル環境でHugoを導入してみました。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"github-pages--hugoへの移行を決断\"\u003eGitHub Pages + Hugoへの移行を決断\u003c/h1\u003e\n\u003cp\u003eHugoを使ってサイトを構築してみると、その軽さとスピード感に驚きました。Markdownで記事を書き、コマンド一つでサイトを生成。そして、そのファイルをGitHubにプッシュするだけで公開できる。このシンプルさに感動しました。\u003c/p\u003e\n\u003cp\u003e最初は「WordPressで構築したものを捨てるのはもったいない」と葛藤しました。しかし、将来を見据えたとき、運用の手軽さが何よりも重要だと判断し、GitHub Pages + Hugoに移行することを決断しました。\u003c/p\u003e\n\u003chr\u003e\n\u003ch1 id=\"結論ブログ運営における最適解とは\"\u003e結論：ブログ運営における最適解とは？\u003c/h1\u003e\n\u003cp\u003eAWSでのLAMP環境構築やWordPressの設定は、確かに学びの多い経験でした。しかし、それ以上に「どんな形でブログを運営したいのか」を考える貴重な機会にもなりました。\u003c/p\u003e\n\u003cp\u003e今、私はHugoとGitHub Pagesでブログを運営しています。そのシンプルさと自由度の高さに満足しながら、これから記事を増やしていくつもりです。\u003c/p\u003e\n\u003cp\u003eもし、ブログの運営方法で悩んでいる方がいれば、「自分にとって最適な運用方法は何か？」をぜひ考えてみてください。決して、簡単にたどり着ける答えではありませんが、その過程で得られる学びは大きいものです。\u003c/p\u003e\n\u003chr\u003e","title":"WordPressをやめて、Hugo + GitHub Pagesに移行した理由"},{"content":"ここは America の雑記です。Linux / Arch / Waydroid のメモを中心に置いていきます。\n","permalink":"https://america.github.io/about/","summary":"\u003cp\u003eここは America の雑記です。Linux / Arch / Waydroid のメモを中心に置いていきます。\u003c/p\u003e","title":"About"},{"content":"","permalink":"https://america.github.io/all-pages/","summary":"","title":"全ページ一覧"}]