「君らはAIネイティブ世代だから」と背中を押された新卒が、AIモブプロでチームのAI活用の促進に取り組んだ話

この記事は、freee Developers Advent Calendar 2025 の 11日目の記事です。

はじめに

こんにちは！freee人事労務アウトソースのチームでエンジニアをしている25卒のatoringoです！

みなさんのチームでは、生成AIを開発にどれくらい活用できていますか？日々、試行錯誤されていると思います。

私の所属するチームは事業統合で弊社にジョインしたプロダクトで、技術スタックや開発フローなどで弊社の標準と違う箇所が多く、AI活用は進んでいるとは言えない状況でした。

今日は、配属直後の私が「AIモブプロ会」を主催し、そこから「週2時間のAI探索タイム」という制度が導入されるまでの、ちょっとした過程を書きたいと思います。

「突き上げる気持ちでやってくれ」

配属前の研修期間のこと、会社の上層部の方から、私たち新人に向けてこんな言葉をかけられました。

「君たちはAIネイティブな初めての世代。AI活用については一番習熟が早いはずだから、下から突き上げる気持ちでやっていってくれ」

そうか、会社は私たちにこういうことを期待しているんだ、何かチャンスがあれば動いてみようという気持ちで配属されました。

AIモブプロのきっかけになったDevContainer × MCP Server 問題

配属されたチームは、AI活用という点では「個々人がCline（VS Code拡張）でちょっと活用する程度」に留まっていました。

その大きな要因が「DevContainer環境におけるMCP Server導入の複雑さ」です。弊社では全社的に許可された社内用MCP Serverを簡単に使えるCLIツールが整備されていますが、これをDevContainer環境に組み込むには、認証・永続化という2つの壁を越える必要がありました。

私たちは「環境構築会」を実施し、全員でエラー画面を共有しながら、最終的に以下の構成で解決しました。これからDevContainerでMCPを試す方の参考になれば幸いです。

なぜ、そこまでしてDevContainer環境での動作にこだわったのか？

その理由は、この社内用MCP Serverが「社内の独自知識と開発コンテキストへのゲートウェイ」だからです。これを導入することで、ClineなどのAIエージェントは以下のリソースへ直接アクセス可能になります。

社内ドキュメント & UIコンポーネント: 独自のDesign Systemの仕様や、社内Wikiにある技術仕様を参照してコードを書く。
Jira & GitHub: 実装すべきチケットの要件詳細や、関連する過去のPRでの議論を「文脈」として読み込む。

単に一般的なコードを書かせるのではなく、「プロジェクトの文脈と、freee標準の仕様に基づいたコーディング」を実現するためには、壁を越えてでも、この環境を整える必要不可欠でした。

認証とインストールの自動化

社内配布のCLIツールはPrivateリポジトリにあるため、単なるcurlでは取得できません。ホスト側のGitHubトークンをコンテナ内に安全に引き継ぐ必要がありました。

.devcontainer/devcontainer.json にて、ローカルの環境変数をコンテナ内に注入し、features でGitHub CLIを導入することで、initialize.sh 内での認証付きダウンロードを実現しました。

// .devcontainer/devcontainer.json
{
  "features": {
    // 認証付きダウンロードのために導入
    "ghcr.io/devcontainers/features/github-cli:1": {},
    // MCP ServerがDockerを操作する場合に必要
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}
  },
  "containerEnv": {
    // ローカルのトークン変数をコンテナ内の環境変数として渡す
    "GH_TOKEN": "${localEnv:GITHUB_TOKEN_FOR_MCP}" 
  },
  // コンテナ作成後にセットアップスクリプトを実行
  "postCreateCommand": "/bin/bash .devcontainer/initialize.sh",
  "mounts": [
    // 認証情報の永続化
    "source=${localEnv:HOME}/.password-store,target=/home/vscode/.password-store,type=bind,consistency=cached",
    // MCP設定の永続化
    "source=${localEnv:HOME}/.config/mcp-server,target=/home/vscode/.config/mcp-server,type=bind,consistency=cached",
    // (参考) Claude Code等の設定も同様に同期して、コンテナ内での認証状態を維持しています
    "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached"
  ]
}

# .devcontainer/initialize.sh

# 必要なツールのインストール (sudo, pass)
if [ -z "$(which sudo)" ]; then
    apt-get update && apt-get install -y sudo
fi
sudo apt-get update && sudo apt-get install -y pass

# 注入されたGH_TOKENを使って社内リポジトリからバイナリを取得
echo "install internal-mcp-server..."
# OS/ARCHの判定ロジックは省略
gh release download -p "*${OS}_${ARCH}" -R mcp-server -O /tmp/mcp-server
chmod +x /tmp/mcp-server
sudo mv /tmp/mcp-server /usr/local/bin/mcp-server

設定と認証情報の永続化

MCP Serverの設定ファイルや、認証に使う pass (password store) のデータが、コンテナをRebuildするたびに消えてしまっては使い物になりません。これらは mounts を使ってホスト側のディレクトリをマウントすることで解決しました。

// .devcontainer/devcontainer.json
"mounts": [
  // 認証情報の永続化
  "source=${localEnv:HOME}/.password-store,target=/home/vscode/.password-store,type=bind,consistency=cached",
  // MCP設定の永続化
  "source=${localEnv:HOME}/.config/internal-mcp-server,target=/home/vscode/.config/internal-mcp-server,type=bind,consistency=cached"
]

こうして、「ひとりじゃめんどくさい作業」もモブプロ形式で一気に解決し、チーム全員が同じスタートラインに立つことができました。

AIモブプロ、爆誕

環境が整ったら、次はこういう場面で使えるぞ！という「成功体験」が必要だと考え、「AIモブプロ会」を企画しました。やり方はシンプルで、一人の画面をみんなで見ながら、できるだけAIに任せて開発を進めるというものです。

私の準備不足でスムーズに進まない場面もありましたが、この会を開いたことで、AI使ったらこんなふうに開発できるぞというチームの共通感覚を養うことができたのかなと思っています。

面白かったのは、AIのコード生成そのものよりも、AIがコードを書いている横で、AIとは関係ない開発ツールのtipsなども共有されることがあり、AIに限らずモブプロは学びが多いなと感じました。

AIモブプロを触媒にして、チーム内のドメイン知識や技術についての会話が（ちょっと）活性化していくという副産物もありました。普段の会話でも「次はこれをAIでやりたいね」「これAIでできないの辛いなぁ」といった声が聞こえるようになり、チームの空気が変わってきたように思います。

活用の停滞と、マネージャーへの相談

一定の成果があったAIモブプロですが、しばらくすると活用の停滞という「壁」にぶつかりました。

みんながAI活用に慣れてきたことで、モブプロの中で「新しい発見」が少なくなってきました。「まあ、AIならこれくらいできるよね」という想定の範囲内に収まるようになってきたためです。

「そろそろ効果が薄れてきている気がする…」

マネージャーとの1on1で、AIモブプロの立ち位置などについて相談しました。

その時感じていた課題は、週に30分という時間だと小さく試せることしかできず、より時間をかけた調査が必要な、大きく開発フローを変えるようなことに、取り組めていないということでした。

マネージャー側としても、よりAI活用が進むように何かしていきたいという思いがあり、全員が「週2時間のAI活用探索」を確保し、今までAIモブプロを行なっていた時間で、その成果を報告する案が出ました。

こうして、私たちのチームに新しい制度が生まれました。

週に2時間、スプリントタスクとして「AI活用の探索」を行う
従来のモブプロ枠は、探索結果の「発表・共有会」にする

業務の合間では試せなかった「重ための検証」ができるようになったことで、ツールのポテンシャルを最大限に引き出せるようになりました。

例えば、毎週のように新しいClaude Codeの「スラッシュコマンド」が登場します。テストの実装コマンドや、リンターの指摘を修正するコマンドなどです。

そんな中の成果の1つが、「Devin × Jira によるタスク消化の完全自動化」です。

これまでDevinは「リポジトリ横断の調査」くらいにしか使えていなかったのですが、探索タイムを使ってJira連携の設定や挙動を深掘りした結果、「Jiraでチケットをアサインするだけで、Devinが勝手に実装を始め、PR作成まで完了させる」というワークフローが確立できました。

Jiraでタスクを作成し、Devinにアサインする
Devinがチケットの内容を読み取り、コードを修正
テストを通し、GitHubでPRを作成して報告

これらは複雑なスクリプトを書いたわけではなく、DevinとJira連携機能をキャッチアップし、運用に乗せただけです。しかし、忙しい日常業務の中では「なんかJiraからDevin呼び出せそうやけど、設定が面倒そうだし後回し」になりがちな部分でした。ここを突破できたのが探索タイムの大きな功績です。

「Claude Code」などのツールも優秀ですが、エンジニアが対話しながら進める必要があります。対してこのワークフローの良さは、圧倒的な「手離れの良さ」です。小さなバグ修正やQA対応などをJira上でDevinに投げておけば、自分は別の設計作業に集中できる。「頭のリソースを奪われない」というのは、開発体験として良いものでした。