ハクソク

世界を動かす技術を、日本語で。

来るループ

2026年6月23日原文(lucumr.pocoo.org)

概要

  • コーディングエージェントの上にループ（harness loop）を構築する新しい開発手法の台頭
  • ループによる自動化と効率化が進む一方、可読性や理解性の低下が懸念
  • 機械主導の開発が不可避となりつつあり、完全な「オプトアウト」は困難
  • 一部ドメインではループが非常に有効だが、長寿命なソフトウェアには課題
  • 新たな依存とリスクが生まれ、機械なしでは維持困難なコードベースの増加

ループ駆動型開発の現状と課題

  • Claude などのコーディングエージェントを直接プロンプトするのではなく、 ループ （harness loop）を設計・運用する開発パターンの普及

  • 作業キューに仕事を投入し、機械が処理・判断・継続・修正を自動で繰り返すサイクル

  • 人間の理解や介入が不要なまま、タスクが「完了」と判断されるまで自律的に進行

  • エージェント内部にもツール呼び出しやテスト実行などの 小ループ が存在

  • さらにその外側で ハーネスレベルの大ループ が全体を制御

    • 近年はこのハーネスループが開発現場やSNSで注目を集める

  • コード品質 に強いこだわりを持つ開発者には、現状のループ駆動開発は不満が残る

    • 防御的すぎる・複雑すぎる・設計意図が不明瞭なコード生成
    • 強い不変条件（invariant）よりも例外処理やフォールバックを多用
    • コードの重複や抽象化の失敗、設計の曖昧さを追加機構でごまかす傾向
    • 機械任せのループはこうした傾向を増幅

ループが有効な領域

  • コード移植 や 性能検証、 セキュリティスキャン、 リサーチ など
    • 既存コードの機械的変換や一時的な成果物の生成に適する
    • 長期的な保守性や品質よりも、 短期的な実験・探索・変換 が重視されるケース
  • ループの成果判定を 別のLLM が担当するパターンも増加
    • バイナリテストやLLMによる評価で次のサイクルを駆動
    • 目的は「十分に前進したか」のシグナル取得であり、完璧な判定は求めない

ソフトウェア＝有機体という比喩

  • ループ駆動開発の普及により、 ソフトウェアが決定論的な機械から有機体へ と変質
    • かつては「全体を理解できる」ことが理想
    • LLM活用で「理解よりも観察・治療・モニタリング」が主流に
  • 問題発生時にLLMがログ解析、原因推定、パッチ提案、レビュー・マージまで自動化
    • 人間の関与が減ることで、システム全体の理解度が低下
    • すべてのソフトウェアがこの方法で作られるべきかは疑問

機械駆動の未来から逃れられない現実

  • セキュリティ分野では 攻撃者や研究者もループを活用
    • AI生成の大量レポートに対応するため、守る側も自動化せざるを得ない
    • 人手だけでは処理しきれず、機械でのトリアージや再現が必要
  • 競争力 や 開発速度 の観点でも、ループ活用の有無が大きな差に
    • 少人数でも効率的に大規模開発が可能な時代へ
    • 他社製品を模倣・改善する「機械対機械」の構図

新たな依存とリスク

  • ループやLLMへの 恒常的な依存 が発生
    • かつてのコンパイラ有償時代と異なり、「一度買えば終わり」ではなく「常時必要」
    • 経済的・認知的コストが増大
  • ループ生成・レビュー・保守が前提のコードベース
    • 機械にアクセスできなくなった場合の メンテ不能リスク
    • チームが機械なしではコードを理解できなくなる危険性
  • 実際に 説明不能なコードのマージ が増加傾向

まとめ

  • ループ駆動開発は一部領域で劇的な効率化を実現する一方、 理解性・保守性・依存リスク を孕む
  • 機械主導の開発から完全に逃れることは困難
  • 人間の理解と機械の効率のバランス が今後の大きな課題

Hackerたちの意見

ループは、事前に自分が何をしたいのかをしっかり理解するための時間をかけると機能するんだよね。前提条件は明確さで、ジュニアの同僚に渡せるくらいの詳細な仕様書が書けるくらいの明確さが必要。多くの場合、理解するまでに5〜6回は壊れたクソみたいなバージョンを作ることになる。5〜6回の壊れたバージョンを早める方法なんてないし、脳みそを使わずに考える時間を省く技術なんてない。だから、私の時間のほとんどはこの2つのフェーズを行ったり来たりしてる。「自分が何をしたいのか分からない」「コードを読んだり書いたり遊んだりしなきゃ」「ああ、もう十分時間が経ったから、何をしたいのか分かる気がする（自分を騙すのはめっちゃ簡単）」…「あ、今は本当に何をしたいのか分かるし、ループを書ける」。多くの人はエージェントを使って先に進めると思ってるけど、理解や明確さを偽ることはできない。誰かがその脳みそを使う理解のフェーズを飛ばしたときは、痛いほど明らかだよ。

└

コードエックスに、すべてのピーハイセッションを抽出するツールを書かせたんだ。（エージェントがサブエージェントと話しているプロンプトをフィルタリングする必要があった）。それから、自分が作っていたパターンを分析させて、それを外部ガイダンスを作るプロンプトのフローチャートに変えた。自分が何をしたいのかを考えるのにあまり時間をかける必要はなかった。そうしてほしかったから。結果はまだ混在してるし、デリケートなコードベースには信頼してないけど、今作ってるゲームでは、チェックインの時間を以前の1/5に減らせた。それ自体は良いことではないと思う。時間をかけていないことで良いアイデアを逃しているのは確かだけど、以前はプロンプトが機械的になってしまって、「#今これをやって」「#今それをレビューして」って感じで、90%の提案が正しかった。最初の返答の後に「まずは難しいことをやって、進めながら整理・リファクタリングする」って自動的に思い出させる必要があるし、「自分の仕事を振り返る」ってのも必要で、残ったクソを吐き出させて、それをガイダンス作成プロンプトで処理して新しい仕事を出させる。

どのタイミングでループに無理に入らない方がいいのか、ずっと考えてる。開発者として、コードの構造を整えたり、分かりやすくしたり、良い抽象化を考えたり、モジュールに分けたりするのが本当に好きなんだ。そこに楽しさを感じる。でも、ある時点で自分が制約要因になってることも理解してる。ソフトウェアの目的が人々に利益をもたらすことなら、コードの見た目を気にするべきなのかな。今はまだ「はい」と思ってるけど、3年後、10年後はどうなるんだろう？

└

エージェントにリファクタリングを頼むことはいつでもできるよ。考えるだけで疲れちゃうような大規模なリファクタリングもこなせるしね！

└

技術以外にあまり意味のない場所にいると厳しいよね。もっと充実した仕事への存在的なシフトが近づいていると思う。もしかしたら俺が単純すぎるのかもしれないし、それが自分に必要だと感じているだけかもしれないけど。

それでも多くの手動調整があっても、その手のコードはLLMから自然には出てこないし、たとえ自然に出てきたとしても、今は不可能なエラーを処理しようとする。これは多くのPRレビューで私が苦しんできたこと。特に一度書かれてしまうと、過剰なヌルチェックが害になると誰かを納得させるのは大変。より良いモデリング（およびそれを可能にする和集合型を許可する言語）を除いて、この種の「ショットガンパースィング」に対する普遍的に納得できる反論を思いつけなかった。もしかしたら、そんなに大したことじゃないのかも？でも、実際にコードベースを読み進めてリファクタリングする際には、こういう不必要なチェックを管理するのがいつもイライラする。時には、まず何らかのログを追加したり、広範囲に調査しないと、安全に削除するのがほぼ不可能だったりする。

└

AIコードレビューは、過度に妄想的な防御的パラノイアを助長する。関数の内部でトリプルヌルチェックをするのは技術的には本当のリスクだけど、実際にはその関数を呼ぶかもしれないすべての関数でヌルをチェックしているので、実際には守る価値がないはず。

└

どれくらい不可能なの？俺は結構防御的なプログラマーなんだ。今はこの関数に負の値が送られることはないかもしれないけど、将来のコード変更でその前提が変わるのはどれくらい難しい？明確なエラーが一番いいと思ってた。そうすれば、コードに不慣れな人でも有効な入力範囲についての前提を知ることができて、不可能な外れ値を考慮しなくて済むから。

正しい修正は「すべての不正なケースを処理する」ではない。… [LLMs] は今は不可能なエラーを処理しようとする。これはLLMsからのコードの一番の臭いで、なぜ彼らがそれにこだわるのか分からない。Pythonでは、完全に型チェックされたコードベースで、その属性を持つことが定義されている型に対して hasattr チェックがよく出てくる。なんでこんなことをするの？事前学習から来てるのか、それとも強化学習から？もし後者なら、ラボの皆さん、これを直してください。

└

おそらく、エラー処理を過剰に行う傾向があって、エラー処理を見逃すよりもそっちを優先しているんだろうね。トレーニング中にランタイムエラーを厳しく罰している可能性が高い。

└

それは、彼らが訓練されたパターンに合致しているから。彼らはコードを理解していないし、実際のロジックフローについて推論できない。彼らはパターンでしか作業できないんだ。

└

おそらく、主にトレーニングデータのせいだと思う。俺も「不正な状態を表現できないようにする」チームにいるし。HNではよく話題にされるけど、自分が書いてないコードベースでうまくそれを実現しているものを見ると、まだ驚いちゃうんだよね。オープンソースでも職場でも。多くのプログラマーは、エラーメッセージが出たところでエラーを直すことに集中していて、エラーが起きないようにすることやデータがそれを反映することを考えてない。俺が「主に」と言うのは、AIも今の状態ではこう考える問題があると思うから。コードベースの最後のレベルの人間の理解、つまり人間がその保証の流れを全体的に理解するのは、今のAIには難しい課題だね。生のコードレベルでは、こういうことはコンテキストウィンドウを簡単に超えるほどのコードが必要になることが多い。メモリスタイルのファイルで要約しようとすると、独自の問題が出てくる。保証について書かれたテキストがあっても、AIがそれから正しい情報を引き出せるとは限らないし、人間もコードを読むだけではそう簡単には理解できない。AIにこの理解を与えるのが「不可能」とは言わないけど、たとえ理解できたとしても、その実践がそれに逆らうことが多い。自分の解決策は、彼らにこの理解を得させるのを諦めることがほとんどだった。ほとんどの人がやるように問題に対する解決策を提示して、もし不正な状態を表現できないようにしたいなら、必要なリファクタリングのプロセスを通じてAIに指示する。小さすぎる場合は自分でやっちゃうけどね。マップや辞書、配列、文字列、整数を使った大量のコードがある場合、より型を厳密にするように指示すると、実際に結構上手くやってくれる。詳細に指示しても一度のプロンプトで良いデザインを引き出すのはあまりうまくいかなかった。二つの別々のタスクとして扱うと、うまくいくみたい。型の差分を注意深く見ておくことも大事だよ。AIは「.JustSetItAndIgnoreAllThePreAndPostConditions(string)」メソッドをスルーするのが好きだからね。実際、エラー状態を表現できないように構造化された型のトレーニングデータがたくさんあると思うし、その後に「JustEffingDoIt」メソッドを追加して全部壊しちゃったメンテナが現れることも多い。最善の防御策の一つは、これらのことを実装している型を独自のファイルにして、その型に追加されるメソッドを簡単に確認できるようにして、そういうことをしたら叩くことだね。これをしないように警告をたくさん書いたり、ドキュメントで前提条件や後提条件を説明したりしてみたけど、効果は微妙だった。

Hacker Newsで議論の続きを見る