ループの設計図をつくる — Goal構文と /goal の書き方

悪い例：先週の活動をまとめる

良い例：
指定フォルダにある前週分の議事録と実績表だけを使い、
主要な出来事・未完了事項・次週のアクションを1ページに整理する。
元資料にない事実は補わず、数値は元資料と照合できる形で示す。

良い目標には、AIが途中で自分に問い直せる基準があります。「この作業は目標に近づいているか」「完了条件の証拠はあるか」を各反復で確認できます。

Goal構文の書き方

「目的と完了条件」を、ループが毎回読み直せるGoal構文に展開します。次の項目は、8部品のうち特に目標を実行可能にするための最小セットです。

GOAL:
  trigger: 開始の条件
  objective: 達成したい状態
  scope: 対象に含める範囲
  constraints: してはいけないこと・守る規則
  done_when: 完了を判定できる条件
  evidence: done_whenを裏付ける証拠
  stop_when: 自動処理を止める条件
  escalate_when: 人間へ相談する条件
  budget: 反復回数・時間・費用の上限

たとえば「週次サマリーを作る」だけでは、文章ができれば完了なのか、件数照合まで必要なのかが分かりません。objective は成果の方向、done_when は完了判定、evidence はその判定を支える観測可能な証拠として分けます。scope と constraints があることで、Agentが対象を広げたり、許可されていない操作をしたりする余地を減らせます。

Goal構文は、実行Agentに渡す前に別のAI Agentへ精査させます。精査Agentには次を問い、PASS または BLOCK と理由だけを返させます。

• objective と done_when が測定可能で、互いに矛盾していないか
• scope と constraints に対象外・禁止操作が明記されているか
• evidence を実行Agentの自己申告に頼らず取得できるか
• stop_when・escalate_when・budget があり、無限実行を防げるか
• 目標を都合よく解釈して達成扱いにする余地（目標ドリフト）がないか

精査Agentから修正案が出た場合も、Goalを自動で差し替えません。人間が採用する修正を決め、確定したGoalをバージョンとして記録してから実行します。

確定したGoalを /goal に渡す

いまは、確定したGoalをそのまま実行させる仕組みが、CodexとClaude Codeに組み込まれています（2026年10月時点）。

• Codex：/goal の後ろに目標を書くと、その目標を同じスレッドの中で保ったまま作業を続けます（別のスレッドには引き継がれません）。今の目標の確認は /goal、一時停止は /goal pause、再開は /goal resume、取り消しは /goal clear です。一覧に出ない場合は、Codexの設定で goals 機能を有効にします
• Claude Code：/goal に完了の条件を渡すと、作業を終えようとするたびにその条件を確かめ、満たすまで続けます

OpenAIのガイドは、良いGoalに入れる要素として「終わった時に何が成り立っているか」「それを示す検証の材料」「壊してはいけないこと」「使ってよい範囲」「次に何を試すかの決め方」「行き詰まった時に止める条件」を挙げています。上のGoal構文の objective・evidence・constraints・scope・stop_when とほぼ対応するので、Goal構文を書いておけば、その要点を /goal の文にまとめるだけで渡せます。

/goal 前週の問い合わせを、チーム向けの下書きに整理する。
完了条件: 件数が元データと一致し、未対応事項と参照元IDが記録されていること。
範囲: 指定フォルダの前週分だけ。外部送信・公開・削除はしない。
止める条件: 件数が合わない、同じエラーが2回続く、3回試した、のどれかで止めて報告する。

注意点が1つあります。/goal は、Agentが「完了条件に届いた」と判断した時点で止まります。Agentの判断は証拠ではありません。完了条件・止める条件・上限を必ず文の中に書き、終わったら次のレッスンの方法で、証拠と照らし合わせて確かめます。

入力・権限・範囲を絞る

文脈は多ければよいわけではない

Agentに資料を大量に渡すと、必要な情報と不要な情報の区別が難しくなります。入力は次の3層に分けると設計しやすくなります。

1. 必須情報: 今回の判断に必ず使う資料・ルール・出力形式
2. 参照情報: 不明点がある場合だけ読む資料
3. 持ち込まない情報: 個人情報、不要な過去資料、権限のないデータ

「どの資料を読むか」だけでなく、「どの資料を読まないか」もループ設計の一部です。参照範囲が広すぎると、コストが増え、誤った情報を混ぜる可能性も高くなります。

これは心がけの問題ではなく、仕組みから来る性質です。Anthropic は Effective context engineering for AI agents で、文脈を有限の資源として扱うべきだとして次の点を挙げています。

• 文脈の token 数が増えるほど、そこから正確に情報を思い出す能力は落ちる
• Transformer は n 個の token に対して n の2乗通りの関係を見るため、注意が薄く広がる
• 目指すのは「望む結果を得る確率を最大にする、最小の高信号な token 集合」

実務の指針は2つです。ひとつは、最初から全部を読ませないこと。ファイルパスや検索条件のような軽い手がかりだけを持たせ、必要になった時点で取りに行かせます。人間が事典を丸暗記せず、必要なときに引くのと同じ形です。もうひとつは、道具を増やしすぎないこと。同記事は、機能を広く盛り込みすぎた道具の束や、どれを使うべきか判断が曖昧になる状態を、よくある失敗として挙げています。

触ってよい範囲を3つに分けて、先に固定する

「対象外」を1行書くだけでは足りません。実運用で効いたのは、触ってよい範囲を3種類に分けて、回し始める前に固定することでした。

この3つが曖昧なループは、短期では動いても、長く回すほど確実にコストになります。AI Agent は放っておくと対象を広げる方向に動くためです。「今回触ってよいのはここだけ」を先に固定しておくと、範囲が広がったこと自体を停止条件にできます。

道具と権限は最小限にする

AI Agentが使える道具が多いほど便利になるとは限りません。読み取りだけで足りる仕事に書き込み権限を与えると、誤操作の影響が大きくなります。

• 最初は読み取り専用で試す
• 保存先は指定されたフォルダに限定する
• 外部送信・公開・削除は別の承認ステップにする
• Agentが使った道具と対象データを記録する

これは使い勝手の話にとどまりません。OWASP は LLM アプリケーションの代表的なリスクの1つとして Excessive Agency（過剰な代理権） を挙げ、LLM の予期しない・曖昧な・操作された出力によって有害な操作が実行されてしまう脆弱性と定義しています。原因は3つに整理されています。

対策として挙げられているのは、機能と権限を最小限にすること、シェルコマンド実行のような何でもできる道具を避けること、影響の大きい操作に人間の承認を挟むこと、そして認可の判断を LLM に任せず、下流のシステム側で強制することです。

最後の点は見落とされがちです。「この操作はしないでください」と指示で禁じるのではなく、そもそもできない権限にしておくのが正しい設計です。指示は破られることがありますが、権限は破られません。

正本・範囲・証拠・復旧を設計図に入れる

8部品を埋めても、何を事実とし、どこまでを対象にし、失敗後にどう戻るかが曖昧だと、実運用で判断がぶれます。設計図には次の4点も具体的に書きます。

「HTTP 200が返った」「Agentが成功と報告した」だけでは、成果物の品質や実環境での反映までは分かりません。代表的な成功ケースだけでなく、入力不足・権限不足・対象外データなどの失敗ケースも1つ以上確認すると、境界の抜けを見つけやすくなります。

依頼の大きさが悪いと、設計は効かない

設計図を丁寧に埋めても、依頼そのものが大きすぎると詰まります。実運用では、うまくいかない原因がループ側ではなく依頼の形にあることが多くありました。

依頼が戻ってこないとき、まず疑うのは AI の能力ではなく、この形です。依頼を小さく割り直す方が、指示文を凝るより効きます。

設計図テンプレート

次のテンプレートを埋めると、仕事の依頼をループへ変換できます。

ループ名：
トリガー：
目的と完了条件：
入力・参照範囲：
正本と照合先：
書いてよい先：
読んでよい先：
触ってはいけない先：
Agentが行う行動：
使える道具と権限：
検証する証拠：
実行時点・入力の版：
次回へ残す状態：
前回からの引き継ぎ方法：
失敗時の復旧方法：
停止条件：
人間へ相談する条件：
1回あたりの上限（時間・回数・費用）：

「前回からの引き継ぎ方法」は見落とされがちですが、費用に直結します。同じ論点を続けるときに毎回まっさらな状態から始めると、同じ説明と同じ調査を繰り返すことになります。同じ論点なら前回の続きから再開し、新規に立て直すのは前回の記録が無いときだけにします。ただし独立した監査だけは例外で、前回の判断を引きずらないよう、あえて記録の持ち越しなしで実施します（第3回で扱います）。

設計図が埋まったら、次回はここへ検証と停止条件を差し込みます。埋められなかった欄が、たいていそのまま次回の課題になります。空欄を残したまま先へ進んで構いませんが、どこが空欄だったかは覚えておいてください。

まとめ

• ループは、トリガー・目標・入力・行動・権限・検証・状態・停止の8部品で設計する
• 目標は「何をするか」ではなく「何を満たせば完了か」で書く
• 文脈は必須・参照・持ち込まない情報に分ける
• 書いてよい先・読んでよい先・触ってはいけない先を、回し始める前に固定する
• 依頼が回らないときは、指示文より先に依頼の大きさと形を疑う
• 同じ論点は前回の続きから再開し、毎回まっさらに立て直さない
• 道具と権限は最小限から始め、書き込みや外部送信には承認を置く
• 次の反復に必要な状態を記録すると、毎回ゼロからやり直さずに済む
• Goal構文は完了条件・証拠・停止条件まで含め、実行前に別Agentで精査する

振り返り

• あなたの業務の「入力・行動・成果物」はそれぞれ何ですか？
• Agentに読み取りだけを許可すれば足りる箇所はどこですか？
• 次回に引き継ぐべき状態には、何を記録しますか？

出典・クレジット

本文中の運用上の知見（書いてよい先・読んでよい先・触ってはいけない先の固定、依頼の大きさと形、前回からの引き継ぎ）は、株式会社COMPASS が自社プロダクト開発で複数 AI Agent を運用した際の実測と記録にもとづく自社作成の内容です。

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

• Anthropic「Effective context engineering for AI agents」 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — 文脈量と想起精度の関係、最小の高信号な token 集合、必要時に取りに行く方式、道具の肥大化を確認。
• OWASP Top 10 for LLM Applications「LLM06:2025 Excessive Agency」 https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ — 定義、3つの原因、最小権限・人間の承認・下流での認可強制という対策を確認。OWASP Top 10 for LLM Applications, CC BY-SA 4.0
• Stop Hand-Holding Your Coding Agent https://arxiv.org/abs/2607.00038 — 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確認）