Pythonが書けなくてもClaude Codeで最初の自動化を動かす手順

この記事で分かること：Claude Codeで最初の一本を動かすまで

結論から言うと、この記事を読み終えると、Claude Codeに渡す日本語の指示文をどう書けばよいか、動かしてみてエラーが出たときに何を貼ればよいか、そして自分の業務のどの工程から試せばよいかが分かる状態になります。

「PythonやClaude Codeが便利らしいとは聞くが、実際にどう指示を出せば動くものができるのか分からない」という状態のまま、手を動かせずにいる方を何人も見てきました。コードが書けないこと自体が問題なのではなく、何をどう伝えればよいかの型を知らないことが、最初の一歩を止めている場合がほとんどです。

私は白米元気という個人事業主として、gpirot.comという名前で業務自動化を受託しています。プログラミングを体系的に学んだことはなく、普段使っているスクリプトのほとんどは、Claude Codeに日本語で処理内容を伝えて作ったものです。この記事では、その具体的なやり取りの中身を、実際に出たエラーメッセージとともに書いていきます。

Pythonでしか拾えない処理はどこか

結論として、n8nのようなノーコードツールは単純な受け渡しや通知の処理に向いている一方、複数の条件を組み合わせて判断する処理になると画面上のフローチャートが複雑になりすぎて扱いにくくなり、その部分をPythonに任せる方が実務上うまくいきます。

自社で運用している案件のスコアリング処理が具体例です。クラウドソーシングなどで見つけた案件を10項目の軸で採点し、優先度を自動で振り分けています。「予算の規模」「納期までの日数」「過去の類似案件での成否」といった項目ごとに重みを変えながら合算する計算を、ノーコードのフローチャートで組もうとすると、条件分岐のノードが増えすぎて、どこでどう判定されているのかが画面から追えなくなります。実際に最初はn8nだけで組もうとして、分岐が増えた段階で画面がぐちゃぐちゃになり、判断ロジックの部分だけPythonに切り出し直した経緯があります。

Claude Code × Python実践ガイドでも自動化やデバッグの実践例としてこうした処理が紹介されていますし、非エンジニア向けのPython活用分野の解説でもデータ加工や判断処理が得意分野として挙げられています。これらの記事が触れている内容と、私が実際の案件で引いている線引きは重なっていて、複数条件を掛け合わせて一つの数値に落とし込む処理や、画面上の文字を読み取って次の操作を判断する処理であれば、Pythonに任せる価値があります。

逆に、単純なAPI呼び出しや、決まった形式のデータをそのまま次のサービスに渡すだけの処理であれば、n8nに任せたほうが早く組めます。この線引きを最初に持っておくと、どちらで作ればよいか毎回悩まずに済みます。

Claude Codeに渡す日本語指示の実例

結論として、指示文を書く段階で保存先のテーブル名・列名まで先に決めておくと、返ってくるコードの手戻りが大きく減ります。

例えば「クラウドワークスの新着案件を取得してタイトルと本文をデータベースに保存したい」という指示だけでは、保存先の形式をClaude Code側が勝手に決めてしまいます。これを次のように書き換えると、返ってくるコードの精度が変わります。

もう一つの例として、「問い合わせフォームに届いたメールの本文から、会社名と希望日程を抜き出してスプレッドシートに追記したい」という指示も、「会社名」「希望日程」が本文のどの位置に書かれているか、スプレッドシートの何列目に入れたいかまで伝えておくと、抽出のルールを自分で決め直す手間が省けます。曖昧にしたまま進めると、一見動いているように見えても、抽出した会社名の末尾に余計な文言が混ざっていたり、日付の書式がばらばらのまま追記されたりすることがあり、後から気づいて直すほうが手間になります。

伝える→動かす→エラーを貼る→直すのループを実例で見る

結論として、エラーが出たときはメッセージを要約せずそのまま貼ることが、遠回りに見えて一番早い直し方です。

実際にClaude Codeとのやり取りでよく出会うエラーには、次のようなものがあります。

1. APIキーが環境変数に設定されていない場合、KeyError: 'ANTHROPIC_API_KEY'のようなメッセージが出ます。この場合は「このエラーが出た」とメッセージ全文を貼るだけで、環境変数の設定方法まで含めた手順を返してくれます。
2. 必要なライブラリが入っていない場合、ModuleNotFoundError: No module named 'requests'のようなメッセージが出ます。これもエラー文をそのまま貼れば、インストールコマンドの提示まで一度で済みます。
3. Windows環境でファイルの文字コードが合わずUnicodeDecodeErrorが出た場合は、エラー文に加えて「Windowsで、UTF-8で保存したCSVを読み込もうとしている」のように、OSと保存形式を具体的に伝えます。この情報を省くと、的外れな修正コードが返ってくることがあります。
4. 保存先のパスが見つからずFileNotFoundErrorが出た場合は、ファイルを実際にどこに置いているかのフォルダ構成を伝えます。「デスクトップに置いている」程度の情報でも、パスの区切り文字の違いに気づいてもらえることがあります。

ここで大事なのは、エラーメッセージを自分の言葉で要約してから伝えないことです。「よく分からないエラーが出た」と要約して伝えると、Claude Code側は何が起きているかを推測するしかなく、見当違いの修正が返ってくることがあります。エラー文は長くても、画面に出た文字列をそのままコピーして貼るほうが、結果的に早く解決します。

実際に動いているスクリプトで起きたこと

結論として、スコアリングのような多軸判断と大量データの差分更新は、実際に動かしてみると設計の甘さがそのまま数字で跳ね返ってくる領域です。

代表例の一つがrun_opportunity_pipeline.pyです。応募率を低く保っているのは、スコアリングの基準を緩めすぎると自社に合わない案件にまで時間を使ってしまうためで、運用を始めた当初は基準が緩すぎて通らない案件への応募が増え、閾値を何度も調整し直しました。この実行ログがないと、応募件数が減った原因がスコアリングの基準にあるのか、そもそも案件の取得自体が止まっているのかを切り分けられません。

もう一つの例がrun_affiliate_updater.pyです。公開済みの記事に広告や内部リンクのブロックを追加する際、全記事を毎回上書きするのではなく、変更が必要な箇所だけを検出して差分更新する設計にしています。記事が数十本のうちは全件更新してもさほど時間はかかりませんが、記事数が増えるほど差分処理の有無が実行時間とミスの発生率に直結します。差分の判定ロジックを甘く作ると、本文を少し書き換えただけなのに「変更なし」と誤判定してしまい、意図したブロックが入らないという事故が起きます。何本か記事を見比べながら、どこまでの変更を「更新あり」とみなすかの条件を調整しました。

手元のファイルで試せる公開ツール

結論として、Pythonで何ができるかは、説明を読むより自分のファイルを貼って動かしてみるほうが早く分かります。

gpirot.comでは、実際に運用しているPythonの処理の一部を、公開ツールやデモとして誰でも試せる形で出しています。それぞれ、どんな詰まりに対応しているかという文脈とあわせて紹介します。

1. 手元にあるPDFや写真、Excelファイルなど、普段の業務で扱っているファイルを一つ用意します。個人情報や取引先名が入っている場合は、試す前に該当部分を黒塗りにするか、ダミーの名前や日付に置き換えておくと安心です。
2. 上の表から近い用途のツールを選び、該当ページを開きます。
3. 実際のファイルをアップロードまたは貼り付けて、出力結果を確認します。ファイルに見出し行がなかったり、列の並びが想定と違うと読み込みでエラーになることがあるので、その場合は見出し行の有無や列の順番を見直してください。
4. 出力結果を見て、自分の業務であればどこを調整すれば使えそうかをメモしておきます。ここで感じた「あと少し」の差分が、自分専用の自動化を考えるときの手がかりになります。

本数が増えてから困らないための3つの決め事

結論として、n8nとPythonの役割分担、命名規則、差分処理の3点を最初に決めておくと、スクリプトの本数が増えても運用が崩れにくくなります。

現在、ローカルPCのWindowsタスクスケジューラで複数の定時タスクを動かし、案件収集・応募文の作成・記事の更新・計測といった処理の結果はSupabaseに蓄積、サイト自体はCloudflare Pagesで公開しています。この構成で運用する中で、実際に詰まった点とその対処を整理します。

1. ノーコードツール(n8nなど)とPythonの役割分担を最初に決めます。単純なAPI呼び出しや通知のような受け渡すだけの処理はノーコード側に任せ、複数条件でのスコアリングやブラウザ操作が必要な処理だけをPythonに切り出しています。最初はすべてn8nで組もうとして、条件分岐のノードが増えすぎて画面が追えなくなり、途中から判断ロジックの部分だけPythonに移しました。
2. ファイル名の命名規則を最初に決めます。すべてrun_から始まる名前にすることで、スクリプトが増えても一覧から内容がある程度推測できます。命名規則を決めずに増やしていくと、半年後に見返したときにどれが何をするスクリプトか分からなくなり、中身を全部開いて確認する羽目になります。
3. 差分処理は後からではなく最初の設計段階で入れます。後から追加しようとすると、すでに全件上書きの前提でコードが組まれているため、保存形式やID管理の見直しが必要になり手戻りが大きくなります。差分の判定は、次のようにハッシュ値を比較する方法であれば、少ないコードで実装できます。

import hashlib

def content_hash(text: str) -> str:
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

# 前回保存したハッシュ値と比較し、一致しなければ更新対象とする
if content_hash(new_text) != previous_hash:
    # 更新処理を実行する
    pass

この3点を決めないまま本数を増やすと、後から直す範囲がどんどん広がります。最初の一本を作る段階ではここまで考える必要はありませんが、2本目・3本目を作る前に一度立ち止まって決めておくことをおすすめします。

最初の一本に何を選ぶか

結論として、大きなシステムを一から作ろうとするより、一つの作業の置き換えから試すほうが、実際に動くものにたどり着きやすいです。

2026年7月には、点検記録のデータ化という業務を、週10時間の継続作業として受注しました。業種はNDAにより非公開ですが、紙やPDFの点検記録をデータに変換する作業で、読み取りの部分にAIを使い、登録前の確認は人が行う運用にしています。特別な技術がなくても始められる規模の自動化です。

この案件もそうですが、最初から全自動を目指すのではなく、作業の一部を置き換えるところから始めるほうが、途中で止まったときの後片付けも小さく済みます。次にやることとして、公開中のAI転記ツールや問い合わせ自動返答のデモに自分の業務で使っているファイルを一つ貼ってみるか、自分の業務の中で「この作業を自動化できたら」と思っている工程を一つ書き出してみてください。