はてなブックマーク

こんにちは。CADDi Quoteのプロダクトデザイナー山崎文菜 (@ayana_yamazaki) です。 去年までは、Figmaでデザインファイルを完成させて、エンジニアに渡す。それが当たり前だと思っていました。 実装に入ってからエンジニアに「ここのデフォルトの並び順、昇順にしてますけど大丈夫ですか？」と聞かれ、Figmaを見返す。あっ決めてなかった…！ デザインファイルではUIが完成していたのに、実はUXの意思決定が終わっていなかった… この記事は、コードが書けないデザイナーが、エンジニアの伴走を受けながらClaude CodeでStorybookを書き、プロダクトマネージャーとのウォークスルーで130件以上の仕様課題を実装前に発見・解決した実践録です。 Figma→実装のハンドオフで手戻りに苦しむデザイナーやエンジニアに向けて、何をやり、なぜ仕様の抜け漏れを実装前に潰せたのかをお伝

※本記事は、こちらの記事を和訳したものです stratomere.com 序章 航空機が音速を超えると、衝撃波が発生する。衝撃波は周囲の空気が伝わる速度よりも速く移動するため、周囲の空気がその擾乱を吸収しきれず、不連続性が生じる。これがソニックブームである。 池の水面に広がる波紋のように、衝撃波は外側へと伝播し、その影響は距離とともに薄れていく。AIサービスの需要は、技術サプライチェーンが吸収できる速度をはるかに超えて拡大している。マイクロソフトのCEOによれば、当初は大規模な言語モデルの学習と実行にGPUが必要だったが、今ではそれらを動かすためのエネルギーが課題となっている。こうした波紋は私たちの日常生活にも波及し、データセンターの需要が電力網の容量を圧迫するにつれて電気料金が高騰し、限られた半導体供給を巡って家電製品同士の競争が激化するにつれて、家電製品の価格も上昇している。 物理的な

こんにちは、キャディで Quote というアプリケーションを開発している plant こと石田 (@plant_ja) です。 ハーネスエンジニアリングという言葉を目にする機会が増えてきましたね。「何をやるべきか」については OpenAI の Harness engineering: leveraging Codex in an agent-first world や逆瀬川さんの Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス が非常に参考になります。 本記事では「何を」ではなく「どう始めるか」に焦点を当てています。Claude Code の場合だと Rules、Skills、Hooks、Subagents、さらには custom linter や pre-commit や pre-push、これらの構成要素を眺

はじめに 何が辛かったのか 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 解決方針 詳細な設計ドキュメントの作り込み Usecase Design Doc 細かい実装指示・計画・実行をAIエージェントに委譲 タスクの分割方針 AIエージェントへの実装委譲 AIのお世話からの解放 - 得られた成果 開発速度の向上 PRレビュー自体の認知負荷の軽減 現在直面している課題 設計書の細かい誤りの増幅 設計とPRレビューのボトルネック化 まとめ はじめに こんにちは。CADDi Quoteのサーバーサイドの開発を担当しています、majimacchoです。私たちのチームでは全員がAIエージェントを活用して実装しPR作成まで行なっています。 私自身を含め、全く自分でコードを書かなくなったメンバーもいます。AIエージェントを使っ

こんにちは。キャディ株式会社の Analysis Platform Group でソフトウェアエンジニアを務めている廣岡です。 業務としては、キャディの様々なサービスの裏側で稼働する機械学習解析のインフラやバックエンドの開発、アプリケーションとの橋渡しなどに取り組んでいます。最近では下記記事で紹介したようなプロジェクトに取り組んでいます。 zenn.dev 今回は私たちのチームで作り、開発業務の中で利用している Claude Skills について紹介します。 TL;DR Claude Skills を使って ML 開発における定型作業を効率化した 推論サーバー構成やログ調査、インフラ構築など 5 つのスキルを整備した エンジニアリングバックグラウンドが異なるチームで、開発効率が大きく向上した 背景 キャディの ML システムでは図面解析のための機械学習モデルを多数開発・運用しています。A

はじめに はじめまして。2025年10月にキャディ株式会社へ入社した、エンジニアリングマネージャー（EM）の蟹澤です。 先日、リードアーキテクトの小森（@littleforest12）が、設計フェーズにおける不確実性への向き合い方を綴った記事（https://caddi.tech/2025/12/16/112311）を公開しました。本記事は、同じプロジェクトをプロジェクトマネージャー（PM）として担当した私からの、アンサーソングです。 本プロジェクトは、今後すべてのチームが依存する、キャディの根幹にズブズブと手を入れるような基幹機能開発です。わずかな設計ミスが将来の全社の開発速度を左右しかねない、失敗の許されない横断プロジェクトです。「幅広くキャディを理解する機会として」という意図でのアサインでしたが、当時の私はドメイン知識ゼロ、入社2週間目。正直に言えば「ヒリヒリする打席がきたなあ」と興

はじめに こんにちは、2月にSenior Research Engineerとしてキャディに入社した福原です。現在、キャディでリサーチ組織を本格的に立ち上げています。 「リサーチ組織」と言っても、単に研究を行なって論文を書くことだけが我々の目的ではありません。キャディが掲げる「モノづくり産業のポテンシャルを解放する」というミッションを実現するために、最先端の技術を研究し、それをプロダクトの価値として実データ上で検証するところまでやり切る — それがこの組織の存在意義です。 この記事では、キャディが取り組んできた、あるいはこれから挑もうとしている技術課題が、Computer Vision（CV）やAIの分野で盛んに議論されている難問といかに深く重なっているかを、最新の研究動向とともに紹介します。 結論を先に述べると、キャディのプロダクトが行なっている「製造業の図面・3DCAD・仕様書といった

こんにちは。Data Platform部に専任QAとしてジョインし、現在QAチームの立ち上げに奮闘しているokanです。 皆さんはQAチームの立ち上げと聞いて、どのような状況を想像しますか？ 「テストが全くない無法地帯に秩序をもたらす」「バグだらけのプロダクトを立て直す」…。 私も最初はそんな火消しのようなミッションを想像し、「これまでの経験を活かして、バリバリテストを回すぞ！」と意気込んでいました。 しかし、いざData Platformチームに入ってみると、そこには嬉しい想定外が待っていたのです。 今回は、すでにエンジニアの品質意識が高い組織において、立ち上げ直後のQAがどのように立ち回り、価値を出そうとしているのかという、現在進行形のリアルな試行錯誤をお届けします。 【本記事の主張（お伝えしたいこと）】 優秀なエンジニアが揃う組織において、QAはバグを見つけるテスターやプロセスを守ら

こんにちは、キャディで Quote というアプリケーションを開発している plant こと石田 (@plant_ja) です。 Claude Code はあくまでツールであって、使い方によって大きくパフォーマンスが左右されるように感じています。 今回はコンテキストという観点から Claude Code の動作原理を紐解きながら、我々が期待するコードを安定して出力してもらうためのコンテキストマネジメントの理論と実践について思いを馳せてみようと思います。 想定読者 Claude Code を日々使っているが、AI があまり賢くないように感じる人 Claude Code を使い始めたばかりの人 日々の開発で Plan Mode を活用しているが「なんで Plan Mode だとうまくいくんだろう」って思っている人 チームメンバーにコンテキストマネジメントの重要性を説明したい人 想定読者 この記事

Control Plane 部 認証認可グループ（※1）のエンジニアリングマネージャーをしている先山(@ksakiayma134)です。 現在キャディは、CADDi Drawer と CADDi Quote といった複数のアプリケーションをお客様へ提供する「コンパウンド戦略（マルチプロダクト化）」を推し進めています。 こうした複数アプリケーションを展開するアプリケーションアーキテクチャでは、共通利用する機能をプラットフォームレイヤーとして切り出すことが一般的です。私たちも認証・認可機能をプラットフォーム化し、各アプリ開発者へ提供しています。 本記事では、現在のキャディの認証認可を支えているシステム群についてご紹介します。 Control Plane 部について 一般的な説明 まず、「Control Plane」という言葉について簡単に触れておきます。 一般的に SaaS アーキテクチャにお

こんにちは、キャディで Quote というアプリケーションを開発している plant こと石田 (@plant_ja) です。 この記事は キャディ株式会社のアドベントカレンダーの20日目の記事です。 adventar.org 今回は AI コーディングを図で表現しつつ、我々が期待する成果物を出力してもらうための様々なアプローチに思いを馳せてみようと思います。 ゴール設定 コーディングエージェントへの期待と現実 AI が書くコードを「確率密度関数」として考えてみる アプローチ1: 解空間の確率密度を上げる 解空間の定義 解空間のインプットコストとどう向き合うか コンテキストの増大 アプローチ2: 解空間外の出力を抑制する linter による抑制 タスクの分解によるコード出力バリエーションの絞り込み 2つのアプローチの比較 終わりに ゴール設定 まず、解きたい問題があります。例えば「新規ユ

Control Plane部の小森 (@littleforest12)です。 こちらはキャディ株式会社のアドベントカレンダーの16日目の記事です。 最近、社内でこれまでの中では比較的大規模な開発プロジェクトのリードアーキテクトを拝命しまして、奔走しています。 プロジェクトはようやく立ち上がってきたところですが、アーキテクトとしての考えをメンバー向けに発信しようと書きはじめたことを、せっかくなのでTech Blogにしたためたいと思います。 背景 私たちは「製造業AIデータプラットフォーム CADDi」としてプロダクトを展開しており、プラットフォームの一部としてCADDi DrawerやCADDi Quoteといったアプリケーションを提供しています。 もちろん、これらは開発から運用まですべてが内製です。 通常は、各アプリケーションやプラットフォーム横断で、おおむね4〜8名程度のチームに分かれ

この記事は CADDi Tech/Product Advent Calendar 2025 14日目の記事です。 Executive Summary 生成 AI アプリで評価プロセス改善 PoC をした 評価制度をアセット化し、生成 AI ツールを組み合わせることによって、評価プロセスを支援した 「メンバーの思考の整理」「メンバーからマネージャーへのコミュニケーションの改善」というポジティブな効果が得られた （画像は実際のシステム、入力されているテキストは架空の人物・チーム・業務） はじめに キャディのエンジニアリングマネージャーの橋本です。 突然ですが、この記事を読んでくださっている皆さんにひとつ聞きたいことがあります。あなたの会社にある評価プロセス、たとえば目標設定、月次振り返り、期末の自己評価、評価フィードバックなどは、あなたの仕事にとってポジティブに働いているでしょうか？ 評価プロ

この記事は CADDi Tech/Product Advent Calendar 2025 の9日目の記事です。 Data Management チームの森岡です。要らなくなったものをすぐに捨てられるデータ基盤を意識して日々開発しています。 この記事では、プロダクトの成長に伴って直面した Terraform State の肥大化問題を Terramate を活用して解決した実践的な事例を紹介します。 はじめに キャディでは、製造業AIデータプラットフォームを開発しています。 我々の顧客には大手エンタープライズ企業も多く含まれるため、セキュリティとデータガバナンスは最優先事項です。 その一方で、キャディには、カスタマーサクセスや、エンタープライズソリューションチームが存在し、顧客への価値提供に取り組んでいます。 これらのチームでは、顧客への提供価値を最大化するために、BigQuery 上のデ

こんにちわ、Core Infrastructure チームの前多です。膝が痛い。 こちらはキャディ株式会社のアドベントカレンダーの3日目の記事です。 先日、弊社の同僚からCADDiのアーキテクチャと開発組織に変遷に関する発表が行われました。 14:55〜E会場 キャディ株式会社/CADDiの発表資料 「事業状況で変化する最適解。進化し続ける開発組織とアーキテクチャ」を公開しました🙌 よろしければお手元でもご覧ください！https://t.co/DrStp16fon #アーキテクチャcon_findy— CADDi.tech (@CaddiTech) 2025年11月21日 私たちのプロダクトのインフラは Terraform で構成しています。 プロダクトがロンチされてから3年以上経っていて、その発展に従ってTerraformの構成も大きく変化してきました。 この記事ではプロダクトのTer

こんにちは、Data&Analysis部(D&A)です。 D&Aでは週1回、機械学習の勉強会を開催しており、本記事は、勉強会の内容を生成AIを活用して記事にまとめたものです。 ※勉強会内容公開の経緯はこちら ※過去の勉強会は「社内勉強会」タグからもご覧いただけます。 はじめに：我々が直面していた課題 現在、我々はドキュメントを解析するプロジェクトを推進しています。その中で以下のような壁に直面しました。 フォーマットの多様性 PDF、Word、PPT、スキャン画像など、形式がバラバラなドキュメントの前処理が大変 構造情報の損失 テキスト抽出時にレイアウト、表、図が崩れて意味が失われてしまう 既存ツールの限界 商用ツールは高価かつクラウド必須の制約があったり、OSSでは品質・機能不安があったり それらを解決するため、Doclingが効果がありそうだと分かり、その性能検証を進めることにしました。

はじめに 「Excellence」とは、スキルではありません。 それは「明日を今日よりも良いものにできる」という信念の表れであり、自らの選択です。 こういった考えは、一見楽観主義のようにも映ってしまいますが、そのような受け身なものではありません。そこには強い意志を伴う決断が必要不可欠です。なぜなら、私たちは生まれつき楽な方へと流されやすい生き物だからです。 私たち人間は習慣の生き物であり、安定や現状維持を好みます。 私が採用の意思決定において「カルチャーフィット」という言葉を使わないのは、これが理由です。この言葉を使うこと自体に異議を唱えるつもりはありません。スタートアップという環境において、共通の価値観を持ち、同じ目標を達成したいと願うことは極めて重要です。しかし、この言葉には、変化への無言の抵抗や現状維持を望むニュアンスが潜んでいます。 だからこそ私は「カルチャーインパクト」という言葉

Intro Excellence is not a skill. It is a choice, and an expression of belief that tomorrow can be better than today. This kind of optimism is not passive – it requires deliberate decisions, because it often goes against our natural inclination toward comfort. We humans are creatures of habit, and we are drawn to stability and the status quo. It is the reason I do not use the term “cultural fit” wh

こんにちは、Data&Analysis部(D&A)です。 D&Aでは週1回、機械学習の勉強会を開催しており、本記事は、勉強会の内容を生成AIを活用して記事にまとめたものです。 ※勉強会内容公開の経緯はこちら ※過去の勉強会は「社内勉強会」タグからもご覧いただけます。 はじめに 12-Factor Agentsとは 12-Factor Agentsを書いた背景 12-Factor Agentsの概略 Agentは様々な経路から入力を受けつけ、出力は構造化されている プロンプトやコンテキスト、制御フローをコードとして管理する 状態管理をし、人の介入やエラー修正を可能にする 小さなエージェントを複数構築し単一の結果を得られるようにする まとめ はじめに 今回の勉強会では、信頼性・保守性の高いLLMアプリケーション構築の原則として提唱された12-Factor Agentsを紹介します。動機としては

こんにちは、 Drawer Growth グループの大木です。 最近（というかずっと）AIが熱いですね、エージェントモデルが出てきてコーディングの常識がまた一つ変わろうとしているように感じます もちろんキャディでもAIツールは多数導入しており、この変化に追従するために組織としてAI活用に積極的に取り組んでいます 今回はその取り組みの一環として、会社内でVibe Coding Hackathonを開催しましたのでご紹介します！ きっかけ 今年2025年の2月頃から、有志を募ってAIツールを積極的に検証していました 初期ではツールごとに推進者を立て、実際に試験的に使ってみて費用感や効果・ベスプラなどを調査して全社に展開していくような動きをしていました ある程度全社的にもツールの導入が終わり使用フェーズに入ったところで、 もっと利用を促進させる AI活用のナレッジを組織に貯める ために、今回のハ

こんにちは、Drawer Growthグループ ソフトウェアエンジニアの内田(id:usadamasa, @usadamasa)です。弊社ではApache Icebergの活用*1とともに、一部のアプリケーションにJavaを導入しています。今回は、システムアーキテクチャから一段レイヤを下げてアプリケーションレベルのお話しをしたいと思います。 アプリケーションアーキテクチャの設計と運用課題 アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。 しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要が

こんにちは、 Drawer Growth グループの高藤です。先日、弊社の江良が活用事例として取り上げた Apache Iceberg の活用事例にあるよう、キャディでは Apache Iceberg を採用したデータレイクハウスの構築を行っています。前回に引き続き今後計画していることについて紹介したいと思います。 先日の江良がまとめた活用事例にもある通り、現在構築しているデータレイクハウスでは、お客様が手元にある構造化データに対して、お客様自身でデータをアップロードし CADDi Drawer 内で利用できるようにしています。データレイクハウスを通じて、お客様固有のデータを CADDi Drawer 内で大量に扱うことができるようになりました。 その一方で、まだまだ解決しないといけない課題もあります。前述の記事のなかでも触れられているとおり、「全社を横断したプラットフォーム」への取り組み

はじめに こんにちは、Data&Analysis部（以下、D&A）所属の宇佐見です。D&Aは弊社が展開する製造業AIデータプラットフォームCADDiに集約されたデータを解析して価値を創造することがメインの業務です。 解析にはもちろん機械学習を用いることが多く、メンバー間の知見共有が求められます。そこで始まったのが機械学習勉強会だと思われます。 思われます、と書いているのはなぜかというと、この勉強会は非常に歴史が長く、2021年の1月ごろから続いているものだからです。 私は2024年8月入社なので初めの頃の雰囲気は不明ですが、おそらくそういう課題はどこのチームにもあるものなのでそういうモチベーションがあったのではないのかなと推察しています。 さて、現在の機械学習勉強会はどのような運用をしているかというと、インフレして負担にならないよう、ゆるく機械学習に関係のあるトピックならなんでも共有しよう

概要 LLM as a Judgeとは？ なぜLLM as a Judgeが注目されているのか？ LLM as a Judgeのプロセス プロンプト設計の詳細 モデル選択の詳細 後処理の詳細 LLM as a Judgeの適用シナリオ 評価パフォーマンス改善戦略 LLM評価者の評価 課題と今後の展望 結論 余談 概要 2025年1月10日に行われたキャディ機械学習勉強会でのLLM as a Judgeに関するレビュー論文の紹介と議論を踏まえ、本記事はA Survey on LLM-as-a-Judge を読み、内容をまとめ、LLMを評価者として用いる概念、そのプロセス、利点、課題、将来展望について解説したものです。 LLM as a Judgeとは？ 従来、専門家が担当していた評価業務をLLMに代行させるという試みです。これにより、評価プロセスの効率化、コスト削減、一貫性の向上が期待されて