背景や目的
AIを活用する企業は日本でも多数を占めるようになり(2026年春71%/2025年春56%[pwc調べ])、注目は具体的効果の創出にシフトしています。とりわけ、ソフトウェア企業では、AIを利用した開発のトライアルが活発に行われている事でしょう。
そのツールとして、Claudeが注目される事が多いのですが、今回はAI本家のOpenAIを使って新規開発のトライアルをしてみます。生産性向上に向けた情報として、ご参考になれば幸いです。
トライアルの方針
実際の開発のミニ版をやるような内容にします。
１．開発するもの
日報管理システムを開発します。画面は数画面、DBテーブル数個のミニ版です。
２．利用AIツール
Open AIのChatGPTデスクトップ版を使います。2026年7月にリニューアルされています。
→GPTのリリースノート ※2026 年 7 月 9 日 の欄に記載あり
３．開発方法
以下のように進めます。
（１）AIに設計書を作成させ、人が内容確認。
（２）上の設計書をベースに、AIにPG作成させる。同時に導入手順書もAIが作成。
（３）上の導入手順書を使い、人がデプロイ。（試験は簡易確認に留めます。）
４．実行環境
AWS Lambdaを使い、Webアプリとして動作させます。DBはAWS内のRDS(Mysql)を使用。
１．ChatGPTデスクトップ版の準備
まずChatGPTを使えるようにします。通常はWebブラウザで使いますが、今回はPCにデスクトップ版をインストールします。
・ChatGPTのサイト(→リンク)にアクセスします。
・先頭画面で、Windowsのボタンを押し(お手元のPCに合わせ)、ポップアップ画面で保存を押し、保存したChatGPT Installer.exeをダブルクリックします。
そうすると、改めてダウンロードが始まり、右上画面が出たらインストール完了です。
・右上の画面で、サインインに進む を押します。
・お帰りなさい の画面で、GPTで既に使っているメールアドレスを入力し、続行を押します。
・メールが届くので、そこに記載されたコードを入力して、続行を押します。(右上画面)
最後にメアドの確認画面（左上）が表示されますので、
・そのまま続行を押します。そうするとデスクトップアプリが前面にあがってきます。（右上）
これでインストールは完了のはずですが、
以下もやっておきました（事前準備？自己紹介？）。
・エンジニアリング、自分向けのタスクを提案、にチェックし、続けるを押し(左上)、
・次の画面（右上）は、チュートリアルっぽいので、スキップを押しました。
・設定をスキップしますか？（左上）に対しては、ChatGPTへ移動 を押し、
・インポートの画面（右上）では、スキップ を押しました。
＃以前使ったClaude Coworkを検知してますね。面白いなぁ。今回は無視します。
・ようやく完了しそうな画面（上図）が出てきました。セットアップを完了 を押します。
ChatGPTの初期画面が表示されました！！
ChatGPTデスクトップ版の準備は完了です。
２．プロジェクトの作成
設計書とPG類をAIと共有するためのフォルダを設定します。
Claude Coworkでは、先にプロジェクトを作成しましたが、ChatGPTでもそうします。
・改めてChatGPTを起動します。Windowsタスクバーの検索ボックスから、該当アプリを呼び出し、それを押します。
ChatGPTが起動します（右上図）。画面内左上にCodexが選択された状態で進めます。
※ChatGPTかCodexか選択可能です。開発はCodexでやるようです。
・そこで、プロジェクトの右にある + を押します。
プロジェクト作成用ポップアップが開くので、
・まず適当な名称（左上図では、日報管理システム）を入力し、
・ソースフォルダー欄では、本開発用のローカルフォルダを指定しておきます。（右上図）
指定すると、左下図の状態になります。
※本開発用のローカルフォルダは、事前に別途作成しておきます。
・そこで、プロジェクトを作成 を押すと、
プロジェクトが１つ作成されました。（右上図）
これで、ChatGPT内で指示する場所が出来ました。
具体的な開発に進みます。
３．設計書の作成
ここからは、ＡＩとの会話になります。まず、設計書作成をします。
先ほど作成したプロジェクト：日報管理システム開発 が選択された状態で進めます。
設計書作成指示の一部として、設計書雛形ファイルを使いたいので、まず、
・その設計書雛形ファイルを先程設定したローカルフォルダに保存しておきます。
雛形は、以下のような内容にしてあります。
| シート名 | 記載する情報 |
|---|---|
| 表紙 | アプリ名、作成日、作成者、版数など |
| 改訂履歴 | 版数、改訂日、改訂内容、改訂者 |
| 基本情報 | 本開発の要求事項、など |
| 基本設計1(DFD) | データフロー図 |
| 基本設計2(テーブル一覧) | 利用するテーブルの一覧 |
| 基本設計3(テーブルレイアウト) | テーブル毎の定義情報 |
| 基本設計4(画面リスト) | 画面の一覧 |
| 基本設計5(実行環境) | 実行環境を記載 |
| 画面10(〇〇画面) | 各画面内の構成要素を定義 |
| 画面10(〇〇画面)詳細 | 各画面内の構成要素毎にロジックを記載 |
| ファイルリスト | 作成するPGファイル、設定ファイル |
| コーディング方針 | コード作成時の基本ルール |
お試しになる際は、それぞれ皆様がお使いの書式で良いかと思います。
記載済の文を情報源にし、見出しを考慮点として、AIが考えてくれます。
さて、作成指示を出します。指示文は以下の内容にしました。
| まず設計書を作成して下さい。以下がその雛形です。このエクセルファイルに記入して完成させて下さい。 日報管理システム開発/開発設計書_日報システム開発.xlsx 作成方法は以下の通りです。 1.各シートで、作成者や更新者の記入欄があります。それはあなたの氏名(AI太郎)を記入して下さい。承認者の欄は、私西原が記入しますので、追記は不要です。 2.シート「改訂履歴」は、作成(修正)する度に、１行追記して下さい。 3.シート「基本情報」に、今回の開発の要求情報が記載されています。これを参照し、それ以降のシートを作成して下さい。 4.シート「基本設計1(DFD)」に、今回のシステムのデータフロー図を記入して下さい。 5.シート「基本設計2(テーブル一覧)」に、今回のシステムのテーブル一覧を、記入して下さい。 6.シート「基本設計3(テーブルレイアウト)」に、テーブル毎のレイアウト情報を記入して下さい。 7.シート「基本設計4(画面リスト)」に、開発すべき画面(機能)の概要情報をリストアップして記入して下さい。 8.シート「基本設計5(実行環境) 」に、今回のシステムの実行環境を記入して下さい。 9.シート「基本設計4(画面リスト)」でリストアップされた各画面毎に、シート「画面10(〇〇画面)」を作成して下さい。その内容は以下のように作成します。 (1)そのシート名の〇〇は、シート「基本設計4(画面リスト)」で記入した名称に変更して下さい。 (2)シート内左部分には、画面の完成図を記載し、その中に全ての構成要素を記入し、番号を付記します。(例)1.-1や1.-2 (3)シート内右部分には、左部分で示した全ての構成要素の情報を記載します。具体的には、構成要素番号、構成要素名称、仕様概要、をそれぞれ記入します。 10.シート「画面10(〇〇画面)」定義した構成要素について、具体的な仕様をシート「画面10(〇〇画面)詳細」に、以下の要領で記入して下さい。 (1)まずそのシート名の〇〇部分を、シート「基本設計4(画面リスト)」で記入した名称に変更して下さい。 (2)シート内では、3,4行目に記載された見出し列に従って記載します。まず、構成要素の番号と名称を合わせて下さい。 (3)シート内の、それ以降の列で、タイプ、必須／任意、タイミングは、選択肢があるので、その中から記入して下さい。 (4)シート内の、その他の列は、3,4行目の記載内容を良く理解し、その内容を記載します。 11.最終的に提供して頂くファイル情報は、シート「ファイルリスト」に記入して下さい。その中に導入手順書も含めて下さい。 12.シート「コーディング方針」には、コード作成時の注意事項が記載されています。コード作成時には、これを遵守したコードを作成して下さい。 |
やや長文ですが、後で質疑応答が多くなるよりは良いかと、細かめに書きました。
これをChatGPTのいつもの入力欄にペーストします。モデルは5.6 Sol 軽 にしてます。
しばらくして、作成したよ！と返答がありました。約８分かかっていました。
ファイル自体は、[プロジェクトフォルダ]¥outputs¥019・・49 と謎な場所にありましたが、
中身を確認して、修正箇所をピックアップしました。大まかには以下の２つでした。
・文字の見切れ、画面イメージの間延び、残骸シート出現、等の人が見にくい問題。
・実行環境での、利用サービスの明確化。(APIGateway不要、Secretsを明示等）
これらを改善してもらう文を書いて再実行しました。
そして、その修正版を得て、再レビューをして・・、をもう少し繰り返して、
最終的に、レビュー３回でFixしました。
細部で少々気になる箇所がありましたが、コスパを考え、これで終了としました。
作成された設計書の一部を紹介します。以下のような内容になりました。
ちなみに、修正指示初回に、こういう許可確認がありましたが、
「一度だけ許可」を押しました。
Cドライブ内のCodex用の何かのキャッシュ情報を操作したかったようで、問題無しです。
設計書は完成しました。PG作成とデプロイに進みます。
４．PG作成とデプロイ
先ほど作成した設計書を参照しPG作成をしてもらいます。
指示文は以下の内容にしました。
| 先程Fixした以下の設計書を参照し、今度はPGファイルを作成して下さい。 [プロジェクトフォルダ]\outputs\019fd4d5-76f2-7222-8c15-be704f108249\開発設計書_日報システム開発_FIX版.xlsx なお、作成するファイルは、開発設計書のシート「ファイルリスト」に従って、保存して下さい。 作成したら、作成したファイルの導入手順書.txtの内容を確認します。 |
これをChatGPTの入力欄へコピーし、実行させます。
途中で、許可確認の画面がいくつか出てきました（下図）が、
どれも必要な事なので、「一度だけ許可」を押しました。（手動承認の解除は、維持にしました）
PGファイル作成を終わり、導入手順書が完成しました。（下図）
手順書をみて、問題箇所をピックアップしました。大まかには以下の２つでした。
・手順が大まかなので、具体的なコマンドにしてもらう。
・AWSの既存環境との競合をケアしておく。
これらを改善してもらう文を書いて再実行しました。
そして、また何度かそれを繰り返して、
最終的に、レビュー4回でFixしました。手順書自体は以下の内容となりました。
日報管理システム 導入手順書
作成者: AI太郎
更新日: 2026-08-07
1. この手順の全体像
原則として、AWSへの構築操作は利用者PCのWSL/UbuntuコンソールからAWS CLIとAWS SAM CLIを使って行う。
AWSマネジメントコンソールで行う操作は、「CloudShell VPC environmentを作成して開く」1か所だけである。
作業場所は次の2つに分かれる。
A. 利用者PCのWSL/Ubuntu
Python仮想環境の有効化、事前テスト、SAMデプロイを行う。
本書では有効化前を「user@PC:~$」、有効化後を「(venv) user@PC:~$」と表記する。
B. AWS CloudShell VPC environment
プライベート配置されたRDSへ接続し、テーブル構造と初期データを登録する。
本書では「cloudshell-user@aws:~$」と表記する。
SAMデプロイで作成されるもの:
VPC、プライベートサブネット、Lambda、Lambda Function URL、RDS for MySQL、
Secrets Manager、セキュリティグループ、CloudWatch Logs、VPCエンドポイント。
SAMデプロイだけでは作成されないもの:
RDS内部のusersテーブル、daily_reportsテーブル、初期利用者データ。
これらはdatabase/schema.sqlをCloudShellから1回実行して作成する。
重要:
DBエンジンは「Amazon RDS for MySQL 8.4.10」であり、MariaDBではない。
後述のmariadb105はMySQLへ接続するためのクライアントであり、DBエンジンを変更するものではない。
2. 提供ファイル
template.yaml AWS SAM / CloudFormationテンプレート
samconfig.toml 東京リージョン向けデプロイ設定
database/schema.sql テーブル、索引、初期利用者の作成SQL
src/app.py Lambdaハンドラー、画面・業務ロジック
src/db.py DB接続・トランザクション処理
src/auth.py 認証・セッション・CSRF処理
src/requirements.txt Python依存ライブラリ
src/templates/ HTMLテンプレート
src/static/ CSS、JavaScript
tests/ 単体テスト
docs/導入手順書.txt 本書
3. 前提条件
作業開始前に、次の条件が満たされているものとする。
(1) WSL/Ubuntuを利用できる。
(2) プロジェクトフォルダ直下に「venv」というPython仮想環境が作成済みである。
(3) venvには最新Pythonが設定されている。今回のLambdaランタイムに合わせ、Python 3.14であること。
(4) AWS CLIとAWS SAM CLIがWSL/Ubuntuへ導入済みである。
(5) AWSへデプロイできるIAMユーザーと、そのAccess Key ID、Secret Access Keyを準備済みである。
(6) IAMユーザーはCloudFormation、Lambda、RDS、EC2/VPC、IAM、Secrets Manager、
S3、CloudWatch Logs、CloudShellを操作できる。
S3権限はSAMがLambdaのZIPをデプロイ用領域へ一時アップロードするために使用する。
schema.sqlの受渡しにはS3を使用しない。
(7) 東京リージョンでRDS for MySQL 8.4.10が利用可能である。AWSコンソールで確認済みであること。
(8) 次のCIDRが既存VPC、社内LAN、VPN、Direct Connect、VPC Peering、
Transit Gateway等で使われていないこと。
VPC: 10.20.0.0/16
Private subnet A: 10.20.1.0/24
Private subnet B: 10.20.2.0/24
既存の172.31.0.0/16とは重複しない。
4. プロジェクトフォルダへ移動し、Python仮想環境を有効化する
本書では、Windows側のプロジェクトフォルダが次の場所にある前提とする。
C:\Users\nishihara\Documents\ChatGPT\nippo_system
WSL/Ubuntuを起動し、最初に次を実行する。
user@PC:~$ export PROJECT_ROOT='/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system'
user@PC:~$ cd "$PROJECT_ROOT"
user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ source venv/bin/activate
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ python --version
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ test -f template.yaml && test -f database/schema.sql && echo 'プロジェクトファイル確認OK'
python --versionでPython 3.14.x、「プロジェクトファイル確認OK」が表示されることを確認する。
以降のWSL操作は、このvenvを有効にした同じコンソールで行う。
5. AWS CLIを設定し、認証を確認する
AWS CLIが利用できることを確認する。
(venv) user@PC:~$ aws --version
(venv) user@PC:~$ aws sts get-caller-identity
すでに認証設定済みで、想定したAWSアカウントIDとIAMユーザーARNが表示された場合、aws configureは省略できる。
認証エラーになった場合、準備済みのIAMユーザー情報を次のように設定する。
(venv) user@PC:~$ aws configure
AWS Access Key ID [None]: ***準備済のアクセスキー
AWS Secret Access Key [None]: ***準備済のシークレットアクセスキー
Default region name [None]: ap-northeast-1
Default output format [None]:
「Default output format」は未入力のままEnterを押す。
実際のキーを本書、ソースコード、作業記録へ記載しないこと。
設定後、改めて認証とリージョンを確認する。
(venv) user@PC:~$ aws sts get-caller-identity
(venv) user@PC:~$ aws configure get region
想定したAWSアカウントID、IAMユーザーARN、ap-northeast-1が表示されればよい。
6. 必要なコマンドとPGを点検する
(venv) user@PC:~$ python --version
(venv) user@PC:~$ sam --version
(venv) user@PC:~$ aws --version
(venv) user@PC:~$ python -m pip --version
すべてバージョンが表示されればよい。Dockerは使用しないため、導入確認も不要である。
7. 事前テストとSAMテンプレート検証を行う
(venv) user@PC:~$ cd "$PROJECT_ROOT"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ python -m pip install --upgrade pip
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ python -m pip install -r src/requirements.txt
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ python -m unittest discover -s tests -v
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam validate --lint
単体テストの最後に「OK」、SAM検証の最後にテンプレートが有効である旨が表示されることを確認する。
8. ZIP形式のLambdaをビルドする
今回はZIPパッケージ方式で、LambdaのCPUアーキテクチャも一般的なWSL/PCと同じx86_64に設定している。
venvにLambdaと同じPython 3.14が設定されているため、Dockerや--use-containerは不要である。
(venv) user@PC:~$ cd "$PROJECT_ROOT"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam build --no-use-container
最後に「Build Succeeded」と表示されることを確認する。
9. WSL/UbuntuからAWSへデプロイする
(venv) user@PC:~$ export AWS_REGION='ap-northeast-1'
(venv) user@PC:~$ export STACK_NAME='nippo-daily-report-prod-20260807'
(venv) user@PC:~$ export NIPPO_VPC_CIDR='10.20.0.0/16'
(venv) user@PC:~$ export NIPPO_SUBNET_A_CIDR='10.20.1.0/24'
(venv) user@PC:~$ export NIPPO_SUBNET_B_CIDR='10.20.2.0/24'
(venv) user@PC:~$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
(venv) user@PC:~$ export SAM_ARTIFACT_BUCKET="nippo-sam-artifacts-${AWS_ACCOUNT_ID}-${AWS_REGION}"
Lambda ZIPの受渡し専用バケットを、内容が分かる固定名で1回だけ作成する。
この方式では、SAM CLIが「aws-sam-cli-managed-default」という管理スタックや、名前の分からないバケットを自動作成しない。
(venv) user@PC:~$ aws s3api head-bucket --bucket "$SAM_ARTIFACT_BUCKET" 2>/dev/null || aws s3api create-bucket --bucket "$SAM_ARTIFACT_BUCKET" --region "$AWS_REGION" --create-bucket-configuration LocationConstraint="$AWS_REGION"
(venv) user@PC:~$ aws s3api put-public-access-block --bucket "$SAM_ARTIFACT_BUCKET" --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
(venv) user@PC:~$ aws s3api put-bucket-encryption --bucket "$SAM_ARTIFACT_BUCKET" --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
(venv) user@PC:~$ printf 'SAM_ARTIFACT_BUCKET=%s\n' "$SAM_ARTIFACT_BUCKET"
作成されるバケット名は「nippo-sam-artifacts-＜AWSアカウントID＞-ap-northeast-1」である。
日報データやschema.sqlは格納せず、SAMが生成したLambda ZIPとデプロイ用テンプレートだけを格納する。
変更セット確認付きでデプロイする。
STACK_NAMEはRDS名やDB名ではなく、今回作成するAWSリソース一式を管理するCloudFormationスタック名である。
既存実験環境との混同・競合を避けるため「nippo-daily-report-prod-20260807」を使用する。
RDSの物理名はCloudFormationが自動生成するため、既存の「nippo-system-db」とは競合しない。
RDS内部のDB名は「nippo_db」だが、これは新しく作成するRDSインスタンス内だけの名前である。
(venv) user@PC:~$ cd "$PROJECT_ROOT"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam deploy --stack-name "$STACK_NAME" --s3-bucket "$SAM_ARTIFACT_BUCKET" --s3-prefix "$STACK_NAME" --capabilities CAPABILITY_IAM --confirm-changeset --region "$AWS_REGION" --parameter-overrides EnvironmentName=production VpcCidr="$NIPPO_VPC_CIDR" PrivateSubnetACidr="$NIPPO_SUBNET_A_CIDR" PrivateSubnetBCidr="$NIPPO_SUBNET_B_CIDR" EnableDeletionProtection=true --tags Application=daily-report-system Environment=production
--s3-prefixにSTACK_NAMEを指定しているため、このシステムの成果物はバケット内の
「nippo-daily-report-prod-20260807/」配下へまとまる。更新時も同じバケットと同じプレフィックスを使用する。
CloudFormation変更セットが表示されたら作成対象を確認し、問題がなければ「y」を入力する。
このコマンドでRDS for MySQLを含むAWSリソースが作成される。RDS作成には時間がかかる。
デプロイ完了時に「Successfully created/updated stack」と表示されることを確認する。
10. スタック出力値を確認する
(venv) user@PC:~$ aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].StackStatus' --output text
(venv) user@PC:~$ export NIPPO_VPC_ID=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`VpcId`].OutputValue' --output text)
(venv) user@PC:~$ export NIPPO_SUBNET_ID=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`PrivateSubnetAId`].OutputValue' --output text)
(venv) user@PC:~$ export NIPPO_CLOUDSHELL_SG=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`CloudShellSecurityGroupId`].OutputValue' --output text)
(venv) user@PC:~$ export NIPPO_DB_ENDPOINT=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`DatabaseEndpoint`].OutputValue' --output text)
(venv) user@PC:~$ export NIPPO_DB_SECRET_ARN=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`DatabaseSecretArn`].OutputValue' --output text)
(venv) user@PC:~$ export NIPPO_APP_URL=$(aws cloudformation describe-stacks --stack-name "$STACK_NAME" --region "$AWS_REGION" --query 'Stacks[0].Outputs[?OutputKey==`ApplicationUrl`].OutputValue' --output text)
(venv) user@PC:~$ printf 'VPC=%s\nSUBNET=%s\nCLOUDSHELL_SG=%s\nDB_ENDPOINT=%s\nDB_SECRET_ARN=%s\nAPP_URL=%s\n' "$NIPPO_VPC_ID" "$NIPPO_SUBNET_ID" "$NIPPO_CLOUDSHELL_SG" "$NIPPO_DB_ENDPOINT" "$NIPPO_DB_SECRET_ARN" "$NIPPO_APP_URL"
スタック状態がCREATE_COMPLETEまたはUPDATE_COMPLETEで、各値が空欄でないことを確認する。
表示結果をCloudShell操作用に控える。
11. schema.sqlの内容をコピーする
WSL/Ubuntuで次を実行し、表示されたSQL全文をクリップボードへコピーする。
(venv) user@PC:~$ cd "$PROJECT_ROOT"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ cat database/schema.sql
先頭のコメント行から最後のセミコロンまで、欠けないようにコピーする。
12. AWSコンソールでCloudShell VPC environmentを作成する
ここだけはWSLのコマンドではなく、AWSマネジメントコンソールで操作する。
(1) AWSマネジメントコンソールへログインし、リージョンを東京にする。
(2) CloudShellを開く。
(3) 「＋」から「Create VPC environment」を選択する。
(4) Nameに「nippo-db-setup」と入力する。
(5) VPCに手順10のNIPPO_VPC_IDを選択する。
(6) Subnetに手順10のNIPPO_SUBNET_IDを選択する。
(7) Security groupに手順10のNIPPO_CLOUDSHELL_SGを選択する。
(8) Createを押し、作成したVPC environmentを開く。
RDSをPublic accessへ変更しないこと。CloudShell VPC environment内のファイルは永続保存されない。
13. CloudShell上でschema.sqlを作成する
手順12で開いたCloudShell VPC environment内で、次を実行する。
cloudshell-user@aws:~$ cat > schema.sql
入力待ちになったら、手順11でコピーしたSQL全文を貼り付ける。
貼り付け後、行頭でCtrl+Dを1回押してファイルを保存する。
cloudshell-user@aws:~$ test -s schema.sql && echo 'schema.sql作成OK'
cloudshell-user@aws:~$ head -n 3 schema.sql
cloudshell-user@aws:~$ tail -n 3 schema.sql
「schema.sql作成OK」と表示され、先頭・末尾が元ファイルと一致することを確認する。
14. CloudShellからテーブル構造と初期値を作成する
山括弧部分は手順10で控えた実際の値へ置き換える。
cloudshell-user@aws:~$ export AWS_REGION='ap-northeast-1'
cloudshell-user@aws:~$ export NIPPO_DB_ENDPOINT='<NIPPO_DB_ENDPOINTの値>'
cloudshell-user@aws:~$ export NIPPO_DB_SECRET_ARN='<NIPPO_DB_SECRET_ARNの値>'
cloudshell-user@aws:~$ aws sts get-caller-identity
MySQL接続クライアントを点検し、入っていない場合だけ導入する。
cloudshell-user@aws:~$ command -v mysql || sudo dnf install -y mariadb105
cloudshell-user@aws:~$ mysql --version
cloudshell-user@aws:~$ command -v jq || sudo dnf install -y jq
mariadb105は接続クライアント名であり、接続先はRDS for MySQL 8.4.10のままである。
cloudshell-user@aws:~$ export DB_SECRET_JSON=$(aws secretsmanager get-secret-value --secret-id "$NIPPO_DB_SECRET_ARN" --region "$AWS_REGION" --query SecretString --output text)
cloudshell-user@aws:~$ export DB_USER=$(printf '%s' "$DB_SECRET_JSON" | jq -r .username)
cloudshell-user@aws:~$ export MYSQL_PWD=$(printf '%s' "$DB_SECRET_JSON" | jq -r .password)
cloudshell-user@aws:~$ mysql --host="$NIPPO_DB_ENDPOINT" --port=3306 --user="$DB_USER" --ssl < schema.sql
cloudshell-user@aws:~$ mysql --host="$NIPPO_DB_ENDPOINT" --port=3306 --user="$DB_USER" --ssl --database=nippo_db --execute='SHOW TABLES; SELECT login_id, user_name, role, is_active FROM users;'
cloudshell-user@aws:~$ unset MYSQL_PWD DB_USER DB_SECRET_JSON NIPPO_DB_SECRET_ARN NIPPO_DB_ENDPOINT
cloudshell-user@aws:~$ rm -f schema.sql
users、daily_reportsの2テーブルと、employee01、admin01の2利用者が表示されれば完了である。
この操作が「DB初期化」であり、RDSそのものの作成操作ではない。
15. 動作確認
WSL/Ubuntuへ戻り、URLを表示する。
(venv) user@PC:~$ printf '%s\n' "$NIPPO_APP_URL"
表示されたURLをGoogle Chrome最新版で開き、次を確認する。
(1) 社員「employee01 / Employee#2026」でログインできる。
(2) 日報の登録、一覧、詳細、修正ができる。
(3) 同一社員・同一対象日の日報を重複登録できない。
(4) 管理者「admin01 / Admin#2026」で全社員の日報を検索・参照できる。
(5) 管理者でも他社員の日報は編集できない。
(6) 未ログインで日報URLへ直接アクセスするとログイン画面へ遷移する。
16. 更新手順
新しいWSL/Ubuntuコンソールを開いた場合は、更新作業の最初にもvenvを有効化する。
user@PC:~$ cd '/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system'
user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ source venv/bin/activate
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ python -m unittest discover -s tests -v
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam validate --lint
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam build --no-use-container
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ export SAM_ARTIFACT_BUCKET="nippo-sam-artifacts-${AWS_ACCOUNT_ID}-ap-northeast-1"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ sam deploy --stack-name nippo-daily-report-prod-20260807 --s3-bucket "$SAM_ARTIFACT_BUCKET" --s3-prefix nippo-daily-report-prod-20260807 --capabilities CAPABILITY_IAM --confirm-changeset --region ap-northeast-1 --parameter-overrides EnvironmentName=production VpcCidr=10.20.0.0/16 PrivateSubnetACidr=10.20.1.0/24 PrivateSubnetBCidr=10.20.2.0/24 EnableDeletionProtection=true --tags Application=daily-report-system Environment=production
DB定義を変更する場合は、事前にRDSスナップショットを取得し、移行SQLを別途作成する。
17. 障害時の確認
HTTP 503の場合:
RDS状態、Lambda/RDSセキュリティグループ、Secrets Manager VPCエンドポイント、DB認証情報を確認する。
HTTP 500の場合:
CloudWatch Logsを確認する。ログへパスワードやSecretStringを出力しない。
CloudShellからRDSへ接続できない場合:
VPC environmentに指定したVPC、Subnet、Security groupが手順10の値と一致することを確認する。
CloudShellでdnfが失敗する場合:
template.yamlで作成されたS3 Gateway VPC Endpointとプライベートルートテーブルの状態を確認する。
このエンドポイントは閉域CloudShellからパッケージを取得する経路であり、schema.sqlの受渡しには使用しない。
18. アンインストール時の注意
RDS削除保護が有効なため、通常のスタック削除は失敗する。
アンインストールは、データ保管方針と最終スナップショット名を責任者が確認した場合だけ実施する。
RDSにはSnapshot方針が設定されているため、スタック削除後も残るスナップショットを個別に確認すること。
CloudFormationスタックを削除し、今後このシステムを再デプロイしないことを確認した後、
今回専用のSAM成果物とバケットを次のコマンドで削除できる。
user@PC:~$ cd '/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system'
user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ source venv/bin/activate
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ export SAM_ARTIFACT_BUCKET="nippo-sam-artifacts-${AWS_ACCOUNT_ID}-ap-northeast-1"
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ aws s3 rm "s3://${SAM_ARTIFACT_BUCKET}/nippo-daily-report-prod-20260807/" --recursive
(venv) user@PC:/mnt/c/Users/nishihara/Documents/ChatGPT/nippo_system$ aws s3 rb "s3://${SAM_ARTIFACT_BUCKET}"
このバケットにはバージョニングを設定していないため、上記で成果物とバケットを削除できる。
以上
これを参考に、デプロイをしました。
PC内のUbuntuコンソールとAWS CloudShellでの操作をして、約2時間で完了出来ました。
途中、sam deployでエラー(インスタンスdb.t4g.microはPerformance Insights)が出ましたが、template.yamlの修正にて、対応しています(AIが修正)。非対応
以下は、DB内の様子です。
テーブルも初期値もセットされていますね。
これで、デプロイ完了したはず。試してみましょう。
５．動作確認
早速、ブラウザで開いてみます。
手順実行時に得たURLをChromeで開きますと、、
開きました！！
途中で作成したSchema.sqlで作成した一般社員でログインしてみます。
日報一覧が開きました（右上）。日報を1件登録してみます。
各項目入力し、登録押下し（左上）、登録されました（右上）。よさそうです。
最後に管理者権限でも、試してみます。
管理者ユーザでもログインでき、先ほどの一般社員の日報が表示されました（右上）。
詳細を表示させても、
大丈夫ですね。登録データが正しく表示されています。
厳密には、途中で認証エラーがありまして、２度PG修正&再デプロイをしました。CSRF判定処理のミスでした。その２度の修正で、上記の状態になりました。
日報管理システム完成！
AI駆動開発のコスト削減効果
人が開発した場合と比較して、どれだけコスト圧縮できるのか、考えてみました。
以下は、今回AI活用した箇所のそれぞれ時間数を記録した結果です。
| 工数(h) 人が開発 | 工数(h) AI駆動開発 | |
|---|---|---|
| 設計 (画面x4、DBテーブルx2、AWS環境) | ８ | ２．３ |
| 製造 (ログイン、日報一覧、日報登録修正、日報詳細) | ８ | ２．３ |
| デプロイ (VPC環境、DB環境、アプリ環境構築） | ８ | ２ |
人が開発、の欄は想定工数です。これで単純計算すると、こうなります。
| 削減時間 | １７．４ｈ（／２４ｈ） |
| 削減率 | ７３％ |
実際の開発では、これ以外に試験や納品物作成等があるので、それぞれの案件で得られる効果は様々となりそうですが、ご参考となれば幸いです。
なお、今回はエンジニアスキルのある人が実行しています。
Claudeとの差異など
ClaudeでAI駆動開発をした時との比較で、気づいた点をまとめておきます。
基本的に、どちらも優秀な相棒でした。
１．設計やPG作成の質(本質的な推論)
LLM自体(Fable 5/GPT5.6 sol)の能力に依存しそうですが、どちらも十分でした。
２．エクセルの作文
文が見切れたり人の可視性の問題が発生しがちです。GPTもClaudeも概ね同じでした。
３．途中の質問
Claudeに比べて、ChatGPTは回答作成途中の質問が少なかった印象でした。好みの問題か。
４．利用制限
今回は、利用制限アラートは発生せず、GPT Plus($20/月)の範囲で最後まで使えました。
まとめ
AI本家のChatGPTでも、AI駆動開発が出来ました。Claudeと比較して、質の問題は全く無く、ミニ開発をデプロイまで完遂できました。
具体的効果の創出を考えると、AIコストがまず気になるところですが、今回はChatGPT Plusの月額固定($20)の範囲で収まりました。
GPT-5.6 Solの場合、入力125、出力750の割合で、利用権が消費されるようですが、今後実際の開発では、それを意識した指示出し等も重要になるかもしれませんね（修正範囲を限定するなど）。
→OpenAI Codex 料金
いずれにせよ、システム開発でのAI活用は重要ですし、もはや必須かもしれません。また対応したら、ご紹介します。お読み頂きましてありがとうございました！
お気づきの点がありましたら、以下の「ご連絡フォーム」から、コメントを頂けますと幸いです。