西新宿の中心で、AIをさけぶ - Adwaysエンジニアブログ

「助けてください・・・」僕は心の中で、誰にともなくそうつぶやいた。

季節がひとつ巡るほどの、ほんのわずかな時間。三ヶ月前には不可能だったことが、今では当たり前のように可能になっている。AIという存在の爆発的な成長は、立ち尽くす僕を置き去りにして、遥か彼方へと加速していくようだった。

・・・ご無沙汰しています。 ADWAYS DEEE アドプラットフォーム事業部でマネジャーをしている、「TD（ともだ）」です。

この発表は、僕がAIと出会い、その存在を組織という世界に浸透させるために行った、ある「成果発表会」についての記録です。

AIをどう組織に定着させ、文化として育んでいくべきか。その答えを探して彷徨う迷える子羊たちにとって、この記事が暗闇を照らす一筋の光になれば幸いです。

なぜ、AI成果発表会（AIを叫ぶ）を実施したのか？

2024年の年末頃からAIエージェントが盛り上がりをみせると、2025年に入ってAIの進化/普及が急速に進み、どの企業でもAI導入・活用が活発化していきました。
こうした流れの中、自組織でもAI活用が急務になり、2025年7月に組織戦略として

「AI（人工知能）の積極的な活用とシステム基盤の刷新を行い、開発生産性と組織能力を向上させて、プロダクトチームへの価値提供を最大化する」

を掲げることになったのです。

戦略KPIのひとつに「AIに関するアウトプット行動・組織全体の奨励活動の実施」を設定し、以下のようなゴールを目指すことに決まりました。

AIを活用する文化を定着させる。（AIが当たり前になり、ノウハウが共有される）
グループ会社内において、所属組織がAI活用をリードする。

その取り組みの一環として、実施したのが今回の　「AI成果発表会」 です。
グループ内でリード、ブランディングするためには、いかにして検証をすばやく実施してアウトプットできるかが肝になります。

幸い自組織では、年始からGitHub Copilot/Cursor/Devin/Claude Codeと利用検証を実施していたため、9月には共有会を実施できました。

開催までの時系列

リードやブランディングに必要なもの。それはスピード感です。
7月に戦略を決めてから、遅くても四半期中に実施できるように進めました。今回、自社で実施しているLT会、通称「ALT（ADWAYS LIGHTNING TALK）」のスペシャルバージョンとして、ALT運営メンバーに全面協力を仰ぐことができました。

過去にイベント実施の知見やノウハウがなかったので、本当に助かりました。感謝です。

7月〜
- 組織戦略として、大々的にAI活用強化を明示し、シニアエンジニア＋各チームでAI導入・検証を実施
8月〜
- ALT運営メンバーとコラボレーションが決定。実施準備を開始
9月5日
- 「ADWAYS LIGHTNING TALK × ADWAYS DEEE AI成果発表会」を実施。
9月末
- ふりかえりの開催

「ADWAYS LIGHTNING TALK × ADWAYS DEEE AI成果発表会」の実施

かっこいいタイトルとイベントのアイキャッチ画像も準備できました。

ちなみにタイトルやアイキャッチは、サポートメンバーがAI（Claude Code）を使ってさくっと作成してくれており、ここでもいろんな意味で 「AI」 を感じることができました。コードを書くだけではなく、画像生成も良い感じに実施してくれるため、自分たちだけで制作を完結でき、非常に効率的に準備を進めることができたと思います。

発表コンテンツを紹介したいと思いますが、全てをご紹介すると長編ブログになってしまうので、かいつまんでご紹介できればなと思います。

発表１　

この発表では、CTOからDEEEにおけるAI投資の現状と、生成AIの活用において「視点を変える必要がある」というメッセージが伝えられました。

各領域におけるAI活用状況

[営業]
GeminiやClaudeを用いた広告分析の効率化や、Difyやn8nを用いたオペレーション作業の撲滅（業務プロセスの自動化・データ処理）を目指し、特にルール化が難しい部分に対しても、LLMによって曖昧さを受け入れながら自動化を進めていく。

[開発]
Cursor、Devin、Claudeといったツールを活用し、「開発生産性3倍」を目指します。PdM（プロダクトマネージャー）や非エンジニアがDevinやCursorを使って実装の依頼や仕様調査を行うなど、非エンジニアへの恩恵も高めていく。

[カスタマーサクセス]
自社プロダクトを通じてAI機能の提供価値を向上させていく。

効率化の視点の変化

AIエージェント時代では、効率化の視点が従来の「標準化/マニュアル化」から、「できる化（頼む）」「自動化（任せる）」「自創化（指し示す）」へと変わります。また、AIの恩恵を受けてエンジニアの仕事の「価値のマップ」が大きく変わり、「価値のあり方」自体も変化していきます。

今後は、開発プロセス全体をプラットフォーム視点で見直し、人がボトルネックにならない設計を再考することが重要になっていきそうです。

発表2

この発表では、Anthropic社が開発した対話型コーディング支援AIツール「Claude Code」の導入実績と、生産性を最大化するための具体的な利用プラクティスが共有されました。

【実績と所感】

Claude Codeは従来のツールに比べて、期待に近いコードが高速で出力され、真の「AIコーディング」体験を提供してくれます。2ヶ月間の定量的な結果として、1ヶ月あたりのマージPR数は約2.5倍、コミット数は3倍に増加しました。その結果、手でコードを書く機会が激減し、代わりにマークダウン（CLAUDE.mdやメモリの内容）を書く機会が最も多くなりました。

【実践プラクティスの紹介】

プロンプトの抽象度を下げる
- 具体的で詳細な要求を記述することで、期待に合致する可能性が大幅に向上します。
タスク分割
- ユーザーストーリーをサブタスクに分割してAIに渡すことで、出力精度が向上し、レビュー負荷が軽減します。
Hooksの活用
- 特定のイベント時にコマンドを強制実行する仕組み（Hooks）を利用し、ファイル末尾の改行追加やフォーマット実行（prettier、go fmtなど）をAIが忘れても、人間が見逃しても必ず実行される確実性を確保できます。
カスタムスラッシュコマンド
- 再利用可能なプロンプトとして定義し、複雑な定型作業（例: dependabotのPR確認とマージ）を自動化します。
サブエージェント
- Goのイディオムや組織のガイドラインを学習させた専門エージェントにタスクを委譲することで、特定のタスクに合わせた専門性を確保できます。

他のエンジニアへの横展開やサポートを実施することで、個人だけではなくチーム全体の開発生産性の向上を目指していきます。

発表3

この発表では、AIが働きやすい環境を構築し、その価値を最大限に引き出すためのドキュメント整備の重要性を伝えることの重要性が共有されました。

【課題と戦略】

現状、組織関連・ドメイン知識・開発関連のドキュメントが「まとまっていない」「古い、あるいは正しくない」という課題があり、まだまだAI活用の事例が少ないです。「AI自身が恩恵を生み出せるdocs環境構築（with Notion）」を目指し、AIの自律的な継続的学習のためには、Knowledge base（散在するドキュメントからナレッジを生成）とEvals（評価や判断のログをナレッジとして蓄積）が重要な要素になってきます。

【具体的な事例の紹介】

知識の一元管理
- figjamなどに散らばる「ユビキタス言語」情報をNotion DBで一元管理し、これを学習データとして生成AIに渡すことで、作業効率が向上。
設計意図の共有
- AIがプログラムから学習できない 設計における「Why（なぜ）」 の部分を抑えるため、 ADR（アーキテクチャに関する意思決定の記録） を収集し、仕様理解と調査の効率化を実施。
運用タスクの自動化
- AI x playbook x GitHubの組み合わせにより、PdMが自立型AI（Devin）を使って、新規OW導入などの運用対応を自然言語のやり取りのみで完結できた。
AIによるドキュメント蓄積の効率化
- ADRの形式をGeminiで学習させ、音声入力とテキストでADRを作成する手法により、通常30分以上かかる叩き台を5分で生成し、ドキュメント蓄積の効率化を実現。

AIを強力なパートナーにするためには、ドキュメント整備から共に働く環境を構築し、コンテキスト駆動でAIを活用して生産性を向上させることが重要です。

発表4

生成AIが登場した現代において、ペアプログラミング（PP）がどのように変化し、なぜ依然として重要であるかが共有されました。

【ペアプロの本質】

ペアプログラミングは、二人でコードを書き、ドライバーとナビゲーターの役割を交代しながら進める開発スタイルです。その最大の効果は、「認識の共有」を常に起こせることにあります。これにより、属人化の防止、知識・技術移転（文章にならないニュアンスも含む）が可能です。

【AI時代のペアプロの継続】

生成AIエージェントの待ち時間にペアの一方が暇になる可能性も指摘される中、発表ではペアプロは続けるべきという結論が出されました。 AIを使ったペアプロでは、プログラミング言語ではなく自然言語を使って生成AIに話しかけることが中心になりますが、対象が変わってもペアプロの良さ（認識の共有）は変わらず、生成AIの効果が純粋に上乗せされます。

【具体的な変化とナビゲーターの役割】

AI導入後、ドライバーの動きは大きく変わりませんが（「生成AIに任せる」というコマンドが増えた程度）、ナビゲーターの役割はより重要になり、かつ増加しました。

プロンプトを一緒に考える
- 「~~~みたいに聞いてみたら？」とプロンプトを一緒に考える行為自体が、ドライバーの現状を言語化する手伝いとなり、「認識の共有」を促進します。
裏で生成AIを使う
- ドライバーが主要タスクに取り組む間に、ナビゲーターが裏でAIを使って解決策や仕様を調査することで、時間効率を向上させます。

ペアプロが有効であり続けるのは、ソフトウェア開発においてコーディングをした結果、初めて認識できる問題が多く、そこから得た学びをペアプロならば圧倒的に速く、ディティールも含めてインタラクティブに学習できるためです。

発表5

この発表では、AWS開発における非効率性（管理コンソールの画面遷移の煩雑さや、アーキテクチャ図作成時の抜け漏れへの不安など）を解消するため、Amazon Q Developer for CLI（Q Developer）の活用が紹介されました。

【Amazon Q Developerの優位性】

Amazon Q Developerは、コードベースの情報だけでなく、AWSリソースの情報も加味したアウトプットを容易に得られる点が強みであり、開発プロセス全体の効率化につながります。クラウドチームでは、調査・設計（AWSリソース情報取得、アーキテクチャ図作成）、実装・リリース（コーディング）、運用、資料作成など、様々なフェーズで活用されています。

【事例：CodeDeployのアーキテクチャ図作成】

オンプレミスからCodeDeployへの移行検証において、検証段階でIaC化されていないリソースのアーキテクチャ図を作成する必要があり、Amazon Q DeveloperにAWSリソース情報（プロファイル、アプリケーション名など）を加えて作図を依頼したところ、関連リソースの情報を含んだ図を生成してくれました。

Amazon Q Developerの利点は、粗い指示でも能動的に必要な情報を取得し、文脈を理解する 「意図の汲み取り」 能力です。特にTerraformとの相性が良く、検証用のリソース作成、コード化、stateへのimportまでの流れを全てQ Developerに任せることができ、リソース作成のためにマネジメントコンソールに行く必要がなくなります。

検証後に実施したアンケートの回答では、基本的な性能や使い心地はClaude Codeの方が優れているが、AWS開発体験の高さにおいてはAmazon Q Developer CLIが優れていると結論付けられています。

イベントの反響

今回実施するにあたって、どのような反響や影響があったか？参加者の感想や率直な意見を知りたかったのでアンケートを実施しました。

まずはイベントとしてどうだったか？という質問に対しての回答です。
・・・何と！参加者の8割近くの人が「非常に良かった」と好評価となりました。

記入形式の質問でも、以下のようなコメントがあり非常に嬉しかったです。

非常に勉強になった。濃厚な1時間だった。
発表者の皆が生き生きしていたので満点つけさせてもらいました！
他の部署から参加させていただきましたが、かなりAI活用が進んでいる印象を受けました。自部署でももっと推進していかなければならないなと感じました。
同じDiv内でClaudeを使用していたがより効率の良い使用方法をキャッチアップすることができた！業務に活かせそうです！！
エンジニアがAIをどう利用しているかものすごくわかりやすかったです！！（逆に自分たちの部署はまだまだだなと実感できました）

また、「もし第二回の開催がありましたら、参加を希望しますか」の質問については、 8割以上の参加者が「参加したい」と回答してくれており、見切り発車に近かったですが本当に実施して良かったなと実感しました。

ふりかえりの実施

発表後、しばらくしてふりかえりを実施。「しっかり学びを整理して、次に活かしたい」と考えていましたので、ふりかえり手法は simple is best　「KPT(Keep Problem Try)」 に決定しました。

よかったこと

「たくさんの人が参加してくれた」

なんと想定の2倍の人数の参加がありました！当初は60人〜70人を想定していましたが、蓋を開けてみると 140名 近くの参加者が参加してくれており、エンジニアだけではなく、さまざまなロールの人達が、「ADWAYS LIGHTNING TALK × ADWAYS DEEE AI成果発表会」に参加してくれました。

AIへの興味・関心が業界やロール問わず、高くなっていることを改めて実感できました。後日談になりますが、発表者には新卒2年目のメンバーもおり、140名のしかも経営層も含めた参加者の前での発表はさぞかし緊張したと思います。 よく頑張ってくれました！

「アンケート結果が好評価だった」

イベントの反響 でも記載していますが、なんと86%もの方がイベントについて「非常に良かった」と回答してくれました。たくさんの期待を上回る内容を提供でき、大変嬉しかったです。

また、たくさんの温かいコメントもいただき、今後の励みになりました。今回のイベントを通して、実現したかった グループ会社内において、所属組織がAIをリードしていることを体現＋ブランディング できたのではないかと思います。

アンケート抜粋です！

DEEEエンジニアのAI溶け込み方の進み度合いに驚きました。ぜひ自分が所属している部署でも見習いたいと思います。
DEEE でのAI活用がかなり進んでいることがわかりました。自分たちでも検証や活用を進めていますが大変参考になりました。ありがとうございました。
想像以上にDEEEでのAI活用が進んでいてビックリしました。組織でちゃんと取り組めている感じもして、すげーって思いました。
他の部署から参加させていただきましたが、かなりAI活用が進んでいる印象を受けました。自部署でももっと推進していかなければならないなと感じました。

反省点/改善点

「活用事例が偏ってしまった」

発表内容が、エンジニアロール/技術領域に偏ってしまい、PdMやデザイナー領域でのAI活用事例などバランスをとれるとよかったです。

ただし、あまりにターゲットを広げすぎると発表のバランスが崩れたり、内容が薄くなるなどの別の問題が発生するので、当初の目的であった「対エンジニア/技術領域」という部分においては、しっかりアプローチできたかなと思います。結果的にエンジニア以外の参加者が多く参加してくれましたが、イベントの目的・ターゲットをどこにするかブレないことが大切だと学びました。

「準備不足」

あるあるですね。ふりかえると「あれも」「これも」ってなるやつです。小さく始めるという意味では、大きな問題ではないですが、次回はしっかり改善していきます。

利用ツール（今回はウェビナー）に慣れていなかったため、チャットにリアクションができなかった
発表資料を上位レイヤーでレビューすることによって、もっとブラッシュアップができた。
アンケートに、誤字やURL間違いがあった。

次のアクション

「他の組織・部署でもイベント開催を促す」

総合的にみて非常に良いイベントが開催できました。今後は業界的にも他組織や部署でもAI活用が活発化していくことは必須だと思います。今回先行してイベントを実施したことによって得た経験や学びをもとにサポートや支援ができるようになりましたので、ぜひ他の組織も追従してイベントを実施してほしいです。

「PdMやデザイナー、営業の領域におけるAI活用の発表を実施する」

PdMやデザイナー領域においても、n8nやDifyなどのノーコード/ローコードツールを使ったAI活用の事例もどんどん増えてきました。

組織全体として、AI活用をリード・ブランディングしていくためにも、開発のプロセスだけではなくプロダクトとしてのAI活用にフォーカスした内容の共有会も実施したいです。

「内部から外へ。外部登壇の機会を狙う」

社内を制した！・・・わけではありませんが、一旦次のフェーズとして、社外へのアウトプットの強化していきたいと思います。
もしセミナーやイベントでADWAYS DEEEのエンジニアを見かけたら、ぜひ声をかけてくださいね。とても喜びます。

今後

アンケートやふりかえりの内容を踏まえて、すぐすぐに第二回を実施するのではなく、社外へのアウトプットを強化する判断になりました。

今後、AI技術の進歩に伴い、業務へのAIの導入や活用がさらに進んでいきます。

その中でも自社のエンジニアリング組織にあった活用方法の模索や検証サイクルの「TRY & Error」をくり返し、どんな形であれ、ADWAYS DEEEのエンジニアは 「AI」 を叫び続けていきたいと思います。