CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 04, 2026
1 min read
What is self-healing code? And how close we actually areの意訳です。
セルフヒーリングコード（自己修復型コード）とは、障害を検知し、根本原因を診断したうえで、人間の介入なしに修正を適用するソフトウェアのことです。
本番運用に耐える自動化は、セキュリティ脆弱性のパッチ当てやコンテナの再起動など、狭い領域の問題に対しては機能しています。とはいえ、完全に自律的な「検知・診断・パッチ・デプロイ」のループは、いまもおおむね理想にとどまっています。最先端モデルは、ベンチマーク汚染を減らすよう設計された難しい評価でも、複数ファイルにまたがるバグ修復タスクの一部を解けるようになっていますが、その性能は、このフレーズが匂わせる「完全自律」の水準にはまだ遠く及びません。
用語が約束するものと業界が提供できるものとの間にあるギャップは本物ですが、特定の領域では急速に縮まりつつあります。
AIコーディングエージェントは、コード生成を安く速くしました。残念ながら検証はそのスピードに追いついておらず、レビューのキャパシティが運用上のボトルネックになっています。CodeRabbitはAI vs. Humanレポートで470件のオープンソースのGitHubプルリクエスト（PR）を分析し、AIが生成したPRには全体としておよそ1.7倍の問題が含まれていることを示しました。PRあたりの問題数は平均10.83件で、人間のみが書いたPRの6.45件を大きく上回っています。
AIが持ち込む問題の量は、現場の運用に本物のプレッシャーを生んでいます。AIがより多くのバグを生み出すのなら、AIにそれを直してもらってもよいのではないか、という発想もあります。本番運用のチームは、まだそのループを安定して閉じきれていません。チームがこのプレッシャーに対して取っている方策は、より強力なレビューです。SalesRabbitは、引き継いだコードベース全体にAI支援のレビューを導入した結果、バグを少なくとも30%減らし、デプロイ速度を少なくとも25%向上させました。
セルフヒーリングのアプローチの中には、コードを変えないまま、障害をしのいでアプリケーションを動かし続けるものがあります。一方で、根本にあるバグを修正して再発しないようにするものもあります。この2つのアプローチを混同してしまうことが、「セルフヒーリング」が本当に何を提供するかについて、現実離れした期待を生み出すのです。
セルフヒーリングコードを次の4つのカテゴリに分けると、その軸に沿って整理できます。
| カテゴリ | 修復対象 | コードを変更するか | 根本原因を直すか |
| インフラのセルフヒーリング | プロセス／コンテナの可用性 | しない | しない |
| ランタイムのセルフリペア | 実行パス／アプリケーション状態 | しない（あらかじめ書かれたパス） | 部分的（想定済みの障害のみ） |
| 自動プログラム修正 | ソースコードの欠陥 | する | する |
| セルフヒーリングテスト | テストロケータ／テストコード | する（テストコード） | 該当なし |
インフラのセルフヒーリング： Kubernetesは、失敗したコンテナを再起動し、ワークロードを再スケジュールして、望ましい状態を維持します。プロセスの可用性は回復しますが、アプリケーションのロジックは変わらないため、同じバグが同じ再起動サイクルを繰り返し引き起こすことがあります。
ランタイムのセルフリペア： サーキットブレーカーや、指数バックオフを伴うリトライロジックが代表例です。このカテゴリでは、開発者が事前に回復のパスを書き込んでおきます。システムは実行時に新しいコードを生成しません。
自動プログラム修正（Automated Program Repair。以下APR）： APRは、学術文献における「セルフヒーリングコード」のもっとも技術的に厳密な使い方です。APRは、ソースコードの欠陥を修正するパッチを生成し、適用します。テストケースが仕様の役割を担います。この4分類の中では、APRがコードベースの根本原因にある欠陥を直接扱います。
セルフヒーリングテスト： 自動化されたテストスイートが、テスト失敗が本当のリグレッションではなくUIのリファクタリングに起因することを検知し、それに合わせて自身を更新します。このカテゴリが修復するのはテストコードです。
誰かが「セルフヒーリングコード」と言っているときは、4つのうちどのカテゴリを指しているのかを確認するとよいでしょう。
セルフヒーリングの実装はどれも、フィードバックループの一形態です。システムが障害を検知し、原因を診断し、是正アクションを適用し、復旧を検証します。
このループは、4つのパートからなります。
検知と診断： モニタリングのシグナル（メトリクス、ログ、トレース、ヘルスチェック）が異常検知システムに流れ込みます。しきい値ベースのアラートは既知の障害モードを扱い、機械学習ベースの偏差検出は未知のシグナルを扱います。障害が検知された後の診断は、単純なルールベースの照合から、コードの意味について大規模言語モデル（LLM）に推論させるものまで、幅広い形を取ります。
修復： インフラの障害は、再起動と経路の切り替えで対処されます。設定の問題は、フィーチャーフラグの切り替えで対処されます。コードの欠陥は、APRのパイプライン（障害の局所化、パッチ生成、テストによる検証）を通ります。
検証： もっともらしいパッチはすべてのテストを通します。正しいパッチは、根本にあるバグを修正します。両者の間にある隙間こそが、AIコードレビューの居場所です。テストスイートが見逃すものを、パッチがマージされる前に捕まえる役割です。Abnormal AIは、自律エージェントの出力をマージ前にレビューへ通すことで、クリティカル重要度のコメントの受け入れ率を65%以上に保っていると報告しています。
セーフティゲート： 成熟した実装には、回数を制限したリトライやカナリアデプロイが含まれることが多く、リスクの高い変更については、人間へエスカレーションするパスが用意されています。
これら4つの段階は、どのセルフヒーリングシステムにとっても骨格となるものですが、それぞれが独自の成熟度カーブを描きます。検知はおおむね解かれており、修復は部分的に解かれており、検証は依然としてもっとも難しい連結点であり、セーフティゲートは、チームがどこまで責任を持って自律性を委ねられるかを決めるものです。各構成要素が現時点でどこに立っているかを理解することは、「ループ全体を本番運用させるまで、私たちはどれだけ近づいているのか」という、より大きな問いの土台になります。
セルフヒーリングコードは、ベンチマークの点数から想像されるよりも本番運用の現実に近づいていますが、用語が匂わせる範囲よりも狭い領域においてです。本番での利用とベンチマーク性能を切り離して見ることが、現時点での境界線を正しく把握する唯一の方法です。
もっとも強い証拠が得られているのは、セキュリティ脆弱性のパッチ当てです。自動チェックとリリース前の人間の承認を組み合わせた、セキュリティに範囲を絞った狭いワークフローでは、自律的な修復が機能しています。インフラの自動修復にも、成熟した例があります。Kubernetesは、アプリケーションロジックを変えずに、ワークロードの可用性を回復させます。
きれいに整えられたベンチマークの結果は、より難しい評価よりもずっと強く見えます。難しい評価は、汚染を減らし、現場のリポジトリに似せるよう設計されています。そうした難しいタスクセットでは、性能が大きく落ちます。ベンチマークの勝利は、まだ本番運用での頼れる自律修復には、きれいに直結しません。
多くのベンチマーク結果は、障害の局所化が完璧であることを前提にしています。つまり、バグがどこにあるのかをモデルに正確に伝えてから測っているのです。この前提を外すと、修復性能は急激に落ちます。モデルは、まず自分で欠陥を見つけなければならない状況になるとずっと弱くなります。欠陥を直接指し示してもらえるかどうかで、難しさはまったく別物になります。
Googleが社内のバグに対して行ったPasserineエージェントの評価は、現場の性能にもっとも近づいたケーススタディの1つです。ここでも、ベンチマーク結果と現場のエンジニアリング作業との間に、同じギャップが見られます。一見もっともらしく見える多くのパッチは、現場のエンジニアリングワークフローの条件にさらされると、有効な修正としては持ちこたえません。
大規模な実証研究では、LLMが生成したパッチと人間のパッチの違いを、セキュリティ関連の問題に対する扱いも含めて検討しています。その証拠は、現場の設定下で複雑なセキュリティ関連のバグ修正にLLMを適用するのは、依然として難しいことを示しています。
以下のステップは、それぞれが前のステップの上に積み上がります。決定的な復旧から、制約付きのAI自律性へと進んでいき、AIに与える余地が大きくなるほど、検証も強くしていきます。
セルフヒーリングはフィードバックループです。検知（見えないものは直せません）とロールバック（自分で巻き戻せない自動化は信頼できません）がなければ、ループは機能しません。他のすべてを動かす前に、次の4つを整えておく必要があります。
これは、これ以降のすべてのステップの前提条件です。これを飛ばすと、自動化は失敗をより速く起こすだけのものになってしまいます。
サーキットブレーカー、指数バックオフでのリトライ、インフラの自動再起動（Kubernetes流のセルフヒーリング）は、AIなしでも、よく起きる障害の大半を捌けます。これらのパターンは、10年以上にわたって本番運用に耐える品質を保ってきました。インシデントレビューで何度もフラグが立つ障害から手を付け、復旧手順をコードに書き込みましょう。
決定的な復旧は、レビュー可能で、予測可能で、安価です。これで解ける問題に対しては、AIはオーバースペックです。
検知と決定的な復旧が機能するようになったら、変更を人間が承認する前提で、狭い領域にAIを足していきます。
どのケースでもパターンは同じです。AIが提案し、人間が決め、変更は巻き戻せる。この段階を使って、AIの出力に対する信頼を、より大きな自律性を委ねる前に積み上げていきます。
AIにより大きな自律性を委ねる前に、レビュー層がテストの見落としを捕まえられるようにしておく必要があります。検証ギャップこそが、AI修復をどこまで安全に自動化できるかを決めます。ここで活躍するのがコンテキストを踏まえたAIコードレビューです。AIが生成したPRかどうかに関わらず、すべてのPRについて、差分全体をリポジトリの履歴やチーム基準と突き合わせて解析します。
脆い、あるいは遅いレビュー層は、AI修復が広がるにつれて検証の負債を増幅させます。強いレビュー層があれば、次の段階を自信を持って進められます。
検知、ロールバック、決定的な復旧、狭いAI、強いレビュー層が揃ったら、AIにより制約のある仕事を任せられるようになります。制約付きのCIデバッグループは、典型的な次のステップです。エージェントが、サンドボックス化されたワークスペース内で失敗したテストを実行し、修正を提案し、リトライ回数の上限の範囲内で再実行します。ループが収束しなければ、その仕事は人間にエスカレーションされます。
この制約こそが、これを安全にしているものです。エージェントはワークスペースの外には出られず、マージの判断は依然として人間が握っています。
現時点での上限は、エージェント主導の修復です。それでもリリースの最終判断は開発者が握ります。1つのエージェントがコードを書き、レビューエージェントがその差分を集中的にテストします。修正はPRに反映され、人間が何をマージするかを決めます。
ここから先にあるのが、用語が匂わせる「完全自律」のセルフヒーリングです。業界はまだそこには到達しておらず、いまの位置とその先を隔てているのは、検証のギャップです。
現時点で有用な結果を出しているパターンは5つあり、いずれも狭い問題領域に範囲を絞っています。
PRでの自動セキュリティパッチ。 セキュリティパッチは、自律的なコード修復に関してもっとも事例の蓄積が厚い領域の1つです。システムが明確に定義された脆弱性クラスに範囲を絞られていて、変更が依然としてレビューを通る前提のとき、もっともうまく機能します。
自動ロールバック付きのフィーチャーフラグ。 ランタイムでの切り替えにより、再デプロイのサイクルを丸ごと回す必要なく、即座にロールバックできます。
セルフヒーリングのテストロケータ。 UIのセレクタが壊れたとき、機械学習ベースのツールが置き換えのロケータを見つけます。サイレントなコミットではなく、人間が承認するための候補として提示します。
制約付きのCIデバッグループ。 エージェントが、失敗したテストを実行し、エラー出力を読み、修正を提案し、サンドボックス化されたワークスペース内で、リトライ回数の上限の範囲内で再実行します。
SRE（サイトリライアビリティエンジニアリング）のプレイブック自動化。 アラートシステムは、繰り返し発生する運用障害に対して、スクリプト化された修復とロールバックのワークフローを発火させられます。
5つのパターンを貫いているのは、同じ筋道です。どれも、問題領域が狭く、障害モードがよく理解されていて、AIが生成した変更と本番環境の間に、人間か自動のセーフティゲートが挟まっているから機能しています。自律性は本物ですが、制約付きの本物です。
テストによる評価では、間違ったパッチをすべて捕まえることはできません。そのギャップこそが、今日のセルフヒーリングツールと、用語が匂わせる完全自律版とを隔てています。CodeRabbitのレポートは、全体の問題ギャップをカテゴリごとに分解しています。ロジックと正しさのエラーは、AIが書いたPRで75%多く見られます。可読性の問題は3倍以上に跳ね上がっており、どのカテゴリよりも大きな差となっています。これが、生成された修正が、表面的には動いているにもかかわらずレビューを遅くしうる理由を説明しています。
SalesRabbitとAbnormal AIは、チームがAIコードレビューを検証ループの内側に置いたときに、測定可能な成果が出ることを示しています。レビューは、最後だけに現れるのではなく、ループの中心、生成のすぐそばに座っています。
セルフヒーリングコードは、これから意味のある形で良くなっていきます。検証は、依然として未解決のパートです。いまもっとも自信を持ってリリースしているチームは、ループのあらゆる段階に検証を組み込んでいます。AIがコードや修正を生成する。コンテキストを踏まえたレビューエージェントが、差分全体とリポジトリのコンテキストにわたって、それを集中的にテストする。開発者が、何をマージするかを決める、という流れです。CodeRabbitはプルリクエストをレビューし、統合開発環境（IDE）、コマンドラインインターフェイス（CLI）、Slackをまたいで動きます。
AIが書いたコードをリリースしているエンジニアリングチームは、AIの出力ペースに追いつける検証層を必要としています。コードレビューの時間とバグを減らしましょう。14日間の無料トライアルをはじめてみる。
