プログラミングの知識がゼロの人でも、自分の業務を自動化できてしまう。そう聞いて「じゃあエンジニアの自動化スキルに、いくらの値段がつくんだ」と不安になったことはないだろうか。
デジタルバンク「みんなの銀行」で、プログラミング未経験の銀行員が生成AIなどのテクノロジーを活用し、7時間かかっていた大量のコピペ業務をわずか5分に短縮した事例が話題になっている。2021年にサービスを開始したスマートフォン完結型のデジタルバンクで、口座数の増加に伴ってバックオフィスの作業量が膨れ上がり、現場の非エンジニアがテクノロジーの力で解決したという内容だ。
自分は副業でAIを活用した自動化の仕組みを複数運用している。こうした事例が出てくるたびに確信するのは、「自動化できます」だけを看板にしていたら、エンジニアの収益は先細るということ。稼ぎどころは「作る力」ではなく「動かし続ける設計力」に完全にシフトしている。
「作れる」の価値が急落している
ほんの数年前まで、業務自動化はエンジニアの専売特許だった。Excelのマクロを書けるだけで部署のヒーロー扱いされていた時代がある。
ところが今、状況はガラッと変わった。ChatGPTに「この作業を毎朝自動でやりたい」と相談すれば、ノーコードツール（プログラミング不要で自動化を組めるサービス）の選定から具体的な設定手順まで、手取り足取り教えてくれる。Google Apps Script（Googleのサービスを自動化できる無料のプログラミング環境）を使えば、スプレッドシートのデータ転記くらいならAIが出力したコードをそのまま貼り付けるだけで動く。Microsoft Power Automate（Microsoft 365に含まれる自動化ツール）を使えば、メールの振り分けやファイルの自動整理がドラッグ&ドロップで組める。
プログラミングを「学ぶ」必要すらなくなりつつある。AIに「やりたいこと」を伝えれば、「やり方」が返ってくる時代だ。みんなの銀行の事例は、この流れが金融業界という規制の厳しい現場にまで到達したことを示している。銀行の裏側というと、お札を数える姿やパソコンで難しい計算をしている光景を想像するかもしれない。でも実態は「大量のコピペ」だった。そして、その退屈な作業を潰せるツールが、今やエンジニアの手を借りなくても手に入る。
フリーランスや副業で「業務自動化を請け負います」と営業しても、クライアント側が「それ、うちの社員がChatGPTに聞いてやったほうが速くない？」と気づき始めている。「作れること」自体の市場価格は、確実に下落トレンドに入っている。
非エンジニアの自動化が「止まる」3つのパターン
とはいえ、非エンジニアが作った自動化がずっと問題なく動き続けるかというと、そうはいかない。動いている間は完璧に見える。でも、だいたい次の3つのパターンで止まる。
パターン1：外部サービスの仕様変更
連携先のAPI（外部サービスとデータをやり取りする窓口）が、ある日いきなり仕様を変えることがある。昨日まで動いていた処理が、今日は「認証エラー」で止まっている。非エンジニアにとっては「昨日と同じことをしているのに動かない」という状態で、原因の切り分けすらできないことが多い。
エラーメッセージを読んで、変更された仕様を調べて、コードを修正する。この一連の流れは、システムの構造を理解していないと手が出せない。AIに聞いても「どのバージョンのAPIを使っていますか？」と返されて、そこで詰む。
パターン2：データ量の増加で処理が詰まる
最初は100件のデータを処理する想定で作った仕組みが、半年後に1万件になって処理時間が爆発する。タイムアウト（処理時間の上限超え）で途中停止したり、メモリ不足でクラッシュしたりする。
これが厄介なのは、「成功すればするほど壊れる」構造になっている点だ。事業が成長してデータが増えるのはいいことなのに、それが原因で仕組みが倒れる。データが増える前提で設計していないと、導入当初のメリットがそのまま負債に化ける。
パターン3：属人化で誰も直せなくなる
これが一番根深い。「あの人が作った謎の自動化」が社内に残り、作った本人が異動や退職した瞬間に誰も中身を理解できなくなる。
修正できない自動化は、もはや自動化ではなく「いつ止まるかわからない時限爆弾」だ。止まった時の対応は結局、外部のエンジニアに依頼するか、ゼロから作り直すかの二択になる。この「作り直し」の費用は、最初からエンジニアに設計を依頼するよりも高くつくことがほとんどだ。
この3パターンのどれかが起きた時、非エンジニアには対処の選択肢がほとんどない。ここがエンジニアの出番になる。
エンジニアが売るべきは「壊れた後の設計」
つまり、エンジニアが提供できる本当の価値は、「動く仕組み」ではなく「壊れても復旧できる設計」だ。
具体的に何が含まれるか、整理するとこうなる。
- エラーが起きたら通知が飛ぶ仕組み（異常を人間が即座に検知できる）
- ログ（動作記録）を残して、何がいつ壊れたか追跡できる構造
- 処理が途中で止まっても、続きから再開できるリトライの設計
- 担当者が変わっても修正箇所がわかるドキュメントと命名規則
地味だ。派手さはゼロ。でも、この地味な設計にお金を払う企業は確実にいる。なぜなら、自動化が止まった時の損害は、自動化を導入した時の効果と同じかそれ以上だからだ。
7時間を5分にした仕組みが壊れたら、また7時間に戻る。その時に「すぐ直せる人がいるかどうか」で、業務の継続性が変わる。この「直せる」を最初から設計に組み込むのが、エンジニアの仕事だ。
自動化は「動かし続ける」ほうが10倍難しい
自分の運用経験から言い切れるが、自動化を「作る」のは全体の労力の2割程度でしかない。残りの8割は、動かし続けるための修正と改善に費やされる。
たとえば、ブログ（WordPress）用のサムネイル画像を自動生成する仕組みを組んだ時の話。最初は快調に動いていた。設定して、テストして、動作確認して……よし完璧。と思った数日後に、突然タイムアウトで止まった。
原因を調べたら、生成する画像の複雑さが上がって処理時間が伸びていた。上限時間を段階的に引き上げて対応したが、今度は別の問題が発生した。タイムアウトで処理が打ち切られた直後に、裏側で処理が完了してしまい、同じ画像が2枚生成される事故が起きたのだ。片方を消せばいいだけの話だが、「どちらが正しい画像なのか」を判別する仕組みがなかったので、そこから設計のやり直しになった。
試した。動いた。速い。もう戻れない——と思った3日後に壊れた。
さらに、SNS（X）への投稿を自動化した時にも似たことが起きた。複数の投稿内容をまとめて処理する設計にしていたら、全体の処理時間がサービスの制限を超えて途中で停止する。1本ずつ順番に処理するように変更して解決したが、今度は処理順序の制御やエラー時のリカバリー設計が必要になった。投稿のタイミングが他の機能と被らないよう、時間帯の調整も加えた。
このモグラ叩きは、自動化を運用している限り終わらない。地味な修正が、確実に効く。でもこの「地味な修正を延々と続けられるスキル」は、プログラミング未経験者にはハードルが高い。「動いてるから大丈夫」と思って放置した3ヶ月後に盛大に壊れる、というのが非エンジニア自動化あるあるだ。
自動化案件で単価を上げる3つの視点
では、具体的にどうすれば自動化の仕事で収益につなげられるか。自分が運用を通じて実感している視点を3つ挙げる。
1. 保守込みの提案に切り替える
初期構築だけを請け負うと、単価は下がり続ける。ノーコードツールやAIアシスタントが「作る」部分の相場を押し下げているからだ。
逆に、月額で保守と改善を含めたパッケージにすると、ストック型（継続的に入る）の収益になる。「壊れたら即日対応」「月1回の動作チェックと改善提案」というサポート契約は、初期構築費より長期の総額で大きくなることが多い。クライアントにとっても、止まるリスクを月額で保険にできるのは合理的な選択だ。
2. 「壊れパターン」の引き出しを増やす
クライアントに「こういう自動化をやりたい」と言われた時、「それ、このパターンで3ヶ月後に壊れる可能性がありますよ」と具体的に指摘できると信頼度が跳ね上がる。
この引き出しは、実際に運用して痛い目を見た人にしか持てない。自分も画像の二重生成事故やタイムアウトの連鎖を踏んで初めて、「ここは最初から対策を入れておくべきだった」と言えるようになった。失敗のログは、提案の説得力に直結する資産だ。
3. 「自動化しない」を判断する
すべてを自動化しようとすると、例外処理やエラー対応の設計が複雑になりすぎて、維持コストが導入メリットを食い潰す。
「この部分は手動のほうがコストが安い」「ここだけ自動化すれば作業時間の80%を削減できる」という線引きができるのは、全体のシステム構造を理解しているエンジニアだけだ。「何を自動化しないか」の判断を売る。これが地味に高単価の仕事になる。クライアントは「全部自動化したい」と言いがちだが、「全部やると維持費がこうなりますよ」と見せた上で「ここだけやりましょう」と提案できるのは、実装と運用の両方を知っている人間だけだ。
まとめ
- プログラミング未経験者でも基本的な自動化ができる時代。「自動化できます」だけでは差別化できない
- エンジニアの売りどころは「壊れた後の設計」と「動かし続ける運用力」に移っている
- 保守込みの提案、壊れパターンの知見、「自動化しない判断」の3つが単価を上げるポイント
7時間が5分になる。そのインパクトは確かにすごい。でも本当にお金になるのは、その5分の仕組みを来月も来年も5分のまま動かし続ける設計力のほうだ。これ、半年前に気づいてたらと思うよ。すごく。
参考
【PR】フリーランスエンジニアにおすすめのツール
海外サービスとの連携やリモートワークに。VPNは地味だけど必須の投資。
通信費を見直すだけで月の固定費が変わる。フリーランスこそ通信環境は整えておきたい。
副業用のドメイン取得に。ポートフォリオや自動化ツールの公開用に1つ持っておくと便利。
AIを活用した運用のリアルな裏側を発信しています。
【PR】おすすめの書籍
記事の内容に関連する書籍を紹介させてほしい。
できるPower Automate Desktop ノーコードで実現するはじめてのRPA (できるシリーズ)
プログラミング不要で業務自動化を始められるPower Automate Desktopの入門書です。ノーコードでRPAに取り組みたい方に向けた一冊です。
Pythonを使った業務自動化の手法を体系的にまとめたハンドブックです。コードによる自動化をさらに深めたい方に適しています。
コメント