はじめに
こんにちは。エンジニア採用広報チーム兼LET運営のオブザーバーもやっている岩田です。
みなさんの会社やチームでも、コーディングエージェントの話題は尽きないのではないでしょうか。リブセンスも例外ではなく、さまざまな生成AIを使ったツールを各所で試しているのですが、そのなかで Claude Code は全社で統一して導入しています。
リブセンスは事業部制をとっているため、各事業部での判断でツールを選定し導入していました。過去にも全社でGitHub Copilotを導入などしていましたが、今年は様々な検討の結果、全社一括でClaude Codeを導入することになりました。
事業部をまたいだ情報共有の機会は、日常的に多いわけではありません。「各事業部がどんな使い方をしているか」は、放っておくと各事業部の中に閉じてしまいます。それはもったいない、ということで、全社横断で Claude Code の活用事例を共有する勉強会を開催しました。それに合わせて、全社での導入の経緯についても情報共有をしてもらいました。
勉強会は、社内勉強会 Livesense Engineering Talk（通称:LET）の3月の回として2026年3月26日に開催し、40名近くが参加しました。形式は、まず全社導入の経緯を共有したあと、各事業部（マッハバイト・転職ドラフト・転職会議）のエンジニアが Claude Code の活用事例を10分程度ずつ発表するというものでした。この記事はその勉強会のレポートです。
LETでは、過去にこんな改善も行ってきました。 made.livesense.co.jp
全社での Claude Code 導入について
最初のパートでは、インフラグループの@sheep_san_whiteさんから、全社導入の経緯が共有されました。
もともとは同じインフラグループのかたいなかさんが、前年6月ごろから Claude Code を触り始めたことがきっかけで、8月に全社導入に向けた Design Doc と ADR の作成が本格化しました。11〜12月にかけて Claude Code・Codex CLI・Copilot Agent・Devin などを比較検証し、今年1月から正式導入という流れです。
選定理由は主に2つ。ベンチマーク上の評価が高かったことと、社内の知見がすでに Claude Code 側に集まっていたことです。予算の持ち方も「Claude Code の予算」ではなく「生成 AI 関連の予算」として確保することで、将来的により良いツールに乗り換える際の障壁を下げるようにしています（特定のツールへの依存を最小化するという考え方が、後述の転職ドラフトの発表とも通じていました）。
現在はエンジニアにとどまらず、デザイナーや企画職にも利用が広がっています。
セキュリティ面では、初期は全機能を開放せず段階的に広げていく方針をとっています。今後は OpenTelemetry を使って利用状況を Datadog に転送し、コスト最適化や利用実態の把握に活かしていく予定とのことでした（こちらは勉強会の翌日に計測が開始されました）。
マッハバイトの活用事例
マッハバイトのエンジニアである@ayumu838さんからは、チーム内でスキルを共有する仕組みとして Claude Skill Market が紹介されました。汎用的な Claude Code のスキルをマーケットプレイス形式でチーム全体に共有・再利用できる仕組みです。
運用スタンスとして印象的だったのが、「スキルは自分で作ることが最も効果的。マーケットは初心者や新卒のための参考例として使ってほしい」という言葉です。スキルを配るだけでなく、「自分で作れるようになること」を目標に置いている点が、単なる効率化ツールにとどまらない設計思想を感じました。
日常で実際に使っているスキルの例として、以下が紹介されました。
- 朝のタスク確認: loop コマンドを使い、GitHub 上の「今やるべきこと」（未マージの承認済み PR、レビューリクエストされたものなど）を一覧表示する
- ブランチの準備: デフォルトのブランチへの切り替え＋最新化＋未コミットの変更があればstashへの退避を、一発で行える
- プルリク作成: lint の実行から Draft PR の作成までを自動化する
転職ドラフトの活用事例
転職ドラフトのエンジニアである@EREFYさんからは、Claude Code を使う上での基本的なワークフローと心得が共有されました。
最も印象に残ったのは「いきなり書かせない」という原則です。AI にいきなりコードを書かせると、修正が的外れになりやすい。そうならないために、情報探索 → 計画策定 → 実装という順序を守ることが重要とのことでした。これはシニアエンジニアが自然にやっていることをそのまま AI のワークフローに落とし込んだ形で、「当たり前のことを当たり前にやらせる」難しさとも言えます。
大きな実装をさせる場合は、コンテキストを維持させるためにテストを先に書かせてから実装させる TDD 的なアプローチが有効だという話もありました。
もう1つのポイントが「AIはコンテキストが全て」という考え方です。AI に渡す前提情報を整理することは、ツールを乗り換える際にも資産として残ります。裏を返せば、ツールへの過度な作り込みやカスタマイズは避けるべきで、「作り込んだものがすぐに古くなるか、本体の変更で保守が大変になる」というリスクも指摘されていました。
転職会議の活用事例
転職会議のエンジニアである落合さんからは、転職会議のチームで整備している CLAUDE.md と Rules の構成が共有されました。
CLAUDE.md は Claude Code のセッション開始時に毎回読み込まれる基本指示ファイルです。500行以下、実質的には100〜300行程度に収めるのが望ましいとされています（長すぎると読み込みコストが上がり、指示が希薄になる）。
Rules は特定のファイルやディレクトリに対して個別の指示を設定できる機能で、CLAUDE.md に集中しがちな記述を分散させることができます。これにより CLAUDE.md をスリムに保ちつつ、より具体的な指示が出せるようになります。
CLAUDE.md の構成要素としては、コア原則・ワークフロー設計・ツール利用に関するカスタム指示などが含まれており、Claude Code の開発者である Boris Cherny 氏の知見をベースに作成されているとのことでした。Rules については Ruby on Rails と TypeScript 向けのベストプラクティスが共有されており、awesome-copilot のリポジトリをベースにしつつ、リブセンス特有の環境（Interactor、RSpec など）に合わせてカスタマイズしています。
今後は Anthropic ハッカソン優勝者の設定集として知られる「Everything Claude Code」を参考にしたり、Anthropic 公式の CLAUDE.md 改善プラグインを使った定期的な見直しを進めていく予定とのことでした。
まとめ
今回の勉強会を通じて感じたのは、各事業部が自分たちの文脈に合わせて、Claude Code の使い方を継続的に育てているということです。スキルの共有の仕組みを作る、ワークフローの原則を言語化する、CLAUDE.md と Rules を丁寧に整備する。それぞれのアプローチは違えど、「導入して終わり」にせず使いこなすための工夫を積み重ねていました。
また、「ツールへの依存を最小化する」「コンテキストを資産として整える」といった考え方が、複数の発表に共通して現れていたのも印象的でした。ツールは変わっても、その考え方は残る。結局、Claude Code を使いこなすことよりも、「どう使うか」を言語化することの方が長く効いてくるのかもしれません。
