AIの最初の退屈なエンジニアリングは、TikZから始まった
午前2時、論文締切まであと6時間。あなたは3枚目の図——ニューラルネットワークのアーキテクチャ図——を見つめ、\drawの座標を何度目かの微調整にかかっている。(4.5,3.2)を(4.6,3.1)に変え、コンパイルし、PDFを見て、違う、戻して、またコンパイル。指導教官の「図はきれいに描け、レビュワーがちゃんと読む気になるから」という言葉を思い出し、調整を続ける。時計の針は3時を指す。
LaTeX論文を書いたことのある者なら誰でもこの場面を経験している。TikZはLaTeXエコシステムで学術図形を描くデファクトスタンダードだが、それは「グラフィック言語」であって「グラフィックツール」ではない——作者のTill Tantauですらドキュメントにわざわざこう書いている：TikZ ist kein Zeichenprogramm（TikZはお絵かきプログラムではない）。コードで図を描き、座標を微調整するたびに文書全体を再コンパイルする。学界は何十年もこれを背負ってきた。
2026年6月、Dominik Petersという開発者がHNであるプロジェクトを公開した：TikZ Editor——WYSIWYGのTikZ図形エディタであり、Figmaのようにノードをドラッグでき、ソースコードが同期更新される。293ポイント、58コメント。このプロジェクトを本当に議論に値するものにしているのは、それがどのように作られたかだ。
「人間がやりたがらないこと」
Dominik PetersはShow HNの投稿で、このプロジェクトの核心的命題を直接的に提示する一文を書いた：
This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.
この文をより率直に言い換えれば：ドラッグ可能なTikZエディタを作るには、TikZの大部分の基盤メカニズム——パーサー、レンダラー、レイアウトシステム、カラー処理——を再実装する必要がある。これはROIが馬鹿げているほど低いエンジニアリングタスクであり、まともな人間は引き受けない。
だがCodexは引き受けた。プロジェクト全体——フロントエンドUI、Tauriデスクトップアプリケーション、TikZ構文パーサー、JavaScriptベースのSVGレンダリングパイプライン、複数フォーマットコンバータ（SVG/PPTX/IPE → TikZ）、そしてあの「常軌を逸した」と言うべきサイドクエスト群——これらはほぼすべてCodexによって生成された。Dominikは2026年2月からこのプロジェクトを進め、約7億tokenを消費、API料金換算で約1.5万ドル——実際に支払ったのは約500ドルのChatGPTサブスクリプション料のみだった。
ロジックの連鎖は明確だ：開発コストがゼロに近づくとき、本来「やる価値がない」プロジェクトが突然やる価値のあるものになる。 この命題自体は新しいものではない。しかしTikZ Editorは、AIコーディングツールが具体的にどのような種類のエンジニアリング労働を引き受け——そして明確に何を引き受けていないのか——を分解できるだけの十分な精度を持ったケースを提供している。
アウトソースされた二種類のエンジニアリング作業
TikZ Editorの実装に関わる作業は二つのカテゴリに分けられる。筆者はここで区別を設ける。
第一類：機械的なフォーマット変換。 これにはSVG→TikZ、PPTX→TikZ、IPE→TikZなどのコンバータが含まれる。これらのコンバータのロジック的複雑さは低くない——SVGのパスコマンドをTikZの\draw構文にマッピングし、PowerPointのシェイプモデルをTikZのノードとパスに翻訳する——が、本質的にはマッピングルールと境界条件のエンジニアリングだ。ルールは列挙可能であり、境界はテストケースでカバーできる。経験豊富なエンジニアが3週間かけて完了し、完了後に何ら深い洞察を得たとは感じない類の作業が想像できる。この種の作業は、AIコーディングツールが比較的信頼性高く処理できる。検証が二値的だからだ：変換後のTikZはコンパイルを通ったか？レンダリング結果は元のフォーマットと一致するか？
第二類：未知の領域で古典的アルゴリズムを再実装すること。 こちらがより興味深いカテゴリだ。Dominikは投稿でいくつかの「サイドクエスト」に言及しており、そのうち二つを掘り下げる価値がある：
-
LaTeXの改行アルゴリズム（Knuth-Plass）の再実装。複数行テキストノードをサポートするため、TikZ Editorはブラウザ側（JavaScript環境）で正しい改行とハイフネーションを実装する必要があった。これはDonald KnuthとMichael Plassが1981年に発表した動的計画法による改行アルゴリズムを再現することを意味する——このアルゴリズムは段落の「不良度」をグローバルに最適化することを目標とし、単純な貪欲法による行充填ではない。ブラウザ側のCSS
text-align: justifyは単一行の貪欲改行のみを行い、結果は粗い。TeXのアルゴリズムはグローバル最適を計算し、単語間グルー（glue）の伸縮、ハイフネーションペナルティ、段落全体の美的スコア関数を扱う必要がある。 -
red!20!blackカラー混合システムの実装。LaTeX論文では、色は頻繁に{色1}!{比率}!{色2}の構文で混合される（例：red!20!blackは20%の赤と80%の黒を混合）。ブラウザ側でこの構文をサポートするカラーピッカーを実装するには、xcolorパッケージから正確な混合モデルをリバースエンジニアリングし、RGB/CMYKの変換、透明度計算、および!演算子のネスト（例：red!20!blue!50!green）を処理する必要がある。
筆者がこの二つを同じカテゴリに分類するのは、それらがある性質を共有しているからだ：やらなければ機能が不完全になり、やってもコア能力がそれによって明確になるわけではない。 これは典型的な「退屈なエンジニアリング」だ——重要でないわけではない、ROIが低すぎるのだ。人間のエンジニアがこの種のタスクを見たときの第一反応は「これを迂回できる既存のライブラリはないか」だ。もしなければ、その機能はしばしばWONTFIXのラベルを貼られる。
そして、AIコーディングツールのこの種のシナリオにおけるパフォーマンスは非常に興味深い。DominikはHNのコメントで具体的なワークフローを共有している：彼はまずLaTeXエンジン（dvisvgm）とJavaScriptレンダラーでそれぞれ同じTikZ図を処理し、次に人手で差分を比較し、合わない箇所をCodexに伝え、修正させた。彼はマルチモーダルモデルに自動比較を試みたが、うまくいかなかった——モデルは「まだやや盲目で、明らかに異なる二つの画像でも同一だとみなす」という。
ここに微妙なディテールがある：loopにおける人間の役割は判断を下すことだ。 どのレンダリング差異がバグで、どれがフォントレンダリングの正常な偏差で、どれが許容可能かを判断する。人間は消えたわけではない——実装者から品質審判員に変わっただけだ。
Armin Ronacherの後半の一文
TikZ Editor発表の前日、FlaskとJinja2の作者であるArmin Ronacherは彼のブログ「The Coming Loop」で、この出来事と正確な対話を形成する判断を書いた：
I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.
そして彼は言葉を翻す：
On the other hand using that same looping methodology to write lasting code does not yet sit well with me.
Ronacherの核心的憂慮はここにある：ハーネスloopが回り続け、各イテレーションで局所的な防御を追加し、コードが人の目なしに自己増殖するとき、最終産物はそれ自身のメンテナンスを必要とする有機体になる。 彼はこれを「ソフトウェアが決定論的マシンから有機体に変わる」と呼ぶ——あなたはそれを監視し、安定させるが、理解はしない。
しかし彼のもう一つの言葉がより重要かもしれない：
Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.
Ronacherはloopがすでに二つのシナリオでうまく機能していると考える：コード変換（移植、ベンチマーク、セキュリティスキャンを含む）と、長寿命を必要としないコード（proof-of-concept、実験的探索）。
ここに興味深い対応関係が現れる。筆者はそれを表にしてみる：
| カテゴリ | 代表タスク | AIの習熟度 | 理由 |
|---|---|---|---|
| 機械的変換 | コード移植、フォーマット変換 | 得意 | マッピングが列挙可能、検証が二値的 |
| 退屈なエンジニアリング | Knuth-Plass再実装、カラー混合 | 得意 | ロジックが決定論的、インターフェースが明確、ROIが人間の投入意欲を下回る |
| アーキテクチャ判断 | プロジェクト構造、抽象化階層 | 不確定 | 価値観のトレードオフを含む |
| デザイン判断 | 何の図を描くか、どうレイアウトするか | 代替不能 | 意図と審美的判断が必要 |
TikZ Editorはまさに最初の二行を横断している。フォーマット変換は一行目、アルゴリズム再実装は二行目に位置する。そしてプロジェクトのアーキテクチャ——Dominikは「まず最も単純なパーサー→SVGレンダラー＋基本ドラッグでアーキテクチャの実現可能性を検証した」と語る——この判断は彼自身が下した。Codexはplan modeで選択式の質問として彼の意見を求めるのみだった。
どんな図を描くかは、ユーザーの判断だ。 エディタが提供するのはツールであって、審美眼ではない。
« loopには明確さが必要 »——この判断はTikZ Editorにぴたりと重なる
Ronacherは記事の末尾に、筆者が三度読み返した一文を書いた：
Adopting the idea of harness loops means that the harness decides when work is finished.
TikZ Editorの開発において「いつ修正が完了したか」を判断していたのは常にDominikだった。彼は二つのレンダラーの出力を並べ、差異を凝視し、Codexにどこがまだおかしいかを伝えた。loopの停止条件は、正しい出力がどのようなものかを知っている人間によって定義される。 これがRonacherの言う「loopの前提は明確さ」だ——何が正しいかを知るには、まず十分な数の粗悪なバージョンを経由しなければならない。エージェントは試行錯誤の退屈な部分を短縮できるが、「正しい」とは何かを定義することは代われない。
このロジックはTikZ Editorのユーザー側にも同様に当てはまる。ある学術研究者がエディタを開く。彼は量子状態のBloch球表現か、Transformerの自己注意機構の図を描きたい——これらの図がどのような見た目になるかは、まず彼の頭の中に意図として存在する。 エージェントは、この論文のコアとなる図をどうレイアウトすべきか、どの情報の流れを強調すべきか、色を緑にすべきかグレーにすべきかを決めることはできない。エージェントができるのは、アイデアが固まった後に、\draw[->] (-0.866,-0.5) -- (0.866,0.5)のような座標を手書きしなくて済むようにすることだけだ。
言い換えれば：退屈なエンジニアリングは機械にアウトソースできるが、意味判断は人間の手に留めなければならない。 これがTikZ Editorという具体的なケースにおける、現在のAIコーディングツールの能力境界の正確な投影だ。
楽観的な部分と、不確定な部分
筆者はこの分析を安易な中庸——「AIには良い面も悪い面もある」——に落とし込むつもりはない。TikZ Editorは本物の良いプロダクトだ。それは学界の何十年にもわたる長期未解決問題をコードで埋め、その埋め方はオープンソース（MITライセンス）、マルチプラットフォームサポート（Web + Linux/Windows/macOSデスクトップ）、さらには論文全体の.texファイルを開いてその中のTikZ図形を直接編集できる。Hacker Newsで最高評価のコメントの一つはドイツの大学院生によるものだ：「すべてのSTEM学生と研究者があなたに感謝します。」
不確定な部分はここにある：このパラダイムがどこまで行けるのか。
Dominikは7億tokenを消費してこのプロジェクトを成し遂げた。Ronacherはモデルが生成するコードの品質が後退していると懸念する——防御的すぎ、局所推論に終始し、不変条件を回避する。しかしTikZ Editorのケースでは、GitHub上の観察者が「コード構造はかなり良さそうだ」と評価している。この落差はどこにあるのか？
筆者の一つの推測はこうだ：タスク境界の明確さがアウトプット品質を決定する。 Knuth-Plassアルゴリズムの入力はテキストと行幅、出力は改行位置——正しさはレンダリング結果で直感的に検証できる。カラー混合の入力は二つの色と比率、出力は一つの色——正否は一目でわかる。TikZパーサーの入力はテキスト、出力はAST——レンダリングが崩れず、座標が合っていれば、正しい。
検証基準が視覚化可能なとき、loopはより信頼できる。検証基準に経験的判断が必要なとき、loopには人間が必要だ。
これはAIを「信じる」か「信じない」かの命題ではない。エンジニアリング上の命題だ：どのタスクが自動検証可能か？ 答えが「自動検証可能」なら、エージェントが引き受けるのに適している。答えが「人手判断が必要」なら、エージェントの価値はループの各ラウンドを加速することであり、ピリオドを打つことではない。
「退屈なエンジニアリング」から「やる価値のあるエンジニアリング」へ
Dominikの言葉に戻ろう——「これは人間がやりたがらないタスクだ」。この言葉の最も興味深い含意は：できないからではなく、やりたくないからだ。
TeXの改行アルゴリズムは1981年から存在し、公開文献にアルゴリズムの記述は完全であり、JavaScript実装も一つではない。red!20!blackのカラー混合モデルはxcolorのソースコードに明確に書かれている。問題は「誰も実装できない」ではなく、「最終製品のコア価値への貢献がわずか2%に過ぎないことに誰も4週間を費やしたくない」だ。
AIコーディングツールはこの計算を変えつつある。2%の限界価値に必要な時間コストが4週間から4時間、あるいは4分に縮まったとき、それは「やる価値がない」から「ついでにやっておく」に変わる。これはソフトウェア開発における人間の役割が消えることを意味しない——人間が何をするかの決定により集中でき、どうやるかの退屈な部分を機械に委ねられることを意味する。
Ronacherの最後の言葉はある意味でこれと同じことの負の側面を語っている：「何をするか」までもが機械に委ねられたとき、我々はシステムを理解する能力を失うかもしれない。 この二つの言葉を並べると、どちらか一方だけよりもはるかに真実に近い。
TikZ EditorのGitHubページはまだ更新が続いている。Dominikは次のステップとしてpgfplotsサポートの導入があり得ると述べている。筆者は「AIコーディングがソフトウェア開発を再形成している」とは言わない——その表現はあまりに漠然としている。しかし言えることは：人間が再実装を望まなかったTeX改行アルゴリズムが、エージェントによっていくつかの会話の中で実装され、ブラウザ側で複数行ノードを正しくレンダリングできるようになったとき、ある閾値はすでに越えられた。 次に注目すべきはもはや「AIはコーディングできるか」ではなく、「どのエンジニアリング判断を人間はアウトソースすべきでなく、どれはどうでもいいのか」だ。
この区別そのものが、おそらく今後数年間のソフトウェアエンジニアリングにおいて最も真剣に考え抜く必要のある問題となるだろう。