「AIにコード書かせたら動いた。でもこれ、本当に大丈夫なのか？」

最近こう思うことが増えた。

僕は2026年に入ってから、開発の起点が完全に変わった。「まずClaude Codeにやらせてみよう」が口癖になった。自分で書くことからではなく、エージェントに任せることから始める。

便利だ。まじで便利。でもふとした瞬間に不安がよぎる。

AIが書いたコードを、僕はどこまで理解しているんだろう？

この記事では、Vibe Codingの品質課題をデータで確認する。その上で、解決策として注目されているAgent Engineeringの実践方法を紹介する。「AIに任せる開発」を否定するつもりはない。品質を担保しながら速さも活かす方法を一緒に考えたい。

Vibe Codingの現在地：データが示す品質リスク

まずは現状を把握しておこう。

2025年のStack Overflow調査（約49,000人が回答）によると、84%の開発者がAIツールを使用している。コードの約41%がAI生成だという推計もある。Vibe Codingはもはや一部の先進的な開発者のものではなく、主流の開発スタイルになった。

ただし、その裏には無視できないデータがある。

コード品質テストのイメージ Photo by Peter Masełkowski on Unsplash

CodeRabbitが470件のGitHub PRを分析（2025年12月発表）した結果、AI生成PRは人間と比べて約1.7倍多くの問題を含んでいた。特に深刻なのはセキュリティだ。XSS脆弱性は2.74倍、パフォーマンス非効率（過剰I/O）に至っては約8倍。

Veracodeの調査では、100以上のLLMをテストした結果、45%のAI生成コードがOWASP Top 10の脆弱性を含んでいたと報告されている。

さらに衝撃的なのは、METRの研究だ。16名の経験豊富なOSSコントリビューターが246のタスクに取り組んだところ、AIツール使用時に完了時間が19%増加した。開発者は事前に「24%短縮できるだろう」と予測していたのに、実態は逆だった。

僕自身も似た経験がある。Claude Codeにゴールが曖昧なまま指示を出すと、修正ループが増えるだけで全然効率的じゃない。人に説明してうまく伝えられないことは、AIにも伝わらない。その感覚はある程度正しいと思っている。

つまり、Vibe Codingは速く書ける。でも速く正しく書けるとは限らない。

ここが今、多くのエンジニアが直面している壁だ。

Vibe CodingからAgent Engineeringへ：Karpathyが示した転換点

では、この品質課題にどう向き合えばいいのか。

興味深い動きがある。Vibe Codingという言葉を2025年2月に生み出したAndrej Karpathy自身が、2026年2月に「vibe codingはpassé（時代遅れ）」と宣言した。そして新たに提唱したのがAgentic Engineeringだ。

Karpathyはこう言っている。

「agenticなのは、99%の時間コードを直接書かず、コードを書くエージェントをオーケストレートするため」

つまり、開発者の役割が「コードを書く人」から「エージェントを設計・監督する人」に変わるということ。

この考え方を補強する概念として、ハーネスエンジニアリングがある。Martin Fowlerのサイトでも紹介されている概念で、Agent = Model + Harnessという考え方だ。

わかりやすく言うと、こういうことになる。

  • モデル（Claude, GPT等）= CPU
  • コンテキストウィンドウ = RAM
  • ハーネス（制約・ルール・フィードバックループ）= OS
  • エージェント = アプリケーション

2025年は「エージェントがコードを書けること」が証明された年だった。2026年は「エージェントではなく、ハーネスが難しい部分だった」と判明した年だ。

僕もこの変化を肌で感じている。2026年に入ってから「ハーネスエンジニアリング」という言葉をよく聞くようになった。コーディングエージェントに留まらず、エージェント全体を制御する概念が次々と生まれている。正直、変化についていくのがやっとだ。

もちろん、Agent Engineeringにも課題はある。品質が本番環境の最大の障壁だと約3分の1のチームが指摘している。非決定論的な動作やトレーシングインフラの未成熟など、まだ発展途上の技術であることは間違いない。

ただ、方向性としては正しいと思う。では具体的にどう実践するか。

実践1：test-firstパターンでAI生成コードの品質を担保する

Agent Engineeringの最も基本的で、今日から始められる実践がある。

Simon Willisonが公開したAgentic Engineering Patternsガイドで詳しく解説されているtest-firstパターンだ。

やり方はシンプル。

ステップ1：まずテストを実行する

エージェントに新しい作業を始めさせる前に、たった4語のプロンプトを打つ。

First run the tests

これだけで3つの効果がある。

  • テストスイートがどこにあるか発見できる
  • プロジェクトの規模感を把握できる
  • テストを意識したマインドセットが確立される

ステップ2：Red/Green TDD

従来のTDD（テスト駆動開発）をエージェントに適用する。

  • Red: まず失敗するテストを書く（エージェントにテストを書かせてもいい）
  • Green: エージェントにテストを通すためのコードを書かせる

Willisonの言葉を借りれば、「コードが一度も実行されていなければ、本番で実際に動くかは純粋に運」だ。

ステップ3：CLAUDE.mdとHooksでガードレールを作る

CLAUDE.mdはエージェントの「憲法」のようなもの。ここにルールを書いておくと、エージェントが従ってくれる。

例えばこんな記述を追加する。

# テストルール
- 新しいコードを書いたら必ずテストも書くこと
- コミット前にテストが全て通ることを確認すること
- テストなしのコードはコミットしない

さらにHooksを使えば、エージェントの判断に関係なくガードレールを設けられる。コミット前にテストが通っていなければブロックする、といった設定が可能だ。

これは僕の実感とも一致する。ゴールが明確なほどClaude Codeは正しく動く。テストは「期待する動作」を明確にする最良の手段だ。曖昧な指示ではなく、テストでゴールを定義する。それだけでエージェントの出力精度が上がる。

実践2：マルチエージェントで「書く」と「検証する」を分離する

ここまでのtest-firstパターンは、1つのエージェントの中で品質を上げる方法だった。

次のステップとして注目されているのが、マルチエージェントオーケストレーションだ。「書く」「テストする」「レビューする」を別々のエージェントに分ける考え方。

人間のチーム開発と同じだ。1人が書いて、別の人がレビューする。これをAIエージェントで再現する。

Claude Code Agent Teams

Claude Codeには、2026年2月にリリースされた実験的機能「Agent Teams」がある。

  • 1つのセッションがチームリーダーとして機能
  • 独立したチームメイトを生成し、各自が独自のコンテキストウィンドウを持つ
  • ピアツーピア通信が可能で、共有タスクリストで依存関係を追跡

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化できる。

oh-my-claudecode

もう1つ注目なのが、GitHub Trending #1を獲得したoh-my-claudecodeだ。

  • 複数のClaude Codeインスタンスを並列実行
  • 各インスタンスが分離されたGit worktreeで動作
  • 簡単なタスクはHaiku、複雑な推論はOpusに自動ルーティング
  • 3-5倍の高速化と30-50%のトークン削減を謳っている

複数モニターでの並列開発環境 Photo by Boitumelo on Unsplash

僕がClaude Codeを一番使っている理由の1つがここにある。Codexも同僚の中で評判がいいけど、Claude Codeはエージェントをワークフローのように使えるのが強い。コーディングだけでなく、Chrome操作やコンピュータユースなど業務全般で活躍できる。

ツール選びはコーディング性能だけでなく、業務全体での活用範囲で判断する時代になっていると思う。

コスト問題にも触れておく

ただし、正直に書いておくとコストは無視できない。Agent Teamsのコストは単一セッションの3-7倍になる。最適化されていないマルチエージェントシステムは、必要量の10-50倍のトークンを処理してしまうこともある。

しかし、ルーティング最適化で60-80%のコスト削減が可能だというデータもある。簡単なタスクは軽量モデルに委譲するだけで大幅に改善する。最初から全力で導入する必要はなく、段階的に取り入れるのが現実的だ。

Agent Engineeringはまだ発展途上

マルチエージェントの可能性について語ってきたが、正直に課題も書いておく。

非決定論的な動作が最大の難題だ。同じ入力から異なる結果が出る。テストとデバッグが従来のソフトウェアと根本的に異なる。「昨日は動いたのに今日は動かない」が日常的に起こりうる。

コスト予測の困難さも問題だ。通常のタスクはそこそこの費用で済む。しかしエッジケースに遭遇すると、コストが数十倍に跳ね上がることもある。企業での予算管理を考えると頭が痛い。

ガバナンスの問題も未解決だ。アクセス権限、説明責任、実行制限のフレームワークはまだ確立されていない。

そしてもう1つ、僕が気になっているのはエンジニアの仕事がどう変わるのかだ。AIエージェントの進化で、仕事がなくなるのではという恐怖感がある。

ただ、変化に怯えるだけでは何も始まらない。変化を活かして自分の領域を広げる方が建設的だと思う。むしろ他部署の仕事を取りに行くくらいの姿勢の方がいい。仕事の定義が変わっている以上、領域を広げた方が価値は上がるはずだ。

Agent Engineeringはまだ発展途上だ。でも、だからこそ今のうちに触っておく価値がある。

まとめ

この記事のポイントを整理する。

  • Vibe Codingの品質リスクは数字で出ている。AI生成コードはバグ1.7倍、脆弱性2.74倍。「動いたからOK」は危険
  • Karpathyが「vibe codingは時代遅れ」と宣言し、Agentic Engineeringを提唱。開発者の役割はコードを書く人からエージェントを設計する人へ
  • test-firstパターンが最も基本。「First run the tests」の4語から始められる。CLAUDE.mdとHooksでガードレールを作る
  • マルチエージェントで書く・検証を分離。Agent TeamsやSubagentsで人間のチーム開発を再現する
  • コストと課題は正直にある。3-7倍のコスト増、非決定論的動作、ガバナンス未確立。段階的に導入が現実的

始め方はシンプルだ。

  1. CLAUDE.mdに「テスト必須」のルールを追加する
  2. Hooksでコミット前テストを強制する
  3. 慣れたらSubagentsで「書く」と「検証する」を分離してみる

Vibe Codingを否定する必要はない。ただ、そこに「工学」の視点を加えるだけで、速さと品質を両立できるようになる。

まずはCLAUDE.mdに一行追加するところから始めてみてほしい。

参考リンク