§この章がなぜ必要か
- APIキーはコードに書かない
- プラットフォーム側で月次上限
- 予期しない従量課金を止める
- public リポジトリを作らない
- 一人運用は個人アカウントで可
- チームは Organization で作成禁止
AIコーチングの現場で、私（コーチ側）がいちばん血の気が引く瞬間があります。それは、経営者の画面を横から覗いたときに、APIキーが平然とメモ帳やチャットのメッセージ、GitHub上の設定ファイルに貼り付けられているのを見つけた瞬間です。
実際、ある事業会社の経営者のPCを一緒に触っていたときに、メモ帳のトップに sk-ant-api03-… から始まる文字列が丸ごとコピーされているのを発見し、その場でチャットを止めて「一旦深呼吸してください、これは今すぐ差し替えます」と作業を切り替えたことがあります。放っておけば、翌朝までに数十万円の請求が飛んできても不思議ではない状態でした。
なぜAIの現場でこの手の事故が多発するのか。理由は単純で、AIは「便利さの最短距離」を提案してくれる道具だからです。「APIキーをそのまま貼り付ければ動きます」「GitHubに上げれば共有できます」──AIはそう教えてくれますが、そこに潜むリスクの重み付けは、経営者側にもエンジニア側にも見えにくい。
しかも、AI導入が本格化するほど、扱うキーの数もリポジトリ（コードの保管場所）の数も、触るメンバーの数も指数関数的に増えていきます。導入初期に事故を防ぐ骨格を作っておかないと、後から回収するコストは10倍以上になります。
この章では、私がコーチング現場で「これだけは絶対にやってください」と口を酸っぱくして伝えている、2つの最重要ガバナンスを扱います。ひとつはAPIキーと環境変数の扱い方、もうひとつはGitHubをPrivateで締めることです。両方とも、地味です。派手なAI活用術ではありません。でも、この2つを飛ばして「10名にAIを配ろう」と走った先には、必ず事故が待っています。逆にここを固めてしまえば、あとは安心して攻めに回れます。
§9-1 APIキーは.envに閉じ込め、金額に上限をかける
このAPIキーを扱う上での鉄則は、たったひとつです。
§解説
Claude Code や各種AIツールを本格的に使い始めると、必ずAPIキーというものが登場します。APIキーというのは、AIサービスに「これは私です」と証明するための長い文字列です。銀行のキャッシュカードと暗証番号がひとつに合体したもの、と思ってください。持っている人は、あなたのアカウントの残高（クレジット）を自由に使えます。
このAPIキーを扱う上での鉄則は、たったひとつです。「テキストファイルにベタ貼りしない」。メモ帳、Word、チャットのDM、スプレッドシートのセル、READMEファイル──どこであれ「人間が普通に読めるかたちで書いてある」状態を作ってはいけません。
理由は明快で、ハッカーが自動プログラムで24時間365日、ネット上を巡回して「それらしい文字列」を探し続けているからです。GitHub（後述するコードの保管場所）にうっかり上げようものなら、公開から数分でキーが盗まれ、あなたの知らないところで数十万円分のAPI呼び出しが走ります。
正しい保管方法は「.env（ドットイーエヌブイ）ファイル」を使うことです。.envというのは「環境変数」を書き込む専用のファイルで、プロジェクトのフォルダの中にひとつだけ置いておきます。Claude Code はプログラムを動かすときに、このファイルから自動でキーを読み込みます。
人間がキーを目にする機会は最初に貼り付けた1回だけ、あとはずっとファイルの中で眠っている状態になります。しかも、.env ファイルは「GitHubには絶対にアップロードしない」設定（.gitignore への追加）を最初にしておけば、外に漏れるルートが物理的に塞がれます。
もうひとつ、必ずセットで設定してほしいのが「利用上限金額」です。Anthropic の管理画面（Console）や OpenAI の管理画面には、月あたりの利用上限額を数字で設定できる項目があります。初期は小さめの金額、慣れてきたら段階的に、フルに使い出したらさらに引き上げる、といった具合に、事業のフェーズに合わせて上げてください（数字の目安は事業規模で変わるので、月末の請求額と相談しながらで構いません）。
これを設定しておくと、万が一キーが漏れても、被害は上限額でストップします。上限をかけずにキーだけ発行するのは、口座に暗証番号を貼って街に置いておくのと同じです。
そしてここが、経営者にとって一番きついポイントです。「AIにどこまで情報を渡していいか」という境界判断は、ビジネス側だけでは絶対にできません。「顧客の氏名は？」「請求書のPDFは？」
「社内Slackのログは？」──これらをAIに渡していいかどうかは、技術的なリスク（キーの持ち出し・学習データへの混入・第三者への漏洩経路）を理解した人間の目が必要です。だから私は、AI導入初期の経営者には必ず「エンジニアかそれに近い人を横に置いてください、社外の人でも構いません」と伝えています。判断を全部自分で背負い込むのが、いちばん危ないのです。
§引用
「AIに渡しちゃいけない情報の境界判断はビジネス側だけだと不可能」
§9-2 GitHubはPrivate徹底。チーム運用なら組織化
AI業務の実務では、この Public 設定が「最も危険なスイッチ」になります。
§解説
APIキーを .env に閉じ込めても、まだ穴があります。それが GitHub（ギットハブ）です。GitHub というのは、簡単に言えば「プログラムコードの保管庫（＝リポジトリ）」を、インターネット上に置けるサービスのことです。
書いたコードを預けたり、複数人で共有したり、履歴を残したりする用途で使います。プログラムコードを保管する1つの箱を「リポジトリ」と呼び、以下でも何度か登場します。エンジニアなら誰でも使っていて、そしてこれが、AI時代における最大の情報漏洩ポイントになります。
なぜか。GitHub のリポジトリにはデフォルトで「Public（パブリック＝全世界に公開）」という設定があります（対義語は「Private（プライベート＝招待した人だけが見られる）」）。Publicは、もともと「オープンソース文化」──ソースコードを世界中に無償で公開し、みんなで改良していく開発文化──から生まれた仕組みで、コードを世界中に見せることを"良いこと"としてきた背景があります。
ところが、AI業務の実務では、この Public 設定が「最も危険なスイッチ」になります。なぜならAIの実装コードには、APIキー、ログイン情報、顧客データベースの接続文字列、業務ルールを書いた rules ファイルなど、外に出したら即事故になるものが混ざりやすいからです。しかも AI 系のコードは差し替えが激しく、うっかりコミット（作業内容を保存する操作）してしまった1回で全部が公開されます。
ですから、対策の本質はひとつです。パブリックにしない。ここだけは規模を問わず全員に当てはまります。その上で、どう実装するかは「何人で触るか」で変わります。
個人事業主・一人運用の場合は、個人アカウントのままで構いません。やることは2つだけです。ひとつは、新規にリポジトリを作るたびに Private を選ぶこと。もうひとつは、既存のリポジトリ一覧を開いて「Public」表示のものが1つも残っていないか確認することです。組織を作る必要はありません。ここを毎回確認する習慣がつけば、一人運用のリスクはほぼ塞げます。
会社・チームで複数人が触る場合は、これが人の記憶頼みでは破綻します。誰か1人が1回 Public のまま作れば終わりだからです。だから設定で機械的に塞ぎます。
ひとつめは「GitHub 組織（Organization、オーガニゼーション）を作る」。Organizationとは、GitHub上に会社やチームの単位でメンバーとリポジトリをまとめて管理するための入れ物です。個人アカウントに直接リポジトリを作るのをやめて、事業体（法人）としての組織を GitHub 上に立てます。
ふたつめは「その組織のデフォルト設定を Private only にする」。組織の設定画面で、パブリックリポジトリの作成そのものを禁止できます。三つ目は「メンバーの個人アカウントでのパブリックリポジトリ作成も業務規程で禁止する」。技術で塞げる部分と、ルールで塞ぐ部分の両方が要ります。組織化は目的ではなく、「パブリックにしない」を人数が増えても守り切るための手段だと理解してください。
さらに、ディレクターや業務委託メンバーが10名を超え始めたら、案件ごとにAPIキーを別発行してください。同じキーを全員で共有するのは、鍵をひとつだけ作って全員にコピーを渡す寮の運用と同じです。誰かがそれをどこかに貼ったら全員のキーが死にます。
案件別・メンバー別に発行しておけば、事故が起きたときに「そのキーだけ即無効化」で被害を局所化できます。テスト用アカウントには「金額に触れない権限」を設定するのも同じ思想です。権限を先に絞ることで、事故のダメージを構造的に減らせます。
最後に、AI補助の「オートモード」や「危険な権限スキップ機能」（Claude Code で言えば --dangerously-skip-permissions。Claude Code が「本当に実行していいですか？」と聞いてくる確認画面を全部スキップして、AIに実行を任せきりにするオプションです）は、10名展開のフェーズでは使わないでください。名前どおり危険だからそう呼ばれているのです。
具体例を挙げます。AIが rm（ファイル/フォルダを消すコマンド）を提案してきたときに、確認画面で反射的に Yes を押す癖がついていると、ある日、AIが「作業フォルダ丸ごと削除」を提案し、その1回で数ヶ月分の議事録や顧客データが復旧不能の状態で消えます。実際、これに近い事故は現場で何度も見ています。「確認を面倒がらない文化」を、ガバナンスとして育てる必要があります。
§引用
「GitHubに上げちゃったら最悪。APIキー/トークン周りの管理が一番のリスク」