コードが「実質無料」になった今、エンジニアは何を学ぶべきか
コードが「実質無料」になった今、エンジニアは何を学ぶべきか
「2025年にコード生産のコスト構造が根本から変わった。コード生成は実質タダになった」— Charity Majors（Honeycomb, CTO）2026年6月
この一言が、今のソフトウェア業界の現実を鋭く切り取っています。LLMがコードを書く時代に、ジュニアエンジニアはどう生き残ればいいのか。今日は3つのトレンドを軸に考えます。
1. AI｜オープンウェイトLLMの新星「GLM-5.2」が登場
所要時間: 約5分で概要把握
GLM-5.2とは？
中国のAIラボ Z.ai が2026年6月に公開した、テキスト専用オープンウェイトLLMです。Simon Willison（著名なPython/LLM評論家）が「現時点で最も強力なテキスト専用オープンウェイトモデル」と評しました。
ポイント:
- MITライセンス（商用利用・改変・再配布すべて自由）
- 6月13日にサブスク向けに先行公開、翌週にオープンウェイトを一般公開
- テキスト推論・コード補完に特化（画像なし）
なぜ重要か？
GPT-5やClaude Opus 4.8などのクローズドモデルと肩を並べる性能が、無料・自前サーバーで動かせるようになりました。企業がプライバシー・コスト・レイテンシを理由にクラウドAPIを使えない場面で、初めて「まともな選択肢」が生まれた意味を持ちます。
ステップ（試し方）
- Hugging Face で
GLM-5.2を検索 ollama pull glm-5.2（Ollamaがインストール済みなら）でローカルダウンロードollama run glm-5.2でチャット開始- 自分の業務コードをコピペして補完・レビューを依頼してみる
- 速度・品質をClaude Haiku 4.5と主観比較してメモ
今日から試せること: Ollamaをインストールし、GLM-5.2をローカルで動かして「コードレビュー依頼」を投げてみる。クラウドAPIなし・費用ゼロで動作確認できます。
2. ソフトウェアテクノロジー｜AIエージェントが脆弱性を自動発見する時代
所要時間: 約7分で概要把握
マルチエージェントLLMによる脆弱性発見とは？
Hacker Newsで話題になった研究（2026年6月）で、LLMを攻撃役・防御役に分けたマルチエージェントシステムが、ソフトウェアの脆弱性を自動的に発見→再現→レポートするまでを完全自動化できることが示されました。
どういう仕組みか？
- エージェントA（攻撃役）: ターゲットのコードやAPIに対して各種攻撃パターンを試みる
- エージェントB（検証役）: 発見された脆弱性が「実際に悪用可能か」を再現・確認する
- オーケストレーター: 両エージェントの結果を統合してバグレポートを自動生成
以前は熟練したペネトレーションテスターが数日かけていた作業が、数分〜数時間に短縮されます。
影響を受ける仕事・スキル
| 変わること | 変わらないこと |
|---|---|
| 初歩的な脆弱性スキャン作業 | 報告書の判断・優先順位付け |
| CVEデータベース照合 | ビジネスリスクの評価 |
| 再現テストの手動実施 | 倫理・法的判断 |
ステップ（エンジニアとしての対処）
pip install bandit safety— Pythonコードの静的セキュリティ解析ツール導入bandit -r ./srcを CI パイプラインに追加- GitHub Actions の
dependabotを有効にして依存関係脆弱性を自動検知 - 週1回、
npm audit/pip-auditを手動実行して出力を読む習慣をつける
今日から試せること: 自分のプロジェクトで pip-audit か npm audit を初めて実行し、何件の警告が出るか確認する。
3. セキュリティ｜LLMの誤検知がカーネルを壊す問題と日本の対策ガイドライン
所要時間: 約5分で概要把握
起きていること（二つの側面）
問題①: LLMが作った「偽の脆弱性レポート」でLinuxカーネルのコードが削除される
2026年4月、LLMが生成した不正確なセキュリティレポートを根拠に、Linuxカーネルのコードが不要に削除される事例が複数発生。LLMはもっともらしい文章でバグを「でっち上げる」ことがあり、人間のレビュアーがそれを見抜けなかったケースです。
問題②: AIシステム自体が攻撃対象になる
- プロンプトインジェクション: 悪意あるテキストをLLMに読ませることで、意図しない動作をさせる攻撃
- データポイズニング: 学習データに毒を盛り、モデルの挙動を歪める
- エージェントハイジャック: 自律的に動くAIエージェントを乗っ取り、外部APIを悪用させる
総務省が日本初のAIセキュリティガイドラインを公表（2026年3月）
「AIのセキュリティ確保のための技術的対策に係るガイドライン」が2026年3月27日に公表されました。主な内容：
- AIシステムをブラックボックスとして扱わない: 入出力の記録・監査ログの整備
- LLM出力を「信頼できない外部入力」として扱う: SQLインジェクション対策と同じ発想
- エージェントにはサンドボックス・最小権限原則を適用
ステップ（セキュリティ視点での開発習慣）
- LLMが生成したコードは必ず人間がレビューしてからコミット（自動マージは禁止）
- AIエージェントが触れるディレクトリ・APIを最小限に限定（Principle of Least Privilege）
- LLMへの入力に外部データをそのまま渡さない（サニタイズしてから渡す）
- 定期的に
git log --all --onelineで「誰（何）がいつコミットしたか」を確認する
今日から試せること: 自分のリポジトリで、AIが生成したコードのコミットに [AI-generated] タグを付けるルールを導入する。後から見直しやすくなります。
AIによる考察
コードが「実質無料」になった今、価値は**「何を作るか」の判断と、「それが正しいか」の検証**に移っています。
LLMは平均的なコードを爆速で生成できます。しかし「このコードはビジネスリスクがあるか」「このレポートは本当に正確か」「この設計は5年後に負債にならないか」は、まだ人間にしか判断できません。
特に危険なのは、LLMの「もっともらしさ」を過信することです。カーネルコード削除の事例は、AIが生成した文章の流暢さと正確さを混同した結果です。
ジュニアエンジニアに今すぐ勧めたいのは：
- AI出力を疑う習慣をコードレビューに組み込む
- セキュリティの基礎（OWASP Top 10、最小権限原則）を自分の言葉で説明できるようにする
- オープンウェイトモデル（GLM-5.2など）を使い、AIの中身の感覚をつかんでおく
関連記事
1. GLM-5.2 is probably the most powerful text-only open weights LLM
Simon Willison（2026年6月17日）が解説するZ.aiのGLM-5.2。テキスト専用ながらGPT-5クラスに匹敵する性能をMITライセンスで公開。ローカル実行可能なため、プライバシー重視の企業ユースケースに大きな可能性を秘める。オープンウェイト競争の新章を告げる一本。 simonwillison.net/2026/Jun/17/glm-52/
2. Multi-Agent LLM System for Automated Vulnerability Discovery and Reproduction
Hacker News（2026年6月）で話題の研究。LLMを攻撃役・検証役に分けたマルチエージェント構成が、ソフトウェア脆弱性の発見から再現レポートまでを全自動化できることを実証。セキュリティ専門家の役割と、AIが代替できない判断領域を改めて問い直す。 news.ycombinator.com/item?id=48297723
3. Kernel code removals driven by LLM-created security reports
Hacker News（2026年4月22日）で議論された問題事例。LLMが生成した不正確な脆弱性レポートをもとにLinuxカーネルコードが削除された経緯を分析。AI出力の「もっともらしさ」と「正確さ」の区別がいかに難しく危険かを示す実例として必読。 news.ycombinator.com/item?id=47862230
リサーチ注記: simonwillison.net、news.ycombinator.com、dev.classmethod.jp はWebFetchが403のため、検索スニペットを情報源として使用。