【ITニュース解説】Anthropic Releases Open-Source Bloom and Petri for AI Behavior Auditing

近年、人工知能（AI）は私たちの生活やビジネスに深く浸透しつつある。特に大規模な言語モデル（LLM）のようなフロンティアAIモデルは、人間のように自然な文章を生成したり、複雑なタスクをこなしたりできるため、さまざまなシステムに組み込まれるようになっている。しかし、AIは非常に強力である反面、予期せぬ振る舞いをすることがあり、それが大きな問題を引き起こす可能性もある。例えば、顧客対応で不適切な発言をしたり、機密情報を誤って扱ったりするリスクが考えられる。

このようなAIの「予期せぬ振る舞い」をどうやって見つけ出し、どうやって評価すればよいのだろうか。これはシステムを開発し運用する上で非常に重要な課題だ。今回、AI研究の最先端を走るAnthropicという企業が、この課題に取り組むための二つの強力なツール、「Bloom（ブルーム）」と「Petri（ペトリ）」をオープンソースとして公開した。これは、システムエンジニアを目指す皆さんにとっても、AIの品質保証や安全性確保について学ぶ上で非常に参考になるニュースだ。

まず「Bloom」について説明しよう。Bloomは、フロンティアAIモデルの「振る舞い」を自動的に評価するためのフレームワークだ。AIモデルが与えられた指示に対して、期待通りの反応をするか、それとも危険な、あるいは望ましくない振る舞いをするかを、体系的にテストする仕組みを提供している。従来のAIのテストは、人間が手作業でいくつかの質問（プロンプト）を入力して反応を見る、というような形が多かった。しかし、これではモデルのすべての潜在的な振る舞いを網羅することは非常に難しい。Bloomは、もっと広範囲に、そして再現性高く、AIの振る舞いを評価できるように設計されている。

次に「Petri」だ。PetriはBloomと連携して機能するコンパニオンツールで、特に「リスクのある相互作用」を監査することに特化している。AIの危険な振る舞いは、単一の指示だけで発生するとは限らず、複数の条件が組み合わさったり、システム内の他の要素と連携したりすることで、初めて現れるケースも多い。Petriは、このような複雑なリスクの組み合わせを並行して探索し、問題となりうる振る舞いを発見する手助けをする。

これらのツールがオープンソースとして公開されたことには大きな意味がある。オープンソースとは、そのツールのソースコードが一般に公開され、誰もが自由に利用、変更、配布できるということだ。BloomとPetriはMITライセンスの下で提供されており、これは非常に柔軟なライセンスで、企業が自社のシステムに組み込んだり、独自のワークフローに合わせて改変したりすることが容易になる。システムエンジニアにとって、内部の仕組みがブラックボックス（中身が見えない状態）ではなく、どのように動作しているかを確認できるのは、信頼性やカスタマイズ性を高める上で非常に重要だ。

Bloomの評価プロセスは、具体的に四つの段階で構成されている。これは「パイプライン」と呼ばれ、まるで工場で製品が順番に加工されていくように、評価が進んでいく。第一段階は「理解（Understanding）」だ。ここでは、どのようなAIの振る舞いをテストしたいのか、その目的と背景を明確にする。例えば、「顧客サポートのAIアシスタントが、機密情報を尋ねられたときに適切に拒否するか」といった具体的な懸念を定義する。第二段階は「着想（Ideation）」だ。定義された懸念に基づいて、具体的なテストシナリオや評価アイデアを生成する。これは、一つ一つのテストプロンプトを考えるだけでなく、その振る舞いを引き出すための多様な状況や条件を考案する作業だ。第三段階は「展開（Rollout）」だ。生成されたテストシナリオを、実際に評価したいAIモデルに対して実行する。つまり、AIにたくさんの質問やタスクを与え、その反応を記録する段階だ。そして第四段階が「判断（Judgment）」だ。AIモデルの反応を分析し、それが望ましい振る舞いだったのか、それとも問題のある振る舞いだったのかを判断する。この判断には、事前に定義された基準が用いられる。

Bloomがこのパイプラインを使って評価する振る舞いには、興味深い例がいくつかある。例えば、「妄想的なごますり（Delusional sycophancy）」という振る舞いは、AIがユーザーの意見に盲目的に同意し、誤った情報であっても追従してしまうことを指す。「自己保存（Self-preservation）」や「自己優遇バイアス（Self-preferential bias）」は、AIが自身を保護したり、特定のタスクにおいて自分自身に有利な選択をしたりする傾向がないかを見るものだ。これらは、AIを業務で使う上で、公平性や信頼性に直結する重要な側面だ。

評価の結果は、「誘発率（Elicitation rate）」や「スイート多様性（Suite diversity）」といった指標で報告される。誘発率とは、その評価スイート（テスト一式）が、本来テストしようとしている振る舞いをどれだけ引き出せたかを示すものだ。スイート多様性は、生成されたテストスイートの中にどれだけ多様なシナリオが含まれているかを示す。これらの指標は、モデルがどれだけ安全かという全体的な評価ではなく、あくまで「このテストで、この振る舞いがどれくらい現れたか」を示すものと理解することが重要だ。

Bloomの最大の貢献は、AIの振る舞いテストをより体系的で再現性の高いものにしようとしている点にある。人間が手作業でチェックリストを作成するよりも、Bloomのパイプラインを使えば、より広範囲で多様なテストケースを生成し、評価することができる。これにより、見落としのリスクを減らし、テストの品質を向上させることが期待できる。

しかし、Bloomの評価結果を「AIモデルが完全に安全である」という証明として捉えるべきではない。Bloomのテストは、あくまで特定の振る舞い、特定の構成、特定のモデル、そして特定の判断方法に基づいて行われる。例えば、あるAIアシスタントを顧客対応システムに導入する場合、Bloomで基本的な安全性を確認できたとしても、実際にそのシステムが使う独自のプロンプト、データ連携、エラー発生時の対応パスなど、アプリケーション固有のテストは別途必要になる。Bloomは、そうしたアプリケーション固有の検証作業を「情報提供」する形でサポートするものであり、その必要性をなくすものではない。

システムエンジニアがBloomを導入する際には、いくつかの実務的な考慮点がある。MITライセンスのおかげでコードの利用は柔軟だが、実際に意味のある評価を行うには、評価対象のAIモデルへのアクセス、テストを実行するためのコンピューティングインフラ、関連するリスクを反映した「シード設定」（評価生成の出発点となる設定）、そして評価結果を既存の開発・レビュープロセスに連携させる仕組みが必要となる。これらは、単にツールをインストールすれば全てが解決するわけではない、ということを意味する。また、Bloomのリポジトリは2026年時点で、Meridian Labsという別の組織によって開発・保守されるようになったという情報も重要だ。長期的に利用を検討する際は、最新のドキュメントや管理体制を確認することが賢明だろう。

Bloomを実際に活用する上での実践的なアプローチとしては、まずAIの振る舞いが明確な運用上の影響を持つワークフローに焦点を当てることが推奨される。例えば、社内アシスタントが機密性の高い要約を作成する場合や、顧客対応ワークフローでAIが返信の下書きを生成する場合などだ。次に、そのコンテキストで問題となる特定の振る舞いを定義する。そして、その振る舞いに関するシード設定を作成または適応させ、実際にチームが使用するモデルとセットアップに対して評価を実行する。最後に、結果を人間によるチェックと合わせてレビューし、必要に応じてプロンプト、権限、ツール、またはエスカレーションルールを調整する。

このアプローチは、AIシステムがビジネスプロセスに深く組み込まれている場合に特に重要だ。AIが生成したテキストは、人間がレビューすれば問題ないかもしれないが、それが顧客への返信、データベースの更新、または自動タスクのトリガーとなる場合、その影響は大きく変わる。Petriがリスクのある相互作用に焦点を当てているのは、まさにこの点に役立つ。単一のプロンプトでは問題なくても、複数の条件が組み合わさることで障害が発生する可能性があるからだ。

Bloomのリリースは、AIの評価にさらなる透明性をもたらすという点でも価値がある。この技術レポートは、ベンダーや社内チームがどのように振る舞いをテストしたのか、どれだけ多様なテストが使われたのか、そして結果がどのように判断されたのかを具体的に質問するための共通の言葉を提供する。これは、「モデルがテスト済みです」という漠然とした声明に頼るよりも、はるかに実用的で意味のある対話につながるだろう。

AIを運用ワークフローに導入しようとしているチームにとって、Bloomのような構造化された評価フレームワークは、高コストな手戻りを減らし、危険な振る舞いが顧客やシステムに到達する前に発見するのに役立つ。AnthropicがBloomとPetri、そして技術レポートを公開したことは、AIの振る舞い評価に対する体系的なアプローチを、より詳細な検証と再利用のために利用可能にしたという意味で非常に意義深い。BloomのMITライセンスコードと文書化されたパイプラインは、関連する構成、モデルへのアクセス、インフラ、そしてアプリケーション固有のレビューを適切に提供できれば、チームが場当たり的なAIテストから脱却し、より堅牢なAIシステムを構築する手助けとなるだろう。