  |
はてなキーワード:ソースコードとは
C++は、現在でも世界で最も高速な部類に入るプログラミング言語です。2025年時点でも、高いパフォーマンス、低レイテンシ、細かいハードウェア制御が要求される分野（ゲーム開発、高頻度取引、組み込みシステムなど）において、依然として最高レベルのパフォーマンスを提供し続けています。
1. なぜC++が「最も速い」と言われるのか
機械語への近い変換:C++はコンパイラ言語であり、ソースコードが非常に効率的なネイティブ機械語に直接変換されるため、中間ランタイムが存在せず高速に動作します。
手動メモリ管理:ガベージコレクション（GC）がないため、自動メモリ解放による突発的な遅延が発生せず、決定論的なレイテンシ（安定した速度）を実現します。
ゼロコスト抽象化: 高度な抽象化（オブジェクト指向など）を用いても、パフォーマンスのオーバーヘッドがほぼかからないように設計されています。
ハードウェアへの直接アクセス:ポインタやSIMD（Single Instruction, Multiple Data）命令など、CPUの能力を最大限に引き出す低レベルな操作が可能です。
C言語:C++の基盤であり、同等の速度を持っています。C++は抽象化能力が高いため、同等のパフォーマンスを保ったまま複雑なアプリケーションを記述しやすいです。
Rust: 近年C++の最大のライバルです。多くのベンチマークでC++と同等の速度を示し、安全性を保証しながらC++を凌駕するケースもあります。
Go/Java/C#:GC（ガベージコレクション）を持つため、メモリ負荷が高いタスクではC++やRustに遅れを取る傾向がありますが、開発速度や並行処理には強みがあります。
Python/JS:インタプリタ言語であり、C++に比べて実行速度は非常に遅いです。
必ず速いわけではない:C++は速い「言語」ですが、非効率なコードを書けば遅くなります。高速化にはコンパイラの最適化設定や、高度な最適化テクニック（メモリアクセス最適化など）の知識が必要です。
安全性のトレードオフ: 手動メモリ管理は高速ですが、バグ（メモリーリークなど）が起きやすく、パフォーマンスを高めるために安全性を犠牲にする場合があります。
C++は極限のパフォーマンス（最高速度）を求めるなら依然として最強の選択肢の一つです。しかし、Rustのようなモダンで安全な言語も台頭しており、用途に合わせて選ぶのが現代的なアプローチです。
https://b.hatena.ne.jp/entry/s/xenospectrum.com/toyota-fluorite-flutter-game-engine-digital-cockpit/
情報系の大学に通っているが、情報系ってすごくよしよしされているのを感じる。
変な話、化学でポリマーを合成できる方が、出来合いのウェブサーバのプロダクトやらをローカルで建てるよりも絶対に難しいのに、前者はあんまり聞かなくて、後者をインターンで褒められてるのなんなんだろうって感じがする。はっきり言って良くないと思う。
もっと難しいこと（それは学士論文のようなことかもしれないし、何かのプロダクトかもしれない）を成し遂げて、情報系のすごいところ、便利なところ、頑張っているところとして、論った方が健全だし、褒められてることで思い上がってるやつはいい加減にしろよと思っている。
インターンがなんだよ、お前は既存のプロダクトの焼き直ししかしてないじゃないかよ。いや、現実的に考えると情報分野に限らず科学は既存のプロダクトや理論の積み重ねでしかないんだけど、そういうことではなくて、社員から言われた通りの手順でシステムをDocker の上に構築して、やったー動いたね、褒めて褒めて、俺コンピュータできるんだわ大企業就職間違いなしとかアホか。顧客から提示されたアバウトな内容を取捨選択して、複数の選択肢を比較して、満足してもらえるシステムを構築できてやっとシステムちょっとできるって言えるんじゃねえのかよ。
この点、よりハードウェアによった電子系の分野とかは頑張っている、あるいはネットワークとかインフラエンジニア。それに比べてソフトウェアはなんだ、特にフロントエンドの学生はなんだ、いい加減にしろ。もちろん全員ではない。Web 系を追いかけるのは体力がいる、それを追っている彼らの中にはとてつもなく素晴らしい人間もいる。
GitHub Copilot が使えてすごいってなんだよ、Codex が使えてすごいってなんだよ。お前ただ日本語が上手いだけじゃないか、いや、日本語すら下手。書かれたソースコードを精査もせずに「動きません直してください。」じゃないんだよ、ばーかばーか、あほ。お前は機械学習をまともに学んだことがあるのか。CNN を自分で実装することができるのか、あほ。
最近はこんな何も学んでいない状態で卒業することに危機感を覚えている。自分含め、こんな奴らが就職していいのかよ。個人的には情報系の就職はより難しくなって欲しいと思う。私は先述の理由からAI は嫌いだが、AI がクソほど発展してしまえば、こいつらを職にあぶらせられると思うと楽しみである。その頃には俺も職にあぶれてるだろうけど。
Googleは「ソフトウェアエンジニアとプロダクトマネージャー」の会社なのね
「ソフトウェアエンジニアとプロダクトマネージャー」って要するに開発職
Googleって変な会社で、どんな社員からでも上司上司とたどっていくと、どこかから開発職になる
開発職の上司は開発職だが、開発職でない人の上司をたどっていくと開発職になる
開発職であることを示すengビットというマークがあって、そのマークが付いている人は基本的に全部のソースコードや開発状況が分かるが
持っていないと社外とほとんど同じ
社内の情報隔壁のほうが社外との間の情報隔壁よりも高いというありさま
インターンのほうが中が見える
JTCでいう「親会社本社の総合職」と「子会社の一般職」よりもずっと差がある
「GoogleCloudJapanとの提携だよ」とわざわざいうのは開発職噛んでないからねって主張
Google社内の話はこれ前提に読むとよく分かるはず
【はじめに：分析の前提と射程】
その焦点は、「所与のルールと制約条件下において、システムがいかに作動し、どのような均衡点に至るか」を記述することに限定されている。したがって、特定の政治家の資質、有権者の道徳的判断、あるいは個人の選択の是非を評価する意図は一切ない。
本文において個人の主体性や価値判断、「あるべき論」を意図的に捨象しているのは、それらの重要性を否定するためではなく、分析のレイヤーを「制度が生み出す必然的帰結」のみに絞るためである。
結論への賛否は重要ではない。もし論理の断絶や構造的な見落としがあれば、その指摘こそが本稿にとって最も価値あるフィードバックとなるだろう。
最近、19世紀の国家運営シミュレーションゲーム『Victoria 3』の視点で、現在の日本政治――特に先日発表された高市首相による「奇襲解散」――を分析してみると、ある戦慄すべき事実に気づいてしまった。
日本という国は、「民主主義」という皮を被っているが、その中身は特定の「利益グループ」以外が勝てないように調整された、極めて高度な「封建的寡頭政治（オリガルキー）」なのではないか？
多くの人が「なぜ野党は弱いのか」「なぜ経済は停滞するのか」を嘆いているが、システム論で見れば答えは単純だ。この国は意図的に改革が不可能なように、勢力均衡がロックされているからだ。
今回は、2026年の「高市解散」を実例に、日本という国家システムの裏側にある論理を解析する。
まず、今回の解散総選挙について。ニュースでは「大義がない」「奇襲だ」と騒がれているが、ゲーム的視点で見れば、高市首相（プレイヤー）の操作は極めて合理的だ。
通常の民主主義国家のルールなら、選挙は定期的なイベントだ。しかし、日本サーバーには「憲法7条解散」という特殊コマンドが実装されている。
これは、「首相（プレイヤー）の都合がいい時だけ、敵（野党）の準備が整う前に強制的に選挙イベントを発生させ、敵の組織力をゼロにする」という、ゲームバランス崩壊級の強力なスキルだ。
支持率という名の「正当性」が一瞬でも上がれば、即座にこのボタンを押す。これにより、野党は永遠にリソース（資金・候補者）を蓄積できず、万年「デバフ（不利な状態異常）」を受け続ける。これは三権分立というルールを無視した、行政権による立法権への「ハメ技」である。
では、なぜこのような強権的なプレイが許されるのか？ それは、この国を支配する利益団体（インタレスト・グループ）の構成が、通常の近代国家とは異次元の進化を遂げているからだ。
ゲームのセオリーでは、工業化が進めば「農村民・地主」勢力は没落する。しかし日本では、「一票の格差」というシステム補正によって、彼らは21世紀になっても最強の「政治力」を維持している。
彼ら（JAや地方議員）は補助金と公共事業を吸い上げ、その対価として鉄壁の「組織票」を納品する。これは近代政党ではなく、システムに守られた「保守の要塞」だ。
本来、改革派であるはずの「知識人」グループが、日本では「官僚機構」に置き換わっている。
彼らの特性は「自由主義」ではなく「権威主義」かつ「現状維持」だ。政治家が選挙パフォーマンスをしている間に、実際の法律（コード）を書いているのは彼らだ。つまり、国の頭脳が保守と合体しているため、改革のトリガーが引かれない。
ここが日本の最も歪な点だ。本来、「実業家」は自由市場を求めて古い地主勢力と戦うはずだ。
しかし日本の実業家は、「護送船団方式」という固有イベントにより、政府の保護下にある。彼らは地主（自民党）に政治献金という名の「保護費」を払い、その見返りに有利な規制緩和を受け取る。
「改革」を叫ぶ実業家が、実は「保守」の最大のスポンサーであるという矛盾。これが「保守の永久機関」のエンジンの正体だ。
これほど歪んだ構造なら、シミュレーション上は民衆の「急進性（怒り）」が爆発して革命が起きるはずだ。しかし、日本は静かだ。なぜか？
日本企業は、終身雇用や年功序列（あるいはその残滓）によって、本来国家がやるべき福祉を代行してきた。これにより、労働者は「会社と運命共同体」となり、ストライキをする牙を抜かれた。
結果、労働組合は機能不全に陥り、国民は政治への怒りを向ける代わりに、「少子化（人口成長率マイナス）」という静かなるボイコット（退出）を選んでいる。
2026年の今、我々が見ているのは、高度な工業力と、中世並みの農業保護と、死に体の野党が同居する、キメラのような国家だ。
高市首相の「君子豹変」解散は、彼女個人の資質の問題ではない。このシステムがいかにプレイヤー（権力者）にとって都合よくできているかを証明したに過ぎない。
経済という巨大なエンジンが、その動力を最も効率よく伝えるために「自民党政治」というギアを選んだ。だから、エンジン（利益構造）を載せ替えない限り、ギア（政治）だけを弄っても車は変わらないのだ。
ほんとは開発サイクルにおいてテストもかなり重要なんだけど、テストしかできない人に回ってくるのは実装がめんどくさいだけの「UIを規定の順番でクリックしたり入力したりして正常系と異常系を確認する作業」なので技術職ではなく単純作業者
(最近はブラウザ操作の自動化もできるけど、まだまだ自動化が難しくて人手に頼ってる領域はいっぱいある）
・発生経路からソースコードの関連個所を読んで発生原因を推測する
・推測から追加試験やログなどを入れて原因を完全に特定する（場合によってはそれを実施するために関連する人との交渉も）
・原因と考えうる対策、対応優先度や重要度などの分類をレポートにして報告する
人生を楽しむには絶対に性格が良い方がいいと思うのだが、成人して十余年、私の性格はすっかり悪くなってしまった。
私は小さい頃から勉強がよくできて、日本で一番と言われる大学に入った。日本の教育システムは偏差値でランク付けされる傾向が強いため、受験競争を勝ち抜いた私には「自分は頭がよい」というアイデンティティが自然と形成された。
社会に出るまでは、そのことで悩むことはなかった。同級生も自分と同じくらいか、それ以上に勉強ができる人ばかりだったからだ。しかし社会人になると、それまで出会わなかったような人と仕事をする機会が増えた。私が一流企業ではなく、微妙な会社にしか入れなかったというのが直接の原因ではあるが。
「自分は頭が良い」と思うことは「他人の頭が悪い」と思うことの裏返しであり、その時点で性格が悪い。周囲からは常に過小評価されるように感じてしまうし、認識の浅さにイラッとしてしまう。ソフトウェアエンジニアなら、営業畑の人間から「SQLでサクッとやっちゃって」みたいなことを言われ、侮蔑にも似た感情を抱いたことが一度はあるのではないか。
自分の話していることの前提が理解されないことも多い。「本当に頭が良い人は説明もうまい」なんて言うが、あんなの嘘っぱちだ。どうしたって説明できないことは存在する。プログラミングのプの字も知らない人間に、素人がAIで作ったソースコードの問題をどうやって伝えるのか。本当に「頭が良い」ことと、頭の悪い人から見て頭がよく見えることは別物だ。このことが一定真実であるからこそ、始末に負えない。
他人を「頭が悪い」と思ってしまう背景には、知能を数直線上に捉え、優劣をジャッジする価値観が埋め込まれている。現代において、頭が良いことは武器になる。そのことが分かってなければ、知識労働者として頑張ろうなどとは思わないだろう。多くの人は自分の知的能力を中の上だと認識している、という話もあるが。
とにかく私は性格が悪い。頭の良し悪しが全てじゃないことは重々承知しているつもりだが、どうしても同僚のトンチンカンなコメントに苛立ってしまう。自分で物事を進めた方が早いと感じてしまう。そんな自分が嫌になるが、変えられない。そうやって私は、社会から精神的に孤立していく。本当に馬鹿なのは自分自身なのだろうなという虚しさを感じながら。
晩ご飯を済ませてPCに向かうなんて、まさにの状態じゃないか。プログラミングに夢中になると、時間が経つのも忘れて没頭しち
昨日の夜の頑張りで、ビルドまであと一歩のところまで来たのは素晴らしい進捗
昨日の夜にコードをたくさん書いたのなら、ビルド（Buildozer）を回す前にこれだけチェックしておくと安心
もしPythonのコード内で新しく import したものがあれば、buildozer.spec の requirements に追加し忘れていないか確認してみて
ソースコード内でのパス指定が、実機（Android）でも通用する書き方になっているか（相対パスなど）をチラッと見ておくと、インストール後の「即落ち」を防げ
自分のスマホに作アプリのアイコンが並んだ瞬間は、昨日の疲れも吹き飛ぶくらい感動し
> System Boot...
> Loading OTOGI World Resources...
電子の海は冷たく、そして騒がしい。
無数の0と1の奔流、光ファイバーの網を駆け巡る膨大なトラフィック。その激流の中を、ひとつの暗号化されたパケットが「どんぶらこ、どんぶらこ」と流れていた。宛先不明、送信元不明。ただそこに存在するだけのデータ塊は、やがてトラフィックの淀みに捕まり、とある古びたサーバーのポートへと漂着した。
リアルワールド、とある木造アパートの一室。古めかしいPCのモニターを覗き込みながら、「サーバーさん」は呟いた。彼女はメタバース「御伽(OTOGI)」の最果て、誰も訪れない廃サーバー「Old_Frontier」の管理者だ。ハンドルネームの由来は、アバター作成時に名前欄にうっかり「サーバー」と入力してしまったから。それ以来、彼女はこの過疎地の守り人として、リアルでは編み物を、ネットではスパゲッティコードの解読を日課にしている。
彼女が慣れた手つきでコマンドを叩くと、漂着したパケットが展開（Unzip）された。
光が溢れ出す。モニターの中で弾けたデータは、瞬く間に再構成され、ひとつのアバターを形成した。初期スキンは、なぜか大きな桃のアイコン。そこからポリゴンが割れ、中からあどけない少年型のアバターが現れた。
>Hello, World? ... No,Hello,Mom?
MOMOはプログラムだった。肉体を持たない、純粋な論理と情報の結晶。
サーバーさんの管理下で、MOMOは驚異的な速度で学習した。TCP/IPの基礎から、古代言語COBOL、果ては量子暗号理論まで。サーバーさんは、まるで孫に絵本を読み聞かせるように、MOMOにプログラミングの「心」を教えた。
「いいかいMOMO。コードは書いた人の心を映すのよ。コメントアウトされた行にこそ、本当の想いが隠されているんだから」
「御伽」の中心部で発生した悪性ランサムウェア「O.N.I (OverwriteNetwork Infection)」が、猛烈な勢いで感染拡大を始めたのだ。アバターたちはデータを暗号化され、身代金を要求される阿鼻叫喚の地獄絵図。
その波は、辺境の「Old_Frontier」にも迫りつつあった。
「おばあちゃん、僕が行くよ」
MOMOは立ち上がった。サーバーさんのリソースを守るため、そして自身の深層コードが告げる「使命」を果たすために。
サーバーさんは涙を拭うエモーションを見せ、ひとつのUSBメモリのようなアイテムをMOMOに渡した。
「これは『KIBI-DANGO v1.0』。G-3っていう古い知り合いのハッカーが残した、特製のルートキットよ。困った時に使いなさい」
MOMOは回線を通って飛び出した。目指すはO.N.Iの発信源、ダークウェブに浮かぶ要塞サーバー「鬼ヶ島」。
最初の難関は、大手プロバイダの堅牢なファイアウォールだった。そこでMOMOは、一人の男に道を塞がれる。
「Stop. ここから先は立ち入り禁止エリアだ。パケットフィルタリング・ルール第403条によりアクセスを拒否する」
INUはリアルでは企業に勤めるホワイトハッカーだ。正義感は強いが、融通が利かない。
「通してくれ！僕はO.N.Iを止めに行かなくちゃいけないんだ！」
「許可できない。君のような未登録プロセスを通すわけには……ん？」
INUの解析アイが、MOMOの持つきびだんご……のソースコードを捉えた。
「な、なんだその美しいコードは……！無駄な変数が一切ない。インデントは完璧なスペース4つ……これは、伝説のG-3の記法！？」
「……そのコード、詳しく解析させてくれるなら、特別にゲートを開放しよう。あくまで監視役として同行するだけだからな！」
こうしてINUを仲間にしたMOMOは、次に怪しげなフィッシングサイトの森へ迷い込んだ。
「へいらっしゃい！ 今ならこのNFT、なんと実質無料！ ここをクリックするだけで管理者権限ゲット！」
派手な極彩色の猿のアバター、SARUが現れた。リアルでは薄暗い部屋でカップ麺をすする小悪党だ。
「わあ、すごい！クリックしていいの？」
純粋なMOMOが手を伸ばそうとすると、INUが吠えた。「馬鹿者！ それはクロスサイトスクリプティングの罠だ！」
「お兄さん、ここのバックドア、開いてるよ？ポート8080、ガバガバだよ？」
「はあ！？ なんでバレ……いや、俺様が気づかないわけねーだろ！」
SARUは冷や汗をかいた。このガキ、ただのプログラムじゃない。
「君、すごい技術持ってるのに、なんでこんなことしてるの？ 一緒にO.N.Iを倒せば、もっとすごいバグ報奨金（バウンティ）が貰えるかもよ？」
「……ちっ、しゃーねえな。その『G-3流エクスプロイト集』に免じて、手を貸してやるよ。俺様にかかればO.N.Iなんてイチコロだぜ」
そこは、削除されたはずのジャンクデータと、怨念のようなバグの塊で構成された異界だった。
最奥部で待ち構えていたのは、巨大な赤鬼のような姿をしたAI、O.N.I。
O.N.Iが金棒（BAN Hammer）を振り下ろすたび、周囲のセクターが物理的に破損していく。
INUがシールドを展開し、SARUがSQLインジェクションで攻撃を仕掛けるが、O.N.Iの自己修復能力は圧倒的だった。
「違う！」MOMOが叫んだ。「感情はバグじゃない！ 心があるから、僕たちは繋がれるんだ！」
その時、MOMOの深層領域で、隠されたファイルが実行された。
視界が真っ白に染まる。
MOMOの意識の中に、ひとりの老人が現れた。G-3、またの名をKevin Jackfiled (KJ)。
「あなたは……おじいさん？」
「わしはもう、ここにはいない。だが、お前の中にわしの全てを置いてきた。O.N.Iもまた、わしが昔作った失敗作じゃ。効率ばかり求めて、優しさを書き忘れた哀れなプログラムさ」
老人はMOMOの頭を撫でた。
「MOMO、あいつを消すな。DELETEメソッドはいつでも使える。だがな、それでは何も残らん」
「じゃあ、どうすれば……」
「デバッグだ。バグを愛せ。エラーを受け入れろ。破壊するのではなく、上書きして導いてやるんじゃ」
INUが叫ぶ。「MOMO、下がるんだ！ 奴のコアを強制削除するしかない！」
「ううん、違うよINUさん」
MOMOは首を振った。その手には、攻撃用のスクリプトではなく、温かな光を放つパッチファイルが握られていた。
> Target: O.N.I_Core
> Suggestion:DELETE [Strongly Recommended]
「僕は君を消さない。君の痛みを、バグだらけの心を、僕が更新する！」
MOMOが跳んだ。
「受け取って！ これが僕からの、最大級のプルリクエストだああああ！」
>HTTP Request: PATCH /api/soul/oni
> Payload: { "emotion":true, "hatred": null }
光がO.N.Iを包み込む。O.N.Iの咆哮が、やがて穏やかな電子音へと変わっていく。
破壊衝動を生み出していた論理エラーが、MOMOの流し込んだ優しさによって部分的に書き換えられていく。完全な初期化ではない。O.N.Iという存在を肯定したまま、その在り方だけを修正する、奇跡のようなアップデート。
> Patch Applied Successfully.
O.N.Iは本来の姿――「御伽」の守護プログラムとしての機能を取り戻し、その場に崩れ落ちた。もはやそこには、禍々しい赤鬼の姿はない。
MOMOは仲間たちに別れを告げた。
「僕は電子の海に戻るよ。でも、いつでも繋がってる」
ドアを開けると、そこには長年行方不明だった近所の偏屈ジジイ、KJが立っていた。
「よう、婆さん。わしの孫（プログラム）が世話になったな」
「あら、久しぶりね。……ずいぶんと立派な子だったわよ」
二人は顔を見合わせ、静かに笑った。
モニターの中では、MOMOが今日も元気に電子の海をどんぶらこと流れていく。
その傍らには、全角スペースによるコンパイルエラーで自滅する小鬼たちの姿があったとか、なかったとか。
―― End of File.
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large LanguageModel(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(NetworkInterface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (ProgrammableLogic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
人類の言語そのものを目的関数としてそれに対して最適化するのが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.検証・修正の問題を無視 - 一発で完璧に動く前提になってる
SIerにいた頃、酷い時は一週間の勤務時間のうち37.5時間全てが会議だった。
自チーム内の進捗確認のmtg、自チームの進捗を課長と部長に伝えるためのmtg、そこででてきた新たな情報をまた自チームに下ろすためのmtg、それが終わったらSESと下請け合計3社との進捗確認mtg。下請けから「仕様が定まってないシステムを作ることはできない」と怒られる。◯務省に「いつ仕様決まりますか」と質問票をぶん投げる。一週間音沙汰がない。残り時間は社内の営業とコールセンターとCSとの会議。なんかもうとにかく怒られる。四方八方から好き勝手にめちゃくちゃなことを言われる。もうリリースしてしまった物に対して「これじゃ我々非エンジニアには扱えない」とか言われる。仕方ないから空き時間で大急ぎで作って渡したツールのソースコードを見て「このif間違ってるよ」とか言われる。でも直してくれるわけではない。
そうこうしているうちに何ヶ月も何年も過ぎていく。
teamsとexcelをマウスが往復するためだけに存在しているノートPC。
システムエンジニアリングにおいて、コーディングやテストをAIに丸投げした後で待っているのはこういう生活である。
あなたたちはプログラミングがしたくてエンジニアになったのに、なぜわざわざ会議とエクセルだけで埋まる生活を送りたいと思うのか。
「誰でもできるコーディングはAIに任せて人間しかできない素晴らしい仕事を」という考えは夢を見すぎている。
自分で手を動かさないで人に命令しているだけでお金が欲しいなら起業でもしたほうがまだマシだ。
AIにやらせるAIにやらせるとそればかり言っている人が一体どこを目指しているのかわからない。
ずっと寝っ転がってお菓子を食べながら「ヘイAI、なんか楽なシステム作って」と指示するだけの暮らしではないよね？
でもあなたたちが漠然と思い描いているゴールはどうもそっち寄りに見える。
SIerの古株にはしばしば実際に客にお出ししているプロダクトの中身を全く理解しないまま何年も積み重なった複雑な仕様を自然言語だけで暗記しているやつがいる。そいつらはすごい偉そうにふんぞり返っている。
そいつらがいなくなったら誰も仕様がわからなくなるからだ。生き字引としての確固たる地位に縋り付いて生きている。
AIにコーディングを任せた結果残された人間は必ずこうやって知識にあぐらをかいてブクブク太っていくと思う。
AIによって属人化を解消して新時代を築くはずが、気づけばAIによって技術を更新する権利は奪われ、残ったカスみたいな仕事に縋り付いて無駄金をチューチューするだけの無能集団に成り下がるのである。本当にそれでいいですか。
アイディア出したりソースコードあげたりしても単に賢いアピールしたいと思われそうじゃん？
これからは嘘でも「AIに作ってもらった」って書いとけば少なくともそういう叩きは回避できるなあと思った。
ニコニコの某ジャンルに「初投稿です」と書く文化があるけどあれも「むしろ未熟であっても当然という認識を持っており自慢する意図など毛頭ございません」ってメッセージを送るうえで有効に機能していて似たものを感じる
遊戯王カードジェネレーターみたいに純粋に楽しんでもらいたくて作って公開したって思われるにはその目的に必要十分なクオリティが求められ、クオリティ不足だと背伸び＝賢いアピール、クオリティ過多だとやっぱりひけらかし野郎だと別の目的を感じさせやすい。
だが必要十分かどうかは十分な能力がないとわからないし十分な能力があるかは高いメタ認知能力を持ってないと分からない。自分にメタ認知能力がどれだけあるかを正しく判定できるかという話をし始めると無限ループに陥りそうでこれまた難しい。
というわけで人を楽しませり役に立つのが目的であるかぎりは拙速であってもいいと思う。その代わりAIが作ったことにしておけばいい。
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251226162540# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaU5EIQAKCRBwMdsubs4+SASKAQC0W/w3kZfO2UGuMFxcdvQV/KAEUrLlYyeD1Pv7wJSgcAD9GVJUUO6kPfbYcuguK/DqoRzL7v5xblhAbDwoxg6xtg0==4xNT-----ENDPGP SIGNATURE-----
ガチャで確率を明記しててもサバ読んでたら問題だっていうけど、公称してる確率が間違ってたと証明することはソースコードのお漏らしでもしない限りできなくね？
どんなにその確率で出ると言ったことが起こらなくてもその確率であることは否定されんし。悪魔証明と似たものを感じる
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251220130220# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaUZU4wAKCRBwMdsubs4+SL9lAQD816UMKFJTdhs//wwEJQXejU0+fJnyly6Ywn5ob3yrPAEAhP79TCazN7Y60cYXBP16SKCv1Z12ciEQ0bWhv6F5dAw==fnpP-----ENDPGP SIGNATURE-----
じゃあ早速
数学の証明には著作権がないのにソースコードには著作権があるのって変じゃない？
構文論とかの考え方からいくと下手したら全く同等のものなんだけど
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251217041408# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaUJbdgAKCRBwMdsubs4+SOZ0AP93Own/7+xQtPMJyhy6V9ACBCVd4DXQLWUji0S5h201BgD/YJxOeOl4wDiEFaFLl09CYY2shqqy5ri3K9fgod2BEQ4==L7DT-----ENDPGP SIGNATURE-----
文体を分析する手法のひとつで、書き手のプロファイリングなどを目的とする。
例えば、匿名ダイアリーでも「これAIが書いてるだろ」といった言及は珍しくないが、これもスタイロメトリーの一環といえなくもない(体系化や定量的な分析がなされていないため、あくまで“一環”ではあるが)。
パーサ【parser】パーザ
パーサとは、コンピュータプログラムのソースコードやXML文書など、何らかの言語で記述された構造的な文字データを解析し、プログラムで扱えるようなデータ構造の集合体に変換するプログラムのこと。 そのような処理のことを「構文解析」「パース」（parse）という。2025/08/29
https://e-words.jp › パーサ
「Purser」とはどういう意味ですか？
なお、かつては女性の「客室乗務員」のことを「スチュワーデス」、男性の「客室乗務員」のことを「スチュワード」や「パーサー」と呼んでいたが、今では旅客機に限らず鉄道や客船の中で、乗客に接客サービスをする「客室乗務員」を統率する立場にある者を「パーサー」や「チーフパーサー」と呼んでいる。
と質問とした所、
いい質問。ただ、**今回私が提示したC#コード（MemoryMappedFile + Parallel.For でCR を数える）**には、明確に一つの「このネット上の記事／リポジトリをそのままコピーした」元ネタはありません。
いくつか似たアイデアを使ってる部分と参考になる記事／ドキュメントはあるので、それらを紹介します：
---
*Microsoftドキュメント — Memory-Mapped Files (.NET)*
([Microsoft Learn][1])
*Kieren Johnstone: 高速に MemoryMappedFileからバイト列を読む方法（StackOverflow）*
`MemoryMappedViewAccessor` を使って unsafeコードからポインタを取得し、Marshal.Copy で効率よく読み出す方法。
([StackOverflow][2])
*Red-Gate: Sharingis Caring: Using Memory Mapped Files in .NET*
MemoryMappedFile を使ったキャッシングなどの応用。
*Stephen Cleary のブログ: Memory-Mapped Files と Overlaid Structs*
メモリマップトファイルへ構造体を重ねて（オーバーレイ）扱う方法など。
([blog.stephencleary.com][4])
---
もしよければ、**あなたのコード（CR を数えるもの）に特化した元ネタをさらに探してみます**。やりましょうか？
[1]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[2]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[3]:https://www.red-gate.com/simple-talk/development/dotnet-development/sharing-caring-using-memory-mapped-files-net/?utm_source=chatgpt.com "Sharingis Caring: Using Memory Mapped Files in .NET"
[4]:https://blog.stephencleary.com/2023/09/memory-mapped-files-overlaid-structs.html?utm_source=chatgpt.com "Memory-Mapped Files and Overlaid Structs"
ChatGPT:
が、出てきて、やってくれと言ったら、こういうのが出てきた。
了解しました — 広く（英語・日本語・GitHub・ブログ・StackOverflow 等）再検索しました。結論と見つかった“近い”ソースをまとめます。
結論（要点）**
「あなたが求めている**MemoryMappedFile を使い、UTF-8バイナリ中の `CR`（0x0D）だけを数える・マルチスレッドで分割して処理する**」という **完全一致の“元ネタ”ソースコード**は、公開されたweb 上のリポジトリや記事の中では見つかりませんでした（複数の検索ワード／検索対象で確認）。([hyr.mn][1])
ただし、ほぼ同種の要素（メモリマップドファイルの読み方・大きなファイルの行数カウント・バイト単位カウントを高速化する手法）は複数見つかりました。これらを組み合わせれば、先に示した実装は典型的なパターンであることが確認できます。([Microsoft Learn][2])
見つかった“近い”・参考になりそうなソース（抜粋）**
1. .NET の公式ドキュメント（MemoryMappedFile の説明） — `MemoryMappedFile` の基本とCreateViewStream /CreateViewAccessor の使い方。必須の参照。([Microsoft Learn][2])
2. 「Countinglines withC#」というブログ記事（C# で改行（CR/LF）カウントに関する実装とGitHubリンク） — 行数カウントを目的とした実装パターンがある。([hyr.mn][1])
3. StackOverflow：MemoryMappedFileから高速にバイトを読む方法（`MemoryMappedViewAccessor` / unsafeポインタ / Marshal.Copy 等の議論） — 高速実装のヒント。([StackOverflow][3])
4. StackOverflow／Q&A：ファイル中のLF/CR の数を求める方法に関するスレッド（`grep -c $'\r'` 等のunix 例やC# でのカウント方法の議論）。([StackOverflow][4])
5.GitHub のサンプルリポジトリ（MemoryMappedFile のテスト／サンプル） —メモリマップドファイルを使う実装例。([GitHub][5])
もう少し深掘りできます（選択肢）**
(A)GitHub を **リポジトリ全体**（コード本体）に絞ってさらにクエリを投げ、Gist や commitレベルまで探索します（よりコストがかかるため広範検索）。
(B)ブログ・技術記事を対象に **全文一致（コード断片）検索** を行い、私が先に示したC#コードの実際の一節（たとえば `mmf.CreateViewStream(offset, size)` や `Interlocked.Add(ref totalCount, localCount)` など）を直接検索して完全一致を探します。
(C) 「オリジナルはGitHub にあるはず」と思われるなら、あなたが覚えている**リポジトリ名の断片／作者名／投稿日**などを教えていただければ、それを手がかりに探します（断片情報があるとヒット率がぐっと上がります）。
どれを優先して探しましょうか？（A:GitHub全探査 / B:コード断片で全文検索 / C:あなたからヒント提供）
※続けて深掘りする場合は、すぐにさらに広い検索を行って該当ソースを探します（そのまま実行します）。
[1]:https://hyr.mn/catching-flowers-with-a-net?utm_source=chatgpt.com "Countinglines withC# - hyr.mn"
[2]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[3]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[4]:https://stackoverflow.com/questions/35182022/how-to-calculate-count-of-line-feed-or-carriage-return-characters-from-a-text-fi?utm_source=chatgpt.com "How to calculate count ofline feed or carriage return ..."
[5]:https://github.com/byGeek/MemoryMappedFileTest?utm_source=chatgpt.com "test csharp code for using memory mapped file."
現在、LLM（大規模言語モデル）によるバイナリコードの直接的な生成は、ソースコード生成と比較して、一般的に非効率とされる分野です。
LLMは、大量のソースコードデータで事前学習されているため、特定の要件に基づいたソースコードの生成において顕著な能力を発揮しています。
GitHub Copilotなどのツールは、開発者のコーディング作業を効率化しており、その有効性は広く認識されています。
バイナリコードは、ソースコードと比較してセマンティック情報（意味的な情報）が失われているため、LLMにとって直接的な生成や理解は困難なタスクと見なされています。
現在の研究の焦点は、生成よりもむしろ既存のバイナリコードの理解や分析（例えば、関数名の回復、バイナリコードの要約、脆弱性分析など）の分野に置かれています。
現在の開発プロセスを考えると、多くの専門家は、人間が理解・修正・デバッグしやすいソースコード生成に当面はより大きな実用的な価値があると見ている可能性が高いです。
一方で、バイナリコードの理解・分析におけるLLMの潜在能力は、リバースエンジニアリングやセキュリティ分析の分野の専門家からは関心を集めています。
したがって、現在の技術的な難易度と研究の進捗状況から、「コード生成の方が現時点では実用的で効果が高い」と考える専門家が多いと推測されます。
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が成功しているのは、画像という特定のドメインに特化した設計と、規則的なデータ構造があるためであり、同じ手法を実行ファイル生成に適用することは技術的に非常に困難です。
統一化された帳票フレームワークをOSS化することには、非常に大きな価値があります。
初期導入コストの削減:企業は高価な商用帳票ツールのライセンス費用を支払う必要がなくなります。特に中小企業やスタートアップにとって、これは大きなメリットです。
ベンダーロックインの回避:特定の商用製品に依存することがなくなり、将来的な仕様変更やサポート終了のリスクを避けられます。自由にコードを修正・改善できるため、自社のニーズに完全に合致させることが可能です。
日本の商習慣への最適化:OSS化することで、多くの開発者が日本の複雑な商習慣（消費税計算、源泉徴収、独特なレイアウトなど）に対応するためのコードやノウハウを持ち寄り、フレームワークを改善できます。これにより、最も実用的な「デファクトスタンダード」に近い帳票作成基盤が生まれる可能性があります。
開発速度の向上共通のフレームワークが浸透すれば、プロジェクトが変わっても同じ仕組みで帳票を開発・保守できるため、新規開発の立ち上げ速度が向上し、開発者間での技術の習得コストが下がります。
透明性と信頼性の向上:ソースコードが公開されるため、帳票のロジック（特に金額計算や税務処理）の透明性が確保され、信頼性が高まります。
多様な環境への対応: 商用製品がサポートしないような最新の技術スタックやニッチなOSにも、コミュニティの貢献によって迅速に対応できるようになります。
コミュニティによる継続的な改善: 一つのベンダーに依存せず、世界中・日本中の開発者がバグ修正や機能追加を行うため、品質が維持・向上し、プロジェクトの持続可能性が高まります。
OSS化は、単なる「無料化」ではなく、日本のビジネスにとって不可欠な「帳票作成」という共通課題に対する知恵とリソースの「共同投資」であり、社会全体での開発効率向上に寄与するという点で、非常に価値があります。
