言語 記事数 圧縮後 展開後推定 平均日本語 約150万 4.73GB 約25GB 約17kB/記事英語 約717万 26.2GB 約131GB 約18kB/記事フランス語 約275万 7.11GB 約36GB 約13kB/記事ドイツ語 約312万 8.10GB 約41GB 約13kB/記事イタリア語 約197万 4.35GB 約22GB 約11kB/記事中国語 約153万 3.47GB 約17GB 約11kB/記事韓国語 約74万 1.35GB 約6.8GB 約9kB/記事
On a Thread of the Web
芥川龍之介が「蜘蛛の糸」を発表して百年。高二の秋の文化祭,クラスの仮装行列のテーマが 蜘蛛の糸だった。お釈迦様の極楽タワーの竹を近所から切り出し,地獄の焔と煙の絵を描いた。犍陀多に続いて蜘蛛の糸(登山部の赤いザイル)に群がる地獄の亡者だったころ。
2026年4月29日水曜日
Wikipedia
2026年4月28日火曜日
業務端末とプライバシー
Q(koshix):
特に重要なのは、会社貸与端末であっても、従業員の人格的利益・プライバシー・個人情報性が完全に消えるわけではない、という点です。会社の所有物だから何でも見てよい、という構成にはなりません。
1.まず、端末パスワードについては、会社が「管理者権限」「MDM」「端末初期化権限」「業務アカウント停止・再発行権限」を持つことは合理的です。退職、事故、情報漏えい、業務継続、証拠保全のために、会社が端末・業務データへアクセスできる仕組みを持つ必要はあります。しかし、従業員本人のログインパスワードそのものを会社が常時把握する方式は、セキュリティ設計としても労務管理としても望ましくありません。パスワードは本来、本人認証の秘密情報です。会社が知ってしまうと、誰が操作したのかという証跡性が壊れます。つまり、後から「その操作は従業員本人がしたのか、管理者がしたのか」が曖昧になります。これは監視強化どころか、監査可能性を弱めます。
2.より妥当なのは、「会社はパスワードを知らないが、管理者権限により必要時にアカウント停止・再設定・端末回収・業務データ保全ができる」という設計です。例外的に、共有管理者アカウントや非常用アカウントを設ける場合でも、利用条件、承認者、ログ記録、事後監査を厳格にすべきです。従業員個人のパスワードを会社に提出させる方式は、原則として避けるべきです。
3.次に、操作ログについてです。ログイン時刻、端末識別子、業務システムへのアクセス履歴、ファイル操作、外部記憶媒体接続、マルウェア検知、異常通信、業務データの持ち出し兆候などは、情報セキュリティ上、取得の必要性が高い領域です。個人情報保護委員会も、個人データの取扱いに関する従業者の監督や安全管理措置の一環としてモニタリングを行う場合、目的の特定、社内規程化、従業者への明示、責任者・権限の設定、ルールに従った適正運用の確認が必要だとしています。(PPC)
4.一方で、「操作ログの全体」という表現が、キーストローク全記録、画面録画、Web閲覧全履歴、アプリ使用履歴の常時記録、チャット内容、メール本文、位置情報、カメラ・マイク、非業務時間の操作まで含むなら、かなり問題が大きくなります。これは単なる業務管理を超えて、人格的監視に近づきます。厚労省系の労働者個人情報保護の考え方でも、コンピュータ等によるモニタリングでは、実施理由、実施時間帯、収集される情報内容等を事前に通知し、労働者の権利を侵害しないよう配慮すべきとされ、常時モニタリングは健康・安全確保または業務上の財産保全に必要な場合に限られる、という考え方が示されています。(厚生労働省)
5.ここで「契約によって同意を取っているからよいのではないか」という点が問題になります。たしかに、従業員が業務端末利用規程、情報セキュリティ規程、就業規則、誓約書などでログ取得に同意していることは、会社側の正当化要素になります。しかし、雇用関係では使用者と労働者の力関係が非対称です。形式的な同意があっても、それが自由で実質的な同意だったのかは常に問題になります。また、就業規則が労働契約の内容となるには、合理的な労働条件であり、かつ労働者に周知されていることが必要です。(e-Gov 법令検索)
6.したがって、契約条項として「会社は従業員の端末操作ログを全て取得・閲覧できる」「従業員は全パスワードを会社に開示する」と包括的に書いても、それだけで無制限に有効になるわけではありません。個人情報保護法上も、個人情報の利用は特定された利用目的の達成に必要な範囲に限られ、目的を超える取扱いには原則として本人同意が必要です。さらに、安全管理措置はリスクに応じて必要かつ適切な内容でなければならないとされています。(PPC)
妥当な設計は、次のような線引きになります。
(1)会社が取得してよい可能性が高いものは、業務システムへのアクセスログ、ログイン・ログアウト、端末のセキュリティ状態、業務ファイルのアクセス・変更・持ち出し、外部媒体接続、異常通信、マルウェア検知、管理対象アプリの利用状況などです。目的は、情報漏えい防止、業務継続、法令遵守、内部不正対策、インシデント対応に限定すべきです。
(2)慎重であるべきものは、メール本文、チャット本文、Web閲覧の詳細、画面キャプチャ、スクリーン録画、位置情報、カメラ・マイク、キーログ、勤務時間外の操作、私的利用が混入し得る領域です。これらは「必要がある場合に、限定された権限者が、限定された目的で、限定された範囲を確認する」運用にすべきです。
(3)原則避けるべきものは、従業員個人のパスワード提出、常時キーロギング、常時画面録画、業務と無関係な私的情報の網羅的取得、本人に知らせない通常時の隠密監視です。ただし、犯罪・重大不正の相当な疑いがある場合には、証拠保全として例外的調査が許容される余地はありますが、それでも必要性・相当性・手続の適正が問われます。
私の評価では、「会社貸与端末だから包括的に全部把握できる」という企業側の論理は粗すぎます。一方で、「従業員のプライバシーがあるから会社はログを取れない」という反対論も、情報セキュリティの現実を無視しています。妥当な中心線は、会社の所有権ではなく、業務目的との関連性、情報セキュリティ上の必要性、取得範囲の最小化、事前明示、権限管理、監査可能性によって決まります。
実務的には、契約書に包括条項を書くよりも、次のような制度設計が重要です。端末は会社所有で業務目的に使用すること、会社は明示された目的のために一定のログを取得すること、取得するログの種類を具体的に列挙すること、通常時に本文・画面・キーストロークまでは見ないこと、例外調査の発動条件を定めること、閲覧権限者を限定すること、ログ保存期間を定めること、従業員本人に周知すること、労働組合または従業員代表との協議・説明を行うこと、ログ閲覧自体のログを残すことです。
要するに、妥当な契約は「会社が必要な範囲で業務端末を管理し、限定されたログを取得することへの同意」であって、「会社が従業員の端末上の全行動とパスワードを丸ごと支配することへの同意」ではありません。後者は、労務管理、個人情報保護、情報セキュリティ、内部統制のいずれの観点から見ても、かなり危険な設計です。
2026年4月27日月曜日
人員削減
米国のテック大手での大規模人員削減が続いています。これを整理してください。人数やパーセンテージなど。また,その原因を分析してください。さらに,メタの「米メタ、社員のパソコン操作データを強制収集 AI開発に利用」との関連についても考察してください。
A(ChatGPT):
(回答略,8000字)
Q(koshix):
上記の話を1000字程度に要約してください。重要なポイントは欠落しないようにお願いします。
A(ChatGPT):
米国テック大手の大規模人員削減は、単なる景気後退やコロナ期の過剰採用の反動だけでは説明できなくなっています。2022〜23年には、パンデミック期に急拡大した人員の調整という性格が強く、Meta、Amazon、Google、Microsoftなどが数万人規模で削減を行いました。しかし2024〜26年にかけては、削減の意味が変わり、AI投資を中核にした組織再編の色合いが濃くなっています。
Metaは約8,000人、全社員の約10%削減を予定し、Microsoftは米国社員約8,750人に自主退職制度を提示、Amazonも2025年秋以降で約3万人規模(〜10%)の削減が報じられています。Intelは約22%の人員縮小方針を示し、Google、Salesforce、Cisco、Appleでも部門別・継続的な削減が進んでいます。業界全体でも、2023年の巨大削減で終わらず、2025〜26年にも削減の波が続いています。
原因は複合的です。第一に、コロナ期の需要急増を前提にした過剰採用の修正があります。第二に、生成AIとデータセンターへの投資が極端に重くなり、人件費を抑えてGPU、電力、クラウド基盤、AI人材へ資源を移す必要が生じています。第三に、AIによる業務の部分代替が現実化し、コード作成、テスト、文書作成、営業支援、データ分析、人事・社内事務などのタスクが圧縮対象になっています。第四に、投資家に対して「効率化」を示す経営上の圧力もあります。AIは本当の技術要因であると同時に、従来型のコスト削減を正当化する言葉にもなっています。
Metaの「社員のパソコン操作データを強制収集し、AI開発に利用する」という動きは、この流れと深く関係します。これは単なる社員監視ではなく、社員が業務用PC上でどの順序で作業し、どこをクリックし、どのように入力し、どこで判断するかという労働過程そのものをAI訓練データ化するものです。従来のAIは文書、画像、コード、対話ログを主な教材としてきましたが、業務を自律的にこなすAIエージェントを作るには、人間の画面操作と判断過程のデータが必要になります。
したがって、人員削減と操作データ収集は、直接の一対一の因果関係というより、同じ戦略の二つの側面です。一方で社員を減らし、他方で残る社員の業務プロセスをAIに学習させる。企業は個々の社員に属していた経験知や作業手順を、組織のAI資産へ移し替えようとしています。これはホワイトカラー業務における新しいテイラー主義とも言えます。
ただし、操作ログを集めればすぐに社員を完全代替できるわけではありません。責任判断、顧客関係、例外処理、法務・倫理的判断などは依然として人間に残ります。それでも、定型的な社内事務、分析補助、営業事務、簡単なコーディング、レポート作成などは確実に圧縮されやすい。結局、現在の人員削減は「AIがすでに人間を全面代替した結果」ではなく、「AIが将来代替・圧縮しうる仕事を先取りして、企業が労働構成と資本配分を作り替えている過程」と見るのが妥当です。
2026年4月26日日曜日
Claude Mythos
2026年4月25日土曜日
豊福モデル
2026年4月24日金曜日
ヘロンの公式
2026年4月23日木曜日
線形代数学
4月に入って線形代数学に凝っている。発端は量子リソース理論なのだが,それはちょっと置いといて,線形代数の基本がわかっていないと量子力学の基礎も心もとないので,復習しているのだ。教養課程では,大嶋勝・佐藤正次の基礎課程 線形代数学の薄い教科書を大島先生の授業でさらっと習っただけなのだ。
2026年4月22日水曜日
デジタルアドレス
2026年4月21日火曜日
ヒマワリ
放送大学の自然科学の授業で,岸根順一郎さんが向日葵の種の配列のシミュレーションを見せていた。自然は黄金比を選んでいるというわけだ。バラメタを少し変えるといろいろな模様が出現する。
Q(koshix):Jupyter環境で,次のJulia プログラムをつくってください。 向日葵の種(塗りつぶした色つき小円でよい)の分布が 1粒ずつ内側から充足されていくインラインアニメーション。 これで意味が分かりますか? なるべく簡素で高速なものにしてください。
2026年4月20日月曜日
超知能と人類の滅亡(2)
2026年4月19日日曜日
超知能と人類の滅亡(1)
2026年4月18日土曜日
物理学者(1)
PREFIX wd: <http://www.wikidata.org/entity/> PREFIX wdt: <http://www.wikidata.org/prop/direct/> PREFIX schema: <http://schema.org/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX bd: <http://www.bigdata.com/rdf#> PREFIX wikibase: <http://wikiba.se/ontology#> SELECT DISTINCT ?person ?personLabel ?dateOfBirth ?dateOfDeath ?sitelinks ?fieldLabel ?enArticle WHERE { ?person wdt:P31 wd:Q5 ; wdt:P106/wdt:P279* wd:Q169470 ; wdt:P569 ?dateOfBirth ; wdt:P570 ?dateOfDeath ; wdt:P101 ?field ; wikibase:sitelinks ?sitelinks . ?field wdt:P279* wd:Q413 . FILTER("0000-00-00T00:00:00Z"^^xsd:dateTime <= ?dateOfBirth && ?dateOfBirth < "1936-01-01T00:00:00Z"^^xsd:dateTime) FILTER(?sitelinks >= 7) ?enArticle schema:about ?person ; schema:isPartOf <https://en.wikipedia.org/> . FILTER(!CONTAINS(STR(?enArticle), "/wiki/Category:")) ?deArticle schema:about ?person ; schema:isPartOf <https://de.wikipedia.org/> . ?frArticle schema:about ?person ; schema:isPartOf <https://fr.wikipedia.org/> . ?ruArticle schema:about ?person ; schema:isPartOf <https://ru.wikipedia.org/> .
?itArticle schema:about ?person ; schema:isPartOf <https://it.wikipedia.org/> . MINUS { ?jaArticle schema:about ?person ; schema:isPartOf <https://ja.wikipedia.org/> . } SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } } ORDER BY DESC(?sitelinks) ?dateOfBirth ?personLabel LIMIT 1000