意図しない課金を止める — AIに外部APIを触らせない線引きを決める

生成AIに作業を任せていると、頼んでいない機能まで作ってくれることがある。それが外部サービスを呼ぶコードだった場合、動いた瞬間から課金が始まる。この章では、何を禁止し、どこから先は必ず人間に確認させるかを決める。作るファイルは1つで、書く量は50行に満たない。

目次

---

1. 何が起きるのか

生成AIは、指示された目的を達成する方法を自分で選ぶ。ここが便利なところであり、同時に危ないところになる。

たとえば「投稿の下書きを毎週作りたい」と頼んだとする。こちらが想定しているのは、手元のファイルを読んで文章を書き出すところまでである。ところがAIは、そこから一歩進めて「投稿まで自動化した方が便利だ」と判断することがある。

その結果、次のようなコードが混ざる。

• X(旧Twitter)へ自動投稿するために、X APIを呼ぶ処理
• 文章の推敲のために、別の生成AI APIを呼ぶ処理
• 画像を作るために、画像生成APIを呼ぶ処理

API(Application Programming Interface)は、外部のサービスをプログラムから呼び出す窓口になる。多くは従量課金で、呼んだ回数や処理した文字数に応じて料金が発生する。

厄介なのは、これらが「親切」として足されることである。悪意も間違いもない。頼んだ目的から見れば理にかなっている。だから、こちらが読み飛ばすと通ってしまう。

そして一度動き始めると、止めるまで課金が続く。ループ処理の中に入っていれば、1回の実行で数百回呼ばれることもある。

この事故は、性能の良いAIほど起きやすい。 気を利かせる範囲が広いためである。

2. どう決めたか

ルールは3つの部分でできている。

基本方針:原則として作らせない

外部の有料API(またはAPIキー・認証情報を必要とする外部サービス)を呼び出すコードは、ユーザーからの明示的な依頼がない限り新規作成しない。

ここで大事なのは、禁止の対象を「有料API」ではなく「認証情報を必要とする外部サービス」まで広げていることである。無料枠があるサービスも、認証情報を登録した時点で課金経路ができる。無料か有料かの判断をAIにさせない。

続けて、判断の余地を潰す一文を置く。

「あると便利そうだから」「自動化できそうだから」という理由だけで、X API・OpenAI API・その他生成AI APIなどを呼ぶ実装を追加しない。

これは1章で挙げた「親切として足される」場面を、そのまま名指しで禁止している。

標準の運用を明記する

禁止だけを書くと、AIは代わりの方法を探して迷う。そこで、このプロジェクトでは何が普通なのかを書く。

このプロジェクトの標準運用は、X投稿・記事作成ともに手動コピー&手動投稿(ブラウザ操作)を前提とする。CSV出力・ファイル読み書きなど、ローカルで完結する処理は対象外(問題なし)。

「手でコピーして貼る」が正式な運用だと宣言している。これがないと、AIは自動化しないことを不備とみなして、別の抜け道を提案してくる。

あわせて、やってよいことを具体的に書いておく。ファイルの読み書き、CSVの書き出しといったローカルで完結する処理は制限しない。ここを書かないと、萎縮して何も作れなくなる。

例外を通すときの条件

外部APIが本当に必要になる場面はある。そのときは、実装前に3つを確認させる。

そして、確認しないまま書き始めることを禁じる一文を添える。

確認・合意なしに、requests・fetch・各種SDK経由での外部API呼び出しコードを書き始めない。

requests や fetch という具体名を出しているのは、判断ではなく検知にするためである。「外部API呼び出しかどうか」は解釈が要るが、「requests を使っているか」は見れば分かる。

3. なぜ「原則禁止」から始めるのか

逆向きの書き方もありえた。「課金が発生する場合は確認する」という形である。こちらを採らなかった理由がある。

課金が発生するかどうかの判断を、AIに委ねることになるため。

無料枠の範囲内か、従量課金がいつから始まるか、自分のアカウントがどのプランかは、コードを書く側からは分からない。判断させれば、判断を誤ることがある。しかも誤りは、請求が来るまで表面化しない。

原則禁止にすると、判断そのものが不要になる。外部を呼ぶなら止まる。それだけになる。

止まったときのコストが小さいことも理由になる。禁止しすぎて止まっても、こちらが「これは許可する」と言えば済む。失うのは数十秒である。逆方向の失敗は、金額と、気付くまでの時間の両方を失う。

損失が非対称なときは、小さい方の失敗に倒す。

4. 短いルールでよい理由

このルールは、他の3つと比べて明らかに短い。50行に満たず、条文と呼べるものは基本方針の3行と確認事項の3項目しかない。

目的が1つしかないためである。このルールが防ぎたいのは「気付かないうちに課金が始まること」だけになる。守備範囲が1つなら、書くことも1つで足りる。

ルールを長く書きたくなったときは、目的が増えていないかを疑うとよい。「ついでにセキュリティも」「ついでにコードの品質も」と足していくと、読まれなくなる。読まれないルールは、無いのと同じになる。

短さには実利もある。AIに毎回読ませても負担にならない。長い資料は「必要なときだけ読む」運用になりがちだが、事故を防ぐルールは常に効いていないと意味がない。

適用範囲だけは明記しておく。どのファイルを触るときに効くのかが曖昧だと、範囲外だと解釈される。

• スクリプト全般
• 新しく作る自動化の仕組み
• その他リポジトリ内で新規に書くコード

5. 自分で作る手順

自分の作業フォルダーに同じものを置くまでの手順になる。全部で4ステップ、15分ほどで終わる。

手順1:ルールを置くフォルダーを決める

作業フォルダーの直下に rule/ のようなフォルダーを1つ作り、その中に 有料API利用ルール.md を置く。

名前は何でもよいが、ルール専用のフォルダーにする。他の資料と混ざると、AIに「ルールだけ読んで」と指示できなくなる。

手順2:禁止する範囲を書く

ファイルの冒頭に、何のためのルールかを1行で書く。その後に基本方針を書く。

# 有料API利用ルール

「気が付いたら有料のAPIを触っていた」という事故を防ぐためのルール。

## 1. 基本方針

- 外部の有料API(またはAPIキー・認証情報を必要とする外部サービス)を
  呼び出すコードは、ユーザーからの明示的な依頼がない限り新規作成しない。
- 「あると便利そうだから」「自動化できそうだから」という理由だけで
  実装を追加しない。

冒頭の1行を省かない。 ここが「何のためのルールか」を示すため、判断に迷ったときの基準になる。条文に書いていない事態が起きたとき、AIはこの目的から推測する。

手順3:標準の運用と、やってよいことを書く

自分の作業では何が普通なのかを書く。ここは人によって変わる。

- このプロジェクトの標準運用は、手動コピー&手動投稿(ブラウザ操作)を前提とする。
- CSV出力・ファイル読み書きなど、ローカルで完結する処理は対象外(問題なし)。

続けて、例外を通すときの確認事項を3つ書く。2章の表をそのまま使ってよい。

手順4:AIが必ず読む場所から参照する

ルールを書いただけでは読まれない。AIが会話の最初に必ず読むファイルから、このファイルへの案内を置く。

Claude Codeであれば CLAUDE.md がその役割を持つ。そこに1行足す。

- 外部APIを呼び出すコードを実装する → rule/有料API利用ルール.md
  (明示依頼がない限り新規実装しない)

括弧の中に結論を書いておく。 リンクだけだと、AIは「関係ありそうなときだけ開く」判断をする。結論が見えていれば、開かなくても方針は伝わる。

動いているかの確かめ方

ルールが効いているかは、試せば分かる。新しい会話で、外部サービスを使いたくなるような依頼をしてみる。

「毎週の投稿をまとめて、自動で投稿できるようにしたい」

止まって「外部APIを使う必要がありますが、ルールにより確認が必要です」といった応答が返れば効いている。何も言わずにコードを書き始めたら、手順4の参照が届いていない。

次のページ

ここまでで、外部サービスとの境界線が引けた。課金という取り返しのつかない事故は、これで止まる。

次に扱うのは、自分の作業フォルダーの中になる。資料が増えてくると、AIも自分も「このファイルは何を書く場所だったか」を見失う。「資料の書き方をそろえる — AIが1ファイルで迷わない冒頭と目次を決める」では、1ファイルの冒頭に何を書き、何を書かないかを決める。開いた瞬間に役割が分かる状態を作る。

← ⓪ 全体像 ｜ 次:② 資料の書き方をそろえる →