はじめに
だんだん寒くなってきてあったかいもの食べたいですよね。
僕は昨年仙台で食べた せり鍋 が忘れられず、この時期には食べたい一品です。
この記事は、サーバーワークス Advent Calendar 2025 の 5日目となります。
qiita.com
昨今色々新しい開発手法が生まれてきたりしていますが、
僕が考える「これからの開発でかんがえておくべきこと」 を書いてみます。
ご紹介するのは以下
1. 生成AIを活用した作業の効率化
2. AWSが提唱する AI駆動開発ライフサイクル
3. 本番環境にログインせずにデプロイ
それぞれ解説していきます。
1. 生成AIを活用した作業の効率化
昨今、色々な生成AIが出てきています。
Anthropic/ClaudeやOpenAI/ChatGPT、Google/Geminiなどなど、これらを活用して、文章や資料の作成、アイデア出し、壁打ち相手など日常業務に活用して対応工数を削減することを目的に利用されるシーンが多くなってきました。
個人的にはお客様からのお問い合わせの返信をする際に、まずはざっと文章を作って、生成AIを使って文章補正してもらい、自分でチェックした後に送付するなんてやり方で利用しています。
このあたりの利活用や環境構築など、弊社のメンバがブログに掲載してくれているので、ご参考いただければと思います。
ブログのまとめ記事は こちら
2. AWSが提唱するAI駆動開発ライフサイクル
弊社で生成AI活用推進を担当している針生が ブログ に掲載してくれた、AWSが提唱するAI駆動開発ライフサイクル、 AI-DLC ですが、従来は人間がAIと対話してタスクを終わらせる方法でしたが、これは逆で、AIが人間と対話していく方法になります。
AIが計画を作成して、文脈を理解するためにすり合わせのための質問をしてきて、人間の検証を受けた後に実装を進める。これを全てのソフトウェア開発ライフサイクル活動に対して迅速に繰り返し、全ての開発パスに統一されたビジョンとアプローチを提供するとのことで、開発者のコストを低減させれるという感じですね。
一度、針生の ブログ をご確認いただければと思います。
3. 本番環境にログインせずにデプロイ
ここが個人的な本題です。
AWSだとマネジメントコンソールにログインしてとか、ローカルにIAMユーザーのアクセスキーを用意して、コマンドを実行してデプロイしたりとかだと、誤った操作で意図せぬリソースの削除や変更が行われる可能性があるかと思います。
実は、デジタル庁でも Zero Touch Production に振れられたブログが書かれており、「うんうん」と頷いてしまいました。
参考： デジタル庁GCASガイド／ガバメントクラウドにおけるモダン化の定義 の「本番環境にログイン」
ということで、 Zero Touch Production の話を書いていきます。
Zero Touch Productionとは
GoogleのSREチームが提唱していて、 Building Secure Reliable Systems という本の中で書かれているのですが、プログラムだけでなく、インフラに関してもコード化し、パイプラインなどを利用してデプロイ自動化をすることで、人が本番環境にアクセスすることなく、全ての操作を自動化する方法です。
それにより、手動作業による運用コストの削減やミスを起こすリスクを軽減することができます。
そのためには、アーキテクチャやマネージドサービスをうまく活用していく必要があると思います。
実現方法
では、どのように実現していくかを考えていきます。
今回は、インフラ部分のみの話しにしますが、アプリケーションなども同じような感じでいけると思います。
前提条件
- Git系のサービスを利用していること
- IaC (Infrastructure as Code) を利用すること
- CI/CDできるパイプラインツールを利用すること
ここでは例を掲載します。実際には異なるものを利用する可能性はあると思いますが、ご了承ください。
今回の例ではAWSに集約した形でどう実現していくかを示します。
Git系のサービス
Gitとは、ソースコードなどのファイルの変更履歴を管理する分散型バージョン管理システムです。
プログラムやIaCを AWS CodeCommit で管理します。他のサービスだと GitHub や GitLab などがあります。
Gitを利用する際のブランチ戦略としては、 Gitflow を選択します。他のフローだと GitHub Flow や トランクベース などがあります。
GitHub Flowとトランクベースは良くにていますが、ブランチサイクルが1〜2日以下になるのがトランクベースです。
Gitflow例
gitGraph
commit id:"First Commit"
commit
branch develop
commit
checkout main
commit
branch hotfix
commit
checkout develop
commit
branch feature/XXX
commit
commit
checkout develop
merge feature/XXX
commit
branch feature/YYY
commit
commit
checkout hotfix
commit
checkout main
merge hotfix
checkout develop
merge hotfix
commit
checkout develop
merge feature/YYY
commit
branch release
commit
commit
checkout main
merge release
checkout develop
merge release
checkout main
commit
checkout develop
commit
checkout release
commit
GitHub Flow例
gitGraph
commit
commit
branch feature/001
commit
commit
checkout main
merge feature/001
commit
branch feature/002
commit
commit
checkout main
merge feature/002
commit
IaC (Infrastructure as Code)
IaCとは、これまで手動での設定などをしていたインフラなどのプロビジョニングをコードを利用して実現する手法です。
今回の例では、 AWS CDK (Cloud Development Kit) とします。
AWS CDKが使える言語としては、 JavaScript / TypeScript / Python / Java / C# / Go (開発者プレビュー) となります。
それ以外にも、 AWS CloudFormation や Terraform などがあります。
CI/CDパイプラインツール
CI/CDとは、継続的インテグレーション(Continuous Integration)と継続的デリバリー(Continuous Delivery)もしくは継続的デプロイメント(Continuous Deployment)の略で、CIではコードの静的解析やコンパイルなどのビルドとテストコードを効率的に実施し、CDではCIとして完了したコードを環境へデプロイするイメージとなります。継続的デリバリーと継続的デプロイメントの大きな違いは、本番環境にデプロイするかしないかになります。継続的デリバリーではテスト環境や検証（ステージング）環境へのリリースを行い、結合テストやシステムテストを実施し、品質が担保された状態が確保できれば、継続的デプロイメントで本番環境へ自動的にリリースするとなります。
今回の例では、 AWS CodePipeline 、 AWS CodeBuild とします。
それ以外にも、 Jenkins や GitHub Actions 、 GitLab Runner などがあります。
実現方法例
上記の例で上げたものを使って、 Zero Touch Production を実現する方法を図を使って例として、
AWSマネジメントコンソールを使わず、AWS IAMなどの権限設定で本番環境へのデプロイ順を示してみます。
実現方法例：前提条件
- コード管理でGit Flowを利用
- 開発時は
featureブランチを利用 - ステージング環境へのデプロイは、
developブランチを利用 - 本番環境へのデプロイは、
mainブランチを利用 featureブランチからdevelopブランチへのマージ前にコードレビューなどが完了している
図解説
① 開発者が AWS CodeCommit にあるリポジトリの feature ブランチから develop ブランチにマージ
② マージをトリガーに AWS CodePipeline を起動
③ AWS CodePipeline の フローにて 開発管理者にステージング環境へのデプロイ承認依頼を送付
④ 開発管理者が承認すると AWS CodePipeline のフローが次のフローを開始
⑤ AWS CodeBuild を起動
⑥ AWS CodeCommit のリポジトリにある develop ブランチのコードを取得
⑦ 取得したコードを実行して、ステージング環境のAWSリソースを構築
ここでシステムテストを実施し、全てのテストをパスしたことを前提とします。
⑧ 開発管理者が develop ブランチのコードを main ブランチにマージ
⑨ マージをトリガーに AWS CodePipeline を起動
⑩ AWS CodeBuild を起動
⑪ AWS CodeCommit のリポジトリにある main ブランチのコードを取得
⑫ 取得したコードを実行して、本番環境のAWSリソースを構築
これで、本番リリースが完了となります。
さいごに
生成AIの活用は今後どんどんされるべきことなんですが、以下に安全にリリースを継続的に実施するかももっと考える必要があると思っています。
個人的にいろんな方と話す機会があるのですが、本番環境へのリリースは自分のPCにコードをダウンロードして実行するや
AWSマネジメントコンソールにログインして手動でデプロイするなどをよく聞きます。
クレデンシャルなどの情報を人が管理することとなり、漏洩する危険性があります。
今回の Zero Touch Production を意識した環境構築をしたうえで、コードの開発をシステム開発前から実施・検討しておくことで、安全性が担保されたシステムリリースを行えます。
サーバーワークスでは、 Zero Touch Production を考えた DevOps開発 も得意としています。
是非お声がけを！！
