AIにはできない「業務システムの設計」、プロなら今こそ取り組もう
コメント
注目のコメント
データモデル設計を商品販売単価を例に分かりやすく解説した良記事です。
ただし、「AIにはできない」のタイトルに引っかかりました。こういった設計こそ生成AIが本来得意とするところだからです。大量の事例を事前学習させた大規模データモデル生成AIを開発できれば、システム開発を飛躍的に効率化できるし、品質も向上できます。
今はまだ荒唐無稽な夢に聞こえるかもしれません。しかし、データセット整備さえできれば、AI技術的には実現可能性が高そうです。あるあるな内容がちゃんと解説されてますが、一般向けwebサービスにこの実装を持ち込むと爆死すると思うのでご注意を。。。
業務アプリと違ってアクセスする母数の桁が違うのでそれを踏まえた実装にする必要があるのはもちろんなんですが、業務の開始終了の概念がないので価格改定はどのタイミングで反映させるのか？という話になります。
db投入のタイミングで更新されると決済確認画面と決済価格が異なるとか、dbとappサーバの距離の問題で決済順序と価格反映が逆になる可能性とか地獄すぎるので、価格とopen_at、close_atなど日時的なものを持たせたくなり、またdbの負荷を減らす為にはマスターデータはappサーバにcacheしたくなります。
そしてユーザには価格が変わる件の注意書きを表示しておくとか、表示価格の有効期限のtokenを持たせておくとか、dead lockやlock wait timeoutを減らす為に在庫についてしっかりlockを取るのは決済の時だけにしてリスティング等では取らないとか。いろいろ。
AIにやってもらうとして、こういう条件をいろいろと漏れなくプロンプトに書ききれる気がしないので、実際には関数やmethod単位みたいな細かい粒度でサンプルコード的に書いてもらって、それを多少いじって組み合わせてクラスや処理の流れを人が構成する事になるんだろうなと。
AIにリッチなコードを書かせれば書かせるほど自分の意図した事と実装がズレてないかの確認コストも大きくなるわけで。機能追加を依頼したらコード全体がほとんど全部書き換えられたりしたら大変ですし。
AIでコード書かなくて良くなるんだ！とか簡単なコードしか書けないプログラマは不要になるんだ！みたいな事を叫ぶ方がいらっしゃるのは認識してますが、何となくコンプレックス商材化してるような気がしてて何とも言い難い微妙な気持ちになります。。。
妙な方向に話が展開された時に盲信する人がでたりしなければいいなと。
AIもコードもシステムも、それそのものが目的ではなくて、ビジネスのための道具でしかないので上手く使えば良いだけなんですけどね。なぜデータ上で矛盾が発生しているのかが分かりやすかった。
ただ、タイトルに違和感。。AIにはできないとする根拠が薄い
まだAIに何ができるかよく分かんないなら結論が分かんないでいい気がする
