Claude Codeの料金は？法人プランの選び方と費用対効果の考え方

「Claude Codeを全社に入れたい。で、いくらかかるの？」

導入のご相談で、最初に必ず聞かれる質問です。そして、この質問にすぐ答えられないことが、稟議が止まるいちばんの理由になっています。

理由ははっきりしています。Claude Codeの料金は「1人あたり月いくら」の一枚岩ではないからです。同じ「Claude Codeを使う」でも、個人プランで使うのか、法人のTeamプランで使うのか、API経由で使うのかで、金額の決まり方そのものが変わります。さらに、使う人によって消費量が10倍違います。営業部の担当者が月に数回メールの下書きに使うのと、情シスが毎日スクリプトを書かせるのとでは、同じ「1ライセンス」でも中身がまったく違います。

この記事では、公式が出している数字だけを使って、法人としての費用の全体像を整理します。そのうえで、当社が導入支援と自社運用の両方で見てきた「実際にどこで金額がぶれるか」「決裁者に何を聞かれるか」を足します。金額表は他社の記事にもありますが、「誰にどのプランを割り当てるか」「膨らんだときにどう止めるか」「効果をどう社内で説明するか」まで書いてある記事はほとんど見当たりません。そこが本題です。

本記事に出てくる料金・使用量の数値は、Anthropicの公式ページ（claude.com/pricing）および公式ドキュメント（Claude Code「Manage costs effectively」）に掲載されている内容を、2026年8月12日時点で確認したものです。表示どおり米ドルで記載し、日本円への換算は行っていません（為替で変動するため、稟議書には起案日のレートを自社で当ててください）。いずれも税別で、価格は変更される場合があります。申し込み前に必ず公式ページで最新の金額をご確認ください。助成金に関する記述は厚生労働省の制度を前提としており、要件・率・期限は改正されます。最新の要件は所轄の労働局・ハローワークでご確認ください。

先に結論：法人の料金は「3つの入口」で決まる

先に全体像です。Claude Codeを会社で使うとき、費用のかかり方は3つのどれかになります。

1. 個人向けプラン（Free・Pro・Max）……1人が自分のアカウントで契約する。定額。使用量には上限（枠）がある
2. 法人向けプラン（Team・Enterprise）……会社がまとめて席（シート）を買う。定額＋管理機能。使用量の枠は席ごと
3. API・クラウド経由……使った分だけ払う従量課金。上限はなく、統制はこちらで設計する

ここで最初に押さえてほしいのは、1と2は「定額で、その代わり使用量に枠がある」、3は「枠はないが、使った分だけ請求が伸びる」という性質の違いです。この違いを理解しないまま「安いのはどれ？」と比べると、必ず後で認識がずれます。

公式ドキュメントは、この点をはっきり書いています。TeamとEnterpriseのプランでは「各メンバーの利用は席ごとの割り当て枠から消費される」のに対し、コンソール（API）とクラウドプロバイダー経由では「トークン単位で組織に課金される」。同じ組織の中で複数のサインイン方法が混在している場合、各利用者は自分が認証した方法に応じて計測されるとも書かれています。つまり「全社でTeamにしたはずなのに、一部の人がAPIキーで使っていて請求が別に立っていた」という状態が起こり得ます。

会社としてまず決めるべきこと

金額表を見比べる前に、次の3つを決めてください。この順番でしか決まりません。

• 誰が使うのか（何人・どの部署・非エンジニアを含むか）
• 何に使うのか（開発なのか、資料作成・データ整理・自動化なのか）
• 会社の情報をどこまで読ませるのか（社内規程・監査要件によって選べるプランが変わる）

3つ目を軽視すると、金額を決めたあとに情シスから差し戻されます。導入支援の現場でいちばん多い手戻りがこれです。セキュリティ・権限設計の記事で扱っている論点を、料金の検討と同時並行で進めてください。

入口1：個人向けプラン（Free・Pro・Max）

まず、個人が自分のアカウントで契約するプランです。公式の料金ページ（2026年8月12日時点）では、次のように表示されています。

公式ページには「税別」「価格は変更される場合がある」と明記されています。金額そのものより、Maxの説明に「Proの5倍または20倍の使用量を選ぶ」と書かれている点に注目してください。ここに、このプラン体系の設計思想が出ています。売っているのは機能ではなく「使用量」です。

法人が個人プランで運用するときの落とし穴

「まずは1人、Proで試そう」は正しい始め方です。実際、当社も導入支援では小さく試すところから始めることを勧めています。ただし、そのまま10人・20人と個人プランのまま増やすのは、金額以外の理由で止めた方がいいケースが多いです。

• 誰が何に使っているか、会社から見えない。 管理コンソールがないので、利用実態を把握する手段がありません
• 退職時にアカウントが会社から切り離せない。 個人契約なので、会社が止められません
• 経費精算が人数分発生する。 5人までは我慢できても、20人になると総務の負担が無視できません
• 会話データの扱いの取り決めが、法人契約と異なる。 情シス・法務が最も気にする点です

当社の観察では、「経費精算が面倒になった時点」で法人プランへの切り替えが検討されることが多いです。おおむね5〜10人あたりが分かれ目になります。逆に言えば、そこまでは個人プランで実績を作り、稟議の材料を集める期間として使えます。

入口2：法人向けプラン（Team・Enterprise）

会社がまとめて席を買う形です。公式ページ（2026年8月12日時点）の表示は次のとおりです。

ここでいちばん重要なのは、標準席とプレミアム席の差が「機能」ではなく「使用量の枠」だという点です。公式ドキュメントには、TeamとEnterpriseでは「各メンバーのClaude Code利用は、5時間のローリング枠と週次の枠でリセットされる、席ごとの割り当てから消費される」「その割り当てはClaudeのチャットやCoworkと共有され、大きさはそのメンバーの席の階層（標準またはプレミアム）による」と書かれています。

つまり「Claude Codeが使えるかどうか」ではなく「どれだけ使えるか」で席を選ぶのが正しい理解です。ここを取り違えると、「全員プレミアムにしないと使えないのでは」と過大な見積りを出してしまいます。

なお、Enterpriseは契約時期によって席の構成が異なる場合があり、旧来の構成ではClaude Codeを使うために特定の席種が必要だったという記述も公式ヘルプに残っています。Enterpriseを検討する場合は、席の構成とClaude Codeの扱いを必ず見積り段階で確認してください。

Teamで得られる「金額以外」のもの

Team以上にすると、料金表には出てこない管理側の機能が付いてきます。稟議ではむしろこちらが効きます。公式ドキュメントに記載されているものだけを挙げます。

• 組織の分析画面での支出レポート。 ユーザー別・モデル別の推定支出が見え、CSVで書き出せる。更新は日次
• 利用状況のダッシュボード。 日次アクティブユーザー数、セッション数などの定着指標が見える
• 支出上限の設定。 組織単位・グループ単位・個人単位で上限をかけられる
• Enterpriseでは分析API。 ユーザーごとの利用・コストをプログラムから取得できる（`read:analytics` 権限のキーをPrimary Ownerが発行）

「日次アクティブユーザー数が見える」は、地味ですが導入後の運用でいちばん効く数字です。研修をやったのに使われていないという事態を、感覚ではなく数字で検知できます。当社が定着支援でまず見るのもこの指標です。法人導入ガイドで書いた「導入したのに使われない」問題は、この数字を毎週見るだけで初動が変わります。

入口3：API・クラウド経由（従量課金）

3つ目は、Claude Console（API）経由、あるいは Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry といったクラウド経由で使う形です。

この形の特徴は「使った分だけ払う」ことです。席という概念がないので、使用量の枠で止まることもありません。裏を返せば、止める仕組みを自分で作らないと止まらないということです。

従量課金を選ぶ理由は「金額」ではない

API経由を選ぶ会社には、だいたい次のどれかの事情があります。

• 自動化に使いたい。 人が座って対話するのではなく、夜間バッチや定期実行でAIを動かしたい。席の枠では設計しづらい
• 既存のクラウド契約に寄せたい。 AWSやAzureの既存契約・予算枠の中で処理したい（購買・経理の要請であることが多い）
• データの通り道を自社のクラウド内に閉じたい。 情シス・監査の要請。これが最も多い理由です

金額が安いから、という理由でAPI経由を選ぶケースはあまりありません。むしろ「統制を自分で握るための選択」と考えた方が実態に近いです。

統制の作り方（公式に用意されているもの）

公式ドキュメントによれば、Console（API）経由ではワークスペースという単位で管理します。Claude CodeでConsoleアカウントを初めて認証すると「Claude Code」という名前のワークスペースが自動で作られ、そこでコストの追跡と管理をまとめて行える仕組みになっています。このワークスペースにはAPIキーを作れず、Claude Codeの認証・利用専用です。

そのうえで、次ができると書かれています。

• ワークスペース単位の支出上限。 Claude Codeの合計支出に上限をかけられる
• ワークスペース単位のレート上限。 Claude Codeの通信量が本番システムの枠を圧迫しないように、上限を設定できる
• ユーザー別のレポート。 コンソールのダッシュボードで、メンバーごとの支出と受け入れられた行数が見える

クラウドプロバイダー経由の場合は、支出の管理はそのクラウドの請求コンソール側になります。この場合Claude Codeはクラウドからの利用実績をAnthropicへ送らないため、Anthropic側の分析ダッシュボードや分析APIには表示されません。ユーザー別の把握が必要なら、OpenTelemetryでの計測エクスポートなど、別の手段を用意する必要があります。「クラウド経由にすれば全部見える」ではないので、監査要件がある会社は設計段階で確認してください。

人数からレート上限を見積もる

API経由で全社展開するときに、情シスから必ず聞かれるのが「どれくらいの通信枠を申請すればいいか」です。公式ドキュメントには、組織の規模ごとの推奨値が表で示されています（1ユーザーあたりのTPM＝1分あたりトークン数）。

人数が増えるほど1人あたりの推奨値が下がっていくのは、大きな組織ほど「同時に使っている人の割合」が下がるからだと説明されています。この上限は組織単位でかかるため、他の人が使っていないときは1人が一時的に多く使えます。

ひとつ注意があります。公式ドキュメントは「大人数での実地研修のように、同時利用が異常に高くなる場面が想定される場合は、1ユーザーあたりの割り当てを多めにする必要があるかもしれない」と書いています。当社も研修を提供する立場としてこれは実感があります。研修当日だけは全員が同時に手を動かします。平常時の見積りのままだと、研修中に全員が止まります。研修を計画している会社は、事前にここを申請しておいてください。

1人あたり、実際いくらかかるのか

ここが、金額表を眺めていても分からない部分です。公式ドキュメントは、エンタープライズ導入全体での実測として、次の数字を挙げています。

この数字の読み方には、注意が2つあります。

注意1：これは「開発者」の数字である

公式の表現は “per developer”（開発者ごと）です。エンジニアが日常的にコードを書く前提の数字だと考えるのが妥当でしょう。

当社が非エンジニア部署の導入支援で見ている限り、営業・経理・総務といったバックオフィス業務での消費は、これよりかなり軽くなります。 理由は単純で、扱うファイルが小さいからです。エンジニアが数万行のコードベースを読ませるのに対し、非エンジニアが扱うのは議事録・メール文面・数百行の表です。1回のやり取りで動く情報量の桁が違います。

これは見積りに直結します。「全社100人分を開発者と同じ前提で見積もる」と、実態より大きな数字になります。 稟議で過大な数字を出すと、通らないか、通っても「思ったより使われていない」という評価になります。当社が支援する場合は、まず1部署でパイロットを回し、実測してから全社の数字を作ることを必ず勧めています。公式ドキュメントも同じことを書いています——「自分のチームの支出を見積もるには、小さなパイロットグループから始め、追跡ツールで基準値を確立してから広く展開してください」。

注意2：定額プランなら、この金額を払うわけではない

上の数字は従量課金で見たときの話です。TeamやEnterpriseの定額プランを使っている場合、この範囲の利用は席の枠の中に含まれます。枠を超えたときに初めて、追加の「使用クレジット」として費用が発生します（後述）。

つまり定額プランは「上限つきの保険」として機能します。1人あたり月 $20〜25 の席で、公式が言う $150〜250 相当の利用が枠内に収まるなら、費用管理の観点では圧倒的に読みやすい。多くの日本企業にとって、まずTeamプランを検討すべき理由はここにあります。

誰にどのプランを割り当てるか：4つの利用強度

ここからが実務です。全社導入で必ず出てくる問いは「全員同じプランでいいのか」です。答えは「良くない。ただし、部署や役職で分けてもいけない」です。

当社が導入支援で使っている分け方は、利用強度の4段階です。

① 試す人（月に数回）

研修を受けたばかり、あるいは「たまに使えれば十分」という層。文章の推敲、資料のたたき台、簡単な表の整理。無料枠や標準席で足ります。 ここに高い席を割り当てると、稼働率の低いライセンスが積み上がります。

② 週に数回使う人

営業・企画・人事など、業務の一部に組み込み始めた層。議事録の要約、メールの下書き、アンケートの集計。標準席で足りることがほとんどです。当社の非エンジニア部署の運用実感でも、この層が枠を使い切ることはまれです。

③ 毎日使う人

その業務の中心にClaude Codeが入っている層。情シス、DX推進、データを扱う職種、そして開発チーム。ここは枠に当たり始めます。 プレミアム席、または使用クレジットの併用を検討する対象です。

④ 自動化を動かす人

人が座っている時間とは無関係に、定期実行やバッチでAIを動かしている層。ここだけは、席で考えると設計が破綻します。

当社自身がこの層です。自社のバックオフィスでは、毎朝の工程表づくり、商談記録の整理、ブログ下書きの生成などを、人が操作していない時間に自動で動かしています。これは「1人が使う量」ではなく「仕組みが消費する量」なので、席の枠という考え方に乗りません。API経由に分けて、支出上限をかけて管理するのが素直です。

費用が想定より膨らむ5つの原因と止め方

公式ドキュメントには、費用が想定より伸びる理由と対処が具体的に書かれています。ここは研修で最初に教えるべき内容でもあるので、実務の言葉に置き換えて整理します。

原因1：セッションを消さずに使い続ける

Claude Codeはやり取りのたびに会話の全体を送り直します。公式ドキュメントの表現では「1日中開いたままのセッションでの1行の質問でも、会話全体ぶんの利用を消費する」。つまり朝から夕方まで同じ会話を続けると、夕方の一言が重くなるということです。

対処：関係のない作業に移るときは `/clear` で新しく始める。公式は「本当に一からやり直したいときは `/compact`（要約）より `/clear` の方が費用がかからない」とも書いています。要約は、その要約対象を読み込むぶんの費用がかかるからです。

原因2：重いモデルを既定のまま使う

公式ドキュメントは「Sonnetはほとんどのコーディング作業をうまく処理し、Opusより安い。Opusは複雑な設計判断や多段の推論のために取っておく」と明記しています。

対処：既定のモデルを業務に合わせて設定する。非エンジニア業務なら、なおさら重いモデルを常用する理由がありません。研修で「モデルを切り替える」という発想自体を教えていない会社が多いので、ここは費用に直結します。

原因3：使わないツール連携をつなぎっぱなしにする

MCPで業務ツールをつなぐと便利ですが、公式ドキュメントは「使っていないサーバーは無効にする」ことを推奨しています。`/mcp` で設定済みのサーバーを確認し、使っていないものを切る。`/context` で何が場所を取っているか確認できるとも書かれています。

対処：四半期に一度、つないでいる連携の棚卸しをする。費用の話であると同時に、権限の話でもあります（MCPの記事で詳しく書いています）。

原因4：自動化が想定外に走り続ける

公式ドキュメントは、定期実行のタスクについて「セッションが待機中でも、間隔ごとに発火し、そのたびに会話の全体を送る」と書いています。また複数のAIを同時に走らせる「エージェントチーム」は「通常のセッションのおよそ7倍のトークンを使う」（各担当が計画モードで動く場合）とも明記されています。

対処：自動化を作るときは、実行ログを必ず残す。当社は自動化を作るときの型として「エラー処理・実行ログ・失敗通知」の3点セットを必ず入れています。費用の異常も、この実行ログがあれば「いつから増えたか」が特定できます。ログがないと、請求が来てから探すことになります。

原因5：認証方法が人によってバラバラ

これは公式ドキュメントの「組織がサインイン方法を混在させている場合、各開発者は自分が認証した方法に従って計測される」という記述に対応する、実務上いちばん厄介な問題です。

対処：会社としての認証方法を1つに決め、情シスが配布時に統一する。個人がAPIキーを自分で取得して使うと、会社の統制の外に出ます。これは費用の問題であると同時に、情報の通り道の問題です。

管理側の統制：「気づく」から「止める」まで

費用の統制には段階があります。見える → 気づける → 止まるの3段階です。多くの会社は最初の段階で止まっています。

段階1：見える（レポート）

Team・Enterpriseでは、組織の分析画面に支出レポートがあり、ユーザー別・モデル別の推定支出が日次で更新され、CSVで出せます。EnterpriseならAPIで取得もできます。まずここを毎週見る担当を決めてください。

段階2：気づける（通知）

レポートは、見に行かないと気づけません。「毎週月曜に前週の数字を確認して共有する」ところまでを運用に組み込んで、初めて気づける状態になります。当社は自社の各種レポートを、毎週決まった時間にチャットへ自動で流す形にしています。人の記憶に頼ると、忙しい週から見なくなります。

段階3：止まる（上限）

公式ドキュメントによれば、定額プランでは「席の割り当て枠が既定の上限」です。枠を超えて作業を続けさせたい場合は「使用クレジット」を有効にし、組織・グループ・個人のそれぞれの単位で支出上限を設定できます。

ここが、法人の費用管理では最も重要な設計判断になります。

なお、メンバーが枠に当たったとき、Team・Enterpriseで請求権限のない人は `/usage-credits` を実行すると管理者に申請が飛ぶ仕組みになっています。管理者側は、この申請が来た人＝実際に足りていない人、と判断できます。これは割り当てを見直すための、いちばん確かなシグナルです。

費用対効果の測り方：自社試算の4ステップ

ここで、はっきり書いておきたいことがあります。

他社の記事に載っている「◯◯%削減」という数字を、自社の稟議に転記しないでください。 それは他社が自社の条件で測った数字で、あなたの会社の業務量・人件費・習熟度とは無関係です。決裁者が鋭ければ「その93%は、どの業務を、何人で、何回測ったものか」と必ず聞きます。答えられなければ、資料全体の信頼が落ちます。

代わりに、自社の1業務を実測してください。 手順は4つだけです。

ステップ1：対象業務を1つだけ選ぶ

選ぶ基準は「頻度が高く、手順が決まっていて、成果物の形が毎回同じ」もの。議事録の整理、定例レポートの作成、問い合わせへの一次返答、経費の内容記入など。複数選ばないでください。 1つを正確に測る方が、5つを雑に測るより説得力があります。

ステップ2：導入前の時間を測る

「たぶん1時間くらい」ではなく、実際に3〜5回、時計で測ります。ここを飛ばすと、後で必ず「その前の時間は何を根拠に？」と聞かれます。

測る単位は「1回あたり何分 × 月に何回 × 何人」。この3つが揃って初めて、月あたりの時間になります。

ステップ3：導入後の時間を測る

同じ業務を、同じ人が、Claude Codeを使って行います。ここで重要なのは「AIが出した結果を人が確認する時間を必ず含める」ことです。確認時間を除いた数字は現実には存在しません。

当社の自社運用では、ほとんどの業務で「AIが作る → 人が確認して直す」の形を取っています。確認込みの時間で測らないと、導入後に「思ったより減っていない」となります。

ステップ4：時間に人件費単価をかける

浮いた時間（月あたり）× その業務を担当している人の時間単価＝月あたりの効果額。ここからライセンス費用を引けば、その業務単体での収支が出ます。

時間単価は、自社の人件費（賞与・社会保険料の会社負担分を含む）から算出してください。総務や経理が持っている数字です。世間の平均年収から計算すると、これも「その数字はどこから？」で止まります。

「浮いた時間」を何に使うのかまで書く

決裁者から最もよく出る反論は、「時間が浮いても、人は減らないよね？」です。これは正しい指摘です。

答え方は2つあります。どちらかを、あらかじめ決めておいてください。

• 浮いた時間を、別の付加価値業務に充てる。 例：営業事務の時間が減ったぶん、既存顧客へのフォロー件数を月◯件増やす。この場合、効果は「増える売上の見込み」で書く
• 今できていないことを、できるようにする。 例：これまで手が回らず放置していた分析・問い合わせの一次対応を回せるようにする。この場合、効果は「増員せずに済んだ人件費」で書く

「時間が浮きます」で終わる稟議は通りません。浮いた時間の行き先まで書いてある稟議は通ります。 当社の導入支援でも、ここを一緒に設計するところから入ることがほとんどです。

稟議で必ず聞かれる6つの質問

当社が導入支援に入った案件で、決裁者から実際に出た質問を整理しました。金額の資料を作るときは、この6つに先回りして答えておいてください。

質問1「他社のAIツールと何が違うのか。二重投資ではないか」

すでにチャット型のAIを契約している会社では必ず出ます。答え方は「使う場面が違う」です。チャット型は画面の中で完結し、Claude Codeは手元のファイルを直接読み書きし、社内ツールとつないで一連の作業を最後までやる。この違いを、自社の業務1つで実演できると一発で伝わります。完全ガイドで全体像を整理しています。

質問2「使わなくなったら、その席は無駄にならないか」

年払いにすると割安になる一方、この不安が強まります。最初の契約は、割り当てを見直せる余地を残すのが現実的です。前述のとおり、使用量は役職や部署とは相関せず、走ってみないと分かりません。

質問3「情報はどこに行くのか」

料金の質問のつもりで説明していたら、必ずここに飛びます。プランによって扱いが変わる領域なので、契約前に確認して、その回答を稟議書に書いてください。 曖昧なまま出すと、法務で止まります。

質問4「導入した後、誰が面倒を見るのか」

ライセンス費用より、この体制の話で止まる会社の方が多いです。「情シスの◯◯が窓口、月◯時間」まで書きます。書けないなら、外部の支援を費用に含めてください。

質問5「請求はどう来るのか。円建てか、ドル建てか」

経理から出る質問です。支払い方法・請求書の形式・為替の扱いは、購買の要件になり得ます。 Enterpriseは個別見積りなので、この点も含めて相談できます。ここを詰めずに稟議を出すと、経理から差し戻されます。

質問6「効果は、いつ・どうやって報告するのか」

いちばん大事な質問です。報告の形を、導入前に決めておいてください。 前述の分析ダッシュボード（日次アクティブユーザー数・セッション数）と、実測した1業務の時間。この2つがあれば、3か月後の報告は作れます。報告の形を決めていない導入は、次年度の予算で必ず削られます。

ライセンス以外にかかる費用

見積りから漏れやすいものを挙げます。金額の桁は会社によりますが、存在を忘れると後で「聞いてない」になります。

• 教育の費用。 使えるようになるまでの研修。これがないと、ライセンスだけ買って使われない状態になります
• 環境を整える情シスの工数。 端末への導入、権限設計、社内ルールの整備。金額ではなく人の時間として、最も大きく効きます
• ルールを作る工数。 何を入れてよくて、何を入れてはいけないか。総務・法務・情シスの合議が要ります
• 連携先サービスの上位プラン。 業務ツールとつなぐ場合、そのサービス側で外部連携に上位プランが必要なことがあります
• 運用を見る人の時間。 週次のレポート確認、四半期の棚卸し。少ない時間ですが、ゼロにはなりません

逆に、「使わなくなったコストが減る」欄も作ってください。 既存の外注（資料作成・データ入力・簡単な集計）を内製に戻せるなら、そのぶんは費用から差し引けます。当社の支援先では、ここを書いたことで収支が反転した例が複数あります。

助成金を使う場合の考え方

ライセンス費用そのものは、通常、助成金の対象になりません。 助成の対象になるのは、多くの場合「研修（人材開発）」の部分です。ここを混同すると、申請の段階で分かって計画が崩れます。

厚生労働省の人材開発支援助成金では、要件を満たす訓練について中小企業で経費助成が最大75%、2027年3月までの措置とされています（当社が確認した範囲。「最大」であって全員がその率になるわけではありません）。要件・率・期限は改正されるため、最新の要件は所轄の労働局・ハローワークで必ずご確認ください。

実務上のポイントは3つです。

• 対象になるのは研修部分。 ライセンス料・ツール利用料は別枠で予算を組む
• 訓練の形式に要件がある。 講師と受講者のやり取りがある形か、動画を見るだけかで扱いが変わります
• 申請は事前。 訓練を始めてから「使えますか」と聞いても間に合わないことがあります

詳しくはClaude Code研修に使える助成金の記事で、対象条件と申請の流れをまとめています。ライセンス費用と研修費用を分けて予算化する——これだけ覚えて帰っていただければ、計画が崩れません。

よくある質問

結局、いくらから始められますか？

無料プランでもClaude Codeは使えると公式ページに記載があります。まずは1人が触って、自社の業務で何ができるかを確かめるところからで十分です。会社として本格的に使うなら、Teamプランの標準席（年払いで1席あたり月 $20、月払いなら $25／いずれも税別・2026年8月12日時点）が出発点になります。金額は変更される場合があるので、必ず公式ページで最新をご確認ください。

日本円だといくらですか？

公式ページの表示は米ドルです。この記事では意図的に円換算していません。 為替で変わる数字を記事に固定して書くと、読んだ時点で古くなるからです。稟議書には、起案日のレートを自社で当ててください。経理に「いつのレートか」を聞かれたときに答えられる形にしておくのが安全です。

Teamプランは何人から契約できますか？

最低契約席数などの条件は変わり得るため、申し込み前に公式ページか営業窓口でご確認ください。 当社の支援では、この点も含めて要件を整理したうえで見積りを取ります。

途中でプランを変えられますか？

変更可否と反映のタイミング、年払いの残期間の扱いは契約条件によります。特に年払いを選ぶ場合は、変更条件を契約前に確認してください。 前述のとおり、実際の使用量は導入してみないと分からないので、見直せる余地があるかどうかは金額と同じくらい重要な検討事項です。

非エンジニアの部署にも、同じ金額をかける価値がありますか？

当社の実感では、非エンジニア部署の方が費用対効果は出しやすいです。理由は2つあります。1つ目は、前述のとおり扱うデータが小さく、消費量が軽いこと。2つ目は、元の作業が「手作業のまま残っていた」ことが多いためです。開発現場はすでに多くの効率化ツールが入っていますが、バックオフィスには「毎月人が手で表に転記している」ような業務が残っています。そこが一続きになると、効果が分かりやすく出ます。具体的な始め方は非エンジニアのためのClaude Code入門にまとめています。

費用の見積りだけ相談できますか？

できます。「何人が、どの業務で、どれくらい使いそうか」をお聞きすれば、どの入口（個人プラン／Team／API）が合うか、割り当てをどう分けるか、稟議書に何を書くべきかまでご提案します。ご相談・お見積りは無料です。

まとめ

Claude Codeの法人利用にかかる費用は、金額表を眺めても決まりません。「誰が・何に・どれくらい使うか」を先に決めると、入口が自動的に決まる——これがこの記事でいちばん伝えたいことです。

• 入口は3つ。 個人プラン／Team・Enterprise／API・クラウド経由。定額は「枠つき」、従量は「上限は自分で作る」
• 標準席とプレミアム席の差は機能ではなく使用量の枠。 「使えるかどうか」で選ばない
• 公式が出している実費の目安は、1人あたり稼働日 約 $13・月 $150〜250・90%は稼働日 $30 未満（従量課金で見た場合／2026年8月12日時点の公式ドキュメント）。ただしこれは開発者前提の数字で、非エンジニア業務ではこれより軽くなる
• 割り当ては利用強度の4段階で決める。 役職や部署で分けると外す
• 費用が膨らむ原因は使い方の癖。 セッションを消さない、重いモデルのまま、つなぎっぱなし、自動化の走りすぎ、認証のバラバラ。全部、教えれば直る
• 統制は「見える → 気づける → 止まる」の3段階。 レポートを見る人と曜日を決め、上限は最初オフで実態を掴んでから
• 効果は自社で1業務を実測する。 他社の削減率は転記しない。浮いた時間の行き先まで書く
• ライセンス費用と研修費用は分けて予算化する。 助成の対象になるのは通常、研修の部分

そして、最も確実な進め方は「小さく始めて、実測してから広げる」です。これは当社の意見であると同時に、公式ドキュメントが明記している推奨手順でもあります。1部署・数人・1か月。それだけで、全社の見積りに必要な数字は揃います。

当社では、Claude Codeの研修と法人導入支援を行っています。「うちの規模だとどの入口が合うか」「稟議書に何をどう書けばいいか」「使用量の見積りをどう作るか」といった費用まわりの設計から、研修・社内展開・運用ルールづくりまで、まとめてご相談いただけます。この記事に書いた運用の型は、当社自身が日々の業務で使っているものです。ご相談・お見積りは無料です。

御社の人数・業務に合わせて、費用と割り当てをご提案します
ご相談・お見積もりは無料です

無料で相談する →