※この記事は、2025 Speee Advent Calendar 18 日目の記事です。昨日の記事はこちら
はじめに
こんにちは、DX 事業本部でエンジニアをしている 22 新卒の高島です。社内ではたかてぃーと呼ばれています。
大学院では機械学習の研究をしていましたが、入社後は既存プロダクトの保守運用や新規事業のアプリケーション開発を経験しました。2024 年 11 月からは、不動産領域で AI/LLM を活用した R&D プロジェクトをリードしています。
この 1 年間、AI エージェントに関する研究開発に取り組んできましたが、決して順調ではありませんでした。特に最初の半年間は、成果が見えない苦しい時期が続きました。
本記事では、私が R&D プロジェクトで試行錯誤した経験と、そこから見えてきた「地に足をつける進め方」についてまとめます。
こんな方に向けて書いています：
- ゴールが曖昧なテーマで「何から手をつけよう」と悩んでいる
- 着実に前には進んでいるけど「うまくいっているか分からない」と感じている
- これから研究開発をリードすることになった
私自身が陥った状況と、どう乗り越えたかを共有することで、同じ状況にいる方の参考になれば嬉しいです。
※ 本記事で扱う R&D プロジェクトはまだ公にオープンになっていないため、具体的な内容はぼかして記載しています。
目次はこちら
成果が見えなかった半年間
R&D を始めるにあたり、大学院の修了から 3 年弱のブランクがありました。「基礎技術も進歩しているはず、知らないことが増えているんじゃないか」と焦り、闇雲にインプットしていたのを覚えています。
しかし、結局それは杞憂に終わりました。本当に直視すべき問題は「知識」ではなく「プロジェクトの進め方」にあったのです。
成果が見えない苦しい時期を振り返ると、次の 2 つの状態が重なっていました。
- マイルストーンがなく、プロジェクト状態を誰も評価できない
- 手段の検証に時間を費やし、何を解決すべきかに向き合えない
これらが重なることで、現在地が分からない状態に陥っていきました。
マイルストーンがなく、現在地が分からない
R&D を進めるにあたり、最初にやったのは目指すゴールの状態定義でした。達成に必要な開発要素や技術的に不確実な要素を洗い出し、1 週間で実験計画を立てました。
イメージとしては以下です：
検証テーマに対して、やるべきことや分からないことをタスク単位で列挙し、プロジェクト計画を立てていました。
しかし、いざ洗い出してみると、そもそも LLM 自体が日本の不動産領域でどれだけ活用できるのかが全く分かりませんでした。潰すべき不確実性ばかりで、やることが無数にある状態です。
さらに AI エージェントに関しては当時まだ情報が少なく、毎週・毎月新しい技術が出てくる状況でした。精度だけでなく運用面も検討しないと、事業に組み込める状態には程遠いことが分かりました。
この進め方の問題点は、「事業として何を検証して不確実性を潰していけば前進するか」というマイルストーンを定義できていないことでした。結果として、「まずは LLM がどの程度日本の不動産ドメインに活用できるのかを明らかにする」というボトムアップな進め方になってしまっていたのです。
こうなると、「何を優先して不確実性を潰していくべきか」が分からないだけでなく、プロジェクトの現在地を評価できません。健全性が測れず PDCA も回らない状態が続きました。
「手段の検証」に時間を費やしてしまう
当時は私を含めてチーム全員が、LLM に過度な期待をしていました。
実際、LLM はそれっぽい回答を返してくれます。数件の検証データを用意して試してみると、期待する回答に近いものを返却してくれるので「あと少し！」という体感でした。
そのため、最初から「なんでもできる AI エージェント」を作ろうとしていました。1 つの AI エージェントで自由度を高めて何でもできるようなプロンプトを開発したり、それに必要な構成要素を定義したりしていました。
こうした状態だったので、「AI エージェントに足りないのは知識とコンテキスト情報だ。それさえ解決すればなんとかなる」と考えました。そこで「宅建業法やプロダクトのドメイン情報」が足りていないと課題設定し、以下のように必要な知識を洗い出して RAG（Retrieval-Augmented Generation）などの技術検証を進めていました。
確かにコンテキスト情報は AI エージェント開発において重要です。しかし実際には、DB から取得したデータや特定 URL から取得するという手段で十分でした。
つまり、手段の検証に時間を費やし、「そもそも何を解決すべきか」という本質的な問いに向き合えていなかったのです。
成果が見え始めた転換点
AI エージェントの技術検証を進めることで、少しずつ外観が見え始めました。一部プロトタイプ検証が進められるような成果の蕾も見え始めていました。
ただ、AI エージェントを実際にプロダクトへ組み込むまでのイメージは、まだ描ききれていませんでした。もっと加速させたいという気持ちはありつつも、空回りしている状態でした。
このとき気づいたのは、足りなかったのは闇雲な実行量ではなく、事業成果から逆算した上での実行でした。何が問題だったのかを整理し、以下の進め方にシフトしました。
- 事業成果から逆算して見立てを作る
- 1 日 1 実験で実行強度を上げる
この動き方に変えた結果、事業成果を引き寄せるために必要な検証を優先して進められるようになり、PDCA も回るようになってきました。小さい成功体験を積み重ねることで、チーム全体が「前に進んでいる」という実感を持てるようになったのです。
事業成果から逆算して見立てを作る
以前の私の進め方は、「やるべきこと」を洗い出して上から順番に倒すゲームになっていました。着実に前に進んでいるはずなのに、成果達成に必要な状態や要素、クリアすべき技術的課題が何なのかを捉えられていませんでした。勝ち筋がないまま進んでいるので、現在地を測ることが難しい状態でした。
たとえば、以前は以下のような計画を立てていました。
一見整理されているように見えますが、これには大きな問題がありました。「完了条件」として精度目標は書かれているものの、どうやって精度を上げるかの具体的なプランがなく、進捗を追えないのです。
評価についても、以下のようにマルバツをつけてはいました。
入力データに対する LLM の出力を確認し、不正解なら「○○ の要素がない」といった失敗理由を記録していました。しかし、この評価が次の打ち手にどう繋がるのかが不明確でした。評価はしているものの、「じゃあ次に何をすれば精度が上がるのか」が見えない状態だったのです。
そこで変えたのは、「どういった目的で今の検証をしているのか」「それはいつまでにマルバツをつけるのか」を常に言語化し、評価し続けることでした。
具体的には、以下のようにマイルストーンを整理しました。
この図のように、事業成果（工数圧縮）から逆算して、R&D で潰すべき不確実性とその優先順位を明確にしています。ポイントは 3 つあります。
1. 事業成果に連動したマイルストーンを立てる
マイルストーンを立てる際に重要なのは、事業成果の指標と R&D で追っている精度がどう紐づいているのかを構造的に明らかにすることです。
以前の単純な「精度 60% → 80% → 90%」という置き方では、達成できなかったときに次に何をすればいいか分かりませんでした。しかし「事業としてどの成果を追っているか → R&D はどの比率でいつ成果を跳ね返すか → 期日から逆算していつまでに何がクリアか」という流れで整理することで、プロジェクトの現在地を自分もチームも評価できるようになりました。
また、R&D においては小さく軌道修正することで最短で事業成果達成を目指すことが最も重要です。最初に立てた目標やマイルストーンに固執するのは停滞原因になることが多いため、必ずマルバツをつけて前に進められるように工夫しています。
実験結果や状況の変化に応じて課題定義を変えながら PDCA を回し、週次・月次で「課題が更新されているか」を点検しています。同じ課題をずっと扱っているなら、それは停滞のサインだと捉えるようにしました。
こうすることで、健全性を測れるとともにチームとしても R&D が着実に進んでいるという自信を持てるようになり、精神的にも楽になりました。
2. インパクトの大きい課題から潰す
技術的に不確実性が残っている要素の中で、工数圧縮のインパクトが大きい順に優先度をつけて潰していきます。これは日々の実験レベルでも同様に適用し、地に足をつけて前に進んでいることを自信を持って説明可能な状態を作っています。
具体事例として、物体検出や画像認識モデルの検証時の考え方を紹介します。
精度をただ「上げる」のではなく、精度が下がっている要素を洗い出して外観をまず見ます。そして失敗パターンを分析することで、先にインパクトをざっくり試算します。上の表では、項目 A が精度インパクト 6.50% で実験数 2 回、項目 B が 4.63% で 6 回といった形で整理しています。 プロンプトの精度についても同様に、インパクトの大きさをベースに達成プランを立てています。
このように整理すると、「理論上、これをやれば目標に到達できる」という見立てが作れます。マルバツの評価が「次に何をすべきか」という打ち手に直結するのです。自信を持って前に進められるだけでなく、コスパの良い順番で精度を上げていけます。
たとえば、「精度 10% 上がるかも（2 週間）」より「精度 3% 上がる（2 日）× 5」の方が、不確実性が低い順に着実に精度を上げていけます。
3. 目標がぼやけるときは「今見える一歩先」まで進む
マイルストーンを立てようにも、「事業として何を検証して不確実性を潰していけば前進するか」を決めるのは難しいと感じることが多いです。それを言い訳に実行に走ってしまいたくなることもあります。
しかし、そういったときこそあえて完璧を目指さないことが、前に進む重要な視点だと気づきました。気持ちの悪い状態でも、次の一歩を決めて動かせばいい。先が見えないなら「何が分かっていればいいか」くらいでもいいので、まず仮説を引いてみることが重要です。
大事なのは、「探る、潜る」という姿勢です。事業として「いつまでにどういった不確実性」を潰せていれば前進するかを仮でもいいので定義し、小さく試して学ぶ。そうすると、向き合っている課題が変わっていく実感を持てます。
たとえば、LLM を利用して検証した結果、限界があると早期に判断できたことで、画像認識や物体検出といった別のソリューションの方がいいと気づけたことがあります。
LLM で 10 パターンほど試しましたが、安定した精度が出るのは 70% 程度でした。仮に精度が出せるモデルの場合でも、処理時間が 2 分ほどかかります。組み込み時のパフォーマンスを考えると到底受け入れがたいものでした。
そこで、画像認識モデルを開発することを決めて「技術的に本当に精度が出るのか？」を実験してみました。すると 1 週間ほどで高精度が出せたのです。
まずは取り組むテーマを絞って 1 週間程度の短期間のスコープでプロトタイプを作り出す。この動きは、足元動かさず停滞しているよりずっと課題が前に進むので良いなと感じています。
この画像認識モデルがうまくいったことを日次の報告で話した際に、事業部長を含めてみんなで喜んだことが今でも忘れられません。R&D はうまくいかないことがほとんどなので、こうした小さい成功体験をチーム全員で分かち合えているのが、実は部活みたいで好きです。
1 日 1 実験で実行強度を上げる
マイルストーンを立てられるようになって、やるべきことがシャープになりました。次の課題は、実行強度を上げられるかどうかでした。
そこで、「1 日 1 実験 1 評価」というシンプルな目標をコミットメントしました。可能な限り 2 実験以上を目標に、日々取り組むことを目指しました。
また、日次でビジネスメンバーとも結果を同期し、報告時は必ず「なぜこの実験をしているか」から話すことで現在地の共有を担保しました。常に「次何をするのか？」のアクションまで引いて同期しています。
シンプルな変化ですが、この動き方で実行強度が高くなりました。ビジネスメンバーとのコミュニケーションもうまく回り、進んでいる実感を自分もチームも得られるようになりました。
さらに、チーム全体で実行強度を高めるために、自分自身の実行強度を上げるだけでなく、全員と総力戦で突破できるように環境を整えて実験数を担保し続けました。
結果として 4 ヶ月で、138 回の実験 / 平均 2.5 実験/日のペースで仮説を消化し続けることができました。前半期とは比較にならないスピードで前進できるようになりました。
自分自身の実行強度を上げる
自分自身のインプット速度を上げて意思決定を早めたり、煩雑な作業を自動化したりすることで、実験速度を加速させることを意識していました。
たとえば、インプット速度を上げるために Deep Research を論文探索・技術調査・ソリューションの幅出しに活用しています。以下のように「丸投げする前に点検する基本原則」や「段階的なアプローチ」を整理し、こうした知見はガイドラインとして社内 Wiki にアウトプットしています。
また、データ作成やモデル学習に必要で繰り返し発生する煩雑な作業を、LLM で自動化するスクリプトを Claude Code で量産しています。これにより実験 1 つ 1 つの速度を高める工夫を行っています。
加えて、評価作業を効率化するツールを作れるだけでなく、スパイク実装を高速で行えます。クイックに試してみたいという状況において、まずは動くものを作ってリポジトリに配置しています。
こうした叩き台のコードがあるだけで、実際に組み込みを行う際に参考にできたり、コードベースで問題を整理することができます。
ビジネスメンバーとの総力戦で突破する
R&D のテーマにおいてボトルネックになる作業も、切り出してチームメンバーを巻き込むことで並列化し、全員で突破しています。
特に、エンジニア以外のメンバーも実験に参加しやすいよう、学習や評価環境の整備をしています。
たとえば、LLM のプロンプトチューニングにおいては Dify を活用しています。また、画像認識や物体検出のアノテーションにおいては、Azure AI Custom Vision を活用しています。
Dify では、ワークフローの構築や LLM のプロンプトチューニングを行ってもらえるようにしています。簡単なワークフローから複雑なワークフローまで開発し、スプレッドシートで評価することで性能を評価できるようにしています。
実際に以下のような複数の LLM が連鎖しているワークフローを Dify で構築して検証しています。
画像認識や物体検出のアノテーションにおいては、以下のような依頼整理を事前に行います。目的・背景、依頼内容、期日を明確にすることで、ビジネスメンバーがアノテーション可能な状態を作り、実験数を担保しています。
エンジニアメンバーに加えてビジネスメンバー数名に、日次で 30 分〜1 時間の工数をもらってアノテーションを行い、実験を重ねていきました。その結果、1 つのモデルで 20 件以上の学習イテレーションを回すなど、顕著に実行量が上がりました。
こうした総力戦の動きができるのは、日次で「なぜこの実験をしているか」を共有し、チーム全員が同じ方向を向いているからだと感じています。
まとめ
研究開発はすぐに成果が見えません。「本当にこの方向で合っているのか？」と不安になる瞬間は何度もありました。
ただ、仮説を立てて高速に検証し続けると、ふと振り返ったときに「あ、前に進んでいる」と気づく瞬間があります。
ここでいう「前に進む」は、作業を消化することではありません。成果を常に見据えながら、仮説が正しかったのか間違っていたのかを一つずつ明確にしていく。その積み重ねが、成果達成に近づいている実感と、事業として自信を持って前に進んでいると言える状態に繋がりました。
この 1 年で学んだのは、ゴールが曖昧でも、事業成果からの逆算を手放さないということ。そして、小さい成功体験を積みながら「どうすれば突破できるか」を探り、潜ること。それが最も早く、最も自信を持って前に進める道でした。
成果から逆算して、小さく試して、学ぶ。それを愚直に繰り返す。
ゴールが曖昧なまま進むのは怖いですし、うまくいっているか分からない時期は辛いです。それでも、成果を直視し続けていれば、少しずつ前に進めます。
この記事が、同じような状況にいる誰かの背中を押せたら嬉しいです。
最後に
R&D は不確実性との戦いで、うまくいかないことの方が圧倒的に多いです。それでも続けられるのは、事業成果に直結する手触り感があるからだと思っています。「この精度が出れば、ユーザーの体験がこう変わる」「この自動化ができれば、業務がこれだけ楽になる」。そういった事業インパクトを常に意識しながら、技術選定からアーキテクチャ設計、実装、評価まで一気通貫で関われる。この距離感の近さが醍醐味だと感じています。そして何より、チーム全員で総力戦で突破していく過程が楽しい。エンジニアもビジネスメンバーも関係なく、同じ目標に向かって実験を重ねて、小さい成功体験を分かち合う。部活みたいな一体感があります。
こうした泥臭くもチャレンジングな環境で、事業成果から逆算しながら小さい成功体験を積み重ねていく——その過程を一緒に楽しんでくれる仲間を探しています。
Speee では一緒にこの変革期を楽しんでくれる仲間を募集しています！
Speee では様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれた方は、こちらをチェックしてみてください。
この記事をきっかけに興味を持っていただけたら嬉しいです！
