【ITニュース解説】How Do You Know Your Reviewer Is Still Reviewing?

システム開発の現場では、多くの作業を自動化することで効率を上げようと努力している。特に、何度も繰り返される決まった作業や、手順が明確で判断が単純なケースは、人間が手作業で行うよりもシステムに任せた方が間違いも少なく、速く処理できることが多い。しかし、この「簡単なケースの自動化」には、予想外の落とし穴が存在することがある。

システム開発の初期段階では、システムが出した結果を必ず人間が確認し、最終的な判断を下すという運用が一般的だ。これにより、システムがまだ未熟であっても、人間の目を通すことで大きな間違いを防ぎ、システムの学習を促すことができる。しかし、システムが安定し、「このルールはいつも正しく処理してくれる」という信頼が生まれると、開発者や運用担当者は「簡単なケース」については、人間が毎回確認する手間を省き、システムに自動で処理させるようになる。つまり、「人間が異議を唱えない限り、システムが自動で解決する」という運用に切り替わるのだ。

この「簡単なケースの自動化」が進むと、システムが正しいかどうかを確認する人間側の目が、だんだんと疎かになるというリスクが生まれる。しばらくの間は問題なく運用できるだろう。しかし、ある時、システムが処理するべきパターンに「非常に似ているが、実際は異なる」という「ニアミス」のケースが発生する。もし、人間がもうシステムの提案を真剣に読んでいないとしたら、このニアミスは誰にも気づかれることなく、システムによって間違った形で処理されてしまう。その間違いは、システムのレビューキュー（確認待ちのリスト）では発見されず、後になって、その間違った処理によって影響を受けた人から連絡があって初めて発覚する、という事態になりかねない。

この問題の本質は、「システムが間違った」こと自体ではない。システムが間違えることは、時には避けられないことであり、誰かがそれを監視していれば対処可能だ。本当の問題は、「システムが間違っていたのに、誰もそれに気づける立場にいなかった」という点にある。人間が確認するステップが形骸化し、システムの出す結論に「盲目的に」承認を与えてしまう「ハンコ押し」の状態になってしまうことが、大きなリスクなのだ。

この問題に対処するため、一つの解決策が提案されている。それは、「人間が決定する」状態から「システムが完全に決定する」状態へ直接移行するのではなく、その間に「中間段階」を設けるというものだ。この中間段階では、システムがまず解決策を「ドラフト（下書き）」として提示し、人間はそれを最終的に「承認する」ためにクリックする必要がある。この段階では、まだ意思決定の時間を短縮できているわけではない。主な目的は、システムが提案する解決策が、人間が選択するであろう結果と実際に一致しているかどうかをテストすることにある。数週間、システムの提案と人間の承認にどのくらいの不一致があるかを数える。そして、その不一致率が十分に低く、システムが信頼できると判断された場合にのみ、システムに完全な自律性を与えるべきだ。これは「シャドウモード」と呼ばれる、一般的なシステム移行前のテスト手法の一つだ。

しかし、さらに鋭いアイデアが生まれている。それは、ルールそのものだけでなく、システムをレビューする人間側もテストするという考え方だ。システムが「提案のみ」モードで実行され、人間がそれを確認する段階において、システムが提示した解決策と人間の選択との不一致率が低いというデータだけでは、実は曖昧な情報しか得られない。低い不一致率は、システムが非常に優れた提案をしていることを意味するかもしれない。しかし同時に、レビュー担当者である人間が、システムの提案をきちんと読まずに、ただ漫然と「承認」ボタンをクリックしているだけかもしれない。どちらの場合でも、データ上は「不一致ゼロ」として記録されるため、この二つの状況を区別することはできないのだ。

そこで提案されたのが、定期的に**「既知の間違った提案」をシステムの処理の流れの中に意図的に混ぜ込む**という方法だ。そして、レビュー担当者がその間違いに気づき、修正するかどうかを監視する。これは、鉱山に毒ガスがないか確認するためにカナリアを連れて行った故事にちなみ、「カナリアテスト」と呼ばれる。

このカナリアテストを効果的に機能させるためには、二つの重要な詳細がある。一つ目は、混ぜ込む間違いが「もっともらしい間違い」であることだ。あまりにも明白でばかげた間違いは、誰でもすぐに気づくため、レビュー担当者が本当に注意を払っているかどうかのテストにはならない。カナリアは、実際のニアミスのように見え、正確なラベルが貼られているかのように見えながら、注意深く見なければ間違いと気づかないような、巧妙な間違いである必要がある。それを見抜くことができて初めて、レビュー担当者が本当に注意を払っている証拠となる。

二つ目は、カナリアが存在することをレビュー担当者に伝えることだ。もし秘密裏にカナリアテストを行った場合、最初のうちは正直なテストのように思えるかもしれない。しかし、ある時レビュー担当者が、事前に知らされていなかったカナリアを発見してしまったら、その担当者はその後システムから送られてくるすべてのエッジケース（特殊な状況）に対して不信感を抱くようになるだろう。これは、テストの純粋性が少し失われるよりも、はるかに悪い結果だ。レビュー担当者に対し、「カナリアテストは存在しますよ」と伝え、しかし「具体的なカナリアがどれであるかは教えません」という方針を取ることで、彼らの警戒心を維持させつつ、彼らを罠にかけるような不信感を抱かせずに済む。

カナリアテストの結果を評価する際は、単にカナリアがどれだけ検出されたかという検出率だけを見るのではなく、その検出率と、実際のシステム運用中に発生した不一致率を合わせて見ることが重要だ。

• カナリア検出率が高く、実際の不一致もまだ発生している場合：これは、システム（ルール）がその役割を果たし、レビュー担当者である人間も注意深く確認を行っていることを意味する。健全な状態と言える。
• カナリア検出率が高く、実際の不一致がゼロの場合：これは、システム（ルール）が非常に優れており、ほとんど間違いを犯さない可能性を示唆している。
• カナリア検出率が低く、実際の不一致がゼロの場合：この状況が最も注意が必要だ。これは、レビュー担当者である人間がシステムの提案をきちんと見ておらず、確認作業を怠っている可能性が高い。システムが実際に正しく機能しているかどうかに関わらず、人間側のチェックが機能していないという問題が露呈する。

この三つ目のケースは、単に「実際の不一致率がゼロ」というデータだけでは、「システムが素晴らしい」という状況と区別できないものだ。カナリア検出率という指標を組み合わせることで、この曖昧さを解消し、人間側のチェック機能が正しく働いているかを判断できるようになる。

このような考え方は、システムを開発し、運用していく上で非常に重要だ。自動化は効率を高めるが、それに伴うリスク、特に人間側の注意力が低下することへの対策を講じる必要がある。単にシステムが正しく動いているかだけでなく、そのシステムを監視し、最終的な判断を下す人間が適切に機能しているかを常に確認する仕組みを持つことが、システムの品質と信頼性を維持するために不可欠である。