CREチームをAIネイティブにする：Claude Code活用基盤の構築 | スパイダープラス Tech Blog

CREチームEMの宮囿です。
2026年3月に、CREチームにおけるClaude Codeの利用ルール・コンテキストを、専用リポジトリ「cre_helper」にプロジェクトルールとして集約しはじめました。
約2ヶ月でチームへの普及が進んできたので、本記事ではその設計思想と普及プロセスについて書きます。

CREチームの業務と課題

CRE（Customer Reliability Engineering）チームは、サービスの安定稼働と顧客対応を担うチームです。
具体的な業務は以下のようなものです。

障害調査・対応: サーバーログ調査、DB調査、原因特定、顧客報告のための資料準備
問い合わせ対応: サポートからの調査依頼に対して原因と対処を回答
定型運用作業: サービスにおける各種設定変更など、多岐にわたる手順
ナレッジ蓄積: 再発予防のための手順書・仕様書の整備

これらの業務は属人化しやすく、各自の知見により「あの資料はここにあったはず」等で業務を回しているフシがありました。
また、「業務量は多いがドキュメント化は後回し」になりがちで、ナレッジの蓄積と活用のサイクルが十分に回っていませんでした。

アプローチ：AIをチームで育てる

Claude Codeを試し始めて気づいたのは、AIは育て方次第で大きく結果が変わるという点です。
同じ質問でも、各自が個別に積み上げてきたコンテキスト・指示・ノウハウの差で出力品質が変わります。

ここで懸念したのは、この「育て方」自体が新たな属人性を生んでしまうことです。
これまで「業務ノウハウが個人に貼り付いている」という属人化に悩まされてきたのに、AIの使い方というレイヤーでも同じ構造が再生産されてしまい、
各メンバーが自分のClaude Codeを独自に育て続ければ、「○○さんのAIは賢い」「○○さんに頼まないと出てこない」という状況になります。

そこで立てた方針が「AIの育成場所をチームで共有する」でした。Claude Codeに渡すコンテキストやナレッジを個人のものではなくチームの資産として一箇所で育てる。これがcre_helperの出発点です。
リポジトリを作り、Claudeを利用するときはここを使うことをルール化し、CLAUDE.md（AIへのルール定義）・ナレッジ・スキルを全員共通のものを利用することにしました。
誰が使っても同じコンテキストでAIが動き、誰かの教育や工夫を即座にチーム全員で活用できる形です。

# チームメンバー全員がこの手順でAIを起動する
cd ~/repos/cre_helper
claude   # Claude Codeを起動

普及させるまでの過程

フェーズ1：自分が使って効果を実感する

最初の期間は、自分でcre_helperを構築・改善しました。チームに広げる前に、まず自分自身が「これは効く」という感覚を持つことを優先しました。

ここで得た感覚から、cre_helperのREADMEには、こう書いています。

自分が作業者になるのではなく、AIに作業をさせるマネージャーとして動く。

「自分でやった方が早い」と思っても、まずAIに指示を出してみる

AIのアウトプットを確認・補正・承認するのが自分の仕事

AIが出した結果に責任を持つのは人間側

この意識の転換が、AI活用の要であると認識しました。特にベテランメンバーほど「自分でやった方が早い・確実」という判断をしがちです。

フェーズ2：セットアップを自動化し、立ち上げMtgを実施

障壁はセットアップです。今回は機能をフルに使うためにブラウザ版ではなくCLI版のClaude Codeを活用する方針で進めたため、WSL2のインストールを含め、全員にCLI環境一式をセットアップしてもらう必要がありました。
Claude Code自体のインストールは簡単ですが、CLI環境の整備をこれまでやってきていないメンバーにとっては技術的なハードルが高いものでした。
セットアップスクリプト・手順書を用意したうえで、Claudeのスキルとしても /setup を用意し、立ち上げからClaudeと並走できるようにし、更にMtgで全員が確実に利用できる状態を整えました。

フェーズ3：日々の促進

日々の会話で多少うざい程度に「これAI使いました？」「これAI使ったら早くないです？」を言うようにしました。続けた結果、報告時に「AIにも聞いてみたんですが」等の発言が聞けるようになりました。

導入後の変化

2026年3月にcre_helperの構築を始めてから約2ヶ月、リポジトリ内の蓄積量は以下のようになりました。

スキル数: 41種類（.claude/skills/ 配下のディレクトリ数）
ナレッジ数: 70ファイル（knowledge/ 配下の .md ファイル数）
PJトラッキング: 5つの進行中PJを projects/ で管理

特に過去の調査結果が蓄積されることで「同じ調査を繰り返さない」状態に近づいてきた点は実感としてあり、ナレッジが育つにつれ、AIが初回調査から的確な観点を提示できるようになってきました。

また、cre_helperの更新は私一人ではなく、複数のメンバーから日常的に行われています。現在ではすでに私よりコミット数が多いメンバーが複数名いるほどです。あるメンバーが追加したスキルを別のメンバーが使い、別の人が改善する、という「育てる人」と「使う人」が固定されない相互運用が回り始めており、当初狙っていた『AIの育て方を属人化させない』という設計が機能してきている手応えがあります。

学んだこと

ルールより仕組みを作る

「AIを使いましょう」という呼びかけだけでは定着しません。起動コマンドを1つに固定することで、行動を変えずにAIのコンテキストが揃う仕組みを作りました。

この点については、弊社EM本田のリーダーの仕事はAIを『使わせる』ことじゃなかったが示唆的です。チームのAI活用の差は「使ってください」と言うかどうかではなく、リーダー自身がどれだけAIを使い込んで解像度を上げているかで決まる、という指摘です。cre_helperの普及プロセスでも、自分が先に使い倒して効果を実証してから展開したことが結果的に効いていました。

techblog.spiderplus.co.jp

ナレッジは「読みやすさ」より「検索しやすさ」で設計する

人間向けに書かれたドキュメントをそのままAIのナレッジとして使おうとしてもうまくいきません。AIが参照するドキュメントとしての設計が必要です。

完璧を目指さず、動く状態から育てる

最初から完璧なナレッジ・スキルを作ろうとしない。使いながら気づいたことを追記・修正することで、チームの実業務に根ざした基盤が育ちます。

チームに合わせたオンボーディングが重要

セットアップの自動化と、最初の成功体験を用意することが定着の鍵でした。特に「最初の1タスク」を設計することで、メンバーが自分でAIと対話する経験を積めるようにしました。