「すでに開発はほぼAIまかせで生産性爆上がり」という声がちらほらと聞こえる昨今，そんなことあり得るか？とかなり懐疑的だったのだが，今日，少し考えを改める出来事があったので記しておきたい．
これまでの違和感
Codexというツールを以前使ってみたときに，既存のコードをバリバリと置き換えてしまう挙動に恐怖を感じ，いやーこれ，恐ろしくて使えんわいとツールを封印してしまった．もちろん，書き換える前に「これでええやろか？」とレビューを促してくるのだが，そもそも，「こう書き換えるけどどうでっか？」と大量のコードを提示してくるので，そんなんいちいち全部確認できるかー！と，まずはその態度に拒否反応が出てしまった．
一方で，データ分析をするときに使い捨てのデータ処理スクリプトを書くときなんかは，パパッと作ってくれるので，それなりに便利かなとも感じていた．しかし，それはCodexのような開発支援型AIでなくとも他のAIでも，わりとよしなにやってくれる．
であるからして，ちょいちょいとAIに相談しながら，いわゆる「AIに壁打ち」しながら，ああなるほどこういうコードでやればいいんだと，コードの内容を全て納得しながら開発するスタイルが私の性分に合うと考えていた．
「開発はほぼAIまかせで生産性爆上がり」という主張は，少し無責任すぎやしないか？バグの温床になりやしないか？と，かなり疑問に思っていたのである．
考え方を改めた経緯
ところで，今日，Dialogbookに修了証をカスタマイズできる機能を追加した．Dialogbookの修了証は，背景となるPDFに，修了証を与える生徒・学生の氏名と，発行の日付（それとシリアルナンバー）を重ねて作るという仕掛けになっている．
なので，背景のPDFと，氏名や日付の位置とフォントの種類と大きささえ与えてあげれば，オリジナルの修了証を発行できるようにするのはさほど難しくない（とりあえず今回，シリアルナンバーの位置と大きさは固定とした）．
CertificateDesignという新たなテーブルを与え，それにしかるべきデータが突っ込まれていたら，そちらを使うというように修正し，オリジナル修了証を発行できるようにするのはさほど難しくなかった．チャッピーをアシスタントにしてパパッと作り上げた．これだけでも以前に比べたら生産性は爆上がり，ではある．
しかし，問題は，デザインの編集機能である．画面上でドラッグして位置を調整できるような，ユーザーフレンドリーなエディタが望ましい．しかし，それを作るのは面倒だなあと思っていた．
「Claudeに作らせてみたらどうだろう？」と試みに考え，いざ，作ってみたら，プロンプトの修正を数回行ったのみで，立派なエディタのアプリが出来上がった．素晴らしい．これはなかなかに役にたつじゃないか．
なぜうまくいったのか
うまくいったのは，このエディタとDialogbookの関係が，疎結合だったという理由が大きい．そもそも，Claudeに作ってもらったアプリのコードの内容を，私は全く把握していない．
ユーザーから入力すべき情報と，出力すべき情報が，比較的シンプルでクリアだった点もうまく働いた．ユーザーが入力すべきなのは，背景となるPDFのデータと，名前，日付の位置，フォントの種類，大きさだけである．
そして，このエディタが出力するべき情報も，単純である．背景のPDFをbackground.pdfという名前のファイルにしたものと，名前や日付などの設定情報をsettings.jsonというJSONフォーマットで表現されたテキストファイルを，ZIPでまとめてダウンロードできればよい．
仮にそのファイルをpackage.zipとしよう．このエディタとDialogbookと間は，形式的にはpackage.zipというファイル，さらには，そこには何のデータがどのように記載されるかというプロトコル「のみ」で結ばれている．
キーワードは疎結合
この考え方を拡張してみよう．
AIにコードを書かせる．そのコードの動作原理は問わない．AIの出力をブラックボックスとして扱い，それを組み合わせてシステムを作る．もしこれが可能であれば，それこそ「開発はほぼAIまかせで生産性爆上がり」になるだろう．
モジュール間のインタフェースをきっちり定義し，内部のコードには触らない．疎結合ここに極まれりという設計にする．それを徹底すれば，AI駆動型によるシステム開発の生産性は，爆上がりになる……かもしれない．
もっとも，それは理想論である．現実には，コードを追っかけて動作原理を見ないと安心できないというケースは多かろう．さらには，モジュール間のインタフェースをきっちり定義してその組合せだけで仕様を満たす設計を，誰もが描けるのか？という課題もある．
全てがそのような開発スタイルに置き換えられるとは到底考えられないところではあるが，今回のケースで身に染みて感じたのは，できるところからやればいいじゃないか，という極めて当たり前のことだ．
モジュールの単位を小さくすれば，そのモジュールの責任範囲は小さくなり，それはインタフェースの仕様も単純なものになるということである．今回のケース程度の単純さ加減であれば，コードの内容をいちいち追っかけなくても，ブラックボックスを組み合せるだけでOKだ．
これはある意味，ソフトウェア工学が追いかけてきた理想郷なのかもしれない．いまやいかなCプログラマであっても，printfの実装まで追いかけて確認するひとは（ほぼ）いないだろう．libcしかり，libmしかり．インタフェースさえしっかりしていて，挙動に実績があれば，人は信用してそのまま使う．
AIが作ったコードをビルディングブロックとして組み合わせてシステムを構築する，ブロックはAIがその品質を担保したブラックボックスであり，その内部には触らない．そんな開発スタイルに，今後はどんどんとシフトしていくのだろうと感じた本日の出来事であった．
