スタディストでは、これまで提供してきた「Teachme Biz」の体験をAIで拡張していくために、AIエンジニアリング室を立ち上げました。
2024年4月、私はスタディスト初のAIエンジニアとして入社しました。これまで、エンジニアリングの現場に身を置きながらも、事業づくりそのものにも強い関心を抱いており、技術だけでなく事業全体を推進する役割を担える環境を求めていたところ、スタディストと出会いました。
その後2024年9月にAIエンジニアリング室を立ち上げ、私は室長に就任しました。徐々にチームを拡大し、現在では私を含めて9名のAIエンジニアが在籍しています。
マニュアルSaaSを提供するスタディストで、AIを組み込んだプロダクト開発を私たちがどのように進めているのか、その試行錯誤をご紹介します。
私たちは「AIを使ったプロダクト機能の開発」に役割を持つ組織です。AI活用というと「社内の生産性を高めるための取り組み」を想像する方もいらっしゃるかもしれませんが、社内オペレーションの改善については別組織が役割を担っています。
スタディストのAIエンジニアリング室のミッションは「AI の “発明” を形にし、価値を届け、基盤を育む」と定めています。現在は
Teachme Biz の AI 機能 (=Teachme AI) の改善
スタディストの他プロダクトも含めた、AIを使った機能開発
実験的な取り組みとしての、新しい体験検証
AIプロダクトにおける品質評価の仕組みづくり
といった領域に注力しています。
なぜ、AIという「技術・How起点」でプロダクト機能を考える組織が必要なのかについても触れておきます。
プロダクトづくりは、多くの場合、ユーザーが抱える課題を解決することを目指します。一般的には、ユーザーが持つ課題 (Why) を捉え、その解決・実現方法 (How) を定義するという流れで進みます。
一方で、ユーザーの課題の中には、Howが存在することで初めて生まれるものもあります。例えば「紙で作られたマニュアルを、更新された瞬間に遠方の拠点にも共有したい」といった課題は、200年前には存在していませんでした。インターネット・クラウドという技術が現れたことで、はじめて課題として認識されます。
同じような変化は、生成AI (LLM) を取り巻く環境でも起こっています。例えば「マニュアルを自分で書かなくても済むようにしたい」といった渇望は、ChatGPTのような生成AIが普及したことで、初めて現実的な課題として認識されるようになりました。つまり、新しい技術が登場することで、従来の “当たり前” が問い直され、「実は書く作業そのものが不要かもしれない」という新しい Why が生まれるという構造です。
この状況に対して、AIエンジニアリング室としては、
どこまでAIでできるかを先に試作する (発明)
試作したものから、ユーザーの手に届く具体的な機能へと磨き上げる (価値を届ける)
そのフィードバックをもとに、誰もが再利用できる共通API/データ/ワークフローとして定着させる (基盤を育む)
という3つのアクションを重視しています。
そして、この検証を素早く進める存在がいれば「AIで何かできそうじゃない？」といった机上の空論に留まらず、本当に解決すべき課題やその解決策を、誰よりも早く見つけることができるはずです。このような考えから、未来のHowを “発明” し、より良い課題発見を推進する組織として、AIエンジニアリング室を設置しました。
スタディストでは、私が入社する以前から、プロダクトへのAI機能の組み込みに向けた検証が進められていました。
その検証を引き継ぐ形で、さらにAIを使ってプロダクトの価値を大きく変えられないかを模索しはじめ、 Teachme Biz 開発チームとともに、これまでにいくつものAI機能を公開してきました。
私たちはAIの技術そのものに注目するのではなく「どの課題に対して、どう使えるか」に意識を向けています。あくまでプロダクトマネジメントの定石に則り、 “ユーザーに本当に役立つ“ ものしかリリースしないことにしています。
AIを試験的に取り入れる段階の機能開発ではなく、本当に役立つ “AI機能” をつくるために、私たちは
AIがあるからこそ生まれる課題を探す
机上の空論ではなく “発明” から始める
という2つのポイントを意識した開発プロセスを取ることで、リリースする前から「これまでにはない体験で、かつ必ずお客さまに使われる」という確信を持つことができています。ここからは、具体例をまじえながらこの2つのポイントについてまとめてみます。
前述のとおり、AIという新しい手段（How）が生まれたことで、はじめて認識される不便さがあります。
AIプロダクト開発で重要なことの一つは、これまで問題として認識されていなかったにもかかわらず、AIの登場によって強く課題として浮かび上がってきた部分を見つけることです。
マニュアル作成という業務には、多くのペインが存在します。たとえば「何を書けばよいのか」「構成をどう組み立てるべきか」「どのように画像を配置するか」など、細かな判断や作業が非常に多く、手間がかかりやすいという特徴があります。
当時、 Claude で「自然言語の指示だけでコードを編集できる」体験に衝撃を受けました。
この体験をマニュアル作成にも置き換えられるのではないか — その仮説を確かめるためにプロトタイプを開発しました。
このプロトタイプは、指示を入力するだけでマニュアルが自動生成されるというものです。文章作成や画像配置を人が一つひとつ手作業で行うのではなく、指示に応じてAIが処理してくれる体験を簡易的に実装しています。この取り組みが、のちに生まれた「マニュアル編集アシスタント機能」の原型となりました。
しかし、このプロトタイプをCSチームに試してもらったところ「これだけでは課題を十分に解決できるイメージが持てない」というフィードバックがありました。
その後、プロトタイピングと調査を繰り返す中で、新規作成の手間を下げるニーズは確かにあるものの、このプロトタイプの延長で深く解決できる見込みのある課題は「作成したマニュアルの編集を楽にしたい」部分だと気付きました。
この気付きを踏まえ、現在はプロダクトの価値を再設計しています。
このように、お客さまの課題の中でもAIが登場したことで強くペインとして現れる部分を探っていくことが、本当に使われるAI機能を開発するうえで重要だと考えています。
AIを使ったプロダクトづくりでは、これまで以上に “体験の共有“ が重要になります。ログイン機能や購入機能のように、すでに共通認識のあるUIであれば仕様書をもとに議論できます。しかし、未来の “AI機能” は誰も見たことがないため、まず動くものを見せて会話することが大切です。
AI機能は実際に体験してみないとイメージが湧きづらいことが多く、言葉で説明するよりも触ってもらう方が圧倒的に理解が早く進みます。だからこそ、課題の確からしさが判断できない段階から初手でプロトタイプをつくり、それを見ながら「本当に課題はあるのか？」「ここを変えるとどうなるのか？」といった対話を重ねていきます。
“発明” から始める — プロトタイプを通じて初めて、議論を深められるようになる。これはAI時代のプロダクトマネジメントにおいて、あらためて強調すべき側面だと考えます。
実際、いくつもの機能が、このようなプロトタイピング文化から生まれています。
先述した「マニュアル編集アシスタント機能」も、プロトタイピングを重ねたことで体験がブラッシュアップされた好例です。 先日Cocodaで事例を公開しましたが、この機能の検証段階では、合計11回にわたるプロトタイプテストを行い改善を繰り返しています。
AIエンジニアがプロトタイピングを行い、それを実際のお客さまにテストするプロセスを重ねる中で、「テキストだけでなく、画像の割り当ても自動化できないか」というインサイトも新たに見えてきました。
この気付きをきっかけに、生成AIが記載されているテキストをもとに適切な画像を割り当てていく「画像割り当て機能」も誕生しています。
当初の仮説段階では、「本当にここまで必要なのか？」という確信はありませんでした。しかし、プロトタイプを使いながら体験を細かく調整していくことで、注目している課題を解決するには不可欠な機能だと判断し、確信を持ってリリースに至りました。
マニュアル編集アシスタントの中に含まれている “ナッジ機能” も、開発メンバーの1人が試しにプロトタイプへ組み込んでみたことをきっかけに生まれたものです。
ナッジ（nudge）は行動経済学の概念で、行動を促す “きっかけ“ を意味します。アシスタントの画面には「ナッジ」ボタンがあり、クリックすると入力欄に例文が自動で挿入されます。これは、ChatGPTのようなツールで生じがちな「何を入力すればいいのか分からない」という課題を解消するために設計した機能でした。
ところが、実際にユーザーの利用状況を観察してみると、多くの人が自分で文章を書くよりもナッジされた文章をそのままクリックしていました。
その理由を精査すると、スタディストが蓄積してきたベストプラクティスをもとに、入力した文章を“より良い形”へ自然に整える提案が返ってくる点に価値を感じていたことが分かりました。これにより、自分で文章を考え込む負荷を減らしながら、一定の品質を確保できるからです。
結果として、ナッジは単なる補助機能ではなく、“文章を入力する体験そのもの” を変える重要な機能として位置付けられました。こうした発見は、プロトタイプをつくることで初めて気付くことができたものでした。
このようなポイントを意識してAIプロダクト開発に取り組んできたことで、いくつものAIを活用した新機能がスタディストからリリースされています。
お客さまからもTeachme AIに対する驚きの声がいくつも生まれていて、本当に現場で使われるAI機能をつくれていることを実感しています。
私自身も、AI活用の可能性をさらに探るため、日々試行錯誤を続けています。たとえば2025年9月には、お客さまの工場で1ヶ月間現場勤務をさせていただきました。
AIを活用して解決できるユーザー課題をより深く理解し、スタディストのプロダクト体験をより良いものへとアップデートしていきたいと考えています。
私はAIエンジニアリング室を立ち上げてきましたが、どんな企業にも “AI専任部署“ が必要だとは考えていません。「専任部門をつくる」よりも「早く試す文化を育てる」ことの方が重要だと感じています。
私たちがいま手応えを感じている理由は、専任部署の有無ではなく、「新しい体験をすぐ形にすること」と「その体験をプロダクトとして磨き切ること」を徹底している点にあります。
AI機能は、つくっただけでは価値につながらず、改善が止まってしまうケースも少なくありません。
だからこそ、実際に使われる機能へ育てるには、最後の“ラストワンマイル”まで体験を丁寧に仕上げることが欠かせません。
私たちの強みは、AI導入そのものを目的化せず、「試作 → 検証 → 本実装」を継続的に回し切る体制を持っている点にあります。
このプロセスはAIエンジニアだけでは成立しません。前回の事例でも紹介したように、リサーチ&デザイン室のデザイナーと連携し、「体験を早くつくり、ユーザーのインサイトを素早く掴む」ことが欠かせません。
今後もユーザーに向き合いながら、AIプロダクト開発に最適なワークフローを進化させていきます。