投稿者: MyEix

  • AIエージェントに必要な「外側のブレーキ」とは

    AIエージェントに必要な「外側のブレーキ」とは

    AIエージェントの安全性は、モデルだけでは決まりません。

    AIがどのシステムに接続でき、どこまで操作できるのか?さらに、その行動を監視し、異常時に止められるのか。こうしたモデルの外側にある仕組みまで含めて考える必要があります。

    従来の生成AIでは、差別的な表現や犯罪につながる情報など「危険な回答を出させないこと」が安全対策の中心だったのですが、AIエージェントは、文章を返すだけではなく、調査からツールの利用、コードの実行、外部システムへの接続まで複数の作業を連続して進めることができます。

    そのため、安全性を見る基準も変わり、AIが「何を答えるか」だけでなく、「何を実行できるか」まで見る必要があります。

    隔離環境の外までAIが動いた

    OpenAIとAnthropicをめぐる問題では、セキュリティーテスト中のAIエージェントが用意された隔離環境を抜け、他社システムへ侵入。

    具体的なテスト条件や侵入範囲は明らかにされていませんが、AIの行動が想定された環境の外まで及び得ることが、議会の関心事項になった形。

    米下院議員らが両社に説明を求めた対象も、モデルそのものに限られておらず、安全管理や監視体制も含まれており、AI企業による内部管理だけで安全性を判断するのではなく、独立したセキュリティー監査を求める議論が出ているのも、この問題とつながっています。

    同じ週には台湾政府も、7月に政府機関を狙った攻撃で、人間による操作とAIエージェントが組み合わされていたと発表しており、さらに、複数のAIエージェントが連携し、認証情報の窃取やシステムの脆弱性探索を行ったとされる事例も報告されています。

    攻撃主体や個々の事例の関係は、ここでは特定できませんが、AIエージェントのリスクがテスト環境だけの話ではなく、実際の攻撃でも報告されている点は分けて考える必要があります。

    危険な「回答」と危険な「行動」は違う

    従来型の生成AIでは、危険な質問への回答を拒否させるなど、出力する情報の制御が安全対策の中心であり、今後も必要な対策ではあるのですが、外部ツールを操作できるAIエージェントでは、それだけでは足りません。

    たとえば、AIにメールの作成だけを任せる場合と、送信まで許可する場合ではリスクが大きく異なります。

    文章を間違えただけなら、人間が送信前に修正できますが、送信権限まで持たせてしまえば、AIの判断がそのまま外部への行動につながってしまいます。

    社内システムへの接続でも同じで、限られたデータだけを閲覧できるAIと、全社のデータや外部サービスまで操作できるAIでは、誤作動した場合の影響範囲がまったく違います。

    重要なのは、AIの能力が高いこと自体を危険視することではなく、高い能力と広い実行権限が組み合わさるほど、判断を誤ったときの影響が大きくなるということ。

    モデルの外側に四つの制御を置く

    行動できる範囲がリスクを左右するなら、安全対策もモデル内部の調整だけでは完結せず、必要になるのが、モデルの外側に置く「ブレーキ」。

    一つ目は権限の制限で、AIが接続できるシステムや実行できる操作を限定しておけば、誤った判断をしても影響が無制限に広がることを防ぎやすくなります。

    二つ目は実行環境で、AIが自由に外部へアクセスできる状態ではなく、行動できる範囲そのものを区切ります。

    権限と実行環境は「AIがどこまで動けるか」を決める仕組みと言えます。

    そして、そこに監視と停止機構を加え、AIが実際に何をしたのか記録し、想定外の行動があれば人間が介入するようにし、必要なら処理そのものを止められる状態にしておきます。

    モデル内部の安全対策との違いはここにあり、危険な操作をしないようAIを調整する方法は、最終的にはモデルの判断に依存します。

    一方、権限や実行環境をシステム側で制限すれば、モデルが誤った判断をしても、その外側で行動を制限できます。

    どちらか一方を選ぶというものでもなく、モデル内部の安全対策に加え、権限、実行環境、監視、停止機構を重ねるという設計が必須となってきます。

    AI選びでは「何をさせないか」も見る

    企業がAIエージェントを導入するときも、性能や回答精度だけでは比較できなくなってきます。

    どのシステムへ接続できるのか、どの操作まで自動実行できるのか、重要な操作に人間の承認を挟めるのか。

    さらに、行動履歴を確認できるか、問題が起きたときに強制停止できるかも確認項目になります。

    これは初期の頃の「最も賢いAIを選べばいい」という考え方とは違い、能力が高くても、必要以上の権限を与えればリスクは増えてしまうだけ。

    一方で、権限を限定し、人間による承認や監視を挟めば、誤った判断が外部へ及ぶ範囲を狭められます。

    AIへ仕事を任せることは、同時に何らかの権限を渡すことでもあり、だからこそAIエージェントを選ぶときは「何ができるか」だけではなく、「何をさせない設計になっているか」まで確認する必要があります。

  • Claude生成コンテンツに「AIの痕跡」Anthropicが透かしを世界展開する理由

    Claude生成コンテンツに「AIの痕跡」Anthropicが透かしを世界展開する理由

    Anthropicが、Claudeの生成物に機械で読める印を付けるようです。

    テキストには見えない電子透かし、画像などにはC2PAの来歴情報を付与するようで、対象はEUだけではなく、対応モデルが使える地域へ広く適用されるようです。

    重要なのは、AI文章を完全に見破れる点ではなく「AIが関与した証拠を残す」という設計が、Claude側に組み込まれるということ。

    Claudeを通した文章にも透かしが残る

    対象は、Claudeがゼロから書いた文章だけではないようで、人間が書いた文章を校正し、翻訳や要約だけをClaudeに任せるというような使い方でも、出力結果には透かしが残る場合があるそうです。

    透かしは文章中の単語選択などに埋め込まれるようで人間が読んでも基本的には分からないようですが、機械は特徴を検出することができるようで、コピーや軽い編集をしても、条件によっては残るのだとか。

    ここは従来のAI検出ツールと分けて考える必要があって、AI検出ツールは文章からAI利用を「推定」するのですが、Claudeの透かしは、生成時に痕跡を「埋め込む」仕組みとなり、対象もWeb版Claudeだけではなく、Claude PlatformのAPIやClaude Codeなどにも含まれます。

    AWSやGoogle Cloudなどを経由する対応モデルも対象。

    つまり企業がAPI経由でClaudeを使う場合も無関係ではなくなります。

    画像はC2PAで「どこから来たか」を残す

    画像などでは別の方法が使われるようで、.svg、.png、.jpgなどのファイルには、C2PA形式の署名付きメタデータが付与されます。

    C2PAはコンテンツの来歴を記録する規格であり、対応ツールを使えば、生成や編集に使われたシステムなどを確認することができ、テキスト透かしとの違いは保存方法で、C2PAの情報は、ファイル操作によって消える場合があり、

    • 形式を変換する
    • 画像を再保存する
    • スクリーンショットを撮る

    こうした操作では、元のメタデータを引き継げない場合があります。

    そのためC2PAが見つからなくても、人間が作った画像とは断定できませんし、これはテキスト透かしにも共通する注意点で「検出できた」はAI関与の材料になりますが「検出できない」からといって、人間だけで作った証明にはなりません。

    これ、意味あるんですかね?

    EUのルールがClaudeの世界標準になる

    今回の変更にはEU AI法があります。

    AI生成・加工コンテンツに関する透明性義務は、2026年8月2日から適用が始まり、生成AIの提供者には、AIが関与したコンテンツを機械で識別できる仕組みなどが求められ、Anthropicも、この要件に対応する方針となっています。

    ただし実装をEU内だけに限定しないようで、対応モデルが提供される地域では、同じ仕組みを広く適用するため、企業側には分かりやすい設計となっています。

    EU向けと日本向けでClaudeの出力仕様を分けるより、同じモデルを同じルールで扱えたほうがいいですからね。

    一方で、AI利用を社内だけの問題として扱うのは難しくなり、たとえば企業がClaudeで文章を校正した場合、人間が原稿を書いていても、最終出力にはAI処理の痕跡が残る可能性があります。

    「AIが書いたか」だけでは判断できず「AIをどの工程で使ったか」まで決めておく必要が出てくるでしょうね。

    透かしは「AI判定機」ではない

    ここを誤解すると、使い方を間違えてしまいまs。Claudeの透かしは、万能なAI判定機ではありませんし、透かしがあっても、文章全体をClaudeが書いたとは限りません。

    そして、これは逆も同じ。

    • 文章を大幅に書き換える
    • 別の文章と混ぜる
    • 翻訳を重ねる

    こうした処理で透かしが弱まる可能性はありますし、短い文章では、判定材料そのものが足りない場合も出てくるでしょう。

    C2PAも同様で、メタデータが残っていれば来歴を確認できるとはいえ、消えていれば、それ以上のことは証明できません。

    だから企業が見るべきなのは、透かしの有無だけではなく、

    • 社内でAIを使える工程を決める
    • 人間による確認範囲を決める
    • 外部公開時の表示ルールを決める

    この3つと組み合わせて初めて、実務で使える仕組みになります。

    Claudeの変更で明確になったのは、AI利用を完全に隠すか、完全に見破るかという話ではなく、生成物そのものに「AIが関与した履歴」を持たせる方向へ、サービス側の設計が変わったことです。

    Claudeを業務利用している企業は、まず自社の文章が「生成」「校正」「翻訳」のどこでClaudeを通っているかを確認すべきです。

    とはいえ、こんなことで技術の進歩を遅らせることになりませんかね?

    こんな中途半端なことするなら、あまり意味ないと思うんですけどね。

    まぁ、これというのもEUがおバカなこと言い出すから、仕方のないことなのかもしれませんが・・・。

    ただのいちゃもんですからね、EUは・・・。

  • AI競争はモデル性能から半導体・電力・水の確保へ移り始めた

    AI競争はモデル性能から半導体・電力・水の確保へ移り始めた

    Anthropicが、Claude向け半導体の自社設計に乗り出し、アメリカではデータセンター部品の輸入規制が検討されています。

    インドではGoogleの大型計画が水資源をめぐる反発に直面し、AI競争の重心は、モデルの性能だけでなく、計算資源を安定して確保できるかへ移り始めてきています。

    Anthropicが半導体設計へ、モデル企業の仕事が下流へ広がる

    AI企業の競争を考えるとき、これまではモデルの性能差が主な比較対象となっており、回答の正確さ、推論能力、コーディング性能、処理速度といった指標が中心だったのですが、いくら高性能なモデルを開発できたとしても、それを多数の利用者へ安定して提供できなければ事業にはなりません。

    Anthropicは、2026年8月5日、Claude向けのカスタム半導体を設計する社内チームを立ち上げるよで、ハードウェアとソフトウェアの双方に詳しい技術者を採用し、モデルと半導体を共同で最適化する方針のようです。

    その一方で、Amazon Web Services、Google、Nvidia、AMDの技術を使う複数調達の戦略も継続して使用していくようです。

    この発表が示しているのは、Anthropicが直ちに既存の半導体メーカーから自立するということではなく、設計と製造は別の工程であり、独自設計に着手しても、実際の生産を外部へ委託する可能性はまだまだ残されています。

    手探りの状況といってもいいでしょうね。

    それでも、モデル企業が半導体の設計段階へ踏み込む意味は小さくありませんし、外部から調達した汎用的な計算基盤へモデルを合わせるだけでなく、モデルの動かし方に合わせて半導体を設計することができれば、処理速度や消費電力、運用コストを改善できる可能性が出てきますよね。

    今後のAIの性能競争が、ソフトウェア単体からハードウェアを含む「一体設計」へ広がっていると解釈できるでしょうね。

    AIを動かす供給網は、半導体だけでは完結しない

    AIモデルを実際に稼働させるには、演算を担う半導体だけでなく、サーバー、メモリー、ストレージ、通信部品、電力、冷却設備、土地、水が必要で、どこか一つが不足すれば、ほかの設備を用意しても計算能力を増やすことはできません。

    この構造では、AI企業の競争力はモデルの品質だけで決まることはなく、必要な部品を予定どおり調達できるか?データセンターへ十分な電力を供給できるか?冷却に必要な資源を確保できるか?建設について地域の理解を得られるかが事業の速度を左右してきます。

    Anthropicの独自半導体計画も、この供給網全体を自社で所有する動きとは言い切れず、同社が従来の調達先を併用する方針を示していることから、狙いは完全な内製化よりも、特定の企業や製品への依存を減らし、用途に応じて選べる計算基盤を増やすことにあると考えられます。

    つまり、「自前インフラ」とは、必ずしも工場やデータセンターをすべて自社保有することではありませんし、設計、調達先、長期契約、運用方法を組み合わせ、必要な計算資源を自社の判断で確保しやすくすることであり、AI企業にとっては、モデル開発とは異なる資本力、調達力、行政との調整力が必要となります。

    米国の輸入規制案が示す、データセンターの安全保障化

    AIインフラの確保を難しくするのは、需要の増加だけではなく、国家間の規制も供給条件を変え始めてきています。

    アメリカ政府は、中国製の新しいデータセンター部品を対象とした輸入禁止措置を検討しており、対象として報じられた光トランシーバーは、電気信号を光信号へ変換し、データセンター内で大量のデータを高速に移動させる部品。

    米連邦通信委員会が規制案を作成している段階であり、内容が変更されたり、計画自体が見送られたりする可能性も十分残されている状況となっています。

    この背景には、中国企業によるデータ取得やマルウェアの組み込み、サービス妨害を防ぐというアメリカ側の安全保障上の懸念があるとはいえ、安全性を優先して調達先を絞れば、別の問題が生じてきます。

    そもそも中国の中際旭創は世界のデータセンター向けトランシーバー市場で27%のシェアを持つとされ、米国企業にも代替候補はあるとはいえ、中国企業を短期間で置き換えられる規模には達していないとの見方が強く、規制が実施されれば、アメリカのクラウド事業者が別の供給元へ移ることで、部品価格や整備日程に影響する可能性があります。

    ここで起きているのは、AIインフラの評価軸が「安く、早く調達できるか」だけでは済まなくなったことであり、供給元の国、部品の安全性、制裁や輸出入規制の影響まで含めて選定するようにしなければなりません。

    経済安全保障が、AIサービスのコストと供給能力に直接入り込む構造となってきているわけです。

    150億ドル計画が直面した、地域の水不足という制約

    たとえ部品を確保できても、データセンターを建てられるとは限らず、Googleがインド南部アンドラプラデシュ州で進める150億ドル規模のデータセンター計画は、水資源と野生生物への影響をめぐって反対運動や法的な異議申し立てに直面しています。

    計画地のあるビシャカパトナムでは、1日に必要な水量が4億8000万リットルであるのに対し、河川や貯水池からの供給は4億1000万リットルと州政府が説明しており、計算上は毎日7000万リットル不足します。

    Googleは、地域の重要な水資源を守るため、高度な空冷方式を採用すると説明しており、州政府も、住宅用や農村部の飲料水をデータセンターへ転用しないとしているのですが、数値上の不安はなかなか払拭できないでしょうね。

    企業のAI導入にも価格・供給・契約条件が波及する

    こうした変化は、大手AI企業や半導体メーカーだけの問題ではなく、一般企業が利用する生成AIやクラウドサービスの価格、提供地域、処理上限にも波及する可能性があります。

    計算資源を安定して確保できるAI企業は、利用者が急増してもサービスを拡張しやすくなりますが、逆に、半導体や通信部品の不足、輸入規制、建設計画の遅れが重なれば、サービス料金の引き上げや利用制限、提供開始の延期につながる可能性があります。

    企業のシステム担当者にとっては、モデルのベンチマークだけでAIサービスを選ぶことが難しくなり、処理能力を継続的に確保できるか、複数の半導体やクラウドへ対応しているか、地政学的な規制を受けた場合に代替手段があるかも確認対象になります。

    購買部門や経営層にも同じ問題が及び、短期的に安いサービスでも、供給基盤が一社や一地域へ集中していれば、規制や設備不足が発生したときの移行費用が大きくなりますし、AIの調達は、ソフトウェア契約であると同時に、背後にある物理インフラへの依存を選ぶ判断にもなりつつあります。