応用情報技術者 2012年 春期 午後 問08
スマートフォンで利用するアプリケーションの設計に関する次の記述を読んで、設問1〜3に答えよ。
X社は、国内旅行を取り扱う旅行代理店である。X社では、旅行者が旅行先で利用できる新たなサービスとして、スマートフォン用のアプリケーション(以下、旅先案内アプリという)と、旅先案内アプリが利用する API を開発することにした。
旅行者は、X社が旅行の案件ごとに割り振った案件番号を旅先案内アプリに設定することで、旅行の日程情報と近隣情報を入手し、スマートフォン上に表示させることができる。近隣情報とは、旅行先の付近にあるレストランと観光地に関する情報である。近隣情報には、リスト表示と地図表示の 2 種類の表示方法が用意されている。旅行者は、当日行きたい場所の近隣情報を、事前にチェックを付けておくことができる。
旅行の日程情報表示の例を図1に、近隣情報のリスト表示と地図表示の例をそれぞれ図2と図3に示す。

日程情報表示では、時刻、場所及び行動予定を、旅程順にリスト形式で表示する。リストの項目をタッチすると、その項目の場所に関する近隣情報を検索してリスト表示する。
リスト表示では、各項目についてレストランか観光地かの種別、名称、住所、電話番号、分類、及びチェックの有無を示すチェックボックスが表示される。一つの近隣情報が複数の分類に当てはまる場合、分類は"、"で区切って並べて表示される。チェックボックスをタップすることで、チェックの有無の状態を切り替えることができる。
リストの項目のチェックボックス以外の部分をタッチすると、地図表示に遷移する。
地図表示では、リスト表示でタッチした項目と、チェックボックスにチェックのある項目に関する情報が、地図上に吹出しを使って表示される。吹出しの部分をタッチすると Webブラウザが開き、関連する Webページを参照することができる。
ネットワークへのアクセスを最小限に抑えるために、リスト表示のときに検索して入手した近隣情報は地図表示にも引き渡され、吹出しの表示に利用される。
〔旅先案内アプリの開発方針〕
旅先案内アプリの開発では、複数の提供元による API を組み合わせることで新しいサービスを構築する、a と呼ばれる手法を用いることにした。
旅先案内アプリは、複数の情報にアクセスし、それらを組み合わせて表示する。旅先案内アプリが利用する情報と、それぞれの情報へのアクセス方法を表1に示す。
日程情報と観光地情報は X社のデータベースに保存されている。これらの情報にアクセスする API を新規に開発する。旅先案内アプリは、この API を利用して、X社のデータベースに保存されている日程情報と観光地情報を取得する。地図情報は、近隣情報の地図表示の際に、背景となる地図を表示するために用いる。Y社はレストラン情報のポータルサイトを運営する広告代理店、Z 社はスマートフォン向けの地図情報ライブラリを提供するソフトウェアメーカである。

〔レストラン情報検索のAPI〕
レストラン情報の検索に用いるY社のAPIの概要を図4に示す。

〔近隣情報を取得するAPIの設計〕
当初は、旅先案内アプリがX社。Y社及びZ社のAPIにアクセスし、結果を組み合わせて表示する方式を考えた。しかし、レビュー時の指摘によって、①旅先案内アプリはX社とZ社のAPIにだけアクセスし、Y社のAPIにはX社のAPIの内部処理からアクセスする方式に変更した。
この変更を受けて、新規に開発するX社のAPIは、X社のデータベースから検索した観光地情報と、Y社のAPIから得られたレストラン情報とを組み合わせて近隣情報を作り、結果をXML形式で返すことにした。
X社のAPIのリクエストパラメタを表2に、応答内容を表3に、応答の例を図5に示す。
なお、X社のAPIでは、位置情報は全て緯度・経度で表す。また、Y社のAPI利用時に用いる b の値は X社のAPIの内部の設定として定義しておき、常にその値を用いることとする。


〔プログラムの改修〕
電波が届かないところでも、近隣情報のリスト表示までは操作ができるようにするために、スマートフォン内部に検索結果のコピーを保存することにした。電波が届かないところでも、検索結果のコピーがあるときにはコピーを参照して画面に表示する。この変更に伴い、②近隣情報の表示項目を変更することにした。
設問1:X社のAPIの設計について、(1)、(2)に答えよ。
(1)本文中のa、bに入れる適切な字句を答えよ。
模範解答
a:マッシュアップ
b:アクセスキー
解説
解答の論理構成
-
問題文では「複数の提供元による API を組み合わせることで新しいサービスを構築する、a と呼ばれる手法」と明記されています。
複数 API の統合によって新規価値を生む開発手法は一般に “マッシュアップ” と呼ばれます。したがって a は 「マッシュアップ」 です。 -
続いて「Y 社に利用者登録をすると、登録者専用のアクセスキーが発行される。」および「アクセスキー、緯度、経度、及び検索半径が指定されると、その指定の範囲内にあるレストラン情報を検索し、結果を返す。」とあります。
さらに「Y社のAPI利用時に用いる b の値は X社のAPIの内部の設定として定義しておき、常にその値を用いる」と書かれており、Y社 API 呼び出し時に必須なのは “アクセスキー” です。よって b は 「アクセスキー」 になります。
誤りやすいポイント
- マッシュアップを「API 連携」や「Web サービス統合」などと書き換えると原文引用要件を満たさず減点対象です。
- アクセスキーを「認証キー」「API キー」などと記述すると固有名称の改変になるため失点します。
- b を「アクセスキー」と判断できても、X社 API 内部で固定という記述を見落とし、外部パラメータと誤解するケースがあります。
FAQ
Q: マッシュアップは必ず複数の外部 API を使う場合のみを指しますか?
A: はい。問題文でも「複数の提供元による API」を組み合わせる点が強調されており、一社のみの API 組み合わせではマッシュアップとは呼びません。
A: はい。問題文でも「複数の提供元による API」を組み合わせる点が強調されており、一社のみの API 組み合わせではマッシュアップとは呼びません。
Q: アクセスキーとトークンは同義と考えてよいですか?
A: 用語の使われ方は似ていますが、本設問では「アクセスキー」という名称が公式に示されているため、同義語への置換は不可です。
A: 用語の使われ方は似ていますが、本設問では「アクセスキー」という名称が公式に示されているため、同義語への置換は不可です。
Q: X社 API が Y社 API を内部で呼び出す方式に変更した理由は評価に影響しますか?
A: 設問(1)(2)の解答自体には影響しませんが、利用規約で禁止されているキーの公開を防ぐといった設計上の配慮を意図した変更だと理解しておくと関連知識が整理できます。
A: 設問(1)(2)の解答自体には影響しませんが、利用規約で禁止されているキーの公開を防ぐといった設計上の配慮を意図した変更だと理解しておくと関連知識が整理できます。
関連キーワード: API, マッシュアップ, XML, アクセスキー, キャッシュ
設問1:X社のAPIの設計について、(1)、(2)に答えよ。
(2)表3中のc~eに入れる適切な字句を答えよ(dとeは順不同)。
模範解答
c:分類
d:緯度
e:経度
解説
解答の論理構成
- 表3の「ViewPoint」要素は、レストラン情報と観光地情報を共通スキーマで表現しています。必須項目として
「id」「name」「address」「tel」「url」が既に列挙されており、残りの可変情報が「property0~2」に割り当てられています。 - 【問題文】の「〔レストラン情報検索のAPI〕」には
“検索結果には、店舗ID、店舗名称、分類、住所、電話番号、緯度、経度、及び店舗のWebページのURLが含まれる。”
と明示されており、X社観光地情報にも同種の属性(分類・緯度・経度)が存在すると考えるのが自然です。 - 既に表3で「id」「name」「address」「tel」「url」は固定フィールドとして定義済みです。残る「分類・緯度・経度」を property0~2 に割り当てれば、Y社API/X社DB の全データ項目を漏れなく格納できます。
- 「分類」は観光地・レストランの双方で多値になり得るため、表3の説明欄に“1以上”とある property0 と整合します。
- 緯度・経度は数値 1 個ずつで足りるため、出現回数“1”の property1, property2 に割り当てるのが妥当です。
- 以上から、
c=分類、d=緯度、e=経度
となります(d と e は順不同の条件も満たす)。
誤りやすいポイント
- 「分類」を address や url と混同し、property1/2 に入れてしまうケース。
- 緯度・経度を一つの要素にまとめてしまい、Latitude/Longitude の対を失う設計ミス。
- 表3の“出現回数”を見落とし、多値である「分類」を 1 出現の property1 に割り当てる誤配置。
- Y社APIの項目列挙を読まずに、X社独自拡張だと勘違いして不要データと判断する思い込み。
FAQ
Q: property0~2 の順序は API 利用者側で決め直してもよいですか?
A: いいえ。X社のAPI仕様として定義されているため、利用者は順序・名称を変更せず実装する必要があります。
A: いいえ。X社のAPI仕様として定義されているため、利用者は順序・名称を変更せず実装する必要があります。
Q: 「分類」はレストランと観光地で内容が異なりますが、同一要素で問題ありませんか?
A: はい。文字列として格納し、複数分類は“、”区切りとする仕様なので ViewPoint の種別によらず共通要素で扱えます。
A: はい。文字列として格納し、複数分類は“、”区切りとする仕様なので ViewPoint の種別によらず共通要素で扱えます。
Q: 緯度・経度を属性(@付き)にせず要素にした理由は?
A: 要素にすることで XML パーサの汎用 API で簡単に取り出せるほか、JSON 変換時のキー構造が単純になるためです。
A: 要素にすることで XML パーサの汎用 API で簡単に取り出せるほか、JSON 変換時のキー構造が単純になるためです。
関連キーワード: XMLスキーマ, API設計, ジオコーディング, データ統合
設問2:本文中の下線①について、Y社のAPIにはX社のAPIの内部処理からアクセスする方式にした理由を解答群の中から二つ選び、記号で答えよ。
Y社のAPIにはX社のAPIの内部処理からアクセスする方式にした理由を解答群の中から二つ選び、記号で答えよ。
解答群
ア:X社のWebサーバの負荷が軽くなり、負荷分散の効果があるから
イ:Y社のAPIの仕様変更時にアプリケーションの改修をせずに済ませることができるから
ウ:Y社のAPIの、アクセスキーの貸与や譲渡を禁止する利用規約に抵触するおそれがあるから
エ:Y社のAPIは、スマートフォンからのアクセスを受け付けないから
オ:地図情報表示の画面で、地図が表示されるまでの時間が短くなるから
模範解答
イ、ウ
解説
解答の論理構成
-
変更点の確認
本文には、
「①旅先案内アプリはX社とZ社のAPIにだけアクセスし、Y社のAPIにはX社のAPIの内部処理からアクセスする方式に変更した。」
とあります。つまり、スマートフォン側からは Y 社の API に直接アクセスしない構成へ改めました。 -
Y 社の利用規約を踏まえた理由
本文の「サービスの利用規約(抜粋)」には次の記述があります。
・「アクセスキーを、他の利用者に貸与したり譲渡したりしてはならない。」
・「APIの仕様が変更された場合は、API利用者側で対応を取る必要がある。」
スマートフォンアプリが直接 Y 社の API を呼び出す場合、アクセスキーを端末アプリに組み込む必要があり、アクセスキーを事実上“譲渡”する行為になります。また、仕様変更のたびに配布済みアプリを改修・再配布しなければなりません。 -
解答群との照合
イ:「Y社のAPIの仕様変更時にアプリケーションの改修をせずに済ませることができるから」
→ 仕様変更対応を X 社側のサーバで完結でき、アプリ改修を回避できる。
ウ:「Y社のAPIの、アクセスキーの貸与や譲渡を禁止する利用規約に抵触するおそれがあるから」
→ アクセスキーをスマートフォンに埋め込まずに済み、規約違反を回避できる。
したがって選択すべきは「イ」「ウ」です。 -
他の選択肢を排除
ア:X 社サーバの負荷軽減とは逆に、Y 社との連携部分を X 社サーバで肩代わりするため負荷は増加します。
エ:問題文に「Y社のAPIは、スマートフォンからのアクセスを受け付けない」という記載はありません。
オ:地図描画は Z 社 API が担当であり、Y 社 API の呼び出し方式の変更と直接関係がありません。
誤りやすいポイント
- 「サーバサイド経由=負荷分散」と短絡的に判断し「ア」を選んでしまう。実際には逆効果になる場合もある点に注意が必要です。
- 規約のキーワード「アクセスキー」に目が行かず、仕様変更対応のみに着目して「イ」だけを選ぶミス。二つ選択する設問であることを忘れないようにしましょう。
- 「リアルタイム表示」の規定から「地図表示が速くなる」と連想し「オ」を選択する誤解。リアルタイム要求は表示時刻の明示で対応でき、描画速度とは無関係です。
FAQ
Q: アクセスキーを暗号化してアプリに埋め込めば規約違反になりませんか?
A: 暗号化してもアプリ利用者にキー情報が渡る点は変わりません。利用規約の「貸与や譲渡」に抵触する可能性を排除できないため、安全策としてサーバ側で保持します。
A: 暗号化してもアプリ利用者にキー情報が渡る点は変わりません。利用規約の「貸与や譲渡」に抵触する可能性を排除できないため、安全策としてサーバ側で保持します。
Q: Y 社 API の仕様が大きく変わった場合でもアプリ改修は不要ですか?
A: 基本的には X 社のサーバ側で変換ロジックを修正すれば済みます。画面項目やデータ構造が変わり、スマートフォン側に追加情報を送る必要が生じた場合のみアプリの更新が必要になります。
A: 基本的には X 社のサーバ側で変換ロジックを修正すれば済みます。画面項目やデータ構造が変わり、スマートフォン側に追加情報を送る必要が生じた場合のみアプリの更新が必要になります。
Q: サーバ経由にするとレスポンスが遅くなりませんか?
A: 追加の通信が発生するため遅延は増えますが、キャッシュや並列処理で緩和できます。規約遵守とメンテナンス性の向上を優先した設計判断です。
A: 追加の通信が発生するため遅延は増えますが、キャッシュや並列処理で緩和できます。規約遵守とメンテナンス性の向上を優先した設計判断です。
関連キーワード: APIゲートウェイ, マッシュアップ, アクセスキー, 利用規約, バージョン互換性
設問3:本文中の下線②について、近隣情報の表示項目にどのような変更を加えたか、変更内容を30字以内で答えよ。
近隣情報の表示項目にどのような変更を加えたか、変更内容を30字以内で答えよ。
模範解答
表示項目としてY社のAPIの実行時刻を追加する。
解説
解答の論理構成
- 【問題文】にはオフライン閲覧のための仕様変更が記述されています。
引用:「電波が届かないところでも、検索結果のコピーがあるときにはコピーを参照して画面に表示する。」
ここから、取得したデータを“リアルタイム”ではなく“キャッシュ”から表示するケースが生じることが分かります。 - しかし、Y社 API の利用規約では次の制約があります。
引用:「APIの実行結果をリアルタイムに表示できない場合は、APIの実行時刻を画面に表示する必要がある。」
キャッシュ表示はリアルタイム表示ではないため、この規約に従う追加情報が必須となります。 - したがって、近隣情報の表示項目には「API実行時刻」を新たに載せる必要があります。
以上より、変更内容は「表示項目としてY社のAPIの実行時刻を追加する」と導かれます。
誤りやすいポイント
- 「検索半径」「分類」など既存フィールドの見直しと誤解し、実行時刻の追加を見落とす。
- 旅先案内アプリ側の API(X社)仕様変更と混同し、XML応答要素の追加と勘違いする。
- 規約の引用を読み飛ばし、“リアルタイムでなければならない”という部分だけに注目してしまう。
FAQ
Q: キャッシュ保存した場合、必ずタイムスタンプを表示しなければならないのですか?
A: はい。【問題文】の規約に「リアルタイムに表示できない場合は、APIの実行時刻を画面に表示する必要がある」とあるため、キャッシュ利用時は必須です。
A: はい。【問題文】の規約に「リアルタイムに表示できない場合は、APIの実行時刻を画面に表示する必要がある」とあるため、キャッシュ利用時は必須です。
Q: タイムスタンプはどの画面に表示すれば良いのですか?
A: 規約は「画面に表示する」とだけ定めています。リスト表示・地図表示のどちらでも、利用者が確認できれば要件を満たします。
A: 規約は「画面に表示する」とだけ定めています。リスト表示・地図表示のどちらでも、利用者が確認できれば要件を満たします。
関連キーワード: API利用規約, キャッシュ, タイムスタンプ, オフライン対応, ユーザーインタフェース


