はじめに 株式会社エブリーは、2026年9月に開催される DroidKaigi 2026 にゴールドスポンサーとして協賛いたします。「エンジニアが主役のAndroidカンファレンス」である本イベントは、2026年9月1日（火）から3日（木）にかけて ベルサール渋谷ガーデン で開催されます。 項目 詳細情報 イベント名称 DroidKaigi 2026 開催日程 2026年9月1日（火）〜 9月3日（木） 会場 ベルサール渋谷ガーデン（東京都渋谷区南平台町） スポンサーランク ゴールドスポンサー ブース出展日程 2026年9月2日（水）〜 9月3日（木）の2日間 エブリーはこれまでも、 Go Conference 2025におけるPlatinum "Go"ld スポンサー や、 TSKaigi 2026におけるゴールドスポンサー としての参加など、技術コミュニティを積極的に応援してきました。今回のDroidKaigiへの協賛も、自社の開発現場で得られた知見をコミュニティに還元し、エンジニアの皆様と共に成長していくための大切な取り組みの一環です。 tech.every.tv tech.every.tv ブース出展：「AI時代！どこまで越境したいですか？」 9月2日および3日に出展するエブリーのブースでは、「AI時代！どこまで越境したいですか？」をテーマにした参加型のアンケートボードを設置します。Android開発をベースにしつつ、バックエンドやPdM、データサイエンスといった他の領域へどのようにスキルを広げていきたいか、皆様のリアルな声をお聞かせください。 また、 エブリーの公式X（旧Twitter） をフォローしていただいた方には、ハズレなしのくじ引きをご用意しています。お鍋や計量スプーン、まな板など、デリッシュキッチンならではの実用的なキッチングッズをプレゼントしますので、ぜひお立ち寄りください。 TSkaigiでもお配りした景品例 事後レポートを公開予定です！ イベント終了後の9月3日（木）には、 every Tech Blog にて最速事後レポートを公開する予定です。開発部メンバーによるセッションの感想や、アンケートボード「AI時代の越境」の集計結果など、現場のリアルな熱量をお届けします。過去のイベント協賛時と同様に、オフラインで得られた知見をいち早くコミュニティに共有していきます。 アフターパーティーも開催します！ さらに、 DroidKaigi & iOSDC After Talks Night 2026 を、ゆめみ、フェンリル、Yappli、WealthNavi、セーフィー、エブリーの6社合同で開催いたします！なお、今回はiOSDC Japan 2026のアフターパーティーも兼ねているので、AndroidエンジニアだけでなくiOSエンジニアの方も交えて、プラットフォームの垣根を越えた活発な技術交流や情報交換をお楽しみいただけます。両カンファレンスの熱気をそのままに、各社によるLTセッションや懇親会をご用意しております。 項目 詳細情報 開催日時 2026年10月2日（金） 19:00 ~ 21:00 開催場所 東京都港区三田一丁目4番1号 住友不動産麻布十番ビル 開催形態 オフライン / オンライン コンテンツ 各社のAndroid & iOSに関するセッション / 懇親会 詳細や参加登録につきましては、以下のリンクよりご確認ください。 yumemi.connpass.com おわりに 株式会社エブリーでは、技術コミュニティの発展を応援するとともに、開発現場で得た知見や知恵を共有し合う文化を大切にしています。今回の DroidKaigi 2026 への協賛を通じて、多くのエンジニアの皆様と技術やキャリアに関するお話ができることを楽しみにしています。 当日のブースでは、デリッシュキッチンをはじめとするプロダクト開発のリアルな話や技術スタック、AI時代におけるエンジニアの挑戦に関する雑談・ご質問も大歓迎です。「ちょっとノベルティのくじ引きをしてみたい」「エンジニアと軽く話してみたい」といった軽い気持ちで構いませんので、ぜひ気軽にエブリーのブースへ足をお運びください。 DroidKaigi 2026 の会場、そして10月のアフターパーティーで、皆様とお会いできることをチーム一同、心より楽しみにお待ちしております！

本記事は 2026 年 8 月 26 日 に公開された「 AWS and DuckLabs: Building the future of analytics together 」を翻訳したものです。 本日、 Amazon が DuckLabs を買収する最終契約を締結したこと を発表します。DuckLabs はオープンソースの分析データベース DuckDB を開発する、アムステルダム拠点の企業です。取引は通常のクロージング条件が満たされ次第、まもなく完了する見込みです。DuckDB を開発し DuckLabs を共同創業した Hannes Mühleisen と Mark Raasveldt は、AWS の一員として引き続きチームとオープンソースプロジェクトの技術的方向性を率いていきます。DuckDB オープンソースプロジェクトも引き続き DuckLabs チームが推進し、独立した Foundation (DuckDB を統括する非営利団体) の下でオープンソースとして維持され、現在と同様に MIT ライセンスで利用可能です ( DuckLabs ブログ を参照)。 データは常に企業の中核となる資産であり、差別化の源泉でした。組織が自社のデータで推論をカスタマイズし AI エージェントを構築する今、その重要性はこれまで以上に高まっています。AWS は 20 年間、データの最前線を切り拓いてきました。あらゆるビジネスにデータレイクをもたらした Amazon S3 のローンチに始まり、初のクラウド分析サービスである Amazon EMR、初のクラウドデータウェアハウスである Amazon Redshift、さらに Athena や Glue ETL などで導入してきた数々の機能があります。S3 Tables で直接利用できる Apache Iceberg 機能、データレイク内のベクトルストレージ、新しく最適化された Graviton ベースの Redshift クラスターなど、AWS のお客様のためにデータ領域での革新を続けています。 DuckDB もまた、世界のデータの扱い方を変える最前線に立ってきました。Hannes と Mark は、Python を生み出したことでも知られるオランダの国立研究機関 Centrum Wiskunde & Informatica (CWI) 在籍中に DuckDB を開発しました。DuckDB の創業者たちは、従来のデータベースや Spark のような分析エンジンが超大規模データ処理のパフォーマンスに注力する一方で、多くのお客様が SQL 分析で行う作業の中心を占める、より小さなサイズのデータクエリに効果的に「スケールダウン」する手段を持っていないと気づきました。 DuckDB が取り組んだのは、今日のデータクエリの 90% 以上を占める、分析やダッシュボード作成で 1 テラバイト以下のデータを扱うクエリを圧倒的な速度で処理する課題です。DuckDB のアーキテクチャは「日常的な SQL クエリを超高速にする」という前提に基づいており、他のアプリケーションのインプロセスで動作するため、アプリケーションとのデータのやり取りが簡単かつ高速になります。DuckDB はベクトル化実行によって大きなパフォーマンス向上を実現しています。 SELECT * FROM table のような単純な文の実行に重たいコンパイラを必要としないためです。日常的なクエリでうまく機能する仕組みは、当然ながらエージェントでもうまく機能します。エージェントはデータと対話するときに人間とよく似た振る舞いをするからです。軽く探ってみる。試してみる。本当にやりたいことを見極める前に、小さなデータセットで探索的な分析を行う。DuckDB は AI エージェントが使うのに自然と最適化された形になっています。学術プロジェクトとして始まったものが、今ではデータエンジニアリング、データサイエンス、分析、そして AI エージェントに至るまで、使いやすさと純粋なパフォーマンスの点で広く採用されています。私たちは、1 テラバイト以下の日常的なクエリにおける DuckDB の強みを、エクサバイト超のエンタープライズ規模で実績のある S3 と、数百テラバイトからペタバイト級のデータで分析を支える Redshift、Athena、EMR、Glue-ETL、SageMaker プラットフォームなどの AWS 分析サービスと組み合わせる計画です。AWS の Distinguished Engineer である Andy Warfield が、Werner Vogels の All Things Distributed ブログで DuckDB and the Changing Physics of Analytics について語っています。 お客様は現在、DuckDB を AWS サービスと組み合わせて活用しており、その速度とシンプルさを高く評価しています。たとえば DuckDB は現在、ローカルや S3 などのクラウドストレージに保存された Parquet、CSV、JSON といった外部ファイルに対して SQL を直接実行し、他に類を見ないパフォーマンスと大幅に低いコストを実現しています。 Allen Institute の Scientific Computing 担当 Executive Director である David Feng 氏は次のように述べています。 「Allen Institute は、生物学における最大級の問いに大規模に取り組むことで、より健康な世界のための科学を加速しています。そこには、大規模でマルチモーダルなデータの広範な分析が伴います。私たちは 2025 年に数テラバイトの科学データを分析するために DuckDB を使い始め、大変気に入っています。神経生理学および行動データのリアルタイム品質管理と分析のためにデータを S3 に保存しており、これは次のデータ取得を進める上で欠かせません。数分かかっていたクエリが 1 秒未満で返るようになり、データとのまったく新しい対話方法が可能になりました。」DuckDB は AWS Lambda 関数のインプロセスで実行することもできます。 DuckDB アプリケーションが AWS で最高のパフォーマンスを発揮するようにし、DuckDB と AWS のビルディングブロックサービスとの深い統合に引き続き投資していきます。 AWS 自身のインフラでも DuckDB を活用しています。Amazon Quick は独自のダッシュボードエンジンのパフォーマンスを強化するにあたり、S3 Tables のデータへのクエリに DuckDB を選びました。Quick チームは、DuckDB エンジンが CPU 数に応じてスムーズにスケールし、単一のライブラリを Quick の内部コントロールプレーンサブシステムに簡単に組み込めることを確認しました。2025 年 10 月に Quick を提供開始して以来、DuckDB との統合と最適化を組み込んだ独自の Quick クエリエンジンで 25 億件を超えるクエリを処理してきました。DuckDB との統合と最適化により、Amazon Quick は平均クエリレイテンシーを 30% 削減できました。データと分析領域の他の AWS サービスでも、DuckDB のパフォーマンスとシンプルさをどのように取り込めるかを検討していきます。 DuckLabs と AWS が、アプリケーション、データエンジニア、AI のためにデータの最前線をどう再定義していくのか、そしてお客様の現状に寄り添いながら AWS の中で DuckDB のイノベーションの恩恵をどのように届けていくのか。続報にご期待ください。 著者について Mai-Lan Tomsen Bukovec AWS の Technology Vice President である Mai-Lan Tomsen Bukovec は、デジタル変革、ビジネス分析、機械学習、生成 AI、次世代のカスタマーエクスペリエンスにおいて数百万人の AWS のお客様が信頼を寄せる Amazon のクラウドデータサービスを率いています。テクノロジー業界で 25 年以上の経験を持ち、クラウド技術を活用してビジネスを変革するお客様の取り組みを支援するパイオニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

はじめに こんにちは、データサイエンス部の大川（ @o_tomo03 ）です。私たちは、WEARにおける「似合う」をユーザーに届けるため、LLMやマルチモーダルAIを活用してコーディネートの特徴抽出や似合うに関する独自の判定処理のR&Dを行っています。 その中核を担うのが、全身のコーディネート画像から特徴を抽出するVLM（Vision Language Model）のプロンプトです。このプロンプトの精度を上げようとすると、地道な手作業のチューニングが延々と続きます。みなさんも一度は経験したことがあるのではないでしょうか？ 当初、私が実際に回していたのは次のようなループでした。 LLMに推論させ、正解データと突き合わせる 間違えたサンプルを開き、LLMの出力・判断理由・画像を分析する 「なぜ間違えたか」を考え、プロンプトの定義や例示を書き直す もう一度評価し、評価指標が上がったか確かめる 効いた／悪化した施策を記録し、次に活かす この「 失敗を見る → 直す → 再評価する 」を、ファッション特徴の数（例：アイテム、素材、柄など）だけ繰り返します。1つのプロジェクトのチューニングに、数週間を費やすこともありました。 以前、関連する取り組みとして「LLMの構造化出力エラーを削減する」という記事を公開しました 1 。あちらは 出力の正しさ （定義外の値を出さないこと）を、バリデーションとエラーフィードバックで守る話でした。本記事はその一歩先、 "精度そのもの"を上げるチューニングのループごと、AIエージェント（Claude Code）に任せられないか という仮説です。 本記事で扱う問いはシンプルです。 人間が手で回していたプロンプトチューニングのプロセスを、Claude Code の自律ループで 再現 できるか。人と同等の精度に、どれだけ短い時間で到達できるか。 ポイントは、新しい最適化アルゴリズムを発明することではなく、 人の作業手順をそのまま機械へ移す ことです。 目次 はじめに 目次 サマリー 背景 ── ハーネスとループエンジニアリング アイデア ── 人のチューニングループを分解する reasoningを勾配として使う システム設計 ── 人の動きを sub-agent に割り当てる 実験セットアップ 対象タスク 推論・最適化モデル 実験設定 実験結果 実験結果1 ── 人の動きを再現できたか（T1） 工数：どれだけ短縮したか 実験結果2 ── スキーマ構造が異なる他タスクでも汎化するか（T1~T3） 実験結果3 ── reasoning は本当に効くのか（ablation、T1のみ） 実践から得た知見 エージェント設計は「自分がどう解いていたか」の移植から始める 過学習とプロンプト肥大化に注意する コストに注意する 今後の展望 まとめ おわりに サマリー 人手のプロンプトチューニング（失敗分析→書き換え→再評価）を、Claude Codeのsub-agentで 役割ごとに分解して自動化 した（ /tune スキル）。 スキーマ構造が異なる 3タスク（T1~T3） で、特徴の定義文のみを列挙した初期プロンプトを出発点に自動最適化を実行。 結果： 精度：T1では自動最適化後のF1が人手チューニングをN=1ながら 同等以上の水準 を達成（train +0.024、test +0.017）。 工数：全体評価サイクルの工数を人手約3.5週間から約1週間に短縮。 汎化：スキーマ構造が異なるT1~T3で適応可能性を確認。 仕組みの核心：LLMの推論時にファッション特徴と 判断理由（reasoning） を合わせて構造化出力している。 reasoningを 「次にどう直すか」の信号（≒勾配） として使い、参照あり／なしのablationでその寄与を検証した。 背景 ── ハーネスとループエンジニアリング 近年、LLM活用の関心は「良いプロンプトを書く」から一段上がり、 エージェントを動かす仕組みそのものの設計 に移ってきました。 ハーネス（harness） ：モデル本体を除いた周辺すべて。システムプロンプト、ツール、権限、コンテキスト管理、検証ループ、ログなど。「Agent = モデル + ハーネス」のモデル以外の側と覚えれば直感的。 ループエンジニアリング（loop engineering） ：ハーネスを停止条件やスケジューラで 自律的に回し続ける よう設計する、一段上の制御プレーン。「自分でClaudeにプロンプトを出す」のをやめ、 「Claudeへプロンプトを投げるループ」を設計する という発想の転換がコア。 本記事でやるのは、まさにこのループエンジニアリングの実践例です。用語の整理や系譜の詳細は割愛します 2 。 アイデア ── 人のチューニングループを分解する 自動化のため、まず取り組んだのは 自分が手で行っていた作業を要素へ分解する ことでした。以下の表の（1）〜（5）が、そのまま /tune のsub-agentに対応します。 人手ループのステップ 人が何をしていたか 自動ループの担当 （1）失敗を見る 誤答サンプルのLLM出力・ reasoning ・画像を眺める analyzer （2）原因を考える 定義と判断のズレ・過検出/見落としを特定 planner （3）プロンプトを直す 定義補足・例示追加・曖昧さ排除 improver （4）再評価する 評価を回してF1を確認 run_eval.py （5）良し悪しを覚える 「前にこれで悪化した」を記憶し次に活かす retrospector reasoningを勾配として使う （1）で人が行っていたのは、 LLMの「なぜそう判断したか（reasoning）」を読んで、次にプロンプトをどちらへ動かすかを決める ことです。機械学習の言葉に置き換えると次のようになります。 F1スコア ≒ 損失 （どれだけ外したか、スカラー） reasoning ≒ 勾配 （どの方向に直せば良くなるか） つまりこのループは、 プロンプトという"パラメータ"を、reasoningという"勾配"で更新する勾配降下 とみなせます。同じ着想はTextGrad 3 やOPRO 4 / APO 5 にも見られ、LLMの出力を自己改善の信号として使う研究の一例です。 システム設計 ── 人の動きを sub-agent に割り当てる /tune は1イテレーションで次のフェーズを回します。 スキルのディレクトリ構成は次のとおりです。 .claude/skills/tune/ SKILL.md # オーケストレーター：ループ制御に徹し、処理は sub-agent に委譲 agents/ analyzer.md #（1）失敗分析 planner.md #（2）改善計画 improver.md #（3）プロンプト改善 retrospector.md #（5）振り返り：DO/DON'T を lessons.md に追記 ... references/ optimization-policy.md # 採用/棄却・停止条件（単一真実源） prompt-design-strategies.md # プロンプト改善パターン集（Gemini公式ドキュメント） ... scripts/ ... 設計上のポイントは4つです。 SKILL.md をオーケストレーターとする ： SKILL.md を「全体フローの制御」のみに徹し、専門的な処理は外部（ agents/ ）へ委譲している。わずか115行で記述。 optimization-policy.md を単一真実源とする ：改善の優先順位、採用/棄却の判定、停止条件を1ファイルに集約。すべてのsub-agentがこの方針に従うよう設計している。 lessons.md ＝ 人の記憶 ：各イテレーション後に retrospector がDO（効いた施策）/ DON'T（悪化させた施策）を追記している。人手でチューニングしていると徐々に知見が溜まっていくので、そのメモリー機能を再現している。 prompt-design-strategies.md ：Gemini公式のプロンプト改善手法 6 の要約を常に参照させることで、改善手法の選択を体系的に行えるようにしている。 なお、実験パラメータ（モデル、LLMパラメータ、最大イテレーション、データセット、実験ログ保存先など）は experiment_config.json に集約しています。実行前にユーザーが確認して自動最適化を開始する仕組みです。 実験セットアップ 対象タスク 全身のコーディネート画像から複数の特徴を抽出するタスクです。例えばT1では、アイテム・着こなし・サイズ感などの特徴を1つのプロンプトでまとめて抽出します。特徴の性質に応じて2値分類や多クラス分類などを使い分けています。 タスク 特徴の種類 特徴数 データ規模 人手チューニング比較 T1 アイテム・着こなし・サイズ感など 数十程度 数百件規模 あり T2 トップス・アウター・バッグなどの着用アイテム 数十〜百近く 数千件規模 なし T3 素材・柄・装飾・シルエットなど 数十〜百近く 数千件規模 なし 推論・最適化モデル 推論モデルにはGemini、最適化モデルにはClaude Codeの claude-sonnet-4-6 を使用しています。タスクによって推論モデルが異なります。 タスク model_id temperature thinking_level max_output_tokens max_iter T1 gemini-2.5-flash-lite 0.0 null 8192 10 T2 gemini-3.1-flash-lite 1.0 MINIMAL 8192 10 T3 gemini-3.1-flash-lite 1.0 MINIMAL 8192 10 実験設定 今回の実験では、以下の3軸で自動最適化を評価します。 実験1 — 人の動きを再現できたか（T1） ：プロンプトエンジニアリングを一切行わずに、特徴の定義文のみを列挙した初期プロンプトを出発点に自動最適化を実行します。これまでの人手チューニング結果（F1: train 0.817 / test 0.847）と比較し、精度が人手を上回るか、工数はどれだけ短縮されるかを確認します。 実験2 — スキーマが異なる他タスクでも汎化するか（T1~T3） ：同様の手順でT2・T3にも適用し、初期からの改善幅とtestへの汎化を確認することで、ループの適用可能性を検証します。 実験3 — reasoning は本当に効くのか（ablation、T1のみ） ：「reasoningを勾配として使う」という設計の妥当性を検証します。reasoningをClaudeに見せる条件A（ /tune ）と見せない条件B（ /tune-no-reasoning ）の2条件をT1で比較します。 各実験に共通する設定は以下のとおりです。 評価指標 ： feature F1 （特徴ごとのF1、例：サイズ感）と leaf F1 （各ラベルのF1、例：「サイズ感=オーバーサイズ」）のマクロ平均。leaf F1はより細粒度で、本実験の主評価指標とする。 停止条件 ：以下のいずれかを最初に満たした時点でループを停止する。 （1）全feature・leaf F1 ≥ 0.7（目標達成） （2）最大10イテレーション到達 （3）3イテレーション連続で収束（leaf F1改善幅＜0.005かつleaf改善数が不変） 実験結果 実験結果1 ── 人の動きを再現できたか（T1） T1について、これまでの人手チューニング結果と自動最適化後のleaf F1スコアを比較します。 タスク データ 人手チューニング leaf F1 自動最適化後 leaf F1 T1 train 0.8165 0.8403 （iter3） test 0.8473 0.8641 （iter3） 所見 ：train +0.024、test +0.017で自動が人手を上回りました。trainでの改善はtestにも汎化しており、feature F1が0.7未満のfeatureを6→2に削減しました。 工数：どれだけ短縮したか 工数の比較は2つの粒度で行いました。 チューニングサイクル（1回） はエンジニアがleaf F1を改善し、ドメインエキスパートへ定性評価依頼が出せる状態にするまでの工程です（ /tune が自動化する範囲）。 全体評価サイクル（最大3回） は「チューニング → ドメインエキスパートによる定性評価 → フィードバック反映」を1セットとし最大3回繰り返すサイクルです。 人手チューニング 自動最適化 速度比 チューニングサイクル（1回） 約6時間 約2.5時間 約2.4倍速 全体評価サイクル（最大3回） 約3.5週間 約1週間 約3.5倍速 人的介在 常時 config確認のみ — イテレーション数（全体評価サイクル） 30（プロンプトバージョン） 10~20 — ※ 全体評価サイクルの速度比がチューニングサイクル1回の速度比を上回るのは、自動化によりイテレーション数が減少したことに加え、ドメインエキスパートとのスケジューリングや待機時間が発生するためです。数値はいずれも実測値です。 実験結果2 ── スキーマ構造が異なる他タスクでも汎化するか（T1~T3） T1~T3のスキーマ構造が異なる3タスクで汎化性能を検証した結果を示します。 タスク データ 初期プロンプト leaf F1 自動最適化後 leaf F1 改善量 T1 train 0.7916 0.8403 （iter3） +0.049（+6.2％） test 0.7842 0.8641 +0.080（+10.2％） T2 train 0.8498 0.9143 （iter9） +0.065（+7.6％） test 0.8481 0.9184 +0.070（+8.3％） T3 train 0.5683 0.7633 （iter10） +0.195（+34.3％） test 0.8721 0.8794 +0.007（+0.8％） 所見 ：3タスクすべてでleaf F1が向上しました。T3のtrain改善幅（+34.3％）は最大ですが、train初期値（0.57）が他タスクより低くtest初期値（0.87）と乖離しており、改善幅はその初期値の低さを反映しています。これはtrain側に初期プロンプトが苦手とする難しいサンプルが偏っていたためと解釈しています。いずれのタスクでもtestでの劣化はなく、feature F1が0.7未満のfeature数はT1で6→2、T3で5→1に削減しました。 実験結果3 ── reasoning は本当に効くのか（ablation、T1のみ） 「reasoningを勾配として使う」という主張の裏を取るため、ablationを実施しました。最適化モデルにGeminiのreasoningを 見せる条件（A ＝ /tune ）と見せない条件（B ＝ /tune-no-reasoning ） の2条件を比較しています。 iter別 leaf F1 推移（T1 / train・test） iter A train A test B train B test 1（初期） 0.7916 0.7842 0.7834 0.8005 2 0.8368 0.8635 0.7906 0.7990 3 0.8403 ← A best 0.8641 ← A test best 0.8239 0.8494 ← B test best 4 0.8359 0.8052 0.8354 0.8124 5 0.8377 0.8346 0.8256 0.7803 6 0.8341 0.8318 0.8299 0.8472 7 0.8385 0.8081 0.8513 ← B best 0.7983（ 低下 ） 8 0.8377 0.8338 0.8202 0.7523 9 0.8296 0.7720 0.8144 0.7896 10 0.8376 0.8467 0.8152 0.8137 所見 ：trainではB（no-reasoning）のbest（0.8513, iter7）がA（0.8403, iter3）を +0.011上回りました。しかし、testではAが 0.8641と汎化した 一方、Bは 0.7983に落ち込みtrain過適合 が明らかになりました。画像情報に加えreasoningを参照することで、VLMの思考をより詳細に把握でき、汎化しやすいプロンプト探索を助けていると考えます。 人手チューニングとの関係 ：人手側はGeminiのreasoningと画像を参照しながら、約30イテレーションの試行履歴とドメイン知見も活用できました。 情報量・試行回数の両面で優位だったにもかかわらず 、条件Aの自動ループが同等以上の水準（実験結果1）に到達したことは、reasoningを活用するループが人間の作業を代替しうることを示唆します。 実践から得た知見 エージェント設計は「自分がどう解いていたか」の移植から始める エージェント設計は、いきなりアーキテクチャを考えるのではなく、 自分がそのタスクをどう解いていたかを細分化し、そのままエージェントに乗せる のが効くことを学びました。また、最初からこの設計だったわけではなく、回しながら lessons.md や prompt-design-strategies.md を足していき徐々に今の形になりました。完璧な設計を最初から目指すのではなく、まず小さいPoCを回して改善していく方が結果的に早いと思います。 過学習とプロンプト肥大化に注意する 過学習は最も注意した点です。ループごとに定量的な精度が向上する一方で、 プロンプトは徐々に肥大化していきました 。近年のVLMは多少プロンプトが長くなっても推論能力が大きく下がらない印象ですが、学習データに寄った記述が増えるほど過学習のリスクは高まります。最低限 学習データ・テストデータを用意しておく ことをお勧めします。 コストに注意する ループごとに全画像へ推論を回すため、API課金が積み上がります。改善のたびにまず少量サンプルで実験し、有望なときだけ全量評価する仕様にすると、コストは削減できるはずです。ループの設計を誤ると 予期せずバックエンドで推論し続け、コストが跳ね上がる ので注意が必要です。 今後の展望 DSPy等の既存フレームワークとの比較 ：本アプローチで十分な精度を得られたため今回は試しませんでしたが、DSPy等（GEPA等のオプティマイザを含む）と精度・効率を比較したい。 N数を増やして再現性を確認する ：今回の結果はN=1の速報値のため、実行間のばらつきを評価できていない。複数回実行し、数値の信頼性を確かめたい。 社内ツール化・全社展開 ：本アプローチを特定タスク専用の仕組みで終わらせず、誰でも自分のタスクに使えるよう汎用化して展開することを目指す。 まとめ 人手のプロンプトチューニングをClaude Codeのスキルで代替することで、人手チューニングと同等以上の性能（leaf F1でtrain +0.024、test +0.017）を発揮しました。工数面では全体評価サイクルを約3.5週間から約1週間に削減でき、スキーマの異なる他タスクへの適用可能性も確認しました。今回の取り組みを通じ、エージェント活用のあり方は「人間がプロンプトで指示をする」から「ループを回すためのエージェント設計」へ移りつつあると実感しました。本記事がループエンジニアリングに取り組む際の参考になれば幸いです。 おわりに ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ corp.zozo.com LLMの構造化出力エラーを削減する - ZOZO TECH BLOG ↩ Claude "Getting started with loops" ↩ Yuksekgonul et al. "TextGrad: Automatic 'Differentiation' via Text" ↩ Yang et al. "Large Language Models as Optimizers" (OPRO) ↩ Pryzant et al. "Automatic Prompt Optimization with 'Gradient Descent' and Beam Search" (APO) ↩ Google "Gemini API プロンプト設計戦略" ↩