こんにちは。Kaneyasuです。
先日、広島のこちらのイベントでLTさせていただきました。
本記事はこの時のLTをブログ化したものです。
このネタを思いついた背景
私はAWSを使ったお仕事をさせていただいていて、最近はAWS Step Functionsをよく使います。
とても便利なサービスだと思うのですが、前々からちょっと気になっていることがありました。
このように、AWS Step Functionsがローコードの仲間として扱われていることです。
ローコードには厳密な定義はなく、AWSなりの基準でこれがローコードならば、納得せざるを得ないのですが、個人的に少々違和感を感じたので、ゆっくり考えてみたら、危機感を覚えたというのが本記事のお話です。
このお話は、疑問を投げかけるような形で話が終わっており、ほぼポエムですがご容赦ください。
Amazon Transcribeを使った文字起こしで考えてみる
Amazon Transcribeは動画や音声ファイルから文字起こしをするサービスです。
これを使った文字起こしプログラムをベースに考えてみます。
MP3から文字起こしをするプログラムを、Pythonを使ったLambdaで実現するとこんな感じになります。
import boto3
import time
def lambda_handler(event, context):
# S3 URIを取得
s3_uri = event['s3_uri']
bucket = s3_uri.split('/')[2]
key = '/'.join(s3_uri.split('/')[3:])
# job名を生成 (S3オブジェクトキーから拡張子を取り除きます)
job_name = key.split('.')[0]
transcribe_client = boto3.client('transcribe')
try:
# Transcribeジョブを開始
response = transcribe_client.start_transcription_job(
TranscriptionJobName=job_name,
LanguageCode='en-US', # 言語を必要に応じて変更してください
MediaFormat='mp3',
Media={
'MediaFileUri': s3_uri
},
OutputBucketName=bucket
)
# 30秒ごとにジョブの状態を確認
while True:
status = transcribe_client.get_transcription_job(
TranscriptionJobName=job_name
)['TranscriptionJob']['TranscriptionJobStatus']
if status in ['COMPLETED', 'FAILED']:
break
time.sleep(30)
# ジョブの状態に応じて結果を返す
if status == 'COMPLETED':
return {
'status': 'success',
'message': 'Transcription completed successfully!'
}
else:
return {
'status': 'error',
'message': 'Transcription failed!'
}
except Exception as e:
# 例外処理
return {
'status': 'error',
'message': str(e)
}
AWS Trascribeによる文字起こしは結構時間がかかるので、非同期の処理になっています。
従って、文字起こしを始めた後、定期的に状態チェックして完了判定する必要があります。
- 引数でS3のパスを渡す
- Trascribeの起動
- ループを利用した定期的な完了判定
以上を実装すると文字起こしサービスを呼んでるだけなのに、意外と長いな・・・というソースになります。
また、Lambdaは15分制限があるので、そこに収まるかも気にしないといけません。
大きな動画ファイルだと、制限オーバーするかもしれないのでEC2で動かす?などが頭をよぎります。
AWS Step Functionsで考えてみる
上記の処理をStep Functionsを使って組み直すとこのようなイメージになります。
Step FunctionsはLambdaの実行順番を制御したり、条件分岐やループを作ることができます。
これを利用することにして、Lambdaを2つに分割します。
- Trascribeの起動
- Transribeのステータス取得
2つに分けたLambdaをStep Functionでコントロールさせます、
Lambdaを順に実行するところ、ループ、ステータスによる条件分岐などをStep Functionsに逃すことができます。
これで個々のLambdaはとても小さくシンプルになる上、Lambdaの時間制限からも解放することもできます。
また、Lambdaからループ処理を取り除いたことにより、実行時間の削減=コスト削減も期待できます。
いい感じです。
AWS Step Functionsはローコードなのか?
記事タイトルに戻ります。
いい感じではありますが、結局Step Functionsはローコードなのでしょうか?
よさげではありますが、Lambdaを書いてるし、Step Functionsもループや判定処理を意識してるので、ローコードと言われると違和感を感じます。
ローコードと言えばエンジニアでない方でも要件が実現できるものというイメージがあるので、そう考えるとやっぱり違うか?と感じます。
しかし、2023年8月現在はChatGPTがあります。
Step Functionsを使うと、個々のLambdaが小さくなります。
小さいLambdaはChatGPTと相性がとてもよく、自動生成がしやすくなります。
Step Functionsの方も、実は定義はJSONで書けて、これもChatGPTである程度書けます。
なんなら、ChatGPTとの長めのやり取りを覚悟するなら、これら一式を作るCloudFormationを生成することは可能です。
Step Functionsを使うことにより、各モジュールが整理され、それによりChatGPTとの相性がとてもよくなります。
各モジュールの自動生成ができるなら、ハードルがぐっと下がります!
これはやはりローコードと言い切っていいのではないでしょうか!!
いややっぱりローコードではないのでは?しかし来年はどうだろう?
いや、ちょっと待ってください。
個々のモジュールを小さくすればChatGPTとの相性がよくなるのはそうかもしれませんが、モジュール分割にはそれなりの知識がいるはずです。
このお話は、AWS Step FunctionsとLambda、そしてChatGPTのプロンプトをしっかり理解してることが前提になってますよね?
であれば、ローコードとは言えないのでは?
・・・ごめんなさい、そうです。
しかし、がっつり知識が要るのは、今今の話だと思うのです。
来年になれば、ラフな質問でもモジュール分割をするところからやってくれるかもしれません。
それはない?
では、非エンジニアの方、つまりお客様が知識を習得する可能性があるかもしれません。
いや、お客様がそこまで踏み込むとは・・・踏み込まないとは言い切れない。
ハードルが急激に下がったのは確かです。
言いたいところは、ChatGPTの登場により、ローコードではないものもローコードのようなものになった。
AWs Step Functionsはそれに類するもの・助長するものではないか?ということです。
そして、エンジニアの仕事とは何か?を考えなくちゃなという言うことです。
ごめんなさい、疑問をなげかけて終わりです!
乱文失礼しました!