AIコーディング可視化、New Relic Preflight無料公開

Claude Codeでコードを書いていて、ふと不安になる瞬間がある。このセッション、結局いくらかかったんだろう。同じエラーに3回も引っかかった気がするけど、それって私の指示が悪いのか、AIの癖なのか。セッションを終えるたびに、なんとなくモヤモヤが残る。

そんな疑問に、New Relicが答えを出してきた。2026年6月8日に米国で初回発表し、6月23日から無料公開しているオープンソースツール「Preflight」だ(New Relic公式ブログ)。日本では7月30日に、同社の調査レポートとあわせて紹介されている。6月8日の初回発表から日本語プレスリリースまで、52日の開きがある。時系列を整理しながら見ていきたい。

このツールが向き合っているのは、バイブコーディングを続けている人なら誰でも薄々感じている課題だ。AIコーディングは便利だが、コストと品質の実態が見えていない。私自身、業務ツールを作りながら何度もその不安にぶつかってきた。「動いたから良し」で終わらせてきたセッションが、実際はどれだけの回り道をしていたのか。今回はそこに数字で光を当てたい。

New Relicの調査が突きつけた、レビューは高評価でも本番で壊れる矛盾

まず押さえておきたいのが、New Relicが同時期に公表した調査だ。名前は「The 2026 State of AI Coding Report」の日本語版という。米国企業のIT・エンジニアリング分野の意思決定者200人を対象にした調査で、いくつもの数字が並んでいる。

もっとも目を引くのが、レビュー負荷が441%増えたという結果だ。AI生成コードの25%以上に大幅な修正が必要だったと回答した企業は74%にのぼる。86%の組織で、シニアエンジニアが手戻り対応に時間を取られているという。レビューする側の負担が、AI導入前とは別次元になっている。

さらに厄介なのは、本番環境での話だ。AIコーディングを導入した企業の78%が、本番環境でのインシデント増加を報告している。深刻な障害の発生率は、導入前の1.7倍に拡大したという(The 2026 State of AI Coding Report 日本語版)。

ここで矛盾が生まれる。同じ調査で、リーダーの94%がAI生成コードを人間の書くコードより高品質だと評価しているのだ。内訳は「やや高品質」が61%、「かなり高品質」が33%だった。レビューの場では高く評価されているのに、本番に出した瞬間に壊れる。

New Relicはこの現象を「Agent Debt(エージェント負債)」と呼んでいる。AIが生成した未検証のコードが積み上がり、その後始末がシニアエンジニアに集中している状態を指す言葉だ。正直、この数字を読んだとき、自分のことを言われている気がした。私も業務ツールをClaude Codeで作っていて、「動いた、完成」で満足してしまう瞬間がある。だがその「動いた」が、本番で何を踏んでいるかまでは、感覚では追い切れていなかった。

ここで1つ、正直に断っておきたい。この調査はNew Relic自身が実施し、公表したものだ。可観測性ツールを売る会社が、可観測性の必要性を訴える調査結果を出している。数字自体を疑う理由はないが、課題の深刻さが強調される方向にバイアスがかかりやすい構造ではある。数字の出どころが当事者企業であることは、頭の片隅に置いたうえで読み進めたい。

なぜ「レビューは高評価、本番で壊れる」が同時に起きるのか

この矛盾の正体を、私なりに分解してみる。ポイントは、レビューという行為の性質にある。レビューは「読んで良さそうかどうか」を判定する作業であって、「実際にどう動くか」を保証する作業ではない。

AIが生成したコードは、構文的に整っていて、命名も丁寧なことが多い。コメントも適切に見える。人間のレビュアーが目で追う分には、違和感を持ちにくい。だが、その裏でどんな試行錯誤があったかは、コードの見た目には残らない。何度も書き直した末にたまたま動いた実装なのか、最初から筋の良い設計だったのか。完成形からは区別がつかないのだ。

私自身、AIコーディング暴走4事例、9秒でDB全消しから逆算する安全設計5手順で、AIの暴走が一瞬で致命的な結果を生む事例を整理したことがある。あのとき書いた教訓は、動いた後の検証プロセスを人間が握っておくことだった。今回の調査結果は、その検証プロセスがレビュー止まりになっている実態を数字で裏付けている。実行時の挙動まで見えている企業は、まだ少数派なのだろう。

具体的に想像してみる。エラーが1つ出て、AIが直す。動いたように見えたので、次のタスクに進む。だが実は、その修正の裏で同じファイルを5回読み直し、無関係な箇所も2箇所書き換えていたとする。レビュー担当者は、最終的なコードの差分しか見ない。差分がきれいであれば、そのまま承認してしまう。プロセスの乱雑さは、差分には残らないのだ。

つまり、必要なのはレビューをもっと厳しくすることではない。レビューでは原理的に見えない部分を、別のレイヤーで可視化することだ。セッション中に何を試し、何にコストを使い、どこでつまずいたか。それがPreflightの狙いだと理解すると、このツールの立ち位置がはっきりする。

Preflightは何を測るのか、OSSダッシュボードの中身

Preflightは、AIコーディングアシスタントに直接フックするMCPサーバーだ。MCP(Model Context Protocol)は、AIツールが外部のデータやサービスとやり取りするための共通規格だ。最近のAIコーディングツールの多くが、この規格を採用している。公開場所はGitHubのnewrelic-experimentalリポジトリだ(GitHubリポジトリ)。ライセンスはApache-2.0で、完全なオープンソースとして公開されている。

対応するツールの幅も広い。Claude Code、Cursor、GitHub Copilot、Windsurfはもちろん対応済みだ。Zed、Continue.devやAmazon Q Developer、Amazon Kiroにも対応の輪が広い。ただし公式リポジトリのREADMEは「対応範囲はツールごとに均一ではない(Coverage isn’t uniform)」と明記している。主要対応ツールの幅は広いものの、記録できる情報の粒度はツールごとに差がある点は留意したい。特定の1ツールに縛られず、複数のツールを併用している人でも横断的に記録を残せる点は大きい。

記録される情報は、大きく3種類ある。1つ目はツール呼び出しの履歴だ。AIがファイルを読んだ・書いた・実行したという一つひとつの動作が残る。2つ目はコストで、セッション単位・日単位・週単位、さらにモデル単位でUSD建ての費用が積み上がっていく。3つ目が効率スコアとアンチパターン検知だ。同じファイルを何度も読み直す「re-read」、内容を確認せずに書き換える「blind edit」がある。同じ手を何度も繰り返す「手詰まりループ」も自動で判定される仕組みになっている。

これらはローカルのダッシュボード(localhost:7777)にリアルタイムで表示される。New Relicのアカウントを作らなくても、この時点で全機能が使える設計は好印象だ。チームでの集計やアラート通知が必要になったときだけ、New Relic本体のバックエンドに接続するオプションが用意されている。デフォルトはオフラインで完結する。まず個人のPCで試して、必要になったらチームに広げる。そういう段階的な導入がしやすい設計になっている。

もう1つ、オープンソースであることの意味も書いておきたい。コストや効率のデータは、開発の中身に直結する機微な情報だ。ブラックボックスの有償SaaSに預けるのは、正直気が引ける。Preflightはコードが公開されているので、何がどう記録されているかを自分の目で確認できる。ローカル完結が基本という設計思想とあわせて、データの扱いに対する不安が小さい点は、個人開発者にとって地味に重要なポイントだと思う。

エンタープライズのガバナンス潮流が、個人開発者にも降りてきた

こうしたAI活用の効果測定は、これまで企業のエンタープライズ導入で先行してきた領域だ。以前、AIエージェント効果測定、SAP実測92.92%と10万件自動化の中身で紹介した事例がある。大企業はすでにKPIを定め、AIエージェントの成果を数値で管理し始めている。稼働率や自動化件数を経営指標として追う体制が、一部の先進企業では当たり前になりつつある。

こうした計測基盤は、これまで社内に専任チームを置ける規模の会社でしか整備できなかった。ダッシュボードを作るエンジニアを確保し、どの指標を追うかを設計し、経営層への報告フォーマットまで整える。相応の予算と人手がかかる話だった。

Preflightが面白いのは、その「測る文化」をエンタープライズの外に持ち出してきた点だ。専任のアナリストもダッシュボード構築のエンジニアも必要としない。1人の開発者が、自分のノートPCの上で同じ発想を再現できる。企業がコンサルとツール導入に予算をかけて実現していたことに、個人がタダで手を伸ばせる時代になった。

大企業と個人とで、抱えている課題の根っこは同じだ。AIにどれだけ頼っていて、それが実際にうまくいっているのかを、感覚ではなく数字で把握したい。その欲求に応える手段が、ようやく個人のレベルにまで降りてきたということだと捉えている。

1分で動く、ローカルで完結するPreflightの始め方

公式ドキュメントによれば、セットアップウィザードはデフォルトでローカルモードを選ぶ設計だ(GitHubリポジトリ)。表示される質問にひたすらEnterを押していくだけで、1分もかからずに終わるという。アカウント登録も不要だ。この手軽さは、バイブコーディングを日常的にやっている身として素直に助かる。

ここで、私が過去に他のMCPサーバーを導入したときにハマったポイントを先に共有しておきたい。MCP対応ツールは種類によって、設定ファイルの置き場所が微妙に違う。Claude Code用の設定とCursor用の設定を混同して、片方にしか反映されずに「動かない」と勘違いしたことが何度かある。Preflightを複数のツールで併用する場合は、それぞれの設定ファイルに個別に接続情報を書き込む必要がある点に注意したい。最初に頭に入れておいたほうがいい。

もう1つ、地味に効くのが「いつから記録が始まるか」という点だ。導入した瞬間より前のセッションは、当然ながら遡って記録されない。効率スコアやコストの週次トレンドを見るなら、思い立った日にまず入れておくのが一番だ。「来月から本気出す」は、この手のツールでは通用しない。

導入した最初の1週間は、何を見ればいいのか迷いやすい。私が公式ドキュメントを読んで整理した限り、優先して確認すべき指標は3つに絞れる。1つ目はセッション単価だ。1回のタスクにいくら使ったかをまず把握し、極端に高いセッションがないかを確認する。2つ目はstuck loop(手詰まりループ)の発生回数だ。ゼロに近ければ、AIとのやり取りが噛み合っている証拠になる。3つ目はre-read(同じファイルの読み直し)の偏りだ。特定のファイルだけre-readが多発している場合、そのファイルの設計や命名がAIにとって読み取りにくい可能性がある。この3つを1週間分見るだけで、次に何を直せばいいかの当たりがつく。

私自身はまだ本格的な運用データを積み上げられていない状態だ。この記事の時点では「入れてすぐ動いた」という体験談までは書けない。だが公式ドキュメントを読む限り、詰まりそうな箇所は設定ファイルの重複くらいだ。導入自体のハードルは、高くなさそうだと感じている。実際に数週間使ってから、コストの推移や検知されたアンチパターンの中身は、続報にまとめる予定だ。

効率スコアとアンチパターン検知が変える開発習慣

Preflightが可視化する中で、個人的にもっとも興味があるのが効率スコアとアンチパターン検知だ。この2つは「AIが悪い」でも「自分が悪い」でもない。両者のやり取りの質そのものを数値化しようとしている点が面白い。

re-read(同じファイルの読み直し)が多いセッションは、AIが文脈を保持できていない可能性がある。何度も同じ情報を確認し直している状態だと考えられる。blind edit(内容を確認しない書き換え)が多い場合は、逆に確認を省略して雑に進めている可能性がある。どちらも、完成したコードの見た目だけを見ていては気づけない。

アラート機能も用意されている。コストが急に跳ね上がったとき、効率スコアが一定水準を下回り続けたとき、手詰まりループが指定回数以上検知されたときに通知が出せる。セッションが終わってから「あれ、今回やけに時間かかったな」と振り返るのではない。悪化している最中に気づける仕組みだ。

私が特に刺さったのは、手詰まりループの検知だ。AIに同じ修正を3回頼んで3回とも失敗しているとき、人間側も意地になって同じ聞き方を繰り返しがちだ。そこで一度立ち止まる。質問の仕方を変えるか、自分でコードを読みに行くかを判断するきっかけを、数字が与えてくれる。感覚に頼っていた「なんか今日は調子悪いな」を、再現性のあるシグナルに変えてくれる道具だと感じている。

個人開発者が今日から計測を始めるべき理由

ここまでの内容は、企業のガバナンス文脈で語られることが多い。だが私は、個人開発者や副業エンジニアこそ、Preflightのようなツールを先に入れておくべきだと思っている。

企業であれば、レビュー体制やセキュリティチームが、Agent Debtの一部を吸収してくれる。だが個人で業務ツールを作っている場合、自分が唯一のレビュアーであり、唯一のシニアエンジニアだ。手戻りに気づく仕組みを自分で持っていないと、Agent Debtは静かに積み上がっていく。

コスト面でも同じことが言える。個人の開発では、月々のAI利用料が家計に直結する。何にどれだけ使ったかが見えないまま、なんとなく高いなと感じている状態がある。そこからセッション単位で数字を追える状態に変わるだけで、判断の質が変わる。無駄に長引いたセッションを早めに切り上げる判断も、数字があってこそできる。

たとえば、月々のAI利用料が1万円だったとする。内訳が分からなければ、来月も同じくらいかかりそうだと漠然と構えるしかない。だがPreflightで週次のコストを追えるようになると、特定の1つのタスクだけが突出して高いといった偏りが見えてくる。その1タスクのやり方を変えるだけで、翌月の請求額を大きく下げられる可能性がある。感覚では見えなかった改善余地が、数字にすると急に具体的になる瞬間だ。

私自身、CS(カスタマーサクセス)出身で、数字を見て判断を変えるという行為には馴染みがある。顧客の利用状況を数値で追い、離脱の予兆をデータで捉える仕事をしてきた。その感覚を、自分のAIコーディングにもそのまま持ち込める。プロのアーキテクトのような設計判断はできなくても、数字を読んで次の一手を決めることならできる。これは、Preflightが私の得意分野と相性がいい理由でもある。

まとめ

New Relicの調査は、AIコーディングの「見た目の評価」と「本番での実態」が乖離している現実を、数字で示した。レビュー負荷441%増、本番インシデント78%増、深刻障害率1.7倍。その乖離を埋める道具として無料公開されたのが、OSSのMCPサーバー「Preflight」だ。

• New Relicは米国で2026年6月8日に発表、6月23日に無料公開した。日本語での紹介は7月30日で、初回発表から52日が経過している
• Claude Code・Cursor・GitHub Copilot・Windsurfなど主要ツールに対応し、ローカルダッシュボード(localhost:7777)でアカウント不要のまま使い始められる
• 記録されるのはツール呼び出し履歴・セッション単位のコスト・効率スコアとアンチパターン(re-read・blind edit・手詰まりループ)の3種類
• セットアップは公式ドキュメント上は1分程度。導入後1週間はセッション単価・stuck loop回数・re-read偏りの3指標をまず追うと、次に直すべき箇所の当たりがつく
• 企業のガバナンスだけでなく、個人開発者が自分自身のレビュアーとして使う道具としても価値がある

私はこの記事を書きながら、今日のうちにPreflightを自分の環境に入れることを決めた。動かしてみて分かったハマりポイントや、実際のコスト推移は、また改めて書きたい。まずは自分のAIコーディングが、レビューだけでは見えない部分でどう動いているのか、数字で確かめてみようと思う。