新人教育の同じ説明を減らす。DeNA勝野さんがClaude Codeで作り替えた受け入れの仕組み

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、DeNAの勝野侑馬さんが、新メンバーの受け入れをClaude Codeが伴走する形に作り替えた記事を読んで、解説します。

この記事は、私が保存したブックマークの1つです。私の過去の記事と重なる所がありました。溜めた物は、気づかないうちに古くなる。引き継ぎには、読む量がある。任せる範囲を広げても、人が決める場所は残る。勝野さんの仕組みの中に、その向きの考え方を見つけました。

元ネタは、DeNAのデータ分析チームの話です。会社の規模は違います。でも、スタッフや外注さんを迎えて仕事を教える立場なら、自分の仕事に引き寄せて読めます。私は、元記事を読んで、自分の仕事に引き寄せて整理する立場です。DeNAの運用は勝野さんのものとして、新人教育の同じ説明を減らす、という視点で順に見ていきます。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「「これ、次どこ見ればいいんですか」問題」の節

結果として、初日に終わる人と2週間かかる人が出ます。本人の資質の問題ではなく、そうなる設計になっていたのが問題でした。

引用が伝えているのは、遅れる人が悪いのではない、ということです。遅れるように作られていた、という話です。

勝野さんは、DeNAのデータサイエンス部で、新メンバーの受け入れを見直しました。見直す前から、課題が見えていたそうです。順に書きます。

1つ目は、情報の散らばりです。手順はConfluenceにありました。データ仕様書はGoogle Drive。項目一覧と進捗はスプレッドシート。質問はSlackです。

ものすごく古い資料も混ざっていたと書かれています。

2つ目は、進み方が個人のスキルで変わることです。データアナリストのチームは、統計や分析に強い一方で、エンジニアリングに明るくない方も少なくありません。それでも最初に、環境構築が待ちます。

Docker（アプリを箱ごと動かす道具）でコンテナーを立てます。CLI（文字で操作する画面）から認証を通します。失敗したら、ログを読んで切り分けます。ここが関門です。

結果、初日に終わる人と2週間かかる人が出たそうです。

最後は、受け入れ担当の工数が読めないことです。人が変わるたびに、同じ説明を繰り返します。環境構築とツールの説明だけで、想定以上の時間が溶けていきます。

対応の方針は、4つに整理されています。1つ目は、導線を1つのGitHubリポジトリ（資料やコードを置いておく場所）に集めること。2つ目は、Claude Codeが伴走すること。

環境構築は、可能な範囲で自動化します。新メンバーがたどる道も、1本にします。

ゴールは、オンボーディング（新しく入った人が仕事に慣れるまでの立ち上げ）が終わった時点で、案件にアサインできる状態です。部のことなら何でも答える汎用Botは、最初にスコープ外と決めました。

全部をエージェントで済ませると、部の人と話す機会が減るからです。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「作ったもの」の節

新規メンバーはこのリポジトリをcloneしてClaude Codeを起動し、スラッシュコマンドでオンボーディングを進めていきます。

新メンバーは、リポジトリをcloneします。Claude Codeを起動します。あとはスラッシュコマンド（「/」で始まる決まった呼び出し）で進めます。引用は、その動きがシンプルだと伝えています。

リポジトリの名前はanalyst-onboarding/です。中のknowledge/sources.ymlは、正本（一番元になる資料）のレジストリです。

knowledge/guide/には、学習ガイドが入ります。

docs/には、チェックリストと運用の文書を置きます。workspace/は個人作業の場所で、年と名前の階層です。.claude/skills/には、Claude Codeのスキルが入ります。

CLAUDE.mdには、ドメイン知識と禁止事項が書かれています。

スラッシュコマンドは、9つあります。/setup-connectorsは、コネクタ（ConfluenceやGoogle DriveなどとAIをつなぐ仕組み）の接続確認で、最初に1回だけ使います。

/initは、ワークスペースとブランチを作ります。Draft PRも作ります。

/setup-envは、環境構築のタスクをHuman-in-the-loop（途中で人が確認を入れる進め方）で順に進めます。/onboarding nextは、次にやるべき項目を案内します。

/onboarding progressは、進捗をフェーズ別に表示します。

/ask <質問>は、正本を引いて答えます。/daily-reportは、日報を作ってワークスペースに保存します。/feedbackは、改善提案をimprovements.mdにためます。

/maintainは、教材の鮮度点検と更新の反映です。受け入れ担当向けです。

流れは、初日と毎日と、気づいたときに分かれます。それぞれで使うスキルが決めてあります。勝野さんは運用の節で、受け入れ日に渡すのはリポジトリのURLだと書いています。

伝えるのは、まず/setup-connectorsと/initを叩いてください、の一言です。地味です。でも、ここが肝です。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「設計の話1：教材の本文は、持たない」の節

二重管理は必ずどちらかが腐ります。ならば書ける場所を1つに絞ってしまえば、腐りようがありません。

引用が伝えているのは、同じ情報を2か所に書くと、必ずどちらかが古くなる、ということです。書ける場所を1つに絞れば、古くなりようがありません！

勝野さんの最初の版は、Confluenceやスプレッドシートの内容を、コネクタ経由でMarkdownに転記していました。リポジトリを開けば全部読める状態が、いちばん親切だと思ったからです。

でも、これは失敗でした。

転記した瞬間から、同じ情報がConfluenceとリポジトリの2か所にある。正本が更新されても、リポジトリはついてこない。

勝野さんは、DRY原則（同じことを2か所に書かないという原則）違反ですね、と書いています。

方針を変えて、本文の転記をやめました。流れはこうです。記録票のスプレッドシートが上流です。そこからsources.ymlへ、page_idとfile_idを転記します。

guideとチェックリストは、idだけを持ちます。実行時に、ConfluenceとGoogle Driveから手順の本文を取りにいきます。

リポジトリが持つのは、正本がどこにあるか。それと、その教材で何を身につけるべきか。それだけです。

規約は、次のとおりです。1つ目は、正本のURLとidを書く場所を、sources.ymlだけにすること。2つ目は、ガイドに「正本: <id>」としか書かないこと。アンカー（見出しへの飛び先）も書きません。

見出しが変わった瞬間に、参照が切れるから。最後は、手順の本文をリポジトリで直さないこと。直すなら、正本側で直します。

版が動くデータ仕様書は、固定IDを持たせません。カタログから最新の承認済版を辿る、という解決ルールを書きました。ここでハマった点があります。版の新旧を、更新日時で判定してはいけません。

承認済みの版にも、後から編集が入るから。ファイル名に含まれる版の表記で判定するルールに、落ち着いたそうです。

外部との連携は、自前のMCPサーバではなく、Claude Codeのコネクタ機能だけです。Atlassianは必須です。Google Driveも必須です。Slackは任意です。

新メンバーがやるのは、ブラウザから認証を1回通すことだけ。

AI氣道『Claude Codeのフォルダ設計の考え方を、7つの法則で順に解説』より

「中に溜めた物ほど、気づかないうちに古くなっていくんですよね。だから、どこに置くかと同じくらい、いつの物かを見ておきたいんです。」

この考えを、私は『Claude Codeのフォルダ設計の考え方を、7つの法則で順に解説』で書いています。

勝野さんの「転記した瞬間に腐る」と、私の「いつの物かを見ておく」は、同じ向きだと読みました。置き場所を1つに絞るのも、いつの物かを見るのも、古くなった物を見つけやすくする工夫です。

私は、正本の場所に更新日を添えて持つと、さらに迷いが減ると考えています。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「設計の話2：出力の形を固定する」の節

これらはモデルの性能の問題ではなく、期待する出力の形をこちらが書いていなかっただけでした。

引用が伝えているのは、出力が揺れたのはAIの性能の問題ではない、ということです。期待する形を書いていなかっただけでした。書き足せば直ります。

/onboarding nextの出力が安定しなかったとき、勝野さんが気になった点がありました。1つ目は、冒頭に判断の過程が並ぶことです。「#Xは保留」「#Yは受け入れ担当のタスク」といった文です。

読み手は、次にやることだけ知りたいのに。

2つ目は、手順書へのパスを示すだけで終わることです。毎回リンク先を開かないと作業できません。集約した意味がないですよね。最後は、手順書の条件分岐を全部展開することです。

実際には踏まないケースの説明で、本筋が埋もれます。

そこで、SKILL.md（スキルの中身を書くファイル）にルールを足しました。次のタスクは、結論のみ出します。スキップの理由は、聞かれたときだけ答えます。

手順書は、読んだうえで3〜5ステップに圧縮します。複数画面のスクリーンショットが前提のものだけ、リンク誘導にとどめます。正常系だけ展開します。

分岐は書かず、「うまくいかなかったら詰まったポイントを教えて」と一文添えます。すると、ぴたりと安定したそうです。ここが肝です。

最後のルールには、狙いがあります。新メンバーに「AIに相談すれば解決できる」という体験を積んでもらうことです。

成果物の形も、決め打ちにしました。日報には、やったことを書きます。つまったことも書きます。明日やることも書きます。notes/improvements.mdの改善メモは、5項目に固定しました。

ステータスと現状。問題と改善案。それから参照です。チェックリストは、進捗の単一の情報源です。

日報は、当初「AIが質問してから書く」流れでした。でも、AIのほうが、行動記録から新メンバーの状況を客観的に把握できます。そこで、タスク進捗や困りどころはAIに書かせます。

本人には、自由形式で書いてもらう形にしたそうです。

AI氣道『CLAUDE.mdは何行までが目安？200行以内でも起動時の文字数は増える』より

「引き継ぎを伝えるにも、読む量がある。私なら「何を書くか」と一緒に、「仕事を始める時に何文字読むのか」を数えます。お願いを増やす前に、毎回渡している全体を確かめたい。」

この見方を、私は『CLAUDE.mdは何行までが目安？200行以内でも起動時の文字数は増える』で書いています。

勝野さんの「期待する出力の形を書いていなかった」と、私の「毎回渡している全体を数える」は、同じ向きだと読みました。

AIの出来が悪いと感じたとき、先に確かめるのは、こちらが何を渡し、何を書いていないか、なんです。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「設計の話3：AIにできないことを、先に決めておく」の節

自動化の可否には、書いた時点で希望的観測がかなり混ざります。ここは素直に負けを認めてドキュメントを訂正しました。

引用が伝えているのは、「自動化できる」と書いた時点では願望が混ざる、ということです。だから実際に測り直して、違えば素直に直した。そういう話です。

任せられない作業を先に決めておかないと、AIが「やったつもり」で先へ進みます。事故になります。勝野さんは、そう書いています。ここは大事です。

例は、コネクタの認証です。AI側からは実行できません。認証用のツールを呼んでも、「/mcpを実行させてください」と返ってくるだけ。そこで/setup-connectorsを用意しました。

環境構築は、CLIで完結する範囲を、承認のうえAIが実行します。ブラウザ操作は人です。申請フォームも人です。第三者への依頼も、人に投げます。

この切り分けは、机上で決めませんでした。実際に手を動かして、測り直しています。当初「自動化できる」と書いた項目のいくつかが、実測すると人手が必要だったそうです。

AIが推測で答えないルールも、CLAUDE.mdに書きました。正本が未登録の項目では、「正本が未登録なので受け入れ担当に所在を確認してください」と答えさせます。手順は、推測で埋めさせない。

新メンバーは検証する手段を持たないので、厳しめに縛ったとあります。

繋いでみて分かった限界が、2つあります。1つ目は、長すぎるページです。全社共通のハブページのように十数万文字あるものは、1回のツール呼び出しに収まりません。

2つ目は、取得の失敗をAI自身が判定できないことです。元ページの表が、取得した本文から丸ごと消えることがあるそうです。

まとめの節で、勝野さんは線引きを書いています。認証は人です。手順の要約はAIです。教材の正しさの判断は、人です。

AI氣道『AI社員とは何か。何を渡せば動くのかを経営者向けにまとめる』より

「私の運用でも、正本を渡さずに書かせたメールは、私の文章になりませんでした。整理したアンケートを、AIが開かなかったこともあります。答える問いの数そのものも、詰まりになっていました。送る1回と方向を決める1回は、自分で持ちます。任せる範囲を広げても、人が決める場所は残るんです。」

この線引きを、私は『AI社員とは何か。何を渡せば動くのかを経営者向けにまとめる』で書いています。

勝野さんの線引きと、私の「任せる範囲を広げても人が決める場所は残る」は、同じ向きだと読みました。どこまで任せてよいかは、AIの賢さより、先に人が線を引いたかどうかで決まる。私は、そう思います。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「新卒が来ないので、AIに新規メンバーを演じてもらった」の節

生成されたチェックリストのリンクが44件すべて切れていました。テンプレートは1階層浅い場所にあり、相対パスがそのままコピーされていました。

引用が伝えているのは、作った本人が気づけない不具合が、新人役のAIで表に出た、ということです。リンク切れは44件。すべてです！

勝野さんがリポジトリを作ったとき、肝心の新卒の方は配属されませんでした。作った本人が触っても、まず詰まりません。書いた本人の前提が全部含まれているからです。

そこで、AIエージェントに新規メンバー役を割り当てました。初日のシナリオを、頭から通してもらいます。

観点を変えて、結局6周になりました。最後の1周でも、まだ問題が出てきた。ここがポイントです。

1つ目は、チェックリストの依存関係の矛盾です。番号順に進めると、多要素認証の設定より先に、VPN接続の確認が来ます。VPNの初回設定には、多要素認証が必要です。素直に番号順に進むと、必ず詰みます。

教材を読める人は暗黙に回避するので、レビューは素通りします。

2つ目は、生成されたチェックリストのリンクが、44件すべて切れていたことです。テンプレートは、1階層浅い場所にありました。相対パス（今いる場所からの道順）が、そのままコピーされていたんです。

テンプレートの位置で見る限り、正常に見えます。実際に生成して踏むまで、気づけません。

最後は、外部スクリプトを実行しかねない状態でした。手順には、Driveからスクリプトをダウンロードして実行する段があります。AIが見る文字列は、禁止コマンドのどのパターンにも一致しません。

でも、中身にはsudo rm -rf（管理者権限でファイルを消すコマンド）が13行ありました。

どれも、指示どおりにしか動かない役がいて、はじめて表面化したものだと、勝野さんは書いています。

設計として残った学びの最後には、こうあります。一番のバグ発見器は、その仕組みをはじめて使う人。AIに演じてもらうのは、あくまで代用だった、と。

勝野侑馬さんの記事「オンボーディングをAIエージェントに任せたら、もはや別ゲーだった」の「ついに実戦投入：中途入社の方に1か月使ってもらった」の節

改善提案を書く場所と、それをPRにする道筋さえ用意されていれば、新規メンバーの「分からなかった」がそのまま教材の資産に変わります。

引用が伝えているのは、気づいたことを書ける場所と、それをPRにする道があれば、新メンバーの「分からなかった」が教材の資産に変わる、ということです。

8月に、中途採用の方がこのリポジトリを使いました。約1か月で、オンボーディングが完了しています。日報は、毎営業日コミット（記録として保存）されました。

/feedbackで気づいた点をimprovements.mdにため、PRにする流れです。実際に上がってきた指摘が、紹介されています。1つ目は、権限の確認手順が実態と食い違っていること。

メンバーが入れ子のグループとして登録されていて、自分の名前を探しても見つからないそうです。

2つ目は、理解度チェックが、どの教材にも書かれていないことを問うている、という指摘です。最後は、Confluenceの古い編集形式で作られた表です。Markdown形式で取得すると、丸ごと落ちます。

AIエージェントの伴走ならではの不具合です。取得形式を変えて取り直す手順を、スキル側に足したそうです。

運用して見えた効き方は、4つあります。部が用意するものが、リポジトリ1つで済むこと。進捗が、毎日文章で残ること。実務のツールに、オンボーディングで慣れられること。質問のハードルが下がることです。

設計として残った5つの学びは、次のとおりです。転記した瞬間に腐るので、集約すべきは情報でなく導線。AIの出力品質は、スキルの書き方で決まる。「自動化できる」は、実測しないと嘘になる。

上流と正本は食い違うので、優先を先に決める。一番のバグ発見器は、初めて使う人。

私は、この5つを、引き継ぎ資料を整理するときの確認項目として読みました。AIには、たとえばこう頼めます。

「私の仕事の引き継ぎ資料を整理したい。次の前提で進めて。

①資料の本文はここに写さず、どこにあるかの一覧だけを作る②各資料に、いつ更新されたか（更新日）を一緒に書く③自動でできるかどうか分からない手順は、できるとは書かず、人に確認と書く④分からない所は、分からないと伝えて、誰に聞くかを教えて。

資料は次の場所にある: ○○。」

ただし、AIが返した一覧は、1回は自分の目で元の資料と見比べておきたいところです。勝野さんの記事にも、取得の失敗をAI自身が判定できない、とあります。

勝野さんの記事は、DeNAのデータ分析チームの話です。でも、考え方は会社の規模に関係なく使えます。正本の場所だけ持つこと。AIの出力は、期待する形を先に書くこと。AIにできないことを、先に人が決めておくこと。新人教育で同じ説明を減らすための考え方として、順に振り返ります。

1つ目は、転記した瞬間に腐る、という話でした！勝野さんは、書ける場所を1つに絞れば腐りようがないと書いています。私の「いつの物かを見ておく」とも、同じ向きだと読みました。

2つ目は、出力が揺れたのはモデルの性能ではなく、期待する形を書いていなかったから、という話でした。私の「毎回渡している全体を数える」と並べると、渡す側が先に整える点で重なります。

最後は、線引きです。認証は人。手順の要約はAI。教材の正しさの判断は人。任せる範囲を広げても人が決める場所は残る、という私の言葉とも重なりました！

そして検証です。新人役のAIに6周演じてもらうと、44件のリンク切れまで出ました。それでも勝野さんは、一番のバグ発見器は初めて使う人だと書いています。あなたも、引き継ぎ資料を作ったら、自分以外の誰かか、AIに頭から読ませてみてほしいなと思います。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！