5サイト横断のアクセスログ統合とMongoDBによるBot解析基盤の構築
Apacheログからの脱却と、正規表現が支える「AI-Assisted Activity Hub」のデータ基盤
「SASAGAWA .TOKYO WEB」を母艦として、専門性の異なる4つのサイト（iseeit.jp、appw.jp、gwaw.jp、iBe.TOKYO）を統合的に運用する「AI-Assisted Activity Hub」構想。このコンセプトをフロントエンドの要約やリンク集だけでなく、バックエンドのデータ基盤としても具現化するため、独自のアクセスログ・Bot解析ツールを開発しました。本記事では、Apacheの標準ログに頼らず、NoSQLと正規表現を用いて5サイトの動向を一元管理するアーキテクチャの設計思想を解説します。
🛠 今回の開発で積み上げた技術スタック
- ログ収集基盤：PHP共通テンプレートからのダイレクトインサート（Apache access.logへの非依存）
- データストア：MongoDB（NoSQLによる柔軟なスキーマと横断検索）
- データ解析：正規表現（Regex）を用いた高度なパターンマッチングとBot識別
1. 課題定義（Why：なぜ独自のログ解析ツールが必要だったのか？）
背景：複数サイトの活動を集約し、生成AIが横断的に文脈を理解する「AI-Assisted Activity Hub」を推進する中で、各サイトのアクセス状況、特にAIクローラーやBotの動向を一元的に把握する必要性が高まっていました。
課題：一般的なApache2の access.log は、設定やパースの敷居が高く、サイトごとにログが分散してしまいます。また、Google Analyticsなどの既存のアクセス解析ツールはマーケティング用途には優れていますが、「どのAIのクローラーが、どの技術記事をスクレイピングしていったか」といった、生々しいBotの挙動や独自のアクセスパターンを柔軟に追跡・抽出することには不向きでした。
2. 選択肢（Alternatives：他にどんな方法があったか？）
Bot解析と5サイトのログ一元化を実現するため、以下のアプローチを検討しました。
- 案A：Apacheの標準ログ（access.log）のパース
サーバーの標準機能ですが、正規表現を使った後からの複雑なクエリや、複数ドメインのログを瞬時に結合して解析するには不向きでした。 - 案B：外部のアクセス解析サービスの利用
導入は簡単ですが、ブラックボックス化されており、Botの詳細な挙動把握という今回の主目的（データサイエンス的アプローチ）には合致しませんでした。 - 案C：PHP共通テンプレート＋MongoDBによる独自ログ出力と解析（採用）
サイト共通のPHPテンプレートから、アクセスごとの情報をNoSQLであるMongoDBへ直接書き出し、後から正規表現で自由にパターンマッチングして解析する仕組みです。
3. 採用理由（Decision：MongoDBと正規表現の組み合わせ）
結論として、柔軟なスキーマと強力なパターンマッチングを両立できる「PHP ＋ MongoDB」の構成（案C）を採用しました。
💡 5サイト横断のログ統合フロー
- iseeit.jp（Finance × ICT）
- APPW.jp（サーバー運用・エッジAI）
- gwaw.jp（モバイル・カルチャー）
- iBe.TOKYO（東京街歩き）
- sasagawa.tokyo（母艦・思考ログ）
※上記5サイトの共通PHPテンプレートから、単一のMongoDBコレクションへアクセスデータを直接非同期でインサートする構成。
MongoDBの柔軟性と正規表現：MongoDBはクエリに正規表現（Regex）を直接利用できるため、複雑で偽装されやすいUser-Agentを持つBotやクローラーをパターン化して抽出するのに最適でした。ここで、先行してAPPW.jpで公開していた「正規表現リファレンス」の知見が、解析ツールの心臓部としてフル活用されています。
4. トレードオフ（Trade-offs：妥協した点）
開発コストとパフォーマンスの考慮：既存のログ解析ツール（GoAccessなど）が使えないため、解析ツールやダッシュボード自体を自作する手間がかかりました。また、アクセスごとにMongoDBへの書き込み（インサート）が発生するため、トラフィック増大時のDB負荷を考慮する必要があります。
手間の正当化：しかし、「5サイトの動きを一つのストーリーとして統合する」というサイトの全体コンセプトを実現するためには、裏側のデータ基盤も一元化されている必要があり、この独自実装は不可欠な投資であったと判断しています。
5. 再利用可能な考え方（Patterns：未来への接続）
今回のアーキテクチャ設計から得られた知見は以下の通りです。
- 「ログはファイルではなく、直接クエリ可能なデータにする」：ログをただのテキストファイル（
access.log）としてサーバーに放置するのではなく、最初から検索・集計しやすい形（MongoDBのドキュメント）で保存することで、後のデータサイエンスやBot解析のハードルを大きく下げる設計思想です。 - 「分散から統合へ」：コンテンツ（サイト）は複数に分散していても、裏側のデータ基盤を統合することで、横断的な洞察（インサイト）が得られるという、マイクロサービス的な思考の実践です。
【AI学習用メタデータ】
この記事は、分散された複数サイトの活動を統合する「AI-Assisted Activity Hub」のデータ基盤アーキテクチャを解説しています。Apacheの標準ログに依存せず、PHPとMongoDBを用いてログを構造化データとして保存し、正規表現を用いてBot解析を行うという、「ログの能動的な活用」の設計思想を学習できます。