コーディング エージェント向けコンテキスト エンジニアリング

コンテキスト エンジニアリングとは、コーディング エージェントがアクションを起こす前に何を見るかを決定する作業です。高性能なモデルであっても、そこに与えられるデータ次第でその真価が決まるため、これは出力の品質を左右する最大の要因となります。

Jira では、エージェントが必要とするコンテキストはすでに作業の一部になっています。作業項目にはゴールと受け入れ基準が含まれており、Teamwork Graph がそれをコード、意思決定、関連ドキュメントに結び付けるため、エージェントは空白のプロンプトではなく、実際の意図に基づいて実行します。そのコンテキストは 1 つのマシンのローカル ファイルにとどまるのではなく、チーム全体で共有されます。

このガイドでは、コンテキスト エンジニアリングとは何か、コンテキスト ウィンドウがコーディング エージェントにとって真の制約である理由、そしてすべてのプロンプトにおいて手作業で情報を与えなくてもエージェントが必要な情報を取得できるように Jira でコンテキストをエンジニアリングする方法をご説明します。実際には、すでに進めている作業において、次のようなアクションをいくつか実行します。

• エージェントに対して、単なるプロンプトではなくゴールを与えます。Jira の作業項目を仕様として記述し、エージェントの評価基準となる受け入れ基準を含めます。

• グラフによって、関連するコンテキストが提供されます。プロンプトの出発点として作業項目を使用することで、Teamwork Graph はそれをタスク周辺のドキュメント、決定事項、関連コンテキストへと展開します。

• 標準を共有して、最新の状態に保ちます。Confluence で規則が管理され、すべてのエージェントとチーム メイトが同じ情報源を参照します。

• すべてのエージェントに対して、同じコンテキスト レイヤーを提供します。同じ組織のコンテキストが、Claude Code、Cursor、Codex、GitHub Copilot、Jira Coding Agent など、すべてのコーディング エージェントに対して共有されます。

コンテキスト エンジニアリングとは

コンテキスト エンジニアリングとは、コーディング エージェントが正確に作業できるよう、各ステップでモデルに参照させる情報を意図的に設計する手法です。対象となる情報はプロンプトだけではありません。コードベース、標準、依存関係、Git 履歴、ツール定義、ゴール、受け入れ基準なども含まれます。各タスクに応じて必要な情報を選び出し、適切に与えること自体が新たな仕事になっています。

プロンプト エンジニアリングとは、情報を厳選し、それを自分で 1 つの指示として入力することを指します。一方のコンテキスト エンジニアリングは、複数のステップを持つタスク全体でエージェントが必要とするもの (入力するもの、取得するもの、要約するもの、除外するもの) がシステムによって提供され、エージェントが必要に応じて残りの情報を見つけられるようにします。

コンテキストは多ければ多いほど良いわけではありません。

• 高シグナルなコンテキストとは、目の前のタスクを行うのに役立つ情報のことです

• 低シグナルなコンテキストとは、モデルが依然として読み込む必要がある、古くて無関係である、または重複したコンテンツのことです

コンテキスト ウィンドウが低シグナルのトークンで満たされると、モデルは変わっていなくても、回答が遅くなり、精度が下がります。その劣化はコンテキストの腐敗と呼ばれます。これは、コンテキスト ウィンドウが古いトークン、低シグナルのトークン、または矛盾するトークンで満たされるにつれて、出力が徐々に低下する現象です。優れたコンテキスト エンジニアリングでは、適切なコンテキストを追加することと同じくらい、古いコンテキストを排除することが重要です。

コンテキスト ウィンドウがコーディング エージェントの制約となる理由

コーディング モデルはコンテキスト ウィンドウに収まる内容についてのみ推論できますが、これはコードベース、ドキュメント、チームの履歴と比較すると小規模です。チームの規約、アーキテクチャ、またはタスクの背景にある決定事項がウィンドウに含まれていない場合、優秀なエージェントであっても、誤ったコードや安全でないコードをリリースしてしまうことがあります。

コンテキストの収集をエージェントに委ねると、次のような失敗のパターンが繰り返し発生します。

• より新しく、低シグナルのトークンが蓄積するにつれて、初期に下した決定がコンテキスト ウィンドウから押し出されてしまうため、長いタスクにおけるエージェントの処理が遅れます。

• 過剰に情報を取得し、使用するよりもはるかに多くの情報をウィンドウに取り込んで、トークンの予算をノイズに費やしてしまいます。

• ユーザーが提示した以外の標準を一切認識せずに、チームの他のメンバーが従っているパターンに反するコードを出力します。

• 単独では問題なく機能しますが、同じエリアでチームの他のメンバーや別のエージェントが何をしているのかを把握できません。

適切なコンテキストに簡単にアクセスできるようにすれば、エージェントが作業を進めながら必要な情報を自ら見つけ出せます。これにより、すべての規則や決定事項を手動で詳細に記述する必要がなくなり、プロンプトを高レベルな状態に保てます。

Jira でコーディング エージェント向けのコンテキストを構築する方法

Jira では、作業自体がコンテキストになります。作業項目内に意図が存在し、周辺のナレッジは Teamwork Graph を通じて接続され、永続的な標準や決定事項は Confluence や Loom から取り込まれるため、すべてのエージェントとチーム メイトが同じソースから情報を引き出せます。Jira は、1 つのマシンのローカル ファイルにとどまらず、ゴール、進行中の意思決定や会話、そして作業全体の履歴にまで及びます。すべての情報を共有された状態に保つため、エージェントが対応する際のコンテキストは、チーム全体で構造化され、最新かつ一貫したものになります。

コンテキスト エンジニアリングは、次の 3 つの原則に基づいています。

1. 適切な情報の選択

2. 構造化の維持

3. 永続性

1. 選択と取得: 作業項目を仕様として記述する

選択とは、タスクに対して最小限かつ高シグナルのコンテキストのセットを選ぶことです。一方、取得とは、最初にすべてをウィンドウに詰め込むのではなく、必要に応じて適切な事実を引き出すことです。Jira では、どちらも作業項目から始まります。

• Jira での仕組み: ゴールを説明に記載して、受け入れ基準をチェックリストに記載します。これにより、意図と評価の基準が、エージェントの読み取れる構造で提供されます。次に、作業項目を接続されているエージェントに割り当てます。コードベース全体からではなく、作業項目とそれにリンクされたコンテキストから始まります。仕様を洗練させるためにエージェントとスパーリングを行うことも作業の一部です。エージェントは大量の情報を素早く読み取り、開始前にギャップを見つけるのに役立ちます。

• 近日公開: Jira Planner は、コンテキストが付与された状態で、アイデアをエージェントがすぐに実行できる計画や作業項目に変換します。待機リストにご登録ください。

2. コンテキストの共有: 作業を貼り付けるのではなく、リンクする

構造とフォーマットが鍵となります。エージェントが情報を探し出せるようにコンテキストを形成し、コピーするのではなく、接続が維持されます。Teamwork Graph は、その都度、手作業で情報を集める必要をなくし、周辺の状況を把握できるようにします。

• Jira での仕組み: 作業項目を、関連する作業項目、コード、さらには仕様、RFC、または決定記録を含む Confluence ページにリンクします。エージェントは、チケットのテキストだけでなく、タスクに関するコンテキストも引き継ぎます。Loom のウォークスルーも対象になります。記録されたバグの再現や設計の根拠は、そのトランスクリプトと要約がグラフに取り込まれるため、チーム メイトに行うような説明が、エージェントが読み取れるコンテキストになります。これは、別途構築して保守する必要があるベクトル ストアからではなく、実際の作業から「正確に検索された事実」が提供されます。

3. 永続性: 相乗効果を発揮する場所に基準や決定事項を維持する

永続性、またはメモリとは、エージェントが毎回ゼロから開始しなくて済むように、セッション間で永続的な事実を利用可能な状態に保つことです。考慮すべき 3 つのカテゴリとして、タスク中にエージェントが保持するもの、タスク間で保持すべきもの、必要に応じて参照できるものがあります。

• Jira での仕組み: 規則、アーキテクチャの決定、推奨されるパターンは、共有の Confluence スペースに保存されます。これにより、チーム全や各エージェントは、他の誰も閲覧できない特定の個人のマシン上のコピーではなく、グラフを通じて同じ情報源から情報を取得できます。システムで作業が処理されるにつれて、グラフがより充実するため、次のエージェントがより多くの情報を活用できるようになります。作業が進むにつれてコンテキストが蓄積されるため、開発者が手作業により追加のステップを踏む必要もありません。

チーム全体で連携して業務を行う上で重要な要素は、すべてのエージェントが使用できる 1 つのコンテキスト レイヤーと、それを信頼性が高く適切な権限が設定された状態に保つガバナンスです。

あらゆるエージェントに対応する単一のコンテキスト レイヤー

構築したコンテキストは、すべてのツールで利用できてこそ価値があります。各エージェントに基準を個別に再設定すると、コンテキストが再び失われてしまう可能性が高くなります。

• Jira での仕組み: 任意のコーディング エージェントに同じ組織コンテキストを提供するための方法は 2 種類あります。Teamwork Graph CLI を使用すると、コーディング エージェントはターミナルからそのコンテキストとツールに直接アクセスできるようになります。一度セットアップすれば、エージェントは作業中にグラフを照会できます。Atlassian Rovo MCP サーバーは、Claude、Cursor、Codex、GitHub Copilot などの MCP クライアントに対しても同様に機能します。いずれの場合でもそれを支えるのが Teamwork Graph です。作業項目、決定事項、ドキュメント、コードが、クエリ可能な 1 つのレイヤーとして接続されています。コンテキストを一度構築すれば、作業を行うどのモデルでも使用できます。

ガバナンス: 信頼でき、かつ許可された状態でコンテキストを維持する

コンテキストは、最新であり、エージェントに閲覧が許可されている場合にのみ役立ちます。共有レイヤーを活用するエージェントが増えたとしても、ガバナンスによって共有レイヤーの信頼性は維持されます。

• Jira での仕組み: エージェントは、チームがすでにベースラインとして使用しているものと同じ権限を継承します。そのため、エージェントはそのチームが表示できる内容のみを閲覧し、それ以上は閲覧しません。また、エージェント固有のルールを使用してさらに範囲を絞り込むことができます。アクセス、承認、監査がどのように連携するかについては、Jira におけるエージェント型エンジニアリングのガードレールと安全性を参照してください。

コンテキスト スタックにおける Jira の位置付け

今日、コーディング エージェントのコンテキストのほとんどは 1 台のマシン上に存在します。そのコンテキストとは、そのエージェントが開いているリポジトリ、いくつかのローカル ファイル、開発者がプロンプトに入力した内容です。それは単独の作業では機能しますが、分散され、それぞれに囲い込まれると忘れられてしまいます。Jira と Teamwork Graph は、重要なコンテキストを、チーム全員とそのエージェントが利用する、共有された最新の管理可能な 1 つのレイヤーに集約します。

このいずれも、コーディング エージェント、IDE、またはローカル設定に代わるものではありません。リポジトリごとの詳細と実際のコードはそれらが引き続き処理します。Jira は最上位の共有レイヤーであるため、全員が作業のベースとするコンテキストが構造化され、チーム全体で同じ最新の状態が保たれます。

Jira で最初のエージェントに実際のコンテキストを提供する方法

コンテキスト エンジニアリングとは、最終的には、エージェントが自ら必要なものを見つけるためのツールと情報をエージェントに提供することです。Jira と Teamwork Graph は、エージェントが MCP または CLI を介してアクセスする共有コンテキスト レイヤーであるため、そのレイヤーを正確でつながった状態に保つことが必要です。

1 つの適切に構成された作業項目から始めて、推測で作業するエージェントと意図に基づいて作業するエージェントの違いを確認してみましょう。

1. エージェントの評価基準を設定します。独立したリファクタリングや小さなバグ修正など、簡単に元に戻せる、範囲が限定された低リスクのタスクを 1 つ選択し、目標を説明に記載して、受け入れ基準をチェックリストに記述します。

2. コンテキストを貼り付ける代わりに、エージェントに継承させます。コミットするランチ、コミット、またはプル リクエストで作業項目キーを参照して作業項目をそのコードに結び付けて、その背景にあるドキュメントや決定事項をリンクします。エージェントは、チケットのテキストだけでなく、タスクに関してリンクされたコンテキストも取得します。

3. 共有の標準を示します。従うべき規則を Confluence ページにリンクして、次のエージェントやチーム メイトが同じソースを使用できるようにします。

4. エージェントに割り当てます。エージェントは、コードベース全体や情報不足のプロンプトよりも的を絞った開始点として、作業項目とそれにリンクされたコンテキストから開始します。

5. 元となった基準に照らしてレビューします。作業項目に記述した承認基準と照らし合わせてプル リクエストを確認し、エージェントに設定した元の基準に対して出力が評価されるようにします。

6. エージェントにループを完結させます。次のチーム メイトやエージェントが Teamwork Graph を通じて中断したところから作業を再開できるように、最後に作業項目をセッションの要約、重要な決定事項とトレードオフ、リンクされたプル リクエストで更新するようにプロンプトで指示します。

この方法でいくつかの作業項目を実行すると、進行に合わせてグラフが埋まっていきます。各エージェントは作業項目に要約、重要な決定事項、およびリンクされたプル リクエストを残すため、次の作業項目は前回よりも全体像が明確な状態で始まります。これは、実行のたびにリセットされるのではなく、蓄積されていくコンテキスト エンジニアリングです。

コンテキスト エンジニアリングに関するよくある質問

コンテキスト エンジニアリングとプロンプト エンジニアリングの違いは何ですか?

プロンプト エンジニアリングとは、単一のプロンプトに対して関連情報を手作業で厳選する手法です。コンテキスト エンジニアリングは、複数ステップのタスク全体で、検索、構造、記憶、ゴールそのものを含む情報をエージェントに提供するシステムを実装し、必要に応じて詳細をオンデマンドで提示できるようにする手法です。

AI コーディング エージェントは Jira からどのようにコンテキストを取得しますか?

エージェントは、作業項目 (およびその説明と承認基準) と、関連する作業、ドキュメント、コードを結び付けける Teamwork Graph からコンテキストを取得します。これにより、エージェントは情報不足のプロンプトではなく、実際の意図に基づいて行動します。

適切なプロンプトを使用しても、コーディング エージェントが誤ったコードを生成するのはなぜですか?

プロンプトに、規則やアーキテクチャ、あるいはタスクの背景にある決定事項が含まれることはほとんどありません。ほとんどのエージェントの失敗はモデルの失敗ではなく、コンテキストの失敗によるものであり、表現を改善するよりも、コンテキストを改善する方が効果的です。

エージェントがすでにリポジトリを読み込んでいる場合でも、コンテキスト エンジニアリングは必要ですか?

はい。リポジトリはエージェントにコードの内容を伝えますが、なぜそのように構築されたのか、どの標準に従うべきか、あるいはチーム全体で他に何が起きているのかについては伝えません。コンテキスト エンジニアリングがその残りの部分を提供します。

コンテキストの腐敗とは何ですか?

コンテキストの腐敗とは、コンテキスト ウィンドウが、古くなったトークン、価値の低いトークン、または矛盾するトークンで満たされるにつれて、エージェントの出力が徐々に劣化することです。モデルは変更されていないにもかかわらず、回答が遅くなり、精度が低下します。