|
|
|
|
|
||
|
||
■ 2026.04.20
》 米海軍、イラン船籍貨物船 TOUSKA を拿捕
TOUSKA -
Container ShipIMO: 9328900 (marinetraffic.com)
米軍がイランの大型貨物船を拿捕 機関室を数回攻撃して航行を停止 トランプ大統領が発表 イラン港湾への船の出入りの封鎖措置で (TBS, 4/20)
米軍が海上封鎖下で初のイラン船拿捕、停戦期限控え協議開催に暗雲 (ブルームバーグ, 4/19)
ホルムズ海峡の通航止まる、船舶への銃撃やイランの警告で緊張激化 (ブルームバーグ, 4/20)
NY原油再び上昇 ホルムズ海峡緊張高まり原油輸送不安が再拡大 (TBS, 4/20)
イラン大統領「威圧的な発言は不信感を高めるだけ」 パキスタン首相との電話会談でアメリカによる海上封鎖を強く批判 (TBS, 4/20)
関連:
パキスタン船籍のタンカー「SHALAMAR」が示した，ホルムズ海峡の新局面 (渡邉英徳研究室 / note, 4/17)
この事象は，単に「1隻のタンカーが通った」という以上の意味を持っています。現時点で確認できる限り，この船は，これまで私が述べてきたイラン側・アメリカ側双方の航行秩序を，ともに満たして通過した最初の明瞭な事例とみられるからです。
ホルムズ海峡の束の間の「開放」と「再封鎖」，その後の状況 (渡邉英徳研究室 / note, 4/20)
》 6GHz帯Wi-Fi、「屋外高出力」SPモードが解禁へ ユースケース拡大に前進 (Business Network, 4/17)。 情報通信審議会 情報通信技術分科会 陸上無線通信委員会（第99回） (総務省, 4/17) での議論だそうで。
作業班の主査を務める南山大学 特任研究員・茨城大学 名誉教授の梅比良正弘氏は、SPモードを新たに導入し、その利用周波数を、すでにLPIモードおよびVLPモードで使用されている5925～6425MHz（6GHz低域帯）に加え、6570～6870MHz（6GHz高域帯）とすることが適当だと、報告書案の骨子を説明した。
ただし SP モード導入にあたっては、仰角制限と AFC システム対応が必要になると。 陸上無線通信委員会報告書概要案
6GHz帯無線LANの周波数拡張等に係る技術的条件
5GHz帯無線LANのDFS高度化に係る技術的条件 (総務省, 4/17)
AFCシステムは、既存無線システム（固定局及び電波天文）への干渉保護や周波数共用を実現するため、 6GHz帯SPモード
無線LANの使用する周波数及び送信電力を場所に応じてコントロールする周波数管理システムである。
①既存システム情報（固定局＋電波天文）を取得し、②SPモードデバイスから位置情報の提供を受け、③位置情報に応じた利用可能周波数チャネルリストと共に送信電力をSPモードデバイスに提供することになる。
等価等方輻射電力（e.i.r.p.）：
SPアクセスポイント及び固定クライアントデバイスは4W以下、SPクライアントは1W以下
屋外設置されるSPアクセスポイントおよび固定クライアントデバイスは、水平面に対して仰角30度を超えるところで測定されるe.i.r.p.の最大が21 dBm（125 mW）を超えないこと。
あと「5GHz帯無線LANのDFS高度化に係る技術的条件」の話。
「パンクチャリング」や「オフチャネルCAC」に対応することで 5GHz 帯をより有効活用できると。
欧米においては、パンクチャリング及びオフチャネルCACは既に導入されており、我が国の検討では、欧州の規定をもとに検討を行うこととした。
(中略)
現行制度に対して、IEEE 802.11axで規定されるスペクトラムマスクを前提としたパンクチャリングを設定することで共用条件が維持され、共用可能となることを確認した。
対応 AP が揃うと、かなり便利になりそう。
最終更新日：2026/04/20
JVN#63376363:
SKYSEA Client ViewおよびSKYMEC IT Managerにおける不適切なファイルアクセス権設定の脆弱性 [2026/04/20 14:00]
JVNVU#94271449:
サイレックス・テクノロジー製SD-330ACおよびAMC Managerにおける複数の脆弱性 [2026/04/20 11:30]
55
2026-04-18
ページビューランキングTOP10（2025年12月）
ランキング
このサイトのタイトル毎に2025年12月のページビューを調べて、ランキングにしてみた。
1位 仮想マシンにCtrl+Alt+Delを送信する方法
2位 Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
3位 仮想マシンから抜ける方法
4位 certutilコマンドの非公開なオプションを表示する方法
5位 Windowsでbase64エンコード・デコードする方法
6位 wiresharkでTCP制御フラグを指定してパケットを表示する方法（Display Filter）
7位 エクスプローラの検索ボックスから「作成日時」や「更新日時」などで検索する方法
8位 Linuxでbase64エンコード・デコードする方法
9位 このブログについて
10位 tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法
このランキングはGoogle Analyticsの情報をもとに作成。
EijiYoshida 2026-04-18 01:52 読者になる
ランキング (237)
2026/04/17(金)金曜日ー。（もふもふ。）
[雑談] いろいろ。
鉄道予約や旅行でネット検索｢上位結果をクリック→詐欺だった｣被害の実態､"偽サイト"を見極めるには | ビジネス | 東洋経済オンライン
鉄道予約や旅行でネット検索｢上位結果をクリック→詐欺だった｣被害の実態､偽サイトを見極めるには
私たちが日常的に使う検索エンジン。しかし､検索上位のサイトだからといって安心してクリックしていませんか？実はその信頼を逆手に取った巧妙なネット詐欺が急増しています。大手企業や行政になりすました偽サイト
https://toyokeizai.net
NIST、ついに“脆弱性の全件分析”を断念 CVE爆増でパンク状態、方針転換：開発現場の脆弱性管理はどう変わる？ - ＠IT
NIST、ついに“脆弱性の全件分析”を断念 CVE爆増でパンク状態、方針転換
NISTは、脆弱性データベース「NVD」の運用を大きく見直す。CVEの急増により従来の“全件分析”が限界に達したためだ。今後は優先度に応じた対応へと転換する。この変更は、脆弱性管理の前提そのものを揺る
https://atmarkit.itmedia.co.jp
リモートデスクトップ接続を介したセキュリティ攻撃に注意 ～2026年4月より警告に仕様変更 - 窓の杜
リモートデスクトップ接続を介したセキュリティ攻撃に注意 ～2026年4月より警告に仕様変更／教育ダイアログと改善されたセキュリティダイアログで二重の防御
2026年4月のセキュリティパッチより、リモートデスクトップファイル（*.rdp）を開く際に新たな警告が表示されるようになっており、利用の際は注意が必要だ。
https://forest.watch.impress.co.jp
Windows「セキュアブート証明書」の期限切れ迫る、“15年ぶり更新”の影響は？：更新されない場合のリスクも - ＠IT
Windows「セキュアブート証明書」の期限切れ迫る、“15年ぶり更新”の影響は？
Microsoftは、WindowsおよびWindows Serverの「セキュアブート」で使用される証明書の更新を開始した。2011年に導入された前回の証明書が2026年6月下旬に期限切れを迎えるた
https://atmarkit.itmedia.co.jp
OpenAI、Codexに「自律型UI操作」機能など追加 PC画面の直接操作で定型業務と開発フローを高速化：AIニュースピックアップ - ITmedia エンタープライズ
OpenAI、Codexに「自律型UI操作」機能など追加 PC画面の直接操作で定型業務と開発フローを高速化
OpenAIはAIコーディング支援ツール「Codex」を大幅に刷新し、PC画面を視覚的に認識して直接操作する「自律型UI操作」など多くの機能を導入した。外部ツール連携やメモリ機能によって複雑な事務作業
https://www.itmedia.co.jp
OpenAIがAIエージェント「Codex」を大幅刷新、「PCの操作」「ブラウザで直接指示」「画像生成でUIモックアップ」など - GIGAZINE
OpenAIがAIエージェント「Codex」を大幅刷新、「PCの操作」「ブラウザで直接指示」「画像生成でUIモックアップ」など
OpenAIがコーディング支援AI「Codex」のアップデートを公開しました。PCを自動で操作可能になったり、アプリ内ブラウザを搭載してウェブページ上で直接AIに指示が出せるようになったり、画像生成が
https://gigazine.net
IPv4と完全下位互換の「IPv8」ドラフト公開。IPv6は事実上失敗 - PC Watch
IPv4と完全下位互換の「IPv8」ドラフトが投稿。IPv6の課題を克服
IETF(Internet Engineering Task Force)に対して、次世代ネットワークプロトコル「Internet Protocol Version 8(IPv8)」のドラフト版「d
https://pc.watch.impress.co.jp
資料ダウンロード: デジタルスキル標準 ver.2.0 | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
資料ダウンロード | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
情報処理推進機構（IPA）の「資料ダウンロード」に関する情報です。
https://www.ipa.go.jp
個人Webアプリの置き場所としてのRender
SoRの復権とSoIの時代の到来
IT技術 (61)
プロダクト (12)
Adobe Acrobat および Reader の脆弱性対策について(2026年4月)_2
Microsoft 製品の脆弱性対策について(2026年4月)
営業秘密のツボ 2026年4月15日 第118号
■ 2026.04.09: 晴
》 クロームブック導入を“後悔” 米国の教育現場で「日本とは真逆」の動き─教室からパソコンが消えはじめた (クーリエ・ジャポン, 4/5)。
元記事はこれか: Chromebook Remorse: Tech Backlash at Schools Extends Beyond Phones (NYTimes, 3/29)。
マクファーソン中学校 (McPherson Middle School)。
DeepL 訳を若干修正:
「Chromebookがこれほど大きな妨げになってはいけないと感じたのです」と、カンザス州の2025年度最優秀中学校校長に選ばれたエスピングさん（43）は語った。「この技術は一つのツールにはなり得ます。教育の万能薬ではありません。」
ツールとしてはなんでもできすぎるし、娯楽性が高すぎるんだよなあ。
米国の学校がGoogleの広範な教育プラットフォームに深く依存していることを考えると、生徒のChromebookを回収するという考えは型破りに思えたが、その中学校は計画を実行に移した。この変更は1月から実施された。
この学校は、あるトレンドの一環となっている。ウィチタでは、マーシャル中学校が「テクノロジーフリー」の金曜日を導入している。1月、カンザス州上院は、幼稚園から小学5年生までの生徒によるノートパソコンやタブレットの使用を禁止し、中学生の端末使用を1日の授業時間中に1時間に制限する学校用端末法案を提出した。
2026-03-25
｢鳥取県青少年健全育成条例」の「児童ポルノ」
「上乗せ」とか「付け出し」とか、行政法の説明が付くでしょう
判例との整合性については既報
https://okumuraosaka.hatenadiary.jp/entry/2025/06/02/171920
｢鳥取県青少年健全育成条例」の解説令和7年度
第10条
９ この章以下において「児童ポルノ等」とは、児童買春、児童ポルノに係る行為等の規制及び処罰並びに児童の保護等に関する法律（平成11年法律第52号）第２条第３項に規定する児童ポルノ又は同法第７条第２項に規定する電磁的記録その他の記録をいい、生成ＡＩその他の情報処理に関する技術を利用し、青少年の容貌の画像情報を加工して作成した姿態（当該青少年の容貌を忠実に描写したものであると認識できる姿態に限る。）を視覚により認識することができる方法により描写した情報を記録した電磁的記録及びその記録媒体を含む。
8 「児童ポルノ等」の定義
（1）「児童ポルノ」は、児童買春、児童ポルノに係る行為等の規制及び処罰並びに児童の保護等に関する法律（以下「児童ポルノ禁止法」という。）第2条第3項において「写真電磁的記録（略）に係る記録媒体その他の物であって（略)児童の姿態を視覚により認識することができる方法により描写したものをいう。」と定められており、データ（電磁的記録）そのものではなくデータの記録媒体などの有体物を指します。
なお、単に文字や音声で描写するだけであって児童の姿態を視覚により認識することができない小説や録音テープは該当しません。
「電磁的記録その他の記録」は、児童ポルノ禁止法第7条第2項に規定する「第二条第三項各号のいずれかに掲げる児童の姿態を視覚により認識することができる方法により描写した情報を記録した電磁的記録その他の記録」を指し、第9項は、有体物である児童ポルノとその電磁的記録をあわせて「児童ポルノ等」と定義しています。
（2）第9項は、条例が定義する「児童ポルノ等」が一定の要件を満たすいわゆる性的デイープフェイクを含むことを確認的に規定しています。
昨今のデジタル技術の著しい発展により、卒業アルバムやSNSに掲載されている実在する青少年の顔写真や顔画像データを生成AIアプリで加工し、あたかも当該青少年の実写の性的姿態であるかのような画像（＝いわゆる「性的ディープフェイク」）を作成することが容易にできてしまう実態がありますbまた、こうした性的画像が匿名性の高いSNSで共有・拡散されている事案も確認されていますb児童ポルノ禁止法は、実在する18歳未満の児童の性的自由（性的虐待及び性的搾取をされない自由）を保護しているところ、このような性的画像を作成又は第三者に提供（インターネット上への拡散を含む。）されることはまさに実在する児童の性的搾取及び人権侵害であり、こうした性的画像は実在する児童の姿態を描写したものとして児童ポルノ禁止法による処罰対象となりうるものと考えられますが、現行法の規定上､必ずしも明らかでないことから、これを明確化したものです
（3）「生成AIその他の情報処理に関する技術」とは、学習データを基に画像や映像を創造することができる人工失畦関連技術その他の情報処理システムに関する技術をいい、CG(コンピュータグラフィクス）も含みます
（4）「青少年の容貌の画像情報を加工して作成した姿態（当該青少年の容貌を忠実に描写したものであると謡哉できる姿態に限る。）」とは、実在する青少年の顔画像データ（動画データを含む。）を生成AIアプリなどにより加工して作成した性的姿態であって、通常一般人から見て当該青少年の実写の性的姿態であると見紛うようなものをいいます。
したがって、生成AIアプリを用いて作成した画像であっても､複数人の顔画像データから実在しない青少年の顔を合成して作成したようなものはこれに含まれません。
参考裁判例
令和2年1月27日最高裁判所第一小法廷決定
平成29年(あ)第242号児菫買舂,児菫ポルノに係る行為等の処罰及び児童の保護等に関する｜|法律違反被告事牛|被告人力i衣服を付けない実在する児童の姿態が撮影された写真の画像ﾃｰﾀを素材として画像編集ソフト等を使用して描写したコンピュータグラフィックス（以下「CG」という。）を作成し､このCG集をインターネットを通じて不特定又は多数の者に販売した事案について、最高裁判決は高裁判決を支持し、当該描写が児菫ポルノに該当し、児童ポルノ製造罪が成立すると判示した。
「児菫買舂児菫ホルノに係る行為等の処罰及び児菫の保護等に閏する法律（平成26年法律第7119号による改正前のもの。以下「児童ポルノ法」という。）2条1項は「児童とは18歳に満たない者をいうとしているところ，同条3項にいう「児童ポルノ」とは写真電磁的記録に係る記録媒体その他の物であって，同項各号のいずれかに掲げる実在する児菫の姿態を視覚により認識することができる方法により描写したものをいい，実在しない児童の姿態を猫写したものは含まないものと解すべきである。
※下記は補足意見
「児童ポルノ法2条3項に定める児童ポルノであるためには、視覚により認識することができる方法で描写されたものが、実在する児童の同項各号所定の姿態であれば足りる。
児童ポルノ法7条が規制する児童ポルノの製造行為は児菫の心身に有害な影響を与えるものとして処罰対象とされているものであるが、実在する児童の性的な姿態を記録化すること自体が、性的搾取であるのみならず、このように記録化されたされた性的な姿態が他人の目にさらされることによって，更なる性的搾取が生じ得ることとなる。
児菫ポルノ製造罪はこのよう性的搾取の対象とされないという利益の侵害を処罰の直接の根拠としており,上記利益は描写された児菫本人が児菫である間にだけ認められるものではなく，本人がたとえ18歳になったとしても，引き続き，同等の保護に値するものである。
児童ポルノ法は,このような利益を現実に侵害する児童ポルノの製造行為を処罰の対象とすること等を通じて，児童の権利擁護を図ろうとするものである。
平成29年1月24日東京高等裁判所第10刑事部判決
※上記事件の高裁判決
（ア）所論は，原判決が，「一般人からみて，架空の児童の姿態ではなく，実在の児童の姿態を忠実に描写したものであると認識できる場合には，実在の児童とCGで描かれた児童とが同一である（同一性を有する）と判断でき」ると説示した点をとらえて，一般人が，実在の児童の姿態を忠実に描写したと認識しさえすれば，実在しない児童の姿態を描写した場合についても処罰の対象となる趣旨であるとして，この点を種々論難する。
そもそも，原判決は，前記のとおり，児童が実在することを要するとの前提に立った上，本件CGについて，被写体となった児童が実在するか否かを，各CGの元となった素材画像の写真の出典等について検討した上で判断し，実在性が認められたものについてのみ，児童ポルノに該当すると判断したのであるから，実在しない児童の姿態を描写した場合も処罰の対象となるという判断をしたとの所論は，前提を欠くものである。
さらに，原判決が上記のように説示した趣旨は，その実際の判断過程に即してみると，素材画像の被写体となった児童の実在性が認められた場合に，当該CGの画像等が，その実在する児童を描写したといえるかどうか，すなわち，被写体となった実在の児童とそれを基に作成されたCG画像等が，同一性を有するかどうかを判断するに当たって，一般人の認識という基準を用いたものと解される。このように，通常の判断能力をもつ一般人が，社会通念に照らして実在する児童と同一であると認識できる場合には，当該描写行為等が処罰の対象となることを認識できるから，このような基準を採用したからといって，刑罰法規の明確性を害するものではない。そうすると，原判決の前記説示は，いささか表現が不明確ではあるものの，その判断に誤りはない。所論は，原判決を正解しないものであって，採用の限りでない。
（イ）所論は，「児童の姿態」とは，実在する児童が被写体となって，実際にとった姿態に限られると主張し，一般人がどう認識しようが，実在しない児童の姿態を処罰の対象とすることは法の趣旨を逸脱するものであると主張する。
しかし，必ずしも，被写体となった児童と全く同一の姿態，ポーズをとらなくても，当該児童を描写したといえる程度に，被写体とそれを基に描いた画像等が同一であると認められる場合には，その児童の権利侵害が生じ得るのであるから，処罰の対象とすることは，何ら法の趣旨に反するものではないというべきである（児童ポルノ法の趣旨については，後に検討する。）。
なお，この点に関して，所論は，当審で取り調べたB氏の意見書を引用し，写真を参考にした絵画表現は，機械による複写とは異なり，独立した新たな創作物であるから，手描きの作品を機械による複製と同視することは，罪刑法定主義に反するとも主張する。
そもそも，被告人の本件CGの作成方法については，原判決が認定するとおり，一から手描きで描いたものではなく，パソコンのソフトを利用して素材画像をなぞるなどして作成されたものであると認められ，純粋な手描きによる絵画とは異なるものであるが，この点を措くとしても，一般に，写真による複写の場合であっても，現在の技術を前提とすれば，データを容易に加工することが可能であり，他方，手描きによる場合であっても，被写体を忠実に描写することも可能であることからすれば，必ずしも，描写の方法いかんによって児童ポルノの製造に当たるか否かを区別する合理的な理由はないというべきである。描写の方法がいかなるものであれ，上記のとおり，実在する児童を描写したといえる程度に同一性の認められる画像や絵画が製造された場合には，その児童の権利侵害が生じ得るのであるから，そのような行為が児童ポルノ法による処罰対象となることは，同法の趣旨に照らしても明らかである。ちなみに，児童ポルノに絵画が含まれ得ることは，児童ポルノ法の立法段階においても前提とされていたことである。
罰則
（児童ポルノ等の作成、製造及び提供の禁止）
第18条の３ 何人も、児童ポルノ等の作成又は製造（県内に居住し、又は県内に通学若しくは通勤する青少年の容貌の画像情報を加工して作成した姿態に係る児童ポルノ等について本県の区域外で行われる作成又は製造を含む。）をしてはならない。
２ 何人も、ＳＮＳの利用その他の手段により児童ポルノ等の提供（県内に居住し、又は県内に通学若しくは通勤する青少年の容貌の画像情報を加工して作成した姿態に係る児童ポルノ等について本県の区域外で行われる提供を含む。）をしてはならない。
３ 知事は、前２項の規定に違反した者に対して、期限を定めて、当該児童ポルノ等の廃棄、削除その他の必要な措置をとるべきことを命ずることができる。
４ 知事は、前項の規定による命令を受けた者が当該命令に従わないときは、その者の氏名若しくは名称又はこれらに代わる呼称及び当該命令の内容を公表することができる。この場合、当該公表による青少年の心身への影響に十分配慮するものとする。
【関係条文】
第28条第18条の3
第1項又は第2項の規定に違反したときは、当該違反行為をした者は、5万円以下の過料に処する。
2 第18条の3第3項の規定による命令を受けた者が当該命令に従わないときは、5万円以下の過料に処する。
【要旨】
本条は、すべての者に対して、児童ポルノ等の作成、製造、提供を禁止する規定です。
【解説】
1 第1項は、児童ポルノ禁止法第7条第3項から第5項まで及び第7項が定める児童ポルノの製造禁止について条例において確認的に規定しているとともに、同法第7条第2項に規定する電磁的記録その他の記録の作成を禁止しています。
本項は、県内青少年の児童ポルノ等を県外で作成・製造する行為も明示的に禁止しており、条例の効力が一般的に属地主義であることの例外となります｡また、本項により禁止される児童ポルノ等の作成又は製造については、目的は問いません。したがって、いじめ目的で青少年の児童ポルノ等を作成・製造した場合も含まれます。
2 第2項は、児童ポルノ禁止法第7項第2項及び第6項が定める児童ポルノ及びその電磁的記録の提供禁止について条例において確認的に規定するものです。本項は、県内青少年の児童ポルノ等を県内から県外へ提供すること、県外から県内へ提供すること、県外から県外へ提供することのいずれも明示的に禁止しており、条例の効力が一般的に属地主義であることの例外となります
また、本項は、児童ポルノ禁止法と同様、目的を問わず全ての提供を禁止しています。
3 「何人も」とは、第15条の解釈と同じく、県民はもとより旅行者、滞在者などの全ての自然人を指し、国籍性別、年齢を問いません。
4 「児童ポルノ等」とは、第10条第9項に規定する児童ポルノ等をいい、いわゆる全身の実写画像のみならず、生成AIその他の情報処理に関する技術を利用し、青少年の容貌の画像情報を加工して作成した姿態（当該青少年の容貌を忠実に描写したものであると認識できる姿態に限る。）を視覚により認識することができる方法により描写した情報を記録した電磁的記録及びその記録媒体を含みます。
5 第3項は、児童ポルノ等の作成・製造・提供の禁止に違反した者に対して知事が命令を行うことができる旨の規定であり、例えば、違反者から当該児童ポルノ等の提供を受けた第三者に対して当該児童ポルノ等の削除を命ずることはできません。また、「必要な措置」としては、例えば、違反者自身が当該児童ポルノ等を提供した第三者に対して当該児童ポルノ等の廃棄を依頼することや、違反者自身がインターネット上に拡散された当該児童ポルノ等の投稿削除依頼をプラットフォーム事業者に対して行うことなどが想定されます。
なお、インターネット上に掲載された児童ポルノ等については、本項による対応とは別途被害者が、特定電気通信による情報の流通によって発生する権禾|脹害等への対処に関する法律に基づく発信者情報の開示請求を行うことや、プラットフォーム事業者に画像の削除依頼を行うことも可能です。
6 第4項は、第3項の規定に基づく命令を受けた者が当該命令に従わない場合に当該者の氏名（法人の場合はその名称）又はこれに代わる呼称を命令の内容とともに公表できる旨を定めています
「これらに代わる呼称」とは、例えば、通称やSNSのアカウント名などを想定しています。
本項に規定する公表は、違反者に対する制裁的意味合いも有するものの、県民への注意喚起や抑止力としての意味合いも持っており、罰則として位置付けられてはいません。公表を行うか否かは、行為の悪質性の程度（商業目的であるか否力等）や公表により被害者及び違反者に及ぼす影響の程度、県民への注意喚起の必要性等を総合的に勘案して決定します。例えば、違反者が被害者と知人である青少年であった場合、違反行為の態様によっては、違反者の氏名を公表することが被害者及び違反者のその後の心身の健全な成長の妨げとなるおそれがある場合も想定されるところ、こうした場合には、公表を行わないか、氏名は非公表として命令内容のみを公表することが考えられます
7 第1項又は第2項の規定に違反して児童ポルノ等を作成・製造・提供した者は、5万円以下
の過料に処すこととされています（条例第28条第1項）。また、第3項の規定による命令を受けた者が当該命令に従わないときは、5万円以下の過料に処することとされています（第28条第2項）。これらの過料は刑罰ではなく行政処分（秩序罰）であり、各規定に基づき過料を課すか否か及びその金額については知事に裁量があり、行為の悪質性等を踏まえ総合的に判断します。なお、第3項の規定による命令を受けた者が当該命令に従わない場合、公表及び過料の対象となり得ますが、これらの適用は連動するものではなく、それぞれ個別に判断されます。
第28条
1 第18条の3第1項又は第2項の規定に違反したときは、当該違反行為をした者は、5万円以下の過料に処する。
2 第18条の3第3項の規定による命令を受けた者が当該命令に従わないときは、5万円以下の過料に処する。
【要旨】
本条は、禁止規定の実効性を確保するため、これらの規定に違反した者に対して一定の過料（行政上の秩序罰）を科す旨を規定したものです。
【解説】
1 本条は、児童ポルノ等の作成、製造及び提供の禁止規定に違反した者並びに児童ポルノ等の廃棄、削除その他の必要な措置をとるべきことの知事命令に違反した者に対し、それぞれ5万円以下の過料を処すことを規定しています。
2 「過料」は金銭罰の一種ですが、罰金や科料のような刑罰ではありません。本条例の過料の性質は、行政上の秩序罰としての過料であり、条例上の義務に違反した者に対し制裁として科せられるものです。
okumuraosaka 2026-03-25 20:15 読者になる
最終更新: 2026-03-25 20:15
｢鳥取県青少年健全育成条例」の「児童ポルノ」
2026 / 3
最終更新: 2026-03-25 20:15
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.
2025-10-12
sora2および動画生成
sora2で10秒動画制作を続けている。30本制限になったけど、テイク数を少なくしつつ量産する感じに持ってきたので、毎日それなりの数を生産できている。
動画としての完成度を上げることはかなりできるようになってきたけど、問題はセリフかなぁ。
元のスクリプトを標準語の会話文として書いて、AIに関西弁をお任せするとイマイチ想定通りいかないことがある。細かく指定すると棒読みになる可能性が結構高い。どちらかと言えば前者の方が自然になる確率が高い。
その一方で、人物の動作とか背景とかは情報を適切に与えるとそれに答えてくれる。ただし漢字は別（笑）。セリフのときもそうだけど、日本語の読みが不自然になることがたまにある。例えば「特定班」のことを「とくていばん」と言うので「特定はん」と書いても「とくていばん」と言ってしまうとか。「怖いよね」というのを「ふいよね」と読んだりもする。ひらがなで指定してても間違えることもある。
そんな試行錯誤の中で、最も情報量が多く、かつ自然になるのは、関西弁の若い女性、というのが見えて来たので（笑）、最近の動画はもっぱらそのパターン。しかし、若い女性、とだけ指定していると服装がパターン化してきてしまうのと、若干の不自然さも出てきてしまうので、正直全く関心が無かった（笑）ファッションをいろいろ勉強しつつ、そのあたりも指定し始めている。使い方を見極めながらやっているので、どうしても同じような装いが続いてしまう（笑）。
本数たまってきたらどっかで連続的に公開していこうかなぁ。なおテーマは情報セキュリティの啓蒙啓発。なので情報量が命なんだよね（笑）。
さすがに長尺ものも欲しいので、他のプラットフォームも試してみようと思うものの、日本語対応がどうなの？というところがあるので、まだ試行中、というところ。
sonodam 2025-10-12 20:16 読者になる
もっと読む
コメントを書く
sora2および動画生成
2025 / 10
この広告は、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 島根県松江市における大規模火災にかかる災害救助法の適用について
はてなブログ アカデミー
法人プラン
意外かもしれないが、初デスクトップ。今回はサイコムというところで注文した。自作という選択肢もあったが、自分の不器用さをよく承知しているので(最近では液漏れで止まった時計を修理しようと分解して、再起不能にした)、BTOに。スペックは、
それに比較対象がThinkPad T460s (Core i7 6600U) 2 core 4 threadだからねえ
追記
サイコムから返事来た。送料着払いでボード２枚を返却したら、ボードぶんの代金を返金するとのこと。やさしい。
高田馬場
杉並区
瑞穂町
目白
飯田橋
西東京市
中野区
豊島区
八丈町
〓
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