はじめに：電気羊の代わりにNotebookを
『アンドロイドは電気羊の夢を見るか？』という問い
フィリップ・K・ディックが1968年に発表したSF小説『アンドロイドは電気羊の夢を見るか？』は、映画『ブレードランナー』（1982年）の原作として知られています。
舞台は、最終世界大戦後の放射性降下物に覆われた地球です。多くの人は火星へ移住し、地球に残った人々の間では、本物の動物を飼うことが何よりのステータスになっています。動物の多くが絶滅し、生きた動物はとても高価だからです。
主人公のリック・デッカードは、サンフランシスコ警察に雇われたアンドロイド狩りの賞金稼ぎです。彼のアパートの屋上にいる羊は、実は電気仕掛けの偽物です。隣人に見栄を張りながら、デッカードはいつか本物の動物を買いたいと願っています。
ある日、火星から最新型アンドロイド「ネクサス6型」が数体逃亡し、地球に潜伏します。ネクサス6型は、外見も会話も知能も人間とほとんど変わりません。見た目では見分けられない相手を見分けるために使われるのが、「フォークト＝カンプフ検査」です。感情を揺さぶる質問を投げかけ、頬の毛細血管や瞳孔のわずかな反応を測ります。人間なら自然に生じる共感の反応が、アンドロイドでは遅れたり欠けたりする、という前提に立つ検査です。
物語が進むにつれ、境界はどんどんあいまいになります。自分が人間だと信じていたアンドロイドが現れ、デッカード自身も「自分は本当に人間なのか」と揺らぎ始めます。人々が共感を確かめ合う宗教「マーサー教」でさえ、作り物ではないかという疑いが持ち上がります。
そして物語の終わり近く、荒野で一匹のヒキガエルを見つけたデッカードは、絶滅したはずの本物だと喜びます。しかし、それも電気仕掛けでした。それでもデッカードは、電気仕掛けのものにもそれなりの生があるのだと受け入れていきます。
本物か偽物か。共感があるのか、あるように見えるだけなのか。そして、偽物だとわかったうえで、それとどう付き合っていくのか。小説が投げかけるのは、そうした問いです。
AI Data Scientistにも同じ問いが生まれる
AIにデータ分析を任せるとき、私たちは同じ問いに向き合います。
AIの書いたNotebookには、コードが並び、図が描かれ、もっともらしい結論が書かれています。見た目は、人間のデータサイエンティストが書いたものとほとんど変わりません。では、このAIは本当に分析しているのでしょうか。それとも、分析しているように見えるだけなのでしょうか。
本稿では、筆者が開発したGitHub Copilot Agent Skillの Jupytermind : AI Data Scientist に、Kaggleの課題を100問解かせました。その結果から、Jupytermindにできたことと、まだできないことを、フォークト＝カンプフ検査になぞらえて整理します。
本稿の数値は、100件の実験で生成されたNotebook・実行ログ・監査結果を集計したものです。各実験の記事はAIが生成しています。分析内容を人間が一件ずつ独立に査読したものではありません。
先に結論
- できたこと：キノコの毒性分類で正解率100%が出たとき、AIは自分でその結果を疑いました。追加分析では、未知の種類のキノコに対する毒キノコの検出率が28.31%まで下がることを示しています。IoTセンサーの課題でも、精度0.9994という結果の裏に隠れたデータ漏れを見つけました。
- できなかったこと：監査は、本文が引用値と正反対のことを言っていても合格にしてしまいます。AIが存在しない不具合を報告したこともありました。
- わかっていないこと：100問の完走は「処理が最後まで回った」ことの証明です。分析の正しさを人間が採点したわけではありません。素のCopilotや人間との比較もしていません。
- これから：見つかった限界はGitHub Issueに登録しています。12件は修正済みで、7件が改善を待っています。
Kaggleとは
Kaggleは、データサイエンスと機械学習のためのオンラインプラットフォームです。2010年に始まり、2017年からはGoogleの傘下にあります。主な機能は次の3つです。
- Competitions：企業や研究機関が出す課題に、世界中の参加者が予測モデルの精度を競います。
- Datasets：誰でも公開・ダウンロードできるデータセットが大量にあります。タイタニック号の乗客、キノコの特徴、Spotifyの楽曲など、題材は多彩です。
- Notebooks：ブラウザ上で分析コードを書いて実行し、他の人と共有できます。
データサイエンティストの「練習場」として定番の場所です。AI Data Scientistの腕試しにも、ちょうどよい題材がそろっています。
Jupytermindとは
Jupytermindは、自然言語で分析の目的を伝えると、Jupyter上で分析を組み立てて実行するAgent Skillです。
筆者が開発し、GitHubでオープンソース（MITライセンス）として公開しています。つまり本稿は、作者が自分の作ったアンドロイドにフォークト＝カンプフ検査をかけてみた記録でもあります。身内びいきにならないよう、不具合は最小再現で確かめたものだけを取り上げました。
- 分析計画を立て、Kaggle APIからデータを取得し、前処理、統計、可視化、解釈まで進めます。
- コードはJupyter MCP経由で実行し、コード・出力・図表をNotebookへ残します。
- 結論（Insight）には、根拠となる実行番号と引用値を
evidenceとして付けます。根拠が見つからない結論は書き込みを拒否します。 -
notebook_auditが、未実行セル、エラー、根拠の欠落、図表の可読性を検査します。
この notebook_audit が、本稿でいうフォークト＝カンプフ検査にあたります。AIの書いたNotebookが「それらしく見えるだけ」でないかを、機械的に確かめる仕組みです。
実験の設定
| 項目 | 内容 |
|---|---|
| 課題 | Kaggleの公開データセットから選んだ100問。定番のデータセット50問（Titanic、Iris など）と、新しく選んだデータセット50問（保険料、キノコ、SMSスパム、LEGO など）。無作為抽出ではありません |
| Jupytermindの版 | 前半50問と後半50問の間で不具合を修正したため、前半と後半で版が異なります |
| 使用したAIモデル・費用 | 記録していません |
| 比較対象 | なし（素のCopilotや人間の分析者とは比較していません） |
| 人間による検証 | 不具合の報告は最小再現で確認しました。分析の正しさは、人間が一件ずつ採点していません |
| 並列数 | 10件を同時実行（起動は20秒間隔、失敗時は自動再試行） |
| 1件の流れ | 初回分析 → AIが自分で追加依頼を作る（最大3回） → 全セル再実行 → 監査 → 記事化 |
人間が決めたのは、課題と分析の問い、共通の制約だけです。初回プロンプトの文面、追加分析の内容、記事の本文は、すべてAIが作りました。
できたこと：AI Data Scientistの「夢」が叶った部分
最初の結果で終わらず、自分で考察して深掘りする
Jupytermindの一番の特徴は、最初のプロンプトで得た結果を「答え」として扱わないことです。結果を自分で読み直して考察し、次に確かめるべき問いを立て、追加の分析を自分で依頼します。
考察のたびに、AIは次のような問いを自分に投げかけます。
- この結果は出来すぎていないか。データの漏れや偏りで説明できないか。
- 別の指標や集計方法でも、同じ結論になるか。
- これは因果なのか、相関にすぎないのか。
- 見たことのないデータでも通用するか。
人間が最初に渡すのは、課題と分析の問いだけです。そこから先の「なぜ？」「本当に？」は、Jupytermindが自分で問い続けます。この深掘りのループによって、次のようなことが実現できました。
100問すべてを最後まで完走した
| 指標 | 結果 |
|---|---|
| 完了件数 | 100 / 100 |
| コードセル（実行済み / 合計） | 1,496 / 1,498 |
| エラーのあるセル | 0 |
| 図表セル | 384 |
| 根拠付きInsightセル | 703 |
| 1問の所要時間（中央値） | 約29分 |
未実行の2セルは、Notebook末尾の監査セルが自分自身を検査したもので、仕様上の除外対象です。
途中で失敗した実験もありました。原因はいずれも、Copilot CLIの起動タイムアウトなど実行基盤の側です。自動再試行で全件が完了しました。夜に10件ずつ流しておけば、朝には大量のNotebookと記事がそろっています。データサイエンティストが電気羊を数えて眠っている間に、Jupytermindが分析を進めてくれる、というわけです。
「エラー0件で完走」は、処理が最後まで回ったことを示す指標です。分析の結論が正しいことを示すものではありません。
「出来すぎた結果」を疑い、データ漏れを見抜いた
深掘りのループが最もよく効いたのは、精度が高すぎる結果を疑う場面です。
キノコの毒性分類：正解率100%
-
決定木のテスト正解率が 100% になりました。
-
AIはこれを喜ばず、次の依頼を自分で書きました。
決定木のテスト正解率100%が、ラベル混入や欠損パターンだけによる見かけの性能でないか確認してください。
-
調べると、無臭のキノコ3,528件のうち120件（3.40%）に毒性ラベルが付いていました。
-
胞子紋の色のカテゴリを丸ごと学習から外して評価すると、balanced accuracyは57.57%、毒キノコの検出率（再現率）は28.31%まで下がりました。
最初のプロンプトの結果だけなら、「100%なので完璧です」で終わっていました。考察と深掘りを重ねたことで、「見たことのない種類のキノコには通用しない」ところまでたどり着いています。食べる前に読んでおきたい分析です。
IoTセンサーによる火災報知：精度0.9994
ランダムに分割して評価すると、balanced accuracy（陽性・陰性の再現率の平均）は0.999403でした。ほぼ完璧です。AIは追加分析でデータの並びを調べ直し、同じセンサー系列と報知ラベルが別の収録区間で使い回されていることを見つけました。学習に使っていない系列だけで評価し直すと、全センサーを使うモデルは火災報知（陽性）をすべて見逃しました。
3回の追加依頼を経て、結論は「ほぼ完全に判定できる」から「既知の系列を再現できることと、未知の系列に通用することは分けて考える必要がある」に変わりました。テストの答案が、実は過去問の丸写しだったと気づいたようなものです。
結論を言い過ぎなかった
考察を重ねる中で、AIは結論を言い過ぎないように振る舞いました。ただし、これは因果を「識別した」のではありません。証拠が足りないときに、因果を「主張しなかった」ということです。
因果を主張しなかった
- Spotify：音響特徴よりジャンルの方が人気度をよく予測すると示しました。そのうえで「ジャンルを変えれば人気が上がるという因果効果は示していない」と明記しています。
- 顧客分析：高収入層の反応率は高いものの、購入額で調整すると独立した効果は確認できないと報告しました。
- LEGO：部品数の「平均」は増えましたが、「中央値」は集計方法によって −12.5〜+4個と揺れました。そのため「典型的なセットが大型化した」とは結論していません。
結論の強さを証拠の強さに合わせる姿勢は、人間の分析者でも身につけるのが難しいものです。一度の分析ではなく、考察と検証を繰り返したからこそ、こうした慎重な結論にたどり着けました。
単純な相関の「逆転」に気づき、点検候補につなげた
太陽光発電所のデータでは、気温と発電量の単純な相関は「正」でした。気温が高いほど、よく発電しているように見えます。ところが、日射量・時刻・日付の影響を調整すると、気温の係数は「負」に逆転しました。晴れて日射が強い日は気温も高いので、見かけ上は正の関係になっていたと考えられます。なお、太陽光パネルは高温で効率が下がるとされており、この結果と矛盾しません。ただし、これは筆者の事前知識による補足で、今回のデータから示したものではありません。
さらにAIは、出力の低いインバータ（発電機器）を「点検候補」として挙げました。ただし「故障」とは断定していません。順位は分析条件によって変わること、データの欠測や発電所全体の停止と区別したことも明記しています。現場の担当者が次に何をすればよいかまで落とし込みつつ、言い過ぎてもいません。
比較する範囲で結論が変わることを示した
世界の大学ランキング（THE、ARWU、CWUR）が互いにどれだけ一致するかを調べた課題です。AIはまず、ランキングごとに表記が異なる大学名を照合しました。似ているだけの名前は自動では採用していません。
結果は、比べる範囲によって変わりました。照合できた全大学で比べると、ARWUとCWURの順位が最もよく一致します。ところが、両方のトップ100に入る大学だけで比べると、最も一致するのはTHEとARWUの組み合わせに入れ替わりました。AIは「どのランキングでも代わりに使える」とは結論せず、名前の照合方法と比較範囲を明示したうえで解釈するよう求めています。
わからないことを「わからない」と書けた
Jupytermindは、データの各項目の定義や単位を「確認済み」「推定」「未確認」に分けて記録します。わからないことを、わかったふりで埋めないための仕組みです。
火災報知の課題でも、AIはデータの「Fire Alarm」列を、実際に火災が起きたかどうかの正解とはみなしませんでした。分析の対象を「記録された報知ラベルをどこまで再現できるか」と定めています。データの名前をうのみにせず、それが何を測ったものかを確かめてから分析する。地味ですが、データサイエンスで最も大事な作法の一つです。
不確実性を数字で添えた
結論には、どれくらい確かなのかを添えました。100問のうち79問で、信頼区間やブートストラップ（データを繰り返し再標本化して、ばらつきを見積もる方法）の結果を出力しています。ただし、その使い方が妥当だったかまでは、人間が一件ずつ確かめていません。
分析の条件を変えても結論が保たれるかを調べる感度分析も行いました。森林の被覆タイプの課題では、水源との比較で9通り、標本数やモデルを変えて4通りの条件を試しています。「この数字です」と1つだけ示すのではなく、「このくらいの幅で、この条件なら」と示す姿勢です。
自分の不具合の候補を報告した
深掘りの対象は、データだけではありません。分析の途中で道具がうまく動かなかったときも、AIはその原因を考察しました。各実験では、こうして見つかったJupytermind自身の不具合を「改善候補」として記録させました。候補を出したのはAIですが、Issueに登録したのは、人間が最小再現で確かめたものだけです。修正版で解消も確認しています。
分析をしながら、自分の道具の不具合まで報告するAIです。アンドロイドが自分の修理票を書いているようなものです。
限界点：まだ電気羊は電気羊、でも改良できる
Jupytermindには、まだ多くの限界があります。ただし、ここで紹介する限界は「行き止まり」ではありません。見つかった限界は、最小再現で確かめたうえでGitHub Issueに登録しました。Issueになった限界は、直すべき課題として改善の順番を待っています。
実際に、この100問の実験の途中でも、このサイクルは回っています。前半の実験で見つかった不具合のうち12件（#27〜#38）は、すでに修正されてクローズしました。ここからは、後半の実験で見つかり、Issueとして改善を待っている限界を紹介します。
監査（フォークト＝カンプフ検査）をすり抜ける答えがある
notebook_audit は、引用値が出力に存在するかを確かめます。ところが、本文の内容までは読んでいません。
# 出力は macro_f1=0.954、引用値も 0.954
md("macro-F1 は 0.123 と低く、モデルは使えません。" + evidence(1, "0.954"))
audit_notebook(nb_path).ok # True
根拠の欄は正しいのに、本文はまったく逆のことを言っています。それでも監査は合格です（#45）。
ほかにも、次の抜け道が見つかり、Issueに登録しました。
「監査に合格した」ことは、「結論が正しい」ことを意味しません。検査表に載っていない質問には、アンドロイドは何とでも答えられます。
改善の余地：Insightの本文と引用値の食い違いを検出する機能を、Feature要望として登録しました（#45）。検査表に新しい質問が加われば、フォークト＝カンプフ検査はそれだけ鋭くなります。
図表の「身分証明書」が自動では残らない
図のタイトルや凡例などの情報（metadata.chart）は、record_chart で保存すれば監査できます。
ところが、エージェントが実際によく使うのは、Jupyter MCPで画像を表示する別の経路でした。この経路では情報が残らず、図が「未監査」になります。各実験のAIは、Notebookを閉じてから情報を手で書き写すことで回避していました（#40）。
正規の手続きは用意されていたのに、肝心の利用者がその道を通っていなかったわけです。
改善の余地：この問題は、前半の実験で見つかった不具合（#35）を直した結果、見えてきたものです。1つ直すと、次の課題が見えてくる。改善のサイクルが回っている証拠でもあります。画像を表示する経路でも図表の情報が残るよう、#40で修正を待っています。
AIの自己評価は、ときどき夢を見る
ある実験のAIが「凡例が画像の右端で切れている」と報告しました。保存されたPNGを確かめると、右端3列のピクセルに暗い画素は1つもなく、凡例は枠ごと画像に収まっていました。存在しない不具合を見たわけです。
デッカードが本物だと信じたヒキガエルのように、AIの報告も確かめるまでは本物かどうかわかりません。AIの「不具合あり」報告をそのまま集計していたら、存在しない不具合を数えていたことになります。そこで、不具合の報告はすべて最小再現で一件ずつ確かめてから扱いました。
改善の余地：AIの報告は、改善のための貴重な「候補」です。ただし、Issueに登録するのは最小再現で確かめたものだけです。人間が確かめる関門を通すことで、AIの寝言でIssueが埋まることを防ぎ、改善のサイクルの質を保てます。
道具の引き出しがまだ少ない
-
render_chartが描ける図は、散布図・折れ線・棒・ヒストグラムの4種類だけです。箱ひげ図や横棒、ヒートマップは描けず、Matplotlibで自作する実験がありました（#46）。 - 拡張子が
.csvのタブ区切りファイルを、警告なしに1列として読み込みます。29列のデータが1列になりました（#42）。 - SKILL.mdの利用例
register_run(run_id)は、実際には必須の引数が足りずTypeErrorになります（#41）。説明書のとおりに動かすとエラーになるのは、人間の書いたドキュメントでもよくある話です。
改善の余地：3件とも、原因と再現手順がはっきりしているので直しやすい部類です。図の種類が増え、ファイル形式の判定が賢くなり、説明書が正しくなれば、AIが手作業で回り道する場面は確実に減ります。
時間とお金はそれなりにかかる：AI利用は従量課金
Jupytermindは、GitHub Copilotのエージェントとして動きます。AIの利用は従量課金です。プロンプトを1回送るたびに、利用枠（プレミアムリクエスト）を消費します。消費量は使うモデルによって変わり、枠を超えた分は追加料金になります。
ここで効いてくるのが、「できたこと」で紹介した深掘りのループです。1問を解くたびに、次のやり取りが発生します。
- 初回分析
- 結果の考察と追加依頼（最大3回）
- 全セル再実行と監査
- 記事化
さらに各段階の中でも、AIはコードの実行、結果の確認、修正を何度も繰り返します。深く考えるほど結論の質は上がりますが、そのぶん課金も積み上がります。100問を解けば、その100倍です。起動タイムアウトによる再試行も、やり直した分だけ費用がかかります。
時間も同じです。1問あたり約29分で、そのうち記事化に約7分かかりました。50問を10並列で回して約3時間です。人手よりずっと速い一方で、「ボタン一つで一瞬、しかもタダ」ではありません。なお、今回の実験では使ったモデルや費用を記録していないため、具体的な金額は示せません。
大量に実験を回す前に、使うモデルと利用枠の残りを確認し、予算の上限を設定しておくことをお勧めします。電気羊の餌代は、意外とかさみます。
この実験そのものの限界
この記事の結論には、検証方法の限界もあります。
- 比較対象がない：素のCopilotや人間の分析者と比べていないので、どこまでが「Jupytermindだからできた」ことかは言えません。
- 正しさを採点していない：100問の分析の正しさを、人間が一件ずつ採点していません。本文の事例は、実験記録から印象的なものを選んでいます。
- 課題は選んだもの：無作為抽出ではなく、定番のデータセットと新しく選んだデータセットです。Kaggleの課題全体への一般化はできません。
- 費用を記録していない：使ったモデル、リクエスト数、費用を記録していません。
素のCopilotとの比較と、一部の課題の人手採点は、今後の課題です。
分析の妥当性は、最後は人間が判断する
Jupytermindが保証するのは、Notebookが再実行でき、結論に根拠のリンクがあることまでです。データの代表性、因果の識別、外部妥当性の判断は、人間の仕事として残ります。
限界は、進化の設計図になる
この章で挙げた7件のIssue（#40〜#46）は、Jupytermindの「次の進化の設計図」です。
| 限界 | Issue | 改善後にできるようになること |
|---|---|---|
| 本文と引用値の矛盾を見抜けない | #45 | 監査で、言っていることと根拠の食い違いを検出できる |
| 見出し付きの結論や2つ目の根拠を検査しない | #43、#44 | 監査の抜け道がふさがる |
| 図表の情報が自動で残らない | #40 | すべての図表を、手作業なしで監査できる |
| 描ける図の種類が少ない | #46 | 箱ひげ図やヒートマップを、標準機能で描ける |
| タブ区切りCSVを1列で読む | #42 | データの読み込みミスに、最初の段階で気づける |
| 説明書の例が動かない | #41 | 説明書のとおりに動く |
実験で限界を見つけ、Issueに登録し、直して、また新しい課題で試す。このサイクルを回すたびに、Jupytermindは一歩ずつ進化していきます。電気羊が本物の羊に近づいていくように。
進化の過程は、GitHub Issueに記録されている
このサイクルの記録は、すべてGitHub Issueに残っています。各Issueには、限界を見つけた実験、最小再現のコード、修正前と修正後の挙動が書かれています。前半の実験で見つかった#27〜#38の12件はクローズ済みで、後半の実験で見つかった#40〜#46の7件が改善を待っています（#39はJupytermindの分析機能とは別件です）。クローズ済みのIssueをたどれば、Jupytermindが何につまずき、どう直してきたかを追体験できます。
たとえば#35（図表の情報が保存されない）を直したら、別の経路の問題（#40）が見えてきました。#30（見出し付きセルの根拠を検査しない）を直したら、根拠のない見出し付きセルが素通りする残りの問題（#43）が見つかりました。Issueの番号の並びそのものが、Jupytermindの成長記録です。
デッカードの時代に必要だったのはフォークト＝カンプフ検査の結果でしたが、AI Data Scientistの「履歴書」はIssueトラッカーにあります。どこまで本物に近づいたかは、誰でもそこで確かめられます。
まとめ：JupytermindはAI Data Scientistの夢を見るか？
夢は見ています。ただ、まだときどき寝ぼけます。
- 夢が叶った部分：Kaggleの課題100問を最後まで完走し、エラーセルは0件でした。結果を自分で疑って追加分析を組み立て、データ漏れや相関の逆転に気づき、因果を言い過ぎませんでした。わからないことは「わからない」と書き、不確実性を数字で添え、自分の不具合の候補まで報告しました。
- 寝ぼけている部分：監査が本文の矛盾を見抜けない、図表の情報が自動で残らない、AIが存在しない不具合を報告する、といった限界が残っています。
- まだわからない部分：分析の正しさの採点と、素のCopilotや人間との比較は、まだしていません。
- 進化していく部分：限界は最小再現で確かめてIssueに登録しました。前半の実験で見つかった12件はすでに修正済みで、残る7件（#40〜#46）が次の改善を待っています。
小説の中で、人間とアンドロイドの境界は最後まであいまいなままでした。それでもデッカードは、電気仕掛けのヒキガエルを受け入れました。AI Data Scientistとの付き合い方も、同じかもしれません。本物かどうかを notebook_audit と最小再現で確かめ、偽物の部分を知ったうえで使いこなす。限界を見つけ、Issueにし、直して、また試す。検査の質問を一つずつ増やしていくこのサイクルこそが、Jupytermindを夢から現実へ近づける一番の近道です。
試してみる・一緒に進化させる
- 試す：JupytermindのREADMEの手順でインストールし、自分の関心のあるKaggleデータセットで分析を依頼してみてください。
-
確かめる：結果を鵜呑みにせず、Notebookの根拠と
notebook_auditの結果を確認してください。 - 報告する：限界や不具合を見つけたら、ぜひIssueで教えてください。最小再現があると、修正が早く進みます。
参考
- Jupytermind（GitHub）
- Kaggle
- フィリップ・K・ディック『アンドロイドは電気羊の夢を見るか？』（浅倉久志訳、ハヤカワ文庫SF）