予測不能な天才を包み込む方法
(melodykoh.substack.com)- 同じ依頼でも結果が変わるAI製品で反復的なエラーを減らすには、指示を増やすよりも、モデルが逆らえない決定論的コードで制御すべきである
- 制御構造はモデル、ハーネス、ドキュメント、フックの4層に分かれ、特定条件で独立して動作する**フック(hook)**だけがルールを強制できる
- 正確性をコードで判定できる作業は保証できるが、微妙な分析ミスのように判断が必要な作業は再びモデルに依存するため、モデルが進歩しても検証の空白は消えない
- AI製品には、モデルの判断に任せる部分とコードで保証する部分を分けるハーネスエンジニアリングが必要であり、制御が不足すれば誤答を出し、行き過ぎれば高価な通常ソフトウェアになる
- 誰もが同じモデルを借りられるなら、製品ごとの基準・コード・データ・統合環境を蓄積した**包み込む層(ラッパー)**が防御可能な競争力となり、Cursorの成長がそれを示している
文書のルールをコードへ移す
- Claude Codeがセッションごとに読むファイルで特定の行動を禁じても、内容を理解して同意したうえで同じ行動を繰り返すことがある
- ルールを、条件を満たした瞬間にコマンドを遮断するコードへ移すと、モデルの判断に関係なく禁止された行動が止まる
- The Verification Taxが扱うAI出力レビューのコストは、事後レビューを増やす代わりに上流段階のエンジニアリングで減らせる
- 1人と個人ツールだけで作った最小限の制御構造でも、大規模なAI製品が解かなければならない問題と同じ形を持つ
- 失敗の種類をフックの種類に対応づけ、層ごとの測定可能な範囲を整理した実務ガイドは、別のX投稿で確認できる
制御を構成する4つの層
- 制御力は下から上へ行くほど強くなる4つの層で構成される
- モデル: Claude Opus 4.8やGPT-5.5のように優れていても、同じ依頼に異なる答えを返すことがあり、この性質を完全になくせる指示はない
- ハーネス: Claude Code、Codex、OpenClawのようにモデルを実行し、モデルが何を見るかを決めるが、大きな方向性しか誘導できない
- ドキュメント: CLAUDE.mdやAGENTS.mdに好み、プロジェクト文脈、ルール、蓄積された修正事項を記すが、モデルは他の情報と合わせて判断するため従わないことがある
- フック: 特定の状況を監視しつつ独立して動くコードで、モデルが同意するかどうかに関係なく禁止コマンドを遮断する
- 4層のうち交渉しないのは最上位のフックだけである
- フックへ移したルールはモデルが回避できないため、反復エラーが消え、人がレビューする範囲も減る
コードで保証できない判断の領域
- 制御すべき表面は減らせても、完全に閉じることはできない
- 「このコマンドを実行するな」という条件はコードで検査できる
- 「分析が微妙に間違った方向へ流れないようにせよ」という条件は判断が必要であり、それを判定する別のモデルにもまた予測不能性がある
- 出力を実際に証明できるシステムは、人があらかじめ書いた基準と結果をコードで比較し、正解を正確に定義できる領域でのみ動作する
- モデルがアップグレードされても判断の問題は消えないため、モデルを包む制御層は引き続き必要である
-
形式仕様に基づく保証
確率的エンジンを決定論的ソフトウェアで包む
- 従来のソフトウェアテストは、望ましい出力と唯一の正解を定めたうえで、予測可能なコードを検査する形で発展してきた
- AIネイティブ製品は、同じプロンプトでも異なる結果を出す確率的エンジンを中心に置くため、従来テストの前提が崩れる
- Hamel Husainの指摘のように、数十年かけて築かれたソフトウェアテストの規律は唯一の正解を前提とするが、AIではまさにその正解が消える
- 複数の開発者は、予測不能なエンジンは維持しつつ、毎回同じように動く決定論的コードで包む方向へ収束している
- Dex Horthyの12-factor agentsは、優れたエージェントを「ほとんどがソフトウェアで構成された」システムと定義する
- Anthropicのbuilding effective agentsは、作業を「事前定義されたコードパス」で実行し、「プログラム的な検査」を追加するよう勧めている
- Claude Codeでは、条件を検査する方法を選べる
- コードが独立して合格または不合格を判定すれば保証が得られる
- モデルが条件充足の有無を判定すれば、判断結果しか得られない
-
Claude CodeのSkillsと/goal
個人設定が組織規模へ拡張されるとき
- 個人環境では、エージェントが1つのルールを無視しても数分を失うだけで、重要なケースは個人フックで防げる
- 同じエージェントを使う200人規模の会社では、構成員ごとに個人フックが存在せず、ルールが1つの共有ファイルに入ることがある
- 共有ルールが一度無視されると、そのファイルが実行されるすべての場所で同じ問題が起こりうり、組織の保護レベルは最も緩く書かれたルールに左右される
- 制御構造は個人設定と同じだが、規模が大きくなるほどエラーのコストが変わる
何を保証し、何を開けておくのか
- Everyのエージェントネイティブ・アーキテクチャガイドは、機能を書かれたコードではなく、「ループの中で動くエージェントが達成する、記述された結果」として定義する
- このアプローチは、モデルが即興的に動けるようにし、結果中心に製品を設計するが、制御が必要な地点では再びコードへ戻る
- 頻繁または重要な経路であるホットパスはコードへ移すよう勧めている
- 一部の作業には、エージェントの判断に任せてはならない検証が必要だと認めている
- モデル中心の製品設計と制御中心のエンジニアリングは相反するように見えるが、同じアーキテクチャを両端から扱っている
- 実際の設計では、製品のどの地点をどの程度までコードで固定するかを決めなければならない
- 固定が少なすぎると、保証が必要な作業でもモデルが即興で判断し、顧客に自信満々の誤答を伝えることがある
- 固定が多すぎると、すべての経路をコードで書いた通常ソフトウェアになり、モデルは既存コードが担っていた仕事を遅く高価に実行するだけになる
- OpenAIチームが呼ぶハーネスエンジニアリングとは、製品の各地点でモデルの判断が必要な部分と、コードによる保証が必要な部分を意図的な比率で分ける作業である
モデルより長く蓄積される包み込む層
- モデルは誰もが同じものを借りられ、モデル研究所のスケジュールに応じてすべての利用者へ同時に改善されるため、最も防御しにくい層である
- 競合がコードリポジトリ全体を読めたとしても、特定業務で何を保証し何を開けておくかを決めてきた蓄積された判断までは得られない
- こうした判断は、モデルが逆らえない層として実装され、製品ごとの制御構造とともに蓄積され続ける
- モデルを取り巻くコード、基準、データ、業務統合環境の総体が、長期的な競争優位を形作る
Cursorが蓄積した制御層
- AIコーディングツールCursorは、自社の汎用モデルを作らず、Claude、GPT、Gemini、Grokの間でリクエストをルーティングし、モデルを借りられる商品として扱っている
- AnthropicのClaude Codeが優れたモデルへ先にアクセスできても、Cursorを代替することはできない
- Cursorの売上は、昨年11月の約10億ドルから6月には約40億ドルへ増加した
- SpaceXは4月に確保したオプションを先週行使し、Cursorを600億ドルで買収することで合意した。これはベンチャー投資先スタートアップの買収として過去最大規模である
- Cursorが蓄積したのは、より優れた汎用モデルではなく、製品を包む層である
- リポジトリ全体を同期し、検索可能な状態に保つコードベースインデックス
- 1日あたり数億件の編集から、開発者がどの提案を受け入れ、どれを拒否するかを学習した独自の自動補完モデル
- Fortune 500企業の大半に入り込んだエンタープライズ統合環境
- モデル企業がより良いモデルを持っていても、エディタ、インデックス、開発者の利用習慣まで所有しているわけではない
AIネイティブ製品の持続性を分ける問い
- Cursorのように制御層を構築した例はまれであり、AIを業務に使う多くの組織は、こうした包み込む層を作っていないか、その存在を認識していない
- 企業規模では、この層をどう構築するかが、実運用に耐えるAIネイティブ製品と、誰もが借りられるモデルの上に載った印象的なデモとを分ける
- 基盤モデルが無料になっても何が残るのか、という問いが、製品の持続可能な資産を分ける鍵になる
まだコメントはありません。