【イベントレポート】コンテキストエンジニアリングは「AIへの渡し方」の技術──サイバーエージェント×DeNAが語る、スピードと品質を両立する開発組織のつくり方

AIコーディングツールが普及して約1年。多くの開発組織が直面しているのは、もはやツールの機能不足ではない。本質的な課題は、AIにプロジェクト固有の文脈（コンテキスト）をどう渡し、品質をどう統制するか――つまり「AI時代の開発アーキテクチャ」が未整備なまま走り出していることにある。実装は速くなったのにレビューが追いつかない、個人のAI活用がチーム資産にならない、生成コードがブラックボックス化して現場が疲弊する。こうした“あるある”を乗り越える鍵として注目されているのが「コンテキストエンジニアリング」だ。

本イベントでは、AI駆動開発を全社規模で推進するサイバーエージェントとDeNAのキーパーソンが登壇。レベル定義による全社推進、“片手間”で82%の工数削減を生む自律開発、SSOT（Single Source of Truth:信頼できる唯一の情報源）を介した職能横断のコミュニケーション設計など、明日からの現場改善に直結する実践知が次々に語られた。本イベントレポートでは、単なるセッション要約ではなく「開発組織の課題解決ストーリー」として、両社の違いが見える形で整理してお届けする。

イベント概要

イベント名：AI駆動開発の最前線｜コンテキストエンジニアリングが変える開発プロセス〜スピードと品質を両立する実践知〜
主催：ファインディ株式会社（Findy Team+）
形式：オフライン／オンラインのハイブリッド開催
開催日：2026年 4月21日（火）
イベントページ：https://jp.findy-team.io/event/live/context_engineering_260421/
登壇者
- 降矢大地氏（株式会社サイバーエージェント／CyberAgent Developer Experts, Flutter・AI Driven Dev）
- 佐々木亮氏（株式会社ディー・エヌ・エー／DeNA AI Link Devin推進部部長）
- モデレーター：沢井拓氏（ファインディ株式会社 PM室副室長／Findy Team+ プロダクトオーナー）

セッションは「①各社の取り組み紹介」→「②パネルディスカッション（コンテキストの設計・共有／AIと人間の役割分担）」→「③Q&A」の流れで進行した。

セッション①｜サイバーエージェント：組織と個人の両面からAI活用を底上げする取り組みを推進中

課題・背景

サイバーエージェントグループは従業員数約8,000人、エンジニア約1,200名を抱え、メディア＆IP・広告・ゲーム・AIと事業領域は幅広い。プロダクト数は降矢氏いわく100以上。この規模ゆえに、全社一律でAI活用を進めるのは容易ではない。

象徴的なのがツールの分断だ。Amebaのように10年以上続くサービスを抱える同社では、ドキュメント管理もタスク管理も部署ごとにバラバラ。Linearを導入しMCPで連携を頑張るチームもあれば、Jiraを使い続けるチームもある。「進められているところと、そうでないところが混在している」のが実情だった。

取り組み内容

サイバーエージェントでは2028年までに開発プロセスを完全自動化することを目標に掲げており、それに向けて組織と個人の両面からAI活用を底上げする取り組みを進めている。
組織面では、各部署のAI活用レベルを相撲の番付のように格付けし可視化する、当社独自の取り組み「AI番付」を2026年4月にスタート。
個人においては、AI活用の成熟度をレベル1〜5に定義付け可視化している。
レベル1は「3年前にCopilotがすごいと言っていた段階」、レベル4は「人間の介入はありつつもほぼ自動化」、レベル5は「人間の介入がほぼ不要」。

降矢氏のチームは現在レベル3。企画はプランナー（人間）が考えるが、仕様書はNotion AIで生成し、仕様書からのタスク生成も一部AIが担う。実装はDevin・Claude・Codex、コードレビューはDevinとGreptile（一部CodeRabbit）という構成だ。

ただし降矢氏は、自動化の前提として「当たり前にやっていた開発プロセスを言語化・図式化して整理すること」の重要性を強調する。AIに任せる範囲を見極めるには、まず人間の業務フローを俯瞰できる状態にする必要があるからだ。

具体的な実践として印象的だったのが2つの事例だ。

ひとつはGitHubのPRレビュー自動化。Devinがプレイブックに基づいてPRの難易度を判定し、ラベルを付与してコメントする。さらに、人間が「ミディアム」判定を「イージー／ハード」に付け替えた履歴を毎週学習し、Devin自身がプレイブックを更新するPRを出す――という自己改善ループを回している。

もうひとつがEntireというツールの活用だ。GitHubのPRはあくまで“コードを生成した結果”だが、Entireは「どんなプロンプト・どんなコンテキストでその実装に至ったか」という過程を帰属できる。「メンバーが恥ずかしいと言いながらプロンプト全文がdescriptionに出てくる」が、これがレビュー精度の向上につながるという。

成果・学び

仕様書からデザインドックを生成し、そこからPRを生成する――という開発プロセスの一部自動化を実現。全社で「2〜3年後にレベル5を目指す」という共通目標のもと、各チームが競い合う構図ができている。
「まだうまくいっていないので、今日はDeNAさんにDevinの使い方をもっと聞けたらいいなと思いながら、ここに来ました」（降矢氏）
トップランナーですら“挑戦中”と語る、その率直さが現場のリアルを物語っていた。

このセッションから得られる示唆

成熟度の可視化が推進力になる。レベル定義とランキングは、組織に健全な競争と共通言語をもたらす。
自動化の前に業務の言語化・図式化を暗黙のプロセスを俯瞰できなければ、どこをAIに任せるか判断できない。
AIレビューに人間の判断を学習させる。自己更新するプレイブックは、運用しながら賢くなる仕組みの好例。
生成“結果”だけでなく“過程”を残す。プロンプト来歴の可視化はレビュー品質に直結する。

セッション②｜DeNA：「AIオールイン」と“片手間”が生む82%削減

課題・背景

DeNAは2025年4月、100%子会社としてDeNA AI Linkを設立した。BtoCのイメージが強い同社が、BtoB領域でAIコンサルティング・ソリューション提供を行うための新会社だ。佐々木氏はその中の「Devin推進部」部長を務める。ツール名を冠した部署は世界的にも珍しく、Devin開発元のCognitionからも歓迎されたという。

背景にあるのは、会長・南場氏が掲げた「AIオールイン」というスローガンだ。一言でいえば「社員を半分にする」――対外発表と同時に社員も知り、「リストラされるのか」とざわついたという。だが真意は、既存サービス運用の生産性を高め、そこで生まれた人材を新規事業や既存サービスの競争力強化へ再配置することにあった。

取り組み内容

DeNAのDevin活用を象徴するキーワードが「片手間」だ。ゴリゴリにチューニングできるエンジニアはClaude等をメインで動かす一方、仕様が明確なものは「裏でガーッと自律的に動いてくれる方が助かる」。環境設定もバーチャルマシン上で完結するため、本業の片手間で回せる。

成果は具体的だ。あるサービスの基盤・データフローの異常を監査するエージェント開発では、「従来なら4人で1年かかる規模」を、1人が10%以下の工数・3ヶ月でDevinとともに構築した。

Devinの強みである「自律性」と「既存コードの解釈性の高さ」が最も活きるのがコードマイグレーションだ。DeNA社内ではPerlからGoへの書き換えを、エンジニアリングマネージャーが片手間・1ヶ月で完了し、約6倍の速度改善を実現。支援先の千葉銀コンピュータサービスでは、AI駆動開発のノウハウがほぼない状態からVB.NET→Pythonの書き換えに着手し、1ヶ月・約82%の工数削減を達成した。しかもこれは2名が約2割の割合で関わった“兼務”体制での成果だという。

もうひとつ示唆深いのがSSOTによる職能横断のハブ化だ。エンジニアは仕様を把握しているが営業・CS・事務局は把握できていない――そんな社内プロダクトで、SSOTを整備し全員がDevinを介して質問する仕組みを作った。営業は見積もりや要件充足の確認を、エンジニアに聞かずDevin経由で完結できる。

「一人ひとりが3倍、5倍の成果を出せても、職能を超えた瞬間にやり取りが大きく発生して、組織的には実は効率化できていないかもしれない。それをDevinにコミュニケーションハブになってもらうことで成果を出している」（佐々木氏）

成果・学び

ソースコードもドキュメントもコンテキストになる。そして、非エンジニアがローカル環境を整えずSlackやTeams上でAIを使える――この「コンテキストとそれを引き出せる場の設計」こそが、組織的な成果を生む要だと佐々木氏は語った。

このセッションから得られる示唆

“片手間”で回る自律性を設計する。仕様が明確なタスクは、ゴール設定とイシュー分解を丁寧に行えば本業の傍らで完遂できる。
マイグレーションはAIの最有力ユースケース。既存コードの解釈性が高いツールは、レガシー刷新で桁違いの効果を出す。
個人の生産性向上は職能の壁で頭打ちになる。組織的効率化には「職能を超えるハブ」の設計が必要。
非エンジニアの参加障壁を下げる。クラウド完結・チャット起点の設計が、AI活用の裾野を広げる。

セッション③｜パネル：コンテキストの設計・共有と、AI/人間の役割分担

テーマ1：コンテキストをどう設計・共有し、標準化するか

両社にとって「コンテキスト」とは何か。佐々木氏は「SSOTに組み込むものほぼ全て」と定義する。ソースコード、仕様書、要件定義、プロダクトの更新履歴――「遡れるもの全て」だ。自身の事業部では営業の議事録や顧客の組織情報・中期計画までGitHubで管理し、ミーティング前にAIでさらうという。

ここで両社が口を揃えたのが、「渡せればいいというものではない」という論点だ。

「渡しまくってはいます、あらゆるものを。でも、それを本当に全部適切に読めているか。最適な状態で引っ張ってこれているか。むしろそこが課題になっている」（佐々木氏）

Devinについては興味深い特性が語られた。ソースコードが膨大になるほど回答精度が上がるというのだ。Devinは連携したコードを自ら「DeepWiki」としてインデックス化・構造化する。佐々木氏はこれを「テスト勉強でまず教科書を自分用に要約してから友達に説明する」状態にたとえた。

降矢氏は一段引いた視点を示す。プロンプト／コンテキスト／ハーネス／環境エンジニアリングは「これまでやってきたことに名前がついただけ」だと。仕様書を構造化しておくことは、新メンバーのオンボーディングを楽にするのと同じ。その対象が人間からAIに置き換わっただけだ、と整理する。

ただし、Devinが構造化済みの状態で動くのに対し、ClaudeやCodexはagent.mdやclaude.mdから読み取り、まずコードを読むところから始まる。「読ませる時間を与えずに指示すれば、よくわからない回答が返ってくる。それはしょうがない」。

ツール選定の本質的トレードオフ

議論は「書き手フレンドリー vs AIフレンドリー」の対立に及んだ。AIに最も適しているのはGitHubだが、GitHub Wikiは企画職にとって使いづらい。画像アップロードやFigmaリンクの貼り付けも快適ではない。一方Notionは使いやすいが、内部がMarkdownではなく独自の「Notionブロック（XML）」のため、余計なトークンが含まれパースが難しい。

降矢氏は「全部GitHubに寄せてコンテキストも移したいが、使いにくいとチームの調整ができないので、Notionに残すという判断を“背中がかゆいな”と思いながらやる。バランスの問題」と本音を漏らした。先週パネルで同席したメルカリCTO・木村氏が1年前のタイミングで「Notionに全振りした」という意思決定には、両氏とも「あのタイミングでは自分には難しい判断」と舌を巻いた。

仕様書の“正しさ”は誰が担保するのか

「仕様書もAIに書かせる」なら、その正しさをどう保証するのか。降矢氏の答えは、ここでもコンテキストだった。過去の仕様書、そのレビューコメント、変更履歴、どんなフィードバックを受けたか――それらを全てRAG化することで、現在の正しさを判断できるという。ただし精度は「8割くらい合っているかな、と思いながらやっている」段階で、人間の関与は不可欠だ。

佐々木氏は、AIが書いた仕様書に欠けやすいものとして「PdMのセンスや意思」を挙げた。

「0から8割まで磨き上げるのはすごく速くなった。でも最後の2割を詰める、そこに魂を込めていくところには、今はまだ人間の目が絶対に必要」（佐々木氏）

「正解を見つけられない作業には人間が介入すべきで、仕様の上でコーディングしてレビューするところはAIに任せる。ふわっとしている部分こそ“人間頑張ろうぜエリア”だ」とまとめた。

テーマ2：どこまでAIに任せ、どこに人が介入するか

DeNAは権限と参照範囲による役割分離で品質統制を実現している。アナリティクス業務では「アナリスト用Devin」と「非アナリスト用Devin」をアカウントレベル（Slackチャンネル）で分離。非アナリスト用は参照コンテキストに準ずるものしか回答できないようプレイブックで制限し、マッチする依頼なら自分でSQLを叩いて数字を返す。範囲を逸脱するものはアナリストが介入する設計だ。「AIに任せきると、変な意思決定を定量的にされてしまうのが一番怖い」という判断からだ。

なお佐々木氏は「ソフトウェアエンジニアリングよりも先に代替されるのはデータアナリストだと思っている」とも語り、だからこそ前向きに取り組めたと振り返った。

降矢氏はこのテーマを3つに分解した。①そもそも「ChatGPTでダイエット相談」レベルのAIユーザーもいる、②Claude CodeやDevinを使いこなす上澄み層もいる、③その間をどう埋めるか。同社では企画職がリモートエージェント（Devin）を解放して使うところまでは至っておらず、Notion AIがその橋渡しになっている。

そして将来像として、全ツールがAI対応し相互接続される世界――「気づいたらできていた」「サーバーが落ちたことすら知らなかった」状態――を描きつつ、その時に残る人間の役割は「アーキテクト＝全体設計」だろうと述べた。

「コンテキストが完全なら、AIは完全体」

コンテキストを完全に渡せばAIは全部できるのか、という問いに、降矢氏は明快に答えた。

「コンテキストが完全だったら、AIは完全体だと僕は思っています。100%用意できれば100%回答できるし、10%しか用意していないなら10%までの回答しか期待するな、です。もう崇めてますわ、AIのこと。自分より頭いいなって」（降矢氏）

AIが悩むのは「わからない情報に対して、わからないなりに頑張って考えているから」。これは新卒と同じ構造だという。佐々木氏も「人間のコンテキストウィンドウは実は狭い」と応じた。

その暗黙知をどう引き出すか。佐々木氏が“効く”と語ったのが新卒の活用だ。1年前、自分が持った新卒にアナリティクスのコンテキストを一から全部作らせた。新卒は部署の内容をいろんな人に聞き、ベテランが「そんなこと気にしないのに」と思うような情報まで引っ張ってくる。

「暗黙知って、僕らは暗黙知だと思っていない。気づけない。だから、あえて人を使って一回形式知化させ、そのタイミングでログとして残す。これが結構有効でした」（佐々木氏）

クロストーク・Q&A

来場者からの質問は、現場の切実な悩みを映し出していた。主要なやり取りを紹介する。

Q. Claude Codeで何でもできそうだが、あえてDevinを使うメリットは？

佐々木氏は「Claude Codeで何でもできると思っている、そこのあなたはかなり上澄みです」と切り返した。環境構築のハードルは想像以上に高く、それをチームで横並びに揃えるのはさらに上位概念だという。Devinはクラウド上にあるため環境構築不要で、各セッションがマイクロVMとして事前に整えられている。「全員が上澄みならClaude Codeでチーム運用すればいい。グラデーションが大きい組織なら、あえてDevinに集約するのもアリ」。

降矢氏は「ローカルエージェントとリモートエージェントの使い分け」という観点を提示。実装はローカルでもできるが、Slack上で皆が見える形でメッセージを渡して実行するのはリモートエージェント（Devin）の役割。「個人でも使うし、チームとしてDevinを用意するのも正しい」。

Q. SSOTの管理方法を具体的に知りたい

佐々木氏によれば、基本はエンジニアが常に管理し続けている。その理由が秀逸だ。

「彼らに一番メリットがある。非エンジニアから聞かれて答えてミーティングして……という、明示的な工数に含まれないけどやらなきゃいけない仕事を削減できる。だから丁寧にSSOTを作る文化が浸透している。“だって自分が楽になるんだもん”という感覚」（佐々木氏）

質問されたら追加し、聞き方のワークフロー（プレイブック）も継続的にアップデートして、完璧版に近づけていく。

Q. ドキュメント形式は？（Markdown vs PowerPoint/Word/Excel）

降矢氏は「書き手にとっての使いやすさをどう取るか」の問題だとし、ClaudeがPowerPoint/Word/Excelに統合され始めている流れに筋の良さを感じつつ、「結局どこをSSOT（正）とするか」を決めきることが重要だと指摘。佐々木氏は、歴史ある企業に多い「Excel方眼紙」も、Excel読み込み用のスキルを整備すれば扱えるようになってきたと述べ、「もうどれでもあまり変わらない。このペースで対応範囲が増えるなら、少し待ってもいい」との見解を示した。

Q. AI活用は誰がどうリードすべきか。現場は通常業務で時間が取れない

ここで両社の推進アプローチの違いが鮮明になった。

降矢氏（サイバーエージェント）は、サイバーエージェントでは、経営層自らがAI活用の推進に積極的に取り組んでいる、と語る。各部署のAI活用レベルを相撲の番付のように格付けし、可視化する「AI番付」もその1つだ。番付は社内で公開されるため、番付が低い組織に関しては、挑戦のサイクルをより一層加速させなければいけないというポジティブな意識づけを行える仕組みとなっている。

佐々木氏（DeNA）は、評価システムと「AIオールイン」の号令を前提としつつ、実態はボトムアップだと語る。各開発チームの自発的な取り組みが全体の流れを作っている。「完全に統制を取ればトップダウンの方が効率はいい。でもやりやすいのはボトムアップ」。その例として、メルカリが100人を集めて現業を放棄させて育成し各部門に投入した事例を紹介。「育てた後に辞めてしまう懸念があったが、業務改善の面白さに気づいて好循環に移っていったという、素敵な話」と振り返った。

Q. 環境エンジニアリングとハーネスエンジニアリングの違いは？

降矢氏はハーネスエンジニアリングを「システムハーネス」と「ユーザーハーネス」に分けて解説した。システムハーネスはLLM（例：Opus）を使いこなすためのClaude Code、そのHook/Skill/Subagentといった機能群。ユーザーハーネスは「僕らがどう使うか」。Devinはユーザーハーネスの部類で、モデルの使い方を”締め上げて”くれる存在だという。環境エンジニアリングは、安全なサンドボックス環境を整えるシステム側の側面と、それを使う人間側の側面の両方を含むが、結論としては両氏とも「ハーネスの一部、というのが一言で言うと正解」で一致した。

Q. AIで開発が速くなっても品質担保は人間。人間がボトルネックになるのでは？

降矢氏は率直に認めた。

「耐えれてないですね、今は。実装スピードは速くなったが、企画も最後のレビューも人間。この間が速すぎて耐えられていない。”PRが多くてシニアエンジニアが疲弊する”という記事をよく見ますが、今はまさにそれです」（降矢氏）

これに対し佐々木氏が示した解決の方向性が秀逸だった。アナリティクスの現場で仕様駆動開発のエッセンスを入れ、レビューを前倒ししたのだ。SQLを書く前にデータフローダイアグラムを生成し、それを人間がレビューしてゴーサインを出す。図にすれば複雑なものも意外と簡単に確認できる。

「AIにとっては不要だが、人間がレビューするために必要な中間成果物を実装前に作る。それでゴーサインを出せば、その後AIが作るものはほぼ100%になり、後工程のレビューがいらなくなる。AIにレビューさせて速くするのではなく、人間がレビューしやすくして速くする」（佐々木氏）

負荷をかける場所を後工程から前工程へ移す――発想の転換が、ボトルネック緩和の鍵になる。

イベント全体のまとめ

共通課題

両社とも、ドキュメント・タスク管理ツールの分断を抱え、各部署で最適解を模索している段階にある。共通して語られたのは、①「書き手フレンドリー vs AIフレンドリー」のツール選定トレードオフ、②実装速度の向上にレビュー・企画が追いつかない人間ボトルネック問題、③人間が書き残していない暗黙知はAIも解釈できないという根本制約だ。

各社アプローチの違い

最大の対比は推進体制にある。サイバーエージェントは「AI番付」によるトップダウン×競争で全社を動かし、DeNAはトップの号令（AIオールイン）を前提にしたボトムアップの実行で広げる。ツール思想も、CAが「ローカル／リモートの使い分け」を重視するのに対し、DeNAはグラデーションの大きい組織を底上げするためDevinへ集約する。AI観も、降矢氏の「コンテキストが完全ならAIは完全体」と、佐々木氏の「渡しまくる、だが適切に読めるかが課題」とで力点が異なる。

成功要因

自動化の前に業務プロセスを言語化・図式化して俯瞰可能にしている
コンテキストを「渡す」だけでなく最適に引ける状態を設計している
SSOTを整備するインセンティブ設計（管理者自身が楽になる）が文化として根付いている
レビューを前工程に前倒しし、人間がレビューしやすい中間成果物を作っている

今後重要になるテーマ

職能を超えたAI活用事例の蓄積と共有。両氏が口を揃えたのは、「個人の生産性向上は職能の壁で頭打ちになる」という認識だ。これからは、各社の成功・失敗のナレッジが共有され始めることで、組織横断・職能横断の効率化が加速していく。そして全ツールがAI対応・相互接続される未来では、人間に残る役割は「アーキテクト＝全体設計」へと収斂していくだろう。

読者へのメッセージ

コンテキストエンジニアリングは、特別な新技術ではない。「仕様書を構造化する」「変更の経緯を残す」「暗黙知を形式知化する」――これまで良いチームが当たり前にやってきたことに、AI時代の名前がついたものだ。だからこそ、自社で今すぐ着手できる。ツール統一を急ぐより「正となる場所」を決める。レビュー負荷は「人間がレビューしやすい中間成果物」で下げる。新メンバーのオンボーディングを暗黙知整備の好機に変える。両社のトップランナーですら「まだ挑戦中」「今は耐えられていない」と率直に語ったように、完成形は誰も持っていない。だからこそ、走りながら整えるしかない。