Three Agentsにおけるループエンジニアリング：Claude Opus 5.5を無人で実行することについて、yetoneのMagpieワークフローが語るもの

yetoneのセットアップで最も興味深いのは、モデルのほうではない。数字の「3」だ。Magpie——コーディングエージェントを、指定した任意のモデルに対して動かせるようにするローカルゲートウェイ——のメンテナーは、2026年10月13日にXで自身のメンテナンスワークフローを説明した。Claude CodeをAnthropicのClaude Opus 5.5で動かし、3つの/loopタスクを同時に走らせ、それぞれが異なる領域——GitHubのissueとプルリクエスト、Discordコミュニティ、そしてXに届くフィードバック——を監視し、見つけたものを修正する。ループエンジニアリング、つまりエージェントをターンごとにプロンプトするのではなくサイクルさせ続ける手法は、今年多くの話題となった。この例が読む価値があるのは、組織図が付いてくるところだ。

Claude Opus 5.5は新しいものではない。Anthropicは2026年9月22日、つまり3週間前に、入力100万トークンあたり4ドル、出力100万トークンあたり20ドルでこれを出荷した。これはローンチの話ではない。3エージェントのメンテナンスループを模倣しようとする者にとって、このモデルのデフォルトが何を意味するのか——そして、そのループのどの部分が、チュートリアルでは言及されていない形で壊れるのか——についての話である。

ワークフローに実際に何が含まれているのか

シグナルは短いので、何が主張されていて何が主張されていないかについては正確を期しておく価値がある。yetone は3つの並行した /loop タスクを、Opus 5.5 上の Claude Code で走らせている。1つはリポジトリ —— issue とプルリクエスト —— を監視している。1つは Discord を監視している。1つは X を監視している。エージェントは、修正する価値があると判断したものを、ループの中で、人間が毎回指示を出さなくても修正する。彼が自動化したのは、ほとんどのメンテナーが下手にこなしているあのパターン、つまりトリアージだ。コーディングではない。1日に1時間を食いつぶす、読む・仕分ける・重複を排除する・答えるという作業のことだ。

「ループエンジニアリング」という表現はここでは要となる。ループとは、タスクを行うエージェントではない。それは、自分が選んだスケジュールでタスクに何度も戻ってくるセッションであり、前回のイテレーションの状態がまだ目の前にある。この区別こそが、ほとんどの自家製バージョンが崩れるところであり、まさに過去6週間でツールが進んだところである。

Claude Codeの/loopが2026年10月に実際に行うこと

現在のドキュメントを読んでいなければ、あなたが覚えているバージョンはおそらく間違っています。なぜなら/loopループエンジニアリングが流行している間に形を変えたからです。

引数なしの /loop では、間隔を指定する必要がなくなりました。省略すると、Claude が前回のイテレーションで観測した内容に基づいて、1分から1時間の間で動的に選びます。ビルドが終わりかけているときやプルリクエストがアクティブなときは短く待ち、何も保留になっていないときははるかに長く待ちます。選ばれた遅延とその理由は各イテレーションの最後に出力されるので、ループ自身がその周期についてどう考えているかを確認できます。代わりに間隔を指定すると — /loop 5m check the deploy — 固定の cron スケジュールになります。

プロンプトも省略すると、組み込みのメンテナンスプロンプトが得られます。これは毎回の反復で3つのことを順番に処理します：

• 会話の中で未完了の作業があれば続けてください。

• 現在のブランチのプルリクエストに対応する — レビューコメント、失敗したCI実行、マージコンフリクト。

• 他に保留中の作業がないときは、バグハントや簡素化といったクリーンアップ作業を実行してください。

そのデフォルトは、次のファイルを書くことで自分の指示に置き換えられます: loop.md — 配置場所: .claude/loop.md（プロジェクト用）、または ~/.claude/loop.md（独自のものを定義していないすべてのプロジェクト用）です。編集は次のイテレーションで反映されるので、実行中のループを再起動せずにその指示を改良できます。ファイルは25,000バイトを超えると切り詰められますが、これはトリアージルールには十分すぎるほどの余裕です。

その仕組みは3ループ構成の要となる部分であり、ワークフロー図がたいてい省略してしまう部分でもあります。汎用の組み込みメンテナンスプロンプトはトリアージポリシーではありません。プロジェクトがGitHub issueを読むのと同じようにループにGitHub issueを読ませたいなら — 何を重複と見なすか、何に返信ではなくラベルを付けるか、何には決して返信しないか — ポリシーは次のファイルに置く必要があります: loop.md、セッションを開始したときに入力したプロンプトではなく。

3が数なのかスローガンなのかを決める限界

3つの並行ループが同時に走るあたりから制約が効き始める。誰かのセットアップをそのまま真似る前に、それらを列挙しておく価値がある。

• 同時実行の上限 — セッションは一度に最大50件のスケジュール済みタスクを保持できるため、3つのループなど上限にはまったく届かない。真の制約はタスク数ではなく、注意力である。3つのループとは、同じセッションを奪い合う3系統のツール呼び出しを意味する。

• 有効期限 — 繰り返しタスクは作成から7日後に自動削除され、去り際にもう一度だけ発火する。8日目に静かに停止してしまうメンテナンスループは断然最もよくある障害モードであり、しかも気づかれずに失敗する。

• 復元の非対称性 — セッションを --resume または --continue で再開すると、cron でスケジュールされたタスクは戻ってきますが、期限切れになった繰り返しタスクは除きます。セルフペースのループはまったく復元されません。再度開始する必要があります。

• ビジーセッション時の挙動 — タスクはターン間で発火し、応答の途中では決して発火しません。ループの予定時刻が到来したときに長時間のエージェント型ターンが実行中の場合、発火は待機します。逃したインターバルは積み重ならず、1回の発火に集約されます。

• ジッター — 繰り返しタスクは意図的に遅れて実行され、その遅れは次回実行までの間隔の最大半分、かつ最大30分です。これにより、多数のセッションが同じ秒に集中しません。10分ごとのタスクは、定刻から5分遅れまでの間のいずれかの時点で開始されます。5分間隔の場合だけは例外で、Claude Code は各実行をプロンプトキャッシュのウィンドウ内に収めるため、15秒前倒しします。

• マシン起動が必須 — ループは Claude Code が実行中かつアイドル状態のときのみ発火します。ノートPCを閉じると停止します。離席していた時間分を後から取り戻すことはできません。

最後の点こそが、このワークフローがプラットフォームチームのものではなく、メンテナーのための仕組みである理由だ。1台のマシンで、1つのセッション中に3つのループを回すのは、別のことをしながら忙しいオープンソースプロジェクトを進め続けるための方法であって、サービスではない。

なぜこのワークフローが「単なるエージェント」ではなく、Claude Opus 5.5 に固有なのか

大きなコンテキストウィンドウを持たないモデルに対して3エージェントループを実行すると、そのループは一日中再読込に費やすことになる。各イテレーションでは、issueスレッド、PR diff、Discord履歴を毎回取り込み直す。ウィンドウが小さいと、その履歴は要約されて失われ、セッションが進むにつれてループの判断は静かに劣化する。Claude Opus 5.5は1Mトークンのコンテキストウィンドウと128Kトークンの出力を備えており、これによってトリアージループは実際のissueバックログに加えて会話と直近数回のイテレーションを同時に保持できる。また、価格は100万トークンあたり$4 / $20で、そのキャッシュ読み取りは100万トークンあたり$0.20、つまり入力価格の5分の1だ。これはここではいつも以上に重要である。なぜなら、ループは存在する中で最もキャッシュに優しいワークロードだからだ。同じシステムプロンプト、同じツール定義、同じリポジトリコンテキストを、何度も何度も。

2つ目の適合は思考のデフォルトであり、各ループが何をしているかによって逆方向に作用する。Claude Opus 5.5 は適応的思考を常時オンで実行し、エフォートのデフォルトはmedium — Claude Opus 5 のデフォルトより1段階低い。エフォートは品質を変えるだけでなく、ツール呼び出しの量も変える。問題をトリアージするループとコードを編集するループでは、求める設定が異なる。そして最低エフォートの設定は、それ自体がスケジューリングの問題でもある。セルフペースのループでは、モデルが次回の起床遅延を自分で決めるため、低エフォートのトリアージループと高エフォートの修正ループは、同じリポジトリに対して異なるペースで進む。両者を一致させる設定は存在しない。要点は、どちらがどちらかを把握することにある。ペースの違いこそ、あなたが最初に目にするものだからだ。

ループとフィクサーを異なるベンダーのモデルに対して実行したい場合——トリアージは安価なもので、修正は Claude Opus 5.5 で——それは Claude Code の判断ではなくルーティングの判断であり、セッションの前にゲートウェイが置かれている理由でもある。

本番環境を賭けずにこれを試している

スリー・ループ構成に対するもっともな反論は、初日の午後には自律エージェントがユーザーのイシューの前に立つことになる、というものだ。そのループはコメントを書き込むだろう。ものごとをクローズするだろう。これを誠実に導入する方法は、1つのループをドライランモードで1週間、読み取り専用のGitHubトークンに対して実行し、そのトリアージ判断が手作業で下したものと一致するかどうかを確認することだ。そして別途、コミットする前に、モデル自体を測定できる場所へルーティングすることだ。

OrcaRouterでは、anthropic/claude-opus-5.5がAnthropicの定価のまま、一切の上乗せなしで提供されています。しかも単一のエンドポイントがOpenAI互換とAnthropic Messagesの両方の形式に対応しているため、Claude Codeのセッションと、同じモデルを呼び出すスクリプトで、統合を2つ用意する必要はありません。Anthropicは2026-09-22に独自の$4 / $20という価格を公表しました。この定価が動けば、パススルー型のゲートウェイは次の請求サイクルを待たずに同じ日で追随します。何か月も走り続けるかもしれないループを見積もるなら、望ましいのはまさにこの挙動です。プロバイダー間の自動フェイルオーバーは、ドキュメントが警告していながら誰もテストしないケースをカバーします。つまり、午前3時に上流の1つが429を返したからといってループが止まることはありません。ここではモデルフュージョンやルーティングDSLの重要度は低めです。トリアージループが求めるのは1つのモデルを一貫して使い続けることであり、その一貫性こそが判断をレビュー可能にするからです。

数字の3をどうするか

ループエンジニアリングの評判問題は、今年デモされたものの大半が、デモの中で1つの狭い仕事を回す1つのループだったことにある。yetoneの構成が興味深いのは、それが3つの異なる入力——リポジトリ、チャットコミュニティ、公開タイムライン——に対する3つのループであり、メンテナが時間を割けない実際の仕事の形をしているからだ。それはまた、上記のあらゆる制約を露呈させる形でもある。有効期限、ジッター、復元、ペーシング、そしてループはマシンの電源が入っている間しか動かないという事実だ。

移植できる部分は回数のほうではない。それは、各ループがそれぞれ独自のサーフェスと、loop.mdの中に独自のポリシーと、そして起動すべき独自の理由を持っていたこと——そして、それを運用している人なら、イテレーションログから、各ループがなぜその遅延を選んだのかを判別できたことだ。それは、1週間後に実際に監査できる仕組みだ。これらのループはどれも8日目に失効することを踏まえると、それはおおよそ、もう一度組み上げるべきかどうかを判断するために与えられた時間の長さに等しい。

はっきり言っておくべきだろう。これはある実務者によるセットアップであり、X上で本人が説明したものであって、ベンダー推奨のガイダンスではない。AnthropicのClaude Opus 5.5およびClaude Codeの/loopに関するドキュメントは、ツールが何をするかを示している。だが、3が正しい数だとは述べていないし、他の誰もまだ述べていない。

トリアージループと修正ループに別々のモデルを使いたい場合：ループと修正役を1つのエンドポイント経由で実行すると、OpenAI互換とAnthropic Messagesの両形式に対応した単一のエンドポイントから、Claude Opus 5.5をAnthropicの定価で利用できます。

このようなモデル選択は、障害モードが表面化する場でもあります。このクラスのモデルの背後にある、記録されたAIインシデントやエージェント障害は、OrcaRouter AIインシデントアーカイブに収められており、各エントリには独自の情報源、重大度、信頼度グレード、係争中フラグが付いています。