キャディ株式会社のデータ解析チームで、MLモデル開発をしている藤田です。 本記事では、私たちのチームで取り組んだ生産性改善の話をします。 1. 電線を張らずに電波塔を建てる？ アフリカの一部地域では、固定電話網が普及する前に携帯電話が一気に広まりました。電線を張り巡らせるという「これまで当たり前だった工程」を飛ばして、いきなり電波塔を建てることで通信インフラを整えたのです。いわゆる「リープフロッグ（蛙飛び）」と呼ばれる現象です。 新しい技術は、既存の工程を「速くする」だけでなく、ときに工程そのものを不要にすることがあります。 今回、私たちは機械学習の開発プロセスで、これと同じことをやりました。これまで、既存モデルのアップデートを自動化するには、ML パイプラインを構築するといった相応の開発が必要でした。しかし Agent Skills を使うことで、そのパイプライン開発という工程そのものをスキップして、効率的に自動化できたのです。電線（ML パイプライン）を張り巡らせる代わりに、電波塔（Agent Skills）を建てた、というわけです。 結果として、1モデルあたりの開発工数はおよそ半分（生産性は約2倍）になりました。この記事では、次の3点を紹介します。 なぜ、これまで自動化が続かなかったのか（ジレンマ） Agent Skills で何をやったか（電波塔を建てる） どれだけ効いたか（効果） 2. 本取り組みでの「生産性」とは 私たちのチームのミッションは、認識モデルを開発し、その成果物を素早く・安全にプロダクトへ届け続けることです。この生産性を測る指標の1つが 開発リードタイム（精度・速度が十分なモデルの平均開発期間）で、今回はこの短縮に絞って取り組みました。 3. どの作業に時間がかかっているか？ まず、工程を分解して、工数を圧迫している作業を洗い出しました。その中でも特に重かったのが「学習の実行」です。原因は大きく2つありました。 学習が自動化できておらず、手作業になっている ：実行のたびに人が張り付く必要がある。 既存コードの実行環境が古い ：既存モデルの精度を改善しようにも、当時のコードの実行環境（Docker image やライブラリのバージョン）が古く、そのままでは動かない。 実際には他にも様々なボトルネックに対策を打ちましたが、この記事では「学習の実行」に絞って紹介します。 4. これまでの取り組み 過去数年、学習の自動化（ML パイプライン構築）を何度か試みました。しかし、あまりうまくいきませんでした。 理由はシンプルで、「アップデートするための仕組みを作る・メンテナンスすること自体に工数がかかる」からです。 モデルごとに要件がバラバラ ：入力データも評価指標も学習手順もモデルごとに違うため、一度作った仕組みを他のモデルに使い回しにくい。汎用化しようとするほど、作り込みの工数が膨らむ。 メンテナンスコストがかさむ ：データやモデルの前提が変わるたびにパイプラインの改修が必要になり、工数がかかる。 ML パイプラインを一度組めば以降の再学習は自動化できます。しかし、その仕組みを作る工数があれば、その工数で手作業のモデルのアップデートや再学習ができてしまう。だったら手でやったほうが早い——そういう判断になりがちでした。 こうして、多くの試みは「割に合わない」か「作っても長続きしない」という形で終わっていきました。つまり私たちは、自動化したい気持ちはあるのに、自動化への投資が回収できないというジレンマをずっと抱えていたのです。 5. 対策：ML 開発で「電波塔」を建てる そこで目をつけたのが「Agent Skills」です。 専用のパイプラインをわざわざ開発しなくても、Agent Skills を用意しておけば、エージェントがその場に応じて作業を進めてくれる。ポイントは、新しく仕組みを作るのではなく、すでにある資産（README や学習コード）をエージェントにそのまま動かさせることです。これが、まさに「電線を張らずに電波塔を建てる」に相当します。 このやり方なら、これまで自動化が続かなかった原因そのものを避けられます。 初期工数が小さい ：パイプラインを作り込まないので「割に合わない」になりにくい。 壊れても直せる ：環境が古くて動かなくても、エージェントがエラーを解析し、修正案まで出してくれる。 対策①：Agent Skills で学習・評価・レポート作成を自動化 我々のチームでは、学習の実行から評価・レポート作成までの手順をREADMEに記載しています。そのREADMEに沿って学習を実行するようにエージェントに任せました。 学習実行 ：README の手順どおりに学習を実行する。 評価 ：精度・速度を測定する。 レポート作成 ：結果のレポートを作成する いずれも既存の Agent Skills を再利用でき、2件目以降のモデルはこのインフラに相乗りするだけで済みます。 対策②：学習実行 CI で「動く状態」を維持 README の手順どおりに学習を実行する Agent Skills を、hosted-runner 上でエージェントに動かさせます。ライブラリや実行環境が古くて動かないときは、エージェントがエラーを解析し、修正案まで出してくれます。これで、コードを常に「動く状態」に保てます。 %%{init: {'sequence': {'mirrorActors': false}}}%% sequenceDiagram participant Dev as エンジニア participant GH as Github participant GHA as Github Actions participant Agent as AIエージェント on hosted-runner Dev->>GH: コード修正、ライブラリのアップデート, etc GH->>GHA: readme実行のGithub Actionsを起動 GHA->>Agent: readme実行の Agent Skills を使い、学習を実行 Agent-->>GHA: 成功・失敗、実行結果レポート、改善案を提示 GHA-->>GH: 結果を返す フローは次のとおりです。 エンジニアが変更をプッシュ ：コード修正やライブラリのアップデートなどを Github に反映する。 CI が起動 ：その変更をトリガーに、README 実行用の Github Actions が走る。 エージェントが学習を実行 ：hosted-runner 上で、README 実行の Agent Skills を使ってエージェントが学習を回す。環境が古くて動かないときは、エージェントがエラーを解析し、修正案を組み立てる。 結果を返す ：成功・失敗の判定に加え、実行結果レポートと改善案を Github に返す。 これにより、変更が入るたびに「本当に動くか」を自動でチェックでき、コードを常に「動く状態」に保てます。 エージェントが作成する実行結果レポートのイメージがこちらです。エラーが出ても修正案まで示してくれるので、直すのがぐっと楽になります。 🧪 スモークテスト結果 — FAIL README 手順別サマリ README の手順 結果 備考（スキップ/失敗の理由・修正内容） セットアップ ✅ データ準備 ✅ 学習 ✅ test_run=True で 1 iteration 完了 export (TorchScript) ✅ det-gpu.pt 生成完了。 推論 ❌ 下記バグにより TypeError 発生。 発生したエラー（推論で TypeError） File "inference.py", line 1061, in main TypeError: 'NoneType' object is not iterable 原因 inference.py L985 の entry.get("results", []) は、Phase 1 で検出なしの画像に対して "results": null が JSON に書き込まれるため、キーは存在するが値が None になる。 修正提案 （以下のパッチで解消を確認） diff --git a/inference.py b/inference.py index 12038b3..a1d697d 100644 --- a/inference.py +++ b/inference.py @@ -982,7 +982,7 @@ def main( for entry in tqdm(entries): image_name = entry["file_name"] gcs_path = entry.get("gcs_path", "") - detection_results = entry.get("results", []) + detection_results = entry.get("results") or [] 新しく仕組みを作らず、既存資産（README・学習コード）を動かし続けることで、環境の再現性を保ちました。 6. 効果 結論から言うと、実際に生産性がおよそ2倍になりました。 過去に実際にかかった、既存モデル改善プロジェクトごとの工数と、今回かかった工数を、ざっくり比較すると、1モデルあたりの工数がおよそ半分——つまり生産性が約2倍になりました。 ※ 本来はプロジェクトごとに要件や状況が異なるため、単純比較はできません。ここではそれらをあえて無視した、ざっくりとした概算です。 効果が大きいのには理由があります。 「学習の実行」の自動化・環境維持が、工数削減に大きく寄与する 既存 Agent Skills を一度作ってしまえば、全てのプロジェクトで使うことができる まさに「電波塔を一度建ててしまえば、次からは同じインフラに相乗りできる」という構図です。最初のモデルで Agent Skills を整備しておけば、2件目以降はそのインフラに乗るだけで、劇的に軽くなります。 まとめ 新しい技術は、既存の工程を「速くする」だけでなく、ときに「工程そのものを不要にする」力を持っています。 アフリカが電線を飛び越えて電波塔で通信インフラを整えたように、私たちは ML パイプライン開発を飛び越えて、Agent Skills で機械学習の開発プロセスを自動化しました。その結果、1モデルあたりの工数はおよそ半分になり、生産性を約2倍に引き上げることができました。とくに既存モデル改善では、一度作った Agent Skills を再利用することで大きな工数削減を実現できています。 これからも Agent Skills のような新しい技術を開発プロセスに取り入れて、生産性を上げていきたいと思います。

はじめに こんにちは！ セーフィー株式会社でサーバーサイドエンジニアをしている坂上（@Bobtaroh）です。 先日、2026年8月5日（水）19:00より、「セーフィー × カンリー AI Night #2：AI開発における社内標準化の取り組み」をオンラインで開催いたしました！ 第1回（詳細はこちら！）の続きとなる第2回目の開催となりましたが、今回も多くの方にご参加いただき、またアーカイブをご視聴いただいた皆様、本当にありがとうございました。 本記事では、当日の各LT（ライトニングトーク）のハイライトや、登壇者同士の白熱したクロストークの様子など、イベントの盛り上がりをお届けしま

こんにちは、タイミーでバックエンドエンジニアをしている志賀（ @akitoshiga ）です。 先日、複数の顧客企業にまたがる、複雑なデータ統合プロジェクトに取り組みました。 このプロジェクトには、次のような難しさがありました。 要件が曖昧で、影響範囲も見えづらい 統合パターンごとに状況や制約が異なり、考慮すべき条件が多い 関係者が多く、合意形成に時間がかかりやすい 事業上、変更しづらい期限がある 当時の体制では、バックエンド領域を主担当として動けるメンバーが限られていた このまま進めるだけでは、期限内の完了が難しい状況でした。 結論から言うと、次の3つを実践することで、期限内に完了できました。 AIを使ってコードと業務を調査し、自分で判断できるメンタルモデルを作った AI-DLCを使い、主担当領域の異なるメンバーも実装を進められる状態を作った ドキュメントを通じて論点を絞り、関係者の認知負荷を下げた 本記事では、この取り組みを紹介します。 プロジェクトの概要 タイミーでは、契約・請求・拠点・アカウント・アクセス権限など、複数の業務データが企業情報と結びついています。 データ統合は、単に参照先を変更するだけでは終わりません。 統合後にどのような状態であるべきかを定義し、その状態に合わせて関連データを整合させる必要があります。 今回のプロジェクトでは、統合パターンごとに移行範囲や制約が異なりました。 そのため、対象データごとに「何を移すのか」「何を残すのか」「どの状態を正とするのか」を判断する必要がありました。 複雑な統合パターンの存在 実案件を抽象化すると、次のような関係でした。 ある統合元は、すべての拠点を統合先へ移す 別の統合元は、一部の拠点だけを統合先へ移す さらに別の統合元は、別の企業へすべての拠点を移す この図は、実案件を説明用に抽象化・簡略化したモデルです。 ポイントは、同じ対象が、ある統合では移行元になり、別の統合では移行先にもなることです。 そのため、すべてのデータを一律に移すことはできません。 残すデータと移すデータを、対象範囲ごとに判定することが求められました。 また、別の統合によって入ってくるデータも考慮する必要がありました。 そのため、統合の実行順序にも依存関係が生まれました。 アクセス権限の組み合わせ爆発 顧客に紐づく各種データについても、場合分けが必要でした。 その一例が、管理画面アカウントとアクセス権限です。 アクセス権限には、全体に関わるものと、一部の範囲に関わるものがあります。 移行後も、本来アクセスできない範囲へ権限が広がってはいけません。 一方で、移行前に必要だった範囲へのアクセスを失わせることもできません。 この両立が、難しいポイントでした。 権限の種類、移行範囲、統合パターンの組み合わせによって、望ましい状態が変わるためです。 関連データごと種類ごとにこれらの判断が必要になる 他のデータも同様でした。 統合パターン、移行範囲、状態、関連データの制約が組み合わさり、判断すべき条件が増えていました。 自分は、関連するすべてのドメインに詳しいわけではありませんでした。 影響範囲を把握し、統合後の状態を決めるには、まず調査が必要でした。 どう進めたか AIを使って調査し、メンタルモデルを作る まず、AIを使ってコードを解析しました。 そのうえで、実際に画面を操作し、コード・画面・データの対応関係を確認しました。 自分の中でメンタルモデルを作れるまで、時間をかけて調査・検証しました。 前例がなく、自分たちで統合後の正しい状態を定義する必要があったためです。 ここで言うメンタルモデルとは、次のようなものです。 どのデータが、どの業務概念を表しているか どの操作で、どのデータが変わるか 統合後に、何が変わってはいけないか 異常系や例外パターンで、どこに影響が出るか この理解をもとに、PdMや関係者と相談しながら統合仕様を決めていきました。 短納期とチーム構成を踏まえてAI-DLCを採用する データ統合には、バックエンドのフレームワーク上で動作するスクリプトの実装が必要でした。 一方で、変更しづらい期限がありました。 自分だけで進めるには、時間的な制約が大きい状況でした。 そこで、主担当領域の異なるメンバーと一緒に進めるため、AI-DLCを採用しました。 AI-DLC（AI-Driven Development Life Cycle） とは、AWSが提唱するAIを中心に据えた開発手法です。 要件整理、計画、設計、実装、テスト、運用まで、開発ライフサイクル全体にAIを組み込んでプロジェクトを進めます。 タイミーでは、以前AI-DLCを業務で活用するための合宿を実施しました。 3日間のUnicorn Gymが1ヶ月で組織を変えた —— データで見るAI-DLC導入の波及効果 - Timee Product Team Blog 今回は詳細設計までを、複数人でAIの出力を確認するモブワークで進めました。 実装に必要な前提と完了条件を共有した後は、主担当領域の異なるメンバーにも、非同期で実装を進めてもらいました。 AIを使うことで、バックエンドの文法や実装パターンの理解を補助できます。 ただし、仕様の正しさまでAIに任せることはできません。 そのため、前提・制約・完了条件を人間が明確にしました。 そのうえで、AIの出力をレビューできる状態を作ることを重視しました。 合意のための認知負荷を下げる このプロジェクトは影響範囲が広く、多様な関係者が関わっていました。 全員に統合仕様のすべてを理解してもらおうとすると、合意までに時間がかかります。 また、関係者がそれぞれ判断すべきポイントも異なります。 そこで、意思決定のためのADR（Architecture Decision Record）では、必要な論点を絞りました。 レビュー観点、選択肢、推奨方針、影響、リスクを整理しました。 関係者が、それぞれの判断範囲に集中できるようにするためです。 仕様を説明・相談する際にも、認知負荷を下げるためのドキュメントを用意しました。 具体的な手法はここでは割愛しますが、以下の書籍を読んだ経験が自分の中で大きな礎となっています。 『ノンデザイナーズ・デザインブック』 『プログラマー脳』 『実装パターン』 その取り組みの結果、短いリードタイムで方針への合意を得られました。 終盤の考慮漏れに向き合う 仕様が複雑だったため、終盤のテスト工程で考慮漏れが見つかりました。 また、終盤で体制変更があり、権限に関する仕様判断を自分が引き取る必要がありました。 ただし、序盤にメンタルモデルを作っていたため、どこを確認し、誰に相談し、どの制約を守るべきかを自分で判断できる状態になっていました。 追加対応は発生しました。 それでも、影響範囲を絞り、対応順を決め、関係者と優先度を確認し、期限内に実装とテストを終えることができました。 まとめ 約1か月半という短い期間かつ限られた体制で、前例のない複雑なデータ統合プロジェクトに取り組みました。 この状況に対して、次の3つを実践しました。 AIを使ってコードと業務を調査し、自分で判断できるメンタルモデルを作った AI-DLCを使い、主担当領域の異なるメンバーも実装を進められる状態を作った ドキュメントを通じて論点を絞り、関係者の認知負荷と合意形成のリードタイムを下げた 結果として、複数のメンバーで実装を分担し、期限内に実装とテストを完了できました。 一方で、AI-DLCを使っても、仕様の正しさまで保証されるわけではありません。 前提となるドメイン理解と、人間による意思決定が重要です。 AIは、単なるコード生成ツールではありません。 理解・合意・協働を加速する存在として開発プロセスに組み込むこと。 それが、AI時代のプロダクトエンジニアリングに必要な姿勢だと感じました。