o1 pro を1週間使った感想と課題、それを乗り越えるVSCode拡張の話
先日、月額 200 ドルで話題の o1 pro を1週間ほど試してみました。率直な感想としては、エンジニアの開発ワークフローを根本から変える大きな可能性を秘めていると感じています。
私はこれまで、GPT-4o (または Claude 3.5 Sonnet) と GitHub Copilot を組み合わせ、「補助的なコーディング支援」として活用してきました。しかし o1 pro は、その枠を超えた全く新しいワークフローをもたらしてくれました。具体的には以下のような流れです。
- o1 pro と協力して機能の設計を行う
- o1 pro に全体のコードを実装してもらう
- 人間がレビューしつつ、必要に応じて GPT-4o や GitHub Copilot で修正を加える
実際、このワークフローにより、100 万行規模の CSV ファイルをデータベースに効率良くインポートする機能(チャンキングなどの工夫が必要)をほぼ o1 pro に任せて実装できました。驚いたのは、適切なインプットを与えるだけで、実用レベルのコードが一発で生成されることです。これまでの「LLM に小規模なコード断片を手伝ってもらう」という使い方とは次元が異なる感覚でした。
一方で、こうした性能をフルに発揮させるためには、タスクに必要な情報やコードをあらかじめ詳細に伝える必要があります。特に、複数ファイルをまたぐ既存コードを大きな LLM に渡すのは煩雑で、開発スピードを落とす大きな要因でした。
この記事では、o1 pro を1週間使ってみて感じた所感と課題、そしてその課題を乗り越えるために開発した VSCode 拡張 「Contextualize」 をご紹介します。
1. o1 pro を1週間使ってみた所感
o1 pro を導入してまず感じたのは、LLM を使った開発スタイルが大きく変わったことです。従来は GPT-4o や Claude 3.5 Sonnet でユーティリティ関数や小規模なコードを生成してもらう「補助的な使い方」が主流でした。しかし o1 pro では、設計から実装までの流れを一貫して任せるという新たな可能性が見えてきました。
具体的な作業フローを比較すると、以下のようになります。
-
従来の方法
- (GPT-4o などを適宜活用しつつ) 人間が全体の設計を考える
- 必要に応じて小さな関数やロジックを LLM に生成してもらう
- 出力されたコードを手作業で統合・調整する
-
o1 pro 導入後の方法
- o1 pro と一緒に機能全体の設計を行う
- o1 pro にコード全体を実装してもらう
- 人間がレビューし、必要に応じて修正や改善を加える
特に驚いたのが、比較的長いコードでも、一度の出力で動くコードを生成してくれる点です。たとえば、100 万行規模の CSV をデータベースに効率良くインポートする機能を実装した際には、データのチャンキングや非同期処理など、複雑なロジックをほぼ完成形の状態で返してくれました。もちろん、実際には o1 pro の使い方を試行錯誤しながらだったので、何度かプロンプトやアプローチを変える必要はありましたが、慣れれば数回のやり取りでほぼ完成形を得られる可能性を感じています。
o1 pro の登場により、「設計から実装までを大部分 LLM に任せ、人間はレビューと最適化に注力する」という新しい開発スタイルが、現実的な選択肢として急速に立ち上がってきたと思います。
2. o1 pro を使う中で見えてきた課題
優れた出力を引き出すためには、適切なインプットが不可欠です。ここで言う「インプット」とは、タスクの仕様や要件だけでなく、既存コードやプロジェクト固有の文脈などを十分に伝えることも含まれます。実際に o1 pro を使ってみて、最も大きく感じた課題がこれでした。
2-1. 良い出力には十分なコンテキストが必要
LLM は、プロジェクト特有の文脈や業務領域の専門知識をあらかじめ備えているわけではありません。そのため、以下のようなケースでは特に、関連コードや特有の規則を LLM に事前に明示する必要があります。
- 既存コードとの整合性を保ちつつ、新機能を実装する場合
- プロジェクト固有のコーディング規約や利用パターンに準拠するコードを生成する場合
十分な情報を事前に与えられなければ、LLM は適切なコードを出力できません。複数ファイルにまたがるコードが存在する場合、その内容をすべてプロンプトに取り込む作業が不可欠です。
2-2. 複数ファイルのコンテキストを渡す煩雑さ
o1 pro に既存コードの文脈を渡そうとすると、ディレクトリ内に点在する複数のファイルをコピペでプロンプトに貼り付ける必要があり、非常に面倒です。ファイル数が多くなればなるほど、その作業は開発スピードを大幅に削ぎます。
- 例:10 個以上の関連ファイルがあるディレクトリ構成
- それらをまとめて LLM に理解させるため、手作業で一つずつコピペ
これでは、せっかくの高性能な LLM も活かしきれません。
2-3. インプットを効率化する必要性
最終的に痛感したのは、「良い出力を得るには、良いインプットを効率的に提供できる仕組みが要る」という点です。大量のコードを素早く、そして正確に LLM に渡す方法がなければ、開発スピードは頭打ちになってしまいます。コードベースが増えれば増えるほど、この問題は深刻化します。
こうした課題を踏まえて開発したのが、次に紹介する VSCode 拡張「Contextualize」 です。
Contextualize」
3. 課題を解決する VSCode 拡張「前述の課題を解決するため、ディレクトリ内のコードをまとめてテキスト化し、LLM に渡しやすくする VSCode 拡張 「Contextualize」 を開発しました。これにより、手間のかかるプロンプトの準備作業を効率化し、o1 pro のポテンシャルを最大限に引き出せるようになります。
Contextualize の主な機能
3-1.-
ディレクトリ全体のスキャンとコードの一括取得
- 指定したディレクトリ配下のファイルを再帰的に走査し、1 つのテキストファイルとしてまとめます。
- コード構造がひと目で分かるディレクトリツリーも自動生成し、各ファイルの内容はそのまま挿入します。
-
TypeScript ファイルに型情報を注釈する (オプション)
- TypeScript ファイルを対象に、
import
文から推定される型情報をコメントとして自動追加する機能を提供します。 - 外部依存や型が明示されることで、LLM により充実したコンテキストを渡すことが可能になります。
- TypeScript ファイルを対象に、
-
LLM 出力の一括適用
- o1 pro などの LLM がマージコンフリクト形式(
<<<<<<< ORIGINAL ... ======= ... >>>>>>> UPDATED
)でコードを出力した場合に、一括で適用できる仕組みを備えています。 - 手作業でコンフリクト箇所をマージする手間が大幅に省けるため、o1 pro を活用した開発をさらに効率化できます。
- o1 pro などの LLM がマージコンフリクト形式(
-
カスタムプロンプトの生成
- テンプレートを事前に用意しておくことで、複数のファイルをまとめたうえで LLM に投げる際のプロンプトを自動生成します。
- プロンプトの作成作業を省力化しつつ、より的確なインプットを与えられるのがメリットです。
3-2. まとめと機能拡張への期待
o1 pro を1週間使ってみた結果、「適切なインプットさえ用意できれば、設計から実装までを LLM に任せる新しい開発スタイルは実現可能だ」と強く感じました。人間はレビューと微修正に専念できるため、従来のワークフローと比べて大幅な効率化が見込めます。
Contextualize は、この「新しい開発スタイル」を支えるためのツールとして開発しました。今後も、o1 pro をはじめとする LLM の新しい活用法を追求しながら、Contextualize 自体にも機能を追加していく予定です。
もし興味を持っていただけたら、ぜひ試してみてください。使ってみた感想や改善アイデア、要望などがあれば、GitHub リポジトリ への issue や PR で気軽にフィードバックをお寄せいただけると嬉しいです。
Discussion