COBITandApplControls JP new Logo reviceditgi.jp/pdfdata/COBITandApplControls_JP.pdf ·...

マネジメントガイド

アプリケーション統制の定義

アプリケーション統制の設計と導入

アプリケーション統制の運用と保守

アプリケーション統制と IT 全般統制

アプリケーション統制の保証

2 © 2009 ISACA. All rights reserved.

ISACA®

世界 160 ヵ国以上で 86,000 人を超える会員を抱える ISACA®（www.isaca.org）は、IT

ガバナンス、コントロール、セキュリティおよびアシュアランスにおいて世界的に認め

られたリーダーである。1969 年に創立された ISACA は、国際会議の主催、ISACA®

Journal の発行、および国際的な情報システム監査およびコントロール基準の開発を行

っている。また、世界的に高く評価されている公認情報システム監査人（CISA®）の認

定（1978 年以降の取得者数 6 万人以上）、公認情報セキュリティマネージャー（CISM®）

の認定（2002 年以降の取得者数 1 万人以上）、および新しい Certified in the Governance of

Enterprise IT®（CGEIT®）の認定を行っている。

免責事項

ISACA（「発行者」）はこの『COBIT®とアプリケーション統制：マネジメントガイド』

（以降「本書」）を、主としてコントロールの専門家向けの教育資料として立案作成し

た。発行者は、本書の使用により成功が保証されるものとは主張していない。本書に、

適切な情報、手順、テストがすべて含まれているわけではない。また、同じ結果を得る

ことを意図した他の情報、手順、テストを排除するものではない。個別の情報、手順、

テストの妥当性を判断する際、コントロールの専門家は、特定のシステムや IT 環境に

基づくそれぞれの状況に対して、専門家としての独自の判断を適用するようにしていた

だきたい。

著作権

© 2009 ISACA. All rights reserved. 本書のいかなる部分も、ISACA の事前の書面による

許諾をえることなく、いかなる形態、いかなる手段（電子的、機械的、コピー機の使用、

記録など）によっても使用、コピー、複製、修正、配布、表示、検索システムへの保存、

記録することを禁ずる。本書のすべてまたは抜粋の複製は、学術的、社内的、非営利的

使用、およびコンサルティング/アドバイザリーを目的とする場合のみ許可されるが、

資料の出典を完全に記載しなければならない。本書に関して、これ以外の権利または許

可は一切与えられない。

Reservation of Rights

© 2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified,

distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic,

mechanical, photocopying, recording or otherwise) without the prior written authorisation of ISACA.

Reproduction and use of all or portions of this publication are permitted solely for academic, internal,

non-commercial use and for consulting/advisory engagements and must include full attribution of the

material’s source. No other right or permission is granted with respect to this work.

© 2009 ISACA. All rights reserved. 3

ISACA

3701 Algonquin Road, Suite 1010

Rolling Meadows, IL 60008 USA

Phone: +1.847.253.1545

Fax: +1.847.253.1443

E-mail: [email protected]

Web site: www.isaca.org

COBIT® and Application Controls: A Management Guide

Printed in the United States of America

1 CGEIT は ISACA の商標/サービスマークである。このマークについては、世界各国で申請または登録され

ている。


ACKNOWLEDGEMENTS

ISACA wishes to recognise:

Authors

Eugene Atangan, CISA, PMP, Deloitte & Touche LLP, Canada

Gary S. Baker, CGEIT, CA, Deloitte & Touche LLP, Canada

Steven Cauwenberghs, CISA, CISM, CIA, Deloitte, Belgium

Candy (Yi-Ting) Chen, Deloitte & Touche LLP, Canada

Dan Cimpean, CISA, CISM, CIA, Deloitte, Belgium

Cosmin Croitor, CISA, CGEIT, ACCA, CIA, Deloitte, Belgium

Jessica Galland, Deloitte, Belgium

Gary Hardy, CGEIT, IT Winners, South Africa

Tony Jiang, CISA, CPA, Deloitte & Touche LLP, Canada

Gord Kilarski, I.S.P., Deloitte & Touche LLP, Canada

Monica Tang, Deloitte & Touche LLP, Canada

Geert Thoelen, Deloitte, Belgium

Johan Van Grieken, CISA, CGEIT, Deloitte, Belgium

Expert Reviewers

Mark Adler, CISA, CISM, CIA, CISSP, Allstate Insurance Company, USA

Kenneth C. Brancik, Ph.D., CISA, CISM, CISSP, ITIL, Northrop Grumman Information

Systems, USA

Dirk Bruyndonckx, CISA, CISM, MCA, KPMG Advisory, Belgium

Luis A. Capua, CISM, Sigen, Argentina

Muhammad Fadli Davies, CISA, Old Mutual, South Africa

Seda Demircioglu, PricewaterhouseCoopers, The Netherlands

Heidi L. Erchinger, CISA, CISSP, System Security Solutions, Inc., USA

Robert F. Frelinger, CISA, CGEIT, Sun Microsystems, Inc., USA

Erik Guldentops, CISA, CISM, University of Antwerp Management School, Belgium

J. Winston Hayden, CISA, IT Governance Service Consultants, South Africa

Monica Jain, CGEIT, CSQA, CSSBB, Covansys–A CSC Company, USA

Kamal Khan, CISA, Saudi Aramco, Saudi Arabia

Suzana S. Keller, CISM, CISSP, Coca Cola Enterprises, USA

John W. Lainhart IV, CISA, CISM, CGEIT, IBM Global Business Services, USA

Charles Mansour, CISA, Charles Mansour Audit & Risk Services, UK


Malcolm R. Pattinson, CISA, CISM, University of South Australia, Australia

Cheryl Faye Santor, CISA, CISM, CISSP, CNE, Metropolitan Water District of SoCal, USA

Maxwell J. Shanahan, CISA, FCPA, MACS, MII, Max Shanahan & Associates, Australia

Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA

Peter Van Mol, CISA, Atos Worldline nv, Belgium

Greet Volders, CGEIT, Voquals, Belgium

ISACA Board of Directors

Lynn Lawton, CISA, FBCS CITP, FCA, FIIA, KPMG LLP, UK, International President

George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President

Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President

Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico,

Vice President

Robert E. Stroud, CGEIT, CA Inc., USA, Vice President

Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President

Frank Yam, CISA, CCP, CFE, CFSA, CIA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc.,

Hong Kong, Vice President

Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President

Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International

President

Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director

Tony Hayes, CGEIT, FCPA, Queensland Government, Australia, Director

Jo Stewart-Rattray, CISA, CISM, CGEIT, CSEPS, RSM Bird Cameron, Australia, Director

IT Governance Committee

Tony Hayes, CGEIT, FCPA, Queensland Government, Australia, Chair

Sushil Chatterji, Edutech Enterprises, Singapore

Kyung-Tae Hwang, CISA, Dongguk University, Korea

John W. Lainhart IV, CISA, CISM, CGEIT, IBM Business Consulting Services, USA

Hugh Penri-Williams, CISA, CISM, CCSA, CIA, Glaniad 1865 EURL, France

Gustavo Adolfo Solis Montes, CISA, CISM, Grupo Cynthus, Mexico

Robert E. Stroud, CGEIT, CA Inc., USA

John Thorp, CMC, I.S.P., The Thorp Network Inc., Canada

Wim Van Grembergen, Ph.D., University of Antwerp Management School and IT Alignment

and Governance Research Institute, Belgium


COBIT Steering Committee

Robert E. Stroud, CGEIT, CA Inc., USA, Chair

Gary S. Baker, CGEIT, CA, Deloitte & Touche LLP, Canada

Rafael Eduardo Fabius, CISA, Republica AFAP SA, Uruguay

Erik Guldentops, CISA, CISM, University of Antwerp Management School, Belgium

Jimmy Heschl, CISA, CISM, CGEIT, KPMG, Austria

Debbie A. Lew, CISA, Ernst & Young LLP, USA

Greet Volders, CGEIT, Voquals, Belgium


コントリビューター代表のメッセージ

企業活動は今や情報システムに依存しているといっても過言ではありません。すべての業

務プロセスには情報システムによる業務アプリケーションが組み込まれていると言えます。こ

のような状況においては、業務プロセスを適切に実施するためにコントロールも業務アプリケ

ーションに組み込まれている必要があります。たとえば、効率的な業務を行うためには業務プ

ロセスをできるだけ自動化する必要がありますが、コントロールも同時に自動化する必要が

あります。人間の不注意によるミスを避けるために、大量のデータを一定の品質で処理する

ためにはコンピュータ処理が必要ですが、そのためのコントロールも同時にコンピュータ処理

することが必要となります。企業活動のあらゆる側面でこれからも情報システムの導入が進

むと考えられます。したがって、アプリケーションに適切にコントロールを組み込むことがます

ます重要となります。これは、内部統制報告制度においても同様です。内部統制の評価を有

効かつ効率的にするためにもアプリケーションコントロールはますます重要となります。

本ガイドは、そのような背景を踏まえた主に、経営者及び管理者層の人がアプリケーション

統制の重要性を認識し、どのような観点からアプリケーション統制を設計、実装していけばよ

いのかを説明したものです。アプリケーション統制に関する多くの例示も含まれており、大い

に参考になるものと思っております。英語ではなかなか手に取りにくいという面もあるので、本

ガイドの翻訳に協力させていただくことになりました。本ガイドが皆様のビジネスのますますの

発展を寄与できますことを心より願っております。

なお、翻訳においては出来る限り従来の COBIT シリーズの翻訳と用語を併せ、かつ平易な

日本語となるように注意を払いましたが、読みにくい点があるかもしれません。私たちの実力

の至らぬ点ですが、お許しを願いたいと思います。

後になりますが、本ガイドの翻訳にかかわる機会をいただきました、日本 IT ガバナンス

協会様に厚く御礼申し上げます。

有限責任監査法人トーマツ

丸山満彦


日本 IT ガバナンス協会からのお礼

有限責任監査法人トーマツさまのご協力により本書の出版が 2 期目の内部統制の Jー

SOX 対応の具体化を検討されるタイミングでだされることは我国の IT ガバナンスに大きく貢

献するものとしてトーマツさま及び英語版本文でも大きく貢献頂いたデロイトトウシュトーマ

ツグループに深く感謝いたします。

皆様に是非みていただきたいのは利用部門の経営管理者の内部統制の実行責任者と示

された図 6 と図 8 です。これが本書の目的です。図 6 の設計段階では、我国で不足している

アーキテクト(アナリスト)の存在を前提とし、図 8 の運用では、モニタリングの実行責任者であ

ることを示しています。

統制のクライテリアがなぜ複雑なのかが理解したい方は、図 1、2、3 を眺めて下さい。アー

キテクトの役割が大切だ。ビジネスの情報と自動化されたデータ/情報の透明度の向上に大

きな課題がある。これに気付かれれば、本書がいかに貴重なものか見えてきます。

日本 IT ガバナンス協会会長

松尾明


コントリビューター：

有限責任監査法人トーマツ

リーダー

丸山満彦

メンバー

味方直子安部靖雄

大氏善洋喜井里恵子

谷口直之中垣光生

細谷明宏松井靖巳

翻訳責任

ITGI Japan 翻訳委員会

委員長松原榮一

委員吉丸成人

委員中村努

委員木村章典

委員梶本政利

ファイナルレビューアー

松原榮一

梶本政利桂由紀子


目次

1. はじめに .................................................................................................................... 13

コントロールの重要性 ............................................................................................... 13

アプリケーション統制に関するガイダンス ................................................................... 14

2. エグゼクティブサマリー ......................................................................................... 17

アプリケーション統制の概要 ...................................................................................... 17

アプリケーション統制の設計と実装 ............................................................................ 18

アプリケーション統制の運用と保守 ............................................................................ 20

アプリケーション統制と IT 全般統制 ........................................................................... 20

アプリケーション統制の保証 ...................................................................................... 21

3.アプリケーション統制の定義 ........................................................................................ 24

業務プロセスとコンピュータ化対応策 ......................................................................... 24

アプリケーション統制とは .......................................................................................... 25

アプリケーション統制の目標 ...................................................................................... 26

業務処理統制とアプリケーション統制 ........................................................................ 34

ビジネスリスクと情報処理 ......................................................................................... 34

アプリケーションコントロールの目標と財務報告の内部統制 ....................................... 36

4.アプリケーション統制の設計と導入 ......................................................................... 38

アプリケーション統制とシステム開発のライフサイクル ................................................ 38

アプリケーション統制の自動化の事例 ....................................................................... 50

アプリケーション統制の設計および導入における役割と責任 ...................................... 52

アプリケーション統制の設計と導入に関連するリスクの管理 ....................................... 53

アプリケーション統制の設計および導入の達成目標と測定指標 .................................. 56

5. アプリケーション統制の運用と保守 ....................................................................... 58

アプリケーション統制の運用と保守 ............................................................................ 58

アプリケーション統制の運用および保守における役割と責任 ...................................... 65

アプリケーション統制の運用と保守に関連するリスクの管理 ....................................... 65

アプリケーション統制の運用と保守における達成目標と測定指標 ............................... 68

アプリケーション統制の継続的な改善を目的とした成熟度モデルの利用 ..................... 68

6. アプリケーション統制と IT 全般統制の関係 ........................................................... 72

アプリケーション統制と IT 全般統制の関係 ................................................................ 72

IT 全般統制の役割と責任 ......................................................................................... 76

情報処理およびシステム運用のアウトソーシングの影響 ............................................ 77

7. アプリケーション統制の保証 .................................................................................. 79


保証とは何か ............................................................................................................ 79

保証に関する一般的な例 .......................................................................................... 79

アプリケーション統制をめぐる保証 ....................................................................... 80

アプリケーション統制の保証取得のプロセス .............................................................. 83

アプリケーション統制のテストに適したサンプルサイズ決定のためのガイダンス ........... 89

アプリケーション統制の保証における IT 全般統制の不備の影響 ................................ 94

付録A ― COBIT 4.1のプロセスおよびコントロール目標に対するアプリケーション統

制活動のマッピング ..................................................................................................... 99

付録 B ― アプリケーション統制タイプに関する追加ガイダンス ............................. 102

入力段階 ................................................................................................................ 102

処理段階 ................................................................................................................ 105

出力段階 ................................................................................................................ 107

プロセスの境界 ....................................................................................................... 108

監査証跡とアプリケーションのログ収集 ................................................................... 110

付録 C ―重要な会計アプリケーションにおける職務分離 29 ..................................... 112

付録 D ― アプリケーション統制の目標達成のためのコントロールプラクティス、価値

およびリスクのドライバー ......................................................................................... 118

付録 E ― アプリケーション統制の設計および導入のためのツール ......................... 125

アプリケーション統制の要件の定義/関連するアプリケーション統制の目標の明確化 . 125

アプリケーション統制の設計のためのテンプレート.................................................... 126

付録 F ― アプリケーション統制に関連する共通の問題と課題 ................................ 135

付録 G ― COBIT の概要 ............................................................................................. 138

付録 H ― キーメッセージのまとめ ........................................................................... 143

第 4 章アプリケーション統制の設計と導入 ............................................................. 143

第 5 章アプリケーション統制の運用と保守 ............................................................. 144

第 6 章アプリケーション統制と IT 全般統制の関係 ................................................. 145

第 7 章アプリケーション統制の保証 ....................................................................... 145

付録 I ― 用語集 ......................................................................................................... 147

付録 J ― 参考資料 ..................................................................................................... 150

はじめに


1. はじめに

自動化された情報処理に企業が依存していることに議論の余地はない。事実、日常業務

においては、情報システムによって自動的に生成、処理、蓄積、保存およびレポート化

された情報の適時性、正確性，信頼性に依存している。顧客、取引先、従業員、運用責

任者、管理責任者、経営幹部、取締役会、株主およびその他すべてのステークホルダー

は、各自が受け取った情報に基づいて意思決定を行っている。そして、ほとんどの場合、

その情報のインテグリティと信頼性は情報処理に使用されるアプリケーションシステ

ムと周辺のコントロールプロセスに依存している。そのため、これらの意思決定の質は、

意思決定のもととなる情報の品質に依存しているといえる。誤った情報は誤った意思決

定につながる。誤った情報によって致命的な決断をした例は多く、企業はその影響から

免れることができない。そのようなことは、みなさんも多く経験しているだろう。

コントロールの重要性

企業は情報の信頼性に大きく依存しているため、情報を処理するアプリケーションシス

テムのリスクを管理し、コントロールすることが必要不可欠である。情報の正確性、イ

ンテグリティ、信頼性および機密性を確実にするためにはそれらのアプリケーションシ

ステムに組み込まれている仕組みとそれに関連する業務プロセスが重要であり、このこ

とを理解することが本書の目的である。

利用する情報は「完全」である必要はない。完全さは必ずしも必要ではなく、情報はそ

れが使用される目的に応じて、求められる信頼性が必要である。単純な例として、自動

車の速度計から得られる情報について考えてみる。日常的な使用では、速度計の情報が

完全に正確である必要はない。速度計の情報は一般的に、目的地へ到着するまでにかか

る時間を把握したり、先にあるスピード違反監視区域に備えてアクセルを緩めるタイミ

ングを決めたりするためのガイドとして使われる。通常、速度計は、時速 1 キロメート

ル（あるいは 1 マイル）の単位まで測定可能である必要はない。交通当局の測定精度に

依存しているが、ある程度の不正確さが許容されるのが普通であろう。一方、医師は、

患者のモニタリングシステムに非常に高い精度を求める。それは、この情報に基づく決

定が生死を分ける可能性があるからである。

ここに挙げた例から、コントロールの重要性と必要性は、情報の用途とその情報の正確

性またはインテグリティが欠如した場合の影響度合いに依存していることが理解でき

る。不運にもスピード違反で捕まってしまう事態を避けたり、目的地への到着時刻を予

想したりするには、「適度に正確な」速度計が必要である。一方，医師は、患者の健康


に関して確実な判断をするために、正確性と信頼性をあわせもつ患者のモニタリングシ

ステムが必要である。企業は、企業を経営し、企業の利益追求、法律、契約および規制

に関わる責任を果たすため、信頼性の高い情報を必要としている。したがって、経営管

理部門は、アプリケーションシステム内のコントロールが、結果として生ずる情報を適

切な信頼度で提供するのに十分であることを確実に整備する必要がある。コントロール

の性質、範囲および精度は、情報の重要性の評価およびその情報の正確性またはインテ

グリティが欠如した場合のリスクまたは影響に基づいて決定しなければいけない。

アプリケーション統制に関するガイダンス

本書は、アプリケーション統制に関するガイダンスを提供するものであり、業務部門や

IT の統括責任者、業務処理オーナ、開発者、利用者、監査人およびコンプライアンス

の専門家を対象としている。これまでは、経営層とユーザはアプリケーションシステム

のビジネス上の機能性を重視し、アプリケーション統制の概念については主に監査人や

コンプライアンス専門家の領域として捉えられていた。しかし本書では、情報の信頼性

が非常に重要であることから、アプリケーション統制は監査関係者の単独領域ではなく、

まさにビジネス上の機能性に相当するという理解を強めるのを目的として作られてい

る。

本書は、業務部門および IT の関係者を主な対象としているため、「監査用語」は小

限に抑え、ビジネス用語を使用するように配慮している。また、本書は、アプリケーシ

ョンシステムのライフサイクル（要件定義、導入、運用および保守、終的にアプリケ

ーション統制の保証提供）に基づいて構成した。このライフサイクルに沿ってアプリケ

ーション統制の概念を構成したが、これから要件定義を行う新規導入のアプリケーショ

ンシステムに対してのみ、この概念を適用すればよいという意味ではない。この概念は、

新規のアプリケーションシステムと既存のレガシーアプリケーションシステムの両方

に等しく該当するものである。レガシーアプリケーションシステムについては、完成す

るために何らかの遅れを取り戻す作業（さもなければ、要件定義と実装の一部として実

施される場合もある）が必要となる場合がある。これらの活動には、たとえば、リスク

分析の実施、関連するコントロール目標および関連したコントロール活動の特定を含む

かもしれない。これらの活動は、レガシーアプリケーションシステム内の重要なリスク

の理解、適切なリスクマネジメントの実施、またはギャップやエクスポージャーを解決

するために必要な追加活動の開発の際に、極めて重要である。

アプリケーション統制は、COBIT 4.1 のフレームワーク 2の一環として、また『IT


2 COBIT 4.1 の概要に関しては、「付録 G ― COBIT の概要」を参照のこと。

Assurance Guide: Using COBIT®（IT 統制の保証ガイド）』、『COBIT® Control Practices

（COBIT®コントロールプラクティス）：Guidance to Achieve Control Objectives for

Successful IT Governance, 2nd Edition（効果的な IT ガバナンスに向けたコントロール目標

を達成するためのガイダンス、第 2 版）』、および『IT Governance Implementation Guide：

Using COBIT® and Val IT , 2nd Edition』（IT ガバナンス導入ガイド:COBIT と Val IT の使

用第 2 版）などの出版物の中で取り上げられている。これらの出版物では、アプリケ

ーション統制に関する明確な手法の詳細（関連目標、価値およびリスクのドライバー、

およびコントロール活動など）を提供している。本書は、これらの出版物を代替するも

のではなく、既存の出版物をサポートする追加的なガイダンスを提供することを目的と

して作成したものである。そのため、本書では COBIT 関連の出版物の関連セクション

との相互参照を多いに利用している。これらの出版物を適宜活用することをお勧めする。

本書全体を通じて、要点となるキーメッセージを個別のボックスの中に記述されている。

これらは、読者に対してアプリケーション統制ガイダンスのキーポイントを提供するこ

とを目的としている。これらのキーメッセージは、「付録 H ―キーメッセージのまと

め」にもまとめて掲載をしている。

エグゼクティブサマリー


2. エグゼクティブサマリー

企業は、正確で完全でかつ信頼できる情報を求めている。この情報は、経営層が重要な

経営判断を行う際に使用される。また、法令を遵守していることを立証するために使用

されるケースも増えている。蓄積された情報をステークホルダーに報告することで、ス

テークホルダーは情報に基づいた意思決定を行うことができる。医療従事者は患者の診

療情報に基づき診断を行い、治療方針の決定を行う。航空管制官は、到着便と出発便の

フライト情報に基づき、非常に重要な着陸の優先順位の決定を行う。郵便および運送業

者は、優先順位と宛先の情報に基づいて、輸送経路と配送手段の決定を行う。

アプリケーションシステムとアプリケーション統制の概念は、これらの用語が使われだ

した当初から飛躍的な進化を遂げている。しかしながら、それらは依然として、主に企

業の財務活動に関連付けられることが多い。カプランとノートン 3は、1990 年代半ばの

バランススコアカードに関する研究の中で、経営層は財務の視点を超えて、顧客、業務

プロセスおよび学習と成長の視点にバランスよく目を向ける必要があると指摘してい

る。たとえば、経営層はパフォーマンス測定とチェンジマネジメントに関する情報に基

づき、業務改善を推進することができる。ビジネスインテリジェンスと人事のスキルデ

ータベースを用いることで、企業の将来のビジネス要件を満たすために役立てることが

できる。また、顧客情報（カスタマーリレーションシップマネジメント［CRM］やヘ

ルプデスクアプリケーションから得られるもの）を使用して、顧客満足度を高め、企業

の財務実績にプラスの影響をもたらすことができる。ビジネスのスピードは速く、複雑

であるため、財務アプリケーションだけでなくすべてのアプリケーションに信頼性のあ

る情報を確実に提供するためのコントロールを組み込む必要がある。

アプリケーション統制の概要

アプリケーション統制は、アプリケーションシステムとそのアプリケーションシステム

に管理されている情報に関する内部統制の一部分である。企業が、意思決定を行うため

には、タイムリーで正確かつ信頼できる情報が不可欠である。情報の適時性、正確性お

よび信頼性は、その情報の生成、処理、保存および報告に使用されるアプリケーション

システムに依存している。アプリケーション統制は、タイムリーで正確かつ信頼できる

情報の提供というビジネス目標を達成するためのコントロールである。このコントロー

ルは、情報が一定の基準（これを、COBIT では情報に関するビジネス要件と呼んでい

る。）に準拠していることを保証する手作業および自動化された活動で構成されている。

3 Kaplan, Robert S.; David P. Norton; 『Balanced Scorecard: Translating Strategy Into Action』、Harvard Business

School Press、米国、1996 年


この基準とは、有効性、効率性、機密性、インテグリティ、可用性、コンプライアンス

および信頼性である。

経営層は、自身の経営判断、およびその判断のもととなった情報の信頼性に対して説明

責任を負う。また、経営層は、自らが作成し、ステークホルダーに提供する情報、規制

遵守要件を満たすための情報の信頼性に対しても説明責任を負う。信頼性のある情報を

提供するため、主要なリスク（不正リスクを含む）を低減できるアプリケーション統制

を確実に整備し、有効に運用することは経営層の責任である。アプリケーション統制に

関する様々な活動、役割および責任は、それぞれのアプリケーションシステムのライフ

サイクル全体を通じて、それぞれの関係者に割り当てられている。

アプリケーション統制の設計と実装

一般的にアプリケーションシステムの開発あるいは調達の初期フェーズにおいて、アプ

リケーションシステムのビジネス要件、機能要件の明確化、具体化および定義が行われ

る。コントロールに関するビジネス要件、つまりコントロール目標も、このフェーズで

明確にし、定義しておく必要がある。これらのビジネス要件が実装されたソリューショ

ンによって終的に提供されることを確実にするために、アプリケーションが正確かつ

信頼性のある情報を確実に収集、処理、報告するためのビジネス要件を明確に定義する

必要がある。コントロールに関するビジネス要件は、情報の正確性、信頼性が欠如する

リスクに対するコントロールであり、従ってこのビジネス要件はその情報に責任を負う

経営管理部門が決定しなければいけない。

コントロール目標を明確に定義することで、業務部門のユーザやシステムアナリストが

これらの目標を確実に達成するための効率的かつ効果的なバランスのとれたコントロ

ール活動を開発することができる。エラーを予防・発見するような、手作業あるいは自

動化されたコントロール活動の組み合わせを活用することができる。また、どのような

頻度で誰がコントロール活動を実施するのかといった事を決定することができる。費用

対効果と効率のバランスがとれたコントロール活動の組み合わせを確実に整備してい

くためにはこれらの決定が必要不可欠である。経営管理部門は、コントロール活動が適

切に設計され、重要なビジネスリスクに対応するコントロール目標が設定されているこ

とを確認する必要がある。

アプリケーションシステムの機能仕様書には、そのアプリケーションに対するビジネス

要件が定義されている。したがって、コントロールとしてのビジネス要件を満たすため

には、コントロール活動が機能仕様書に含まることになる。これらの仕様書は開発者が


コードを開発する際、あるいはベンダーソリューションの評価チームが、代替ソリュー

ションを評価する際の基礎として作成される。また、仕様書に手作業によるコントロー

ル活動も含めることで、将来の業務プロセスを設計するチームや、プロセスやワークフ

ローを作成するベンダーソリューションを利用するチームが使用できるようになる。ア

プリケーション統制の定義は、他のビジネス機能要件の定義に関連したステップと同様

に、それぞれのシステム開発のライフサイクルプロセス（SDLC）の中で独立したステ

ップとすべきである。

開発または調達後すぐに、そのビジネスソリューションが仕様にしたがって機能し、期

待されるビジネス目標を達成することを担保するために、開発または調達が行われたシ

ステムに対してシステム設定およびテストが行われる。同様に、同時期に、アプリケー

ション統制も、その仕様および目標に適合していることを保証するために、設定および

テストが行われる。システム導入を「決行するか中止するか」といった経営層の判断は、

アプリケーションで処理される情報の正確性、インテグリティ、信頼性および機密性を

担保する主要なアプリケーション統制の設計、構築、設定およびテスト結果に基づいて

行われるべきである。

不適切なコントロールの導入、その結果として信頼性の低い情報が生成されることによ

って、システム導入が失敗している例は多い。これらの失敗の多くは、導入前のコント

ロールの設計やそのテストに対して、もっと入念に集中して取り組むことで防ぐことが

できたかもしれない。

ソリューション設計活動の一部として、費用対効果が高く、有効でバランスがとれたコ

ントロールを設計することに注力することで、自動化されたコントロール活動に関連す

る有効性も大化することができる。コントロール要件の検討を十分に行い、費用対効

果の高いコントロールソリューションを積極的に開発することで、導入後にコントロー

ルの欠如を補うため、高額な手作業によるコントロール手順を追加しなければならない

事態を小限にすることができる。

リスクの評価、関連するコントロール目標の明確化、およびアプリケーション統制の設

計の充足性の確定は、新規システムの設計および導入プロセスにおいて重要な作業の一

部である。また、企業の業務および経営プロセスの一部として使用されている既存のア

プリケーションに対して、これらの作業を実施することも同様に重要である。

アプリケーション統制の設計および導入に対する責任は分担されている。経営管理部門

は、コントロールに対するビジネス目標を達成するため、アプリケーション統制の要件


が適切に設計および導入されていることを保証することに対して説明責任を負う。IT

部門は、定義されたビジネス要件にしたがってアプリケーション統制を開発することに

対して説明責任を負う。


アプリケーション統制に対する責任は、システムを導入したところで終わるわけではな

い。情報処理の継続的な信頼性を確実なものにするために、アプリケーションが動作す

る IT 処理環境を管理、維持していく必要がある。アプリケーション統制は、その有効

性を確実なものするために通常の情報処理活動の一環として、継続的に運用、実行して

いく必要がある。ビジネス要件および業務プロセスに変更が発生すれば、アプリケーシ

ョン統制も更新および改善していく必要がある。

IT（部門）は通常、IT 処理環境の信頼性の確保に責任を負う。この処理環境ではデータ

の機密性を保護するだけではなく、情報処理の継続的な信頼性および可用性、ならびに

アプリケーションとそのデータのインテグリティを備え持っている。

経営管理部門は、そのアプリケーション統制の継続的な有効性をモニタリングする必要

がある。そのモニタリングでは、自動化されたコントロール活動を補完するために必要

な手作業によるコントロール活動が適切に実施されていることを保証する必要がある。

ビジネスリスクと情報の重要性に基づいて、モニタリングの仕組みは、コントロール欠

如の可能性がある環境の特定を可能とするように、適応させ、フォローするものにする

必要がある。

ビジネスニーズの進化に伴い、アプリケーション統制にも変更が必要となる。経営層が

意思決定の基盤としている情報の継続的な信頼性を確実なものにするためには、アプリ

ケーション統制の変更を管理し、コントロールしていく必要がある。

アプリケーション統制の運用と保守の責任は、経営管理部門と IT 部門の間で分担され

るとともに、すべての関係者が責任を明確に理解している必要がある。経営管理部門は、

アプリケーション統制の継続的な有効性のモニタリング、および変更が発生した場合の

要件の明確化と定義に責任を負う。IT 部門は、信頼できる処理環境の提供および定義

されたビジネス要件に基づく変更点の開発と実装に責任を負う。

アプリケーション統制と IT 全般統制

アプリケーションおよびアプリケーション統制の継続的な有効性は、IT 処理環境の信

頼性に依存している。IT 全般統制とは、IT 処理環境の中で継続的な信頼性を提供する


ためのコントロールである。（例：情報セキュリティおよび変更管理のコントロール、

IT 運用およびジョブスケジューリングのコントロール）。IT 全般統制の中の不具合や、

機能停止は、アプリケーション統制の有効性に大きな影響を与える可能性がある。

そのため、アプリケーション統制の設計、導入、運用および保守作業全体を通して、IT

全般統制の有効性について把握していることが重要である。IT 全般統制が有効なシス

テムでは自動化されたアプリケーション統制に依存することができるが、IT 全般統制

の信頼性が低いシステムでは、手作業によるコントロールに重点を置く必要がある。

また、アプリケーション統制の設計時に、いくつかのコントロール活動は、全てのアプ

リケーションに共通の方法で実施することができて、IT 全般統制の一部として組み込

むことが可能どうかについての選択肢が存在する場合がある。共通の方法を組む込むこ

とは、それぞれのアプリケーションシステムで個別にコントロールを設計、構築、導入

するよりも、ずっと効率的かつ効果的な代案となるだろう。たとえば、複数のアプリケ

ーションシステムに共通のツールおよび方法を利用してユーザクセスコントロールを

設計する方が、各アプリケーションシステムに独自のセキュリティ管理機能を開発する

よりも、効率的かつ効果的となる可能性がある。この判断を行う場合、効率や効果だけ

でなく、たとえば技術的な実現可能性など、判断に影響を与える他の要因も考慮する必

要がある。

IT 活動の一部または全体を第三者であるサービス提供企業に委託している場合、所定

のコントロール活動における責任をサービス提供企業に移管している可能性がある。し

かし、委託している環境の有効性、およびサービス提供企業が内部で実施しているコン

トロール、プロセスの開発、導入に対する終的な説明責任は経営層が有している。


保証業務担当者は頻繁に、アプリケーション統制の有効性に対して、保証の提供を要請

される。将来のソリューションや業務プロセス全体の一部としてのアプリケーションコ

ントロールの予定設計を評価することによって、「導入前」保証が提供される場合ある。

また、コントロールの設計と運用の有効性を「導入後に」評価し、保証を提供する場合

がある。

保証業務担当者が保証の提供を行うアプローチは、保証提供における通常のプロセスに

従うべきである。通常のプロセスとは範囲と目的の定義、ソリューションとそれに関連

するコントロール目標の理解、設計されたコントロール活動を運用した場合にコントロ

ール目標が達成されるかどうかの評価、コントロール活動が目標達成のために有効に運


用されたかどうかの評価、発見されたコントロールの欠陥およびその改善案に関する文

書化と報告などのプロセスで構成されている。

アプリケーション統制に関連する保証提供を行う場合、保証提供者はアプリケーション

が運用されている IT 処理環境の中の IT 全般統制について発見された欠陥あるいは潜在

的な欠陥の影響を慎重に検討する必要がある。それは、この不備がアプリケーション統

制の有効性の判断に重大な影響を及ぼす可能性があるためである。

保証の提供という概念は、一般的に、経営層、取締役会および株主に保証を提供する（社

内外の）監査人によって使用される。しかし、この概念は、ステークホルダーに対する

保証の提供という観点から、財務管理者および経営管理者に利用されるケースが増えて

いる。これらの経営層がステークホルダーに対して保証を提供する例としては、米国の

サーベンスオクスリー法などの法律に従い、高経営責任者（CEO）/ 高財務責任者

（CFO）が内部統制の設計と運用の有効性を保証するケースや、運用責任者（高情報

責任者［CIO］など）が CEO/CFO に対して事業ユニット内の内部統制の有効性を「部

分的に認証」するケースなどが挙げられる。

アプリケーション統制の定義


3.アプリケーション統制の定義

本書では、アプリケーションは、情報処理に使用されるプログラム化されたロジックと

自動化されたビジネスルールから成り立っている。「アプリケーション」あるいは「コ

ンピュータ化対応策」という用語は、一般的な意味で使用されている。プログラム化さ

れたロジックとビジネスルールが特定の「モジュール」の中に存在し、モジュールの集

合体が「アプリケーション」となり、アプリケーションの集合体やアプリケーションと

関連する手順が「システム」となる。本書では、このような区別を重視していない。

アプリケーション統制の有効性は、重要なビジネス目標であり、経営層がビジネスにお

ける重要な意思決定を行い、法的な要求事項を満たすために使用する情報のインテグリ

ティおよび信頼性に対する保証である。これらの概念は監査人や内部統制の専門家には

比較的よく理解されているが、経営管理部門および IT 部門にはあまり理解されていな

い。経営層は、要件を定義し、その設計を承認し、信頼性の高い運用を確実にする必要

があるため、本書は経営層がこれらの概念を把握する手助けとなることを目的としてい

る。

コントロールに関する検討は、経営層が関与したうえで、リスクの概念を理解し、リス

クを許容可能なレベルに低減するために必要なコントロール活動に関する意思決定を

行うことが重要である。

業務プロセスとコンピュータ化対応策

経営管理部門（すなわち業務処理オーナ）は、企業の経営目標の達成を確実にするため

の適切な業務ルールおよび業務プロセスに関する要件の定義に責任を負う。自動化され

たタスクおよび活動は、ほとんどの業務プロセスにおいて、重要不可欠である。

ビジネス部門と IT 部門が協力し、手作業による処理とコンピュータ化対応策を組み合

わせ、が適度に統合された業務プロセスを設計すべきである。

IT 部門は通常、経営層のビジネスルールおよび目標の達成を可能とする自動化したソ

リューションの設計、実装、運用ならびにこれらのコンピュータ化対応策が信頼性の高

い運用ができるシステム環境の提供に責任を負う。

経営管理部門は、手作業によるコントロールおよび自動化されたコントロールを含む業

務プロセス全体の運用に対して責任を負う。


導入されたコンピュータ化対応策は通常、以下の 2 つのうちいずれかの形式を取ること

になる。

・経営情報システム ― このソリューションは、企業活動の遂行および財務に関する

情報収集と処理を自動化するために使用されるが、企業のプロセス、資源および顧

客に関する情報収集と処理を自動化するためにも使用される。一般的な例としては、

財務情報の収集と処理を自動化する基幹業務システム（ERP）、およびビジネスの

意思決定をサポートするために使用されるデータウェアハウスあるいは経営情報シ

ステム/意思決定支援システム（EIS/DSS）などが挙げられる。

・プロセス自動化システム ― このソリューションは、プロセス内の特定の作業を自

動化するために使用される。自動車製造に使用されるロボットシステムは、プロセ

ス自動化の 1 つの例である。

本書では、あらゆる種類のシステムに関連するアプリケーション統制に着目し、コント

ロール活動の設計、導入および運用に関するガイダンスを提供している。それは、いず

れの種類の情報システムでも、主要な意思決定に関わる重要な情報が提供されるからで

ある。

アプリケーション統制とは

端的に言えば、アプリケーション統制とは、アプリケーションまたはアプリケーション

システムに関連する内部統制のサブセット（一部）である。アプリケーション統制の理

解を深めるためには、内部統制とコントロール活動の基本的な理解から始めるのがよい。

トレッドウェイ委員会組織委員会（COSO）では、内部統制を以下のように定義してい

る。

内部統制とは、以下に分類される目的達成に対する合理的な保証を提供するために

設計され、企業の取締役、経営層およびその他の従業員によって遂行される 1 つの

プロセスである。

・業務の有効性と効率性

・財務報告の信頼性

・関連法規の遵守

COSO では、コントロール活動を、経営者の指示を確実に実行させるために役立つ

ポリシーおよび手続きとして定義している。4

4 www.coso.org/resources.htm


この文脈では以下のようになる。

アプリケーション統制は、与えられたコンピュータ化対応策に関連する目標が達成され

るという合理的な保証を提供するために設計されたポリシー、手続および活動であると

捉えることができる。

アプリケーション統制の一般的な例を以下にいくつか挙げる。

・論理的アクセスコントロール（アプリケーション機能へのアクセスを制限）

・データ入力/項目妥当性チェック（入力されたクレジットカード番号の妥当性チェッ

クなど）

・ビジネスルール

・ワークフロールール（購買依頼の回覧と承認など）

・事前に定義された値による項目入力値の制限（価格情報など）

・事前に定義されたトランザクションステータスに基づくワークステップ（オープン

＞レビュー＞クローズなど）

・照合

・アプリケーションが生成した例外レポートのレビューとフォローアップ

・自動アクティビティログ

・自動計算

・経営管理と監査証跡

アプリケーション統制とは、アプリケーションシステム内のトランザクションおよびデ

ータの処理に係るコントロールを指すため、それぞれのアプリケーションに固有のもの

である。手作業またはプログラム化されたアプリケーション統制の目標は、手作業およ

びプログラム化された処理結果の記録、入力されたエントリーの妥当性評価の正確性、

インテグリティ、信頼性および機密性を確保することである。

アプリケーション統制の目標

前述のように、アプリケーション統制は、与えられたアプリケーションに関わる経営層

の目標が達成されるという合理的保証を提供するものである。経営層の目標は、一般的

に、ソリューションに対する具体的な機能要件の定義、情報処理におけるビジネスルー

ルの定義、および補完的な手作業による手続の定義の中で明確化される。その例を以下

に示す。

・網羅性 ― アプリケーションがすべてのトランザクションを処理し、その結果得ら

れる情報の完全性を指す。

・正確性 ― すべてのトランザクションが正確かつ想定通りに処理され、その結果得

られる情報の正確性を指す。


・妥当性 ― 有効なトランザクションだけが処理され、その結果得られる情報の妥当

性を指す。

・承認 ― 適切に許可されたトランザクションだけが処理される。

・職務分離 5 ― アプリケーションは経営層によって定義された適切な職務および責

任の分掌に従って運用される。

ビジネス目標を達成するには、情報は一定のコントロール基準に従う必要がある。

COBIT では、この基準を情報のビジネス要件と呼ぶ。COBIT では以下の 7 つの個別基

準（部分的に重複）が定義されている。

・有効性 ― 該当するビジネスプロセスに関連する適切な情報であること、またそれ

らの情報がタイムリーで正確かつ矛盾がなく、使用可能な状態で提供されることを

指す。

・効率性 ― 情報の提供が資源の適な（も生産的かつ経済的な）利用により行わ

れることを指す。

・機密性 ― 機密情報を不正な開示から保護することを指す。

・インテグリティ ―情報の正確性と網羅性と有効性が、ビジネスの価値と期待に一

致している関係を指す。

・可用性 ― 現在および将来においてビジネスプロセスで必要な情報が利用可能であ

ることを指す。また、そのために必要な資源および関連する性能の保全も考慮する。

・コンプライアンス ― ビジネスプロセスが従うべき法律、規制および契約条項の遵

守、すなわち、外部から課せられるビジネス基準と社内ポリシーの遵守も指す。

・信頼性 ― 経営層が企業を運営し、受託者としての責任とガバナンス責任を果たす

ための適切な情報を提供することを指す。

これらの要件は、特有の業務プロセスの性質によって変わる可能性がある。これらの情

報要請規準は、内部統制活動の仕組みを通じて達成される。これらのコントロール活動

の中には、業務プロセスおよびアプリケーションシステムに組み込まれるものもあれば

（アプリケーション統制）、IT プロセスおよびアプリケーションの環境を管理する運

用サービスの中で実施されるものもある（IT 全般統制）。アプリケーション統制と IT

全般統制との関係については、「第 6 章：アプリケーション統制と IT 全般統制の関係」

で説明する。

5 IT ガバナンス協会、COBIT® 4.1、米国、2007 年


COBIT 4.1 では、6 つのコントロール目標とアプリケーション統制に関連するコントロ

ールプラクティスが説明されている 6。

・ AC1 ソースデータの準備と許可 ― 原始帳票が、定められた手続に従い、該当文書

の作成と承認に関する職務分離を十分に考慮した上で、許可を受けた資格のある要

員によって準備されていることを確認する。入力ミスや入力漏れは、効果的な入力

フォームを作成することで小限に抑えることができる。入力ミスや不正データを

検出して、報告、訂正できるようにする。

1. データが記録可能であり、ワークフローで制御され、その後のリファレンスチ

ェックによって正確性を高めることができるように原始帳票を設計する。必要

に応じて、原始帳票の設計に網羅性コントロールを盛り込む。

2. ソースデータの入力準備の手続を作成し、文書化する。それらを許可を受けた

資格のある要員に効果的かつ正確に周知する。この手続では、必要な承認レベ

ル（原始帳票の作成、編集、承認、決定および却下）を作成し、明確にする必

要がある。また、それぞれの取引タイプに応じて、利用する原始メディアを明

確にしておく必要がある。

3. データ入力に責任を負う部署は、許可された要員リスト（各人の署名付き）を

確実に保持する。

4. すべての原始帳票には、標準的なコンポーネント（適時性、規定された入力コ

ード、初期値など）を盛り込み、適切に文書化したうえで、確実に経営層が承

認する。

5. すべての取引に対して一意かつ連続した識別子（インデックス、日付および時

刻など）を自動的に割り当てる。

6. 適切に承認されていない、あるいは原始帳票が不完全であるため、修正が必要

な原始帳票を提出元に差し戻し、差し戻されたという事実をログに記録する。

ログを定期的にレビューすることで、修正された帳票が適時に提出元に差し戻

されていることの確認、またパターン分析の実施、根本的な原因の調査が可能

となる。

・ AC2 ソースデータの収集と入力 ― データ入力は、許可を受けた資格のある要員に

よってタイムリーに実施されるように定める。誤入力されたデータの訂正と再送信

は、元のトランザクションの許可レベルを損なうことのないように実施する。元の

原始文書は、復元時に必要となる場合に備えて、一定期間にわたって保存しておく

ようにする。

6 IT ガバナンス協会、COBIT® 4.1、米国、2007 年、p. 16


1. 原始帳票の適時性、網羅性および正確性に関する基準を定義し、周知する。そ

の基準に則してデータ入力が確実に実施されるような仕組みを確立する。

2. 重要な取引には予め採番された原始帳票を使用する。取引において連番が要求

されている場合は、連番となっていない原始帳票を特定し、正しい番号を割り

振る。網羅性がアプリケーション要件である場合は、欠番となっている原始帳

票を特定する。

3. トランザクションの入力、編集、承認、決定および却下、ならびにエラー対応

の実施者を定義し、それを周知する。アクセスコントロールを導入し、説明責

任を果たすため、役割と責任の根拠となる証拠を記録する。

4. エラーの修正、回避および例外ケースへの対処、ならびに原始帳票およびトラ

ンザクションへの適時のフォローアップ、修正、承認および再処理を行う手続

を定義する。この手続では、エラーメッセージの説明文、エラーの回避条件お

よびエスカレーションレベルなどの項目について検討する必要がある。

5. エラーが発生した時点で、適時にエラーメッセージを生成する。エラーが修正、

適切に対応あるいは回避されるまで、トランザクションを処理すべきではない。

即時に修正できないエラーは自動的に保留ログとして記録され、有効なトラン

ザクションの処理を継続すべきである。エラーログを適切な期間内にレビュー

し、特定の期間内に対処する。

6. エラーおよび例外ケースのレポートを適任者がレビューし、適切な期間内にフ

ォローアップおよび修正を行い、必要であればインシデントをより上のレベル

に報告する。自動化されたモニタリングツールを使用して、エラーを明確化に

し、モニタリングおよび管理を行う必要がある。

7. 原始帳票を、法規制要件あるいはビジネス要件を満たす十分な期間にわたって

安全に保管する。（業務あるいは IT のいずれかの部門が保管を担当する）

・ AC3 正確性、網羅性および真正性のチェック ― トランザクションの正確性、網羅

性、および妥当性を検証する。入力したデータを確認し、可能な限り原本に近づけ

て編集する、または修正を求めるようにする。

1. オンラインセッション中、トランザクションデータを可能な限りデータ入力タ

イミングで、対話的に検証する。マニュアル入力、システムによる自動生成ま

たはインターフェースされた入力のいずれの場合でも、トランザクションデー

タは、正確性、網羅性および妥当性のコントロールチェックの対象として検証

する。可能な限り、初のエラー発見後にトランザクション妥当性評価を止め

るのではなく、効率的に修正するために分かりやすいエラーメッセージを即座

に表示する。

2. データ入力の正確性、網羅性、妥当性および法規制要件へのコンプライアンス

を検証するためのコントロールを導入する。コントロールには、シーケンスチ


ェック、リミットチェック、範囲チェック、妥当性チェック、合理性チェック、

テーブル参照、存在チェック、キー検証、チェックディジット、網羅性チェッ

ク（合計金額、合計件数、合計文書数、ハッシュトータルなど）、重複および

論理的関係チェック、およびタイムエディットなどが含まれる。妥当性の基準

とパラメータは定期的な見直しおよび確認が必要である。

3. 許可を受けた資格のある要員のみがデータの入力、修正および承認を行うよう

に、アクセスコントロールおよび役割と責任の仕組みを構築する。

4. トランザクションデータの入力、修正および承認の職務分離ならびに妥当性評

価ルールを定義し、自動化されたコントロールおよび役割と責任のルールを導

入する。

5. 妥当性評価の基準から外れたトランザクションを記録し、一時中断ファイルへ

移動させる。すべてのエラーを適時に報告し、有効なトランザクション処理を

遅延なく実施する。

6. エディット妥当性評価ルーチンでエラーになったトランザクションを、エラー

が修正されるまでフォローアップの対象として検証する。根本的な原因分析の

ために、処理エラーに関する情報を保持し、手続と自動化されたコントロール

の調整に役立てる。

・ AC4 処理のインテグリティと妥当性 ― 処理サイクルを通じて、データのインテグ

リティと妥当性を維持する。誤りのあるトランザクションが検出されても、有効な

トランザクションの処理は中断されない。

1. トランザクション処理の開始を承認し、適切で承認されたアプリケーションと

ツールのみの使用を強化するための仕組みを構築し、導入する。

2. 必要に応じて、自動化されたコントロールによる処理が完全かつ正確に実行さ

れていることを定期的に検証する。コントロールには、シーケンスおよび重複

エラーのチェック、トランザクション/レコードのカウント、参照インテグリテ

ィチェック、コントロールおよびハッシュトータル、範囲チェックおよびバッ

ファオーバーフローなどが含まれる。

3. 妥当性評価ルーチンではじかれたトランザクションを記録し、一時中断ファイ

ルへ移動したことを検証する。ファイルに有効なトランザクションと無効なト

ランザクションが含まれている場合、有効なトランザクションの処理を遅延な

く実施し、エラーを適時に報告する。根本的な原因分析のために、処理の失敗

に関する情報を保持し、手続きと自動化されたコントロールの調整に役立たせ、

エラーの早期発見または予防を確実なものとする。

4. 妥当性評価ルーチンではじかれたトランザクションを、エラーが修正されるま

で、あるいはトランザクションがキャンセルされるまでフォローアップの対象

として検証する。


5. ジョブの実行順序が文書化され、IT 運用部門に周知されていることを確認する。

ジョブのアウトプットには処理中にデータが不適切に追加、変更あるいは欠落

しないように、後続のジョブに関する十分な情報を確実に含んでいなければい

けない。

6. すべてのトランザクションに対して一意かつシーケンシャルな識別子（インデ

ックス、日付と時刻など）があることを確認する。

7. 処理されたトランザクションの監査証跡を保持する。オンラインまたはバッチ

処理に対して入力日時およびユーザ ID を監査証跡に組み込む。機密性の高い

データに関しては、処理結果リストに処理前後のイメージを盛り込み、ビジネ

スオーナが変更の正確性を確認し、承認しなければならない。

8. システムおよびデータベースユーティリティによるデータ処理において、想定

しない中断があっても、データのインテグリティを保持する。運用上の問題解

決のために処理の失敗あるいはシステムやデータベースユーティリティを使

用した場合のデータインテグリティを確認するためのコントロールを確実に

整備しておく。処理の前にすべての変更を報告し、ビジネスオーナの承認を得

ておかなければいけない。

9. トランザクションの修正、無効化、重要度の高い処理については、データ入力

を実施していない管理者が適切かつ迅速に詳細をレビューする。

10. ファイル合計を照合する。たとえば、トランザクション件数や金額をデータと

して記録しているパラレルコントロールファイルは、トランザクションの実行

後にマスターファイルのデータと比較する必要がある。処理件数や合計金額に

不整合がある場合は状況を明確にし、報告を行い、それに対応する。

・ AC5 出力のレビュー、調整およびエラー処理 ― 出力は、許可された方法によって

扱われ、適切な受領者に送付され、送信中に保護されるように、手続とこれに伴う

責任を定める。出力の正確性について検証、検出、修正を行い、また、出力から得

られる情報を利用できるように、手続とこれに伴う責任を定める。

1. IT アプリケーションからの出力処理または出力結果の保管を行う場合、プライ

バシーやセキュリティ要件を考慮し、定められた手続に従って行う。出力結果

の配布の手続を定め、周知しそれに従う。

2. 有価証券などの機密性の高い全ての出力結果については、適切な間隔で物理的

な在庫を確認し、在庫データと比較する。機密性の高い出力文書のうち、例外

処理または拒否処理されたすべての理由を説明するために、監査証跡による手

続を作成する。

3. 出力が行われたヘッダのコントロールトータルや証跡レコードと、データ入力

時にシステムが生成したコントロールトータルの差とを照合し、処理の網羅性

と正確性を検証する。コントロールトータルが不一致の場合は、それを適切な


レベルの経営層に報告する。

4. 他の操作を実行する前に処理の網羅性および正確性を検証する。電子的に出力

された結果を再利用する場合には、その後の利用の前に妥当性評価が行われる

必要がある。

5. ビジネスオーナは、終的な出力結果の適切性、正確性、網羅性のレビューお

よび、情報管理基準に準拠していることを検証する手続を定義し、導入する。

潜在的エラーを報告し、ログを管理ツールへ自動的に記録し、適時にエラーに

対処する。

6. アプリケーションが機密性の高い出力結果を生成する場合は、受領者を定め、

人や機械が認識できるようにラベリングし、それに従って配布する。必要に応

じて、特別なアクセスコントロールが設定された出力デバイスに送信する。

・ AC6 トランザクションの認証とインテグリティ ― 内部アプリケーションとビジ

ネス機能/運用上の機能（企業の内外を問わず）の間でトランザクションデータをや

り取りする前に、データの宛名が正しいかどうか、送信元の真正性、および内容の

インテグリティをチェックする。送信または移送の間の真正性とインテグリティを

維持する。

1. トランザクションを電子的にやり取りする場合は、トランザクションのデータ

転送方式、相互の責任範囲および例外処理方法など、相互認証に必要な伝達お

よび仕組みに関する基準を作成する。

2. 業界標準にしたがって、アプリケーションによって処理されたトランザクショ

ンの出力にタグを付けることで、取引先企業との相互認証、否認防止に対する

証拠提供となり、下流のアプリケーションが受領した内容のインテグリティ検

証が可能となる。

3. 送信中のオリジナルデータの真正性およびインテグリティの維持のために、ア

プリケーションを処理するその他のトランザクションから受け取った入力デ

ータを分析する。


図 1 は、情報要請規準と、これまで定義してきたアプリケーション統制の目標の関係を

示している。

図 1 ― アプリケーション統制の目標と情報要請規準

情報要請規準

有効性

効率性

機密性

インテグリティ

可用性

コンプライアンス

信頼性


AC1 ソースデータの準備と許可 S P S P S

AC2 ソースデータの収集と入力 S S S P S

AC3 正確性、網羅性および真正性のチェック S P S P S P P

AC4 処理のインテグリティと妥当性 P P P P P

AC5 出力のレビュー、調整およびエラー処理 P S P P P P P

AC6 トランザクションの認証とインテグリティ S P P P

P ＝プライマリー、S ＝セカンダリー

これは、図 2 に示されるアプリケーション統制の位置づけのためのフレームワークを提

供するものである。この図は IT 全般統制の目標をすべて示すものではなく、あくまで

も一部の IT 全般統制ではこれらの情報要請基準のすべてを満たす必要がある可能性が

ある（セキュリティコントロールなど）という点に注意すること。IT 全般統制に関連

する追加情報については、「第 6 章：アプリケーション統制と IT 全般統制の関係」を

参照。


図 2 は、経営層のビジネスゴールと目標の達成および当該アプリケーションに関連する

情報についての目標を満たすために、アプリケーション統制と IT 全般統制により、情

報要請基準の達成が必要であるということを示している。

業務処理統制とアプリケーション統制

業務処理統制とは、プロセス全体に関する経営層の目標を幅広く達成するために設計さ

れた活動である 7。一方、アプリケーション統制は、特にこれらの業務プロセスを実現

するために使用されるアプリケーションと関連情報に関連する業務処理統制の一部（サ

ブセット）である。図 3 は、アプリケーション統制と業務処理統制の関係を示している。

ビジネスリスクと情報処理

業務プロセスにはリスクが多く存在しており、ビジネス情報の複雑な処理によって、さ

らにリスクが発生する可能性がある。コンピュータ化対応策は手作業による処理よりも

はるかに信頼性が高いものと考えられているが、これは、コンピュータ化対応策におけ

るキーリスクが特定されていて、適切なコントロールが導入されている場合に実現され

る。

主要情報関連リスクおよび情報処理関連リスクの一例：

・不完全および不正確な情報処理 ― このリスクは、情報の収集、入力または処理中

に発生する可能性があるエラーに関連している。

7 COBIT 4.1 では、以下のプロセスコントロール目標が明確化されている。PC1 プロセス達成目標とプロセ

ス目標、PC2 プロセスオーナシップ、PC3 繰り返し可能なプロセス、PC4 役割と責任、PC5 ポリシー、

計画、および手続、および PC6 プロセスの成果の改善

図 2 ―アプリケーション統制

情報に関するビ

ジネスゴールお

よび目標

情報要請規準

IT 全般統制の

目標アプリケーション

統制の目標

アプリケーション

統制

満たす

可能にする

達成する


・無効あるいは承認されていないトランザクションの処理 ― 前述のリスクが正規

のビジネストランザクションの処理中に発生する恐れがあるエラーに関連するもの

であったのに対し、これは、誤りあるいは不正なトランザクションの処理に関連し

たリスクである。

・マスタデータへの不正な変更 ―システムによる処理に続く情報に対する不正な変

更のリスクである。

・コントロールの回避、無効化、手作業による入力 ― これは、自動化されたアプリ

ケーション統制の回避、無効化あるいは手作業による入力により発生するリスクで

ある。（これらの機能は、すべてではないがほとんどのアプリケーションシステム

に備わっている）

・非効率 ― このリスクは、情報の収集、入力、処理、出力、あるいは情報の伝達に

おける不必要なコストの発生または遅延に関連している。

・機密性の損失 ― このリスクは、経営層によって機密性が高いものとして識別され

ている情報（業務あるいは法令順守の理由など）の不注意あるいは故意による開示

に関連している。

・情報の非可用性― 必要な時に情報が入手できず、それによって処理の遅れが生じ、

適切な意思決定が出来ない。

・インテグリティの欠如 ― このリスクは、処理されたデータの信頼性の欠如に関連

している。

ビジネスゴール

および目標

業務プロセス


統制の目標

アプリケーシ

ョン統制

達成する

可能にする

達成する

業務処理統制

業務プロセスの目標

図 3 ―業務プロセスとアプリケーション統制


アプリケーションコントロールの目標と財務報告の内部統制

有効な内部統制の要件はすでに十分に確立されたものとなっている 8。しかし、米国の

サーベンスオクスリー法や世界各国の類似法規の制度化により、近年においては経営目

標の中でも特に財務情報に関連する分野に注目が集まっている。それは、財務報告の内

部統制を適切に設計し、効果的に運用することで財務諸表およびそれに関連する開示に

関連する虚偽表示のリスクを軽減することである。

企業がサーベンスオクスリー法または類似の財務報告制度の対象となっている場合、経

営層は、財務情報に関連するコントロールの有効性を証明することが求められる。経営

層が自社の財務関連の業務プロセスのコントロール目標を明確化する際、財務情報に関

連するアサーション 9にそれぞれ対応しているかを検討する必要がある。ほとんどの財

務関連の業務プロセスが自動化されたアプリケーションシステムに支えられているた

め、アプリケーション統制の目標およびアプリケーション統制は、経営層による全社的

なコントロール評価活動において重要な構成要素となっている。特にサーベンスオクス

リー法の要件の遵守に関連するアプリケーション統制の目標およびアプリケーション

統制に関するガイダンスは、ITGI の発行物『IT Control Objectives for Sarbanes-Oxley, 2nd

Edition（サーベンスオクスリー法（企業改革法）遵守のための IT 統制目標、第 2 版）』

に記載されている。

8 以下のような発行物が含まれる：不正な財務報告に関する国家委員会（トレッドウェイ委員会）、不正な財務報告に関する国家委員会の報告書、米国、1987 年。イングランド・ウェールズ勅許会計士協会、内部統制－統合規範に関する取締役のためのガイダンス（ターンブル報告書）、英国、1999 年、

www.icaew.com/index.cfm/route/120907/icaew_ga/pd; コーポレートガバナンスキング委員会、コーポレート・

ガバナンス―南アフリカ・キング委員会報告書（キング I 報告書）、南アフリカ取締役協会、南アフリカ

1992 年。コーポレートガバナンスキング協会、コーポレート・ガバナンス―南アフリカ・キング委員会報

告書（キング II 報告書）、南アフリカ取締役協会、南アフリカ、 2002 年、www.iodsa.co.za/king.asp#King%20I%20Report%20-%201994. 9 米国公認会計士協会（ AICPA) 、 AU326.03 、米国、 2008 年、

www.aicpa.org/download/members/div/auditstd/AU-00326.PDF では、財務情報の観点からアサーションを以下

のように定義している。アサーションとは、財務諸表の構成要素の中に統合される経営層による表明のことである。これらは、明示的あるいは暗示的に表現され、実在性または発生、網羅性、権利と義務、評価または期間帰属、表示と開示といった広義のカテゴリーにしたがって分類することができる。


4.アプリケーション統制の設計と導入

第 3 章で述べたように、アプリケーション統制の要件（COBIT の情報要請規準を利用）

は、コントロールに対するビジネス要件と経営層のリスクアセスメントに基づいている

べきである。コントロール活動の導入には費用がかかるため、業務にも影響を与える

リスクへの対応を優先して行う必要がある。経営層は識別したリスクに対して、コント

ロール目標を達成するためにどのコントロール活動を導入するのかを検討し、その活動

を導入した場合の費用とベネフィットのトレードオフを勘案して終的な決定を行う。

また、残存リスクについて理解し、そのリスクを許容するのか、あるいはコントロール

活動を強化することでリスクを許容可能なレベルにまで低減するのかを判断する必要

がある。

アプリケーション統制とシステム開発のライフサイクル

アプリケーションシステムの開発や調達に際し、多数の SDLC モデルが存在する。その

中でも「ウォーターフォール方式」SDLC アプローチがおそらくも有名である。これ

は、アプリケーション開発（またはサードバーティからの購入）が体系的で連続したフ

ェーズで構成されており、各フェーズのアウトプットが次フェーズのインプットになっ

ている。また、「アジャイル方式」など対話型の開発アプローチも一般的になりつつあ

る。アジャイルでは、実行可能な小ピースになった機能が繰り返され（あるいは反復さ

れ）、各機能の繰り返しは、早期に事業価値の測定を実現可能にし、その機能を継続的

に改善拡張していくことに重点を置いてプロジェクトの開発サイクル（計画、要件分析、

設計、コーディングおよびテスト）を実施する。企業がいずれの SDLC アプローチを採

用する場合でも、情報要請規準と経営層のコントロール目標を確実に達成するため、シ

ステム導入の初期段階からアプリケーション統制を組み込んでいくステップが重要で

ある。アプリケーション統制の定義は、他のビジネス機能要件の定義に関連したステッ

プと合わせて組み込んでいくが、それぞれのシステム開発のライフサイクル（SDLC）

の中で独立したステップとすべきである。

企業を横断的に、生成、使用されるデータを統合的に活用するために、データモデリン

グを利用する企業もある。企業データモデルは、データの収集、保存、処理あるいはア

クセスの「方法」とは関係なく、データについての統合された単一の定義を示す。その

データ定義の一部として、企業は、COBIT の 7 つの情報要請規準（有効性、効率性、

機密性、インテグリティ、可用性、コンプライアンスおよび信頼性）を含め、それらの

データと関連する情報システムに対するビジネス要件の全範囲を盛り込むことができ

る。


調達と導入（AI）ドメインで実施する主要なアクティビティについては COBIT 4.1 に記

載されている。図 4 では、AI プロセスとアプリケーション統制に関連するアクティビ

ティ（設計、構築およびテスト）の関係を示している。

「付録 A ―COBIT 4.1 のプロセスおよびコントロール目標に対するアプリケーション

統制活動のマッピング」には、アプリケーション統制の設計および導入の詳細なマッピ

ング、ならびに COBIT 4.1 の調達と導入活動との統合が記載されている。

ビジネス要件とリスクに基づくコントロール目標の設定― AI1

開発/調達ライフサイクルでは初めに、「AI1 コンピュータ化対応策の明確化」プロセ

スの一環として、ビジネスゴール/目標に基づき、ビジネス要件を十分に理解し、定義

する。次に、その業務と提案されたコンピュータ化対応策に関連する情報リスクについ

てアセスメントを実施し、そのソリューションによって実現すべきコントロール要件を

定義する。アプリケーション設計における実現可能性とソリューションの開発および導

入に関連する情報リスクの観点から、重要性の高いビジネスリスクの検討を行う。実現

可能性調査の目的は、経営層がソリューションの評価を行うために必要な根拠を提供す

ることである。

SDLC のこのフェーズにおける主要なアクティビティは以下の通りである。

・主要なステークホルダーを特定し、アプリケーション統制に関する役割およびそれ

ぞれの責任を明確にする。アプリケーション統制の要件定義、アプリケーションコ

ントロール設計とその承認に対する役割と責任がこれに該当する。

・アプリケーションの目標および機能要件に基づき、情報および情報処理に関連する

リスクのアセスメントを実施する。

・識別されたリスクを許容可能なレベルに低減するため、コントロール目標を設定し、

AI1 コンピュータ化対応策

の明確化

図 4 ―ソフトウェアの開発/調達プロセスとアプリケーション統制

調達と導入ソリューション

AI2 アプリケーションソフトウェアの調達と保守

AI3 技術インフラストラクチャーの調達と保守

AI4 運用と利用の促進

AI5 IT 資源の調達

AI6 変更管理

AI7 ソリューションおよびその変更の導入と認定

アプリケーション統制のテストと

承認

コントロールの文書化とユーザトレ

ーニング

アプリケーション統制の構築/設

定

アプリケーション統制の設計

コントロール目標の設定


それを文書化する。このプロセスにおいて、コントロール目標は、アプリケーショ

ン統制の機能要件に含まれる。つまり、アプリケーションシステムによって実現さ

れるソリューションは、法令対応および設定されたコントロール目標を達成するた

めに十分なコントロールとなっている必要がある。

・サードパーティのソフトウェアを選定および調達する場合は、設定されたコントロ

ール目標を機能要件の一部として提案依頼書（RFP）に組み込む必要がある。

アプリケーション統制の設計 ― 例

ある企業が、自社の買掛金とベンダーへの支払プロセスをサポートするアプリケーショ

ンシステムの開発または購入を希望しているケースを例に検討を行う。このプロセスに

おける重要なリスクの 1 つが、二重支払処理、つまり同一の物品またはサービスに対し

て複数回の支払を行ってしまうリスクである。経営層はリスクアセスメントを実施し、

このリスクの重要性と発生可能性を検討し、このリスクを許容できるレベルまで低減す

るためにコントロールの導入を行う必要があると結論付けた。経営層は、アプリケーシ

ョン統制 AC3 を参考にし、アプリケーションに対するコントロール要件（買掛金に計上

された金額が受領した正当な物品またはサービス分に相当していること、およびそれら

の金額が複数回計上されていないことの検証）を明確にすることで必要なコントロール

活動を組み込むことができる。この例では、どのようにコントロール要件を明確にし、

アプリケーションシステムの機能要件の定義に盛り込んでいくのかを説明をしている。

経営管理部門およびユーザは、要件定義フェーズの一環として、リスクアセスメントに

基づくコントロール要件の明確化や定義に積極的に関与していく必要がある。ビジネス

プロセスオーナは、そのプロセスに特有のリスクアセスメントを実施し、十分かつ適切

なコントロール要件を確実に定義することに対して、実行責任および説明責任を負う。

プロセスオーナは、この責任を遂行するため、リスクおよびコントロールの専門家やそ

の業務に精通した利用者からの助言を必要とする場合がある。コントロールの専門家が

適切かつ適時に関与することで、必要なアプリケーション統制の要件を明確化し、ビジ

ネス目標の達成を支援することができる。

リスクアセスメントの実施とコントロール目標の設定に関する追加検討事項

キーメッセージ #1

企業は、通常アプリケーション設計の一環として、ビジネス要件および機能要件の検討

を行なうが、「コントロール」要件の検討を積極的に行うことはない。このため、必要

とされるコントロールが初期段階からソリューションの中に組み込まれず、導入後にコ

ントロール活動の「組み込み」が必要となり、導入や運用における課題となる可能性が


ある。システム仕様の整合性を修正する費用だけではなく、導入後のコントロールの組

み込みに対して膨大な追加費用が発生する可能性がある。経営層はビジネスリスクに基

づいてコントロール要件が適切に定義され、機能要件に盛り込まれていることを検証す

る必要がある。

「AI1 コンピュータ化対応策の明確化」における主要な目的は、ビジネス要件を正確に

定義することである。リスクアセスメントを実施し、コントロール目標を設定すること

は、次フェーズで設計および構築されるアプリケーション統制活動の網羅性、有効性お

よび効率性を決定する上で重要なステップである。このプロセスにおいて役立つ追加検

討事項は以下の通りである。

・リスクアセスメントにおいてすべてのキーリスクが検討されているか ―識別され

たリスクの網羅性を確認し、業務プロセス全体の目標、業務プロセスにおけるアプ

リケーションシステムの目標、情報要請規準、および COBIT 4.1 で記述されている

アプリケーション統制目標（AC1～AC6）について検討を行う。

・識別されたリスクの重要性が適切に優先順位付けられているか ―一般的に、リス

クはその発生頻度やリスクが発生した場合の影響の大きさに基づいてアセスメント

が実施され、優先順位が付けられる。社内外の監査を含めたリスクおよびコントロ

ールの専門家に意見を求め、アセスメントを完了させる。財務関連リスクに関して

は、潜在的な影響の重要性についても考慮が必要である。経営層やビジネスプロセ

スオーナが関与し、リスクの重要性に対して、それぞれの見解を共有し、検討を行

う。

・設定されたコントロール目標が識別されたリスクへ十分に対応するか、あるいはリ

スクを低減しているか ―あらゆるリスクを回避する必要はないが、許容可能なレ

ベルまで低減する必要がある。リスクが許容可能なレベルまで低減されたかどうか

の判断は経営層が関与して行う必要がある。アプリケーション統制目標を情報要請

規準にマッピングし、設定されたコントロール目標の網羅性を確認する。必要に応

じて、自動コントロールの補完や代替コントロール（場合によっては手作業）につ

いて検討し、コントロールの見直しを行う。これは全体的なコントロールフレーム

ワークを考慮する必要がある。

アプリケーション統制の設計 ― AI2

コンピュータ化対応策の開発や調達の一環としてアプリケーション統制の設計を行う

必要がある。対象システムに対するビジネス要件を満たすために必要な活動や手続きの

開発と共に、前フェーズで定義されたコントロール要件とコントロール目標に基づきコ

ントロール目標の達成に必要なアプリケーション統制活動の開発を行う。多くの場合、

ビジネス要件を満たすよう設計された活動や手続きが、コントロール要件を満たしてい


る。アプリケーション統制の効率性および有効性を大化するためにはアプリケーショ

ン統制をそれ単体で開発や評価をするべきではない。業務プロセス、あらゆるアプリケ

ーションシステム、IT 処理環境、コントロール活動の相互関係を検討し、十分に理解

することが重要である。たとえば、アプリケーションやプロセスの相互の関係によって

は、他のプロセスの既存のコントロール活動をリスクの低減に利用できる可能性がある。

一方で、新たなリスクが生じたり、リスクに影響を与えたりする可能性もある。したが

って、関連する他のアプリケーションやシステム環境、情報管理基盤の構成要素を考慮

して、コントロールの検討を行う必要がある。

ここでは、ビジネス要件とコントロール要件の両方を満たす活動や手続きを設計するこ

とが重要である。SDLC のこのフェーズにおける主要なアクティビティは以下の通りで

ある。

・アプリケーション仕様の詳細設計（カスタム開発のアプリケーション） ―ビジネ

スアナリストは、開発チームがアプリケーションを構築できるようにビジネス要件

を詳細な仕様に落とし込む。カスタム開発を行うアプリケーションの場合、プログ

ラミング/アナリストチームがソフトウェアアーキテクチャ全体を定義し、そのアー

キテクチャをモジュールやコンポーネントといった構成要素に分解する。コントロ

ール要件を満たすため、これらのモジュールやコンポーネントに、必要な自動化さ

れたアプリケーション統制を組み込む必要がある。

・ベンダーソリューション（購入したソフトウェアアプリケーション）の評価 ―RFP

の中で明記したビジネス要件およびコントロール要件に対するベンダーからの提案

を評価する。ベンダーの提示したソリューションが企業のビジネス要件とコントロ

ール要件ならびに詳細な仕様をどの程度満たしているかを判断する。期待している

リスクの低減がどの程度達成できず、それが企業に与える影響がどの程度かという

観点でコントロール要件と提案されたソリューションのギャップを評価する必要が

ある。重要なギャップを解消するために、代替的な手作業によるコントロール活動

を将来の業務プロセス設計に組み込む場合もある。（次項目参照）

・将来の業務プロセスの再設計 ―業務プロセスチームがビジネス目標を達成するた

めに、新規アプリケーションシステムと連携が必要な活動やワークフローを設計す

る。定義されたコントロール要件を満たすために、必要に応じて手作業によるコン

トロール活動を組み込み、将来の業務プロセスの設計を行う。

・コントロール目標達成のためのアプリケーション統制設計の十分性アセスメント

と判断―アプリケーション品質保証（QA）計画の一環としてコントロール活動にお

ける設計の品質を保証する。コントロール活動が効果的に運用された場合、設定さ

れたコントロール目標が達成できるか、対応するリスクが許容可能なレベルにまで

低減されるかを経営層がレビューし、検証をする。


アプリケーション統制の属性

アプリケーション統制の設計（およびその設計が十分かどうかの判断）をするうえで、

多くの属性について検討を行う。これらの属性はアプリケーション統制に固有のもので

はなく、業務処理統制の属性と整合するものである。本書の目的は、内部統制の理論に

ついて議論することではなく、その理論をアプリケーション統制にどのように応用する

かに焦点を当てている。


経営層は、コントロール活動のさまざまな属性、タイプおよび性質をバランスよく検討

することで、コントロール設計の効率性と有効性を適化する必要がある。

例：

・コントロールタイプの検討。コントロール活動を手作業の活動とすべきか、自動化

すべきか、あるいはその両方、つまりハイブリッドコントロールとすべきか。自動

化する場合は、ビジネス環境の変化に伴うビジネスルールの変更に容易に対応でき

るようにコントロールを「設定可能（コンフィギュレーション可能）」なものとす

べきか。

・エラー対応における費用対効果の検討。予防的コントロール活動と発見的コントロ

ール活動のどちらを採用するか。

・コントロールの頻度、リスクとコントロール活動の関係、およびコントロール活動

実施者の役割の検討。これらはエラーが発生するリスクを許容可能なレベルにまで

十分に低減しているか。

・リスク低減によって得られる便益とコントロール活動の追加費用（構築、テストお

よび実施）の検討。

手作業/自動化/ハイブリッド/設定可能（コンフィギュレーション可能）なアプリケーシ

ョン統制は、以下のように手作業による活動、自動化された活動、あるいは手作業と自

動化された活動の両方によって構成されている。

・手作業によるアプリケーション統制 ― これはアプリケーションまたはシステム

を利用せず実施するコントロール活動である。たとえば、小切手への上位者による

署名や物品の領収書と発注書の照合などの手作業による活動がこれに該当する。手

作業によるコントロールは、人為的ミスのリスクが伴うため、自動化されたコント

ロールよりも信頼性が低い場合が多い。

・自動化されたアプリケーション統制 ― これはプログラム化されアプリケーショ

ンに組み込まれたコントロール活動である。たとえば、発注数量を確認する入力編

集チェックや銀行口座番号の正確性を検証する桁数チェックなどが該当する。


・ハイブリッドあるいはコンピュータに依存するアプリケーション統制 ― これは

手作業および自動化された活動の組み合わせで構成されるコントロールである。ハ

イブリットコントロールを構成するすべてのコントロールが有効に運用される必要

がある。たとえば、受注処理プロセスに、出荷責任者が未出荷レポートをレビュー

するためのコントロールが組み込まれている場合、このコントロールを有効にする

ためには、自動化された活動（正確かつ完全な未出荷レポートの生成）と手作業に

よる活動（管理者によるレポートのレビューとフォローアップ）が必要である。ハ

イブリッドまたはコンピュータに依存するコントロールを手作業によるコントロー

ルとして不適切に識別されないように、十分注意しなければならない。

ハイブリッドコントロールを構成するすべてのコントロールを有効にするため、コ

ントロールを正しく識別する必要がある。正しく識別されなければ、そのハイブリ

ットコントロール全体として有効にはならないため、重大なリスクとなる可能性が

ある。たとえば、先ほどの例で、未出荷レポートのレビューを手作業によるコント

ロールとして誤って識別した場合、未出荷レポートの網羅性および正確性を担保す

るコントロールの設計を見過ごしてしまうリスクがある。

・コンフィギュレーションコントロール ― これは一般的に、アプリケーションシス

テム内のパラメータのコンフィギュレーションをベースにし、それに依存する自動

化されたコントロール活動である。たとえば、購入システムにおいて、予め設定さ

れた承認範囲内でのみ発注を許可するコントロールは、承認範囲のコンフィギュレ

ーションに依存している。現在、市販されているアプリケーションシステムや社内

開発されたアプリケーションシステムのほとんどは、さまざまなパラメータテーブ

ルのコンフィギュレーションに大きく依存している。これらのケースでは、コント

ロール設計とコンフィギュレーションテーブルのコントロール設計を別個の要素と

して検討するのが適切な場合もある。

予防的/発見的アプリケーション統制は、以下のように定義される。

・予防的アプリケーション統制 ― このコントロールは、予め定義されたビジネスロ

ジックまたはビジネスルールに基づいてエラーの発生を予防するものであり、通常

は処理の実行または確定処理前に、トランザクションレベルで実行される。たとえ

ば、人事（HR）アプリケーションで、給与支払のための銀行口座を指定せずに新規

従業員を入力した場合にユーザをブロックするコントロールがこれに該当する。（入

力妥当性コントロール）

・発見的アプリケーション統制 ― このコントロールは、予め定義されたロジックま

たはビジネスルールに基づいてエラーを発見するように設計される。これは通常、

処理が実施された後に実行され、複数トランザクションをカバーしている場合が多

い。たとえば、サプライヤーのマスターファイルに重要な変更（サプライヤーの銀


行口座番号の変更など）があった場合、購買アプリケーションが定期的に生成する

例外レポートがこれに該当する。

エラー発生後の対応が費用増加につながる場合は、予防的コントロールの方が効率性と

有効性に優れていると考えられる。また、予防的コントロールは、発見的コントロール

よりも簡単に自動化できる。また、発見的コントロールは、手作業による活動の場合が

多い。予防的コントロールと発見的コントロールのバランスを適度に考慮して、効果的

にコントロール設計を行う必要がある。

コントロールの属性には以下のようなものが挙げられる。

・コントロールの頻度 ― これは、リスクが発生する状況や影響を考慮して検討をす

る。年次の給与支払いレビューは、給与計算における潜在的なエラーや退職した従

業員に対する不正な支払を発見するには、有効なコントロールではない。この場合、

年次でのレビューにおいて、給与額の虚偽表示を発見することができない可能性が

ある。コントロール実施の頻度が少なすぎるためにコントロールの有効性が損なわ

れている。同じ活動を、給与支払サイクルごとなど、より頻繁に実行することで、

より高い有効性が得られる。同様に、銀行残高の日次照合では、人的負荷が高いた

め、活動における人為的エラーのリスクが高まり、有効性が低くなるが、月次照合

を実施することで有効性や信頼性が高まる。（頻繁に実施する必要があり、人為的

エラーのリスクが高いコントロールの場合は、コントロール活動を自動化すること

も解決策のひとつである）

・リスクイベントに対するコントロール活動の近接性 ―これは、リスクの発生可能

性がも高いイベントに対して、プロセス中のどの部分でコントロール活動を実施

するのかを検討する。たとえば、不完全あるいは不正確なデータ入力のリスクが問

題となる場合、データの入力時点にできるだけ近いタイミングで実施するコントロ

ール活動の方が、プロセスの後の方で実施するコントロール活動よりも有効性や効

率性が高いと考えられる。経営層は、作業のやり直しやサイクルタイムの削減で得

られる便益とコントロールの実施における費用のバランスを考慮する必要がある。

この分野に関する追加ガイダンスは、「付録 B ― アプリケーション統制タイプに

関する追加ガイダンス」で記載している。

・コントロール活動の実施者 ―この属性では、主に手作業によるコントロールに関

係し、役割、職務およびコントロールに関連する決定、承認を誰が行うかを決定す

る。また、この属性は、コントロールの実施者が、職務を分離する必要のある他の

職務から適切に分離されているかどうかも考慮し、決定する。財務アプリケーショ

ンに関する追加ガイダンスは「付録 C ― 重要な会計アプリケーションにおける職

務分離」に記載している。これは ITGI の発行物『 IT Control Objectives for


Sarbanes-Oxley, 2nd Edition（サーベンスオクスリー法（企業改革法）遵守のための

IT 統制目標、第 2 版）』の職務分離に関連するセクションから引用したものである。

これはあらゆる種類のアプリケーションに対して適用可能である。

自動化されたアプリケーション統制の場合は、「実施者」の属性に、自動化されたコン

トロールが存在する具体的なアプリケーション/モジュール名を記述する。これにより

アプリケーション統制とアプリケーションが運用される IT 処理環境の有効性を結びつ

けることが可能になる。自動化されたアプリケーション統制と IT 全般統制との関係、

および自動化されたアプリケーション統制と IT 処理環境の関連性については、「第 6

章：アプリケーション統制と IT 全般統制の関係」および「第 7 章：アプリケーション

統制の保証」でさらに考察していく。

「付録 D ―アプリケーション統制の目標達成のためのコントロールプラクティス、価

値およびリスクのドライバー」には、ITGI の発行物、『COBIT® Control Practices（COBIT®

コントロールプラクティス）: Guidance to Achieve Control Objectives for Successful IT

Governance, 2nd Edition.(効果的な IT ガバナンスに向けたコントロール目標を達成する

ためのガイダンス、第 2 版)』10から引用した、アプリケーション統制に関連するような

コントロールプラクティスに関するガイダンスを掲載している。この情報は、経営陣、

業務アナリスト、およびリスクやコントロールの専門家が、アプリケーション統制活動

の設計におけるガイダンスとして利用することができる。

アプリケーション統制の構築/設定（コンフィギュレーション） ― AI2

カスタム開発を行うアプリケーションの場合、詳細な設計が完成し、それが承認された

後、システム開発者およびプログラマが、アプリケーションのコーディングを行う。そ

の際、自動化されたアプリケーション統制の要件を含めた詳細設計のコーディングを行

う必要がある。購入したアプリケーションの場合、一般的にこの段階では、アプリケー

ションベンダーならびにアプリケーションの専門家が関与して、インストールを行い、

アプリケーションコントロールの要件を含めた詳細設計に沿ってパラメータ設定（コン

フィギュレーション）を行う。購入したアプリケーションの場合、一部の機能（レガシ

ーアプリケーションシステムとのデータインターフェースなど）をカスタム開発する必

要がある。

10 IT ガバナンス協会、『COBIT® Control Practices（COBIT®コントロールプラクティス）: Guidance to Achieve


Control Objectives for Successful IT Governance, 2nd Edition』、米国、2007 年

アプリケーション統制の構築/設定（コンフィギュレーション）フェーズにおいて実施

される主要なアクティビティには以下の項目が含まれる。

・カスタム開発アプリケーションにおけるプログラムコードの開発ならびに自動化さ

れたアプリケーション統制のデバッグ（他のソフトウェア機能のコーディングおよ

びデバッグに則して実施）。

・アプリケーションのインストールと設定コントロールの設定。

コントロールの文書化とユーザトレーニング ― AI4

アプリケーションおよびアプリケーション統制（手動あるいは自動化されたもの）を運

用するには、アプリケーション統制を含めた現行のアプリケーション環境に則して、効

果的なユーザマニュアルや運用マニュアルならびにトレーニング資料を作成、更新して

いく必要がある。主要なアクティビティとして以下のようなものが挙げられる。

・コントロール目標を達成するためのコントロール活動を反映したアプリケーション

統制に関する文書を作成/更新する。

・トレーニング資料を作成/更新し、必要に応じて対象スタッフに対してトレーニング

を実施する。

・新規に採用した従業員の場合、アプリケーションと関連するアプリケーション統制

に関して、フルトレーニングを実施する。

経営層のコントロール目標達成のためにコントロール活動を文書化し、その情報をトレ

ーニングに盛り込むことは、アプリケーションおよびコントロール活動の継続的な運用

の有効性に関する役割と責任を明確にするために重要なステップである。

アプリケーション統制は、業務処理統制の一部であるため、業務プロセスの関連文書に

統合する必要がある。

アプリケーション統制のテストと承認 ― AI7

テストはソフトウェアの開発および導入プロセスにおいて不可欠なものである。承認さ

れた要件と受入基準に沿ってテストを実施し、アプリケーション統制を含むシステムの

検証と有効性の確認を行う。テストでは、テスト対象のユニットがシステムの他のコン

ポーネントに悪影響を及ぼすことなく動作するか確認をする。テスト方針、方法および

アプローチはさまざまであり、それらは導入されるアプリケーションシステムの性質と

業務プロセスによって異なる。どのようなテスト方針を選択する場合でも、自動化され

たあるいは手作業によるアプリケーション統制が期待通り機能することを確実にする

には、全体的なテスト計画の一環としてアプリケーション統制のテストを必ず実施する


必要がある。


設計されたコントロール活動が想定通りに動作するかテストによって検証されるため、

システムの受入にはこれらのアプリケーション統制のテストを盛り込むことが不可欠

である。

自動化されたアプリケーション統制、ハイブリッドおよびコンフィギュレーションコン

トロールにおける自動化に関連する部分（コンポーネント）を明確に文書化しておく必

要がある。これらはコントロールにおける運用の有効性を実証するための証跡として使

用される可能性がある。

手作業によるコントロールおよびハイブリッドコントロールに関連する手作業の活動

のテスト/検証の証跡を明確に文書化しておくことは、そのコントロールの実現可能性

を再確認し、活動に対するユーザの理解を深めることに使用できる。

この段階のアプリケーション統制に関する主要なアクティビティには以下の項目が含

まれる。

・アプリケーション統制の手作業および自動化されたコンポーネントを含めたテスト

計画を作成、文書化し、承認する。テスト計画では、機能要件および技術要件、な

らびに自動化および手作業によるアプリケーション統制に対するテスト受入基準を

満たす必要があり、さらに各コントロールに適したテストフェーズを明確にすべき

である。このようなテストフェーズの例としては、単体テスト、システムテスト（リ

カバリー、セキュリティ、ストレス/ボリュームおよびパフォーマンス）、統合テス

ト、回帰テストおよび受入テストなどが挙げられるが、これらに限定されない。ユ

ーザ受入テスト（UAT）は特に重要である。ここでユーザが、自動化されたコント

ロールの運用可能性の検証と手作業によるコントロール活動のテストを行う。

・テスト計画に従ってアプリケーション統制のテストを実施する。業務処理オーナと

エンドユーザをテストチームに関与させる。

・テスト中に発見されたエラーや問題を明確化し、記録を行い、優先順位を付けて解

決をする。

・ビジネスプロセスオーナが把握できるように、未解決の問題を含めて終的なテス

ト結果を文書化する。テストプロセスとその結果のレビューおよび評価を適切に文

書化し、監査証跡としてテスト結果を保管する必要がある。

・テスト結果を承認する。終的な受入時に、テスト計画の中で定められた合格基準

が満たされているかどうかを評価する必要がある。また、未解決の問題に関連する

リスクやそれに対する代替的なプロセス活動や代替コントロールの導入の必要性に


ついても検討すべきである。

・アプリケーション統制の設計および導入を承認する。つまり、経営管理部門がコン

ピュータ化対応策の導入を承認する前に、リスクアセスメントに基づき設定された

アプリケーション統制目標に対して、アプリケーション統制が適切に設計、構築さ

れ、期待通りに機能していることを確認する必要がある。


経営層は、アプリケーション統制の設計および導入の承認において、導入するコントロ

ールの効率性と有効性の比較、費用対効果、コントロール目標の達成、当該の情報要請

規準が満たされていることを確認する必要がある。

「付録 E ―アプリケーション統制の設計および導入のためのツール」には、アプリケー

ション統制の設計および導入において有益だと考えられるテンプレート例がいくつか

掲載されている。アプリケーション統制の要件を定義し、該当するアプリケーション統

制の目標の設定を支援するために、COBIT オンラインを活用することができる。付録 E

の「アプリケーション統制の設計および導入のためのツール」に関するセクションでは、

アプリケーション統制の目標を設定するための COBIT オンラインのツールの画面キャ

プチャが掲載されている。また、付録 E の「アプリケーション統制の設計および導入の

ためのツール」のセクションには、アプリケーション活動を明確化し、それらの活動を

該当するアプリケーション統制の目標に対してマッピングするために利用できるテン

プレートが掲載されている。テンプレートは、コントロール活動に関連するさまざまな

属性の文書化、および対応する目標を達成するためのコントロール設計の有効性に関し

て、経営層の結論の確認を提供するものである。

アプリケーション統制と既存のアプリケーション

これまでは、新規アプリケーションを調達/開発するという状況を例にしてきたが、こ

のコンセプトを既存アプリケーションにも応用することができる。既存アプリケーショ

ンの場合、経営層が以下の項目を実行することが重要である。

・ビジネス目標およびリスクに基づいてアプリケーション統制の目標を設定する。（前

述の「ビジネス要件とリスクに基づくコントロール目標の設定－ AI1」のセクショ

ンで取り上げられている）

・設定されたコントロール目標を達成するためにアプリケーション統制の設計が十分

であるかの判断を行う。（前述の「アプリケーション統制の設計 ― AI2」のセクシ

ョンで取り上げられている）

・アプリケーション統制が適切に文書化され、コントロール活動を有効かつ確実に実

施するためユーザへ適切なトレーニングを提供し、ユーザの理解を深める。（前述


の「コントロールの文書化とユーザトレーニング ― AI4」のセクションで取り上げ

られている）


新規システムの場合と同様に、既存のアプリケーションに対してもリスクアセスメント

および適切なコントロール目標の設定、アプリケーション統制の設計が十分であるかの

判断を行う。

既存のアプリケーションに関するこれらのアクティビティを完了させることで、経営層

はアプリケーション統制の継続的運用および保守という点における役割と責任を果た

すための基盤を得ることができる。これについては、「第 5 章：アプリケーション統制

の運用と保守」で検討する。

アプリケーション統制の自動化の事例

多くの場合、コントロールを自動化することで、手作業によるコントロールに関連した

リスクが軽減され、効率性が向上する。たとえば、発注書、物品の受領書およびサプラ

イヤーからの請求書に対して 3-way-match コントロールを自動化することができる。こ

れまでは、検収した数量が発注した数量と合致していることと、検収した数量および契

約時の価格で、請求書が作成されていることを手作業によるコントロールで確認してい

た。この 3-way-match を自動化することで、倉庫担当者と会計担当者の大幅な時間の削

減が可能であり、発注および検収機能におけるコントロールの強化につながる。ERP

環境では、コントロールの自動化がさらに 1 段階進んでいる。物品の受領書や請求書な

どの伝票がアプリケーションに入力されると、対応する会計伝票が自動で生成され、総

勘定元帳に計上される。これらの自動化されたアプリケーション統制（3-way-match、

会計伝票の自動生成など）は、物流プロセスおよび財務情報のインテグリティに貢献す

る。


自動化されたアプリケーション統制は、内部統制における費用対効果が高く、持続性に

優れたシステムで使用可能であるが、そのためには効果的な IT 全般統制が必要である。

自動化されたアプリケーション統制は、人為的エラーや情報操作のリスクが大幅に低減

されるため、手作業によるコントロールよりも信頼性が高いのが一般的である。自動化

されたコントロールにおいても適時に例外を発見し、それに対応するためのモニタリン

グが必要である。自動化されたコントロールが適切に設定され、運用されていれば、経

営層は通常は例外ケースがめったに発生しないことを確認すればよい。さらに、今日の


ように 24 時間稼働している環境で、ビジネスフロー全体が自動化されている場合は、

手作業によるコントロール活動を挿入することで処理のスループットに重大なボトル

ネックを発生させてしまう恐れがある。このように自動化されたビジネス環境の例とし

ては、小売業者が取り扱う大量の消費財、クレジットカード処理、通信業界および航空

業界などが考えられる。これらのケースでは、手作業による活動は主にマスタデータ（価

格テーブルのデータなど）に対して実施され、自動化されたコントロールによって、適

時かつ正確な処理が行われる。

スループットだけでなくプロセスのパフォーマンスに対する影響を考えても、手作業に

よる活動は非常に費用がかかる場合がある。活動の自動化（コントロール活動を含む）

により、人件費が大幅に削減できる可能性がある。手作業によるコントロールに伴う費

用は、活動の数や業務プロセスの規模および複雑性によって、飛躍的に増大する。

図 5 は、自動化されたコントロールと手作業によるコントロールを示しているが、これ

を見ると、できる限りアプリケーション統制の自動化が必要であることが分かる。

自動化されたアプリケーション統制の継続的な信頼性および有効性は、関連するアプリ

ケーション統制や IT 全般統制の有効性に依存している。たとえば、自動化された

3-way-match コントロールの有効性判断には以下の項目が前提条件となっている。

・アプリケーションシステムにおいてその機能を有効化するパラメータの変更は権限

を付与されたユーザに限定されている。（通常は「DS5 システムセキュリティの保

証」によって管理される IT 全般統制）

・発注書、物品の受領書およびサプライヤーからの請求書の照合における許容範囲の

変更はビジネスニーズに応じて権限を付与された業務管理者のみが行う。

・上記の変更が適切に文書化され、承認されている。

・ 3-way-match に関連するアプリケーション機能の変更について有効なコントロール

が存在している（通常は、「AI6 変更管理」によって管理される IT 全般統制）。

自動化されたアプリケーション統制と IT 全般統制との関係は、「第 6 章：アプリケー

ション統制と IT 全般統制の関係」でより詳しく検討する。


アプリケーション統制の設計および導入における役割と責任

アプリケーション統制の設計、開発、テストおよび導入は、SDLC プロセスに不可欠な

要素であり、これらのプロセスのコンポーネントとして導入されるべきである。

以下のセクションには、これまでのセクションで検討されたアクティビティに基づき、

図 6 には「実行責任者（Responsible）、説明責任者（Accountable）、協議先（Consulted）

および報告先（Informed）」の役割を記載している。（RACI チャート）

経営管理部門は以下の項目に責任を負う。

・リスクアセスメントの実施

・アプリケーション統制要件の正確な定義と承認

・ SDLC 全体を通じて関与し、コントロール要件が確実に満たされ、アプリケーショ

ン統制のテストが適切に実施されていることの検証

・アプリケーションシステムがアプリケーション統制の機能を含めて、要件に則した

ものであることの確認

・アプリケーションシステムの利用において、ユーザが自動化および手作業によるア

プリケーション統制活動を含めた十分なトレーニングを受けていることの検証

・自動化されたシステムの利用およびコントロールの運用状況の有効性のモニタリン

グ（「第 5 章：アプリケーション統制の運用と保守」に追加のガイダンスが掲載さ

れている）

・アプリケーション統制を含む業務プロセスの文書の保持

IT 部門は以下の項目に責任を負う。

・アプリケーション統制を適化するために業務部門のユーザへの協力。効率性を高

図 5 ―アプリケーション統制の自動化の事例

運用費用

手作業によるコントロール

自動化されたコントロール

プロセスの規模と複雑性


めるため、アプリケーション統制の自動化やコントロール活動を IT 全般統制の一部

として実行することへのアドバイスの提供。（たとえば、ユーザセキュリティのプ

ロビジョニングや管理の設計および構築は、それぞれ固有のアプリケーションソリ

ューション内で行うよりも IT 全般統制に組み込む方がより効率的かつ効果的だと

考えられる）

・業務部門のユーザが定義した通りのビジネス機能および自動化されたアプリケーシ

ョン統制の設計、構築、導入

・情報システムおよび情報処理のインテグリティを維持するための IT 管理プロセス

およびコントロールの導入

・ビジネス要件に従って情報処理の可用性と適時性を維持するための IT 管理プロセ

スおよびコントロールの作成

・ビジネス要件に従って情報システムやデータの機密性を維持、保護するための IT 管

理プロセスおよびコントロールの作成

・効果的かつ信頼性の高いアプリケーションシステムの基盤となるインフラストラク

チャーを運用するための IT 管理プロセスおよびコントロールの作成


アプリケーション統制の設計および導入に関する責任は経営管理部門と IT 部門によっ

て分担されている。経営管理部門は、ビジネス目標を達成するようにアプリケーション

統制の要件を適切に設計および導入することに説明責任を負う。IT 部門は、ビジネス

要件に従ってアプリケーション統制を開発することに説明責任を負う。

図 6 は、これまで検討したように、リスクアセスメント、コントロールの識別、アプリ

ケーション統制の設計および導入に関連する主要なアクティビティの役割と責任をま

とめた表である。

アプリケーション統制の設計と導入に関連するリスクの管理

アプリケーション統制の設計および開発時には多くの潜在的リスクが発生する恐れが

ある。これらのリスクの一部を以下に挙げる。

・不完全あるいは不適切に設計されたアプリケーション統制 ―経営層がアプリケー

ション統制を IT 関連の領域として捉え、アプリケーション統制の設計および導入は

IT 部門のみの責任であるという誤った考えを持つ可能性がある。また、IT 部門は業

務側の関与やサポートがなければ、業務プロセスを完全に理解できなかったり、業

務部門が IT に期待する目的を誤解したりする可能性がある。結果的に、アプリケー

ション統制によって対処すべきビジネス要件が完全に組み込まれず、対応されない

可能性がある。このような場合、アプリケーション統制を導入しても、ビジネス要


件や該当するコントロール目標が完全には満たされない。

・非効率に設計されたコントロール―アプリケーション統制活動の自動化が適切に

検討されないため、費用のかかる手作業による手続で補完したり、導入後にコント

ロールの自動化をしたりするために改善が必要となる可能性がある。

リスクを低減し、アプリケーション統制の効果的かつ効率的な設計、導入および運用を

確実にするには、共通のリスクおよびコントロールのフレームワークを採用する必要が

ある。このフレームワークには、定められたプロセスおよび手続、ならびに経営管理部

門、ユーザおよびその他のステークホルダーの役割と責任を明確に定義する必要がある。

この役割と責任については、図 6 の RACI チャートで示している。フレームワークとし

て COBIT を採用し、プロセスと説明責任を定めることで、「共通言語」の使用が可能

となり、誤解や解釈の誤りというリスクを低減するのに役立つ。

社内外の監査やコンプライアンスチームといった内部統制の専門家（SME：Subject

Matter Expert）による積極的な関与や支援も、アプリケーション統制関連のリスク管理

および低減にとっては重要である。これらのステークホルダーが、設計および導入プロ

セスの全体にわたって関与し、適時に助言をする必要がある。たとえば、SME は要件

定義の段階では、経営層が明確にしたコントロール目標/要件の網羅性に関して見解を

述べる。設計段階では、アプリケーション統制をレビューし、設計の適切性に関するフ

ィードバックを提供する。テスト段階では、ユーザの参加があるかどうかテスト計画を

レビューし、テスト結果に関して利用者の承認が得られるようにセキュリティテストと

ユーザ受入テスト（UAT）の状況を確認する。

「付録 F ―アプリケーション統制に関連する共通の問題と課題」には、各種アプリケー

ションに関するアプリケーション統制の設計および導入に伴う共通のリスクと課題、な

らびにそれらのリスクや課題を軽減するための関連するコントロールプラクティス案

についての追加のガイダンスが掲載されている。


図 6 ―アプリケーション統制の設計および導入に関する役割と責任：RACI チャート

アクティビティ

ステークホルダー

業務執行役員

業務処理オーナ/

アプリケ

ーションオーナ

ビジネスアナリスト

エンドユーザ

プロジェクトマネージャー

プログラマ/IT

スペシャリスト/IT

アプリケーションオーナ

リスクおよびコントロール（また

はセキュリティ）専門家

社内外の監査人

関連するコントロール

目標の設定

主要なステークホルダーの特定およびアプリケ

ーション統制に関する役割および責任の割当 A R C C C C I

情報および情報処理に関連するリスクアセスメ

ントの実施 C A R C I R C

コントロール目標の設定と文書化 C A R C C サードパーティーソフトウェアの場合は、RFP へ

のコントロール要件の組み込み C A R C

アプリケーション統制の設計/

構築/

設定

アプリケーション仕様の詳細設計（自動化され

たアプリケーション統制を含む） C A R C C C

ベンダーソリューションの評価（コントロール要

件の適合を含む） A R C C

将来の業務プロセス設計（コントロール目標を

達成するための手作業によるアプリケーション

統制の設計を含む） A R C C

アプリケーション統制設計の十分性アセスメント

と判断 A R C C R C C C

ソフトウェア開発の一環としてのプログラムコー

ドの開発と自動化されたアプリケーション統制

のデバッグ C C C A/R R C

アプリケーションのインストールと設定コントロ

ールの設定（コンフィギュレーション） C R C A/R R C I

コントロールの文書化と

ユーザトレーニング

アプリケーション統制の文書の作成/更新 A R C R C C C

ユーザトレーニングの資料作成/更新、ならびに

必要に応じて、対象スタッフへのトレーニングの

実施 A R R R C C I

新規に採用した従業員の場合、アプリケーショ

ンと関連するアプリケーション統制に関するフル

トレーニングの実施 A R

アプリケーション統制の

テストと承認

テスト計画の作成、文書化および承認 A R C R R I I テスト計画に従ったアプリケーション統制のテス

ト R C C A/R R R C

テスト中に発見されたたエラーや問題を明確

化、記録、優先順位付け、および解決 R C C A R R I

未解決の問題を含めた終のテスト結果の文

書化と説明 A R C R R C

テスト結果の承認 A R C C R C C I アプリケーション統制の設計および導入の承認 A R C C R C C I

RACI チャートでは、実行責任者（Responsible）、説明責任者（Accountable）、協議先（Consulted）、報告先

（Informed）が識別されている。


アプリケーション統制の設計および導入の達成目標と測定指標

図 7 では、重要成果達成指標/測定指標について記載している。これらは、アプリケー

ション統制の設計および導入に関連するプロセス活動および成果の測定に役立つと考

えられる。この表では、COBIT における IT／プロセスの達成目標との関連を示してい

る

図 7 ―アプリケーション統制の設計および導入のパフォーマンス測定指標

アプリケーション統制の測定指標該当する COBIT 4.1 IT/プロセスの達成目標


アプリケーション統制の設計および導入に関する

役割と責任が定義され文書化されているプロジェ

クトの割合

PO10 重要な工程ごとのプロジェクト管理に

関するタイムリーな意思決定

アプリケーション統制の要件/目標が文書化され、

ビジネスプロセスオーナによって承認されている

プロジェクトの割合

PO10 重要な工程ごとのプロジェクト管理に

関するタイムリーな意思決定

調達するソフトウウェアアプリケーションの場合、

提案依頼書（RFP）にアプリケーション統制の要件

が含まれているプロジェクトの割合

AI1, DS5

セキュリティおよびコントロール要件の

早期検討

アプリケーション統制の設計仕様が文書化されて

おり、設計の有効性に対してビジネスプロセスオ

ーナの決定が文書化され、承認されているアプリ

ケーションの割合

AI1 ビジネスの機能的要件およびコントロ

ール要件を効果的かつ効率的なシス

テムソリューションによって実現する

方法の定義タイプ別（手作業、自動化、ハイブリッド、コンフィ

ギュレーション）および性質別（予防的、発見的）ア

プリケーション統制の比率

AI7 ビジネスの機能的要件およびコントロ

ール要件を効果的かつ効率的なシス

テムソリューションによって実現する

方法の定義社内外の監査人によって確認されたアプリケーシ

ョン統制の設計における不備の件数 AI7 ソリューションの提供における不備と

手戻りの必要性の削減アプリケーション統制のテスト計画およびテスト結

果が文書化されているアプリケーションの割合 AI7 新規ビジネスアプリケーション、および

既存アプリケーションへの変更におけ

るエラーの確実な排除アプリケーションのテストで発見、解消された不備

や問題、ならびに未解決の不備や問題の件数 AI7 新規ビジネスアプリケーション、および

既存アプリケーションへの変更におけ

るエラーの確実な排除適切な設計仕様および受入基準のあるアプリケ

ーション統制の割合 AI7 ソリューションの提供における不備と

手戻りの必要性の削減アプリケーション統制に関するトピックがユーザト

レーニングのカリキュラムに組み込まれているプ

ロジェクトの割合

AI4 アプリケーションに関する効果的な利

用者マニュアルおよび研修資料を提

供先行承認を促進するために開発された回避策の

数 AI7 ソリューションの提供における不備と

手戻りの必要性の削減業務執行役員/ビジネスプロセスオーナの承認に

よって導入されたアプリケーションの割合 AI7 アプリケーションに関する本来の目的

への適合性の検証と確認


5. アプリケーション統制の運用と保守

本章では、コンピュータ化対応策のライフサイクルの次のステージ（事業経営の一環と

してのコンピュータ化対応策の運用、利用および保守）におけるアプリケーション統制

について記載している。


経営層は内部統制を実施し、効果的に運用することに対して、広範囲にわたって実行責

任と説明責任を有している。企業の特定の機能やプロセスを外部に委託している場合で

も、経営層はこれらの機能やプロセスの内部統制の有効性に対して説明責任を負う。た

とえば、COSO では、内部統制を全社的リスクマネジメント（ERM）に不可欠な部分と

して捉え、終的な責任を高経営責任者（CEO）に置いているが、他の責任者が責任

範囲内で業務の実施、サポートの提供、コンプライアンスの推進およびリスク管理に対

して責任を負うこともある 11。アプリケーション統制の継続的運用については、主に以

下の 3 タイプで構成されている。

・コンピュータ化対応策の実施 ― これは一般的に、IT 部門が責任を負う。COBIT 4.1

のサービス提供とサポート（DS）ドメインにおける複数のプロセスで取り上げられ

ているが、その中心となるのが「DS13 オペレーション管理」である。

・アプリケーション統制の有効性のモニタリング ― ビジネスプロセスオーナは一

般的に、該当する手作業によるコントロール活動の実施、自動化されたアプリケー

ション統制のモニタリング、有効性を保証するために必要な対応などを含め、業務

プロセスの効果的な運用に対して説明責任を負っている。経営管理部門は、アプリ

ケーション統制が効果的に運用されているかモニタリングする必要がある。これに

ついては COBIT 4.1 のモニタリングと評価（ME）ドメインの、「ME2 内部統制の

モニタリングと評価」の中で主に取り上げられている。経営層は、アプリケーショ

ン統制の有効性モニタリングの支援ツールを使用して、継続的な統制モニタリング

（本章で後述する）を実施することも考えられる。

・アプリケーション統制に対する変更管理 ―一般的にビジネスプロセスオーナの責

任で、業務プロセスおよび手作業によるアプリケーション統制が変更される。自動

化されたアプリケーション統制に対する変更については、経営管理部門（変更要件

の定義、変更要件に対するテストと承認）と IT 部門（変更依頼に基づく開発と導

11 トレッドウェイ委員会支援組織委員会、『Enterprise Risk Management—Integrated Framework, Executive

Summary（全社的リスクマネジメント――フレームワーク篇）、米国、2004 年、p. 6


入）で責任を分担しており、COBIT 4.1 では「AI6 変更管理」と「AI7 ソリューショ

ンおよびその変更の導入と認定」で取り上げられている。

「付録 A ― COBIT 4.1 のプロセスおよびコントロール目標に対するアプリケーション

統制活動のマッピング」には、アプリケーション統制の運用および保守の詳細なマッピ

ング、ならびに COBIT 4.1 の調達と導入（AI）活動との統合が記載されている。

コンピュータ化対応策の実施

自動化されたアプリケーション統制やアプリケーションに依存した手作業による活動

の継続的有効性を保証するためには、コンピュータ化対応策の効果的かつ信頼性の高い

運用が不可欠である。効果的かつ信頼性の高い運用が実施されなければ、自動化された

コントロールのインテグリティと信頼性およびその元となるデータに問題が生じる。

通常、コンピュータ化対応策の効果的かつ信頼性の高い運用に対する実行責任と説明責

任は、高情報責任者（CIO）と IT 部門にある。コンピュータ化対応策の効果的な運

用に関連するガイダンス、目標、測定規準および測定指標は、COBIT 4.1 （主に「DS13

オペレーション管理」）に記載されている。DS13 のコントロール目標には、データ処

理手続の有効な管理およびハードウェアの入念な保守に基づく、コンピュータ化対応策

の完全かつ正確な処理に関連するガイダンスが示されている。

アプリケーション統制の有効性モニタリング

アプリケーション統制活動は、業務プロセスの一部であるため、経営層による全社的な

業務プロセスのモニタリング活動に組み込む必要がある。経営層は業務プロセスの正確

性と信頼性を確実なものにするため、手作業によるコントロールと自動化されたコント

ロール、およびこれらの両方が統合されたコントロールの運用に対して、モニタリング

する必要がある。


アプリケーション統制の継続した有効性を保証するためには、その継続的なモニタリン

グが重要である。

経営層は以下の要素について検討をする必要がある。

・アプリケーション統制の有効性に関する定期的なアセスメント

・手作業によるコントロールを含むハイブリッドコントロールと手作業によるコン

トロールの運用の有効性に対するモニタリング

・自動化されたコントロール活動（自動化されたコントロールを含むハイブリッドコ

ントロール）が想定通りに継続して運用されているかどうかのモニタリング


・第三者に委託し、実施しているアプリケーション統制の運用の有効性に対するモニ

タリング

・業務プロセスおよびアプリケーション統制におけるコントロールが有効でないこ

とを示す重要成果達成指標（KPI）のモニタリング

経営層は、手作業による正確かつ効率的な手続の実施、自動化されたコントロールによ

る出力に対してのモニタリング、およびシステムが生成する例外レポートに対する対応

のレビューを実施する必要がある。現在のように複雑なシステム環境下では、経営管理

部門のユーザは「システムの動作」を信用し、システムやコントロールの不備を示す主

要リスク指標（KRI）を見落としてしまう危険性がある。経営層はコントロール活動を

運用するだけでなく、発生したコントロールの不備に対して適切に対処し、対応するた

めのプロセスを開発することも重要である。場合によっては、その効率性と有効性を

大化するために、一部のアプリケーション統制が業務プロセスの外部の部門や企業によ

って実施される場合がある。その例を以下に挙げる。

・ IT 全般統制の一環として実施されるバッチ処理およびアプリケーションシステム

間のデータ転送に関するコントロール

・サードパーティのサービス企業によって実施されるアプリケーション統制活動

上記の状況において、コントロールの実施責任を委託する可能性があるが、経営管理部

門はその運用の有効性に対して説明責任を負っている。経営管理部門は、このようなコ

ントロール活動を可視化し、その継続的有効性のモニタリングができるようなプロセス

を開発する必要がある。これには以下のようなアクティビティが含まれる。

・主要な手作業によるコントロール活動の実施を管理、監督。

・ビジネスニーズやリスクの分析、規制、コンプライアンスの要件に基づいて、コン

トロールの不備および逸脱、処理エラーを特定し、優先順位付けを行い、エスカレ

ーションならびに解決策の管理、監督を行なう。

・サードパーティのサービスプロバイダーにおける、アプリケーション統制の継続的

な有効性をモニタリングするために、ベンダー管理のための会議を定期的に開催し

たり、内部統制の有効性に関する外部監査人の報告書のレビューを実施したりする。

・ IT 全般統制レベルで発生する可能性があるアプリケーション統制に関連するイン

シデントおよび問題管理レポートのモニタリング。

・「第 4 章：アプリケーション統制の設計と導入」に記載されているプロセスおよび

コントロール設計の一環で定められたプロセス指標と重要成果達成指標のモニタリ

ング。

・内部のセルフアセスメント、内部監査レビューや外部またはサードパーティレビュ

ーなどのアプローチを用いた、コントロールの有効性に対する定期的なアセスメン


ト。

・コントロールのアセスメントおよびレポートで報告された問題に対して、問題の特

定、トラッキング、改善策の実施。

継続的コントロールモニタリング（CCM）

自動化された業務プロセスは手作業による処理よりも本質的に信頼性が高いと考えら

れるが、経営層は自動化されたアプリケーション統制が完全であると過信すべきではな

い。自動化されたコントロールを含む内部統制では、エラーが発見されないリスクを排

除することができない。自動化されたコントロールが IT 全般統制に依存しているよう

に、多くの内部統制は他の活動に依存している。取引が誤って処理されたり、自動化さ

れたアプリケーション統制によって発見されなかったりするリスクが常に存在する。こ

れらのシステム的なエラーが重大な虚偽表示につながり、データのインテグリティに影

響を及ぼす恐れがある。

内部監査協会（IIA）研究財団では、課題を以下のようにまとめている。

システムに組み込まれているコントロールが想定通りに機能していないことを識

別し、評価活動やモニタリングの実施につなげるような効果的な情報システム、コ

ミュニケーションとモニタリングのシステムの開発が課題である。12


継続的コントロールモニタリング（CCM）は、経営層が内部統制活動の継続的有効性

をモニタリングするための効果的な仕組みである。

継続的コントロールモニタリングは、経営層がキーコントロール活動に対して有効なモ

ニタリングを実施するためのコンセプトである。継続的コントロールモニタリングは以

下のようにまとめることができる。

予防、発見と内部統制の運用の有効性のモニタリングを行うために定義されたビジ

ネスルールとモニタリングソフトウェアを組み合わせて利用する。13

12 内部監査人協会（IIA）研究財団、Sarbanes-Oxley Section 404 Work, Looking at the Benefits、米国、2005

年

13 ISACA ヒューストン支部、 Continuous Control Monitoring Presentation 、米国、 2006 年、

http://isacahouston.org/documents/ISACACCMPresentation_000.pdf


継続的コントロールモニタリングを支援するツールおよび手法は、飛躍的に進歩してい

る。これらのツールは、設定コントロールにおける変更点の発見、データの分析、ビジ

ネスルールやポリシーまたはその他の規準を満たさない例外トランザクションを発見

し、コントロールが有効でないことを知らせる。新のツールは、データ分析に重きを

おくため、特定の ERP アプリケーションシステムの上でも動くが、アプリケーション

に依頼しないようにもなっている。近のこの種のツールの多くは、監査人が使用する

データ分析ツールから経営管理部門が使用するツールへ進展してきたものである。

継続的コントロールモニタリング ― 例

大手のアプリケーションベンダーでは、CCM の機能がその ERP システムの標準的なコ

ンポーネントに組み込まれているケースが増えている。たとえば、ガバナンス、リスク

およびコンプライアンス（GRC）ソリューションは、コーポレートガバナンス、リスク

マネジメント、コンプライアンスマネジメントやレポーティングや GRC プロセス全体

を自動化するために設計されている。自動化されたアプリケーション統制をモニタリン

グする GRC ソリューションには以下のようなものがある。

・ GRC アクセスコントロール ―企業全体の IT システムにおけるアクセスや権限に

対するリスクを識別、予防することで、不正を防止し、コンプライアンスやコント

ロールの維持にかかるコストを削減する。

・ GRC プロセスコントロール ―事業経営を適化し、コンプライアンスを遵守する

ために、業務プロセスや企業全体の IT システムのキーコントロールを集中的にモ

ニタリングする。

GRC プロセスコントロールモジュールでは、3-way-match などの自動化されたコントロ

ールやそれに関連する許容範囲設定のモニタリングが可能である。GRC アクセスコン

トロール機能では、3-way-match の許容範囲設定などの設定可能なパラメータ変更に対

するユーザクセスをモニタリングすることができる。

運用の効率性の証拠の保持

企業はキーコントロールが有効に機能していることを示す証拠を保持することおよび

財務報告に重大な影響を与えかねないコントロールの不備を含む事象適時な開示を求

められる場合もある。14キーコントロールの運用の有効性を証明するための証拠を必要

としない場合でも、コントロール活動の継続的な有効性をモニタリングすることは、企

業がその全社的なビジネス目標を確実に達成するための経営管理手法である。

14 サーベンスオクスリー法あるいは類似法規への準拠が求められる企業など


「第 7 章：アプリケーション統制の保証」には、主要なコントロールの運用の有効性を

裏付ける証跡の保持に関して、経営層の責任について追加情報を記載している。

アプリケーション統制に対する変更管理

変化するビジネスおよび市場の状況に企業が対応するためには、ビジネスの変更は避け

られない。これらのビジネスや市場の変化に対応するため、業務プロセスやそのプロセ

スを支えるアプリケーションに対して何らかの変更が必要となる可能性がある。また、

プロセスのスループット時間の削減、プロセス効率の改善、コストの削減や内部統制の

強化/改善といった継続的な改善活動を実施するうえで、変更が必要となる可能性もあ

る。経営層が変化するビジネス要件に対応するため、業務プロセスやアプリケーション

を変更する際には、これらの変更に伴う既存のアプリケーション統制への影響を慎重に

評価すべきである。それに伴い、コントロールの強化や適化を考慮し、プロセス全体

の有効性および効率性が改善されるようにコントロールを調整する必要がある。業務プ

ロセスの変更に伴い、コントロールの更新や調整が実施されない場合はコントロールの

欠陥となる可能性がある。

アプリケーション統制に対する変更は、業務プロセスやそのプロセスを支える業務アプ

リケーションの変更管理と同様に、標準プロセスに基づき管理する必要がある。アプリ

ケーション統制を含むこれらの変更管理の実行責任と説明責任は、共有される必要があ

る。経営層は、変更要件の明確化や定義および業務プロセス変更に伴う設計および導入

に対して責任を負う。IT 部門は一般的に、コンピュータ化対応策の変更に対する設計、

構築、導入に責任を負う。

主要なアクティビティとして以下のものが挙げられる。

・業務プロセスおよびそれを支えるコンピュータ化対応策に対する変更ニーズの明確

化、およびビジネス要件の定義

・アプリケーション統制の変更に伴う影響分析、変更が必要となるコントロール要件

の定義

・定義、合意されたビジネス要件に基づいて、自動化されたアプリケーション統制を

含むコンピュータ化対応策の再設計、構築、テスト、導入

・定義されたビジネス要件やコンピュータ化対応策の変更に対して発生する手作業に

よるアプリケーション統制手続を含めた業務プロセスの再設計、構築、および導入

・ビジネス情報テーブル、マスタデータ、「ユーザ部門が管理する」設定テーブル（コ

ンフィギュレーションテーブル）に対する変更の管理

・ビジネスルールや「IT 部門が管理する」テーブルに対する変更の管理（COBIT コン

トロール目標 AI2.5 も参照のこと）


ビジネス要件に基づく、コンピュータ化対応策の変更に対する設計および導入の責任に

ついては、「第 4 章：アプリケーション統制の設計と導入」で記載されている要件に従

う。効果的な変更管理および導入に関連するガイダンス、目標、測定規準、測定指標は、

COBIT 4.1 のコントロールプロセス AI6 および AI7 に記載されている。

・「AI6 変更管理」では、IT 部門がソリューションやサービス提供における問題や手

戻りの削減を行い、ビジネス戦略に則してビジネス要件を満たす方法を記載してい

る。

・「AI7 ソリューションおよびその変更の導入と認定」では、IT 部門が重大な問題を

発生させずに新規システムやシステム変更を導入するというビジネス要件を満たす

方法を記載している。

アプリケーション統制がビジネス要件や関連するアプリケーション統制の目標を継続

かつ確実に達成するためには、これらの COBIT 4.1 プロセスの目標を達成する必要があ

る。

自動化されたアプリケーション統制の設定可能なパラメータの管理

第 4 章では設定コントロールはアプリケーションシステム内のパラメータ設定に依存

する自動化されたアプリケーション統制として識別されている。一般的な例として、ビ

ジネス情報テーブル、承認リミットや為替レートテーブルなどのマスタデータ、購買・

在庫アプリケーションにおける 3-way-match と 2-way-mach のどちらを採用するかを決

定するパラメータなどが考えられる。

有効かつ信頼性が高い設定コントロールの運用は、その基盤となるパラメータのインテ

グリティや正確性に依存している。パラメータテーブルのエラーは、関連する情報およ

び情報処理の正確性や信頼性に直接的な影響を及ぼす。たとえば、割引タイプにエラー

があれば、得意先への請求書の金額の正確性に直接的な影響が及ぶ。これらの設定テー

ブル（コンフィギュレーションテーブル）のインテグリティや正確性は、第 4 章に記載

されているように、システムのテストおよび導入プロセスの一環として取り上げられる

のが一般的である。しかし、導入後に必要となる設定テーブルに対する変更を管理する

ため、十分かつ適切なコントロールを整備することも重要である。

設定テーブル（コンフィギュレーションテーブル）に対する変更管理を行うための一般

的な手法は以下の通りである。

・設定テーブルの変更に関連するシステム機能へのアクセスを承認された人に限定す

る。

・設定テーブルを変更する職務とそれに関連するトランザクションを処理する職務を


分離する。以下に例をいくつか挙げる。

- 業務処理ルール（支払処理前に 3-way-match を必須とするように購買／在庫シス

テムを設定）に影響を与えるテーブルへの変更に関する職務を業務部門のスタ

ッフが持つのではなく、IT 部門（アプリケーションサポートグループなど）の

職務とする。これらの変更は、変更管理プロセスと承認に従って行う必要があ

る。

- 従業員の給与、支払レートや所得税テーブルへの変更管理の職務を、給与支払

部門ではなく、人事部門の職務とする。

・経営層によるリスクアセスメントに基づき、設定テーブルにおける特定のクラスの

パラメータ変更を正式な変更管理プロセスの対象とする ― これは、定義されたビ

ジネスルールを反映するテーブルや、アプリケーションシステムそのものの動作を

変えてしまうテーブル、および、頻繁に変更されることがないテーブルについては

特に有効である。経営層は、ビジネス要件の変更や新規ビジネス要件に必要な修正

ならびに、これらの変更に伴うテストや承認を、変更管理プロセスを通じて実施す

ることができる。COBIT 4.1 のコントロール目標 AI2.5 では、このようなアプリケ

ーションの設定変更を管理するための追加ガイダンスが提供されている。

・経営層はパラメータテーブルの変更を承認する。

・経営層はシステムが生成した変更活動レポートをレビューする。

・システムが生成したパラメータテーブルに対する変更ログを保持する。

アプリケーション統制の運用および保守における役割と責任

アプリケーション統制の運用および保守の管理に関連する主要なアクティビティの役

割と責任は、図 8 に掲載されている。


アプリケーション統制の運用および保守の実行責任と説明責任は、経営管理部門と IT

部門との間で分担されている。経営管理部門は、アプリケーション統制の継続的有効性

のモニタリング、およびアプリケーション統制の変更に対する要件の明確化と定義に対

して説明責任を負う。IT 部門は、アプリケーションとそれに関連する自動化されたア

プリケーション統制の運用に必要な信頼性の高い環境の提供やユーザの要求に基づく

変更のための開発/提供に対して説明責任を負う。

アプリケーション統制の運用と保守に関連するリスクの管理

アプリケーション統制の運用および保守に関連するキーリスクには以下のようなもの

がある。

・ハイブリッドや設定コントロールなど自動化されたアプリケーション統制に関連す


る手作業による活動（システムが生成したログのレビューやフォローアップなど）

を適時に実行しない。手作業による活動の重要性を担当者が完全に理解していない

ため、コントロール活動全体の有効性が脅かされるというリスクがある。

・自動化されたアプリケーション統制に満足し、自動化されたアプリケーション統制

が継続して有効に運用されるということを過剰に「信頼」している。他の内部統制

と同様に、自動化されたアプリケーション統制にも誤りはあり、固有のリスクがあ

る。

・変更によってアプリケーション統制に対して想定外の影響を与える。システムまた

は業務プロセスへの変更によって、アプリケーション統制活動の継続的な有効性を

損なう恐れがあり、想定外や予期せぬ結果が生じる可能性がある。

経営層は、リスクを低減し、アプリケーション統制の有効かつ効率的な運用と保守を確

実に行うために、潜在的なコントロールの不備に関連するリスクや影響に応じて、日常

の運用活動に対する適切な監督や管理の必要がある。また、コントロールの有効性を継

続するためにハイレベルなモニタリングを導入する必要がある。

アプリケーション統制の運用と保守に対するリスク管理やそのリスク低減をしていく

上では、社内外の監査やコンプライアンスチームといった内部統制専門家の関与や支援

が重要な要素である。これらのステークホルダーは、コントロール活動の運用の有効性

に関して、定期的に客観的な立場でアセスメントに関与していく必要がある。

「付録 F ― アプリケーション統制に関連する共通の問題と課題」には、各種アプリケ

ーションのコントロールの運用および保守、ならびにそれらのリスクや課題を軽減する

ための該当するコントロールプラクティス案についての追加のガイダンスが掲載され

ている。


図 8 ― アプリケーション統制の運用および保守に関する役割と責任：RACI チャート

活動

ステークホルダー

業務執行役員

業務処理オーナ

ビジネスアナリスト

エンドユーザ

プロジェクトマネージャー

システムオペレーター

プログラマ/


サポート

リスクおよびコントロール（ま

たはセキュリティ）専門家

社内外の監査人

コンピュータ

化対応策の

運用

コンピュータ化対応策の有効かつ信頼性

の高い運用の実現（COBIT 4.1 コントロ

ール目標 DS13 も参照のこと） I C/I I R/A C/I

アプリケーション統制の有効性

モニタリング

手作業によるキーコントロール実施につ

いての管理 A/R R C

コントロールの例外、逸脱、処理エラー

の明確化、優先順位付け、エスカレーシ

ョンや解決についての管理 I A/R R C

サードパーティのサービスプロバイダー

におけるアプリケーション統制の継続的

有効性のモニタリング

プロセス測定指標と重要成果達成目標

のモニタリング I A/R R C

コントロールの有効性について定期的ア

セスメントの実施 I A/R R C


業務プロセスとコンピュータ化対応策に

おける必要な変更の明確化およびビジ

ネス要件の定義 C A/R R C I I

アプリケーション統制変更による影響の

アセスメントと必要なコントロール要件と

変更の定義 A/R R R I C C C

定義されたビジネス要件に基づく、自動

化されたアプリケーション統制などのコン

ピュータ化対応策の変更に伴う設計、構

築、テストおよび導入

COBIT 4.1 プロセス AI6 およびを AI7 参照のこと

定義されたビジネス要件に基づき、手作

業によるアプリケーション統制手続など

の業務プロセスの変更に伴う設計、構

築、および導入

C A/R R R R C C

ビジネス情報テーブル、継続データおよ

び「ユーザ管理」テーブルに対する変更

の管理 A/R R C

ビジネスルールおよびその他の「IT 管

理」構成テーブルに対する変更の管理

（COBIT コントロール目標 AI2.5 も参照

のこと）

C A R C

RACI チャートでは、実行責任者（Responsible）、説明責任者（Accountable）、相談相手（Consulted）、報告先

（Informed）が識別されている。


アプリケーション統制の運用と保守における達成目標と測定指標

図 9 では、重要成果達成目標/測定指標を示しており、これらは、アプリケーション統

制の運用と保守に関わる主要な活動に関連するプロセス活動や成果の測定に役立つと

考えられる。この表では、COBIT に記載されている IT プロセスの達成目標との関連を

示している。アプリケーション統制の変更管理に関連する主要なアクティビティの測定

指標については、図 7 を参照する。

図 9 ― アプリケーション統制の運用および保守のパフォーマンス測定指標

アプリケーション統制の測定指標該当する COBIT 4.1 IT/プロセスの達成目標


アプリケーション統制のインシデント/アプリケーシ

ョン統制の実行が閾値を逸脱する事例や不備の

件数

AI7 アプリケーションの適切な利用と成果

達成の確保

発見されたアプリケーション統制のインシデント解

決に要する平均時間 DS8 アプリケーションの適切な利用と成果

達成の確保アプリケーション統制に影響を及ぼすため、導入

後にシステム変更や実装を実施した件数 AI7 アプリケーションの適切な利用と成果

達成の確保アプリケーション統制のシステム変更や実装に要

した平均時間 AI6 IT サービスの中断または変更が及ぼ

すビジネスへの影響の極小化を保証アプリケーション統制の終レビューから経過した

日数/月数 ME2 内部統制目標の達成度のモニタリン

グサービスプロバイダーによって発見されたアプリケ

ーション統制の不備の件数 AI7 アプリケーションの適切な利用と成果

達成の確保社内外の監査人によって発見された自動化された

アプリケーション統制の運用が有効でない件数 AI7 アプリケーションの適切な利用と成果

達成の確保発見されたアプリケーション統制の不備を解決に

要した平均時間 DS10 提供サービスに対するエンドユーザの

満足の確保

アプリケーション統制の継続的な改善を目的とした成熟度モデルの利用

成熟度モデルは、アプリケーション統制に関する機能の継続的な改善に活用できる仕組

みとして、経営層の一般的なツールとなりつつある。成熟度モデルのアプローチは、プ

ロセスに関連する特性を使用して、そのプロセスにおける相対的な特性や成熟度を測定

するものである。このアプローチは、能力成熟度モデル（CMM）のオリジナルコンセ

プトに基づいている。これは、政府が委託したソフトウェアプロジェクトを実行する委

託業者のプロセス能力を客観的に評価するためのツールとして開発されたものである。

また、ソフトウェア開発分野から発展したものであるが、さまざまな分野で、企業のプ

ロセス能力の成熟度の把握を目的として、一般的に受け入れられている。15

15 カーネギーメロン大学ソフトウェア工学研究所、The Capability Maturity Model: Guidelines for Improving

the Software Process (CMM および SW-CMM としても知られている。このタイトルは 2003 年に CMMI®:

Guidelines for Process Integration and Product Improvement に改称）、Addison-Wesley Professional、米国、1995

年



アプリケーション統制の設計、導入、運用および保守プロセスの成熟度の定期的なアセ

スメントの実施は、継続的な信頼性のモニタリングや改善の機会を明確にするために有

効である。

能力成熟度モデルは一般的に、プロセス成熟度の相対的なアセスメントに利用されてお

り、プロセス能力やコントロールがビジネス要件に則したものであることを検証するた

めの有効なベンチマーキングツールである。能力成熟度モデルのアセスメントは、対象

となる業務プロセスと「ベストプラクティス」を比較することで行われる。アプリケー

ション統制活動の成熟度は、プロセス全体の成熟度の一部であり、図 10 に定められて

いる属性について検討が行われる。

図 10 ― 内部統制の成熟度

成熟度レベル成熟度の属性

0 不在アプリケーション統制を含む内部統制が、プロセスおよびそれを支えるアプリ

ケーション設計の一部として考えられておらず、文書化もされていない。また、

オーナシップや責任も明確ではない。

1 初期/その場対応一般的にビジネスプロセスオーナやユーザがプロセスやアプリケーションの設

計、開発および導入に関与している。コントロールの設計と運用の責任は不明

瞭で一貫性がなく、あまり理解されていない。何か問題が生じた場合に、その

問題解決に重点が置かれている可能性がある。個人がそれぞれのアクティビ

ティの達成度および適切性を判断している。

2 再現性はあるが直観的アプリケーション統制を含む内部統制が検討され文書化されている。しかし、

同じタスクであっても実行する人によってその実行にはばらつきがある。コント

ロール手続の実施責任について周知されている。コントロールの重要性は、主

に処理の問題の発見とその修正に置かれている。

3 定められたプロセスがあるアプリケーション統制を含む内部統制が文書化されており、実施者が異なる場

合やアプリケーションをまたいだビジネスニーズに対しても適切なものとなって

いる。ただし、コントロールの例外が存在し、その場合に手順が一貫していな

い場合がある。コントロール実施に関する実行責任と説明責任が文書化され、

業務プロセスをまたいで周知されている。

4 管理され、測定可能であるアプリケーション統制を含む内部統制が文書化されており、ビジネスニーズに

対して適切であるほか、全社的に一貫したコントロールのフレームワークに基

づいたものとなっている。役割、実行責任および説明責任が定義され、周知さ

れている。コントロールが一貫して、信頼できる方法で実施されており、経営層

によるパフォーマンス測定とモニタリングが行われている。

5 適化定期的なコントロールのモニタリングおよび経営層の報告プロセスが整備され

ている。アプリケーション統制を含む内部統制が、定期的に見直され、ベストプ

ラクティスになるように更新されている。プロセス活動、パフォーマンス測定指

標、主要コントロール指標および主要リスク指標（KRI）が測定され、自動化さ

れたツールおよびソリューションを用いてモニタリングが行われている。


COBIT 4.1 では、アプリケーションシステムの調達、導入、デリバリーに関連するプロ

セスを含め、それぞれの COBIT プロセスに対する IT プロセス成熟度モデルの追加ガイ

ダンスが提供されている。（「付録 A ― COBIT 4.1 のプロセスおよびコントロール目

標に対するアプリケーション統制活動のマッピング」も参照のこと）。これらのプロセ

ス成熟度モデルは、アプリケーション統制の設計／開発および運用の実行能力を評価す

る際に役立つ。

アプリケーション統制と IT 全般統制の関係


6. アプリケーション統制と IT 全般統制の関係

アプリケーション統制とは、アプリケーションによる処理の正確性、インテグリティ、

信頼性および機密性に関連し、そのアプリケーション特有のコントロールである。IT

全般統制は、それらのアプリケーションが動作する環境の信頼性とインテグリティを担

保するためのコントロールであり、一般的にはその環境で動作するすべてのアプリケー

ションに適用される。

第 3 章では、アプリケーション統制を、特定のコンピュータ化対応策に関連する目標が

達成されるという合理的な保証を提供するために設計されたポリシー、手続および活動

であると定義している。アプリケーション統制は、経営層の意思決定のため、あるいは

ステークホルダーのために正確かつ信頼性の高い情報を提供し、アプリケーションから

生成される情報が信頼されるという事業目標をサポートする。一方、IT 全般統制は、

アプリケーション開発、保守、運用が行われるコンピュータ上の環境に関係するコント

ロールであり、その目標は、アプリケーションの適切な開発や導入、プログラムやデー

タのインテグリティ、およびシステム運用のインテグリティを担保することである。IT

全般統制により、アプリケーションのインテグリティ（テストや変更管理などのコント

ロール活動を含む）、システム運用のインテグリティ（データ管理、ジョブスケジュー

リングなど）およびアクセスコントロール（物理的および論理的セキュリティなど）を

保つことができる。詳細については、COBIT 4.1 マネジメントガイドラインを参照のこ

と。

本章では、アプリケーション統制と IT 全般統制との相違および相互関係について詳し

く考察していく。

アプリケーション統制と IT 全般統制の関係

アプリケーションシステムは、コンピュータ処理環境の中で動作し、そのコンピュータ

処理環境の信頼性に依拠している。コンピュータ処理環境の信頼性は、その環境におけ

るコントロールの有効性によって決定される。そのコントロールは、環境内で動作する

すべてのアプリケーションに対して比較的広範な影響を及ぼすものであるため、多くの

場合は IT 全般統制と見なされる。有効でない IT 全般統制は、コンピュータ処理環境の

信頼性に悪影響を与え、さらにその環境内で運用されるアプリケーション統制の信頼性

および有効性を損なわせることになる。



アプリケーション統制、特に自動化されたアプリケーション統制とハイブリットおよび

コンフィギュレーションコントロールの自動化されたコンポーネント（部分）は、アプ

リケーションが動作するコンピュータ処理環境の運用の信頼性に依拠している。この環

境における IT 全般統制の不備により、アプリケーション統制の運用の有効性が損なわ

れる恐れがある。一方、有効な IT 全般統制は、自動化されたアプリケーション統制の

信頼性を向上させることができる。

内部統制システムの設計時には、ある活動をすべてのアプリケーション共通のものとし

て IT 全般統制に組み込むか、アプリケーション特有のものとし、業務プロセスの一部

とするかを選択しなければならないことがある。議論になるところではあるが、一般的

に、セキュリティなどのコントロールは個々のアプリケーション内に組み込むよりも

「環境」レベルで管理する方がよいと言われるが、これはそうすることによってテスト

や共通のセキュリティ機能の信頼度を効率よく高めることができるからである。個別対

応では、コントロールソリューション全体として、インテグレイションの問題やギャッ

プが生じる可能性がある。したがって、このようなコントロールは、IT 全般統制の一

部である IT 管理プロセスの中に設計するのが一般的である。終的には具体的なビジ

ネス要件を指針としてこのような決定を行うことになる。業務プロセス内で実行される

活動とコンピュータ処理環境内で実行される活動との間に、網羅的に内部統制システム

が確実に存在していることに注意することが重要である。

コンピュータ処理環境の理解

コンピュータ処理環境は、コンピュータ機器（および関係するソフトウェアならびに基

盤となる部品）と業務アプリケーションシステムを運用するために必要な IT の管理お

よびガバナンスのプロセスで構成されている。COBIT 4.1 では、図 11 の通り、IT の効

果的なガバナンスおよび管理のためのプロセスの説明、コントロール目標、マネジメン

トガイドラインおよび成熟度モデルガイドラインを含むガイダンスを提供している。


図 11 ― COBIT フレームワーク

これらのプロセスの多くは、本書に示すアプリケーション統制の活動と重複している。

IT プロセスドメイン内の特定の分野は、第 4 章および第 5 章において、アプリケーシ

ョン統制の信頼性および有効性に関係するものと位置づけられている。また、「付録 A

― COBIT 4.1 のプロセスおよびコントロール目標に対するアプリケーション統制活動

のマッピング」には、これら主要分野のいくつかをまとめた表を掲載している。

IT 全般統制の影響

有効でない IT 全般統制は、コンピュータ処理環境の信頼性に影響を与え、さらにその

環境の中で運用されるアプリケーション統制の信頼性および有効性にも影響を与える

ことになる。現在のビジネス環境においては、情報処理の複雑さが、主要アプリケーシ

ョンが様々な処理環境において動作することと相まって複雑なアーキテクチャをもた

らすことがある。図 12 に示す比較的簡単な例を考察する。


この例では、アプリケーション A は複数の業務プロセスにまたがって使用されており、

アプリケーション B と C はコンピュータ処理環境 1 の中で動作している。また、アプ

リケーション D と E は業務プロセス 2 で使用されており、異なるコンピュータ処理環

境の中で動作している。（アプリケーション D は環境 2、アプリケーション E は環境 3）

それぞれのコンピュータ処理環境の有効性が、関連するアプリケーション統制の信頼性

に異なる影響を与える。

例：

・すべての環境に共通のプロセス（この例の「計画と組織」および「モニタリングと

評価」など）におけるコントロールのギャップはすべてのアプリケーションに影響

を与える可能性がある。

・特定の環境内のプロセス（この例における環境 2 の「サービス提供とサポート」プ

ロセスなど）におけるコントロールのギャップは、その環境の中で動作するアプリ

ケーション（この例ではアプリケーション D）にのみ影響する。

経営層は特定のコンピュータ処理環境やアプリケーションにおけるコントロールの脆

弱性が及ぼす影響を理解し、その脆弱性が他の環境およびアプリケーションにどのよう

な影響を与えるのかを判断するために、企業は同じような情報処理環境のマッピング手

法の検討を望むことになる。

図 12 ― コンピュータ処理環境の理解

業務プロセス 1

アプリケーション A

業務プロセス 2

アプリケー

ション B

アプリケー

ション C

アプリケー

ション D

アプリケー

ション E

コンピュータ処理環境 1 環境 2 環境 3

計画と組織

モニタリングと評価

調達と導入

サービス提供とサポート

調達と導入

サービス提供とサポートサービス提供とサポート


通常、アプリケーション統制に対しても影響が大きい IT 全般統制のプロセスは、「調

達と導入」（AI2 アプリケーションソフトウェアの調達と保守、AI6 変更管理）および

「サービス提供とサポート」（DS5 システムセキュリティの保証、DS11 データ管理、

DS13 オペレーション管理）のドメインである。

IT 全般統制の役割と責任

COBIT では、ビジネス部門と IT 部門とが共同してアプリケーション統制に責任を負う

と定義している。

ビジネス部門は以下の項目の適切な実行に責任を負う。

・機能要件およびコントロール要件の定義

・自動化されたシステムおよびサービスの利用

IT 部門は以下の項目に責任を負う。

・ビジネス機能要件およびコントロール要件の自動化と導入

・アプリケーションシステムのインテグリティを維持するコントロールの確立

図 13 は、業務管理、IT 全般統制、アプリケーション統制それぞれの境界と責任を図示

したものである。

この一体かつ一貫した責任を果たすためには、IT 部門とビジネス部門との間で以下の

分野において明確かつオープンにコミュニケーションを行うことが重要になる。

・ IT 全般統制の強みと限界 ― 信頼性が高く十分にコントロールされたコンピュー

図 13 ― 業務管理、IT 全般統制およびアプリケーション統制の境界

計画と組織

モニタリングと評価

調達と導入サービス提供

とサポート

ビジネス部門の責任 IT 部門の責任ビジネス部門の責任

業務管理業務管理 IT 全般統制

機能要件

コントロール要件

自動化されたサービス

アプリケーション統制


タ処理環境により、ビジネス部門はアプリケーション統制の自動化をさらに進め、

コストのかかる手作業を削減することができる。反対に、コントロールが不十分な

環境では、情報処理の同程度の信頼性を得るには、ビジネス部門がより多くの手作

業によるアプリケーション統制を追加しなければならない。アプリケーション統制

の設計をする際には、ビジネス部門が IT 部門と協力し、業務プロセスが使用するア

プリケーションのコンピュータ処理環境とそれぞれの IT 全般統制の相対的な強み

と限界を理解しておくことが重要である。

・処理上の問題点および IT 全般統制の不備の周知 ― IT 全般統制に問題点あるいは

不備がある場合、自動化されたアプリケーション統制の信頼性に悪影響を及ぼすだ

けでなく、業務プロセスおよびデータのインテグリティも損なわれる恐れがある。

このような状況では、業務プロセスにおける処理上の問題点や統制上の不備の影響

評価、追加調査や是正措置に権限を持ってビジネス部門が関与することが重要であ

る。

・ IT 全般統制活動における変更計画の認識 ― アプリケーション統制の信頼性に IT

全般統制が重要な役割を果たすことから、IT 全般統制に対して計画されている重大

な変更がアプリケーション統制にどのように影響を及ぼすかの評価に、影響を受け

る業務ユーザが関与することが大切である。ビジネス部門が IT 全般統制の改善に寄

与することによりアプリケーション統制の信頼性が高まり、コストのかかる手作業

による統制活動を削減できるようになる。

情報処理およびシステム運用のアウトソーシングの影響

データセンタへのホスティングから情報システムの開発、運用および保守の完全なアウ

トソーシングに至るまで、企業が一部あるいはすべてのコンピュータ処理環境をアウト

ソースするケースが、現在のビジネス環境では多くなっている。アウトソースされた環

境では、管理およびコントロール活動の多くはサービス提供者が実行責任を負っている。

しかし、経営層は、アウトソーシング先における内部統制の有効性に関する説明責任を

負っており、サービス提供者の内部統制の強みと限界の両方の影響を自社の内部統制活

動に反映させる必要がある。サービス利用企業は、内部統制に関する自社の要件を定義

し、提供企業が実施するこれらの活動の有効性をモニタリングするために適切な措置を

講じなければならない。経営層がサービス提供企業におけるコントロールの有効性をモ

ニタリングするために利用できるツールおよび手法としては、SLA（サービスレベルア

グリーメント）に照らしたサービス提供状況のモニタリング、サービス提供者の内部統

制システムの有効性に関する第三者評価結果の取得などが挙げられる。このような手法

は、サービス提供者に対するガバナンスおよび管理の全体フレームワークの一部となっ

ている。詳細については、COBIT 4.1 IT プロセス「DS2 サードパーティのサービスの

管理」を参照のこと。


7. アプリケーション統制の保証

保証とは何か

保証に関する概念およびガイダンスとしては、国際監査・保証基準審議会（IAASB）の

保証業務のための国際フレームワーク（IAASB 保証フレームワーク）などの正式な基

準が挙げられるであろう。ただし、これらは第三者に保証を提供する独立した監査人の

観点から開発され、提供されている基準である。本書では、「保証」という用語が「監

査」よりも広い意味で使用され、内部あるいは外部監査基準では統括されない評価活動

も対象にしている。

「保証」という概念には、5 つのコンポーネントが必要である（図 1416）。

要約すると、「保証」とは、対象事項が関連する規準を満たしているかいう点について、

保証提供者によって作成された追加的情報または結論を利害関係者に提供することで

ある。

保証に関する一般的な例

保証の提供が行われる一般的な例を以下に挙げる。

・財務諸表監査の意見 ― 独立した監査人（保証の提供者）の意見として、取締役会

や株主（利害関係者）に対して企業の財務諸表（対象事項）が一般的に公正妥当と

認められた会計原則（規準）に従って適正に作成されていること（結論）を示すも

の。

16 ITGI の発行物『IT Assurance Guide: Using COBIT（IT 統制の保証ガイド）』、米国、2007 年を参照のこ

と

対象事項に対する

責任者、保証業務の

専門家、および保証

報告書の想定利用

者という三者の関係

保証が提供される

対象事項（デー

タ、システム、プロ

セス）

対象事項を評価

するための適切

な規準（基準、ベ

ンチマーク、法

規）

保証業務の専

門家が実施す

るプロセス

保証業務の専門家

の結論

図 14 ― 保証活動の 5 つのコンポーネント


・特定の業務プロセスに関する内部監査報告 ― 内部監査人（保証の提供者）による

報告として、経営層および取締役会（利害関係者）に対して、特定の業務プロセス

内のリスク（対象事項）が COSO ERM フレームワーク（規準）に基づき適切に低

減されていること（結論）を示すもの。

・ ISO 27001 認証 ― 公認の認証会社（保証の提供者）による審査の結果、企業の情

報セキュリティマネジメントシステム（対象事項）が ISO 27001 によって定められ

た規準（規準）に準拠していることを世間一般（利害関係者）に示す認証。

・サービス監査人の報告 ― 独立したサービス監査人（保証の提供者）によって提供

される監査および監査意見として、サービス提供企業の内部統制活動（対象事項）

が、利用企業およびその監査人（利害関係者）が関心を持つコントロール目標を達

成するために、適切に設計され有効に運用されていること（結論）を示すもの。

・サーベンスオクスリー法第 404 条で義務付けられている内部統制に関する経営層の

アサーション ― 財務報告に関する内部統制がCOSOなどの内部統制フレームワー

ク（規準）に従って、適切に設計され有効に運用されていること（結論）を株主お

よび資本市場（利害関係者）に対して示す経営層（保証の提供者）のアサーション。

・ IT 全般統制の信頼性に関する高財務責任者（CFO）/CEO に対する CIO の「サ

ブ認証」17 — CIO（保証の提供者）による「認証」。CIO の管轄下にある財務報告

に関連する IT 全般統制（対象事象）が、COBIT（規準）に従って適切にデザインさ

れ（結論）有効に運用されていること（結論）を示すもの。


保証の提供という概念は、経営層、取締役会および株主に保証を提供する（社内外の）

監査人という意味合いで一般的には考えられている。しかし、関連するステークホルダ

ーに対する保証の提供という観点から、この概念が財務管理および経営管理へ関連付け

られる場面が増えている。経営層がステークホルダーに対して保証を提供する例として

は、サーベンスオクスリー法などの法律に従い、CEO/CFO が内部統制の設計と運用の

有効性を認証するケースや、ライン統括責任者（CIO など）が CEO/CFO に対して事業

ユニット内の統制の有効性の「サブ認証」を提供するケースなどが挙げられる。

アプリケーション統制をめぐる保証

アプリケーション統制は、自動化されたアプリケーションシステムに関連するトランザ

クションおよびマスターファイル、あるいはマスタデータに関連するものであり、それ

ぞれのアプリケーションに特有のものである。アプリケーション統制により、情報の正

17 「サブ認証」とは、コントロールの責任が運用管理者に委任されている場合に、CFO および CEO が企

業内の財務報告に関する内部統制の保証を獲得できるようにするための方法である。


確性、インテグリティ、信頼性、機密性、ならびに手作業および自動化された処理に起

因するトランザクションやマスタデータに対して行われた入力の正当性が保証される。

アプリケーション統制に関連する目標については、第 4 章および第 5 章で詳しく考察し

ているが、一般的には以下の項目の保証が関係している。

・入力のために準備されたデータは承認され、完全かつ妥当で信頼できる。

・データが自動処理可能な形式に変換され、正確、完全、かつ適時にアプリケーショ

ンに入力される。

・データがアプリケーションによって、定義された要件に従い、正確に、完全かつ適

時に処理される。

・インテグリティと妥当性を維持するために、処理の全体を通してデータが保護され

ている。

・承認されていない改変や破損から出力が保護されており、規定された方針に沿って

配布される。

アプリケーション統制をめぐる保証の提供には、確立された規準（COBIT のアプリケ

ーション統制目標など）に対して、アプリケーション統制（対象事項）が適切に設計さ

れ、有効に運用されている（結論）という十分な証拠を収集するプロセスに従う保証の

提供者（プロセス/アプリケーションのオーナ、内部監査人、外部監査人など）が通常

は関与している。

『COBIT Control Practices: Guidance to Achieve Control Objectives for Successful IT

Governance, 2nd Edition』、および『IT Assurance Guide: Using COBIT（IT 統制の保証ガ

イド）』の付録 VI には、関連するアプリケーション統制の実践のための詳細なガイダ

ンス、保証ステップ、および COBIT の 6 つのアプリケーション統制目標のそれぞれに

関するコントロールのテスト案が掲載されている。

重要性

ある一連のアプリケーション統制がコントロール目標および規準を十分に満たすもの

であるかどうかを決定する際には重要性を考慮しなければならない。何が重要であるか

というアセスメントは専門家が判断すべき問題であり、これには、コントロールの欠陥

の結果としてエラー、入力漏れ、不正データおよび違法行為が発生した場合、それが企

業の事業目標達成能力に与える潜在的な影響を検討することも含まれる 18。

18 ISACA IS Auditing Guideline G6 Materiality Concepts for Auditing Information Systems section 3.1.1（情報シス

テム監査指針 G6、情報システムの監査に係る重要性の概念）

重要性は、以下のようなものとして利用することができる。


・保証の提供者の結論を裏付けるために必要な証拠の量を決定する要因

・対象事項について発見した事項の重大性の測定

財務諸表監査を実施する、あるいは支援する際、保証の提供者は通常、金額的観点から

重要性を測定する。これは、監査対象も金額的観点から測定され、報告されるからであ

る。アプリケーション統制の保証の提供者は、財務以外のシステム（航空管制システム

など）や記録（医療診断コードなど）に関する保証の提供が求められる場合もあるため、

代替的な測定も必要である。特定のコントロール目標について、重要なコントロールと

は、そのコントロール手続によってコントロール目標が果たされるという合理的な保証

が必ず提供されるひとつのあるいは複数のコントロールである。「ISACA IS Auditing

Guideline G6 Materiality Concepts for Auditing Information Systems（情報システム監査指針

G6、情報システムの監査に係る重要性の概念）」では、保証の目標が財務トランザク

ションを処理するシステムあるいはオペレーションに関係する場合は、システムが管理

する資産の価値および日/週/月/年ごとに処理されるトランザクションの値を評価する

際に重要性を考慮すべきである、と定めている。

財務トランザクションに影響しないシステムおよびコントロールに関しては、以下のよ

うな測定例を検討し、重要性を評価することができる。

・システムまたはオペレーションがサポートする業務プロセスの重要度

・システムまたはオペレーションのコスト（ハードウェア、ソフトウェア、人員、サ

ードパーティのサービス、間接費、これらの組み合わせなど）

・エラーに対する潜在的なコスト（風評リスク、顧客／消費者の信用の失墜、売上の

減少、保証請求、回収不能な開発コスト、告知費用、訂正コスト、安全衛生のコス

ト、不必要に高い生産コスト、大量の無駄など）

・期間ごとに処理されるアクセス/トランザクション/照会の件数

・作成されるレポートおよび保持されるファイルの性質、タイミングおよび範囲

・扱われる材料の性質および数量（在庫の動きが価格なしで記録されている場合など）

・ SLA の要件と潜在的な違反コスト

・法的要件および契約上の要件への準拠違反に対する罰則

・エンドユーザの生産性の損失

・エンドユーザの効率性の低下

保証リスク

保証リスクとは、対象事項の虚偽表示の存在（あるいは不在）に関して保証の提供者が

誤った結論に達するリスクのことである。アプリケーション統制に関しては、誤った結

論のリスクとして、実際には効果的に運用されていないアプリケーション統制が、効果


的に運用されていると結論付けられるリスクなどが挙げられる。保証リスクは、重大な

エラーまたはコントロールが有効ではないリスク、および保証の提供者が関連するエラ

ーまたはコントロールの不備を発見できないというリスク（発見リスクと呼ばれる場合

もある）である。

重要なエラーのリスクには 2 つのコンポーネントがある 19。

・固有リスク ― 対象事項（責任部署によるアサーション）が重要な虚偽表示になり

得るリスク

・統制リスク ― アサーションにおける虚偽表示が発生する恐れがあり、それが内部

統制によって適時に防止、発見あるいは修正されないというリスク

保証活動を計画する際には、対象事項に関連する固有リスクを検討して手続の性質と範

囲を判断し、発見リスクを受容可能なレベルにまで低減するようにそれらの手続を設計

することが重要である。

アプリケーション統制の保証取得のプロセス

保証の提供者が特定の保証活動を実施する際に参考とすることができるプロセスのロ

ードマップを図 15 に示す。

ステップ 1 ― 理解の精緻化

実行段階の初のステップは、保証が必要な対象事項について理解し、それを精緻化す

ることである。アプリケーション統制の場合、これは業務プロセスをその目的と目標を

19 これらの定義は国際監査・保証基準審議会（IAASB）より引用してある。国際会計士連盟（IFAC）の

『International Standard on Auditing（ISA：国際監査基準）330（redrafted）』、米国、2006 年などを参照の

こと。

図 15 ― アプリケーション統制の保証のためのロードマップ

IT 保証の対象に

対する理解を精緻

化する。

IT 保証の対象

のための主要な

コントロール目

標の対象範囲

を精緻化する。

コントロールの

欠陥の影響を文

書化する。

全体の結論と

提言を作成し

伝達する。


標を達成する

ためのコントロ

ールの設計の

有効性を評価

する。


標を達成する

ためのコントロ

ールの運用の

有効性を評価

する。


含めて理解すること、ならびに業務プロセスを支援するアプリケーションを理解するこ

とを指す。これを理解する際には、以下のような要素の理解が必要である。

・対象となるアプリケーションの特定（独立したアプリケーションとインタフェース

アプリケーションを含む）

・対象となる入力、出力および保存データの特定

・アプリケーションが処理する情報の種類とソース ― 重要な入力

・アプリケーションが実行する処理の性質（計算、要約、翻訳/変換など）

・アプリケーションからの出力情報の種類と宛先

・企業とそのステークホルダーが意思決定を行う際の業務プロセスに対する情報の重

要性

このステップからの成果物には、以下の項目に関する文書化された証拠が含まれる。

・アプリケーションに対する情報の主要な供給者

・アプリケーションの処理に必要な情報の重要な種類またはクラス

・情報をアプリケーションに入力するためのフォーム、内容および方法

・アプリケーションが実行する重要な処理の詳細

・他のアプリケーション、プロセスまたはサブプロセスへの従属関係

・以後の利用（当該アプリケーションまたはその他による）のために保持されている

重要なデータの主要な保管場所およびテーブルに関する詳細

・情報をアプリケーションから出力するためのフォーム、内容および方法

・アプリケーションが生成した情報の主要なステークホルダーまたは受領者

保証の提供者が現在有している業務プロセスおよびアプリケーションに関する知識レ

ベルに応じ、以下の流れに従ってこのステップを構築することができる。

・ビジネスプロセスオーナ、アプリケーションの対象事項の専門家およびアプリケー

ションユーザに対する聞き取り調査を行う。

・アプリケーションユーザおよびシステムをサポートする資料、ポリシー、システム

の入出力、問題のログ、会議の議事録、これまでの保証報告書および推奨事項、マ

ネージメントレターなどを収集し、精読する。

・既存の情報フローや情報処理の主要素をまとめた記述書を作成し、活用する。

・有効性、効率性、機密性、インテグリティ、可用性、コンプライアンスおよび信頼

性の情報要請規準の観点から、関連する事業目標や情報に対するステークホルダー

の期待を要約する。

・網羅性、正確性、妥当性、承認および職務分離など、保証を提供する対象のアサー

ションを要約する。


ステップ 2 ― 対象範囲の精緻化

アプリケーションおよび関連する業務プロセスに対する詳細な知識に基づき、保証の提

供者は求められる保証を提供するために必要な対象範囲を決定する。このプロセスは以

下の項目で構成される。

・関連する情報要請規準や関連リスク、あるいは関連するアサーションに影響を及ぼ

す恐れがある潜在的脅威の評価（情報のインテグリティに影響を及ぼす恐れのある

脅威、網羅性または正確性のアサーションに関連するようなリスクまたは影響など）

・識別された脅威/リスク、およびステークホルダーの要求を満たす保証の提供に関連

するアプリケーション統制の目標の明確化

ステップ 3 ― コントロールの設計の評価

このステップでは、保証の提供者は、該当する対象範囲内のコントロール目標を達成す

るために導入されたコントロール活動を識別し、アプリケーション統制活動が有効に運

用された場合に、そのアプリケーション統制活動が設計に従って、識別されたコントロ

ール目標を合理的に達成するかという点について結論を出す。コントロールの設計の有

効性に関する結論を出す際、保証の提供者は、一般的に、第 4 章で取り上げた経営層が

アプリケーション統制の設計において検討する項目と同じアプリケーション統制の属

性を検討する。それには以下の項目が含まれる。

・活動の種類 ― 自動化 vs 手作業 vs ハイブリット vs コンフィギュレーション

・コントロールの性質 ― 予防的 vs 発見的

・コントロールの頻度 ― コントロール活動が有効ではない場合の虚偽表示のリスク

を検討する

・重大なコントロールの不備につながる恐れがあるリスクとなる対象事項とコントロ

ール活動との近接性（距離）

・コントロール活動の実行者、およびその責任が、情報処理に関連するその他の矛盾

する活動から十分に分離されているかどうか

このステップの一環として、保証の提供者は、コントロール活動が業務に組み込まれて

いることを確認するため、十分な手続を実施する。一般的に「ウォークスルー」と呼ば

れるこの活動により、保証の提供者がアプリケーション統制活動を正確に理解しており、

かつこれらの活動が記述通りに運用されているということが確認できる。保証の提供者

が実行する活動の性質は、ステップ 4 に示すものと似ている場合もあるが、限定した範

囲で実行するのが一般的である。

ステップ 4 ― コントロールの運用の有効性の評価

プロセスのこのステップでは、保証の提供者はコントロール活動が記述通りに運用され


ているという証拠を収集する。独立した保証の提供者の場合（社内外の監査人あるいは

企業のコンプライアンスグループなど）、この活動にコントロール活動の「テスト」が

含まれるのが一般的である。経営層によって保証が提供される場合は、保証のアサーシ

ョンを裏付ける証拠が業務プロセス内に累積しており、経営層によるレビューの対象と

なっている場合がある。

特定のコントロール活動に適したテスト手続は、その活動の個別内容によって異なるが、

以下の 4 つの共通した一般的なテスト手法が使用される。

・質問と確認

- 例外/逸脱の検索とその審査

- 通常でない、またはルーチンでないトランザクション/イベントの調査

- トランザクション/イベントの発生の有無の確認/判断

- スタッフからの聞き取り調査およびその知識や認識の評価

- 発見事項を確認するための経営層への質問および回答の回収

・検査

- 計画、ポリシーおよび手続のレビュー

- 入力データと原始文書との比較

- 監査証跡、問題のログなどの検索

- プロセス/システムを通じたトランザクションの追跡

- 存在（文書、資産など）の物理的点検

- 実際の結果と期待される結果の比較

・観察

- プロセス活動および手続の観察と記述

- 実際の挙動と期待される挙動の比較

・再実施や再計算

- トランザクションの照合（トランザクションと銀行取引明細書との照合）

- 独自の開発及び推測により期待される結果

- 予防された項目の試行

- 発見的コントロールにより発見された内容の再実施

- トランザクション、コントロール手続などの再実施

- 独立した再計算

- 実際の値と期待される値との比較

- 実際の挙動と期待される挙動の比較

- プロセス/システムを通じたトランザクションの追跡


コンピュータ支援監査技法（CAAT）

アプリケーションは、電子データの収集、処理、要約および保存を行っているため、電

子形式でこれらのデータを利用できれば、保証の提供者が自動化された分析手法（一般

的に「CAAT」と呼ばれる）を設計し、それをコントロール活動の有効性のテストある

いはコントロール活動の結果に対するテストに利用することができる。一般的に CAAT

が使用される例は以下の通りである。

・システムに組み込まれたコントロールの対象になっていないすべての入力データ

（コントロールが回避されたデータ、無効化されたデータ、あるいは手入力された

データ）を明確化し、分析する。

・例外ファイルの例外の件数、例外の経過期間、例外の種類および例外の根本的原因

を分析する。

・関連する属性または要素の存在あるいは不在に関するデータを分析する。（ステー

タスフラグ、フィールド内容の妥当性、ブランクフィールド、電子承認）

・項目またはトランザクションの連番をチェックする。

・通常でない、あるいはルーチンではない項目を明確化し、これらの項目に対して適

切なコントロール（承認など）が適用されているかをチェックする。

・自動計算によって期待されるアウトプットを独立的に推定または再計算する。

・コントロール活動の違反を示すようなデータの傾向や潜在的異常を分析する。

・異なるシステム間でのデータの比較/照合を行う。

・再計算または生成ルーチンの報告を行う。

その他の検討事項

保証の提供者は、情報とアプリケーションの情報処理目標に関連する具体的な保証目標

を達成するだけではなく、コントロールの設計と運用の費用対効果などの属性について、

その評価業務の一環として検討する場合がある。以下のようなステップの検討が行われ

る。

・一連のコントロールプラクティスの設計が有効である場合、他のコントロールの仕

組みとの相乗効果を求めることや予防統制と発見統制のバランスを再検討して補正

することによりステップを適化し、コントロールプラクティスの設計がさらに効

率的になるかどうかを評価する。また、コントロールプラクティスの維持に費やさ

れる労力も検討する。

・一連のコントロールプラクティスが有効に運用されている場合、その費用対効果を

さらに高められるかを調査する。このコントロールプラクティスに関連する活動の

パフォーマンス測定指標や追加の自動化の可能性について分析を行う。


ステップ 5 ― コントロールの欠陥が及ぼす影響の文書化と周知

コントロールの欠陥（設計の不備あるいは運用の有効性の不備）が見つかった場合、そ

の内容は機密性が高く慎重に扱う必要が多いことに留意するとともに、適切に文書化し、

プロセスオーナに注意を促す必要がある。発見された欠陥と業務への潜在的な影響の重

大さを正確に分析し評価するためには、特別な配慮が必要である。

このステップの目標は、コントロールの欠陥とそれに起因する脅威、脆弱性および影響

に関する詳細な理解を得るために必要な分析を行うことである。

コントロール目標が達成されない場合の影響を文書化し、伝達するためには、以下のア

クティビティを実施する。

・損益への影響、財務報告のインテグリティ、作業ロス、売上の減少、市場、顧客

および株主からの要求事項への対応能力などの観点から実際のコントロールの欠

陥の影響を決定し、文書化するために、さらなる調査分析を実施する。

・効果的なコントロールによって予防可能であったエラーによるコスト（顧客およ

び財務への影響など）を文書化する。

・規制要件および契約上の合意に対する準拠違反の影響を明確化する。

・混乱や機能停止による業務プロセスや事業目標、ならびに顧客に対する実際の影

響を測定する。（件数、復旧や代替処理に対する対応、ダウンタイム、顧客満足

度、コストなど）

・コントロールの欠陥により影響を受ける効率性の指標として、復旧にかかるコス

ト（通常業務に対する復旧作業の割合など）を測定し、文書化する。

・設定したパフォーマンス指標を測定した結果に結びつける。パフォーマンス指標

がない場合は原因を結果に結びつける。（因果分析）

・コントロールが効果的に運用されていない場合に発生しやすい脆弱性および脅威

を明らかにする。

・どのような影響が及ぶかを説明する。（業務の達成目標と目的、エンタープライ

ズアーキテクチャの構成要素、業務能力、リソースなど）

・コントロール目標を達成しないことによる影響を、同業界内の実際の事例に関連

付け、業界のベンチマークを活用する。

・エラー、非効率および不正の件数やそれらにより想定される状況から、コントロ

ールの欠陥の影響を説明する。

・企業のパフォーマンスを他社と比較するためにベンチマークや調査結果を利用す

る。

保証の提供者は、明確化されたすべてのコントロールの欠陥とその結果として生じる脅


威および脆弱性を文書化するとともに、実際の影響および潜在的影響の明確化と文書化

を行う必要がある。（根本的な原因分析など）

目標は、経営層に対して推奨される措置や措置を講じる理由を明確に示すことができる

ように、重要な項目を明確にすることである。このステップには、これまでの結果を集

め、識別されたコントロールの欠陥に関連する結論を導き出し、以下の項目を周知する

ことが含まれる。

・識別されたコントロールの欠陥が及ぼす影響と企業がそれに対応するための準備

・コントロールの欠陥が及ぼす影響を軽減するために推奨される措置

・基準やベストプラクティスに照らしたパフォーマンスの比較

・プロセスにおけるリスクの位置づけ

ステップ 6 ― アプリケーション統制に関する結論

このステップにおいて、保証の提供者は、対象事項が規準を満たしていることを合理的

に保証するのに適した十分な証拠があるかという点について結論を出す。アプリケーシ

ョン統制の場合は、情報処理の正確性、インテグリティ、信頼性および機密性に関する

合理的な保証を提供するためのコントロール活動が適切に設計され、有効に運用されて

いるかを判断する。保証の提供者は、結論を出すために、保証プロセスで集めたすべて

の情報を検討する。これには、以下の項目が含まれる。

・業務プロセスの目標およびアプリケーションの目標に関する理解

・識別された目標に適合したアプリケーション統制の設計の有効性を裏付ける証拠

・コントロール活動の運用の有効性を裏付ける証拠の十分性および適切性

保証の提供者は、結論の形成にあたり、正式な保証の伝達、報告基準や報告ガイドライ

ンといった保証基準への準拠に留意する必要がある。

アプリケーション統制のテストに適したサンプルサイズ決定のためのガイダンス

アプリケーション統制のテストのためにこれまでに識別された多くの手続に関し、保証

の提供者はサンプリング方式を利用し、母集団の一部（サブセット）を選択して調査す

ることになる。コントロールのテストのためのサンプルに選ぶ項目数を決定するために、

保証の提供者は、求められる信頼水準、テスト対象のコントロールに対する許容逸脱率、

逸脱の発生率、およびコントロールリスクの評価における許容リスクを検討する。

・信頼水準 ― サンプルによって提供される保証の程度を指す

・許容逸脱率 ― 保証の提供者が結論を形成するにあたり、許容可能な大の逸脱

率（コントロール活動の例外）を指す

・逸脱の発生率（あるいは想定されるエラー率） ― 母集団の中で見つかることが


想定されている逸脱の割合を指す。第 4 章で考察したように、アプリケーション

統制は活動の属性によって、その信頼性にばらつきが出る場合がある。

・コントロールリスクの評価における許容リスク（許容監査リスク） ― サンプリ

ングにおける固有リスクにより誤った結論に達することを指す。これには、選択

したサンプル数が少なすぎて母集団全体における実際の結果を反映しないという

リスクも含まれる。

内部統制のサンプリングに関する追加のガイダンスについては、米国公認会計士協会

（AICPA）の監査基準書（SAS）第 39 号：監査サンプリングの改訂版である監査基準

書第 111 号を参照のこと。

サンプルサイズを決定する際に検討される要因は多数存在するが、企業および監査人が

コントロールの運用の有効性をテストするのに使用する一般的な（小の）サンプルサ

イズは、図 16 の通りである。

図 16 ― サンプルサイズ決定のためのガイダンス

コントロールの性質実行頻度小のサンプルサイズ

手作業 1 日複数回 25

手作業毎日 25

手作業毎週 5

手作業毎月 2

手作業四半期ごと 2

手作業毎年 1

自動化プログラム化されたコントロール活動ごとに 1 回

（IT 全般統制が有効である場合）

IT 全般統制手作業もしくはプログラム化された IT 全般統制の実施状況により、

上記ガイダンスに従う

図 16 のガイダンスは、財務報告にかかわる内部統制に関して提供される保証やある時

点でのコントロールの有効性に関する付随の意見に関連するものとして特別に作成さ

れているため、すべての状況に該当する訳ではない。結論を裏付けるために必要なサン

プリングの程度の終的な決定は、保証の提供者が関連するすべての要因を検討し、各

自の専門的判断を適用しなければならない。たとえば、サンプル中に 1 つのエラーが含

まれることが想定される場合、信頼水準が同程度になるようサンプルサイズを拡大する

必要がある。


サンプリングが適さないと考えられるコントロールのテストも多い。たとえば、実行結

果としての文書化された証拠が存在しない場合や保証の提供者が利用可能な証拠をす

べて調査することで、サンプリングと同程度の効率性で実施できると考えられる場合は、

サンプリングが適さないと考えられる。

自動化されたアプリケーション統制のテスト

第 4 章では、自動化されたアプリケーション統制の事業価値および便益について考察し

ている。自動化されたアプリケーション統制には、保証コストの大幅な削減の機会も存

在する。図 16 では、アプリケーション統制が自動化されている場合、コントロール活

動ごとに 1 回テストを実施すれば、必要な保証を十分に得られる可能性があるというこ

とを示唆している。（例：発注書、物品の受領書、請求書の許容範囲をみるための自動

化された 3-way-match プロセスとアプリケーションの観察など）手作業によるコントロ

ール活動の規模や件数の拡大および複雑化により、手作業によるコントロール活動を裏

付けるために必要な証拠を集めるコストが増加することから、自動化されたアプリケー

ション統制では大幅に効率が向上する。

この「1 回テスト」という原則は、処理活動の信頼性に影響を及ぼす変更が情報処理環

境に行われるまでは毎回同じように実行するという情報システムの処理がもたらす固

有の信頼性に基づいている。このためには、情報処理環境におけるコントロール（IT

全般統制）が評価され、それらの運用の有効性が確認されている必要がある。


保証の提供者が可能な範囲で自動化されたアプリケーション統制に依拠することは、効

率性と費用対効果の向上につながる可能性がある。なぜなら、手作業による活動の運用

の有効性の検証に係るコストを削減できる可能性があるからである。IT 全般統制が有

効であれば、ベンチマーキング戦略により、運用の有効性の検証コストと労力をさらに

削減できる可能性もある。

ベンチマーキング

この論理をさらに拡大すると、ベンチマーキングあるいはベースライニングの概念を導

入することとなる。全体が自動化されたアプリケーション統制は、当該アプリケーショ

ン統制が運用されるコンピュータ処理環境が適切にコントロールされており、それらの

コントロールが効果的に運用されている限り、当然一定の信頼度で運用され続けること

が期待できる。このアプローチを保証戦略上採用する場合は、以下の項目が求められる。

・保証の提供者は、対象となる自動化されたアプリケーション統制が十分な信頼性

を持って運用されていることを立証する必要がある。上述の論理で示唆されてい


るのは、自動化されたコントロールは一定の信頼度で運用され続けるであろうと

いうことだけである。それが現状効果的に運用されていなければ、今後も効果的

な運用が期待できないと考えるのが妥当である。したがって、保証の提供者は、

自動化されたアプリケーション統制が有効に運用されていることを立証する必要

がある。自動化されたアプリケーション統制が現状においても有効であることを

立証する活動は、「ベンチマーキング」または「ベースライニング」と呼ばれる。

・保証の提供者は、自動化されたコントロールの信頼できる運用に関連する IT 全般

統制の設計および運用の有効性に依拠可能である必要がある。IT 全般統制の影響

に関する追加のガイダンスについては、次のセクションで取り上げる。自動化さ

れたアプリケーション統制のベンチマーキングは、購入したソフトウェアを利用

している企業にとって特に効果的であると考えられる。それは、プログラム変更

の可能性が少なく、頻繁な「再ベースライニング」が不要であるためである。ベ

ンダーがソースコードへのアクセスまたは改変を認めていない場合がこれに該当

する。

ベンチマーキングは、財務報告に係る内部統制に関連する保証を提供する外部監査人に

とって、許容できるアプローチとして認識されてきた。PCAOB の「Question and Answer

guidance（Q&A ガイダンス）」20からの引用を以下に掲載する。

自動化されたアプリケーション統制は、・・・特定のコントロール（売掛金の年齢

調べ、インボイスの単価と数量の計算、エディットチェックの実行など）を、プロ

グラムが変更されるまでまったく同じように実行し続けるものである。したがって、

全体が自動化されたアプリケーション統制では、人為ミスによる例外が発生しない

ことになるため、監査人はこれらのコントロールを「ベンチマーキング」あるいは

「ベースライニング」することが可能となる。プログラムの変更、プログラムへの

アクセスおよびコンピュータの運用に係る IT 全般統制が有効かつ継続的にテスト

されており、監査人が前回、アプリケーション統制のテストを実施してから自動化

されたアプリケーション統制に変更がないことを確認できる場合は自動化された

アプリケーション統制に対して前年実施した詳細な運用テストを繰り返さなくて

も、そのアプリケーション統制が有効であると結論付けることができる。コントロ

ールが変更されていないことを検証するために監査人が入手すべき証拠の様態や

範囲は、組織のプログラム変更管理のレベルなどの状況に応じて変わる可能性があ

る。

20 公開会社会計監視委員会（PCAOB）、『Staff Questions and Answers, Auditing Internal Controls Over Financial

Reporting』、米国、2005 年 5 月 15 日


この文書では、アプリケーション統制に対する「1 回テスト」によりコントロールが有

効に運用されていることに十分な証拠を得るためには、IT 全般統制が有効である必要

があるという点が強調されている。IT 全般統制が有効でなければ、「1 回テスト」では

アプリケーション統制が有効に運用されているという十分な証拠が必ずしも提供され

ないことになる。

ある自動化されたアプリケーション統制が、期待水準の保証を得るためのベンチマーキ

ング戦略や活動計画に適したものであるかどうかを決定する際には、IT 全般統制の有

効性に加え、以下のような要因を考慮する必要がある 21。

・自動化されたアプリケーション統制と特定のプログラムとの対応付けがどの程度

可能か

・自動化されたアプリケーション統制機能を含むアプリケーションがどの程度安定

しているか（期間によっていくらかの変化がある）

・本番環境に組み込まれているプログラムのコンパイル日付を含むレポートが入手

可能であるか、およびそれが信頼できるものであるか（この情報はアプリケーシ

ョン内の自動化されたアプリケーション統制が変更されていないことを示す証拠

として利用できる）

・自動化されたアプリケーション統制の確実かつ有効な機能に関連するファイル、

テーブル、データおよび設定パラメータに係るコントロールの有効性を裏付ける

証拠（例えば、利息計算のための自動化されたアプリケーションは、自動計算に

使用されるレート表の継続的インテグリティに係るコントロールの有効性に左右

されると考えられる）

・保証の提供者が必要な保証水準とその有効性を維持するために、自動化されたア

プリケーション統制を「再ベンチマーキング」しなければならない頻度。ベンチ

マークを確立しなおす時期を決定するために、保証の提供者は以下の要因を考慮

する。

- アプリケーションやシステムソフトウェアの調達および保守、アクセスコント

ロールやコンピュータの運用といった IT 全般統制の設計および運用の有効性

において利用可能な保証水準

- コントロールを含む特定のプログラムに対する変更がある場合は、その頻度と

潜在的な累積的影響の理解

- 関連するその他のコントロールの有効性

21 公開会社会計監視委員会（PCAOB）、『Staff Questions and Answers, Auditing Internal Controls Over Financial

Reporting』、米国、2005 年 5 月 15 日


- ベンチマークされている自動化されたアプリケーション統制に関連するエラー

の影響

アプリケーション統制の保証における IT 全般統制の不備の影響

前のセクションで述べたように、保証の提供者が「1 回テスト」手法により自動化され

たアプリケーション統制の信頼性に係る保証を得ることができるかどうかは、対象とな

る自動化されたアプリケーション統制が運用されている IT 処理環境に係る IT 全般統制

そのものが有効に設計され運用されていることが保証されているかによる。

ここで、IT 処理環境の IT 全般統制における不備が、自動化されたアプリケーション統

制の有効な運用にどのような影響を及ぼすのかという疑問が生じる。

この疑問に答えるために、保証の提供者は以下の項目を検討する必要がある。

・識別された IT 全般統制の不備が、自動化されたアプリケーション統制に関連してい

るか。

・識別された IT 全般統制の不備が、アプリケーションもしくは関連する自動化された

アプリケーション統制の運用に悪影響を及ぼすリスクにはどのようなものがあるか。

識別された IT 全般統制の不備が、自動化されたアプリケーション統制に関連しているか

保証の提供者は、IT 全般統制において識別された不備が自動化されたアプリケーショ

ン統制に関連しているか（あるいはしていないか）を決定する必要がある。この関連性

の立証は、以下の手順で実行することができる。

・アプリケーション統制の保証の提供者は、自動化されたアプリケーション統制が運

用されている具体的なアプリケーションを明確化する必要がある。一般的にこれは、

自動化されたアプリケーション統制の設計の識別と評価を行う際、も効率的であ

ると考えられるが、アプリケーションアーキテクチャの詳細な知識を有する対象事

項の専門家による技術支援が必要な場合もある。この明確化により、保証の提供者

が IT 全般統制の保証を必要とする関連アプリケーション一覧が明確になる。

・ IT 全般統制の保証の提供者は、IT 全般統制の設計と運用の有効性の評価が必要な IT

処理環境を識別するために、上記のアプリケーション一覧を利用することができる。

さらに、IT 全般統制の保証の提供者は、IT 全般統制の運用の有効性を評価するため

に選ばれる項目から適切な母集団を決定する際、識別された関連するアプリケーシ

ョンの一覧を利用することができる。

・ IT 全般統制の保証の提供者は、IT 処理環境で識別された不備およびそれによって影

響を受けるアプリケーションをアプリケーション統制の保証の提供者に伝達するこ

とができる。


この関係を図示したものが図 17 である。

識別された IT 全般統制の不備が、アプリケーションもしくは関連する自動化されたアプリケー

ション統制の運用に悪影響を及ぼすリスクにはどのようなものがあるか

IT 全般統制の不備が、自動化されたアプリケーション統制に悪影響を及ぼすリスクを

評価する際には、以下の項目を考慮する必要がある。

・ IT 全般統制の不備に関連するリスク（あるいはエラーの状況）がどのようなものか、

関連する IT 全般統制の目標の達成に対する影響がどの程度重大か。IT 全般統制に

識別された、関連するコントロール目標が達成されるかどうかに影響を及ぼすほど

重大ではない不備は、通常、関連する自動化されたアプリケーション統制にも重大

な影響を及ぼさない。

・コンピュータ処理環境の中に、識別された IT 全般統制の不備を補完し、それによっ

て当該リスクを十分に低減するような他の有効なコントロールがあるか。

・そのような補完的コントロールが存在しない場合は、さらなる調査分析によって、

自動化されたアプリケーション統制が悪影響を受けないという十分な保証が提供さ

れるか。たとえば、識別された不備が、アプリケーション開発者によるアプリケー

ション処理環境への不適切なアクセスに関連するものである場合、操作ログの分析

（ログの網羅性に係る合理的な保証が得られることを想定）により、そのようなア

クセスによって影響を受けるアプリケーションの運用に悪影響が及ばないという十

分な保証が提供される可能性がある。

図 17 ― IT 全般統制の不備とアプリケーション統制の有効性との関係



関連するアプリケーションの

一覧

関連する IT 処理環境

IT 全般統制の評価

業務プロセスの目標

業務処理統制

信頼性への影響範囲を決定する

範囲を決定する

定義する定義する

達成する


これらの活動によって自動化されたアプリケーション統制への悪影響のリスクが十分

に低減されない場合、アプリケーション統制の保証の提供者は以下の項目を考慮しなけ

ればならない。

・自動化されたアプリケーション統制に対する潜在的な悪影響に起因するリスク（あ

るいはエラーの状況）がどのようなものか、また、アプリケーション統制の目標に

関連する他のコントロールを検討した場合、その目標の達成に対する影響がどの程

度重大か。

・関連するアプリケーションおよび業務処理統制の中で、自動化されたアプリケーシ

ョン統制の不備を補完し得る他の有効なコントロールがあるか。たとえば、自動化

されたアプリケーション統制における重大な障害を発見できる手作業による発見的

コントロールが存在する可能性がある。

・他のアプリケーション統制や業務処理統制の中に補完的コントロールが存在しない

場合は、アプリケーションシステムおよびデータのさらなる調査分析によって、自

動化されたコントロール活動が悪影響を受けないという十分な保証が提供されるか。

たとえば、自動化された活動について追加でテストを実施し、自動化された活動が

IT 全般統制の不備による悪影響を受けず、有効に運用され続けているという十分な

保証を提供できるか検討する。追加テストの程度の決定は、専門家として判断すべ

き問題である。ただし、不備が手作業による IT 全般統制に関連するものである場合、

同じ範囲におけるアプリケーション統制の追加のテストは、その活動が手作業で実

施されているとみなすことで（図 16 参照）、アプリケーション統制が有効に運用さ

れているという十分な証拠となる。


図 18 には、IT 全般統制の不備がアプリケーション統制に及ぼす影響を判断するために

役立つチャートを示している。

IT 全般統制の不備が存在する場合、保証の提供者は（これまでに概説したステップな

どにより）アプリケーション統制の目標達成に関連する十分な情報を他の方法を用いて

得ることができるが、これは、IT 全般統制の不備を是正する経営層の行動が不必要あ

るいは不適切であるという意味ではない。

IT 全般統制と自動化されたアプリケーション統制との関係は、アプリケーション統制

の保証の提供者と IT 全般統制の保証の提供者との間で適時に有効なコミュニケーショ

ンを取ることの重要性を示している。

図 18 ― 自動化されたアプリケーション統制に対する IT 全般統制の欠陥の影響

IT 全般統制の目標が達成されているか（他の直接的コントロールまたは補完的コ

ントロールのいずれかによるもの）

追加の調査的分析により、不備が発生し

ていないという合理的な確証が得られる

か。

IT 全般統制の不備を十分に補うその他のアプリケーション統制が存在するか。

影響を受けるアプリケーション統制のテストを拡大することで、アプリケーション統制が有効に運用されてきたという十分な保証が

得られるか。

自動化されたアプリケーション統制は効果的に運用されていないと結論付け、全体

的な保証への影響を評価する。

IT 全般統制の不備がアプリケーション統制の目標達成に影響を及ぼさない。

Yes

Yes

Yes

Yes

No

No

No

No

付録 A―COBIT 4.1 のプロセスおよびコントロール目標に

対するアプリケーション統制活動のマッピング


付録 A ― COBIT 4.1 のプロセスおよびコントロール目標に

対するアプリケーション統制活動のマッピング

自動化されたアプリケーション統制の設計、導入、運用およびモニタリングに関係する

責任は、IT 統括責任者（コンピュータ化対応策と業務の提供および運用）と経営層（そ

れぞれの業務プロセスの実行と運用）との間で分担される。図 19 および図 20 では活動

と個々の COBIT 4.1 プロセスとコントロールの目標をマッピングしている。プロセスの

目標、目的、達成目標と測定指標、成熟度モデル、役割と責任およびコントロールプラ

クティスに関する追加ガイダンスを参照することができる。表中の参照番号は、第 4 章

および第 5 章の項目参照番号を示している。

図 19 ― アプリケーション統制の設計と導入：COBIT のプロセスとコントロール目標に対するマッピング

主要な活動関連する COBIT の

コントロール目標

第４章


関連するコントロール

目標の明確化

主要なステークホルダーを特定し、アプリケーション統制に関する役

割および責任の割当 AI1.1

情報および情報処理に関連するリスクアセスメントの実施 AI1.2

コントロール目標の設定と文書化 AI1.1

サードパーティーソフトウェアの場合は、RFP へのコントロール要件

の盛り込み AI5.2、5.3、5.4


設計/

構築/

設定

アプリケーション仕様の詳細設計レビュー（自動化されたアプリケーシ

ョン統制を含む） AI2.1、2.3

ベンダーソリューションの評価（コントロール要件の適合を含む） AI2.2

将来の業務プロセス設計（コントロール目標を達成するための手作業

によるアプリケーション統制の設計を含む） AI2.1、AI4.1

アプリケーション統制設計の充足性アセスメントと結論 AI2.1、2.3、2.4、

2.5 ソフトウェア開発の一環としてのプログラムコードの開発と自動化され

たアプリケーション統制のデバッグ AI2.7

アプリケーションのインストールとコンフィギュレーションコントロール

の設定 AI2.5

コントロールの文

書化とユーザトレ

ーニング

アプリケーション統制の文書の作成/更新 AI4.1

ユーザトレーニングの資料作成/更新、ならびに対象スタッフへのトレ

ーニングの実施 AI4.2、4.3、4.4

新規に採用した従業員の場合、アプリケーションと関連するアプリケ

ーション統制に関するフルトレーニングの実施 AI4.2、4.3、4.4

アプリケーション統

制のテストと承認

テスト計画の作成、文書化および承認 AI7.2

テスト計画に従ったアプリケーション統制のテスト AI7.6

テスト中に発見されたたエラーや問題を明確化、記録、優先順位付

け、および解決 AI7.6

未解決の問題を含めた終のテスト結果の文書化と説明 AI7.7 テスト結果の承認とアプリケーション統制の導入判断 AI7.7


図 20 ― アプリケーション統制の運用と保守：COBIT プロセスおよびコントロール目標に対するマッピング

主要な活動関連する COBIT の


第５章


システムソリューシ

ョンの運用

システムソリューションの有効かつ信頼性の高い運用の実現 DS13


有効性モニタリング

手作業によるキーコントロール実施についての管理、監督 AC1～AC7

コントロールの例外、不備、処理エラーの明確化、優先順位付け、エス

カレーションや解決についての管理、監督

プロセス測定指標と重要成果達成目標のモニタリング

コントロールの有効性について定期的アセスメントの実施


業務プロセスとシステムソリューションにおける必要な変更の明確化お

よびビジネス要件の定義 AI6.1

アプリケーション統制変更による影響のアセスメントと必要なコントロー

ル要件と変更の定義 AI6.2

定義されたビジネス要件に基づく、自動化されたアプリケーション統制を

含めたシステムソリューションの変更に伴う設計、構築、テストおよび導

入

AI2、AI6.3、AI6.4、

AI6.5、AI7

定義されたビジネス要件およびシステムソリューションの変更に基づき、

手作業によるアプリケーション統制手続などの業務プロセス変更に伴う

設計、構築、および導入

AI4.2

ビジネス情報テーブル、マスタデータおよび「ユーザ管理」テーブルに対

する変更の管理 AC1～AC7

ビジネスルールおよびその他の「IT 管理」構成テーブルに対する変更の

管理（COBIT コントロール目標 AI2.5 も参照のこと） AI2.5、AI6

付録 B ― アプリケーション統制タイプに関する

追加ガイダンス


付録 B ― アプリケーション統制タイプに関する追加ガイ

ダンス

第 4 章では、リスクイベントの発生とそれに関連するコントロールの近接性を検討する

必要性について取り上げた。以下では、情報処理サイクルのあらゆる段階におけるコン

トロールタイプについて、より詳細なガイダンスを提供する。これらのコントロールは、

例示のために掲載しているものであり、該当するコントロール活動がすべてリストアッ

プされている訳ではない。

情報処理サイクルの各段階におけるコントロールとして、以下のようなものが挙げられ

る。

・入力段階

- 入力妥当性

- 入力時の例外レポートとそのハンドリング

・処理段階

- プログラム化されたロジック

- 処理の検証

- 処理時の例外レポートとそのハンドリング

・出力段階

- 出力結果の検証

- 出力時の例外レポートとそのハンドリング

- 出力結果の配布

- 出力結果の保持と保管

・プロセスの境界

- 情報保護と認証

- 職務分離

- インターフェース

・監査証跡とアプリケーションのログ収集

図 21 は、これらのコントロールの種類と COBIT のアプリケーション統制目標へのマッ

ピングを示すものである。

入力段階

情報処理の入力段階におけるコントロールは、主に業務アプリケーションへ入力された


データのインテグリティをチェックするために使用される。これは、担当者によるシス

テムへの直接入力、ビジネスパートナーによるリモートでの入力、ウェブ対応アプリケ

ーションまたはインターフェースを介した入力のいずれの場合においても該当する。こ

れらの手法および手続きは、アプリケーションに対して有効で承認されたデータのみが

入力され、トランザクションが 1 度だけ処理されるためのデータの確認、承認および編

集時に使用される。

入力妥当性

入力妥当性コントロールの達成目標は、アプリケーションに入力された情報がそのアプ

リケーションの設計に基づき、有効であり、完全なものであることを確実にすることで

ある。入力妥当性コントロールは、入力されるデータの種類、およびアプリケーション

へのデータ入力方法によって、さまざまな形式を取ることができる。

ユーザがアプリケーションに対して情報を入力する場合、必須項目が入力されているこ

と、情報が正しいフォーマットで入力されていること、入力値が有効であること、予め

定められた範囲、限界あるいはその他の基準に準拠していること、および複数の入力フ

ィールドに入力されている情報に一貫性があることなどの確認が入力妥当性コントロ

ールとしてアプリケーションに組み込まれている。たとえば、入力妥当性コントロール

として、顧客マスターファイルに新規顧客を作成する場合に、顧客の名前や住所といっ

た必須情報がユーザによって正しいフォーマット（電話番号特有のフォーマットなど）

で入力されていること、および一貫性があること（利用可能な情報のドロップダウンリ

ストからの選択）の検証などが挙げられる。また、会社の信用ポリシーに確実に準拠す

るため、特定の顧客の与信限度に対して範囲チェックを実施することもできる。

チェックディジットも入力妥当性の一つである。これは、銀行口座番号などの数値にお

ける変換ミスを発見するために有効な手段である。チェックディジットは、元のデータ

が変更されたり、誤ったりすることなく、有効な数値に変換されていることを確認する

ために、数学的に計算され、データに追加されるものである。たとえば、銀行の口座番

号をユーザが入力する場合に、その口座番号の妥当性を確認するため、チェックディジ

ットが一般的に利用されている。

ユーザによる入力を必要としないアプリケーションの場合（EDI やインターフェースを

介してアプリケーションに情報が自動的に入力される場合など）、入力妥当性コントロ

ールにより、情報の網羅性の確認ならびに重複がないかどうかのチェックが行われる。

たとえば、番号管理のコントロール（請求書番号など）を利用し、データファイル内に

レコードの漏れまたは重複がないかどうかをチェックすることができる。


図 21 ―アプリケーション統制の種類と COBIT のアプリケーション統制目標とのマッピング


コントロールの種類

AC

1

ソースデータの準備と許可

AC

2

ソースデータの収集と入力

AC

3

正確性、網羅性および真正性のチェック

AC

4

処理のインテグリティと妥当性

AC

5

出力のレビュー、調整およびエラー処理

AC

6

トランザクションの認証とインテグリティ

入力コントロール

入力妥当性コントロール P S S

入力時の例外報告とそのハンドリング S P S

処理コントロール

ロジカルコントロール P S

処理の検証コントロール P P

処理時の例外報告とそのハンドリング P P

出力コントロール

出力結果の検証コントロール S S P

出力時の例外報告とそのハンドリング S S P

出力結果の配布コントロール P

出力結果の保持と保管コントロール P

境界コントロール

情報保護と認証コントロール P P S P P P

職務分離コントロール P P S S S S

インタフェースコントロール P S P P

監査証跡コントロール

監査証跡 S S S S

P ＝主要な実現要因、S ＝副次的な実現要因


入力時の例外レポートとそのハンドリング

入力エラーは、適時かつ適切な方法で発見され、修正されるべきである。入力時の例外

レポートとそのハンドリングのコントロールとして、ユーザに対してエラーと解決策を

示す警告メッセージを表示することが考えられる。また、例外が発生した場合にプロセ

スが次のプロセスへ移動しないようにその処理を止めることが考えられる。事前に想定

している動作、例外の重要度と種類に応じて対応方法は異なる。コントロールを有効か

つ効率的なものとするために、この点を設計から運用の全体を通じて十分に考慮してお

く必要がある。

たとえば、顧客マスタの作成時に顧客の E メールアドレスの欄が空欄のままになってい

る場合に、警告メッセージがポップアップ表示されることが考えられる。ただし、（E

メールアドレスを入力しなかった場合）ユーザは警告メッセージを認識した上で顧客マ

スタを作成することができる。また、顧客への請求書発行時に、ユーザは顧客マスター

ファイルで設定された与信限度額を超えて入力ができないようになっている。

アプリケーションが発見した入力エラーを含む例外トランザクションは、例外ファイル

に書き込まれるようにすべきである。エラーを修正するために必要な処理を行う担当者

は、例外トランザクションをレビューする。上長は、例外トランザクションが適時に解

消されたことを確実にするために例外ファイルをレビューする。さらにアプリケーショ

ン統制の修正やアプリケーションの例外メッセージ/文書化の修正あるいは改善トレー

ニングが必要となる継続的な例外トランザクションを識別するために、例外ファイルは

マネジメント層によるレビューが行われるべきである。これは、ハイブリッドのアプリ

ケーション統制の例である。

処理段階

この段階のコントロールは、アプリケーション処理のインテグリティおよび信頼性の確

保に役立つ 22。このコントロールによって、有効な処理ルールに従ったアプリケーショ

ン処理の結果として、データ更新が行われた場合に、アプリケーションのデータの網羅

性と正確性が維持されていることが担保される。

プログラミングロジック

ロジックコントロールは、データが予め定められた（ビジネス）ロジックに従って確実

に処理されるように、アプリケーションの中に組み込まれたコントロールである。発注

22 ISACA、『CISA Review Manual 2009 』、米国、2008 年


書、物品の受領書および請求書に対する 3-way-match 機能を備えた購買アプリケーショ

ンの場合を例に挙げると、請求書とそれに対応する発注書や物品の受領書が予め定めら

れた許容値を超えている場合は、請求書照合の転記や支払がブロックされる。しかしな

がら、請求書の金額の正当性が確認されると、自動的に転記が行われる。また、予め定

められた支払期限を超過した請求書については、承認のため経営層に自動に送ることが

できる。

処理の検証

処理のステップが正確に実行されていることを検証するために、データの処理中に中間

チェックが実行される場合がある。これらのチェックは、処理の検証のコントロールと

して知られている。この目的に利用されるものとしては、以下の 2 つの手法がある。

・ランツーランの合計 ― これによって、アプリケーションの処理段階を通じてデー

タの値を検証できる。ランツーランの合計による検証によって、アプリケーション

に読み込まれるデータが全て受け入れられ、その後更新プロセスに流れたことが担

保される 23。たとえばテレコム環境では、課金アプリケーションにおいてすべての

有効な通話が課金されるようにするためにランツーランの合計が使われることがあ

る。

・リミットまたは許容範囲のチェック ― このチェックにより計算エラーが予防す

ることができる。計算した金額を予め定められていたリミットや許容範囲に照らし

てチェックを行う。たとえば、給与支払アプリケーションにおいて従業員の月給を

計算する際、計算された小計（社会負担額や所得税など）を予め規定した許容範囲

に照らして、チェックを行い、異常な値があれば、それ以降の処理をブロックする。

処理の例外レポートとそのハンドリング

コントロールにより発見された要件を満たさない処理済みのトランザクションまたは

レコードを、サスペンドトランザクションファイルとして作成される場合がある。この

ファイルは、一般的に「リジェクトアイテム」ファイルあるいは「サスペンド」ファイ

ルと呼ばれる。拒否されたこれらのトランザクションは、予め決められた担当者による

修正やレビューが行われ、アプリケーションによって自動的に再処理される。その場合、

23 米国連邦金融機関検査協議会（FFIEC）、Development and Acquisition Booklet（開発と取得ブックレット）、

米国、2004 年、www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html。これは、『1996 FFIEC Information Systems

Handbook（1996 年版 FFIEC 情報システムハンドブック）』を改訂する一連のブックレットの 1 つである。

このブックレットで、第 12 章が破棄され、審査官および金融機関に対し、開発および取得のリスクを明確

化しコントロールするためのガイダンスが提供されている。


再処理の前に当該担当者がトランザクションに対して必要な調整を行う場合がある。

（発注書が在庫不足により処理されなかった場合など）

出力段階

出力段階におけるコントロールによって、アプリケーションが提供するデータが（アプ

リケーションのロジックに従って）正確であり、一貫したセキュアな方法で、書式が整

えられ、提供されることが担保できる 24。

出力結果の検証

アプリケーション処理結果の正確性と妥当性を、出力結果の検証コントロールを利用し

て検証することができる。これらのコントロールは、以下のような手法により、アプリ

ケーション内の処理ステップ結果をテストすることができる 25。

・妥当性の検証 ― 処理結果が予め定められた妥当な値の範囲に合致しているかど

うかの確認が行われる。範囲に合致しない場合、拒否されるか、手作業によるレビ

ューの対象となる。たとえば、給与支払アプリケーションによって計算された月給

の手取額の妥当性を前月の手取額と比較する。現在の月の数字が前月の数字の一定

の割合から外れている場合は、拒否され、レビューが行われる。

・比較と照合 ― 入力されたデータ（発注の合計金額および処理された項目の総数な

ど）に基づいてコントロール合計を計算し、そのコントロール合計と出力結果を比

較し、網羅性と正確性を確認する。この方法は、バッチ処理の結果の確認に特に有

効である。たとえば、ある企業ではオンラインオーダー入力システムに入力された

トランザクションの総数と課金システムに送信されたトランザクションの数の一致

を自動的に検証している。

出力結果の例外レポートとそのハンドリング

出力結果の検証コントロールによって拒否された場合、例外ファイルおよびレポートが

生成される場合がある。これは、入力または処理のエラーをリストアップするために生

成されるファイルやレポートと同様のものである。このファイルとレポートにより、処

理結果の更なる分析が可能となる。また、入力データの再処理が必要となる場合もある。

上長は、例外トランザクションが適時に解消されたことを確実にするために例外ファイ

ルをレビューする。さらにアプリケーション統制の修正やアプリケーションの例外メッ

セージ/文書化の修正あるいは改善トレーニングが必要となる継続的な例外トランザク

24 前述の ISACA、『CISA Review Manual 2009 』

25 同上


ションを識別するために、例外ファイルはマネジメント層によるレビューが行われるべ

きである。

出力結果の配布

出力結果の配布のコントロールは、承認された配布パラメータに従って出力結果が確実

に配布されることに役立つ。自動化された配布リストおよび電子的に保存あるいはプリ

ンターにスプールされた情報へのアクセス制限などが、配布のコントロールの例である26。

出力結果の保管と保持

出力結果の保管と保持のコントロールの目的は、出力結果をセキュアに保管し、保持（あ

るいは破棄）することである。たとえば、レコードの保持スケジュールの利用が考えら

れる。その場合、適用される管理法規を保持ポリシーに盛り込む必要がある。保持期間

の経過後は、出力結果を適切に破棄し、不正な開示を防止しなければならない。

プロセスの境界

境界コントロールとは、（入力、処理あるいは出力といった）アプリケーションの特定

の処理段階に関係せず、アプリケーションの境界線上で機能し、情報が正確かつ完全に

送受信されていることおよび不正なアクセスから保護されていることを担保するため

のコントロールである。

情報保護と認証

情報保護と認証のコントロールは、一般的に、データの機密性およびインテグリティ、

ならびにデータやアプリケーションの利用可能性を達成するために使用される。これら

のコントロールは、情報セキュリティに関わる IT 全般統制に関連しており、以下の 3

つの部分で構成される。

・ベーシックアプリケーションセキュリティ ― これは、アプリケーションの認証の

仕組みやパスワードのパラメータ、ユーザのタイムアウト設定などに関連するコン

トロールである。たとえば、企業の ERP アプリケーションでは、厳格なパスワード

パラメータ（パスワードの長さ 8 文字以上、パスワードの長有効期間 30 日間、複

雑性対応など）と 30 分間利用しないユーザのセッションタイムアウトが求められる

場合がある。

26 前述の FFIEC、『Development and Acquisition Booklet 』


・権限プロファイルを介したアプリケーション機能へのユーザのアクセス ―権限プ

ロファイルによって、データの入力および操作、トランザクションの実行および出

力結果照会の実行権限を承認された個別グループに制限することができる。

・情報保護の手法 ― （暗号化などの）情報保護の手法は、一般的に送信中あるいは

コンピュータ上に保存されているデータを不正な閲覧や操作から保護するため、あ

るいはデータ内容のインテグリティを確保するために利用される。

データをアプリケーション間で確実にやり取りする場合は、送信元の真正性を確認し、

受信したデータが承認されたソースから、可能であれば暗号キーを利用して送られたも

のであることを確認する必要がある。このリスクは、ERP アプリケーションなど、同じ

アプリケーション内でデータを処理する際は、比較的低いものとなる。

職務分離

1人の人が複数の重要度の高い機能に責任を持つことによるエラーや不正が発生する可

能性や、それが通常の（業務）プロセスの流れの中でタイムリーに発見されない可能性

を職務分離によって防ぐことができる。27。

職務分離のコントロールは、通常権限プロファイルによってアプリケーションに組み込

まれている。職務の分離が必要なユーザにはそれぞれ異なる権限プロファイルが割当て

られ、それぞれがアプリケーション内で相いれないアクションを実行できないようにす

る。たとえば、財務アプリケーションでは、発注書の入力/承認、物品の受領書の計上、

サプライヤーからの請求書の計上、および支払の実施といった支払サイクルにおいて、

1 人のユーザがすべてのトランザクションにアクセスできないようにする必要がある。

これは、支払サイクル内のユーザに対して異なる権限プロファイルを割当てることによ

って実現できる。

インターフェース

アプリケーション間でデータが正確かつ完全に転送されることを確実にするために、イ

ンタフェースコントロールを導入すべきである。たとえば、これはインターフェースさ

れるデータファイルのヘッダ詳細にコントロールトータルを組み込むことで実現する

ことができる。購買アプリケーションによって支払ファイルのヘッダ詳細に支払件数の

総数および支払額の総計を作成し、この支払ファイルは支払処理実行のために電子支払

アプリケーションに転送を行う。支払ファイルの処理前に、電子支払アプリケーション

は支払ファイルに含まれている支払件数の総数と合計金額を再計算し、この値を支払フ

ァイルのヘッダ詳細に含まれている値と比較する。



値が一致しなければ、支払ファイルは拒否され、処理は行われない。

監査証跡とアプリケーションのログ収集

監査証跡およびログ収集よって、トランザクション処理の流れについて再構築や再追跡

が可能となる。これにより、発生時点からファイルを更新する時点までの実際のトラ

ンザクションの流れを再生することができる 28。また、間違ったトランザクションの調

査および修正、ならびにデータ照合に役立つ情報が提供される。たとえば、会計アプリ

ケーションには、ユーザが実行する機密性の高いすべてのトランザクション（会計期間

テーブルの保守、総勘定元帳（ＧＬ）勘定の作成など）のログが含まれている。多くの

アプリケーションシステムにおけるアプリケーションのログ収集のレベルおよび程度

を決定することは、一般的に難しいものであると考えられる。主な理由として、すべて

のアプリケーションに広く利用できる標準化されたフォーマットが存在しないことが

考えられる。SYSLOGS、IDS アラート、ウェブサーバなどにおいては標準化されたフ

ォーマットが存在するが、アプリケーションのログ収集に関する標準化されたフォーマ

ット（データおよびメタデータ）は存在しない。アプリケーションのログ収集は、ビジ

ネス要件を完全に理解していることが重要であり、これは、統合された（業務および技

術の）リスクアセスメントおよび規制、セキュリティおよびコンプライアンスの要件の

分析によって決定される。これらの要件を、アプリケーションまたはシステムに関する

アプリケーション統制の設計および導入に盛り込むべきである。


付録 C ―重要な会計アプリケーションにおける職務分離


付録 C ―重要な会計アプリケーションにおける職務分離 29

企業のコントロール活動が内部統制の目標達成において有効かどうかを判断する際、適

切な職務分離は重要な検討事項である。職務分離の基盤となる基本的コンセプトは、通

常の職務の流れにおいて、従業員によるエラーや不正を防止し、かつそれを隠すことが

できないようにするというものである。一般的に、分離すべき職務は以下の通りである。

・資産に影響する関連トランザクションに対する権限または承認

・資産の管理

・関連トランザクションの記録または報告

従来型の内部統制システムでは、これらの職務を別々の個人に割当てるか、両立すべき

でない機能を分離することで対応してきた。このような職務分離は、ある人物が資産へ

のアクセスと、その資産の保持に関する説明責任の両方を有する状況を防ぐためのもの

である。IT 環境においては、機能の分離が IT 全般統制に不可欠なコンポーネントとし

て捉えられ、テストされている。たとえば、企業は、プログラムを本番機に移送できる

権限を承認された個人に制限するようなコントロールを導入している。同様に、通常、

システムおよびデータへのアクセスの要求と許可について職務分離を実施している。

ただし、適切な職務分離は、アプリケーション/業務プロセスレベルでも非常に重要で

ある。たとえば、在庫管理システムにおいては、以下の職務の責任者はそれぞれ異なる

人物が担当している。

・購入の開始または依頼

・発注書の発行および入力

・物品の受領

・在庫の現物管理

・廃棄またはスクラップの承認を含めた在庫の記録、およびコスト、数量に対する調

整の承認

・在庫マスターファイルの変更

29 IT ガバナンス協会の発行物、『IT Control Objectives for Sarbanes-Oxley （サーベンスオクスリー法（企業

改革法）遵守のための IT 統制目標） ― The Role of IT in the Design and Implementation of Internal Control Over

Financial Reporting, 2nd Edition,（財務報告をめぐる内部統制の設計および導入における IT の役割、第 2 版）』、

米国、2006 年。ここでは財務アプリケーションに焦点が当てられているが、職務分離はあらゆる種類のア

プリケーションに適用されることに注意する。


・棚卸しの実施

・棚卸し差異へのフォローアップ

・生産依頼や材料の移動の承認

・生産工程における物品の受領と転送

・物品の出荷

多くの企業が直面している課題は、アプリケーションレベルでの両立すべきでない職務

を明確にすることである。レガシーシステム環境では、その周辺で手作業によるコント

ロールのフレームワークがあるため、必然的に職務が分離されていた。レガシーシステ

ムすなわち購買システム、在庫システムおよび総勘定元帳システムが断片的に稼働して

いる場合、職務が分離されていた。しかし、完全に自動化された ERP システム環境で

は、職務分掌に関する従来の考え方を改善していく必要がある。ERP システムでは、ユ

ーザは複数のビジネス機能にアクセスが可能であり、物理的資産を管理し、コンピュー

ティングや会計システムにその移動を直接記録することが可能であるため、ユーザの権

限強化を重視するようにシフトしてきた。職務分掌コントロールは、リスクマネジメン

トの観点とトレードオフのバランスを考慮し、設計する必要がある。業務プロセスレベ

ルにおける職務分離を明確にするため、さまざまなアプローチがあり、以下は、企業が

それぞれの環境で活用/適用できるツール/テンプレートの 2 つの例である。図 22 のテン

プレート 1 はレガシーシステムに適用可能であり、図 23 のテンプレート 2 は統合シス

テムに適用可能である。

図 22 は、販売アプリケーションに関連してコンフリクトする職務に注目したアプロー

チの説明である。財務報告に盛り込まれる他の重要なアプリケーションに関しても、同

様の文書を作成する必要がある。リストにあるアプリケーション内の各機能に対して責

任者の名前を記述することで、テンプレートが完成する。機能がコンピュータアプリケ

ーションによって実行されている場合は、該当欄に「コンピュータ」または「IT」と入

力すればよい。


図 22 ― 職務分離分析表の例：販売

販売アプリケーション

承認現物管理記録

コントロール活動

受注の登録信用および与信限度額の承認与信関連のデータファイルへのアクセスの承認出荷の許可出荷書類の作成出荷に備えた在庫の取り扱い請求書の作成請求書の正確性の確認価格関連のデータファイルへのアクセスの承認標準価格に対する変更の承認請求書の網羅性の確認販売レコードの保持売掛金レコードの保持出荷と請求書の照合売掛金レコードと総勘定元帳との照合

それぞれ重要なアプリケーションに対して、職務分掌に関するフォームに記入した後、

担当者がコンフリクトする職務を実行している場合はいつでも、それをレビューできる

ようにする。また、ある担当者が複数のカテゴリー（承認、現物管理あるいは記録／報

告）にある職務を実行している場合や自らが記録／報告に関連するトランザクションの

コントロールの実施に責任がある場合は、そこに職務のコンフリクトが発生していると

考えられる。さらに、ある職務を実行する担当者が存在しない場合も、コントロールに

欠陥がある可能性がある。しかし、ある担当者が複数の欄の職務を実行しているからと

いって、必ずしも職務分離が不十分ということではない。また、企業は、同じカテゴリ

ー内の職務分離が十分でない可能性についても考慮しなければならない（与信の承認を

担当する人が貸倒損失の承認もおこなっている場合など）。

ある担当者が、対立する職務を実行しているということが明らかになった場合、職務分

離が十分でないため、その担当者が実行しているすべての職務の有効性が損なわれたり

排除されたりしていないかを判断する必要がある。有効性に対して影響を及ぼす場合、

次の段階で、関連するアプリケーションに対するコントロールへの影響、およびエラー

または不正が発生するリスクに対処していく。リスクの増加が識別された場合、企業は

そのリスクを予防または発見する他のコントロールを検討し、その有効性を評価しなけ

ればならない。追加のコントロールが識別されない場合、職務分離が十分でないため、

報告エラーのリスクが増大する可能性がある。


職務分離を評価するための 2 つ目のアプローチは、業務プロセス機能をリスト化したマ

トリックスを活用することである。マトリックスでは、同一人物が実行しても矛盾が生

じず、対立しない機能が示される。サーベインスオクスリー法第 404 条のコンプライア

ンスの一環として、多くの企業がリスクマネジメントの観点と職務上のアクセスとセキ

ュリティとのトレードオフを反映させた職務分離に関するマトリックスを作成してい

る。権限の付与と不正や未承認のトランザクションのリスクを小限に抑える必要性と

のトレードオフを適切に考慮し、企業内の各業務プロセスに合わせてこのようなテンプ

レートをモデリングする必要がある。図 23 は、このコンセプトを購買・支払業務に適

用した場合の例である。この例では、経営層の対立する職務の定義に基づき、対立する

職務を「x」で示している。

図 23 ― 職務分離分析表の例：購買・支払

機能

機能

仕入先マスタの登録と変更

購買発注伝票の承認／リリース

入庫処理

仕入先請求書登録

支払処理

支払ブロックの解除

仕入先デビッドメモの登録

仕入先マスタの登録と管理 x x x

購買発注伝票の承認／リリース x x x

入庫処理 x x x

仕入先請求書登録 x x x

支払処理 x x

支払ブロックの解除 x x

仕入先デビッドメモの登録 x x

職務分離のテストを自動化する具体的な手法については、本書の対象範囲外である。し

かし、まずはシステムそのものの中ですでに利用できるレポートを検討することが起点

となる。レビューおよびテストプロセスを出来るだけ自動化するためにソフトウェアの

利用について検討することも考えられる。自動化されたツールを利用して職務分離をテ


ストする場合は、データの網羅性（すべてのユーザ、プロファイルおよび権限が分析に

盛り込まれていること）およびデータの正確性（権限プロファイルが適切に各ユーザへ

割り当てられていること）に注意を払う必要がある。

付録 D ― アプリケーション統制の目標達成のための

コントロールプラクティス、価値および

リスクのドライバー


付録 D ― アプリケーション統制の目標達成のためのコン

トロールプラクティス、価値およびリスクのドライバー

AC1 ソースデータの準備と許可

コントロール目標価値のドライバーリスクのドライバー

原始帳票が、定められた手続に従

い、該当文書の作成と承認に関する

職務分離を十分に考慮した上で、許

可を受けた資格のある要員によっ

て準備されていることを確認する。

入力ミスや入力漏れは、効果的な入

力フォームを作成することで最小

限に抑えることができる。入力ミス

や不正データを検出して、報告、訂

正できるようにする。

・データのインテグリティ

・標準化され承認されたト

ランザクション文書

・アプリケーションのパフ

ォーマンスの改善

・トランザクションデータ

の正確性

・重要なデータのインテグ

リティの毀損

・承認されていないトラン

ザクションもしくは間違

ったトランザクション

・処理の非効率性と手戻り

コントロールプラクティス

1. データが記録可能であり、ワークフローで制御され、その後のリファレンスチェックによって正確性

を高めることができるように原始帳票を設計する。必要に応じて、原始帳票の設計に網羅性コントロ

ールを盛り込む。

2. ソースデータの入力準備の手続を作成し、文書化する。それらを、許可を受けた資格のある要員に効

果的かつ正確に周知する。この手続では、必要な承認レベル（原始帳票の作成、編集、承認、決定お

よび却下）を作成し、明確にする必要がある。また、それぞれの取引タイプに応じて、利用する原始

メディアを明確にしておく必要がある。

3. データ入力に責任を負う部署は、許可された要員リスト（各人の署名付き）を確実に保持する。

4. すべての原始帳票には、標準的なコンポーネント（適時性、規定された入力コード、初期値など）を

盛り込み、適切に文書化したうえで、確実に経営層が承認する。

5. すべての取引に対して一意かつ連続した識別子（インデックス、日付および時刻など）を自動的に割

り当てる。

6. 適切に承認されていない、あるいは原始帳票が不完全あるため、修正が必要な原始帳票を提出元に差

し戻し、差し戻されたという事実をログに記録する。ログを定期的にレビューすることで、修正され

た帳票が適時に提出元に差し戻されていることの確認、またパターン分析の実施、根本的な原因の調

査が可能となる。


AC2 ソースデータの収集と入力


データ入力は、許可を受けた資格の

ある要員によってタイムリーに実

施されるように定める。誤入力され

たデータの訂正と再送信は、元のト

ランザクションの許可レベルを損

なうことのないように実施する。元

の原始文書は、復元時に必要となる

場合に備えて、一定期間にわたって

保存しておくようにする。

・正確なデータ入力と効率

的な処理

・適時に発見されるエラー

・機密性の高いトランザク

ションデータの保護

・不完全なデータ入力によ

る処理の非効率性


リティの毀損

・アクセスコントロール違

反

・発見されないデータ入力

のエラー


1. 原始帳票の適時性、網羅性および正確性に関する基準を定義し、周知する。その基準に則してデー

タ入力が確実に実施されるような仕組みを確立する。

2. 重要な取引には予め採番された原始帳票を使用する。取引において連番が要求されている場合は、

連番となっていない原始帳票を特定し、正しい番号を割り振る。網羅性がアプリケーション要件で

ある場合は、欠番となっている原始帳票を特定する。

3. トランザクションの入力、編集、承認、決定および却下、ならびにエラー対応の実施者を定義し、

それを周知する。アクセスコントロールを導入し、説明責任を果たすため、役割と責任の根拠とな

る証拠を記録する。

4. エラーの修正、回避および例外ケースへの対処、ならびに原始帳票およびトランザクションへの適

時のフォローアップ、修正、承認および再処理を行う手続を定義する。この手続では、エラーメッ

セージの説明文、エラーの回避条件およびエスカレーションレベルなどの項目について検討する必

要がある。

5. エラーが発生した時点で、適時にエラーメッセージを生成する。エラーが修正、適切に対応あるい

は回避されるまで、トランザクションを処理すべきではない。即時に修正できないエラーは自動的

に保留ログとして記録され、有効なトランザクションの処理を継続すべきである。エラーログを適

切な期間内にレビューし、特定の期間内に対処する。

6. エラーおよび例外ケースのレポートを適任者がレビューし、適切な期間内にフォローアップおよび

修正を行い、必要であればインシデントをより上のレベルに報告する。自動化されたモニタリング

ツールを使用して、エラーを明確化にし、モニタリングおよび管理を行う必要がある。

7. 原始帳票を、法規制要件あるいはビジネス要件を満たす十分な期間にわたって安全に保管する。（業

務あるいは IT のいずれかの部門が保管を担当する）


AC3 正確性、網羅性および真正性のチェック


・トランザクションの正確性、網

羅性、および妥当性を検証する。入

力したデータを確認し、可能な限り

原本に近づけて編集する、または修

正を求めるようにする。

・データ処理エラーの効率

的な修復

・処理の間、データの正確

性、網羅性および実現性

が維持される

・連続的なトランザクショ

ン処理

・データの入力と処理の職

務分離

・不完全であるか、無効であ

るか、もしくは不正確なデ

ータ入力による、処理の非

効率性および手戻り


リティの毀損

・発見されないデータ入力

のエラー

・承認されていないデータ

入力


1. オンラインセッション中、トランザクションデータを可能な限りデータ入力タイミングで、対話的

に検証する。マニュアル入力、システムによる自動生成またはインターフェースされた入力のいず

れの場合でも、トランザクションデータは、正確性、網羅性および妥当性のコントロールチェック

の対象として検証する。可能な限り、最初のエラー発見後にトランザクション妥当性を止めるので

はなく、効率的に修正するために分かりやすいエラーメッセージを即座に表示する。

2. データ入力の正確性、網羅性、妥当性および法規制要件へのコンプライアンスを検証するためのコ

ントロールを導入する。コントロールには、シーケンスチェック、リミットチェック、範囲チェッ

ク、妥当性チェック、合理性チェック、テーブル参照、存在チェック、キー検証、チェックディジ

ット、網羅性チェック（合計金額、合計件数、合計文書数、ハッシュトータルなど）、重複および

論理的関係チェック、およびタイムエディットなどが含まれる。妥当性の基準とパラメータは定期

的な見直しおよび確認が必要である。

3. 許可を受けた資格のある要員のみがデータの入力、修正および承認を行うように、アクセスコント

ロールおよび役割と責任の仕組みを構築する。

4. トランザクションデータの入力、修正および承認の職務分離ならびに妥当性ルールを定義し、自動

化されたコントロールおよび役割と責任のルールを導入する。

5. 妥当性の基準から外れたトランザクションを記録し、一時中断ファイルへ移動させる。すべてのエ

ラーを適時に報告し、有効なトランザクション処理を遅延なく実施する。

6. エディット妥当性ルーチンでエラーになったトランザクションを、エラーが修正されるまでフォロ

ーアップの対象として検証する。根本的な原因分析のために、処理エラーに関する情報を保持し、

手続と自動化されたコントロールの調整に役立てる。


AC4 処理のインテグリティと妥当性


処理サイクルを通じて、データのイ

ンテグリティと妥当性を維持する。

誤りのあるトランザクションが検

出されても、有効なトランザクショ

ンの処理は中断されない。

・処理のエラーが適時に

発見される

・問題調査能力

・エラーや不正の不十分な証

拠

・データ入力エラーの見逃し

・承認されていないデータ処

理


1. トランザクション処理の開始を承認し、適切で承認されたアプリケーションとツールのみの使用を

強化するための仕組みを構築し、導入する。

2. 必要に応じて、自動化されたコントロールによる処理が完全かつ正確に実行されていることを定期

的に検証する。コントロールには、シーケンスおよび重複エラーのチェック、トランザクション/

レコードのカウント、参照インテグリティチェック、コントロールおよびハッシュトータル、範囲

チェックおよびバッファオーバーフローなどが含まれる。

3. 妥当性ルーチンではじかれたトランザクションを記録し、一時中断ファイルへ移動したことを検証

する。ファイルに有効なトランザクションと無効なトランザクションが含まれている場合、有効な

トランザクションの処理を遅延なく実施し、エラーを適時に報告する。根本的な原因分析のために、

処理の失敗に関する情報を保持し、手続きと自動化されたコントロールの調整に役立たせ、エラー

の早期発見または予防を確実なものとする。

4. 妥当性ルーチンではじかれたトランザクションを、エラーが修正されるまで、あるいはトランザク

ションがキャンセルされるまでフォローアップの対象として検証する。

5. ジョブの実行順序が文書化され、IT 運用部門に周知されていることを確認する。ジョブのアウトプ

ットには処理中にデータが不適切に追加、変更あるいは欠落しないように、後続のジョブに関する

十分な情報を確実に含んでいなければいけない。

6. すべてのトランザクションに対して一意かつシーケンシャルな識別子（インデックス、日付と時刻

など）があることを確認する。

7. 処理されたトランザクションの監査証跡を保持する。オンラインまたはバッチ処理に対して入力日

時およびユーザ ID を監査証跡に組み込む。機密性の高いデータに関しては、処理結果リストに処理

前後の画像を盛り込み、ビジネスオーナが変更の正確性を確認し、承認しなければならない。

8. システムおよびデータベースユーティリティによるデータ処理において、想定しない中断があって

も、データのインテグリティを保持する。運用上の問題解決のために処理の失敗あるいはシステム

やデータベースユーティリティを使用した場合のデータインテグリティを確認するためのコントロ

ールを確実に整備しておく。処理の前にすべての変更を報告し、ビジネスオーナの承認を得ておか

なければいけない。

9. トランザクションの修正、無効化、重要度の高い処理については、データ入力を実施していない管


コントロールプラクティス（続き）

理者が適切かつ迅速に詳細をレビューする。

10. ファイル合計を照合する。たとえば、トランザクション件数や金額をデータとして記録しているパ

ラレルコントロールファイルは、トランザクションの実行後にマスターファイルのデータと比較す

る必要がある。処理件数や合計金額に不整合がある場合は状況を明確にし、報告を行い、それに対

応する。

AC5 出力のレビュー、調整およびエラー処理


出力は、許可された方法によって扱

われ、適切な受領者に送付され、送

信中に保護されるように、手続とこ

れに伴う責任を定める。出力の正確

性について検証、検出、修正を行い、

また、出力から得られる情報を利用

できるように、手続とこれに伴う責

任を定める。

・機密性の高いデータ出

力の保護

・完全でエラーのない処

理結果の正しい受け手

への送付

・エラー発見の適時性

・機密性の高いトランザク

ションデータの間違った

受け手への送付

・データの機密性の毀損

・非効率なトランザクショ

ン処理

・トランザクションデータ

出力のエラーの見逃し


1. IT アプリケーションからの出力処理または出力結果の保管を行う場合、プライバシーやセキュリ

ティ要件を考慮し、定められた手続に従って行う。出力結果の配布の手続を定め、周知しそれに従

う。

2. 有価証券などの機密性の高い全ての出力結果については、適切な間隔で物理的な在庫を確認し、在

庫データと比較する。機密性の高い出力文書のうち、例外処理または拒否処理されたすべての理由

を説明するために、監査証跡による手続を作成する。

3. 出力が行われたヘッダのコントロールトータルや証跡レコードと、データ入力時にシステムが生成

したコントロールトータルの差額とを照合し、処理の網羅性と正確性を検証する。コントロールト

ータルが不一致の場合は、それを適切なレベルの経営層に報告する。

4. 他の操作を実行する前に処理の網羅性および正確性を検証する。電子的に出力された結果を再利用

する場合には、その後の利用の前に妥当性が行われる必要がある。

5. ビジネスオーナは、最終的な出力結果の適切性、正確性、網羅性のレビューおよび、情報管理基準

に準拠していることを検証する手続を定義し、導入する。潜在的エラーを報告し、ログを管理ツー

ルへ自動的に記録し、適時にエラーに対処する。

6. アプリケーションが機密性の高い出力結果を生成する場合は、受領者を定め、人や機械が認識でき

るようにラベリングし、それに従って配布する。必要に応じて、特別なアクセスコントロールが設

定された出力デバイスに送信する。


AC6 トランザクションの認証とインテグリティ


内部アプリケーションとビジネス

機能/運用上の機能（企業の内外を

問わず）の間でトランザクションデ

ータをやり取りする前に、データの

宛名が正しいかどうか、送信元の真

正性、および内容のインテグリティ

をチェックする。送信または移送の

間の真正性とインテグリティを維

持する。

・ストレート・スルー・プ

ロセッシング

・トランザクションの妥

当性と真正性に対する

信頼

・エラーと不正の防止

・間違いや未承認のトラン

ザクション

・トランザクションエラー

の見逃し

・非効率性と手戻り


1. トランザクションを電子的にやり取りする場合は、トランザクションのデータ転送方式、相互の責

任範囲および例外処理方法など、相互認証に必要な伝達および仕組みに関する基準を作成する。

2. 業界標準にしたがって、アプリケーションによって処理されたトランザクションの出力にタグを付

けることで、取引先企業との相互認証、否認防止に対する証拠提供となり、下流のアプリケーショ

ンが受領した内容のインテグリティ検証が可能となる。

3. 送信中のオリジナルデータの真正性およびインテグリティの維持のために、アプリケーションを処

理するその他のトランザクションから受け取った入力データを分析する。

付録 E ― アプリケーション統制の設計および導入の

ためのツール


付録 E ― アプリケーション統制の設計および導入のため

のツール

アプリケーション統制の要件の定義/関連するアプリケーション統制の目標の明確化

第 4 章では、新規のコンピュータ化対応策に関するビジネス要件の定義の一環として該

当するアプリケーション統制の明確化に対する経営層の責任を取り上げた。経営層は、

該当するアプリケーション統制の目標を決定するためのツールとして、COBIT オンラ

インを利用することができる。特定のコンピュータ化対応策に関するアプリケーション

統制の目標の重要性を明らかにし、それらを評価するために、COBIT オンラインをど

のように利用できるかを示した画面イメージが図 24 である。

□□

□□

□

証拠

関

連性

なし

ある

程度

関連

性が

ある

関連

性が

ある

非

常に

関連

性が

ある

不

可欠

他の

目標

でカ

バー

経

営層

が認

識し

てい

ない

経営

層が

認識

して

いる

経

営層

が解

決に

尽力

して

いる

導入

に着

手さ

れて

いる

導入

が順

調に

行わ

れて

いる

解

決策

が導

入さ

れて

いる

解決

策が

持続

して

いる

原始帳票が、定められた手続に従い、該当文書の作成と承認に関する職務分離を十分に考慮した上で、許可を受けた資格のある要員によって準備されているこ

とを確認する。入力ミスや入力漏れは、効果的な入力フォームを作成することで小限に抑えることができる。入力ミスや不正データを検出して、報告、訂正でき

るようにする。

便宜：中程度持続性：高

有効性：高

データ入力は、許可を受けた資格のある要員によってタイムリーに実施されるよう

に定める。誤入力されたデータの訂正と再送信は、元のトランザクションの許可レベルを損なうことのないように実施する。元の原始文書は、復元時に必要となる場

合に備えて、一定期間にわたって保存しておくようにする。

便宜：高持続性：高

有効性：高

トランザクションの正確性、網羅性、および妥当性を検証する。入力したデータを確認し、可能な限り原本に近づけて編集する、または修正を求めるようにする。

便宜：中程度

持続性：高有効性：高

重要でないある程度重要

重要非常に重要

不可欠

プロセス：AC ― アプリケーション統制企業にとっての重要性

図24 ― MyCOBITのコントロール目標評価フォーム

AC ― アプリケーション統制

コントロール目標：1.2. ソースデータの収集と入力

コントロール目標：1.3. 正確性、網羅性および真正性のチェック

関連性コンプライアンス状態

「C」＝現行、「P」＝計画中

コントロール目標：1.1. ソースデータの準備と許可

貢献：非常に高

労力：非常に高






□□

□□

□

証拠

関連

性な

し

あ

る程

度関

連性

があ

る

関

連性

があ

る

非常

に関

連性

があ

る

不可

欠

他

の目

標で

カバー

経営

層が

認識

して

いな

い

経

営層

が認

識し

てい

る

経営

層が

解決

に尽

力し

てい

る

導

入に

着手

され

てい

る

導

入が

順調

に行

われ

てい

る

解決

策が

導入

され

てい

る

解

決策

が持

続し

てい

る

処理サイクルを通じて、データのインテグリティと妥当性を維持する。誤りのあるトランザクションが検出されても、有効なトランザクションの処理は中断されない。

便宜：中程度

持続性：高有効性：高

出力は、許可された方法によって扱われ、適切な受領者に送付され、送信中に保

護されるように、手続とこれに伴う責任を定める。出力の正確性について検証、検出、修正を行い、また、出力から得られる情報を利用できるように、手続とこれに

伴う責任を定める。

便宜：中程度持続性：中程度

有効性：高

内部アプリケーションとビジネス機能/運用上の機能（企業の内外を問わず）の間でトランザクションデータをやり取りする前に、データの宛名が正しいかどうか、送

信元の真正性、および内容のインテグリティをチェックする。送信または移送の間の真正性とインテグリティを維持する。

便宜：中程度

持続性：中程度有効性：高

図24 ― MyCOBITのコントロール目標評価フォーム（続き）

AC ― アプリケーション統制

プロセス：AC ― アプリケーション統制企業にとっての重要性

重要でないある程度重要

重要非常に重要

不可欠

関連性コンプライアンス状態

「C」＝現行、「P」＝計画中

コントロール目標：1.6. トランザクションの認証とインテグリティ

コントロール目標：1.4. 処理のインテグリティと妥当性

コントロール目標：1.5. 出力のレビュー、調整およびエラー処理



貢献：高

労力：高

貢献：高

労力：高

アプリケーション統制の設計のためのテンプレート

図 25 は、アプリケーションソリューションの設計チームのメンバーがアプリケーショ

ン統制の設計を支援するのに役立つテンプレートの例である。このテンプレートは、そ

の個々の属性を含む、設計されたコントロールの主要素を把握し、コントロールが個々

のコントロール目標を果たすかどうかについての結論を提供するのに役立つ。コントロ

ール情報は、第 4 章で考察したように、アプリケーション統制の設計の正確性を確保す

る責任の一環としての経営層の見直しおよび承認を促進するような方法で提示される。

この表中にあるコントロールプラクティスは、『IT Assurance Guide: Using COBIT®（IT

統制の保証ガイド）』から提供されたものであり、各アプリケーションソリューション

の具体的要件を満たすように修正する必要がある。


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

1

1デ

ータ

が記

録可

能で

あり

、ワ

ーク

フロ

ーで

制御

さ

れ、

その

後の

リフ

ァレ

ンス

チェ

ック

によ

って

正確

性を

高め

るこ

とが

でき

るよ

うに

原始

帳票

を設

計す

る。

必要

に応

じて

、原

始帳

票の

設計

に網

羅性

コン

トロ

ール

を盛

り込

む。

2ソ

ース

デー

タの

入力

準備

の手

続を

作成

し、

文書

化す

る。

それ

らを

許可

を受

けた

資格

のあ

る要

員に

効

果的

かつ

正確

に周

知す

る。

この

手続

では

、必

要な

承認

レベ

ル（原

始帳

票の

作成

、編

集、

承認

、決

定

およ

び却

下）を

作成

し、

明確

にす

る必

要が

ある

。ま

た、

それ

ぞれ

の取

引タ

イプ

に応

じて

、利

用す

る原

始メ

ディ

アを

明確

にし

てお

く必

要が

ある

。

3デ

ータ

入力

に責

任を

負う

部署

は、

許可

され

た要

員リ

スト

（各

人の

署名

付き

）を確

実に

保持

する

。

4す

べて

の原

始帳

票に

は、

標準

的な

コン

ポー

ネン

ト

（適

時性

、規

定さ

れた

入力

コー

ド、

初期

値な

ど）を

盛り

込み

、適

切に

文書

化し

たう

えで

、確

実に

経営

層が

承認

する

。

5す

べて

の取

引に

対し

て一

意か

つ連

続し

た識

別子

（イ

ンデ

ック

ス、

日付

およ

び時

刻な

ど）を

自動

的に

割り

当て

る。

6適

切に

承認

され

てい

ない

、あ

るい

は原

始帳

票が

不完

全あ

るた

め、

修正

が必

要な

原始

帳票

を提

出元

に差

し戻

し、

差し

戻さ

れた

とい

う事

実を

ログ

に記

録す

る。

ログ

を定

期的

にレ

ビュ

ーす

るこ

とで

、修

正さ

れた

帳票

が適

時に

提出

元に

差し

戻さ

れて

いる

こと

の確

認、

また

パタ

ーン

分析

の実

施、

根本

的な

原因

の調

査が

可能

とな

る。

情報

要請

規準

設計

の有

効性

の結

論

ソー

スデ

ータ

の準

備と

許可

原始

帳票

が、

定め

られ

た手

続に

従い

、該

当文

書の

作成

と承

認に

関す

る職

務分

離を

十分

に考

慮し

た上

で、

許可

を受

けた

資格

のあ

る要

員に

よっ

て準

備さ

れて

いる

こと

を確

認す

る。

コン

トロ

ール

目標

とコ

ント

ロー

ルプ

ラク

ティ

スの

説明

コン

トロ

ール

活動

の属

性

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

参照

情報

目標


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

2

1原

始帳

票の

適時

性、

網羅

性お

よび

正確

性に

関す

る基

準を

定義

し、

周知

する

。そ

の基

準に

則し

てデ

ータ

入力

が確

実に

実施

され

るよ

うな

仕組

みを

確

立す

る。

2重

要な

取引

には

予め

採番

され

た原

始帳

票を

使用

する

。取

引に

おい

て連

番が

要求

され

てい

る場

合

は、

連番

とな

って

いな

い原

始帳

票を

特定

し、

正し

い番

号を

割り

振る

。網

羅性

がア

プリ

ケー

ショ

ン要

件

であ

る場

合は

、欠

番と

なっ

てい

る原

始帳

票を

特定

する

。

3ト

ラン

ザク

ショ

ンの

入力

、編

集、

承認

、決

定お

よび

却下

、な

らび

にエ

ラー

対応

の実

施者

を定

義し

、そ

れを

周知

する

。ア

クセ

スコ

ント

ロー

ルを

導入

し、

説明

責任

を果

たす

ため

、役

割と

責任

の根

拠と

なる

証

拠を

記録

する

。

4エ

ラー

の修

正、

回避

およ

び例

外ケ

ース

への

対処

、な

らび

に原

始帳

票お

よび

トラ

ンザ

クシ

ョン

への

適

時の

フォ

ロー

アッ

プ、

修正

、承

認お

よび

再処

理を

行う

手続

を定

義す

る。

この

手続

では

、エ

ラー

メッ

セー

ジの

説明

文、

エラ

ーの

回避

条件

およ

びエ

スカ

レー

ショ

ンレ

ベル

など

の項

目に

つい

て検

討す

る必

要が

ある

。

5エ

ラー

が発

生し

た時

点で

、適

時に

エラ

ーメ

ッセ

ー

ジを

生成

する

。エ

ラー

が修

正、

適切

に対

応あ

るい

は回

避さ

れる

まで

、ト

ラン

ザク

ショ

ンを

処理

すべ

き

では

ない

。即

時に

修正

でき

ない

エラ

ーは

自動

的に

保留

ログ

とし

て記

録さ

れ、

有効

なト

ラン

ザク

ショ

ン

の処

理を

継続

すべ

きで

ある

。エ

ラー

ログ

を適

切な

期間

内に

レビ

ュー

し、

特定

の期

間内

に対

処す

る。

コン

トロ

ール

目標

と

コン

トロ

ール

プラ

クテ

ィス

の説

明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

ソー

スデ

ータ

の収

集と

入力

デー

タ入

力は

、許

可を

受け

た資

格の

ある

要員

によ

って

タイ

ムリ

ーに

実施

され

るよ

うに

定め

る。

誤入

力さ

れた

デー

タの

訂正

と再

送信

は、

元の

トラ

ンザ

クシ

ョン

の許

可レ

ベル

を損

なう

こと

のな

いよ

うに

実施

する

。元

の原

始文

書は

、復

元時

に必

要と

なる

場合

に備

えて

、一

定期

間に

わた

って

保存

して

おくよ

うに

する

。

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

2

続き

6エ

ラー

およ

び例

外ケ

ース

のレ

ポー

トを

適任

者が

レ

ビュ

ーし

、適

切な

期間

内に

フォ

ロー

アッ

プお

よび

修正

を行

い、

必要

であ

れば

イン

シデ

ント

をよ

り上

のレ

ベル

に報

告す

る。

自動

化さ

れた

モニ

タリ

ング

ツー

ルを

使用

して

、エ

ラー

を明

確化

にし

、モ

ニタ

リン

グ

およ

び管

理を

行う

必要

があ

る。

77. 原

始帳

票を

、法

規制

要件

ある

いは

ビジ

ネス

要件

を満

たす

十分

な期

間に

わた

って

安全

に保

管す

る。

（業

務あ

るい

はIT

のい

ずれ

かの

部門

が保

管を

担当

する

）

AC

3

1オ

ンラ

イン

セッ

ショ

ン中

、ト

ラン

ザク

ショ

ンデ

ータ

を

可能

な限

りデ

ータ

入力

タイ

ミン

グで

、対

話的

に検

証す

る。

マニ

ュア

ル入

力、

シス

テム

によ

る自

動生

成ま

たは

イン

ター

フェ

ース

され

た入

力の

いず

れの

場合

でも

、ト

ラン

ザク

ショ

ンデ

ータ

は、

正確

性、

網

羅性

およ

び妥

当性

のコ

ント

ロー

ルチ

ェッ

クの

対象

とし

て検

証す

る。

可能

な限

り、

初の

エラ

ー発

見後

にト

ラン

ザク

ショ

ンバ

リデ

ーシ

ョン

を止

める

ので

はな

く、

効率

的に

修正

する

ため

に分

かり

やす

いエ

ラー

メッ

セー

ジを

即座

に表

示す

る。

2デ

ータ

入力

の正

確性

、網

羅性

、妥

当性

およ

び法

規制

要件

への

コン

プラ

イア

ンス

を検

証す

るた

めの

コン

トロ

ール

を導

入す

る。

コン

トロ

ール

には

、シ

ー

ケン

スチ

ェッ

ク、

リミ

ット

チェ

ック

、範

囲チ

ェッ

ク、

妥当

性チ

ェッ

ク、

合理

性チ

ェッ

ク、

テー

ブル

参照

、存

在チ

ェッ

ク、

キー

検証

、チ

ェッ

クデ

ィジ

ット

、網

羅性

チェ

ック

（合

計金

額、

合計

件数

、合

計文

書数

、ハ

ッ

シュ

トー

タル

など

）、重

複お

よび

論理

的関

係チ

ェッ

ク、

およ

びタ

イム

エデ

ィッ

トな

どが

含ま

れる

。バ

リ

デー

ショ

ンの

基準

とパ

ラメ

ータ

ーは

定期

的な

見直

しお

よび

確認

が必

要で

ある

。

3許

可を

受け

た資

格の

ある

要員

のみ

がデ

ータ

の入

力、

修正

およ

び承

認を

行う

よう

に、

アク

セス

コン

ト

ロー

ルお

よび

役割

と責

任の

仕組

みを

構築

する

。

コン

トロ

ール

目標

とコ

ント

ロー

ルプ

ラク

ティ

スの

説明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照

正確

性、

網羅

性お

よび

真正

性の

チェ

ック

トラ

ンザ

クシ

ョン

の正

確性

、網

羅性

、お

よび

妥当

性を

検証

する

。入

力し

たデ

ータ

を確

認し

、可

能な

限り

原本

に近

づけ

て編

集す

る、

また

は修

正を

求め

るよ

うに

する

。


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

3

続き

4ト

ラン

ザク

ショ

ンデ

ータ

の入

力、

修正

およ

び承

認の

職務

分離

なら

びに

バリ

デー

ショ

ンル

ール

を定

義

し、

自動

化さ

れた

コン

トロ

ール

およ

び役

割と

責任

のル

ール

を導

入す

る。

5バ

リデ

ーシ

ョン

の基

準か

ら外

れた

トラ

ンザ

クシ

ョン

を記

録し

、一

時中

断フ

ァイ

ルへ

移動

させ

る。

すべ

ての

エラ

ーを

適時

に報

告し

、有

効な

トラ

ンザ

クシ

ョ

ン処

理を

遅延

なく実

施す

る。

6エ

ディ

ット

バリ

デー

ショ

ンル

ーチ

ンで

エラ

ーに

なっ

たト

ラン

ザク

ショ

ンを

、エ

ラー

が修

正さ

れる

まで

フォ

ロー

アッ

プの

対象

とし

て検

証す

る。

根本

的な

原因

分析

のた

めに

、処

理エ

ラー

に関

する

情報

を

保持

し、

手続

と自

動化

され

たコ

ント

ロー

ルの

調整

に役

立て

る。

AC

4

1ト

ラン

ザク

ショ

ン処

理の

開始

を承

認し

、適

切で

承認

され

たア

プリ

ケー

ショ

ンと

ツー

ルの

みの

使用

を強

化す

るた

めの

仕組

みを

構築

し、

導入

する

。

2必

要に

応じ

て、

自動

化さ

れた

コン

トロ

ール

によ

る処

理が

完全

かつ

正確

に実

行さ

れて

いる

こと

を定

期的

に検

証す

る。

コン

トロ

ール

には

、シ

ーケ

ンス

およ

び重

複エ

ラー

のチ

ェッ

ク、

トラ

ンザ

クシ

ョン

/レコ

ード

のカ

ウン

ト、

参照

イン

テグ

リテ

ィチ

ェッ

ク、

コン

ト

ロー

ルお

よび

ハッ

シュ

トー

タル

、範

囲チ

ェッ

クお

よび

バッ

ファ

オー

バー

フロ

ーな

どが

含ま

れる

。

3バ

リデ

ーシ

ョン

ルー

チン

では

じか

れた

トラ

ンザ

ク

ショ

ンを

記録

し、

一時

中断

ファ

イル

へ移

動し

たこ

と

を検

証す

る。

ファ

イル

に有

効な

トラ

ンザ

クシ

ョン

と無

効な

トラ

ンザ

クシ

ョン

が含

まれ

てい

る場

合、

有効

なト

ラン

ザク

ショ

ンの

処理

を遅

延な

く実

施し

、エ

ラー

を適

時に

報告

する

。根

本的

な原

因分

析の

た

めに

、処

理の

失敗

に関

する

情報

を保

持し

、手

続き

と自

動化

され

たコ

ント

ロー

ルの

調整

に役

立た

せ、

エラ

ーの

早期

発見

また

は予

防を

確実

なも

のと

す

る。

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照

コン

トロ

ール

目標

と

コン

トロ

ール

プラ

クテ

ィス

の説

明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）

処理

のイ

ンテ

グリ

ティ

と妥

当性

処理

サイ

クル

を通

じて

、デ

ータ

のイ

ンテ

グリ

ティ

と妥

当性

を維

持す

る。

誤り

のあ

るト

ラン

ザク

ショ

ンが

検出

され

ても

、有

効な

トラ

ンザ

クシ

ョン

の処

理は

中断

され

ない

。


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

4

続き

4バ

リデ

ーシ

ョン

ルー

チン

では

じか

れた

トラ

ンザ

ク

ショ

ンを

、エ

ラー

が修

正さ

れる

まで

、あ

るい

はト

ラン

ザク

ショ

ンが

キャ

ンセ

ルさ

れる

まで

フォ

ロー

アッ

プ

の対

象と

して

検証

する

。

5ジ

ョブ

の実

行順

序が

文書

化さ

れ、

IT運

用部

門に

周

知さ

れて

いる

こと

を確

認す

る。

ジョ

ブの

アウ

トプ

ット

には

処理

中に

デー

タが

不適

切に

追加

、変

更あ

る

いは

欠落

しな

いよ

うに

、後

続の

ジョ

ブに

関す

る十

分な

情報

を確

実に

含ん

でい

なけ

れば

いけ

ない

。

6す

べて

のト

ラン

ザク

ショ

ンに

対し

て一

意か

つシ

ー

ケン

シャ

ルな

識別

子（イ

ンデ

ック

ス、

日付

と時

刻な

ど）が

ある

こと

を確

認す

る。

7処

理さ

れた

トラ

ンザ

クシ

ョン

の監

査証

跡を

保持

す

る。

オン

ライ

ンま

たは

バッ

チ処

理に

対し

て入

力日

時お

よび

ユー

ザー

IDを

監査

証跡

に組

み込

む。

機

密性

の高

いデ

ータ

に関

して

は、

処理

結果

リス

トに

処理

前後

の画

像を

盛り

込み

、ビ

ジネ

スオ

ーナ

ーが

変更

の正

確性

を確

認し

、承

認し

なけ

れば

なら

な

い。

8シ

ステ

ムお

よび

デー

タベ

ース

ユー

ティ

リテ

ィに

よる

デー

タ処

理に

おい

て、

想定

しな

い中

断が

あっ

て

も、

デー

タの

イン

テグ

リテ

ィを

保持

する

。運

用上

の

問題

解決

のた

めに

処理

の失

敗あ

るい

はシ

ステ

ム

やデ

ータ

ベー

スユ

ーテ

ィリ

ティ

を使

用し

た場

合の

デー

タイ

ンテ

グリ

ティ

を確

認す

るた

めの

コン

トロ

ー

ルを

確実

に整

備し

てお

く。

処理

の前

にす

べて

の変

更を

報告

し、

ビジ

ネス

オー

ナー

の承

認を

得て

おか

なけ

れば

いけ

ない

。

9ト

ラン

ザク

ショ

ンの

修正

、無

効化

、重

要度

の高

い

処理

につ

いて

は、

デー

タ入

力を

実施

して

いな

い管

理者

が適

切か

つ迅

速に

詳細

をレ

ビュ

ーす

る。

10

ファ

イル

合計

を照

合す

る。

たと

えば

、ト

ラン

ザク

ショ

ン件

数や

金額

をデ

ータ

とし

て記

録し

てい

るパ

ラレ

ルコ

ント

ロー

ルフ

ァイ

ルは

、ト

ラン

ザク

ショ

ンの

実

行後

にマ

スタ

ーフ

ァイ

ルの

デー

タと

比較

する

必要

があ

る。

処理

件数

や合

計金

額に

不整

合が

ある

場

合は

状況

を明

確に

し、

報告

を行

い、

それ

に対

応す

る。

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照

コン

トロ

ール

目標

と

コン

トロ

ール

プラ

クテ

ィス

の説

明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）


網羅性

正確性

妥当性

承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

AC

5

1IT

アプ

リケ

ーシ

ョン

から

の出

力処

理ま

たは

出力

結

果の

保管

を行

う場

合、

プラ

イバ

シー

やセ

キュ

リテ

ィ

要件

を考

慮し

、定

めら

れた

手続

に従

って

行う

。出

力結

果の

配布

の手

続を

定め

、周

知し

それ

に従

う。

2有

価証

券な

どの

機密

性の

高い

全て

の出

力結

果に

つい

ては

、適

切な

間隔

で物

理的

な在

庫を

確認

し、

在庫

デー

タと

比較

する

。機

密性

の高

い出

力文

書の

うち

、例

外処

理ま

たは

拒否

処理

され

たす

べて

の

理由

を説

明す

るた

めに

、監

査証

跡に

よる

手続

を作

成す

る。

3出

力が

行わ

れた

ヘッ

ダの

コン

トロ

ール

トー

タル

や

証跡

レコ

ード

と、

デー

タ入

力時

にシ

ステ

ムが

生成

した

コン

トロ

ール

トー

タル

の差

額と

を照

合し

、処

理

の網

羅性

と正

確性

を検

証す

る。

コン

トロ

ール

トー

タル

が不

一致

の場

合は

、そ

れを

適切

なレ

ベル

の経

営層

に報

告す

る。

4他

の操

作を

実行

する

前に

処理

の網

羅性

およ

び正

確性

を検

証す

る。

電子

的に

出力

され

た結

果を

再利

用す

る場

合に

は、

その

後の

利用

の前

にバ

リデ

ーシ

ョン

が行

われ

る必

要が

ある

。

5 ビ

ジネ

スオ

ーナ

ーは

、終

的な

出力

結果

の適

切性

、正

確性

、網

羅性

のレ

ビュ

ーお

よび

、情

報管

理

基準

に準

拠し

てい

るこ

とを

検証

する

手続

を定

義し

、導

入す

る。

潜在

的エ

ラー

を報

告し

、ロ

グを

管理

ツー

ルへ

自動

的に

記録

し、

適時

にエ

ラー

に対

処す

る。

6ア

プリ

ケー

ショ

ンが

機密

性の

高い

出力

結果

を生

成

する

場合

は、

受領

者を

定め

、人

や機

械が

認識

でき

るよ

うに

ラベ

リン

グし

、そ

れに

従っ

て配

布す

る。

必

要に

応じ

て、

特別

なア

クセ

スコ

ント

ロー

ルが

設定

さ

れた

出力

デバ

イス

に送

信す

る。

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照

コン

トロ

ール

目標

と

コン

トロ

ール

プラ

クテ

ィス

の説

明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

出力

のレ

ビュ

ー、

調整

およ

びエ

ラー

処理

出力

は、

許可

され

た方

法に

よっ

て扱

われ

、適

切な

受領

者に

送付

され

、送

信中

に保

護さ

れる

よう

に、

手続

とこ

れに

伴う

責任

を定

める

。出

力の

正確

性に

つい

て検

証、

検出

、修

正を

行い

、ま

た、

出力

から

得ら

れる

情報

を利

用で

きる

よう

に、

手続

とこ

れに

伴う

責任

を定

める

。


網羅性

正確性

妥当性承認

職務分離

有効性

効率性

機密性


利用可能性


信頼性

種類

― 手

作業

― 自

動化

― ハ

イブ

リッ

ド―

構成

可能

性質

― 予

防的

― 発

見的

頻度

― ト

ラン

ザク

ショ

ン―

毎日

― 毎

週―

毎月

― 毎

年

近接

性―

リス

クの

ポイ

ント

― リ

スク

対象

事象

の

後 ― 経

営層

の見

直し

実行

者―

役割

を挿

入

1ト

ラン

ザク

ショ

ンを

電子

的に

やり

取り

する

場合

は、

トラ

ンザ

クシ

ョン

のデ

ータ

転送

方式

、相

互の

責任

範囲

およ

び例

外処

理方

法な

ど、

相互

認証

に必

要な

伝達

およ

び仕

組み

に関

する

基準

を作

成す

る。

2業

界標

準に

した

がっ

て、

アプ

リケ

ーシ

ョン

によ

って

処理

され

たト

ラン

ザク

ショ

ンの

出力

にタ

グを

付け

る

こと

で、

取引

先企

業と

の相

互認

証、

否認

防止

に対

する

証拠

提供

とな

り、

下流

のア

プリ

ケー

ショ

ンが

受領

した

内容

のイ

ンテ

グリ

ティ

検証

が可

能と

なる

。

3送

信中

のオ

リジ

ナル

デー

タの

真正

性お

よび

イン

テ

グリ

ティ

の維

持の

ため

に、

アプ

リケ

ーシ

ョン

を処

理す

るそ

の他

のト

ラン

ザク

ショ

ンか

ら受

け取

った

入

力デ

ータ

を分

析す

る。

図25 ―

アプ

リケ

ーシ

ョン

統制

の設

計支

援の

ため

のテ

ンプ

レー

ト（続

き）

プロ

セス

/ アプ

リケ

ーシ

ョン

の名

称

業務

プロ

セス

オー

ナー

：

アプ

リケ

ーシ

ョン

統制

の設

計

日付

：＿

＿＿

＿＿

＿＿

参照

コン

トロ

ール

目標

とコ

ント

ロー

ルプ

ラク

ティ

スの

説明

情報

目標

情報

要請

規準

コン

トロ

ール

活動

の属

性

設計

の有

効性

の結

論

トラ

ンザ

クシ

ョン

の認

証と

イン

テグ

リテ

ィ

内部

アプ

リケ

ーシ

ョン

とビ

ジネ

ス機

能/運

用上

の機

能（企

業の

内外

を問

わず

）の間

でト

ラン

ザク

ショ

ンデ

ータ

をや

り取

りす

る前

に、

デー

タの

宛名

が正

しい

かど

うか

、送

信元

の真

正性

、お

よび

内容

のイ

ンテ

グリ

ティ

をチ

ェッ

クす

る。

送信

また

は移

送の

間の

真正

性と

イン

テグ

リテ

ィを

維持

する

。

AC

6

付録 F ― アプリケーション統制に関連する共通の

問題と課題


付録F ― アプリケーション統制に関連する共通の問題と課

題

図 26 には、アプリケーション統制の設計、導入、運用、保守に伴う共通のリスクと課

題、それらのリスクや課題を低減するためのコントロールプラクティスが記載されてい

る。

図 26 ― アプリケーション統制のリスクと課題

アプリケーションの

種類アプリケーション統制

のライフサイクルリスク指標（悪化する恐れ

があるもの）コントロールプラクティス

ベンダーのパッケージ

ソフトウエア（カスタマイ

ズせずにそのまま使

う）

コントロール目標と

コントロールの明確化

ベンダーソリューションに

重要な自動化されたアプ

リケーション統制活動が

組み込まれていない。

アプリケーション統制の要件とベンダーソ

リューションのギャップ分析を実施する。

コントロールのギャップと運用上の影響

に対応するために必要な代替的コントロ

ール活動を検討する。

ギャップ分析のアセスメントをソリューショ

ンの全体的評価に盛り込む。アプリケーション統制

の設計/構築/設定パラメータテーブルの設定

が不適切である。コンフィギュレーションコントロールの設

計および運用の有効性に関する受入規

準を整備する。

導入前に運用の有効性を測定する。アプリケーション統制

の設計/構築/設定新規アプリケーションとレ

ガシーアプリケーション間

のデータ転送にエラーが

ある。

アプリケーション統制の設計、導入、運用

および保守にインターフェースを盛り込

む。


のテストベンダーソリューションの

アプリケーション統制が想

定通りに機能しない。

アプリケーション統制をテストの計画およ

び実行に組み込む。

テストエラーの状況をモニタリングする。

業務プロセスオーナがテスト結果と受入

規準を承認する。アプリケーション統制

の保守コンフィギュレーションパラ

メータに対する不正な変

更が存在する。

重要なコンフィギュレーションコントロール

およびコンフィギュレーションパラメータに

対して正式な変更管理プロセスを導入す

る。

継続的コントロールモニタリングツールを

活用する。アプリケーション統制

の保守ユーザ管理のコンフィギュ

レーションテーブルに対し

て不正な変更が存在す

る。

ユーザ管理のテーブル変更に対して承

認コントロールを導入する。

上位者がテーブル変更のレポートをレビ

ューする。


図 26 ― アプリケーション統制のリスクと課題（続き）

アプリケーションの

種類


のライフサイクル

リスク指標（悪化する恐れ

があるもの）


カスタムまたは社内開

発のソリューションコントロール目標と

コントロールの明確化アプリケーション統制の要

件が定義されていない。アプリケーション統制の設計に関する役

割と責任を定義する。

機能設計の前に、業務処理オーナがア

プリケーション統制の要件/目標を承認す

る。アプリケーション統制

の設計/構築/設定ソリューションに重要な自

動化されたアプリケーショ

ン統制活動が組み込まれ

ていない。

アプリケーション統制が想

定通りに機能しない。

アプリケーション統制の設計に関する役

割と責任を定義する。

開発の前に、業務プロセスオーナへアプ

リケーション統制の要件/目標の承認を依

頼する。

アプリケーション統制の受入規準をテスト

の計画および実行に組み込む。

業務プロセスオーナがアプリケーション統

制のテストを承認する。アプリケーション統制

の運用および保守アプリケーション統制の不

備が明確化されず、エス

カレーションが行われてい

ない。

影響分析をインシデント管理プロセスの

一環として、情報要請規準やエスカレー

ション手順に組み込む。

継続的コントロールモニタリングツールを

活用する。アプリケーション統制

の運用および保守アプリケーション統制に対

する不正な変更が存在す

る。

開発者の本番アプリケーション環境への

アクセスを制限する。

正式な変更管理プロセスおよびコントロ

ールを導入する。第 4 世代のツールソリ

ューション /エンドユー

ザコンピューティング

（Excel、SQL クエリ、

Cognos など）


の設計/構築/設定コントロール目標/活動が

ソリューションに組み込ま

れていない。

第 4 世代のツールにおける役割と責任を

定義する。

ビジネスリスクに基づいてソリューション

の優先順位を付ける。

アプリケーションソリューションのリスクア

セスメントに基づいて開発、テスト、運用

における職務を分離する。アプリケーション統制

の運用および保守第 4 世代のソリューション

に対する変更で生じるエラ

ーが発見できない。

アプリケーションソリューションのリスクア

セスメントに基づいて開発、テスト、運用

における職務を分離する。

リスクの高いアプリケーションに対する正

式な変更管理プロセスを導入する。

付録 G ― COBIT の概要


付録 G ― COBIT の概要

COBIT は、IT ガバナンス協会によって開発され、IT 部門が IT 投資のリスクを小限に

抑え、便益を大化することを目指し、IT 機能の有効性をできるだけ高めるために利

用できるガバナンスのフレームワークであり、サポーティングツールセットである。そ

れを使用することで、IT 部門は、標準的な業界のベストプラクティスならびに経営層

および監査人の期待に対しての自社の位置付けを判断することができる。

COBIT は、IT がビジネスのニーズを満たすための包括的管理アプローチであり、より

詳しい国際基準およびガイダンスに一致するハイレベルのフレームワークである。組織

は COBIT に基づき IT マネジメントを改善し、以下のような便益を得ることができる。

・より高品質の IT サービス

・ IT プロジェクトのさらなる成功

・効率性の向上とコストの適化

・情報セキュリティおよびプライバシーの向上

・コンプライアンス対応の簡素化

・オペレーショナルリスクの軽減

・経営層の自信および信頼性の向上

COBIT は、ベストプラクティスに基づき、包括的かつ統合された方法で IT 部門のプロ

セスを開発するのに役立つ。COBIT は、以下の分野におけるマネジメントガイダンス

およびツールを提供する。

・ビジネス目標と IT 戦略の整合性

・サービスや新規プロジェクトにおける価値の提供

・リスクマネジメント

・リソース管理

・パフォーマンス測定

経営層は、COBIT を利用して IT プロセスを設計し、企業内の IT 関連の役割と責任を計

画、構築、実行およびモニタリングというライフサイクルの 4 つの主要プロセス分野に

マッピングすることができる。これらのドメインにおいて、オーナシップと責任を明確

にし、企業内における IT 管理プロセスを形成する。測定ツールを使用して、IT の達成

目標と企業の戦略的達成目標とを一致させることができる。

COBIT は、企業における IT マネジメントを成功させるために不可欠なプロセスや手続


に関する包括的見解を提供している。したがって、世界中の大手企業や中小企業の多く

の役員や CIO がこれを採用している。また、監督機関や監査人にも受け入れられてお

り、業界標準に位置付けられている。

COBIT は、www.isaca.org/cobit より無料でダウンロードすることができる。

COBIT 4.1 には以下の項目すべてが含まれている。

・フレームワーク ―COBIT において、IT ガバナンス管理、コントロール目標、およ

び優れた実践方法(手法)が、IT ドメインごとおよびプロセスごとにどのように編成

され、ビジネス要件と対応付けられるか説明されている。

・プロセスの説明 ―IT の実行責任に伴う領域に全面的に対応した 34 の IT プロセス

について説明されている。

・コントロール目標 ―IT プロセスについて、管理目標に関する一般的なベストプラ

クティスが規定されている

・マネジメントガイドライン ― 責任の割り当て、評価の測定、およびベンチマーキ

ング評価、能力とギャップの解消を支援するツールが提供されている。

・成熟度モデル ―IT プロセスの現状と将来見込まれる状態を記述したプロファイル

が提供されている。

COBIT のコアコンテンツは当初より進化を続けており、COBIT をベースにした資料も

多数発行されている。COBIT をベースにした現行の発行物を以下に掲載する。

・『Board Briefing on IT Governance, 2nd Edition（取締役会のための IT ガバナンスの手

引き第二版）』 ―IT ガバナンスの重要性、IT ガバナンスの課題、およびその管

理に関する経営者の責任は何かという点について、経営者が理解するのに役立つ

・『COBIT® Online（COBIT®オンライン）』―COBIT のバージョンを自社に合わせ

てカスタマイズし、必要に応じて操作が可能である。ここでは、オンラインによる

リアルタイム調査、FAQ、ベンチマーキング、事例や質問を共有するめの討論の場

が提供されている。

・『COBIT® Control Practices（COBIT®コントロールプラクティス）: Guidance to

Achieve Control Objectives for Successful IT Governance, 2nd Edition（効果的な IT ガバ

ナンスに向けたコントロール目標を達成するためのガイダンス、第 2 版）』 ― 回

避すべきリスクおよびコントロール活動の導入によって得られる価値についてのガ

イダンス、ならびに目標の導入方法に関する指示が提供されている。コントロール

プラクティスは、「IT Governance Implementation Guide: Using COBIT® and Val IT™,

2nd Edition（IT ガバナンス導入ガイド:COBIT と Val IT の使用第 2 版）」と併せて

の利用を強く推奨する。


・『IT Assurance Guide: Using COBIT® （IT 統制の保証ガイド）』― さまざまな保証

活動を支援するための COBIT の利用方法に関するガイダンスが提供され、COBIT

の IT プロセスとコントロール目標すべてに対して推奨されるテスト手続きが提供

されている。これは、COBIT® 4.1 内のコントロール目標に基づく自己アセスメント

の実施にも役立つ。

・『IT Control Objectives for Sarbanes-Oxley （サーベンスオクスリー法（企業改革法）

遵守のための IT 統制目標）：The Role of IT in the Design and Implementation of Internal

Control Over Financial Reporting（財務報告をめぐる内部統制の設計および導入にお

ける IT の役割）』 ― COBIT のコントロール目標に基づく、IT 環境のコンプライ

アンスを保証する方法に関するガイダンスが提供されている。

・『IT Governance Implementation Guide: Using COBIT® and Val IT™, 2nd Edition (IT ガ

バナンス導入ガイド:COBIT と Val IT の使用第 2 版) 』 ― COBIT、Val IT リソース

および補助的ツールキットを利用した IT ガバナンスの導入に向けた一般的ロード

マップが提供されている。

・『COBIT® Quickstart（COBIT®クイックスタート）』 ―小規模組織向けおよび大企

業の導入初期向けのコントロール基準が提供されている。

・『COBIT® Security Baseline, 2nd Edition（COBIT®セキュリティベースライン第 2

版）』、― 企業内の情報セキュリティ導入のために不可欠なステップに重点が置か

れている。

・『COBIT® Mappings（COBIT®マッピング）』 ―現在、www.isaca.org/downloads で

公開されている。

- Aligning CobiT® 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit

- COBIT® Mapping: Mapping of CMMI® for Development V1.2 With COBIT® 4.0

- COBIT® Mapping: Mapping of ISO/IEC 17799:2000 With COBIT®, 2nd Edition

- COBIT® Mapping: Mapping of ISO/IEC 17799:2005 With COBIT® 4.0

- COBIT® Mapping: Mapping of ITIL With COBIT® 4.0

- COBIT® Mapping: Mapping of ITIL V3 With COBIT® 4.1

- COBIT® Mapping: Mapping of NIST SP800-53 With COBIT® 4.1

- COBIT® Mapping: Mapping of PMBOK With COBIT® 4.0

- COBIT® Mapping: Mapping of PRINCE2 With COBIT® 4.0

- COBIT® Mapping: Mapping of SEI’s CMM for Software With COBIT® 4.0

- COBIT® Mapping: Mapping of TOGAF 8.1 With COBIT® 4.0

- COBIT® Mapping: Overview of International IT Guidance, 2nd Edition

・『Information Security Governance: Guidance for Boards of Directors and Executive

Management, 2nd Edition（情報セキュリティガバナンス：取締役会および経営幹部に

向けたガイダンス、第 2 版）』 ―情報セキュリティについてビジネス用語で解説し、


セキュリティに関連する問題の解決に向けて利用できるツールや手法が紹介されて

いる。

Val IT は、Val IT フレームワークに対応する発行物と将来的な追加製品やアクティビテ

ィを示す包括的用語である。

現在の Val IT 関係の発行物は以下の通りである。

・『Value Management: Getting Started, How to Begin Creating Value Through IT-Enabled

Business Investments, An Executive Primer Based on the Val IT Framework（価値管理：着

手、IT 対応のビジネス投資を通じた価値創造の開始方法、Val IT フレームワークに

基づく役員のための入門書）』 ― この発行物では、業務、IT 担当役員や組織のリ

ーダーがビジネスにおける価値管理を開始するための手引きが提供されている。

・『Enterprise Value: Governance of IT Investments（IT 投資の企業価値ガバナンス）』－

企業が IT に対する投資から適な価値を引き出す方法を説明する Val IT フレーム

ワーク 2.0 であり、COBIT フレームワークを基準としている。構成は以下の通りで

ある。

- 価値ガバナンス、ポートフォリオ管理、投資管理からなる 3 つのプロセス

- IT 重要施策－期待される成果、あるいは特定のアクティビティに伴う目標を

達成する上で効果的な影響をもたらす重要なマネジメントプラクティス。Val

IT プロセスをサポートすると同時に、COBIT のコントロール目標とほぼ同様の

役割を果たしている。

・『Enterprise Value: Governance of IT Investments-The Business Case （IT 投資の企業価

値ガバナンス ― ビジネスケース）』 ― 投資管理プロセスに伴う特定の主要要素

に焦点を当てている

付録 H ― キーメッセージのまとめ


付録 H ― キーメッセージのまとめ

本書全体を通じ、経営層の検討に関する重要なメッセージを強調するために、キーポイ

ントを明確にしてきた。これらのキーメッセージを以下に要約する。

第 4 章アプリケーション統制の設計と導入

1. 企業は、通常アプリケーション設計の一環として、ビジネス要件および機能要件の

検討を行なうが、「コントロール」要件の検討を積極的に行うことはない。このた

め、必要とされるコントロールが初期段階からソリューションの中に組み込まれず、

導入後にコントロール活動の「組み込み」が必要となり、導入や運用における課題

となる可能性がある。システム仕様の整合性を修正する費用だけではなく、導入後

のコントロールの組み込みに対して膨大な追加費用が発生する可能性がある。経営

層はビジネスリスクに基づいてコントロール要件が適切に定義され、機能要件に盛

り込まれていることを検証する必要がある。

2. 経営層は、コントロール活動のさまざまな属性、タイプおよび性質をバランスよく

検討することで、コントロール設計の効率性と有効性を適化する必要がある。

例：

コントロールタイプの検討。コントロール活動を手作業の活動とすべきか、自

動化すべきか、あるいはその両方、つまりハイブリッドコントロールとすべき

か。自動化する場合は、ビジネス環境の変化に伴うビジネスルールの変更に容

易に対応できるようにコントロールを「設定可能（コンフィギュレーション可

能）」なものとすべきか。

エラー対応における費用対効果の検討。予防的コントロール活動と発見的コン

トロール活動のどちらを採用するか。

コントロールの頻度、リスクとコントロール活動の関係、およびコントロール

活動実施者の役割の検討。これらはエラーが発生するリスクを許容可能なレベ

ルにまで十分に低減しているか。

リスク低減によって得られる便益とコントロール活動の追加費用（構築、テス

トおよび実施）の検討。

3. 設計されたコントロール活動が想定通りに動作するかテストによって検証されるた

め、システムの受入にはこれらのアプリケーション統制のテストを盛り込むことが

不可欠である。自動化されたアプリケーション統制、ハイブリッドおよびコンフィ

ギュレーションコントロールにおける自動化に関連する部分（コンポーネント）を

明確に文書化しておく必要がある。これらはコントロールにおける運用の有効性を

実証するための証跡として使用される可能性がある。手作業によるコントロールお


よびハイブリッドコントロールに関連する手作業の活動のテスト/検証の証跡を明

確に文書化しておくことは、そのコントロールの実現可能性を再確認し、活動に対

するユーザの理解を深めることに使用できる。

4. 経営層は、アプリケーション統制の設計および導入の承認において、導入するコン

トロールの効率性と有効性の比較、費用対効果、コントロール目標の達成、当該の

情報要請規準が満たされていることを確認する必要がある。

5. 新規システムの場合と同様に、既存のアプリケーションに対してもリスクアセスメ

ントおよび適切なコントロール目標の設定、アプリケーション統制の設計が十分で

あるかの判断を行う。

6. 自動化されたアプリケーション統制は、内部統制における費用対効果が高く、持続

性に優れたシステムで使用可能であるが、そのためには効果的な IT 全般統制が必要

である。

7. アプリケーション統制の設計および導入に関する責任は経営管理部門と IT 部門に

よって分担されている。経営管理部門は、ビジネス目標を達成するようにアプリケ

ーション統制の要件を適切に設計および導入することに説明責任を負う。IT 部門は、

ビジネス要件に従ってアプリケーション統制を開発することに説明責任を負う。

第 5 章アプリケーション統制の運用と保守

8. アプリケーション統制の継続した有効性を保証するためには、その継続的なモニタ

リングが重要である。

経営層は以下の要素について検討をする必要がある。

アプリケーション統制の有効性に関する定期的なアセスメント

手作業によるコントロールを含むハイブリッドコントロールと手作業による

コントロールの運用の有効性に対するモニタリング

自動化されたコントロール活動（自動化されたコントロールを含むハイブリッ

ドコントロール）が想定通りに継続して運用されているかどうかのモニタリン

グ

第三者に委託し、実施しているアプリケーション統制の運用の有効性に対する

モニタリング

業務プロセスおよびアプリケーション統制におけるコントロールが有効でな

いことを示す重要成果達成指標（KPI）のモニタリング

9. 継続的コントロールモニタリング（CCM）は、経営層が内部統制活動の継続的有効

性をモニタリングするための効果的な仕組みである。

10. アプリケーション統制の運用および保守の実行責任と説明責任は、経営管理部門と

IT 部門との間で分担されている。経営管理部門は、アプリケーション統制の継続的

有効性のモニタリング、およびアプリケーション統制の変更に対する要件の明確化


と定義に対して説明責任を負う。IT 部門は、アプリケーションとそれに関連する自

動化されたアプリケーション統制の運用に必要な信頼性の高い環境の提供やユーザ

の要求に基づく変更のための開発/提供に対して説明責任を負う。

11. アプリケーション統制の設計、導入、運用および保守プロセスの成熟度の定期的な

アセスメントの実施は、継続的な信頼性のモニタリングや改善の機会を明確にする

ために有効である。

第 6 章アプリケーション統制と IT 全般統制の関係

12. アプリケーション統制、特に自動化されたアプリケーション統制とハイブリットお

よびコンフィギュレーションコントロールの自動化されたコンポーネント（部分）

は、アプリケーションが動作するコンピュータ処理環境の運用の信頼性に依拠して

いる。この環境における IT 全般統制の不備により、アプリケーション統制の運用の

有効性が損なわれる恐れがある。一方、有効な IT 全般統制は、自動化されたアプリ

ケーション統制の信頼性を向上させることができる。

第 7 章アプリケーション統制の保証

13. 保証の提供という概念は、経営層、取締役会および株主に保証を提供する（社内外

の）監査人という意味合いで一般的には考えられている。しかし、関連するステー

クホルダーに対する保証の提供という観点から、この概念が財務管理および経営管

理へ関連付けられる場面が増えている。経営層がステークホルダーに対して保証を

提供する例としては、サーベンスオクスリー法などの法律に従い、CEO/CFO が内部

統制の設計と運用の有効性を認証するケースや、ライン統括責任者（CIO など）が

CEO/CFO に対して事業ユニット内の統制の有効性の「サブ認証」を提供するケース

などが挙げられる。

14. 保証の提供者が可能な範囲で自動化されたアプリケーション統制に依拠することは、

効率性と費用対効果の向上につながる可能性がある。なぜなら、手作業による活動

の運用の有効性の検証に係るコストを削減できる可能性があるからである。IT 全般

統制が有効であれば、ベンチマーキング戦略により、運用の有効性の検証コストと

労力をさらに削減できる可能性もある。

付録 I ― 用語集


付録 I ― 用語集

アプリケーションベンチマーキング ― アプリケーション内の自動化されたコントロ

ールの効果的な設計および運用を確立するプロセスのこと

アプリケーション統制 ― 特定のコンピュータ化対応策（アプリケーション）に関連す

る目標が達成されるという合理的な保証を提供するために設計されたポリシー、手続お

よび活動のこと

自動化されたアプリケーション統制 ― プログラム化されアプリケーションに組み込

まれたコントロールのこと

コンピュータに依存するアプリケーション統制 ― ハイブリッドのアプリケーション

統制を参照のこと

コンフィギュレーションコントロール ― 通常、アプリケーションシステムのパラメー

タ設定をベースにして、それに依存する自動化されたコントロールのこと

コントロール目標 ― 特定のプロセスにおいてコントロール手続を導入することによ

り達成されるべき成果や目的を記述したもの 30

発見的アプリケーション統制 ― 予め定義されたロジックまたはビジネス規則に基づ

き、エラーを発見するために設計されたコントロールのこと。発見的アプリケーション

統制は、通常はある行動が実施された後に実行され、トランザクションのグループをカ

バーする場合が多い。

全般的コンピュータ統制 ― アプリケーション統制以外で、コンピュータベースのアプ

リケーションシステムが開発、維持および運用される環境に関連し、すべてのアプリケ

ーションに適用されるコントロールのこと。全般的統制の目標は、アプリケーションの

適切な開発および導入を確保するとともに、プログラムおよびデータファイル、ならび

にコンピュータの動作のインテグリティを確保することである。アプリケーション統制

と同様に、全般統制には、手作業によるものとプログラムされたものがある。全般的統

30 前述の IT ガバナンス協会、『COBIT 4.1』p.190


制の例としては、情報システム戦略および情報システムセキュリティポリシーの開発と

導入、矛盾する職務を分離するための情報システム要員の組織、ならびに災害の予防お

よび復旧のための計画などが挙げられる。31

ハイブリッドのアプリケーション統制 ― 手作業による活動と自動化された活動の組

み合わせで構成されるコントロール。そのすべてがコントロールを有効なものとするた

めに運用されるものである。コンピュータに依存するアプリケーション統制と呼ばれる

場合もある。

情報要請規準 ― ビジネス要件の達成のために満たさなければならない情報の属性の

こと。COBIT では、有効性、効率性、機密性、インテグリティ、可用性、コンプライ

アンスおよび信頼性という 7 つの情報要請規準を利用している。

予防的アプリケーション統制 ― エラーの発生を予防することを目的としたアプリケ

ーション統制のこと。予防的アプリケーション統制は、一般的に、ある行動が実行され

る前にトランザクションレベルで実施される。

プロセス ― 一般的に、（他のプロセスを含む）多数のソースの入力を利用し、入力を

操作して出力を生成する企業のポリシーおよび手続によって影響を受ける一連の活動

のこと。注：プロセスには、既存の説明責任オーナに対する明確なビジネスの理由、プ

ロセスの実行をめぐる明確な役割と責任、およびパフォーマンス測定のための手段が備

わっている 32。

透明性 ― 活動に関する企業の公開性のことであり、以下のコンセプトをベースとして

いる。

・影響を受ける者、あるいは仕組みの機能に関するガバナンスの決定に異議を申し立

てたいと思う者に対して、明確であること

・共通の言語が確立されていること

・関連する情報が利用できる状態にあること

注：透明性とステークホルダーの信頼には直接的関係があり、ガバナンスプロセスの透

明性が高ければ高いほど、ガバナンスの信頼性が高くなる。

31 前述の IT ガバナンス協会、『COBIT 4.1』p.190

32 同上、p.192

付録 J ― 参考資料


付録 J ― 参考資料

米国公認会計士協会（AICPA）、Audit and Accounting Guides（監査および会計ガイド）、

米国、2008 年、www.aicpa.org

Brancik, Kenneth C.、Insider Computer Fraud（コンピュータ不正の内情）、Auerbach

Publications、米国、2008 年

トレッドウェイ委員会支援組織委員会（COSO）、Enterprise Risk Management—Integrated

Framework（全社的リスクマネジメント－統合されたフレームワーク）、米国、2004

年、www.coso.org

米国連邦金融機関検査協議会（FFIEC）、Development and Acquisition Booklet（開発と取

得ブックレット）、米国、2004 年、www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html

FFIEC、IT Handbook InfoBase（IT ハンドブックインフォベース）、米国、2008 年、

www.ffiec.gov/ffiecinfobase/index.html

イングランド・ウェールズ勅許会計士協会、Internal Control Guidance for Directors on the

Combined Code（統合規範に関する取締役のための内部統制ガイダンス）（ターンブル

報告書）、英国、1999 年、www.icaew.com/index.cfm/route/120907/icaew_ga/pdf

内部監査人協会（IIA）、GTAG1—Information Technology Controls（GTAG1 ― 情報技

術コントロール）、米国、2005 年、www.theiia.org

IIA GTAG8—Auditing Application Controls（GTAG 8 ― アプリケーション統制の監査）、

米国、2007 年、www.theiia.org

IIA 調査研究財団、Sarbanes-Oxley Section 404 Work, Looking at the Benefits（サーベンス

オクスリー法第 404 条対策、便益の考察）、米国、2005 年、www.theiia.org

国際会計士連盟（IFAC）、International Standard on Auditing（国際監査基準）（ISA）330

（改訂版）、米国、2006 年

ISACA、CISA Review Manual 2009、米国、2008 年、www.isaca.org

ISACA、IS Auditing Guideline G14 Application Systems Review（IA 監査ガイドライン G14

アプリケーションシステムの見直し）、米国、2008 年、www.isaca.org

ISACA、ヒューストン支部、Auxis 管理および技術ソリューション、Continuous Controls

Monitoring（継続的コントロールモニタリング）、米国、2007 年、www.isacahouston.org


IT ガバナンス協会、COBIT® 4.1、米国、2007 年、www.itgi.org

IT ガバナンス協会、COBIT® Control Practices（COBIT®コントロールプラクティス）:

Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition（効果的な

IT ガバナンスに向けたコントロール目標を達成するためのガイダンス、第 2 版）、米国、

2007 年

IT ガバナンス協会、ITAF™：A Professional Practices Framework for IT Assurance（IT 保

証のための専門的プラクティスのフレームワーク）、米国、2007 年、www.itgi.org

IT ガバナンス協会、IT Assurance Guide: Using COBIT®（IT 統制の保証ガイド）、米国、

2007 年、www.itgi.org

IT ガバナンス協会、IT Control Objectives for Sarbanes-Oxley （サーベンスオクスリー法

（企業改革法）遵守のための IT 統制目標） ― The Role of IT in the Design and

Implementation of Internal Control Over Financial Reporting, 2nd Edition（財務報告をめぐる

内部統制の設計および導入における IT の役割、第 2 版）、米国、2006 年、www.itgi.org

IT ガバナンス協会、IT Governance Implementation Guide: Using CobiT® and Val ITTM, 2nd

Edition,（IT ガバナンス導入ガイド:COBIT と Val IT の使用第 2 版）、米国、2007 年、

www.itgi.org

Kaplan, Robert S.; David P. Norton、Balanced Scorecard: Translating Strategy Into Action（バ

ランスの取れたスコアカード：戦略から行動への移行）、Harvard Business School Press、

米国、1996 年

コーポレートガバナンスに関するキング委員会、King Report on Corporate Governance for

South Africa（南アフリカのコーポレートガバナンスに関するキンング報告書）（キング

I 報告書）、南アフリカ取締役協会、南アフリカ、1992 年。

コーポレートガバナンスに関するキング委員会、King Report on Corporate Governance for

South Africa（南アフリカのコーポレートガバナンスに関するキンング報告書）（キング

II 報告書）、南アフリカ取締役協会、南アフリカ、 2002 年、

www.iodsa.co.za/king.asp#King%20I%20Report%20-%201994

不正な財務報告に関する国家委員会（トレッドウェイ委員会）、Report of the National

Commission on Fraudulent Financial Reporting（不正な財務報告に関する国家委員会の報告

書）、米国、1987 年

公開会社会計監視委員会（PCAOB）、Staff Questions and Answers on Auditing Internal

Control Over Financial Reporting（財務報告をめぐる内部統制の監査に関するスタッフの


質疑応答）、米国、2005 年 5 月 15 日

カーネギーメロン大学ソフトウェア工学研究所、The Capability Maturity Model:

Guidelines for Improving the Software Process（能力成熟度モデル：ソフトウェアプロセス

改善のためのガイドライン）（CMM および SW-CMM としても知られている。このタ

イトルは 2003 年に『CMMI®: Guidelines for Process Integration and Product Improvement

（CMMI®:プロセス統合および製品改善のためのガイドライン）』に改称された）、

Addison-Wesley Professional、米国、1995 年

3701 Algonquin Road, Suite 1010

Rolling Meadows, IL 60008 USA

電話番号： +1.847.253.1545

Fax: +1.847.253.1443

E メール：[email protected]

ウェブサイト：www.isaca.org

COBITandApplControls JP new Logo reviceditgi.jp/pdfdata/COBITandApplControls_JP.pdf ·...

Documents

Transcript of COBITandApplControls JP new Logo reviceditgi.jp/pdfdata/COBITandApplControls_JP.pdf ·...