【2026年最新】ゴールドマン・サックスがClaude Codeなどの利用を制限！AI開発のリスクと中小企業の対策

「AIに指示するだけで、業務システムが作れる！」

生成AIの進化によって、プログラミングの専門知識がない人でも、アプリや業務ツールを作りやすくなっています。

しかし、その便利さをどこまで会社の業務に取り入れるべきなのでしょうか。

2026年11月2日、Bloombergは、米国の大手金融機関ゴールドマン・サックスが、
Claude Codeなどの高度なAIコーディングツールについて、非エンジニアによる利用を大幅に制限したと報じました。

同社は数カ月前まで、銀行員やトレーダーにもこうしたツールの利用を認めていました。

ところが、生産性やリスク管理などを検証した結果、利用できる社員の範囲を見直したというのです。

「AIで誰でもシステムが作れるのは、いいことじゃないの？」

「なぜ、大手企業が利用を制限するの？」

「中小企業もAIによる開発を禁止した方がいいの？」

今回は、DX担当ちゃま男と先輩の会話を交えながら、ニュースの背景と、中小企業がAI開発を安全に活用するための具体策を解説します！

ゴールドマン・サックスがAIコーディングツールの利用を制限

2026年10月に社内指針を変更

2026年11月2日のBloomberg報道によると、ゴールドマン・サックスは10月に社内のAI利用指針を更新しました。

これまで銀行員やトレーダーにも認めていた高度なAIコーディングツールの利用を、原則としてエンジニアに限定したとされています。

報道で挙げられているのは、Anthropicの「Claude Code」や、Microsoft傘下のGitHubに関連する開発ツールです。

なお、報道の「GitHub」が具体的にどの製品・機能までを指すかは明確ではありません。GitHub全体やGitHub Copilotのすべての利用を禁止したと解釈するのは適切ではありません。

また、金融取引とソフトウェア開発の両方を専門とする「ストラッツ」と呼ばれる職種は、制限の対象外と報じられています。

数カ月前まではAIによる開発を積極的に評価

今回のニュースが注目されている理由の一つは、同社が以前、非エンジニアによるAI活用を評価していたことです。

2026年7月、同社の最高情報責任者（CIO）であるマルコ・アルジェンティ氏は、トレーダーや銀行員がAIを使って業務に役立つ仕組みを作成していることを紹介していました。

例えば、次のような業務です。

• 顧客の取引動向を把握する
• 市場の変化を分析する
• 保有資産の動きをモデル化する
• 文章やグラフを作成する

非エンジニアがAIで試作品を作り、それを専門のエンジニアへ引き継いで改良する取り組みも行われていたといいます。

ところが今回、利用できる社員の範囲を見直すことになりました。

なぜ利用を制限したのか？

同社の広報担当者はBloombergに対し、社内のさまざまな業務でAIツールを試験的に利用し、生産性やリスク管理などを評価したうえで、長期的な活用に適した社員へ利用対象を絞っていると説明しています。

ここで注意したい点があります。

今回の利用制限が、Claude Codeによる情報漏えいや重大なシステム事故を原因として実施されたという事実は確認されていません。

また、ゴールドマン・サックスが生成AI全体の利用を禁止したわけでもありません。

今回のニュースは、企業がAIツールの利用範囲を検証し、業務や職種に応じて調整した事例として捉える必要があります。

出典：Bloomberg｜ゴールドマン、トレーダーらの一部AI利用を制限（2026年11月3日日本語報道）

Claude Codeとは？なぜ非エンジニアでもシステムを作れるのか

AIに日本語で指示するだけでプログラムを作成

例えば、次のような指示を考えてみましょう。

「Excelの売上データを読み込み、月別の売上を自動集計するツールを作ってください」

Claude CodeなどのAIコーディングツールは、指示をもとにプログラムを作成し、動作確認や修正を支援できます。

さらに、既存のソフトウェアの内容を読み取り、変更が必要な箇所を探すこともできます。

こうした技術の進化によって、専門的なプログラミング経験が少ない人でも、業務ツールの試作品を作りやすくなっています。

バイブコーディングとは？

最近は、自然な言葉でAIに指示し、プログラムの細かな記述をAIに任せる開発方法を「バイブコーディング」と呼ぶことがあります。

例えば、

「在庫が10個以下になったら、担当者へメールを送る仕組みを作って」

と伝えると、AIが必要なプログラムを生成するイメージです。

ただし、AIがコードを書いたからといって、必ず正しい仕組みが完成するわけではありません。

AIコーディングツールは通常のチャットAIとは異なるリスクがある

Claude Codeの開発元であるAnthropicも、ファイルの編集やコマンド実行などができることに伴うリスクを公式に説明しています。

例えば、AIが本来意図していないファイルを変更したり、外部から読み込んだ悪意のある指示に影響されたりする可能性があります。

そのため、Claude Codeには権限確認やサンドボックスと呼ばれる実行範囲の制限機能などが用意されています。

出典：Anthropic公式｜Claude Codeのセキュリティと権限管理

なぜ企業はAIによるシステム開発に慎重になるのか？

AIでプログラムを作ること自体が問題なのではありません。

問題になるのは、作成されたシステムの品質、安全性、運用責任が明確になっていないことです。

中小企業でも考えられる4つのリスクを見ていきましょう。

① AIが作成したプログラムに不具合がある

例えば、AIを使って在庫管理プログラムを作成したとします。

一見すると正常に動いていても、次のような問題が残っているかもしれません。

• 同じ入庫データを二重に登録してしまう
• 在庫数がマイナスになっても処理を続ける
• 通信エラーが発生したときに処理が途中で止まる
• 本来アクセスできない人が在庫データを変更できる

こうした問題は、通常の画面操作だけでは気づきにくい場合があります。

GitHubも、AIが生成したコードには不正確な処理やセキュリティ上の問題が含まれる可能性があり、レビューやテストが必要だと説明しています。

② 機密情報を外部AIへ送信してしまう

AIにプログラムを作らせる過程で、社内のデータやソースコードを参照させる場合があります。

ソースコードとは、プログラムの動作を記述したものです。

そこには、社内システムの構成、接続先、場合によっては認証情報などが含まれることがあります。

また、AIが業務データを扱う場合、顧客情報や製造ノウハウなどの機密情報にアクセスする可能性もあります。

情報の送信先や保存方法、利用条件、権限を十分に確認せずに使用することは避けるべきです。

ただし、AIコーディングツールを使用すると必ず情報が漏れるという意味ではありません。

適切な契約や権限設定、利用環境の構築によってリスクを抑えることができます。

③ 作成した本人しかシステムを管理できない

例えば、営業担当者がAIを使って見積計算ツールを作成したとします。

最初は問題なく動いていても、担当者が退職した後に計算方法を変更する必要が出てきたらどうでしょうか。

誰もプログラムの内容を把握していなければ、修正や保守が難しくなります。

これは、ExcelマクロやAccessなどで以前から見られた属人化の問題とも共通しています。

AIによってシステムを作りやすくなるほど、管理されていないツールが社内に増える可能性もあります。

④ 本当に業務効率化につながっているかわからない

AIを使えば、短時間でプログラムを作成できる場合があります。

しかし、開発時間が短くなったからといって、システム全体の費用が必ず安くなるわけではありません。

例えば、開発にかかった時間は減っても、次のような作業が増える可能性があります。

• 不具合の修正
• セキュリティの確認
• 運用マニュアルの作成
• 担当者への教育
• システムの継続的な保守

重要なのは、開発時点の作業時間だけでなく、運用開始後の費用や効果も確認することです。

AIによる開発は禁止すべき？中小企業が考えたい判断基準

今回のニュースを見て、「AIでのシステム開発を禁止した方が安全なのでは」と考える企業もあるかもしれません。

しかし、すべてのAI開発を一律に禁止する必要があるとは限りません。

重要なのは、開発するシステムのリスクに応じて管理方法を変えることです。

AI開発の利用範囲を3段階で考える

区分	業務の例	推奨する管理方法
低リスク	公開情報を使った資料作成補助ツール、個人用の試作品	社内ルール内で試験利用
中リスク	部門内の集計ツール、社内向け業務アプリ	管理者の承認・テストを実施
高リスク	受発注、原価、給与、個人情報、本番設備に関わるシステム	専門家のレビュー・厳格な権限管理・正式な検証を実施

※これは中小企業向けの運用例であり、公的機関が定める正式な分類ではありません。実際のリスクは扱うデータや外部接続、システム停止時の影響によって変わります。

例えば、個人が架空のデータを使って集計ツールを試す場合と、会社の実際の受注データを自動で変更するシステムでは、求められる管理水準が異なります。

すべてのAI開発を同じルールで管理するのではなく、業務上の影響に応じて承認や検証の水準を変えることが合理的です。

中小企業がAI開発を安全に進めるための5つのルール

では、実際に企業がAIコーディングツールを導入する場合、何を決めておくべきなのでしょうか。

ルール① AIで開発してよい業務の範囲を決める

まず、AIを使って開発してよい業務の範囲を明確にしましょう。

例えば、以下のようなルールです。

• 個人用の試作品は許可する
• 実際の顧客情報は事前承認なしで使用しない
• 本番システムへの直接接続は禁止する
• 業務データを自動更新する仕組みはレビューを必要とする
• 経理・給与などの重要業務は管理者の承認を必要とする

このように利用範囲を決めるだけでも、無秩序な開発を防ぎやすくなります。

ルール② AIに与える権限を最小限にする

AIがプログラムを作成・実行する際は、必要以上の権限を与えないことが重要です。

例えば、データを参照するだけの作業であれば、データを削除・更新できる権限まで与える必要はありません。

また、次のような対策も検討しましょう。

• 本番環境ではなくテスト環境を使用する
• AIが操作できるフォルダーやファイルを制限する
• 本番用のAPIキーを試験開発に使用しない
• 重要な操作には人の承認を必要とする
• 操作履歴を記録する

AIの作業範囲を限定することは、誤操作や情報漏えいのリスクを下げるうえで重要です。

ルール③ 業務で使う前にテストとレビューを実施する

AIが作成したプログラムについては、実際の業務に導入する前に検証しましょう。

例えば、在庫管理ツールであれば、次のようなテストが考えられます。

• 在庫数が0になった場合
• 同じデータを二重に登録した場合
• 存在しない品番を入力した場合
• 通信が途中で切れた場合
• 権限のないユーザーが操作した場合

正常に動くことだけでなく、異常な状態になったときにも適切に対応できるか確認することが重要です。

特に重要な業務については、開発者とは別の担当者や専門家によるレビューを推奨します。

ルール④ システムの管理責任者を決める

例えば、次のような役割分担が考えられます。

担当	主な役割
業務担当者	課題の整理、要件の確認、業務テスト
開発担当者・外部専門家	プログラムの確認、不具合修正、技術的な検証
IT管理者	アクセス権限、セキュリティ、運用環境の管理
経営者・部門責任者	導入判断、費用対効果、業務上のリスクの判断

もちろん、すべての中小企業に専門のIT部門があるわけではありません。

その場合は、外部のシステム開発会社やIT保守会社と役割分担を決めることも有効です。

ルール⑤ 開発したプログラムと運用手順を残す

AIで作成したシステムについても、最低限の管理資料を残しましょう。

例えば、次のような情報です。

• システムの目的と利用部門
• ソースコードの保存場所
• 使用している外部サービス
• 管理者と連絡先
• データの保存先
• 更新・修正履歴
• バックアップと復旧手順

また、変更前の状態に戻せる仕組みを用意することも重要です。

AIがプログラムを変更した結果、不具合が発生した場合に備えて、過去の正常な状態を残しておきましょう。

参考となる公的ガイドライン

IPAは、AIを活用したソフトウェア開発について、コード生成やレビュー、テストなどの活用動向を整理しています。

また、2026年には製品開発者と製品利用者向けのセキュリティガイドも公開しています。

• IPA｜AIを用いたソフトウェア開発
• IPA｜製品開発者向け・製品利用者向けガイド
• 経済産業省｜AI事業者ガイドライン第1.2版

製造業ではどう考える？AIによる業務システム内製化の可能性

中小製造業では、紙やExcelで管理している業務が数多く残っています。

例えば、次のような業務です。

• 設備保全の点検記録
• 製造指示書の管理
• 品質検査記録の集計
• 原材料や部品の在庫管理
• 受注情報と生産進捗の共有

こうした業務を改善するために、生成AIを活用してシステムを開発する選択肢も広がっています。

AIで作れることと、現場で安全に使えることは違う

例えば、原材料の在庫を管理するシステムをAIで作成したとします。

画面に在庫数量が表示され、入庫や出庫を記録できれば、試作品としては完成したように見えるかもしれません。

しかし、実際の製造現場では、さらに検討すべきことがあります。

• 同じ伝票を二重に登録しない仕組み
• ロットごとの在庫管理
• 棚卸差異が発生した場合の調整方法
• 複数担当者が同時に操作した場合の整合性
• 入出庫履歴の追跡
• システム障害時の復旧方法

こうした要件が整理されていなければ、システム自体は動いていても、実際の業務で問題が発生する可能性があります。

つまり、プログラムを作る技術だけでなく、現場業務を理解してシステムの要件を設計することが重要なのです。

kintoneなどの業務基盤とAI開発を組み合わせる方法もある

すべてのシステムをAIにゼロから作らせる必要はありません。

例えば、kintoneのような業務プラットフォームを使って、データ管理やアクセス権限などの基本機能を活用しながら、必要な部分をAIによる開発で補う方法もあります。

ただし、既存の業務プラットフォームを利用していても、追加開発したプログラムの品質や権限管理については確認が必要です。

重要なのは、AI開発か既存システムかという二者択一ではありません。

既存の業務基盤で対応できる部分と、独自開発が必要な部分を見極めることが、費用とリスクのバランスを考えるうえで重要です。

AI開発を始める前に、自社の準備状況を確認しよう

AIコーディングツールを導入する前に、企業として確認しておきたいことがあります。

それは、社内の業務やデータ、運用ルールがどこまで整理されているかという点です。

例えば、業務の手順が担当者によって異なっていたり、使用するデータの形式が統一されていなかったりすると、AIを使った開発でも手戻りが増える可能性があります。

関連サービス｜AI READY診断 for 製造業

ラック・インターナショナル株式会社では、企業のAI活用に向けた準備状況を確認できる「AI READY診断 for 製造業」を無料公開しています。

データ化・構造化・言語化などの観点から、自社の現状を確認できます。

全10問・約3分・会員登録不要で利用できます。

▶ AI READY診断｜自社のAI活用準備状況を無料チェック

※本診断は独自の簡易セルフチェックであり、AI開発の安全性を保証するものではありません。

まとめ｜AIでシステムを作れる時代こそ「運用責任」が重要になる

今回のゴールドマン・サックスのニュースは、AIコーディングツールの活用について、大手企業でも利用範囲やリスクを見直していることを示しています。

ただし、同社がAI開発そのものを否定したわけではありません。

むしろ、試験的に利用した結果を踏まえ、どの職種に高度なAI開発ツールを提供するかを調整した事例と捉えることができます。

中小企業でも、AIによる開発を無条件に禁止する必要はありません。

一方で、自由に開発させるだけでは、品質やセキュリティ、保守の問題が発生する可能性があります。

重要なのは、次の3つです。

① 誰が開発してよいのかを決める

② 誰が安全性や品質を確認するのかを決める

③ 誰が運用・保守の責任を持つのかを決める

AIによってプログラムを作ることが簡単になっても、会社として安全に使い続ける責任がなくなるわけではありません。

「AIで作れること」と「企業として運用できること」は別問題です。

AIの開発スピードを活かしながら、業務に必要な品質と安全性を確保すること。

それが、これからの中小企業に求められるAI活用の考え方ではないでしょうか。

参考資料・公式情報

• Bloomberg｜ゴールドマン・サックスのAIコーディングツール利用制限（英語）
• TBS CROSS DIG with Bloomberg｜日本語報道
• Anthropic｜Claude Codeの安全な利用と権限管理
• GitHub｜AIエージェント利用時の注意事項
• IPA｜AIを用いたソフトウェア開発
• IPA｜製品開発者向け・製品利用者向けガイド
• 経済産業省｜AI事業者ガイドライン第1.2版

※本記事は2026年11月3日時点の公開情報をもとに作成しています。ゴールドマン・サックスの社内指針の詳細はBloombergの取材報道に基づいており、同行の社内規程全文を独自に確認したものではありません。