Claude Codeで業務ツールを作るときの注意点—チャット型AIとは別のリスクがある

生成AIの社内ルールは「機密情報を貼り付けない」を中心に作られていることが多い。チャット型を前提にすれば、それで妥当だ。ただしClaude Codeのようにファイルを直接読み書きするツールを使い始めると、この前提が崩れる。貼り付けていなくても、フォルダの中身は読まれている。この記事では、何が違うのか、業務で使うなら何を決めておくのかを整理する。

チャット型と何が違うのか

チャット型の生成AIは、こちらが貼り付けたテキストしか見ない。だから「貼らない」というルールが有効に機能する。

Claude Codeのような開発支援ツールは、動作の前提が違う。許可した範囲のファイルを自分で開いて読み、必要ならコマンドを実行し、ファイルを書き換える。これが便利さの理由であり、同時に注意点が変わる理由でもある。

つまり、決めるべきことが「何を貼らないか」から「何を見せるか、何をさせるか」に移る。ルールの作り方そのものが変わる。

観点1｜見せるフォルダの範囲

最も重要で、最も簡単に対策できるのがこれ。起動する場所を間違えない、それだけだ。

デスクトップやドキュメントフォルダの直下で起動すると、そこにある全部が読める範囲に入る。顧客リストのExcel、経理の資料、他社との契約書。作業には一切関係ないものまで含まれる。

• 作業用のフォルダを新しく作り、その中だけで動かす。これが基本
• 作業に必要なファイルだけ、そのフォルダにコピーして持ち込む
• 共有ドライブの直下では起動しない。他部署のファイルまで範囲に入る

フォルダを分けるだけで、見せてはいけないものを見せる事故はほぼ防げる。ルールとしても簡単で、非エンジニアにも守れる。

観点2｜実行させる操作

この種のツールはコマンドを実行できる。ファイルの削除、外部への通信、インストール。便利だが、業務PCで動かす以上は線を引いておく。

• 削除を伴う操作は、実行前に内容を読む。提案されたコマンドをそのまま承認しない
• 外部にデータを送る操作は、送り先を確認する。どのサービスに、何を送るのか
• 本番環境に直接つながる操作はさせない。作業は必ず手元か検証用の環境で行う

特に3つ目。本番のデータベースに接続した状態で作業すると、確認のつもりの操作が本番データを変えてしまうことがある。「動かしながら直す」を本番でやらない、という一線は引いておく。

観点3｜生成物の置き場所

できあがったツールをどこに置くかは、作った後に慌てて決められがちだ。ここで判断を誤ると、後から直すのが面倒になる。

• 個人のアカウントで公開しない。その人が抜けた瞬間に止まる。引き継ぎの問題に直結する
• 認証をかけずに公開しない。社内向けのつもりでもURLは広がる
• 動作確認用に書いた認証情報が残っていないか確認する。これがAPIキーの直書きとして残る典型パターン

「作れてしまう」ことの副作用

技術的な話から少し離れる。この種のツールを使い始めた組織で共通して起きるのが、ツールの数が管理できる量を超えることだ。

1つ目は本人が全部把握している。3つ目くらいまでは覚えている。5つを超えたあたりで、何が動いていて何が使われていないのかが分からなくなる。使われていないツールも、認証情報を持ったまま動き続ける。

対策は単純で、作ったら台帳に1行足す。ツール名、作った人、何をするもの、置き場所。これだけでいい。作るコストが下がったぶん、記録するコストを払う。

業務利用のルールとして書くなら

既存の生成AI利用ルールに、次の4行を足せば足りる。

1. 作業用フォルダを作り、その中だけで起動する。顧客データ・経理資料のあるフォルダでは起動しない
2. 削除・外部送信を伴う操作は、実行前に内容を確認する
3. 本番環境に直接接続した状態で作業しない
4. 作ったツールは台帳に登録する（名前・作成者・用途・置き場所）

ルール全体の作り方は生成AIの社内ルール、どう作る？を参照。

まとめ

Claude Codeのような道具は、非エンジニアが業務ツールを持てるようにした。使うべきでないという話ではない。ただしチャット型を前提に作られた社内ルールでは、想定が合わない。「見せる範囲を絞る」「させる操作に線を引く」「作ったものを記録する」——この3つを足すだけで、扱いはかなり安全になる。