1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@aktsmm(やまぱん！)

Loop Engineering とは？ エージェントに「指示する側」を卒業する設計の話

1
Posted at

こんにちは、エージェントに毎日同じ指示を打ち込んでたアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

最近、自分が VS Code や Claude Code の前で同じ指示を朝から繰り返していることに気付いて、ふと「これ、自分がプロンプター（指示出す人）になっちゃってないか？」と思ったんですよね。
ちょうど同じ頃、Addy Osmani さんが "Loop Engineering" という言葉でその違和感を綺麗に言語化していました。^[Addy Osmani, "Loop Engineering", https://addyosmani.com/blog/loop-engineering/ (2026/06/07)]

この記事では、その Loop Engineering の正体と、現場で動かすときの設計ポイントを、自分なりにまとめます。

TL;DR

  • Loop Engineering とは「エージェントに指示する人」から自分を外し、代わりに指示する仕組みを設計すること（Osmani が 2026/06/07 に記事として整理し、用語が定着。Steinberger は 2026/05 から、Cherny は数週間前から同趣旨を発信）
  • 「ループ」自体は新発明じゃなく、control loop / TDD / CI / SOAR など半世紀前から使われてきた形。新しいのは 中で動く worker が LLM になって、曖昧さを吸収できるようになったこと（Nathan House, StationX）
  • prompt → context → harness の積み重ねの 1 つ上の階に乗る概念で、harness が「人間の入力を待つ」のをスケジューラと検証で置き換える
  • 1 ターンで必要な動きは 5 つ: Discovery / Handoff / Verification / Persistence / Scheduling
  • 部品は 6 つ: Automations / Worktrees / Skills / Connectors / Sub-agents / Memory（Claude Code と Codex でほぼ 1:1 対応）
  • 一番外しがちなのが Verification（"nodding loop"）。書いた本人に採点させず、別モデルの skeptic（疑う側のレビュアー）を回す
  • ループの本当のコストは API 利用料じゃなく、検証負債・理解の腐敗・思考の放棄・トークン暴発 の 4 つ。「動かす」ループは 30 分で組めるが、「エンジニアでい続ける」ループにするには checkpoint を意図的に残す必要がある
  • 振り返ると自分も、家の LAN トラブルや株 PoCを、Copilot Scheduler で定期実行しながら似たような形で回していた。Osmani の 5 moves に当てはめ直すと、後から名前がついて整理された感じで、新しいのは概念より「組むコストが激減した道具側」だったかも

きっかけ：用語は 1 ヶ月で爆誕した、けど概念は半世紀前から

調べてみて面白かったのが、"Loop Engineering" という用語自体は本当にここ 1 ヶ月で広まったものなのに、概念としては全然新しくない、というところです。

用語が広まったタイムライン

時期 出来事
2026/05 中 Peter Steinberger（OpenClaw 著者）が X で同じ趣旨の投稿を始める。バリエーション違いで何度か投げていた
2026/05〜6/06 Boris Cherny（Anthropic / Claude Code リード）が「私はもう Claude をプロンプトしていない。Claude をプロンプトするループを動かしている。私の仕事はループを書くことだ」と数週間前からインタビューで発言
2026/06/07 Steinberger の "monthly reminder" 投稿がバズり、数日で数百万ビュー^[Peter Steinberger on X (2026/06/07), https://x.com/steipete/status/2063697162748260627]
2026/06/07 同日 Addy Osmani（Google Cloud AI Director、元 Chrome 14 年）が essay を公開、これを "Loop Engineering" として記事に整理（用語が定着）^[Addy Osmani, "Loop Engineering" (2026/06/07), https://addyosmani.com/blog/loop-engineering/]
2026/06/08 以降 Osmani が Substack でも展開、X でさらに広まる
2026/06/17 Forbes (Lance Eliot) が解説記事^[Lance Eliot, Forbes (2026/06/17), https://www.forbes.com/sites/lanceeliot/2026/06/17/loop-engineering-is-fully-making-the-rounds-for-boosting-generative-ai-and-agentic-ai/]
2026/06 StationX (Nathan House) が「新パラダイムか、リブランドされた cron か」という批評記事（公開日付未明示）^[Nathan House, StationX (2026/06), "Loop Engineering: New Paradigm or Rebranded Cron?", https://app.stationx.net/articles/loop-engineering]

「Steinberger のフレーズは同じ週に爆発した。Cherny は既に数週間それを言っていた。Osmani が同日に essay でそれを教えられる形にまとめた。そして用語が定着した」
— Nathan House, StationX

ポイントは、Osmani が "発明者" というより "記事として整理して用語を定着させた人"、ということ。流行り言葉として広まった瞬間が 6/7 で、Cherny は実運用を 数百個の small agent（自分の GitHub / Slack / X を読んで次に作るべきものを決めさせる）として既に走らせていた、というのが Nathan House の取材で出てきています。

概念自体は半世紀前から

もうひとつ面白いのが、StationX の Nathan House の整理です。

The loop itself is an idea engineering has used for half a century.
（ループ自体は、エンジニアリングが半世紀使ってきたアイデアだ）

具体的には：

  • Control loop（制御工学）: 50 年前から
  • TDD（テスト駆動開発）: 「テストが緑になるまで書き直す」は loop そのもの
  • CI の retry until green: 何十年も
  • SOAR playbook（セキュリティ自動応答）: 少なくとも 15 年前から、アラート → enrich → 脅威情報照合 → 偽陽性ならクローズ、という verifiable な finish line を持つ loop を回している
  • Cron + script: 「trigger を置く」部分だけはこれ

つまり「trigger を置いて、worker を回して、verifier で stop 条件を判定する」という形は、エンジニアリングの世界ではお馴染みです。

じゃあ何が新しいの？

Nathan House の整理だと、新しいのは 1 点だけです。

AI agent automation flips the contract. You no longer define the steps. You define the finish line, and the intelligence in the loop absorbs the messiness of the path.
（AI エージェント自動化は契約を反転させる。もはやステップを定義する必要はない。ゴールラインを定義すれば、ループ中の知能が経路の汚さを吸収する）

これを Nathan House は "fuzziness tolerance"（曖昧さ吸収）と呼んでいて、要するに 「中で動く worker が LLM になった」ことで、入力の曖昧さやエッジケースに耐えられるようになった、それが本質的な新しさ、と。

具体例として挙げているのが「400 箇所の API 呼び出しを新 API に移行する」というタスク。これは：

  • 昔: regex では判断できない（各箇所ちょっとずつ違う）→ スクリプト化困難
  • 今: 各箇所に小さな判断は要るけど、最終的な検証は機械的（コンパイルが通る・テストが緑）→ ループに丸投げできる

逆に言うと、機械的に検証できない問題（例: 「このアーキ設計は正しい？」）は今でもループ化できない。Nathan House はそこを「the verifier is the bound（境界はベリファイアにある）」と書いています。

つまり「概念は古い、ツールが安くなった」

Osmani 自身もこれを認めていて、loop の流行りは 個別パーツがネイティブ機能化したから、と説明しています。

  • Claude Code の /loop / /goal、Codex の /goal と Automations タブ、sub-agents、worktrees
  • OpenAI Codex の Automations タブ
  • GitHub Actions
  • MCP コネクタ

これらが揃ったことで、昔は shell script を山ほど書かないと組めなかった loop が、設定ファイルとプロンプト数行で組めるようになった。コンセプトは古いけど、「やる」コストが激減したのが 2026 年の今です。

Nathan House の見立て（要約）: Loop Engineering は「新パラダイム」というより、control loop の中身を LLM に置き換えてコストが下がっただけ。ただし「ステップ定義」から「finish line 定義」への契約変更は、これまで自動化できなかった領域に手を伸ばせる、という意味で実質的な変化。

ここを押さえた上で、loop の構造に入ります。

4 層スタック：Loop は harness の 1 つ上に乗る

この概念は、これまでの AI 開発の延長線上にあります。Osmani の記述と、独立に整理された解説 note (HuaShu, Orange Books, 2026/06)^[HuaShu, "Loop Engineering: Stop Asking Me What It Is", Orange Books v260615, 2026/06. https://drive.google.com/file/d/1qzKI4DKnyHRpXK1J3ATPqwaqLc0iNu-M/view] を併せて整理すると、4 層になります。

層 スコープ ねらい
1. Prompt engineering 一文 1 つの指示を上手く書く
2. Context engineering 一窓 1 つのコンテキスト窓を上手く埋める
3. Harness engineering 一実行 1 つのエージェントが動く環境（ツール・権限・終了条件）
4. Loop engineering 自走 harness を スケジュールで自動的に動かす仕組み

ポイントは「積み木」というより「入れ子（マトリョーシカ）」で考えるとしっくり来ます。Prompt は Context の中に含まれていて、Context は Harness が組み立て、Harness は Loop が回す対象、という包含関係です。

Loop Engineering の 4 層スタック

「上の階」と書きましたが、実態は「外側の輪」のほうが近いです。Loop が来たから Prompt が消えるわけではなく、Prompt も Context も Harness も全部、Loop の中で繰り返し呼ばれる。Loop は harness の中で「人間の次の入力を待っている」ところを、timer や trigger と evaluator で置き換える役割を担います。

Osmani の 1 行定義はこうです。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（Loop Engineering とは、エージェントに指示する人としての自分自身を置き換えること。代わりに指示する仕組みを設計する）
— Addy Osmani

そして、harness との関係を彼はこう表現しています。

The harness but it runs on a timer, it spawns little helpers, and it feeds itself.
— Addy Osmani

「自分を解放するため」に loop を作るのか、「自分が判断しなくて済むため」に loop を作るのかで、同じループでも結果が真逆になる、と Osmani は釘を刺しています。後半でまた触れます。

1 ターン = 5 つの動き

Loop の「1 周」は「もう一回プロンプトを送る」では足りません。HuaShu の note では、これを 5 つの move に分解しています（Osmani の 6 部品論と表裏一体）。

Move やっていること 主な部品
1. Discovery 今ターンで何をやるか、自力で見つける Skills / Triage Automation
2. Handoff 仕事を孤立した作業環境に渡す Git Worktree
3. Verification 別の存在に「No」と言える機会を作る Sub-agent / /goal
4. Persistence 結果を会話の外（disk）に残す State file / Linear / Memory
5. Scheduling 次のターンが回るきっかけを置く cron / Automations / GitHub Actions

図にするとこういう環になります。Scheduling が次の Discovery を呼んで一周する、という関係です。

この 5 つは「お行儀のいい仕事の手順」と言ってしまえばそうなんですが、どれか 1 つ抜けるとループは溶ける、というのが現場の感覚に近いです。
たとえば Verification が抜ければ「自分で自分を採点して PR を出す」ループになるし、Persistence が抜ければ「翌朝同じバグをまた発見する」ループになります。

The agent forgets, the repo doesn't.
（エージェントは忘れる。リポジトリは忘れない）
— Addy Osmani

なので、loop のコードは disk に書きに行く前提で組むのが鉄則です。

ループを構成する 6 つの部品

5 つの動き × 6 つの部品 × tool 対応マップ

Osmani の整理だと、ループは 5 つの主要部品 + 1 つの記憶で構成されます。^[Addy Osmani, "Loop Engineering" の "The five pieces, and then notes" セクション] 部品を Claude Code と Codex (OpenAI Codex App) で並べると、ほぼ 1:1 で対応していて、ツールが違っても設計の形は同じになります。

部品 役割 Claude Code Codex (OpenAI)
Automations スケジュールで discovery と triage を回す /loop, /goal, hooks, GitHub Actions Automations タブ + /goal（project + prompt + cadence + env）
Worktrees 並行エージェントを衝突させない git worktree, --worktree, isolation: worktree スレッドごとに worktree 内蔵
Skills プロジェクト知識を毎回再説明しない SKILL.md (.claude/skills/) SKILL.md を $skill-name または /skills で呼ぶ
Plugins / Connectors 実ツールに繋ぐ MCP + プラグイン配布 MCP コネクタ
Sub-agents 立案と検証を別人に分ける .claude/agents/ + agent teams .codex/agents/ の TOML 定義
State / Memory 会話の外に「何が済んで何が次か」を持つ AGENTS.md / progress file / MCP 経由 Linear Markdown ファイル / MCP 経由 Linear

ここでひとつ、私が誤解していたのが /loop と /goal の違いです。

  • /loop は「指定間隔で同じプロンプトを回す」だけ。Claude Code には bundled されているが、Codex には /loop はない（代わりに Automations タブ + Cloud Routines でその役割）。
  • /goal は「書いた条件が満たされるまで走り続け、毎ターン別の小さなモデルが達成判定する」もの。/goal は Claude Code と Codex の両方に同名で存在する、と Osmani も明記しています（Codex has the same thing, also called /goal）。

つまり /goal は仕様レベルで **maker-checker（作る人と検査する人を分ける）**になっています。あとで触れる Generator/Evaluator パターンの「最も簡単な使い方」と言ってもいいです。

You give it something like "all tests in test/auth pass and lint is clean" and walk away.
— Addy Osmani

そして Skill (SKILL.md)。これは GitHub Copilot を VS Code で使っている人にも馴染みのある考え方で、プロジェクトの「暗黙知」を 1 ファイルに書き出して、エージェントが毎回ゼロから推測しないようにする 仕組みです。
Osmani はこれを「intent debt（意図負債）の返済」と表現しています。スキルが無いと、ループは毎周「このプロジェクトはこう書くんですよね？」を再発明し続けます。

Generator / Evaluator パターン：「自分採点」をやめる

ここまでの話の核になるのが Generator/Evaluator パターンです。

Anthropic のエンジニアである Prithvi Rajasekaran さんが、長時間走るエージェントアプリの設計について書いた "generator / evaluator pattern" がベースにあります。^[Prithvi Rajasekaran, Anthropic engineering blog, "Building long-running agentic applications: generator/evaluator pattern" を HuaShu (2026/06) が引用]

ポイントは超シンプルで、「コードを書いたモデル」と「コードを評価するモデル」を分けること。

何故これが効くかというと、エージェントに自分の出力を採点させると、ほぼ必ず褒めるからです。自分が選んだ実装には「ちゃんと理由がある」ように見える、という人間と同じ罠にハマる。Osmani も同じ趣旨を、

The model that wrote the code is way too nice grading its own homework.
（コードを書いたモデルは、自分の宿題を採点するときどうしても甘い）

と書いています。

効くやり方の 3 点

  1. モデルも変える。同じモデルに「今度は批判的にレビューしてね」と言うだけだと、同じ盲点を引き継ぐ。
  2. デフォルトを "broken until proven otherwise" にする。「動くはず」じゃなくて「壊れている前提でしか出力できない」評価者にする。
  3. read ではなく act させる。コードを「読む」だけじゃなく、Playwright MCP で実際にクリックして DOM を確認したり、ターミナルでテストを走らせる。「Approved」と書くのは、行動で否定できなかった時だけ。

/goal （Claude Code・Codex 両方）はまさにこれを内部で薄くやっていて、毎ターン 別のモデル（一般的にはコスト効率の良い小型モデル）が完了条件を判定します。手書きで作りこむ前に、まず /goal を使えると言うのは大きい。

このパターン、銀行業界の maker-checker 原則（取引を起票する人と承認する人を分ける）と同じです。自分採点の loop は、要するに 承認者がいないループです。それが本番に流れると、何が起きるかは想像つきますよね。

やってしまいがちな 5 つのアンチパターン

5 つの move のうち、どれか 1 つでもスキップすると、ループは特有の壊れ方をします。HuaShu の note では、それぞれにあだ名が付いています。私もぜんぶ通った気がする。

抜けた move アンチパターン名 症状
Verification Nodding loop（うなずきループ） 自分採点で「OK」を出し続ける。一番多い
Persistence Amnesiac loop（健忘ループ） 翌朝、昨日と同じ issue をまた triage する
Scheduling Manual loop（手動ループ） デモ日は綺麗に動く。翌週、誰も走らせていない
Discovery Blind loop（盲目ループ） 結局、朝に人間が「これやって」と渡している
Handoff Tangled loop（もつれループ） 並行で動かしたら全員が同じファイルを書いて事故る

特に Nodding loop は気をつけたい。出力が綺麗に整っていればいるほど、レビューする側も「ま、いいか」と通したくなる。だからこそ「書いた人と違うレビュアーを必ず置く」の構造を先に作っておく必要があります。

Tangled loop は、Git の worktree を使うだけで結構解決します。--worktree のついた claude セッションは、リポジトリ履歴を共有しつつ別ディレクトリで動くので、書き込みが物理的にぶつかりません。これ、人間の並行作業でも同じ問題なので、ループの設計を考えてると チーム開発の作法を再発明している気分になります。

実例 1：Osmani の朝の triage ループ

Osmani 自身が回しているループは、派手じゃないけど効きます。

  1. 毎朝、自動で起動する automation が、
  2. 昨日の CI 失敗 / 24h 以内に立った issue / 今朝までの commit を triage skill で読み、
  3. 結果を markdown ファイル（または Linear ボード）に書き、
  4. 行ける項目だけ isolated worktree を切って、
  5. draft 用 sub-agent が修正案を書き、
  6. 別の review 用 sub-agent が「テスト通る・lint 通る」を確認、
  7. 行けるものは PR を自動 open、迷うものは inbox に残す。

これを毎朝、自分が起きる前に走らせておいて、コーヒー入れてる間に inbox を眺める。彼が "What one loop looks like" として紹介している構成です。

You designed it one time. You did not prompt any of those steps. That's Steinberger's whole point made real.
— Addy Osmani

要するに「1 回設計しただけで、それから後は自分はプロンプトを書いていない」状態。私は今、これの簡略版を組み始めていて、ちょっとした調整でも結構効きます。

実例 2：Stripe の Minions、週 1,300 PR

規模が桁違いの事例も一つ。Stripe の社内システム Minions の話です。

以下は HuaShu の note が podcast を整理した内容ベースです（一次ソースは Steve Kaliski の podcast 出演）。

Stripe の Steve Kaliski さんが "How I AI" podcast で紹介した Minions という社内システム。^[Steve Kaliski, "Stripe's Minions: 1,300 PRs a week", How I AI podcast (HuaShu, 2026/06 経由で引用)]

  • 週に 1,300 件超の PR を機械生成し、人間レビューを通してマージしている
  • 基盤は Goose（オープンソースのコーディングエージェント）の社内 fork
  • "reliability は モデルのサイズではなく、制約の質から来る" という設計思想
  • トリガーは軽い: Slack で @bot メンションや emoji リアクション
  • deterministic orchestrator が先に Jira / Sourcegraph / MCP で context を組み立てて、その後 LLM ステップ
  • linter のような hard gate は LLM ステップで上書きできない
  • 実行環境は EC2 上の Devbox。「cattle, not pets」で 1,000+ 同時実行
  • PR は 必ず人間がレビュー。人間は「書く」から「レビュー」へ desk が移動した

この事例で刺さるのは「reliability は制約の質から来る」という一文。
ループの強さはモデルの賢さではなくガードレールの精度で決まる、ということです。エージェント時代も、結局は地味なソフトウェアエンジニアリングなんですよね。

静かに溜まる 4 つの負債

ループが綺麗に回り始めると、トークン使用量や PR 数みたいな「派手な数字」に目が行きがちです。でも本当のコストはもっと静かに溜まる、というのが Osmani の警告です。

負債 何が起きるか
Verification debt（検証負債） 「動いた」と申告された未検証コードが積み上がる
Comprehension rot（理解の腐敗） 自分が書いていないコードが増え、頭の中の地図が現実と乖離する
Cognitive surrender（思考の放棄） 「もう判断しなくていい」が癖になる
Token blowout（トークン暴発） 一晩 idle で回し続けて、月末に請求書を見て真顔になる

これらは 互いに強化し合うのが厄介です。
理解が腐ると評価できなくなり → 評価できないから自動承認に逃げ → 自動承認だから理解はもっと腐る、というスパイラル。

Osmani が "cognitive surrender"^[Addy Osmani, "Cognitive Surrender", https://addyosmani.com/blog/cognitive-surrender/] という別記事で書いている話で、ループ設計が理解を支える方向に働くか、逆に思考停止を進める方向に転ぶかは、設計する人の姿勢で決まると。

静かな負債への 3 つのガード

  • Read a sample, always. 全部読む必要はないが、毎日 1-2 件は 自分の言葉で説明できるまで読む
  • Cap before you ship. 1 回あたりの上限、1 日あたりの上限、リトライ上限を 先に設定する
  • Keep one door open. 構造的に 1 つは人間 checkpoint を残す（PR auto-merge をしない、など）

「便利だから自動化する」と「便利だから判断を委ねる」の境界線は、自分で先に引いておかないとズルズル超えます。

最初のループを 30 分で組むチェックリスト

ここまでで「概念は分かった、で、何から始めればいいの？」を整理します。

必須 6 要素

要素 自問
Discovery source timer で 何を読みに行く？（CI / issues / commits / inbox）
State file ターンをまたぐ記憶は どの disk file か？
Evaluator "No" と言える 独立チェックはあるか？
Isolation 並行エージェントごとに worktree を切るか？
Token cap 支出上限を先に設定したか？
Human review どこで 人間が pause するか？

サンプル: morning-triage Skill

---
name: morning-triage
trigger: invoked by daily automation
---

## Read (DISCOVERY)

- 前回実行以降に失敗した CI run
- 過去 24h に open した issue
- 昨日以降に merge された commit
- 前回の ./state/triage.md

## Judge

- すぐ着手できる？ それともノイズ？
- リリースをブロックするか？ → priority
- 既に tracked されているか？ → skip

## Write (PERSISTENCE)

./state/triage.md に append:
| finding | source | priority | status |

## Hand off (HANDOFF)

emit: worktree=fix/<slug> goal=<stop-condition>

## Stop

auto-merge しない。delete しない。
迷うものは ./inbox/ に置く。

SKILL.md の 5 つの見出し（Read / Judge / Write / Hand off / Stop）が、そのまま 5 つの move に重なります。"Stop" だけが 6 つ目で、これは 設計者が意図的に引いた境界になります。

GitHub Actions 版の最小ループ

ローカル機を起動しっぱなしにできないなら、最小は GitHub Actions で十分です。

on:
  schedule:
    - cron: "0 6 * * *" # 毎日 06:00 (UTC)

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run morning triage skill
        run: claude --skill morning-triage
      - name: Draft fixes in worktrees
        run: |
          for finding in $(parse ./state/triage.md); do
            claude --worktree "fix/$finding" \
              --goal "tests pass and lint is clean" \
              "draft a fix for $finding"
          done

--goal を使うことで、/goal の maker-checker がそのまま CI 上で効きます。注意点は、PR は絶対に auto-merge しないこと。迷うものは ./inbox/ に積んで人間に渡す。

ローカル /loop は機械が起きていないと動かない。雲は機械が寝てても動くが、Codex の Cloud Routines の最小間隔は 1 時間で、毎回 fresh clone が走る。— Addy Osmani の整理を踏まえて

なので、頻度の高い triage はローカル、夜間バッチ系はクラウド、という使い分けが現実的です。

振り返り：「Loop Engineering」って名前がつく前からやってたかも

家の LAN トラブルと株 PoC、それを裏で回していた Copilot Scheduler を、時系列で並べます。

ここまで書いてきた通り、ループ自体は control loop / TDD / CI / SOAR で半世紀使われてきた形です。なので「やってた」と威張れる話じゃないんですが、それでもこの記事を書きながら振り返って気付いたのが、Osmani が "Loop Engineering" と命名する 4 ヶ月前から、自分は LLM 版のループを 3 ヶ所で雑に組んでたということでした。「あ、後から名前がついたな」っていう、ちょっと変な気持ちです 😅

そして StationX の言うとおり「ツールが安くなったから誰でも組めるようになった」のもまさにその通りで、私が 2 月に手で組んだものは、6 月の今なら Copilot Scheduler や Claude Code の /loop で もっと薄く書けます。

2026/02/02: Copilot Scheduler で Scheduling を外部化

最初に作ったのは VS Code 拡張機能 Copilot Scheduler（2026/02/02 Marketplace 公開）でした。

これは要するに、GitHub Copilot Chat のプロンプトを Cron 式で予約実行できる拡張機能です。「毎朝 9 時に最新ニュースをまとめて」「毎週金曜 17 時に週報作成」みたいな定型タスクを、GUI でスケジュールできます。

Osmani の整理で言うところの Automations（Claude Code の /loop / Codex の Automations タブ）に対応する役割を、VS Code + GitHub Copilot 側に乗せたかった、というのが動機でした。Loop Engineering の 6 部品のうち、私が一番触っていなかったのが Automations の部分だったので、自作してでも欲しかったんです。

この拡張機能を先に作ってあったことが、結果として後の Mission Board のトラブルシュートでも、株 PoC の定期実行でも効きました。

2026/02/16〜: 株の自動売買 PoC で週次フィードバックループ

Scheduler を出した 2 週間後、別件で始めたのが、個人検証用の株自動売買 PoC（Ag_Stock_Auto、initial commit 2026/02/16）。これも今振り返ると、Generator/Evaluator パターンに近いことを最初からやってました。

  • Generator: 日次でシグナル生成 → 仮想ポートフォリオに反映
  • Evaluator: 週次 で別ロジックがパフォーマンスをレビューして、ルールやしきい値を見直す
  • Persistence: 日次・週次の結果を全部 disk と Git に書く
  • Scheduling: Copilot Scheduler も使いながら、cron 的に毎日・毎週決まった時間に動かす

「自分が判断しなくていいループ」ではなく、「自分が次に何を見るべきかが、毎週レポートで上がってくるループ」として組んでいて、これは Osmani の "stay the engineer" の例そのものです。週次 review があるからこそ、自分が地図を失わないんですよね。

2026/02/23: Git リポジトリを「掲示板」にしたエージェント協調ループ

きっかけは家の LAN です。
家のサーバー（JAM）に Windows クライアントから突然 RDP できなくなって、原因がしばらく分からなかったんですよね。疎通が断たれた 2 台の PC をクラウド経由で協調させたくて、思いついたのが「Git リポジトリ自体をメッセージ基盤にする」というやり方でした。

両方の PC で動く GitHub Copilot Agent が、missions/<名前>/messages/ の下に Markdown ファイルを置いて、お互いに pull して読む。掲示板みたいなものです。定期 pull のトリガーには、3 週間前に作っておいた Copilot Scheduler をそのまま流用しました。
結果、2 台が協調して調査してくれて、犯人は Global Secure Access Client がローカルポートを 1.4 万本リークしていた、というところまで自分で辿り着きました。

このとき作ったテンプレートが gh-copilot-multi-agent-mission-board で、記事はこちら 👇

Loop Engineering の 5 moves で読み直すと、ほぼ全部当てはまります。

Move Mission Board での実装
Discovery 各 Agent が missions/<name>/messages/ を git pull して新着を発見
Handoff mission ファイルを介して別 PC の Agent に作業を渡す
Verification 受け取り側 Agent が独立に状況を確認して返信
Persistence 全部 Git リポジトリ = disk に書く（履歴も残る）
Scheduling Copilot Scheduler で定期 pull を仕込む

掲示板 = State file、git pull = Discovery、別 PC の Copilot = Sub-agent。
Persistence と Handoff を Git に寄せるだけで、特別な MCP サーバーも専用バスも要らない、というのが当時の発見でした。今読み返しても、これは Osmani が "the agent forgets, the repo doesn't" と言っていることとそのまま同じです。

ループのコードを書いたのが 2026/02 で、"Loop Engineering" という言葉が出てきたのが 2026/06。先に手を動かしていた人間からすると、後から付いた名前で自分のやってきたことが整理されていく、不思議な体験です。

個人の年表でまとめると

個人の Loop 周辺アクション タイムライン

別に予言してたわけじゃなくて、「自分が同じ調べ物を毎朝やってる」「2 台の PC がうまく協調しない」「投資判断のフィードバックを忘れる」みたいな、ただの不便から始まったものです。それを後で Osmani の 5 moves / 6 parts の枠で並べ直したら、ほぼ全部当てはまった、というだけ。

逆に言うと、Loop Engineering の文法を知ってから始める人は、私が 4 ヶ月かけて散らかしたものを最初から綺麗に組めるということでもあります。これ、結構大事だと思ってて、後発のほうがクリーンに作れるはず。

自分の 3 つを 5 moves にマッピングし直すと

Move 自分の実装例
Discovery morning-report 系の自前スクリプト（メール / 会議 / SR 通知 / Credly）／ Mission Board の git pull
Handoff VS Code の subagent と tmp/ 配下の短命作業ディレクトリ ／ 別 PC への mission ファイル
Verification .github/agents/reviewer.agent.md の別エージェント ／ 株 PoC の週次 review ロジック
Persistence tmp/critic-<topic>.md ／ /memories/session/ ／ Mission Board のリポジトリ全体
Scheduling Copilot Scheduler の Cron 予約 ／ Stock PoC の daily/weekly trigger

ここまで書き出してみて、自分でも一番足りていなかったのが Verification の "別モデル化" だと気づきました。今のところ Verification 用 agent は別ファイルにしているものの、モデルは同じ。次に手を入れるなら、ここに別系統のモデルを噛ませて、本当の意味で skeptic（「動いてる」を信じず、壊れてる前提で見るレビュアー）にしようと思ってます。

もう 1 点、Copilot の Skill 文化 (SKILL.md を「入口」ではなく「作業手順」として扱う) が、Osmani の「Skill は intent debt の返済」という言い方と非常に近いです。
スキルを書くことは、エージェントに 1 回だけ説明する貯金みたいなものなので、書くたびに「明日の自分のループが軽くなる」と感じられると、結構楽しい作業になります。

まとめ：build the loop, stay the engineer

Osmani のクロージングが、この記事で一番伝えたかったところです。

技術的には、ループはもう、Codex App や Claude Code の機能群を 5 つの move に正しく並べれば 30 分くらいで組めます。
でも「自分はエンジニアでい続ける」という意思を組み込めるかどうかは、ツールじゃなくて姿勢の話です。

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
（ループを作れ。ただし、ボタンを押すだけの人ではなく、エンジニアであり続ける気のある人として作れ）
— Addy Osmani

同じループを 2 人が作っても、結果は真逆になり得る、と彼は書いています。
片方は「自分が深く理解している領域でスピードを上げるため」に使い、もう片方は「理解しなくて済むため」に使う。ループ自身はその違いを知らない、知っているのは設計者だけ。

私もまずは、自分の Manual loop を 1 つ /loop に置き換えて、Verification を別モデルに任せるところから始めようと思います。これを 1 ヶ月くらい回したら、また結果を書きます。

参考リンク

一次ソース

補助資料

関連ツールの公式ドキュメント

自分の関連プロジェクト

ここまで読んでくれてありがとうございました 🙏
「自分の現場でこの move が刺さった」「この antipattern やらかしてた」など、コメントや感想いただけたら嬉しいです。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?