稟議書とは・書き方【IT担当者版】技術を経営言語に変える5つのポイント
「本当に必要ですか」「他の方法はないですか」——IT担当者が稟議を出すたびに直面するこの問いかけに、うまく返せないことはありませんか。
技術の正しさは分かっている。なぜ必要かも説明できるはず。それなのに毎回つまってしまう、という人もいるはずです。稟議書の書き方を確認したいとき、社内には聞きにくいという状況もあるかもしれません。
原因は説明力ではありません。技術の言葉を、経営者が判断できる言語に翻訳できていないことが、ほとんどの差し戻しの根本にあります。言い換えると、稟議書を書く仕事の半分は「翻訳」であり、技術の正確さを追いかけることではありません。
この記事では次の3点を整理します。
- 稟議書の定義と、IT担当者にとっての役割
- 差し戻しが起きる構造的な理由と、役員が判断している3点
- 経営語に翻訳するための5項目の構成・実例3本・コピペ用テンプレート
稟議書とは何か？ IT担当者向けの定義
稟議書とは、経費・設備・サービスの支出を組織として承認するための社内申請書類です。IT担当者の場合、技術の必要性を経営言語で証明する翻訳文書として機能します。
一般的には「上位者に決裁を仰ぐための書類」と説明されます。しかしIT担当者の文脈では、もう少し具体的な役割があります。技術的に正しいことと、経営者が承認できることは別物です。稟議書はその橋渡しをするための翻訳作業の出力物である——そう捉えると、何を書くべきかが決まります。
IT担当者の稟議書が特に難しい理由は、説明の対象が技術を知らない人だからです。「Cloudflare Pro のWAFカスタムルール20本で Bot トラフィックを削減する」という文章は技術的に正確です。WAF（Web Application Firewall）は、Webサイトへの不正なリクエストを自動で判別して遮断する仕組みを指します。ただし、用語の意味を添えたところで、それが会社にとって何を意味するのかは承認者に伝わりません。翻訳なしに技術情報を書くと、正確であるほど読まれなくなるという逆説が生じます。
稟議書と提案書の違い
稟議書と提案書は混同されることがあります。提案書は社外向けに新しいビジネスや契約を提案する文書です。稟議書は社内向けで、既存の業務に必要な投資の承認を求める文書です。社内のIT投資申請で使うのは稟議書です。
稟議書と報告書・申請書の違い
報告書は起きたことを伝える文書です。申請書は許可・補助・支給を求める文書（有給申請、補助金申請など）です。稟議書は「支出の承認」を求めるという点で用途が限定されています。IT担当者が書く稟議書は、外部サービスの契約・機器の購入・保守費用の承認などが主なユースケースになります。
IT稟議書が差し戻される理由は何か？
技術の正しさを書いても、経営者が判断できる形になっていないためです。役員が判断するのは損得であり、技術情報をそのまま書いた稟議は判断材料が無いまま差し戻されます。
「DDoS対策が必要」「TLS 1.3に移行したい」「EDRを入れたい」——IT担当者にとっては正確な要求です。しかし承認者の立場では、「それで会社に何が起きるのか」が読み取れません。判断できない書類は、「もう少し調べてから」と差し戻されます。
これは内容の失敗ではなく、翻訳の失敗です。
差し戻しコメントのパターンとその原因を整理すると、次のようになります。
| 差し戻しのコメント | 翻訳の失敗箇所 |
|---|---|
| 「本当に必要ですか」 | リスク提示が不足している（やらないと何が起きるかが見えない） |
| 「他の方法はないですか」 | 代替案との比較が書かれていない |
| 「費用感が分からない」 | 費用の内訳と根拠が不明確 |
| 「もう少し調べてから」 | 申請者が状況を把握していないという印象を与えている |
差し戻しコメントに「本当に必要？」が含まれているなら、それはリスク提示の翻訳が足りていないサインです。直す場所はその一項目に絞れます。
役員が稟議書で判断しているのは何か
役員が稟議書を読むとき、判断軸はほぼ次の3点に集約されます。
- 得か損か — この投資でコストが減るか、リスクが下がるか、売上につながるか
- リスクが高いか低いか — やらないと何が起きるか。説明責任を果たせるか
- 信頼できる情報か — 申請者が状況を把握していると感じられるか
技術の優劣を判断しているのではありません。役員には技術を評価する専門知識がないことがほとんどで、「判断できる土俵を作る」のがIT担当者の役割になります。
もう一つ重要な点があります。役員は稟議書を最初から最後まで読みません。件名と費用と効果の3点だけ拾って判断することが多いです。件名が何をするかを1行で示し、費用欄に数字が明確に記載されていて、リスク欄に「やらないと何が起きるか」が書いてあれば、細部を読まなくても承認できる構造になります。
IT稟議書に必ず書く5項目は何か？
申請目的・現状の問題・提案内容・費用・導入しなかった場合のリスクの5項目です。IT担当者はこの5項目を経営者が判断できる言葉に翻訳することが最重要になります。
5項目の内容と翻訳の方向性
① 申請目的
何のために申請するのかを1〜2文で書きます。技術的な説明は不要で、「何の業務が改善するか」「何のリスクが減るか」を中心に書きます。
NGの書き方: 「Cloudflare Pro のWAFカスタムルールを使って高度な攻撃を防ぐため」 OKの書き方: 「弊社Webサイトへの攻撃増加に対し、サービス停止リスクを低減するため、セキュリティ機能を強化する Cloudflare Pro の導入を申請します」
技術的な正確さを書くのは③の提案内容です。①の申請目的は「何のビジネス課題に対処するか」を1文で書く場所です。
② 現状の問題
現時点で何が起きているか、またはこのままでは何が起きるかを書きます。「〜の問題がある」ではなく、「このまま放置すると〜が止まる/〜の損失が出る」と書きます。
数字を1つでも入れると説得力が大きく変わります。「不審なアクセスが増えている」より「直近30日で◯件の不審リクエストが記録されている」の方が、承認者は状況を把握できます。
③ 提案内容
何を・いつから・どのように導入するかを書きます。他の選択肢との比較を1行で添えると、「なぜこれか」への先回り回答になります。「A社と比較検討し、コスト・導入速度・保守負担の観点から本製品が最適と判断」のような1文です。
また、「導入後に誰が何をするか」を書いておくと、承認者の「うちの担当者で対応できるのか」という不安が下がります。
④ 費用
初期費用・月額・年額・5年合計を明示します。金額を小さく見せることが目的ではなく、対策しなかった場合のコストと並べることが重要です。「月額◯円 vs インシデント1件の復旧工数◯万円」という対比が、承認を後押しします。
ドル建てのサービスは為替変動リスクを一言添えておくと、後から「費用が変わった」という問題が起きにくくなります。
⑤ 導入しなかった場合のリスク
5項目のうち手が止まりやすいのはこの項目です。一方で、承認する側にとっては判断の中心にある項目でもあります。詳しくは次の節で整理します。
「導入しなかった場合のリスク」が最も重要な理由
IT担当者はなるべく問題を前面に出したくない心理が働きがちです。問題が明らかになると「なぜ今まで放置していたのか」と問われるかもしれない、という懸念が背景にあります。
しかし承認者の立場では、「やらないと何が起きるのか」こそが最大の判断材料になります。
攻めの投資（「これで売上が増える」）より、防衛の投資（「これをやらないとこの損失が出る」）の方が、稟議は通りやすい傾向があります。特にIT系の投資は直接的な売上貢献が見えにくい分、リスク提示を軸にした「防衛コスト」として位置づけると承認を得やすくなります。
IPA（情報処理推進機構）の2024年度中小企業実態調査（調査全体 n=4,191、2025年5月公開）では、情報セキュリティ関連の被害を受けた企業の平均被害額が73万円、復旧までの平均期間が5.8日という結果が出ています。「月◯円のツール導入費」と「平均73万円の被害リスク」を並べると、稟議書の説得力は大きく変わります。
また、同調査では情報セキュリティ体制を整備済みの企業の59.8%が「対策が取引につながった」と回答しています。未整備の企業では24.2%にとどまります。セキュリティ投資を「コスト」でなく「取引機会の確保」として位置づけられる場合、この対比は有効に機能します。
なお、同調査ではセキュリティ対策投資をしていない中小企業が62.6%（2024年度）という結果も示されており、その投資していない企業（n=2,623）が挙げた対策しない理由として「費用対効果が見えない（24.2%）」「コストがかかりすぎる（21.7%）」が上位に入っています。承認者も同じ感覚を持っている可能性があります。「費用対効果が見えない」という感覚を解消するのが、5項目による翻訳の役割です。
出典: IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査」速報版 https://www.ipa.go.jp/pressrelease/2024/press20250214.html（2025年2月14日公開）/ 全体版 https://www.ipa.go.jp/security/reports/sme/sme-survey2024.html（2025年5月27日公開）
技術用語をどう経営語に翻訳するか？ 実例3本
技術の名前でなく「何が止まるか」「いくら損するか」に言い換えることが翻訳の核心です。名前の正確さより、経営者が判断できる損得の言語が優先されます。
翻訳には決まったパターンがあります。「技術の名称」を「ビジネスへの影響」に置き換えるだけです。以下の3本の実例で具体的なパターンを確認してください。
実例① Cloudflare Pro 導入
Cloudflare は世界最大規模のCDN（コンテンツ配信ネットワーク）兼セキュリティサービスです。無料プランでも基本的な保護はありますが、高度な攻撃への対応は有料のProプランが必要になります。
| 技術的な書き方 | 経営語への翻訳 |
|---|---|
| DDoS対策のためCloudflare Proを導入したい | Webサイトが攻撃で停止するリスクへの対策コスト。月$25で常時保護を維持する |
| WAFカスタムルールを20本設定する | 不正アクセスの自動遮断システムを設置する（設定後は承認不要で即時対応） |
| Super Bot Fight ModeでBotトラフィックを削減 | 悪意ある自動アクセスを検知・排除し、サーバー負荷を軽減する |
| Freeプランでは高度な攻撃に対処できない | 現状体制では大規模攻撃への対応手段がなく、停止時の対応工数は推定◯時間 |
費用対効果の書き方の例: 「Cloudflare Pro の月額$25（年間$240〜$300）に対し、セキュリティインシデント1件の対応工数は推定8〜16時間（時給換算で2〜5万円）。1件の発生を防ぐだけで年間費用を回収できる計算になります」。
ここまでの5項目は、どんなIT投資にも共通する骨格です。案件が具体的になるほど承認者の確認したいことが増え、骨格の各項目はさらに枝分かれします。Cloudflare Pro の導入を例にその展開を書き出すと8項目になり、テンプレートと各項目の書き方は「IT投資の稟議書が通らない理由と、承認される8項目の書き方」で解説しています。技術用語の言い換え早見表もあわせて参照してください。
実例② サーバー新規構築（VPS移行）
物理サーバーの老朽化は、IT担当者には危機感があっても、承認者には「動いているのに買い換える理由がわからない」と感じられることが多い案件です。「老朽化」を「リスクの上昇」として数字で示すことが翻訳のポイントになります。
| 技術的な書き方 | 経営語への翻訳 |
|---|---|
| 物理サーバーが老朽化したためVPSに移行したい | 障害発生時に全業務が停止するリスクを回避するための設備更新 |
| サーバーのMTBFが低下している | 購入から◯年が経過し、製品寿命の観点から故障確率が高い状態にある |
| VPSはスペックを柔軟に変更できる | 業務量の増減に合わせて費用を調整できる（使わないスペック分の固定費が発生しない） |
| 移行後はハードウェア保守不要 | サーバー故障時の交換・修理対応がなくなり、IT担当者の緊急対応負担が減る |
VPS（仮想専用サーバー）とは？ 物理的な1台のサーバーを仮想的に分割して使う方式です。自社専用のスペックで運用しながら、物理サーバーの保守・交換コストを外部に委ねられます。ハードウェア障害が自社設備の問題ではなくなる点が、稟議における「リスク低減」の根拠になります。
サーバー構築稟議書の完全版テンプレートは「VPS・サーバー構築稟議書の書き方とテンプレート」を参照してください。
実例③ セキュリティツール（EDR・ウイルス対策）導入
セキュリティツールの稟議書は、IPAの統計データを活用できる数少ないケースです。自社の実数が取れない場合でも、業界全体のデータを参照できます。
| 技術的な書き方 | 経営語への翻訳 |
|---|---|
| EDRを導入してエンドポイントの保護を強化したい | ウイルス・ランサムウェアによる業務停止を防ぐ検知・隔離システムを設置する |
| 既存のアンチウイルスでは未知の脅威に対応できない | 従来型ウイルス対策では検知できない攻撃が増加しており、現状体制に死角がある |
| 年額◯円 | IPA調査では中小企業の平均被害額が73万円（2024年度・調査全体 n=4,191）。この金額を保険料として年額◯円と比較できる |
EDRとは？ 「Endpoint Detection and Response」の略で、PCやスマートフォンなどの端末（エンドポイント）でウイルス・不審な動作を検知し、即時に隔離・対応する仕組みです。従来のウイルス対策ソフトが「既知の脅威をパターンマッチで検知する」のに対し、EDRは「不審な動作の流れを検知する」点が異なります。稟議書では「既存対策の死角を埋めるシステム」と表現すると伝わりやすくなります。
また、デジタル化・AI導入補助金2026（旧称：IT導入補助金。公式: https://it-shien.smrj.go.jp/）には「セキュリティ対策推進枠」があります。交付申請にはIPA「SECURITY ACTION」の自己宣言IDが必要です。稟議書と補助金申請を並行して検討する場合は、公式サイトで最新の枠・条件を確認してください（補助率・補助上限額は変動するため、本記事では記載しません）。
セキュリティ予算稟議書の完全版は「情報セキュリティ対策の稟議書テンプレート」で解説しています。
IT担当者向け稟議書テンプレート（記入ガイド付き）
下記のテンプレートは、5項目の各欄に経営語への翻訳ガイドを付記しています。自分の数字と状況を記入ガイドに沿って入れることで稟議書の骨格が完成します。
【IT担当者向け稟議書テンプレート】
（出典：InfraDB / infradb.dev）
件名: ○○の導入について
━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 申請目的
━━━━━━━━━━━━━━━━━━━━━━━━━━━
[翻訳ガイド: 「何の業務が改善するか」「何のリスクが減るか」で書く]
→ 記入例: 「弊社Webサイトへの攻撃増加に対し、サービス停止リスクを低減するため、
セキュリティ機能を強化する○○の導入を申請します」
━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. 現状の問題
━━━━━━━━━━━━━━━━━━━━━━━━━━━
[翻訳ガイド: 「現状のまま放置すると○○が止まる/○万円の損失が出る」で書く]
→ 記入例: 「現状体制では大規模攻撃への対応手段がなく、
サービス停止時の影響範囲は○○（取引先◯社、売上影響額◯万円試算）」
※ 数字が入手できる場合は実数を入れる。
難しい場合は「推定」「試算」と明記した上で計算根拠を示す。
━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. 提案する解決策
━━━━━━━━━━━━━━━━━━━━━━━━━━━
[翻訳ガイド: なぜこの選択肢か。他の選択肢との比較を1行で書く]
→ 記入例: 「○○（製品名）を選定。同カテゴリ製品との比較では、
コスト・導入スピード・保守負担の観点から最適と判断（別紙比較表参照）」
※ 「別紙比較表」を添付すると、④費用の妥当性の説明が省略できる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. 費用（初年度／5年合計）
━━━━━━━━━━━━━━━━━━━━━━━━━━━
初期費用: ○円
月額: ○円 × 12ヶ月 = ○円/年
5年合計: ○円
[翻訳ガイド: 対策しなかった場合のリスク額と並べる]
→ 記入例: 「月額○円 / 年額○円。インシデント1件の平均復旧費用○万円と比較すると、
年間費用は○回分のリスクヘッジに相当する」
━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. 導入しなかった場合のリスク
━━━━━━━━━━━━━━━━━━━━━━━━━━━
[翻訳ガイド: 「何が止まるか」「その影響範囲（売上・取引先・復旧日数）」を書く]
→ 記入例: 「現状維持の場合、○○が発生した際に業務が最大○日停止する見込み。
取引先◯社への影響と、復旧対応に伴う工数（推定◯時間）が発生する」
※ 自社データが取れない場合は、業界団体・省庁の公開データを根拠に引用する。
IPA の中小企業セキュリティ調査等は稟議書で引用できる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━
承認をお願いします。
━━━━━━━━━━━━━━━━━━━━━━━━━━━記入のポイント
- 数字の根拠を先に確認する: 「◯万円試算」と書くための計算根拠を、提出前に自分でも言えるようにしておく。差し戻し後の口頭説明で必要になります
- 技術用語の初出には1行の説明を添える: 稟議書本文に「WAF（不正アクセスの自動遮断システム）」のように括弧書きで補足する
- リスク欄が埋まらない場合はデータを引用する: IPA の中小企業調査など、省庁・業界団体の公開データは稟議書で引用できます
- 承認後の動きを書いておく: 「承認後、翌月1日から切り替え」のように導入スケジュールを一行書くと、承認者が「次に何が起きるか」を把握できます
よくある質問：稟議書を出す前と出した後の疑問
差し戻しは「内容の失敗」ではなく「翻訳が足りていない」サインです。差し戻しコメントを元に、どの項目の経営語翻訳が足りなかったかを確認すれば修正できます。
Q: 稟議書と稟議は何が違うか？
「稟議」は上位者に決裁を仰ぐプロセス全体を指します。「稟議書」はそのプロセスで使う書類です。口頭で稟議を通す文化の会社でも、金額や継続費用が発生する契約では書面化を求められることがあります。後から「書類がない」と問われる場面を避けるためにも、書いておく方がリスクは低くなります。
Q: 稟議書と提案書は何が違うか？
提案書は社外向けに新しいビジネスや契約を提案する文書です。稟議書は社内向けで、既存の業務運営に必要な支出の承認を求める文書です。社内プロジェクトのIT投資承認には稟議書を使います。VPS移行の場合の社内提案書については「VPS移行の提案書テンプレート」も参考にしてください。
Q: 稟議が差し戻されたらどうするか？
差し戻しコメントを確認して、5項目のうちどの翻訳が足りなかったかを特定します。「本当に必要？」は⑤リスク提示の不足、「他の方法は？」は③提案内容の比較不足、「費用が不明確」は④費用内訳の不足というパターンが多くなります。
差し戻しは自分の判断の失敗ではありません。どの翻訳が届かなかったかを示す診断結果として読めば、次に直す場所が決まります。
Q: 口頭の許可があれば稟議書は不要か？
会社の規程によります。ただし金額が一定を超える場合や、継続費用が発生するSaaSサービスの契約は書面化が求められることが多いです。口頭許可で進めた後に「正式な書類はどうなっているか」と問われる場面もあるため、書いておく方がリスクが低くなります。SaaS月額費用の稟議書については「SaaS月額費用の稟議書テンプレート」を参照してください。
Q: 金額が小さい場合でも稟議書は必要か？
社内の規程で定められた承認フローに依ります。一般的には月額数千円のSaaSでも、継続課金が発生する場合は書面承認を求める会社が多いです。小さい金額の場合は、個別に稟議書を書くより、ツールスタック全体を一覧化して月1回まとめて承認を取るフローを整備する方が効率的です。
稟議書が通らないのは、あなたの説明力の問題ではなく、技術と経営のあいだに翻訳者がいなかっただけです。テンプレートはその翻訳を代行するために作りました。
自社の状況に合わせたカスタマイズや、稟議書の構成についての個別相談は [email protected] からどうぞ。