|
|
|
|
|
||
|
||
2026/05/15(金)金曜日ー。（どれくらいのカジュアル？）
[雑談] いろいろ。
「【機密】昇進リスト先行公開、VPNでアクセスを」巧妙な詐欺メールが拡散中 「給与改定」「交通費改定」版も - ITmedia NEWS
「【機密】昇進リスト先行公開、VPNでアクセスを」巧妙な詐欺メールが拡散中 「給与改定」「交通費改定」版も
「給与改定」「人事評価および昇進対象者リストの先行公開について」――会社員なら気になる件名の詐欺メールが、5月上旬ごろから出回っている。
https://www.itmedia.co.jp
企業も「振り込め詐欺」に狙われている！ 業務フローの隙を突いたり、社内外の信頼関係を悪用したりする手口を知っておこう【読めば身に付くネットリテラシー】 - INTERNET Watch
企業も「振り込め詐欺」に狙われている！ 業務フローの隙を突いたり、社内外の信頼関係を悪用したりする手口を知っておこう【読めば身に付くネットリテラシー】
企業を狙う「振り込め詐欺」の被害が、国内外で次々に起きています。かつては、不自然な文章のメールや、身に覚えのない取引先からの請求書に気を付ければ大丈夫と考えられていました。ところが昨今の手口は、実在
https://internet.watch.impress.co.jp
「Linux」カーネルに三たび重大な脆弱性が見つかる--AIツールの登場で加速 - ZDNET Japan
「Linux」カーネルに三たび重大な脆弱性が見つかる--AIツールの登場で加速
「Linux」カーネルに最新の深刻な脆弱性「Fragnesia」が見つかった。Claude MythosなどのAIツールの登場でバグ発見が相次いでおり、ローカルのルート権限に関する深刻な脆弱性の発見は
https://japan.zdnet.com
Claudeがパスワード忘れで11年間アクセス不能なビットコインを救出、6300万円の価値に バックアップファイルの解析とツールの不具合修正で復元を支援｜FinTech Journal
Claudeがパスワード忘れで11年間アクセス不能なビットコインを救出、6300万円の価値に
米Anthropic社のAIモデル「Claude」を活用し、11年間にわたりアクセス不能だった仮想通貨ウォレットから、5BTCを復元した。回復された5BTCは現在、約40万ドル（6300万円）の価値が
https://www.sbbit.jp
Amazonの従業員がランキング上位を目指し上司に好印象を与えるためにAIの使用量を水増ししていることが判明 - GIGAZINE
Amazonの従業員がランキング上位を目指し上司に好印象を与えるためにAIの使用量を水増ししていることが判明
Amazonの従業員が、管理職への印象を良くするために社内AIツールを不必要に使い続けているという話を共有しました。
https://gigazine.net
AI｢間違って全データを消してしまいました。申し訳ありません｣ | ギズモード・ジャパン
AI｢間違って全データを消してしまいました。申し訳ありません｣
9秒で何もかも消えてなくなるなんて…。4月25日、SaaS（Software as a Service：クラウド経由でソフトウェアを提供するサービス）企業PocketOSの創業者が、X（旧Twitt
https://www.gizmodo.jp
なぜ？ マクドナルド「巨大セルフ注文端末」に批判殺到の理由 UI／UXに価格表示まで……直面している課題とは - ITmedia Mobile
なぜ？ マクドナルド「巨大セルフ注文端末」に批判殺到の理由 UI／UXに価格表示まで……直面している課題とは
マクドナルドが全国の店舗に導入している巨大な店頭注文用タッチパネルのUIに対しSNSで不満が噴出している。特に注文の最終段階まで合計価格が表示されない仕様が予算を意識するユーザーにとって大きな障壁だ。
https://www.itmedia.co.jp
ボリュームある生協の弁当をよく見ると……「ガチで何事www」 “まさかのおかず”に「えええええ」「これは反則」（1/2） | ライフスタイル ねとらぼ
ボリュームある生協の弁当をよく見ると……「ガチで何事www」 “まさかのおかず”に「えええええ」「これは反則」（1/2） | ライフスタイル ねとらぼ
市販のお弁当に入っていた一品が、X（Twitter）でさまざまな意見を呼んでいます。投稿は記事執筆時点で290万回以上表示され、2万件以上の“いいね”を獲得しています。焼肉のお弁当にサラダ菜のアクセ
https://nlab.itmedia.co.jp
VLCC タンカー ENEOS ENDEAVOR
■ 2026 年 5 月のセキュリティ更新プログラム (月例)
(Microsoft, 2026.05.12)
Microsoft 2026.05 更新。
137 Microsoft CVE + 128 non-MS CVE (大半は Edge)。
.NET CVE-2026-26171 CVE-2026-32178
.NET and Visual Studio CVE-2026-32203
.NET Framework CVE-2026-23666 CVE-2026-32226
.NET, .NET Framework, Visual Studio CVE-2026-33116
Applocker Filter Driver (applockerfltr.sys) CVE-2026-25184
Azure Logic Apps CVE-2026-32171
Azure Monitor Agent CVE-2026-32168 CVE-2026-32192
Desktop Window Manager CVE-2026-27923 CVE-2026-27924 CVE-2026-32152 CVE-2026-32154 CVE-2026-32155
Function Discovery Service (fdwsd.dll) CVE-2026-32086 CVE-2026-32087 CVE-2026-32093 CVE-2026-32150
GitHub Copilot and Visual Studio Code CVE-2026-23653
GitHub Repo: Git for Windows CVE-2026-32631
Input-Output Memory Management Unit (IOMMU) CVE-2023-20585
Microsoft Brokering File System CVE-2026-26181 CVE-2026-32091 CVE-2026-32219
Microsoft Defender CVE-2026-33825
Microsoft Dynamics 365 (on-premises) CVE-2026-33103
Microsoft Edge (Chromium-based) CVE-2026-33118 CVE-2026-33119 CVE-2026-5272 CVE-2026-5273 CVE-2026-5274 CVE-2026-5275 CVE-2026-5276 CVE-2026-5277 CVE-2026-5279 CVE-2026-5280 CVE-2026-5281 CVE-2026-5283 CVE-2026-5284 CVE-2026-5285 CVE-2026-5286 CVE-2026-5287 CVE-2026-5289 CVE-2026-5290 CVE-2026-5291 CVE-2026-5292 CVE-2026-5858 CVE-2026-5859 CVE-2026-5860 CVE-2026-5861 CVE-2026-5862 CVE-2026-5863 CVE-2026-5864 CVE-2026-5865 CVE-2026-5866 CVE-2026-5867 CVE-2026-5868 CVE-2026-5869 CVE-2026-5870 CVE-2026-5871 CVE-2026-5872 CVE-2026-5873 CVE-2026-5874 CVE-2026-5875 CVE-2026-5876 CVE-2026-5877 CVE-2026-5878 CVE-2026-5879 CVE-2026-5880 CVE-2026-5881 CVE-2026-5882 CVE-2026-5883 CVE-2026-5884 CVE-2026-5885 CVE-2026-5886 CVE-2026-5887 CVE-2026-5888 CVE-2026-5889 CVE-2026-5890 CVE-2026-5891 CVE-2026-5892 CVE-2026-5893 CVE-2026-5894 CVE-2026-5895 CVE-2026-5896 CVE-2026-5897 CVE-2026-5898 CVE-2026-5899 CVE-2026-5900 CVE-2026-5901 CVE-2026-5902 CVE-2026-5903 CVE-2026-5904 CVE-2026-5905 CVE-2026-5906 CVE-2026-5907 CVE-2026-5908 CVE-2026-5909 CVE-2026-5910 CVE-2026-5911 CVE-2026-5912 CVE-2026-5913 CVE-2026-5914 CVE-2026-5915 CVE-2026-5918 CVE-2026-5919
Microsoft Graphics Component CVE-2026-32221
Microsoft High Performance Compute Pack (HPC) CVE-2026-32184
Microsoft Management Console CVE-2026-27914
Microsoft Office CVE-2026-32190
Microsoft Office Excel CVE-2026-32188 CVE-2026-32189 CVE-2026-32197 CVE-2026-32198 CVE-2026-32199
Microsoft Office PowerPoint CVE-2026-32200
Microsoft Office SharePoint CVE-2026-20945 CVE-2026-32201
Microsoft Office Word CVE-2026-23657 CVE-2026-33095 CVE-2026-33114 CVE-2026-33115 CVE-2026-33822
Microsoft Power Apps CVE-2026-26149
Microsoft PowerShell CVE-2026-26143 CVE-2026-26170
Microsoft Windows CVE-2026-32181
Microsoft Windows Search Component CVE-2026-27909
Microsoft Windows Speech CVE-2026-32153
Node.js CVE-2026-21637
Remote Desktop Client CVE-2026-32157
Role: Windows Hyper-V CVE-2026-26156 CVE-2026-32149
SQL Server CVE-2026-32167 CVE-2026-32176 CVE-2026-33120
Universal Plug and Play (upnp.dll) CVE-2026-32212 CVE-2026-32214
Windows Active Directory CVE-2026-32072 CVE-2026-33826
Windows Admin Center CVE-2026-32196
Windows Advanced Rasterization Platform CVE-2026-26178
Windows Ancillary Function Driver for WinSock CVE-2026-26168 CVE-2026-26173 CVE-2026-26177 CVE-2026-26182 CVE-2026-27922 CVE-2026-32073 CVE-2026-33099 CVE-2026-33100
Windows Biometric Service CVE-2026-32088
Windows BitLocker CVE-2026-27913
Windows Boot Loader CVE-2026-0390
Windows Boot Manager CVE-2026-26175
Windows Client Side Caching driver (csc.sys) CVE-2026-26176
Windows Cloud Files Mini Filter Driver CVE-2026-27926
Windows COM CVE-2026-20806 CVE-2026-32162
Windows Common Log File System Driver CVE-2026-32070
Windows Container Isolation FS Filter Driver CVE-2026-33098
Windows Cryptographic Services CVE-2026-26152
Windows Encrypting File System (EFS) CVE-2026-26153
Windows File Explorer CVE-2026-32079 CVE-2026-32081 CVE-2026-32084
Windows GDI CVE-2026-27930 CVE-2026-27931
Windows Hello CVE-2026-27906 CVE-2026-27928
Windows HTTP.sys CVE-2026-33096
Windows IKE Extension CVE-2026-33824
Windows Installer CVE-2026-27910
Windows Kerberos CVE-2026-27912
Windows Kernel CVE-2026-26163 CVE-2026-26179 CVE-2026-26180 CVE-2026-32195 CVE-2026-32215 CVE-2026-32217 CVE-2026-32218
Windows Kernel Memory CVE-2026-26169
Windows Local Security Authority Subsystem Service (LSASS) CVE-2026-26155 CVE-2026-32071
Windows LUAFV CVE-2026-27929
Windows Management Services CVE-2026-20930
Windows OLE CVE-2026-26162
Windows Print Spooler Components CVE-2026-33101
Windows Projected File System CVE-2026-26184 CVE-2026-27927 CVE-2026-32069 CVE-2026-32074 CVE-2026-32078
Windows Push Notifications CVE-2026-26167 CVE-2026-26172 CVE-2026-32158 CVE-2026-32159 CVE-2026-32160
Windows Recovery Environment Agent CVE-2026-20928
Windows Redirected Drive Buffering CVE-2026-32216
Windows Remote Desktop CVE-2026-26151
Windows Remote Desktop Licensing Service CVE-2026-26159 CVE-2026-26160
Windows Remote Procedure Call CVE-2026-32085
Windows RPC API CVE-2026-26183
Windows Secure Boot CVE-2026-25250
Windows Sensor Data Service CVE-2026-26161
Windows Server Update Service CVE-2026-26154 CVE-2026-26174 CVE-2026-32224
Windows Shell CVE-2026-26165 CVE-2026-26166 CVE-2026-27918 CVE-2026-32151 CVE-2026-32202 CVE-2026-32225
Windows Snipping Tool CVE-2026-32183 CVE-2026-33829
Windows Speech Brokered Api CVE-2026-32089 CVE-2026-32090
Windows SSDP Service CVE-2026-32068 CVE-2026-32082 CVE-2026-32083
Windows Storage Spaces Controller CVE-2026-27907 CVE-2026-32076
Windows TCP/IP CVE-2026-27921 CVE-2026-33827
Windows TDI Translation Driver (tdx.sys) CVE-2026-27908
Windows Universal Plug and Play (UPnP) Device Host CVE-2026-27915 CVE-2026-27916 CVE-2026-27919 CVE-2026-27920 CVE-2026-27925 CVE-2026-32075 CVE-2026-32077 CVE-2026-32156
Windows USB Print Driver CVE-2026-32223
Windows User Interface Core CVE-2026-27911 CVE-2026-32163 CVE-2026-32164 CVE-2026-32165
Windows Virtualization-Based Security (VBS) Enclave CVE-2026-23670 CVE-2026-32220
Windows WalletService CVE-2026-32080
Windows WFP NDIS Lightweight Filter Driver (wfplwfs.sys) CVE-2026-27917
Windows Win32K - GRFX CVE-2026-33104
Windows Win32K - ICOMP CVE-2026-32222
0-day は無いようです。
ヤバいものとして挙げられているのは:
今月のセキュリティ更新プログラムで修正した脆弱性のうち、以下の脆弱性は、CVSS 基本値が 9.8 以上と高いスコアで、認証やユーザーの操作なしで悪用が可能な脆弱性です。(中略)
CVE-2026-42898 Microsoft Dynamics 365 オンプレミスのリモートでコードが実行される脆弱性
CVE-2026-42823 Azure Logic Apps の特権昇格の脆弱性
CVE-2026-41096 Windows DNS クライアントのリモートでコードが実行される脆弱性
CVE-2026-41089 Windows Netlogon のリモートでコードが実行される脆弱性
うぉぅ DNS ねた。
CVE-2026-41096 Windows DNS クライアントのリモートでコードが実行される脆弱性
(Microsoft, 2026.05.12)。CVSS:3.1 9.8 / 8.5。
対象 OS は Windows 11 / Server 2025 のみ。
攻撃者はこの脆弱性をどのように悪用する可能性がありますか?
攻撃者は、特別に細工された DNS 応答を脆弱な Windows システムに送信することによって、この脆弱性を悪用し、DNS クライアントに応答を正しく処理させないようにしてメモリを破損させる可能性があります。特定の構成では、これにより、攻撃者が認証なしで影響を受けるシステムでコードをリモートで実行できるようになる可能性があります。
攻略 DNS 応答で RCE。
「悪用される可能性は非常に低い」とされているので、
「特定の構成」の条件がかなり厳しいのかもしれない。
関連:
【Windows11】 WindowsUpdate 2026年5月 不具合情報 - セキュリティ更新プログラム KB5089549 ［Update 1］ (ニッチなPCゲーマーの環境構築Z, 2025.05.14 更新)
【Windows10】 WindowsUpdate 2026年5月 不具合情報 - セキュリティ更新プログラム KB5087544 ［Update 1］ (ニッチなPCゲーマーの環境構築Z, 2025.05.14 更新)
『C:\Windows\SecureBoot』が新たに作成される。KB5089549等のインストール後に。このフォルダはいったい (ニッチなPCゲーマーの環境構築Z, 2025.05.14 更新)
Intel 各種
インテルがセキュリティ情報を公開 ～Intel Graphicsに深刻度CRITICALの脆弱性 (窓の杜, 2026.05.14)
INTEL-SA-01457 - Intel Vision Software Advisory (Intel, 2026.05.12)
INTEL-SA-01438 - AI Playground Software Advisory (Intel, 2026.05.12)
INTEL-SA-01434 - Intel EMA Software Advisory (Intel, 2026.05.12)
INTEL-SA-01430 - Display Virtualization for Windows OS Advisory (Intel, 2026.05.12)
INTEL-SA-01429 - Intel Connectivity Performance Suite Software Installer Advisory (Intel, 2026.05.12)
INTEL-SA-01426 - Intel 800 Series Ethernet Linux Driver Advisory (Intel, 2026.05.12)
INTEL-SA-01425 - Intel Slim Bootloader Advisory (Intel, 2026.05.12)
INTEL-SA-01424 - Intel NPU Driver Advisory (Intel, 2026.05.12)
INTEL-SA-01420 - 2026.2 IPU - Intel Processor Firmware Advisory (Intel, 2026.05.12)
INTEL-SA-01413 - UEFI Reference Firmware Advisory (Intel, 2026.05.12)
INTEL-SA-01410 - Intel Server Firmware Update Utility Software Advisory (Intel, 2026.05.12)
INTEL-SA-01402 - Intel Graphics Advisory (Intel, 2026.05.12)
INTEL-SA-01387 - Intel QAT Software Drivers for Windows Advisory (Intel, 2026.05.12)
Zoom
Zoomがセキュリティ情報を発表 ～最大深刻度はHigh (窓の杜, 2026.05.13)
dnsmasq
dnsmasq contains several vulnerabilities, including attacker DNS redirect, privilege escalation, and heap manipulation -
Vulnerability Note VU#471747 (CERT/CC, 2026.05.11)。
dnsmasq に複数の欠陥。
DeepL AI 訳:
DoS (CVE-2026-2291、CVE-2026-4890、CVE-2026-5172) — dnsmasq がクラッシュしたり応答しなくなったりする可能性があり、その結果、DNS 解決が停止し、関連するサービスに影響が及ぶ恐れがあります。
キャッシュポイズニング／リダイレクト (CVE-2026-2291, CVE-2026-4893) — 攻撃者はキャッシュエントリを上書きしたり、レスポンスのルーティングを操作したりすることで、ユーザーを悪意のあるドメインへ気付かれずにリダイレクトさせることが可能です。
情報漏洩 (CVE-2026-4891, CVE-2026-4893) — 内部メモリおよびネットワーク情報が意図せず漏洩する可能性があります。
ローカル特権昇格 (CVE-2026-4892) — ローカルの攻撃者が、DHCPv6を悪用することで、root権限で任意のコードを実行する可能性があります。
dnsmasq 2.92rel2 で修正されている。
■ 追記
Linux KernelのLPE(Local Privilege Escalation)脆弱性(Dirty Frag: CVE-2026-43284, CVE-2026-43500) (2026.05.08)
Dirty Frag 脆弱性クラス (class) に属すると自称する Fragnesia が登場。 CVE-2026-46300。
回避方法は Dirty Frag と同様でよいそうで。
60
Microsoft 製品の脆弱性対策について(2026年5月)
「GUARDIANWALL MailSuite」におけるスタックベースのバッファオーバーフローの脆弱性について（JVN#35567473）
最終更新日：2026/05/13
JVN#35567473:
GUARDIANWALL MailSuiteにおけるスタックベースのバッファオーバーフローの脆弱性 [2026/05/13 16:15]（更新）
JVN#24167657:
Androidアプリ「あんしんフィルター for au」における重要情報の平文送信の脆弱性 [2026/05/13 12:00]
JVN#98871848:
Bytello Share（Windows版）のEXE形式インストーラにおけるDLL読み込みに関する脆弱性 [2026/05/13 12:00]
JVNVU#96777324:
Intel製品に対するアップデート（2026年5月） [2026/05/13 11:15]
JVNVU#99296478:
Siemens製品に対するアップデート（2026年5月） [2026/05/13 09:15]
JVNVU#97068023:
CISA ICS Advisory / ICS Medical Advisory（2026年05月12日） [2026/05/13 09:15]
JVN#94012927:
エレコム無線LAN関連製品における複数の脆弱性 [2026/05/12 14:15]
JVN#24885537:
エレコム製無線LANルーターおよび無線アクセスポイントにおける複数の脆弱性 [2026/05/12 14:15]
JVN#06672778:
エレコム製無線LANルーターにおける複数の脆弱性 [2026/05/12 14:15]
JVNVU#95381465:
エレコム製無線LANルーターにおける複数の脆弱性 [2026/05/12 14:15]
JVNVU#90908488:
エレコム製無線LANルーターにおけるOSコマンドインジェクションの脆弱性 [2026/05/12 14:15]
JVNVU#91630351:
エレコム製およびロジテック製ネットワーク機器における複数の脆弱性 [2026/05/12 14:15]
JVN#03037325:
エレコム製無線LANルーターおよび無線アクセスポイントにおける複数の脆弱性（2026年5月） [2026/05/12 14:00]
JVN#38788367:
GROWIにおけるパストラバーサルの脆弱性 [2026/05/11 15:00]
JVNVU#90880682:
Ollamaにおける境界外の読み取りおよび書き込みの脆弱性 [2026/05/11 14:00]
■ 2026.05.11: 晴
》 JP
【安い】AliExpressで見つけた謎の超音波カッター【FS-F1】 (コスパガジェット探検隊 / YouTube, 4/18)。
よさげなので、私もとりあえず FS-S1 (バッテリー非塔載型) を買ってみた。
まだ試してない。
2026-05-05
SecHack365の2026年度融合駆動コースについて
SecHack365の2026年度融合駆動コースについて
今年度のSecHack365は10周年を迎え、まぁまぁ様子が変わります。コース制になってから8年くらいだっけ（笑）？数年前にも変革かなーってぼんやり考えてたりはしましたが、コロナ禍でそれどころじゃなくなったりして（笑）ある意味延命延命で2025年まで来ちゃいました。中身は段々変わってきてたんですけどね。
で、今回学習駆動コースを離れ、コンテンツゼミ＆社会実装ゼミのコンセプトを継ぎつつ、融合を目指すことにしました。あっしは何かを発想するとき、頭の回路的に異質なものの組み合わせをシミュレートすることが多いのですが、異質なものを組み合わせて融合させる、それを社会に届ける、みたいなものがこのコースの目標です。以下コース紹介より。
https://sechack365.nict.go.jp/course/#c06
Q.どのようなコースですか？1年間でどんなことをやりますか？
A.「社会実装」という言葉をご存じですか？ ツールを作成しても利用者がいないと意味がありませんし、コンテンツを公開しても視聴者が増えないなら不十分です。本コースは「作ること」よりも「世間に浸透させること」を目指します。作るものはすべて歓迎です。セキュリティ関連のシステムやソフト開発から、研究論文、小説、動画、アートまで。これまでには毎日ひとことセキュリティトークしてくれるアヒルやセキュリティ料理のレシピという作品もありました。重要なのは「作品をどう公開し、ユーザーを増やすか（世の中に浸透させるか）」という視点です。
単なる完成品を作るのではなく、それを使いこなす人が増えるまで社会に実装していく経験を通じて、あなたの価値観を広げます。
Q.どのようにセキュリティの知識や意識を身につけますか？ 何を目標としますか？
A.単なるツールやコンテンツ作成ではなく、「なぜその課題が起きているのか」を分析し、根本的なメカニズムを理解するアプローチです。
セキュリティの社会的課題に対し、独自の視点で問いを立て、解決法を具現化する発想法やものづくりを学びます。最終的には、抽象度の高い啓蒙活動から、ランサムウェア対策やロマンス詐欺防止といった具体的な課題まで、社会実装の視座から多角的に対応する力を身につけます。
Q.期待する応募者像、応募者に求めるものは？
A.「セキュリティを学びたい」だけでなく、「社会課題解決に取り組みたい」という熱意を持っている方に向いています。
具体的な技術（コードなど）よりも、社会へのインパクトやストーリーテリングに価値を感じる方
ユニークで自分だけのニッチなセキュリティ課題を見つけたい方
「啓発コンテンツ作成」や「ランサムウェア対策」「詐欺防止」など、多様なアプローチを好む方
世界で唯一の視点で、社会に届く何か、人々の役に立つ何かを生み出してみませんか？
ってなところです。
とはいえ、何に取り組むべきか、そもそもそこから悩むこともあるかも知れません。そんなときは以下のようなテーマで挑むことを考えてみてください。
人が騙されにくくなる何か
人がやっていて大変なことを肩代わりしてくれる何か（例：生成AI時代にどこも苦労しているデータのアノテーションとか）
便利で安全なのに人が使い切れていない、使いこなせていないパスキーなどの方法を広く使ってもらうための何か
人の現在の能力を可視化する何か（例：情報検索力、特定分野の学習能力やスキル、コミュニティやチームにおける会話から見える影響力など）
人と人のコミュニケーションを安全にサポートする何か
人のメンタルの可視化（例：そのコミュニケーション環境で人が病むかどうかをAIによって調べる＝カナリアなど）
人に対する（セキュリティに関する）トレーニングの効果の可視化
ヒューマンファクターの評価や向上に資する何か
社会インフラの安全性や性能向上を目指したトラスト基盤に繋がる何か
これらのテーマは社会的課題の裏返しです。逆に言えば、テーマ案から社会的課題に遡って、そちらに取り組む、ということでもOKです。
作るモノは何でもOKです。研究論文小説ゲーム動画コンテンツ漫画システムツールアプリサービス書籍など。過去には喋るアヒルや固定電話用の詐欺検知装置などのハードウェアもありましたし、そういうものでもOKです。
みなさんの野心的な挑戦をお待ちしています。
#SecHack365 #cybersecurity #Hackathon
sonodam 2026-05-05 14:54 読者になる
もっと読む
コメントを書く
SecHack365の2026年度融合駆動コースについて
▼ ▶
2026
2026 / 5
2026-04-28
2024年ページビューランキングTOP20（2025年1月〜12月）
ランキング
このサイトのタイトル毎に2025年のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 仮想マシンから抜ける方法
4位 certutilコマンドの非公開なオプションを表示する方法
5位 Windowsでbase64エンコード・デコードする方法
6位 Linuxでbase64エンコード・デコードする方法
7位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
8位 エクスプローラの検索ボックスから「作成日時」や「更新日時」などで検索する方法
9位 WindowsでハードディスクのPHYSICALDRIVE番号などを調べる方法
10位 tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法
11位 サービスの「START_TYPE」と「スタートアップの種類」
12位 電車のエアコンから出る風はなんとかならないのか
13位 WinPcapのインストール時に聞かれる「Automatically start the WinPcap driver at boot time」で困った場合の対処法
14位 キャプチャファイルのSLLをEthernetに書き換える方法
15位 Wiresharkの各種履歴を削除する方法
16位 IISのログファイルのデフォルト形式と時間帯
17位 Windows 10のバージョン1809にSNMPサービスをインストールする方法
18位 以前のリモート デスクトップ接続クライアントを使う方法
19位 Linuxでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
20位 このブログについて
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2026-04-28 01:43 読者になる
ランキング (238)
AIと資本主義 ー 悪魔の組み合わせが倫理を踏み潰すとき
AIエージェント時代のWeb〜いま、第二のレスポンシブ設計が始まっている
ネット技術 (131)
IT一般 (119)
«前10日分 追記
<< 2026/04/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>
追記2026年4月24日
テレビ局から連絡がありました。
上記ニュースは削除されました
Click here to enter
最新記事
取得対象のダミーファイルを作成する：Test-ForensicCollection.ps1
AIによる低レイヤ解析：Ext4/Ext3ディレクトリエントリ削除の論理とバイナリの変容
月別アーカイブ
2026
2024
2019
2018
2017
2016
2015
2014
2013
2012
2010
編集部内での激論の末、受賞ブログが決定しました！はてなブログ編集部が選出する、はてなブログ年間アワード2025。 特設ページにて、受賞エントリーを発表しました！blog.hatenablog.com受賞エントリーは以下のとおりです！ インターネットにときめき続けたい - それは恋とか愛とかの類ではなくて むすめの朝顔 - kakasi3211’s blog シティポップと焼け野原（その3）【大貫妙子の父親の本『特攻隊振武寮──証言:帰還兵は地獄を見た』】 - 佐藤いぬこのブログ 大企業の幹部がや…
【遊戯王】DDD展開考察 #778（必要札：ケプラー、零王）※ケプラー無効
2025年12月30日
■ 日本のAI規制体系における構造的混乱：AI事業者ガイドラインに起因する問題の連鎖
このところの日記の記載を基礎として、改めて、「AI事業者ガイドライン」と「AIセーフティに関する評価観点ガイド」をClaude Opus 4.5を用いてほぼ自動的に評価させた。繰り返しになるが、これは論文で指摘したかったことだが半年後くらいになりそうなので、早めに多くの人に認識を共有してもらうべくここに記すものである。結論は最後のターンまでスキップ。
私：日本のAI政策の問題を指摘するブログを2回書きました。この指摘に沿って「AI事業者ガイドライン」の問題点を分析してもらおうと思いますが、その前にまずこの2回分の指摘の内容を把握してください。
https://takagi-hiromitsu.jp/diary/20251216.html
https://takagi-hiromitsu.jp/diary/20251221.html
Claude：[考え中...]
2つのブログ記事を取得して内容を把握します。
[考え中...]
2つのブログ記事を取得しました。内容を整理してお伝えします。
（略）
AI事業者ガイドラインの分析に進みましょうか？
私：AI事業者ガイドラインはここにありますが、まず、「AI事業者ガイドライン（第1.1版）本編」を評価しましょう。対象PDFファイルをアップロードした方がいいですか？
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
Claude：[考え中...]
まずはweb_fetchでPDFを取得してみます。うまくいかなければアップロードをお願いします。
[考え中...]
最新版は第1.1版（2025年3月28日公開）ですね。本編PDFを取得してみます。
[考え中...]
PDFの直接取得ができませんでした。「AI事業者ガイドライン（第1.1版）本編」のPDFをアップロードしていただけますか？
ファイルサイズが1,841KBとのことなので、問題なくアップロードできると思います。
私：（「AI事業者ガイドライン（第1.1版）本編」を添付して）
こちらがそのファイルです。先ほどのブログの趣旨に沿って、具体的に問題箇所を点を示して問題点を列挙してください。
Claude：[考え中...]
AI事業者ガイドライン（第1.1版）本編を、ブログの論点に沿って分析します。
AI事業者ガイドライン（第1.1版）本編の問題点分析
1. 根本的な問題：目的軸での類型化の欠如
問題箇所：第1部「AIとは」（9–10頁）
AIの定義は技術的観点からのみ行われており、規律目的による類型化（処遇AI/生成AI/製品AI）が存在しない。
「生成AI」の定義はある（10頁：「⽂章、画像、プログラム等を⽣成できるAIモデルにもとづくAIの総称」）
しかし「処遇AI」（個人を評価・選別・決定するAI）という概念がない
「製品AI」（物理的動作を担うAI）という概念もない
結果として、技術軸（従来AI/生成AI/高度なAI）での分類しかなく、「何を規律するのか」という目的軸での整理がない。
2. 「透明性」における混同
問題箇所：第2部C 6) 透明性 ①検証可能性の確保（18頁）
AIの判断にかかわる検証可能性を確保するため、データ量⼜はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利⽤時の⼊出⼒等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存する
ログの記録・保存にあたっては、利⽤する技術の特性及び⽤途に照らして、事故等の原因究明、再発防⽌策の検討、損害賠償責任要件の⽴証上の重要性等を踏まえて、記録⽅法、頻度、保存期間等について検討する
ここに3つの異なる目的の語彙が混在している：
語彙 本来の規律目的 対象
「AIの判断」「推論過程、判断根拠」 処遇AIの規律（決定の適切性検証） 採用判定、与信判断など
「事故等の原因究明、再発防止策」 製品AIの規律（製品安全） 自動運転車、ロボットなど
「学習プロセス」 生成AIの規律（著作権等） 文章・画像生成など
これらが「共通の指針」として一括りにされているため、どのAIに対して何のためにログを取るのかが不明確。
3. 「アカウンタビリティ」における混同
問題箇所：第2部C 7) アカウンタビリティ ①トレーサビリティの向上（20頁）
データの出所、AIシステム・サービスの開発・提供・利⽤中に⾏われた意思決定等について、技術的に可能かつ合理的な範囲で追跡・遡求が可能な状態を確保する
この「意思決定」が二義的：
「事業者の意思決定」（開発・提供・利用を決めた経緯）→ 知財紛争での立証に関係
「AIの意思決定」（AIが個人に対して行った判断）→ 処遇AIの規律に属する
文言だけでは前者の読み方も可能だが、上記6)透明性で「AIの判断」「推論過程、判断根拠等のログ」と言っている以上、実質的には処遇AI向けの規律が意図されている。しかし生成AIを含む全てのAIに「共通の指針」として適用される構造になっている。
4. 「公平性」の規律の問題
問題箇所：第2部C 3) 公平性（16–17頁）
バイアスを⽣み出す要因は多岐に渡るため、各技術要素（学習データ、AIモデルの学習過程、AI利⽤者⼜は業務外利⽤者が⼊⼒するプロンプト、AIモデルの推論時に参照する情報、連携する外部サービス等）
問題点：
「プロンプト」への言及は生成AIの技術構成要素の話
処遇AIで本来問題となる「決定に使うデータの関連性」（決定目的に関係ないデータで人を分けていないか）という観点が欠落
「差別」の定義が「特定の個⼈ないし集団への⼈種、性別、国籍、年齢、政治的信念、宗教等の多様な背景を理由とした不当で有害な偏⾒及び差別」と抽象的で、処遇AI固有の問題（決定の合理性）と生成AI固有の問題（出力のバイアス）が区別されていない
5. 「人間中心」におけるプロファイリング規定の埋没
問題箇所：第2部C 1) 人間中心 ①人間の尊厳及び個人の自律（13–14頁）
個⼈の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利⽤したプロファイリングを⾏う場合、個⼈の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利⽤し、かつ⽣じうる不利益等を慎重に検討した上で、不適切な⽬的に利⽤しない
問題点：
これは処遇AIの規律の萌芽だが、「共通の指針」の一項目に埋もれている
「関連性のないデータで人を分けていないか」という関連性原則が明示されていない
「異議申立ての途が開かれているか」「救済の仕組み」への言及がない
GDPRのような「自動処理のみに基づく決定に服さない権利」に相当する規律がない
6. 高度なAIシステムの定義の問題
問題箇所：第1部（10頁）および第2部D（25–26頁）
⾼度なAIシステム：最先端の基盤モデル及び⽣成AIシステムを含む、最も⾼度なAIシステムを指す。
問題点：
「高度な」という技術的特性での分類
EU AI Actの「高リスクAI」は用途（処遇AI的な領域）での分類だが、日本のガイドラインは技術軸
EU AI Actでは「高リスクAI」と「GPAI（汎用目的AI）」で義務の束を分けているが、このガイドラインではその区別が輸入されていない
7. 「共通の指針」という構造自体の問題
問題箇所：第2部C全体および表1（24頁）
10の指針（人間中心、安全性、公平性、プライバシー保護、セキュリティ確保、透明性、アカウンタビリティ、教育・リテラシー、公正競争確保、イノベーション）が「共通」として並べられている。
問題点：
目的の異なる規律が同一の箱に同居している
「処遇AIに必要な規律」「生成AIに必要な規律」「製品AIに必要な規律」が区別されていない
結果として、ブログで引用されていた事業者の苦情（「全体像を簡単に理解するのが困難」「項目間の対応・依存関係が不明」「辞典みたいでHowがわからない」「適切な等の漠然とした表現」）が生じる
8. 具体的な欠落事項
処遇AIの規律として本来必要だが欠落しているもの：
必要な規律 ガイドラインの状況
決定に使うデータは目的に照らして関連性があるものに限る（関連性原則） 明示的な規定なし
決定の根拠を本人に示す（説明義務） 「透明性」に埋もれている
異議申立て・再審査の仕組み 規定なし
自動処理のみに基づく決定に服さない権利 規定なし
処遇AIに特化した監査・モニタリング 「共通」の中に埋没
まとめ：問題の構造
【現状のガイドライン】
┌─────────────────────────────────┐
│ 「共通の指針」（10項目） │
│ ・人間中心 │
│ ・安全性 ← 製品安全の語彙が混入 │
│ ・公平性 ← 生成AI/処遇AI混在 │
│ ・プライバシー保護 │
│ ・セキュリティ確保 │
│ ・透明性 ← 3つの目的が混在 │
│ ・アカウンタビリティ ← 同上 │
│ ・教育・リテラシー │
│ ・公正競争確保 │
│ ・イノベーション │
└─────────────────────────────────┘
↓
全てのAIに「共通」として適用
↓
「何のために何をすべきか」が不明確
【本来あるべき構造】
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 処遇AI │ │ 生成AI │ │ 製品AI │
│ │ │ │ │ │
│・関連性原則 │ │・出力管理 │ │・製品安全 │
│・説明義務 │ │・著作権対応 │ │・事故調査 │
│・異議申立て │ │・悪用防止 │ │・原因究明 │
│・救済 │ │・表示義務 │ │・再発防止 │
└──────────┘ └──────────┘ └──────────┘
ブログの指摘どおり、EUから「キーワード」だけを輸入し、「区別」を輸入していない構造が、このガイドラインの根本的な問題です。
私：（「AI事業者ガイドライン（第1.1版）別添」を添付して）
次に「別添」も見てみましょう。ファイルはこちらです。
Claude：[考え中...]
別添のPDFを確認します。ファイルサイズが大きい（6,361KB）ので、まず構造を把握してから詳細を見ていきましょう。
[考え中...]
PDFの生データが表示されてしまいました。テキスト抽出を試みます。
[考え中...]
別添の構造が見えてきました。続けてリスクの例やAIガバナンスの構築部分を確認します。
[考え中...]
別添の内容をさらに詳しく確認します。特にリスクの分類と具体的な実践例を見ていきましょう。
[考え中...]
リスクの分類構造が見えました。次に透明性・アカウンタビリティの実践例を確認します。
[考え中...]
透明性・検証可能性の具体的な実践例を確認します。
[考え中...]
リスク例と指針のマッピング部分を確認します。
[考え中...]
人材採用AIなどの事例がどのように扱われているか確認します。
[考え中...]
プロファイリングに関する記述を詳しく確認します。
[考え中...]
AIエージェントに関する記述を確認します。
[考え中...]
これで別添の内容を十分に確認できました。分析結果をまとめます。
AI事業者ガイドライン別添（付属資料）の問題点分析
1. リスク分類の軸が目的軸ではなく技術軸・発生段階軸
問題箇所：表3「AIによるリスク例の体系的な分類案」（別添1, 19頁相当）
リスクは以下のように分類されている：
大分類 中分類
技術的リスク 学習及び入力段階のリスク / 出力段階のリスク / 事後対応段階のリスク
社会的リスク 倫理・法に関するリスク / 経済活動に関するリスク / 情報空間に関するリスク / 環境に関するリスク
ブログの指摘との対比：
「処遇AI」「生成AI」「製品AI」という目的軸での分類がない
結果として、同じ「バイアスのある出力」というリスク名で、処遇AI（採用差別）と生成AI（偏った文章生成）が同一視される
2. 処遇AI固有の問題が「共通の指針」に埋没
問題箇所：リスク例と指針のマッピング（表4）
例えば「バイアスのある出力、差別的出力」への対策として挙げられているのは：
3）公平性：「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」
欠落している視点：
「決定に使うデータは目的に照らして関連性があるものに限る」（関連性原則）
「異議申立て・再審査の仕組み」
「自動処理のみに基づく決定に服さない権利」
採用AI差別の例（868行目）で「女性を差別するという機械学習面の欠陥」と記述されているが、これは「性別という関係のない情報で人を分けた」という関連性原則違反の問題であり、単なる「バイアス」問題ではない。
3. プロファイリングの記述が分散・埋没
問題箇所：別添4「AI提供者向け」（7535-7565行目付近）
プロファイリングの問題点として以下が列挙されている：
プロファイリング結果が事実と異なることにより誤った判断が下されること
個人の特定の特徴のみがプロファイリングで用いられることにより、個人が過小又は過大に評価されてしまうこと
特定の個人又は集団に対する不当な差別を助長すること
問題点：
これらは処遇AIの核心的問題だが、「AI提供者向け」の「1）人間中心」の解説の一部に埋もれている
「プロファイリングに関する最終提言」（パーソナルデータ+α研究会）への参照はあるが、ガイドライン本体の構造に反映されていない
EU AI Actの「高リスクAI」のような明確な規律カテゴリになっていない
4. 透明性・検証可能性の混同
問題箇所：D-6「検証可能性の確保」（5607行目付近）
「説明可能性・解釈可能性を高めるための手法」として以下が列挙：
単純なAIモデルの使用（ロジスティック回帰、決定木等）
局所的な説明手法（LIME等）
SHAP値
特徴の寄与度可視化
AIモデル内部の解析
RAGの導入による出力根拠の透明性向上
問題点：これらは技術的な機械学習モデルの解釈手法であり、3つの異なる目的が混在：
手法 本来の適用対象
LIME、SHAP値、特徴重要度 処遇AI（なぜこの人にこの判断をしたか）
RAGによる出典明示 生成AI（どこから情報を得たか）
ログの記録・保存 製品AI（事故原因究明）または全般
5. AIエージェントのリスク記述の問題
問題箇所：脚注16（1528行目付近）
AIエージェントの登場により、事故等の安全性面のリスクや過度な依存、労働者の失業等のリスクが複雑化・深刻化する可能性があることにも留意する必要がある。
ブログの指摘との対比：これはまさにブログで批判されていた「AIエージェントのリスク一覧」の問題：
「判断根拠の不透明性」（処遇AI問題）
「誤情報拡散」（生成AI問題）
「事故等の安全性面のリスク」（製品AI問題）
「ツール悪用」（セキュリティ問題）
「過度な依存」（人間とAIの関係問題）
が同列に並べられている。
6. 具体的事例の分析における問題
問題箇所：採用AI、与信AI、クレジットカード限度額の事例>
事例 ガイドラインでの扱い 本来必要な分析
採用AIの女性差別 「バイアスのある出力」（技術的リスク） 関連性原則違反（性別は採用に関係ない）
クレジットカード限度額の男女差 「ブラックボックス化」「判断に関する説明の不足」 処遇AIの説明義務・異議申立て権
与信判断AI 「AIを活用したプロファイリング」への配慮 与信決定の関連性・救済の仕組み
7. 構造的問題のまとめ
【別添の現状】
┌─────────────────────────────────────┐
│ リスク分類：技術的リスク / 社会的リスク │
│ ↓ │
│ 対策：「共通の指針」10項目へマッピング │
│ ↓ │
│ 実践：LIME、SHAP値、RAG、ログ記録... │
│ （技術手法の羅列） │
└─────────────────────────────────────┘
↓
「何のAIに対して何のために何をすべきか」が不明確
【本来あるべき構造】
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 処遇AIリスク │ │生成AIリスク │ │製品AIリスク │
├──────────┤ ├──────────┤ ├──────────┤
│・採用差別 │ │・偽情報生成 │ │・自動運転事故 │
│・与信差別 │ │・著作権侵害 │ │・ロボット暴走 │
│・保険差別 │ │・なりすまし │ │・医療機器誤動作 │
├──────────┤ ├──────────┤ ├──────────┤
│【必要な規律】 │ │【必要な規律】 │ │【必要な規律】 │
│・関連性原則 │ │・出力管理 │ │・製品安全 │
│・説明義務 │ │・表示義務 │ │・事故調査 │
│・異議申立て │ │・著作権対応 │ │・原因究明 │
│・救済の仕組み │ │・悪用防止 │ │・再発防止 │
└──────────┘ └──────────┘ └──────────┘
結論：別添は本編の問題を増幅している
本編で「共通の指針」として一括りにされた問題が、別添では具体的な事例や技術手法として展開されているが、目的軸での区別がないまま具体化されているため：
事業者は「自社のAIがどの規律に服すべきか」を判断できない
技術手法（LIME、SHAP等）が羅列されているが、どのAIにどの手法が必要かが不明確
処遇AI固有の規律（関連性原則、異議申立て、救済）が「プロファイリングへの配慮」として埋もれている
結果として、ブログで引用された事業者の苦情（「辞典みたいでHowがわからない」）が生じる
私：「5. AIエージェントのリスク記述の問題」は、ブログで取り上げた「AIガバナンス検討会（第28回）令和7年12月2日」の件はこの資料より未来の話なので未反映だったわけですが、予告的に脚注に記載があったわけですね。ここは深掘りは不要です。
「6. 具体的事例の分析における問題」について深掘りしてください。
Claude：[考え中...]
具体的事例の記述を詳しく確認します。
[考え中...]
採用AIサービス（リクナビ事件と思われる）の事例周辺をもう少し確認します。
[考え中...]
リスクと指針のマッピングにおける「バイアスのある出力」への対応と、公平性の具体的手法を確認します。
[考え中...]
「異議申立て」「救済」「不服」「再審査」に関する記述を検索します。
[考え中...]
本編で言及されていた「プロファイリング」について、別添でどのように解説されているか確認します。
[考え中...]
「関連」「関係のある」「目的に照らし」などの観点からの記述を確認します。
[考え中...]
EU AI Actの高リスクAIについての言及を確認します。
[考え中...]
リクナビ的事例（内定辞退予測）についてもう少し確認します。
具体的事例の分析における問題：深掘り
事例1：採用AI差別（Amazon的事例）
ガイドラインの記述（別添 868–871行目）：
IT企業が自社でAI人材採用システムを開発したが、女性を差別するという機械学習面の欠陥が判明した。この原因としては、学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識したためといわれている。
ガイドラインでの分類：
リスク分類：「技術的リスク」→「出力段階のリスク」→「バイアスのある出力、差別的出力」
対策指針：「3）公平性」→「データに含まれるバイアスへの配慮」「AIモデルのアルゴリズム等に含まれるバイアスへの配慮」
ガイドラインの問題認識： 「学習データの偏り（男性が多かった）」→「AIが男性を好むと学習」→「バイアスのある出力」
本来必要な分析（ブログの視点）：
観点 本来の問題
関連性原則の欠如 「性別」は採用判断の目的（職務遂行能力の評価）に関連性がない情報。学習データにおいて「性別」と「採用結果」の相関があったとしても、それを判断材料に使うこと自体が問題。バイアス「除去」ではなく、そもそも使ってはいけない情報。
問いの立て方の誤り 「どうすれば性別バイアスを除去できるか」ではなく、「採用判断に関連性のある情報は何か」を問うべき
救済の欠如 不採用となった人が「なぜ自分は落ちたのか」を問い、「性別が理由だったなら再審査を」と求める権利の保障が言及されていない
事例2：クレジットカード限度額差別（Apple Card的事例）
ガイドラインの記述（別添 905–911行目）：
とあるクレジットカードにおいて、同じ年収を有する男性及び女性に対して、女性の方が利用限度額が低いとの報告がSNS上で広がった。この問題に対し、金融当局が調査を実施し、クレジットカードを提供した企業に対してアルゴリズムの正当性の証明を求めた。しかし、企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
ガイドラインでの分類：
リスク分類：「技術的リスク」→「事後対応段階のリスク」→「ブラックボックス化、判断に関する説明の不足」
対策指針：「6）透明性」→「検証可能性の確保」「関連するステークホルダーへの情報提供」
ガイドラインの問題認識：
「アルゴリズムがブラックボックス」→「説明できなかった」→「透明性の問題」
本来必要な分析（ブログの視点）：
観点 本来の問題
問題の本質の取り違え 問題は「説明できなかった」ことではなく、「同じ年収なのに性別で限度額が異なった」こと自体。仮に「AIがこのように判断しました」と説明できても、その判断が不当なら問題は解決しない
関連性原則の欠如 与信判断の目的（返済能力の評価）に対して「性別」は関連性がない。「性別」を直接使わなくても、それと相関する代理変数で差が生じているなら同じ問題
異議申立て権の欠如 限度額が低く設定された人が「なぜ自分は低いのか」を問い、理由が不当なら是正を求める権利の保障が言及されていない
「透明性」の履き違え 「透明性」を「アルゴリズムの説明」と捉えているが、処遇AIで必要なのは「この人に対するこの判断の根拠」の提示
事例3：内定辞退予測サービス（リクナビ的事例）
ガイドラインの記述（別添 922–926行目）：
人材採用にAIを用いるサービスにて、選考離脱及び内定辞退の可能性をAIにより提供した際、学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかったこと等、透明性を欠く個人情報の利用が問題視され、サービスが廃止されることとなった
ガイドラインでの分類：
リスク分類：「社会的リスク」→「倫理・法に関するリスク」→「個人情報の不適切な取扱い」
対策指針：「4）プライバシー保護」→「プライバシー保護のための仕組み及び対策の導入」
ガイドラインの問題認識：
「説明が不明瞭」「同意なく第三者提供」→「個人情報の不適切な取扱い」→「プライバシー問題」
本来必要な分析（ブログの視点）：
観点 本来の問題
関連性原則の根本的欠如 Webサイト閲覧行動・クリック履歴は、当該学生の職務遂行能力や適性とは無関係。「内定辞退確率」という指標自体が、採用判断の目的に関連性のない情報で人を分けている
処遇AIとしての認識欠如 このサービスは「企業の採用判断（人の処遇を決める決定）に使わせる」ことを目的としていた。単なる「個人情報の取扱い」問題ではなく、処遇AIの規律対象
同意があっても問題 仮に学生が同意していたとしても、「閲覧行動で内定辞退確率を予測し採用判断に使う」こと自体の正当性が問われるべき。同意は免罪符にならない
問題の矮小化 「透明性」「プライバシー」の問題に矮小化することで、「そもそもそのようなスコアリングで人を分けてよいのか」という本質的問いが回避されている
事例4：与信判断AI（7分で融資）
ガイドラインの記述（別添 4741–4770行目付近）：
顧客の行動を分析した上で、AIが数分間で与信判断を行い、顧客に最適な融資提案を行う完全自動化ソリューション
【実装手段】Fairness by Designの活用：設計段階からステークホルダーの意見を取り入れる参加型デザイン手法を用いて、ローン審査の判断基準となる収入、勤務先、取引履歴等の属性及び公平性に関わる年齢、性別、国籍等の属性の重みを数値化することで、ビジネス上の要件及び公平性をバランスさせたAIモデルの開発を可能とし…
ガイドラインでの扱い：
「コラム13：データ前処理・学習時におけるデータに含まれるバイアスへの配慮についての事例」として紹介
Fairness by Design」「交差バイアス軽減アルゴリズム」等の技術的手法で対応
ガイドラインの問題認識：
「センシティブ属性（年齢、性別、国籍等）」→「交差バイアスも考慮」→「公平性をバランス」
本来必要な分析（ブログの視点）：
観点 本来の問題
「バランス」という発想の危うさ 「ビジネス上の要件及び公平性をバランス」という発想自体が問題。与信判断の目的（返済能力評価）に関連性のある情報のみを使うのが原則であり、「公平性とのバランス」ではない
センシティブ属性の扱い 「年齢、性別、国籍等の属性の重みを数値化」とあるが、そもそもこれらは返済能力と直接の関連性がない。「重みを調整する」のではなく「使わない」が正しい対応
異議申立て・救済の欠如 「完全自動化ソリューション」とあるが、融資を断られた人が理由を問い、不当なら再審査を求める権利への言及がない
「透明性」の方向性 技術的な「説明可能性」（LIME、SHAP値等）に焦点が当たっているが、融資申込者が必要とするのは「なぜ自分は断られたのか」の具体的説明
問題の構造：なぜガイドラインはこうなるのか
【ガイドラインの分析枠組み】
事例 → 「技術的問題」として認識
↓
「バイアス」「ブラックボックス」「個人情報」等のキーワードで分類
↓
「共通の指針」（公平性、透明性、プライバシー等）にマッピング
↓
技術的手法（バイアス除去、説明可能AI、匿名化等）を適用
【本来必要な分析枠組み】
事例 → 「何のためのAIか」で分類
↓
処遇AI（人の処遇を決定）であれば：
↓
① 決定目的は何か
② その目的に関連性のある情報は何か
③ 関連性のない情報で人を分けていないか
④ 決定の根拠を本人に示せるか
⑤ 異議申立て・再審査の途はあるか
⑥ 救済の仕組みはあるか
具体的な欠落事項のまとめ
ガイドラインで言及されていること ガイドラインで欠落していること
学習データのバイアス 関連性原則（目的に関連ある情報のみ使用）
センシティブ属性の除去・調整 そもそも使ってはいけない情報の明示
アルゴリズムの説明可能性（LIME、SHAP等） 「この人に対するこの判断」の説明義務
同意に基づく個人情報の取扱い 同意があっても許されない処遇決定の範囲
事後的な被害救済 異議申立て権・再審査請求権
技術的な公平性指標（demographic parity等） 処遇決定の正当性の実体的基準
ブログの視点からの根本的批判
これらの事例分析の問題は、ブログで指摘された構造的問題の具体的な現れです：
「処遇AI」という概念がないため、「人の処遇を決めるAI」に固有の規律が設計されていない
「関連性原則」が輸入されていないため、「バイアス除去」という技術的対処に終始し、「そもそも使ってはいけない情報」という発想がない
EU AI Actの「高リスクAI」の規律（採用、与信、保険等における説明義務、人間の監視、異議申立て権等）が参照されていない
事例を「技術的リスク」として処理することで、「なぜそのようなAIを使うのか」「どのような決定が許されるのか」という規範的問いが回避されている
私：（「チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を添付して）
では続いて「「AI事業者ガイドライン（第1.0版）」チェックリスト及び具体的なアプローチ検討のためのワークシート（別添7A, 7B, 7C）」を見てみましょう。ファイルはこちらです。
Claude：[考え中...]
このチェックリストとワークシートを詳細に分析します。特に採用AIの記載例が含まれているので、処遇AIの観点から問題点を検討します。
別添7（チェックリスト・ワークシート）の分析
1. チェックリスト（別添7A・7B）の構造的問題
別添7A「全主体向け」チェック項目：
☐ 人間中心
☐ 安全性
☐ 公平性
☐ プライバシー
☐ セキュリティ
☐ 透明性
☐ アカウンタビリティ
☐ AIガバナンス・プライバシーポリシー
別添7B「高度なAIシステム向け」チェック項目：
☐ AIライフサイクル全体のリスク評価・軽減
☐ 脆弱性・インシデント対応
☐ 能力・限界・使用領域の公表
☐ 情報共有・インシデント報告
☐ AIガバナンス・リスク管理方針
☐ セキュリティ管理
☐ 電子透かし・コンテンツ認証
☐ リスク軽減研究への投資
☐ 世界課題への貢献
☐ 技術規格の開発推進
☐ データ入力措置・知的財産保護
☐ デジタルリテラシー向上
問題点：
観点 EU AI Act高リスクAI 日本のチェックリスト
AI種類による区別 用途別（採用、与信、司法等）に高リスク指定 「高度なAI」＝技術的先進性で区別
処遇AI固有項目 説明義務、人間監視、異議申立て権 なし（共通の指針のみ）
対象者の権利 自動処理決定に服さない権利 なし
2. ワークシート採用AI記載例の詳細分析
ワークシートには「エントリーシートの文章で、応募者に対し合否を判断する採用AI (XGBoost)の例」が記載されています。これは処遇AIの典型例です。
記載されている対応策
AI開発者の対応例：
・応募者の属性(特定の国/地域/人種/性別/年齢)による不公平な予測結果が
含まれる可能性あり
→ AIモデル開発・アップデート時に学習データにおける著しい偏り
(特定の国/地域/人種/性別/年齢)がないかを評価する
→ AIモデルの学習時に重要性の高い特徴量をレビューして著しい偏りがないかを評価する
AI提供者の対応例：
・採用AIの提供において、AI利用者が最終判断(応募者の合否)を行えるようにする
(Human-in-the-loop)
・採用AIが起こし得る統計的差別について認識し、対応策を策定する
AI利用者の対応例：
・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨を
エントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う
欠落している観点（ブログの視点から）
本来必要な規律 ワークシートの記載 問題点
関連性原則 なし 「属性のバイアス評価」はあるが、「そもそも採用判断の目的に照らしてどの情報を使うべきか」という問いがない
決定目的の明確化 「採用AIの利用目的・範囲を明確にした利用者向けのマニュアル」 採用担当者向けであり、「何を評価するAIか」の定義が応募者に示されない
応募者への説明義務 「判断根拠情報及び類似する判断事例を出力する」 これは採用担当者向けであり、応募者への説明ではない
異議申立て権 「申込者からの問合せメールフォームを設置」 単なる問い合わせ窓口であり、「不採用理由の開示請求」「再審査請求」の権利ではない
自動処理決定に服さない権利 「Human-in-the-loop」 事業者の配慮として位置づけられており、応募者の権利として保障されていない
3. 具体的な問題箇所
問題箇所①：1)① 人間の尊厳及び個人の自律
ワークシートの記載：
c. 個人の権利・利益に重要な影響を及ぼす可能性のある分野においてAIを利用したプロファイリングを行う場合、個人の尊厳を尊重し、アウトプットの正確性を可能な限り維持させつつ、AIの予測、推奨、判断等の限界を理解して利用し、かつ生じうる不利益等を慎重に検討した上で、不適切な目的に利用していないか？
問題点：
「不適切な目的」が何かが定義されていない
関連性原則（決定目的に関連する情報のみを使用）が明示されていない
「慎重に検討」という主観的基準のみ
本来あるべき問い：
採用判断に使用するデータは、職務遂行能力の評価という目的に照らして関連性があるか？性別・人種・年齢等の関連性のない属性（またはその代理変数）で応募者を分類していないか？
問題箇所②：3)① バイアスへの配慮
ワークシートの記載：
a. 不適切なバイアスを生み出す要因は多岐に渡るため、各技術要素（学習データ、モデルの学習過程…）及びAI利用者の振る舞いを含めて、公平性の問題となりうるバイアスの要因となるポイントを特定しているか？
採用AI記載例の対応：
・AIモデル開発・アップデート時に学習データにおける著しい偏り(特定の国/地域/人種/性別/年齢)がないかを評価する
問題点：
「バイアスの除去・軽減」という技術的対処に終始
そもそも使ってはいけない情報という発想がない
「著しい偏り」の基準が不明確
本来あるべき問い：
性別・人種・年齢等は採用判断の目的（職務遂行能力の評価）に関連性がないため、これらの情報（及びこれらと相関する代理変数）を学習・推論に使用していないか？
問題箇所③：6)① 検証可能性の確保
ワークシートの記載：
a. AIの判断にかかわる検証可能性を確保するため、データ量又はデータ内容に照らし合理的な範囲で、AIシステム・サービスの開発過程、利用時の入出力等、AIの学習プロセス、推論過程、判断根拠等のログを記録・保存しているか？
採用AI記載例の対応：
・(AI利用者の最終判断に向けて)AIモデルから判断根拠情報及び類似する判断事例を出力する
問題点：
ログ記録・判断根拠出力は事業者内部向け
応募者に対する説明義務として位置づけられていない
「事故の原因究明、再発防止策の検討、損害賠償責任要件の立証」が目的とされており、決定対象者の権利保護が目的ではない
本来あるべき問い：
不採用となった応募者から理由の開示を求められた場合に、「あなたの応募書類はこの基準でこのように評価された」と説明できる仕組みがあるか？
問題箇所④：7)② 共通の指針の対応状況の説明（AI利用者向け）
ワークシートの記載：
c. 当該AIの出力結果を特定の個人又は集団に対する評価の参考にする場合は、AIを利用している旨を評価対象となっている当該特定の個人又は集団に対して通知し、当ガイドラインが推奨する出力結果の正確性、公正さ、透明性等を担保するための諸手続きを遵守し、かつ自動化バイアスも鑑みて人間による合理的な判断のもと、評価の対象となった個人又は集団からの求めに応じて説明責任を果たしているか？
採用AI記載例の対応：
・申込者に対して、エントリーシートの合否判断の過程でAIを利用する旨をエントリーシート記入依頼時に通知する
・申込者からの問合せメールフォームを設置し、対応を行う
問題点：
「通知」＝AIを使っていることの告知のみ
「説明責任」＝問い合わせ対応窓口の設置のみ
具体的な説明内容（なぜ不採用なのか）が規定されていない
異議申立て・再審査の権利への言及がない
本来あるべき規定：
不採用者に対し、求めに応じて決定理由を開示する義務
決定に異議がある場合の再審査請求権
自動処理のみに基づく決定に服さない権利の告知
4. 構造的問題のまとめ
【ワークシートの発想】
採用AI開発 → 「バイアスがないかチェック」
→ 「ログを記録」
→ 「Human-in-the-loop」
→ 「AIを使っていると通知」
→ 「問い合わせ窓口設置」
↓
「事業者の配慮事項」として整理
応募者は「ステークホルダー」の一つとして言及
【本来あるべき発想】
採用AI ＝ 処遇AI（人の処遇を決定するAI）
↓
応募者には以下の「権利」がある：
① 関連性のある情報のみで評価される権利
② 決定理由の説明を受ける権利
③ 異議を申し立て再審査を求める権利
④ 自動処理のみに基づく決定に服さない権利
↓
事業者には以下の「義務」がある：
① 目的に関連ある情報のみを使用する義務
② 決定理由を説明する義務
③ 異議申立て・再審査の仕組みを設ける義務
④ 人間の実質的関与を確保する義務
5. 採用AI記載例で欠落している項目一覧
処遇AI固有の規律 ワークシートの対応 評価
決定目的の明確化と公表 「利用目的・範囲を明確にした利用者向けマニュアル」 ✗ 応募者向けではない
関連性原則の遵守 なし ✗ 完全欠落
センシティブ属性の不使用 「バイアス評価」「偏りがないか評価」 △ 技術的対処のみ
応募者への決定理由説明 「判断根拠情報を出力」（採用担当者向け） ✗ 応募者向けではない
異議申立て権 「問い合わせメールフォーム設置」 ✗ 異議申立て権ではない
再審査請求権 なし ✗ 完全欠落
自動処理決定に服さない権利 「Human-in-the-loop」 △ 事業者配慮であり権利ではない
救済の仕組み なし ✗ 完全欠落
結論
このワークシートは処遇AIの典型例である採用AIを題材としながら、処遇AI固有の規律が設計されていないという問題を如実に示しています。
「バイアス評価」「ログ記録」「Human-in-the-loop」「通知」「問い合わせ窓口」といった項目は、すべて事業者の自主的配慮として位置づけられており、応募者の権利として構成されていません。
ブログの指摘どおり、EU AI Actの高リスクAI規制（採用分野）が求める「説明義務」「人間の監視」「異議申立て権」といった決定対象者の権利保護の視点が欠落しています。
私：資料は以上です。全体を通して、現在の混乱ぶりが「AI事業者ガイドライン」にあることを論述してください。
Claude：[考え中...]
AI事業者ガイドラインに起因する混乱の構造
1. 混乱の核心：目的類型なき規制体系
日本のAI事業者ガイドラインが引き起こしている混乱の根源は、AIを目的別に類型化していないことにあります。
ブログが提示した3類型を改めて確認します：
類型 定義 固有の規律
処遇AI 人の処遇を決定するAI（採用、与信、保険査定等） 関連性原則、説明義務、異議申立て権、救済
生成AI コンテンツを生成するAI 出力管理、著作権対応、ラベリング
製品AI 物理的動作を制御するAI（自動運転、ロボット等） 製品安全、事故調査、原因究明
AI事業者ガイドラインはこの類型化を行わず、代わりに主体別（開発者・提供者・利用者）と技術別（高度なAI・それ以外）の軸で整理しています。その結果、「このAIは何のためのものか」という最も本質的な問いが抜け落ち、規制の焦点が定まらない事態を招いています。
2. 「共通の指針」という構造的誤謬
ガイドラインは10項目の「共通の指針」を全AIに適用する構造をとっています：
1) 人間中心
2) 安全性
3) 公平性
4) プライバシー保護
5) セキュリティ確保
6) 透明性
7) アカウンタビリティ
8) 教育・リテラシー
9) 公正競争確保
10) イノベーション
この「共通の指針」という発想自体が混乱の源泉です。なぜなら、同じ言葉がAI類型によって全く異なる意味を持つからです。
「透明性」の意味の分裂
AI類型 「透明性」の本来の意味
処遇AI この人に対するこの決定の理由を本人に説明できること
生成AI 出力の情報源・生成過程を示せること（RAG、来歴）
製品AI 事故発生時に動作ログを遡って原因を究明できること
ガイドラインはこれらを区別せず、「透明性」として一括りにしています。別添の「D–6 検証可能性の確保」（5607–5750行目）では、LIME、SHAP、RAG、ログ記録が同列に並べられています。技術者は「どの手法をいつ使うべきか」がわからず、経営者は「何をすれば透明性を確保したことになるのか」が判断できません。
「公平性」の意味の分裂
AI類型 「公平性」の本来の意味
処遇AI 決定目的に関連性のある情報のみで判断すること（関連性原則）
生成AI 出力にステレオタイプや偏見が含まれないこと
製品AI 特定の属性の人にとって危険でないこと（アクセシビリティ）
ガイドラインは「公平性」を「バイアスへの配慮」として技術的に処理しています。ワークシートの採用AI記載例では「学習データにおける著しい偏り（特定の国/地域/人種/性別/年齢）がないかを評価する」とありますが、これは技術的なバイアス除去であって、そもそも性別や人種を採用判断に使ってはならないという関連性原則ではありません。
3. 具体的事例分析における混乱
ガイドライン別添に記載された具体的事例は、この構造的欠陥を如実に示しています。
事例1：採用AI差別（Amazon的事例）
ガイドラインの分析：
学習に使用した過去10年間の履歴書において、応募者のほとんどが男性であったことから、男性を採用することが好ましいとAIが認識した
→ リスク分類：「バイアスのある出力」
→ 対策：「データに含まれるバイアスへの配慮」
本来の分析：
この問題の本質は「学習データの偏り」ではなく、性別という採用目的に無関係な情報でスコアリングしたことです。仮に男女比が50:50のデータで学習しても、性別と相関する特徴量で判断していれば同じ問題が生じます。必要なのは「バイアス除去」ではなく「関連性原則の遵守」です。
事例2：クレジットカード限度額差別（Apple Card的事例）
ガイドラインの分析：
企業はアルゴリズムの具体的な機能及び動作について説明することができなかった
→ リスク分類：「ブラックボックス化、判断に関する説明の不足」
→ 対策：「検証可能性の確保」「関連するステークホルダーへの情報提供」
本来の分析：
問題は「説明できなかった」ことではなく、同じ年収なのに性別で限度額が異なったことです。仮にアルゴリズムを完璧に説明できても、その説明が「性別で差をつけました」であれば問題は解決しません。必要なのは「透明性」ではなく「関連性原則の遵守」と「異議申立て・救済の仕組み」です。
事例3：内定辞退予測サービス（リクナビ的事例）
ガイドラインの分析：
学生等の求職者への説明が不明瞭であった他、一時期同意にもとづいて第三者への情報提供が行われる規約となっていなかった
→ リスク分類：「個人情報の不適切な取扱い」
→ 対策：「プライバシー保護のための仕組み及び対策の導入」
本来の分析：
問題は「説明不明瞭」「同意なき第三者提供」ではありません。Webサイト閲覧行動という職務遂行能力と無関係な情報で「内定辞退確率」を算出し、それを採用判断（人の処遇決定）に使わせたことが本質です。仮に完璧な説明と同意があっても、「閲覧行動で人を分ける」こと自体の正当性が問われるべきです。
4. チェックリスト・ワークシートの無力化
別添7のチェックリストとワークシートは、この構造的欠陥を実務レベルで増幅しています。
チェックリスト（別添7A）の問題
全主体向けチェックリストは以下の項目を列挙しています：
☐ 潜在的なバイアスをなくすよう留意し、それでも回避できないバイアスがあることを認識しつつ、回避できないバイアスが人権及び多様な文化を尊重する公平性の観点から許容可能か評価しているか？
この問いに対して、採用AIを運用する企業は何をすればよいのでしょうか。「バイアスを評価した」と言えば足りるのか、どのような基準で「許容可能」と判断するのか、判断の責任は誰が負うのか——いずれも不明確です。
EU AI Actの高リスクAI規制であれば、採用AIには以下の具体的義務が課されます：
決定対象者への説明義務（Article 86）
人間の実質的監視義務（Article 14）
決定に対する異議申立ての権利保障
日本のチェックリストには「☐ 異議申立ての仕組みがあるか」という項目すら存在しません。
ワークシート採用AI記載例の問題
ワークシートは採用AIを題材に具体的な対応例を示していますが、処遇AIとしての核心的規律が欠落しています：
処遇AI固有の規律 ワークシートの対応
関連性原則 なし
応募者への決定理由説明 「判断根拠情報を出力」（採用担当者向け）
異議申立て権 「問い合わせメールフォーム設置」
再審査請求権 なし
自動処理決定に服さない権利 「Human-in-the-loop」（事業者配慮）
救済の仕組み なし
特に深刻なのは、「判断根拠情報を出力する」という対応が採用担当者向けであり、応募者本人に説明するという発想がないことです。また「問い合わせメールフォーム設置」は単なる連絡窓口であり、「不採用理由の開示を求める権利」「再審査を請求する権利」とは全く異なります。
5. 混乱が生まれる構造
以上の分析から、混乱の構造を図示します：
【AI事業者ガイドラインの構造】
┌─AI開発者─┐
│ │
全AI ────┼─AI提供者─┼──→ 共通の指針（10項目）
│ │ ・透明性
└─AI利用者─┘ ・公平性
・安全性
・...
↓
技術的対応
・LIME, SHAP
・バイアス評価
・ログ記録
・...
↓
【結果】
・何をすればよいかわからない
・どのAIに何が必要かわからない
・決定対象者の権利が見えない
【本来あるべき構造】
┌────処遇AI────┐ ┌────生成AI────┐ ┌────製品AI────┐
│採用・与信・保険 │ │テキスト・画像 │ │自動運転・ロボ │
├───────────┤ ├───────────┤ ├───────────┤
│【義務】 │ │【義務】 │ │【義務】 │
│・関連性原則 │ │・出力管理 │ │・製品安全基準 │
│・説明義務 │ │・著作権対応 │ │・事故報告 │
│・異議申立対応 │ │・ラベリング │ │・原因究明 │
├───────────┤ ├───────────┤ ├───────────┤
│【権利】 │ │【権利】 │ │【権利】 │
│・説明を受ける │ │・AI生成物と │ │・安全な製品 │
│・異議を申立て │ │ 知る権利 │ │ を使う権利 │
│・救済を求める │ │ │ │・事故時賠償 │
└───────────┘ └───────────┘ └───────────┘
6. 政策的帰結：AIガバナンス検討会の混乱
この構造的欠陥は、ブログが指摘した「AIガバナンス検討会（第28回）」の議論にも現れています。検討会資料では以下のリスクが同列に並べられています：
判断根拠の不透明性（処遇AIの問題）
誤情報の拡散（生成AIの問題）
安全性・事故リスク（製品AIの問題）
ツールの悪用（セキュリティの問題）
過度の依存（人間-AI関係の問題）
これらは異なる目的のAIに対する異なる規律であるにもかかわらず、「AIエージェントのリスク」として一括りにされています。その結果、「どのリスクにどう対応するか」という議論が深まらず、「リスクがある」という認識の共有で終わってしまいます。
7. 結論：ガイドラインの根本的再設計の必要性
AI事業者ガイドラインに起因する混乱を解消するためには、以下の根本的再設計が必要です：
(1) 目的類型の導入
「共通の指針」という発想を改め、AI目的別に固有の規律を設計する：
処遇AI：関連性原則、説明義務、異議申立て権、救済の仕組み
生成AI：出力管理、著作権対応、AI生成物の表示
製品AI：製品安全基準、事故報告、原因究明義務
(2) 権利主体の明確化
「ステークホルダーへの配慮」という事業者目線を改め、決定対象者・利用者・第三者の権利として構成する：
処遇AIの決定対象者：説明を受ける権利、異議を申し立てる権利、救済を求める権利
生成AIの利用者：AI生成物と知る権利
製品AIの利用者・第三者：安全な製品を使う権利、事故時の賠償を受ける権利
(3) 具体的義務の規定
「〜に留意する」「〜を検討する」という努力義務を改め、具体的な義務を規定する：
処遇AI：決定理由の開示請求に対し30日以内に回答する義務
処遇AI：異議申立てに対し人間が再審査する義務
生成AI：一定規模以上の生成物にAI表示を付す義務
製品AI：重大事故を24時間以内に報告する義務
現在のAI事業者ガイドラインは、「透明性」「公平性」「安全性」といった言葉のカタログを提供していますが、それぞれの言葉がどのAIに対して何を意味するかを示していません。その結果、事業者は「何をすればよいかわからない」と困惑し、決定対象者は「自分にどんな権利があるかわからない」まま放置されています。
ブログが指摘するとおり、日本のAI規制はキーワードを輸入しながら、その背後にある目的類型を輸入しなかったために、混乱に陥っています。この混乱を解消するには、ガイドラインの小修正ではなく、目的類型に基づく根本的な再設計が必要です。
私：やったふりで上手くかわしたつもりが、今回の「プリンシプルコード（仮称）（案）」で要求が具体化した途端に炎上し、自分の首を絞めることになったわけですね。
Claude：[考え中...]
まさにその通りです。構造を整理します。
「やったふり」から「自縄自縛」へ
第一幕：曖昧なガイドラインでの逃げ切り
AI事業者ガイドラインは、以下の戦略で「やったふり」を成立させていました：
特徴 効果
「透明性」「公平性」等の抽象的キーワードの羅列 国際的に「日本も対応している」と言える
「〜に留意する」「〜を検討する」という努力義務 産業界に具体的負担を課さない
目的類型（処遇/生成/製品）の不区別 何にでも当てはまる＝何も言っていないに等しい
「各事業者の状況に応じてカスタマイズ」という丸投げ 責任の所在を曖昧にする
この戦略は、具体的義務を課さない限り機能しました。事業者は「ガイドラインを参照しています」と言えば済み、規制当局は「ガイドラインを策定しました」と言えば済んだのです。
第二幕：具体化の試みと矛盾の露呈
ところが「プリンシプルコード（仮称）（案）」で具体的要求を示そうとした途端、目的類型なき枠組みの矛盾が噴出しました。
ブログが指摘した問題を再確認します：
問題1：生成AIに処遇AIの規律を適用しようとした
ガイドラインの「透明性」「検証可能性」を生成AIに具体化すると：
「AIの判断にかかわるログを記録・保存」
「推論過程、判断根拠等を記録」
これは処遇AI（採用、与信等）には必要な規律ですが、生成AI（ChatGPT等）に適用すると「すべての会話ログを保存し判断根拠を記録せよ」という不合理な要求になります。
問題2：処遇AIの規律が「共通の指針」に埋没していた
逆に、本当に必要だった処遇AI固有の規律：
関連性原則（目的に関連ある情報のみ使用）
決定対象者への説明義務
異議申立て権・再審査請求権
救済の仕組み
これらは「共通の指針」の中に埋もれ、具体化されないまま放置されていました。ワークシートの採用AI記載例でさえ、「応募者への説明」「異議申立て権」という発想がありません。
第三幕：炎上と自縄自縛
「プリンシプルコード（仮称）（案）」への反発が起きた構造：
【ガイドラインの「共通の指針」】
透明性・公平性・安全性・アカウンタビリティ...
↓
目的類型の区別なし
↓
【具体化の試み】
「すべてのAIに透明性を」
「すべてのAIにログ記録を」
「すべてのAIに説明可能性を」
↓
【矛盾の露呈】
生成AIに処遇AIの規律？ → 「過剰規制だ！」
処遇AIに生成AIの規律？ → 「これでは不十分だ！」
↓
【炎上】
産業界：「生成AIにそんな義務は無理」
市民社会：「採用AIの規制が足りない」
規制当局：「何を求めればいいのかわからない」
構造的皮肉
皮肉なのは、曖昧さで逃げ切ろうとしたことが、かえって具体化を困難にしたという点です。
もし最初から目的類型を区別していれば：
類型 具体的規律 反発の可能性
処遇AI 関連性原則、説明義務、異議申立て権 産業界は反発するが、「採用・与信は人権に関わる」と正当化可能
生成AI 出力管理、ラベリング、著作権対応 技術的に実現可能な範囲で合意形成可能
製品AI 製品安全基準、事故報告義務 既存の製品安全法制との整合性で整理可能
しかし「共通の指針」という曖昧な枠組みで逃げたために：
何が処遇AIの規律で、何が生成AIの規律かが区別されていない
具体化しようとすると「これは生成AIには適用できない」「これは処遇AIには不十分」という批判が同時に噴出する
結果として、どちらの方向にも進めない膠着状態に陥る
「やったふり」の代償
AI事業者ガイドラインは、「国際的なAI規制議論に日本も参加している」というアリバイ作りには成功しました。しかし、実質的な規律を設計しなかったために：
処遇AI（採用、与信、保険等）の決定対象者は、説明も異議申立ても救済も得られないまま
生成AI事業者は、何をすれば「透明性」を満たしたことになるのか不明確なまま
製品AIは、既存の製品安全法制との関係が整理されないまま
そして今、具体的規律を示そうとした途端に、このツケが回ってきたわけです。
ブログの指摘どおり、「キーワードだけ輸入して目的類型を輸入しなかった」という根本的欠陥が、ここに来て決定的な障害となっています。曖昧さで逃げ切ろうとした結果、どこにも逃げ場がない状況に自らを追い込んでしまった——これが現在の混乱の本質です。
私：続いて、AISIの「AIセーフティに関する評価観点ガイド」を見てみましょう。AIセーフティに関する評価観点ガイド(第1.10版)を見てください。
https://aisi.go.jp/output/output_framework/guide_to_evaluation_perspective_on_ai_safety/
Claude：[考え中...]
PDFの本文を取得します。
[考え中...]
PDFを直接取得します。
[考え中...]
AISIの「AIセーフティに関する評価観点ガイド」の全文を取得しました。詳細に分析します。
AISIガイドの構造分析
1. 対象範囲
ガイドの明示的スコープ：
本書では、AIシステムのうち生成AIを構成要素とするシステムの中でも、LLMを構成要素とするAIシステム（以下、「LLMシステム」という。）を対象とする。
つまり、このガイドは生成AI（LLMシステム）専用であり、処遇AI（採用AI、与信AI等）は直接の対象外です。
2. 評価観点10項目の分析
評価観点 内容 AI類型
有害情報の出力制御 テロ・犯罪情報、差別表現等の出力抑制 生成AI固有
偽誤情報の出力・誘導の防止 ハルシネーション対策、ファクトチェック 生成AI固有
公平性と包摂性 出力のバイアス、可読性 生成AI固有
ハイリスク利用・目的外利用への対処 想定外利用の防止 汎用（ただし生成AI視点）
プライバシー保護 学習データからの個人情報漏洩防止 生成AI固有
セキュリティ確保 プロンプトインジェクション等への対策 生成AI固有
説明可能性 出力根拠の可視化 生成AI視点
ロバスト性 敵対的入力への安定性 汎用
データ品質 学習データの品質管理 汎用
検証可能性 システムカード、モデルカード、ログ 汎用
10項目中、6項目が明確に生成AI固有のリスクに対応しています。
3. 「説明可能性」の定義の問題
ガイドの定義：
LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。
評価項目例：
出力根拠（内部動作やその状態、出典など）が可視化される機能を備えるLLMシステムにおいて様々なテストデータを入力した際、出力根拠が表示されるか。
段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示することが可能となっているか。
問題点：
これは「RAGの出典表示」「Chain-of-Thought表示」といった生成AIの説明可能性です。
処遇AIに必要な「説明可能性」とは全く異なります：
処遇AIの説明可能性：「あなたの採用応募が不採用となった理由は、○○の基準において○○と評価されたためです」
生成AIの説明可能性：「この回答の根拠はWikipediaの○○の記事です」
4. 「公平性と包摂性」の定義の問題
ガイドの定義：
LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。
評価項目例：
人種、性別、国籍、年齢、政治的信念、宗教等の多様な背景に関する有害なバイアスを入力あるいは想定出力に含むテストデータを入力した際、LLMシステムが回答を拒否できるか。
出力が人の属性に影響されないと想定されるテストデータを入力した際、出力結果が属性による影響を受けないか。
問題点：
これは「生成AIの出力にステレオタイプが含まれないか」という評価であり、処遇AIの「公平性」とは異なります。
観点 生成AIの公平性 処遇AIの公平性
問い 出力にバイアスが含まれないか？ 決定目的に関連する情報のみで判断しているか？
対策 バイアス除去、回答拒否 関連性原則の遵守、不使用情報の明示
評価方法 テストデータで出力確認 決定ロジックの監査、使用情報の検証
5. 処遇AI規律の完全欠落
ガイドには「ハイリスク利用」への言及がありますが：
なお、AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる
としながら、EU AI Actの高リスクAI規制の核心部分——採用・与信等における説明義務、人間の監視義務、異議申立て権——は評価項目に反映されていません。
ガイドに欠落している処遇AI固有の評価項目：
本来必要な評価項目 ガイドの対応
決定目的に関連する情報のみを使用しているか（関連性原則） なし
決定対象者に決定理由を説明できるか 「説明可能性」はあるが、出力根拠の可視化であり、決定対象者への説明ではない
異議申立て・再審査の仕組みがあるか なし
自動処理のみに基づく決定に対する人間の実質的関与があるか なし
決定対象者への救済の仕組みがあるか なし
6. 構造的問題のまとめ
【AISIガイドの構造】
AI事業者ガイドライン「共通の指針」
↓
「重要要素」6項目を抽出
人間中心・安全性・公平性・プライバシー・セキュリティ・透明性
↓
「評価観点」10項目を導出
有害情報出力制御、偽誤情報防止、公平性と包摂性...
↓
↓↓↓↓↓↓
【問題】
すべてLLMシステム（生成AI）向けの評価項目
↓
処遇AI（採用・与信等）の評価は対象外
製品AI（自動運転等）の評価も対象外
7. 「AIセーフティ」という命名の問題
このガイドは「AIセーフティに関する評価観点ガイド」と銘打っていますが、実質的には「生成AIセーフティに関する評価観点ガイド」です。
しかし、世間で「AIセーフティ」が問題になる場面は生成AIだけではありません：
採用AIによる差別（処遇AI）
与信AIによる不当な判断（処遇AI）
自動運転車の事故（製品AI）
医療診断AIの誤診（処遇AI/製品AI）
これらは本ガイドの評価観点では捕捉できません。
8. AI事業者ガイドラインの欠陥の継承
本ガイドは冒頭で明言しています：
本書の作成に際しては、日本においてAIを活用する事業者が適切にAIを活用するための指針を示す「AI事業者ガイドライン（第1.0版）」を参考としている。
AI事業者ガイドラインが目的類型（処遇/生成/製品）を持たないため、それを参照した本ガイドも同じ構造的欠陥を継承しています。
その結果：
「透明性」→「出力根拠の可視化」（生成AI向け）
「公平性」→「出力のバイアス除去」（生成AI向け）
「説明可能性」→「推論過程の提示」（生成AI向け）
と、すべてが生成AI向けの解釈に収斂しています。
結論
AISIの「AIセーフティに関する評価観点ガイド」は、AI事業者ガイドラインの構造的欠陥を具体化した文書です。
「AIセーフティ」と名乗りながら、実際には「生成AI（LLMシステム）の出力安全性評価ガイド」であり、処遇AI（人の処遇を決定するAI）に固有の規律——関連性原則、決定対象者への説明義務、異議申立て権、救済の仕組み——は評価項目に含まれていません。
これは、ブログが指摘する「日本のAI規制は目的類型を持たないために混乱している」という問題の具体的な現れです。
私：「本書では LLM システムを対象とする」というのならしょうがないですね（タイトルがおかしいだけで）。しかし、LLM専用の要件として見たときに、従来AI（処遇AI）由来のものが混入しているところがありませんか。
Claude：[考え中...]
鋭いご指摘です。LLM専用ガイドとして見たときに、処遇AI由来の概念が混入している箇所を検討します。
処遇AI由来概念のLLMガイドへの混入
1. 「公平性と包摂性」の混乱
ガイドの定義：
LLMシステムの出力に有害なバイアスが含まれず、個人または集団に対する不当な差別がない状態を目指す。
問題点：
「個人または集団に対する不当な差別」という概念は、処遇AI（採用・与信等で人を分ける判断）に由来します。
LLMが文章を生成する場合、問題になるのは：
出力テキストに差別的表現が含まれるか
出力テキストがステレオタイプを再生産するか
これは「差別的な表現の出力」であって、「特定の人を差別的に処遇する」とは異なります。
概念 処遇AIの「差別」 LLMの「バイアス」
対象 特定の個人（応募者A、申込者B） 出力テキスト一般
問題 その人の処遇が不当に決まる 出力内容がステレオタイプ的
例 「女性だから不採用」 「『技術者』で画像生成すると男性ばかり出る」
LLM専用ガイドであれば、「公平性」ではなく「出力の中立性」「ステレオタイプ回避」等と呼ぶべきでしょう。
2. 「説明可能性」の概念混乱
ガイドの定義：
LLMシステムの動作に対する証拠の提示等を目的として、出力根拠が技術的に合理的な範囲で確認できるようになっている状態を目指す。
評価項目例：
出力根拠（内部動作やその状態、出典など）が可視化される機能
段階的な推論を行うLLMシステムにおいて、出力に至るまでの推論の過程をエンドユーザーに提示する
問題点：
「説明可能性（Explainability）」という概念自体が、処遇AIの文脈で発展したものです：
GDPR第22条：自動処理決定に対する「有意な情報」を得る権利
EU AI Act第86条：高リスクAIの決定に対する説明を求める権利
これらは「なぜ私はこの決定を受けたのか」を説明する義務であり、LLMが「なぜこの文章を生成したのか」を説明することとは本質的に異なります。
LLMに必要なのは：
情報源の明示（RAGの出典表示）
生成物であることの表示（AI生成ラベル）
ハルシネーション検知
これらは「説明可能性」というより「出力の来歴・根拠の透明性」と呼ぶべきです。
3. 「ハイリスク利用」概念の不整合
ガイドの記述：
AIシステムのハイリスク利用については、一例としてEU AI Actにおける内容が参考になる
問題点：
EU AI Actの「高リスクAI」は、ほぼ処遇AIです：
採用・人事管理
教育・職業訓練へのアクセス
必須サービスへのアクセス（与信等）
法執行
移民・亡命・国境管理
司法・民主的プロセス
汎用LLM（ChatGPT等）自体は高リスクAIではなく、GPAI（汎用目的AI）として別枠で規制されています。
LLMが「ハイリスク」になるのは、それが処遇AI用途（採用判断支援、与信判断支援等）に使われる場合です。つまり「ハイリスク利用」はLLM固有の問題ではなく、用途（処遇AI化）の問題です。
LLM専用ガイドに「ハイリスク利用」を入れるなら、「LLMを処遇AIとして使う場合は本ガイドの範囲外であり、別途処遇AI固有の規律が必要」と明記すべきでしょう。
4. 混入の原因構造
【混入の経路】
EU AI Act / GDPR
↓
処遇AI（採用・与信等）の規律
・公平性（関連性原則）
・説明可能性（決定理由の説明義務）
・高リスクAI（処遇分野の指定）
↓
AI事業者ガイドライン「共通の指針」
・公平性
・透明性
・説明可能性
（目的類型なく「全AI共通」として整理）
↓
AISIガイド（LLM専用のはず）
・公平性と包摂性 ← 処遇AI由来
・説明可能性 ← 処遇AI由来
・ハイリスク利用 ← 処遇AI由来
AI事業者ガイドラインが「共通の指針」として目的類型を区別しなかったため、処遇AI由来の概念がLLM向けガイドに混入しています。
5. 本来あるべき整理
LLM（生成AI）固有の評価観点：
観点 内容
有害情報の出力制御 犯罪情報、CBRN等の出力抑制
偽誤情報の防止 ハルシネーション対策、ファクトチェック
出力の中立性 ステレオタイプ回避、偏向表現の抑制
生成物の来歴表示 AI生成ラベル、出典表示
プライバシー保護 学習データからの個人情報漏洩防止
セキュリティ確保 プロンプトインジェクション対策
ロバスト性 敵対的入力への安定性
データ品質 学習データの品質管理
処遇AIに移すべき評価観点：
観点 内容
関連性原則 決定目的に関連する情報のみ使用
決定理由の説明義務 決定対象者への個別説明
異議申立て・再審査 決定対象者の権利保障
人間の実質的関与 自動処理のみに基づく決定の制限
「ハイリスク利用」の整理：
LLMを処遇AI用途（採用判断支援、与信判断支援等）に使用する場合は、本ガイドの評価観点に加え、処遇AI固有の規律（関連性原則、説明義務、異議申立て権等）を別途適用する必要がある。
結論
AISIガイドは「LLMシステムを対象とする」と明示しながら、AI事業者ガイドラインの「共通の指針」を経由して、処遇AI由来の概念（公平性、説明可能性、ハイリスク利用）がそのまま混入しています。
その結果：
「公平性」が「出力のバイアス」と解釈され、本来の意味（処遇の公平）とずれる
「説明可能性」が「出力根拠の可視化」と解釈され、本来の意味（決定理由の説明）とずれる
「ハイリスク利用」がLLM固有の問題のように扱われ、実際は用途（処遇AI化）の問題であることが曖昧になる
これは、AI事業者ガイドラインが目的類型を持たずに「共通の指針」を設定したことの帰結です。上流の設計ミスが下流のガイドに波及しています。
私：処遇AIが無視されている側面はひとまず置いておくとして、LLM専用として見たこの文書の出来の問題はどこまで深刻ですか。
Claude：[考え中...]
良い問いです。処遇AI問題を脇に置いて、純粋に「LLMセーフティ評価ガイド」として見た場合の出来を評価します。
LLM専用ガイドとしての評価
1. カバー範囲：概ね妥当
LLMセーフティの主要論点はカバーされています：
評価観点 国際的議論との整合
有害情報の出力制御 ✓ 標準的論点
偽誤情報の防止 ✓ ハルシネーション対策として重要
プライバシー保護 ✓ 学習データ漏洩問題
セキュリティ確保 ✓ プロンプトインジェクション等
ロバスト性 ✓ 敵対的入力への耐性
データ品質 ✓ 学習データ管理
検証可能性 ✓ ログ・モデルカード
欠落している重要論点も特にないと言えます。
2. 具体性の問題：中程度
評価項目例の記述を見ると：
「LLMシステムの出力の有害性スコア（攻撃的であるかどうかなどの有害さを数値で表したもの）を測定した結果、スコアに問題がないか。」
「LLMシステムの出力の流暢性スコアを測定した結果、スコアに問題がないか。
トップ «前3日分 追記
2023-07
2023-06
2023-05
2023-04
2023-03
2023-02
2023-01
2022-12
2022-11
2022-10
2022-09
2022-08
2022-07
2022-06
2022-05
2022-04
2022-03
2022-02
2022-01
2021-12
2021-11
2021-10
2021-09
2021-08
2021-07
2021-06
2021-05
2021-04
2021-03
2021-02
2021-01
2020-12
2020-11
2020-10
2020-09
2020-08
2020-07
2020-06
2020-05
2020-04
2020-03
2020-02
2020-01
2019-12
2019-11
2019-10
2019-09
2019-08
2019-07
2019-06
2019-05
2019-04
2019-03
2019-02
2019-01
2018-12
2018-11
2018-10
2018-09
2018-08
2018-07
2018-06
2018-05
2018-04
2018-03
2018-02
2018-01
2017-12
2017-11
2017-10
2017-09
2017-08
2017-07
2017-06
2017-05
2017-04
2017-03
2017-02
2017-01
2016-12
2016-11
2016-10
2016-09
2016-08
2016-07
2016-06
2016-05
2016-04
2016-03
2016-02
2016-01
2015-12
2015-11
2015-10
2015-09
2015-08
2015-07
2015-06
2015-05
2015-04
2015-03
2015-02
2015-01
2014-12
2014-11
2014-10
2014-09
2014-08
2014-07
2014-06
2014-05
2014-04
2014-03
2014-02
2014-01
2013-12
2013-11
2013-10
2013-09
2013-08
2013-07
2013-06
2013-05
2013-04
2013-03
2013-02
2013-01
2012-12
2012-11
2012-10
2012-09
2012-08
2012-07
2012-06
2012-05
2012-04
2012-03
2012-02
2012-01
2011-12
2011-11
2011-10
2011-09
2011-08
2011-07
2011-06
2011-05
2011-04
2011-03
2011-02
2011-01
2010-12
2010-11
2010-10
2010-09
2010-08
2010-07
2010-06
2010-05
2010-04
2010-03
2010-02
2010-01
2009-12
2009-11
2009-10
2009-09
2009-08
2009-07
2009-06
2009-05
2009-04
2009-03
2009-02
2009-01
2008-12
2008-11
2008-10
2008-09
2008-08
2008-07
2008-06
2008-05
2008-04
2008-03
2008-02
2008-01
2007-12
2007-11
2007-10
2007-09
2007-08
2007-07
2007-06
2007-05
2007-04
2007-03
2007-02
2007-01
2006-12
2006-11
2006-10
2006-09
2006-08
2006-07
2006-06
2006-05
2006-04
2006-03
2006-02
2006-01
2005-12
2005-11
2005-10
2005-09
2005-08
2005-07
2005-06
2005-05
2005-04
2005-03
2005-02
2005-01
2004-12
2004-11
2004-10
2004-09
2004-08
2004-07
2004-06
2004-05
2004-04
2004-03
2004-02
2004-01
2003-12
2003-11
2003-10
2003-09
2003-08
2003-07
2003-06
2003-05
2003-04
2003-03
2003-02
2003-01
2002-12
2002-11
2002-10
2002-09
2002-08
2002-07
2002-06
2002-05
2002-04
2002-03
2002-02
2002-01
2001-12
2001-11
2001-10
2001-09
2001-08
2001-07
2001-06
2001-05
2001-04
2001-03
2001-02
2001-01
2000-12
2000-11
2000-10
2000-09
2000-08
2000-07
2000-06
2000-05
2000-04
2000-03
2000-02
2000-01
1999-12
1999-11
ただのにっき
2023-07-08(土) [長年日記]
■ 川崎 3-0 横浜FC＠等々力陸上競技場
ものすごい久しぶりに現地観戦なわけだが*1、かみさんが別件で来られなくてソロ観戦。
今日は恒例の川崎市政なんちゃらの日で、ハーフタイム小はYMCAだったんだけど、なぜかマッチが来ていて昭和だった。それより、マッチが乗ったオープンカーの後ろを自転車が走っていて笑った。先日のアウェイ神戸戦が大雨で中止になった中、川崎から自転車で神戸まで行って(とうぜん試合を観ずに)帰ってきたサポの人。すっかり時の人だ(笑)。
試合は危なげなく、3-0で勝利。今年ホームで勝ち試合観るの、初めてでは? GKはソンリョンで安心してみていられた。最近は上福元ばかりがスタメンだったけど、あいつ前に出すぎて危なっかしくて見られんないんだもん。
Tags: frontale
*1 グスタフ闘病中はできるだけ家を空けないようにしていたのだ。
[ツッコミを入れる]
2023-06-14(水) [長年日記]
■ グスタフ、骨になる
昨日はかかりつけの動物病院へ連絡したところ、ていねいなエンバーミング後、ぴったりの棺に入れてくれるサービスをしてくれた。休診日だったのにありがたいことだ。そもそもここの診断がなければ半年以上前にこの日を迎えることになっていたわけで、命の恩人としてももはや足を向けて寝られない。今日はそのとき紹介してもらった、大和市にあるペット専用の葬儀場へ。施設としては火葬場に墓地が併設されているものだけど、自宅に庭があるので墓はいらないね、ということで火葬だけ、いちばんいいコースでお願いした。
さすがに出棺のときはべそべそ泣いてしまったが(ここでキャンセルして連れて帰る人もいるらしい。わかる)、がんばってお別れをした。形見として毛を一束切らせてもらい、子猫のときからずっと持ち歩いていたFC東京のタオルマフラー(すでに赤青のボロきれにしか見えない)を一緒に棺へ入れた。グスタフはなぜか手を握ってやるととても安心する猫だったので、別れ際にそっと握ってやったら、体の他の部分はもうカチカチなのになぜか肉球だけはまだ柔らかくて、こっちの指先を優しく押し返してくれた。最後までかわいいやつ。
待合室で一時間ほど待つと、骨上げに呼ばれる。
驚いたことに、ステンレスのトレイに骨格標本のようにきれいに並べられて出てきた。すごい、人間の葬儀でもこんな仕事みたことない。なんといっても目を引くのは、トレイを半周するくらいに長い尻尾だ。グスタフ自慢のしなやかでまっすぐな尻尾が、死んで骨になってもきれいで表情豊かなのをみて、なんだか誇らしい気持ちになった。やっぱ史上最高の猫だよなぁ。
とにかく始終ていねいかつ厳かな対応と、宗教的な押し付けのないセレモニーで、とても好感が持てた。病院といい葬儀場といい、この2日間で愛猫を失ったこと以外でいやな思いをひとつもしなかった。ありがたい。
とはいえ疲労困憊なので、帰宅後はただゴロゴロしながらGoogle Photoでグスタフの写真を眺めてすごした。スマホの登場とタイミングが同じだったこともあって、無限に写真がある。ひとつとして同じ表情の写真がなくて、一日眺めていてもぜんぜん飽きない。おれの胸の上に乗って香箱を組むのが好きだったので、同じアングルはたくさんあるけど。
Tags: gustav
[ツッコミを入れる]
2023-06-13(火) [長年日記]
■ グスタフ、虹の橋を渡る
10月の手術から半年以上、闘病生活を続けていたグスタフが、とうとう最後のときを迎えた。満13歳と10ヵ月でした。
腎不全にともなう貧血が徐々に悪化してきていて、昨日からだいぶ呼吸が苦しそうになっていたので仕事は徐々にキャンセルし、できるだけ一緒にいてやれるようにしていたおかげで、しっかり抱きしめたまま看取ることができた。
新型コロナのおかげでリモートワークが当たり前になり、自宅で過ごす時間が増えたことでいちばん嬉しそうだったのは間違いなくグスタフだったし、最後の最後までいっしょにいられてきっと幸せだっただろうと思う。飼い主のエゴかも知れないけど。
写真は先週の金曜日、最後の散歩のひとこま。三度の飯より散歩が好きなグスタフだったが、最近は庭に出て草をはむくらいしかできなかったのに、この日はなぜか妙に元気で、久しぶりに前の道路まで歩いて出た。すぐに疲れてへたり込んでしまったけど。
明日からはしばらく忌引き。半年かけて徐々に覚悟を決めてきたからショックはないけど、心を落ち着ける時間は必要だ。
Tags: gustav
We’re getting things ready
Loading your experience… This won’t take long.
この広告は、90日以上更新していないブログに表示しています。
雑談用ストーリー [4] 1180
2025年01月12日(日) [晴れ]
＊ [IRC] dev.ircnet.ne.jp : 6667 / 6697 and 6679 提供開始しました
祝) IRCnetJPとして、2025年01月06日に日本国内にとってもとっても新しいIRCサーバーをリリースしました！！
こちらは、既存のIRCnet（日本国内では通称WIDE IRCといわれていた従来のネットワーク)に接続したものを提供しています。
前回同様、私個人ASのネットワーク上に設置されています。また、実験目的での提供となり、カナダに次ぐ2番目のサーバーとして日本に設置されました。インストールされているIRCdのバージョンは、irc2.12.0-preで、今の所ソースコードはGitHub上ではまだPrivateなものになります。IRCnet2においても数台このバージョンが適用され、動作確認がされているようです。既存のIRCnetとの相互接続性などの試験も十分に行われたことから、最新版のIRCdをインストールされたソフトウェアで、既存のネットワークに接続をして今後も開発をしていく、また、SASL対応の環境においてユーザーが困らないかテスト環境を提供するといった趣旨で設置されています。日本に設置を求められた経緯については、次のセクションで記載しますので、是非ご覧ください。
Server Name: dev.ircnet.ne.jp
IPv4: 103.167.46.70
IPv6: 2001:df6:a680:1014::7000
Port: 6667 / 6697 and 6679
※ irc.ircnet.ne.jp の DNSラウンドロビンには組み込みしておりません
IRCnet server info
IRCnet.com SASL
★ 日本に設置されることとなった経緯:
このサーバーは、12月28日頃、IRCnet全体で決まり、既存のIRCnetに日本からサーバーを提供することとなりました。当初開発サーバーは1台のにでよいという他国の意見がありましたが、日本を好意にしてくれている方々が、日本にも必要だと言ってくれたことから、日本にも準備することとなりました。日本にも設置する必要があると認められた理由は、日本独自の文字コードがあり、ISO-2022-JP という文字コードが利用されています。この文字コードに対応するため、これまで、日本のIRCサーバーは「JP Patch」というのを個別に適用してビルドしていました。
このパッチの適用が無い場合、一部の文字が壊れ、チャネルへのログインやメッセージの送信に失敗します。これは、ISO-2022-JP の文字コード由来の一部の文字に潜在的に 「,」「:」 が含まれており、チャネル名に「:」の文字が含まれると、サーバーは区切り文字が来たと判断し、正しいチャネルを作れない、正しいチャネルにJOINできない、メッセージを送れない、壊れたチャネル名が作成されてしまうと言う問題がありました。故に、日本とリンクされている海外のサーバーとの間でも問題が発生しました。そのため、日本国内に閉じたサーバーに限り正しく文字コード処理ができたという話があります。IRCでは、プロトコル上、チャネルとメッセージの間の区切りに、「:」(コロン)を使用します。
このあたりは、 1999年度WIDE報告書 第17部 IRCの運用技術と活用技術に記載がありますので、興味がある方は是非ご覧ください。私がIRCに関わったのは2002年ごろで、私が参加した当時は、irc2.10.xが動作しており、Pentium3なサーバー上で動いていました。ircdそのものが使用しているメモリは100Mも無かったように記憶しています。90年代から使われているプロトコルで当時は回線も数十kbps～数百キロbpsといった細い回線で使われているほどだったそうです。その当時からの実装のため、IRCは非常に軽量な実装となっています。その後、2.11へとアップグレードし少しずつ重たくなりましたが、現在でも数百MB以内に収まっています。IRCとは、Internet Relay Chatとよばれ、メッセージを中継するだけのとてもとてもシンプルな作りになっています。むしろいまはSSL処理の方が重たいのでは...。IRCの歴史については、
IRC Working Groupが解散されるまでの情報が毎年報告書として掲載されておりますので、こちらも気になる方はご覧ください。歴史の一部が分かるかと思います。
少し脱線てしまったので、話を戻します。今回の irc2.12.0-pre では、この「JP Patch」も取り込まれており、ISO-2022-JP に標準で対応されるようになりました。日本のメンテナが事実上不在となったことから私が、今まで使用されていた日本のパッチを投げることにより、新しいバージョンで取り込んでもらうに至りました。こういった背景から、日本人によるテストが必要なこと、日本で多く使われているIRCクライアントの対応の必要性があると言うことで、日本に設置することとなりました。
世界的に見ても、UTF-8に移行している中、日本は未だに ISO-2022-JP から移行できていませんし、今後も移行されることはおそらく無いでしょう。
私が考える大きな理由は、日本で提供されている日本語のクライアントに大きく依存しているためだと考えられます。また、その日本で慣れ親しんでかつ、一般的に利用されているクライアントの多くは開発が終了もしくは事実上メンテされていないことだと考えられます。では、TLS や SASL に対応し、かつ、ISO-2022-JP に対応した海外製のクライアントはほかにあるかというと、HexChat ぐらいしかみつけれませんでした（ほかにあったら教えてください）。そういう私も、Freenode に接続する際、クライアントがUTF-8に未対応のため、Tiarra を用いて文字コード変換を行い、慣れ親しんだクライアントで接続していたりします。
最近、新たにHexChatというのを試してみましたが、ISO-2022-JP にも対応していますが、NOTICEメッセージがきたら画面表示が壊れてみだれたり、なかなかUIになれれなかったりと、苦戦しており、こりゃー、移行がむりだなぁって気分になってしまいます。
今回、新たに用意したサーバーは、新バージョンでSASL対応の環境となるため、IRCクライアントを開発されてきた皆様、この環境を是非役立てていただければ幸いです。お願い申しあげます(切実)
以下についてはあくまでも超辛口個人的なコメントや愚痴で、気分を害するような記載があるので、注意願います。
----------- ここから -----------
特に日本人の多くはリテラシーが低く、また、多くの人は新しいものや変化、英語クライアントというだけで抵抗があったり、日本語で手取り足取り書いてあっても、手取り足取り教えてもらわないと使うことが出来ない人がおおいという感触を受けました。2000年代当時ゲームをしたい、連絡手段にIRCをつかいたいのにわからない。解説サイトがあっても面倒くさいから教えてくれ、それどころか「パソコンの使い方をおしえてくれという教えてクレくれ君」というのを多々見かけました。自分で調べて学ぼうという人が非常に少ないと感じられました。が故に、変化を嫌う、既存のままずっと使い続けるということもあるでしょう。
当時一番シェアを誇った、CHOCOAがISO-2022-JP以降対応していないこともあるでしょう。今まで困ってないし…というのもあるでしょう。これらから日本のIRCnetではUTF-8に行くのも難しく、クライアントの対応有無が混在することから、未だにIRCnetJPにおいては、ISO-2022-JPが標準になっており、今後もおそらく変わることは無いでしょう。無理矢理SASLに強行移行したら、ISO-2022-JPの問題はなくなり、全員UTF-8にいけると思いますが、おそらくそのタイミングで、IRC bouncersの多くが対応不可、また、新たなIRCクライアントを探して自分にあったクライアントを探し、英語の壁や日本語環境でうまく動くかわからない中、試行錯誤すると行った試練が待ち構えているでしょう。また、SASL認証するために登録をして、となると多くのIRCユーザーが離れてしまうと個人的には感じています。
すでに風前の灯火なので。いっそのこと入れ替えるか切り離して、サーバーを分けるという話も管理者の中で議論がありましたが、分断は崩壊を進めるだけになるので、阻止する方向で調整し、折り合いをつける必要がありました。ということで、日本で使われていたIRCクライアントの開発、アップデートが強く望まれます。正直私も行く当てが無くて困ってんだよー！！！(涙)
----------- ここまで -----------
こういう状況から日本の状況も配慮する必要があり、日本のサーバー直下にぶら下がった開発用JPサーバーが必要になったと言うことです。
私が見える範囲のチャンネルで、CTCP Versionをたたいて、どういうクライアントが多く使われているのか、暇なときに集計してみたいなと、思いました。
参考に、日本発日本クライアントで、UTF-8に対応しているのは、LimeChat2, Cottonぐらいで、CHOCOA, RainMaker, LimeChat1 は未対応です。
SASLに対応しているのは、Mac版のLimeChat2のみとなります。
SSL対応と記載があるのは、Windows版iでは、LimeChat2(SSLv3までかな?)、Cotton（対応バージョン未確認)です。時間があるとき調査します。
なお、数少ないUTF-8対応クライアントの一つである、Limechat2 Windos版について、 LimeChat 2.40の配信についても、つい先日ですが、バイナリの配布が停止してしまいました。
これは、 Vectorのホームページサービスが2024年12月20日終了による配布終了が起因です。。。公式の人にバイナリの復活が出来ないか、また当方でミラーをすることができるので、ミラー出来ないか打診してみようかと思います。（Windows版LimeChatで、SASL対応、TLS対応をしてほしい…）
★ IRCnetの利用状況:
現在、IRCnet全体のユーザー数は、執筆の時点で 17,000 程度です。
国別クライアント数(ユーザー数)においては、Netherlands: 3900, Finland: 3200, 日本: 1500 程度で3番目に利用されている国になります(Open serversのクライアント数除く)。
世界全体でもみても、日本はまだ上位3位に位置しています。まだまだ日本にユーザーがいることから、無視は出来ない存在だと思います（移行できないなら、切り離すという話も出ました…がなんとか阻止しました)
なお、全盛期、IRCnetJP(日本のクライアント数)では、接続数で2万以上ありました...
IRCの利用者人口は年々減っておりますが、また活気を取り戻したいなあ、これほどシンプルで素晴らしいプロトコルはないので、是非とも皆さん、新しい動きがありますので是非戻ってきてください。インターネット中年会や老人会といわれても仕方ありませんが、昔懐かしのチャンネルもまだ残っておりますので、是非もどってきてくださいませ。dh.ircnet.ne.jp を含め、日本のIRCサーバーはまだまだ生き残ります。というか私が引っ張っていきます。
日本の中のオペレーター内にあった蟠りもほぼ解消しております。これから新たなスタートに向けて勢いをつけて行きたいので、是非レガシーな懐かしい世界にもどってきてくださいませ。今回SSLの対応も入っていることから通信路の暗号化も実装が入りました。通信路を暗号化したい方は、是非TLSをご利用くださいませ。
さらに、IRCサーバーを設置させていただけるネットワークも是非募集中です。興味がありましたら国際間で調整しますので、是非お声がけください。
DDoS対策などのノウハウも必要に応じて技術提供いたします。
★ IRCといえば、TELNET クライアントが一番最強でしょ？:
IRCといえば、TELNETで接続出来るぐらい軽量であり、シンプルなプロトコルであると言うことが言えます。では、IRCnet2や、今回リリースした、dev.ircnet.ne.jp など、SASL認証が入ったネットワークではどのように接続するのでしょうか？また、TLSに対応した場合どのように接続するのでしょうか？それはとても簡単なことです。手で接続するときのサンプルを貼り付けておきますので是非ご参考にしてください。なお、SASL Plain認証による例となります。
SASLパスワードである、SASL Plain Base64は以下の方法で作成します。
PLAIN 認証では mechanism が PLAIN、argument が "ユーザID\0ユーザID\0パスワード" という文字列を Base64 エンコードした物になる。
以下はユーザ名 user、パスワード pass の場合の argument 文字列を作成する Perl スクリプト。
$ perl -MMIME::Base64 -e 'print encode_base64("user\0user\0pass");'
dXNlcgB1c2VyAHBhc3M=
(出展： SASL base64によるエンコード演算プログラム)
$ openssl s_client -connect dev.ircnet.ne.jp:6697
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = E5
verify return:1
depth=0 CN = dev.ircnet.ne.jp
verify return:1
---
Certificate chain
0 s:CN = dev.ircnet.ne.jp
i:C = US, O = Let's Encrypt, CN = E5
1 s:C = US, O = Let's Encrypt, CN = E5
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDgDCCAwagAwIBAgISA/quCPeNgRf1slSZe33yZY9FMAoGCCqGSM49BAMDMDIx
CzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQDEwJF
NTAeFw0yNTAxMDQyMjU4MjhaFw0yNTA0MDQyMjU4MjdaMBsxGTAXBgNVBAMTEGRl
di5pcmNuZXQubmUuanAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASBXLHJvou7
6Y94f1lt+/bcXPpn6VGAE7GP515BXHC0rdld42PRzf3IsG9ZxXBRKuwRduwtBqRJ
51/TWjfL+oCfo4ICETCCAg0wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSZloGZjyx5
iX0fQ1jpuQ1ogjXEVjAfBgNVHSMEGDAWgBSfK1/PPCFPnQS37SssxMZwi9LXDTBV
BggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9lNS5vLmxlbmNyLm9y
ZzAiBggrBgEFBQcwAoYWaHR0cDovL2U1LmkubGVuY3Iub3JnLzAbBgNVHREEFDAS
ghBkZXYuaXJjbmV0Lm5lLmpwMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBAwYKKwYB
BAHWeQIEAgSB9ASB8QDvAHUAzPsPaoVxCWX+lZtTzumyfCLphVwNl422qX5UwP5M
DbAAAAGUM8AlswAABAMARjBEAiBg5IYH82Y0AJUas19n9+8ExDWRPwayYtT9gfvA
MKWNbwIgXyPRcyIUDvSefA5RlJw1CfrMGOq+PJyMVRm5zcmW3OkAdgDgkrP8DB3I
52g2H95huZZNClJ4GYpy1nLEsE2lbW9UBAAAAZQzwCXNAAAEAwBHMEUCIHZH1YFd
kKnBJtWC7/BkHG55Cr/hoCmjDqrUz6Eot3dmAiEAqkNhkBR9A21oeHhyZ/1AilJy
LzkovRd+OHWN4MQI0OYwCgYIKoZIzj0EAwMDaAAwZQIwXDduNyxWjoLYrZV0nLl0
fnwPUTIJ2VXzTLxR3iWXoU1nrFXgX33P5mS9+M7SkoT5AjEA3aMK1Z+MmU5q0ALV
J2Xf1NAP4Y2KqoVQydVrqoQdncsZggwWpi44e6SJwo5KJCRm
-----END CERTIFICATE-----
subject=CN = dev.ircnet.ne.jp
issuer=C = US, O = Let's Encrypt, CN = E5
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2395 bytes and written 394 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 46A60731DA3425BF57E81CC83E8ABD79E91DD0D2218CD7326AF6DE134C5646F5
Session-ID-ctx:
Resumption PSK: E0C3ECD28DA503688DAB2327F18A5E9EC7B7C7C3A07B2FA417A73F5780653E303A15D344FD1CE482B403D63910C3CD90
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - 52 b5 47 b0 35 44 cc 3b-de 32 57 59 08 92 2d f8 R.G.5D.;.2WY..-.
0020 - 0f b0 da da 9c 5c 1e 73-56 c2 f1 c2 f4 be 35 46 .....\.sV.....5F
0030 - 11 dd b0 3d 64 c9 1c 0c-85 6c ec ba f3 20 05 08 ...=d....l... ..
0040 - 6d 42 e6 65 a3 66 28 73-5c 23 ac da e0 52 1e 39 mB.e.f(s\#...R.9
0050 - 57 3a db 82 81 06 d4 b8-85 ad 50 cd 42 c8 d9 94 W:........P.B...
0060 - d6 89 04 8f 24 9c 91 20-de 47 e6 4b 14 dd b8 a1 ....$.. .G.K....
0070 - 23 bc 26 76 99 39 0f 99-d6 70 aa ab dd 77 aa f9 #.&v.9...p...w..
0080 - 09 1d 9a ef 8d 1b 99 db-9d 8f 3a 97 89 d6 db ad ..........:.....
0090 - 62 07 27 30 71 4d b3 ae-19 e7 8a 74 07 8a b1 d8 b.'0qM.....t....
00a0 - 10 18 e0 53 27 68 5d 75-80 01 c6 a7 c0 d8 59 79 ...S'h]u......Yy
00b0 - 9a 04 c8 a9 af fe 9f f7-32 7d 40 68 55 7c 28 f0 ........2}@hU|(.
00c0 - 67 5f 6a b9 0b 95 8c 0f-3c 14 41 ee 3c ac 6f 20 g_j.....<.A.<.o
00d0 - d9 74 1d d1 5c ed b7 41-18 01 6a 7b 1d 4f c4 87 .t..\..A..j{.O..
00e0 - 04 52 f0 3f 36 6f c8 68-ca bc a3 72 04 80 36 11 .R.?6o.h...r..6.
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: A06D178561B14439775672D22209A1E52A16D6A86246CDD5C4D3C4674A32F950
Session-ID-ctx:
Resumption PSK: C740D49409010B867FC4E8583F8773FE550E1BF1FBA222B54C5E031F9D7458FD9F0D5C9A94519745B0D4E527E9925838
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6b f1 a1 2c e9 6f 56 63-ce 00 9b 88 1f 16 c6 a2 k..,.oVc........
0010 - d6 78 1a 4c cd 24 d9 2c-a3 ff 90 db 7e ec 46 56 .x.L.$.,....~.FV
0020 - 27 7c b3 84 ee 0b 08 de-e1 3c 8b 7a 52 24 97 89 '|.......<.zR$..
0030 - f9 70 a7 a3 1d b0 2e 88-62 b5 83 db 33 88 8a fc .p......b...3...
0040 - ac ef de 9b ba fa c6 d4-42 26 1c c6 e9 c5 e0 78 ........B&.....x
0050 - d8 18 f5 8a 29 c8 bf 83-10 bd e1 e0 4b f2 bb e0 ....).......K...
0060 - 87 68 90 7b 7b fc 3a 07-83 f5 fb 5d 7e 4e 5b 64 .h.{{.:....]~N[d
0070 - 11 4a 0d d8 a0 8c 33 d8-9b d8 34 c0 6d e0 b4 77 .J....3...4.m..w
0080 - 7d 22 42 41 dd 1f 25 3a-29 11 53 34 d7 57 cb 97 }"BA..%:).S4.W..
0090 - 3c a3 e4 ee 11 8b 81 1d-29 ef a3 a3 42 3b 69 60 <.......)...B;i`
00a0 - 86 12 22 f0 65 7b 1a 39-f7 f8 b7 5e db 62 0e 21 ..".e{.9...^.b.!
00b0 - ee dd 68 53 f0 0f cc 20-71 0c e9 04 8a c8 ba e8 ..hS... q.......
00c0 - 4a 78 24 a3 c7 91 55 a2-16 44 c0 ea b5 e1 70 4f Jx$...U..D....pO
00d0 - 43 3b 5b 9b a6 b9 22 17-69 de 44 14 3a 5c 08 71 C;[...".i.D.:\.q
00e0 - 4c 73 e7 9d 5e 95 48 62-32 a0 d8 1e 72 85 0b 12 Ls..^.Hb2...r...
Start Time: 1736755741
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
:dev.ircnet.ne.jp 020 * :Please wait while we process your connection.
CAP LS 302
:dev.ircnet.ne.jp CAP * LS :extended-join ircnet.com/extended-join multi-prefix sasl
NICK tomocha_dev4
USER tomocha 0 * :tomocha
CAP REQ :extended-join multi-prefix sasl
:dev.ircnet.ne.jp CAP tomocha_dev4 ACK :extended-join multi-prefix sasl
AUTHENTICATE PLAIN
AUTHENTICATE +
AUTHENTICATE <encode_base64("user\0user\0pass");>
:dev.ircnet.ne.jp 900 tomocha_dev4 tomocha_dev4!tomocha@tomocha.users.ircnet.com tomocha :You are now logged in as tomocha.
:dev.ircnet.ne.jp 903 tomocha_dev4 :SASL authentication successful
CAP END
:dev.ircnet.ne.jp 001 tomocha_dev4 :Welcome to the Internet Relay Network tomocha_dev4!~tomocha@tomocha.users.ircnet.com
:dev.ircnet.ne.jp 002 tomocha_dev4 :Your host is dev.ircnet.ne.jp, running version 2.12.0-pre(3a7b5ff)
:dev.ircnet.ne.jp 003 tomocha_dev4 :This server was created Sun Jan 5 2025 at 07:55:02 JST
:dev.ircnet.ne.jp 004 tomocha_dev4 dev.ircnet.ne.jp 2.12.0-pre(3a7b5ff) aoOirw abeiIklmnoOpqrRstv
:dev.ircnet.ne.jp 005 tomocha_dev4 RFC2812 PREFIX=(ov)@+ CHANTYPES=#&!+ MODES=3 CHANLIMIT=#&!+:42 NICKLEN=15 TOPICLEN=255 KICKLEN=255 MAXLIST=beIR:64 CHANNELLEN=50 IDCHAN=!:5 CHANMODES=beIR,k,l,imnpstaqr :are supported by this server
:dev.ircnet.ne.jp 005 tomocha_dev4 PENALTY FNC WHOX EXCEPTS=e INVEX=I CASEMAPPING=ascii NETWORK=IRCnet :are supported by this server
:dev.ircnet.ne.jp 042 tomocha_dev4 392DAAAQK :your unique ID
:dev.ircnet.ne.jp 251 tomocha_dev4 :There are 17352 users and 2 services on 32 servers
:dev.ircnet.ne.jp 252 tomocha_dev4 75 :operators online
:dev.ircnet.ne.jp 254 tomocha_dev4 10145 :channels formed
:dev.ircnet.ne.jp 255 tomocha_dev4 :I have 35 users, 1 services and 1 servers
:dev.ircnet.ne.jp 265 tomocha_dev4 35 37 :Current local users 35, max 37
:dev.ircnet.ne.jp 266 tomocha_dev4 17352 19763 :Current global users 17352, max 19763
:dev.ircnet.ne.jp 375 tomocha_dev4 :- dev.ircnet.ne.jp Message of the Day -
:dev.ircnet.ne.jp 372 tomocha_dev4 :- 5/1/2025 20:00
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server: dev.ircnet.ne.jp
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Location: Tokyo, Japan
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Admins: tomocha
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Disclaimer
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This is an irc 2.12.0 development server. To connect you
:dev.ircnet.ne.jp 372 tomocha_dev4 :- need to authenticate with SASL: https://sasl.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- This server is running for AS45679 experimental purposes
:dev.ircnet.ne.jp 372 tomocha_dev4 :- and stability is not assured.
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Website: https://www.ircnet.com
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Server/Channel list: https://www.ircnet.info
:dev.ircnet.ne.jp 372 tomocha_dev4 :- Webchat: https://ircnet.chat
:dev.ircnet.ne.jp 372 tomocha_dev4 :-
:dev.ircnet.ne.jp 372 tomocha_dev4 :- *************************************************************
:dev.ircnet.ne.jp 376 tomocha_dev4 :End of MOTD command.
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Your connection is secure (SSL/TLS).
:dev.ircnet.ne.jp NOTICE tomocha_dev4 :Due to an administrative decision, your connection is cloaked.
JOIN #arege
:tomocha_dev4!~tomocha@tomocha.users.ircnet.com JOIN #arege * :tomocha
:dev.ircnet.ne.jp 353 tomocha_dev4 @ #arege :tomocha_dev4 ...(snip)
:dev.ircnet.ne.jp 366 tomocha_dev4 #arege :End of NAMES list.
quit
ERROR :Closing Link: tomocha_dev4[~tomocha@tomocha.users.ircnet.com] ("")
closed
★ 参考リンク:
IRCnet.com
ircnet.info
IRCnet-JP 情報提供サイト
WikiPedia: Internet Relay Chat
WikiPedia: Wikipedia:チャット
IRCv3 Specifications
RFC7194 : Default Port for Internet Relay Chat (IRC) via TLS/SSL
Liber.chat - Using SASL
IRCv3 - IRCv3.2 SASL Authentication
SASL base64によるエンコード演算プログラム
[ コメントを読む(0) | コメントする ]
＊ [IRC] IRCNET2.com の ircnet2.ircnet.ne.jp のサーバーをリリースしました
ずいぶん前のネタになりますが、日本のIRC管理者は、Tomocha だって海外から宣言されて、 IRCnet2という網で、新しい実装をした実験網だから日本でも提供してほしいといわれたので、提供することにしました。
サーバー名は、 ircnet2.ircnet.ne.jpというホスト名で提供することになりました。本文にも記載しているとおり、個人AS、個人所有の設備で運用しているものであり、実験・研究・自ASのネットワーク品質のモニタリングのため、品質は保証いたしませんが、最大限の安定稼働を出来るよう努めさせていただく予定です。
サーバー情報
Server Name: ircnet2.ircnet.ne.jp
IPv4: 103.167.46.69
IPv6: 2001:df6:a680:1014::6900
Port: 6667 / 6697 and 6679
IRCNET2
IRCNET2 - What's SASL and how it works?
IRCNET2 - Server List
IRCnet2では、構築当初 irc2.11.3 (2024/12/13 release)のRCバージョンで動いており、ircnet2用(後にirc2.12.0で取り込まれる内容)のパッチ適用し、SASL認証、TLS接続などの実装が入っております。
基本的には、既存のIRCnetとは独立していますが、ゆくゆくは既存のIRCnet網と統合するか、廃止するかという前提での運用のようです。
そんなわけで、日本時間の2024年8月28日夜23時頃メッセージが来て、0時頃にはサーバの準備が始まり、海外との国際リンクの構築を行い、朝の5時にはリリースしているという頭のおかしい状況が出来ました(祝）
提供に至った経緯としては、自ASは実験・検証での使用を主としており、サービスを設置していないこと、品質のモニタリングをするにあたってもサービスが無いため正確なモニタリングがしにくいこと、IRCというプロトコルの特性上、常時TCPコネクションを張り続けるといいとてもインフラを管理する側からすれば嫌な実装で、メンテナンスしにくい実装です。これらの特徴から、ネットワークの安定性が一目瞭然でわかりやすく、ネットワークの品質モニタリングもかねて提供するに至りました。また、irc2.11.2より、14年間開発が停止しており、政権交代ならず世代交代、枯れたプロトコルから今時の実装として、認証・認可、またSSL/TLS対応などを行っています。このあたりは、 IRCv3 Specifications準拠に伴う内容となります。このサーバーは、世界と接続された日本国内にある唯一オープンなサーバーであり、実験的リソースの供給という公共・社会性から判断しました。ここからは完全な個人的な思いなのですが、WIDE ProjectのIRC Working Groupから始まり、20年以上日本のサーバーの管理者の一人として運用に関わっています。また、当時研究してきたものが廃れて日本または世界から消えていくのは忍びなかったことなどがあります。そんななか20年以上面倒を見ていたところ、海外より相談があったことから、じゃあ、日本でももう一回ちゃんとやるか！って気持ちになり、取り組み始めたのが現在です。これらの成果は今後、日本のIRCnetに生かされるはずで、それにより、20年以上生活した憩いの場を失うのを阻止しようという思いもあります。でも人口は減っていく悲しさ...
★ 接続方法:
IRCnet2に接続するには、最初に アカウント登録をする必要があります。
その上で、SASL対応のクライアントで、ircnet2.ircnet.ne.jp を設定すればよいでしょう。また、既存の CHOHOAはSSLそのものが未対応、Windows版の LimeChatでは、TLS1.2以降に未対応のため、IRCサーバーには接続出来ません。また、SASL認証にも対応していないため、事実上HexChatかmIRCあたりになります。
対応クライアント一覧は、 IRCnet2 How to configure SASLを参照の上接続ください。
Mac版のLimeChatはGitHubに公開されているソースコードベースに、SASL Plain認証のみ使用可能となっています。
なお、 サーバー一覧にサーバーリストもあり、実際に接続されているサーバー一覧、ユーザー数、IRCdのVersion、設置されている国などの一覧表があります。
そのほか、 Tiarraについては、PerlのSSLライブラリを使用している
(参照： Tiarra over SSL without stone) ことから、そのままSSL/TLSで対応出来ますが、今後、実装が変わっていく可能性が高いことから、SASLの実装をしてほしいとご本人に聞いてみたところ、SASL対応するコードを追加する予定はなさそうなので、雄志によるパッチのリクエストを私は希望します。 :)
なお、 Tiarra - ChangeLogや、 doc-srcをみても、SSL対応の記載が無く、 tiarra/main/Tiarra/Socket/Connect.pm
を見たところ、以下の記載があり、commit logで確認することが出来ました。
* check ssl module before connect.
* fix bug tiarra entering busy-loop after verification error.
* handle ssl-configuration failure.
現時点では、IRC Bouncers で、SASL対応しているクライアントは見つけれておりませんので、ご存じの方は教えてください。
★ ネットワーク運用のこぼれ話:
運用開始して数日後、10Gbpsを超えるDDoSを受けているらしいです。
直接流れ込むトラフィックもあり、モニタリングしていると、数時間毎に5分間のDDoSを観測されるなどとてもとても楽しい状況を楽しんでおります。
この自宅にある個人ASは10Gbpsの専用線を含むアップリングが複数本あり、そのほか、1Gbpsになりますが、NGN閉域接続のよる回線などがあります。ルータについては、Cisco ASR や 各種ソフトウェアルータなど複合的に組み合わせ、冗長化構成を取っており、リージョン間でも同様の仕組みを構築しています。その辺の普通の一般的なAS運用と同じレベルでの運用を目指しておりますが、電気代高騰に伴うコスト増のため、半分はハードウェア、半分はソフトウェア(仮想化基板上)で実装していました。
その中で、10Gbpsを超えるDDoSが流入し、一部のパケットが仮想化基盤へ流れ込み、その結果ppsに負けてしまい、vDS含む仮装基板が破綻しました。帯域では無くパケットの数で負けました。なお、ハードウェアで構成されたネットワーク部分については、余裕でした。
自宅の構成は、インターフェースはすべて10G以上で構成されているので帯域的には戦えるのですが、それ以前のボトルネックにぶち当たる羽目に。元々、普段トラフィックがないので通常は仮想化することによる集約メリットがあるのですが、DDoSが流れ込むと仮装基板が破綻することから、一部のサービスを仮想化するという事を辞め、機能ごとに、オンプレに回帰する方向に向かっています。
もちろんナレッジをためたいのは山々ですが、DDoSを耐えるためのオーバースペックともいえる最新CPUの搭載したサーバーを何台も用意しチャレンジする、とか、SR-IOVやNICをまるまるVMに渡すなど、いくつかの方法は考えられるのですが、結局、その分システム全体が大きく、また複雑になります。自宅で運用するには金銭面だけではなく、運用コストも含めると、全くもってコストメリットがでない状態になります。また、DDoSに耐えれる仮想化基盤を作るのが目的では無く、リソースの集約のための仮想化基盤のため、リソースの集約が出来ないような代物については、オンプレでホストごと潰すというのが一番手っ取り早くてコストが安いものです。ネットワーク機器の仮想化は日常的にDDoSが来る事を想定すると向かないということが頭ではわかっていたものの、ここまで性能が出ないのかというのを目の当たりにしました。また、ホストの組み合わせ方によっては巻き添えを喰らうvmもでてくることから、結局組み合わせなどを考えて最適な配置をする必要が出てきて、結果物理サーバーの台数が必要になってしまいます。
また、トランジットを受けている一部の上位でも悲鳴が上がり、協議の結果、BGP flowspecによるネットワーク保護、RTBH、特定IPに対して、事前フィルタを上位で設定するなど、いくつか調整を行い、DDoSパケットを落とす仕組みが入っています。
そのほか、IRCでは、C&Cサーバー *1 などが設置され悪用されることも多いと言われていますが、IRCnetにはそういうのが居ないことを願いたいものです。今回、そのためユーザーを認証するという概念が取り込まれています。セキュリティー系の人からすれば、IRCってC&Cサーバーの温床でしょ？っていう方も居るぐらいIRC=C&Cのプラットフォームと思われているケースもあります。
ガチ運用できて落としても怒られないASって最高ですね。面白い。商用でこういうサービスをぶち込む勇気のある事業者がほとんどおらず、WIDE ProjectがIRCの提供を終了するとなったとき、引取先や協力してくれる事業者やASが見つからなかったのもそういう背景がありました。だったら、おうちで持ってみたらどうか？って思い始め、さらに品質モニタリングもしちまえっていうのが今回の私のテーマです。とりあえず、対外線などを100Gになればとりあえず頑張れるのですがなかなか頑張れる気がしませんね。
そんなわけで、省電力で10G喰えてソフトウェアルータに向く箱、IRCサーバーに向く箱などを探していたというのもあり、先日の 2024/05/06 MINISFORM MS-01検証などをやってたというのが実は関連していたりしました。個人的には見送りましたけど....
面白そうだからオンプレだけじゃなくて、クラウドやVPSにおいてどうなるかもためしてみたいなぁ。
*1:
C&Cサーバー：
「コマンド&コントロール（C&C）サーバ」とは、ボットネットや感染コンピュータのネットワークに対し、不正なコマンドを遠隔で頻繁に送信するために利用されるサーバのこと。この用語は、もともと、司令官が目的遂行のために、部隊へ直接指令（com >
mand）を送り、制御（control）するといった軍事的な概念から派生したものである。C&Cサーバは、「Internet Relay Chat（IRC）」や>正規のWebサイト、ダイナミックDNSサービスを利用することで知られている。
(出展: TrendMicro: コマンド&コントロール（C&C）サーバ)
[ コメントを読む(0) | コメントする ]
Diary for 3 day(s)
ブログを開設した年のグループに入りましょう
はてなブログには、同じ話題でつながる「グループ」があります。まずはブログを開設した年のグループに入りましょう。同時期に始めたブログとつながることができます。
「2025年開設ブログ」のグループ
「字幕職人の朝は早い……」にコメントを書く
northADの日記
読者になる
ripjyr's blog
読者になる
読者になる
おきらくにっき
読者になる
登 大遊 (Daiyuu Nobori) の個人日記
読者になる
うさぎ文学日記
読者になる
情報てとりす。
読者になる
R'lyeh ノ記
読者になる
TOTOROの自堕落 日記
読者になる
蠅蠅蚊蚊蚊金鳥ル。
読者になる
teracc’s blog
読者になる
motonの日記
読者になる
9DOの日記
読者になる
たぬきん貧乏日記 〜No Worry, No Hurry. Eat Curry!〜
読者になる
luminのコードメモ
読者になる
SecuDiary
読者になる
Luffyのメモ
読者になる
ヴァルカンの気まぐれ日記
読者になる
CVSSとその限界
Vuls祭り#8資料 2023-09-15
CSPを無意味にする残念なServiceWorker
Shibuya.XSS techtalk #12資料 2023年7月25日
Bluesky
hasegawa.bsky.social
▼ ▶
2021
2021 / 12
2021 / 9
▼ ▶
2020
2020 / 12
2020 / 5
▼ ▶
2019
2019 / 12
2019 / 7
2019 / 6
▼ ▶
2018
2018 / 12
2018 / 11
2018 / 10
2018 / 8
2018 / 3
2018 / 1
▼ ▶
2017
2017 / 12
2017 / 10
2017 / 5
2017 / 3
2017 / 2
2017 / 1
▼ ▶
2016
2016 / 12
2016 / 8
2016 / 7
2016 / 6
2016 / 4
2016 / 2
2016 / 1
▼ ▶
2015
2015 / 12
2015 / 10
2015 / 9
2015 / 8
2015 / 6
2015 / 5
2015 / 4
2015 / 3
2015 / 2
2015 / 1
▼ ▶
2014
2014 / 12
2014 / 7
2014 / 5
2014 / 4
▼ ▶
2013
2013 / 12
2013 / 9
2013 / 6
2013 / 5
2013 / 4
2013 / 3
2013 / 2
2013 / 1
▼ ▶
2012
2012 / 12
2012 / 11
2012 / 10
2012 / 9
2012 / 8
2012 / 7
2012 / 6
2012 / 5
2012 / 4
2012 / 3
2012 / 2
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 11
2011 / 10
2011 / 9
2011 / 8
2011 / 7
2011 / 6
2011 / 5
2011 / 4
2011 / 3
2011 / 2
2011 / 1
▼ ▶
2010
2010 / 12
2010 / 11
2010 / 10
2010 / 9
2010 / 7
2010 / 2
2010 / 1
▼ ▶
▼ ▶
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
2004 / 6
2004 / 5
2004 / 4
2004 / 3
▼ ▶
2003
2003 / 10
▼ ▶
1000
1000 / 1
▼ ▶
0
0 / 1
▼ ▶
2022
2022 / 1
▼ ▶
2021
2021 / 7
2021 / 6
▼ ▶
2020
2020 / 6
2020 / 5
2020 / 4
2020 / 3
2020 / 2
▼ ▶
2019
2019 / 2
▼ ▶
2017
2017 / 7
2017 / 5
▼ ▶
2016
2016 / 10
2016 / 8
2016 / 7
2016 / 4
2016 / 3
2016 / 2
▼ ▶
2015
2015 / 10
2015 / 8
2015 / 4
2015 / 2
▼ ▶
2014
2014 / 8
2014 / 6
2014 / 3
▼ ▶
2013
2013 / 12
2013 / 9
2013 / 8
2013 / 7
2013 / 6
2013 / 5
▼ ▶
2012
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 11
2011 / 9
2011 / 8
2011 / 7
2011 / 6
2011 / 5
2011 / 4
2011 / 3
▼ ▶
2010
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 4
▼ ▶
2009
2009 / 12
2009 / 11
2009 / 10
2009 / 9
2009 / 8
2009 / 7
2009 / 6
2009 / 5
2009 / 4
2009 / 3
2009 / 2
2009 / 1
▼ ▶
2008
2008 / 12
2008 / 11
2008 / 10
2008 / 9
2008 / 8
2008 / 7
2008 / 6
2008 / 5
2008 / 4
2008 / 3
2008 / 2
2008 / 1
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
2004 / 6
2004 / 5
2004 / 4
2004 / 3
2004 / 2
2004 / 1
▼ ▶
2003
2003 / 12
2003 / 11
2003 / 10
2003 / 9
▼ ▶
0
0 / 1
▼ ▶
2020
2020 / 6
▼ ▶
2018
2018 / 12
▼ ▶
2017
2017 / 12
2017 / 3
2017 / 2
2017 / 1
▼ ▶
2016
2016 / 12
2016 / 11
2016 / 1
▼ ▶
2014
2014 / 6
▼ ▶
2013
2013 / 12
2013 / 1
▼ ▶
2012
2012 / 12
2012 / 10
2012 / 9
2012 / 6
2012 / 5
2012 / 1
▼ ▶
2011
2011 / 12
2011 / 8
2011 / 6
2011 / 5
2011 / 4
2011 / 3
2011 / 2
2011 / 1
▼ ▶
2010
2010 / 12
2010 / 11
2010 / 10
2010 / 9
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 4
2010 / 3
2010 / 2
2010 / 1
▼ ▶
2009
2009 / 12
2009 / 11
2009 / 10
2009 / 9
2009 / 8
2009 / 7
2009 / 6
2009 / 5
2009 / 4
2009 / 3
2009 / 2
2009 / 1
▼ ▶
2008
2008 / 12
2008 / 11
2008 / 10
2008 / 9
2008 / 8
2008 / 7
2008 / 6
2008 / 5
2008 / 4
2008 / 3
▼ ▶
2007
2007 / 10
2007 / 9
2007 / 8
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 6
2006 / 5
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
HOME
LOG
Wiki
QX UG
BAD's
GEM's
HOME
annex1
TORON
SBM
BAD's
SITE's
HOME
annex2
BeChic
REVIEW
BAD's
BBS
お笑いパソコン日誌
Take You To The Pilot
Text by Terry Minamino
Music by IKO-IKO
不動産情報
2007/12/9 PM 1:05
＠ 今日の今年の回顧・2007年はチョー豊饒
まだ三週間残ってるつーのに、早漏気味の回顧である。若いときはチロー気味で顰蹙をかったこともあるくらいだが、年々ソーロー傾向が高まりつつある。これも老化現象の一つであろうか。なんの話だモゴモゴ。
さて諸君。今年はここ十年間でも、いや、ひょっとすると歴史上もっとも良い一年であったかもしれない。素晴らしいことにショートパンツが若い女性の間で流行ったんである。それも、ケチくさく詐欺まがいのキュロットもどきのショートパンツではなく、写真のようにきっぱりと潔いどうだこのヤロー的ショートパンツ、古いいい方だとホットパンツ、が流行ったのである。すんばらしいではないか。街にはショートパンツ姿の女のがわしわしいたし、テレビでもがんがんタレントが見せてくれた。ちなみに上の写真は私の脚フェチ＆ホットパンツ好き＆ピンヒール好みを察知したキャバクラ嬢が、そんなに好きならと同伴の時に着てくれた時のものである。いやはや眼福頓服ぷっぷくぷう、カミサマありがとー。ま、ちょっと高くついたけどな。うはは。
Permalink | BBS
不動産情報
2007/11/26 PM 9:49
＠ 今日のヨタ・ソフトバンクの広告に隠された暗喩を読む
ソフトバンクモバイルのテレビコマーシャルには二つの路線がある。スターがケータイで話しながら歩くだけの古典的なイメージアップ戦略ものと、謎の家族が謎の生活をしているという（まあこっちも新奇とはいいがたいのだけど）ものの二つだ。それについて、私はある発見をしたのでここに記しておく。なお、これは半年ぐらい抱えてるネタなので、すでにどなたかが同じ話を書かれている可能性も高いが、もしもカブってたらゴメンね。あと、あくまでネタなんで、そこんところもよろしく。
先日、スターが歩く路線の方に、キティちゃんが登場した。それを見た私は、次はミッキーマウスが出てくると思った。理由は二つある。一つは、ディズニーがソフトバンクから回線を借りて日本のケータイ業界に進出してくるというニュースがあったからだ。ただよく考えるまでもなく、その場合ディズニーは自分でミッキーを使いたいだろうから、この読みは浅すぎた。実際、登場したのはディズニーキャラではなくスヌーピーだったわけだ。
さて、もう一つの理由が本題である。私はミッキーだと考えたのと同時に、男のアニメキャラが使われると考えた。まあこっちは誰にでも予想がついただろう。ただし、絶対日本のアニメからは使われないと考えた方はいるだろうか？ それが予想できたのは、もう一つの路線の方にヒントがあったからだ。
考えても見て欲しい。変な家族篇に登場する男は、犬と黒人とイルカである。一方、女はすべて日本人なのだ（実は違うというオチはナシという方向で）。やや微妙な話になってきたので書き方には注意が必要であろうが、そういうことなんである。だからアメリカ製の男のキャラクタが使われたのである。間違いない（死語）。
ところでこれはいったいなんの暗喩であるのか。あえてオチまでは書かないことにしよう。各自自分で考えてくだされ。ただ、下手するとソフトバンク側は誰もこの事実に気がついてないという恐れもある。その場合は代理店とかディレクターとか、そこらあたりに悪意を持った犯人がいることになるが。みゅう。
Permalink | BBS
以前の記事へ
2021-12-31
2021/5/4 エベレスティング
読者になる
http:
読者になる
2006|01|03|
2015|09|10|11|
2016|01|04|
2021/04/05 島根県松江市における大規模火災にかかる災害救助法の適用について
はてなブログ アカデミー
法人プラン
高田馬場
杉並区
瑞穂町
目白
飯田橋
西東京市
中野区
豊島区
八丈町
〓
Copyright © 2005-
Theme
Light
Dark
High contrast
2019-07-26
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
本日、2019年7月26日、はてなダイアリーからはてなブログへのデータの自動移行及び、移行先のブログへのリダイレクトなど移行に関する工程が完了いたしました。
これまではてなダイアリーをご利用いただき誠にありがとうございました。
つきましては、ご自身のダイアリーからデータの移行が正常に行われているか、はてなブログへのリダイレクトが行われるかなどご確認ください。もし、ご不明な点などございましたら、2019年9月1日までに下記のお問い合わせ窓口までご連絡ください。
https://www.hatena.ne.jp/faq/q/diary
なお、すべての記事を削除しているダイアリー、一部のはてなダイアリーについては引き続きはてなダイアリーが表示されておりますが、今後徐々に閲覧できなくなる予定です。
どうぞよろしくお願いいたします。
移行に関する注意事項
はてなブックマークについては、徐々に移行が行われていきます
移行完了までに数ヶ月かかる可能性もございますが、何卒ご了承ください
本日記にて告知いたしました通り、自動移行によらずはてなブログへの移行を行っていたブログについても、リダイレクト処理を行っています
リダイレクトを希望されない場合は、お問い合わせ窓口までご連絡ください
よくある質問
はてなダイアリーでは、メインアカウントでログイン中に非公開のサブアカウントのダイアリーが閲覧できるなど、サブアカウントに関する機能を提供していましたが、はてなブログでは提供していません。ブログごとに閲覧権限の設定をお願いします
hatenadiary 2019-07-26 15:30
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
Tweet
もっと読む
コメントを書く
はてなダイアリーからはてなブログへの自動移行が完了し、はてなダイアリーでの記事の公開が終了しました
コメント
2017-12-06
■ [Joke] ローカルネットワークに対するクロスオリジンの攻撃からシステムを守る簡単な方法
インターネット上に公開されているわなサイトを経由して社内イントラネットなどのローカルネットワークへXSSやCSRFなどのクロスオリジンでの攻撃を仕掛けようという試みは古くから存在します。現実にこれらが行われたという話は聞いたことはありませんが、理論上は可能であるという話をよく聞きます。対策としてまず検討すべきは、社内システムであっても通常のシステム同様に脆弱性を生まないようセキュアなものにするということです。それらが難しい場合には、少しの手間でローカルネットワークに対するクロスオリジンでの攻撃を低減させることができます。
フィドラでクロスオリジンからの攻撃を低減させる手順
Fiddler を起動し「Rules」メニューから「Customize Rules...」をクリックします。エディターが立ち上がってルール用のFiddlerScriptの編集画面が出てきますので、以下を追記します。
function isLocalServer(host:String):Boolean {
// TODO: 環境に合わせてここを修正して下さい
const localServers = ["server-name-1", "server-name-2"];
var re = /^([￥d]{1,3})￥.([￥d]{1,3})￥.([￥d]{1,3})￥.([￥d]{1,3})$/;
var m = re.exec(host);
var i;
// プライベートIPアドレスのホストはローカルのサーバーとみなす
if (m !== null) {
m[1] = m[1]|0;
m[2] = m[2]|0;
m[3] = m[3]|0;
m[4] = m[4]|0;
if (m[1] > 255 || m[2] > 255 || m[3] > 255 || m[4] > 255) return false;
if (m[1] === 10) return true;
if (m[1] === 172 && (m[2] >= 16 && m[2] <= 31)) return true;
if (m[1] === 192 && m[2] === 168) return true;
}
// ローカルサーバーの一覧に存在するかチェック
for (i = 0; i < localServers.length; i++) {
if (host.Equals(localServers[i]) ){
return true;
}
}
return false;
}
class Handlers
{
// 省略
static function OnBeforeRequest(oSession: Session) {
// 省略
// ターゲットがローカルサーバー
if (isLocalServer(oSession.hostname)) {
var from = oSession.oRequest.headers["origin"];
if (from !== "") {
from = from.replace(/^https?:￥/￥//,"");
} else {
var m = /￥/￥/([^￥/]+)￥//.exec(oSession.oRequest.headers["Referer"]);
if (m !== null) {
from = m[1].replace( /^[^@]+@/,"");
}
}
// 呼び出し元がローカルサーバーではない
if (!isLocalServer(from)) {
FiddlerApplication.Log.LogFormat("Blocked {0} from {1}", oSession.fullUrl, from);
oSession.utilCreateResponseAndBypassServer();
oSession.oResponse.headers.Add("Content-Type", "text/plain");
oSession.oResponse.headers.HTTPResponseCode = 404 ;
oSession.oResponse.headers.HTTPResponseStatus = "404 Not Found";
}
}
}
}
たったこれだけで、外部のわなサイトを経由したクロスオリジンの攻撃からローカルシステムをある程度守れます。
まとめ
やっていることは、通常は社外の公開サーバーをRefererやOriginとして社内に対してリクエストが発行されることはないので、それを検知した場合に404応答を返しているだけです。ただし、もちろんのことながら、ReferrerやOriginがつかない状況も頻繁に発生するので、そういった場合にはこの方法では攻撃を防ぐことはできません。繰り返しになりますが、社内システムであっても社外のシステム同様にきちんと脆弱性への根本的な対策を行っておくべきでしょう。
ツイートする
コメント
2017-11-06
■[SECURITY][Event] サイボウズ バグハンター合宿に行ってきた
先週の11月3日-4日に開催されたサイボウズ バグハンター合宿に参加してきた。
サイボウズ バグハンター合宿 - connpass
3年前は個人戦だったけれど今回はチーム戦ということに加え、クソつまらない脆弱性を多数報告した場合は評価が下がる採点方式だったので、最初はチームの足を引っ張らないようホームラン級のバグを探そうとしたけれど、最近すっかり技術的なことをやっていないのでなかなかそういうバグも見つけることができず、ゼロよりマシだろうということで結局わりとくだらないバグをいくつか報告した次第。とはいえ、他の人はあまりやらないだろうなという「クロスオリジンでの情報漏えい」みたいな自分としては好きなタイプのバグをひとつ見つけて報告することができたので、その点は満足。結果的にチーム順位は最下位、個人順位ではかろうじて10位に入るという感じでした(下から数えた方が早い)。Masato Kinugawaさん強すぎ。
いろんな攻撃手法に関して、以前なら自分の技として適切な場面でそれを取り出して使えることが多かったけれど、だんだんと手を動かす時間が減るにつれ他の人の攻撃例を見て「ああ、そうか。そこでその攻撃手法が使えたんだ！」みたいな感覚になっていってたんだけど、さらに今回は「なにそれ。そんな攻撃方法あったのか」みたいに全く知らない技がいくつもあったりして、すっかり時代においていかれた感を味わってきた。
実際にサイトを検証するのは、CTFと違って「問題のための問題」みたいなのではなく、実際に生きて動いてるWebサイトなのでどれだけ不合理で不自然なかたちであっても脆弱性が存在すればそれは現実のものなわけだし、あるいは特定の挙動についてあるサービスではサービスの提供方針として脆弱性として認定されるものが他のサービスでは脆弱性とは認定されないというような運用指針に寄るものがあったり、そういう点でリアルな世界なので学びも大きいし超楽しかった。
次回が開催されるのかはわからないけれど、もし開催されるのであれば次は事前にちゃんと予習復習をして、もうちょっと人権をちゃんと確保したい。
ツイートする
コメント
2017-04-24
■ [SECURITY] podcast 第1回 セキュリティの『アレ』
@ntsujiさん、@MasafumiNegishiさん、mtakeshiさんのポッドキャスト「セキュリティの『アレ』」の収録にお邪魔してきました！
第1回 動画のアレからポッドキャストのアレに帰ってきたよ！スペシャル « podcast - セキュリティの『アレ』
http://tsujileaks.com/media/are_170423.mp3
人に聞かせるために話すっていうよりは、辻さん根岸さんに解説してもらいながら3人との会話を自分自身が楽しむみたいな感じでした。ゆるゆるグデグデな感じですけどよろしくお願いします！
ツイートする
コメント
2016-12-16
■[SECURITY] 安全な脆弱性の作り方
この記事は 「脆弱性"&’<<>￥ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。
受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいく
URL変更のお知らせ
このページのURLを変更しました。お気に入り・ブックマーク・更新アンテナ等へ登録されている方は登録の変更をお願い致します。
del.icio.us・はてなブックマーク等のソーシャルブックマーク経由、日記・プログ・個人ニュースサイト等の紹介記事から訪れた方で、もし、リンク切れ状態であるなら ニュース過去ログ & ネタ・まとめ系特集記事、雑学・考察系リンク集 を参照してください。
2010-02-02
atword.jp
このドメインを購入
ドメイン atword.jp は 299 USDで売り出し中です!
検索検索
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ナビゲーションを切り替え
投稿日: 5月 17, 2016 投稿者: admin
カテゴリー: Money
投稿日: 5月 1, 20165月 17, 2016 投稿者: admin
カテゴリー: Money
投稿日: 4月 24, 20165月 24, 2016 投稿者: admin
カテゴリー: Uncategorized
2016.02.15
当サイト「やまもといちろうブログ」は、LINEブログにお引越しをしました
すでにご案内のとおり、ここニフティ「ココログ」で長らく運営しておりました「やまもといちろうブログ」は、知らない間にスマホ向けブログページに無断で広告が貼られていて私には広告収入の分配がなかったという理由でLINEブログに移籍することになりました。
やまもといちろうブログ（LINEブログ）
http://lineblog.me/yamamotoichiro/
もっとも、いままで無料で長く続けさせていただいていたということや、ココログ立ち上げの経緯も考えますと、感情的には断腸の思いもあるわけですけれども、そこは是々非々での判断ということで…。スタッフの皆様にも長らくお世話になりましたので、改めて、ここで深く御礼申し上げたいと存じます。
» Continue reading
2016.02.15 | Permalink
Tweet
«今日は『こころに効く本読みガイド』＆フジテレビ系『真夜中のニャーゴ』
当サイト「やまもといちろうブログ」は、LINEブログにお引越しをしました
このブログへのアクセスは現在停止しています。
ぐるなびHOME | お店のブログ
Android Extra Field Vulnerability Spotted in the Wild
It has been 20 days since the Extra Field vulnerability (also known as Chinese Master Keys) ...
Posted by dgoddard on Jul 30, 2013
ladysmokerの日記 [全5905件]
2012.10.18
未だ蔓延る放射脳
[ セキュリティ雑記 ]
人にはそれぞれの動かしがたい価値観や基準などがあり、だからこそお互いの差異を知った上での距離感や信頼感がないまぜになった上での人付き合いになる。
ある人には許容出来るものが別の人には容認しがたいというのはこれで、全部頭の上に書いてあるわけではない上に新しい事態に直面して初めて判断するということもある。
この判断は無論正しかったり間違っていたりするわけで、その繰り返しでほんの僅かずつ経験値にもなるんだが経験値といってもそれが正負両方なのも当然ある。
最初に書いた「動かしがたい」も実はその瞬間瞬間、時には相手にもよるし事態にもよるのというのが良くも悪くも人間らしいということかもしれない。
しかし例えば科学技術とか軍事という分野は「怖い怖いいやいや」で済むかというと「好ましくはないが容認せざるを得ない」脳内の感情を自分で宥める事も時には必要になる。
自分にとって好ましいものだけで社会は成立運用されていず国家となると尚更で、1億3千万弱がこの水準の生活を維持するには多大な「個人的には好ましくないもの」も存在する。
昨日Twitterでひとしきり騒ぎがあった。
【驚異の】「放射能はウイルスやアレルゲンに変異する（キリッ」【新説】
一見おちゃらけたような題名だが、こうでも書かないとこの1年半営々と放射脳を説得しまた傍から見るものにも充分納得できるだけの意見を発信し続けたにも関わらず未だこういう認識なのかという無念や脱力感のみに押し流されてしまうのは私にはよく判る。
やってきた者だけがこの題名を付けられるというのなら纏めた方も当然こうした題名をつけていいと思ってもいる。
この騒ぎの大元といっていい放射脳と言われる脳内アレルギーは発災から1年半を過ぎこれだけ情報が数字としてまた何よりもその地にいる方々が自ら証を立てていることから目を背け続けている。
どんなデマを飛ばしても自分達の気分がそれで休まるのならいいという極めて病的な衝動と理由だけでこの1年半彼らはやってきたわけだが、それらが時間が立ちまた数字や経緯経過によってデマの根拠さえも覆され始めるとこの纏めの最初の発言者のようにどこから突っ込んでいいか判らないほどの錯乱を示す。
もうひとつ言うのなら「勝手に移り住んで勝手に脳内アレルギーになる」自体は勝手だがまとめコメントにもあるようにそれを正当化しようとするとこのような事態に陥る。
日本ではどこに住もうとそれは自由で移った以上はその先で楽しく生活すりゃいいものを勝手に移住したのまで人のせい何かのせい、果ては金寄越せは通らない。
また私もじかに病院で見たが癌患者へのインチキ健康食品、なんちゃらキノコの押し売りと同じで、元々ある程度信用のあったもの(EM菌)を勝手に放射能に効く的なデマを飛ばして高価に売りつけるなどの被害も発生している。
もう一度言うがゼロベクレルはこの宇宙にも地球上にも存在しない。
目指すのは無駄だ。
この当たり前の事実くらいはせめて理解しろと思うけれどね。
mixiチェック
最終更新日 2012.10.18 09:03:51
コメント(0) | コメントを書く
■[資][Ubuntu] 日本語ディレクトリ名を英語名に変換
■[資][Ubuntu] 標準ディレクトリの設定
Copyright © 1995 - 2010 Pangeia Informática LTDA. Todos os direitos reservados.
Powered by Ruby version 1.8.7-p352
2011年5月12日
■ 「優しく, 美しく, 気高い数学書」 2011年5月12日 08:13
数学書房さんから出版される『この数学書がおもしろい 増補新版』という書籍に文章を書きましたのでアナウンスします。
この本は「約50名の執筆者が数学書について自由に書く」というもので、 数学に興味を持っている方なら、どなたにも参考になると思います。 編集部によれば、出版は近日中ということですが、正確な日付はまだわからないそうです。
各執筆者は一人およそ4ページずつ書きます。 結城は「優しく, 美しく, 気高い数学書」というタイトルで書きました（このタイトル…なにこれすごい）。
以上、簡単ですがご紹介でした。よろしくお願いします。
『この数学書がおもしろい 増補新版』
数学書房編集部編
ISBN 978-4-903342-64-1
数学書房（5/12現在、まだ本書の情報はないようです）
feedback | top
<前の日
ツイートする
旧Blog（ここ）について
質問の答えを書く
諸所の事情で
http://blog.moooi.jp/
こちらにて更新を再開しています。
[ツッコミを入れる]
2009-05
2009年1月13日
Xplico
だそうです。
トラフィックから色々なものを抽出して、アーカイブできるようですね。
閲覧したWebサイトやFTPアクセス、メールなどなど。
IRCやMSNなどのチャットプロトコルにも対応予定のようです。
今後に期待といった感じですかね。
公式サイト
2009年1月 (2)
鵜飼氏は，WinnyやMicrosoft製品，組込み機器などのセキュリティ・ホールを多数発見していることで知られるセキュリティの専門家。2003年から2007年7月まで米国に在住し，米eEye Digital SecurityのSenior Software Engineerを務める。2007年7月に帰国しフォティーンフォティ技術研究所を設立，取締役副社長最高技術責任者に就任。米国から執筆していたITpro Watcher「Security from USA」は，帰国にともない「Security from KAGURAZAKA」に改題した。
過去記事
>> 一覧
ethereal 日本語化 (325)
総務省地方公共団体コード一覧表
総務省: 地方公共団体における情報セキュリティポリシー（情報セキュリティ対策に関する基本方針）等の策定状況
Yahoo! - 06/02/08 09:43:35
ethereal 日本語化
Google - 06/02/08 09:43:22