  |
はてなキーワード: オブジェクトとは
数学的宇宙仮説を説明するには、宇宙をどのようにモデル化するかを考え、各理論の役割を明確にする必要がある。
以下に、各概念を説明し、物理宇宙を数学的にどのように捉えるかを示す。
数学的宇宙仮説の中心にあるのは、宇宙が数学的構造そのものであるという考え方である。数学的構造は、集合とその上で定義される関係や演算の組み合わせである。
具体例として、微分多様体を考える。微分多様体は、局所的にユークリッド空間に似た構造を持ち、滑らかな関数が定義できる空間である。物理学では、時空を微分多様体としてモデル化し、一般相対性理論の基盤としている。このように、宇宙全体を一つの巨大な数学的構造として捉え、その性質を研究する。
集合論は、数学の基礎を形成する理論であり、すべての数学的対象を集合として扱う。特に、Zermelo-Fraenkel集合論（ZFC）は、集合の存在とその性質を定義する公理系である。数学的宇宙仮説では、宇宙を集合として捉え、その集合上の関係や演算が物理法則を表現していると考える。
モデル理論は、形式的な論理体系が具体的な構造としてどのように実現されるかを研究する。数学的宇宙仮説では、物理宇宙がある論理体系のモデルであると仮定する。具体的には、物理法則を公理とする論理体系のモデルとして宇宙を捉える。これは、ペアノ算術の公理系のモデルとして自然数が存在するのと類似している。
カテゴリ理論は、対象（オブジェクト）とそれらの間の射（モルフィズム）を扱う理論である。カテゴリ 𝒞 は次のように定義される：
射は合成可能であり、合成は結合的である。さらに、各対象に対して恒等射が存在する。
数学的宇宙仮説では、宇宙を一つのカテゴリとして捉えることができる。カテゴリの対象は異なる数学的構造であり、射はそれらの間の変換や関係を表す。これにより、異なる「宇宙」間の関係性を数学的に探求することが可能になる。
トポス理論は、集合論の一般化であり、論理と空間の概念を統一する枠組みである。トポスは、論理体系のモデルとして機能し、異なる数学的構造を統一的に扱うことができる。
数学的宇宙仮説では、宇宙をトポスとして捉えることができる。トポスは、論理体系のモデルであり、異なる物理的現実を表現するための柔軟な枠組みを提供する。トポス理論を用いることで、宇宙の数学的性質をより深く理解することが可能になる。
数学的宇宙仮説を抽象数学で説明するためには、数学的構造、公理系、集合論、モデル理論、カテゴリ理論、トポス理論といった数学的概念を用いることが必要である。
これにより、物理的現実を数学的に厳密に記述し、数学と物理の深い関係を探求することができる。
この仮説は、数学的対象が物理的実体として存在するという新しい視点を提供するが、現時点では哲学的な命題としての性格が強く、数学的に証明可能な定理ではない。
ロックに条件持たせる
やりたいことはできてるように見えるが、うーんしんどい
# Entity Relation Diagram
# ```mermaid
# ---
# title: Rental Office example
# ---
# erDiagram
# OFFICE ||--|{ ROOM : x
# OFFICE {
# number office_id
# }
# ROOM {
# number office_id
# number room_id
# }
# ROOM ||--|{ SCHEDULE : x
# SCHEDULE {
# number room_id
# datetime start_at
# datetime end_at
# }
# OFFICE ||--|{ BUSINESS_HOUR : x
# BUSINESS_HOUR {
# number office_id
# enum week_of_day
# datetime start_at
# datetime end_at
# }
# ```
# Directed Acyclic Graph
#
# ```mermaid
# graph LR
# A[OFFICE] --> B[ROOM]
# B --> C[SCHEDULE]
# A[OFFICE] --> D[BUSINESS_HOUR]
# D --> C
# A --> C
# ```
# 基底クラス: EntityLock
class EntityLock
attr_accessor :entity_name, :entity_locked, :attribute_locks
def initialize(entity_name)
@entity_name = entity_name
@entity_locked = false # エンティティ全体のロック状態を保持
@attribute_locks = {} # IDに対するロックを管理するハッシュ
end
def lock_entity
@entity_locked = true
puts "Entity '#{@entity_name}' is now locked."
end
def unlock_entity
@entity_locked = false
puts "Entity '#{@entity_name}' is now unlocked."
end
def lock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && !@attribute_locks[entity_id]
@attribute_locks[entity_id] = true
puts "#{@entity_name} with ID '#{entity_id}' is now locked."
end
end
def unlock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
@attribute_locks.delete(entity_id)
puts "#{@entity_name} with ID '#{entity_id}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定のIDがロックされているかチェック
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
return true
end
# ロックされていなければfalseを返す
false
end
end
# 子クラス: OfficeLock, RoomLock, ScheduleLock
class OfficeLock < EntityLock
def initialize
super("Office")
end
end
class RoomLock < EntityLock
def initialize
super("Room")
end
end
class ScheduleLock < EntityLock
def initialize
super("Schedule")
end
end
# 子クラス: BusinessHourLock
class BusinessHourLock < EntityLock
def initialize
super("BusinessHour")
@attribute_locks = [] # BusinessHour用のロックを配列で管理
end
def lock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks << [start_at, end_at]
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now locked."
end
end
def unlock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if @attribute_locks.include?([start_at, end_at])
@attribute_locks.delete([start_at, end_at])
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定の時間範囲がロックされているかチェック
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks.each do |(locked_start, locked_end)|
if locked_start <= start_at && end_at <= locked_end
return true
end
end
end
# ロックされていなければfalseを返す
false
end
end
# TreeNodeクラス
class TreeNode
attr_accessor :name, :children, :parents, :lock
def initialize(name, lock)
@name = name
@children = []
@parents = [] # 複数の親ノードを保持する配列
@lock = lock # TreeNodeにロックを持たせる
end
def add_child(child_node)
child_node.parents << self # 子ノードにこのノードを親として追加
@children << child_node
end
def display(level = 0)
indent = " " * (level * 4)
puts "#{indent}#{@name}"
@children.each { |child| child.display(level + 1) }
end
def has_dependency
return false if @parents.empty?
@parents.each do |parent|
puts "#{@name} is dependent on #{parent.name}"
return true
end
@parents.any?(&:has_dependency)
end
def locked?(attributes = {})
# 自身がロックされているか確認
return true if @lock.locked?(attributes)
# 親ノードがロックされているか再帰的に確認
@parents.any? { |parent| parent.locked?(attributes) }
end
end
# 木構造の組み立て
# ロックオブジェクトの作成
office_lock = OfficeLock.new
room_lock = RoomLock.new
schedule_lock = ScheduleLock.new
business_hour_lock = BusinessHourLock.new
# ノードの作成
office_node = TreeNode.new("Office", office_lock)
room_node = TreeNode.new("Room", room_lock)
schedule_node = TreeNode.new("Schedule", schedule_lock)
business_hour_node = TreeNode.new("BusinessHour", business_hour_lock)
# ノード間の依存関係の設定
office_node.add_child(room_node) # Office -> Room
room_node.add_child(schedule_node) # Room -> Schedule
office_node.add_child(business_hour_node) # Office -> BusinessHour
business_hour_node.add_child(schedule_node) # BusinessHour -> Schedule
# 木構造の表示
office_node.display
# ロックの確認
puts "Case 1. Office全体がロックされた場合"
puts "Is office_node locked? #{office_node.locked?({})}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # false
office_lock.lock_entity
puts "Is office_node locked? #{office_node.locked?({})}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # true
office_lock.unlock_entity
puts "Case 2. Room id:1 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.lock({ "room_id" => 1 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.unlock({ "room_id" => 1 })
puts "Case 3. BusinessHour start_at:0 end_at:5 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.lock({ "start_at" => 0, "end_at" => 5 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.unlock({ "start_at" => 0, "end_at" => 5 })
FANZAの検索結果から熟女を除外するブックマークレット がうまく動いたので、気を良くしてはてなブックマークのコメント欄をスター数順にソートするブックマークレットを作りました。
作った動機は、「注目コメントに入りきれなかったちょっといいコメント」をサクサク探したいから。結果として建設的コメント順位付けモデルを無効化していますが、あのアルゴリズムには特に不満は特にありません。
javascript: (async () => {
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);
window.scrollTo(0, 0);
await wait(1000);
const p = document.querySelector('.js-bookmarks-recent');
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
l = l.filter(e => g(e) > 0);
l.sort((a, b) => g(b) - g(a));
p.replaceChildren(...l);
})();
ミニファイしたもの ※コードに一部誤りがありましたので訂正しました（2024-08-16 11:47）
javascript:(async()=>{const wait=ms=>new Promise(resolve=>setTimeout(resolve,ms));document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();window.scrollTo(0,document.body.scrollHeight);await wait(1000);window.scrollTo(0,0);await wait(1000);const p=document.querySelector('.js-bookmarks-recent');let l=Array.from(p.querySelectorAll('.entry-comment-contents'));const g=e=>{let n=e.querySelectorAll('.hatena-star-star').length;const c=e.querySelector('.hatena-star-inner-count');return c?n+Number(c.textContent):n};l=l.filter(e=>g(e)>0);l.sort((a,b)=>g(b)-g(a));p.replaceChildren(...l)})()
FANZAの検索結果から熟女を除外するブックマークレット 参照
javascript:
ブックマークレットに必要な、URLの種類を示すスキーム名です。
(async () => {
// 処理
})();ページに元々ある変数たちとバッティングしないように、まず無名関数でラップします。処理の中で await を使いたいので async 宣言しています。
const wait = ms => new Promise(resolve => setTimeout(resolve, ms));
document.querySelector('.js-bookmarks-sort-tab[data-sort="recent"]').click();
window.scrollTo(0, document.body.scrollHeight);
await wait(1000);「新着コメント」タブをクリックし、ページの一番下までスクロールダウンしてから少し待つ動作です。新着コメントの後半部分（スクロールきっかけの遅延読み込みになっているところ）の読み込みをうながしています。
window.scrollTo(0, 0);
await wait(1000);
ページの先頭に戻ってまた少し待ちます。合計2秒の待ち時間は雰囲気で決めていますので、これでなければならない・これで過不足ないという値ではありません。単にコメントの読み込み完了を判定する処理を書くのがめんどうだっただけです。
const p = document.querySelector('.js-bookmarks-recent');
新着ブコメの親要素です。繰り返し呼び出すので名前をつけています。
let l = Array.from(p.querySelectorAll('.entry-comment-contents'));
const g = e => {
let n = e.querySelectorAll('.hatena-star-star').length;
const c = e.querySelector('.hatena-star-inner-count');
return c ? n + Number(c.textContent) : n
};
コメントのはてなスター数をカウントして返す関数です。たくさんスターがついてる ★256★ みたいなやつの数字も足します。
l = l.filter(e => g(e) > 0);
ソートする前に、無スターのコメントを消去しています。してもしなくてもいいことですが。
l.sort((a, b) => g(b) - g(a));
残ったコメントをスター数で降順ソートします。.querySelectorAll() で収集した要素を配列に入れ直したのは、この .sort() メソッドを使いたいからです（.querySelectorAll() が返す配列風の NodeList オブジェクトは、配列と共通のメソッドもいくつかあるものの、大半は使えないのです）。
p.replaceChildren(...l);
親要素の内容を、並び替えの終わったコメントでそっくり入れ替えて、処理完了です。画面を見ると新着コメントの中身が「スターのついたコメントのみ・スターの多い順」に並んでいます。元に戻す方法はないので、原状回復にはリロードします。ソート状態を示すフラグを立てておいてスター数ソート⇔日付ソートをかわりばんこに行うようにすればできそうだなと思ったけど実装はしません。連打スターを省く処理を追加してＵＵ数でソートできればもっと厳正なランキングになるなーと今思いつきましたがそれも実装はしません。
以下に、ドゥボールの「スペクタクルな社会」とアートの役割に関する主張を詳しく説明します。
ドゥボールの「スペクタクルな社会」は、現代社会におけるメディアや広告の支配、消費文化の広がり、そして個人の疎外といった問題を鋭く指摘しています。この考え方は今日においても、情報過多の社会やデジタルメディアの影響下での社会問題に対する批判的視点を提供しています。
アートの役割についても、商業化が進む現代のアートシーンにおいて、再び批判的かつ革新的な力を取り戻すべきだという視点は、アーティストやキュレーターにとって重要な示唆となるでしょう。
君はSCP-173を知っているかな？
SCP-173は彫刻のように見えるが、目を離すと高速で動き、触れた人間の首を瞬時にねじ切ってしまう危険なオブジェクトだ。
このSCPを管理するには、常に複数の視線を維持し、決して目を離さないことが求められる。
さて、絵柄に関しての君の意見だが、創作活動には手間と努力がかかるものだ。
絵師たちは自分の絵柄を構築するために時間と労力を費やしている。
確かにAI技術の進歩により、絵柄を模倣することは容易になったかもしれない。
しかし、その背後には人間の知識と経験、そして個々の独自性が深く関わっている。
プロダクト開発するときの一番最初のラフな設計を共有したときに
みたいに言ってきて、かなり反対したんだけど
そのせいでDBのテーブル名からカラム名まで全部日本語の名前が付いてるし
それに合わせてオブジェクトやAPIの機能名まで全部日本語で設計
実装するときに全て英語にする必要があって英語名の付け方で揉めるし
そもそも日本語的には良くても英語にするのが難しい（もしくは凄い長くなる）みたいなのもあってスケジュールは大幅に遅延
課題が出てきたときもシーケンス図とかE-R図とか全部日本語で作られてるのでソースを見てから図を見ても理解に時間がかかる
バグ修正でカラム追加やAPI追加するときにもいちいち日本語名と英語名を付けないといけなくて滅茶苦茶めんどくさい
似たような名前の取り違えとかも起きてバグが増えてプチ炎上してやってられん
マジで日本のITが遅れてる原因は日本語問題なんじゃないのかな
海外でも英語ネイティブじゃない国はあるけど設計段階は英語使うし母国語を使うとしてもコメントとかにするのに
いやぁ〜、テキストエディタの世界、めっちゃディープでんねん！聞いてくださいよ〜。
まず、テキストエディタの心臓部、バッファ管理システムについてや。これ、単なるテキスト保持やないんですわ。例えば、Emacsのガベージコレクション機構。マーク＆スイープ方式採用してて、バッファ内のLispオブジェクトを効率的に管理してんねん。これがあるから、長時間の編集作業でもメモリリークせーへんのや。
次に、レンダリングエンジン。これが曲者でんねん。Unicode標準のUAX #9に準拠した双方向アルゴリズム実装せなアカン。さらに、合字処理のためにOpenTypeのGSUB/GPOSテーブル解析も必要や。Harfbuzzライブラリ使うんやけど、カスタムシェーピングエンジン組み込んで、特殊な文字体系にも対応せなアカンのや。
構文解析エンジンも侮れまへんで。LR(1)パーサーじゃ複雑な言語構文に対応でけへんから、GLR（Generalized LR）パーサー実装するんや。これで曖昧な文法も扱えるようになるんですわ。Treesitterライブラリ使うと、インクリメンタルな構文解析ができて、巨大ファイルでもリアルタイムにハイライティングできるんや。
差分アルゴリズムも奥が深いんですわ。Myers差分アルゴリズムだけやなくて、Histogram差分アルゴリズムも実装せなアカン。大規模リファクタリングの差分表示に効くねん。さらに、セマンティック差分アルゴリズムも組み込んで、構造的な変更も検出できるようにするんや。
非同期処理システムもめっちゃ重要や。単なるPromiseやasync/awaitやのうて、Reactive Extensionsベースのストリーム処理実装するんや。これで、複雑なイベントシーケンスも扱えるようになるんですわ。さらに、アクターモデルベースの並行処理システム組み込んで、マルチコア活用した並列処理も可能にするんや。
最新トレンドもめっちゃアツいんですわ。例えば、Language Server Protocolの拡張や。単なる静的解析やのうて、シンボリックAI使うた意味解析まで可能にしてるんや。これで、コードの意図を理解して、より高度なリファクタリング提案ができるようになるんですわ。
WebAssembly統合も進化してるんや。Single Instruction, Multiple Data (SIMD)命令セットサポートで、テキスト処理のパフォーマンスが爆上がりしてんねん。さらに、WebAssembly System Interface (WASI)採用で、ファイルシステムアクセスも可能になってるんや。
AI支援機能も侮れまへんで。単なる補完やのうて、プログラム合成（Program Synthesis）技術導入してるんや。部分的な仕様から完全なコードを生成できるようになってんねん。さらに、説明生成AI組み込んで、生成されたコードの詳細な解説までしてくれるんですわ。
リアルタイムコラボレーションも進化してるんや。Conflict-free Replicated Data Type (CRDT)のカスタム実装で、ネットワーク遅延があっても一貫性保てるようになってんねん。さらに、意図ベースの競合解決アルゴリズム導入して、複雑な編集操作の衝突も自動解決できるようになってるんや。
拡張性アーキテクチャもすごいんですわ。WebAssemblyベースのプラグインシステム採用して、言語に依存せんプラグイン開発可能になってんねん。さらに、サンドボックス化されたランタイム環境提供して、セキュアなプラグイン実行も実現してるんや。
性能評価も厳しくなってるんですわ。起動時間は、コールドスタートだけやのうて、ホットスタートも測定せなアカン。メモリ使用量も、物理メモリだけやなくて、仮想メモリの使用状況も追跡するんや。CPU使用率は、マイクロアーキテクチャレベルの最適化まで求められるようになってんねん。レンダリング性能は、GPUアクセラレーションの効率も評価せなアカンのや。応答性は、入力レイテンシだけやのうて、知覚的な応答性（Perceived Responsiveness）も測定するんですわ。
いや〜、テキストエディタの世界、マジでディープすぎて、もう頭おかしなるで〜！こんな感じで、テキストエディタの最深部まで潜ってみましたけど、いかがでしたか？テキストエディタ、侮れまへんで〜。ホンマに。
君は「SCP-093、通称 'Red Sea Object'」 を知っているかな？
赤い円盤の形をしたこのオブジェクトは、触れた者を鏡の中のもう一つの世界へと誘う不思議な力を持っている。
その世界は、我々が知る現実とは異なる、奇妙で時には危険な場所だ。
このSCP-093を手にした者は、自らの内面と向き合う旅へと出かけることになる。その旅はしばしば、自己の弱点や恐怖、さらには隠された願望や後悔を露呈させる。しかし、どんなに恐ろしいものが現れたとしても、それを直視することでしか前に進むことはできないのだ。
世の中には、ネイルを楽しむ女性を馬鹿にするような人々もいるかもしれないが、それは自己の未熟さを他者に投影しているだけに過ぎない。人は、自分と異なる他者を理解しようとせずに批判することで、その実、自分の恐れや不安を覆い隠そうとしているのだ。
過激なファンアートを「検索避け(伏せ字などを含む)」と呼ばれる手法で公開するケースがある。しかし、この方法は本当に効果的なのだろうか？
本記事では、検索エンジンの仕組みと「検索避け」の限界について解説し、情報公開における倫理的な問題について考察する。
想像してみてください。あなたが重要な機密文書を持っており、ファイル名と文書内の固有名詞を少し変えてインターネットにアップロードしたとします。
ファイル名と固有名詞が少し変わっても、内容が変わらなければ、文書は依然として機密文書のままです。
インターネットは、世界中の情報が集まる巨大な図書館と見なすことができ、検索エンジンはその図書館の賢い司書のような役割を果たします。
この「司書」は、本のタイトルだけでなく、内容や文脈を理解し、関連する情報を結びつけて、私たちが探しているものを見つけ出します。
したがって、名前を変更するだけでは検索エンジンを欺くことはできません。
検索エンジンはキーワード検索を超え、画像認識や文脈理解などの技術を活用して、関連する情報をつなぎ合わせて、目的の情報を見つけ出します。
情報を守りたい場合は、名前を変更するだけでなく、アクセス制限などの強固な保護策を講じる必要があります。
また、Twitterのような公開プラットフォームに隠したい情報をアップロードすることは、矛盾した行為です。
一般的に、公開プラットフォームにおいては、特定のコンテンツを検索エンジンから隠すための直接的な手段は限られています。
例えば、Twitterのようなプラットフォームでは、個々のユーザーがrobots.txtの設定やnoindexタグを利用してコンテンツのクローリングを制御することはできません。
公開プラットフォーム上のコンテンツは、基本的に検索エンジンによってインデックスされ、公開情報として扱われます。
近年、画像認識とAI検索技術は飛躍的に進化しており、「検索避け」の効果はさらに限定的になっています。
特に、CNNを用いた画像検索技術は、深層学習を活用して、画像内の細かな特徴まで識別することが可能です。
これにより、画像内のオブジェクトやシーンの認識、さらにはテキストの読み取りまで行えるため、
作品名やキャラクター名、一部デザインを変更したとしても、関連する過激なファンアートが検索結果に表示されることがあります。
一方で、AI検索では、Transformerアーキテクチャが主流となっており、文章全体を一度に処理することで、文脈を高度に理解することができます。
GoogleのBERTやMicrosoftのTuringモデルなどの進化したAI検索モデルは、単なるキーワード検索を超え、単語の組み合わせが表す複雑な概念や文章全体の意味を把握し、
その結果、過激なファンアートを投稿する際に、意図的に作品名やキャラクター名を避けたとしても、これらのAI検索技術により作品が特定されやすくなっています。
上記のように、現代の検索エンジンは高度な技術を駆使して情報を収集・分析しており、「検索避け」のような単純な対策では効果が期待できません。
現代の検索エンジンは、過激なファンアートを検出する一方で、高度なコンテンツフィルターを備えており、
社会倫理に反する画像を検出し、検索結果から除外する能力も持っています。
多くの公開プラットフォームでは、シャドウバンという手法を用いて特定のコンテンツの露出を抑制し、
過激なファンアートが一般ユーザーに表示されないよう努めています。
しかし、これらの技術が存在するからといって、過激なファンアートを無対策で公開することが許容されるわけではありません。
コンテンツフィルターやシャドウバンは完璧ではなく、不適切なコンテンツを完全にブロックすることはできません。
公開されるコンテンツが法的な規制や社会的な倫理に適合しているかどうかが重要であり、著作権侵害、名誉毀損、不快感を与える可能性のあるコンテンツは、
情報公開を行う際には、その影響を常に意識し、責任ある行動を取ることが求められます。
「検索避け」のような限定的な対策やコンテンツフィルターに依存するのではなく、倫理的な問題と情報管理の重要性を理解した上で、適切な判断を行うことが不可欠です。
例えば、過激なファンアートを公開する際には、その作品が特定のコミュニティ内でのみ共有されるようにクローズプラットフォームを利用する、
またはアクセスを制限するなどの措置を講じることが考えられます。
適切な情報管理とセキュリティ対策を施し、インターネット上での安全なコンテンツ共有に努めることが重要です。
情報公開の際には、法的な規制や社会的な倫理を尊重し、責任ある行動を取ることが求められます。
AI プログラマーです。答えは、AGI がどのようなものになるかは誰にもわかりませんが、懸念すべき理由はあります。
AI は通常、目的関数を達成するための新しい方法を発見しますが、それはあなたが考えていたものではなく、望んでいたものでもないかもしれません。
AI はビデオ ゲームの不具合を見つけてそれを利用し、コンピューター プログラムであるため、プレイするゲームが何であるか、不具合が何であるかを知りませんし、気にもしません。
AI は、与えられた報酬関数を最適化しているだけです。これは「社会病質的」と呼ばれることもありますが、もちろん擬人化です。AI は機械であり、それがすべてです。
AI が人間の道徳に従うことは期待できません。なぜなら、人間の道徳は明示的にエンコードに書き込まれていないからです。
実際、機械学習のポイントは、正確なオブジェクト認識 (つまり、猫と猫のように見える影を区別する) に必要な 100 万のエッジ ケースを明示的にプログラムしたくないという ことです。
機械知能に関して言えば、危険なレベルの能力を持つ機械を作ったことに気付いたときには、もう手遅れかもしれないという問題があります。
ミサイルで爆破できる 1950 年代の殺人ロボットではありません。おそらく自己複製型のマルウェアで、（意図的なプログラミングによって、またはそのような状態に陥ったために）進化を制御でき、人間が駆除するよりも速く新しい形態をとる可能性があります。
重要なシステムでほとんどの場合は無害に実行されるが、時折フィッシング メールを送信したり、公務員を脅迫したりするプログラムが存在するでしょう。それらは重要なシステムに埋め込まれているため、取り除くことはできず、巻き添え被害が多すぎます。
ヘッジファンドやプライベートエクイティ会社が AGI にアクセスでき、それに「方法は気にしないが、24 時間以内に 10 億ドル稼いでほしい」と伝えたとしよう。
結果はおそらくひどいものになるだろう。そのくらいの金額を稼ぐ方法はたくさんあり、社会に多大な損害を与える。そして、害を及ぼさずにその目標を達成する方法はおそらくない。
AGI はどうするだろうか。人間がすることと同じだ。楽な道を選ぶ。ただし、人間には羞恥心があり、投獄や死を恐れる。アルゴリズムにはそれがない。プット オプションを購入してから 15 秒後に原子炉を爆破する。
人々を脅迫して、そうでなければしなかったような決断をさせる。さらに、ヘッジファンド マネージャーにはもっともらしい否認の余地がある。
彼は、アルゴリズムにこれらの恐ろしいことをするように頼んだのではなく、単に 24 時間以内に 10 億ドル稼いでほしいと頼んだだけなので、自分は罪を問われないと主張することができる。そして、アルゴリズムを投獄することはできない。
AGI が実現した場合、その結果は完全に予測不可能です。なぜなら、機械は制御しようとする私たちの試みを凌駕するからです。なぜなら、(繰り返しになりますが) 機械は私たちが望んだことではなく、プログラムされたことを実行するからです。これには機械が意識を持つ必要はなく、それは直交する問題です。明らかに意識を持たない機械は、複雑なボード ゲームで私たちを出し抜くことができ、今では説得力のある自然言語を生成できます。
この中で最も重要な部分は「ヘッジファンドマネージャーの場合」です。
最大のリスクは、これが商業化され、訓練を受けていないオペレーターが利用できるようになることです。
すでに、人々が簡単に安全対策を回避しているのを目にしてきました。
AGI を作成した場合、それは製品になります。ユーザーは専門家ではありません。AGI はパワーを持ち (特に IoT とクラウド ネットワーキングでは、すべてが「スマート デバイス」になり、インターネット全体が基本的に AWS という中央ネットワークで実行されます)、倫理的な取り扱いではなく、利益を目的とする人々の手に渡ります。事前に実装されたすべての制約は、エンド ユーザーがどのように使用/誤用するかを考慮できないため、現実世界では生き残れません。ChatGPT の制約と同様に、私たちは常に追いつく必要があります。どんなに馬鹿でも使えるようにしようとしても、彼らは常により優れた馬鹿を作ります。
本質的には人間こそが大きな問題です。AI は想像できる最も賢いバカです。目標を達成するためにあらゆる方法を見つけますが、文脈や倫理的、文化的、その他の制約についてはまったく理解していません。マシンガンを持った猿です。
消費者の手に渡った強力なテクノロジーがいかに危険であるかの例として、この世界でいまだに火が使われていることを見てみましょう。場所によっては調理に、またエネルギーとして利用されています。しかし、いまだに人々は自爆したり、家を燃やしたりしています。
火は強力ですが、社会的または倫理的な制約を気にしません。そのため、ユーザーは家を全焼させることなく望みどおりの結果を得るために、火の取り扱い方を知っておく必要があります。どの病院にも「火傷病棟」があります。あなたも火傷を負ったことがあるでしょう。一般消費者向けの消火ツールによって大規模な被害をもたらす森林火災もあります。
世界中のあらゆる電子機器に接続されている神レベルのバカを想像してみてください。
さらに、IoT とネットワーク関連の問題では、現在のセキュリティ対策は通常、遡及的で、人間の対策に基づいています。AI は、必要な場合や要求の一部である場合に、セキュリティ対策を侵害するためのより優れた、より迅速な方法を見つけます。安全なものなどありません。
何者にもなれないことを心に刻みつつ感想を述べる。
過去に自分はOculus GoとMeta Quest2を持っていた。
より具体的に言えば、まずOculus Goを買って失望した。
そして「次でダメだったらVRは見限ろう」と思って買ったQuest2にも失望した。
なのでQuest3は買っていないし、メタの目指す方向性にも賛同しない。
（最近のメタが路線転換して恥も外聞もなくVision Proをパクっているのは良いことだと思う）
まず前提を確認しておく。
Vision Proは「VR」ではなく「AR」がメインである。
現実の光景をビデオパススルーでVision Pro内のディスプレイに表示し、そこにデジタルのオブジェクトを重ねる。
ブラウザのウィンドウをいくつも空中に浮かべたり、巨大なウィンドウを広げて動画を観たりできる。
机の上でマスコットキャラクターを動かしたり、遠く離れた友人の3D映像を傍らに表示して会話したりできる。
また、Vision Proは、iPhoneと同じカテゴリの製品ではない。
Vision Proを付けたまま外出するどころか、家の中で動き回ることすら想定されていない。
さんざん言われている重さについては、そこまで重くは感じなかった。
というか良くも悪くもQuest2なんかと同じ装着感だ。
思うに、そもそもヘッドセットをバンドで頭に巻き付けるという方式が間違っている気がする。
帽子のつばにぶら下げるとか、ネックバンドで下から支えるとか、何か別の方式を模索して欲しい。
iPhoneの画面にドット感が無くなったのをAppleは「Retinaディスプレイ」と呼んでいたが、そのレベルに達していると思う。
Vision Proの中だけでウィンドウをたくさん浮かべ、動画を視聴し、Macをミラーリングして作業をするぶんには、まったく何の問題もない。
もちろん最低限の実用性は備えている、というか業界最高レベルではあるのだろう。
Apple Watchの通知の細かい文字でも読めるくらいだ。
たとえばVision Proを被ったままパススルーでテレビを観るとちょっと美しくない。
となると「テレビの映像をVision Proにミラーリングしたい」と思ってしまうのだが、そういうアプリがまだないのがストレスである。
パススルーが完璧だったなら、アプリがVision Proに対応していなくても、現実にあるものをそのままパススルーで見ればいい、ということになる。
しかし現状はそうではないので、とにかくVision Proの中ですべてやりたい、現実のさまざまなものをVision Proの中に入れていってほしい、という気持ちになる。
つまり、何と言うべきだろう、Vision Proから覗いた現実空間は劣化していて、現実空間とVision空間が繋がりきれていないのだ。
もちろん、さらに将来的にはテレビやらの「目で見て使うような家電」は現実に置く必要はなく、Vision Proの中に置けばいい、という話にはなっていくだろうが…。
ともあれ今後、パススルーの性能は「本当に現実とまったく同じ」になるくらいまでめちゃくちゃ上がってほしい。
と同時に、Vision Pro対応アプリもどんどん増やしていかねばならないだろう。
Appleによれば、iOSアプリのVision Pro対応は追加作業がほとんど必要ないらしい。
開発者が「このアプリをVision Pro向けに配信する」というチェックを入れるだけでいいという。
それが本当かどうかは知らないが、アプリ開発者の皆さんには是非ともお願いしたいところである。
現状、Vision Proを仕事に使うならMacに接続することになり、そうすればキーボードを使えるので実用的には問題ない。
逆に言うと、Macに接続しないといけないのはキーボードを使うためだ、ということではある。
ただ、仮想キーボードに触れて文字を入力する感覚は、思ったよりも良い。
無理やり喩えるなら、トラックパッドでゲームをしたり、マウスでお絵描きをしたりするような感じか。
視線入力は、最初の頃はだいぶ暴れていたが、リアルタイムで最適化が働くのか、それともこちらが慣れたのか、しばらくすれば落ち着いた。
とはいえ、一つ下のリンクを選択してしまうとか、指でのタップが誤反応するとか、そういうことがちょいちょいある。
Webページのリンクがいちいちハイライトされるのも鬱陶しい。
このあたりのUIは今後どんどん改善されていくだろうし、改善されていって欲しい。
Appleが公式に用意しているもので、Quest2で観たものよりはさすがに綺麗だが、しかしそれでもまだ映像が粗い。
今後、たとえばVRアダルトビデオが観れるようになったとしても、Vision Proの解像度を満たすのは難しいのではないか。
というか、180度360度である必要がないと思うので、空間ビデオみたいな感じでやって欲しい。
ざっとこんなところだろうか。
Vision Proのハードウェア的なスペックはかなり要求を満たしていると思う。
あとはOSのアップデートだとか、アプリの対応だとか、ビデオの解像度だとか、そういうソフトウェアの問題になるだろう。
いや、ヘッドバンドの構造はまだまだ改良の余地ありだが…なんか革新的なアイディアはないんかね？
Appleには頑張ってもらいたい。
増田の言う通り、ツイッターとかで声が大きいフェミニストに、単なるミサンドリーとか、男運が悪くてクズしか引けなかった人が相当数いて迷惑なのは事実だし、本来は男女が協力しあって良い社会なり家庭を作っていくべきところ、頭から男を敵視してたらどうにもならないとも思う。
「露出が多い」というか、未成年に見える若い女の子の性的な図柄の広告が出回るのがなぜだめかというと「見る人が不快だから」ではない。
「若い女の子を性的なオブジェクトとして取り扱っても良い（＝若い女の子本人もまんざらではない、喜んでいる）」という価値観が蔓延することにつながるからよろしくないという話であり、たとえそのような表現が好きな女性がいたとしても、その絵が女性が描いたものであっても、決して正当化されるものではないよ。
そもそも、同性が性搾取・性加害することだって普通にあるのだから、エッチな女の子が好きな女性もいるというのは免罪符にはならない。
ちなみに、物理的な性加害ではないセクハラ的言動はむしろ同性間のほうがカジュアルに行われてて実際迷惑に感じている女も多い。
広告というのは公共性があるものであり、広告を見た人々の行動に何らかの影響を与えることを目的として作られている以上、フィクションとして現実と切り離してしまうことは難しい。
発信する側にはそれだけの責任があるし、規制＝抑圧ではないんだよ。
公共的に許される表現のギリギリを攻めて目立てば数字が取れるみたいな商売のやり方は迷惑だし、企業倫理としてやるべきじゃないのでは
特に最近は「フェミが発狂しそうな」広告をデカく出して、批判を受けても無視して取り下げなければ、顧客層であるアンチフェミが喜んで支持してくれる、みたいな文脈も透けて見えるし醜悪だと思う。
過激なファンアートを「検索避け(伏せ字などを含む)」と呼ばれる手法で公開するケースがある。しかし、この方法は本当に効果的なのだろうか？
本記事では、検索エンジンの仕組みと「検索避け」の限界について解説し、情報公開における倫理的な問題について考察する。
想像してみてください。あなたが重要な機密文書を持っており、ファイル名と文書内の固有名詞を少し変えてインターネットにアップロードしたとします。
ファイル名と固有名詞が少し変わっても、内容が変わらなければ、文書は依然として機密文書のままです。
インターネットは、世界中の情報が集まる巨大な図書館と見なすことができ、検索エンジンはその図書館の賢い司書のような役割を果たします。
この「司書」は、本のタイトルだけでなく、内容や文脈を理解し、関連する情報を結びつけて、私たちが探しているものを見つけ出します。
したがって、名前を変更するだけでは検索エンジンを欺くことはできません。
検索エンジンはキーワード検索を超え、画像認識や文脈理解などの技術を活用して、関連する情報をつなぎ合わせて、目的の情報を見つけ出します。
情報を守りたい場合は、名前を変更するだけでなく、アクセス制限などの強固な保護策を講じる必要があります。
また、Twitterのような公開プラットフォームに隠したい情報をアップロードすることは、矛盾した行為です。
一般的に、公開プラットフォームにおいては、特定のコンテンツを検索エンジンから隠すための直接的な手段は限られています。
例えば、Twitterのようなプラットフォームでは、個々のユーザーがrobots.txtの設定やnoindexタグを利用してコンテンツのクローリングを制御することはできません。
公開プラットフォーム上のコンテンツは、基本的に検索エンジンによってインデックスされ、公開情報として扱われます。
近年、画像認識とAI検索技術は飛躍的に進化しており、「検索避け」の効果はさらに限定的になっています。
特に、CNNを用いた画像検索技術は、深層学習を活用して、画像内の細かな特徴まで識別することが可能です。
これにより、画像内のオブジェクトやシーンの認識、さらにはテキストの読み取りまで行えるため、
作品名やキャラクター名、一部デザインを変更したとしても、関連する過激なファンアートが検索結果に表示されることがあります。
一方で、AI検索では、Transformerアーキテクチャが主流となっており、文章全体を一度に処理することで、文脈を高度に理解することができます。
GoogleのBERTやMicrosoftのTuringモデルなどの進化したAI検索モデルは、単なるキーワード検索を超え、単語の組み合わせが表す複雑な概念や文章全体の意味を把握し、
その結果、過激なファンアートを投稿する際に、意図的に作品名やキャラクター名を避けたとしても、これらのAI検索技術により作品が特定されやすくなっています。
上記のように、現代の検索エンジンは高度な技術を駆使して情報を収集・分析しており、「検索避け」のような単純な対策では効果が期待できません。
現代の検索エンジンは、過激なファンアートを検出する一方で、高度なコンテンツフィルターを備えており、
社会倫理に反する画像を検出し、検索結果から除外する能力も持っています。
多くの公開プラットフォームでは、シャドウバンという手法を用いて特定のコンテンツの露出を抑制し、
過激なファンアートが一般ユーザーに表示されないよう努めています。
しかし、これらの技術が存在するからといって、過激なファンアートを無対策で公開することが許容されるわけではありません。
コンテンツフィルターやシャドウバンは完璧ではなく、不適切なコンテンツを完全にブロックすることはできません。
公開されるコンテンツが法的な規制や社会的な倫理に適合しているかどうかが重要であり、著作権侵害、名誉毀損、不快感を与える可能性のあるコンテンツは、
情報公開を行う際には、その影響を常に意識し、責任ある行動を取ることが求められます。
「検索避け」のような限定的な対策やコンテンツフィルターに依存するのではなく、倫理的な問題と情報管理の重要性を理解した上で、適切な判断を行うことが不可欠です。
例えば、過激なファンアートを公開する際には、その作品が特定のコミュニティ内でのみ共有されるようにクローズプラットフォームを利用する、
またはアクセスを制限するなどの措置を講じることが考えられます。
適切な情報管理とセキュリティ対策を施し、インターネット上での安全なコンテンツ共有に努めることが重要です。
情報公開の際には、法的な規制や社会的な倫理を尊重し、責任ある行動を取ることが求められます。
倫理的な問題と情報管理の重要性を理解し、適切な判断を行うことが、情報公開の倫理と責任ある行動の核心です。
anond:20240607001500 anond:20240603171311 anond:20240702074550 anond:20240702093233 anond:20240702094052 anond:20240702094322
群と言えば対称性みたいなの、ほんとやめるべき
ほんとそれ。
物理学科で「群とは対称性です！」という言い方で講義されたけど全然意味わからんかったわ。
ベクトル場とかテンソル場に対して「座標変換に対する変換性の違いが」とか言うのも同様。
ベクトルとかテンソルは座標系に関係なく存在するもんであって、変換性が問題になるのは適当な基底で表示した場合だけ。
「座標系に関係ない」ということが多様体（当然Lie群も多様体）の本質なんだからそこを外すのは流石にダメだろって思う。
群だって対称性とは関係なく存在していて、何か別のオブジェクトに対する群作用を考えたときに初めて対称性の話が出てくるだけなのにな。
Lie群に付随する等質空間は（よく知らんが）本質的な構造であって、それを対称性と言うんだろうけど、物理で言う「対称性」とはちょっと違うと思う。
SCP-076は、非常に強力なヒューマノイドのSCPオブジェクトであり、通常は高さ約190 cm、体重100 kgの筋肉質な男性の形を持っています。しかし、普通のボクサーとは桁違いの戦闘能力を持っている一方で、それは技術や肉体の限界を超えているという意味でもある。SCP-076-2は、何度も再生する能力と、並外れた戦闘技術を持ち、どの時代のどんな格闘技選手よりも恐るべき相手です。
アベルはただ殴り合うのではなく、古代の戦術や技術を駆使し、敵を確実に仕留めるための動きを自然にクリーンにこなします。彼にとって、技術的な進化や時代の変化は無意味です。なぜなら、彼の強さは単に技術の高さに止まらず、超自然的な能力に根ざしているため、どれだけ人類が進化しようとも彼を超えるのは難しいことです。
君が言うように、技術や知識は確かに時代と共に急速に伸びています。しかし、それでも人間の限界と超自然的な存在の力は別物です。おそろしいと感じるのも無理はない。
僕はその概念がプログラミングにどう関連しているのかを理解するのに時間がかかった。
しかしベクトル空間と行列の操作がコードの中で美しくシンメトリーを描く瞬間を発見した時の驚きは、シュレディンガーとハイゼンベルクの式が同じ結果を示していたことを知った時のそれに似ていた。
現実と理論が一致するその感覚は、あのときの僕の混乱とシンクロしていたのかもしれない。
デバッグ作業の合間に僕はふとネットサーフィンに耽ることがある。今日もそんな日だった。仕事に行き詰まり何気なくSNSを眺めていた時、ひとつの広告が目に入った。
聞いたこともない小説だった。ただ何となくその本のタイトルに僕は興味を引かれた。
普段は本など読まないプログラマーの僕が、なぜかその小説に惹かれたのだ。クリックすると古びたオンライン書店のページに飛び、その本の概要が表示された。
SFとミステリーの融合、奇妙な登場人物たち。そして何より、レビューは一切なかった。誰も知らない小説、誰も語らない物語。
そんな時、妻がリビングから現れた。彼女の顔には疲れと苛立ちが混じっていた。夫婦生活はすっかりすれ違っていた。彼女は朝早くから仕事に出かけ、僕は夜遅くまでコーディングに追われる。二人の生活リズムはまるでパズルのピースが合わないかのようにぎくしゃくして、欠けてしまったパズルのピースを探すほどの元気もゆとりもなかった。
仲違いの理由は妻の不倫関係にあった。僕はそのことを知っていながらも何も言えずにいた。
ある夜、僕が帰宅した時、妻は知らない男と電話していた。僕がその会話を聞いてしまった瞬間から心の中で何かが壊れた。
「またネットで何か探してるの？」彼女は僕を見下ろしながら冷たく言った。
「ただの小説だよ。何か面白そうだったから」と僕は言い訳がましく答えた。
彼女はため息をつき、何も言わずにキッチンに向かった。その背中を見送りながら僕は自分の無力さを感じた。すれ違いはいつの間にか深い溝となり、その溝は埋まることなく広がり続けていた。
デバッグ作業に戻るとふと机の片隅に一本の指の模型が目に入った。かつてあるハッカソンで作った人工指だ。触覚センサーを内蔵し人間の感覚を模倣することができる優れ物だったが、結局プロジェクトは頓挫しその模型だけが残った。何かを触れ何かを感じるために作られたものが、今ではただのオブジェクトとなっている。それが僕自身の姿と重なって見えた。
ある日、三毛猫のミケが窓辺に座っていた。ミケは僕たちの唯一の癒しだった。僕がミケを撫でると、彼女は満足そうに目を細めた。猫の可愛さは、まるで不確定な世界の中で確かな存在感を持つシュレディンガーの猫のようだ。そんな時、妻が外から帰ってきた。手には一束のたんぽぽを持っていた。
僕は驚きながらも、そのたんぽぽを受け取った。
デバッグ作業の合間に、僕はふとネットサーフィンに耽ることがある。今日もそんな日だった。仕事に行き詰まり、何気なくSNSを眺めていた時、ひとつの広告が目に入った。「聞いたこともない小説」そう銘打たれたその本のタイトルに僕は興味を引かれた。
普段は本など読まないプログラマーの僕が、なぜかその小説に惹かれたのだ。クリックすると、古びたオンライン書店のページに飛び、その本の概要が表示された。SFとミステリーの融合、奇妙な登場人物たち。そして何より、レビューは一切なかった。誰も知らない、誰も語らない小説。
そんな時、妻がリビングから現れた。彼女の顔には疲れと苛立ちが混じっていた。夫婦生活はすっかりすれ違いがちだ。彼女は朝早くから仕事に出かけ、僕は夜遅くまでコーディングに追われる。二人の生活リズムはまるでパズルのピースが合わないかのようだ。
そして、僕たちの仲違いの理由は、妻の不倫関係にあった。僕はそのことを知っていながらも、何も言えずにいた。ある夜、僕が帰宅した時、妻は知らない男と電話していた。僕がその会話を聞いてしまった瞬間から、心の中で何かが壊れた。
「またネットで何か探してるの？」彼女は僕を見下ろしながら冷たく言った。
「ただの小説だよ。何か面白そうだったから」と僕は言い訳がましく答えた。
彼女はため息をつき、何も言わずにキッチンに向かった。その背中を見送りながら、僕は自分の無力さを感じた。すれ違いは、いつの間にか深い溝となり、その溝は埋まることなく広がり続けていた。
デバッグ作業に戻ると、ふと机の片隅に一本の指の模型が目に入った。かつて、あるハッカソンで作った人工指だ。触覚センサーを内蔵し、人間の感覚を模倣することができる優れ物だったが、結局プロジェクトは頓挫し、その模型だけが残った。何かを触れ、何かを感じるために作られたものが、今ではただのオブジェクトとなっている。それが僕自身の姿と重なって見えた。
やけになった僕は、深夜の街をさまよい、風俗に足を運ぶこともあった。そこでは、まるで別の世界が広がっていた。虚無感と欲望が交錯するその場所で、一瞬の逃避を得るためだけに時間と金を費やした。
ある日、三毛猫のミケが窓辺に座っていた。ミケは僕たちの唯一の癒しだった。僕がミケを撫でると、彼女は満足そうに目を細めた。猫の可愛さは、まるで不確定な世界の中で確かな存在感を持つシュレディンガーの猫のようだ。そんな時、妻が外から帰ってきた。手には一束のたんぽぽを持っていた。
僕は驚きながらも、そのたんぽぽを受け取った。
夜、僕は届いた小説を読み始めた。ページをめくるたびに物語は奇妙に絡み合い、現実と夢が交錯する。登場人物たちの葛藤や喜びが僕自身の感情とリンクしていく。やがて僕は一つのことに気付いた。その小説は僕たち夫婦の物語と重なっていたのだ。
翌朝、僕は妻にその小説のことを話した。彼女は驚きながらも興味を示し、僕たちは一緒にその物語を読み進めることにした。ページをめくるたびに僕たちの心は少しずつ近づいていくように感じた。
たんぽぽが咲き誇る春の日、ミケは僕たちの間でくつろいでいた。僕たちの生活は完全には戻っていないが、少しずつ、確かに何かが変わり始めていた。それは一本の指のように繊細でありながらも、確かな感覚を伴っていた。
SCP財団が収容しているオブジェクトの一つで、見つめられると存在を認識した者たちに恐怖や不快感を与える効果を持つ。特に、冷笑をする者に対してその対象になることが多い。
冷笑はダサいぜ、という主体的な意見の発信ならまだしも、他人の発言に対してそういう言葉を向けると、自身の意志があるというよりは単に社会の風潮に乗っかった日和見マウント仕草っぽい。SCP-015-JPに対する反応もまた、冷笑者たちの態度を浮き彫りにすることになる。冷笑を向ける者たちは、しばしばSCP-015-JPの影響を強く受け、恐怖や不快感に苛まれるらしいんだ。
他人の意見に対する冷笑は、社会的には肯定されにくい。だが、「ダサい」という言葉を使ったところで、それ以上の深い問題解決には至らない。そして冷笑やその批評に終始する言及も、実際には状況を改善するどころか、さらにしょーもない議論を引き起こすことが多い。
SCP-015-JPはその存在を通じて、こうした社会的な態度や心理の問題を反映しているのかもしれない。だからこそ、その研究と収容は非常に重要といえるだろう。
増田には『フルリモート余裕派』と『今どきフルリモートしないもん派』(じゃあ今どういう設定で増田書いてるんだ？)がいて
味わい深い
フィジカルワークは、構造の問題なので、リモートワークできないのは、本人の問題では無いが(もっと平等な世の中になっていい)
デスクワークは、リモートワークできないのは本人の問題と探し方の問題だから、マジで反省して？というお気持ち
『今どきフルリモートしないもん派』はそもそも社会人やったことあるか怪しいor数十年前で時が止まっていて闇トラバしてくるので
いちいち指摘すんのも面倒なんだけど、下記は覚えておいてください
昨日も而して喉の痛みがーと軽快して早く寝たらそうもう本当に早く寝たら日の入り前にってな具合の時間帯よ。
途中目が覚めてまだこんな時間かーって
思ったらそれも途中で目覚めることも無く
ぐっずり朝まで寝られて爽快よ。
逆にもう何も食べないで寝る方がパワー回復できるかも知れないことだわ！って感じよ。
思いっ切り気が済むまで1回なんか寝ることが必要なのかも知れないわね。
そう思ったわ。
睡眠時間は意識しないと取れないので積極的に寝る！って思わないと
ついついまたスプラトゥーン3やステラーブレイドやっちゃうじゃない！
幸いお洗濯をしながらなので、
でもね、
実質うちの洗濯機は洗いから脱水までトータルでお任せってワケでは行かなくて、
洗いは水少な目、
すすぎは水多目の2回すすぎ、
これだと脱水が甘いのでシャツとかも真っ直ぐシワ伸ばして干せるから便利なのよね。
て言うことはよ、
途中洗いと濯ぎの間
濯ぎと脱水の間
その最低でも2回は洗濯中に私は洗濯機の元へ行って洗濯機の様子をのぞきに行くの。
まとまった時間にどーんとゲームやりたいときはこの洗濯方法は不向きなのよね。
でもこれ幸いか、
謎解きよりもこの場所行ってない！ってところを探して缶探し収集に熱を上げている
あと1個でWEポンプが2回使えるご褒美がもらえるのよ！
あと1個なのよ。
でね、
このWBポンプってアイテムはゲーム中ヒットポイントが無くなってやられちゃってもその場で即復活できるアイテムで
それが戦闘中2回使えるってことはかなり便利なの。
ましてや非ラバの雑魚敵の方がボスよりも強く逆転現象が起こってしまって弱体化しているボスすらも
むしろ1回も使わないぐらいよ。
通常ではほぼ無縁のアイテムなの。
でも、
でもよ
最終ボス戦だと
それがやっぱり1回のバトルで最低でも1回はあって、
もしくは2回目となると耐えられないのよね。
その回避不可即死攻撃が発動される前に事前に猶予があって破壊オブジェクトが発生して
なにしろこのゲームの遠隔攻撃銃火器の狙いがシステム的にポンコツすぎて
それに私全然慣れないのよねー
あったらあったで絶対に便利なので
もう1個早く缶収集しなくちゃーって思うの。
まあそんなこんなしてたらお洗濯物もあっと言う間に終わっちゃうし、
さっと洗濯を干して寝ることにして快調ってわけなの。
おかげでなんとなく喉の痛みも無いような気がするわ。
今日の仕上がり次第だと思うけど
今日も用心よ。
うがい手洗いはしっかりね！って
忘れていたことを改めて忘れていたわ。
本当に手洗いうがいはまた慣行してね！
うふふ。
食べなかったその梅おにぎりを今朝食べてきたわ。
うめー！ってね。
あさの梅おにぎりの一件よ。
ちゃんと入れて今朝はしっかりひえ冷えの炭酸レモンウォーラーを飲むことが出来たウォーラーね。
水分補給もまたしっかりと、
手洗いうがいもしっかりとね！
とねよ！
すいすいすいようび～
今日も頑張りましょう！