「社内の集計ツール、自分で作れちゃいました」
AIコーディングツールが広まって、こんな声を聞く機会が増えました。情シス担当の方や、ちょっとプログラミングをかじったことのある社員が、勤怠の集計画面や案件管理のミニアプリを数日で組み上げてしまう。実際に動いていて、現場でも使われている。これはもう、立派な成果です。
ただ、ここで一度立ち止まってほしいのです。「動いている」と「安全に運用できている」は、別の話だからです。
「動くから安全」とは限らない
AIに「ログイン画面を付けて」とお願いすれば、ログイン画面は付きます。見た目も動きも、それっぽく仕上がります。でも、そのログインが「鍵のかかっていないドアに、立派な取っ手を付けただけ」だったとしたら、どうでしょう。
動作確認では気づけません。自分のIDでログインできて、データが見られて、ボタンを押せば集計が走る。テストはぜんぶ緑です。問題は、動作確認では「正しく動くこと」しか確かめていない点にあります。「許されていない人に、許されていないことができてしまわないか」は、誰もテストしていないのです。
セキュリティの穴は、エラーを出しません。静かに、動いているふりをして残り続けます。
まず、穴になりやすい場所を見渡す
細かい話に入る前に、社内ツールでよく見つかる「穴」を一覧にしておきます。自社のツールに当てはめながら読んでみてください。
| 穴になりやすい場所 | よくある状態 | 何が起きうるか |
|---|---|---|
| 認証（本人確認） | ログイン処理を自前で実装 | パスワードの守り方が甘く、突破されやすい |
| 認可（権限） | 誰でも全データが見られる | 他部署・他人の情報まで丸見え |
| 機密情報の置き場所 | パスワードや鍵をコードに直書き | 画面共有や流出で一発アウト |
| ログ | ログに個人情報や鍵が出る | ログを見られた時点で漏れる |
| 公開範囲 | 社内向けのつもりが外から見える | 取引先情報が検索でヒット |
| 退職者アクセス | 辞めた人のIDが生きたまま | 元社員が今もデータを見られる |
| 監査ログ | 誰が何をしたか残らない | 何かあっても追跡できない |
全部を一度に直す必要はありません。ここからは、特に影響が大きい3つを掘り下げます。
穴その1：認証を「自前で」作ってしまう
一番やりがちなのが、ログインの仕組みを丸ごと自分で書いてしまうことです。AIは頼めば書いてくれます。でも、パスワードの安全な保管方法、ログインの試行回数制限、セッションの扱い——本人確認まわりは、地味なのに奥が深い領域です。ここを独学とAIの提案だけで固めるのは、正直おすすめしません（鍵まわりは、餅は餅屋なのです）。
本人確認は、世の中に「すでに安全に作り込まれた仕組み」がたくさんあります。Googleアカウントでのログインや、認証を専門に提供するサービスに任せるほうが、自前で守るより圧倒的に堅い。鍵だけは、鍵の専門家に任せるという発想です。
穴その2：「誰が、何を見られるか」が決まっていない
認証（本人確認）が通っても、その次に「認可（権限）」という関門があります。ログインできた人全員が、すべてのデータを見られて、すべての操作ができる——これが、社内ツールで一番多い穴です。
経理しか見てはいけない数字を、アルバイトのアカウントでも開けてしまう。退職予定者の評価メモを、本人が見られてしまう。悪意がなくても、見えてしまえばそれは漏えいです。権限は「あとで付ければいい」と思われがちですが、データ構造に深く関わるので、後付けほど高くつく部分でもあります。
設定を見直すだけで2時間溶けることもあります（その2時間、残業に化けていませんか）。だからこそ、作り始めの「誰がどこまで触れるか」を決める一手間が効いてきます。
穴その3：パスワードや鍵が、コードに直接書いてある
外部サービスと連携するとき、APIキー（外部サービスを使うための、鍵のような文字列）やパスワードが必要になります。AIに「この外部サービスとつないで」と頼むと、サンプルとして鍵をコードの中に直接書いた形で出してくることがあります。動きます。動くんですよね。でも、その鍵はファイルにそのまま残ります。
画面共有した瞬間、ファイルを誰かに送った瞬間、社外のサービスにコードを貼り付けた瞬間——鍵は外に出ます。鍵が漏れれば、つながっている先のデータも危ない。鍵は、コードとは別の場所に、隠して持つのが原則です。
技術者向け：機密情報の扱い（クリックで開く）
機密値はソースに直書きせず、環境変数やシークレット管理の仕組みに逃がすのが基本です。
# 避けたい書き方（鍵がそのまま残る）
api_key = "sk-live-abcd1234..."
# 望ましい書き方（鍵は外から渡す）
api_key = read_from_environment("EXTERNAL_API_KEY")
加えて、ログ出力に鍵・トークン・個人情報を含めない、リポジトリに .env をコミットしない、といった基本も合わせて確認しておくと安心です。
見落とされがちな「人の出入り」
技術的な穴とは別に、運用の穴もあります。代表が「退職者アクセス」です。辞めた人のログイン情報、消し忘れていることはありませんか？ 手作りのツールは、入社・退職に合わせてアカウントを整理する仕組みが抜けがちです。半年前に辞めた人が、今もデータを見られる状態だった、という話は珍しくありません。
そして「監査ログ」。誰が、いつ、何をしたかの記録です。普段は誰も見ませんが、何かトラブルが起きたとき、これが無いと原因にたどり着けません。記録があるのとないのとでは、いざというときの安心感がまるで違います。
どこから手をつけるか
ここまで読んで不安になったかもしれませんが、全部を作り直す必要はありません。順番をつけて、効くところから直していけば十分です。
| 優先度 | やること | ねらい |
|---|---|---|
| 高 | コードに直書きされた鍵・パスワードを外に逃がす | 流出の即死リスクを止める |
| 高 | 権限を「役割ごと」に分ける | 見えてはいけない情報を閉じる |
| 中 | 本人確認を既製の仕組みに寄せる | 自前実装の弱点をなくす |
| 中 | 退職者アカウントの棚卸し | 出入りの穴をふさぐ |
| 低 | 監査ログを残す | いざというときに追える |
大事なのは、これらが「ツールを止めずに、後から足せる」ことです。既存の仕組みを活かしたまま、危ないところだけを順番にふさいでいけば、大きなリスクなく安全側に寄せられます。
そもそも、どのツールで作るのが自社に合うのか迷っている段階なら、AIコーディングツールの比較・選び方はこちらも判断材料になります。作る前に向き不向きを知っておくと、後の手戻りが減ります。
AIは「コード」は知っていても「あなたの会社のルール」は知らない
AIコーディングツールは、たしかに優秀です。動くものを、驚くほど速く作ってくれます。ただ、AIが知らないものが一つあります。あなたの会社の「誰にどこまで見せてよいか」というルールです。
経理だけが見るべき数字、役員しか触れない契約情報、現場には伏せておきたい評価——こうした線引きは、その会社の事情そのものです。AIはそこまでは判断できません。動くツールはできても、安全なツールにするには、人の手で「うちのルール」を教え込む工程が要るのです。
不安な箇所、一緒に棚卸ししませんか
「動いているけど、セキュリティは正直、自信がない」。そう感じたら、それは止まるタイミングではなく、整える合図です。
playpark のAI実装支援では、Web制作から業務改善まで、まるごとご相談いただけます。法人として責任をもって伴走しますので、「作ったツールを捨てずに、安全なところだけ直したい」というご相談も歓迎です。最短2週間で公開できる体制で、無理のない範囲から進められます。
まずは今のツールのどこに穴がありそうか、一緒に整理するところから始めませんか？ お気軽にご相談ください。
