システムの保守・改修を依頼していると、開発会社から「このチケットはAIに実装させてもいいですか？」と聞かれる場面が出てきました。IssueやJira（＝やることを1件ずつ管理するチケット管理ツール）に書いた依頼を、AIエージェントが読んで実装まで進める仕組みが、実際に使えるようになっているためです。
「IssueやJiraに書くだけでAIが実装するなら、発注者のチケットの書き方はどう変わるのか」
先に結論をお伝えします。AIが実装する場合でも、良いチケットの条件は人に頼む場合と変わりません。変わるのは「書いていないことを、会話で補ってもらえる余地が小さくなる」点です。そのため、発注者が一番力を入れるべきは受入条件（＝どうなっていれば完了と言えるか）です。また、AIに作業を割り当てる操作は、多くの場合、発注者ではなく開発会社が行うのが現実的です。
この記事では、AIエージェントに実装を任せる開発の流れを専門用語をかみくだいて説明したうえで、発注者向けのチケットのひな形、良い例・悪い例、結果が返ってきたときの確認ポイントを紹介します。
チケットをAIに割り当てると何が起きるのか（AIエージェント開発の流れ）
「チケットを割り当てる → AIが修正案を出す → 人が確認する」が基本の形
代表的な例が、GitHub（＝プログラムの保管・共同作業のためのサービス）のAI機能「GitHub Copilot」です。チケットに相当するIssueをAIに割り当てると、AIがバックグラウンドで作業し、修正案をプルリクエストとして作成して、人にレビューを依頼する仕組みが2025年9月に一般提供（正式版）になりました。
📰 出典：GitHub Changelog「Copilot coding agent is now generally available」（2025年9月25日）
この機能は2026年4月に「Copilot cloud agent」へ名称が変わり、プルリクエストを作る前に実装方針（計画）を提示させて人が確認する、といった使い方も案内されています。
📰 出典：GitHub Changelog「Research, plan, and code with Copilot cloud agent」（2026年4月1日）
さらに2026年6月には、Jiraのチケットから同じAIエージェントに作業を任せられる「GitHub Copilot for Jira」が一般提供になりました。Jira上で担当者にAIを設定したりコメントで呼びかけたりすると作業が始まり、進み具合がJiraに表示され、結果はプルリクエストとして作成されます。
📰 出典：GitHub Changelog「GitHub Copilot for Jira is now generally available」（2026年6月25日）
GitHub以外にも、似た「非同期型（＝頼んだら裏で作業を進め、終わったら知らせてくれる）」のAIエージェントがあります。たとえばAnthropicの「Claude Code」はクラウド上でセッションを動かし、完了後にプルリクエストを作成できます。AWSの開発ツール「Kiro」も、2025年12月に自律的に作業するエージェントをプレビュー（＝試験提供）として発表しています。いずれも仕組みや対象プランは執筆時点（2026年9月）のもので、今後も変わる可能性があります。
📰 出典：Claude Code Docs「Use Claude Code in the cloud」
📰 出典：Kiro Changelog「Introducing Kiro autonomous agent」（2025年12月2日）
プルリクエストとレビューをひと言でいうと
- プルリクエスト：「このように直しました。本番のプログラムに取り込んでいいですか？」という修正案の提出書類です。どのファイルのどこを変えたかが一覧で見られます
- レビュー：その修正案を別の人が読み、問題がないか確認する工程です。問題があればコメントで直しを依頼します
- マージ：レビューで承認された修正案を、本体のプログラムに取り込むことです
つまりAIが作るのは「完成品」ではなく「修正案」です。取り込むかどうかは、人がレビューして決めます。
人の確認を前提にした安全装置がある
GitHubの公式ドキュメントでは、AIエージェントのリスクへの対策として次のような仕組みが説明されています。
📰 出典：GitHub Docs「Risks and mitigations for GitHub Copilot cloud agent」
- AIに作業させられるのは、そのリポジトリ（＝プログラムの保管場所）への書き込み権限を持つ人だけ
- AIを呼び出した本人は、そのプルリクエストを承認できない（別の人のレビューが必要）
- 自動テストなどの処理は、既定では人が内容を確認して許可するまで動かない
「AIが勝手に本番を書き換える」仕組みではなく、人のレビューを通すことが前提になっている、と理解しておけば十分です。
誰がAIに作業を割り当てるべきか：多くの場合は開発会社
Jiraから使う場合、公式ドキュメントでは、Jira Cloudであること、AI機能（Rovo）が有効であること、GitHub側で有料のCopilotプランを使っていること、そして作業を始める人が対象リポジトリへの書き込み権限を持つことが前提条件として挙げられています（執筆時点（2026年9月））。
📰 出典：GitHub Docs「Integrating Copilot cloud agent with Jira」
発注者がAIに直接作業を割り当てるには、プログラムへの書き込み権限を持つ必要があります。これは「発注者が開発に直接手を入れられる」状態であり、責任の範囲や保守契約の前提が変わりかねません。そのため多くの場合は、次のような役割分担が現実的です。
| 役割 | 発注者 | 開発会社 |
|---|---|---|
| チケットを書く（何を・なぜ・完了条件） | ◎ | ○（質問・補足） |
| AIに任せるか人がやるかを判断する | 相談を受ける | ◎ |
| AIへの割り当て・修正案のレビュー | ― | ◎ |
| 動作確認・受け入れ | ◎ | ○（確認手順の提示） |
発注者の役割は「AIを操作すること」ではなく、判断の材料になるチケットを書くことと、結果を受け入れるかを決めることです。
AIに任せやすい作業・任せにくい作業
GitHubの公式ドキュメントは、AIエージェントに向く作業と、人が担当したほうがよい作業を次のように整理しています。
📰 出典：GitHub Docs「Best practices for using GitHub Copilot to work on tasks」
| 任せやすい作業の例 | 人が担当したほうがよい作業の例 |
|---|---|
| 不具合の修正 | 影響範囲が広く、業務知識が深く必要な変更 |
| 画面の文言・見た目の小さな変更 | 本番環境・セキュリティ・認証・個人情報に関わる作業 |
| テストの追加 | 要件があいまいで、決まっていないことが多い依頼 |
| ドキュメントの更新 | 担当者が仕組みを理解すること自体が目的の作業 |
発注者にとってのポイントは、「あいまいな依頼」はAIに向かないと明記されている点です。書き方次第で、同じ依頼でも「AIに任せられる作業」にも「人が相談しながら進める作業」にもなります。
AIにも人にも伝わるチケットのひな形
同じドキュメントでは、良いタスクの条件として「解決したい問題や作業の明確な説明」「良い解決策とはどういうものかを示す、漏れのない受入条件」「変更が必要な箇所の手がかり」が挙げられています。これを発注者向けに置き換えると、次の5項目になります。
- 背景・目的：なぜこの変更が必要か。誰がどんな場面で困っているか
- やってほしいこと：変更したい内容。「今こうなっている → こうしたい」の形で書く
- 受入条件：どうなっていれば完了か。確認できる形で箇条書きにする
- 対象外：今回はやらないこと、変えてほしくないこと
- 参考資料：画面のスクリーンショット、エラーの発生日時、関連する過去のチケット、業務のルール
「変更が必要なファイル」は発注者には分からなくて当然です。代わりに画面名や操作手順を具体的に書けば、開発会社（とAI）が該当箇所を探す手がかりになります。
※ チケットはAIや外部サービスに読み込まれる前提で書きましょう。お客様の個人情報やパスワードは書かず、必要なら開発会社と受け渡し方法を決めてください。
良いチケット・悪いチケットの例
以下は、説明のために作成した例です。
悪い例
- 件名：会員一覧が使いにくい
- 本文：検索しづらいので改善してください。急ぎでお願いします。
「使いにくい」「改善」の中身が書かれていないため、人が担当しても確認の往復が必要です。AIに渡すと、もっともらしい推測で何かを作ってしまい、期待とずれた修正案が返ってくる可能性があります。
良い例
- 件名：会員一覧で電話番号でも検索できるようにしたい
- 背景・目的：問い合わせ電話の対応中に会員を探す際、今は氏名でしか検索できず、同姓の会員が多いと特定に時間がかかる
- やってほしいこと：会員一覧の検索欄で、氏名に加えて電話番号でも検索できるようにする
- 受入条件1：ハイフンあり・なし（例：03-1234-5678／0312345678）のどちらで入力しても同じ会員が見つかる
- 受入条件2：電話番号の一部（下4桁など）では検索しない（完全一致のみ）
- 受入条件3：氏名での検索は今までどおり動く
- 受入条件4：該当なしの場合は、今と同じ「該当する会員がいません」を表示する
- 対象外：会員一覧の画面デザインの変更、CSV出力への影響
- 参考資料：現在の会員一覧画面のスクリーンショット（個人情報は塗りつぶし済み）
受入条件が具体的なので、AIが作った修正案でも、人が作った修正案でも、「条件を満たしているか」で判断できます。受入条件がはっきりしているほど、人もAIも迷わず作業できるというのが、この記事で一番お伝えしたいことです。
結果が返ってきたときに発注者が確認すること
AIが作った修正案は、まず開発会社がレビューします。発注者が見るのは、プログラムの中身ではなく受入条件を満たしているかです。
- 開発会社から「どのチケットの対応か」「AIを使ったか」「誰がレビューしたか」の報告を受ける
- テスト環境（＝本番とは別の確認用の環境）で、受入条件を1つずつ実際に操作して確かめる
- 対象外にしたはずの部分（例：CSV出力）が変わっていないかも確認する
- 気になる点はチケットにコメントで残す（口頭だけで済ませない）
- 問題がなければ、本番への反映日時を開発会社と合意する
受入条件の確認に使った手順は、次回以降の確認にも使い回せます。受け入れの考え方は、仕様変更の判断とも深く関係します。
システム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方
注意点：AIに任せても変わらないこと
- 責任の所在は契約どおり：AIを使ったかどうかで、開発会社の品質責任が消えるわけではありません。ただし、AI利用のルールを契約や覚書でどう定めるかは会社ごとに異なるため、必要に応じて専門家に確認しましょう
- 速さと正しさは別：修正案が早く出てきても、レビューと動作確認の時間は必要です。「AIなら今日中にできるはず」と期限を詰めすぎないことが、結果的に品質を守ります
- 得意・不得意がある：既存システムの大きな改修や移行など、AIが苦手とされる作業もあります
AIで開発費は下がる？「改修・移行は苦手」と発注者の見積もりの考え方（関連記事）
発注者がやることチェックリスト
- ☐ 開発会社がAIエージェントを使っているか、どの作業に使っているかを確認した
- ☐ AIへの割り当てとレビューを誰が行うか、役割分担を決めた
- ☐ チケットを「背景・目的／やってほしいこと／受入条件／対象外／参考資料」の形で書いた
- ☐ 受入条件を、実際に操作して確かめられる文章にした
- ☐ 「今回はやらないこと」を対象外として明記した
- ☐ チケットに個人情報・パスワードを書いていない
- ☐ 納品時に、テスト環境で受入条件を1つずつ確認する時間を確保した
開発会社への質問例
- 「このチケットはAIに任せる予定ですか？ 任せる場合、レビューはどなたが担当しますか？」
- 「AIに任せやすくするために、チケットに追加で書いておいたほうがいい情報はありますか？」
- 「この受入条件で、完了したかどうかを判断できますか？ あいまいな点があれば教えてください」
- 「AIを使う作業と使わない作業で、見積もりや納期の考え方は変わりますか？」
- 「チケットの内容はどのAIサービスに読み込まれますか？ 学習に使われない設定になっていますか？」
まとめ：チケットの質が、人とAIの両方の成果を左右する
IssueやJiraのチケットをAIエージェントに割り当て、修正案（プルリクエスト）を人がレビューする開発の流れは、執筆時点（2026年9月）で実際に使える段階にあります。ただし、AIが作るのはあくまで修正案で、取り込むかどうかは人が決めます。
- AIへの割り当てとレビューは、多くの場合は開発会社の役割
- 発注者はチケットを「背景・目的／やってほしいこと／受入条件／対象外／参考資料」で書く
- 特に受入条件は、実際に確かめられる形で具体的に
- 結果は、テスト環境で受入条件を1つずつ確認して受け入れる
チケットの書き方を整えることは、AIのためだけではありません。人が担当する場合でも確認の往復が減り、認識のずれも起きにくくなります。まずは次に出すチケット1件から、ひな形を使ってみてください。
あわせて読みたい関連記事
コメント