はじめに
今回は個人開発にて AIをメンターとして活用しながら、実装はあえて自分でやる というやり方に挑戦しました。
作成したものは AWS SSM で使うシェルスクリプトです。
作成の経緯は個人開発で完成したら失敗談も含めて話しますが簡単に述べるとAWS移行でデプロイ！の時にVPC Lambdaのエンドポイントが無く、外部インターネットに接続できず、外部APIの認証機能に問い合わせが出来ない。当然リクエストを送っても出口が無いので帰ってくることもなくtimeout
コスト抑えるために設計見直しという絶望的なやらかしをしてしまいました...
データの流れを把握する大切さを身をもって痛感しました...
実装を通じて得た気づきを共有できればと思います。
↓ 実際に作成したシェルスクリプト
#!/usr/bin/env bash
set -euo pipefail
# -e: エラーが発生した場合にスクリプトを強制終了する。
# -u: 未定義の変数が使われてたらエラーを出してスクリプトを強制終了する。
# -o pipefail set -eだけだとパイプラインの最後のコマンドしか検出できない
# 存在しないコマンド | echo "hello" でも通ってしまう(|は右側のコマンドを右に流して出力する)
# 1. 一時的なプレフィックスと作業ディレクトリの定義
PREFIX="example-app_$(date +%Y-%m-%d)"
WORK_DIR=$(mktemp -d --tmpdir "${PREFIX}.XXXXXXX")
KID="example-app-api-$(date +%Y-%m-%d)"
# -d のみだと現在の位置にディレクトリが作成されてしまう。pushして事故を起こす可能性があるので
# --tmpdirで一時ディレクトリを作成する
# 2. スクリプト終了時に一時ディレクトリを自動削除する設定
trap 'rm -rf "${WORK_DIR}"' EXIT
# 自動削除しないと更新しないと裏でゴミがたまってしまう
# 3. ECDSA (prime256v1) 鍵ペアの生成
# 秘密鍵の生成 (PEM形式)
openssl ecparam -name prime256v1 -genkey -noout -out "${WORK_DIR}/ec-p256-private.pem"
# 公開鍵の抽出 (DER形式)
openssl ec -outform DER -in "${WORK_DIR}/ec-p256-private.pem" -pubout -out "${WORK_DIR}/ec-p256-public.der"
# 4. Java/JWTライブラリで読み込めるように秘密鍵を PKCS#8 形式 (DER) に変換
# PEM 形式だと ----- TEXT ------を排除するコードを書かないといけないため実装コストが上がる。
openssl pkcs8 -topk8 -inform PEM -outform DER -in "${WORK_DIR}/ec-p256-private.pem" -out "${WORK_DIR}/ec-p256-private.der" -nocrypt
# 5. AWS SSM に登録するために Base64 エンコード (改行コードは削除)
# 76文字だと自動で改行されてエラーのもとになる
PRIVATE_B64=$(base64 "${WORK_DIR}/ec-p256-private.der" | tr -d '\n')
PUBLIC_B64=$(base64 "${WORK_DIR}/ec-p256-public.der" | tr -d '\n')
# 6. AWS SSM Parameter Store への登録コマンドを出力
# 秘密鍵は安全のために "SecureString" として保存します
# EOFは${}の中身を展開する
# 'EOF'はすべて文字列として展開する。
# JavaScriptのテンプレートリテラル的な
# SecureStringでAWS KMSで暗号化する
# 公開鍵はStringで保存
# --overwriteでterraform apply時に上書き
cat <<EOF
aws ssm put-parameter \\
--name "/example-app/prod/private_key" \\
--value '${PRIVATE_B64}' \\
--type "SecureString" \\
--overwrite
aws ssm put-parameter \\
--name "/example-app/prod/public_key" \\
--value '${PUBLIC_B64}' \\
--type "String" \\
--overwrite
aws ssm put-parameter \\
--name "/example-app/prod/jwt_kid" \\
--value '${KID}' \\
--type "String" \\
--overwrite
EOF
体感したこと
実装は明らかにAIの方が速い
言わずもがなですが、AIのアウトプット量には敵いません。
AIへの指示で出てくるコードを自前で実装しようとすると、下手すると 半日以上 は溶けます。
実務経験がまだない分、スピード差はここで特に痛感しました。
現代だと開発が非効率になる
速度がどうしても出ないため、実装に時間がかかるのは当然です。
また、AIの出すコードが正しいかを判別できない場合は結局ドキュメント参照になります。
ハルシネーションもあるため、ソース確認は必須だと感じました。情報が古い可能性もあります。
学べたこと
知識の定着率がかなり上がる
公式ドキュメントを参照したり、エラーと格闘することで「なぜ動かないか」を嫌でも体感できます。
効果的だと感じたフロー：
- 自力で 60点ほどの土台 を作る
- AIに指摘・足りない部分を補完してもらう
- 公式ドキュメントで最新情報を反映し、AIの出力と照合する
- 理解確認を声に出しながら言語化してmdにメモする
AIに出力させて「どう書くか説明してもらう」「写経する」だけでは、単語はわかるけど何やるんだっけ？ という状態になりがちでした。
声に出しながら打ち込む癖をつけることが副産物として大きな効果をもたらしました。また今後の学習の向き合い方にも繋がりました。
将来への投資になる
プライベートな時間にあえて自力実装したり、ダメなコードを書くことで「なぜ？」の検証ができ、実装力の向上が見込めます。
新しい技術が出たときは 公式ドキュメントスタート になるため、この経験が必ず活きると感じました。
また、あえてやばいコードを書いて試して直すを行うことで レビュー力も上がりそう……個人の感想ですが（笑）
脳みそが疲れる
めっちゃ疲れます。
どれが正しいのかを切り分けるために、情報の取捨選択が本当に大変でした。
AIがなかった時代の開発者様、すごい……現代に感謝。
おわりに
AIのプロンプト整理や設定を突き詰めるのもいいですが、たまには自力実装するのも悪くないと感じました。
そして何より——
実装できた時の嬉しさは段違いです！
ありがとうございました！