AI はチームのずれを直さない。見えにくくするだけだ。

魔法の精の問題

AI について考えるとき、いつも頭に浮かぶたとえがあります。AI は魔法の精のようなものです。こちらが言ったことはそのままやる。でも、こちらが本当に言いたかったことまでは汲み取ってくれません。そのずれの中で、驚くほど多くの開発が崩れていきます。

この状況には見覚えがあるはずです。プロダクト側の人が四つのことを同時に抱えながら、二分で Jira チケットを書きます。そのチケットが悪意で雑なのではありません。ただ、曖昧で、急いでいて、不足が多く、しかも口に出されなかった前提が詰め込まれているだけです。

エンジニアリング側はそこに書いてある言葉を頼りに筋の通ったものを作ります。ところが二週間後のレビューでは、誰もが結局こう言います。そういう意味じゃなかった。

誰も嘘をついていません。誰も怠けていません。ただ、仕事を始める前に肝心の意図が十分にはっきりしていなかっただけです。AI が相手だと、この問題はさらに厳しくなります。モデルには、チームの中に漂っている暗黙の文脈がありません。チケットにほとんど文脈が入っていなければ、魔法の精はほぼ何もないところから動くしかありません。

いちばん弱い材料

そもそも、プロダクトについての本当の知識はどこにあるのでしょうか。コードベースにはアーキテクチャ、命名、依存関係、実装の境界があります。デザインファイルには見た目の言語、操作の型、そして繰り返されてシステムになった判断があります。過去のチケットや文書には、チームの言い回しや、普段どんなふうにトレードオフを語るかが残っています。

Jira チケットは、そのほとんどを知りません。多くの場合、スタック全体の中でいちばん文脈が乏しい材料です。だから、チームがチケットを AI ツールに貼り付けて高品質な出力を期待するのは、いちばん情報量の少ない入力から、いちばん良い答えを引き出そうとしているのと同じです。

そのため、出力はもっともらしく見えても、実態には合わないことがよくあります。受け入れ条件が想定している利用者が違う。デザイン案が、実際には絶対に出さない見た目へ流れていく。技術的な提案が、今の技術構成や配備の前提、あるいはチームがあえて採らない近道を無視している。AI が「失敗」しているわけではありません。貧弱な説明をもとに、できる範囲で答えているだけです。

自信たっぷりの的外れ

多くの Jira 向け AI ツールは、だいたい同じ形をしています。Issue を開く。ボタンを押す。説明文や受け入れ条件、場合によってはサブタスク分解まで返ってくる。結果が速く、整っていて、見た目もきれいなので、生産的に感じられます。

だいたい、こんな流れです。

• issue を開く。
• ボタンを押す。
• 整った文章、条件、場合によってはサブタスクを受け取る。

でも、整っていることと、認識がそろっていることは別です。入力が曖昧で文脈もなければ、出力はその曖昧さをもっと自信ありげに言い換えただけです。実際には、この手のツールが問題を悪化させることさえあります。見た目がきれいになるほど、実装に入る前に前提を疑い直す空気が弱くなるからです。

ここに静かな危険があります。入ったものが粗いなら、出てくるものも粗い。ただし今度は、その粗さが見出しや箇条書きや断定口調で飾られています。チームは、より自信を持ちながら、同時により分からないまま実装へ進んでしまえます。

AI が本当に必要としているもの

AI が Jira issue に対して本当に役に立つものを出すには、少なくとも四つのことを理解している必要があります。

• プロダクトそのもの: 何をしているのか、何が重要な成果なのか、その機能は利用者と事業の何を良くするのか。
• デザインの言語: 見た目の型、UI 部品群、操作の癖。これがあるからこそ、出力がありきたりな見本ではなく、自分たちのプロダクトらしく見える。
• 対象となる利用者: その人たちは誰で、何を必要とし、何を期待し、何を知らないのか。これは文言、操作設計、境界条件をほぼすべて変えます。
• 技術構成: 実際のフレームワーク、実行境界、連携、データ上の制約、技術的な限界。どんな提案が妥当かは、ここに左右されます。

面白いのは、たいていのチームがこれをすでに持っていることです。コード、文書、モック、チームの記憶の中にはあります。ただ、それが AI に見える形で Jira の中に置かれていないだけです。だから Jira だけを見る道具は、プロジェクトでいちばん大事な文脈を見落としてしまいます。

この文脈の層をどう作って再利用するかの実践版は、あなたの AI はプロダクトを推測している で詳しく書いています。

コードのほうがよく知っている

今のコーディングエージェントで本当に面白いのは、リポジトリを読むのがうまく、そこから平易な文脈を引き出せることです。Claude Code、Codex、あるいは別の強いコーディングエージェントに対して、プロダクトの目的、技術構成、実装の境界、既知の穴、事業上の兆しを markdown で要約してほしいと頼めます。必要なのは数分であって、一週間の文書整備ではありません。

ここで前提が変わります。二文しかないチケットから真空状態で生成させる代わりに、プロダクト、デザインシステム、利用者、技術構成の土台を渡せるようになります。そうなると、モデルは暗闇で即興するのではなく、実際のプロジェクトに近い世界の中で考えられます。

答えは最初からコードベースの中にありました。コンポーネント名はデザインの言語を示し、ドメインモデルはプロダクトの考え方を表し、連携先やライブラリは技術的な境界を語ります。文脈をゼロから作る必要はありません。別の AI が安定して使える形に取り出せばいいのです。

まだ決まっていないこと

プロジェクト文脈が十分でも、AI が推測では埋められないもう一つの問題が残ります。まだ誰も決めていないことです。どの Jira issue にも、権限、段階的公開のルール、境界条件、後方互換、操作の細部、そして本当に成功と呼べる状態が何かといった前提が隠れています。

それらの判断は、着手したからといって消えません。ただ、スプリントの途中で顔を出すだけです。そして、それは気づくには最も高くつくタイミングです。デザイナーは、基準にすべき既存画面はどれかを尋ねます。エンジニアは、その流れに使える API がすでにあるのか知りたがります。受け入れ条件はログイン済み利用者を前提にしていたのに、体験の半分は匿名だったと気づく人もいます。どれも後から見れば意外ではありません。最初からそこにありました。

だから、文脈だけでは足りません。質問も必要です。しかも、チケットそのものと実際のプロダクト文脈の両方に根ざした具体的な質問です。既存利用者にも適用するのか、新規利用者だけなのか。途中でブラウザが閉じたらどうなるのか。管理者だけの機能なのか。一回限りの操作なのか、繰り返される振る舞いなのか。こうした率直な答えの積み重ねのほうが、もう一枚きれいな仕様書を増やすより、ずっと認識をそろえてくれます。

Just でのやり方

これはそのまま Just: AI Assistant for Jira に組み込んだ流れです。

1. まず、プロジェクト文脈を四つの構造化された項目に一度だけ設定します。プロダクト概要、デザインシステム、利用者像、技術構成です。Just には、Claude Code やほかのコーディングエージェントに流して、これらの要約をリポジトリから作らせるための指示も用意されています。一度貼り付ければ、その文脈は以後のチケットでも使い回せます。
2. 次に Jira issue を開きます。毎回の作業ごとにプロンプトを工夫したり、追加設定をしたりする必要はありません。Just は保存済みの文脈と issue を一緒に読み、プロジェクトの実情に沿った示唆を出します。そのうえで、汎用的ではない確認質問を返します。質問は、プロダクト、技術的な現実、チームのデザイン言語を踏まえたものです。
3. そして計画を作ります。Just はその回答から、要件、設計の方向性、境界条件、期待される結果、そしてチームが実際に進められる構造化された実行の道筋を組み立てます。必要なら最新のウェブ文脈も取り込みますし、五つの主要な AI 提供元すべてに対応しているので、各段階で最適なモデルを使えます。狙いは魔法っぽく見せることではありません。速い何かではなく、正しいものをチームが作れるようにすることです。全体の流れは aiapps.me で確認できます。

何が変わるのか

では、なぜ多くの Jira 向け AI ツールは、認識ずれの問題を良くするどころか悪化させるのでしょうか。理由はたいてい同じです。曖昧さがすでにチケットの中に入ったあとで登場し、その曖昧さを整っていて完成しているように見せてしまうからです。

本当の効きどころは、その前にあります。チームが本当に何を望んでいるのかを先に明らかにし、隠れた判断を実装前に表に出し、AI に十分な文脈を渡して、情報の乏しい依頼から推測させるのではなく、プロダクトの実際の形の中で働かせる必要があります。

要するにそこです。仕事を始める前にチームが自分たちの望みを理解していれば、AI は役に立ちます。そうでなければ、出力は見事に見えるかもしれませんが、その混乱の代償は後から手戻りとして返ってくる可能性が高いです。