非エンジニアがClaudeCodeを使う、現実的なライン
Claude Codeにやりたいことを日本語で伝えると、画面の中でコードがどんどん書かれていって、ファイルができて、最後に「できました」と返ってくる。初めて動かしたとき、正直ちょっと感動しました。
でも、その次の瞬間に手が止まったんです。これ、合ってるのかな、と。
動いてはいる。エラーも出ていない。でも、書かれたコードが本当に正しいのか、自分には判断がつかない。すごいツールを手に入れたはずなのに、できあがったものを前にして固まっている。
この感覚、n8nを4ヶ月放置していた頃と、実はよく似ていました。
Claude Codeは「何を作れるか」で語られがちなんですが、自分が使ってみていちばん大事だと思ったのは、そこじゃなかった。「自分がどこまで確かめられるか」のほうでした。
今日は、コードを書く専門職ではない自分が、Claude Codeをどこまで使って、どこからは手を出さないことにしているか、その線引きの話をします。
入れ方や画面の操作は出てきません。
出てくるのは、任せる仕事の選び方だけです。
Claude Codeは、結局なにをしてくれる道具なのか
まず、自分の中での位置づけから。
ChatGPTやClaudeにチャットで相談すると、返ってくるのは文章やコードの「下書き」です。それを自分でコピーして、どこかに貼って、動かすのは自分の仕事になります。
Claude Codeは、その「貼って動かす」ところまで、自分のパソコンの中でやってくれる道具です。日本語で「こういうものを作って」と伝えると、ファイルを読んで、コードを書いて、実際に動かして、エラーが出たら直して、という手を動かす部分を代わりにやる。チャットのAIが「相談相手」だとしたら、Claude Codeは「手を動かす人」に近い。
この違いは、便利さと同時に、あとで効いてくる注意点にもなります。
相談相手なら、間違ったことを言われても、自分で読むから気づいて捨てられる。
でも手を動かす人は、こちらが気づかないうちに、もう作り終えている。
ここが、あとの話につながる分かれ目でした。
自分が実際に任せている範囲
じゃあ自分が実際に何を任せているかというと、共通点が1つあります。
「できあがったものを、自分の目で確かめられる」仕事です。
いくつか挙げると
n8nのCodeノードに入れる、短い処理のコード。
日付の変換とか、受け取ったデータの形を整えるとか。
標準ノードを何個も並べるより、5行書いたほうが早い場面があって、その5行をお願いする。一回きりのデータ整理。
大量のファイルの名前を規則的に付け替える、CSVから必要な列だけ抜き出す、といった単発の作業自分だけが使う小さな道具。
手元のメモを決まった形に整える、みたいなもの
これらに共通するのは、結果が目に見えることです。
変換されたファイルを開けば、ちゃんとできているかは一目で分かる。
n8nのCodeノードも、実際にデータを流してみれば、出てきた形が正しいかどうかはその場で確認できる。コードの中身を1行ずつ読めなくても、出口で判断できるんです。
正直に言うと、自分はコードを隅々まで読んで「この処理は正しい」と保証できるタイプではありません。
でも、出てきた結果が期待どおりかどうかなら、細かい知識がなくても分かる。
この「出口で分かる」が、任せていい仕事の条件でした。
ちなみに、業務を工程に割っておくと、渡すのはそのうちの一部品だけになるので、確かめる範囲も小さくなります。
どこからは、手を出さないことにしているか
逆に、手を出さないことにしている領域も、はっきりしています。ひとことで言うと、「できあがったものが正しいか、自分では確かめられない」仕事です。
Claude Codeは、頼めばかなり大きなものも作ってくれます。
ちょっとしたWebアプリらしきものも、それっぽく動く形で出てくる。
最初はこれに舞い上がりました。
でも、そこに落とし穴があって、AIが書くコードは、間違っていても堂々としているんです。
明らかなエラーで止まってくれるなら、まだいい。困るのは、動いてはいるけど、どこかが静かに間違っているケースです。ぱっと見は完成して見えるから、コードを読めない自分には気づけない。相談相手なら「それ違うよ」と言えたはずのミスが、手を動かす人だと、もう作り込まれた状態で目の前にある。
だから自分は、次のような仕事はClaude Codeに丸ごとは任せません。
他の人や、お客さんが使うもの。
自分が中身を保証できないものを、人に渡すわけにはいかない動かし続ける必要があるもの。
作った瞬間は動いても、あとで壊れたときに、自分では直せない間違うと影響が大きいもの。
お金の処理や、大事なデータの書き換えが絡むところ
これは能力の限界というより、責任の線だと思っています。
作れるかどうかではなく、壊れたときに自分が引き受けられるか。
引き受けられない場所には、たとえ作れても置かない。
現実的なラインは「確かめられるか」で引く
ここまでの話を、自分は1本の線で引いています。
「できあがりを、自分で確かめられるか」
この線の内側がClaude Codeに任せていい範囲で、外側は、たとえ作れても任せない範囲です。
もう少しほぐすと、確かめやすさは2つで決まっていました。
1つは、結果が目に見えるかどうか。
変換したファイルや整理したデータのように、出口を見れば正しさが分かるものは、確かめやすい。逆に、正しさがコードの中に隠れていて、動かしても表に出てこないものは、確かめにくい。
もう1つは、壊れても自分の責任の範囲で収まるかどうか。
自分専用の道具なら、間違っていても困るのは自分だけです。
でも人が使うものは、自分が気づかない間違いが、そのまま相手に届いてしまう。
この2つが両方そろっている目で確かめられて、壊れても自分の中で収まる仕事だけを、Claude Codeに預けています。
どちらかが欠けた瞬間に、線の外側だと考えるようにしました。
性能がどれだけ上がっても、自分が確かめられる範囲より外は、任せる相手を間違えているだけなんです。
だから、他のツールと「使い分ける」
この線が引けると、Claude Codeを他のツールと使い分ける感覚が、自然に出てきます。どれが優れているか、ではなく、どこにどれを置くか、という話です。
自分の場合、役割はだいたいこう分かれています。
チャットのAI（ChatGPTやClaude、Gemini）は、相談相手。
何を作るかまだ決まっていない段階で、考えを整理したり、下書きをもらったりする場所です。
Claude Codeは、部品を作る道具。
作るものが決まっていて、結果を目で確かめられる小さな仕事を、手を動かして片付けてもらう。
n8nやDifyは、仕組みそのもの。
毎日動き続ける本体で、フローが目に見えるから、非エンジニアでも中身を追える。ここが自分にとっての主戦場です。
大事なのは、Claude Codeは「仕組みの部品を作る道具」であって、「仕組み本体」ではない、と割り切っていることです。動かし続ける本体はn8nやDifyに置いて、その中で使う細かい部品を、必要なときだけClaude Codeに作ってもらう。この住み分けにしてから、背伸びして事故ることが減りました。
作れることと、任せていいことは、分けて考える
まとめます。非エンジニアがClaude Codeを使う現実的なラインは、ツールの性能ではなく、自分の「確かめられる範囲」で決まります。
Claude Codeは、頼めば大抵のものを作ってくれます。
だからこそ、作れることと、任せていいことは、分けて考えたほうがいい。
出てきた結果を自分の目で確かめられて、壊れても自分の中で収まる、
その2つがそろう仕事から始めるのが、遠回りに見えて、いちばん事故りませんでした。
もし今からClaude Codeを触ってみるなら、いきなり「アプリを作らせる」ではなく、n8nのCodeノードに入れる短いコードとか、手元のファイルを整える一回きりの作業とか、結果がすぐ目で分かるものから渡してみてください。「うまく動いたかどうかを自分で判断できる」その手応えが、次にどこまで任せられるかの、いちばん確かなものさしになります。
途中で操作に詰まっても、それはまた別の小さな問題なので、エラーを丸ごとAIに貼れば、たいてい越えられます。
最後まで読んでくれて、ありがとうございます。
思いつきや週1くらいのペースで、実装メモとつまずきの記録を書いています。
今後の投稿が気になる人はフォローしておいてください。
