あなたのAIは6ヶ月前に学ぶのを止めた

書くことと届けることの間にある溝

チケットは先月書かれた。機能は来月リリースされる。その間に、競合が似たものをリリースし、APIが変わり、新しい必須要件が静かに施行された。それらは何もチケットに反映されていない。

これは仮定の話ではない。スプリントの途中、火曜日のスタンドアップのことだ。チームの誰かが、チケットの記述とは違う挙動をするAPIについて言及する。別の人が競合のChangelogを開くと、3週間前にほぼ同じ機能がリリースされていた。チケットが書かれたときは問題なかった。ただ、スプリントが始まる前に世界が動いていたのだ。

コストはやり直しだけではない。信頼の侵食にある。静かにフィクションと化すスプリントゴールにある。チームが初日からすでに時代遅れのものを届けた理由をステークホルダーに説明するPMにある。

どのチームにもこの話のバリエーションがある。ほとんどのチームは、何かを変えるまでに一度以上それを語る。

AIには知識のカットオフがある

いまや多くのチームがJiraチケットの作成、計画、改善にAIを活用している。それは機能している。AIモデルは要件の構造化、受け入れ基準の生成、実装アプローチの提案において本当に優れている。曖昧なチケットをAIに直接渡すと特に危険になる理由の大きな枠組みを理解したいなら、アライメント問題の記事が詳しく扱っている：なぜほとんどのJira向けAIツールはアライメント問題を解決するどころか悪化させるのか。

多くのチームが考慮していないのは、どのAIモデルのトレーニングデータにもカットオフがあるという点だ——通常は現在の日付より6〜12ヶ月前だ。モデルはトレーニングが終わった後に何が起きたかを知らない。推測しているわけでも慎重になっているわけでもない。単純に見えないのだ。

つまりモデルは、Next.js 16.1が2025年12月にNode 18のサポートを廃止し、互換性を前提にしていたチームのビルドを壊したことを知らない。OpenAIが2026年2月にchatgpt-4o-latestモデルエンドポイントを永久削除し、そのストリングを参照し続けていたすべての統合が壊れたことも知らない。米国の3つの州が2026年1月1日に包括的なプライバシー法を施行し、データのオプトアウト要件が一夜で拡大したことも知らない。

あなたのAIアシスタントの知識はおよそ6ヶ月前に止まっている。規制は待ってくれない。

これはモデルの品質の問題ではない——構造的な問題だ。モデルはトレーニングされた範囲の中でその仕事をしている。その境界と今日の間の空白に、破壊的変更が積み上がり、競合がリリースし、コンプライアンス要件が動く。計画プロセスがこの空白を考慮していなければ、AIが関与したすべてのチケットには隠された有効期限がある。

チケットを見積もったときのドキュメントと今日の同じドキュメントの比較——廃止、バージョンの変化、価格変更を伴って

実際に痛みを伴う3つのケース

これらは抽象的なリスクではない。「予測できなかった」というラベルでスプリントレトロスペクティブに登場するが、実際には5分の調査で予測できたはずのものだ。

依存関係の破壊的変更。 チケットは、ライブラリやAPIが最後に統合したときと同じ動作をすると想定している。チームが実装計画を書く。スプリントの途中で、ビルドが失敗し始めるか、APIコールが誰も予期しないエラーを返す。これはOpenAIが2026年2月17日にchatgpt-4o-latestスナップショットを削除したときに起きたことだ。そのモデルストリングを参照した2025年末見積もりのチケットを持つチームはすべて壁にぶつかった——エンドポイントが単純に応答しなくなったからだ。
競合がすでにリリース済み。 チケットをキャンセルする理由とは限らないが、作る前に学ぶ理由には常になる。競合が同じ機能をリリースしている場合、エッジケースを文書化し、ユーザーフィードバックを集め、ときには自分たちがぶつからなくて済む壁にすでにぶつかっている。競合調査に5分かけることで、2週間のディスカバリーを省けるかもしれない——あるいは、市場がすでに通り過ぎたものを届けてしまう落胆を防げる。
規制とコンプライアンスの変化。 これは最もリスクが高いケースだ。なぜなら結果は無駄になったスプリントだけでなく、法的リスクになるからだ。2025年11月に米国ユーザー向けに書かれたチケットは、誰かがスプリント前に確認しない限り、2026年1月1日のプライバシー法の変更を考慮していない。規制当局はJiraチケットを開かない。スプリントサイクルに合わせてくれない。

一方の皿に小さな5分間の確認、もう一方の皿にブロックされ、再見積もりされ、やり直されたスプリントカードの重い山

このチェックをすべきタイミング

チェック自体よりタイミングの方が重要だ。

チケットが作成されたとき、ではない。 早すぎる。チケットはバックログに何週間も何ヶ月もある可能性がある。今確認したものは、誰かが実際に取り掛かるころには古くなっている。
スプリントの途中、でもない。 遅すぎる。チームはすでにキャパシティを確約している。この時点で破壊的変更や規制の変化を発見することは、やり直し、ブロックされたストーリー、達成不可能なスプリントゴールを意味する。
チケットが詳細化され、次のスプリントにスケジュールされるとき。 ちょうどそのとき、チームはすでにチケットに実際の時間を投資している——スコープを磨き、サブタスクを書き、アプローチを確認している。この時点で5〜10分の市場確認を加えることは、コストが低く、リターンが高い。このチェックの後に開発準備できたチケットがどう見えるべきかの構造については、実装計画の記事が自然な続編だ：曖昧なJiraチケットを明確な実装計画に変える。

チケットをスプリントにコミットする前に確認すること：

チケットが書かれてから、関連する依存関係やプラットフォームで何か変わったことはあるか？
競合がすでにこれをリリースしていて、そこから何を学んだか？
この機能領域に関連する最近の規制やコンプライアンスのシグナルはあるか？
チケットがスコープされたときには存在しなかった新しいツール、パターン、アプローチはあるか？

この4つの質問は数分で答えられる。省略するとスプリントが代償になる。

バックログと進行中の作業の間、スプリント詳細化のフェーズでチケットがハイライトされているワークフローレーン

Justがこのステップをどう自動化するか

難しいのは、確認すべきと知ることではない。難しいのは、確認を一人の記憶に頼らず、ワークフローの一部にすることだ。

Justは計画とインサイトのフローの中にWebサーチのステップを組み込んでいる——すべてのチケットのデフォルトとしてではなく、外部のコンテキストが重要なチケットでチームが有効にするオプションとして。有効にすると、Justはプランを生成する前にissueに関連する現在の情報を取得し、依存関係の最近の変更、競合のパターン、規制のシグナル、エコシステムの変化を構造化された出力として提示する。

結果として得られるのは、モデルがトレーニングされた時点の真実ではなく、今日実際に真実であることを反映したプランだ。これは現在Atlassianエコシステムで利用可能な、Jira計画へのリアルタイム市場調査の最も直接的な統合だ。

確認はステップになる、習慣ではなく。ステップはチームの変化を生き延びる。習慣はそうではない。プロダクトを直接見たいなら、JustのMarketplaceページにある。

実行計画とレビューの前に市場とエコシステムの確認がハイライトされた5ステップの計画フロー

今の5分か、後のスプリントか

バックログが古くなる間も、市場は止まらない。依存関係は破壊的変更をリリースする。競合があなたが半分まで作った機能をローンチする。規制はスプリントカレンダーとは無関係な日付で施行される。

チケットが書かれてからリリースされるまでの間が、前提が古くなる場所だ。スプリント詳細化前の簡単な市場確認は、余分なプロセスではない。動くものに触れるすべてのチケットに必要な、最低限の注意義務だ。