「Claude Codeを導入したいが、稟議書に目的・費用・セキュリティ・効果をどう書けば通るのか分からない」という方は多いはずです。じつは稟議で問われる項目は、公式の料金ページとプライバシーポリシー、そして実際の研修事例で裏づけることができます。ただし料金やデータの扱いは変わることがあり、古い情報のまま書くと逆に信頼を落としかねません。そこで本記事では、Anthropicの公式情報と研修で確認できた実例をもとに、稟議の4項目を具体的にどう埋めればいいかを解説します。稟議を控えている方は、そのまま構成の下敷きにしてください。
稟議に書く4項目「目的・費用・セキュリティ・効果」の全体像
Claude Codeの稟議書は、目的・費用・セキュリティ・効果の4項目で構成すると通りやすくなります。この4つは、稟議を読む経営層と情報システム部門それぞれの承認基準に対応しているためです。
| 項目 | 主に答える疑問 | 想定する決裁者 |
|---|---|---|
| 目的 | 何のために、誰が使うのか | 経営層・現場責任者 |
| 費用 | いくらかかり、予算内に収まるのか | 経営層・経理 |
| セキュリティ | 情報漏洩や規約違反のリスクはないか | 情報システム部門 |
| 効果 | 投資に見合う成果が見込めるのか | 経営層 |
なぜこの4項目で構成すると通りやすいのか
稟議が差し戻される典型的な理由は、読む人の懸念に答えないまま提出してしまうことです。経営層は予算と成果を見ており、情報システム部門はデータの扱いを見ています。目的・費用・セキュリティ・効果の4項目は、この2種類の懸念にそれぞれ対応する形になっています。目的と効果が経営層の「投資判断」を支え、セキュリティが情報システム部門の「リスク判断」を支えます。費用はその両方をつなぐ数字として機能します。どれか1項目でも曖昧なまま提出すると、その項目の担当部署から質問が返り、決裁が止まります。
書く順番で決裁者の納得感が変わる理由
4項目は並び順も結果に影響します。目的を最初に置くのは、何のために導入するのかが決裁者の判断の起点になるためです。目的がはっきりしないまま費用やセキュリティを説明しても、読む人は何と比較して良し悪しを判断すればいいか分かりません。目的の次に費用を置けば、投資額の規模感をつかんだ状態でセキュリティの説明に進めます。セキュリティを費用の後に置くのは、情報システム部門の懸念が解消されないまま効果の話に進むと、話が前に戻ってしまうためです。最後に効果を置くことで、目的で示した狙いが数字や事例でどこまで裏づけられるかを、決裁者が読み終えた時点で判断できます。
次のセクションからは、この4項目を1つずつ、何を根拠にどう書けばよいか具体的に見ていきます。セキュリティ欄の書き方については、Claude Codeのセキュリティとは？法人導入前に確認すべきデータ管理と設定を解説でも詳しく扱っています。
目的の書き方：何のために・誰が使うのかを絞り込む
目的欄で最初につまずきやすいのが、「業務効率化のため」「AIを活用したいため」といった書き方です。これでは、どの業務がどう変わるのか決裁者に伝わらず、差し戻しの対象になります。
「AIを使いたい」ではなく業務とセットで書く
目的欄に必要なのは、どの部門の、どの業務に、誰が使うのかという3点です。この3点がそろって初めて、費用やセキュリティの説明が具体的に読めるようになります。
| 書き方 | 内容 | 決裁者の反応 |
|---|---|---|
| 抽象的 | 「生産性向上のためAIを導入する」 | 何に使うのか分からず質問が返る |
| 具体的 | 「マーケティング部門が、月次レポートの作成業務でClaude Codeを使う」 | 対象業務が明確で判断しやすい |
他部門が実際にどんな業務でClaude Codeを使っているかを調べておくと、自社の目的欄を書くときの参考になります。職種別の使い方はClaude Code活用事例｜非エンジニアの会社・個人が実際にどう使っているか解説にまとめています。
使い始めの範囲を絞ると稟議が通りやすくなる理由
目的欄は、対象業務だけでなく最初に使う範囲も絞ったほうが通りやすくなります。Extend Claude Code - Claude Code Docsでは、Claude Codeに不慣れな場合はまずCLAUDE.md（プロジェクトの慣習を記録するファイル）から始め、外部サービスとの連携や再利用可能な手順の登録といった拡張機能は、必要になった時点で追加することが推奨されています。最初からすべての機能を設定する必要はなく、多くのチームはほぼ決まった順序で機能を足していくとも説明されています。
この考え方は、実際の研修先でも同じ形で実践されていました。
実録支援先の声（GOROの事例より）
使い始めに押さえる4つのうち、最初の2つに絞った研修
GOROのClaude Code研修では、使い始めるときに押さえることを4つに整理しています。
- フォルダを決める
- ルールをファイルに書く
- 外部のアプリとつなぐ
- 手順をスキルにする
先方の研修では、このうち最初の2つだけに時間を使いました。
出典：Claude Code未経験だった全部門5名が、4時間の研修から1ヶ月後も毎日使い続けている事例（GOROの事例記事）
公式ドキュメントの段階的な考え方と、研修先で実際に範囲を絞った進め方は一致しています。稟議の目的欄も、この考え方に沿って書くと説得力が増します。「全社であらゆる業務に使う」と書くのではなく、「まず特定の部門の特定の業務から始め、定着を見て範囲を広げる」と書けば、対象範囲が狭まる分だけ費用の見積もりもセキュリティの説明範囲も具体的になります。決裁者にとっては、判断すべき対象が小さくまとまっているほうが承認しやすくなります。
費用の書き方：公式の料金ページの数字をそのまま使う
目的欄が具体的に書けたら、費用欄はその対象人数と利用範囲に合わせて、公式の料金ページの数字をそのまま当てはめます。
Standard seatとPremium seatの金額をどう書き分けるか
Teamプランには2種類のシート（利用枠）があります。Plans & pricingによると、標準シート（Standard seat）は年払いなら月額20ドル、月払いなら月額25ドルです（米国価格、税別）。Teamプランは最低2人から契約でき、最大150シートまで対応します。
What is the Team plan?には、もう1種類のシートの金額も示されています。Premium seatは月払いで月額125ドル、年払いで月額100ドルです。StandardとPremiumの違いは金額だけではありません。Standard seatはProプランの1.25倍のセッション利用枠を持ちますが、Premium seatはProプランの6.25倍の利用枠を持ちます。
稟議の費用欄には、対象人数分のシート料金を次のような表で示すと伝わりやすくなります（What is the Team plan?）。
| シート種別 | 年払い（月額） | 月払い（月額） | 利用枠の目安 |
|---|---|---|---|
| Standard seat | 20ドル | 25ドル | Proプランの1.25倍 |
| Premium seat | 100ドル | 125ドル | Proプランの6.25倍 |
目的欄で対象業務を絞り込んでいれば、まずStandard seatで必要人数分を見積もり、利用状況を見てPremium seatへの切り替えを検討する、という書き方ができます。最初から全員分をPremium seatで見積もるより、総額を抑えた形で提出できます。
利用上限（5時間ごと・週間）も費用対効果の説明に含める
料金表の金額だけでは、実際にどの程度の作業量で上限に達するかはつかみにくいものです。Standard seatには5時間ごとのセッション利用枠に加えて、全モデルに共通する週間の利用上限があります（What is the Team plan?）。利用人数や作業量によっては、この上限に実際に達する場面が出てきます。
Teamプランのスタンダードシートを使った記録でも、公式が説明する利用上限に実際に到達したケースが確認できます。
実録代表・旭の一次体験
Teamプランのスタンダードで完走したが、利用上限にはよく当たった
私はClaudeのTeamプラン（スタンダード）の範囲で使いました。専用の追加課金はありません。
Teamプランのスタンダードで完走。ただし5時間ごと・週間の利用上限にはよく当たったので、作業を日で切り分けて回した。
出典：スライド作りをClaude Designに任せたら、主役はスライドではなくなった（代表・旭俊成のnote）
ここで使われた製品はClaude CodeではなくClaude Designです。ただし同じTeamプランのスタンダードシートで、公式が説明する利用上限に実際に到達した記録として参考になります。稟議の費用欄には、金額に加えて「利用が多い月は上限に達する場合があり、その際は作業日を分けて運用する」という一文を添えておくと、追加費用が発生しにくいことを示せます。利用量が増えて上限に頻繁に達するようであれば、Premium seatへの切り替えを検討する、という段階的な書き方も費用対効果の説明として機能します。
料金は変わるため「取得日」を必ず書く
ここまでの金額は、2026年10月時点でPlans & pricingとWhat is the Team plan?で確認した数字です。Anthropicの料金プランは改定される場合があるため、稟議書には金額とあわせて確認した日付を記載します。
「◯年◯月◯日に公式サイトで確認」と一文を添えるだけで、後日金額が変わっても、稟議作成時点の根拠が明確なまま残ります。提出直前には、改めて公式サイトで最新の金額を確認してから数字を入れ直す運用にしておくと安全です。
法人向けのプラン構成や支払い方法の違いについては、Claude Codeの法人料金はいくら？公式データで見るプランと注意点を解説でも詳しく整理しています。
セキュリティの書き方：データ学習・保持期間を事実で説明する
費用欄の次は、情報システム部門が最も厳しく見るセキュリティ欄です。ここで曖昧な説明をすると、担当者から追加の確認依頼が入り、稟議の進行が止まります。
個人プランと法人プランでデータ学習の扱いが違う
まず押さえておきたいのは、データが学習に使われるかどうかは、プランの種類だけでは決まらないという点です。Is my data used for model training?には、学習への利用可否は、本人が設定をオンにしたか、安全レビューでフラグが立ったか、明示的にオプトインしたかで決まると説明されています。
その上で、プランごとの既定の扱いには明確な違いがあります。Data usage - Claude Code Docsによると、個人向けプラン（Free・Pro・Max）はこの設定がオンになっていれば、Claude Codeの利用分を含めて学習に使われます。一方、Team・Enterpriseなどの商用プランは、顧客側が明示的にデータ提供を選ばない限り、コードやプロンプトを学習に使いません。
| プラン | 学習への利用 | 利用される条件 |
|---|---|---|
| 個人向け（Free・Pro・Max） | 設定次第 | 本人が設定をオンにしている場合 |
| 商用（Team・Enterprise等） | 既定では使わない | 組織側が明示的にオプトインした場合のみ |
この違いを確認する過程で見つかったのが、「個人プランは学習に使われない」という説明の誤りです。
実録GOROの作業記録
「個人プランは学習に使われない」という説明は誤りだった
「個人プランは学習に使われない」と説明するのは誤り。情シス・経営層への説明で信用を失う。
訴求は「法人プランだから安全」ではなく「個人アカウントのまま業務データを扱うのが一番危ない。設定が本人任せで、オンだと5年保持される」。
出典：GOROの社内の作業記録
稟議書のセキュリティ欄には、「個人プランは安全」と書くのではなく、「業務利用は法人プランに統一し、個人アカウントでの利用を認めない」という方針で書くと、実態に即した説明になります。
保持期間の数字（5年／30日）をそのまま使う
学習への利用可否とあわせて、保持期間の数字も稟議書に書いておくべき内容です。How long do you store my data?には、モデル改善への利用を許可した場合、チャットやコーディングセッションは非識別化された形で最大5年間、訓練パイプラインに保持されると説明されています。会話を削除すれば30日以内にバックエンドからも削除され、以降の学習には使われません。
| 状態 | 保持期間 |
|---|---|
| 学習利用を許可している場合 | 最大5年間 |
| 会話を削除した場合 | 30日以内に削除 |
| 商用プランの標準設定 | 学習に使わず、保持も標準で短い期間に収まる |
稟議書には「◯年◯月◯日に公式サイトで確認」という一文を数字とあわせて書いておきます。保持期間の方針は規約の改定で変わる可能性があるため、提出直前にもう一度同じページで数字を確認し直す運用にしておくと安全です。
フィードバック機能など稟議に書き漏らしやすい例外
ここまでの説明だけでは拾いきれない例外が1つあります。評価や報告のための機能です。Data usage - Claude Code Docsには、/feedbackコマンド（および同じ経路で送られる/bug・/share）で送ったトランスクリプトは5年間保持されると明記されています。Is my data used for model training?でも、親指ボタンで送ったフィードバックは会話全体を含めて最大5年間保存されると説明されています。
この保持期間は、法人プランで学習利用をオプトアウトしていても適用されます。つまりプランの設定とは別に、フィードバック機能を使った時点で発生する例外です。社内の確認でも、この例外はプランの種類に関係なく発生することが確かめられています。
| 操作 | 保持期間 | プランによる違い |
|---|---|---|
| 通常の会話（学習利用オフ） | 30日 | プランの既定設定に従う |
| /feedback・/bug・/share | 5年 | プランに関係なく一律 |
| 親指ボタンでの評価 | 5年 | プランに関係なく一律 |
稟議書のセキュリティ欄には、この例外を利用ルールとあわせて書いておくと、情報システム部門からの追加質問を防げます。具体的には、「業務で機密情報を扱う際は、/feedback・/bug・/share・親指ボタンでの評価を使用しない」という一文を、運用ルールの項目に加えておく形です。
効果の書き方：期待効果は公開されている研修事例で裏づける
セキュリティ欄の説明が終わったら、最後に効果欄を書きます。ここで使える根拠の一つが、職種別の課題と成果をセットで示す公開事例です。
自社と近い職種の公開事例を引用する
効果欄に「業務が効率化される見込みです」とだけ書いても、何がどう変わるのか決裁者には伝わりません。説得力を持たせるには、自社と近い職種が抱えていた課題と、その課題への対応をセットで示す必要があります。
あるデザインチーム向けの研修では、事前ヒアリングで次の3つの実態が確認されています。
実録支援先の声（GOROの事例より）
デザインチーム向け研修の事前ヒアリングで分かったこと
研修前のヒアリングで、デザインチームがどのようにFigmaを使い、どこで時間を取られているかを把握したうえで、プログラムをゼロから設計しました。
確認できた実態は3つです。「チーム全体で足並みを揃えたいが、個人でのキャッチアップには時間がかかります」「CLIやHTMLに普段触れる機会が少ない環境でした」「レビューとコメント対応に繰り返し時間がかかっていました」。
出典：Claude Code未経験の非エンジニア10名が、2時間の研修でサイト公開まで到達した事例（GOROの事例記事）
稟議の効果欄に自社の課題を書くときは、ここまでのように「現状どこで時間が取られているか」を先に書き出しておくと、効果の説明に具体性が出ます。
「わかった気になる」で終わらない研修形式を効果の根拠にする
ヒアリングで見えた課題をもとに、研修には3つの設計方針が立てられました。
- 「できた」体験を最初の2時間に集約する：インストールから始めてWebページを公開するまでを1回目に詰め込む
- 業務に直結するシナリオを使う：Figmaコメント対応・プロトタイプ修正という実業務そのものを2回目のテーマにする
- 全員が同じペースで進められる設計にする：既存HTMLの小さな修正から始め、段階的に難易度を上げる
この3つの方針が示しているのは、説明を聞いて終わる研修ではなく、受講者が自分の手で成果物を完成させるところまでを研修に含めている点です。インストールからWebページの公開、そして実際の業務であるFigmaコメント対応とプロトタイプ修正までを扱っています。
稟議の効果欄には、この「課題把握→設計→成果物完成」という流れをそのまま書くと、根拠のある説明になります。たとえば「事前のヒアリングで現場の課題を特定し、その課題に対応する内容で研修を設計し、受講者が初回から成果物を完成させた事例がある」という書き方です。社内の説明として使うときは、自社の対象部門に当てはめて「同様の設計であれば、自社の〇〇業務でも成果物の完成までを見込める」と続けると、効果欄が単なる期待ではなく、既存の進め方に基づいた見込みとして読めます。
稟議を出す前に確認しておきたい想定質問への先回り
効果欄まで書き終えても、決裁者からはいくつかの質問が返ってくることがあります。提出前に回答を用意しておくと、差し戻しの回数を減らせます。
「エンジニアしか使えないのでは」への回答
Claude Codeという名称から、プログラミングの知識が必要だと誤解される場面があります。この質問が出たときは、目的欄で絞り込んだ対象業務と対象者を改めて示すのが有効です。前述のとおり、使い始めに必要な設定はCLAUDE.mdという1つのファイルだけです。外部サービスとの接続（MCP）や、再利用可能な手順の登録（Skills）といった拡張機能もありますが、前述のとおり必要になった時点で追加すれば十分です。
稟議書には、次の2点を書いておくと回答になります。
- 最初に使うのは基本機能のみで、対象者が日常業務の延長で操作できる範囲であること
- 外部連携や手順の自動登録といった高度な設定は、定着を見てから検討する段階であること
技術的な難易度への不安は、使い始める機能の範囲を具体的に示すことで解消しやすくなります。
いきなり全社導入ではなく小さく検証する選択肢
もう一つよく出る質問が、全社展開した場合の失敗リスクです。この質問には、対象範囲を限定した検証から始める提案で答えられます。
前述のとおり、公式ドキュメントは機能を一度にすべて設定するのではなく、必要になった順に追加していく考え方を示しています。この考え方は、使う機能の範囲だけでなく、導入する部門の範囲にも当てはめられます。
稟議書には、次のような段階を書いておくと、決裁者はリスクの小さい判断から始められます。
| 段階 | 対象範囲 | 確認すること |
|---|---|---|
| 第1段階 | 目的欄で定めた1部門・1業務 | 想定した業務で実際に使えるか |
| 第2段階 | 利用状況を見て近い部門に拡大 | 費用・利用上限が想定どおりか |
| 第3段階 | 全社展開を検討 | 第1・第2段階の結果を踏まえた判断 |
シートの契約も、全社分を一度に揃えるのではなく、目的欄で絞り込んだ範囲から始め、利用状況を確認してから次の段階に進む書き方にします。この進め方なら、想定どおりの効果が出なかった場合でも、影響範囲は最初の部門にとどまります。
ここまでの4項目と想定質問への回答がそろえば、稟議書に書く材料は一通り揃います。提出前には、料金とデータ管理の公式ページで最新の数字を確認し、自社の対象部門・対象業務に当てはめた状態で仕上げてください。
この記事と合わせて読みたい
- Claude Codeの法人料金はいくら？公式データで見るプランと注意点を解説 — 稟議の費用欄をさらに厚くしたい場合、プラン別の料金を公式データで詳しく整理したこの記事が参考になります。
- Claude Codeのセキュリティとは？法人導入前に確認すべきデータ管理と設定を解説 — セキュリティ欄をより詳しく書きたい場合、法人導入前に確認すべきデータ管理の全体像を解説したこの記事が役立ちます。
- Claude Code活用事例｜非エンジニアの会社・個人が実際にどう使っているか解説 — 効果欄に書ける活用イメージをさらに広げたい場合、非エンジニアの会社・個人の活用事例をまとめたこの記事が参考になります。
Claude Codeの社内導入を検討している方へ
GOROは、デザイナー・マーケ担当・ディレクターなど非エンジニアの部署を対象にしたClaude Code法人研修を提供しています。事前ヒアリングで業務の内容を伺い、研修の内容を設計します。研修の当日に、受講者が実際の成果物を作り切る形式です。
