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

45日前原文(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年。残念ながら、彼は私たち全員にこの点で正しかったかもしれない。

└

エンジニアリングは二つのことだ。1. 応用物理学 - ソフトウェアは即座に失格。記号には物理がないから。2. 倫理 - 人の命や生活があなたの正確さに依存している。ソフトウェアの人たちは、その退屈なことから失格になりたいと思っているけど、これは日々深刻な問題になってきている。

└

何を作ってるの？これ、1000倍重要だよ。特にソフトウェア業界の過去10年は、メタ作業で溢れているように見える。新しいフレームワーク、新しいツール、新しい仮想化レイヤー、新しい分散システム、新しい開発ツール、新しい組織図。結局、何を作るためなの？これらは本当に必要なの？それとも、新しい仕事を生み出して持続不可能な業界を支えるために必要なの？これが一大ピラミッドスキームに見えるのはなかなか拭えないね。最近の「革新」の大部分は、実際のソフトウェアエンジニアリングではなく、ソフトウェア職業の資金モデルと制度を支えるために使われていると強く疑っている。> ソフトウェアを作ることが今やエンジニアリングの分野なのか、正直わからない。もしかしたら、最初からそうじゃなかったのかも。それは、そして今もそうだ。でも普遍的ではない。科学的に質問を立てて、その答えを使って決定を下すなら、それがエンジニアリングだ。実際にそうなるのを見たことがある。適切な指導の下で、LLMでもそれは可能だ。もし雰囲気で質問を立てて、答えを無視して、CEOの言うことをそのままやるなら、それはエンジニアリングじゃない。残念ながら、そういうことがあまりにも頻繁に起こっているのを見てきた。そして、この考え方にはクラウディオットの考え方がついてくる - 情報は最終的に無意味だから、偽の自動生成コンテンツも本物の仕事と同じくらい価値がある。

└

えっと、Visual Basicはまだ健在だよ。前にチェックしたときは、OLEオートメーションをやるにはまだまだ定番の選択肢だった。RoRはもうピークを過ぎたけど、ウェブの中ではまだ安定したシェアを持ってるし、PHPがその大部分を占めてるね。まぁ、Lotus Notesは今や完全に過去の遺物だね。でも、これはプログラミング言語じゃないから、同じようなもんじゃないし。LLMもプログラミング言語とは全然違う存在だよ。扱うのが難しいときは「獣を飼いならす」って表現がぴったりだと思う。だから、エンジニアリングからはかなり離れたところにあると思う。科学的な領域に留まるなら、情報学やコンピュータサイエンスのバックグラウンドよりも、動物行動学から始める方がいいかもね。

ここでの有用なコンテキストは、著者がPiを書いたこと。これはOpenClawで使われるコーディングエージェントフレームワークで、一般的に最も人気のあるオープンソースのコーディングエージェントフレームワークの一つだ。

└

...そういう人たちは、何も言っていないように見える記事を書く方法がある。

└

それは面白いね。libGDXやRoboVMでの彼の仕事を追ってきたよ。彼のpiに関するブログ記事はここにあるよ: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/

└

それは素晴らしい指摘だね。多くの人がこの意見をただの反AI懐疑論者として無視するだろうから。彼はこのサイトのほとんどの人よりもLLMやエージェントとの仕事の経験があるから、彼の意見はかなり重みがあると思う。

AIが書いたコードが100%だって主張してる会社は、想像を超えるクソみたいなものを出してるよね。指摘はしないけど、メモリリークがギガバイト単位で、UIのバグ、壊れた機能、クラッシュ。昔のDOSやオリジナルのMacOSの時代は、こんなことがほとんど許されなかった。コンピュータがガッツリクラッシュして、再起動しなきゃいけなくて、保存してない作業は全部消えちゃう。アップデートやパッチも簡単には出せなかったし、出荷時にちゃんと動く必要があった。今のOSは仮想メモリやマルチタスク、ユーザーの隔離があるから、クソコードにも寛容になってる。だから、ますます増えてるんだよね。DOSに戻りたいわけじゃないけど、Wordperfect 5.1はかなり安定してた記憶があるな。

└

もう一つの要因は、リリース前に厳密なテストで捕まえるべき問題を修正するためにローリングアップデートを使っていること。'常時接続'のインターネットがなかった頃は、物理メディアで出荷されたものを修正するのは非常にコストがかかった。すべてが完璧だったわけではないけど、全体的には出荷前にかなりのストレステストが行われてた。悲しいことに、今は、ユーザーがほぼ常時ネットワークに接続されているだけで、修正を簡単にプッシュできるから、OSですらアプリやゲームのように扱われてるんだよね。

└

現代のOSは仮想メモリやマルチタスク、ユーザーの隔離があるから、クソコードにも寛容になってる。だから、ますます増えてるんだよね。計算リソースが溢れてるわけじゃなくて、現代のソフトウェアにはすでに膨張を受け入れてる。新しい crutch は、すべてのデバイスを「常時オンライン」と見なすことと、「今出荷！後で修正をプッシュ」のマントラを組み合わせること。大きな複雑なCIパイプラインを設定して、そこに修正をプッシュして、ユーザーのシステムをOTAでパッチするのが簡単になった。これで、同じことをしてる競合に勝つために、壊れた未完成の製品をプッシュする正当化ができるんだよね。

└

あなたは実際に良かったソフトウェア製品を思い出してるだけだと思う。昔はクラッシュして作業を失うクソみたいなソフトウェアがたくさんあったよ。

自然は時間が経てばこれを処理するよ。もしこれが完全に制御を失ったら、ソフトウェアの世界で「ベア・スターンズの瞬間」が見られると思っておいて。

└

AIGのような状況になって、みんなが責任を負うことになるのが心配。

記事が触れていないのは、現在進行中のベンダーロックインの問題だ。多くの企業が今、主要なAIプロバイダーに依存したAIベースの開発プロセスに移行している。コードベースが完全にエージェント的になったら、つまり、エージェントだけがそれを理解し、修正できるようになったら、価格は上昇し始めるだろう。結局、これらの赤字を出しているAI企業は、投資を回収する必要があるからね。コードベースの開発において基盤となるAIを入れ替えることはできるかもしれないけど、果たしてそれがかなり安くなるのか？もちろん、市場の見えない手がその問題を解決するだろう。OPECが石油市場で成功裏にやってきたことだ。もう一つの問題は、コードベースがエージェント的になり、開発者の価格が十分に下がって人間を雇う方が安くなる時、彼らはそのエージェント的なコードベースを理解できるのか？これは一方通行の移行なのか？プロAIの人たちは、技術はどんどん安くなり、良くなるから、根本的には問題ないと言うだろうね。石油価格や世界経済と同じように、根本的にすべてが良くなっているんだ。

└

これはいい指摘だね。いくつかのAI企業は、CSの学生を取り込もうとしてるから、彼らは自社の製品の一部として「開発者」しか知らなくなる。最初の一回は無料って言うしね（ドラッグディーラーみたいに）。

└

これは素晴らしいポイントだと思う。経験豊富なプロがスキルを維持するために努力すべき理由や、新人プロが最初からスキルを身につけるべき理由を説明するのに、よく使うんだ。こういう会社から詳細な知識作業を委託するのは、全然快適じゃない。時々、この議論は通じるけど、ほとんどは通じないね。君が言ったように、「でも価格は上がらないし、サービスコストは今が最高だ」っていうのがよくある反論だよね。あるいは「推論はすでに大きな利益を上げていて、今後もっと利益が出るだろうってニュースサイトで読んだ」って。こういう発言は、残念ながら議論を終わらせるものになっちゃう。こういうことを言う人は、すでに賭けをしていて、サイコロを振ろうとしてるんだ。

この投稿は、すべてのTypescript開発者に向けられるべきだと思う。多くの問題は、Typescript開発者が関わってるから起きてるんじゃないかな。彼らを除外したら、彼が書いてる問題のほとんどは消えちゃうと思う。Typescript開発者は、エージェントなしでReactが何をしてるかも理解できてなかったのに、今は一発で機能を出して、ウェブアプリやCLI、デスクトップアプリを作って、世界に発信してる。これの典型例がAnthropicだよ。彼らは機能やアプリ、CLIをどんどん出してるけど、どれもバグだらけでリリースされてる。

最近、エージェントを調整するためのイテレーションループで作業してて、Claude CodeとOpus 4.6を使ったらすごく生産的だったよ。このコンセプトは、オーケストレーターエージェントが自分自身のコピーを作って、サブエージェントが/tmpのgitワークツリーで隔離されて動くっていうもの。だから、コンテキストが漏れないようになってる。サブエージェントは動きながらオーケストレーターとコミュニケーションを取る。オーケストレーターはトークンの使用量やCPU、メモリを監視してる。サブエージェントが終わったら、オーケストレーターが分析して指示を更新して、再度実行する。これで、何か変更があったときに、トレーニング/バリデーションセットに対して検証されて、サンプル外でテストされるから、モグラたたきの問題が解決される。これは私にとって新しいアイデアで、他の開発者がこのコンセプトをどう扱ってるのかは分からないけど。

今日の散歩中に気づいたんだけど、プログラムはプログラミングの唯一の成果物じゃないよね。もう一つ、もっと重要な成果物はプログラマーそのものなんだ。プログラムを書くことで、プログラマーが築くメンタルモデル。で、ここで一つの大事な質問があるんだけど、手を使わずに済むことはできるのかな？知識は「思考レベル」よりも深いところに存在していて、多くは筋肉の記憶にあるんだ。教科書の段落をチラッと見て「うん、分かる」って言っても、試験でうまくいくとは限らない。実際にそれを生み出せる必要があるんだ。（電話番号を忘れた経験を思い出す人もいると思うけど、話したり書いたりできなくても、ダイヤルパッドに打ち込むことができるのは、筋肉の記憶がまだ残ってるから！）最近のトレンドは、プログラムと呼ばれる成果物を増やす一方で、プログラマーと呼ばれる成果物を減らしてる。これはあまり良い兆しじゃないね。参考までに：文明の崩壊を防ぐ / ジョナサン・ブロウ（Thekla, Inc） https://www.youtube.com/watch?v=ZSRHeXYDLko

これが私が「ゴミ」に基づくコンテンツと呼ぶものだね。ゴミは人々のランダムなコレクションだから。ゴミ捨て場を通じて社会について考察したりコメントしたりすることはできるけど、かなり表面的だよね。本当の人の動機についてはあまり教えてくれない。だから、実際の人々についてコメントするにはあまり良い基盤じゃない。OPのコメントは、ニュースやソーシャルメディアを通じて出会ったもののコレクションに過ぎない。確かにたくさんのことが起こっているように見えるけど、どの一人の人やビジネスのアプローチを見ても、もっと理解できるようになるよ。そう、確かに人々は「ゴミ」マインドに訴えるコンテンツを生み出してるけど、明らかにそれは演劇だよ。週に10,000行のコードを書いてくれるシステムは、見出しのための演劇に過ぎない。

ハクソク