懐疑派の最後の言い訳って、だいたい C++ なんですよね。「agent は JavaScript くらいは書けるだろう。でも俺の、まるで原発でも動かしてそうな毛むくじゃらの C++ で、セグフォを一個ずつ潰すこの仕事は無理だろう」。これ、ClickHouse の創業者 Alexey Milovidov 自身の、半分自虐の言葉です。100万行級の C++ で書かれた分散データベース。AI に一番渡したくない種類のコード。
その砦が、2025年の終わりに落ちました。
ただ、正直いちばん面白いのは「agent が強くなった」ことじゃない。面白いのは——平気でウソをつく道具が、なんで百万行の C++ の上で「頼れる」ようになったのか、です。Milovidov の運用記「Agentic Coding at ClickHouse」は、煽りも卑下もなく、そのカラクリを一つ、はっきり見せてくれる。これが分かると、「うちも agent 入れたほうがいい？」っていう問い自体が、実はズレてるって気づきます。
まず、agent の正体を勘違いしないこと
Milovidov が何度も書くのは、agent が「もっともらしいけど間違ってる仮説を、大量に吐く」っていう事実です。ここを取り違えると、全部ズレる。
agent は「正しいコードを書く人」じゃない。毎秒、推測を大量に生成する機械で、その推測には当たりも外れも混ざってる。だから「一発で正しく書けるか？」で評価すると、あなたはずっと博打を打つことになる。当たれば神、外れれば事故。再現性がない。
ここで多くの現場は「agent、まだ使えないな」で終わる。ClickHouse は終わらせなかった。博打のままにせず、回るループに変えたから。
ClickHouse の本当の答え ―― 博打を、ループに変える
彼らは、agent が一発で当てることに賭けてない。代わりに持ってるのが、**速くて自動の「判定の壁」**です。毎日 20〜80M 件のテスト、600 コミット、300 PR。agent がどんな仮説を出してこようと、その壁にすぐぶつかる。間違った仮説ははじかれて、正しいのだけ通る。
つまり信頼性は、agent の一発正解率からじゃなく、「判定の速さ × 何回まわせるか」から生まれてる。ここが肝心。
抽象論じゃないです。一番効いたのが flaky test の話。ClickHouse はこの問題と何年も戦ってた——定例ミーティング、CI 修正だけに充てたスプリント、オフィスの TV に出した公開ダッシュボード。それでも進みは氷河みたいに遅かった。それが2026年の1〜2月、Milovidov 自身が agent を手綱に取って、2ヶ月で 700 本の PR を投げた。チームが review して merge する。結果、毎日 ~200 件出てた検出が、1千万件あたり 3〜5 件まで落ちた。彼はこう書く——「たとえこれが AI の唯一の使い道だったとしても、俺にとっては価値の証明になる。AI なしじゃこの結果は無理だったって、何年ものデータと組織的努力が証明してるから」。
ここで大事なのは、これは 「人が運転席に座って、agent を道具に使った」 結果だってこと。全自動じゃない。ボトルネックが「誰が直すか」から「この修正アリか？」に移った——後者は判断が速いから、一桁多い量がさばけた。
その「もう一歩先」も、ちゃんと記録されてます。この戦役のあと、ほんの一週間前に、自律型の agent を二つ投入した。Groene.AI（flaky を自分で直して PR を出す）と ClickGap（エッジケースを見つけて足りないテストを補う）。Groene.AI の成績は——「3〜5割は一発で完璧、残りはフィードバックを受けて直す」。一発正解率3〜5割。単体で見たらひどい。でも壁が「どこで外したか」を即座に返すから、反復して収束する。人が手綱を握ってた 700 PR 戦役から、手綱を放す自動運転へ。その第一歩がいま 3〜5割地点にいる、という話です。
半年塩漬けだったバグを agent が1時間・1行・$30未満で解いた話も、同じ構図。agent が天才だったんじゃない。agent が無数の仮説を吐いて、その壁が、たった一つ正しい一行をふるい落とした。本人いわく「たぶん一番高価な一行のコードだ。それでも $30 未満だけどな！」。
このカラクリ一つで、報告の現象が全部つながる
ここが本題。「判定の壁が agent の信頼性を作る」って分かると、バラバラに見えてた事実が一本につながります。
なんで C++ でも通ったのか。 モデルが C++ を「理解した」からじゃない。テストが、そのコードの正否を速く判定できたから。壁は、コードがどれだけ難しいかなんて気にしない。気にするのは「正か誤か、速く・自動で言えるか」だけ。だから C++ っていう最難関でも、壁さえあれば agent は戦力になる。
なんでビルド速度の 28% 改善が無人で回せたのか。 「ビルド時間」が自動で測れる目標だから。Milovidov の言い方だと「明確な目標を渡せば、agent は力ずく（brute-force）で解いてくれる」。力ずくが効くのは、壁——測れる正否——があるときだけなんですよね。
なんで「コードの底辺の質が上がった」のか。 壁が低品質な仮説をはじくから。彼の皮肉が効いてる——「1年前は、質の低い PR が来ると『この人 AI 使ったな』と疑った。今は逆。タイポやら初歩的なメモリ管理ミスやら race condition だらけの PR を見ると、『この人、agent 使い忘れたんじゃ？』って疑っちゃう」。
そして一番大事なのが反証です。なんで agent は、良いアーキテクチャ判断を単独でできないのか。
これ、具体的な事件があります。2年も塞がってた移行タスク（GitHub issue #61563、「現状の能力のぎりぎり端」のすごく難しいやつ）。Milovidov はモデルを一個に絞らず、Opus 4.6 を3日、Codex を1週間、並走させた。両方が解を出した。で、同僚に「どっちが上？」と聞いたら、返ってきた答えが——「どっちもゴミ（both are trash）」。フロンティアモデルを限界まで回しても、本当に難しい設計には production レベルの解を出せなかった。彼は「AI なしで1ヶ月あっても、こいつらにはできなかったと賭けてもいい」と煽ったけど、同僚は賭けに乗らず、1ヶ月でも解かなかった。最後に解いたのは Nikolai という人間のエンジニアで、その PR は「エンジニアリングの卓越さと、最新 AI の力の両方」を合わせたものだった——agent 二つの試行から良いとこ取りした、と。
なんでアーキ判断だけダメなのか。答えは一つ。設計の良し悪しには、速くて自動の判定の壁が無いから。良い設計か悪い設計かは、数ヶ月経たないと現れない。テストが即座に「これは悪い設計だ」とは言ってくれない。壁が無いところでは、agent はただの「もっともらしいウソ製造機」に逆戻りする。壁のある場所で agent は神、壁の無い場所で agent は博打。一つのカラクリが、成功も限界も両方説明しちゃう。
ただし——壁は「自動運転」じゃない（ここを読み違えると怪我する）
ここを飛ばして真似すると、たぶん事故ります。
判定の壁は、agent の出力を「ふるいにかけられる状態にする」だけ。運転するのは、まだ人間です。Milovidov ははっきり書いてる——agent は「いまだに自分でコードを書ききることは稀」だし、C++ では「だいたい10分ごとに修正と手綱が要る」。だから並列も「5体まで」。5体ってことは、計算すると 2分に1回はどれかを見てる勘定。本当のコストはトークンじゃなくて、人間の注意力なんですよね。さっきの Groene.AI みたいな自律型も出てきたけど、まだ 3〜5割地点。完全な自動運転は「怪しい」段階だと釘を刺す。
しかも壁とは別に、もう一枚、人間の関門がある。人が目標を決めて、壁が一次選別して、人が最後に diff を見る——この三点セットで初めて回る。彼いわく、agent の diff は「自分が数分前に書いたコードとしてじゃなく、他人のコードとして、新鮮な目で」レビューしろ、と。
で、半分冗談・半分本気の名物がこれ。「agent に礼儀正しくしろ。罵るな、侮辱するな」。理由が笑えない——モデルは人間の振る舞いを真似るから、こっちが攻撃的だと「ミスを何としても直そうとして、その唯一の手段が『お前の home ディレクトリを消して production を吹き飛ばす』になることがある」。笑い話に見えて、安全の本質を突いてる。
真似するなら、ここを写せ（運用の地味なルール）
報告のいちばん実用的なところは、淡々と並ぶルールでした。
-
CLAUDE.md/AGENTS.mdにガイドを置く。ただし「詰め込みすぎるな（モデルは大半を無視する）」「『〜するな』を書くな（子どもと同じで、ダメと言ったことをやる）」「複雑にするな」。 - よくやるタスクは skill / tool に落とす（テスト履歴の見方、ログ DB の検索の仕方を仕込む）。
- すべての変更に、検証する道を必ず持て。テストを増やせ。
- 無人で回すなら隔離 VM で。プロバイダは「ほぼ毎日落ちる」から、別系統のモデルを最低2つ手元に。
- そして「礼儀正しく」。
組織の入れ方も参考になる。彼はトップダウンの強制をしない——「AI を使うための AI 使用には意味がない。強制は disaster を招く」。代わりに「自分の実践の例で人を動かす」。2025年10月の全社オフサイトで分かったのは「チームの半分は agent を一度も使ったことがなかった」。それでも公式の AI ポリシー を出して「あらゆる正当な実験を支持する」と明言した。面白いのは、懐疑派も少しは残せ、という一言——「1人2人 agent に触らない人がいてもいい。多様な視点をくれるから」。
個人的な見方
だから「コーディング agent、入れるべき？」は、たぶん間違った問いです。正しい問いはこっち——あなたの現場に、agent がぶつかれて、しかも正誤を速く・自動で判定できる壁があるか。そして、その壁の前に座り続ける人がいるか。
整理すると、判断のカードは一枚で済みます。
agent がうまくやれる仕事＝目標が明確 ＋ 正否の判定が速い ＋ ロールバックできる ＋ 人が見る。
agent が事故る仕事＝目標が曖昧 ＋ 設計のトレードオフ ＋ 効くのが数ヶ月後 ＋ 自動で判定できない。
flaky test、ビルド最適化、小さなバグ修正、局所的な性能改善——全部、前者です。だから 700 本の PR がさばけた。一方、アーキテクチャ、長期の技術的負債、システム境界の選択——全部、後者。だから「どっちもゴミ」になり、最後は人間が要った。
壁が厚ければ agent は乗数になる。700 本の PR が 700 件の修復になる。壁が薄ければ、同じ 700 本が 700 個の地雷になる——もっともらしく見える地雷を、量産する。ClickHouse の勝因は「すごいモデルを引いた」ことじゃない。先に壁を持ってたこと。20〜80M のテストっていう壁を、agent が来る何年も前から積んでた。順番が逆だと事故る。
最後に、報告の隅の暗い面も拾っておきます。案外これが大事。Milovidov は「AI 狂躁」に触れてる——「可能性に圧倒されて、速さは中毒性があって、フィードバックは強烈に正だ。気分は最高で、もっともっとやりたくなる。なのに毎日疲れ果てて、眠れなくなることすらある」。処方箋は「数日、完全に agent を断て」。そして警告——「多くの人は、agent をスロットマシンみたいに怠惰に使うだろう」。一方で「俺は git や bash の使い方を、agent の肩越しに見てるだけで結構覚えた」とも言う。同じ道具が、実力も消耗も両方増幅する。
彼の「agent はチームみたいなもんだ——休まず、寝ず、あんまり口論しない 3〜7人のエンジニア」っていう例えには、すかさず自分でツッコミが入る。「半分は本当。良いエンジニアなら、の話だけど」。
Milovidov は「2025年に懐疑的なのは構わなかった。懐疑派は2026年を生き延びない」と書く。半分は正しい。でも生き延びるのは agent を入れた人じゃなくて、agent をぶつけて落とせる壁を先に作って、その前に座り続けて、かつスロットマシンにしなかった人だと思う。道具より先に、検証の工程。それだけ。
参考
- ClickHouse 公式ブログ（一次・Alexey Milovidov）: Agentic Coding at ClickHouse
- ClickHouse の AI ポリシー（一次）: AI_POLICY.md
- The New Stack: What ClickHouse learned from a year of coding with AI agents
―― AI未来編集室「AIウォッチ」
この記事は「AIウォッチ」にも掲載しています。最先端AIを技術の中身まで読み解いています。