Applied Information Technology Engineer Examination case studies
Applied Information Technology Engineer Examination · Put your knowledge to work in context.
The Applied Information Technology Engineer Examination (応用情報技術者試験, widely shortened to AP) is one of the national IT examinations administered in Japan by the IPA (Innovation Platform Agency, Japan). The IPA describes its role as "Conducting national IT examinations", and its English site groups the exam under that function alongside related pages such as "Examination Categories and Typical Examinees" and "ITEE in Asia / ITPEC Common Examination". This page is written for candidates searching for a practical, independent guide to the AP exam. It is not an official IPA page, and nothing here should be read as an affiliation with or endorsement by the IPA. Topics on this exam: Technology, Management, Strategy, and Professional and general knowledge. The Applied Information Technology Engineer Examination case studies are 5 cases and about 433 words.
1タイムセール時の在庫引当てタイムアウト ― 行ロック競合の切り分け
FOR UPDATE」で行を更新ロックした後、与信チェックと決済APIの同期呼び出し(平均0.6秒、タイムアウト30秒・リトライ3回)を同じトランザクション内で実行し、最後に数量をUPDATEする。トランザクションの平均保持時間は0.8秒で、リトライにより保持時間が伸びるケースも観測されている。監視ではDBサーバのCPU使用率は30%前後、APサーバも40%前後で、DBの待機イベントは行ロック待ちが大半を占める。注文は上位3商品に全体の65%が集中している。アプリ側に在庫キャッシュはなく、緊急予算でAPサーバの台数追加のみ可能で、DBのスケールアップ予算は確保できていない。. DBのCPU使用率が30%前後 で飽和していない。CPUやI/Oがボトルネックなら使用率が高い側に張り付く。低いのに遅い場合は「待ち」が支配的である。 2. 待機イベントの大半が行ロック待ち である。つまりトランザクションはDB内の計算で待っているのではなく、他のトランザクションが同じ行のロックを解放するのを待っている。 3. トランザクション保持時間0.8秒のうち0.6秒が決済APIの同期呼び出し である。ロックを取ったまま外部通信を待っている構造なので、決済先の応答が遅れるほどロック保持が延び、待ち行列が増幅する。タイムアウト30秒・リトライ3回の設定は、失敗したトランザクションがロックを握ったまま再試行する時間をさらに延ばす。 APサーバのCPUも40%で余裕があり、AP台数を増やせば同時実行数が増えてロック待ちの列が長くなるだけである。インデックス追加も、主キーによる1行更新が既に効いているため改善しない。切り分けの結論は「DB性能」ではなく「ロック保持区間の設計」にある。.
49 words, under 1 min2基幹システム再構築のEVP分析 ― 要員追加かスコープ調整か
ある企業の基幹システム再構築プロジェクトは、総予算8,000万円・工期12か月で計画され、現在5か月目末の完了時点を迎えた。実績はPV=3,200万円、EV=2,800万円、AC=3,400万円である。遅延の原因は、外部取引先との連携方式(取引先ごとに異なるAPI仕様)の設計が想定より難航したことであり、この遅れは今後の製造・テスト工程にそのまま波及する見込みである。プロジェクトマネージャは次の3案を比較している。 案A:要員を3名追加する。1人あたり月80万円、残工期は7か月。ただし新規メンバーは習得に1か月を要し、その間は既存メンバーが1人あたり0.5人月の教育工数を割く必要がある。 案B:予定していた帳票20本のうち12本を第2フェーズに移す。削減効果は600万円・1.5か月相当。ただし利用部門は全20本を初回リリースで期待している。 案C:案Aと案Bを組み合わせる。 経営会議は2週間後に予定され、追加予算の承認が必要な場合はこの場で説明する必要がある。. CPIとSPIを計算し、EACを2通りに見積もれ。両者の差が何を意味するかを述べよ。. 案A・案B・案Cを比較し、推奨案とその理由を述べよ。. 指標の計算 CPI = EV ÷ AC = 2,800 ÷ 3,400 ≒ 0.82 SPI = EV ÷ PV = 2,800 ÷ 3,200 = 0.875 CPIが1未満なので、投入したコストに対して生み出した価値が少ない、つまりコスト超過である。SPIも1未満で、価値ベースの進捗は予定の87.5%にとどまる。12か月計画に対して約1.5か月分の遅れに相当する。 EACの2通りの見積り 1.
98 words, under 1 min3オンプレミスからクラウドへの移行判断 ― 5年TCOの比較
ある中堅企業が、5年前に導入した基幹システム(Web/AP/DBの3台構成)の更新時期を迎えている。情報システム部はクラウド移行を提案しているが、経営層から「TCOが悪化するのではないか」と問われている。 現行の年間コストは、ハードウェア保守180万円、電気・空調120万円、ラック費60万円、運用要員0.4人月/月(人月単価80万円)で年間384万円、合計744万円である。ハードウェアは償却済みで簿価はゼロ。ただし老朽化により、5年以内に再調達2,400万円が必要で、ベンダのサポート終了も2027年3月に迫っている。また、事業継続の観点から災害対策サイトの構築が経営課題になっており、オンプレミスで実現する場合は初期1,500万円・年間運用200万円と試算されている。 クラウド案は、マルチAZ構成と別リージョンへのバックアップを含めて月45万円、ネットワーク月8万円、監視SaaS月5万円。運用要員は0.25人月/月に削減できる見込み。移行費用は一括1,200万円で、移行期間中は3か月間オンプレミスと並行稼働となる。. 5年間のTCOを比較せよ。また、情報システム部が当初提示した比較にはどのような費用が不足していたと考えられるか。. 現行のまま(オンプレミス)5年 年間運用:744万円 × 5年 = 3,720万円 ハードウェア再調達:2,400万円 災害対策サイト:初期1,500万円 + 年間200万円 × 5年 = 2,500万円 合計:3,720 + 2,400 + 2,500 = 8,620万円 クラウド案 5年 年間:(45 + 8 + 5)万円 × 12か月 = 696万円、運用0.25人月 × 12か月 × 80万円 = 240万円、計936万円 5年:936万円 × 5年 = 4,680万円 移行費用:1,200万円 合計:4,680 + 1,200 = 5,880万円 差額は約2,740万円で、クラウドが有利となる。 当初の比較で不足していた費用 第一に、 ハードウェアの再調達費 である。償却済みで簿価ゼロの資産を「コストゼロ」として扱うと、5年の間に必ず発生する2,400万円が比較から抜け落ちる。第二に、 災害対策の費用 で、これは経営課題として既に意思決定済みの要件であり、比較の前提に含めなければならない。第三に、 並行稼働中の二重コスト (3か月間はオンプレミスの744万円×0.25年とクラウド費用が同時に発生する)。第四に、 移行に伴う社内工数 (データ移行検証・テスト・教育)で、ベンダ費用1,200万円には含まれていないことが多い。 逆に、クラウド側で見落としやすいのは データ転送料 と ストレージの増加 、そして 監視SaaSのライセンスが利用者数に比例する 場合はその増加分である。単価の見積りは初年度の想定であり、5年後のデータ量増加を織り込む必要がある。. 条件1:災害対策要件が不要、または既に別手段で満たされている場合 オンプレミス側の2,500万円が消えると、8,620万円は6,120万円になり、クラウドの5,880万円との差は約240万円まで縮む。ここに移行の社内工数や並行稼働コストを積むと、ほぼ互角か逆転し得る。「BCPが本当に必要なのか」「既存の遠隔バックアップで代替できないか」を先に確認しないと、比較の前提が崩れる。 条件2:クラウドの運用削減効果が実現しない場合 クラウド案の優位は、運用要員を0.4人月から0.25人月に減らせるという前提(年間144万円の削減)に依存している。クラウド化しても監視・課金管理・IAM運用などの新規作業が発生し、実際には0.35人月程度しか減らないことも多い。0.35人月だと年間削減は48万円にとどまり、5年で240万円の目減りとなる。 条件3:利用量の増加(データ量・トランザクション) クラウド費用は従量課金であり、データ量が年20%増えると5年間のストレージ・バックアップ費用は単純比例以上に増える。逆にオンプレミスは固定費なので、利用量が増えるほど1件あたりのコストは下がる。5年後にデータ量が2倍になる想定では、クラウド側の年間費用が936万円から1,100万円台に膨らみ、差は1,000万円程度まで縮む。 条件4:再調達の先送り 「2027年3月のサポート終了」は、実務上は延長サポート契約で1〜2年先送りできることが多い。延長費用が5年で500万円程度なら、再調達2,400万円を6年目にずらすことで、5年間の比較ではオンプレミスが有利に見える。ただし先送りは将来のコストを消すのではなく移すだけであり、判断の妥当性は別に問われる。 結論として、この比較は「災害対策を要件に含めるか」「運用削減がどこまで現実的か」の2点に強く依存する。資料には必ずこの前提条件を明記し、単一の結論だけを示さない。.
121 words, under 1 min4委託先でのテスト環境からの情報漏えい ― 報告・通知の判断
通信販売業を営むA社(会員48万人)は、基幹システムの運用をB社に委託している。B社の担当者が、障害再現のために本番の会員データをテスト環境へコピーし、そのテスト環境に接続する踏み台サーバの設定を誤って、約3日間インターネットから到達可能な状態にしていた。調査の結果、アクセスログに不審なアクセスが12件記録され、うち1件はデータのダウンロードに成功した可能性が高い。影響を受けた可能性があるのは3,200件で、そのうち40件には健康状態に関する自由記述欄(要配慮個人情報)が含まれる。クレジットカード番号はトークン化されており保持していない。判明から2日が経過しているが、対外発表は未実施。委託契約書にはデータの取扱いと再委託に関する定めが抽象的で、テスト環境への本番データ複製を禁止する条項はなかった。B社は「自社内で完結する問題」と受け止めている。. 不正アクセスによる漏えい等の疑い :外部から到達可能な状態で不審なアクセスとダウンロードが確認されており、不正アクセス禁止法上の不正アクセスに該当する可能性がある。これも件数を問わず報告対象である。 なお、対象が3,200件であることは「1,000人超」の類型にも該当するが、上記2点だけで結論は同じである。 期限 速報:事案の発生を知った後、 概ね3〜5日以内 。判明から2日経過しているため、余裕はほとんどない。まず分かっている事実だけで第一報を出す。 確報: 30日以内 (不正アクセスが原因の場合は60日以内)。調査の進展に応じて更新する。 本人への通知 報告対象となる事案では、本人への通知も必要である。対象3,200件の特定を待つのではなく、判明している範囲から速やかに連絡する。連絡手段は、メール・郵送・マイページ上の告知を組み合わせる。 判断のポイント 「ダウンロード成功の可能性が高い」という推定段階でも、報告は「確定してから」ではなく「疑いの段階で」行うのが原則である。確定を待って期限を過ぎる方がリスクが大きい。また、B社が「自社内で完結する問題」と考えている点は誤りで、委託元であるA社が保有個人データの管理者として報告義務を負う。. 委託元のモニタリング不足 :A社がB社の環境設定やデータ取扱いを定期確認する仕組みを持っていなかった。 再発防止策 契約の改訂 :本番データのテスト環境への複製を原則禁止し、必要な場合はA社の事前承認を要する旨を明記する。再委託は書面承認制とし、委託先の監督義務、監査立入り権、事故発生時の報告期限(例:判明後24時間以内)を条項化する。 技術的統制 :テストデータはマスキング(氏名・連絡先・自由記述欄の削除または置換)を必須とする。自由記述欄は特に危険で、形式的なマスキングでは要配慮情報が残るため、原則として本番データを使わない合成データ生成に切り替える。 環境分離 :テスト環境はインターネットから遮断し、接続元IP制限と多要素認証を必須とする。設定のドリフトを検出する定期スキャンを自動化する。 監督の実効性 :年1回の立入監査に加え、四半期ごとに設定情報とアクセス権限の棚卸しを求める。 押さえるべき点 再発防止策は「契約」「技術」「監査」の3層で示す必要がある。契約だけでは現場の運用は変わらず、技術的対策だけでは委託先の意識が変わらない。. 公表の判断:実施すべきである。 根拠は3点。第一に、要配慮個人情報を含む事案で報告義務が生じており、委員会への報告事案は公表が前提となる運用であること。第二に、不審なアクセスによるダウンロードの可能性があり、情報が既に外部に出ている疑いがあること。第三に、判明から2日経過しており、SNS等で先に広がった場合、説明の信頼性が大きく損なわれること。 発表内容の構成 事実:何が、いつ、どのくらいの期間、どのような状態だったか。対象件数は「最大3,200件(調査中)」と幅を持たせる。 原因:委託先でのテスト環境への本番データ複製と、踏み台サーバの設定誤り。責任の所在を委託先に押し付けず、委託元としての監督責任に言及する。 影響:カード情報は保持していない(トークン化)ことを明示し、過度な不安を抑える。一方で、健康に関する記述が含まれることは隠さない。 対応:本人通知の方法、問い合わせ窓口、二次被害への注意喚起。 再発防止:契約・技術・監査の3層の対策と実施時期。 顧客対応の実務 対象者3,200件の特定を待つと通知が遅れる。まず判明分に連絡し、追加判明分は順次追加通知する。コールセンターは平時の体制では対応しきれないため、専用ダイヤルとFAQを用意し、回答スクリプトを統一する。 二次被害への注意 カード番号は保持していないが、氏名・住所・健康情報があれば、それを使ったなりすましや標的型メールが可能になる。「A社を名乗る不審な連絡」への注意喚起を通知に必ず含める。 タイミング 委員会への第一報と同じ日か翌日までに公表するのが望ましい。調査が固まるのを待って公表を遅らせると、「隠蔽した」という評価に転じる。未確定部分は「調査中」と明記すればよい。.
74 words, under 1 min5脆弱性診断後の対応優先順位 ― 限られた工数での意思決定
ある企業の受注管理Webアプリケーションが、外部の脆弱性診断を受け、18件の指摘を受けた。内訳はCritical 2件、High 4件、Medium 8件、Low 4件である。3週間後に新機能のリリースが予定されており、そこまでに改修へ投入できる工数は25人日である。 指摘の主要なものは次のとおり。 (a) OSコマンドインジェクション。管理者画面のファイル出力機能に存在し、利用には管理者権限でのログインが必要。管理者画面は社内VPNからのみ到達可能。改修8人日。 (b) SQLインジェクション。取引先向けの検索画面に存在し、ログイン前の入力欄が対象。インターネットに公開されている。改修5人日。 (c) 認可不備(IDOR)。URLのIDを書き換えると他店舗の受注情報が閲覧できる。ログインは必要だが、取引先ユーザなら誰でも実行可能。改修3人日。 (d) CSRF対策の欠如、XSS(反射型)、セッション固定などが続く。 WAFは導入済みだが、ルールはシグネチャベースで、暗号化やエンコードを変えた回避入力には対応できない。リリースを延期すれば工数は確保できるが、取引先との契約で新機能の提供時期が定められており、延期には違約金が発生する。. WAFによる緩和はどの程度期待できるか。限界と残存リスクを述べよ。. 優先順位:(b)→(c)→(a)の順に着手し、残り工数を(d)群に配分する。 判断の軸 脆弱性対応の優先順位は、スコアの高低ではなく「到達可能性」「必要な前提条件」「悪用された場合の影響」の3つで決める。 (b) SQLインジェクションを最優先 到達可能性:インターネット公開かつログイン前の入力欄が対象で、認証情報を持たない第三者でも試行できる。 前提条件:なし。自動スキャンで発見されやすく、実際に攻撃されるまでの時間が短い。 影響:DB全体の情報漏えい、場合によってはデータ改ざん。 工数5人日で、費用対効果が最も高い。 (c) 認可不備を2番目 到達可能性:ログインは必要だが、取引先ユーザなら誰でも可能。取引先は多数存在し、退職者や取引停止先のアカウントが残っている可能性もある。 影響:他社の受注情報が見える。これは自社だけでなく取引先の機密漏えいであり、契約上の重大な問題になる。 工数3人日と小さく、確実に直せる。 (a) OSコマンドインジェクションを3番目 到達可能性:管理者権限でのログインが前提で、さらに社内VPNからのみ到達可能。 影響は最大級(サーバ乗っ取り)だが、前提条件が重い。ただし「管理者権限を持つ内部関係者」が攻撃者になり得る点、VPN接続端末が侵害された場合には前提が崩れる点は無視できない。 工数8人日。25人日のうち5+3=8を使った残り17人日で対応可能だが、(d)群とのバランスを考える。 残りの配分 (a)に8人日、残り9人日を(d)群へ。CSRFとセッション固定は認証後の操作に影響し、XSSは利用者間の攻撃に使われる。Medium以下でも、管理画面や決済画面に関わるものは優先度を上げる。 見落としやすい点 「Criticalだから最優先」という機械的判断は誤りである。本件ではCriticalの(a)より、Highの(b)(c)の方が実際のリスクは高い。診断結果のスコアは一般的な深刻度であり、自システムの公開範囲・権限設計を反映していない。. 期待できる範囲 シグネチャベースのWAFは、既知の攻撃パターン(典型的なSQLインジェクションの文字列、OSコマンドの区切り文字など)を遮断する。改修が間に合わない項目に対する仮想パッチとして、攻撃の成功率を下げる効果はある。特に(b)のような自動化されたスキャン攻撃には一定の抑止力がある。 限界 1.
91 words, under 1 min