この記事について「モデルは正しい。あとはデータを差し替えて本番につなぐだけ。」デモが成功した日、私たちはたいていそう考えています。そして数か月後、モデルは正しいまま、案件だけが死にます。殺すのは数学ではありません。月曜の朝に返ってくる「解なし」、そして「なぜ私のシフトはこうなんですか?」という問い合わせ。全部、教科書の外側で起きます。この記事は連載「デモで動いた最適化が本番で止まる」(全12回)の第1回です。80行のシフト最適化PoCを実際に作って動かし、それを実測で4回壊します。PoCと本番の間に横たわる4つの谷の地図と、明日のPoCに入れられる4つの保険を示します...

AIエージェントはコードを速く書きます。もっともらしい間違いも、同じ速度で書きます。2026年4月から6月にかけて、Claude CodeとCodexを使い、3つの個人開発を進めました。AIには調査、実装、テスト追加、レビューを任せています。しかし、生成されたコードを採用する責任までAIへ渡したわけではありません。この3ヶ月で作ったのは、AIを信用する仕組みではなく、AIの成果物を信用しなくても開発を前へ進められる仕組みでした。この記事では、実際に起きた3つの失敗と、それを受けて整備した5層の品質ゲートを紹介します。なお、以下の問題がAIだけを原因として起きたと証明できたわけではあ...

テスト

3行で言うとPostgreSQL 2台に同じデータを書き込むために Kafka を経由させたら、直接書き込みより 6〜25倍速くなりました。遅くなる前提で測っていたので、最初は測定バグを疑いました。Kafka fan-out 構成なら、DB が片方落ちても手を触れずに1万2千件を取り戻せた（ただし条件付き）「Kafka を挟むぶん遅くなる」という直感は、条件を揃えて測ったら外れた速さの代償は CPU ではなく、Kafka ブローカーが常時食う 3.5〜4.7GB のメモリだった普段はオンプレの RHEL / vSphere を見ているインフラエンジニアです。Kafka ...

個人で作っている iOS アプリを TestFlight に出しました。そこで手が止まりました。それまでの検証を、全部 __DEV__ でやっていたからです。60 秒で開封、匿名ログイン、サンプルの録画。つまり 本番だけを通る経路は、一度も実行していませんでした。実機を持っていないので、できる最大のことは、その経路をコードで洗うことだと考えました。結果、8 件見つかりました。全部、本番でしか起きないものでした。結論を先に書きます。開発環境が「都合よく」してくれているところを数え上げると、そこに欠陥が並んでいます。 バグを探すより、都合のよさを探すほうが速い。 60 秒で...

お久しぶりです。Hirotoshi Uchidaです。これはテスト投稿です。

!実際のプロダクト名・チーム名・PRの詳細は伏せていますが、体験自体は実務で起きたことをベースにしています。 はじめにこんにちは、修行中エンジニアのKomugiです。半年ほど前、受託案件で手動テストを担当する機会がありました。それをきっかけに、手動テストや自動テストに関心を持つようになり、最近、業務で実際にテストコードを書かせてもらえる機会を得ました。今回は、当時の自分の感覚のままPRを出したら、実務のレビュー密度に何度も突き返された話です。突き返されるたびに、「これは当時の自分だったら絶対に気づかず、そのまま見逃していただろう」という穴が見つかりました。何が見逃されていた...

この教材についてJupyterの上で最適化モデルが動いて、良さそうな解が出た。ここまでは楽しい仕事です。問題はその先です。壊れたデータが毎朝流れ込み、ある日突然「解なし」が返り、現場からは「なぜ私のシフトはこうなの?」と問い合わせが来る。最適化の案件が死ぬのは、たいてい数学ではなく工学の側です。この連載では、PoCで動いた最適化モデルを本番システムとして動かし続けるための技術を扱います。テスト、データ検証、シミュレーションによる評価、API化、可観測性、説明責任、効果検証、そして保守。凡例: ✅ 公開済み / 📝 執筆予定 第1部 モデルを工学する編 1-1....

ドキュメントを書いていたら、テストの抜けが見つかったagent-cost という小さな OSS CLI を公開しています。Claude Code / Codex CLI のローカル利用ログを読み込み、トークンコストを見積もるツールです。このツールのドキュメントを整えながら、そこに書く主張をコードやテストと一つずつひも付けていました。その作業中に、回帰テストがないケースを2つ見つけました。どちらのコードも、すでに意図したとおりに動いていました。見つけたのは実装バグではなく、その挙動を将来の変更から守るテストの抜けです。2件とも実装には手を入れず、回帰テストだけを追加しました。き...

冒頭の失敗告白私は Claude Code に npm test を一発で叩かせていました。100 回のうち完走したのは 28 回。3 コマンドに分けて順に叩かせたら、次の 100 回のうち 87 回完走したのです。同じリポジトリ、同じテスト、同じモデル。変えたのは「渡し方」だけでした。この記事はその測定と、明日から真似できる 3 ステップの導入手順の話です。 逆説命題AI に全部やらせるより、3 つに分けて渡す方が完走率も速度も上がる。直感に反するかもしれません。人間なら「まとめて全部やっといて」の方が指示は楽です。ところが LLM ハーネスでは、まとめて渡した瞬間に...

はじめに社内でTDD（テスト駆動開発）の勉強会を開催することになり、事前説明用の資料を作成していました。TDDの基本サイクルは次の3ステップです。Red（失敗するテストを書く）Green（最小限の実装でテストを通す）Refactor（コードを整理する）私自身、これまでTDDを実践する中で、特に疑問を持つことなくRedから始めていました。しかし、資料に「なぜ最初に失敗するテストを書くのか？」という説明を書こうとしたとき、ふと手が止まりました。わざわざ失敗させる理由を、自分の中で十分に言語化できていなかったのです。そこで、勉強会の準備や実際の演習を通して気付いたことを...

🎯 はじめにAIエージェントにテストを書かせている。カバレッジも上がるし、速い。ただ、あるときから引っかかっている。テストは検証器だ。 AIが書いたコードが正しいかを判定するための仕組みを、同じAIに書かせているとしたら、それは自己採点ではないのか。この記事では、AIエージェントの実地調査を1本と、開発者の生産性を測ったRCTを1本、計2本の論文を読んだうえで、テストの委譲にどこで線を引くべきかを考える。結論を先に書くと、こうなる。テストの委譲は「何を確かめるか」が決まっているときだけ成立する。だから「この関数のテストを書いて」は委譲していい。「このモジュールをテストして」...

大規模リファクタリングのテスト戦略では、既存のテストを増やす前に、変更する境界を決めます。入力の解釈、ユースケースの判断、依存方向、外部システムとの接続では、壊れ方が異なるためです。それぞれの失敗を検出できる場所へテストを置きます。ここでは、クリーンアーキテクチャへ移行したvscode-ajsbutlerを例にします。題材は VS Code 拡張ですが、扱うのは特定のフレームワークに依存しないテストの分け方です。コードを層と業務機能のどちらで分けるかは、Feature-firstとLayer-firstの使い分けで整理しています。ここでは、分けた境界をリファクタリング中にどう守るかへ...

コーディングエージェントは、ほとんどのタスクを同じ言葉で締めくくります。「完了しました。テストはすべて通っています。」本当のこともあります。ただ、6月の論文(arXiv 2606.09863)が測ったところ、自己採点した失敗ランのうち75.8%が、それでも成功を主張していました。同じ論文はLLMの審査員にこの嘘を見抜かせる実験もしていて、5モデル×5プロンプト戦略で最高AUROC 0.65、最低0.54。ほぼコイントスです。審査員は実際のマシンの状態ではなく、自信に満ちた締めの文体を読んでしまうからです。テストランナーは、失敗したスイートを1.0で検出します。だから、Stopフックを...

はじめにNode.js v26.6.0 のリリースノートを眺めていたら、Notable Changes が4件しかないのに、そのうち2件が test_runner でした。ひとつが context.log() と test:log イベントの追加（PR #64389）、もうひとつが TestStream イベントへの entryFile 追加（PR #64309）。しかも作者が同じ人です。t.log() は、テストの中から「このログはこのテストのものだ」という情報付きでメッセージを流せる API です。すでに console.log も t.diagnostic() もあるのに...

AIが書いた UPDATE を、人間が承認してから実行するライブラリを作っている。売りは一点だけで、承認画面に出る値は推測ではなく実測だという点だ。トランザクションの中で本当に実行して、実行前後の値をデータベースから読み直して、必ずロールバックする。人間はAIの説明ではなく、その実測値を見て承認する。公開翌日、そのライブラリが承認画面に出していない列を本番に書き込んでいたことが分かった。 実際の出力公開済みの 0.4.0 を npm install して動かしたもの。データは name='田中', postcode='00100'。 UPDATE customers SET...

はじめにRAG、チャットボット、エージェント。LLMを組み込んだアプリを作り始めると、必ずぶつかる壁があります。それは「この出力、本当に良いの?」という問いです。コードのテストなら、assert result == 4 のように正解が明確です。ところがLLMの出力は「だいたい合っている」「まあ悪くない」といった曖昧なものになりがちで、良し悪しの判定がとても難しくなります。そこで多くの人は目視でチェックします。しかし目視には大きな問題があります。再現性がない: 同じ出力でも、日によって「OK」と「NG」の判断がブレるスケールしない: 100件、1000件のケースを毎回人...

はじめに最近、AI Coding Agentを使った開発方法が大きく変わっています。以前は、人間↓コードを書く↓Testを書く↓Reviewするという流れでした。しかし現在は、人間↓Issue作成AI Agent↓実装↓Test追加人間↓Reviewという開発も現実的になっています。Claude CodeなどのAgentは、単純なコード補完ではなく、Repositoryを理解しながら複数ファイルを変更する開発支援ツールとして利用されています。ただし、ここで新しい問題があります。 AIがコードを書けるなら、誰がそのコードを確認...

再現できない状態は、レビューされないコーディングエージェントに一覧画面を作ってもらった後、レビューで最初に詰まるのはここでした。0件やエラーの画面を、どうやって出すのか。本番のAPIが正常に動いている環境では、エラー画面は出せません。データが入っているアカウントでは、初回0件も再現できません。結果として、正常データが入った画面だけを見て「問題なさそう」と判断することになります。よくあるのは、見た目が整った一覧を先に見て「ほぼ完成」と感じたあと、0件表示に切り替えた時点で修正箇所が一気に増える流れです。表のヘッダーだけが残り、その下に何もない画面が出てくる、という形になりま...

はじめに本記事では、AIを使った開発においてバグ発見の記録のために検討したログ設計について説明します。私は、ExcelなしでVBAを実行し、テストできるVBA言語の評価エンジン VBA Runner を開発し、公開しました。詳しい背景は、ExcelなしでVBAを実行できる環境を構築しAIでのVBA開発を促進する にも書いています。現在も、VBA言語仕様の完全互換を目指して、AIによる評価と修正を繰り返しながら日々トークンを消費しています。現在は主要な言語機能の実装が一通り完了し、残った仕様差やバグを調べています。そこで、AIにバグを発見させ、最小再現を作り、修正し、回帰テ...