個人でのAI活用の次に必要なものは何か──LINEヤフーでAIDD Workshopを開催して見えた、組織導入の条件

こんにちは、井上です。

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 という形を取ったのか、そしてそこから見えてきた組織導入の条件を共有します。

私たちは、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日目は自走しながらの検証と持ち帰り設計に重心を置き、実務へ戻せる形にすることを狙いました。

今回のワークショップも、チームが実際に手を動かしながら進められる場として設計しました。ここで大きな役割を果たしたのは、Orchestration Guild のメンバーです。

Guild は各事業ドメインのエンジニアが横断的に参加し、現場の実践知をもとにコンテンツを磨き、参加チームの伴走や学びの共有を支える存在です。DevRel と Guild、そして技術品質を支える Technical Directors が連携することで、再現性のある学びの場を作っています。

詳細は AI 活用スキル向上ワークショップ「Orchestration Development Workshop」記事一覧 も参考になります。

実際にやって、参加チームが痛感したこと

今回のワークショップを通じて、いくつかはっきり見えたことがあります。その中でも特に重要だったのは、次の 4 点です。

価値が大きかったのは、実装そのものより前工程だった

AI コーディングエージェントの話をすると、どうしても「コードをどれだけ速く書けるか」に注目が集まりがちです。もちろんそこにも価値はあります。

ただ、今回のワークショップで参加チームがより強く実感していたのは、むしろ前工程でした。たとえば、曖昧な要求を論点に分解する、要件を言語化する、チーム内で認識を揃える、何を先に決めるべきか整理する、次の作業単位に落とすといった工程です。

これは新しい理論を発見したというより、実テーマを持ち込んで試したからこそ、自分たちの課題として具体的に痛感したといった方が実態に近いと思います。

AIDD の価値は、AI が前進を支え、人が重要な判断と責任を担う構造をつくることにあります。だからこそ、実装フェーズだけでなく、その前段の整理こそが成果を左右することが、現場の感覚として共有されました。

ボトルネックはツールではなく、コンテキストだった

もうひとつ、多くのチームが共通して直面したのは、AI Skill を入れるだけでは速くならないということです。

AI の出力品質は、渡したコンテキストの質に大きく依存します。仕様、用語、制約、設計意図、既存コードとの関係、運用ルール。これらが整理されていない状態では、AI はもっともらしい答えは返しても、実務に耐える形にはなりません。

この点も、頭では分かっていた話ではあります。ただ、実際に自分たちのテーマで試すと、コンテキストの不足がそのまま出力の不安定さやレビュー負荷として返ってきます。多くのチームにとって、これは「知っていたこと」ではなく、実務の痛みとして実感したことでした。

だからこそ、仕様や用語、制約を整理すること自体を周辺準備ではなく、組織的な AI 活用の土台づくりとして扱う必要があります。

チーム参加だからこそ、見える論点があった

今回のワークショップでは、個人での参加ではなくチーム単位での参加を前提に設計しました。この方針は非常に重要だったと感じています。

AI 活用は個人の作業効率化としてスタートすることは可能です。しかし、現場で意味のある形にしていくには、一人の視点だけでは不十分です。ビジネス側、企画、デザイン、エンジニア、リーダーなど、多様な役割（Role）がそれぞれ持つ観点や暗黙知を引き出すことで初めて、「どこで AI を使うのか」「誰がレビューを行うのか」「どの成果物を正解とするのか」「既存のフローにどう戻すのか」といった論点を具体化できます。

個人で試しているだけでは表に出にくい、合意形成や責任分界に関する課題も、チームで同じテーマに向き合うことで初めて明確になりました。

組織導入には、意思決定者の関与が効く

もう一つ大きな発見は、意思決定者やリーダー層が参加しているチームほど、その後のアクションにつながりやすかったという点です。

AI 活用は現場だけで完結すると、「便利だった」で終わってしまう傾向があります。しかし、組織全体へ広めるには、「どの領域から始めるか」「どこに時間を投資するか」「何を標準化するか」「どこまでを運用に組み込むか」といった判断が必要です。

今回、そうした判断に関わる人が最初から場に参加していたため、ワークショップ後の議論は単なる「面白かった」で終わらず、次の具体的なアクションへとつながりやすくなっていました。

運営して初めて見えたこと

今回のワークショップを通じて印象的だったのは、AIDD（AI Design & Development）の実務検証そのものだけでなく、同じ場に集まって対話すること自体がチームの前進条件になっていたことです。

実務テーマに取り組むと、普段は明文化されていない前提や、役割ごとに異なる認識が自然と表に出てきます。そうしたズレをその場で言葉にし、すり合わせる時間があることが、AIDD を試すこと以上に大きな意味を持つ場面もありました。

また、休憩や食事を含めてチームが同じ場所で会話を続けられる余白があったことも無視できません。形式的な会議だけでは出にくい相談や雑談の中から、次に試すべきことや組織として整えるべき論点が見えてくるケースも多々ありました。

AIDD を組織で進めるために必要なこと

適用しやすいテーマから始めること

最初から何にでも AI を適用しようとすると失敗します。比較的進めやすいのは、要件や論点の整理余地が大きいテーマ、関係者の認識合わせが重要なテーマ、既存情報をある程度集められるテーマ、小さく一回試せるテーマです。

軽量に始められる入口を作ること

AIDD と聞くとどうしても大規模な変革に見えます。しかし実際には、最初からフルセットで始める必要はありません。むしろ、1 つの機能だけ、1 つの要件整理だけ、1 つのレビュー観点整理だけのように、小さく始められる入口がある方が広がりやすいです。

コンテキスト整備を業務として扱うこと

仕様や用語、制約、設計意図、判断理由を整理することは、AI 活用のためだけの追加作業ではありません。本来、チームの開発力を高めるために必要な資産化そのものです。

ただし、重要性は理解していても、日々の開発現場では後回しになりがちです。だからこそ、これは個人の善意や趣味に任せるべきものではなく、チームや組織として時間を確保すべき業務として位置づける必要があります。

おわりに

今回のワークショップを通じて改めて感じたのは、AI活用の本質は「強力なツールを導入すること」だけではないということです。

重要なのは、AI に何を渡すか、どこで人が判断を下すか、チームでどう運用するか、そしてその仕組みを組織に根付かせるかを、共に設計していくことにあります。

AIDD は単なる開発効率化のテクニックではなく、ものづくりの進め方そのものを問い直す取り組みだと感じています。

だからこそ、実際のテーマを持ち寄り、チームで試し、行き詰まりながら進む今回のような場には大きな意味があります。AI で何ができるかを見るだけでなく、自分たちの開発プロセスに何が不足しているのかまで可視化できるからです。

今後も、AI を単発の実験で終わらせず、現場で再現可能な形にしていくための取り組みを続けていきたいと思います。