「代わりにやる」AIの時代——SaaSの終焉とAnthropicの覇権戦略

AI は「人間に使い方を教える道具」から「人間の代わりに手を動かす実行主体」へと役割を変えつつある。2026年1月に Anthropic が公開した Claude Cowork は、その転換を象徴する製品として受け止められ、SaaS 株の大幅な下落——いわゆる SaaSpocalypse ——を引き起こしたと報じられた。本稿では、まず検証可能な事実と筆者の見立て（予測・論評）を明確に分けて整理する。そのうえで、規制産業にとって最も重要な論点——AI が実行した操作の責任は誰が負い、その記録を誰の行為として残すのか——を、21 CFR Part 11 の条文に即して掘り下げる。

1. まず事実を確認する——数字はどこから来ているか

エンタープライズ LLM API 市場でのシェア逆転

「Anthropic が OpenAI を逆転した」という話には、確認できる出所がある。ベンチャーキャピタルの Menlo Ventures が2025年12月9日に公開した年次調査レポート 2025: The State of Generative AI in the Enterprise である。同レポートは、企業向け LLM API 利用における事業者別シェアを次のように推計している。

「Claude Code の台頭」——事実の部分と、見立ての部分

事実として言えるのは、上記調査においてコーディング用途のシェアが Anthropic に大きく偏っている、という推計値までである。その原因を Claude Code に帰する説明は、筆者の見立てである。従来型の AI ツールが「人間に使い方を教える」ものであったのに対し、Claude Code は「人間の代わりに仕事をこなす」設計思想を採る——この対比は、製品の設計思想を筆者の言葉で要約したものであり、Anthropic の公式発表がそう述べているわけではない。

2. 「SaaSpocalypse」——何が起き、何が確認できないのか

時系列で確認できる事実

Claude Cowork は、開発者以外の一般業務従事者が、ファイル・フォルダ・各種アプリケーションを対象に、複数ステップの業務をエージェントに委ねられるようにする製品である。公式の製品ページは Claude Cowork にある。中核となるのが Skills（エージェント・スキル）で、これは自然言語で書かれた手順書・参照資料・スクリプトをフォルダにまとめたものである。Anthropic はこれを Introducing Agent Skills として公開し、技術解説記事でその設計原理（必要になった時点でのみ情報を読み込む「プログレッシブ・ディスクロージャー」）を説明している。

下落額の数字は、報道によって食い違っている

投資家が何を恐れたのかについては、当社の別稿「SaaS株暴落の真相」でも取り上げている。あわせてお読みいただきたい。

3. 【見立て】SaaS が「死ぬ」という議論の中身

SaaS の価値を3要素に分解する

SaaS が提供している価値は、おおむね「データ」「ロジック（業務フロー）」「UI」の3つに分解できる。この3要素それぞれについて、AI エージェントが代替し得るかを考えると、次のように整理できる。

1. データ多くの SaaS は、利用者が入力したデータを預かっているに過ぎない。データそのものを SaaS 事業者が生成しているわけではない場合、これは本質的な参入障壁とはなりにくい。
2. ロジック（業務フロー）「この手順でレビューする」「この順序で承認を回す」といった業務フローの型は、まさに自然言語の手順書として記述できる領域である。AI エージェントが最も得意とする部分であり、代替圧力が最も強く働く。
3. UI人間が画面を操作することを前提とした UI は、AI が操作を代行するのであれば、その価値の相当部分を失う。UI の使いやすさで差別化してきたサービスほど影響を受けやすい。

スイッチングコストの低下

加えて、乗り換えコストの低下が効いてくる。従来、SaaS の乗り換えを阻んでいたのは「データ移行の手間」「新ツールの操作習得」「業務フローの再構築」であった。この3つはいずれも AI エージェントが引き受け得る作業である。障壁が下がれば、価格交渉力は買い手側に移る。

4. 【本題】「代わりにやる」AI は、規制対応の何を変えるのか

ここからが、規制産業の実務者にとっての本題である。AI エージェントが人間の操作を代行するようになると、GxP・Part 11 の枠組みは何を要求することになるのか。結論を先に述べる。規制の要求は変わらない。変わるのは、その要求を満たすための実装である。

4-1. 誰が責任を負うのか——AI は責任主体になれない

最初に確認すべき原則は単純である。AI が実行した操作の責任主体は、依然として事業者および作業者である。AI エージェントは規制上の「者」ではなく、事業者が使用するツールに過ぎない。この点は、各極の規制当局が繰り返し明示している。

• EMA の Reflection paper on the use of Artificial Intelligence (AI) in the medicinal product lifecycle は、AI モデルが規制上の文脈に適合していることを保証する責任は申請者および製造販売承認取得者にあると述べている。
• FDA の Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products（2025年1月公表のドラフトガイダンス）は、コンテキスト・オブ・ユース（COU）に応じたリスクベースの信頼性評価の枠組みを提示している。責任の所在は、モデル提供者ではなく、そのモデルを使って規制判断の根拠を作る側にある。
• EU では AI Act（Regulation (EU) 2024/1689）が、AI システムの提供者（provider）と利用者（deployer）のそれぞれに義務を課している。AI を業務に組み込む事業者は、単なる「利用者」ではなく義務の名宛人である。適用時期は段階的で、ハイリスク AI に関する規定の適用時期については見直しの議論が続いている点に留意されたい（欧州委員会の解説ページ）。

4-2. 記録の帰属性——ALCOA+ の Attributable をどう満たすか

データインテグリティの原則 ALCOA（Attributable／Legible／Contemporaneous／Original／Accurate）は、FDA の Data Integrity and Compliance With Drug CGMP: Questions and Answers においても明示されている。このうち Attributable（帰属性）——その行為を「誰が」行ったのかが特定できること——が、AI エージェントの導入によって最初に揺らぐ。

AI エージェントが GxP 対象システムにログインし、データを入力・変更したとする。監査証跡には、誰の行為として記録されるべきか。選択肢は3つある。

実務上は (B) を採ったうえで、「どの人間が、いつ、どの指示を出し、誰が結果を承認したか」を紐付けて記録する——すなわち (A) と (B) の併記——が現実的な解となる。21 CFR §11.10(e) は、監査証跡について次のように定める。

条文が記録の対象としているのは “operator entries and actions”、すなわち「操作者の入力および行為」である。エージェントが操作者となる以上、その行為も監査証跡の対象であり、かつそれが自動実行であったことが判別できなければならない。人間の手入力と AI の自動実行が、監査証跡上で区別できない状態は避けるべきである。

監査証跡に追加すべきメタデータ

4-3. 電子署名——AI エージェントに署名させることは想定されていない

ここが最も誤解されやすい論点である。結論から言えば、21 CFR Part 11 の電子署名は、AI エージェントが行うことを想定していない。条文がそう書いているからである。

まず定義を見る。§11.3(b)(7) は電子署名を次のように定義する。

署名を実行・採用・承認する主体は individual（個人）であり、その効果は当該個人の自筆署名と法的に等価であるとされている。ソフトウェアエージェントはここでいう individual ではない。

続いて、電子署名の一般要件を定める §11.100 を見る。

(a) は一意性——ひとつの電子署名はひとりの個人に固有であり、他者への再利用・再割当てを禁じる。(b) は本人確認——組織は電子署名を設定・付与する前に、その個人の身元を確認しなければならない。「身元を確認できる個人」が存在しないエージェントに、この要件を満たす形で電子署名を付与することはできない。

さらに §11.200 は、バイオメトリクスに基づかない電子署名について、少なくとも2つの識別要素（ID コードとパスワード等）を用いること、真の所有者のみが使用できるよう管理・運用されること、そして本人以外による使用の企図には2名以上の共同（collaboration）を要することを求めている。この「2名以上」の趣旨については、当社の別稿「なぜ2人以上の共謀が必要とされたのか」で詳述している。

加えて §11.70 は、署名と記録の結合を求める。

4-4. 監査証跡——自動実行された変更をどう追跡可能にするか

AI エージェントの厄介な点は、1回の指示が数十から数百の個別操作に展開されることである。「この試験成績書を確認して、規格外があれば逸脱を起票して」という一言が、複数システムにまたがる読み取り・転記・起票の連鎖に変わる。従来の監査証跡は「人間が1操作すれば1レコード」という粒度を前提に設計されており、この前提が崩れる。

粒度をどう設計するか

実務上は、2層で記録するのが合理的である。

1. セッション層（指示単位）誰が、いつ、どのような指示を出したか。どのモデル・どの Skill を用いたか。最終的に何を出力し、誰が承認したか。査察官に「この変更はなぜ行われたのか」を説明するための層である。
2. トランザクション層（操作単位）個々のレコードに対する作成・変更・削除を、従来どおり §11.10(e) の要件に従って記録する。ここにセッション層の識別子を必ず埋め込み、両者を突合可能にする。

また、エージェントの動作を規定する Skill／手順書そのものが変更管理の対象になる点も見落とせない。§11.10(k)(2) は、システム文書の開発・変更の履歴を時系列で追跡できるよう、改訂管理と変更管理の手順を求めている。「AI に渡した手順書」は、システム文書として版数管理されなければならない。

4-5. バリデーション／CSA——自律的に振る舞うシステムをどう検証するか

21 CFR §11.10(a) は、次のように定める。

問題は consistent intended performance（一貫した意図された性能）である。出力が確率的に変動するシステムに対して、「一貫した性能」をどう定義し、どう立証するのか。

鍵は「意図した使用（intended use）」の切り分けにある

FDA は2025年9月24日、Computer Software Assurance for Production and Quality Management System Software を最終ガイダンスとして発出した。同ガイダンスは、ソフトウェアの機能ごとにプロセスリスクを判定し、リスクに応じて検証の厳格さを配分するという考え方を採る。リスク判定の起点は、そのソフトウェアの意図した使用（intended use）である。

したがって AI エージェントの CSA においては、「AI が何をするシステムか」を漠然と定義するのではなく、機能を分解して、それぞれの意図した使用と、その出力が最終的に誰の判断を経るかを定義することが出発点となる。

4-6. アクセス制御——エージェントに与える権限を最小化する

21 CFR §11.10(d) の要求は、一文である。

加えて §11.10(g) は権限チェック（authority checks）を求め、認可された個人のみがシステムを使用し、記録に電子署名し、入出力装置にアクセスし、記録を変更し、当該操作を実行できるようにすることを要求している。

AI エージェントの怖さは、権限を与えれば与えただけ、疲れも迷いもなく使い切ることにある。人間であれば「これは自分の担当外だから確認しよう」と立ち止まる場面で、エージェントは立ち止まらない。ここでの原則は最小権限（least privilege）に尽きる。

5. Human in the Loop から Human on the Loop へ

従来のバリデーション実務は、Human in the Loop——人間が処理の流れの内側にいて、各工程で判断する——を前提としてきた。エージェントの導入は、これを Human on the Loop——人間は流れの外側から監視し、要所で介入する——へと押し出す。この移行を、規制対応として設計する手順を整理する。

1. 適用範囲を書き出すどの業務の、どの工程を AI に委ねるのかを文書化する。GxP 記録に触れる工程かどうかを最初に判別する。
2. 意図した使用を定義する「AI にやらせること」ではなく「AI にやらせないこと」から定義する。判定・承認・電子署名は原則として対象外とする。
3. 承認ゲートを配置する不可逆な操作、規制記録の確定、外部への提出——この3種類の直前には、必ず人間の確認と承認を置く。
4. 記録項目を決める4-2 の表に示したメタデータを、既存の監査証跡にどう追加するかを設計する。既存システムが対応できない場合、エージェント側で独立した実行ログを保持し、両者を突合できるようにする。
5. アクセス権限を設計する4-6 の表に従い、専用アカウント・最小権限・ホワイトリストで構成する。設定内容と根拠を記録する。
6. 教育訓練を実施する使う側の力量が問われる。「AI が誤ることがある」ことを知識として持ち、誤りを検出できる技能を持つことが、この業務における力量の中身である。教育訓練記録の対象とする。
7. 供給者評価と定期照査を行うAI ベンダーを供給者として評価し、モデル更新の通知、データの取扱い方針、可用性、サポート体制を確認する。導入後も定期的に見直す。

6. 広告を拒絶するという選択——事実関係の確認

両社の公式発表

この論点については、双方の公式発表が公開されている。

• Anthropic：2026年2月4日、Claude is a space to think を公表。Claude は広告を掲載しない方針を明示し、利用者は会話の隣に「スポンサー」リンクを見ることはなく、Claude の応答が広告主の影響を受けたり、利用者が求めていない第三者の製品紹介を含んだりすることはない、と述べている。収益はサブスクリプションと法人契約によるとしている。
• OpenAI：Our approach to advertising and expanding access および Testing ads in ChatGPT において、米国の Free ティアおよび Go プランを対象に広告のテストを開始したと公表。広告は回答の下部に「スポンサー」と明示して表示され、広告主は会話・履歴・メモリ・個人情報にアクセスできない、広告が回答内容に影響することはない、Plus／Pro／Business／Enterprise には広告を表示しない、としている。

スーパーボウル CM の効果について

規制産業の実務者にとっての含意

広告の有無は、単なるビジネスモデルの違いにとどまらない。AI ベンダーの選定は、GxP における供給者評価の対象である。評価にあたって確認すべき事項は、少なくとも次のとおりである。

• 入力データの取扱い：入力した内容がモデルの学習に使われるか。使われない契約形態が選べるか。
• 第三者への提供：会話内容が広告配信を含む第三者に提供されることがあるか。
• データの所在と保持期間：どの法域のどのデータセンターに、どれだけの期間保持されるか。
• 出力への介入：広告主・スポンサーによって出力が影響を受けることがあるか。GxP 判断の根拠となる情報を生成させる以上、これは極めて重要である。
• モデル更新の通知：バージョン更新が事前に通知されるか。バージョンを固定できるか。

これらは製品の広告方針の有無だけで判断できるものではなく、契約条件・利用規約・エンタープライズ向けプランの仕様書に基づいて確認し、記録に残すべき事項である。AI ベンダーのリスク評価については、当社の別稿「#QuitGPT — ChatGPTに「解約」を突きつける市民ボイコットの深層」でも扱っている。

7. 【見立て】競争ポジションの整理

現在の主要3社は、それぞれ異なる主戦場に立っていると見るのが妥当である。OpenAI は消費者向けの利用者規模を、Anthropic は法人業務での実行精度を、Google は自社プロダクト群との統合を、それぞれ競争軸に据えている。「覇権」という語で単一の勝者を語るのは、市場の実像を単純化しすぎている。

規制産業の立場からより重要なのは、順位ではない。どのベンダーを選ぼうとも、責任・記録・署名・監査証跡・バリデーション・アクセス制御の要求は変わらないという事実のほうである。ベンダーの盛衰に振り回されない実装——すなわち、特定ベンダーに依存しない形で承認ゲートと記録の設計を確立しておくこと——が、結局のところ最も堅牢な戦略となる。

8. PMDA・当局側の動きも押さえておく

AI の業務利用は、規制される側だけの話ではない。PMDA は2025年9月に業務における AI 活用のアクションプランを公表し、2026年4月には全職員を対象とした生成 AI の利用を開始したと発表している。また、AI を活用したプログラム医療機器については 専門部会が設置され、国際的な規制動向、機械学習に伴うバイアス、市販後の学習データの取扱い等が検討されている。

当局が AI を使いこなすようになれば、査察・審査における記録の読み込み方も変わり得る。監査証跡の網羅的な解析が現実的になれば、「膨大すぎて誰も見ない」という前提に依存した運用は成り立たなくなる。この点は、AI 導入の是非とは独立に、備えておくべき変化である。