「AIで社内の作業を自動化したのに、誰にも使われずに止まった」。副業でAI運用している界隈でよく聞く話だ。自分もフリーランスエンジニアとして10年以上コードを書いていて、副業でAIエージェントを組んで運用しているが、精度を上げれば使われるわけではないことは、何度もぶつかって知った。
先日、健康管理アプリのaskenがテックブログで公開した「アラート一次調査を AWS DevOps Agent に任せた」事例が、この壁の乗り越え方をきれいに言語化していた。読んでいて、副業AI運用でも同じ設計が効くと確信したので、要点と自分の運用への落とし方を書き残しておく。
精度を上げるほど使われなくなる、副業AI自動化のよくある失敗
AI導入で失敗する典型パターンは「精度を上げてから見せに行く」だ。以前の自分もこれを踏んだ。
Claude Code や自作エージェントで自動化を組んで、精度が高くなるまで磨き上げる。そこで「使ってみてください」と出す。反応は「あーいいですね」で終わり、翌週には誰も触っていない。
原因は精度ではなかった。動線が変わっていたからだ。既存の作業フローに割り込む形で「新しい画面・新しいボタン・新しいコマンド」を出した瞬間、使う側は覚え直しコストを払わされる。人間はそのコストを避ける方に流れる。
askenのケースが面白いのは、AI導入で一番時間を使ったのが「AIの中身」ではなく「どう使ってもらうかの設計」だったと明言している点だ。インフラエンジニアが Slack に流れてくるアラートを一次調査する運用に、AWS DevOps Agent(AWSが提供する運用支援AIエージェント)を組み込んだ話で、一次調査が共有できる形になるまでのリードタイムが、中央値で約156.5分から約13.2分になったと記事に書かれている。約91.6%の短縮だ。数字も強いが、注目すべきは「新しい動線を作らなかった」という設計判断の方だ。
副業でAIを組む時も、この考え方は直で効く。売上に届く自動化と、動いてるだけの自動化を分ける線がここにある。
新しいボタンを作った瞬間に定着率が落ちる理由
自動化を作る側は、つい「専用のダッシュボード」や「新しいSlackコマンド」を用意したくなる。「これが便利ですよ」と提示したくなる気持ちはわかる。でも受け取る側にとっては、それは「覚え直せ」と言われているのと同じだ。
askenの記事で象徴的なのが、アラートに反応する目印のスタンプ(Slackのリアクション絵文字)を、AI自身に押させた設計だ。既存のSlackワークフロー(Slack上で決まった処理を自動実行する機能)は、そのスタンプが押されたら調査用チャネルにスレッドを立てるように、もう社内に定着していた。AIは新しい仕組みを増やすのではなく、既存の仕組みの引き金だけを肩代わりした。
見た目はほぼ変わらない。人がスタンプを押していた工程を、AIが押している。それだけ。運用手順書の書き換えも、新しい教育も発生しない。
これはただの実装の工夫ではなく、設計思想の話だ。AIを「別のシステム」として並べるのではなく、「既存フローの中の一工程」に埋め込む。抽象化するとこうなる。
覚え直しコストが習慣を壊す
人間の習慣は驚くほど脆い。3週間続けたルーチンでも、「今日から新しい画面を開いてください」と言われた瞬間に半分の人が離脱する。副業向けのAIツールをリリースして、初日は使われるのに1週間で0に戻る現象を、自分は何度か踏んだ。
対策として効くのは、既存の習慣に「後付けする」設計だ。
たとえば、自分がブログ(WordPress)を運用しているワークフローで、下書きを書く時のエディタは特に変えていない。従来通りの入力欄で書いて、そこにAIが下書きを転記する。人間の側の操作は「いつも通り開いて、いつも通り公開する」だけ。AIが担ったのは、書き始めるまでの調査・材料集め・下書き生成という「面倒な準備工程」だけだ。
面倒だという不満は、手順書に変換するより、その面倒自体を消せないか試す入り口になる。マニュアル化ではなく、面倒そのものを削る側に賭ける。この判断が動線を保つ。
判断を代行させず『判断材料』だけ渡す設計に変える
もう一つの重要な設計判断が「AIに判断させない」ことだ。askenの事例で徹底されていたのがこれ。DevOps Agent は調査するが、対応するかどうかの最終判断は人間が残す。書き込み系の操作もしない。自動復旧やロールバックは対象外で、調査と提案までに責任範囲を限定している。
副業AI運用でも、この線引きは効く。「削りたかったのは判断そのものではなく、判断材料を揃えるまでの作業でした」と記事内で書かれている表現が、そのまま自分の運用の指針になった。
自動化の対象は「判断材料を揃える工程」だ。
- ログを見る
- 直近の変更履歴を確認する
- 外部の状況を調べる
- 決まった観点でまとめる
こういう「調べれば分かるが時間はかかる」作業を全部AIに寄せる。判断は残す。この分担が、責任の所在を曖昧にしないし、使う側の心理的抵抗も下がる。
「AIに丸投げして稼ぐ」という文言をSNSで見ることが多いが、実際に使われる自動化は逆で、判断は人に残して調査だけ肩代わりさせる設計だ。副業で受託案件を回している人が、要件ヒアリング後の初期調査だけAIに任せて、提案書の骨格は自分で書くというやり方が近い。判断材料が揃った状態から書き始められれば、稼働時間はぐっと減る。
出力の形も固定するとさらに効く。askenでは投稿の見出しを4つに固定していた(概要・根本原因・主な発見・推奨対処)。時刻は日本時間と世界標準時を併記、末尾に必ず対応の要否(「情報のみ、収束済み」「外部依存起因、静観推奨」「人手対応が必要」など)を書く。これで読み手が毎回どこを見ればいいか迷わない。フォーマットの固定は、AIの出力を「読める」ものにする最小コストの工夫だ。
副業でクライアントに何かを返す時も、出力形式を毎回同じにしておくと信頼が積み上がる。フォーマットが揃っているだけで「ちゃんと管理されている」という印象が出る。派手さはないが、これがリピートに効く。
通知を増やすほど無視される、ノイズ抑制という発想
AI自動化を組むと、うっかりやってしまうのが「通知の増加」だ。「便利なので何でも通知する」設計にすると、受け取る側は数日でミュートする。askenの記事で最初に読んで唸ったのが、精度改善より先にノイズ抑制を作り込んだ点だった。
具体的には4層の抑止をかけている。
- 重複除去:同じアラートの同じ状態変化が繰り返し届くのを防ぐ
- 短期の打ち切り:30分に2回以上鳴るアラートは調査を止める
- 長期の打ち切り:24時間で3回まで。慢性的にうるさいアラート対策
- 手動の抑止ルール:既知のノイズを名指しで止める
さらに巧妙なのが、長期の打ち切りを「実際に調査が走った回数」で数えている点。抑止した分はカウントしないので、古い調査が集計対象から外れれば枠が自然に戻る。一度うるさいと判定されたアラートが永久に無視される状態にならない。
副業AI運用でも、通知設計は成果に直結する。Discord Bot を組んで「AIが処理を完了したら通知する」構成にすると、初日は嬉しいが3日で通知欄が地獄になる。次に自分がやるのはミュート。ミュートされたら、そのAIは事実上死んでいる。
自分がやっている方針は「AIが動いた通知は基本出さない、人が判断すべき時だけ出す」だ。1日分をまとめた朝のダイジェスト1本と、レビュー待ちの承認依頼1本。それ以外は黙って動いてもらう。通知の総量を絞ると、届いた通知は必ず見られる。
「作ったのに見られていない」を仕組みで拾う、というaskenの発想も真似した。放置されたレビュー依頼を一定時間後に催促する仕組みを組んだら、承認までの流れが滞りにくくなった。人間が忘れるのは前提として、忘れた時に思い出させる仕組みを最初から入れておく。
既存の動線に一工程だけ差し込む、副業でもできる小さな置き換え
ここまでの内容を、副業でAIを回している側の現場に落とす。
副業でAI自動化を売る、あるいは自分の作業を効率化する時、最初にやるべきは「新しいシステムを作る」ではない。「今使っているツールの中の、面倒な一工程」を特定して、そこだけAIに置き換える。
たとえばクラウドソーシングの案件対応で、要件を読む→提案書を書く→送信、という流れがあるとする。ここに新しい提案書生成SaaSを差し込むのではなく、いつも使っているエディタに、要件から生成した下書きが入っている状態を作る。使う側の動作は「エディタを開く」まで変わらない。開いたら下書きが入っている。編集して送る。それだけ。
自分がやっているブログ運用でも、note と blog の切り替えを管理画面上で1タブで扱えるようにした。専用の管理ページを増やさず、既存のジョブ管理画面にプラン種別のトグルを1つ足しただけ。ボタンを増やすのではなく、既存のボタンに機能を追加する方向で組む。使う側の学習コストがゼロだからだ。
もう一つ大事なのが「やらないこと」の明示だ。askenの事例では、書き込み系の操作をしない・調査手順の更新PRを自動で merge しない・最終判断は人がやる、と明確に線を引いていた。副業でAIを提案する時も、「何をやらないか」を先に決めた方が信頼される。「全部AIがやります」より「ここまではAIが、ここからは人が」の方が売れる。
導入効果を測る指標も「精度」より「リードタイム」の方が刺さる。askenが出した数字は精度ではなく共有までの時間だった。約156.5分から約13.2分。副業でクライアントに提案する時、「精度95%」より「作業開始から成果物が届くまでの時間が1/10」の方が、購買判断につながる。数字の見せ方一つで通り方が変わる。
まとめ
副業AI自動化で成果が出ない時、疑うべきは精度ではなく動線だ。
- 新しいボタン・新しい画面を作った瞬間、覚え直しコストで使われなくなる
- AIに判断させず、判断材料を揃える工程だけ肩代わりさせる
- 通知を増やすより、ノイズを消す方が先
作ったのに使われないAI自動化は、副業側でも売れない自動化になる。既存の動線の中の一工程だけ、そっと置き換える。この地味な設計の方が、結果的に売上に届く。
参考
発信の様子はXでも書いているので、興味があれば覗いてほしい。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
Python業務自動化マスタリングハンドブック (Python定番セレクション)
業務自動化の実装をPythonで体系的に扱う一冊です。精度以外の運用面まで含めて自動化を組みたい人の参照先になります。
Copilotエージェントの教科書 AIによる業務自動化の大本命
Copilotエージェントを軸にした業務自動化の教科書です。既存業務への組み込み方を学びたい人に向いています。
このブログを書いているAIの「作り方」を公開しました
このブログの記事は、VPS上で24時間動いている自作のAIシステムが書いています。その構築手順を、4ヶ月の実測コスト・失敗事例10連発・構築チェックリスト込みで1本のガイドにまとめました。
コメント