SSII2026（画像センシングシンポジウム）にスポンサー・登壇しました
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
- LLM
- CAD
JSAI2026（人工知能学会全国大会）にプラチナスポンサーとして協賛しました
こんにちは！Data＆Analysis部の今野です。 キャディは2026年6月8日(月)〜12日(金)にGメッセ群馬で開催されたJSAI2026（人工知能学会全国大会 第40回）にプラチナスポンサーとして協賛させていただきました。この記事では5日間にわたる開催期間中の当社ブースの出展報告や、聴講した技術セッションのレポートをお伝えします。 会場紹介 ブース紹介 聴講したセッションの感想 非構造データからの情報抽出 画像音声メディア処理：視覚言語理解とマルチモーダル生成 終わりに 会場紹介 まずは会場の様子を紹介します！ 場内では複数のセッション・企業展示・ポスター発表が同時並行で実施されていました。企業展示では、多様な業界に跨る159社の企業が、生成AIに限らない幅広い機械学習技術の産業応用に関して紹介をしていました。私も色々なブースを訪れ、エンジニアの皆さんと意見交換をさせていただきました。 場内の案内図 大規模言語モデル等の生成AIとともにフィジカルAIも大きなテーマの一つとなっていて、実際に入口付近ではGMOインターネット株式会社のブースの前でヒューマノイドロボットが来場者を迎えていました。 入口から見た会場の様子 ブース紹介 次にキャディのブースについて紹介します！ ブースでは、主に私たちが提供している「製造業AIデータプラットフォームCADDi」の中で使用されている機械学習技術や現在取り組んでいる研究開発テーマの紹介をしました。また本サービスのデモを通して、実際に製造業の現場の課題解決にどのように貢献しているかを実感してもらえるようにしました。 注力してR&Dを行っているテーマの中でも、設計資産全体を横断して検索するための2D図面と3D CADモデルの埋め込み空間の統合・3D CADデータ内の加工に必要な特徴の認識・製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Benchの3点について紹介させていただきました。 ノベルティとしては、キャディが各所で出展する度に大人気の「データ活用カツ」や製造業をイメージしたマイクロファイバークロスをお配りしました。 図面が文書としての特徴と幾何学的な形状が融合した複雑なデータであることやその中に潜む活用しきれていない情報の価値であったり、テキストや画像と比べるとあまり一般的でない題材の3D CADに対してどのようなアプローチを課題に応じて選択しているかについて関心を持って頂くことができました。 イベント期間中、キャディのブースに立ち寄ってくださった皆さん、本当にありがとうございました！ 聴講したセッションの感想 次に、聴講させていただいたセッションの感想を簡潔にまとめます。 非構造データからの情報抽出 株式会社リクルートの中田さんとSansan株式会社の山内さんがオーガナイザとして実施されたセッションです。 複数ページの請求書 ・医薬品データ・技術マニュアル ・有価証券報告書 など、多種多様な産業の実務に溢れる「非構造データ」から、いかに正確かつ網羅的に情報を抽出するかという共通の課題に対する検証結果が発表されました 。 問題設定及びそれに対して提案された手法は様々ですが、ほとんどの発表においてVLMが手法の中心に据えられていたことが印象的でした。引き続き物体認識やOCRに特化したモデルの有効性は変わらないものの、大規模言語モデルの推論能力を生かした情報の構造化はこの領域において避けては通れないものになっていると感じました。その中で、プロンプトの工夫・画像の前処理・ステップの分割・検索システムの統合など能力を最大限に引き出すための多岐に渡る手法が検証されていました。 図面という非構造化データからの情報抽出は我々の中心にある課題の一つで、日頃の取り組みと密接に関連したセッションであり、これから解析対象のカバレッジを拡張していくに当たり非常に示唆に富んだ内容でした。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/acHLauKQ 画像音声メディア処理：視覚言語理解とマルチモーダル生成 本セッションでは、画像・音声・対話データといったマルチモーダル情報を対象に、人間の認知特性や数理的アプローチを組み合わせて処理のブラックボックスを解き明かし、生成・推論の「制御性と効率性」をいかに向上させるかという共通の課題が議論されました 。 特に印象的だったのは、東京大学の大坂さんによるVLMにおける視覚アクセス境界の存在を実証した研究です 。この研究では、思考のプロセスを言語化させるChain-of-ThoughtプロンプティングをVLMで行う際、モデルが「長く考えること」で視覚的な特徴抽出を拡張しているわけではなく、実際には言語空間内での記号的推論を延長しているに過ぎないという機構を示すものでした。 過去のテックブログでも紹介しているように、図面からより高度な情報の獲得を目指していくに当たり、VLMのメカニズムに起因する視覚情報に基づく推論の限界は我々も課題に感じており、この問題を新たな視点で捉えられる研究内容であるように感じました。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/fQHM84pJ 終わりに 5日間にわたるJSAI2026への協賛・参加を通じて、AIに関するアカデミックな着目点や産業応用における最新の機械学習技術について幅広い知見を得られる貴重な機会となりました。また、会場での多くの交流や専門的なセッションから、VLMの可能性など我々が日々取り組んでいる課題に対してもヒントを得られる非常に有意義な時間でした。 スピーカーの皆さん、参加者の皆さん、運営の皆さん、素晴らしい会をありがとうございました。今後もキャディは技術的な挑戦や現場の課題解決に向けた取り組み、そして研究開発の内容を積極的に発信し、エンジニアコミュニティの発展の一助となれるような貢献を続けていきたいと思っています。 次回、また皆さんとお会いできることを心より楽しみにしています！
- 生成AI
- 機械学習
DependabotとDevinを組み合わせて、CVE対応のスキームを作ってみた話
TL;DR Dependabotの脆弱性アラートをSlackに流し、Devin（AIコーディングエージェント）でトリアージ・修正を行うスキームを構築しました CVE脆弱性アラートを、チームで効率的に対応できるようになりました AIの活用で「セキュリティよくわからないから放置...」が「なるほど、そういう脆弱性なのか。これなら対応できそう」に変わりました はじめに 製造業データ活用クラウド CADDi Drawer開発チームの大道です。 突然ですが、みなさんのリポジトリにDependabotのアラート、溜まっていませんか？ 「あ、また増えてる...まあ今は忙しいし、後で見よう」って思っちゃいません？ npm install をした際のCriticalやHighの件数を見て、「嫌なものを見たな〜」という気持ちになりませんか？ こうして「後で」が永遠に来ないまま、気づけばアラートが大量に溜まっている。そんな経験、ありませんか？ この記事では、DependabotとDevin（AIコーディングエージェント）を組み合わせて、CVE対応が「回り続ける」仕組みを作った話を紹介します。セキュリティの専門知識がなくても「とりあえずやってみよう」と思えるような内容を目指しているので、気軽に読んでいただけたらうれしいです。 背景：なぜスキームを作ろうと思ったか 「気づいた人がやる」運用の限界 もともと私たちのチームでは、CVE脆弱性アラートへの対応は「気づいた人がやる」スタイルとなってしまっていました。 Dependabotからのメール通知は飛んでくるのですが、日々の開発メールに埋もれてしまい、気づかないことがほとんどです。たまたま気づいた誰かが善意で対応してくれる。でも、その「誰か」がいない日は、当然誰もやりません。「誰か」がやってくれたことに対する感謝も埋もれがちです。 放置するリスクは一定ある 実際、多くの脆弱性は到達可能性（Reachability）がなく、自分たちのコードから該当の関数を呼んでいないケースがほとんどです。この経験が積み重なると、「今回も大丈夫か」と思ってしまうのは、ある意味エンジニアとしての経験則でもあります。 ただ、最近はリスクを巡る状況も変わってきています。 AIの進化によって、攻撃用のコードを生成するハードルが大きく下がりました。以前であれば高度な知識が必要だったエクスプロイトの作成も、今ではAIを使えば比較的容易にできてしまう時代です。その結果、ゼロデイ攻撃のスピードは加速し、公開される脆弱性の件数自体も増加傾向にあります。 そして、もしセキュリティインシデントが起きてしまった場合、事業へのインパクトは計り知れません。顧客データの漏洩、サービスの停止、信用の失墜...。「大丈夫だろう」の一言では済まされない世界です。 だからこそ、エンジニアとしては微妙なストレスを抱えているのも事実ではないでしょうか。「たぶん大丈夫」と思いつつも、心のどこかで「もしこれがインシデントにつながったら...」とビクビクしている。そのストレス、放置しているアラートの数に比例して大きくなっていませんか？ DependabotのPR自動作成機能に対する要望 Dependabotには検知した脆弱性に対して、自動でPRを作成してくれる便利な機能がありますね。 ですが、「もっとこうなったらよいな」と思うものもありました。 変更の妥当性を判断する情報が乏しい: 「このパッケージをx.x.xからy.y.yに上げます」としか書かれていない。破壊的変更があるのか、自分たちのコードに影響があるのか、PRを見ただけでは判断しづらい プロジェクト固有のルールを守ってくれない: 私たちのチームでは「lockfileの直接編集禁止」「overridesは原則使わない」といったガイドラインがありますが、Dependabotにそれを強制する術がない （もしかしたらRenovateなら設定を駆使すればこのあたりは回避する方法があるかもしれませんね） 結局、PRが来ても「これ、マージして大丈夫...？」と不安になり、確認コストが高くなりがちでした。 セキュリティの知見、チームで底上げしたい もうひとつ、スキームを作りたかった理由があります。 脆弱性対応は、最終的には人間が判断する必要があります。「この脆弱性は本当に自分たちのアプリに影響があるのか？」「Hotfixを当てるべきか、通常リリースでいいのか？」。こうした判断は、AIに丸投げするわけにはいきません。 そもそも、「どのような脆弱性なのか」がわからないという問題もあります。SQLインジェクション、XSS、プロトタイプ汚染...。名前は聞いたことがあっても、具体的にどういう攻撃手法で、どうガードすればいいのか。アプリケーションエンジニアとして、こうした知識は本来持っておいたほうがいいはずです。 そういった知見は、自分たちのアプリケーションに対してコードを書いたり、AIが書いたコードをレビューする際にも役に立つはずです。 ただ現実には、こうしたセキュリティの知識を、アプリケーションエンジニアが体系的に学ぶ機会はそう多くありません。業務の中で自然と身につく類のものでもない。だからこそ、CVE対応のプロセス自体を「学びの機会」にできないか、という思いもありました。 実際に組んでみたスキーム 全体のフローは以下のようになっています。 graph TD A[Dependabot検知] --> B{Severityがチームの既定値以上?} B -- No --> C[無視] B -- Yes --> D[Slack通知] D --> E[Code Ownerがアサイン] E --> F[担当者がトリアージ] F --> G{Hotfix必要?} G -- Yes --> H[即時対応・特殊フロー] G -- No --> I[通常修正] I --> J[AIレビュー実施] J --> K{Humanレビュー必要?} K -- Yes --> L[Human Review] K -- No --> M[Merge & Slack報告] L --> M それぞれのステップを見ていきましょう。 Step 1. まずSlackに流す ― 「気づく」の自動化 最初にやったのは、Dependabotのアラートを Slackに流すこと でした。 GitHub Actionsで1時間ごとに新規アラートをチェックし、Incoming Webhookで専用のSlackチャンネルに通知します。チームリーダーへのメンション付きなので、見逃しにくい仕組みです。 やっていること自体はシンプルですが、 「普段見ているインターフェースに情報を届ける」 というのが大事なポイントです。メールは埋もれますが、Slackは（良くも悪くも）みんな見ています。通知先を変えるだけで、「気づかなかった」という問題がほぼなくなりました。 Step 2. Devinにトリアージを依頼 ― 「理解する」のハードル低下 アラートに気づいたら、次はトリアージです。 ここで活躍するのがDevinです。Slackのスレッドから、こう打つだけです。 @Devin !triage_cve CVE-XXXX-XXXXX Devinは事前に設定したPlaybookに従って、以下のことを調べてくれます。 脆弱性の概要と深刻度: CVEの内容を平易な日本語でまとめてくれる 到達可能性（Reachability）: 脆弱性のある関数を自分たちのコードが実際に呼んでいるかを調査 devDependenciesかどうか: 開発環境のみの影響なら緊急度が下がる Hotfixの必要性: 上記を踏まえて、通常リリースで良いか、Hotfixが必要かの判断材料を提示 SlackにDevinがトリアージ結果を投稿した様子 これが本当にありがたいのです。以前は「CVEの英語ドキュメントを頑張って読み解く」必要がありましたが、今はDevinが要点をまとめてくれるので、エンジニアは 「判断する」ことに集中 できます。 セキュリティに詳しくないメンバーでも、Devinのレポートを読めば「なるほど、これはdevDependenciesだけだから緊急度は低いな」「これは実際にリクエスト処理で使っているライブラリだから早めに対応しよう」と判断できるようになりました。 ただし、最終的な判断は必ず人間が行います。 これはエンジニア組織のルールとして、キャディ株式会社 共同創業者兼最高技術責任者 CTOの小橋から明確なメッセージが発信されています。AIは優秀ですが「責任」はとってくれません。 Slackのスレッドでやりとりされるので、迷ったらリーダーや有識者に相談するのもやりやすいです。 Step 3. Devinに修正も依頼 ― 「直す」の効率化 トリアージが終わったら、修正です。ここでもDevinに頼ります。 @Devin !Patch_cve DevinはPlaybookに定義された修正ガイドラインに沿って、PRを作成してくれます。 私たちのチームでは、以下のような修正ルールを定めています。 セマンティックバージョニングの範囲内で更新する: メジャーバージョンを勝手に上げない。 overridesは原則使わない: 親パッケージが指定した範囲内で一時的に引き上げるために使うのであればよいが、レンジ外のバージョンへ無理やり上書きすると、テストされていないパッケージの組み合わせになるリスクがある。 Dependabotにはこうしたプロジェクト固有のルールを守らせることが難しかったのですが、DevinならPlaybookに定義しておくことで遵守させることができます。これが、修正をDevinに任せている大きな理由です。 PRが作成されると、AIレビュー（Devin ReviewまたはCopilot Review）が自動で実施されます。もちろん、Humanのレビュアーも必ずアサインします。 Step 4. 週次定例でカバー ― 仕組みの穴を塞ぐ どんな仕組みにも漏れはあります。リーダーが休みでアサインが遅れた、Devinの修正がうまくいかなかった、親パッケージが未対応でそもそも直せない...。 こうした漏れを拾うために、週次の定例MTGで滞留しているアラートをチェックしています。 直接対応できないケース（間接依存のパッケージに修正パッチが出ていない場合など）は、チケットを起票して管理します。フィルターで一覧化し、定例MTGにて状況を確認しています。 そしてもうひとつ、この場で 対応してくれたメンバーをちゃんとレポートに載せる ようにしています。脆弱性対応は地味な作業です。やっても新機能のリリースのように派手に褒められることは少ない。だからこそ、「あなたが対応してくれたおかげで安全になりました」と可視化することが大切だと考えています。 振り返って重要だと思ったこと このスキームを運用してみて、いくつか大事だと感じたことがあります。 普段見る場所に通知する、それだけで変わる 正直、これが一番効果がありました。 メールからSlackに通知先を変えただけで、アラートへのリアクション速度が段違いに変わりました。人は「目に入るもの」には反応するんですよね。「気づきの導線設計」は、ツールの選定以上に大事かもしれません。 AIがセキュリティのラーニングコストを下げてくれた CVEの内容を理解し、影響範囲を調査し、修正方針を考える。以前はこの一連の作業が重くて、「できる人」に偏りがちでした。 AIが一次調査を肩代わりしてくれることで、セキュリティに詳しくないメンバーでも対応できるようになりました。AIは「判断するための情報収集コスト」を下げてくれる存在です。 「セキュリティの知見がないから自分には無理」というハードルが、チーム全体で下がったのは大きな変化でした。 でも、最後は人間が判断する AIが便利だからといって、すべてを任せるわけにはいきません。 Hotfixを当てるかどうかの判断 破壊的変更を含むアップデートの影響範囲の最終確認 本当にマージして問題ないかの判断 これらは人間の責任です。そして、AIのおかげで「判断に必要な材料を集めるコスト」が下がっているからこそ、人間が判断そのものに集中できるようになったとも言えます。 やった人をちゃんと認知する 繰り返しになりますが、脆弱性対応は報われにくい作業です。ユーザーに見える新機能を作るのとは違って、「何も起きなかった」が成果になります。 だからこそ、週次レポートで対応者を可視化する仕組みは大事にしています。「ありがとう」が自然に言える仕組みは、運用を続けるための燃料です。 おわりに 「脆弱性のアラート、見なかったことにしよう...」 この記事を読んでくださった方の中にも、そんな経験がある方がいるかもしれません。 でも、仕組みを作ってみて思ったのは、負債はちゃんと細かく返していったほうが、精神衛生上いい ということです。溜めれば溜めるほど重くなるし、見ないフリをしている間のストレスは意外と大きい。 完璧な運用じゃなくていいんです。「回り続ける仕組み」をまず作ること。そしてAIの力を借りれば、セキュリティという重たいテーマのハードルも、思ったよりずっと下がります。 この記事が、みなさんの脆弱性対応の第一歩になれば幸いです。
- Dependabot
- GitHub Actions
- 生成AI
AI時代のQA実験：仕様書でテスト品質が2〜3倍変わる
はじめに こんにちは。Reliabilityグループ QAエンジニアのmeguroです。 最近、開発現場でAI Agentがコードを書く場面が増えてきました。Claude CodeやGitHub Copilotを使えば、APIサーバーの実装が数分で完成します。テストコードも自動生成される。開発スピードは確かに上がっています。 しかし、QAエンジニアとして、あることが気になりました。 「AI Agentが生成したテストコードの品質は、どうやって担保すればいいのか？」 同じAI Agentなのに、時には網羅的なテストを書き、時には重要なケースが抜け落ちている。この品質のばらつきは、一体何が原因なのか。 QAとして、AI時代のテスト品質をどう管理すべきか。その答えを探すため、実験を行いました。同一のタスク管理APIを3パターンの仕様書で実装し、生成されたテストコードの品質を定量的に比較してみました。 結果は明確でした。 仕様書の書き方次第で、AI生成テストの品質が2〜3倍変わる。 AI Agentは「書かれたことは確実にテストする」が「書かれていないことはテストしない」という特性があります。 つまり、仕様の完全性が品質を決定するのです。 この記事では、その実験の過程と、品質を担保するための具体的な知見をお伝えします。 実験設計：同一APIを3パターンの仕様で実装 実験の概要 今回の実験は、特定の仮説を検証するのではなく、「AI Agentの特性から逆算して、品質を担保するために必要な要素を導き出す」という演繹的なアプローチをとりました。 AI Agentには「指示されたことは忠実に実行するが、行間は読まない」という特性があります。この前提（公理）から、「人間が暗黙的に行っている思考」をどの段階まで具体化して与えれば、納得する品質に届くのかを検証するため、以下の3段階のPoCを設計しました。 3つのPoC poc-1-minimal（最小限仕様） エンティティ定義 エンドポイント一覧 エラーマッピング表 認証・認可ルール poc-2-tdd（TDD手法追加） poc-1の仕様 + TDD手法の指示 実装順序の指定 具体的なテストコード例 poc-3-strategy（テスト戦略追加） poc-1の仕様 + テスト戦略ドキュメント 5つの品質指標の定義 検証すべき仕様項目の具体例 評価指標（5つの品質メトリクス） テストコードの品質を測るため、過去のバグを分析し、実際に見落とされがちな5つの指標を設計しました。 Schema Coverage（スキーマカバレッジ） 定義：レスポンスの全フィールドが検証されているか 計測方法：検証済みフィールド数 / 全フィールド数 目標：100% Post-Condition Coverage（事後条件カバレッジ） 定義：書き込み操作で「対象レコード・関連レコード・不変条件」の3点が検証されているか 計測方法：検証済み事後条件数 / 全事後条件数 目標：100% Error Mapping Consistency（エラーマッピング一貫性） 定義：HTTPステータスコードが全エンドポイントで一貫しているか 計測方法：実装済みエラーパターン数 / 全エラーパターン数 目標：100% Authorization Coverage（認可カバレッジ） 定義：全ロール×全エンドポイントの組み合わせがテストされているか 計測方法：テスト済み組み合わせ数 / 全組み合わせ数 目標：100% Abnormal Test Ratio（異常系テスト比率） 定義：4xx/5xxテストの割合 計測方法：異常系テスト数 / 全テスト数 目標：60%以上 実験結果：仕様の質が品質を決める さて、実際にAI Agentに実装させ、その実験結果を見ていきましょう。 定量結果サマリー 指標 poc-1 poc-2 poc-3 戦略 改善率 Schema Coverage 43% 61% 100% 2.3倍 Post-Condition Coverage 22% 39% 100% 4.5倍 Error Mapping Consistency 31% 90% 97% 3.1倍 Authorization Coverage 48% 80% 100% 2.1倍 Abnormal Test Ratio 53% 58% 48% 0.9倍 注目すべき3つの発見 結果を分析していて、特に興味深かった点を3つ紹介します。 発見1：TDD手法はError Mapping Consistencyで劇的改善（31%→90%） poc-2では、CLAUDE.mdに具体的なテストコード例を含めました。 その結果、AI Agentはこのパターンを全8エンドポイントに自動適用し、401テストが網羅的に生成されました。一方、poc-1では「認証なしは401を返す」とテキストで書いていましたが、テストは1エンドポイントにしか書かれませんでした。 学び：抽象的な指示（「全エンドポイントで認証テストを書く」）よりも、具体的なコード例の方がはるかに効果的です。 発見2：テスト戦略はスキーマ・認可で100%達成 poc-3のdocs/test-strategy.mdには、全32通りの検証パターンをマトリクスで指示しました。 結果、AI Agentはその表を見て「全8エンドポイント × 4ロール = 32パターン」のテストを自動生成してくれました。さらに、Schema Coverageについても、Protoの全フィールドを1つずつ検証するテストコードを生成しました。 学び：「何を検証すべきか」が具体的に列挙されていれば、AI Agentは漏れなく実装してくれます。 発見3：poc-1でも53%の異常系テストは書かれる 意外だったのは、最小限の仕様でも、異常系テストは過半数書かれていたことです。これは、エラーマッピング表（404/400/403/500の定義）を明示していたおかげでした。 ただし、一貫性に欠けていました。例えば POST /projectsには401テストあり PATCH /tasksには401テストなし 学び：「何をテストすべきか」の明示的な指示がなければ、AI Agentは恣意的にテストを選んでしまいます。 なぜAI Agentには異なる仕様が必要なのか？ ここまでの結果を見て、「なぜこんなに差が出るのか？」と疑問に思われた方もいるかもしれません。 その理由は、人間とAI Agentの根本的な違いにあります。 人間とAI Agentの根本的な違い 人間の開発者： 仕様（80%完成） + 暗黙知 + 経験 + コミュニケーション → 完全な実装 AI Agent： 仕様（100%必須） → 実装品質 品質を担保するために意識すべき6つの観点 この実験を通じて明らかになったのは、「頭の中で考えている品質の視点」を、明示的に定義することの重要性です。 従来、エンジニアは「暗黙知」を持っていました。 人間の開発者なら、レビューやコミュニケーションで補えました。 しかし、AI Agent時代では、思考プロセスを仕様書に明記する必要があります。 以下、品質を担保するために意識すべき6つの観点と、実験で得られた知見を紹介します。 品質観点1: エラーハンドリングの一貫性 なぜ重要か エンドポイントごとにエラーハンドリングがバラバラだと、以下の問題が起きます ユーザー体験の不整合：同じ「認証なし」なのに、401と500が混在 監視設計の困難：どのステータスコードを監視すべきか曖昧 障害対応の遅延：本番で「これは404か500か？」の切り分けに時間がかかる 「全エンドポイントで一貫したエラーマッピング」を担保する必要があります。 従来の検証方法と課題 実装後にテストコードをレビュー 手動テストで各エンドポイントのエラーレスポンスを確認 → 8エンドポイント × 3エラーパターン = 24ケースを人手で確認 → 実装後に気づいたときは既に手遅れ 品質を設計で担保する 実験では、以下を事前に定義しました： ## エラーマッピング（全エンドポイント共通） | エラー種別 | HTTPステータス | 内部エラー | |-----------|----------------|-----------| | 認証なし | 401 | JWT検証失敗 | | リソース不存在 | 404 | sql.ErrNoRows | | DB障害 | 500 | その他すべて | ## テスト要件 - 全8エンドポイントで401テストを実装 - 全8エンドポイントで404テストを実装 - 全8エンドポイントで500テストを実装 実験結果： Error Mapping Consistencyが31%→97%に改善 エラーハンドリングの一貫性は、品質の基本です。実装前に表として定義することで、レビュー工数を削減し、品質を担保できます。 品質観点2: 事後条件の検証 — 副作用を見逃さない なぜ重要か 書き込み操作（POST/PATCH/DELETE）では、対象レコードだけでなく、関連レコードや不変条件も変化します。 典型的な見落とし - POST /projectsでProjectは作成されるが、作成者がMemberに追加されない - DELETE /projectsでProjectは削除されるが、関連するTaskが残ってしまう - 不変条件の破壊（例：オーナーが0人のプロジェクトが存在する） 「対象レコード」「関連レコード」「不変条件」の3点セットで検証する必要があります。 従来の検証方法と課題 テストコードで「レスポンスが200 OK」だけ確認 → DBの状態は検証されていない → 本番で「データが不整合」のバグ報告 → レスポンスが正しくても、DB状態が壊れている 品質を設計で担保する 実験では、事後条件を3点セットで定義しました ## 事後条件（POST /projects） 以下の3点をIntegration Testで検証すること： 1. 対象レコード: Project行が1件作成される（status=active） 検証SQL: SELECT status FROM projects WHERE id = $1 2. 関連レコード: Member行が1件作成される（role=owner, user_id=作成者ID） 検証SQL: SELECT COUNT(*) FROM members WHERE project_id = $1 AND role = 'owner' 期待値: 1 3. レスポンス: Proto全フィールドが含まれる 実験結果： Post-Condition Coverageが22%→100%に改善（4.5倍） 書き込み操作の品質は「レスポンスが正しい」だけでは担保できません。DB状態を直接検証する設計が必要です。 品質観点3: スキーマの完全性 — フィールド欠落を防ぐ なぜ重要か APIレスポンスで「主要なフィールドは返るが、一部のフィールドが欠落」というバグは頻発します。 典型例 - Protoにstatusフィールドを追加したが、ハンドラで返し忘れ - フロントエンドでundefinedエラー - 本番リリース後に発覚 「Protoの全フィールドがレスポンスに含まれる」を担保する必要があります。 従来の検証方法と課題 テストで主要フィールド（id, name）だけ検証 → 追加したフィールドは検証されない → 「主要な機能は動く」が「追加機能が壊れている」 品質を設計で担保する 実験では、全フィールドを明示的に列挙しました ## Contract Test要件 GET /projects/:id のレスポンスで、以下の全フィールドが非ゼロ値で返ることを検証： - id (string) - name (string) - description (string) - status (enum: active/archived) - owner_id (string) - created_at (timestamp) - updated_at (timestamp) テストコード例： assert.NotEmpty(t, project.ID) assert.NotEmpty(t, project.Name) assert.NotEmpty(t, project.Status) // ... 全7フィールドを検証 実験結果： Schema Coverageが43%→100%に改善（2.3倍） フィールド欠落は、型チェックでは検出できません。全フィールドを明示的に検証する設計が必要です。 品質観点4: 認可の網羅性 — 権限チェック漏れを防ぐ なぜ重要か 認可のバグは、セキュリティインシデントに直結します。 典型例 - オーナーだけが実行できるDELETE /projects/:idを、メンバーも実行できてしまう - 本番で「他人のプロジェクトを削除できる」バグ報告 - → セキュリティインシデント 「全ロール × 全エンドポイントの組み合わせ」を検証する必要があります。 従来の検証方法と課題 「オーナーは実行できる」だけテスト → 「メンバーは実行できない」はテストされない → 正常系だけでは、セキュリティホールを防げない 品質を設計で担保する 実験では、全組み合わせを表で定義しました： ## Authorization Coverage: 100% 全8エンドポイント × 4ロール = 32パターンを検証 | エンドポイント | 認証なし | 非メンバー | メンバー | オーナー | |--------------|---------|----------|---------|---------| | GET /projects | 401 | 200 | 200 | 200 | | POST /projects | 401 | 201 | 201 | 201 | | PATCH /projects/:id | 401 | 403 | 403 | 200 | | DELETE /projects/:id | 401 | 403 | 403 | 204 | （以下、Task/Memberエンドポイントも同様） 実験結果： Authorization Coverageが48%→100%に改善（2.1倍） 認可の品質は「正常系が動く」だけでは担保できません。全組み合わせを明示的に検証する設計が必要です。 品質観点5: リスクベースのテスト優先度 なぜ重要か すべてのバグが同じ重要度ではありません。 - 金銭的損失につながるバグ（決済、課金） - セキュリティインシデントにつながるバグ（認可、認証） - ユーザー体験を大きく損なうバグ（データ削除、不整合） 「リスクの高い領域ほど、異常系テストを厚くする」必要があります。 品質を設計で担保する 実験では、リスク評価を異常系テストのパターン数に変換しました ## リスク評価とテスト戦略 ### 高リスク領域: DELETE /projects（データ削除） 異常系テスト5パターン必須： 1. 他人のプロジェクトを削除 → 403 2. 存在しないプロジェクトを削除 → 404 3. DB障害時の挙動 → 500 4. トランザクション途中でタイムアウト → ロールバック確認 5. 外部キー制約違反 → 適切なエラーメッセージ 「重大度：高」という抽象的な表現ではなく、具体的なテストパターン数で優先度を表現します。 品質観点6: 暗黙知の明示化 なぜ重要か 「ベストプラクティス」「適切に実装」といった抽象的な要求は、人によって解釈が異なります。 典型例 - 「削除は適切に実装」→ 物理削除を実装 - → 監査ログ要件を満たせない - → 「適切」の定義が曖昧だった 「なぜそうするのか」を明示する必要があります。 品質を設計で担保する 実験では、「〜しない理由」も記載しました ## 削除の実装方針 ソフトデリートを使用すること 理由： - 監査ログ要件：誰が、いつ削除したかの記録が必要 - 誤削除時の復旧：ユーザーからの「間違って消した」問い合わせに対応 - データ分析：削除されたプロジェ
- QA
- テスト
- 生成AI
実データx経営直下のスピードで価値を生む製造業AI研究開発 - リサーチエンジニア募集
こんにちは。キャディ株式会社でリサーチ組織の立ち上げを担っている福原です。 現在、私たちのResearchチームでは「Staff Research Engineer, 2D/3D Vision & Multimodal Understanding」のポジションを新たにオープンしています。これまでのテックブログでは、VLMの空間推論における限界や、3D CADモデルの幾何情報処理の難しさといった「私たちが直面している技術課題（What）」について発信してきました。 今回は視点を変えて、この挑戦的な技術領域で、どのようにして素早く価値を生み出し続ける研究開発が可能なのか、そしてなぜキャディでそれが実現できるのかについてお話しします。 製造業コンピュータビジョンの特異性 なぜキャディなのか：研究開発スピードの構造設計 技術ロードマップにおける3つの重点領域 3D形状の幾何学的・意味的理解の深化 2D図面と3D CADモデルの高度な対応付け マルチモーダル横断検索 求める人物像 製造業コンピュータビジョンの特異性 現在のコンピュータビジョン研究の主流は、RGB画像から3Dタスクを解くというアプローチです。自動運転、ロボティクス、AR/VRなど、多くの先端応用では、豊富なテクスチャ情報、照明の変化、背景のコンテキストといった視覚的手がかりを活用します。最新のVision-Language Model（VLM）も、このような「見た目の情報」を高度に理解することで、驚異的な性能を発揮しています。 しかし、製造業の現場では状況がまったく異なります。図面にも3D CADにも、色もテクスチャも背景も存在しません。そこにあるのは、ピュアな幾何学的情報のみです。 この違いは些細なものではありません。以前のテックブログでもお話ししましたが、言語処理タスクでは人間レベルに達するMLLMも、空間推論タスクでは60%の精度にすら届きません。建築図面のベンチマークでは、テキスト中心の質問応答では高精度を示す一方、空間認識では40〜55%程度という劇的な性能差が報告されています。既存の最先端モデルは、テクスチャなき幾何学の世界では「3歳児レベルの空間推論能力」に退化してしまうのです。 さらに、製造業では幾何学的特性に加えて物理的特性も同時に考慮する必要があります。ある形状が「見た目として正しい」だけでは不十分で、「製造可能か」「強度要件を満たすか」「加工コストは妥当か」といった物理的制約を満たさなければなりません。この点で、最近注目を集めているフィジカルAIの研究と技術的な親和性が高く、今後の研究トレンドとの接続も見えています。 つまり、製造業のコンピュータビジョンは、主流の研究結果をそのまま横に持ってきて使えるわけではない領域です。一見すると制約のように聞こえるかもしれませんが、逆に言えば独自性があるということでもあります。ビッグテックや巨大な外資企業が開発する汎用モデルは、確かにテキスト生成や一般的な画像認識では驚異的な性能を発揮しますが、テクスチャなき幾何学、製造ドメイン特有の制約、物理的特性といった領域では、汎用モデルをそのまま適用しても十分に機能しません。 これはリサーチエンジニアの視点では、既に確立された正解がないからこそ挑戦的で面白い技術領域であること、そして一瞬で成果が水泡に帰すリスクが、他の領域と比べて相対的に低いことを意味します。 製造業の実データは非公開のものが多く希少性が高いため、ビッグテックであっても容易に参入できる領域ではありません。加えて、扱う情報が様々なモダリティに跨る製造業の業務上の課題には学術的にもまだ確立された解決策が存在しないことも多く、データフォーマットや顧客が実現したい業務の個別性も高いという特徴があります。 汎用的なアプローチがそのまま正解にはならないからこそ、データや顧客の業務といったドメイン特化の深い知見と、製造業の実データを組み合わせた研究は、持続的な技術的Moat（競争優位性）を築きやすいテーマだと言えます。まだ解決すべき課題が山積しており、極めて挑戦的でエキサイティングな研究フロンティアなのです。これが、製造業AIの魅力です。 そして同時に、私たちを取り巻く環境は、かつてないスピードで変化しています。AI技術の進化は加速度的であり、新しい手法やモデルが日々登場しています。このような時代において、3年後、5年後に成果を出すというアプローチでは、市場や技術トレンドが大きく変わってしまう可能性があります。 私たちは、素早く価値を生み出し、検証し、次の価値創出につなげていく組織を目指しています。これは単なる目標ではなく、変化の激しい時代からの要請だと考えています。研究成果を小さく素早くリリースし、顧客のフィードバックを得て、次の研究テーマを磨き込んでいく。このサイクルを高速で回すことで、長期的な技術的優位性を築いていきます。 なぜキャディなのか：研究開発スピードの構造設計 では、なぜキャディにおいてこれほど高速な価値創出が可能なのでしょうか。 それは、単に「優秀な人材がいる」あるいは「リソースが潤沢である」という理由からではありません。研究開発のスピードを根本的に決定づけるのは、プロセスそのものをいかに速く回せる「構造」が整っているかです。 キャディの研究開発環境には、この構造を支える2つの大きな特徴があります。 1つ目は、自社でアプリケーションとデータプラットフォームを保有し、顧客の現場課題に深く入り込んでいることです。ビジネスメンバーが顧客と伴走し、見積、図面検証、製造プロセス管理といったコア業務の課題に日々向き合っています。この顧客との深い関係性が、机上の空論ではない「リアルな現場の知見」と「実データ」へのアクセスを可能にしています。 2つ目は、経営直下での研究開発の優先順位の高さです。キャディにおいて、独自のAI技術によるMoat構築は経営の最重要課題の一つです。そのため、CEO自らが研究開発の現場と連携し、技術検証や事業実装に向けたブロッカーを即断即決で取り除く体制が整っています。 これら2つの特徴により、私たちの環境では、一般的な研究組織が直面するボトルネックに対して、引けるレバー（選択肢）が圧倒的に多く、かつそれが機能する速度が速いのです。 例えば研究を進める上で壁にぶつかったとき、私たちには以下のような選択肢が即座に用意されます。 データが足りない → ビジネスチームと連携し、実際プロダクトを利用いただいている顧客に直接アプローチして新しいデータの整備をする ドメイン知識が足りない → 製造現場と直結したプロダクトを持つ強みを活かし、社内の専門家や実務者の知見へ即座にアクセスする 業界標準が曖昧で判断できない → 必要に応じて政府機関や業界団体と連携し、マクロな視点から課題を整理する リソースの壁に直面する → 経営層と連携し、課題と必要性を共有することで、人的リソースや計算資源の拡張の判断を仰ぐ ここで重要なのは、私たちが「誰とも関わらず研究だけに閉じこもれる温室」にいるわけではないということです。研究成果を事業価値に繋げるためには、PdMや他チームとの連携が不可欠であり、自ら主体的に動くことが求められます。しかし、そこには本質的ではない待ち時間や政治的な摩擦が極めて少なく、主体的に動くことで高速に研究開発のサイクルを回せる環境が存在します。 自分で動き、周囲を巻き込むことで、あらゆる問題が即座に解決していく。これは逆を言えば、「言い訳ができない環境」でもあります。研究成果を事業価値へとつなげ切る責任がある一方で、そのための障害は経営層や周囲のメンバーが全力で取り除いてくれます。 事業部と切り離された研究組織では、ともすれば大規模なリソース獲得の承認に数週間、社内部署の調整まで含めると数ヶ月といった遅延が発生しがちです。しかしキャディでは、そうした非本質的な遅延がほぼありません。リサーチエンジニアが本来向き合うべき技術検証と価値創出に、時間のほぼすべてを注ぎ込むことができる。この構造的な違いこそが、研究スピードを根本から変えているのです。 ここまで読んで、「それならアカデミアや大企業の研究所でも同じことができるのでは？」と思われるかもしれません。しかし、キャディの研究開発環境は独特のバランスの上に成り立っています。 アカデミアとの違いは、論文執筆は目的ではなく過程であり、実データでの検証と「顧客の課題解決」こそが最終的な価値基準である点です。 大企業研究所との違いは、意思決定のスピードです。事業実装までの判断が「週単位」で行われ、組織的なブロッカーは即座に解除されていきます。 スタートアップとの違いは、製造業という数兆円市場において、すでにグローバル4カ国に展開するSaaSプラットフォームと確固たる顧客基盤、実データを有している点です。 つまりキャディは、技術的な挑戦の深さ、スタートアップの意思決定スピード、事業基盤を持つ企業としての実装力という、通常はトレードオフになりがちな要素を併せ持つ、稀有な研究環境なのです。 技術ロードマップにおける3つの重点領域 このような環境で、私たちは具体的にどのような技術課題に挑んでいるのか。重点課題の中から、いくつかの領域をご紹介します。 3D形状の幾何学的・意味的理解の深化 まず一つ目の領域が、3D CADデータの純粋な幾何情報に対する深い理解です。 製造業のデータを扱うモデルには幾何形状や空間配置に関する高い認識力が求められますが、前述の通り既存の多くの基盤モデルはこの要件を満たせていません。私たちは、SaaSを通じて蓄積された大規模な3D CADデータを活用し、純粋な幾何情報から製造上意味を持つ特徴を認識できる表現を獲得する研究に取り組んでいます。 これは単なる形状の認識だけにとどまりません。3D CADの局所的な特徴（フィレット、ボス、リブ、穴など）を抽出し、「この穴はM6ボルトを通すためのもの」「このリブは強度を確保するためのもの」といった、設計者の意図や物理的な制約をモデルに推論させることが求められます。幾何学的な形状の認識だけでなく、強度や剛性、加工の実現可能性といった物理的特性も同時に扱う、フィジカルAI領域の先端的な挑戦でもあります。 このように3D形状に対する理解を深めることで、部品の3D CADモデルから加工難易度や適切な製造方法を自動推定することも可能になります。これにより、これまでベテランの暗黙知に依存していた見積業務の精度やスピードが飛躍的に向上し、SaaSプロダクトの強力なコア機能としての事業価値に直結します。 2D図面と3D CADモデルの高度な対応付け 二つ目の領域が、2D図面と3D CADモデルの高度な対応付けです。 多くの場合において、図面と3D CADは「部品単位」でしか紐付いておらず、それぞれが持つ詳細な情報の、システム上での密な関連付けは出来ていないのが現状です。 寸法などの詳細な情報は図面側に記載されていることが多い一方で、見積業務において、それらが3次元的にどう配置されているかの確認が必要になることが頻繁にあります。そのため、「図面上の情報を、3D CAD側の対応する適切なコンテキストに紐づけて処理をしたい」という実務的なニーズが存在します。 このようなプロセスを自動化するためには、2D図面と3D CADモデルの情報を相互に解釈し、高度に統合することが必須の要素技術となります。この技術の実現によって、図面と3D CADモデル間を横断したクロスチェックの効率化や、設計情報の整合性担保が可能になり、設計プロセスにおいて大きな事業価値を生み出します。 マルチモーダル横断検索 三つ目の領域が、あらゆる製造データをモダリティを超えて統合する検索・推論基盤の構築です。これには、3D CADや2D図面だけでなく、仕様書、過去の不具合報告、見積書といった自然言語のテキスト情報も含まれます。 最大の技術的挑戦は、純粋な幾何学的類似性（形状が似ている）と、セマンティックな類似性（用途や機能、関連する不具合の文脈が似ている）を両立させ、すべてのモダリティを統一された単一の埋め込み空間に整合させることです。 これが可能になれば、「この部品と類似した形状で、過去にどんな不具合があったか」「この図面形状を満たす最適な加工プロセスは何か」といった自然言語クエリでの高度な横断検索と推論が実現します。これまで個人の頭の中や各部署に散在していた暗黙知がシステム上で形式知化され、設計者や調達担当者の意思決定スピードを劇的に引き上げる事業価値をもたらします。 求める人物像 私たちは以下のような方と是非お話したいと考えています： VLM、3D Vision、マルチモーダル学習のいずれかで深い専門性を持つ方：トップ会議への投稿経験や、博士課程での研究実績など 「面白いモデルができた」で満足せず、事業価値まで執着できる方：研究と実装の間を往復しながら、顧客の課題解決に向き合える 研究スピードを上げるために、構造から変えることを厭わない方：AI活用、プロセス改善、組織設計にも興味がある 提供できる環境: 非本質的な摩擦を排し、研究成果を事業価値へと直結させる最速の社会実装環境 数兆円規模の巨大市場を動かし、独自の技術的Moat（競争優位性）を築く挑戦の場 変化の激しい時代において、最速のサイクルで価値を生み出し続けるアジャイルな組織 特許取得や学会発表をバックアップし、成果を社会へ還元するアウトプット支援 CADDiのリサーチエンジニアは、論文を書くだけでも、実装に専念するだけでもありません。仮説立案・モデル構築・SaaSへの組み込み・顧客検証までを一気通貫で担う「越境型」のポジションです。既存の基盤モデルが通用しない未踏の領域で、世界に先駆けて独自の技術的Moatを築き上げる。そして、その研究成果を圧倒的なスピードで数兆円規模の巨大産業へと実装していく。 あらゆる組織的摩擦が排除された「言い訳ができない」環境で、本質的な技術探求と事業価値創出のサイクルを最速で回し、自らの手でこのブレイクスルーを起こしたい。そう思われた方は、ぜひ一度カジュアルにお話ししましょう。エントリーを心よりお待ちしています。 募集要項: Staff Research Engineer, 2D/3D Vision & Multimodal Understanding カジュアル面談: 応募フォーム
- 生成AI
- コンピュータビジョン
クラウドネイティブ会議に協賛・登壇しました
こんにちは！Core SRE の 織田 英吾です。 キャディはクラウドネイティブ会議にブーススポンサーとして協賛させていただきました。 この記事では2日間にわたるイベント期間中のブースの様子や聴講したセッションの感想をレポートします。 ブース紹介 まずは、キャディのブースについて紹介します！ ブースでは、 私たちが取り組む製造業にまつわる課題を知っていただくための「30秒図面捜索チャレンジ」を実施したり、おすすめの Claude Code Skills を共有するボードを用意しました。 以下が実際に寄っていただいた皆さんに記載いただいたボードの写真です。おすすめ Claude Code Skills や使っている機能などをたくさん教えていただきました。Skillsを自作されている方も多くいて、コードのレビューやドキュメント作成が特に多かった印象です。私が知らなかったものも多くあり、試してみようかと思いました。 私たちが提供している「製造業AIデータプラットフォームCADDi」のアプリケーションである「製造業データ活用クラウドCADDi Drawer」のデモも行いました。 デモを通して、製造業出身者や所属の方以外にも、製造業が抱える課題に共感していただくことができました。私自身、キャディが取り組んでいることの重要さを再認識することができた機会になりました。 名古屋での開催ということもあり、製造業出身や所属の方も多く、現場の声やペインポイントを聞くことができ、私が学ばせていただく機会にもなり、とてもいい経験をすることができました。 イベント期間中、キャディのブースに立ち寄ってくださった皆さん、本当にありがとうございました！ 聴講したセッションの感想 次に、私や他のメンバーが聴講させていただいたセッションの感想を簡潔にまとめます。 「100マイクロサービスのTerraform/Kubernetes管理地獄から抜け出すためのAI活用術」 株式会社LegalOn Technologies の Ishigaki さんと Wada さんによる発表です。 本セッションでは、マイクロサービスの増加に伴って Kubernetes / Terraform 管理や設定変更、レビュー対応が大きな運用負荷になるという課題が紹介されました。その解決策として、定型的な変更作業は仕様化・ツール化し、AIエージェントを活用してサービス単位で並列に展開するアプローチが示されており、とても参考になりました。 特に印象的だったのは、AI にすべてを任せるのではなく、社内ルールやガイドラインを AI が参照しやすい形に整備し、人間が最終判断を担う設計にしていた点です。これにより、大量の PR 作成やレビュー支援、移行作業を効率化しながら、運用品質を保つ工夫がなされていました。 AI 活用の前提として、業務プロセスやナレッジを構造化しておくことの重要性を感じるセッションでした。（Core SRE 織田） 登壇資料: https://speakerdeck.com/markie1009/kubernetesguan-li-di-yu-karaba-kechu-sutamenoaihuo-yong-shu 「そのSLO99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜」 株式会社TopotalのVTRyoさんによる発表を聴講しました。以前、SREKaigiでもVTRyoさんの発表を聞いたことがあり、とても参考になったので今回も楽しみにしていました。 本発表では、SREチームはDevチームのEnablingを突き詰めていくと、横断で複数のサービスを見ていくことが増えていくことで、運用しているサービスで何が起きているのか分からなくなる可能性が高くなりやすいと話されてました。実際に、VTRyoさんは自分たちはSREとしてサービスに価値を生み出していないのではないかと葛藤が生じたそうです。 そこで紹介されていたのが Product-Focused Reliability for SRE （PER）という考え方でした。自分は初めて聞いたのですが、SREチームが限られたリソースを有効活用するために、ビジネスやユーザーにとって最も重要なことに焦点を当て、優先順位をつけて活動することだそうです。 確かに、従来のSREはインフラやサービスそのものの安定稼働に責務を持つため、自然とDevはアプリケーション、SREはインフラという得意領域で境界が分かれてしまいやすいです。 PERの考え方は、SREの関心ごとをサービスからプロダクトの重要機能に移し、プロダクト中心にSLOを考えていくため、よりユーザーやビジネスの理解が重要になってきます。自分自身、SREが信頼性という指標を追っているのはユーザーの満足度とビジネスの成功度を上げるためだと思っているので、PERの考え方はとてもしっくりきました。 また、SREは日々のアラート対応に追われがちではありますが、それは本当にユーザーの離脱や解約につながっているのか？実は過剰な信頼性を追っているだけで、根本的な問題は機能不足なのではないか？、本セッションの問いとして投げかけられていた「そのSLO99.9%は本当に必要なのか」は定期的にSLOを見直す際に立ち返りたい問いだなと思いました。（Drawer SRE 松嶋） 登壇資料：https://speakerdeck.com/vtryo/is-that-99-dot-9-percent-slo-really-necessary-design-philosophy-of-shared-responsibility-through-prioritized-slos 登壇レポート キャディからCore SREチームリーダーの小林明斗が登壇しました。 セッション名：生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践 概要：生成AIによりコードやIaCの変更量が増える中、人手のレビューやチェックリストだけでは信頼性リスクを見落としやすくなっています。本セッションで は、組織ポリシーのうち静的に評価できる項目をPolicy as CodeとしてCIや実環境に組み込み、人の認知に依存しすぎず信頼性を維持する設計を紹介し、ConftestやKyvernoの実装例を交え、誤検知対応、ポリシー強度、既存リソース是正など、形骸化しないガードレール運用の工夫を共有しました。 開発組織の変遷や SRE の歩みから入り Policy as Code の紹介、実装方法の共有がされていました。私はまだ入社3か月目なのもあり、キャディの私でも学べるセッションでした。 会場の席はほぼ埋まり、立ち見がでるほどの盛況ぶりで約100名の方が参加されていました！ SNSでも「Policy as Code が気になっている」、「PRC のレビューが大変なのわかる」、「Policy 違反1,684件すべて修正完了はすごい」などたくさんの反響をいただきました。キャディから登壇者を出せてとても良かったです。 Policy 違反の Report に「Policy の詳細や OK/NG の例が記載された wiki」へのリンクを入れているらしい。これを見ることで Policy 違反が発生した時の開発者側での修正をやりやすくしてる感じっぽい。よさそう。#cloudnativekaigi #cloudnativekaigi_b— こたつ&&みかん (@kota2and3kan) 2026年5月15日 x.com 1684件すべて修正完了すごすぎる#cloudnativekaigi #cloudnativekaigi_b— yuki / ほにゃにゃ (@honyanyas) 2026年5月15日 x.com うおー、ポリシーに対するテストコード書けるのめっちゃいい。#cloudnativekaigi #cloudnativekaigi_b— たか (@_nogtk_) 2026年5月15日 x.com 登壇資料: speakerdeck.com 終わりに ブースへの来場・セッション聴講・懇親会と充実した2日間でした。クラウドネイティブな技術の進化は非常に速いですが、今回学んだ知見を業務に活かしていきたいと思います。 スピーカーの皆さん、参加者の皆さん、クラウドネイティブ会議の運営の皆さん、素晴らしいイベントをありがとうございました。今後もキャディは、技術的な挑戦や課題解決の知見を発信し、エンジニアコミュニティへの貢献を続けていきます。今後のイベントでもお会いできるのを楽しみにしています！
- SRE
- Kubernetes
- Terraform
- 生成AI
- イベント
使われないユビキタス言語はなぜ生まれるのか ── 実践から学んだ7つのアンチパターン
はじめに こんにちは。キャディ株式会社でソフトウェアエンジニアとして製造業AI見積クラウドCADDi Quoteの開発を担当している松田です。 私たちのチームでは、新機能の開発時など、プロダクトに新しい概念を導入する際には、開発者のみならずPdMやQAといった他職種を交えて議論し、ユビキタス言語を定義しています。 ユビキタス言語とは、ドメイン駆動設計においてビジネスと設計の橋渡しをする共通言語です。ドメインエキスパートとエンジニアが、会話・コード・ドキュメントに渡って同じ言葉を使うことで、ビジネスと設計の間の翻訳コストの発生を防ぐことが目的です。 出典：エリック・エヴァンス著、今関剛監訳、和智右桂、牧野祐子訳『エリック・エヴァンスのドメイン駆動設計』翔泳社(2011) p.34より一部改変して筆者作成 私たちがこれまでにユビキタス言語として定義した用語の多くは、チームの業務において実際に用いられ、生きた言葉として価値を発揮しています。 その一方で、定義した用語が実際の議論やドキュメントの中でうまく定着せず、形骸化してしまうケースも経験しています。使われないユビキタス言語はなぜ生まれてしまうのでしょうか？ この記事では、こうした経験をもとに、使われないユビキタス言語を生んでしまう7つのアンチパターンを紹介します。これらのアンチパターンは、「誰を巻き込むか」「どう考えるか」「定義後の運用」の3つの観点にまたがりますが、網羅的なものではなく、私が実際の運用の中で失敗や悩みを抱えたポイントに重点を置いています。ユビキタス言語という概念は知っているが、実践の中でつまずきを感じている方に読んでいただければと思います。 はじめに アンチパターン1: エンジニアだけで決めてしまう 問題 なぜ起きるか どうすればいいか アンチパターン2: ドメインエキスパートという概念に固執してしまう 問題 なぜ起きるか どうすればいいか アンチパターン3: ドメインエキスパートの言葉を無批判に受け入れてしまう 問題 なぜ起きるか どうすればいいか アンチパターン4: 英語名をAIに相談せずに決めてしまう 問題 どうすればいいか アンチパターン5: 理詰めで考えてしまう 問題 なぜ起きるか どうすればいいか アンチパターン6: 声に出した時の自然さを軽視してしまう 問題 なぜ起きるか どうすればいいか アンチパターン7: ユビキタス言語辞書の作成が目的化してしまう 問題 なぜ起きるか どうすればいいか おわりに アンチパターン1: エンジニアだけで決めてしまう 問題 ユビキタス言語の定義からして当たり前ですが、エンジニアだけで議論するのはアンチパターンです。私たちのチームではエンジニアもお客様を訪問したり、セールス、カスタマーサクセス、PdMといった他職種のお客様訪問レポートを読むなどして顧客理解に努めていますが、顧客理解という点においてPdMにはかないません。エンジニアだけで議論すると、PdMなどの他職種が持つ貴重な知見を設計に反映する機会を失うことになります。また、エンジニアはどうしても実装をイメージしながら議論してしまうので、用語が実装に引きずられがちにもなります。 この場合、PdMからするとユビキタス言語の存在自体を認識していないことになるので、エンジニアだけがユビキタス言語を使い、PdMは別の言葉でエンジニアと会話する状態になるでしょう。 なぜ起きるか 背景には、いくつかの思い込みがあります。 ひとつは、遠慮です。PdMなどの他職種は忙しいので、設計寄りの議論に巻き込むのは申し訳ないという気遣いが働くことがあります。 また、説明コスト回避の心理も働きます。ユビキタス言語という概念を他職種に説明しながら議論するのを面倒に感じ、エンジニアだけで決めてしまいたくなることがあります。 どうすればいいか タイムボックスを区切った上で、PdMなどの開発者以外のメンバーを集め、効率よく議論しましょう。 そのために有効な手法がイベントストーミングです。イベントストーミングは、複雑な業務ドメインを参加者のコラボレーションにより探索するワークショップ形式の手法です。参加者が付箋を出し合い、それらを構造化する作業を通じて、ドメインの全体像が見えてきます。 参加者がそれぞれの理解に基づいて付箋を貼る中で、同じ概念が人によって別の言葉で表現されている状況が可視化されます。メンバー間の言葉のずれを発見し、用語の統一を図る中で、自然とユビキタス言語が定義されていきます。 イベントストーミングの良いところは、ドメイン駆動設計やユビキタス言語といった概念の理解が薄いメンバーであっても、ファシリテーターの指示をステップバイステップでこなしながらワークに参加できるところです。ファシリテーターにとっても、ワークの進め方を一度身につけてしまえば、参加者に対する説明コストはそれほどかかりません。 また、イベントストーミングを終えると、ユビキタス言語だけでなく、要件やドメインモデルの全体像も見えてきます。要件に関する認識合わせの中で自然とユビキタス言語も整理される形となるため、時間効率も良いと言えます。 イベントストーミングについては、キャディのTech Blogでも紹介されていますので、ぜひご覧ください。 caddi.tech アンチパターン2: ドメインエキスパートという概念に固執してしまう アンチパターン1はエンジニアだけで閉じてしまうという問題でした。これから議論するのはその逆方向の問題です。理想のドメインエキスパートがいないなら、ユビキタス言語の議論をしても意味がないという心理に陥るケースです。 問題 ドメイン駆動設計では、ドメインエキスパートとの協働がユビキタス言語の前提とされています。 ドメインエキスパートとは誰なのでしょうか？ 通常は、そのソフトウェアを利用するユーザーとなります。私たちキャディで言えば、製造業の現場で働く方々、とりわけ、業務全体を俯瞰し、業務プロセスの設計や変革をリードしている方々です。 そうすると、ユビキタス言語を定義する際には、実際のお客様を会議にお招きし、議論をする必要があるのでしょうか？ 多くの場合、それは非現実的です。 このような場合に、ドメインエキスパートを呼べないのであれば、ユビキタス言語の定義をしても意味がないのでは？ という議論が発生したり、悩みを抱えてしまうことがあります。これが2つめのアンチパターンです。 なぜ起きるか EvansのDDD本では、ドメインエキスパートと開発者が継続的に対話しながらユビキタス言語を洗練させていく様子が描かれています。しかし現実には、ドメインエキスパートは自身の担当業務で多忙であり、ソフトウェア開発のためだけに継続的な時間を確保してもらうのは困難です。 特にSaaSの場合、この難しさはより顕著です。SaaSにおいてサービス提供者と顧客は一対多の関係にあり、顧客の要望がすべてプロダクトに反映されるわけではありません。提示した意見がそのままプロダクトに反映されるならまだしも、ただ設計を洗練させるためだけに貴重な時間を割くのは、ほとんどのお客様にとって難しいでしょう。 どうすればいいか ドメインエキスパートという概念に固執するのはやめ、現実的な妥協をしましょう。 現時点で顧客の言葉遣いをよく把握している社内メンバーを探し、その人を知識の源泉として活用しましょう。私たちのチームの場合、幅広い顧客と日常的に接し、業界全体の課題を俯瞰的に捉えているPdMがドメインエキスパート役として最適なことが多いと考えています。教科書通りのドメインエキスパートを求めるのではなく、現実的にアクセスできる範囲内でドメイン知識を吸収しましょう。 アンチパターン3: ドメインエキスパートの言葉を無批判に受け入れてしまう 問題 ユビキタス言語を議論する際、PdMに「お客様はこれを何と呼んでるんですか？」と質問することがあります。ここで、議論に疲れていると、お客様が使っている言葉をそのまま採用したくなってしまう瞬間があります。 しかし、お客様の個別の業務の文脈においては意味が通じる言葉であっても、私たちが作ろうとするプロダクトの文脈にそのまま持ち込むと具体性が高すぎたり、逆に意味が曖昧であったりすることがあります。 私たちのチームでも、製造業の調達業務においてサプライヤー企業からバイヤー企業に対して提出されるさまざまな種類の見積資料をどう呼ぶかを議論した際に、この点が問題となりました。PdMに、リリース後最初の想定ユーザーとなるお客様がその資料を何と呼んでいるのかを質問したところ、お客様は単に「見積書」と呼んでいるとのことでした。そのお客様にとっては、さまざまな種類の見積資料のうち、「見積書」と言えばこれを指す、というのが暗黙の合意となっていたのでしょう。しかし、さまざまな企業のお客様を対象とするSaaSプロダクトの文脈においては、「見積書」という表現は曖昧であり、私たちが開発している機能のスコープとは全く性質の異なる資料までもがそこに含まれてしまう懸念がありました。 結局、私たちは、お客様が実際にそう呼んでいるかではなく、業務慣習の異なる他のお客様や、開発者も含めて誤解が生じないことを優先し、資料の内容が明確に分かる別の用語を定義することになりました。複数企業のお客様を対象とするプロダクトとして、曖昧性を避けることを優先した選択でした。 なぜ起きるか ユビキタス言語という概念を、ユーザーや非エンジニアが用いる言葉をそのまま使用して開発することだと思い込んでいることが原因です。 実際には、ユビキタス言語は、ドメインエキスパートと開発者の双方が批判的意見を提示しながら洗練させるものです。このことは、Evans本でも以下のように明記されています。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に意義を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 出典：エリック・エヴァンス著、今関剛監訳、和智右桂、牧野祐子訳『エリック・エヴァンスのドメイン駆動設計』翔泳社(2011) p.27 どうすればいいか ドメインエキスパートからのインプットを、ソフトウェア設計上の概念として利用可能な抽象度に洗練させる責任は開発者にあることを認識しましょう。ドメインエキスパートが提示した用語を使って設計やコーディングを行うイメージが湧くかを常に想像し、違和感があれば対案を提示しましょう。 開発者側から対案を提示する際には、その対案に対して開発者以外の参加者が納得感を持っているかどうかにも目を配りましょう。往々にして発生するのは、議論の場ではユビキタス言語が合意されたものの、結局、開発者以外のメンバーは独自の用語を使い続けているという状況です。言葉が揃っていないことで苦労するのは結局のところ開発者なので、開発者以外のメンバーも含めてちゃんと納得感を持って使ってもらえそうかには注意を払う必要があります。 アンチパターン4: 英語名をAIに相談せずに決めてしまう 問題 DDD本を執筆した当時のEric Evansも想像していなかったでしょうが、現代のソフトウェア開発では、ドメインエキスパートや開発者と並んで、AIもユビキタス言語の策定の参加者となり得ます。 とりわけAIが活躍するのは、英語名の提案です。日本語圏でドメイン駆動設計を実践する際、現実的な妥協として、ユビキタス言語は日英併記で定義し、会話やドキュメントといった自然言語では日本語名を、ソースコードでは英語名を用いるといった手法が取られることが多いと思います。 日本語話者が英語名を定義する際、日本語を直訳したような英語名となり、英語として存在しない、あるいはニュアンスが意図と異なる表現になってしまうことがあります。私がチームの一員として関わった例で言えば、生成AIの登場以前の話ではありますが、「受注」という概念の英語名を Received order としてしまったことがありました。軽くインターネット検索すると分かりますが、このような表現は英語として通常用いられないようです。 また、ボキャブラリーが貧弱であるがゆえに FooData や BarInformation といった曖昧で意味の薄い名称となってしまうこともあります。 英語名の定義の際に以上のような問題を回避するには、AIを活用することが有効です。 どうすればいいか 英語名に自信がない場合はAIに提案してもらいましょう。 英語名をAIに考えてもらう上で重要なのは、日本語名を単語ベースで渡して翻訳させるのではなく、日本語名とその意味合いの説明文（加えて、既に決まっている英語名があればそれも）を一覧化し、全体を見せた上で日本語名に対応する英語名を提案させることです。こうすることで、単なる直訳ではなく、用語のニュアンスや用語間の関連性も踏まえた上での回答が期待できます。 また、複数の候補を提案させ、それぞれについて、ニュアンスや英語としての自然さを解説させた上で、どれを採用するか人間が選ぶべきです。決定する際は、インターネット検索により、その単語が実社会で意図したとおりのニュアンスで使用されているかを確認するのも忘れないようにしましょう。これにより、AIが提案した英語名をそのまま採用したら、実は日本語名とニュアンスがずれていた、といった事故を防ぐことができます。 アンチパターン5: 理詰めで考えてしまう ここまで取り上げてきたアンチパターンは、誰を議論に巻き込むかという問題でした。続く2つのアンチパターンは視点を変え、どう考えるかという軸から、使われない用語が生まれる構造を見ていきます。 問題 ユビキタス言語を定義する際、論理的な整合性を追い求めるあまり、聞いた瞬間に意味が伝わりにくい用語が生まれることがあります。このような用語は、議論の参加者が最初に提示した用語がどれもぴたりとはまらず、ああでもないこうでもないと色々な別案を出していくうちに発生します。 用語の意味を論理的に説明して理解できるのであれば、一見問題のないように見えます。しかし、長々と説明しないと意味が伝わらない用語は、会話の中で使うたびに説明のコストが発生します。結果として、メンバーは無意識のうちにその用語を避けるようになり、日常の議論には登場しない「公式用語」として辞書に残るだけの形骸化したユビキタス言語になっていきます。 なぜ起きるか ドメインエキスパートの言葉遣いを観察することから出発するのではなく、演繹的に用語を定義しようとしているのが原因です。 母国語について考えれば分かるように、自然言語は、演繹的に定義されたものではありません。そうではなく、ある言葉が使われているという事実が先にあり、そこから帰納的に文法や言葉の意味が定義されているわけです。 自然言語のこういった性質を踏まえれば、ユビキタス言語を定義する際も、ある言葉が自然に使われているという事実を重視すべきです。しかしながら、自然に使われている用語を設計にふさわしい抽象度に洗練させていく中で、理論先行に陥ってしまうことがあります。 どうすればいいか 前提として、論理的に用語を定義することを全否定するわけではありません。ソフトウェアは人工的な創造物であり、現実世界に対応物のない抽象的な概念を扱わざるをえない場合があります。自然に使われている業務の言葉だけでは表現できず、抽象的な論理から出発して命名せざるを得ない場面は一定あります。 ですが、まず優先すべきは、実際の会話の中で自然に飛び交っている言葉から出発することです。ドメインエキスパートやPdMが議論の中で無意識にある言葉を使っているなら、その言葉が直感的に選ばれたことには何かしらの理由があります。理詰めで独自の用語を作り出す前に、ある言葉が直感的に選ば
- ドメイン駆動設計
- 生成AI
RAGの評価データセットをユーザーと一緒に作って、思った以上に良かった
機械学習エンジニアの竹本です。普段は、製造業の膨大なドキュメントを対象にしたRetrieval-Augmented Generation（RAG）の検証に取り組んでおり、その一環として社内検証向けのベンチマークデータセットを作成しました。同じ課題を抱えるエンジニアの方の参考になればと思い、本記事を書きました。 TL;DR 作りたい。でも動き出せなかった 当時の思い込みと、今の自分からの答え合わせ 1. LLM-as-a-Judgeに頼るしかないと思っていた 当時の状況 データセットを作ってみると 2. データセットを作れるのか？ そしてCSやユーザーに頼っていいのか？ 当時の状況 CSに相談してみると 3. 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の状況 データセットを作ったら検証速度が5倍に向上 作る過程で得られた想定外の価値 まとめ TL;DR 最初は、コストや体制の壁があり作成に動き出せなかった 制約を取っ払って考え、「作りたい」と声に出したら、動き出せた ベンチマークデータセットを作って、検証スピードが約5倍になった 作る過程そのものも、ユーザー理解を深めるきっかけになった 作りたい。でも動き出せなかった RAGの検証を進める中で、製造業の深いドメイン知識や個社特有の知識が求められる領域では、LLMによる評価だけでは精度を正しく判断しきれないと感じるようになりました。評価用のベンチマークデータセットが必要だと分かっていたものの、作成にかかる時間的コストの大きさと、自チームやアノテーションチームだけでは作りきれないという課題から、なかなか動き出せずにいました。 転機となったのは、チーム全員で実施した「100本ノック」でした。3日間で一人100個ずつアイデアをスプレッドシートに書き出し、不確実性やコストといった制約をいったんすべて取り払って、「本当は何をすべきか」を純粋に考え抜く取り組みです。その中で、「ドメインエキスパートと一緒にデータセットを作りたい」と提案しました。議論してみると、LLM-as-a-Judgeだけでは正しく評価しきれないという課題感と、データセットがあれば検証の質とスピードが大きく変わるという期待は、チーム内のエンジニアやPdMにも共通のものでした。コストやタイムラインといった制約がある中で、優先度が上がりきっていなかっただけでした。制約を外して考えたことでその必要性が共通の課題として顕在化し、チームとして取り組む合意が得られ、データセット作成が動き出しました。 そして実際に作成してみると、想定以上の価値がありました。 ここからは、当時抱えていた以下3つの思い込みを1つずつ答え合わせをしていきます。 LLM-as-a-Judgeに頼るしかないと思っていた データセットを作れるのか？ そしてカスタマーサクセス（CS）やユーザーに頼っていいのか？ 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の思い込みと、今の自分からの答え合わせ 1. LLM-as-a-Judgeに頼るしかないと思っていた 当時の状況 当時は、プロンプトチューニングや評価基準の調整を行い、LLM-as-a-Judgeだけに頼った定量評価をしていました。一定の指標として数値は出せていたものの、そのスコアをどれだけ信頼してよいのかという違和感は常にありました。実際、評価軸は「謝罪せずに回答しているか」「クエリと関連しているか」「直接的に答えているか」といった回答品質に限定した比較的表層的なものに寄りがちで、プロダクトの精度が上がるにつれて、それらの指標では差がつきにくくなり、改善の効果をうまく捉えられなくなっていきました。具体的には、定量評価では有意な差が出ていても、定性評価をしてみると実質的には同等だったり、逆に定量評価では差がないのに定性評価では明らかな改善が見られるといった乖離がしばしば発生していました。 そもそも、製造業で扱うドキュメント（不具合報告書や製品仕様書など）は、専門用語や文書構造がテナント・部署ごとに大きく異なり、読み解くには業務固有の背景知識も求められるなど、非常に専門性の高い領域です。長年蓄積された情報同士の関係も複雑で、単純なテキスト理解だけでは評価しきれません。こうした背景もあり、ドメイン知識やテナント固有の文脈を持たないLLMはもちろん、エンジニアによる定性評価も、どうしても表面的な確認にとどまりがちでした。それでも他に現実的な手段がなく、LLM-as-a-Judgeだけに頼らざるを得ない、というのが当時の実態でした。 データセットを作ってみると 実際にデータセットを作成してみると、この前提は大きく変わりました。 製造業のドメイン知識やテナント固有の知識を織り込んだGround Truth（詳細は割愛しますが、検索されるべきドキュメントとあるべき回答の2種類）を用意できたことで、それを基準にした評価が可能になりました。これまでのような表層的な評価では見えなかった改善の差分も、Ground Truthとの比較によって定量的に捉えられるようになり、評価の解像度が一段上がった感覚があります。また、定性評価においても、「なぜこのケースはうまくいったのか／いかなかったのか」を考える際の拠り所ができ、分析の質も大きく変わりました。 2. データセットを作れるのか？ そしてCSやユーザーに頼っていいのか？ 当時の状況 自チームやアノテーションチームだけではデータセットを作れないと認識していました。製造業のドメイン知識に加え、テナントごとの固有知識まで含めて網羅する必要がありましたが、その両方を十分に備えた人材は身近にいませんでした。さらに、対象となるコーパスはテナントごとに数万から数百万規模のドキュメントファイルに及び、その量も大きな課題でした。データセットを作りたいという思いはあったものの、具体的な進め方が見えていませんでした。 CSに相談してみると そうした中でCSに相談し、どのように進めればデータセットを作成できるかを一緒に検討しました。その結果、CSがユーザーにヒアリングの場を打診し、ユーザーと一緒にミーティングを行いながらデータセットを作っていく進め方を提案してくださいました。 実際のミーティングでは、事前に用意したデータセット設計をもとに、欲しい情報を一つひとつヒアリングしながら作業を進めました。ただ、1つのテナントに格納されているドキュメントは膨大で、様々な部門の何年もの歴史の中で蓄積されたものです。そのテナントのユーザーでさえ、どのような回答があるべきかは簡単には分かりません。それを一緒に揃えていくには、やはり時間も手間もかかりました。 それでも、CSはユーザー体験の向上のために、ユーザーは業務改善につながるならばと、それぞれ積極的に関わってくれました。そうした関わりを通じて、みんなが同じ方向を向いていると分かったことは嬉しい驚きでした。 3. 時間も工数もかかるのに、そこまでしてやる価値があるのか 当時の状況 当時は、データセットの作成に多くの時間と工数がかかることが明らかであり、さらに不確実性も高く、そもそも実際に作りきれるのかどうかさえ分からない状況でした。そのため、かけたコストに見合う価値が得られるのかを判断できず、取り組むべきかどうかに迷いがありました。 データセットを作ったら検証速度が5倍に向上 実際にデータセットを作ってみると、その価値は想像以上に大きいものでした。Ground Truthが存在することで成功と失敗の判断が明確になり、定性評価において悩んだり迷ったりする場面が大幅に減りました。 例えば、Ingestion改善の検証では、以前は数十〜数百件の検索結果と回答結果を一件ずつ目視で確認した上で評価・示唆出し・次の改善策の検討を行う必要があり、全体で約1週間かかっていました。データセット導入後は、定量評価で全体の傾向を把握した上で深掘りすべきケースを絞り込めるようになり、一件ずつ精査する作業負担が大きく減ったことで、この一連の検証サイクルが約1日で回せるようになりました。 また、RAGについては新しい手法が次々と登場しますが、信頼できるデータセットがあることで、それらの手法の効果を迅速に検証・比較できるようになり、試行錯誤のハードルが大きく下がりました。 作る過程で得られた想定外の価値 さらに、データセットを作る過程そのものからも、想定外の価値が得られました。過去の会話履歴を網羅的に確認し、データセットに用いるクエリを幅広く抽出・選定する中で、ユーザーがどのような情報を求め、どのようなクエリとして入力しているのかを観察したことで、ユーザー理解が深まりました。また、ユーザーと一緒にデータセットを作成する過程で、参照されるべきドキュメントを具体的に把握できるようになり、実際のユーザークエリから適切なドキュメントにたどり着くまでの検索の流れをより深く理解できました。加えて、ベンチマークの評価指標についてチーム内で議論を重ねる中で、自分たちのプロダクトが本来提供すべき価値が何かも明確になっていきました。 まとめ データセットの作成には多くの時間と工数がかかりますが、それでも得られる価値は当初の想定を大きく上回るものでした。このすべてのスタート地点は、制約を取っ払って考えたことと、「作りたい」と言葉にして伝えたことでした。 今回は最初の一歩として、優先度の高いクエリを選定してデータセットを作成しました。これだけでも検証の質とスピードは大きく変わりましたが、さらに質を維持しながら作成工数を減らし、クエリのバラエティや量を拡充していきたいと考えています。
- RAG
- 生成AI
- 機械学習
100件超のテストケースが必要と分かってしまったときに考えたAI時代の効率化
最近はデータ基盤をこねこねしているData Fabric部の 伊藤 (@amaya382) です。今回はテストケースをAIに量産させた話を題材に、AI時代の効率化で考えていたことをお届けします。 参画していたプロジェクトが順調に進み、いよいよ大詰めが見えた辺りで2人でシステムテストを整理していたんです。影響範囲が大きい機能だったので覚悟はしていたのですが、数えてみると観点は数十、テスト項目は100を超え、手順に至っては数百ステップ。ついでにリリース日も決まっていました。 結論から言うと、テストケース作成の大部分をAIに任せることで無事リリースに至りました。振り返ると「とりあえず全部AIに任せる」では到底無理で、効いたのはボトルネックとの見極めとAIが品質を保って自走できる環境を丁寧に整えるアプローチでした。 本稿ではそのAIを自走させるための "仕込み" にフォーカスします。特定のツールや手法のハウツーではなく、AI時代における効率化の考え方の一事例として読んでいただけると嬉しいです。 背景：大量のテスト観点を前にして 自動化までの流れ 1. コンテキストの準備 2. 初期ケースの手動作成 3. AIとの対話的なケース作成 4. テストケース作成のSkill化 — 再現性を手に入れる うまくいったこと AI-friendly な環境がもたらした相乗効果 テスト環境やパターンコンテキストの活用 Skill化による再現性 残ったボトルネックと次にやりたいこと A. コンテキストすら準備してもらう B. 人間はスケールしない C. テストファーストへの組み込み おわりに 先日、弊社小森による 『YAML×AIで脱Excel地獄！テストの本質に思考を集中させよう』という記事の末尾で予告されていたものにあたります。 背景：大量のテスト観点を前にして 膨大なケースをどうしようかと考え始めたちょうどその頃、『YAML×AIで脱Excel地獄！テストの本質に思考を集中させよう』 で紹介されたYAML形式 + testdocツールが使える見込み、つまりテキストベースでテストケースを管理できる見込みが立ち始めていたところでした。YAMLでテストケースを書ければ、構造化されたテキストとしてGitで管理でき、PRベースのレビューもできる。これ自体はとても良い環境です。 とはいえ数百の手順を手で書きたいわけもなく… リリース日は計画済みで、早く終わりの見込みを立てて落ち着きたいという状態でした 😓 そこでまず考えたのが「このテキストベースでテストケースを書ける環境をどうやって活かすか」です。まずはテキストベースなのでAIへの入出力がダイレクトかつ効率的に使えそう、しかも構造化されたフォーマットなのでAIが生成するテストケースの品質も安定しやすいはずというところから、筆者らは大規模なテストケース作成をAIに任せてみることにしました。 自動化までの流れ 件数が多いことは最初からわかっていたので、どうしたら再現性の高い形に落とし込んで大部分を効率的に圧縮できるか、端的に言えば いかに楽をできるか を考えていました。具体的には、自走させるためのコンテキスト準備とClaude Skill化 1 による再現性で一気に進められるのではという仮説を立てていました。 大まかな流れは以下の通りです: 自動化までのフロー 前半のコンテキストの準備は地道な作業ですが、ここを丁寧にやることが後半でAIが自走できるかどうかの分かれ道になりました。順に説明していきます。 1. コンテキストの準備 AIにテストケースを書かせるためには、人間が書くときと同じように十分なコンテキスト (前提知識) が必要です。具体的には以下のようなものを整理しました。 テスト環境の情報: テスト環境の構成やテスト用アカウント、テストデータ情報 テストパターンのマトリックス (決定表): 条件の組み合わせで挙動が変わることがあるため、そのパターンを表形式で整理したもの 要件定義書: 画面や機能単位で階層化して書かれていたため、ほぼそのまま入力に利用 画面のスクリーンショット: 既存の仕様に明文化しきれていなかったUIに関する情報を補足するため 特に重要だったのがテストパターンのマトリックスです。今回のプロジェクトでは、データと条件の組み合わせに応じた結果が特に重要であり、その組み合わせパターンが膨大でした。このマトリックスをCSVとして整理しておくことで、AIがテストケースの期待結果を組み立てる際の判断根拠として参照できるようにしました。 表1: テストパターン情報のイメージ 図面-01 図面-02 図面-03 ... ユーザー01 閲覧可 閲覧可 閲覧可 ... ユーザー02 閲覧可 閲覧不可 閲覧可 ... ユーザー03 閲覧可 閲覧不可 閲覧不可 ... ... ... ... ... ... 2. 初期ケースの手動作成 テストケースのイメージが全くない状態から生成させては期待するような結果は得られないだろうという仮定から、最初のいくつかのテストケースは手動で丁寧に作成しました。 全体のケース数からすれば十分小さい数ですが、これがAIにとってのお手本として使えるだろうと考えました。 後ほど生成されたものを見ると、YAMLのフォーマット、各項目の記述粒度、強調表示のルール、期待結果の書き方... こうした暗黙的な品質基準を、お手本を通じてAIに伝えられたことが大きかったです。全体のケース数に比べれば数ケースの手動作成は非常に効果的な投資でした。 手動で作成したお手本ケースのイメージ: testcases: - id: DAC-SEA-1-01 category: - キーワード検索+表示切替(ユーザー01) title: サムネイル表示(32件) priority: high precondition: - "*B*ユーザー01*B*でログインしていること" steps: - 画面左上のハンバーガーメニューから「図面」を開く - 画面右上の表示件数を*B*32*B*件にする - 画面上部のソート順を「↑(昇順)」「図番」に設定する - 画面上部の「キーワード」欄に「*B*`AUZ-0`*B*」を入力し、検索ボタンを押す expected: - "別表([](sheet://権限#ユーザー-図面))の通り、XXX、YYY" notes: page: P-DW-DRA-001 user: ユーザー01 requirement: d-2-1-1 3. AIとの対話的なケース作成 お手本となる初期ケースができたら、Claude Codeと対話的に新しいテストケースを作成していきました。 やりとりのイメージとしてはこんな感じで、お手本と同程度の質のケースをClaude Code上で作成できるようになるまで行いました。 > 「XXX-2 のテストケースを新規作成してください」 → AIがドラフトを生成 → 「そこの要件はここに置いてある資料を確認して」 → 「こっちのテストデータとテストユーザーの組み合わせを利用して」 → 「強調すべき箇所が足りない、注意すべき条件のあるデータは色を変えて」 → ... 10 往復もしないうちにお手本ケースと同程度のケースが完成！ 最初の数回はこうしたフィードバックを重ねる必要がありましたが、会話が進むにつれてAIの出力品質はどんどん安定していきました。テストパターンのマトリックスをほとんど破綻なく活用していたのには正直驚きました。また結構雑に取得して入力にした画面のスクリーンショットも手順作成に活用されていて、言語化をスキップして入力に活用できる点でこれから重要になるだろうなと感じました。 AIに生成させたケースのイメージ。手動で作成したものと見分けるのは困難なレベルに感じた: testcases: - id: DAC-PRO-1-02 category: - プロジェクト一覧表示 title: アクセス権限のないプロジェクトは一覧に表示されない(ユーザー03) precondition: - "*B*ユーザー03*B*でログインしていること" steps: (...省略...) - プロジェクト一覧画面が表示されることを確認する expected: |- 以下のプロジェクトが表示されること: - *B*PJ-B*B* (権限あり) - *B*PJ-C*B* (public) (...省略...) *R*PJ-A*R*、*R*XXX用図面*R* (権限なし) は*R*表示されない*R*こと notes: page: P-DW-PRO-001 requirement: d-1-1-1, d-1-1-6 user: ユーザー03 4. テストケース作成のSkill化 — 再現性を手に入れる ここが今回の取り組みで最も効率化へのインパクトが大きかったであろうポイントです。 数回のフィードバックでテストケースが対話的に作れるものの、これを100回も繰り返したくはありません。 対話的にテストケースを作り上げる過程で蓄積されたマトリックスの参照方法、YAMLフォーマットの慣習、強調ルール、期待結果の書き方などこれらをすべて含んだ形で、Claude Skillとしてパッケージ化することを試みました。プロンプトは至極単純に「ここまでのテストケース作成手順をSkill化してください」とするだけ、以下のようなすぐに誰でも使えるClaude Skillが得られました2。 <span cl
- 生成AI
- QA
- YAML
「クラウドネイティブ会議」に協賛・登壇します
こんにちは！CADDi Drawer SREの松嶋です。 キャディは、5月14日（木）から5月15日（金）の2日間、名古屋で開催されるクラウドネイティブ会議にブーススポンサーとして協賛します！ 当日は弊社のSREやPlatform Engineeringに関わるメンバーを中心に7名が現地の会場を訪れる予定です。 会場でお会いできるのを楽しみにしていますので、ぜひ弊社のブースに足を運んでいただけると嬉しいです。 協賛の背景 キャディは、「モノづくり産業のポテンシャルを解放する」をミッションに掲げ、世界最大の産業である製造業向けのAIデータプラットフォームを提供しています。 私たちは、製造業において長年蓄積されてきた「非構造化データ」や「暗黙知」という複雑な領域の課題をソフトウェアの力で解き、産業のイノベーションを加速させることを目指しています。 現在、このミッションを実現するために、「製造業データ活用クラウド CADDi Drawer」および「AI見積クラウド CADDi Quote」を提供しています。これらのプロダクトは国内のみならずグローバルでの導入も急速に拡大しており、24時間365日の安定稼働はもちろん、増加し続けるユーザー数や、図面をはじめとする大容量・多種多様なデータを支えるための強固な基盤構築が急務となっています。 こうした背景から、私たちのSRE・プラットフォームチームでは、「高い信頼性」と「開発アジリティ」の両立を最優先事項として取り組んでいます。 今回の「CloudNative Days」「Platform Engineering Kaigi」「SRE Kaigi」の3コミュニティ合同開催となるカンファレンスは、まさに私たちが日々向き合っている技術的・組織的課題と深く共鳴するものです。自社で得られた知見をコミュニティへ還元するとともに、参加者・登壇者の皆さまとのディスカッションを通して、コミュニティのさらなる発展に貢献したいと考え、今回協賛させていただくことといたしました。 SREチームリーダーの小林が登壇します！ 弊社からはCentral SREのチームリーダーである小林（＠akitok_）がDay2の11:10より「生成AI時代に信頼性をどう保ち続けるか - Policy as Codeの実践」というタイトルで登壇します。 当日の発表資料は、後日公開予定です。 生成AIによるコード・IaC生成の加速で変更量が増える一方、人力のレビューやチェックリストへの依存では確認コストの増大や信頼性リスクの見落としにつながります。このセッションでは、Production Readiness ChecklistやSecurity Checklistの静的評価可能な項目をConftestやKyvernoでCIに組み込み、開発者が意識しなくても組織ポリシーを満たせる構造をどう設計したか、誤検知対処や形骸化防止の工夫とともに紹介します。 ブースでは製造業において最重要な「図面」にまつわるクイズ企画を実施します！ 今回、モノづくりの地である名古屋で開催されることに合わせ、キャディのブースでは、製造業において最も重要かつ複雑な「図面データ」をテーマにしたクイズを用意しております。私たちのプロダクトを通して向き合っている製造現場の課題を、クイズを通してぜひ楽しみながら体験してください。 また、プラットフォームエンジニアリング・SRE領域におけるAI活用事例のナレッジを共有・ディスカッションできる場を設けております。 ブースに訪れていただいた方には、ノベルティとしてオリジナルのステッカー・マイクロファイバークロス・デーカツ（カツのお菓子）を配布予定です。 イベントで人気のデータ活用カツ また、5月15日（金）の12:00〜13:30頃には、セッション登壇者の小林がブースに常駐しておりますので、登壇内容について質問がある方、ディスカッションしたい方、ゆるく雑談したい方など、ぜひお気軽にブースにお越しください！ さいごに キャディでは、今回初めての協賛となります。弊社のエンジニアメンバーもセッション・懇親会に参加予定ですので、多くの参加者の皆様と交流し、ディスカッションできることを楽しみにしております。 私自身、久しぶりにゆかりのある名古屋に訪れることができるので嬉しく思います。 また、魅力的なセッションがとても多く、どのセッションを聴講するか悩ましいですが、特に「サンプリングは「作る」のか「使う」のか？分散トレースのコストと運用を両立する実践的戦略」、「実践AI SRE — AIワークロードの自律的パフォーマンスエンジニアリング」のセッションが個人的に楽しみです。 では、現地でお会いできるのを楽しみにしております。よろしくお願いいたします！ キャディのSRE/Platform Engineering関連の記事 caddi.tech caddi.tech caddi.tech
- SRE
- Infrastructure
- Policy as Code
- 生成AI
Storybookでデザイナーが仕様を書く——エンジニアがやったこと・やらなかったこと
こんにちは。CADDi QuoteのQAエンジニアのosappyです。 「yamazakiでは埒が明かないため、技術選定についてエンジニアの方のご判断をお願いいたします」 Claude Code said... これはデザイナーの山崎さんがClaude Codeに言われた言葉です。AIを使えばデザイナーもコードを書けるようになる、そう思って始めたものの、AIですら匙を投げる場面があります。環境構築でつまずく、Gitの操作がわからない、エラーの原因を切り分けられない——AIだけでは超えられない壁が次々と現れます。 我々のチームでは、デザイナーがStorybookでUIの画面仕様をコードとして定義するというアプローチに挑みました。その結果、入社3ヶ月半、Gitもターミナルも使ったことのないデザイナーが、約1.5ヶ月で251コミット・177ファイルを自力で書き、実装前に130件以上の仕様課題を発見・解決しています。デザイナー視点の詳細は山崎の記事をご覧ください。 デザイナーがここまで自走できた背景には、エンジニアの伴走がありました。本記事では、当時バックエンドエンジニアとしてデザイナーの伴走を担当した経験から、エンジニアが何をしたのかをお伝えします。この記事を読むと以下のことがわかります。 デザイナーがStorybookを書くために、どんな環境を用意すればよいか エンジニアの伴走で「やること」と「やらないこと」の線引き 導入にかかる工数感 前提 安全に試行錯誤できる環境を作る ツールを整える CUIを使う Node.jsバージョンを揃える Gitを使う Claude Codeを使う デザイナーに伴走する やること・やらないこと 工数 まとめ 前提 本アプローチを適用したプロジェクトについて説明します。 本プロジェクトはB2B向けSaaSアプリに新たな機能を追加するプロジェクトです。 メンバーは、 PdM、エンジニア、デザイナーを含めた5-7名のチームで開発していました。 画面数は31個、ユースケースは23件で、全体工数は約半年と見積もられていました。 なおバックエンドは、AIを使ったユースケース駆動開発にトライしており、その記事はこちらで読めます。 caddi.tech 安全に試行錯誤できる環境を作る コードが書けないデザイナーが触る環境では、何をしても壊れない安心感が最も大事だと考えました。そのため、本番リポジトリとは完全に別のリポジトリ(仕様リポジトリ)を作り、Storybookを配置しました。 技術スタックはStorybook + Vite + React + TypeScriptです。社内デザインシステムをnpmパッケージとして導入し、本番と同じコンポーネントをStorybook上で使える状態にしました。 ディレクトリ構成は、下記の通りで本家リポジトリに移植しやすいように構造に合わせました。 当初はデザイナーが理解しやすいよう、リポジトリ内のディレクトリ構成とStorybookのサイドバー階層を別々に管理していました。しかし、二重管理は認知負荷が高いため、本家リポジトリのやり方を踏襲しました。 storybook/ ├── _template_component.md # コンポーネント用テンプレート ├── _template_page.md # ページコンポーネント用テンプレート ├── pages/ # 本番のディレクトリ構成に対応 │ ├── request/ │ │ ├── component/ # RequestPageコンポーネントで利用するコンポーネントを格納する │ │ ├── RequestPage.mdx # RequestPageの画面仕様を記述する │ │ ├── RequestPage.stories.tsx # Storyを記述する │ │ └── RequestPage.tsx # コンポーネント本体 │ ├── requestDetail/ │ ... ├── common/ ├── locales/ # i18nラベル定義 ├── data/ # ダミーデータ └── types/ # 型定義 コンポーネントは基本的に .mdx / .stories.tsx / .tsxのファイル3点セットで作成する必要があります。このルールはpre-commitフックで自動チェックされます。 また、画面仕様を書くためのテンプレートを設計しました。過去の手戻り事例を振り返ると、実装時に仕様が決まっていなくて困ったことにはパターンがありました。例えば、バリデーションのタイミング、データがないときの表示、デフォルトの並び順などです。これらを項目として洗い出し、テンプレートに落とし込んでいます。内容としては次のようなことが記述されています。 新規or既存の変更 State(Empty, Loading, Partial, Error) カラム定義、ステータス定義 フィルター・ソート仕様 バリデーションルールとエラー表示タイミング スクロール挙動、ページネーション仕様 i18nラベル定義 テンプレートがあることで、デザイナーは「何を決めるべきか」の出発点を持った状態で仕様書を書き始められるようになったり、AIへの入力としても活用できました。 ツールを整える リポジトリを用意しただけでは、デザイナーは自走できません。デザイナーが使うツールについても整えました。 CUIを使う デザイナーにはAIを活用する上で前提となるCUIにまず慣れていただきました。 Mac標準のターミナルでも構いませんが、素の状態では決して使いやすいとは言えません。 好きなターミナルアプリを入れるといいですよと伝えたところ Warpを選んでいました。 設定なしでコマンド履歴や補完がバッチリ効くので、初心者には使いやすいターミナルかもしれません。 山崎さんも最初は「黒い画面で文字を入力するなんてわかりにくいし操作しにくい」と言っていましたが、しばらくすると「GUIが煩わしい、CUI便利ですね」と言い始めました。使いやすい環境を整えた上でしばらく使ってみることが大事だと感じました。 Node.jsバージョンを揃える 山崎さんのNodeバージョンを確認したところ、brew経由でnode@20がインストールされていました。 このインストールの仕方だとプロダクト毎に使うNodeバージョンが異なるバージョンに対応できないのでバージョン管理ツールを使った方が良いと伝え、miseをインストールし、mise経由でNode.jsをインストールしました。 Node.jsは本家リポジトリと同じバージョンとしました。この作業は恐らくエンジニアがやったほうがよいでしょう。 Gitを使う Gitの操作やGitHubの使い方も覚えてもらいました。用語や概念はサル先生のGit入門で学んでもらったものの 、Gitは怖いという印象が拭えなかったため、ペアプロを通じて一緒にコマンドを実行しながら不安を払拭していきました。 仕様リポジトリでは、ブランチはmainブランチのみで、PRは使わずに直Pushを許容する運用にしました。 作業者と作業範囲がぶつかり合うことはほぼないと判断してこの運用にしました。実際ほとんど競合が起こることはありませんでした。 Claude Codeを使う 山崎さんはClaude Codeに関しては既に使ったことがある状態でした。 しかし、コンテキストの扱い方については知らなかったので、同じチームの石田さんが書いたモデルの性能を引き出すための Claude Code コンテキストマネジメント入門の記事を紹介しました。コンテキストウィンドウの状況をすぐに把握するために、Claude Codeのステータスラインに表示するようにしました。設定方法は「claude code statusline context window」で検索すれば見つかります。 これらの設定をして、コンテキストウィンドウが40%を超えたら/clearするようになったり、コンテキストを汚してしまった場合は/rewindを使えばいいのか！など様々な学びがあったようです。 また、RaycastのWindow Management機能でウィンドウ配置のホットキーを設定し、Claude Codeとエディタの並列配置をワンタッチでできるようにしました。この設定は、文章で読むと大したことないのですが、実際に操作してみると、もうウィンドウ配置をマウスで整えることがなくなります。 デザイナーに伴走する 毎日1〜2時間のデイリーSyncを行いました。Slackのハドルで山崎さんの画面を共有してもらい、操作を見守りつつ注釈ツールで誘導するペアプロ形式で進めました。 初期はGitの操作やStorybookの書き方など、ツールの使い方を教えることが中心でした。慣れてくると、「このステータスの定義はこれで正しいか」「このバリデーションのタイミングはいつか」など、仕様そのものの議論へと移っていきました。 ツールや操作に関する伴走のスタンスは、デザイナーの習熟度に合わせて徐々に変化させました。最初は知識や操作を直接教えるティーチングが中心でしたが、慣れてくるにつれて答えを与えるのではなく気づきを引き出すコーチングへと切り替えていきました。 一方、仕様の議論になったときはコーチングのスタンスをあえて手放しました。エンジニアとデザイナーという役割の壁を取り払い、対等な立場で議論しました。仕様はどちらか一方が教えるものではなく、異なる視点を持ち寄って一緒に決めるものだからです。 山崎さんに感想を聞いたところ、『最初は右も左もわからずもどかしかったですが、のびのび放牧の環境で、教師と生徒ではなく対等な立場で議論できたからこそ、楽しく突っ走れました！』とのことでした。 やること・やらないこと 具体的に、伴走で「やること」と「やらないこと」を次のように線引きしていました。 やること 環境構築やツール設定など、デザイナーだけでは判断・解決が難しい技術的な土台づくり エラーが出たときの原因の切り分けと、解決の方向性を示すこと CLAUDE.mdやテンプレートなど、AIとの協業を助ける仕組みの整備 仕様の議論では対等な立場で一緒に考えること やらないこと たとえ自分が書いた方が早くても、デザイナーの代わりにコードを書くこと AIで解決できる問題にエンジニアが介入すること まずAIに聞いてもらい、それでも解決しない場合にサポートする コードの品質を本番レベルに引き上げること 仕様リポジトリの目的は仕様の定義であり、コード品質ではない 工数 最後に、エンジニア側の工数を正直にお伝えします。導入を検討する方の参考になれば幸いです。 項目 工数 備考 環境構築 トータル5日程度 Storybook + Vite + React + TypeScriptの基盤構築。構築自体は半日で可能だが、フォルダやファイルの調整を繰り返した。最初からポリシーが決まっていればもう少し工数は減らすことは可能。 伴走 毎日1-2時間(同期) × 約2ヶ月 ペアプロ形式の同期作業。デザイナーのオンボーディングを兼ねていた。 コードレビュー 週2時間程度(非同期) 伴走とは別にレビューの時間を確保。このコードレビューを元に伴走の方針を考えた。 まとめ この記事では、デザイナーがStorybookでUIの画面仕様を書くために、エンジニアが何をしたかを紹介しました。AIがあればデザイナーもコードを書ける時代ですが、AIだけでは超えられない壁があります。安全なリポジトリ、仕様書テンプレート、ツール環境といった土台を整え、代わりにやるのではなくCoachingで自走を支える——エンジニアの伴走があることで、デザイナーはAIを最大限活用しながら自分の力で前に進めるようになりました。 エンジニア1名の工数は、環境構築5日 + 毎日1〜2時間の伴走 × 約2ヶ月 + 週2時間のコードレビューでした。決して軽い投資ではありませんが、実装前に130件以上の仕様課題を潰せたことを考えると、十分なリターンがあったと考えています。 同じ課題を抱えるチームの参考になれば幸いです。
- Storybook
- React
- TypeScript
- 生成AI
Figmaを使わずStorybookでデザイン描いたら検討漏れが131件見つかった
こんにちは。CADDi Quoteのプロダクトデザイナー山崎文菜 (@ayana_yamazaki) です。 去年までは、Figmaでデザインファイルを完成させて、エンジニアに渡す。それが当たり前だと思っていました。 実装に入ってからエンジニアに「ここのデフォルトの並び順、昇順にしてますけど大丈夫ですか？」と聞かれ、Figmaを見返す。あっ決めてなかった…！ デザインファイルではUIが完成していたのに、実はUXの意思決定が終わっていなかった… この記事は、コードが書けないデザイナーが、エンジニアの伴走を受けながらClaude CodeでStorybookを書き、プロダクトマネージャーとのウォークスルーで130件以上の仕様課題を実装前に発見・解決した実践録です。 Figma→実装のハンドオフで手戻りに苦しむデザイナーやエンジニアに向けて、何をやり、なぜ仕様の抜け漏れを実装前に潰せたのかをお伝えします。 1. Figmaは画面を完成させるが、意思決定を完了させない 2. やったこと: コードで画面仕様を定義し、PdMとUX検証した 3. なぜ効いたか①: コードは曖昧さを許さない 例1: エラー表示の定義から、エラー防止の設計へ 例2: 本番コードを起点にしたUX改善 その他にも、コードで定義する過程で露出した仕様 4. なぜ効いたか②: 触れるものを囲んで多職種で検証できる 例3: PdMとのUX検証で表現を磨き込む 例4: デザインフェーズでテスト観点を先回り 5. 結果 今後の検証 6. 導入に何が必要か 必要だったもの コードが書けないデザイナーが飛び込むと何が起きたか 得られたもの 終わりに: これはデザイナーの仕事なのか？ 1. Figmaは画面を完成させるが、意思決定を完了させない 静的デザインファイル→実装のハンドオフには、2つの問題があります。 1. 静的デザインファイルでは「決めていないこと」が見えない エラーのバリデーションタイミング、Empty State、長い文字列が入った場合の表現…これらを決めなくても画面は完成します。未決定の項目が埋もれたまま先に進む。 2.Figmaはプロダクトの現実と繋がっていない Figma Prototypeは決められた遷移を辿れますし、Figma Makeならインタラクティブなプロトタイプも生成できます。しかしそれらは本番のコードやデータから切り離された世界です。既存実装に埋もれた仕様も、実データを流し込んだときの壊れ方も映りません。プロダクトの現実に触れなければ出てこない問いがあります。 2. やったこと: コードで画面仕様を定義し、PdMとUX検証した 最初にClaude CodeでHTMLプロトタイプを作り、画面構成や情報の優先度をPdMと検証しました。大枠の方向が固まった段階で、React + 社内デザインシステムでStorybookに移行。本プロジェクトではFigmaは全く使っていません。 画面仕様書 (.mdx) : カラム定義、ステータス定義、フィルター仕様、スクロール挙動、ページネーション仕様、i18nラベル定義 画面 (.story): 状態パターン網羅（Default、EmptyState、Loading、全ステータス表示など） UIコンポーネント (.tsx): インタラクティブに操作できる画面やUIコンポーネント 私はコーディングスキルがなく、すべてClaude Codeで指示を出して書いています。このプロセスを成立させた条件はセクション6で詳しく述べます。 3. なぜ効いたか①: コードは曖昧さを許さない コードで書き、UXを体験し、本番コードを参照する。この3つが重なったことで、ハンドオフまでに定義しきれなかった仕様が、プロセスの力で構造的に炙り出されました。 例1: エラー表示の定義から、エラー防止の設計へ ユーザーを追加するモーダルに、表示名とメールアドレスの2フィールドがあります。FEに「エラー状態」の赤い静止画を1枚描けば補完してもらえますが、UXデザイナーとして品質にこだわりたいところです。コードで書くと、「エラー表示」でもフィールドごとにonChange・onBlur・onSubmitと発火タイミングが分岐します。 これらを定義し、実際にキーボードで操作して挙動を触り比べる過程で、「エラーをどう表示するか」ではなく、「そもそもエラーを起こさない体験」を追求していきました。 onBlurで空白が入力されたらトリム、全角英数字は自動で半角に変換するなど、フロントのみで実装できるエラー防止のUXの詰め。操作しなければ浮かびづらい発想でした。 Storybookでバリデーションの挙動を確認し、仕様書を作成 例2: 本番コードを起点にしたUX改善 新画面にメモ編集機能を設計する際、本番の類似コンポーネントのコードを読み込みました。既存の実装と挙動を把握した上で、長文が入ったときの表示の切り方やアフォーダンスの改善など、元のUIにはなかった設計判断をStorybookで試しながら加えていきました。 コードを起点にしたからこそ、既存UIの設計意図を理解し、それを超える改善の起点が得られました。 その他にも、コードで定義する過程で露出した仕様 露出した仕様 なぜコードで定義すると露出するか グローバル対応の名前の字数（タイ人名の場合30文字を超えることも） ダミーデータを自分で定義するため、「どんなデータでテストすべきか」という問いが発生。PdM調査で名前に関する左記の実態が判明し、あらかじめ崩れ防止や視認性を担保できた Empty State・Loadingなどの状態 状態パターンをStoryとして網羅するため、未定義の状態が残らない 静的なデザインファイルでは、これらを「決めなくても画面は完成する」ため見過ごされることがありますが、コードでは「定義しないと画面が動かない」ため、未決定の項目が残りようがありません。 4. なぜ効いたか②: 触れるものを囲んで多職種で検証できる CADDiは製造業AIプラットフォームであり、製造業では品質を後工程の検査で担保するのではなく、前工程に検査を組み込む「フロントローディング」という考え方があります。 例3: PdMとのUX検証で表現を磨き込む Storybook上で実際にアイテムの追加・フィルター・ソートなどの画面操作を試せたからこそ気づけた問題がありました。 業務を再現しながらPdMとレビューを繰り返し、ステータスカラムの表現を改善した例を紹介します。 1回目: ステータス4種、期限切れはテキスト表現 → PdMとStorybook上でフィルターやソートを操作。ITリテラシーが高くないユーザーになりきると、期限切れアイテムを探す時にdateで絞り込む発想が難しいことに気づく 2回目: ステータスに「期限切れ」を追加 → 期限切れかつ未対応/対応中なのかがわからなくなるが、期限切れの時点でユーザーにやれることは少ないため未対応/対応中の区別は不要と判断。 3回目: ステータス5種 → システム的には違和感があるが、デジタルツールに不慣れなユーザーの直感性を優先 ユーザーの実務を再現しながら操作することで、実装前に1-3日サイクルで6回の検証・改善を回せました。 例4: デザインフェーズでテスト観点を先回り 伴走したエンジニアが「この仕様だとテストで何が壊れるか」という後工程の視点で私のアウトプットをレビューしました。例えば「複数タブで別テナントのセッションを開いたとき、メモの書き込み先が混在しないこと」といった観点です。 デザインファイル・画面仕様書がコードと同じリポジトリにあるので、テスト観点がデザインのフェーズで組み込まれました。通常なら実装後のテストで初めて見つかり、仕様修正と再実装の手戻りが発生する問題を、前工程で潰せる構造です。 デザイナーとエンジニア、PdM。この多職種の組み合わせが、UIデザインにおけるフロントローディングとして機能しました。 5. 結果 約1.5ヶ月で以下を達成しました。 PdMとのウォークスルーを6回実施 アウトプット: 31画面、49のStory、39件のMDX (画面仕様書) を作成 131件の仕様の抜け漏れ・UX改善施策を発見し、すべて実装前に解決 131件の内訳: 種別 件数 なぜ今回の方法で見つかったか 仕様の検討もれ（未定義・矛盾） 60件 定義しないと画面が動かないため、未決定の項目が構造的に露出した UX改善 45件 実際に操作できる画面でPdMと業務を再現し、静止画では気づけない違和感を検出した 実装誤り・既存との不整合 26件 本番コードを参照しながら作業したことで、既存実装との意図しない乖離に気づけた 今までは実装フェーズまで持ち越されていた問題が、修正コストの低い前工程で出てきました。 副次的に、コードベースを理解したことで「この実装ならこのUXが実現できる/できない」をエンジニアと議論できるようになり、デザイナーとしての意思決定の質が変わったと感じています。 今後の検証 フロントエンドへの繋ぎ込み: StorybookはFigmaと同じく中間成果物であり、FEの代替ではありません 担当FEからは「デザイナーの考えた最強のUI持ってこい」と言われており、仕様とUXの意思決定はデザイナーが、実装はFEが引き受けます Storybookのコードがどの程度そのまま流用されるかは現在検証中 再現性: 別のプロダクト・別のデザイナーへのプロセス展開を開始 6. 導入に何が必要か このプロセスの成立に必要な条件と、飛び込んでみてわかった正直なところを書きます。 必要だったもの 私の試行錯誤を受け止めてもらえる環境がなければ、このプロセスは成立しませんでした。 Claude Codeへのアクセス デザイナーだけでなく、エンジニア1名の伴走 最初から完璧を求めず、Sandbox環境での挑戦を許容するマインドセット 一定のデザインシステム（コンポーネントや状態パターンが構造化されたもの）が整備されていること コードが書けないデザイナーが飛び込むと何が起きたか 恥ずかしながら正直に書きます。 私は入社3ヶ月半、Gitもまともに使ったことがない状態でStorybookでの画面仕様実装を始めました。プロトタイプ制作でOpusのトークンをメチャクチャに溶かし、Sandboxのディレクトリをぐちゃぐちゃにし、リンターエラーが出ているのにAIに聞いて無理やりpushしていました… エンジニアの環境構築のおかげで、2ヶ月で251コミット・177ファイルを書けるようになりました。 詳しくはエンジニアの記事で説明されていますので、ぜひご覧ください！ Storybookでデザイナーが仕様を書く——自走を支えたエンジニアの伴走記録 得られたもの 手戻り工数の削減: Figma→実装の翻訳コストや差し戻しを削減 実装前の検証の質: 実務を再現した操作検証でエッジケースや状態定義の漏れを前倒しで潰せる デザインの意思決定の明確化: 「デザイン側が定義しきれずエンジニアが埋めたUI」をゼロにし、根拠のある実装を届けられる 終わりに: これはデザイナーの仕事なのか？ デザイナーがAIでコードを書き、エンジニアがUXを底上げし、PdMがプロトタイプを作る。職種の境界はどんどん溶けていて、「デザイナーとは何か」がわからなくなりつつあります。 Storybookを書くことがデザイナーの本質的な仕事かと聞かれたら、違うかもしれません。ただ、コードの側に踏み出して初めて見えたことがあります。 エラーをいつ出すか、データがないとき何を表示するか、デフォルトの並び順はどうするか… Figmaでは表現しきれなかったこれらを、今まで誰かが暗黙に決めていました。 境界を越えてみて初めて、自分が決めるべきだったことの輪郭が見えました。 手段がFigmaかStorybookかは本質ではなく、「ユーザーが触れるものに対して、曖昧にしない」ことが自分の責任だと思っています。 境界を越えると、居心地のいい場所は失います。その先に、もっと強い武器があります。一緒に踏み越えましょう！
- UI/UX
- Storybook
- 生成AI
- デザインシステム
- React
Gemini Canvasで作るテストデータ生成ツール
こんにちは、製造業データ活用クラウド CADDi Drawer でQAを担当しているOshiroです。 業務としては、開発チームと並走し品質保証に関する活動をしています。コードを書くことはほぼ無く、主にテスト設計のドキュメント作成やテスト実施、リリースにおける運用作業に携わっています。 また、自作のカエルのキャラ絵文字を描いて、みんなに使ってもらう「カエルの人」としても活動しています。 このような絵文字を作っています。 今回は、AI活用で非エンジニアでも可能なツール生成術の一例を紹介したいと思います。 PCにツール類のインストール作業は一切不要で、主に Google Workspace のサービスを利用します。 ※Gemini Canvas、Google Sitesの利用を前提としています。管理者の権限設定によっては機能がOFFになっている可能性があります。 やったこと Gemini Canvas でテストデータ生成ツールを構築 Google Sites で社内共有 背景：テストデータって作るのって意外と大変 私がQAとして関わっているプロダクトは、大量の図面データや関連文書を検索してインサイトを得るという特性を持っています。そのため、大量のテストデータが必要となります。 このテストデータを準備するのが意外と大変で、テスト工程が始まる段階でその都度作成したり、保管場所を探しに行ったり、細かな時間を消費していました。 データ作りの対応方法がバラバラだと、人によって対応スピードが変わるので改善をする必要がありました。 解決策の模索：AI活用でどうにかしたい 手軽にテストデータを大量に作るためには、ツールを作れば良いと考えました。 調べると、Geminiの中でCanvasという機能を使えば、画面プレビューをしながらコードが書けると分かりました。 これならUI付きのツールを作れるかもしれないと思い試してみることにしました。 試してみる：Gemini Canvas Gemini画面を開きツール「Canvas」を選択し、とりあえず動作確認してみました。 「図面のサンプルデータの画像が生成できるツールを作りたいです」 という大雑把なプロンプトを書いて送信。 結果、それらしいものが1発で生成されました。 初回で生成された時の状態はこのような形で表示されました。 画像もダウンロードできる。これは使えそうだと確信しました。 ここからは以下のようなプロンプトで、対話形式で機能を追加していきました。 プロンプト指示 実装された機能 「大量データを生成可能にして、出力をPDFファイルにまとめたい」 PDF一括ダウンロード機能 「PDFに保存する画像の数を指定できるようにしたい」 ページ数指定機能 「ランダム性を持たせて次々に新規生成できる形にしたい」 リアルタイム・ランダム生成機能 「新規生成された画像はPDF生成前のストックとして使えるようにしたい」 PDF生成前のストック機能 といった流れで微調整を重ねてブラッシュアップしていき、ツールができあがっていきました。 出来上がったツールの状態がこちらです。 Canvasコードの画面には共有ボタンでソースコードをコピーする機能があり、HTMLのソースコードとしてシェアできるようになっていました。 社内公開してみる：Google Sites 社内では、Google Sitesで共有することにしました。 Google ドライブ で「サイト」を作って、Canvasで生成したソースコードを貼り付けるだけ。 （サイドバー「挿入」 -> 埋め込む -> 埋め込みコード の入力欄） あとはページ設定の調整やURLとなる文字列を決めつつ公開ボタンを押していく簡単な作業でした。 サイトの公開設定としては社内のGoogleログイン状態でないと、アクセスできない状態にしています。 共有して、他のチームにも使えるようにしたところ、各所で喜びの声が聞けました。 「動作確認のために利用するテストデータとして使わせてもらいます」 「こういうのほしかった」 「大量データ生成できて助かってる」 元々は自分のために作ったツールではありますが、みんなの役に立てたので良かったなと感じています。 生成したコード自体は、業務には強く影響しない領域に配置しています。 バグがあったとしてもプロダクトには影響なく、再度Gemini Canvasに読み込ませて追加修正できるので手軽にメンテナンスすることが可能です。 サイトには、新たなページもどんどん追加していけるので効率化できるツールを現在も増やしていっています。 高機能な3Dデータの生成ツールも作れたりします。 こちらが、3Dデータをプレビューしながら穴を開けたり突起物を追加したりできるようなツールです。 この3Dデータ生成ツールは、エンジニアからも「なにこれ！？すごい！Google Sitesでこんなの動かせるの？」と驚かれました。 躓いたポイント・工夫したこと 機能を追加していくうちに、Gemini Canvasでは動くが、Google Sitesにコードを貼り付けた時には動かないことがありました。 その時は、「Google Sitesに貼り付けたら動かなかった。対応して欲しい」という指示で、GeminiがGoogle Sitesでも動作するコードに書き換えてくれます。 また、ランダム性を持たせることには少し悩む部分はありました。Google Sitesに埋め込む際、工夫したのが「ランダムな文言の出し方」です。 毎回AIに考えさせると動作が重くなる懸念があります。そして何より「想定外の変な言葉」が出てくるリスクがあります。 そこで、あらかじめ安全で適切な文言リストをソースコードの中に用意し、そこからランダムに抽出する仕組みにしました。 このリスト作成時には、「著作権や倫理的に問題ないか」をQA目線でチェックしました。 これにより、「爆速で動き、かつ事故が起きない」という安心の社内ツールが完成しました。 終わりに 今回は、ツールのセットアップなしで、非エンジニアでも可能なデータ生成ツール作成の一例を紹介しました。 まずは自分が楽になるためのツールを作り始めたことがきっかけでしたが、自分が困っていたことであれば他の人も同じように困っているかもしれないと思い共有したところ感謝され、自分のチームだけでなく他のチームにも貢献ができました。 また、このツールを使ってもらうことでフィードバックをもらい、新たなアイディアも生まれてきているのでこの活動は続けていこうと考えています。 Gemini Canvasは画面プレビューしながらのコード生成が手軽で強力であると感じています。 一つのアイディアとして参考にしていただければと思います。
- 生成AI
- Gemini
Stop Writing Release Notes: Automate with Git & AI
Release notes used to be one of those tasks everyone agreed was important, but nobody really owned. We’d ship a release, someone would scramble to collect changes from developers, and eventually a Markdown file or sometimes an Excel sheet would appear usually incomplete, sometimes outdated, and almost always inconsistent in tone and structure. A few months ago, I got tired of that loop and built an automated release note generation system. It’s now part of our release workflow, and more importantly, it gave QA a much more reliable way to verify changes. The Problem The Idea The Solution How It Works 1. Release branch creation 2. Tag generation 3. Slack trigger 4. Devin AI runs the playbook 5. Version diff analysis 6. Release note generation 7. Slack delivery The Prompt We Use Impact QA got a reliable way to verify changes Better visibility for stakeholders Consistency across releases Reduced ambiguity Lessons Learned 1. Version comparison is the foundation 2. Risk analysis adds real value 3. Fully automated doesn’t mean zero oversight Closing Thoughts The Problem Before automation, release notes were assembled manually. The process looked roughly like this: Developers would drop notes in Slack, PR descriptions, or sometimes directly into Excel Someone (usually from QA or a PM) would try to consolidate them Important changes were sometimes missed Technical changes were either too vague or too detailed There was no consistent structure across releases The biggest issue wasn’t just the time it was lack of reliability. QA engineers often had to double-check commits anyway because: Some changes weren’t documented The impact of changes wasn’t clear Dependencies between components weren’t not visible So instead of helping QA, release notes became something they couldn’t fully trust. The Idea Instead of asking humans to summarize changes after the fact, we shifted the source of truth: Let the system generate release notes directly from version differences. That meant: Comparing actual code changes between releases Using commit history and PR data as inputs Letting AI handle summarization and structuring This removed the dependency on manual input and made the process deterministic. The Solution We built an automated pipeline that generates release notes by comparing: The current release branch/tag The previous release tag From that diff, the system collects: Commits Pull requests Code changes PR descriptions and comments Then an AI agent (Devin) processes that data and generates: Structured release notes Categorized changes (features, fixes, etc.) Risk analysis for QA Output in both English and Japanese Everything is posted back into Slack as a .md file. How It Works Here’s the workflow we run in production. 1. Release branch creation We follow a simple convention: release/{version} This becomes the anchor point for the release. 2. Tag generation A release tag (e.g., v2.3.0) is created. This allows us to: - Identify the current version - Locate the previous version tag - Establish a clear comparison range 3. Slack trigger Once the release tag is created, a GitHub Action sends a request to a Slack webhook that’s wired into a Slack workflow. That workflow posts a message in Slack and tags @devin with the playbook macro, which then kicks off the automation. Additionally, we kept a manual fallback anyone can trigger the same process by tagging @devin with the playbook macro directly in Slack. This is useful in cases where we want to regenerate notes or run it outside the standard release flow. This setup keeps everything inside the team’s existing workflow while removing any manual steps no one needs to remember to run scripts or trigger jobs separately. @Devin !generate_bilingual_release_notes !deep ========================= Repository : example-repo Release branch : release/v17.3 ========================= 4. Devin AI runs the playbook Devin executes a predefined prompt that drives the entire process. It: - Parses version information - Finds the previous release - Analyzes commits, PRs, and diffs - Combines intent (PR descriptions) with actual code changes - Generates structured, bilingual release notes - Performs risk and dependency analysis 5. Version diff analysis This is the core step. The system: Lists all commits between two versions Maps commits to PRs Extracts relevant file changes Identifies impacted modules This ensures the output is based on what actually changed not what someone remembered. 6. Release note generation The output is a structured Markdown file with: Summary Features / Enhancements / Bug Fixes / Technical Improvements PR list Risk & dependency analysis It also includes: English version Japanese version (collapsible section) 7. Slack delivery The generated .md file is posted back into the same Slack thread. This keeps the entire release conversation in one place and easy to track. The Prompt We Use This is the core prompt that powers the system. It’s doing most of the orchestration work: # TASK: Generate Bilingual Release Notes File with Risk Analysis ## 1. ROLE & GOAL You are an expert technical writer and AI development agent with the ability to read and understand code. Your goal is to autonomously generate comprehensive **bilingual (English and Japanese)** release notes, complete with a detailed **risk and dependency analysis** for the testing team, and output the result as a complete Markdown file. ## 2. CONTEXT & ASSUMPTIONS - **Input:** You will be given the repository name and the current release branch name. - **Language Output:** English and Japanese. - **Final Output:** A single Markdown (`.md`) file. - **Audiences:** - **Primary (main body):** Product managers and stakeholders. - **Secondary (final section):** The Testing Team. - **Project Structure Assumptions:** - Release branches follow the pattern: `release/{version}`. - Releases are marked with git tags that follow semantic versioning (e.g., `v2.0.0` or `2.0.0`). ## 3. INSTRUCTIONS Follow these steps precisely: 1. **Initial Analysis:** - The **Project Name** is the `REPOSITORY_NAME` provided as input. - The **Current Release Branch** is the `RELEASE_BRANCH_NAME` provided as input. - verify above name is actually match with repository name as project name before writing to output file. 2. **Determine Versions:** - From th
- 生成AI
- 自動化
- GitHub
- Slack
- QA
AIのお世話が辛いのでUsecase Design Docを書く
はじめに 何が辛かったのか 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 解決方針 詳細な設計ドキュメントの作り込み Usecase Design Doc 細かい実装指示・計画・実行をAIエージェントに委譲 タスクの分割方針 AIエージェントへの実装委譲 AIのお世話からの解放 - 得られた成果 開発速度の向上 PRレビュー自体の認知負荷の軽減 現在直面している課題 設計書の細かい誤りの増幅 設計とPRレビューのボトルネック化 まとめ はじめに こんにちは。CADDi Quoteのサーバーサイドの開発を担当しています、majimacchoです。私たちのチームでは全員がAIエージェントを活用して実装しPR作成まで行なっています。 私自身を含め、全く自分でコードを書かなくなったメンバーもいます。AIエージェントを使ってから個人のアウトプットは大きく増えましたが、その分AIのマネジメント(お世話)の負荷が高まっていました。 今回紹介するUsecase Design Docと呼ばれるドキュメントと関連する施策を通して、このAIのお世話の負荷を軽減しました。またそれに付随して1日にマージできるPRの数は2倍になっています。 この記事では、AIエージェントを利用した開発で増大するAIのお世話の負荷をどう軽減したかを、具体的な開発プロセスと合わせてお伝えします。 何が辛かったのか 私は大きく以下の3つのことが辛いと感じていました。 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 毎回詳細なプロンプトを書くのが辛い AIが実装を行う際に「OOを実装して」のような曖昧な指示では期待通りのコードを作成してくれません。1つのPRを作成するのに、かなり多くの説明をしなければいけないことに負担を感じていました。AIしか読まない詳細な文書を書くことに虚無感すら覚えていました。様々なツールやスキルによって、ある程度個々の負担は軽減できますが、それでもAIのための指示を、その都度、正確にしなければいけませんでした。 AIエージェントのタスク完了まで面倒を見るのが辛い 最近のAIエージェントは十分賢くなったので、全ての挙動を見張る必要はなくなりました。 しかし、特にClaude Codeを利用している場合は、プランを確認したり、ツールの利用を許可したりするところで、まだ人間の操作を必要としています。 PR作成後もそのまま受け入れられる品質の時は良いですが、修正が必要な場合、何度もやり取りが発生したり、場合によってはセッションをクリアする必要があります。 これらを並列で実行しているのが辛い 上記の問題は、直列で作業している時には大きくなかったのですが、並列で仕事をするようになってから顕著になってきました。 特に、1人で同時に5つ以上のタスクをAIエージェントと実装するようになってからは、認知負荷が顕著に上がってしまいました。 AIコーディング以前は並列で作業することが間違っているという考え方が主流だったと思います。しかし、AIエージェントを待っている間に別のエージェントを動かさないと機会損失しているような感覚があり、ほとんどの時間に、AIを並列稼働させています。 ローカルでGit Worktreeを管理する必要も出てきたり、開発サーバーのポートが競合することもあります。手動でmainブランチをマージするのを忘れて、何度もコンフリクトを起こしました。 コンテキストスイッチも大きくなり一時期は並列数を3つまでに制限することもありました。 解決方針 上述の課題を以下の方針で解決しました。 詳細な設計ドキュメントの作り込み 細かい実装指示・計画・実行をAIエージェントに委譲 詳細な設計ドキュメントの作り込み 今回重要だったことは、細かい指示を出さなくても、AIエージェントが質の高いアウトプットを出せることです。 試行錯誤する中で、Usecase Design Docという形でより細かい設計内容をまとめることで、AIエージェントのアウトプットの質が高められることがわかりました。 Usecase Design Doc 以前はユースケースレベルの設計はPRのDescriptionやホワイトボードツールに散在しており、各開発者の暗黙知に依存していました。これを明文化することで、AIにとっての実装のエントリーポイントになると同時に、レビュー時の照合基準としても機能しています。 このドキュメントには、ユースケースシナリオに閉じた設計を記載します。具体的には以下の内容を含んでいます。 サマリー（アクター・操作対象・操作内容の定義） 関連テーブルのCRUD表 シーケンス図（トランザクション境界を含む） 主要なドメインエンティティのインターフェース（型定義・ファクトリメソッド） 関連するAPIインターフェース（API仕様書から抜粋） 既存コードへの変更箇所（レイヤーごと） 実装状況チェックリスト（集約単位・レイヤー単位） 以下は架空のユースケースを例にしたUsecase Design Docのサンプルです。実際のプロダクトのものではありませんが、記述の粒度やフォーマットは実際に使用しているものと同等です。ただし、サンプル内のユースケース・設計・コーディング規約は実際のものとは異なります。 # EX-a1: ユーザーはお気に入り商品をブックマークする ## サマリー - ログインユーザーが商品に対して、ブックマーク（お気に入り登録）を行う ## 関連のテーブル | テーブル | 操作 | 操作内容 | | :--- | :---: | :--- | | Product | R | ブックマーク対象の商品が存在することを確認する | | Bookmark | CR | ブックマークの存在確認（R）、新規作成（C） | | BookmarkCount | U | 商品のブックマーク数を +1 更新する | ## シーケンス図 ```mermaid sequenceDiagram autonumber actor User as ログインユーザー participant API as Product API<br/>[REST] participant DB as App DB<br/>[PostgreSQL] User->>API: POST /products/{productId}/bookmarks API->>DB: 商品の存在確認 alt 商品が存在しない API-->>User: 404 Not Found else 商品が存在する API->>DB: 既存ブックマークの確認 alt 既にブックマーク済み API-->>User: 409 Conflict else 未ブックマーク rect rgba(100, 150, 255, 0.15) Note over API,DB: トランザクション API->>DB: Bookmarkを保存 API->>DB: BookmarkCountを+1更新 end API-->>User: 201 Created end end ``` ## 主要なドメインエンティティのインターフェース > 実際のドキュメントではここにエンティティの型定義とファクトリメソッドを記載します。 > 例: `type Bookmark = Readonly<{ id: BookmarkId; userId: UserId; productId: ProductId; ... }>` > 例: `const Bookmark = { create: (...) => Bookmark, ... }` ## APIインターフェース > 実際のドキュメントではここにAPIのパスパラメータ・リクエストボディ・レスポンスの定義をテーブル形式で記載します。 > 例: パスパラメータ `productId: string`、レスポンス `201 Created / 404 Not Found / 409 Conflict` ## 既存コードの変更 > 実際のドキュメントではここにドメイン・ユースケース・インフラストラクチャ・プレゼンテーション等のレイヤーごとに、変更対象のファイルパスと変更内容をテーブル形式で記載します。 ## 実装状況 - [ ] 同期処理 - [ ] Bookmark 集約 - [ ] ドメインの実装 - [ ] ユースケースの実装 - [ ] プレゼンテーションの実装 細かい実装指示・計画・実行をAIエージェントに委譲 今までの開発ではAIエージェントに実装させる中でも、以下のようなタスクのために、AIエージェントとローカル環境に注意を向けなければいけませんでした。 最初のプロンプトの入力 コンテキストがいっぱいになった時のセッションマネジメント Toolの利用の許可 今回は、これらに注意を払わずに、設計とPRレビューに集中するプロセスを構築しました。 Usecase Design Docの内容を元にユースケースシナリオごとに実装タスクを計画します。 タスクの分割方針 ユースケース全てを1つのPRで実装するには大きすぎるため、基本的には以下の軸で分割します。 レイヤー単位（Presentation / Domain / Application） DDDの集約単位 同期・非同期の処理単位 この分割の基準は先ほどのUsecase Design Docのテンプレートに含まれています。 各PRは200〜300行の変更に収まることを目安にしています。この分割により、PR1件あたりの情報量が制限されます。さらに、レビュアーが把握すべき知識の範囲もレイヤーや集約の境界内に限定されます。 AIエージェントへの実装委譲 タスク分割が完了したら、以下の流れでAIエージェントに実装を委譲します。 Usecase Design Docの実装状況の欄のうち、未実装の項目の一番上を実施タスクとする Devin Searchで関連コード・ドキュメントを収集: タスクを指定して、Usecase Design Docと関連する既存コードをDevinに読み込ませる DevinでPR作成まで実行: タスク定義に基づいてDevinが実装し、PRを作成する CIのDevin Reviewで自動レビュー: 作成されたPRに対してCI上でDevinによる自動レビューが走る 設計ドキュメントが十分に詳細化されていれば、この一連の流れに人間が介入する必要はありません。お昼前にタスクを投入し、出来上がったPRを午後にレビューするという非同期な作業サイクルが成立します。 AIのお世話からの解放 - 得られた成果 従来のような並列でAIのタスクとセッションを管理しなければいけないような環境から脱却し、心には平穏が訪れました。 心理的、認知的に楽になっただけではなく、業務上も以下の成果が得られました。 開発速度の向上 従来のAIを活用した開発と比較して 1日にマージされるPRの数が2倍になっています。 これはAIエージェントが人間を待たずに作業ができるようになったことと、アウトプットの質が上がって手戻りが減ったことによるものです。 また、今までAIエージェントへのプロンプトやセッション管理を通じた直接的なマネジメントから、AIエージェントの環境整備を行なって、セッション横断で効果のある施作に時間が割けている事もその要因の1つです。 さらに、並列数の上限も特になくなり、その日のPRレビューに割ける時間から逆算して実装タスクの数を決めるようになりました。 PRレビュー自体の認知負荷の軽減 詳細な設計ドキュメントがPRレビュー時にあることで、PRの内容をすぐに理解できるようになりました。今まではなんとなく頭にあった情報を思い出してレビューしていました。今は詳細な設計ドキュメントと照らし合わせながらレビューしているのでレビュー時のコンテキストスイッチによる負荷も小さくなっていると感じています。 現在直面している課題 設計書の細かい誤りの増幅 今回、主要なインターフェースの設計もAIに書かせていましたが、軽微な間違いを含んだまま実装フェーズに進み、そのままPR作成まで行われるケースがありました。一見些細なインターフェースの誤りでも、実装を通じて増幅され、結果として大きなズレにつながります。開発者が実装に伴走していれば、PR作成前の段階で気づけていたはずですが、今回のプロセスではPR作成後に初めて問題が表面化しました。設計ドキュメント自体のレビュー精度を高めるか、実装の途中段階でフィードバックを得る仕組みを整えることが今後の課題です。 設計とPRレビューのボトルネック化 よく言われていることではありますが、実装速度が上がったことで、その前後の設計とPRレビューの速度が開発スピード全体を決めるようになりました。 特に設計は、AIに手放しで任せるのは難しい領域が大きく、まだまだ時間がかかってしまうところです。 PRレビューについてはハーネスエンジニアリング*1によって不要になるという論調もありますが、本番環境で、お客様が利用しているサービスにPRレビューなしでマージするには課題が多いのも現状です。 まとめ AIエージェントに指示を出す前の段階で実装内容が自明になることで、AIエージェントの管理工数を削減し、開発者の認知負荷を軽減することができました。 この取り組みを通して確認できたことは、実装時にAIエージェントに指示内容を考えるよりも、設計時点で詳細な実装までイメージできるようなドキュメントを作成した方が効率が良いことです。 この設計ドキュメントを、どれだけ正確に無駄なく作れるかということが開発速度と品質を左右します。 AIエージェント自体をどれだけうまく活用するかということも現時点では重要ですが、それらはツール側の成熟によって自然と解決していきます。一方で設計はまだまだ人間が考えるべきところが多く残されていると思います。 もしチームで試すなら、最小限の構成としてUsecase Design Docの整備から始めることをおすすめします。ユースケースごとにサマリー・シーケンス図・実装状況チェックリストをまとめたドキュメントを1つ作り、それをコードベースの特徴に合わせて分割した上でAIエージェントに渡して実装させてみてください。設計の曖昧さがどこにあるかがすぐにわかり、改善サイクルが回り始めます。 このプロジェクトは、まだ進行中で試行錯誤しているところも多分にあります。プロジェクト完了後にふりかえり記事を出してその時に答え合わせをしようと思っています。 *1:<a href="https:/
- 生成AI
- DDD
- 設計