AIネイティブなソフトウェア開発ライフサイクルを構想から実稼働へ

この記事は、Atlassian brings the AI-native SDLC from playbook to production の抄訳です。

 

AIコーディングアシスタントは、ほんの始まりに過ぎませんでした。いまやAIは、ソフトウェアデリバリーのライフサイクルのあらゆる場面に登場しています。作業の計画立案、コードの記述、プルリクエストのレビュー、そしてインシデント対応の支援まで。

アトラシアンの「2026年 AI SDLC調査」では、エンジニアリングリーダーの94%が自社のチームはすでにAIを活用していると回答した一方で、それをスケールさせ、適切に統制する仕組みが整っていると答えたのはわずか6%にとどまりました。

アトラシアンは、AIネイティブなSDLC（ソフトウェア開発ライフサイクル）を構築するためのプレイブックを公開しました。その要点を簡潔にまとめると、次のようになります。まず土台、すなわちコンテキストと測定の仕組みを強化し、そのうえで、計画・設計・開発・レビュー・保守という日々の業務のあり方を見直すというものです。

従来のプロセスに後からAIを付け足すのではなく、このプレイブックは、より速いオペレーティングモデルの築き方をチームに示しています。そこでは依然として、人間が方向性を定め、重要な判断を下し、何をもって良しとするかを決めるのです。

今週開催されているTeam 26 Europeにおいて、アトラシアンはそのプレイブックを実際の製品として形にしています。Jira、Confluence、Loom、DX、そしてJira Service Managementに渡る新機能が、エージェントの作業をTeamwork Graphに接続し、計画・開発・レビューにわたる業務を連携させ、そしてリーダーに対して「実際に何が成果に結びついているのか」をより明確に示します。人間が判断を下し、エージェントが実行し、そのうえでチームはこの一連のループから学び、改善を重ねていくのです。

AIエージェントには優れたコンテキストが必要です。それがなければ、エージェントは誤った内容に対して自信満々になってしまいます。Atlassian Teamwork Graphは、コード、ドキュメント、意思決定、各種の基準、そして80を超えるサードパーティのソースを、権限を考慮した一つのレイヤに統合します。これにより、エージェントは、あなたのチームが長年かけて築き上げてきたシステムに対する理解を、より深く得られるようになるのです。

Code Contextは、大規模かつ複数リポジトリにまたがるコードベースの理解を、Teamwork Graphに取り込みます。開発者やAIコーディングエージェントは、ソースコードと、それに関連する作業の両方を横断して推論できるようになります。

仕組み

• 大規模なコードを理解する：連携されたBitbucketおよびGitHubのリポジトリにわたってコードをインデックス化し、ファイル、シンボル、クラス、関数、そしてそれらの関係性をマッピングします。

• 適切なコンテキストを見つける：字句検索とセマンティック（意味）検索を組み合わせ、正確なコード検索と自然言語による質問の両方に、複数リポジトリを横断して回答します。

• コードを作業に結びつける：関連するJiraの作業項目、Confluenceのページ、Loomの動画、さらにSlackやGoogleドライブといった連携ツールの情報に基づいて回答を導き出します。

下の並列比較では、両方のエージェントが想定される技術的な問題を把握できていますが、Code Contextを使用している側（右）は、その仮説を、全体的な変更を理解したうえで検証済みのシステム診断へと発展させています。

こうしたコンテキストの土台が整えば、チームはSDLCの各工程を刷新し始めることができます。まずは計画立案からです。

コンテキストが散在した状態での手作業による計画立案から、顧客、組織、そしてコードベースのコンテキストに基づいた、AIによる支援を受けた要件定義へ

計画立案は、白紙の状態から始めるべきではありません。チームは、作業を分担する前に、意図、トレードオフ、リスク、そして担当者を把握しておく必要があります。

Plannerは、人間やエージェントが構築に着手する前に、大まかなアイデアを明確で共有可能な計画へと変換することで、チームが仕様駆動開発を実践できるよう支援します。

仕組み

• アイデアを実行可能な計画に変える：プロンプトから始めると、Plannerが明確化のための質問を投げかけ、スコープ、制約条件、成功基準、そして未解決の決定事項を定義します。

• 計画を実際のコンテキストに基づかせる：Jiraの作業項目、Confluenceページ、Slackのメッセージ、Code Contextを通じた関連コード、そして過去の意思決定といった、Teamwork Graphのシグナルから情報を引き出します。

• リアルタイムで更新されるConfluence上の計画を作成：目的、選択肢、推奨される進め方、リスク、依存関係、担当者、そしてレビュー用の質問を盛り込んだ、構造化された計画や仕様を作成します。これらはステークホルダーがコメントを付け、共同で練り上げていくことができます。

• 計画をエージェントがすぐに使える状態にする：承認された計画を、順序立てられたJiraの作業項目へと分解します。各項目には、説明、受け入れ基準、リポジトリへのリンク、依存関係、そして人間とAIエージェントが安全に実行するのに十分なコンテキストが含まれます。

[図]

静的なモックアップと受け渡し作業により、あらゆるビジュアル面の変更がエンジニアリングに依存していた状態から、デザイナー自身がライブプロトタイプを構築し、UIコードを生成し、バグを直接修正できる状態へ

AIネイティブSDLCにおいて、デザインは孤立した静的な受け渡し作業ではなく、作業のループの中へと組み込まれます。静的なフレームに代わって、ライブプロトタイプが使われるようになります。デザイナーやプロダクトマネージャーは、わずかな余白の調整まで毎回エンジニアを経由させるのではなく、UIの更新や修正を自分で直接反映できるようになります。動画を使ったチームからのフィードバックは、そのままプロンプトになり得ます。これにより時間が節約されますが、同時にプロダクトの判断に求められる水準も高まります。変更が速くなることが本当に良い結果につながるのは、チームが品質、アクセシビリティ、そして意図を引き続き守り抜いている場合に限られるのです。

Record for Agentは、デザイナーが静的な受け渡しから「見せて伝える」開発へと移行することを支援します。プロトタイプのウォークスルー、ビジュアルフィードバック、あるいはUIのバグを長文の仕様書に書き起こす代わりに、デザイナーは伝えたい内容をLoomで録画し、その動画を、AIエージェントがUIコードの生成、プロトタイプの構築、あるいはコンテキストが豊富な作業項目の作成に利用できる構造化されたプロンプトへと変換できます。

仕組み

• デザインの意図を捉える：Figmaのプロトタイプ、実際のプロダクトフロー、あるいはデザインレビューのウォークスルーを録画しながら、何を変更すべきか、なぜそれが重要か、そしてユーザーがどのような体験をすべきかを語ります。

• ビジュアル面のコンテキストを保持する：Loomはクリック、URL、画面の変化、キーフレームを記録するため、エージェントは、デザイナーがどのコンポーネント、状態、あるいはインタラクションを指しているのかを正確に理解できます。

• マジックペンで細部を指し示す：録画中に、ボタンを丸で囲んだり、余白の問題を指し示したり、不要な要素に取り消し線を引いたり、注目してほしい画面の部分に印を付けたりできます。

• 動画をエージェントがすぐに使える計画に変える：Loomは録画内容を構造化されたアクションプランに変換します。これはJira Coding Agentやサードパーティのコーディングエージェントに引き渡せるため、チームは曖昧さを抑えながら、プロトタイプの作成、UIコードの生成、あるいは実装作業の起票を行えます。

作業を事前に計画・記録し、進捗を提供スピードで測っていた状態から、リアルタイムのシグナルに適応し、AIエージェントがライブコンテキストを活用して、より速く構築し反復していく状態へ

開発者はすでに、Cursor、Claude Code、Codex、Copilotといったツールで本格的な作業を行っています。しかし、その作業の多くは、個々のターミナルウィンドウの中に閉じ込められたままになっていました。AIネイティブSDLCは、そうしたエージェントを、作業がすでに行われている場所へと連れてきます。これによりチームは、さらに多くのコーディングエージェントをJiraに直接接続できるようになります。エージェントは作業項目を引き受け、実際のコンテキストに基づいて構築を進め、そしてそのチケット上に直接結果を報告できるのです。

Jiraは、拡大を続けるサードパーティのコーディングエージェントに対応しました。Cognitionの Devin、Factory、Warp は、Atlassian Marketplaceで利用可能となり、OpenAI Codex も近日対応予定です。チームは、ツール間でコンテキストをコピー&ペーストすることなく、すでに信頼して使っているエージェントをJiraに取り込むことができます。

仕組み

• エージェントに作業を割り当てる：作業項目の担当者フィールドでコーディングエージェントを選択すると、エージェントは概要と説明をタスクとしてセッションを開始し、その後レビュー用のプルリクエストを作成します。

• コンテキストの中で呼び出す：コメント内でエージェントを@メンションし、具体的な指示を与えます。エージェントはそのコメントをタスクとして、作業項目をコンテキストとして扱い、進捗をチケット上に報告します。

• 自動化に組み込む：課題の作成、ラベル付け、ステータス変更、担当者の割り当て、コメントといったJiraのイベントをトリガーとして接続することで、あなたが選んだチェックポイントで人間の承認を挟みつつ、作業が自動的に適切なエージェントへと流れていきます。

• ローカルのエージェントセッションを追跡する（近日対応）：IDEやターミナルでのエージェントセッションをJiraに取り込むことで、コンテキストが引き継がれ、エージェントの活動が人間の作業と並んで管理されるようになります。

各エージェントが同じJiraの画面・機能に接続されるため、チームはその仕事に適したエージェントを選び、特定のツールを中心にワークフローを作り直すことなく、時間の経過とともにエージェントを切り替えていくことができます。

問題の発見が遅れ、時間がかかり一貫性のないレビューから、エージェントが共通の基準を数分で適用し、人間がより十分な情報に基づいて判断を下せる状態へ

レビューは、スピードがプラスにもマイナスにも働きうる場面です。エンジニアリングの基準を一元的に定義し、コンテキストとして持ち運べるようにすることで、エージェントは、JiraのAI Reviewや、Cursorのようなサードパーティのエージェントを通じて、新規・既存のコードに対する最初のレビューを実行できます。日常的なフィードバックはより速く届き、その一方で、判断を要する決定については引き続き人間が責任を持ちます。

エージェントは、Bitbucket上のプルリクエストについてLoomのウォークスルーを録画できます。これにより、レビュアーは、何が変更されたのか、そしてその成果物が当初の要件を満たしているのかを素早く把握できます。

仕組み

• ガイド付きのウォークスルーを生成する：エージェントは、プルリクエストを、変更の意図、最も重要なファイル、主要な実装上の判断、そしてレビュアーが確認すべきリスクやエッジケースを明らかにする、短いナレーション付きのフローへと変換します。

• レビュアーがすでにいる場所にコンテキストを作る：エージェントがBitbucketのプルリクエストを作成または更新する際、Loomのウォークスルーをプルリクエストの説明欄に直接添付できます。これにより、その説明は、リンクされたJiraのコンテキストやレビュースレッドのすぐ隣に配置されます。

• 変更をより速くレビューする：レビュアーは、まずLoomを視聴することで、何がなぜ変更されたのかを素早く理解し、その後それをJiraのチケットや当初の要求と照らし合わせて、不足している作業や想定外の挙動を見つけ出せます。そのうえで、コメントを残したり、変更を要求したり、プルリクエストを承認したり、あるいは動画の中で浮かんだ点についてエージェントや作成者に質問したりできます。

技術的負債を生み出す、受動的で手作業によるメンテナンスから、トリアージ、根本原因分析、そして日常的な修正を自動化する、能動的でAIの支援を受けた運用へ

フィーチャーフラグを片付けたり、リグレッションを追ったりする担当者は、そのコードに最後に触れた人物とは限りません。そして、エージェントがそうした日常的な作業をより多く引き受けるようになるにつれ、チームは、起きていることを後から継ぎ合わせて把握するのではなく、リアルタイムで見て信頼できる状態を必要とします。

Agent Sessionsは、エージェントの作業を、Jira上で可視化し、追跡可能にし、再利用できるようにします。ローカルおよびクラウドのエージェントセッションは、適切な作業項目に自動で紐づくため、チームは、手作業によるステータス更新を追いかけることなく、エージェントが何をトリアージし、診断し、修正しているのかを、人間の作業と並べて確認できます。各セッションは、Teamwork Graphを通じてそのコンテキストを引き継いでいくため、次のクリーンアップ、根本原因の分析、あるいは日常的な修正は、目標、変更内容、意思決定、そして関連する作業がすでに手元にある状態から始められます。

仕組み

• どこからでも始める：開発者は、Slack、計画、バックグラウンドのループ、ローカルのIDE、ターミナルなど、すでに使っているツールからエージェントセッションを開始または継続します。

• リアルタイムで記録する：Jiraはセッションを進行中のまま記録し、関連する作業項目に紐づけます。チケットが存在する前にエージェントが課題の調査を始めた場合でも、開発者はそのセッションをボード上にドラッグするだけで、Jiraがそのコンテキストから作業項目を作成します。

• チーム全体の活動を見る：Agent Sessionsのビューには、チーム全体で進行中のすべての保守・運用作業が表示され、入力が必要な作業、レビュー準備が整った作業、完了した作業といったフィルターで絞り込めます。

• コンテキストをつなぐ：セッションの記録は、目標、変更内容、プルリクエスト、意思決定、そして方向づけのやり取りを捉え、それらをTeamwork Graph内の関連リポジトリ、ドキュメント、作業項目、過去の修正に結びつけます。これにより、根本原因が毎回蒸し返されることはありません。

• 実行のたびに改善する：以降の実行では、その結びついたコンテキストが再利用されるため、エージェントは繰り返し発生する保守作業をゼロの状態から始めることがありません。チームは、トークンと時間を節約しながら、より質の高い修正を得られます。

利用状況の数字は、人々がAIを試しているかどうかはリーダーに教えてくれます。しかしその数字は、AIが時間を節約しているのか、品質を高めているのか、コストを押し上げているのか、あるいは知らず知らずのうちに皆を苛立たせているのかまでは教えてくれません。チームには、AIがどこで役立ち、どこで行き詰まり、そしてどこにプロセスの改善が必要かを示す、フィードバックと指標が必要です。

DX AI Measurement ソリューションは、エンジニアリングリーダーが、AIコーディングツールが測定可能な価値を生み出しているかどうか、そしてチームがどこで支援を必要としているかを把握できるよう支援します。本ソリューションは、AIの利用状況を提供成果に結びつけ、ROIを関連する同業他社グループと比較してベンチマークし、個々のエージェントセッションを実践的なコーチングのためのシグナルへと変換します。

仕組み

• 成果の測定：DX AI Impactレポートは、AIの活動を、スループット、品質、導入状況、摩擦など、リーダーが重視するエンジニアリングの成果に結びつけます。

• ROIのベンチマーク：チームは、自社のAI投資対効果を、地域、企業規模、業種別に匿名化された同業他社グループと比較できます。

• エージェントセッションのスコアリング：Agent Experienceは、要件の明確さ、人間による方向づけ、スコープ、コンテキストの品質、そしてモデルの適合性といった観点から、個々のセッションを評価します。

• モデル適合性の監査：リーダーは、高価なモデルが複雑度の低い作業を処理していた箇所を把握し、より高い効率を目指して利用方法を調整できます。

AIネイティブSDLCは、単にAIツールを導入すればよいというものではありません。それには、チームが計画し、構築し、統制し、学習する方法を変えるための、新しいオペレーティングモデルとマインドセットの導入が求められます。頭一つ抜け出すチームは、統制されたエージェントの実行を、つながったコンテキスト、明確な説明責任、そして継続的な測定と組み合わせます。そして、最初のバージョンがスライドで約束されたほどきれいにいかず雑然としていても、調整を続けていくのです。

あなたのチームをAIネイティブなSDLCの時代へと導く方法について詳しくは、jira.dev をご覧ください。

提供状況：Code Contextは、オープンベータを通じて、アトラシアンの有料顧客に段階的に提供を開始しています。Record for Agentは、現在オープンベータで利用可能です。Planner、エージェントループ、およびAI Reviewは、プライベートアーリーアクセスで利用可能です。Agent SessionsとLoomのインタラクティブなPRレビューは、クローズドな早期アクセスプログラムの段階にあります。DX AI Measurement ソリューションは、現在一般提供されています。

これらのアップデートは、Atlassianの年次ユーザーカンファレンスである Team '26 Europe にて、今年のその他の最新情報とあわせて発表されました。さらに深く知りたい方のために、セッションはライブおよびオンデマンドでご視聴いただけます。