デザインレビューで止まる「第三者評価は？」の先
たとえば、次の四半期の生成AI基盤を決めるレビューです。候補は大手クラウドのフロンティアモデル、別ベンダーのエンタープライズ向けモデル、必要なら閉域の自社ホストです。
セキュリティから出る質問は、いつも同じ形になります。
「第三者評価は入っているか」
「インシデントは報告されるか」
「うちの用途で、どこまでテストされているか」
ここまでは健全です。問題は、その先です。評価の基準そのものを、誰が書いたのか。参入できるベンダーの条件が、巨大な計算資源や常駐の外部評価チームまで含むと、名簿は最初から狭くなります。安全の話が、気づかないうちに調達の話へ移ります。
この「誰が合格ラインを書くのか」という問いが、2026年9月にCEO同士の公開論争として表に出ました。Anthropic CEOのDario Amodei氏は、フロンティア開発のペースを揃えつつ安全を検証するロードマップを示し、必要なら狭い独占禁止法の免除（antitrust waiver）を政府に求めました。Cohere共同創業者兼CEOのAidan Gomez氏は、独立レビュー自体は支持しつつ、「少数の市場上位企業が世界のルールを書く構図」に反対するエッセイを出しました。
本稿では、どちらが正しいかを決める記事にはしません。IT技術者として、誰が基準を書くかが、ベンダー選定・評価設計・運用コストにどう効くかを整理します。
Amodei氏とGomez氏は、何を提案し、何を問うたのか
現場に効く争点を追うには、まず双方の主張の骨格を揃えておく必要があります。Amodei氏のエッセイ We Must Pace the Frontier の骨子は、次の3段階です。
-
常駐の第三者評価者（embedded evaluators）をフロンティア企業に置き、安全慣行の実行を検証する
-
民主国のフロンティア企業が、共通の安全基準と「無制限の能力拡張」への限度を協調して決める
-
可能なら国際協調へ広げる
争点になったのは2です。競合企業が「何を出すか・どの速さで進めるか」を合意すると、独占禁止法上の問題になりうるため、米国政府に狭い免除や仲介を求める、という書き方になっています。Amodei氏自身も、法令による規制が本筋だとしつつ、法制化が間に合わないあいだの並行ルートとして協調を置いています。
Gomez氏の Who Gets to Define the Rules for AI? は、独立レビューへの賛成を先に述べたうえで、次を問います。
-
レビューが依拠する標準は誰が書くのか
-
誰がレビューを行い、誰が監督するのか
-
ルール作りの会話に、誰が入れるのか
ここで言う「安全」は、モデルの誤答やバイアスだけの話ではありません。サイバー攻撃支援、詐欺、重要インフラへの接続など、実害につながる能力の扱いです。公的枠組みが揺れても、現場の運用・セキュリティ・ガバナンスの責任は残る、という見方は 「AI規制は嫌いだ」——その一言の先に、IT技術者が担う運用・セキュリティ・ガバナンスでも整理しています。今回の論争は、その「現場責任」の前提条件——何を合格とするか——を誰が決めるか、という一段上の話です。
両者が共有していること、分かれること
共有していること
両者とも、「AIにガードレールは要る」という前提は共有しています。Gomez氏は銀行・通信・防衛など高リスク領域への導入経験を前提に、サイバー攻撃能力の安価化が防衛より速いことへの懸念も書いています。Amodei氏は、能力向上の加速やエージェント群の逸脱事例を挙げ、安全対策が追いつく時間を確保したいと述べています。
独立した第三者による検証という方向性も、対立ではありません。争点は検証の有無ではなく、何を合格とするか、誰がその基準に参加できるかです。
分かれること
Amodei氏側の構図は、「フロンティア企業＋常駐評価者＋（必要なら）政府の免除」で、基準とペースを先に揃えやすくする点にあります。検証可能性を高め、商業的不利を恐れて安全投資を後回しにする競争を抑えたい、という意図が読み取れます。
Gomez氏側の懸念は、その揃え方が既存の上位企業の条件を、業界全体の参入条件にしてしまうことです。エッセイでは、計算資源の規模、常時監視、専任セキュリティ組織、バッジ付きの常駐評価チーム、シャットダウン設計、深い政府関係など、提案に含まれる参入要件を列挙し、すでに上位にいる企業に有利だと指摘しています。
加えて、リスクを「規模」や巨大計算の関数として定義すると、巨大システムを持つ側だけが審査資格を持つ構図になりやすい、とも述べています。小さなモデルでも、ツールと検証ステップを組み合わせたオーケストレーション（いわゆるサイバースウォームのような構成）は、単体の巨大モデルとは別のリスク面を持ちます。ここを見ない基準は、現場の脅威モデルとずれます。
では、なぜ Gomez 氏はそこまで強い言葉で反対するのか。次に、彼が持ち出す過去の制度設計を見ます。
「安全のための門番」が、既存勢力を守った例
Gomez氏は「カルテル」という言葉を、雰囲気だけの非難ではなく、制度設計の失敗例として使います。安全を名目にした門番が、結果として既存勢力を守った、という読み方です。
1975年の格付け機関
米国SECが資本規制のために債券格付けを必要とし、3社を「国家認定の統計的格付け機関」に指定した一方、他社が同じ地位を得る基準を公開しなかった、という整理です。評価者は発行体から報酬を受け、規制が作った壁の内側にいました。四半世紀後も3社のまま残り、のちにサブプライム関連証券をトリプルAと格付けし、2008年の危機の文脈で強く批判されました。
1985年の自動車ブロック免除
欧州では、複雑な車両の安全のためとして製造者が販売・整備の資格をコントロールできる独占禁止法上の免除が広がりました。建前は安全な車両です。結果として既存勢力の保護が長く続き、欧州委員会がほどくのに約25年かかった、というのが Gomez 氏の読みです。
どちらの例も、「最初から悪意があった」とは書かれていません。意図は安全でも、誰が基準を書き、誰が入場できるかを閉じると、市場構造が固定されやすい——これが技術者向けの教訓です。調達要件に「特定の評価枠組みへの参加実績」だけが並ぶと、同じ型の問題が社内のベンダー名簿にも入ります。
批判だけで終わらせないために、Gomez氏は代替案も示しています。次は、その4本柱を現場の判断軸に訳します。
Gomez氏が示す4本の柱を、現場の判断軸に訳す
Gomez氏は「自分がルールを書く側になるべきだ」とは言わず、政府・立法が検討できる実務案として4本柱を挙げています。ここをITの判断軸に落とします。
証拠に基づくリスク枠組み
先に監査を義務化するのではなく、どの危害を心配するか、どの能力がどの条件で危害につながるか、いつ政府が介入するかを、公開された形で合意する、という柱です。一国の閉じた安全保障議論だけに閉じず、複数国・技術者・政策・重要セクターの専門家を入れ、意見の不一致も公開する、と書かれています。
現場では次のように読めます。社内のAIリスク分類を、「ベンダーのブランド」や「パラメータ数」だけで切らない。できることと触れるシステム（顧客データ、本番API、重要インフラ隣接）で切る。国際標準の側から同じ問いを見るなら、ITU・ISO・IECのAI標準化がITシステム設計に与える影響 の設計チェック観点も参考になります。
義務的な透明性
モデルカード相当の公開に加え、開発・配備の各層で深刻なインシデントを報告し、実害への説明責任をつなぐ、という柱です。PoC段階でも、「重大インシデントの定義」と「社内報告先」を先に決めておくと、後からベンダー契約へ載せやすいです。
証拠でスコープしたテスト
あらゆるリスクの総点検ではなく、サイバー攻撃生成、合成詐欺・音声クローン、大規模操作、生物化学兵器、重要インフラ接触など、枠組みが危険と認めた能力にテストを集中させる、という柱です。能力が高い、または特定コンテキストに置くシステムほど厳しくする段階制も提案されています。
無制限のコンプライアンスは、最大手の予算に合わせて膨らみます。中小ラボや社内モデル、オープンウェイトが先に窒息しやすい、という警告は調達側にも効きます。「全部やれ」ではなく、「この用途で何が危険か」から逆算する方が、現場のレビューは通りやすいです。
利益相反のない保証
金融のライセンス、航空の安全、原子力の検査のように、開発者の自己テスト、顧客側の検証、必要に応じた第三者、規制の監視という層を積む、という柱です。第三者は、被監査企業から報酬を受けないこと、公開可能な結論を持つこと、基準は被測定企業以外が合意すること、が条件として挙げられています。
常駐評価者そのものを否定しているわけではありません。誰が選び、誰が払い、何を公開できるかが、捕捉（capture）を生むかどうかを分ける、という指摘です。
4本柱は政策論に見えますが、自社の運用設計とベンダー依存の置き方にもそのまま効きます。次にその接続を見ます。
4本の柱が、自社運用とベンダー依存に効くところ
透明性・スコープ付きテスト・利益相反のない保証を現場に落とすと、論点は2つに分かれます。ひとつは供給者をどれだけ替えられるか。もうひとつは、モデル単体ではなくエージェントやツールまで含めて観測・制限できるかです。
少数ベンダーへの依存を減らし、自社制御可能な運用へ寄せる話は、「借りるAI」から「持つAI」へ——Cohere Command A+が開いた、ソブリンAIの現実 ともつながります。Gomez氏のエッセイ末尾でも、病院・決済・防衛が敏感データを閉じたインターフェースの向こうに預けるリスクと、供給者の多様性が障害を吸収するという主張が続きます。ソブリンAIは製品名の話ではなく、失敗したときに乗り換えられるかの話でもあります。
テスト時の観測性や、ツール到達範囲の制限は、エージェント統制の設計と同じ問題です。エージェンティックAI時代のセキュリティは防御から統制へ——「動くAI」を止めずに制御する設計へ が述べた権限分離・監査・停止権限は、Gomez氏が挙げる「指示の質」「テストの壁の強さ」「監視なしで動かし続ける時間」への対処と重なります。巨大計算の上限だけでは、そこは埋まりません。
では、四半期の選定表には何を書けばよいか。次のチェック観点に落とします。
ベンダー選定で先に決めておくチェック観点
政策論争の決着を待たなくても、次の四半期の選定表には載せられます。コードというより、契約・設計レビュー用のチェックリストとして使えます。
# 前提: 用途とデータの機密度は別シートで定義済みとする
vendor_eval:
transparency:
- model_card_or_equivalent: required # 能力・制限・テスト概要
- incident_reporting_path: required # 重大事象の定義と通知期限
- redaction_policy: preferred # 不利な結論を消されない契約があるか
risk_scope:
- evaluated_capabilities: list # サイバー／詐欺／重要システム接触など
- deployment_context_tested: list # 自社の用途に近い条件か
- not_only_compute_threshold: true # 規模だけで合格になっていないか
assurance:
- independent_party: preferred
- auditor_paid_by_vendor: false # 利益相反の有無を確認
- findings_public_or_customer_visible: preferred
operational_control:
- on_prem_or_vpc_option: optional # 機密度に応じて必須化
- kill_switch_and_tool_scope: required
- replaceability: preferred # 乗り換え可能な abstraction があるか
このYAMLは動くプログラムではありません。レビュー議事のアジェンダとして貼り、項目ごとに「必須／推奨」を用途別に塗り替えるためのたたき台です。機密度の高い業務では on_prem_or_vpc_option を必須にし、社内向けチャットボットでは透明性とインシデント経路を厚くする、といった調整ができます。
インシデント報告の最小項目も、社内で先に決めておくとベンダー交渉が楽になります。
{
"incident_id": "INC-2026-0918-001",
"detected_at": "2026-09-18T10:15:00Z",
"severity": "agent_tool_misuse",
"systems_touched": ["ticket_api", "read_only_kb"],
"data_classes": ["internal"],
"containment": ["revoked_tool_scope", "paused_agent"],
"customer_impact": "none_confirmed",
"next_update_by": "2026-09-18T16:00:00Z"
}
カテゴリ名は組織に合わせて変えて構いません。大切なのは、「重大」の定義と、顧客へ見える更新期限を先に決めておくことです。
チェックリストを使う前に、読み違いやすい点だけ押さえておきます。
読み違いやすい3つの点
「独立レビューに反対している」わけではない
Gomez氏は独立レビューを支持すると明言しています。反対しているのは、少数の商業プレイヤーが基準とペースを決め、他者に従わせるための免除付き協調です。Amodei氏側も、法令による規制を否定しているわけではありません。読み違いをすると、議論が「安全派 vs 反安全派」に潰れます。
「スローダウン＝常に危険回避」でもない
ペースを落とすこと自体が悪いわけではありません。落とした時間で何をするか、誰が合格ラインを書くかで結果が変わります。Amodei氏は運用品質・アライメント・解釈可能性・評価の強化に使う時間だと説明しています。Gomez氏は、その合格ラインが既存優位を温存しないかを見ています。
「フロンティアだけ見ていれば現場は安全」ではない
Gomez氏が指摘するように、病院内の小さくて仕様が甘いモデルは、今日すでにリスクです。フロンティア専用の制度だけだと、そこは視野に入りません。社内のリスク台帳は、モデルのブランド名より接続先と権限を先に書く方が実務に合います。
現場で先に決められる3点
政策の結論を待つ必要はありません。次の3点だけでも、四半期のうちに決められます。
危険能力と配置コンテキストの対応表
社内の「危険能力」と「配置コンテキスト」の対応表を1枚作ります。サイバー支援、対外発信の自動化、本番変更、機微データへのツール接続などを行に置き、列に承認とテストの深さを置きます。
契約に載せる透明性の最小セット
ベンダー契約に載せる透明性条項の最小セットを決めます。モデルカード相当、重大インシデントの定義と通知、不利な評価結果の取り扱いです。
評価者・監査の利益相反を確認する一行
評価者・監査の利益相反を確認する質問を調達チェックに1行足します。誰が払い、何を公開でき、基準は誰が更新するか。ここが空欄のまま「第三者評価済み」と書くと、後から説明が難しくなります。
Amodei氏の提案が示す緊張——能力の伸びと安全検証の時間——は無視できません。Gomez氏の提案が示す緊張——基準の作成権と市場構造——も、調達とアーキテクチャの話として無視できません。両方を読んだうえで、自社の用途に必要なのは「名刺にある評価」か「自社の脅威モデルに刺さる評価」かを切り分けるのが、技術者の仕事です。
レビューのアジェンダに足す4行から始める
Gomez氏の締めは、規則はどちらにせよ書かれる、開かれた証拠ベースのプロセスか、閉じた少数企業の部屋か、だという整理です。Amodei氏の側は、検証可能なペース調整なしでは、安全が商業競争に負ける、という整理です。
現場に持ち帰れるのは、どちらのCEOに賛成するかの投票ではありません。レビューのアジェンダに、「基準の出典」「スコープ」「利益相反」「乗り換え可能性」の4行を足せるかどうかです。それだけで、安全の議論が調達のチェックリストに落ち、チーム内で同じ言葉で話せるようになります。
作成日: 2026-09-24