ハクソク

世界を動かす技術を、日本語で。

テリー・タオによる最新のコーディングエージェントを通じた古いアプリと新しいアプリ

2026年7月12日原文(terrytao.wordpress.com)

概要

  • 1999年から 数学教育・研究のための 機械支援ツール 開発への関心
  • 古いJavaアプレット を AI支援でJavascriptへ移植、短時間で再機能化
  • AIエージェント によるコーディングで バグ発生率が低減、品質も向上
  • 新規アプリの開発も AI支援で実現可能性が拡大
  • 今後もインタラクティブな可視化ツール を論文・ブログに追加予定

数学教育・研究におけるAI支援ツール開発の軌跡

  • 1999年より、数学の可視化や教育のために Java 1.0でアプレット開発 を開始
  • 複素解析や線形代数の講義用 に、 honeycombsやBesicovitch集合 などの可視化アプレットを作成
  • 当時は成功したが、プログラミングの手間や Javaのウェブサポート終了 によりアプレットが非機能化
  • 最近、AI支援を活用して 古いウェブページやブログデータを 保守しやすいリポジトリへ移行
  • AIエージェントに依頼し、Javaアプレットを Javascriptへ数時間で移植、グラフィックも進化
    • 例： Besicovitch集合アプレット が モノクロからカラー化 へアップグレード
    • Allen Knutsonと共作のhoneycombアプレット も再生、手作業では困難だった部分も実現
  • LLMベースのコーディングエージェント はバグを生む懸念があったが、 20数個中1件のみ軽微なバグ
    • ドラッグイベントの挙動 に小さな不具合
    • 逆に AIが元のコードのバグ2件を発見、コード品質はプラスマイナスゼロ
  • アプレットは補助的役割 であり、バグによるリスクは低いと判断

AI支援による新規アプリ開発の可能性

  • 古いアプレット移植が容易だったため、新規アプリの開発にもAIを活用
  • 1999年に構想した特殊相対性理論の可視化ツール （Minkowski空間でのInkscape風アプリ）の再挑戦
    • 当時は Javaのコードが複雑すぎて断念
    • AIエージェントと数時間の対話で、当時のビジョン通りのアプレットを実現
    • コード生成過程の要約 も公開、技術的な詳細報告を整理して掲載
  • “アルファ版”アプレットのプレイテスト済み、さらなるフィードバックを希望
    • LLM生成コードゆえに、今後もバグや粗さの解消が必要

Gilbreath予想の可視化ツール開発と今後の展望

  • Gilbreath予想に関する論文ブログ執筆後、 AIエージェントに可視化ツール開発を依頼
    • 数時間の対話で完成、論文・ブログの補助教材として公開
    • 開発手順の記録も掲載
  • 今後も論文やブログの補助として、 インタラクティブな可視化ツールを追加予定
    • 補助教材であり、ミッションクリティカルでないため、AI生成によるリスク許容
    • AIとの対話型開発 で 効率的かつ革新的な教育・研究支援環境の実現

Hackerたちの意見

テリー・タオがコーディングエージェントを使ってアプリを作るってことは、フィールズ賞受賞者が「なんで俺のDockerコンテナが起動しないんだ？」ってLLMに聞く日も近いってことだね。まるで俺たちみたいに。

└

これはとても謙虚な考えだね、ありがとう。

└

LLMの前にも、プロのソフトウェアを作るフィールズ賞受賞者がいたんだよね。[0]: https://en.wikipedia.org/wiki/Martin_Hairer [1]: https://www.hairersoft.com/

└

逆に、コーディングエージェントがテリー・タオに「自分たちが取り組もうとしている証明はフィールズ賞に値するか？」って聞くのを待ってるよ。

最後のバランスの取れた視点がいいね。「このような[LLMでコーディングされたインタラクティブな]補助は論文の核心にとってミッションクリティカルではないので、LLMエージェントとのガイド付きインタラクションを使ってこういったビジュアライゼーションを生成するリスクは許容できると思う。」ツールなんだよね。いいところもあれば、ダメなところもあって、基本的には信頼しすぎない方がいい。

└

そして一般的に信用されるべきではない こういうAIに懐疑的な人たちがいて、タオの数学的証明に関するLLMの発言を引用して、これらのシステムがどれだけ進んでいて自律的かを示す例として挙げてるんだよね。

└

それは道具だよ。いくつかのことには良いけど、他のことにはあまり向いてないし、基本的には信頼しない方がいい。LLMエージェントの仕事は常にチェックする必要があるって完全に同意するけど、「信頼する」って言葉を使ってAIを擬人化するのがちょっと面白いなと思う。一方で、無チェックの出力を使ってAIを擬人化するのは警告しているわけだし。 ;) 一般的に言って、AIへの「信頼」はモデルやハーネスが改善され、人々が効果的なワークフローを見つけるにつれて急速に上がってるよ。釘にはハンマーを信頼するけど、ネジには信頼しない…それってハンマーが一般的に信頼されるべきじゃないってことになるのかな？AIの問題は、釘とネジの違いが分からないことなんだ。（ここで俺のアナロジーが崩れるかも。 :P）でも、「信頼しないで」って言うよりも、もっと計画や反復に時間をかけることを期待するべきだとか、出力をレビューしてチェックするのにもっと時間をかけることを期待するべきだとか、スキルやコンテキスト、サブエージェントの使い方を学ぶべきだって言った方が役に立つと思う。AIを使うのは、まずは非生産的で影響の少ないプロジェクトから始めるべきだよ。「一般的に信頼しない方がいい」って言うのは、暗にAIを使わない方がいいって示唆してるし、読者にAIの使い方を教えてないよね。目標は、良いワークフローを構築して、何がうまくいくか、何がうまくいかないかを理解することで信頼を築くことだよね？

└

この文脈で「信頼」って何を意味するのかよくわからない。たとえドナルド・クヌースを雇って全てのコードを書いてもらったとしても、それがバグフリーだとは「信頼」できないし、自分のニーズに合っているとも思えないよ。

記事の不自然な冒頭の文が、これがAIによって書かれたものでないことを証明してる。1999年から、数学を教えたりするための機械支援の方法に興味があって、Java 1.0でいくつかのアプレットをコーディングしてたんだ。複素解析や線形代数の授業で、ハニカムやベシコビッチ集合みたいな興味のある数学的なオブジェクトを可視化するためにね。

└

これぞテレンス・タオスタイルって感じだね。彼のスタイルは、短く分けられるはずの長い文をそのまま使うことなんだ。でも、読解力にはあんまり影響しないよ。

└

俺は毎回、クロードのリライトなんかよりこれを選ぶわ。

自分は数学者とは程遠いけど、AIを使ってもっと数学を生み出せる可能性にワクワクしてる。数学は自分の中では形の世界にしか存在しなくて、利益のために利用されるものじゃないけど、他のすべてに影響を与えるものだと思ってる。これが何を可能にするのか楽しみだな。

Hacker Newsで議論の続きを見る