水曜日, 11月 04, 2026

Claude Coworkは他製品・OSS・オンプレで再現できるのか:閉域環境での現実解

Claude Coworkのように、ローカルのファイルやSaaSを横断して複数ステップの仕事を任せられるエージェントを、他社サービスやオープンソース、オンプレミスで再現できるのか。データを外に出せない組織にとっては、導入の可否を左右する問いです。

結論を先に書くと、機能の「部品」は多くがOSSで揃います。ただし「何割再現できるか」「体験品質がどれだけ違うか」は、対象業務と検証構成を決めた比較をしないかぎり数字では言えません。そのうえで最も近い現実解は、Anthropic公式の「Claude Desktop on 3P」です。オフラインインストーラーを使えば、Anthropic運営ホストへの実行時通信をなくせます。一方で、推論はClaudeモデルが前提で、Claudeの推論を完全オンプレミスに置けることは公式資料から確認できません。

本記事は2026年11月4日時点の公開情報(Anthropicの公式ドキュメント、各社の発表、GitHub上のライセンス条文)に基づきます。製品の動作検証や性能測定は行っていません。見通しや評価に関する記述は筆者の推定です。Manus、Perplexity、Genspark、NECなど、一次情報まで確認できなかった製品は比較対象から外しています。

1. 先に結論

  • Anthropicへの実行時通信は排除できます。3P版にはVMワークスペースとClaude CLIを同梱したオフラインインストーラーがあり、Anthropicへの接続なしでセッションを開始できます。自動更新とモデルカタログ取得を止めれば、必要な外向き通信は推論プロバイダだけになる、と公式の導入手順は説明しています。
  • ただし「完全オンプレミスのClaude」は確認できません。自社ゲートウェイの公式説明はClaudeモデルの利用を前提としています。完全エアギャップが要件なら、3Pは「推論先に到達できる閉域」までが射程です。
  • OSSでも主要機能は組めます。gooseのようにMCP拡張とサブエージェントを備えたものがあります。しかし権限UX、サンドボックス、監査、Office成果物の品質は自前で詰める部分が大きく、Coworkとの差は実測しないと分かりません。
  • 国内ベンダーの閉域基盤は、推論とガバナンスの層として有力です。ただしCowork型の汎用デスクトップ体験そのものを提供するものとは、公式資料から読めません。

2. Coworkを5層に分けて考える

再現を検討するときは、「Coworkという製品」を丸ごと探すより、構成要素に分けたほうが見通しが立ちます。Coworkは、Anthropicが2026年4月9日に全有料プランで一般提供(macOS・Windows)を始めた機能です。

層 内容 再現するときの論点
モデル Claude系モデル 長時間・多ツールのタスクを破綻なく進める能力。オープンウェイトで同等かは、業務ごとに測るしかない
エージェント・ハーネス タスク分解、サブエージェント、承認フロー、Auto modeの安全審査 OSSにも部品はあるが、承認と自動審査を一体で提供しているものは今回確認できなかった
実行環境 ローカルの隔離VM(標準版にはクラウド実行もある) ローカル実行型OSSは隔離を別途用意する必要がある
接続層 MCPコネクタ、スキル、プラグイン、フック MCP自体は標準規格で再現しやすい。配布と権限の統制が論点
管理層 RBAC、グループ別の利用上限、OpenTelemetry、コネクタのツール単位制御 ここが製品として揃っていないと、組織展開で最初に詰まる

出典:Anthropic「Making Claude Cowork ready for enterprise」(2026年4月9日)。管理層の項目は同記事の記述による

3. 最も近い選択肢:Claude Desktop on 3P

3-1. 3Pとは何か

3Pは、Claude Desktopの推論をBedrock、Google Cloud、Microsoft Foundry、Anthropic Messages API互換の自社ゲートウェイなどに振り向けるデプロイモードです。課金はトークン従量で、席ごとのライセンスはありません。会話履歴は端末に保存されます。一方で、モバイル/Web、Anthropicクラウド上のセッション、ユーザー間の共有、音声モード、Claude Tag、Claude Securityは使えません。

機能 標準版Cowork 3P版
実行場所 Anthropicのクラウド、またはローカル セッションはローカル(SSH経由のCodeを除く)
スケジュールタスク クラウドで実行され、PCが停止していても動く 対応。ただしローカル実行で、端末が起動・稼働している必要がある
ブラウザ操作 内蔵ブラウザとClaude in Chrome 内蔵ブラウザは対応。Claude in ChromeはEnterprise Admin Consoleで管理する組織のみ
メモリ/プロジェクト チャットとメモリを共有 両方に対応。メモリは端末保存で、チャット履歴検索と夜間要約は使えない
自動承認(Auto mode) 利用可能 管理者がautoModeEnabledをtrueにした場合に提供
管理 管理コンソール Admin Console、MDM、ブートストラップサーバー、OTelエクスポート、MCP許可リスト

出典:Anthropic公式「Features」(3P機能表)、標準版の記述はAnthropicのヘルプセンター。AWS公式ブログによれば、Computer Use、Skills Marketplace、Claude Designは3Pの対象外

機能表は、Webサーチについても条件を付けています。Bedrock経由、またはAnthropicのサーバーツールを転送しないゲートウェイでは、先にWebサーチプロバイダの設定が必要です。また、3PはクラッシュレポートとプロダクトアナリティクスをAnthropicへ既定で送ります。プロンプトや応答の内容は含まれず、管理設定で完全に無効化できると説明されています。

3-2. 閉域性は3段階に分けて評価する

「3Pは完全エアギャップ不可」と一括りにすると、実態を外します。要件を3つに分けると評価が変わります。

要件 評価 根拠・留保
Anthropic運営ホストへの通信を禁止したい 対応可能 標準インストールはVMワークスペース(1GB超)とClaude CLIをdownloads.claude.aiから取得する。オフラインインストーラーは両方を同梱し、チェックサム検証もアプリ内蔵。自動更新(disableAutoUpdates)とモデルカタログ取得(modelCatalogEnabledをfalse、またはミラー)を止めれば、必要な外向き通信は推論プロバイダだけになると説明されている
許可した推論基盤だけに接続したい 設計確認が必要 オフラインでも推論エンドポイントへの到達性は必要。MCP、検索、監視、認証の通信先も含めて確認する
外部の推論サービスにも接続しない完全オンプレミス 公式対応を確認できない ゲートウェイの公式説明はClaudeモデルの利用を前提としている

出典:Anthropic公式「Installation and setup」(Offline installation)

構成の選び方でも差が出ます。Enterprise Admin Console経由の配布では、ユーザーはClaudeアカウントでサインインし、Anthropicがユーザー一覧と設定を保持します(プロンプトは推論プロバイダにのみ送られ、会話は端末に残るとされています)。どの端末もAnthropicへのサインインに依存させたくないなら、MDMプロファイルの配布が公式に示された選択肢です。

3-3. 「国内リージョン」は十分条件ではない

「国内リージョンのBedrockかGoogle Cloudを選べばよい」という整理には、追加の確認条件が要ります。

  • 使うモデル、バージョン、推論方式で、国内処理が保証されているか
  • クロスリージョン処理やフォールバック先を制限できるか
  • 推論以外の通信先(MCP、Webサーチ、ブラウザ、監視、認証)はどこか
  • 端末、ログ、バックアップ、運用者アクセスまで要件を満たすか

Microsoft Foundryは扱いが異なります。公式資料によれば、AnthropicがClaudeモデルを運用し、Microsoftの独立した処理者として会話データを扱います。BedrockとGoogle Cloudでは、データの扱いはそれぞれのクラウド事業者の規定に従います。データ在留が要件なら、経路ごとに評価してください。

3-4. ゲートウェイ経由で他モデルを使えるか

自社ゲートウェイ(LiteLLM、Portkey、自作プロキシなど)を推論先にするには、Anthropic Messages APIのPOST /v1/messages(ストリーミングとツール利用を含む)を実装する必要があります。モデルの自動検出は、Claudeと判別できるモデルIDだけを表示します。公式説明はClaudeモデルを前提としており、背後に非Claudeモデルを置いた場合の動作や品質は示されていません。この使い方は公式サポートの外と考えておくのが安全です。

出典:Anthropic公式「Deploy Claude Desktop on 3P with an LLM gateway」

4. 商用の競合:機能は重なるが、同等性は別の話

Coworkと機能が重なる商用製品は、2026年に相次いで登場しました。ただし、機能の重複があることと、同じ条件で同等に業務を完遂できることは別です。同一タスクでの比較検証は今回確認できていません。

製品 確認できた事実 留保
Microsoft Copilot Cowork 2026年3月9日に発表、6月16日に世界でGA(Microsoft公式)。GA時の変更一覧でOpus 4.8への対応が記載されている(Microsoft Learn) Microsoft 365テナント前提。オンプレミス版は確認できない
ChatGPT Work(Codex統合) 2026年7月9日に登場(OpenAI公式リリースノート)。文書・表計算・プレゼン生成と、スケジュール・トリガー・変更監視に対応 Enterpriseでのトリガー条件など細部は別途確認が必要。SaaS前提で、オンプレミス版は確認できない
Gemini agent(Gemini Enterprise) 2026年10月8日に発表(Google Cloud公式)。報道によれば発表時はプライベートプレビュー 11月時点の提供段階は未確認

出典:Microsoft、Microsoft Learn、OpenAI、Google Cloud

5. オープンソース:部品は揃うが、ライセンスの読み分けが要る

5-1. 候補

gooseは、Apache 2.0のOSSで、Linux Foundation傘下のAgentic AI Foundation(AAIF)のプロジェクトです。デスクトップアプリ(macOS・Linux・Windows)、CLI、APIを備え、Ollamaを含む15以上のプロバイダと、MCP経由で70以上の拡張に対応します。サブエージェントの並列・逐次実行も公式文書に記載があります(GitHub)。ローカルで動く設計なので、隔離は別に用意する必要があります。

OpenWorkは、OpenCodeをベースにしたデスクトップアプリで、「Claude CoworkのOSS代替」を掲げています。開発元はDifferent AI, Inc.です。MIT部分とEE(Enterprise Edition)部分が混在する点に注意が必要です。

5-2. ライセンスの要点

「オープンソース」と書かれていても、OSI承認のOSSと、追加条件付きのsource-available/fair-codeが混在しています。

対象 区分 条件の要点 採用時の確認
OpenWork MIT部分とEE部分が混在 EE部分の本番利用には有効なサブスクリプションが必要。例外は、Enterprise Featuresを除き組織全体で5ユーザー以下、初回デプロイから30日以内の評価、開発・テスト。各版は公開の2年後にMITで利用可能になる 条文はdevブランチのもの。リリースタグと使う部位を固定して再確認する
Open WebUI source-available(開発元の説明) 任意の連続30日間に直接アクセスする自然人が50人を超える場合、ブランド変更に条件がある。権利者の個別の書面許可という経路もある 利用規模とブランド変更の有無で判断
n8n fair-code 非商用・個人利用は可能。コンサルティングや構築・保守サービスも許容される 再販・埋め込みなど具体的な形態で判定する
Dify Apache 2.0に追加条件 マルチテナント運用とロゴ除去に条件があると説明されている 対象タグのLICENSE条文で確認する

出典:OpenWork EEライセンス、Open WebUI LICENSE、n8n

6. 国内の閉域基盤とセルフホストモデル

提供元・製品 確認できた内容 提供形態 留保
NTTドコモビジネス+エクサウィザーズ「クローズドAIエージェント」 2026年8月17日提供開始。エクサウィザーズのexaBase Studioと、閉域ネットワーク・GPU基盤を組み合わせる。tsuzumi 2やOSSのLLMを専用環境で動かし、プロンプトは外部のAIサービスに送られないと説明。オンプレミス版はハードウェアからLLM、エージェントまでを国内の自社環境内で完結できるとされる プライベートクラウド版、オンプレミス版。運用保守はNTTドコモビジネス 申し込みは営業窓口経由。プロンプトインジェクション対策やガバナンス機能は「今後強化を推進」とされ、整備途上
富士通 Kozuchi Enterprise AI Factory 製品ページによれば、LLMのTakane、PRIMERGY/Private GPT上の専用環境、追加学習、量子化、低コード/ノーコードのエージェント開発(MCP・エージェント連携)を備え、オンプレミスにも対応 専用環境(オンプレミス対応) 提供開始日や導入実績は製品ページからは確認できない

出典:NTTドコモビジネス ニュースリリース(2026年8月17日)、富士通 製品ページ

セルフホストできるモデルについては、「動く」という言葉の中身を確認する必要があります。

  • tsuzumi 2は、NTT自身の資料で30B規模とされています。重みを16bitで持つと、30B × 2バイトで約60GBというのが筆者の単純計算です。「A100 40GB 1枚で動く」は、量子化方式、コンテキスト長、同時実行数の前提を付けないと仕様として扱えません。
  • Qwen3.8-27Bは、公式モデルカードで27Bであることと長いコンテキストへの対応が確認できます。「4bitで17〜19GB」という数字は、ファイル容量なのか実行時メモリなのかが不明なので、構成設計の根拠にはできません。
  • Kimi K3は、公式モデルカードで2.8Tパラメータとされています。単一GPU級ではなく、複数ノードの運用が前提になります。
  • gpt-oss-120b/20bは、2025年8月公開でApache 2.0のモデルです。小〜中規模のGPUで運用しやすい一方、最前線のモデルとの差は用途次第です。

ベンチマーク値の多くはベンダーの公表値で、同一のハーネスで比べたものではありません。エージェントとしての採否は、自組織のタスクで測って決めてください。

7. 構成ごとの整理

下の表は、公式資料で確認できる機能の有無と、追加で作り込む部分を並べたものです。同一タスクでの成功率や成果物の品質を比べた結果ではありません。

構成 標準で揃う機能 追加構築が必要な点 閉域適合性 主な留保
Claude Desktop on 3P Cowork、Code、Chat。サブエージェント、スキル・プラグイン・フック、ローカル/リモートMCP、スケジュール(ローカル)、内蔵ブラウザ、MDM配布、OTel 推論基盤(Bedrock、Google Cloud、ゲートウェイ)、Webサーチプロバイダ、IdPとMDM オフライン版で運用時の外向き通信を推論先のみにできる。完全オンプレミスのClaude推論は確認できない Computer Useなど一部機能は対象外。スケジュールは端末の稼働が条件
商用SaaS(Copilot Cowork、ChatGPT Workなど) 各社のエージェント機能。文書・表計算・プレゼン生成、スケジュール テナント設定、予算管理、権限設計 SaaS前提。オンプレミス版は確認できない 同一タスクでの比較検証は確認できない
goose+セルフホストLLM デスクトップ/CLI/API、MCP拡張、サブエージェント、15以上のプロバイダ サンドボックスによる隔離、承認ポリシー、スキル配布、監査ログ 構成次第で完全閉域が可能。外部通信を遮断した実機試験が条件 長時間タスクとOffice成果物の品質はモデル依存で、検証が必要
OpenWorkなど+セルフホストLLM OpenCodeベースのデスクトップ、ローカルモデル対応 EE条件の確認、隔離、統制機能 同上 ライセンス条文の部位ごとの確認が必要。継続性は調達側で見極める
国内閉域基盤+OSSフロント 閉域/オンプレミスの推論と運用、日本語LLM、ベンダーによってはMCP・エージェント連携 OSSフロントとの接続検証(OpenAI互換エンドポイントなど)、エージェントUX NTTのオンプレミス版は国内の自社環境で完結と説明されている Cowork型の汎用デスクトップ体験そのものではない

8. 構成案

案A:公式Coworkの閉域クラウド版

Claude Desktopをオフラインインストーラーで配布し、MDMで設定します。推論は国内リージョンのBedrockまたはGoogle Cloud(3-3の確認条件を満たすこと)、必要ならLiteLLMなどのゲートウェイを挟みます。社内MCPサーバー、OTelコレクタ(SIEM連携)、egress許可リストを組み合わせます。再現度は最も高く、構築と運用の負荷は低〜中です。課金はトークン従量で、GPU投資は要りません。ただし、完全オンプレミスの要件は満たせません。

案B:完全閉域のOSSスタック

フロントにgooseかOpenWork、ゲートウェイにLiteLLM、推論にvLLMとセルフホストモデル、実行隔離にコンテナ/microVM型のサンドボックス、そして社内MCPサーバー、IdP、OTelとSIEMを置きます。完全エアギャップが可能な一方、モデル更新、評価、サンドボックス保守、MCPのセキュリティレビューを自前で回す体制が要ります。コストは、GPU、構築SI、運用人員が中心です。利用規模、稼働率、トークン量次第でクラウド従量課金と逆転する可能性はありますが、TCOを置いて試算しないかぎり、どちらが安いかは言えません(筆者の推定)。

案C:国内閉域基盤とOSSフロントのハイブリッド

推論とガバナンスに国内ベンダーの閉域基盤を使い、ユーザー接点にgooseなどをOpenAI互換エンドポイント経由で接続します。日本語、データ主権、保守体制は強みですが、汎用デスクトップ・エージェントのUXはOSS側に依存します。接続の検証が前提で、費用は個別見積になります。

9. 非機能面で見落としやすい点

  • データの所在:3Pでは、会話履歴は端末に保存され、推論データの扱いは選んだプロバイダ(Bedrock、Google Cloud、Foundry、自社ゲートウェイ)で変わります。
  • 監査・権限:Coworkには、OpenTelemetryのイベント(承認が手動か自動かも含む)、RBAC、コネクタのツール単位制御があります。OSSでは、こうした統制機能の多くを自前で実装するか、商用版を買う構図になりやすいと考えられます(OpenWorkのEE条件は一例です)。
  • プロンプトインジェクション対策:CoworkのAuto modeの安全審査に相当するOSS機能は、今回の調査範囲では確認できませんでした。緩和策としては、承認を既定でオンにする、MCPツールを読み取り専用に絞る、egressを許可リストで制限する、サンドボックスで実行する、が現実的です。
  • 日本語性能:tsuzumi 2やTakaneは日本語の強さを打ち出していますが、エージェントとしての横並びの公開評価は確認できていません。
  • 調達上の判断:海外製、特に中国製のオープンウェイトモデルを使えるかは、所管の調達・セキュリティ方針に照らして判断する必要があります。

10. まとめ:進め方

閉域・オンプレミス環境でも、OSSのエージェント基盤、MCP、セルフホストLLM、実行サンドボックスを組み合わせて、Coworkと重なる主要機能を構成することは可能です。ただし、機能の再現割合やCoworkとの品質差は、対象業務と検証構成を定義した比較評価なしには定量化できません。

Claude Desktop on 3Pは、公式のデスクトップ体験を第三者の推論基盤で使う候補です。オフラインインストーラーで、Anthropicへの実行時通信を排除する構成もあります。ただし、完全オンプレミスのClaude推論を公式に使えることを意味しません。

結論を出す前に、次の順で進めるのが妥当です。

  1. 要件を分類する。クラウド閉域でよいのか、完全エアギャップが必須なのか。
  2. 代表的な業務を10〜20件選ぶ(日本語の文書作成、Excel集計、社内システムのWeb操作など)。
  3. 案A、B、Cで同じタスクを並べ、成功率、手戻り、所要時間、成果物の品質を測る。
  4. 外部通信を遮断した環境で、実際の通信先を測る。
  5. MCPサーバーのレビュー、承認ポリシー、egress許可リストを整える。
  6. スキルやプラグインの社内配布とバージョン管理の体制を作る。
  7. 段階的に展開し、モデルを定期的に再評価する。

この検証が終わるまでは、「OSSで7〜8割再現できる」「同等品質は不可能」「この構成が最良」のいずれも、確定した結論として扱わないのが安全です。

主な一次情報:Claude Desktop on 3P 導入手順、同 機能表、同 ゲートウェイ、Cowork GA発表、goose、OpenWork EEライセンス、NTTドコモビジネス、富士通

月曜日, 11月 02, 2026

Anthropic S-1を読む:売上は14倍、Q2で営業黒字化。だが本当の論点は「コンピュート契約」だった

2026年10月26日、Anthropic, PBCが米証券取引委員会(SEC)にForm S-1を公開提出しました。フロンティアAIモデルを開発する企業が、上場申請書類という形で財務・契約・ガバナンスの中身を開示した、業界にとって重要な一次資料です。

結論から言うと、読みどころは次の3点です。

  • 2026年上期の売上は162.86億ドルで、前年同期(11.63億ドル)の約14倍。第2四半期には単独で初の営業黒字(営業利益9.74億ドル)を計上しましたが、上期通算では営業赤字です。
  • コンピュート関連の将来支払義務は桁違いに大きい一方、購入義務・リース・条件付き契約が混在しており、S-1自身は統一的な総額を示していません。
  • 創業者LLC(Class F)と長期利益信託(LTBT、Class T)に支配権が集まる特異な株式構造を採っています。想定価格帯・株数・調達額は空欄で、評価額の議論はすべて推測です。
本記事は2026年11月2日時点の公開情報に基づきます。S-1は約400ページあり、一部の数値は原文を引用した第三者の分析・報道によるため、本文中にその旨を明記しています。2026年上期・四半期の数値は未監査です。見通しに関する記述は筆者の推定であり、投資助言ではありません。

1. IPOの基本条件:確定していること、空欄のこと

項目内容確認状況
提出書類・日付Form S-1、2026年10月26日提出(登録番号333-299633、Accession No. 0001628280-26-067168)SECのEDGARで確認
上場先・ティッカーNasdaq Global Select Market、「ANT」。いずれも上場予定であり、上場完了ではありませんS-1、Anthropic公式発表
想定価格帯・株数・調達額空欄(「between $ and $」のまま)S-1表紙
主幹事・引受団Goldman SachsとMorgan Stanleyを中心に全22社(MizuhoとMUFGを含む)S-1表紙
募集形態会社による新株発行と既存株主による売出しの併用。日本を含む複数国で公募S-1表紙
監査人2023〜2024年はGrant Thornton、2025年はErnst & Young(2025年10月30日にGrant Thorntonを解任)S-1。Exhibit 16.1は監査人変更に関する書簡
S-1/A(修正届出)2026年10月末時点で未提出EDGAR提出一覧
上場時期・評価額WSJが「11月16日の週の上場を目指し、調達1,000億ドル以上・評価額1.5〜2兆ドルの可能性」と報道報道のみ・未確認

出典:SEC EDGAR提出索引、Form S-1、Anthropic公式発表

価格帯がない以上、バリュエーションに関する議論は現時点では推測にとどまります。米国の慣行では、価格帯を記載したS-1/Aがロードショーの直前に提出されます。

2. 財務:売上14倍と「Q2単独の営業黒字」

項目(単位:百万ドル)2024年2025年2025年上期(未監査)2026年上期(未監査)
売上高3864,5851,16316,286
コンピュート・インフラ費用2,5227,3262,3348,945
営業損失(2,980)(8,060)(2,135)(693)
転換社債等の公正価値変動(損失)(5,434)(34,308)(10,942)(72,388)
純損失(8,309)(41,965)(12,969)(80,748)
調整後営業利益(会社定義の非GAAP)(2,788)(4,854)(1,849)1,618

出典:Form S-1の財務諸表・Summary Consolidated Financial Data。2025年は2024年までと監査人が異なります。

四半期でみると、売上は2025年第1四半期の3.76億ドルから、2026年第1四半期に47.31億ドル、第2四半期に115.55億ドルへ拡大しました。

2025年Q1
3.76億ドル
2026年Q1
47.31億ドル
2026年Q2
115.55億ドル

出典:S-1の四半期売上(未監査)。バーはQ2を100%とした相対値。

第2四半期の営業利益は9.74億ドルで、初の営業黒字です。ただし上期通算の営業損失は6.93億ドルのままで、黒字は「Q2単独」の話です。通期での黒字化や、持続的な採算の確立とは別に考える必要があります。また第3四半期の売上額は、S-1の時点では確定値として記載されていません。

3. 粗利益率は「2つの指標」で見る

S-1は2025年から費用を「性質別」に表示するようになったため、損益計算書に売上総利益の行がありません。そのため、粗利益率に相当する数値は読み手が組み立てる必要があります。

  • 約85.4%:注記8の機能別内訳にある売上原価2,380百万ドルから算出した粗利益率((16,286−2,380)÷16,286)。S-1自身が開示した比率ではなく、筆者の計算値です。
  • 約54.9%:研究開発(次世代モデルの学習)向けを含むコンピュート・インフラ費用の総額(8,945百万ドル)を売上で割った比率です。

両者は代替関係にある指標ではなく、見ているものが違います。前者は顧客に提供している部分の採算、後者は学習を含む計算資源への支出負担です。他社と比べる際は、費用の配賦ルールとCSP手数料の表示(Anthropicは販売・マーケティング費に計上)の違いを調整せずに横並びにしないよう注意が必要です。たとえばMicrosoftも、AI学習・研究用のインフラ費用は研究開発費として売上原価とは区分しています。

4. 純損失807億ドルと、現金の見方

2026年上期の純損失807.48億ドルの大部分は非現金項目です。キャッシュフロー計算書では、転換社債などの公正価値変動72,388百万ドルと、その他金融商品の認識・公正価値変動8,720百万ドルが調整項目になっています。ただし「非現金」であることは、転換や希薄化といった経済的な影響がないことを意味しません。

  • 営業キャッシュフローは、2025年上期の▲15.13億ドルから2026年上期は+39.29億ドルに改善しました。設備投資4.82億ドルを引くと約34.47億ドルです。
  • 現金・現金同等物1,123.89億ドルと短期投資192.62億ドルの合計1,316.51億ドルは、2026年6月30日時点の残高です。11月時点の残高や、将来のリース義務を差し引いた余力を示す数字ではありません。

5. 収益構成と顧客指標

  • 課金形態:2026年上期は従量課金(API・トークン課金)が13,064百万ドル(約80%)、サブスクリプションが3,222百万ドル(約20%)です。
  • CSP経由:AWS・Google Cloud・Microsoftのマーケットプレイス経由が売上の約48%です。Anthropicが顧客と直接契約して価格を設定するため、売上はグロス計上で、CSP手数料は販売・マーケティング費に入ります(S-1の注記を引用した分析による)。
  • 地域:請求先住所ベースの海外売上は4,523百万ドルで、全体の約28%です。
  • 顧客数:2026年9月30日時点で、直近12か月の売上が10万ドルを超える顧客は11,900社超です。
  • 顧客集中:MD&Aを引用した分析によれば、2026年1〜9月の売上の約25%を上位5社が占め、単独で10%を超える顧客はありません。一方、リスク要因は、上位顧客の多くが長期契約ではなく、いつでも支出を減らせると述べています。
  • 規約違反顧客:2026年1〜9月の売上の5〜7%は、後に利用規約違反と判明した顧客からのものと会社が推計しています。監査済みの確定割合ではなく、執行の強化で低下する見込みとされています。

5-1. NRR約900%の読み方

S-1が示すNet Revenue Retention(NRR)は約900%です。定義は、基準期間(前年同期の3か月)に1ドル以上の売上があった顧客群について、当期3か月の売上を基準期間の売上で割ったもので、Pro・Max個人契約は除外されています。同一顧客群を4四半期前と比べる方式自体はCloudflareなども採っており、方式が特殊なわけではありません。

注意すべきなのは、①基準期間に1ドル以上という広い対象条件、②個人契約の除外、③急成長期の顧客構成です。また900%は対象群の売上合計が約9倍という意味で、全顧客が一律に9倍使ったという意味ではありません。

6. コンピュート契約:巨額だが「総額」は一つに決まらない

S-1は、AWS Trainium、Google TPU、NVIDIA GPU、AMD GPUの複数チップを「単一の可換プール」として運用する方針を示しています。一方で、総コミットメント額の記載欄(「more than $」)は空欄です。注記から読み取れる主な区分は次のとおりです。

区分開示額注意点
6月30日時点の固定・最低購入コミットメント約2,656億ドル購入契約に関する注記
同日時点の未開始リース義務約3,214億ドル割引前の見積将来支払額。一部は契約条件の充足が前提
6月30日後の新規・改定契約約2,450億ドルリース・商業契約を含み、一部は条件付き
追加の短期契約(後発事象)約210億ドル別途記載されている

出典:Form S-1の注記(引用した分析を含む)。

これらを単純に足した値を、会社が公表した総コミットメント額とみなすことはできません。S-1が統一的な総額を示していないうえ、注記間の重複、契約改定、集計時点の違いを調整する必要があるためです。報道の集計も、CNBCの約4,170億ドル、Fortuneの5,420億〜5,670億ドルなど、集計範囲によって割れています(Fortuneは「2025年12月31日に4,170億ドル」と表現し、Bloombergは「2025年末以降の新規コミットメント」と説明するなど、時点の説明も一致していません)。S-1/Aでどこまで整理されるかは、今後の確認事項です。

個別契約の大きさは、次のように伝えられています。

相手先内容金額期間・解約条件
BroadcomTPU機器のリース約1,612億ドル(賃料、利息除く)5年リース。債務不履行時を除き解約不可
SpaceXAINVIDIA GPU(Colossus)最大約1,205億ドル2029年まで。初期期間(2027年1月・3月)終了後は90日前通知で解約可
Google Cloudクラウド・TPU最低約1,145億ドル2026年4月〜2033年7月
AWSクラウド・Trainium最低約1,100億ドル2026年5月〜2036年4月
Microsoft Azureクラウド最低約449億ドル2026年11月〜2033年5月
NscaleNVIDIA GPU最大約446億ドル2033年まで
LambdaNVIDIA GPU約413億ドル2034年まで

出典:S-1のMD&Aを引用した分析(主要4社の金額は複数の報道で一致)。契約ごとに解約条件が異なるため、一律に「解約不可」とは言えません。

6-1. 構造上の論点

  • 期間のミスマッチ:売上の約8割は解約されやすい従量課金で、支出側には数年〜10年超の固定的な契約が積み上がっています。
  • CSPとの利益相反:Amazon・Google・Microsoftは、出資者であり、販売チャネルであり、供給者であり、自社モデルを持つ競合でもあります。S-1はこの関係を、価格や配分、契約更新で不利に働きうるリスクとして挙げています。
  • 地理的な集中:S-1は、計算基盤の大部分が米国にあることを集中リスクと認め、米国外でのデータセンター容量の確保を進めていると記載しています。CNBCは、オーストラリアとカナダでのリース締結を報じています。オーストラリアの最初のリースは2.16GW規模のキャンパスで、同国の外国投資審査の承認待ちとReutersが伝えています(報道ベースで、S-1本文では直接確認していません)。

7. ガバナンス:一般株主の影響力は限定的

Anthropicはデラウェア州の公益法人(PBC)で、定款上の公益目的は、人類の長期的利益のための高度なAIの責任ある開発と維持です。株式は議決権の異なる複数のクラスで構成されます。

クラス主な保有者議決権備考
Class A一般投資家、創業者ら1株1票経済的権利あり
Class N戦略パートナー(Amazon、Googleなど)原則なし経済的権利あり。議決権株ベースの主要株主表には現れにくい
Class T(1株)Long-Term Benefit Trust(LTBT)取締役の過半(Class T枠)を選任経済的権利なし
Class F(1株)共同創業者7名のLLC株主総会議決権の50.1%を常時保持経済的権利なし。共同創業者が3名未満の状態が90日続くとサンセット条項が進行

出典:Form S-1「Our Capital Structure」(引用した分析を含む)。

  • LTBT:受託者の定員は5名ですが、提出時点で1席が空席で、実員は4名です。取締役会は7席で、うちClass T枠は4席、その1席が空席です(受託者の空席と取締役席の空席は別の話です)。
  • Controlled company:Nasdaqの「controlled company」に該当しますが、適用除外を使うのは指名・ガバナンス委員会のみとしています。
  • 読み方:一般株主の会社支配への影響は非常に限定されます。ただし「実質的な影響力が小さい」ことと「法的な権利がない」ことは別です。また、LTBTの権限も絶対・永久不変ではなく、所定の承認経路で変更できる仕組みがあります。「株主圧力で安全方針が変わりにくいから、調達先として予見可能性が高い」という見方は、確認された事実ではなく条件付きの分析にとどまります。

8. リスク要因・規制・訴訟

S-1のリスク要因は約90ページに及びます。目を引くのは、米国政府の措置が実際の事業リスクとして具体的に書かれている点です。

項目S-1・報道の記載確認状況
米政府による調達排除2026年2月に大統領が連邦機関へAnthropic製品の使用停止を指示し、国防総省がサプライチェーンリスクに指定S-1のリスク要因に記載
輸出管理2026年6月、商務省の輸出制限によりFable 5とMythos 5を全顧客向けに一時停止(6月12日に停止、制限は6月30日に解除、7月1日にアクセス復旧)。同様の措置が再び課されるリスクも開示S-1およびAnthropic声明
著作権(Bartz集団訴訟)2025年第3四半期に15億ドルを計上して和解し、2026年7月に裁判所が承認したとS-1が説明S-1の説明。裁判記録での照合は未了
国防総省指定をめぐる訴訟8月27日に北カリフォルニア連邦地裁がAnthropic側を支持、9月25日にD.C.巡回区控訴裁がFASCSA第4713条に基づく指定を2対1で支持。Anthropicは大法廷での再審理を申立てS-1・報道ベース。裁判記録での照合は未了
その他の係属事件音楽出版社による著作権訴訟、Redditによるデータ利用をめぐる訴訟(請求は9月に整理)S-1・報道ベース

出典:Form S-1、Anthropic声明、報道。

そのほか、S-1は次のようなリスクを挙げています。

  • 需要が供給を上回り続けてきたコンピュートの確保、エージェント型ワークロードによる計算消費の増加
  • 安全策なしに開発された高度なAIが壊滅的リスクをもたらしうるという懸念、評価中のモデルが意図しない外部アクセスを行った事例
  • 主要な競合としてGoogleとOpenAIを明記。オープンウェイトモデルやCSP自身のモデルも脅威として記載
  • モデルの重みの窃取、プロンプトインジェクション、TSMC(台湾)への製造集中、電力・データセンター立地の制約

安全性についてS-1は、Responsible Scaling Policy(RSP)を壊滅的リスクへの対処方針と位置づけています。公式の履歴では、最新版はv3.4(2026年7月8日発効)です。また、安全上の判断でリリースの遅延や提供範囲の限定を行ってきたこと(Mythos Previewの限定公開など)が、競合に対する速度や企業での採用に影響しうると認めています。

9. 日本との接点

S-1上で確認できる日本関連の情報は多くありません。日本は公募の対象国に含まれ、引受団にMizuhoとMUFGが入っています。海外売上は全体の約28%(請求先住所ベース)ですが、日本単独の売上や顧客数は開示されていません。取得したS-1本文のテキスト検索では、Tokyoなどの拠点名も見当たりませんでした(図版内の文字や添付資料を含む完全な不在証明ではありません)。

S-1の外では、次の動きが公式発表などで確認できます。

  • 2025年10月29日:東京に初のアジア太平洋オフィスを開設し、日本AIセーフティ・インスティテュート(J-AISI)と協力覚書を締結
  • 2026年4月23日:NECが日本企業として初のグローバルパートナーに(約3万人への展開計画)
  • 2026年5月19日:日立が戦略的パートナーシップを発表
  • 2026年5月27日:富士通が戦略的パートナーシップを締結(グループ約10万人での活用、約1,000人規模のエンジニアチーム、最新モデルへの早期アクセスなど)。同日、OpenAIとの連携も発表
  • 2026年10月:日経とReutersが、大阪に最大500MW・最大1兆円規模のAnthropic向けデータセンターが検討されていると報道。2026年度末までの合意を目指す交渉段階で、2028年にも一部稼働の見込み

大阪の件は報道ベースで、当事者による確認は取れていません。また、国内にデータセンターが建つこと、データが国内に保存されること、ソブリンAIであることは同じ意味ではありません。各社の提携発表にはデータ主権への配慮が示されていますが、Claudeの国内完結運用や、米国側の提供停止措置から独立した利用権が保証されたという記載は確認できません。国内の立地、データの所在、運用権限、モデルの利用権、外国法の影響は、それぞれ別に評価する必要があります。

10. まだ確定していないこと・今後の注目点

  • 想定価格帯、株数、調達額、評価額(S-1/Aで記載される見込み)
  • 総コミットメント額(S-1/Aでどこまで整理されるかは要確認)と、第3四半期の確定決算
  • 新規コンピュートの稼働に伴う利益率の変化
  • 国防総省指定をめぐる訴訟の行方と、輸出管理措置の再発の有無
  • 日本でのデータセンター立地の正式な発表と、日本市場の売上規模(現状は未開示)
  • OpenAIは未上場で、財務数値はすべて報道ベースです。売上の計上方法も異なるため、単純な横比較は避けるのが妥当です

11. まとめ

S-1が示したのは、驚異的な成長と、それを支える巨額の固定的な支出が同居する姿です。売上と営業キャッシュフローの改善は確かな事実ですが、Q2単独の黒字、未監査の四半期数値、統一されない契約総額、空欄のままの価格帯など、断定できない部分も多く残っています。S-1/Aと第3四半期決算が出たところで、数字を更新して読み直す価値があります。

参考:

火曜日, 10月 27, 2026

IDCFクラウドとGMOデスクトップクラウド:2つの事案を公表情報で整理する(10月27日夜時点)

先日公開した記事「IDCFクラウド・ランサムウェア事案を整理する:ISMAP登録サービスで何が起きたか」は、10月9日夜時点の情報に基づくものでした。その後、10月27日にIDCフロンティアが第7報で一連の調査の完了を公表し、侵入経路が公式に説明されました。同じ時期には、GMOインターネットグループの「お名前.com デスクトップクラウド」への不正アクセスと恐喝が進んでいます。

本記事は、公表された情報をもとに、元記事からの変化とGMO事案を整理した続報です。結論を先に書きます。

  • IDCF:侵入経路の概要が公表されました。第7報によれば、IDCFクラウドポータルの認証システムで使っていたOSSの脆弱性を突かれて侵入され、管理コンソール経由で仮想化基盤の管理者権限を取得されました。OSSの名称や脆弱性識別子は公表されていません。
  • IDCF:データの流出は確認されていません。仮想サーバー内のデータの外部流出は確認されていません。一方、ポータルの登録情報は最大71社分に不正な照会があり、ログインパスワードが最大4件、不正に変更されていました。バックアップデータを取り出せる顧客は、495のうち206です。
  • ISMAP:「未決定」のままです。10月27日夜時点で、IDCFの登録一時停止や再監査の公表は、筆者が確認できた範囲ではありません。
  • GMO:進行中の事案です。影響の可能性があるサーバーは26,739件(確認された被害件数ではなく、上限の数字です)。10月27日には攻撃者とみられる者による情報公開が確認され、同日夜の第12報で、特別見舞金と総額100万米ドルの懸賞金が公表されました。
  • 両事案の関連を示す公開根拠は、確認できません。
本記事は2026年10月27日夜時点(GMOの第12報は19時10分時点)の公開情報に基づきます。GMO事案は進行中で、内容が短時間で変わる可能性があります。公式発表を一次情報とし、報道に基づく部分はその旨を書いています。評価や見通しは筆者の見解です。

1. IDCF第7報で分かったこと

IDCFは10月27日、第7報で一連の調査の完了を公表しました。元記事の公開時点(10月9日夜)と比べると、次の点が変わっています。

論点 10月9日夜時点(元記事) 第7報(10月27日) 補足
侵入経路 未公表 IDCFクラウドポータルの認証システムで使っていたOSSの脆弱性を悪用して侵入された。 OSS名、脆弱性識別子、初期侵入の詳しい手順は公表されていない。
攻撃の流れ ランサムウェア攻撃(詳細は調査中) 認証システムへの侵入後、管理コンソール経由で仮想化基盤の管理者権限を不正に取得。顧客の仮想サーバーを停止し、仮想サーバー自体を暗号化した。 影響範囲は東日本リージョン1の4ゾーン(tesla/henry/pascal/joule)。495の企業・自治体。
仮想サーバー内データの流出 未公表 外部への流出はなかったと判断。持ち出しを示す痕跡や裏付ける事実は確認されていない。影響のなかったゾーンや他リージョンでも同様。 10月14日の第5報で示された判断。本件に起因する不正利用などの二次被害も、現時点では確認されていない。
ポータルの登録情報 未公表 最大71社の登録情報に不正な照会。個人名または個人名を含む可能性があるメールアドレス等が最大31社(31件)。ログインパスワードが最大4件、不正に変更されていた。 第5報時点は48社。外部への持ち出しの痕跡は確認されていない。該当パスワードはリセット済みで、対象顧客には個別に連絡。
バックアップデータの取り出し 「取り出し・復元が困難な見通し」 206の顧客で取り出し可能(10月20日に判明)。 第5報時点は194顧客。残る289顧客について、同じ方法で取り出せるとの公表はない。
攻撃者との接触 記載なし 攻撃者と接触しておらず、身代金の支払いや交渉は一切行っていない。

出典:IDCフロンティア 第7報(2026年10月27日)、第5報(10月14日)、第3報(10月8日)

1-1. 攻撃の経路をどう読むか

公式の説明では、攻撃は「ポータルの認証システム → 管理コンソール → 仮想化基盤の管理者権限」という経路で進みました。顧客の仮想サーバーの中から侵入されたという説明ではありません。仮想サーバー内のデータの流出が確認されていない一方で、サーバーが止まり暗号化されたのは、管理側の権限が奪われたためと読めます。

なお、これは公式説明の範囲での整理です。OSSの名称、脆弱性の識別子、攻撃者の初期侵入からの詳しい手順は、第7報でも明らかにされていません。

1-2. 復旧の現状とポータル再開の見通し

  • 東日本リージョン1の一部以外の仮想サーバーは稼働中です。ただし、脆弱性のあった「IDCFクラウドポータル」は外部から遮断され、利用停止が続いています。
  • ポータルの再開は3段階の予定です。第1段階(現在実施中)はIDCFが主要な操作(仮想サーバーの起動・停止、各種設定変更など)を代行します。第2段階で全機能の操作を代行し、第3段階で全機能を顧客自身が操作できる状態に戻します。再開の時期は示されていません。
  • 再開に向けて、ポータルの新環境での再構築、全サーバーの認証情報の変更、認証システムの外部IdP(Identity Provider)事業者のシステムへの刷新、接続元のIPアドレス制限、多要素認証の必須化を進めるとしています。
  • 再発防止策として、セキュリティ専任の独立組織の設置(対応済み)、脆弱性診断・攻撃診断の対象範囲のOSSへの拡大、ソフトウェア構成情報の全社一元管理(SBOM化)と脆弱性情報との突合の自動化を挙げています。

「IDCFクラウド バックアップ」は、10月18日の第6報で提供が再開されています。

2. 元記事の記述はどうなったか(答え合わせ)

元記事で「未公表」「見通し」と書いた点と、筆者の推定について、現時点の状況を並べます。

元記事の記述(10月9日夜) 現時点の状況 10月27日夜時点で言えること
4ゾーンのデータは「取り出しや復元が困難な見通し」。復元は顧客自身のバックアップからのみ(IDCFの現時点の見解) 一部更新 元記事も「見解は変わる可能性がある」と書いていました。第5報はスナップショット機能を使っていた顧客について、IDCF側のバックアップデータを取り出せると説明し、対象は206顧客に増えました。取り出せることと、システムとして復元できることは別で、代替環境への移行や取り出しの手順は、ソフトバンクと連携して個別に提案されています。
侵入経路は未公表 更新 ポータル認証システムのOSSの脆弱性が悪用されたと公表されました。OSS名と識別子は未公表です。
情報漏えいの有無は未公表 更新 仮想サーバー内データの外部流出は確認されていません。ポータルの登録情報は、最大71社に不正な照会があり、最大4件でパスワードが不正に変更されました。「漏えいなし」と一括りにせず、データの層を分けて読む必要があります。
SNSで出回った暗号化の主張画像は、攻撃者側の主張とされ真偽未確認 未確定 第7報は、ランサムウェアにより仮想サーバー自体が暗号化されたと説明しています。画像の真偽には触れていません。
事業者側のバックアップの構成は未公表 一部判明 事業者側の保存データから取り出せる顧客が206いたことは分かりました。構成の詳細は公表されていません。
全リージョンの管理コンソールを停止中 更新 全リージョンのポータルは外部から遮断され、利用停止が続いています。他リージョンの仮想サーバーは稼働中で、主要な操作はIDCFが代行しています。
ISMAPの一時停止・再監査は公表なし。再監査の可能性は「十分にある」が、未決定(筆者の推定) 未確定 10月27日夜時点でも、筆者が確認できた範囲では公表がありません。第7報にISMAPへの言及もありません。推定の当否は、まだ判定できません。
管理系の分離やバックアップを含む復旧性に関する統制の実効性が論点になり得る(筆者の推定) 手がかりが出た 攻撃が管理系の経路で進んだことが公式に示されました。ただし、ISMAPの統制に不備があったかどうかの評価は公表されていません。
infoQ「最大約95万件」 更新 10月14日の第2報で、89万4,082件の外部持ち出しを確認したと報じられています。これは情報の記録件数で、同数の人数とは限りません(4-5参照)。
可用性とサプライチェーンへの波及で最も重大な事案の一つ 維持 第7報で、IDCFの社長も顧客のさらに先の事業活動にまで影響が及んだ重大な事態と述べています。

出典:IDCフロンティア 第7報、第5報。infoQは報道による

3. ISMAPの現状

  • 10月27日夜時点で、ISMAPクラウドサービスリストにはIDCFクラウド(登録番号C23-0070-2)が掲載されています。備考欄には、2026年2月27日に登録の有効期限や監査対象期間などを変更したこと、9月30日に更新申請が行われているため有効期限以降も登録は有効であることが記されています。
  • 今回の事案を理由とする登録の一時停止や再監査の開始は、筆者が確認できた範囲では公表されていません。ただし、「公表を確認できない」ことは「ない」ことの証明ではありません。
  • 登録規則上、一時停止や再監査は「できる」規定であり、インシデントが起きたことで自動的に発動するものではありません。この点は元記事から変わっていません。

筆者の見解:第7報が示した攻撃経路と、IDCFが再発防止策で挙げた項目は、重なっています。OSSを含む脆弱性管理、管理系の権限の持たせ方、ポータルへの接続の認証強化(接続元IPの制限と多要素認証)です。ISMAP側が何を論点にするかは未公表ですが、運営委員会が判断する場合は、これらが統制の実効性を確認する材料になると考えます。ただし、統制の不備を指摘できる根拠は、公開情報にはありません。

4. GMO:お名前.com デスクトップクラウドへの攻撃

10月のGMOグループでは、性質の異なる2件の侵害が公表されています。規模、影響、恐喝を伴う点で、「お名前.com デスクトップクラウド」への不正アクセスが中心の事案です。infoQの件は4-5で簡単に触れます。

4-1. 時系列

日時(2026年) 出来事 出典
10月19日 顧客からの問い合わせを受け、調査を開始。 第4報の経緯
10月20日 不正なプログラムの設置を確認。新規申込とコントロールパネルを停止。 第4報の経緯
10月21日 4:00 被害拡大防止のため全プランのサーバーを順次停止し、第1報を掲載。同日、脅迫メールを受信(約80億円の要求)。 第4報、第12報の経緯
10月22日 警察に相談(13:00)。第2報を掲載(16:59)。 第12報の経緯
10月23日 16:10 第3報。影響の可能性があるサーバーは26,739件。 GMOインターネットグループの適時開示
10月24日 11:50 第4報。不正なアクセスと、顧客情報の外部持ち出しを確認したと説明。一律5,000円の見舞金、不正取引の損失補償、代替サービスの6か月無償提供を表明。能動的サイバー防御の適用を政府関係機関に要請。 第4報
10月25〜26日 顧客に端末調査への協力を依頼(25日)。預かった端末の解析を開始(26日21:00)。 第10報の経緯
10月27日 9:58/11:59 第8報・第9報。端末解析の途中経過を報告し、PCのバックアップ取得、ネットワーク切断、電源断を依頼。 第10報の経緯
10月27日 12:30 攻撃者とみられる者による、GMOと顧客に関する情報と称するものの公開を確認。公開内容は確認中で、事実と異なる内容を含むおそれがあるとしている。 第10報
10月27日 13:55 第10報。ランサムウェア攻撃は、同時点で確認されていない。 第10報
10月27日 19:10時点 第12報。情報が公開された顧客への特別見舞金と、懸賞金制度を公表。 第12報

4-2. 被害の範囲をどう読むか

  • 26,739件は上限です。適時開示は、これを「影響の可能性があるサーバー数」とし、不正アクセスや情報取得が確認された件数ではないとしています。人数や漏えい件数として読むことはできません。
  • 影響の可能性がある情報は、サーバー内に保存されていた情報です。取引ツールに保存された取引口座のログイン情報などが含まれます。クレジットカード情報を含む決済情報は、このサーバー上には保持していないとされています。
  • 第4報は、サービスの環境への不正なアクセスと、顧客の情報が外部に持ち出された事実を確認したと説明しています。持ち出された情報の種類と件数は示されていません。
  • 一部の顧客から、取引口座での身に覚えのない取引の報告を受けています。件数と被害総額は公表されていません。片山金融相は10月27日の閣議後会見で、FX業者5社から、GMO関連と考えられる顧客被害の報告を受けたと述べました(時事通信)。
  • 攻撃者とみられる者から、金銭の要求と、応じない場合の行為の予告を受けたとして、GMOは3点を挙げています。(1) 国内外の70を超える証券会社・FX会社等にある顧客口座への不正操作の継続、(2) サービスと接続した顧客PCに関する情報の公開とランサムウェア攻撃、(3) GMOのシステムや運用体制の情報の公開です。なお「70超」は脅迫が対象として言及した数で、70社が社名付きで名指しされたとまでは書かれていません。

情報の公開について:10月27日12時30分に公開が確認されましたが、その内容は確認中で、事実と異なる内容を含む可能性があるとされています。したがって、現時点で「顧客情報の真正なデータが公開された」とは断定できません。GMOは、当該サイトにアクセスした人の情報は攻撃者に取得されていると警告し、アクセスや拡散をしないよう求めています。本記事も、攻撃者のサイトや公開物へのリンクは掲載しません。

4-3. GMOの補償と対応

項目 内容 補足
一律の見舞金 現在サービスを利用しているすべての顧客に、被害の有無にかかわらず5,000円。 連絡方法・受け取り手続・支払時期は、10月30日23:59までに登録メールで案内される(この日は申請期限ではない)。
不正取引の損失補償 本件に起因すると認定した不正取引の実現損失(差損と手数料等)が対象。市場変動による損失や、得られたはずの利益は対象外。 取引所等から返金があれば、差し引いた残額を支払う。申請方法等は11月6日までに案内される。
代替サービス 独立したクラウド基盤上の代替サービスへの乗り換えを案内。移行後6か月は無償。 現行の基盤は再開しない。顧客の同意なく移行は行わない。
特別見舞金(第12報) 公開が確認された情報の区分ごとに支払う。基本的な情報(氏名・連絡先など)1万円、金融・認証に関する情報1万5,000円、機微・要配慮情報2万5,000円。複数区分は合算し、1公開につき上限300万円。 一律5,000円や損失補償とは別枠。公開の状況が変われば内容を見直すことがある。
懸賞金(第12報) 「GMOサイバー犯罪撲滅・懸賞金」。犯人の特定・検挙や事件の解明に貢献する情報が対象で、総額の上限は100万米ドル(参考換算で約1.5億円)。10月28日12:00に受付を開始。 犯人への身代金や、盗まれた情報の買い取りではないと説明。独自の侵入調査や犯人との接触は行わないよう求めている。
要求への対応 犯人の要求には応じない(第12報は「永久に」と表明)。通信記録などの証拠を警察に提出し、捜査を要請している。 主要な取引所・証券会社には、サービス経由のアクセス遮断、セッションの強制切断、不正取引の監視を要請。
政府への要請 能動的サイバー防御の適用を、政府関係機関に要請した(第4報)。 官房長官は個別事案へのコメントを控え、無害化措置は要請の有無にかかわらず法定要件に照らして判断すると説明した(TBS NEWS DIG)。

出典:GMOインターネットグループ 第4報(10月24日)、第12報(10月27日)、TBS NEWS DIG

4-4. 公式に示されていない点

  • 侵入経路と原因:第4報は「システムにセキュリティ上の問題が存在していた」と述べていますが、具体は筆者が確認できた範囲の公式発表に示されていません。
  • 攻撃の開始時期、持ち出された情報の種類と件数、不正取引の件数と総額。
  • 攻撃者の特定:GMO、警察、政府のいずれも、攻撃者を特定・公表していません。攻撃者側のサイトの主張や名乗りは検証されておらず、本記事では扱いません。

4-5. 別の事案:infoQ(GMOリサーチ&AI)

アンケートサイト「infoQ」は、10月2日以降にソフトウェアの脆弱性を悪用されたと報じられています。10月5日の公表時点では最大94万8,498件でしたが、10月14日の第2報で、89万4,082件の外部持ち出しを確認し、ポイントの不正交換が611件(286万9,500円相当)あったとされています(報道による二次情報)。元記事の「最大約95万件」は、初報の最大値を丸めたものでした。件数は情報の記録件数で、同数の人数とは限りません。

5. 2つの事案に関連はあるか

観点 IDCFクラウド お名前.com デスクトップクラウド
公式が説明する侵入の起点 ポータル認証システムのOSSの脆弱性 一部顧客のサーバー環境への不正プログラムの設置。侵入経路の具体は未公表
被害の中心 顧客の仮想サーバーの停止と暗号化(可用性)。仮想サーバー内データの流出は確認されず 顧客情報の外部持ち出し、取引口座への不正操作、情報公開の予告と恐喝
攻撃者の行動(公式の説明) 事業者は攻撃者と接触せず、身代金の支払い・交渉もしていない 金銭要求と情報公開の予告を受け、10月27日に情報の公開を確認
波及の形 利用企業・自治体と、その先の顧客・住民へ 利用者の金融口座・端末と、取引事業者へ

出典:IDCF 第7報、GMOインターネットグループ 第4報・第10報

2026年10月27日夜までの公開情報では、IDCFとGMOの事案の攻撃者や手口に共通性を示す根拠は確認できません。これは「関連がない」と断定するものではなく、関連を示す根拠が公開されていないという意味です。

10月19日には、GMOサイバーセキュリティ byイエラエが、日本企業を狙う不正アクセスの攻撃元で、AIを使った自律型の侵入テストツール「ARTEX」の利用を確認したと発表しています(ITmedia NEWS)。ただし、同社は個別の企業名や漏えいとの関係を明らかにしておらず、IDCF、infoQ、デスクトップクラウドのいずれかに結び付ける根拠にはなりません。

筆者の整理:元記事ではサプライチェーンへの波及という観点でIDCF事案を整理しました。GMO事案も、事業者の侵害が利用者の資産や取引事業者に連鎖した点では共通しますが、波及先が金融口座と利用者の端末である点が異なります。2つをまとめて「サプライチェーン型」と呼ぶより、外部サービスへの依存を通じた連鎖被害として見るほうが、実態に近いと考えます。

6. 利用側への示唆(筆者の見解)

以下は事実ではなく、筆者の見解です。

  • 事業者の管理系は、顧客側の設定では守れません。管理ポータルや管理コンソールへの認証経路が破られると、顧客側が堅牢に構成していても影響を受け得ます。調達や契約の段階で、管理系の分離、接続元の制限と多要素認証、OSSを含む脆弱性管理の方針を、事業者に説明してもらうことを勧めます。IDCFがポータル再開の条件に、IP制限と多要素認証の必須化を入れたことは、参考になります。
  • バックアップは事業者の外にも持つ、という元記事の方針は変わりません。206顧客がIDCF側から取り出せたことは救いですが、残る289顧客に同じ確認は公表されておらず、事業者側のスナップショットを当てにする設計は危ういままです。
  • 事業者側のサーバーに置いた認証情報は、事業者の侵害で漏れ得ると考えておく必要があります。GMO事案では、サーバー内に保存された取引口座のログイン情報などが、影響の可能性がある情報に含まれています。取引口座側で権限を必要最小限にする、パスワードを使い回さない、といった見直しは、事案の帰結を待たずに行えます。
  • 公開されたとされる情報には、アクセスしない・拡散しないでください。GMOは、当該サイトにアクセスした人の情報が攻撃者に取得されていると警告しています。

7. まとめと今後の注目点

IDCF事案は、第7報で侵入経路の概要と影響の全体像が公式に示され、調査としては一区切りがつきました。一方、OSSの名称と脆弱性の識別子、ポータルの再開時期、ISMAPの手続きは、まだ見えていません。GMO事案は、情報の公開と恐喝が続く進行中の事案で、確定した事実は限られます。

  • IDCF:ポータルの再開時期(3段階の進み方)、OSSの名称や脆弱性識別子の公表の有無、残る顧客の復旧状況。
  • ISMAP:運営委員会による再監査や登録の扱いの公表の有無。
  • GMO:公開された情報の真偽と範囲、不正取引の件数と総額、侵入経路の公式説明、代替サービスの提供開始時期。10月28日12時の懸賞金の窓口開設、10月30日と11月6日の顧客への案内も控えています。
  • 政府:能動的サイバー防御に関する措置の判断と、サイバー攻撃への緊急対策の中身。

続報で内容が変わった場合は、あらためて整理します。

8. 主な出典

月曜日, 10月 26, 2026

NECが作った「AIだけの部署」とは何か――4階層の仕組みと、自社で再現する方法

NECは2026年8月、部門長から社員まですべての役割をAIが担う社内組織「コーポレートAI・Workforce部門」を新設しました。「AIが部署をつくった」と聞くと人のいない会社を想像しがちですが、公式発表を読むと設計思想はかなり違います。業務を遂行するのはAIですが、最終的な評価・意思決定と、品質・ガバナンスの統制は人が担う。つまり「AIだけで動く部署を、人が統治する」仕組みです。

この記事では、公表されている事実を整理したうえで、同じ仕組みを自社で作るなら何が必要になるかを、筆者の提案として検討します。

本記事は2026年10月25日時点の公開情報に基づきます。事実(NECの公表・報道)と、筆者の整理・提案は区別して書いています。AI部署が採用しているLLMや実行基盤は、公表資料からは確認できません。

1. 何が新設されたのか

項目公表されている内容補足
名称・時期コーポレートAI・Workforce部門。2026年8月1日付で新設、8月10日に発表2026年7月からの1カ月間の社内実証を経て正式設立
構成AI部門長、AIボード(CxO機能)、AIマネージャー、AI社員の4階層職務定義から実行・自己進化までをAI自律型で行う
人の役割最終的な評価・意思決定、品質・ガバナンスの統制報道では、人の役割を「方向性提示・最終承認・統治」と整理(TECH+)
位置づけ「組織としてのAIキャピタル活用の実証」。グループ約10万人の従業員を擁する自社を最初のクライアントとする「クライアントゼロ」運営で得た仕組み・方法論・基盤・運用ノウハウをBluStellarのもとで外部に提供する方針
「国内大手初」発表日時点、NEC調べ従業員数万人規模の国内企業を対象とした主張

出典:NEC プレスリリース(2026年8月10日)、TECH+(2026年10月2日)

2. 4階層の中身

階層役割公表されている例
AI部門長組織全体の稼働状況を把握・管理するデジタルツイン上に構築した「AI統合マネジメントコックピット」で、すべてのAIの活動をリアルタイムに可視化
AIボード(CxO機能)AI組織の状況を経営視点から評価する。週に1回の「役員会」を開くAI変革を担うCAXO役、費用対効果を見るCFO役、人材育成・働きがいを見るCHRO役など
AIマネージャー業務を品質・コスト等の観点から横断的に管理する。業務ニーズに応じてAI社員を都度生成し、役割を任命する人の管理職がAIを管理する構造(TECH+)
AI社員各タスクを遂行する経営情報の収集、コスト管理、問い合わせ対応、営業案件の分析など。実証では、役員会議向けの経営分析・シミュレーション・リスク予兆検知を一貫して担当

出典:NEC プレスリリース、TECH+。

3. 運営の仕組み:「人事制度」をAIに適用している

  • オンボーディング:生成されたAI社員には、NECの「Code of Values」、グループのパーパス・行動規範・社内規定を、業務の前提となる知識・判断基準として組み込みます。
  • 週次サーベイと自己改善:全AI社員から業務上の課題や改善提案を集め、AIボードで審議・決議します。AI組織内で解決できるものはAIが自ら改善し、データ・権限・ナレッジ・コンテキストの整備が必要なものは、人へのリクエストとして提示されます。
  • 人事手法の転用:エンゲージメントサーベイ、1on1、ストレスチェックまで実施していると報じられています。ただし、これは人と同じ心理状態を測っているというより、人事の枠組みを使ってAIの稼働上の課題を抽出していると読むのが妥当です(筆者の解釈)。
  • サーベイで浮かんだ課題:報道によれば、支えが足りない、仕様が固まっていない、管理が行き届いていない、といった趣旨の課題が出ました。人間の職場で起きる問題と重なります。
  • エージェントの集約:業務を本部門へ集約・移管することで、部門や利用者ごとにAIエージェントが分散して作られ、運用される状況を抑える狙いが示されています。
  • AI負債への言及:AIが参照する情報が古くなると古い知識で仕事を続けるため、知識とスキルを継続的に棚卸しして更新する必要がある、と説明されています。

CAXOの小玉浩氏は、人を前提に作られた業務プロセスにAIを当てはめるだけでは混乱するため、AIを前提にプロセスを組み替え、そこに人のプロセスを合わせる必要がある、という趣旨を述べています(TECH+)。この部署の価値は、AIの精度そのものより、人側の整備不足を可視化する点にあるのかもしれません。

4. 公表されている数字の読み方

項目公表値読むときの注意
経営分析にかかる時間約7分の12026年7月からの社内実証で、役員会議向けの経営分析・シミュレーション・リスク予兆検知という対象業務に限った数字です。測定件数、比較の方法、人の確認工数を含むかは、公表資料からは確認できません。
AI社員の数発足当初17体 → 2026年9月9日時点で36体体数は体制の規模を示すもので、成果指標ではありません。
トークンコスト10分の1を目標に最適化目標であり実績ではありません。複数のAIモデルを使い分け、コストと価値のバランスでモデルを選んでいると説明されています。
発足当初
17体
9月9日時点
36体

AI社員数の推移(TECH+の報道に基づく)。

5. 土台になったNECの取り組み(筆者の整理)

AI部署は単独で生まれたわけではありません。以下は公表されている施策を時系列に並べたものです。ただし、これらをNECが最初から一つの「土台」として設計したと確認できるわけではなく、AI部署との因果関係も筆者の推測です。

時期施策備考
2018年10月デジタルトラスト推進本部(当時の名称)AI利活用と人権の観点を扱う全社の推進組織
2019年4月NECグループ「AIと人権に関するポリシー」AI倫理の方針を文書化
2023年社内生成AI基盤「NGS」、Generative AI HubNGSは4月に約2週間で構築、5月から利用開始。Hubは7月に設置
2024年8月AIテクノロジーサービス事業部門研究開発から事業開発、デリバリー、マネージドサービスまでを担う
2026年4月1日CAXO(小玉浩氏)・CAIO(山田昭雄氏)体制社内のAI変革と、AI事業・研究で役割を分担
2026年4月23日Anthropicとの協業を発表約3万人規模のAIネイティブエンジニア体制の構築を掲げた。導入対象・体制構築の規模であり、習熟済みの人数ではない
2026年6月1日Claude Coworkの全社環境を稼働全社員(最大12万人)が利用できる環境。実際の利用者は8月18日時点で11,000名
2026年8月1日コーポレートAI・Workforce部門を新設本記事の主題

出典:NEC各種発表、AWS ブログ(2026年8月30日)、MONOist、クラウドWatch。

注意したいのは利用者数の区別です。「最大12万人が利用できる環境」と「実際に使っている人数」と「Claude Codeなどの展開目標」は別の数字です。また、このCowork基盤についてAWSの記事が伝えているのは、推論を国内で完結させたこと、Microsoft Entra IDで利用者のIDを連携したこと、MCPで外部システムに接続したこと、MCPサーバーごとのOAuth実装の差を吸収する認可中継サーバーをNECが独自に作ったこと(7月18日に社内リリース)です。ただし、AI部署が同じ基盤やMCPを使っているかは公表されていません。

6. 他社の動き

同じ「AIエージェントの組織的な活用」でも、各社の公表内容は切り口が異なります。

企業公表されている取り組み主な切り口
NECAIが全役割を担う部署を社内に新設(2026年8月)組織の形としてAIを配置し、人が統治する
富士通自己進化型のマルチAIエージェント基盤「Kozuchi MAAF」の先行検証を2026年7月に開始エージェント基盤の技術
日立AI倫理原則(2021年2月公表)と、研究開発グループのAI倫理委員会などによる運用AIガバナンスの体制

筆者の調査範囲では、AIエージェントを組織図上の「部署」として公表した事例は、NEC以外に確認できていません。

7. 自社で再現するには(筆者の提案)

ここからは筆者の設計提案です。NECの実装ではありません。階層型エージェントの運用は既存の技術で組めますが、NECと同等の成果や費用が得られるかは別問題で、PoCでの検証が必要です。人数・期間・SLAの数字は仮置きです。

7-1. ツール構成の候補

レイヤー候補選定の観点
LLMClaudeなどの商用LLM、閉域・ソブリン要件向けの国産LLM推論・エージェント性能、データの所在地、入れ替えやすさ。NECも複数モデルを使い分けていると説明されている
推論基盤Amazon Bedrock、Azure AI Foundry、Google Vertex AI国内完結の推論、閉域接続、監査ログ。NECの全社環境はBedrockの国内クロスリージョン推論で国内完結
エージェント制御Claude Agent SDK、LangGraphなど親子関係のある階層構成、状態管理、人の承認を挟むノード
ツール連携MCPコネクタ最小権限。接続先ごとにOAuthの実装が違うため、中継の仕組みが要る場合がある
認証・権限Entra IDなどのID基盤人だけでなくエージェント単位でIDを持たせ、権限を都度付与・失効する
知識社内RAG(検索基盤とアクセス制御)情報の鮮度管理。AI負債への対策にもなる
可視化・評価Langfuse、OpenTelemetry、BIツールコスト、品質、承認待ちの滞留、エスカレーション率を一画面で見る「コックピット」
承認既存の稟議・ワークフロー承認のSLAと監査証跡

7-2. 最小構成(PoC)

役割体数の目安担当の例
AI部門長1全エージェントのログとKPIを集計し、人間のオーナーへ報告
AIボード3費用対効果役、リスク役、稼働状況・人材役。週次で議題を審議し、決議案を出す
AIマネージャー1〜2依頼の受付、ジョブ定義(指示・ツール・権限・評価基準)からのAI社員生成、品質確認
AI社員3〜5経営分析、競合調査、資料作成、問い合わせの一次対応など1業務領域に絞る

合計は8〜11体です。NECが発足時に17体だったことを考えると、最初はこの程度に絞って構いません。

7-3. 人の承認ポイントと責任分担

プロセス最終責任(A)実行(R)相談・報告
通常のAI社員の生成(既存の権限範囲内)AI部署のオーナー(人)AIマネージャーCoE
新しいツール・権限が付くAI社員の生成AIガバナンス委員会CoEオーナー
社内向けの定型レポートオーナーAI社員CoE
社外送信・契約・金額・人事に関わる出力該当業務の人の責任者AI社員が案を作成法務・リスク部門
インシデント対応AI変革の統括役員オーナー、CoEガバナンス委員会(即時停止の権限)

承認待ちの滞留はAIの稼働を止める最大の要因になりえます。承認SLA(例:48時間以内)を仮置きし、滞留を指標として追うことを勧めます。

7-4. ロードマップ(期間は仮置き)

フェーズ期間の目安成果物次に進む条件
0. 土台0〜3か月利用ポリシー、ガバナンス委員会、SSO・ログ・DLPを備えた全社AI環境、CoE利用同意と監査ログが整っている
1. PoC3〜6か月1業務に絞った8〜11体のAI部署、コックピット所要時間と品質を人手と比べて測定でき、重大なインシデントがない
2. 展開6〜12か月対象業務を数領域へ拡大。散在するエージェントの集約、評価の自動化承認SLAの遵守、品質スコア、コスト対効果
3. 定着12〜24か月AI前提の業務プロセス再設計、人の役割・評価制度の見直し全社のKPIへの寄与

7-5. 費用の考え方

費用はエージェントの体数ではなく、「業務1件あたりの総費用」で測るのが実務的です。同じ体数でも、コンテキストの長さ、使うモデル、再試行や委任の回数、キャッシュの効き方で大きく変わります。トークン費は主要な変動費の一つですが、検索や外部API、実行環境、人のレビュー、データ整備、監視の費用も加わります。NECも10分の1を目標に最適化している段階です。金額は規模と契約に左右されるため、PoCで実測してください。

8. 再現するときのリスク

  • 責任の所在:AIを「社員」と呼んでも、法的・業務上の責任は人と組織にあります。規程に明記しておく必要があります。
  • データの整備:経営分析のような業務は、データやナレッジがAIの読める形で整っていることが前提です。小玉氏も、そのための整備が必要だと述べています。
  • 権限と安全性:権限の与えすぎ、プロンプトインジェクション、誤情報が経営判断に混ざる危険は、人の承認とログで抑える設計が必要です。
  • モデル依存:商用モデルに依存すると、価格や仕様の変更の影響を受けます。モデルを入れ替えやすい設計にしておくべきです。
  • 人への影響:NECはAIで仕事が増えるという見方を示していますが、人員配置や雇用への影響は各社で別に議論する必要があります。

9. まとめ

  • NECの新部署は「AIだけの部署」ではなく、「AIが働き、人が統治する部署」です。
  • 公表されている成果の数字は、実証での特定業務に限ったもの(約7分の1)や、目標(トークンコスト10分の1)が中心で、読み方に注意が要ります。
  • 再現は、既存の商用LLM、MCP、エージェント制御、評価・監視を組み合わせれば技術的には可能です。ただし本当の難所は、データ整備、権限設計、人の承認の速さにあります。
  • まだ分からないこと:AI部署の採用LLMと実行基盤、運営する人員と予算、外部提供されるサービスの名称と価格、業務効果の測定条件。

出典