D-sides. のお知らせ・プレスリリースと、データ／AI を業務に組み込む実装ノート。https://d-sides.co.jp/jahttps://d-sides.co.jp/columns/2026-08-12-data-drift-seasonality/https://d-sides.co.jp/columns/2026-08-12-data-drift-seasonality/PoCでは高精度が出ていたモデルが、運用開始後の季節変動で崩れかけた話。データ分布のskewにどう気づき、どう仕組みで対処したかを振り返ります。Tue, 11 Aug 2026 21:51:21 GMT<h2 id="h8492368e89">PoCが成功しても、本番化には時間がかかる</h2><p>「PoCでは高い精度が出た。なのに本番化になぜか時間がかかる」——このギャップに心当たりのある方は多いのではないでしょうか。</p><p>原因はさまざまですが、私たちが実際に手を焼いたのは、<strong>運用してみないと分からないデータ分布のskew（偏り）</strong> でした。季節性のあるユーザー行動を予測するプロダクトでの話です。</p><h2 id="h199461560a">気づき：運用してみないと分からない&quot;揺れ&quot;</h2><p>このプロジェクトでは、Click RateやCV Rateといった予測対象そのものに季節ごとの変化がありました。加えて、流入してくるユーザーの属性自体も季節によって変化するのではないか、という仮説を持っていました。</p><p>厄介なのは、こうした揺れは短期間のPoCデータだけを見ていても気づきにくいということです。特定の季節だけモデルが「当てやすくなる」「当てにくくなる」という現象は、実際に運用期間をまたいでみて初めて輪郭がはっきりします。</p><h2 id="hf82479f67b">PoC段階での先回り</h2><p>幸い、このプロジェクトではPoCの時点で時系列を加味したEDA（探索的データ分析）を行い、季節によって予測精度に差が出ることを事前に確認できていました。</p><p>ここで重要だったのは、「精度の出るモデルを1つ出して終わり」にしなかったことです。PoCの結果を見た時点で、「これは運用後も継続的に監視し、学習し続ける仕組みが必要だ」という方向に設計を切り替えました。</p><h2 id="h24065a787f">仮説を現場の知見と照らし合わせる</h2><p>季節変動という仮説は、データを眺めているだけでは確信が持てません。そこで現場のドメイン知識を持つ方に「そうした季節性の影響は実際にあり得るか」を確認しました。</p><p>結果、現場側でも同様の感覚があることが分かり、<strong>ドメイン知識をデータからも検証する</strong>というプロセスを踏むことになりました。この、データサイドの仮説と現場の肌感覚をすり合わせる工程が、後の特徴量設計に直結することになります。</p><h2 id="hbbe2a1f65e">設計した仕組み</h2><p>実際に運用に入れた仕組みは、大きく4つです。</p><ul><li><strong>ドリフト検知</strong>：入力データの分布と、予測対象そのものの値の変動を監視する</li><li><strong>再学習フロー</strong>：最初は手動トリガーから始め、運用結果を見ながら段階的に自動トリガーへ移行</li><li><strong>ドメイン知識の特徴量化</strong>：現場から得た季節性・傾向変化の知見を、モデルに渡す特徴量として設計に組み込む</li><li><strong>A/Bテスト基盤</strong>：追加した特徴量やモデルの効果を、実際の運用成績で継続的に検証できる環境を用意</li></ul><p>いきなり全自動を目指さず、手動→自動という段階を踏んだのは、運用の実感を積んでから仕組みを固めるためでした。</p><h2 id="h3c48db88b5">安定するまでの期間</h2><p>PoC開始から、自動再学習まで含めた運用が安定するまでには、おおよそ3〜6ヶ月かかりました。この期間を短いと見るか長いと見るかは立場によりますが、「モデルを1つ出して終わり」の感覚でスケジュールを引いていたら、確実に見誤っていた期間です。</p><h2 id="he4095a67db">PoC段階の自分に伝えたいこと</h2><p>もしPoC段階の自分にアドバイスできるなら、こう伝えます。</p><p><strong>まず、現場でドメイン知識を持つ方に、季節性や流入データの傾向変化について早い段階でインタビューすること。</strong> そこから「判断の軸として重要なデータ（特徴量）は何か」を洗い出しておくべきだった、と。</p><p>データだけを見て仮説を立てるよりも先に、現場の知見を起点に検証すべき変数の当たりをつけておく。それだけで、PoCの設計そのものがもっと筋の良いものになっていたはずです。</p><h2 id="ha214098e44">まとめ</h2><p>PoCのゴールは「精度の出るモデルを出すこと」ではありません。運用後も学び続けられる仕組みを設計することが、本当のゴールです。</p><p>データ分布のskewは、多くの場合、運用してみるまで正体を現しません。だからこそ、PoCの時点で「運用後に何が変わりうるか」を先回りして問い、現場の知見と照らし合わせておくことが、本番化までの時間を大きく左右します。</p>https://d-sides.co.jp/news/2026-06-01-kobayashi-remedy-outside-director/https://d-sides.co.jp/news/2026-06-01-kobayashi-remedy-outside-director/弊社代表の小林 拓磨が、リメディ株式会社の社外取締役に就任しました（2026.6〜）。同社のメンバーページでもご確認いただけます。Tue, 11 Aug 2026 21:51:20 GMT<h2 id="hfb3595d392">就任のお知らせ</h2><p>このたび、弊社（株式会社 D-sides.）代表取締役 <strong>小林 拓磨</strong> が、 <strong>リメディ株式会社の社外取締役</strong> に就任いたしました（2026.6〜）。</p><h2 id="h282b720588">関連リンク</h2><ul><li><a href="https://remedy-tokyo.co.jp/members/67/">小林 拓磨 | リメディ株式会社（メンバーページ）</a></li></ul><h2 id="h52f2592661">D-sides. の事業について</h2><p>小林はリメディ株式会社における新たな職務と並行して、株式会社 D-sides. の代表取締役を継続いたします。 D-sides. の事業運営、案件遂行、お客様へのサポート体制に変更はございません。</p><p>「Data × AI を、業務のオペレーションに組み込む」という D-sides. のミッションは変わらず、 引き続きお客様の現場に実装知見を還元してまいります。</p><h2 id="h9006f5ed34">今後について</h2><p>引き続きご指導ご鞭撻のほど、よろしくお願い申し上げます。</p><hr><p><strong>お問い合わせ:</strong> <a href="mailto:info@d-sides.co.jp">info@d-sides.co.jp</a></p>https://d-sides.co.jp/news/2026-04-28-kobayashi-caxo/https://d-sides.co.jp/news/2026-04-28-kobayashi-caxo/弊社代表の小林 拓磨が、CyberAgent AI Creative Company の CAXO に就任しました。同社の AI クリエイティブ事業の戦略立案を担いつつ、D-sides. の代表業務も継続します。Tue, 11 Aug 2026 21:51:18 GMT<h2 id="hfb3595d392">就任のお知らせ</h2><p>このたび、弊社（株式会社 D-sides.）代表取締役 <strong>小林 拓磨</strong> が、 <strong>CyberAgent AI Creative Company の CAXO（Chief AI Transformation Officer）</strong> に就任いたしました。</p><h2 id="hc69c85bcf9">背景</h2><p>CyberAgent AI Creative Company は、生成 AI を活用したクリエイティブ制作の最前線で 事業を展開しています。小林はこれまで D-sides. にて、データ基盤と生成 AI を業務オペレーションに 組み込む実装に取り組んでまいりました。両社の知見が交差する位置で、 AI クリエイティブ事業のさらなる加速に貢献してまいります。</p><h2 id="h52f2592661">D-sides. の事業について</h2><p>小林は CyberAgent における新たな職務と並行して、株式会社 D-sides. の代表取締役を継続いたします。 D-sides. の事業運営、案件遂行、お客様へのサポート体制に変更はございません。</p><p>「Data × AI を、業務のオペレーションに組み込む」という D-sides. のミッションは変わらず、 むしろ大規模クリエイティブ事業での実装知見を、お客様の現場に還元してまいります。</p><h2 id="h9006f5ed34">今後について</h2><p>両社における役割を通じて、生成 AI とデータ活用が事業 KPI に貢献する取り組みを さらに積み上げ、業界全体の進展に寄与してまいります。 引き続きご指導ご鞭撻のほど、よろしくお願い申し上げます。</p><hr><p><strong>お問い合わせ:</strong> <a href="mailto:info@d-sides.co.jp">info@d-sides.co.jp</a></p>https://d-sides.co.jp/columns/2026-08-12-expert-review-human-in-the-loop/https://d-sides.co.jp/columns/2026-08-12-expert-review-human-in-the-loop/長大な報告書のレビュー支援で直面した、辞書ベース検索の限界と「人間側が疲弊するヒューマンインザループ」のリスク。確信度ベースの優先順位づけとデータ蓄積を加速する設計を振り返ります。<h2 id="ha07a05b310">長大な報告書の本当の難所</h2><p>年次報告書のような長大な文書を扱う案件で、私たちが向き合ったのは「文書が長い」こと自体ではありませんでした。本当に難しいのは、<strong>専門知識がないと見逃してしまう記述が、文書全体に散らばっている</strong>ことです。</p><p>しかもそうした箇所は、たいてい「レビュー漏れの影響が大きい」箇所と重なります。財務リスクの記載、内部統制の不備、契約条件の細かな注記——これらを見逃さずに拾い上げる仕組みが必要でした。</p><h2 id="hbbc562ff23">気づき：辞書ベースだけでは、人間の負荷が増えていく</h2><p>最初から、用語辞書とAugmented キーワードによる検索は行っていました。レビューサイクルの中で辞書を育てていく運用です。</p><p>ただ、これでは類語や意味的に近い表現の漏れがどうしても蓄積します。「為替リスク」は拾えても「外貨建て負債」や「円安の影響」といった、意味的には関連するが辞書に無い表現は拾えません。</p><p>この状態を放置すると、AIが拾いきれない分だけ人間のレビューに依存し続けることになります。効率化のためのAIが、かえって<strong>人間側に負荷のかかるヒューマンインザループ</strong>を生んでしまうリスクは、<a href="https://share.google/DIGDPAJAKIAQ7eajk">日経の記事</a>でも指摘されている通りです。この問題は先回りして設計段階で見越しておく必要がありました。</p><h2 id="h2768e8c2fb">設計の拡張：用語検索 + 言い換えaugmentation + Embedding</h2><p>そこで、用語検索・言い換えaugmentationに加えて、embeddingによる意味検索を組み合わせる設計に拡張しました。効果はシンプルに図解できます。</p><p>用語辞書ベースでは拾えなかった意味的に近い表現も、embeddingを加えることで検索対象に入る</p><p>左側（辞書 + augmentationのみ）では、辞書に登録された表現とその言い換えしか拾えません。右側のようにembeddingによる意味検索を加えることで、辞書に無い表現でも「意味的な近さ」を手がかりに拾えるようになります。</p><h3 id="he75b9e7a37">embeddingにもいろいろな手法がある</h3><p>一口にembeddingと言っても、目的や文書の性質によって選択肢は複数あります。</p><ul><li><strong>Word2Vec</strong>：単語単位の分散表現。周辺の単語との共起関係から意味の近さを学習する、比較的シンプルな手法。計算コストが低く、まず試す選択肢として扱いやすい</li><li><strong>fastText</strong>：Word2Vecを拡張し、単語をサブワード単位で扱う。専門用語の表記ゆれや未知語にもある程度強い</li><li><strong>文（Sentence）単位のembedding</strong>：BERT系のモデルなどを使い、文脈を踏まえた文単位の意味表現を得る手法。単語の並び方や前後関係まで含めて「意味の近さ」を判定できるため、長い報告書の文単位の検索には向いている</li><li><strong>ドメイン特化でファインチューニングしたembedding</strong>：専門用語や業界特有の言い回しが多い文書では、汎用モデルのままでは意味の近さの精度が落ちることがある。ドメインのコーパスで追加学習したembeddingを使うことで、専門家が使う語彙に沿った検索精度に近づけられる</li></ul><p>どこから始めるかは文書の専門性やデータ量次第ですが、まずWord2Vec相当の軽量な手法で効果を確認し、精度が足りない箇所からBERT系やドメイン特化の手法に広げていく、という段階的な進め方が現実的です。</p><h2 id="ha198a21d8f">優先順位づけの仕組み：確信度で人間とAIの役割を分ける</h2><p>意味検索で拾える範囲を広げても、すべてを人間がレビューしていては意味がありません。そこで、章やファイルごとに分類したうえで、AIモデルの確信度をもとにレビューの優先順位を決める仕組みを組み込みました。</p><p>重要度が高い記述（赤）と、AIモデルの確信度が低い記述（黄）を分けて表示するレビューUIのイメージ</p><ul><li><strong>重要度が高い箇所</strong>（財務リスクや統制不備など）は、確信度に関わらず優先的に人間の目を通す</li><li><strong>AIモデルの確信度が低い箇所</strong>は、判断が難しい／学習データが少ない可能性が高いため、こちらも優先的にレビュー対象にする</li></ul><p>この2軸で優先順位を分けることで、「AIに任せる部分」と「人間が見るべき部分」の役割分担が明確になりました。</p><h2 id="h64bec3fcbd">副次効果：確信度の低いデータほど、学習データとして価値がある</h2><p>確信度が低い箇所を人間に優先的にレビューしてもらう設計には、もう一つ狙いがありました。<strong>確信度が低い＝モデルがまだ学習できていない箇所</strong>でもあるため、そこにレビューが入ることで、モデル改善に効くデータから優先的に学習データ化できます。</p><p>いわゆるアクティブラーニングの考え方に近い形で、レビューのコストをモデル改善にも還元できる設計です。</p><h2 id="hcf01dd4680">データ蓄積を加速する仕組み</h2><p>さらに、レビューフェーズで「この記述が漏れていた」と指摘された際に、その漏れの周辺キーワードから「このキーワードも漏れていないか」を推薦する仕組みも入れました。これはembeddingベースの探索モデルをそのまま活用できます。</p><p>これにより、</p><ul><li>レビューする側の体験（見逃しの周辺も一緒に確認できる）</li><li>辞書やアノテーションデータが育つ速度</li></ul><p>の両方を底上げできます。レビューが単なる「チェック作業」ではなく、データを蓄積・改善するループの一部になる設計です。</p><h2 id="hd6f3e79400">理想の形：業務を手伝いながら、正しい学習データが自然に貯まる</h2><p>ここまでの仕組みはどれも「レビューという作業」を起点にしていますが、本当に目指したいのはもう一段先です。専門家に「レビューしてください」と特別な作業をお願いするのではなく、<strong>専門家が普段通りの業務を完了させるだけで、その過程で正しい学習データが自然に貯まっていく</strong>——これが理想の形だと考えています。</p><p>人間の業務を&quot;手伝う&quot;AIが、同時に人間の業務の結果から学び続ける。データ収集のための追加作業を専門家に強いるのではなく、業務そのものが学習データの供給源になるように設計する。レビュー優先度づけや漏れ推薦の仕組みも、突き詰めればこの理想に近づくための手段の一つです。この視点を持っておくと、「どこまで人間に作業をお願いするか」の設計判断がぶれにくくなります。</p><h2 id="he4095a67db">PoC段階の自分に伝えたいこと</h2><p>もしPoC段階の自分にアドバイスできるなら、こう伝えます。</p><p><strong>モデルの精度を追求する前に、専門家のドメイン知識や語彙をどう効率的に集めるか、専門家のレビュー負荷をどれだけ下げられるかというUI/UXの部分を、PoC段階からしっかり設計検討すること。</strong> そのためには、専門家と直接議論する時間を早い段階で確保すべきでした。</p><p>精度は後からでも上げられますが、専門家が「レビューを続けたい」と思える体験は、後付けでは直しにくいものです。</p><h2 id="ha214098e44">まとめ</h2><p>長大な文書のレビュー支援は、モデルの精度勝負に見えて、実際には「人間とAIの役割分担」と「専門家の負荷をどう設計するか」の勝負でした。</p><p>辞書ベースの限界を先回りして見越し、embeddingで検索範囲を広げ、確信度で優先順位をつけ、レビューがデータを育てるループを作る——精度の追求は、その設計の上に乗るものだと捉え直すと、PoCの立て方そのものが変わってきます。</p><hr><p><em>参考: </em><a href="https://share.google/DIGDPAJAKIAQ7eajk"><em>ヒューマンインザループの負荷に関する日経の記事</em></a><em> / </em><a href="https://amzn.asia/d/086WNvtM"><em>参考書籍</em></a></p>