🔐 セキュリティと会社での活用 7問
機密情報の扱い・社内制約・周囲へのAIの広め方
仕事でAIに入力する情報は、どこまでなら許容範囲ですか?
仕事でAIを活用したいが、セキュリティ面の理解が不足していると感じているという質問です。入力情報がAIの学習に使われるという話をよく聞くが、それによる最悪の被害として想定されるケースは何か、個人情報・社内の機密情報・非公開だが顧客には開示する営業資料・受注明細や見積書などをどこまで入力してよいか、一般的な判断基準を知りたいという内容です。
まず、多くのAIツールでは、入力した情報を学習データとして使うかどうかを設定できるようになっています。また、大手の生成AI企業も個人情報・機密情報の扱いには気を使っています。たとえば、ある人がAIに個人的な相談をした内容が、その人の友人がAIを使ったときに「あなたの友達の○○さんはこんなことで困っているらしいですよ」という形で漏れてしまえば、使った本人の損失であるだけでなく、AI企業自身も信用・信頼を失う大きなマイナスを抱えることになります。そのため各社は、学習に使う情報は個人が特定されない形に加工していると説明していますが、詳細は自分で必ず確認する必要があるとしています。
こうした前提のもとで、講師は「最悪のリスクは極めて低い」という考えを示しています。ただし、リスクを議論し始めると「車は危ないから乗らない方がいい」という結論になりかねないのと同じで、万が一の可能性を突き詰めれば常に否定はできません。重要なのは、危険か危険でないかという二元論ではなく、個別具体の情報についてこれは良いか悪いかを判断していくことだと講師は述べています。保守的になりすぎると、新しい道具を使うこと自体が難しくなってしまいます。
一般論としては、外に出てほしくない情報をAIに入力することは推奨されません。仮に大手企業のサーバーに情報が残らなかったとしても、機密情報をチャットでやり取りしているという事実自体が、パソコンを紛失したときや悪意のあるプログラムに感染したときに情報が漏れるリスクにつながります。これはパソコン内のメモ帳に機密情報を残すのと本質的には同じことです。会社に所属している場合は、会社のルールに従う必要があります。ルールを破った場合の責任は自分では取れないためです。
一方で、何でもかんでもAIに入力してはいけないというルールにしてしまうと、AIが使いにくくなってしまいます。そこで、個人情報そのものは入力せず、個人が特定されないデータに置き換えて学習・活用してもらうという方法が現実的です。たとえば顧客のCSVがあれば、個人名・メールアドレス・住所・電話番号といった個人情報をすべてサンプルデータに置き換えたうえでAIに仕事をしてもらう、営業資料であれば社名を伏せる、クライアントの機密情報は入力しない、といった対応がベターです。
なお、講師の知る限り、AIを積極的に使っている会社、特にスタートアップや小さな会社ほど、こうしたセキュリティ意識が緩い傾向にあるといいます。これは決して推奨できることではないとしつつも、「守るものが少ない会社」は、確率としては低いリスクを気にするよりも前に進むことを優先する構造になっているためだと説明しています。逆に守るものが多い組織ほど、より保守的な判断をすべきだというのが講師の考えです。
AIで作ったツールをチームに導入する際、保守への抵抗にどう対処すればいいですか?
AIで作ったツールをチームに導入しようとした際、「保守はできるのか」といった抵抗を受ける可能性を感じている、経営者としてではなくチームメンバーを説得する立場だったらどう対処するか、という質問です。
講師はまず、保守はできる必要があると前置きします。ただし、一部の人が使う社内ツールであれば、何万人にも使ってもらうサービスとは事情が異なり、落ちた瞬間にすべての仕事が止まってしまうような重大な損失が生まれるわけではないはずだといいます。まずは小さく試す段階であれば、止まらずに確実に動くところまで保守を突き詰めるのは、最初からやりすぎだというのが講師の考えです。
もっとも、こうしたAIツールは一度使い始めると必ず改善したくなるものであり、その意味で一定の改善リソースを確保しておくことは現実的に必要だとしています。
チームメンバーの説得という観点では、「保守はできるのか」という指摘自体が、100%腹落ちしているわけではなく、ケチをつけるポイントを探しているだけという側面もあると講師は見ています。そこで有効なのは、「AIを使いたい」という言葉での説明よりも、実際に動くツールを見せることです。「これが使えたらすごく便利ではないですか、すぐ導入できますよ」と見せたときに、「これは本当にいいね、ぜひ使いたい」と感情的に納得してもらえれば、その後の保守リソースの確保や導入コスト、チューニングのコストについても多めに見てもらいやすくなります。
つまり、「これはすごくいい」と思わせられるツールを作ることに勝る説得材料はない、というのが講師の結論です。
APIキーなど重要な情報の扱いについて、サブエージェントの判断が割れた場合の最終判断はどう行うべきですか?
AIツールの開発で外部サービスと連携する際、APIキー(外部サービスを利用するための認証情報)や重要なアドレスの扱いに不安があり、あるサブエージェント(特定の役割でレビューを行うAIの分身)に確認すると「OK」と言われ、別のサブエージェントには「危険」と言われることがある場合、最終的な判断はどのような基準で行うべきかという質問です。
前置きとして、これはケースバイケースであり、講師が「大丈夫」と言ったことをそのまま実行して問題が起きても責任は取れない、という前提のうえで、経験則が語られています。AIの判断が割れた場合、しっかり精査することが前提ではあるものの、「危険だ」と言っている側の判断が、実際には気にしすぎのレベルになっていることが多い、というのが講師の感覚です。
判断の軸として重要なのは、何が本当に危険で、何がそれほど危険ではないかを理解しておくことです。例えばAnthropic(Claudeを開発する企業)のAPIキーのように、クレジットカードが紐づいており、AIを動かすたびに課金が発生するタイプのAPIキーが流出すると、非常に危険な状態になります。こうしたAPIキーをインターネット上の誰でも見られる場所、あるいは見えやすい場所に置いておくことはリスクです。
特に注意すべきなのはGit(変更履歴を記録・管理する仕組み)へのコミット(変更を保存する単位で記録すること)です。一度コミットしてしまうと、その情報は履歴として残り続けます。パソコンを紛失したり、ウイルスに感染して情報を盗まれたりした場合、Gitの履歴に残ったAPIキーが悪用される危険が生じます。万が一コミットしてしまった場合は、そのAPIキーを無効化することが必須の対応です。GitHub(Gitのデータをオンラインで保管・共有するサービス)上にAPIキーを含むコミットをプッシュ(手元の変更をGitHub側に反映させる操作)することも危険です。プライベート(非公開)なリポジトリであれば基本的に他人には見られませんが、権限を持つ人がクローン(複製)してオープンな場所に上げてしまえば、公開したのと同じ状況になり得ます。
こうした重要な情報は、手元に平文で残さない管理が基本です。講師はAPIキーをすべて1Password(パスワードや機密情報を安全に管理するサービス)で管理し、必要なときに都度そこから読み込む仕組みを取っています。1Passwordが唯一の正解ではありませんが、重要なのは「何が危険で何が危険でないか」を自分自身で理解しておくことです。APIキーは家の鍵のようなものであり、粗末に扱ってはいけません。
会社ではCursorが使えず、CopilotとPowerShellしか使えません。マイクロソフト縛りの環境でもAI-Driven Schoolの知見は活かせますか?
会社の方針でCursor(AIが組み込まれたコード編集ツール)が使えず、Copilot(マイクロソフト社が提供するAIアシスタント)とPowerShell(Windowsの操作を自動化するためのコマンド実行環境)のみが使える、いわゆるマイクロソフト縛りの環境で、AI-Driven Schoolで学んだ知見を活かせるかという質問です。
結論として、マイクロソフト縛りの環境でもAIの本質は変わりません。現時点での見方として、Copilotの性能は他の最新モデルと比べると十分使えるレベルではあるものの、やや劣るという評価です。例えばExcel作成についてはClaude(Anthropic社のAIモデル)の方が明らかに強いという実験結果も語られています。とはいえ、会社で使えるツールが限られているという制約自体は変わらず、性能の高いモデルやツールを使えないことはどうしても縛りになります。
この状況は、講師が過去に運営していたプログラミング教育事業でよく聞かれた「どの言語を学ぶといいですか」という質問と重ねて語られています。どの言語を選ぶかによってすべてが決まるわけではなく、プログラミングの原理原則はどの言語でも共通しています。世界の主流の開発言語は非常に速いスピードで移り変わるため、1つの言語にこだわりすぎず、「今はこれをやりつつ他の言語も学んでいく」という前提で臨む方がよいという考え方です。これはAIモデルやツールの選択にもそのまま当てはまります。
Windowsは開発者向けツールの充実度という点では、規格が統一されているMacに比べてやや見劣りするように感じられますが、Windowsだから絶対にできないということはありません。Copilotしか使えない企業は多く存在しますが、それによってAI-Driven Schoolの内容が役に立たなくなるわけではありません。ツールが変わっても、AI活用の普遍的な原理原則は変わらないためです。マイクロソフトの技術も日々進化しており、性能面での制約が今後どう変化していくかは誰にも分かりません。
会社のパソコンにツールをインストールできない、データを持ち出せないという制約がある中で、AI開発スキルを業務に活かすにはどうすればいいですか?
会社のセキュリティ規定によりCursorやClaude Codeなどのツールを業務PCにインストールできず、業務データも扱えないため、ダミーデータで課題に取り組んでいる。実務と結びつかず、モチベーションが下がってしまう、という相談がありました。
「ダミーデータで取り組んでいること自体はモチベーション低下の原因ではない」という指摘から回答が始まりました。実際の開発現場でも、セキュリティ意識が比較的緩い企業を含め、多くのエンジニアはダミーデータで開発を進めるのが通常であり、これはセキュリティ上の理由に加え、本番データがそもそも扱いにくいためでもあります。
会社のセキュリティが固いことで失われるスピード感がある一方、それによって得ているものもあります。たとえば顧客情報の流出のような重大事故が起きて会社自体がなくなり、働き先を失うリスクを、高いセキュリティレベルが防いでいます。逆に、失うものが少ないスタートアップ企業はダミーデータを使いつつもスピード重視で開発を進められますが、その分事業が続かないリスクも高くなります。どちらが良い悪いではなく、自分がどんなライフスタイルを望むかという選択の問題だとされました。
個人環境で作ったプロトタイプを仕事に活かしたい場合は、「こういうツールを作ったので運用してみませんか」と社内で提案してみることがすすめられました。会社に勤めている以上、やりたいことを全部自由にできるわけではありませんが、その分得ている安定もあります。もし自由な開発環境を強く求めるのであれば、機動力はあるがリスクも大きいスタートアップへ飛び込むという選択肢もありますが、それが幸せにつながるかは人それぞれだと締めくくられました。
AnthropicのClaude Mythosがニュースで話題になっていますが、実際のところ安全なのでしょうか?
「自分で考えて行動できる天才ハッカーのようなAI」だと報じられているClaude Mythosについて、実際に安全なのか、対応が必要なのか、という質問でした。
Claude Mythosは、Claudeを開発するAnthropic社が2026年4月7日に発表したフロンティアAIモデル(多くの人に広く提供するのではなく、限られた範囲で使われる、実験的かつ高度なAIモデル)であると説明されました。
報道されている「自分で考えて行動できる天才ハッカーのようなAI」という説明は、おおむね事実だとされました。ソフトウェアの脆弱性(セキュリティ上の弱点)を見つける能力が非常に高く、悪用された場合には多くの人が想定する以上に危険な事態を招きかねないといいます。極端な例として、軍のシステムに侵入してミサイルを発射させたり、大企業の口座から資金を全て抜き取ったりするといったリスクが挙げられましたが、実際にそこまでの行為は物理的に不可能に近いだろうとも付け加えられました。
個人レベルでできる対策としては、パスワードを推測されやすいものにしない、APIキー(サービスを外部から利用するための鍵となる文字列)などの重要な情報を誰でもアクセスできる場所に置かない、といった基礎的なセキュリティ対策を徹底すること以外にないと説明されました。高い倫理観と安全性を重視する姿勢を持つAnthropic社が最初にこの水準のモデルを生み出したことは、不幸中の幸いだったという見解も示されました(もし悪意ある集団がこの技術を先に手にしていた場合、より深刻な事態になり得たため)。
インターネットに接続された便利なツールが増えるほど、ハッカーが1台のパソコンから巨大なシステムに侵入できてしまうリスクも高まっており、セキュリティの重要性・市場規模は年々拡大しています。個人が今すぐ何か特別な対応をする必要はありませんが、セキュリティが緩い状態で事業を進めるリスクが高まっていることは理解しておくべきで、経営者であれば予算を割いてセキュリティに本腰を入れる必要がある時代になった、と締めくくられました。
社内や顧客に無償・有償でツールを提供する際、一般常識的なセキュリティレベルをどのようにAIに指示すれば実現できますか。
難しく考える必要はなく、「自分の公開しているアプリケーションをセキュリティ観点で分析して」とAIにそのまま聞くだけでよい、と説明されています。重要なのは、AIが指摘してきた内容を自分で理解できる状態になることです。セキュリティ対策自体の実装は誰にでもできますが、問題は「どんなセキュリティリスクがあるのか」を自分の言葉で説明できるかどうかにあります。
講師自身、エンジニアとしてセキュリティの知識は持っているものの、プロのセキュリティ専門家ではないと明言しています。セキュリティという分野は非常に奥深く、日々変化していくものであり、悪意のあるAIがアプリケーションのセキュリティの穴を狙っているかもしれない、という指摘もされています。
対策としては、AIに「こういう理解で合っていますか」と繰り返し確認しながら理解を深めていく方法が勧められています。そうすれば、まったく分からないという状態にはならないはずだといいます。ただし、セキュリティの理解には技術的な知識が前提として必要であり、これまでの講義で学んできたような技術の教養がないと、理解の難易度は上がるとも述べられています。
なお、セキュリティについては別の教材「本気AIドリル」でも扱われます。