応用情報技術者 2020年 秋期 午後 問04

解答の論理構成

1. 必要な連続測定時間の把握
   問題文には、 「1日24時間の総消費カロリーを推測するために、1日23時間30分以上の活動量計の測定データが必要である。」
   とあります。したがって、1 日当たり許容される測定データの欠損（＝サービス中断）は
   24 時間 − 23 時間 30 分 ＝ 30 分 です。
2. 稼働率（可用性）の定義
   稼働率 ＝ (総運用時間 − 中断時間) ÷ 総運用時間 × 100 (%)
3. 数値の代入
   総運用時間：1日24時間 ＝ 1,440 分
   中断時間：30 分
   稼働率 ＝ (1,440 − 30) ÷ 1,440 × 100
   ＝ 1,410 ÷ 1,440 × 100
   ＝ 0.979166… × 100
   ＝ 97.9166… (%)
4. 桁数指定に従った丸め
   問題文の指示「小数第2位を四捨五入して小数第1位まで」に従い、 97.9166… (%) → 97.9 (%)

誤りやすいポイント

• 「30 分」を「0.03 日」などと日単位に直さず、分単位や時間単位で計算してしまい誤差を出す。
• 稼働率算出時に「中断時間／総時間」を直接 100 から引かず、逆順で計算ミスをする。
• 四捨五入の位置を誤り、小数第2位を残してしまう。
• 可用性と耐障害性を混同し、故障対応時間まで含めてしまう。

FAQ

解答の論理構成

1. 前提整理
   【問題文】には、測定データについて
   ・「活動量計から1回の測定で100バイト、毎分100回の測定データが生成される。」
   と記載されています。サービス中断がない前提なので、この条件が1日中継続すると考えます。
2. 1分間に生成されるデータ量
   100バイト/回 × 100回/分 ＝ 10,000バイト/分
3. 1時間当たりのデータ量
   10,000バイト/分 × 60分/時 ＝ 600,000バイト/時
4. 1日当たりのデータ量
   600,000バイト/時 × 24時/日 ＝ 14,400,000バイト/日
5. 単位換算
   1Mバイト＝1,000,000バイトなので
   14,400,000 ÷ 1,000,000 ＝ 14.4Mバイト
6. 結論
   したがって、1日に生成される測定データは 14.4Mバイト です。

誤りやすいポイント

• 「毎分100回」を「毎分1回」と読み違えてしまう。
• 1Mバイト＝1,024,000バイトと誤って2進換算で計算してしまう。
• 24時間の掛け忘れ、または60分と24時間の積算順序を混同して計算ミスを起こす。

FAQ

解答の論理構成

1. [問題文]の該当箇所
   “測定データをクラウドへ保存する処理は、業務処理量とaの品質を考慮して、再実行を2回行う余裕をもたせる。”
   ここで a に入る語を決定する必要があります。
2. [問題文]の非機能要件（可用性―耐障害性）に、次の記述があります。
   “活動量計からクラウドまでのネットワークが切断されている間も測定データは消失しない。”
   すなわち、測定データ保存処理は “ネットワーク” の切断や遅延による失敗を想定して再実行できる設計が求められています。
3. よって、保存処理の品質面で特に考慮すべき要素は “ネットワーク” であると判断できます。
4. 以上より、a に入る字句は “ネットワーク” が最適です。

誤りやすいポイント

• “クラウド” や “データベース” と誤答するケース
  → 再実行が必要なのは転送経路である “ネットワーク” の不安定さに備えるためです。
• “性能” という抽象語で済ませてしまうケース
  → 文中で “業務処理量とaの品質” と書かれており、同列で扱われる具体要素として “ネットワーク” を指し示しています。
• “可用性” と混同するケース
  → 可用性は大分類であり、空欄には具体的な品質特性が入る必要があります。

FAQ

解答の論理構成

1. 【問題文】ではセキュリティの非機能要件として
   ・「個人のヘルスケアデータという機微な情報を取り扱うので、情報の漏えいや盗聴を防ぐ対策も重要である。」
   と記載されています。
2. さらにアクセス制限の具体策として
   ・「クラウド上のWebサービスでの利用者の認証には、IDとパスワードによるログインに加えて、①ショートメッセージサービスや電子メールからの確認コードによる認証も用いる。」
   と明示されています。
3. ID・パスワードだけでは不正ログインのリスクが残るため、確認コードという第2要素を追加し、利用者本人以外がアクセスしにくい仕組み（多要素認証）を実現します。
4. その目的は、機微なヘルスケアデータを守り「情報の漏えいを防ぐ」ことに他なりません。
5. 以上より、20字以内で要旨をまとめた解答は「機微な情報の漏えいを防ぐため」となります。

誤りやすいポイント

• 「利便性向上」や「なりすまし防止のみ」と答えてしまい、情報漏えいという最終目的を明示しない。
• 「二要素認証を実現するため」と技術名だけを書き、目的を説明しない。
• 活動量計側の暗証番号と混同し、SMS確認コードの意義を取り違える。

FAQ

解答の論理構成

1. 【問題文】ではデータベース選定理由として
   “データベースは、②新サービスのデータ特性からKVS（Key Value Store）を採用する。”
   と記載されています。
2. KVS は「キー」と「値」の単純なペアで高速に読み書きできる構造が特徴です。
   典型的なキーは “ユーザ ID ＋タイムスタンプ” など、個々の利用者を識別するキーになります。
3. 新サービスの要件を見ると、 ・“歩数や心拍数などの測定データを長期間保存して、…利用者の日々の総消費カロリーをグラフで示す。”
   ・“事前登録した身長や体重、目標体重などの情報から、利用者に適切な運動種目と時間を提案する。”
   とあるように、データは利用者ごとに蓄積・分析されます。
4. また性能要件には
   “利用者数は最大10万人を見込む。”
   とあり、多数利用者のデータをユーザ単位で独立に扱う必要があります。
5. これらから②は「新サービスの利用者単位でデータを収集、分析する特性」に該当し、解答群ではイが適切です。

誤りやすいポイント

• “リアルタイム収集だからエ” と速断する
  → KVS 採用理由はリアルタイム性能だけでなく、キーの粒度（ユーザ単位）に適合するかが主眼。
• “自由形式のデータだからウ” と誤認する
  → 今回のデータは数値や画像で構造が大きく変わるわけではなく、ユーザキーで整理できる。
• “利用者間で集計するからア” と考える
  → サービス説明は個人向けフィードバックが中心で、横断的な統計は主要要件ではない。

FAQ

解答の論理構成

1. 【問題文】ではクラウド直接方式について
   「活動量計にモバイル通信サービスを利用するためのモジュールやカメラなどを組み込み…リストバンド型の形状やサイズを維持するために、データ入力や画面表示方法を工夫する必要がある。」
   と記載されています。
2. さらに従来機の仕様は
   「横10文字、縦2文字のモノクロ液晶画面」「四つのボタン」
   しか入力・表示手段がなく、写真撮影用のカメラもありません。
3. 新サービスでは
   「総消費カロリーをグラフで示す」「飲食した内容を文字や写真で記録する」
   など高度な入出力が求められます。
4. リストバンド型という厳しい筐体制約の下で、グラフ描画・写真撮影・文章入力を実装するのは困難であり、これが「活動量計の柔軟性と拡張性に課題がある」原因です。
5. 解答群のうち入力・表示の困難さを端的に表しているのは
   「ア：グラフや写真の画面表示や文章データの入力は実現が難しい。」
   であり、他の選択肢は測定ロジックや提案機能に関する内容で趣旨が異なります。
6. したがって解答は【ア】となります。

誤りやすいポイント

• “拡張性”をデータ解析機能の不足と誤解し「イ」や「ウ」を選択してしまう。拡張性はハード／UIの追加容易性を指すことが多い。
• 「USBなどの入出力ポート」の有無（選択肢エ）に目を取られがちですが、問題文は画面表示と入力方法の制約を強調している。
• 「柔軟性＝ソフト更新のしやすさ」と考え、分析アルゴリズムの難易度に着目してしまう。

FAQ

解答の論理構成

• 【問題文】では、活動量計のメモリについて「測定データ記録用のメモリ容量は64Mバイトあり、使用中のメモリが一杯になったときには、データの古いものから順に新しいデータに上書きされる。」と記載されています。
• 同じく【問題文】でモバイル端末経由方式の安定性向上策として「活動量計とモバイル端末が通信できない最大許容日数を7日間としてシミュレーションした」とあります。
• 7日間分のデータを一度もモバイル端末へ転送できなかった場合、上記の“上書き”仕様により、古い測定データが削除される可能性があります。
• さらに、非機能要件には「活動量計からクラウドまでのネットワークが切断されている間も測定データは消失しない。」という要求が示されています。つまりデータ消失は要件違反となります。
• 以上より、最大7日間連携できない条件下で「クラウド上に保存していない測定データ」がメモリ上書きにより失われる点が問題であり、模範解答のとおりとなります。

誤りやすいポイント

• 「通信できない最大許容日数を7日間」とあるため“7日分丸ごと失われる”と早合点しやすいが、真の問題は“上書きにより未送信データが一部でも失われる”ことです。
• 非機能要件の「耐障害性」を見逃し、メモリ容量や上書き仕様と結び付けられないケースが多いです。
• 「モバイル端末のバッテリー切れ」がキーワードに見えるため、端末側のデータ損失と勘違いしやすいですが、今回の問題は活動量計側で発生します。

FAQ

解答の論理構成

1. 測定データ生成量の確認
   【問題文】「活動量計から1回の測定で100バイト、毎分100回の測定データが生成される。」
   → 1分当たり 100バイト × 100回 = 10,000バイト
   → 1日当たり 10,000バイト × 60分 × 24時間 = 14,400,000バイト（約14.4 MB）
2. 現行メモリ容量の把握
   【問題文】「測定データ記録用のメモリ容量は64Mバイト」
   → 約4.4日でメモリが一杯になる計算
3. オフライン許容期間とのギャップ
   【問題文】「活動量計とモバイル端末が通信できない最大許容日数を7日間」
   → 必要容量は 14.4 MB × 7日 ≒ 100.8 MB
   → 現行の 64 MB では不足し、【問題文】「④ある問題」が“メモリ不足によるデータ消失”であると推定
4. クラウドやWebサービスは変更不可
   【小問説明】「クラウド上のデータ及びWebサービスには変更を加えないこと。」
   → 対策は活動量計本体側のみで完結させる必要
5. 導出される変更内容
   不足分を補うには本体メモリを増設するしかない
   → 解答「活動量計本体のメモリ量を7日分以上に増やす。」

誤りやすいポイント

• バッファリングをモバイル端末側で済ませると誤解し、活動量計のメモリ不足を見落とす
• 「再実行を2回行う余裕」「暗号化でサイズ不変」など他要件を絡めてしまい、本設問の焦点を外す
• メモリ増設以外（圧縮・測定間隔変更など）の策を提示し、クラウド要件不変更の条件を満たさなくなる

FAQ