1.1 対象アプリ

作業管理アプリは社員ワークレポート用と協力会社ワークレポート用が分かれているため、対象は合計5アプリです。5アプリすべてに同一の仕組みを実装します。1アプリ目で仕様を確定させ、2〜5アプリ目は同じ構成を展開します。

1.2 利用者区分

ユーザーマスタの権限区分（システム管理者・作業管理者・承認者・一般）と、ユーザー区分（社員・協力会社）に基づく利用者は次のとおりです。本機能は区分によらず全利用者に同一の認証を適用します。

1.3 既存のアカウント運用フローとの整合

既存要件定義（資料6）では次が定義されています。本機能はこれらと矛盾しない形で追加します。

2.1 基本方針

認証コードの発行・保管・照合を、ユーザーマスタのフィールドとアクションだけで実現します。外部サーバーやデータベースは使用しません。

2.2 全体の流れ

2.3 失敗回数の考え方

失敗回数はログインボタンの押下と同時に0へリセットします。したがって、1回のログイン操作あたり5回まで入力を誤ることができます。

2.4 通信環境について

Platio Canvas のWebアプリは通信環境がなければ起動しないため、オフライン時の動作は考慮の対象外とします。認証コードの生成・送信・照合はいずれも通信を前提とした処理であり、アプリが起動できる状況であれば実行可能です。

2.5 複数アプリでの動作

5アプリすべてに同じ仕組みを実装するため、アプリを起動するたびに認証が発生します。複数アプリを使用する利用者（社員作業管理者など）は、アプリごとに認証コードの入力が必要です。

3.1 機能要件一覧

3.2 パラメータ一覧

上記の値は設定項目としては持たず、アクション内に組み込みます。変更にはアクションの修正が必要です。

3.3 通知メール仕様

3.4 異常系

4.1 画面一覧

SCR-03 はモーダル表示でも構いません。実装のしやすさに応じて選択します。

4.2 SCR-02 認証コード入力画面

4.3 画面項目定義（SCR-02）

本画面には業務画面への導線を設けません。ログイン画面へ戻る場合は Platio Canvas 標準のログアウト操作を使用します。

4.4 SCR-03 有効期限切れ画面

4.5 SCR-04 アカウントロック画面

本画面には再送ボタンも認証ボタンも配置しません。ロック中は認証コードを発行しないため（FR-01）、利用者が自力で復帰する導線を持たせない設計とします。

4.6 画面遷移図

5.1 ユーザーマスタへの追加フィールド

既存のユーザーマスタに次の4フィールドを追加します。新規テーブルの作成は行ないません。

認証コードはテキスト型とします。数値型では先頭の0が失われ、6桁を維持できないためです。

5.2 権限設定（アプリ項目一覧への追加行）

既存の「アプリ項目一覧」の形式に合わせた追加行は次のとおりです。

上記は既存資料「_v5_Platioマスタ関係」のアプリ項目一覧へそのまま追記できる形式で記載しています。

5.3 既存フィールドの参照

本機能は既存フィールドを参照するのみとし、変更は行ないません。

6.1 アクション一覧

6.2 ACT-01：ログイン（コード発行）

1. ログインした利用者のユーザーマスタのレコードを取得する
2. ロック状態を判定する。「ロック中」の場合は SCR-04（アカウントロック画面）へ遷移し、以降の処理を行なわずに終了する
3. ランダム関数により6桁の数字を生成し、変数へ格納する
4. ユーザーマスタのレコードを更新する
   　・認証コード ← 生成した6桁
   　・コード送信日時 ← 現在日時
   　・失敗回数 ← 0
5. メール送信アクションを実行する。宛先は当該レコードのメールアドレス、本文に生成した6桁を差し込む
6. SCR-02（認証コード入力画面）へ遷移する

6.3 ACT-02：認証

1. 入力値を変数へ格納する
2. 入力形式を判定する。6桁の半角数字でない場合は E-05 を表示し、失敗回数を加算せずに SCR-02 に留まる
3. ユーザーマスタのレコードを取得する
4. 有効期限を判定する。現在日時 − コード送信日時 が5分を超えている場合は SCR-03（有効期限切れ画面）へ遷移し、以降の処理を行なわずに終了する
5. コードを照合する。入力値 = 認証コードフィールド の場合はステップ6へ、不一致の場合はステップ8へ進む
6. ユーザーマスタのレコードを更新する
   　・認証コード ← 空（クリア）
   　・失敗回数 ← 0
7. SCR-05（ホーム画面）へ遷移して終了する
8. 失敗回数を1加算してレコードを更新する
9. 失敗回数を判定する。5回に達した場合はステップ10へ、5回未満の場合はステップ11へ進む
10. ロック状態を「ロック中」に更新し、SCR-04（アカウントロック画面）へ遷移して終了する
11. E-01 のメッセージと残り試行回数（5 − 失敗回数）を表示し、SCR-02 に留まる

6.4 ACT-03：認証コードの再送

1. ユーザーマスタのレコードを取得する
2. ランダム関数により6桁の数字を生成し、変数へ格納する
3. ユーザーマスタのレコードを更新する
   　・認証コード ← 生成した6桁
   　・コード送信日時 ← 現在日時
   　・失敗回数は更新しない
4. メール送信アクションを実行する
5. SCR-02（認証コード入力画面）へ遷移する

ACT-01 との違いは、失敗回数をリセットしない点のみです（FR-14）。再送で失敗回数が戻る仕様にすると、再送を繰り返すことで無制限に試行できる状態になるため、リセットはログインボタン押下時に限定します。

6.5 ACT-04：ロック解除（運用操作）

専用のアクションは作成せず、マスタアプリの標準的なレコード編集で対応します。

1. システム管理者がマスタアプリでユーザーマスタの該当レコードを開く
2. ロック状態を「解除」に変更する
3. 失敗回数を0に変更する
4. 保存する

この2フィールドはシステム管理者のみ入力可能に設定するため（5.2）、他の権限区分では解除操作を行なえません。

6.6 実装数量

ユーザーマスタが5アプリ共通の場合、フィールド追加は1回で済みます。アプリごとに独立している場合は5回必要です。いずれであるかは、ソウゾウにて着手前に確認します。

6.7 事前確認事項

着手前に Platio Canvas 上で確認する項目です。すでに実績のある機能であれば確認は不要です。

7.1 認証コードフィールドの非表示（最重要）

あわせて、レコード一覧のカード表示・検索結果・CSV出力など、フィールドが露出しうる箇所をすべて確認します。単体テストの必須項目とします（TST-06）。

7.2 認証成功後のコードのクリア

認証に成功した時点で認証コードフィールドを空にします（ACT-02 ステップ6）。クリアしない場合、同じコードで繰り返し認証できる状態が残ります。ログインをやり直せば新しいコードが発行されるため影響は限定的ですが、使用済みのコードを保持し続ける理由がないためクリアします。

7.3 有効期限判定に用いる日時

有効期限は「コード送信日時」と「現在日時」の差分で判定します。この現在日時が端末の時計を参照する場合、端末の日時を変更することで期限判定を回避できる可能性があります。

実務上の影響は小さいため、本開発では対策を行ないません。Platio Canvas の現在日時がサーバー時刻を参照する仕様であれば、この論点自体が発生しません（P-03 で確認）。

7.4 認証を経ないホーム画面への到達

認証コード入力画面から Platio Canvas の標準操作でホーム画面や業務画面へ到達できると、OTPが形骸化します。

P-05 で実際の挙動を確認し、単体テスト（TST-07）で網羅的に検証します。

7.5 本方式で対応しない事項

次の項目は本方式では対応しません。いずれも実装の複雑化に見合う効果が得られないと判断したものです。必要が生じた場合は追加開発としてご相談ください。

8.1 導入前に必要な準備

8.2 利用者への案内が必要な事項

既存スケジュールの「6. 運用マニュアル」への追記をご検討ください。

8.3 定常運用

本方式は外部サーバーを使用しないため、ソウゾウ側での稼働監視・保守は発生しません。運用は高田工業所様の既存のマスタ管理業務の中で完結します。

8.4 想定される問い合わせと一次回答

9.1 役割分担

結合テストで検出された不具合のうち、原因が本開発範囲にあるものはソウゾウが無償で修正します。

9.2 単体テスト観点（ソウゾウ実施）

合計 86ケース程度を想定しています。境界値は「規定値の直前・当該値・直後」の3点を必ず含めます。画面・アクションのテストは5アプリすべてで実施しますが、1アプリ目で仕様を確定させたうえで2〜5アプリ目は差分確認とし、記載ケース数は代表1アプリ分としています。

9.3 結合テストの推奨シナリオ（ふえん様向け参考）

9.4 テスト環境の配慮

失敗回数の上限（5回）についても、テスト環境で一時的に2回等へ変更すると検証が容易になります。同様に、本番反映時の戻し忘れに注意します。

10.1 工数内訳

設計工程は独立して設けず、本書をもって基本設計書とします。外部サーバーの構築・API開発・データベース設計が不要なため、この工数に収まります。

10.2 スケジュール（案）

導入前の準備（8.1）は、開発と並行して高田工業所様側で進めていただく前提です。

10.3 お見積りの前提

上記の金額・期間は、次の前提が成立する場合のものです。前提が崩れた場合は、速やかにふえん様へご連絡のうえ、変更管理（10.4）としてお取り扱いいただきます。

B-01・B-02 はD1（初日）に確認し、その日のうちにご報告します。成立しない場合も着手直後に判明するため、対応の選択肢が残ります。

10.4 変更管理

本書 Ver 1.0 承認後の仕様変更は、次の手順で取り扱います。

1. ふえん様より変更依頼をご連絡
2. ソウゾウにて影響範囲・工数・納期影響を2営業日以内に回答
3. 合意のうえ変更を反映（追加費用が発生する場合は別途お見積り）

11.1 ソウゾウにて決定した仕様

次の項目はソウゾウにて決定しました。この内容で実装します。相違があればご指摘ください。

11.2 ご回答をお願いしたい事項

高田工業所様の環境・運用に依存するため、ソウゾウでは決められない項目です。この2点のみご回答をお願いします。

あわせて、メールの差出人名・件名・本文（3.3）につきましては案を記載していますので、修正のご希望があればご指摘ください（C-03）。ご指摘がなければ記載の案で実装します。

11.3 前提条件

11.4 リスクと対応

A.1 ご依頼事項

A.2 ご回答をお願いしたい事項

高田工業所様の環境・運用に依存するため、ソウゾウでは決められない項目です。この2点のみご回答をお願いします。

メールの差出人名・件名・本文（3.3）は案を記載しています。修正のご希望があればご指摘ください。ご指摘がなければ記載の案で実装します。

A.3 高田工業所様にてご準備いただきたい事項

ふえん様よりお伝えいただきたい事項です。開発と並行して進めていただく前提としています。

A.4 ソウゾウにて実施すること（ご依頼は不要です）

A.5 進め方