+++
title = "採用したAIエンジニアの最初の1週間：オンボーディングの設計"
date = 2026-06-08
description = "AIエンジニアを採用した後、最初の1週間でやってもらうことと、初期の期待値設定の方法"
[taxonomies]
tags = ["HR×AI", "AIエンジニア", "オンボーディング", "採用後", "エンジニア採用"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "オンボーディングは新人を会社に慣らす期間ではない。採用判断が正しかったかを低リスクで確かめられる、最後の1週間だ。"

[[extra.faqs]]
question = "AIエンジニアのオンボーディング最初の1週間で何をやってもらうのが効果的ですか？"
answer = "2つが有効です。①開発環境のセットアップを自力でやってもらう（どこで詰まるか・詰まった時どうするか・ドキュメント改善提案を自発的にするかが見える）。②既存コードを読んで自分の言葉で説明してもらう（AIツールを使って読んでいい。コードの理解より「どう理解を進めるか」のプロセスを見る）。1週間でプロダクションに機能を出すことは求めないことが重要です。"

[[extra.faqs]]
question = "AIエンジニアの入社後ミスマッチを防ぐために最初の1週間で何を伝えるべきですか？"
answer = "3点を言語化して伝えます。①最初の3ヶ月でやってほしいことを3つ（採用時に言語化したもの）。②どの程度の独立度で動いてほしいか（毎日確認なのか週1確認でいいのか）。③間違いや詰まりをどう報告してほしいか（黙って抱えるか・すぐ相談するかを組織として決める）。これらを明示しないと「期待していたこととやっていることが違う」という3ヶ月後の退職につながります。"

[[extra.faqs]]
question = "AIエンジニアのオンボーディングで手取り足取りのウォークスルーをしてはいけない理由は何ですか？"
answer = "1日目からメンターが全部説明すると「ひとりで動けるか」が1週間では見えなくなります。採用前の評価で見えなかったことが最初の1週間で見えてくることが多く、自力で環境を構築するプロセスを観察することで採用判断の検証にもなります。プロダクションコードに触れる前の低リスクな段階で独立性を確認することが、長期的な活躍予測につながります。"

[[extra.faqs]]
question = "AIエンジニアのオンボーディング1週間後に確認すべきことは何ですか？"
answer = "「入社前に期待していたことと、入ってみて感じるギャップはあるか」を率直に聞きます。これは新入社員の満足度確認だけでなく、「採用プロセスで伝えたことが正しく伝わっていたか」の確認でもあります。ギャップを早期に発見することで修正できますが、放置すると3ヶ月後に「思っていた仕事と違う」という退職に繋がります。特にAIエンジニアは需要が高く、早期退職のコストが大きいため初週のチェックインは重要です。"
+++

優秀なAIエンジニアが3ヶ月で静かに去るとき、引き金はたいてい本人のスキルでも報酬でもない。最初の5日間で「何を任され、何を任されなかったか」が、すでに答えを出していた。

顧問として入社直後のすれ違いを何度も見てきたが、原因はほぼ初週にある。オンボーディングを「新人を会社に慣らす期間」だと思っているうちは、ここは設計できない。最初の1週間は、採用前の評価では見えなかったものが表に出てきて、採用判断が正しかったかを低リスクで確かめられる、最後のチャンスだ。

---

## 最初の1週間でやること・やらないこと

### やること

**開発環境のセットアップを自力でやってもらう**：環境構築手順書があれば渡す。なければ「READMEだけを頼りに環境を構築してください」という課題にする。

分かったこと：
- どこで詰まったか（ドキュメントの品質の問題か、理解の問題か）
- 詰まった時にどうしたか（自分で調べるか、すぐ聞くか）
- ドキュメントの改善提案を自発的にするか

**既存コードを読んで説明してもらう**：「このコードを読んで、次のミーティングで自分の言葉で説明してください」という課題を出す。

コードの量は「1〜2時間で読める範囲」で十分。AIを相棒として使ってほしい（むしろ、使わない方が不自然だ）。見たいのは「コードを正しく理解したか」ではなく、「相棒とどう組んで、未知のコードに分け入っていくか」だ。AIに丸投げした答えを読み上げるのか、AIの出力を疑って自分で裏を取るのか——その差に、その人の仕事のしかたが出る。

### やらないこと

**1週間でプロダクションに機能を出すことを求めない**：コンテキストがない状態でプロダクションに出すことを求めると、リスクを理解せずに動くか、動きが止まるかのどちらかになる。

**手取り足取りのウォークスルーをしない**：セコンドは選手の代わりに殴らない。1日目からメンターが全部説明してしまうと、その人がひとりで立てるかが1週間では見えなくなる。渡すのは答えではなく、READMEと現物のコードだ。横にはいる。代わりに進めはしない。

---

## 初期の期待値を話す

採用後のミスマッチで多いのは「期待していたこととやっていることが違う」という状態だ。これは能力の問題ではなく、ほぼ言語化の不足から起きる。

月曜から動ける具体として、初日までに次の3つを1枚にまとめ、本人に渡す：
- **最初の3ヶ月でやってほしいことを3つ書く**：採用の時点で言語化したもの（言語化できていなければ、本人を迎える前に言語化する。書けないなら、何を採ったのかが自分でも曖昧だということだ）
- **どの程度の独立度で動いてほしいかを書く**：毎日確認してほしいのか、週1確認でいいのか。本人に「自分で進めていい」と思わせる線を、こちらから引く
- **間違いや詰まりをどう報告してほしいかを書く**：黙って抱えるのか、すぐ相談するのか。これは性格ではなく、組織として先に決めて渡すルールだ

---

## 1週間後に確認すること

1週間後に「入社前に期待していたことと、入ってみて感じるギャップはあるか」を聞く。

ギャップは、初週なら一言で直せる。放置すれば、3ヶ月後に「思っていた仕事と違う」という退職に化ける。AIエンジニアは引く手が多く、辞められたときの穴も埋め直しのコストも大きい。だからこそ、安いうちに直す。

このチェックインは「新入社員の満足度確認」ではない。「採用プロセスで伝えたことが、本当に伝わっていたか」を確かめる、採用側の答え合わせだ。初週は、相手を試す週ではなく、自分たちの設計を試す週でもある。

---

## 関連記事

- [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 採用後に力が発揮されない組織的な原因と対処法
- [AIスタートアップで非エンジニア職を採用する方法](/n/ai-startup-engineer-hiring-criteria/) — AI企業全体のオンボーディング設計に関わる視点
- [AI採用でカルチャーフィットを評価できない理由](/n/ai-hiring-culture-fit-limits/) — 入社後に表れるカルチャー適合の判断ポイント