見出し画像

AIへ作業を頼む前に決める4つの終了条件|Codexの「完了しました」で終わらせない依頼方法

AIに作業を頼んで、

「完了しました」

と言われたものの、

「……で、私は何を確認すればいいんだろう?」

となったことはないでしょうか。

私はCodexに記事制作やコード修正を頼むとき、最近は作業を始める前に「何をしたら完了なのか」を決めるようにしています。

AIは文章やコードを短時間で形にしてくれます。

ただし、AIが言う「完了」と、人が安心して使える「完了」は同じとは限りません。

そこで私が先に決めているのが、次の4つです。

  • 変更してよい範囲

  • 残す成果物

  • 確認する操作

  • 触れてはいけない情報・操作

この記事では、実際にCodexへ記事制作を頼んでいる流れを例に、4つの終了条件を整理します。

なぜ「終了条件」を先に決めるのか

2026年9月10日、Xでもこの4項目について投稿しました。

取得時点では、

  • 表示:131

  • いいね:20

  • 返信:3

  • リポスト:1

  • 詳細クリック:15

という反応でした。

これは24時間後の確定値ではありませんし、この数字だけで需要があると判断するつもりもありません。

ただ、AIを使っていると、

「どこまで任せればいいのか」

「完了と言われた後に何を見るのか」

が曖昧になりやすいという問題は、実際の作業でも何度も感じています。

そこで今回は、私自身が使っている終了条件を具体例付きで残しておきます。

1.変更してよい範囲を決める

最初に決めるのは、

「AIがどこまで触ってよいか」

です。

たとえば、

「記事を1本作ってください」

とだけ頼んだ場合、

  • 新しい記事だけ作るのか

  • 既存記事も修正するのか

  • 管理ファイルも更新するのか

  • 外部サービスへ投稿するのか

が曖昧です。

今回の記事012では、変更してよい範囲を次のようにしました。

  • 記事番号012の正本Markdown

  • 記事012の根拠と公開前確認の記録

  • 記事012のアイキャッチ画像

  • note記事一覧の制作状況

一方で、

  • 既存記事の本文

  • 作業中の未コミット変更

などは対象外にしています。

重要なのは、

「AIが変更できるか」ではなく、「今回の目的のために変更する必要があるか」

で範囲を決めることです。

コードなら対象ファイル。

記事なら対象記事。

画像なら変更する画像と、残すべき要素。

最初に境界線を作っておくだけでも、意図しない変更を防ぎやすくなります。

2.残す成果物を決める

次は、

「何が残ったら完了なのか」

を決めます。

AIとの会話では、回答欄に文章が表示された時点で「完成」に見えることがあります。

しかし、その文章をあとで使うなら、会話の中だけに残っていても不十分です。

私はnote記事の場合、Markdownファイルを正本として保存しています。

今回の記事なら、最低でも次の3つを成果物として残します。

  • noteへ転記できる本文

  • 記事内容に合ったアイキャッチ

  • 根拠・未確認事項を含む公開前チェック記録

さらにMarkdown側では、

  • タイトル

  • 公開状態

  • 公開URL

  • アイキャッチ

  • タグ

なども管理しています。

つまり、

「記事を書いてください」

ではなく、

「どの形式で、どこに、何を残したら完成なのか」

まで決めておくということです。

これだけで、次の作業にも引き継ぎやすくなります。

3.確認する操作を決める

成果物が存在することと、

実際に使えることは別です。

最近は画像生成AIも、一度画像を作って終わりではなく、「ここだけ直して」と部分的な修正を重ねながら完成形へ近づけられます。

2026年9月11日に確認したOpenAIの公式案内では、ChatGPT Images 2.5について、指定部分以外を保ちながら編集する精度と、複数回の編集でそれまでの変更を保つ一貫性の向上が説明されています。note上でも、直してほしい場所以外が変わる問題と部分修正の指示を扱う記事を確認しました。

便利になる一方で、私はここに別の問題もあると思っています。

「直せるなら、どこまで直したら完成なのか?」

という問題です。

修正できる回数が増えるほど、「AIが画像を生成したら完了」ではなく、

どの状態になったら作業を終えるのか

を先に決める重要性は高くなります。

たとえば記事なら、文章が保存されているだけでは不十分です。

私は公開前に、次のような項目を確認します。

  • 本文の開始・終了マーカーがあるか

  • note本文に不要な表が残っていないか

  • タイトルと本文の内容が一致しているか

  • リンク先が正しいか

  • 画像を小さく表示しても主要文字が読めるか

  • 未確認の数値を実績として書いていないか

  • 顧客情報や秘密情報が混ざっていないか

以前、AIでnote用のヘッダー画像を作ったとき、

画像単体では問題ないのに、実際の掲載画面では文字の一部が切れる

ということがありました。

その経験から現在は、

  • 画像サイズ

  • 安全余白

  • 文字位置

  • 掲載先での縮小表示

まで確認条件に含めています。

「画像を生成できた」ではなく、

「掲載先で問題なく使える状態になった」

を終了条件にするわけです。

4.触れてはいけない情報・操作を決める

最後は、

「やってはいけないこと」

です。

今回の記事制作では、次の操作はAI側で実行しない条件にしています。

  • noteへの転記と公開

  • Xへの投稿

  • Gitのcommit・push

  • 既存の未コミット変更の削除・上書き

  • 顧客情報や勤務先の非公開情報の利用

人に仕事を頼むときに「ここまではお願いする」「ここから先は自分で判断する」と境界線を引くのと同じように、AIへの依頼にも境界線が必要です。

特にAIは、指示された範囲を効率よく進められるからこそ、

「できること」ではなく「やってよいこと」

を人間側で決めておく必要があります。

特に、

  • 外部公開

  • メッセージ送信

  • 購入

  • 契約

  • 削除

のように、実行後の影響が大きい操作は、人が内容を確認してから実行する方が安全です。

「してほしいこと」だけでなく、

「してはいけないこと」も依頼時に決める。

これも終了条件の一部だと考えています。

今回、実際に入力したプロンプト

ここまで読んで、

「毎回そんな長いプロンプトを書いているの?」

と思った人もいるかもしれません。

実は、今回の記事制作で最終的に入力した指示はこれだけでした。

第一案で記事を作成してください。

かなり短いです。

では、なぜこれだけで作業を進められたのでしょうか。

理由は、この一文を入力する前に、

  • 記事の正本

  • 本文として扱う範囲

  • 記載する項目

  • 画像の保存場所

  • 公開前の確認項目

  • 外部操作の禁止事項

などを、継続して使う作業ルールとして決めていたからです。

つまり、重要なのは

「プロンプトを長くすること」ではありません。

短い指示でも、

共有されている前提と終了条件が明確なら作業を進められます。

逆に、終了条件が何も決まっていない状態では、長いプロンプトを書いても認識がずれることがあります。

今回の記事原稿にはCodex、アイキャッチには組み込み画像生成を使いました。

基盤モデルの識別名と作業時間は取得できていないため、推測では記載していません。

テーマ案の相談から初稿制作までは、AIへの依頼2回で進めました。

その後、

  • 無料記事と有料記事の色分けを相談

  • 無料記事用の青いアイキャッチへ変更

  • 自己紹介記事001だけは特別に赤を残す

  • 本文全体を本人が読み直して改稿

  • ChatGPT Images 2.5を、使用ツールではなく外部事例として追加

という判断を追加しています。

こうした途中変更も含めて、

AIが判断したことと、人が判断したことを分けて残す

ようにしています。

コピペして使える4項目

とはいえ、最初から細かいルールを作る必要はありません。

AIへ依頼するとき、まずは次の4項目だけ埋めれば十分です。

次の条件で作業してください。

【変更してよい範囲】
対象のファイル・文章・画像:
変更してよい部分:

【残す成果物】
保存するもの:
保存形式と保存場所:

【確認する操作】
完了前に確認すること:
正常と判断する条件:
確認できない場合:未確認と記載する

【触れてはいけない情報・操作】
変更しないもの:
外部公開・送信の可否:
秘密情報や個人情報の扱い:

たとえば画像制作なら、

「横長画像を作ってください」

だけでなく、

  • どこへ掲載するのか

  • どの範囲を安全余白にするのか

  • 残すキャラクターや要素

  • 必ず読める必要がある文字

  • 公開まではしないこと

まで指定します。

コード修正なら、

  • 変更対象

  • 実行するテスト

  • 維持する既存機能

  • 削除してはいけない未コミット変更

を決めます。

記事制作なら、

  • 正本

  • 本文の範囲

  • 根拠

  • CTA

  • 画像

  • 公開前チェック

  • 外部公開の可否

を指定します。

すべてを書く必要はありません。

自分の作業で事故が起きやすいところから、少しずつ追加していけばよいと思います。

AIと人の役割も先に分けておく

今回の記事制作でAIへ任せたのは、

  • 既存記録の確認

  • 記事構成

  • 初稿作成

  • アイキャッチ作成

  • 形式チェック

です。

一方で、人が判断したのは、

  • Xの反応を見て記事化するか

  • どの案を採用するか

  • 無料記事を青、有料記事を赤にするか

  • 記事001だけ赤を残すか

  • 本文の導入・説明・CTAをどう表現するか

といった部分です。

さらに公開前には、

  • 自分の経験と本文の表現が一致しているか

  • noteの画面で画像が切れていないか

  • リンク先が正しいか

  • 公開日時に問題がないか

を人が確認します。

ここで大切なのが、

AIが確認できなかったことを「問題なし」にしないことです。

確認できないなら、

「未確認」

と残します。

これも私が使っている終了条件の一つです。

「作業前」と「作業後」の2段階で確認する

今回紹介した4項目は、

AIへ作業を頼む前のチェック

です。

ただし、終了条件を決めても、AIの出力が必ず正しくなるわけではありません。

作業が終わった後には、

  • 変更されたファイル

  • 実際の差分

  • 既存機能への影響

  • 保存データ

  • エラー

  • 元に戻す方法

などを確認する必要があります。

私は、

作業前に「どこまでやるか」を決める。

作業後に「本当にできているか」を確認する。

この2段階でAIを使うようにしています。

作業後に確認している具体的な7項目は、こちらの記事にまとめました。

AIの「直しました」を信用する前に確認する7項目|小さなWebアプリのチェックリスト

まずは次にAIへ頼む作業で、

「確認する操作」だけでも1つ書いてみてください。

AIから「完了しました」と言われたあとに、

「何を確認すればいいんだ?」

と迷ったときにも、確認する場所を決めやすくなります。

もしAIに「完了しました」と言われたあと、確認方法が分からず困った経験があれば、コメントで教えてください。

実際に困りやすい場面を集めながら、この4項目も今後改善していこうと思います。

いいなと思ったら応援しよう!