とにかくイテレーションを回したい
AIプロジェクトの品質を高めるには、作って、試して、フィードバックを得て、改善する。このサイクルを回すしかない。そしてこのサイクルが速ければ速いほど、プロジェクトは良くなる。
とにかくイテレーションを回したい。
私がここまでイテレーションに執着するようになった背景には、フィードバックなしに5年間開発を続けた経験がある。詳しくは前回の記事に書いたが、自社サービスの開発に5年を費やし、売上はゼロだった。善意のフィードバックはあったが、お金を払わない人の「良いね」は責任を伴わない。それを真に受けて方向転換を繰り返すうちに、何が正解かわからなくなった。
2025年、国立研究機関や大手製薬企業を含む、いくつものAI・AIエージェントプロジェクトのご相談をいただいた。お金を払うお客様からのフィードバックは、具体的で、正直で、ときに厳しい。その中で、フィードバックループを回せるかどうかがプロジェクトの成否を大きく左右すると実感するようになった。
本記事では、AIプロジェクトにおいてイテレーションを高速に回すために何が必要か、自分自身の失敗と業界の変化を交えて書きたい。
AIエージェント開発に必要なのはコーディングだけではない
AIエージェント開発のプロジェクトでは、大きく2つのフェーズで考えている。
立ち上げフェーズ では、要件を定義し、全体を設計し、関係者の合意を得る。何を作るのか、なぜ作るのか、誰のために作るのかを明確にする段階だ。
反復フェーズ では、機能を1つずつ実装し、テストし、評価する。その結果を踏まえて次の機能に取りかかる。この繰り返しがイテレーション だ。
反復フェーズではイテレーションを回せる回数が肝
2025年からCoding Agentが急速に普及した。Claude Code、Codex、Gemini CLI。AIがコードを書く時代が来て、「機能実装」のコストが劇的に下がった。かつて数日かかっていた実装が、数時間で終わる。場合によっては数十分だ。
しかし、AIエージェントの開発プロジェクト（ひいては全てのソフトウェア開発）はコーディングだけで成り立っているわけではない。
Coding Agentによって機能実装だけが歪に圧縮された。テストや評価はどうか。従来通りのやり方を続けている限り、ここが相対的に巨大なボトルネックとして浮かび上がる。コーディングの速度に合わせて他のプロセスも圧縮できれば、イテレーションは本当に速く回る。しかし従来通りでは、Coding Agentの恩恵はプロジェクト全体にはそれほど波及しない。
以下、テスト・評価の各プロセスについて、自分自身の経験を交えて書く。
テスト：後から入れる地獄
2025年7月、社内のアサイン管理システムをClaude Codeで開発した。
それまでCursorを使っていたが、Claude Codeの自律性に驚いた。苦手なフロントエンドもサクサク作れる。気をよくしてガンガン機能を実装した。プロジェクト情報の登録、メンバーのアサイン状況の表示、エフォートの編集。Next.jsとReactで、作成ボタンや編集ボタン、保存ボタンなど、GUI操作に依存した機能を次々と追加していった。
“ それっぽい“プロジェクトやアサイン管理のシステムは一瞬でできた
機能を追加するたびに、ブラウザを開いて手作業で動作確認をしていた。ボタンを押して、フォームに入力して、保存されたか確認する。最初のうちはそれで回っていた。
しかし、Coding Agentを使うと簡単に機能を追加できるので、ついつい進めてしまう。機能が増え、相互に作用し始めると、人間の認知では全体を把握しきれなくなる。人間が自分でコードを書いていた頃は、時間をかけた分だけプロジェクトの全容が頭に入っていた。Coding Agentの速さに、人間の認知は追いつけない。
途中から「これはまずい」と思い、Playwrightで自動テストを導入しようとした。Claude Codeを使えばコードベースからテストを大量生成できる。しかし、通らない。ブラウザ上には明らかに「作成」ボタンがあるのに、テストは「ボタンが見つからない」と報告する。
原因は、UIコンポーネントを全て自作していたことだった。Coding Agentにとって馴染みのない独自のコンポーネント構造になっており、テストコード生成時に要素を正しく認識できなかった。後からエンジニアの知人に相談したところ、shadcn/uiのようなデザインシステムを使っていれば、少なくとも要素が見つからないという問題は起きなかったはずだと言われた。
結局、大量のテストを1つずつ検証・修正するフェーズに入り、開発スピードが大幅に鈍化した。本来、機能を作って価値を生む時間を、テストの修正に費やすことになった。
この反省から、以降のプロジェクトではテストファーストで進めるようにした。いわゆるTDD（テスト駆動開発）の考え方だ。
-
テストを書く
-
機能を実装する
-
テストが通ることを確認する
-
次のテストを書く
-
機能を追加する
-
これまでの全てのテストが通ることを確認する
TDD自体は昔からある手法だが、Coding Agentとの組み合わせでその重要性が増した。前述の通り、Coding Agentの速さに人間の認知は追いつけない。テストという自動化されたセーフティネットなしにCoding Agentで快調に進めるのは、ブレーキのない車でアクセルを踏み込むようなものだ。
評価：最も見落とされ、最も高くつくボトルネック
テストと評価は似ているようで、全く別物だ。
テストは「システムとして壊れていないか」のチェック。ボタンを押したら正しく動くか、データが正しく保存されるか。入力に対して期待する出力が返るか。従来のソフトウェア開発と同じ、決定論的なpass/failの世界だ。
評価は「作ったAIが実際にどれだけ役に立つか」の測定だ。GoogleのAgent Development Kitのドキュメント（ Why Evaluate Agents ）はこう述べている。「従来のテストアプローチでは、LLMエージェントの変動性に対応しきれない」「決定論的なpass/failのアサーションは、エージェントの性能評価には不適切なことが多い」。同じ入力でも異なる出力を返し得るLLMの性質上、テストとは別の枠組みが必要になる。Anthropicもテスト（test）と評価（eval）を 明確に区別したドキュメント を公開している。
AIプロジェクトにおいて、この評価こそが最もイテレーションを阻むボトルネックになり得る。
開発は半日、評価は1週間
私が従事するAI for Science領域では、AIエージェントの出力の評価に専門知識が求められることが多い。例えば、ある学術テーマについてAIエージェントが生成した回答が妥当かどうかは、その分野の専門家でないと判断できない。
機能実装自体はCoding Agentのおかげで半日で終わる。しかし、その実装によってAIエージェントの出力がどう変わったかを評価するには、お客様に回答を見てもらう必要がある。お客様にも本業がある。評価のための時間を確保してもらい、複数のケースを確認してもらうだけで1週間以上かかることも珍しくない。
結果、細かな機能実装のたびに評価をお願いすることは現実的でなく、プロジェクトの中間報告や最終報告のタイミングでまとめて評価をお願いする形になりがちだ。しかし、それでは評価の結果を受けて改善するタイミングが限られてしまう。Coding Agentでコードの変更がどれだけ速くなっても、評価がボトルネックになり、イテレーションが回らない。
業界の模索：LLMの出力を誰が評価するのか
この問題に悩んでいるのは私だけではない。
2024年6月、「 LLM赤裸々ナイト 〜#1 評価編〜 」という勉強会に参加した。LLMの確率的な挙動をどう制御するかが議論のテーマだった。2025年7月にも自社で AIエージェントについての勉強会 を開き、同様に「いかに評価するか」が質疑で最も盛り上がった。
当時の業界の空気感としては、こうだった。定量的に評価できる項目、例えば「この質問に正しく答えられるか」のようなものは評価基盤を整え、変更のたびに自動で回す。一方で、マルチターンの対話全体の品質や、ユーザーの意図を汲んだ応答になっているかといった定性的な部分は、結局人が見るしかない。多くの開発者がそう受け入れていたように思う。
当時からLLM-as-a-Judge（LLMの出力をLLMに評価させる手法）の概念はあった。しかし、「LLMが出した答えをLLMに評価させて、そのLLMの評価の正確性はどう担保するのか」。慎重な人ほど懐疑的だったし、私自身もその妥当性を自信を持って語れなかった。
転換点：LLM-as-a-Judgeの実用化
しかし、AI Agent元年とも言える2025年の一年を通じて、業界の知見は急速に蓄積された。
象徴的なのがGoogleのAgent Development Kit（ADK）のドキュメント「 Why Evaluate Agents 」の変遷だ。2025年4月のADK初版では、エージェントの最終応答の評価は ROUGE（テキストの表層的な類似度を測る従来手法）のみだった。
ところが2025年10月14日、このドキュメントに大きな更新が入った。LLMベースのメトリクスが一挙に5つ追加されたのだ。最終応答のセマンティック評価、カスタム基準によるルーブリック評価、ハルシネーション検出、安全性評価。いずれもLLMを審判として使う。これは「従来のテキスト類似度では不十分で、LLMの判断力を評価に組み込むべきだ」というパラダイムシフトを反映している。
私自身も、2026年に入ってからAIエージェントの最終応答の評価にLLM-as-a-Judgeを採用し始めた。
理由は二つある。一つは、LLMの性能が私自身の判断力を超えたと確信できるようになった こと。2025年前半は「なかなか賢い、使い所がありそう」という認識だったが、後半にかけて「自分より賢い」ことを受け入れざるを得なくなった。
もう一つは、開発イテレーションを高速化するメリットが、LLM-as-a-Judgeの不完全さを上回る と判断したことだ。もちろん、専門的な判断力では専門家に劣る領域はまだある。プロジェクトの中間報告や最終報告でお客様に直接評価してもらうことは引き続き重要だ。
しかし、その間の日々の開発プロセスにおいて、テストと評価が全て自動で、定量的にスコアを出してくれることの価値は非常に大きい。
機能を追加するたびにテスト・評価を自動で回し、定量的な指標で比較する。今の変更を受け入れていいのか、デグレが起きていないか、即座に判断できる。自動でなければ人のチェックがボトルネックになるし、定性的な評価だけでは解釈にもまた人がボトルネックになる。
高速なイテレーションには、自動であること、定量的であること、この両立が必須だ。
テストの章でTDDに触れたが、AIプロジェクトではこれを一歩進めて、EDD（Evaluation-Driven Development、評価駆動開発）という考え方が広がりつつある。TDDが「テストを先に書く」なら、EDDは「評価基準を先に定義する」。Andrew Ng先生は「AIエージェント開発チームの進捗を最も左右するのは、評価とエラー分析に対する規律あるプロセスだ」と 書いている 。テストファーストで壊れていないことを担保し、評価ファーストで価値を担保する。この両輪が揃って初めて、イテレーションは意味のある速度で回る。
コーディングだけの加速では足りない
ここまでの話を整理しよう。
プロジェクトの精度を高めるには、イテレーションを回すしかない。そしてイテレーションを高速に回すには、サイクルを構成する全てのプロセスを圧縮する必要がある 。
Coding Agentの登場で機能実装は劇的に速くなった。しかし、テストなしに進めれば品質が崩壊し、評価が手動のままではフィードバックがボトルネックになる。
私自身、テストを後回しにして開発が止まった経験がある。評価のボトルネックに何度もぶつかり、LLM Judgeの導入に至った。これらは全て、コーディング以外のプロセスが追いつかなかった結果だ。
コーディングだけの加速で事足りるなら、Coding Agentを使えばいい。しかし、プロジェクト全体のイテレーションを回すことが成功の鍵だと考えるなら、テスト・評価の各プロセスをどう設計し、高速化するかが問われる。そして私たちは、様々なプロジェクトを通じてその知見を蓄積し続けている。
そもそも、方向が間違っていたら
ここまでイテレーションの高速化について書いてきた。しかし、これには大前提がある。イテレーションを回す方向が正しいこと だ。
これは社内で繰り返し伝えていることだが、お客様には課題がある。時に、解決策を指定されることがある。しかし、それを鵜呑みにしてはいけない。解決策とは課題を解決するための手段でしかなく、選択肢は無数にある。背景や課題の原因、予算や期間といった制約条件を加味して比較検討した上で選定する必要がある。誤った解決策の選定は、不要にプロジェクトを難しくし、不確実性とリスクを高める。
今やCoding Agentに頼めば実装はしてくれる。従来の開発速度に比べれば格段に速いが、それでもゼロではない。仕様書やソースコードを読み込み推論するにはそれなりの時間がかかっている。一度のやり取りで数分かかることもザラだ。テストと評価を整備し、機能を実装する。数日間はかかる。立ち上げフェーズが適切でないと、特に前提が間違っていたり情報が不足していたりすると、この数日が白紙になり、再度設計からやり直しになる。
立ち上げフェーズの重要性については、改めて別の記事でまとめたい。
仕組みをスケールさせる
ここまで書いてきたことは、いくつものプロジェクトを通じて辿り着いた現時点での答えだ。テストファースト、評価の自動化、立ち上げフェーズの見極め。
仕組みの輪郭は見えてきた。より多くのお客様にAI for Scienceの実現を届けるには、営業もデリバリーも、この仕組みを組織の力に変えてスケールさせるフェーズに来ている。
現在、Science Aidでは2つのポジションで仲間を探しています。
本記事で「方向が間違っていたら」と書いた通り、お客様の課題を正しく理解し、適切な解決策を選ぶことが全ての出発点だ。この立ち上げフェーズを、営業・提案の観点からリードし、再現性のある型を作る営業責任者 。
テスト・評価の設計からイテレーションの高速化まで、プロジェクトの品質と速度を複数案件横断で担保し、仕組みに変えていくデリバリー統括責任者 。
どちらも、既存の型にはまるのではなく、型そのものを一緒に作っていく仕事です。
この記事の内容に共感いただけた方は、まずはカジュアルにお話ししましょう。募集の詳細は下記からご覧いただけます。