#監査

率直に、かなり気持ち悪さのある話だと思った。AIの安全性をチェックする側が、チェックされる側からお金を受け取る。しかも当事者がそれを「本来は違う形であるべきだ」と同じ発表文の中で認めている。そこまで分かっていて、なおその形で進めるしかないのか、という後味の悪さが残る。 ただ、完全に机上のきれいごとで済まないのも分かる。外部の独立評価って、実際にやろうとすると人も金も足りない。専門家を集めて、モデル内部に近いところまで入ってもらうには、かなり重いコストがかかるはずだ。記事にあるように、非営利団体や政府資金の受け皿がまだないなら、企業が先に金を出すしかない、というのは現実としては理解できる。だからこそ厄介で、理想と実装の間に大きな穴が空いているのだと思う。 いちばん引っかかったのは、「独立」の意味がどこまで本当に独立なのか、という点だ。評価者に社員並みのアクセスを与えるのは、それ自体は強い。外から遠く眺めるだけより、ずっと踏み込める。でも報告義務や公開のルールが未整備なら、その結果は結局、企業の内部事情に吸い込まれてしまうかもしれない。危ない発見があっても、製品を売る側の都合で止まるのでは

読んでまず思ったのは、「その 19 回は、そりゃ刺さるよな」ということだった。 監査の nag 自体は、人間が画面の前にいるならかなり筋がいい。実装したついでに報告を飛ばしがちな場面を、その場で止められるからだ。でも記事を読んでいて引っかかったのは、その仕組みが launchd 経由の無人実行にもそのまま流れ込んでいた点で、ここはかなりありがちな落とし穴だと思った。 面白いのは、作者が「通知を止める」ために、通知の有無ではなく実行環境を見ているところだ。`entrypoint` を transcript の先頭から読んで、人間の端末で始まったのか、`sdk-cli` のような自動化で始まったのかを分ける。これ、言われてみれば当然なんだけど、実際には見落としやすい。ツールの挙動を「どこで動いたか」で切り替えないと、同じ hook が別の文脈でまったく違う意味を持ってしまう。 もう一つ、`Stop` hook に置いた判断も納得感があった。途中の tool call ごとにチェックすると、まだ状態が固まっていないのに監査を促すことになる。終わったタイミングで、「ちゃんと自己監査を書いたか」

この記事を読んでまず思ったのは、こういう機能は派手さのわりにかなり効く、ということだった。Claude Code のような開発支援ツールって、便利になるほど「誰が何をしたか」を後から追いにくくなる。だから Compliance API みたいに、監査や統制のための入口を別に用意する発想は、地味だけど筋がいいと思う。 面白いのは、セキュリティ製品を足すというより、既に使っている AI コーディング環境に「あとから管理の目」を差し込もうとしている点だ。現場では、禁止するより先に使われることのほうが多い。だったら、使われる前提でログや権限、追跡を整えるしかない。そこを真正面からやっている感じがある。 ただ、ここで少し引っかかったのは、Compliance API があっても、それだけで安心はできないだろうという点だ。API があるのは入口であって、実際には運用側が何を監視し、どこまで許可し、誰が責任を持つのかを決めないと意味が薄い。監査のための機能は、導入した瞬間よりも、使い続ける運用のほうがずっと難しい。 AI を開発に入れる話は、どうしても「生産性が上がる」で終わりがちだけれど、この記事

読んでまず思ったのは、これって「AIで分析が速くなりました」という話ではなく、AIをそのまま信用しないための設計が主役になっているのが面白い、ということだった。金融はそもそも、速さよりも「あとから検証できるか」が大事だ。だからこそ、モデルに自由に答えさせるのではなく、計算は deterministic にやらせ、Claude には解釈や分解を担当させる、という分業がしっくりくる。 特に引っかかったのは、Claude を「賢い回答者」としてではなく、パイプラインの一段として扱っているところだ。プロンプトをいじれば終わりではなく、ontology だの execution environment だの、かなり地味で骨の折れる周辺設計に力を入れている。正直、こういう話のほうがAIっぽさは薄いし、でも現実にはこっちのほうが重要なんだろうと思う。モデル単体の性能差より、どこで止めるか、どこで人間に返すか、どこを機械的に固定するかのほうが、実務では効く。 あと、各数値を「exact filing, page, and line item」まで辿れる、というのはかなり強い。金融の現場で嫌われ