問い合わせ管理システムの更新、チケットと添付の扱いを整理する

問い合わせ管理システムの更新、チケットと添付の扱いを整理する。この記事は2026年10月21日に JPCERT/CC が公表した OTRS Community Edition の認証回避脆弱性に関する情報を踏まえ、問い合わせ管理システムの更新作業やチケット・添付ファイルの取り扱いについて一般的な確認手順を示すものです。

自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

更新対象チケット情報の整理手順

対象チケットの抽出条件を確認

まず、対象となるチケットの抽出条件は、実際に運用している業務フローや担当チームの役割に合わせて決める必要があります。たとえば「新規」や「オープン」だけでなく、他のステータスが対象になるケースや、期限の範囲が異なる場合も考えられます。

固定的に「本日から1週間以内」や「自チームに割り当てられている」だけを基準にすると、実際の業務要件と合わない可能性があります。そのため、抽出条件は担当者に確認し、現行の運用ルールやレビュー基準に沿っているかを確かめることが重要です。

担当者に確認すべき具体的な質問は次のとおりです。

• 現在、チケットのステータスで抽出対象にしているものは何ですか。
• 期限の設定はどのように決めていますか。期間の上限や下限はありますか。
• 担当者の割り当て基準はどのようになっていますか。チーム単位だけでなく、個人やロールでの条件はありますか。
• 抽出結果の保存や共有方法について、社内で決まっている手順やフォーマットはありますか。

これらの質問に対する回答をもとに、抽出条件を見直すことで、実務に即した正確なデータ取得が可能になります。確認した内容は、後続のレビューや変更履歴として記録しておくと、後で条件の根拠を示す際に役立ちます。

添付ファイルの有無とサイズを照合

抽出したチケット一覧から、添付ファイルの有無をスクリプトで取得し、各ファイルのサイズを確認します。上限サイズ（例：50 MB）を超えるものは例外リストに記録し、担当者に通知します。取得に失敗した場合は、OTRS のシステムログにエラー情報と対象チケット ID を記録し、再取得手順を文書化してください。結果は Excel にまとめ、担当者間で共有します。

更新適用前のバックアップ取得方法

バックアップはデータベースと添付ファイルをそれぞれ取得し、適切なツールでダンプ・アーカイブした上で安全な場所に保管してください。使用するコマンドやパスはシステム構成に合わせて確認してください。取得後は復元テストを実施し、復元手順書に成功/失敗の結果を記録します。テストは本番とは別の検証環境で行い、問題がなければ本番適用へ進めます。

チケットステータス遷移ルールの再定義

新ステータス名と遷移条件の設定

担当者はまず、現在利用しているステータスの一覧を取得し、実際の業務フローと照らし合わせて確認してください。新しく追加したいステータス（例として「レビュー待ち」など）が、既存の流れのどこに位置し、どのような条件で遷移すべきかを表にまとめると、抜けや重複が見えやすくなります。この作業は、ステータス変更が業務全体に与える影響を把握するために必要です。

確認すべきポイントとしては、次の質問を担当者に投げかけます。
・現在のステータス一覧はどこに保管されており、最新のものはいつ更新されたか。
・新規ステータスを導入する目的と、具体的にどの業務工程で使用するか。
・既存フローとの間に生じるギャップや、例外的に自動クローズしないケースはどれか。

これらの情報を整理したうえで、関係者の合意を得て設定変更を進めると、後からの不整合や余計な手戻りを防げます。担当者から得た回答や資料は、確認済み項目と未確認項目を区別できるように一覧化して保管してください。

権限別遷移可否の確認手順

権限マトリクスを作成し、ロール（管理者、担当者、閲覧者）ごとに遷移可能なステータスを一覧化します。管理者のみが特定ステータスへ遷移できるケースは、設定変更前にテストユーザーでシミュレーションし、失敗した場合は即座にロールバック手順を実行します。結果は変更履歴に残し、監査用に PDF で保存します。

変更後のステータス表示テスト

テストケースをシナリオ形式で作成し、各ステータス遷移後の画面表示を確認します。例外として非表示項目がある場合は、画面キャプチャを添付し、期待結果と比較します。テストは担当者とユーザー代表が共同で実施し、合格基準を満たしたらユーザー受入テスト（UAT）として完了扱いにします。結果はスプレッドシートに記録し、次回リリース時の改善点として活用します。

添付ファイル管理機能の改善策

ファイル形式制限とウイルススキャン設定

担当者はまず、許可する拡張子のリストを社内の業務要件と法的要件を照らし合わせて作成します。リストに含めない形式はアップロード時にエラーメッセージで拒否し、同時にウイルススキャンエンジン（例：ClamAV）を組み合わせてファイルの安全性を検証します。

例外として、社内専用フォーマット（独自拡張子）については、別途検証プロセスを設け、合格したものだけを例外的に許可します。失敗した場合は、アップロードログにエラーコードとユーザーIDを残し、担当者が後続の対応を追えるようにします。

この手順は、まずテスト環境で数種類のファイルを実際にアップロードし、期待通りにブロックまたは許可されるかを確認します。次に、設定変更を本番環境に反映する際は、変更履歴をバージョン管理システムにコミットし、変更点をレビュー担当に提示して承認を得ます。

最終的に、設定が正しく反映されたことを確認するため、ランダムに選んだユーザーで実際に添付を試み、結果をレポートにまとめます。

添付ファイルの自動削除ポリシー策定

添付ファイルの保存期間は、実際に業務で必要とされる期間や、法務部門が示す保存義務に合わせて決める必要があります。したがって、具体的な日数や年数を一律に決めてしまうと、現場の実情と合わない可能性があります。また、自動削除の実行タイミングや通知方法についても、システムの運用状況や担当者の業務負荷を踏まえて検討すべきです。

この点について、担当者に確認すべきことは次のとおりです。

1. 現在、添付ファイルの保存期間を決める際に参照している社内規程や法的要件は何か。
2. 各種問い合わせや契約関連のファイルについて、実務上どの程度の保存が必要と考えているか。その根拠となる記録や判断基準はあるか。
3. 法的に保存が義務付けられているファイルの特定方法や、例外として扱う条件はどのように管理しているか。
4. 自動削除を実施する場合、実行時間帯や削除対象の一覧をどのように確認・報告するか。担当者が想定している手順や、必要な承認フローがあれば教えてください。

これらの質問に対する回答をもとに、実際の業務フローに合った削除ポリシーを策定し、関係者全員が共有できる文書を作成することが重要です。

削除実行後は、削除ログにファイル名、削除日時、実行者（システムユーザー）を記録し、監査証跡として保存します。万が一削除が誤って行われた場合に備えて、直近のバックアップから復元できるよう、バックアップ保持期間と復元手順を別途ドキュメント化し、担当者が定期的に復元テストを実施します。これにより、削除ポリシーが適切に機能していることを検証できます。

ダウンロード権限の細分化手順

まず、ダウンロード権限をロールごとに細かく分けることは、実際の業務フローや利用者の業務範囲に合わせて検討すべき項目です。たとえば「社内エンドユーザーは自分が担当したチケットの添付のみダウンロード可」という設定は、担当者がどの程度の情報を必要としているか、また情報漏洩リスクをどう評価しているかによって変わります。

したがって、権限の分け方を決める前に、各ロールの業務内容と情報取扱いの方針を確認する必要があります。

担当者に確認すべき具体的な質問は次のとおりです。

1. 各ロール（エンドユーザー、管理者、外部提供元など）が実際に必要とする添付ファイルの範囲はどこまでか。
2. それぞれのロールに対して、現在の権限設定で問題が生じている事例や懸念点はあるか。
3. 外部提供元に対しては、どのフォルダやファイルに限定したアクセスが契約上求められているか、またその根拠となる文書はあるか。

これらの回答をもとに、権限設定の方針を整理し、必要に応じて追加の検証や関係者との合意を取ることが、適切な権限管理につながります。

設定後は、テストユーザーを用意して権限テストを実施します。テストケースは「許可されたロールが正しくダウンロードできるか」「許可外のロールがエラーメッセージでブロックされるか」の2パターンを含め、結果をチェックリストに記録します。テストが全て合格したら、変更内容を本番環境へ適用し、適用後も定期的に権限レビューを行い、不要な権限が残っていないかを確認します。

更新作業の検証とリリース手順

ステージング環境での機能確認項目

担当者は、本番とは別の検証環境にて実施する機能確認チェックリストを作成します。項目例は「チケット検索が正しく動作するか」「添付ファイルのアップロード・ダウンロードが問題なく行えるか」「ステータス遷移が設定通りに反映されるか」などです。

本番とは別の検証環境は本番環境に近い構成で用意し、実データを使用する場合は個人情報等を適切にマスクまたはサンプルデータに置き換えてください。例外として、本番データを直接使用しないことを徹底し、データ漏洩リスクを回避します。

確認作業は、担当者が手順書に沿って順番に実施し、各項目の結果をスプレッドシートに記録します。失敗が見つかった場合は、ロールバック手順（DBリストア、ファイルストレージの復元）を即座に実行し、原因を分析して修正後に再度テストを行います。全項目が合格したら、ステージング完了報告書を作成し、リリース承認者に提出します。

本番適用時の障害切り分けフロー

本番適用時は、事前に障害シナリオを列挙したフローチャートを用意します。代表的なシナリオは「アップデート後にチケットが表示されない」「添付ファイルのダウンロードがタイムアウトする」などです。障害が発生した場合は、まず監視ツールでシステムログとアプリケーションログを確認し、エラーメッセージの有無をチェックします。

ネットワーク障害が疑われる場合は、外部接続テストを実施し、問題がアプリケーション側かインフラ側かを切り分けます。

障害が特定できたら、担当者は即座にロールバック手順に従い、バックアップから復元します。復元後は、再度ステージングで実施したテストを本番環境で実行し、正常化を確認します。障害対応の経緯は障害報告書に詳細に記載し、次回リリース時の改善策としてチーム全体で共有します。

リリース後の利用者フィードバック取得方法

リリース完了後は、利用者からのフィードバックを体系的に収集します。担当者は、簡易アンケート（例：満足度5段階、改善要望自由記述）とシステムログの分析を組み合わせ、利用状況と問題点を把握します。アンケートはメールや社内ポータルで配信し、未回答者にはリマインドを送ります。

ログ分析は、添付ファイルのダウンロードエラーやステータス遷移の失敗を自動抽出し、レポートにまとめます。

取得した情報は、改善項目リストとしてまとめ、次回のリリース計画に反映させます。検収は、担当者が改善項目の実装確認と利用者承認を得た上で完了とし、最終的にリリース完了報告書に署名捺印します。これにより、リリース後の品質向上サイクルが確実に回ります。