Jira の AI エージェント向けヒューマンインザループ パターン
ヒューマンインザループは、エージェントに任せるビルドの領域が増えても制御を維持するための手段であり、Jira では別個のツールとしてではなく、ワークフロー内に存在します。実際に成果を上げているチームは、人間の判断を重要な意思決定に限定し、それ以外をエージェントに任せています。
そのような判断には、ふさわしい場所があります。Jira は、チームが常に作業を管理し、推進する取り組みを承認してきた場所ですが、今ではエージェントに対しても同じ役割を果たしています。このガイドでは、人間がどこでどのように AI エージェントの制御を維持し、誰が何を担当し、拡張可能な監視をどのように設計するかについて説明します。簡単に言えば、ヒューマンインザループを適切に行うことで、次の 3 つが実現します。
完全に元に戻すことができないアクションをゲート制御する承認
リリース前に低品質な出力や要件に合わない出力を検出するレビュー
エージェントが判断に迷うコールを自動で担当者にルーティングするエスカレーション
AI エージェントのヒューマンインザループとは
ヒューマンインザループとは、AI エージェントが定義されたチェックポイントで一時停止することで、リスクの高い作業が進行する前に人間が作業を承認、修正、または方向転換できるようにするシステム設計のことです。エージェントが定型的な作業を実行するのに対して、人間は実際の結果をもたらす意思決定を制御します。
これは信頼性を高めるためのアーキテクチャであり、AI が失敗したことを示す兆候でも、モデルが十分に良くなったら取り外す一時的な補助でもありません。最高のエージェント システムとは、人間の判断が結果を左右する場面で人間が判断を下すシステムです。
実際には、ヒューマンインザループはたいてい次の 3 つのパターンとして現れます。
承認は、リスクが高いアクションや取り返しのつかないアクションの前に行うサインオフです。
レビューは、リリース前にエージェントの出力を検証することです。
エスカレーションは、確信度が低い場合、コンテキストが不足している場合、または権限範囲を超える場合に、エージェントが引き継ぎを行うことです。
ヒューマンインザループ、ヒューマンオンザループ、ヒューマンアウトオブザループ
これら 3 つの用語は、エージェントが作業を開始した後に人間がどの程度制御を維持するかを示しています。その違いは、誰が実行し、誰が決定するかにあります。
監視モード | 仕組み | 使用する場面 |
ヒューマンインザループ | エージェントが提案し、その後一時停止する。アクションが進行する前に、人間が承認または修正する。 | 誤った操作を取り消すのに多大なコストがかかる、リスクの高い作業や取り返しのつかない作業。 |
ヒューマンオンザループ | エージェントが自律的に動作するが、人間がリアルタイムで監視し、介入して停止または修正できる。 | スピードが重要でミスを回復できる、中リスクの再現可能な作業。 |
ヒューマンアウトオブザループ | リアルタイムの監視なしでエージェントが自律的に動作する。監視は事後に行われる (監査、ログ、抽出検査など)。 | リスクが低く、回復可能で、範囲が明確であり、レビューのコストがその効果を上回る作業。 |
目標は、あらゆるケースで最大限の監視を行うことでも、まったく監視しないことでもありません。リスクが実際に存在する場面で適切なモードを使用し、信頼性の向上に従って作業をより自律的な方向へ移行させることです。
人間はどこで AI エージェントの制御を維持するか
「誰が何を担当するか」から始める
チェックポイントの前に、担当を決めます。人間がどこでレビューや承認を行うかを決める前に、そもそもエージェントが何を担当できるかを決定してください。チェックポイントはその決定を実現するものであり、置き換えるものではありません。
作業を分割する簡単な方法は、ミスによって生じるコストの大きさで分けることです。
エージェントが担当する。エージェントが単独で完了してクローズできる、引き継ぎ不要の明確に規定された作業。
エージェントが提案し、人間が処理する。エージェントが下書きを作成し、人間が仕上げ、承認、または差し戻す作業。
人間が担当する。人間が最初から下す決断。エージェントは決定ではなく支援を行う。
担当は誰が作業を開始するかを決定し、上記の監視モードは作業が進行し始めた後に誰が監視するかを決定します。Jira では、エージェントのすべてのアクションが既知の ID に紐づけられ、作業項目の履歴に残るため、責任の所在は記憶ではなく記録によって明らかになります。
1. 承認: 影響の大きい作業を行う前のサインオフ
アクションを元に戻すのが難しい場合は、承認を使用します。本番環境の変更、削除、およびコストが発生する呼び出しは、いずれも誤った操作による代償が大きいため、サインオフを必須とする必要があります。Jira では、承認は指名された担当者がサインオフするまでトランジションを保留するワークフロー承認ステップです。そのため、このゲートはプロセスの一部であり、誰かが覚えておくべきリマインダーではありません。条件やバリデーターを含め、これらのゲートの背後にあるワークフロー ルールのメカニズムの詳細については、Agentic engineering guardrails and safety in Jira (Jira におけるエージェント型エンジニアリングのガードレールと安全性) をご参照ください。
Jira の場合: エージェントが、本番環境の構成の更新やリリースなど、影響の大きい変更を準備するとします。指定された承認者が承認するまで、作業項目を承認ステータスから先に進めることはできません。ネイティブの承認ステップでは、トランジションが「承認」または「却下」の 2 つの結果に関連付けられ、誰がいつ判断したかが作業項目に記録されます。
2. レビュー: 提供前に出力を検証する
既存のチェックで検証されるまでは、エージェントの出力を信頼できないものとして扱います。コーディング エージェントの場合、レビューの対象となるのはプル リクエストであり、通常のレビューおよびマージ プロセスに従って処理されます。
適切にレビューするには、結果だけでなく、作業の過程を確認することが重要です。Jira の「あなた専用の場所」ページにあるエージェント セッション ビューでは、エージェントが何を行い、なぜそうしたのかを 1 か所で確認できるため、レビュアーは経緯を一からたどり直すことなく、コンテキストを把握したうえでレビューを開始できます。
Jira の場合:Jira コーディング エージェントなどのコーディング エージェントに作業項目を割り当てます。エージェントは作業項目とリンクされたコンテキストを読み取り、その作業項目にリンクされたドラフト プル リクエストを作成します。そのプル リクエストは、通常のマージ プロセスに従ってレビューします。また、Jira の「あなた専用の場所」ページにあるエージェント セッション ビューでは、次に対応が必要な内容ごとにすべてのセッションがまとめられ、各エージェントが行った作業も表示されます。そのため、経緯を一からたどり直すことなく、コンテキストを把握したうえでレビューできます。
Jira の任意の課題をコーディング エージェントに割り当てると、エージェントが安全なクラウド サンドボックス内でコードベースを調査し、修正や機能を実装して、プル リクエストを作成します。
3. エスカレーション: エージェントが判断に迷う場合や権限範囲を超える場合は引き継ぐ
エスカレーションとは、エージェントが自身の限界を認識することです。確信が持てない場合、コンテキストが不足している場合、またはポリシー上の境界に達した場合は、推測するのではなく、処理を一時停止して確認を求めるか、人に引き継ぐ必要があります。重要なのは、この引き継ぎを体系化することです。人が後からミスを見つけるのではなく、システムが例外としてエスカレーションを発生させるよう、トリガーを設計します。エージェントが自身の確信度を確実に判断できると期待してはいけません。必要なコンテキストが不足している、利用可能な場合に確信度が低いことを示すシグナルがある、変更が設定された規模を超えている、ポリシー上の境界を越えるアクションがある、といったトリガーをあらかじめ定義してください。
Jira では、コンテキストが不足している場合に、自動化ルールを使用してコメントを追加したり、作業項目に「要調整」というラベルを付けたり、担当者に引き継いだりできます。これは、アトラシアンのエージェントでもサードパーティ製のエージェントでも同様に機能します。タスクの途中でエージェントが処理を一時停止して確認を求めるタイミングは、Rovo または Jira エージェントの場合は Jira 内のエージェント独自の指示で設定し、Claude、Cursor、Copilot などのサードパーティ製エージェントの場合は、各ツールのエージェント設定で指定します。
Jira の場合: 自動化ルールによって、毎朝、未完了のセキュリティ関連の作業項目をすべてチェックし、重大度に応じて振り分けます。リスクが低く、元に戻せる修正は、プル リクエストを作成するコーディング エージェントに割り当てます。重大度が高いものやクリティカルなインフラストラクチャに影響するものは、変更を加える前に内容を要約し、適切なエンジニアに引き継ぎます。これにより、リスクの高い判断は、必要なコンテキストがすでに整理された状態で担当者に委ねられます。
Jira で自動化を一度設定すれば、あとはエージェントに任せることができます。
人間参加型 (HITL) が安全策ではなくボトルネックになるのはどのような場合か
監督は、少なすぎても多すぎても機能しません。監督が不十分だと、意図に沿わない作業や取り返しのつかない作業をリリースすることになります。AI を活用したコーディングの導入が進む一方で、開発者の生産性向上はおよそ 10 ～ 15% にとどまっています。これは、ソフトウェアをリリースするうえで難しいのは、コードを書くことではないからです。何を構築するかを決め、変更するシステムを理解し、成果物を安全にリリースできるかどうかを判断することこそが難しいのです。一方、監督が多すぎても、別の問題が生じます。
人間参加型 (HITL) がボトルネックになるのは、ゲートがリスクに見合わなくなったときです。よく見られる失敗パターンは、次の 3 つです。
ゲートが多すぎる。すべてのアクションをレビューすると、レビュー疲れが生じ、エージェントは人による確認を待つ間、作業を進められなくなります。その結果、エージェントを導入した本来の目的であるスピードが、いつの間にか失われてしまいます。
形だけの承認を行う。本来は必要のない作業にまでゲートが設けられていると、内容を読まずに承認するようになります。チェックポイントが形骸化し、本当に問題のある作業が紛れ込んだときに、肝心の役割を果たせなくなります。
監督の実効性ではなく、実施の有無を測る。承認件数を数えてわかるのは、人が関与したということだけです。実際に問題を見つけたかどうかはわかりません。件数の多さは、適切な判断が行われたことを意味しません。
すべてのアクションにゲートを設けると処理量を維持できない場合は、代わりにサンプリングを行います。エージェントが完了したすべての作業をレビューするのではなく、その一部をレビューします。Jira では、自動化ルールを使用して、エージェントが完了した作業項目の一定割合にフラグを付けて、人による監査の対象にしたり、価値の高い作業項目をすべて人に振り分けたりできます。これにより、作業の流れを止めることなく、品質を確実にチェックできます。
レビューと承認の場としての Jira
Jira では、人間参加型 (HITL) のために別のツールを用意する必要はありません。Jira はチームがすでに日々の作業を行っている場であるため、すべてのチェックポイントを実際の作業と同じ場所に設けることができます。これが、規模の拡大に対応できる監視と、誰も管理しない並行した管理基盤との違いです。
3 つのパターンは、すべて 1 つの場所に集約されます。
承認: ワークフローの承認ステップを使用して、指定された担当者が承認するまでトランジションを保留します。
レビュー: 作業項目に紐付けられたプル リクエストをレビューします。Jira の「あなた専用の場所」ページにあるエージェント セッション ビューを使用すれば、各エージェントが行った作業と、自分の対応を待っている作業を確認できます。
エスカレーション: エージェントの指示と自動化ルールを使用してエスカレーションし、引き継ぎの内容とその担当者を作業項目に直接記録します。
Jira なら、エージェントの出力を簡単にレビューし、何をリリースするかを判断できます。
人とエージェントは、1 つの記録システムを基盤として作業します。どのエージェントが作業を行う場合でも、チームがすでに信頼しているワークフロー、データ権限、履歴が適用されるため、AI 専用の別システムを構築することなく、既存の管理機能を監督に活用できます。システムをいたずらに増やすことなく、必要なチェックを行えます。
AI エージェントで人間参加型 (HITL) を活用するためのベスト プラクティス
優れた人間参加型 (HITL) システムでは、人による対応が結果を左右する場面に人の注意を集中させ、それ以外の場合はエージェントに処理を任せます。
介入の回数を減らし、価値の高い介入に集中する。ゲートを設けるたびにコストが発生します。形だけの承認になっているゲートは削除します。
リスクと元に戻せるかどうかに応じて監督のレベルを調整する。定型的な作業は自動化します。コストが高いものや、元に戻すのが難しいものに承認を限定します。
承認とレビューを分ける。影響の大きいアクションは実行前に承認し、リリースするものはすべてレビューします。
エスカレーションを体系化する。確信度が低い、コンテキストが不足している、ポリシー上の境界に達した場合など、トリガーをあらかじめ定義します。
狭い範囲から始め、徐々に広げる。新しいエージェントにはまず限定された範囲の作業を任せ、信頼性が実証されるにつれて、任せる範囲を広げます。
Jira で初めての人間参加型 (HITL) ワークフローを設定する方法
始めるにあたって、ワークフローを全面的に設計し直す必要はありません。1 つのワークフローを選び、チェックポイントを 1 つ追加して、そこから範囲を広げていきます。
定型的なタスクを 1 つ選ぶ。依存関係の更新、不安定なテストの修正、ドキュメントの更新など、ミスがあっても簡単に元に戻せる作業から始めます。リスクの高い作業を任せるのは、この仕組みに十分な信頼を置けるようになってからにします。
そのタスクに範囲を限定して、エージェントに割り当てる。担当者フィールド、ボードの列、またはワークフローのトランジションからエージェントを追加します。エージェントは、その背後にいるユーザーに代わって動作するため、Jira 内ではそのユーザーがアクセスできるものにのみアクセスできます。Jira 内の作業へのアクセスは Jira によって管理されます。一方、サードパーティ製エージェントが独自のツールを使って実行できる操作については、Jira の外部で別途設定されます。エージェントを割り当てると、そのエージェントが実行されます。ただし、この時点ではまだ人間参加型 (HITL) にはなっていません。次のステップで追加するチェックポイントによって、人を介在させます。
影響が生じるポイントにチェックポイントを設ける。影響の大きいステータスへのトランジションに承認ステップを追加し、作業を先に進める前に担当者が承認するようにします。ネイティブの承認機能を利用できないプランでは、トランジション条件を使用して、作業を移行できるユーザーを制限します。
出力をレビューに回す。コードの場合は、作業項目に紐付けられたプル リクエストのドラフトをエージェントに作成させ、マージする前に変更内容が適切にレビューされるようにします。エージェントの判断だけでリリースすることはありません。
履歴を確認してから、範囲を広げる。エージェントのアクションが作業項目に記録されていることを確認してから、次のトランジションやタスクの種類を追加したり、作業範囲を広げたりします。まずは元に戻せる作業から始めます。エージェントの信頼性が実証されるにつれて、自律的に任せる範囲を広げていきます。
Jira で、エージェントが実行したアクションや下した判断を確認できます。
目指すべきは、人の介在なしに動作するエージェントではありません。重要な判断にのみ人が関与し、それ以外はエージェントに任せ、すべてのステップが記録されるワークフローです。
人が適切な場面で関与できるようにする準備はできましたか。AI ネイティブな開発のための Jira を始めましょう。
人間参加型 (HITL) AI エージェントに関するよくある質問
AI コーディング エージェントに人を介在させるにはどうすればよいですか?
エージェントの作業をレビュー可能にし、ゲートを設けます。エージェントの出力をプル リクエストに送り、影響の大きい変更には事前承認を必須とします。また、エージェントが判断に迷った場合や許可された範囲を超える場合にエスカレーションするよう、トリガーを設計します。
Jira の AI エージェントに人による承認を必須にできますか?
はい。影響が及ぶトランジションにワークフローの承認ステップを追加すると、指名された担当者が承認または拒否するまで作業項目は保留されます。ネイティブ承認は、Premium プランおよび Enterprise プランでご利用いただけます。
AI エージェントの行動に対して誰が責任を負いますか?
常に人間です。エージェントが作業を行いますが、結果の責任は人間が負います。Jira では、エージェントのすべてのアクションは既知の ID に紐づけられ、作業項目の履歴に残ります。
AI エージェントのループ エンジニアリングとは何ですか?
ループ エンジニアリングとは、エージェントが自律的に処理を継続するのか、それとも人間に引き継ぐのかを判断するトリガーを設計することです。適切なトリガーによってエスカレーションが体系化されるため、監視の目はあらゆる場所ではなく、リスクのある場所に向けられます。
人間参加型 (HITL) は AI ガバナンスの要件を満たしますか?
人間による監視は、EU AI 法や NIST AI RMF などのフレームワークにおいて中心的な役割を果たしますが、監視だけではガバナンスとは言えません。強制的なアクセス制御、承認、監査証跡も必要です。Agentic engineering guardrails and safety in Jira (Jira におけるエージェント型エンジニアリングのガードレールと安全性) を参照してください。