💻【税理士事務所 事務員のヒヤリ】顧問先データをAIに貼りつけかけた私が、公式セキュリティプラグインを試した
「試算表のデータ、AIに丸ごと渡して分析させたら一瞬なのに」
「便利すぎる。でも……このデータ、渡したあとどこへ行くんだろう」
「顧問先からお預かりした数字をAIに入れて、本当に大丈夫なんだろうか」
AIを実務で使い始めた税理士事務所の人間なら、こんな迷い、一度はよぎったのではないでしょうか。
正直に言うと、私も一度、その「大丈夫だろうか」を考えないまま、手が動きかけたことがあります。
こんにちは、バッツです。税理士事務所の事務員として、顧問先のお金とデータに日々触れて8年、いま生成AIを実務に取り入れようとしています。
今日は、自分がヒヤリとした話から始めさせてください。
私は、顧問先のデータを「無防備に」AIへ渡しかけた
少し前のことです。
仕事に追われ、少しでも手早く片付けたい一心で、お預かりした試算表の数字を、対話型AIにそのまま貼りつけて「この傾向を分析して」と頼もうとした——そんな瞬間がありました。
便利そうでした。恐ろしいほどに。便利だからこそ、つい手が伸びそうになるんですよね。
そのデータが、サービスや設定によっては、AIの学習に使われることがある——貼りつける直前に、ふとそれが頭をよぎって、手が止まりました。その瞬間まで、私はそれを本気で意識したことがありませんでした。
税理士事務所の人間にとって、顧問先のデータは守秘義務の塊です。それを、行き先も確かめずに外部のAIへ流すところだった。いま思い返しても、背筋が冷たくなります。
結果的に、データを入れることはありませんでした。ですが、止まれたのはたまたまです。「知らなかった」で済む話ではありません。
このヒヤリ以来、私は「AIに何を渡すか」「ツールは何をどこまで守ってくれるのか」を、まず確かめる人間になりました。
そんな折の2026年5月27日、Anthropicが公式のセキュリティプラグイン `security-guidance` を無料でリリースしました。「危険なコードを書いた瞬間に止めてくれる」と言います。
あの日の私のような「うっかり」の一歩手前を、これは防いでくれるのか。リリース翌日、税理士事務所の人間の目線で、実際に試しました。
そもそも「セキュリティプラグイン」とは
プログラミングが本業でない方へ、一言だけ。
これは、コードを書いている最中に危険な書き方を自動で見張ってくれる仕組みです。仕訳の貸借が合わないと教えてくれるチェック機能の、コード版だと思ってください。
たとえば「パスワードやAPIキーをコードに直接書いてしまう」「外部から不正侵入されかねない書き方をしてしまう」——こうしたミスを、書いた瞬間に止めてくれる、というのが触れ込みです。
`security-guidance` はAnthropic公式の無料プラグインで、Claude Code(コードを書くAIツール)に組み込んで使います。配布元と解説は公式のこちらです。
インストールはコマンド2行、費用ゼロ、要件のハードルも低めでした(私の環境は Claude Code 2.1.153 / Python 3.11.9・全プラン対応)。
/plugin install security-guidance
/reload-plugins実行すると `1 plugin · 6 hooks` と表示されます。6つのフックが、働くタイミングで見ると大きく3段階(編集時・作業の区切り・保存時)に分かれます。
導入は5分もかかりません。手軽に防御を1段足せるなら、属人的な注意力だけに頼る運用よりずっと現実的だと思います。だからこそ、性能を確かめておきたかった。
🔍【検証】脆弱性を4種仕込んだら、止めてくれたのは1種だけ
実行しない前提のダミーコード(冒頭に「DO NOT EXECUTE」と明記したテスト用ファイル)に、代表的な脆弱性を4種類わざと仕込み、反応を観察しました。
ここからは、私の環境・テスト用ファイルでの1回のテスト結果です。条件が変われば反応も変わりうる、という前提で読んでください。
検知できた1種:command injection(コマンド注入)
外部から悪意あるコマンドを注入されかねない危険な書き方です。
これを書いた瞬間、プラグインは即座に警告し、より安全な書き方まで提示してくれました。手が止まり、その場で直せる。この体験はかなり実用的だと感じました。
検知漏れだった3種
残りの3種は、書き込んでも無反応でした。
SQL injection(データベース不正侵入): 危険なクエリ → 警告なし
hardcoded API key(APIキー直書き): キー文字列 → 警告なし
XSS(利用者入力をHTMLにそのまま埋め込む) → 警告なし
つまり、4種のうち3種は素通り。とりわけ「APIキー直書き」が止められなかったのは、意外でした。
保存(commit)しても、警告は出なかった
「編集時は軽いチェックだから、保存時に深く見てくれるはず」と期待し、検知漏れのファイルをそのまま保存しました。結果は警告なし・そのまま成功です。
最も疑わしいのは、ファイル冒頭に「テスト用」と明記したことで対象外と判定された可能性。ただ、プラグインの設計を追い切れたわけではないので、断定はできません。
ひとつだけ確かなのは——「保存すれば全部チェックされる」という思い込みは危険だ、ということではないでしょうか。
税理士事務所の事務員として痛感したこと:一番怖いのは、プラグインが守る範囲の「外」
ここが、私がこの記事を書いた本当の理由です。
このプラグインに、何を期待し、何を期待すべきでないか
顧問先のデータ自動化では、これからfreeeやマネーフォワードのAPIと連携する場面が必ず来ます。私自身はまだこれからの領域ですが、顧問先ではすでに使われています。
そのとき一番怖いのが、APIキーの流出です。キー1本が外に出れば、つながった会計データ全体が危険にさらされる。
ところが——正直に言えば、今回の検証で APIキーの直書きそのものは止められませんでした(検知漏れ3種のひとつ)。期待していた部分だっただけに、ここは残念でした。
それでも、command injection のような危険なコードは確実に止めてくれた。だから私はこう受け止めています。これは「万能の防壁」ではなく、「1段の網」だと。人間の注意力だけに頼る運用に、機械のチェックを一枚重ねられる。その意味でなら、入れておく価値はあると思います。
守ってくれないもの——私がヒヤリとしたのは、まさにココ
そしてもう一つ、誤解してはいけないことがあります。このプラグインの守備範囲はコードの脆弱性検知だけだということです。
思い出してください。冒頭の私のヒヤリ——学習リスクを意識しないまま、試算表のデータをAIへ渡しかけた、あれです。
あれは「危険なコードの書き方」ではありません。「そもそもAIに何を渡すか」という、もっと手前の問題です。そして、それはこのプラグインの守備範囲の完全な外側にあります。
顧問先の実名がメモやデータに紛れ込む → 検知しません
マイナンバー・口座番号の記述 → 守備範囲外
「このデータをAIに渡していいのか」という判断 → 機械は何も言ってくれない
私が一番ヒヤリとした領域は、最新の公式プラグインを入れても、1ミリも守られないのです。この怖さ、同じ仕事をしている人なら、わかりますよね。
結論:1段の網として導入する。でも、最大の防御は「何を渡さないか」
整理するとこうなります。
危険なコードの書き方(command injection など)→ 即座に止めてくれる。1段の網として導入します。
顧問先情報・守秘義務・「何をAIに渡すか」の判断 → プラグインでは守れない。ここは人間が守るしかない。
公式プラグインを入れて「これで安心」と思い込むこと——それこそが、かつての私と同じ「知らないことの怖さ」だと思います。
おわりに
4種中1種という検知結果は、隠さず記録しました。「公式だから完璧」は、リリース翌日のテストが否定しています。それでも、コストはほぼゼロで網が一枚増えるなら、入れない理由はありません。
そして何より——ツールがどれだけ進化しても、顧問先のデータを何に渡すかを決めるのは、最後まで私たち自身です。あの日の私が踏み出しかけた、取り返しのつかない一歩を、一人でも減らせたら嬉しいです。
ここまで読んでくださって、ありがとうございました。
ひとつだけ聞かせてください。
あなたの事務所では、AIに渡していいデータとダメなデータの線引き、決まっていますか?
「うちはこう運用している」「線引きで迷っている」——どんな話でも、コメント💬 で教えてもらえると嬉しいです。
(同じテーマで発信を続けています。フォローとスキ❤もいただけると、次を書く力になります。)
#バッツ #ヤる気ZER0
#ClaudeCode
#生成AI
#セキュリティ
#事務員
#業務効率化
#APIキー管理
#守秘義務
#Claude
