応用情報技術者 2012年 春期 午後 問08

解答の導き方

1. 問題文に「複数の提供元によるAPIを組み合わせることで新しいサービスを構築する」とあります。
2. この説明は、外部の複数の公開APIやデータを組み合わせて新しい機能や価値を生み出す手法を指しています。一般にこの手法はマッシュアップと呼ばれます。つまり「複数の提供元のAPIを組み合わせる」→ マッシュアップ、が対応します。
3. 補強証拠として、表1に旅先案内アプリがX社のAPI、Y社のAPI、Z社のAPIを使って情報を集めている点があり、これは複数の提供元を組み合わせる典型例です。以上よりaは「マッシュアップ」です。

1. 図4の(1)に「Y社に利用者登録をすると、登録者専用のアクセスキーが発行される。発行されたアクセスキーと検索条件を指定してAPIを呼び出すと、検索結果を得ることができる。」と明記されています。
2. また本文に「Y社のAPI利用時に用いる b の値はX社のAPIの内部の定数として定義しておき、常にその値を用いることとする。」とあり、Y社が発行する認証情報を指す語を入れる必要があります。図4の記述と照合すると、この語は「アクセスキー」です。
3. したがってbは「アクセスキー」です。

誤りやすいポイント

• 「マッシュアップ」と意味が近い語（例：API連携、Webサービス統合、サービス統合）を見て迷うこと。意味が合致すれば評価されることもありますが、設問文の記述に最も対応する標準用語は「マッシュアップ」です。
• [b] に対して「APIキー」「認証キー」「トークン」などの語を用いる誤り。これらは概念的に近いので採点者により許容される場合がありますが、問題文と図4で明示されている語は「アクセスキー」です。
• 設問の前後にある「X社がY社のAPIに内部からアクセスする」という設計変更（①）を読み違えて、aを「プロキシ」や「ゲートウェイ」などのネットワーク機能名で答えてしまう誤り。設問のaは手法名（複数の提供元のAPIを組み合わせる手法）を問うています。
• 表記の揺れ（英語表記や略語）による戸惑い。問題文中の語句と意味が同じかをまず確認し、可能なら問題文の語句を使うと安全です。

FAQ

解答の論理構成

1. 表3の「ViewPoint」要素は、レストラン情報と観光地情報を共通スキーマで表現しています。必須項目として
   　「id」「name」「address」「tel」「url」が既に列挙されており、残りの可変情報が「property0～2」に割り当てられています。
2. 【問題文】の「〔レストラン情報検索のAPI〕」には
   　“検索結果には、店舗ID、店舗名称、分類、住所、電話番号、緯度、経度、及び店舗のWebページのURLが含まれる。”
   　と明示されており、X社観光地情報にも同種の属性（分類・緯度・経度）が存在すると考えるのが自然です。
3. 既に表3で「id」「name」「address」「tel」「url」は固定フィールドとして定義済みです。残る「分類・緯度・経度」をproperty0～2に割り当てれば、Y社API／X社DBの全データ項目を漏れなく格納できます。
4. 「分類」は観光地・レストランの双方で多値になり得るため、表3の説明欄に“1以上”とあるproperty0と整合します。
5. 緯度・経度は数値1個ずつで足りるため、出現回数“1”のproperty1, property2に割り当てるのが妥当です。
6. 以上から、
   　c＝分類、d＝緯度、e＝経度
   　となります（dとeは順不同の条件も満たす）。

誤りやすいポイント

• 「分類」をaddressやurlと混同し、property1／2に入れてしまうケース。
• 緯度・経度を一つの要素にまとめてしまい、Latitude／Longitudeの対を失う設計ミス。
• 表3の“出現回数”を見落とし、多値である「分類」を1出現のproperty1に割り当てる誤配置。
• Y社APIの項目列挙を読まずに、X社独自拡張だと勘違いして不要データと判断する思い込み。

FAQ

解答の論理構成

1. 変更点の確認
   本文には、
   「①旅先案内アプリはX社とZ社のAPIにだけアクセスし、Y社のAPIにはX社のAPIの内部処理からアクセスする方式に変更した。」
   とあります。つまり、スマートフォン側からはY社のAPIに直接アクセスしない構成へ改めました。
2. Y社の利用規約を踏まえた理由
   本文の「サービスの利用規約（抜粋）」には次の記述があります。
   ・「アクセスキーを、他の利用者に貸与したり譲渡したりしてはならない。」
   ・「APIの仕様が変更された場合は、API利用者側で対応を取る必要がある。」
   スマートフォンアプリが直接Y社のAPIを呼び出す場合、アクセスキーを端末アプリに組み込む必要があり、アクセスキーを事実上“譲渡”する行為になります。また、仕様変更のたびに配布済みアプリを改修・再配布しなければなりません。
3. 解答群との照合
   イ：「Y社のAPIの仕様変更時にアプリケーションの改修をせずに済ませることができるから」
   → 仕様変更対応をX社側のサーバで完結でき、アプリ改修を回避できる。
   ウ：「Y社のAPIの、アクセスキーの貸与や譲渡を禁止する利用規約に抵触するおそれがあるから」
   → アクセスキーをスマートフォンに埋め込まずに済み、規約違反を回避できる。
   したがって選択すべきは「イ」「ウ」です。
4. 他の選択肢を排除
   ア：X社サーバの負荷軽減とは逆に、Y社との連携部分をX社サーバで肩代わりするため負荷は増加します。
   エ：問題文に「Y社のAPIは、スマートフォンからのアクセスを受け付けない」という記載はありません。
   オ：地図描画はZ社APIが担当であり、Y社APIの呼び出し方式の変更と直接関係がありません。

誤りやすいポイント

• 「サーバサイド経由＝負荷分散」と短絡的に判断し「ア」を選んでしまう。実際には逆効果になる場合もある点に注意が必要です。
• 規約のキーワード「アクセスキー」に目が行かず、仕様変更対応のみに着目して「イ」だけを選ぶミス。二つ選択する設問であることを忘れないようにしましょう。
• 「リアルタイム表示」の規定から「地図表示が速くなる」と連想し「オ」を選択する誤解。リアルタイム要求は表示時刻の明示で対応でき、描画速度とは無関係です。

FAQ

解答の論理構成

1. 【問題文】にはオフライン閲覧のための仕様変更が記述されています。
   引用：「電波が届かないところでも、検索結果のコピーがあるときにはコピーを参照して画面に表示する。」
   ここから、取得したデータを“リアルタイム”ではなく“キャッシュ”から表示するケースが生じることが分かります。
2. しかし、Y社APIの利用規約では次の制約があります。
   引用：「APIの実行結果をリアルタイムに表示できない場合は、APIの実行時刻を画面に表示する必要がある。」
   キャッシュ表示はリアルタイム表示ではないため、この規約に従う追加情報が必須となります。
3. したがって、近隣情報の表示項目には「API実行時刻」を新たに載せる必要があります。
   以上より、変更内容は「表示項目としてY社のAPIの実行時刻を追加する」と導かれます。

誤りやすいポイント

• 「検索半径」「分類」など既存フィールドの見直しと誤解し、実行時刻の追加を見落とす。
• 旅先案内アプリ側のAPI（X社）仕様変更と混同し、XML応答要素の追加と勘違いする。
• 規約の引用を読み飛ばし、“リアルタイムでなければならない”という部分だけに注目してしまう。

FAQ