AIエンジニア大会閉幕討論:自動コーディングloop、ハイプはエンジニアリング規律に勝てるか
- AI Engineer World's Fair最終日、「loop」(agentが自動でコードを書き、テストを走らせ、エラーを見つけて自分で直す循環)をめぐる公開討論が、大会全体を貫いていた論争を表舞台に引き出した。推進派はもう手書きコードには戻れないと言い、懐疑派はハイプがエンジニアリング規律を追い越していると言う
- AnthropicのHead of Labsでインスタグラム共同創業者のMike Krieger氏は、社内ツールClaude Tagについて語った。今与えている指示は「このコードベースを君が担当し、フィードバックチャンネルを自分で見張り、自主的に動いてくれ」であって、バグを一件ずつ直させることではない
- Amplifyの2026年AIエンジニア調査:回答者の95%がすでにagentを使用(昨年は約半数)、そのうち89%のagentはデータを書き込める(昨年は52%)。一方で59%はAI生成コードが長期的な技術的負債を積み上げていると懸念しており、agentの「制御レイヤー」はまだ原始的だ
- 閉幕スピーチは楽観論に転じた。Theo Browne氏は「以前ならスタートアップ規模だったものが、今はただのside project」と語り、YC社長兼CEOのGarry Tan氏は、最も急成長している創業者たちはAIを自動補完ではなく労働力として扱っていると述べた
- 会場投票では舞台照明が明るすぎて、司会も討論者も観客が何本手を挙げたか数えられず、うやむやに終わった
大会最終日、「loop」論争が勃発
AI Engineer World's Fair(AIEWF)の最終日、「loop」をめぐる公開討論が、大会全体を貫いていた論争を表舞台に引き出した。loopとは、agentが自分でコードを書き、テストを走らせ、エラーを見つけて自分で直す、というサイクルを何度も繰り返すことを指す。人間が逐一つきっきりで見ている必要はない。
この討論がはっきりさせようとしたのは一つ:自律的に動く「ソフトウェア工場」は今すでに大規模に使える段階にあるのか、それとも野心にエンジニアリング規律がまったく追いついていないのか。司会のAllie Howe氏は冒頭でこう切り出した。「loopのハイプと、実際に使える度合いとの間に、ギャップはあるのか?」
賛成派はRalph Loopの作者Geoffrey Huntley氏と、Keycard CEOのIan Livingstone氏。反対派はHumanLayerのDex Horthy氏とSubroutineのGreg Pstrucha氏。両者ともloopが役立つこと自体は否定していない。争点は「今」コーディングを丸ごとagentに任せられるかどうかだ。
タスクリストを一人のインターンに渡し、完了するまで自分で何度も試行錯誤させる、あなたが一から手取り足取り教えるのではなく。agentのloopもだいたい同じ意味だ。agentが自分で回し、あなたはそばで脱線しないか見ている。
賛成派:loopはもう来ている、後戻りはできない
Huntley氏は開口一番、loopはもう来ていると述べた。「これは必然であり、これからも残り続ける」。さらにこう付け加えた。「もう手でコードを書く側には戻らないと思う」。
Livingstone氏が続けて、話をより本質的な論点に引き寄せた。重要なのは検証できるかどうかだ。コードがどう書かれたか(人間かagentか)は問題ではなく、結果さえ検証できればいい。彼はまた、loopはそもそもソフトウェア開発の核心であり、何も新しいものではないと指摘した。
Livingstone氏の言葉:「loopの核心とは、『何かを試す、何かを学ぶ、それを反映させる』ということだ。我々が本当に議論しているのは、このプロセスをどれだけ加速できるかにすぎない」。彼にとって、agentコーディングはこの古くからある循環をより速く回しているだけだ。
反対派:ハイプがエンジニアリング規律を追い越した
Horthy氏はまず線引きをした。彼はloop自体に反対しているわけではない。「ここでの基本的な問いは、loopが良いか悪いかではない」。Kubernetes自体、制御ループの上に構築されているが、それは決定論的な循環だと述べた。彼が本当に問題視しているのは:「ハイプが規律を追い越している」ことだ。
では「決定論的」とはどういう意味か。簡単に言えば、ルールがあらかじめ固定されている状態を指す:サーバー負荷が高くなれば自動でもう一台追加する、その調整方法は決まっていて、誰かがその場で判断する必要はない。agentのloopは違う。各ステップで何をすべきかはAIがその場で判断するため、同じタスクを二回走らせても、プロセスも結果も異なる可能性がある。この二つのloopは見た目が似ていても、中身はまったく別物だ。
Horthy氏はこの違いをさらに掘り下げた。いわゆる「抽象化レイヤー」とは、要するに人間がどれだけ高い位置から物事を管理するかということで、レイヤーが上がるほど人間が見る細部は減り、AIに任せる部分は増える。彼はこう言う。「今すでに抽象化レイヤーを一段引き上げられるという証拠は見当たらない」。つまりコーディングを丸ごとagentに委ねるという話だ。「本当に動くとすれば、方向はむしろ一段下げる方だ」。
Pstrucha氏が懸念しているのは別の勘定、つまりお金だ。彼はagent loopの経済的な持続可能性に疑問を呈し、「tokenを買い増すだけで問題をorchestrateできるわけではない」と述べた。
- loopはもう来ている、手書きコードには戻れない
- 重要なのは検証できるかどうか、コードの出所は問題ではない
- loopはそもそもソフトウェア開発の核心:試す、学ぶ、反映させる
- loop自体には反対しない、Kubernetesも制御ループの上に成り立つがそれは決定論的
- ハイプがエンジニアリング規律を追い越している
- 抽象化レイヤーを一段上げられる証拠はなく、方向はむしろ一段下げるべき
- 経済的に持続不可能、tokenを買い増して問題をorchestrateすることはできない
「我々は今、機関車の運転士のようなものだ。それが我々の仕事だ:機関車をレールの上にとどめておくこと」Geoffrey Huntley、loop推進派
ソフトウェア工場のジレンマ:全部自動化した後、誰が問題そのものに触れるのか
話題は「ソフトウェア工場」に移った。これは開発プロセス全体(コーディング、テスト、リリース)を一群のagentに自動で任せ、人間は監督とレビューの立場に退く、という比喩で、業界ですでに流行している。
Horthy氏の懸念は具体的だ。すべてが工場式のagent環境で自動的に回っていると、「問題そのものに永遠に触れられなくなる」。だから彼は、小さく始めてagent loopを少しずつ反復し、まず「直感を身につける」ことを勧める。いきなりエンドツーエンドの全自動化を目指すべきではない、と。
Huntley氏でさえloopに潜む危険を認めた。ソフトウェア工場は未来の方向性を象徴しているが、市場はまだこの問題を解決していないという。「これはfrontier thinking(最前線の思考実験)だ」。
1時間に及ぶ討論の終盤、Howe氏は観客にどちらが「勝った」か挙手で投票させた。結果は人間らしい笑い話に終わった。舞台照明が明るすぎて、彼女も何人かの討論者も観客が何本手を挙げたか見えなかったのだ。照明を暗くする係のagentがいればよかったのに。
Anthropicの事例:Claude Tagはどんなものか
ソフトウェア工場モデルに本当に向かいつつある企業を挙げるなら、Anthropicはその一つだ。インスタグラム共同創業者で現在Anthropic Head of LabsのMike Krieger氏は、午前のトークセッションでswyx氏の取材を受けた。
彼は先週会社が発表した社内ツールClaude Tagについて語った。彼はTagをClaudeよりも「delegated(委任的)、非同期、能動的」だと表現した。これはおそらく初期のソフトウェア工場の実像だ。agentがチーム全体を置き換えるのではなく、複数の人間がそれぞれの職務をClaude Tagのような一つのシステムに委任していく、という形だ。
Krieger氏は壇上では要点だけ触れたが、公式発表はClaude Tagをより明確に説明している。それはClaudeをSlackの中にチームメンバーとして置くものだ。指定したチャンネルを開放し、ツールとコードベースを接続すれば、チャンネル内の誰でも@Claudeでタスクを任せて自分は他のことに専念できる。Claudeはチャンネル内の関連情報を記憶してコンテキストを蓄積し、将来のタスクの計画まで立てられる。AnthropicはこれをClaude Codeの次の進化形と位置づけ、モデルをより能動的に、チーム全体で使いやすいものにしている。
個別に会話ウィンドウを開いてClaudeを使わせるのと比べ、@Claudeには4つの違いがある:
公式によれば、Anthropicのプロダクトチームではコードの65%がすでに社内版Claude Tagによって生成されている(ベンダー自己申告)。しかもこの使い方はエンジニアリングから、プロダクト指標の追跡、カスタマーサポートのチケット対応、厄介なバグの調査へと広がっている。ガバナンス面では、管理者がチャンネルごとに互いに独立した「Claudeアイデンティティ」を切り分けられる。営業チーム用の記憶とツールはエンジニアリングチーム用には流れない。tokenの支出上限も設定でき、誰がいつ@Claudeに何をさせたかの完全なログも確認できる。現在はClaude Enterprise / Team顧客向けのbetaで、Opus 4.8上で動作し、従来のClaude in Slackアプリを置き換える。
「我々のほとんどの使い方は、実際には委任に近い」とKrieger氏は語る。彼が挙げた例:「このバグを直すだけじゃない。これからはこのコードベースのこの部分を君が担当し、このフィードバックチャンネルを見張り続けて、自主的に動いてくれ」。彼はこれがチームの働き方そのものを変え、「複数人・非同期・能動的」な協働形態になったと述べた。
だが彼は自動化の副作用も指摘した。チームは今「レビュー工程で詰まっている」、そして「自分たちが本当は何をしているのかを人間がきちんと把握できているか」という点でも詰まっているという。
数字が語る:2026年AIエンジニア調査
大多数のAIエンジニアの今の現実に話を戻そう。この日の午前、AmplifyのBarr Yaron氏が年次の業界調査結果を発表した。
Amplifyのデータによれば、回答者の95%が今agentを使っており、これは昨年のおよそ2倍にあたる。agentを使っているチームのうち89%が、これらのagentはデータを書き込めると回答した。昨年はこの数字が52%だった。「agentはもはや読み取り・要約・下書き作成だけの存在ではない」とYaron氏は言う。「システム内部で実際に行動を起こしているのだ」。
だが管理の手法はまだ原始的だ。人間による承認と権限管理が二大主要な防護策で、その後ろにタスク分解、検索、記憶、サンドボックスといった断片的な技術が並ぶ。「誰もagentの制御レイヤーを固めていない」とYaron氏は言う。平たく言えば:agentはすでにシステム内で実際に手を動かせる段階にあるが、それにどう手綱をつけるか、業界はまだ答えを出せていない。
安くなった、でも不安も増えた:コストと技術的負債
コストも頭痛の種だ。回答者の40%が、AIのコストが「頻繁に」自分たちのAI活用の野心を制限していると答え、さらに36%が「時々」制限すると答えた。token使用量は今、品質に次ぐ2番目に多いプロダクション監視指標になっている。
AIは実験のコストを下げ、チームがより多くのソフトウェアを生み出せるようにした。だが同じ回答者のうち59%が、今日AIが生成しているコードが長期的な負債を積み上げていると懸念している。節約できた時間とお金は、抱え込んだ技術的負債によって少しずつ食い潰されているのかもしれない。このギャップは、討論の壇上でどちらの側が語った言葉よりも雄弁だ。
閉幕スピーチ:次に何をするか
大会最後の数セッションは、AIを楽観的に捉え、AIを使って何かを作るという空気に会場を引き戻した。結局それこそがAIEWFの存在意義であり、一番楽しい部分でもある。
Theo Browne氏は、自分がAIで作った、あるいは今も作っているいくつかのプロジェクトを披露した。彼の論点はこうだ。開発者が現実に手を出せる規模そのものが変わった。「以前ならスタートアップ規模だったものが、今はただのside projectだ」と彼は言う。そして以前は「大きすぎる」と諦めていたプロジェクトも、今では手の届く範囲に入ってきた。
YC社長兼CEOのGarry Tan氏は続けて、この楽観論を組織のレベルに落とし込んだ。彼によれば、YC内で最も急成長している創業者たちは、AIを一つの労働力として運用している。以前は誰もがせいぜい自動補完としてしか扱わず、タイピング中に二行ほど補完が出てくる程度だった。だが今の彼らは、AIにまとまった仕事を丸ごと任せている。
冒頭の機関車の比喩に戻ろう。1週間にわたる討論は、AIネイティブなビジョンが本当にすべての人に行き渡る前に、エンジニアリングという関門をまだどれだけ越えねばならないかを、はっきり示していた。そして閉幕スピーチは、集まったエンジニアたちに、そもそもなぜ自分たちがこれを追い求めているのかを思い出させた。原文の言葉を借りれば、彼らはただ、この機関車を運転したいのだ。
「AIネイティブな会社を作ってほしい。ただAIをついでに使っているだけの会社ではなく」Garry Tan、YC社長兼CEO、閉幕スピーチ