新入社員エンジニアのオンボーディングは AI で

みなさまこんにちは、IVRy で AI プロダクトの開発をしている井口 貝（いのくち かい; @kainoku）と申します。
本記事は、IVRy Advent Calendar 2025「IVRy AIブログリレー Part2」の三日目の記事です。

私は 2025 年 10 月 1 日に IVRy に入社し、本稿執筆時点で二ヶ月ほど Software Engineer として在籍しています。この記事では、新入社員エンジニアであった私がどうやって AI を活用して自身をオンボーディングしていったかをお話しします。

これから新入社員として入社を控えるエンジニアさんや、新入社員を迎えるチームの参考になれば幸いです。

三行まとめ

• オンボーディングされる側の新入社員は、AI に社内情報を把握させて教えてもらう方法や、AI の Context Window をどのように効率的に使うかを意識すると良さそうです

• オンボーディングする受け入れチーム側は、新入社員に必要な情報（コードベース、過去の意思決定など）を AI が読みやすいように整えると、AI に支援された新入社員の立ち上がりがスムーズになりそうです

• AI には出来ないことをチームメイトと議論するために、AI をうまく使って良いオンボーディングにしましょう！

知らない用語を AI で調べよう

新入社員としてなんといってもまず大変なのが、周囲の議論についていけないということではないでしょうか。「入社早々バリューを出してやろう！」と意気込む我々新入社員の耳に飛び込んでくる数々の聞きなれない用語、英語三文字、略語。転職を機に新しいドメイン・業界に飛び込んだ新入社員にとっては、さらにそれが社内用語なのか一般用語なのかわからないことが最初の難関となります。

ニュースアプリ業界から一転、対話型音声 AI SaaS を作っている会社に入った私も同様でした。最初このような会話を耳にした時、自分は「ああ、AI にセリフを読ませて音声合成することを言っているのかな？」と思いました。

多くの新入社員にとって、周りのメンター・チームメイトの方々はとても忙しく見えます。周りが優しく「なんでも訊いてね」と言ってくれても「こんなことでいちいち声をかけて良いのかな」「まずは自分で調べるべきだろうか」という思いが心をよぎるのではないでしょうか。こんなとき、IVRy では Notion AI が非常に役に立ちました。

"あふれこ" は、私が当初想定していた "アフレコ" ではなく "あふれ呼" を指しており、コールセンターなど電話業界で用いられる一般用語かつ、IVRy でも対応している機能名称であることがわかりました。メンターの人に声優さんの話を急に持ち出さなくて済んだのは Notion AI のおかげです。

特に社内で特有の文脈や使い方がある言葉は、インターネット検索だけではなく、社内情報に接続された AI による文脈を加味した解説が有用でした。

上記のスクリーンショットからもわかるように、IVRy の Notion AI は Notion（ストック型のドキュメント）に加え、Slack（フロー型の会話）、Linear（タスク管理）、Google Drive（プレゼン資料や表計算資料）、そして GitHub（コードベース）などに接続されており、パブリックになっているあらゆる情報源を探してくれます。IVRy は人事や報酬にまつわる以外のほとんどの情報をパブリックにすることが強く推奨されており、AI 利用時にもその恩恵を受けることができます。

💡 新入社員を迎えるチームの方へ

• 新入社員が何でも訊きやすい雰囲気を醸成するの加えて、社内の情報のパブリック化と、それを接続した AI の整備が大切なように感じています。特に、情報源となるデータが局所化・最新化出来ていると、AI が効率的に回答を生成することができます。Notion AI はあくまで一例で、Gemini や Slack の AI 機能でも同様のことが実現できるでしょう。

• AI にとって効率的に読みやすいフォーマット（Markdown など）の文章が充実していることが重要だと思います。

コードベースを AI と一緒に読んでみよう

エンジニアとして入社したからには、入社からさっそくバリバリとコードを書いて変更をデプロイしたいですよね。そして、そのためには我々はなるべく早く既存のコードベースを完全理解したいことと思います。

Agentic Coding 隆盛の昨今ですが、ご存知の通り AI Agent はコードを書くのと同じぐらい読むのが得意です。 この章では、IVRy の新入社員である私がどのように AI にコードを読ませ "Agentic Code Reading" をやってきたかをご紹介させていただければと思います。

コードベースのエントリーポイントと主要リポジトリ一覧を手に入れよう

まずは、我々新入社員が取り組むプロダクト・機能の最も主要な処理のエントリーポイントの情報をチームメイトやオンボーディング用文章から手に入れましょう。「このリポジトリのこのメソッド」レベルの情報で大丈夫です。さらに、大まかな全体アーキテクチャ図と、それぞれに対応するリポジトリの一覧が入手出来れば下準備はバッチリです。

IVRy では、ハイレベル（大まかな、細かくない粒度）のアーキテクチャ図が採用ページ（IVRy｜プロダクト開発 採用ページ）に、Organization 配下の .github-private リポジトリの profile/README.md にリポジトリ一覧がそれぞれ存在するので下準備は本当に一瞬でした。

それぞれの情報は本当にハイレベルでよく、根気よくメンテされていなくても大丈夫です。AI Agent の取っ掛かりとなりさえすれば、その正誤も含めてかなりしっかりと読んでくれます。

💡 新入社員を迎えるチームの方へ

システム全体のドキュメンテーションやアーキテクチャ図を実際のコードベースの変更に追随させるのは大変ですよね。自分も前職ではついぞこの取り組みを成功させることがありませんでした。「最新のアーキテクチャ図ありますか？」と内外から訊かれてよく口ごもっていました。

AI 時代には、上記のようにハイレベルな図を用意しておくだけでも十分そうです。粒度をやや粗めにしておくと変更頻度も抑えられますし、なにより簡単に作れます。主要処理のエントリーポイント、主要リポジトリ一覧、そしてアーキテクチャ図があればあとは AI と新入社員が生き生きと動き出すはずです。また、後述するように、このあたりの情報も AI で継続的にメンテすることが出来ます。

メインの処理をリポジトリ横断で AI に読ませよう

さて、下準備が整ったので、早速 AI Agent にコードを読ませていきましょう。多くの場合、我々が扱うシステムには複数機能があり、単一のリポジトリで要件が完結しません。そのため、先程手に入れた主要リポジトリ一覧のすべてを AI Agent が読めるように整えましょう。

私はあるディレクトリをコードリーディングのための git project として git init しました。その配下に repositories/ ディレクトリを作り、そこの配下に主要リポジトリをすべて git submodule として登録してみました。色々とブランチを切り替えられると便利なのでこうしましたが、他に clone したリポジトリのシンボリックリンクを貼るのもシンプルで良さそうです。

ここまできたらおもむろにお気に入りの AI Agent を立ち上げ、さっそく以下のように質問するだけです。私は Claude Code を愛用していますが、以下内容は Codex、Gemini CLI、Cursor、Devin Search などを利用しても同様のことが出来ると思います。

ご存知の通り、お使いの AI Agent への指示ファイル（ここでは CLAUDE.md）に以下項目を設定しておくと AI Agent がより効率良く作業できます。

• ゴール（例: 新入社員のコードベース理解促進）

• どこに何があるのか（例: リポジトリ一覧、他重要文章へのリンク）

• 重要な注意事項（例: 推測を避けコードベースのみから返答すること）

また、Language Server Protocol（LSP）の力を使って semantic code analysis を行う Serena などの MCP を組み込むとより精度が上がるケースがあります。

プロンプト一発でも Opus 4.5（と Serena）ではこんなものを出してくれます（今回は概要レベルを指定）

💡 新入社員を迎えるチームの方へ

• 各リポジトリの README.md や CLAUDE.md が整備されていると、 AI にとって非常に読みやすくコードリーディングの効率性がとてもあがります。また、あるドメインに対するコードがなるべく少ない数のリポジトリ、極端なケースではドメインごとのモノリポに入っていると AI にとって非常に読みやすいリポジトリになる気がします。

• AI は書かれていることに良くも悪くも引っ張られます。レガシー・未使用な実装や不正確なコメントが入っているだけでミスリードされて不正確な文章を出力する可能性が高まります。日頃からリポジトリ内容を最新に保つことが、人間だけでなく AI にも優しい環境を生み出します。

読ませた結果を文章化しよう

さて、出力した内容はどれも新入社員にとってシステム理解に大切なものでしょう。ぱっと読んで内容がすべて頭に入る量でないことも多いので、ぜひ出力した内容は文章化するようにしましょう。

私はコードリーディングプロジェクトの配下に docs/ を作り、そこに文章を出力させるようにしています。これにより、時間を取ってじっくりと読める文章が生成されます。渡されたオンボーディング向けドキュメントを読み切ってしまった新入社員の方は、このように自分で読むべき文章を作っていってはどうでしょうか。

これらの文章群はある種の知識データベースとなり、今後あなたがコードを書く際に AI に質問する場合にも利用できます。

また、このようにテーマごとに知識を文章化しておくと、AI Agent の Context Window を節約できます。一度獲得した知識を形式知として外出ししておけば、必要に応じてその文章を読み込むだけで済み、現在の Context Window は /clear しておけます。その結果、AI Agent の性能劣化をなるべく抑えることができます。

文章をたまに更新しよう

積年の課題である「コードと文章の乖離」に対して、私は定期的に submodules とそれに対応する文章を更新するようにしています。Claude Code で一気に実行できるよう Slash Commands という形にしています。また、これは各リポジトリの README.md・CLAUDE.md 更新にも使えるパターンだと思います。

.claude/commands/update-submodules-docs.md に以下の仕込みをしておくことで、Claude Code 上で Slash Command "/update-submodules-docs" を呼び出してコードと文章を一括で更新することができます。

---
allowed-tools: Bash(cd:*), Bash(git:*), Bash(uvx:*)
description: "Submodule をすべて更新し、対応する文章を必要に応じて更新します"
---

このコマンドでは、git submodule を更新し、コード変更に対応する docs/ 配下の文章を必要に応じて更新します。

# 1. 各 submodule をすべて更新

`git submodule update --init --recursive --remote` を実行

# 2. 各 submodule の serena index 更新

以下の 3 つの submodule に対して順次 index 更新を実行：

```bash
# example1
cd repositories/example1 && uvx --from git+https://github.com/oraios/serena serena project index

# example2
cd ../example2 && uvx --from git+https://github.com/oraios/serena serena project index

# example3
cd ../example3 && uvx --from git+https://github.com/oraios/serena serena project index
```

# 3. 差分確認とドキュメント更新判断
各 submodule の最近のコミットを確認し、重要な変更について docs/ 配下のドキュメント更新の必要性を検討:

```bash
# 各 submodule の最近のコミットログを確認
cd repositories/example1 && git log --oneline -10
cd ../example2 && git log --oneline -10
cd ../example3 && git log --oneline -10
```

**ドキュメント更新が必要な変更の例**:
- 新しいシステム機能の追加（例: 新しい rule_type の追加）
- アーキテクチャの大幅な変更（例: 新しいマイクロサービスの追加）
- 重要な設定構造の変更（例: DynamoDB スキーマの変更）
- ローカル環境構築手順に影響する変更（例: 新しい環境変数の追加）

**ドキュメント更新が不要な変更の例**:
- 実装の詳細レベルの変更（例: ライブラリの移行）
- バグ修正
- リファクタリング
- 依存関係の更新
- 削除されたリソース

ループを回して AI Agent を鍛えよう

AI Agent は（いまのところ）絶対に気を悪くしないので、 彼らの出力には気兼ね無くダメ出ししましょう。

残念ながら、最初の出力には多くの場合エラーが含まれます。一般に多くのコードベースを読みながら文章の出力が行われるので、頑張って token を節約して Context Window に余裕を持たせようとしてもどこかで Compaction などが起こり、情報の精度が劣化したまま出力されてしまうためです。そのため、何かおかしいな？と思ったら鋭い質問をバンバンと打ち込むと良いと思います。

そもそも新入社員で何が正しいかわからない場合でも、以下のように、こちらがチームメイトから言われたらドキッとするようなことを質問すると、結構な頻度で誤りが見つかります。

• それではこのケース（エッジケースや複雑なパターン）の時の処理はどうなりますか？深く分析してください。文章の内容に不整合がある場合は必要に応じて修正してください。

• （他のドキュメントを @ などで参照しつつ）この文章との整合性を確認してください。不整合がある場合はコードベースを再度参照して必要に応じて修正してください。

また、シンプルに「シニアなバックエンド（または AI やフロントエンド）エンジニアとして、今作成された文章とコードベースを詳細に比較し、コードベースを正として整合性を深く分析してください」などとお願いすることもとても有効です。レビュー専用の subagent を設定しても良さそうです。

このようにしてエラーを集めた後は、「なぜこのエラーが発生したのか」「直接原因と根本原因は何か」と Incident Postmortem さながら追求しましょう。

最後には「アクショナブルな再発防止策を CLAUDE.md（または他の AI Agent 指示ファイル）に保存してください」とお願いすると、その結果が永続化され、セッションをまたいで利用できる資産となります。

フィードバックループを繰り返していくと CLAUDE.md が肥大化し、Context Window が圧迫されたり Lost in the Middle により指示がスキップされたりする場合があります。この内容自体を定期的に内省させ、本質的な指示だけをキープさせるようにすると良さそうです。

コードを書いてみよう

ここまでは AI Agent に文章を書かせる "Agentic Code Reading" の話をしてきましたが、花形である Agentic Coding についても簡単に触れておきましょう。

Design Doc

IVRy では中規模以上の開発をする場合、Design Doc（技術設計書）を書いて方針をチームで合意してから実装して GitHub へ Pull Request を出すケースが多いです。Design Doc の書き方はここでは詳細について触れませんが、背景・ゴール・実装方針・考慮したが採用しなかった方針などが記載された文章で、IVRy ではそのツールとして Notion を利用しています。

上述したコードリーディング文章群を読み込ませながら、AI Agent に Design Doc の下書きをさせるのも便利です。色々な実装パターンと Pros/Cons を出させることで、開発の要件やチームの状況・プラクティスにあった解法を、チームレビューに回す前に一通り議論することが出来ます。

実装

Design Doc がチームレビューを通過したらいよいよ実装です。AI Agent に対して Design Doc に従ってコードを書くよう指示すると、合意した設計と乖離しない実装が出力されるケースが多いです。その際、効率的に Design Doc を読み込ませるため Notion MCP を使ったりすることも有効です。

💡 新入社員を迎えるチームの方へ

• チームに Design Doc の文化が根付いていると、人間だけではなく AI も過去の技術的意思決定を参照してアンチパターンを回避できたり、類似解法を簡単に見つけることができたりして効率が良いです。

• Design Doc のフォーマットが統一され（ドメインごとに、または全体として）同じ場所に保存されていると AI にとっても見つけやすく読みやすいです。また、AI の実装オプションを飛躍させすぎないため、制約ダウンサイドなどについても記載するフォーマットにしておくと良さそうです。

レビュー

IVRy では多くの会社と同様に、GitHub を使って Pull Request をレビューします。レビューについては本稿で触れることは多くないのですが、GitHub CLI (gh) をインストールしておくと、AI Agent がそれを使って GitHub 上のコメントに対して対応する実装をしてくれ便利です。

指摘内容がハイコンテキストで新入社員にとって理解が難しい場合も、これまでに作成してきた docs/ 配下の内容などを踏まえて意味を教えてくれます。

チームメイトに話を聞こう

最初にとっかかりとなる情報を教えてもらった以降、この文章ではチームメイトがほとんど登場していませんでした。私は AI とだけ会話をしていたように見えたかも知れませんが、実はそんな事はありません。

オンボーディングの最も大事なパートは、やはり先輩たるチームメイトたちとの会話です。AI のおかげで上記のように、「これはなに？」（What）をチームメイトに訊くことは減ったかもしれません。それで浮いた時間をチームメイトと話すことに充てると、とても良いオンボーディングとなるのではないでしょうか。

その際は、「What を統合するとこういう風になっていそうだが、なぜこうしていないの？」や「これが今の設計になっている理由はなんだろう？」など、Why を中心に話すことをおすすめします。歴史的経緯、チームのカルチャー、システム全体を貫く設計思想などは What に比べるとコードベースに直接表現されることが相対的に少ないのですが、今後システムを作っていくときに非常に重要となるインプットだからです。

AI がコードベースだけを読んでいると、生成される文章やコードからもこの視点が抜け落ちてしまうことが多いです。チームメイトと Why にまつわる会話を重点的に行い、その知見を AI へフィードバックするループを回せれば、AI Agent はオンボーディング後も引き続き、我々新入社員の非常に頼もしい相棒になってくれるでしょう。

💡 新入社員を迎えるチームの方へ

• システムに関する Why を話す場、出来ればカジュアルな場が意図的に設計されていると、What を把握した新入社員も議論に加われそうです

• AI との対話が中心になっている新入社員がいたら、ぜひ声をかけてあげると良さそうです

まとめ

これまで書いてきたことをまとめると、それぞれの登場人物（と AI）が以下を頑張るとオンボーディングがスムーズに行きそうな気がします。

• 新入社員側: AI にいかに情報を把握してもらうか・どのように効率的に Context Window を使うか、AI ではわからない情報をどうやってチームメイトから吸い上げるか

• 受け入れチーム側: 新入社員が AI に読ませる情報をいかに整えるか、コードベースに存在しない情報をいかに新入社員と共有するか

ちなみに IVRy では受け入れチーム側が強力で、上記がほぼ全て整っていました。その結果、AI 対話システムを電話無しでシミュレートする簡単な end-to-end（Frontend, Backend, LLM, Infrastructure）の Web アプリケーションを、AI Agent およびチームメイトの支援のもと入社二週間程度で作ることが出来ました。

また、上記受け入れチーム側の取り組みは DORA State of AI-assisted Software Development 2025 でも重要とされている「AI の力をより解き放つため組織が持つべき 7 つの能力（DORA AI Capabilities Model）」のうち、以下の 2 つにバッチリ当てはまりそうです。

• Healthy data ecosystems（内部データ全体の品質が高いこと）

• AI-accessible internal data（AI がアクセス可能な内部データが整備されていること）

そして最後に、やはりオンボーディングの肝はチームメイトとの密度が高い会話です。この密度を上げる・この時間を作るために、新入社員のみなさまに AI を活用していただければと思います。

この記事を読んで「IVRy でエンジニアリングをすることについて気になる、もう少し知りたい」と思ってくださった方がいらっしゃったら、ぜひお話ししましょう！

また、私とのカジュアル面談以外でも、以下のリンクからいろいろな形で IVRy とつながっていただければ嬉しいです。

• キャリア登録

  • 「今すぐ転職を考えているわけではないけれど情報収集はしたい」「IVRyがどんな会社かもう少し知りたい」という方向け

• IVRy｜プロダクト開発 採用ページ

  • エンジニアリングに関わる公開資料や募集職種一覧はこちらから