Claude Codeで自分専用ツールを内製する｜作る仕事の選び方と、直し続けるコストの実測【2026年版】
目次
「欲しかったツールが、自分の手で作れる」——Claude Codeを営業・マーケの現場で使い始めた人が、最初に驚くのはここです。エクセルのマクロも書けなかった人が、その日の午後に自分専用の集計ツールを動かしている。実際に起きます。
問題はその先です。1か月後、そのツールがまだ動いているかどうか。そして止まったときに、自分以外の誰かが気づけるか。
当社は営業・マーケの定型業務を自作の処理で回しており、定時で動くものだけで45本あります。この記事は、その運用の記録から「どの仕事をツールにしてよいか」と「作った後に何が起きるか」をまとめたものです。作り方のチュートリアルではありません。作る前の判断と、作った後のコストの話です。
この記事の要点
- 内製できるのは「自分の手順を、他人に口で説明できる仕事」だけ。説明できない仕事は、AIの性能ではなく手順の不在で失敗する
- 作る前に決めるのは4つ。何がきっかけで動くか／成果物がどこに届くか／壊れたとき誰が直すか／どうなったらやめるか
- 当社の実測では、27日間の改善記録284件のうち83件（29%）が新機能ではなく「壊れたものの修復」だった。内製の本体コストは作る時間ではなく直し続ける時間にある
- 壊れ方は4つに収束する。もっとも重いのはエラーを出さずに「0件」で正常終了する故障。気づくまでに日数がかかる
- 社内に広げる前に必要な設計は1つだけ。落ちたことを、そのツール自身ではない別の処理が検品すること
内製できるのは「口で説明できる仕事」だけ
判定はここから始めます。その作業を、今日入った人に口で説明して、同じ成果物が返ってくるか。返ってくるならツールにできます。返ってこないなら、まだツールにする段階ではありません。
Claude Codeは日本語の指示でファイルを読み書きし、実務をこなします。つまり渡せるのは「手順が存在する仕事」です。逆に、手順ではなく判断そのものが仕事の中身になっているものは渡せません。この線引きを先にやらないと、「AIが思ったように動かない」という感想だけが残ります。
| 内製に向く仕事 | 向かない仕事 |
|---|---|
| 入力の置き場所が毎回同じ（同じフォルダ・同じ画面） | 入力を毎回人が探してくる |
| 出力の形が決まっている（表・一覧・定型文） | 出力の良し悪しがその場の空気で決まる |
| 毎日〜毎週発生する | 月1回・年数回しか発生しない |
| 間違っていても、社内で気づいて直せる | 間違いがそのまま社外に出る |
| 例外が2〜3通りに収まる | 例外のほうが本流より多い |
右側の仕事に手を出さないことが、内製を続けるうえで一番効きます。特に月1回しか発生しない作業をツールにするのは、ほぼ確実に損です。次に動かすのは1か月後で、そのときには前提がずれていて動きません。動かない理由を調べる時間のほうが、手でやる時間より長くなります。
作る前に決める4つ
作り始める前に、この4つを紙に書きます。書けないうちは作らないほうが早いです。
- 何がきっかけで動くか（トリガー）。 人が「実行」を押すのか、時刻が来たら動くのか、ファイルが置かれたら動くのか。ここが決まっていないツールは、結局「使うのを忘れる」で消えます
- 成果物がどこに届くか。 自分のPCの中で完成しても、仕事は進みません。誰が次に受け取るのかまで決めます
- 壊れたとき誰が直すか。 作った本人しか直せないツールは、その人が休んだ日に業務ごと止まります。ここを曖昧にしたまま社内に広げると、属人化がツールの形に移動しただけになります
- どうなったらやめるか。 「週3回以上使わなくなったら捨てる」のような条件を先に決めます。使われていないツールを抱えたままにすると、直す対象が増え続けます
2026年の実務で描くべき姿は、チャットにプロンプトを1つずつ投げる形ではありません。トリガーで動いて、成果物が届いて、人はそれをレビューして本番に挑むだけという形です。時刻で動かす場合の設計はClaude Codeのスケジュール実行に分けて書いています。
自社の実測：19の定型業務で合計14時間55分→54分
当社が自分たちの営業・マーケ業務でとった実測です。定型19業務の合計で、14時間55分が54分になりました（2026年9月時点）。
| 業務 | 前 | 後 |
|---|---|---|
| 商談準備一式 | 30分 | 3分 |
| トークスクリプト作成 | 30分 | 5分 |
| 提案資料の作成 | 30分 | 5分 |
| 商談後の議事録 | 20分 | 1分 |
| フォローメールの作成 | 30分 | 1分 |
| CRMへの入力 | 20分 | 1分 |
| 稟議用サマリーの作成 | 30分 | 1分 |
| 競合・反社チェック | 10分 | 1分 |
この数字は「作業時間が減った」という話であって、受注が増えたという話ではありません。ここを混ぜて説明した瞬間、報告は検証できなくなります。
だから内製をやるなら、浮いた時間の行き先を先に決めておく必要があります。当社の場合は、商談前の仮説づくりと、返信までの時間に寄せています。お客様側から見た変化は「速くなった」ことではなく、問い合わせへの返信が当日中に返ってくること、商談で自社の事業の話から始まることです。時間を浮かせる工程と使い道を決める工程は別に設計する必要があり、片方だけやると何も起きません（AIで時間は浮いたのに数字が動かない）。
作る時間より「直す時間」のほうが長い
ここが、内製を検討している人にいちばん伝えたい実測です。
当社は自作の処理に対する改善・修復をすべて1本の台帳に起票しています。2026年8月25日〜9月20日の27日間で284件。内訳を種別で見ると、次のようになります。
| 種別 | 件数 | 割合 |
|---|---|---|
| 壊れたものの修復 | 83件 | 29.2% |
| 新しい試み・改善 | 85件 | 29.9% |
| ルール・運用の修正 | 23件 | 8.1% |
| 調査・原因切り分け | 22件 | 7.7% |
| その他（内容の追加・状態整理など） | 71件 | 25.0% |
3割が「直す」です。さらに83件のうち22件は、定時処理が落ちたことを機械が自動で起票したもの＝人が気づく前に落ちていたものでした。9月単月では260件中73件（28.1%）が修復で、比率は月をまたいでもほぼ動いていません。
つまり内製のコストは「作るのに何時間かかるか」ではなく、動き続けさせるのに毎月どれだけ手が入るかです。ツールを1本増やすことは、直す対象を1本増やすことと同じです。作れる本数と、抱えられる本数は別の数字になります。
壊れ方は4つに収束する
83件を読み返すと、原因はほぼ4つに分かれます。作る前にこの4つを知っているだけで、設計が変わります。
| 壊れ方 | 実例（当社） | 対策 |
|---|---|---|
| ① 外部の認可が切れる・消える | 連携アプリを整理していたら、画面に出ていた確認対象と実際に消えた対象が食い違い、別の処理の認可を消していた（2026-09-19）。その処理は現在403を返し、再認可が必要な状態になっている | 認可が要るものを一覧にして、生きているかを定期的に確認する |
| ② OSや環境の権限が外れる | 画面操作を伴う処理の自動化許可が、実行ファイル単位で外れて全部止まった（2026-09-16・09-18）。手元で動かすと通るのに、自動起動だと通らない | 権限が外れたら代替経路に落ちる作りにする。復旧を人の作業として切り出す |
| ③ 同時に動いて上書きする | 複数の処理が同じ台帳ファイルを同時に書き、後から保存した処理が先の更新を丸ごと消した（2026-09-14に修正） | 共有ファイルは読み書きを1本の窓口に通す。追記ではなく上書きする処理を放置しない |
| ④ エラーを出さずに「0件」で終わる | 外部の集計APIへの指定を1文字間違えていて、結果が全ページ0件で返っていた（2026-09-17）。処理は成功扱いで、数字は「0」として台帳に載り続けた | 「0件」は成功ではなく異常として扱う。想定下限を割ったら止める |
このうち、いちばん重いのは④です。①〜③は止まるので気づきます。④は止まりません。正常に終了し、間違った数字が毎日届きます。当社はこれで、ページ別の実測を判断材料にできていない期間を作りました。
回線が切れた・PCがスリープしたといった環境要因も合わせると、「手元では動くのに、自動だと落ちる」が内製の日常です。危険な操作を機械で止める設計はClaude Codeは危険かに分けて書いています。
「AIが自分で直してくれるのでは？」
ここはよく聞かれます。そして、半分は本当です。原因が1つのファイルの中にあるものなら、AIは自分で見つけて直せます。当社の修復83件のうち大半は、人が「直して」と言う前に原因の切り分けまで終わっていました。
直せないのは、AIの外側が変わったときです。外部サービスの仕様変更、認可の失効、OSの権限、他の処理との競合。これらはコードを読んでも分かりません。誰かが「そもそも動いていないぞ」と気づいて、外側を直す必要があります。
だから内製で本当に足りないのは、作る力ではなく「止まっていることに気づく仕組み」です。
当社の不利も書いておきます。この45本が毎日動いている一方で、問い合わせは5週連続で0件の期間がありました（2026-09-17時点の自社集計。検索表示は同じ週に678まで伸びています）。自動化は作業量を減らしますが、それ自体が引き合いを作るわけではありません。作業が減ったことと商談が増えたことは別に管理する必要があります。当社はこの2つを混同していて、引き合いが増えていないことに長く気づけていませんでした。
社内に広げる前に決める1つ
自分専用ツールを、チームで使うものに変える段でやることは1つだけです。落ちたことを、そのツール自身ではない別の処理が検品する。
理由は単純で、落ちたツールは「落ちました」と言えないからです。当社は、毎日更新されるはずのページが前日の日付のまま止まっていたのを、別の確認処理が拾って初めて気づいたことがあります（2026-09-17）。手順書に「毎朝確認する」と書いておく方法は、当社では機能しませんでした。人もAIも、確認したつもりになれるからです。
検品側に求める条件は3つです。①本体とは別の時刻に動く ②本体が書いた結果を見て、想定の下限を割っていたら異常として扱う ③異常のときだけ人に届く。毎日「正常です」と届く通知は、2週間で読まれなくなります。
やめる判断も同じ台帳で持ちます。当社は修復の起票のうち6件を「直さない＝この処理は捨てる」として落としました。直さない判断ができる状態が、内製が回っている状態です。
よくある質問
Q. プログラミングの知識がまったくなくても内製できますか？
作ることはできます。当社の運用も、コードを書けない前提で組んだところから始まっています。ただし「自分の業務手順を言葉にできること」は必要です。ここが曖昧なままだと、出てきた成果物の良し悪しを判断できず、直す指示も出せません。プログラミングより先に、手順の棚卸しをしてください。
Q. 何本くらいから作り始めるのが現実的ですか？
1本です。毎日発生していて、成果物の形が決まっている業務を1本選んでください。当社が支援する場合も月に3つずつというペースで進めます。同時に5本作ると、5本まとめて壊れて、どれから直すか分からなくなります。
Q. 作ったツールの保守は、どれくらい時間を取られますか？
当社の実測では、27日間で修復の起票が83件（1日あたり約3件）でした。ただしこれは45本を動かしている規模の数字です。動かす本数に比例して増えると考えてください。1〜3本の規模なら、週に数十分〜1時間程度を保守の枠として空けておけば回ります。逆に言えば、その枠を取れない状態で本数を増やすべきではありません。
Q. 内製と、外部に作ってもらうのはどちらが得ですか？
作るところだけを比べると内製が安いです。判断が分かれるのは直し続ける部分です。外側が変わったときに原因を切り分けられる人が社内にいるかどうかで決めてください。いない場合、内製は「動いていたはずのものが静かに止まる」状態に着地しがちです。当社は伴走型でここを引き受けており、費用感と形態の違いはClaude Code導入支援の費用相場に整理しています。
Q. 作ったツールが社内で使われません。どうすればよいですか？
たいてい、トリガーが「人が思い出して実行する」になっています。時刻やファイルの到着で勝手に動き、成果物が向こうから届く形に変えてください。人の記憶を前提にした自動化は、2週間で使われなくなります。この摩擦そのものについてはAIが社内に浸透しない3つの理由に書きました。
---
執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）
自社の営業・マーケ業務を自作の定時処理45本で運用しており、本記事の件数・失敗事例はすべて自社の改善台帳（2026-08-25〜09-20）に基づいています。