こんにちは。タイミーのデータエンジニアリング部 DSグループでMLOpsを担当しているYukitomoです。 私たちのチームでは多くのPythonアプリをモノレポで管理していますが、Dependabotによる依存関係更新PRが多すぎることが運用課題でした。本記事では、Renovateへの移行によって「更新PRの粒度と数をコントロールできる運用」を実現するまでの設計判断と、Python + uv環境特有の注意点を共有します。 この記事の想定読者 Pythonのモノレポ環境で、複数のアプリケーションやライブラリを運用している方 Dependabotが生成する大量の更新PRの対応に疲弊しており、運用を効率化したい方 Renovateへの移行を検討している、または導入したが設定（packageRules）のベストプラクティスに悩んでいる方 パッケージマネージャーに uv を採用している（または検討している）方 要約（TL;DR：この記事でわかること） 本記事では、Python + uv環境でRenovateを運用する際の課題とその解決策（新しすぎるパッケージの除外設定、Google Cloud WIFにおけるブランチ名の文字数制限の回避など）を整理し、実践的なrenovate.json5の設定ノウハウを解説します。 背景 近年はサプライチェーン攻撃が現実的なリスクになっており、Trivyの侵害以降も Python モジュールや JS ライブラリを狙った攻撃が継続して観測されています。PyPI など外部エコシステムに依存する以上、これまで以上に「依存関係をどう安全に運用するか」を真面目に考える必要があります。 一方で、依存関係を「安全に」保つには、継続的にアップデートを回し続ける必要があります。ここで次の課題になるのが、運用対象が増えたときに更新対応のコストがスケールしてしまう点です。 私たちもDependabot運用の効率化を進めてきましたが *1 、アプリごとにパッケージ管理へ移行した結果、モノレポ内のpyproject.tomlが増えました。2026年5月時点では、DSグループだけでも約70のPythonアプリケーション／ライブラリを扱っています。Dependabotは脆弱性の検知とPR作成を行ってくれる一方で、依存関係ごとにPRが分割されます。そのため、対象が増えるほど対応コストが急増します。 そこでこの課題を解決するため、Renovateを導入し「更新をまとめて扱える運用」へ切り替える方針にしました。本記事では、公式ドキュメントや公開されている設定例を参考にしつつ、私たちが重視した設定ポイントを整理します。 この記事の前提 言語: Python 依存関係ファイル: pyproject.toml / uv.lock 動作環境: GitHub & Google Cloud 目的: Renovateで「脆弱性対応」と「定常アップデート」を破綻なく回す（PRの数と粒度をコントロールする） 設定ファイル(.renovaterc.json5) 設計方針 私たちが設定で重視したのは以下の3点です。 PRの粒度をコントロールする — patch / minor / vulnerability を適切にグルーピングし、PRの本数を削減する サプライチェーンリスクを軽減する — 公開直後のバージョンを即座に採用しない 小さく始める — まず許可リスト方式で必要な更新だけを有効化し、段階的に広げる 全体像 以下が設定ファイルの抜粋です（各設定の詳細は後述）。 // .renovaterc.json5　より一部抜粋 { extends : [ " config:best-practices " ] , minimumReleaseAge : " N days ", lockFileMaintenance : { enabled : true , branchTopic : " lfm ", // GCP WIF 127-byte limitに対応するためブランチ名を省略 minimumReleaseAgeBehaviour : " timestamp - optional " // 一時的な対応 } , vulnerabilityAlerts : { groupName : " maintenance ", groupSlug : " maint ", minimumReleaseAge : " 14 days " , } , packageRules : [ // packageFileDirをブランチ名に含めつつGCP WIF 127-byte limitに対応するためブランチ名を省略 { matchFileNames : [ " base_containers/base/** " ] , additionalBranchPrefix : " {{{replace 'base_containers/base/' 'b_b/' packageFileDir}}}/ " , } , // packageRuleを一旦無効化 { matchPackageNames : [ " ** " ] , enabled : false } , // グルーピング ---------------------------------------------------- // ルール 1: { matchUpdateTypes : [ " patch " ] , enabled : true , groupName : " maintenance ", groupSlug : " maint " , } , // ルール 2: { matchUpdateTypes : [ " minor " ] , matchJsonata : [ " isVulnerabilityAlert = false " ] enabled : true , groupName : " minor updates ", groupSlug : " minor ", dependencyDashboardApproval : true } , // ルール 3: { matchPackageNames : [ " ** " ] , matchJsonata : [ " isVulnerabilityAlert = true " ] enabled : true , // この２つは vulnerabilityAlerts で設定した値で上書きされます groupName : " maintenance ", groupSlug : " maint " , } , // マイナーレベルでの破壊的な更新の抑制 ただし脆弱性対応を除く { matchJsonata : [ " isBreaking = true and not(isVulnerabilityAlert) " ] , enabled : false , }, ] , // バージョンの更新 bumpVersions : [ { bumpType : " patch ", filePatterns : [ " {{packageFileDir}}/pyproject.toml " ] , matchStrings : [ " version \\ s*= \\ s* \" (?<version>[^ \" ]+) \" " ] } , { bumpType : " patch ", filePatterns : [ " {{packageFileDir}}/uv.lock " ] , matchStrings : [ " name = \" [^ \" ]+ \"\\ nversion = \" (?<version>[^ \" ]+) \"\\ nsource = \\ { (?:editable|virtual) = \"\\ . \" \\ } " ] } ] } 設定項目の説明 config:best-practices を土台にする Renovateは設定可能な項目が多く、ゼロから組むと必ず設定が肥大化します。そこでまずは extends: ["config:best-practices"] をベースにして、一般的に安全側なデフォルトを取り込みました。 ベース設定を取り込んだうえで、運用上の要所（PRの粒度、セキュリティ例外、ロックファイルの扱い）だけを packageRules で上書きしています。 minimumReleaseAge （新しすぎるリリースを避ける） サプライチェーン観点では「出たばかりのバージョンを即座に拾う」ことが常に正解とは限りません。そこで minimumReleaseAge を設定し、公開直後のバージョンを一定期間は自動採用しないようにしています。 ここで一つ注意点があります。 minimumReleaseAge が効くのは、Renovateが pyproject.toml のバージョン指定を直接書き換える通常の更新（Standard Update）だけです。 一方、 pyproject.toml には記載されず uv.lock にだけ現れる間接依存（依存パッケージがさらに依存しているパッケージ）の更新は、Renovateの lockFileMaintenance が担当します。 lockFileMaintenance は内部で uv lock を実行しますが、現時点ではRenovateから uv lock に --exclude-newer 等のオプションを渡す手段がありません *2 。つまり、間接依存に対しては minimumReleaseAge による「新しすぎるバージョンの除外」が効かないのです。 そこで、uv自身が持つ exclude-newer 機能で補完しています。各 pyproject.toml に以下のように記述することで、 uv lock 実行時にuv側で公開直後のバージョンを除外します *3 。 # pyproject.toml [tool.uv] exclude-newer = "n days ago" # uv 0.10+ で相対日付指定が可能 # uv.lock (uv lock 実行時、以下のように変換されて保存されます) [options] exclude-newer = "2026-04-07T08:39:48.633055Z" exclude-newer-span = "PnD" この二重構成により、直接依存は Renovate の minimumReleaseAge 、間接依存は uv の exclude-newer でそれぞれカバーし、すべての依存パッケージに対して「新しすぎるバージョンを即座に採用しない」制約を適用しています。 lockFileMaintenance (Google Cloud Workload Identity Federationの制約対策とminimumReleaseAgeBehaviourの調整) 明示的に有効化します。また、プライベートなモジュールを独自のArtifactoryやNexusなどのパッケージインデックスに配置・利用することはよくあると思います。我々はGoogle Cloudを利用しており、プライベートなパッケージは Google Artifact Registry に保管しています。この場合、RenovateからGoogle Cloudにアクセスが発生し、Workload Identity Federation (WIF) を使う構成だと、subject claimにブランチ名が入ります *4 。ここに127 bytes制約があり、Renovateが生成するブランチ名が長いと認証に失敗します。対策として、作成するブランチ名を短縮化するため、 branchTopic の値を短縮しています(デフォルトでは “lock-file-maintenance”)。 この値を調整して通常の更新とブランチ名を一緒にし、PRを一緒にできないかと試したのですが、 Grouping lockfile maintenance with other update types is not supported というエラーメッセージが出たため断念しました。 minimumReleaseAgeBehaviour は、本来はデフォルト値の "timestamp-required" のほうが自然です。ただし、（*2）のrenovate のPRがマージされるまでは "timestamp-optional" にしておかないと、 lockFileMaintenance のPRがRenovate botの承認待ちになってしまうため注意してください。 vulnerabilityAlerts AIエージェントの助けを借りてRenovateのコードを確認し、試行錯誤する中で気づいたのですが、脆弱性対応に関する一部の設定は、packageRules で指定してもグローバルの vulnerabilityAlerts の値で上書きされます。具体的には、後述するグルーピングルール3の内容や、前項の minimumReleaseAge の設定です。 packageRules 以下、設定の意図をダイジェスト順に説明します。 1) packageFileDirをブランチ名に追加 複数のモジュールの更新を集約するために packageFileDir を additionalBranchPrefix に利用しています。モノレポにおけるadditionalBranchPrefixの一般化（ packageFileDir 由来のprefixを使う等）の詳細は別記事 *5 に委ねます。lockFileMaintenanceの項と同様、ブランチ名が長くなるため、Google Cloud Workload Identity Federation (WIF) の制約対策のためにブランチ名を短縮しています。 2) いったん全ルールを無効化して「許可リスト方式」にする { matchPackageNames: ["*"], enabled: false } 最初に全パッケージを enabled:false に落としてから、必要な更新だけを後続ルールで enabled:true に戻しています。Defaultを使いこなす方が安全とは思うのですが、まず最初は小さく、自分達でコントロールできる範囲から始めようとしてこのような設定としました。 3) PRのグルーピング（patch / minor / vulnerability） 別記事(*5)にもありますが依存関係更新の運用コストは「PRの数」と「レビューのコンテキスト切り替え」で決まるので、グルーピングが最重要です。 グルーピングルール1: patch更新: まとめて1本（メンテナンス枠） グルーピングルール2: minor更新: まとめて1本（ただし dependencyDashboardApproval:true で人間の許可待ちにする） グルーピングルール3: vulnerability: patchと同じグループに合流させ、優先して処理できるようにする Minor更新は、まずはダッシュボードで確認する運用にします。運用がうまく回りそうであれば、将来的にpatch groupingに合流させる想定です。 また、renovateのconfigは後ろの条件が前の条件を上書きするため、グルーピングルール3は最後に配置する必要があります。4）で扱う isBreaking に関する packageRule も同様に、後ろに配置してください。 4) 0.y.z系の“実質breaking”を抑止する SemVer上はminorでも、 0.y.z のようにリリースされていない場合、minor更新がbreakingになり得ます。そこで isBreaking = true を検知した更新は原則止めています。 ここは「通常アップデートは保守的に、ただし脆弱性対応は止めない」方針にしたいため、脆弱性アラート（ isVulnerabilityAlert:true ）にはこの抑止が効かないようにしています(=脆弱性があるものはIsBreakingでも検出させる)。 bumpVersions RenovateをGitHubで動作させるには、1) GitHub Actionsとして renovatebot/github-action を利用する方法と、2) 作成元のMend社が提供するMend Renovate Appを利用する方法があります。設定が簡単なことからタイミーでは後者を利用しているのですが、それ故の制約もあり、 postUpgradeTasks のように任意のコマンドを実行するようなことができず、コマンド実行できれば簡単なversionの更新もそのままでは実現できません *6 。解決策として、 bumpVersions を使い、正規表現で pyproject.toml と uv.lock の両方を同時に更新しています。なおbumpVersionsは オフィシャルドキュメントの最初にはpackageRulesの外の記述例があるのですが、マッチ表現と組み合わせpackageRulesの中に記述することもできます *7 。上記のサンプルではpackageRulesの外で記述していますが、我々はlockFileMaintenanceとそれ以外でbump up の方法を一部変えるため、 matchUpdateTypes を lockFileMaintenance とそれ以外で分離し、packageRulesの中に両方を記述しています。 // 応用例: lockFileMaintenanceと通常の更新を別々に記述する場合　（packageRulesの中に記述する) packageRules : [ 　　: { matchUpdateTypes : [ " lockFileMaintenance " ] , bumpVersions : [ .. ] } , { matchUpdateTypes : [ " major ", " minor ", ... ] , bumpVersions : [ .. ] } ] まとめ Dependabotの「依存ごとにPRが分割される」性質は、対象が増えるほど脆弱性対応の運用コストを押し上げる。 Renovateは packageRules を適切に設定することで、上記の運用コストの削減を行うことができる。 Python + uv の場合、 lockFileMaintenance のオプションとして指定できない exclude-newer については pyproject.toml に直接記述することで問題を回避できる。 Mend Renovate Appを利用する場合においても、bumpVersionsを利用することで pyproject.toml / uv.lock それぞれのversionの更新を実現できる。 We’re Hiring! 現在、タイミーでは、データサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ 　現在募集中のポジションは こちら です！ また、気軽な雰囲気での カジュアル面談 も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ 「話を聞きたい」と思われた方は、是非一度 カジュアル面談 でお話ししましょう！ References *1 : https://tech.timee.co.jp/entry/2024/10/15/101953 *2 : uv lock コマンド自体は --exclude-newer オプションを持つのですが、Renovateからこのオプションを2026年5月13日現在渡せていません。他のパッケージマネージャーに関しても同様でIssueとして登録されており、uvに関しては既にPRも出ているようですがリリースはまだされていません。 https://github.com/renovatebot/renovate/issues/41652 *3 : 0.10より古いバージョンのuvでも exclude-newerは記述できるのですが　”N days ago” のような相対的な評価がこのバージョンから記述できるようになりメンテナンスが非常に楽になっています。 https://github.com/astral-sh/uv/releases/tag/0.10.0 *4 : https://docs.cloud.google.com/iam/docs/troubleshooting-workload-identity-federation#error-google-subject-too-long *5 : 近日公開予定 *6 : uvを利用する場合、　pyproject.toml / uv.lock に記述された自身のversionの更新はuv version --bump patchのように実現できます。 *7 : https://docs.renovatebot.com/configuration-options/#bumpversions

本ブログは ONESTRUCTION 株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。GENIAC（Generative AI Accelerator Challenge）第 3 期の取り組みとして、ONESTRUCTION が AWS の Generative AI Innovation Center（以下、GenAIIC）から技術アドバイスを受けながら開発した、建設・BIM 特化型基盤モデル「Ishigaki-IDS」の開発事例をご紹介します。 背景 ONESTRUCTION 株式会社 （ note ） は、openBIM を中心に建設分野の課題解決に取り組む建設テックスタートアップです。建設業界の人手不足が続く中、設計・施工・維持管理の各段階で情報を一元的に扱える BIM（Building Information Modeling）の活用が、国レベルでも推進されています。一方で、BIM の導入や運用には専門知識が必要であり、習得コストの高さが普及の壁となっていました。 BIM モデル（IFC モデル）に対する情報の付与・照査の内容を定義する XML 形式の規格が IDS（Information Delivery Specifications）です。IDS の作成には、独自の文法に加えて IFC（Industry Foundation Classes）に関する知識やルールの理解が求められます。本プロジェクトでは、この専門知識の障壁を基盤モデルの力で下げ、BIM の専門家でなくても属性情報の確認と管理を行えるようにすることを目指しました。 課題 開発では主に 3 つの課題に直面しました。1 つ目はデータ不足です。IDS は 2024 年に公開された比較的新しい規格であり、建設業はもともと Web 上の公開情報が限られる領域です。金融・医療・法律のような主要ドメインでは数 B から数百 B トークン規模のコーパスが用いられることも珍しくない一方、IDS 領域ではそれに匹敵する量の公開データが存在しません。最新の Web コーパスを収集しても得られる情報はごく少量かつ浅いものにとどまり、大量のデータがなければモデルが IDS や関連情報を十分に学習できず、小手先のテクニックではカバーできない理解不足・精度不足に陥ります。2 つ目は数千規模の IFC 語彙の注入です。例えば「梁」は「IfcBeam」、「エアコン」は「IfcUnitaryEquipment」のように、建設領域の用語を IFC 上の語彙へ正確に対応付ける必要があります。従来は専門家が一つひとつ手作業で紐づけてきた知識を、モデル側に学習させなければなりません。3 つ目は IDS 独自文法の習得です。IDS は単なる XML ではなく、情報付与や確認の対象・記述内容に応じてタグ構造が変化する専用ルールを持ちます。繰り返しや専用タグの使い分けが求められるため、汎用の基盤モデルでは正確に生成することが難しい領域でした。 解決策 学習パイプライン 汎用言語性能とモデルサイズの選択肢を考慮し、Qwen3（8B / 14B / 32B）をベースに 3 段階の学習パイプラインで Ishigaki-IDS を開発しました。 継続事前学習（CPT）：Web コーパスに加え、社内のドメインエキスパートと協働して構築した大量の合成データを用い、IDS と IFC に関するドメイン知識をモデルに注入しました。具体的には、妥当性のある IDS を大量に生成するとともに、IDS 関連ドキュメントを多角的に説明する合成データセットを整備し、学習データの多くを合成で補いました。 教師ありファインチューニング（SFT）：CSV または自然言語による IDS 作成指示と、出力すべき IDS のペアデータでモデルを学習させ、IDS の「型」を安定して生成できるようにしました。SFT 単独では、XML タグの選択ミスや誤った属性値の付与など、それらしいが不正な生成が残ることが分かっており、後段の学習で補強する前提で設計しています。 検証可能な報酬による強化学習（RLVR）：国際標準団体 buildingSMART が提供する IDS-Audit-Tool を報酬関数に組み込みました。同ツールは XML としての整合性、IDS 形式としての妥当性、意味的な整合性の 3 観点を自動検証できるため、モデル自身が出力を試行し、機械的な正誤フィードバックを受けながら改善を重ねられます。RLVR は大量の教師データがなくても出力品質を洗練できるため、データが乏しい IDS 生成タスクとの相性が非常に良いと考えています。 アーキテクチャと評価 学習基盤は、Amazon EC2 P5en インスタンス（p5en.48xlarge × 2 ノード、NVIDIA H200 GPU 搭載）を AWS ParallelCluster でオーケストレーションし、学習データ・合成データ・チェックポイントは Amazon FSx for Lustre 上で高スループットに共有する構成としました。これにより、複数ノードでの分散学習と大容量データの並列アクセスを安定して回しています。評価軸は、社内の IDS 専門家と協働で独自ベンチマーク「IDS-Bench」として構築し、IFC バージョン × 建設分類（意匠／構造／設備／共通）× 言語（日本語／英語）× Implement／Structure／Content の多軸で、実業務に耐え得る精度を測定しました。 結果 開発した Ishigaki-IDS-8B と IDS-Bench は Hugging Face で公開しています。 Ishigaki-IDS-8B IDS-Bench 評価の結果、汎用フロンティアモデルでは十分に対応できないケースが多い一方、Ishigaki-IDS は IDS を適切に生成できることを確認しました。IDS が専門性の高い比較的新しい領域であるため、ドメイン特化モデルであれば解決可能な課題設定であったと考えられます。また、YaRN によるコンテキスト長スケーリングにも対応しており、最大 120k トークンほどの入出力でも問題なく生成できることを確認しました。buildingSMART と実施した実証実験でも、IDS の専門家・非専門家の双方から、業務への活用可能性や、曖昧な表現からでも意図通りの IDS を生成できる点について、ポジティブな反応を得ました。同時に、今後の改善や展開に繋がる多くの示唆もいただき、開発したモデルの実用性と意義を改めて確認できました。 IDS-Bench 評価結果。Ishigaki-IDS（8B / 14B / 32B）は XML 構造準拠・IDS 構造準拠・IDS 内容整合性準拠のいずれでも高いスコアを達成している一方、汎用フロンティアモデルでは低いスコアにとどまっている。 GenAIIC からの技術アドバイザリー ONESTRUCTION が建設・BIM ドメインの知見をもとに開発を主導し、GenAIIC から基盤モデル開発に関する技術アドバイザリーを Bi-weekly で受けながら進めました。開発の節目ごとに学習結果や評価データを持ち寄り、以下の 5 つの観点から GenAIIC の専門的な助言を得ています。 学習データ設計：IDS ドメインにおける合成データ活用と、CPT／SFT／RLVR 各段階のデータ配合・多様性設計 評価ベンチマーク：IFC／IDS 知識、構造化生成、汎用対話を多面的に評価する指標設計 学習段階と学習テクニック：CPT／SFT／RLVR の学習設計と、長文対応・報酬設計・構造化生成の最適化 学習インフラ：大規模分散学習における並列化設計と、スループット・安定性の最適化 実験結果の診断と次段の方向提示：学習・評価結果に基づく課題要因の特定と、次イテレーション方針の整理 これらの観点で「どの方向に振れば IDS 生成の精度と実用性が一段上がるか」を継続的に議論できたことが、データの乏しいニッチ領域でドメイン特化の基盤モデルを短期間で成立させる推進力となりました。 まとめと今後 専門家との協働・合成データ・検証ツール連動型の RLVR の組み合わせが、データが乏しい専門領域のドメイン特化モデル開発に有効であることを確認しました。本開発は、GenAIIC から技術アドバイスを継続的にいただきながら進められたことで、短期間でも高い品質の基盤モデルを完成させることができました。ONESTRUCTION では今後も、AWS との連携を活かしながら、AI を活用した建設 DX の推進に取り組んでまいります。 About the authors 日高洸陽 ONESTRUCTION AI戦略ユニット Manager。自社でのAI開発にとどまらず、自社製品へのAI活用や、クライアントとのAI領域の共同研究も行っています。最近生活の意思決定をAI Agentに預けるようになってきました。好きなSFは、エヴァンゲリオンとSteins Gateです。 金澤 亮 ONESTRUCTION AI戦略ユニット AIエンジニア。建設xAIの基盤モデル開発に取り組んでおり、GENIAC Cycle3ではIDS特化モデルIshigaki-IDSを開発。東京理科大学修士2年。好きなSFは、Steins Gateと三体です。 王　晨光 アマゾンウェブサービスジャパン合同会社 Applied Scientist。APJCのエンタープライズ企業に対し、LLM・VLM・MLMのトレーニングおよびエージェント導入の技術支援を担当しております。 姜　大原 アマゾンウェブサービスジャパン合同会社 Senior Deep Learning Architect。９年以上のAI・機械学習の業務経験を持ち、ビジネス環境でデータサイエンスの概念を適用することに熟練しており、現実世界の問題をモデル化し、問題を解決するためにデータを解釈し分析することに経験があります。 Angie Wang アマゾンウェブサービスジャパン合同会社 Sr. Generative AI Strategist。AWSのお客様を対象に、生成AIの活用戦略策定から本番導入までを支援しています。コンピュータサイエンスとベンチャーキャピタル投資のバックグラウンドを活かし、ビジネス戦略と技術実装の橋渡しを行っています。

はじめに こんにちは、株式会社タイミーでデータサイエンティストをしている藤井です。 普段は推薦システムの改善を担当しています。 早速ですが、皆さんは推薦モデルの改善実験を月に何本回せていますか？ 仮説を立てて、実装し、実験し、結果を整理し、次を考える。 1サイクル回すだけでも、相応の負荷がかかります。片手間でサイクル数を増やすのは簡単ではありません。 しかし、もし「仮説を立てる」から「結果を整理する」までを AI が担えるとしたら？ 実際に AI の案から改善が生まれています。しかも、人間が担うのは方針の選択、コードレビュー、実験の実行に絞れています。 では、実際にどれだけ回せて、どれだけ当たるのか？ 人間が思いつかない切り口は出てくるのか？ 私たちはそれを確かめるために、Claude Code の Skill 機能を使った半自動の実験プロセスを組み、実際に回してみましたので、紹介したいと思います。 先に結論 AI が出した改善案は 13件で、そのうち実験まで進めたのは 8件でした。 改善が確認できたのは 3件、横ばいが 2件、下落が 3件です。 打率だけを見ると突出して高いわけではありません。 ただ、人間が手を動かしたのは方針の選択、コードレビューと実験の実行だけで、それ以外は AI が担っています。通常業務と並行しながら、このサイクル数を回せたこと自体が、この取り組みのいちばんの成果でした。 モデル改善は 1回ごとの改善幅だけでなく、試行回数を増やせるかどうかが効いてくる領域です。 片手間で回せる仕組みがあれば、改善の累積速度が変わります。 解決したかった課題 AI に推薦モデルの改善案を聞くだけなら、チャットでもできます。 しかし、それを継続的な実験プロセスとして回そうとすると、運用上のボトルネックがいくつか出てきます。 長期記憶がない セッションが切れるたびに AI は過去の実験を忘れます。 同じ失敗を繰り返すリスクがあるだけでなく、過去の失敗を踏まえて次の方向を絞る、改善が出た方向を深掘りするといった、蓄積を活かした提案ができません。 コンテキストの無駄遣い 毎回生のログや大量のファイルを読ませると、トークンを消費するだけで、期待したほど精度も上がりません。 必要な情報を構造化して渡す仕組みがないと、コストだけが膨らみます。 これらを解決するために、Claude Code の Skill 機能を使って半自動の実験プロセスを組みました。 Skill と記憶の設計 このプロセスには 2種類の記憶があります。 knowledge（長期記憶） 過去の実験記録を構造化した Markdown ファイルとして蓄積するフォルダです。 各 Skill はここを読み、過去の試行を把握した状態から動きます。 実験結果はサマリとして圧縮されて書き戻されるので、サイクルを重ねてもトークン消費が膨らみにくい設計です。 scratch（作業記憶） サイクル途中の方針メモや実装の下書きなど、一時的な情報を置く場所です。 長期記憶に残すほどではないが、セッション内では参照したい情報がここに入ります。 また、AI のコンテキストウィンドウが圧縮された場合でも、ファイルとして残っていれば再読み込みで復元できるため、意図しないコンテキスト消失への備えにもなっています。 Skill Skill 自体には、参照すべきファイルパスやテーブル定義、コーディングルールに加えて、実験コストの前提、安全性チェックの観点、実装原則、過去実験との重複を避けるための自問自答リストなどを埋め込んでいます。 これにより、毎回ゼロから指示しなくても、各フェーズで必要な文脈と制約が揃った状態で AI が動けます。 また、長期記憶と作業記憶はリポジトリ上に存在するため、Cursor など別の AI ツールからも同じ情報を参照でき、Claude Code の提案を独立に検証することも可能です。 半自動実験プロセスの仕組み このプロセスは、上記の Skill と記憶の仕組みを使って構築しています。 1サイクルの流れ AI がテーブル定義やコーディングルールを確認する AI が過去の実験記録を読み、現状を把握する AI が次に試す改善案を複数提案する 人間が方針を選ぶ AI が実装する AI が変更の安全性を確認する AI が実施予定の内容を記録する 人間が実験を実行する AI が結果を記録に反映する 人間が手を動かすのは、方針の選択、コードレビュー、実験の実行だけです。 定義の確認、過去実験の整理、提案、実装、安全性チェック、記録は主に AI が担います。 実験結果 個別の実験内容の詳細は割愛し、ここでは改善幅の傾向のみを共有します。 13件の提案のうち、実験に進めなかった 5件を除いた 8件の結果です。 実験 主要な機械学習指標の改善幅（複数指標の範囲） A +2〜+7% B +0.5〜+3% C +1〜+3% D ±2%以内 E ±2%以内 F -3〜-7% G -3〜-6% H -35〜-20% 学び 以下はあくまで運用を通じた感想であり、厳密に検証された結論ではありません。 提案の方向性 変更が小さくなりがちな傾向がある。 AI に自走させると、実験結果の正確性を担保しやすい方向、つまり対照実験がしやすい最小限の変更に寄りやすい傾向がありました。 指示を入れると質が変わる。 「小さい改善ではなく構造ごと変える改善を考えてほしい」と明示的に伝えたところ、論文の知識を参照した鋭い提案が複数出てきました。AI の提案の質は、渡す制約や方向付けに強く依存します。 既存手法の非自明な応用が出てくる。 たとえば、DIN（Deep Interest Network）の target-aware attention を two-tower モデルに持ち込む提案がありました。two-tower では推論時に候補アイテムが不明なためそのまま適用できませんが、AI は「学習時だけ正例を attention query として使い、推論時はフォールバックする」という変形を考えました。この切り口自体、推薦チーム内では出ていなかったもので私たちには非自明でした。当然、学習と推論の不一致（train-serve skew）がリスクになりますが、提案自体にそのリスクと失敗した場合に何がわかるかが含まれていました。成功の保証はなく、失敗する可能性は高そうですが、失敗しても学びが得られる実験設計になっています。また、仮にこの方式がそのまま機能しなくても、事前学習フェーズでのみ target-aware に学習させるといった派生が考えられ、アイデアの種として意味のある提案でした。 壁打ち相手としては十分実用的だった。 厳密な比較をしたわけではありませんが、少なくとも今回の運用では、AI が出す提案は人間の壁打ち相手として十分実用的だと感じました。場面によっては、自分たちだけではすぐに出なかった切り口が出てくることもありました。 蓄積と学習 最も鋭い提案は最後に出てきた。 偶然の可能性はありますが、サイクルを重ねて過去実験の蓄積が増えたタイミングで、最も構造的な提案が出ています。蓄積が提案の質に寄与している可能性は否定できません。 過去の失敗を踏まえた推論が出てくる。 AI が提案を出す際に、「過去にこの実験は失敗したので、こういう可能性がある。だからこちらの方向を試してみましょう」といった推論のログを出してくることがよくありました。蓄積された記憶を参照しながら提案理由を組み立てている様子が見て取れます。 運用コスト 人間の作業時間の大半はバグ対応。 実験が問題なく動く回では、人間の仕事は方針を選び、コードをレビューし、実験を実行することに絞られます。一方でバグが出ると調査・修正・再実行に手を取られ、体感で人間の作業時間の 8〜9割はバグ起因でした。逆にいえば、バグが出た回を無理に立て直さず次の実験に進めば、手数自体はさらに増やせる可能性があります。実装にバグが出た実験案も、提案自体は knowledge に記録しておけば、AI のコーディング能力が向上した時点で低コストに再挑戦できます。 現時点でまだ分かっていないこと サンプルサイズが不足している。 この半自動改善プロセスを運用し始めたのは最近であり、実験数は 8 件です。ここから得られた傾向が一般化できるかは、まだわかりません。 長期記憶の効果は未検証。 長期記憶なしのフローと比較した実験は行っていません。蓄積が提案の質に寄与している可能性は示唆されますが、長期記憶が本当に効いているのか、それとも同じ品質の提案が記憶なしでも出るのかは、現時点では検証できていません。 まとめ このプロセスの価値は、AI が良い改善案を出すことそのものではなく、試行の回転数を上げられることにあります。 13件の提案から 8件を実験し、3件の改善を得る。個々の実験の改善幅は小さくても、改善を積み重ねれば累積的な効果は大きくなります。 つまり、モデル改善は打率ではなく打席数が効いてくる可能性が高い。この取り組みの価値は、試行錯誤を片手間でも継続して回せるようになる点にあります。 長期記憶の効果や AI の提案精度については、まだ言い切れることは多くありません。 ただ、少なくとも「AI に改善案を出させて回す」というサイクル自体は、実用的に機能しています。今後はサンプルを増やしながら、このプロセス自体の改善も続けていきます。 こうした推薦改善の試行錯誤や、評価・運用の仕組みづくりに興味がある方は、ぜひ以下もご覧ください。 We’re hiring! 現在、タイミーではデータサイエンスやエンジニアリングの分野で、共に成長し、革新を推し進めてくれる新たなチームメンバーを積極的に探しています！ データ | 採用情報 |株式会社タイミー また、気軽な雰囲気での カジュアル面談 も随時行っておりますので、ぜひお気軽にエントリーしてください。↓ hrmos.co hrmos.co hrmos.co Reference Skillを作成するにあたっては、Y Combinator の Garry Tan さんによる gstack リポジトリ（MITライセンス）を大いに参考にしました。 GitHub - garrytan/gstack: Use Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA · GitHub なお、本記事を書いている途中に、AI に継続的に作業させる方向の動きがいくつか出ていました。今回の取り組みと直接の関係はありませんが、同じ方向性の事例としてメモ的に置いておきます。 Automated Alignment Researchers: Using large language models to scale scalable oversight （Anthropic, 2026/04/14）― 9 体の Claude Opus 4.6 を自律的なアライメント研究者として走らせた実験。複数 AI に役割分担させて探索を回す、という方向の一例。 Introducing routines in Claude Code （Anthropic, 2026/04/14）― Claude Code にスケジュール実行や webhook トリガーで動かせる routines が追加。今回は Skill で手動起動していますが、こうした仕組みに載せれば定期的な提案・記録反映まで自動化できそうです。