非エンジニアがAI生成コードを本番に出す前に見る判断基準──検証ゲートで欠陥率が81%から0%になった実測をもとに

コードを読めない非エンジニアは、AIエージェントが書いたコードの正しさを、コードそのものを見て判定することができない。だからといって、出てきたものをそのまま本番に出していいわけでもない。この記事では「コードの中身は読めなくても確認できる基準」を4つに絞って書く。抽象的な心構えではなく、Claude Codeの公式ドキュメントに実際にある設定と、自分の運用で検証工程の有無を比較した実測データにもとづく。

• Anthropicが公開した1,053人参加の実験によると、人間がその場でクリックして承認する方式は危険なコマンドの13.6%しか止められなかったのに対し、AIによる分類は89%を止めた
• 自社の運用でも、検証工程を挟まずに公開した記事21本のうち17本(81%)が修正の必要な状態で公開されていたのに対し、検証工程を挟んだ8本は0本だった
• Claude Codeの公式設定例には、.envのようなファイルの読み取りやcurlの実行を最初から禁止しておくdeny設定がある。人間の注意力に頼らず、機械的に塞げる穴は先に塞ぐという発想そのものが公式にも組み込まれている

4つの基準

その場のクリック承認は、思ったより機能しない

AIエージェントがコマンドを実行しようとするたびに「実行していいですか」と聞かれ、人間が中身を見て承認・却下する──この方式は一見安全に思えるが、Anthropicが2026年8月7日に公開した実験結果によると、実際の効果は薄い。1,053人の有償テスターを対象にした実験で、人間がその場で承認・却下を判断する方式は、危険なコマンドのうち13.6%（1,053件中143件）しか止められなかった。一方、Claude Codeの自動モード（auto mode）は89%（1,053件中937件）を止めている。両者を突き合わせると、自動モードは人間が承認してしまった800件のコマンドをブロックした一方、人間が自動モードの見逃しを止められたのはわずか6件だった、とブログは記載している。

この実験は実際の自分のコードベースではなく、研究用に用意されたテスト環境で行われたものだという注記がある。数字をそのまま実運用にあてはめられるわけではない。ただし、非エンジニアが「毎回中身を読んで判断する」という前提そのものが、期待するほど機能しないことを示す数字として参考になる。コードを読めない人間が、その場のクリックだけで安全性を担保しようとするのは、そもそも設計として無理がある。

ブログはさらに、セッションが長くなるほど人間の見逃しが増える傾向も報告している。セッション序盤では危険なコマンドの約17%を人間が止められていたが、直前に50回以上の許可プロンプトをこなした後では約5%まで低下した。一方、自動モードのブロック率はセッションの長さによらず一定だったという。非エンジニアが長時間の作業セッションで「後半になるほど確認が雑になる」のは、この実験結果からも裏付けられる傾向だ。

Anthropicは実運用データでも同様の傾向を報告している。2026年5〜6月に、安全パイプラインがレビュー対象として検知したセッション（データ利用に同意したアカウントのみ）を、0〜10の被害深刻度スケールで再評価したところ、本番環境相当の深刻度（7以上、例: 本番データベースの行削除）に達する意図しない有害な操作が、手動承認セッションでは6.3%発生していたのに対し、自動モードセッションでは2.4%だった。すべての深刻度帯でこの差は同じ方向だったとブログは述べている。

Anthropicは英国のAI安全スタートアップApollo Researchとも2週間の敵対的レッドチーミングを実施し、合成攻撃を実際のコーディング作業に注入するテストを行った。この結果を踏まえて自動モードの分類器を強化したところ、強化前に見逃していた攻撃の約半分を新たに検知できるようになった一方、強化前に検知できていた攻撃の約2%を新たに見逃すようになったという、トレードオフも同時に報告されている。

シークレットを読ませない設定を先に入れる

Claude Codeの公式ドキュメントには設定ファイルの例だけを集めた「Example settings files」というページがあり、deny(禁止)の例が2種類載っている。個人・プロジェクト向けの例はこの3行。

"permissions": {
  "deny": [
    "Read(./.env)",
    "Read(./.env.*)",
    "Read(./secrets/**)"
  ]
}

組織が配る managed-settings.json の例のほうは、curl を止める行が入った別の3行になっている。

"permissions": {
  "deny": [
    "Bash(curl *)",
    "Read(./.env)",
    "Read(./secrets/**)"
  ],
  "disableBypassPermissionsMode": "disable"
}

ただし同じ公式ドキュメントの権限ページは、Bash(curl http://github.com/*) のようにコマンドの引数まで絞ろうとするBashのパターンは脆弱だと注意している（オプションが前に付く・httpsになる・リダイレクトされる・変数展開されるといった形で、書いたパターンから簡単に外れるため）。上の組織向けの例が Bash(curl *) と引数を絞らない形になっているのは、その注意と整合する書き方だ。

APIキーやパスワードが書かれたファイルを、そもそもAIエージェントが読み取れない設定にしておけば、「出力に出てしまわないか毎回確認する」という負担そのものを減らせる。非エンジニアにとっては、事後にログを目で追ってシークレットが混ざっていないか確認するより、先に読み取れない設定にしてしまう方が確実で負担も小さい。

ここで見落としやすい点がある。Claude Codeのサンドボックス機能に関する公式ドキュメントには、次の記載がある。

デフォルトの読み取り動作：特定の拒否ディレクトリを除く、コンピュータ全体への読み取りアクセス。このデフォルトは ~/.aws/credentials や ~/.ssh/ などの認証情報ファイルの読み取りを許可することに注意してください。

つまり、サンドボックスを有効にしただけでは、AWSの認証情報やSSHの鍵はデフォルトで読み取り可能なままになっている。これらを塞ぐには、sandbox.credentialsという専用の設定ブロックで、ファイルパス（例: ~/.aws/credentials）と環境変数（例: GITHUB_TOKEN）の両方を個別にdeny指定する必要があると公式ドキュメントは説明している。「サンドボックス化＝安全」と早合点せず、認証情報だけは別枠で塞ぐ設定が要ることを覚えておく価値がある。

破壊的コマンドは事前確認を要求する

Claude CodeにはPreToolUseというフックの仕組みがあり、コマンドが実行される前に内容を検査して拒否できる。公式ドキュメントの例では、実行しようとしているBashコマンドの中身を確認し、rm -rfのような文字列が含まれていれば拒否するスクリプトが紹介されている。取り返しのつかない削除コマンドのような操作は、こうした仕組みで機械的に止める側に回した方が、人間が毎回注意して見るより確実だ。この仕組みで防げる事故と防げない事故の違いは、非エンジニアがAIコーディングで事故った話で具体例つきに書いた。

書いた本人以外が検証してから出す

最後の基準は、コードそのものの中身を読めない非エンジニアにとって、実質的にいちばん効く基準だ。2026年8月14日、同じモデルに書かせた記事を、検証なしでそのまま公開した21本と、書き手とは別の視点で裏取りしてから公開した8本を比較したところ、前者は17本(81%)が修正の必要な状態のまま公開されていたのに対し、後者は0本だった。

これは記事についての実測だが、コードでも構造は同じだと考えている。生成した本人(エージェント)がその場で「大丈夫です」と言うのと、別の視点で実際に動かして確認するのとでは、通過する不備の量が変わる。非エンジニアが自分でコードを読めなくても、「誰が最終確認したか」「どうやって確認したか」という工程の設計は判断できる。

この基準表でも防げなかったこと

正直に書いておくと、ここに挙げた4つの基準は、いずれも「実行しようとしている操作」や「公開しようとしている内容」の正しさを対象にしたものだ。別の記事で書いた、二重起動や作業ディレクトリのずれのような「今どういう状態か」の誤認から起きる事故は、この基準表の対象外になる。コマンドの中身は正しくても、実行するタイミングや状況の把握を誤れば事故は起きる。この基準表は「AIが書いた/実行しようとしている中身」を止める仕組みであって、状況認識のミスまでは防げない。

日常的にどんな作業をこの基準で回しているかは非エンジニアがClaude Codeで自社サイト運用を回した実測記録に、Gitの取り消し操作で気をつけるべき点は非エンジニアがGitを最低限使うための手順にまとめた。Anthropicの実験の全体像や、Claude Codeのauto modeについてはClaude Code、8月14日からautoモードがデフォルトにで詳しく書いている。