令和7年度 秋期 システム監査技術者試験 午後Ⅰ 問1 オープンAPI態勢の監査
この問題は2025(R7)秋 システム監査技術者 午後Iに出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
金融機関のオープンAPI態勢を対象とするシステム監査の問題です。API仕様の変更が外部の電子決済等代行業者に与える影響、APIサーバの負荷対策、監査資源を絞るリスクベースアプローチなど、自社に閉じないエコシステム全体を視野に入れた監査の発想が試されます。この記事では、各改善提案を「外部事業者が安全に追随できる条件を整える」という軸で読み解き、制約字数に収める表現を検討します。
この記事で押さえる論点
- オープンAPIの各機能(認可・接続管理・負荷対策)のリスクを識別する
- 外部事業者への影響を考慮した仕様変更管理の改善を提案する
- リスクベースアプローチによる監査資源の配分を説明する
出題情報
- 出題
- 2025(R7)秋 システム監査技術者 午後I 問1
- 配点
- 50点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
金融機関と外部の事業者との間の安全なデータ連携は,オープンAPIによって可能になる。一方で,金融機関のデータ,システムへの接続仕様などを公開することになり,セキュリティの確保やオープンAPIが稼働するサーバの負荷の増大といった課題が生じる。本問では,オープンAPI態勢を題材として,オープンAPI態勢の各機能において生じるリスクの知識,及びリスクに応じたコントロールを識別する能力,また,それらのコントロールの有効性を検証するために必要な監査証拠を特定し,監査手続を導き出す能力を問う。
問1では、オープンAPI態勢を題材として、オープンAPI態勢の各機能において生じるリスク、及びリスクに応じたコントロール、また、それらのコントロールの有効性を検証するために必要な監査証跡と監査手続について出題した。全体として正答率は平均的であった。
問題本文
オープンAPI態勢の監査に関する次の記述を読んで,設問に答えよ。
A銀行は,以前から個人預金者(以下,顧客という)向けにインターネットバンキングによるサービス(以下,IBサービスという)として,口座残高,入出金明細などの照会サービス,及び振込,振込状況確認などの決済サービスを提供している。数年前からオープンAPIを利用してIBサービスの利便性向上を図っており,顧客はフィンテック事業者が提供するスマートフォンやタブレット向けのアプリケーションソフトウェア(以下,アプリという)からIBサービスを利用できるようになった。
〔オープンAPIを利用したIBサービスの概要〕
A銀行がAPIを公開し,フィンテック事業者が提供する通帳,家計簿,決済などのアプリが,顧客の操作に応じてA銀行のIBサービスにオープンAPI経由でアクセスして結果を顧客に返す。当該アプリによるIBサービスへのアクセスは,A銀行とオープンAPI利用契約を締結したフィンテック事業者に対して,A銀行がアクセストークンを発行することによって許可される。アクセストークンは,A銀行のIBサービス利用に係る顧客との同意に基づく許可証であり,これによってフィンテック事業者のアプリがアクセスできるIBサービスの範囲が決定される。
〔金融オープン・イノベーションの推進〕
現在,インターネット経由で銀行口座の情報を取り扱うサービスを提供するフィンテック事業者には,電子決済などの代行業者(以下,電代業者という)としての登録が義務付けられている。また,銀行には努力義務として,オープンAPIを活用してセキュリティを確保しつつ電代業者との協業や連携を促進するオープンAPI態勢の整備が求められている。
〔A銀行のオープンAPI態勢〕
A銀行のIBサービスに係るオープンAPI態勢は,次の各機能から構成される。
(1) IBサービスの企画・改善
リテール業務部は,オープンAPI経由で顧客に提供するIBサービスを企画する。また,電代業者からの要望などを参考に,新規IBサービスの企画や現行IBサービスの改善を検討する。企画及び改善の内容は,IBサービス要件定義書にまとめられる。オープンAPIに係る新規公開,仕様変更及び廃止の通知は,実施の1か月前までにA銀行のホームページに掲載されるとともに,オープンAPI利用契約を締結している電代業者に送られる。
(2) オープンAPIの設計・開発・保守
情報システム部は,IBサービス要件定義書を基にオープンAPI仕様書を作成し,オープンAPIの開発及び保守を行う。当該仕様書は,処理の詳細,処理を制御するパラメータと指定可能値,接続方法などを記載したものであり,オープンAPIの仕様変更やバグ修正に伴って改訂される。
(3) オープンAPIの運用
情報システム部は,オープンAPI運用手順書に沿って,新規公開及び廃止を含めて運用を行う。運用ではオープンAPIが稼働するサーバ(以下,APIサーバという)の負荷状況,接続遮断などの各種イベントの発生状況,オープンAPI経由のアクセス状況が監視される。また,その結果は月次でオープンAPI運用報告書にまとめられ,情報システム部内で回付される。
(4) オープンAPIの接続審査
情報システム部は,公益財団法人金融情報システムセンター発行の“API接続チェックリスト”を基に,A銀行独自のAPI接続チェックリスト(以下,チェックリストという)を作成している。公開しているAPIに対する電代業者からのオープンAPI利用申請があった場合には,チェックリストを用いて,電代業者における情報セキュリティ対策の状況,認識している課題,課題への対応計画などについて審査を行う。そして,顧客情報の安全な提供が可能であることを確認した上でオープンAPI利用契約を締結する。
〔システム監査の実施指示〕
内部監査部長は,オープンAPI利用契約を締結する電代業者が増加してきたことから,オープンAPI態勢の各機能が有効に働かない場合に電代業者及び顧客に及ぼす影響を懸念した。そして,オープンAPI態勢の各機能の状況について監査を行うようシステム監査チームに指示した。
〔予備調査の結果〕
システム監査チームは,オープンAPI態勢の各機能を担うリテール業務部及び情報システム部に対して予備調査を実施し,把握した状況を表1にまとめた。

図の説明テキスト
| 項番 | 機能 | 状況 |
|---|---|---|
| 1 | IBサービスの企画・改善 | 提供している各IBサービスの利用状況を分析することによって,今後の顧客の利便性向上に役立つサービスを検討している。 |
| 2 | オープンAPIの設計・開発・保守 | 自行のデータやシステムへの接続仕様を公開するので,アクセストークンで許可された範囲を超えるアクセスが,電代業者からできないようにするなど,セキュリティの確保に重点を置いている。 |
| 3 | オープンAPIの運用 | APIサーバの過負荷を防ぐために,APIサーバで単位時間当たりに受け付けるオープンAPI接続リクエスト数の制限(以下,APIレート制限という)を行っている。 |
| 4 | オープンAPIの接続審査 | 電代業者からのオープンAPI利用申請が増加しており,情報システム部によるチェックリストを用いた審査の負荷が高まっているので,審査の効率向上を図りたいと考えている。 |
〔本調査の結果〕
システム監査チームは,本調査を実施し,指摘事項及び改善提案を次のようにまとめた。
(1) オープンAPI運用報告書が情報システム部内での回付にとどまっており,オープンAPI態勢において有効利用されていない。当該報告書にはオープンAPI経由のアクセス状況が記載されているので,他に有効利用できる余地がある。
(2) オープンAPI態勢における電代業者との協業や連携の促進の観点からは,セキュリティの確保だけでなく,電代業者におけるアプリ管理への影響を抑えるために,次の事項を考慮する必要がある。
(a) オープンAPIの仕様変更が頻繁に発生しないような設計にすること
(b) オープンAPIの仕様変更が行われた場合,それによって電代業者がIBサービスを利用できなくなることを防ぐこと
(3) APIレート制限値を超えた場合には,エラーメッセージがアプリに返され,オープンAPIへの接続が一時的に遮断されるが,APIサーバの能力に余裕がある状態でも接続が遮断される事象が発生している。DDoSなどのサイバー攻撃や不正アクセスの検知,及びそれに伴う接続遮断の形跡がないので,APIサーバで設定されているAPIレート制限値が適切でない可能性がある。不要な接続遮断によるIBサービス提供の中断を避けるために,APIレート制限値のチューニングが必要である。
(4) チェックリストによる審査に時間を要しており,契約の可否判断が遅れる傾向にあるので,IBサービスの利用開始に関して,直接的には電代業者,間接的には顧客に影響を及ぼすおそれがある。チェックリストの各確認項目を同等に取り扱うのではなく,アクセストークンに基づくリスクベースアプローチによって,審査の効率向上を図る必要がある。
設問と解答・解説
設問1
〔本調査の結果〕(1)について,オープンAPI運用報告書の有効利用に関してシステム監査チームが提案すべき改善内容を,30字以内で答えよ。
模範解答
リテール業務部がオープンAPI運用報告書を参照すること
採点基準(配点 10点)
知識・理解度(内容)(6点)
- 6点: リテール業務部がオープンAPI運用報告書を参照し活用すべきことを、主語と目的語を明確にして的確に記述できている。
- 3点: 改善の方向性は合っているが、主体(リテール業務部)または対象(オープンAPI運用報告書)のいずれかの明記が欠けている。
- 0点: オープンAPI運用報告書の活用について適切に言及できていない、または主語・目的語が誤っている。
論理性(構造)(4点)
- 4点: 提案すべき改善内容として、30字以内で簡潔かつ論理的に因果や行動が表現されている。
- 2点: 意味は概ね通じるが、改善提案としての文脈や文末表現がやや不自然である。
- 0点: 文のつながりが破綻しており、改善内容として読み取れない。
解説
解答の根拠
オープンAPIの運用において、各機能で生じるリスクに応じたコントロールの有効性を検証することが求められています。本問では、作成されているオープンAPI運用報告書が関係部署において有効に活用されていないという課題に対し、改善策を提示する必要があります。報告書の情報を必要とするリテール業務部が、継続的に内容を参照して状況を把握し、必要な対策を講じる態勢を整えることが重要です。
高得点のポイント
- アクションの主体である「リテール業務部」を明記していること
- 活用すべき対象として「オープンAPI運用報告書」を正確に挙げていること
- 改善行動として「参照すること」「確認すること」といった具体的な動詞を用いていること
設問2
〔本調査の結果〕(2)について,(i),(ii)に答えよ。
(1)
システム監査チームは,オープンAPIの仕様変更によって電代業者でどのような対応が必要になると考えて,(a)に示す改善提案を行ったか。30字以内で答えよ。
模範解答
仕様変更の都度,電代業者のアプリの改修が必要になること
採点基準(配点 8点)
知識・理解度(内容)(5点)
- 5点: 仕様変更が行われる都度、電代業者のアプリ(システム)の改修・変更が必要になるという影響を的確に指摘できている。
- 3点: 改修が必要になることは読み取れるが、「電代業者のアプリ」といった対象の記述が不明確である。
- 0点: 電代業者側でのアプリ改修の必要性に触れられていない。
論理性(構造)(3点)
- 3点: 「仕様変更の都度」「改修が必要になる」という因果関係が簡潔かつ論理的に示されている。
- 1点: 因果関係の表現がやや曖昧であるか、説明が不足している。
- 0点: 論理が繋がっておらず、対応が必要な理由として成立していない。
解説
解答の根拠
金融機関がオープンAPIの仕様変更を行うと、それに接続してサービスを提供している外部事業者(電代業者)のシステムにも直接的な影響が及びます。したがって、金融機関側の仕様変更の都度、電代業者側でもアプリ(システム)の改修を余儀なくされるという課題を識別する必要があります。
高得点のポイント
- 仕様変更に伴う影響として、電代業者のアプリ(システム)の改修が必要になる事実を挙げていること
- 「仕様変更の都度」といった頻度やタイミングの制約に触れ、事業者側の負担を論理的に表現できていること
(2)
システム監査チームによる改善提案(b)を行うために,仕様変更後のAPI公開に当たって情報システム部が取り得る方策を二つ挙げ,それぞれ30字以内で答えよ。(1つ目)
模範解答
仕様変更後のオープンAPIのテスト環境を提供すること
仕様変更前のオープンAPIを一定期間並行稼働させること
採点基準(配点 8点)
知識・理解度(内容)(5点)
- 5点: テスト環境の提供、または仕様変更前の旧APIの一定期間の並行稼働のいずれかを正確に記述できている。
- 3点: 方策の趣旨は概ね合っているが、「一定期間」「テスト環境」といった重要な要素が不足している。
- 0点: 新旧APIの永続的な並行稼働など、不適切な方策を記述しているか、的外れな解答となっている。
論理性(構造)(3点)
- 3点: 情報システム部が取り得る具体的な方策・行動として、実行可能な形で論理的に記述されている。
- 1点: 行動としての記述がやや不自然であるか、曖昧な表現となっている。
- 0点: 文脈が破綻しており、方策としての意図が伝わらない。
解説
解答の根拠
APIの仕様変更に伴い、電代業者が自社アプリをスムーズに改修・移行できるよう、情報システム部が支援する方策が求められます。有効な方策として、改修したアプリの動作確認ができるようテスト環境を提供することや、改修が完了するまでの移行期間として仕様変更前の旧APIを一定期間並行稼働させることが挙げられます。なお、新旧のAPIを永続的に並行稼働させることは、サーバ負荷や管理コストの増大に繋がるため不適切です。
高得点のポイント
- 「仕様変更後のAPIのテスト環境の提供」または「仕様変更前のAPIの一定期間の並行稼働」のいずれかを具体的に記述していること
- 永続的な並行稼働を前提とした不適切な解答になっていないこと
(3)
システム監査チームによる改善提案(b)を行うために,仕様変更後のAPI公開に当たって情報システム部が取り得る方策を二つ挙げ,それぞれ30字以内で答えよ。(2つ目)
模範解答
仕様変更後のオープンAPIのテスト環境を提供すること
仕様変更前のオープンAPIを一定期間並行稼働させること
採点基準(配点 8点)
知識・理解度(内容)(5点)
- 5点: テスト環境の提供、または仕様変更前の旧APIの一定期間の並行稼働のいずれかを正確に記述できている。
- 3点: 方策の趣旨は概ね合っているが、「一定期間」「テスト環境」といった重要な要素が不足している。
- 0点: 新旧APIの永続的な並行稼働など、不適切な方策を記述しているか、的外れな解答となっている。
論理性(構造)(3点)
- 3点: 情報システム部が取り得る具体的な方策・行動として、実行可能な形で論理的に記述されている。
- 1点: 行動としての記述がやや不自然であるか、曖昧な表現となっている。
- 0点: 文脈が破綻しており、方策としての意図が伝わらない。
解説
解答の根拠
APIの仕様変更に伴い、電代業者が自社アプリをスムーズに改修・移行できるよう、情報システム部が支援する方策が求められます。有効な方策として、改修したアプリの動作確認ができるようテスト環境を提供することや、改修が完了するまでの移行期間として仕様変更前の旧APIを一定期間並行稼働させることが挙げられます。なお、新旧のAPIを永続的に並行稼働させることは、サーバ負荷や管理コストの増大に繋がるため不適切です。
高得点のポイント
- (1つ目と重複しない形で)「仕様変更後のAPIのテスト環境の提供」または「仕様変更前のAPIの一定期間の並行稼働」のいずれかを具体的に記述していること
- 永続的な並行稼働を前提とした不適切な解答になっていないこと
設問2は、(ii)の正答率が低かった。新旧両方のAPIを継続して存続させる旨の解答が散見された。IBサービスの向上など、APIの仕様を変更する意味及び必要性を理解してほしい。
設問3
〔本調査の結果〕(3)について,APIサーバで設定されているAPIレート制限値以外にシステム監査チームが入手した監査証拠を含め,当該状況を発見した監査手続を,45字以内で答えよ。
模範解答
オープンAPI運用報告書を閲覧し,APIサーバの負荷と接続遮断との関係を分析した。
採点基準(配点 8点)
知識・理解度(内容)(5点)
- 5点: 監査証拠として「オープンAPI運用報告書」を明記し、手続として「APIサーバの負荷と接続遮断の関係の分析」を正確に記述できている。
- 3点: 分析する内容(負荷と接続遮断の関係)は記述できているが、監査証拠の指定が曖昧(「各種ログ」など)であるか不足している。
- 0点: 監査証拠の特定と分析内容のいずれも不適切であるか、監査手続として成立していない。
論理性(構造)(3点)
- 3点: 監査手続の記述として「〜を閲覧(入手)し、〜を分析(確認)した」という形式で妥当に表現できている。
- 1点: 意味は通じるが、監査手続としての表現・構文が不十分でやや不自然である。
- 0点: 文意が通らず、論理が破綻している。
解説
解答の根拠
監査手続においては、適切な監査証拠を特定し、それに基づく分析を実施する能力が問われます。単なる「各種ログ」といった曖昧な記述ではなく、APIサーバの負荷状況や接続遮断のイベント発生状況がまとめられているオープンAPI運用報告書を入手・閲覧することが正しい証拠収集手続です。その上で、APIサーバの負荷と接続遮断との因果関係を分析することが求められます。
高得点のポイント
- 入手した監査証拠として「オープンAPI運用報告書」を正確かつ具体的に指定していること
- 実施した手続として「APIサーバの負荷と接続遮断の関係を分析(確認)した」旨を論理的に記述していること
設問3は、正答率が平均的であった。APIサーバの負荷状況、接続遮断などの各種イベント発生状況、オープンAPI経由のアクセス状況がまとめられたオープンAPI運用報告書が、監査証拠として最も適しているが、各種のログといった明確でない解答が少なからず見られた。適切な監査証拠を特定し、それを基に監査手続を行う能力は監査人にとって必須であるので、ぜひ身に付けてほしい。
設問4
〔本調査の結果〕(4)について,システム監査チームが意図したリスクベースアプローチの内容を,50字以内で答えよ。
模範解答
アクセスを許可するIBサービスの範囲の広さによってチェックリストの確認項目を決定する。
採点基準(配点 8点)
知識・理解度(内容)(5点)
- 5点: 「アクセスを許可するIBサービスの範囲(アクセストークンの権限)の広さ」に応じて、「チェックリストの確認項目を決定する」ことを明記できている。
- 3点: アクセスの範囲による違いには触れているが、確認項目の決定に明確に結びついていないか、あるいは一般的なリスクベースアプローチの記述に留まっている。
- 0点: 本問の意図する「アクセストークンに基づく」リスクベースアプローチの要素が含まれていない。
説得力(考察)(3点)
- 3点: 問題の趣旨を踏まえ、対象の権限の広さに応じてコントロール(確認項目)を変化させるというアプローチの意図を説得力をもって論理的に説明できている。
- 1点: アプローチの説明としてはやや飛躍があるか、説得力に欠ける表現となっている。
- 0点: 論理的に破綻しており、アプローチの内容として意味をなしていない。
解説
解答の根拠
問題文で「アクセストークンに基づくリスクベースアプローチ」と指定されているため、一般的なリスクベースアプローチに関する解答ではなく、この文脈に沿った具体的な内容を記述する必要があります。アクセストークンの権限によってアクセスを許可するIBサービスの範囲が異なる点に着目し、その範囲の広さに応じてコントロールの度合い(チェックリストの確認項目)を決定・変更するというアプローチを説明します。
高得点のポイント
- アクセストークンに基づく要素として「アクセスを許可するIBサービスの範囲の広さ」に言及していること
- 上記に応じて「チェックリストの確認項目を決定(変更)する」というコントロールの変化を論理的に説明していること
設問4は、やや正答率が低かった。一般的なリスクベースアプローチについての解答が多く見られた。問題文に“アクセストークンに基づくリスクベースアプローチ”とあるので、趣旨に沿って解答してほしい。