Slack → 条件フィルタ → Claudeで要約 → Notion保存。
前回、日常を観察して自動化のネタを見つけた流れで、いよいよ実際にワークフローを組んでみました。
たった4ノード。
シンプル。
これなら動くでしょう、と。
まあ、動かなかったんですけど。
このシリーズでは自動化は自分で組み立てる時代という話から始まり、AI自動化ツールの比較を経てn8nにたどり着きました。
ここまでの4回で考え方やツール選定は固まった。
あとは作るだけ。そう思っていた自分に、3段階の失敗が待っていました。
今回は、その失敗の記録です。
美化はしません。
失敗①：そもそも動かない
最初の壁は、拍子抜けするほど地味でした。
Webhookの設定ミスです。
n8nのWebhookトリガーを「テストモード」のまま本番URLとして使い、Slackからのリクエストがそもそも届いていませんでした。
エディタ上ではグリーンのチェックが出ているのに、何も起きない。
ログを見てもイベント自体が来ていない。
30分ほど格闘して、URLが「test」と「production」で違うことにようやく気づきました。
正直、これには少し笑いました。
ワークフロー設計がどうとか以前の話です。
ただ、この種のエラーはググれば解決できます。
n8nの公式ドキュメントにもWebhookの注意点は書いてあります。
技術的な壁は、時間をかければ超えられます。
問題は、次でした。
失敗②：動いたけど「見返したくないデータベース」ができた
Webhookを直し、条件フィルタを設定し、Claudeに要約させ、Notionに保存する。
フロー全体がついに動きました。
技術的には、成功です。
ところが1週間後、Notionを開いて固まりました。
200件以上のエントリが並んでいて、その8割が要らない情報でした。
botの通知、リマインダーの繰り返し、チャンネル参加メッセージ。
全部「要約」されて、全部「保存」されている。
Claudeの要約も微妙でした。
Slackの短いメッセージを無理やり3行に膨らませたような文章が並んでいて、元のメッセージを読んだ方が早い。
フィルタ条件が甘すぎたのと、AI要約の粒度が用途に合っていなかったのが原因です。
技術的に動いている。
でも、実用的に壊れている。
このNotionデータベースを見るたびに、うっすら嫌な気持ちになりました。
「見返したくないデータベース」の完成です。
ワークフローが動くことと、ワークフローが役に立つことは、まったく別の話でした。
失敗③：「守るために生きてる」状態になった
見返したくないDBをなんとかしようと、ワークフローを改良し始めました。
自動タグ付け。
カテゴリ分類。
優先度判定。
重複チェック。
ノードが増えるたびに「これでマシになるはず」と思いました。
4ノードだったフローが、気づけば12ノードを超えていました。
そのうち、エラーが増えました。条件分岐のどこかで失敗して止まる。
直す。
別の場所が壊れる。
直す。
また止まる。
朝起きてまずn8nのログを確認する生活になっていました。
ある朝、ふと思ったんです。「これ、守るために生きてるな」と。
全部自動化しようとして疲れた話でまさに書いた状態に、自分がハマっていました。
自動化を維持するために自分の時間を使っている。
本末転倒の教科書みたいな状況です。
半自動に戻したら、急に快適になった
12ノードのワークフローを全部消しました。
新しく作ったのは、3ノードだけのフローです。
Slackで特定のリアクション（:bookmark:）を押したメッセージだけを、そのままNotionに転送する。
AI要約なし。
自動タグ付けなし。
条件フィルタもほぼなし。
「保存する価値があるか」は自分が判断する。
リアクションを押す、というたった1アクションだけ人間が担当します。
これが、びっくりするほど快適でした。
Notionに溜まるのは自分が「これは残したい」と思ったものだけ。
ノイズがない。
見返したくなるデータベースに変わりました。
完全自動の12ノードより、半自動の3ノードの方がずっと使えるものになったのです。
自分ルール：3ノード以内、AI抜き、1週間後に改良
この失敗から、最初のワークフローを作るときのルールを3つ決めました。
1. 3ノード以内で作る
最初から複雑なフローを組まない。
トリガー → 処理 → 出力。
この3ステップに収まる範囲で作ります。
足りなければ後で足せばいい。
最初に足しすぎると、どこが壊れたか分からなくなります。
2. AIを入れないバージョンで試す
Claude要約やGPT分類は便利ですが、最初のワークフローでは外します。
AIを入れると、AIの出力品質という別の変数が加わります。
まずはデータがちゃんと流れるかだけを確認します。
3. 1週間使ってから改良する
作った直後に改良しない。
1週間そのまま使って、「ここが不便だな」「ここは自動でいいな」が見えてから手を入れます。
仕組みで続ける方法でも書きましたが、使い続けることで見えてくるものがあります。
まとめ：失敗は、自分のワークフローの輪郭を教えてくれる
最初のワークフローは、成功させるために作るものではありません。
動かなくていい。
ノイズだらけでもいい。
複雑にしすぎてもいい。
その失敗が、自分は何を残したいのか、何がノイズなのか、どこを自動化すべきでないかを教えてくれます。
観測ドリブンで自動化を育てる考え方で書いた通り、失敗は観測データです。
壊れたワークフローの残骸から、自分だけのワークフローの輪郭が見えてきます。
だから、最初の1つは壊れる前提で作ってください。
3ノード以内で、AIなしで、1週間だけ。
それだけで十分です。
どなたかの参考になれば幸いです。
