AIエージェントに仕事を完遂させる｜「実行した」と「終わった」の間を埋める設計
午前 8 時に下書きを作るジョブが、8 時 2 分に Markdown を保存しました。ですが、ビルドは落ちています。Git にも残っていません。これは「実行済み」ではあっても「完了」ではありません。
AI エージェントの自律化を進めるほど、この差が効いてきます。私は、成果物の作成から検証、保存、報告までを 1 つの仕事として渡すようにしています。
成功条件を動詞ではなく状態で書く
「記事を書く」では終了地点が曖昧です。モデルは文章を保存した時点で、依頼を終えたと判断できてしまいます。
代わりに、最後に残る状態を指定します。
- 新しい記事が 2 本あります
- 2 本とも
draft: trueです - frontmatter 監査と textlint が通ります
- Astro の check と build が成功します
- コミットがリモートへ送られています
git statusがリモートとの同期を示します
この書き方なら、エージェントは作業の途中と終了を区別しやすいです。人が確認するときも判定がぶれません。
検証コマンドを仕事の中に置く
文章の見た目だけでは、Astro のスキーマ違反を見抜けません。たとえば description の欠落や日付形式の誤りは、本文を読んでも分かりません。
このブログでは次の順で確認しています。
node scripts/audit-frontmatter.mjs
node scripts/check-humanization.mjs
node_modules/.bin/textlint "src/content/**/*.{md,mdx}"
node_modules/.bin/astro check
node_modules/.bin/astro build大事なのは、コマンドを「推奨手順」にしないことです。すべて成功するまで修正と再実行を続けます。終了条件に組み込めば、検証忘れを減らせます。
私は、生成と公開も分けています。朝のジョブは draft: true の下書きだけを作ります。レビューを通ったファイルだけ、別の指示で公開します。文章の品質判断を、時刻だけで自動化しないためです。
再実行できる仕事にする
無人ジョブでは通信切断や API 障害が起きます。同じ処理をもう一度走らせたとき、記事やコメントが二重に増える設計は扱いにくいです。
再実行前に既存ファイル、Git 差分、外部サービス側の ID を確認します。ファイル名には日付だけでなく、内容を示す slug を使います。投稿 API を使うなら、作成後に返る ID を保存します。
Hermes Agent の通常の cron ジョブは、実行ごとに新しいエージェントセッションを作ります。スクリプトだけを動かす no-agent mode は例外です。
ジョブに作業ディレクトリを指定すると、AGENTS.md などを読み込みます。実行前には API キー、付属スキル、配信先を検査します。不備があればモデルを呼ばずに止まります。この検査は cron.preflight: false で無効化できます。
Gitは保存装置ではなく完了証明になる
ローカルコミットだけでは、マシン故障や作業ディレクトリの取り違えに弱いです。私は次の確認までを一まとまりにしています。
git pull --rebase
git push
git status --short --branchただし、未コミットの変更が先にあれば勝手に混ぜません。誰の変更かを確認できない無人実行では、停止して報告する方が安全です。
コミットメッセージも記録になります。何を作ったか、下書きなのか公開なのかを短く残します。後から git log を見れば、エージェントがどこまで進めたか追えます。
報告には結果と未完了を分けて書く
「問題なく終わりました」だけでは、翌朝また確認することになります。最低でも、変更ファイル、検証コマンドの成否、コミット ID、push 先、残った承認待ちを書きます。
ここまで揃うと、報告は感想ではなく作業記録になります。次に増やすべきなのは処理の数ではありません。機械が自分で完了を証明できる範囲です。
参照した一次情報
