2026 年 4 月 14 日、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」の採択企業向け勉強会を東京の AWS 目黒オフィスにて開催しました。勉強会では、 NVIDIA 加瀬 敬唯氏より、NVIDIA Robotics Solutions をご紹介いただきました。AWS からは、Physical AI 開発 「データ生成」 フェーズにおける AWS の活用方法と Remote AWS Develop Station のご紹介を行いました。本プログラムについては、過去のブログも参照してください。 「フィジカル AI 開発支援プログラム by AWS ジャパン」の応募受付を開始 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 「Physical AI on AWS 勉強会 #1」を開催しました NVIDIA Robotics Solutions のご紹介 Physical AI が今注目される背景と、NVIDIA のシミュレーション技術、そして、世界モデル Cosmos とヒューマノイド向け基盤モデル GR00T について、NVIDIA Robotics Solution Architect の 加瀬 敬唯氏よりご紹介いただきました。 Agentic AI の次のステップとして注目されているのが Physical AI です。Physical AI という言葉は、ヒューマノイドだけでなく、監視カメラ・自動運転・ドローン・工場ロボット等、物理世界を理解し行動する AI 全般を指します。従来の産業ロボットはルールベースで柵の中でしか動けませんが、Physical AI は経験から学習し非構造化環境で動作します。最大の課題はデータ不足で、実ロボットから取得できるデータには物理的限界があるため、シミュレーションによる大規模データ生成が鍵となっています。 Physical AI における最大の課題、データ不足に対して、NVIDIA は実世界におけるロボットの動きを再現しデータを取得できる、さまざまなシミュレーション技術を開発し、提供しています。オープンソースのロボットシミュレーター Isaac Sim を中核に、実環境を iPhone 撮影から 3D Gaussian Splatting で再構築する NeuDex、柔軟物シミュレーションに対応する次世代物理エンジン Newton を提供しています。学習フレームワーク Isaac Lab では強化学習・模倣学習に加え、VR デバイスによるシミュレーション内テレオペレーション（Isaac Teleop）も可能です。 Physical AI のモデル開発においては、シミュレーションによるデータ収集に加え、データの前処理・拡張（Augmentation）・品質評価といった一連のデータパイプラインの整備が不可欠です。NVIDIA からは、この工程を実行するツールやモデルとして、Cosmos Curator（動画キュレーション）、Cosmos Transfer（背景変換）、Cosmos Reason（Physical AI 特化 VLM）を提供しています。 シミュレーションやデータパイプラインに加え、NVIDIA が開発・公開しているモデルやデプロイ向けツールの紹介もありました。Cosmos v2 は、3500 万時間の動画データで学習された世界モデルで、入力映像の続きを予測・生成することでロボットの検証やベンチマークに活用できます。ヒューマノイド向け基盤モデル GR00T N は VLM（System 2）と 120Hz 制御の Diffusion Transformer（System 1）の 2 層構造です。デプロイ向けには GPU 最適化 ROS パッケージ群 Isaac ROS や、異種 GPU リソースを統合管理する OSMO も提供されています。 Physical AI 開発 「データ生成」 フェーズにおける AWS 活用 Physical AI の開発では 「データ生成・収集 → モデル学習 → モデル配信・推論」 の 3 ステップを繰り返します。この各ステップにおける、AWS から提供される NVIDIA GPU の選択肢と、データ生成フェーズにおける AWS の活用方法について、Solutions Architect の杉山より紹介しました。 Physical AI 開発の各フェーズに最適なインスタンスをその理由とともにご紹介しました。データ前処理において、 GPU が不要な場合は、Amazon EC2 C8/M8 等のコンピュート最適化インスタンス、シミュレーションにはレイトレーシングに特化した RT コアと大容量 VRAM を備えリアルタイムレンダリングが可能な Amazon EC2 G6e/G7e (NVIDIA L40S Tensor Core GPU / RTX PRO 6000 Blackwell Server Edition 搭載) インスタンスを推奨しています。学習フェーズでは、VRAM 消費が比較的軽い LoRA ファインチューニングにはAmazon EC2 G6e、大容量 VRAM が必須となるフルファインチューニングには Amazon EC2 P5 (NVIDIA H100 Tensor Core GPU 搭載)インスタンスが適しています。さらに事前学習から取り組む場合は、大規模な分散学習に対応した Amazon EC2 P5en/P6-B200 (NVIDIA H200 / B200 Tensor Core GPU 搭載) インスタンスがおすすめです。 Physical AI モデル開発に利用するデータ生成目的のシミュレーションは、Amazon EC2 上にインストールされた Issac Sim で実行します。そして、生成されたデータは、スケーラブルでコスト効率に優れたオブジェクトストレージである Amazon S3 への保存するのが一般的です。AWS の東京リージョンでは、Issac Sim のリモートデスクトップによるグラフィック操作を快適に行える Amazon EC2 G6e/G7e インスタンスがご利用いただけます。さらに、高性能リモートデスクトッププロトコルである Amazon DCV を利用することで、より快適なシミュレーション環境を実現できます。EC2 間の DCV 接続は無料です。 また、Kubernetes ベースのワークフローオーケストレーターである NVIDIA OSMO もご紹介しました。NVIDIA OSMO は、Physical AI の開発パイプラインである、 「データ生成・収集 → モデル学習 → モデル配信・推論」 を Kubernetes 上で定義・自動実行するオーケストレーターで、各ステージに最適な GPU リソースを自動で割り当てる点が特徴です。NVIDIA OSMO は AWS 上でも利用でき、G 系・P 系インスタンスの選択が自動最適化されるため、インスタンス選定の手間が軽減されます。 スライド資料 Remote AWS Develop Station (RADS)​ Physical AI 開発に便利な Amazon EC2 ベースの開発環境を​簡単に起動/接続/管理できるサンプル 「Remote AWS Develop Station (RADS)​」 を Solutions Architect の原田より、ご紹介しました。 RADS は Amazon EC2 ベースの開発環境を Web ポータル経由で提供するサンプルソリューションです。Isaac Sim や ROS を使ったシミュレーションワークロードを AWS 上で手軽に始められることを特徴としており、ユーザー自身の AWS 環境にデプロイして使うセルフマネージド環境です。接続方式は Amazon DCV（Web / ネイティブクライアント）、code-server（ブラウザ IDE）、SSH（Systems Manager 経由）の 3 種をサポートしています。Web ポータルからインスタンスタイプ・AMI・EBS サイズを選ぶだけで環境が立ち上がり、チームメンバーごとに独立した環境をセルフサービスで作成・停止・削除できます。 ゴールデンイメージには NVIDIA ドライバー・ROS・Isaac Sim に加え、Amazon Bedrock 連携の AI コーディングエージェント（Claude Code 等）もセットアップ済みで、約 5 分で開発を開始できます。 Physical AI 開発におけるユースケースとしては 2 つあります。1 つ目は Issac Sim などを用いたシミュレーションで、DCV 接続まで含めたセットアップ済み環境により、初めての方でもすぐに始められます。2 つ目は AI 駆動開発です。ローカルから分離されたサンドボックス環境として開発環境が起動するため、ローカルに保存された機密データの AI エージェントによる漏洩や改変を心配することなく、長時間エージェントを稼働させたり、大量のエージェントを並列で実行することができます。 利用開始方法もシンプルです。インフラは全て AWS Cloud Development Kit (AWS CDK, コードでクラウドインフラを定義・プロビジョニングするフレームワーク) で定義されており、2 つのコマンドを実行するだけで約 30 分〜 1 時間でデプロイが完了します。現在オープンソース公開に向けて準備中です。 今後のスケジュール 時期 内容 2026 年 5 月中旬 ロボット勉強会: AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 6 月 1 日 Community Meetup #1 – 登録ページは こちら 2026 年 6 月 25-26 日 Demo Day（中間報告会）at AWS Summit Tokyo 2026（幕張メッセ） 2026 年 7 月中旬 Community Meetup #2 2026 年 7 月下旬 最終成果報告会（AWS 麻布台ヒルズ オフィス 予定） おわりに 本勉強会では、NVIDIA の Robotics Solutions に加え、Physical AI 開発の各フェーズに最適な Amazon EC2 GPU インスタンスの選び方、そしてシミュレーション環境を手軽に構築できるサンプルソリューション RADS をご紹介し、AWS 環境でシミュレーションを実行するための実践的な知識を共有することができました。参加された企業の皆様が、既存の環境と合わせて活用いただくことで、より開発を加速させることができるよう、AWS ジャパンとしても引き続き支援をさせていただきます。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI の発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク : –  フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ） – 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました – 「Physical AI on AWS 勉強会 #1」を開催しました

製造業のお客様を支援しているソリューションアーキテクトの澤、大前、池田です。 2026 年 3 月 31 日に AWS 大阪オフィスにて「生成 AI ラウンドテーブル in 大阪」を開催しました。本記事ではイベントの概要と当日の様子をお伝えします。 開催の背景 製造業における生成 AI の活用は、ユースケース選定のフェーズを経て、実運用を目指したプロジェクトとして推進する企業が増えています。製造現場に眠る暗黙知を生成 AI で活用できる形式知へと変える取り組みや、生成 AI を搭載した自社製品の開発など、さまざまなユースケースで活用が進んでいます。 私たちソリューションアーキテクトが各社の技術支援を行う中で気づいたのは、扱う製品や事業領域は異なっても、直面している課題には多くの共通点があるということです。お客様からも「同じ業種で近しい取り組みを進める企業は、どのように課題へ向き合っているのか知りたい」という声を多くいただいていました。 お客様と AWS の 1 対 1 の技術支援だけでは届かない領域があります。ある企業の試行錯誤が、別の企業が抱える課題解決のヒントになりうる — お客様同士の知見がつながることで、課題解決はスケールし、さらには日本の製造業全体の競争力強化にもつながると私たちは考えました。そこで、企業間の対話を通じた相互学習の場として、ラウンドテーブル形式でのイベントを開催しました。 イベント概要 開催日： 2026 年 3 月 31 日（月）13:00 〜 18:00 + 懇親会 会場： AWS 大阪オフィス 26F 形式： クローズド・ラウンドテーブル形式（各社発表 + 質疑応答） 参加者数： 15 名 参加企業（順不同）： シャープ株式会社 ヤマハ株式会社 株式会社村田製作所 株式会社日立産業制御ソリューションズ コベルコシステム株式会社 東洋紡株式会社 大日本印刷株式会社 ダイキン工業株式会社 各社 30 分（発表 20 分 + 質疑 10 分）の持ち時間で自社の取り組みを共有するラウンドテーブル形式で実施しました。クローズドな場だからこそ踏み込んだ内容を共有でき、参加者全員が発表者であり聴講者でもあるため、双方向の議論が自然に生まれる構成です。 各社の発表テーマ 各社の発表では、生成 AI を実業務に適用する中で直面する課題と、まさに今取り組まれている実践知が共有されました。クローズドなイベントのため、各社の発表タイトルとご登壇者名のみの公開となりますが、以下でご紹介します。 暮らし、拡がる、SHARP の AI シャープ株式会社　Smart Appliances & Solutions 事業本部　Smart Life 事業統轄部　AI サービス推進部 中尾 祐介、早川 元基 家電製品への生成 AI 搭載における開発事例と技術的な課題が共有されました。 Yamaha Network 事業　AI の取り組み ヤマハ株式会社　PS 事業部商品開発部 クラウド開発 G　加藤 康之介 ネットワーク機器の運用・設計支援における AI 活用の段階的な取り組みが紹介されました。 AWS の生成 AI を活用した文書検索業務の効率化 ～その性能が期待を凌駕する～ 株式会社村田製作所　技術・事業開発本部 共通基盤技術センター マネージャー　徳本 直樹 少人数体制での社内ドキュメント検索システムの構築と運用の工夫が紹介されました。 OT における暗黙知と生成 AI 利用の取り組み ～業務インプロセス化と AI Agent～ 株式会社日立産業制御ソリューションズ　企画統括本部未来創造本部　梶山 義徳 株式会社⽇⽴産業制御ソリューションズ GenerativeAI センタ 佐塚 洋右 ベテランエンジニアの暗黙知を形式知化し AI で活用する取り組みが紹介されました。 1,300 人の現場知を AWS AI-DLC で価値へ昇華させる ～文化醸成とデリバリー標準の同期による組織変革の実践～ コベルコシステム株式会社　事業統括本部 技術推進部　前園 博文 全社的な AI 活用推進に向けた組織づくりと意識変革の取り組みが共有されました。 RAG × CPT でつくる現場特化 AI 東洋紡株式会社　TX・業務革新総括部　TX 推進部　坂倉 広也 製造現場特有の用語や表記ゆれへの対応に向けた技術的なアプローチが紹介されました。 DNP の生成 AI 活用に関する取り組み 大日本印刷株式会社ABセンター　佐藤 陽平 ドキュメントの構造化と社内への AI 展開の工夫が紹介されました。 ダイキン工業における生成 AI の取り組み ダイキン工業株式会社　電子システム事業部　森本 康太 自社ドメインに特化した AI の開発と社内業務支援への活用が紹介されました。 AWS セッションの紹介 エージェントの本番稼働を加速する AgentOps を AWS で実現 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 大前 遼、澤 亮太 各社の発表を通じて、RAG による社内ナレッジ検索から一歩進み、AI エージェントを業務に組み込むプロジェクトが多くの企業で始まっていることが見えてきました。一方で、エージェントの本番運用における評価や監視は、業界全体としてまだベストプラクティスが確立されていない領域です。 本セッションでは、エージェントの構築パターン（Single Agent、Tool-Augmented、Multi Agent など）に応じて評価すべき観点が異なる点を整理し、Amazon 社内での実践をもとにした Define → Evaluate → Share → Monitor の 4 ステップの評価フレームワークと、その実現を支える Amazon Bedrock AgentCore を紹介しました。 詳細は AWS ブログ「 Evaluating AI agents: Real-world lessons from building agentic systems at Amazon 」でも紹介されています。 参加者からは「AI エージェントシステムの観点を体系的にまとめていただいてわかりやすかった」「応答の評価や運用時の監視周りは既存システムでも課題に上がっているため、検討していきたい」といった声をいただいています。 「ここだけの話」はどうつながったのか？ 各社の発表では普段は表に出ない課題や試行錯誤が率直に語られました。質疑応答では「うちも同じ課題を抱えている」「こういうアプローチで解決した」といったやり取りが自然と生まれ、予定時間を超えて議論が続くセッションもありました。まさに、各社の「ここだけの話」がつながり、新たな解決のヒントが生まれていました。  「作ったツールを社内で使ってもらえない」問題 技術的に動くものは作れても、現場に定着しないという悩みは多くの企業に共通していました。議論では「トップダウンで広げるべきか、現場起点のボトムアップが良いか」「推進チームと現場のエンゲージメントをどう設計するか」「評価指標をどこに置くか（利用率か、業務インパクトか）」といった論点が交わされ、各社が実際に試してうまくいった/いかなかった施策が具体的に共有されました。  少人数で AI 推進を回すリアルな状況 「専任チームは数名、兼任メンバーも含めて十数名」という体制で全社展開を進める企業が多く、リソース制約の中で何を優先し、何を諦めるかが共通のテーマでした。内製と外部活用の線引き、社内啓発にどこまで時間を割くか、小さく始めて実績を作る進め方など、現実的なトレードオフについての議論が続きました。 製造業特有のデータをどう扱うか 図面、仕様書、現場のベテランの暗黙知、設計ノウハウ — 製造業ならではの非構造化・機密性の高いデータをどう生成 AI で活用するかは、各社が直面している共通課題でした。RAG の精度を現場要件まで引き上げる工夫、用語ゆれへの対処、セキュリティを担保した上での社内展開の設計など、「製造業だからこそ」の踏み込んだ技術論が飛び交いました。 扱う製品や事業領域は違えど、共通の悩みが次々と浮かび上がったのも印象的でした。 懇親会でも議論の熱は冷めず、セッション中には踏み込みきれなかった技術的な詳細について、あちこちで話の輪が広がっていました。 アンケート結果と参加者の声 「つながることで課題解決を加速する」というイベントの狙いが実現できたことは、参加者の声からも伝わってきます。 「生成 AI 活用に関するネット上の情報とは違う、各社の取り組みの生の声を聴くことができてとても勉強になった」 「独自モデルの開発が意外に多いことに驚いた。AI とアジャイルの親和性も新たな気づきだった」 「どう使ってもらうかという観点や、社内に生成 AI を広げていくやり方なども参考になった」 「難しい課題に挑戦されているが、目的が明確で地に足がついており、とても参考になった」 「取り組みを進めることができる人員が限られている中で、各社の背景や目的観、具体的なツールの話が特に参考になった」 「ラウンドテーブルは質問もたくさんできて大変有意義だった」 「自分だけが苦労しているのかと思っていたが、各社同じ課題に向き合っていることがわかり、ここに来てやろうという決断を持てた」 おわりに 今回のラウンドテーブルを通じて、 お客様だからこそ応えられるお客様の悩みがある ということ、そしてお客様同士の対話が課題解決を加速させるということを、改めて実感しました。アンケートでの次回参加希望 100% という結果が物語っています。 改めて、参加いただいた皆様に御礼申し上げます。AWS では今後もこうした企業間の対話の場を企画してまいります。生成 AI の活用でお悩みの方は、ぜひ担当のソリューションアーキテクトにご相談ください。 著者について 澤 亮太 (Ryota Sawa) 製造業のお客様を担当するソリューションアーキテクトです。前職では AI、機械学習開発へ従事しており、現在も最新技術の導入・活用に悩む企業様への技術支援も行っております。 前職では AI 、機械学習を用いた開発に従事しており、現在も同様の技術活用にお悩みのお客様へも技術支援しております。好きなサービスは Amazon Bedrock AgentCore です。最近はゴルフへの熱が再燃しており、コースに立つとアーキテクチャより打数が気になります。 大前 遼 (Ryo Omae) AWS Japan のソリューションアーキテクトとして製造業のお客様を中心に、クラウド活用の技術支援を行っています。特に 機械学習・生成 AI 領域を得意とし、お客様のビジネス課題をテクノロジーの力で解決するお手伝いをしています。好きな AWS サービスは Amazon SageMaker, Amazon Bedrock で、新しい基盤モデルが出たらすぐに触っています。休日はバイクにまたがってツーリングへ行くのが好きで、風を感じながら走る時間が、最高のリフレッシュです。 池田 敬之 (Takayuki Ikeda) 関西の製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。好きなサービスは Amazon Bedrock AgentCore と Strands Agentsです。休日はキックボクシングで汗を流した後、愛犬と散歩といったコンボで英気を養うのが定番コースです。

はじめに こんにちは、株式会社タイミーでデータサイエンティストをしている藤井です。 普段は推薦システムの改善を担当しています。 早速ですが、皆さんは推薦モデルの改善実験を月に何本回せていますか？ 仮説を立てて、実装し、実験し、結果を整理し、次を考える。 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 で手動起動していますが、こうした仕組みに載せれば定期的な提案・記録反映まで自動化できそうです。