提案書に書くAI利用の申告項目｜入札で聞かれる前に

「提案書にAIを使ったと書くと、手を抜いたと思われませんか」「入札の書類に申告する欄が無いのですが、こちらから書くべきでしょうか」——公共の案件や大手の案件に提案を出している会社から、ここ数か月で急に増えた問いです。迷う原因は、書くか書かないかの二択で考えていることにあります。申告は、使ったと名乗る欄ではなく、どこに使い、どこを人が確かめたかを示す欄です。この記事では、提案書に置く申告の項目と、それを組み立てる手順を、審査する側がすでに公開している観点から逆算して整理します。

「書くと手を抜いたと思われないか」で止まっている

提案書の作成にAIを使っている会社は、すでに多数派に近づいています。ところが、それを書類に書くかどうかは、会社によってばらばらです。判断を決めているのは方針ではなく、相手の反応に対する予想です。書けば安く見られるのではないか、書かなければ後で問題になるのではないか。どちらも根拠のない予想なので、担当者ごとに答えが変わります。

この迷いが厄介なのは、社内で決着が付かないまま提出日が来ることです。営業は書きたくない、情報システムは書いたほうがよいと言う、法務はどちらとも言わない。結果として、その案件の担当者の裁量で決まります。同じ会社が、案件ごとに違う態度で出している状態が一番まずい形です。後から一方の案件だけを問われたとき、なぜこちらには書いてこちらには書かなかったのかを説明できません。

決着を付けるには、予想ではなく材料が要ります。幸い、材料はすでに公開されています。審査する側が何を見ているかは、政府が自ら文書にして出しているからです。次の節で、そこから逆算します。

聞かれる前に変わっていること——調達の側は、もう項目を持っている

デジタル庁は、行政の進化と革新のための生成AIの調達・利活用に係るガイドラインを公表しています。2026年6月に2.0版が決定され、2.0版の内容は2026年9月1日から施行されています。AIガバナンスの枠組みにあたる部分は同年7月1日から先に適用されており、初版は2025年5月に運用が始まっていました。つまり、この2週間ほどの間に、府省の側の基準は一段更新されたばかりです。

ここで先に断っておく必要があります。このガイドラインは、政府が生成AIのシステムそのものを調達するときの決まりであって、AIを使って作った提案書に申告を義務づけるものではありません。対象も、入力がテキストと音声、出力がテキストと画像と音声である生成AIシステムが原則で、機微な情報を扱うシステムは対象外だと明記されています。それでも読む価値があるのは、審査する側が何を気にしているかが、そのまま項目の形で書かれているからです。

具体的には、別添として3つのシートが用意されています。高リスク判定シート、調達チェックシート、契約チェックシートです。調達チェックシートは、生成AIを調達する際に事業者への要求事項として仕様書等に盛り込むべき項目を整理したもので、ガバナンスの項目、開発と運用の過程に関する要件、生成AIシステム自体の要件の3群に分かれ、丸数字で21番まで並んでいます。提案を出す側にとっては、いずれ自分たちが答えることになる質問の一覧として読めます。

高リスクの判定軸に「人の判断を経た利活用」が入っている

3つのシートのうち、提案を出す側がまず読むべきは高リスク判定シートです。これは、その案件を高リスクとして扱い、助言を求めるべきかどうかを各府省が判定するための物差しで、勘案する観点が3つ示されています。生成AIを使う業務の性格、利用の範囲、そして出力結果を政府職員などの判断を経て活用するかどうかの3つです。

3つ目に注目してください。ここが、申告の書き方を根本から変えます。人の判断が入っているかどうかが、リスクの高さを決める要素として明示されているということは、人の確認工程を書けるなら、それは不利な情報ではなく有利な情報だということです。使ったかどうかだけを書いた申告は、この観点に何も答えていません。だから、書いても評価が上がらず、むしろ不安だけを残します。

同じガイドラインには、府省の職員に向けた利活用ルールのひな形も付いています。そこに並ぶ理解すべき事項には、生成AIの出力に基づいて行われた判断についての説明責任を理解すること、出力結果の正確性や根拠や事実関係を必要に応じて確認すること、第三者の著作権などの侵害の有無を含めて問題がある出力でないかを確認し、問題点は必ず加除修正の上で利用することが挙げられています。使う側に求められているのは、使わないことではなく、確かめたと言えることです。提案書の申告も、同じ形に合わせれば通ります。

書かないと起きること

では、書かないままにするとどうなるか。起きることは3つあります。1つ目は、質問回答の期間や、契約の直前に個別に聞かれることです。聞かれてから答える場合、社内で材料を集める時間がありません。準備なしで出す答えは、必ず曖昧になります。曖昧な答えは、追加の質問を呼びます。

2つ目は、検収や納品の場面で問題になることです。成果物にAIを使ったこと自体が問題になるのではなく、使ったことを前提とした確認が行われていなかった、という形で問題になります。相手の側が後から知った場合、隠していたのではないかという疑いが、事実関係の確認より先に立ちます。この疑いは、説明では消えにくいものです。

3つ目は、社内に基準が残らないことです。案件ごとに担当者が判断していると、次の案件でまた同じ議論をします。書く形を一度決めてしまえば、以降は埋めるだけの作業になります。申告欄を作る本当の効果は、相手への説明より、社内の判断を1回で終わらせることのほうにあります。

書きすぎると起きること

逆に、書きすぎたときに起きることも見ておきます。よくあるのは、方針の文書をそのまま提案書に貼り付けてしまう形です。自社のAI利用方針を丸ごと載せると、案件と関係のない約束まで書いたことになります。提案書に書いたことは、その案件での約束として読まれます。守る範囲が広がるほど、守れなかったときの説明が増えます。

次に多いのが、確認の工程を実態より手厚く書いてしまう形です。全ての出力を複数人で確認していると書けば、印象は良くなります。ところが契約チェックシートには、事業者が期待する品質を満たすための取組を履行する義務についての取り決めが挙げられており、書いたことは履行の対象として読まれる余地があります。実態より手厚い記述は、自分で自分の義務を増やす行為です。

3つ目は、根拠の提出を求められることです。ガイドラインの調達チェックシートには、説明可能性の確保と検証可能性が項目として並んでいます。確認したと書けば、どう確認したのかを示す資料を求められる可能性があります。出せない記録に基づく記述は書かない、というのが安全な線です。書かないと決めた項目については、聞かれたときに答える用意だけをしておきます。

申告は「使ったか」ではなく「どこに、どこまで」で書く

ここまでを踏まえると、書く形は決まります。使ったかどうかの一文ではなく、工程と範囲と確認で書きます。申告欄に入れる項目は5つです。どの用途に使ったか、どの範囲まで使ったか、人がどの工程で確認したか、入れたデータをどう扱ったか、再委託先のAI利用をどう把握しているか。以下の表が、それぞれの欄に何を書き、書かなかったときに何を聞かれるかの対応です。

申告欄の項目	書く内容	書かないと聞かれること
用途	提案書のどの部分に使ったかを、工程の名前で書く	全体を生成したのか、一部なのか
範囲	下書きまでか、構成までか、図表の作成までか	どこからが自社の判断なのか
人の確認工程	誰が、何を見て、何を直したか	出力をそのまま出していないと言える根拠
データの扱い	入れた情報の区分と、学習に使われない設定かどうか	貴社の情報を入れたのか、それはどこへ行ったのか
再委託先	協力会社のAI利用を把握しているか、条件を課しているか	自社だけの話として書いた理由

この5つは、思いつきで並べたものではありません。契約チェックシートが取り決めるべき項目として挙げているのは、入力に関する取り決めとして学習の有無やデータの保存方法、出力に関する取り決めとして一定の保証と権利の帰属、成果物の定義と権利の帰属、そしてインシデントが起きたときの対応義務とその範囲です。相手が契約で決めたい項目と、こちらが先に書いておく項目は、そろえておくほど手戻りが減ります。

並べる順番にも意味があります。用途と範囲は事実の記述で、人の確認工程は取組の記述、データの扱いと再委託は体制の記述です。事実から書き始めて、取組、体制の順に並べると、読む側が判断しやすくなります。逆に体制の話から書き始めると、何をしたのかが最後まで分からない文書になります。

手順1 提案書のどこにAIが入ったかを工程名で洗い出す

では実際に組み立てます。最初にやるのは棚卸しです。ここでつまずく会社が多いのは、使った本人が使ったと認識していないからです。文章の下書き、構成案の作成、過去案件からの要約、表の整形、図の生成、誤字の確認。作業の名前で聞かないと、使ったかどうかの質問には「使っていません」という答えが返ってきます。

洗い出しの単位は、提案書の章立てではなく作業の工程にします。第3章に使ったという書き方は、読む側に何も伝えません。構成案の作成に使った、という書き方なら、何が自動で、何が人の手なのかが分かります。工程の名前は、社内で普段使っている呼び方をそのまま使うのが続けるこつです。きれいな用語に直すと、次の案件で誰も同じ名前を思い出せません。

この4つの手順は、提案書を書き終えてから振り返るのではなく、書きながら埋めます。後から思い出して書いた申告は、必ずどこかが抜けます。作業の記録をその場で1行残す習慣があれば、申告欄は数分で埋まります。

手順2 工程ごとに、人が確かめた範囲を添える

2つ目の手順が、この記事で最も重要な部分です。高リスクの判定軸に人の判断が入っていた以上、確認の記述は申告の中心になります。書く内容は3つだけです。誰が見たか、何を見たか、何を直したか。肩書きではなく役割で書き、見た対象は文書の部位で書きます。

ここで差が出るのは、全部を見たのか、抜き出して見たのかの区別です。実務では、全部を見ていない工程のほうが多いはずです。それを全部見たと書くと、前の節で触れたとおり自分の義務を増やします。抜き出して見たなら、どういう基準で抜き出したかまで書きます。確認の量ではなく、確認の設計を書くほうが、読む側の納得は得やすくなります。

直した内容も1行で足します。事実関係を直した、数値の出どころを差し替えた、表現を社内の基準に合わせた。どれも短い記述で構いません。ガイドラインのひな形が、問題点は必ず加除修正の上で利用することと書いているとおり、確認したという記述と、直したという記述は対になって初めて意味を持ちます。見たが何も直さなかった場合は、そう書いて構いません。ただしその工程が全体のどれくらいを占めるかは添えておきます。

手順3 入れたデータと、学習に使われない設定を書く

3つ目は、入力側の話です。相手が最も気にするのは、自分たちが渡した資料がどこへ行ったかです。提案の準備段階で受け取った資料、打ち合わせの記録、公開されていない仕様。これらをAIに入れたかどうかは、はっきり書きます。入れていないなら、入れていないと書くだけで相手の疑問は1つ消えます。

入れた場合は、扱いを書きます。書く内容は、入力が学習に使われない設定であること、保存の期間、そして誰が見られる状態かの3つです。ガイドラインの契約チェックシートも、入力に関する取り決めとして学習の有無とデータの保存方法を挙げています。あわせて、利活用ルールのひな形には、約款型のクラウドサービスは原則として機密を要する情報を扱えないという理解が挙げられており、国外のサーバーを使う生成AIの場合に現地の政府によるデータの検閲や接収を受ける可能性があることの理解も並んでいます。

この2点は、提案書に長々と書くものではありません。ただし、どの契約形態のサービスを使っているかは1行で書いておく価値があります。個人の申込みで使える形のサービスと、法人の契約で使うサービスとでは、相手の受け取り方がまったく違います。社内で使ってよいサービスの一覧を先に決めておけば、案件ごとに調べ直す作業は要らなくなります。

手順4 再委託先のAI利用まで確かめる

4つ目は、自社の外側です。制作や執筆を協力会社に出している場合、その会社がAIを使っているかどうかは、自社の申告の一部になります。ガイドラインの体制図には、サプライチェーンに由来するリスクも考慮する旨の注記が付いています。相手にとっては、直接の契約相手である自社が答える立場です。協力会社の話だから分かりません、では通りません。

実務では、把握の度合いを3段階で書き分けるのが現実的です。条件を課して確認まで取っている、聞いてはいるが記録は取っていない、把握していない。把握していない場合に、把握していると書かないことがいちばん大事です。後で協力会社の側から別の説明が出ると、自社の申告全体の信用が落ちます。

把握していないと書くのは不利に見えますが、そこに改善の予定を1行添えられるなら、むしろ誠実な記述として読まれます。次回の契約更新でAI利用に関する条件を追加する予定である、といった書き方です。今できていないことを、いつまでに、どう変えるかまで書けば、書いた側の管理の姿勢が伝わります。ただし、書いた予定は次の案件で聞かれます。守れる予定だけを書いてください。

実務仕様 提案書に置く申告欄の書式

ここまでの5項目を、実際の紙面に落とします。置き場所は、提案書の本編ではなく巻末の付記か、体制の章の末尾が扱いやすくなります。本編に置くと、提案の内容とAIの話が混ざって読みにくくなるためです。分量は文章で10行前後、表にするなら5行1枚に収めます。長い申告は、読まれずに疑問だけを残します。

型として示しましたが、そのまま使わないでください。実態に合わない一文が1つでも混ざると、申告全体の信用が下がります。とくに4行目と5行目は、会社によって答えが変わります。自社の状況に合わせて書き換えるか、当てはまらない行は削って構いません。削る判断ができることのほうが、5行そろっていることより大切です。

表の形で出す場合は、左の列に項目名、右の列に記述を置きます。項目名は、用途、範囲、確認、データ、再委託の5語で足ります。読む側が探しているのは文章ではなく該当する欄なので、見出し語をそろえておくと照合が速く終わります。複数の案件に同じ形で出していけば、社内の資産にもなります。

不利になるのは使ったことではなく、書き方

申告で損をする書き方には、共通の型があります。ひとつは、AIを全面的に活用していますという自己宣伝の文になっている形です。提案の場で求められているのは能力の証明ではなく、管理の状態の説明です。宣伝として書かれた申告は、確認の記述が薄くなる傾向があります。読む側は、そこを見ています。

もうひとつは、逆方向の書きすぎです。一切使っておりません、と書いてしまう形。実際には誤字の確認や表の整形で使っていることが多く、後から食い違いが出ます。使っていないという記述は、使っていないことを証明し続ける義務を自分に課します。工程を限って書くほうが、守りやすい約束になります。

• 自社のAI利用方針の全文を提案書に貼り付け、案件と無関係の約束まで書いてしまう
• 全ての出力を複数人で確認していると書きながら、記録が残っていない
• 生成AIを一切使用していないと断言し、誤字の確認や表の整形で使っていた実態と食い違う
• 協力会社の利用状況を確かめないまま、全社的に管理していると書く
• 使ったサービスの名前だけを並べ、どの工程に使ったかを書かない

並べてみると、どれも実態と記述のずれから起きています。申告の質は、文章のうまさではなく、実態を書ける状態かどうかで決まります。書けない項目があるなら、それは書き方の問題ではなく、社内の記録の問題です。そちらを先に直すほうが早く終わります。

審査で追加で聞かれたときに出せるもの

申告を書いた結果、追加の質問が来ることはあります。来たときに何を出せるかを、先に決めておきます。求められる可能性が高いのは3つです。確認の記録、利用したサービスの契約の形が分かる書面、そして社内の利用の決まりです。3つとも、案件が始まってから作ると間に合いません。

確認の記録は、凝った様式が要るわけではありません。日付、工程、確認した人、直した内容の4列で足ります。ガイドラインの調達チェックシートに検証可能性が項目として並んでいることを思い出してください。後から確かめられる状態になっているかどうかが、そのまま項目になっています。記録の形よりも、記録が存在することのほうが先です。

社内の利用の決まりについては、全文を出す必要はありません。その案件に関係する部分だけを抜き出して出せるよう、章立てを整理しておきます。あわせて、インシデントが起きたときの対応手順も聞かれることがあります。契約チェックシートには、問題が起きたときの対応義務とその範囲について、被害を最小限に食い止めるためや原因を特定するための情報やデータの提供を含む形で取り決める旨が挙げられています。止める手順と、連絡する先が決まっていれば、その場で答えられます。

ミニ用語解説 調達の場で出てくる言葉

提案の準備で出てくる言葉のうち、意味を取り違えると申告の中身がずれるものを整理しておきます。どれも一般的な用語ではないので、社内で共有しておく価値があります。

このうち、提案を出す側が日常で意識すべきは高リスク判定と約款型のサービスの2つです。前者は自社の申告の書き方を決め、後者は使ってよい道具の線を決めます。残る3語は、相手の書類に出てきたときに意味が取れれば十分です。

なお、これらの項目の土台になっているのがAI事業者ガイドラインです。調達チェックシートの1項目めは、このガイドラインの共通の指針を守ることを求めています。総務省と経済産業省が公表しているもので、最新版は2026年3月31日の第1.2版です。毎年のように更新される文書なので、参照するときは版の日付まで書く習慣をつけておくと、後で食い違いません。

申告書を作る作業のうち、AIに渡せるのはどこまでか

申告欄を作る作業そのものを、AIに手伝わせることもできます。ただし渡せる範囲は限られます。渡してよいのは、集める作業と、そろえる作業までです。過去の提案書から同じ工程の記述を拾ってくる、書式の5項目に対して埋まっていない欄を指摘する、長い記述を指定の行数に収める。ここは向いています。

渡してはいけないのは2つあります。1つは、何を書き、何を書かないかの判断です。前の節で見たとおり、書いたことは約束として読まれます。約束の範囲を決める行為は、その約束を守る立場の人が決めるべきものです。もう1つは、実態の確認です。確認の工程が実際にあったかどうかを、記録を見ずにAIに書かせると、もっともらしい記述が出てきます。これが最も危険です。

実務としては、AIに書かせるときに必ず根拠の欄を一緒に出させる形にします。この記述の元になった記録はどれか、という欄です。根拠の欄が埋まらない記述は、そのまま削ります。人が確認する範囲も先に決めておきます。5項目のうち、確認工程とデータの扱いと再委託の3つは、必ず人が原本に当たって確かめる、といった決め方です。決めておかないと、締切が近い案件から順に省略されます。

提出前に確かめる項目

最後に、出す直前の確認です。5項目を書いたあと、提出前に見るのは書きぶりではなく、実態との対応です。1つでも対応が取れない記述があれば、その行は削ります。削った結果、申告が3行になっても構いません。書いていないことは聞かれれば答えられますが、書いて違っていた場合は説明が難しくなります。

• 書いた工程が、実際の作業の記録と一致しているか
• 確認の記述について、誰が見たかを役割で書けているか。肩書きだけになっていないか
• 全部を見たと書いた工程が、本当に全部見たものか
• 相手から受け取った資料を入力していないと書いた場合、その根拠を示せるか
• 協力会社について書いた内容を、協力会社の側も同じように説明できるか

あわせて、案件をまたいだときの整合も見ます。同じ体制で受けている案件に、違う内容の申告を出していないか。申告は1件ごとの文書ですが、読まれ方は会社単位です。過去に出した申告を1か所にまとめておくと、この確認が数分で終わります。

• 申告欄は提案書の巻末か体制の章の末尾に置く。本編に混ぜると提案の筋が読みにくくなる
• 書いた予定は次の案件で聞かれる。守れる予定だけを書く
• 使ってよいサービスの一覧を社内で先に決めておくと、案件ごとに調べ直す作業が消える
• 確認の記録は日付・工程・確認した人・直した内容の4列で足りる。様式より存在が先

まとめ

提案書にAIの利用を書くかどうかは、印象の問題ではありません。決めているのは、どこに使い、どこを人が確かめたかを、実態に基づいて書ける状態にあるかどうかです。政府の調達のルールは、出力を人の判断を経て使うかどうかを、リスクの高さを測る観点のひとつに置いています。確認の工程を書けるなら、申告は不利な材料ではありません。逆に、実態より手厚く書いた記述は、自分で自分の義務を増やします。足りないのは書き方の工夫ではなく、書ける材料を作業のときに残す習慣です。まずは直近で出した提案書を1件選び、この記事の5項目を埋められるか試してみてください。埋まらない欄が、次に整える場所になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。