AI Workflow Insight
同じプロンプトを毎回打ち直すのをやめた。Claudeの「スキル」に自分の記事の型を覚えさせてみた
AIに書かせると量産感が出る。ずっとモデルの限界だと思っていたが、原因は自分の評価基準を毎回のチャットに手打ちしていなかっただけだった。Claudeの「スキル」機能に基準を一度預けたら、無料プランでも同じ判定が再現された。
先に結論：同じプロンプトや評価基準を毎回チャットに打ち直す手間は、Claudeの「スキル」機能に一度預ければ消える。SKILL.mdとして評価基準を明文化し、.skillにパッケージしておけば、新しいチャットでも同じ基準で判定してくれる。無料プランでも今日から試せる。
実際に何が起きていたのかを整理します。
「AIに書かせると当たり障りのない文章になるのは、モデルの限界だから仕方ない」
評価基準（深さ×熱量の採点軸）を毎回のチャットに手打ちで説明し直していただけ。基準をSKILL.mdとして固定して渡すと、新しいチャットでも同じ判定を再現できた。
なぜ「その場のプロンプト」ではダメで、「スキル」だと再現するのか
チャットにどれだけ丁寧に評価基準を書いても、そのチャットが終われば情報は残らない。次の会話ではまた一から説明が要る。SKILL.mdは違い、ファイルとして保存されているため、関連する作業のときに毎回自動で読み込まれる。「その場の指示」から「常備してある判断基準」に変わる、という違いが大きい。
実例：今日、実際に「深さ×熱量ハイブリッド記事作成スキル」を作り、使い方ガイドと特典受け取りページもセットでサイトに公開した。さらに、スキルを作った自分のアカウントとは別の無料アカウントにこのスキルだけを追加し、渡したプロンプトは次の一文だけだった。
「“depth-heat-article”スキルを追加しました。これを使って素晴らしいものを作ってもらえますか？実際の体験記をまとめたものを添付します。」
添付したのは、n8nの監視ワークフローが21日間・1日48回のペースで「異常なし」と報告し続けていたのに、中身は3週間前のまま止まっていたという実際の障害対応記録。テーマも技術領域もこの記事とはまったく違うのに、返ってきたのは同じ評価基準・同じ構成（結論→実例→比較表→チェックリスト→クロージング）の記事だった。原因は並列ノードのonErrorが既定値のままだったこと、そして監視自体が「形式」しか見ておらず「鮮度」を見ていなかったこと——この二段構えの気づきが、たった一文のプロンプトから再現された。
以下、実際に生成された記事の全文です。要約でも抜粋でもなく、その無料アカウントに一文のプロンプトだけを渡して返ってきた出力をそのまま掲載します（改変なし）。
毎朝「異常なし」と届いていた監視が、21日間ずっと嘘をついていた
実際の業務システムで起きた障害の調査・修正記録です。ブログ公開のため、会社名・個人名・各種IDは伏せています。技術的な内容は実際に起きたとおりです。
「動いているか」ではなく「エラーが出ているか」しか見ていないなら、この記事は他人事ではない
n8nで定期実行のワークフローを組んだことがある人なら、一度は監視も入れているはずだ。「エラーが出たら気づける」——そう思っている人に、まず結論から共有したい。
エラーが一度も出ないまま、21日間・1日48回のペースで完全に沈黙し続けた自動化があった。そして毎朝走っていた点検ワークフローは、その21日間、一度も欠かさず「異常なし」と報告し続けていた。
エラーゼロ、点検グリーン、それでも中身は3週間前のまま固まっていた。この記事は、その原因と、なぜ気づけなかったのかの記録だ。
何が起きていたか
A社では、Discordのボイスチャンネル名を書き換えて相場を表示する仕組みを運用していた。サーバーのサイドバーがそのままモニターになる、という工夫だ。
🔊 【USD/JPY】 159.95 (⬈ +0.00%) 🔊 【日経平均】 67,743.85pt (⬈ +1.38%) 🔊 【NYダウ】 50,867 (⬊ -1.01%)きっかけは、同僚から「ドル円が動いていない」と指摘されたことだった。指摘がなければ、誰も気づいていなかった。
実際の相場と突き合わせると、乖離の幅が銘柄ごとにバラバラだった。日経平均は+9.5%、Goldは+5.7%ずれていたのに、S&P500はほぼ一致していた。おまけに6銘柄中4銘柄で騰落の符号が逆転していた。下がっていると表示されている銘柄が、実際は全部上がっていた。
ここで「データ取得先が銘柄ごとに古い」という仮説を立てた。方向としては正しかったが、本質はもっと単純なところにあった。
実行履歴を開いた瞬間に全部わかった
出力の中身を分析する前に、実行履歴を見るべきだった。開いてみると、こうなっていた。
実行 22669 15:30 error 0.17秒 実行 22666 15:00 error 0.20秒 実行 22664 14:30 error 0.26秒全部エラー。しかも0.2秒で終了。最後の成功実行は21日前。
Discordの数字が3週間前のもので固まっていたのは当然だった。乖離の幅がバラバラだったのも、その3週間で銘柄ごとに動いた量が違っただけの話だ。凝った仮説より先に「そもそも動いたか」を確認していれば、1クリックで済んでいた。
直接原因は、6銘柄を並列で取得する枝の1本(米株)が、無料の株価データサービスから404を返されるようになったことだった。そして致命的だったのが、n8nの
onErrorが既定値のstopWorkflowのままだったことだ。Schedule Trigger ─┬─ USD/JPY → 整形 → Discord更新 ├─ BTC/JPY → 整形 → Discord更新 ├─ 日経平均 → 整形 → Discord更新 ├─ 米株 → 整形 → Discord更新 ← ここで404 ├─ NYダウ → 整形 → Discord更新 └─ Gold → 整形 → Discord更新見た目には独立した6本の枝だが、n8nでは1本が
stopWorkflowでエラーになった瞬間、実行全体が止まる。他の5本は無関係なのに、一度も動かなかった。「0.2秒でerror」の正体はこれだった。並列に見える構成でも、1本のノードの設定次第で全体が道連れになる。自分のワークフローの各ノードの
onErrorが既定値のままかどうかは、今すぐ確認する価値がある。本当に怖かったのは、監視が「正常です」と言い続けていたこと
原因の特定より、なぜ発見が21日も遅れたのかのほうが重かった。特に決定的だったのが、A社に存在していた毎朝9時の点検ワークフローだ。Discordのチャンネル名を取得し、こういう判定をしていた。
const invalid = !channel || // チャンネルが取得できたか !name.startsWith(target.prefix) || // 【USD/JPY】で始まるか !/\d/.test(name) || // 数字を含むか /NaN|undefined|null|Infinity/i.test(name); // 壊れた値でないか見ているのは表示の「形式」だけだ。3週間前の数字は、この4つの条件を完璧に通過する。プレフィックスは正しく、数字も入っていて、NaNも混ざっていない。だから点検は毎朝 ✅ を返し続けた。
もう一つ、気づく機会を奪っていた事実がある。前回の修正作業を追うと、こんなタイムスタンプが残っていた。
07:13:29 最後の保存(日経平均の修正) 07:14:37 最後の成功実行 ← 手動テスト 07:14:37以降 すべてerror編集の1分後の手動テストは、実際に成功していた。修正した人は「直った」という正しい証拠を手にしていた。壊れ始めたのは、その後の定時実行からだった。手元では緑、その後赤——これが一番気づきにくいパターンだった。
さらに、このn8nは下書き(
versionId)と公開版(activeVersionId)が別管理になっていた。エディタで保存しても、それは下書きに入るだけで、スケジュール実行が使うのは公開版のままだ。今回の修正作業でも、保存の成功レスポンスを受け取ったのに、次の定時実行はまだ古いコードで落ちる、という同じ罠を一度踏んでいる。下書き(versionId) : 642d9388... ← 修正済み 公開版(activeVersionId) : 84c752ea... ← 古いまま。これが実行されている「保存できた」と「本番に反映された」は、別の事実だ。「公開」ボタンを押して初めて両者が一致する。
似た構造は、同時期に進んでいた別の自動化(Zoomの録画をGoogle Driveへ保存する仕組み)でも見つかった。共有ドライブのメンバーではなくフォルダ単位の権限しか持っていないアカウントで、ドライブ全体を横断する検索だけが
The attempted action requires shared drive membership.で弾かれ続けていた。原因は違うが、こちらにも失敗通知は設定されていなかった。「動いていないのに、誰にも伝わらない」という同じ穴が、別の場所にも空いていた。今すぐ確認すべき3つのこと
エラーゼロの監視は、動いていることの証明にはならない。次の3つは、今のワークフローに当てはめて確認できる。
- 並列ノードの
onErrorが既定値のままになっていないか。既定はstopWorkflowで、1本の失敗が全体を止める。取得失敗時はreturn []などで安全にスキップし、他の枝を止めない設計に変える。- 監視ワークフローに「鮮度」の判定が入っているか。形式が正しいかだけでなく、値が更新されているかを見る。今回は、6項目の表示内容を連結した文字列を前回点検と比較し、完全一致したら「更新停止の疑い」と判定する仕組みを追加した。相場が6銘柄すべて前回と同値になることは現実的にないため、これだけで凍結を検出できる。
- 失敗を伝える通知が、実際に届くかテスト済みか。n8nにはエラー時に別ワークフローを起動する
Error Workflowの機能があるが、設定されていなかった。設定していれば、この障害は初日の1回目で気づけていた。「正常です」という報告こそ、疑うべき対象になり得る
今回の点検ワークフローは、毎朝きちんと動き、毎朝きちんと成功し、21日間ずっと同じ嘘をついていた。プレフィックスは正しく、数字は入っていて、壊れた値も混ざっていない——確認していた項目は、すべて真実だった。ただ、その数字が3週間前のものだという一点だけを、誰も見ていなかった。
システムが黙って止まるなら、いつか誰かが気づく。しかし「正常です」と報告し続けるシステムは、気づく機会そのものを奪う。指摘してくれた同僚がいなければ、この状態はもっと長く続いていたはずだ。
自動化を増やすことは、見ていないものを増やすことでもある。今動いている監視が「エラーが出ていないか」しか見ていないなら、それは形式チェックであって、鮮度チェックではない。次に開くときは、その1点だけ確認してほしい。
本記録は実際の障害対応をもとにしています。会社名・個人名・プロジェクトID・各種リソースIDは公開にあたり伏せています。
この記事のテーマ(n8nの監視設計)は、今書いているこの記事の話題とは何の関係もない。それでも「結論→実例→比較表→チェックリスト→クロージング」の型は保たれ、「形式チェックと鮮度チェックは違う」という固有のInsightもそのまま立っている。評価基準を毎回説明し直していないのに、これが返ってきた。
うまくいった話ばかりではない。使い方ガイドのページを作る過程で、23,240文字の長いコードを一度に貼り付けたところ、一部が欠落・重複して13,780文字分しか反映されない事故が起きた。原因は、長すぎる文字列を一括で扱おうとしたこと。対策として、2,000文字ずつに分割し、貼り付けるたびに文字数を検証してから次に進む、という地味な手順に切り替えて解決した。「AIに任せれば速い」は本当だが、検証を挟まないと事故に気づけない、という教訓も込みで書いておきたい。
| 項目 | 従来 | スキル化後 |
|---|---|---|
| 評価基準の伝達 | 毎回チャットで手打ち説明 | SKILL.mdとして一度登録するだけ |
| 記事の質のばらつき | チャットごとにブレる | 二軸80点ゲートで一定基準を維持 |
| プランの制約 | 検証していなかった | 無料プランでも同じ基準で動作確認済み |
AI副業は何から始めればいいか、とよく聞かれる。ツールの選び方でも、プロンプトのテクニックでもない。実は一番土台になるのは、AIに何度も説明し直さなくても、ブログとして本当に価値のある記事を安定して書けるかどうかだ。上の記事は、その土台がある状態を言葉ではなく実物で示している。完璧な一本を最初から目指さなくていい。無料プランでもまず1回試して、効果を体感してから磨き込めばいい。今回使った判断基準とスキル一式は、読者特典としてご案内しています。
AIに任せれば、できることは増える。 けれど、正しく選べるとは限らない。
AI時代に必要なのは、AIに丸投げする力ではなく、AIが出した結果を判断できる最低限の基礎です。
活躍できる場所
AI活用と人間力が重なるほど、あなたにしか生み出せない価値の領域は広がっていきます。
AIトレンドロードマップを見る →※ 別タブで開きます。読み終えたらこの記事に戻れます。
この記事へのコメントはありません。