AIを使って研究・実験したらどうなるのか？
AIを研究パートナーとしてどのように活用していくべきか？
というテーマで書きます。
最近、進化計算学会という学会で発表してきました。
なんとか無事発表まで終えることができました。議論してくださった方々のおかげです。
今回の発表ではとくにAIを使って高速に研究を進めることができました。
私自身は人工知能が専門で、最近はLLMのプロンプト最適化というテーマで研究しています。
今回はその過程で感じた、AI利用の利点や課題、工夫した点についてまとめてみます。
ここで実験と呼んでいるのは、PC上で実行できる計算実験を指してます。
最適化計算や、性能検証のための実験です。
読者は検証を行うエンジニアやAI研究者のような人を想定しています。
使ったLLMの違い
Github Copilotを使ってコードを書いています。文章もいけます。
Microsoft Copilotとは別でコードや文章を相談しながら作っていけます。
copilotとなるLLMも選択できるのでClaude Sonnet 4.5とgpt-5-miniを使いました。
それぞれ使ってみた際に感じた利点は下の通りです。
Claude Sonnet 4.5
- 意図をよく理解してくれている感がある
- ほぼすべて日本語で応答してくれる
gpt-5-mini
- sonnetと比べると少し堅い印象
- 意図は理解している
- 日本語で聞いても出力が英語 読めるけど大量にあると辛い
gemini 3 pro(ついでにAntigravityも使ってみたのでコメント)
- gpt-5-nanoを問題なく使ってくれる。スムーズ
- 理解力はClaude Sonnetよりある印象（主観）
AIを利用した実験の利点
- 多少複雑なロジックも文句を言わずに作ってくれる。
- 数式もtex形式で扱えるので、定式化の記述もできる（でも細かいところはいい加減）
- 指示通りに実行するために手段を考えてくれる
- 指示に誤りがあった場合にも訂正して実行してくれる
- 2024年くらいまでに論文発表された内容が知識として入っているので、聞けばアドバイスしてくれる
- 実行コマンドを生成してユーザーがAllowボタンを押す形で実行できる（でもたまに自動で実行している）
- AI主体で実行したコマンドについては出力もモニタしているので、エラーが出た時の対応も自動（でも人が実行した場合は見てくれない）
- 実験が途中で失敗した場合も途中から再実行できる仕組みを考えてくれる
- 自分でコードを作ると細かいところに注意が向きそうになるが、AIにコードを書いてもらうと視野が広く保てて余裕をもってチェックできる
- レポートや論文で足りない説明を補完してくれる（ただしチェックは必要）
AIを利用した実験の課題点
今回は数式で定義されたアルゴリズムを使って最適化を行うという実験を行いました。
その過程であった課題点を挙げていきます。
- 数式や数学的な定義からの理解が難しい場合がある
- gpt-5-nanoを使いたいのにgpt-4oを標準と考えて推してくる（LLMの標準がすこし古い）
- 指示に誤りがあった場合にも訂正して実行してくれる点は良いが、ちょっと変わった指示の場合も修正されて違う処理になることがある。
- 実行の際に仮想環境を使わずに実行してエラーを頻繁に起こす。しかもライブラリが足りませんといってインストールしようとする。
- ちょっと複雑な分析指示をすると１行コマンドを作ろうとして引用符の問題でエラーになる
- いまのところ画像認識はしてくれないらしい(2025-12現在)、svgなら場合によってはテキストで確認してくれる
- たまにメソッドの実装が空だったり簡易版、近似で済ませる
- 実験計画にミスが多い
- 意味のない条件を入れてくることがある
- 一時的なスクリプトが大量に作成されて混乱する
- 分析の考察が浅い
- 単に多要因分析を実施してというとscipyを使って一要因分散分析を大量に行ってくる（多重比較で扱いが面倒になるので、多要因分析で済ませたい）
実験計画に問題が多いのは多要因実験を行っていて、制約多くハイコンテキストな状況での計画なのでLLMにはまだ難しいのかもしれないと思いました。
AIを使った実験サイクル
この研究の前から
「AIを使って実験・研究するためにはどうしたらいいか」という視点から工夫・方法を考えてきました。
試行錯誤の結果、利用のコツもわかってきましたので、書き出してみました。
何をどのように検証すべきかという対象を決めるところからAIとやり取りして考えています。
あまり整理できていないので、すいませんが箇条書きで並べます。
全体：
- WSL Ubuntu Bashを使うよう指示（自分がPowerShellよりBashの方が詳しいので）
- 多くの実験を行う場合、実験インデックスのドキュメント（EXPERIMENTS.md）を作成する
実験サイクル：
- まず実験IDを作り実験リストをまとめてもらう。実験ID（例えば exp_202512_comparison）はディレクトリと一致させる
- 実験ごとにディレクトリを作って、文書やスクリプトなどは基本的にそこで作って管理する（例：EXPERIMENT_PLAN.md）
- 実験計画書を作る（作ってもらう）
- 実験分析レポートを作る
- リサーチクエスチョンを作る（例えば「LLMの応答は意味のあるものか、もしくは意味のないランダムか」など）
- リサーチクエスチョンに応じた結論を作るよう指示する。最初は仮の結果として作成し「（仮）」を付ける
- 実験実行
- 時間がかかる計算の場合は最初に小規模で試しておく
- 結果出力はテキストで取っておく
- 出力結果をerror,empty,warning,exceptなどの単語で検索してチェック
- 途中で失敗しても慌てずにAIに相談して方法を考えてもらう
- 分析する
- statsmodelsを使って多要因分散分析をするように明確に指示する
- 分析スクリプトは実験分析レポートからリンクを貼る
- 可視化する
- グラフはSVGで作ってレポートから読み込ませる
- 批評する
- 結論、結果とグラフを見て論理に矛盾がないか確かめる。
- 根拠があいまいな部分は元のデータを確認
- 実験の結果、結論が出せない部分は今後の課題としてまとめる
- 実験計画書と実験レポートを元に次の実験計画書を作成する（実験サイクル初めに戻る）
実験ディレクトリ（フォルダ）を分けるのは私の実験では大量のデータファイルが生成される形式なので、整理のためにディレクトリを分けるのは重要です。
さらに課題でも述べたように、AIで実験スクリプトや再実行スクリプト、内容確認スクリプトなど多くの一時的なスクリプトを作ることがあります。あとから集計結果や分析処理を確認したい場合も出てくると思います。しかもanalyze_data.pyとかいうファイルができると、似たような名前で混乱しそうなのでディレクトリを分けておくことは重要です。
実験IDの必要性については、実験を１回しか行わない場合は必要ないかもしれません。
しかし、複数の実験がある場合、まとめる過程でこの結論はどの実験から得られたものかを確認したくなることがあり、
数週間前～数か月前の実験など詳細を覚えていないです。少なくとも私は忘れやすいので覚えてないと断言できます。
仮にそれをAIに指示しようとした場合、実験IDが無いと指示しにくいです。「リサーチクエスチョン１の○○って前にやった実験から考察できますよね？」とか聞いても、全く違う実験を参照してきて「まだ検証できていませんでした」なんて返してきます。
そのため、実験IDを示して例えば「exp_optimization_improved_v2の結果を確認してください」などと明確に指示することが重要です。
上で述べたのは実験の全体的な枠組みです。
実験計画と分析、まとめと全自動で行うのはまだAIでは難しそうなので、明確に指示する必要があるようです。
FAQ
LLMにこのブログを読んで質問を考えてもらいました。内容はチェックしています。
Q1: AIを使うことで実験にかかる時間はどれくらい短縮されましたか？
A: 体感では2～3倍程度のスピードアップになりました。コード実装やデバッグの時間が大幅に削減されました。ただし、実験計画やコマンドの実行、結果の検証時間は必要なので、すべてが自動化されるわけではありません。
Q2: Claude Sonnet 4.5とgpt-5-miniのどちらがおすすめですか？
A: 用途によります。日本語でのやり取りを重視するならClaude Sonnet 4.5が快適です。コストを抑えたい場合や英語でも問題ない場合はgpt-5-miniが良いでしょう。私は両方を使い分けています。
Q3: プログラミング初心者でもこの方法で実験できますか？
A: ある程度のプログラミング知識は必要です。AIが生成したコードが正しいか判断したり、エラーが出た時の対処を指示したりする必要があるためです。最低限、Python の基礎や実験で使うライブラリの概要は理解しておくことをおすすめします。
Q4: AIに実験計画を任せる際の最大の注意点は何ですか？
A: 実験計画と分析の妥当性は必ず自分で確認することです。特に多要因実験では、AIが不要な条件を追加したり、重要な条件を見落としたりすることがあります。リサーチクエスチョンを明確にして、それに対応した計画・分析になっているか丁寧にチェックしてください。
Q5: 一つの実験にどれくらいの規模のコードを書いてもらいましたか？
A: 実験によって異なりますが、1つの実験で数百行～1000行程度のPythonコードになることが多いです。最適化アルゴリズム本体、実験実行スクリプト、データ分析スクリプト、可視化スクリプトなど複数のファイルに分かれます。
Q6: コスト面はどうですか？GitHub Copilotの利用料以外にかかる費用はありますか？
A: 料金ページを確認してください。
Github Copilotの料金のページ→ https://github.com/features/copilot/plans?locale=ja
Q7: AIが生成したコードの品質はどうですか？そのまま使えますか？
A: 基本的なロジックは正しいことが多いですが、そのまま使えることは稀です。細かいバグや、要件と微妙に異なる実装になっていることがあるため、テストと検証が必要です。また、数式の実装は特に注意が必要で、定義と実装が一致しているか確認する必要があります。古い知識が混ざっているためか現バージョンと使い方が合っていない場合などはエラー＆修正を繰り返しています。
Q8: 実験の再現性を確保するためにどんな工夫をしていますか？
A: 実験ディレクトリごとに実験計画書（EXPERIMENT_PLAN.md）を作成し、使用したコード、パラメータ、乱数シード、ライブラリのバージョンなどを記録しています。また、結果はすべてテキストファイルで保存し、後から確認できるようにしています。
Q9: 多要因分散分析について、具体的にどう指示すれば良いですか？
A: 「statsmodelsのANOVAを使って、要因A、要因B、要因Cの主効果と交互作用を含む多要因分散分析を実施してください」のように具体的なライブラリ名と分析内容を明示すると良いです。「多要因分析」だけだと一要因分析を複数回実行されることがあります。
Q10: この方法は他の分野の実験にも応用できますか？
A: はい、応用可能です。機械学習の性能評価、シミュレーション実験、統計分析など、PC上で実行できる計算実験であれば同様のアプローチが使えます。ただし、実験の性質に応じて実験サイクルやディレクトリ構造は調整する必要があります。
補足：多要因分散分析
最適化実験では複数の要因（例：アルゴリズムの種類、パラメータ設定、問題の種類など）が同時に結果に影響を与えます。一要因ずつ分散分析を行うと、要因間の交互作用（例：「アルゴリズムAはパラメータXで良いが、アルゴリズムBはパラメータYで良い」という関係）を見逃してしまいます。また、複数回の統計検定を行うと多重比較問題が発生し、偽陽性（本当は差がないのに差があると判定してしまう）のリスクが高まります。多要因分散分析を使えば、これらの問題を適切に扱いながら、複数の要因とその交互作用を同時に評価できるため、実験結果の解釈がより正確になります。
Discussion