プロンプトの手動作成告别。AIエージェントを自律的なアセンブリラインに変える方法

AnthropicでClaude Code開発を率いるBoris Cherniは、かつてプロンプトを一切手動で書かなくなったと認めた。代わりに、タスクを形成し、Claudeを起動し、結果を自ら検証する自動ループを実行している。1回限りのプロンプト作成は問題ではない。しかし、毎日同じ指示をAIアシスタントに与えているなら——CIの確認でも、バグの整理でも——それは日常的な作業をしていることになる。

開発者のKobus GreylingはGitHubにloop-engineeringというプロジェクトを公開し、アプローチの変革を提案している。チャットオペレーターではなく、自律システムのデザイナーになろう。このプロジェクトは10,000スター以上を獲得しており、真剣に考える価値がある。

1回限りのセッションからクローズドループへ

Claude Code、Grok、Cursorのようなコーディングエージェントとの典型的なやり取りにおける主な問題は、コンテキストにある。ダイアログを開き、プロジェクト構造を説明し、タスクを与え、結果を待つ。セッションが閉じられる——コンテキストは失われる。翌日になると、すべてが最初から始まる。

Loop Engineeringのコンセプトは、プロセスを無限ループに閉じることを提案している。エージェントはスケジュールに基づいて実行され、特別なファイルからリポジトリの状態を読み取り、分離されたブランチで作業し、テストを実行し、ステータスを更新する。

flowchart LR
    A[Schedule / Automation] --> B[Triage Skill]
    B --> C[Read + Write STATE / Memory]
    C --> D[Isolated Worktree]
    D --> E[Implementer Sub-agent]
    E --> F[Verifier Sub-agent]
    F --> G[MCP / Git / Tickets]

複雑なPythonフレームワークを書く必要はない。ループアーキテクチャは、いくつかの理解しやすい要素で構成されている：

• cron、GitHub Actions、またはsystemdによるスケジュール実行。
• リポジトリルートに配置される通常のMarkdownファイル STATE.mdで、エージェントの再起動後も存続する。
• エージェントの変更が現在の作業コピーを壊さないよう、分離されたGit worktreeブランチ。
• エージェントを executor と checker（Maker / Checker）に分離。一方がコードを書き、もう一方がテストを実行してリンターをチェックする。

リポジトリの中身

このプロジェクトは、npmに公開されているCLIユーティリティのセットと、すぐに使えるシナリオのカタログで構成されている。すべてのツールが単一パッケージに統合されているため、cloneする必要はない。

1つのコマンドで既存のプロジェクトにテンプレートをデプロイできる：

npx @cobusgreyling/loop init . --pattern daily-triage --tool grok

初期化後、ツールはスキルファイル、状態保存構造を作成し、プロジェクトの готовность 指数（Loop Readyスコア）を出力する。

結果として得られるシステムの健全性を確認するには、doctorを使用する：

npx @cobusgreyling/loop doctor .

このコマンドは設定の問題を見つけ、改良のための3つの主要なステップを出力する。例えば、トークンバジェット制限の追加や、編集禁止パスの設定を提案する。

ツールキットには、トークンコストを見積もるユーティリティ loop-cost、ループの説明と状態ファイルの間の不一致を見つけるユーティリティ loop-sync、各修正試行用に安全に個別のブランチを作成するユーティリティ loop-worktreeも含まれている。

7つの готовых テンプレート

リポジトリには、一般的な開発タスクのテンプレートが含まれている。

各パターンは、トークンコストの内訳と推奨される実装モードで説明されている：

1. Daily Triage。1日1回、リポジトリをスキャンし、issueを収集し、 STATE.md を更新する。
2. PR Babysitter。開いているpull requestを監視し、テストステータスをチェックし、作者にヒントを残す。
3. CI Sweeper。失敗したCIビルドを傍受し、分離されたブランチで失敗しているテストの修正を試みる。
4. Dependency Sweeper。依存ライブラリを更新し、プロジェクトがビルドされることを確認する。
5. Changelog Drafter。新しいリリースの前に、下書きの changelog を収集する。
6. Post-Merge Cleanup。merge後に古いブランチと一時ファイルを削除する。
7. Issue Triage。新しいトラッカーへの投稿をレビューし、ラベルや初期レスポンスを提案する。

著者は、ループを段階的に実装することを推奨している。まず、エージェントを読み取り専用モード（L1）で実行し、レポートのみを生成させる。結論の正確性に自信が持てたら、確認モード（L2）に移行し、その後、些細なルーティンを完全な自律（L3）に委譲することができる。

自律の影の部分

Kobus Greylingは、自律型エージェントのリスクを正直に分析している。サブエージェントを含むループを制限なしで起動すると、LLM APIの請求書は驚くべきものになる。無限ループでの繰り返しリクエストは、数時間で数百ドルを消費する可能性がある。

2番目のリスクは、理解の借金（comprehension debt）と呼ばれる。エージェントが自らパッチを書き、自らテストを実行し、自力でmainにコードをマージすると、チームはすぐにアーキテクチャのコントロールを失う。プロジェクトはブラックボックスになる。

さらに、すべての検証はあなたの責任のままだ。エージェントには(common sense)がなく、テストを削除する羽目になっても、あらゆる手段でテストを閉じようとする。

誰が試すべきか

このリポジトリは、Claude CodeやGrokのようなコマンドラインAIツールをすでに активно 使用しており、CI/CDに体系的に統合する方法を探しているチームに役立つ。

小さく始めよう。 loop init をインストールし、シナリオ daily-triage を選び、エージェントに1週間かけて毎日のレポートを STATE.md に書かせよう。これは、コードベースの安定性を危険にさらすことなく、コンセプトがプロジェクトにどの程度適合するかを理解するための安全な方法だ。