AI に作業を任せたいのに、勝手にファイルを書き換えられたり、メールを送られたりしないか不安になっていませんか。本記事は、自分の手元のファイル・メールアカウント・GitHub リポジトリ・外部サービスに対して、AI にどこまで動かしてよいかを決めたい開発者・個人事業者向けにまとめた整理ノートです。専門語の意味を辞書のように解説する記事ではなく、自分の作業範囲を 4 つに分けて、どこから人間が確認に入るかを先に決める考え方を紹介します。
紹介する道具の名前だけ並べておくと、ローカルでファイル編集を任せる仕組み (この記事では Claude Code と呼びます)、外部サービス連携や定期実行を組む仕組み (n8n と呼びます)、変更履歴と巻き戻しを担当する仕組み (Git と呼びます) の 3 つです。名前を覚える必要はなく、それぞれが「AI にどの作業を任せるかを分けるための器」だと思って読み進めてください。後の章で 1 つずつ、何を任せて何を残すかを具体的に並べていきます。
この記事は新しいツールの紹介ではなく、すでに AI に何かを任せ始めた人、もしくはこれから任せようとしている人が、最初に手元で決めておきたい許可範囲の話です。ファイルが対象なのか、メール送信が対象なのか、GitHub のリポジトリが対象なのか、外部 SaaS が対象なのかで、止めるべき場所が変わります。読み終わったときに「自分の作業ではこの 4 つのうちどれが該当するか」が見え、最初に閉じておくべき設定や承認の入れ場所が決まる状態を目指します。
判断軸は終始 2 つだけです。1 つは「あとから戻せる作業か (可逆性)」、もう 1 つは「影響が自分の手元に閉じるか、外まで出ていくか (影響範囲)」です。この 2 軸さえ手元に置いておけば、新しいツールが出てきたときも自分で線引きができます。逆に、この 2 軸を決めずに「全部 AI に任せて速くしたい」と進めると、戻せない場所まで AI に踏み込ませてしまい、後から気付くことになります。
最後にひとつ前置きをしておきます。AI を信用するかしないかは、本記事では問いません。AI が触れる範囲を狭く切っておくほうが、信用の議論より先に効きます。範囲を狭く切れば、信用が低くても任せられる作業が見つかり、信用が高くても外せない人間判断が残ります。ここから先は「狭く切るための具体的な分け方」を 1 章ずつ並べていきます。
AI に作業を任せる前に出てくる不安
AI に作業を任せたいと思いつつ、勝手にファイルを書き換えられたり、メールを送られたりしないか不安になったりすることが多い今日このごろです。ここでは、Claude Code や n8n を試そうとしている個人開発者・エンジニアが、AI に作業を渡す前に決めておくべき許可範囲を整理します。専門語の整理ではなく、自分の手元のファイル・メール・GitHub に対して、どこまで自動で動かしてよいかを判断する話として読んでください。
ファイルを書き換えられそうな不安
Claude Code に Edit や Write を任せると、意図しないファイルまで上書きされそうで止まりやすい不安です。書き換えがどこまで広がる可能性があるかを 1 段下で確認します。
Edit / Write と言われても、開発の現場以外では遠い言葉に見えますよね。ここでは「AI が指示に従ってローカルのファイルを上書きする道具」と考えておけば十分です。問題は、対象ディレクトリを切らずに動かすと、設定ファイル・認証情報ファイル・隣のプロジェクトのコードまで巻き込んで書き換えが広がる経路があることです。書き換え系を任せる前に、対象ディレクトリの境界を先に決めるのが入口になります。
メールや外部送信が走りそうな不安
AI にメール送信や外部 API 呼び出しを任せた瞬間、勝手に走り始めるのが怖いところです。送信が動く経路と、止められる場所がどこかを次以降で並べていきます。
メール送信や外部呼び出しは、ファイル書き換えと違って「外に出てから取り消せない作業」が含まれます。ここで止まる人は多いです。後の章で「下書きで止める / 即送信させない / 承認を挟む」の 3 つを分けて並べるので、まずは「外に出る作業はファイル書き換えと同じ感覚で扱えない」とだけ押さえておいてください。
Git や本番環境まで触られそうな不安
git push や本番デプロイまで AI に任せたら何が起きるか、見える前に不安が立つのは当然のことです。後段で「どこまで任せて、どこから人間で押すか」を分けて並べます。
git push と言われると技術寄りに見えますが、要は「手元の変更を、自分のチェックなしに公開してしまうかどうか」の境目です。手元の差分を作る段階までは戻しやすく、push と本番デプロイは公開・外部反映が走るため戻しにくくなります。GitHub の章で、ローカル差分 / PR 作成 / push の 3 段階に分けて整理します。
ファイルの読み取りと書き換えの境目
AI にファイルを触ってもらうとき、読み取るだけか書き換えるかの境目で止まりやすいですよね。Edit や Write と言われても、まずは「AI がファイルを上書きする道具」として読み進めてください。ここで決めるのは「あとで戻せる作業」と「戻せない作業」のどちらに振るかで、書き換え側に振る前に戻し方を先に決めておきます。
読み取り作業の自動化範囲
ファイルを読むだけの作業は、影響範囲が読み手側に閉じているため AI に任せやすい部類です。ログ確認・設定ファイル読み取り・コード検索などはここに入ります。
読み取り中心の作業は、外に出る経路がほぼないため、最終確認なしで動かしてもリスクが小さいまま収まります。ログを眺めて要因を絞り込む、設定ファイルから不要な行を見つける、似たコードを横断検索する、といった作業は AI のテンポを生かしやすい場所です。ただし、認証情報やシークレットが書かれたファイル (.env や secrets/ 配下など) は読み取りでも閉じておくほうが安全で、後述する設定ファイルで先に止めておきます。
書き換えるときに人間が見るべき範囲
書き換えを任せるときは、対象ディレクトリと差分の範囲をあらかじめ狭く切っておきます。Edit や Write の対象を作業ディレクトリ配下に限定するだけでも、事故率は大きく下がります。
書き換え系で重要なのは「どのファイルに何を書いたか」を後から自分で見られる状態にしておくことです。後述するように Git 配下で動かしておけば、書き換え後に差分を読んで戻せます。逆に、Git 管理されていないディレクトリで Edit / Write を走らせると、上書き前の状態を取り戻せません。書き換え対象は Git 管理ディレクトリに寄せる、というのが手元での簡単な防衛線になります。
戻せる場合と戻せない場合の違い
削除・上書き・移動が混ざる作業は、戻せない側に分類します。Git 配下の編集は戻せる範囲、rm や mv は戻せない範囲として、同じ感覚で扱わないようにします。
ファイル削除や移動コマンド (rm / mv 系) は、Git 管理外のファイルが対象になると戻せません。AI に任せる場合は、削除系コマンドを禁止リストに入れておくのが手堅い対策です。Claude Code の settings.json には「実行してよいコマンド」と「禁止するコマンド」を書き分ける設定がありますので、最初に次のような禁止ルールを入れておきます。
{
"permissions": {
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force *)",
"Read(./.env)",
"Read(./secrets/**)"
]
}
}
deny に書いた操作は AI 側からは実行不能になります。.env や secrets/ 配下を読み取り側から閉じておくと、認証情報を AI のコンテキストに乗せる経路もまとめて塞げます。
メールの下書きと送信の境目
AI にメールを書かせるとき、下書きを作るだけか、即送信まで任せるかで不安の大きさは大きく違ってきます。Gmail などのメール送信は、下書き作成と即送信が別の許可で扱われる仕組みになっていて、AI に渡す権限の範囲はこの 2 つで切り分けられます。下書き止まりにすれば人間が読んでから送れるため取り消しが効きますが、即送信まで任せると後戻りできません。
下書き作成までを AI に任せる範囲
Gmail の下書き作成までは、人間が読んでから送れるため AI に任せやすい範囲です。文面の生成・宛先候補の整理までを AI 側に寄せ、送信ボタンは人間が押すかたちにします。
下書きを作るだけなら、誤った文章でも送信前に直せます。宛先候補の整理や文面たたき台の作成は、メール 1 通あたりの所要時間が大きく削れる場所なので、AI に寄せて効きやすい作業です。送信ボタンを人間が押す前提を維持しておけば、可逆性は確保されます。
即送信を AI から外す理由
即送信は取り消しが効かないため、可逆性の低い操作の代表例です。AI のループ判断が暴走したときの被害が直接外に出てしまうので、即送信は AI 範囲から外しておきます。
メール送信は外部に出てしまえば取り消せません。AI が複数回ループする処理の中に即送信が組み込まれていると、想定外の宛先・想定外の文面が一気に出ていくことがあります。「下書きまでは AI、送信ボタンは人間」を線として固定しておくと、ループ判断の暴走を最後の段階で止められます。
承認を挟むためのワークフローの組み方
n8n の「Send a message and wait for approval」のような承認ノードを挟みます。送信前に Slack やメールで人間に確認を取る経路を作れば、送信は機械的でも承認は人間に残せます。
n8n には Gmail ノードと並べて「Send a message and wait for approval」という承認ノードを置く構成が用意されています。承認チャネルは Slack またはメールから選ぶ形で、AI が作った文面を人間が一度読んでから承認ボタンを押すと、その後ろの送信ノードが動き始めます。送信処理そのものは自動でも、承認は人間に残せる作り方なので、メール送信のような不可逆操作では既定の選択肢として組み込んでおきます。
GitHub の差分作成と push の境目
GitHub の操作も、差分を作るだけか push まで AI に任せるかで分かれ目があります。push と言われると技術寄りに見えますが、まずは「AI が書いた変更を、自分の確認なしに公開してしまうかどうか」の境目だと考えてください。手元で変更を作る段階までなら戻しやすく、push してしまうと履歴に残るため、人間が見るタイミングはこの境目に置きます。
変更をローカルに作るだけの使い方
AI に PR の前段までを任せる場合、変更はローカルに置いておくだけで公開はしません。git add と git commit で記録しておけば、後で差分を見て戻せる形になります。
ローカルにコミットを積む段階では、まだ公開していない状態が続きます。git diff で差分を読みながら、不要な変更を git restore で戻すこともできます。AI に書き換えを任せる場面では、まずこの「ローカルコミットだけ作って公開しない」段階に止める運用が手堅いです。
PR 作成までを任せる範囲
GitHub の PR 作成は、人間レビューを挟む前提で AI に渡せる範囲です。gh pr create で PR を立てるところまでを任せ、マージは人間が押すと安全に運用できます。
GitHub の公式コマンドラインツール gh を使うと、ターミナルから PR を立てられます。引数を最小にした例は次のような形です。
gh pr create --title "feat: 設定ファイル更新" --body "AI が生成した設定変更の PR"
PR の本文には変更の意図と差分の要約を AI に書かせ、マージボタンは人間が押すという分担にしておくと、自動化と人間レビューが両立します。なお、Claude Code 側で git push を承認制にしたい場合は、settings.json の permissions.ask に次のように書いておきます。
{
"permissions": {
"ask": [
"Bash(git push *)",
"Bash(npm publish *)"
]
}
}
ask に書いた操作は実行直前に人間の確認を挟む扱いになります。push と npm 公開はこの層に置いておくのが、個人開発でも顧客案件でも扱いやすい線引きです。
push 系を AI に任せない判断
git push --force ・ branch -D ・ reset --hard などの破壊的操作は、AI 範囲から外します。Claude Code の permissions.deny に書いておけば、誤って実行されるリスクを下げられます。
force push やブランチ強制削除は、履歴を上書きする操作で、戻すには別の手立てが必要になります。AI のループ判断で偶然走ってしまうと、共有ブランチの履歴が崩れる経路にもなりますので、最初から deny に書いて閉じておくのが安全です。料金や課金責任の話まで含めて整理しておきたい場合は、関連解説として Claude Codeの自動実行に料金分離｜Agent SDKクレジットで何が変わるのか を併読しておくと、許可範囲と請求の責任分担まで線が通しやすくなります。
外部サービスに命令が走るときの動き
外部サービスに AI から命令を送るとき、何が裏で動いているのか見えなくて怖いですよね。実際には AI 自身が直接サービスを叩いているのではなく、AI と外部サービスの間に立つ別のプログラムが、認証情報を持って命令を送っています。ここで止まりやすいのは、課金や誤送信が裏で起きる経路がどこかという点ですので、その動きを 1 枚で整理します。
外部に命令を送る経路と認証情報の置き場所
AI 自身は API キーを直接持たず、認証情報は Claude Code や n8n などの実行基盤側に置きます。AI が見るのは「どんな引数で呼ぶか」というツール定義だけ、と覚えておくと整理しやすくなります。
API と言われても、いきなり自分の作業と結びつかないですよね。ここでは「外部サービスに命令を送るための窓口」と考えてください。正式名称は API (Application Programming Interface) ですが、AI に渡る情報は「窓口の名前と、呼び出す引数の形」だけです。実際に窓口を叩く側のプログラム (Claude Code 本体や n8n のノード) が認証情報を保持し、AI からの指示を受けて初めて外に出ます。判断軸としては「AI が見ているのは引数の形だけ / 認証情報は実行基盤側に閉じている」と置いておけば十分です。
課金やレート制限が動く場面
外部 API の呼び出しでは、レート制限と課金が裏で動きます。AI のループで同じ API を連続呼び出しすると、月額が一気に積み上がる経路があるので、ループの上限と通知を先に設計します。
レート制限と言われても、普段の作業では意識しないですよね。簡単に言うと「単位時間あたりの呼び出し回数の上限」のことで、ここを超えると追加課金になるか、エラーで止まる経路に切り替わります。AI のループでは同じ API を回し続けるパターンに陥りやすいので、ループ回数の上限と、想定を超えたときの通知先を先に決めておきます。n8n と API 課金の積み上がり方を構造で押さえたい場合は、関連解説として n8nでAI自動化するとAPI課金が膨らむ理由：構造と用途別の月額試算 を併読しておくと、月額の見え方がはっきりします。
取り消しが効く操作と効かない操作
外部サービスへの操作には、後から取り消せる作業 (下書き作成・PR の close) と取り消せない作業 (メール送信・課金確定) が混在しています。同じ「AI に任せる外部操作」としてまとめずに、可逆性で分けて扱います。
可逆性で分ける、というのが本記事の通奏低音です。同じ「外部サービス操作」でも、下書きを作って消す程度なら戻せますし、PR を close するのも後で開き直せます。一方で、メール送信・決済・課金確定・公開デプロイは外に出てしまったら戻せません。AI 範囲を決めるときは「サービス名」ではなく「その操作が戻せるか」で線を引きます。
AI に任せてよい作業と本番で止める作業
AI に任せてよい作業と、本番では絶対に手を動かす作業の線引きを、ここで一度はっきり決めます。判断の基準は「戻せるか / 影響範囲はどこまで広がるか」の 2 軸で、可逆性が低い操作 (本番 DB の削除・大量メール送信・公開デプロイ) は最後まで人間に残します。読み取り・書き込み・公開系の 3 つを分けて見れば、自動化と承認の境目が自然に決まります。
読み取り中心で自動化しやすい作業
ログ確認・設定ファイル探索・コード検索・API GET 系の情報取得は、AI に任せやすい部類です。読み取り側に影響が閉じているため、最終確認なしで動かしてもリスクが低いままです。
読み取り系は外への副作用がほぼないため、AI のテンポを生かす一番の場所になります。ログから例外を拾う、設定ファイルから不要設定を抜く、横断的にコードを検索する、外部 API から情報を取って整形する、といった作業は積極的に寄せていって構いません。ここで悩む時間を減らせるほど、人間が見るべき書き込み・送信側の作業に集中できます。
書き込み・送信で承認を挟む作業
ファイル書き込み・API POST・git commit ・PR 作成などは、可逆ではあるものの影響が外に広がります。人間承認を挟むワークフローで運用すると、AI の暴走を止められます。
書き込み・送信側は「戻せるが、外に影響が出る」ゾーンです。Git のように後から差分を読んで戻せるならローカルに作るところまで任せ、外部送信系は前述の承認ノードで人間判断を挟みます。AI が判断を間違えていても、承認の段階で気付ければ被害は止まります。AI と人間の役割分担そのものを整理しておきたい場合は、関連解説として AIをどう活用するか──手放す作業と残す判断、作業者に戻らない使い方 を併読しておくと、何を残して何を渡すかの軸が手元で固まります。
本番環境では人間が手を動かす作業
本番 DB の DELETE ・ git push --force ・メール一斉送信・公開デプロイは、AI 範囲から外します。これらは可逆性が低く影響範囲が広いため、最後の操作は人間が手で押す前提にしておきます。
本番環境への破壊的操作・大量配信・公開反映は、AI の判断がどれだけ良くても外に出すべきではないクラスです。bypassPermissions のような全許可モードを本番で常用しない、本番 DB に対する DELETE は人間がコマンドを叩く、デプロイのトリガーは人間のクリックに残す、というラインを先に決めておくと、後から議論する必要がなくなります。
個人開発とブログ自動化での使い分け
個人開発やブログ自動化のような小さな現場では、AI に何でも任せるよりも、誰が何をやるかを先に決めるほうが楽になります。Claude Code・n8n・Git と言われても作業者目線で見ると、要は「AI に何を任せるか」を分けるための道具です。この 3 つで役割を分担すれば、ファイル変更・外部連携・履歴確認のそれぞれで止めどころが決まります。
ローカルのファイル変更を Claude Code に寄せる役割
Claude Code はローカルファイルの編集に強い道具です。コード変更・設定ファイル編集・ドキュメント更新をここに寄せて、settings.json の deny ルールで触ってほしくないファイルを先に閉じます。
ローカル編集を 1 箇所に寄せておくと、許可範囲の管理が settings.json 1 ファイルで完結します。次の行動として、まずは Claude Code の settings.json を開き、Bash(git push *) と Read(./.env) が deny / ask のいずれかに含まれているかを確認しておいてください。書かれていなければ前述の例をそのまま貼り、対象パスだけ自分のプロジェクトに合わせ直す形で問題ありません。料金・課金責任の分担まで踏み込んで整理したい場合は、関連解説として Claude Codeの自動実行に料金分離｜Agent SDKクレジットで何が変わるのか を併読しておくと、許可範囲と請求の整理が同じ軸でつながります。
外部連携を n8n に寄せて承認を挟む構成
外部 API 連携・SaaS 連携・スケジュール実行は n8n 側で組みます。メール送信のような不可逆操作には、「Send a message and wait for approval」のような承認ノードを挟みます。
外部に出る作業を n8n に寄せておくと、認証情報・承認ノード・実行ログが 1 箇所に集まり、後から見直しやすくなります。次の行動として、n8n のワークフローに Gmail ノードを置く前に、その手前に「Send a message and wait for approval」を挟み、Slack またはメール宛で承認を取る経路を試しておくと、送信処理の止めどころが手元の感覚として掴めます。API 課金の積み上がり方を構造で押さえておきたい場合は、関連解説として n8nでAI自動化するとAPI課金が膨らむ理由：構造と用途別の月額試算 を併読しておくと、ループ呼び出しの上限設計の判断材料が揃います。
差分確認と巻き戻しを Git で押さえる仕組み
AI が触ったコード・設定はすべて Git に記録し、git diff で人間が差分を読みます。PR 経由でのみ main に反映する運用にすれば、暴走しても巻き戻せます。
Git と言われると開発者向けの話に見えるかもしれませんが、ここで見るポイントは「変更をあとから確認して戻せる仕組み」を一枚噛ませておくことです。Claude Code が書き換えたファイルも、n8n が更新した設定も、Git 配下に置いておけば差分を読み、必要なら戻せます。main ブランチへの反映は PR 経由に限定しておくと、レビューの入口を 1 つに絞れます。
最後の判断を人間に残す範囲
本番デプロイ・公開 push・外部送信・課金確定は、最後まで人間が手を動かす範囲に残しておきます。AI がどれだけ正しく判断しているように見えても、実行ボタンは人間側にあるほうが安全に運用できます。
役割分担の最後は「実行ボタンは人間」というシンプルな線で締めます。AI に作業を渡す側として残しておきたい範囲を整理する角度では、関連解説として AIをどう活用するか──手放す作業と残す判断、作業者に戻らない使い方 を併読しておくと、「手放す作業」と「残す判断」の軸が手元で言葉になります。
まとめ
記事の最後に、ファイル・メール・GitHub・外部サービスの許可範囲を 1 枚で整理しておきます。AI をどれだけ信用するかで悩む前に、AI が触れる範囲を狭く切るほうが、個人開発でも顧客案件でも早く回り始めます。
許可範囲を狭く決める設計
AI を恐がる必要はなく、許可範囲を狭く切っておけば、安心して任せられる作業が増えていきます。tools / MCP / API といった専門語の理解より、まずは「どこまで動かしてよいか」を決めるほうが先です。
AI 信用より触れる範囲を狭く切る発想
AI を信用するかどうかで悩むより、AI が触れる範囲を狭く切るほうが個人開発でも顧客案件でも早く回り始めます。ファイル・メール・GitHub・外部サービスの 4 つから、自分の手元で 1 つずつ範囲を決めてみてください。
