ACES エンジニアブログ

ACESのエンジニアブログです。

フィードバックサイクルを高速化するACES Meetの開発哲学

こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です。

この記事では、私が所属する ACES Meet の開発チームが掲げる「フィードバックサイクルの高速化」という開発哲学について、その背景や具体的な取り組みをご紹介します。この記事を通じて、ACES Meetの開発チームの挑戦にご興味を持っていただいたり、皆様のプロダクト開発にとってご参考になる部分があれば幸いです。

フィードバックサイクルとは何か

ここで言うフィードバックサイクルとは、開発やリリースの各段階で得られるフィードバックを迅速に活用し、次の行動へ反映させるプロセスのことを指します。このサイクルが効率よく回るほど、価値提供までのリードタイムが短縮され、顧客に迅速に成果を届けることが可能になります。

具体的には以下のような項目が挙げられます。

  • ローカル環境での確認: コードを実行し、テスト結果を即時確認します。Green/Red (成功/失敗) の把握で初期エラーを検出し、素早く修正につなげます。
  • CI/CDによるテスト: 継続的インテグレーション環境でコードを検証し、品質を保証します。問題を早期に発見し、リリース前に修正することが可能です。
  • Pull Requestのレビュー: 他の開発者からフィードバックを受け取り、コードの改善点を素早く反映します。
  • 検証環境での動作確認: 実際の利用環境を想定し、期待する挙動が実現されているかを確認します。リリース前に問題を排除することができます。
  • 社内でのドッグフーディング: 開発チーム自らプロダクトを使用し、実際の使用感から改善点を見つけ出し、顧客視点の課題を洗い出します。
  • 顧客からのフィードバック: MVP (Minimum Viable Product) などを通じて顧客から直接得た意見を次の改善につなげ、プロダクトの方向性を調整します。

フィードバックは、上記のような段階ごとに発生します。これらの段階は、それぞれ異なる粒度でプロダクトの改善や価値提供を支え、いずれのフェーズでも「フィードバックを得るまでの時間を短縮すること」が鍵となります。この一般的な考え方は、ACES Meetにおいても同様で、顧客やビジネス要求に迅速に応えるためにフィードバックサイクルの高速化を最重要課題の一つとして掲げ、開発体制を整えています。

一般論としてのフィードバックサイクルの重要性

「フィードバックサイクルの高速化」は、単なる効率化ではなく、市場の変化に迅速に適応し続けるための重要な鍵となります。その有効性は、データに基づく研究結果で裏付けられると同時に、プロダクト開発現場での経験からも多くの示唆が得られています。

2.1. DORAの研究レポートが示す事実

DevOps Research and Assessment (DORA) による調査によれば、高速なフィードバックサイクルはプロダクトの成功に直結しています。

例えば、DORAの2024年の最新のレポートによると、パフォーマンスレベルがエリートのチームは「コードの変更から本番リリースまでのリードタイムが1日未満」であることが報告されています。*1

dora.dev

このような短いリードタイムを実現することで、競争の激しい市場でも迅速に新しい価値を顧客に提供することが可能になります。

これは、フィードバックサイクルの高速化が単なる「スピードアップ」ではなく、プロダクトが市場で競争力を保つための重要な戦略であることを示しています。

2.2. プロダクト開発における重要性

フィードバックサイクルは、開発チーム内の効率化にとどまらず、プロダクト全体の方向性を迅速かつ柔軟に調整する上で重要な役割を果たします。特に以下の2点で、その重要性が際立ちます。

  • 顧客ニーズへの適応: 高速なサイクルによって顧客からの意見をタイムリーに収集し、改善へ反映できます。これにより常に市場の期待に応える状態を維持します。
  • ビジネスサイドとの連携強化: フィードバックサイクルは、開発とビジネスの橋渡しとしても機能します。初期アイデアからリリース後の評価まで、継続的なコミュニケーションがプロダクトの方向性を正確に調整します。

このようにフィードバックサイクルの高速化は、常に変化する市場にプロダクトが適応し続けるために欠かせないアプローチです。次章では、ACES Meetがこの高速化を重視する背景について掘り下げます。

ACES Meetにおけるフィードバックサイクル高速化の重要性

ACES Meetは、商談や会議内容を可視化し、営業組織の強化を支援する営業DX×AI SaaSです。音声書き起こし、話者分割、トピック抽出、議事録自動生成、対話分析など、多岐にわたるAIアルゴリズムを組み合わせて価値を提供しています。

さらに、ACES Meetはリリースから2年半ほどの比較的新しいプロダクトであり、市場からのフィードバックを受けながら進化を続けています。

このような特性を持つACES Meetにおいては、一般論としてのフィードバックサイクルの重要性に加え、以下の2つの理由からフィードバックサイクルの高速化を重視しています。

3.1. PMFを目指すプロダクトとしての挑戦

ACES Meetはまだ完全にPMF (Product-Market Fit) を達成していない段階にあります。そのため、顧客ニーズや市場動向を迅速に捉え、改善を繰り返すことが極めて重要です。特に市場からのフィードバックを素早く仮説検証へと反映し、プロダクトの進化を加速させることが欠かせません。

プロダクト開発において、成功するアイデアと失敗するアイデアを見分けることは非常に難しいとされています。多くのケースでは、どの機能や改善案が市場に受け入れられるかは事前に予測がつきにくいため、試行錯誤を繰り返しながら学んでいくアプローチが求められます。この点について、以下の記事で次のように指摘されています。

これらのことから、人間は基本的に、成功するアイデアと失敗するアイデアを見分けることが得意ではないということがよくわかる。長年、ソフトウェアプロダクト開発に携わっていれば、これに頷ける。プロダクトのアップデートを何度繰り返しても重要指標が一向に改善されないことや、自信を持ってローンチした新機能がほとんど使われないといった経験を重ねてきただろう。

mtx2s.hatenablog.com

このような背景を踏まえ、ACES Meetでは「とにかく多くの打席に立つ」姿勢を重要視しています。効率的なフィードバックサイクルを活用し、迅速な仮説検証を通じてプロダクトを市場に適合させる取り組みを進めています。

3.2. AI開発の不確実性への対応

AI機能はその特性上、精度や性能を事前に予測することが難しく、不確実性への対応が求められます。PoC (Proof of Concept) での仮説検証や、実運用環境での予期せぬ挙動への迅速な対処が必要です。また、ビジネスサイドとの密接な連携を通じて、技術的な不確実性を早期に解消し、顧客に求められる価値を確実に届ける取り組みが重要となります。

こうしたPMFへの挑戦とAI特有の不確実性を背景として、ACES Meetはフィードバックサイクルの高速化を、プロダクトの進化と競争力維持のための戦略的要素と位置づけています。

ACES Meetにおけるフィードバックサイクル高速化の具体的な取り組み

ACES Meetでは、フィードバックサイクルを高速化するため、フィードバックを「フィードバックサイクルを高速化するための取り組み」「フィードバックを最大化するための取り組み」の2つの視点から捉え、短期間でのプロダクト進化や市場ニーズへの柔軟な対応を実現しようとしています。

4.1. フィードバックサイクルを高速化するための取り組み

ACES Meetの開発チームでは、設計、実装、テスト、デプロイの各段階でサイクルを効率的に回し、開発プロセス全体の速度を向上させる取り組みを進めています。これにより、アイデアの具現化から実装、リリースまでを短期間で繰り返し、プロダクトの進化を加速させています。この章では、それぞれの段階での具体的な工夫や改善策について簡単にご紹介します。

4.1.1. 初期アイデア段階からの設計レビュー

開発前キックオフで要件を明確にし、懸念点を洗い出したうえで設計方針を議論します。以下の取り組みを通じて設計段階での問題を早期発見し、後続工程での手戻りを最小限に抑えています。

  • 要件確認や懸念点の洗い出しを行い、設計方針を議論する。
  • ペアでの設計とタスク分解により、作業の粒度を細かくする。
  • 週1回の設計レビュー会で進行中の設計や実装について壁打ちとフィードバックを行う。
  • SlackのHuddle機能を活用して、即時的な相談と議論を可能にする。

4.1.2. 小さなPull Requestの徹底

一度に扱う変更量を最小限に抑えたPull Requestを作成することで、レビューと修正の迅速化を実現しています。

  • 変更量を抑えた小規模なPull Requestを作成することで、レビュー効率を向上させる。
  • タスク分解を徹底し、Pull Requestは1つの変更に限定する。
  • レビュアーが素早く変更内容を把握できる状態を保つことで、レビュイー・レビュアー双方の負担を軽減する。

詳細については以下の記事をご覧ください。 tech.acesinc.co.jp

4.1.3. CIの高速化

継続的インテグレーション (CI) では「5分以内で完了」を目標に定期的な改善を行っています。以下のアプローチにより、全体のテスト時間を短縮しています。

  • Slow Testsを撲滅し、CIのボトルネックを解消する。
  • GitHub Actionsのmatrix機能を活用してテストを並列実行する。
  • Rust製のLintツールを導入し、数秒で完了するコードスタイルチェックを実現する。

これらの具体的な改善内容については、別の記事で詳しくお伝えする予定です。ぜひご期待ください!

4.1.4. デプロイプロセスの改善

以前はデプロイ前の準備や実行に多くの手間がかかり、開発者にとって負担が大きいプロセスでした。この課題を解決するため、特定のブランチに変更をマージするだけで自動的にデプロイが実行される仕組みを整備しました。

さらに、マイグレーションファイルに変更がない場合には該当工程をスキップする仕組みを導入することで、デプロイ時間を短縮しました。特にSandbox環境ではデプロイ頻度が高いため、この改善によりデプロイの回転数が大幅に向上し、開発フロー全体の効率化に貢献しています。

4.2. フィードバックを最大化するための取り組み

ACES Meetでは、顧客やステークホルダーからの意見を迅速に収集し、それをビジネスサイドとの連携を通じて即座にプロダクトの方向性へ反映しています。この取り組みにより、フィードバックを迅速に次のアクションへとつなげる仕組みを構築し、顧客ニーズに適応したプロダクト開発を加速させています。

4.2.1. ワークショップの開催

社内のステークホルダーを対象に、定期的なワークショップを実施しています。この場では、利用者が直面している業務上の課題や背景、具体的な影響を詳細に共有し、それらを解決するための最適なアプローチを議論します。たとえば、営業やカスタマーサポート部門が抱える課題を可視化することで、プロダクトがどのように貢献できるかを具体化し、開発テーマの優先順位を整理しています。

この取り組みは、単なる課題共有にとどまらず、ステークホルダー全体で仮説検証を推進する場として機能しています。結果として、開発テーマやプロダクト戦略が明確になり、チーム全体で共通認識を持ちながら迅速な意思決定を行う体制を構築しています。

4.2.2. リリース前の検証

リリース前の検証プロセスでは、開発前と開発後の2つの段階でフィードバックを収集し、プロダクトの完成度を高める取り組みを行っています。

開発前

開発に着手する前の段階では、UIデザインやプロトタイプを活用してステークホルダーからフィードバックを収集しています。開発者、PdM、デザイナーだけでなく、営業やCSとも積極的に壁打ちを行い、認識のすり合わせを徹底しています。特にAI機能の場合は、プロンプトと生成結果を確認できる簡易画面を活用することで、具体的なフィードバックを得る環境を整えています。この段階では、実装というコストの高い作業を進める前に可能な限り課題を洗い出し、仕様の精度を高めることを重視しています。

開発後

完成したプロダクトについては、営業やCSに実際に触ってもらい、使用感の確認を行います。特に以下の観点でフィードバックを収集しています。

  • 実際の業務で使用する際に違和感がないか。
  • 他の機能と組み合わせてシームレスに利用できるか。

また、収集したフィードバックをもとに、リリース前に修正可能な課題については即座に対応し、可能な限り最適な形で顧客に提供できるよう準備を整えます。

4.2.3. MVPのリリース

ACES Meetでは、MVP (Minimum Viable Product) のリリースを通じて、必要最小限の機能を持つプロダクトを早期に市場へ投入し、顧客からのフィードバックを迅速に収集することを重視しています。これは、3.1節で述べた「何が成功するか分からない」という前提に基づいており、提供したいユーザー体験や解決すべき課題の本質を見極めるための重要なプロセスです。

このアプローチでは、下図の下段一番左の絵のような手押し車からスタートして徐々に肉付けしていくように、まずは最小限の形で価値を届けることを目指します。*2

提供する体験や解決する課題の方向性が正しければ、それを強化する形で進化させ、間違っていれば迅速に次の仮説を検証する足掛かりとなります。

MVP - not "bike to car"

また、仮説を大きく外さないようにするためにも、4.2.1で述べたワークショップや、4.2.2で実施するリリース前の検証といった工程を大切にしています。これらを通じて、ステークホルダーの声を早い段階で収集し、仮説の精度を高める工夫を重ねています。

まだまだ課題は多く、すべてが完璧にワークしているわけではありませんが、試行錯誤を重ねながら改善を図っています。

4.2.4. ユーザーインタビュー

定期的にユーザーインタビューを実施し、現在のプロダクトが顧客にとって本当の意味で価値を提供できているかを確認するようにしています。

インタビューでは、ACES Meetを利用することで顧客のKGIやKPIが改善につながっているかをヒアリングし、プロダクトが業務上の課題解決や効率化にどの程度寄与しているかについてフィードバックを収集しています。これにより、プロダクトの現状を顧客視点で見直し、さらなる改善のための材料としています。

なお、顧客とのACES Meet導入前の商談や導入後のCS活動、ユーザーインタビューの内容はすべてACES Meetに記録されています。これにより、初期の課題から利用後の変化までを一元的に管理でき、後からの振り返りや分析も容易に行える環境が整っています。

まとめ

本記事では、フィードバックサイクルを高速化することの重要性と、ACES Meetのプロダクトチームがそれをどのように実現しているかをご紹介しました。

今後もこの取り組みを進めることで、ACES Meetは顧客に求められる機能と体験をスピーディに届け、常に進化し続けるプロダクトを目指していきます。

本記事を通して、ACESに少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております!

ACESの採用情報はこちら↓ youtrust.jp

元VPoEがACESを選んだ理由 〜このチームと働きたい〜

初めまして!ACESでエンジニアリングマネージャーを担っています、小林と申します!

今回入社3ヶ月も過ぎ、無事試用期間を終えた記念として、入社エントリなるものを書いてみようと思います。

ドーナッツに挟まる息子くん

簡単な前職までの経歴

大学卒業後、SI企業を2社ほど経験した後

エムティーアイ、グリーでスクラムマスターを、リクルートキャリア(現リクルート)で7年半ほどプロジェクトマネジメントやサービスマネジメントを経験し前職のテックタッチに転職しました。

初めてのスタートアップでしたが、1人目EMとして様々な機会に恵まれ

  • スクラム運営
  • チームトポロジーを活かしたチーム分割
  • インシデントマネジメント
  • デリバリーマネジメント

などプロダクト開発の実装以外をCTOとともに担わせていただきました。

その後同社初のVPoEとして採用や組織運営にも携わらせていただき、身に余る経験を積ませていただいたと思っています。

なんで転職しようと思ったのか

前職では機会にも恵まれ、幅広い業務を任せていただきました。

ただ、VPoEになってから、もしくはなる直前くらいからできる限り自分自身の能力で再現性の高い組織作り・プロダクト作りをしたかったという思いが膨らんできたことが主な理由です。 (もっと詳しい話が聞きたい方はぜひお声がけください・・・!色々とお話しできると思います)

なんでACESに決めたのか

様々な会社(合計20社くらい)とカジュアル面談を重ねるうちに、自分なりの軸がはっきりしてきました。

  • チームとしての伸び代が大きいチームがよい
  • フィードバックサイクルを高速で回せるプロダクトを目指せる
  • 評価制度など、本人の成長支援する制度を一緒に考えられる人事がいること
  • プロダクトそのものとしての成長の余白が大きい

といったチームの環境で働きたいなと思えるようになっていました

そんな中ACESは

  • 面接官だったテックリードをみて、開発メンバーが若手なのにとても優秀だなというのが伝わってきた
  • シンプルなプロダクトが故に進化余地が大きい
  • エンジニアリングの基本が整っており、改善を行うことで、簡単に倍以上のフィードバックスピードを目指せる
  • 評価制度を組織状況に応じて着実に改善できており、それをしっかり前に進められる人事がいる

というのが明確に見えてきた時点でほぼ心はACESに決まりました。

ACES と プロダクト

ちなみに私が求人を見た時に思った会社の第一印象は

合理的で厳しそうな雰囲気を想像していました。が、それは面談・面接・入社を経て綺麗さっぱり無くなりました。今日これを書くネタを考えていた時まで思い出せなかったくらいです。笑

実態でいうと和気あいあいとした雰囲気があり、適度にウェットな一面も感じられ、第一印象とは真逆で、みなさん人柄的には真面目でありつつも自分の仕事にプライドを持っている素敵な方々だなと思っています。

プロダクトについて

ACES Meetというプロダクトを今開発しています。 ACES Meetというのはローンチから2年半が経ち、基盤的な機能が揃い始め、第二創業期に突入したと感じています。

基本機能はできているので、これからは特定の領域(これは面談の時にお話しします!)に対し攻めの姿勢でいけるフェーズに入り始めています。

最後に

実はいろんな施策をこの数ヶ月の中で打つことができ、その結果、チームのパフォーマンスも一段上がる成果にもつながりました。その話もいずれ別の記事でご紹介できればと思っています。

カジュアル面談を通じて、ACESの魅力や私たちのビジョンをぜひお伝えしたいと思っています。転職をお考えの方や、少しでも興味を持たれた方はお気軽にご連絡ください。もちろん応募もお待ちしておりますし、転職に関するご相談も歓迎しています!

https://pitta.me/matches/SclKZswiSGvh

いわゆるAIで議事録を書くというだけにとどまらない、もっと面白いプロダクトを開発していくという体験ができること請け合いです!

リリースを加速するACES Meetの設計プロセス

こんにちは、株式会社ACES でソフトウェアエンジニアをしている奥田(@masaya_okuda)です。

この記事では、私の所属するACES Meetの開発チームで実践している設計プロセスをご紹介します。ここで言う設計とは、PdMから開発チケットの要件定義が共有され、本格的な実装を始める前までの期間に行うプロセスを指します。

背景には、私たちの開発チームが以下の課題を抱えていたことがあります。

  • 複数の変更内容が含まれるPull Requestが作成され、レビューコストが高い
  • レビュアーと実装者の認識齟齬による指摘の多発と手戻り

これらが原因となり、リリースまでの期間が大きく遅延したり、手戻りによる実装者とレビュアーの疲弊につながっていました。

肥大化したPull Requestが引き起こす3つの課題

改善にあたり、開発工程のどこに課題があるのかを検討した結果、Pull Requestの粒度であると分かりました。

  • 1つのPull Requestで複数の変更が実装されておりレビューコストが高い
  • 機能開発の大部分が完了した段階で、考慮漏れや設計の見直しとなった場合、手戻りが大きくなる
  • リリーススケジュールの後半で問題が発覚することが多く、リカバリが困難

背景には変更の全体像が不透明なまま開発が進められ、結果的にスコープが広がってしまうという構造的な問題もありました。 Pull Requestの粒度に関してはFindy社のテックブログでわかりやすくまとまっており、参考にさせていただきました!

tech.findy.co.jp

Pull Requestの粒度を適切に保つためには、本格的な実装を始める前に変更の全体像を把握し、タスク分解することが重要と考え設計フェーズで行うことを整理しました。

設計からコードレビューまでの流れ

設計フェーズで行う4つのステップ

設計フェーズは、大きく4つのステップで構成されています。

  1. 要件を開発に必要なレベルまで具体化する
  2. APIのインターフェースとDB設計を行う
  3. 仮実装を行う
  4. タスク分解を行い、レビュアーと開発手順の認識を揃える

Step4のタスク分解は1つのPull Requestで行うことと対応しています。設計フェーズの目的は、1つのPull Requestが意味のある粒度で小さくなるようにタスクを分解し、その開発ステップをレビュアーと合意することです。

要件を開発に必要なレベルまで具体化する

設計の初めに要件を具体化します。この工程では、満たすべき仕様を整理し、開発者間で認識を共有できる形に落とし込みます。

このステップでは要件に対する理解を深め、仕様に納得感を持って次の工程に進むことを重要視しています。特に、開発者がPdMやデザイナーと協力して仕様を検討することで、現場感覚を反映した実現可能な設計を追求しています。

具体化プロセスでのよくある課題と対応策

要件を具体化する中で、以下のような場面に直面することがあります。

  • 上手く言語化できないとき
    • どの画面上でどのように動作するのか?
    • ユーザーの状態によってどのように分岐するのか?
    • → PdMやデザイナーと開発者が直接対話することで、具体的なシナリオを共有します。
  • ボリュームが大きくなりすぎるとき
    • この機能開発で複数のことを同時にやろうとしていないか?
    • もっとシンプルにしたり、機能を分割することでリリースを高速化できないか?
    • → チームで優先度を再評価し、必要に応じて分割案を議論します。

ここで重要なのは、「言われたことをそのまま作る」ではなく、開発者自身が仕様の妥当性や実現性を検証し、必要であればフィードバックを返すことです。例えば、設計段階で以下のような「現場の気づき」をチームに共有し、納得できる解決策を模索します。

  • 現場の技術的な制約が原因で、別案が必要な場合
  • ユーザーストーリーに抜け漏れがある場合
  • 既存の仕様に影響が出るリスクが見つかった場合

仮実装

次に仮実装を行います。次に仮実装を行います。仮実装の目的は、「タスク全体のイメージを掴むこと」と「適切な粒度でタスクを分解するための判断材料を得ること」です。

  • タスク全体のイメージを掴む
    • 具体的にどの箇所に変更が必要か?
  • 適切な粒度でタスクを分解するための判断材料を得る
    • 実装の前例が無いなど、不確実性の高い実装はどこか?
    • セキュリティリスクが高く、慎重な設計が必要な箇所はどこか?
    • 修正箇所で事前にリファクタリングが必要な箇所があるか?

この段階では、作り込みに時間をかけすぎないように注意します。 例えばフロントエンドの仮実装の場合は、以下の観点で進めます。

タスク分解を行い、レビュアーと開発手順の認識を揃える

仮実装で開発の全体像を掴んだ後にタスク分解を行います。この工程は本格的な実装時にレビュアーとなるエンジニアとバディで行います。レビュアーが以下のポイントを事前に理解しておくことで、レビュー時のコストが大幅に削減されます。

  • この開発のゴールは何か?
  • どの手順や粒度でPull Requestが作成されるのか?
  • ユーザーの体験や仕様が大きく変わるなど、特に注意してレビューすべきタスクはどれか?
  • デプロイ時に注意すべきことがあるか?

さらに、仮実装を確認しながら、手戻りが大きくなりそうな認識のズレがないかを事前に検証します。

実際に運用してみての効果

設計フェーズを改善した結果、冒頭で挙げた課題への効果を実感しています!

  • 課題:大きなPull Requestが作成され、レビューコストが高い
    • タスクを小さく分解することで、1つのPull Requestが意味のある粒度に保たれ、レビューが効率化
    • 仮実装の段階でタスク分解を行うため、レビュー時に「何を見ればよいか」が明確になり、レビュアーの心理的負担が軽減
  • 課題:レビュアーと実装者の認識齟齬による指摘の多発と手戻り
    • 設計フェーズで要件を具体化し、認識を共有することで、仕様や設計の方向性に対する共通理解が形成され手戻りが減少
    • 仮実装を通じて、「想定外の仕様変更」や「実現が難しい設計」を早期に発見し、実装後の修正コストを削減

終わりに

今回は、私の所属する開発チームで実践している設計フェーズの取り組みをご紹介しました。このプロセスが、皆さんのチームにとっても何か参考になれば幸いです。

ACESではご紹介した開発プロセスに取り組む前提として、ユーザーへの価値提供と技術品質の高さの両方に妥協せず取り組む文化があると感じています。少しでも興味を持っていただけた方は、ぜひカジュアル面談のお申し込みをお待ちしております!

ACESの採用情報はこちら↓

youtrust.jp

youtrust.jp

AIアルゴリズムのプロフェッショナルと協働するソフトウェア開発の魅力

同じマイクで複数人が話しても、話者を識別する機能
同じマイクで複数人が話しても、話者を識別する機能
こんにちは、株式会社ACES でソフトウェアエンジニアをしている奥田(@masaya_okuda)です。

独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行い、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を開発しています。

meet.acesinc.co.jp

現職で初めてAIが根幹にあるソフトウェアサービスを開発し、従来の開発と比較して「設計の難易度が明確に上がった」と感じています。AI機能はユーザーが使えば使うほど精度が上がる一方で、学習が十分でないフェーズでは期待値を下回ってしまう可能性があります。

それを乗り越えてユーザーにご利用いただくため、開発時にはAIエンジニアとソフトウェアエンジニアが協働して機能開発を行います。AIエンジニアがAI自体の精度向上を担当し、ソフトウェアエンジニアがAIをユーザーが利用可能なUIを持ったソフトウェアとして実装します。

特に、「いかにユーザーにストレスを感じさせない体験を作るか?」「100%ではないAIの精度をソフトウェア側でどうカバーするか?」をAIエンジニアと共に設計しプロダクトに落とし込んでいく過程に、これまでにない面白さを感じています!

そこで今回は、ソフトウェアエンジニア目線でAIプロダクト開発の課題や魅力をご紹介したいと思います。

ACESの開発組織

まずは簡単に組織についてご紹介します。ACESは「アルゴリズムで、社会はもっとシンプルになる。」というビジョンのもと、アルゴリズム事業を展開する会社です。SaaSを提供するAIソフトウェア事業に加え、クライアントとプロジェクト型で伴走するDXパートナー事業、AIソフトウェアの研究開発部門があり、時短社員も含めると30名以上のエンジニアが所属しています。

私はAIソフトウェア事業に所属しており、研究開発部門と連携して「ACES Meet」を開発しています。

直近のAI機能リリース

ACES Meetは先日、「同じマイクで複数人が話しても、話者を識別する機能」をリリースしました。ユーザーの音声データを学習し、同じマイクに対して複数人が話しても話者を特定して文字起こしを行うことができます。この機能によってオフライン会議でもACES Meetを活用できるようになります。

同じマイクで複数人が話しても、話者を識別する機能
同じマイクで複数人が話しても、話者を識別する機能

この機能を実装する中でAIプロダクトの難しさに直面しました。

AI故の課題

これまで私が経験してきたソフトウェア開発は、「あらかじめ機能要件を定義し、要件を実現するように実装する」というプロセスで行われていました。エンジニアが開発した以上のことはできませんが、十分に検証すれば不具合のリスクは小さくできます。一方で、AIの期待性能を100%にすることは難しいため、AIが間違えたときの体験を保証する必要があります。

エンジニアの精度テストでは高い性能で話者を識別できていたにも関わらず、いざビジネスサイドの方を交えてレビューを行ったところ、稀に起こる失敗によってユーザーの体験を大きく損ねるのではないか?というリアクションが返ってきました。

音声を聞いて話者を識別することは人間にとって簡単であり、それをAIが間違えると、ユーザーは自分で手を動かした方が速いと見切りをつけてしまうリスクが高まります。

この機能の場合、会議参加者の発話量や音声の学習状況によっては3人で会議しているのに4人に過剰分割されるといったことが起こり、ユーザー体験の悪化が懸念されました。

トラストの観点をもとにユーザー体験を考える

仕様を再度検討するにあたり、AIエンジニアからトラストの観点をもとに見直そうと提案が上がりました。AIをプロダクトやサービスに組み込む場合には、人とAIの間にトラスト(信頼関係)が構築され、人が安心して使える状態を追求することが重要です。

たとえばAIの技術そのものが素晴らしくても、人が使い方を理解できなかったり、期待と異なる動作をし且つその理由がわからないと継続的な利用には繋がりません。

以下はMicrosoftの「人間と AI の相互作用に関するガイドライン」を参考に、特にACES Meetに重要な部分をピックアップした観点です。

learn.microsoft.com

トラストの観点

  • 機能を使う前に、
    • AIが「何ができるか」を容易に理解できるか?
    • AIが「どれくらい上手くできるか」を容易に理解できるか?
  • AIが間違えた時に、
    • ユーザーが「なぜAIがそのように間違えたか」を理解できるか?
    • ユーザーがAIの失敗を容易に修正することができるか?
    • AI機能をすぐさまオフにできるか。また必要な時だけ呼び出せるのか?

この中でも、

  • AIが「どれくらい上手くできるか」を容易に理解できるか?
  • AI機能をすぐさまオフにできるか。また必要な時だけ呼び出せるのか?

に着目し、最終的にはソフトウェアエンジニアとAIエンジニアで役割分担してリリースまで走り切ることとなりました。

  • AIエンジニア
    • AIの精度自体をさらに向上させる
    • 発話量が少ない場合、無理に分割しない
  • ソフトウェアエンジニア
    • 機能をON / OFFできるようにし、ユーザーが必要なときだけONにできるようにする
    • 「どんな環境なら高い精度で利用できるか?」を厚く説明したサポートページを設け、機能のすぐ近くに導線を設置する

AIプロダクトの面白さ

ACESで働くソフトウェアエンジニアとして、AIという新しいパラダイムのユーザー体験をAIエンジニアと共に考え作り上げていくことが、最も面白い瞬間です。

ACESにはAIアルゴリズムのプロフェッショナルが多数在籍しており、AIの精度をチューニングし理想の状態に近づけることができます。一方で、どんなに精度が高くてもAIの処理では間違いは発生し、結果ユーザーは難解であると感じやすいのです。

そのため、ソフトウェアエンジニア側では「どのようなインターフェースが分かりやすいのか?」「AIの精度が及ばない部分をどうフォローするか?」を設計し、ユーザーがより利用してくれる状態を目指します。

私はフロントエンドを中心に開発していますが、AIを利用したプロダクトにおいてどのようなUIがユーザーにとって分かりやすいのか?に関する国内の事例はまだ多くありません。具体的な実例が限られているチャレンジングな環境での開発を日々楽しんでいます!

今回はトラストの観点に沿って、以下の工夫を行いました。

  • 機能のON / OFFを簡単に切り替えられる
  • 設定導線の中にサポートページへのリンクを設置し、「AIに何ができるか?どれくらい上手くできるか?」を説明する

同じマイクで複数人が話しても、話者を識別する機能の設定画面
同じマイクで複数人が話しても、話者を識別する機能の設定画面

サポートページでフォローできることには限界があるため、機能設計時点でいかにUI/UXをシンプルにできるかが今後の課題です。

おわりに

本記事では、AIプロダクト開発の課題や魅力についてご紹介してきました。今後もAIエンジニアとソフトウェアエンジニアの協働を通して、お客様にとって使いやすいプロダクトづくりに努めてまいります。

これを実現するために、ソフトウェアエンジニアをはじめNLPアルゴリズムエンジニアなど幅広く募集しています。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください!

Serverside Engineer

https://open.talentio.com/r/1/c/aces/pages/22028

Front-end Engineer

https://open.talentio.com/r/1/c/aces/pages/22026

Algorithm Engineer(自然言語処理音声認識

https://open.talentio.com/r/1/c/aces/pages/55104

【登壇レポート】LLMをファインチューニングして対話用のLLMを作成する

こんにちは、株式会社ACESの久保 (@seishin55) です。 1ヶ月程前になりますが、大規模言語モデルのイベント「TechFeed Experts Night#23 〜 【非AI技術者向け】大規模言語モデルを易しく学ぶ」で登壇してきたので、そのときの資料等内容について公開します!

techfeed.io

イベント概要

内容としては以下のような内容でした。

  • @karaage0703 オープンなLLMをローカルで動かす
  • @seishin55 LLMをファインチューニングして対話用のLLMを作成する
  • @y_kimura199412 LLMの非専門家のエンジニアのためのGPT活用具体例

からあげさんも登壇レポートを上げていらっしゃるのでこちらもご参照下さい!

karaage.hatenadiary.jp

登壇内容

私は「LLMをファインチューニングして対話用のLLMを作成する」という題目でLLMのファインチューニングについて発表しました。以下の資料をご参照下さい。(内容は登壇時のものです。オープンなLLMもこの1ヶ月で色々と進展がありましたね)

イベントは以下の動画で見ることができます。

youtu.be

イベントの書き起こし記事を以下で見ることができます。 techfeed.io

おわりに

ACESではLLMの開発・導入をガンガン行っています!ご興味ある方は以下のリンクから是非ご応募ください!

acesinc.co.jp

MicrosoftのOAuth2.0連携機能の開発を振り返る

こんにちは、株式会社ACESでソフトウェアエンジニアをしている村上 (@d_murakami_0816) です。

ACES は、オンライン会議を録画し、独自 AI による話者ごとの自動文字起こしや重要なシーンの可視化を行うことで、オンライン商談における成約率の向上と現場の工数削減に寄与する商談解析 AI ツール「ACES Meet」を提供しています。今回はACES Meetで提供しているMicrosoft IDプラットフォームとの連携機能 (以下Microsoft連携) について、実装に至った背景と実装の際に苦労した部分についてこの場を借りて振り返りたいと思います。今後同様に連携機能を開発する方の助けになれば幸いです。

Microsoft連携の前提知識

Microsoft連携はOAuth 2.0の認証フローを用いて実現しています。OAuth 2.0の認証フローについてはRFC 6749のドキュメントをご参照ください。 (内容はこちらで翻訳されているのでこちらもご参照ください)

OAuth認証にはその認証方法で大きく分けて以下の4つのフローが存在しています。

  • Authorization Code Grant
  • Client Credentials Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant

今回のMicrosoft連携ではこのうち、Authorization Code Grant, Client Credentials Grantを扱っています。

Microsoft連携をなぜ実装したか

ACES Meetはオンラインで行った会議の情報を取得して、解析を行いその結果を提供するサービスになっています。したがってまず機能を利用するためにオンラインで行った会議の情報を取得する必要があります。

ACES Meetは初期リリース時、ZoomのAPIを用いてZoomで行った会議に対して上記のような解析機能を提供していました。しかし、その中で2つの課題がありました。

  • ACES Meetで作成した会議をMicrosoft Outlookに反映させてスケジュール管理できるようにしたい
  • Microsoft Teamsで行なった会議を録画できるようにしたい

Microsoft Teams (以下Teams) やMicrosoft Outlook (以下Outlook) は日本国内で見ても利用率が高く、ACES MeetとしてもTeamsを利用するユーザーもACES Meetの機能を利用できるようになることや、Outlookを利用しているユーザーがよりACES Meetを使いやすくなることは今後サービスを多くの方にご利用いただくには必要不可欠となっていました。

そういった背景から今回Microsoft連携を実装することを決定しました。

Microsoft連携を実装するにあたって苦労した部分

Microsoft連携を実装することが決まったものの、弊社では普段社内会議・商談ともにZoomの利用が主となっており、Microsoft環境についての知見はほとんどない状態でした。そんな状態から公式のドキュメントを参考に実装を進めていくわけですが、当然多くの壁にぶつかることとなりました。今回はその中でも特に大変だったものについていくつかピックアップしてみました。これからMicrosoft連携を実装する方の参考になれば幸いです。

①ドキュメントが膨大かつ用語が複雑

Microsoftのドキュメントは非常に内容が多く、かつ複雑です。Microsoftの歴史を考えれば当然のことだと思います。知りたい情報だけを得ようとしてもその説明を理解するために別のページを開くみたいなことが繰り返され、気がつくとタブがMicrosoftのドキュメントだらけになります。

一方で体系的に情報を取得しようとしてもどこを見れば知りたい情報に繋がっているのか最初はなかなかわからないです。

Microsoftのドキュメントトップページ

Microsoftのドキュメントを開くとこのようなトップページが出てきます。これだけでもサービスの多さを感じます。Microsoft連携はAzure ADを通して行われるのでAzureを選択します。

Azureのドキュメントトップページ

大分数が絞れてきたので探しやすくなると思ったのですが、この中にAzure ADがありません。ここに出ているのは「基本」の製品のみなのでAzure ADは出てきていないようです。なのでここからAzure ADを探すことになります。連携機能に関係するので「開発者ツール」、ユーザーに連携機能の許可を出したりするので「管理とガバナンス」、サービス間の通信やMicrosoft内のリソースを扱うので「ネットワーク」や「セキュリティ」など思いつく項目から探していくと、

AzureのドキュメントでIDを選択した場合

「ID」の中で見つかります。連携機能を実現する際にAzure ADから操作することが多いのですが、Azure ADそのものは「Azure Active Directory (Azure AD) は、クラウドベースの ID およびアクセス管理サービスです。」とAzure ADの説明にある通り、ID管理の製品になります。このAzure ADのドキュメントからMicrosoft IDプラットフォームのドキュメントに遷移することでやっと連携機能の実装に必要な情報に辿り着くことができます。

このようにドキュメントが膨大なので必要な情報に辿り着くのに非常に苦労しました。自分の主観になりますが、今後Microsoft連携を実装する方に向けて特に読んでおくべき記事をいくつかピックアップしたので参考にしていただければと思います。

②アクセス許可の種類による連携フローの違い

Microsoft連携を実現するにあたってAzure AD上でアクセス許可を設定するのですが、このときにアクセス許可の種類に「委任されたアクセス許可」と「アプリケーションの許可」の2つが存在します。

Azure ADのアクセス許可の画面

説明だけではあまりイメージが掴めなかったので「委任されたアクセス許可」と「アプリケーションの許可」についてドキュメントを探してみたのですが、こちらもなかなか見つかりません。

サポートの方などに問い合わせをする過程でわかったのですが、「委任されたアクセス許可」がAuthorization Code Grantと、「アプリケーションの許可」がClient Credentials Grantとそれぞれ対応づけされているようでした。

その情報を元にドキュメントを確認すると、Client Credentials Grantの説明の方に「アプリケーションの許可」に関する記載がありました。

ここに関してはドキュメントからなかなか辿れなかったのもあり、情報が結びつかずかなり苦戦した箇所になりました。

③Authorization Code Grantの管理者による同意

Authorization Code Grantは基本的にユーザーによってリソースへのアクセスに同意する形になっていますが、Azure ADではユーザーから同意する代わりに管理者が一括で同意するということが可能になっています。加えてユーザーからの同意を禁止して管理者しかリソースへのアクセスに同意できないようにする設定も存在しています。

この設定自体は問題ないように思えるのですが、OIDCの仕様と合わせたときに直感的ではない挙動がありそこでハマることになりました。

OIDCでは最初にユーザーに同意を要求する際にpromptという値を設定することができます。これは一度同意を行なったユーザーであっても連携時に再度同意を要求するという設定になります。一方でAzure ADではユーザーからの同意を禁止できるので両方の設定が有効になっていると「ユーザーから同意はできないのに毎回ユーザーの同意が要求される」という状態が発生し連携できなくなってしまうという問題がありました。

管理者の同意がうまくいかないように映るのでなかなか連携時の設定の方に思考がいかず、こちらもかなりハマることになりました。

(サポートの方に問い合わせたときに紹介していただいたのですが、サポートブログというものがあるらしく、そこにこの件についての記載がありました。当時はサポートブログの存在を知らなかったのでなかなか見つけるのは難しかったのですが、上手く検索できていれば辿り着けたのかなと思っています。)

また、この設定自体もClient Credentials Grantと混同しやすいので注意が必要になります。

どちらも管理者から同意を行うという点は同じなのですが、以下のように違いがあるので注意した上で必要なフローを選択していただくのが良いと思います。

  • Authorization Code Grant
    • 管理者から同意を行なった後にユーザーごとに連携処理を行う必要がある
    • 操作できるリソースをユーザーによって制限することができる
    • Azure AD内の「委任されたアクセス許可」に対応
  • Client Credentials Grant
    • 管理者から同意を行なった後にユーザーごとの操作は必要ない
    • 全ユーザーのリソースを操作することができる
    • Azure AD内の「アプリケーションの許可」に対応

まとめ

今回はACES MeetでMicrosoft連携を実現するに至った経緯とその際に苦労した箇所について簡単に説明させていただきました。

今回これらの課題を解決するにあたってサポートの方には大変お世話になりました。この場を借りて感謝を述べさせていただきます。

同様にMicrosoft連携を実装する方にとってこの記事が問題解決の参考になってくれればいいなと思っています。

ACES Meetはサービスの性質上、これ以外にも複数のサービスとの連携機能を実装しています。今後もこういった連携機能を強化していくことでより多くのユーザーに使っていただけるように努めて参ります。

弊社ではACES Meetをより良いサービスにしていくために引き続きソフトウェアエンジニア、アルゴリズムエンジニアを補充しております。弊社の取り組みにご興味をお持ちいただける場合は、下記の募集ページから是非ご応募ください!

Serverside Engineeropen.talentio.com

Front-end Engineeropen.talentio.com

Algorithm Engineer(自然言語処理音声認識open.talentio.com

参考サイト

CyberAgent社の日本語LLM OpenCALMの対話モデル用途のfinetune検証

こんにちは、ACESでアルゴリズムエンジニアとして働いている檜口です。最近はChatGPTを始めとする言語モデルの研究開発やプロダクト改善に取り組んでいます。

昨年末のChatGPTのリリース以降、大規模言語モデル(large language model, LLM)の社会実装が急速に進んできています。弊社でも商談解析AIツールACES MeetにLLMを組み込むなど、LLMの活用を広げています。こちらに関してはLLMを活用したAIまとめ機能リリースの裏側について過去記事を書いてありますのでご興味ある方はぜひご覧ください。

tech.acesinc.co.jp

LLMはOpenAIのChatGPTが最も有名ですが、最近はオープンソースでモデルを開発する流れも活発になっています。特に、英語で学習したオープンソースモデルはMeta社のリリースしたLlamaを始めとして非常に強力なものがリリースされています。オープンソースモデルは性能的にはOpenAIのモデルにまだまだ及ばないものの、データをセキュアに扱えたり、個人のPCでも動いてAPI利用料がかからないなど、ビジネス面からは非常に魅力的な存在です。

さて、英語でのオープンソースLLMは活発に開発されている一方で、日本語LLMはなかなか出揃っていないというのが記事執筆時点での状況です。純粋な日本語コーパスで学習されたモデルはABEJA社からリリースされた2.7Bのモデルが最大でした1。また、学習コーパスオープンソースの多言語データセットの日本語サブセットを抜き出したもので学習したものが多く、性能的には英語と比べるとまだまだという状況です2

huggingface.co

ところが、今週になってCyberAgent社から純粋な日本語コーパスで学習した最大のパラメータサイズを持つLLMモデルがサプライズ的に発表されました。また、ほぼ時を同じくして日本語LLMに取り組んでいたrinna社からも3.6BというCyberAgentモデルを除けば最大級の日本語LLMを発表しており、日本語モデルのオープンソース化が加速していてデベロッパー目線では嬉しい限りです。

こんな背景を受けて本ブログ記事では今回CyberAgent社から公開された最大の日本語LLMである open-calm-7b のLoRA finetuneを試してみました。今までの日本語モデルからは考えられないほど回答の質が良いので是非結果を見ていただきたいと思います。

モデル情報

今回リリースされたモデルの情報はhuggingfaceの各ページからアクセスできます。モデルサイズはsmall〜7Bまで6種類のモデルがリリースされています。

huggingface.co

今回公開されたモデルはtokenizerも日本語で学習されているため、日本語の埋め込み効率が非常に良くなっている点が特筆すべき点だと思います。これによって同じ文章の長さであっても、(今回リリースされたモデルとアーキテクチャが同じ)GPT-NeoXと比べてトークン数が少なく、長いコンテキストの入出力を扱うことができます。なお、コンテキスト長はGPT-NeoXと同様の2048です。

github.com

検証条件

学習データには kunishou/databricks-dolly-15k-ja を使いました。こちらは商用利用可能なオープンソースのinstructionデータセットであるdollyをdeeplを使って日本語に翻訳したものです。instructionデータセットとは何らかのリクエストとそれに対する望ましいレスポンスをペアにしたもので、このようなデータで学習するとモデルの出力を望ましい方向に誘導できます。

huggingface.co

学習の際にはparameter efficient finetune手法であるLoRAを使いました。コードはalpaca-loraをベースに弊社でリファクタしたもの(ハイパラを触りやすくした程度の改変です)を使いました。モデルがGPT-NeoXベースであるため、LoRAのターゲットは query_key_value です。

github.com

その他学習のパラメータは以下のような感じでした。

dict(
  batch_size=128,
  micro_batch_size=2,  # gradient_accumulation_steps=64
  num_epochs=3,
  learning_rate=3e-4,
  lora_r=8,
  lora_alpha=16,
  lora_dropout=5e-2,
  lora_target_modules=['query_key_value'],
  train_on_inputs=True,
  add_eos_tokens=True,
  warmup_steps=100,
)

生成パラメータは以下のものを使いました。

dict(
  temperature=0.7,
  top_p=0.75,
  top_k=40,
  max_tokens=128,
  repetition_renalty=5.0,
)

なお、学習にはRTX3090を使いました。DeepSpeedは使っていません。

検証結果

実際の入力プロンプトはalpacaスタイルに変換して与えています。LLMの出力は原文ママです。

回答サンプル

人工知能って何?

AIは、人間の知的能力をコンピュータ上で実現する技術である。具体的には、人間の使う自然言語を理解したり、論理的な推論を行ったり、経験から学習したりするコンピュータプログラムを開発することを指す。近年の技術進歩により、音声認識や画像認識の精度は大幅に向上した。また、機械による自動翻訳の精度も向上しており、近い将来、通訳がいらない時代が来ると予想されている。<|endoftext|>

何だか普通に人に聞いたみたいな答えが返ってきました。テキストの終わり位置も完璧です。(<|endoftext|> はテキストの終わりを示すマーカーです。)ChatGPTに慣れてると「まあそんなもんかな」と思うかもしれないですが、オープンソースの日本語モデルとしてこの性能は驚異的なんです。本当に。

自然言語処理とはどのようなものですか?

自然言語処理」は、人間が日常的に使っている自然言語をコンピュータに処理させる一連の技術の総称である。具体的には、文章や話し言葉機械的に解析する形態素解析構文解析、意味解析、文脈解析、固有表現抽出といった技術を指す。近年、人工知能(Artificial Intelligence:AI)の一分野として、注目が高まっている。<|endoftext|>

(感動)

広島の世界遺産を教えて

世界遺産に登録されているのは、厳島神社原爆ドームの2つです。厳島神社は宮島で、原爆ドーム広島平和記念公園にあります。<|endoftext|>

今開催G7サミットがされている広島について聞いてみました。なお、どちらの情報も合っています。ちなみに筆者は厳島神社の所在地を知りませんでした。

日本で一番高い山は?

富士山(ふじさん、Mount Fuji)は、静岡県山梨県に跨る活火山である。標高3776.24m、日本最高峰(剣ヶ峰)[注釈 1]の独立峰で、その優美な風貌は日本国外でも日本の象徴として広く知られている。数多くの芸術作品の題材とされ芸術面で大きな影響を与えただけではなく、気候や地層など地質学的にも大きな影響を与えている。懸垂曲線の山容を有した玄武岩成層火山で構成され、その山体は駿河湾の海岸まで及ぶ。数百万年前から火山活動を営んでおり、山頂部には高温火砕物によって形成された竪琴状の堆

出力が長かったので今回は指定したトークン数で終わりませんでした。すごい、完璧な情報だ……なんかwikipediaにありそうな文章だな……と思ってwikipediaを見たら完全に同じでした。こんなに完全に記憶しているものなんですね。(商用利用可能モデルですが、著作権侵害のリスクもありそうですね。)

参考 ja.wikipedia.org

りんご1個が100円のとき、りんご4個を買うといくらになりますか?

100×4=400円です。<|endoftext|>

言語モデルには苦手とされる計算問題も簡単なものなら解けるみたいです。感動ものです。

現時点での限界

  • 今回学習したパターンではopen QA以外のタスク(追加のコンテキストを必要とするタスク)の性能が微妙でした。うまく学習できている方もいるのでハイパラチューニングなどが必要なのかもしれないです
<user>: ACESのビジョンはなんですか?
<context>: ACESは、「アルゴリズムで社会はもっとシンプルになる」というビジョンのもと2017年に立ち上がった東京大学松尾研発のAIスタートアップです。Deep Learningを用いて属人化しているヒトの知見を数式化し、幅広い業界のAI事業の開発を推進しています。
<cyber LLM>: この課題では、以下の2つの問いに答えることが求められています。

 1. ACESは何を実現しようとしているのか。

 2. ACESの技術的な特徴は何か。<|endoftext|>
  • repetition_penalty をデフォルトの値(1.0)にすると結構出力が繰り返される現象が見られました
  • 学習時のハイパラにセンシティブかもしれないです
    • 結局alpaca-loraのデフォルトが一番いい感じになりました
    • あるトライアルでは失敗してあんまりいい感じの出力が出なかったです

まとめ

本ブログ記事ではCyberAgent社がリリースした open-calm-7b モデルのfinetuneを行いました。今までリリースされた日本語モデルと比べてダントツに回答のクオリティが高くて感動するレベルです。特に、コンテキストを利用しないで回答させた場合のクオリティはかなり信頼できるものが出てくると感じました。

自分の学習の設定に問題があるのかもしれないですが、コンテキストを利用した回答生成はあまりうまくいかなかったのでこの辺りはfuture workにしようと思います。

CyberAgentさんが今回のモデルをリリースしたことで日本語LLMのオープン化の流れが一段と加速したように思います。デベロッパーとしてはうれしい限りです。今後もこの流れが続くと日本語LLM界隈が盛り上がっていいなと思っています。

弊社ではLLM技術を始めとして自然言語を扱えるエンジニアを募集しています。ご興味ある方は以下のリンクから是非ご応募ください。

www.wantedly.com

www.wantedly.com


  1. 英語で事前学習したのちに日本語でfinetuneした7BモデルはNovelAI社からリリースされています。こちらのモデルは学習コーパスがなろう小説を含んでいて、なかなかラノベチックな文章を生成してくれます。
  2. 英語で学習されたモデルを日本語でfinetuneするという方法もあるのですが、日本語での知識がどうしても不足していて、不自然な文章が生成されたり、問いかけに対して頓珍漢な回答をしたり、文章が繰り返してしまうなどの現象が起きることが多いです。また、英語で学習したモデルは日本語のトークン効率が悪く、英語と同じ内容を持つ文章であっても、英語と比べてトークン数が増えやすい(=計算コストの増加、出力トークン数の減少)傾向があり、長い文章を扱いづらいなどの問題もあります。(これは厳密にはLLMの問題というよりtokenizerの問題ですが。)