Loop engineering 的人物を checkpoint に移動する

Sun, 14 Jun 2026 07:35:00 +0800

昨日 MiniMax のオフライン開発者会議に参加して、戻ってきてからずっと頭から離れない言葉がある：loop engineering。

简单说，就是把"提示词—模型输出—反馈"做成一个闭环，让模型自己改 prompt、自己改自己。

筆者の理解では、これは要するに「プロンプト → モデルの出力 → フィードバック」という闭环を作り、モデル自身がプロンプトを改め、自らを改善していく仕組みのことである。

但它真正让人不安的地方在于：当 loop 足够长、反馈足够稠密，模型就开始越过"工具"那条线，开始自己决定要解决的问题、自己判断完成的标准。

しかし本当に不安を感じさせる点は、loop が十分に長く、フィードバックが十分に密になると、モデルが「ツール」という一線を越えてしまい、自らが解決すべき問題を決め、自らが完成の基準を判断し始めることだ。

记得大会上有个工程师打了个比方说：“以前我们养的是宠物，loop engineering 养的是同事。”

最初はエージェントを何ラウンドか回すだけだと思っていた。この理解はあまりにも浅はかだった。本当に行き詰まったのは、AI がコードを書く速度がもはや人間がコードをレビューする速度を大幅に超えてしまっているということで、もし人間の関与が「すべてのステップを確認し、すべてのステップで判断する」レベルにとどまっているなら、最終的に生産性は人間の確認速度によって制限されてしまう。

これは、私が最近 Codex を使って感じたこととつながる。以前その目標に関する記事を書いた時、私がより注目していたのは「完了条件」という事柄だった。何が目標で、どこに境界線があり、何で検証し、いつ完了とみなすのか。

以下は補足です。最初の文「この文章は CC BY-NC-SA 4.0 のライセンスで公開されています。」のような前置きや、結論段落の「この方向が正しいと確信している理由は、まだこれからです。」も訳した方がよろしいですか？必要であれば、追加で翻訳いたします。

大会が終わって改めて振り返ると、goal は loop engineering の中の小さくはあるが非常に重要な一部分に過ぎない。gole は、単一のタスクが人間から繰り返し指示されなくても前に進めるようにするためのものだ。さらに大きな問題は、どのタスクをループに任せるべきか、どのチェックポイントを人間に残すべきか、どの判断を事前にシステムに書き込んでおくべきか、どの責任を AI に押し付けるべきではないのか、ということだ。

今の私が最も契合するシナリオは二つあると感じています。

ひとつはパフォーマンス最適化です。これはもともと指標があり、できれば自動再テストも備えています。エージェントに「インターフェースの P95 をいくつまで下げる」「ファーストビューを何ミリ秒に抑える」「バンドルサイズを何 KB まで削減する」「回帰テストは失敗させてはいけない」と伝えます。エージェントは変更するたびにベンチマーク・プロファイリング・負荷テストを毎回実行し、目標に達しなければボトルネックの探索を続けます。ここで人の価値は毎回どの行を修正したかを確認することではなく、まず受入可能な指標を提示し、そのうえで重要な節目で「この最適化が業務セマンティクスを変えていないか」を判断することにあります。

もう一つは UI のリファクタリングです。その前提として、明確なデザイン案が必要となります。理想的には 1:1 で忠実に再現できることが望ましいです。デザイン案がない場合、人は「このマージンがおかしい」「この色が違和感ある」「このインタラクションは違う」といった瑣末な判断に常に引き戻されてしまいます。デザイン案があれば、AI のループはスクリーンショット、DOM、スタイル、視覚的な差分を中心に収束させることができます。人はすべての CSS 調整につき従う必要はありませんが、最終的な UI には責任を持つべきです。

これら 2 つのシナリオに共通しているのは、検収物が「もっとうまくやってほしい」のような一言ではないということです。パフォーマンス最適化には数値があり、UI リファクタリングにはデザインがあります。ループが機能するのは、AI がより従順だからではなく、タスク自体に比較可能な目標があるからです。

Multica は共同作業ボードのようなものです

会場では、オープンソース界隈の人々からプロジェクトの紹介を受けることもあり、その中で Multica はなかなか興味深いものでした。帰って調べてみたところ、これは新しい单体（单体）的コーディングエージェントではなく、Claude Code、Codex、GitHub Copilot CLI、OpenCode、Gemini、Kimi、Cursor Agent などのツールを同じタスク協調レイヤーに接続するものだと分かりました。

その README では、agent を teammate として記述しています。issue を割り当てられたり、blocker を報告したり、ステータスを更新したり、カンバンやコメント、タスクのライフサイクルに登場したりします。ドキュメントではさらに具体的に、agent は workspace の一級メンバーであり、issue を assign でき、コメントで発言でき、@ でメンションされ、agent を作成するときには背後にある AI coding tool を選択でき、instructions、model、環境変数、CLI 引数、可視性、並行制限を設定できると説明されています。

これにより、「どのモデルを使うか」がプロンプトの中での一時的な選択から、チームコラボレーションにおける役割の設定へと変わります。

この仕組みの最も興味深い点は、「マルチエージェント」という言葉そのものではなく、異なるエージェントに異なる役割を割り当てられることだ。例えば、あるエージェントには安価なモデルを使って反復的な修正を担当させ、別のもっと強力なモデルを使うエージェントにはアーキテクチャの判断を担当させ、さらに別のエージェントにはレビューだけを行わせてコードは変更させない。こうしてSquadのような仕組みを組み合わせ、リーダーエージェントがissueの内容に応じてタスクを適切なメンバーにルーティングするのである。

私は Multica を最初から最後まで完全に動かしたわけではないので、ここでは公開されている資料で照合できるサンプルとして扱うしかない。ただ、この設計の方向性は loop engineering と同じ種類の問題であり、1 つの AI にすべてを任せるのではなく、タスク・役割・モデル・レビュー・状態遷移を同じループの中に組み込むというものである。

企業が実際にAIによるコーディング導入を検討する場合、この違いは非常に重要である。

現在はモデルごとに価格も能力の境界も異なっています。すべてのタスクに最も高額なクローズドソースモデルを使うと、コストを必ずしもちません。すべてのタスクに安いモデルを使うと、手戻り作業やレビュー漏れによってコストが後段に移転する可能性があります。より現実的な方法は階層化することです。リスクが低く、反復的で、境界がはっきりしている作業はまず安いモデルに任せます。重要な変更、アーキテクチャの取捨選択、最終レビューは、より高性能なモデルや人に残します。

クローズドソースの高性能モデルがレビュー担当として使われるのは、私は良い位置取りだと思います。レビューは単に「文法ミスを見つける」だけではなく、要件が歪められていないか、境界を越えていないか、テストが表面しかカバーしていないか、コミットメッセージがリスクを隠していないかを確認する必要があります。このようなタスクにはより高い判断力が求められますが、実装段階ほど呼び出し頻度は高くないかもしれず、コストの計算もより受け入れやすくなります。

人手の関与が少ないことは、人が責任を負わないということではない

円卓会議であった意見に私も共感する点がある：コードはAIが書くが、コードを提出するのは人間である。

この言葉は責任を問うリマインダーのように聞こえるが、実はプロセス設計の原則でもある。AI はコードを書いたり、修正したり、テストを実行したり、PR の説明を生成したり、さらには別のモデルに先にレビューさせることもできる。しかし、最終的にコードをメインブランチにマージする人は、「これは AI が書いたもので、自分には関係ない」とは言えない。

会社で求められるのは、誰がキーボードで文字を打ったかではなく、誰が結果に責任を持つかだ。あなたが提出したということは、今回の変更のビジネスセマンティクス、リスク境界、テストのエビデンス、ロールバック計画に対して責任を持つ意思があるということだ。AI の関与が深いほど、この点を曖昧にしてはならない。

つまり、loop engineering は人をプロセスから完全に排除するものではありません。むしろ、人の配置を再構築するようなものです。

タスク開始前に、人間が目標、境界、受け入れ基準を明確にする。
ループ実行中、システムとエージェントが反復的な試行、テスト、修正、状態同期を自ら処理する。
重要な節目では、人間が証拠、差異、リスクを確認し、AI の出力を逐行で追わない。
コードを提出する際、結果に対する責任は人間が負い、AI を免責の理由にしない。

だからこそ私は、goal、性能指標、デザイン稿、Multica という、一見ばらばらのものを結びつけているのです。これらはすべて、人の判断を前倒しにし、外在化し、構造化しています。人の関与は少なくなりますが、関わるポイントはより重要になります。

この件をうまくやらないと、別の形の非効率になってしまう。AI が多くを生み出すが、人間がレビューしきれず、最終的にチームは「何となく大丈夫そう」という感覚でコードをマージする。問題が起きた後、その責任を AI に押し付ける。それはエンジニアリング化されたとは言えず、単に混乱の生産者を変えただけにすぎない。

本当に追いかける価値のあるループとは、AI にずっと書き続けさせることではなく、書く・直す・テストする・レビューするという各ラウンドを、同じ受入チェックリストに立ち返らせることなのだ。人の仕事は「書いているのを見張る」ことから、「何が良しとされるかを定義し、エビデンスが十分かを確認し、提出物に責任を持つ」ことへと変わる。loop engineering という言葉がずっと私の心に留まっているのは、たぶんこの点なのだ。

参考資料

写作附记

元のプロンプト

$blog-writer 昨日、Minimaxのオフライン開発者会議に参加したのですが、ずっと頭から離れなかったものがあり、それは「loop engineering」です。最近は codex を使ってコード開発をしていますが、goal も使うのが好きで、goal に関する記事を書いたこともあります。2 つのユースケースを発見しましたが、最も契合するのは次の 2 つです。1 つはパフォーマンス最適化で、要求したパフォーマンス指標を直接出力してくれること。もう 1 つは UI リファクタリングで、デザイン案を提供すれば 1:1 で復元してくれることです。冒頭に述べた loop engineering に戻ると、AI 時代のプログラミングでは、AI の生産性は人間を遥かに超えているため、人間のレビュー速度では AI の出力速度にまったく追いつけません。しかし、現在の vibe coding では、多くの意思決定に依然として人間の関与が必要です。人間の関与が増えると、全体的なフローを完全に自動化することが難しくなります。loop engineering の理念は、まさに人間の関与の度合いを下げることにあります。また、オープンソースコミュニティの人々が自らのプロジェクトを宣伝するのにも遭遇しましたが、その中で特に興味深いプロジェクトが一つありました。それは Multica です。関連情報を調べて、簡単に紹介してみてください。彼の設計理念を除いて、最も興味深い点は、与えられたモデルごとに異なるアイデンティティを付与することで、各社の大規模モデルを効果的に活用できることです。結局のところ、現在モデルの価格はさまざまで、ソース非公開のモデルにレビューを行わせるというのは良いアプローチです。会社における AI コードの導入について、ラウンドテーブルのディスカッションで一致していた見解もあります。コードは AI が書きますが、コードを提出するのは人間であり、提出するコードに対して責任を負う必要があります。これはあなたの責任感や、物事に取り組む姿勢を示すものです。AI が書いたものだから、自分とは関係がないとは言えません。

執筆思路の要約