令和7年度 春期 応用情報技術者試験 午後 問8 エラーハンドリングの設計

【解説】 業務運用の開始後に想定外の不具合が発生した場合、限られた情報を頼りに対応を行う必要があるため、エラーハンドリングの機能を設計時に考慮しておくことが望ましいです。本問ではCRMシステムの設計を題材にオブジェクト指向の基本概念を問うています。スーパークラスの特性（属性やメソッド）をサブクラスが引き継ぐ仕組みを継承と呼びます。エラーハンドリング機能において、共通の処理を抽象クラスに定義し、各具象クラスでそれを継承して利用することで、設計の共通化と再利用性の向上が図られます。 【高得点のポイント】 ・オブジェクト指向の基本用語である「継承」を文脈に合わせて正しく導出できていること。

【解説】 エラーログなどの記録において、各事象を一意に識別するための識別子が必要です。図1や図2の文脈において、各処理やログレコードを紐付けるために利用されるのがID（識別子）です。障害調査の際には、このIDをキーとして関連するログを抽出します。 【高得点のポイント】 ・ログやレコードの一意性を担保する項目として「ID」を特定できること。

【解説】 セキュリティ監査やエラー調査において、ログインの成功・失敗の履歴は非常に重要です。図2のエラー処理フローにおいて、認証に関連する記録としてログイン認証の判定結果をログに残すことが求められます。これにより、不正アクセスの試みや認証エラーの原因究明が可能になります。 【高得点のポイント】 ・認証処理に関するログとして必要な情報（ログイン認証の判定結果）を正しく補完できること。

【解説】 エラーハンドリングにおけるシステムエラーの出力先について、誰がその情報を必要とするかを問う問題です。システム内部の異常や詳細なエラーログは、システムの維持管理を担う運用担当者や、不具合の調査・修正を行う開発担当者に向けた情報です。 【各選択肢の解説】 ・顧客: システムの利用者側であり、詳細なシステムエラー情報を提示するのはセキュリティ上も適切ではありません。 ・利用者: 顧客と同様に、システムの内部情報は不要です。 ・運用担当者: 正解。システムの監視や一次対応を行うため必要です。 ・開発担当者: 正解。障害の根本原因を調査・修正するために必要です。

【解説】 「システム障害」とは、システムが提供するべき機能を果たせなくなった状態を指します。データベースへの接続不可などは、システム全体の機能停止に直結する重大な障害です。したがって、データベースの接続確認の結果を監視することは、システム障害の検知に直結します。 【各選択肢の解説】 ・ア: エラーメッセージはユーザー向けであり、システム全体の障害監視としては不十分です。 ・イ: 正解。データベース接続はシステムの基幹であり、これが失敗することはシステム障害を意味します。 ・ウ: 電子メール送信履歴は個別の業務結果であり、障害監視の直接的な指標ではありません。 ・エ: ログ種別の文字列はエラーの分類に用いるもので、障害そのものの監視対象としては適切ではありません。 ・オ: ログファイルのサイズは容量監視には有効ですが、システム障害の即時検知には向きません。

【解説】 「システムエラー」とは、システムの機能や挙動に直接的な影響は与えないものの、内部的に発生した異常や状態変化を指します。これを捉えるためには、出力されるログの中に含まれるエラーレベルやログ種別の文字列（例：ERROR, WARNINGなど）を監視し、異常を検知することが有効です。 【各選択肢の解説】 ・ア: 画面のエラーメッセージはユーザー操作による業務エラーの可能性もあり、システムエラーの確実な監視対象とはいえません。 ・イ: これはシステム障害の監視に該当します。 ・ウ: 個別の処理結果であり、システム全体のエラー監視指標ではありません。 ・エ: 正解。ログ種別（エラーレベル等）の文字列を監視することで、システムエラーを適切に拾い上げることができます。 ・オ: ログの肥大化は監視できますが、エラー内容の検知はできません。

【解説】 システムエラーの出力先として、誰に対して情報を提示するべきかの判断が問われます。不特定多数や一般利用者が目にする可能性のあるエラーメッセージ表示には、詳細な内部情報を出力すべきではありません。そのため、変更対象となる出力機能は「エラーメッセージ表示」となります。システムが出力する情報は必ずしも多ければよいわけではなく、対象者に応じた適切な判断が必要です。 【高得点のポイント】 ・対象となる出力機能が「エラーメッセージ表示」であることを正しく特定できていること。

【解説】 運用担当者や開発担当者向けの詳細なシステムエラー情報は、攻撃者にシステムの内部構造（脆弱性のヒントなど）を教えることになりかねません。そのため、一般の利用者が目にする画面上には、エラーの詳細情報を出力しないように変更する必要があります。情報の受け手に合わせた出力内容の制御が重要です。 【高得点のポイント】 ・エラーの詳細情報を画面等に出力しないようにするという変更内容が含まれていること。 ・利用者に不要かつ機密性の高い情報を見せないという意図が反映されていること。

【解説】 アスペクト指向プログラミング（AOP）を導入することで、ログ出力やエラーハンドリングといった横断的な関心事を分離できます。本文の構造上、各コントローラで共通して行われるべき例外補足や処理は、それらの親となるAbstractControllerに集約するか、AOPの仕組みを用いて共通化されます。文脈から、共通のコントローラ基底クラスであるAbstractControllerが該当します。 【高得点のポイント】 ・AOPの適用対象または共通処理の集約先として「AbstractController」を正しく導出できること。

【解説】 ログを出力する際、どのクラスでエラーや例外が発生したかを特定することは、原因調査において不可欠です。AOPを利用してログ出力を一元化する場合でも、実行時の情報から発生元のクラス名を取得し、ログに含める必要があります。 【高得点のポイント】 ・エラー発生箇所を特定するために必要な情報として「クラス名」を挙げられること。

【解説】 システムに関連する情報について、誰が参照する可能性があるのかを見誤ると重大なセキュリティインシデントを引き起こしかねません。ログの参照権限を持つのが運用担当者だけでなく、開発担当者も参照する場合、開発環境や委託先などに機密情報が流出するリスクが高まります。そのため、参照範囲を考慮して機密性の高い情報はログに出力しない設計が必要です。 【高得点のポイント】 ・ログの参照者に「開発担当者」が含まれていることを指摘できていること。 ・情報の参照可能性に起因するセキュリティリスクを回避する意図が読み取れること。