Docs&Code生成ツール"GEAR.indigo"を用いたo1-preview、o1-miniの性能検証
はじめに
- この記事は私が開発しているDocs&Code生成ツール"GEAR.indigo"へのOpenAI o1導入を検討するために行った技術検証についての記事です。純粋なモデル性能の定量・定性分析ではない点を留意ください。
- 検証に利用したモデルはo1-preview、o1-mini、gpt-4o、Claude 3.5 sonnetの4種類です。
- 評価は定性的かつ感覚的なものになります。生成物は可能な限り公開するので詳細は各々でご判断頂けると幸いです。
- 検証結果は後半に記載しているため、概要だけ知りたい方はこちらをご覧ください。
OpenAI o1とは
OpenAI o1は、複雑な推論を実行するために強化学習で訓練された新しいAIモデルシリーズです。高性能なo1-previewと軽量なo1-miniの二つのモデルが用意されており、大まかな特長は以下になります。
- このモデルは、応答する前に考える時間を増やし、科学、数学、プログラミングなどのSTEM分野で高い推論能力を発揮します。
- o1-miniは、基本的能力を維持しつつ処理速度と効率性を向上させた軽量・高速モデルです。
- 新しい安全性学習手法により、安全性と整合性が向上しています。
- o1シリーズは、応答する前により多くの時間をかけて思考するように設計されています。
- 問題を解決する際に人間のように時間をかけて考え、思考プロセスを洗練します。
- 異なる戦略を試し、自分のミスを認識することを学習します。
- GPT-4oと比較して、o1-miniとo1-previewはより正確な回答を提供します。
- o1-miniはo1の約3倍速く正解にたどり着くことができます。
- o1シリーズは科学、コーディング、数学の分野でより難しい問題を解決可能です。
- 物理学、化学、生物学の難しいベンチマークタスクで博士課程の学生と同等の成績を達成
- 国際数学オリンピックの予選試験で83%の正答率を記録。
- コーディング能力はCodeforcesで参加者の上位11%に入る水準。
- STEMタスクで高度な推論力を発揮する一方、言語処理を重視する分野ではGPT-4oの方が優れています。
出展：OpenAI
よくわからないけど賢いモデルが出たらしい、という印象です。
どのLLMベンダーでも同じですが新しいモデルが出た際は（当たり前ですが）どれだけモデル性能が高いかがアピールされるため、読むだけで性能・使い勝手等を理解することは難しいです。
実際に自分のユースケースに合わせて使ってみる、または思いつく限りの使い方を試して使い方を探っていくというアプローチが大切だと思います。
検証概要
目的
冒頭に記載したようにこの技術検証は私が開発しているDocs&Code生成ツール"GEAR.indigo"に対するOpenAI o1導入を検討するために実施しました。
GEAR.indigoについては次項で簡単に説明します。
GEAR.indigoについて
GEAR.indigoはPDFや簡単なテキストから要件定義書・設計書・ソースコードを段階的に生成できるツールです。
要件定義書・設計書の生成ではプロジェクト概要、業務フロー、業務要件一覧、機能要件一覧、テーブル定義、画面一覧などSIerによるシステム開発に準拠した項目が生成されるため、開発するシステムの解像度を高めるだけでなく、チーム開発におけるコミュニケーションを円滑にします。
開発時にChatGPT gpt-4o、Gemini 1.5 Pro、Claude 3.5 sonnetの3モデルを比較検討した結果、いずれの項目においてもClaude 3.5 sonnetの出力が高品質かつ安定していたため、基本的にはClaude 3.5 sonnetを採用しています。
検証方法
検証はドキュメントとソースコードそれぞれに分けて実施しました。
ドキュメント（要件定義書・設計書）
テキストは入力せずGEAR.indigoのピッチデックから要件定義書を生成し、生成された項目をもとに基本設計・詳細設計のドキュメントを生成しました。
生成時は普段プロダクトに使用しているClaude 3.5 sonnetに加えて比較対象用のgpt-4o、そして今回新たに追加されたo1-preview、o1-miniの2種類を使い、計4種類のドキュメントを生成しました。
要件定義書の生成
ドキュメント生成のステップ
ソースコード
ソースコード生成はClaude 3.5 sonnetから生成されたドキュメントをもとに行いました。
ドキュメント・ソースコードを同じモデルで生成して比較を試みたのですが、生成されるファイルが異なり同一条件下での比較が難しかったため、同じドキュメントから生成したソースコードで比較しています。
ソースコード生成画面
生成結果
ドキュメント（要件定義書・設計書）
テキスト
"about_project": "簡単なテキストやPDFから開発ドキュメントやソースコードを生成するAIツールであるGEAR.indigoのプロジェクトです。",
"current_system": "現在 開発ドキュメントやソースコードの作成には多くの時間と労力が必要となっています。",
"problems": "ドキュメントやソースコードの作成に手間がかかり 開発期間が長くなっていることが問題です。"
"scope": "開発ドキュメントの作成時間の短縮やソースコードの自動生成による開発立ち上げの迅速化を実現します。",
"direction_of_solution": "AIを活用してドキュメントやソースコードを自動生成し 開発プロセスを効率化します。",
"user_of_system": "新規事業企画者 開発者 営業担当者などのシステム開発に関わる人々です。",
"organization": "Stellaps Inc.のTech lead Biz Engineerが参加しています。",
"budget": "予算は未定です。",
"schedule": "プロジェクト開始は2023年10月 リリース予定は2024年4月です。",
"about_project": "GEAR.indigoは簡単なテキストやPDFファイルから開発ドキュメントやソースコードを生成するAI搭載の開発ツールです。このツールはステップバイステップで作成されたドキュメントからソースコードを生成し、実装工程の立ち上がりを大幅に加速します。",
"current_system": "現在のシステムでは開発ドキュメントやソースコードの作成が手動で行われており、時間と人手が多くかかっています。",
"problems": "手動でのドキュメント作成やコード生成は時間がかかり、人的リソースを多く必要とするため、開発期間が長くなりコストが増加します。"
"scope": "システムが解決する問題は開発期間の短縮と人月工数の削減です。また、要件定義やシステム設計のドラフト作成を自動化することで、コミュニケーション工数も削減します。",
"direction_of_solution": "AIを活用してドキュメント生成とソースコード生成を自動化し、開発プロセスを効率化します。",
"user_of_system": "主なユーザーは新規事業開発部、開発チーム、営業チームです。",
"organization": "Stellaps Inc.",
"budget": "未定",
"schedule": "未定",
"about_project": "このプロジェクトは、AIを活用して開発ドキュメントやソースコードを自動生成するツール「GEAR.indigo」の導入を目指しています。具体的には、シンプルなテキストやPDFファイルからドキュメントを生成し、そのドキュメントを基にソースコードを自動で生成することで、開発プロセスのスピードと効率を大幅に向上させることを目的としています。",
"current_system": "現在のシステムでは、要件定義からシステム設計、コーディング、テストまで各フェーズで多くの手作業が必要とされ、時間と労力がかかっています。特にドラフト作成やコミュニケーションに多くのリソースが消費されています。",
"problems": "現行のプロセスは手動による作業が多いため、ミスが発生しやすく、開発期間が長期化する傾向があります。また、効率的なドキュメント作成とコード生成ができないため、プロジェクト全体のコストが高くなっています。"
"scope": "このシステムは、新規事業企画、開発、営業の各分野において利用可能です。特に要件定義書・システム設計書の作成およびドキュメントからのソースコード生成に焦点を当てています。",
"direction_of_solution": "GEAR.indigoを導入することで、ドキュメントやソースコードの自動生成を行い、効率的な開発プロセスを実現します。これにより、手作業によるミスを削減し、開発期間を短縮することができます。さらに、AIによる高度な解析と独自のアルゴリズムにより、高品質なドキュメントとコードを生成します。",
"user_of_system": "このシステムの主な利用者は、新規事業企画担当者 開発者 営業担当者です。それぞれのユーザーが効率的にドキュメント作成やコード生成を行うことができます。",
"organization": "プロジェクトの体制は、Tech Lead エンジニア ビジネス担当者からなるチームが担当します。それぞれの専門知識を活かし、効率的なプロジェクト運営を行います。",
"budget": "プロジェクトの予算は、システム開発費用 AIツール購入費 トレーニング費用などを含めて計画しています。詳細な金額は別途見積もりを行います。",
"schedule": "プロジェクトは2023年10月開始を予定しており、約6ヶ月間でのシステム導入を目指しています。具体的なスケジュールは要件定義 フェーズ 設計フェーズ 開発フェーズ テストフェーズ 導入フェーズに分けられます。"
"about_project": "GEAR.indigoは簡単なテキストやPDFファイルから開発ドキュメントとソースコードを生成するAI駆動の開発ツールです。開発プロセスを加速し 工数を大幅に削減することを目的としています。",
"current_system": "現在の開発プロセスは手動で行われており 要件定義からコーディングまでに多くの時間と労力を要しています。",
"problems": "従来の開発手法では時間がかかり 人的リソースの負担が大きく コストが高くなる傾向があります。また 各工程間の整合性維持が難しく 品質にばらつきが生じる可能性があります。"
"scope": "GEAR.indigoは要件定義 システム設計 開発 テストの各工程におけるドラフト作成を支援し 開発期間の短縮と工数削減を実現します。",
"direction_of_solution": "AIを活用して開発ドキュメントとソースコードの自動生成を行い 開発プロセスを効率化します。Step by stepでドキュメントを生成し それをもとにソースコードを生成することで 高品質な成果物を短時間で作成します。",
"user_of_system": "主な利用者は新規事業企画部門 開発部門 営業部門を想定しています。各部門で要件定義書作成 ソースコード生成 クライアントへの提案資料作成などに活用できます。",
"organization": "Stellaps Inc.が開発元となっています。具体的な組織体制の記載はありませんが 新規事業開発部 開発部門 営業部門が関与していることが示唆されています。",
"budget": "予算に関する具体的な記載はありませんが 開発工数の大幅な削減（-30%から-50%）を目指していることから コスト削減効果が期待できます。",
"schedule": "プロジェクトのスケジュールに関する具体的な記載はありませんが ツールの即時性を考慮すると 比較的短期間での導入が可能と推測されます。"
マーメイドフロー
o1-preview
o1-mini
gpt-4o
Claude 3.5 sonnet
機能要件一覧
o1-preview
o1-mini
gpt-4o
Claude 3.5 sonnet
画面デザイン
o1-preview
o1-mini
gpt-4o
Claude 3.5 sonnet
より詳細にドキュメントをご覧になりたい方がいらっしゃいましたら、GEAR.indigo内のプロジェクトページから閲覧できるよう設定するのでXにてDM頂けると幸いです。
ソースコード
Githubのリポジトリは以下となります。
※未修正のため動かすにはローカルでの編集が必要です。
o1-preview:
o1-mini:
gpt-4o:
Claude 3.5 sonnet:
検証結果
性能に対する所感
総合評価は
Claude 3.5 sonnet >= o1-preview > gpt-4o > o1-mini
です。
項目別にみると以下になります。
| o1-preview | o1-mini | gpt-4o | Claude 3.5 sonnet | |
|---|---|---|---|---|
| テキスト | 〇 | △ | 〇 | 〇 |
| マーメイドフロー | 〇 | × | 〇 | 〇 |
| 要件一覧 | ◎ | △ | 〇 | ◎ |
| 画面デザイン | 〇 | △ | △ | ◎ |
| フロントエンド | 〇 | 〇 | △ | ◎ |
| バックエンド | 〇 | 〇 | 〇 | 〇 |
マーメイドフローの設計や要件一覧などところどころでo1-previewが少し賢いかな、という印象ではあるものの多くの項目でClaude 3.5 sonnetが優れていると感じることが多かったです。
o1-previewが優れていると感じた点はインプットから膨らませる能力です。例えば画面遷移・画面一覧を出力する際、いくつかの項目をもとに一覧を生成するのですが、他のモデルでは入力項目の内容に即した一覧を出力するのですが、o1-previewの場合は入力項目の内容をもとに足りない要素を補って出力している印象でした。
またo1-miniについては正直に言うとこのラインナップの中では明確に劣っているように感じました。
多くの項目で内容が薄かったです。他LLMベンダーの軽量モデルと比較すると優秀だと思うのですがコスト的にはClaude 3.5 sonnetと同クラスと考えるともう少し頑張ってほしかった気がします。
なおコーディングについてはgpt-4oのみフロントエンドのコードがやや崩れていたこと、Claude 3.5 sonnetのデザイン力が優れていること以外は差がなかったように感じます。
前々から言われているようにClaudeはReactを重点的に学習しているため、やはりフロントエンドの実装力は高いです。
一方賢いとされているo1-preview、コーディングが得意とされているo1-miniでは武骨で崩れ気味の実装となってしまいました。このことから少なくともフロントエンドにおいてはモデル性能よりも学習データの方が出力品質に大きな影響を与えると推察しており、ファインチューニングの重要性がより一層高まっているように思います。
バックエンドにおいても同一コードを比較したときにより優れたコードが書かれているようには感じませんでした。ただ数学能力、コーディング能力が高いと言われるo1の面々なのでプロンプト改善によって品質が高まる可能性があると考えています。
プロダクトへの影響
性能だけで見ればo1-previewの導入を考えてもいいのですが、コスト・生成時間を鑑みると現時点での導入は保留です。
o1はモデル自身で回答を内省し新しい回答を生成するという特徴があるため、公式でも言われているように深い推論が必要なタスク処理＝抽象的なタスク処理が向いているように感じました。
現在のGEAR.indigoは要件定義・設計の項目を細分化しそれぞれを生成できるようになっており一つ一つの処理が軽量化されているため、深い推論を実行したところでアウトプットの品質の向上に大きな影響はなかったものと考えています。
（とはいえ品質向上の余地はまだまだ残されていると思いますが、、、）
o1活用の方向性
前項で現時点での導入は保留と結論付けましたが、導入自体をあきらめるということではありません。
先ほど書いたようにアウトプット品質の向上が見られなかった原因は一つ一つの処理が軽量化されていることにあると考えているため、o1導入により現在のGEAR.indigoで解決できていない深い推論が必要なフローを組み込める可能性があると考えています。
具体的には
- ドキュメント各項目のうちどの項目を取り込むかの判断
- 生成されたプログラムファイルにおける依存関係の判断
- 項目生成中の分岐ワークフロー設定
- 要件定義におけるアプローチ手法の選定
- ソースコード生成におけるフレームワーク選定
などに使える可能性があると考えており、引き続き検証していければと思います。
Special Thanks
末筆ながら謝辞となりますが、本検証はHooksさんにAPI key及びAPI利用料をご提供頂いて実施致しました。
私はo1モデルを利用可能なAPI keyを入手できるステータス（Tier）ではなかったため、本検証を実施できる環境をご提供頂いたこと、この場を借りて改めて御礼申し上げます！
Discussion