監査人がいない会社にこそ、監査の視点が要る—CISAに学ぶ「信頼に根拠を与える」技術

あなたの会社で、AIが作った資料や、システムが弾き出した数字を、最後に誰が確認しているでしょうか。

「担当者が見ているはず」「おかしければ気づくだろう」。そう答えたくなったとしたら、その役割は、実は誰にも割り当てられていないのかもしれません。

この「仕組みを信頼してよいかを、誰が確認するのか」という問いに、昔から正面切って向き合ってきた世界があります。システム監査です。

その国際的な体系がCISA（公認情報システム監査人）です。CISAは、1978年に設立されたISACAが認定する資格で、これまでに世界で20万人以上が取得しています。試験は150問で、監査プロセス、ITのガバナンスとマネジメント、システム開発、運用とレジリエンス、情報資産の保護という5つの領域をカバーします。

ただし、この記事は資格の解説でも、取得の勧めでもありません。

CISAが監査人に教えている考え方を、社内に監査人がいない会社—つまり多くの中小企業—の経営に翻訳する試みです。

システム監査とは、ITが正しく動いているかを見るだけではなく、経営者がそのITを信頼して判断できる状態かを確認する仕事です。

監査人は、単なるチェック担当ではありません。組織の情報システム、データ、業務プロセス、統制、リスク対応を見たうえで、「この仕組みは信頼してよいのか」を判断する人です。

システム監査は「ITの健康診断」である

システム監査を一言で言えば、ITの健康診断です。

ただし、健康診断といっても、サーバーが動いているか、パスワードが設定されているかだけを見るわけではありません。

見るべき対象は、もっと広いです。

• 重要な情報資産は守られているか
• データは正確で、改ざんされていないか
• システムは事業目標の達成に役立っているか
• リスクは識別され、適切に対応されているか
• 評価する人は、独立した立場に立てているか

問われているのは、IT技術の細かい知識ではありません。

ITを、経営、リスク、内部統制、説明責任の文脈でどう見るかです。

最初に押さえるべきは「独立性」

システム監査で最初に重要なのは、監査人の独立性です。

監査人が、監査対象のシステムを自分で設計していたり、運用責任を持っていたりすると、公平な評価は難しくなります。

監査人は、システムを作る人でも、運用する人でも、現場を責める人でもありません。

独立した立場から、証拠に基づいて評価し、経営者が判断できる情報を提供する人です。

ここを間違えると、監査は単なる内部チェックや改善活動と混ざってしまいます。

中小企業では、この「独立性」が構造的に成立しにくい

この原則を、人手の限られた会社に当てはめてみます。

システムを選んだのは社長。運用ルールを決めたのも社長。例外を承認するのも社長。うまくいっているかを判断するのも社長。設計者、運用者、承認者、評価者が同一人物に集中する—これは、規模の小さな会社では避けにくい構造です。

これは怠慢ではありません。そして社長が現場を熟知している間は、この体制は実際にうまく機能し得ます。

問題は、「この仕組みは信頼してよいか」と問う役割が、誰にも割り当てられていないことです。専任の監査部門を置ける中小企業は多くありません。

社長の中にある「大丈夫だ」という感覚は、長年の経験に裏づけられた、根拠のある判断かもしれません。しかしその根拠は言語化されておらず、社外からも、後継者からも見えません。

言語化されていない「大丈夫だ」は、そのままでは承継できません。

だからといって、中小企業が監査部門を作るべきだという話ではありません。必要なのは組織ではなく、視点です。そしてCISAが教える視点は、まさに「人手も時間も限られた中で、どこを見るべきかを決める」ためのものです。

監査は「全部見る」仕事ではない

監査というと、すべてを細かく確認するイメージがあります。

しかし、現実にはすべてのシステム、すべての取引、すべてのログを人間が確認することはできません。

そこで重要になるのが、リスクベース監査です。

リスクベース監査とは、限られた監査資源を、重要なリスクが大きい領域に優先的に配分する考え方です。

たとえば、顧客情報を扱うシステム、資金移動に関わるシステム、外部接続されているシステム、障害時に事業停止につながるシステムは、優先的に見るべき対象になります。

逆に、重要性が低く、影響も限定的な領域に過剰な時間を使うと、監査全体の価値は下がります。

これは、監査資源どころか経営資源そのものが限られている中小企業にとって、そのまま経営の技術です。全部はできない。だから、どこを見るかを決める。

この割り切りをせずにチェック項目だけを増やすと、チェックリストが形骸化し、現場は「監査対応業務」に疲弊し、かえって何も見えなくなる—という失敗シナリオに陥りやすくなります。

リスクは「影響度」と「発生可能性」で考える

リスクは、単に怖そうかどうかで判断するものではありません。

基本は、影響度と発生可能性です。

発生確率が高く、影響も大きいリスクは、当然優先度が高くなります。

一方で、発生確率は低くても、起きた場合に会社が止まるようなリスクも軽視できません。

たとえば、ランサムウェア、基幹システム停止、重要データの消失、重大な個人情報漏洩などです。

見るべきは技術的な脆弱性だけではなく、それが事業にどれだけ影響するかです。

監査リスクは3つに分けて考える

CISAでは、監査リスクの考え方も重要です。

監査リスクとは、監査人が重要な不備を見逃し、誤った監査意見を形成してしまうリスクです。

監査リスクの要素	意味	監査人の見方
固有リスク	統制がないと仮定した場合に、もともと存在するリスク	業務やシステムの性質として高いかを見る
統制リスク	内部統制が不十分で、誤りや不正を防止・発見できないリスク	統制が設計され、運用されているかを見る
発見リスク	監査手続で重大な不備を見つけられないリスク	監査範囲やテスト方法で下げる

このうち、監査人が直接コントロールしやすいのは発見リスクです。

固有リスクや統制リスクが高ければ、監査人はサンプル数を増やす、監査範囲を広げる、追加手続を行うなどして、発見リスクを下げます。

内部統制は「防ぐ・見つける・直す」で考える

内部統制は、難しい言葉に見えますが、基本は3つです。

統制の種類	目的	例
予防コントロール	問題を起こさせない	アクセス権限、MFA、職務の分離
発見コントロール	問題が起きたことを見つける	ログ監視、アラート、例外レポート
是正コントロール	問題を直し、再発を防ぐ	パッチ適用、復旧手順、再発防止策

良い統制は、この3つがつながっています。

たとえば、不正ログインを防ぐためにMFAを導入する。失敗ログインが急増したら検知する。アカウントが侵害されたら停止し、原因を調べ、再発防止策を講じる。

人手の限られた会社で起こりがちなのは、予防だけが存在するパターンです。パスワードは設定した。権限も分けた。しかし、破られたことに気づく仕組みと、気づいた後に直す手順がない。この場合、問題は起きていないのではなく、起きても見えていないだけかもしれません。

準拠性テストと実証性テストを混同しない

監査の手続には、大きく二つの種類があります。

テスト	見るもの	例
準拠性テスト	統制がルール通りに機能しているか	アクセス権申請が承認フローを通っているか
実証性テスト	データや取引結果そのものが正しいか	売上データや送金額が正確かを確認する

内部統制が有効なら、実証性テストの範囲をある程度縮小できます。

逆に、内部統制が弱いなら、データそのものをより広く確認する必要があります。

つまり、監査人は最初からすべてのデータを力技で見るのではなく、統制の有効性を見ながら監査手続を調整します。仕組みへの信頼が、確認作業の量を決めるのです。

監査証拠は「量」だけでは足りない

監査人の結論は、証拠に基づかなければなりません。

ただし、証拠は多ければよいわけではありません。

重要なのは、十分で、信頼でき、監査目的に関連していることです。

証拠の観点	意味
十分性	結論を支えるための量があるか
信頼性	証拠の出所や質が信頼できるか
適切性	監査目的と関係しているか
有用性	改善や判断に役立つか

一般に、監査対象部門が自分で作った資料だけよりも、システムログ、外部証跡、第三者報告書、監査人自身が再実行した結果の方が信頼性は高くなります。

求められるのは「資料を受け取ること」ではなく、その資料が結論を支える証拠として信頼できるかを判断することです。

CSAは便利だが、監査の代わりではない

CSA、つまり統制自己評価は、現場が自分たちの業務リスクや統制を評価する仕組みです。

現場のリスク感度を高め、早く問題を見つけるうえで有効です。

ただし、現場自身が評価するため、客観性には限界があります。

そのため、CSAは監査を効率化する材料にはなりますが、監査そのものを代替するものではありません。

「自分たちで確認しているから大丈夫」と「独立した立場から確認されている」は、別のものです。

ITガバナンスは「IT部門の話」ではない

ITガバナンスは、IT部門だけの話ではありません。

経営戦略とIT戦略を整合させ、ITが企業価値の向上、リスク管理、コンプライアンス、資源最適化に貢献しているかを見る考え方です。

ここで重要なのは、ガバナンスとマネジメントを分けて考えることです。実際、CISA試験の5領域のうち一つは「ITのガバナンスとマネジメント」に丸ごと充てられており、その中でもガバナンスとマネジメントは別の柱として扱われています。

区分	役割	主な担い手
ITガバナンス	何をすべきかを決める	取締役会、経営陣
ITマネジメント	どう実現するかを管理する	IT部門、現場担当者

監査人は、IT部門が頑張っているかだけを見るのではありません。

経営がITをどう位置づけ、どのリスクを受け入れ、どの統制を求めているかを見る必要があります。

中小企業では、ガバナンスとマネジメントが一人に溶けている

この表を、社長が現場も見ている会社に当てはめると、どうなるでしょうか。

「何をすべきかを決める」のも社長。「どう実現するかを管理する」のも社長。ガバナンスとマネジメントが分かれておらず、社長という一人の人間の中に溶けている—そういう会社は少なくないはずです。

繰り返しますが、これは悪いことではありません。意思決定が速く、責任の所在が明確で、小さな組織ではむしろ合理的です。

しかし、事業承継の場面では、この一体構造が壁になります。

株式や役職は書類で渡せます。渡しにくいのは、「この会社では、どのリスクを取り、どのリスクは取らないと決めてきたか」という判断の基準です。それはガバナンスの中身そのものであり、社長の中に溶けたまま言語化されていないことが多いのです。

事業承継とは、ガバナンスとマネジメントを一度分離し、それぞれを渡せる形にするプロセスでもある。そう捉えると、監査の視点は承継の準備そのものだと言えるかもしれません。

AIエージェント時代のシステム監査

そして今、この問いが急に現実味を帯びる変化が起きています。AIエージェントの業務利用です。

AIエージェントが、顧客対応、資料作成、経理処理、営業提案、コード生成、ログ分析まで担うようになると、従来のシステム監査だけでは見切れない論点が増えます。

• AIエージェントにどのデータを見せているか
• どこまで実行権限を与えているか
• 人間の承認が必要な境界はどこか
• AIの出力を誰がレビューしているか
• プロンプトや判断ログは残っているか
• 誤回答や誤操作が起きたときに止められるか

これは一過性のテーマではなさそうです。CISAを運営するISACA自身が、AI監査に特化した資格（AAIA）の提供を始めています。監査の世界は、AIを次の監査対象として正面から扱いはじめています。

大企業には、こうした問いを担当する監査部門やリスク管理部門があります。一方、専任部門を持たない中小企業では、社長や担当者が便利さを実感してAIを使い始め、気づけば重要業務に組み込まれているのに、上の問いには誰も答えていない—そんな状態が生まれやすいのではないでしょうか。

AIが業務に組み込まれても、監査の仕事の中心は変わらないはずです。変わるのは、見る対象です。

独立性、リスク評価、統制、証拠、報告、フォローアップ。この骨格は、対象がAIになってもそのまま使えます。

まとめ—監査とは、信頼に根拠を与えることである

CISAが教えるシステム監査の本質は、組織がITを信頼して使える状態にあるかを評価することです。

監査人は、全部を見る人ではありません。重要なリスクを見極め、十分かつ適切な証拠を集め、統制の有効性を評価し、経営者が判断できる形で報告する人です。

そしてこの視点は、監査人がいない会社でこそ欠けがちです。設計も運用も承認も評価も社長が担う構造では、「この仕組みは信頼してよいか」と問う役割が、誰にも割り当てられていないからです。

AIを導入する会社は増えるでしょう。

しかし、AIを信頼してよい状態に保てる会社は、そう多くないかもしれません。

システム監査とは、ITを止めるためのものではありません。疑うためのものでもありません。

監査とは、信頼に根拠を与えることです。

あなたの会社で、「この仕組みは信頼してよいか」と問う役割は、いま誰が担っているでしょうか。そしてその問いは、あなたがいなくなった後も、問われ続けるでしょうか。

参考情報

• ISACA「CISA Exam Content Outline」確認日：2026年7月22日
  https://www.isaca.org/credentialing/cisa/cisa-exam-content-outline
• ISACA「CISA Certification」確認日：2026年7月22日
  https://www.isaca.org/credentialing/cisa
• ISACA「AAIA – Advanced in AI Audit」確認日：2026年7月22日
  https://www.isaca.org/credentialing/aaia