ソフトウェアエンジニアリングの基本がより重要である

2026年8月16日原文(rhonabwy.com)

概要

インポスター症候群 と ソフトウェアエンジニア の本質についての考察
エージェント的開発ツール の進化と現状分析
LLM（大規模言語モデル） の限界と使い方の工夫
ソフトウェア開発で重要な アーキテクチャ設計 と トレードオフ の選択
今後の展望 とコミュニティから学ぶ意義

ソフトウェアエンジニアとは何か

インポスター症候群 が浮き彫りにする、ソフトウェアエンジニアの本質的な役割
インターネット上の エージェント的エンジニアリング に関する情報のノイズとシグナル
開発時の選択 の重要性、特にシステムやソフトウェアのパズルを解く際の意思決定
大手モデルプロバイダー の誇大広告や過剰なマーケティングを超えた実用的なツールの発見
目立たないが優秀な開発者が 本質的な成果 を上げている現状
- Archimedesのレバー理論になぞらえた、 テクノロジーの活用
エージェントハーネス の進化と「できるかどうか」の壁を越えた現状

LLMとエージェント開発ツールの現状

知識の無断利用 や経済的な問題、モデルのビジネス性の疑問
オープンウェイトモデル の普及により、個人PCでも高性能な処理が可能
「できるかどうか」は出発点に過ぎず、 本質はその先 にある
溶接の例えから学ぶ、 構造設計の重要性
エージェントハーネス を用いた開発で「動作する」だけでなく、「テスト可能」にする工夫
コードの API設計 や他ソフトウェアとの結合部分（シーム）の難しさ
主観的な判断 や経験が求められる、長期運用を見据えた設計

LLMの限界と今後の課題

デバッグ性・保守性・レイヤリング・コンポーザビリティ の確保の難しさ
LLMは推論ではなく予測 を行う仕組み
人間の知識を圧縮し出力するため、 人間の推論の痕跡 がないと再現できない問題
LLMの推論力の限界を指摘した論文「 The Illusion of Thinking」の紹介
JEPAモデル や LeWorld Model、 Yann LeCun の講演など、推論を目指す最新研究への注目

LLM活用の工夫とリスク

LLMをより効果的に使うための工夫
- 適切なデータ提供 と 決定的な検証ツール、自然言語フィードバックの活用
ツール呼び出し や 指示の遵守 の精度向上
Simon Willison による「 lethal trifecta」のリスク指摘
- LLMは良い助言と悪い助言を区別できず、 プロンプトインジェクション攻撃 を完全に防げない
アラインメント や サンドボックス による安全対策の限界
推論力がないまま指示に従い続けることの危険性
RLHF （強化学習による人間フィードバック）で推論の痕跡を含める今後の期待

本質的なソフトウェア開発スキル

インターフェース設計 や 保守性・デバッグ性 を重視した開発の重要性
システムの継続的な見直し・修正 が求められるスキル
簡単に実装できる時代だからこそ、 本質的な設計力 の重要性が増す現状
ソフトウェアの職人技 を共有するコミュニティの価値
唯一絶対の解答がない、常にトレードオフの選択を迫られる開発現場
認知負荷の管理、安定性が必要な部分と柔軟性が求められる部分の見極め
抽象化の選択と再設計 による最適化

まとめ

ソフトウェア開発 は、ツールやAIの進化で変化しているが、 本質的な設計力と判断力 が不可欠
LLM や エージェントツール の活用には課題と工夫が必要
コミュニティや過去の知見 を活かし、より良いソフトウェアを目指す姿勢

Hackerたちの意見

生成されたコードは、ディレクトリ構造やインターフェースデザイン、全体の状態管理がめちゃくちゃになってることが多いよね。どんなに優れたフロンティアモデルでもそう。でも、ほんとにイラッとくるのは、モデルが自分がプロンプトで指定してない前提を勝手に作っちゃうこと。例えば、「これやばいから逃げるべき」っていうエラーステートと、「これは致命的じゃない」っていうのを区別するような微妙なところ。たまに聞いてくることもあるけど、ほとんどの場合は勝手に決めちゃって、しかもそれが間違ってることが多い。完全に整ったテストスーツと、最終製品を確認するための良い型チェッカーがないと、ループ処理なんて自分には役に立たないし、結局は出力されたコードの一行一行を見直して、何年もかけて培ったアーキテクチャの経験を活かさなきゃいけないんだよね。

└

だって、そういうのは答え方がわからないマネージャー向けに作られてるから、質問されるのも嫌なんだよ。魔法の答えボックスに何か選ばせるだけでいいんだ。

└

彼らは、タスクを一発で完了させるために、命がけでRLHF（人間フィードバックによる強化学習）されてるから、人間の入力を必要とするのは労働力を置き換える目的に反するんだよね。でも、この狂気が終わったら、LLMは開発者が生産性を上げるためのツールとしてパッケージされるようになるし、IDEやデバッガーみたいに扱われるようになると思う。ただ、このハイプサイクルを乗り越えないとね。

└

生成されたコードは機能的には問題ないし、ディレクトリ構造もそのプロジェクトのタイプに応じた標準パターンになってることが多い。エラーの種類やコードも仕様通りに出力されるよ。「あれを作って」って入力すると、たぶん自分の望むものにはならないけど、仕様とガイダンスを与えれば、だいたいはうまくいくよ。ただ、インターフェースデザインは…あんまり良くないけどね。

└

どんな状況でもクラッシュしたりエラーが出たりするコードが大嫌いなんだ。だから、疑わしいフォールバックをたくさん追加する。

└

でも、本当に気になるのは、モデルがしばしば俺がプロンプトで指定していない仮定をしようとすることだ。これはあなたの指示や仕様の問題だよ。LLMは心を読む存在じゃない。要件が欠けていたり曖昧だったりしても、成功しようとするんだ。

└

これは解決できる問題だと思うよ。普通のソフトウェア開発者がディレクトリ構造やインターフェースデザイン、一般的な状態管理、エッジケースや微妙な仮定の問題に対処できるなら、AIシステムもこれらの問題に対処できるように訓練することは可能だと思う。ソフトウェア開発は神秘的な魔法のような活動じゃないしね。自動運転についても似たような議論があったのを思い出すなぁ…

└

ほとんどの場合、ただ決定を下すだけで、それが間違った選択であることが多い。これらのチャットボットは出力オプションを選ぶためにランダム数生成器に依存していることを忘れないでおこう。

LLMは「推論」しないってことを知っておくといいよ。彼らは予測するんだ…意味論を。予測がトレーニングの目的だからね。推論する能力は、それの派生的な特性と言えるかもしれないし、かなり議論の余地があるけどね。

└

それが本当だとしても、やっぱりそれが出現したことを証明しなきゃいけないよね。

└

なんで「推論」が予測の派生的な特性になるの？

└

もしかしたら、それは推論に見えるのかもしれないし、それで満足する人もいるかもしれないね。

Hacker Newsで議論の続きを見る

ハクソク