こんにちは、井上です。
LINEヤフーではこれまで、AI活用スキル向上ワークショップ「Orchestration Development Workshop（ODW）」を通じて、個人がAIを使いながら開発や検討を進める土台を広げてきました。実際、コード補完、調査、テスト、ドキュメント作成などの場面で、AIコーディングエージェントを使うこと自体は、すでに多くの現場で一般的になりつつあります。
一方で、次の課題として見えてきたのは、その活用を個人の工夫にとどめず、組織として再現できる形へどう引き上げるかです。
組織としてAIDDを進めるためには、単にツールを配るだけでは足りません。AIが扱えるように、仕様、設計、用語、判断基準、既存コードとの関係といったコンテキストを整理し、AI Readyな環境を組織として整える必要があります。
しかし、この環境整備は現場のエンジニアだけで完結するものではありません。どの業務を対象にするのか、どこまで整備するのか、誰が判断し、どこで合意するのかといった論点には、部門長や企画者を含む意思決定が欠かせません。
そこで私たちは、2026年6月30日から7月1日にかけて、LINEヤフーでAIDD Workshopを開催しました。LINE Plusを含む全21チーム、112名が参加し、各チームが実際の業務テーマを持ち込みながら、AIDDを組織として進めるための前提条件を検証しました。
この記事では、AIDDそのものの一般論を説明するよりも、なぜ今、LINEヤフーで、チーム単位のWorkshopという形を取ったのか、そしてそこから見えてきた組織導入の条件を共有します。
AIDDをどう位置づけているか
私たちは、AIを要件整理から設計、実装、レビューまで開発プロセス全 体の協力者として活用する考え方を、AI Driven Development（AIDD）と呼んでいます。
AIDDは、AIに仕事を丸投げする開発スタイルではありません。また、既存の開発プロセスの横で、部分的にAIを使うだけの話でもありません。
AIがたたき台を作り、人が意図や制約を与え、重要な判断を担い、その結果を次の工程につないでいく。この流れを、分断された作業ではなく、ひとつの開発プロセスとして設計することに意味があります。
ただし今回のWorkshopで主題にしたのは、AIDDの概念説明そのものではなく、それを組織として実務に載せるために何が必要かという点でした。
AIDDは、AIと人の役割分担を設計しながら開発プロセス全体を前に進める考え方です。
AIを補助的に使うのではなく、開発プロセス全体に組み込んで進めるのが、AIDDの考え方です。
なぜ今、LINEヤフーでAIDD Workshopを行ったのか
ここ1年ほどで、AIコーディングエージェントを使うこと自体はかなり一般的になってきました。個人レベルではすでに多くのエンジニアが、コード補完、調査、テスト、ドキュメント作成などでAIの恩恵を受けています。
しかし、組織として見ると、次のような状態で止まりやすいのも事実です。
- 触っている人はいるが、チームの開発プロセスにはつながっていない
- AIの出力をどうレビューすべきかが曖昧
- 既存プロダクトにどう適用すればいいか分からない
- 試してみたが、思ったより使えず、結局個人の工夫で終わっている
- 「便利そう」以上に進まず、組織としての投資判断につながらない
つまり、AI活用は始まっているのに、個人利用から組織的な実践へ進むところで詰まりやすいということです。
ODWが個人のAI活用を広げる場だとすると、今回のWorkshopは、それを組織として機能させるために、AI Readyな前提条件を確認する場でした。
今回のWorkshopは、まさにその壁を越えるために実施しました。AIツールのデモを見せるのではなく、チームで実際のテーマを持ち込み、現場の文脈を使いながら「自分たちの開発にどう組み込めるか」を考える場にしたかったのです。
なぜチーム単位の参加にしたのか
AIDDを組織で進めるとき、個人の理解だけでは前に進みにくい場面が多くあります。
なぜなら、AI活用の価値は単発のプロンプトではなく、どんな情報を渡すか、どこで人がレビューするか、誰が成果物を正とするか、既存のプロセスにどう戻すか、といった実務の流れの中で初めて見えてくるからです。
そして、その設計にはエンジニアだけでなく、企画、要件整理、デザイン、リーダー層など、さまざまな立場の観点が必要です。さらに、どこから始めるか、何に時間を投資するか、どこまで標準化するかといった判断には、意思 決定者の関与が欠かせません。
だからこそ今回は、個人参加ではなく、意思決定者を含むチーム単位での参加を前提にしました。現実の仕事を前に、役割をまたいで対話できる場にすることで、「AIが使えるか」だけでなく、「組織として何を整える必要があるのか」まで見えるようにすることを狙いました。
2日間をどう設計したのか
今回のWorkshopは、単にAIツールを使うハンズオンではなく、理解して、持ち込んで、試して、共有するところまでを2日間で回す構成にしました。
1日目は問題設定とコンテキスト整理、2日目は自走しながらの検証と持ち帰り設計に重心を置き、実務へ戻せる形にすることを狙いました。
今回のWorkshopも、実際にチームが手を動かしながら進める場として設計しました。ここで大きな役割を担ったのが、Orchestration Guildのメンバーです。Guildは各事業ドメインのエンジニアが横断的に参加し、現場の実践知をもとにコンテンツを磨き、参加チームの伴走や学びの共有を支える存在です。DevRel と Guild、そして技術品質を支えるTechnical Directorsが連携することで、再現性のある学びの場を作っています。
詳細はAI活用スキル向上ワークショップ「Orchestration Development Workshop」記事一覧も参考になります。
実際にやって、参加チームが痛感したこと
今回のWorkshopを通じて、いくつかはっきり見えたことがありました。その中でも特に重要だったのは、次の4点です。
価値が大きかったのは、実装そのものより前工程だった
AIコーディングエージェントの話をすると、どうしても「コードをどれだけ速く書けるか」に注目が集まりがちです。もちろんそこにも価値はあります。
ただ、今回のWorkshopで参加チームがより強く実感していたのは、むしろ前工程でした。たとえば、曖昧な要求を論点に分解する、要件を言語化する、チーム内で認識を揃える、何を先に決めるべきか整理する、次の作業単位に落とす、といった工程です。
これは新しい理論を発見したというより、実テーマを持ち込んで試したからこそ、自分たちの課題として具体的に痛感したといった方が実態に近いと思います。
AIDDの価値は、AIが前進を支え、人が重要な判断と責任を担う構造をつくることにあります。だからこそ、実装フェーズだけでなく、その前段の整理こそが成果を左右することが、現場の感覚として共有されました。
ボト ルネックはツールではなく、コンテキストだった
もうひとつ、多くのチームが共通して直面したのは、AI Skillを入れるだけでは速くならないということです。
AIの出力品質は、渡したコンテキストの質に大きく依存します。仕様、用語、制約、設計意図、既存コードとの関係、運用ルール。これらが整理されていない状態では、AIはもっともらしい答えは返しても、実務に耐える形にはなりません。
この点も、頭では分かっていた話ではあります。ただ、実際に自分たちのテーマで試すと、コンテキストの不足がそのまま出力の不安定さやレビュー負荷として返ってきます。多くのチームにとって、これは「知っていたこと」ではなく、実務の痛みとして実感したことでした。
だからこそ、仕様や用語、制約を整理すること自体を周辺準備ではなく、組織的なAI活用の土台づくりとして扱う必要があります。
チーム参加だからこそ、見える論点があった
今回のWorkshopでは、個人参加ではなくチーム参加を前提にしました。これも、かなり重要な設計だったと感じています。
AI活用は、個人の作業効率化として始めることはできます。でも、実際に現場で意味のある形にしていくには、一人の視点だけでは足りません。ビジネス側、企画、デザイン、エンジニア、リーダーなど、さ まざまなRoleがそれぞれに持っている観点や暗黙知を引き出してはじめて、どこでAIを使うのか、誰がレビューするのか、どの成果物を正とするのか、既存のフローにどう戻すのか、といった論点を具体化できます。
個人で試しているだけでは表に出にくい、合意形成や責任分界の論点が、チームで同じテーマに向き合うことで初めて見えやすくなりました。
組織導入には、意思決定者の関与が効く
もうひとつ大きかったのは、意思決定者やリーダー層が参加しているチームは、その後のアクションにつながりやすかったことです。
AI活用は、現場だけで閉じると「便利だった」で終わりやすい側面があります。ですが、実際に組織へ広げるには、どの領域から始めるか、どこに時間を投資するか、何を標準化するか、どこまでを運用に組み込むか、といった判断が必要です。
今回、そうした判断に関わる人が最初から場にいることで、Workshop後の議論が「面白かった」で止まらず、次のアクションへつながりやすくなっていました。
運営して初めて見えたこと
今回のWorkshopを通じて印象的だったのは、AIDDの実務検証そのものだけでなく、同じ場に集まって対話すること自体がチームの前進条件になっていたことです。
実テーマを前にすると、普段は明文化されていない前提や、役割ごとに違っている認識が自然と表に出てきます。そうしたズレをその場で言葉にし、すり合わせる時間があることが、AIDDを試す以上に大きな意味を持つ場面もありました。
また、休憩や食事を含めて、チームが同じ場で会話を続けられる余白があったことも無視できませんでした。形式的な会議だけでは出にくい相談や雑談の中から、次に試すべきことや、組織として整えるべき論点が見えてくる場面も多くありました。
AIDDを組織で進めるために必要なこと
適用しやすいテーマから始めること
最初から何にでもAIを適用しようとすると、うまくいきません。比較的進めやすいのは、要件や論点整理の余地が大きいテーマ、関係者の認識合わせが重要なテーマ、既存情報をある程度集められるテーマ、小さく1周試せるテーマです。
軽量に始められる入口を作ること
AIDDというと、どうしても大きな変革に見えます。でも実際には、最初からフルセットで始める必要はありません。むしろ、1つの機能だけ、1つの要件整理だけ、1つのレビュー観点整理だけ、のように、小さく始められる入口がある方が広がりやすいです。
コンテキスト整備を業務として扱うこと
仕様や用語、制約、設計意図、判断理由を整理することは、AI活用のためだけの追加作業ではありません。本来、チームの開発を強くするために必要な資産化そのものです。
ただし、重要だと分かっていても、日々の開発の中では後回しになりやすい。だからこそ、これは個人の善意や趣味にせず、チームや組織として時間を確保するべき仕事として扱う必要があります。
おわりに
今回のWorkshopを通じ て、あらためて感じたのは、AI活用の本質は「強いツールを入れること」だけではないということです。
重要なのは、AIに何を渡すか、どこで人が判断するか、チームでどう運用するか、そのやり方をどう組織に根付かせるかを一緒に設計することです。
AIDDは、単なる開発効率化のテクニックではなく、ものづくりの進め方そのものを問い直す取り組みだと感じています。
だからこそ、実際のテーマを持ち寄り、チームで試し、詰まりながら進める今回のような場には意味があります。AIで何ができるかを見るだけでなく、自分たちの開発プロセスに何が足りないのかまで含めて見えるからです。
今後も、AIを単発の実験で終わらせず、現場で再現できる形にしていくための取り組みを続けていきたいと思います。
