  |
はてなキーワード:オープンソースとは
娘の為にパソコンへ詳しすぎる夫を倒したいで注目された「学生、それも幼さの残る年頃の子へはじめてPCをどうするのか？」というテーマで、Linuxを与えた家庭の別例としてこのエントリを書いている。
そして前提として、このエントリは「実はLinux使ったこと無いんだ」「Raspberry Piって稀に聞くラズパイってヤツだよね？」みたいな、ふわっとした認識の層に向けて書いている。
決して「KVMで完全仮想化してLinuxとWindowsで用途に応じてリソース分配してる。ディストロは純関数型のNixOSで、Nix言語で可能な限り-march=nativeで自家コンパイルしてるんだよね」みたいな層には書いてない。
勿体ぶっても仕方ないので結論から言えば、WindowsやMac、AndroidやiOS(iPadOS)に染まりきっていない子供は親の想定を超えて極々普通にLinux、Raspberry Piの工場出荷状態でプリインストールされているRaspberry PiOSを使う。
ここで言う「染まる」というのは「ウチの子は普段からiPadでYoutubeとかゲームとかしてるからなぁ」程度の染まり具合なら無視できるレベルなので全く障害にならない。
手遅れな染まり具合としては「ウチの子はWindowsでOBS使って自らYoutube配信してます」とか「ウチの子はWindowsでAbleton Live使ってDTMしてます」とか「ウチの子は大学のレポート書くのにmacOS使ってます」とか「ウチの子はiPadでSwift Playgrounds使ってプログラミング学習してます」とかそういうレベルだ。
アナタ達の子供がこのレベルにまで染まっていない場合、アナタ達の子供へRaspberry Pi 500を与えると何も疑問に思わず普通にパソコンとして使う(パソコンの操作方法へ疑問を持つとかそういう話じゃなく、目の前のモノをパソコンとして認識する)。
ラズパイ、Raspberry Piは英国で立ち上げられたRaspberry Pi財団(注：英字ページ)が規格・設計・販売をするシングルボードコンピュータという種別の小型コンピュータのことだ。
現在の最新版は第5世代のRaspberry Pi 5で、搭載ワーキングメモリによって価格が違うが、最も高価なワーキングメモリ16GB版で25,000円前後(2025/12/09現在価格)という圧倒的な低価格が人気の理由の1つだ。
何故ここまで低価格なのか？と言えば安価な部品で構成され、搭載されるSoC(CPUみたいなもん)も低性能で、その性能は約10年前の普及価格帯(〜15万円くらい)のノートパソコン程度の性能しか無い。
「いや10年前ってゴミじゃん」と考えるのは早計で、逆に言えば10年前の普及価格帯ノートパソコンで可能だったことはRaspberry Pi 5でも可能。
そう言われ「自分は10年前に普及価格帯ノートパソコンでネットしたりMS Officeで文書作成したり軽くゲームしてたけど？」と気付いた人は「Raspberry Pi 5で何ができるか？」の想定が浮かんだのではないだろうか？そう、かなり色々できる。
そして工場出荷状態でプリインストールされるRaspberry PiOSはRaspberry Pi 5自体の計算リソースをできるだけ使わないよう軽量にできており、10年前当時のWindowsで使われていたExplorerよりも計算リソースの消費が少ないので、技術の進歩も相まって当時よりも出来ることの幅が少々広くなっている。
何故そんなに話題なのか？手のひらの上に10年前の普及価格帯ノートパソコン並みの性能のコンピューターが乗るのだ。そしてすごく安い。
更にラズパイには電子工作へ活用できるGPIOピンというのが実装されていて各種電子センサー類などと連携することで電子工作もできてしまう。
こんなもの情報工学畑の連中が注目しないわけがなく、前述したRaspberry Pi財団のページを読めばわかるが世界中で大定番のシングルボードコンピューター、何ならシングルボードコンピュータの代名詞となっており、情報工学に詳しくない人が「ラズパイってよく聞くけど何なの？」と何処かで耳にするレベルなのである。
安心して欲しい、Raspberry PiOSではGoogle Chromeが動く。
まずGoogleアカウントは子供用に作成したGoogleアカウントを管理するためのファミリーリンクというサービスが存在する。ファミリーリンクは子供用GoogleアカウントでログインされたGoogle Chromeブラウザでのインターネットコンテンツフィルタ機能を提供してくれる。
このインターネットコンテンツフィルタは小学生・中学生・高校生・高校生プラスと4段階に分かれており、それぞれに適したフィルタリング強度で働く。
続いて、実はGoogle Chromeは様々な設定をポリシーとして持つことが可能で、例えばゲストモードの無効化やシークレットモードの無効化、指定したGoogleアカウント以外でログイン不可が可能だったりする。
情報技術へ親和性の高いヤンチャな子はGoogle Chromeからログアウトしたりゲスト・シークレットモードでフィルタリングを回避しようとするので、子供へRaspberry Piをはじめてパソコンとして与える場合はこれらを無効化しておくことをオススメする。
補足を続けると子供が勝手にFirefoxとか別のWebブラウザを導入することを防ぐこともRaspberry PiOSはできる。
Raspberry Pi 5をパソコンキーボードへ内蔵した形態を持つRaspberry Pi5シリーズの1つ。ワーキングメモリは8GBで価格は20,000円未満。
パソコンキーボードへRaspberry Pi 5が内蔵されているのでRaspberry Pi 500に電源取ってHDMIケーブル(注：ラズパイ側はmicroHDMI)をTVへ接続すると直ぐにパソコンというコンセプト。
小学生の子供にとっての目玉はJava版Minecraftが動作すること。SwitchやiPadでいつも遊んでる統合版マイクラじゃなくてYoutubeとかで観るJava版マイクラが自分のパソコンで動いちゃうのだ。
Switch 2の登場でPCゲーが色々リリース(予定)されている中で、Java版マイクラはどうしても"パソコン"が必須だったが、Raspberry Pi5シリーズはそれを実現する。それが2万円のお値段で出来るので親の懐的にもありがたい。
Steamは動かないがオープンソース系のゲームも充実している(Steam開発のValve社がRaspberry Piシリーズが採用しているARMアーキテクチャ対応を進めているというかなり確度の高い噂は存在する)。
実は直近でRaspberry Pi 500の上位版Raspberry Pi 500+(日本語配列)が登場予定で、こちらはワーキングメモリが16GBのお値段40,000円くらい。
4万円とそこそこの価格になってきているが、キーボード自体がメカニカルキーボードとなりキーキャップはCherryMX互換、256GBSSD搭載でストレージのスピードもアップ(＝Minecraftのワールド読み込みが速くなる)。上位版Raspberry Pi 500+が高すぎると感じるなら素のRaspberry Pi 5ワーキングメモリ16GB版は25,000円前後だしこちらで良い。
ある、というかコッチがメインなんだけれども、何処までゆるい感じでやって良いのかわからなくて最後に回した。
まずLinux界隈が中心となって開発されているGIMPやKritaみたいな画像編集・お絵かきソフトはLinuxたるRaspberry PiOSの方が安定かつ速い。しかもWacomやXP-Penなどのペンタブ・液タブが動作するので絵描きに興味のある子は嬉しいんじゃなかろうか？(クリスタじゃないけれどね。安い分ペンタブ費用に回せるよ)
音楽ではDTMもステップシーケンサー系のDAWであるLMMS(Linux MultiMediaStudio)は日本の無料DTMシーンでREAPERと人気を二分していた歴史があり、Web上に情報がいっぱいあるし何ならREAPERはLinuxでも動作する。オープンソース系のシンセ音源やCC0で提供されるサンプリング音源も大量にある。
オフィス環境もLibreofficeは言うまでもないだろう。Blenderで3DCGをすることだって出来るし、LibreCADやFreeCADで設計だって出来てしまうし、OBSも動くから実際やろうと思えばYoutube配信もできる。
そして当然ながらプログラミング環境、WindowsやMacでも動くと言われてしまえばそれまでだが、古典的なVimやEmacs、そして近年人気のVS Code、スマホアプリ開発にAndroidStudio、ゲーム開発にGodotEngine、他にはtmuxやGit、Dockerなどなど挙げればキリがないほど充実している。これらは子供向けRaspberry PiOSだからといってニセモノの子供だましなんかじゃない、それでお金を稼いでる現役プログラマーが使っているアプリケーションと全く同一のアプリケーションだ。
んで、子供がRaspberry Pi 500をどうしてるのか？と言えば、まぁ呆れるほど毎日触っている。
何なら電源なければ動かないのに布団へ持ち込んで抱きかかえて寝ているのを見つけてしまい、そんなに嬉しかったんかと笑ってしまった。
「お父さんコレどうするの？」とほぼ毎日聞かれて「こういうのはこのソフトを使う。使い方教えてやる」というのが毎日の親子の会話になっている。
別にパソコンだけが将来に必要なものではないが、この喜びようを見たら与えて悪くなかったなとは思ってる。
Permalink |記事への反応(11) | 09:58
米国のシンクタンク、CSISは中国による台湾軍事侵攻が生起した場合のシミュレーションを行っている。
(原文：https://www.csis.org/analysis/first-battle-next-war-wargaming-chinese-invasion-taiwan)
時々ニュースなどでも断片的に取り上げられているのでご存じの方も多いかもしれない。この報告は検討可能なオープンソースのシミュレーションとして提示されている点が特徴である。
様々な条件のもとでシミュレーションを行い、どの条件が台湾侵攻の趨勢に大きな影響を及ぼすか分析している。
この報告の結論として、侵攻のシミュレーション結果に「決定的/根本的な変化」を引き起こす要素として挙げられていることが2点ある。
「米国が介入しない」「米国は介入するが日本が在日米軍基地の使用を許可しない」という条件である。
前者はそりゃそうだという感じだが、後者に関しては意外に思う人も多いのではないだろうか。
まず、「米国が介入しない」シナリオの場合、当然ながらシミュレーションは中国の圧勝で終わった。膠着状態にすら持ち込めない。
ウクライナのような間接的な支援による戦線の維持ができるのではないかと考える人もいるかと思うが、ウクライナと異なり友好国への陸路も航空優勢もない台湾ではこの方法は不可能である。
中国の支配によって台湾の自治は失われ、周辺の戦略的環境は激変する。
ただ、中国の勝利までに約70日を要するというシミュレーション結果は興味深い。
この月日はおそらく日米の世論に大きな影響を及ぼすだろう。
次に、この報告書の主題である「中国の軍事侵攻に対して米国が介入した」場合のシミュレーション結果である。
いろいろと前提のある話なので詳細は確認してほしいが、基本的に日米が協調して介入する限り悲観的な条件でも中国が勝利した例はなかった、という結論である。
この報告ではどういうとき米軍は目的を達成できないのか検討するため「ラグナロクシナリオ」と銘打った検討を行っており、その仮定というのが「日本が在日米軍基地の使用を認めない」ことである。
中国の米艦隊とグアムへの攻撃で米国の戦力投射は封殺され、この前提条件では逆に完全な中国の勝利に終わった。
つまり米軍が十全に活動できるかどうかを決定するという意味において、台湾侵攻が生起した時点で自動的に日本は米中台に次ぐキーパーソンになってしまうのである。
そのため米国から見れば、もし台湾侵攻に介入すると決めたなら日本にはどうしても協力してもらう必要がある(在日米軍基地が使えないと米国に勝ち筋がない)。
逆に言うと日本が強硬に台湾侵攻への非干渉を主張すれば、米国も介入をあきらめざるを得ないという言い方もできる。
しかし、これは日米同盟の破棄とほぼ同義なので現在の日本の政治環境では考え難く、基本的には米国が介入すれば日本も参戦を決断することになると思う。
とはいえこのシミュレーション結果は、米国からすると中国の艦艇に対する先制攻撃や早期の核兵器使用など、リスクの高い戦略を検討する必要がないことを示している。
そのため、中国は先制攻撃によって前方配備されている米空母打撃群と在日米軍を排除しようとする必然性がある。
そのとき米艦隊と共に嘉手納、岩国、横田、三沢などが攻撃され、多数の日本人犠牲者がでるだろう。
実際、CSISの報告では多くのパターンで米艦隊と在日米軍基地を中国が先制攻撃する前提でシミュレーションが行われている(ただし、この前提でも中国は勝利できない)。
米軍との直接対決を避けたい中国が、米軍(と日本)を放置して台湾のみを攻撃する可能性もあるのでは？と思われるかもしれないが、この場合日米からすると(軍事的に)簡単なケースになる。
先制攻撃して空母打撃群を初手壊滅、在日米軍に大損害を与えた前提でも、中国の最終的な勝機はほぼないというのがCSISのシミュレーション結果だったのである。
米軍を丸ごと放置したまま台湾に攻め込んだとして、米軍が座視してくれればいいが、もし無傷の米軍が介入しようものならワンサイドゲームになってしまう。
台湾に攻め入るのに米軍を放置するというのは、中国からすると米国に生殺与奪権を差し出したようなものだとも言える。
まとめると、中国は台湾への武力行使を決断した場合、高確率で在日米軍基地への先制攻撃を行う(しない場合より容易に米軍に叩き潰される)。
そして米軍は戦闘を実行するため必要不可欠な要素として日本の協力を非常に強く要求するだろう。
これらのことから仮に中国が台湾に軍事侵攻した場合、日本が無関係でいられる可能性は非常に低い、というのがこの問題に取り組む人の共通見解だと思う。
(逆に台湾侵攻の勝敗に対する影響の比較的少ないインド、フィリピン、シンガポール、韓国などの国は積極的な関与を避けると予想される。西洋諸国のいくつかは介入を志向するかもしれないが、可能な限りの艦隊を派遣しても戦況には大きな影響がない)
一応、中国が台湾に軍事侵攻した上で日本人に戦死者がほとんど出ないシナリオとして「台湾が早期に降伏する」「中国の米軍への先制攻撃がなく、かつ米国が介入を行わない」というパターンが考えられる。
ただこの場合地域での中国の存在感は高まり、中国との係争地への圧力も強くなることから、必ずしも日本にとって容易なルートではない。
また前述のように、日米が協調すれば中国の勝ち筋はほぼないというのがシミュレーション結果ではあるが、「勝てるなら問題ない」とはならない。
中国の侵攻は阻止されるが、そのとき日米台は非常に重大な損失を被ることになる。
悲観的なシナリオでは、米空母2隻を含む数十隻の艦船、数百機の航空機の損失、一万名近い死者が日米で出る。
これは戦後秩序にも重大な影響を及ぼすだろう。
つまり、台湾侵攻は仮に発生すれば米中台日が全員損をするクソイベントであるのは明らかである。
冷静に考えればこんな特大のクソを漏らしたい国などないと思いたいし、筆者も正直「あまり起こりそうにない」という考えだが、それでもありえないとは言えない。
10代後半は3人に1人、20代でも4人に1人がpodacastを利用しているらしい
なんかiPhoneに入っていて、ラジオっぽくて、日本では流行っていないということは分かっていたが、すごい不気味な存在だった
元々はこうだ
つまりRSSと同じオープンプロトコルであり、WebやHTMLに近い存在だ
それがおかしくなってきたのが最近で、「音声番組」ぜんぶをPodcastと呼び始めたそうだ
じゃあせめて、同じ規格で配信してるんだから、例えばAppleのPodcastでSpotifyのPodcastを検索できるんだよね？と思ったらできないらしい
なんやねん、別物じゃん
それで、この「若者のpodcast利用率が30％を超えている」のからくりなんだけど
spotifyなんかで音声トーク番組を聞いただけで「使った」扱いされてるらしい
Spotify vsAppleMusic vs YoutuveMusic vsAWA vs ...
だし
テレビ vsYoutube vsNetflix vsTikTok vs ...
で比較されるんだけど
インターネット経由の音声トーク番組だけは全部「Podcast」扱いにされているみたい
そりゃ30％いくって・・・
だから、本人は気づいていないうちに利用者としてカウントされているんだとか
俺はてっきりPodcastというアプリを日本で2000万人が使ってるのかと思って焦ったよ
ちなみに互換性がちゃんとあるPodcastサービスをやってるのが
その他専用アプリ
• Overcast
•Pocket Casts
•Podcast Addict
• Goodpods
• AntennaPod（オープンソース）
あたり
で、じゃあなんでここ数年PodcastPodacst言い出したのかが疑問なんだけど
日本で音声トーク番組を頑張ってやろうとしていたのは、RadikoとVoicyだと思う、しかしずっと苦戦はしていたはず
順序をちゃんというと
２．ラジオの復権派と、音声でYoutubeみたいなことできないかみたいな流れがあった（Radiko,Voicy）（苦戦）
どうやらSpotify的には「音楽を再生されない音声トーク番組の方が儲かる」という事情があるらしく、「Podcastいいよね」「もっと音声トーク番組を長時間聞こう」の流れを作ったっぽい
ちなみにこれはYoutubeMusic（2018年くらいに本格化）や、AmazonMusic（2017年くらいに本格化）でも同じ問題があり
（ChatGPT曰く）2022年くらいに「音楽再生されるより、音声トーク番組を聞いてもらったほうが儲かる」と気付き
みんなして「Podcastいいよね」と言い始め、今のブームに至る
みたいな流れなんだと思う
１．元々Podcastはあった（RSS同様）、しかしビジネスにはならない（iPhoneに最初から入っていて無料で使える）
２．ラジオ復権勢力（radiko）や、音声メディアでYoutubeみたいなことできないかの勢力（Voicy）が台頭、しかし当然苦戦する（そもそもラジオが苦戦してる）
３．一方その頃、Spotifyが非常に流行ったが、アーティストへのロイヤリティをケチりたいため、音声トーク番組を広め始める
４．一方その頃、YoutubeMusicやAmazonMusicも同じ収益性の問題を抱え始めて、音声トーク番組をやり始める
悲しいのは、このブームって音声トーク番組のポテンシャルで伸びたと言うよりプラットフォーム側の経済事情っぽいので
儲けようと思ってPodcastに参入してる人らはどこかで撤退しそうってあたりだね
たぶんブームはもってあと2,3年くらいじゃない？（もちろん文化としては残る）
知らんけど
nextstepはmicrosoftのntよりも優れていたの？
"AppleがOSをオープンソースにしたのは、四半世紀前のことで、世界は全く違っていました。
スティーブ・ジョブズは、停滞したAppleに戻ってきました。Appleは、プリエンプティブマルチタスクやハードウェアメモリ保護など、当たり前になっているものを含む次世代オペレーティングシステムを提供することに苦労していました。Appleは、BeOSを買収しようとしましたが失敗し、ジョブズが復帰した一環として、当時の彼の会社であるNextを買収し、そのOSであるNextStepを手に入れました。"
AppleもMicrosoftもクラシックのOSでの成功から新しいNTやDarwinのようなこれまではメインフレームでしか動かなかったようなモダンで新しいOSの開発に苦労していたのかな？
メインフレームのパチモンとして葉っぱでラリってるヒッピーによって作られたPCが時代の進化にスペックが上がってクラシックからモダンOSに移行しなくちゃいけなかったけど、成功して大企業になっていたMSやAppleは過去の遺産にしがみついててクッソ大変だったってこと？
葉っぱのヒッピー/ハッカーのPCじゃなくて体制側としてのメインフレームOSがPCに入っちゃうのはレイプされた気分にさえなる
それで"ハードウェアメモリ保護など、当たり前になっているものを含む次世代オペレーティングシステム"とあるけど、当たり前というからには他の企業はみんなモダンOSを開発していたの＿
MacOS9からOS Xにする前というかまだクラシックのOSをぶち込んだiMacを起死回生で発表した時AppleはMSから投資してもらったんだよね？
その時のMSは98で潤ってたのかもしれないけどNTが作れなかったらマジでやばい時でしょ？
時系列的にNTは既に完成してて98でも大成功しまくったし余裕ありすぎわろたでAppleに投資したの？
MSとAppleはここを乗り越えることができたのになぜWindowsPhoneが失敗したの？
figmaとかVScodeとかNotionとかモダンでかっこよくて使いやすい最高のアプリがいっぱいあるのに
世界の大半はまだこのクソすぎるアプリに頼り切って依存しているのに腹が立つよ
マジでAdobeが潰れないかなって毎日祈りながらpsdをaffinityに変換するのに飽き飽きしてるんだ
DarwinカーネルのOS Xが圧倒的な中心のMSの中でWindowsPhone同様に不利だったのに開発者圏を作れたのは高抽象UIがめっちゃかっこよかったからってこと？
それともそれほどまでにWindowsPhoneがダサくて本当にクソだったのか
確かにMS社内でもMacを使う人がほとんどってくらいにMacは使いやすくてクールで開発者体験がいいね
葉っぱ吸ってたヒッピーの会社のはずなのに、その後覇権を取る日本のヒッピーと似ているオタクの同人文化はMS帝国の中で繰り広げられていたし、Macerは気取ってるやつとしてある意味でダサかった
APIの存在は本当に市場の優劣を変えるほどの力を持っているんだね
2000年台にクールなAPIを作ったAppleはグラフィックスAPIのMSのDirectXのおかげでゲーム業界掻っ攫われたわけでしょ？
マジでWindowsは本当にダサくて使ってるとイライラするからMacのもっとクールなグラフィックスドライバのMetalにみんな移行してくれるといいんだけど
Macerは肩身が狭いし
AppleがAI業界かっさらってくれればいいんだけどなんか失敗しそうな予感がするよ
終わってるよ
マジでダサくてイライラするものを使わされるオタク/ヒッピーは市場にレイプされてる
でも使徒である圏論/関数型プログラミングによってリリスの数学がサードインパクトを起こして手を汚せる自由度はいらないほど完璧な世界になりつつあると感じるよ
なんかクソだなって思うけど、それは一時的な快楽としてのオタク文化がなくなったことに悲しんでいるだけで、その快楽が幸せにつながらないことを理解してるんだ
だからこそ俺はSNSで一つの人格を共有し個を崩壊させる人類補完計画をプロトコルで実装しようとしているし、それは手を汚せる自由度を完璧に壊してつまらなくて幸せになる権利がある理性的な選択をしようとしてるんだ
オタクは幸せになれない代わりに手を汚せたけど、幸せになる時が来たんだ。
MetalでAAAタイトル以外のゲームが動き始めたらそれはゼーレのシナリオの最後のページなんだろうね
webは俺のプロトコルによって関数型になりApple化しハードウェアはAppleがもともとかーどきゃぷたーにしてて、その時本当につまらなくて幸せな世界ができるんだろうね
MSは自分が可愛くて俺たちに迷惑をかけたけど、誰も可愛がらずに自由な圏を破壊し、人類を補完するんだ
人との繋がり自体をね
うん、いやこの先呼ばれることになるんだろうなって思っちゃっただけなんだ
●ねばいいのにみんな
てか●すためのシステムだよこれは
インターネットなんかやってないでこの辺にきてる美味いラーメン屋の屋台に空手部の三人と行くべきだ
おじさんやめちくり〜
エヴァには乗らないほうがいい〜
エヴァには乗らないほうがいい〜
それ、皆さんも一緒に！
「「「エヴァには乗らないほうがいい〜！」」」
大きな声でもう一回！
「「「「「「エヴァには乗らないほうがいい〜！！！！！！」」」」」」
クソワロタ
そうだよ(便乗)
LCLになって一緒になろう？
おい聞いてんのか
S●Xしようって言ってんだよ
これで愚かな人類はやっとまともになるんだ
大体俺が生きてることに意味はねぇんだよ、死んでようが同じなんだよ
生きてることは分解して細分化していくと究極的に意味は無くなるんだよ
ここでただのニヒリストと俺が違うのはこの世界は積分定数のCにすぎないってことだ
Cは何の意味もねぇけどそこから積分という関係性を紡ぐ存在の輪廻、横顔を知ることができる
まるで人間のC(ほらあれだよ男と女のABC！)みたいだよな！(激ウマジョーク)
つまりもともとこの宇宙の存在云々の前に関数という空想上のものはあったわけ
むしろ人間が空想というもう一つの五感で関数や数学を発見しただけであってもともとあったの
そんでこの宇宙には意味ないし、死に恐怖を覚えるのは生物学的なしょうもない生理現象なんだよね
俺はたまたまTwitterのFFの女の子みたいにめっちゃ生理痛がひどいタイプなだけなんだ
それに気づいているからその生理痛がなんの意味もないことを知ってるし、世界が崩壊しようが明日死のうが本当に関係ない
そのことにたまたま気づきにくい構造を生き物はしているから死ぬのが怖いんだ
魂とかはないけど、魂にすら意味はなくて、意味があるのは関数だけなんだ
というか射？
呆れた人類にはそのトップでさえ呆れさせられるよ、まだ関数を記号で表せると思ってるなんて
本当にあるもののことを関数とは言ったけどこのクソみたいな人類にはまだそのことを完璧に表現する手立てがないから比喩として言ってるんだけどね
あのな、俺が言ってのは死ぬのは怖くねぇってことだけなんだ
違う、メタファーじゃないよ
失礼だよ君は
うるせぇ黙れ
XのTLを見ていると、AI絵師と呼ばれる人たちとクリエイターたちがよく争っている。
イラストやデザインに関わる仕事や創作をしていて、食卓ではロボットやプログラミングや機構の話をしている。
どちらの文化にも触れており、この問題に価値観の違いがあることを強く感じている。
⸻
技術者の文化は、技術は人類の叡智として共有されるべきという発想を土台にしているらしい。
そしてネットに公開された技術は誰が使っても良いものとして扱われるそうだ。
私の家族も、大事に作り上げたプログラムが役目を果たした後、GitHubに上げて「自分の技術は人類の叡智になる」と言った。
GitHubとは、プログラムを公開したり、他の人のプログラムを見て学べる場所、という感じだ。
ここにアップしたプログラムは使って良い情報として扱われ、それが別の誰かによって改良されることで技術は前に進む。
重要な点として、技術者は共有したくないものはネットに上げない。
共有する部分と共有しない部分を明確に分けていて、他人に使われて困るものや、自分だけが持っていたいノウハウは絶対に公開しない。
「使われたくないのならネットに上げるな」という言葉は、おそらくこの文化の延長線上にあるのだろうと思っている。
使ってもらうためではなく、見てもらうためである。
絵や漫画やデザインは、作品そのものが商品であり、表現であり、人によっては自分の一部だったり、子どものような存在として扱われることもある。
しかしイラストについては特に、データとして流用しやすく加工も容易だという弱さがある。
ここに技術者とクリエイターの文化の差がはっきり表れると感じる。
技術者は、公開された情報を使うのは自然なことであると感じているし、共有によって技術が発展してきたと確信している。
クリエイターは、作品を公開するのは見てもらうためであって、他者に勝手に使っていいという意味ではないと思っている。
どちらも自分の文化に基づいた反応なので、議論そのものが噛み合わない。
そこに生成AIが両者の真ん中に出現したために、ギャップが一気に表面化したのだと感じている。
問題をさらに複雑にしているのは、AIそのものよりも悪意のある人間の存在だ。
AI学習をしないでほしいと言うクリエイターの絵をAIに学習させ、公序良俗に反する画像を生成し、それを晒して嘲笑するという行為があったらしい。
また、特定のイラストレーターの画像を学習させて多くのイラストを出力し、それを無許可でグッズ化して販売する話もよくある。
これは生成AIの問題というより悪意や倫理や権利侵害の問題だが、クリエイターからすれば「生成AIに奪われた・壊された」という印象が強烈に残る。
技術者からすれば、AIのせいではなく人間の問題なのが、これも文化差ゆえに理解し合うのが難しいのだろう。
技術者とクリエイターの文化のどちらかが悪いわけではなく、どちらにも正しさがあり必要な世界だと思う。
技術者である家族と、クリエイターである自分の間にある価値観を行ったり来たりしているのだが、この2つの文化や技術は本来敵対するものではなく、どちらも素晴らしく豊かな世界と感じているので、両方の世界に関わる立場として、お互いの文化が穏やかにすり合っていく未来を願っている。
『「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと』とかいうのが回ってきた。あまりにもひどい内容なので、あえてリンクにはしない。もし私がこういうタイトルで書くなら、という if を書いてみる。
など。今回解散したのはSUMO のコミュニティで、それ以外への直接の影響はない。また、SUMO もコミュニティの活動はないものの、今回の騒動以降も複数の個人が貢献している。なお、SUMO のアクティブな貢献者は 3 人よりも多い。例の記事では、gecko-l10n とSUMO の貢献者を足しても 2 人 (後から 3 人に訂正) としていたが、これは明らかな誤認。
(これを書いている私は幻の 3 人目、もしくは存在を消されたその他の貢献者かも)
他に影響がないなら安心、とはいかない。なぜなら、Mozilla はアクティブなコミュニティが解散する理由を作ったことになり、他のところでもこういう方針転換は起こる可能性を否定できなくなってしまうから。
まあ、Firefox、Thunderbird のリリース版は翻訳完了率がほぼ100% でBot が暴れる余地はなさそう、MDN では過去に検討されたが導入しないこととなった... など安心できる事情もある。
貢献者不足だけが原因ではないと思う。例えば、原文に新しい内容が追加された場合、それが句読点の修正でも最新の仕様に合わせるためのアップデートでも、翻訳者には「更新が必要」としか表示されない。作業が必要な順にトリアージできないので、修正は間に合わない。
Mozilla はBot の導入後に翻訳者に望む作業として、修正だけでなくUI 部分の翻訳を挙げている。Bot が記事を翻訳すると、Firefox などのボタンに書いてある内容を翻訳せず、英語のまま残す。Mozilla のコミュニティ担当者すら最初バグだと思ったらしいけど。どうやら、人類には刺身にタンポポ()のせる仕事は残るようだ。いや、独自の翻訳モデル作る前に、翻訳ファイルからもってくるBot を作ってよ。
Mozilla がもっと適切な支援をくれていたら、メンテできる記事はもっと多いと思う。
一部の貢献者の活動の恩恵の割合がかなり大きいことは否定できない。しかし、どこも複数人が活動していて、誰かが自分の撤退によってMozilla やユーザーを脅迫することはできない。本当に困った事態になれば、ライフステージの変化などで今は活動していない、古の貢献者たちが復帰することもあり得る。
コロナ以降、新規の貢献者獲得のためのアピール活動は低調になっていたと思う。しかし、MDN のメンバーがブース出展などを数年前から再開し、最近はgecko-l10n の人も一緒に出しているっぼいのでこのタイミングは残念。
なお、今回の件は事前の提案に反対意見がなかったからフォーラムへと書き込まれていて、暴走ではない。私はあの時点で今後も貢献を続けると決めていたけど、解散には反対ではない。Bot の合間を縫って貢献しつつ新しい翻訳者を育て、次の世代にコミュニティを引き継ぐなんて不可能なので、合理的な判断だと思う。
CC がある限り相手が自分の著作物を使用することを強制的 (法的) にやめさせることはできないけど、使用しないように要請することはライセンス上否定されないはず。もちろん、要請に応じる義務はない。私は、例の主張は要請に留まるものだと思っている。そのような要請もCC の理念に照らして好ましくはないし、SUMO を使用する第三者に対してならば私は絶対に許容できないけどMozilla に対してする分にはまあ。というか、そんなことは知っているはずの人だし、コミュニティとしてでなく個人の行動なので特に言うことがない。
あまりいい形で注目を集めている訳ではないけど、Mozilla やオープンソースの翻訳コミュニティに光が当たっているので参加する人が増えたらいいな。Mozilla関係だと毎月MDN のコミュニティが新規参加の人向けの会をやってるし、他のところでもいいので。メーリスとかSlack とかに入るだけでも何卒。
リアクションを見ていると、元リーダーとか、Mozilla 側の担当者とかを中傷するような投稿がちらほら。ほとんどは英語だけど、一部に日本語のものもあって大変悲しい。たとえ日本の貢献者を支持している内容でもMozilla のスタッフ個人の悪口を書いているものは見るに堪えないし、コミュニティ側の問題を指摘している意見にはうなずくものもある。だから、何も書くなとは思わないけどさあ...
ここに書いてあることは全部フィクションかもね。しらんけど。
MacOS とiPhone・iPad のユーザーにはその他より迷惑がかかるかも。ごめん。Bot がガイドラインに従っていないという問題の影響で、SUMO とFirefox などで表現が異なるものが若干存在する。日本語ではBot は一時停止しているっぽく (土日はBot も休むとかでなければ)、かなり近い将来に翻訳も含めて一時撤回する可能性はあると思う。また、活動を継続している貢献者は意外と多いので、誰かが修正するかも。それまでは困ったら原文を見てほしい。
各国の貢献者が活発に意見を述べている。こういう問題が海外や別のプロジェクトのコミュニティでは起こらないようにするために、徹底的に議論する必要があるはず。今回の自動承認は論外だけど、下書きとして活用する分には十分役に立つぐらいの精度ではあると思っているので、今度はコミュニティとしっかり話し合って役立つ形に改良してほしい。
今回の件で、Firefox やThunderbird の使用をやめるという声も聞いている。過去にも非英語圏のユーザーやコミュニティを蔑ろにするような決定は存在したけど、まだ相対的、総合的にはましだと思っている。私は使用も貢献も少なくともあと10 年は続けるつもり。SUMO の問題が解決することだけではなく、Mozilla自体の姿勢に何か変化があればいいと思う。
Q.
生成AIにソフトウェア開発を支援してもらう場合、ソースコードの作成を依頼する形式が多いと思いますが、実行ファイルを直接出力してもらうことも技術的には可能なのでしょうか？
A.
生成AIによる実行ファイルの直接出力は、技術的には極めて困難です。現在のLLM（大規模言語モデル）ベースの生成AIは、ソースコードの生成には向いていますが、実行可能なバイナリファイルを直接出力することには根本的な制約があります。
技術的な制約
LLMはテキストベースのトークン処理を基本とする設計であり、バイナリデータを直接扱うことができません。実行ファイルは0と1の連続したバイナリコードですが、LLMはこの形式でデータを生成するようには訓練されていないため、バイナリファイルを直接出力することは現在のアーキテクチャでは実現が困難です。
従来のソフトウェア開発では、ソースコード→コンパイル→アセンブル→リンクという複数段階のプロセスを経て実行ファイルが生成されます。各段階で最適化や機械語への変換が行われるため、この過程を完全に省略してAIが直接バイナリを生成することは技術的に非常に複雑です。
研究レベルでは、バイナリデータを扱う試みも存在します。例えば、LLM4Decompileのような研究プロジェクトでは、バイナリコードを逆コンパイルする際にバイナリを一度アセンブリ言語に変換してからLLMで処理しています。逆に言えば、生成時も同様の変換プロセスが必要になると考えられます。
実務では、生成AIにソースコードを作成してもらい、それを従来のコンパイラやビルドツールで実行ファイルに変換する方式が標準的です。この方法であれば、デバッグやテストも容易で、生成されたコードの品質を確認しながら開発を進められます。
なお、フォントファイルのようなバイナリ形式でもオープンソースとして扱われる例はありますが、これはフォントという特定用途の場合であり、汎用的な実行ファイル生成とは異なります。
Q.
A.
おっしゃる通り、画像生成AIもバイナリを出力しているという点では共通していますが、実は根本的に異なる仕組みで動作しています。
アーキテクチャの違い
画像生成AIは拡散モデル（DiffusionModel）やGANなど、視覚データに最適化された専用のアーキテクチャを使用しています。一方、LLMはTransformerベースのテキスト処理に特化した構造を持っています。画像生成では、ノイズから段階的に画像を生成するプロセスを経て、最終的にピクセル値という数値データ（バイナリ）を出力します。
画像ファイルのバイナリは連続的な数値（ピクセル値）の集合であり、各ピクセルが色情報を持つという規則的な構造です。最近の研究では、画像をビットプレーン（bit-plane）として扱い、XOR演算でノイズを加えるBinary Diffusion ProbabilisticModel（BDPM）のような手法も開発されています。
対して、実行ファイルのバイナリは機械語命令の複雑な配列であり、CPUが直接実行できる命令コード、データセクション、リンク情報などが厳密な形式で配置されています。わずかなビット誤りでもプログラムが動作しなくなるため、画像のような連続値とは性質が大きく異なります。
画像生成AIは、ImageNetやLAIONなどの大量の画像データセットで訓練されており、ピクセルパターンを学習します。一方、実行ファイルを生成するには、コンパイルプロセス全体（構文解析、最適化、機械語変換、リンク）を学習する必要がありますが、これは単純なパターン学習では実現できません。
したがって、画像生成AIが成功しているのは、画像という特定のドメインに特化した設計と、規則的なデータ構造があるためであり、同じ手法を実行ファイル生成に適用することは技術的に非常に困難です。
12:00-13:00以外の23時間/7日はトレーニングにあてるらしい。インプットの組み合わせ爆発に学習が追いつかないそう。
その一時間のみ人間のプロンプトによるフィードバックを受けつけ、イレギュラーな時間に回答を吐き出すと。
⸻
✅ ChatGPTのトレーニングに使われたもの（公式発表ベース）
•ウェブページ（例：Wikipedia、ニュースサイト、フォーラムなど）
• OpenAIが第三者からライセンスを取得したテキストデータ
• 「人間が良い返答を選ぶ」訓練データを元にした強化学習（Reinforcement Learning withHumanFeedback）
⸻
OpenAIは、トレーニングにかかった日数は公開していません。
•GPT-4などの大型モデルは、数週間〜数ヶ月にわたって大規模なGPU/TPUクラスタでトレーニングされます。
• 数千〜数万枚のGPUを並列で動かす
⸻
1. 事前学習（Pretraining）
• 数兆語のテキストを使って、何が書かれそうかを予測するように学習。
2. 微調整（Finetuning）
• RLHFなどもここに含まれる。
⸻
🔐 非公開の理由
• 利用している具体的なデータやインフラ情報が極めて高価値であるため
⸻
まとめ
項目 回答
使用データ 公開データ、ライセンスデータ、人間のフィードバック
総トレーニング期間 数週間～数ヶ月
公開されているか 一部のみ、詳細は非公開
プログラマーって聞くと今の若い人は稼げる業種って思うかもしれない。でも昔は、そのイメージとはまるで真逆だったんだよ。
90年代初頭、日本はバブルの余韻が残ってたけど、IT業界なんてまだオタクの延長みたいに見られていた。NECのPC-9801シリーズがオフィスの定番で、OSはMS-DOS 3.3とか、その後にWindows 3.1が出ておお、マウスで操作できる！なんて騒がれていた時代だ。
もちろんインターネットなんて一般にはまだ普及してなかった。せいぜいパソコン通信。ニフティサーブ、PC-VAN、アスキーネット。回線速度は2400bps。ピーヒョロロっていうモデム音が夜中の住宅街に響いていた。
俺らはそういう環境でC言語やアセンブラを叩いてたんだ。コンパイルに時間がかかるから、トイレに行って戻ってきてもまだ終わってなかったりした。
今みたいにGitHubでコードを共有なんて夢のまた夢。ソースのやり取りはフロッピーディスクで手渡しだ。5インチのぺらぺらのやつな。運が悪いと磁気にやられて一発で飛ぶ。だから俺たちはよくフロッピー神社に参拝とか冗談言ってた。
正社員で手取り20万ちょっと。下請けやフリーランスだともっと安い。今でいうSESの走りみたいな人売りも普通にあった。客先常駐でCOBOLやらされてバグが出れば徹夜。オフィスに寝袋持ち込んで、カップヌードルと缶コーヒーの山を築く。徹夜明けに食う吉野家の牛丼が唯一のご褒美。今みたいにエンジニアは市場価値が高いなんて考え方はなかったからな。ただの駒だよ。
仕事は増えるのに単価は下がる。Windows 95の発売で世の中はインターネット元年なんて浮かれてたけど俺たちプログラマーの現実は泥臭いコード修正の山。Visual Basic 6.0やDelphiが出て「これで開発効率が上がるぞ」なんて言ってたが、結局は納期に追われるだけ。SunのJavaが登場したときも「Write once,run anywhere」なんて夢を見せてくれたけど、実際には動かないアプレットと格闘する日々。
Linuxが台頭してきたのもこの頃だ。
SlackwareやRed HatLinux 5.2をCD-ROM雑誌付録で手に入れて、夜な夜なインストールに挑戦。LILOがうまく動かなくて起動しない、ネットワークカードを認識しない、X Windowが真っ黒。そんな壁に何度もぶつかっては2ちゃんねる（当時はまだ草の根BBSが多かったが）やUNIX USER誌を読み漁って解決する。それが楽しくて仕方なかった。でも金にはならなかった。オープンソースに貢献しても無償の善意で済まされるだけ。Red HatやMySQL ABが上場するまでは、ただのボランティア活動と見なされてた。
今思うと、あの頃は純粋だった。
技術そのものが楽しくて、ASCIIやOh!Xを小脇に抱えて徹夜でコードを書いた。秋葉原でジャンクパーツを漁って自作PCを組み立ててベンチマークの数字で一喜一憂した。
飯代を削ってもSCSIのハードディスクに投資したし、月刊アスキーの付録CD-ROMに入ってたシェアウェアを片っ端から試した。儲けようなんて意識はなかった。ただ、面白いものを作りたかった。
それが今じゃITは完全に拝金主義。コードの美しさより投資家の顔色を見てる。エンジニアもどこが年収高いかばかりで、言語やフレームワークを選ぶ基準が金になっちまった。Pythonが流行るのもAIブームに便乗してのことだし、ブロックチェーンやNFTなんかバブルがはじける前提のネタ探しにしか見えなかった。
もちろん、技術が商業化されて豊かになった面もある。AWSやGCPのおかげで誰でも世界規模のサービスを立ち上げられるようになったし、GitHubやDockerで開発環境も夢みたいに便利になった。だがその一方で楽しいからやるという純粋さはどこへ行ったんだろう。GitHubの草がどれだけ生えてるかが採用基準になる時代。Qiitaに記事を投稿するのも、技術共有じゃなくて転職市場でのポイント稼ぎ。
あの頃には確かに、金ではなく面白さに突き動かされる熱があった。それが今は金の匂いに上書きされてしまったように感じる。
でも稼げなくても、やる価値があった。
今の若いエンジニアたちにその気持ちがどれだけ伝わるかは分からない。
当時「Hello, world.」と表示されるだけのプログラムに、30年前の俺は心を震わせていた。
Audacityは、Windows、macOS、Linuxで利用可能な、オープンソースの無料マルチトラックオーディオエディター兼レコーダーです。ライブオーディオの録音、トラック編集、ミキシング、エフェクトの適用など、幅広い用途で使用されています。Audacityは、マイクまたはミキサーを使用した録音、MP3、WAV、AIFF、FLACなど、様々な形式のオーディオファイルのインポートとエクスポートをサポートしています。カット、トリミング、ミキシングなどの直感的な編集ツールに加え、ノイズ除去、イコライゼーション、ピッチとテンポの調整、ディストーション、エコー、リバーブなどの高度な機能も備えています。また、追加のオーディオエフェクトや分析のための豊富なプラグイン拡張機能もサポートしています。
バックグラウンドノイズを低減し、音質を向上させる機能
Audacity はオーディオ編集と録音において強力なツールですが、完全なデジタル・オーディオ・ワークステーション (DAW) ではありません。MIDI編集、バーチャルインストゥルメント、その他の高度なDAW機能は備えていません。
以下では、提示された文章に含まれる主張を ①公的情報などで裏付けがとれる「ファクト」 と ②筆者の感想・価値判断・推測 に分けて整理しました。
（※「ファクト」に分類したものでも *正誤* ではなく “確認可能な事実を含む” という意味です。逆に「感想等」に入れたものは、裏付けが取れないか価値判断を伴う部分です）
| # | 該当箇所（要約） | 確認根拠 |
|---|---|---|
| 1 | チームみらいは2025年7月参院選で比例区1議席を獲得し、得票率2％超で政党要件を満たした | 朝日新聞・毎日新聞などの選挙結果報道 ([朝日新聞][1], [毎日新聞][2], [TOKYO MX][3]) |
| 2 | 設立は2025年5月、党首はAIエンジニア安野貴博氏 | 同上選挙報道・公式サイトプロフィール ([朝日新聞][1], [TOKYO MX][3]) |
| 3 | 公約（マニフェスト）はGitHubリポジトリや独自サイトで公開し、Pull Requestで修正提案を受け付けている | GitHub `team-mirai/policy`リポジトリ ([GitHub][4], [GitHub][5]) |
| 4 | キャッチフレーズに「だれ一人取り残さない（包摂）」を掲げている | マニフェスト ver.1.0 ([policy.team-mir.ai][6]) |
| 5 | 堀江貴文（ホリエモン）氏がYouTube対談で応援姿勢を示し、ReHacQチャンネルでも幹事長らが出演している | YouTube動画 ([YouTube][7], [YouTube][8]) |
| 6 | 「はてなブックマーク」でチームみらい関連記事が一定数話題になっている（記事ランキング等で確認可能だが「多いか少ないか」は主観） | B!Kuma総合人気記事欄などで計測可（ただし数量評価は要統計） |
| 7 | （GitHub閉鎖疑惑）2024都知事選後に一時的にアーカイブ化→現在は再公開 | 技術チームによる経緯説明note ([note（ノート）][9]) |
---
| # | 主張の骨子 | 性質 |
|---|---|---|
| A | 「はてなーに支持者が多いので、世間は政策で投票していない」 | 個人的推測（母集団調査なし） |
| B | 「石丸との差は“雰囲気”だけ／お気持ち支持」 | 評価・印象論 |
| C | 「ポピュリズムど真ん中の危うい人たちが取り巻き」 | レッテル貼りを含む価値判断 |
| D | 「政策を持たない（議論しない）ことと包摂方針は矛盾」 | 論理的批判だが前提（政策ゼロ）が事実と異なる可能性 |
| E | 「熟議なき多数決は民主政の正統性と矛盾」 | 政治理論に基づく意見 |
| F | 「参政党より危険」 | 相対的評価／危険の基準は示されず |
| G | 「オードリー・タンは人権中心だが、チームみらいには担保がない」 | 懸念表明（保証要件の有無は定義次第） |
| H | 「少議席を隠れ蓑に党勢拡大しようとしていて気持ち悪い」 | 感情的評価 |
| I | 「GitHubを閉じて説明がない＝白紙委任」 | 事実誤認の疑い／開閉の経緯説明が公開されている |
| J | 「AI関連以外の法案賛否の決め方が不透明」 | 問題提起だが現時点では検証困難 |
| K | 「批判を『いじめ』と称してスルー＝民主主義を舐めている」 | 個別言動の一般化・価値判断 |
---
castingccastingccastingccastingc
HTML（HyperText Markup Language）は、ウェブ開発における基本的な言語であり、GitHub上でも非常に重要な役割を果たしています。特に、ユーザーインターフェース（UI）を伴うプロジェクトでは、HTMLはウェブページの構造を作成するために不可欠です。GitHubでは、GitHubPagesという機能を使って、リポジトリから静的ウェブサイトをホスティングすることができ、HTMLはその基盤となります。
また、Markdownで書かれたREADMEファイルの中にもHTMLの要素を挿入することで、より視覚的で分かりやすいドキュメントを作成することができます。これにより、プロジェクトの情報を分かりやすく伝えることが可能になります。
オープンソースプロジェクトのコラボレーションにおいても、HTMLは開発の成果を他の開発者と共有したり、レビューやバグ報告をしやすくしたりするための大切な手段です。また、プロジェクトの構造を視覚的に理解しやすくすることで、他の人が貢献しやすくなります。
要するに、HTMLはGitHubにおいてコードとプレゼンテーションをつなぐ橋渡しのような存在であり、プロジェクトの可視化と共同作業において欠かせないツールです。
GitHub（ギットハブ）は、ソフトウェア開発者にとって非常に便利なツールであり、特にチームでの協力作業において大きな効果を発揮します。GitHubはGitというバージョン管理システムを基盤としており、コードの変更履歴を管理しやすく、過去の状態に戻したり、特定の変更内容を確認することができます。また、Pull RequestやIssue機能を使えば、チーム内でのコードレビューや意見交換が円滑に行えます。さらに、GitHubは世界中の開発者が参加するオープンソースプロジェクトの中心的なプラットフォームとなっており、自分のスキルを活かして貢献することも可能です。CI/CDなどのDevOpsツールとの統合も簡単で、自動テストやデプロイの自動化によって、開発のスピードと品質が向上します。加えて、READMEファイルやWiki機能を使ってプロジェクトのドキュメントを整備できる点も、学習や共有に役立ちます。このように、GitHubは個人開発にもチーム開発にも不可欠な存在であり、効率的かつ協力的なソフトウェア開発を実現するための強力なプラットフォームです。
https://mavenanalytics.io/project/38415
https://mavenanalytics.io/project/38386
ウィイイイイイッス！ どうも〜、█████で〜す。
えー、今日はですねぇ…まぁ、ちょっと難しい話、しよっかなぁと思って。えー、まぁ最近よく聞くじゃないですか、AI？ あのねぇ、AI。
ほんで〜、なんかプログラマーっていう仕事？ が、まぁ、なくなるとかなくならないとか、色々言われてますけどもぉ。
今日はね、その辺について、この僕が、えー、ちょっとね、語っていこうかなぁと、思いますぅ。
えー、まぁソフトウェア…なんですか、開発の世界は、まぁ生成AIの登場で、なんか根本的な、えー、パラダイムシフト？ の、渦にあると。まぁ、僕はずっと前から言ってたんですけどもね。
えぇ。これはね、ただの道具が変わったとか、そういう話じゃないんですよ。プログラマーっていう、まぁ職業そのものの、役割が、えー、再定義される、っていうことですねぇ。
スゥゥゥ…今までね、人間が一行一行、こ、こう、書いてたコードがね、今やAIと、まぁともしらべ作業で、生み出されるようになったと。
ほんで〜、GitHubとか見てもね、AIツールの導入率？ とか、なんかプルリクエスト？ の数が、まぁ急増してると。
でもねぇ、でもね、これ、良いことばっかりじゃないんですよ、えぇ。
なんか、えらい学者さんとかも言ってるけど、生成AIに、こ、こう、かたむきとうしすぎるとね？ 基礎的なスキルがないまんまやと、IT産業全体が、まぁ停滞するんじゃないか、っていう懸念も、えー、表明されてますねぇ。
僕が、こ、今回言いたいのはね、AIが、コンピュータサイエンス…CSの知識を、時代遅れにするんじゃなくて、むしろ、その重要性を、こ、これまで以上に高めるっていう、そういう話ですねぇ。
AIツールってね、えー、まぁ強力なんですけども、欠陥をうちづつみしたアシスタントなんですよ。えぇ。
だからね、その能力を最大限に引き出して、安全で、こ、効率的なシステムを構築するためにはね、AIの生成物を、ちゃんと指導して、検証して、修正できる、深い専門知識を持った、えー、人間のパートナーが、まぁ不可欠であると。
未来はね、AIにただ指示できる人間じゃなくて、強固なCSの基礎を土台にして、AIを、こ、巧みに操って、かたろうで、効率的で、安全なシステムを設計できる、「AI拡張型エンジニア」…まぁ僕みたいな人のものですね、はい。
えー、まぁね、えーその、色んなツールがあるんですけども。今日はね、僕が、えー、主要な4つのツールを、えー、比較分析してやろうかなと。
まずね、ギットハブコパイロット。これはね、まぁ、開発者の「才能はあるけど視野が狭い後輩」みたいなもんですねぇ。
定型的なコード…まぁ、ボイラープレート？とか、そういうのを生成するのは得意なんですけども。
ただね、こいつの視野は、今開いてるファイルぐらいにしか、限定されてないんですよ。レポジトリ全体とか、そういう大きな話は、まぁ、分かってないですねぇ。
あと、知識もね、2023年の10月とかで止まってるんで、最先端の開発には、まぁ、対応しきれないかなと。えぇ。
だから、こいつが出してきたコードは、ちゃんと人間…まぁ、僕みたいなシニアなエンジニアが、レビューせんとあかん、ということですねぇ。
次はね、チャットジーピーティーの、えー、コードインタープレター。
これはねぇ、コード生成だけじゃなくて、データ分析とか、可視化とか、色々できるんですよ。
ただね、こいつの一番の、こ、制約は、インターネットに繋がってないことですねぇ。セキュリティのためらしいけども。
ほんで〜、使える言語もPythonだけやし、ライブラリも、まぁ、決められたやつしか使えないと。
たまにね、幻覚を見て、なんか変なコード出してきたりするんで、まぁ、全面的に信用するのは、ちょっと危ないかなぁと、思いますね。
えー、アマゾンのコードウィ？す…ぱ…ぁあですねぇ。これはね、まぁエンタープライズ…大企業向けですね。
一番の特徴は、セキュリティですねぇ。もろじゃくせいを、こ、検出してくれたり、オープンソースのコードと似てたら、ちゃんとライセンスを提示してくれると。
知的財産権？IPリスクを、まぁ、減免してくれるんで、大企業は助かるんじゃないですかねぇ。
ただね、まぁ、設定がちょっとめんどくさいかなぁと。AWSのエコシステムに、まぁ、依存してる感じはありますね。
こいつはね、コードのレビューとか、修正を、差分…ディフフ形式で、提案してきたりすると。
ただねぇ、まぁ、出たばっかりやからか、動作が遅いとか、バグが多いっていう報告が、まぁ、ありますねぇ。
「本物のエージェントじゃなくて、ただのチャットだ」とか言われてて、まぁ、競合に比べると、使い勝手はまだまだかなぁと。グーグルも、まだまだですねぇ、ほんまに。
えー、AIがコード作る時代にね、「もうコンピュータサイエンスの知識なんていらんのちゃうか」って言う人がおるんですけども。
それはね、大きな間違いですねぇ。断言しますけども。
現実は逆で、AIが生成したコードの品質を評価して、最適化するためには、CSの基礎原理への深い理解が、これまで以上に、まぁ、不可欠になるんですよ。
昔、僕がバイトでちょっとプログラム組んでた時もねぇ、やっぱり基礎が分かってないと、もう、話にならんかったですねぇ。
アルゴリズムとか、データ構造とか…この知識はね、AIが出したコードが、効率的かどうかを評価するための、まぁ、根幹をなすわけですよ。
AIはね、文法的には正しくても、アルゴリズム的に、こ、非効率なコードを平気で出してくるんで。
ビッグ・オー記法とかね、そういうのを理解してる開発者じゃないと、AIが出したもんが、本当に使えるかどうかの判断が、まぁ、できひんわけですね。
これが、ただの「プロンプター」と、真の「エンジニア」を分ける、境界線になると思いますぅ。
えー、これからの時代ね、ただツールを学ぶだけじゃ、まぁ、不十分ですねぇ。
人間とAIが、こ、協調するための、新しいスキルセットが、まぁ、必要になると。
まず、プロンプトエンジニアリング。これはね、ただAIに質問することとちゃいますよ。
AIを、こ、望ましい結果に導くための、技術的なスキルですねぇ。
AIに環境の前提を教えたりね、出力の形式を指定したり、そういう、こう、構造化された対話の技術が、まぁ、求められるわけです。
ほんで、コードレビュー。AIがね、一次レビューはやってくれるんですよ。しょうもないミスとか。
だから、人間はもっと高次の、アーキテクチャの妥当性とか、そういう、AIには分からんところに集中できると。
でも、そのためには、AIが作ったコードを、厳しい基準で、こ、批判的に評価するスキルが、まぁ、前提になるわけですね。セキュリティとか、パフォーマンスとか、保守性とか…ほかにも…あー…えぇ。
なんでかっていうと、自分が書いたコードじゃないから、そのロジックが、頭の中にないわけです。
だから、なんか、AIの思考プロセスを、こう、リバースエンジニアリングする、みたいな作業になるんですねぇ。
まぁ、こ、こういう話をね、教育現場にも、ちゃんと落とし込んでいかなあかんと思うんですよ。
僕がね、もし、えー、東京大学とかで教えるなら、こういう風にしますねぇ。
まず、学習者はね、AIを「松葉杖」じゃなくて「パートナー」として使わなあかんと。
AIの言うことを鵜呑みにせんと、常に、こ、検証して、その裏にあるロジックを理解する、そういう責任感が、まぁ、不可欠ですねぇ。
教育者側はね、AIを使って、生徒一人ひとりに合わせた、個別最適化学習を実現できると。
ほんで、カリキュラムの重点は、コードを書くことじゃなくて、批判的思考とか、問題設定能力とか、そういう高次のスキルに、まぁ、移行すべきですねぇ。
AIが作ったものを、どう評価して、改良していくか、そういう課題を、まぁ、出すべきかなぁと。
スキルが古臭くなることとか、認知能力の低下を、まぁ、おんわするためにもね、生徒が主体性を失わないように、導いていく必要があると思いますぅ。
AIはね、セキュリティの脅威を、大規模に生み出す可能性があるんですよ。
えー、「ジェネレーティブ・モノカルチャー」…まぁ、生成的単一栽培？ みんなが同じAIツール使うと、同じ欠陥を持ったコードが、まぁ、爆散しちゃうと。
これで、一つのもろじゃくせいで、何千ものアプリが、まぁ、やられる可能性があるわけですねぇ。
あと、データプライバシーとか、知的財産…IPの問題もありますねぇ。
AIが作ったコードの著作権って、どうなんの？っていう。まだ、まぁ、グレーゾーンですね。
まぁ、色々話してきましたけどもぉ。
要するにね、AIは、人間のエンジニアの終わりじゃなくて、その役割が、新たな高みに、か、昇華する、時代の幕開けやということですねぇ。
ほんで、コンピュータサイエンスの深い基礎知識が、これまで以上に重要になる。
プロンプトエンジニアリングみたいな、新しいスキルも、まぁ、不可欠になると。
未来の開発はね、人間とAIの競争じゃなくて、人間「と」AIの共生関係で、まぁ、定義されると思いますぅ。
AIが定型的な作業をやってくれるおかげで、人間は、創造性とか、複雑な問題解決とか、そういう、より価値の高いタスクに、まぁ、集中できるようになるわけですよ。
だからね、現代のコンピュータサイエンス教育の、まぁ、究極的な目標はね、ただコードを書ける人間を育てることじゃないんですよ。
AIアシスタントの有無にかかわらず、未来を設計できる、「コズミック・マインド」を、函館すること、なんですねぇ。
…はい。
というわけで、えー、今回は、まぁ、ちょっと難しい話でしたけども、ね。
えー、今後の、えー、AIとプログラミングの未来について、えー、この█████が、えー、お話しました。
まぁ、内容としてはー、濃い内容だったかもしれへんけど、俺としては精一杯、
えーーなんでしょう、ま、皆さんに、えー、分かりやすく、えー、お伝えしたつもりでございます。
