AIエージェントを安全に仕事で使うために、最初に決めておきたいこと
こんにちは、neco.🐈⬛です。
AIエージェントを使うと、アプリ作成、資料整理、文章作成、業務代行のようなことまで、どんどん任せられるようになってきました。
一方で、便利になるほど気になるのが、
「セキュリティって大丈夫なの？」
「AIが作ったものを、そのまま信じていいの？」
「どこまで自動で任せて、どこから人間が確認すればいいの？」
というところです。
先日、くまさんをお招きして、AIエージェントを安全に実務で使うための勉強会を開催しました。
今回はその内容をもとに、AIエージェントを仕事で使う人が、まず押さえておきたい考え方をまとめます。
専門的な話も出てきますが、この記事ではなるべく実務目線で整理します。
GitやAPIキーなどの用語が不安な方は、最後にミニ解説も付けているので、必要なところだけ見てもらえれば大丈夫です。
リベの方はこちらにアーカイブがありますので、ご参照ください(´ ˘ `)♡
https://libecity.com/tweet/all?tweet_id=fnpDRTRUrPrGAAf07spl
今日の結論
AIエージェントは、すごく便利です。
でも、まだ「全部丸投げして大丈夫」と言える道具ではありません。
特に大事なのは、この2つです。
- 機密情報をどう扱うか
- 取り返しのつかない操作をどう止めるか
AIに任せる範囲が広がるほど、
「何を渡していいか」
「何を勝手に実行させないか」
「どこで人間が確認するか」
を先に決めておく必要があります。
AIを怖がって使わないのではなく、安全に任せるための土台を作ることが大事です。
AIは賢い。でも、人間ならやらないミスをする
勉強会の中で印象的だったのが、くまさん自身の失敗談でした。
AIエージェントに本番環境の作業を手伝ってもらっていたところ、作業中のメモファイルに書いていたパスワードが、いつの間にかGitに上がってしまったそうです。
気づいてすぐに取り下げ、パスワードも変更したとのことでしたが、これはかなり怖い話です。
AIはとても賢いです。
でも同時に、人間なら「それは上げちゃダメでしょ」と気づくようなことを、しれっとやってしまうことがあります。
たとえば、
- パスワードを書いたメモをコミット対象にしてしまう
- 大事なファイルを削除してしまう
- よくわからないコマンドを実行してしまう
- お客様に送る前の文章を勝手に送信してしまう
- 公開してはいけない情報を外に出してしまう
こういうリスクは、AIが悪意を持っているから起きるわけではありません。
AIが「このファイルはただのメモなのか、機密情報なのか」を判断できないことがあるから起きます。
だからこそ、AIに任せる前に、人間側でルールを用意しておく必要があります。
まず守るべきは「機密情報」
AIエージェントを使うときに、まず気をつけたいのは機密情報です。
機密情報には、たとえば次のようなものがあります。
- パスワード
- APIキー
- アクセストークン
- 秘密鍵
- 管理画面のログイン情報
この中でも、パスワードやAPIキーのような認証情報は別格です。
原則として、AIにそのまま渡さない方が安全です。
「ちょっとだけなら大丈夫かな」と思って貼ったものが、ログやGit、共有ファイルに残ることもあります。
どうしても必要な場合だけ、被害を限定できる形にしてから扱います。
- 専用のキーを発行する
- 漏れても被害を限定できる権限にする
.envなど、機密情報用の場所で管理する- Git管理から外す
- 1Passwordなどの安全な管理方法を使う
といった対策を考えます。
大事なのは、「漏れない前提」ではなく、「万が一漏れても被害を小さくする前提」で設計することです。
AIに読ませるフォルダを意識する
AIエージェントは、作業フォルダの中にあるファイルを読んだり、編集したりできます。
これは便利ですが、同時にリスクでもあります。
たとえば、作業フォルダの中に、
- パスワードを書いたメモ
- クライアント情報
- 個人情報
- 契約書
- 社外秘資料
が入っていると、AIがそれを読んだり、作業対象にしてしまう可能性があります。
なので、AIに作業させるときは、
「このフォルダの中に、AIに読ませてはいけないものはないか？」
を確認するのがおすすめです。
クライアントワークなら、会社ごと・案件ごとにフォルダを分ける。
パスワードやAPIキーは、作業フォルダ直下の雑なメモに置かない。
Gitに上げたくないファイルは、.gitignore に入れておく。
こういう基本的な整理だけでも、かなりリスクは下げられます。
私もAIに作業をお願いする前は、まず「このフォルダを見せて大丈夫かな？」を一度見るようにしています。
もう一つ大事なのは「取り返しのつかない操作」
くまさんがもう一つ強調していたのが、取り返しのつかない操作です。
たとえば、
- ファイル削除
- 本番環境への反映
- メール送信
- チャット送信
- SNS投稿
- 決済や請求に関わる処理
- 外部公開
こういう操作は、AIに完全自動で任せる前に、人間の確認を挟んだ方がいいです。
逆に、取り返しがつく作業は、ある程度思い切ってAIに任せても大丈夫です。
たとえば、下書きを作る、案を出す、ファイルを整理する、コードを修正案として出す、などは、間違っても戻せることが多いです。
ポイントは、全部を怖がることではありません。
戻せる作業は任せる。戻せない作業は確認する。
この線引きを持つだけで、AIエージェントはかなり使いやすくなります。
「Yes」を連打しない
AIエージェントを使っていると、途中で確認を求められることがあります。
「このコマンドを実行していいですか？」
「このファイルを変更していいですか？」
「この操作を許可しますか？」
最初はちゃんと見ていても、慣れてくるとだんだん面倒になって、Yesを連打したくなります。
これは正直、かなりあるあるだと思います。
でも、ここが危ないところです。
くまさんも、AIエージェントの確認に対して、何も見ずにYesを押し続けるのは危険だと話していました。
とはいえ、全部を毎回じっくり読むのも現実的ではありません。
そこでおすすめなのが、安全な操作はあらかじめ許可しておくことです。
たとえば、明らかに安全な確認だけは自動で通し、危なそうな操作だけ人間に聞いてもらうようにします。
Claude CodeなどのAIエージェントでは、設定によって「読み取りだけ」「検索だけ」のような低リスクな操作を通しやすくし、削除・送信・公開のような操作は確認を残す、といった分け方ができます。
そうすると、人間が見るべき確認の数を減らせます。
全部を気合いで見るのではなく、見るべきものだけが残るように設定するという考え方です。
AIに「これ危なくない？」と聞くのは有効
勉強会では、参加者の方から、
「AIに、これって大丈夫？危なくない？と聞いていたのは正しかったんですか？」
という質問もありました。
くまさんの回答は、かなり明確でした。
それはとても良い使い方です。
AIは、自分が出した答えを見直させるだけでも、危険に気づくことがあります。
たとえば、
「この操作、セキュリティ的に危なくない？」
「このファイル、Gitに上げても大丈夫？」
「この実装に脆弱性はない？」
「私は非エンジニアなので、危ないところをわかりやすく教えて」
と聞くだけでも、何もしないより安全性は上がります。
もちろん、AIの回答を100%信じるのは危険です。
でも、聞かないよりはずっと良いです。
別のAIにレビューさせる
プログラムやシステムを作る場合は、脆弱性の観点も大事です。
AIは、ある程度セキュリティを考慮したコードを書いてくれます。
ただし、外部に公開するアプリや、お客様に使ってもらうシステムでは、それだけでは不十分なことがあります。
そこで有効なのが、別のAIにレビューさせる方法です。
たとえば、
- Claude Codeで作ったものをCodexにレビューしてもらう
- Codexで作ったものをClaude Codeにレビューしてもらう
- 同じAIでも、別セッションでセキュリティレビューを依頼する
- 攻撃者目線のチェック役を作る
こうすると、作ったAI自身では気づかなかった問題が見つかることがあります。
人間のチームでも、作った人とレビューする人を分けますよね。
AIでも同じように、作業役とレビュー役を分けると安全性が上がります。
GitLeaksのようなチェックツールも使う
勉強会では、GitLeaksというツールの話も出ました。
GitLeaksは、ざっくり言うと、Gitの中に秘密情報が入っていないかをチェックするためのツールです。
たとえば、APIキーやトークンのようなものが、うっかりコミットされていないかを確認するのに役立ちます。
非エンジニアの方は、最初からツール名を全部覚えなくても大丈夫です。
大事なのは、
秘密情報が混ざっていないかを、人間の目だけに頼らずチェックする仕組みがある
と知っておくことです。
AIエージェントを仕事で使うなら、こういう環境面の整備も少しずつ取り入れていくと安心です。
会社の情報をAIに読ませていいのか
勉強会では、会社のナレッジや営業戦略などをAIに読ませて活用する場合の質問もありました。
この話は、かなり現実的です。
仕事でAIを使うなら、会社の文脈やお客様の情報をある程度読ませた方が、実用性は上がります。
一方で、その情報は外に出したくないものでもあります。
ここで大事なのは、全部を同じ重さで扱わないことです。
たとえば、公開済みの会社情報や一般的な業務手順と、顧客情報・契約情報・未公開の営業戦略では、扱い方を分けた方がいいです。
くまさんの考え方としては、チームプランやGoogle WorkspaceのGeminiなど、業務利用を前提とした環境で、学習に使われない設定になっているなら、一定の社内情報や業務情報は活用しやすいだろう、というものでした。
個人の有料プランでオプトアウト設定をしている場合も、考え方としては近い部分があります。
ただし、会社の情報を扱う場合は、個人の判断だけで決めない方が安全です。
一方で、パスワードや重要な認証情報のようなものは別です。
そこはAIに渡さない方が安全です。
また、サービス側が「学習には使わない」としていても、最終的な責任は自分たちにあります。
なので会社で使う場合は、
- 利用しているプラン
- 学習に使われるかどうか
- どの情報まで入力してよいか
- 社内ルールと合っているか
- お客様との契約上問題ないか
を確認した上で進めるのが安心です。
AgentBaseという考え方
勉強会の最後に、くまさんが開発している「AgentBase」という仕組みも紹介されました。
当日時点では準備中の仕組みとして紹介されていましたが、その後、ベータ版として公開されています。
AgentBaseは、AIエージェントを安全に、かつ実務で扱いやすくするための土台です。
イメージとしては、AIに守ってほしいルールを階層化して管理する仕組みです。
たとえば、
- 絶対に守る基本ルール
- 会社ごとのルール
- お客様ごとのルール
- プロジェクトごとのルール
- チームごとのルール
のように、ルールを整理しておけます。
くまさんは、これを「憲法、法律、条例」のようなイメージで説明していました。
上位のルールほど強く、下位のルールほど具体的。
この構造を作ることで、AIエージェントが自由に提案しながらも、実行時にはルールに沿って慎重に動くことを目指しているそうです。
また、Claude CodeやCodexなど、複数のAIエージェントで同じルールを使えるようにする思想もあります。
AIごとに毎回設定を作り直すのではなく、共通の土台を持てるのはかなり便利です。
気になる方は、GitHubの公開ページも見てみてください。
使ってみたい方へ
導入は、エンジニアじゃなくても大丈夫な作りになっています。
- GitHubのReleasesページを開き、最新バージョンの Assets にある
Source code (zip)をダウンロードする
- zipを好きな場所に展開して、フォルダ名を変える（展開直後は
agent-base-バージョン番号のような名前なので、my-ai-workspaceなど好きな名前でOK） - Claude Code・Codex・Cursorなどで、そのフォルダを作業フォルダとして開く（Cursorなら「フォルダを開く」、Claude Codeならそのフォルダでターミナルを開いて起動）
- AIに「セットアップして」と話しかける
あとはAIが、組織名や名前を確認しながら、あなた用のルールを作ってくれます。
使い始めてからも、
- 「使い方を教えて」
- 「ルールを追加して」
- 「健康診断して」（ルールが壊れていないかのチェック）
- 「AgentBaseを更新して」（新しいバージョンの取り込み）
のように、AIに話しかけるだけで操作できるようになっています。
そして、クライアントごとのルールを育てていくと、AgentBaseの良さが本領を発揮します。
たとえば、
- 「A社向けの資料を作りたい」→ AIがA社のルール（トーンや資料フォーマット、注意点）を読んでから作業してくれる
- 「B社向けのルールに追加して」→ 「B社の資料は敬語多め」のような決まりごとを、AIがB社のルールとして貯めてくれる
一度ルールにしておけば、次からは毎回説明し直さなくても、AIがその会社の文脈で動いてくれるようになります。
なお、v1.0.0になるまではベータ版という位置づけで、仕様やフォルダ構成が変わることがあります。ただ、更新しても自分で育てたルール置き場（rules/）は上書きされない設計です。
今日からできるチェックリスト
少し多く見えるかもしれませんが、最初から全部やらなくて大丈夫です。
まずは★の項目だけでも確認してみてください。
AIに渡す前
- ★ 作業フォルダに機密情報が入っていないか
- ★ パスワードやAPIキーをチャットに貼ろうとしていないか
- クライアント情報や個人情報をそのまま渡していないか
- 会社やお客様のルールに反していないか
- AIに「この情報は機密情報です」と伝えているか
AIに作業させるとき
- Yesを連打していないか
- ★ 削除・送信・公開・本番反映は人間確認にしているか
- 安全な操作だけを事前許可しているか
- 危ない操作をAIに説明させているか
- 「これ危なくない？」と確認しているか
AIが作業した後
- 変更されたファイルを確認したか
- Gitに余計なファイルが入っていないか
- パスワードやAPIキーが混ざっていないか
- 別のAIや別セッションでレビューしたか
- 公開・送信前に人間が最終確認したか
まとめ
AIエージェントは、これからもっと仕事の中に入ってきます。
だからこそ、今のうちに大事なのは、
「AIを使うか、使わないか」
ではなく、
AIを安全に任せるためのルールを作ること
だと思います。
今回の勉強会で、私が一番大事だと感じたのは、機密情報を雑に渡さないことと、取り返しのつかない操作は人間が確認することです。
まずはこの2つからで大丈夫です。
完璧なセキュリティ体制をいきなり作ろうとすると大変ですが、「渡す情報」と「戻せない操作」を見るだけでも、かなり安心して使いやすくなります。
そして慣れてきたら、
- 安全な操作の事前許可
- Git管理からの除外
- 1Passwordなどの安全な認証情報管理
- GitLeaksのようなチェックツール
- AI同士のレビュー
- AgentBaseのような共通ルール基盤
を少しずつ取り入れていく。
AIを怖がりすぎず、でも過信しすぎず。
「任せるところ」と「確認するところ」を分けながら、仕事で安心して使える形にしていきたいですね。
付録｜専門用語ミニ解説
最後に、今回の話に関連して知っておくと役立つ用語をざっくり整理しておきます。
AIエージェント
チャットで答えるだけでなく、ファイルを読んだり、コードを書いたり、ブラウザを操作したり、外部サービスと連携したりできるAIのことです。
普通のチャットAIより「実際に動く範囲」が広いので、便利な一方で安全確認も大事になります。
機密情報
外に出ると困る情報のことです。
パスワード、APIキー、個人情報、顧客情報、社外秘資料、営業戦略、契約情報などが含まれます。
「これはAIに渡していい情報か？」と迷ったら、一度止まって確認するのがおすすめです。
APIキー・アクセストークン
外部サービスを使うための「合鍵」のようなものです。
これが漏れると、自分の代わりにサービスを使われたり、料金が発生したり、データを見られたりする可能性があります。
1Password
パスワードやAPIキーなどを安全に管理するためのパスワード管理サービスです。
AIに直接パスワードを渡すのではなく、こうした専用ツールで管理すると、漏えいリスクを下げやすくなります。
.env
APIキーやパスワードなどを入れておくためによく使われる設定ファイルです。
ただし、.env に入れたから絶対安全という意味ではありません。
Gitに上げない、AIに読ませない、権限を絞る、といった運用もセットで考えます。
Git・GitHub・コミット
Gitは、ファイルの変更履歴を管理する仕組みです。
GitHubは、その履歴をインターネット上で管理・共有できるサービスです。
コミットは、変更を履歴として保存する操作です。
ここにパスワードなどが混ざると、あとから消したつもりでも履歴に残ることがあります。
.gitignore
Gitで管理したくないファイルを指定するための設定ファイルです。
たとえば .env や一時メモなどを .gitignore に入れておくと、うっかりGitに上げるリスクを下げられます。
GitLeaks
Gitの履歴や変更内容に、APIキーやトークンのような秘密情報が混ざっていないかチェックするツールです。
人間の目だけで確認するより、見落としを減らしやすくなります。
脆弱性
システムの弱点のことです。
たとえば、ログインしていない人がデータを見られる、悪意ある入力でシステムを壊せる、権限のない人が管理画面に入れる、などが脆弱性です。
オプトアウト
サービス側に「このデータを学習などに使わないでください」と設定することです。
ただし、オプトアウトしていれば何でも入力してよい、という意味ではありません。
会社やお客様のルール、契約、情報の重要度もあわせて判断します。
RAG
AIに社内資料やナレッジを参照させて、回答の精度を上げる仕組みです。
会社の文脈をAIに理解させやすくなる一方で、どの情報を読ませるかの設計が大事になります。
本番環境
実際のお客様やユーザーが使っている環境のことです。
ここでの変更は影響が大きいので、AIに作業させる場合でも、人間の確認を強めに入れた方が安全です。
プルリクエスト
コードやファイルの変更を、正式に取り込む前に確認してもらうための仕組みです。
AIに作ってもらった変更も、プルリクエストで区切って確認すると、危ない変更に気づきやすくなります。
サブエージェント
AIの中に役割別の担当を作る考え方です。
たとえば、作業担当AI、レビュー担当AI、セキュリティ確認AIのように分けると、1つのAIに全部任せるより確認しやすくなります。