AI を「便利屋」から「相棒」へ – 月1業務の自動化で気づいた、AI に任せる場所の選び方

Claude Code や Codex などを利用して、タスクの自動化に取り組んでいる方も多いと思います。
私も毎月1回ある定型業務を AI で自動化を考えていました。

4つのツールを往復し、マネージャーへの確認も挟む、1時間ほどの繰り返し作業でした。
そのため『全部 AI に任せられるはず』と意気込んで、Claude Code のスキルにする形で自動化に取り組みました。
一通りのスキル化を終えて、やったことをメンバーに共有したとき、こんな一言をもらいました。

「やることが決まってるなら、スクリプトにしたほうが良さそうですね！」

ハッとしました。

「AI で自動化する」がゴールになっていて、「AI である必要があるか」を問えていなかったことに気づいたからです。

この記事は、その一言から自分なりに整理した「AI に任せる仕事 / スクリプトに任せる仕事」の判断軸を書いてみます。
同じように「これ AI に任せられるはず」と自動化に取り組まれている方の参考になれば幸いです。

何をスキルにしたのか？

弊社コーポレートサイトには「直近のスケジュール」というセクションがあり、3ヶ月先までのリソース空き状況を表示しています。
これを月に1回更新する作業をスキルにしました。

工程はこんな感じです。

1. GitHub で更新作業用の issue を作る
2. Slack でマネージャーに向こう3ヶ月のリソース状況を確認する
3. DatoCMS で「直近のスケジュール」の値を更新する
4. DatoCMS に新しいお知らせ記事を追加する
5. Slack で完了報告を投稿する

ツールは3つ、所要時間は1時間ほどです。
手順を覚えてしまえば大きな負担ではないのですが、決まりきった手順なので、人の手で実行する必要性は薄いと感じていました。

また、手順を完全に把握できていない場合は esa に書かれたドキュメントも確認する必要があり、4つのツールを切り替えながら実行することになります。

Claude Code を利用すれば、作業開始の指示を出すだけで対応が完了でき、詳細な手順を覚えていなくても誰でも作業できるようになると考えました。

振り返って見えた2つのコスト

メンバーの一言を受けて立ち止まり、自分が払っていたコストを振り返ってみると、2つありました。

暗黙知を全部言語化する作業が重かった

スキル作成には合計で3〜4時間かかりました。
特に自分が無意識にやっていた工程を全部文字に起こす作業に時間がかかりました。

例えば、DatoCMS でスケジュールを更新するスキル1つとっても

• DatoCMS のどこの何をどのように修正するのか
• 「前月の2ヶ月目を今月の1ヶ月目に、今月の3ヶ月目は未確定の ? にする」という表記のスライドロジック
  などを言語化する必要がありました。

AI に任せるとなった瞬間、「なんとなく」では伝わりません。
スキル化とは、自分の頭の中の暗黙知を、全部形式知に変換し、構造化する作業であることを改めて実感しました。
そして、その変換コストは想像していたよりずっと重いものでした。

月1回しか動かさないとスキルの調整が必要になる

もう1つは、月1実行ならではのコストです。

実行しようとした時、お知らせ追加のスキルが動かなくなっていました。
発生したのは下記のエラーです。

Failed to start dist/stdio.js: Error [ERR_PACKAGE_PATH_NOT_EXPORTED]

調べてみると、DatoCMS MCP が依存している @datocms/cma-client-node というパッケージの 5.2.0 以降で、exports フィールドが厳格化されていました。
MCP 側が古いパス参照のままになっていて、import がブロックされていました…。

「書いたら終わり」ではなくて、毎月「動かしてみるまでわからない」状態に晒されます。
これも、スキル化を始める前には見えていなかったコストでした。

どこに線を引くか

2つのコストを認識できた後、自分なりの線引きの基準を考えてみました。

最初は工程を「決まっているもの」と「決まっていないもの」を分けて、前者はスクリプト、後者はAIに渡せば、シンプルに整理できるはずでした。

しかし、実際に工程を並べてみると、「マネージャーへの確認」のように、半分は固定で半分は揺らぐ工程が出てきます。
固定部分だけ取り出してスクリプトにしてしまうと、揺らぎを拾うフックがなくなってしまいます。
何度か並べ替えた結果、たどり着いたのは下記の基準でした。

具体的に決まっている変更点はスクリプトに切り替える。
判断が必要な部分、変化可能性がある部分は、対話で AI に確認させる。

「AIでやれるか」ではなくて、「AIである必要があるか」を問う、ということです。

リソース更新フローを工程ごとに分解すると、こうなりました。

決定的な処理はスクリプトが安定します。
変化可能性がある部分は、毎回 AI に「変える必要ある？」と問わせることで、変化を取りこぼさない仕組みになると考えました。

AI を「相棒」として活用

線を引いたあと、AIに残した役割は3つありました。

変化を取りこぼさないように問いかけてもらう

「マネージャーへの確認窓口、今月も同じでいい？」を毎月 AI に問わせることができます。

問い合わせ先は基本固定なのですが、組織の役割が変わったときには変更が必要になります。
これをスクリプトで分岐ルールとして書こうとすると、ケースが爆発してしまいますし、誰かがコードを更新しないといけません。

AI に対話で確認させておけば、変化が起きた瞬間に拾えます。
変化に追従できる仕組みとしての AI の活用場面だと感じています。

詳しくない領域でのトラブルを一緒に解いてもらう

先述の ERR_PACKAGE_PATH_NOT_EXPORTED エラーが発生したとき、私は DatoCMS の依存関係には詳しくありませんでした。

Claude Code と対話しながら、エラーメッセージを読み解き、パッケージのバージョンを遡り、exports フィールドの仕様変更にたどり着いて、最終的に Docker イメージで依存を固定する解決策まで一緒に詰めていきました。

詳しくない領域でも、AI と協働すれば解決に至れる。
これも AI に任せたい仕事だなと思います。

正解が固定されていない判断を一緒に考えてもらう

完了報告の文面など、相手や状況によって調整したいものは、テンプレを流し込むより、対話で「この月はこんな感じでいいかな？」と相談できるほうがいいです。

「正解」が固定されていない作業こそ、AI の柔軟さが活きる場面だと感じました。

業務を工程レベルで分解してみる

「AI で自動化できる」と「AI で自動化すべき」は、別の問いだと思います。

• AI でやれるか → 多くのことができる時代になりました
• AI である必要があるか → 問うてみると、案外スクリプトでいい部分が多い

線を引いてみると、AI は「全部任せる便利屋」から「特定の場面で頼れる相棒」になりました。
むしろその方が、AI の価値を引き出せている実感があります。

メンバーの一言が、AI 自動化を見直すきっかけになりました。
けれど振り返ってみると、これは「AI 活用」そのものの話というより、自分の業務を工程レベルで分解して、それぞれに「どんな道具が一番落ち着くか」を選び直す話だったように思います。

決まった手順をそのまま AI に任せるのではなく、変化が起きる場所を見極めて、そこに AI を置く。
それが、自分にとっての「AI である必要があるか」の答えでした。

今、AI で自動化しようとしている業務をもう一度工程レベルで分解してみたら、どこに線が引けるか考えてみてください！

Gaji-Labo フロントエンドエンジニア向けご案内資料