こちらの記事は「MEDLEY Summer Tech Blog Relay」の28日目・最終日の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp みなさん、こんにちは。株式会社メドレー 人材プラットフォーム本部 VPoE の倉林（ @terukura ）です。全社のAI活用を支えるAI基盤開発室の室長も兼務しています。 7月13日から28日間、平日毎日つないできたリレーも今日でゴールとなります。社内の皆さん、完走お疲れ様でした！！ はじめに 先日、社内でこんな光景がありました。 法務のメンバーが Pull Request を出し、AIエージェントがレビューコメントを付け、それを受けて修正がマージされる。 ここまでなら、開発チームの日常です。ただしこのPRの中身はコードではなく、契約書レビューの観点をまとめたskill定義でした。出したのはエンジニアではなく、法務のメンバー本人です。 昨年4月に「メドレーのAI活用戦略：AI for All」という記事を書きました。「全職種が全業務で当たり前にAIを活用する」—当時はまだ宣言に近かったこの言葉が、この1年でどこまで現実になったのか。 メドレーのAI活用戦略：「AI for All」 | MEDLEY Developer Portal メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林(@terukura)です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組ん... developer.medley.jp その答えを一言でいうと、こうなります。 全職種にAIを届けようとした結果、全職種がGitHubを使う会社になってきた。 この記事では、なぜそうなったのか、そしてそれを支えている仕組みの一部を紹介します。 室長を務めているAI基盤開発室は、AI共通基盤の構築、ツールの選定・開発・運用、環境整備といった土台づくりと、それを現場に行き渡らせるAI活用推進（いわゆるAI Enabling）の両方を担っています。基盤は、作るだけでは使われません。作って、届けて、使われるところまでが仕事です。 この1年の活動を貫いていたテーマは、次の3つです。 エージェントが速く、安全に走れる環境（ハーネス）を整える 業務知識（skill）を流通させる 効果を計測し、見える化する この記事では、この3つを軸に振り返ります。 なぜ「全社AIハーネス」が必要になったのか AIエージェントに仕事を任せようとすると、すぐに気づくことがあります。 エージェントには「働く場所」が要る、ということです。 業務の文脈（ルール、過去の判断、ドメイン知識）はどこに置くのか 成果物はどこに出すのか 人間によるレビューと承認はどこで回すのか 改善の履歴はどこに積むのか チャットUIも最近はメモリやプロジェクト機能を備え、「使うほど賢くなる」方向に進化しています。ただ、その蓄積は個人とツールの中に閉じがちです。隣のチームからは発見できず、レビューも履歴も残らず、別のエージェントには持ち運べない。個人の生産性は上がっても、組織の資産にはなりにくいと感じています。 エージェントの実行環境（ハーネス）に必要な要件を並べてみると— エージェントに必要なもの それを満たすもの 文脈の蓄積と版管理 リポジトリ + バージョン管理 成果物の置き場 リポジトリ 人間の承認フロー Pull Request 自動実行 GitHub Actions 作業キュー Issues 並べてみて、気づきました。この要件は、すべてGitHubが満たしています。 新しいAI基盤ツールを探すまでもなく、エンジニアが20年近く使い続けてきた道具が、AI時代の全社ハーネスの要件をそのまま満たしていた。私たちはこの事実を受け入れ、GitHubを軸に全社のハーネスを整えていくことにしました。 エージェントの生産性は、モデルの賢さだけでは決まりません。整備された道路の上でこそ車がスピードを出せるように、同じモデルでも、走る環境—ハーネス—次第で出せる速度と安全性はまるで変わります。私たちがこの1年やってきたのは、この道路を全社に敷くことでした。 部門ごとに .claude/ を持つ 現在のメドレーでは、エンジニア組織の外にも部門ごとのリポジトリがあります。実際の構成の一部を挙げると— legal-compliance/ # 法務・コンプライアンス .claude/skills/ # contract-review(契約レビュー), ops-ringi(稟議)… human-capital/ # 人事 .claude/skills/ # jd-review(求人票レビュー), workflow-review(業務フロー)… corporate-it/ # コーポレートIT .claude/skills/ # support-L1(ヘルプデスク一次対応), isms-take-inventory-github(ISMS棚卸し)… internal-audit/ # 内部監査 .claude/skills/ # draft-jsox-rcm(J-SOX文書ドラフト), review-audit-workpaper(監査調書レビュー)… 契約レビューの観点も、稟議の通し方も、J-SOXの文書化も、部門の業務知識そのものが .claude/ （skillsやCLAUDE.md）としてバージョン管理されていっているのがポイントです。 業務ルールの変更はPRになる。つまりレビューと履歴が残る 新メンバー（人間もAIも）は、リポジトリをcloneすれば部門の文脈を持てる 会議室の空きを探すskillから監査調書レビューまで、粒度の大小を問わず「その部門のやり方」が形式知になる 集めて、共有して、配布する skillが各部門のリポジトリに散らばると、今度は同じようなskillの乱立や、車輪の再発明が起きます。そこで、収集→共有→配布の3層で流通させる仕組みを作りました。 収集（collect） : 毎日早朝、グループ全org・400超のリポジトリをスキャンして、AI設定ファイルを横断収集。集めたskillは名前・説明・出典リポジトリつきの全社カタログとして自動整理され、日々の差分がSlackに流れる 共有（share） : 良さそうなものは共有リポジトリに持ち寄る。 npx skills add で使いたい人が自分で引いていく、気軽な置き場 配布（marketplace） : 全社標準と判断したものだけを、プラグインとして版管理つきで正式配布。Claude Codeの /plugin install と、非エンジニアが使うClaude Coworkで同一のmarketplaceを共用し、さらにClaude Teamの組織設定で本人が何もしなくても届く 共有と配布の違いは、届け方と責任です。共有は使う人が引く（pull）、配布は全社に押して届ける（push）。持ち寄りの気軽さと標準装備の信頼性は求められるものが違うので、同じ場所に混ぜないようにしています。 私たちの仕組みが少し珍しいのは、「共通リポジトリを用意したので、ここで共有してね」から始めなかったことだと思っています。 skillやルールは、業務のあるところで生まれます。各プロダクトのリポジトリには、そのチームのskill、エージェント向けのルール、CLAUDE.md、カスタムエージェント定義やhooksが既に大量に育っています。多いリポジトリではskillだけで90近く。これを「中央のリポジトリに引っ越して共有してね」と言った瞬間、現場の文脈から切り離されて陳腐化するか、そもそも誰も引っ越しません。 だから順番を逆にしました。skillは現場のリポジトリに置いたまま、収集する側が毎日全部を読みに行く。書き手には何の作業も求めない。良いものはカタログの中から発見され、必要になった段階で初めて共有・配布へ昇格する。中央は「正」ではなく、現場の写像です。 収集は書き手に、配布は使い手に、作業を求めない。 両端がゼロタッチであること が、全社に広げるうえで一番効いたと思います。 この仕組みで見えるようになったskillの数は— 指標 収集開始時（2026-03） 現在（2026-08） スキャン対象リポジトリ 280 445 CLAUDE.md の数 147 370 Claude Skills の数 212 1,221 約5ヶ月でskillは6倍近くに増えました。「発見できる」ようにしただけで、隣の部門のskillを参考に自部門版を作る動きが自然に生まれています。 skillにもテストを書く skillが1,000を超えると、「作ったのに発火しない」「関係ない場面で発火する」が品質問題になります。そこで共有リポジトリのskillにはトリガー評価セットを同梱しています。 should_trigger: true のクエリだけでなく、「このクエリでは発火してはいけない」というネガティブ例も書く。発火しすぎるskillは、発火しないskillと同じくらい有害だからです。 さらに、Claude用に書いたskillがCodexでも機能するかを codex exec でsmoke testする自作evalも運用しています。1つのskillをClaude Code / Cowork / Codexの3つのハーネスに向ける以上、テストもハーネス横断です。 非エンジニアはGitHubを使えるのか 正直に言うと、いまも簡単ではありません。 「コミット」「ブランチ」という語彙の壁 コンフリクトで完全に手が止まる そもそもローカル環境を持っていない 「非エンジニアもPRを出す会社」の先行例といえば、 GitLabのhandbook文化 が有名です。全社員がMerge Requestでハンドブックを直す。ただしあれは、採用からオンボーディングまで長い時間をかけて根付かせた文化があってこそ成立するもので、同じやり方をすぐに真似するのは難しい。私たちが選んだのは、 人がGitに歩み寄るのを待つのではなく、AIとハーネスの側から人に歩み寄るやり方でした 。 それでも前に進めているのは、書く作業の大半をAIエージェントが肩代わりするからです。契約レビューのskillを直したい法務メンバーがAIに「こう直して」と伝えれば、ブランチもコミットもPRもAIが作る。本人に残るのは、Gitの操作スキルではなく「レビューして承認する」ことだけ。PRという承認フローは、むしろ非エンジニアにとって自然だったのです。 そしてもうひとつ大事なのは、 そもそも「GitHubを使えるようになること」を目的にしていなかったことです 。「まずGitを覚えましょう」という研修から入ったわけではありません。非エンジニアの目的はあくまで「AIに仕事を任せること」であり、GitHubはエージェントが働く場所として、その後ろに静かについてきただけです。タイトルの「AIを届けようとしたら、GitHubを使う会社になってきた」は、文字通りこの順番の話です。 全部収集する 〜 それを支えるAI Usage ハーネスが整うと、良いことがあります。全部が見えるようになるのです。 私たちはAI利用の状況を「AI Usage」という内製ダッシュボードに集約しています。収集しているのは— コーディングエージェントのテレメトリ : Claude Code / Claude Cowork / Codex からOpenTelemetryで直接収集 各AIツールのAPI : Cursor、Devin、GitHub Copilot、Claude / OpenAI Platform API 基盤ツールの利用状況 : n8n、Dify LLMアプリの品質データ : Langfuseのtraceと評価スコア 開発成果 : GitHubのPRデータ（Four Keys） 組織データ : 人事データと突合して本部別・職種別の活用率を算出 ちなみに、集めたデータの出口はWebのダッシュボードだけではありません。MCPサーバーとしても提供していて、Claude Codeから「今月の自分のAI利用状況を教えて」と聞けます。 トークン数の「先」まで測る 「誰がどれだけ使ったか」だけなら、各ツールの管理画面でも分かります。本題はその先です。 Skill実行とMCP呼び出しを計測している。どのskillが何回使われたかに加えて、自動発火したのか・明示的に呼ばれたのかまで分かる。skillを作った側が「ちゃんと発火しているか」を検証できる AI利用と開発成果を重ねている。チーム別に、AIトークン投入量とContributorあたりマージPR数をバブルチャートで可視化している AI活用レベルは、聞かずに測る 社員やチームのAI活用度を把握する方法として、アセスメント—自己申告アンケートやスキル検定でレベル分けする—を採る会社は多いと思います。私たちも一度は考えて、やめました。ハーネスが整っていれば、聞かなくても行動ログから算出できるからです。 チームのページを開くと、Skills利用、MCP活用、エージェントへの委任、高度活用メンバーの数といった指標が自動で表示されます。アセスメントとの違いは3つ。回答負荷がゼロであること、常に最新であること、そして申告と実態のズレがないこと。アンケートによる定点観測では、この速度の技術変化には追いつけません。 必要だったのは、常時観測です 。 おわりに 〜 リレーの裏側にあったもの この28日間、メンバーたちはハーネスエンジニアリングから権限設計、LLM API設計、ローカルMLLMまで、それぞれの持ち場の実践を書いてきました（全記事は リレーの紹介記事 からたどれます）。いくつか挙げると— 素晴らしい提案をしよう！君もハーネスエンジニアにならないか？ 生成AIを活用した自動化に必要な権限設計の考え方 LLM API を叩くときに考えること — AIを機能に組み込む前に確認する6つの観点 Jetson Orin Nano Super によるローカルMLLM活用について 個々のメンバーが28日間書いてきた実践の裏には、今回ご紹介させていただいたような計測と推進の仕組みがあります。 「AIでエンジニアリングは不要になる」という言説を見かけますが、私たちの現場で起きているのは逆です。バージョン管理、コードレビュー、CI—エンジニアが20年かけて磨いてきた道具と規律は、AI時代になって初めて「全社の標準装備」になってきています。エンジニアリングは要らなくなるどころか、会社全体の働き方の中心を担いはじめています。非エンジニアがGitHubに来つつあるのは、そこにしかない規律の価値を、AIが翻訳してくれているからです。 「AI for All」と宣言してから1年。全職種がAIを使う会社を目指した私たちは、気づけば全職種がGitHubを使う会社になっていました。AIの民主化とは、実はハーネスの民主化のことだったのかもしれません。 その意味で、私たちはGitHubそのものに賭けているわけではありません。今年6月にはCursorが、エージェント時代を前提に設計したGitフォージ「 Origin 」を発表しました。賭けているのはバージョン管理・レビュー・自動化という「ハーネスの型」であって、Git互換である限り、この記事で書いた仕組みは持ち運べます。次の道路がどこに敷かれるのか、こうした動きにも注目しています。 メドレーは今期、 AX Project を始動しました。「AIを足す」のではなく、 AIを前提に会社をゼロから設計し直す 取り組みです。全部門のワークフローを「人が担う工程」と「AIに任せる工程」に仕分けし、組織構造や要員計画のあり方まで変えていく。全社AI活用の統括責任者としてCAXO（Chief AI Transformation Officer）が置かれ、AI基盤開発室はその直下で、全社の環境と基盤を作る役割を担います。自律型AIを業務やプロダクトに組み込む新職種「 Applied AI Developer 」の新設も、この流れの一部です。 社内で共有されている問いがあります。 今日、AIを取り上げたら会社が回らなくなるか？ 回るなら、それはまだAIを「足している」だけの会社である。 AX Projectは、全社のワークフローを書き出し、skillとして整備するところから始まります。この記事で書いたGitHubハーネスも、skillの流通も、AI Usageも—すべては、この問いに「回らなくなる」と胸を張って答えられる会社になるための土台です。 メドレーでは「医療を人間中心へ」というミッションのもと、一緒にこの仕組みを進化させてくれる仲間を大募集しています。この記事や本リレーの記事にピンときた方、ぜひカジュアルにお話ししましょう！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

はじめに こんにちは！株式会社ユーザベース スピーダ事業でソフトウェアエンジニアをしている阿波連、内山、撰、知念です。 私達は現在、データの取り込み業務を行っており、様々なファイルの読み込み、Speedaに取り込んでいます。 その中で、ファイルの改行コードがCRLFのものがあり、そのテストを書くために、CRLFのファイルをgit管理するときに躓いた話をブログで執筆することにしました。 問題 $ git add -A warning: in the working copy of 'path/to/crlf_include.csv', CRLF will be replaced by LF th…

はじめに こんにちは。クラウドエース株式会社 第四開発部の河添です。 近年、生成AIの進化によって、PowerPointスライドの作成も AI に任せられる時代になりました。今では AI でスライドを作る方法が数多くありますが、それぞれ実際に出力されるものは微妙に異なります。 そこで、この記事では同じ原稿・同じテンプレを異なるツールに渡すと出力がどれだけ変わるのかを見比べることで、AI時代における効率的なスライド作成方法について考えていきたいと思います。 早見表 まずは、今回比べる4手法を簡単に紹介します。 NotebookLM: 原稿（ソース）を渡すと自動でスライド化してく