Claude Codeとは何か、実際に投げた依頼文と直し方から説明する

Claude Codeとは何か、ChatGPTでコードをもらう方法と何が違うか

Claude Codeは、ターミナル上で日本語の指示を受け取り、自分のPCにあるファイルを直接読み書きしながらプログラムを完成させていくツールです。ChatGPTにコードを書いてもらってコピペする方法との一番の違いは、コードがどこで動くかにあります。

ChatGPTの場合、画面に表示されたコードを自分でコピーし、エディタに貼り付け、ファイル名や保存場所を自分で管理する必要があります。複数のファイルにまたがる修正になると、どこを直したか分からなくなり、貼り忘れや上書きミスが起きやすくなります。Claude Codeはプロジェクトのフォルダを直接開き、必要なファイルを自分で探して読み込み、修正箇所だけを書き換えます。人がコピペを仲介しない分、作業の抜け漏れが減ります。JAPAN AI ラボでも、Claude Codeがターミナルから自然言語でコード生成・修正・実行までを一貫して行えるツールだと紹介されていますが、実際に手を動かしてみると「ファイルを自分で触ってくれる」という一点が、非エンジニアにとっての体感差として一番大きいと感じています。

gpirot.comの自動化は、ほぼ全てClaude Codeで作られている

私が運営するgpirot.comの自動化の大半は、プログラミング未経験の状態からClaude Codeに日本語で指示を出しながら組み上げたものです。

たとえば、定時タスクは複数本動いています。Webからの情報収集、AIによる分類と下書き作成、LINEのwebhook受信、Cloudflare Workerでの処理、Supabaseへのデータ保存までを組み合わせ、ローカルPCの定時タスクとして無人で回しています。日本株の監視ボードfunnel.gpirot.comも同じ発想で、寄り付き前の板情報を機械が読んで候補を選び、結果を毎日採点して公開するところまでを、収集・選定・通知・採点・公開のすべてで人の手を介さずに動かしています。

AI副業ラボでも非エンジニアがClaude Codeを使って自動化から副業を始める動きが紹介されていますが、私の場合も最初の一本は、今日これから説明する一文から始まりました。

最初の一文はこう書く：実際に投げた依頼文を公開する

最初に動かすスクリプトは、業務の流れをそのまま一文にして渡すと、驚くほどそのまま動きます。

私が実際に投げた依頼文は、記事投稿を自動化するrun_post_article.pyというスクリプトを作ったときのものです。

Supabaseのarticlesテーブルからstatus='ready'の記事を取得して、
WordPressにREST APIで投稿し、投稿済みに更新するスクリプトを書いて

この一文には、次の4つの情報が入っています。1つ目はデータの取得元(Supabaseのarticlesテーブル)、2つ目は対象を絞る条件(status='ready')、3つ目は処理の内容(WordPressへのREST API投稿)、4つ目は処理後の後始末(投稿済みに更新)です。この4つがそろっていれば、Claude Codeは必要な接続情報やライブラリをこちらに確認しながら実装を進めてくれます。

依頼文を作る手順は次のとおりです。

1. 自分の業務で「何を、どこから取ってきて、どこに渡すか」を紙に書き出す。この時点で箇条書きで構わない。
2. 取得元の名称(テーブル名、ファイル名、サービス名)を具体的な固有名詞で書く。「データベースから」ではなく「Supabaseのarticlesテーブルから」まで書く。
3. 対象を絞る条件があれば数値や文字列をそのまま書く。「準備ができた記事」ではなく「status='ready'の記事」と書く。
4. 処理後に何を変えるかを書く。更新し忘れると同じ記事を何度も処理してしまうため、この一行を抜かさない。
5. 書き終えた一文をそのままClaude Codeのターミナルに貼って実行する。初回はAPIキーの入力や接続先の確認を聞かれることが多いので、順番に答える。

ここで詰まりやすいのは、取得元の名称があいまいなまま依頼してしまうケースです。「記事データから」のような書き方だと、Claude Codeは存在しないテーブル名を推測して実装してしまい、実行してから初めてエラーに気づくことになります。固有名詞は面倒でも先に確認しておくと、やり直しの回数が減ります。

詰まったときの直し方：エラーログの貼り方と指示の分け方

詰まったときは、エラーをそのまま貼ること、依頼を一度に詰め込みすぎないことの2つで、ほとんどの問題が解決します。

スクリプトを実行してエラーが出たときは、自分でエラーの意味を調べる必要はありません。ターミナルに表示された内容をそのままコピーして渡すだけで直ることがほとんどです。

Traceback (most recent call last):
  File "run_post_article.py", line 42, in <module>
    res = supabase.table("articles").select("*").eq("status", "ready").execute()
KeyError: 'SUPABASE_URL'

このようなエラーをそのまま貼って「このエラーが出ました」と伝えるだけで、原因(環境変数が読み込まれていない)を特定し、設定ファイルの確認方法まで提示してくれます。自分で「KeyErrorとは何か」を理解していなくても、修正自体は成立します。

一方で失敗しやすいのは、一度の指示に複数の機能を詰め込んでしまうパターンです。たとえば次のような依頼文は、途中から意図と違う実装になりがちです。

Supabaseから記事を取ってWordPressに投稿して、
投稿したら画像も自動生成して、SNSにも流して、
失敗したらLINEに通知もしてほしい

これは実際には4つの機能(投稿・画像生成・SNS連携・通知)が一文に混ざっています。この状態で依頼すると、Claude Codeはどれを優先するか判断に迷い、通知の実装を省略したり、画像生成とSNS連携を一体化させて後から分離しにくい形にしたりすることがありました。直す手順は次のとおりです。

1. まず投稿処理だけを依頼し、動作確認が取れるまで次の機能には進まない。
2. 投稿処理が動いたら、画像生成だけを別の依頼として追加する。このとき「既存の投稿処理は変更しないでください」と一言添える。
3. SNS連携、LINE通知も同じ順番で1つずつ追加する。
4. 途中で意図と違う実装になっていたら、どこまでは合っていてどこから違うかを具体的に伝える。「全部やり直して」ではなく「投稿処理は問題ないので、画像生成の部分だけ直して」と範囲を絞る。

これが「一指示・一機能」の実際の粒度です。機能が増えるほど、1回の依頼に含める量は減らす方向に調整すると、手戻りが少なくなります。

自分の業務で試すなら、まずこの題材から

自分の業務で最初の一本を試すなら、紙やPDFの情報をAIが読み取り、最後だけ人が確認するという構造の業務から始めるのが扱いやすいと感じています。

私自身、2026年7月から週10時間ほどの継続作業として、手書きの点検記録を読み取って業務ツールへ登録する仕事を受注しています(NDAのため業種は非公開です)。この仕事では、読み取りはAIが行い、登録前の確認だけを人が行う形にしています。AIに全部任せるのではなく、最後の確認だけ人が残すことで、誤読のリスクを抑えながら作業時間を減らせました。

同じ構造(入力してAIが処理し、最後に人が確認する)を持つ公開ツールを3つ用意しています。自分の手元にある表や写真を使って、実際に試すことができます。

• AI転記ツール(PDF・写真→Excel)：手書きの帳票や写真をアップロードすると、内容を読み取ってExcel形式に転記します。
• 問い合わせの自動返答(管理画面つき)：登録した拠点・営業時間・よくある質問の範囲で答え、判断が要る質問は担当者へ引き継ぎます。管理画面で登録内容を書き換えると、答えがその場で変わります。
• シフト表から出勤簿・申請書を作るサンプル：シフト表をもとに、出勤簿や申請書の形式に組み替えます。

これらのツールを見ると、どこまでをAIに任せ、どこからを人の確認に残しているかの線引きが分かります。自分の業務に当てはめるときは、まず自分が今手作業でやっている中で「読み取って、別の形式に書き写す」工程がないかを探すところから始めると、最初の一本の題材が見つかりやすくなります。

まとめ：言語化できれば、最初の一本は今日動かせる

最初の一本を動かすために必要なのは、コードの知識ではなく、自分の業務を一文で言い表す力と、出てきたエラーを恐れずにそのまま投げ返す姿勢です。

ここまで見てきたように、依頼文は「どこから、何を条件に、何をして、処理後どう変えるか」の4点を固有名詞で書けば十分で、詰まったときはエラーログをそのまま貼り、機能を1つずつ分けて依頼すれば直せます。この2つのやり方さえ押さえれば、自分のPCで最初のスクリプトを動かすところまでは、特別な準備なしに到達できます。

次は、Pythonが書けなくてもClaude Codeで最初の自動化を動かす手順を扱った記事で、環境構築の最初の一歩から順を追って確認してみてください。