本記事では、Claude Codeを使ってコードの開発を伴う数理的な研究をしている中で、直面した課題について共有します。
問題の本質がどこにあるかを考察し、解決策として始めたSkillsの開発・導入の試みについてレポートします。
Claude Codeと進めている研究・開発の概要
今回の内容はあくまで一般論なので必須ではないのですが、一応、
実際にClaude Codeを使って行っているプロジェクトについて簡単に紹介しておきます。
人口の統計データを使って一日の人の移動について推定する数理的な方法を、
プログラミング言語・Pythonのコードで、開発・実装しています。
ちなみに、人の動きを地図上で考えるので、人口だけでなく、地理的なデータ（道路や鉄道も含む）も必要です。
データの事前の処理や、数理的な解析の際に使うデータが実空間のメッシュだったりグラフデータだったりすることもあり、全体的にコードそのものやプロジェクトを進める際の実装計画の判断が複雑になります。
AIとの研究・開発で課題となっていること
細部や状況固有の問題は多岐にわたるにせよ、
基本的には、以下が課題であると言えます。
- とにかく情報量が多すぎる
- 何が重要かがわからなくなる
以下、課題点を言語化・説明していきます。
大量の情報を処理し切れない
Claude Codeを使った開発や研究における一番の課題は、
AI生成により、わかりにくいコードが大量に出力されてくること、
そしてそれへの人間側の処理が追いつかないことにあります。
特に研究の場合、それなりの難易度の用語・概念が出てきます。
地味に困るのは、マイナーで、あまり一般的でないものも登場すること、
Claude Codeが独自に定義した言葉との区別が難しいこと、などです。
ターミナルでの回答やコードのコメント文にそれらが当然のように使われ、
十分かつ丁寧な説明もないままになっているわけですね。
生成させるプログラムそのものの品質の問題ではない
現在のAIは、コードに関してはかなりの質のものを生成してきます。
また、科学や技術に関しても、かなりの理解ができているようです。
先端的なAIが数学の難問を解決していることが話題になっていますが、
一般ユーザー向けのAIも、それほどではないものの、かなりのものです。
私はChat GPTと普段あたり前のように研究のディスカッションをしているくらいです。
本プロジェクトで使っているClaude Codeに関しては、
数理的な理論を実装まで一気に進め、しかも自律的に検証・改善まで行ってくれます。
これまでにコードを読んだり出力を見てきた限りでは、プログラム自体の大きな問題はありませんでした。
つまり、AIエージェントとの共同研究における中心的な課題はコードの可読性や人間との連携にあるわけですね。
何が本質なのか見えにくくなる
すでに書いた通り、AIは自律的に改善・検証をしてくれます。
それどころか、自ら提案までしてきます。
また、すでに立てた計画がある場合は、現在地点を教えてくれるので、進め方で迷う心配もありません。
ただしそれは、計画それ自体が問題がなければの話です。
通常のアプリ開発などのコーディングと違って、
研究の場合は、そこが最もクリティカルな部分です。
研究では、使っているモデルや（理論／計算の）方法論が本質を外していないかを常に考える必要があります。
AIが自律的に行うまたは提案してくる改善・修正は、すでに現在行っている方法に関するもの、
いわば局所的な改善ばかりです。
実際のところ、研究者、特に数理的なアプローチがメインの場合、は、
コードを書くよりも、扱う問題の背景にある理論や現象を考えることに最も時間を使うものです。
通常それは、コードの実装と足並みを揃えて進めることができます。
思いついた検証をすぐに試せたりするからです。
今回の場合は、少なくとも最初は既存の方法を考えている問題に当てはめるだけなので、AIに実装させました。
そこから、それなりに高度なことを要求しても平然と進めてくるので、いつの間にかかなりの量のAI生成コードが蓄積してしまったという点が問題です。
AIエージェントと研究する際の個人的な問題点
この他にも、問題の原因となっている要素があります。
Pythonは意外とわかりにくい
例えば、今回はPythonによりプログラムを実装していますが、
これが意外と読みにくいです。
Python自体は簡単な言語として知られていますが、
私がプログラミング経験を積んだのは科学技術計算で、FORTRANが主流でした。
後に学んだWebプログラミングなどに比べてわりと単純なイメージがあります。
Pythonだと、各種のライブラリを使ったり、キーを使うデータ構造とかがあるなど、
コードのシンプルさのわりには情報量が多いです。
動的型付け言語であるのもわかりにくさの要因かもしれません。FORTRANでは型宣言があり、注目している変数がどんなデータ構造なのかの確認がしやすかったです。
理論自体の考察が際限なく深まる
AIエージェントがコードを次々と生成するが止まらないのと同じように、
研究者は、理論を考察したり考案しようとしたりして、止まらなくなることがあります。
それは、コードを書く以前の基礎理論だったりすることもあれば、コードで実装しながらできることの場合もあります。
ただ、後者の場合でも、AIエージェントのような一直線に進む思考では、進めることは難しいでしょう。
AIエージェントと共同研究する際に起こる問題の本質
ここまでは個々の事象を見てきただけなので、問題意識が分かりにくいと思います。
本質的な問題は、2点です。
一つは、AIの思考は直線的すぎるので、研究として新しいことを考えるには向かないということです。
最近話題になった純粋数学のように問題が明確な場合は、また話が違いますが、
現実的な問題への対処や、未知の研究領域を切り拓くには、人間の研究者の創造性や想像力が必要です。
また、数学の未解決問題解決などは、長時間エージェント（しかも最新の非公開モデル）に作業させるので、コスト面で規模感が違う話でもあります。
もう一つは、人間の研究者が、AIをかなり使っているとしても自分の研究だと思えるようにするにはどうすればよいか、ということです。
Skills導入以前から行っている対策
以前から、Claude Codeを使いこなすための工夫はしてきましたし、
そもそも何も工夫しなくてもある程度はわかりやすいように自発的に工夫してくれてもいます。
例えば、何も指示せずとも、コードには日本語でコメント文が書かれています。
また、仕様書を作成させたり、質疑や作業内容などをドキュメントに記録させるようにもしています。
ただ、用語がわかりにくかったり、どこに何が書かれているかが非常にわかりにくいです。
Chat GPTとの対話などでも多くの人がよく経験すると思いますが、
内容について確認の質問をしても、大量の回答のどこが該当するのかわかりにくかったり、
こちらの意図を理解せずに論点を外していることもあります。
Claude Codeの場合は、回答がターミナルに出力されたまま流れてしまうという問題もあります。それをドキュメントに記録させても、元の会話とは違う形で記録されるので、多くの場合、後から見てもよくわかりません。
研究・開発の補助としてのSkillsの導入
Skillsとは、Claude Codeに行わせる作業のルールや手順を予めドキュメントに記載しておき使える仕組みのことで、
都度、必要なSkillを指定して指示を出すことで、毎回プロンプトにすべて入力するより効率的に指示できるもの、と理解しています。
Skillsで行うべき／行った対策
わかりやすいコードを出力させるのも大切ですが、おそらく限界があります。
また、多くの場合、問題には後から気づくものです。
（特に研究の場合は、専門用語の多用や独自用語をつくってくる問題があり、
そのやり方への代案はすぐは思いつきません。
また、今は新規で実装する前に計画検討のために立ち止まっている段階なので、
新たなコードを書く際の対策を試すことはできません。）
そこで、対策の一つとしては、生成されたコードを後から分析し、
人間が理解できるような形に情報をまとめることです。
このコード分析自体にもまだ先の構想もありますし、
他にも文献調査関係などもつくっていますが、
まずは以下のような分析結果を出力する機能を実装しました。
- コードに出てくる変数の型や意味を一覧にまとめる辞書的なもの
- 関数の定義箇所や呼び出し場所を、依存関係をまとめたもの
実は最初につくったものはもっと多くのことをできますが、
個人的な開発段階（Gemini api）から本番（Claude Code）に移行する際に、
作業の規模が大きくなりすぎないように慎重に制限をかけています。
Skillsの概要
冒頭を抜粋すると以下のようなものです。
（これは日本語訳版です。実際には英語版を使っています。）
---
name: code-explainer
description: ユーザーが指定したソースファイル、関数、メソッド、クラスを解説する。その対象から始め、理解に必要なコードだけを調べる。ユーザーがプロジェクト全体の分析を明示的に求めない限り、プロジェクト全体を探索しない。特定のコードがどう動くかを理解したいときに使う。
---
# Code Explainer
## 最重要：プロジェクトではなく、指定された対象から始める
ユーザーがプロジェクト全体の分析を明示的に求めない限り、プロジェクトの調査から始めてはならない。
1. ユーザーが指定したファイル、関数、メソッド、クラス、またはコード断片から始める。
2. 事前準備として、プロジェクトディレクトリの走査、プロジェクトファイルの列挙、プロジェクトアーキテクチャの把握を行わない。
3. 対象の場所が不明な場合は、その名前の対象を見つけるのに必要な最小限の検索だけを行う。対象の特定をプロジェクトの棚卸しに変えてはならない。
4. 分析を始められるほど対象が明確に指定されていない場合は、どのファイルまたはコード要素を解説してほしいのかを尋ねる。プロジェクト全体の分析を望んでいると決めつけない。
5. 対象の外へ広げるのは、現在のスコープ内では答えられない具体的な疑問に答える場合に限る。
プロジェクトルート、ワークスペース、リポジトリが存在することは、プロジェクト全体を分析する許可や必要性を意味しない。
## 1. 目的
既存コードの特定部分を人間が理解できるよう支援する。
これを所定のフォルダに配置しました。
Skillsを使った出力結果
以下は実際の出力内容の一部です。
いくつかのファイルに出力されるのですが、その一つのファイルの一部です。
02 シンボル索引 (Symbol Index)
本ドキュメントでは、humanflow/scripts/plot_bridge_drift.py にて定義される関数および主要モジュールシンボルの定義位置、引数、戻り値、責務、呼び出し関係、副作用、依存関係を詳細に記録します。
1 定義シンボル一覧
| シンボル名 | 種別 | 定義位置 | 責務概要 | 呼び出し元 | 主な呼び出し先 |
|---|---|---|---|---|---|
build |
関数 | line 37–73 | グラフ・周辺分布・遷移核・ポテンシャル系列等の初期状態構築 | main() |
load_graph, nighttime_marginal, daytime_ward_marginal, ward_aggregation, reference_kernel, reach_matrix, bridge_endpoints
|
drift_vectors |
関数 | line 76–88 | 参照過程を差し引いた目的地引力（追加最適ドリフト）ベクトルの算出 | main() |
scipy.sparse.csr_matrix.__matmul__, np.where
|
binned_field |
関数 | line 91–111 | ドリフトベクトルの空間 $26 \times 26$ ビンへの質量重み付き集約 | main() |
np.linspace, np.digitize, np.add.at, np.meshgrid
|
main |
関数（エントリ） | line 114–232 | A1（矢印場）、A2（差分マップ）、代表時刻大判図の生成・描画・ファイル保存 | __main__ |
build, drift_vectors, binned_field, load_zone_polygons, matplotlib.pyplot.*
|
意味が日本語でわりとわかりやすそうな感じで説明されているのがポイント高いです。
こうした出力により、人間の理解を比較的改善しそうだと感じました。
特に、研究で重要になるのは数式やアルゴリズムとコードの対応ですが、かなりの前進と言えそうです。
この記事は、株式会社Fieldとのプロジェクトの一環として投稿されました。
株式会社Fieldは、京都を拠点に、Webシステム開発とAI活用の支援を行っています。
https://field-company.co.jp/