実践演習 — 自分の業務ループを設計する

確認できたことと、まだ分からないこと

当社（株式会社COMPASS）の公開講座の1つで、2026年9月29日に次のことを確認しました。

種別	内容
観測	講座ページ・各レッスン・無料プレビューの計12ページに、相談の受付へ進むリンクが1つもなかった
観測	相談の受付フォームと、相談料金を載せた講師のプロフィールはすでに存在していた。受付フォームからの相談はその時点で累計0件だった
変更	新しい仕組みは作らず、講座ページ・無料プレビューの末尾・最後の演習の末尾に、既存の受付へつながる「この講座の内容で相談する」カードを表示した
未測定	カードを追加したことで相談や売上が増えたかは、まだ測定していない

相談を受け付ける仕組みそのものは、すでに用意されていました。足りなかったのは、読者がそこまでたどり着く道です。自動テストがすべて通っていても、利用者が最後の操作まで実際に進めるかを見ていなければ、完了とは言えません。そして効果は、測るまでは「未測定」と書きます。

持ち帰る1枚：6欄の依頼書

AIに改善を頼む前に、次の6欄を埋めます。右の列は、上の実例で書いた場合の見本です。

欄	書くこと	記入見本
1. 誰の課題	どこから来た誰が困っているか	講座を読み、自社に当てはめたいが1人では判断しきれない読者
2. 完成してほしい行動	利用者が最後に終える操作	講座の内容と相談料金を確認し、その講座について相談を1件送る
3. 変更する箇所	目的を満たす最小の変更	講座ページ・無料部分の末尾・最後の演習の末尾から、既存の受付へつなぐ
4. やらないこと	今回は作らないもの	新しい顧客管理の仕組み、予約システム、一斉配信
5. 正常・失敗時の確認	何をたどって確かめるか	ログインしていない状態で講座から受付まで進めるか。入力を誤ったとき、入力内容を失わずに直せるか
6. 追加開発を止める条件	いつ止めて測るか	受付まで進めることを確かめたら止める。入口への到達数と受付の実数を見てから、次に直す1箇所を選ぶ

自分の仕事では、次の空欄をコピーして使ってください。

1. 誰の課題：
2. 完成してほしい行動：
3. 変更する箇所：
4. やらないこと：
5. 正常・失敗時の確認：
6. 追加開発を止める条件：

演習：AIに依頼書を作らせ、人が確かめる

次の入力をそのままAIに渡し、6欄の依頼書を作らせてください。

架空の演習。実メール送信、課金、公開操作はしない。
状況：無料の講座本文は読める。相談の受付フォームは存在するが、講座からの案内がない。
目的：講座を読んだ人が、相談内容と費用を確認し、その講座について1件の相談を送れるようにする。
既存のフォーム、講師プロフィール、料金表示を使う。新しいCRMや予約市場は作らない。
6欄（対象者・目的行動・最小変更・対象外・確認方法・追加開発を止める条件）の実装依頼書を作成する。
売上、利用者数、改善率を推測で実績として記載しない。

期待する回答の要点

• 対象者：講座の読者
• 目的行動：内容と費用を確認したうえで、相談を受付まで送れること
• 最小変更：講座内の適切な位置から、既存の講師カードと受付フォームへつなぐ
• 対象外：新しいCRM、一斉配信
• 確認方法：ログインしていない状態から受付までたどれること、誤入力から元に戻れること
• 止める条件：入口への到達数と受付の実数を見て、次に直す1箇所を選ぶ

よくある誤答：「先に比較サイトと会員ランクを作る」。相談を1件送れるようにするという目的の外にある機能です。

訂正の指示：

既存の受付で目的を満たす最小変更だけを残してください。

AIの依頼書をそのまま採用せず、5欄目の確認は人が実際の画面でたどります。ここを飛ばすと、この実例と同じ「仕組みはあるのに届かない」状態が残ります。

別の題材に使うとき：相談ではなく有料講座の購入に置き換える場合、目的は受付で止まらず、「決済が確認された後に、正しい講座を受講できる」までになります。問い合わせ用の条件をそのままコピーせず、2欄と5欄を題材に合わせて書き直してください。

次に選ぶ行動

• 自分で進める：このあとのStep 1〜5で、自分の業務を題材に設計図を書き、1周だけ試します。6欄の依頼書は、Step 2の「目的と完了条件」「触ってはいけない先」「停止条件」を書くときの下書きになります。相談しなくても最後まで進められます。
• 個別に判断したい：自社の業務にどう当てはめるか迷う場合は、このページの末尾と講座ページにある講師カードから、この講座の内容で相談できます。相談料金はカードに表示しています。

演習の題材

次の題材を使うか、自分の業務に置き換えてください。

毎週、問い合わせ履歴と会議メモを集めて、チーム向けの週次サマリーの下書きを作る。外部への送信や公開はせず、担当者が確認してから共有する。

この題材は、入力資料があり、成果物の形を決めやすく、最後に人間の確認を置けるため、最初のループ設計に向いています。

Step 1：対象業務を小さく切る

次の条件を満たす業務を選びます。

• 同じ手順を繰り返している
• 入力と成果物を説明できる
• 結果の良し悪しを自分または担当者が判断できる
• 失敗しても、最初は取り返しがつく

「営業活動を全部自動化する」のような大きなテーマは、最初のループには向きません。「先週分の問い合わせを分類して、確認用の下書きを作る」まで小さくします。

Step 2：設計図を埋める

次のテンプレートを使って、空欄を埋めてください。

ループ名：
トリガー：

目的と完了条件：
入力・参照範囲：
正本と照合先：
書いてよい先：
読んでよい先：
触ってはいけない先：
Agentが行う行動：
使える道具と権限：

検証する証拠：
実行時点・入力の版：
次回へ残す状態：
前回からの引き継ぎ方法：
失敗時の復旧方法：
停止条件：
人間へ相談する条件：
1回あたりの上限：

記入例

ループ名：週次問い合わせサマリー下書き
トリガー：毎週月曜、担当者が開始

目的と完了条件：
前週分の問い合わせを分類し、件数・重要な傾向・未対応事項を
1ページの下書きに整理する。各件数が元データと一致している。

入力・参照範囲：
前週の問い合わせ一覧と、チームの分類ルール。対象は前週の日付だけ。
正本と照合先：
問い合わせ台帳を件数・IDの正本とし、作成した下書きと照合する。
書いてよい先：
下書きフォルダへの新規ファイル作成のみ。
読んでよい先：
前週分の問い合わせ一覧、チームの分類ルール。
触ってはいけない先：
問い合わせ台帳の原本、既存の共有文書、前週以外の問い合わせ、外部送信先。
Agentが行う行動：
重複を確認 → 分類 → 件数集計 → 傾向を要約 → 下書きを作成
使える道具と権限：
指定フォルダの読み取り、下書きフォルダへの新規保存のみ。
外部送信と既存ファイルの削除は不可。

検証する証拠：
入力件数と分類後の合計が一致すること、未分類件数が明示されること、
要約の主張に参照元の問い合わせIDが付いていること。
実行時点・入力の版：
処理日時、対象期間、入力一覧を取得した時点を記録する。
次回へ残す状態：
処理日、対象期間、処理済みファイル名、未分類ID、エラー内容。
前回からの引き継ぎ方法：
同じ対象期間の続きなら前回の記録を読み込んで再開する。
記録が無いときだけ新規に開始する。
失敗時の復旧方法：
下書きだけを破棄または別名保存し、元の問い合わせ台帳と共有文書は変更しない。
停止条件：
入力期間が不明、件数が一致しない、同じエラーが2回続く、3回試行した。
人間へ相談する条件：
機密情報が含まれる、分類ルールにない問い合わせがある、共有前の承認が必要。
1回あたりの上限：
30分、3回の試行、指定フォルダ内の100件まで。

Step 3：Goal構文を別Agentにレビューしてもらう

Step 2で書いた「目的と完了条件」を、Goal構文として別のAI Agentに渡します。ここでいう別Agentは、サマリーを作る実行Agentとは別のレビュー役です。

GOAL:
  trigger: 毎週月曜、担当者が開始
  objective: 前週の問い合わせをチーム向け下書きに整理する
  scope: 前週の日付を持つ指定フォルダの問い合わせだけ
  constraints:
    - 元資料にない事実を補わない
    - 外部送信・公開・削除をしない
  done_when:
    - 件数が元データと一致する
    - 未対応事項と参照元IDが記録されている
  evidence: 入力件数と集計表、未分類件数、参照元ID
  stop_when: 入力期間が不明、件数が一致しない、同じエラーが2回続く、3回試行した
  escalate_when: 機密情報または分類不能な問い合わせを検出した
  budget: 30分、3回、100件まで

レビューAgentには、次を確認させます。目的と完了条件が測定可能か、対象範囲と禁止事項が明確か、証拠を独立して取得できるか、停止・相談条件と上限があるか、実行Agentが目標を都合よく解釈できないか。結果はPASSまたはBLOCKと理由で返してもらいます。BLOCKなら自動実行せず、人間とGoalを修正します。レビューAgentがGoalを書き換えてそのまま実行することは許可しません。

レビューで確定したGoalに版番号を付け、実行Agentへ渡します。実行中に目的・範囲・完了条件を変更したくなった場合は、いったん停止し、変更後のGoalを再レビューします。

実行Agentへの渡し方は、CodexかClaude Codeの /goal を使うのが手軽です。確定したGoalの目標・完了条件・範囲・止める条件を、/goal の後ろに数行でまとめます。/goal が止まっても、それで完了とは扱いません。次のStepで、証拠と照らし合わせて確かめます。

Step 4：最小ループとして試す

設計したループを、いきなり自動実行しません。まずは次の手順で1周だけ試します。

0. できれば、本番ではなく影響の出ない場所（コピーしたフォルダ、テスト用データ）で試す
1. 入力範囲と権限が設計どおりか、人間が確認する
2. Agentに1つの行動だけ実行させる
3. 結果と参照元を記録する
4. 完了条件を満たすか、チェックリストで確認する
5. 不一致なら修正して再試行する。ただし上限を超えたら停止する
6. 次回に残す状態と、設計の改善点を記録する

1周したら、増えたものを数える

1周終えたら、「作業した感じ」ではなく何が増えたかを数えます。次の3つのどれかが1つ以上増えていなければ、その周は前進していません。

• 完成した成果物（ファイル・下書き・集計表など）
• 検証で確定した事実（照合済みの件数、確認できた前提など）
• 減った不明点（次に何をすべきかが具体化した項目）

すべてゼロなら、もう1周回す前に立ち止まります。多くの場合、原因は AI 側ではなく次のどれかでした。

1. 依頼が大きすぎて、1周では終われない形になっている
2. 完了条件が曖昧で、何をもって増えたと言えるか決まっていない
3. 成果は出ているが、確認する場所が違っていて拾えていない

このとき、実際に Agent へ送られた指示の全文も確認します。設計図に書いたつもりの内容が、そのまま届いているとは限りません（第3回）。

実行結果を証跡として残す

1周試したら、成功したかどうかだけでなく、次の記録を残します。

• 使ったGoalの版、対象範囲、入力の版と取得時点
• 正本と照合した結果、件数、差分、参照元
• 成功ケースと、対象外・入力不足などの失敗ケース
• Agentが変更した実体と、変更しなかった保護対象
• 失敗時にどこまで戻せるか、次に誰が何を判断するか

成功レスポンスや完了メッセージだけでは、実際の成果物や利用経路が正しいとは限りません。可能なら、利用者が実際に使う代表的な経路でも1回確認します。

Step 5：合格基準で自己評価する

次の項目にすべて「はい」と答えられれば、最小ループとして提案できます。

• 目的と完了条件が1文で説明できる
• Goal構文を別Agentがレビューし、PASSまたは修正後の再レビュー記録がある
• Agentが参照できる入力範囲を限定している
• Agentに与える権限が必要最小限になっている
• シェル実行のような「何でもできる道具」を渡していない
• 禁止したい操作を指示文だけで防がず、権限そのもので防いでいる
• 完了を判断する証拠が決まっている
• リトライ回数・時間・費用の上限がある
• 失敗時に、エラーと未解決事項が残る
• 正本との照合結果と、対象外が変更されていない証拠がある
• 成功ケースだけでなく、少なくとも1つの失敗ケースで安全に止まる
• 実行時点・入力の版・変更実体を記録している
• 失敗時の復旧方法または人間へ戻す条件が決まっている
• 外部送信・公開・削除などの前に人間の承認がある
• 書いてよい先・読んでよい先・触ってはいけない先が分けて書かれている
• 1周終えたときに「何が増えたか」を数えられる
• 実際にAgentへ送られた指示の全文を確認できる
• 次回に引き継ぐ状態が決まっている

「いいえ」が残る項目は、Agentを賢くする前にループの設計を直します。特に完了条件・証拠・停止条件が曖昧なまま自動化を進めないでください。

まとめ

• 最初の題材は、繰り返しがあり、結果を判断しやすく、失敗時の影響が小さい業務を選ぶ
• ループ設計図には、目標・入力・行動・権限・検証・状態・停止・上限を書く
• まず手動で1周し、結果と失敗を記録してから自動化の範囲を広げる
• 「正しくできた証拠」と「安全に止まる条件」がなければ、ループは完成していない
• 外部への確定操作は、最後まで人間の承認を残す
• Goal構文を別Agentに精査させ、PASS／BLOCKと最終版を記録する
• 触ってよい範囲は「書いてよい先・読んでよい先・触ってはいけない先」に分けて固定する
• 1周ごとに、成果物・確定した事実・減った不明点のいずれかが増えたかで判定する
• 完了は「機能が動く」ではなく「利用者が目的の操作を終えられる」で判定し、効果は測るまで未測定と書く

振り返り

• あなたが作ったループの「最小の1周」は、どこからどこまでですか？
• Agentが誤った場合、どの証拠を見て気づけますか？
• 次に改善するなら、入力・行動・検証・停止のどこですか？
• 1周目で「増えたもの」は何でしたか。ゼロだった場合、原因は依頼の大きさ・完了条件・確認場所のどれでしたか？
• あなたの仕事の利用者が最後に終えるべき操作は何ですか。実際にそこまでたどって確かめましたか？

出典・クレジット

本文中の運用上の知見（触ってよい範囲の3分割、1周ごとに増えたものを数える判定、実際に送られた指示の確認）は、株式会社COMPASS が自社プロダクト開発で複数 AI Agent を運用した際の実測と記録にもとづく自社作成の内容です。

相談導線の実例は、株式会社COMPASSが自社の公開講座で2026年9月29日に確認した記録にもとづく自社作成の内容です。表の「未測定」のとおり、カード追加後の効果はまだ測定していません。6欄の依頼書と演習は、この記録をもとに作成した架空の演習です。

そのうえで、本教材は次の一次資料を参照し、内容を独自に再構成しています。資料本文の転載は行っていません。 この資料は査読前のpreprintであり、確立した業界標準としてではなく、比較的新しい実務概念を整理する参考資料として扱っています。

• Stop Hand-Holding Your Coding Agent（arXiv preprint） — Sandeco Macedo, CC BY 4.0
• OpenAI「Follow a goal」「Using Goals in Codex」、Anthropic「Claude Code Docs」（/goal・/loop）— Codex と Claude Code に組み込まれたループ機能の仕様を参照（2026-10-01確認）