バックエンドエンジニアの伊藤です。
最近、AIコーディングエージェントを使った開発が当たり前になる中で、改めてチケットには何を書くのが最適なんだろう、そもそもチケットが生まれた経緯・役割はなんだったのだろう、AI時代にはチケットはどう変わるのだろう、ということを考えています。
ここ1、 2年で、AIによってコードを書く速度が格段に速くなってきました。簡単な修正であれば、実装そのものは数分で終わります。バグの再現条件を渡し、関連しそうなファイルを読ませ、修正案を出させ、テストまで書かせることもできます。
一方で、その作業をチケットに起こし、背景を書き、スコープを書き、受け入れ条件を書き、担当者を設定し、ステータスを動かす時間の方が重く感じることがありました。
ここで疑問が生まれます。
チケットは、AI時代のソフトウェア開発においても、最適なインターフェースといえるだろうか？
本稿では、チケットというUIそのものについて再考します。
本記事の概略
本記事の概略を先に書いておきます。
- チケットは、実装が遅く、人間同士のハンドオフ（人から人への作業の引き渡し）が多く、文脈を一箇所に圧縮して渡す必要があった時代に適したインターフェース
- AIによって実装、分解、レビュー補助、テスト生成が速くなると、チケットにすべてを詰め込むモデルは、少しずつ重くなっていく。
- 短期的にはチケットの構造化が重要になるが、中長期では、チケットは開発の中心的なUIではなく、意図や証跡を見るための一つのビューになっていく
- これから必要なのは、チケットだけを中心に置く開発ではなく、意図(Intent)を意識した開発。Ticket-firstではなく Intent-aware の開発。
チケットは何を解決していたのか
チケット、Issue、Bug report、Work item。呼び方はいろいろありますが、起源をたどると、もともとは未解決の不具合や変更要求を追跡するための仕組みでした。
たとえば Bugzilla は、自らを defect-tracking system または bug-tracking system と説明しています。Bugzilla の説明では、開発チームが未解決の bugs、problems、issues、enhancement requests、change requests を追跡するための仕組みとされています*1。
しかし、チケットは単なるバグ管理表にとどまりませんでした。現代のIssue Tracking Systemは、requirements、development tasks、maintenance itemsなど、ソフトウェア開発に関わる複数の成果物を管理する基盤として使われています*2。
つまりチケットは、以下のような役割を持っています。
| 役割 |
内容 |
| 入口 |
要望、バグ、問い合わせ、改善案を受け取る |
| キュー |
後でやるかもしれない作業を貯める |
| 優先順位づけ |
何を先にやるべきかを決める |
| ハンドオフ |
PdM、エンジニア、QA、CS（カスタマーサクセス／カスタマーサポート）の間で仕事を渡す |
| 責任の明確化 |
誰が担当するかを決める |
| 進捗管理 |
Todo / Doing / Review / Done を可視化する |
| 合意形成 |
仕様やスコープの認識を揃える |
| 検証条件 |
何をもって完了とするかを定義する |
| 証跡 |
なぜその変更をしたかを後から追えるようにする |
| メトリクス |
件数、滞留、リードタイム、担当負荷を見る |
言い換えると、チケットは「作業にまつわる不確実性を、一つのカードにまとめたもの」とも言えます。
チケットは文脈圧縮インターフェースだった
顧客の不満、PMの判断、エンジニアへの作業依頼、仕様のメモ、優先度、担当者、受け入れ条件、関連 PR、QA 結果……などなど、関係者ごとに散らばる前提や判断をチケットという一枚のカードに圧縮する。この働きは、「文脈圧縮」と呼ぶことができそうです。
チケットが多様な文脈を一枚のカードに圧縮することで、チームは非同期に仕事を進めることができました。
一方で、これまでチケットが有効だった背景には、いくつかの前提があったと考えています。
まず、実装には時間がかかりました。そのため、事前に何を作るかを整理し、優先順位をつけ、担当者を決める価値がありました。
次に、仕事は人間が順番に処理していました。そのため、チケットはキューとして機能しました。
さらに、開発には多くのハンドオフがありました。PMが背景を説明し、エンジニアが仕様を解釈し、QAが期待挙動を確認し、CSが顧客影響を追います。その間で文脈が失われないように、一枚のチケットに情報を圧縮して渡す必要がありました。
つまりチケットは、実装が遅く、ハンドオフが多く、非同期コミュニケーションにコストがかかる時代に適したインターフェースだった、と整理できます。
少し強く言うと、チケットは「実装が遅い時代の文脈圧縮フォーマット」とも言い換えられるかもしれません。しかし、AIコーディングエージェントが高速でコードを生成していく今、その前提はいま崩れつつあります。
※もちろん、規制対応、監査、大規模分散開発のように、チケットが提供してきた他の機能、たとえば証跡や責任の所在の明示は、AI時代でも変わらず必要になる場面があります。チケットの存在意義そのものを否定したいわけではありません。
これからのチケットの在り方については後半で触れたいと思います。
チケット以外の思想から学べること
チケット中心の開発を相対化する視点は私だけの意見ではなく、すでにいくつかの言説が存在しています。
ひとつはShape Upです。Basecampは、未着手アイデアを大量に抱えるバックログを「大きな重荷」だと表現しています*3。古いアイデアを定期的に整理することに時間が取られ、現在のプロジェクトを進める力が削がれる。だからこそ、少数のwell-shaped、リスクを下げた選択肢にbetするべき、という考え方です。
もうひとつはSciitという研究です。Issue trackerとSCM（ソースコード管理）が分離していると、開発者が両方の情報を手作業で整合させる必要があり、手間が大きいと指摘しています*4。Sciit はそのうえで、issueをSCMの中で（コードと同等に扱う）構成要素として置き、進捗や担当者をリポジトリの状態から推測できるようにする方向を示しています。
そしてGitHubのSpec Kitがあります。Spec Kitは、Spec-driven developmentという方法論を実装するためのツールキットです*5。これまでは「コードが正で、仕様は足場のようなもの」だったが、Spec Kitではむしろ「仕様が実装を生む中心的な成果物になる」という整理が示されています。Microsoft for Developersのブログでも、AI エージェントに正しい出力を出させるためには、まず良い文脈（context）が必要であり、決めないまま進めると codebase が de-facto specification になってしまう、と指摘されています*6。
これらに共通するのは、チケットを保存形式・操作 UI・実行単位として一枚にまとめる前提を疑う動きだと考えます。バックログを軽くする、issueをSCMに埋め込む、仕様を実装の中心に置く。それぞれアプローチは違いますが、チケットが暗黙に担ってきた多くの責務を、別のレイヤーに分けていく方向性で重なっています。
チケットが担っていた役割を分解する
つまり、すべての情報をチケットが持ち続ける必要はないのかもしれません。
改めて、チケットがこれまで担ってきた役割を、AI時代に合う形で考え直してみましょう。
| 役割 |
従来の置き場 |
AI時代の移行先（候補） |
入口
・要望 |
チケット |
ドキュメント、対話、フィードバック |
背景
・意図 |
チケット |
設計ドキュメント、ADR |
仕様
・制約 |
チケット |
実行可能な仕様（executable spec）、テスト |
| 作業の実行 |
チケット |
AI エージェントが動的に生成する作業単位、PR |
| 進捗管理 |
チケット |
PR、commit、test、deploy、AI エージェントのログから自動観測 |
| 検証 |
チケット |
テスト、CI、合成テスト、AI レビュー |
| 証跡 |
チケット |
PR、commit、AI エージェントの実行履歴 |
| 振り返り |
チケット |
メトリクス、ダッシュボード |
| 決定 |
チケット |
ADR、設計ドキュメント |
具体的な移行先（情報の管理方法）については後で考えたいと思います。
ここでは一旦、役割の方に注目してください。これらの役割に共通するのは、作業そのものではなく、その背後にある「何を実現したいのか」という意図と、それを支える判断・制約・検証だった、と整理できます。チケットが守っていた中核は、作業（Task）よりも、その背後にある意図（Intent）だったとも言い換えられるのではないでしょうか。
AI時代のソフトウェア開発では、この「意図（Intent）」がより重要になってきていると感じます。
AIによって変わったこと
AI時代のソフトウェア開発では、単にコードを書くだけではなく、調査、分解、実装、テスト生成、レビュー補助、要約、トリアージ。ソフトウェア開発の周辺工程全体にAIが入り始めています。
象徴的な発信もあります。Linear は、2026 年 3 月 24 日にマーケティング上のメッセージとして "Issue tracking is dead." を打ち出しました*7。Linear によれば、従来のIssue trackingはPMが作業をスコープし、エンジニアが後から拾うハンドオフモデルのために作られたものだったとされています。今後のシステムは、ハンドオフではなく、文脈（context）とAIエージェント（agents）を中心に設計される、というのがLinearの主張です。
DORAの2025年の報告書も、AIは組織の既存の強みと弱みを増幅するものであり、AI導入による効果はツール単体ではなく組織システム全体に依存すると指摘しています*8。同報告書は、速度向上が下流の不安定さを露わにする、内部プラットフォーム品質がAI価値を決定づける、といった具体的な論点も提示しています。
ここから読み取れるのは、AI時代のボトルネックが、実装そのものから、意図の明確化、検証、責任分界へと移りつつある可能性です。
何を作るべきか、どこまで作るべきか、何を守るべきか、どうなれば正しいと言えるのか。そういった「意図（Intent）」こそが、より重要になっていく。このことはここ1, 2年で急速に共通認識になりつつあります。
なぜIntentが重要なのか
ここでいうIntentは、単なる目的文ではありません。
「なぜこれをやるのか」「何を満たせば成功か」「どこまでやれば終わりか」「どの制約を守るのか」「どんな副作用を避けたいのか」これらをまとめた、開発の起点です。
作業（Task）と意図（Intent）の違いを下記の表にまとめました。
| |
Task |
Intent |
| 粒度 |
作業単位 |
目的単位 |
| 寿命 |
完了したら閉じる |
達成後も参照されることが多い |
| 数 |
多い |
少ない |
| 主な担い手 |
AI エージェント |
人間 |
| 役割 |
実行 |
判断・検証 |
AI時代にIntentの重要性が増すと考えられる理由は、AIが作業を高速・大量に実行できる場面が増えてきたからです。
人間の開発者であれば、曖昧なチケットでも文脈から意図を補完して、「たぶんこういうことだろう」と判断できます。AIも確認はできますが、人間より速く・大量にコードを生成できるため、曖昧な指示を誤って解釈してしまった場合に積み上がる量が桁違いに大きくなります。
そのため、AI時代には「実装できること」よりも、「意図に沿って実装されていること」の方が重要になっていくと考えています。
Taskは完了すれば閉じます。しかしIntentは、作業が完了した後も、後続の意思決定で参照されることが多い情報です。「なぜこれを作ったのか」「制約は何だったか」「どうなれば成功か」を、後から検証・参照できることが重要です。
この考え方に立つと、開発の中心にあるのが必ずしもチケットである必要はなくなります。
むしろ、これまでどおりチケットを中心に扱うと、Intentはチケット内に閉じ込められることになります。こういった方法では、複数のチケットやPRが同じIntentを参照する場面で、参照の起点がチケットの中に隠れてしまいます。また、チケットが閉じた後も生き続ける情報の追跡もしにくくなる問題もあります。
では、Intentを軸にすると、具体的にどういう情報の置き方になるのか。次節で見ていきます。
Intentを軸に、開発情報をつなげて考える
本稿では、大それた新しいシステムや大きな方法論を提案したいわけではありません。
たとえば、ある改善について次のようなIntentがあったとします。
Intent:
ユーザーが問い合わせをせずに、自分で退会手続きを完了できるようにする
この Intent の周辺には、次のような情報が紐づきます。
例えばこういった形で必要な情報を管理可能です。
- 背景や意思決定はNotionや設計ドキュメントに置けばよい
- 作業単位や担当はLinearやGitHub Issuesに置けばよい
- 実装の証跡はPRに残る
- 検証結果はCIやテストレポートに残る
- リリース状況はDeploymentに残る
- 運用後の変化はメトリクスや外形監視で確認できる
情報を（従来のチケットのように）一箇所に集めてはいません。適切に残されたそれぞれの情報が、どのIntentに紐づいているのか。そのつながりを追えることが重要です。（ここで新しいシステム名や方法論を提案したいわけではありませんが、 便宜的に「Intent Graph的な構造」と呼ぶことはできそうです）
もちろん、これをきれいに整備するのは簡単ではありません。Intentを軸にして、開発に関わる情報をつなげて扱いたい、という思いはありつつも、私たち自身もこの形をきれいに整備できているわけではないのです。現実には、背景はNotionにあり、作業はLinearにあり、実装はGitHubのPRにあり、結果はアプリ上にあり、それらのつながりは人間の記憶に依存していることも多いのが実情です。
実運用上は、Intent IDをどこに置くかという規約と、ツール間のwebhookやリンクの整備が必要になります。メトリクスからIntentへの逆引き（ある数値変動がどのIntentに紐づくか）を機械的に追うのも、現状ではまだ弱い部分です。このあたりの人間の規律と運用コストの部分で課題は残りますが、今後あるべき姿としてはこういった構造なのではないか、と考えています。
※「Linearや Jira の階層機能（Initiative / Project / Issue / Sub-issue）で十分では？」と思われるかもしれません。
たしかに、既存ツールの組み合わせで近い構造は組めるはずです。そもそも、ある程度成熟したチーム・組織であれば、すでに似たようなことはやっているのではないかと思います。ただ、今あるツールをうまく使うよりもより良いUIがあれば、より広く実践される可能性はあると思います。
Ticket-firstからIntent-awareへ
昨今、チケットの構造化に関する話題が増えています。背景、目的、制約、非スコープ、受け入れ条件を今まで以上にきちんと書きましょう、という流れです。これは短期的には正しい方向です。曖昧なチケットは、曖昧な実装を生みます。AIは曖昧な指示に対しても、それらしい実装を高速に返してしまうことがあるため、目的と制約を明示する価値はむしろ高まります。
しかし中長期では、状況は変わってくると考えています。
「良いチケットを書きましょう」という議論は、チケットが開発の中心にあることを前提にしています。本当に考えたいのは、チケットというUIが、AI時代の開発における最適な中心であり続けるのか、という問いです。
チケットはこれまで、意図、作業、責任、進捗、検証、証跡を一枚にまとめる便利な箱でした。その便利さは、実装が遅く、ハンドオフが多く、文脈を一箇所に圧縮する必要があった時代には大きな価値を持っていました。
しかしAIが文脈を保持し、関連するIntent、過去の判断、制約、テスト結果を踏まえて作業できるようになると、すべてをチケットに書く必要は薄れていきます。
細かい実装ToDoは、AIエージェントが動的に生成するようになっていきます。進捗ステータスは、PRやCI/CDから自動観測される方向に進みます。バグ調査は、ログや監視アラートから直接AIエージェントが始める運用も、商用ツール（SentryのAutofix、DatadogのBits AI等）で部分的に現れ始めています。
仕様は、ドキュメントだけでなく、実行可能な仕様（executable spec）としてCIに組み込まれていきます。
一方で、人間の判断は残ります。何を作るべきか。なぜ今やるのか。どんな副作用を避けたいのか。法務・セキュリティ・倫理上、何を許容しないか。これらはIntentの領域であり、AIが代替するのは難しい部分です。
AIが高速に実装できるようになるほど、「何を作るか」よりも、「なぜ作るのか」「何を守るのか」「どうなれば成功なのか」が重要になります。DORA の 2025 年の報告書が指摘するように、速度向上は下流の不安定さを露わにし、その不安定さを支えるのは、内部プラットフォームの品質や、小さく変更を進める運用のような、組織システム側の力です*9。
だからこそ、これから必要なのは、チケットが担っていた役割を分解し、Intentを軸に再配置することです。Intentを意識して、ドキュメント、チケット、PR、テスト、監視、メトリクスをつなげていく方向に、少しずつ組み直していくことです。
その過程で、チケットは消えるのではなく、置かれる位置が変わると考えています。
チケットは、作業管理の唯一の中心ではなくなっていきます。作業の記録（record of work）であると同時に、Intentを軸につながった情報を、人間が見るための一つのビューになっていくのではないかと思います。
書いた人：伊藤
参考文献・引用元
