  |
はてなキーワード: Githubとは
エディタの乗り換えとか嫌じゃないんだろうか。
ちなみに自分はめちゃくちゃ嫌。
VSCodeに乗り換えるときもハードルあったし、Antigravityとかかなり似てるUIのやつをテーマも合わせて使ってみたけどほんのちょっとのサクサク感・UIのムニュムニュ感の違いとかが嫌すぎる。
慣れれば乗り換え前の方には戻れない状態になるんだけど、慣れるまでの不快感がすごく強い。
今年からGitHub CopilotとClaude Codeを併用できることになって、Claude CodeはCLIだからターミナルから使おうと思ってるんだけど、「今までVSCodeでやってきたことをターミナル上でやる」というのにハードルを感じて（見た目やちょっとした動きの違いで不快になるのが容易に想像できる）もう半月経ってしまった...
どこかで一念発起してがんばらないとなあ。はあ。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
---
https://anond.hatelabo.jp/20240722084249
人類の言語そのものを目的関数としてそれに対して最適化するのがLLMなのだから、人類の認知で到底不可能なことはやりようがないだろう。
一文で本質を突いている。AIの能力限界を構造的に説明している。
今よりもAIが進歩した未来では「自然言語で与えられた仕様から機械語を出力するように訓練されたAI」が出てくるかもしれないけど、そいつの内部をよく観察したら結局今日の高級言語みたいなもので思考していた、みたいなオチになるんじゃないんですかね
結論と完全に一致。内部に抽象化レイヤーが生まれるという洞察。
マシン語でエラーを吐き出されても、元となるプログラミング言語での設計がすっ飛ばされていたら、どこの何が問題なのかが照合困難で修正が困難なのが根幹な気がします。
検証・修正サイクルに意味の単位が必要という話を、実務的な観点から der 表現。
計算機科学について何一つ知らなかったとしても、ニーモニックを無作為に並べるよりソースからコンパイルした結果の方が解空間が圧倒的に小さいのだから、機械語の生成は AI 以前に単なる探索として悪手だ、というのが自然な発想だと思うんだけど。
探索空間という観点からの指摘。高級言語は制約を与えて解空間を狭める役割がある。
抽象化した方が簡潔に記述できるのはAIにとっても同じことで、そっちの方がAIも理解しやすいし、生成しやすい。現在の機械語、アセンブリ、高級言語の階層構造が崩れるとは思えない。
「AIにとっても同じ」という視点が正しい。人間向けとAI向けが乖離しないことを理解している。
「AIが直接機械語書けばプログラミング言語は要らないのでは？」的な話はみんな最初に頭を過るだろうけど、コードを出力するのがLarge "Language" Modelである以上は意味論から組み立てる高級言語の方がそりゃ相性いいでしょうね。
AIを何かgodlikeな超知性だと思っている人間が多いけど、人間にとって「機械語よりも高級言語の方が当然書きやすい」のと同様、AIにとっても「機械語よりも高級言語の方が当然書きやすい」よなぁという話
「AI向け言語は人間にも使いやすいはず」という結論と同じ方向。
CPUへの命令にまで細かく分解された機械語なんて、それが何をするための処理なのかはAI（LLM）でも大変だと思いますよ。そのCPUへの命令群で何をやろうとしているのかなんていう情報はほぼ捨て去っているわけなので。
機械語には意味がエンコードされていない、という議論の核心部分。
機械語派は抽象化の力を舐めすぎ。型なし言語はトークン削減量に対して失われる確定情報量が多すぎ。LLMが内部で型を推論したら本当にトークンが削減できるか怪しい。全能AIを仮定するなら、「人が作ったハード上で機械語を直接書く」なんて中途半端で「ハードごと最適化」くらいの夢を語ってほしい。
AIが機械語を直接書くようになるとか言っている人は、機械語にこそ真の価値があると思ってるんですかね？いかなる音声も元にせず、指示に従ってレコードに直接溝を刻んで音を鳴らす技術が広まれば、音楽がさらに発展するとでも思っているんでしょうか？
AI専用言語にせよ機械語を直接出力にせよ、人の持つ高レベルの意図や仕様、アルゴリズムを正しく反映したデータセット、意味構造が保存された対応データが存在しないから難しいというか現実的に無理よなぁ
学習データの観点から。意味構造が保存されたデータがないと学習できない。
「AI がマシン語を吐いたらプログラミング言語はいらない」系の話が出てくるのは「AIは人間の言葉より、機械の言葉の方が本当は理解しやすいはずだ」という思い込みから来ているのじゃないかと思っていて
誤解の根源を正確に特定している。
まず機械語を直接記述するメリットがない。現代コンパイラ、インタープリタは超優秀(OSや組み込みの一部だけ)。人類のプログラム資産は高級言語がほとんど。AIの学習先もそれ、よってAIは高級言語で出力するほうが成績が良い
AIが直接機械語を出力すべきか？という話題が流行っている。直感的には、動作中のAIの中身を調べると、結局はコンパイラやプログラミング言語に相当する構造が即席で構成されてそう。つまり同じことを高いコストでやる感じになり
内部に抽象化レイヤーが生まれるという洞察。mod_poppoさんと同じ結論。
意味推論がLLMの得意技なので、意味を削ぎ落とした本質の塊である機械語は理解できず、意味の羅列である高級言語こそがむしろ生成AIに最適化されている。
コンパイラって優秀だから、AIといえども生で機械語を読み書きするよりもコンパイラ介した方がいいと思うんだよな。そのくらいLLMって機械寄りじゃなくて人間寄りなんだと思う。元がニューロンの模倣だし。
高レベルになるとコンパイラの出力を疑って生成されたコードを読まないといけない状況は普通にあるので、高水準なAI生成のコードが何をやってるか理解するスキルは当面は必須だと思う
もし仮にAIが機械語を吐き出せるとしても、高速に、決定論的に、段階的に、最適に動作するコンパイラを使わず、低速で、確率論的で、逐次的で、最適な動作ができないAIを利用する意義はほぼないと思う
コンパイラとの比較で、AIに機械語を吐かせるメリットのなさを指摘。
機械語は冗長で複雑かつ非常に正確な出力が必要なので、高級言語を使って既存のコンパイラやビルドパイプラインに乗せる方がAIにとっても効率が圧倒的に良いと聞いて確かになぁと思いました。
自然言語を処理するのがLLMなので、不自然な機械語は難しいだろうね。1命令ごとに「それは何を目的とした操作か」とか文脈でわかりにくいしねぇ。
AI時代の人間の仕事は、信頼性確約（＝こういう理屈で大丈夫、と説明できること）が大きな領分を占めるだろうと推測されるので、機械語だけで良いとか言ってるやつは責任を取る気皆無なゴミ野郎です。
LLMに機械語を出力させようとするやつは「AIは機械なんだから機械語は簡単に扱える」という意味不明な思考をしてるだけなのでまともに取り扱うような相手ではない。名字が山口な人は長州方言が話せるんですよねとか言ってるくらい支離滅裂
人間がソフトウェアに「こう動いてほしい」という意図と「ソースコードがどのように変更されたか」の対応はGitHubとかに大量のデータがあるのでそれを学習すればコーディングするAIは作れる気がするけど、人間の意図と機械語の対応は学習データが全然ないからAI作れないように思う
「よく使うロジックを共通部品化する」とか「とはいえ局所最適な命令も欲しい」とかを考えると、中間言語を用意して最終的な機械語へコンパイルする、という流れは必要と思う。つまり、「AI用に最適化されたプログラミング言語」があるべき。
AIは人とのコミュニケーションをいかにスマートにするかにとんでもなく時間を掛けてきたわけで、人が直接読み書きできない機械語を出力しても意味がないよね。
AI機械語コーディング、やろうと思えばできるが普通はやらないような可読性の低いコーディング方法が多すぎて、AIﾁｬﾝに本気出されるとバグったときに修復不能になりそうな気がする
これだけAIが発展したならAIに直接機械語作らせればいいじゃんみたいな言説をたまに見るけど、それどうやって今のLLMと同じ水準まで学習するの？といつも思ってる
ロジックに従っているわけだから、ソースで想定外の挙動をした被疑箇所前後にロガーやらブレークポイントを仕込むという原始的だが確実なデバッグが、いきなり機械語を吐かれると出来ないんよ。
デバッグ実務の観点から。意味の単位がないとデバッグできない。
AIにしか読めない言語より、人類が発見的に設計したんじゃない人類にもAIにも優しいプログラミング言語・中間表現・機械語をデータドリブンに統計的に正しくAIが作るって方向に行かないですかね
AIが直接機械語吐くのは遠回りしてるだけだから無いとして、完全に人間がプログラムを読まなくなったらプログラミング言語はどう進化するのかは気になる
「無い」と断じた上で、次の問いを立てている。建設的。
プログラミング言語は人間の認知負荷、記憶量の限界、ミステイク、スパゲティコード理解できないためにあるので、AIだったら直接機械語吐くだろ。常考。
反論： 完全に逆。プログラミング言語は「人間の限界を補うため」ではなく「意味を構造として保持するため」にある。AIも意味を扱う以上、意味を表現する層が必要。「常考」と言いながら何も考えてない。
シンギュラリティ前夜 アダム（AI）が、人間には理解できないどころか、読むことすらできないコードを出力し始めた。後に判明することだが、それは機械語だった。
反論： SFポエム。「人間に読めない＝機械語」という発想が、まさに今回の議論で否定されてる誤解そのもの。AIが人間を超えるとしたら、ローレベルに降りるんじゃなくてハイレベルに登る方向。
なんかLLM界隈？では「AIがやがて機械語をだす（ので実用的にはコンピュータ言語は不要になる）」と言うと、無知だとか実情知らないとかブロックしてやるとか言われる見たいだけど。数年は無理だけど、いずれそうなると予想してる。
反論： 「数年は無理だけど、いずれそうなる」の根拠がゼロ。なぜそうなるのか、意味と機械語のギャップをどう埋めるのか、何も説明してない。批判されてる理由を理解してない。
プログラム言語って人間が扱うために自由度を削り取った結果の産物やから、AIに機械語で作ってもらって最適解であれば、現代の言語の宗教感ってほぼほぼ否定されるのです
反論： 「人間が扱うために」という前提が間違い。自由度を削ってるのは「意味を保持するため」。AIも意味を扱う以上、同じ制約を受ける。「宗教感」とか言って茶化してるけど、構造を理解してない。
「まだ」人間が安心する為では無いのですか？コンパイル後の機械語を読む人が殆ど居ない事は受け入れてるのに、将来的にAIが機械語出力する事に忌避感を感じるのは論理的とは言えません
反論： コンパイラの出力を読まないのは「コンパイラが検証済みだから」。AIの出力は検証が必要。この二つを同列に扱うのがおかしい。「論理的とは言えません」と言いながら、論理が破綻してる。
AIが機械語はけば、は数ヶ月前にメンバーと話になった。結論は、いまはあかんやろけど数年後に、もう人間が見る必要全然ないわ、となったらありうるな、となった。
反論： 「人間が見る必要がなくなったら」という仮定自体が検討されてない。人間が見なくていいとして、AIはどうやって検証・修正するの？意味の単位がない機械語で？その議論が抜けてる。
機械語って逆にトークン消費するの？お〜…じゃあLIFE3.0時代のAIは機械語ではなくAI用に最適化された人間には読めない言語で思考する、という方向性なのかな。
反論： 「人間には読めない言語」がなぜ生まれると思うのか。AIは人間の認知を模倣してるので、AIにとって扱いやすい言語は人間にも扱いやすい方向に収束する。逆方向には行かない。
中間言語不要派の言い分：AIが直接機械語を出力可能で、効率最適化が進む。人間の都合で言語が存在するが、AIなら移植性や抽象化不要で中間層をスキップできる。
反論： Grok自身が「中間言語不要派の言い分」として紹介してるけど、これ全部間違い。「人間の都合で言語が存在する」が誤り。意味を扱うために言語が存在する。AIも意味を扱う。
反論： 「うまくやってくれるかもしれん」で済む話じゃない。なぜうまくいくのか、検証・修正はどうするのか、何も考えてない。
反論： これは自虐なので反論というより…正直でよろしい。専門外だと自覚してるなら、なぜそう思ったのか掘り下げて、専門家の意見を聞く姿勢があれば良いと思う。
筋の悪い言説に共通するのは：
1. 「高級言語＝人間のため」という誤解 - 意味を扱うための構造だと理解してない
2. 「AIは機械だから機械語が得意」という誤解 - AIは人間の認知を模倣してると理解してない
3. 検証・修正の問題を無視 - 一発で完璧に動く前提になってる
東大卒で都知事選で得票数が暇空より多くて他の選挙で勝って本当に政治家になれてITリテラシーがあり年下なのに嫁がおり資産は暇空よりも上、もう完全に安野は暇空の敵
一時期暇空が山田太郎叩きしてたのも、安野が大学時代に山田の講義を受けていたと判明したのがきっかけだった
安野叩きが再燃しこれはもう止まらねえよ
暇空茜
@himasoraakane
安野たかひろの嫁のりなくろがなけなしの2000万円を突っ込んでくれたって言ってたのは完全な嘘ってこと？
暇空茜
@himasoraakane
暇空茜
@himasoraakane
安野たかひろ、動画でも確認したんだけど、寄付3000万あつまって自腹は2000万出してます、お金余裕あるんだねと言われて
暇空茜
@himasoraakane
安野たかひろの嫁、最低3.6億あるけど2000万をなけなしかのように装ったことを認め、しかも「別に総資産全額つっこんだとはいってませんw貯めてた金をつっこんだことは事実ですw草w」
まあ一生こいつを信頼することはないな
暇空茜
@himasoraakane
10億持ってる人（当時の時価総額は違うかも）が、それを隠して2000万円をつっこんだのを「ためてたお金全部」と言って寄付をつのるのはちょっと僕はナシと思うかなあ
安野たかひろさんが言うことを信じることは一生ありえないですね
暇空茜
@himasoraakane
安野たかひろがすごい！とかはひろゆきの嫁とかホリエモンとかうさんくせー奴らが言うけど、こいつらも信者も安野たかひろがどうしてすごいのかは説明してくれない
暇空茜
@himasoraakane
わかってないアホが意味不明な反論してくるんだけど、日本人は「嘘つきは泥棒の始まり」と躾けられて育つから嘘つきが嫌いなんだよ
暇空茜
@himasoraakane
問題とされてるのは、安野たかひろ夫婦が、貯めてた金2000万全部突っ込みました！寄付してください！と詐欺的な表現、普通に嘘としか思えないことを言ってたことだとわからないわけないですよね？それってあなたの感想ですよね？
暇空茜
@himasoraakane
安野たかひろはカップラーメンを忙しいから食ってるそうですが、両手が塞がるし汁が飛び散るし栄養も味も良くないカップラーメンとかアホかね？
暇空茜
@himasoraakane
安野たかひろ「貯めていた2000万円全部出しました！選挙のために寄付してください！」安野たかひろ「資産3.6億円+α」嘘つきでは？ @YouTube
より
暇空茜
@himasoraakane
トピックみたいなのも小さくなってたよね…😟
最近、トレンドに上がるのAI関係ばかりすぎて、ちょっと辟易してたんだけど、
自分もあんまりソフトウェアとかコンピュータへの興味が薄れてきてしまって、
というか、当たり前だけど、コンピュータはあくまで道具であるわけで、
まあ、手段を目的にするというか、道具を目的にする、道具を洗練させる、みたいなアプローチも間違ってはいないんだけどさあ…😟
要は、コンピュータであれ、他の道具であれ、その道具を使って、本当にあなたの生活が豊かになりましたか？というのが重要なんであって…😟
この辺で、これまでの経験とか、わずかであれ知識とか、近年のAIとか技術とか社会的な流れとか、
そういうのを総動員して、何か良い方向というか、良い結果を出したいところである…😟
死ぬ前にできることはやっておきたい…😟
https://x.com/i/status/1983745679433269398
このCMへ対して一部のユーザーが「M.U.G.E.Nじゃねぇかｗ」の様なコメントを付けている。
この「M.U.G.E.N」こそが格ゲー界の公然の秘密である。
M.U.G.E.Nとは、1999年にElecbyte社が公開した、ユーザー拡張型の2D格闘ゲームエンジンだ。「キャラクターやステージを自由に自作して追加できる」という画期的な仕様により、本来なら交わるはずのない別作品のキャラ同士を戦わせる「ドリームマッチ」を実現できるツールとして、2000年代のネットの片隅で熱狂的な支持を集めた。
だが、このエンジンには致命的な「暗部」がある。
全盛期に最も広く利用された「WinMugen」と呼ばれるバージョンは、実は正規にリリースされたソフトウェアではない。
開発元のElecbyte社が一度消息を絶つ直前に、本来は非公開だった次期バージョン（Mugen 1.0）のベータ版が何者かによってリークされ、それがアングラサイト経由で広まったものなのだ。つまり、WinMugenを使っている時点で、それは「流出した未完成の開発データ」を勝手に使っている状態に他ならなかった。
正直に申し上げて、M.U.G.E.Nというコミュニティは、このエンジンの出自も含め、著作権的に見れば限りなく真っ黒に近いグレーだ。
「キャラクターやステージを自由に自作して追加できる」という画期的な仕様は、実質的に「既存の商用格闘ゲームのキャラクターをファンメイドで移植できる」環境を意味していた。
つまり、スプライトのぶっこ抜きである。この事実は否定しようがない。
だからこそ、格闘ゲームのプロプレイヤーや開発者、そして我々のようなコアな格ゲーマーにとって、M.U.G.E.Nは長らく「名前を言ってはいけないあの人」のような存在だった。
みんな知っている。家でこっそり触ったこともある。でも、表立って「M.U.G.E.Nで遊んでいます」とは口が裂けても言えない。そういう「公然の秘密」として、格闘ゲーム史の影に存在し続けてきた。
けれど、あえて今、その「技術的・文化的な功績」についてだけは語らせてほしい。
法的な問題を一旦脇に置いて（肯定するわけではないが）、なぜあそこにあれほどの熱量が生まれたのかを言語化するならば、「あれはプログラムによる同人活動だったから」という結論に行き着く。「絵」ではなく「挙動」を模写するのだ。
同人作家が、好きな漫画のキャラクターを愛ゆえに模写し、自分の手で二次創作漫画、そこから更に発展してBL同人などを描くようにだ。
M.U.G.E.N職人と呼ばれた人たちは、好きな格闘ゲームのキャラクターを愛ゆえに解析し、自分の手で動かそうとしていた。
彼らにとって、リュウの波動拳やテリーのパワーウェイブのドット絵は、単なる画像素材ではない。「完成された美」であり「憧れ」そのものだ。
しかし、画像をM.U.G.E.Nに持ってきただけでは、それは動かない。
憧れのあの技を放つためには、中身のエンジン……つまりプログラムを、自分たちの手で一から組み上げる必要があった。
彼らがやっていたのは、MS-DOS時代から続く古臭い仕様のスクリプト言語を駆使して、最新ゲームの挙動を「コードで模写する」という作業だった。
これは、プログラマーやゲームデザイナーにとっての一種の「写経」であり、エンジニアリングの側面から愛を表現する手段だったのだと思う。
さらに特筆すべきは、単なる模倣に留まらない「実験場」としての側面だ。
M.U.G.E.N界隈には、既存の格闘ゲームの枠組みには収まりきらないアイデアを形にするクリエイターたちもいた。
ドット絵からアニメーションまで全てを一から描き起こした「完全新規オリジナルキャラクター」の制作。あるいは、商業ゲームならバランス崩壊として即座にボツになるような、複雑怪奇かつ斬新なシステムの実装。
「売れるかどうか」を考える必要がない同人活動だからこそ、そこには尖ったアイデアが無数に投入されていた。
プレイヤーが操作することを放棄し、キャラクターに搭載されたAI（人工知能スクリプト）同士を戦わせる。
そこでは「いかに強いAIを書くか」というプログラミング競争が勃発し、時にはゲームのプログラム仕様の隙を突くような「凶悪キャラ」「神キャラ」と呼ばれる人知を超えた存在が生み出された。
そして、それらが公平に戦えるよう、有志によって厳格なレギュレーション（階級分け）が整備され、毎日のように動画サイトで大会が開かれる。
これは、ある種の「レジェンド級プロ格ゲーマーを超えた理論値格ゲープレイのシミュレーション」であり、eスポーツとは全く異なるベクトルでの技術的進化だったと言える。
現在では将棋や囲碁などのAI同士が対戦し、その強さを競うことは珍しくないがM.U.G.E.N界隈ではそれらよりもずっと前に対戦AIを専門的に書く人たちが認知されていたのだ。
漫画界で「同人出身」がある種の実力の証明(例えば高い評価を受けていた同人作家が商業誌での新連載が決まり、同人作品を知る一部界隈で話題)になるように、実はゲーム業界にも「M.U.G.E.N出身」の才能が確実に存在する。
例えば、Steamで世界的な評価を得た2D格闘ゲーム『Skullgirls』や『Indivisible』でリード・アニメーターを務め、『熱血硬派くにおくん外伝 リバーシティガールズ』にも関わったJonathan "Persona" Kim氏は、かつてM.U.G.E.N界隈で伝説的なスプライト改変職人として知られた人物だ。
また、セガ公式の『Sonic Mania』でコンポーザーを務めたTee Lopes氏も、キャリアの初期にはM.U.G.E.N等のファンゲームへの楽曲提供で腕を磨いていた。
最近の例では、ホロライブのファンメイド格闘ゲーム『Idol Showdown』が記憶に新しい。
このゲーム自体はUnity製だが、プロジェクトを牽引したGura_D氏や、美麗なドット絵を統括したアートリードのSodan氏は、海外のハイレベルなM.U.G.E.Nプロジェクト（Hyper Dragon Ball Zなど）出身のベテランだ。
彼らにとってM.U.G.E.Nは、GitHubやUnityが普及する前の時代における、ポートフォリオであり実験場だったのだ。
もっとも、彼らのように自らそれを語り、その出自が明るみに出ることは業界の慣習としては稀なケースなのかもしれない。
プロ格ゲーマーを含めた多くのプロフェッショナルたちが、過去の経歴としてM.U.G.E.Nを語ることはない。そこには、あえて触れないという「暗黙の了解」が、今も静かに横たわっている。
「俺ならもっとこう動かす」「もしもこのキャラとあのキャラが戦ったら」という妄想（IF）を、絵や文章ではなく、実際に動くゲームシステムとして出力する。
それは紛れもなく「挙動の二次創作」と呼べるものだったはずだ。
現在はYoutubeなどのSNSを通して格ゲー界のプロフェッショナルへ気軽に話しかけられるようになったが決してM.U.G.E.Nの話を振ってはいけない。無視されるか立場上、表面上、便宜上M.U.G.E.Nを否定する発言しかしないだろう。
二次創作の経歴がある人へ「盗作ってどう感じますか？」と質問しても多くは「悪いことだと思う」と返すしか無いはずなのだから。
現在は、Ikemen GOのようなMITライセンスのオープンソースエンジンが登場し、エンジンの権利問題はクリアになった。Steamでは『The Black Heart』のように、この系譜から生まれたインディー格闘ゲームが正規に販売され始めている。
かつてのM.U.G.E.Nが抱えていた著作権侵害の罪は消えない。
しかし、「憧れのキャラを自分の手で動かしたい」というあの熱量と、そこで培われた技術的土壌までを「黒歴史」として封印してしまうのは、あまりに惜しい。
あれは無法地帯だったかもしれないが、同時に、間違いなく数多くのクリエイターを育てた、一つの巨大な「同人界隈」でもあったのだ。
Gemini Deep Researchで本当の話なのか調査させ、はてな匿名ダイアリーへ投稿出来るように要約させた
はてな匿名ダイアリーを指定したら口調が勝手に変わって吹いたｗ
2025年末、「娘のはじめてPCにLinux」という議論がネット上で波紋を呼んだ。これは単なるOSオタクの戯言ではない。 「エリート層は子供にRaspberry Pi（ラズベリーパイ）を与えて"支配側"へ育て、一般家庭や公教育はiPadを与えて"消費側"に留め置く」という、現代の身分制度（デジタル階級社会）への警告だ。
本稿は、英国王立協会やGIGAスクール構想の実態、労働市場データを分析した「公教育の機能不全と家庭内資源動員に関する調査報告書」の要約である。 結論から言えば、「中流以下の家庭こそ、なけなしの金を払ってでも子供にLinuxを触らせろ」ということになる。
かつてのデジタルデバイドは「ネットに繋がるか否か」だった。スマホ普及後の現代における格差は、「コンピュータの制御権（Root権限）を持っているか否か」である。
英国王立協会はすでに2012年の段階で「学校のICT教育はオフィスソフトの使い方しか教えていない」と酷評している。 その結果、富裕層の私立校では専門家を雇ってRaspberry PiやAI活用を教え、貧困地域の公立校では管理が楽なiPadを配って終わり、という絶望的な「質の乖離」が起きている。米国でも同様に、富裕層の子供ほど「消費的なスクリーン（TikTokやYouTube）」から離れ、ChromeOSやRaspberry PiやUbuntuなどを導入し創造的なプログラミング教育を受けている。
日本の金のある自治体の公立小中学校で配られたiPadは、MDM（管理ツール）によってガチガチに制限されている。 逆に、ChromeOSはLinuxベースであり開発環境として優秀なのだが、教育委員会は「セキュリティ」と「管理コスト」を理由にその扉（ChromeOSやLinuxでの創造的な授業）を諦めた。 結果、公立校の生徒はiPadで「Web閲覧」と「ドリルアプリ」しかできない。
一方で、開成や筑駒といったエリート校の生徒は、制限のない環境でサーバーを構築し、Unityでゲームを作り、競技プログラミングに没頭している。iPadの 「サンドボックス（砂場）」の中で遊ばされている公立校生と、システムの内側に触れているエリート校生。このスタート地点の差は、10年後に致命的な「年収の差」となって現れる。
「社会に出ればWindowsだろ？」というのは20年前の常識だ。 現代の高付加価値インフラ（AWS、Google Cloud、AI開発、IoT）は、ほぼ全てLinuxで動いている。
GUI（マウス操作）はAIにとってコストが高いが、CLI（コマンド操作）はAIへの命令（プロンプト）そのものであるため、相性が抜群に良い。 Linuxを学ぶことは、「AI時代におけるコンピュータへの正しい命令作法」を学ぶことと同義だ。
「MOS(Microsoft Office Specialist)」というフィルター機能は低下し、GithubやPixiv、Youtubeなどでのクリエイティブな活動履歴（何を作れるか）がパスポートになる。貧困・中流層がこの壁を越える唯一の武器が「技術力（ポートフォリオ）」だ。
中流以下の公教育が頼りにならない以上、家庭で動くしかない。幸い、Linuxの世界は「金はかからないが、知恵と時間はかかる」。これは資金力のない家庭にとって最大の勝機だ。
30万円のMacBookは不要。企業落ちの中古ビジネスPC（ThinkPad X250/X260等）なら、秋葉原や通販で1.5万〜3万円で買える。 Windows 11が入らない型落ちこそ、軽量なLinuxには最高の機体だ。Raspberry Pi 4や400の中古も良い選択肢となる。
親が教えられないなら、CoderDojo（無料のプログラミング道場）のようなコミュニティに子供を連れて行けばいい。そこには「技術を楽しんでいる変な大人」がいる。その出会いが重要だ。
「壊れるから触るな」ではなく、「壊してもOSを入れ直せば直るから、好きにいじれ」と言って管理者権限（Sudo）を与えること。 YouTubeを見る端末を、YouTubeを作る端末に変えること。
高価なiPadを買い与えて安心するのではなく、1万円の中古PCを与えて「黒い画面」に向かう子供を応援すること。 その小さな投資が、子供を「デジタル小作人」から救う唯一の手段になるかもしれない。
picetableという名前ではなく、RopeとかSumTreeという名前になってるけどな…。
https://github.com/oonyanya/FooList/tree/main
こっちはBigList.csあたり読めば元となったであろう論文が出てくるし、
https://tadaoyamaoka.hatenablog.com/entry/2019/08/18/154610
https://x.com/i/status/1995357685395652652
ただ、誰もgistやstack overflow には書いてないし、aiは大昔に書かれた本の内容なんて知りもしない。
だから、gistとstack overflow、一部のgithubからしか学習できないAIには早いコードは書けないし、それこそが、ちゃんと英語と数学を勉強したITエンジニアが死なない理由の一つでもある。
（マイナーなアルゴリズムやデーター構造は基本的に英語での解説がメインなんで、高校の英語のリーディングがある程度できるまではやらんとダメなのよ。ものによっては数学の知識もいるので、高校の数学は全部取ったほうがいい。受験数学の難しい奴は知らなくても支障はないと思うが、もしかしたら、使うかも）
あと、.netだから重いというのは半分当たっていて半分は間違い。
ただ、.netだと油断するとコピーしまくりなせいでメモリー使用量が増えるという側面はあるし、regexにイテレーターすら突っ込めないんで、巨大ファイルの改行またぎの検索が苦手という側面がある。
最近の.netだとspanに検索かけられるけど、あまり大きなspanだとlohの問題とか色々出てくるし…
これさ
愚かな人間の都合など完全無視、LLMのための高効率プログラミング言語「Sui」（粋）
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
別にいいんだけど、どうにもブクマカ含めて、しっくり来る批判できてないんだよな
それが気になってしょうがない
俺ごときが言ってもアレだから、Gemini3.0先生に頼んだよ（一時チャット、Pro 3.0 思考モード）
ユーザーが提供した情報と、一般的なLLMの技術特性に基づき、プログラミング言語「Sui」についての冷静かつ客観的な評価をまとめます。
感想: 一言で言えば、**「思想実験としては極めて面白いが、実用性とLLMの学習原理を無視した『早すぎた最適化』」**です。
作者の「人間ではなくLLMを主客にする」という視点の転換は、アーティスト的・哲学的な問題提起としては鋭いですが、現在のLLM（Transformerアーキテクチャ）の動作原理を工学的に捉えると、メリットよりもデメリットが上回る可能性が高いです。
メリット:
・トークン効率の改善: Python等と比較して記述が圧倒的に短くなるため、出力速度の向上と課金コストの削減（トークン節約）は確実に達成できます。
・構文エラーの激減: 括弧やインデントの複雑なルールを排除しているため、「閉じ忘れ」などの単純なSyntax Errorは減るでしょう。
・コンテキストウィンドウの節約: 長いプログラムでもコンテキスト（メモリ）を圧迫しにくくなります。
・学習データとの不一致: LLMは「大量の人間用コード（Pythonなど）」を学習して賢くなっています。未知の言語「Sui」を書かせるには、Few-shot（プロンプトでの例示）に頼るしかありませんが、これではLLM本来の推論能力やコーディング能力（事前学習の重み）を活かせません。
・ブラックボックス化: 生成されたコードがバグっていた場合、人間が読んで直すことが不可能です。「LLMに直させる」にしても、LLM自身がSuiのロジックを深く理解していないため、無限ループ（幻覚の連鎖）に陥るリスクが高いです。
・CoT（Chain of Thought）の阻害: 最近の研究では、LLMは「冗長な思考過程」を出力することで論理的整合性を保つことがわかっています。極限まで圧縮された記号列は、LLMの「考える余地」を奪い、論理破綻を招く可能性があります。
正しいと思う所（Agree）
理由: 人間にとっての「読みやすさ（可読性）」は、機械にとって単なるトークンの無駄遣いです。if x > 10: よりも ? x 10 の方が情報密度が高いのは事実です。
理由: TransformerのAttentionメカニズムにとって、遠く離れた ( と ) の対応関係を維持するのは計算コストが高く、ミスの原因になりやすいです。ネストを排除する方向性は機械的処理として正しいです。
正しくないと思う所（Disagree）
・「可読性を排除しても良い」:
理由: ソフトウェア開発においてコーディングは「書く」時間より「読む・直す」時間の方が長いです。AI生成コードであっても、最終責任は人間が負う現状では、人間が検証不可能なコードは「危険なバイナリ」と同義であり、プロダクトには採用できません。
理由: 前述の通り、現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。Suiは「計算機にとっては最適」ですが、「現在のLLMにとっては異言語」です。
パース（解析）は容易になりますが、LLMは「前の行の文脈」を読んで次の行を出力するため、行を独立させすぎると文脈の連続性が失われ、複雑なアルゴリズムの構成力が落ちる可能性があります。
LLMが最も苦手とする「深いネスト構造の維持」を回避する策として有効です。アセンブリ言語に近いフラットな構造は生成難易度を下げます。
これが最大の問題点です。LLMは変数名（user_id, total_price など）に含まれる「意味」を使って推論を行っています（Semantic Grounding）。すべてを記号化すると、LLMは変数の役割を見失い、論理的なバグを埋め込みやすくなります。
トークン効率は最強ですが、1文字の違いで意味が激変するため、LLMの確率的な「ゆらぎ」による1文字ミスが致命的なバグになります。冗長さはエラー訂正の役割も果たしています。
goto 文の多用はスパゲッティコードを生みます。LLMにとっても、構造化プログラミング（if/forブロック）の方が、「ここからここまでがループ」というチャンク（塊）として認識しやすいため、一概にジャンプ命令が良いとは言えません。
＞現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。
ここ！マジで覚えてね
LLMはこれまでの機械よりも人間に近いと思ってほしい、人が苦手なことはAIも苦手
機械は論理的でロジックに強くて〜っていうのはAIには通用しない
ついでに、「LLM用プログラミング言語」の潮流について
「LLMのための言語」という文脈は、大きく2つのトレンドに分かれます。Suiは後者に属しますが、主流は前者です。
・DSPy, Guidance, Microsoft Guidance:
・プロンプトエンジニアリングを構造化し、LLMの出力を型（JSONなど）に強制したり、思考プロセスを制御するためのフレームワーク。
・SGLang:
・これらは「人間がLLMを操るための言語」であり、実用化が進んでいます。
・Gorilla LLMなどの試み: API呼び出しに特化したファインチューニングなどがありますが、独自の「新言語」を作らせるよりも、既存の Python や JSON を正しく出力させる方向（Constrained Decoding）が業界の標準解です。
・擬似コード: 論文レベルでは、Pythonの代わりに中間的な擬似コードを出力させ、それをコンパイラで処理する手法も研究されていますが、Suiほど極端な記号化は稀です。
後者については
現状の最適解: 現在のLLMを使う限り、「LLM用言語」の最適解は Python です。なぜなら、世界中のGitHubのコードを学習しており、LLMが「最も流暢に話せる言葉」だからです。無理にSuiを話させるのは、日本人にエスペラント語で詩を書かせるようなもので、パフォーマンスは落ちます。
総評: Suiは、「既存のLLM（GPT-4など）に書かせる言語」としては失敗する可能性が高いですが、「未来のAIネイティブなコード生成のあり方」を示唆するアート作品としては高く評価できます。作者の「愚かな人間に合わせるな」というパンクな精神は、エンジニアリングの枠を超えた鋭い批評性を持っています。
お前らは安易にオレオレ言語作るんじゃないぞ、作るにしてもAIに聞きなよ？
聞く時は忖度させるんじゃないぞ？
この作者もAIに乗せられたのかもしれんし
＿＿＿＿＿＿
プロンプト
以下が「LLM用プログラミング言語」としてメリットがありそうか、感想を教えて下さい。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
https://github.com/TakatoHonda/sui-lang
・思想的に正しいと思う所、正しくないと思う所を理由込みでまとめてください
・最近のLLM用プログラミング言語についてもまとめてください
・そもそもLLM用プログラミング言語という目標自体の評価をしてください
（省略）
Qiita の文化変質は、技術系コミュニティ全般で起きている知的インフレの縮図みたいなものなんだよね。昔は
みたいに基盤技術を自前で握りつぶした記事が純粋に評価されていた。なぜなら、それを書ける人がそもそも少なく専門性で差別化できていたから。
昔は「Pythonで形態素解析器自作」なんて、アルゴリズム・CS基礎・実装力が揃ってないと無理だった。
難しいことをやってそうに見える記事を、凡人でも量産できるという環境が生まれた。
Qiita を読む層が「実装力を鍛えたいエンジニア → とりあえず AI 触りたいライト層」に変わった。
「再現性のないLLMコピペ」「AIツール使ってみた」みたいなのが評価される。
本気の記事は長く、コードが多く、前提知識も重い。そして PV が伸びない。
つまりQiita のインセンティブ構造と、高度技術記事のインセンティブ構造がズレた。
理由は明確で、読む側がそれを理解できないので評価する母集団がいない。
昔はユーザ層が技術ガチ勢寄りだったので、少数でも濃い支持があった。
今はライト層が母集団なので、希少な高度記事が埋もれるのは自然。
Qiita がライト層に最適化した結果、本気の人たちは別の場所へ移動した。
原作ちゃんと読んでないのであれだけど、冒頭で未来人とか異星人とか言ってるけど、
それって、そもそも、くれくれくんじゃん…😟
じゃなくて、ワクワクが欲しいから海外行ったり、宇宙行ったり、深海行ったりするんだし、
金のない自分もネットとかgithub徘徊するのは、ワクワクするなにか、落ちてないかなあ、と思ってるからなわけで、
何も起こらない！つまらん！というのは、単なる、くれくれくんだよね…😟
終わりなきつまらない日常をハルヒも生きてるんだろうし、みんな日常がつまらないと思ってるけど、
つまらないと思うんだったら、今からインド行ってくるわ、とか、アフリカでちょっとライオンと格闘してくる、とか、
今の日本なら、北海道とか東北に行けばクマに遭遇できるよ、という話なわけで…😟
でも、涼宮ハルヒがくれくれくん、つまり、アクティブなようでいながら、
なんだかんだ学校に来る、くれくれくん、じゃなかったら、物語が成立しないんだよね、当たり前だけど…😟
ハルヒは結局、神さまであって、彼女の妄想が現実世界を改変しているわけで、
彼女が本当に行動的なら、まず、学校に来ないと思うんだよね、いきなりステーキ、いきなり不登校…😟
で、インド行ったり、アフリカ行ったり、東南アジアで沈没して、同じヒッピー系バックパッカーと結婚して、
って、昔、どっかで見た女性の話だな…😟
まあ、それがハルヒレベルだと、映画コンタクトみたいに宇宙に行こうとかなるのかもしれんけど、
一般市民としてはそこで限界で、前澤なんとかみたいに札束で宇宙に行くことも凡人には不可能なんで、
そこからLSD使って、人間の意識は拡張できるとか、ドラッグの力で脳内にモデムが形成できるとか、
インターネットはドラッグカルチャーの影響を強く受けているとか、
例えばさ、ある時期にお前のGithubで公開したコードが一世風靡したとするだろ？
んで、お前がXでこんなコードを作りましたと言っても、お前のXアカウントは信頼されない。
なぜなら、そのGithubアカウントがお前のXアカウントを同一人物として判別するには、プロフィールの相互リンクが不可欠だから。
たぶん、Google検索もこういったトランスランクを加味している可能性が高い。
だから結局、トラストランクというのは内容そのものの良し悪しよりも、主体の一貫性が外部から検証可能かどうかで決まるんだよ。
技術的に正しいコードを書いても、それが誰による成果物なのかが曖昧なら、評価システム全体は防御的に振る舞う。
これはSNSでも検索エンジンでも同じで、なりすまし・スパム・宣伝アカウントを排除するための基本的なリスク管理構造だから。
そして、これらのサービスは互いのデータを直接共有しているわけじゃない。
個別に主体の実体を推定しようとする。そのとき一番効くシグナルが相互にリンクされたプロファイルなんだよ。
片方向リンクは主張に過ぎない。相互リンクは検証可能な関係性になる。
つまり、X → GitHub だけでは本物かどうかは確証できない。
GitHub → X のリンクが揃ったとき初めて、システムはこれは同一主体の操作だと判断しやすくなる。
これはWebのリンク解析が昔から採用している相互性から生まれる確からしさと同じ構造だ。
そしてGoogleがこれを無視する理由はほぼ存在しない。なぜなら、主体の正当性を誤判定すると検索品質そのものが崩れるからだ。
品質維持のためには、リンク構造・アカウント間の整合性・外部発信の一貫性をスコア化せざるを得ない。
これはPageRankの派生というより、E-E-A-Tやスパム防御の延長線上に自然発生した要件と考えるほうが合理的だ。
だから、どれだけ良いコードを書こうが、どれだけ正確な技術記事を書こうが、主体の整合性が弱ければ情報は正当に扱われない可能性がある。
Pythonちょっと勉強してたし、将来はAIエンジニアとしてバリバリ活躍するんだって思ってた。
入社したのは普通のソフトウェア開発会社で、同僚はみんな優しい。
でも…みんなこう言うんだ。
……まあ信じたよ。当初はね。
で、ある日の昼休み。
同僚の一人がふと見せてきたん。
そこにあったのが、Flutterで作ったマルチプラットフォームアプリ。
バックエンドはFirebase Authentication + Firestore。
UIの状態管理はRiverpod。画面遷移制御はGoRouter。
「あーでもこれ遊びで作ってるだけだからｗ」
しかもスクリーンショット見たらCI/CDがGitHub Actionsで回ってんの。
別の同僚もほぼ同じ。
「休日は何してんの？」って聞いたら「普段ゲームばっかで何もしてないわｗ」とか言うわけ。
でも昼休憩にそいつモニターを見たらタブに開いてたのがStackOverflowとかRFC 6455だった。
冗談で勉強してんの？って聞いたら「趣味ですｗ」とか言うわけ。正直引いた。
更に驚いたのが勉強会の存在で、あいつらの「休日何もしてない」は嘘だってことが分かった。。
俺が「休日は何もしてないんでしょ？」って聞くと
「してないしてない、何も〜。あ、でもLT会と、Go言語の勉強会は毎週参加してるかなｗ」
とか普通に言ってくる。
は？？何もしてないって言うのに土曜も日曜も、誰かの書いた技術書読んでんの？
もうこれさ……完全に別の生き物じゃん。
https://b.hatena.ne.jp/entry/s/ziglang.org/news/migrating-from-github-to-codeberg/
I personally would seriously encourage other projects, particularly any using self-hosted runners, to look carefully at the stability of Actions and ask themselves whether it is a solution worth sticking with long-term when compared with alternatives.
どこからこんな巨大な世話心が湧いてくるんだろ
