こんにちは。LINEヤフー株式会社の平野です。普段はYahoo!ファイナンスの主にフロントエンド領域の開発とスクラムマスターを担当しています。
LINEヤフー全エンジニアを対象とした AI利活用を横断的に推進するワークショップであるOrchestration Development Workshopを運営するOrchestration Guildメンバーも担当しています。
Orchestration Guildは、CTOから選抜されたエンジニアが集まり、現場のAI活用の実践知識を横断的に持ち寄るコミュニティです。ワークショップで扱うテーマ提案、実践的ユースケースの共有、技術的観点での品質アドバイスなどを担当し、Orchestration Development Workshopのコンテンツが属人化せず、継続的に発展していくことを支える役割を担っています。
このテックブログでは、Orchestration Development Workshopで開催したワークショップ「CopilotからPilotへ：Agentic Coding実践ワークショップ」の内容を中心に、実施に至る背景とチームへの推進についてもご紹介します。
抱えていた課題と転機
2025年の夏頃、既存の開発フローの中で、私やチームの周辺メンバーのコーディングへのAI活用は未成熟でした。
GitHub Copilotなどを用いてコードの一部を生成する使い方はできていましたが、開発の多くの部分は人間の手で行っている状況で、生産性が上がっているとは感じられていませんでした。
この状況に対して転機となった出来事が2つありました。
1つは仕様書駆動開発の登場です。この開発手法は設計等のドキュメントを最初に作成してから実装を進めるもので、意図したアウトプットが出しやすくなります。私の所属するチームでは、最初に要件定義や仕様書などの作成を行っており、ドキュメントは十分に用意することができていました。そのドキュメントを利用すれば、現在の開発フローをそのままに、AIでのコード生成を効 率化できると考えました。
2つ目は社内で利用できるJiraやConfluenceとAIがMCP (Model Context Protocol)で連携できるようになったことです。上述の仕様書などはConfluenceにまとまっており、このMCPの登場によりスムーズにAIコーディングツールと連携することができるようになりました。
Agentic Codingとは
Agentic Codingは「高レベルの目標を受け取り、ステップに分解し、自律的に実行し、フィードバックで調整する」開発の進め方です。
従来の補助ツールが『目の前のコードの続きを提案する』であるのに対して、エージェントはコードベース全体を読み、ファイル間の関係も理解し、コマンド実行やテストまで含めて「要求が満たされるまで反復する」点が特徴です。
ここで意識すべきなのは、AIに一部分の実装タスクだけを渡すのではなく、「プロダクトの機能が成立するまでの一連の作業」を渡すことです。
テストが落ちたら直す。lintで弾かれたら修正する。ビルドまで通す。このサイクルをAIに回させたとき、はじめてPilotとして機能します。
ワークショップの内容
ワークショップの目的
今回のワークショップのゴールは、開発フローのうち「実装〜Pull request作成」までをAIにやり切ってもらう体験をすることでした。
AIが要件定義や仕様書を生成するところから行うような開発の仕方も存在しますが、今までの開発フローを大きく変えるのはコストがかかります。要件定義・仕様書作成は人間が担い、テスト・レビュー・リリースも最終的には人間が責任を持つ。一方で、実装計画の作成、実装、Pull request作成、初回のレビューはAIに寄せて、実務に近い形で一連の流れを体験する構成にしています。
ワークショップの流れ
Agentic Codingについて紹介しつつ、3つのステップのハンズオンを行いました。
Step1：タスク理解と実装計画作成
Agentic Codingを安定させる鍵は、最初に『実装計画』を作って、手戻りを減らすことです。 いきなり曖昧なタスク指示をしても、作りたかったものと違うものが生成され、手戻りが発生してしまっては本末転倒です。そこで、仕様書を読ませ、実装の詳細な計画をAIに作ってもらい人間がレビューをすることでAIが意図通りの実装を生成できるようにします。このアプローチは主要なAIコーディングツールにPlan Modeが用意されている点からも自然でしょう。
普段の開発ではJiraチケットにタスクの内容が記載されており、関連する案件仕様書などがConfluenceにまとまっています。これを元に実装計画をAIに作成してもらいます。
ハンズオンではサンプルアプリケーションリポジトリを用意し、Claude Code用とGitHub Copilot 用にカスタムスラッシュコマンドを用意しました。
Step1ではJiraチケットのURLを引数にコマンドを実行し、生成される計画を人間がレビューするところまでを行います。
Plan カスタムスラッシュコマンド
---
description: 作業計画を立てる際に使用する
---
# 概要
あなたはこのプロダクトの内容に精通したエンジニアです。
ユーザーから入力されるJiraやWikiのURLから情報を収集し、コードを分析して作業計画書を作成してください。
# 手順
1. Jiraチケットはjira MCPツールを使用して情報を収集する
2. JiraチケットのEpicリンクが存在する場合、そのEpicに関連するすべてのチケットを収集する
3. Jiraチケットに含まれる、あるいは別途入力されたConfluenceのURLから情報を収集する際は、confluence MCPツールを使用する
4. 収集した情報をもとに関連するコードを分析する。コードを分析する際はExplore Agentを使用する
5. 分析結果をもとに作業計画書を作成する
# 注意事項
- 作業計画書の作成場所は、`specs/{案件名orチケット番号:英数字ハイフン区切り}/plan.md`とする
- コードを分析する際は、memoryがあれば確認しコーディングスタイルなどを把握した上で行うこと
- 作業計画書には以下の内容を含めること
```
# 作業計画書: チケットID
## チケット情報
## 概要
### 背景
## 対応箇所
### 対象URL
### 対象コンポーネント
## 受け入れ条件
## 関連Pull request・チケット
## 技術的な分析
### 実装が必要な箇所
## 作業タスク
## 参考情報
### 実装の参考箇所
## 注意事項
### 影響範囲
### テスト観点
## 想定工数
## チェックリスト
```
- 別のリポジトリでの作業が必要な箇所がある場合、その旨を明記し、別途対応することを促すこと
- wikiを参照する際、案件仕様書の他に、画面仕様書やコンポーネント仕様書なども参照することコマンドの要点は以下です。
- MCPのツール利用によるドキュメント調査についての指示
- コード調査でのExplore Agentの利用
- 実装計画をファイルに書き出す
1つ目はツールを正しく使ってもらうための指示を入れていることです。普段の開発では関連チケットにConfluenceのURLが記載されていることが多いため、関連資料まで調査するように指示しています。
2つ目のExplore AgentはClaude Codeのための指示です。Claude Codeに組み込まれているこのsubagentを使うことでメインセッションのコンテキストを汚さずに、場合によっては並列でコード探索の処理をすることができます。
3つ目の実装計画をファイルに書き出す点は、AIが作成した計画を人間がレビューするためという点と、セッションを新しくしても永続して利用できるという点がメリットです。そして、関連資料をまとめておくことで、後ほどAIにPull requestを作成してもらう際にもそのまま使えるという点もメリットです。
Claude Codeの場合、本記事執筆時点ではPlan Modeを使うことで~/.claude/planに計画をファイルに書き出したり、Explore Agent を自動で使うようになっており上記の内容は十分満たせるため、ドキュメント調査のみをカスタムスラッシュコマンドやsubagentに分離してPlan Modeを使うのも良いです。
Step2：実装とPull request作成
Step1でAIに作成してもらい、人間が確認した実装計画書をAIに渡して、そのままコード生成と簡単な検証を実施させます。
ここでも実装とPull request作成コマンドを用意し使ってもらいました。
Implementカスタムスラッシュコマンド
Step1で作成された実装計画書のファイルパスを引数に実行します。
---
description: "引数で指定した実装計画書をもとに実装を行う。"
---
$ARGUMENTSに整理された実装計画に基づいて実装を行ってください。
▼具体的な手順
1. 実装計画書の内容を確認し、必要な実装箇所を把握する
2. 実装計画書に基づいてコードを実装する
3. 必要な範囲のテストコードを追加・修正する
4. testコマンドを実行し、すべてのテストが通過することを確認する
5. 実装が完了したら、lintコマンド、buildコマンドを実行しデプロイできる状態になっているかを確認し、問題があれば修正するカスタムスラッシュコマンドの内容はシンプルですが、ここで大切なのは作業のステップを明示する点です。
実装し、テストを実行し、lintやbuildを通すことで、最低限の品質を保ちつつ、AIに自走してもらいます。最初にステップを明示することで、Claude CodeやGitHub CopilotなどのコーディングエージェントはTodoリストを作成し、行うべき作業を忘れないように進めてくれます。
Pull request作成カスタムスラッシュコマンド
実装を終えて内容を確認し、問題がなければPull request作成カスタムスラッシュコマンドを実行して、Pull requestを作成します。このコマンドはOrchestration Development Workshopの第1回で紹介されたものを利用します。
このコマンドはテンプレートに沿って説明文を書いてくれる点が便利です。私のチームではテンプレートには関連資料を記載する欄を設けているのですが、Step1で調査した内容をここでAIに記載してもらうことで面倒な作業を減らすことができます。
Step3：AIレビューと指摘対応
Orchestration Development Workshopの第1回では AIスクリーニングレビューのカスタムスラッシュコマンドが紹介されています。Step3でもこのコマンドを使います。
このコマンドはすでに記載されているコメントも取得するプロンプトになっています。
Step2で作成されたPull requestをセルフレビューした際のコメントや、他のメンバーからのレビューコメントも含めてAIに読ませることができます。
レビューが完了すると、AIが修正すべきと考えた点と、Pull requestにすでについているコメントに対してのAIの判断などが出力されます。このコメントを人間が確認し、実際に修正が必要だと思うものがあれば、そのまま修正するように指示します。
AIによるレビューの効率化だけではなく、そのままAIに修正をしてもらうことで修正対応コストを抑えるのです。
Agentic Codingを推進する上でのメリットと注意事項
ワークショップで紹介したAgentic Codingのフローには大きく2つのメリットがあります。
1つはコード生成アウトプットの速度向上です。このフローでは、AIエージェントが自律的に行動することで人間が確認、指示する回数が減るため、AIが実装している間に他の作業をしたり、エージェントを複数並列で実行することで今までよりもコード生成のアウトプットを増やすことができます。
また、 実装計画を作成する点は事前にどのような作業を行うのかのイメージを持つことにも使え、見えていなかった作業やリスクに早く気づくことができます。
一方で注意点もあります。AIが大量にコードを書きますが、今の時点では人間がレビューするため、レビュー負荷は増えます。また、今までの開発の体験とは大きく変わるという点でもストレスに感じるかもしれません。そして、AIが書いたコードに対して人間が責任を持つという意識も不可欠です。プロダクトの品質維持も大事ですし、低品質なコードはレビュアーの負担になったり、プロダクトの負債になります。
ワークショップの結果
今回のワークショップでは事前準備の実施を前提とした実践編と、丁寧なサポートを行う導入編の2回開催とし、約2500名の方に参加いただきました。参加者を対象に「今回のワークショップの内容について、あなたの実践状況を教えてください」という趣旨のアンケートを実施したところ、結果は以下の通りでした。
| 選択肢 | 内容 | 割合 |
|---|---|---|
| 4 | すでに継続的に活用している | 9.5％ |
| 3 | すでに一部を試している | 34.7％ |
| 2 | まだ試していないが、近いうちに試す予定がある | 48.5％ |
| 1 | まだ試していないし、試す予定もない | 5.8％ |
| その他 | - | 1.5％ |
コーディングについてのワークショップで馴染みの作業であることもあったためか、4割以上の方が何らかの形で実践しているとのことでしたが、一方でおよそ半数の方がまだ 実践できていない状態です。
今回のワークショップではMCPサーバーの活用の仕方や、エージェントへのタスクの渡し方などのより具体的なコーディング領域への活用方法を扱いました。参加者からは具体的な活用イメージを持つことができたとの声もあり、まだ実践ができていなかった方を中心に業務への活用が期待できるかと思います。
ワークショップの準備で得られた知見
チーム向けの実施内容を土台にし、Orchestration Development Workshopの準備で得た知見を紹介します。
所属するチームではスクラムのスケーリングフレームワークであるLeSS (Large-Scale Scrum)を採用しており、開発タスクをユーザーストーリーとして扱い、詳細な受け入れ条件をチケットに記載することをルールとしています。この環境下ではJiraチケットに何をするべきかの詳細な情報がまとまっており、AIにJiraチケットを渡すだけである程度安定した開発が可能になっています。
一方で、Jiraチケットに曖昧な情報しか記載されていなければ、AIにそのまま開発をしてもらうのは難しいでしょう。所属するチームではたまたま下地が整っていましたが、AIが必要な情報を参照できる環境を整えるというのも、大事になってくるということが改めてわかりました。
おわりに
AIのモデルや周辺ツールの進化は速く、また多くの方が情報を発信していて、事例を見ると実践や導入する難しさを感じる場面も多くあります。また、社内の状況などから導入できないというケースもしばしばあるでしょう。
しかし、このスピードについていかなければ、時代の変化においていかれてしまうという危機感があります。
このような状況のなか、AIやそのツールを業務で使えるようになるには以下のような課題があると考えています。
- 導入のイメージが持てていない
- 普段の業務に時間が取られて導入や利活用の準備時間が持てていない
大きな変化を起こすものは導入するのも、適応するのも難しいです。今回のワークショップでは、既存の開発フローは大きく変えずにコンパクトに導入できる形の取り組みとし、普段の業務の中で取り入れられるようにしました。
この考え方はコーディングの業務に限らないと考えています。既存業務のどの作業をどのように変化させることができるのかというイメージと、導入しやすさを揃えることでAI利活用をさらに推進することができるだろうと考えています。
改善は後からたくさんできます。まずはミニマムに、そしてクイックに導入して変化を体験することでAIと共に開発する時代に適応していきましょう。
