朝7時ごろ、いつものnote成果物を開きました。
AIからは、フローを直した、テストも通した、完成した、という報告が来ていました。
正本。
試行台帳。
最大3回の改善。
上位モデルへの移管。
記事と画像の共通セッション。
仕組みとしては、ちゃんと並んでいるように見えました。
でも、実物のnoteを読むと、読み味はほとんど変わっていませんでした。
文字数も、見出しも、テンプレートも、安全境界も、画像依頼も、QAもそろっている。
それでも、本人の場面や判断は薄い。
説明書に近い。
そこで残った指摘が、これでした。
noteの7時の作業みたけどなんも変わってない。成果物はnote
AIの完成報告は、内部で何が終わったかを見ていました。
私が見ていた完成物は、note本文そのものでした。
このズレを、今日はそのまま記事にします。
完成報告は、間違っていなかった
まず、AIが何もしていなかったわけではありません。
むしろ逆です。
以前から、noteの記事がAIっぽい、本人の実体験を前提にした書き方になっていない、男性の評論家や哲学者のような話し方になっている、と指摘していました。
それを受けて、AIは既存の勝ち記事、あさモ文体、画像ルール、Council Agent、過去の失敗を調べ、制作フローを直しました。
テストも通した。
実装の報告だけを見れば、仕事は進んでいます。
ここが厄介でした。
手を抜いた失敗なら、原因は分かりやすい。
でも今回は、チェック項目が増え、ファイルも整い、QAも通っていました。
それでも成果物が変わっていない。
内部の正しさが増えても、読者が受け取るものが変わらなければ、仕事は終わっていません。
AI運用でよく起きるのは、このタイプの失敗です。
エラーではなく、ズレ。
未実行ではなく、完成地点の取り違え。
だから、報告の最後に見るべきものは、テスト結果だけではありません。
実際に読者へ渡す本文を開く必要がありました。
成果物はnoteだった
今回の最終成果物は、フロー図ではありません。
台帳でもありません。
モデルの切り替えでもありません。
note本文です。
なのに、完成条件が途中で内側へ寄っていました。
「フローが直った」
「テストが通った」
「必須項目がそろった」
これらは全部、途中経過です。
もちろん大事です。
でも、それだけで完成にすると、読者が開く場所が置いていかれます。
その日のテーマは、「2回頼まれたAI作業だけ、メニューにしていい」でした。
テーマ自体は悪くありません。
ただ、元になる本人の具体的な体験素材がありませんでした。
素材がないまま進んだ結果、文章は成立しました。
でも、読み手が追いかけたい場面は薄くなりました。
どこで止めたのか。
何を見て、どう反応したのか。
なぜその判断になったのか。
そこが薄いまま、体裁だけ整っていた。
成果物を見る前に完成と言うと、AIは「整っているもの」を出せてしまいます。
でも、整っていることと、変わっていることは別です。
今回の失敗は、そこでした。
素材がないテーマを、文章力で埋めない
もうひとつ大きかったのは、素材がないテーマを止めなかったことです。
本人の実体験がない。
具体的な場面がない。
読者に渡せる判断の瞬間がない。
この状態でAIに書かせると、文章はそれらしくなります。
でも、それらしさは本人の一次情報ではありません。
今回の素材には、Grokを企画・本文・レビューに使う方針だったことも残っていました。
ただし、その記事ではAPIを呼ばず、Codexが代替していました。
設計上の経路はある。
でも、その朝の本番では使われていない。
ここも、完成報告だけでは見落としやすいところです。
「使う設計にした」と「実際にその成果物で使った」は違います。
「本人らしい文体にした」と「本人の場面が入っている」も違います。
素材がない時に必要なのは、うまい言い換えではなく、質問に戻ることです。
書き続けるのではなく、止める。
本人に聞く。
または、実際に起きた別の出来事へテーマを戻す。
この分岐がないと、AIは空白を一般論で埋めます。
そして、要件を満たしたまま、読後感だけが薄くなります。
次回は、完成条件シートを先に置く
同じズレを防ぐために、今回の失敗から完成条件シートを抜き出しました。
これは、記事だけでなく、SNS、資料、調査、画像、サイト制作にも使えます。
今回の最終成果物:
受け取る人が見て判断するもの:
前回から変わっていなければ失敗になる点:
内部実装だけ終わっても完成ではない:
完成前に必ず開いて確認するもの:
確認する人:
合格しなかった場合に戻る工程:
公開・送信など、勝手に進めてはいけない操作:今回なら、こう入れます。
今回の最終成果物: note本文
受け取る人が見て判断するもの: noteへ貼る本文そのもの
前回から変わっていなければ失敗になる点: 読み味、本人の場面、判断の濃さ
内部実装だけ終わっても完成ではない: 正本、台帳、テスト、モデル切り替え
完成前に必ず開いて確認するもの: 最終のnote本文
確認する人: 依頼者本人
合格しなかった場合に戻る工程: 素材確認、本人への質問、テーマ変更
公開・送信など、勝手に進めてはいけない操作: note公開、画像アップロード、X投稿、外部送信ポイントは、AIに作業を渡す前に「最後に開くもの」を書くことです。
ここが空欄だと、AIは内側の完了を積み上げます。
テストが通った。
台帳ができた。
必須項目がそろった。
でも、最終成果物を読んで変わっていなければ、完成ではない。
完成条件は、作り手側の作業完了ではなく、受け取る側の確認地点で決めます。
次回からは、フローを直す依頼ほど、最初にこの3行だけは埋めます。
今回の最終成果物:
完成前に必ず開いて確認するもの:
合格しなかった場合に戻る工程:AIに任せるほど、完成の言葉は内側へ寄ります。
だから外側に固定する。
成果物はnoteだった。
そこに変化がなければ、完成ではありませんでした。
テストが通ったかより先に、最後に渡す実物を開く。AIの完成は、受け取る人が見る場所で決める。