AI should only run as fast as we can catch up

2025年12月7日 – AIは私たちが追いつける速度でしか動かないべきだ

ダニエルとエリックの物語

最近、AIを楽しんでいる友人二名に会いました。

エリック

先月、ミッドサイズのスタートアップで恐れ知らずのPMとして活躍しているエリックに出会いました。彼はついにGeminiを使い始めたばかりです。Geminiに慣れた後、プロンプトからウェブアプリケーションを作る速度に本当に驚きました。デザイナーやエンジニアへアイディアを伝える初期プロトタイプとしてはうまく機能します。

しかしエリックはそのステップを飛ばして直接本番環境へ出荷したいと考えていました。しかしGeminiが実際に作るのは「動いているように見える」単一ページHTMLファイルであり、信頼できる企業向けプロダクトには不十分だと理解できませんでした。さらに技術的な詳細を追いつき、エンジニアリングチームを上回る方法が見つからず、困っていました。

ダニエル

先週、AIコーディングに夢中になったシニアスタッフエンジニアのダニエルとカフェで話しました。彼は当初懐疑的でしたが、今では数か月間コードを書いていません。プロンプトを使って既存フレームワーク（Kafka, Postgres, AuthN/Z, k8s infra）に新しいコンポーネントを作成し、既存のパラダイムに沿うように指示します。

AIの成果をスニペットチェックしたり、ローカルでデプロイして動作確認したり、コードレビューを経て本番リリース用機能としてマージしています。すべて自分で一行も書かずに実現。ダニエルにとっては高速でスケーラブルな構築・配布がこれまでより簡単です。

2つの物語を結びつける

エリックとダニエルの話を聞いて感じた共通テーマは、「信頼できるエンジニアリング」― AIを確実に動かす方法でした。

AIはほんの数行のプロンプトでインターネット上のあらゆる作業を任せられます。私よりも早く思考・学習しますが、ただ機能するだけではなく「信頼できて安心できる」状態にするためには、我々が追いつかなければなりません。

ダニエルの場合：検証は速い―スニペットチェックと簡易テストで信頼性を確保できます。
エリックの場合：ゼロから学ぶのは遅い―自分だけではエンジニアリングチームに追いつけません。

AIが爆発した領域：高速検証・低速学習＆創造

任意のタスクを 学習／創造 と検証に分解できます。

検証 ≪ 学習/創造 → AIの成果を効率的にチェックできる→高い信頼性
検証 ≈ 学習/創造 → 収益は限定的；AIはボイラープレート自動化ツールになる
検証 ≫ 学習/創造 → AIの信頼が低く、実際に制御できない「バイブ・コーディング」状態

例 – 画像生成：
リアルな画像を描くことは難しい。スライドレイアウトを微調整するには人間で数時間かかりますが、AIなら出力を見るだけで即座に検証できます。視覚的直感に基づく瞬時の確認です。特別な知識は不要。このコスト非対称性が画像生成の爆発を説明します。

検証負債：技術負債より恐ろしい

検証が煩雑になり、ドメイン知識や技術的専門性が要求されると「検証負債」が生まれます。作業は増える一方で、チェックの遅延も増大します。組織がバイブ・コーディングを続けて追いつかない場合、タスクは未確認の負債となり予期せぬ副作用を招く恐れがあります。

この問題は数多くのブログで議論されており、今日のリーダーにとって重要な課題です。

検証エンジニアリング ― 次世代コンテキストエンジニアリング

AIを信頼できる速度で動かすには、その成果をチェックする速度が鍵です。
検証エンジニアリング（VE）は、プロンプト・コンテキストエンジニアリングの論理的後継です。抽象化とフレームワークを再構築することで、AI実行タスクを検証しやすくし、より堅牢な製品を可能にします。

始動アイデア例：

AIを「バイブ」ではなく「外科的」に導く技術的に精密なプロンプトを作成
AI出力を効果的に検証できるステークホルダーを育成
検証しやすいが創造が難しいタスクを特定
簡潔に検証可能な範囲の理論的限界（計算複雑性）を押し広げる

今後の方向性

最も大きな利益は、より複雑なタスクを人間の認知で検証できる方法を見つけた者にあります。従来のプログラミング言語から、実装詳細に関係なく検証しやすい抽象的なグラフ／データフロー表現へ移行するべきです。

将来は Severance のように「揺れる数値」を画面で見るだけで、「直感が正しい」結果を得る世界になるかもしれません。これらの effortless、低レイテンシーな感覚を収集すれば、AIにより強力な仕事を確実に遂行させることができるでしょう。