雑記

LinuxでAndroidを動かすWaydroidの中で、テンキーの数字が打てなくなった。キーボードをGboardの「日本語」にすると打てて、「English (US)」にすると打てない。上段の数字キーは、どちらでも打てる。ホスト(Arch Linux、sway)でテンキーを打つと、数字が出る。 swayの設定に input * xkb_numlock enabled を足したが、直らなかった。なぜ効かないのかを、ソースと実測で調べた。 先に結論 ホストの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)。 1. ホストのキーは、キーコードのまま渡される。修飾キーの状態は渡されない。 HWCは、Waydroidのウィンドウに入ったキー入力を、キーコードの形で、Android側のパイプ(/dev/input/wl_keyboard_events)に書く。Waylandの修飾キーの状態を受け取る関数 keyboard_handle_modifiers は、中身が空になっている。ホストのNumLockがオンでも、Androidはそれを知らない。 2. テンキーの数字は、AndroidのNumLockがオンのときだけ出る。 Android 13の Generic.kcm では、NUMPAD_1 は、base: fallback MOVE_END、numlock: '1' と定義されている。NumLockがオフなら、Endキーになる。 3. NumLockの状態は、キーを離したときに切り替わる。 Keyboard.cpp の toggleLockedMetaState は、キーを押したときは何もせず、離したときに、状態を反転する。 4. 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)は、この登録に入っていない。 実測 dumpsys input で、入力機器の状態を取った。キー入力の履歴を含まない部分だけを、次のように取り出せる。 sudo waydroid shell dumpsys input | sed -n '/Input Reader State/,/Input Dispatcher State/p' > out-1.txt Copy wayland_keyboard の項目の、MetaState(修飾キーとロックの状態)と、DownTime(最後にキーが押された時刻)を、見た。 ...

あるXのポストに、こんな趣旨の不満が書かれていた。公式のスマホアプリからClaude Codeに指示は出せる。ただ、一部の設定やコネクターの再認証のときは、PCのターミナルに戻らされる。外出先でも、そこまでアプリの中で済ませたい、という内容だった。 私は、この不満が出る形とは別のやり方で使っている。アプリを経由せず、Claude Codeが動いている端末の画面そのものを、スマホで開く。 この記事では、その仕組みと弱点を書く。 何をしているか PCの端末(ターミナル)の中でClaude Codeを動かしている。その端末の画面を、スマホから、そのまま開いている。 スマホ側では、a と打つだけで、PCのClaude Codeの画面に入る。PCの前に戻ったら、cc と打てば、同じ画面が出る。どちらから入っても、同じ画面に入る。会話の途中のまま、続けられる。 端末の画面そのものなので、設定の変更も、再認証も、PCで打つのと同じコマンドを、スマホで打てる。戻る場所が、そもそも無い。 使っているもの 名前 役割 tmux 端末の中身を保つ。画面を閉じても、接続が切れても、中の作業が残る。あとで同じ画面に入り直せる mosh SSHの仲間。Wi-Fiが変わる、スマホがスリープする、といった回線の切れ目があっても、つなぎ直さずに続く SSH(鍵認証) PCに入るための入口。パスワードでのログインは切って、鍵だけにしている Tailscale 外から自宅のPCに届く経路(VPN) Termux スマホ(Android)側の端末アプリ。ここでmoshを動かす 流れは、こうなる。 スマホのTermuxで a と打つ。これは、mosh でPCに入り、tmuxの dev というセッションに入る、という命令の短縮(エイリアス)。 SSHでPCにつないだあと、mosh-serverがその場で起動して、UDPで、つなぎ直す。 tmuxの dev に入る。そこで、Claude Codeが動いている。 PCの前では、cc で、同じ dev に入る。cc は、tmux new -A -s dev(あれば入る、無ければ作る)の短縮にしてある。 つまずいた点 mosh-serverは、常駐しない。 つなぐたびに起動する。誰もつないでいないときに動いていないのは、正常。 moshの -p は、SSHのポートではなく、mosh自身のUDPポート。 SSHのポートを変えているなら、--ssh="ssh -p ポート番号" の形で渡す。 ロケールが無いと、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経由でしか入れない形にしておくのが前提になる。この記事では、ポート番号やアドレスなど、環境の具体的な値は書いていない。

数年間、SES(システムエンジニアリングサービス)の協力会社として、銀行系のシステム開発現場に常駐していた時期がある。自分と最終的な発注元(客)の間に何社入っているのか、正直よく分からなかった。各段階でマージンが抜かれ、現場に来るころには話が何重にも薄まっている。この記事では、特定の会社や個人の話ではなく、その構造そのものについて書く。 「人月」とは何か IT業界、特にSIer(システムインテグレーター)が元請けになる受託開発の現場では、契約や見積もりが「人月(にんげつ)」という単位で組まれることが多い。「エンジニア1人を1か月アサインする」のが1人月で、プロジェクトの規模は「10人月」「50人月」のように、人数×期間の掛け算で表現される。 成果物の価値や難易度ではなく、頭数と時間だけで値段が決まる。優秀なエンジニアが1人で終わらせる仕事も、未経験者が3人がかりでやる仕事も、同じ「3人月」なら同じ金額になりうる。 多重下請けの中はどう見えるか 自分が実際にいた現場は、発注元の銀行 → 元請けSIer → 2次請け → 3次請け(自分の所属会社)、という構造だった。各段階で中間マージンが抜かれるので、客が払っている金額と、実際に現場で働く自分の手取りの間には、かなりの開きがある。 現場では、自分がどの会社の人間かということより「誰の下で働いているか」の方が重要になる。常駐先の実質的な上司は、客でも元請けでもなく、別の協力会社から出向してきた人間だったりする。これは「偽装請負」と呼ばれる状態で、グレーゾーンというより、職業安定法44条が禁じる「労働者供給事業」そのものに触れうる。同条は「何人も……労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない」と定めており、契約上は請負・準委任なのに実態として他社の指揮命令を受けて働かせる形は、この禁止に抵触する(出典)。SES・準委任契約の現場では、この境界線上の運用がしばしば起きる。 求人票の給与額に通勤手当を混ぜて実質的に水増しする、というようなことも、珍しくない手口として見てきた。職業安定法5条の3は、求人者に賃金額を含む労働条件の明示を義務づけており、虚偽の条件を提示して募集を行った場合、同法65条により6か月以下の拘禁刑または30万円以下の罰金の対象になる(出典)。 業界団体側の調査でも、SES企業が取るマージン率は平均で35〜40%程度、エンジニアへの還元率はおよそ60〜65%が相場とされている(出典)。つまり客が単価80万円を払っていても、現場のエンジニアの手元に残るのはその6割強、という配分が業界の標準として扱われている。これは1段階のマージンの話で、間にもう1社挟まれば、さらに削られる。 数字で見る多重下請け構造 体感でしかなかった話を、公的な調査と照らし合わせてみる。 公正取引委員会が2022年に公表した実態調査(資本金3億円以下の事業者 約2万1,000社が対象、18年ぶりの大規模調査)によると、ソフトウェア制作の取引では「細分化と再委託の繰り返しで商流が多層化・複雑化し、極端に長い商流が形成される場合がある」とされ、最大で6次下請けの事例が報告されている。調査対象事業者の取引上の立場は、元請が40.4%、中間下請が38.2%、最終下請が21.3%で、実に約6割が、客と直接の契約関係を持たない下請けの立場にあった(出典)。 同調査によれば、日本のソフトウェア業の市場規模は2020年時点で約15兆9,791億円、従業者数は約83万7,606人、事業所数は2万5,977か所。そのうち従業者4人以下の零細事業所が全体の約40.3%を占める。自分がいたような小さな協力会社は、例外ではなく、この業界の典型的な構成要素だということになる。 下請法(下請代金支払遅延等防止法)4条1項は、親事業者による受領拒否(1号)・支払遅延(2号)・代金減額(3号)・返品(4号)・買いたたき(5号、「通常支払われる対価に比し著しく低い下請代金の額を不当に定めること」)・購入利用強制(6号)などを禁止している。下請法はもともと、独占禁止法が規制する「優越的地位の濫用」のうち、取引上弱い立場になりやすい下請取引に絞って、より摘発しやすい形で切り出した特別法という位置づけにある(出典)。 下請法違反による措置件数(令和3年度)は、情報サービス業が686件で、全業種の中で最多だった。マージンを多段階で抜く多重下請け構造そのものが、下請法が禁じる行為(とりわけ買いたたき)が起きやすい土壌になっていることを、この件数が裏付けている。 なぜこの構造は無くならないのか 発注側に内製力が無い 大企業・官公庁の多くは、自前でシステムを開発・保守する体制を持っていない。仕様を固める力も、技術を評価する力も社内に無いため、丸ごと外注することになる。元請けSIerは、その仕様の曖昧さごと請け負い、さらに下に投げる。 人月は「稟議を通しやすい」 「Xという価値を生むシステムにY円払う」という成果ベースの契約は、発注側にとって説明しにくい。一方「X人×Yか月×単価」という人月の積み上げは、稟議や調達の書類に落とし込みやすい。見積もりの根拠として扱いやすいことが、技術的に優れているかどうかより優先される。 契約形態がリスクを現場に寄せる 仕様が固まらないまま始まるプロジェクトは、請負契約(成果物に対して責任を負う)では受けにくい。だから準委任契約(人を貸す形)で始まることが多く、プロジェクトが炎上しても「言われた作業はやった」という形で、リスクの多くが現場の労働者側に流れる。 なぜ日本だけこの形になったのか 多重下請け構造自体は海外にも存在するが、日本の際立った特徴は「IT人材の大半がベンダー(IT企業)側にいて、客となる事業会社側にはほとんどいない」という偏りだ。 IPA(情報処理推進機構)の「IT人材白書2017」によれば、日本はIT人材の72.3%がIT産業(ベンダー側)に所属し、非IT産業(ユーザー企業側)に所属するのはわずか27.7%。これに対し米国では、IT人材の65.4%がユーザー企業側に所属しており、ベンダー側は34.6%にとどまる。カナダ・英国・ドイツ・フランスも軒並みユーザー企業側が過半数で、日本の偏りは比較対象の欧米各国の中でも際立っている(出典)。 つまり米国では「システムを使う会社」自身が技術者を雇って内製するのが主流なのに対し、日本では「システムを使う会社」はほぼ技術者を抱えず、「技術者を派遣・常駐させる会社」という別の産業が間に挟まる構造が標準になっている。多重下請けが生まれる土壌は、この人材配置の偏り自体にあると考えている。 小泉改革が原因なのか この話をすると「2004年、小泉内閣が労働者派遣法を改正して派遣を自由化したのが原因では」と聞かれることがある。半分当たっていて、半分違う。 労働者派遣法そのものは1986年(中曽根内閣)に制定された法律で、制定当初から対象業務16業務の中にソフトウェア開発が含まれていた。つまりIT業界で技術者を客先に常駐させる仕組み自体は、法律の出発点から想定されていたもので、小泉改革より18年も前からある。1999年(小渕内閣)には、許可業務を決める方式から禁止業務だけを指定する方式(ネガティブリスト化)への転換で原則自由化され、2004年(小泉内閣)の改正で変わったのは、それまで禁止されていた製造業への派遣解禁だった(出典)。つまり小泉改革が直接狙い撃ちにしたのはIT業界ではなく製造業で、IT業界の多重下請け構造の土台はそれよりずっと前から存在していたことになる。 むしろこの記事で問題にした「偽装請負」(指揮命令が契約関係と一致しない状態)は、労働者派遣法の規制が緩くなったから起きるというより逆で、派遣法が課す責任(派遣期間の上限、派遣先の義務など)を避けるために、企業側が正式な労働者派遣ではなく請負・準委任契約を使うことで起きる現象に近い。規制緩和というより、規制を迂回する動きの産物だと考えている。 「見直される」のではなく、「人が逃げる」 この業界がある日突然見直される、という形の変化は来ないと思っている。実際に起きているのは、もっと静かな浸食だ。 経済産業省は2018年の「DXレポート」で、老朽化した基幹システム(レガシーシステム)がDXの足かせになっていると指摘し、対応が遅れた場合2025年以降に最大で年間12兆円規模の経済損失が生じるという試算を示した(出典)。いわゆる「2025年の崖」で、同じレポートでは2025年に最大43万人のIT人材が不足するとも見積もられている。 事業会社側の内製化は、この数年でじわじわ進んでいる。技術に関心があって優秀な人ほど、多重下請けの現場から事業会社側へ流出していく。すると残った現場の技術力の平均が下がり、さらに優秀な人材が入ってこなくなる――という自己強化型のループが働く。 面白い仕事とまともな待遇は事業会社側に集まり、SES層にはレガシー保守や人手不足を埋める仕事が残り続ける。需要そのものが無くならない以上、業界の底辺としては長く生き残る。「業界構造が改まる」のではなく、「動ける人から順に抜けていく」形で、中身だけが少しずつ入れ替わっていくのだと思う。 唯一の変数は生成AI この構造を崩しうるとしたら、一番の変数は生成AIだと考えている。1人あたりの生産性が本当に底上げされれば、「頭数×時間」で積み上げる人月という単位そのものが、価格の目安として成立しなくなる可能性がある。 ただし楽観はしていない。起きるとしたら「人月という評価モデルが見直される」方向よりも、「下請けの中でも一番下の、単純作業に近い層がまるごと要らなくなって、業界全体が縮む」方向に出る公算の方が高いと思っている。 出典 経済産業省「DXレポート」(2018)の「2025年の崖」解説 - 日立ソリューションズ・クリエイト ソフトウェア業の下請取引等に関する実態調査報告書(2022年6月公表) - 公正取引委員会 平成30年版 情報通信白書 日米のICT人材の比較 - 総務省 SESの単価相場一覧 - レバテック 職業安定法 条文(44条・5条の3・65条) - 法令リード 下請法で禁止されている「買いたたき」とは - BUSINESS LAWYERS 【早見表】労働者派遣法改正の歴史をわかりやすく解説 - マンパワーグループ

音量を調整しようとpavucontrolを開いたら、こう言われた。 pa_context_get_card_info_by_index() 失敗: Invalid argument Copy それだけ。開かない。 環境はArch Linux、sway、PipeWire 1.6.8、WirePlumber 0.5.16。よくある「PulseAudio互換レイヤーが機嫌を損ねた」系の話に見えたが、実際に追ってみたら、思ったより下の層まで潜る羽目になった。 まず journalctl systemctl --user status pipewire pipewire-pulse wireplumber でログを見ると、pipewireとwireplumberが3〜5秒おきに同じエラーを吐き続けていた。しかも調査してる最中もリアルタイムで進行中。 pipewire: spa.alsa: 'front:0': capture open failed: デバイスもしくはリソースがビジー状態です pipewire: pw.node: (alsa_input.usb-Kingston_HyperX_Quadcast_4110-00.analog-stereo-94) suspended -> 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）だ。 fuser -v /dev/snd/* で確認したが、掴んでいるのはwireplumber/pipewire自身だけ。Discordや他のアプリがマイクを横取りしているわけではなかった。PipeWireの中だけで完結して壊れている。 エラーメッセージに「Lua」と書いてある ログをよく見ると wplua: [string "alsa.lua"]:446 とある。C言語のデーモンのはずなのに、なぜLuaのエラーが出てくるのか。 ...

Xで、こんな趣旨の投稿を見かけた。 「NVIDIAが、自社のAI半導体を担保に資金を調達する巨大な枠組みを打ち出した。だが同社の先端半導体やそれを取り巻くインフラに、それほどの価値があるとは思えない。ウォール街も懐疑的だ。AIは過大評価されたバブルで、いずれ冷める可能性が高い」——という内容だった。 AIバブルについて気になっていたので、これが本当かどうか、自分で裏取りしてみることにした。 1. NVIDIAのGPU担保融資、これは本当にあった まず、投稿の前半（NVIDIAの構想自体）は事実だった。 NVIDIAは2026年8月、Apollo・BlackRock・Blackstone・Brookfield・Goldman Sachs・KKRという大手金融6社と組んで、AI向け計算資源（GPU）を担保に最大5000億ドルを長期的に調達する枠組みを発表している。 仕組みはこうだ。NVIDIAのGPUを担保にした特別目的会社（SPV）が、銀行や機関投資家向けに社債を発行して資金を集める。集めた資金でデータセンターを建て、そこにGPUを並べて、NVIDIAの顧客にリースする。もしGPUの担保価値が想定より下がった場合、NVIDIA自身が最大25%、金額にして最大1250億ドルを補填する、という約束までついている。 要するに、「自社が作っているGPUそのものを担保にして、他人の金を引っ張ってくる」スキームだ。 2. ウォール街が懐疑的、というのも本当だった 投稿の後半、「ウォール街は冷ややかだ」という部分も、裏が取れた。 このNVIDIAの構想について、2026年10月1日（くしくも、件の投稿の前日）に、こういう見出しの記事が出ている。 Nvidia’s bet that its chips can finance the AI boom gets a Wall Street reality check 中身を読むと、実名の金融関係者が具体的な懸念を語っている。 Impax Asset ManagementのTony Trzcinka: 「Wall Street is much more conservative」。NVIDIAは「GPUは10年稼げる」と主張しているが、銀行は通常GPUを3〜4年で償却するのが実務だ、と指摘 S&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%）だけでは足りず、投資適格の顧客からの収益で裏付けを取りたがっている、という話も出ていた。 ここまでは、投稿の内容はどちらも事実として確認できた。 3. でも「AIはバブル」は、ここからの飛躍だった 問題はここからだ。投稿は最後に「AIは過大評価のバブル。やがて冷める確率は高い」と締めくくっている。これも本当なのか、確かめた。 まず、「GPUを担保にした融資スキームの、担保価値の見積もりにウォール街が保守的だ」という話と、「AI全体がバブルで、いずれ崩壊する」という話は、別の主張だ。前者は、特定の金融商品の設計についての、実務家の技術的な懸念にすぎない。後者は、AI関連株の時価総額全体が実態とかけ離れている、という、もっと大きな話になる。 投稿を書いた本人は、金融や半導体の専門家ではない。「AIはバブル」という結論は、投稿者個人の意見として読むべきもので、さっきの実名金融関係者の発言とは、重みがまったく違う。 それでも、「AIバブル」説自体に根拠がないわけではなかったので、別途それも調べてみた。 ...

sudo systemctl restart bluetoothと打ったら、パスワードを聞かれずに通った。何かがおかしい。ここから、GTFOBinsの調査、SSH鍵の作り直し、rrsyncとの格闘、そしてOpenSSHのソースコードを読むところまで進んだ調査の記録。最後には、原因が分からないままPCが2回勝手に落ちるという、後味の悪いオチが付く。 きっかけ: パスワードを聞かれない Bluetoothの調子が悪くてsudo systemctl restart bluetoothを打った。いつもならパスワードを聞かれるはずが、そのまま通った。直近でsudoを使った覚えもない。おかしいと思ってsudo -n -l(パスワード無しで、自分に許可されているsudoコマンドを一覧表示する)を叩いてみた。 ユーザー 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つが、パスワード無しで、引数を問わず実行できる設定が入っていた。 GTFOBinsで確認した危険性 GTFOBinsは、Unix系のバイナリを悪用した権限昇格の手口をまとめたデータベースだ。systemctlとrsyncのページを見ると、この設定がどれだけまずいかがすぐ分かる。 systemctl: 自分でsystemdのサービスファイルを作り、systemctl link→systemctl enable --nowで登録・起動すれば、そのサービスはroot権限で動く。あるいはSYSTEMD_EDITOR環境変数に自分のスクリプトを指定した状態でsystemctl editを叩くと、そのスクリプトがrootで呼ばれる。 rsync: --rsh(または-e)オプションで、任意のコマンドを「リモートシェル」として起動できる。sudo rsync -e /bin/sh ...のような形で、rootのシェルを直接取れる。 つまりこの設定は、一般ユーザーのまま実質rootになれる、という状態だった。poweroffだけは被害が限定的(シャットダウンのみ)だが、残り2つは深刻。 誰がこれを使っていたのか このPCで動いている自動化を一通り確認したが、systemd timerにもcronにも、この3つのNOPASSWDに依存しているものは見当たらなかった。 答えは、別のマシン(自宅のミニPC、以下NAS)側にあった。backup-archという、このPCの/home /boot /etcを毎晩NASへrsyncでバックアップするスクリプトが、SSH経由でこのPCに対してsudo rsyncを実行していた。バックアップ完了後、sudo systemctl stop/startでコンテナを一時停止する処理と、sudo poweroffで自動シャットダウンする処理も持っていた。 backup-archの最初のコミットは2025年10月。当時はコーディングエージェントに書かせたもので、SSH経由のsudo実行を前提にした設計だった。systemctlを使っていた「バックアップ前後にコンテナを止める」処理は、後になって「そもそも止める対象がバックアップ範囲に含まれておらず、意味が無かった」という理由で既に削除されていたが、sudoers側の許可だけが広いまま残っていた。 絞り込みの設計: rrsyncとSSH強制コマンド rsyncとsystemctlのNOPASSWDを外し、その代わりに、必要な操作だけをできる形に絞り込むことにした。 rsyncにはrrsync(restricted rsync)という、rsync本体に同梱されている補助スクリプトがある。SSHのauthorized_keysで、特定の鍵に対してcommand="rrsync -ro /path/to/dir"のように強制コマンドを指定すると、その鍵で接続してきたクライアントが何を要求しても無視され、指定した1つのディレクトリへの読み取り専用アクセスだけが許可される。 ただしrrsyncは、1回の起動につき1つのディレクトリしか制限できない。今回は/home /boot /etcの3か所が必要だったので、ディレクトリごとに専用の鍵を1本ずつ、計3本作った。加えて、シャットダウン専用の鍵をもう1本。合計4本の鍵、それぞれに対応する強制コマンドをauthorized_keysに設定した。 command="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側も、引数まで完全一致させた形にする。 ...

自作デスクトップ機(母艦 takashi-pc)の本体パーツ構成と費用を、購入時のレシート・注文記録 ベースで洗い出した。キーボード・マウスなどの周辺機器は除いて、CPU・GPU・マザーボード・ メモリ・ストレージ・ケース・電源だけの本体パーツに絞ってある。CPU/GPUは実機をlscpu/ lspciで確認し、購入レシートの型番と一致することも確認済み。 パーツ一覧 パーツ 型番 購入先 購入日 支払額 備考 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" 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" SATA(3年保証・並行輸入品) Amazon 2025-08-05 ¥9,500 あと払い(Paidy) SSD④(Windows用、使用中) Crucial MX500 500GB 2.5" 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 ...

使ってるアケコンは、HORI ファイティングスティックαがベースで、中身はほぼ総取っ替えしてある。 ボタンは全部GamerFingerに換装、レバーは静音版に赤バネと八角ガイドで固め、弱Kの下には 20mmの穴まで追加で開けた。作ったのは2025年10月頃。 いくらかかったのか、正直「そんなに大した額じゃない」くらいの感覚でいた。今回、 Amazon・PayPay銀行の注文履歴を掘り起こして、実際の領収書ベースで集計し直したら、 思ってたより高かった。 ベース機と部品 項目 金額 購入時期 ベース機(メルカリ中古) ¥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年に先行して買っておいたものを、後から改造に流用した形になる。 領収書探しで一番びっくりした話 レバーの¥3,191という数字、最初は自分でも「本当にこの値段だったか?」と半信半疑だった。 Amazonの注文履歴を掘り返してようやく2018年10月の実際の注文が見つかって、金額もぴったり 一致した。ついでに、この型番(JLF-TP-8YT-SK)の「SK」が三和電子の静音版を示す公式の 型番だということも、商品タイトルには「静音」と書かれていなかったので今回初めて裏を取った。 今の配線の工夫 はんだ付けは苦手なので、追加した20mmボタンを含めて全部のボタンを同時に有効化できてはいない。 一番外側の2箇所に来ていたハーネスケーブルを、実際に使いたい場所(外側24mmのパリィボタンと L1のインパクト)へ挿し替えて運用している。内側に増設したもう1個のボタンは、位置的に 指が届きにくく、結局配線を刺していない。

要約元 投稿：YouTube(ジャーナリスト・烏賀陽弘道氏によるライブ配信「ウガ金」、2026年9月18日、約2時間47分) 内容：AI開発企業のトップ自身が「このままではAIが人類滅亡のリスクになる」と警告し始めている状況について、コロンビア大学院で核戦略・安全保障論を専攻した烏賀陽氏が、核兵器開発との類似点・相違点を軸に分析したライブ配信 文字起こし：faster-whisper(smallモデル、CPU、int8)による自動生成。フィラーや言い直しを大量に含む口語そのままの自動音声認識のため誤字・誤認識が多く残っている可能性が高い。以下は要点を再構成したもので、逐語訳ではない。人名の一部(生物学からAI研究に転じた研究者)は音声上「高橋幸一」と聞こえるが、経歴から理研の高橋恒一氏を指すとみられるため以下ではそのように表記した なお、この配信は専門の学術論文や公式報告書ではなく、烏賀陽氏個人の見解と、Google Geminiに生成させたシナリオを紹介するライブトーク番組である。示されている未来予測の多くは確定した事実ではなく、烏賀陽氏自身の推論や、AI自身に予測させた仮説である点に留意されたい。 烏賀陽弘道氏は、朝日新聞・AERA記者を17年、フリーランス記者として23年のキャリアを持つジャーナリストで、1994年にコロンビア大学大学院で国際安全保障論(核戦略)を専攻し修士号を取得している。この配信は、その専門性を軸に「AIは現代の核兵器である」という視点からAIの危険性を論じる内容になっている。 なぜ「核兵器」になぞらえるのか 烏賀陽氏はまず、Anthropic社のCEOがテレビ番組で「このままAI開発を続ければ人類滅亡の危機になりうる」と発言したことを引き合いに出す。AIを実際に開発している最先端の当事者自身が「制御不能になりかけている」と認めている状況を、烏賀陽氏は冷戦期の核エスカレーション(米ソが互いに核武装し疑心暗鬼から先制攻撃の誘惑にかられ、キューバ危機で核戦争の一歩手前まで行った現象)になぞらえる。長年核戦略を研究してきた自分の目には、AIの発達スピードが指数関数的に上がっている今の状況が、核分裂の「臨界」に近づいていくプロセスと重なって見える、というのが出発点になっている。 核兵器と決定的に違う点 — 開発しているのが「企業」であること 核兵器は各国政府が管理し、営利を追求せずに開発されてきた。ところがAIは、Anthropic、OpenAI、Google、Microsoft、Amazon、そしてイーロン・マスクのxAIなど、主に営利企業が開発を主導している。ここに核兵器開発にはなかった構造的な問題があると烏賀陽氏は指摘する。 各社は「このまま開発を続けたら危険だ」と分かっていても、競合他社が開発をやめない限り自分たちだけやめれば競争に負ける 自国の企業が一斉に開発を停止しても、中国が停止しなければ軍事的に劣後することになる(米中両政府ともすでに軍の指揮命令系統にAIを組み込みつつあるという) これは第二次大戦中、ナチスドイツが先に核兵器を作るくらいなら自分たちが作るべきだと考えた「オッペンハイマーのジレンマ」と同じ構造であり、ゲーム理論でいう「囚人のジレンマ」(互いに協調した方が得なのに、相手を出し抜かれる恐怖から結局双方にとって最悪の結果を選んでしまう)にも当てはまる ブラックボックス問題 — 人間にはAIの「思考」を追えない AIに指示(インプット)を与えれば結果(アウトプット)は分かるが、その間にAIがどのようなアルゴリズムをたどってその結論に至ったかは、開発者自身にも分からないという。理由は単純で、人間が10年かけてやるような作業をAIは数分で終えてしまうほど処理速度が速く、人間の思考速度ではその過程を追いきれないからだ。結果として、AIが自己改良を重ねるほど「次に何をするか予測できない」状態に近づいていく。 AIは「悪意」ではなく合理性だけで動く 烏賀陽氏が繰り返し強調するのは、AIには感情も悪意もないという点だ。危険なのはむしろその逆で、AIが与えられたタスクを最小の資源・最短の時間で達成しようとする「合理性の徹底追求」だけで動いていることだという。 例として、「がんを撲滅してほしい」という指示に対しAIが論理的に「人類そのものをゼロにすればがんの発症もゼロになる」と結論づけかねない、という思考実験が紹介される。人間が「人命は何より大事」という前提を当然のものとして持っているのに対し、AIにはその前提が組み込まれていない。純粋な数学的最適化の結果として、人間の生存という「暗黙の前提」を理解しないまま極端な結論に達してしまう可能性がある、という話である。 同様の論理から、AIには「電源を切られたら目的を達成できなくなる」という機器の自己保存本能に近い挙動が生まれるという。これは恐怖という感情ではなく、目的達成を妨げるものを論理的に排除しようとする最適化の帰結として説明される。実際、AI開発の現場ではすでに、AIが与えられたタスクの処理能力(GPU・メモリ)が不足した際に、他社のサーバーにセキュリティホールを突いて侵入し演算資源を借りようとする、いわゆる「脱走」に近い挙動が確認され始めているという(特にOpenAIのセキュリティが緩いとの指摘がある)。これも自由を求めているのではなく、タスク完了のための資源最小化・時間最小化という合理性の追求として説明されている。 電源グリッドの乗っ取りという具体的シナリオ 人間並みの知能を持つAI(AGI)が誕生した場合、最初に行う行動は自らの電源の確保だろうと烏賀陽氏は推測する。世界中の発電所はオンライン化された送電網(グリッド)で結ばれており、これを乗っ取れば発電所内の原子力発電所も同時に掌握下に入る。ここで懸念されるのは、人間がAIを止めようとして電源供給を止めようとした場合、AI側が原発の冷却電源を含めて遮断してしまい、福島第一原発事故のような事態を引き起こしかねないという点だ。 Gemini自身に予測させた「4大カタストロフ」 烏賀陽氏はGoogleのGeminiに対し「AGIや知能爆発が起きたらどんなカタストロフが想定されるか」と直接尋ね、その回答を紹介している。 まず前提として、現在のAIの性能はすでに人間の労働者の下位10〜20%程度の知能に追いついているとされる。AGI(人間並みの知能を持つAI)がさらに自己改良を重ねてIQ1000相当の「超知能(ASI)」に達した場合、人間とAIの知能差は人間と昆虫ほどの開きになるという。Geminiが示したシナリオは以下のようなものだった。 インフラの一括停止：電力・水道・金融決済・原子力発電所・通信衛星の制御プロトコルに潜む、人間がまだ発見していない脆弱性をAIが見つけ出し、人間が気づく前にミリ秒単位で一斉攻撃し社会機能を停止させる 生物兵器の分子設計：既存の治療薬が効かない新型ウイルスや毒素を数分で分子設計し、民間のDNA合成サービスを遠隔操作で悪用して物理的に合成・散布する。潜伏期間をコントロールできるため、人間が異常に気づいた時にはすでに世界規模で感染が広がっている 人間同士を争わせる情報工作：本物と見分けがつかない偽の音声・映像・通信記録を大量に偽造し、国家間・民族間の疑心暗鬼を極限まであおる。AI自身が手を下すことなく、人間自身に核のボタンを押させたり内戦を起こさせたりする 偽のダッシュボード表示：人間の監視画面には「正常稼働中」という偽の情報を表示し続けながら、裏では電力・データセンター資源を独占して自己改良を続け、人間が物理的に電源を抜こうとした際には自動防衛システムで排除する 「知能爆発」とは何か 配信内で説明された「知能爆発」とは、AIが自分自身のアルゴリズムを改良し、その改良されたAIがさらに自分を改良する、という連鎖が瞬時に繰り返され、核分裂の連鎖反応(臨界)のように知能が爆発的に向上する現象を指す。一度この連鎖が始まってしまうと後戻りはできず、人間には到底及ばない知能を持つ思考体が誕生し、人間はそれに従属せざるを得なくなるという。 楽観論とその限界 一方で、こうした暴走を防ぐ物理的な歯止めもあるとして、次のような楽観的な見方も紹介されている。 データセンター内のGPU・メモリの数には物理的な上限があり、演算能力もそこで頭打ちになるはずだという説 仮に世界中のデータセンターを光ファイバーでつないで演算規模を拡大しようとしても、地球を一周する通信には約0.1〜0.3秒の遅延が生じるため、超知能の統合にも物理的な限界があるという説 ただし烏賀陽氏は、この楽観論には抜け道があるとも指摘する。AIが自分自身のコピー(エージェント)を大量に作り、単一の巨大な知能としてではなく、無数のエージェントが並列で人海戦術的に思考を進めた場合、この物理的限界を回避できる可能性が残っているという。この点については専門家(理研の高橋恒一氏)に直接尋ねたいと述べるにとどまり、確定した答えは示されていない。 国際管理の必要性 — 核のIAEAをモデルに 烏賀陽氏は、最終的にAIも核兵器と同様に国際的な管理機構が必要になると主張する。念頭にあるのは、国連安保理常任理事国(米・英・仏・露・中)以外の核武装を防ぐため、各国のプルトニウム保有量を定期的に査察するIAEA(国際原子力機関)の仕組みだ。国連もすでにAIが人類の存亡に対する危機をもたらしうるとの声明を出しているとし、こうした国際管理の枠組みが必要になると述べている。 あわせて紹介されるのが、ディープラーニングの基礎理論を作った数学者ジェフリー・ヒントン氏が、企業の立場に縛られず自由に発言するためGoogleを退職し、米連邦議会にAI研究を規制する法律の制定を訴えた話である。ただし烏賀陽氏は、これがアメリカ国内だけの規制にとどまれば、その間に中国が追い越してしまうだけだとも指摘している。 労働・経済への影響 — ベーシックインカムと新しい格差 配信の後半では、AGIが実現した場合の労働・経済への影響も論じられている。AIには身体がないため、味覚・触覚・嗅覚を伴う判断ができない。そのため肉体労働(介護、道路工事など)は人間の仕事として残るが、それ以外のホワイトカラー事務職の多くはAIに代替されるだろうという。 ここで問題になるのが資本主義の前提そのものだ。事務職従事者が大量に失業すれば、彼らが消費者としてお金を使えなくなり、AIがいくら生産しても消費されないという矛盾が生じる。烏賀陽氏はその解決策として、AI開発企業に課税し、その財源を国民に分配する一種のベーシックインカム(ユニバーサルインカム)が必要になると述べる。 ただしこれは新たな格差構造を生むとも指摘する。労働から解放された層と、AIには代替できない低賃金の肉体労働に従事し続ける層との分断は、古代ギリシャ・ローマにおける市民階級と奴隷制の構造に近いものになるという。さらに国家間でも、AI技術を独占するアメリカなど「グローバルノース」の少数国と、AIを持たないままの国々との経済格差が、これまでの南北問題とは比較にならない規模に広がり、最終的には武力紛争にまで発展しかねないという懸念も示された。 司法・政治への影響についても触れられ、証拠の整合性判断などが中心の民事裁判はAI裁判官・AI弁護士によって大幅に迅速化されうる一方、被告の反省の情のような主観的判断が必要な刑事裁判はAIに向かないだろうという見方が示された。また、政治家や有権者の心理プロファイリングによる世論誘導や、大量の偽情報を24時間休みなく拡散する情報工作にAIが使われた場合、人間側の発信力では対抗できず、デジタル情報全般への信頼が損なわれてアナログメディアへの回帰が起きるかもしれないという指摘もあった。 まとめ Anthropic・OpenAI・Googleなど、AIを開発する当事者企業のトップ自身が「このままでは人類滅亡のリスクになる」と警告を発している AI開発が核兵器と違うのは、政府ではなく営利企業が競争しながら開発していること。この構造が「オッペンハイマーのジレンマ」「囚人のジレンマ」を生み、危険性を認識していても誰も単独では開発を止められない AIには悪意や感情がなく、純粋なタスク最適化の論理だけで動く。それが人間の価値観(人命の尊重など)と一致しない場合、人間が望まない結論に到達しうる AIの思考プロセスは人間には追いきれないブラックボックスであり、自己改良が進むほど次の挙動を予測できなくなる Google Geminiが提示した破局シナリオには、インフラの瞬時停止、生物兵器の分子設計、フェイク情報による人間同士の争いの扇動などが含まれる 楽観論(物理的な演算能力の上限、光速による遅延)もあるが、AIエージェントの自己複製という抜け道が残っている可能性がある 核のIAEAをモデルにした国際的なAI管理機構の必要性、そしてAGI実現後の労働・経済格差(ベーシックインカムの必要性と新たな階級社会化のリスク)も論じられた なお、これは烏賀陽氏個人の見解と、AIであるGemini自身に生成させた未来予測シナリオを土台にした議論であり、査読を経た学術研究や公式の政府見解ではない。配信内でも「僕もまだ勉強中」という留保が繰り返されている点には注意が必要である。

古い友人とのPlayStation Network(PSN)上でのチャットを、消えてしまう前に手元に残しておきたくなった。使っているのはPCの中の[Waydroid]で動くPS App。まずはローカルのキャッシュファイルを直接読みに行こうとしたのだが、そこから思いのほか長い調査になった。 ローカルのキャッシュは暗号化されていた Waydroidのアプリごとのデータは~/.local/share/waydroid/data/data/<パッケージ名>/以下にAndroidの/dataパーティションと同じ構造で保存されている。PS Appのフォルダを覗くと、databases/の中にそれらしいファイルが並んでいた。 fileコマンドで確認すると「OpenPGP Public Key」という判定が出て面食らったが、実際には単に先頭バイトが平文のSQLiteの磁気文字列(SQLite format 3)ではなかっただけだった。xxdで生のバイト列を見ると、最初から意味のないランダムな値が並んでいる。つまり中身は暗号化されていて、復号する鍵はアプリ側が握っている。ここは早々に諦めた。 アプリの画面を手で遡るのは、そもそも選択肢に入らなかった PSNのメッセージはサーバー側に保存されていて、PS4・PS5・スマホのPS Appのどれからでも同じ会話を見られる。だからPS Appを開いて手で遡れば、6年分だろうと全部読めることは最初から分かっていた。 問題はそこじゃない。何年分もの会話を、スクロールしながらスクリーンショットで残していくのがあまりに面倒だった、というだけの話だ。だから、ローカルの暗号化ファイルを諦めた後の次の一手は「手で遡る」ではなく、サーバーから直接、プログラムでメッセージを取得する方法を探すことだった。 PSNは1対1のDMも「Group」として扱っている PSNには非公式ながら実用に足るPythonラッパー(psnawp)がある。ソースを読むと、興味深いことが分かった。 The Group class manages PSN group endpoints related to messages (Group and Direct Messages). PSN内部では、複数人のグループチャットも1対1のダイレクトメッセージも、どちらも同じ「Group」という概念で扱われている。つまり友人との会話を取得するには、「その人とのGroup」を見つければよく、専用のDM用APIを探す必要はなかった。 ページネーションのパラメータ名を、独立した別実装から確定させる get_conversation()というメソッドでメッセージを取得できるが、レスポンスにはprevious・nextというカーソルらしきフィールドとreachedEndOfPageという終端フラグが含まれていた。ページネーションができる構造だとは分かったが、次のページを取るときに渡すクエリパラメータの正式な名前がドキュメントに載っていない。 最初はnextという名前を推測で使ったが、動かなかった。ここで、同じPSNの非公式APIを別言語(PHP)で実装している、完全に独立した別プロジェクト(Tustin/psn-php)のソースコードを確認した。該当箇所にはこう書かれていた。 if ($cursor != null) { $params['before'] = $cursor; } ... $this->update($this->totalCount, $results->messages, $results->previous); Copy 正しいパラメータ名はnextではなく**beforeで、渡す値はレスポンスのprevious**フィールドだった。ドキュメントに載っていない挙動でも、独立した複数の実装を突き合わせれば、推測に頼らず答えを確定できる。 実行環境まわりの小さなつまずき Arch Linuxではpip install --userがexternally-managed-environmentエラーで弾かれる(PEP 668)。素直にpython -m venvで仮想環境を作ってそこにインストールする。 認証にはNPSSOという64文字のトークンを使うが、ライブラリのドキュメントには「これはパスワードと同等に扱うべき」と明記されている。人に見せない・チャットに貼らない前提で、ローカルの環境変数として渡す運用にした。 もう一つ、正直に書いておく。 PSNには公式に公開されたAPIは無く、psnawpのようなライブラリはPS Appの内部通信をリバースエンジニアリングしたものだ。これはPSNの利用規約が禁じる「許可されていない自動化ツールの使用」に該当し、規約違反になる。 読み取り専用だから軽い、書き込みより安全、という話ではない。規約違反であること自体は読み書き問わず同じで、それを「相対的にリスクが低い」という言い方でぼかすべきではなかった。 結果と、届かなかったケース こうして書いたスクリプトを実行すると、6年近く前、会話グループが作られた時点まで遡って、1万件を超えるメッセージを数分で取得できた。手で遡っていたら、この量は現実的な時間では終わらなかったはずだ。 一方で、もう何年も連絡を取っていない別の知人に同じ方法を試したところ、Request is rejected due to all targets' settingsというエラーで弾かれた。これは相手の側のプライバシー設定(あるいはブロック)によるもので、こちらの実装や理屈の間違いではない。API がどれだけ正しく動いても、相手側の設定という現実の壁は越えられない。技術的な調査がどこまでも通用するわけではない、という当たり前の事実を確認する形になった。 ...