自己紹介

こんにちは！株式会社BuySell Technologiesテクノロジー統括本部所属、25卒エンジニアの大石・斎藤・宮川です。バイセルでは、入社後に毎年新卒エンジニアをチーム分けして「プロダクト開発研修」を実施しています。

2025年は新卒エンジニアが7人おり、今回は2チームに分かれて開発しました。本記事では、プロダクト開発研修とはどのような取り組みか、研修の中で各チームがそれぞれどんなプロダクトを開発したのかについて説明します。

プロダクト開発研修の概要

バイセルのプロダクト開発研修は、一般的な座学形式の研修とは異なり、新卒エンジニアが実際に手を動かしてプロダクト（サービス）を開発する、実践的な研修プログラムです。単に技術を学ぶだけでなく、業務上の課題解決や新たなプロジェクトの立ち上げを経験することを目的としています。プロダクト開発研修では、はじめにテーマが与えられた後、チームに分かれてゼロからのアイデア出し、要件定義、開発、発表と進んでいきます。今年のテーマは下記の通りでした。

[テーマ]
バイセルが過去に提供していたリアルタイム査定買取サービス「CASH」のコンセプトを再解釈し、AIを活用したユーザーの深い課題に対してクリエイティブなアイデアを提供するサービスを開発する

進める上でフィードバックを貰いたい場合や、懸念の解消をしたい場合は都度相談したり、毎日マネージャーとの夕会が用意され相談の機会をもらいながら進めることができました。

プロダクト開発研修の目的

プロダクトエンジニアとしてのものづくりを学ぶ

プロダクトエンジニアの仕事は、単にコードを書くことだけでなく、ユーザーが抱える本質的な課題を発見し、その課題をどのようなプロダクトで解決すべきか、解決までのプロセスを理解することが必要です。

リーダシップとチームワークを学ぶ

会社の仕事は1人で行うものではなく、チームで進めるものです。研修ではチームに分かれて開発を行い、各メンバーがチーム内でどのような役割分担で動き、リーダーシップを発揮するべきかを意識しながら開発に取り組みました。

AIネイティブエンジニアとしてAI活用の暗黙知/形式知を稼ぐ

開発時にCursorの利用が必須となっていたり、NoteBookLMやDevinの使用が可能だったりと、実際に自分たちでAIを使って試行錯誤する場を整えていただいた上で研修に臨むことができました。

Aチームの取り組みについて

このパートでは、Aチームの取り組みについて齋藤(@ShinShi)が紹介します。

Aチームは、レトロゲームの買取&レンタルプラットフォーム「Rentro」を企画・開発しました。

背景

バイセルが過去に提供していたリアルタイム査定買取サービス「CASH」のコンセプトを再解釈するというテーマの中で、私たちは自分たちが感じているニーズを引き出しながらトピックを出し合いました。その結果、若年層から中年層まで幅広くニーズのある「レトロゲーム」というトピックが挙げられました。

そこで私たちは、プロ研全体のミッションである「AI を活用してユーザーの深い課題に対しクリエイティブなアイデアを提供するサービスを開発する」という観点から、「CASH の体験をレトロゲーム市場に最適化し、AI査定によってレトロゲームに眠る価値を最大化しよう！」という思いからこのプロジェクトはスタートしました！

レトロゲームの課題

本プロジェクトを考える中で現状以下の課題あるとチームで考えました。 1. 本来は価値のあるゲームカセットが遊ばれず、死蔵されている 2. 昔の有名タイトルを遊びたくても、中古品は高価でハードルが高い

課題解決のための仮説と提供する価値

私たちは、売りたいユーザーと遊びたいユーザーを買取とレンタルで繋ぐことにより、課題を解決できると仮説を立てました。その後、「レトロを高く売りたいとレトロを安く遊びたいを繋ぐこと」というテーマを作成し、以下の価値を提供することで仮説の実現を図ることにしました。

売る側への提供価値

納得のいく価格での買取について、査定がどうやって決まったかがわかるシステムで、買取価格の理由をしっかり説明します。また、手間をかけずにレトロゲームを売ることができるよう、ネットで簡単に査定を申し込めて、めんどうな手続きなしでサクッと売れるサービスを提供します。

借りる側への提供価値

手頃な価格でレトロゲームを遊ぶことができるよう、定額制または個別レンタルで安価にゲームを提供します。また幅広いタイトルをオンラインで選ぶことができるかつ、郵送で受け渡しできるようにすることで、レトロゲームに手軽にリーチできるサービスを提供します。

※ゲームレンタル事業を行うためには、著作権の所有者からの許諾が必要です。この点に十分配慮しながら、研修・発表に取り組みました。

具体的なアプローチ

七日間という短い期間の中でアイデアを形にするため、私たちはGemini Deep Researchを使いながら要件を定義しました。まずターゲットを調査し、その結果をもとにコンセプトを定めたり、ビジネスモデルや機能・デザインについて話し合いました。開発の段階では、AIエージェント（GeminiやCursor、Devin）をフル活用してエージェントコーディングを実践し、Gemini APIを使って査定機能も実装しました。また定期的に開かれる朝会ミーティングや進捗確認ミーティングでは、Google Meetのメモ機能などのツールも活用しながら、効率よく進捗管理を進めていきました。

成果物

「Rentro」はレトロゲームをメインコンテンツとした「もう遊ばない、また遊びたいを叶えるプラットフォーム」がコンセプトのスマホ向けサービスです。

レトロゲームを売りたい人向けの買取機能と、レトロゲームを遊びたい人向けのレンタル機能を軸として開発しました。

主な機能

売る側の方はAIによるリアルタイム査定やレンタル期間の設定、価格交渉や売却の選択などが利用できます。

また、借りる側の方はゲームタイトルの検索や選択、オンライン決済手続きが行えます。

取引後は、期間内であれば自由に返却できたり、ミッションというアプリ内コンテンツをクリアするとポイントをゲットできる機能も用意しています！

さらに、マイページやお知らせ機能、レンタル品の破損保証（レントロ負担）など、共通の基本機能も充実しています。

技術的な内容

この「Rentro」の心臓部とも言えるのが、AIを活用した査定機能です。以下のようなロジックによって高精度なAI査定システムの実現に取り組みました。

AI査定の流れ

ユーザーがゲームタイトル選択後、カセットの写真とゲーム起動時の画面を撮影します。
ユーザ査定開始ボタンを押すとGemini APIを用いたAIが写真から傷、起動可否、真贋を判定し、査定額を算出・提示します。

具体的なロジック

当初は既存のオンラインフリマサービスの売却済みデータを参照して査定額を算出する方法も検討していました。しかし、要件を満たすAPIが存在せず、さらにスクレイピングを行うと規約違反となる可能性があったため、この方法は断念することにしました。

より現実的で安定した査定ロジックとして、私たちはゲームカセットの買取市場で高いシェアを持っている中古ゲーム販売店の販売価格を基準価格として設定し、AIの出力する価格情報に大きな差が生じにくい安定した価格データ算出するアプローチを採用しました。

買取価格の市場平均の算出 中古ゲーム販売店の販売価格をベースに、市場の買取価格相場を算出。
既存のオンラインフリマサービスでの推定販売価格の算出 個人間取引プラットフォームでの相場を分析し、市場平均からの倍率を設定。レトロゲームは希少性や状態によって価格の変動が大きいという特徴も考慮。
レントロでの買取価格の決定 「市場相場より高く買い取る」という目標を実現するため、競争力のある価格を設定。

さらに、査定精度向上のために以下を実施。 * タイトル毎に最低価格と最高価格を設定し、価格の安定化を図った。 * アップロードされた写真をもとに、AI（Gemini）がカセットの傷やゲーム起動写真の有無を判定し、必要に応じて減額を適用。 * タイトルと写真が一致しない場合は査定を拒否するなど、真贋判定も実施。 * 「販売時期が古いタイトルほど希少価値が高い」といった、ソフトごとの価格傾向をプロンプトに盛り込み、より適切な価格算出を目指した。 * AIからの出力は、後続の処理で利用しやすいようJSON形式に統一。

将来の展望・ネクストアクションと課題

今回の研修では、ここまでの内容しか実現できませんでしたが、今後はバックエンドの実装や査定AIのさらなる精度向上、ユーザーにとってより魅力的な価格設定の追求などにも取り組んでいきたいと考えています。また、通常とは異なるカセットの状態をどう扱うかを明確にしたり、エージェントコーディングをもっと効率的に進める方法も模索していく予定です。

Bチームの取り組みについて

このパートでは、Bチームの取り組みについて大石(@umaidashi18)が紹介します。

Bチームは、楽器のリユース&レンタルプラットフォーム「NoteRelic」を企画・開発しました。

背景

「物」で人と人が繋がる。そんな温かみのある体験を、無機質になりがちなオンライン取引にも持ち込みたい、というのが本プロジェクトの出発点でした。

そこで私たちは「楽器」のリユース＆レンタルプラットフォームを考えました。

楽器を選んだ理由は以下の3つです。

楽器は持ち主の思い出や想いが詰まりやすいアイテムです。演奏会での成功体験や、練習を重ねた日々など、単なる「物」以上の価値が宿っています。
楽器は単価が高く、買取・レンタルともに収益性が見込めます。
特に吹奏楽部の学生など、高額な楽器を購入できない層に対して、レンタルという形で音楽活動を支援できる点が魅力的でした。

現在のリユースプラットフォームでは、思い出や思い入れといった"物のストーリー"が十分に拾いきれていないのでは？という課題感がありました。特に、楽器のように持ち主の人生や想いが詰まったアイテムは、単なる取引以上の価値があるはずです。

査定の課題と仮説

この研修の題材となった「CASH」では、画像1枚だけでは十分な情報が得られないという課題がありました。死角になっている部分や、状態の詳細、画像からは読み取れない購入時期、購入金額などは、1枚の画像からは情報を拾いきれません。これを解決するため、AIが追加の質問を行うことで査定精度を向上させることを考えました。さらに、画像だけでなく追加質問や音声・テキストなど、多様な入力形式を用意することで、AIに目・耳・口を持たせ、より詳細な情報収集を可能にできると考えました。

また、AIの役割を情報収集エージェントと意思決定エージェントに分けることで、事実を探るAIと評価するAIの役割分担を明確にし、精度のブレを小さくすることを目指しました。これは、弊社の査定においても、査定に必要な情報を集める人とそれをもとに専門的な査定を行う人というように、役割分担がされているところから着想を得ました。

具体的なアプローチ

この研修では、すべてのプロセスにおいてAIネイティブエンジニアとして振る舞い、生成AIを最大限活用することを目指しました。

企画段階では、生成AIをふんだんに活用し、ブレスト的に出た意見をGeminiのDeepResearchを使用して非同期で実現可能性を確かめたり、Google Docsに集約した議事録やメモからNotebookLMを用いて意見をまとめるなど、効率的な議論を行いました。このアプローチにより、複数の企画を検討しながら、その可能性や問題点を非同期に調査でき、短時間で多くのアイデアを検討・ブラッシュアップできました。

また、三日目の中間発表で、弊社CTOのkyunsさんよりフィードバックをいただき、それまで考えていた企画を捨てて1から考え直すことになりました。それから、チームの方向性を決めるために3人で一人1つずつ、3つのプロダクトを同時に開発し、それをもとに話し合ってみることにしました。

全体で5日間という短い研修期間だったのでリスクある判断でしたが、生成AIで開発を進めることで方針の決定に必要なだけのプロダクトを1日で作成できました。その結果採択されたのが「NoteRelic」です。

成果物・機能紹介

「NoteRelic」は、楽器の買取（Appraisal）、楽器のレンタル（Melodyレンタル）、教育プラットフォーム（セッション）の3つの機能で構成されるサービスです。今回は、メイン機能の楽器の買取「Appraisal」を紹介します。

Appraisalでは、楽器の査定を「楽器査定AIエージェント」が行います。対象の楽器の画像をアップロードすると、査定されて価格が提示される機能です。査定の根拠として、画像から読み取れる傷や劣化などの情報を提示します。画像にブランドやロゴが含まれている場合は、それも評価します。

Additional Questions

前述の通り、画像1枚だけでは十分な情報が得られないという課題がありました。これを解決するため、AIが追加の質問を行うことで査定精度を向上させることを考えました。

最初に画像をアップロードすると、それだけではわからなかった情報や、画像から読み取れない情報をAIが人間に質問をします。それに人間が回答することを繰り返すことで、買取金額を決めるのに必要な情報を収集できます。

追加の情報をAIに与えると、情報収集エージェントがレポート化したものを元に、買取金額を判断するエージェントが動き出し、買取金額を決定します。

Additional Questionsを使用することで、限られた情報では足りない部分を追加で質問するようにし、現実の査定士のように「口」を持たせることに成功しました。

開発手法・技術選定

5日間という短い開発期間だったので、FE/BEの実装でNext.jsを使用しました。

開発の初期段階では、イメージを最速で形にするために bolt.new を使用しました。サービスの要件や機能をプロンプトとして用意したものを元に、大枠のシステムをbolt.newで作成し、ソースコードをダウンロードして続きをCursorで開発する手順を取りました。

Cursorに移ってからは、Vibe Codingを行い実装を進めました。

Playwright MCP を使用した UI/UX の改善

Playwright MCPを使用して、ペルソナになりきってテストを行い、UI/UXの改善を行いました。

企画段階で、楽器の買取を行うユーザー、レンタルするユーザー、教育プラットフォームを使用するユーザーで、3つのペルソナを想定していました。その時の議事録もGoogle Docsにまとめていたため、その情報を元にペルソナになりきって開発段階のUI/UXを評価するプロンプトを作成しました。

画像の @docs に記述されているコンテキストは以下です。

# 買取事業

`NoteRelic`が提供する楽器買取サービス

## サービス名

`NoteRelic 楽器Appraisal`のように表記

## サービスの概要

リユースで買い取った楽器をメンテナンスし、レンタル提供する

## 提供したい価値

- 簡単AI査定
  - 自分のPCやスマホで簡単にAIエージェントが楽器の価値を
- 安心の取引
  - AIエージェントが対話形式で査定結果をブラッシュアップしていく

## 出品の流れ
- 写真を撮影
- AI査定
- 査定結果確認
- 買取完了
- この流れが40~60代男性にわかりやすい感じにしたい

## ターゲット

### 出品ユーザー

- 年齢 : 40-60代
- 性別 : 問わない
- 背景 : 元楽団所属など、音楽経験がある層
- 特徴 : 
  - 使用していた楽器を手放したいと考えている
  - 楽器を単に手放すだけでなく、次の人にも使ってほしいと感じている
  - 楽器を手放せなくて困っているケースも多い
```

Playwright MCP の評価の結果、楽器の買取を行うユーザーが使用する画面では、ペルソナとして50代くらいの年齢層を想定していたため、画面の文字サイズを変更できるUIを提案したり、ペルソナに合わせて適切なトンマナを提案してくれたりしました。

そして、その評価ポイントを元に Cursor への改修指示プロンプトに変換し、評価を実際に反映しました。次の画像がそのBefore/Afterです。

Playwright MCP を使用して、Cursor が出力したプロンプト

<!-- 長いので折りたためるようにする -->

```markdown
# NoteRelic UI改善プロンプト

## コンセプト
「楽器の思いを次世代へ」というブランドコンセプトを体現し、ユーザーの感情的な価値と実用的な価値を両立させたUIデザインを目指します。

## デザインシステム

### 1. カラーパレット
```markdown
- プライマリーカラー: #8B4513（深い茶色）- 楽器の温かみと歴史を表現
- セカンダリーカラー: #DAA520（ゴールド）- 楽器の価値と輝きを表現
- アクセントカラー: 
  - #FFFFF0（アイボリー）- 背景色として使用
  - #4A90E2（ブルー）- CTAボタンやリンクに使用
- テキストカラー:
  - 見出し: #8B4513
  - 本文: #333333
  - リンク: #4A90E2
```

### 2. タイポグラフィ
```markdown
- 見出し: font-family: 'Tsukushi A Round Gothic', sans-serif
- 本文: font-family: 'Yu Gothic', sans-serif
- フォントサイズ:
  - h1: 2.5rem (40px)
  - h2: 2rem (32px)
  - h3: 1.5rem (24px)
  - 本文: 1rem (16px)
  - 小テキスト: 0.875rem (14px)
```

## コンポーネント改善指示

### 1. ヘッダーナビゲーション
```markdown
- 「楽器Appraisal」→「楽器の買取・査定」に変更
- 「Session」→「教育プラットフォーム」に統一
- ナビゲーションアイテムにホバーエフェクトを追加
  - 下線アニメーション
  - 色の変化: #8B4513 → #DAA520
```

### 2. CTAボタン
```markdown
- プライマリーCTA
  - サイズ: padding: 1rem 2rem
  - 背景色: #DAA520
  - ホバー時: 
    - スケール: transform: scale(1.05)
    - 背景色: #8B4513
  - アニメーション: transition: all 0.3s ease
  - シャドウ: box-shadow: 0 4px 6px rgba(139, 69, 19, 0.1)

- セカンダリーCTA
  - ボーダー: 2px solid #8B4513
  - 背景色: transparent
  - ホバー時:
    - 背景色: rgba(139, 69, 19, 0.1)
```

### 3. カード・セクションコンポーネント
```markdown
- 背景色: #FFFFFF
- ボーダー: none
- シャドウ: box-shadow: 0 8px 16px rgba(139, 69, 19, 0.08)
- 角丸: border-radius: 16px
- パディング: 2rem
- ホバー時:
  - シャドウ: box-shadow: 0 12px 24px rgba(139, 69, 19, 0.12)
  - トランスフォーム: translateY(-4px)
```

### 4. フォーム要素
```markdown
- 入力フィールド:
  - ボーダー: 2px solid rgba(139, 69, 19, 0.2)
  - フォーカス時: 
    - ボーダー: 2px solid #DAA520
    - シャドウ: 0 0 0 4px rgba(218, 165, 32, 0.1)
  - パディング: 0.75rem 1rem
  - 角丸: border-radius: 8px

- バリデーションスタイル:
  - エラー時:
    - ボーダー色: #FF4D4D
    - エラーメッセージ: 
      - 色: #FF4D4D
      - フォントサイズ: 0.875rem
      - アイコン: ⚠️
```

### 5. ローディング状態
```markdown
- スケルトンローディング:
  - 背景: linear-gradient()を使用
  - アニメーション: 2秒のパルスエフェクト
  
- プログレスインジケーター:
  - 色: #DAA520
  - サイズ: 48px
  - アニメーション: 回転アニメーション
```

## レスポンシブ対応
```markdown
- ブレイクポイント:
  - sm: 640px
  - md: 768px
  - lg: 1024px
  - xl: 1280px

- モバイル対応:
  - ナビゲーション: ハンバーガーメニュー化
  - グリッドレイアウト: 1カラムに変更
  - フォントサイズ: 
    - h1: 2rem
    - h2: 1.75rem
    - h3: 1.25rem
    - 本文: 1rem
```

## アクセシビリティ改善
```markdown
- ARIA属性の追加:
  - aria-label
  - aria-describedby
  - role

- フォーカス管理:
  - フォーカスリング: outline: 2px solid #DAA520
  - フォーカストラップ: モーダル表示時

- カラーコントラスト:
  - テキスト: WCAG AAA基準を満たすこと
  - ボタン: WCAG AA基準を満たすこと
```

## アニメーション・トランジション
```markdown
- 基本トランジション:
  - duration: 300ms
  - timing-function: ease
  
- ホバーエフェクト:
  - スケール: transform: scale(1.05)
  - シャドウ: box-shadow増加
  
- ページトランジション:
  - フェードイン/アウト
  - duration: 400ms
```

## エラーハンドリングUI
```markdown
- エラーメッセージ:
  - 背景色: rgba(255, 77, 77, 0.1)
  - ボーダー: 1px solid #FF4D4D
  - アイコン: ⚠️
  - パディング: 1rem
  - 角丸: border-radius: 8px
  
- リカバリーアクション:
  - 明確なアクションボタン
  - エラーの原因と解決方法の説明
```

## ユーザーフィードバック要素
```markdown
- レビュー表示:
  - スター評価
  - ユーザーアイコン
  - 検証済みバッジ
  
- 成功メッセージ:
  - 背景色: rgba(75, 181, 67, 0.1)
  - アイコン: ✓
  - アニメーション: フェードイン
```

楽器査定AIエージェント（AI査定士）の実装

今回のメインの機能である楽器査定AIエージェントは、Vibe Codingの流れのまま、Mastraなどのフレームワークを使わずに実装しました。今振り返ると、拡張性やデバッグのしやすさを考えるとMastraのようなフレームワークを使用するように指示しておけばよかったと思います。

後述するMCP Serverをエージェントに接続したいと考えていたので、AIエージェントを動かすライブラリは @modelcontextprotocol/sdk と相性の良い @anthropic-ai/sdk を選択しました。他のライブラリでも、 function callingをサポートしていましたが、流行りのMCPを想定していました。

LLMとのやりとりでは、画像やテキストに加えてそれまでの過程で生成したレポートをInputとして、 Outputに出力して欲しいレポートのフォーマットをJSON形式で指定し、パースして使用してUIに表示する方法を取りました。画像などのテキストではないマルチモーダルな情報は、一度テキストに変換してからコンテキストとして使用しています。

// このプログラムはイメージです。
const APPRAISAL_SYSTEM_PROMPT = `
あなたは楽器の査定専門家です。ユーザーから提供される楽器の画像や追加情報に基づいて、査定結果を出力してください。

渡されたレポートをもとに、査定金額を出力してください。

返答は以下のJSON形式で出力してください:

      {
        "estimatedValue": {
          "max": string, // Note: type is string, prompt used int
          "min": string, // Note: type is string, prompt used int
          "currency": string,
          "description": string
        },
        "reasoning": string,
      }

`;

// AIエージェントを初期化
const appraisalAgent = new AnthropicClient(ANTHROPIC_API_KEY, APPRAISAL_SYSTEM_PROMPT);

// 査定をする上で情報収集をするAIエージェントが出力したレポートをもとに、査定金額を出力するプロンプト
const appraisalPrompt = `
  査定をする上で情報収集をするAIエージェントが出力したレポートは以下の通りです。
  ---
  ${JSON.stringify(surveyJsonResponse.report)} // 情報収集AIエージェントの出力したレポート
  ---
  
  このレポートをもとに、査定金額を出力してください。
  システムプロンプトで指定されたJSON形式で再度出力してください。
`;

// 実際に査定をするAIエージェントにプロンプトを投げて、査定金額を出力する
const appraisalResponse = await appraisalAgent.processQuery(appraisalPrompt);

エージェントのマルチモーダル化「音」

楽器査定AIエージェントで画像を入力できるようにしましたが、より実際の楽器査定に近い体験を実現しようと考えました。そこで、私たちは「音」を査定材料として扱えるように、画像に加えて音声を入力できるようにしました。楽器を査定する上で、音声は重要な情報です。基本的にはAnthropicのモデルを使用していましたが、音声データを扱うためにこの部分だけGoogleのモデルを使用しました。

Additional Questionsで「口」を、画像認識によってAIに「目」を持たせたことに加えて、「音」を査定材料として扱えるようにしたことで、現実の査定士のように「耳」を持たせることに成功しました。

今後の展望・感想

今回のプロダクト研修で開発した「NoteRelic」は、楽器査定AIエージェントを実装し、現実の査定士のように「目」「耳」「口」を持たせ、新しいAI査定体験を提供しました。

これに加えて、より査定の精度を上げ、信頼できる査定士として仕上げるために次のようなことを考えています。

フレームワークの導入

今回の研修では、Mastraなどのフレームワークを使用せずに実装しました。しかし、そのようなフレームワークを使用することで、LLMのモデルの切り替えが容易になったり、MCPとの接続部分を抽象化したりと、さまざまな運用上のメリットがあります。A2Aのような技術が標準化されれば、その恩恵をフレームワークを通じて受けられるかもしれません。また、 Workflowの概念を使用すれば、ステップを定義してより成功度が高いエージェントを作成できそうです。

エージェントの多才化

今回AnthropicのSDKを使用した理由にもあったように、MCPでToolを与えることでエージェントをより多才にしようと考えていました。例えば、楽器の種類ごとに査定に必要な質問を提案するようなMCPや、弊社が蓄積している商材のマスタデータから情報を引きだすMCPなどです。

査定には大量の知識が必要ですが、それを効率的にコンテキストに含めるには、前段階で画像認識や音声認識だけを行うエージェントに切り分けることや、MCPで効率的に情報を引き出すことが必要です。

エージェントの有機的な動き

「楽器査定AIエージェント」のあるべき姿、理想を追い求めていき、役割ごとに分割して設計していった結果、次の図のような構成になりました。この図は、実際の弊社の組織体制に近いものになっており、人間が分業して1つの組織として有機的に活動しているように、エージェントも役割ごとに分業したほうが、有機的に動くのかもしれません。逆に現実の組織図を見ることで、あるべきエージェントの姿を見つけるヒントを得られるかもしれません。

終わりに

この研修を通じて、自分が求めるアウトプットをAIから得るために必要なトライアンドエラーのサイクルを学ぶことができました。具体的には下記のような学びを得ることができました

1つの作業を全てAIに任せて満足するアウトプットが出てこない場合、部分的にAIを活用して改善できる箇所がないか試してみる
なぜこのアウトプットが出たのかという理由を仮説立てて、プロンプトを再度考え直すことを繰り返す大切さ

また、研修の中で自分の考えることを正直に伝え合う中でぶつかることもありました。しかしそのおかげで、お互いの価値観や考え方を知ることができたので、新卒メンバー同士での仲をより深めることができました。

現在は研修が終了し、それぞれ別のプロジェクトに配属され、業務に取り組んでいます。

研修での経験を活かして、今後の業務でもプロダクトエンジニアとしての視点を忘れず、AI活用を積極的にしていきたいと考えています。

最後に、バイセルでは新卒エンジニアを随時募集しています。興味のある方は、採用サイトをご覧ください！

バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセルの新卒エンジニア研修〜AIネイティブエンジニアとしてのプロダクト開発〜

自己紹介

プロダクト開発研修の概要

プロダクト開発研修の目的

Aチームの取り組みについて

背景

レトロゲームの課題

課題解決のための仮説と提供する価値

売る側への提供価値

借りる側への提供価値

具体的なアプローチ

成果物

主な機能

技術的な内容

AI査定の流れ

具体的なロジック

将来の展望・ネクストアクションと課題

Bチームの取り組みについて

背景

査定の課題と仮説

具体的なアプローチ

成果物・機能紹介

Additional Questions

開発手法・技術選定

Playwright MCP を使用した UI/UX の改善

楽器査定AIエージェント（AI査定士）の実装

エージェントのマルチモーダル化「音」

今後の展望・感想

終わりに

自己紹介

プロダクト開発研修の概要

プロダクト開発研修の目的

Aチームの取り組みについて

背景

レトロゲームの課題

課題解決のための仮説と提供する価値

売る側への提供価値

借りる側への提供価値

具体的なアプローチ

成果物

主な機能

技術的な内容

AI査定の流れ

具体的なロジック

将来の展望・ネクストアクションと課題

Bチームの取り組みについて

背景

査定の課題と仮説

具体的なアプローチ

成果物・機能紹介

Additional Questions

開発手法・技術選定

Playwright MCP を使用した UI/UX の改善

楽器査定AIエージェント（AI査定士）の実装

エージェントのマルチモーダル化 「音」

今後の展望・感想

終わりに

エージェントのマルチモーダル化「音」