AlchemIIIF開発の裏話も交えながら、ElixirとAI駆動開発の相性について書きます。
1. はじめに
AlchemIIIFは、私が約1か月かけてAI駆動開発で作成したWebアプリケーションです。考古学PDFレポートをIIIF v3アセットに変換・配信します。就労継続支援B型施設での実務活用を念頭に置いて開発しました。
おそらく、AIの助けなしにはこの短期間で形にすることはできなかったと思います。
日中は福祉の仕事をしながら、夜間や休日に開発を進められたのは、Elixirの生産性の高さとAIの助けがあったからです。
2. Elixirの生産性の高さ
Elixirは、とても生産性の高い言語だと感じています。特にそう思う理由は、次の点です。
-
REPL環境がある
実際に動かしながら試せるので、デバッグがとても楽でした。
-
変数が不変
IIIFマニフェストは「組み上げていく」ものなので、副作用を抑えながら積み上げていけるElixirの設計とよく合っています。
-
Rubyに近い読みやすい構文
-
パイプ演算子
PDF → 画像 → アノテーション → マニフェスト構築という変換の連鎖が、パイプ演算子と自然に対応します。 -
JSONとマップの類似性
-
構造的なパターンマッチング
3. ElixirのマップとIIIFの構造的な相性
Elixirを採用した理由の一つは、IIIFで扱うJSONとElixirのマップの構造が非常によく似ていることです。
たとえば、IIIF v3のマニフェストの基本的な形は次のようになります。
{
"id": "https://...",
"type": "Manifest",
"label": { "ja": ["遺跡調査報告"] },
"items": [ { "type": "Canvas", ... } ]
}
Elixirのマップでは、次のようにほぼそのまま対応できます。
%{
"id" => "https://...",
"type" => "Manifest",
"label" => %{"ja" => ["遺跡調査報告"]},
"items" => [%{"type" => "Canvas"}]
}
JSONをJasonでデコードするとElixirのマップになり、エンコードすれば再びJSONに戻せます。ほぼ無損失で行き来できるので、IIIFのように構造が深いデータを扱うときに、とても相性がよいと感じました。
さらに、IIIFのネストした構造をたどるときも、Elixirのパターンマッチを使うと「構造そのものを語る」ように書けます。
%{"type" => "Canvas", "items" => items} = canvas
4. 私とAI駆動開発
AIを使ってプログラミングを再開した
昨年からAIを使ってプログラミングを再開しました。Claude Codeが出てきた頃です。それまでは、業務で使う小さなスクリプトをたまに書く程度でした。
ところが、AIを使ってプログラムを書いてみると、これが面白かった。最初は半信半疑でしたが、思った以上にコードを書いてくれて、しかも動く。
学生時代や若い頃に、寝食を忘れてプログラムを書いていた頃の情熱がよみがえりました。
AIを使ってはまった罠
もちろん、最初からうまくいったわけではありません。喜んでいろいろ書かせてみた結果、次のような罠にはまりました。
- 指示が曖昧で、動かないプログラムを作ってしまった
- 設計なしで進めたため、中身のないよく分からないものができてしまった
- 実際の動作確認を最後までしなかったため、エッジケースで動かないものができてしまった
- 意図しないライブラリや言語を使われてしまった
これらは、仕様・要件・制約事項をきちんと決めないまま、AIに丸投げした結果です。
AIとの協働で意識していること
もともと私は発達障がいがあり、ワーキングメモリはかなり弱い一方で、言語理解や構造把握は得意です。そこで、その特性に合わせて、AIを「思考の補助輪」として使うようにしました。
AIを「思考の補助輪」として使うために、システム設計に関する本もいろいろ読みました。課金をだいぶ無駄にしてしまいましたが、その分学んだことは大きかったです。
その結果、今は次のような点を意識しています。
-
rules.mdなどに、必ず守ってほしい固有ルールを書く -
CLAUDE.mdなどに仕様を明確に書く - 仕様には、技術的要件だけでなく、何を作りたいのかという目的やゴールも書く
- 一度に変更するファイル数を限定する
- 必要に応じてASCIIアートやMermaidで図解し、実装理由も説明してもらう
- 逆に、必要に応じてMermaidを使って実装してほしい内容をAIに渡す
- 1機能ごと、変更ごとに実際に動かして確認する
- エラーが出たら、その都度修正してもらう
- AlchemIIIFで言えば、
mix reviewなどの統合テストを変更ごとに実施する- テストそのものはAIに任せてもよい
- テスト駆動開発を行う
- ただし、AIが無理やりテストを通そうとすることもあるので注意する
これらは、失敗から学んで身につけたやり方です。最近はAI駆動開発の書籍も出ていますが、そうした本を知ったのは、これらを自分でやり始めた後でした。
少し損をしたような気もしますが、やはり経験は強いです。
5. AI駆動開発とElixirの相性
Elixirは、PythonやRuby、C#などに比べると、AIにとっての学習データが少ないのではないかと思っていました。そのため、AIと協働するにはむしろ不利かもしれない、と考えていたのです。
ところが、AlchemIIIFに取りかかる前に、個人的なツールをAIと一緒に書いてみたところ、意外なほどあっさりと、しかも大きなエラーもなく書けました。
理由を考えてみると、次のような点があると思います。
- Elixirの構文に一貫性があり、推論しやすい
- 関数の入出力が説明しやすく、データの流れが明確
- AIにとっても検証しやすく、「この関数は何をするか」を伝えやすい
- パイプラインで処理の意図を表現しやすい
- かなり仕様書に近い形で書ける
- ExUnitのテストがシンプルで、AIにも扱わせやすい
- Phoenix Frameworkは、JavaScript中心のフレームワークに比べて構成が比較的一貫しており、ツールの使い方も整理されている
- そして何より、私自身との相性がよかった
6. おわりに
私は昔気質なので、「コードは自分の手で直接書かねばならない」とずっと思っていました。
しかし、適切にAIを使えば、自分の弱点を補いながら、目的のものを形にできます。そう実感してしまった以上、もう使わない理由はありません。
むしろ今は、プログラミングの本質は、必ずしもコーディングそのものではないのだと学び直しているところです。