  |
はてなキーワード: 規約とは
ツイッターに画像を投稿する際はAI学習のために利用されることに同意しなければならないというものだけど、一部絵師様が「ツイッターやめる！移住だ！」などと言ってるらしい
別に違うSNSに移住したところでそこに投稿された画像をAI学習に利用するのは法律上完全に合法なんだから意味ないんじゃねーのと思うけど、まぁとにかくAIに反対しているというポーズをとるのが重要なんだろうな
移住先のSNSだってAIの学習目的での利用を禁止する規約を用意しているところなんてないし、仮にあったとしても法的には合法なんだから意味がないのにご足労なことだと思う
マジで生きづらそう
これは皮肉で言ってるんじゃないよ
最近ワンピースの作者がAIを利用したコンテンツを提供したり、ぷにるは可愛いスライムの作者が背景にAIを使ったりとクリエイターの中にもAIを利用する人が増えている
AI嫌いの人って自分の好きなクリエイターがAI使ったらそれだけで嫌いになるのかな
だとしたらあと5年後にはあらゆる作者のことが嫌いで嫌いで仕方なくなるだろう
ここ最近のエロ系の同人とかよく目を凝らして読んでみるといいよ
やぶ蛇になるからわざわざ作者が言及していないだけで実はもう効率化の一つとしてAIの利用は浸透していってる
AI自体のクリエイターに対する支援機能の進化もめざましくて、あと数年もすれば背景アシスタントなんていらなくなるんじゃないか？ってレベルだ
Adobeに生成AIが搭載されたのだってもう1年も前の話だからね
ユーチューブの広告でAI生成の合成音声を耳にしない日ってある？
あとゲーム系のクリエイターなんかはAIに対しても親和的だよね
例えば同人ゲームについてはAIを完全に排斥したゲームを探す方が難しいくらいになっている
企業系のゲームだって荒れるからいちいち言わないだけでAIの利用には積極的だよ
別にAIなんてのはただの道具に過ぎないわけで、自分の脳内にある作品を効率よく出力できるならクリエイターは合法な範囲で何でも使うに決まってるだろ
っていうか、AIに反対しているクリエイターって自分の作品を褒められたいんじゃなくて自分の技術を褒められたいだけなんじゃないか？
それってクリエイターとしては異端というか、結構いびつだと思うんだよね
俺は反AIに傾倒してフォロワーや友人を失っていく絵師を何人も見てきたよ
かわいそうに、反AI活動で増えたフォロワーって別に手描きのイラストそれ自体にはあまり興味がないようで、せっかく手で描いたイラストにも感想を寄越してくれないんだよね
反AIのクリエイターは今一度自分がなぜ反AIなのか考える時が来たんじゃないか？
Ｘは、11月から、投稿した画像をＡＩ学習に自由に使用できるよう規約を変更する。この場合のユーザに対する報酬は、Ｘというサービスを利用できていることを上限とするとしている。
ここで問題になるのは、規約変更前に、ニンテンドースイッチなどの投稿機能を利用して投稿したゲーム画像などもＡＩ学習に利用されて著作権侵害されるのではないかということである。
ニンテンドースイッチやソニーのプレイステーションなど各種のゲームプラットフォームでは、ゲーム画像の投稿にあたり「ネタバレにあたらないこと」のほか「改変しないこと」「クレジット・タグを入れたままにすること」などの条件をユーザーに求めている。
しかし、ＡＩ学習された元の画像の特徴をのこして改変の状態になったものが学習済みＡＩから生成されてしまうことはすでによく知られている。この手落ちはＡＩ学習者に一向に治される気配がない。
現在のＸとニンテンドーは、提携していないので、スイッチなどのゲーム機から画面を投稿することはできなくなった。
しかし過去に投稿したものをそのまま残しておくことは、ゲーム等の著作権を間接的に侵害する立場であるとみられてもしかたがない。
しかたがないので、良心あるユーザーは、ゲームや肖像権など他者に完全許諾を得られない動画も写真も絵も投稿したものは全部削除するしかないとおもう。
もちろん、実況系ユーチューバーなども全部消した方が良さそうだ。
私も現状のAIに対して思うところはあるが、無断学習の禁止はそれを解決する手段になり得ないと思う
学習には合意があるべきと主張する人の言う「合意」とは心からの合意を指していると思うが、法では契約上の合意が重要になる
例えばXでは投稿したデータは学習されると規約に記載されている、投稿した時点で合意しているのだ。知らなかったは認められない
そしてX社がAI企業にデータを販売することにも文句は言えない、”合意”してるんだから
結局、無断学習を禁じた所で利用規約にちょこっと盛り込まれて終わりなんだよね
自分のサイトだけで公開してれば良い話ではあるけど、現実的にそれは難しい。必ずどこかで合意しなければいけない時が来る
カリフォルニア州で俳優がAIでコピーされない法律が認められたけど、あれだって実際のところどうかは分からない
大物俳優は断れるだろうけど、無名の俳優は果たして断れるのだろうか
利益の還元の話も眉唾、Redditはデータの販売で莫大な利益を得たがユーザに還元したか？してない
OpenAIと契約したマスコミは記者に利益を還元したのか？してない
結局企業同士がやり取りし合うだけの話
初代プリキュアは初回一発でコードが当てられるのに、なんでだろう
なんか、コードが当てられる曲と、当てられないタイプの曲がある気がする
少なくとも、自分は耳は駄目な方だと思っているので、ベースギターのような音がない曲とかはかなりアウト、つらい
伴奏のベース音を地道に読むしかない、でもベースがあれば簡単である
問題はベースギターは低周波、低音域であるため、プロでも聴き取りづらいことがあるのである
しかし、今はAI技術も相まって、奇麗に原曲をパートに分けることができる
分けるツールも数多くあるが、Meta社が公開してるものがオープンソースで無償で一番よいであろう
それを呼び出すGUIツールも存在するので、そちらを利用した方が簡単であろう
規約上良いのか怪しいが、検索ワードを入れるとYouTube上の楽曲が表示され、そこからパート分けしたいものをクリック一発で選べるようになっている
さて、比較的奇麗なドラムやベース音が取り出せるようになっただけでも、大昔に比べれば快挙であろうが、私はこのパート分解した音声データをそのままDAWに貼り付ける
ちなみに、私の現在のDAWはStudio Oneである
貼り付けたベースのトラックのトランスポーズ？だったかを0から12に変更すればオクターブが1つ上がる
オクターブは2つまで上げられるみたい、でもオクターブ1つがちょうどいい
あとは短音でベースがなくともギターで真似していけばいいし、打ち込みのトラックのピアノロールに打ち込んでいくのもいいだろう
原曲の音声を使うのはYouTubeでは厳密には規約違反であり、違法であるはずだが、すべてを聴き取って打ち込み、楽器演奏を録音したコピー演奏は許されているはずである
これぐらいの簡単な曲であれば、ベースの音をそのままパワーコードにするだけで、ほぼなんちゃってメタルバージョンのできあがりである
最近の日本の楽曲は、異常にコード進行が複雑で、頻繁なものが増えてる
そうなるとテンションの違いなどがかなり顕著に意味を持ってくるので、パワーコードにしてしまったら、そのニュアンスがまったく死んでしまい、意味がなくなってしまう
それから、ベースの音＝コードのルート音みたいな安直なパターンからも外れやすくなるので、そこは注意する必要があろう
しかし、少なくとも昭和、平成のアニソンであれば、大抵のものはなんとかなるものである
超弦理論を数学的に抽象化するために、場の理論を高次圏（∞-圏）の関手として定式化する。
𝒵: 𝐵𝑜𝑟𝑑ₙᵒʳ → 𝒞ᵒᵗⁿ
ここで、𝒞ᵒᵗⁿ は対称モノイダル (∞, n)-圏（例：鎖複体の圏、導来圏など）。
超弦理論におけるフィールドのモジュライ空間を、導来代数幾何の枠組みで記述する。
BV形式はゲージ対称性と量子化を扱うためにホモトピー代数を使用する。
Δ exp(𝑖/ℏ 𝑆) = 0
ミラー対称性はシンプレクティック幾何学と複素幾何学を関連付ける。
𝓕(𝑋) ≃ 𝐷ᵇ(𝒞𝑜ʰ(𝑌))
以上の数学的構造を用いて、超弦理論における重要な定理である「ホモロジカル・ミラー対称性の定理」を証明する。
ミラー対称なカラビ・ヤウ多様体 𝑋 と 𝑌 があるとき、𝑋 のフクヤ圏 𝓕(𝑋) は 𝑌 の連接層の有界導来圏 𝐷ᵇ(𝒞𝑜ʰ(𝑌)) と三角圏として同値である。
𝓕(𝑋) ≅ 𝐷ᵇ(𝒞𝑜ʰ(𝑌))
1. フクヤ圏の構築：
- 対象：𝑋 上のラグランジアン部分多様体 𝐿 で、適切な条件（例えば、スピン構造やマスロフ指数の消失）を満たすもの。
- 射：ラグランジアン間のフロアーコホモロジー群 𝐻𝐹*(𝐿₀, 𝐿₁)。
2. 導来圏の構築：
- 射：Ext群 𝐻𝐨𝐦*(𝒜, 𝐵) = Ext*(𝒜, 𝐵)。
- 合成：連接層の射の合成。
- ファンクターの構成：ラグランジアン部分多様体から連接層への対応を定義する関手 𝐹: 𝓕(𝑋) → 𝐷ᵇ(𝒞𝑜ʰ(𝑌)) を構築する。
- 構造の保存：この関手が 𝐴∞ 構造や三角圏の構造を保存することを示す。
- 物理的対応：𝑋 上の 𝐴-モデルと 𝑌 上の 𝐵-モデルの物理的計算が一致することを利用。
- Gromov–Witten 不変量と周期：𝑋 の種数ゼロのグロモフ–ウィッテン不変量が、𝑌 上のホロモルフィック 3-形式の周期の計算と対応する。
5. 数学的厳密性：
- シンプレクティック幾何学の結果：ラグランジアン部分多様体のフロアーコホモロジーの性質を利用。
- 代数幾何学の結果：連接層の導来圏の性質、特にセール双対性やベクトル束の完全性を利用。
結論：
以上により、フクヤ圏と導来圏の間の同値性が確立され、ホモロジカル・ミラー対称性の定理が証明される。
ラグランジアン部分多様体 𝐿₀, 𝐿₁ に対し、フロアー境界演算子 ∂ を用いてコホモロジーを定義：
∂² = 0
𝐻𝐹*(𝐿₀, 𝐿₁) = ker ∂ / im ∂
∑ₖ₌₁ⁿ ∑ᵢ₌₁ⁿ₋ₖ₊₁ (-1)ᵉ 𝑚ₙ₋ₖ₊₁(𝑎₁, …, 𝑎ᵢ₋₁, 𝑚ₖ(𝑎ᵢ, …, 𝑎ᵢ₊ₖ₋₁), 𝑎ᵢ₊ₖ, …, 𝑎ₙ) = 0
Extⁱ(𝒜, 𝐵) ⊗ Extʲ(𝐵, 𝒞) → Extⁱ⁺ʲ(𝒜, 𝒞)
セルシスではプラグインSDKのダウンロード時に、使用許諾に合意する必要がある。
そして、その第4条には、プラグインSDKの再配布についての条項がある。
ざっくりいうと、「公式で審査の上で公開する以外の、勝手な再配布は認めない」というもの。
なので、プラグインSDKを利用しようとする以上、この規約には当然従う必要がある。
だが、青猫氏は審査前にGitHubで勝手にSDKを使った自作プラグインを公開してしまった。
それのみならず、「審査が通らなかったら、ソースコードとビルド用バッチファイルの形で非公式に配布する」と
https://x.com/aonekoss/status/1836418339729739860?s=61&t=w77c_83Mc7twk3hZpQ2ZPw
バッチファイルならプラグインとして完成していないとみなせるからOKだろう、という理屈と思われるが、
ということで、この件、AIとか反AIとか一切関係ない話である。セルシスの審査を待たずに公開し、
審査が通らなかったら非公式にばら撒くと宣言している青猫氏と、規約を守れと繰り返すセルシスの話だ。
昨年、一念発起して100kgの大台から70kgまで、30kgの減量に成功した。
やたらと知見を共有したがるのはエンジニアの美点の一つだが、私もその例にならい、ここにダイエット中に学んだことを共有しようと筆を執っている。
ダイエットとはそもそも、日常の食事のことを指し、それが転じて食習慣の適正化を意味するようになった。
減量の本質もそこにある。
人は食べたものからできている。食習慣を適正化すれば、自然と健康的になる。
30kgもの減量に成功した最大の要因は、自分がエンジニアであったことだと思う。
そもそもプログラミングとは、入力されたデータに対して任意の出力データを得るために加工する、その計算方法を設計し、実装することを指す。
料理もまた同じで、食材という入力に対して、調理を実施し、料理という出力を得る。
そのため、体重と食習慣の適正化というプロジェクトに対して、プロジェクトのマネジメント手法が応用可能なのだ。
メモリ4GBのオンボロPC抱えてパイプ椅子で開発すすめても、ろくに進捗しないのと同じだ。
ただし、闇雲に金をかければよいというものでもない。投資すべきものというのは、だいたい決まっている。
どれも無くても減量自体は可能なものばかりだが、あったほうが効率が良い。
そもそも減量はモチベーション管理のゲームなので、自動化、簡易化できるところはやったほうがいい。
金を払って健康を買っていると考えればよい。
まったくアーキテクチャを考えず、行き当たりばったりでファイルごとに違う設計のプロジェクトは悲惨な結果を招く。
最初にこのアーキテクチャで行くと決め、ひとまずはそれを続けることが大事だ。
減量で言えば、ローファットでいくかローカーボでいくかということだ。
日によって低脂質でいったり低糖質でいったりするのは全く良くない。
自分は低脂質でいくことにした。そのほうが筋肉量の減少を抑えられるし、コレステロール値の改善にも効果的だからだ。
金融系プロジェクトにありがちな細かすぎるコード規約は有害無益で時間と金の無駄だが、余りにフリーダムなのも混乱のもとである。
減量でいえば、目標カロリー量とPFCバランスだ。ここがいい加減だと、到底うまくいかない。
カロリー量はハリス・ベネディクト方程式から出される基礎代謝の1.5倍とかに設定すればよいだろう
そのうえで、低脂質ならP:30%, F:20%, C:50%のように割り振ろう。
たとえば1600kcal目標なら、P: 480kcal = 120g, F: 320kcal = 35g, C: 800kcal = 200g、といった感じだ。
この規約を守るためにも、あすげん/カロミルがあれば、計算が楽だったというわけだ。
プログラミングでは、実行時に行うと重すぎる計算はビルド時など事前に行ったりすることがある。
初代スーパーマリオブラザーズのジャンプは、1フレームごとに重力係数をかけて計算しているわけではなく、加速度がハードコードされている。
ブロック崩しでさえ物理演算するような現代においても、似たようなことをすることはある。
ダイエットで言えば、時間的余裕のあるタイミングで、できることをしておけということになる。
キャベツを千切りにしたり、きゅうりやトマトを切ったり、オートミールに材料混ぜておくことは事前にできることなのだ。
夜寝る前などにやっておき、明日の調理工数を最低限にしておくことが大事だ。
処理したものはジップロックコンテナにでも入れて、冷蔵庫にしまっておこう。
よく食べる鶏むね肉や牛もも肉なんかもキロ単位で大量買いして、1食量ごとに切り分け、ジップロックバッグに入れて冷凍庫に入れておこう。
適切なキャッシュがもたらす実行速度の向上効果は非常に大きい。
これは料理についても言える。
毎食ごとに献立を考え、材料を揃え、包丁で切ったり、コンロで焼いたり…などの調理を行うのは非常に非効率である。
いわば冷蔵庫はメモリキャッシュであり、冷凍庫はディスクキャッシュのようなものである。
よく1人分作るのも3人分作るのも変わらないよ〜などと言うが、同じ理屈で1食分作るのも、3食分作るのも、手間としてはたいして変わらない。
すでに広く使われ、実績のあるライブラリがあるのに、なぜ一から作らなければならないのか。
これはダイエットについても言える。
安価で大量に手に入るカット野菜などは、買ってしまえばいいのだ。
たとえばきんぴらごぼう。作ると面倒なきんぴらごぼうだけど、その面倒さの9割はごぼうを千切りするところにある。
千切りして水にさらし終わったら、きんぴらごぼうの調理工程の9割は終わっている。
しかもこの部分は、工数が量に依存しているため、大量作成の恩恵を受けづらい部分だ。O(n)である。
一方でカットごぼうを大量買いすれば、あとは炒めるだけなので量に依存せず、大量作成が容易になる。O(1)にすることができる。
他にも、オイコスヨーグルトとか、サラダチキンとか、Baseブレッドなどの外部サービスを使うのも良い。
プロジェクトの初期段階、リードエンジニアが重要なクラス群とサンプルとなるクラスをいくつか作った後は、それをひらすらに横展開していくことになる。
この段階では天才エンジニアなど必要なく、コピペマンでじゅうぶんになる。むしろ下手に独自の考えを持たず従順に開発してくれるぶん、そのほうが良いことさえある。
ダイエットについても同じことが言える。
なぜ毎食毎食、独自の健康メニューを考え出さないといけないのか。食事の都度、栄養成分を計算し、調整しなければならないのか。
あすけんで一度100点をとったらあとは、ひたすらそれをこすり続ければいいだろう。
朝
蒸しかぼちゃ
昼
ふかしたさつまいも
蒸しかぼちゃ
夜
りんご（皮ごと）
蒸しかぼちゃ
毎食似たようなものを食べていることがわかるだろう。
これは日単位でも同じで、別の日は牛もも肉が刺し身になったり、さつまいもが蕎麦になったりはするが、その程度の差だ。
どうしても違うものが食べたくなったら、そのときに改めて計算すれば良いのだ。
そうすれば手持ちのカードが増えていく。
インシデントが発生したとき、必要なのはリカバリーであって、そんな時に人を責めても何の役にも立たない。時間の無駄だし、士気も下がるだけだ
こうしたとき、自分を責めても仕方がない。自分をクビにはできないし、ダイエットは長期戦なのだ。
ある日に食べすぎたからと言って、次の日にその分を減らすと、必要な糖質や脂質が不足して代謝が落ちてしまったり、だるさが抜けなくなったりするため、そういう方向でのリカバリーはやめよう。
しっかりと痩せる食事スタイルが確立しているなら、それを続ければ良いだけだ。
どうせ1食程度ではそんなに太ることはできない。
計測は減量期間中だけでなく、むしろ減量終了後にこそ必要になる。
そもそも、減量前の食事が減量前の体重を作り上げてきたのだから、減量前の食事に戻せば、体重も戻るのは当然のこと。
もとの体重に戻りたくないなら、新たな食習慣を作り上げる必要がある。
プロダクトリリース後、つまり減量後の運用フェーズにうつったら、減量飯でもデブ飯でもない、心にも体にも良い食習慣へと移っていこう。
急激なUI変更がユーザーの反発を招くように、急激な食事変更は体重の反発（リバウンド）を招く。
そこで、オートミールだったところを玄米ごはんにするとか、ささみだったところを蒸し鶏にするとか、ちょっとずつ維持するためのご飯へと変えていき、どのくらいの量なら大丈夫なのかを見つつ、ソフトランディングしていこう。
