Claude Code や Codex のようなを使う開発者が増えています。こうしたツールは、チャット画面で答えを返すだけのAIと違い、パソコンの中で実際にファイルを書き換え、コマンドを実行します。動くときの権限は、そのパソコンにログインしている開発者本人の権限です。開発者が見られるソースコード、使えるパスワードや鍵、つなげるサーバーには、AIも同じように届きます。
そうなると、会社が考えるべきことが1つ増えます。開発に使うパソコンを誰が持ち、何を入れ、どこにつなげてよいことにするかです。個人のパソコンや、メールもネット閲覧も開発も1台でこなすパソコンにAIコーディングツールを入れると、どこか1か所から悪い指示が入ったとき、AIはその指示に従って、開発者の権限のまま動いてしまいます。経営者や情報システムの担当の方が、開発端末のルールを決めるときの考え方をまとめました。
開発環境は、個人のパソコンや仕事とプライベートを兼ねたパソコンに入れないでください。会社が用意した開発専用の端末に、必要な開発ツールだけを入れ、利用者が他のソフトを入れられないようにします。ソースコードは GitHub の会社のアカウントで扱い、本番のデータベースに入れる人はごく少数に絞ります。それ以外のメンバーはサーバーにログインできない状態にしておくと、AIが乗っ取られても、届く範囲はそのメンバーが触れるコードまでに収まります。
この記事の調べ方
AIコーディングツールの権限の仕組みは、Anthropic の Claude Code の公式ドキュメント(セキュリティ、サンドボックス、開発用コンテナ)と、OpenAI の Codex の公式ドキュメント(承認とセキュリティ)を根拠にしました。悪い指示の入り方は OWASP の生成AI向けのリスク一覧を、実際の事件は Nx の開発元が公表した事後報告を参照しています。端末で動かせるソフトの制限は Microsoft と Apple の公式ドキュメント、ソースコードの権限は GitHub の公式ドキュメントによります。記事で勧める構成は、一式で組んで試していません。Windows のアプリ制限や MDM による配布も、この記事のためには試していません。
AIコーディングツールは、開発者と同じ権限でパソコンを動かす
AIコーディングツールがどこまでのことをするかは、ツールの設定で決まります。Claude Code の公式ドキュメントによると、手動で承認するモードでは、最初は読み取りだけが許され、ファイルの編集やコマンドの実行の前に毎回利用者へ確認します。一方で、対話して使うときの初期設定は自動モードで、利用者の代わりに別のAIのモデルが操作を点検し、危ないと判断したものを止める仕組みになっています。同じドキュメントには、手動で承認するモードでも、人が承認したコマンドは、その利用者のアカウントが書き込める場所ならどこにでも書き込めると明記されています。
Codex も考え方は似ています。OpenAI の説明では、読み取りだけを許すモード、作業中のフォルダの中なら編集とコマンドの実行を自動で行うモード、制限も承認もないモードの3つがあり、初期設定ではネットワークへの接続が切られています。作業中のフォルダの外を編集するときや、ネットワークにつなぐコマンドを動かすときは、利用者に承認を求めます。ただし、制限のないモードを選べば、こうした歯止めは外れます。
AIコーディングツールの安全は、ツールの設定だけでなく、そのツールを動かすパソコンの中身にも左右されます。ツールの設定を厳しくしても、開発者が承認ボタンを押せば、AIは、そのパソコンで開発者ができる操作をすべて実行できます。パソコンに会社の全サーバーへの鍵が入っていれば、承認1回でそこまで届きます。パソコンに開発に要るものしか入っていなければ、同じ承認1回でも届く範囲は狭く済みます。
悪い指示は、リポジトリやWebページやメールに紛れて届く
AIコーディングツールでは、開発者の依頼とは別の悪い指示が、AIの読む資料に紛れて届くことがあります。この攻撃はと呼ばれます。生成AIのリスクをまとめている OWASP は、Webサイトやファイルなど外から取り込んだ入力を通じて起きるものを、間接的なプロンプトインジェクションとして分けています。AIに調べ物をさせたWebページ、取り込んだ他人のリポジトリの説明文、要約させたメールの本文が、そのまま入口になります。
Codex のドキュメントも、プロンプトインジェクションによって、AIが信頼できない指示を取りに行き、それに従ってしまうおそれがあると注意を促しています。Claude Code のドキュメントは、信頼できない内容を扱うときは、スクリプトの実行やツールの呼び出しをの中で行うよう勧めています。2社とも、AIが読む文章から悪い指示が入りうることを前提にしています。
もう1つの入口は、パソコンに入り込んだ悪いプログラムです。2025年8月26日、JavaScript の開発で使われる Nx という道具に悪いコードを仕込んだものが、npm(JavaScript の部品の配布所)に公開されました。開発元の事後報告によると、開発元の公開用の鍵が盗まれて使われたもので、約4時間後に取り下げられています。インストール時に動くこのコードは、パソコンの中の機密情報を探し、そのパソコンに入っていた Claude や Gemini などのAIツールを使おうとしました。開発元のセキュリティ情報では、インストールした人のパソコンのファイルを調べて認証情報を集め、その人自身の GitHub アカウントの下に作ったリポジトリへ書き出したとされています。開発に使うパソコンにAIツールと鍵が一緒に入っていると、悪いプログラムがその両方を使えてしまう例です。

図の上の段にある4つの入口のうち、Webページとメールは、開発以外の用途にパソコンを使うほど増えます。個人のメールを読み、業務と関係のないサイトを開き、家族と共用しているパソコンなら、入口の数は会社では数えきれません。図の下の段のように、開発専用の端末に分けて、本番サーバーへの線を最初から引いておかなければ、悪い指示が入っても届く先はそのパソコンの中に限られます。
ツール側の守りは強くなったが、パソコンの中身までは守れない
AIコーディングツールの側にも、守りの仕組みは増えています。Claude Code には、AIが動かすコマンドをの中で動かす機能があります。公式ドキュメントによると、macOS では OS に組み込まれた Seatbelt、Linux では bubblewrap という仕組みを使い、書き込める場所と接続できる相手を絞ります。Codex も、macOS、Linux、Windows のそれぞれで、OSの仕組みを使って制限をかけると説明しています。
ただし、公式ドキュメントには限界も書かれています。Claude Code のサンドボックスは初期設定では切れていて、利用者が自分で入れる必要があります。入れた場合でも、初期設定では、パソコンの大部分を読めます。読める範囲には、サーバーにつなぐための鍵(~/.ssh)やクラウドの認証情報のファイルも含まれると、同じページに明記されています。囲われるのはシェルのコマンドだけで、AIのファイル操作の道具や、追加で組み込んだ外部の連携ツールは囲いの外で動きます。Windows でそのまま使うとサンドボックスは働かず、WSL2 の中で動かす必要があります。
についても、Claude Code のドキュメントは注意点を挙げています。承認を省く設定で動かした場合、悪意のあるプロジェクトがコンテナの中にあるものを外へ持ち出すことは防げません。そのため、信頼できるリポジトリでだけ使い、サーバーの鍵やクラウドの認証情報のファイルをコンテナに持ち込まず、使えるリポジトリが限られた鍵や、短期間で切れる鍵を使うよう勧めています。
| 守りの仕組み | 何を防げるか | 公式ドキュメントが書いている限界 |
|---|---|---|
| 承認の確認(Claude Code・Codex) | ファイルの編集やコマンドの実行の前に、人が止められる | 一度承認したコマンドは、利用者の権限でできることを全部できる |
| サンドボックス(Claude Code) | 書き込める場所と接続先を絞れる | 初期設定では切れている、入れても鍵のファイルを含めて大部分を読める、シェルのコマンドしか囲わない |
| サンドボックス(Codex) | 初期設定でネットワークにつながない | 制限のないモードを選べば外れる |
| 開発用コンテナ | AIの作業をパソコン本体から切り離せる | 承認を省く設定では、コンテナの中のものの持ち出しを防げない |
表の右の列を見ると、どの仕組みも「そのパソコンや入れ物の中にあるものは守りきれない」という点で共通しています。ツール側の守りは使うべきですが、それだけで十分とは言えません。守りきれない部分は、パソコンの中に置くものを減らし、つなげる先を減らして小さくします。ここから先は、そのための端末の分け方と権限の分け方です。
推奨する構成は、会社が用意する開発専用の端末
1台のパソコンで開発もメールもネット閲覧もできるのは便利です。その半面、開発の道具と、外から文章が届く道具が同じパソコンに入ることになります。AIコーディングツールはその両方に触れられるので、開発に使う端末をほかの用途と分けて考える必要が出てきます。
はてなベースが勧めるのは、次の表の構成です。端末の用意には費用がかかりますが、ほかの項目は、特別な製品を買わずに、アカウントの作り方と運用の決まりを変えれば始められます。
| 決めること | 推奨する形 | 防げること |
|---|---|---|
| 端末 | 会社が開発専用に用意し、個人のパソコンや事務作業と兼ねるパソコンでは開発しない | 開発と関係のないソフトやデータが、AIの届く範囲に入らない |
| 入れるソフト | 開発に要るツールだけを会社が入れ、利用者は他のソフトを入れられない | 出どころの分からないソフトや拡張機能から、悪い指示が入りにくい |
| 用途 | 個人のメールやネット閲覧、私用のチャットには使わない | 悪い指示が届く入口が減る |
| ソースコード | GitHub に会社のアカウントで入り、本番に出すコードは他の人の確認がないと取り込めない | AIが書いた不正な変更が、そのまま本番に出ない |
| 本番のサーバーとデータベース | 入れる人をごく少数に絞り、それ以外のメンバーはログインできない | 開発メンバーの端末が乗っ取られても、本番には届かない |
| パスワードや鍵 | できるだけ開発端末に置かず、置くなら短期間で切れるものにする | 端末から持ち出されても、使える期間と範囲が限られる |
表の2行目の「利用者が他のソフトを入れられない」状態は、OSの機能で作れます。Windows では、Microsoft が App Control for Business と AppLocker という2つの仕組みを用意しており、どちらも、その端末で動かしてよいアプリを会社が決められます。Microsoft は、使える環境なら App Control for Business を選ぶよう勧めていて、Intune のようなで配れるとしています。Mac には、ダウンロードしたソフトを App Store のものか、Apple に登録された開発者の署名があるものに限る Gatekeeper という仕組みがあります。Apple の説明では、利用者はこの制限を外して開けますが、MDM で管理すれば外せないようにできます。ただし、これは動かしてよいアプリを1つずつ決める仕組みとは違います。Mac でどこまで絞れるかは、使う MDM の製品で確かめてください。
表の3行目は、仕組みよりも運用の決まりです。開発専用の端末では、個人のメールアカウントにログインしない、業務と関係のないサイトを開かない、AIに調べ物をさせるときは信頼できる公式のページに限る、といった決まりを、配るときに書面で渡しておきます。ネット閲覧を完全に止めると開発ができないので、決まりを設けて悪い指示が入る経路を減らします。
社外秘の度合いが高い開発では、表の構成に加えて、開発端末を社外につながない方法もあります。外部のAIサービスに接続せず、社内のサーバーで動かすを使い、開発端末ごと社外とつながらないネットワークに置く形です。性能や費用は外部のサービスと比べて決める必要がありますが、ソースコードを社外のAIサービスに送らない形にできます。
本番に入れる人を絞り、コードの権限とサーバーの権限を分ける
開発端末を分けても、その端末から本番のサーバーやデータベースに入れるのなら、届く範囲はあまり狭くなりません。そこで、ソースコードを書く権限と本番のサーバーに入る権限を分けます。ほとんどのメンバーには、GitHub のリポジトリに変更を送る権限だけを渡し、本番のサーバーにはログインできない状態にします。本番のデータベースを直接見られる人も、ごく少数に限ります。

図の一番上の開発メンバーは、GitHub のリポジトリまでしか届きません。GitHub のを使うと、決められた人数の承認を受けた変更しか、本番に出すブランチに取り込めないようにできます。GitHub の説明によると、そのブランチへ直接変更を送れる人やチームを限ることもできます(この設定は、公開しているリポジトリか、有料の Team 以上の契約で使えます)。AIが書いたコードも、人の確認を通らないと本番に出ません。ただし初期設定では、リポジトリの管理者はこの制限を受けません。管理者にも制限をかける設定を入れ、管理者の人数も絞っておきます。
本番のサーバーとデータベースに入る人は、普段の開発と本番の作業で端末かアカウントを分けるのが理想です。AIコーディングツールを動かす端末に、本番のデータベースの接続先とパスワードを置かないようにします。本番に出す作業は、GitHub に取り込まれたコードを自動で配る仕組みに任せれば、人が本番のサーバーに入る回数そのものを減らせます。
権限を分けておく考え方は、AIに限った話ではありません。同じシリーズの「乗っ取られても全部は取られない設計」では、サーバーの中で権限を分ける方法を書いています。開発端末の分離は、同じ考え方を人とパソコンの側に当てはめたものです。シリーズの全体の流れは「オープンソースの時代は終わるのか」にまとめています。
退職のとき、記録の残し方、お客様や監査への説明
端末と権限を分けたら、人が入れ替わるときの手順を決めておきます。メンバーが退職したり、外部の開発者の契約が終わったりした日には、まず GitHub の組織から外し、本番に入れる人であれば本番のアカウントと鍵を止めます。そのあと開発専用の端末を回収し、中身を消してから次の人に渡します。個人のパソコンで開発していると、この回収ができず、手元に残ったソースコードや鍵を消したかどうかを会社が確かめられません。社外から来て現場で開発する技術者(FDE)を迎えるときのアカウントの出し方と止め方は、「FDE を迎える前に情シスが用意するもの」に順番を書いています。
記録は、あとで何が起きたかを確かめるために残します。GitHub の組織の監査ログには、誰が、いつ、どの操作をしたかが残ります。Claude Code を組織で使う場合、会社は利用の状況を OpenTelemetry という仕組みで集められ、会社がまとめて決めた設定を各端末に配れると公式ドキュメントに書かれています。開発用コンテナのページによると、この設定を MDM などで届ければ、開発者がリポジトリの中のファイルを書き換えても外せません。本番のデータベースへの接続の記録も、入れる人が少なければ見返しやすくなります。
お客様や監査の担当者に開発の体制を説明するときも、この分け方がそのまま説明の材料になります。体制を整えたら、例えば次の4点を伝えられます。
- 開発は会社が用意した専用の端末だけで行い、端末で動かせるソフトは会社が決めている
- ソースコードは会社のアカウントで管理し、本番に出す変更は他の人の確認を通している
- 本番のサーバーとデータベースに入れるのは決まった少数の人だけで、その記録を残している
- 人が抜けるときは、その日のうちにアカウントを止め、端末を回収している
4点のどれも、「AIをどう使っているか」より前の、人と端末と権限の話です。AIコーディングツールを使っていることを説明するときも、どのツールを使うかより、そのツールがどこまで届くかを示すほうが、相手は判断しやすくなります。AIに作らせた社内ツールを公開する前の確認は、「公開前に確かめる7項目」にまとめています。
明日から始めるなら、この順番で
全部を一度にそろえる必要はありません。危ないところから順に手を付けると、短い期間で届く範囲を狭くできます。はてなベースが勧める順番は次のとおりです。
- 個人のパソコンで開発しているメンバーがいないか、まず数える
- 本番のサーバーとデータベースに入れる人を一覧にし、必要な最小限の人数まで減らす
- GitHub の本番に出すブランチに、確認なしの取り込みを禁じる設定を入れる
- 開発端末に置いているパスワードや鍵を洗い出し、置かなくて済むものから外す
- 開発専用の端末を用意し、入れるソフトを決めて、利用者が追加できない設定で配る
- 退職と契約終了の日の手順を書き、次の入れ替わりで試す
1つ目から4つ目は、新しい機材を買わずに今週から始められます。5つ目の端末の用意には費用がかかりますが、2つ目から4つ目が済んでいれば、端末が乗っ取られても、本番には届きにくくなっています。AIの利用ルール全体を決めるときは、「中小企業の生成AI運用ルール」も参考にしてください。
AIコーディングツールを止める理由はありません。開発の速さは確かに上がっています。そのうえで、AIが開発者の権限で動くことを前提に、そのパソコンに何を入れ、どこにつなげるかを会社が先に決めておきます。開発端末と本番の権限を分けておけば、AIコーディングツールを使う人が増えても、本番に届く人数は少ないまま変わりません。
AIを安全に使うための社内ルールと仕組みづくりをお手伝いします
開発端末の分け方、GitHub と本番の権限の整理、退職時の手順、お客様や監査への説明資料まで一緒に整えます。