LLMとo1-proで品質とコストを向上させる ✨
はじめに
ソフトウェア開発において、高品質とコスト削減を両立するのは容易ではありません。さらに、時間が経つにつれて溜まる技術的負債を、いかに先送りせずに解消できるかが、プロダクトの持続的成長を左右します。⚡
そこで注目されているのが、LLM(大規模言語モデル) と o1-pro を組み合わせたアプローチです。特に o1-pro は要件やアーキテクチャ情報を参照してくれますが、ChatGPTのプロジェクト機能を併用してコンテキストをしっかり管理すると、両者のパフォーマンスが一気に引き上がります。
ただし、人間が最終判断を行い、LLMとの役割分担を明確にしないと、かえって混乱や手戻りを引き起こす恐れもあります。❗
本記事では、人間(PM/PL/TL/エンジニア/QA)と LLM/o1-pro の棲み分けを示しつつ、全体フローのシーケンス図や設計レベルでのIssue管理・テスト充実の方法をまとめます。さらに、ユースケース例やデジジョンテーブルを使い、ChatGPTでのプロジェクトベースのコンテキスト管理とo1-proとの連携により、品質向上とコスト削減をどのように実現できるかを具体的かつ詳細に紹介します。✨
1. 人間とLLMの役割分担
まずは、誰がどの工程をリードし、LLM・o1-proがどの部分を支援してくれるかを全体的に整理しておきます。
単なる「補佐」ではなく、それぞれが得意領域を活かす点が重要です。⚙
工程/タスク | 主担当(最終責任) | 補助(LLM / o1-pro 等) | 具体例 |
---|---|---|---|
要件定義 / エピック作成 | PM (ビジネス視点) | o1-pro(過去ドキュメント照合), LLM(提案) | - PMがユーザーストーリーや受け入れ基準(AC)を策定 - o1-proが既存ドキュメントや要件と照合 - LLMが文言調整や追加アイデアを提案 |
基本設計レベルのIssue作成 | PL (プロジェクトリーダー) | o1-pro(アーキ情報参照), LLM(不足観点提案) | - PLが機能間の連携・API仕様をIssue化 - o1-proが要件IDや関連Issueとの重複を検知 - LLMが不足している観点や設計パターンを補足 |
詳細設計レベルのIssue作成 | TL (テックリーダー) | o1-pro(ドキュメント照合), LLM(コード例) | - TLがクラス・DB設計を具体化→Issue化 - o1-proが関連資料と照合し衝突を指摘 - LLMがサンプル実装や最適化案を提示 |
コーディング & レビュー | エンジニア / QA(レビュー支援) | LLM(コード生成), o1-pro(要件比較) | - エンジニアが実装→ git diff で差分- o1-proが要件IDやACとの不整合を検知 - LLMと壁打ちし、不足修正やリファクタ案を適用 |
テスト計画 & テストケース整備 | QA (品質保証担当) | LLM(テスト雛形生成), o1-pro(要件照合) | - QAがテスト方針やシナリオを策定 - LLMがユニット/E2Eテストコードの雛形を生成 - o1-proがIssueや要件IDとの整合を自動チェック |
リファクタリング & 負債解消 | TL / エンジニア | LLM(壁打ち), o1-pro(差分比較) | - コード変更後に git diff → o1-proで要件比較- LLMにリファクタ提案をもらい、人間が可否判断 - テスト充実でデグレを早期発見し、負債を先送りしない |
⚠ 注意ポイント: LLMやo1-proに任せきりではなく、あくまで最終決定は人間が行うことで、混乱・手戻りを防ぎやすくなります。✋
2. 全体フローのシーケンス図
下記のシーケンス図は、PM/PL/TL/エンジニア/QA という「人間のロール」と、o1-pro・LLM という「AIツール/システム」のやり取りを可視化したものです。⚡
開発プロセスをこのように可視化すると、どのタイミングで誰が何をするかが明確になり、LLMやo1-proとのコラボレーションが円滑に進みます。♻
3. git diff をテキスト化して o1-pro と連携
3.1 差分抽出コマンドとワークフロー
# mainブランチと featureブランチの差分を diff.txt に書き込む
git diff main...feature/awesome-feature > diff.txt
-
diff.txt
を o1-pro のプロジェクト機能にアップロード -
o1-pro が Issue/要件 との照合を自動実行
- 「Issue #123 のACが実装されていない?」「REQ-001との整合が崩れている?」などを指摘
- 不足箇所は LLM と壁打ち → 人間が最終調整 ✋
3.2 レビュー負荷を大幅軽減
- 従来の目視レビューが減り、仕様漏れや実装不足を早期発見
- LLMでコード生成やリファクタ提案を受け、人間が最終判断することでバグを減らしつつ工数削減
- さらに、o1-pro は差分を要件に紐付けて自動解析するため、「このIssueのACテストコードが不足している」など具体的な指摘が得やすい
4. 設計レベルでIssueを管理する意義
4.1 基本設計と詳細設計の分割
- PLが基本設計Issue: 機能間連携、外部API、データフローなどを大まかにまとめる
- TLが詳細設計Issue: クラス構造、DBスキーマ、メソッド仕様などを細かく設計
- エンジニアはこれを参照しつつ LLM に「実装手法」「エラーハンドリング例」などを質問しながら進める
4.2 ChatGPTのプロジェクト機能(コンテキスト管理)との連携
ここでは、従来「o1-proのプロジェクト機能」としていた箇所を、ChatGPTが提供するプロジェクト機能によるコンテキスト管理に置き換え、o1-proがそこから情報を取得する流れを説明します。
-
プロジェクト単位でコンテキストを保持
- ChatGPTのプロジェクト機能を利用し、要件定義やアーキ情報、Issue一覧、非機能要件などを一括管理
- 開発中に追加・変更された情報もプロジェクトに追記することで、LLMが常に最新コンテキストを参照できる
-
要件・Issueの一元管理で o1-pro の指摘が爆発的に向上
- o1-proは、ChatGPT内に蓄積された大規模なコンテキストを活用できる
- たとえば「要件ID REQ-200 のACに反しているのでは?」といった高度な指摘も、プロジェクト全体像を把握できるため素早く行える
- プロジェクト機能を使わずに断片情報だけだと、o1-proの検索対象が限定され、精度が下がる恐れもある
-
新規Issue作成時の自動チェック
- ChatGPTのプロジェクト機能に登録済みの設計情報・ドキュメント・過去のIssueを参照し、重複や矛盾があれば自動で警告 ✋
- PL/TLは、ChatGPT(LLM)とやり取りして追加修正し、o1-proが「問題解決したか」まで追随
-
コード差分(git diff)の照合
- 開発ブランチの差分ファイル
diff.txt
をChatGPTプロジェクトに取り込み → o1-proがそこから抜け漏れを発見 - 「この変更は Issue #305 の受け入れ基準AC-2に合致していないかも?」など、プロジェクト全体の情報を活かした横断的な指摘が可能
- 開発ブランチの差分ファイル
-
ドキュメント更新提案
- コードやアーキが変わった場合、プロジェクトに登録している設計書やAPI仕様が古くなる可能性あり
- o1-proが差分を検知して「要件文書#R003を更新すべきかも」と提案 → ChatGPT(LLM)に「更新内容のドラフトを生成して」と依頼
- 人間が承認する流れで、ドキュメントの陳腐化を防止できる
パフォーマンス向上のポイント:
- 大量の情報を1つのChatGPTプロジェクトに集約すると、LLMがコンテキストを見失わず、o1-proも包括的な関連性を評価しやすくなる
- 断片化した状態ではo1-proが発見できない問題も、プロジェクト全体を俯瞰することで「既存要件との不整合」「他のIssueで類似パターンが存在」などを爆速で検出可能
5. テスト充実とリファクタリング
ここからが今回のブラッシュアップポイントです。o1-pro と LLM を活用することで、テストの品質を高めながら、リファクタリングにも強い開発体制を構築できます。⛑️
5.1 テストケース自動生成
- QA がテスト戦略・方針(ユニット/結合/E2Eなど)を決定
- LLM に境界値テストや異常系テストコードをまとめて生成依頼
- o1-pro が Issue/要件ID と突合 → テストカバレッジ漏れを警告
- 人間(QA, エンジニア)が補足修正して最終化
5.1.1 テストカバレッジの管理
- o1-pro は「どのテストがどの要件ID/IssueIDをカバーしているか」を可視化し、抜け漏れを自動検知
- ユニットテストからE2Eまで、一貫して紐づけが可能
- カバレッジ率をグラフ化して表示するなど、プロジェクト全体の品質状況を把握しやすい
5.1.2 CI/CDとの連動
- JenkinsやGitHub ActionsなどのCI/CDパイプラインでテストを実行 → 結果をo1-proに連携し、要件IDごとの合否を自動記録
- LLM と連携することで、テスト結果のログから「エラー原因の推定」や「追加テストの提案」を受けることも可能
- 人間はレポートを確認し、合否・要改善点を最終判断する
5.1.3 境界値 & 負荷テスト
- LLM へ「境界値テストのリストを提示して」「負荷試験ケースを生成して」と依頼すると、初期サンプルが得られる
- o1-pro が「負荷試験用Issue(#xxx)」や「性能要件(REQ-PERF-010)」と照合し、カバレッジ不足を指摘
- 負荷テストの自動スクリプトもLLMに生成依頼 → 人間が調整
5.2 リファクタリングに強い体制
- 充実したテスト → コード変更直後にデグレを検知
- o1-pro が差分と要件を突合し、想定外の改修をアラート
- LLM がリファクタ案を提示し、最終判断は人間 → 必要な部分だけ反映
5.2.1 こまめな負債解消
- テストが網羅されていれば、小さなリファクタもすぐに検証できる → 負債を後回しにしなくて済む✨
- o1-proが「このクラスはIssue#210で予定していた内容と矛盾かも?」といった設計レベルの指摘をするため、設計ドキュメントも継続的に更新
- QAがテスト再実行→合格時点でデプロイOK → スムーズなリリース
5.2.2 テストの再利用 & 追加提案
- リファクタ後でもテストケースを使い回し → 機能が大きく変わっていなければ、同じテストセットで回すだけ
- 変更点が多いときはLLM が新たなテストコードの差分を提案 → o1-pro がそれをIssue/要件に紐付けて管理
- 結果として、リファクタのたびにテストが拡張され、バグ温床を根こそぎ除去できる⚡
5.2.3 技術的負債を先送りしないメリット
- いつでも安全に改修できる環境 → 大掛かりなリファクタもタイミングを逃さない
- 後から「この部分は影響範囲が読めずに放置…」とならない
- チームの士気が下がらず、長期的なコスト削減にもつながる
ポイント: リファクタリングは小さく・こまめに行うのがベスト。o1-proとLLMによる抜け漏れ検知と自動テスト生成支援は、そのこまめなリファクタを支える強力な仕組みとなります。⏫
6. Issue & テストケースの実例(ユースケース例 & デジジョンテーブル)
ここでは、Amazonの商品検索APIを題材に、o1-proがプロジェクト機能を使って自動検知・管理しそうな項目を示します。さらに、デジジョンテーブル(決定表)を使ったテストケース整理手法を紹介し、o1-proのメリットが分かるように補足します。⚙
6.1 基本設計レベルのIssue(Amazon商品検索API)
-
概要
- 検索キーワードを基に商品を抽出し、JSON形式で返す
- ソートオプション(価格昇順/降順、人気順など)に対応
-
ユースケース/フロー
- UC-1: ユーザーがキーワードを入力して検索
- UC-2: サーバ側が該当商品をDBまたは検索インデックスで取得し、JSONで返却
- UC-3: 件数が多い場合はページングで分割(1ページあたりX件)
- UC-4: レートリミットを設定し、過度な連続アクセスをブロック(例: 429返却)
- 関連要件ID: AMZ-SEARCH-001 (キーワード検索), AMZ-SEARCH-002 (ソート機能)
-
o1-proでの自動チェック
- 在庫API(Issue #105など)と衝突・重複がないか?
- UI要件(Issue #112)で定義した1ページの表示件数と整合性があるか?
- パフォーマンス要件(REQ-PERF-010)で定義した応答速度2秒以内を満たせるか?
6.2 詳細設計レベルのIssue(Amazon商品検索API)
-
処理ステップ
- 認証トークンチェック → 無効なら 401
- 検索条件バリデーション → 不正なら 400
- DB/インデックスクエリ & ページング → items[], currentPage, totalPages
- レートリミット → 超過時 429
- 予期せぬ障害 → 500
-
o1-proの自動照合ポイント
- 「AMZ-SEARCH-002(人気順)が未実装?要追加Issueでは?」
- レートリミットは別Issue(#210)にも記載 → 衝突や未整合がないか?
-
異常系
- 400, 401, 429, 500
- o1-proは、この異常系パターンがテストケースで網羅されているかチェック可能
6.3 デジジョンテーブルを用いたテストケース例
デジジョンテーブル(決定表)を使って、複数のパラメータや条件を整理します。
ここでは、トークン有効/無効、ソートオプション、ページング範囲、レートリミットなどを組み合わせてテストケースを導出します。
No | トークン有効? | ソートオプション | ページング範囲 | 想定される他条件 | 期待結果 |
---|---|---|---|---|---|
1 | ○ (valid) | price_asc / price_desc | 範囲内 (page=1〜5) | レートリミット通常 | 200 OK, 該当商品一覧返却 |
2 | ○ (valid) | popularity | 範囲内 (page=1〜5) | レートリミット通常 | 200 OK, 人気順で商品一覧 |
3 | ○ (valid) | 未定義の文字列 ("hoge"等) | 範囲内 | - | 400 Bad Request |
4 | ○ (valid) | price_asc | 範囲外 (page=9999) | - | 200 OK (items=[]) or ページ数超過の扱い |
5 | × (invalid token) | price_asc | 範囲内 | - | 401 Unauthorized |
6 | ○ (valid) | price_asc | 範囲内 | 短時間大量アクセス → レート超過 | 429 Too Many Requests |
7 | ○ (valid) | price_asc | 範囲内 | DB障害 (内部設定) | 500 Internal Server Error |
8 | ○ (valid) | price_asc | 範囲内 (page=1) | 空キーワード (query="") | 200 or 400 (仕様次第、要確認) |
- No1/2: 正常系。キーワードが有効で、ソート指定が正しく、ページ数も範囲内
- No3: 未定義ソート → 400
- No5: トークン無効 → 401
- No6: レートリミット超過 → 429
- No7: DB障害 → 500
- No8: 空キーワードや特殊文字 → 200 or 400かは仕様に依存
6.3.1 o1-pro がカバーしてくれる点
-
要件カバレッジのチェック
- AMZ-SEARCH-002(ソート機能)がすべてのオプションをテストしているか?
- レートリミットIssue(#210)で設定した閾値分テストされているか?
-
依存Issueとの連携
- 認証無効時に401を返す設計が、AuthAPI (Issue #015) の仕様と食い違いないか?
-
未定義パターンの自動提案
- 「404エラーはないの?」「特殊文字検索にUTF-8外文字はどう扱う?」などを気づかせる
-
テスト結果の集計とレポート
- テストツールからの成功/失敗ログを取り込み、要件IDごとのカバレッジを自動算出 → QAやTLに通知
デジジョンテーブルをきっちり作り込むことで、複数条件の網羅を確実にでき、o1-proの照合機能と組み合わせると効率的で抜け漏れの少ないテストが期待できます。💯
7. まとめ
-
人間が主担当、LLMとo1-proが補助
- PM/PL/TL/エンジニア/QA それぞれが工程をリードし、最終判断を下す
- LLMはコード生成・提案、o1-proは要件・ドキュメント照合で支援
-
全体フローのシーケンスを明確にしてチームの理解を統一
- git diff → o1-proで要件比較 → LLMで修正案 → 人間が採否判断
-
設計レベルでIssueを作成し、コンテキストを明確化
- 基本設計(PL)と詳細設計(TL)で粒度を分け、エンジニアが実装しやすい環境を整える
- ChatGPTのプロジェクト機能を活用してドキュメント一元管理 → o1-proが横断的に要件照合
-
テスト充実でリファクタリングにも強い開発体制
- QAとLLMがテストケースを自動生成 & デジジョンテーブルで組合せ網羅
- 小さく・こまめなリファクタを推進し、長期的なコスト削減と品質向上を両立✨
Discussion