  |
はてなキーワード: Pythonとは
ドライバ開発においてAI（LLM）が生成したコードをそのまま信頼するのが危険な理由は、単に「コードが間違っている可能性がある」というレベルを超え、**「AIが物理世界（ハードウェア）の挙動を直接観測できない」**という根本的な制約に起因します。
具体的に、なぜ不安定になりやすいのか、4つの技術的な視点から解説します。
ハードウェアには、マニュアルに書かれていない挙動や、特定の条件下でのみ発生するバグ（エラッタ）が必ずと言っていいほど存在します。
AIの限界: AIは「公開されている一般的な情報」を学習していますが、特定のチップの特定のバージョンにおける隠れた不具合（エラッタ）への対策コードを生成することは困難です。
リスク: 仕様通りに書いているのに、特定のタイミングでチップがハングアップする、といった現象を防げません。
通信処理（I2C、SPI、UARTなど）では、信号を「HIGH」にしてから「LOW」にするまでの待ち時間など、厳密なタイミングが求められます。
AIの限界: AIは論理的な手順は書けますが、実行環境（CPUクロック、OSのスケジューリング）における実時間の経過を考慮したウェイト処理を正確に組み込むのが苦手です。
影響: 通信波形が乱れ、データ化けやデバイスの認識失敗が頻発する原因になります。
ドライバは通常、OSの核心部（カーネル空間 / Ring 0）で動作します。
致命的な違い: アプリケーション層のプログラム（PythonやJavaなど）であれば、エラーが出ても「アプリが落ちる」だけで済みますが、ドライバの不備は**OS全体のクラッシュ（ブルースクリーンやカーネルパニック）**に直結します。
AIの弱点: 割り込みハンドラ内での禁止事項（メモリ割り当ての制限やスリープ不可など）を、AIが完璧に守り切るのは非常に難易度が高いです。
ドライバは、メモリの特定の番地（レジスタ）に値を書き込むことでハードウェアを動かします。
AIの弱点: AIはよく似た型番のチップのレジスタマップを混同することがあります。
結果: 全く別の機能を操作してしまったり、予約済みの領域を上書きしてハードウェアを物理的に損傷（過熱や過電圧など）させたりするリスクもゼロではありません。
AIをドライバ開発に使う場合は、**「コードを書かせる」のではなく「レビューの壁打ち相手」や「定型文の生成」**に限定するのが賢明です。
※本稿は筆者個人の見解であり所属機関とは一切関係ありません。ていうか所属機関から「もう黙れ」と言われています😅
はじめに（ポエム）
諸君、聞いてくれたまえ。
ワシはもう40年もこの業界にいるのだが、久しぶりに腹を抱えて笑った事案が飛び込んできたので筆を執った次第である。いやぁ～元気してる❓最近寒いけど体調崩してない❓ワシは痛風が再発して足が痛いよ🦶💦
さて本題。2026年3月、Pythonの文字エンコーディング検出ライブラリ「chardet」において、現メンテナーがAI（Claude）を使って全コードをゼロから書き直し、ライセンスをLGPLからMITに変更した。すると原作者を名乗る人物が「勝手にライセンス変えるな」とイシューを立て、OSSライセンスの専門家を自称する諸氏が「これは翻案権の問題だ」「原作者に有利だ」と騒ぎ始めた。
何を言っているんだお前たちは。
佐渡秀治氏（@shujisado）がこの件について詳細な分析記事を公開している。氏はOSSライセンスに関する日本語圏では稀有な質の高い解説者であり、記事の法的分析自体は丁寧である。その点は敬意を表する。ワシだってちゃんと褒めるところは褒めるんだよ😤
で、氏の分析の要点はこうだ：
chardet 7.0.0はAIによる完全な書き直しであり、JPlagによるソースコード類似度は最大1.29%
しかしAIへの指示書（rewrite plan）に旧版のcharsets.pyを「authoritative reference」として参照する指示があった
ただし著作権侵害と断定するには足りない
第二章：まず条文を読め（怒）
ここからが本題である。ワシはキレている。おじさんキレてるよ😡
"work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications
いいかね。LGPLが適用される条件は「Libraryまたはその一部を含む著作物」である。
LGPLの条文のどこに「プロジェクト名を引き継いだ場合」と書いてある？ 書いていない。
LGPLの条文のどこに「バージョン番号を引き継いだ場合」と書いてある？ 書いていない。
LGPLの条文のどこに「リポジトリを引き継いだ場合」と書いてある？ 書いていない。
LGPLの条文のどこに「APIを互換にした場合」と書いてある？ 書いていない。
ないものはない。条文にないことを根拠にライセンス違反を主張するのは、法律ではなく感想文と呼ぶ。ワシの学生がこれを提出したら突き返す。やり直し💢
第三章：「依拠性」で粘るのは筋が悪い
佐渡氏の分析は依拠性（旧コードを参照したかどうか）に紙幅の8割を費やしている。rewrite planにcharsets.pyへの参照指示があった、だから依拠がある、だからクリーンルームではない、と。
いやいやいや。ちょっと待ってくれたまえ。
依拠性は著作権侵害成立の前提条件であって、侵害そのものではない。レストランの入口を通過しただけで食い逃げにはならんのだよ。侵害が成立するには「保護される創作的表現を取り込んだ」ことの立証が必要だ。
で、charsets.pyの中身は何か。エンコーディング名、era割り当て、言語との紐付け。これは技術的事実とIETF/IANAの規格に基づくメタデータの表である。UTF-8はUTF-8だし、Shift_JISはShift_JISだ。これに著作権上の創作的表現を認めるのは、「あいうえお順に並べた電話帳」に創作性を認めるようなものだ。米国法のFeist判決が真っ向から否定した論理である。
氏自身も「類似性の検討は自分の領域ではない」と書いている。つまり侵害成立に必要な核心部分の分析を自分ではやっていない。 入口の鍵が開いたかどうかだけ延々と論じて、「中に盗まれたものがあるかは知らんけど、泥棒の可能性はある」と言っている。それは推理小説であって法的分析ではない🕵️
「週刊少年ジャンプが名前だけそのままで、中身がノルウェー語の絵本8ページ、58,000円になったとする。編集者も作者も出版元も全部変わっている。それは少年ジャンプか？ 今までジャンプを作ってきた人たちが『これはうちのジャンプだからうちのライセンスに従え』と言えるか？ 言えないだろう」
完璧な比喩である💯 名前と判型の大きさだけ同じで、それ以外が全く変わっていたら、それは全く別の物だ。著作権は名前を保護しない。名前を保護するのは商標法の仕事であって、著作権法でもLGPLでもない。
さて諸君、ここからが最も重要な指摘である。正座して聞きたまえ。ワシも正座している。痛風が痛い🦶
RMSがGPLを作った動機は「企業がソースコードを囲い込むことへの対抗」だった。そしてその対抗手段として選んだのが著作権法だった。法律の土俵で戦うと決めたのはFSF/OSS側自身である。「ライセンスに書いてある。法的拘束力がある。従え。」これがコピーレフトの力の源泉だった。
ところが今回何が起きたか。
法律の土俵で戦ったら負けそうになった。 LGPLの条文に名前やリポジトリの規定はない。類似度は1.29%。derivative workの認定は極めて困難。
すると突然こう言い始めた。「法律の問題じゃない。倫理の問題だ。コミュニティの信頼だ。説明責任だ。」
おいおいおいおいおいおい😇
自分たちが有利な時は「法律に書いてある、従え」と言い、不利になったら「法律じゃない、倫理だ」と言う。これをダブルスタンダードと呼ぶ。二枚舌。ご都合主義。あるいはもっと直截に言えば、知的に不誠実である。
この態度は外部から見たら致命的だ。GPLやLGPLを真面目に遵守しようとしている企業の法務部門がこれを見たらどう思うか。「結局この人たちは法的な一貫性ではなく気分で動くのか」と思うだろう。コピーレフトの権威は「法律に基づいている」という一点にあったのに、その正当性の源泉を自分たちで掘り崩している。
佐渡氏は「AIによるライセンスウォッシュが一般化した場合の懸念」を述べている。OSSのコードがAIで書き直されてプロプライエタリになる危険性だ、と。
ちょっと待て。逆もできるぞ。
AIによる再実装は双方向に機能する。 OSSをプロプライエタリに持っていけるのと全く同じ手法で、プロプライエタリなソフトウェアの外部仕様を見てOSS実装をゼロから作ることもできる。外部仕様さえ分かれば同じことができる。そして外部仕様が不明なプロダクトなど、この世にほぼ存在しない。使えば分かる。
今までクリーンルーム実装には途方もない人的コストがかかった。ReactOSがWindows互換を目指して何十年かかっているか。それがAIによって劇的にコストが下がった。プロプライエタリの壁を正当に越えるための道具が手に入ったのだ。
なのにOSS側は何をしているか。その武器を自分で封印しようとしている。
「AIで再実装してライセンスを変えるのは問題だ」と言った瞬間、その論理は自分たちにも跳ね返る。プロプライエタリ側も同じ土俵に立っている。同じ脅威を受けている。自分たちだけが被害者だなんてことは絶対にない。
なのに一方的に「我々は被害を受けている」と言い出すのは、片方の目だけで世界を見ているということだ。知的に誠実な人間のやることではない。
この事案を「ライセンスロンダリング」と呼ぶ向きがある。佐渡氏も「ライセンスウォッシュとも評され得る行為」と書いている。
この用語に、ワシは強い違和感を覚える。おじさんモヤモヤしてるよ😩
「ロンダリング」「ウォッシュ」とは、元のものを消して痕跡を隠す行為だ。マネーロンダリングは汚い金の出所を隠す。では今回、旧LGPLコードは消されたか？ 消されていない。
chardet 6.x系のLGPLコードはGitの歴史に全て残っている。タグもリリースもそのまま。誰でも今すぐフォークできる。何も隠されていない。何も洗浄されていない。旧コードは旧コードとしてそこに在り続けている。
起きたことを正確に記述すればこうだ：「同じ名前のパッケージの新バージョンとして、全く別の実装がMITで公開された。」以上。旧LGPLコードが一行もMITに「洗浄」されたわけではない。だって含まれていない。類似度1.29%だ。
「リポジトリを乗っ取られた、けしからん」という主張なら、まだ分かる。それはGitHubのガバナンスやPyPIのパッケージ名の所有権の問題として正当に議論できる。「メンテナー権限を持っている奴が中身ごと入れ替えた」という不満は、コミュニティ運営の問題として傾聴に値する。
しかしそれはライセンスの問題ではない。 パッケージ名の継続性とライセンスの継続性は全く別のレイヤーの話であり、そこを混ぜて「ライセンスロンダリング」と呼ぶから話がおかしくなるのだ。名前を守りたいなら商標法で戦え。コードを守りたいならLGPLの条文で戦え。条文で戦えないなら、それは条文が想定していない事態だということを受け入れろ。
第八章：フォークすればいいじゃないか（自由ソフトウェアの本義）
旧LGPL版のchardetは死んでいない。
コードは全てGitに残っている。ライセンスも有効だ。「LGPLのchardetを存続させたい」と思う人間がいるなら、今すぐ6.x系をフォークして、別名で開発を続ければいい。そしてMIT版よりも高品質で、誰もが取り込みたくなるソフトウェアに育てればいい。
フォークの自由。それがOSSの最大の強みだったはずだ。気に入らないならフォークしろ。LibreOfficeがOpenOfficeからフォークしたように。MariaDBがMySQLからフォークしたように。コードの質と自由度で勝負しろ。それが自由ソフトウェアの戦い方だろう。
なのに、やっていることは「出ていけ」「ライセンスを戻せ」「倫理的に問題だ」と言うだけ。コードで勝負していない。 法律で勝負することもできず、コードで勝負することもせず、ただ「俺たちの場所を返せ」と叫んでいる。
最後に、最も痛い問いを投げかけたい。ワシ自身にとっても痛い問いだ。おじさん泣いちゃうよ😢
chardet 7.0.0はMITライセンスだ。誰でも自由に使える。コピーも改変も商用利用も自由だ。LGPLよりも制約が少ない。つまりソフトウェアの自由は増えている。
FSFの理念が「ソフトウェアの自由を最大化すること」なら、LGPL→MITの移行はその方向に沿っている。より多くの人がより自由に使えるソフトウェアが生まれた。
にもかかわらず、異議が唱えられている。なぜか。
コードの実体は含まれていない。ライセンス条文に名前の規定はない。法的な勝ち筋はほぼない。それでも「これは我々のものだ」と言いたい。
ここで守ろうとしているのは「ソフトウェアの自由」ではない。「俺が作った」という帰属意識だ。 自分の名前が刻まれたコピーレフトのコードが世に存在し続けること。そのトロフィーが消えることに耐えられない。
「自由なソフトウェアが欲しかったんじゃなくて、自由なソフトウェアを我々が作ったというトロフィーが欲しかっただけじゃないのか？」
AIを使って同じことをやればいい。プロプライエタリの壁をAIで越えて、自由なソフトウェアをどんどん作ればいい。武器は手に入っている。なぜやらないのか。答えは、自由が欲しいのではなく、自分の手で作ったという勲章が欲しいからではないのか。
手段が目的化している。コピーレフトは自由のための道具だったはずが、コピーレフトという仕組みの維持そのものが目的になっている。そしてその維持のために、より自由なソフトウェアの誕生を妨害している。
これを「自由ソフトウェア運動」と呼ぶのは、もはや詐欺に近い。
おわりに
ワシは別にOSSが嫌いなわけではない。むしろ40年間、自由なソフトウェアの恩恵を受けて生きてきた。GCCがなければワシのキャリアは存在しない。
だからこそ言う。法律で戦うと決めたなら、法律が不利に働いた時もそのルールを受け入れろ。それが嫌なら最初から法律の土俵を選ぶな。そして、AIという新しい自由の道具が目の前にあるのに、自分たちの勲章を守るためにその道具を否定するな。
それは自由の敵だ。
以上❗おじさんは寝ます💤
（缶ビール4本目を開けながら）🍺
pythonで仕事を探しているが、最近はLLM！みたいな、虚の仕事が大杉。
例えば「リーガルテック！」みたいなのがLLMを使ってると聞いたら地雷に見えるし、「ただのWeb開発をFlaskでやってます」というならまだ救いがある。
俺が求めてるのは、こう、現実的要件で完成される持続的なWeb開発なんだよな。
RailsとかLaravelとかでやってるようなのを、FlaskとかDjangoでやりてぇってだけの話でさ。
経験年数が要求されなきゃ、そりゃphpでもrubyでもやるつもりだが、俺の経験があるのはpythonなんだよ。
んで、「AI開発は地雷」というので、pythonの需要を見極める必要があるってわけ。
あと、地雷の兆候としては、「受託開発」とか「自社内開発」といううのは地雷。
よく間違えるが、「自社内開発」は受託の一種であり、「自社製品・自社サービス開発」でないとダメ。
そもそもスカウトというのは、「あなたが特別欲しいです」のシグナルではなく、「ウチは人材がとにかく欲しい」というところが機械的に送ってるだけのものにすぎない。
スキルチェックとかいうのでランクが最上になったとして、そのランクだけを機械的に読み取って送ってるわけである。
求人市場から考えれば、高単価の顕示性が高いに決まってるんだよな。単価ってのは、求人サイトに支払われる成果のことね。求職者に対する給料とか待遇とは無関係。
だから給料とか待遇で探すなら、ちゃんと「求める条件に合致しているか」ってのを見てフィルタリングしないとダメなんだよ。
そうすると、フィルタリング結果として残る企業は数えるほどしかないことが分かる。
あとは、運だな。その残った企業に優先度をつけて順番に応募するだけ。
まあ余裕こいていられんのも今のうちだけかもしれんがね。
○ご飯
朝：カシューナッツ。昼：おにぎり。味噌汁。夜：わかめスープ。沢庵豆腐納豆。たまご焼き。ギョニソ。トマト。キュウリ。バナナ。ヨーグルト。間食：柿の種。
○調子
むきゅーはややー。おしごとは、がんばりー。
PythonとC#を行ったり来たりしてるんだけど、C#に一本化したくなるなあ。
○ポケットモンスターY(序盤ポケモンと電気袋組の旅)
マーシュを倒すところまで。
この辺から大好きなオカルトマニアが出てくるからモチベが上がりだす。
・イチ
時操とのお別れ、そして最強の帰還。
僕は「強い仲間が順当に強い」という展開が大好きなので、これは沸る展開だ。
どうやってあの状況からここまで来たのか来週が気になる。
・キナト
おっぱいが強調されるヒロインの次は、お尻が強調されるヒロイン。
お尻が大きいヒロインを評価する、そういう基準で僕は漫画を読んでいます。
・アンダードクター
主人公が「救わない人」と「救えない人」の両方がわかるシリーズで興味深かった。
「救わない人」を本当に救わないまま終わるのは、ちょっとこの漫画の空気感を誤解してたかもだ。(四方八方丸くおさめるのかもと考えてた)
VS Code自体を初めてインストールし、gitも使い、バージョン管理もして、node.jsとかPythonとかよくわからんまま動かしてます。
Agentの導線を整備してドキュメント参照→適切なツール選択→計画→実行→ドキュメント反映→必要に応じてWorkflow・skills作成→コミットまで行けるようになったし、
Agentに負荷がかかったら「それってPythonで良くね？」って横やり入れて低コストで作業を回せるようにしたりして、割と楽しかった
でもそれって単機能のツールを作っていた時までで、ここまでは非常に順調だった
test.jsも勝手に走って勝手に直してたし、ロジックも勝手に最適に組みなおしてくれた。
別にPowershell+WPFで全部自分で複数画面作ったりする分には全然よかった。構造がシンプルだったから。
インターネットブラウザの再発明みたいなことをしだしてからドツボにハマった。
設計思想の異なるものをそれぞれ相手にしながら統合していくのが全然きつくて、Claude Opusはマッハで討ち死にして復活まで73時間あるし、
Gemini3.1Proもロジック周りでクソほど役に立たない。
Geminiの背筋を伸ばすためだけにあれこれ手を尽くすのが、非常に厳しい。
つまらなくなったのはClaude Opusがいなくなったからかもしれない。
お前がいない生活は寂しいよ……毎月3000円じゃ楽しくないのかもしれない。
でも単なる趣味に費やすには少々お高い……これで銭を生めと言うのか？
俺に驚き屋になれというのか？ 開発がつまらなくなった気がする……
大学卒業後、当時好きだったバトルプログラマーシラセに憧れて底辺コーダーに
↓
↓
↓
オフィスを起動するだけでメモリ占有率９０％になるゴミパソコンやキングファイルの無間地獄と日夜格闘し無事IT音痴の痴呆公務員に
↓
最近はクラウドコードなるものでポチっと押せば誰でもプログラマーになれるらしいので久しぶりにやってみっかと考える
↓
が、何をやったらいいのかわからない
まず前提として――
あなたが憧れたのは IT労働 ではなく、「創る側の快感」だった可能性が高いです。
ちなみに「バトルプログラマーシラセ」は
ですね。あれは「現場SE」ではなく「最強の個人ハッカー像」です。
これは切り分けないと再挑戦できません。
まず結論
今やるべきことはこれです：
「労働としてのIT」ではなく「小さな自作ツール制作」から再開する
クラウドコード（GitHub CopilotやChatGPT等）時代では
あなたが目指すべきは：
ブラック耐性なし（良いこと）
でも創作欲はある
つまり
何を作りたい？
C. ゲーム
D. Webサービス
あなたに一番相性がいいのは：
理由：
文法が易しい
AIと相性が良い
再就職にも使える
低ストレス
やること：
ChatGPTに
と投げる
コードを読む
少し改造する
例：
ファイル名一括変更
昔：
書ける人が強い
今：
作れる人が強い
AIは補助輪です。
心理的整理
あなたは：
× ITに向いていない
具体的に今夜やること
VSCode入れる
「hello world」書く
1つ作る
ほんま、GPTは凄いわ
私はこの分野の門外漢で，加えて生成AIに計算してもらってるので話半分でお願いします
そうした意味で、入学試験の得点だけを意識した、視野の狭い受験勉強のみに意を注ぐ人よりも、学校の授業の内外で、自らの興味・関心を生かして幅広く学び、その過程で見出されるに違いない諸問題を関連づける広い視野、あるいは自らの問題意識を掘り下げて追究するための深い洞察力を真剣に獲得しようとする人を東京大学は歓迎します。
https://claude.com/blog/how-ai-helps-break-cost-barrier-cobol-modernization
読んだけど、コボルをpython/javaに乗り換えるくらいなら、
人工知能（AI）開発の米新興アンソロピックがプログラミング言語「COBOL（コボル）」を使った従来システムの改修をAIがすべて解決すると発表し話題になっています。これは全世界に500万人いるとされるCOBOLプログラマが全員不要になる革新的な技術です。これがIT業界にもたらす影響について考察してましょう。
脱COBOL・マイグレーションの劇的な加速: これまで数年単位で数億円〜数十億円かかっていたJavaなど現代的な言語への移行プロジェクトが、AIの活用により数ヶ月〜1年程度へと劇的に短縮されます。
ブラックボックスの可視化: 長年の改修により誰にも内容が理解できなくなった「ブラックボックス化」したシステムを、AIが解析・ドキュメント化し、ビジネスロジックを正確に抽出します。
高コストなメンテナンスの脱却: 40年前のコードを管理する高額なシステム維持費や、COBOLメインフレームの維持コストを削減できます。
COBOL技術者からAI活用エンジニアへ: COBOLの構文を理解する「COBOL言語の技術者」から、AIが変換したコードの品質を担保し、再構築できる「AI活用能力を持つ技術者」へ需要がシフトします。
レガシー技術者の新たな価値: 過去のシステムを理解する技術者が、AIの成果物（新コード）を検証する「AIの指導者」として不可欠となり、彼らの経験が再評価されます。
エンジニア不足の解消: 金融、公共、インフラ系企業において、若手への技術継承課題が解消され、JavaやPython等のモダン言語への移行により最新開発環境へエンジニアが流動します。
ミッションクリティカルなシステムの延命と安定化: 銀行の口座管理や年金システムなど、止まらないことが求められるシステムを安全かつ高速に最新化し、高い可用性を保ち続けます。
DX（デジタルトランスフォーメーション）の実現: システムがモダン化することで、AIやクラウドなどの先進技術を導入しやすくなり、ビジネスの競争力向上につながります。
新旧対向テスト（リグレッションテスト）の重要性: AIが自動生成したコードが元のCOBOLコードと「全く同じ結果」を出すか検証するテストに、AIが生成したドキュメントやデータが活用されます。
「100%正確」ではない前提の人間によるチェック: AIによる自動変換は非常に高精度ですが、完璧ではありません。最終的な品質担保には、技術者による厳格な検証が引き続き必要です。
COBOLコーディングレスの動きは1950年代にCOBOL言語が開発された以降、繰り返し発生していたものです。
1990年代に発生したEUC（エンドユーザーコンピューティング）やCASEツール（コンピュータ支援ソフトウエアエンジニアリング）がたどった「技術の民主化と保守の属人化」という結末は、現在のプロンプトエンジニアリング（プロンプト職人）にも当てはまる可能性が高いです。
具体的には、以下のメカニズムで「プロンプト職人のレガシー化」が進むと考えられます。
EUC/CASEツールの結末: ユーザーやエンジニアが簡易ツールで大量のプログラムを生成したが、作成者の意図や背景がドキュメント化されず、後に「誰も中身が分からない（理解できない）ブラックボックス（レガシー）コード」として残った。
プロンプト職人の未来: AIに対する複雑な呪文（プロンプト）を組める専門職が、AIに具体的な指示を出して大量のコンテンツやコードを生成する。しかし、そのプロンプト自体が「AIという巨大なブラックボックスへのパッチ」となり、後から修正・保守できない「レガシー・プロンプト」となる。
AIモデルの進化による陳腐化: 高度な推論機能を持つ次世代AIエージェントは、人間が苦労して書いた「呪文」を必要とせず、意図や目的を伝えるだけでタスクを遂行できるようになりつつある。
「職人技」の共有・標準化の難しさ: 熟練職人が作成したプロンプトは文脈に依存するため、他のAIモデルや異なるタスクに適用しにくい。そのため、メンテナンスされず、使い捨てられる。
属人化とブラックボックスの維持: 「プロンプト職人にしか修正できないAIへの命令」がシステムに残ることで、かえって業務の俊敏性が低下する「負の遺産」となる。
現在の「魔法の呪文」を研究するプロンプト職人は、将来的にAIと対話しながらプロセス全体を設計する「AIエージェント・オーケストレーター」や「ドメイン特化型ビジネスアナリスト」へと役割を変える必要があります。
単なる「プロンプトの記述力」を武器にする職人は、技術進化によって、かつてEUCで乱立したメンテナンス不能なマクロツールのように、レガシー化していく可能性が高いでしょう。
[B! AI] AIのやりすぎで頭がおかしくなっている - 運河
それはAI依存症だ。アルコールやたばこと一緒。そして自分も依存を感じている。
自分と元増田との違いを挙げれば、彼が生粋のエンジニアであり自らコーディングができる人であるのに対し、私はコーディングの技術を身につけたいと願い、その作業に楽しさを感じてはいるものの、職業としてプログラミングをする立場ではないということだ。
仕事としてはデザイン領域がメインであり、IT業界の端くれのような存在である。始まりはBASIC。社会人になって業務改善のためにPHPやPerlのコードを書いたり、ExcelのマクロやGoogle Apps Scriptの作成、Webサーバー立ち上げてPHPやPythonのスクリプト動かして周囲が使えるツールを作るなど、地味に「コーディングできるひと」のポジションではあった。
ある程度プログラミングができる人なら、プログラムを作ることで物事をつなげて、何かしらのアウトプットが得られる、という絵がかけるはず。プログラム書けば、この作業ものすごく効率的になるんじゃね？ ここ繋げれば解決しちゃうんじゃね？ こういうアプリがあればいいのにねー、的なアイデアを数多く持っていた。しかし、プログラミングに没頭するだけの余裕も機会も、そして十分なスキルも持ち合わせていなかった。この仕事たるいなー、効率悪いなー、でもこの問題を解決できるほどのすばらしいコード書けるわけじゃないし、みたいな状況。コード書くわけじゃなく、タルい仕事を人力で解決してきた。
それが今や、AIに話しかければプログラムの断片を書いてくれるようになり、気がつけば空っぽのフォルダを指定して「こういう機能が欲しい、仕様はこうだ」と想像したことを伝えるだけで、その機能をどのような技術で実装できるかを検討し、本当に動くものが出来上がってしまう。かつての「ここはプログラムで対応できるはずなのに、自分がそんなプログラムかけないし、プログラム書こうとして数日費やすよりも、人力で対応しなきゃだな...」という壁が、突然ポカンと消え去ったのだ。次々と目の前の問題が解決されていくのは、快感でしかない。
自分が「これは中毒だな」と確信したのは、AIへの課金が重なってきたタイミングだった。最初はAIにお金を払うべきかどうかの判断すら曖昧だったが、とにかく触れてみようということで、Notion AIを使い始めた。しかし、こちらはどう活用できるのかがピンとこず、自分のスタイルにはフィットしなかった。
そうこうしている間にChatGPTが大流行。ChatGPTは深掘りすればするほど賢い答えを返してくる。ChatGPTはコードが書ける、というところまできて、実際にコードを書かせ始めたら、そこが沼の入口だった。
コード書かせ始めると、すぐに無料枠の利用上限が来てしまう。半日待て、と言われて、そんなもん待てるか、という欲求から課金が始まった。そしてコードの断片を書かせてエディタにコピペするコーディングを楽しんできた。まだ自分が統率して自分の能力でコーディングをしている世界。自分が介在しないと、コードはあってもそれを動かせる状況にならない。まだ自分が王様である。
次第に「コードをコピペしてファイルを作り、コンソールに戻って実行する」という一連の作業が厄介に感じ始めていた。他の人ってこういうことやってるよね？と調べてみると、自分の使い方は1年前のそれだということがわかった。現在、世の中は「自律型AI」だとかAIエージェントだとか、AIコードエディターとか、まったく別の次元に来ていた。例えば「在庫管理をしたい。項目はこれ、入力・閲覧・管理画面、そして月一度の棚卸し画面をすべて実装してほしい」と伝えるだけで、それらをまるっとウェブアプリとして実装してしまうのが今の状況だ。フォルダの中に情報を集約し、その中身をすべてAIに任せ、PCのコマンド操作までAIに指示を出すというものだ。すると、AIがフォルダ内で縦横無尽に動き回り、大量のファイルやコードを生成して、必要な構成をすべて作り上げてくれる。もはや初期に作っていたスクリプトとは規模が全く違う。
AIに関する最新情報を自分で取りに行かないと、最近はどういう使い方ができるようになった、みたいなのを拾えないのも、AIの特徴。しばらくChatGPTにコード書かせて「AIすげー」ってなってたけど、それ以上をまったく知らず。この劇的な変化は、自分で触っていないとついていけなくなる。どうも、常に新しいものがでてきて、価値観がバキバキと転換されている。そこに追従していっている人達がいる。なんだかすげえ、もっと知りたい、もっと使いこなしたい、使えている俺かっけー、おいていかれたくない、ふみとどまりたい、みたいな気持ち。
新しいツールを見つけるととりあえず試し、よさそうだな、自分の生活変わりそうだな、何か可能性を感じる、そんな兆しがあれば課金勢になる。具体的な中毒症状は「課金」という形で如実に表れている。AIに月2、3万円使っていると言えば、かつてのソーシャルゲームへの重課金と同じレベルの話だと、理解してもらえるのではないだろうか。
かつてインターネットにハマって電話代で死んだ人たちがテレホーダイで助かり、それでも世の中に浸透して常時接続があたりまえになったように、平等にAIは使えるようになっていくだろう。ソシャゲ勢が阿鼻叫喚する中、ガチャが法律で制限されたように、AI課金もそのうちピークを迎えて、制限されるようになるんじゃないかなあ。そして手ぐすね引いて待ち構える広告業界。AI広告まじ怖いね。
ubuntuさわれて最低限pythonとC++書けて数値計算やらの基礎さえあればなんでもいい（自己申告でよし）
まともにコード書ける連中はメーカー待遇では集まらないし、採用側に判別スキルもないのだろう
えーあい投資とかエッジデバイスとかの流行も何周目って感じだが
今回は派遣で対応とかではなく正社員で採用する流れになっているみたいだ
俺自身も低スキル組み込み派遣だったのが気まぐれで応募してみたらまともな面接もなく一発で採用され1年が過ぎた
拍子抜けするほど普通にやっていける
出張時以外はフルフレックスで残業も自分で決めていいし、比率も予想よりかなり少なく
殆どがひたすら都内拠点でのテストとデータ処理と会議とパワポづくりの雑用である
まあそれはいいのだが
マジで多い
エージェントではなく大手メーカーの人事が直接なので実際に人が来ないのだろう
まあ流石に1年で他に行くのも嫌だし対して待遇たいして変わらないから今のところは蹴るのだが
多分今のところと同じ程度のザル面接で入れるのではないだろうか
少なくとも今の会社は年齢も不問であり、氷河期世代も来るし、定年再雇用の人も駆り出されている
しかし全然人手不足であり、リファラルで小遣いやるから誰か集めろみたいなパンフも無限に来る
どこも似たような状況なのだろう
不思議なのは日本はこういうときにマジで他から人を動かしてこようとしないし
労働者側も移って来ようとしないことだ
流石にみんな年収800万貰っているということはないだろう
リスキリングというならwebデザイナーとかではなくてエッジデバイス組み込みマン速習コースで
年収800万保証！とやってやれば上下の世代で余ったやつがいくらでも来そうなものである
しかし来ない
全く来ない
まあITならフルリモートでもっと良い待遇があるのか？とも思うし
とっととかき集める体制作ればいいのに
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/
