ISMAPとは｜政府クラウド調達の評価制度と対応案件の実務

ISMAPとは｜政府クラウド調達の「事前審査済みリスト」

ISMAPは、政府が求めるセキュリティ要求を満たすクラウドサービスを事前に評価し、リストに登録しておく制度です。正式名称は「政府情報システムのためのセキュリティ評価制度」、英語では Information system Security Management and Assessment Program といいます。読み方はイスマップ。

登録の単位は事業者ではなくサービスです。同じ会社でも、申請したサービスだけが評価・登録の対象になります。

調達の現場で起きることは単純です。政府機関等がクラウドを調達する際は、原則としてISMAPクラウドサービスリストに登録されたサービスから選定します。載っていなければ、どれだけ技術的に優れていても候補に入りにくい。だからベンダー側は登録を取りにいきます。ただし実際の調達では、個別の要件や制度上の整理も確認が必要で、リスト掲載だけで選定が決まるわけではありません。

制度の目的と運営体制

目的は、調達のたびに各省庁が個別にセキュリティ評価をやり直す無駄をなくすことにあります。評価を一度まとめて行い、その結果を全省庁で使い回す。言ってしまえば政府調達の「予選」です。

所管と実務運用は分けて理解してください。制度を所管するのは、内閣官房 国家サイバー統括室（NISC）、デジタル庁、総務省、経済産業省の4者です。独立行政法人情報処理推進機構（IPA）は所管官庁ではなく、ISMAPポータルの運用や申請の受付・審査といった制度運用の実務を担います。制度の一次情報は国家サイバー統括室のISMAP解説ページとISMAPポータルにまとまっています。

運用開始は令和2年、つまり2020年6月です（国家サイバー統括室の公表による）。政府の情報システムがオンプレミス前提からクラウド・バイ・デフォルトへ舵を切った流れの中で生まれた制度です。

なぜ調達の前に評価しておく必要があったのか

省庁ごとにクラウドの安全性を審査していた時代は、同じサービスが何度も別々に評価されていました。ベンダーからすれば、提出する資料が調達案件ごとに違う。審査する側も専門人材が足りない。

この非効率を解消するために、評価を先に済ませる方式へ切り替えたわけです。

ISMAPとISMAP-LIUの違い

ISMAP-LIU（ISMAP for Low-Impact Use）は、リスクの小さな業務・情報を扱うSaaSを対象にした枠組みで、2022年11月1日から運用されています。

違いは扱う情報の重要度です。機密性の高い行政情報を扱うならISMAP本体、影響度が限定的なSaaS利用ならISMAP-LIU、という住み分けになります。LIUは低リスク用途を前提とした枠組みで、本体より評価の対象範囲や要求事項が限定されています。

登録サービスの件数は更新のたびに動きます。デジタル庁はクラウドサービスリスト等の更新をお知らせとして公表しており、最新の登録状況は上記の公式リストで直接確認するのが確実です。本記事では件数を固定で示しません。二次情報で見かける数字は集計時点がばらついており、そのまま引くと古い数に乗ってしまうためです。

ISMAP・ISMS・SOC2・Pマークは何が違うのか

結論から言うと、評価する主体と、手に入る成果物が違います。4つとも「セキュリティの第三者評価」ではありますが、使われる場面は重なりません。

ISMSとSOC2が民間取引の信頼担保に使われるのに対し、ISMAPは政府機関等のクラウド調達において参照される事前評価・登録制度です。調達に乗るための通行証、と言い換えるとイメージしやすいでしょう。ここを取り違えると、案件の要件定義で話が噛み合わなくなります。

ISMSとSOC2の実務についてはISMS・SOC2取得支援案件｜フリーランスの実装・証跡業務と単価で、客先に持ち込む側の対応は客先セキュリティ要件対応｜ISMS・Pマーク・持ち込みPCの実務で整理しています。本記事はISMAPに絞ります。

ミニFAQ：ISMSを取っていればISMAPは楽になる？

楽にはなりますが、免除はされません。ISMAP管理基準はISO/IEC 27000シリーズや政府機関等の統一基準群を参照して作られているため、ISMS運用で整えた文書・記録の多くは流用できます。一方で、ISMAP固有の管理策や、監査機関による監査・IPAの審査という手続きは別途必要です。

「ISMS認証済みなので3か月で取れますよね」という見立ては、たいてい外れます。

ISMAP管理基準は3層構造になっている

ISMAP管理基準は、ガバナンス基準・マネジメント基準・管理策基準の3つで構成されます。上から順に、経営レベル、管理プロセスレベル、個別の技術・運用レベルと粒度が細かくなる設計です。

3つの基準がそれぞれ見ているもの

ガバナンス基準は、経営層がセキュリティをどう統治しているかを見ます。方針の策定、責任者の指名、資源の配分といった領域です。

マネジメント基準は、リスクアセスメントから是正までのPDCAが回っているかを問います。ISMSの要求事項と重なる部分が多いものの、同一ではありません。

管理策基準は、具体的に何を実装しているかの集合です。アクセス制御、暗号、ログ、構成管理、インシデント対応。エンジニアが手を動かすのは、ほぼここです。

作業量を決めるのは管理策基準

工数の見積もりで外しやすいのが、この管理策基準の扱いです。統制目標の下にぶら下がる詳細管理策は数が多く、一つひとつについて「実装しているか」「していると言える証跡はあるか」を揃えていく必要があります。

実装そのものより、証跡の整備で時間を取られるケースが目立ちます。設定は正しく入っているのに、入っていることを第三者に見せる形で残していない。この手戻りは案件の後半で効いてきます。

クラウド設定の不備を継続的に検出する仕組みについてはCSPMとは｜クラウド設定不備対策の実務と案件単価・必要スキルが参考になります。ISMAP対応でも、構成の証跡化という文脈でCSPM系ツールが登場します。

2027年3月に向けた管理基準の全般改定

ISMAP管理基準は、現在まとまった改定作業の途中にあります。2025年9月18日から10月17日にかけて管理基準（案）等の意見公募が実施され、募集は終了しました。

ここで大事なのは、改定の方向性は示されている一方、適用の詳細はまだ固まっていないという点です。確定していることと、していないことを分けて読んでください。

詳細管理策の項目数については、公表資料や解説資料で数え方に差があります。本記事では固定値として扱わず、「大幅に整理される方向の案」として理解するのが安全です。正確な数字が必要な場合は、公式の公表資料にあたってください。そもそも項目数が減ることと作業量が減ることは、同じではありません。原則すべて実施という建て付けになれば、1項目あたりの対応密度は上がります。

案件の面接でこの話題が出たときは、「確定した基準」と「案の段階」を混ぜずに話せるかどうかが、そのまま制度理解の深さとして見られます。

ISMAP登録までの流れと、時間がかかる場所

登録の流れは、大きく4段階です。

1. ISMAP管理基準に沿ったセキュリティマネジメントシステムを構築し、運用する

2. ISMAP監査基準に基づき、ISMAP監査機関の監査を受ける

3. IPAによる審査を受ける

4. ISMAPクラウドサービスリストに登録される

制度の全体像は総務省が公開しているはじめてのISMAP（PDF）がわかりやすく、事業者側・調達側の双方の立場から整理されています。

どこで止まるか

止まりやすいのは1と2のあいだです。管理策の実装は進んでいるのに、監査に出せる状態の記録がない。あるいは、運用を始めてからの実績期間が足りない。

マネジメントシステムは「構築した」だけでは評価できず、一定期間回した記録が要ります。つまり、実装が終わった翌月に監査、という日程は組めません。案件に入る時点で、どのフェーズを任されるのかは確認しておくべきです。

もうひとつ見落とされがちなのが、登録後です。登録は取って終わりではなく、維持のために毎年の監査対応が発生します。年次で回る業務なので、初回登録が終わったあとも運用支援の形で継続する案件が残ります。

ミニFAQ：ISMAP登録はどのくらいの期間がかかる？

サービスの規模と現状の整備度合いで大きく変わるため、一律の期間は示せません。ただ、管理策の実装・運用実績の蓄積・監査・審査という段階を踏む構造上、数か月で完了する前提は現実的ではないと考えておくのが無難です。参画前に、どの段階から入るのか、監査の予定時期がいつかを確認してください。

フリーランスエンジニアがISMAPに関わる3つの立ち位置

ISMAPを「制度の勉強」として眺めても案件にはつながりません。実際に仕事になるのは、次の3つのどれかです。

①登録を目指すSaaS事業者側の実装・証跡担当

公開案件では、この文脈で募集要件に現れやすい入口です。自社サービスをISMAPまたはISMAP-LIUに登録したいクラウド事業者が、管理策の実装と証跡整備を回せる人を探します。

具体的な作業は、アクセス制御の見直し、ログの収集・保全設計、鍵管理、脆弱性管理のプロセス化、構成管理の自動化あたり。コンサルタントが作った要件一覧を、動くインフラに落としていく役回りです。

ISMSやSOC2の取得支援と地続きの業務なので、ISMS・SOC2取得支援案件の経験はそのまま効きます。

②政府・自治体システム側でのサービス選定・構成設計

調達する側に立つパターンです。要件定義や基盤設計のフェーズで、「このSaaSはISMAPリストに載っているか」「載っていない場合どう整理するか」を判断材料として扱います。

設計の自由度が制度で縛られるため、技術的な最適解がそのまま採用できないことがある。この制約を理解したうえで代替案を出せる人は重宝されます。公共系案件の全体像は官公庁・公共系のフリーランスエンジニア案件｜単価相場・契約形態・セキュリティ要件を徹底解説に、行政DXの領域はGovTech・防災DXのフリーランスエンジニア案件動向｜単価と参画ルートにまとめています。

③登録後の維持・年次監査対応

登録済みサービスの運用フェーズを支える立場です。年1回の監査に向けて証跡を揃え、前年からの変更点を説明できる形に整える。構成変更のたびに管理策への影響を確認する、という地道な作業が中心になります。

登録後の維持案件は、初回登録支援より稼働が平準化しやすい傾向があります。ただし監査の前後は作業が集中しやすく、体制や責任範囲次第で負荷は変わります。

ミニFAQ：ISMAPの実務経験がなくても入れる？

入口はあります。2026年時点で主要フリーランスエージェントの公開案件を確認する限り、ISMAP経験そのものを必須とする募集はまだ限定的です。ISMS・SOC2・Pマーク対応やクラウドセキュリティ設計の経験を前提に、ISMAP固有の部分は現場で覚える形が見られます。逆に、監査対応の経験がまったくない状態で証跡整備の主担当に入るのは負荷が高めです。

ISMAP対応案件で評価されやすいスキルと経歴

結論として、求められるのは「クラウドの実装力」と「監査に耐える形で記録を残す力」の両方です。片方だけだと厳しい。

評価されやすい要素を挙げます。

• AWS・Azure・GCPいずれかでの本番運用経験。特にIAM設計、ログ基盤、鍵管理

• IaCによる構成管理の経験。設定内容を証跡としてそのまま提示できる

• ISMS・SOC2・Pマークのいずれかで、取得または更新を内側から経験している

• 監査人・審査機関とのやり取りに抵抗がない。質問に対して記録で答える作法を知っている

• 文書を書くことを嫌がらない。規程・手順書・報告書の作成が業務時間の相当部分を占める

資格は必須ではないものの、情報処理安全確保支援士やクラウド系の上位資格は、経歴の裏づけとして機能します。とりわけ監査対応や公共系の提案場面で、説明可能性を補強する材料になります。資格と案件の関係はセキュリティ資格おすすめ｜支援士・CISSP・CEHの難易度と案件影響で扱っています。クラウド側の順序づけで迷う場合はクラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸が参考になるはずです。

公共系では身元確認や機微情報の取扱いが論点になります。関連してセキュリティクリアランス制度とエンジニア案件｜対象・適性評価7項目・IT案件への影響も押さえておくとよいでしょう。

単価と契約の考え方

ISMAP対応案件に独立した相場があるわけではありません。クラウドセキュリティ案件の単価に、監査対応や公共系要件の負荷が上乗せされる形で決まることが多いです。

以下は観測ベースの目安です。2026年時点で、フリコンを含む主要フリーランスエージェントの公開案件を確認する限り、ISMAPという語が要件に明記された募集はまだ限定的でした。セキュリティエンジニア・クラウドセキュリティの募集要件の中に、ISMS・SOC2と並んで列挙されている形が中心です。母集団が小さい領域のため、確定した相場ではなく観測時点のスナップショットとして読んでください。

レンジそのものは隣接領域の記事に委ねます。セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジとISMS・SOC2取得支援案件が近い水準の参考になります。公共系特有の契約構造（複数次請けが前提になりやすい点）は官公庁・公共系のフリーランスエンジニア案件を確認してください。

自分の経歴でどのくらいの単価を狙えるか知りたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

契約面で確認しておきたいのは、監査時期の稼働です。監査前後は作業が集中しやすく、「通常は週3だが監査月だけ週5」といった変動が起きることがあります。稼働の上限と変動の扱いを、契約時に文面で確認しておくと揉めません。

よくある失敗と対策

制度の勉強だけして案件を探してしまう

ISMAPの条文を読み込んでも、それ自体は売り物になりません。発注側が求めているのは、管理策を実装して証跡を残せる手です。クラウドの実装経験を主軸に置き、ISMAPは「その経験を公共系の文脈に接続する語彙」として使うほうが通ります。

ISMSの延長線上だと見積もってしまう

参照している規格が重なるため、工数を軽く見がちです。ただし監査機関の監査とIPAの審査という手続きが別にあり、要求される記録の粒度も異なります。ISMS運用の資産をどこまで流用できるかは、案件開始時に棚卸ししてから判断してください。

改定の内容を確定事項として話す

意見公募が終わっただけの段階で「2027年から管理策は○○項目になります」と断言すると、制度を追えていないと見なされます。確定しているのは改定作業が進行中であることと、公表の目標時期です。中身は公式資料の更新を追う前提で話すのが正確です。

証跡を後回しにする

実装を先に全部終わらせて、証跡はあとでまとめて作る。この進め方は、ほぼ確実に手戻りを生みます。変更のたびにスクリーンショットや設定差分を残す運用を最初から組み込んだほうが、結果的に早い。

ISMAP案件に入る前のチェックリスト

参画を検討する段階で、次の項目を確認しておくと見立てを誤りにくくなります。

この表は、案件票だけでは読み取れない部分を面談で聞くための下敷きとして使えます。特に「現在のフェーズ」と「証跡の整備状況」は、実際の作業量を左右するのに案件票には書かれていないことが多い項目です。

まとめ

ISMAPは、政府機関等が利用するクラウドサービスを事前評価し、サービス単位で登録する制度であり、エンジニアにとっては「クラウドの実装力を公共系の文脈に接続する入口」です。制度そのものを覚えるより、管理策を実装して証跡で説明できる状態を作れるかが問われます。

要点を整理します。

• ISMAPは2020年6月運用開始。NISC・デジタル庁・総務省・経済産業省の4者が所管し、IPAがポータル運用や申請受付・審査といった実務を担う

• ISMAP-LIUは2022年11月1日運用開始で、リスクの小さな業務・情報を扱うSaaSが対象。リストは別建て

• ISMSやSOC2とは役割が違う。流用できる資産はあるが、監査機関の監査とIPAの審査は別途必要

• 管理基準はガバナンス・マネジメント・管理策の3層。エンジニアの作業量を決めるのは管理策基準

• 管理基準は全般改定の作業中で、ガイドライン等の公表目標は2027年3月。確定事項と検討中の事項を分けて扱う

• 関わり方は、登録を目指す事業者側の実装・証跡、政府側での選定・設計、登録後の年次維持の3つ

• 登録は取って終わりではなく、毎年の監査対応が続く。運用支援として案件が残りやすい

次の一歩としては、自分の経験のうちアクセス制御・ログ・構成管理の部分を、証跡として提示できる形に言語化しておくことをおすすめします。そのうえで公共系・セキュリティ領域の募集要件を眺めると、ISMAPがどの文脈で出てくるかが見えてきます。

参照した一次情報は以下のとおりです。

• 政府情報システムのためのセキュリティ評価制度（ISMAP）｜内閣官房 国家サイバー統括室

• ISMAPポータル（IPA運用）

• ISMAP管理基準（案）等に対する意見公募（募集終了）

• ISMAPクラウドサービスリスト等を更新しました｜デジタル庁

• はじめてのISMAP（PDF）｜総務省