AIが書いたコードは誰が検査するか｜Claude新機能と現場の3つの守り

■ はじめに

社内の業務を効率化するために、AIに簡単なツールやプログラムを作らせる会社が増えています。ただ、出来上がったものを見て「これ、本当に安全なのだろうか」と不安になった経験はないでしょうか。

本記事では、Claudeが2026年7月に公開した、AIが書いたコードの危険な箇所を検査する新機能を取り上げます。スマートエイトは生成AIの研修と開発支援を通じて、多くの企業が「AIに任せた後のチェック」でつまずく様子を見てきました。

結論として、この新機能は「作らせて終わり」になりがちなAI活用に、検査の工程を足すものです。ただしツールを1つ入れれば安全になるわけではなく、組織としての備えが別に要ります。その全体像を、コードを書かない方にも分かるように整理します。

AIにコードを書かせる時代に、なぜ「検査」が問題になるのか|生成は速くなったが、確かめる手間は消えていない

AIがプログラムを書く速さは、この1〜2年で大きく上がりました。一方で、出来上がったものが安全かどうかを確かめる手間は、なくなっていません。むしろ生成の量が増えるぶん、検査すべき対象も増えています。

AIが書くコードが増えるほど、危険な箇所も一緒に増える

プログラムには、外部から悪用されると情報が漏れたり乗っ取られたりする「弱点」が混じることがあります。この弱点を＊脆弱性と呼びます。人が書いても混入しますが、AIに大量に書かせれば、その分だけ見落としも増えます。

問題は、書いた本人が非エンジニアの場合、どこが危ないのかを判断できない点にあります。動いているから大丈夫だと思って使い始めたツールに弱点が残っていても、気づけません。たとえば社内の申請フォームをAIに作らせたところ、入力された内容が誰でも見られる場所に保存される作りだった、というようなことが起こり得ます。

＊脆弱性：プログラムの弱点。悪用されると情報漏えいや不正アクセスにつながる箇所を指す。

これは経理の現場で先に起きたことと同じ構図です

同じことは、実は経理の現場で先に起きています。領収書や請求書を読み取って帳簿に入れる作業は、＊AI-OCRの普及でほぼ自動化されました。ところが現場の本当の負担は、入力そのものではなく「入力した後のチェック」に移りました。

金額の取り違えや二重計上を見つける工程は、自動化してもなくなりません。生成が速くなるほど、確かめる工程が仕事の中心になります。AIが書いたコードでも、まったく同じことが起きています。

AIの費用対効果を考えるときも、この検査や手戻りの手間を計算に入れる必要があります。生成の速さだけを見て「安くなった」と判断すると、後から見えないコストに気づくことになります。効果の測り方は「生成AIの費用対効果を測る4つの問い」で詳しく整理しています。

＊AI-OCR：紙や画像の文字をAIが読み取ってデータ化する技術。

Claude Securityは何をする機能か|AIが書いたコードを、別のAIが疑う

今回Claudeが公開したのは、AIが書いたコードの危険な箇所を自動で検査する仕組みです。「Claude Security」と呼ばれ、Claude Code（プログラム開発にAIを使うための道具）の中で使うプラグイン（追加機能）が、2026年7月22日に＊ベータ版として提供され始めました（Claude公式ポスト）。

＊ベータ版：正式版の前に、試せる状態で提供する段階。

コミット前でも、プログラム全体でも検査できます

この機能は、開発者が使う文字ベースの操作画面（＊ターミナル）から動きます。変更を保存して確定する前の段階で危険な箇所を洗い出すことも、プログラム全体をまとめて検査することもできます。

検出するのは、情報の抜き取りや認証の回避につながるような、深刻度の高い弱点が中心です。たとえば、入力欄から不正な命令を紛れ込ませてデータの中身を抜き取る手口や、本来ログインが必要な画面を認証なしで開けてしまう抜け穴などです。単純な文字の一致で探すのではなく、複数のファイルにまたがる複雑な弱点も追いかけると説明されています（Claude Security 製品ページ）。見つけた箇所には修正案が示されますが、それを反映するかどうかは常に人が決めます。自動では適用されません（Claude Code 公式ドキュメント）。

＊ターミナル：文字を打ち込んでコンピュータを操作する画面。開発の現場で使われる。

見つけた弱点を、AI自身がもう一度疑ってから出します

この機能で特徴的なのは、検出した弱点をそのまま報告せず、AIが自分の判断を一度疑い直す工程を挟む点です。「本当にこれは危険か」と自らに問い直してから表に出すことで、誤って危険と判定する数を減らしていると説明されています。

スマートエイトが研修で繰り返し伝えているのも、これと同じ考え方です。AIが作ったものを、同じ会話の中でそのまま点検させると、直前のやり取りに引きずられて点検が甘くなります。作る役と確かめる役を分け、校閲は新しい会話で行わせると、点検の精度が上がります。Claude Securityは、この「生成と検査を分ける」発想を、コードの安全性という分野で形にしたものと言えます。

検査は、他人の成果物よりも自分の成果物にこそ効きます。実際にスマートエイトがファクトチェックを実演したとき、他社の記事ではなく自社の資料の側に、古くなった名称や断定しすぎた表現が見つかったことがあります。作った本人は間違いに気づきにくいからこそ、別の目で確かめる工程を仕組みにする意味があります。

使える範囲は広がっている途中です

「Claude Security」という名前は、提供の形が2つに分かれている点に注意が必要です。1つは、今回取り上げたClaude Codeの中で使うプラグイン版で、Claude Codeの有料プランを使う人がベータで試せます。もう1つは、企業向けに管理された形で提供されるもので、こちらはClaude Enterprise向けに先行して広く試せるベータが始まっています（Anthropic公式ブログ）。

いずれもベータの段階なので、対応するプランや条件は今後変わる可能性があります。導入を検討する際は、その時点の公式情報を確認してください。

なぜスキャンだけでは足りないのか|「出口の検査」と「入口の設計」は別物

検査機能は強力ですが、これだけでセキュリティが完結するわけではありません。スキャンは、出来上がったコードの弱点を見つける「出口の検査」です。その手前には、AIに何を触らせるかを決める「入口の設計」があります。両者は役割が違い、どちらか一方では足りません。

スキャンは出口、権限の設計は入口です

いくら出口で弱点を見つけても、AIが最初から重要な情報や本番のデータに触れる状態だと、事故は入口で起きます。たとえばAIに、システムへアクセスするための＊秘密鍵を読める状態で作業させれば、その鍵が生成物やログに紛れ込む危険があります。

長く自動で動くAIを安全に使う関門の考え方は「AIエージェントの暴走対策」でも整理しています。検査と入口の設計は、必ずセットで考える必要があります。

＊秘密鍵：システムやサービスにアクセスするための鍵となる文字列。漏れると不正利用につながる。

組織として決めるのは、まず3つだけで十分です

スマートエイトが企業のAI導入を支援するとき、組織の設定で「必ず守る」と決めるのは、次の3つに絞ることを勧めています。あれもこれもと禁止を増やすと、現場が使わなくなるからです。

• 秘密鍵など重要な情報をAIに読ませない
• 顧客の資産（データや外部サービス）にAIが勝手に書き込めないようにする
• AIが使うソフトの最低限のバージョンを決めて、古いまま使わせない

この3つに絞る理由は、事故の大きさが違うからです。秘密鍵は一度漏れると不正利用が一気に広がります。顧客資産への書き込みは、誤操作がそのまま金銭の損失につながります。古いバージョンの放置は、すでに世に知られた弱点を抱えたまま使い続けることになります。

この3つを土台にして、残りは「禁止」ではなく「実行前に人へ確認する」に緩めると、安全と使いやすさのバランスが取れます。データを書き換えたり外部へ送ったりする、取り返しのつかない操作だけ、人の承認を挟む設計です。

AIに開発を任せる会社が、明日からやる3つのこと|検査を仕組みにする

最後に、コードを書かない立場でも今日から始められる手順を挙げます。どれも30分から1時間で終わるものです。

AIに作らせている業務を1つ選び、検査の担当を決める

まず、社内でAIに作らせているツールや自動化を1つ選びます。そのうえで「出来上がったものを、誰が、どうやって確かめているか」を紙に書き出します。ここが空欄なら、それが最初に埋めるべき穴です。

たとえば問い合わせ内容を自動で分類するツールをAIに作らせたなら、その分類結果を誰が最終確認しているか、顧客の情報がどこに保存されているかまで確認します。担当が決まっていない状態は、動いていても未完成です。

権限は「読むは広く、書くは止める」から始めます

AIに与える権限は、最初から欲張らないほうが安全です。情報を読み取る操作は広く許し、データを書き換えたり外部へ送ったりする操作は止める、という順番にします。読み取りは分析の価値そのものなので止めず、取り返しのつかない書き込みだけを承認制にします。

この考え方は、顧客の資産に触れる仕組みでは特に重要です。誤操作が金銭の実損に直結する領域では、読む権限は広く、書く権限は狭く、が基本の型になります。

検査は自動化しても、承認は人が握ります

スキャンや検査は自動で回して構いません。ただし、その結果を反映するかどうかの最終判断は人が持ちます。スマートエイトが自社でSNS投稿や記事作成を自動化しているときも、「集める・作る・人が承認する・実行する」の流れにして、承認の一手だけは必ず人に残しています。

自動化の目的は、人の判断をなくすことではありません。人が判断すべき場所に集中できるように、それ以外を任せることです。検査を仕組みにすると、この「集中すべき場所」が明確になります。

よくある質問|AIが書いたコードの安全性

AIが書いたコードの安全性について、研修や商談でよく受ける質問をまとめます。

AIが書いたコードは、人が書くより危険ですか？

一概に危険とは言えません。人もAIも弱点を混入させます。違いは量とチェック体制です。AIは短時間で大量に書けるぶん、検査の仕組みがないと見落としが積み上がります。逆に検査を仕組みにすれば、人より安定して弱点を洗い出せる場面もあります。

Claude Securityは無料で使えますか？

ベータの段階で、Claude Codeの有料プランを使う人は、ターミナルから使うプラグイン版を試せます。企業向けには、管理された形の提供がClaude Enterprise向けに先行して始まっています。ただし提供範囲や条件はベータのため変わりやすく、料金体系も含めて、導入前にその時点の公式情報を確認することをおすすめします。

非エンジニアでも扱えますか？

検査機能そのものは開発の道具の上で動くため、操作には一定の慣れが要ります。ただし、非エンジニアの経営者や管理者が担うのは操作ではなく設計です。「どこまでAIに触らせるか」「誰が承認するか」を決める役割は、コードを書けなくても果たせます。

スキャンツールを入れれば、対策は十分ですか？

十分ではありません。スキャンは出来上がったものを調べる出口の検査です。その手前の、AIに何を触らせるかを決める入口の設計が抜けていると、事故は防げません。検査と設計は必ずセットにしてください。

■ さいごに

本記事では、AIが書いたコードの弱点を検査するClaudeの新機能と、それだけでは埋まらない組織の備えを解説しました。生成が速くなった今、競争力を分けるのは「作る速さ」ではなく「確かめる仕組み」です。

Claude Securityのような検査は「出口」を守ります。その手前で、秘密鍵を読ませない、顧客資産に書き込ませない、古いバージョンを使わせない、という「入口」の3つを決めておくことが、事故を未然に防ぎます。「AIに作らせているが、安全かどうか誰も確かめていない」という企業ほど、まずは検査の担当と承認の線引きから始めることをおすすめします。

スマートエイトの生成AI研修では、AIを使う設計から、安全に任せる権限と承認の仕組みづくりまでを、実務に落ちる形で支援しています。

詳細はお気軽にスマートエイト公式サービスページからお問い合わせください。貴社の状況に合わせた最適な進め方をご提案します。 ※生成AI研修資料/導入事例も無料ダウンロードいただけます。