MCPlato における Loop Engineering：プロンプトから Artifact を残すワークフローへ

先に答えると： Loop Engineering は、より長いプロンプトを書くことではありません。入力を観察し、状態を保ち、チェックポイントで一時停止し、失敗から復旧し、人間の承認を求め、検査可能な Artifact を残せる作業ループを設計することです。MCPlato では、そのループは Wand、Skill、Scheduled Task、channel workflow、または Sprite が調整する複数セッションの集合になります。

MCPlato における Loop Engineering のカバーイラスト

図 1：Loop Engineering は、一回限りの AI への依頼を、永続的な Artifact を生み出す作業サイクルへ変える。

Prompt Engineering が問うのは、どう依頼すべきか？ です。Loop Engineering が問うのは、Artifact が完成するまで、AI はどう安全に作業を続けるべきか？ です。

この違いは重要です。実際の仕事は、一度の応答で完了することがほとんどないからです。メンテナーはテスト証拠付きの修正を必要とし、プロダクトリードは出典とタイムスタンプ付きのブリーフィングを必要とし、運用チームは監査証跡付きのレポートパッケージを必要とし、事業責任者は外部向けまたは破壊的な操作の前に承認を必要とします。

したがって、正しい設計単位はループです。

MCPlato のループ設計メソッド

良いループには三つの性質があります。

1. 観察可能： ユーザーが出典、状態、操作、結果を確認できる。
2. 復旧可能： 作業を最初からやり直したり同じことを繰り返したりせず、チェックポイントから再開できる。
3. Artifact 中心： ループは、レポート、diff、スプレッドシート、パッケージ、意思決定ログ、ブリーフィング、ドラフト、レビュー記録など、検査可能なものに到達して終わる。

MCPlato はこのモデルに自然に対応します。

• Wand： 反復可能な仕事のためにパッケージ化されたワークフロー。フェーズ、ガイダンス、Artifact 指向の可視ランタイムを備える。
• Artifact： ループが有用な作業を行ったことを証明する永続的な出力。
• Sprite： 作業を複数セッションに分割し、結果を再びまとめられる調整役。
• Skill と Distill Skill： ループが有効だと証明されたあと、再度呼び出せる再利用可能な知見。
• ClawMode： 時間、channels、バックグラウンドコンテキストをまたいで作業を続ける方法。
• Scheduled Tasks と Channels： 繰り返しループのトリガーと配信経路。
• 権限とチェックポイント： 有用な自律性を制御下に保つ境界。

実用的な MCPlato ループは、通常、次の九つのステップに従います。

この記事の残りでは、このメソッドを、公開された議論やドキュメントに見られる四つの実際のユーザー需要シナリオに適用します。

シナリオ 1：GitHub issue → 修正 PR → 証拠に裏付けられた QA レポート

オープンソースのメンテナーは、GitHub issues を引き受け、境界付きの修正を試みる agents をすでに試しています。OpenHands はリポジトリ issues のための GitHub resolver を説明しており、その QA ドキュメントは、単にコードを生成するのではなく変更を検証することに焦点を当てています。¹² メンテナーには、パッチ、テスト、そしてその変更がレビューに十分安全であることを示す証拠が必要です。

関連するリスクは、実際の開発者フィードバックにも現れています。Continue の GitHub issue では、ある agent がきれいに停止せず、同じコードで繰り返しループしたと報告されています。³ これこそ Loop Engineering が扱うべき失敗モードです。停止条件のない制御不能な反復です。

GitHub issue から QA 証拠へのループ

図 2：境界付きのエンジニアリングループは、issue が修正されたという主張だけでなく、diff、検証ログ、QA 証拠 Artifact を生成すべきである。

ループ設計

MCPlato では、ループはモデル出力ではなく Artifact から始めるべきです。

1. Issue 受付： issue、リンクされたファイル、再現メモ、リポジトリ制約を収集する。
2. 計画チェックポイント： 編集前に、ユーザーまたはメンテナーへ想定範囲の承認を求める。
3. パッチフェーズ： スコープ化された作業領域内で、合理的な最小変更を行う。
4. 検証フェーズ： 合意されたチェックを実行し、失敗を記録し、承認済み範囲内でのみ再試行する。
5. 証拠 Artifact： 変更ファイル、テストログ、関連する場合はスクリーンショット、残存リスクを含む QA レポートを生成する。
6. レビューゲート： PR または MR 説明のドラフトを準備するが、作業がマージ済みまたは受理済みであるとは表現しない。
7. Distill： パターンが機能するなら、再利用可能なリポジトリ QA Skill またはチーム向け Wand に変える。

MCPlato 実装パターン

ここでは Sprite が調整する構成が有効です。あるセッションが issue を読み計画を起草し、別のセッションがリポジトリを調査し、さらに別のセッションが検証し、最後のセッションが QA 証拠 Artifact を組み立てます。Wand はこれらのフェーズをパッケージ化し、チームが issue ごとにループを作り直さなくて済むようにできます。

重要なガードレールは停止条件です。検証予算を使い切ったとき、同じ失敗が繰り返されたとき、または変更が承認済み範囲を超えるとき、ループは停止すべきです。Artifact は不確実性を隠すのではなく、何が起きたかを正確に述べるべきです。

Artifact： diff 要約、テストログ、QA 証拠レポート、PR/MR 説明ドラフト、リスク一覧。

シナリオ 2：完全な結果を届けるスケジュール型リサーチブリーフィング

定期的なリサーチも、「prompt once」では弱すぎる領域です。スケジュールされた AI タスクについて議論するユーザーは、完了通知だけでなく、完全な結果をメールで送ることを求めています。⁴ Zapier による ChatGPT scheduled tasks の概要は、将来または繰り返しの頻度で ChatGPT にプロンプトを実行させるパターンを説明しています。⁵ 実務上のギャップは配信品質です。有用なスケジュール型ループは、リンク、タイムスタンプ、差分、アクション項目を備えたブリーフィングを生成すべきです。

スケジュール型ブリーフィング配信ループ

図 3：スケジュール型ループは、ソースを集め、重複を除去し、統合し、引用を確認し、完全なブリーフィング Artifact を適切な channel へ届けるべきである。

ループ設計

MCPlato のブリーフィングループは次のようにできます。

1. スケジュールトリガー： 毎日、毎週、または定例会議の前に実行する。
2. ソース収集： 保存済み URL、RSS 風フィード、ドキュメントページ、ワークスペース資料など、承認済みソースを収集する。
3. 関連性判定と重複除去： 重複する発表やシグナルの低い項目を取り除く。
4. 統合： 安定した形式でブリーフィングを書く。
5. 引用チェック： すべての具体的な主張がソース URL に戻れることを確認する。
6. Artifact 出力： 日付付きのブリーフィングを作成し、ソース一覧とアクション項目表を含める。
7. Channel 配信： 完全な Artifact、または Artifact へのリンク付きの簡潔な要約を送る。
8. フォローアップ： ユーザーがより深い分析を求め、次のアクションを割り当て、またはブリーフィングループを distill できるようにする。

MCPlato 実装パターン

ここで Scheduled Tasks、ClawMode、channels が連携します。Scheduled Task がループをトリガーし、MCPlato が承認済みコンテキストを集め、Artifact を生成し、ワークスペースまたは channel へ届けます。ブリーフィングの重要度が高い場合、Sprite はソース収集、統合、引用レビューを別々の workers に調整できます。

ブリーフィングループは、実際にはアクセスしていないソースを読んだふりをしてはいけません。情報が利用できない場合、Artifact には「見つからない」または「未確認」を含めるべきです。この正直な状態は、洗練されていても検証不能な段落より有用です。

Artifact： 日次または週次ブリーフィング、ソース一覧、アクション項目表、前回実行からの差分、引用メモ。

シナリオ 3：ブラウザーログイン、パラメーター入力、レポートダウンロード、ローカル整理

多くの業務ワークフローは、クリーンな API ではなく、いまだにウェブページの背後にあります。Stack Overflow の質問では、ウェブページへログインしてレポートをダウンロードする方法が尋ねられています。⁶ Python.org の議論では、あるユーザーが約 50 社のクライアントについて、それぞれ 3 から 4 本のレポートをダウンロードし、毎週手作業で 3 から 4 時間かかっていると述べています。⁷ これは現実の運用上の痛点です。反復的で、ブラウザーに縛られ、間違えやすい作業です。

ブラウザーレポートダウンロードループ

図 4：ブラウザー自動化では、人間のログイン境界を、反復的なパラメーター入力、ダウンロード、検証、整理のステップから分離すべきである。

ループ設計

安全なブラウザーレポートループは、アクセス境界を明示すべきです。

1. 要件受付： クライアント名、レポート種別、日付範囲、期待されるファイルを列挙する。
2. アクセス境界： ログイン、MFA、CAPTCHA など、ユーザーが手動で行うべきことを決める。
3. 発見と API チェック： ブラウザー自動化を使う前に、文書化されたエクスポートまたは API が存在するかを確認する。
4. ブラウザー自動化： パラメーターを入力し、ダウンロードを開始し、各ステップを記録する。
5. 検証： ファイル名、タイムスタンプ、期待件数、明らかな空ファイルを確認する。
6. 変換： フォルダーを正規化し、適切な場合は形式を変換し、要約を作成する。
7. 例外レポート： 不足しているダウンロード、失敗したクライアント、変更されたページを列挙する。
8. スケジュール反復： 繰り返し可能な部分だけを一定の頻度で実行し、認証情報またはページ構造が変わったときは人間のチェックポイントを置く。

MCPlato 実装パターン

MCPlato を「どんなウェブサイトでも処理できる」と位置づけるべきではありません。ウェブサイトはそれぞれ異なり、ログインは変化し、ポリシーが重要であり、一部のフローは意図的に自動化へ抵抗します。より適切な位置づけは、MCPlato は許可された反復可能な部分を中心に制御されたループを設計する支援ができる、というものです。

ユーザーはログインチェックポイントを処理できます。その後、AI ループは承認済みのブラウザーセッション内で動作し、レポートをダウンロードし、ローカルファイルを整理し、例外 Artifact を生成できます。ウェブサイトが変わった場合、ループは推測するのではなく、停止して不一致を報告すべきです。

この種のループは、数回成功したあとで Wand に distill する価値があることがよくあります。Wand は、脆いトランスクリプトではなく、明確なフェーズと出力フォルダーを備えた、チームの反復可能な「月次レポートパッケージ」プロセスになります。

Artifact： ダウンロード済みレポートパッケージ、成功/失敗一覧、正規化されたフォルダー構造、要約スプレッドシート、例外レポート。

シナリオ 4：リスクの高いツール呼び出しに対する人間の承認

Loop Engineering は、より多く実行することだけではありません。いつ止まるべきかを知ることでもあります。LangGraph の issue では、ユーザーが実行前に操作を承認、拒否、または変更できる approval-node パターンが求められています。⁸ LangChain の human-in-the-loop ドキュメントは、ツール呼び出しの周辺でレビューのために一時停止することを説明しています。⁹

リスク例は身近です。ファイルへの書き込み、SQL の実行、データの削除、コンテンツの公開、メール送信です。これらは単なる「agent steps」ではありません。事業上の操作です。

人間の承認ゲートループ

図 5：良いループは、リスクの高い操作の前に一時停止し、決定を記録し、実行後に証拠を残す。

ループ設計

リスク操作のループは次のようにあるべきです。

1. リスク分類： 次の操作が読み取り専用、可逆、外部向け、破壊的、または金銭関連かを判断する。
2. 操作ドラフト： ファイル変更、SQL 文、メール、投稿、コマンドを、実行せずに準備する。
3. 承認チェックポイント： 意図した操作、理由、期待される影響、ロールバック計画をユーザーに示す。
4. ユーザー決定： 承認、編集、拒否、または追加コンテキストの要求を行う。
5. 実行： 承認された操作だけを実行する。
6. 証拠 Artifact： 決定、前後 diff、実行結果、残存リスクを記録する。

MCPlato 実装パターン

MCPlato のループ語彙により、これは素直に実装できます。Wand はドラフトと実行を分離できます。権限は承認前には狭くし、確認後にのみ広げられます。Sprite は、ユーザーに見せる前に別セッションへ提案操作のレビューを依頼できます。ClawMode と channels は、承認依頼をユーザーが作業している場所へ運べます。

ループは危険な既定値を常態化してはいけません。データ削除、外部メッセージ送信、請求変更、コンテンツ公開には、その操作についてユーザーが信頼済みで境界付きのワークフローを明示的に設計していない限り、ゲートが必要です。

Artifact： 承認記録、変更計画、前後 diff、メッセージまたはメールのドラフト、実行証拠、リスク一覧。

成功したループを再利用可能な MCPlato 能力へ変える方法

ループが一度成功しても、すぐにすべてを自動化しないでください。まず問いましょう。

1. Artifact は有用だったか？ 出力がユーザーの意思決定や作業完了を助けなかったなら、ループはまだ準備できていません。
2. チェックポイントは適切な場所にあったか？ 多すぎるチェックポイントはループを煩わしくし、少なすぎるチェックポイントは危険にします。
3. 別のユーザーが隠れたコンテキストなしに実行できるか？ 答えがいいえなら、必要な入力と前提を文書化します。

次に、適切な MCPlato のパッケージ化経路を選びます。

MCPlato の main branch における最新の方向性は、チャットからパッケージ化された観察可能な作業へのこの移行を強めています。Wands はワークフローを明示化します。Artifact 指向のランタイムビューは結果を見える状態に保ちます。Wand の作成と反復ガイダンスにより、成功したループを再利用可能な能力へ変えやすくなります。Skills と Distill Skill は、メソッドの反復可能な部分を保持します。

原則は単純です。答えだけを保存するのではなく、その答えを生み出した作業ループを保存する。

リスクとガードレール

Loop Engineering は強力ですが、予測可能な形で失敗することがあります。

• 暴走する反復： 予算、反復失敗検出、明示的な終了状態を追加する。
• 偽の完了： ログ、ソース、または前後の証明を含む Artifact を必須にする。
• 権限の肥大化： フェーズごとに権限を割り当てる。
• 隠れたコンテキスト： 前提を Artifact に記録する。
• 過剰自動化： リスクの高いステップに承認チェックポイントを追加する。
• 脆いブラウザーフロー： 静かに推測するのではなく、検証と例外レポートを使う。
• 引用のずれ： ソースのタイムスタンプと引用レビューを必須にする。

良いループとは、最も自律性が高いループではありません。良いループとは、作業を信頼できるほど可視化しながら Artifact を完成させるループです。

FAQ

Loop Engineering とは何ですか？

Loop Engineering は、AI の作業を単一の応答ではなく、状態を持つプロセスとして設計する実践です。ループは、目標、入力、フェーズ、権限、チェックポイント、復旧経路、最終 Artifact を定義します。

Prompt Engineering とどう違いますか？

Prompt Engineering は指示を改善します。Loop Engineering は、指示を取り巻く作業システムを改善します。より良いプロンプトは、より良い最初の答えを生むかもしれません。より良いループは、継続し、検証し、一時停止し、復旧し、提供できます。

MCPlato はどこに位置づけられますか？

MCPlato は、作業がセッション、ファイル、ブラウザーコンテキスト、スケジュール、channels、永続的な出力にまたがるときに有用です。Wand、Artifact、Sprite、Skill、ClawMode、Scheduled Tasks、channels、権限、チェックポイントというループ語彙は、有用な一回限りの作業を反復可能な能力へ変える助けになります。

すべての AI タスクをループにすべきですか？

いいえ。単純な質問は単純な質問のままで構いません。Loop Engineering は、タスクが長時間実行される、反復される、リスクが高い、証拠が多い、または Artifact 中心である場合に使います。

Loop Engineering は正確性を保証しますか？

いいえ。観察可能性、復旧、レビューを改善します。それでもループは悪いソースを使ったり、誤った前提を置いたり、変更されたツールで失敗したりする可能性があります。だからこそ、引用、チェックポイント、例外レポートが重要です。

参考文献

Footnotes

1. OpenHands：GitHub 内のオープンソース coding agents が issues を修正する ↩

2. OpenHands ドキュメント：QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community：通知だけでなく、完全な ChatGPT task 結果をメールで送信する ↩

5. Zapier：ChatGPT scheduled tasks の使い方 ↩

6. Stack Overflow：ウェブページへのログインとレポートダウンロードを自動化する方法はあるか？ ↩

7. Python.org discussion：Selenium を使ってウェブサイトからレポートを自動ダウンロードする ↩

8. LangGraph issue #8026：ApprovalNode ↩

9. LangChain ドキュメント：Human-in-the-loop ↩