コラム
■ 読むのにかかる時間
・約10〜12分
■ 読むことで得られる知識
・3階層Webシステムを「構成図」ではなく「情報の流れ」として捉える視点
・各レイヤーのログで「把握できること・把握しきれないこと」の整理
・「ログはあるのに説明できない」状態がなぜ起きるのかの構造的理解
・ログ設計・監査設計を考える際の思考の起点
■ 関連ページ
・BlackBoxSuiteの構成図
・BlackBoxSuiteのログ取得エージェント群「TraceSeries」
Webシステムの障害対応や問い合わせ対応、あるいは監査対応の場面で、「結局、どこを見れば状況が分かるのか」と迷った経験はないでしょうか。
Webサーバのアクセスログを確認しても原因が特定できず、アプリケーションログを追っても処理の背景が見えない。データベースの操作履歴を見ても、それがどの画面(ユーザー)の操作に対応するのか分からない──こうした状況は、多くの現場で見られるものです。
多くの場合、その背景には「3階層Webシステム」という構成理解が、知識としてはあっても、実務で十分に使いこなされていないという課題があると考えられます。
本コラムでは、Web／アプリケーション／DB(データ)という3階層構成をあらためて整理しながら、各レイヤーで「どのような処理が行われ、どのような痕跡が残り得るのか」を対応づけて解説します。そして、なぜこの構成理解がログ設計や監査設計の前提になるのかを、実務視点で掘り下げていきます。
目次
１． 3階層Webシステムは「構成図」ではなく「情報の流れ」で捉える
3階層システム、あるいは3層アーキテクチャという言葉は、Webシステム構成を語るうえで非常に一般的です。Webサーバ、アプリケーションサーバ（WAS）、データベースという役割分担も、多くの方が理解されているでしょう。
しかし、実務で問題が生じるのは、この構成を「静的な構成図」としてしか捉えていない場合です。Webシステム構成の本質は、各レイヤーを情報がどのように流れ、どこでどのような処理が行われるか、という点にあります。
ユーザーの操作は、Webサーバで受け取られ、WAS(アプリケーションサーバー)で業務ロジックとして解釈され、データベースでデータとして永続化される。この一連の流れの中で、処理の結果としてさまざまな痕跡がログとして残る可能性があります。
ログ設計やシステム監査を考える際に重要なのは、「どのレイヤーにログがあるか」ではなく、「どのレイヤーで、どの事実が発生しているのか」を理解することです。この前提が曖昧なままでは、目的とズレたログ設計になりやすいと考えられます。
2．プレゼンテーション(Webサーバ)層で起きている処理と残る痕跡
プレゼンテーション層は、外部からのリクエストを最初に受け取る入口です。HTTPリクエストの受信、URLへのルーティング、静的コンテンツの配信などが主な役割となります。この層で残る代表的な痕跡が、アクセスログです。
Webサーバのアクセスログには、リクエスト元のIPアドレス、リクエストされたURL、HTTPメソッド、レスポンスコードなどが記録されます。これらの情報から、「いつ、どこからアクセスがあったのか」という事実を把握することができます。
しかし、Webサーバのログだけでは、そのアクセスが業務的に「何を意味していたのか」までは分かりません。同じ URLへのアクセスであっても、単なる画面表示なのか、検索条件の指定なのか、登録・更新処理の前段なのかといった意味合いは、Webログ単体からは判断できない場合があります。
さらに、アクセスの結果として「どのデータ（情報）が実際に参照・更新されたのか」という点についても、Webサーバ層では把握できません。URL や画面単位でのアクセスは確認できても、その先でアプリケーションがどの業務処理を実行し、どのデータに影響を与えたのかといった事実は、この層には残らないためです。
このように、Webサーバのアクセスログは、「いつ、どこから、どのリソースにアクセスがあったか」という入口の事実を把握するうえでは有効である一方、そのアクセスの意味や、業務・データへの影響を直接示すものではないという特性を持っています。
Webサーバのログだけを見て状況を判断しようとすると、処理の背景や意図が見えず、原因調査や監査対応が行き詰まるケースがあるのは、このためだと考えられます。
3． アプリケーション層が担う役割とログの特性
プレゼンテーション層では「誰が、いつ、どこにアクセスしたか」は把握できる一方で、そのアクセスが業務的に何を意味していたのかまでは分かりませんでした。その「意味」が初めて明確になるのが、アプリケーション層です。
アプリケーション層は、Webサーバから渡されたリクエストを、業務処理として解釈・実行する役割を担います。ログイン処理なのか、検索なのか、登録や更新なのかといった判断は、この層で行われます。言い換えると、単なるHTTPリクエストが「業務上の行為」として意味づけられるのが、アプリケーション層です。この層で残る代表的な痕跡が、アプリケーションログです。
アプリケーションログには、処理の開始・終了、業務ロジック上の分岐、入力値の検証結果、権限チェックの成否などが記録されることがあります。これらのログを通じて、「そのアクセスが何をしようとしていたのか」「どの業務処理が実行されたのか」といった文脈を読み取ることが可能になります。
一方で、アプリケーションログにも限界があります。アプリケーション層では、業務処理の流れや意図は把握できるものの、その結果としてデータベース上でどのデータが最終的に参照・更新されたのかという事実までは、この層だけでは確定しないケースが多いと考えられます。
たとえば、「顧客情報を更新する」という処理がログに残っていても、
・実際にどのレコードが更新されたのか
・更新件数はいくつだったのか
・トランザクションは正常にコミットされたのか
といった点は、アプリケーションログだけでは判断できない場合があります。
また、アプリケーションログは設計や実装に大きく依存するという特性もあります。開発時のデバッグ用途を中心に設計されている場合、運用や監査の観点で必要とされる情報が十分に残らないこともあります。その結果、「意味は分かるが、事実として裏付けきれない」という状態に陥ることも少なくありません。
このようにアプリケーション層は、Web層では見えなかったアクセスの意味や業務的な文脈を補完する役割を果たしますが、それだけでは「何が起きたか」を完全に説明できるわけではありません。
次の章では、業務処理の結果が最終的に確定するデータベース層で、どのような痕跡が残り、どのような点が見えにくくなるのかを整理します。
4. データ（DB）層で確定する「事実」と、見えにくくなる背景
Webサーバ層やアプリケーション（WAS）層で行われた処理の結果は、最終的にDB（データベース）層に反映されます。DB層は、Webシステムにおいてデータを永続的に保持し、業務処理の「結果」が確定するレイヤーです。
この層では、SELECT、INSERT、UPDATE、DELETEなどの操作が実行され、その痕跡としてデータベースログやデータアクセスログ、監査ログが取得される構成があります。これらのログからは、「どのデータに対して、どのような操作が行われたのか」「いつデータが参照・更新されたのか」といったデータ操作の事実を把握できます。
この点で、DB層のログは非常に有効です。アプリケーション上の処理内容に関わらず、実際にデータがどう扱われたのかという結果を、事実として確認できるため、内部統制やシステム監査の場面でも重視されると考えられます。
しかしながら、DB層のログだけでは、その操作が業務的に何を意味していたのかまでは分かりません。どの画面操作や業務処理に紐づくものなのか、通常業務なのか例外対応なのかといった文脈は、DBログ単体からは読み取りにくいのが実情です。
加えて、多くのWebシステムでは、データベースへの接続はWebサーバやWASから行われます。そのため、DBログ上では、実際の利用者が誰であっても、アクセス者が「Webサーバ」や「アプリケーション」として記録されるケースが一般的です。この構造により、データ操作の結果は分かっても、「誰の行為だったのか」をDBログだけで特定することは困難になります。
このようにDB層のログは、「何が起きたか」という結果の事実を捉える点では強力である一方、意味や背景、主体を単独で説明できないという特性を持っています。
5． 単一レイヤー視点の限界と、ログがつながらない理由
ここまで見てきたように、Webシステムを構成する各レイヤーには、それぞれ異なる役割と視点があります。
Webサーバ層では「誰が、いつ、どこにアクセスしたか」、
WAS（アプリケーション）層では「そのアクセスが何を意味していたのか」、
DB層では「どのデータが実際に操作されたのか」という事実が主に把握できます。
しかし、いずれのレイヤーも単独では情報が完結しません。一つの層のログだけを見ても、アクセスの背景から結果までを一貫して説明することは難しいのが実情です。この問題が生じる大きな理由は、各レイヤーのログが異なる目的で設計されている点にあります。
Webサーバログは通信管理、アプリケーションログは処理や障害解析、DBログはデータ整合性や復旧を主目的としており、「後から行為全体を追跡する」ことを前提に作られているわけではありません。
さらに、レイヤーをまたぐ際に、利用者の情報や処理の文脈が引き継がれない構造も、ログがつながらない要因となります。たとえば、DB層ではアクセス主体がWebサーバやWASとして記録されるため、Web層で把握できていた利用者情報が、そのままデータ操作と結び付かないケースが一般的です。
この結果、
・誰が操作したのか
・その操作は何を目的としていたのか
・結果としてどのデータがどう扱われたのか
といった一連の流れが、ログ上では分断されてしまいます。
単一レイヤーのログを個別に確認するだけでは、「部分的な事実」は見えても、一つの行為としての全体像を把握することは難しいと言えるでしょう。そのため、内部不正対策や監査、インシデント調査の場面では、「ログがあるのに説明できない」という状況が生じやすくなります。
このような背景を踏まえると、重要なのは「どのログを見るか」ではなく、分断されたログをどうつなぎ、意味と事実を結び付けて捉えるかという視点です。次章では、この課題に対しての考え方や有効なアプローチについて を整理していきます。
6．ログを「つなげて捉える」ための考え方
Webシステム上のアクセスは、本来、ユーザーの操作を起点に、アプリケーション処理を経てデータ操作へと連続して発生するものです。しかし実際には、Webサーバ、WAS（アプリケーションサーバ）、データベースという各レイヤーでログが個別に記録されるため、処理全体の意味や意図が見えにくくなります。
このような状況を踏まえると、ログ設計や監査設計において重要なのは、「どの層で、どの事実を捉えたいのか」を明確にしたうえで、レイヤー間の情報をどのようにつなぐかを考えることです。ログを単体で集めるのではなく、一連の行為として理解できる形で設計する視点が求められます。ただし、この関連付けを運用やログ設計の工夫だけで実現するのは容易ではありません。レイヤーごとにログ形式や粒度が異なり、利用者情報や処理識別子が必ずしも引き継がれるとは限らないためです。
この課題に対して一般的に検討されるのが、セッションIDやトランザクションIDなど、処理を横断して引き継がれる識別子を軸にログを設計するアプローチです。これにより、Webアクセス、アプリケーション処理、データ操作を関連づけて把握できる可能性が高まりますが、設計段階からの対応が前提となる点には注意が必要です。
こうした「ログが分断される」という構造的な課題に対し、ログ取得の仕組みそのものを通じて解決を図る考え方もあります。たとえばBlackBoxSuiteのTraceSeriesに含まれるWAS-Traceは、アプリケーションサーバ上でユーザー（クライアント）とデータ操作を紐づけた形でアクセスログを取得できる仕組みを提供しています。一般的な3階層Webシステムでは、データベース層から見えるアクセス主体はWeb／アプリケーションサーバとなるため、こうしたアプローチは構造的な制約に対応する一例と位置づけられます。
重要なのは、特定の製品や仕組みそのものではなく、ログは後付けではなく、意味づけされた形で設計・取得されるべきものであるという視点です。3階層Webシステムを情報の流れとして捉え直すことが、ログ活用や監査対応を考える際の確かな思考の起点になると考えられます。
BlackBoxSuiteでは、３階層Webシステムでも、
ユーザーとデータアクセスを紐づけてログ取得できます。
Webサイトに公開されていない資料をお
届けしています。
こんな方に最適な資料です。
7．まとめ：3階層を「情報の流れ」として捉えるために
本コラムでは、3階層Webシステムを構成図として理解するのではなく、情報がどのように流れ、どこに痕跡が残るのかという視点で整理してきました。Webサーバ、WAS、データベースはそれぞれ役割が異なり、記録されるログの性質も異なります。この違いを理解することが、ログ設計や監査設計の前提になります。
各レイヤーのログには、見える情報と見えない情報があります。Webログからはアクセスの入口やユーザー情報を把握できますが、どのデータが操作されたのかまでは分かりません。一方、DBログではデータ操作の事実は確認できても、その操作が誰のどの処理に基づくものなのかという文脈は見えにくいケースがあります。
このように、単一レイヤーの視点では「アクセスの事実」は捉えられても、「そのアクセスが何を意味していたのか」を説明しきれない場面が生じやすくなります。その結果、監査対応等の場面で情報がつながらず、判断や説明が難しくなることがあります。これは運用上の問題というより、システム構成と情報の流れを前提とした整理が十分でないことに起因する構造的な課題と考えられます。
重要なのは、ログの有無ではなく、「どの層で、どの事実を捉えているのか」を意識することです。3階層Webシステムを情報の流れとして捉え直すことで、ログ設計や監査設計を考える際の思考の起点が明確になります。今後、自社システムを見直す際には、まず構成と処理の流れを整理することから始めてみてはいかがでしょうか。
お問合せ
BlackBox Suiteは、多くの実績を持つ情報漏洩対策ソリューションです。
ご不明な点はお気軽にお問い合わせください。
利用用途やリスクに応じて、最適なご提案をいたします。