AI エージェントを研究に使った例は、どの作業を任せ、研究者がどこで確かめたかによって性格が分かれる。ここでは、コードの作成、評価の仕組みを与えたうえでの自律的な改善、史料の震度判定における経過と限界、研究チームとの協働、研究環境の整備、利用者の実感という順に、報告された事例を述べる。三類型や指揮者の概念は節「AI 時代の研究方法」で定義されており、本節はそれを参照するにとどめる。

コードの作成を任せる

最も多く報告されているのは、コードの作成をエージェントに任せる使い方である。参加者アンケートでは、AI の利用目的として「プログラムの作成(コーディング)」を挙げた回答者が有効回答 38 名中 14 名で、文章の作成・要約・翻訳(29 名)や質問・相談・アイデア出し(27 名)より少ない [Issues-002 §調査の方法と回答者の構成]。役立つことの設問には、プログラムが生成 AI でほぼ正確に書けるようになり、書いていた時間をアイデアの検証など他の作業に使えるようになったという記述がある [Issues-002 §論点1：AIの使い方]。

SPReAD 採択研究の発表では、Python でコードを書けない発表者が Gemini にコードを生成させて画像認識システムの実装を進め、非常に有用だと述べている [Issues-004 §論点1：AIを使う研究環境の整え方]。

確認の側には課題が残る。同じ発表では、プロンプトや指示が不十分だと意図と異なるコードが生成されることがあり、生成されたコードを評価・修正するための知識が求められると述べている [Issues-004 §論点1：AIを使う研究環境の整え方]。アンケートでも、プログラミング作業が容易になった反面、希望どおりの出力を得るためのプロンプトが複雑になり、エラーが起きたときの対応が困難だという声がある [Issues-002 §論点1：AIの使い方]。

評価の仕組みを与えて改善を任せる

コードを書かせるだけでなく、改善の試行錯誤そのものを任せた例もある。対象は、『天保郷帳』の約 6 万の村名と他の資料の村との対応づけである。同名が 2 件以上ある村名は行数にして全体の 56.8%(34,394 行)を占め、たとえば田中村は全国に 104 村あり、14 郡では同じ郡の中に複数ある。「駒方新田」と「駒形新田」のような表記の揺れもあり、単純な文字列の一致では対応づけにならず、全件の人手確認も膨大な手間がかかった [UC-049 §対応付け作業の問題：同名地名と表記揺れ]。

この絞り込み方法の改善を Claude に頼んだところ、AI がスコアリング制を提案した。候補を辞書から広く集め、表記・別名・距離・県・石高などの手がかりで加点・減点し、郡ごとに全体で最高点の組み合わせを選び、1 位と 2 位の点差で人手確認の要否を振り分ける方法である [UC-049 §AIエージェントが発案したスコアリング制]。人手確認なしで確定できたのは 60,601 村のうち 47,126 村(77.8%)で、すでに人手で対応づけた村を検証データにして確かめたところ、2,129 行のうち不正解の確定は 16 件(0.75%)だった。人手で確認が必要な件数は 1.9 万件から 1.3 万件に減り、100 万円以上の経費減になった [UC-049 §AIエージェントが発案したスコアリング制]。研究者がしたのは、絞り込み方法の改善を AI に頼むことだけだった [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。

この例を支えた条件は二つ報告されている。一つは、人手による検証データがあったため、人間が具体的に指示しなくても AI がさまざまな方法を試せたこと。もう一つは、施策の効果を即座に検証できたため、AI が高速に PDCA サイクルを回せたことである [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。この手法はループエンジニアリングと呼ばれ、人間は AI がタスクをどれだけうまくこなしたかを評価する仕組みを用意し、AI はその評価結果が良くなるように自律的にサイクルを回す方式として説明されている [UC-049 §AIによる改善が機能した理由とループエンジニアリング]。この例で研究者が確かめる場所は、個々の出力ではなく、評価に使う検証データと評価の仕組みに置かれていた。

史料の震度判定で見えた限界と、人に残る責任

大量に処理できることの裏側を示すのが、歴史地震の被害記述から震度を判定する事例である。この事例では、コードを書けない研究者がエージェントに実装を任せている。

最初の実験では、史料の URL から本文を取得し、長文から地点を抜き出して震度を判定するアプリを自作した。安政江戸地震の史料である別本「藤岡屋日記」上の約 2 万文字から約 160 地点を抽出し、そのうち 140 件の震度を判定した(残る 20 件は火災などによる被害で判定不能)。報告者の確認では、160 地点中の 8 割で「適切」「概ね適切」な基準を使っていた。ところが、同じプロンプトで史料 790 件を大量に処理すると、判定したのは 20 か所にとどまり、適切な基準の使用は 66% から 45% に下がって、不適切は 5% から 15% に増えた。量が増えると取りこぼしと精度の低下が起きたため、構造化されていないテキストからいきなり地点の抽出と震度判定の両方を行わせる方式には限界があると考え、処理を再設計した [UC-048 §第1実験：史料を一括処理するアプリとその課題]。

再設計したツールで同じ史料の約 2 万文字を処理すると、抽出した被害記述は 160 件から 461 件へと約 3 倍に増えた。タグ付けで地名だけでなく、震度判定の対象になる構造物まで対象に入れたことが大きいと見られている。461 件のうち 315 件(68%)で震度を判定し、146 件は判定不能とした。適切な基準を使っているかの AI による自己判定は、妥当 264 件(84%)、注意 4 件(1%)、警告 47 件(15%)で、注意と警告の行は人が再判定に回す。人による確認はこれからである [UC-048 §第2実験の結果]。

この経過を踏まえて、報告された限界は次の五点である [UC-048 §限界と人間に残る責任]。

そのうえで、人間に残る責任として、何を変えないかを決めること、結果を史料で確かめること、AI の提案の採否を決めることの三つが示されている。報告者はこのあり方を「Historian in the Loop」ではないかと述べている [UC-048 §限界と人間に残る責任]。この事例で確かめる場所は、件数の増加で基準の使い方がどう変わるかという処理全体の傾向と、個々の判定を史料に照らす点の双方にある。

設計は人が決め、実装はエージェントが担う

西洋古典テクスト基盤 Humanitext では、3 人の研究者の共同研究として、設計や方針をチームが相談して決め、実装を AI エージェントが担う分担をとっている。AI の側がより適切な設計案を示してくることも多く、協働の実感はチームの一員に近い。ただし、何を採用するかという最終的な意思決定は常に人間のチームが行う [UC-038 §研究チームとAIの協働]。

この分担を支えたのは、判断を文書として残すことだった。決定した事項、採用しなかった案とその理由、生じた不具合を各リポジトリの AGENTS.md に記録し、以後のセッションで最初にエージェントへ読ませている [UC-038 §研究チームとAIの協働]。報告によれば、3 つのサービスを一から構築して維持できているのは AI の支援によるところが大きく、外部委託や大規模な開発体制なしには実現できなかったシステムを、研究上の判断と直結した形で作れるようになりつつある [UC-038 §研究チームとAIの協働]。

研究環境の中にエージェントを組み込む

研究の進め方そのものにコーディング支援エージェントを組み込む計画も、複数の発表で示されている。ある発表では、プログラマではない研究者が実験の設計と判断を担い、Claude Code 上に作成とレビューを分けたエージェントの組織を置いた。さらに別のモデルを外部のレビュワーとし、コードと統計の最終確認は人間の補助者が行う体制をとっている [Issues-004 §論点1：AIを使う研究環境の整え方]。ここでは、確かめる役割が、別のエージェント、別のモデル、人間の補助者へと段階的に分けられている。

動かす場所の選択も、確かめ方の設計の一部である。未公開の学術調査写真の解析や、機微情報・著作権で保護された資料を扱う研究では、外部に送り出さずに解析するために、ローカル環境で LLM を動かす計画が複数の発表に見られる [Issues-004 §論点1：AIを使う研究環境の整え方]。

日常の作業への手応え

利用者の実感としては、時間の短縮が最も多く挙げられている。体裁の調整にかけていた時間が大幅に短縮され、本質的な作業に向き合う時間を長く取れるようになったという回答や、自分の書いた文章のレビューを何度も簡単に行えるようになったという回答がある [Issues-002 §論点1：AIの使い方]。

一方、どう使うかの実例を求める声は強い。アンケートでは、AI を使って達成できたプロジェクトや研究、プロンプトと結果の実例を知りたいという回答がある [Issues-002 §論点1：AIの使い方]。エージェントを協調させる方法についても、プログラマやエンジニア向けの情報は手に入りやすいが、もっと一般的なタスクでの使い方の勘どころが知りたいという回答がある [Issues-002 §論点1：AIの使い方]。ただし、回答者の構成は偏っている。有効回答 38 名のうち、ほぼ毎日使っている人が 17 名で、満足度の設問も肯定的な層に偏っている [Issues-002 §調査の方法と回答者の構成]。

文書の生成と検査の具体例としては、DiHuCo ガイドラインシステムの工程がある。その流れは節「AI でデータを作る」で扱う。