AIスピードと外部制約の前に、人間の目視と事後対応が限界を迎えるとき

マルチリポ環境でAIが生むレビュー地獄、Qodoはどう切りに行くか

マイクロサービスを日々書いている身からすると、Qodoが今回出した機能は刺さるポイントが明確だ。リリースされたのはCross-Repo Code Review、Custom Rules Miner、Skill Review Standardsの3つ。どれもAIがコードを大量生産するいま、レビューの限界をどう超えるかという問いへの回答になっている。

モノリスからマルチリポへの移行は、チームの所有権を明確にする。だが代償として、リポ間の繋がりによるバグが人間にのしかかる。あるリポの1行変更が、別チームが依存するアーキテクチャ不変条件を黙って壊す。500行の差分を斜め読みするレビュアーにそれが見えるはずがない。QodoのCEOであるItamar Friedmanが指摘する通り、トランジティブな依存のバージョンアップを追うだけで2日を溶かすこともある。

ここにAIが加わって状況がさらに悪くなる。Google DORA 2025のレポートによれば

（DORA: DevOps Research and Assessment。ソフトウェア開発チームのパフォーマンスを測定する業界標準の指標）、AIを多用するチームのPRは154%大きく、レビュー時間は91%長く、バグは9%多く出荷される。人間のペースで作られたガバナンスが、エージェントのスピードに追いつかないのだ。

だからこそCross-Repo Code Reviewの存在意義は理解できる。リポジトリ境界を越えた破壊的変更をマージ前に捕捉するという。共有ライブラリのシグネチャ変更やスキーマ変更が下流にどう響くか。これを単一リポのレビューで見抜くのは最初から無理があった。

一番面白いと感じたのはCustom Rules Minerだ。コーディング標準がWikiやシニアエンジニアの頭の中にあり、強制不可能だった現状を変える。既存のコードベースやPR履歴からパターンを自動で発見し、強制可能なルールにするという。ただ、ここは懸念もある。過去のコードが負債だらけだった場合、マイニングの結果として負債を正当化するルールが抽出される可能性はゼロではない。抽出されたルールの質を誰がどうレビューし、メンテナンスするのか。そこがワークフロー上の新たな論点になるはずだ。

AIエージェントのスキルを管理するSkill Review Standardsも、エージェントが組織の見えないところで動くのを防ぐ一歩としては妥当。AIがPRを溢れさせ、その爆風がマルチリポをまたぐいま、人間が目視で踏み止まる時代は終わったと言わざるを得ない。ツールに境界を跨がせるしかない。

GitHubのアクセシビリティ誓約、1年後の実践が見えてきた

GitHubが昨年掲げたオープンソースのアクセシビリティ誓約。障害のある人のOSS貢献を支える、支援技術の普及を高める、主流プロジェクトのアクセシビリティを改善する――3つの目標に対して、具体的な取り組みが動いている。

ハッカソンがひとつの形になった。2026年5月、サンフランシスコのGitHub本社でOpen Source Assistive Technology Hackathonを開催。2日間で貢献者やメンテナ、障害当事者が集まり、実際のアクセス障壁に取り組んだ。プロジェクトは多岐にわたる。カメラベースの視覚支援、PDFからアクセシブルなフォーマットへの変換ワークフロー、車いずれのオープンなソフトウェアとハードウェア、スクリーンリーダーの発音改善、アクセシブルなゲーム、複数行点字ディスプレイ向けの触覚体験。現場の課題に根ざしたラインナップだ。NV Accessチームによるオフィスアワーも設けられ、NVDAスクリーンリーダーのトラブルシューティングをその場で実施。学習環境としてGitHub Learning Roomも開設し、スクリーンリーダーやキーボードのみの操作を手取り足取りサポートした。

CIにアクセシビリティを組み込む流れも地味に重要だ。Open Source Accessibility組織がロードマップとコラボレーションの場を提供し、ベストプラクティスガイドではACCESSIBILITY.mdの作成やCIへのアクセシビリティ統合を推奨している。GitHub Accessibility ScannerはAIを活用したオープンソースツールで、GitHub ActionsとGitHub Copilotを使ってアクセシビリティの障壁を検出・起票・修正まで行う。Figma向けのAccessibility Annotation Toolkitも公開され、デザインから実装までアクセシビリティを織り込む流れが整いつつある。

2025年10月にはRaleighでOpen Source Accessibility Summit 2025をAll Things Openと共に開催。障害者・アクセシビリティ・OSSコミュニティのメンバーが集まり、OSSのアクセシビリティ改善に向けたロードマップを定義した。誓約から実践への転換点としては妥当な方向に見える。ただ、ロードマップの具体の中身が記事からは読み取れない。どこまで合意形成が進んだのか、今後のイベントで掘り下げられるのだろう。

直近の参加機会は2つ。2026年7月9日のOpen Source Accessibility Community Dayはバーチャル開催で、ハッカソンプロジェクトのデモと更新情報が中心。2026年10月19日にはRaleighでOpen Source Accessibility Summitを再び開催予定。アクセシビリティベストプラクティスに沿ったOSS貢献の方法をレベル問わず教える設計らしい。

個人的に気になるのは、GitHub Accessibility ScannerがCIパイプラインにどう馴染むか。GitHub Actionsで動くなら既存のワークフローに組み込みやすい。ただ、検出結果の精度や誤検知の頻度、修正提案の実用性は実際に回してみないと分からない。ACCESSIBILITY.mdも、置くだけなら形骸化しやすい。レビュープロセスやCIチェックと連動して初めて意味を持つはずだ。誓約が実践に変わるかどうかは、こうした土着の仕組みが現場に根付くかどうかにかかっている。

Google Analyticsをやめて内製トラッキングサービスに移行した話

Delivery HeroがGoogle Analytics（GA）をやめて、自社のユーザートラッキングサービスへ移行した。きっかけはUniversal Analytics（UA）の終了だ。GA4への移行作業がどうせ発生するなら、いっそ内製に切り替えよう。そう判断した。

なぜGAを捨てたのか。一番の理由はリアルタイム性だ。広告の課金データなど、リアルタイムで欲しい情報がある。GAは1日1〜2回しかデータを出さない。これではビジネスに使えない。イベント定義の上限も問題だった。大規模に使うと上限に引っかかる。内製なら無制限に定義できる。GDPRの問題もある。

（EU一般データ保護規則。個人データの収集・処理に厳格な制限を課す法規制）第三者にデータを預けられない法的制約があった。

アーキテクチャの推移が面白い。モバイルSDKとTypeScriptのフロントエンドSDKからAPIへデータを送る。APIからはPub/Sub経由でストリーミングし、BigQueryに保存する。当初はAPIと2つのプロセッサだけという極めてシンプルな構成だった。スケーラブルで、問題もゼロ。最初から作り込まない。バックエンドエンジニアとして、この判断は腑に落ちる。

結果はどうなったか。データ品質を示す「オーダーマッチレート」が85%から91%へ6%向上した。課金に直結するデータなら、6%の向上は金額としてデカい。コストも25%削減。GA時代の2倍の負荷を捌いているのに、である。データロストのインシデントもゼロで移行を終えた。

サードパーティの制限がビジネスのボトルネックになるなら、内製は有力な選択肢だ。特にリアルタイム性やデータ保管場所が要件に絡む場合、GAでは満たせない。ただし内製はメンテナンスコストがかかる。Delivery Heroは「シンプルな構成で始めて、後からデータ検証などのサービスを足す」アプローチをとった。最初から大規模な基盤を作り込む必要はない。制限にぶつかったとき、シンプルな内製で置き換える。そんな選択肢も現実味があるのではないか。

Spring ToolsがClaude Code Pluginを試験導入、Hibernateは行レベルセキュリティでマルチテナンシーを変える可能性

6月15日時点のJavaエコシステムで、いくつか気になる動きがあった。

Spring Tools 5.2.0が実験的機能としてClaude Code Pluginを追加した。組み込みMCPサーバーと

（MCP: Model Context Protocol。AIモデルが外部データやツールに標準化された方法でアクセスするためのプロトコル）Claude code skillsを提供するという。IDEの中にAIエージェントがコードを操作する経路を公式に作ったことになる。Spring AIのサポートも入っているので、Spring BootでAI機能を組み込むチームは開発体験が変わるだろう。型安全なプロパティ参照の自動リファクタリングも地味にうれしい。文字列ベースのプロパティ参照をタイプセーフに変換してくれるので、設定ミスの実行時発見が減るはずだ。

Hibernate ORM 8.0.0 Beta1は要注目。Jakarta Persistence 4.0-M5を実装しているが、個人的に面白いのは行レベルセキュリティの対応。discriminator-based multi-tenancyの

（マルチテナンシー：単一のアプリケーションインスタンスで複数の顧客（テナント）を分離して管理する設計。discriminator-basedは、カラム等の識別子でデータを区別する手法）可視性ルールを、PostgreSQL・Db2・SQL Server・CockroachDBの行レベルセキュリティ機能で強制できるようになった。これまではアプリケーション側でテナントフィルタをかけるしかなく、漏れがあれば別テナントのデータが見える事故が起きた。データベース側で強制できるなら、そのリスクを構造的に消せる。グラフベースのフラッシュ調整も気になる。挿入・更新・削除をドメインモデルのリレーショナル制約を使って計画するそうだ。どういう順序最適化が入るのか、ベータが進んだら詳しく見たい。

Quarkusは緊急メンテナンスリリースを5つのリリーストレーンに出している。CVE-2026-50559への対応。エンコードされたセミコロン(%3B)でマトリックスパラメータをセキュリティレイヤーの背後で送り込める。エンコードされたスラッシュ(%2F)やバックスラッシュ(%5C)で保護された静的リソースにアクセスできる。CVE-2026-39852の関連脆弱性だ。3.20から3.37まで幅広くパッチが出ているので、該当バージョンを使っているチームはすぐ上げたい。

Commonhaus FoundationにOkHttp・Okio・Retrofit・SQLDelightが参加した。Squareのライブラリ群がコミュニティ基盤に移る流れ。OSSライブラリのサステナビリティ問題への具体的な回答であり、企業依存のリスクを減らす意味がある。

Open Liberty 26.0.0.6は2つのCVEを修正。サービス運用妨害と認証バイパスの可能性。Apache TomEE 11.0.0-M1はJakarta EE 11とMicroProfile 7.1に対応したが、OpenJPAがまだJakarta EE 10止まり。完全なEE 11互換にはもう一段必要そうだ。

eBPFは「安全なカーネル拡張」から「事前防御の武器」に変わっている

Dan FineranがInfoQのポッドキャストでeBPFの現在を語った。Isovalent（現在はCisco傘下）のコミュニティチームに属し、CiliumやTetragonの開発に関わる人物だ。話の骨子はシンプル。eBPFはもうパケットフィルタの話ではない。

元々はBerkeley Packet Filterとして始まった技術だが、今やカーネルを安全に拡張する汎用メカニズムに変貌した。鍵になるのが「verifier」と呼ばれるセーフガード。eBPFプログラムがカーネルの実行をブロックしたり、不正メモリにアクセスしたり、クラッシュを引き起こしたりしないかを検証する。カーネルモジュールの脆弱性や、アップストリームへの長いマージプロセスを回避できるというわけだ。

ここまでは多くの人が知っている話かもしれない。私が面白いと感じたのは、Tetragonが提示する「front-foot security」という考え方だ。従来のエージェントは事後監視が基本だった。イベントが起きてからログを見て対応する。一方eBPFはシステムコールにpre-hookをアタッチできる。バッファオーバーフローや不正なファイル削除を、カーネルが実行する前に傍受してブロックする。重大なCVEに対するライブパッチも可能になるという。

実務で何が変わるか。KubernetesクラスタでCiliumを入れているチームは多いだろう。でもネットワークポリシーだけでなく、セキュリティ強制のレイヤーとしてもeBPFを捉え直せる。アプリケーションコードに手を入れず、ファイルシステムやデバイスドライバの挙動まで可視化できる点は、インフラ寄りのエンジニアにとって魅力的だ。

もう一つ興味深いのは、eBPFがLinux専用技術ではなくなりつつあること。Windowsへのサポートが進んでおり、異種OS環境でオブザーバビリティとセキュリティポリシーを統一できる道が見え始めている。どこまで実用段階かは分からないが、注目しておく価値はある。

最後に、AI生成コントリビューションへの警告も挙げられていた。オープンソースのeBPFプロジェクトを評価する際、機能リストやPRの量ではなく、人間のメンテナコミュニティの強度と長期的なサポート体制を見よという指摘だ。AIが書いたコードが増える環境では、当然の注意と言えるだろう。

まとめ

AIがコードを大量生産するスピードに、人間のレビューが追いつかなくなっている。Qodoがリポ境界を跨ぐレビューを自動化したり、Spring ToolsがIDE内にAIエージェントの経路を公式に作ったりするのは、人間の目視でガバナンスを効かせる限界の表れだ。DORAレポートが指摘するPRの肥大化やレビュー時間の増大は、そのままバグの出荷増加に直結する。AIが動くスピードに合わせて、制御もツールに組み込まざるを得ない。

この「構造的な強制」は、セキュリティやインフラの領域でも顕著だ。Hibernateが行レベルセキュリティでテナント分離をデータベース側で強制できるようになったのは、アプリケーション側のフィルタ漏れという事後的なリスクを構造的に消す動きだ。eBPFもパケットフィルタから事前防御の武器に変わりつつある。Tetragonがシステムコールのpre-hookで実行前にブロックする仕組みは、ログを見てから対応する事後監視からの脱却を意味する。

サードパーティの制約に縛られず、自前で制御を取り戻す流れも共通している。Delivery Heroがリアルタイム性やGDPRの制約からGAを捨てて内製トラッキングに切り替えたのは、外部サービスの提供する枠がビジネスのボトルネックになったからだ。GitHubがアクセシビリティをCIパイプラインに組み込む推奨をしているのも、ドキュメントを置くだけの事後対応から、検出と修正をフローに強制する方向への転換だ。

AIが生成するコードやインシデントのスピードが上がるなかで、「人間があとで見る」「外部サービスの都合に合わせる」といった事後の前提が崩れている。マルチリポの境界を跨ぐバグも、テナントのデータ漏洩も、リアルタイムのデータ要件も、事後では追いつかない。実行前にブロックし、インフラレイヤーで強制し、制約になる外部を切り捨てる。そうした構造的な防御をどこに組み込むかが、これからの技術選択の軸になるはずだ。

参照記事

記録日: 2026-06-23