---

title: "From issue titles to requirements an empiricalに見るコンテキスト設計"

description: "OSSのissueタイトルからソフトウェア要件定義書を自動生成する実証研究を技術的に読み解きます。GPT-4oとGemini 1.5 Proを対象に、プロンプト戦略・評価指標・実装上の注意点を整理します。"

meta_description: "LLMがissueタイトルから要件定義書を生成できるか検証した実証研究を解説。プロンプト設計・評価指標・RAG連携・実装上の注意点をまとめます。"

date: 2026-06-06

tags: ["LLM開発", "RAG", "LLMアプリ開発", "プロンプトエンジニアリング"]

---

From issue titles to requirements an empiricalに見るコンテキスト設計

何が出たのか

2026年6月初旬、arXivに公開された論文「From issue titles to requirements: an empirical study of large language models and prompt engineering strategies」が、Hacker NewsやRedditのr/MachineLearningで取り上げられ、LLM活用の実務寄りな検証として注目を集めています。

この研究が扱うのは、OSSプロジェクトのissueトラッカーに投稿された機能リクエストのタイトル（例：「Add dark mode support」）という、極めて短くて曖昧なテキストを入力として、構造化されたソフトウェア要件定義書（Software Requirements Specification、以下SRS）を自動生成できるかどうかという問いです。

対象モデルはGPT-4oとGemini 1.5 Proの2つ。プロンプト戦略としては、ゼロショット・フューショット・Chain-of-Thought（CoT、思考の連鎖を明示的に促す手法）・RAG（Retrieval-Augmented Generation、外部知識を検索して補完する手法）の4パターンを組み合わせて評価しています。評価指標にはBLEU・ROUGE（テキスト類似度の自動評価指標）に加え、人手評価も取り入れており、単純なテキスト一致だけでなく要件としての妥当性も測定しています。

結論を先に述べると、RAGとCoTを組み合わせたプロンプト戦略が最も高い評価スコアを記録しており、issueタイトルという極端に短いコンテキストを補完するためのコンテキスト設計の重要性を実証的に示しています。

---

技術的に面白い点

入力の極端な短さが設計上の核心

通常のLLMアプリケーション開発では、入力テキストにある程度の情報量があることを前提にします。しかしこの研究では「Add dark mode support」のような5〜10語程度のタイトルだけを入力とします。これはプロンプト設計において、モデルが補完すべき情報量が非常に大きいことを意味します。

この状況でゼロショットプロンプトが機能しにくい理由は明確で、モデルが「何のソフトウェアか」「どのユーザーが対象か」「既存の機能との関係は何か」といったドメイン知識を持たないためです。フューショット（少数の例示を与える手法）を加えると出力の形式は安定しますが、内容の具体性は依然として低い傾向が示されています。

RAGによるコンテキスト補完の効果

この研究で特に注目すべきは、RAGの使い方です。検索対象として使われているのは、同一プロジェクトの既存issueや過去のコミットメッセージ、READMEといったリポジトリ内のドキュメントです。つまり、外部の汎用知識ではなくプロジェクト固有のコンテキストを動的に注入しています。

これにより、「dark mode」というキーワードから「このプロジェクトはElectronベースのデスクトップアプリであり、既にテーマ切り替えのAPIが存在する」という情報を取得し、それを要件定義の前提として組み込む流れが実現されています。BLEU・ROUGEスコアの改善幅はRAGなしのCoTと比較して約15〜20%程度（論文内の数値）であり、コンテキストの質が出力品質に直結することが数値で確認できます。

CoTとRAGの組み合わせによる構造化効果

CoTプロンプトでは「まずissueの背景を推定し、次にユーザーストーリーを定義し、最後に受け入れ条件を列挙せよ」という思考ステップをプロンプト内に明示しています。これをRAGで取得したコンテキストと組み合わせると、出力が単なる箇条書きではなく、IEEE 830形式（ソフトウェア要件定義の標準フォーマット）に近い構造を持つようになると報告されています。

GPT-4oとGemini 1.5 Proの比較では、GPT-4oが人手評価において一貫して高いスコアを示していますが、Gemini 1.5 Proは長いコンテキストウィンドウ（最大100万トークン）を活かして、大規模リポジトリのドキュメントをそのまま注入するアプローチで差を縮めています。この点は、RAGのチャンク分割設計を省略できる可能性を示唆しており、実装コストとのトレードオフとして興味深いです。

---

既存の流れとの違い

従来のissue自動処理との差分

issueの自動分類・優先度付け・重複検出といったタスクにLLMを使う研究は2023〜2024年頃から多数存在します。しかしそれらの多くは分類タスクであり、既存のラベルや優先度に当てはめる処理です。本研究は生成タスクとして要件定義書を出力する点で異なります。

また、GitHub Copilotなどのコーディング支援ツールがissueから実装コードを生成するアプローチとも異なります。本研究は実装の前段階、つまり「何を作るべきか」を文書化するフェーズを対象にしており、要件定義〜設計フェーズのオートメーションという文脈に位置づけられます。

プロンプト戦略の体系的比較という貢献

個別のプロダクトや社内ツールでRAGやCoTを使っている事例は多いですが、同一タスク・同一データセット上で4つの戦略を横断比較した実証研究は少ないです。特に「入力が極端に短い場合にどの戦略が有効か」という問いへの答えは、実務での設計判断に直接使える知見です。

2026年6月時点でのLLM開発の文脈では、モデルの能力向上よりもプロンプト設計とコンテキスト管理の最適化がROI（投資対効果）を左右するという認識が広まっています。本研究はその認識を実証データで補強するものとして、コミュニティでの評価が高い理由の一つになっています。

---

実装・運用で気になる点

RAGのインデックス設計とレイテンシ

実装を検討する際にまず考慮すべきは、検索対象のインデックス設計です。本研究ではリポジトリ内のissue・コミット・READMEを対象にしていますが、実際のプロダクトでは更新頻度が異なります。issueは毎日追加され、READMEは月次程度の更新、コミットは日次〜週次といった具合です。

これらを単一のベクトルDBに混在させると、検索精度の管理が複雑になります。更新頻度ごとにインデックスを分離し、検索時にマージするアーキテクチャが現実的です。また、issueタイトルからの検索クエリ生成にも一工夫が必要で、タイトルをそのままクエリにするより、CoTの最初のステップで「背景推定テキスト」を生成してからそれをクエリにする二段階アプローチが有効です。

レイテンシについては、RAG+CoTの組み合わせでは検索1回＋LLM推論1回の直列処理になるため、エンドツーエンドで5〜15秒程度の応答時間を想定しておく必要があります。リアルタイムUIに組み込む場合はストリーミング出力とスケルトンUIの組み合わせが必須になります。

評価パイプラインの設計

BLEU・ROUGEは実装が容易ですが、要件定義書の品質評価としては限界があります。「正しい単語が含まれているか」は測れても「要件として実装可能か」「曖昧さがないか」は測れません。本研究が人手評価を併用している理由はここにあります。

実務での継続的評価を考えると、LLM-as-a-judge（別のLLMに評価させる手法）を使った自動評価パイプラインが現実的です。評価観点として「具体性」「実装可能性」「曖昧さの有無」をルーブリック（評価基準表）として定義し、それをシステムプロンプトに組み込む形が一般的です。ただし評価LLM自体のバイアスや一貫性の問題があるため、定期的な人手サンプリングとの組み合わせが推奨されます。

プロンプトのバージョン管理とフォールバック

CoT+RAGのプロンプトは複雑になりがちで、モデルのバージョンアップや検索結果の変化によって出力品質が変動します。プロンプトをコードと同様にバージョン管理し、変更時には回帰テストを走らせる仕組みが必要です。

フォールバックとして、RAGの検索結果が空または低スコアだった場合にゼロショットに切り替えるロジックを実装しておくことも重要です。新規プロジェクトや情報が少ないリポジトリでは検索結果が期待通りに得られないケースがあり、その場合に出力品質が急落するリスクがあります。

セキュリティとデータ管理

issueトラッカーには未公開の機能計画や顧客情報が含まれる場合があります。RAGのインデックスに取り込む範囲をアクセス権限と連動させる設計が必要で、特にプライベートリポジトリのデータを外部LLM APIに送信する場合はデータ処理契約（DPA）の確認が必須です。ログについても、入力のissueタイトルと検索されたコンテキストを記録する際に、機密情報のマスキングを検討してください。

---

Spectralの見解

1. 技術的な読み

この研究が示す最も実用的な知見は、入力の情報密度が低いほどコンテキスト設計の差が出力品質に直結するという点です。issueタイトルのような短い入力は、社内の問い合わせフォーム・チケットシステム・営業メモなど、実務でよく遭遇するデータ形式と共通しています。RAG+CoTの組み合わせが有効であることは、これらの類似タスクにも適用できる汎用的な知見として読めます。

一方で、GPT-4oとGemini 1.5 Proという特定モデルでの検証であるため、他のモデルやオープンソースLLMへの転用時には再検証が必要です。また、評価データセットがOSSプロジェクトに限定されているため、クローズドなエンタープライズシステムへの適用では分布の違いに注意が必要です。

2. PoCで確認すべき点

• 検索精度の確認自社データでRAGを構成した際に、issueタイトルから適切なコンテキストが取得できるかをヒット率とランキング精度で測定する。
• 出力の一貫性同一入力に対して複数回推論した際の出力のばらつきを確認し、温度パラメータ（temperature）の調整が必要かを判断する。
• 評価基準の合意「良い要件定義書」の定義をチーム内で合意し、LLM-as-a-judgeの評価ルーブリックに落とし込む作業をPoC初期に行う。

3. 業務・プロダクト実装に移す時のリスク

• 品質のばらつきリスクモデルのバージョンアップやRAGのインデックス更新によって出力品質が変動するため、継続的な評価パイプラインなしに本番投入すると品質劣化の検知が遅れます。
• 過信リスク生成された要件定義書を人間がレビューせずに実装に渡すフローは避けるべきです。本研究の人手評価でも、自動スコアが高い出力でも実装観点での問題が残るケースが報告されています。
• データガバナンスリスクRAGのインデックスに取り込む情報の範囲とアクセス制御を設計段階で決めておかないと、後から修正コストが大きくなります。

Spectralでは、このような実証研究の知見を自社データに当てはめる技術調査から、プロトタイプ構築・評価設計まで一貫して支援しています。

---

まとめ

「From issue titles to requirements」は、LLMに渡す入力が短く曖昧な場合でも、RAGによるプロジェクト固有コンテキストの注入とCoTによる思考ステップの明示化を組み合わせることで、構造化された要件定義書の生成品質が向上することを実証した研究です。

実装観点では、RAGのインデックス設計・レイテンシ管理・評価パイプラインの整備・プロンプトのバージョン管理が主な論点になります。特に「入力情報が少ない」という条件は、社内システムや業務ツールでよく遭遇するシナリオであり、この研究の知見は要件定義自動化以外のタスクにも転用できます。

2026年6月時点では、モデル単体の性能よりもコンテキスト設計と評価の仕組みをどう作るかがLLMアプリケーションの実用化を左右する段階に入っています。本研究はその判断を支える実証データとして、実装設計の参照点になります。

関連論点として LLMSurgeon Diagnosing Data Mixture of Largeに見るコンテキスト設計 もあわせて読むと、この技術動向の背景を追いやすくなります。

Spectralでは、技術調査からPoC設計、プロダクト実装まで支援しています。実現性の確認や事業活用の相談は サービス詳細 と お問い合わせ をご覧ください。