現在公開に向けて、D-Shelf（仮）というメディア管理プラットフォームのセルフホストアプリを開発中です。で、これは基本的にWeb UIで操作するのですけれど、やはり外部アプリとの連携もやりたい。すると、APIを用意するかなと思いました。
元々の設計として、フロントエンドとバックエンドにわけて、その疎通はAPIでやっていました。なので、何もわざわざ新しく作らずとも、今あるAPIのうちいくつかをドキュメント化すれば十分であるように思えます。AIに聞いても、この規模のアプリケーションならばそれが合理的との回答です。
そんでまぁ作ってくれと言ったら、秒で作ってくれました。大したものです。で、それはすぐに使えたのですが、いざ実行してみると、想定と動作がちょっと異なる。
具体的には、たとえば「[作家名] 作品名/作品名 1巻.pdf」みたいなファイルがあったとすると、これについて「作家名 -> 作品名 No.1」のような階層構造を推定して登録したかったのですが、実際にAPIで動かすとそうはなりませんでした。階層構造が推定されず、そのままの名前で登録されてしまったのです。
なので、AIに「Web UIで登録した時の挙動と異なる」と聞いたところ、どうやら「階層構造の推定はフロントエンドでやっていたため、そのロジックがスクリプトから漏れました」とのことでした。なるほど。
これはもっともな話です。ファイル名から階層構造の推定をするのが、バックエンドの仕事なのか、フロントエンドの仕事なのか、これは確かに、ちょっと微妙です。個人的には、APIの仕事は最小にしたいところです。そのほうが汎用的だからです。しかしそれだと、当然スクリプトは作り込みが発生します。また、Web UIロジックとの違いから、管理にばらつきが生じるかも。
うーん……などと思っていたところで、なんか10年前から考えていること変わらないな、と思いました。
まぁつまりこれはWeb APIというものの、原理的に正解のない問題なのであって、どう対応するかはアプリケーションのポリシーであり開発者の思想に基づきます。まぁ実際には、これこれの合理的な理由があるからだと自他を納得させる理屈付けをします。AIに言えば多分「こうするのが合理的です」と推奨案を出してくれます。それは参考になるかもしれません。しかし、僕は今回それについてはただ僕がそのまま考えようと思いました。
この問題は多分、突き詰めると、思想なんです。誰が何をすべきなのか。客観的なのはそのトレードオフだけで、そのスライドバーの調整に正解などありはしません。それを突き詰める思想の根幹がまだアプリケーションの中に根付いていないままに、AIの判断を仰ぎたくはない、と思いました（僕は作りながらいったい自分は何を作っているんだろうと考えるタイプなのです）。
そんなようなことを考えていると、何も変わらないなぁと思う一方、スニペットをAIが秒で作ってくれるという前提にたったとき、調整の仕方はやはり変わるように思われます。つまりAIにとって明確でわかりやすく取り回しの良い仕様のほうが良いはずで、そこから生じる複雑なスクリプト、これはAIは得意ですから、トレードオフとして問題が少ないように思われました。
もちろん、Web UIとのロジックの差分を完全に吸収できるか（またそもそもすべきなのか）といったことや、通信量、通信回数からくるパフォーマンスとコストの違いのような物理面は根源的な問題として残りますので、完全解決というわけではないんですけれど、「粒度の小さなAPIだと実装自体に手間がかかる」という問題についてはかなりの部分解決するわけです。これは実務上大きな違いだと思います。
そう考えると、AI時代においては、APIは小さく保ちつつ、どこでどういうロジックが任せられているのか、その根幹たる思想はなにか、ユーザにわかるようにすることが大事かもしれませんね。そして今後、AIの処理能力次第によって、スライドバーの調整は絶え間なく変わっていくことでしょう。スライドバーがある事自体は、変わりませんが。もしかするとスライドバーの調整までほとんど不要になる時は来るかもしれないのですが、それでもその存在だけは、認識を続ける必要があると思います。
コメント