障害の原因を追おうとした矢先に、肝心のログが残っていなかったという声は珍しくありません。ログは自動的に記録され続けるものではなく、何を取得し、どれだけ保存し、誰が確認するのかを設計段階で決めておかないと、必要な記録は残らないままです。本記事では、ログの種類、保存期間の考え方、自動化された分析と手動分析の役割分担を整理し、リモートワークの案件で設計に関わる際に押さえておきたい視点をまとめます。

1. 「ログが残っていない」は設定で決まっている

障害調査の場面で「その時間帯のログがない」と気づいた経験は、運用に関わったことがあるエンジニアなら一度はあるのではないでしょうか。ログは、機器やアプリケーションが動いていれば自動的に積み上がっていくものだと感じられがちですが、実際には取得の設定をしていない項目は最初から記録されていません。ログが存在しなければ、いつ、誰が、何をしたのかを追うことができず、通常の動作との違いも判断しにくくなります¹。

設定していない項目は、そもそも記録されない

調査で使えるログを残せるかどうかは、事後の対応力よりも事前の設計で決まります。機器やソフトウェアごとにログレベルなどを正しく設定しないと、そもそもログが取得されない場面があります³。運用を引き継いだ直後にこの設定を見直さず、後から「取っていたはずのログがない」と分かるケースは、設計の抜けが後になって表面化した形です。ログの設計は、取得・保存・点検という3つの工程がひと続きになっていて、最初の取得でつまずくと、あとの工程がどれだけ整っていても意味を持ちません。

「ログが残っていない」という一言の裏には、実は3つの違う原因が隠れています。取得の設定そのものが漏れていた場合、保存期間が短すぎて調べたい時点のログが消えていた場合、そして取得も保存もできていたのに誰も点検していなかった場合です。原因を切り分けずに「もっとログを取ろう」とだけ決めても、同じ抜けを繰り返しかねません。どの工程で止まっていたのかを見極めることのほうが、次の設計に活かせる発見になります。

この流れを図にすると、次のようになります。取得の設計を先に固めておくことが、保存や点検の質を決めるという順序が見えてきます。3つの工程はどれも独立した作業ではなく、前の工程が後の工程の材料になる関係にあります。取得の範囲が狭ければ保存する対象も狭くなり、保存が短ければ点検で振り返れる期間も短くなります。工程ごとに個別最適で決めるのではなく、最終的に何を確認したいのかから逆算して3つを一体で設計する視点が求められます。

図の作成：Remogu編集部。ログ運用の一般的な工程を整理したもので、統計データではありません

次の章では、取得の工程で具体的にどのログを選ぶのかを見ていきます。

2. どのログを取るのか

4つの種類と、それぞれが答えられること

ログと一括りに語られがちですが、記録している内容は種類によって異なります。認証ログは誰がいつ認証を試みたかを記録し、HTTPアクセスログはどの画面にどの経路で到達したかを記録します。監査ログは、利用者の操作やシステム内で発生した事象を記録したものです²。ネットワークフローログは、どの通信がどこと行われたかという通信の記録です。取得の設計とは、これらの中から答えたい問いに対応する種類を選ぶ作業でもあります。

種類を選ばずに手当たり次第に取得を有効にすると、保存や点検の負荷だけが増え、必要なときに必要な記録が見つけにくくなります。取得できる項目の広さよりも、答えたい問いに対応した種類を選ぶ精度のほうが、あとから見返したときの扱いやすさを決めます。どの問いに答える必要があるかを先に決め、そこから逆算して種類を選ぶ順序のほうが、後から見返したときに扱いやすくなります。

案件によっては、既存の仕組みで一部の種類しか取得できていないこともあります。その場合は、4つの種類をすべて揃えることを目的にするのではなく、いま答えられない問いは何かを洗い出し、優先順位をつけて取得対象を広げていく進め方が現実的です。認証ログとアクセスログは「誰がどこに来たか」を、監査ログとネットワークフローログは「何が起きたか」を追う役割を持っており、この2つの軸で欠けを確認すると整理しやすくなります。

ログの種類ごとに、答えられる問いが違います

次の表は、代表的な4つのログの種類と、それぞれが主に記録する内容、そして答えられる問いの例を整理したものです。案件で「どのログを取得するか」を検討するときの出発点として使えます。認証ログとアクセスログは利用の経路を追う場面で、監査ログとネットワークフローログは操作や通信そのものを追う場面で使われる傾向があり、目的が異なる点を押さえておくと選び方に迷いにくくなります。

ログの種類	主に記録する内容	答えられる問いの例
認証ログ	ログインの試行や認証の結果	誰がいつ認証を試みたか
HTTPアクセスログ	リクエストの経路や応答の状態	どの画面にどの経路で到達したか
監査ログ2	利用者の操作やシステム内で発生した事象	誰の操作でシステム内に何が起きたか
ネットワークフローログ	通信の発生元・宛先・時間帯	どの通信がどこと行われたか

出典：デジタル庁「政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」（2026年3月31日）をもとに作成

種類を選び終えたら、次に決めるのは「どれだけ残すか」です。ここで保存期間とコストの釣り合いが問題になります。

3. どれだけ残すのか

ログの種類によって、残す長さの考え方は変わる

取得したログをどれだけ保存するかは、長ければ安心というだけの話ではありません。ログの保存期間は、統一基準が推奨する1年間以上を一つの基準としながら、保存コスト・情報の重要度・適用される法規制などを踏まえて総合的に決めるという考え方があります⁶。この基準は政府情報システムを前提にした整理であり、民間の案件にそのまま当てはめられるわけではありませんが、保存期間を検討するときの視点としては参考になります。

すべてのログを同じ長さで残す必要があるわけでもありません。ネットワークフローログは大容量になるため費用対効果を考えると数か月から1年程度、サーバ監査ログは重要性が高いため1年以上の長期保存とするといった対応も考えられます⁷。すべてを均等に残すことよりも、重要度に応じて長さを変える設計のほうが、保存コストと点検の実用性を両立させやすくなります。

保存期間を長く取るほど安心に近づくように感じられますが、保存領域と点検の対象が増える分、コストと運用の負荷も一緒に膨らみます。長さだけを追い求めるよりも、何のためにその期間を残すのかという目的から逆算して長さを決める姿勢のほうが、コストの説明にも耐えやすくなります。案件でこの提案をするときは、「重要度が高い記録を優先して長く残す」という優先順位の考え方を示せると、クライアントとの協議も進めやすくなります。

残す長さは、ログの性格で変わります

次の表は、保存期間を検討するときの目安をログの種類ごとに整理したものです。数値は政府情報システムを対象にした資料の考え方であり、そのまま民間案件の基準にはなりませんが、コストと重要度をどう釣り合わせるかを考える手がかりになります。

ログの種類	保存期間の目安	主な理由
ネットワークフローログ	数か月〜1年程度7	大容量になり保存コストが大きくなるため
サーバ監査ログ	1年以上の長期保存も検討7	重要度が高く、さかのぼって確認する場面があるため
全体の基準	1年間以上6	コスト・重要度・法規制を踏まえて総合的に判断するため

出典：デジタル庁「政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」（2026年3月31日）をもとに作成

取得と保存の設計が固まったら、次はそのログを誰がどのように点検するのかという役割分担の話に移ります。

4. 誰が見るのか

自動化された分析と、人が担う手動分析

取得し、保存したログは、そのままでは意味を持ちません。誰かが、あるいは何らかの仕組みが点検して初めて、異変を見つける材料になります。SIEMは、複数のIT機器のログを一元的に集約・管理し、リアルタイムの監視や横断的な分析によって脅威の検知やインシデント対応を支える仕組みです⁴。特定の製品を比較する話ではなく、こうした仕組みが一元的な集約と横断的な分析を担うという役割の話です。

ここで気になるのが「仕組みを入れれば、人の点検はいらなくなるのか」という点です。ログ分析には、専用のソリューションによる自動化された分析と、運用担当者やログアナリストが行う手動分析があり、自動化を進めながら、その限界で生じる空白を手動分析が補うという補完関係があります⁵。どちらか一方だけで完結する話ではなく、自動化した仕組みよりも、その仕組みが拾いにくい部分をどう補うかの設計のほうが、案件の中では評価される場面が多くなります。

自動化された分析は、決められた条件に沿って大量のログを継続的に見続けることに向いています。一方で、条件からわずかに外れた挙動や、業務の背景を踏まえないと判断できない事象は、仕組みだけでは拾いきれません。手動分析は、こうした「条件に当てはまらないが気になる」記録を拾い上げ、事業の文脈に照らして意味づけをする役割を担います。仕組みを整えることと、人が見るべき範囲を絞ることは、対立する話ではなく同じ設計の中で決めるべき一対の項目です。

案件に参画するときは、すでに自動化の仕組みが入っている現場も、これから整える現場もあります。どちらの場合も、仕組みが検知した内容をそのまま受け取るだけでなく、「この条件で拾えないものは何か」を問い直せる姿勢が、手動分析の役割を担うエンジニアに求められる視点になります。仕組みの設定を疑える力は、仕組みを使いこなす力よりも身につけにくく、その分、案件の中では差になりやすい部分です。

出典：デジタル庁「政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」（2026年3月31日）をもとに作成

この役割分担を理解していると、案件に入ったときに「どこまでを仕組みに任せ、どこから人が見るのか」を自分の言葉で提案できるようになります。次の章では、実際にリモートの案件でこの設計にどう関わるのかを見ていきます。

5. リモート・フリーランス案件でどう関わるか

設計に関わるときに、決めておきたい項目

ログの設計は、常駐して手を動かす作業だけを指すわけではありません。取得対象の整理、保存期間の提案、点検の役割分担のドキュメント化は、リモートでも進めやすい領域です。むしろ、後から差し込む改修よりも、最初の設計段階で決めておくことのほうが、後戻りの少ない結果につながります。設計段階で決められるエンジニアは、運用が始まったあとの案件でも頼られやすくなります。

運用の現場に毎日出向かなくても、取得対象や保存期間の案を資料にまとめ、オンラインの打ち合わせでクライアントと協議しながら固めていく進め方は、リモートの案件でも十分に成立します。手を動かす作業の速さよりも、決めるべき項目を漏らさず整理できる力のほうが、この領域では評価の軸になりやすくなります。

設計に関わるときに決めておきたい項目を整理すると、次のようになります。

決める項目	検討のポイント
取得対象	どの機器・システムのログを取得するか
保存期間	重要度と保存コストの釣り合いをどう置くか
アクセス権限	誰がログを見られるようにするか
個人情報への配慮	マスキングなどの安全管理をどう組み込むか

ログにも、個人情報への配慮が必要になる

ログの設計では、セキュリティの視点だけでなく、個人情報への配慮も欠かせません。ログに個人情報や要機密情報が混入する可能性を排除できない場合は、必要最小限の情報のみを取得する、利用目的を明示する、目的外利用を禁止する、マスキング処理を施すといった適切な安全管理措置を講じる考え方が示されています⁸。個人情報保護法の逐条的な解説はこの記事の範囲を超えますが、ログにも個人情報が入り込む可能性があるという視点は、設計の入り口で持っておく価値があります。

こうした設計を任される案件は、常駐よりもリモートで進めやすい傾向があります。Remoguでは、案件の90%以上がフルリモート可能です⁹。場所に縛られずに設計の経験を積みたいエンジニアにとって、ログの取得・保存・分析という一連の設計は、積み上げた経験を活かしやすいテーマの一つです。表にまとめた4つの項目のうち、どこに強みがあるかを自分の言葉で語れるようになっておくと、条件を協議する場面でも説得力を持たせやすくなります。

6. まとめ

ログが残っていないという状況は、事後の不運というよりも、設定していなかった項目がそもそも記録されていなかったという設計の結果です。取得する種類を絞り込み、種類に応じて保存期間の長さを変え、自動化された分析と手動分析の役割分担を決めておく。この3つを設計段階で決めておけば、障害や不正が起きたあとに「調べる材料がない」という事態を避けやすくなります。

ログを取ることそのものよりも、何を取り、どれだけ残し、誰が見るのかを決める設計のほうが、案件の中では長く頼られる経験になります。こうした設計に関わる経験は、常駐の現場よりもリモートの案件でも十分に積み上げられるものです。設定を見直すだけで防げていた抜けと、設計そのものを見直さないと防げない抜けを分けて考えられるようになると、次に任される範囲も自然と広がっていきます。まずはRemoguに登録し、自分の経験に合う条件から探してみるのも、次の一歩になります。

7. よくある質問

ログはとりあえず全部取ればよいのか

取得できる項目をすべて有効にする方法もありますが、量が増えるほど保存や点検の負荷も大きくなります。まずはどの問いに答える必要があるかを整理し、対応するログの種類を選ぶ考え方のほうが現実的です。機器やソフトウェアごとにログレベルなどを正しく設定しないと、そもそもログが取得されない場面もあります³。取得の設定そのものを見直すところから始めると、抜け漏れに気づきやすくなります。量を増やすことよりも、答えたい問いに対応した種類を漏らさないことのほうが、点検の実用性につながります。

保存期間は何を基準に決めるのか

政府情報システムを対象にした資料では、統一基準が推奨する1年間以上を基準に、保存コスト・重要度・適用される法規制を踏まえて総合的に決める考え方が示されています⁶。これは政府情報システムを前提にした整理であり、民間の案件にそのまま当てはめられる基準ではありませんが、期間を検討するときの視点としては参考になります。ログの種類によって重要度が異なる場合は、長さを分けて考える方法もあります⁷。

SIEMを入れれば人はいらなくなるのか

SIEMは複数のIT機器からログを一元的に集約・管理し、リアルタイムの監視や横断的な分析を支える仕組みです⁴。ただし、自動化を進めても、その限界で生じる空白を手動分析が補う関係は残ります⁵。人の点検がなくなるという整理にはなっておらず、仕組みと人がどこを分担するかを決める設計は残り続けます。仕組みを入れる目的は、人を不要にすることではなく、人が見るべき範囲を絞り込むことにあると捉えると、案件での提案もしやすくなります。

ログに個人情報が入ってしまったら

ログには個人情報や要機密情報が混じる可能性を排除できません。その場合は、必要最小限の情報のみを取得する、利用目的を明示する、目的外利用を禁止する、マスキング処理を施すといった安全管理措置を組み込む考え方が示されています⁸。個人情報保護法の詳細な解説はこの記事では扱いませんが、設計の段階でこの視点を持っておくことが助けになります。取得した後にマスキングを足すよりも、取得の設計に安全管理の項目を組み込んでおくほうが、手戻りの少ない進め方になります。

リモートでもログの設計に関われるのか

ログの設計は、現場に常駐しなくても、要件の整理やドキュメント作成、レビューを通じて関わりやすい領域です。取得対象や保存期間の考え方を提案できる経験は、リモートの案件でも評価されやすい材料になります。Remoguでは、案件の90%以上がフルリモート可能です⁹。積み上げてきた運用や監査の経験を、常駐という条件にとどめておく必要はありません。まず登録して、自分の経験に合う条件を確かめてみるのも一つの選択です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 はじめに（2026年3月31日）
＊2 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ分析の概要（2026年3月31日）
＊3 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ分析の概要（2026年3月31日）
＊4 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 用語（2026年3月31日）
＊5 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ分析の概要（2026年3月31日）
＊6 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ保存・保全における留意事項（2026年3月31日）
＊7 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ保存・保全における留意事項（2026年3月31日）
＊8 デジタル庁「政府情報システムにおける脅威の検知・対応のための ログ取得・分析導入ガイドブック」DS-222 ログ取得における留意事項（2026年3月31日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）