監査は「問題炙り出し装置」である
監査（仕事の中身を別のAIが点検すること）の目的は、GOをもらうことではありません。
これが第2部を通じて伝えたかった原則の核心です。監査はそもそも「通過儀礼」ではなく、「問題を表に出す装置」として設計されています。この章ではその意味を整理します。
「GOのため」にやる監査は、本質からずれている
監査という言葉を聞いたとき、「最終的にGOが出れば成功」というイメージが浮かぶ人は少なくないと思います。審査があって、合格する。試験があって、通過する。そういう経験からくる感覚です。
ただ、この連載で設計した組織における監査は、少し違う位置づけです。
GOが出ることを目標にすると、監査のやり方が変わります。「通れるか」という視点で動き始めると、問題を見つけることより「どこまで問題とみなすか」の線引きに意識が向く。閾値（しきいち：問題ありと判断する基準線）を甘めに設定すれば、問題は出にくくなります。GOは出やすくなりますが、実際の問題は残ります。
本来の監査は逆の向きで動きます。「問題がないかを確認する」ではなく、「問題があれば必ず出す」という向きです。GOが出なくていい、という状態を許容できる設計でなければ、監査は形骸化（けいがいか：仕組みとしての形は残るが機能しなくなること）します。
「粗探し」とは何が違うか
ここで一つ、よく混同される話を整理しておきます。
「問題を出す」と聞くと、粗探し（相手の欠点を探して責めること）のように聞こえることがあります。ただ、監査が目指すものは粗探しとは異なります。
粗探しは、問題を見つけることで誰かを批判したり、失敗を証明したりすることに力点があります。見つけた問題が責任追及や評価の材料になります。
監査が問題を出す理由は違います。後工程で問題が残ったまま進むと、より大きなコストや手戻りが発生するからです。早い段階で問題を表に出して直す、という順序が目的です。問題が出ること自体は失敗の証明ではなく、「今、直せる段階にある」という確認です。
この違いは、運用する側の心理にも影響します。「問題を出したら責められる」という文化では、監査担当は問題を出しにくくなります。「問題を出すのが仕事」という設計であれば、監査担当は思い切って出せます。どちらの設計にするかで、実際に上がってくる情報の質が変わります。
指摘が出ることは、監査が機能しているサイン
実際に組んで動かしていると、こんな経験があります。
ある回の成果物に対して、監査担当のAIから複数の指摘が返ってきました。最初はその量を見て「問題が多い」と感じました。ただ、指摘の中身を読んでいくと、どれも無視できない内容でした。方針との照合でズレが出ていたこと、専門用語の噛み砕きが不十分だったこと、前後の章との整合性に抜けがあったこと。
後で修正したものと元の成果物を並べると、修正後の方が明らかに質が上がっていました。指摘が多かったから問題が多いのではなく、問題が多かったからこそ指摘が出た、という順序です。
監査は問題を作り出しているのではありません。すでにある問題を表に出しているだけです。指摘ゼロの監査は、問題がないことを意味しません。問題を見つけられなかった可能性もあります。
「指摘が出てくること」は、装置が正常に動いているサインです。
問題があっても進む設計にする
「問題が出るかもしれない」という不安は、監査を動かすことへの抵抗感に変わりやすいです。ただ、問題は出す前からすでに存在しています。見えていないだけです。
早い段階で問題が出てくることと、後の段階で問題が表面化することを比べると、前者の方が対処コストは低くなります。後から発覚する問題ほど、修正の影響範囲が広くなるからです。
このプロジェクトで運用している設計では、監査で問題が出てきたとき、それをそのまま承認担当の人間に提示します。「問題があったので、GO保留です」ではなく、「これこれの問題が見つかりました、判断してください」という渡し方です。
問題があることと、進めるかどうかの判断は、別の話として扱います。問題の大小・緊急度・影響範囲を見た上で、承認担当が「直してから進む」「このまま進む」「一旦止める」を判断します。監査が担うのは問題の発見と記録であり、その先の判断ではありません。
この設計にしたことで、監査担当が問題を「出しやすい」構造になりました。隠す理由がなく、出すことがそのまま役割の完了になるからです。
この章の整理
監査の目的は、GOをもらうことではなく、問題を表に出すことです。
問題が出てくることは失敗のサインではなく、装置が機能しているサインです。逆に指摘ゼロが続くときは、粒度の設定や監査の動き方を確認する理由になります。
監査は粗探しではありません。早い段階で問題を見つけ、後工程での手戻りを減らすための設計です。問題を出すことがそのまま役割の完了になる構造にしておくことが、監査を形骸化させないための基本です。