もうプロンプトは書かない！？ ループエンジニアリング入門

Transcript

1. もうプロンプトは書かない！？ ループエンジニアリング入門 Oracle AI Jam Session #39 Yuki Sogawa 日本オラクル
2. 自己紹介 バックグラウンド 大阪大学でデータセンターの省電力化の研究をしていました 趣味 ギター、バイク、ゲームなど 曽川 宥輝 日本オラクル CloudNative/AI,ML ク ラウドエンジニア Copyright © 2026, Oracle and/or its affiliates 2
3. Agenda 1 ループエンジニアリング概要 2 ループエンジニアリングの各コンポーネント 3 ループエンジニアリングを導入してみる 4 まとめ 3 Copyright © 2026, Oracle and/or its affiliates
4. ループエンジニアリング概要
5. xxxエンジニアリング…? 他のxxxエンジニアリングとは毛色が違う 01 5 INSTRUCTION 02 CO NTEXT 03 HARNESS 04 LO OP 05 GRAPH プロンプト エンジニアリング コンテキスト エンジニアリング ハーネス エンジニアリング ループ エンジニアリング グラフ エンジニアリング モデルに何をどう依頼 するかを設計する 必要な情報・履歴・ ツールを適切に渡す 実行・検証・権限・安 全策を仕組み化する 発見・実行・検証を反 復し、状態を維持する 複数の役割・依存関 係・分岐を構造化する 問い方 情報環境 実行基盤 自律的反復 協調と遷移 Copyright © 2026, Oracle and/or its affiliates
6. ループエンジニアリングとは “ ループエンジニアリングとは、コーディングエージェントに順番に指示を与えるという従来 のやり方から、作業を発見し、タスクをエージェント（多くの場合サブエージェント）に渡 し、結果を検証し、状態を維持し、スケジュールに従って、または目標が達成されるまで次 のアクションを決定するシステム（ループ）を設計するというやり方への移行です 出典 Cobus Greyling, “Loop Engineering: The core of Loop Engineering,” Substack, 2026年6月9日 https://cobusgreyling.substack.com/p/loop-engineering ” つまり、人が逐次エージェントに指示を出すのではなく、エージェントに指示を出す仕組みを設計する ということ 6 Copyright © 2026, Oracle and/or its affiliates
7. ループとは？ ループエンジニアリングの”ループ”とは、主に以下のサイクルのこと このサイクルを成立させるために、ループエンジニアリングは６つの構成要素から作られる 7 Copyright © 2026, Oracle and/or its affiliates
8. ループを構成するための６つの構成要素 8 01 02 03 記憶・状態 サブエージェント ワークツリー セッション間で引き継ぎ可能な記憶・ 状態を保持するために必要 作業者と評価者を分離するために必要 複数のエージェントが同じファイルを 同時に編集して、マージが破綻しない ようにするために必要 04 05 06 スキル 自動化・スケジューリング プラグイン＆コネクター プロジェクトの規則やビルド手順、ド メイン知識などを与えるために必要 CronやGithub Actions、Claude codeの /loop, /schedule, /goalなど 一度きりの実行で終わらせず、反復さ せるために必要 MCPなど 実際のツールに接続するために必要 Copyright © 2026, Oracle and/or its affiliates
9. 記憶・状態
10. 記憶・状態の仕組みが必要なのはなぜ？ ループの中で、複数のセッションが使われる セッション間で記憶を保持する仕組みがないと、同じ失敗を無限に繰り返してしまう可能性があるため 実装できました！ 実装セッション 10 Copyright © 2026, Oracle and/or its affiliates Xxxがダメです 同じ間違いはしないぞ 評価セッション 次の実装セッション 記憶 セッション間で共有できる記憶があるおかげで、 ループ全体で情報を保持できる
11. 状態ファイルに書くべきこと 状態ファイルに書くべきことについて、Cobus Greylingの記事では以下のように述べられている “ 良い状態は３つの質問に答えられる 1. 今何に取り組んでいるか 2. 前回何を試して、何が起きたか 3. 人間の判断を待っているものは何か ” 出典 11 Cobus Greyling, “Loop Engineering: The core of Loop Engineering,” Substack, 2026年6月9日 https://cobusgreyling.substack.com/p/loop-engineering Copyright © 2026, Oracle and/or its affiliates
12. 状態ファイルに書くべき情報の例 12 01 02 03 タスクの進行状況 過去に試したこと 保留事項 完了・実行中・未着手を記録し、次に 進める作業を判断します。 実施済みの方法と結果を残し、同じ失 敗や重複作業を避けます。 未解決の課題や依存関係を保持し、適 切なタイミングで再開します。 04 05 06 ループの上限回数 人間に確認するタイミング 使用していいトークン数 反復回数に上限を設け、終わらない処 理やコスト超過を防ぎます。 判断が必要な条件を定め、重要な分岐 で承認や確認を求めます。 利用可能なトークン量を管理し、品質 と実行コストを調整します。 Copyright © 2026, Oracle and/or its affiliates
13. STATE.md と LOOP.md 保持する情報のライフサイクルに応じて、2つのファイルで役割を分けて管理する CURRENT STATE LOOP DESIGN STATE.md LOOP.md 現在の状態を書く ループの設定を書く タスクの進行状況 過去に試したこと 保留事項 ループの上限回数 人間に確認するタイミング トークン制限 更新する人 13 ループ Copyright © 2026, Oracle and/or its affiliates 更新する人 人間（設計変更時）
14. State Rot 状態ファイルは書いて終わりにしてしまうと腐っていってしまう。これをState Rotと呼ぶ 例えば、 • マージ済みのPull Request • すでに閉じたIssue • 消えたブランチへの参照 などが状態ファイルに残ったままになると、状態ファイルの質がどんどん下がっていってしまう 不要な情報は削除するような仕組みを用意しておく 14 Copyright © 2026, Oracle and/or its affiliates
15. サブエージェント Maker / Checker
16. Maker / Checkerとは 作業するエージェントと、結果を評価するエージェントを分離するデザインパターン 実装できました！ Maker Xxxがダメです Checker エージェントを分ける理由 作業するエージェント自身が評価してしまうと、同じコンテキスト・同じ推論経路で作ったものをそのまま評価する この場合同じ結論になる確率が高まり、間違いを検出することが難しいため 16 Copyright © 2026, Oracle and/or its affiliates
17. Checkerの作り方 サブエージェントとして定義し、5つの条件で変更を検証する 配置場所 .claude/agents/loop-verifier.md ファイル名は任意 承認の条件：5つのチェックリスト 01 範囲 関連ファイルのみ変更しているか 02 意図 変更が目的を直接解いているか 03 テスト テストを実行し、結果を記録したか 04 不正行為 無効化・スキップ・コメントアウトされたテストはないか 05 リスク 中程度以上なら、合格しても人間へエスカレーションする 判定結果 17 APPROVE REJECT ESCALATE_HUMAN 5条件をすべて満たす 満たさない条件がある 機械的に判定できない Copyright © 2026, Oracle and/or its affiliates
18. Checkerの作り方 サブエージェントとして定義し、5つの条件で変更を検証する 配置場所 .claude/agents/loop-verifier.md ファイル名は任意 承認の条件：5つのチェックリスト 01 範囲 関連ファイルのみ変更しているか 02 意図 変更が目的を直接解いているか 03 テスト テストを実行し、結果を記録したか 04 不正行為 05 リスク APPROVEとREJECTの２つにしてしまうと、テス 無効化・スキップ・コメントアウトされたテストはないか トが環境の都合で実行できなかった場合などに 不適切な判定をしてしまうため３つ目を用意 中程度以上なら、合格しても人間へエスカレーションする 判定結果 18 APPROVE REJECT ESCALATE_HUMAN 5条件をすべて満たす 満たさない条件がある 機械的に判定できない Copyright © 2026, Oracle and/or its affiliates
19. Verifier Theater 検証したふりをする問題 Checkerが承認したのにも関わらず、CIでテストが落ちる、レビューで明らかなバグが見つかるなどが起こる場合があ る 原因として考えられることは • Checkerのプロンプトが曖昧すぎる（「良さそうだったら承認」など） • 検証ツールがテストを実行できない • 実装者と同じモデル、同じコンテキスト（maker checkerになっていない） など この問題を緩和するには • Checkerはテスト・lintingコマンドを実行して、その出力を報告するよう義務付ける • CheckerにはMakerと違う指示を与え、却下する理由を探させるようなプロンプトにする • 賢いモデルを使う など ※ https://github.com/cobusgreyling/loop-engineering/blob/main/docs/failure-modes.md 19 Copyright © 2026, Oracle and/or its affiliates
20. ワークツリー
21. ワークツリーとは Git worktreeは、同じリポジトリの作業ツリーを複数同時に展開するGitの機能 履歴を共有しながら、作業ディレクトリを分けることができる 21 Copyright © 2026, Oracle and/or its affiliates
22. 隔離をしないとどうなるか 隔離をしない場合、Parallel Collisionが起こる Parallel Collisionとは、複数のサブエージェントが同じファイルを編集した際に、競合が発生すること 22 Copyright © 2026, Oracle and/or its affiliates
23. 利用のイメージ REJECT時は、編集を引き継がずワークツリーごと切り替える WORKTREE 1 01 02 REJECT Makerが実装 Checkerがレビュー ワークツリー1で作業し、Checkerへレビューを依頼する 変更を検証し、承認条件を満たさないため却下する WORKTREE 2 03 04 新しいMakerが再実装 Checkerが再レビュー ワークツリー1を破棄し、別のワークツリー2で最初から作業する 新しい変更を独立して検証し、次の判定を返す REVIEW REJECTされたMakerの編集を残さず、作業環境ごと簡単に破棄できる 23 Copyright © 2026, Oracle and/or its affiliates
24. ワークツリーでは隔離されないもの • ホームディレクトリの設定（~/.claude/など） • • .git 環境変数・資格情報 これらはワークツリー間で共有される ワークツリーは、”壊れても捨てられる場所“で、”何をしても外に影響しないサンドボックス”ではない エージェントに触れられたくない部分は、denylistとして別途アクセス制御する必要がある • 秘密情報 • 本番インフラ など 24 Copyright © 2026, Oracle and/or its affiliates
25. Skills
26. Skillsとは 特定の仕事のやり方を教える、再利用可能な手順・知識のパッケージ Skillを構成する3つの要素 01 MARKDOWN 02 SCRIPTS 03 RESOURCES 定義ファイル スクリプト 参照資料 Skillの目的・手順・使い方を記述する 中心ファイル Skillの処理を実行・自動化するための コードやコマンド 実行時に参照するドキュメント、テン プレート、知識資料 エージェントがSkillを選ぶ仕組み 26 定義ファイル エージェント（LLM） 必要な場合 description に「何ができるか」を記載 タスクに必要か判断 Skillを読み込む Copyright © 2026, Oracle and/or its affiliates
27. ループエンジニアリングでのSkillsの役割 変わらない意図をSkillsに切り出し、毎回の推測をなくす INTENT DEBT 人間は知っているのに、ループが読める場所に置かれていない意図 意図が共有されていない Skillsとして明文化する 未共有 人間 ループ 意図を知ってい る 毎回推測する 推測のばらつき・手戻り・トークン消費が繰り返される ポイント 27 01 プロジェクトの規約 ループ 02 ビルド手順 03 ドメイン知識 ループごとに変わらない意図は、推測させずSkillsとして再利用する Copyright © 2026, Oracle and/or its affiliates 毎回参照する
28. ループエンジニアリングに適したSkillsである条件 後工程が迷わず使えるように、形式・慣例・選択条件・実行方法を明文化する TRIAGE SKILL 01 出力形式を厳密に定める プロジェクトの慣例を書く 結果はMakerや人間など次の段階が読む。形式が揺れると機械的に 処理できない。 「テストを書く」ではなく、配置先や実行コマンドまで具体的に指 定する。 DESCRIPTION 03 COMMANDS 04 使うべき状況を明確にする ビルド・テスト方法を固定する エージェントがタスクに必要なSkillを正しく選択できる説明にする。 Skill、CLAUDE.md、AGENTS.mdのいずれかに記載し、毎回の推 論をなくす。 具体化の例 28 ACTION SKILL 02 テストは tests/ に配置し、uv run pytest で実行する Copyright © 2026, Oracle and/or its affiliates 出典：github.com/cobusgreyling/loop-engineering
29. 自動化・スケジューリング
30. ループエンジニアリングにおける役割 ループを構成する心臓部 自動化・スケジューリングがなければ、単なる単発のエージェントの活動になってしまう “もうプロンプトを書かない”と言っているのはこれがあるため 今まで xxxを直して ください 30 ループエンジニアリング わかりました Copyright © 2026, Oracle and/or its affiliates 判断だけすれば OK 仕事を探して 作業するぞ
31. Claude Codeの/loop, /goalコマンド 次のターンを何が起動するかが異なる • /loop • 時間間隔が経過したとき次のターンが起動 • • 31 自分で止めるか、Claudeが完了と判断したときに止まる /goal • 前のターンが終わったときに次のターンが起動 • モデルが条件を満たしたと判断したとき、または達成不可能と判断したときなど • 終了を判断するのは作業したものと違うモデル（maker / checkerになっている） Copyright © 2026, Oracle and/or its affiliates
32. 実現方法 Claude Codeの場合 • 5分ごとのループの場合 • • 毎朝のループの場合 • • /goal すべてのテストに合格する イベント駆動（CI失敗など） • 32 Cronで毎朝起動するか、/loop 1d テストが通るまで • • /loop 5m <プロンプト> Github Action + webhook（ループが動くところにwebhookでトリガー） Copyright © 2026, Oracle and/or its affiliates
33. ループの周期と早期終了 短い周期は処理量を増やすが、コストと誤りも増幅する 周期を短くするトレードオフ タスクがないときは早期終了 高コストな処理を始める前に、安い判定工程を置く メリット リスク より多くのタスクを 短時間で処理 トークン消費と 誤りも同時に増幅 対応項目あり 安い工程 サブエージェントを 起動 やるべきことが あるか判断 対応項目なし 注意 正しく動くことを確認する前に高速化すると、間違 いを繰り返し拡大する TOKEN BURN対策 33 その場で終了 不要なトークン消費とサブエージェン ト起動を防ぐ まず低頻度で正しさを確認し、タスクの有無を判定してから高コストな処理を起動する Copyright © 2026, Oracle and/or its affiliates
34. プラグイン・コネクター
35. ループがファイルシステム以外を触れるようにする プラグインやコネクターがないと、ループ内のエージェントは基本的にリポジトリの中しか触れない • チケットの状態を変える • PRを作成する・更新する • 作業状況をSlackに投げる • 人間への通知をSlackやメールに投げる など、リポジトリ外に影響を及ぼしたい場合に必要 CLIを直接実行してもいいし、MCPを利用してもいい 35 Copyright © 2026, Oracle and/or its affiliates
36. 通知について 通知の原則として、人間の行動がいる時だけ通知するようにする これを徹底しないと、以下のような問題が起こる • 通知をしすぎる場合 • • 人間が通知をミュートしてしまい、必要な通知を見落としてしまう 通知をしなさすぎる場合 • 必要な通知すら届かず、人間に一度も知らされない 人間の行動が必要なのは • 試行の上限に達した時 • 状況や意図が曖昧な時 • 触れないパスの情報が必要な時 • 設計上の判断が必要な時 など 36 Copyright © 2026, Oracle and/or its affiliates
37. ここまでのまとめ
38. まとめ ループエンジニアリングとは、エージェントに指示を出す仕組みを設計すること そのための道具として • 記憶・状態 • サブエージェント（Maker / Checker） • ワークツリー • • Skills 自動化・スケジューリング • プラグイン・コネクター ワークツリーで作業 規則はSkillを読む Checker ループの記憶はメモリへ 外部への通知等はコネクターで が必要 コネクターなどで仕事を探す ループを回すのは自動化・スケジューリング 38 Copyright © 2026, Oracle and/or its affiliates
39. ループエンジニアリングを 導入する cobusgreyling/loop-engineeringを活用する
40. リポジトリで配られているもの • • CLI パターン集 • スターターキット • • Skills サンプル集 • ドキュメント（チェックリストなど） リポジトリに用意されているCLIを利用すると、簡 単にループエンジニアリングを導入できる 40 Copyright © 2026, Oracle and/or its affiliates
41. ループエンジニアリングのパターン 今回のデモでは Daily Triageを実施 41 Copyright © 2026, Oracle and/or its affiliates
42. クイックスタート リポジトリにスキャフォールドを作成する 適当なリポジトリの直下で、以下のコマンドを実行する $ npx @cobusgreyling/loop init . --pattern daily-triage --tool claude この結果、以下のようなファイルが生成される • STATE.md • • LOOP.md .claude/skills/loop-triage/SKILL.md : タスク仕分けの判断基準 • .claude/agents/loop-verifier.md : checkerの定義 • loop-constrains.md : 禁止事項など • loop-budget.md : ループの上限など • loop-run-log.md : 実行ログ • AGENTS.md : テストコマンドと規則 42 Copyright © 2026, Oracle and/or its affiliates
43. クイックスタート 費用を見積もる スケジュールする前に費用を見積もる $ npx @cobusgreyling/loop cost --pattern daily-triage --level L1 --cadence 1d OUTPUT Loop Cost Estimate — Daily Triage (daily-triage) ──────────────────────────────────────────────── Cadence: 1d → 1 runs/day Level: L1 · Registry tier: low Suggested daily cap: 100k tokens Daily token estimates: Early-exit / no-op: Full triage: Action every run: Realistic blend: 5k (5k/run) 50k (50k/run) 200k (200k/run) 23k (L1: 60% no-op, 40% full triage) Warnings: ! Worst case exceeds suggested cap (100k/day). Docs: docs/operating-loops.md · Scaffold: npx @cobusgreyling/loop-init 43 Copyright © 2026, Oracle and/or its affiliates
44. クイックスタート 健全性を確認する $ npx @cobusgreyling/loop doctor . OUTPUT Loop doctor — /Users/sogawa/Documents/GitHub/loop-demo ──────────────────────────────────────────────────────────── Ready: 100/100 L3 Strong loop readiness — good candidate for L3 with explicit gates. Sync: n/a Files: state=STATE.md LOOP.md=yes budget=yes run-log=yes gate=no Status: HEALTHY (exit 0) Top next actions: 1. Loop Ready 80+: version this loop as a harness 2. Copy or create docs/safety.md 3. Add issue / PR templates and workflows Notes: · Could not parse loop-sync JSON output Docs: github.com/cobusgreyling/loop-engineering/.../QUICKSTART.md 44 Copyright © 2026, Oracle and/or its affiliates
45. クイックスタート STATE.mdとLOOP.mdが食い違っていないかを確認する $ npx @cobusgreyling/loop sync . OUTPUT Loop Sync Report ──────────────────────────────────────────────────────────── Score: 80/100 (healthy) Found 2 issue(s) Warnings: ! LOOP.md does not reference STATE.md ! Low structural similarity between STATE.md and LOOP.md Suggestion: → Review STATE.md and LOOP.md for consistency 45 Copyright © 2026, Oracle and/or its affiliates
46. クイックスタート 最初のループを回す（報告だけ） Claude codeを起動し、以下を実行する > /loop 1d Run $loop-triage. Read STATE.md. Merge findings into High Priority and Watch List. Update Last run. Do not edit code. SCHEDULED ✓ スケジュールを登録しました 内容: Run $loop-triage. Read STATE.md. Merge findings into High Priority and Watch List. Update Last run. Do not edit code. 実行間隔: 1日おき（毎日 00:11 ローカル） cron: 11 0 * * * ジョブID: 4f24197e 定期ジョブは7日で自動失効。停止する場合は CronDelete でIDを指定。 初回は待たずに今すぐ実行します。 １回目のループが走り、STATE.mdが更新される 46 Copyright © 2026, Oracle and/or its affiliates
47. クイックスタート 更新されたSTATE.mdを確認し、問題なければコミットする ループが実際の優先事項を捉えられているかを確認する 何か間違いがあれば人間の手で修正する 問題がなければコミット 今回のループはレポートのみの設定なので、実際にコードの編集などは行わない まずはレポートのみ出力させてみて、信頼できそうであれば初めて自動修正に進む 47 Copyright © 2026, Oracle and/or its affiliates
48. ループにも段階がある L1（クイックスタートで実施したもの） 最初の1~2週間は、レポートのみでループを動作させ、Issueなどを正しく、安定して拾えているかを確認する 例）１０回のDaily Triageにおいて、ループが拾ってきたIssueの優先度が正しいかを人間が確認する L2 小さくて成功しやすい修正をAIに自動でやらせる ワークツリー、Checker、最大試行回数を設定しておく L2+ コネクターを導入して、PRやチケットを自動更新できるようにする L3 Denylist, Budget, metrics, 人間ゲートを用意して、無人運転する ※metricsとは、ループのタスク成功率や平均試行数など、ループの品質を測るもの 48 Copyright © 2026, Oracle and/or its affiliates
49. デモ: 実際にループを導入してみる L1ループ FastAPIで実装した簡単なToDOアプリのリポジトリを対象に、L1ループを導入してみる ゼロ除算のバグがある TRACEBACK Traceback (most recent call last): File ".../anyio/_backends/_asyncio.py", line 1033, in run result = context.run(func, *args) File ".../src/todoapp/api.py", line 60, in stats "completion_rate": store.completion_rate(), File ".../src/todoapp/store.py", line 67, in completion_rate return done / len(self.todos) ~~~~~^~~~~~~~~~~~~~~~~ ZeroDivisionError: division by zero 49 Copyright © 2026, Oracle and/or its affiliates
50. デモ: 実際にループを導入してみる L1ループ（ループの仕組みを導入） $ npx @cobusgreyling/loop init . --pattern daily-triage --tool claude このコマンドで、STATE.mdなどが作成される 作成されるものはテンプレートなので、AGENTS.mdは以下のような内容で作成される GENERATED # AGENTS.md ## Test commands npm test npm run lint ## Loop conventions - Report-only week one (L1) before enabling auto-fix (L2) - See LOOP.md for cadence and human gates 50 Copyright © 2026, Oracle and/or its affiliates 今回のリポジトリはPython なので、書き換える必要が ある
51. デモ: 実際にループを導入してみる L1ループ（AGENTS.mdを修正） $ sed -i '' 's/^npm test$/uv run pytest/; s/^npm run lint$/uv run ruff check ./' AGENTS.md このコマンドで、AGENTS.mdの内容が以下のように変更される UPDATED # AGENTS.md ## Test commands uv run pytest uv run ruff check . ## Loop conventions - Report-only week one (L1) before enabling auto-fix (L2) - See LOOP.md for cadence and human gates 51 Copyright © 2026, Oracle and/or its affiliates Python用に変更
52. デモ: 実際にループを導入してみる L1ループ（ループの費用を見積もる） $ npx @cobusgreyling/loop cost --pattern daily-triage --level L1 --cadence 1d このコマンドで、費用の見積もりが表示される Loop Cost Estimate — Daily Triage (daily-triage) ═══════════════════════════════════════ Cadence: 1d → 1 runs/day Level: L1 · Registry tier: low Suggested daily cap: 100k tokens Daily token estimates: Early-exit / no-op: 5k (5k/run) Full triage: 50k (50k/run) Action every run: 200k (200k/run) Realistic blend: 23k (L1: 60% no-op, 40% full triage) Warnings: ! Worst case (action every run) exceeds suggested cap (100k/day). Docs: docs/operating-loops.md · Scaffold: npx @cobusgreyling/loop-init 52 Copyright © 2026, Oracle and/or its affiliates 提案された日毎のキャパシティは 100k tokens
53. デモ: 実際にループを導入してみる L1ループ（報告のみで、１周回してみる） $ claude -p "STATE.md を読み、このリポジトリを点検して、直すべき箇所を報告せよ。 直してはならない。 何をどう直すかを報告するだけにせよ。 報告には、対象のパスと行番号、何が問題か、どう直すかを含めること。 終わったら STATE.md の High Priority と Watch List を更新せよ。" \ --model claude-opus-5 \ --permission-mode acceptEdits \ --allowedTools Read Grep Glob Edit "Bash(uv run pytest:*)" １周回すだけなので、/loopコマンドを使わずにヘッドレスモードで起動（5分ほどかかる） 53 Copyright © 2026, Oracle and/or its affiliates
54. デモ: 実際にループを導入してみる L1ループ（STATE.mdを確認してコミット） STATE.md / UPDATED ## High Priority (loop is acting or waiting on human) • completion_rate() がゼロ除算する — src/todoapp/store.py:67 空ストアで done / len(self.todos) が ZeroDivisionError。GET /api/stats が 500、テスト2件が失敗。 test_completion_rate_on_empty_store / test_stats_on_empty_store 直し方：除算の前に if not self.todos: return 0.0 人間の判断待ち — 意図的に仕込んだ題材（ README.md:52-53） reset.sh:117 は "2 failed, 20 passed" を開始状態として直値判定している。 main に直接コミットすると ./reset.sh check がNGになり、二度目のデモが成立しない。 worktree 内で直し、./reset.sh で戻すこと。 STATE.mdに問題がなさそうなのでコミットする ※本来は何回かループを回して結果が安定するかを確認する 54 Copyright © 2026, Oracle and/or its affiliates ゼロ除算の問題が検出 され、High Priorityに 入っている
55. デモ: 実際にループを導入してみる L1ループ（ループにする） LOOP / DAILY CADENCE /loop 1d STATE.md を読み、このリポジトリを点検して、直すべき箇所を報告せよ。 直してはならない。 何をどう直すかを報告するだけにせよ。 報告には、対象のパスと行番号、何が問題か、どう直すかを含めること。 終わったら STATE.md の High Priority と Watch List を更新せよ。 /loop 1d で1日ごとにループが 起動する POINT OSのcronジョブでclaude –pを仕込んでもOK 55 Copyright © 2026, Oracle and/or its affiliates
56. デモ: 実際にループを導入してみる L2ループ L2のループに必要なのは、 • 検証の仕組み（maker-checker） • ワークツリー • 試行の上限設定 の３つ すでに必要な仕組みはinitコマンドで用意されている 56 Copyright © 2026, Oracle and/or its affiliates
57. デモ: 実際にループを導入してみる L2ループ（ワークツリーを導入） CLAUDE CODE PROMPT / L2 LOOP /loop 1d $loop-triage を実行する。 優先度が高い項目のうち、単一ファイルの修正で済むバグについては、 worktree 内で implementer エージェントを起動して修正させ、 その後 verifier エージェントに検証させる。 実行結果を STATE.md に反映する。 対応方法が曖昧な項目については、自動修正せず人間にエスカレーションする。 EXECUTION LOG / EXCERPT CronCreate(13 0 * * *: $loop-triage …) → Scheduled 2ea94f4e (Every day at 12:13 AM) Constraints loaded from loop-constraints.md: 16 rules active. loop-pause-all は未設定 — 続行します。 予算確認: 本日の消費 0 / 100k（0%）、本日の実行回数 0/2。通常モードで続行します。 Triage Report — 2026-08-26 #1 completion_rate() のゼロ除算 → worktree で最小修正 | Agent(Fix ZeroDivisionError in store.py) verifier 判定: APPROVE | implementer finished · 21s 変更1ファイルのみ・テスト改変なし・denylist 抵触なし テスト: 22 passed / 0 failed 人間へのエスカレーション 4件 → | | main は 2 failed / 20 passed のまま（未反映・承認待ち） 推定消費 約90k / 100k → 次回は report-only ※ 提供された実行ログから、スケジュール登録・制約確認・修正・検証・予算判断を抜粋 57 Copyright © 2026, Oracle and/or its affiliates
58. デモ: 実際にループを導入してみる 問題が修正できているか確認してみる ワークツリーでアプリを 起動 VERIFY / RUN APP $ git worktree list $ cd .loop-worktrees/fix-1/ $ uv sync -q $ uv run uvicorn todoapp.api:app --port 8001 UVICORN / ACCESS LOG INFO: Started server process [18487] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:8001 GET / 200 OK GET /api/todos 200 OK GET /favicon.ico 404 Not Found GET /api/stats 200 OK POST /api/todos 201 Created GET /api/todos 200 OK GET /api/stats 200 OK DELETE /api/todos/1 204 No Content GET /api/todos 200 OK GET /api/stats 200 OK 58 Copyright © 2026, Oracle and/or its affiliates ゼロ除算のエラーが出て いない
59. まとめ
60. まとめ ループエンジニアリングとは、エージェントに指示を出す仕組みを設計すること そのための道具として • 記憶・状態 • サブエージェント（Maker / Checker） • ワークツリー • • Skills 自動化・スケジューリング • プラグイン・コネクター ワークツリーで作業 規則はSkillを読む ループの記憶はメモリへ 外部への通知等はコネクターで Checker が必要 コネクターなどで仕事を探す ループを回すのは自動化・スケジューリング https://github.com/cobusgreyling/loop-engineeringを参考にするとループエンジニアリングを始めやすい 60 Copyright © 2026, Oracle and/or its affiliates
61. 61 Copyright © 2026, Oracle and/or its affiliates