現場が抱える課題

コンプライアンス評価において、ある規定を見つけることは作業の始まりに過ぎません。実際に時間がかかるのは判断です。この規定は現在の製品に適用されるのか。会社は過去に同様のケースをどのように処理してきたのか。どの条件を満たす必要があるのか。どのような場合に専門家の判断を仰ぐべきなのか。

Meta がコンプライアンス領域で直面した困難は、主に三つの点に集中しています。

第一に、専門家は判断方法を知っているが、ドキュメントにはその「理由」が明確に書かれていません。

「暗黙知」には、専門家が習慣的に最初に確認する手がかり、要素の重要度の順序付け方、過去の結論が有効となる条件、そしていつ推論を止めて誰かと議論すべきか、といったことが含まれます。専門家は熟練するあまり、これらの手順を意識的に説明しなくなることがあり、履歴には最終的な結論だけが残されてしまいます。

例えば、「小規模な試用を許可する」という結論だけでは、後から携わる人に、試用の対象者、使用するデータ、問題が発生した場合に撤回できるかどうか、といった情報が伝わりません。以下では、こうした隠れた条件を、一連の教育用ルールとして具体化します。内部テスト、模擬データ、ロールバック可能性の三つをすべて満たす場合のみ、通常の試用審査に進みます。その他の場合は、特別な有人審査に回すか、追加資料の提出を求めます。 これは理解を助けるための架空のルールであり、Meta の社内規定ではありません。

試用人数を変更しても、審査のプロセスが変わるとは限りません。一方、模擬データを実際のユーザー情報に置き換えると、人数が同じでも、異なる種類の審査が必要になる可能性があります。専門家の経験には、まさにこのような取捨選択が含まれています。何が表面的に類似しているだけで、何が判断を変えるのかということです。

これらの経験を文章化することは、単に古いドキュメントの要約を作成することではありません。要約は依然として「プロジェクトが試用を承認された」に留まるかもしれません。しかし、再利用可能な知識には、適用条件、除外ケース、判断の根拠、未解決の問題を保持する必要があります。元の記事では、ドキュメントからオフラインで抽出し、専門家のフィードバックで更新する方法が紹介されていますが、完全な抽出アルゴリズムは公開されていません。ドキュメントに存在せず、専門家も表明したことがない経験は、デフォルトでシステムが認識しているとは見なされません。

第二に、大規模モデルは一般的な知識を理解していますが、この会社が採用している基準を知りません。

同じビジネスであっても、業界には複数の処理方法が存在する可能性があります。しかし、会社は歴史的な経験、事業の方向性、リスク許容度などに基づいて、そのうちの一つを採用すると決定済みです。

汎用モデルはいくつかの選択肢を列挙できますが、会社が既にその選択を行ったことを知りません。モデルが出す提案は必ずしも理不尽ではないものの、社内の専門家による再判断と修正が依然として必要です。

不足しているのは、組織自身の立場です。つまり、この問題に対して当社はどのような解釈を採用し、越えてはならない境界はどこにあるのか、ということです。

第三に、RAG は資料を探せますが、毎回判断根拠を整理し直す作業を省くことはできません。

RAG（検索拡張生成）は、回答の前に関連ドキュメントを検索できます。しかし、検索結果には、古いプロジェクトの記録、現在のルール、特定のケースにのみ適用される例外が同時に含まれる可能性があります。

事前に整理されていなければ、AI は毎回再判断する必要があります。どの資料が優先されるのか。どの条件が適用されるのか。複数の資料の間にはどのような関係があるのか。

これは時間がかかるだけでなく、同種の問題に対して一貫性のない結論を導き出す原因にもなります。専門家が一度修正しても、その修正がチャットの履歴にだけ残り、知識やプロセスに反映されなければ、次回の分析でも同じ誤りを繰り返す可能性があります。

したがって、Meta が補強すべき二つの能力は明確です。専門家が使用する判断条件を事前に明確に文書化すること。そして、その後の修正を実際にシステムに反映し、更新が有効かどうかを検証することです。

システム設計を​支える四つの柱

Meta はシステムを四つの層に分割し、判断根拠、実行手順、受け入れ基準、フィードバック更新のそれぞれに明確な役割を持たせました。

知識層は会社が採用する判断基準を保持します。推論層は分析をどのように完了するかを規定します。評価層は修正と副作用をチェックします。改善ループは専門家のフィードバックを検証待ちの修正に変換します。

これら四つの層は相互に依存しています。知識に明確なファイル境界があって初めて、正確な修正が可能になります。分析に明確な手順があって初めて、失敗箇所を特定できます。評価は修正が通過できるかどうかを決定します。改善ループはその結果を知識とプロセスに更新します。

知識層：​専門家が毎回​説明する内容を​事前に整理する

Meta はまず元のドキュメントをオフラインで処理し、そこから組織の判断を抽出して、200 以上の構造化テキストファイルを整理しました。

これらのファイルは四つのカテゴリに分類されます。

• 立場ファイル： 会社が特定の問題に対して採用する解釈、適用条件、制限事項。
• 分類・用語ファイル： チームが使用する用語の意味を定義し、同じ言葉が異なる概念として解釈されるのを防ぎます。
• ルーティングインデックス： 現在のタスクの特徴に基づいて、適用可能なルールと分析プロセスを見つけ出し、テキストの類似性だけに頼って資料を選択することを減らします。
• エントリーチェックファイル： 現在のタスクが特定の専門分析の適用範囲に含まれるかどうかを最初に判断し、最初から誤ったルールを適用しないようにします。

この汎用化された例では、分析手順を recipe ディレクトリに置き、見解と事実を knowledge ディレクトリに置いています。右側のファイルヘッダーにある triggers はいつロードするかを示し、depends_on はどの根拠に依存するかを示し、referenced_by はどのプロセスやルールがそれを使用するかを示しています。YAML はこれらの構造化フィールドを記述するための形式です。

エントリーチェックは、まず「現在のタスクがこの分析範囲に該当するかどうか」に答え、次にルーティングが「該当する場合、どのルールを使用すべきか」に答えます。テキストが似ているだけでは、現在のタスクに適用できるとは限りません。明確なトリガー条件により、根拠の選択を追跡可能にします。

試用の例に沿って、利用可能なナレッジカードは次のように記述できます。

組織の見解：内部テスト、模擬データ、ロールバック可能性を満たす場合は、通常の試用審査に進む。
適用範囲：機能の試用申請。
除外ケース：一般公開、実際のユーザー情報の使用、またはロールバック不能な場合。
情報不足：条件が満たされていると推測せず、先に資料を揃える。
根拠：教育用の例における専門家の補足説明。
利用者：試用審査プロセス、資料チェックリスト。

これらのテキストは教育用ナレッジカードであり、元の図のディレクトリとフィールド値も汎用化された例として示されています。ここで注目すべきは構造です。ルール、境界、根拠、利用者がそれぞれ個別にチェックできることです。

また、すべての資料を Wiki に詰め込む必要はありません。Meta は情報密度と使用頻度によって役割を分担しています。情報密度とは、資料の中に、現在の判断に直接役立つ内容がどれだけ含まれているかと理解できます。頻繁に使用する抽出済みルールは Wiki に置き、具体的な製品仕様や履歴の詳細はオンデマンドで検索します。

非常に長い履歴資料でも、二つの役割を同時に担うことがあります。そこから抽出された一般的な判断は中核知識となり、元の詳細はオンデマンドで参照するための証拠として残ります。頻繁に使用するからといって、ドキュメント全体を常にコンテキストに入れる必要はありません。

推論層：​専門家の分析方法を​手順として記述する

たとえ正しい知識があっても、AI は誤った順序で使用したり、条件の確認を漏らしたり、時期尚早に結論を下したりする可能性があります。

そこで Meta は、Recipes（分析プロセス）と呼ばれる仕組みを別途構築し、何を最初に確認するか、どの段階でどの知識をロードするか、何をもって分析が完了したと見なすかを規定しました。

知識ファイルは AI に「どの基準を採用するか」を伝え、プロセスファイルは AI に「このタスクを完了するためにそれらの基準をどのように使うか」を伝えます。 プロセスは知識ファイルを参照し、領域の事実を手順内に繰り返し記述しません。知識ファイルは見解を述べ、操作手順は規定しません。

上位プロセスはタスクに応じて異なるサブプロセスを呼び出し、各サブプロセスが一つの分析段階を担当します。新しい組織の見解が追加された場合、主に知識とルーティングを更新します。分析手法に問題がある場合は、プロセスを重点的に修正します。

段階的に実行する場合、各ステップでは現在必要な命令と資料のみをロードします。教育用の例では、エントリー段階でまず試用申請かどうかを確認し、基準を確認する際には立場ファイルを取得し、条件を検証する際には今回の製品のデータ範囲とロールバック資料を確認します。

これにより、「知識の修正」と「プロセスの修正」がそれぞれ異なる対象を持つことになります。審査基準が変わった場合は、立場ファイルを更新します。基準は明確に記述されているのに、アシスタントがデータ範囲の確認を漏らした場合は、資料検証のステップを修正します。両者は参照によって接続されているため、同じ基準を複数のプロセスに重複して記述し、修正漏れが発生するリスクを軽減します。

人とAIの協働：​専門家の判断が​必要なところで​立ち止まる

Meta は二つの人的介入方法を保持しており、これらは分析プロセス全体にわたって存在します。

チェックポイントは、事前に定義された分析ノードに設定されます。AI が中間的な判断を提示し、専門家が確認した後に続行し、その場で方向性を修正することもできます。

エスカレーションは、必要な情報が欠落している、または証拠が複数の妥当な解釈を支持しているなど、信頼性の高い判断ができない場合に使用されます。この場合、専門家がその後の処理方法を決定します。

専門家の介入は、現在のタスクの完了を助けるだけでなく、システム改善のためのフィードバックも提供します。中間判断や不確実な点を観察することで、専門家はどの作業を安心してシステムに任せられるかを段階的に判断できます。

最も注目すべき​メカニズム：​この「自己進化ループ」は​どのように機能するのか？

システムが実際に経験を蓄積するのは、専門家が修正を行った後に起こることです。

「この結論は間違っている」という一言は、そのまま信頼できる知識の更新にはなりません。ファイル間には依存関係があり、一箇所の修正が他のルールに影響を与える可能性があります。システムは原因を調査し、修正箇所を見つけ、その修正が問題を解決したかどうかを検証する必要があります。

Meta は、依存関係の整理、影響の調査、修正の検証を人手で行うと、数週間かかる可能性があると指摘しています。

Meta はこのメンテナンス作業を「コンパイル」と見なしています。自然言語のフィードバックを、正確で検証可能なファイル修正に変換するのです。プロセス全体は四つのステップに分かれています。

1. 原因の特定：​知識が足りないのか、​使い方を誤ったのか

チームは初期段階で、専門家の発言形式に基づいて分類しようとしました。情報の補足は知識のギャップ、方向性の修正はプロセスの問題と見なしたのです。しかし、同じ修正でも異なる根本原因を指し示す可能性があり、この方法は失敗しました。

その後、システムはまず会話から専門家の実質的なフィードバックを抽出し、次に AI が実際にロードしたファイル、そのタイミング、使用方法を確認し、対応する内容を読み取ります。

その後、重要な問いに答えます。当時利用可能だった資料だけで、AI は本来正しい結論に到達できたのか？

試用の例を続けます。実際にロードされたルールに「模擬データのみを使用する」という記述がなかった場合は、知識の追加が必要です。この条件が既に資料に含まれているのに、AI がデータの種類を検証しなかった場合は、プロセスの修正が必要です。専門家の間で実際のユーザー情報の処理方法について合意がない場合は、先に人による議論に委ねるべきです。

ここで確認されるのは、実際の実行時に使用された資料です。ナレッジベース全体に「特定の文が存在するかどうか」だけを見ても、個別の失敗を説明するには不十分です。

システムはまた、問題の発生頻度と重大度に基づいて重み付けを行い、処理の優先順位を決定するのに役立てます。

このステップにより、すべてのエラーを「ルールを一つ追加する」という形で処理することを回避します。

2. 必要な箇所だけを​修正し、​独立したレビューで​影響を確かめる

原因が特定された後、システムは問題を具体的なファイル修正に変換します。

複数のサブエージェントがそれぞれチェックします。変更が古い見解と矛盾しないか、参照関係に影響がないか、重複内容がないか、テキスト予算を超過していないか、テストが関連ケースをカバーしているか。

次に、完全に新しいコンテキストにある独立したレビューエージェントが修正の差分を検査します。このエージェントは提案者の説明を受け取らず、矛盾や破壊された境界条件を探すことに専念します。

さらに、定められたルールに従う検査プログラムが、無効な参照、識別子の衝突、ファイルの上限超過、依存関係の循環などの構造的なエラーを検出します。

意味上の問題は独立したレビューで対応し、形式や構造の問題はプログラムによるチェックで対応します。

3. 二段階のテスト：​今回の誤りを直し、​他のケースの​悪化を防ぐ

第一段階は、元のケースを使ったブラインド再生テストです。

システムは、専門家の是正が発生した状況を再実行します。タスクを実行するAIは、自分がテストを受けていることを知りません。独立した評価者は、元の専門家のフィードバックに基づいて新しい出力を評価しますが、具体的に何が変更されたかは知らされません。これにより、修正の意図に沿った好意的な評価になる偏りを減らします。

第二段階は、回帰テストです。

システムは、領域内の既存のベンチマークケースを実行し、これまで正常だった判断に後退がないかをチェックします。複数の妥当な答えが存在しうる分析タスクでは、評価は判定基準に基づいて行われ、回答の文言が完全に一致するかどうかでは判断されません。

二つのテストは役割が異なります。元のケースの再実行は今回の誤りが直ったかを確かめ、回帰テストは修正の副作用を調べます。どちらかが失敗すれば修正に戻ります。回帰テストで失敗した場合は、悪化したケース、元の問題、試した修正内容をまとめて戻し、やり直しの根拠とします。

4. 修正とテストを​蓄積し、​将来も正しい動作を​確かめる

検証が成功すると、システムは具体的な差分と監査記録を含む変更リクエスト（PR）を生成し、専門家によるレビューに提出します。

専門家の承認を得て初めて、知識やプロセスが正式に更新されます。同時に、初期に失敗した状況と検証済みの正解は、自動的に回帰テストセットに追加されます。

このようにして、一度の修正から二つの成果が得られます。

• 更新された知識やプロセスは、今後のタスクで使用されます。
• 新しく追加されたテストケースは、将来の変更がこの確認済みの動作を壊していないかをチェックするために使用されます。

ここで、同じ教育用のケースを具体的な修正に落とし込みます。旧プロセスは試用対象者とロールバック計画の確認のみで、データの種類の確認が漏れていました。専門家の是正後、パッチはデータ検証を追加する必要があり、すべての試用を特別な有人審査に格上げするべきではありません。

「すべて特別な有人審査に格上げする」というパッチは、今回の誤った通過を修正できるかもしれませんが、通常の条件を満たすタスクまで格上げしてしまう可能性があります。回帰ケースは、まさにこのような副作用を発見するためにあります。承認後に保存されるのは、更新されたプロセスとテストです。モデルの重みは今回の修正では変更されておらず、新しいタスクはこれらのファイルを読み込むことで経験を活用します。

実際の導入効果

Metaの報告によると、三回の開発イテレーション、計六週間で、以下の結果が得られました。

• 一回の評価が数日から数分に短縮。 AIが分析作業の大部分を担い、専門家は曖昧な判断に集中できるようになりました。
• 出力の実用性が大幅に向上。 専門家は結果がほぼ常に有用であると評価しており、初期に頻繁に大幅な手直しが必要だった状態から改善されています。
• 一ラウンドあたりのトークン消費量が約80%削減。 トークンはモデルがテキストを処理する際の計量単位です。この利点は、段階的かつオンデマンドな読み込みにより、各ラウンドで入力される無関係な材料が減ったことで得られました。
• 知識のメンテナンスも高速化。 自動改善プロセスにより、検証済みの知識修正を生成できます。この種の作業は、従来は完全なエンジニアリング開発サイクルを必要としていました。
• 前述の改善サイクルでは、回帰は観察されませんでした。 修正のたびにテストセットも拡張され、将来の更新のためのチェック基準が増えていきます。

これらは、Metaによる社内の特定領域での結果の説明です。「ゼロ回帰」は実行済みのチェックに対応するものであり、将来のすべてのタスクでエラーが発生しないことを保証するものではありません。他の組織は、自社のケースで効果を検証する必要があります。

企業のAI導入に​活かせること

この実践は、企業に具体的な方向性を示しています。AIに専門的な判断をさせるには、判断の根拠、実行方法、受け入れ基準を同時に保存する必要があるということです。

ドキュメントだけでは、AIはその使い方を理解できないかもしれません。プロセスだけでは、組織固有の問題に遭遇したときに対処する根拠が不足します。修正記録だけがあり、更新とテストがなければ、同様のエラーが繰り返し発生する可能性があります。

Metaはこれらの要素を結び付け、各フィードバックが明確な行き先を持つようにしました。どの知識を補うべきか、どのステップを変更すべきか、変更が有効であることをどう証明するか、誰が承認するか、といった点です。

知識とプロセスは、人間とAIの両方が読めるテキストファイルに保存され、更新のたびに差分を比較し、バージョンを保持し、必要な時にはロールバックできます。複雑な改善プロセスは、最終的にはレビュー可能な具体的な変更として残ります。

この方法は、専門的な経験が集中しており、同種の評価で一貫性が求められ、タスク量が専門家の処理能力を超え、かつ汎用モデルの分析では要件を満たせない作業に特に価値があります。コンプライアンス、財務リスク、セキュリティレビュー、エンジニアリング標準の評価などは、これらの条件に該当する可能性がありますが、具体的なルールとテストは各分野で確立する必要があります。

これを採用するには、明確な境界と関連性を持つナレッジベース、知識から分離された分析プロセス、継続的に拡張される評価セット、そして分野のリスクに見合った人によるチェックポイントを同時に準備する必要があります。

組織レベルのセカンドブレインの価値は、専門家が一度修正に時間を費やせば、その後のタスクでその経験を活用でき、それが正しく維持・保存されているかを継続的にチェックできるようにすることです。