CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 04, 2026
1 min read
What is AI agent explainability? A 2026 SDLC primerの意訳です。
AIエージェントの説明可能性は、AIエージェントが現場の問題を解決するために本番投入されるか、それとも重要度の低い社内タスクの相棒にとどまるのかを左右します。これは、エージェントが判断に至った推論の道筋、検討した別の選択肢、そしてどの程度の自信を持っていたかを理解することに関わるテーマです。
AIが書いたコードをリリースしているエンジニアリングチームの多くは、いまブラックボックスを信頼している状態です。AIコーディングエージェントは、人間のレビュアーが意味のある形で読み切れる量を超えてPRを開きます。エージェントが差分を生成し、レビュアーや別のエージェントがコードをマージする。その間にエージェントがどのルールをチェックし、何をスキップし、なぜその変更がリリースしても安全だったのかを記録するものはありません。結果としてチームは、自分たちでは説明できない本番コードを抱え込むことになります。
AIが書いたコードを説明可能にすることは、いまやエンジニアリングの課題であると同時に、コンプライアンスの課題でもあります。本記事ではこの後、なぜ説明可能性はAIワークフローの生成側ではなく検証側のほうが構造的に扱いやすいのか、エージェント型ソフトウェア開発ライフサイクル（SDLC）で動かすAIエージェントが答えられるべき5つの問い、説明可能性がデリバリー指標に及ぼす効果、そしてSOC 2監査やEU AI Actのレビューに耐えるためにツールに求めるべきことを解説します。
エージェントがログに残す内容と、人間が本当に理解できる内容との間にあるギャップこそが、結局のところエージェント型プロダクトの普及を妨げる要因です。
説明可能性には、主に3つの役割があります。
ここでの主な受け手はユーザー本人ではありません。利用者のマネージャー、コンプライアンスチーム、顧客、あるいは6か月後に過去の判断を理解しようとしている未来の自分自身です。
エージェントの出力を検証する話になると、AIエージェントが生成したコードを検証するエージェントと、コードそのものを生成するエージェントとの間には大きな隔たりがあります。
生成エージェントは、次に来そうなトークンを予測することで、それらしく見えるコードを書きます。そのため、同じプロンプトでも毎回異なるコードが返ってくることがあります。検証エージェントが行うのは、これとは別の仕事です。出来上がったコードを、コードベースに置かれた既知のルールやポリシーに照らして判断します。
モデルの「temperature（温度）」設定は、加えられるランダム性の量を制御します。0より大きくすると、同じ入力でも実行ごとに異なる出力が返ってくる可能性があり、後から監査担当者に求められたときに再現するのが難しくなります。コンパイルされたAIシステムに関する研究では、temperatureが0であっても、実行ごとに出力が変わりうるという証拠が挙げられています。つまり、生成エージェントは監査に堪える安定した記録を残しません。再実行して、確実に同じ答えを取り戻すことはできないのです。
これに対して、検証エージェントの場合を比べてみてください。固定された入力と固定されたルールを与えれば、「ルールXがZ行目でパターンYに一致した」というような、追跡可能な判断が返ってきます。チームの誰でも、そのルールと変更されたコードから判断を再構築できます。検証エージェントの推論は、ルールの一致そのものであり、モデルの外側に存在する具体的な記録です。生成エージェントの推論はモデルの内側で起きたことそのものであり、後から推測することしかできず、まったく同じ形に再現することはできません。
VeriGuardフレームワークも、この2つの仕事を同じように分担させています。1つのエージェントが生成を担当し、もう1つのエージェントが最初のエージェントの出力をチェックします。チェックに失敗した場合、2つ目のエージェントはただ「ダメ」と言うのではなく、何が具体的に間違っているかを指し示します。
同じ分担は、本番運用でも見られます。AIネイティブなサイバーセキュリティ企業であるAbnormal AIは、AIが生成したコードと手書きのコードの両方にまたがる単一の強制層として、CodeRabbitを動かしています。チームは、CodeRabbitのクリティカル重要度のコメントを65%以上受け入れています。これがうまく機能するのは、AIが失敗するのは構文を間違えるためではなく、目の前のコードベース特有の事情を取り違えるためであることがほとんどだからです。だからこそ、そのコードベースのルールに照らしてコードをチェックするツールこそが、「なぜこれをフラグ立てしたのか」を説明できる立ち位置にいるのです。
エージェント型SDLCで動くAIエージェントはどれも、これら5つの問いに、差分に紐づいた現場の答えで応えられるべきです。
何を、なぜ変更したのか？ エージェントは、自分が評価した変更について、PRの中身に根ざした構造化されたウォークスルーを示すべきです。PRのタイトルをそのまま繰り返しただけの要約は、答えになっていません。
何をチェックしたのか？ エージェントは、どのルールが発火し、どのポリシーを参照したかを、それらのポリシーがバージョン管理のどこに置かれているかも含めて明示できるべきです。「学習データを使いました」という答えしか返ってこないなら、そのエージェントに説明可能性はありません。
何をチェックしなかったのか？ これがもっとも難しく、もっとも重要な問いです。誠実なエージェントは、自分のカバー範囲がどこで終わるのかを伝えてくれます。リンクされたJiraのチケットに照らして検証したのか？ 答えが返ってこないなら、あなたはブラックボックスを信頼していることになります。
自信の度合いはどれくらいか、そしてその数値は何に対して較正されているか？ 信頼度スコアがあれば、監査担当者は後から「人間にエスカレーションする」ルールが、本来発火すべきタイミングで発火していたかを確認できます。ただし、生の数値だけではほとんど意味を持ちません。モデルは、自信たっぷりに間違うこともあるからです。エージェントは、その数値が何を基準に測られているのかを語るべきです。
何が変われば、その推奨は変わるのか？ 役に立つレビューコメントは、どのような条件が満たされれば判断がひっくり返るのかを説明します。「同時に書き込む者がいない前提なら安全です」は説明可能ですが、「LGTM」だけでは説明可能とは言えません。
差分に紐づけた平易な言葉でこれらの問いに答えられないなら、そのエージェントは説明可能ではありません。
説明可能性は、1回のレビューにかかる時間を長くしながら、エンドツーエンドのデリバリーを改善することがあります。2025年のDORAレポート（約5,000人が回答）は、この緊張関係を明確に名指ししています。AIの導入は、デリバリーのスループット向上と相関する一方で、デリバリーの安定性低下とも相関するのです。回答者の30%が、AIの出力をほとんど、あるいはまったく信頼していないと答えています。
レビュアーがAIの生成したものを信頼できないとき、残された選択肢は2つしかなく、どちらも好ましくありません。1つは、すべてを手作業で再チェックすることで、これではAIが節約してくれるはずだった時間が打ち消されます。もう1つは、よく理解しないまま通してしまうことで、これでは本番環境に多くのバグが流れていきます。どちらも好ましくありません。抜け道は、エージェントが自分の作業内容を見せることです。そうすれば、レビュアーはツール全体を丸ごと信頼するのではなく、個別の検出結果を信頼できるようになります。
CodeRabbitのState of AIレポートでは、AIと共同で書かれたPRは、人間のみが書いたPRに比べて、PRあたり1.7倍の問題を生み出すことが分かりました。もっとも乱雑な上位10%のPRでは、その差は2.11倍まで広がります。何をチェックし、何をスキップしたかを伝えてくれるエージェントがあれば、チームはエージェントが本当にカバーした範囲に応じて、信頼の度合いを調整できます。
個人情報を多く含む出願データを扱うCommon Appは、レビュアーの手前に検証エージェントを置いています。これによってコードレビューにかかる時間を35%削減し、PRあたりの人間のレビュアー数を2人から1人に減らしました。ルーチンとなるチェックは、CodeRabbitが受け持っています。
エージェントが何をチェックしたかという記録は、何かが壊れた後にも役立ちます。検出結果がエージェントの適用したルールを名指しし、該当する行を正確に指し示してくれれば、チームはバグをより速く修正できます。問題を一からたどり直す代わりに、引用されたルールと行へ一直線に飛べるからです。修正にかかる時間がもっとも短くなるのは、PRがすでに問題でいっぱいになっているときです。さらに時間が経つにつれて、具体的で修正可能な検出結果を目にしていることが、レビュアーの信頼を育てます。エンジニアは、信仰として受け止めるのではなく、推論を直接確かめられるからです。
エンジニアリングリーダーにとって意味を持つ説明可能性は、運用層、つまりSOC 2監査やインシデント後のレビューで監査担当者が引用するログや記録に宿っています。このテーマを扱う多くの文章はモデルの話で止まってしまい、ここまでたどり着きません。
AIシステムに対するSOC 2監査では、AI特有の証跡が求められる場合があります。どのモデルバージョンが動いたかのログ、重要度の高い意思決定のそれぞれの記録、そしてモデルの振る舞いが時間とともにドリフトしたときにフラグを立てるモニタリングなどです。
変更管理の観点で、監査担当者の問いはあけすけです。ある変更を誰がレビューしたのか、いつレビューしたのか、そしてマージ前に組織のセキュリティポリシーを満たしていたことを証明できるのか。エージェントが自前で書き、自前で動かし、人間の承認がないまま流れていくコードは、現時点でこの問いに答えられません。
EU AI Actも同じ方向を後押ししています。高リスクシステムについては、ロギング、書面の技術文書、そしてシステムが本番稼働した後にその振る舞いを追跡できる能力を求めています。第113条のもとで、附属書III（Annex III）のシステムに対する高リスク義務は、2026年8月2日から適用される予定でした。2025年後半に提示された改正パッケージ「Digital Omnibus」は、2026年に暫定合意に至っており、Annex IIIの適用時期は先送りされる見通しです。エンジニアリングの論理とコンプライアンスのルールは、同じ方向を指しています。どちらも、誰が、何を、何を根拠に決めたのかについて、ログ化され、検査可能な記録を求めているのです。
アクセス制御と改ざん不可能なログは、規制当局がテストする隙間を埋めます。記録を十分な期間保持し、誰が何をしたかを証明します。これは、監査担当者から「あるマージを誰が、何を根拠に承認したのか」と問われたときに、VPが守らなければならない層です。CodeRabbitのEnterpriseプランは、この層を提供します。SOC 2 Type II認証、自社サーバー上で動かすオプション、コードを保持しないという保証、シングルサインオン、ロールベースのアクセス制御、エクスポート可能な監査ログが含まれます。これらが揃えば、SOC 2が期待する、人間の説明責任と承認に関する文書化された証跡が手に入ります。
社内構築の本当のコストをモデル化するとき、最初の構築スプリントだけでなく、保守チーム、モデルの評価サイクル、インフラ、セキュリティレビュー、社内サポートまで含めて考えると、数字は、プロジェクトを立ち上げるときに走らせるざっくりした概算とは、まったく違うものになります。
Cloudflareのエンジニアリングブログは、現場のスケールでAIレビューツールを社内構築した経験を、1人称で語っている貴重な事例です。Cloudflareのチームがぶつかった難所には、プラグイン同士を結線していく作業と、CI/CDパイプラインを安定して動かし続けることが含まれていました。それに加えてチームは、AIをどの程度信頼するかを較正する必要があります。2026年1月に公開されたEYのハルシネーション・リスクに関するガイダンスは、本番運用に向けた段階的な計画を、回答品質と出典明示の両方について具体的な目標値とともに示しています。
エンタープライズ向けAIプラットフォームのWriterは、自社でコードレビューを構築することを検討した結果、購入する道を選びました。チームリードの時間を節約できたこと、そして単一のスタイルガイドをチーム全体に強制できるようになったことを報告しています。
CodeRabbit自身の検証セットアップは、構築に数年を要しました。ドキュメントでは、50を超える個別ツール（静的解析ツールやセキュリティスキャナを含み、SASTはソースコードの脆弱性をスキャンするものです）を動かす層構造のコード解析を解説しています。これに加えて、モデルのオーケストレーションと、過去のフィードバックから学習するメモリも備えています。これらは、プラットフォームを使えば使うほど良くなっていきます。同等のものを社内で作り直すということは、その運用層全体を再現し、スケールに耐えるよう動かし続けることを意味します。
良いSDLCツールは、すべての判断について明確な記録を残します。どのルールを適用したか、そのルールがどこから来たのか、そしてコードのどの行に触れたかを正確に残します。その記録を出せないツールは、監査担当者とエンジニアがすでに突きつけている基準を満たせません。エージェント型SDLCの時代では、なおさらです。
CodeRabbitの検証アーキテクチャは、コードグラフ解析や監査ロギングを含めて、これらの記録をプラットフォームの一部として提供する一例です。とはいえ、どのツールを選ぼうとも、満たすべき基準は変わりません。
コンプライアンスの期限は本物で、エンジニアリング指標は測定可能で、構築コストは構造的に過小評価されがちです。だからこそ、どのような評価にも持ち込める判定基準はシンプルです。先ほどの5つの問いをエージェントに投げかけ、差分に紐づけた平易な言葉で答えるツールを選ぶこと。あらゆる行は、依然として自らマージされる価値を勝ち取らなければなりません。
GitHubとGitLabでもっとも多くインストールされているAIアプリで、コードレビューの時間とバグを50%削減しましょう。14日間無料トライアルからはじめてみる。
