IT開発の知識なしに生成AIを活用することはできないという話
AIコーディングサービスは銀の玉ではない
当方は生成AIの使用は慎重派です。
一方で、世の中は何でもかんでも使ってやれ。少なくとも私にはそう見えます。
これは２０００年代のIT化の乗り遅れの揺り戻しとも入れるでしょう。当時若手だった人は今や５０代から６０代、部長職以上の人も多いでしょうし、役職定年まで迎えている方も多くいらっしゃる年代です。
欧米のIT化の波乗り遅れたさらに上の世代を見ていたからこそ、何が何でも導入しないと、世界から後れを取る。そんな危機感を覚えているところでしょう。意識していなくても社会人なりたての頃の印象は強烈に刷り込まれているものです。
ただ、出始めの頃のIT同様、強力なツールであるからこそ、なくなるステップを意識しなければ、課題解決に使用はできません。
やみくもにAIツールを使っても新しい課題を増やすだけで、課題は解決できない。つまり、なんでも課題を解決してくれる銀の玉ではないのです
生成AIでなくなるプロセスは何か、具体的に考えてみる
私は生成AIとしてCopilotを強く押し出しています。これはGithub Copilotとの連携もあるためで、こちらを積極的に利用しています。
ではここで一例を見てみましょう。
プロンプトに「Snowflakeでサンプル値が含まれるカラムを探すコードを作って。」と入力します。
結果は１分ほどで帰ってきます
下記はその一部です
def get_columns_info(connection, database: str, schema: str, table_name: str)
query = f"""
SELECT
COLUMN_NAME,
DATA_TYPE,
IS_NULLABLE,
COLUMN_DEFAULT,
CHARACTER_MAXIMUM_LENGTH,
NUMERIC_PRECISION,
NUMERIC_SCALE
FROM {database}.INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = '{schema}'
AND TABLE_NAME = '{table_name}'
ORDER BY ORDINAL_POSITION
"""
cursor = connection.cursor()
cursor.execute(query)
columns = cursor.fetchall()
cursor.close()
df = pd.DataFrame(columns, columns=[
'COLUMN_NAME', 'DATA_TYPE', 'IS_NULLABLE',
'COLUMN_DEFAULT', 'CHAR_MAX_LENGTH',
'NUMERIC_PRECISION', 'NUMERIC_SCALE'
])
return df一見すると悪く内容のも思えます。このまま実行しよう。動いたらそのままでいい。
９０％のエンジニアはそうなるでしょう。コーディングができない人はこのままプロダクションコードにしてしまうでしょう。
ここが落とし穴です。
なにがいけないでしょうか。プロンプトには「要望」を記載しました。出てきたのは「コード」です。
具体的に見ていきましょう
開発には４フェーズ存在する
開発は「要件定義」「設計」「コーディング」「テスト」という４段階が必要となります。アジャイル開発であってもこの４段階は存在します。どんなに小さい開発でも存在します。特にアジャイル開発やノーコードローコードの開発では明確な境界線はなくなりつつありますが、しっかり存在します。
いま、プロンプトに入れたものは「要望」です。何を実現したいか大まかに入力しました。これは要件定義のインプットとして扱われます。出てきたものは「コード」そのもの。つまり「コーディング」の結果です。
生成AIでは「要件定義」「設計」という２フェーズが大きく飛んでいることが分かりますでしょうか。
この二つが飛んだことによる問題点を見ていきましょう
「要件定義」「設計」が飛ぶとなぜよくないか
「要件定義」「設計」には機能とは別の問題の議論や、運用方法の議論も含まれます。
「サーバはどれだけの大きさだから、どこまで耐えられるか」や「入力値は誰がいつ入れるか」、「サーバは止めていいのか」などの議論です。ここの議論があるからどのソリューションを選択するのか、どれだけの時間稼働させていいのか。が決定します。
それに応じてどの機能を開発の時にまとめるか（わかりやすいのは繰り返し処理をいつのタイミングで走らせるか）を決定します。
これがないとプロダクションになった時、確実に止まります。サーバが耐えられなくなったり、運用が回らなくなるからです。
さらに、止まった時どこが悪くて止まったのかの原因追及も行えなくなります
これらを生成AIに聞いて書き直しさせても、変なものを付け加えたり一貫性がなくなるためめちゃきちゃになるだけなのです。
ケーススタディ：上のコードの問題点
さて、上記のコードの問題点を考えましょう。
いったんスクロールを止めて考えましょう。
設計を意識していないのでかなり多くありますが、致命的になりうるものを２つ挙げます。
- テーブル逐一処理でデータのやり取りの回数が多すぎる
- Snowflakeのような大規模DBのデータに対してPandasのDataFrameを使っている
この二つは簡単に見てわかる致命傷です。
DBへの接続はトラブルが多い点であり回数は減らさなくてはなりません。負荷も大きくなりますし、時間もかかるところになります。
次にDataFrame。これはカラム指向のデータ型のためかなりのメモリを消費します。100万行レベルでも処理を行う場合、一般的なPCやインスタンスではあっという間にメモリ枯渇になるでしょう。
生成AIは簡単にコードを作れるが考慮しなければならない点は減らない
誰しもが考えるコードで生成AIは答えてくれましたが、ぱっと見でも２つも致命的な見落としがありました。
これらを解決するためには「プロンプトにあらかじめ入力する」という方法がとられます。しかし、プロンプトに入力するためには事前に考慮しなければなりません。生成AIで考慮しなければならない点はほとんど減っていないのです。
一方で開発ができない非エンジニアが使えば「開発できた気」になります。これだけ大きなことを見落としていても動いてしまうのです。
「設計」の考慮が抜ければ壁打ちなどしない
生成AIを積極的に使いたい人は次のように反論するでしょう
「壁打ちをすればいい」
これも大きな間違いです。
第２章で私は何を書いたでしょうか
このまま実行しよう。動いたらそのままでいい。
９０％のエンジニアはそうなるでしょう。コーディングができない人はこのままプロダクションコードにしてしまうでしょう。
動作確認だけして、そのままOKとしてしまいます。設計の考慮ができない人は壁打ちのための質問もできません。つまり、壁打ちなどしないでそのまま開発を終わらせます。
「要件定義」「設計」「開発」「テスト」の４つが理解できていないと、致命的な欠陥を見落としてそのままプロダクションにしてまいます。
上記の例で、しっかりとした開発現場であれば「テスト」のフェーズで気づけるでしょう。ただ、管理がしっかりできていない開発現場では見落として、すぐに止まるシステムしか作れないでしょう。
生成AIを活用するにはIT知識が不可欠。
上記の気づきができないまま「開発は生成AIで」というビジネスマンはかなり多くいらっしゃいます。
私の開発者、システムコンサルタントという立場では、私生活でもそういう方々とは距離を置くようにしています。そういった方々と親しい人とも距離を置きます。
仕事のパートナとしては不適切で、トラブルが起きたときに泣きつかれても、さらにトラブルが生じたり巻き込まれたりするだけですから。例えば、地方自治体のシステム開発を生成AIでやってるような企業があったとして、そのシステムが動かなくなったから何とかしてくれ。といわれても手助けはできません。最初からやり直し以外ありえないですが、それを受け入れられないからです。高コストになりますから。
今後、技術力を持った方や会社であればあるほど、こういった「AIだけで十分」という人たちとは距離を置くようになるでしょう。つまり、会社で考えれば「高品質な開発ベンダーは引き受けてくれない」となります。高品質なベンダーは高単価で顧客も選べます（高単価ですが工数は小さいので売り上げは変わりません）
顧客側も正しいIT知識を得ていかないと生成AIの波に乗り遅れるどころか、DXすら成し遂げられず、今の潮流から退場せざるを得なくなるでしょう。