ZCodeはエージェント駆動型なのか？Goal Modeと長時間タスクの考え方
ZCodeのGoal Modeを、通常プロンプトとの違い、反復、検証、トークン消費、Full Accessとの関係、安全な使い方に分けて解説します。
公開 2026.07.05 / 更新 2026.07.05
この記事のポイント
- Goal Modeは通常promptや単純なauto-continueではなく、session-levelの目標として扱われる
- 完了判定、経過時間、tokens、iterationを見ながら進めるため、検証可能なgoalを書く必要がある
- Full AccessやAuto Editと組み合わせると進みやすいが、作業範囲と停止条件を狭くしないと危険になる
Goal Modeは普通の「続けて」ではない
ZCode公式は、/goalで設定した目標をsession-level runtime objectとして扱い、目標、budget、verification resultをsystem側で記録すると説明しています。単にモデルへ「続きをやって」と言うのではなく、完了確認まで反復するための作業枠です。
| 依頼 | 悪い例 | 良い例 |
|---|---|---|
| TypeScript修正 | 全部いい感じに直して | npx tsc相当の型エラーを解消し、buildが通るまで。失敗したら原因と残件を報告する |
| 記事クラスター | ZCodeの記事を増やして | 親ハブ、料金、Goal Mode、安全、比較、MCP記事を追加し、sitemap/checkまで通す |
| UI改善 | 見た目をよくして | 対象ページのLighthouse performance 90以上を目標にし、画像・CSS・bundle増加を確認する |
| 安全確認 | Full Accessで任せる | まずPlan Modeで方針、触るファイル、実行コマンド、停止条件を出してから進める |
Goal Modeと権限モードの関係
Goal Modeは完了条件を管理する仕組みで、権限モードは何を自動実行できるかを決める仕組みです。長いgoalほどAuto EditやFull Accessにしたくなりますが、秘密情報、本番反映、install、外部通信、push/deployを含む作業ではPlan firstの方が安全です。
- 検証コマンドをgoalに含める
- 最大作業時間や最大iterationの目安を決める
- 外部通信、install、push、deployは確認条件を書く
- 失敗時は次の仮説と残件を報告させる
- Usage Statsでtokensとモデル別消費を見る
よくある質問
Goal Modeは「続けて」と何が違いますか？
Goal Modeは目標、status、budget、verification resultsが記録される長時間タスク用の仕組みです。普通のpromptの連続とは扱いが違います。
/goalはモデルにそのまま送られるpromptですか？
公式説明では、/goalはsession-level runtime objectとして扱われます。本文の言い方だけでなく、完了条件と検証方法を書くのが重要です。
Goal Modeは止められますか？
公式docsではactive / paused / completeなどのstatus表示が説明されています。長時間作業では止める判断を人間側にも残してください。
Full Accessと一緒に使うべきですか？
信頼できる狭い作業なら候補ですが、最初からFull Access前提にはしません。Plan、Confirm、Auto Editとの使い分けを先に決めます。
関連記事
- AIエージェントを一晩放置する前に決めること｜止め方・上限・ログ・作業範囲の安全設計
寝る前にAIエージェントを走らせる前に、止め方、上限、ログ、作業範囲、禁止操作を決めます。
- AIエージェントに安全に作業を頼むプロンプトテンプレート｜Codex・Claude Code・MCP向け
AIエージェントに作業を頼む時の安全テンプレートを、禁止事項、確認コマンド、秘密情報、初見repoの読み取り-only確認、push前レビューまで含めて用意します。
- AIエージェントに30分・1時間・8時間の仕事を任せる境界線
長時間タスクを任せるほど、AIの能力よりも、分割、確認、戻せる単位が重要になります。