はじめに こんにちは。人材紹介開発グループでエンジニアをしている熊谷です。 ここ1年ほどで、AIを使うこと自体はかなり当たり前になってきました。人材紹介開発でも同じで、「使うかどうか」よりも「どう安全に、どう再現性高く使うか」のほうが重要なテーマになっています。この記事では、社内で実施したAIコーディング勉強会の内容を軸にしながら、現場での導入状況や、普段の取り組みを紹介したいと思います。 エス・エム・エスのコーディングエージェントの現状 会社として「特定のエージェントを」「どのくらい使ってよい」という縛りはなく、各々が必要と感じているサービスを申請し、それらを利用する形になっています。例えば私はもっぱらCodex（ChatGPT-5.4）を愛用しつつ、ローカルではClaude Codeと連携するようにしていますし、Pull Request上ではGitHub Copilotがレビューをします。そのほかにも社内ではCursorを利用している方もいますし、OpenCodeと特定のLLMを組み合わせて使う人もいます。 もちろん新規のサービスを利用するには事前申請・審査が必要ですが、使いたいという要望に可能な限り答えてくれるような環境が揃っているな、と感じます。 まず、現場でどれくらい使っているのか 勉強会をすることになったきっかけとして、社内でコーディングエージェントは一般的に使われていることをslack等で観測していました。一方で互いにどのように使っているかをsyncする場がなかったため、 @kenjiszk と相談し勉強会を開催することにしました。 勉強会の冒頭では、参加メンバーに簡単なアンケートを取りました。回答者は19名です。 「業務でコーディングエージェントを利用していますか？」という質問に対しては、「ほぼ全ての業務で利用している」が63%、「一部で利用している」が36.8%でした。少なくとも今回の参加者に限って言えば、まったく使っていない人はいませんでした。人材紹介開発では、すでにAIの活用が特別な試みではなく、日常的な前提になっていると言えそうです。 用途として多かったのは、設計の壁打ちとコーディングです。実装そのものを任せるだけでなく、仕様の整理や方針検討の相手として使っているメンバーが多いのも印象的でした。 普段使っているエージェントツールとしては、Claude CodeとGitHub Copilot系が多めでした。一方で利用モデルはかなり収束していて、Opus 4.6やGPT-5.4系を使っているメンバーが多い、という結果でした。 最後に現在のコーディングエージェントに対する感想です。「もうこれがないと厳しい」という声もあれば、「なくても何とかなるけれど、あるとやはり速い」という声もありました。温度差は多少あっても、AIをまったく使わない状態には戻りにくい。そんな空気感で勉強会はスタートしました。 勉強会で最初にそろえたかった前提 今回の勉強会では、いわゆる「AIがすごい」という話よりも、その性能を現場で引き出すための土台にあたる部分を中心に扱いました。 スライドではこれをHarness Engineeringの入口として紹介しています。AIそのものを賢くする話ではなく、AIを安全に、安定して使うための運用設計の話です。いま主要なコーディングエージェントは、単にモデルが優秀かどうかだけでなく、AGENTS.md、Skills、MCPやCLIといった周辺の仕組み込みで使われるようになっています。 勉強会でも、まずはこのあたりの基礎知識をそろえるところから始めました。 AGENTS.md は「最初に効かせたい前提」を置く場所 AGENTS.mdには、そのリポジトリでエージェントが最初に知っておくべき前提を書きます。 たとえば「このリポジトリはpnpmを使う」「生成ファイルは直接編集しない」「スキーマ変更時にはmigrationが必要」といった情報です。価値観やお気持ちを書くというより、次の行動が変わる事実を書くほうが効きます。 人間にとっては暗黙知になりがちなことでも、AIにとっては明示されているかどうかで挙動がかなり変わります。このあたりを雑にせず、最初の入口で分岐ルールを渡すのが大事だよね、という話をしました。 Skills と MCP は「再利用できる判断」と「実行の接続境界」 もうひとつ勉強会で触れたのが、SkillsとMCPの位置づけです。 Skillsは、特定のタスクに対してどう判断し、どう進めるかを再利用できる形にしたものです。うまく作れば、他人のベストプラクティスをかなり高い精度で再現できます。個人的には、コーディングエージェントを使いこなすうえでかなり重要な要素だと思っています。 一方でMCPは便利な反面、サーバー側が公開する仕様を読み込んでから使い方を判断する構造なので、対象によってはトークン消費が重くなりがちです。そのため、最近は公式のCLIがあればそちらを優先する、という流れも強くなっています。 このあたりはツールごとの差も大きいのですが、少なくとも「モデルの性能だけ見ていればよい時代ではない」という認識を合わせるのが今回の狙いでした。 セキュリティ 勉強会開催時点の2026年3月13日は、コーディングエージェントにおけるセキュリティの話題が特に多かったこともあり、このテーマは厚めに扱いました。セキュリティといっても話はさまざまに広がりますが、今回は特に話題の多かった「シークレットの取り扱い方」をベースにしています。 基本方針はシンプルで、 「漏れた後で止める」より「そもそも見せない」で設計する ことです。AIに安全設定を入れること自体は大事ですが、それだけで守り切れる前提には立っていません。AIから見えてしまう状態を作らないこと、見えたとしても被害が最小限になる構成にしておくことを重視しています。 たとえば、repo内に平文の .env を置くことを前提にしません。社内では1Passwordを使って秘密情報を共有するのが前提なので、平文の秘密情報を直接AIに触らせないようにする。少なくとも「普通に作業していたら見えてしまう」状態は避けるべきだ、という話をしました。実際にハンズオンも行い、CLIを介して実行時に秘密情報を外部から埋め込むやり方も確認しました。 さらに、開発環境と実行環境を分離する考え方も共有しました。AIが触る開発環境と、人間が秘密情報を扱う実行環境を分けておけば、物理的に環境変数へ触れない構成に寄せられます。devcontainerのような仕組みも、この文脈ではかなり相性がいいです。 もちろん、AIに秘密を見せないようにしても、AIが書いたコード側から秘密が出力されてしまえば意味がありません。そのため、commit前に検知する仕組みも重要です。勉強会では、lefthookやsecretlintを使って決定論的に防ぐ考え方にも触れました。 このあたりは、人材紹介開発としてかなり大事にしているところです。AIを積極的に使うからこそ、安全寄りの運用ルールやガードを先に整える。そこは候補者の方にも安心材料として伝えたいポイントです。今回の勉強会で完璧に網羅はできているとは言えませんが、それでも最低限やっておきたいことは共有できたと思います。 個人的なおすすめツールとモデルの話 勉強会の後半では、少し肩の力を抜いて、個人的な（かなり偏見の入った）おすすめも紹介しました。 参加メンバー全体で見るとClaude Code利用者はかなり多いのですが、私はCodexやGPT-5.4が結構好きです。コストと性能のバランスがよく、きちんと指示したときの手堅さもあって、普段の開発ではかなり使いやすいと感じています。 スライドでも少し冗談っぽく話したのですが、Opus 4.6とGPT-5.4は、優劣というより味付けが違う印象です。Opus 4.6はよしなに色々やってくれる一方で、GPT-5.4はシンプルに言われたことを淡々とこなしますと感じています。この違いは好みの問題でもありますし、用途によって向き不向きもあります。ただ、モデル選定も含めて「どう使うと気持ちよく働けるか」をチームで共有できるのは、勉強会の良いところだと思っています。 ※ 勉強会→記事の執筆の間でCursorではすでにComposer 2がリリースされており、情報が古くなっている点にご注意ください。 あわせて、おすすめのSkillsや、野良のMCP / Skillsを安易に入れないといった運用ルールも共有しました。便利そうに見えるものをすぐ入れるのではなく、公式のものや信頼できるものを選ぶ。判断に迷う場合は社内でレビューする。このあたりも、安全にAIを使い続けるうえでは外せないポイントです。 勉強会だけで終わらせず、日常的に相談できる場を作っている 人材紹介開発では、勉強会を単発イベントで終わらせないことも意識しています。 AIに関する雑談や相談をする時間を意識的に取り、最近気になったニュース、試してよかったツール、うまくいかなかった使い方、困りごとの相談などを持ち寄っています。きっちりした発表会というより、かなり気軽な共有の場です。 こんな感じで雑談ネタをまとめていて、話したいこと・聞きたいことをリストアップしてます。 専用のSlackチャンネルもあり、「こういうときはどう使うのがよさそうか」「この運用で危なくないか」といった話を日常的にできるようにしています。 AIの活用は、個人が一人で頑張るだけだとどうしてもムラが出ます。だからこそ、使い方をオープンにし、うまくいったことも失敗したことも共有できる場を持つことが大事だと考えています。 おわりに いまのソフトウェア開発では、AIを使うこと自体はかなり当たり前になりました。人材紹介開発でも、その前提は同じです。 一方で、私たちが本当に大事にしているのは、「とにかく速く書ける」ことだけではありません。安全に使えること、再現性高く使えること、チームで学びを共有しながら前に進めること。そのあたりまで含めて、開発の仕組みとして整えていこうとしています。 これからエス・エム・エスに興味を持ってくださる方や、選考中の方にとって、現場の雰囲気が少しでも伝わればうれしいです。AIを積極的に使いながら、同時に安全性や運用もちゃんと考える。そんなチームに関心があれば、ぜひカジュアルに話しましょう。

はじめに 本記事は、先日開催された「RECRUIT TECH CONFERENCE 2026」より「和田卓人氏と語る、"開発現場"の

1. はじめに 今回は、MCP 初心者が MCP サーバを試してみて考えたこと・気づいたことを紹介しようと思います。 MCP は概要だけ知っていたものの今まで使ったことがなかったのですが、GitHub Copilot（筆者は VS Code で利用）の Agent モードを活用すれば簡単に環境を作って試せるのではないかと思いつきました。 そこで、馴染みのないツールの MCP サーバでも手軽に試すことができたら良いなと思い、初めて触る Playwright を用いて UI/UX レビュー&修正のサイクルを自動化させてみました。 なお、この試みの中で私は1行もコードやプロンプトは