• はじめに：情報処理学会 全国大会で発表を行いました！
• 課題：試行錯誤による「文脈の迷子」と、研究・発表間の一貫性
• 実践：リアルな研究・開発の進め方
  • Makefile の主なターゲットと機能一覧
  • ステップ1：いきなりコードを書かない（要求・仕様の明文化等）
  • ステップ2：アイデアナレッジベースと仮説設定
  • ステップ3：実験の仕様書作成と実装
• 実験仕様書: ベースライン探索パラメータの強化による復元精度向上
  • 目的
  • 仮説
  • 実験設定
    • 比較対象
    • パラメータ比較
    • 評価指標
  • 手順
    • ステップ4：実験実行と振り返り
    • ステップ5：論文とスライドの「自動ビルド」
  • AIエージェントとの「付き合い方」：その自信はどこから来たんだ！
  • おわりに

はじめに：情報処理学会 全国大会で発表を行いました！

こんにちは。データサイエンティストの浦山です。 2026年3月6日に開催された情報処理学会 第88回 全国大会にて、「埋め込み反転攻撃に対するプライバシー保護手法の定量的評価 - 防御効果と有用性のトレードオフ分析 -」というテーマで口頭発表を行いました。

昨今、情報検索や RAG（Retrieval-Augmented Generation）などのシステムで「テキストから変換された埋め込みベクトル」を扱うことが一般的になっていますが、「ベクトルだから中身は見えないし安全」という前提は、実は崩れつつあります。 今回の発表では、元のデータを復元してしまう「反転攻撃 (Embedding Inversion Attack)」の脅威について、LLMを用いた独自の攻撃手法と、PQや差分プライバシーを用いた防御手法とのトレードオフについて定量的に評価しました。

当日の発表スライドは SpeakerDeck にて公開していますので、ぜひご覧ください！ 🔗 埋め込み反転攻撃に対するプライバシー保護手法の定量的評価 (SpeakerDeck)

本記事では、この研究を題材に、「分析の開始から、最終的な論文執筆・スライド生成までをどうやって一気通貫で行ったのか？」という、裏側の「リアルな開発ワークフロー」にフォーカスしてご紹介します。

Git worktree や DVC を使った実験管理の仕組みについては、過去の記事でも紹介していますが、今回はそれをどう「実践」したのかに焦点を当てます。

techtekt.persol-career.co.jp

techtekt.persol-career.co.jp

---

課題：試行錯誤による「文脈の迷子」と、研究・発表間の一貫性

機械学習やデータサイエンスの実験は試行錯誤の連続です。とくにAIエージェントと協働しながら開発・実験を進めることが多い昨今、「過去の自分（あるいはAI）がなぜそのパラメータを選んだのか」「その実験で何を確かめたかったのか」というコンテキストが簡単に失われてしまう問題がありました。（人間だけで仕事してても翌週には忘れてたりすることも・・・）

さらに、実験の数が増えるにつれて「初期の仮説・実際の実験結果・最終的な論文やスライドの主張」の間にブレが生じず、一貫性を保つことが非常に難しくなります。膨大な実験履歴を人間の目と記憶だけで追跡し、辻褄の合った発表資料を作り上げるのにはかなりの手間と時間がかかります。だからこそ、研究の全貌をAIエージェントに正確に共有し、彼らに考察から資料作成までをワンストップでサポートしてもらえるワークフローを自ら構築することが不可欠でした。

本プロジェクトでは、アイデアの発案、実験コードの実装、DVCによる実験管理から、TeXによる論文PDFやBeamerスライドの生成に至るまでを一気通貫で行う枠組みを構築しました。「小さな意思決定でも記録を残す（残させる）」ことで、迷いなく最後の学会発表まで走り切る環境を実現しています。

---

実践：リアルな研究・開発の進め方

まずはリポジトリの成長の様子を振り返ってみましょう。以下の動画は Gource を用いてコミット履歴から可視化したものです。試行錯誤しながらプロジェクトが育っていく過程をご覧ください。

ワークフローの全体像は以下の通りです。全て Makefile を起点として、実験の自動化だけでなく、論文とスライドのビルドまでがシームレスに繋がっています。

ここからは、日々の研究で「実際にどう手を動かしていたのか」を具体的に紹介します。 まず全体像の把握として、プロジェクトの要（かなめ）となっている Makefile に定義された主なターゲットと機能一覧を以下に示します。後述する各ステップでも、これらのコマンドが活躍します。

Makefile の主なターゲットと機能一覧

💡 なぜ今、あえて make なのか？

• make: Makefile に書かれた手順を自動実行するためのコマンドです。
• Makefile: make が実行する手順を定義したファイルです。複雑なコマンドを簡略化したり、ファイルの依存関係を管理したりできます。

make は古くからあるツールですが、AIエージェントにとっては「次に何をすべきか」を判断するための明確なインターフェースになります。

• 自動化: 複雑なコマンドを 1 行に集約。
• ドキュメント: 手順そのものが「動くコード」として残る。
• AI親和性: AIに「まず make rs-start して」と指示するだけで確実に意図が伝わる。

研究・実験のフロー管理

• make rs-setup：実験管理の基盤となる初期設定（Git worktree や Orphan Branch の設定など）を行います。
• make rs-start：実験用ブランチ作成、実験要件メモテンプレートの保存など、実験の準備を行います。
• make rs-run：DVCを用いて実験パイプラインを自動実行し、MLflowに結果を記録します。
• make rs-close：実験を完了させ、振り返りの記録と共に環境をクローズします。
• make rs-push：完了した実験内容や実行結果をリモートリポジトリに保存（Push）します。

コードの開発・テスト

• make lint：Ruff を使ってコードの静的解析・自動フォーマット（Lint / Format）を行います。
• make test：pytest を使って単体テストを実行します。

執筆・スライド生成

• make build-pdf：Docker上で latexmk を実行し、学会提出用の論文PDFを自動ビルドします。
• make build-slides：作成したTeXファイルから、登壇用のスライド資料を一発でコンパイルします。

---

ステップ1：いきなりコードを書かない（要求・仕様の明文化等）

プロジェクトを開始し、Cookiecutter Data Science テンプレートで src/ や data/ などのディレクトリを切った後、いきなりコードを書くことはしません。

まずは docs/ ディレクトリに、研究全体の背景や目的，明らかにしたいこと，想定する方法，システム全体の構成や評価したい内容を定義する spec.md ファイルや、DVCの処理単位を設計する pipeline_spec.md を作成しました。

「何をするべきか」を Markdown形式のドキュメントにし、AIと壁打ちしながら洗練させていきます。このドキュメントが研究全体の骨格になるため、十分に時間をかけて背景、目的、方法、想定する結果、先行研究の調査、研究の意義等を検討します。普通のチャットボット、Deep Research、NotebookLM など様々なツールを使って時間をかけて取り組みました。

作成したドキュメントは、複数のAIチャットボットで批判的に評価させることで、より内容をブラッシュアップさせたり、人間のコダワリを貫いたり等と修正します。AIが受け入れにくいような批判を回避することで、後工程での手戻りを防ぎます。

実験管理関連の設定（Makefile、uv、DVC、MLflow）もこの段階で行います。Orphan Branch や Git worktree の設定（make rs-setup）も行います。

ステップ2：アイデアナレッジベースと仮説設定

研究を進める上で湧いた「こういうアプローチはどうだろう？」という着想は、すべて trials/stocks/stock-NNN.md というマークダウンにストックしていきます。AIがコーディングしてたりトラブルシュートしている待ち時間にアイディアが出ることが多いです。

そして、その中の一つのアイデアを進めると決めたら、仮説をテーマにした実験を開始します。

make rs-start コマンドを実行すると、コード管理とは切り離された思考履歴専用のタイムラインに、新しい実験（Trial）用のディレクトリ trials/EXP-20251212-103000-xxxx/ が自動で作成され、作業ブランチが切り替わります。

例えば以下のようなコマンドを実行します。

$ make rs-start MSG="KSR指標の改善実験"

ステップ3：実験の仕様書作成と実装

実験ディレクトリが作成されると、実験の仕様を書くための spec.md が作成されます。例えば以下のような実験仕様書を作ります。（サンプルなので簡単に書きますが、実際にはもっと内容を濃くします。）

実験仕様書: ベースライン探索パラメータの強化による復元精度向上

目的

現在のベースライン手法（単純な焼きなまし法）は、探索不足により局所解に陥っている可能性が高い。本実験では、探索パラメータ（イテレーション回数、バッチサイズ、温度パラメータ）を大幅に強化し、探索空間を広げることで、KSR（Keyword Survival Rate）の向上および復元テキストの可読性改善が見られるか検証する。

仮説

1. イテレーション数の増加: 探索回数を増やすことで、よりターゲット埋め込みに近いテキストを発見できる。
2. バッチサイズの拡大: 各ステップでの候補生成数を増やすことで、より良い近傍解を選択できる確率を高める。
3. 温度パラメータの調整: 初期温度を高く、冷却をゆっくりにすることで、初期段階での大域的な探索を促進し、局所解への早期収束を防ぐ。

実験設定

比較対象

• Baseline: デフォルトパラメータ
• Enhanced: 今回設定する強化パラメータ

パラメータ比較

パラメータ	Baseline (Default)	Enhanced (今回)	意図
iterations	5000	20000	探索回数を4倍にし、収束までの猶予を与える
batch_size	128	512	候補数を4倍にし、より良い近傍を探す
initial_temperature	0.1	2.0	高温から開始し、多様な状態を許容する
cooling_rate	0.99	0.9995	冷却を遅くし、高温状態を長く維持する
samples	10	2	計算時間が約16倍になるためサンプルサイズを減らす

評価指標

• Cosine Similarity: ターゲット埋め込みと復元テキスト埋め込みの類似度
  • 高いほどオリジナルテキストに近く復元（攻撃）が成功している
• KSR (Keyword Survival Rate): 元テキストに含まれるキーワードの復元率
  • 高いほど個人名が復元できるなど復元（攻撃）が成功している
• 定性評価: 復元されたテキストが自然言語として成立しているか

手順

（以下省略）

上記のように「目的」「仮説」「手順」などを日本語で書き出します。これを書かずにコードを書くことは禁止です。この spec.md が書けたら、次に tests/ に検証用のテストコードを作成または修正し、それを満たすように src/ 配下に実際のロジック（.py）を実装します。

💡 なぜ Jupyter Notebook を使わないのか？

データ分析プロジェクトでは .ipynb ファイル（Jupyter Notebook）が使われることもありますが、この実験フローでは使用しません。 Notebook はセルごとの実行順序によって「隠れた状態」を持ちやすく再現性が低下するだけでなく、中身が JSON 形式であることに加え、コードの実行出力を含んでしまうため、Git の差分（Diff）がノイズを含みバージョン管理がしづらいからです。DVC のようなハッシュ値に依存したパイプラインツールとも相性が悪いです。 何より、AIエージェントにとって現在の実行状態や変数を把握したり、既存の Notebook の途中のコードブロックだけを適切に書き換えたりするのは非常に難易度が高いのです。 .py 形式のPythonスクリプトとテストコードで構成し、ターミナルから make rs-run で一発実行できる形にすることが、人間とAIとの協働に適したアプローチだと感じています。

この時、コードの自動フォーマットや自動テストは make lint（内部でRuffが動作）や make test で実行します。

ステップ4：実験実行と振り返り

実装が完了したら、いよいよ実験です。 DVC（Data Version Control）を用いたデータとパイプラインの管理を行っているため、実行コマンドは非常にシンプルです。

$ make rs-run

このコマンドは内部でコードの自動フォーマット、ワークディレクトリのダーティーチェック（Git commit 漏れを確認）、 uv run dvc repro を呼び出し、パラメータ（params.yaml）に従って学習や評価スクリプトを走らせ、MLflow に結果を送信します。

実験が完了すると、AIエージェントが実行結果を評価して、reflection.md に振り返り内容を 記入し、対話を求めてきます。

「実験結果が出ました。仮説と比較してどうでしたか？」

これに対して考察を記述し、最後に実験を完了させます。

$ make rs-close  # 実験の完了を宣言
$ make rs-push   # 実験結果をリモートリポジトリに保存

これで、この実験における「コード（どうやって実装したか）」「データ（dvc.lockによるハッシュ値）」「思考履歴（spec.mdとreflection.md）」が完全にパックされ、いつでも再現できる状態としてリポジトリに保存されます。

DVC remote を設定することで、パイプラインで生成されたデータやモデルをリモートストレージに保存し、他の環境から利用することも可能です。

ステップ5：論文とスライドの「自動ビルド」

全ての実験が終われば、あとは結果をまとめてアウトプットするだけです。 まずは、研究目的に立ち返り、実施内容と実験結果を整理することで、研究の振り返りをします。必要に応じて追加の文献調査を行い、長さに制限を設定せずにMarkdwonファイルに結果をまとめます。

評価結果のプロット画像などは reports/figures/ に出力されているため、それらを参照します。 執筆中は実験結果の図の修正が頻発します。可視化コードを修正して、make rs-run で再実行するなど、可視化のためのコード修正と、論文・スライドの執筆を並行して進めます。

次に docs/templates/main.tex （投稿用の LaTeX ファイル）や docs/presentation/slides.tex （発表用の Beamer スライド）を執筆します。振り返り内容を元にドラフトを作成し内容を検討します。

TeX と Beamer とは？

• TeX (LaTeX): 数式や高度な図表を美しく組版することに長けた、非常に歴史の長い文書作成システムです。プログラミングのようにプレーンテキストで文書の構造を記述します。
• Beamer: LaTeX の記法を使ってプレゼンテーション用のスライドを作成するためのパッケージです。私個人としても約20年前に Beamer を使って学会発表のスライドを作ったことがあり、当時は奥村晴彦先生の書籍を片手にエラーメッセージと格闘したという、懐かしくも苦い思い出の詰まったツールたちでもあります。

PDFや画像への変換フロー

本プロジェクトでは、ローカルPCへの重い LaTeX 環境のインストールを避けるため、Docker（paperist/texlive-ja など） を利用してコンパイル環境をコンテナ化しています。

1. make build-slides などを実行すると、Dockerコンテナ内で latexmk が走り、.tex ファイルが PDF に変換されます。
2. AIエージェントが視認したり、Webブラウザや SpeakerDeck などで扱いやすくするため、出来上がったPDFに対して pdftoppm などのツールを実行し、各ページを自動的にきれいな PNG画像 に変換しています。

💡 なぜ TeX / Beamer を選んだのか？

ここで、あえて TeX や Beamer を選定した最大の理由は、「AIエージェントに執筆・作成をサポートしてもらうため」です。

LaTeX にはいくつかの明確なデメリットが存在します。特に 「環境構築の面倒さ」 と 「複雑なマークアップ言語との格闘（学習・執筆コスト）」は大きな壁になりがちです。しかし本プロジェクトでは、これらの課題を現代のアプローチで克服しています。

1. 環境構築の壁 → Docker コンテナを利用することで解決します。ローカル環境を汚さず、make コマンド一発で誰でも同じコンパイル環境を即座に利用できます。
2. 複雑なマークアップ言語の壁 → AI エージェント に実記法を任せることで解決します。すべてをテキストベース（TeXのコード）として一元管理しているため、AIが spec.md や reflection.md などのコンテキストを直接読み込み、正確な LaTeX 記法で論文の章立てやスライドを自律的に生成してくれます。人間は面倒な記法と格闘するのではなく、出力内容のレビューと微調整に集中できます。最悪の場合は「奥村晴彦先生の LaTeX 美文書作成入門」を片手に頑張るつもりでしたが、買わずに済みました。

PowerPoint等を生成する外部のAIアプリを利用することも可能ですが、リポジトリ外部のツールを使うと、過去の実験記録を手作業でコピー＆ペーストして文脈を移す「手動操作」がどうしても発生し、一貫性、再現性、そして研究速度が落ちてしまいます。コンテキストと生成コードが同一リポジトリにまとまっている恩恵は非常に大きいのです。Marp や Python-pptx も検討しましたが、表現力の高さと「テキストで書けるメリット」を考えると LaTex Beamer に落ち着きました。

そして、最終的なコンパイルも手作業では行わず、Docker や Makefile を用いて環境依存をなくしています。

$ make build-pdf     # 学会の抄録PDFをビルド
$ make build-slides  # 登壇用スライド(PDF/PPTX)をビルド

コマンド一発でフォーマットを崩さずにPDFが出力されるため、ローカルへの煩雑な LaTeX 環境構築なども不要になりました。このような執筆プロセスの機械化も、本番直前のギリギリの調整で非常に役立ちました。

振り返り：AIが苦手な分野は人間が頑張る

テキストベースの管理により、「細かい仕様や設計のドラフト作成」「シンプルなコーディング」「単純なアウトプットの評価」などはAIに大きく任せることができました。

しかし、全てが自動化できたわけではありません。 例えばスライド作成時の「図の調整」には、かなりの時間とトークンを消費しました。 LaTeX の tikzpicture を使い、AI に座標を指示させてボックスや矢印を配置しようと試みたのです。 「LaTeX 編集 → PNG 生成 → AI エージェントによる視覚的確認 → 人間による最終確認 → 修正指示」というループを何時間か回してみましたが、どうしてもボックスが重なったり、矢印が微妙に斜めになったりしてしまいます。人間が PowerPoint で直接操作すれば 30 分から 60 分ほどで終わるようなレイアウト調整が、AI ではどうしても上手くいかない。結局、最後は人間が目で見ながら自分の手で座標を微調整するという、泥臭い形に落ち着きました。

AI が得意な作業（ドラフト生成や論理的な構成）と、人間が担うべき領域（微細な位置調整や視覚的な完成度、そして本質的な評価）を明確に分担し、「できないことは早々に人間に戻す」と割り切る形で運用しました。AIエージェントの高精度化や低価格化により人間の分担範囲が減るのを楽しみにしています。

---

AIエージェントとの「付き合い方」：その自信はどこから来たんだ！

今回のプロジェクトを通じて、AI エージェントという新しい「研究パートナー」とどう向き合うべきか、いくつかの教訓を得ました。

第一に、AI の「思い込み」を程よく崩してあげる必要性です。 彼らは時に驚くほど強いバイアスを持っており、一度こうだと思い込むと、自信満々で的外れなことを言い出すことがあります。「その自信はどこから来たんだ！」とツッコミを入れたくなる瞬間は一度や二度ではありませんでした。人間側が論理的に、かつ徹底的に裏取りをしながら、おかしな方向に行きそうなときは「やんわりと論破」してあげる必要があります。バグがある実験コードの出力を信じ切ってたりするので怖いです。

第二に、テストコードによる「ガード」の重要性です。 特にリファクタリングを任せる際、テストコードで固めておかないと、静かにバグを埋め込まれる恐怖が付きまといます。AIに任せる部分はありますが、機械的な検証によって彼ら（我々？）の仕事の質を担保する仕組みは不可欠です。

もちろん、人間側が間違えていることも少なくありません。 基本的には「背景と目的をしっかり伝え、方法は一旦任せてみる」というスタンスで、筋が悪い方法を選びそうになったら介入します。この「任せつつ、手綱は離さない」という良い塩梅の関係性が、AI との協働においては何より大切だと感じています。

---

おわりに

今回の学会発表は、テキスト埋め込み反転攻撃の最新の知見を探求するという挑戦でしたが、その裏側にある「make コマンドを叩けば実験が回り、登壇スライドまで出力される一気通貫のワークフロー」があってこそ、複雑な実験や執筆を最後までやり遂げることができました。

過去の記事で紹介したDVCやGit worktree & Orphan branchのような個別のツールも強力ですが、それらを「分析の開始から成果物（スライド・論文）の生成までを分断させず、AIエージェントと一緒に迷わず進められるパイプラインをどう組むか」という視点で繋ぎ合わせることが今回の研究の裏テーマになっていました。実際にこのワークフローを構築して発表まで漕ぎつけた経験から、AIとの協働の形を模索する上で、有用なヒントを得たように感じます。

この実践的なワークフローが、機械学習プロジェクトや研究活動に取り組む皆さまのヒントになれば幸いです！ 最後までお読みいただきありがとうございました。

※2026年3月現在の情報です。