Inside Sakana AI's Product Team


Switch to the Japanese section - 日本語版はこちら


Sakana AI’s Product Team turns the technology created by our research teams into products and delivers them to the world. Many of the questions we hear from candidates in casual interviews and throughout the hiring process turn out to be the same ones. In this article, we’ve gathered the Product Team’s culture and our answers to those frequently asked questions, based on interviews with team members.

Members who contributed to this article


The Product Team in Numbers

First, let’s look at the Product Team through data. Below is a breakdown of the team as of September 2026. The team brings together a range of roles, including product managers, engineers, designers, and sales, and a range of nationalities.


How We Work

Do I need to come into the office? Can I work remotely?

As a team, we encourage face-to-face communication, but how often people come in varies. Some members are in the office nearly five days a week, and there is considerable flexibility in working hours. For example, some members arrive between 11:00 and 12:00, or leave around 17:00. There are no fixed core hours; 10:00–19:00 is the standard workday. Rather than imposing a single way of working, we expect people to take the initiative themselves. As long as you stay productive, you’re free to work how you like. That said, the team operates primarily on-site, so if you work remotely, you’re expected to close any information gaps on your own.


How many meetings are there?

As the team has grown, the all-hands Product Team meeting now happens about once a month. Beyond that, each team sets its own cadence: some run a short daily sync (Sakana Chat / Translate), while others hold a weekly retrospective (Sakana Marlin). There is a separate regular meeting where each product reports its KPIs and progress to a group that includes Sota, our Head of Product, and there are also sessions to discuss product direction directly with David, our CEO.


Is internal communication in Japanese or English?

On teams with English speakers, English is encouraged for both documentation and spoken communication. That said, Japanese speakers are not required to speak English with one another. What matters is that communication across the team as a whole runs smoothly.


What tools do you use?

Slack, Claude Code, Codex, Figma, Confluence, Google Workspace, Jira, Devin, GitHub, Typeless, Adobe Creative Cloud, among others. Given the nature of the Product Team, we actively encourage trying out new products, and it’s easy to bring in the tools you want to use.


Autonomy and Roles

How much autonomy do I get?

This is the question engineers ask most often. The short answer: a lot. That said, the broad direction is set at the company, team, and product levels, and we don’t expect anyone to unilaterally go off in a different direction. Communicating with the people around you and getting alignment before moving forward is essential.

As a concrete example, one of our Applied Research Engineers (AREs) has taken on something like a PM role for the API Platform based on their own interests. The scope of work you’re trusted with is broad, and your opinions carry weight.

The same goes for Software Engineers (SWEs). Beyond designing and building everything from infrastructure to application code, SWEs handle whatever software development requires: monitoring, QA, testing, data governance, security, and communication with stakeholders. Because we have relatively few SWEs for the number of products we run, the environment may suit someone who works broadly across the full stack better than someone who wants to specialize deeply in a single area.


What’s the difference between an ARE and a SWE?

AREs build out the core technical components of a product; SWEs build the system around them. SWEs focus on laying the foundations for agent systems and on the broader software infrastructure. The boundary isn’t rigid, though. The two roles give each other feedback as they work, and the division of responsibilities shifts flexibly with team needs and individual preferences.


How do AREs on the Product Team differ from AREs on the Applied Team?

For AREs on the Applied Team, what matters is building agent systems tailored to a specific customer’s requirements. AREs on the Product Team, by contrast, build products for a broad user base, so they place more emphasis on generality when benchmarking and developing AI technology. Product Team AREs also tend to work more closely with the Research Team.


How do you work with the Research Team and the Applied Team?

The basic flow is that the Research Team creates the technology behind our products, and the Product Team connects it to business use cases. But responsibilities aren’t strictly separated: the Product Team sometimes customizes the technology, and the Research Team sometimes works directly on products. We collaborate with the Applied Team when a Product Team product looks likely to help solve a customer’s problem. The setup we’re aiming for is one where the Product Team builds general-purpose products, and the Applied Team customizes them further to deliver distinctive value to each client.


A Day in the Life

Here’s what a typical day looks like for an ARE.

Time Activity
10:00 Arrive at the office. Work through emails and messages that came in overnight.
11:00 Meeting with a company that reached out to us. Discuss the fit between their use case and our product, and agree on next actions toward adoption.
12:00 Join Fish Lunch and catch up with colleagues from other parts of the company.
13:00 Analyze user feedback and fix bugs. Map out the plan for the next three months and think through system architecture.
16:00 Attend the Research Team’s meeting to hear about development status and upcoming plans.
17:00 Verify the bug fix in staging. Coordinate the timing of the production release with other members.
18:00 Discuss a side project with the intern working on it.
20:00 Leave the office.


Culture and Team Atmosphere

What kinds of backgrounds do people have?

Most AREs used to come from research-oriented backgrounds, such as corporate R&D, but that’s less true recently. If there’s one thing most AREs have in common, it’s a background in computer science. For other roles, many members joined from companies that build products, such as SaaS companies.

Many members also simply love making things. Outside of work, you’ll find people designing their own caps, T-shirts, and stickers featuring our product logos. These are people who enjoy building something with their own hands.

The makeup of the team is changing, too. We’ve recently welcomed more members from outside Japan, and the team has become more diverse. We also plan to add sales and marketing roles going forward.


What’s the team atmosphere like?

With many members in the office, casual conversations happen naturally. Team lunches are frequent but never mandatory. Every so often, there’s even a volleyball tournament.


The Hiring Process

What do you look for in the technical problem set?

Applied Research Engineer

In the ARE assignment, we look beyond whether you can solve the problem. We want to see whether you understand the strengths and weaknesses of each technique and can explain them in your own words. Product development means making decisions every day amid a tangle of constraints (accuracy, latency, cost, UI/UX), so the ability to judge quickly and well is essential. We also check whether you can design an appropriate evaluation for the task. Measuring any capability is inherently hard, and building convincing benchmarks that speed up the product development cycle is a key part of the job.

Software Engineer

Using AI in development has become the norm, and what matters to us is whether you can take responsibility for your own decisions and actions. We look for people who don’t hand everything off to AI, but learn alongside it and use it to grow. In the technical assignment, we expect a baseline level of quality in the final output, and beyond that we place weight on whether you can explain, in your own words, why you chose the technologies and design you did and how the system could evolve.


Who We Want on the Product Team

Finally, here is the kind of person Sota Omura, our Head of Product, hopes to work with:

The thinking behind this profile is discussed in depth in a previous interview. We encourage you to read it as well.

Blog: From Japan, Products the World Will Use: An Interview with Sakana AI’s Head of Product Development





The Product Team is currently hiring for ARE / SWE / Data Engineer / PM / Designer / Sales roles, among others. If any of this has piqued your interest, we’d love to hear from you.

Product Team Open Positions



Inside Sakana AI’s Product Team


Sakana AIのProduct Team (PD Team)は、研究チームが生み出す技術をプロダクトとして世に届けるチームです。カジュアル面談や選考の場で候補者の方からいただく質問には、実は共通するものが多くあります。この記事では、PD Teamのカルチャーや面談でよく聞かれる質問への答えを、メンバーへのヒアリングをもとにまとめました。

ヒアリングに協力してくれたメンバー


数字で見る Product Team

まずは、PD Teamがどんなチームなのかをデータで見てみましょう。以下は2026年9月時点のメンバー構成をまとめたものです。プロダクトマネージャー、エンジニア、デザイナー、セールスと多様な職種のメンバーが集まり、国籍もさまざまです。


働き方について

出社は必須ですか? リモートはできますか?

チームとしては対面コミュニケーションを推奨していますが、出社頻度は人によります。ほぼ週5で出社するメンバーもいれば、11〜12時の出社、17時頃の退勤など、働く時間の調整はかなり利きます。コアタイムがはっきり決まっているわけではなく、10:00〜19:00が標準的な勤務時間です。働き方を画一的に縛らず、自ら動けることを前提としています。生産性が保てるのであれば働き方は自由ですが、チームの運営はオンサイトを中心に行われるため、リモートで生じる情報の差分は自分自身で埋めにいくことが期待されます。


ミーティングはどのくらいありますか?

人数が増えてきたこともあり、PD Team全体の定例は月に一度ほどあります。あとはチームごとに設計が異なり、毎朝短めのsyncを設定しているチーム(Sakana Chat / Translate)もあれば、週次で振り返りMTGを設定しているチーム(Sakana Marlin)もあります。各プロダクトのKPIや進捗をHead of Productの大村を含めて報告する定例は別途あり、CEOのDavidと直接プロダクトの方向性を議論する場も設定されています。


社内のコミュニケーションは日本語ですか? 英語ですか?

英語話者のいるチームでは、ドキュメント・口頭コミュニケーションともに英語が推奨されています。ただし日本語話者同士の会話まで英語が強制されることはありません。重視されているのは、全体のコミュニケーションがスムーズに進むことです。


どのようなツールを使っていますか?

Slack、Claude Code、Codex、Figma、Confluence、Google Workspace、Jira、Devin、GitHub、Typeless、Adobe Creative Cloudなどです。PD Teamという特性上、新しいプロダクトを積極的に使っていくことが奨励されており、使いたいツールを使いやすい環境です。


裁量とロールについて

裁量はどのくらいありますか?

エンジニアの方から最もよく聞かれる質問です。結論から言えば、裁量は大きいチームです。ただし、会社・チーム・プロダクトそれぞれのレイヤーで大きな方針は決まっており、そこから外れることを一人で勝手に進めることは想定されていません。周りとコミュニケーションをとり、合意を得てから進めることが大切です。

実際に、Applied Research Engineer (ARE)のメンバーが興味関心に応じてAPI PlatformのPdMのような役割を担っている例もあります。幅広く業務を任せてもらえ、意見も通りやすい環境です。

Software Engineer (SWE)も同様で、インフラからアプリケーションの設計・実装はもちろん、モニタリング、QA、テスト、データガバナンス、セキュリティ、ステークホルダーとのコミュニケーションまで、ソフトウェア開発に関わることはなんでも担当します。プロダクト数に対してSWEが少ないため、どこかの領域を専門性高く深掘りするタイプよりも、フルスタックに広くやれる人に向いている環境かもしれません。


AREとSWEはどう違うのですか?

プロダクトのコアとなる要素技術を作り込むのがARE、システムを作り上げるのがSWEです。SWEはエージェントシステムの土台構築や、より外側のソフトウェア基盤の整備が中心になります。ただし境界が明確に決まっているわけではなく、お互いにフィードバックしながら業務を進めており、担当範囲はチームの状況や個人の希望によって柔軟に変わります。


PD TeamのAREとApplied TeamのAREはどう違うのですか?

Applied TeamのAREは、顧客の具体的な要件に合わせてエージェントシステムを作り込むことが重要です。一方PD TeamのAREは、幅広いユーザーに使ってもらうため、汎用性をより意識してベンチマーキングやAI技術の作り込みを行います。また、PD Teamの方がResearchに近い距離でやり取りすることが多くなる印象です。


Research Team、Applied Teamとはどう関わっていますか?

Research Teamがプロダクトの源泉となる技術を生み出し、PD Teamがそれをビジネスユースケースに紐づける、という進め方が基本です。ただし職責が完全に分かれているわけではなく、PD Team側で技術をカスタマイズすることも、Research Team側でプロダクトに手を入れることもあります。

Applied Teamとは、PD Teamのプロダクトが顧客の課題解決に役立ちそうな場合に連携して進めます。目指しているのは、PD Teamが汎用的なプロダクトを作り、Applied Teamがそれをさらにカスタマイズして、案件先の企業に特別な価値を届けられる体制です。


ある一日のスケジュール

AREのとある一日を紹介します。

時刻 内容
10:00 出社。届いていたメールやメッセージを処理。
11:00 問い合わせのあった企業とMTG。ユースケースとプロダクトのフィットを議論し、導入に向けたNext Actionを決める。
12:00 Fish Lunchに参加し、普段関わらない社員と交流。
13:00 ユーザーフィードバックの分析、バグ修正。今後3ヶ月のプランを整理し、システムアーキテクチャを検討。
16:00 ResearchチームのMTGに出席し、開発状況と今後のプランをヒアリング。
17:00 バグ修正をステージング環境で動作確認。本番反映のタイミングを他メンバーと調整。
18:00 サイドプロジェクトについて担当インターンと議論。
20:00 退勤


カルチャー・チームの雰囲気

どのようなバックグラウンドの人が多いですか?

AREは研究寄りのバックグラウンド(企業のR&D出身)が多かったものの、最近はそうとも限りません。共通点を挙げるならComputer Scienceのバックグラウンドで、これは多くのAREが持っています。それ以外の職種は、SaaSなどプロダクトを作っている会社からの転職が多いです。

また、ものづくりそのものが好きなメンバーが多いです。仕事の外でも、自分たちのプロダクトのロゴを入れたオリジナルキャップやTシャツ、ステッカーを自作する人など、手を動かして何かを形にすることを楽しんでいるメンバーが集まっています。

チームの構成も変わってきています。最近は日本以外の国から来たメンバーが増え、多様な環境が整ってきました。今後は営業やマーケティング職も増やしていく予定です。


チームの雰囲気は?

出社しているメンバーが多いこともあり、雑談は自然発生的に起きています。チームランチもしばしばありますが、強制ではありません。たまにバレーボール大会が開かれることもあります。


選考について

選考課題ではどこを見ていますか?

Applied Research Engineer

AREの課題では、単に解けるかどうかではなく、それぞれの技術の強み・弱みを理解し、自分の言葉で説明できるかを見ています。プロダクト開発では、精度、所要時間、価格、UI/UXなど様々な制約が複雑に絡み合う中で日々選択を続ける必要があり、迅速かつ適切な判断ができるかが問われます。また、タスクに対する評価設計を適切にできるかも確認しています。何かの能力を評価することは本質的に難しく、説得力のあるベンチマークを構築してプロダクトの開発サイクルを加速させられるかが大事だからです。

Software Engineer

開発にAIを用いることが当たり前になってきた一方で、自分の決定や行動に責任を持てるかが重要だと考えています。全てAI任せにせず、AIと共に学び、自身を成長させられる人かどうかを見ています。技術課題では、最終的なアウトプットの品質が一定担保された上で、技術や設計の選定理由、システムの発展性を自分の言葉で語れるかを重視しています。


PD Teamが求める人物像

最後に、Head of Productの大村から一緒に働きたいと考える人物像をお伝えします。

この人物像の背景にある考え方は、過去のインタビュー記事で詳しく話しています。あわせてご覧ください。

Blog: 日本から、世界で使われるプロダクトを:Sakana AI プロダクト開発責任者インタビュー


PD Teamでは現在、ARE / SWE / Data Engineer / PdM / Designer / Sales などを募集しています。少しでも興味を持っていただけたら、まずはご応募ください。

PD Team 採用情報