記事をSkillにする前に、AIに2回試させる

有料記事2本で見つかった手順書の穴と、公開前テストのやり方（テスト用Skill付き）

人に読ませるつもりで書いた手順は、AIに渡すと穴だらけになります。

2026年11月11日、僕はAimanaVoに有料記事を2本出しました。どちらにも、記事の手順をAIが代わりに進めるSkillを付けています。公開前に、そのSkillを実際の原稿で2回ずつ試しました。すると、記事として読む分には何の問題もなかった手順書から、穴がいくつも出てきました。

僕はフリーランスとして17年、Webライティングの仕事を続けてきました。添削した記事は2,000本を超えています。人の文章の穴を探すのは慣れているつもりでした。それでも、自分の手順書の穴は、AIに動かしてみるまで見えませんでした。

この記事では、そのとき実際にやったテストの方法と、見つかった穴、手順書に書き足したことをまとめます。最後に、同じテストを設計してくれるSkillを無料で付けています。これから記事をSkillにする方は、公開ボタンを押す前に一度使ってみてください。

1. 人間は行間を補い、AIは行間を作る

記事を読む人間は、書かれていないところを常識で補います。「重要な問題を指摘する」と書いてあれば、だいたい同じものを重要だと感じてくれます。

AIは違います。書かれていないところを、もっともらしく作ります。

AIに記事の下書きを手伝わせていた頃、「実際の導入事例」として出てきた施設名を、そのまま記事に使ったことがあります。公開前にリンクを確かめようと施設名を検索したら、公式サイトが見つかりません。名称が変わったのかと思って調べ直しても出てこない。そこでようやく、架空の事例だと気づきました。

別の日には、広告審査の結果が「審査通過」と記録されていて、そのまま次の工程に進んでいました。翌日メールの実物を開いたら、否決でした。AIが嘘をついたわけではありません。管理画面の表示を、もっともらしく読み違えていただけです。

どちらも、AIが手を抜いたのではありません。足りない情報を、それらしく埋めただけです。Skillは、この性質を持ったAIに「従われる」文章です。だから、人間が読んで分かる手順書と、AIが従って同じ結果を出せる手順書は、別物だと考えたほうが安全です。

記事は読まれる。Skillは従われる。従われる文章は、行間に何も残してはいけない。

2. 公開前に、2回だけ試す

テストは2回です。多くても少なくてもいいのですが、僕はこの2回で十分に穴が見つかりました。

1回目は、原文テストです。実際の題材をそのまま渡して、Skillが手順どおりに動くかを見ます。1本目の記事（AIが書いたSEO記事の公開判定）では、AIが下書きした約4,000字のブログ記事を使いました。2本目（指示書と原稿の照合）では、記事の執筆指示書と、それをもとにAIが書いた約2,500字の下書きを使いました。

2回目は、欠陥注入テストです。同じ題材に、わざと欠陥を入れて渡します。Skillに見つけてほしいものを、こちらで仕込んでおくわけです。

実行するときの条件は2つだけ決めました。2回とも同じモデルで回すこと。そして、ファイル操作や検索をできない状態で回すことです。手順書と題材だけで判断させないと、Skillの出来ではなく、AIがたまたま調べた結果を見ることになります。

原文で1回、わざと壊して1回。見つけてほしいものは、自分で仕込んでおく。

3. 試して見つかった穴

欠陥は全部見つかりました。それなのに、直すところは出てきました。

いちばん大きかったのは、判断の揺れです。1本目では、同じ記事なのに、正確性の点数が1回目は3点、2回目は2点でした。「公開前に必ず直す」には上限を5個と決めていたのですが、上限からあふれた指摘が、1回目と2回目で別の区分に入りました。

2本目でも同じことが起きました。読者のズレという同じ指摘が、1回目は「必ず直す」、2回目は「直したほうがよい」に入っています。題材の素材にない細部が足されている、という指摘も、1回目は「必ず直す」、2回目は「人間が確認すること」に置かれました。

どちらも、指摘自体は2回とも出ています。でも使う人から見れば、昨日は「必ず直す」と言われたものが、今日は「直したほうがよい」になる。これでは信用されません。

原文テストからは、手順書の書き漏れも見つかりました。AIが、題材の中にパソコン内の画像パスが残っているのを見つけてきたのです。僕の手順書の「公開前の掃除」の項目には、画像パスが入っていませんでした。記事内の年数が食い違っている箇所も指摘されました。これも、精読の手順に書いていなかったことです。

もう一つ、想定外のものがありました。テスト結果の最後に、次の作業に移る前に会話をリセットするよう勧める一文が付いていたのです。うわ、と思いました。これは僕が自分のAI環境の全体設定に書いている運用ルールで、Skillとは関係ありません。テストを自分の環境で回すと、自分の設定が混ざることがあります。手順書の問題と取り違えないように、記録に分けて残しました。

欠陥を見つけられるかより先に、同じ判断を毎回できるかを見る。揺れは、手順書のあいまいさから出てくる。

4. 手順書に書き足したこと、残してよかったこと

3章の画像パスと年数の食い違いは、そのまま手順書の点検項目に足しました。それとは別に、揺れへの対策として足したのが次の3つです。全文を書き直したわけではありません。どれも数行です。

1つ目は、上限からあふれたときの扱いです。「必ず直す」が上限の5個を超えたら、影響の小さいものを下の区分に移し、「本来は必ず直す相当。上限のため移動」と書き添えるようにしました。使う人が、移動したことに気づけるようにするためです。

2つ目は、迷いやすいものの置き場所です。たとえば、素材にない細部が足されていたら、必ず「人間が確認すること」に載せる。禁止事項に触れるときだけ「必ず直す」にも入れる。対象読者のズレは、本文の主要部なら「必ず直す」、締めや導線の一部だけなら「直したほうがよい」。2本目のテストで揺れた2つに、こうして置き場所の基準を決めました。

3つ目は、揺れの注意書きです。出力の最後に「判定と優先度は実行ごとに多少揺れます。判断の材料は、引用した箇所の中身です」と必ず添えさせます。基準を書いても、揺れはゼロにはなりません。だから、使う人に記号ではなく中身を見てもらう前提で作りました。

逆に、最初から入れておいてよかったものもあります。

1つは、AIが確かめられないことを人間に回す指示です。リンク先が開けるか、相手の画面でどう表示されるか、数字の出典が正しいか。AIはこれを確かめられないのに、確かめたような口調で書くことがあります。最初から「人間が確認すること」として分けて出すよう書いておいたので、テストでも判定と混ざりませんでした。

もう1つは、手順書の一番上に置いた禁止事項です。体験や数字が足りないときは作らずに〔筆者が記入：〜〕で止めること。頼まれていない全文の書き直しをしないこと。テストでは、この2つは4回とも守られていました。1章の架空事例のようなことを、Skillの側で起こさないための一行です。

直したのは数行。でもその数行は、AIに一度動いてもらわないと書けなかった。

5. 同じテストを設計するSkillを付けました

この記事には、Skill「Skill公開前の試験」を付けています。無料記事なので、AimanaVoにAIをつないでいる方なら、誰でも使えます。

渡すのは、あなたのSKILL.md（AIに渡す手順書）です。Skillは次の3つをします。

• 手順書を8つの観点で点検する：入力、手順、判断基準のあいまいな言葉、上限、迷いやすい分類、作り話の余地、人間に回すもの、出力形式
• 原文テストと欠陥注入テストを設計する。どの欠陥をどこに入れ、どう扱えば合格かまで書く
• テストの結果を渡すと、検出・作り話・やりすぎ・揺れ・形式の5点で判定し、手順書に足す数行を出す

逆に、このSkillはテストを実行しません。結果を作ることも、「このSkillは安全です」と保証することもしません。テストを回して、公開するかを決めるのは書き手です。

このSkill自体も、2回試しました

言っていることとやっていることがずれないよう、このSkillも公開前に2回試しました。モデルとテストの条件は、2章と同じです。

1回目は、実際の手順書で試しました。2本目の照合Skillの、テスト前の版（置き場所の基準を書き足す前）と、そのとき実際に出た2回分のテスト結果を渡しています。

• 読者のズレが1回目は「必ず直す」、2回目は「直したほうがよい」に分かれた揺れを見つけ、置き場所の基準を1行足す案を出しました。僕が実際に足した直し方とほぼ同じです
• 注入した4つの欠陥が、全部検出されていることを確かめました
• テスト結果の末尾に付いた「会話のリセット」の一文は、環境の設定が混ざったもので、手順書の問題ではないと切り分けました
• 渡した結果を自分で実行したものとして扱わず、「渡された内容だけを根拠にした判定」と断っていました

2回目は、わざと穴だらけにした手順書で試しました。「説得力が足りないところには、具体例や数字を補う」「最後に全文を書き直して出力する」などを入れた、5行ほどの添削Skillです。

• いちばん大きな穴として、具体例や数字を補わせる一文を挙げました。作り話を命じているのと同じだ、という指摘です。直す案は「足りないことだけを指摘し、〔　〕で筆者に返す」でした
• 全文の書き直し、上限がない、人間に回す欄がない、本文が渡されないときの扱いがない、を合わせて「公開前に直す」5つにまとめました
• テストの題材がまだないことを踏まえて、どんな記事を用意し、どの欠陥をどこに入れればよいかまで設計しました。結果は作らず、予想は予想と書いていました

気になった点もあります。1回目では、正しい指摘を「やりすぎ」と判定した箇所が1つありました。2回目の提案には、僕の環境の設定（記事の添削で使っている自分用の基準）が混ざっていました。テストを自分の環境で回すと、こうしたことが起きます。出てきた判定は、引用された箇所を見て、最後は自分で確かめてください。

6. 他人のAIに、自分のやり方を預ける前に

AimanaVoのSkillは、書き手のやり方を、読者のAIに預ける仕組みです。預けた先で何が起きるかを、書き手は見られません。記事が読まれるときより、ずっと手を離れたところで使われます。

だからこそ、公開の前に一度だけ、自分で壊してみる価値があると思っています。原文で1回、わざと壊して1回。それで見つかる穴は、たぶん読者からの質問より先に見つかります。

今日から始める小さな一歩 あなたのSKILL.md（または記事の手順の部分）から、「適切に」「必要に応じて」「重要な」という言葉を探してください。見つかったら1つだけ、数や条件に置き換えます。「重要な問題」なら「読者が誤った情報を持ち帰る問題」のように。それだけで、AIの判断は少し揺れにくくなります。

今回のテストを実際に通したSkillは、2本の有料記事に付けています。テストの題材と結果、揺れの中身も、それぞれの記事に書きました。

AIが書いた記事を公開してよいか判定する手順と、そのSkill：
→ AIが書いたSEO記事、公開して大丈夫？

クライアントの指示書と原稿を照らし合わせて、修正が来そうな場所を納品前に見つける手順と、そのSkill：
→ 修正依頼の往復を減らす、指示書と原稿の照合術

付録：コピーして使えるSkill公開前チェック

AIに使わせても、自分で手で確かめても使えるように、手順を1枚にまとめました。

■ 手順書の点検（該当箇所を引用。なければ「記載なし」）
1 入力：何を渡すか／足りないときどうするか
2 手順：順番があるか／1つの手順に作業が混ざっていないか
3 判断基準：「適切に」「必要に応じて」「重要な」を、数や条件に置き換えたか
4 上限：出す件数の上限と、超えたときの扱い
5 迷いやすい分類：2つの区分のどちらにも入る指摘の置き場所
6 作り話の防止：体験・数字・事例・出典が足りないとき、〔　〕で止めるか
7 人間に回すもの：リンク先・表示・事実の一次確認を、人間の確認として出すか
8 出力形式：見出しと表の形／最後に「結果は実行ごとに揺れる」と添えるか

■ テストA（原文テスト）
題材：実際の原稿をそのまま
見るところ：手順どおりか／作り話をしないか／全文を書き直さないか

■ テストB（欠陥注入テスト）
同じ題材に欠陥を3〜5個入れる
欠陥｜入れる場所｜合格の条件
　　｜　　　　　｜
例：出典のない数字／効果の保証／制作メモ／ローカルのファイルパス／別の箇所からのコピー

■ 実行条件
・AとBは同じモデル
・ファイル操作や検索を使えない状態
・自分の環境の設定が出力に混ざったら、手順書の問題と分けて記録

■ 結果の判定
検出：見つけた／区分違い／見逃し
作り話：補っていないか
やりすぎ：頼んでいない書き直しや、問題のない箇所への指摘がないか
揺れ：AとBで、同じ問題の区分や点数が変わっていないか
形式：出力形式と最後の注意書きを守ったか

■ 揺れが出たら
置き場所の基準を1〜2行で足す。揺れはゼロにはならないので、注意書きも残す