ゼロトラストの案件では、設計しただけでは終わりません。監査に残る記録の作り方

📘 この記事でわかること
- クラウド前提の方針が定まった背景と、監査の仕組みを活用する環境整備が閣議決定で位置づけられた経緯
- 第三者が監査してクラウドサービスをリストに登録する制度の仕組みと、評価が個人の主観ではなく審議・投票で決まる理由
- 日々の記録から四半期の点検・年次の監査までの周期と、リモートで記録を整えるときに先に決めておく前提
設計書は仕上がりました。認証基盤もアクセス制御のポリシーも、都度検証の仕組みも狙いどおりに組み上がっています。それでも案件の終盤で「この設計を誰が確認したのか、記録はどこにあるのか」と聞かれ、答えに詰まった経験はないでしょうか。ゼロトラストの案件で本当に問われるのは、設計そのものより、その先の記録です。
1. クラウドを前提に置くことは、方針として決まっています
ゼロトラストを扱う案件は、クラウドを前提にした設計が広がるにつれて増えている領域です。境界防御だけでは説明がつかない場面が増え、都度確認する設計そのものが求められるようになっています。
案件の内容を見ても、認証基盤の刷新やアクセス制御の見直しといった設計そのものの依頼だけでなく、その設計を第三者にどう説明するかまで含めて相談される場面が増えています。設計と説明はセットで扱われる前提で臨んだほうが、案件全体の見通しは立てやすくなります。
「クラウド・バイ・デフォルト原則」という考え方
セキュリティ設計を任されるようになると、まず疑うのは「境界を守る」という発想そのものです。社内ネットワークの内側は安全、外側は危険という前提が崩れているのは、現場で日々感じている実感だと思います。
この感覚は、案件ごとの個別事情ではありません。政府情報システムでは「クラウド・バイ・デフォルト原則」が平成30年6月7日のCIO連絡会議決定で示され、クラウドサービスの利用を第一候補として検討する方針が定まりました2。
この原則は政府調達に限った話ではありません。クラウドサービスを使う設計が標準になるほど、社内ネットワークという境界そのものが薄れ、認証と認可を都度確認する設計が現実的な選択になっていきます。
境界の内と外で信頼を分けるやり方は、前提から外れつつあります。だからこそ、都度確認する設計そのものが必要になります。
ゼロトラストが求められる流れ
クラウドが前提になれば、社内と社外という区切りは意味を持たなくなります。誰が、どこから、何にアクセスしているかを都度確認する設計のほうが、境界を固める設計よりも実態に合います。
ID管理、デバイスの状態確認、通信の暗号化といった要素は、それぞれ単体でも意味を持ちますが、都度検証という考え方でつなげたときに初めて、境界防御に代わる仕組みとして機能します。要素をそろえるだけでなく、つなぎ方を設計する案件だと捉えると、扱う範囲が見えやすくなります。
つなぎ方を設計するということは、判断の根拠をどこかに残しておくということでもあります。「なぜこの順序で検証するのか」「なぜこの条件で許可するのか」という判断は、設計した本人の頭の中だけに置いておくと、後から誰も再現できなくなります。
前提が決まっているなら、確認の仕方にも決まりがあるのでしょうか。
2. 監査の仕組みを使うことは、閣議決定の文書に書かれています
デジタル・ガバメント実行計画に書かれていること
設計や実装が終わった後の確認作業は、つい「余力があれば」の扱いになりがちです。納期に追われる案件ほど、記録づくりは後回しにされやすい部分だと思います。
けれど、この確認作業は付帯的な扱いにとどまっているわけではありません。デジタル・ガバメント実行計画(令和元年12月20日 閣議決定)では、安全性評価基準と安全性評価の監査の仕組みを活用して、安全性が評価されたクラウドサービスの利用を開始できるよう環境整備を進めることが位置づけられています3。
監査の仕組みを活用する、という一文が閣議決定の文書に明記されている以上、記録と監査は設計の後付けではなく、設計と対になる作業だと捉えたほうが実態に近いです。
ここでいう仕組みとは、誰かが一度確認すれば終わるものではありません。継続的に安全性を確かめる体制そのものを指しており、設計する時点でその体制に組み込まれる前提を意識しておく必要があります。
体制が用意されていても、記録が残っていなければ体制を使ったことにはなりません。監査の仕組みを活用する環境が整っているかどうかは、記録という具体的な形になって初めて確認できます。
記録は設計と対になる作業
監査の仕組みを活かすためには、設計の途中から記録を残しておく必要があります。完成してから振り返って記録を作ろうとすると、判断の根拠や検討した代替案が抜け落ちてしまいます。
仕組みを使うと書かれているなら、実物を見たほうが早いです。
3. 第三者が監査して登録する制度が、実際にあります
ISMAPという制度の仕組み
「第三者が確認できる記録」と言われても、具体的に何を指すのか掴みにくい部分だと思います。
政府情報システムのためのセキュリティ評価制度(ISMAP)は、令和2年6月に運用が開始された制度です。国家サイバー統括室・デジタル庁・総務省・経済産業省が所管し、ISMAP管理基準に基づいて、第三者であるISMAP登録監査機関が監査したうえで「ISMAP等クラウドサービスリスト」に登録する仕組みになっています1。各政府機関等は、原則としてこのリストに掲載されたクラウドサービスから調達します。
クラウドサービス側が自ら「安全です」と説明するだけでなく、外部の監査機関が確認した記録として残る点に、この制度の特徴があります。個々の技術要素だけを審査するのではなく、運用や記録の体制まで含めて確認される設計です。
出典:国家サイバー統括室「政府情報システムのためのセキュリティ評価制度(ISMAP)」をもとに作成
この制度は政府調達の枠組みであり、個々の案件に自動的に適用されるとは限りません。それでも、基準を定めて第三者が確認するという骨格は、民間の審査でも参考になります。
「基準を決める」「第三者が確かめる」「確認済みのものだけを一覧にする」という3段階は、規模の大小を問わず、記録を設計する際の骨組みとして応用できます。制度そのものを覚えるより、この骨組みを覚えておくほうが、日々の案件では役立ちます。
骨組みだけを取り出せば、案件ごとの規模に合わせて調整もできます。大掛かりな監査の仕組みをそのまま持ち込む必要はなく、基準・確認・一覧という3つの動きを、案件の規模に合わせて簡略化して当てはめれば十分です。
セキュリティ設計に関わるリモート案件を見る →
表1:ISMAPの仕組みの全体像
ISMAPの仕組みは、大きく3つの要素から成り立っています。1つ目はクラウドサービス事業者が満たすべき基準である管理基準、2つ目はその基準を満たしているかを外部の目で確かめる第三者監査、3つ目は確認が済んだサービスだけが載る一覧です。設計や運用の担当者が「できています」と説明するだけで終わらず、外部の監査機関が確認した記録として残る点が、この制度の骨格になっています。以下の表に、3つの要素と、それぞれで何が行われるかを整理しました。
| 要素 | 内容 | 誰が確認するか |
|---|---|---|
| 管理基準 | クラウドサービス事業者が満たすべき基準を定める | 制度の枠組みとして事前に整備 |
| 第三者監査 | 基準を満たしているかをISMAP登録監査機関が確認する | 事業者以外の第三者 |
| リスト登録 | 監査を経たサービスが「ISMAP等クラウドサービスリスト」に登録される | 政府機関等が調達時に参照 |
制度があるとして、評価は誰がどう決めているのでしょうか。
4. 評価は、担当者の主観で決まるものではありません
約250名が審議・投票して決める仕組み
監査や評価と聞くと、担当者ひとりの印象で判断されるのではないかという不安を持つ場面があります。
情報セキュリティ10大脅威は、研究者や企業の実務担当者など約250名のメンバーからなる「10大脅威選考会」が審議・投票を経て決定しています4。この記事で扱うのは脅威の順位そのものではなく、決め方の構造です。様々な立場の人が集まって審議し、投票という手続きを経る点に注目します。
選考会には研究者だけでなく、企業で実務にあたる担当者も加わっています。立場の異なる人が同じ情報を見て審議し、最終的に投票という手続きを経ることで、特定の個人の判断に偏らない形になっています。
出典:IPA「情報セキュリティ10大脅威 2026」(2026年1月29日)をもとに作成
第三者の合議という設計は、審査全般にも応用できる考え方
ひとりの担当者が評価を下す設計よりも、複数の立場が確認し合う設計のほうが、外部から見たときの納得感は高くなります。監査を意識した設計にも、同じ考え方が使えます。
フリーランスとして案件に参画する場合も、自分ひとりの判断で「これで問題ない」と完結させるのではなく、クライアント側の担当者と一緒に確認する場を設計に組み込んでおくと、同じ効果が得られます。
決め方が分かれば、日々の記録に落とせます。
5. 監査の山は、日々の記録で決まります
表2:記録を積み重ねる4つの周期
監査は年に一度、突然やってくるわけではありません。日々の作業ログ、四半期ごとの点検、年次の監査、契約や制度の更新時の審査という4つの周期が積み重なって、監査に耐える記録になります。日々の記録が粗いままだと、年次の監査で慌てて資料を作り直すことになりがちです。以下の表に、周期ごとの主な目的と、残しておきたい記録の例を整理しました。
| 周期 | 主な目的 | 残す記録の例 |
|---|---|---|
| 日々の記録 | 自分自身の作業ログとして残す | 変更内容・実施日時・承認者のメモ |
| 四半期の点検 | クライアントとの定期確認に使う | 設定変更の一覧と点検結果の共有資料 |
| 年次の監査 | 外部監査や社内監査のタイミングで参照する | 1年分の記録をまとめた報告資料 |
| 更新審査 | 契約や制度の更新時に確認される | 前回の指摘への対応状況の記録 |
図の作成:Remogu編集部。監査までに記録が積み重なる周期を整理したもので、統計データではありません
記録を作る範囲は、事前の合意で決まります
日々の記録は、変更した内容と、その承認を誰が行ったかが分かる程度でかまいません。特別な様式は必要なく、続けられる形にしておくことのほうが重要です。四半期の点検では、その記録をクライアントと一緒に見返し、抜けがないかを確認します。
日々の記録を積み重ねていくと、年次の監査は「まとめ直す作業」ではなく「揃っている記録を提出する作業」に変わります。この積み重ねが、監査の負担そのものを軽くします。
更新審査では、前回の監査や点検で指摘された内容にどう対応したかが問われます。指摘への対応記録も、四半期の点検や日々の記録の延長として残しておけば、更新のたびに一から資料を作り直す必要がなくなります。
外部の立場としてどこまでの記録を作るかは、業務委託契約の範囲内でクライアントと事前に合意しておく事項です。責任の所在を判断するものではなく、双方が確認できる形をあらかじめすり合わせておく話だと捉えると、進めやすくなります。
記録の形が決まれば、リモートでも整えられます。
6. リモートで記録を整えるための前提
記録が残る場所と権限を先に決める
リモートで案件を進めていると、記録をどこに置くかという取り決めが後回しになりがちです。
設計や監査対応の記録は、案件が終わったあとも参照される可能性があります。保存場所・閲覧権限・更新のルールを着手前にクライアントと決めておくと、あとから確認を求められたときに慌てずに済みます。
オフィスに常駐していれば、記録の保管場所や閲覧できる人の範囲は自然と決まっていることが多いですが、リモートで進める案件では、そうした前提が存在しません。だからこそ、着手前の合意が欠かせません。
クライアントとの定例確認をオンラインで行う案件であれば、その場で記録を画面共有しながら確認するだけでも、四半期の点検に近い効果が得られます。特別な仕組みを新しく用意しなくても、既にある打ち合わせの場を記録の確認に使う発想で十分です。
保存場所・アクセス権限・共有ルールの3点は、案件の開始時にまとめて確認しておくと、その後の運用で迷う場面が減ります。案件の途中で決め直そうとすると、それまでの記録をどちらの形式にそろえるかという余計な調整が発生しがちです。
記録を作ってから置き場所を考えるよりも、置き場所を先に決めてから記録を作るほうが、あとで探す手間がかかりません。
図の作成:Remogu編集部。リモートで記録を整える際の段取りを整理したもので、統計データではありません
リモートで進めやすい案件の傾向をチェックする →
表3:リモートで記録を整えるために決めておくこと
Remoguが扱う案件は、90%以上がフルリモート可能です5。ただしリモートで進めやすいかどうかと、記録の残し方をどう合意するかは別の話です。案件によって求められる記録の粒度は異なるため、着手前の確認は欠かせません。リモートで案件を進める場合、記録を作ること自体はオフィスでの作業と変わりません。変わるのは、記録がどこに保存され、誰がいつ確認できるかという環境の整え方です。以下の表に、決めておきたいことと、決めていない場合に起きやすいことを整理しました。
| 決めておくこと | 内容 | 決めていないと起きること |
|---|---|---|
| 保存場所 | 記録をクライアント環境に置くか、双方で合意した場所に置くかを事前に決める | 案件終了後に記録だけ手元に残り、参照できなくなる |
| アクセス権限 | 誰が記録を閲覧・編集できるかをクライアントと合意する | 権限の範囲があいまいなまま作業が進む |
| 共有ルール | 更新のタイミングと通知方法を決めておく | どれが最新の記録か分からなくなる |
記録の置き場所と権限を先に決めておくことが、リモートで進める案件をスムーズにする土台になります。
7. まとめ
ゼロトラストの案件で問われるのは、設計の技術力だけではありません。クラウド前提の方針、監査を活用する仕組み、第三者が確認して登録する制度、審議・投票で決まる評価という流れをたどると、最後に残るのは「記録として示せるかどうか」という一点です。
- クラウド前提の方針が定まり、都度確認する設計が求められる背景があること
- 監査の仕組みを活用することが、閣議決定の文書に位置づけられていること
- ISMAPのように第三者が監査してリストに登録する制度が実在し、その骨格は民間の審査にも参考になること
- 評価は個人の主観ではなく、複数の立場が審議・投票して決める考え方であること
- 記録は日々・四半期・年次・更新の周期で積み重ね、リモートでは保存場所と権限を先に決めておくこと
設計だけで案件を終える時代ではなくなりつつあります。境界を固める発想から、都度確認して記録に残す発想へ。この切り替えができているかどうかが、案件の終盤で慌てるかどうかを分けます。次の案件では、記録の置き場所と権限を、着手前に一つだけ決めてみてはいかがでしょうか。
8. よくある質問
資格は必要ですか
特定の資格が案件の条件になっている場合もありますが、資格の有無だけで判断されるわけではありません。これまでの設計・監査対応の実務経験を、記録として説明できる形にしておくことが重視されます。資格はその経験を裏づける材料のひとつと考えると、位置づけが整理しやすくなります。
政府調達に関わらない案件でも関係がありますか
ISMAPは政府調達のための制度ですが、基準を定めて第三者が確認するという骨格は、民間の社内審査やクライアント監査にも参考になる考え方です。案件が政府調達に関わるかどうかにかかわらず、記録の残し方を検討する材料になります。「制度に適合しているか」を判断するのではなく、「考え方を参考にできるか」という視点で見ておくと扱いやすくなります。
記録はどこまで細かく残せばよいですか
求められる粒度は案件によって異なります。変更内容・実施日時・承認者が分かる程度を最低限とし、詳細な粒度はクライアントと事前に協議して決めることが安全です。粒度を細かくしすぎて続かなくなるより、続けられる粒度を先に決めるほうが結果的に記録が揃います。
外部の立場として、どこまで記録を作る範囲になりますか
どこまでの記録を作るかは、業務委託契約の範囲内でクライアントと合意しておく事項です。責任の所在を切り分ける話ではなく、双方が確認できる状態を事前にすり合わせておく話だと捉えると整理しやすくなります。範囲が曖昧なまま進めるより、着手前に一度言葉にしておくほうが、あとの手戻りは少なくなります。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
求められる記録の粒度は案件ごとに違います。まずは条件を見比べるところから確かめられます。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 国家サイバー統括室「政府情報システムのためのセキュリティ評価制度(ISMAP)」閲覧日(2026年8月4日)
*2 国家サイバー統括室「政府情報システムにおけるクラウドサービスの利用に係る基本方針」閲覧日(2026年8月4日)
*3 国家サイバー統括室「デジタル・ガバメント実行計画」閲覧日(2026年8月4日)
*4 IPA「情報セキュリティ10大脅威 2026」(2026年1月29日)
*5 Remoguサイト公開情報(案件の90%以上がフルリモート可能)