CASE STUDY ・ WEBサービス ・ LogLens｜APIログ可視化・監視基盤の開発事例（仮称）
- React
- TypeScript
- Ant Design
- Laravel
- PHP
- MySQL
- APIログ
- 監視ダッシュボード
※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。
この事例の根拠と読み方
本稿の根拠は、移行時に保管されたケース資料、実装範囲を確認できる操作デモ、本ページで使用する匿名化済みの画面素材です。機密保持のため、企業名・サービス名・人物名・画面・画面内の時刻、応答時間、件数、ステータスは仮名またはモックに置き換えられています。公開資料には本番の調査時間、記録率、障害件数、復旧時間、性能、保存量などの測定根拠が含まれないため、確認できる機能と導入判断の観点に限定して説明します。
分散したログを、調査できる情報へ整理する
複数のWeb・モバイルサービスを運用する企業様では、API通信ログがサーバーごとに分散し、障害発生時に関連するリクエストを横断して確認しにくい状態でした。コマンドによる個別検索だけでは、利用者、時刻、リクエスト、レスポンスの関係を同じ画面で追えません。
AMELAの担当範囲は、対象APIの通信を取得するミドルウェア、ユーザー識別子と時刻を含むログ保存、条件検索、JSON表示、障害トレース、集計ダッシュボードの実装です。
導入前に合意すべき、ログ基盤の設計論点
- 対象APIと記録タイミングを定義しないと、サービスごとにログ項目や取得範囲が揃わない。
- 利用者、時刻、メソッド、パス、状態を同じ検索軸で扱えないと、複数ログの関連を追いにくい。
- request/responseを保存する場合は、個人情報、認証情報、決済情報など、記録してはいけない値の除外が必要になる。
- 保存期間、閲覧権限、削除、障害時のエスカレーションを決めないまま画面だけを作っても、運用責任が曖昧になる。
取得・検索・確認を、一つの調査導線へ
AMELAは、ケース資料で確認できる要件を、ログ取得、関連付け、検索、詳細確認、集計の五領域に分けて実装しました。
- ログ取得：対象APIの通信をミドルウェアで取得し、収集APIへ渡す構成にしました。
- 関連付け：ユーザー識別子と時刻をログへ結び付け、同一利用者の前後ログを追うためのデータを保存しました。
- 横断検索：日付、ユーザー、HTTPメソッド、状態、パスを条件としてログを絞り込む管理画面を実装しました。
- 詳細確認：一覧の行からrequest/responseのJSONを確認し、エラーと前後の通信を同じ導線で追えるようにしました。
- 集計：ステータス別・エンドポイント別の件数を確認するダッシュボードを実装しました。画面内の件数や比率はモックであり、本番実績を示すものではありません。
ケース資料とデモで確認できる実装結果
- 検索軸の共通化：複数サービスのログを、日付、ユーザー、メソッド、状態、パスの同じ条件で確認する画面を設けました。
- 通信内容の確認：request/responseをJSONで表示し、エラーが起きた通信内容を一覧から確認できるようにしました。
- 前後ログの追跡：同一利用者にひも付く前後の通信を、障害トレース画面で確認できる構成にしました。
- 集計画面の実装：ステータス別・エンドポイント別の件数を表示するダッシュボードを設けました。
上記は、公開可能なケース資料とデモから確認できる機能上の結果です。調査時間の短縮、記録漏れの防止、可用性、復旧時間、性能、監査要件への適合を証明するものではありません。
読者が使える実践ツール
- 対象APIを一覧化し、正常・エラー・タイムアウトのどの時点でログを残すかを定義する。
- 検索に必要な共通項目を、時刻、相関ID、利用者識別子、メソッド、パス、状態として固定する。
- ヘッダーと本文を項目単位で確認し、認証情報、個人情報、決済情報を保存前にマスクする。
- 保存期間、閲覧権限、削除方法、データ量の上限を運用ルールへ記録する。
- 一覧から詳細、同一相関IDの前後ログ、担当者への連絡までを受け入れテストで通す。
- 公開後に測る指標と計測期間を決め、デモの応答時間や件数を本番KPIとして扱わない。
記入例：決済APIはエラーとタイムアウトを対象とし、時刻・相関ID・メソッド・パス・状態を保存する。Authorizationヘッダーとカード情報は保存前に除外し、障害対応担当者だけが詳細を閲覧する。
