Jira でエージェント型エンジニアリングを使用する
エージェント型エンジニアリングは Jira で稼働します。エンジニアリングがコードの記述から AI エージェントの操作へと移行するにつれて、重要な作業も変化します。今では、開発者がコードの記述に費やす時間は約 16% に過ぎません。エージェントが構築の多くを担うようになったため、困難な作業とは、構築自体ではなく、その周辺のあらゆることを指すようになりました。つまりエージェントへのコンテキストの提供、エージェントの調整、出力のレビュー、そしてエージェントの管理です。
これらは、Jira が常に管理してきたエリアであり、現在ではそれがエージェントにも拡張されました。Jira と Teamwork Graph はそのための記録システムであり、チームの規模が拡大するにつれて、AI アクティビティを生産性の向上へと繋げるために必要なレイヤーです。
本ガイドでは、Jira がエージェント型エンジニアリングをどのようにサポートするか、他のツールとどのように連携するか、そしてその始め方についてご説明します。簡単に言えば、Jira はコーディング エージェント単独では提供できない 3 つの要素を提供します。
エージェントが正確に対応できるように、適切なコンテキストを提供する
ルーチン作業を、自動化された権限対応フローに委任する
Teamwork Graph 内に責任の所在が明確となる記録を保持する
エージェント型エンジニアリングとは
エージェント型エンジニアリングとは、自分でコードを 1 行ずつ書くのではなく、目標を設定して結果を評価する一方で、複数のステップから成る作業を計画して実行する AI エージェントに指示を出すことでソフトウェアを構築する手法です。
これにより、労力を注ぐ対象が、コードの記述からエージェントが作業するシステムの設計へと変わります。何を構築するかを指定し、エージェントにコンテキストを提供して、作業中に方向付けを行い、出力が基準を満たしているかを判断します。AI オートコンプリートが次の行を提案するのに対して、単一のエージェントが記述された成果からプル リクエストまで一貫して処理できます。エージェント型エンジニアリングはその上位レイヤーという位置づけになります。多数のエージェントを拡張してオーケストレーションし、その作業を調整して、リリースされるものを管理します。
そのため、エージェント型エンジニアリングは単なるコーディングの分野にとどまらず、調整と判断を必要とします。エージェントがコーディングやタスクの実行を担う場合、そのアクセス、アクション、出力は、チームがすでに信頼している制御の範囲内に留まる必要があります。ここで提起される課題は、コーディングに関する課題というよりも、むしろ作業管理に関する課題です。そのため、Jira のような記録システムに依存しています。
Jira はエージェント型エンジニアリング向けに構築されているか
Jira は、AI エージェント全体で作業の計画、調整、拡張を行う手法である、AI ネイティブなソフトウェア開発向けに構築されています。Jira がエージェント型エンジニアリングを "サポート" しているかと質問されるとき、真に問われるべきは、Jira がエージェントの作業をコンテキストに基づいて位置づけし、その作業を調整、レビュー、管理するためのレイヤーになり得るのかということです。それこそがまさに Jira の得意とすることであり、コーディング エージェント単体ではできないことです。
コーディング エージェントは変更を記述しますが、何を構築すべきかの決定、結果が基準を満たしているかの判断、その作業が進行中の他の作業とどう関連しているかについての考慮は行えません。これらは作業管理であり、チームの決定事項です。1 人のマシン上に存在するコーディング エージェントはその人のためだけに機能しますが、人とエージェントのチームには、共通の連携、可視性、そして信頼できる唯一の情報源が必要です。Jira はそのレイヤーを担っています。計画を保持し、作業を適切なエージェントにルーティングし、リリースされるものを人が管理できるようにし、将来の作業に役立つ永続的なコンテキストとして発生した事象を記録します。これは、作業が Jira で進むにつれて行われます。開発者が追加の手順を実行する必要はありません。
コーディング エージェント単体にはない、Jira がもたらすものとは
コーディング エージェントに実際の仕様を渡しても、脱線してしまうことがあります。決定事項を忘れて、完了した作業をやり直し、コンテキスト ウィンドウの制限に苦戦します。計画を markdown ファイルに保存したところで、問題は解決しません。より優れたエージェントを使っても結果は同じでしょう。こうした状況を解決するのが、仕様と状態をエージェントのメモリの外部に保持するシステムです。これにより、チーム全体で相乗効果が生まれます。そのため、エージェント型エンジニアリングは実際にはコーディング ツールの選択ではなく、記録システムの選択となるのです。Jira はそれ自身がこのようなシステムであるため、次のような機能を活用できます。
コネクタにより、ツールチェーンを Teamwork Graph に連携させます。MCP は、その組織の知見を各チームがすでに利用している AI と連携させます。
人間とエージェントの作業にわたる単一の記録システム。エージェントは作業中に Teamwork Graph 全体で読み書きを行い、タスクに関するすべての決定事項や記録を更新するため、ローカル セッションでコンテキストが失われることはありません。
ガバナンスが企業における既存の制御を継承。エージェントのアクセスは、企業がすでに信頼している権限モデルに従うため、こうした制御がエージェントの作業に自動で適用され、新たに管理すべき対象になりません。
あらゆるエージェントやモデルを一元化。Claude、Cursor、Codex、GitHub Copilot、またはネイティブの Jira コーディング エージェントに作業を割り当て、1 か所で管理します。エージェントは既存のワークフロー内で作業するため、エージェントが変わってもプロセスは変わりません。単一のコーディング エージェントでは 1 つのベンダーに縛られますが、Jira はエージェントに依存しません。
チケットだけでなく、スタック全体を対象としたコンテキスト エンジニアリング。Teamwork Graph は、Jira、Confluence、コード、そして Slack や Teams のように実際に作業が議論されるツール全体の作業項目、決定事項、履歴に基づいてエージェントが動作できるようにします。そのため、エージェントは情報不足のプロンプトではなく、実際の意図に基づいて行動します。つまり、Jira はエージェントを取り巻くコンテキスト レイヤーです。
エージェントの作業に単一の制御プレーンを提供。コーディング エージェントは独自のセッションで実行され、計画やチームの他の作業から切り離されています。Jira はそのレイヤーを追加することで、開発者の日常に手順を増やすことなく、エージェントがピックアップする内容を決定し、適切なコンテキストをフィードし、各コーディング セッションをエージェントが実行する作業に結び付けます。記録システムは何が起きたかを記録するのに対し、制御プレーンは背後でエージェントを指揮し、作業を接続します。
AI ネイティブなソフトウェア開発ライフサイクル全体における Jira の位置づけ
Jira は、計画、連携、レビュー、拡張という 4 つの段階にわたってエージェントの作業をサポートします。安全性を維持するためのガバナンスと権限を確保したうえで、作業をエージェントが対応可能な項目として計画し、複数のエージェントを連携させてその作業に取り組ませ、成果物をレビューおよびテストし、それらのパターンを組織全体に拡張します。それぞれの段階で Jira が行うことは次のとおりです。
計画: 作業をエージェント対応にする
ワンクリックで計画やドキュメントを提案された作業項目に変換して、承認前に必要に応じてレビューや調整を行います。
計画では、意図をエージェントが対応可能な作業へと変換します。つまり、明確な要件と受け入れ基準を記載した実際の仕様を作成し、エージェントが着手する前に必要となるコンテキストを提供します。
どこで始まった作業でもキャプチャします。Slack のスレッド、Confluence ページ、Loom の録画、会議など、あらゆる場所からリクエストが届きます。@Jira をメンションするか、Rovo を使用して、その場で作業項目に変換できます。受付は再入力の手間を省くだけではありません。会話から始まったものであっても、曖昧なリクエストを、チームの作業にどのように適合するかを示す Teamwork Graph からのコンテキストを備えた作業項目に変換します。
単なるプロンプトではなく、明確に定義された仕様をエージェントに提供します。仕様駆動型開発では、仕様が基準となる入力です。エージェントは、セッション後に失われる単発のプロンプトではなく、仕様に基づいて作業項目に取り組みます。その仕様はコードベース、チームの標準、プロジェクトの履歴と連携して機能するため、エージェントはチームの標準に適合するコードを作成するために必要なコンテキストを得ることができます。Jira Planner は、Teamwork Graph、コードベース、Confluence の履歴を使用して仕様の草案を作成します。その後、内容を推敲して受け入れ基準を追加することで、この仕様はエージェントが構築を行うための基盤となり、レビューの基準として使用されます。
エージェントにコンテキストを提供し、そのコンテキストは蓄積されます。コンテキストは、エージェントの品質の上限を決める真の制約です。Jira は Teamwork Graph を活用して、チケットだけでなく、使用しているツール全体から得られるゴール、決定事項、履歴に基づいてエージェントが動作できるようにします。Jira はあらゆる MCP エージェントと連携し、そのコンテキストは蓄積されます。システムを通じてより多くの作業が実行されるほど、エージェントが活用できる情報が増え、結果の品質が高まります。
連携: 複数のエージェントに作業を割り当て、連携させる
ネイティブの Jira コーディング エージェントをはじめとするエージェントに作業を 1 か所から割り当てます。
最適なエージェントに作業を割り当て、そのエージェントの行動を指示および監督するすべての操作を、チームがすでに作業を追跡している場所から実行できます。
あらゆるエージェントに 1 か所から作業を割り当てます。作業項目を Claude、Cursor、Codex、GitHub Copilot、またはネイティブの Jira コーディング エージェントに割り当て、Web、IDE、ターミナル セッション全体でエージェントが実行したアクションや下した決定を確認できます。これにより、フローを中断することなく、早期にズレを検知して修正できます。
すでに作業している場所でエージェントを使用できます。チームが使用しているツール上で連携を実行できます。Slack で @Jira をメンションして作業項目を作成し、修正ループを開始したり、Cursor、Claude Desktop、または任意の MCP クライアントを Jira のコンテキストに接続したり、エージェントに CLI/ターミナル アクセスを付与してコンテキストからアクションに移動したりできます。
定型作業を自動化します。自動化ルールやワークフロー トランジションからエージェントをトリガー (またはボードの列にエージェントを追加) すると、ステータスが変わったときに自動的に作業をピックアップし、同じワークフローを通じて出力をルーティングして戻すことができます。まずは、定型的で反復的な作業から始めましょう。
エージェントのアクティビティが作業に紐付けられ、常に表示されます。エージェントが作業を進めている間、そのアクティビティと作成したプル リクエストは作業項目にリンクされたままになります。そのため、別のツールではなく作業が存在する場所で進捗を確認できます。各エージェントがピックアップした作業、作成した成果物、レビュー待ちのタスクを、すべて 1 か所で確認できます。
レビュー: エージェントの出力を検証する
エージェントの出力をレビューする際は、人間が関わり続けるステップを含める必要があります。
エージェントの出力は完成しているように見えても間違っている可能性があるため、リリース前に必ず人間がレビューし、テストし、承認する必要があります。
テストと検証を行います。エージェントの出力も、通常のチェックを通過する必要があります。これらのチェックは CI パイプラインで実行され、そのステータスは作業項目に表示されるため、レビュー段階で、作業が検証されるまで完了へのトランジションを保留できます。この一部を自動化できます。エージェントは自身の出力に対してチェックを実行し、パスするまで反復を続けてから人の手に渡します。
人間が介在するレビューをワークフローに組み込みます。人間によるレビューは必須です。出力は作業項目に表示され、人間が承認するまで完了にトランジションできません。プル リクエストとそのレビュー ステータスは作業項目の開発パネルに表示されます。つまり、追跡している場所でレビューを行えます。
マージして、リリースされた内容を記録します。レビューを通過すると、変更がマージされ、作業項目は完了に移動します。接続されたツールでマージおよびデプロイが実行されます。Jira が記録を保持します。
拡張: 長期的に、複数のチームでエージェントを安全に運用する
単一の作業システムは、組織全体への拡張において、より大きな成功につながります。
エージェントの作業を拡張することは、組織レベルの変革です。課題となるのは、1 人の開発者が実行するエージェントを増やすことよりも、エージェントの作業がチーム全体に広がる中で、品質、信頼、可視性を安定して維持することです。
定型業務を委任。反復的でスコープが明確な作業はエージェントがバックグラウンドで処理し、準備が整うとプル リクエストが表示されます。共有権限とセキュリティ基準を通じて、コントロールを維持できます。
イテレーション。エージェント型エンジニアリングは線ではなくループです。結果は次の仕様にフィードバックされ、作業はライフサイクルに再投入されます。そのフィードバックを Jira で収集し、今後の作業の改善に役立てます。
ガバナンスと監査。ガードレールはポリシー ドキュメントではなくワークフロー内に存在し、すべてのアクションは作業項目に監査可能な証跡を残して、Jira 独自の権限によって制御されます。
影響を測定。サイクル期間やプル リクエストのスループットなどのデリバリー データを使用して、AI がチームのリリース方法をどのように変えているかを追跡します。これにより、アクティビティではなく成果を測定し、重要な部分に投資できるようになります。
AI スタックにおける Jira の位置付け
Jira は、コーディング エージェント、IDE、または実行するモデルに代わるものではありません。Jira はそれらを横断する調整および記録レイヤーとなります。これにより、どのツールで構築を行っても、作業は可視化され、管理された状態が保たれます。このレイヤーは、拡張する際に不可欠です。共有の記録システムがなければ、エージェントの作業はツール間で断片化し、生産性を十分に発揮できません。
トピック | Jira の役割 (調整および記録レイヤー) | Jira が担当しないこと (スタック内の他のツールで処理すること) |
計画 | エージェントの作業を計画、分解、優先順位付けする (Jira Planner) | ゴールを設定する (人が「何を」「なぜ」を決定し、Jira がそれを計画に変える) |
コンテキスト | 作業項目と Teamwork Graph からのコンテキストに基づいてエージェントが動作できるようにする | コンテキスト ストアまたはベクトル データベースが別途必要 (Teamwork Graph は管理対象コンテキスト レイヤー) |
連携 | 自動化、ワークフローのトランジション、および割り当てを通じて、作業を適切なエージェントにルーティングし、指示および監督する | エージェントが実際に実行される環境を提供する (エージェント自身のプラットフォームが提供する。Jira Coding Agent の場合は、アトラシアンのサンドボックス) |
モデル | モデルに依存せず、1 か所からサポート対象のすべてのエージェントを制御する (モデルはアトラシアンの AI ゲートウェイが管理する) | モデルをホストする (アトラシアンの AI ゲートウェイがアトラシアンがホストするモデル、ベンダーのモデル、または bring-your-own-key モデルにルーティングする) |
レビューと品質 | 監査可能で権限によって保護された証跡を残しながら、出力をレビューおよび承認プロセスにルーティングする | 出力が正しいことを保証したり、コード自体を記述したりする (ユーザーがレビューとテストを行う) |
チームの調整 | チーム全体の作業を 1 つの共有システムで調整することで、ユーザーとエージェントが同じ信頼できる唯一の情報源からビルドできるようにし、デリバリー データ (サイクル期間、スループット) を使用して影響を測定する | 個別のコーディング作業を行う (作業はコーディング エージェントと IDE 内に保持される) |
依存関係 | チームやサービス間で作業がどのように関連しているかをマッピングして、変更がリリースされる前にエージェントがその影響を確認できるようにする | (IDE とビルド ツールで) コードベースの技術的な依存関係を分析する |
Jira でエージェント型エンジニアリングを始める方法
エージェントが実行したアクションと下した決定を確認します。セッションの全履歴を確認し、ドリフトを早期に発見して、必要に応じて修正します。
始めるにあたって、本格的なロールアウトは不要です。最も早く最初の成果を上げるには、コーディング エージェントを接続し、1 つの小さなタスクを割り当て、エージェントが作成したプル リクエストをレビューするという作業を、すべて 1 つの作業項目から行います。
日常的でスコープが明確なタスクを 1 つ選択します。不安定なテスト、依存関係の更新、または小さなバグ修正から始めるのが最も安全です。
作業項目として記録します。Confluence ページ、Slack スレッド、または短いプロンプトを、要約と説明を含む作業項目に変換します。
エージェントに割り当てます。Git リポジトリを接続し、[Agents (エージェント)] パネルで Jira Coding Agent に作業項目を割り当てます。
プル リクエストをレビューします。エージェントによって作業項目に結び付けられたプル リクエストが作成されます。そのため、計画したのと同じ場所でレビューできます。
自動化します。最初の実行後、繰り返し行うタスクを見つけて、自動化ルールに変換します。最もリターンが大きく、最もリスクが低い「反復的な作業」から始めることをお勧めします。
有利なスタートを切りたいですか? 一度設定するだけで、エージェント型エンジニアリング テンプレートによって、ワークフロー、ステータス、エージェントのステップが組み込まれたエージェント対応のスペースが構築されます。そのため、空白のプロジェクトからではなく、動作中のループから開始できます。うまく機能しているスペースで、すでにエージェント型ワークフローを実行していますか? 有料プランのお客様はそれをカスタム テンプレートとして保存できるため、チームは同じエージェントとワークフローが組み込まれた新しいスペースを立ち上げることができます。
エージェント型エンジニアリングに関するよくある質問
エージェント型エンジニアリングでは、エンジニアは何をするのでしょうか?
エージェント型エンジニアは、AI エージェントに複数ステップの作業をさせる際のゴール、コンテキスト、およびガードレールを定義し、その結果をレビューして承認します。Jira のような記録システムによって連携と説明責任を維持します。
プロンプト エンジニアリングとエージェント型エンジニアリングの違いは何ですか?
プロンプト エンジニアリングは、モデルから適切な応答を得るために単一の指示を作成します。エージェント型エンジニアリングは、タスク全体にわたって計画、実行、反復処理を行うエージェントを連携させます。作業単位は、プロンプトからゴールへと移行します。
コーディング エージェント単体にはない、Jira がもたらすものとは
コーディング エージェントはコードを記述しますが、Jira は作業の定義、優先順位付け、調整、レビュー、管理が行われる 1 つの記録システムです。各作業項目に結び付けられた監査可能な証跡を保持しながら、あらゆるエージェントを調整します。
AI エージェントは Jira からどのようにコンテキストを取得しますか?
エージェントは、作業項目自体 (要件および承認基準) と、関連する作業、ドキュメント、コードを結びつける Teamwork Graph からコンテキストを取得します。これにより、プロンプトに基づく場合だけでなく、実行前にエージェントの役割を明確にできます。
AI がコードを記述する場合でも、Jira は必要ですか?
はい。おそらく、以前よりも必要になります。エージェントがより多くのコードをより速く生成するようになると、制約はその作業の調整、レビュー、管理へと移行します。Jira は、エージェントの出力を可視化して説明責任を明確にし、本来行うべき作業に結び付ける制御プレーンです。