雑に「API叩いておいて」「DB見ておいて」と投げると、Claude Code はだいたい困る。困るだけならまだいいが、権限が広すぎると余計な変更まで手を出す。ここでやるべきことは単純で、触れる範囲を狭く切り、危ない操作は人間の確認を挟み、あとで検証できる形にしておくことだ。
Claude Code は Anthropic の CLI ベースのコーディングエージェントで、ローカルのファイルだけでなく、外部 API やデータベースに対する作業にも使える。とはいえ、何でも自由にやらせると事故る。たとえば、調査だけのつもりが更新系の SQL を流す、一覧取得だけのつもりが大量データを吸い上げてコンテキストを食い潰す、認証情報を雑に置いて別の用途まで届いてしまう。こういう手戻りは、最初の設計でかなり減らせる。
まず押さえるべきは、「Claude Code に直接本番の権限を持たせない」ことだ。これは大げさでも何でもない。外部 API なら読み取り専用のトークンを分ける、DB なら参照専用ユーザーを作る、変更系は別の手順に分ける。Claude Code に渡すのは、最小権限の資格情報だけにする。これで事故の半分は消える。
たとえば、API の調査だけをさせたいなら、こんな頼み方にする。
このプロジェクトのユーザー一覧を外部 API から確認したい。
読み取り専用の認証情報だけを使ってください。
取得は 100 件までに絞って、結果は要約だけを書いてください。
秘密情報は出力しないでください。
この書き方の肝は、何をしていいかを限定し、何をしてはいけないかも明示することだ。「見ておいて」だけだと、エージェントは広く解釈する。100 件まで、と上限を切るのも大事だ。API は気を抜くと平気で大量の行を返す。そこから全部を会話に載せると、肝心の文脈が溶ける。
DB でも同じだ。まずは読み取り専用の接続先を分ける。書き込み権限のある接続文字列を渡すのは、最後の最後だ。筆者は以前、検証用に「とりあえず同じ接続先で」と雑に始めて、集計用の SELECT を頼んだつもりが、後から更新系の作業にそのまま流れ込みそうになって冷やっとしたことがある。人間が見れば危ないと分かるが、曖昧な権限設計だと流れでやれてしまうのが怖い。
実務でやるなら、接続情報はリポジトリに直書きしない。ローカルの環境変数か、OS の秘密管理機能、少なくとも .env のような外に出さない場所に置く。Claude Code には、そのファイルを読んでいいと明示する。逆に、Git 管理している設定ファイルに本物のキーを入れるのはやめたほうがいい。履歴に残ると後で消すのが面倒だし、消したつもりでも完全には安心できない。
たとえば、こういう手順にする。
# 例: 読み取り専用の環境変数を別ファイルに置く
export API_BASE_URL="https://api.example.com"
export API_TOKEN_READONLY="***"
この作業では API_BASE_URL と API_TOKEN_READONLY だけを使ってください。
.env や他の設定ファイルは変更しないでください。
必要なら、まず一覧取得だけして、結果を短く整理してください。
DB の変更を伴う作業は、さらに一段しぶとくする。いきなり UPDATE や DELETE を実行させない。先に「対象件数の確認」「影響範囲の SELECT」「必要ならトランザクション内での実行」の順に分ける。これをやらないと、条件の甘い WHERE で一気に広く触る。人間でもやりがちなミスだが、エージェントに任せるとスピードが出るぶん、事故も速い。
頼み方はこうなる。
次の順で進めてください。
1. 変更対象を SELECT で確認する
2. 影響件数を示す
3. 私が確認したあとにだけ UPDATE を提案する
4. 実行する場合はトランザクションを使う
DELETE は提案しないでください。
まずは読み取りだけで十分です。
ここで大事なのは、「実行していいこと」と「提案まで」に線を引くことだ。Claude Code に考えさせるだけならまだいいが、勝手に実行まで行くと話が変わる。操作の前に差し戻しポイントを作っておくと、レビューがかなり楽になる。
外部 API で特に注意したいのは、レスポンスをそのまま全部貼らせないことだ。ログイン情報、個人情報、内部 ID、長い HTML、巨大な JSON はすぐにコンテキストを汚す。必要なのは「何件あったか」「異常値はあるか」「キーの名前は何か」くらいで済むことが多い。要約だけ返させる癖をつけるといい。
レスポンス全文は貼らないでください。
件数、主なフィールド名、気になる差分だけを箇条書きで出してください。
機密っぽい値は伏せてください。
これは非エンジニアの作業でも同じだ。たとえば、請求書や契約書の整理を Claude Code に手伝わせるなら、外部の文書管理サービスやDBに接続しても、まずは「一覧の整理」「重複候補の抽出」「古いものの候補出し」までに留める。削除や移動は最後に人間が確認する。ファイル整理は一見安全そうだが、実際は「似た名前の別ファイルを消す」が一番やばい。DB も同じで、似た値をまとめて更新するのは危険だ。
もうひとつの勘所は、Claude Code に「監査しやすい形で」動いてもらうことだ。何を参照し、何を変更したかが追えるように、作業前後の差分を残す。SQL なら実行予定のクエリを先に出させる。API ならエンドポイント名と取得条件を先に書かせる。ファイルなら変更前の一覧と変更後の一覧を分ける。あとで見返したとき、何が起きたか分からないのがいちばん困る。
実行前に、次を必ず出してください。
- 使う API エンドポイント
- 使う認証情報の種類
- 取得件数の上限
- 変更がある場合は対象レコードの条件
- 実行後に確認すべき点
この手の作業でありがちな失敗は、権限を絞ったつもりで実は絞れていないことだ。たとえば、読み取り専用のつもりが、同じトークンで別の管理 API にも届く。DB でも、参照専用ユーザーなのにビュー経由で予想外の情報が見えることがある。だから「アプリ側の指示」だけで安心しないで、外部側の権限設定も確認する必要がある。Claude Code は賢いが、権限の境界そのものを保証してくれるわけではない。
実用上は、作業を二段階に分けるのがいちばん堅い。第一段階では、Claude Code に調査と提案だけをさせる。第二段階で、人間が確認したうえで実行させる。これだけでかなり事故が減る。雑に全部を一気通貫でやらせると、速いが荒い。外部 API や DB みたいに副作用のある相手には、その速さは毒だ。
最後に、迷ったらこう考えるといい。Claude Code に渡すのは「権限」ではなく「手順」だ。権限は最小限、手順は細かく、出力は要約中心。これが守れていれば、外部 API でも DB でもかなり安全に触らせられる。逆にここを外すと、あとでログを追いながらため息をつくことになる。そういう手戻りは、だいたい最初の一文で防げる。