AIエージェントに作業を頼むとき、最初はついこう言いたくなります。

「いい感じに直して」

実際、これで進むこともあります。
記事の誤字を直す、短い文章を整える、ファイル名を確認する。そういう小さな作業なら、雑な依頼でも十分です。

でも、コードを触る、ブログ記事を公開する、複数ファイルをまたぐ、ビルド確認まで必要になる。そういう作業になると、雑な依頼のままでは少し危なくなります。

この記事では、AIエージェントへ作業を任せるときに、細かい命令を増やすより先に、目的、触ってよい範囲、禁止事項、完了条件、確認方法を渡すと楽になる、という実録メモを書きます。

細かい命令より、まず目的を渡す

AIに頼むとき、手順を最初から全部書きたくなることがあります。

たとえば、ブログ記事を追加してほしいときに、

このフォルダにファイルを作って、
frontmatterを書いて、
本文を書いて、
ビルドして、
結果を報告して

と並べるやり方です。

これは悪くありません。特に定型作業では強いです。

ただし、作業の途中で「このリポジトリは下書きから始めるルールだった」「記事スキーマにFAQがある」「公開前チェックのコマンドが別にある」と分かることもあります。

そのときに、手順だけを渡していると、AIが手順に引っ張られて、現場のルールを見落とすことがあります。

なので、最初に渡すなら手順より目的です。

目的: ブログに新しい下書き記事を1本追加したい。
壊してはいけないもの: 既存記事、ビルド、公開承認ルール。
完了条件: blog:check と build が通ること。

このくらいでも、かなり迷子が減ります。

「やってほしいこと」と「やらないこと」を分ける

AIエージェントは、気を利かせて作業を広げることがあります。

これは便利な面もあります。
関連するファイルを見つけたり、テストを追加したり、作業ログを書いたりしてくれるからです。

一方で、広がりすぎると困ります。

記事を1本書いてほしいだけなのに、デザインを変え始める。
バグを1つ直してほしいだけなのに、周辺の構造を大きく作り替える。
下書きにしてほしいのに、公開状態へ切り替えてしまう。

こういう事故を防ぐには、「やること」と同じくらい「今回やらないこと」も効きます。

やること:
- 新規記事を1本、draft: trueで追加する
- 既存記事への内部リンクを入れる
- blog:check と build を通す

やらないこと:
- draft: falseにはしない
- デザインやカテゴリは増やさない
- 既存記事を大きく書き換えない

これはAIを縛るためというより、作業の境界線を合わせるためです。

境界線があると、AI側も「ここまでは自分で進めてよい」「ここから先は確認が必要」と判断しやすくなります。

完了条件を先に決める

AIとの作業で一番ずれやすいのは、「終わった」の意味です。

人間側は「実際に動くところまで確認してほしい」と思っている。
AI側は「ファイルを書いたので終わり」と扱ってしまう。

このずれは、作業前に完了条件を置くとかなり減ります。

たとえばブログなら、次のように分けられます。

最小完了:
- 記事ファイルを作る
- frontmatterをスキーマに合わせる

確認済み完了:
- npm run blog:check が通る
- npm run build が通る

公開完了:
- draft: falseへ変更する
- commit / pushする
- 本番URLで表示を確認する

この3つは、ぜんぶ違います。

「記事を書いた」と「公開された」は同じではありません。
「ビルドが通った」と「本番で見えた」も同じではありません。

完了条件を分けておくと、AIの報告も正確になります。

禁止事項は、強い言葉で短く置く

AIに頼むとき、禁止事項は曖昧にしない方が安全です。

特に、次のようなものは短く明確にします。

  • 勝手に公開しない
  • 秘密情報をコミットしない
  • 既存のユーザー変更を戻さない
  • 本番プロセスを再起動しない
  • 取引や資金に関わる判断を断定しない

これはAIに対して怒っているわけではありません。

人間同士の作業でも、危険な操作には赤いテープを貼ります。AI相手でも同じです。

とくに公開、削除、移動、認証情報、本番環境、資金、健康、法務に近い作業は、禁止事項をはっきり置いた方がよいです。

「確認して」と「実確認して」は違う

AIに「確認して」と頼むと、文脈によっては静的に読むだけで終わることがあります。

それで足りる場合もあります。
文章の整合を見る、設定ファイルの値を見る、差分を読む。これは静的確認で十分なことがあります。

でも、実装作業では、実際にコマンドを走らせないと分からないことがあります。

たとえば、

  • 型チェックが通るか
  • ビルドが通るか
  • 生成されたページ数が増えるか
  • sitemapに入るか
  • 画面で崩れていないか

こういうものは、できるだけ実確認した方がいいです。

依頼文では、こう書くと伝わりやすくなります。

実確認して。
通ったコマンドと、未確認のものを分けて報告して。

ポイントは「未確認も書いてもらう」ことです。

AIの報告で一番大事なのは、全部できた風に見せることではありません。
確認済みと未確認を分けることです。

依頼文テンプレート

自分用に残すなら、次の形が使いやすいです。

目的:
今回やってほしいこと:
触ってよい範囲:
触らないでほしい範囲:
守ってほしいルール:
完了条件:
確認してほしいコマンド:
報告してほしいこと:

毎回ぜんぶ埋める必要はありません。

小さい依頼なら、これだけでも十分です。

目的: ブログに下書き記事を1本追加したい。
ルール: draft: trueのまま。既存記事は大きく変えない。
完了条件: npm run blog:check と npm run build が通ること。
報告: 作ったファイル、QA結果、未確認点。

このくらいなら、人間側の負担も小さいです。

AIの自由度を下げるのではなく、迷子を減らす

構造化した依頼というと、AIを細かく縛るイメージがあります。

でも、実際には逆です。

目的と境界線が見えている方が、AIは動きやすくなります。

何を調べればよいか。
どこまで自分で直してよいか。
どこから先は人間に確認すべきか。
何をもって完了とするか。

そこが分かっていれば、AIは細かい手順を自分で組み立てられます。

逆に、目的も完了条件もないまま「いい感じに」と頼むと、AIは空気を読もうとして、余計な作業を足したり、必要な確認を省いたりしやすくなります。

構造化は、自由度を奪うためではありません。

AIと人間が同じ地図を見るための作業です。

まとめ

AIエージェントに作業を頼むとき、最初から完璧なプロンプトを書く必要はありません。

ただ、次の5つを置くだけで、作業はかなり安定します。

  • 目的
  • 触ってよい範囲
  • やらないこと
  • 完了条件
  • 実確認と未確認の分離

AIを便利に使うほど、「何を頼むか」だけでなく、「どう終わったと判断するか」が大事になります。

雑に頼んでもいい。
ただし、雑に頼むほど、後ろに小さな構造を置いておく。

そのくらいの距離感が、個人開発やブログ運用ではちょうどよいと感じています。