ゆっくりすることについての考え

2026年3月25日原文(mariozechner.at)

概要

エージェント型AI の導入による ソフトウェア開発現場の混乱 について分析
エージェント任せの開発フロー がもたらす問題点とその根本原因を指摘
複雑化・品質低下・学習の欠如 などのリスクを具体例とともに解説
現時点でのAIエージェント活用法 とその適切な運用指針を提案
人間による最終チェック の重要性と、開発速度よりも 品質重視 の姿勢を推奨

業界の現状とエージェント型AIの影響

2023年以降、Coding Agent が登場し、誰でも簡単にプロジェクト構築が可能な時代へ
AnthropicやOpenAI による無料枠の提供で、多くの開発者がエージェント体験を開始
開発の民主化 が進む一方で、 ソフトウェアの品質低下やバグの増加 が顕著
MicrosoftやAWS など大手でもAIコード生成が進むが、 安定性や品質の問題 が露呈
AI主導の開発 による「 複雑で壊れやすいシステム」の増加

エージェントと「壊れた開発現場」

エージェント任せの開発 は、 コード量の増加 を最優先しがち
設計判断やレビューの放棄、不要な機能の乱造が常態化
Beads のようなツールを無批判に導入し、 セキュリティリスク を招く事例も
「 次世代LLMなら直るはず」という楽観論が蔓延
小規模な趣味プロジェクト なら問題が表面化しにくいが、 実用的なソフトウェア では失敗例が多発

エージェント活用の失敗パターン

エージェントは同じミスを繰り返す 傾向、学習や改善ができない
人間はボトルネックとして自然に品質制御 を行うが、エージェントは 爆発的なペースでバグを蓄積
エラーや設計ミスが複利的に積み重なり、後で修正困難なモンスターコードベース が誕生
テストコードも信用できなくなり、最終的には手動テスト頼み の状況に

エージェントが生む「学習済み複雑性」の罠

設計や意思決定をエージェントに丸投げ することで、 複雑性の商人 と化す
エージェントは部分的な情報しか持たず、全体最適化ができない
コード重複や無意味な抽象化が頻発 し、人間と同じく「エンタープライズ地獄」に短期間で到達
大規模コードベースではエージェント自身も管理不能 となり、 修正やリファクタリングも困難

「Agentic Search」の限界

エージェントによるコード検索（Agentic Search）はリコール率が低い
ツールやインデックスを駆使しても、巨大なコードベースでは必要な箇所を見逃す
結果として、コードの重複や不整合が拡大し、複雑性が加速

現時点でのエージェント活用指針

エージェントは部分的・限定的なタスク に使うのが最適
- システム全体を理解不要な範囲 での利用
- 自動評価可能なタスクや、非ミッションクリティカルな用途 への適用
- アイデア出しやラバーダック的用途 としての活用
最終的な品質チェックは人間が担うべき
エージェントのアウトプットはあくまで「たたき台」 として活用し、 本番品質には人間の介入が不可欠
開発速度よりも「何を作り、なぜ作るのか」熟考する時間を持つことが重要

まとめ：エージェント時代の開発で大切なこと

AIエージェントは強力なツールだが、万能ではない
全自動化・丸投げは短期的な効率化と引き換えに、長期的な混乱と品質低下を招く
人間の判断・設計・レビューが不可欠
「ゆっくり進めて考える」姿勢が、最終的な価値と品質を守る鍵

この内容は、 現代のAI活用開発現場で陥りやすい罠 と、 それを回避するための具体的な指針 を示しています。 エージェントの力を正しく引き出すためには、人間の役割と責任を見失わないことが不可欠 です。

Hackerたちの意見

ソフトウェアが脆弱な混乱状態になっている感じがするね。98%の稼働率が例外じゃなくなってきて、大きなサービスでもそうなってる。20年間こういうシステムを運用してきた者として言うけど、ソフトウェア自体は変わってない。変わったのは、以前は誰も何も信じてなかったから、人間が手動で全てをやらなきゃいけなかったこと。これがプロセスを遅くして、欠陥が起こる頻度を下げてた。でも、結局それもクソだった。すごく遅いクソで、手動テストや視覚的検証が多かった。失敗はまだたくさんあったけど、ステータスページで間隔が空いてるとあまり失敗してる感じがしない。「稼働率」は時間に基づいていて、コードの行数あたりのバグ数ではない。DevOpsの目的は、物を壊さずに素早く動けることを教えることだけど、それには特定の働き方が必要で、信頼を築くことが重視される。ランダムなものを100倍速で出荷して、うまくいくと思ってはいけない。これが「速く動いて物を壊せ」って言ってた人たちが数年前に学んだこと。物を壊すこと自体は悪いことじゃない - もし失敗から学んで、その後システムを改善できるならね。問題は、それが余分な作業になって、みんなやりたがらないこと。もし部屋に大人がいなくて、みんなを改善させる力がなければ、過去1ヶ月の災害が起こる。例を挙げると、GoogleのSREはチームにエラーバジェットを与える。SREが部屋の大人の役割を果たして、チームに出荷を止めて品質の問題を直させるんだ。DevOpsやリーン、TPSでこれに対処する方法の一つがアンドンコード。トヨタで導入された有名なコードで、どんな組立作業者でも問題が特定されて修正作業が行われるまで生産ラインを止めることができる（即時の欠陥だけでなく、根本原因も）。これはほとんどのビジネスパーソンには狂気に思える。なぜなら、誰も一つの問題を直すために全てを止めたくないから。みんな素早く修正して作業を続けたいか、無視して後で直したい。だけど、フォードやGMが気づいたように、それは問題の山を作って、全てを悪化させるだけ。トヨタは、すぐに直すために長くて辛い時間をかけると、逆に効率が上がり、品質が良くなり、欠陥が減り、出荷が早くなることを発見した。違いは文化にある。これが本当のDevOpsだ。AIの作業を高品質かつ迅速にしたいなら、その提案に従うことをお勧めする。これらは技術的な問題ではなく、ビジネスプロセスの問題だということを忘れないで。

└

それに、大規模な統合が問題を引き起こしているようにも見える。みんなGitHubにいる。みんなAWSにいる。みんなCloudflareの背後にいる。ここで問題が発生すると、みんなに影響が出て、みんながそれを見る。過去には小さなサービスがあったけど、それらは常に壊れていた。しかし、そのダウンははるかに小さな範囲に限られていた。また、システム同士の統合が少なかったので、一つのサービスがダウンしても全てがダウンすることは滅多にない。

└

これはシステムエンジニアリングの仕事だよ。文脈を提供し、許容できる失敗モードを設定し、各レベルで検証のためにテストを行う必要がある。エージェントの計画段階で、誤った結合や不適切なインターフェース、ビジネスの文脈に合わないものを特定する。そして、他の人に伝えて、彼らの決定がシステムを破壊するのではなく、改善するようにするんだ。

└

すごくいい意見だね。アンドンコードはどこにでも必要だよ。

みんなHNでこういう考えのピースに到達する時期があると思うけど、私はちょうどその時期に来た。何を作ってるの？そのツールは役に立つの？役に立たないの？人々はRubyの時代に間違った答えを出し、PHPの時代にも間違った答えを出し、Lotus NotesやVisual BASICの時代にも間違った答えを出した。5、6回繰り返すと、ちょっと疲れてくるよね。ツールを賢く使おう。予算が許すなら、自分たちが実際に作っている混乱の現実を超えないペースで作業しよう。これが起こることは滅多にない、趣味のプロジェクトでも全てのコストを考慮すると。アジャイルやウォーターフォール、"機能的"、PodmanやDocker、VMwareなどの依存関係を抽象化することについてではない。エージェントを使って、ほとんど制御できないLLMと話しているエージェントのバグをキャッチすることでもない。それがあなたの生産データベースを削除してしまう間に、あなたが寝ている間に。そして、あなたがコミュニティでの地位を上げると思っているポストモーテムのブログ記事のイラストを作るように頼むことでもない。今の時点でソフトウェアを作ることがエンジニアリングの分野かどうかもわからない。もしかしたら、最初からそうではなかったのかもしれない。

└

初めはそうだったかもしれないけど、今はエンジニアリングの分野ではないと思う。だけど、それが悪いとは思わない。私たちが「エンジニア」という言葉を付けたのは、もっとお金を稼ぐためだと思ってた。私はそれで構わない。私が知っているエンジニアたちはアプローチがとても厳格で、それは良いことだ。だって、私のデッキが崩れ落ちるのは嫌だから。私たちのほとんどはアプローチがリスキーすぎる。新しいことやパターンを試すのが好きで、時間をかけて確立されたものだけを使うわけじゃない。これには問題ないけど、「エンジニア」という言葉を仕事に適用すると、ちょっと不安になる。なぜなら、それは私たちが本当にやりたくないこと、つまり、私たちのアプローチがうまくいくことを証明し、今後何年もそれが続くことを絶対に証明しなければならないことを暗示していると思うから。あくまで私の意見だけどね。

└

今の時点でソフトウェアを作ることがエンジニアリングの分野かどうかもわからない。もしかしたら、最初からそうではなかったのかもしれない。それはそうだ。 "ソフトウェアエンジニア"になるためのライセンス要件を見せてくれ。何もない。12歳の子供が自分をソフトウェアエンジニアと呼ぶことができて、実際に大きなプロジェクトでリモートワークを得た子もいるかもしれない。

└

RubyやPHP、Notes、VBでたくさんの素晴らしいものが作られた。問題が本当に何なのかわからない。個人的には、あのKarpathyのことが世界で最も遅いことだと思う。ドラッグスターのホイールを回してもいいし、すごくうるさいし、煙の匂いもするけど、ある時点でどこにも行っていないことに気づく。最近、コンピュータの一般的な遅さ（iOS 26、ファイルピッカー、ビルドシステム、ビルドシステム、ビルドシステム…）に対する自分のフラストレーションがピークに達していて、正直なところ、その反応のなさが私をイライラさせている。もし仕事が忙しくて、数年分のサイドプロジェクトがなければ、全てのGUIスタックを底から引き剥がして、ハードリアルタイム要件を尊重するように再構築していたと思う。

└

ソフトウェアはエンジニアリングの分野だった…一部の場所ではね。今でもそういうところはあるけど、他の場所では「大きなバグが見つからないまでハックして、誰かが見つける前に出荷しよう」って感じだった。そして今は「ねえ、AIエージェント - これをハックオマティックとして使えるよ！」って。でも、彼らは以前から持続可能性に問題を抱えてたし、今もそうだと思う、ただもっと早くなるだけ。

└

人々はソフトウェアエンジニアリングがどれだけ改善されたかを理解していない。ほとんどのチームがバージョン管理を使っていなかった頃を覚えてるし、もし使っていたとしても、クソみたいなものでした。ジョエルテストを通過して、ほとんどの質問に「いいえ」と答えた会社のことを考えてみて。 [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

└

ソフトウェアを作ることが今やエンジニアリングの分野なのか、正直わからない。もしかしたら、最初からそうじゃなかったのかも。橋を設計する時は、どれくらいの荷重に耐えられるか分かってるし、安全係数も加える。ウェブサイトを作る時、プロダクト側の人は実際にトラフィックを予測できるの？橋を作る時は、材料の本を見て、どれくらいの荷重で材料が変形するか、破断点や期待寿命がどうかを理解できる。サーバーやウェブフレームワーク、ネットワーク負荷分散装置についても、そういう情報はあるのかな？ソフトウェアがエンジニアリングの分野になり得るとは思うけど、まだまだ道のりは長いね。

└

こういった現象のいくつかは「ソフトウェアエンジニアリング」という名前でまとめられている。経済学が「悲惨な科学」と呼ばれるように、ソフトウェアエンジニアリングは「運命づけられた学問」として知られるべきだ。なぜなら、その目標が自己矛盾しているため、目標にすら近づけないからだ。もちろん、ソフトウェアエンジニアリングは別の立派な目的を持っているように見えるが、それはただの見せかけだ。文献をよく読んで、信奉者たちが実際に何をしているか分析すれば、ソフトウェアエンジニアリングは「プログラムできないならどうするか」をその憲章として受け入れていることがわかる。- エドスガー・ダイクストラ、1988年。残念ながら、彼は私たち全員にこの点で正しかったかもしれない。

Hacker Newsで議論の続きを見る

ハクソク