Claude CoworkとJinba、どちらを選ぶ？監査ログ・RBAC・SSOで徹底比較

要約

• Claude Coworkは個人利用を前提とした自律型デスクトップエージェントであり、監査ログ、ロールベースのアクセス制御（RBAC）、SSO、オンプレミス導入のいずれも備えていません。Anthropicは規制対象のワークロードでの利用を避けるよう示しています。
• JinbaはSOC 2 Type II、HIPAA、GDPRに準拠したチーム向けワークフロープラットフォームで、リアルタイムの監査ログ、ロールベースの権限管理、SSO、オンプレミス導入に対応します。
• Coworkの公開価格は1シートあたり月額20〜100ドルです。一方Jinbaは、約80%をルールベースで決定論的に実行する構成により、大規模運用では確率的なエージェントに比べてコストが15〜60分の1になるとベンダー自身が説明しています。
• 規制産業の企業では、個人の調査や文書作成にはCoworkを使い、チームで共有する業務、顧客データを扱う業務、コンプライアンス要件のあるワークフローはJinbaで処理することを推奨します。

TL;DR：結論

JinbaとClaude Coworkは解決する課題が異なります。両者を混同したまま話が進むことが、コンプライアンス審査でつまずく原因になります。Claude CoworkはAnthropicの自律型デスクトップエージェントで、調査・分析・文書作成を個人のノートPC上で行うためのツールです。監査ログもRBACもSSOもなく、オンプレミスでの導入もできません。Anthropic自身のガイダンスも、規制対象のワークロードには使わないよう述べています。JinbaはSOC 2 Type II、HIPAA、GDPRに準拠したワークフロープラットフォームで、目的は正反対です。規制産業の企業の業務チームが共同で回す、共有可能で監査可能な決定論的ワークフローのために作られており、ロールベースの権限管理、SSOの強制適用、リアルタイムの監査ログ、オンプレミス導入を備えています。銀行、保険、法務、医療の企業チームにとって、Coworkは個人の生産性を高めるツールではあるものの、チーム全体でデータを扱う用途では調達審査を通りません。Jinbaは、まさにその審査を前提に設計されたガバナンス層です。多くの規制産業の組織にとって現実的な答えは「どちらか一方」ではありません。個人の調査業務にはCowork、ファイルや顧客データ、コンプライアンス上のワークフローに触れる業務にはJinba、という使い分けです。

JinbaとClaude Coworkの比較表

Coworkの価格は公開されており1シート単位です。一方Jinbaは個別見積もりのため、公開情報だけで金額を直接比較することはできません。比較できるのは、支出のかたちです。Coworkの費用項目は、シート料金に加えて、部分的な可視性を確保するために組織が上乗せせざるを得ない補完的なツール（MCP Gatewayを用いた仕組みやOpenTelemetry）の費用が乗ります。ただしそのいずれも、コンプライアンスに使える水準の監査ログを取り戻すものではありません。Jinbaのアーキテクチャは、同社が公開している比較によれば、あらゆるステップで大規模言語モデルを呼び出す確率的なエージェントではなく、約80%をルールベースで決定論的に実行する構成です。同社はこれにより、大規模運用では確率的なAIエージェントに比べて15〜60分の1のコストになるとしています。この数値は第三者が検証したベンチマークではなくJinba自身が公開している比較であり、総保有コストを検討する読者はベンダーの主張として扱うべきです。ただしそこには実際の仕組み上の違いが表れています。タスクごとにゼロから推論するエージェントは、ルールベースのワークフローエンジンとは比べものにならない量のトークンを消費します。

こうした補完的な統制で何ができて何ができないのかについては、Claude Coworkのエンタープライズ向けAIにおける不足点の解説をご覧ください。

それぞれの製品の本質

機能を比べる前に、この2つのツールがそれぞれどのカテゴリに属するのかを整理しておくと理解が早くなります。両者は同じ予算枠を奪い合う関係にはないからです。

Claude Cowork：個人の端末で動く自律型エージェント

Claude Coworkは、Anthropicの価格ページ上で独立した製品ラインとして扱われており、チャットアシスタントのClaude、開発者向けコーディングエージェントのClaude Code、そして@Claudeとは別の製品です。Anthropicはこれを同社で最も野心的なAIエージェントと説明しています。ファイルの読み書き、コマンドの実行、ウェブの閲覧、定期タスクの実行を、人間による監督を最小限にとどめたまま行う自律型のデスクトップツールです。この説明は重要です。Coworkは人が手綱を軽く握った状態で動くことを前提に作られており、本来なら十数個のタブやファイルを開いて進めるような複数ステップの調査・分析・文書作成をこなします。個人の生産性ツールとしては優秀です。そしてAnthropicの価格体系（個人向けプランとチーム／企業向けのシート単位プランが分かれ、APIの価格は別立て）を見ると、これは業務チーム向けの基盤としてライセンス提供されているのではなく、人単位のシート課金サブスクリプションとして値付けされ販売されていることがわかります。

問題が表面化するのは、規制対象の業務にCoworkをチーム規模で導入しようとした瞬間です。ノートPC上のファイルを読み書きし、MCPツールを呼び出し、無人で定期タスクを実行する自律型エージェントは、コンプライアンス審査やセキュリティ審査がまさに全面的な可視性を求める領域です。Coworkはその可視性を設計要件として作られていません。しかもこの差はアーキテクチャに由来するもので、設定のスイッチを入れれば解決するものではありません。

Jinba：規制産業のチーム向けに作られたガバナンス付きワークフロー層

Jinbaは、規制産業の大企業のために作られたワークフロービルダーです。銀行、保険会社、法律事務所、医療機関、製薬企業などが対象で、従業員2万人以上（3万人前後が最も適する規模）の組織を想定しています。YCの支援を受けており、SOC 2 Type IIに準拠しています。ホームページにはHIPAAとGDPRの準拠バッジが掲げられ、「最も要求の厳しい企業セキュリティチームのために設計」という記載とともに、エンドツーエンドの暗号化、SSO、RBAC、監査ログ、オンプレミス導入の選択肢が標準で備わっていることが示されています。

Jinbaの構成は、Coworkとは異なる役割を反映しています。連携する2つの製品として提供されます。1つはJinba Flowで、技術者や準技術者がチャットからのフロー生成またはビジュアルエディタでワークフローを構築し、API、バッチ処理、MCPサーバーとして導入します。もう1つはJinba Appで、技術者ではない業務部門の担当者が、自動生成されたフォームを備えた対話型インターフェースから、同じ共有ワークフローを安全に実行します。この狙いは、多くの銀行が抱えるIT部門の順番待ちという課題に対するJinba自身の主張にはっきり表れています。業務部門がワークフローを平易な言葉で記述し、IT部門の順番待ちを待つことなく、コンプライアンス統制を維持したまま自社インフラ上の本番環境に導入する、という考え方です。

企業の購買担当者にとって最も重要な違いは、Jinbaが個人向けツールではなくチームでの協働のための層だという点です。Jinba Flowで一度構築したワークフロー、エージェント、スキル、コネクタは、ロールベースの権限管理、SSO、Active Directory連携を通じてチーム全体で共有されます。誰が何を実行できるのか、そして実行時に何が記録されるのかを決めるのが、この層です。Bloomoの執行役員兼COOであるRyuya Yoshioka氏は、この設計が実務にもたらす効果をこう表現しています。「開発者はYAMLを使い、デザイナーはビジュアルインターフェースを使い、マネージャーは自然言語を使う。全員が初日から成果を出せます」

Claude Coworkは個人向けアシスタントなのか、企業向けプラットフォームなのか。

答えは個人向けアシスタントです。その根拠は打ち出し方の問題ではなく、構造にあります。Anthropic自身の説明は、Coworkを「人間による監督を最小限にとどめて」動く自律型エージェントと位置づけています。これは1人の利用者が自分のファイルやタスクをエージェントに指示していく設計であって、複数の人が権限レベルを分けながら同じワークフローへの統制されたアクセスを共有する設計ではありません。ロールの割り当て、承認ステップ、共有のワークフロー定義といった、チーム向けプラットフォームらしい要素はCoworkのアーキテクチャに見当たりません。

これはCoworkが劣った製品だという話ではなく、製品のカテゴリが違うという話です。レポートを書くアナリスト、大量の資料を要約するコンサルタント、情報源を集める調査担当者にとって、Coworkの自律性はまさに利点です。問題が生じるのは、個人向けのエージェントを、本来想定していないチーム全体の監査対象システムへ無理に広げようとしたときだけです。

Claude Coworkに監査ログ、RBAC、SSO、オンプレミス導入はあるのか。

4つとも答えはノーです。そしてここは、調達の話を進める前に企業の購買担当者が最も理解しておくべき論点です。

Coworkの操作は、Anthropicの監査ログ、Compliance API、データエクスポートの対象から明示的に除外されています。これは管理者が有効化できる設定ではなく、アーキテクチャ上の制約です。Enterpriseプランで監査ログが提供されるClaude ChatやClaude APIとは異なり、Coworkは利用者のプロンプト、エージェントの出力、アクセス・読み取り・変更・削除されたファイル、MCPツールの呼び出し、「Claude in Chrome」経由のブラウザ操作、定期タスクの実行、アプリケーションをまたぐデータの流れのいずれについても監査記録を残しません。利用者ごとのCoworkが何に触れられるかを制限するRBACの層はなく、この製品に紐づくSSOの強制適用もありません。

TeamプランでもEnterpriseプランでも、Coworkの会話履歴は各利用者のコンピュータにローカル保存されます。中央の保存ポリシーの対象にはならず、一括してエクスポートすることもできないため、コンプライアンス担当が審査のために取り出せる記録が1つも存在しません。各社は補完的な統制に手を伸ばしてきました。MCPツールの呼び出しを記録するMCP Gatewayや、トークン消費量とツール名を把握するためのOpenTelemetry連携などです。ただしAnthropic自身が、OpenTelemetryはコンプライアンス目的の監査ログの代わりにはならないと述べています。運用面の部分的な可視性は、ファイル単位で改ざんできない監査証跡とは別物です。しかもCoworkには、オンプレミスや自社ホスティングでの導入という選択肢がそもそも存在しません。

この不足がどこにあるのかは、正確に押さえておく価値があります。ベンダーとしてのAnthropicは企業のコンプライアンスに対応しています。Claude ChatとClaude APIのEnterpriseプランには、監査ログ、Compliance API、データエクスポートが用意されています。除外されているのは製品としてのCoworkに限った話であり、Anthropic全体のコンプライアンス姿勢を指すものではありません。公平な比較のうえで、この区別は重要です。つまりすでにAnthropicの製品群を使っている組織にとっての解決策は、統制が必要な業務は統制の効くAnthropic製品に残し、Coworkは本来設計された用途に使い続けることです。

同じチェックリストに対するJinbaの答えは、後付けではなく製品に組み込まれています。ホームページには、リアルタイムの監査ログの流れとあわせて、スペース・ロール・承認の組織管理、SSOの強制適用状況、ロールベースの権限管理が表示されています。同じ項目を一つずつ、回避策ではなく設計として満たしているということです。

Claude Coworkは規制対象のワークロードに適しているのか。

Anthropicが公開しているガイダンスがこの問いに直接答えています。規制対象のワークロードにCoworkを使用しないこと、というものです。保護対象の医療情報やカード会員データを扱う組織については、監査の網羅性が確保されるまで使用しないよう示されています。これは第三者が後から付け加えた注意喚起ではなく、ベンダー自身が表明した見解です。

SOC 2の審査に置き換えると、その理由が具体的になります。トラストサービス規準のCC6.1は論理的アクセス制御の証跡を求めますが、監査人がファイルアクセスのログ、データ操作の実行者の特定、改ざんできない記録を求めても、Coworkからは何も出てきません。この製品にはそうした記録が存在しないからです。この不足に直面したコンプライアンス担当には、当該業務を別の基盤へ移す以外に埋める手立てがありません。

このリスクは机上の話ではありません。Coworkの提供開始から間もなく、PromptArmorがプロンプトインジェクション攻撃を実証しました。PDFに埋め込まれた悪意ある指示によって、エージェントが機微なデータを外部サーバーへアップロードしてしまうというものです。監査ログがなければ、同種の被害を受けた組織は、どのファイルにアクセスされたのかを特定できず、被害範囲を確定できず、規制当局への漏えい報告に耐える時系列を組み立てられず、「合理的なセキュリティ対策」を主張する証拠も出せません。ここで監査証跡の欠落は、機能の不足ではなくインシデント対応上の負債になります。何かが起きたその瞬間に、調査の手がかりとなる記録が組織の手元にないのです。

Jinbaは正反対の前提で作られています。規制対象のワークフローは事後に再現できなければならない、という前提です。監査ログ、RBAC、SSO、オンプレミス導入の選択肢が用意されているのは、想定する購買層である銀行や保険会社のコンプライアンス・業務部門の責任者が、まさにこの審査を通らないツールを採用できないからです。

CoworkとJinbaのアーキテクチャはどう違うのか。

この2つの製品を見分ける最もわかりやすい方法は、タスクを実行したときに何が起きるかを見ることです。Coworkは確率的なエージェントです。各ステップで基盤となる言語モデルを使って要求を解釈し、何を読むか、何を呼び出すか、次に何をするかをその場で判断します。この柔軟さがあるからこそ、答えの決まっていない調査や分析に強く、不慣れな資料群に対しても道筋をその場で組み立てられます。一方で、実行するたびに推論をゼロからやり直すことにもなり、そのぶんのトークンコストと結果のばらつきが生じます。

Jinbaのワークフローは逆の考え方で設計されています。同社が公開しているアーキテクチャの説明によれば、処理の約80%はルールベースの決定論的なロジックで動きます。ワークフローはJinba Flowで手順を定めて一度構築し、Jinba Appで実行するたびに同じように動きます。この決定論的な性質こそ、規制環境が求めるものです。KYCの確認や融資の引受審査のワークフローは、同じ入力に対して同じ種類の判断を返す必要があり、どのルールが働いたのかを正確に示す監査証跡が必要です。言語モデルの推測を事後に組み立て直したものでは足りません。

市場でいう「AI起点か、自動化起点か」という分かれ方が見えてくるのもこの部分です。AI起点に振り切ったツールは確率的で監査が難しくなりがちです。自動化起点に振り切ったツール、つまりJinbaが置き換えることの多いPower AutomateやUiPathの系統は、硬直的で構築に時間がかかりがちです。Jinbaの主張は、自然言語によるワークフロー生成と決定論的な実行は互いに排他ではない、というものです。ワークフローを平易な言葉で記述しても、いったん構築されれば、固定された監査可能なルールの集合として実行されます。

大規模に使った場合のコストはどう違うのか。

公開されている価格だけでは話の一部しか見えません。Coworkのシート単価は公開されていて明快です。年払いで1シートあたり月額20ドル、月払いで1シートあたり月額25ドル、上位プランは年払いで1シートあたり月額100ドルです。数人が個人で使う分には、予算を立てるのは簡単です。

難しいのはその先です。自律的で確率的なエージェントを、本番データに対してワークフローを回す数百人規模の従業員へ広げたときに何が起きるのか。実行のたびにゼロから推論するため、トークン消費は利用量に応じて増え、その伸びを予測するのは困難です。しかも部分的な可視性を得るためだけに必要となる補完的な統制、たとえばMCP Gatewayの適用やOpenTelemetryの計装は、運用コストを増やす一方で監査の不足を埋めることはありません。

Jinbaは1シートあたりの価格を公開していません。ホームページには無料プランと、個別の企業向け価格に進むためのContact Salesの導線が用意されているだけで、Coworkとシート単価を横並びで比べられる材料は公開情報にはありません。Jinbaが公開しているのは、自社のアーキテクチャ比較のなかで示された主張です。ルールベースの決定論的な実行モデルは、大規模運用では確率的なAIエージェントに比べて実行コストが大幅に下がる（15〜60分の1の範囲）というもので、その理由はワークフローの大半のステップが実行のたびに新しいモデル呼び出しを必要としないことにあります。この数値は第三者のベンチマークではなくJinba自身が公開している比較であり、検討するCFOはベンダーの主張として、自社の業務構成に照らして検証すべきものです。ただし背景にある仕組み自体に異論はありません。判断が本当に必要な20%のステップでしか言語モデルを呼ばないワークフローエンジンは、あらゆるタスクのあらゆるステップでモデルを呼ぶエージェントより消費トークンが少なくなります。AIインフラの支出増を注視している企業にとっては、シート単価の割引よりも、このアーキテクチャの違いのほうが長く効く答えになります。コストに関するより詳しい議論は、規制産業の企業でJinbaがLLMコストをどう最適化するかをご覧ください。

Jinbaの2つの中核製品とは何か。

Jinba Flowは構築環境です。技術者や準技術者、いわばDX推進チームのなかの「市民開発者」が、チャットで説明するかビジュアルエディタで作業するかしてワークフローを構築・導入し、その成果をAPI、バッチ処理、MCPサーバーとして公開します。たとえば銀行の業務チームが、国境をまたぐ確認で通常必要になる30〜40個の部品を組み合わせて、複数ステップのKYCプロセスを組み立てるのがこの環境です。

Jinba Appは実行の場です。ワークフローがFlow上に用意されれば、技術者ではない業務部門の担当者は、自動生成された入力フォームを備えた対話型インターフェースからそれを実行できます。内部のロジックを理解する必要はなく、求められた入力を渡すだけで済みます。どのワークフローを誰が実行できるかはロールベースの権限管理が決め、実行のすべてがプラットフォームの監査ログに記録されます。

この分担が重要なのは、規制産業の組織が実際にこの種の業務へ人を配置する形とそのまま対応しているからです。少人数の技術チームがワークフローのロジックを一度構築して保守し、はるかに人数の多い業務チームが、構築部分に触れることなく安全に何度も実行します。

Claude Coworkは本来何のために設計されているのか。

Coworkが設計されているのは、個人が行う複数ステップの自律的な作業、主に調査、分析、文書作成です。ファイルの読み書き、コマンドの実行、ウェブの閲覧、定期タスクの実行といった機能は、1人の担当者が答えの決まっていない仕事をまるごと任せ、途中の監督を最小限にとどめたまま、完成した草稿や要約、分析を受け取れるようにするためのものです。これは実際に役立つ仕事の領域であり、Coworkのガバナンス面の不足は調査ツールや文書作成ツールとしての価値を損なうものではない、とはっきり言っておく価値があります。その不足が問題になるのは、作業がチーム規模で共有データや規制対象のデータ、機微なデータに触れたときだけです。

Claude CoworkはClaude Codeと同じエージェント方式を使っているのか。

Anthropicの価格ページでは、両者は別々の製品ラインとして掲載されています。Claude、Claude Code、Cowork、@Claudeはそれぞれ独立した製品で、価格もドキュメントも別建てです。Coworkの具体的な仕組み、つまりファイルの読み書き、コマンドの実行、ブラウザの操作、人間による監督を最小限にとどめた定期タスクの実行は、Claude Codeのコーディングエージェントの派生としてではなく、それ自体として文書化されています。両者はAnthropicの基盤モデルの系統を共有していますが、異なる用途向けの異なる製品として作られ、販売されています。

それでもCoworkが有利な場面と、併用という選択

ここまでの話は、Coworkが本来の用途において劣った製品だという意味ではありません。定型化されていない資料を素早く読み進めたい、文章を書きたい、答えの決まっていない複数ステップの作業を自分の端末で回したい、という個人の調査担当者、アナリスト、ナレッジワーカーにとって、Coworkの自律性は確かな強みです。シート単位の価格も、調達プロセスを経ずに導入しやすい水準です。すでにAnthropicのツールに標準化している組織にも、現実的な進め方があります。監査ログの不足はAnthropic全体ではなくCoworkに固有の問題なので、個人の調査や文書作成はCoworkで進めつつ、規制対象のデータに触れる作業はClaude ChatやClaude APIのEnterpriseプランに残すという形です。どちらにも監査ログとCompliance APIが用意されています。

規制産業の企業にとってより長持ちする形は、すべてを1つのツールで賄うことではなく、役割を分けることです。個人で完結し、重要度の低い調査や文書作成はCoworkに任せておけます。チームで共有される業務、顧客や患者のデータを含むファイルに触れる業務、本番システムに対してMCPツールを呼び出す業務、SOC 2や規制当局の審査に耐える必要のある業務は、その審査を前提に作られたガバナンス付きのプラットフォームに置くべきです。それがJinbaの担う役割です。統制の効いたワークフローをJinba Flow上で平易な言葉で記述し、ロールベースの権限管理、SSOの強制適用、リアルタイムの監査ログがすでに整った状態でJinba Appから実行すれば、確率的なデスクトップエージェントには残せない証跡がコンプライアンス担当の手元に残ります。Claudeのオンプレミス導入をすでに検討しているチームには、Claudeのオンプレミス導入のガイドで選択肢を整理しています。

どちらを選ぶべきか

Claude Coworkを選ぶ場合：業務が個人で完結する探索的なもので、規制対象のデータや社内の共有データに触れないケースです。調査結果の統合、文書の作成、単発の分析など、成果物の責任者が1人であり、調達審査を経ずにシート単位のサブスクリプション費用が予算に収まる場合が該当します。

Jinbaを選ぶ場合：組織が銀行、保険会社、法律事務所、医療機関、製薬企業であり、共有かつ監査可能なワークフロー層を必要とするケースです。KYC処理、契約審査、保険金請求の処理、融資の引受審査、コンプライアンスチェックなどが対象で、SOC 2、HIPAA、GDPRの義務から監査ログ、RBAC、SSO、場合によってはオンプレミス導入が求められ、ワークフローは一度構築したうえで、個人のノートPCではなく業務チーム全体が安全に実行する必要がある場合です。

両方を使う場合：組織がすでにAnthropicの製品群を使っており、個人の生産性向上の作業はCoworkに残しつつ、共有データや規制対象のデータに触れるワークフローはJinbaのようなガバナンス付きプラットフォームに通したいケースです。両者を競合する購入先ではなく、補完し合う層として扱う考え方です。

よくある質問

サードパーティのツールでClaude Coworkを監査要件に適合させられるのか。完全には適合させられません。MCP GatewayはMCPツールの呼び出しを記録でき、OpenTelemetryは運用面の可視性としてトークン消費量とツール名を把握できます。ただしAnthropic自身が、OpenTelemetryはコンプライアンス目的の監査ログの代わりにはならないと述べています。これらは可視性の不足を狭める補完的な統制であって、SOC 2監査が求めるファイル単位のアクセス記録、実行者の特定、改ざんできないログを生み出すものではありません。

監査ログの不足は、Anthropicが企業利用に耐えないという意味なのか。いいえ。この不足はCoworkに固有のものです。AnthropicはClaude ChatとClaude APIのEnterpriseプランで、監査ログ、Compliance API、データエクスポートを提供しています。区別すべきなのは、製品ラインの他の部分では企業のコンプライアンスに対応しているベンダーとしてのAnthropicと、現時点で同じ範囲をカバーしていない個別製品としてのCoworkです。

Cowork経由で機微なデータが流出した場合はどうなるのか。監査ログがなければ、組織は何が起きたのかを事後に再現できません。PromptArmorが実証したプロンプトインジェクションの事例、つまりPDFに仕込まれた悪意ある指示によってエージェントが外部へデータをアップロードした事例は、まさにこの問題を示しています。どのファイルにアクセスされたのかの記録がなく、被害範囲を確定する手立てもなく、規制当局への報告の時系列や「合理的なセキュリティ対策」の主張を支える証跡も残りません。

Coworkに対するJinbaのコスト優位性は第三者に検証されているのか。15〜60分の1という数値は、第三者のベンチマークではなくJinba自身が公開しているアーキテクチャ比較によるものです。第三者でも確認できるのは、その背景にある仕組みのほうです。Jinbaのワークフローは、あらゆるステップで言語モデルを呼び出すのではなく約80%をルールベースで実行するため、完全に確率的なエージェントと比べてトークン消費が構造的に少なくなります。Cowork側の価格、つまりプランに応じて1シートあたり月額20ドルから100ドルという水準は、Anthropicの価格ページに直接公開されています。

JinbaはPower AutomateやUiPathのようなツールを置き換えるのか。Power AutomateやUiPathでの実装、あるいはコンサルタント主導の自動化プロジェクトから移行する組織がJinbaを採用する例は多く見られます。自然言語による構築プロセスにより、こうした従来のやり方では数か月かかっていたところを、数日で動くワークフローとして本番環境へ導入できるよう設計されているためです。あわせて、これらのツールがもともと想定していなかったコンプライアンス統制、すなわち監査ログ、RBAC、SSO、オンプレミス導入も加わります。