記事本文は、もう読める状態でした。
タイトルもありました。
本文もありました。
画像依頼もありました。
公開前QAまで通っていました。
でも、その日の作業ログを開くと、最後の欄はこうなっていました。
note本文貼り付け: 未実施
画像アップロード: 未実施
公開: 未実施
X投稿: 未実施
外部送信: 未実施
git commit/push: 未実施一見すると、まだ終わっていない作業の一覧です。
でも私は、ここにかなり救われました。
AIに仕事を任せるとき、怖いのは「できていないこと」より、「できた気分で外へ出てしまうこと」です。
下書きができる。
チェックが通る。
ファイルが揃う。
それだけで、AIは前へ進める顔をします。
でも、公開、送信、アップロード、外部共有は別の種類の操作です。
公開しない欄が残っていると、AIの自走はそこで一度止まります。
今日は、その小さなブレーキの話です。
本文はできた、でも出していない
今回のnote作業では、本文そのものは通読できる状態まで来ていました。
ready package には、こう書かれていました。
状態: 記事本文は通読可能。画像は未生成。
status: waiting_for_imageここで大事なのは、「本文ができた」と「公開してよい」が分かれていたことです。
AI運用でよくある失敗は、この2つを同じ箱に入れてしまうことです。
下書きがあるから公開。
画像依頼があるから完成。
QAがOKだから送信。
こうつながると、見た目は速いです。
でも、本当は途中に人間の判断が残っています。
画像はまだない。
noteへの貼り付けもしていない。
公開もしていない。
X投稿もしていない。
つまり、読者に届く直前の作業はまだ全部残っていました。
「通読可能」は、公開許可ではありません。
この差をログに残していたから、AIは勝手に外へ出ませんでした。
これは地味ですが、かなり大事です。
完成に近づくほど、人間は「もういいか」と思いやすくなります。
AIも同じです。
むしろAIのほうが、整ったファイルを見ると次へ進みやすい。
だからこそ、最後の欄に未実施を並べる。
それは進捗の悪さではなく、境界線です。
止めた欄が事故を防ぐ
公開前QAにも、同じ線が残っていました。
本文QAはOK。
勝ち記事との接続もOK。
重複回避もOK。
今日できる一手もOK。
でも、公開前ゲートだけは全部未実施でした。
note本文貼り付け: 未実施
画像アップロード: 未実施
公開: 未実施
X投稿: 未実施
外部送信: 未実施
git commit/push: 未実施このリストは、ただのtodoではありません。
AIが勝手に越えてはいけない線です。
公開は、読者に届きます。
外部送信は、相手に届きます。
X投稿は、戻しにくい場所へ出ます。
画像アップロードは、見た目の事故がそのまま表に出ます。
どれも、内部の下書き作業とは重さが違います。
私はここを、同じ「作業」として扱わないほうがいいと思っています。
AIに任せてよい作業と、人間が最後に見たい作業を分ける。
その分け方を、気分ではなく欄にする。
未実施欄は、AIに対する「ここから先は別ゲート」という標識です。
これがないと、AIは親切に前へ進みます。
親切に貼り付ける。
親切に投稿する。
親切に送る。
そして、人間があとから気づく。
その事故は、AIが暴走したというより、止める場所を書いていなかっただけです。
未実施リストはブレーキではなく境界線
未実施と書くと、作業が遅れている感じがします。
でも、今回の未実施リストは違いました。
進めないための欄ではなく、正しい順番で進めるための欄でした。
まず本文を作る。
次に画像を作る。
それから、本文と画像を一緒に見る。
最後に、人間が公開してよいか判断する。
この順番が見えているから、waiting_for_image で止まれる。
画像がないのに公開しない。
本文だけで完成扱いにしない。
X投稿を先に出さない。
当たり前に見えるけれど、AIに複数工程を任せると、この当たり前がよく抜けます。
とくに、成果物が複数ある仕事は危ないです。
- 本文
- 画像
- 投稿文
- 公開ページ
- 送信先
- 記録ログ
どれか1つができると、全体ができたように見えます。
でも実際には、最後に並べて見ないと分からないことがあります。
文章と画像の温度が合っているか。
公開してはいけない情報が入っていないか。
実在ロゴや製品名が混ざっていないか。
読者に届く順番が自然か。
AIに工程を増やすほど、「まだ出さない理由」を明文化する必要があります。
これはAIを信用しないためではありません。
信用して任せるために、最後の扉だけ別にする。
そのほうが、人間もAIも楽です。
次から公開前ゲートを1行で残す
次からは、AIに外へ出る作業を渡す前に、公開前ゲートを1行で残します。
長い仕様書でなくていい。
最低限、この形で十分です。
公開前ゲート:
本文貼り付け、画像アップロード、公開、SNS投稿、外部送信、commit/push は、人間の確認が終わるまで未実施のまま残す。必要なら、作業ごとに少しだけ変えます。
問い合わせ返信なら、送信を未実施にする。
見積もりなら、金額確定と送付を未実施にする。
記事なら、公開とSNS投稿を未実施にする。
画像なら、ロゴ/IP目視チェック前のアップロードを未実施にする。
大事なのは、AIに「最後までやって」と言う前に、最後の意味を分けておくことです。
AIの自走は便利です。
でも、自走してよい場所と、止まる場所を同じ文章の中に混ぜると危ない。
だから私は、最後の欄だけははっきり残します。
やったことではなく、まだやっていないことを書く。
それは弱さではなく、安全装置です。
公開しない欄があるから、安心して途中まで任せられます。
今日のルールはこれです。
AIに公開・送信・投稿を含む仕事を渡す日は、最初に 未実施のまま残す操作 を書く。
次回見る数字は、未実施ゲートを越えた作業が何件あったかではなく、ゲートなしで外へ出そうになった作業を0件にできたか。
AIに任せる範囲を広げる日は、公開しない欄を先に置く。止める場所があるから、自走は仕事になる。