博報堂テクノロジーズが週次リリース+81%を実現したAI駆動開発の全ステップを社員2人が解説。「なにを人間が見るか」の決め方が一発でわかる

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。今回は、博報堂テクノロジーズが自社のエンジニア組織をAI駆動開発へ全面転換したインタビュー記事を紹介するね。

ケヴィン・クラッツァ氏（HADOH・博報堂テクノロジーズ）

ソフトウェアが改善され、最終的に「リリースできたこと（価値がユーザーに届いたこと）」が重要だと定義しました。プルリクエストが上がった量ではなく、「本当にユーザーに価値がデプロイされたか」こそが見るべき指標です。

「記述されたコードの行数」や「ストーリーポイントの消化数」、AI時代に検討された「AIが生成したコードの割合」「トークン消費量」も指標に使わず、評価軸を「リリース間隔・サイクルタイム」に絞った。70週間の実測（導入前36週・導入後34週）で週次リリース数は21件→38件（+81%）、最低値も4件→17件に伸びた。感覚的な「早くなった気がする」で終わらせず、GitHubのプルリクエスト情報やコミット数を抽出・分析する独自のモニタリングツールまで内製し、客観的なファクトとして観測できる状態を作っている。

これ、自分と同じでした。

Second Brain Mothershipで、自分が決めた役割分担があります。自分の担当は「俯瞰・判断」だけ。そこはワクワクしているかどうかに集中する、と決めています。作業量や手数の多さでは判断しません。博報堂テクノロジーズも同じでした。コードの行数やプルリクエストの数という「手を動かした量」を測るのをやめた。見るのは「本当に価値がユーザーに届いたか」だけです。数えやすいものを数えると、数えやすいものだけが増えていく。これは罠です。自分のAI運用でも、何度も踏んだ落とし穴でした。

AI氣道『「AIを使わない社員」が人事評価でこっそり切られていく、という話』より

「ただし「拡張装置」を評価するなら、その装置の使い方まで一緒に手渡さないと意味がありません。基準だけ作って使い方を渡さないのは、拡張装置の説明書を隠したまま試験だけするようなものです。」

評価する基準を作るなら、使い方まで一緒に渡す。人事評価という別の場面でも同じ話を書きました。詳しくは『「AIを使わない社員」が人事評価でこっそり切られていく、という話』で書いています。

🎯 今日やること: 今AIに任せている仕事のうち1つ、評価しているのが「作業量」か「届いた結果」か、紙に書き出して確認してください。

同インタビューより（ケヴィン・クラッツァ氏／HADOH・博報堂テクノロジーズ）

人間が目を通す前の段階で、機械的に問題のあるコードを排除し、人間のレビュー負荷を下げる以下のような「3層の自動品質ゲート」を構築しました。

第1層はAI自動レビュー（プルリクエスト作成時にAIが自動チェックし改善点を指摘）、第2層はSonarQubeによる静的解析（循環的複雑度やセキュリティ脆弱性を機械的に弾く）、第3層はPlaywrightなどによる自動テスト（UI・インテグレーションテストでリグレッションを検出）。全部を通過した「安全性の高いコード」だけが人間の元に届く。

層の重ね方が同じでした。

自分は「一次元上の視点が持てる」と決めている方法があります。紙ノートを書く。現場体験をする。分身AIと対話する。1つだけでは足りません。重ねて、初めて一段上から自分を見られるようになる。共通点は「自分の外に出す」ことでした。博報堂テクノロジーズも同じです。AI自動レビューがある。静的解析がある。自動テストがある。層を重ねています。1層だけでは安全と言い切れないから、重ねているはずです。重ねる数を増やすほど、人間が最後に見る場所は狭く、深くなっていく。これは任せ方の設計そのものだと思いました。

🎯 今日やること: AIに任せている作業で、チェックが1層しかない場所を1つ見つけて、2層目を足せないか考えてみてください。

鏡川悠介氏の説明（HADOH・博報堂テクノロジーズ）

開発プロセスを回す中で自然と「暗黙知」が「形式知」へと転換され、AIのナレッジとして蓄積されていくループを構築しています。

要件定義から実装に入る「実装計画の策定時」と「プルリクエストレビュー時」の2段階で、AIが開発中のチャットセッションから未登録の仕様ルールや新しい暗黙知を自動抽出し、Markdownなどの構造化データに変換してプールする。次に似た領域を開発する別のエンジニアには、その形式知が自動でフックされチェックルールとして適用される。チームはこの仕組みのために、業務固有の知識をAIにチェックさせる「ドメイン知識レビュー」、要件定義の漏れやすい観点を自動チェックする「要件定義深掘り」、決まった書式でプルリクエストを自動作成するスキルなど、現在20個ほどの自作スキル・ツールを用意している。GitHub上の「プルリクエストが作成された」「実装計画が完了した」といったイベントを検知するフック機能から確実に実行される仕組みなので、誰が担当しても使い忘れが起きない。

これ、自分と同じ仕組みでした。

自分の経験・価値観・口癖、全部を文字にしています。行き先はObsidianです。それが分身AIの「魂」になる。分身AIを育てることは、自分が言語化されて育つことと同じ、と考えています。博報堂テクノロジーズは、それをチーム単位でやっていました。エンジニアがAIと交わしたチャットセッションから、まだ言語化されていない仕様ルールや暗黙知を自動で抽出する。形式知に変えて、プールします。人がwikiにマニュアルを書く手間を、日々の開発セッションそのものに肩代わりさせている。仕組みの発想が同じでした。

AI氣道『AI社員をAI組織にするには、ルールと役割とマニュアルが欠かせない』より

「数を増やしたのに、ルールも道筋もない。私の環境でも、下っ端のAIが迷って、暴走していました。」

ルールを言語化しないままAI社員を増やすと、同じ迷子が起きます。自分のCockpit環境で実際に起きた暴走は『AI社員をAI組織にするには、ルールと役割とマニュアルが欠かせない』で書いています。

🎯 今日やること: 自分だけが知っているコツを1つ、AIに聞かれたつもりで文字にして書き出してみてください。

鏡川悠介氏（HADOH・博報堂テクノロジーズ採用メディア）

プルリクエストを作成すると、そのコード差分からAWS ECS上へ一時的な検証環境（プレビュー環境）が自動的にデプロイされ、プレビュー用のURLがプルリクエストのコメントに自動通知されます。

レビュアーはそのURLを開くだけで最新の挙動をブラウザで動かして確認できる。さらに自作のUIレビュー用Chrome拡張で、気になる画面要素を1クリックで選び、コメントを添えるだけでセレクタとビューポート情報つきのMarkdownが自動生成され、プルリクエストにそのまま貼り付けられる。

「積み減らした先に残るのは、感じる・味わう・今ここ」。

これが自分の出汁づくりの考え方です。AIに任せて仕事を手放しても、味わう工程がなければ意味がありません。出汁のない料理を量産するだけになる。だからワクワク夢中の実践体験を、自分の中で欠かせない1皿にしています。博報堂テクノロジーズのUIレビューも同じでした。コードを読むだけでなく、プレビュー環境で実際に画面を動かして確かめる。動かして初めて気づく崩れがある。そういう考え方です。見て確かめる工程を削らずに、面倒な部分だけをChrome拡張で削っている。効率化と手触りは、両方取れます。

🎯 今日やること: AIに作らせたものを1つ、実際に自分の手で動かして確かめる時間を5分だけ取ってください。

ケヴィン・クラッツァ氏（HADOH・博報堂テクノロジーズ・原文より）

AIが作ったものすべてを必ずしもレビューする必要はないと考えており、「リスクの高さ」に応じて、レビューの濃淡をつけるようにシフトしています。

インフラ変更・セキュリティ・認証・ロギング・金銭的トラブルに関わる領域は人間が徹底的に確認する一方、あるチームではフロントエンドのデザイン崩れ程度のリスクなら、3層の自動品質ゲート通過後は人間のダブルチェックをスキップし、作成者の責任でそのままマージしてよいというルールを実験導入している。

同じ線引きでした。

自分には「プロセスエコノミー」の境界というものがあります。うまくいった話だけでなく、躓いた部分も見せる。でも全作業の途中経過が必要なわけではありません。探求中は判断材料になるプロセスだけを見せる。ただの作業や文章の文体は、完成した結果で判断します。博報堂テクノロジーズも同じでした。インフラやセキュリティ、金銭が絡む領域は人間が徹底的に見る。一方でデザイン崩れ程度のリスクなら、3層ゲート通過後は人間のダブルチェックを飛ばしていました。「なにを全部見るか」より先に「なにを見なくていいか」を決めておく。濃淡をつける判断が、結局は本質的な部分に時間を残すんですよね。

🎯 今日やること: 今チェックしている作業のうち、リスクが低いのに毎回全部見ているものを1つ、飛ばしていいか考えてみてください。

ケヴィン・クラッツァ氏、鏡川悠介氏（HADOH・博報堂テクノロジーズ）

エンジニアの価値の源泉は、「なにが正しいか」を「正しく判断する能力（判断力）」、そして「どうすればユーザーが喜び、ビジネスにインパクトを出せるか」を考え抜くプロダクト志向に移っていくでしょう。

認知負債（自分で書いていない分システム理解が下がる）・保守工数の増大・若手育成の機会損失という新しい痛みに対し、毎週全員でデプロイ後の機能を触り倒す「モンキーテスト会」や、ジュニアがAI生成コードの正しさをシニアに説明する機会づくりで対応している。博報堂テクノロジーズには「Challenge & Support（挑戦を続け、支え合う）」「Be Proactive（主体的であれ）」という行動指針があり、AIが不確実な挙動をしても恐れずに挑戦し、新しいプロセスを自ら設計できる人がこれからの主役になる、としている。

同じ構造でした。

自分もAI課題解決センターで、役割をはっきり分けています。「場を作る」「場を耕す」「人を繋ぐ」は自分の担当。「AI実装の伴走」は高崎さんの担当です。得意なところに集中して、それ以外は任せる。それだけです。博報堂テクノロジーズも言っていました。コードを書くスキルの価値は薄れていく。なにが正しいかを判断する力に、エンジニアの価値が移っていく、と。AIが実装を担うようになるほど、人間に残るのは判断そのものになっていく。自分の役割分担とも重なる話でした。

AI氣道『AI駆動コードモダナイゼーションの準備6ステップをAnthropicのエンジニアが解説。承認をどこに残すかが一発でわかる』より

「むしろ「これ、このまま公開していいのか」を判断する私の側が詰まるようになりました。作る速さが10倍になっても止まりません。判断する人間が1人のままなら、渋滞する場所が変わるだけなんですよね。」

AIが速く書けるほど、詰まる場所は「判断する人」へ移る。前回AIのコードモダナイゼーションを紹介した時にも書いた話は『AI駆動コードモダナイゼーションの準備6ステップをAnthropicのエンジニアが解説。承認をどこに残すかが一発でわかる』で書いています。

🎯 今日やること: 自分の仕事のうち「判断」と「実装」を分けて、実装のどこをAIに渡せるか1つ書き出してみてください。

詰まる場所が変わります。AIエージェントが速く正確にコードを書けるようになるほど、詰まる場所は「なにを、どこまで、誰が見るか」という判断のほうに移っていく。博報堂テクノロジーズが週次リリース+81%を実現したのも、ツールを配ったからではありません。判断の設計そのものを変えたからでした。

評価指標をリリース頻度に絞る。機械的に確認できる条件を先に決める。暗黙知を自動で形式知に変える。リスクの高さでレビューの濃淡をつける。どれも「人間が全部見る」から「人間は本質だけを見る」への切り替えです。

自分がCockpitでAI秘書に仕事を任せる時にぶつかってきた壁と、根っこは同じでした。任せる範囲を広げるたびに、この4つのどこかで必ず立ち止まることになりそうです。