こんにちは、メルペイiOSエンジニアのkubomiです。 この記事は Merpay & Mercoin Tech Openness Month 2026 の 10日目の記事です。 生成AIによって、エンジニアが短時間でプロトタイプをつくれる場面はかなり増えました。最近、小規模なプロジェクトで「初回ミーティングの前に、動くものをつくり切ってしまう」という進め方を試したところ、意思決定のスピードが劇的に変わりました。私はこのやり方を "Build First, Discuss Later（まずつくる、議論は後）”と呼んでいます。この記事では、その具体的な進め方と、実践を通じて私自身に起きたマインドセットの変化を紹介します。 よくある開発フローと、その課題 私たちの現場では、開発に取りかかる前に、まず関係者の認識をそろえておくのが一般的です。具体的には、最初にプロダクトマネージャー（PdM）が大まかな仕様を用意し、それをもとにキックオフミーティングを開いて詳細を議論します。議論を経てPdMが仕様を固め、エンジニアはその仕様をもとに見積もりを出して実装に入ります。 ただ、議論して仕様を固めたつもりでも、いざつくり始めると「あれ、ここの挙動どうするんだっけ？」という疑問が次々と出てくることがあります。そのたびにPdMへ確認したり、追加のミーティングを開いたりすると、少しずつコミュニケーションの往復が増えていきます。 "Build First, Discuss Later" という提案 そこで私が実践したのが、プロセスの順番をあえて逆転させる "Build First, Discuss Later" です。仕様が固まる前に、まず動くプロトタイプをつくってしまうという発想で、ミーティングはその動くものを土台に議論を進めます。 従来は「議論して仕様を固めてからつくる」流れでしたが、これを「先につくり、その動くものを見ながら議論する」へと入れ替えます。実際に触れる画面があると、抽象的な仕様書をめぐる議論よりもはるかに早く、関係者の認識がそろっていきます。 ただし、何にでもこの進め方を使うわけではありません。何日もかかるような大きな実装でこれをやると、方針が変わったときの手戻りが大きすぎます。私の場合は、数時間から1日以内でつくれるくらいの小規模な施策に限定しています。そのくらいの規模なら、悩んで待つより、とりあえずつくってしまったほうが圧倒的に速い、という実感があります。 ミーティングにプロトタイプを持ち込む3つのステップ 私は "Build First, Discuss Later" を、ミーティングの前・中・後という3つの場面に分けて実践しています。ここでは、アプリの画面にバナーを追加した事例を例に、それぞれの場面で意識していることを順に紹介します。 ミーティング前：自分のベスト案でつくり切る ミーティング前は、手に入る計画書や仕様書をAIと一緒に読み込み、「なぜつくるのか（Why）」「何をつくるのか（What）」を自分なりに解釈します。この段階で最も大事なのは、完璧な実装をつくることではなく、どこが曖昧なのかを目に見える形にすることだと考えています。実際、詳細が決まっていないことがほとんどですが、曖昧な点にぶつかっても立ち止まりません。PdMに質問する代わりに、いったん自分が考えるベストな案でつくり切り、迷ったポイントはミーティングのアジェンダに整理しておきます。 たとえば、バナー追加の事例では、リリースに必要な最小限の機能に絞って早くリリースするか、将来使い回せる再利用性を優先するか迷いながらも、まず最小限の機能で動くプロトタイプをつくりました。UIデザインがまだない場合も、既存の画面部品を組み合わせた仮の見た目で形にしました。 ミーティング中：動くものを見ながら論点を解消する ミーティング中は、その動くプロトタイプを見せながら議論し、可能な限りその場で論点を解消します。意見が分かれそうな箇所には、あらかじめA案とB案を用意し、「私はこういう理由でA案を推します」と推奨案まで添えておきます。バナーの例では、期日を踏まえて、リリースに必要な機能に絞った設計プランと、将来の再利用まで見据えた設計プランを提示し、PdMはその場で前者のプランに合意できました。細かな仕様も、プロトタイプを見ながらサクサクと決まっていきました。判断の材料がそろっているため、議論は驚くほど早く前に進みます。 ミーティング後：決まった内容をすぐ反映する ミーティング後は、決まった内容を仕様書に反映し、実装を微修正したうえで品質保証（QA）のテストに回します。大きなつくり直しが起きにくく、初回ミーティングの直後にはリリースが見えている、という状態になりました。バナーの例では、私がつくった仮の見た目をデザイナーが本番デザインへブラッシュアップし、実装側はそれを反映する微修正で済みました。 "Build First, Discuss Later" で起きた3つの変化 この進め方を試してみると、ミーティングの進み方やPdMとのやり取りがかなり変わりました。特に大きかった変化は、次の3つです。 1つ目は、ミーティングがほぼ1回で完結するようになったことです。うまくいけば、初回ミーティングが終わった時点で仕様も実装もほぼ固まっており、開発見積もりすら不要になることもあります。その後の往復も大きく減りました。 2つ目は、議論が速く、かつ正確になったことです。実際に動くものを見せながら「この画面の挙動はこれでよいですか」と確認できるため、言葉だけのやり取りで生じがちな認識のズレが起きにくくなりました。 3つ目は、PdMの負担が軽くなったことです。エンジニアが具体的な仕様の案まで持っていくので、PdMは方針を確認するだけで済みます。特にPdMが複数プロジェクトを兼務しているような状況では、その確認コストを減らせるだけでも大きな価値があります。 「待つエンジニア」から「提案するエンジニア」へ こうした変化は、単に開発プロセスやコミュニケーションを効率化しただけでなく、私自身のエンジニアとしてのマインドセットにも影響を与えました。 以前の私は、決まった要件を正しく実装することがエンジニアの主な役割だと思っていました。けれど、PdMが持つWhyと大まかなWhatを起点に、まず動くものをつくってみると、「これは要らないかもしれない」「こっちの方がお客さまに価値を届けられるのでは」といった議論を、自分から持ち込めるようになりました。 いちばん大きかったのは、「私はこれがいいと思う」というアイデアを持ってミーティングに参加できるようになったことです。ただ仕様を待つのではなく、要件定義の段階から意見を出し、仕様を決めていく側に少しずつ入っていけるようになりました。 そうやって関わっていると、「この機能は今いちばん自分が詳しい」というオーナーシップも自然と生まれてきます。自分の提案が仕様に反映され、動くものを通じてプロダクトの方向性が決まっていく。その過程に関われるようになって、プロダクトづくりが前より一層楽しくなりました。 生成AIによって「まずつくってみる」ハードルが下がったことで、エンジニアが上流の議論に入りやすくなったと感じています。プロトタイプをつくってミーティングに持ち込むことは、単に開発を速くするだけではなく、エンジニアがより主体的にプロダクトづくりに関わるためのきっかけにもなるのだと思います。 まとめ "Build First, Discuss Later" は、先に動くプロトタイプをつくり、それを見ながら議論することで、意思決定を速くする進め方です。みなさまも、「仕様待ちで開発が始められない」「仕様が曖昧で手戻りが多い」と感じたら、自分なりのプロトタイプを会議に持ち込んでみてください。会話が前に進むだけでなく、プロダクトづくりの楽しさも少し違って見えてくると思います。 次の記事は mewutoさんです。引き続きお楽しみください。

Data＆Analysis部の稲葉です。 キャディは2026年6月10日(水)〜12日(金)にパシフィコ横浜で開催されたSSII2026（第32回 画像センシングシンポジウム）にプラチナスポンサーとして協賛しました。また、キャディから3名が登壇しましたので、当日の様子をレポートします。 オーガナイズドセッション：産業界における生成AIの利活用 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 インタラクティブセッション 終わりに オーガナイズドセッション：産業界における生成AIの利活用 生成AIが産業界でどのように価値を生み、どのような条件で実運用に乗るのかを議論するセッション です。 キャディからは、オーガナイザーとしてシニアリサーチエンジニアの福原（ @gatheluck ）、また講演者として私、稲葉（ @mi_spindel ）が登壇しました。会場には約450名と、非常に多くの方にお越しいただきました。 登壇資料はこちらです。 speakerdeck.com speakerdeck.com 私からは、Data＆Analysis部として取り組んでいる生成AI活用事例として製造業RAGを紹介しました。 （本当は、他にも様々な取り組みがあるのですが、また機会を見て紹介したいと思います。） また、この中で直面した課題の一つが「各LLM/VLMモデルが我々のドメイン特有のタスクをどこまで実行できているかが不明」というものでした。 そこで、製造業LLM/VLMベンチマークとしてManuDraw-Benchを独自構築し、比較評価したお話しをしました。 皆様からのたくさんの質問をいただきまして、ありがとうございます。当日は時間の関係で回答しきれませんでしたので、ここで回答したいと思います。 Question： CADでのDXFはパースせずに図面の見た目で拾ってしまった方が総合的なコストが安いという判断でしょうか？ Answer：DXFなどベクター図面のまま処理した方が、QualityやCostの観点で良いタスクは存在していると思います。ただ、結局はimage encoderが必要なタスクはありますし、処理プロセスの種類が増えることによって運用負荷も増えますので、QCDを総合的に判断して技術選定をしています。 Question：会社の固有知識については基本的にはRAGで対応となると思うのですが、RAGでは対応しきれないのではないか、モデルの Fine Tuning が必要ではないかという意見も社内であり、意見が分かれています。 Fine Tuning まで実施したというような事例はあるでしょうか？ Answer：Fine Tuningまで実施した事例があるかないかの詳細はお答えできないのですが、Fine Tuningを考える前に基本はナレッジ管理とGroundingで対応できないかを先に考えるべきだと思っています。また、Fine Tuningと言えど一定のデータ量は確保しなければならないですが、機密情報の漏洩を考えると個社ごとに調整をすることになりがちです。確保できるデータ量とその労力に対する効果を検討する必要があります。 Question：過去の故障事例などは、設計改善に使用可能なレベルで、原因情報が現場から上がってくるモノでしょうか？実は、原因をLLMが把握するところに課題はないでしょうか。 Answer：おっしゃる通りで原因とその対応が上がってくる仕組みを作ることが重要ですし、そこは課題です。その解決のためにも、キャディが提供しているような部横断のデータ基盤を構築しデータを紐づけることが必要になります。 Question：P15のVLMによる3次元点群予測は1点1点を文字列として出力しているわけではないのだと思いますが、Pythonスクリプト出力などでCADモデリングさせて、表面に点を生やしているのでしょうか？ Answer：1点1点を点群を文字列として出力させているのではなく、メッシュモデルとして形状を面の組み合わせで出力させてから点群サンプリングをしています。おっしゃるようにPythonスクリプト出力などでCADモデリングする方法もありますが、コーディング能力や各LLM/VLMが扱える開発環境にも依存するため、このような方法を取っています。 Question：位置やサイズなど幾何的な理解の性能は、モデルの進化を待てばある程度上がってきそうなベンチの結果になっているのでしょうか？ Answer：そのあたりは今後の傾向を見てみないと何とも言えないところですので、今後もトラッキングしていきます。ただ、自然画像や文字列で表現されている位置やサイズの理解は進化が見られます。 Question：3面図とアイソメ図でVLMからみた理解度にどれだけ差があるのでしょうか？VLMの訓練にメインで使われているであろう写真データには三面図的な見え方は珍しそうに思います。写真に近そうなアイソメ図の方が理解してくれたりするのでしょうか？ Answer：とても良いご指摘です。三面図をそのまま与えるよりは、斜めから見たアイソメ図の方が形状の理解力は高い印象です。ただ、アイソメ図には寸法など必要な情報が抜けているので、処理プロセスのどこかでアイソメ図にリフトするとかデータを組み合わせて利用するとか工夫は必要にはなると考えています。 共に登壇いただいたエクサウィザーズの加藤様、LayerXの松村様、素晴らしい発表をありがとうございました。エクサウィザーズ様はやはり取り組まれていることの幅が広いですし、生成AIの性能だけでなくUI/UXやガバナンスといった活用推進の重要なポイントを俯瞰して抑えられているなと感じました。LayerX様はAgentありきの業務フローに変革していく強い意思を伝えながらも、結局は当たり前をやりきれるかという話に共感しました。 登壇の様子 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 昨今の3D基盤モデルなどの潮流を概観し、CAD解析技術の実プロダクト適用における「研究と実践」のリアルを解説するセッション です。 キャディから、Data Platform本部長の今井（ @imaimai0 ）が登壇しました。こちらも500名近い方に聴講いただくことができました。 speakerdeck.com なぜ製造業においてCADが重要なのか、CADの活用において何がボトルネックになっているのか、最新研究の動向はどうなっているのかをお話ししています。 詳細は資料をご確認いただけると幸いですが、私からは特に、CAD（Geometric系）やMechanical Engineering系の研究開発をもっと盛り上げたいと思っていることをお伝えしたいです。 資料の中でもCVPRにおいてGeometric系の論文は5%程度というお話しがありましたが、製造業のGDPが日本の2割程度を占める巨大産業にも関わらず日本においても類似の研究開発が少ないように思います。我々もResearchチームの規模を拡大中ですし、共同開発や共同研究の機会も探しているところです。一緒に盛り上げていただける仲間を募集中です。 インタラクティブセッション 6/11（木）のブース出展では、多くの方にキャディブースへお越しいただきました。セッションを聴講して「話を聞いてみたい」と立ち寄ってくださった方もいらっしゃいました。 ポスター発表では、現在取り組んでいる研究開発テーマを紹介しました。注力しているテーマとして、以下の3点をご紹介しました。 設計資産全体を横断して検索するための、2D図面と3D CADモデルの埋め込み空間の統合 3D CADデータ内の加工に必要な特徴の認識 製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Bench ManuDraw-Benchは公開されているのか？されないのか？といった質問をたくさんいただきましたが、権利の関係上公開は難しいです。ただ、業界の研究開発を促進したいと思っていますので、何かしら対応を考えていきたいとは思っています。 お話いただいた皆様、本当にありがとうございました！ 終わりに SSII2026への協賛・参加を通じて、製造業領域におけるAIの研究開発の現状や、その中でのキャディのチャレンジについて知っていただく貴重な機会となりました。また、来場者の方との交流から、日々取り組む課題に対してもヒントを得られる非常に有意義な場でした。 運営の皆様、素晴らしい会をありがとうございました。 今後もキャディは技術的な挑戦を続け、画像センシング・コンピュータビジョン研究コミュニティの発展と、モノづくり産業のポテンシャル解放の両面に貢献していきたいと思っています。 また皆さんとお会いできることを楽しみにしています！

こんにちは、ラクス技術広報です。 AIツールが開発現場に届いたあと、何が起きているのか。ChatGPT EnterpriseやGitHub Copilotが展開されてしばらく経ったころ、ラクスの開発本部横断組織「開発管理課」はある問いに詰まっていました。ツールは使えている。使っているエンジニアもいる。でも組織として本当に生産性が上がっているのか、確かめる手段がなかった。 実際に声を集めてみると、大きく個人差が開いている状況でした。AIを使いこなしてどんどん先へ進む人と、今まで通りのやり方を続ける人。「チームによって開発スピードに差が出てきている。個人の問題というより、組織として型がないことが課題だと感じていた」と担当者は言います。 ラクスは楽楽精算・楽楽明細・楽楽自動応対など複数のクラウドサービスを展開しており、開発組織は商材ごとに独立したチームで構成されています。チームが独立しているぶん、AI活用のやり方も自然と各チーム任せになりやすく、活用度にムラが出やすい環境でもあります。このムラをどう埋め、組織全体に浸透させるか。開発管理課がどう向き合っているのかを、担当者に語ってもらいました。 まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して まず「測る」ことを設計した 「浸透しているかどうかが見えない」問題を解くために、開発管理課が最初に選んだ一手は計測の仕組みを作ることでした。 参考にしたのはSalesforceが実施していた48項目にわたるAI浸透度調査。ただ、そのまま導入するのは規模が大きすぎる。削り込んでいっても20問ほどになってしまい、それでもまだ多い。さらにラクス特有の難しさがありました。ラクスの開発組織は商材ごとにチームが独立しており、技術スタックも文化も異なる。単一組織向けに設計されたサーベイをそのまま当てはめても、実態を正しく測れない。加えて「どのツールを使っていますか」「その機能は使っていますか」という質問は、ツールや機能が変わるたびに使えなくなる。「変わらない計測軸で、AI導入を継続的に観測するにはどうすればいいか」という問いに、担当者は上長と二人で揉みに揉みました。 行き着いたのが「プロセス別AIコミット度」という設計軸です。実装・テスト・設計・要件定義といった各開発フェーズで、どれだけAIを活用しているかを問う。ツールの名前ではなく「工程への組み込み度合い」を問うことで、環境が変わっても変わらない比較軸を持てるようになりました。これにより、管理職への相談も「感覚値」から「数値に基づく議論」に変わっていきました。 第1回サーベイを実施すると「一歩目を踏み出せていない人が一定数いる」ということが数字としてはっきりしてきました。次の問いは「なぜ使われていないのか」でした。 具体的な計測設計については、2026年1月開催のイベントで詳しく発表しています。 speakerdeck.com 「使わない」には、それぞれの理由があった サーベイを取りながら、担当者は管理職や現場メンバーへのヒアリングも重ねていました。すると、「使わない」には想像以上に多様な事情があることが見えてきました。 担当者の印象に残っているのは、こんな声でした。 「"AI活用してます"とは言いにくい」 エンジニア文化特有の謙遜として、「AIちょっとできます」と名乗ること自体への抵抗感がある。「使っている」と言うのが気恥ずかしく、結果として使っていないように見えてしまう人が一定数いた。 「ハルシネーションでテストが増えて、むしろ手間が増える」 AIを入れると今まで動いていたコードがずれてしまい、テストの修正コストが上回る。「わざわざAIに作り直させると余計に手間が増える」と感じている人がいた。 「試行錯誤の時間が取れない」 高負荷な業務を抱えながら、AIを自分の業務にフィットさせる時間が取れない。「失敗したらまた手直しもしなきゃいけない。片手間でなんとかするのは難しい」という声もあった。 「AIとチャットはするけど、開発業務で効率的に使う方法がわからない」 AIとやりとりすること自体はしている。でも、実際の開発のどの場面でどう使えばいいかイメージが持てず、業務への組み込みは試せていない。気づけば「使っていない人」になっていた。 こうした声を踏まえ、「まず一歩目を踏み出せていない人をケアする」という方針で勉強会を設計しました。GitHub Copilotのベンダー開発者を招いたQA付きセッション、社内のAI推進者によるClaudeの活用ハンズオン。ハンズオンでは「AIとチャットするだけでなく、実際の業務にどう組み込むか」にフォーカスしたプレゼンを行い、参加できなかったメンバーのために動画も社内に公開しました。「特にあまりAIに触れていなかった方々からは『ためになりました』という声が届きました」と担当者は振り返ります。 AI活用は確かに進んだ。でも、浸透しきってはいない 2025年9月の第1回から約5ヶ月後、2026年2月の第2回サーベイでは、開発本部全体のAI生成比率が約15ポイント上昇（43.3% → 58.3%）。「生成比率75〜100%」と回答したエンジニアの割合も30%から50%以上に増加し、AI活用が個人の試みから組織的な広がりに変わってきた手応えがあります。 一部のチームでは、より具体的な成果が出ています。 コミットからマージまでのサイクルタイムが、以前の数分の1以下に短縮された 実装工程の大部分をAIが生成するようになった（実装工程のAI生成比率は60%台から70〜90%台に到達） リリース頻度が倍近くに上がった 「仕様駆動開発（SDD）」の導入で、ある工程の工数が半分以下になった テスト項目書からE2Eテストを自動生成する取り組みで、テスト工程も大幅に削減できた 楽楽明細・楽楽自動応対チームなど一部チームでは、要件定義・概要設計といった上流工程でのAI活用率も20%台から50〜60%超に向上。設計フェーズでもAIが機能する段階に入ってきています ただ、組織全体を見渡すと、AIはまだ浸透しきっていません。商材や個人のスキルによって、活用度にムラがあります。AI活用が進んでいるチームのやり方は、そのチームメンバーの体に染み込んだ暗黙知になっており、「隣のチームでも再現したい」となったとき、そのままでは届きません。「何ができるか」を検証するフェーズは超えた。「組織全体にどう行き渡らせるか」が、今期のスタート地点です。 顧客に届けるための、AI活用標準化 なぜAI活用を組織として標準化するのか。答えは「開発を速くしたいから」だけではありません。 ラクスの開発組織が最も重視している価値観は「顧客志向」です。顧客が抱える業務課題を深く理解し、それを解決するプロダクトを届けること。個人のAI活用では、顧客への価値提供スピードを「組織として」上げるには不十分です。一部のチームの開発スピードが上がっても、全体が変わらなければ、顧客が受け取る価値の差分は限定的です。だからAI活用を「組織の標準」にする必要があります。 AI活用が進んでいるチームを観察すると、スキルや知識だけでなく「どの工程で・どんなインプットを渡せばAIが機能するか」という設計が体に染み込んでいます。これは情報共有だけでは伝わりません。型化の優先順位は「顧客価値に最も直結する工程」から決めています。 今期進める4つの取り組み 以下の4つの取り組みを通じて、全商材で高速かつ高品質な開発プロセスを再現性のある形で確立していきます。 ① AI駆動開発手法の標準化 設計・実装・レビュー・テストで、なるべくエンジニアの介入が要らないAI活用の「型」を統一します。成果が出ているチームの事例を収集済み。仕様駆動開発の型化が進行中。 ② 商材特性に応じた最適化 各工程でのAI駆動開発を磨き込み、より精度の高いAIワークフローを実現します。商材・技術特性に応じて使い方を順次アップデートしていきます。 ③ ナレッジの体系化・横展開 成功・失敗を含む実務レベルの知見をガイド化し、誰でもアクセス可能な形で集約します。キャッチアップの土台を整備し、勉強会支援や情報共有の場も整えていきます。 直近のハンズオン会アンケートでは、「他チームとの密接な情報共有がほしい」という声が50%に上り、事前に最多と予想されていた「技術的なトレーニングやワークショップが必要」と同数でした。知識を増やすことと同じくらい、「隣のチームが何をしているか」を知ることが求められています。 ④ AI活用の浸透度・生産性の可視化 「測れないものは改善できない」という考えから、AI活用の推進状況を可視化する仕組みを整備しました。開発・インフラ・QA・PdM・PDを対象に、各工程でのAI活用状況を定義した「AI活用実践カタログ」です。定性的な「なんとなく進んでいる」から、「ここが遅れている、だから次はこうする」という定量的な議論への転換を目指しています。 「エンジニア非稼働時間帯でも開発が進む」を目指して 一部のチームでは、エンジニアが設計に集中している間にAIが実装を進める状態が見えてきています。非稼働時間帯も開発が動く。そのゴールの射程が、ようやくリアルになってきました。 ただ正直に言うと、型が定まっていない領域はまだ多く、ナレッジの体系化も道半ばです。それでも「組織全体にどう行き渡らせるか」という問いに正面から向き合えるタイミングになってきた、と感じています。 この取り組みについて、もう少し詳しく聞いてみたいという方には、7月15日（水）開催のオンラインイベントの視聴をご検討ください。CTOや執行役員をはじめ複数のエンジニアが、複数プロダクト組織でのAIネイティブ化の実践をリアルに語る場です。無料・オンラインで参加できます。 「CTO登壇」RAKUS AI Conference 2026 Summer