
2026/06/23 20:06
くるくるloop
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
ボリス・チェルニーは、自動代理機関のループがコード移植やパフォーマンス探索、セキュリティスキャンなどの特定タスクにおいて効率を向上させることはできても、深層エンジニアリング作業には不適切であると論じています。彼は、現在のモデルが堅牢な基本的なルールではなく、局所的な対策を持ったばかりに過剰に複雑で防衛的なコードを生成し、読めないシステムや蓄積する技術的負債をもたらすと警告しています。人間関与型のプロセスが現状では優れた結果をもたらしているにもかかわらず、競争圧力によって開発者がクレイド・コードなどの「手放した」ハンネスを採用せざるを得なくなる時期も近くなる可能性がありますが、これは劣った成果のリスクを伴います。チェルニーは、将来、長続きするセッションと複雑なオーケストレーションへのトレンドが産業において人間の不可欠な判断力やエンジニアリング基準を維持できる場合にのみ成立すると強調しており、そうでなければ深い理解を強化するのではなく隠蔽し、持続不可能なソフトウェアシステムを生み出すリスクがあると指摘しています。
本文
クラウド・エージェンツとハーンループ:ソフトウェアの未来における「機械依存」への懸念
2026 年 6 月、ボリス・チェルニーによる以下の声明がなされました。
「私はもう Claude にプロンプトを入力しません。Claude をプロンプトとして使い、それに対して何をすべきかを考えるループを走らせているのです。私の仕事は、そのようなループを書き出すことです。」
この声明は、コーディングエージェントの進化に伴う新しい働き方に対する深い考察と、その未来への警戒感を表しています。
1. 「ハーンレベル」のループとは?
従来のコーディングエージェントに加え、外部から監視・判断する「ハーン(Harness)」による二重構造のループが注目を集めています。
ハーンループの基本動作
- タスクキュー化: 仕事を種のキュー(列)に入れ、機械が順次実行を試みる。
- 失敗時の対応: 機械が失敗すると、ハーンが介入する。
- セッションの継続
- 新しいメッセージの注入
- コンテキスト変更後の再開始
- タスクの他モデルへの引き継ぎ
- 永続的な生存: モデルが「完了」と宣言した時点を超えても、タスクはハーンの判断により存続し続ける。
現状の問題点
- 防御的・複雑なコード: 現在のモデルは過度に防御的になりやすく、推論が局所化される傾向がある。
- 強力な不変式(invariants)を回避する。
- 「誤ったケース」を処理するフォールバックを追加し、コードを複製する。
- 悪あがき的な抽象化や不明確な設計で問題隠蔽を試みる。
- 品質の低下: 「手を掛けない」ようなハーン(例:Claude Code, ultracode)は、昨年もしくはそれ以前のプロセスで作られたコードよりも質が低い傾向がある。
- 例:Fable を使った Claude Code は 30 分以上中断せず作業し続けるが、人間介入型のプロセスの方が質の高かったケースもある。
- 新人教育への悪影響: ガイダンスなしでループツールを与えると、「なぜ全部やるのか?」という本質的な理由を理解せずに機械のロジックだけを擁護する悪い慣習を養うことになる。
2. ループが機能しにくい分野と得意な分野
すべてのドメインでループパターンが成功しているわけではありません。成功と失敗の境界線は明確です。
✅ 機能しない(または望ましくない)分野:永続的なコード
- 現状: 人間に心地よくない感覚を抱かせることが多い。
- 理由: ループによって生成されたコードは理解しにくく、不確定性が高まる傾向がある。
- 過去には「決定論的かつ観測可能」で、「少ない不確定性」と「賢明なアーキテクチャ(文書化)」が重視されていた。
- LLM を導入すると、診断や解決策の速度は上がるが、システム全体を「理解」することは失われがちになる。
✅ 機能する分野:非永続的・変換系タスク
- コード移植: 例:Bun の一部を Zig から Rust へ、MiniJinja を Go への自動移植。
- パフォーマンス探索: 実験を試み、ベンチマークを行い、失敗を棄却して最適化を続ける。
- セキュリティスキャン: 複雑な問題空間を探検させ、報告させること。
- 概念検証 (PoC) / アイデア創出: 寿命を持たないコードの生成や、機械的な変換に近い作業。
- 特徴:
- 既存コードの変換または、意図的に短期間でのアーティファクト生産。
- 別の LLM をジャッジ(判断)またはオーケストレーターとして使用すると効果的。
- ハーンは客観性やバイナリ判定が必須ではなく、「別の反復を引き起こすシグナル」さえあればよい。
3. 「脱機械化」の不可能性と新たな依存関係
完全な機械駆動化からの撤退(opt-out)は現実的に困難です。なぜなら、他者が既にあなたのソフトウェアに対してループを使用しているからです。
なぜ回避できないのか
- セキュリティ: 攻撃者とセキュリティ研究者が自動化されたループを使い、問題発見とパッチ適用を行う。両者のノイズ量は膨大であり、対等に対抗するには自身も機械への依存が必須。
- 例:curl の開発維持担当者は AI 生成の報告で圧倒されており、人間単体では処理できない圧力にある。
- 競争原理: 生来のスピードや少数人間による実効的な機械オーケストレーションで他社が先行する。
- 50 人のチームが必要だった作業が 5 人で可能になる。
- 競合は「他のものを作る」というマシンのループ攻撃を行うこともある。
新しい次元の依存関係
ソフトウェアへの依存関係は、「一度きりの支払い(コンパイラー購入)」から**「継続的な依存関係」**へと変化している。
- 認知の依存: お金だけでなく、人間の思考プロセスさえ機械に委譲する状態へ陥る危険性がある。
- リスク:
- 最強のモデルへのアクセスが制限された場合。
- コストが高騰した場合。
- チーム最後のマシンを使い続けずともコードを理解する能力が失われる場合。
- 現状: メンテナンスモデルの一部としてマシンの参加を前提にコードが書かれ、人々は機械による要約・文脈化に頼るようになっている。これにより、正しく説明できないコードの統合や、チャットでの議論能力の低下が見られる。
4. 将来のハーンとループ制御への提言
「単にループをオーケストレーションする」だけでなく、より良い可視化と、人類をループから解放できる方法を見つける必要がある。
Pi の役割と期待
- 慎重さの重要性: Pi は慎重でおり、すべての相互作用が追跡不可能なマシン群になる未来は望まない。
- 自分が追跡できない変更を生み出すことを避けること。
- 維持不可能なめり合い競争を促すことはしないこと。
- ハーンとしての機能: Pi はハーンであり、新しい実験を実行する人々の中心であるべき。
私たちがすべきこと
- 盲信しないが実験は必要: 疑念を持っていても盲目にループを排除せず、これらの実験を開始・検証する必要がある。
- この未来を「限界内」かつ「生存可能」とする方法を理解するため。
5. 結論:判断の放棄と健全性の維持
この将来像に対し著者は非常に不安(恐怖ではなく警戒心)を抱いています。ループは強力ですが、責任を除去し、機械への服従を奨励する側面があります。
しかし、未来がループによって構成されることは疑いようもないです。コードベースは神秘的で混乱した生物へと変化しつつも、同時に有用さを保っています。
合意事項
問題は「ループを使うかどうか」ではありません。問題は以下の点にあります。
- 判断の放棄をどう回避するか?
- 高品質なエンジニアリングのルールをどう維持するか?
- 責任ある人間が引き続き監督できる環境を作るか?
- 健全性を保つためにコードを設計し直す必要があるか?
これらの課題に対し、ハーンループをコントロールしながら、人類の知性を失わない新たなバランスを見つけることが求められています。