ローカルLLM PoCの稟議書テンプレート。セキュリティ事故を根拠にした費用対効果の書き方と、通る稟議の7項目
「ローカルLLMを試したいが、稟議が書けない」。情報システム部門や企画部門からこの相談を受けることが増えました。技術的にはOllamaを入れれば今日から動くのに、社内で費用を承認してもらう段になると、何をいくらで、何が得られるのかを一枚にまとめられず止まります。本記事は、ローカルLLMや社内専用の生成AI環境のPoC（概念実証）を稟議にかけるときの書き方を、記入例つきのテンプレートとして整理したものです。なお、本記事は「稟議書を生成AIに書かせる方法」ではなく、「生成AIのPoCを稟議に通す書き方」を扱います。
稟議で問われるのは金額だけではありません。「なぜ今か」「失敗したらどうするのか」「誰が面倒を見るのか」に先回りして答えている稟議書は通り、答えていない稟議書は差し戻されます。本記事では、通らない稟議の型を先に押さえ、通る稟議の7項目を記入例とともに示し、最後にテンプレート全文と添付資料、提出前のチェックリストをまとめます。
この記事の要点
- 通らない稟議には3つの型があります。本番費用を一括で求める、効果が「業務効率化」のような定性的な言葉で止まっている、撤退基準がない、の3つです
- 通る稟議は7項目で構成します。目的と対象業務、現状の工数と課題、効果の仮説、段階投資の費用、リスクと対策、撤退基準、体制とスケジュールです。今回承認を求めるのは検証費用だけだと明記します
- セキュリティ事故を根拠にする場合は、他社の事故そのものではなく、自社で扱うデータ区分と現行ルールの穴を示します。「禁止のまま」も安全ではない点を併記します
- 費用欄は、社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）、ミニ検証（約30万円・2週間）、業務PoC、本番構築の4段に分け、段階ごとに承認を取り直す前提で書きます
- 生成AIプロジェクトの少なくとも30%がPoC後に頓挫するという予測があります。撤退基準と運用担当者を稟議書に書いておくことが、PoC止まりを防ぐ最短の方法です
通らない稟議の3つの型
差し戻される稟議書には、ほぼ決まった型があります。自分の稟議書がどれかに当てはまっていないかを先に確認してください。
| 型 | 稟議書に書かれていること | 承認者が抱く疑問 |
|---|---|---|
| 本番費用を一括で求める | 「GPUサーバー一式と構築費で1,500万円」 | 効果が出るか分からないものに、なぜ最初から全額を出すのか |
| 効果が定性的 | 「業務効率化と情報漏洩リスクの低減が見込める」 | 何がどれだけ減るのか。検証でそれをどう確かめるのか |
| 撤退基準がない | 「検証結果を踏まえて本番化を判断する」 | どの数字を下回ったらやめるのか。やめる判断を誰がいつするのか |
3つに共通するのは、承認者が「承認した後に起きること」を想像できない点です。段階投資にして今回の承認範囲を検証費用に限定し、効果を検証で確かめられる数字に落とし、撤退基準を先に書いておけば、承認者は「検証費用の範囲で、失敗しても止まれる投資」として判断できます。
ローカルLLMの場合、ここに「機材をどうするか」という固有の論点が加わります。買ってから置けなかった、速度が出なかったという失敗を避けるために、機材を買わずに検証する段階を最初に置くのが現実的です。段階の分け方は『ローカルLLM PoCの費用・期間・進め方』で整理しているので、稟議書の費用欄はこの3段階に合わせて書きます。
通る稟議の7項目
通る稟議書は、次の7項目で構成します。順番も重要です。承認者は「何のために」「今どう困っていて」「何が良くなり」「いくらかかり」「何が危なくて」「ダメなときはどうし」「誰がやるのか」の順に読みます。
| # | 項目 | 書くこと | 一言で |
|---|---|---|---|
| 1 | 目的と対象業務 | 対象業務を1つに絞り、判断したいことを書く | 何のために |
| 2 | 現状の工数と課題 | 現状の処理件数・1件あたり時間・今のやり方の問題 | 今どう困っているか |
| 3 | 効果の仮説 | 検証で確かめられる形の数字 | 何が良くなるか |
| 4 | 段階投資の費用 | 4段に分け、今回承認を求める範囲を明記 | いくらかかるか |
| 5 | リスクと対策 | 情報漏洩・誤回答・著作権・依存・運用停止と対策 | 何が危ないか |
| 6 | 撤退基準 | 精度・コスト・運用の合格ラインと判断ルール | ダメなときはどうするか |
| 7 | 体制とスケジュール | 推進担当・評価者・情シス窓口・運用担当の当て | 誰がやるか |
以下、項目ごとに書き方と記入例を示します。記入例は架空の中堅企業（従業員120人、取引先からの受託データを扱う）を想定したものです。
1. 目的と対象業務
目的は「ローカルLLMを試す」ではなく「この業務でこの判断をする」と書きます。対象業務は1つに絞ります。複数の業務を並べると、どれも中途半端な検証になり、判断ができなくなります。
記入例
本件の目的は、取引先から受領した仕様書・図面の社内検索と要約を、社外にデータを送信しない生成AI環境で行えるかを検証することである。対象業務は設計部門の「過去案件の仕様書検索」に限定し、他の業務への展開は本検証の結果を踏まえて別途判断する。
「社外にデータを送信しない」を目的に含めるかどうかは、後述するセキュリティ事故を根拠にする書き方と対応します。対象業務を絞るときの考え方は『社内向け生成AI導入の手順2026』のStep1を参照してください。
2. 現状の工数と課題
現状は数字で書きます。月あたりの件数、1件あたりの所要時間、担当者数の3つがあれば、効果の仮説が計算できます。課題は「時間がかかる」だけでなく、「今のやり方では何が起きているか」を書きます。
記入例
設計部門では、過去案件の仕様書を参照する作業が月およそ200件発生しており、1件あたり平均30分（検索15分、該当箇所の読み取り15分）を要している。担当者は8名。現状はファイルサーバーの全文検索と目視に頼っており、担当者によって所要時間に3倍の差がある。また、一部の担当者が私用アカウントの生成AIに仕様書の一部を貼り付けて要約していた事実が、社内ヒアリングで判明している。
最後の一文のように、現状の課題の中に「現行ルールの穴」を事実として書いておくと、次のセキュリティの論点が自然につながります。
3. 効果の仮説
効果は「業務効率化」ではなく、検証で確かめられる計算式で書きます。現状の数字に削減率の仮説を掛け、月あたりの時間に換算します。削減率は仮説なので、検証で測ると明記します。
記入例
検索15分が5分に、読み取り15分が10分に短縮できれば、1件あたり30分が15分となり、月200件で約50時間の削減になる。この短縮幅は仮説であり、検証では実データ50件で所要時間と出力の正答率を測定し、仮説の成否を判定する。
ここで金額換算をするかどうかは社内の慣習によります。金額に直す場合は、時間に社内の標準単価を掛ける形にし、単価の根拠を注記します。効果を大きく見せる必要はありません。検証で確かめられる形になっていることのほうが、承認者にとっては重要です。
4. 段階投資の費用
費用欄は、ローカルLLMの検証と導入を4つの段階に分け、今回承認を求める範囲を明記します。段階ごとの位置づけと費用の目安は次のとおりです。
| 段階 | 答える問い | 期間 | 費用の目安 | 今回の承認 |
|---|---|---|---|---|
| 社内設置の実現性検証 | オフィスにローカルLLMを置いて回せるか | 2週間 | 30万円〜（税別・機材貸出料込み） | 求める |
| モデル選定ミニ検証 | どのモデルが自社データで使えるか | 2週間 | 約30万円 | 求める（同時申請の場合） |
| 業務PoC | この業務で効果が出るか | 1〜2ヶ月 | 一般構成30万円〜、GPUサーバー・RAG基盤込みの費用例で300〜500万円 | 検証結果を見て別途稟議 |
| 本番構築 | 運用体制を含めて本稼働 | 3〜6ヶ月 | 構成により数百万〜1,500万円規模 | 別途稟議 |
記入例
今回承認を求めるのは、第1段階の社内設置の実現性検証（30万円・税別・2週間・機材貸出料込み）と、第2段階のモデル選定ミニ検証（約30万円・2週間）の合計約60万円である。機材は購入せず貸出で行い、貸出料は次段階の費用または機材購入時に充当される。第3段階の業務PoCおよび本番構築の費用は、第1・第2段階の結果を踏まえて別途稟議を起案する。本番構築に進む場合の費用は構成により数百万〜1,500万円規模を見込むが、現時点では幅として示すにとどめる。
本番費用を幅で示しておくことには意味があります。承認者は「検証に60万円を出すと、その先にいくらの話が控えているのか」を知りたいからです。隠すと後で信頼を失い、書き過ぎると今回の承認が重くなります。「幅で示し、別途稟議」が落としどころです。各段階の費用の中身は『ローカルLLM導入費用の相場2026』で開示しています。クラウドAIとの比較を求められる場合は、稼働率と運用人件費を含めた3年TCOで示す必要があり、その計算は『オンプレLLMは本当に安いのか』に沿って別紙にします。
5. リスクと対策
リスク欄は、承認者が想像する不安に先回りする欄です。生成AI固有のリスクを5つに分け、対策とその根拠を対応させます。
| リスク | 何が起きるか | 対策 | 根拠・参照 |
|---|---|---|---|
| 情報漏洩 | 受託データが社外に送信される、または社内で権限外の人に見える | 社外送信しない構成で検証する。検証機は社内LANのみに接続し、インターネットに接続しない。検証後は機材のストレージを完全消去する | 構成図と接続範囲の説明を添付 |
| 誤回答 | 誤った要約や存在しない記述を事実として出す | 出力は担当者が確認してから使う運用とし、検証では正答率を実データで測る | 評価シートを添付 |
| 著作権・契約 | 取引先の資料をAIに入力することが契約上問題になる | 契約書の第三者提供・外部委託条項を法務が確認する。社外送信しない構成はこの確認を軽くする | 法務確認結果を添付 |
| 利用者の依存 | 確認なしに出力を使う、スキルが落ちる | 利用ルールで確認義務と禁止事項を定める | 利用規程の案を添付 |
| 運用停止 | 導入後に維持する人がいなくなる | 運用担当者の当てと保守の範囲を体制欄に書く | 運用担当者の記載 |
ローカルLLMにしても消えないリスクがあることは、正直に書いておくほうが通ります。閉域に置いても推論サーバーの設定不備や社内の権限設計の穴は残るからです。この点は『ローカルLLMは本当に安全か』に整理しており、稟議書では「社外送信のリスクは構成で解消し、社内の攻撃面は運用で管理する」と書き分けます。
6. 撤退基準
撤退基準は、検証の結果どの数字を下回ったら本番に進まないかを、精度・コスト・運用の3つで書きます。「1つでも割ったら止まる」という判断ルールと、判断する人と時期も書きます。
記入例
次の3つの基準のうち1つでも満たさない場合、本番構築には進まず、法人契約のクラウドAI継続または対象業務の縮小を検討する。
- 精度: 実データ50件に対し、担当者の修正なしで使える出力が80%以上
- コスト: 想定利用量での3年TCOが、同等のクラウドAI法人契約を下回る
- 運用: モデル更新・障害対応・精度監視を担う担当者を社内または外部保守で確保できる 判定は検証終了後2週間以内に、設計部門長と情報システム部門長が行う。
80%という数字そのものに意味があるわけではなく、始める前に合格ラインを数字で合意しておくことに意味があります。基準の決め方と、基準を割ったときに「ここまでやったのだから」と進めてしまう力学を防ぐ考え方は『ローカルLLMのPoCで300万円溶かす前に』で扱っています。
7. 体制とスケジュール
体制は4つの役割を名前または部署で書きます。推進担当者、出力を判定する業務担当者、情報システム部門の窓口、導入後の運用担当者の当てです。運用担当者が未定なら「未定」と書き、検証期間中に決めることを明記します。空欄のままにしないことが重要です。
記入例
推進担当: 設計部門 A（兼務、週2日相当） 評価者: 設計部門の担当者3名（評価セットの採点、各2日相当） 情報システム窓口: 情報システム部門 B（持込機器の申請、接続範囲の確認） 運用担当（導入時）: 未定。検証期間中に、内製か外部保守かを含めて決定する スケジュール: 承認後2週間で機材搬入、搬入から2週間で実現性検証、並行してミニ検証、検証終了後2週間以内に判定会議
運用担当者の不在は導入挫折の最大要因であり、稟議の段階で「誰が維持するのか」を問われることが増えています。運用に必要なスキルと3つの体制パターンは『導入したローカルLLM、誰が維持するのか』を参照してください。
セキュリティ事故を根拠にする書き方
昨今は、他社のセキュリティ事故や情報漏洩を背景に「社外につながない独立したシステム」としてローカルLLMを提案する場面が増えています。この根拠の書き方には要点があります。
他社の事故を根拠にしない。「他社で事故があったから」は、承認者にとって自社の話ではありません。書くべきは、自社で扱うデータの区分と、現行ルールの穴です。
記入例
当社は取引先の仕様書・図面など、契約上社外への提供が制限されるデータを日常的に扱っている。現行の生成AI利用ルールは「業務での利用を禁止する」のみで、禁止の実効性を担保する手段がなく、社内ヒアリングでは私用アカウントでの利用が確認された。個人情報保護委員会は2023年に生成AIサービス利用の注意喚起を公表しており、IPAの情報セキュリティ10大脅威2026でも組織向けの脅威としてAI利用をめぐるリスクが挙げられている。禁止を続けても利用は社外の見えない場所に移るだけであり、社外送信しない公式の環境を用意して吸収することが、現実的な対策である。
この書き方には3つの要素が入っています。自社のデータ区分（契約上の制限）、現行ルールの穴（禁止だけで実効性がない事実）、公的資料による裏づけ（注意喚起と10大脅威）です。禁止だけでは私用利用に流れる構造と、公式ルートで吸収する設計は『シャドーAI対策2026』に整理しています。
もう1点、「ローカルLLMにすれば安全」と書かないことです。承認者の中に技術に詳しい人がいれば、必ず「ローカルでも穴はあるのでは」と問われます。「社外送信のリスクは構成で解消する。社内の攻撃面は運用で管理する」と書き分けたうえで、インターネットにつながない構成の作り方は『生成AIをオフラインで使う2026』、残るリスクと対策は『ローカルLLMは本当に安全か』を参考資料として添付します。
費用欄と効果欄で承認者が見ている3つの点
費用欄と効果欄は、承認者が最も時間をかけて読む欄です。見られている点は3つです。
| 見ている点 | 通る書き方 | 差し戻される書き方 |
|---|---|---|
| 今回の承認範囲 | 検証費用に限定し、次の段階は別途稟議と明記 | 本番費用まで一括 |
| 効果の検証可能性 | 現状の数字 × 削減率の仮説 = 月あたりの削減時間。検証で測る方法を併記 | 「効率化が見込める」 |
| 費用の比較対象 | 法人契約クラウドとの3年TCO比較を別紙で用意 | 比較なし、またはクラウドを個人向け料金で比較 |
効果の金額換算を求められたら、削減時間に社内単価を掛けるだけで十分です。生成AI開発全般のPoC費用は公開例で150〜500万円・1〜2ヶ月が中心ですが、ローカルLLMではGPU機材の扱いが費用を左右するため、機材を買わない段階から始めることで初回の承認額を抑えられます。生成AIプロジェクトの少なくとも30%がPoC後に頓挫するという予測を承認者が知っている場合もあるので、「だからこそ撤退基準を先に決めている」と稟議書の中で先回りします。
稟議書テンプレート全文
以下をそのまま社内の様式に写して使えます。角括弧の部分を自社の内容に置き換えてください。
件名: ローカルLLM（社内専用生成AI環境）の導入検証に関する稟議
1. 目的と対象業務 [対象業務]において、[判断したいこと]を検証する。対象業務は[業務名]に限定し、他業務への展開は本検証の結果を踏まえて別途判断する。
2. 現状の工数と課題 [対象業務]は月[件数]件発生し、1件あたり平均[時間]を要している（担当[人数]名）。現状は[現在のやり方]で行っており、[課題]が生じている。また、[現行ルールの穴があれば事実として記載]。
3. 効果の仮説 [作業A]が[時間]から[時間]に、[作業B]が[時間]から[時間]に短縮できれば、1件あたり[時間]の削減、月[件数]件で約[時間]の削減となる。この削減幅は仮説であり、検証では実データ[件数]件で所要時間と正答率を測定して判定する。
4. 費用（段階投資） 今回承認を求める費用: [段階名]（[金額]・税別・[期間]）[および段階名（金額・期間）]、合計[金額]。 機材は購入せず貸出で行い、貸出料は次段階の費用または機材購入時に充当される。 次段階以降（業務PoC・本番構築）は、本検証の結果を踏まえて別途稟議を起案する。本番構築の費用は構成により[幅]を見込む。
5. リスクと対策 情報漏洩: 社外送信しない構成で検証し、検証機は社内LANのみに接続する。検証後は機材のストレージを完全消去する（構成図・接続範囲説明を添付）。 誤回答: 出力は担当者が確認してから使用する。検証で正答率を測定する（評価シートを添付）。 著作権・契約: [対象データ]の取り扱いについて法務が契約条項を確認する。 利用者の依存: 利用規程で確認義務と禁止事項を定める（規程案を添付）。 運用停止: 運用担当者の当てを体制欄に記載する。
6. 撤退基準 次のいずれかを満たさない場合、本番構築に進まず、[代替案]を検討する。 精度: 実データ[件数]件で、修正なしで使える出力が[%]以上。 コスト: 想定利用量での3年TCOが[比較対象]を下回る。 運用: モデル更新・障害対応・精度監視を担う担当者を確保できる。 判定者: [役職]。判定時期: 検証終了後[期間]以内。
7. 体制とスケジュール 推進担当: [部署・氏名・工数]。評価者: [部署・人数・工数]。情報システム窓口: [部署・氏名]。運用担当（導入時）: [氏名または未定。未定の場合は決定時期]。 スケジュール: 承認後[期間]で機材搬入、搬入から[期間]で検証、検証終了後[期間]以内に判定会議。
添付資料: 別紙1 構成図と接続範囲、別紙2 データ取り扱い説明、別紙3 評価シート、別紙4 見積書、別紙5 利用規程案、別紙6 3年TCO比較（求められた場合）
添付資料の一覧と用意する順番
稟議書本体は1〜2枚に収め、根拠は添付に回します。用意する順番は、情報システム部門と法務の確認に時間がかかるものから着手します。
| 別紙 | 内容 | 用意する人 | 備考 |
|---|---|---|---|
| 1. 構成図と接続範囲 | 検証機の設置場所、接続するネットワーク、インターネットに接続しないことの明示 | 検証を依頼する事業者 | 持込機器の申請にも使う |
| 2. データ取り扱い説明 | 検証に使うデータの範囲、保存場所、検証後の消去方法と記録 | 事業者と推進担当 | 返却時の完全消去と消去記録を含める |
| 3. 評価シート | 評価セットの件数、採点軸、合格ライン、採点者 | 推進担当と評価者 | 作り方は『ローカルLLM PoCの評価シート』 |
| 4. 見積書 | 段階ごとの金額と含まれる範囲 | 事業者 | 機材貸出料の充当条件を明記 |
| 5. 利用規程案 | 入力してよい情報、禁止事項、確認義務、相談窓口 | 推進担当と法務 | 既存の情報セキュリティ規程との整合 |
| 6. 3年TCO比較 | 想定利用量、クラウド法人契約との比較、運用人件費込み | 推進担当 | 求められた場合のみ |
社内に設置する機材の条件（電源・設置場所・騒音・ネットワーク）を情報システム部門に説明する必要がある場合は、『ローカルLLMを社内サーバーとして置く前に確認する10項目』を別紙1の補足として使えます。
補助金と契約を稟議に織り込む
費用の根拠として補助金を書く場合は、注意が2つあります。補助金は原則後払いで、交付決定前の発注は補助対象外になるため、検証を補助金で賄おうとするとスケジュールが合いません。検証は自己資金で行い、本番構築を補助金の射程に入れるのが順序です。また、旧IT導入補助金（デジタル化・AI導入補助金2026）は登録済みのITツールが対象で、作り込みのローカルLLM構築は対象外になりやすい点を、稟議書に書く前に確認してください。制度ごとの向き不向きは『ローカルLLM構築に補助金は使えるか』にまとめています。
外部に検証を委託する場合、契約の形も稟議材料になります。JDLAの生成AI開発契約ガイドラインには、秘密保持契約・アセスメント・導入検証・ソフトウェア開発の各段階に対応した契約書のひな形が付属しており、検証と本番で契約を分ける段階投資の考え方と整合しています。法務に「検証と本番で契約を分ける」と説明するときの根拠として使えます。
提出前チェックリスト
提出前に次の項目を確認してください。1つでも空欄があると、その点で差し戻されます。
- 対象業務を1つに絞り、判断したいことを目的に書いた
- 現状を月あたり件数・1件あたり時間・担当者数の数字で書いた
- 効果を計算式で書き、検証で測る方法を併記した
- 今回承認を求める費用を検証費用に限定し、次段階は別途稟議と明記した
- 本番構築の費用を幅で示した
- リスク5項目それぞれに対策と添付資料を対応させた
- 撤退基準を精度・コスト・運用の3つで数字にし、判定者と時期を書いた
- 推進担当・評価者・情シス窓口・運用担当の4役割を書いた（未定なら決定時期を書いた）
- 「ローカルLLMにすれば安全」と書いていない。社外送信のリスクと社内の攻撃面を書き分けた
- セキュリティを根拠にする場合、自社のデータ区分と現行ルールの穴を事実で書いた
- 構成図・データ取り扱い説明・評価シート・見積書を添付した
- 補助金を書く場合、交付決定前の発注が対象外になる点とスケジュールを確認した
まとめ
- 通らない稟議は、本番費用を一括で求める、効果が定性的、撤退基準がない、の3つの型に当てはまります。段階投資・計算式・撤退基準の3つで解消できます
- 通る稟議は7項目で構成します。目的と対象業務、現状の工数と課題、効果の仮説、段階投資の費用、リスクと対策、撤退基準、体制とスケジュールです
- 費用欄は実現性検証（30万円〜・税別・2週間・機材貸出料込み）、ミニ検証（約30万円・2週間）、業務PoC、本番構築の4段に分け、今回の承認範囲を検証費用に限定します
- セキュリティ事故を根拠にする場合は、他社の事故ではなく、自社のデータ区分と現行ルールの穴を事実で書き、公的資料で裏づけます。「ローカルにすれば安全」とは書きません
- 撤退基準と運用担当者を稟議書に書いておくことが、PoC後に頓挫する3割に入らないための最短の方法です
よくある質問
Q. ローカルLLMの稟議では、最初にいくらを申請するのが妥当ですか？
機材を買わずに行う検証費用だけを申請するのが現実的です。社内設置の実現性検証が30万円〜（税別・2週間・機材貸出料込み）、モデル選定のミニ検証が約30万円・2週間で、両方合わせても100万円に届きません。業務PoCと本番構築の費用は、検証結果を踏まえて別途稟議にかけます。本番構築の費用は幅で示しておくと、承認者が先の見通しを持てます。
Q. 効果をどう書けば「定性的」と言われずに済みますか？
現状の数字に削減率の仮説を掛けて、月あたりの削減時間に換算します。「1件30分が15分になれば、月200件で約50時間の削減」のように、計算式が見える形にします。削減率は仮説なので、検証で実データを使って測ると併記します。金額換算を求められたら、削減時間に社内の標準単価を掛け、単価の根拠を注記します。
Q. セキュリティ事故を理由にローカルLLMを提案したいのですが、どう書けばよいですか？
他社の事故そのものではなく、自社で扱うデータの区分（契約上社外提供が制限されるデータなど）と、現行ルールの穴（禁止だけで実効性がない、私用利用が確認されたなど）を事実として書きます。そのうえで、個人情報保護委員会の注意喚起やIPAの10大脅威のような公的資料で裏づけます。「ローカルにすれば安全」とは書かず、社外送信のリスクは構成で解消し、社内の攻撃面は運用で管理すると書き分けます。
Q. 撤退基準には何を書きますか？
精度・コスト・運用の3つです。精度は「実データ50件で修正なしに使える出力が80%以上」のように数字で、コストは「想定利用量での3年TCOがクラウド法人契約を下回る」、運用は「モデル更新・障害対応・精度監視を担う担当者を確保できる」とします。1つでも満たさなければ本番に進まないという判断ルールと、判定者と判定時期を併記します。
Q. 運用担当者が決まっていません。稟議書にはどう書きますか？
「未定」と書いたうえで、検証期間中に内製か外部保守かを含めて決定すると明記します。空欄にすると「誰が維持するのか」で差し戻されます。運用に必要なのはAIの専門知識ではなく、更新・監視・障害対応を回せる体制です。体制の3パターンは運用担当者の記事で整理しています。
Q. 補助金を使う前提で稟議を書いてもよいですか？
検証費用を補助金で賄う前提は避けてください。補助金は原則後払いで、交付決定前の発注は対象外になるため、検証のスケジュールと合いません。検証は自己資金で行い、本番構築を補助金の射程に入れる順序で書きます。旧IT導入補助金は登録済みITツールが対象で、作り込みのローカルLLM構築は対象外になりやすい点も先に確認します。
主な参考資料: 生成AI受託開発の費用相場2026（renue）、Gartnerの生成AIプロジェクト頓挫予測（Intelligent CIO）、JDLA「生成AI開発契約ガイドライン」、IPA「情報セキュリティ10大脅威 2026」、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」、中小企業庁 デジタル化・AI導入補助金2026 公募要領
TodoONadaでは、稟議に添付する構成図・接続範囲の説明・データ取り扱い説明・見積書を、社内設置の実現性検証（30万円〜・税別・2週間・機材貸出料込み）の申込前にお渡ししています。機材のみの短期貸出（1週4.5万円〜・税別）も承っており、貸出料は次の段階の費用や機材購入に充当します。「稟議書のこの欄に何を書けばよいか」という相談だけでも歓迎します。
この記事に関連するサービス
TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。
- ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
- Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
- ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- 生成AI開発のPoC費用の公開例（PoC・プロンプト設計 150〜500万円・1〜2ヶ月） （2026年10月3日確認）
- Gartner予測: 生成AIプロジェクトの少なくとも30%がPoC後に頓挫する（2025年末まで） （2026年10月3日確認）
- JDLA「生成AI開発契約ガイドライン」（秘密保持・アセスメント・導入検証・開発の各段階の契約書ひな形つき） （2026年10月3日確認）
- IPA「情報セキュリティ10大脅威 2026」 （2026年10月3日確認）
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」 （2026年10月3日確認）
- 中小企業庁 デジタル化・AI導入補助金2026 公募要領ページ （2026年10月3日確認）
